Cryptography - Lecture 20 - Key Management and Certificates

1. Key Management

• all cryptographic systems have the problem of how to securely and reliably distribute the keys used
• in many cases, failures in a secure system are due not to breaking the algorithm, but to breaking the key distribution scheme
• ideally the distribution protocol should be formally verified, recent advances make this more achievable
• have a range of possible key distribution techniques

2. Physical Delivery

• by secure courier
• eg. code-books used submarines,
• one-time pads used by diplomatic missions,
• registration name and password for computers

3. Authentication Key Server

• have an on-line server trusted by all clients
• server has a unique secret key shared with each client
• server negotiates keys on behalf of clients
• use private key encryption
• eg Kerberos (later)

4. Public Notary or Certification Authority

• have an off-line server trusted by all clients
• server has a well known public key
• server signs public key certificates for each client
• uses public key encryption
• eg SPX
• will consider this first

5. Public Key Certificates

• public key management generally involves the use of public key certificates
• these bind an identity to a public key
• usually with other info such as period of validity, rights of use etc
• with all contents signed by a trusted Public Notary or Certification Authority (CA)
• assumed that both parties either already know, or can securely obtain and verify, the public key of the CA to verify the certificate

6. X.509 - Directory Authentication Service

• part of CCITT X.500 standards for directory services
• X.509 defines framework for authentication services
• directory may store public-key certificates
• also defines authentication protocols using these certificates
• uses public-key cryptography and digital signatures
• algorithms not standardised but RSA is recommended

7. X.509 Certificate

• issued by a Certification Authority (CA)
• each certificate contains:
  • version (1, 2, or 3)
  • serial number (unique within CA) identifying certificate
  • signature algorithm identifier
  • issuer X.500 name (CA)
  • period of validity (from - to dates)
  • subject X.500 name (name of owner)
  • subject public-key info (algorithm, parameters, key)
  • issuer unique identifier (v2+)
  • subject unique identifier (v2+)
  • extension fields (v3)
  • signature (of hash of all fields in certificate)
• notation: CA<<User>> means CA has signed certificate details for User

8. Certificate Extensions

• has been recognised that additional information is needed in a certificate
• eg. email address/URL, policy details, usage constraints etc
• rather than explicitly naming new fields defined a general extension method
• see these in use in secure email application and SSL for example

9. Certificate Properties

• any user with access to CA can get any certificate from it
• only the CA can modify a certificate
• because they cannot be forged, certificates can be placed in a public directory

10. CA Hierarchy

• if both users share a common CA then are assumed to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to validate other CA's
• each CA has certificates for clients (forward) and parent (backward)
• each client trusts parents certificates
• enable verification of any certificate from one CA by users of all other CAs in hierarchy

11. CA Hierarchy Use

• A acquires B certificate following chain:
  • X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
  • B acquires A certificate following chain:
  • Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>

12. CA's Now

• currently see single level CA's mostly used
• the most used are those whose CA Certificates are in Explorer/Netscape
• Verisign the most used
• they issue Digital IDs which are X.509 certificates for users/businesses
• have several classes of certificates:

  Class	Identity Checks	Usage
  Class 1	automated name/email check	web browsing/email
  Class 2	+ automated enrollment/address check	inter/intranet email,subscriptions,s/w validate
  Class 3	+ ID documents sighted	e-banking/service access etc

• see my example Verisign certificate (as a text dump, expired)
• also seeing govt (eg ATO) and business (eg Telstra) issuing certificates for on-line service access
• the University (both UNSW at Kensigton and ADFA) is creating certificates for its secure web services

13. Authentication Procedures

• X.509 includes three alternative authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication

14. One-Way Authentication

• 1 message ( A->B) used to establish
  • identity of A and that messages is from A
  • message intended for B
  • integrity & originality of message
• message must include timestamp, nonce, B's identity and is signed by A

15. Two-Way Authentication

• 2 messages (A->B, B->A) which also establishes
  • identity of B and that replay is from B
  • reply intended for A
  • integrity & originality of reply
• replay includes original nonce from A, also timestamp and nonce from B

16. Three-Way Authentication

• 3 messages (A->B, B->A, A->B) which enables
  • above authentication without syncronised clocks
• has replay from A back to B containing signed copy of nonce from B
• means that timestamps need not be checked or relied upon

17. Summary

• key managements issues in general
• X.509 certificates and CA's