Cryptography - Lecture 20 - Key Management and Certificates

Objectives

Preliminary Reading

Lecture Content

Key Management

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

     This is one of the most critical areas in security systems - on many occasions systems have been broken, not because of a poor encryption algorithm, but because of poor key selection or management. It is absolutely critical to get this right!

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

     The simplest - but only applicable when the is personal contact between the recipient and the key issuer. Nonetheless, no matter what other mechanism is used - at some point a physical key transfer is going to be required to bootstrap the system. Examples include issue of logins/passwords, passport applications, and soon digital certificate applications (cf Australia Post).

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)

     Here use a trusted intermediary, whom all parties trust, to mediate the establishment of secure communications between them. Must trust intermediary not to abuse the knowledge of all session keys.

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

     Here use a trusted notary to certify the identity of users and their public keys. With this model, the notary does not have access to the encrypted communications, hence less trust is required (but public key crypto is needed, see later).

Public Key Certificates

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

     If using public key techniques, then the usual approach is to use the services of a CA, which is trusted only to verify that a public key belongs to some named identity. Note that the CA does not (necessary) know the private key, hence can't decrypt or forge messages, unlike a private key server. So the level of trust in a CA is lower. Mind you - governments seem to want to generate private keys on user's behalf.....

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

     X.509 is the Internationaly accepted standard for how to construct a public key certificate, and is becoming widely used. It has gone through several versions. See Stallings section 11.2 for discussion.

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

     The X.509 certificate is the heart of the standard. There are 3 versions, with successively more info in the certificate - must be v2 if either unique ident field exists, must be v3 if any extensions are used.

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

     The extension field provides a general mechanism for adding new info into a certificate, sometimes standardised, sometimes simply de facto. Of particular interest is the extensions to do with trust, and the policies used in creating certificates. Currently these are just free form text, and hence cannot be automatically processed. There is a lot of debate, and not much agreement on how better to do this - but "trust" IS the key issue here.

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

     All very easy is both parties use the same CA. If not, then there has to be some means to form a chain of certifications between the CA's used by the two parties. And that raises issues about whether the CA's are equivalent, whether they used the same policies to generate their certificates, and how much you're going to trust a CA at some remove from your own. These are all open issues.

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

     This illustration shows the chain of certificates required for A and B to verify each other's certificates. Note the ordering used for each.

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

     Whilst X.509 supposedly supports hierarchies of CA's, given the issues associated with trusting a chain of certifications, in practise we currently see only single-level CA's - where users share one or more CA's whose public keys they know or both learn and verify somehow. The most common are the ones whose CA certificates are distributed in every copy of Explorer/Netscape. Of these, Verisign have brought out most of the rest! Note the different classes of certificates Verisgn issue (at successively higher charges). There is an equivalent set of classes for business users. Seeing increasing use of such certificates for online services from gvt, business & the Uni.

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

     The X.509 standard specifies the authentication protocols that can be used when obtaining and using certificates. 1-way for unidirectional messages (like email), 2-way for interactive sessions when timestamps are used, 3-way for interactive sessions with no need for timestamps (and hence synchronised clocks).

10. 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
11. 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
12. 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

Summary

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

Additional References