Public Key Infrastructure: Architecture & Security

Introduction to PKI

The internet and many other digital systems rely upon public key infrastructure (PKI) to manage trust within a system. PKI includes a number of different parties working together to build certificates that can be used to verify the identity of their owners.

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

Start Learning

Parties in a PKI system

A PKI system has a number of different stakeholders and parties that participate in the creation of valid trustworthy certificates:

• Certificate owner: The certificate owner is the person whose identity the certificate is intended to verify (i.e., a website’s owner)
• Registration authority (RA): A registration authority processes requests for certificates, including validating the provided information and the requestor’s identity
• Certificate authority (CA): A certificate authority generates and digitally signs a user’s certificate. A CA is either an organization that a user’s computer trusts or someone that this authority has delegated power to
• Verification authority: While a user can independently verify that a particular certificate is valid, they can’t be sure that it is still active. A verification authority keeps a list of revoked certificates and responds to certificate validity verification requests

Many of these parties can be combined, such as a CA including VA functionality. However, each has a distinct role to be fulfilled.

Structure of a PKI certificate

When you visit a TLS-protected website or make another use of a digital certificate, you likely don’t implicitly trust the owner of the certificate. Digital certificates are designed to operate based upon a chain of trust leading to an organization that you (presumably) do trust.

Imagine an image above that shows how a certificate chain works. The top-left certificate is the one for the particular website that a user is visiting. It includes the name of the owner, their public key (for setting up encrypted connections or creating digital signatures) and the name and signature of the CA that issued it.

The middle certificate (and any other intermediate CAs that may exist) are structured identically to the end user certificate. The public key included in this certificate can be used to verify the authenticity of any certificates (or other data) that they sign. If the signature is valid, then it was created by someone with access to the corresponding private key.

Finally, the bottom-right certificate belongs to the root CA. It is self-signed, meaning that the signature on the certificate is verified with the public key within the certificate. The root CA is implicitly trusted by a user and/or their computer. Every computer comes with a pre-loaded set of trusted root CAs, and users can add or remove these root CAs to meet their needs.

This chain of signed certificates implements the chain of trust that is the basis for PKI systems. If a user trusts the root CA at the bottom of the certificate chain and all of the certificates signing the certificates are valid, then the end-entity certificate is valid and verifies the owner’s identity and public key. However, a user should also consult a VA to ensure that the certificate has not been revoked because revocation does not change the contents of the certificate (which the owner controls) or the validity of the signatures that it contains.

Security of a PKI system

The PKI system is designed to make it possible to trust individuals or organizations that a user has never met or communicated with previously. When visiting a new website (or one that you’ve visited a thousand times before), the certificate verifies that you are in the right place.

However, this system only works if it is secure. Two of the main security assumptions associated with PKI systems are that the chain of trust is valid and that the root CA does not misuse their powers.

Chain of trust

The nuts and bolts of a PKI system are based upon cryptography. Digital signatures are generated using hash functions and asymmetric encryption algorithms. As long as these algorithms are secure and properly deprecated when they become insecure (which doesn’t always happen promptly), then a user should be able to be confident in the authenticity of the chain of trust contained within a particular certificate.

However, this makes the assumption that each organization within this chain of trust deserves this trust. A certificate only validates the identity of a particular CA with the assumption that CAs up the chain have vetted them and verified that they will do their job properly. If a CA misuses their power to create valid but incorrect certificates (such as claiming that a Google-owned site is the real Facebook), then these certificates will appear legitimate and will be trusted by a user.

Misused root certificates

The chain of trust is designed to ensure that power and trust accurately flows down the chain of certificates. However, this makes the assumption that the organization at the root of the chain should be trusted to validate the rest of the certificates that it signs.

Root CA authority can be abused for a number of different reasons:

• Failed due diligence: Root CAs are supposed to validate the identity of an individual or organization before signing their certificate. A failure to do this properly can result in invalid or misleading certificates
• External pressures: Root CAs should be independent companies, but some are closely affiliated with governments. Governmental pressure could force a root CA to sign invalid certificates
• Stolen private keys: Asymmetric cryptography’s security relies on private key security. A stolen root CA private key could be used by the thief to sign invalid certificates

If any of these cases occurs, then the security of the PKI system is compromised. A chain of trust is only valid if the root can be trusted.

Putting trust in PKI

PKI makes it possible to create trust within the internet and other systems by creating a mechanism to transfer trust from a root CA to an end entity via cryptography. However, if the cryptography is broken or a “trusted” party misbehaves, everything falls apart.

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

Start Learning

Sources

1. K41280190: Understanding the SSL Certificate Chain, AskF5
2. 21% of Websites Still Use SHA-1. Don’t They Know It’s Broken?, Venafi
3. Apple, Google, and Mozilla block Kazakhstan's HTTPS intercepting certificate, ZDNet