The 6 Components of PKI

At a high level, it can be confusing to understand public key infrastructure (PKI), however, breaking it down into components makes it more palatable. Many of these components build on and reuse some of the more basic or elementary components.

When we talk about public key encryption we are actually 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.

PKI entails having a public and private key pair to make this all 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 that can be used to decrypt the message. When we want to reply, we use their public key to encrypt the message and the cycle repeats with them decrypting the message with their private key.

All 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

In order to understand self-signed, it is important to understand it is not the only method of creating a key pair. 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 on the spot 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 without requiring a CA. The cost typically works out well too with it being free. TLS/encryption is very important; many services come by default with an SSL certificate pre-installed. There are quite a few barriers that would prevent a public CA from issuing these certificates from the factory, so they are initially started off with a self-signed certificate that is generated on first run or boot. Later on, many system administrators may opt to replace them with CA signed certificates.

The main disadvantage of a self-signed certificate, though, is that it is not trusted by default so if it will be used permanently the other end will need to trust it on a one off basis. Any Linux Administrator or System Administrator that had to go into a default web interface for a management tool, likely has run into a self-signed certificate where the browser did not trust it and you had to push through, allowing the untrusted certificate to get to the content you needed.

2.Private Keys

Private keys earned their name because they need to be kept private and only shared when absolutely necessary. Strict access control over them should be maintained. If someone were to gain access to any private keys they could potentially decrypt the encrypted data it protects.

As such, it is important you do not have extra copies of private keys laying 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 that 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 it gets delivered into your mailbox. In this analogy, the private key is comparable to a locked mailbox. The mailman can deliver mail to it — but you are the only person with a key to retrieve it.

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

4. Hashing

Hashing is a very 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 is so that if the password file is ever stolen, those passwords cannot be reversed to their original text and therefore good luck guessing the password since it’s a one way process.

To protect against dictionary mappings of original text to hash based on various hashing mechanisms the idea of salt or salting a hash comes into play. Salting a hash is just a technical term for slightly modifying the hash with random data so that the output is unique and protects against these types of dictionary attacks.

5. Digital signatures

Prior to the digital world, analog signatures existed. They consisted simply of a name typically using cursive letters. The idea was that unless someone was highly trained in forging signatures, the average person cannot easily reproduce a signature other than the originator.

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

They have the ability for someone with a private key to digitally sign something. The receiver of the document will have access to the public key to help authenticate and verify that signature and it is much more difficult to fake a digital signature than an analog signature.

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 that 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 and one of the most well known is MD5 or Message Digest 5. There are other iterations such as MD2 and MD5. MD5 is relatively deemed insecure so others have come along that use the SHA2 family.

Where these come in handy are validating the source content quickly. These digests are made publicly available. Many open source projects that allow you to download an image file, and provide the digest so that you can 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 your version is identical.

Because the output is a fixed and shortened length, there is the remote possibility that we get what's called 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 near impossible to create one of these collisions. It also doesn't happen by accident of corrupted data or small changes in the file.

Final Words

In this post, we walked through the six major components of PKI. We also broke down some of the essentials of asymmetric encryption and walked through how it is used today to keep our data safe. In the early days of computing and the internet, security was not as much of a concern.

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