Digital Certificates

1
Digital Certificates

• Per HAGEN
• CERN IT
• Internet Services
• June 2000

2
Words of warning

• Our project is somewhat behind schedule compared
  to original plan
• We are still working on a prototype service these
  days
• The project has not been reviewed from important
  decision making bodies in CERN
• But some user requirements are known

3
Some relevant standards

• The IETF reference sitehttp//ietf.org/html.chart
  ers/wg-dir.htmlSecurity_Area
• Public-Key Infrastructure (X.509) (PKIX)X.509 v3
  v2 CRL (RFC 2459)
• LDAP v2 for certificate and CRL storage (RFC
  2587)
• Guidelines practices (RFC 2527)
• S/MIME v3 (RFC 2632 2633)
• TLS 1.0 / SSL v3 Transport Layer Security (RFC
  2246)

4
What certificates are typically used for

• Secure channel TLS / SSL for web servers
• Sign emails
• Authentication
• Code signing
• Encrypt files (EFS in Windows/2000)
• IPsec (encrypt network layer)

5
Recap how it works ...

• Certificates are based upon PK (public key)
  technology
• A pair of keys are linked together with an
  asymmetric algorithm (one-way).
• The user requests a certificate via a local
  application (example web browser).
• At this point of time a key-pair is generated.
• The public key is part of the certificate, while
  the private key is never exposed to somebody else
  (not even local administrators).
• Asymmetric keys are only used for small amount of
  data (signing, protecting private keys).
  Symmetric keys (like 3DES) are used for bulk
  transfer of data.

6
how it works (2)

• The certificate is signed by a certificate
  authority (CA)
• The CA checks that the certificate user indeed is
  the one he claims to be in the certificate
  request.
• The CA signing is recursively based upon the
  usage of certifcates. The root CA certificate is
  self-signed.
• The CA is therefore a critical part of the system
  and must operate in a secure and predictable way
  according to some policy to achieve confidence.

7
Main parts of a digital certificate system

• Requst and issue certificates (different
  categories) with verification of identity
• Storage of certificate (including the private
  key)
• Publishing of certificates (public part) to
  anyone (LDAP, HTTP)
• Pre-install root certificates in a trusted
  environment
• Support by platform, applications and services to
  use certificates
• Maintain database of issued certificates (no
  private keys!)
• Helpdesk (information, lost compromised private
  keys)
• Publishing of CRLs (and enforce apps to do
  revocation checking)

8
Driving forces for requirements

• QA (achieve true security)
• Integration with existing, local user
  registration / authentication
• Interoperate inside and outside (platforms x
  organisations)
• Ease-of-use and central manpower

9
Project so far in CERN

• Currently using Web server certificates (SSL)
  from Verisign
• Advantage Root certificate pre-installed
  (pre-trusted) in browsers. Less user support.
• Disadvantage Cost money, 1 year life-time, need
  to revoke when upgrade web server (interop
  problem within Microsoft products)
• Too expensive and complicated to deploy on a
  large-scale (like for personal certificates)
• This was chosen last year in order to have
  something working (and gain experience) quickly
• IT now has an overall commitment towards using
  Windows/2000 technology for providing services

10
Near future

• Verisign SSL certificates will be used for secure
  communication to mail servers (meant for external
  users over Internet)
• We are just now (this week) starting a prototype
  with Windows/2000 CA
• This will hopefully one day provide an integrated
  and automated solution for our 5-7000 Windows
  users
• Obviously, we must also support other centrally
  registered users (UNIX / AFS)

11
Breakdown of a X.509 cert

• Version V3
• IssuerCNCERN Certificate Authority OCERN
  LGeneva SSwitzerland CCH Eemail_at_address
• Serial Number integer
• Validity from-to date and times
• Subject CNPer HAGEN
  OCERN LGeneva SSwitzerland CCH
• Public Key RSA n 512
  bits
• Key Usage (intended purpose)
• Standard extensions like CRL and policy
• Vendor-specific extensions
• Signature algorithm signature SHA1-RSA
  hash

12
CA hierarchy for HEP ?

• Having one CA hierarchy for HEP does not seem to
  solve any real problem (although it looks neater)
• When validating a certificate, all certificates
  including root CA must be accessible
• Issuing and validation of certificates must be
  done where user registration is
• To which CERN account should a SLAC user
  certificate map? Is there a need for a HEP-wide
  user-registration? Or special guest accounts?

13
Improve HEP interop

• Pre-install root certificates into user apps
• Configure LDAP directory services into user apps
  (where public keys are advertised)
• That is, my email client should by default
  recognise all HEP sites

14
Security of CA

• Must minimise risk of CA private key being
  compromised
• Best option is to have off-line signing CA
• Microsoft recommends using CA hierarchy where
  root CA is off-line and signing CA MUST be
  on-line
• In addition, I believe using a smart card CSP for
  the signing CA would help (should be impossible
  to extract private key into server computer)
• What if hardware failure? Too slow in W2K
  environment?

15
Mapping personal certs into accounts

• A personal certificate must map one-one into an
  account for the sake of authentication
• In some systems, mapping are based upon X.509
  naming attributes from the Subject field
• Example Microsoft issues certificate as CNFull
  Name (account)
• The account is local to the issuing domain

16
Code signing (downloaded software)

• The no of code signing certificates should be
  kept small as the end user must explicitly trust
  each one.
• I believe we need certificates for groups
  like"The ATLAS collaboration
• There MUST be a registered owner of the
  certificate who is responsible for distributing
  it inside the group

17
Storage of private key

• The problem of having the user to manage the
  private key is a treat (user support, key loss or
  compromise)
• Windows offers the CryptoAPI Protected Storage
  which saves private keys (encrypted) in the
  Protected Storage, which again is part of the
  roaming user profile.
• MS apps like IE and Outlook take advantage of
  this, whilstNetscape which is optimised for
  cross-platform saves private keys encrypted into
  the configuration directory
• Thus, user who mix applications or platforms must
  manually import / export private keys via PFX
  files.

18
Smart card readers?

• I have no real experience with this, just some
  opinions which need validation!
• Price is not a problem ( floppy drive)
• Cannot read private key out of card, so cannot
  export private key to another environment
• Currently issues with cross-platform driver /
  application support (ok if only Windows/2000!)
• Should wait to see if it takes off
• Will Internet shopping have impact?
• Intend to evaluate smart cards on a small scale

19
Key length

• Strong encryption is being adopted quickly since
  the relax of US export laws
• There is a common belief that 512 RSA key and 56
  bits DES is no longer safe
• I believe a root CA should have a key length of
  gt 2048 bits given its importance and typical
  lifetime of 3-5 years
• I believe a personal certificate should have a
  key length of gt 1024 bits
• When using encryption, like SSL, do not forget to
  test that older browsers still work with low
  encryption 56-bits DES