The 6 Components of PKI

Quick Definition: Public Key Infrastructure (PKI) confirms identity by proving ownership of a private key. This can be used to verify someone sending or receiving data is who they claim to be.

At a high level, understanding public key infrastructure (PKI) can be confusing. However, breaking it down into components and exploring each makes it easier to understand. Many of these components build on and reuse some of the basic components, so they may start sounding familiar faster than you think!

How Does PKI Work? 

When talking about public key encryption, we're referring to something called asymmetric cryptography. This is where anyone with the public key can encrypt the data, but only the person, process, or system with the private key can decrypt it.

Implementing PKI entails having a public and private key pair to make this work. If we wanted to receive an encrypted message from someone, we would disseminate our public key or make it easily accessible so they could use it to encrypt the message. We then have our secured private key to decrypt the message. To reply, we use their public key to encrypt the message, and the cycle repeats with them decrypting the message with their private key.

With this in mind, let's go through the six components of public key encryption, which is beneficial for both IT pros and non-technical people to understand.

1. Self-Signed Key

There are two main ways of generating the public key/signing it. One method is using a certificate authority or CA. The other way is to self-sign. This typically refers to all certificates not signed by a CA. They are usually signed when needed by the system or application in question, although some are signed "from the factory" well in advance.

A self-signed key is usually the starting point due to the ease of generation and cost — which is free. TLS/encryption is very important; many services come by default with a pre-installed SSL certificate. Quite a few barriers prevent a public CA from issuing these certificates from the factory, so they start with a self-signed certificate generated on the first run. 

Later on, many system administrators may opt to replace them with CA-signed certificates. The main disadvantage of a self-signed certificate is they are not trusted by default, so if it's used permanently, the other end will need to trust it on a one-off basis. 

2. Private Keys

Private keys earned their name because they must be kept private and only shared when necessary. Strict access control should be maintained. If someone gains access to a private key, they could decrypt the encrypted data it protects.

As such, it is important not to keep extra copies of private keys lying around. If you do, you risk them becoming compromised. If a private key ever becomes compromised, a new one should be generated — and the public key or certificate revoked so it cannot be used again.

3. Public Keys

Public keys are just that, public. These are meant to be shared so that others can encrypt data that you or your systems will decrypt at some point. It’s akin to a mailing address. You want people to be able to send you mail so that you can receive it and have it delivered to your mailbox. In this analogy, the private key is comparable to a locked mailbox. The mail carrier can deliver mail to it — but you are the only person with a key to retrieve it.

You may get advertisements or unintended mail once too many people know your address, but it’s a minor annoyance and not a security issue. The same holds true for sharing your public key with too many entities.

4. Hashing

Hashing is a common technique to protect data such as passwords or verify the contents of a file have not changed. When we talk about encryption, it is usually a two-way process. One end encrypts the data, and the other end decrypts it. With hashing, it is a one-way process. We do not need to decrypt or dehash. We can simply compare the hashes.

In the password example, the password is stored as a hash. This means if the password file is ever stolen, those passwords cannot be reversed to their original text — good luck guessing the password, since it’s a one-way process.

Salting a hash is used to protect against dictionary mappings of original text to hash based on various hashing mechanisms. Salting a hash is a technical term for slightly modifying the hash with random data so that the output is unique and protects against dictionary attacks.

5. Digital Signatures

Analog signatures consisted simply of a name, typically using cursive letters. The idea was that the average person could not easily reproduce a signature unless they were highly trained in forging signatures.

Digital signatures are not much different. They are just a digital form of a unique and difficult-to-reproduce method of verifying the authenticity of an electronic document. In today's world, PKI is the framework used to achieve that.

Someone with a private key can digitally sign something. The receiver of the document will have access to the public key to help authenticate and verify that signature. Faking a digital signature is much more difficult than an analog one.

6. Message Digest

A message digest uses a one-way hashing function to create a fixed-length output. The fixed length nature of this is very important, so no matter the size of the source content, the digest is always the same length and easy to process. There are a few message digests; one of the most well-known is MD5 or Message Digest 5. There are other iterations, such as MD2 and MD5. MD5 is relatively insecure, so others in the SHA2 family are more common.

These come in handy to validate source content quickly. These digests are made publicly available. Many open-source projects allow you to download an image file and provide the digest to compare it for integrity and authenticity. If you perform the same message digest procedure on the downloaded file and get the same results, then you can be fairly certain that version is identical.

Because the output is a fixed and shortened length, there is a slim possibility of a collision. This is where a different source input produces the same output, but this is extremely hard to come by and does not happen by accident. For a large downloaded file, it is nearly impossible to create a collision. It also doesn't happen by accident of corrupted data or small changes in the file.

Final Thoughts on PKIs

In this post, we walked through the six core components of PKI. We also broke down some of the essentials of asymmetric encryption and explored how it is used to keep our data safe. 

Today, some level of security is a must, and it’s essential for Linux system administrators to be conscious of the various techniques at play so that they are properly implemented. Technology is only half of the battle against bad actors wishing to steal data maliciously. The other half of the battle is limiting human error when implementing these technologies. With a greater understanding of encryption, quite a bit of human error can be eliminated.

Want to learn more about PKI? Check out this ‘Certificates and the PKI’ training by Keith Barker.