Presentation on theme: "Cryptography and Security Services: Mechanisms and Applications Manuel Mogollon M. Mogollon – 0 Chapter 9 Certificates and Public-"— Presentation transcript:
Cryptography and Security Services: Mechanisms and Applications Manuel Mogollon M. Mogollon – 0 Chapter 9 Certificates and Public- Key Infrastructure
1 M. Mogollon – 1 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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
2 M. Mogollon – 2 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Authentication and Confidentiality Recipient Sender’s Public Key Yes/No Verification Session Key Encipher RSA Decipher Decipher DES Encipher DES Session Key Signed Cipher Message Hash SHA-1 Decipher DSS / RSA Hash Signed Cipher Message Digital Signature Deciphered Message Sender’s Private Key Encipher RSA Message Cleartext Message Hash Hash SHA-1 Sender’s Certificate Digital Signature Sender’s Certificate Hash Sender Digital Envelope
3 M. Mogollon – 3 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms What is a Public Key Certificate? 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.
4 M. Mogollon – 4 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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.
5 M. Mogollon – 5 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Certificates Who certifies the Certificate Authority’s public key? Authority’s Public Key Authority’s Private Key Certificate AuthorityAlice’s Computer Alice’s info and public key Alice’s Public Key Alice’s Private Key Random Number Generator Generates Keys Signed certificate Sign Alice Decipher Alice’s public key and info I am Alice. This is my certificate to prove it. It includes my public key. Certificate Authority’s Public Key
6 M. Mogollon – 6 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms X.509 Certificate Certificate version Certificate serial number ID of the algorithm used by the issuer (CA) to sign the certificate CA’s name issuing the certificate Certificate validity period (not before, not after) End-entity’s name Subject public key information Issuer CA’s unique ID (optional) End-entity’s unique ID (optional) Extensions (optional) Authority-Key Identifier Subject-Key Identifier ● Certificate Authority’s Private Key Encipher Hash SHA-1 Digital Signature Subject’s Certificate Information R A D I X 64 ASN1+DERASN1+DER ASN1: Abstract Syntax One Notation DER: Distinguish Encoding Rules (tag, length, value)
7 M. Mogollon – 7 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms RSA Certification The Certificate Authority generates its own secret prime numbers, p ca and q ca, its own secret encryption exponent, Priv CA, and its corresponding public decryption exponent, Pub CA. The Certificate Authority's public numbers, Pub CA and N CA (N CA = p CA. q CA ), are provided to all users in the network. The C A 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 C A to Bob and, since he has Pub CA and N CA, then Bob can obtain Ident Alice and Pub Alice by computing the following:
8 M. Mogollon – 8 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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. * Adams, C., Lloyd S. “Understanding PKI” PKI is about managing certificates and keys during their complete life cycles; as well as the entities involved.*
9 M. Mogollon – 9 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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.
10 M. Mogollon – 10 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Public Key Infrastructure 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. FunctionsElements
11 M. Mogollon – 11 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms PKI Management Model 1. Alice registers with the certificate authority and applies for a certificate. 2. The CA verifies Alice’s identity and issues a certificate. 3. The CA publishes the certificate at a repository site 4. 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. 5. After receiving the message, Bob goes to the repository site to check the authenticity of Alice’s certificate. 6. The repository site gives the status of Alice’s certificate. 7. Bob verifies the message’s integrity using Alice’s public key. Repository Site Certificate Authority / Registration Authority Digital Signature Enciphered Message Alice Bob
13 M. Mogollon – 13 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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.
14 M. Mogollon – 14 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms PKI Management Requirements 1. Conform to the ISO /IEC / ITU – T X.509 standard. 2. Update regularly any key pair without affecting any other key pair. 3. Kept to a minimum the use of confidentiality (encryption) in order to ease regulatory problems. 4. Allow the use of different industry-standard cryptographic algorithms. 5. Allow the generation of key pairs by end-entity, the CA, or the RA. 6. Support the publication of certificates by the end-entity concerned, by an RA or by a CA 7. Support the production of Certificate Revocation Lists (CRLs) by allowing certified end-entities to make requests for the revocation of certificates. 8. Use a variety of "transport" mechanisms, including specifically mail, http, TCP/IP and ftp. 9. The CA is the final authority for certification creation. 10. Support scheduled, non-compromised CA key updates. 11. The CA itself may in some implementations or environments, carry out the functions of an RA. 12. An end-entity requesting a certificate containing a given public key must be able to demonstrate possession of the corresponding private key value.
17 M. Mogollon – 17 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Certificate Life-Cycle Key Generation Certificate Expiration Certificate Revocation Certificate and Certified Key Usage Certificate Suspension Certificate Creation End-Entity Certificate Acceptance Certificate Resumption Certificate Application Key Recovery and Update Certificate Distribution Dissemination
18 M. Mogollon – 18 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Digital Signature Pair Key Signed Document 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 … Document 1 Document 2
20 M. Mogollon – 20 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms End Entity−CA/RA Processes Exchanged 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. End Entity (PKI User) Certificate Authority -1 Registration Authority Registration Form Request 2Registration Form Replay 3Registration Form Submission. 4Registration Setup Request 5Registration Setup Results 6Registration Results 7Certificate Request 8Certificate Response
21 M. Mogollon – 21 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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.
22 M. Mogollon – 22 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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 CRLReposItoryCertIfIcates CRLReposItory End Entity (PKI User) Search, Read Published Certificates
23 M. Mogollon – 23 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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 -1 Certificate Authority -2 Cross- Certification 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”.
24 M. Mogollon – 24 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms CRL Structure CRL version ID of the algorithm used by the issuer (CA) to sign the CRL CA’s name issuing the CRL Date & time this CRL was issued Date & time next CRL will be issued List of revoked certificates (S/N, revocation time) Extensions (optional) Authority Key Identifier Subject Key Identifier ● ● Certificate Authority’s Private Key Encipher Hash SHA-1 Digital Signature Subject’s Certificate Information R A D I X 64 ASN1+DERASN1+DER ASN1: Abstract Syntax One notation DER: Distinguish Encoding Rules (tag, length, value)
25 M. Mogollon – 25 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Hierarchical Trust Model Level n CA3 Level 1 CA1 End Entity A Root CA Level 1 CA2 End Entity B End Entity E End Entity G End Entity D End Entity C End Entity F End Entity H Level n CA4 Level n CA5 Level n CA6 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.
26 M. Mogollon – 26 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Mesh Trust Model All root CAs are cross-certified with each other, or whenever their respective communities need to communicate with each other. Level n CA3 Level 1 CA1 End Entity A Root CA (1) Level 1 CA2 End Entity F Level n CA5 Root CA Cross-Certification Level 1 CA2 End Entity B Level n CA5 Root CA (2)
27 M. Mogollon – 27 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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 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. Level 1 CA1 End Entity A Entrust CA Level 1 CA2 End Entity C Web Model Equifax CA Level 1 CA2 End Entity B VeriSign CA
28 M. Mogollon – 28 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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 Sandra Root CA Bob Root CA Jason Root CA Rick User-Centric Model
29 M. Mogollon – 29 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Comparison of Trust Models CharacteristicsHierarchicalMeshTrust-List (Web) Trusted key(s)“Root” CACA that issued user’s certificate. File of (usually) many trusted CA certificates in each browser. Trust pathsChain of parent-child certificates. Mesh of bi-directional cross certificate pairs. Pre-ordered certificate list. Trust path findingDirectory-Based, comparatively simple. Directory-Based, complex.Minimal; finds individual certificates in LDAP directory. Cross-certificationMay be supported.Basis of PKINo direct capability. Certificate statusCertificate Revocation List. Certificate Revocation ListNone (may add support for On- line Certificate Status Protocol in future).
30 M. Mogollon – 30 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Certificate Path and Validation End Entity A Root CA ● ● ● Issuer: CA1 ● ● ● Subject: End Entity A End Entity Certificate ● ● ● Issuer: CA2 ● ● ●Subject: CA1 Intermediate CA Certificate ● ● ● Issuer: CA Root ● ● ●Subject: CA2 Intermediate CA Certificate ● ● ● Issuer: Root ● ● ● Subject: Root Self Signed Certificate ● ● ● Intermediate CA 1 Intermediate CA 2 Same
31 M. Mogollon – 31 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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,.
32 M. Mogollon – 32 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms 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.
33 M. Mogollon – 33 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms To Probe Further [NEW01] Newman, D. PKI: Build, Buy, or Bust. Networkworld Magazine, December 10, Retrieve on January 6, 2002 from [RFC 2510] Adams, C., Farrell. S. “Internet X.509 Public Key Infrastructure Cer-tificate Management Protocols.” RFC 2510, March [RFC 2511] Myers, M., Adams, C., Solo, D., Kemp, D. "Internet X.509 Certificate Request Message Format." RFC 2511, March [RFC 2527] Chokhani, S., Ford, W. “Internet X.509 Public Key Infrastructure Cer-tificate Policy and Certification Practices Framework.” RFC 2527, March [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 [RFC 2898] Kaliski, B. “PKCS #5: Password-Based Cryptography Specification Version 2.0.” RFC 2898, September [RFC 2315] Kaliski, B. “PKCS #7: Cryptographic Message Syntax Version 1.5.” RFC 2315, March [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 [RFC 2585] Housley, R., Hoffman, P. “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP.” RFC 2587, May [RFC 2587] Boeyen, S., Howes, T., Richard P. “Internet X.509 Public Key Infra-structure LDAPv2 Schema.” RFC 2587, June 1999.
34 M. Mogollon – 34 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms To Probe Further [RFC 2985] Nystrom, M., Kaliski, B. “PKCS #9: Selected Object Classes and At-tribute Types Version 2.0.” RFC 2315, November [RFC 2986] Nystrom, M., Kaliski, B. "PKCS #10: Certification Request Syntax Specification Version 1.7." RFC 2986, November [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 [RFC 3039] Santesson, S., Polk, W., Barzin, P., Nystrom, M. “Internet X.509 Pub-lic Key Infrastructure Qualified Certificates Profile.” RFC 3039, January [RFC 3161] Adams, C., Cain, P., Pinkas, D., Zuccherato, R. “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”. RFC 3161, August [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 [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 [RFC 3447] Jonsson, J., Kaliski B. “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1.” RFC 3447, February [RFC 3494] Zeilenga, K. “Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status.” RFC 3494, March [WH99] Wing, P. O’Higgins, B. Using Public-Key Infrastructure for Security and Risk Management. IIEE Communications Magazine September 1999.
35 M. Mogollon – 35 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Value of Digital Signatures (from VeriSign)
36 M. Mogollon – 36 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms Value of Digital Signatures (From VeriSign)
37 M. Mogollon – 37 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms PKI-Enable Application List (From PKI Forum)
38 M. Mogollon – 38 CertificatesPKILife-cycleProcessesTrust ModelsAlgorithms PKI-Enable Application List (From PKI Forum)