1 / 17

Mechanisms to Secure x.509 Grid Certificates

Mechanisms to Secure x.509 Grid Certificates. Andrew Hanushevsky Robert Cowles Stanford Linear Accelerator Center. Version (v1,v2,or v3). Serial # (unique to issuer). Subject DN (Distinguished Name). Subject's public key. Issuer DN (Distinguished Name). Validity period. Extensions.

fia
Download Presentation

Mechanisms to Secure x.509 Grid Certificates

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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 3: CHEP 2003

  4. Cert & Keys 3 2 4 1 x.509 + SSL Authentication Overview Might be a Secure Directory Service CA Certs & CRLs Certificate Authority Periodically get current CRL’s Perform SSL Handshake Obtain Long-Term Cert Client Server Send Cert + Encrypted Authenticator 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). 4: CHEP 2003

  5. 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! 5: CHEP 2003

  6. 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/e-mail keys to remote machines & leave them • User managed keys should not be trusted 6: CHEP 2003

  7. 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

  8. Cert & Keys 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. Client Server Authenticate Using Short-Lived Proxy Cert 8: CHEP 2003

  9. Cert & Keys 1 2 3 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. 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. Generate Proxy Cert Discard Long-Term Cert SACRED Client Server Authenticate & Download Cert Authenticate Using Proxy Cert 9: CHEP 2003

  10. Cert & Keys 1 2 3 MyProxy MyProxy Steps: ● 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. 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 Client Server Authenticate & Get Proxy Cert Authenticate Using Proxy Cert Generate Proxy Cert 10: CHEP 2003

  11. User Registry 1 2 3 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. 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 Authenticate via kinit Client Server Authenticate Using Obtained Cert KCA Get new cert via kx509 11: CHEP 2003

  12. 1 2 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. Client Server Get proxy cert Signed or generated Authenticate Using proxy Cert Smart! 12: CHEP 2003

  13. User Registry 2 3 1 VSC 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. Kerberos (or other) Authenticate via kinit Client Server Authenticate Using proxy Cert Sign proxy cert via vsc-proxy-init 13: CHEP 2003

  14. 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 14: CHEP 2003

  15. 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 • Can provide stronger security guarantee • Signed cert as secure as institution’s account 15: CHEP 2003

  16. 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

  17. References • KCA/x.509 • http://www.nsf-middleware.org/documentation/NMI-R2/0/KX509KCA/ • Globus grid-proxy-init • http://globus.org/ • MyProxy • http://www.ncsa.uiuc.edu/Divisions/ACES/MyProxy/ • SACRED • http://www.ietf.org/internet-drafts/draft-ietf-sacred-protocol-bss-06.txt • http://www.imc.org/ietf-sacred • Virtual Smart Card • http://slac.stanford.edu/~abh/vsc • http://www.cs.dartmouth.edu/~pki02/Sandhu/paper.pdf 17: CHEP 2003

More Related