Mechanisms to Secure x.509 Grid Certificates

1
Mechanisms to Secure x.509 Grid Certificates

• Andrew Hanushevsky
• Robert Cowles
• Stanford Linear Accelerator Center

2
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

3
Authentication

• Subject presents cert
• The cert must be valid (validity date)
• The cert must have been issued by trusted issuer
• Issuers private key signature must match
  re-computation done with issuers 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

4
x.509 SSL Authentication Overview
Might be a Secure Directory Service
CA Certs CRLs
Certificate Authority
Periodically get current CRLs
Perform SSL Handshake
Client
Server
Obtain Long-Term Cert
Send Cert Encrypted Authenticator
Authenticate Client 1) Authenticator must be
signed by Certs 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) Clients cert must not be
revoked (I.e., in the CRL).
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!

6
X.509 Difficult to Secure

• Secure private keys and users dont mix
• No guarantee of good or any password choice
• In fact, many users dont 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

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

8
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 /CNproxy to the Users name. ? Signs the
new cert with the long-term certs 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.

Server
Client
Authenticate Using Short-Lived Proxy Cert
9
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
Server
SACRED
Client
Authenticate Using Proxy Cert
Authenticate Download Cert
10
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
Server
Client
Authenticate Using Proxy Cert
Authenticate Get Proxy Cert
Generate Proxy Cert
11
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 CAs security domain.
Kerberos
Authenticate via kinit
Server
Client
Authenticate Using Obtained Cert
KCA
Get new cert via kx509
12
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.
Server
Client
Authenticate Using proxy Cert
Get proxy cert Signed or generated
Smart!
13
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
Server
Client
Authenticate Using proxy Cert
Sign proxy cert via vsc-proxy-init
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

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 institutions account

16
Conclusion

• X.509 Security is inherently difficult to protect
• Need some kind of key service for a practical
  solution
• Simplify users 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!

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-sac
  red-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.pd
  f