CompTIA Security+ SYO-401

Certification Training
9037 Learners
View Course Now!
33 Chapters +

Use appropriate PKI CM and AC Tutorial

1 Use appropriate PKI CM and AC

Today, a secure networking environment is vital for any enterprise, especially one that relies on electronic transactions. To ensure confidentiality of data and safety from cyber-attacks, companies depend on digital credentials. The cornerstones of security are encryption, non-repudiation, and authentication. In this lesson, we will talk about a cryptographic technique, the public-key cryptography, which helps secure communication and ensure data privacy through encryption and decryption of data. Let’s begin with objectives covered in this lesson in the next screen. After completing this lesson, you will be able to: • Comprehend Public Key Infrastructure, • Illustrate the method to obtain or register digital certificate, and • Understand certificate status.

2 Public Key Infrastructure

In this topic, you will learn about Public Key Infrastructure. Let’s start with understanding what Public Key Infrastructure, or P-K-I is. It is a set of hardware, software, policies, and procedures that are required to create, distribute, use, store, and revoke the Digital certificate and manage Public Key. For P-K-I, it is essential to use Pretty Good Privacy, or P-G-P, wherein every user is required to generate a key pair to carry out secure communication. Generally used for secure transactions, this helps provide authenticity, integrity and non-repudiation. The different components of PKI include Certification Authority, Registration Authority, Certificate Repository, Digital Certificate, and Revocation System. Moreover, entities such as keys, encryption, hashing, and others also belong to the Public Key Infrastructure. Now, let’s consider an example to explain the PKI process. User 1 and User 2 both generate a key pair using asymmetric cryptography. This pair consists of a public and private key. Next, both User 1 and User 2 will exchange their public keys and store the key details in in their browser settings. When User 1 wants to send any data to User 2, he will encrypt the message by using the public key of User 2, and vice versa. When User 1 and User 2 want to read the message, they will decrypt the message by using their private key. It is important to note that, users can decrypt the data only by using their private key. For those of you who don’t know: A public key originates from a private key, and is a digitally signed document which is sent out to validate the sender’s credentials, such as authorization and name. Since this is key is publicly available, anyone can use it to initiate a secure communication with the sender. On the other hand, a private key can be accessed only by its rightful owner and is stored locally in a secure manner. Its primary function is to unlock or decrypt the communications received from the corresponding public key. Another use of private key is to create digital signatures. Let’s now look at the security aspect of Public Key Infrastructure. It is always better to secure communication against Session hijacking and man-in-the-middle attacks, also known as M-I-T-M. As users exchange their public key that can only be used for encryption and the data can be only decrypted by their respective private keys, this means that no one else will have access to the data. So if an attacker is able to successfully sniff the packet, he cannot decrypt the data. Recovery agents are commonly referred to as key-recovery or key-escrow agents. We have already explained the working of Escrow Agents in Lesson 6.1. As you may recall, a recovery agent does the task of retrieving a key from the escrow, and this key is used by the user to decrypt a piece of information. This saves the user from the hassle of managing multiple keys.

3 Digital Certificate

In this topic, you will learn how to obtain or register digital certificates. Certificate Authority is the only PKI component that can be used to create Digital Certificates for users even before the Registration Authority, or RA, validates the identity of the user. A certificate authority (CA) is an organization responsible for issuing, revoking, and distributing the certificates for clients or servers. A certificate contains information about the user and affirms the authenticity of the user. But to receive this digital certificate, the client has to follow certain procedures. These processes vary depending on the existing services and infrastructure. There are many organizations who provide digital certificates. For example, VeriSign makes its own CA to work on its intranet. But when it has to establish communication with the Internet, VeriSign is required to borrow or buy certificates from a public domain. The key features of certificate authority include: • Creating digital certificate, • Binding user identity to public key, and • Maintaining the certificate till it expires. Let’s consider a scenario to understand how to obtain a Certificate Authority. We have two users, Rick and Sam. Rick decides to communicate with Sam through an email, so he sends a public key. But Sam doesn’t trust Rick and doesn’t accept Rick’s key. Now, the only option for Rick is to communicate with Sam in a trusted manner. For this, he needs to obtain or register for a digital certificate. To do this: • The Registration Authority, or RA, first validates Rick’s identity. • Then, they create a private key which in turn is used to generate a public key. • Next, along with the proof of subject’s identity, the generated public key is sent to the CA to generate a digital certificate. • CA then verifies the shared details and performs the required checks. • Next, once all details have been successfully verified, the CA creates a certificate, and digitally signs Rick’s public key with his own private key. • This is followed by adding a text file with mandatory details according to the X.509 v3 certificate standard. • And in the final step, the CA releases the digitally signed certificate to Rick via a secured route. Rick’s identity is now bonded to the public key and embedded in the digital certificate. So now if Rick sends a communication request, Sam would accept the public key as it is signed by a trusted certificate authority. Now let’s see the contents in a digital certificate. It includes: • The certificate holder’s public key • Information about the computer or organization to which the certificate has been issued • Information about the Certificate Authority, or organization, that issued the certificate and the CA’s digital signature • Date of Issue and Expiry of the certificate • Serial number of the certificate • Algorithm used for encryption Additionally, a certificate is classified into three classes: Class 1, Class 2, and Class 3. Class 1 is used to exchange secure e-mail communication with another user and to verify an individual’s identity. Class 2 is used to digitally sign the software and to ensure the integrity of the software to the users. And finally, Class 3 is used to set up a certificate authority for an organization.

4 Trust Models

Trust model refers to the structure of the trust hierarchy used by certificate authority systems. The Root CA lies at the top of the hierarchy. A root CA self-signs its own certificate to initiate the tree of trust. The Root CA assigns two subordinate CAs, they sign two subordinates’ certificates, and so on. This how the tree grows in an inverted manner. The subordinates to the Root CA are termed Intermediate CAs, and to the Intermediates, Leaf CAs. Since the root CA begins the trust, and it flows downward to all CAs and participants in the hierarchy, we can say that all entities in the model rely on the trustworthiness of the root CA. There exists another form of hierarchical trust model where the Root CA of one organization is configured to trust the Root CA from another organization. In this bridge trust structure model, the keys or certificates from either organization are trusted and accepted. Another form of this model is known as Trust List. Here, a web browser or online application displays the provided list of root certificates of trusted CAs. It is because of the existence of the trusted root CA, the web application agrees to display the countless sources of certificates. In PKI, Certificate Signing Request, or C-S-R, is an encrypted request sent to the CA by a user or organization to apply for a digital certificate. The displayed table describes the information to be included in CSR. Common Name The name of your request server e.g. svr1.xyz.com Organization name The name of your organization xyz Organization unit The domain of your organization IT City/Locality City name Delhi State/County/Region Sate name New Delhi Country Country name usually denoted by two letters e.g. India .in India E-mail Address e-mail admin@xyz.com Public Key The public key that will go in to the certificate Will be created automatically As CA receives the request, they use the provided information to create the S-S-L certificate, and provide the Private Key. Next, as the certificate is associated with the requester’s server, it is mandatory to back up your private key. This would be helpful if the certificate gets corrupted or is lost. In case you are unable to recover the private key from the backup, you need to raise a request to the key recovery agent, or KRA, and provide your serial number. Moreover, in this process, the RA has to register the key, and act as the mediator in the process of providing the certificate. Though not directly responsible for creating the certificate, RAs have to accept the registration request, validate the user identity, and distribute the key.

5 Manage Certificate Status

In this topic you will learn how to manage certificate status. All issued certificates come with an expiration date, termed the lifetime date. As the certificates reach this date, they are no longer valid, and the issuing authority invalidates or rejects the certificates. However, in order to revoke the rights or permissions for a certificate, the CA or issuing authority must have a valid reason. The reasons can be that the subject has changed its identity information or used the certificate to commit a crime or theft. Once the certificate is revoked, it is added to the Certificate Revocation List, or CRL. This is a database to store the details of revoked certificates. If a certificate in the CRL has crossed its validity date, it is automatically removed from the CRL. In other words, the CRL consists of revoked, but valid certificates. All applications and users regularly receive updated CRL without any cost, and it acts as a reference point before accepting a certificate. Like the certificates, even CRLs are assigned a lifetime date. Once the date is reached, users and applications cannot rely on its authenticity and are required to obtain its updated version. Now, let's understand the Certificate Revocation process. As an application receives a certificate from a server, it checks whether the issued certificate is valid. If yes, the application moves to the local copy of the issuing CA's CRL, and verifies, if the CRL hasn't reached its lifetime date. In case the CRL is no longer valid, the application requests for an updated copy of the CRL. In the next step, the application verifies if the certificate is listed in the updated CRL. If the result is negative, the application passes the certificate to the user for acceptance. At this point, the user has the option to either accept or reject the certificate, and command the application to either accept or reject all succeeding instances of this certificate. In addition to CRL, there is another mechanism, referred to as Online Certificate Status Protocol, or OCSP, that does the task of intimating applications and users about the current status of certificates. This mechanism enables users and applications to directly send a query to its CA or RA server. As the query is received, the CA responds with the certificate status—whether the certificate is valid, or revoked. This saves the effort of regularly transmitting updated heavy CRL database files to users and applications.Almost all keys and certificates have an end or expiration date. In other words, after this date, the key or certificate is not valid to provide the required service. Users and applications are aware of this date, and as this date approaches, you can request a renewal. It is advised that you choose renewal because if this expiration date is crossed, you would have to perform the entire process of obtaining or registering the key. Renewal is the process of re-issuing the certificate with a new or extended validity date. This process can be performed only till the certificate or key is valid, and it uses the existing key to sign the request for the new key. However, the decision to renew the key still rests with the CA and depends on two key factors. First, the key's lifetime date, and second, the user's compliance with the agreed terms of the user-acceptance policy. Though suspension and revocation are similar, unlike the latter, suspension enables you to bar the key or certificate from its regular task or signing or encrypting new items for a certain duration. While the key or certificate is suspended, you can still verify or decrypt the items signed using this key. However, it can be reactivated at a later date. The reason to suspend or reactivate a key rests with the Certificate Authority.

7 Summary

Let’s summarize the topics covered in this lesson. • PKI is a set of hardware, software, policies, and procedures that are required to create, distribute, use, store, and revoke the Digital certificate and manage the Public Key. • Certification Authority is the only PKI component that can be used to create Digital Certificates for users even before the Registration Authority, or RA, validates the identity of the user. • CSR is an encrypted request sent to the CA by a user or organization to apply for a digital certificate. • Suspension enables you to bar the key or certificate from its regular task or signing or encrypting new items for a certain duration. With this we conclude the lesson “Using appropriate PKI, certificate management and associated components.”

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*