Public key infraestructure — PKI
The Public key infrastructure (PKI) is a framework (guideline) that consists of several security policies, communication protocols, and procedures to enable secure and trusted communication between different entities using public-key encryption. This framework relies on a hierarchy of trust relationships, by providing authentication (to confirm the owner using digital certificates) and confidentiality by providing encryption (confidentiality) with the public-key encryption.
How does asymmetric encryption work?
When using asymmetric encryption we make use of two sets of key pairs, a public (which is shared) and a private (which is not shared). The Public key is used to encrypt the message to a receiver and the receiver then can decrypt the message using their own private key. When we encrypt a message it is called ciphertext. Do not worry about what occurs from behind, it is all about mathematics, in which those two keys are able to solve the same puzzle!
There is also a Diffie-Hellman key exchange that explains how to distribute the public key. But not needed for this specific topic. Another question that is usually is asked is, ok this provides confidentiality but how we can ensure authentication? This is where digital certificates play a key role.
Digital Certificates
The digital certificates help to guarantee authentication, as well as confidentiality since it associates a public key with a specific entity. It is issued by a CA (certificate authority), more of this later on this post.
These digital certificates are referred to as x.509 certificates, and it defines a standard defining the format of a public-key certificate. The content of a certificate contains different attributes such as the valid period, optional values, serial numbers, the CA (the issuer) for that certificate, and other relevant information.
Types of certificates
- Self-signed certificate: These certificates won’t be trusted by the browsers of external users, but internal systems may be configured to trust the internal CA, saving the expense of obtaining certificates from a third-party CA.
- Root certificate: the top-level certificate for their entire PKI.
- Personal certificate: Identifies a person and includes a digitally signed version of the person’s name, organization, and public key
Certificate formats
- Distinguished encoding rules (DER)
- Privacy enhanced mail (PEM)
- Personal information exchange (PFX): Commonly in windows systems
- .cer
Remember the PKI is based on a trust model which is Hierarchical, Mesh, web-of-trust. in which everyone trusts everyone, a friend of a friend is someone to trust A = B and B= C therefore A=C. And this is important to understand due to the Certificate chaining: To validate a certificate, the browser verifies the identity of the intermediate CA(s) first and then traces the path of trust back to a known root CA, verifying the identity of each link in the chain of trust.
Certificate of Authority (CA)
The CA manages certificates from issuing, revoking, and distribution. These neutral organizations offer notarization services for digital certificates. To obtain a digital certificate from a reputable CA, you must prove your identity to the satisfaction of the CA, and once confirmed the public key is stored in a directory that is available to anyone that wants to verify your certificate. Some examples of CA are VeriSign, DigiCert. This is also known as the Root CA.
- Offline CA: Certificate authorities must carefully protect their own private keys to preserve their trust relationships. To do this, they often use an offline CA to protect their root certificate, this offline CA is disconnected from networks and powered down until it is needed. The offline CA uses the root certificate to create subordinate intermediate CAs that serves as the online CAs used to issue certificates on a routine basis.
Intermediate CA
Transfer trust between different CAs. The purpose of creating and using intermediate Cas is primarily for security. They can register their own certificates, if this one is vulnerable it will only affect the certificate belonging to him. So the root CA will remain secure since it is usually turned off after the Intermediate CA servers are live!
Registration authority (RA)
Here is where new certificates are created, but not where they are signed. It verifies the information, payment, and all the data to generate a valid certificate. You can also send to them your own created public key instead of relying on the third-party CA to create both keys. It is important that only the Registrant can revoke the certificate, if they do no longer work for the company, you must revoke those certs and create a new one. There are some specific validations that can be done when deciding if there is a certificate that can be issued or not:
- Domain validation (DV): Simply verifies that the certificate subject has control of the domain name.
- Extended validation (EV): A higher level of assurance and the CA takes steps to verify that the certificate owner is a legitimate business before issuing the certificate.
When everything was okay, then there is a Certificate signing request (CSR): in which the public key of your certificate is sent to the CA to generate the Certificate with X.509 standard, BUT after validating the identity.
Validation Authority (VA)
The VA provides validation of PKI certificates. If we are going to visit a website, the browser will look to this VA and check for the certificate validation services that can include access to Certificate Revocation Lists (CRL), Online Certificate Status Protocol (OCSP), and CA chain certificate downloads.
Certificate revocation list (CRL)
It is the place where each CA put a list of revoked certificates this should be posted in a public directory. There are different reasons in which a certificate might be revoked, for example:
- Certificate expiration: The expiration date was met
- Certificate revocation: which is permanent, due to a compromised private key, company name changes, the key owner does no longer works for the company, etc.
- Suspended certificates: To put the certificate on “hold”
Online Certificate Status Protocol (OCSP)
Checks the state of the certificate, it asks (the browser) and the OCSP responder will reply if it is valid or invalid. For example, it will check if the certificate is not in the CRL.
The Certificate request and validation process
It might be hard to explain this without a video, but I’ve enumerated each of the steps.
1- The User wants to generate a new certificate, so it shares the contact info, payment, and locally created public key to the RA (Registration Authority).
2- The registration authority will take that info and perform the proper validation and call the CA (root or intermediate) to issue the certificate if correct.
3- Then the CA will share the proper certificate to the user
4- Now the user wants to add this brand new certificate to its page.
5- When someone accesses the page, the browser will call the Validation Authority
6- Then the VA will check the OSCP in the CA
7- And finally confirm if the certificate is valid or not.
Recovery Agent (We lost the key, what can we do now?)
The person who created the certificate needs to access the key recovery server, normally it is an in-house CA implementation. And you will be requested for some Key Recovery Information (KRI) such as:
- The proof that the request is from an authorized agent
- Name of the key owner
- Time key was created
- Issuing CA server
If we lost the whole access, the current certificate must be revoked and a new one must be created.
In this article I showed a little bit more in detail how the PKI and certificate process works, this is key if you are trying to get a cybersecurity position as a software engineer / professional services role. I hope you liked it!
