What is public key infrastructure?

Paired with public-key cryptography, digital certificates act as virtual passports—authenticating the identity and permissions of various users and entities when establishing secure end-to-end communication over public or private networks.

Encompassing elements of software, hardware, policies and procedures, PKI formalizes the process to create, distribute, manage and revoke digital certificates.

Public key infrastructure (PKI) provides protocols to validate the authenticity of the digital certificates that underscore the trust in public key cryptography systems. A cornerstone of cybersecurity, cryptography provides confidentiality, integrity, nonrepudiation and authenticity. PKI adds validity to cryptographic systems by cryptographically binding digital certificates to unique users, institutions, entities and third parties.

The following are the key components of a public key infrastructure.

The ability to establish the secure transfer of information between users, entities and devices enables ecommerce and banking platforms to collect financial information, allows Internet of Things (IoT) connected devices and establishes confidential lines of communication for secure email web servers.

To send and receive secure information over potentially vulnerable and insecure networks, cybersecurity specialists rely on data encryption to securely encrypt (scramble) and decrypt (unscramble) sensitive data.

The two primary types of data encryption are known as public key cryptography and private key cryptography.

Also known as asymmetric encryption or public key encryption, public key cryptography uses a pair of keys, a shared public key and a private key that is unique to each party. The public key is used for encryption while the private key is used for decryption. Because every user has their own private key, each key pair is unique to each user, while the public key is shared among all users.

Also known as symmetrical or secret key cryptography, private key cryptosystems use only one key for both encryption and decryption. For these types of systems to work, each user must already have access to the same secret key. Private keys might be shared either through a previously established trusted communication channel (such as a private courier or secured line) or, more practically, a secure key exchange method, such as the Diffie-Hellman key agreement. Safe and effective key management is a primary use of PKI that cannot be devalued.

Establishing secure communications over the internet is one of the most common applications for cryptography. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), use cryptographic algorithms to establish protected connections between web browsers and servers by using SSL/TLS certificates to confirm user and server identities. By establishing secure channels, these protocols ensure that data shared between a user’s browser and a website’s server remains private, and cannot be intercepted by malicious actors.

Cryptography is also used for common messaging applications like email and WhatsApp to provide end-to-end encryption (E2EE) and maintain the privacy of users’ conversations. With E2EE, only the sender and intended recipient can decrypt and read their messages, making it nearly impossible for third parties—including users’ own service providers—to access the content.

While symmetric cryptography is faster, asymmetric cryptography is often more practical and secure. In practice, both types of cryptosystems are often used together. For instance, a user might choose to encrypt a long message by using a symmetric system and then use an asymmetrical system to share the private key. While the asymmetrical system will be slower, the symmetrical key will likely be shorter and faster to decrypt than the full message.

However, both types of systems can be vulnerable to so-called man-in-the-middle (MitM) attacks, in which a malicious eavesdropper might intercept secure data during transmission.

In such an attack, a hacker or bad actor might intercept a public key, create their own private key and then replace the authentic public key with one that has been compromised. The hacker might then intercept encrypted messages sent between parties over the compromised asymmetric system, decrypt the message, read the contents, encrypt them again and forward along the now-compromised message. For the users, the effect would be the same, and the effective attack would be undetectable.

To prevent these types of attacks, public key infrastructure (PKI) uses digital certificates (also known as PKI certificates, public key certificates and X.509 certificates) to confirm the identity of people, devices and/or applications that own the private and corresponding public keys. PKI provides the framework to effectively assign authenticated ownership of cryptographic keys—ensuring that when information is sent over an asymmetric cryptosystem, only the verified and intended recipient will be able to decrypt it.

Used to establish a verifiable identity, a digital certificate contains specific information, including the following:

• The Distinguished Name (DN) of the owner

• The owner’s public key

• The date of issuance

• An expiration date

• The DN of the issuing CA

• The issuing CA’s digital signature

While all digital certificates are not alike, all valid digital certificates should:

• Contain information for establishing the identity of an individual or entity

• Be issued from a trusted and specified third-party Certificate Authority

• Be tamper-resistant

• Contain information to prove their authenticity

• Contain an expiration date

Being able to trust the validity of a digital certificate is critical for establishing a trustworthy PKI, which is why a trusted third-party Certificate Authority (CA) is crucial.

Reliable CAs vouch for the identity of certificate holders. They are responsible for creating and issuing digital certificates and the policies, practices and procedures associated with vetting recipients.

Specifically, a CA will establish the following:

• Vetting methods for certificate recipients

• The type of certificate issued

• Associated parameters with each certificate type

• Operational security procedures and requirements

A reputable CA formally documents and publishes these policies to allow users and institutions the opportunity to assess the CA’s security measures and trustworthiness. Once operational, a CA follows a set order of operations to create new digital certificates by using asymmetric cryptography. 

The following steps outline the process to create a new digital certificate:

1. A private key is created and assigned for the certificate recipient along with a corresponding public key.
2. The CA requests and vets any available identifying information for the private key owner. 
3. The public key and identifying attributes are encoded into a Certificate Signing Request (CSR).
4. The CSR is signed by the key owner to establish possession of the private key.
5. The CA validates the request and signs the digital certificate with the CA’s own private key.

By confirming who owns the private key used to sign a digital certificate, the certificate can be used to verify not only the certificate holder’s identity, but also the identity (and reputation) of the CA, and therefore the trustworthiness of the certificate itself.

To further establish trust, CAs use their own public and private keys and issue certificates to themselves (self-signed certificates) and each other. This practice requires a CA hierarchy, in which an exceptionally trustworthy CA acts as a root certificate authority, trusted to self-sign their own certificates as well as the certificates of other CAs.

Should a CA’s keys become compromised, a hacker might issue false certificates and create a massive security breach. As such, root certificate authorities mostly operate offline and under the most strict security protocols. Should a root CA or a subordinate CA become compromised, they are beholden to make the details of such a breach public and provide certificate revocation lists for any potential certificate holders or recipients.

All of this makes the security of private keys extra important for CAs. A private key falling into the wrong hands is bad in any case, but it’s devastating for CAs because then someone can issue certificates fraudulently.

Security controls and the impact of loss become even more severe as you move up the chain in a CA hierarchy because there is no way to revoke a root certificate. Should a root CA become compromised, the organization needs to make that security breach public. As a result, root CAs have the most stringent security measures.

To meet the highest security standards, root CAs should almost never be online. As a best practice, root CAs should store their private keys in NSA-grade safes within state-of-the-art data centers with 24/7 security via cameras and physical guards. All of these measures might seem extreme, but they’re necessary to protect the authenticity of a root certificate.

Although a root CA should be offline 99.9% of the time, there are certain instances where it does need to come online. Specifically, root CAs need to come online for the creation of public keys, private keys and new certificates as well as to ensure that its own key material is still legitimate and hasn’t been damaged or compromised in any way. Ideally, root CAs should run these tests about two to four times a year.

Finally, it’s important to note that root certificates do expire. Root certificates typically last for 15–20 years (compared to approximately 7 years for certificates from subordinate CAs). Introducing and building trust in a new root isn’t easy, but it’s important that these certificates do expire because the longer they run, the more vulnerable they become to security risks.