Transcript Virtual Smart Card

Credential Repositories in an
Interprise Environment
Bob Cowles
Stanford Linear Accelerator Center
27 January 2003
Work supported by U. S. Department of Energy contract DE-AC03-76SF00515
Noon 2PM 4PM 6PM
http://average.matrix.net
8PM
India
China
Japan
Korea
Australia
8AM
10AM Noon 2PM
Grid Computing Model
Grid Vision
• Location independent access to computing
resources similar to access to the electrical grid
• User authenticates using PKI-based application
• Request job to be run
• Scheduler determines where job runs
• Data and computational resources brought
together
• Results are stored or returned
Grid Security Infrastructure
• Based on X.509 certificates
• International efforts coordinated by several
security working groups in the Global Grid
Forum (www.gridforum.org)
Statement of the Problem
• Provide trusted authentication and
authorization checking across security and
trust domains
• Risk model is difficult to determine
– What are threats and vulnerabilities?
• Protect but not interfere (too much)
– Balanced to reduce over/underprotection
– On the edge of chaos …
“Logging on” to the Grid
• Authenticate:
% grid-proxy-init
Enter PEM pass phrase: ******
• Creates temporary, short-lived proxy
credential
Proxy Credentials
• Proxy credentials are short-lived
credentials created by user
– Short term binding of user’s identity to
alternate private (and public) key
– Stored unencrypted for easy repeated access
– Short lifetime in case of theft
– Enables user to authenticate once then
perform multiple actions without
reauthenticating
Proxy Delegation
• Delegation = remote creation of a (second level)
proxy credential
–
–
–
–
New key pair generated remotely on server
Proxy cert and public key sent to client via SSL
Client signs proxy cert and returns it
Note: no private key movement across network
• Allows remote process to authenticate on behalf
of the user
– Remote process “impersonates” the user
Private Key Problems
• Private keys and users don’t mix
– No guarantee of good or any password choice
– No guarantee of secure private key location
• E.g., users store keys in network based file
systems
– No guarantee how private key was handled
• E.g., users copy/e-mail keys to remote machines &
leave them
• User managed keys cannot be trusted
Solitary Private Keys
• Never give a user their private key
– Can’t mishandle something you don’t have
• Provide a stronger security guarantee
– Signed cert as secure as institution’s accounts
– Must provide agent-based key handling
• E.g., smart cards
SACRED
• IETF RFC 3157
• SACRED is concerned with the secure
use of credentials in roaming or mobile
environment with: desktop or laptop,
mobile phone, PDA, etc.
• (thanks to Yuri Demchenko [email protected] )
IETF Information
• Internet-Drafts:
– Securely Available Credentials - Credential Server Framework
http://www.ietf.org/internet-drafts/draft-ietf-sacred-framework02.txt
– Securely Available Credentials Protocol
http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-bss00.txt
– PKI Enrollment Information
http://www.ietf.org/internet-drafts/draft-ietf-sacred-pkienrollinfo00.txt
• Request For Comments:
– Securely Available Credentials - Requirements (RFC 3157)
http://www.ietf.org/rfc/rfc3157.txt
SACRED Motivation
• Support user mobility by allowing roaming
user to retrieve / use credentials
• Allow to use the same credentials for/from
different user network appliances
• Secure user credentials by storing
credentials on Credential Server
SACRED Principles I
• Credentials MUST not be sent in the clear
during network transmission and SHOULD
not be in the clear when stored on an end
user device
• Secured credentials are defined for
SACRED: opaque (and partially privacy
and integrity protected) data object that
can be used by network device
SACRED Principles II
• Clients should be able to recover their
credentials from opaque object
• Credential formats SHOULD provide
privacy and integrity protection
• Credentials MUST be protected with a
second layer of encryption prior to network
transmission (using client/server
negotiated keys)
SACRED Framework
• The framework MUST support both "credential
server" and "direct" solutions.
• The "credential server" and "direct" solutions
SHOULD use the same technology as far as
possible.
• The framework MUST allow for protocols which
support different user authentication schemes
• The details of the actual credential type or
format MUST be opaque to the protocol, though
not to processing within the protocol's peers.
The protocol MUST NOT depend on the internal
structure of any credential type or format.
SACRED and Grid
• General issues:
– Traditional systems are client/server centric
– Grid computing is data centric
• Traditional systems:
– Protect system from users
– Protect data of single user
• In Grid systems:
– Protect applications and data from the execution system
– Stronger/mutual authentication needed to ensure resources and
data not provided by a attacker
– Different admin domains/Security policies
Kerberos
• IETF RFC 1510
• National Science Foundation project to
support KX.509 / KCA extensions for Grid
applications
http://www.nsf-middleware.org/documentation/NMIR1/1/KX509KCA/
KCA
• Acts (nearly) as root Certificate Authority
• Signs a certificate for user based on
Kerberos authentication ticket
• All resource providers must agree to
accept KCA signed certificates
KX.509
• Client side of protocol
• Generates key pair and sends certificate
containing public key to KCA for signing
• Resulting credentials can be used like a
GSI proxy certificate.
KX.509/KCA Drawbacks
• Site specific installation (based on KDC)
• Lacks scaling
– Requires multi-site trust (potentially)
– Grid projects (virtual organizations) have to
perform site-by-site negotiation of trust
Virtual Smart Card
Andrew Hanushevsky
Robert Cowles
Stanford Linear Accelerator Center
Work supported by U. S. Department of Energy contract DE-AC03-76SF00515
Virtual Smart Card (vsc)
• Premise: Physical smart cards (psc) in software
– vsc’s have a 1-to-1 concept correspondence to psc’s
Concept
Procurement
Possession
Operations
Tamper
protection
Theft protection
Physical
Virtual
Purchase/downlo
ad
Physical
Indirect
Request/generat
e
Authentication
Indirect
Self-destruct
Restricted access
Settable pin
Settable
password
VSC Conceptualization
• A vsc is implemented using a secure,
access restricted server
– One server holds many user’s private keys
• Hence, one server instantiates many vsc’s
– Can be well secured
• Restricted physical access
– Cages, keyed room, etc.
• Restricted logical access
– Only three access protocols needed: dns, ntp, and vsc
• Keys can be encrypted via user-supplied
passwords
VSC Procurement
CA
3. E-mail cert url
2. Generate keys and
send cert request
4. Download
CA signed
public cert*
1. Ask for a cert
User never sees the private key!
*When available
on 1st request or
automatic poll.
VSC Operation (vsc-proxy)
Externally authenticated (e.g., Kerberos)
1. Get public cert
2. Generate proxy
public/private key
3. Sign proxy cert
Private key never sees the network!
VSC Theft Protection
Externally authenticated (e.g., Kerberos)
2. Send encrypted key-string
1. Generate
key-string from a
strong user password
3. Encrypt user’s
x509 private key and
discard key-string
User must now supply key-string for vsc to use private key
VSC Advantages I
• Simple and effective
– Models well-known physical object -- smart
card
– Initial certificate request is trivial
• Private keys never exposed
– Can be further encrypted by user
• Can get proxy cert anywhere in the world
– No need to copy public/private keys
VSC Advantages II
• Can provide special always-on services
– Perhaps proxy cert revalidation
• Can provide stronger security guarantee
– Signed cert as secure as institution’s
accounts
VSC Disadvantages
• Private keys are concentrated
– Can be user-encrypted
– Similar problem in Kerberos
• May violate current CA CP/CPS
– Political vs. practical reality
• No more secure than external
authentication
– Need good authentication (e.g., K5)
Conclusion
• Virtual Smart Cards effective
– Simple, relatively transparent, secure
• Provides a path to more stringent security
– Physical smart cards
• Simplify user’s lives
– Ease of use reduces security lapses