1. 1 Public Key Infrastructure Dr. Rocky K. C. Chang 25 February, 2002

2. 2 The problem Problem: How do principals learn each other’s public keys for a number of public-key based protocols, such as IPSec, IKE, PGP, S/MIME, or SSL? Some naïve solutions: –Configure each principal with the public key of every other principal (scalability problem). –Publish public keys in Web sites or newspapers (authentication and scalability problems). One accepted solution is through trusted intermediaries known as certification authorities (CAs).

3. 3 The problem CAs digitally sign data structures known as certificates that state the mapping between names and public keys. –A typical certificate contains a serial number the name of the principal being certified the public key of the principal the name of the certification authority valid duration of the certificate a digital signature

4. 4 Digital signatures Bob’s certificate without signature HashDigest Bob’ private key Bob’s certificate without signature Signature Sent to Alice From Bob Bob’s certificate without signature Signature Bob’ public key HashDigest Compare

5. 5 An example If Alice’s certification is issued by CA1 and Bob knows CA1’s public key, he can securely obtain Alice’s public key from Alice’s certificate. In general, Bob may not know the public key of Alice’s CA (he knows CA1’s public key). Therefore, it is necessary for Bob to obtain a chain of certificates (also known as certification path), e.g., –[CA2’s key is P2] signed by CA1 –[CA3’s key is P3] signed by CA2 –[Alice’s key is P4] signed by CA3

6. 6 Certificate revocation For various reasons (e.g., employment termination), a certificate may no longer be valid before the expiration date. –The solution to this problem is to define a Certification Revocation List (CRL), which contains serial numbers that should not be honored. A CA periodically issues a signed CRL available in a public repository. –An advantage of this approach is that CRLs may be distributed by exactly the same means as certificates. Therefore, a certificate is valid if it has a valid CA signature, has not expired, and is not listed in the CA’s most recent CRL.

7. 7 Authentication using certification Bob is an application that needs to authenticate the user Alice. –Bob needs Alice’s certificate (or certification path) and a recent CRL (or CRLs for the certification path). –Bob can obtain them from directory service (X.500) or from Alice. –If the certificate(s) is (are) valid, Bob obtains Alice’s public key from the certificate(s). –Then, Bob will go through an authentication handshake whereby Alice proves she knows the private key that corresponds to the public key listed in her certificate.

8. 8 Public key infrastructure A PKI is defined as the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke certificates based on public-key cryptography. A PKI consists of five types of components: –Certification authorities (CAs) –Registration authorities (RAs) –Certificate holders that are issued certificates and can sign digital documents and encrypt documents. –Clients that validate digital signatures and their certification paths from a known public key of a trusted CA. –Repositories that store and make available certificates and CRLs.

9. 9 Public key infrastructure

10. 10 Functions of a PKI Registration: A subject first makes itself known to a CA. Initialization: A subject get the CA’s public key. Certification: A CA issues a certification Key pair recovery: User’s private key may be backup. Key generation: Generate the private-public key pair. Key update –Key expiry: A graceful transition to a new key. –Key compromise: A not so graceful transition to a new key. Cross-certification: One direction or both directions Revocation: Cause a certificate invalid. Certificate revocation notice distribution and publication

11. 11 X.509 PKI (PKIX) PKIX defines a profile to facilitate the use of X.509 certificates within Internet application (RFC 2459). –It specifically profiles the X.509 v3 certificate and X.509 v2 CRL. –This profile does not assume the deployment of an X.500 directory system. –The v3 certificate format extends the v2 format by adding provision for additional extension fields. –The extensions provide methods for associating additional attributes with users or public keys and for managing the certification hierarchy, e.g., The subject alternative names extension allows additional identities to be bound to the subject of the certificate, such as an Internet electronic mail address, a DNS name, an IP address, and a URI.

12. 12 X.509 v3 certificate Version Serial number Signature: Must be the same as the Signature Algorithm. Issuer Name Validity: Not before and not after Subject Subject Public Key Info: Carry the public key and identify the algorithm with which the key is used. Issuer Unique ID and Subject Unique ID (optional) Extensions Signature Algorithm: Algorithm for generating the sig. Signature value

13. 13 A single-CA model A pure single-CA model: consist of a single CA for the world. Problems: –Almost impossible to find such a CA and other nontechnical issues. –It is inconvenient, insecure, and expensive to obtain a certificate. It is difficult for the CA to authenticate the user requesting the certificate. –It is not scalable if CA’s key is changed. A single-CA model with multiple registration authorities (RAs) trusted by the CA. –The RAs authenticate users and users’ keys, and sends a signed request to the CA. –CA is still responsible for issuing certificates.

14. 14 Configured + delegated CAs model This model, implemented in current browsers, configures keys of CAs (configured CAs), but the CAs can sign certificates authorizing other CAs to grant certificates (delegated CAs). CA Configured CAs Delegated CAs

15. 15 A strict hierarchy There is only one configured CA (root CA). The CAs are related in a strict hierarchy and a hierarchical namespace is assumed. –A CA is trusted only to certify name-to-key mappings for the names in the subtree of the namespace (name subordination). –E.g, a CA on the premise polyu.edu.hk is entrusted for certificates with names of the form foo@polyu.edu.hk. –Therefore, Alice can authenticate to Bob by sending him all the certificates from the root down to herself. But it turns out that this hierarchy is too rigid for a widespread deployment (experienced by PEM).

16. 16 A strict hierarchy User CA PCA1PCA2 IPRA PCA3 CA IPRA=Internet Policy Registration Authority (root) PCAn=policy certification authority CA=certification authority

17. 17 A less restrictive hierarchy This model also assumes a hierarchical name space and the name subordination rule. Each node in the namespace is represented by a CA. It contains three types of certificates: –Down: a parent certifies the key of the child –Up: a child certifies the key of the parent –Cross: any node certifies the key of any other E.g., SunMIT WestEastJeff RadiaSteve

18. 18 A less restrictive hierarchy If Radia.East.Sun wants to discover Steve.East.Sun’s key, –She starts with her own key and finds the up certificate to the parent East.Sun. –She notes that she has now reached an ancestor of Steve.East.Sun’s name, and proceeds downward from there. If Radia.East.Sun wants to discover Jeff.MIT’s key, –She continues on from East.Sun, following the up certificate to the parent (Sun), and then finding the cross-certificate to MIT, from there down to the name Jeff.MIT.

19. 19 The current status A Federal PKI is currently under development in the US (http://csrc.ncsl.nist.gov/pki/program/welcome.html). HK Government’s Electronic Transactions Ordinance stipulates the Postmaster General to be the CA. PMI (Privilege Management Infrastructure) –Instead of binding public keys to identities, PMI binds attributes to identities. –Support rule-based and role-based access control decisions –Attribute certificates (AC) vs. public key certificates (PKC)

20. 20 Acknowledgements The notes are based on –R. Housley, W. Ford, W. Polk, D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” RFC 2459, January 1999. –R. Perlman, “An Overview of PKI Trust Models,” IEEE Network Magazine, pp. 38-43, Nov/Dec, 1999.