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?

Figure #1. Asymmetric Encryption

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

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.

Figure #2. Inside a container

Types of certificates

  • 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

  • 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)

  • 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

Registration authority (RA)

  • 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)

Certificate revocation list (CRL)

  • 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)

The Certificate request and validation process

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 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!

--

--

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josué Carvajal

Sr. Security software engineer working in the DevSecOps area. CompTIA Sec+, C|EH