session_07_certificates_and_pki_100508

session_07_certificates_and_pki_100508 - Certificates and...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Certificates and PKI Cryptography and Network Security TECH 6350 Session 7 Certificates and PublicKey Infrastructure Manuel Mogollon [email protected] Graduate School of Management Information Assurance University of Dallas 0 Certificates and PKI 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 Certificates PKI Life-cycle Processes Trust Models Algorithms 1 M. Mogollon – 01/08 - 1 • In public-key encryption, the secrecy of the public key is not required, but the authenticity of the public key is necessary to guarantee its integrity and to avoid spoofing and playback attacks. A user’s public key can be authenticated (signed) by a certificate authority that verifies that a public key belongs to a specific user. In this chapter, digital certificates, which are used to validate public keys, and certificate authorities are discussed. • When public key is used, it is necessary to have a comprehensive system that provides publickey encryption and digital signature services to ensure confidentiality, access control, data integrity, authentication, and non-repudiation. That system, Public-Key Infrastructure or PKI, is also discussed in this session. 1 Certificates and PKI Authentication and Confidentiality Hash Encipher Digital Envelope Encipher Cleartext Message Hash Sender’s Certificate Message RSA Digital Signature RSA SHA-1 Encipher Session Key Sender’s Private Key Signed Cipher Message DES Sender Recipient Digital Envelope Decipher Decipher Sender’s Public Key DSS / RSA Digital Signature Hash Hash SHA-1 Hash Verification Certificates PKI Session Key Sender’s Certificate Decipher DES Signed Cipher Message Deciphered Message Yes/No Life-cycle Processes Trust Models Algorithms 2 M. Mogollon – 01/08 - 2 • Some protocols rely on cryptography and digital certificates to ensure message confidentiality and authentication. Whenever end-users, and Certificate Authorities are exchanging information, either to get a certificate, to place orders, or to request payment authorization, the information is secured using digital signatures, digital envelopes and encryption. • The following steps describe the authentication and confidentiality: • The sender generates a random session. The session key is a one-time secret key used to encipher the message by encrypting it with a symmetric encryption algorithm. • The message is hashed using SHA-1 and signed using RSA with the sender’s private key creating a digital signature. • The cleartext message is concatenated with the digital signature and the sender’s certificate. • The cleartext message, digital signatures, and certificate are enciphered with a symmetric algorithm (AES) using the one-time secret key generated previously by the sender. • The one-time session key is enciphered with RSA using the recipient’s public key. The enciphered one-time session key is called a Digital Envelope. • The enciphered session key is concatenated with the signed cipher message. • To decipher and authenticate the message, the receiver performs the above steps in reverse. • As described in previous chapters, digital certificates are digital documents attesting to the binding of a public key to an individual or entity. The Certificate Authority provides certificates to all users to bind a public key to those individuals or organizations. When a CA grants these unique certificates, it is in fact, certifying that those individuals and organizations are who they claim to be. 2 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 3 M. Mogollon – 01/08 - 3 3 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 4 M. Mogollon – 01/08 - 4 • When Alice needs to use Bob’s public key generally she needs to be confidence that the associated private key is owned by Bob, so he will be the only one deciphering the message. • The secrecy of the public key is not required, but the authenticity of the public key is necessary to guarantee its integrity and to avoid spoofing and playback attacks. If an attacker could replace Bob’s public key with his own public key, then the secret information intended for Bob would be available to the attacker. The attacker could receive the information, decipher it, and send it on to the Bob. Or, a spoofer could intercept the communications between Alice and Bob make them to believe that they are talking to each other, when, in reality, they are taking to the intruder. • The confidence that the public key is authentic is obtained through the use of Public-Key Certificates, which bind the public key values to subjects. The binding is asserted by having a trusted Certificate Authority (CA) digitally sign each certificate. The Certificate Authority authenticates, signs, the public key of each user. • It is also possible to make the certificate a function not only of the user's public key, but, also, of an identification block. The block identifies, for example, the user's computer serial number, the user's telephone number, the network, the certificate number, the expiration date of the certificate, and certain authorizations. The certificate is created by linking the public key and the identification block. When the two users establish communications, their certificates are exchanged, thereby validating their identification. • There are several ways to create and load the certificate. The public key components and the identification block of each unit could be written to smart card. Using the smart card, the components are physically (or electronically) transported to a certified authority where the certificate is generated and loaded into the smart card. The certificate stored in the smart card is then loaded into the unit. 4 Certificates and PKI Certificates Alice’s Computer Random Number Generator Certificate Authority Alice’s info and public key Authority’s Public Key Alice’s Public Key Generates Keys Sign Alice’s Private Key Authority’s Private Key Signed certificate Certificate Authority’s Public 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? Certificates PKI Life-cycle Processes Trust Models Algorithms 5 M. Mogollon – 01/08 - 5 • Alice sends her information to a Certificate Authority and applies for a certificate. • In any transaction in which Alice’s identity needs to be authenticated, she sends her certificate. The receiver authenticates Alice by deciphering the certificate using the Certificate Authority’s public key. 5 Certificates and PKI 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) Subject’s Certificate Information 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 ● Certificates PKI Life-cycle Hash SHA-1 Encipher Digital Signature A S N 1 + D E R R A D I X 64 Certificate Authority’s Private Key ASN1: Abstract Syntax One Notation DER: Distinguish Encoding Rules (tag, length, value) Processes Trust Models Algorithms 6 M. Mogollon – 01/08 - 6 • X.509 is the most widely used certificate format for PKI. It is used in SSL, IPsec, S/MIME, SET, and now on PGP. RFC 4325 (Santesson, & Housley, 2005) lists the following X.509 certificate basic fields: • Version: This field gives the version of the encoded certificate. • Certificate Serial Number: The serial number is a unique positive integer assigned by the CA to each certificate. Certificate users must be able to support serial number values up to 20 octets. • Signature Algorithm Identifier: This field contains the algorithm identifier for the algorithm used by the CA to digitally sign the certificate. The algorithm could be RSA or DSA. • CA Issuer Name: The issuer field identifies the certification authority that has signed and issued the certificate. • Validity Period: The validity period field is the time interval during which the CA certifies that it will maintain information about the status of the certificate. The field is represented as a sequence of two dates: the date on which the certificate validity period begins and the date on which the certificate validity period ends. • Subject Name: The subject field identifies the entity whose public key is authenticated. • Subject Public-Key Information: This field is used to carry the public key and public- key parameters, as well as the identifier of the public-key algorithm used (e.g., RSA, DSA, or DiffieHellman). • Issuer Unique ID: This is an optional field used to allow the reuse of issuer names over time. • Subject Unique ID: This is an optional field used to allow the reuse of subject names over time. • Extensions: This field must appear only if the certificate version is 3. The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing a certification hierarchy, such as CA Key Identifier and Subject Key Identifier. • The information from the above fields is signed using the CA’s private key. The CA’s digital signature and the information from the above fields are (1) Concatenated; (2) Written using a syntax notation system called Abstract Syntax One; (3) Converted into binary data using Distinguish Encoding Rules (DER) encoding system; and then (4) Converted to ASCII characters using base-64 encoding. 6 Certificates and PKI 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 and NCA (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: Priv C Alice = ( Ident Alice , Pub Alice ) ca mod N CA • Upon receiving the certificate, Alice verifies the certificate by checking: ( Ident Alice , Pub Alice ) = C Alice Pubca mod N CA • 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: ( Ident Alice , Pub Alice ) = (C Alice ) Certificates PKI Life-cycle Processes PubCA mod N CA Trust Models Algorithms 7 M. Mogollon – 01/08 - 7 7 Certificates and PKI 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” Certificates PKI Life-cycle Processes Trust Models Algorithms 8 M. Mogollon – 01/08 - 8 • In the next chapters, secure mail, IPsec, and SSL protocols will be discussed. The protocols specify how a specific process is carried out, but they don’t describe how to manage keys and certificates on behalf of users and applications in a way that is transparent. The term transparency means that the end-users don’t need to know how the complex process to manage keys and certificates is done, and the process is virtually transparent to them. • VPNs are the standard used to provide privacy, authentication, integrity, and non-repudiation. It may seem that if a corporation uses VPNs then it doesn’t need PKI, but the reality is that VPNs and PKI are complementary. 8 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 9 M. Mogollon – 01/08 - 9 • There are many applications available to implement communications or network security. When public key is used, however, 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 Public Key Infrastructure or PKI. PKI enables organizations to set up and define secure networks by authenticating the validity of each person involved in a secure transaction, in a consistent manner, across a wide variety of applications. 9 Certificates and PKI Public Key Infrastructure Functions Functions Elements • Manages the complete life • A Certificate Authority cycle of keys and certificates. • Provides key backup and recovery. • Updates automatic key pairs and certificates • Manages key histories • Supports cross-certification • 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 10 M. Mogollon – 01/08 - 10 • The following are some of functions carried out by a PKI: • 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 10 Certificates and PKI PKI Management Model 1. Alice registers with the certificate Certificate Authority / Registration Authority Repository Site authority and applies for a certificate. 2. The CA verifies Alice’s identity and issues a certificate. 3 3. The CA publishes the certificate at a repository site. 4. Alice sends her enciphered 1 2 message and certificate to Bob. The message was signed with Alice’s private key to ensure authenticity, message integrity, and non-repudiation. 6 5 Enciphered Message 5. After receiving the message, Bob Digital Signature 4 Alice Bob 7 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 11 M. Mogollon – 01/08 - 11 11 Certificates and PKI PKI Management Entities Certificate Authority -2 Publish Certificate R e p o s I t o r y Publish CRL Certificate Revocation List (CRL) Issuer Publish Certificate Certificate Authority -1 Out-of-band publication Registration Authority PKI Users S I T e Search, Read End-Entity (PKI User) Published Certificates Certificates PKI Life-cycle Processes Trust Models Out-of-band loading Algorithms 12 M. Mogollon – 01/08 - 12 12 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 13 M. Mogollon – 01/08 - 13 • 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. End-entities include not only human users of applications, but, also, applications themselves (e.g., for IP security). All end-entities require secure local access to some information -- at a minimum, their own name and private key, the name of a CA, which is trusted by this entity, and that CA's public key (or a fingerprint of the public key when a self-certified version is available elsewhere). • Certification Authority • The identity and public key of each PKI user can be authenticated (signed) by a Certificate Authority. The Certification Authority (CA) may or may not actually be a real "third party" from the end-entity's point of view. Quite often, the CA will actually belong to the same organization as the end-entities it supports. The term CA refers to the entity named in the issuer field of a certificate. • Registration Authority • In addition to end-entities and CAs, many environments call for the existence of a Registration Authority (RA) separate from the Certification Authority. Since the RA is an optional component, when it is not present, the CA is assumed to be able to carry out the RA's functions, so that the PKI management protocols are the same from the end-entity's point of view. The RA is, in fact, another end-entity and all RAs are certified end-entities, meaning that they have private keys that are usable for signing. It is possible that one RA may work with more than one CA. In some circumstances, end-entities will communicate directly with a CA even when an RA is present. For example, for initial registration and/or certification, the subject may use its RA, but communicate directly with the CA in order to refresh its certificate. The RA’s obligations are the same as the CA’s. • Repository Site • CRLs are defined by the standard RFC 4325. The term repository refers to a network service that stores and distributes information, in this case, certificates. The Certificate Revocation List (CRL), which tracks expired certificates, is also stored in the repository site. As an option, in certain circumstances, a CA may delegate the publication of certificate revocation lists to a CRL Issuer. According to RFC 3647, the repository site obligation is the timely publication of certificates and revocation information. 13 Certificates and PKI PKI Management Requirements 1. 2. 3. Conform to the ISO /IEC 9594 -8 / ITU – T X.509 standard. 4. 5. 6. Allow the use of different industry-standard cryptographic algorithms. 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. 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 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 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 14 M. Mogollon – 01/08 - 14 1. PKI management must conform to the ISO /IEC 9594 -8 / ITU – T X.509 standard. 2. It must be possible to update regularly any key pair without affecting any other key pair. 3. The use of confidentiality (encryption) in PKI management protocols could be kept at different levels in order to ease countries’ regulatory problems. 4. PKI management protocols must allow the use of different industry-standard cryptographic algorithms, specifically including RSA, DSA, MD5, and SHA-1. 5. PKI management protocols must not preclude the generation of key pairs by the end-entity concerned, by an RA, or by a CA. Key generation may also occur elsewhere, but for the purpose of PKI management, it is assumed that key generation occurs whenever the key is first present at an end-entity, RA, or CA. 6. PKI management protocols must support the publication of certificates by the end-entity concerned, by an RA, or by a CA. 7. PKI management protocols must support the production of certificate revocation lists by allowing certified end-entities to make requests for the revocation of certificates. 8. PKI management protocols must be usable over a variety of "transport" mechanisms, including, specifically, mail, http, TCP/IP, and ftp. 9. The final authority for certification creation rests with the CA; no RA or end-entity equipment can assume that any certificate issued by a CA will contain what was requested. A CA may alter certificate field values or may add, delete or alter extensions according to its operating policy. 10. Whenever scheduled, non-compromised CA key updates should be supported. 11. The CA itself may, in some implementations or environments, carry out the functions of an RA. 12. When an end-entity requests a certificate containing a given public-key value, the end-entity must be ready to demonstrate possession of the corresponding private-key value. 14 Certificates and PKI Certificate Life-Cycle Initialization • Key pair generation • Registration • Certificate creation • Key & certificate Issued distribution • Key backup Certificates PKI Certificate retrieval • Certificate validation • Key recovery Key update • Certificate dissemination • • • Certificate update Life-cycle Processes Cancellation • Certificate expiration • Certificate revocation • Key history • Key archive Trust Models Algorithms 15 M. Mogollon – 01/08 - 15 • PKI is about managing certificates and keys during their complete life cycles and the entities involved. There are three phases in the life of a certificate and keys: Initialization, Issued, and Cancellation. • Phase 1 Initialization • Key pair generation • Registration • Certificate creation • Key & certificate distribution • Certificate dissemination • Key backup • Phase 2 Issued • Certificate retrieval • Certificate validation • Key recovery • Key update • Certificate update • Phase 3 Cancellation • Certificate suspension • Certificate expiration • Certificate revocation • Key history • Key archive 15 Certificates and PKI Key Lifecycle Management Initialization Key Generation Certificate Issuance Certificate Validation or Key Usage Key Expiration Key Update Certificates PKI Life-cycle Processes Trust Models Algorithms 16 M. Mogollon – 01/08 - 16 • Another way to describe Certificate Life-Cycle. 16 Certificates and PKI Certificate Life-Cycle Key Generation Certificate Application Key Recovery and Update Certificate Creation Certificate Distribution Dissemination Certificate Expiration Certificate and Certified Key Usage End-Entity Certificate Acceptance Certificate Revocation Certificate Suspension Certificate Resumption Certificates PKI Life-cycle Processes Trust Models Algorithms 17 M. Mogollon – 01/08 - 17 • Another way to describe Certificate Life-Cycle. 17 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 18 M. Mogollon – 01/08 - 18 • In this example, the following certificate policies are assumed: • The private key lifetime is 5 years. • The digital signature (public key) is valid for 10 years. • A certificate must be renewed every year. • Two documents have been signed, one at the beginning of the private key life span, let’s say on January 1, 2007 and another at almost the end of the private key time span let’s say December 31, 2011. Since the public key should be available for the duration of the digital signature, ten years, then the public key should be available until the end of 2021. • The public-key’s life span should always be longer than the private-key’s life span. 18 Certificates and PKI PKI Management Operations C e r t I f I c a t e s PKI Management Entities Publish Certificate Certificate Authority -2 • Cross-certification request • Cross-certificate update Publish CRL Certificate Revocation List (CRL) Issuer Certificate Authority -1 Publish Certificate 5 4 1, 3 2, 6 R e p o s I t o r y 7 8 PKI Users • Initialization • Registration • Certification • Issuance • Key Pair Recovery and Update • Certificate Renewal and update • Certificate Revocation Request & C R L Registration Authority Out-of-band publication Search, Read Published Certificates 1 2 3 4 5 6 7 8 Registration Form Request Registration Form Replay Registration Form Submission. Registration Setup Request Registration Setup Results Registration Results Certificate Request Certificate Response End-Entity (PKI User) Out-of-band loading CRL: Certificate Revocation List Certificates PKI Life-cycle Processes Trust Models Algorithms 19 M. Mogollon – 01/08 - 19 • The following are some of the CA’s functions: • Registering and accepting applications for certificates from end users and other entities; • Issuing and notification of issuance of a certificate to the subscriber who is the subject of the certificate being issued; • Validating the entities’ identities who are requesting certificates. • Notification of issuance of a certificate to others, other than the subject of the certificate; • Revoking, renewing, and suspension of a certificate and notification to the subscriber whose certificate is being revoked, renewed, or suspended; • Notification of revocation or suspension of a certificate to others other than the subject whose certificate is being revoked or suspended; and • Publishing directories of valid and revoked certificates. 19 Certificates and PKI Registration Authority Certificates PKI Life-cycle Certificate Authority Processes Trust Models Algorithms 20 M. Mogollon – 01/08 - 20 20 Certificates and PKI Process Exchange between End Entity and CA (Initialization) 4 • Registration 5 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. • Certificate Creation • Certificate Authority -1 Registration Authority 1 2 3 6 7 8 End Entity 1 (PKI User) 1 2 3 4 5 6 7 8 Registration Form Request Registration Form Replay Registration Form Submission. Registration Setup Request Registration Setup Results Registration Results Certificate Request Certificate Response Certificate and Key-pair Dissemination Only the CA can generate certificates. 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 21 M. Mogollon – 01/08 - 21 • Initialization refers to the process whereby an end-entity, which does not have a certificate from a CA contacts the CA or RA to get one. The end result of this process (when it is successful) is that a CA issues a certificate for an end-entity's public key, and then returns that certificate to the end-entity and/or posts it in a public repository. • This process may, and typically will, involve multiple steps, possibly including an initialization of the endentity's equipment. For example, the end-entity's equipment must be securely initialized with the public key of a CA to be able to be used in validating certificate paths. Furthermore, an end-entity typically needs to be initialized with its own key pair(s). The following are the initialization phase components: • Registration: Registration is the process in which the identity of the end-entity is established and verified, by either by the CA or the RA. • Key Pair Generation: Key pair generation is the process by which the public key pair is generated 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 endentity, the owner of the public-key pair. • Certificate Creation: Certification creation is the process by which the CA creates the certificate. Only the CA can generate certificates. • Certificate and Key-Pair Distribution: Certificate and key pair distribution is the process of distributing the certificate to the end-entity. If the CA generated the key pair, then the key pair also needs to be sent to the end-entity. • Certificate Dissemination: Certificate dissemination is the process by which the certificate is disseminated to the end-entity and to the repository site by the CA. The certificate can be sent to the end-entity using physical delivery; this is called out-of-band distribution. The certificate also can be sent to an end-entity application (S/MIME); this is called in-band distribution. • Key Backup (Optional): Key backup is the process of storing the key pair at a trusted third party’s location. 21 Certificates and PKI Process Exchange between End-Entity and CA (After Certificate is Issue) • 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 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. • Certificate Revocation Request Process of invalidating a certificate prior to its expiration date. Initiated by an authorized person. Certificates PKI Life-cycle Processes Trust Models Algorithms 22 M. Mogollon – 01/08 - 22 Key-Pair Recovery and Update • Once the certificate has been generated and disseminated, an end-entity has an exchange process with a CA in two situations. Those situations are key recovery and key update. The key-pair recovery process 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 is stored get corrupted. This process implies that all key material is stored and available for backup. • 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 end-entity information remain the same and a new certificate is issued. Update means that a new public-key pair and end-entity information are generated and a new certificate is issued. Certificate Revocation Request • When a certificate is issued, it is expected to be in use for its entire period of validity. However, various circumstances may cause a certificate to become invalid prior to its expiration date. The process of invalidating a certificate prior to its expiration date is called certificate revocation. The process is initiated by an authorized person who advises a CA of an abnormal situation requiring certificate revocation. It is not possible to detect by looking at a certificate whether it has been revoked or not, so it is a difficult process to keep up with all the revoked certificates. 22 Certificates and PKI End Entity – Repository Processes Exchanged C e r t I f I c a t e s • Certification Retrieval Certification retrieval is the process by which an endentity 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. C R L R e p o s I t o r y Certificates Search, Read End Entity Published Certificates PKI Life-cycle (PKI User) Processes Trust Models Algorithms 23 M. Mogollon – 01/08 - 23 • There are two processes exchanged between an end-entity and a repository site. These processes are called certification retrieval and certificate validation. • 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 • Once the certificate is retrieved, and before it is used, the end-entity needs to validate the certificate. The certificate validation includes the following assurance: • The certificate was issued by a trusted CA. Validate the certificate. • The certificate has not been changed. Check the integrity. • The certificate has not expired. Check the validity time period as indicated by the parameters “Not Valid Before” and “Not Valid After.” • The certificate has not been revoked. Check the CRL. 23 Certificates and PKI 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 CrossCertification 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”. Certificates PKI Life-cycle Processes Trust Models Algorithms 24 M. Mogollon – 01/08 - 24 • There are situations in which end-entity Alice has been certified by CA1 and end-entity Bob has been certified by CA2. Alice trusts only the certificates signed by CA1, and Bob trusts only the certificates signed by CA2. If Alice would like to certify Bob, it is not possible because Alice and Bob are in different domains. The mechanism of cross-certification, CA1 cross-certifies CA2, can be used to the extent that Alice trusts the end-entities certified by CA2, including Bob. • The processes exchanged between CA1 and CA2 are initiated when one CA requests issuance of a cross-certificate from the other CA. Specific types of cross certificates include the following: (1) Inter-domain cross-certificate – when the subject and issuer CAs belong to different administrative domains; (2) Intra-domain cross-certificate – when the CAs belong to the same domain. • When doing cross-certification, it is possible to set some controls. For example, the trust can be extended to certain groups within an organization within the other CA: a specific department, several groups, or to a limited number of end-entities. For example, organization “A” may set cross certification so that their customer account managers will only accept certificates from organization “B”s purchasing department. 24 Certificates and PKI CRL Structure CRL version ID of the algorithm used by the issuer (CA) to sign the CRL CA’s name issuing the CRL Subject’s Certificate Information 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 ● ● Certificates PKI Life-cycle Hash SHA-1 Encipher Digital Signature A S N 1 + D E R R A D I X 64 Certificate Authority’s Private Key ASN1: Abstract Syntax One notation DER: Distinguish Encoding Rules (tag, length, value) Processes Trust Models Algorithms 25 M. Mogollon – 01/08 - 25 • X.509 defines one method of certificate revocation. This method involves every CA periodically issuing a signed data structure called a Certificate Revocation List (CRL). A CRL is a timestamped list identifying revoked certificates; it is signed by a CA or CRL issuer and is made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate’s signature and validity, but also acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. • In X.509, only the issuer of a certificate can revoke it. If the CA loses its private signing key, then it would not be able to produce CRLs nor perform normal key rollovers. CAs should maintain secure backup for signing keys. If the CA’s private key is compromised by an attacker who obtains the private key unnoticed, the attacker might issue bogus certificates and CRLs, which would undermine confidence in the system. RFC 4325 recommends that if such a compromise is detected, all certificates issued by the compromised CA must be revoked, preventing services between its users and users of other CAs. Rebuilding after such a compromise will be problematic, so CAs are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident. 25 Certificates and PKI Hierarchical Trust Model Root CA Level 1 CA2 Level 1 CA1 Level n CA3 End Entity A Level n CA4 End Entity B End Entity C Advantage: End Entity D Level n CA6 Level n CA5 End Entity E End Entity F End Entity G End Entity H Relatively simple to implement Disadvantage: No cross certification between CAs. If endentity A wants to certify end-entity F, it needs to go all the way to CA5. Certificates PKI Life-cycle Processes Trust Models Algorithms 26 M. Mogollon – 01/08 - 26 • CAs act as agents of trust by validating PKI users’ identity and public keys. All PKI users must have a registered identity. The concept is known as third-party trust; a PKI user can trust the certificate issued by a CA as long as the user trusts the CA. “Alice trusts Bob” means that “Alice trusts the CA that signed Bob’s certificate.” • A security domain is the logical domain in which a CA issues and manages certificates, for example in a corporation, a department. For example above, if Alice and Bob work for the same corporation and are in the same department, they may have the same CA. If Alice and Bob are not in the same domain, and work for different organizations, how can each of them establish trust? • Two end-entities can establish trust in each other by using one of several trust models. Those trust models are Hierarchy, Mesh, Web Model, and User Centric (Adams, & Lloyd, 2003, pp 131-149). • In a hierarchical trust model, the root CA is at the top and below are several layers of intermediate CAs. The layer below the lowest layer of intermediate CAs consist of non-CAs, and end-entities or end users. • Each of the intermediate CAs is considered an entity. In this model, all entities in the hierarchy trust the root CA. The advantage of this model is that it is relatively simple to implement; the disadvantage is that it doesn’t allow cross certification between CAs. 26 Certificates and PKI Mesh Trust Model Cross-Certification Root CA (1) Root CA Root CA (2) Level 1 CA1 Level n CA3 Level 1 CA2 Level 1 CA2 Level n CA5 Level n CA5 End Entity A End Entity F End Entity B • All root CAs are cross-certified with each other, or whenever their respective communities need to communicate with each other. Certificates PKI Life-cycle Processes Trust Models Algorithms 27 M. Mogollon – 01/08 - 27 • The process of interconnecting Root CAs is called cross-certification. • In a mesh trust model, all root CAs are initially cross-certified with each other, or whenever their respective communities need to communicate with each other. 27 Certificates and PKI Web Trust Model Entrust CA VeriSign CA Equifax CA Level 1 CA1 Level 1 CA2 Level 1 CA2 End Entity A End Entity B End Entity C • 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. • Web Model • 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 28 M. Mogollon – 01/08 - 28 • In terms of the number of users, the trust list, also called Web model, is the most widely used trust model. Firefox and Microsoft Explorer Web browsers are distributed with about 100 CA public keys pre-installed. Each browser user has a local file of trusted self-signed root certificates. The browsers normally are distributed with an initial set of root certificates, but users can add to this set or delete certificates from it. In addition, organizations may have provision for loading or managing the trust list from a central network management server. In the trust-list model, the Web browser acts as a virtual root CA because Web users trust the CA installed in their software. • The browsers can use the pre-installed certificates to sign, verify, encrypt and decrypt S/MIME email messages and establish Transport Layer Security (TLS) and Secure Socket Layer (SSL) sessions. Browsers can also verify the signatures on signed codes. • For an end-user, managing the numerous trusted CA certificates installed in a browser is a very difficult task; besides, there is no practical way to prevent either users or others with access to users’ workstations from making unauthorized alterations to the list. The practice of distributing an initial file of such self-signed certificates with browser products, and the fact that there are only two leading browsers in the market, make the self-signed certificates included with the browsers the de facto CA accreditation. • In this model, there is no practical mechanism to revoke certificates. If Firefox or Microsoft make a mistake and install a “bad” CA, there is no way to revoke that certificate from the millions of Web browsers in use, unless MS and Firefox update the CA list. 28 Certificates and PKI User-Centric Model • Used by Pretty Good Privacy (PGP) in a decentralized environment. • Any user can act as a certifying Root CA Alice Root CA Bob authority and validate another user’s public key certificate. • Not all certificates generated Root CA Jason 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. Root CA Rick • Each user is directly responsible for deciding which certificates to accept and which ones to reject. Certificates PKI Life-cycle Root CA Sandra User-Centric Model Processes Trust Models Algorithms 29 M. Mogollon – 01/08 - 29 • Pretty Good Privacy (PGP) uses the user-centric trust model in a decentralized environment. In PGP, any user can act as a certifying authority and validate another PGP user’s public-key certificate. However, a certificate generated by Alice, who is acting as CA, may not be valid to another user because he knows that Alice cannot be trusted as a CA. In the user-centric model, each user is directly responsible for deciding which certificates to accept and which ones to reject. 29 Certificates and PKI Comparison of Trust Models Characteristics Hierarchical Mesh Trust-List (Web) Trusted key(s) “Root” CA CA that issued user’s certificate. File of (usually) many trusted CA certificates in each browser. Trust paths Chain of parent-child certificates. Mesh of bi-directional cross certificate pairs. Pre-ordered certificate list. Trust path finding Directory-Based, comparatively simple. Directory-Based, complex. Minimal; finds individual certificates in LDAP directory. Cross-certification May be supported. Basis of PKI No direct capability. Certificate status Certificate Revocation List. Certificate Revocation List None (may add support for Online Certificate Status Protocol in future). Certificates PKI Life-cycle Processes Trust Models Algorithms 30 M. Mogollon – 01/08 - 30 30 Certificates and PKI Certificate Path and Validation Same Self Signed Certificate ●●● Issuer: Root Intermediate CA 2 ●●● Issuer: CA Root ●●● Intermediate CA 1 ●●● Issuer: CA2 ●●● ●●● Issuer: CA1 Root CA ●●● Subject: Root ●●● Intermediate CA Certificate Subject: CA2 ●●● Intermediate CA Certificate End Entity A Certificates PKI Life-cycle ●●● Processes Subject: CA1 ●●● End Entity Certificate Subject: End ●●● Entity A Trust Models Algorithms 31 M. Mogollon – 01/08 - 31 • The PKI Forum has proposed two fields, Issuer Certificate Authority Key identifier and Subject Key identifier, in the X.509 Version 3 Public Key Certificate Optional Extensions field to help facilitate the certification path and validation process. This process is called “name chaining.” • The PKI Forum is an international, not-for-profit, multivendor and end-user alliance whose purpose is to accelerate the adoption and use of Public-Key Infrastructure (PKI). http://www.pkiforum.org 31 Certificates and PKI 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,. Certificates PKI Life-cycle Processes Trust Models Algorithms 32 M. Mogollon – 01/08 - 32 • • • • One-way Hash Functions • Function: One-way hash functions are also called message digest algorithms. • Mandatory Algorithm: SHA-1 is the preferred one-way hash function for the Internet X.509 PKI. The U.S. Government developed SHA-1. SHA-1 produces a 160-bit "hash" of the input. Signature Algorithms • Function: Certificates and CRLs conforming to RFC 3280 may be signed with any public key signature algorithm. Signature algorithms are always used in conjunction with a one-way hash function. • The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA encryption) is performed to generate the signature value. This signature value is then ASN.1 encoded as a bit string and included in the Certificate in the signature field. According to RFC4210, PKI messages are protected using digital signatures. • Mandatory Algorithm: DSA/SHA-1 • Others Algorithms: HMAC/SHA-1, RSA/MD5 and ECDSA/ECDH Public Key (Asymmetric) Algorithms • Function: Used for encryption of private keys transported in PKI messages. • Mandatory Algorithm: Diffie-Hellman • Others Algorithms: RSA, ECDH. Symmetric Algorithms • Function: Encryption of an end-entity’s private key when the symmetric key is distributed in-band or out-of-band. • Mandatory Algorithm: 3DES, (3-key EDE, CBC mode). • Others Algorithms: AES, RC5 and Cast 128. 32 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 33 M. Mogollon – 01/08 - 33 • When an organization is going to deploy PKI, it could do so by in-sourcing or out-sourcing. Insourcing gives an organization full control of the PKI implementation by utilizing its own resources, including personnel and hardware, and/or hiring external resources. Out-sourcing takes the PKI management burden from the organization, but gives control of the PKI operation to an external party. • According to Adams, and Lloyd, (2003), when an organization is making a decision for PKI deployment, it should consider the following factors: • 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. • The perceived sense of trust that customers might have from knowing that the PKI operation is 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 Certificates and PKI To Probe Further • [NEW01] Newman, D. PKI: Build, Buy, or Bust. Networkworld Magazine, December 10, 2001. 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 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. http://www.nwfusion.com/research/2001/1210feat.html Certificates PKI Life-cycle Processes Trust Models Algorithms 34 M. Mogollon – 01/08 - 34 34 Certificates and PKI 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. Certificates PKI Life-cycle Processes Trust Models Algorithms 35 M. Mogollon – 01/08 - 35 35 Certificates and PKI Value of Digital Signatures (from VeriSign) Certificates PKI Life-cycle Processes Trust Models Algorithms 36 M. Mogollon – 01/08 - 36 36 Certificates and PKI Value of Digital Signatures (From VeriSign) Certificates PKI Life-cycle Processes Trust Models Algorithms 37 M. Mogollon – 01/08 - 37 37 Certificates and PKI PKI-Enable Application List (From PKI Forum) Certificates PKI Life-cycle Processes Trust Models Algorithms 38 M. Mogollon – 01/08 - 38 38 Certificates and PKI PKI-Enable Application List (From PKI Forum) Certificates PKI Life-cycle Processes Trust Models Algorithms 39 M. Mogollon – 01/08 - 39 39 ...
View Full Document

This note was uploaded on 05/26/2010 for the course TECH 6350 taught by Professor Mogollon during the Spring '10 term at University of Arkansas for Medical Sciences.

Ask a homework question - tutors are online