Taking off with PKI

Public key infrastructure (PKI) is evolving into one of the most pervasive technologies. It is everywhere around us, often without people even realizing it. Yet, it’s a concept that few people understand. To many people who have heard of it, PKI retains an almost magical aura. People barely dare to touch it, even the certificates they enroll for their own use. However, this reluctance is unnecessary.

While running a PKI requires diligence and attention to detail, the basic concepts are not overly complicated. This blog post will explore the basic concepts behind PKI.

 

The two components of PKI: Public and private keys

The engine in a PKI consists of the public and private keys, which hold the entire concept together. Their origin comes from the age-old problem of sending encrypted messages. If a message is intercepted but the interceptor does not have the key, the message is (supposedly) unreadable. However, if the key is sent by the same means as the message, what stops the interceptor from getting their hands on both?

In the 1970s, a method was invented through which keys could be exchanged without compromising the messages. While the mathematics are somewhat complicated, the applied technology is easy to understand. The math allows for two related calculations that reverse each other using a pair of keys.[1] One of these keys you keep to yourself — called the private key. The other one is given out to the public and appropriately. called the public key.

The beauty of this system is that what you encrypt with the public key cannot be decrypted even if you have the public key. As long as the private key stays safe, only the holder of the private key can decrypt the message. Likewise, if you encrypt a message with the private key, you can only decrypt it with the public key. We’ll explain later why this is important.

 

Understanding the applications of public and private keys

Public and private keys have three practical uses:

1. Encryption: If you wish to encrypt a message for another recipient, you use the recipient’s public key, ensuring the confidentiality of the message and that only they can decrypt and read the message.
2. Signing: If you want to ensure the authenticity and integrity of a message, you sign it. First, you must follow a series of standard processes to ensure that the changes made to the message do not go undetected and the exact time is locked in. Then, you encrypt the resulting outcome with your private key. Everyone can read the message and verify the signature, but only you could have made the signature — guaranteeing the message is authentic and unaltered.
   
3. Authentication: Authentication is another way of using the principle of signing. The computer asking for authentication sends a challenge, which is then signed using the private key of the authenticating entity (normally a user or another computer). Because the signature is correct, the authentication attempt is valid.

 

Digital certificates: How to know who you can really trust

The applications above are very helpful, but they have two major drawbacks. While an interceptor cannot use the public key to read encrypted messages or alter signed messages, they could potentially stop the exchanged public keys from ever arriving, instead sending both the sender and the recipient their own public keys. As long as they intercept every message, re-encrypt and re-sign them, the interceptor would become a man in the middle and neither the sender nor the recipient would ever know the difference. Moreover, a system based only on exchanging keys is cumbersome. You must decide whether to trust the public key of every single person you communicate with.

The solution to this is digital certificates. Every entity sends its public key and identity details to a central certificate authority that everyone trusts. The certificate authority validates that the public key belongs to the entity, compiles both the identity details and the public key into one document and signs it as a certificate with its own private key. This way, you don’t have to verify every public key yourself. You also don’t have to worry if the key you received is the right one. You merely need to trust the certificate authority, and the certificates it signs are then implicitly trusted.

Often in PKIs this process is repeated where the certificate authority has its own certificate signed by an even more strictly guarded Root Certificate Authority (CA). This Root CA also has a certificate, but since all signatures must end somewhere, it signs itself. Trusting the Root CA implicitly results in trusting the underlying certificate authorities, which in turn implies trusting all the certificates and public keys they have issued.

 

Validity, lifetime and revocation: Everything has its limits

Nothing stays secure forever. Eventually, the private key may be broken or stolen. PKI has two mechanisms to handle such situations.

First of all, the certificate authority sets a finite lifetime for every certificate it issues. So, even if someone manages to compromise the private key, they can’t use it forever.

It may also be necessary to render a certificate invalid before its intended expiration. To do so, the CA keeps a blacklist of certificates it has revoked or declared invalid. Every certificate it issues states the location of public repositories where this blacklist — or Certificate Revocation List — is stored and can be downloaded. Most entities won’t trust a certificate unless they can confirm it is not on the Certificate Revocation List. This list also has a finite lifetime, so entities must download fresh ones regularly and stay up to date on the most recently revoked certificates.

 

Subscribers and relying parties: Knowing the key players

Finally, we must explain two final terms that one will often come across, especially when managing teams using certificates. two distinct kinds of entities exist when it comes to using certificates:

• First, one entity has the private key, has requested and received the certificate, and is using the combination to decrypt messages intended for them, sign messages and authenticate to services. In PKI terms, we call this entity the subscriber.
• The other entity wants to validate that the signature or authentication is correct and that the certificate is still valid. This entity is known as the relying party.

In many organizations, it’s common practice for these entities to find themselves in different (often multiple) silos within the organization. The term “PKI” is somewhat ambiguous. Sometimes, it includes the subscribers and relying parties. Other times, it just means the certificate authorities and the immediately related infrastructure, like the certificate revocation list repositories. Either way, to use a PKI effectively, multiple teams of subscribers and relying parties must work together in harmony.

 

Final thoughts

In this blog post, we have covered the basic concepts and terms related to PKI. There are many more concepts, such as OCSP, AIA, whitelisting, blacklisting and SCEP — enough for an entire dictionary of its own. However, understanding the fundamental concepts outlined above should help us deal more effectively with a PKI at a high level.

 

---

References
[1] The detailed mathematical concepts are beyond the scope of this blog post. There are several good articles available for anyone interested. As an example, see https://www.nku.edu/~christensen/the%20mathematics%20of%20the%20RSA%20cryptosystem.pdf

Acknowledgements

Special thanks to Vasco Gomes for technical proofreading, Jon Luebke, Sachin Kulkarni, and Laurence Begou for text reviews, and Mathilde Cadrouil for all the support organizing the posting of this article.