Represents a system designed to manage public-key encryption and digital certiﬁcates.
A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.
In cryptography, a PKI is an arrangement that binds public keys with respective identities of entities (like people and organizations). The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA). Depending on the assurance level of the binding, this may be carried out by an automated process or under human supervision.
To understand how PKI works, it’s important to go back to the basics that govern encryption in the first place. With that in mind, let’s dive into cryptographic algorithms and digital certificates.
Building Blocks of Public Key Cryptography
Cryptographic algorithms are defined, highly complex mathematical formulas used to encrypt and decrypt messages. They are also the building blocks of PKI. These algorithms range in complexity and the earliest ones pre-date modern technology.
Symmetric encryption is a simple cryptographic algorithm by today’s standards, however, it was once considered state of the art. In fact, the German army used it to send private communications during World War II. The movie The Imitation Game actually does quite a good job of explaining how symmetric encryption works and the role it played during the war.
With symmetric encryption, a message that gets typed in plain text goes through mathematical permutations to become encrypted. The encrypted message is difficult to break because the same plain text letter does not always come out the same in the encrypted message. For example, the message “HHH” would not encrypt to three of the same characters.
To both encrypt and decrypt the message, you need the same key, hence the name symmetric encryption. While decrypting messages is exceedingly difficult without the key, the fact that the same key must be used to encrypt and decrypt the message carries significant risk. That’s because if the distribution channel used to share the key gets compromised, the whole system for secure messages is broken.
Asymmetric encryption, or asymmetrical cryptography, solves the exchange problem that plagued symmetric encryption. It does so by creating two different cryptographic keys (hence the name asymmetric encryption) — a private key and a public key.
With asymmetric encryption, a message still goes through mathematical permutations to become encrypted but requires a private key (which should be known only to the recipient) to decrypt and a public key (which can be shared with anyone) to encrypt a message.
Here’s how this works in action:
Asymmetric encryption also makes it possible to take other actions that are harder to do with symmetric encryption, like digital signatures, which work as follows:
In both of these examples, Alice has not generated her own key. Just with a public key exchange, Alice can send encrypted messages to Bob and verify documents that Bob has signed. Importantly, these actions are only one-way. To reverse the actions so Bob can send private messages to Alice and verify her signature, Alice would have to generate her own private key and share the corresponding public key.
Today, there are three popular mathematical properties used to generate private and public keys: RSA, ECC, and Diffie-Hellman. Each uses different algorithms to generate encryption keys but they all rely on the same basic principles as far as the relationship between the public key and private key.
Let’s look at the RSA 2048 bit algorithm as an example. This algorithm randomly generates two prime numbers that are each 1024 bits long and then multiplies them together. The answer to that equation is the public key, while the two prime numbers that created the answer are the private key.
This approach works because it’s extremely difficult to reverse the computation when it involves two prime numbers of that size, making it relatively easy to compute the public key from the private key but nearly impossible to compute the private key from the public key.
Both symmetric and asymmetric encryption get used often today.
Asymmetric encryption is much slower than symmetric encryption, so the two are often used in tandem. For example, someone may encrypt a message using symmetric encryption and then send the key to decrypt the message using asymmetric encryption (which speeds up the decryption process since the key is much smaller than the entire message).
Today, asymmetric encryption powers things like:
Signal private messenger
S/MIME encrypted email
Most notably, asymmetric encryption powers PKI.
PKI governs encryption keys by issuing and managing digital certificates. Digital certificates are also called X.509 certificates and PKI certificates.
However, you refer to them, a digital certificate has these qualities:
Is an electronic equivalent of a driver's license or passport
Contains information about an individual or entity
Is presented to someone (or something) for validation
Contains information that can prove its authenticity
Is tamper resistant
Can be traced back to the issuer
Has an expiration date
Is issued from a trusted third party
The easiest way to understand how PKI governs digital certificates to verify identities is to think of it as a digital DMV. Much like the DMV, PKI introduces a trusted third party to make decisions about assigning identities to a digital certificate. And much like driver’s licenses, digital certificates are difficult to spoof, include information that identifies the owner and have an expiration date.
Finally, it’s up to the person verifying the digital certificate to determine what that verification process should be and how carefully the certificate should be vetted based on the use case.