What is PKI? A Public Key Infrastructure Definitive Guide

Today, organizations rely on PKI to manage security through encryption. Specifically, the most common form of encryption used today involves a public key, which anyone can use to encrypt a message, and a private key (also known as a secret key), which only one person should be able to use to decrypt those messages. These keys can be used by people, devices, and applications. 

PKI security first emerged in the 1990s to help govern encryption keys through the issuance and management of digital certificates. These PKI certificates verify the owner of a private key and the authenticity of that relationship going forward to help maintain security. The certificates are akin to a driver’s license or passport for the digital world. 

Common examples of PKI security today are SSL certificates on websites so that site visitors know they’re sending information to the intended recipient, digital signatures, and authentication for Internet of Things devices.

So how does PKI work?

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. 

Cryptographic algorithms are defined, highly complex mathematical formulas used to encrypt and decrypt messages. They are also the building blocks of PKI authentication. 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: 

• Alice wants to send a private message to Bob, so she uses Bob’s public key to generate encrypted ciphertext that only Bob’s private key can decrypt. 
• Because only Bob’s private key can decrypt the message, Alice can send it knowing that no one else can read it — not even an eavesdropper — so long as Bob is careful that no one else has his private key.
  

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: 

• Bob can send a message to Alice and encrypt a signature at the end using his private key. 
• When Alice receives the message, she can use Bob’s public key to verify two things: 
  • Bob, or someone with Bob’s private key, sent the message 
  • The message was not modified in transit, because if it does get modified the verification will fail
    

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: 

• SSH algorithms 
• SSL/TLS 

• S/MIME encrypted email 
• Code signing 
• Bitcoin/Blockchain 
• Signal private messenger 
• Digital signatures
  

Most notably, asymmetric encryption powers PKI. 

Both symmetric and asymmetric encryption have one major challenge: How do you know that the public key you received actually belongs to the person you think it does?  

Even with asymmetric encryption, the risk of the “man in the middle” exists. For example, what if someone intercepted Bob’s public key, made his own private key, and then generated a new public key for Alice? In this case, Alice would encrypt messages for Bob, the man in the middle could decrypt them, change them and then re-encrypt them and neither Alice nor Bob would be any wiser. 

PKI resolves this challenge by issuing and governing digital certificates that confirm the identity of people, devices or applications that own private keys and the corresponding public keys. In short, PKI assigns identities to keys so that recipients can accurately verify the owners. This verification gives users confidence that if they send an encrypted message to that person (or device), the intended recipient is the one who will actually read it and not anyone else who may be sitting as a “man in the middle.” 

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 issued from a trusted third party 
• Is tamper-resistant 
• Contains information that can prove its authenticity 
• Can be traced back to the issuer 
• Has an expiration date 
• Is presented to someone (or something) for validation
  

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 Department of Motor Vehicles (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. 

Certificate Authorities (CAs) are responsible for creating digital certificates and own the policies, practices, and procedures for vetting recipients and issuing the certificates. 

Specifically, the owners and operators of a CA determine: 

• Vetting methods for certificate recipients 
• Types of certificates issued 
• Parameters contained within the certificate 
• Security and operations procedures 

Once CAs make these determinations, they must formally document their policies. From there, it’s up to the consumers of certificates to decide how much trust they want to place in certificates from any given CA. 

The certificate creation process relies heavily on asymmetric encryption and works as follows: 

• A private key is created and the corresponding public key gets computed 
• The CA requests any identifying attributes of the private key owner and vets that information 
• The public key and identifying attributes get encoded into a Certificate Signing Request (CSR) 
• The CSR is signed by the key owner to prove possession of that private key 
• The issuing CA validates the request and signs the certificate with the CA’s own private key 

Anyone can use the public portion of a certificate to verify that it was actually issued by the CA by confirming who owns the private key used to sign the certificate. And, assuming they deem that CA trustworthy, they can verify that anything they send to the certificate holder will actually go to the intended recipient and that anything signed using that certificate holder’s private key was indeed signed by that person/device. 

One important part of this process to note is that the CA itself has its own private key and corresponding public key, which creates the need for CA hierarchies. 

Since each CA has a certificate of its own, layers of trust get created through CA hierarchies — in which CAs issue certificates for other CAs. However, this process is not circular, as there is ultimately a root certificate. Normally, certificates have an issuer and a subject as two separate parties, but these are the same parties for root CAs, meaning that root certificates are self-signed. As a result, people must inherently trust the root certificate authority to trust any certificates that trace back to it. 

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 particularly 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 2-4 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 seven 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. 

A CA hierarchy typically involves two tiers, following the chain of Root Certificate Authority → Subordinate Certificate Authorities → End-Entity Certificates. 

A two-tier hierarchy is absolutely necessary at a minimum because a root CA should be offline 99.9% of the time, which is a difficult standard for subordinate CAs that regularly issue certificates to meet since they need to be online to issue new certificates.  

While subordinate CAs do the best they can to protect their certificates, they carry a much higher security risk than root CAs. Unlike root CAs though, subordinate CAs do have the ability to revoke certificates, so any security breach that does happen is easier to recover from than it is for root CAs (which can’t revoke certificates). 

That said, a two-tier hierarchy is also usually sufficient for security. The more tiers that exist within a CA hierarchy, the more challenging the usability and scalability of the PKI become. This is because additional tiers increase the complexity of the policies and procedures governing the PKI.

If a subordinate CA gets compromised in any way or wants to revoke a certificate for any reason, it must publish a revocation list of any issued certificates that should not be trusted. This list is known as a Certificate Revocation List (CRL) and is critical to PKI design. 

While CAs must issue CRLs, it’s up to the discretion of certificate consumers if they check these lists and how they respond if a certificate has been revoked. Once again, this is a prime example of how digital certificates are similar to driver’s licenses since the vetting process typically depends on the need for the certificate (think about the difference between using a recently expired license to buy alcohol vs. to pass a Time Stamping Authority (TSA) checkpoint). 

In many cases, certificate consumers choose not to check CRLs because doing so slows down the authentication process. Certificate consumers can also choose how far back to go within the CA hierarchy as part of the check, keeping in mind that the further back they go, the longer the process takes. 

Although checking CRLs — and going all the way to the root CA to do so — slows down the authentication process, doing so is becoming more standard as more things go online and rely on digital certificates for security. Consider the case of web browsers. Many web browsers previously didn’t check certificates because it slowed down the browsing experience, but now these checks are commonplace as internet security becomes more important. 

Critically, the CRLs themselves have an expiration date, and if a CRL expires, every certificate issued by the CA becomes invalid. While CAs primarily focus on making sure certificates don’t expire — which is important — it’s also important they make sure CRLs don’t expire because if that happens it can take down the entire PKI. When root CAs do go online, they also check to make sure that CRLs from subordinate CAs have not expired for this reason. 

Today, every device and system that goes online  (e.g. phones, laptops, servers, operating systems) needs to interact with certificates. This widespread interaction with certificates has led to the concept of a trusted root certificate within devices and operating systems. 

For example, all Microsoft computers have a trusted root store. Any certificate that can be traced back to that trusted root store will be automatically trusted by the computer. Each device and operating system comes with a pre-set trusted root store, but machine owners can set rules to trust additional certificates or to not trust certificates that were pre-set as trusted. 

PKI is so important in today’s digital age because there are now millions of applications and connected devices that require certification. Properly authenticating and maintaining certificates for these technologies is essential to keeping our highly connected world secure. 

To fully illustrate the importance of PKI in today’s digital age, let’s track its evolution since it first came about in the mid-1990s. 

The first wave of PKI included only a small number of certificates, which had a high value and were used only in very specific cases.  

The biggest use case for PKI during this time was to issue certificates to eCommerce websites, which could then display the lock icon in the browser to give consumers the confidence they were visiting the right website and that there was a secure connection when sharing credit card information to make a purchase.  

Some large organizations rolled out PKI, but these projects typically spanned two years and millions of dollars only to result in a handful of certificates actually being issued, leaving a lot of unfulfilled potential.  

During this time, nearly all certificates got purchased from public vendors and could cost thousands of dollars. This created a revenue stream for these vendors that guaranteed they would monitor certificate expirations and alert recipients accordingly. As a result, managing PKI was relatively easy for organizations that did get anything off the ground. 

The second wave of PKI saw enterprise use cases explode and led to a set of new challenges as a result. 

The early 2000s saw the rise of the mobile workforce, when almost all employees received laptops and the ability to work remotely became commonplace. All of a sudden, employees needed to access assets outside of the office, usually through a VPN, which made authenticating devices and securing remote user access to systems more important than ever. 

In response, organizations identified PKI as the best way to authenticate their newly mobile workforces. Specifically, they began to put certificates on employee laptops (and any other devices like mobile phones) to verify that devices connecting to the VPN or accessing assets from outside the office were indeed employee devices and had the right antivirus software required to access those systems.  

During this time, enterprise-issued certificates became like corporate ID badges. Organizations could deploy their own certificates and even put SSL or TLS certificates on internal web servers to improve security by preventing plaintext passwords from flying around the network. 

While this approach to PKI allowed enterprises to solve important problems around authenticating a mobile workforce and encrypting internal systems, it also created a new set of challenges around ensuring a healthy program.  

First, organizations needed to put a lot of effort into designing robust and secure PKIs that adhered to best practices. Second, they needed to find ways to properly track their PKIs to ensure certificates didn’t expire and/or that they weren’t compromised and needed to be revoked. To stem these challenges, most organizations introduced PKI management programs led in-house by employees with relevant expertise. 

The third wave of PKI, which we’re still experiencing today, includes several new uses around the Internet of Things (IoT) and some growing pains with scaling PKI along the way. 

Today, organizations issue millions of certificates to authenticate a fully mobile, multi-device workforce. Beyond employee devices, organizations also have to manage embedded certificates in all sorts of cloud systems. Finally, the rise of the IoT has led to millions of new connected devices, each of which needs to be secured, authenticated, and able to get firmware updates. All of these connections make PKI more important than ever and have led to enormous growth in this space. 

But as PKI becomes more important and more prevalent, it also gets more challenging. Specifically, today’s connected digital world creates PKI management challenges around getting certificates where they need to go, ensuring certificates are properly vetted and mapped, and monitoring already-issued certificates.  The legacy systems that were built during the second wave are struggling to keep up – in fact, 98% of organizations today would rebuild their PKI if they could.

Overseeing, managing, and updating millions of certificates is such a big job that most organizations now rely on third-party managed service providers and specialized certificate management tools to handle their PKI. This trend is similar to the move to the cloud, as organizations shifted from owned data servers to third-party cloud computing providers. 

Engaging a managed service provider for PKI allows each organization to focus their employee’s expertise on areas directly related to their line of business (rather than operating infrastructure) and protects against turnover among PKI experts. Most importantly, it improves PKI management and security by providing access to a large team that specializes in developing and running best practice PKI programs. 

Some of the most common PKI use cases include: 

• SSL/TLS certificates to secure web browsing experiences and communications 
• Digital signatures on software 
• Restricted access to enterprise intranets and VPNs 
• Password-free Wifi access based on device ownership 
• Email and data encryption
  

One trend driving the explosion of certificates and PKI is IoT. These use cases span across industries, as any connected device — no matter how innocuous it may seem — requires security in this day and age. For instance, The Home Depot data breach first started because hackers were able to access the retailer’s point of sale system by getting onto the network posing as an unauthenticated HVAC unit. 

Some of the most compelling PKI use cases today center around the IoT. Auto manufacturers and medical device manufacturers are two prime examples of industries currently introducing PKI for IoT devices. 

The cars produced today are highly connected due to features like built-in GPS, call-for-help services like OnStar and vehicle parts that self-monitor for maintenance needs. These capabilities create a variety of connection points where things like data and software updates get passed back and forth.  

If any of these connections are insecure, the results could be catastrophic, as it would open the door for malicious parties to hack into the car to do things like gain access to sensitive data or send malware to vehicles so that they purposely harm people. As a result, it’s critical that any piece of the car that’s connected receives a digital certificate to ensure security. 

Medical devices, such as surgical robots and next-generation pacemakers, are also becoming more connected and require higher security precautions as a result. Additionally, the FDA has now mandated that any software as part of a next-generation medical device must be updateable, that way manufacturers can easily shore up inadvertent bugs and patch security issues. 

While this mandate does a lot of good in terms of making this next-generation software more advanced, it also opens up vulnerabilities by creating more points of connection for malicious parties to hack into and take control over. PKI limits these vulnerabilities by issuing certificates to the devices and any software with which they communicate so that each side can authenticate data sources to ensure they only accept data and updates from the intended source. 

PKI helps secure our digital world by protecting sensitive data and communications and verifying digital identities. And as the number of connected devices and applications explodes, this security continues to grow in importance.

For enterprises, in particular, introducing PKI is critical — but it’s also only the first step. Building and maintaining a best practice PKI program that manages millions of digital certificates isn’t easy, but that’s the challenge facing today’s enterprises. 

Ready for more information? Whether you’re first getting started with PKI or need help improving PKI program management, Keyfactor can help. Contact us and get the right advice from PKI experts.