Mechanisms to Secure x.509 Grid Certificates Andrew Hanushevsky Robert Cowles Stanford Linear Accelerator Center

March 25, 20032: CHEP 2003 x.509 Certificate (abbreviated) Version (v1,v2,or v3)Serial # (unique to issuer) Validity period Subject DN (Distinguished Name) Subject's public key Issuer’s Signature of Cert Extensions Issuer DN (Distinguished Name) Certificate Validating the Issuer of Next Cert in Chain Subject’s Private Key ( ) usually in same file as cert unencrypted for proxy certs CERTCERT Certificate Validating the Issuer of Next Cert in Chain

March 25, 20033: 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 re- computation 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, 20034: CHEP 2003 Authenticate Client 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). x SSL Authentication Overview ClientServer CA Certs & CRLs CertificateAuthority Might be a Secure Directory Service 1 2 Periodically get current CRL’s 3ObtainLong-TermCert Perform SSL Handshake Send Cert + Encrypted Authenticator 4 Cert&Keys

March 25, 20035: 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 Client securely maintained private key This is the most problematic assumption It is also one that appears to have a solution!

March 25, 20036: 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 No guarantee how private key was handled E.g., users copy/ keys to remote machines & leave them should not User managed keys should not be trusted

March 25, 20037: 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

March 25, 20038: CHEP 2003 Globus grid-proxy-init Proxy Cert Steps 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 Authenticate Using Short-Lived Proxy Cert ServerClient

March 25, 20039: CHEP 2003 SACRED (IETF Securely Available Credentials Protocol) SACRED Steps 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. 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. Authenticate Using Proxy Cert Server SACRED Authenticate & Download Cert Generate Proxy Cert Discard Long-Term Cert Client Cert&Keys

March 25, : CHEP 2003 MyProxy Steps MyProxy Steps: ● Client contacts an allowable server via special protocol. myproxy-init myproxy-init ● Uploads delegated short-lived (e.g., 1 week) proxy credentials associated with an arbitrary userid/password and download restrictions. myproxy-get-delegation 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.  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 Authenticate Using Proxy Cert Server MyProxy Authenticate & Get Proxy Cert Generate Proxy Cert Client Cert&Keys

March 25, : CHEP 2003 KCA Steps KCA Steps: ● User registers with a known organization & gets a Kerberos account. kinit; kx509 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. 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. KCA (Kerberos Certificate Authority) UserRegistry Authenticate Using Obtained Cert Server Kerberos Authenticate via kinit KCA Get new cert via kx509 Client

March 25, : CHEP 2003 Smart Card Steps 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. Smart Card Authenticate Using proxy Cert Server 1 2 Get proxy cert Signed or generated Client

March 25, : CHEP 2003 VSC Steps 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 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. VSC (Virtual Smart Card) Authenticate Using proxy Cert Server Kerberos (or other) Authenticate via kinit 2 3 Sign proxy cert via vsc-proxy-init 1 Client UserRegistry

March 25, : CHEP 2003 Software Solution Summary Each solution presents its own problems grid-proxy-init Private long term must be available and may be potentially mishandled SACRED & MyProxy Private long term is available and may be potentially mishandled KCA Private keys never see the wire (no long-term private key) but issuer relies on very strong trust assumptions VSC Private keys are never exposed but long-term keys are concentrated on a secure server

March 25, : CHEP 2003 VSC May Have The Edge Simple Model 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 Can provide special always-on services Perhaps proxy cert validation stronger Can provide stronger security guarantee Signed cert as secure as institution’s account

March 25, : CHEP 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!

March 25, : CHEP 2003 References KCA/x R2/0/KX509KCA/ R2/0/KX509KCA/ Globus grid-proxy-init MyProxy SACRED bss-06.txt bss-06.txt Virtual Smart Card