Virtual Smart Card_1_

Mechanisms to Secure x.509 Grid Certificates Andrew Hanushevsky Robert Cowles Stanford Linear Accelerator Center x.509 Certificate (abbreviated) Certificate Validating the Issuer of Next Cert in Chain Certificate Validating the Issuer of Next Cert in Chain Version (v1,v2,or v3) Subject DN (Distinguished Name) Issuer DN (Distinguished Name) Extensions Serial # (unique to issuer) Subject's public key Validity period Issuer’s Signature of Cert usually in same file as cert unencrypted for proxy certs C E R T Subject’s Private Key ( March 25, 2003 ) 2: CHEP 2003 Authentication Subject presents cert The cert must be valid (validity date)  The cert must have been issued by trusted issuer  Issuer’s private key signature must match recomputation done with issuer’s known public key  Subject proves that it knows private key   X.509 does not specify how this is to be done  De facto standard is via the SSL algorithm March 25, 2003 3: CHEP 2003 x.509 + SSL Authentication Overview Might be a Secure Directory Service Certificate Authority 1 Obtain Long-Term Cert Cert & Keys CA Certs & CRLs 4 2 Perform SSL Handshake Client 3 Send Cert + Encrypted Authenticator Server Authenticate Client: 1) Authenticator must be signed by Cert’s private key. (authenticator is an MD5 hash of all exchanged handshake bytes ) 2) Cert must not be expired. 3) Cert must be signed by a known and trusted CA. 4) Client’s cert must not be revoked (I.e., in the CRL). March 25, 2003 4: CHEP 2003 Security is Tenuous Model is predicated on various assumptions Certificate Authority is trustworthy  Client was independently authenticated  Client securely obtain long-term cert  Client securely maintained private key   This is the most problematic assumption  It is also one that appears to have a solution! March 25, 2003 5: CHEP 2003 X.509 Difficult to Secure Secure private keys and users don’t mix    No guarantee of good or any password choice  In fact, many users don’t want password on their keys No guarantee of secure private key location  E.g., users store keys in network based file systems E.g., users copy/e-mail keys to remote machines & leave them No guarantee how private key was handled  User managed keys should not be trusted March 25, 2003 6: CHEP 2003 Today’s Solutions Protect Long-Term Certificate  Use proxy-certs to limit key exposure damage  Grid-proxy-init Make x.509 cert handling convenient  Limit avenues for user error  SACRED, MyProxy Protect Identity Cert and Make it Easier  KCA, Smart Cards, VSC 7: CHEP 2003 March 25, 2003 Globus grid-proxy-init Proxy Cert Steps: ● Client generates a new public/private key pair. ● Uses it to construct a new short-lived cert. This is called a proxy cert and is distinguished by the addition of /CN=proxy to the User’s name. ● Signs the new cert with the long-term cert’s private key ● Uses the proxy cert wherever the long-lived cert would be used Since cert is short-lived, exposing the private key limits duration of damage. Cert can be passed along in a job for remote execution with limited danger. But client needs access to long-term private key to generate proxy cert. This allows the long-term private key to still be exposed to inadvertent disclosure. Cert & Keys Client Authenticate Using Short-Lived Proxy Cert Server March 25, 2003 8: CHEP 2003 SACRED (IETF Securely Available Credentials Protocol) SACRED Steps: ● Client contacts “secure” server via special XML (BEEP variant) protocol. ● Creates an account/password (all data is encrypted). ● Uploads any kind of credentials users wants (long-term or proxy). ● Uses account/password to download these elsewhere when needed. Handy and relatively secure world-accessible repository for credentials. Proxy certs can be generated where needed. Cert & Keys But client needs to protect credential server password now and make sure that the long-term cert is not left behind in some un-trusted location. 2 Generate Proxy Cert Discard Long-Term Cert Authenticate & Download Cert SACRED Client Authenticate Using Proxy Cert Server 1 March 25, 2003 9: CHEP 2003 3 MyProxy ● Client contacts an allowable server via special protocol. myproxy-init ● Uploads delegated short-lived (e.g., 1 week) proxy credentials associated with an arbitrary userid/password and download restrictions. myproxy-get-delegation ● User or service acting in behalf of the user can download a MyProxy generated short-lived proxy cert for use with a server. ● Uses account/password to download these elsewhere when needed. MyProxy Steps: Cert & Keys Much like SACRED but with additional restrictions (e,g., only proxies) and more authentication mechanisms (e.g., Kerberos, x.509). But private key is still unverifiable and the proxy damage window has increased to one or more weeks. MyProxy Generate 2 Proxy Cert March 25, 2003 1 Authenticate & Get Proxy Cert Client Authenticate Using Proxy Cert Server 3 10: CHEP 2003 KCA (Kerberos Certificate Authority) KCA Steps: ● User registers with a known organization & gets a Kerberos account. kinit; kx509 ● Login via Kerberos and get fresh short-lived credentials from a special server, ● Use obtained certificate anyway you choose. User can always obtain a fresh cert from anywhere in the world. User Registry Significant increase in the complexity of trust. You are a CA with all of the attendant problems: any breach allows the attacker to generate practically any certificate within the CA’s security domain. Kerberos 1 Authenticate via kinit KCA 2 March 25, 2003 Client Get new cert via kx509 11: CHEP 2003 Authenticate Using Obtained Cert Server 3 Smart Card Smart Card Steps: ● User gets a physical card with a password protected identity cert. ● User inserts card into a reader, enables it via password, and asks card to either sign a generated proxy cert or generate a signed new one for later use. ● Use smart card proxy certificate as you would a normal proxy certificate. Card is portable so user can obtain a fresh proxy certificate and never see the private key (private key never leaves the card). Smart card readers not widely deployed. Get proxy cert Signed or generated Client Authenticate Using proxy Cert Server 1 March 25, 2003 12: CHEP 2003 2 VSC (Virtual Smart Card) VSC Steps: ● User registers with a known organization & typically gets a Kerberos account. ● User requests the VSC server, only once, to obtain a long-lived cert for them. kinit; vsc-proxy-init ● Login via Kerberos (or other) and get proxy cert signed by long-term cert. ● Use VSC proxy certificate as you would a normal proxy certificate. User can obtain a fresh proxy cert from anywhere in the world & never see the private key (private key never leaves server). Server may require key encryption. Breach of the VSC server exposes any unencrypted certs to compromise. User Registry Kerberos Authenticate via kinit (or other) 1 Client Sign proxy cert 2 via vsc-proxy-init March 25, 2003 13: CHEP 2003 Authenticate Using proxy Cert Server 3 Software Solution Summary Each solution presents its own problems  grid-proxy-init  Private long term must be available and may be potentially mishandled Private long term is available and may be potentially mishandled Private keys never see the wire (no long-term private key) but issuer relies on very strong trust assumptions  SACRED & MyProxy   KCA   VSC  Private keys are never exposed but long-term keys are concentrated on a secure server March 25, 2003 14: CHEP 2003 VSC May Have The Edge Simple Model  Initial certificate request is trivial Can be further encrypted by user No need to copy public/private keys Perhaps proxy cert validation Signed cert as secure as institution’s account 15: CHEP 2003 Private keys never exposed  Can get proxy cert anywhere in the world  Can provide special always-on services  Can provide stronger security guarantee  March 25, 2003 Conclusion X.509 Security is inherently difficult to protect  Need some kind of key service for a practical solution Simplify user’s lives  Reduce security lapses  Virtual Smart Cards effective Simple, relatively transparent, secure  Provides a path to more stringent security   Physical smart cards  Promotes a congenial grid security environment! 16: CHEP 2003 March 25, 2003 References KCA/x.509  http://www.nsf-middleware.org/documentation/NMIR2/0/KX509KCA/ http://globus.org/ Globus grid-proxy-init  MyProxy      http://www.ncsa.uiuc.edu/Divisions/ACES/MyProxy/ http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocolbss-06.txt http://www.imc.org/ietf-sacred http://slac.stanford.edu/~abh/vsc http://www.cs.dartmouth.edu/~pki02/Sandhu/paper.pdf 17: CHEP 2003 SACRED Virtual Smart Card March 25, 2003