Public Key Infrastructure (PKI) governs the issuance of digital certificates to protect sensitive data, provide unique digital identities for users, devices and applications and secure end-to-end communications.
PKI Defined: Summary of How PKI Works
PKI manages security through asymmetric encryption, which involves a public key that anyone (person, device or application) can use to encrypt a message and a private that only one person (or device or application) should be able to use to decrypt those messages.
PKI governs encryption keys by issuing and managing digital certificates that verify the owner of a private key. The certificates are like a driver’s license or passport for the digital world. This approach helps maintain security by protecting against a “man in the middle” that pretends to be someone else and intercepts messages, decrypts them, changes them and then re-encrypts them for the intended recipient.
Although PKI first emerged in the 1990s, it has exploded since then. PKI is more important — and complicated — than ever in today’s digital world, as millions of applications and connected devices now exist that require digital certificates to maintain the security of online communications.
Common examples of PKI today are SSL/TLS 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.
The ABCs of PKI: Defining the Top PKI Terms You Need to Know
Ready to take a deeper look into all things PKI? Click here to get The Definitive Guide to PKI, which provides an in-depth view of what PKI is, how PKI works, why PKI is so important in today’s digital age, common challenges that PKI solves and common use cases for PKI.
Introducing The Definitive Guide to PKI
Getting into a conversation about PKI can be something of an alphabet soup if you’re not familiar with the terms involved. To help you better navigate these resources, here is a full list of terms and definitions you need to know as they relate to PKI.
Symmetric Encryption
Symmetric encryption uses mathematical permutations to encrypt a plain text message. The same key is used to both encrypt and decrypt these messages. Decrypting messages is exceedingly difficult without the key, but the fact that the same key gets used for encryption and decryption creates a distribution risk, since anyone who intercepts the key during transmission can then compromise the system for secure communications.
Asymmetric Encryption
Asymmetric encryption solves the transmission risk of symmetric encryption by creating two different keys – a public key (which can be shared with anyone) to encrypt messages and a private key (which should be known only to the recipient) to decrypt messages. Asymmetric encryption also makes it possible to verify a digital identity through the use of digital signatures, in which the private key owner encrypts a “signature” with that private key, which anyone can then verify through use of the corresponding public key.
Encryption Key
An encryption key gets generated through advanced mathematical algorithms and is used to encrypt and decrypt messages in both symmetric and asymmetric encryption. For instance, asymmetric encryption today typically uses one of three popular properties to generate encryption keys: RSA, ECC and Diffie-Hellman. Each uses different algorithms, but they all rely on the same basic principles to make it so that it’s relatively easy to compute the public key from the private key but nearly impossible to compute the private key from the public key. Looking at the RSA 2048 bit algorithm as an example, it 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.
Digital Signature
A digital signature is a way to verify authenticity through the use of a unique digital identifier. Digital signatures rely on asymmetric encryption, as a private key owner can use that key to digitally sign a message. Third parties can then use the corresponding public key to verify the signature and confirm that the message was not modified in transit, which would cause the verification to fail. Digital signatures also offer non-repudiation, as signers cannot deny their signature.
Hash
A hash is akin to a digital fingerprint and is commonly used in digital signatures and to ensure that data has not been tampered with. Specifically, it is a one-way algorithm used to convert one value into another to mask information through a mathematical output. Secure hash algorithms that get used often today include SHA-1, SHA-2 (SHA-256, SHA-512) and MD5.
Digital Certificate
A digital certificate confirms the identity of people, devices or applications that own private keys and the corresponding public keys. In short, it is like a driver’s license or passport for the digital world and is often presented to someone (or something) for validation. Digital certificates contain information about an individual or entity, are issued from a trusted third party and can be traced back to that issuer. They are also tamper resistant, contain information to prove their authenticity and have an expiration date.
Certification Authority (CA)
Certification Authorities create digital certificates and own the policies, practices and procedures for vetting recipients and issuing the certificates. It’s up to the owners and operators of a CA to determine vetting methods for certificate recipients, the types of certificates they will issue, the parameters contained within each certificate and security and operations procedures. It’s then up to consumers of certificates how much trust to place in certificates from a specific CA.
Certificate Signing Request (CSR)
A Certificate Signing Request is critical to the certificate creation process. The CSR records identifying information for a person or device that owns a private key as well as information on the corresponding public key. The key owner must then sign the CSR to prove possession of that private key. Finally, the issuing CA validates the request and signs the certificate with its own private key
CA Hierarchy
CA hierarchies create layers of trust in which CAs issue certificates for other CAs. This process is not circular, as there is ultimately a root CA which issues and signs its own certificates. CA hierarchies typically have two tiers that look as follows: Root Certificate Authority → Subordinate Certificate Authorities → End-Entity Certificates. This type of hierarchy provides a sufficient level of security to ensure the validity of certificates that get issued without creating too many layers that make scalability a challenge.
Root CA
A root CA issues certificates to other CAs but also issues its own certificates (which are self-signed), as it sits at the top of a CA hierarchy. As a result, people must inherently trust the root CA to trust any certificates that trace back to it, making security for root CAs absolutely essential. In fact, there is no way to revoke a root certificate, so if a root CA is compromised, the organization needs to make that security breach public. To meet the necessary level of security, root CAs should be offline 99.9% of the time, only coming 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.
Subordinate CA or Registration Authority (RA)
A subordinate CA (also known as a Registration Authority) sits below root CAs in the CA hierarchy. These CAs regularly issue certificates, making it difficult for them to stay offline as often as root CAs. However, subordinate CAs do have the ability to revoke certificates, making it easier to recover from any security breach that does happen (as opposed to root CAs, which can’t revoke certificates).
End-Entity Certificate
An end-entity certificate sits at the bottom of the CA hierarchy and can not be used to sign any other certificates. People, applications and devices that require certificates to verify identities and communicate use end-entity certificates to do so.
Certificate Database
A certificate database houses information on all certificates issued by a CA, including who owns the certificate, when it expires and its current status. CAs must revisit their certificate database regularly to ensure validity and manage revocations.
Certificate Revocation List (CRL)
A Certificate Revocation List contains information about any certificates that have been revoked by a subordinate CA due to compromises to the certificate itself or to the overall system. CAs are required to publish CRLs, but it’s up to certificate consumers if they check these lists and how they respond if a certificate has been revoked. In many cases, certificate consumers don’t check CRLs (or don’t go all the way through the CA hierarchy in checking CRLs) because doing so slows down the authentication process as it requires downloading a list of all certificates and checking for revocation status on a specific one.
Online Certificate Status Protocol (OCSP)
Online certificate status protocol offers a faster way to check a certificate’s status compared to downloading a CRL. With OCSP, the consumer of a certificate can submit a request to the issuing CA to obtain the status of a specific certificate.
Trusted Root Certificates
Trusted root certificates are certificates that are automatically trusted by a device or operating system based on pre-set inputs. The concept of trusted root certificates came about as the use of certificates became more widespread. Since every device and system that goes online today needs to interact with certificates, trusted root certificates make certain interactions more efficient.
Trusted Root Store
A trusted root store houses all trusted root certificates within a specific device or operating system. For example, all Microsoft computers have a trusted root store. 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.
Public Key Cryptography Standards (PKCS)
Public Key Cryptography Standards promote the use of standard cryptography techniques within PKI programs. These standards are defined and published by RSA Security LLC and include techniques like PKCS 7, PKCS 10, PKCS 11 and PCKS 12, which cover things like messaging syntax and formatting for digital certificates and how private keys get stored.
