CompTIA Security_ Deluxe Study Guide_ SY0-201 - Emmett Dulaney [179]
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; however, this situation should change over the next few years because customers expect compatibility.
Most organizations have a PKI policy document that describes the uses for the electronic signing technology. Associated documents that fall under this category often include a confidentiality certificate policy document and a digital signature certificate policy document.
The following sections explain the major functions and components of the PKI infrastructure and how they work in relationship to the entire model.
Under no circumstances should you ever divulge or send your private key. Doing so jeopardizes your guarantee that only you can work with the data and can irreparably damage your security.
Using a Certificate Authority
A certificate authority (CA) is an organization that is responsible for issuing, revoking, and distributing certificates. A certificate is nothing more than a mechanism that associates the public key with an individual. It contains a great deal of information about the user. Each user of a PKI system has a certificate that can be used to verify their authenticity.
For instance, if Mike wants to send Jeff a private message, there should be a mechanism to verify to Jeff that the message received from Mike is really from Mike. If a third party vouches for Mike and Jeff trusts that third party, Jeff can assume that the message is authentic because the third party says so. Figure 7.10 shows this process happening in a communication between Mike and Jeff; the arrows in this figure show the path between the CA and the person using the CA for verification purposes.
CAs can be either private or public. Many operating system providers allow their systems to be configured as CA systems. These CA systems can be used to generate internal certificates that are used within a business or in large external settings.
The process of providing certificates to users, although effective in helping to ensure security, requires a server. Over time, the server can become overloaded and need assistance. An additional component, the registration authority (RA), is available to help offload work from the CA. Registration authorities are discussed in the next section.
FIGURE 7.10 The certificate authority process
Working with Registration Authorities and Local Registration Authorities
A registration authority (RA) offloads some of the work from a CA. An RA system operates as a middleman in the process: It can distribute keys, accept registrations for the CA, and validate identities. The RA doesn’t issue certificates; that responsibility remains with the CA. Figure 7.11 shows an RA operating in San Francisco, while the CA is located in Washington, D.C. The Seattle user obtains authorization for the session from the RA in San Francisco. The Seattle user can also use the San Francisco RA to validate the authenticity of a certificate from the Miami user. The arrows between the Seattle user and the RA server represent the certificate request from the remote user. The RA has a communications link with the CA in Washington, D.C. Because