Chapter 9

1. Chapter 9 Certificates and Public-Key Infrastructure

2. Session 7 – Contents • Certificates • X.509 Basic Certificate Fields • RSA Certification • Public Key Infrastructure • PKI Management Components • CA Trust Models • Encryption Algorithms Supported In PKI

3. Session Key Session Key Cleartext Message Digital Envelope Digital Envelope Digital Signature Hash SHA-1 Hash SHA-1 Encipher RSA Decipher DSS / RSA Verification Authentication and Confidentiality Encipher RSA Sender’s Private Key Hash Encipher DES Signed Cipher Message Sender’s Certificate Sender Message Recipient Decipher Sender’s Public Key Sender’s Certificate Digital Signature Decipher DES Signed Cipher Message Deciphered Message Hash Hash Yes/No

4. public key certificate / n.Information provided by an issuing organization, a Certificate Authority, that has a copy of the end-user’s public key signed by the Certificate Authority, the hash value of the end-user’s public key, the name of the key’s owner, and a digital signature of the Certificate Authority. Certificates are used to identify the owner of a particular public key. What is a Public Key Certificate?

5. Certificates • Secrecy of the public key is not required. • Authenticity of the public key is necessary to avoid spoofing and playback attacks. • A public key can be authenticated (signed by a Certificate Authority). • A user can send his public key with a certificate which can then be used to verify the authenticity of the public key. • Certificates may also include additional user information. • Any user with access to the public key of the CA can recover the user public key that was certified. • No party other than the CA can modify the certificate without being detected. Certificates provide a safe method of distributing public keys via electronic media.

6. Certificates Alice’s Computer Certificate Authority Random Number Generator Alice’s info and public key Authority’s Public Key Alice’s Public Key GeneratesKeys Sign Authority’s Private Key Alice’s Private Key Signed certificate Certificate Authority’sPublic Key Decipher Alice I am Alice. This is my certificate to prove it. It includes my public key. Alice’s public key and info Who certifies the Certificate Authority’s public key?

7. X.509 Certificate ASN1 + DER RADIX 64 Subject’s Certificate Information Hash SHA-1 Digital Signature Encipher Certificate Authority’s Private Key ASN1: Abstract Syntax One NotationDER: Distinguish Encoding Rules (tag, length, value)

8. RSA Certification • The Certificate Authority generates its own secret prime numbers, pca and qca, its own secret encryption exponent, PrivCA, and its corresponding public decryption exponent, PubCA. • The Certificate Authority's public numbers, PubCA andNCA (NCA = pCA . qCA), are provided to all users in the network. • The CA certifies Alice's public key and identification number by computing the certificate public number of Alice: • Upon receiving the certificate, Alice verifies the certificate by checking: • When Alice wants to establish a secure communication with Bob, she sends her certificate CA to Bob and, since he has PubCA and NCA, then Bob can obtain Ident Alice and Pub Alice by computing the following:

9. What is a PKI? public-key infrastructure / n. (abbr. PKI)(1) a mechanism for (a) establishing trust according to a defined trust model; (b) making entities uniquely identifiable within a domain; (c) distributing information regarding the validity of the binding between a particular key pair and an entity.* (2) An authentication mechanism. PKI is about managing certificates and keys during their complete life cycles; as well as the entities involved.* * Adams, C., Lloyd S. “Understanding PKI”

10. PKI • When public-key is used, it is necessary to have a comprehensive system that efficiently delivers security services such as confidentiality, access control, data integrity, authentication, and non-repudiation in a cohesive manner. • That system is called Public Key Infrastructure or PKI. • PKI enables organizations to set-up and define secure networks in a consistent manner across a wide variety of applications.

11. Manages the complete life cycle of keys and certificates. Provides key backup and recovery. Updates automatic key pairs and certificates Manages key histories Supports cross-certification A Certificate Authority A certificate repository A certificate revocation system Key backup recovery Support for non-repudiation of digital signatures Automatic update of key pairs and certificates Management of key histories Support for cross certification Open standards and support for legacy applications. Public Key Infrastructure Functions Elements

12. 6 5 1 2 3 4 7 PKI Management Model Certificate Authority / Registration Authority • Alice registers with the certificate authority and applies for a certificate. • The CA verifies Alice’s identity and issues a certificate. • The CA publishes the certificate at a repository site • Alice sends her enciphered message and certificate to Bob. The message was signed with Alice’s private key to ensure authenticity, message integrity, and non-repudiation. • After receiving the message, Bob goes to the repository site to check the authenticity of Alice’s certificate. • The repository site gives the status of Alice’s certificate. • Bob verifies the message’s integrity using Alice’s public key. Repository Site Enciphered Message Digital Signature Bob Alice

13. PKI Management Entities Certificate Authority -2 Publish Certificate Publish CRL Out-of-band publication Certificate Authority -1 Certificate Revocation List (CRL) Issuer ReposItory S I T e PublishCertificate Registration Authority PKI Users Search, Read Published Certificates End-Entity (PKI User) Out-of-band loading

14. PKI Management Model • End-Entities (PKI Users) • An end-entity is a user of PKI certificates and/or an end-user system that is the subject of a certificate. • Certification Authority • The identity and public key of each PKI user can be authenticated (signed) by a Certificate Authority. • A CA can issue several kinds of certificates including: User (end-entity) certificates, CA certificate (a certificate for itself or for another CA), and cross certificates (an authentication process across security domains). • Registration Authority • An RA is an optional system to which a CA can delegate certain management functions. • Functions will vary from case to case, but they may include the end-entity verification process, personal authentication, token distribution, revocation reporting, name assignment, key generation, archival of key pairs, etc. • RAs do not issue certificates or CRLs. • Repository Site • The repository site is a system or collection of distributed systems that stores certificates and Certificate Revocation Lists (CRLs) and serves as a means of distributing these certificates and CRLs to end-entities. • Certificates are stored at a repository site so that applications can retrieve them on behalf of a user.

15. PKI Management Requirements • Conform to the ISO /IEC 9594 -8 / ITU – T X.509 standard. • Update regularly any key pair without affecting any other key pair. • Kept to a minimum the use of confidentiality (encryption) in order to ease regulatory problems. • Allow the use of different industry-standard cryptographic algorithms. • Allow the generation of key pairs by end-entity, the CA, or the RA. • Support the publication of certificates by the end-entity concerned, by an RA or by a CA • Support the production of Certificate Revocation Lists (CRLs) by allowing certified end-entities to make requests for the revocation of certificates. • Use a variety of "transport" mechanisms, including specifically mail, http, TCP/IP and ftp. • The CA is the final authority for certification creation. • Support scheduled, non-compromised CA key updates. • The CA itself may in some implementations or environments, carry out the functions of an RA. • An end-entity requesting a certificate containing a given public key must be able to demonstrate possession of the corresponding private key value.

16. Initialization Key pair generation Registration Certificate creation Key & certificate distribution Certificate dissemination Key backup Cancellation Certificate expiration Certificate revocation Key history Key archive Certificate Life-Cycle • Issued • Certificate retrieval • Certificate validation • Key recovery • Key update • Certificate update

17. Key Expiration Key Update Key Lifecycle Management Initialization Key Generation Certificate Validation CertificateIssuance or Key Usage

18. Certificate Life-Cycle Key Generation Certificate Creation Certificate Application Certificate Distribution Dissemination Key Recovery and Update Certificate and Certified Key Usage End-Entity Certificate Acceptance Certificate Expiration Certificate Revocation Certificate Suspension Certificate Resumption

19. Digital Signature 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 …. 2021 Pair Key Document 1 Signed Document Document 2 Public Key in Certificate Certificate Renewed Certificate (s) Certificate Policy Example:The pair key lifetime is 5 years.The digital signature (public key) is valid for 10 years.A certificate must be renewed every year.

20. PKI Management Operations PKI Management Entities CertIfIcates ReposItory & C R L Certificate Authority -2 Publish Certificate • Cross-certification request • Cross-certificate update Publish CRL Out-of-band publication Certificate Authority -1 Certificate Revocation List (CRL) Issuer PublishCertificate Registration Authority 5 4 1, 3 7 8 2, 6 PKI Users 1 Registration Form Request2 Registration Form Replay3 Registration Form Submission.4 Registration Setup Request5 Registration Setup Results6 Registration Results7 Certificate Request8 Certificate Response • Initialization • Registration • Certification • Issuance • Key Pair Recovery and Update • Certificate Renewal and update • Certificate Revocation Request Search, Read End-Entity (PKI User) Published Certificates Out-of-band loading CRL: Certificate Revocation List

21. End Entity−CA/RA Processes Exchanged 4 Certificate Authority -1 • Certificate Creation • Only the CA can generate certificates. • Certificate and Key-pair Dissemination • Certificate is sent to the end-entity using physical delivery, off-line distribution. • Certificate is sent to an end-entity application (S/MIME), online distribution. • Key-pair is sent to the end-entity, if the key-pair was generated by the CA. • Key Backup (Optional) • Key pair is stored by a trusted third key. • Registration • Identity of the end-entity is established and verified. • Key Pair Generation • Generation of public key pair, either by the end-entity, the RA, or by the CA. In some environments, a trusted-party may generate the key pair. • If the key-pair is going to be used for non-repudiation, then it should be generated by the end-entity, the owner of the public-key pair. 5 Registration Authority 1 2 3 6 7 8 End Entity (PKI User) 1 1 Registration Form Request2 Registration Form Replay3 Registration Form Submission.4 Registration Setup Request5 Registration Setup Results6 Registration Results7 Certificate Request8 Certificate Response

22. End Entity−CA/RA Processes Exchanged • Key Pair Recovery • Key pair recovery allows end-entities to recover key material from a CA or RA when they lose key material or forget passwords, or when the devices where key material are stored get corrupted. • Key pair backup and recovery refers to the encrypting key pair; the organization can recover the end-entity private key if the key is lost, so loss of a private key doesn’t mean loss of valuable data. • The backup and recovery of signing keys should not be allowed because it destroys the basic requirement of non-repudiation. • Key Pair Update • The key pair update process supports the regular update of every key pair. Key pairs need to be updated regularly (i.e., replaced with a new key pair), and a new certificate should be generated for the new key pair. • Certificate Renewal and Update • Certificates are assigned a valid time period. When a certificate expires, it can be renewed or updated, Renewal means that the public key and information remain the same and a new certificate is issued. Update means that a new public key pair and information are generated and a new certificate is issued.

23. End Entity – Repository Processes Exchanged • Certification Retrieval • Certification retrieval is the process by which an end-entity retrieves an end-entity certificate to either (1) encrypt data destined for another end-entity using the public key included in the certificate, or (2) verify a digital signature received from another entity. • Certificate Validation • The certificate was issued by a trusted CA. The certificate needs to be validated. • The certificate has not been changed. • The certificate has not expired. • The certificate has not been revoked. The CRL should be check. CertIfIcates CRL ReposItory Search, Read Published Certificates End Entity (PKI User)

24. CA1 – CA2 Processes Exchanged • Cross Certification • “Alice” has been certified by CA1 and “Bob” has been certified by CA2. • Alice trusts only the certificates signed by CA1, and Bob trusts only the certificates signed by CA2. • It is not possible for Alice to certify Bob because Alice and Bob are in different domains. • If CA1 cross-certifies CA2, Alice can extend her trust to the end-entities certified by CA2, including Bob. Certificate Authority -2 Cross-Certification Certificate Authority -1 • Inter-domain cross-certificate • When the subject and issuer CAs belong to different administrative domains. • Intra-domain cross-certificate • When the CAs belong to the same domain. • Cross certification controls are possible • Trust can be extended to certain groups within an organization within another CA; e.g., organization “A” may set cross certification so their customer account managers can only accept certificates from the purchasing department of organization “B”.

25. CRL Structure ASN1 + DER RADIX 64 Subject’s Certificate Information Hash SHA-1 Digital Signature Encipher Certificate Authority’s Private Key ASN1: Abstract Syntax One notationDER: Distinguish Encoding Rules (tag, length, value)

26. Hierarchical Trust Model Root CA Level 1 CA1 Level 1 CA2 Level n CA6 Level n CA3 Level n CA4 Level n CA5 End Entity A End Entity B End Entity C End Entity D End Entity E End Entity F End Entity G End Entity H Advantage: Relatively simple to implement Disadvantage: No cross certification between CAs. If end-entity A wants to certify end-entity F, it needs to go all the way to CA5.

27. Mesh Trust Model Cross-Certification • All root CAs are cross-certified with each other, or whenever their respective communities need to communicate with each other. Root CA (1) Root CA Root CA (2) Level 1 CA2 Level 1 CA1 Level 1 CA2 Level n CA3 Level n CA5 Level n CA5 End Entity A End Entity F End Entity B

28. Web Trust Model • The Web trust model is the most widely used trust model. • There are only two leading browsers in the market. • Certificates are included in the initial web browser distribution. • Web browsers are distributed with more than 100 CA public keys pre-installed. • Browsers use pre-installed certificates to sign, verify, encrypt and decrypt S/MIME email messages and to establish Secure Socket Layer (SSL) sessions. • It is a very difficult task for an end-user to manage the numerous “trusted CA certificates” installed in a browser. • There is no practical way to prevent either users, or others with access to their workstations, from making unauthorized alterations to the list. • There is no practical mechanism to revoke certificates. • If Netscape or Microsoft makes a mistake and installs a “bad” CA, there is no way to revoke that certificate from the millions of web browsers in use. Entrust CA VeriSign CA Equifax CA Level 1 CA1 Level 1 CA2 Level 1 CA2 End Entity A End Entity B End Entity C Web Model

29. User-Centric Model • Used by Pretty Good Privacy (PGP) in a decentralized environment. • Any user can act as a certifying authority and validate another user’s public key certificate. • Not all certificates generated by users are valid certificates. • A certificate generated by Alice, who is acting as CA, may not be valid to other users because they know that Alice cannot be trusted as a CA. • Each user is directly responsible for deciding which certificates to accept and which ones to reject. Root CA Alice Root CA Bob Root CA Jason Root CA Sandra Root CA Rick User-Centric Model

30. Comparison of Trust Models

31. Certificate Path and Validation Same Self Signed Certificate Issuer: Root Subject: Root ● ● ● ● ● ● ● ● ● Root CA Intermediate CA Certificate Issuer: CA Root Intermediate CA 2 ● ● ● ● ● ● Subject: CA2 ● ● ● Intermediate CA Certificate Issuer: CA2 Intermediate CA 1 ● ● ● ● ● ● Subject: CA1 ● ● ● End Entity Certificate Issuer: CA1 Subject: End Entity A End Entity A ● ● ● ● ● ● ● ● ●

32. Encryption Algorithms Supported in PKI • Signature Algorithms • Mandatory Algorithm: DSA/SHA-1 • Other Algorithms: HMAC/SHA-1, RSA/MD5 and ECDSA/ECDH • Public Key (Asymmetric) Algorithms • Mandatory Algorithm: Diffie-Hellman • Other Algorithms: RSA, ECDH. • Symmetric Algorithms • Mandatory Algorithm: 3DES and AES in CBC mode. • Other Algorithms: RC5, Cast 128,.

33. Models for PKI Deployment • In-Sourcing • Gives an organization full control of a PKI implementation by utilizing its own resources, including personnel and hardware, and/or hiring external resources. • Allows organizations to issue and manage certificates in a consistent manner. • Out-Sourcing • Takes the PKI management burden from the organization and gives control of the PKI operation to an external party. • Factors in Choosing PKI Deployment Model • Total cost of ownership − software, hardware, personnel, facilities, training, legal fees, etc. • Degree of control that the organization wants to maintain during the PKI operation. • Perceived sense of trust that customers will have from knowing that the PKI operations are out-sourced or in-sourced. • Response time associated with PKI related services. • Level of help desk support. • Flexibility and scalability. • Ability and willingness of the vendor to evolve to meet the future needs of the organization. • Disaster planning and recovery.

34. To Probe Further • [NEW01] Newman, D. PKI: Build, Buy, or Bust. Networkworld Magazine, December 10, 2001. Retrieve on January 6, 2002 from • http://www.nwfusion.com/research/2001/1210feat.html • [RFC 2510] Adams, C., Farrell. S. “Internet X.509 Public Key Infrastructure Cer-tificate Management Protocols.” RFC 2510, March 1999. • [RFC 2511] Myers, M., Adams, C., Solo, D., Kemp, D. "Internet X.509 Certificate Request Message Format." RFC 2511, March 1999. • [RFC 2527] Chokhani, S., Ford, W. “Internet X.509 Public Key Infrastructure Cer-tificate Policy and Certification Practices Framework.” RFC 2527, March 1999. • [RFC 2528] Housley, R., Polk, W. “Internet X.509 Public Key Infrastructure Repre-sentation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key In-frastructure Certificates.” RFC 2528, March 1999. • [RFC 2898] Kaliski, B. “PKCS #5: Password-Based Cryptography Specification Version 2.0.” RFC 2898, September 2000. • [RFC 2315] Kaliski, B. “PKCS #7: Cryptographic Message Syntax Version 1.5.” RFC 2315, March 1998. • [RFC 2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C. “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP.” RFC 2560, June 1999. • [RFC 2585] Housley, R., Hoffman, P. “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.” RFC 2587, May 1999. • [RFC 2587] Boeyen, S., Howes, T., Richard P. “Internet X.509 Public Key Infra-structure LDAPv2 Schema.” RFC 2587, June 1999.

35. To Probe Further • [RFC 2985] Nystrom, M., Kaliski, B. “PKCS #9: Selected Object Classes and At-tribute Types Version 2.0.” RFC 2315, November 2000. • [RFC 2986] Nystrom, M., Kaliski, B. "PKCS #10: Certification Request Syntax Specification Version 1.7." RFC 2986, November 2000. • [RFC 3029] Adams, C., Sylvester, P., Zolotarev, M., Zuccherato, R. “Internet X.509 Public Key Infrastructure Data Validation and Certification Server Proto-cols.” RFC 3029, February 2001. • [RFC 3039] Santesson, S., Polk, W., Barzin, P., Nystrom, M. “Internet X.509 Pub-lic Key Infrastructure Qualified Certificates Profile.” RFC 3039, January 2001. • [RFC 3161] Adams, C., Cain, P., Pinkas, D., Zuccherato, R. “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”. RFC 3161, August 2001. • [RFC 3279] Bassham, L., Polk, W., Housley, R. “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” Rfc 3279, April 2002. • [RFC 3280] Housley, R., Polk, W., Ford, W., Solo, D. “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” RFC 3280, April 2002. • [RFC 3447] Jonsson, J., Kaliski B. “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1.” RFC 3447, February 2003. • [RFC 3494] Zeilenga, K. “Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status.” RFC 3494, March 2003. • [WH99] Wing, P. O’Higgins, B. Using Public-Key Infrastructure for Security and Risk Management. IIEE Communications Magazine September 1999.

36. Value of Digital Signatures (from VeriSign)

37. Value of Digital Signatures (From VeriSign)

38. PKI-Enable Application List(From PKI Forum)

39. PKI-Enable Application List(From PKI Forum)