SY0-501 Section 6.3- Given a scenario, use appropriate PKI, certificate management and associated components.

Certificate authorities and digital certificates

Certificate Authorities

The CA is the trusted authority that certifies individuals’ identities and creates electronic documents indicating that individuals are who they say they are. The electronic document is referred to as a digital certificate, and it establishes an association between the subject’s identity and a public key. The private key that is paired with the public key in the certificate is stored separately. It is important to safeguard the private key, and it typically never leaves the machine or device where it was created. The CA is more than just a piece of software, however; it is actually made up of the software, hardware, procedures, policies, and people who are involved in validating individuals’ identities and generating the certificates. This means that if one of these components is compromised, it can negatively affect the CA overall and can threaten the integrity of the certificates it produces. Every CA should have a certification practices statement (CPS) that outlines how identities are verified; the steps the CA follows to generate, maintain, and transmit certificates; and why the CA can be trusted to fulfill its responsibilities. It describes how keys are secured, what data is placed within a digital certificate, and how revocations will be handled. If a company is going to use and depend on a public CA, the company’s security officers, administrators, and legal department should review the CA’s entire CPS to ensure that it will properly meet the company’s needs, and to make sure that the level of security claimed by the CA is high enough for their use and environment. A critical aspect of a PKI is the trust between the users and the CA, so the CPS should be reviewed and understood to ensure that this level of trust is warranted.

Digital Certificates

A digital certificate binds an individual’s identity to a public key, and it contains all the information a receiver needs to be assured of the identity of the public key owner. After an RA verifies an individual’s identity, the CA generates the digital certificate, but how does the CA know what type of data to insert into the certificate? The certificates are created and formatted based on the X.509 standard, which outlines the necessary fields of a certificate and the possible values that can be inserted into the fields. As of this writing, X.509 version 3 is the most current version of the standard. X.509 is a standard of the International Telecommunication Union (www.itu.int). The IETF’s Public-Key Infrastructure (X.509), or PKIX, working group has adapted the X.509 standard to the more flexible organization of the Internet, as specified in RFC 3280, and is commonly referred to as PKIX for Public Key Infrastructure (X.509).

The following fields are included within a X.509 digital certificate:

– Version number Identifies the version of the X.509 standard that was followed to create the certificate; indicates the format and fields that can be used.  Subject Specifies the owner of the certificate.

– Public key Identifies the public key being bound to the certified subject; also identifies the algorithm used to create the private/public key pair.

– Issuer Identifies the CA that generated and digitally signed the certificate.

– Serial number Provides a unique number identifying this one specific certificate issued by a particular CA.

– Validity Specifies the dates through which the certificate is valid for use.

– Certificate usage Specifies the approved use of certificate, which dictates intended use of this public key.

– Signature algorithm Specifies the hashing and digital signature algorithms used to digitally sign the certificate.

– Extensions Allow additional data to be encoded into the certificate to expand the functionality of the certificate. Companies can customize the use of certificates within their environments by using these extensions. X.509 version 3 has extended the extension possibilities.

The subject of a certificate is commonly a person, but it does not have to be. The subject can be a network device (router, web server, firewall, and so on), an application, a department, a company, or a person. Each has its own identity that needs to be verified and proven to another entity before secure, trusted communication can be initiated. If a network device is using a certificate for authentication, the certificate may contain the network address of that device. This means that if the certificate has a network address of 10.0.0.1, the receiver will compare this to the address from which it received the certificate to make sure a man-in-the-middle attack is not being attempted.

CA

Four main types of certificates are used:

– End-entity certificates

– CA certificates

– Cross-certification certificates

– Policy certificates

A CA issues end-entity certificates to a specific subject, such as Joyce, the Accounting department, or a firewall. An end-entity certificate is the identity document provided by PKI implementations. A CA certificate can be self-signed, in the case of a standalone or root CA, or a superior CA within a hierarchical model can issue it. The superior CA gives the authority and allows the subordinate CA to accept certificate requests and generate the individual certificates it. In these situations, a representative from each department requiring a CA registers with the higher trusted CA and requests a Certificate Authority certificate. Cross-certificates, or crosscertification certificates, are used when independent CAs establish peer-to-peer trust relationships. Simply put, they are a mechanism through which one CA can issue a certificate allowing its users to trust another CA. Within sophisticated CAs used for high-security applications, a mechanism is required to provide centrally controlled policy information to PKI clients. Placing the policy information in a policy certificate often does this.

CRLS

Certificate revocation is the process of revoking a certificate before it expires. A certificate may need to be revoked because it was stolen, an employee has moved to a new company, or someone has had their access revoked. A certificate revocation is handled either through a certificate revocation list (CRL) or by using the Online Certificate Status Protocol (OCSP). A repository is simply a database or database server where the certificates are stored. The process of revoking a certificate begins when the CA is notified that a particular certificate needs to be revoked. This must be done whenever the private key becomes known. The owner of a certificate can request that it be revoked at any time, or the administrator can make the request.

OCSP

The CA marks the certificate as revoked. This information is published in the CRL and becomes available using the OCSP. The revocation process is usually very quick; the time required is based on the publication interval for the CRL. Disseminating the revocation information to users may take longer. Once the certificate has been revoked, it can never be used—or trusted—again. The CA publishes the CRL on a regular basis, usually either hourly or daily. The CA sends or publishes this list to organizations that have chosen to receive it; the publishing process occurs automatically in the case of PKI. The time between when the CRL is issued and when it reaches users may be too long for some applications. This time gap is referred to as latency. OCSP solves the latency problem: If the recipient or relaying party uses OCSP for verification, the answer is available immediately. Currently, this process is under evaluation and may be replaced at some time in the future.

Pki

The Public-Key Infrastructure (PKI) is intended to offer a means of providing security to messages and transactions on a grand scale. The need for universal systems to support ecommerce, secure transactions, and information privacy is one aspect of the issues being addressed with PKI.

PKI is a two-key, asymmetric system with four main components: certificate authority (CA), registration authority (RA), RSA (the encryption algorithm), and digital certificates. Messages are encrypted with a public key and decrypted with a private key. As an example, take the following scenario:

1. You want to send an encrypted message to Jordan, so you request his public key.

2. Jordan responds by sending you that key.

3. You use the public key he sends you to encrypt the message.

4. You send the message to him.

5. Jordan uses his private key to decrypt the message

The main goal of PKI is to define an infrastructure that should work across multiplevendors, systems, and networks. It’s important to emphasize that PKI is a framework and not a specific technology. Implementations of PKI are dependent on the perspective of the software manufacturers that implement it. This has been one of the major difficulties with PKI: Each vendor can interpret the documents about this infrastructure and implement it however they choose. Many of the existing PKI implementations aren’t compatible with each other, but this situation should change over the next few years because customers demand compatibility.

Public key

Public key infrastructures (PKIs) are becoming a central security foundation for managing identity credentials in many companies. The technology manages the issue of binding public keys and identities across multiple applications. The other approach, without PKIs, is to implement many different security solutions and hope for interoperability and equal levels of protection.

Private key

PKIs comprise components that include certificates, registration and certificate authorities, and a standard process for verification. PKI is about managing the sharing of trust and using a third party to vouch for the trustworthiness of a claim of ownership over a credential document, called a certificate. The Public-Key Infrastructure (PKI) is intended to offer a means of providing securityto messages and transactions on a grand scale. The need for universal systems to support ecommerce, secure transactions, and information privacy is one aspect of the issues being addressed with PKI.

PKI is a two-key, asymmetric system with four main components: certificate authority (CA),

registration authority (RA), RSA (the encryption algorithm), and digital certificates. Messages are encrypted with a public key and decrypted with a private key. As an example, take the following scenario:

1. You want to send an encrypted message to Jordan, so you request his public key.

2. Jordan responds by sending you that key.

3. You use the public key he sends you to encrypt the message.

4. You send the message to him.

5. Jordan uses his private key to decrypt the message.

The main goal of PKI is to define an infrastructure that should work across multiple vendors, systems, and networks. It’s important to emphasize that PKI is a framework and not a specific technology. Implementations of PKI are dependent on the perspective of the software manufacturers that implement it. This has been one of the major difficulties with PKI: Each vendor can interpret the documents about this infrastructure and implement it however they choose. Many of the existing PKI implementations aren’t compatible with each other, but this situation should change over the next few years because customers demand compatibility.

The Basics of Public Key Infrastructures

A PKI provides all the components necessary for different types of users and entities to be able to communicate securely and in a predictable manner. A PKI is made up of hardware, applications, policies, services, programming interfaces, cryptographic algorithms, protocols, users, and utilities. These components work together to allow communication to take place using public key cryptography and asymmetric keys for digital signatures, data encryption, and integrity. Although many different applications and protocols can provide the same type of functionality, constructing and implementing a PKI boils down to establishing a level of trust. If, for example, John and Diane want to communicate securely, John can generate his own public/private key pair and send his public key to Diane, or he can place his public key in a directory that is available to everyone. If Diane receives John’s public key, either from him or from a public directory, how does she know it really came from John? Maybe another individual is masquerading as John and replaced John’s public key with her own. If this took place, Diane would believe that only John could read her messages and that the replies were actually from him. However, she would actually be communicating with Katie. What is needed is a way to verify an individual’s identity, to ensure that a person’s public key is bound to their identity and thus ensure that the previous scenario (and others) cannot take place.

In PKI environments, entities called registration authorities and certificate authorities (CAs) provide services similar to those of the Department of Motor Vehicles (DMV). When John goes to register for a driver’s license, he has to prove his identity to the DMV by providing his passport, birth certificate, or other identification documentation. If the DMV is satisfied with the proof John provides (and John passes a driving test), the DMV will create a driver’s license that can then be used by John to prove his identity. Whenever John needs to identify himself, he can show his driver’s license. Although many people may not trust John to identify himself truthfully, they do trust the third party, the DMV.

What does the “infrastructure” in “public key infrastructure” really mean? An infrastructure provides a sustaining groundwork upon which other things can be built. So an infrastructure works at a low level to provide a predictable and uniform environment that allows other higher-level technologies to work together through uniform access points. The environment that the infrastructure provides allows these higher level applications to communicate with each other and gives them the underlying tools to carry out their tasks.

Registration

A key pair (public and private keys) can be generated locally by an application and stored in a local key store on the user’s workstation. The key pair can also be created by a central keygeneration server, which will require secure transmission of the keys to the user. The key pair that is created on the centralized server can be stored on the user’s workstation or on the user’s smart card, which will allow for more flexibility and mobility. In most modern PKI implementations, users have two key pairs. One key pair is often generated by a central server and used for encryption and key transfers. This allows the corporate PKI to retain a copy of the encryption key pair for recovery, if necessary. The user to make sure that she is the only one with a copy of the private key usually generates the second key pair, a digital signature key pair. Nonrepudiation can be challenged if there is any doubt about someone else obtaining a copy of an individual’s signature private key. If the key pair was created on a centralized server, that could weaken the case that the individual was the only one who had a copy of her private key. If a copy of a user’s signature private key is stored anywhere other than in her possession, or if there is a possibility of someone obtaining the user’s key, then true nonrepudiation cannot be provided.

Trust models

We need to use a PKI if we do not automatically trust individuals we do not know. Security is about being suspicious and being safe, so we need a third party that we do trust to vouch for the other individual before confidence can be instilled and sensitive communication can take place. But what does it mean that we trust a CA, and how can we use this to our advantage? When a user chooses to trust a CA, she will download that CA’s digital certificate and public key, which will be stored on her local computer. Most browsers have a list of CAs configured to be trusted by default, so when a user installs a new web browser, several of the most wellknown and most trusted CAs will be trusted without any change of settings. In the Microsoft CAPI environment, the user can add and remove CAs from this list as needed. In production environments that require a higher degree of protection, this list will be pruned, and possibly the only CAs listed will be the company’s internal CAs. This ensures that the company will automatically install digitally signed software only if it was signed.