December 19, 2017
Designing a Public Key Infrastructure means managing keypairs to implement signing chains. These keypairs are the cornerstone for transport security (TLS) or code signing (software whitelisting, market restrictions). In other words, signing chains are crucial elements of both computer security and creating artificial scarcity on the Internet. So for those of you who don’t aspire to understand computer security, follow the smell of money and stick with me.
Cryptographic signing is process used to attest that the contents of a file haven’t changed since the moment-of-signing. For public-private keypairs, a signed public key is certified as a valid means of identifying services, particular servers, or other end-entities you may talk TLS with. Yeah, end-entity sounds clumsy, but just be grateful that PKI folks managed to avoid loading the word object with yet another jargon-definition.
Now let’s talk signing chains. In principal, signing chains illustrate the relationships between the holders of each keypair in the chain of trust. Typically a signing chain is a single path through a tree of other trust relationships. At the furthest edges of the tree are the leaf certificates, issued to end-entities such as servers (TLS) or whitelisted programs (code-signing). The keypair that signs a leaf certificate is generally an intermediate Certificate Authority.
These intermediate CAs are typically signed by a chain of one to two other intermediates, until you get to the root of the signing chain, which is called the Root Certificate Authority. Generally, the Root CAs are what your Operating System comes installed with so that your system trusts the leaf certificates it sees on the Internet. In other words, these Root CAs are the trust anchors that your OS uses as a reference. When your OS talks TLS, as soon as it encounters a trust anchor in a signing chain, the chain is considered valid and communications will proceed.
Since the Web PKI’s purpose is to ensure the authenticity of the services you talk to, we need to think about trust in the context of signing chains. When you visit a website, trusting a signing chain (and getting a green lock) means three things, in order of dependency:
Like taking advice from a succession of strangers, trusting a server means you trust every “authority” in this sequence. Each hop is another level of indirect trust worth thinking about for a PKI designer.
Last time, we discussed trust from the perspective of software politics and incentives. Another way to discuss trust is by talking about behavior or events that would compromise or threaten trust. This is a limited form of threat modelling. It may seem self-evident that security of your PKI depends on the security of your client and server OSes. Unfortunately, weak system security or outdated software often makes it frighteningly simple to compromise unencrypted private keys at rest, or add rogue CAs to your OS trust store as a trust anchor. Threat modelling of transport-level issues prior to solving endpoint security puts the cart before the horse. Although techniques exist for protecting key materials from the OS using hardware security modules, cross-platform standards for this protection remain immature at best, or nonexistent at worst.
Assuming your system security is implemented perfectly, PKI trust additionally hinges on the default Root CAs your software vendor manages. System updates tend to add or remove CAs from your OS trust store, and for any system on the broader Internet, if you don’t trust a broad set of CAs, you’ll get error fatigue from certificate warnings and connection failures. Basically, we blindly hope that the policies and procedures used by OS vendors to vet the controllers of CA private keys are sufficient. Oftentimes, it is not, so whenever you write software intended for use in a constrained environment, you can improve your transport-level security by maintaining a thin trust store, where only specific CAs or remote certificates that you trust are included in your trust store.
The last facet of signing chain trust to discuss is the chain validation step. Validating a signing chain means validating that each certificate in the chain is trustworthy, and not revoked by the signing authority. It will take more than one future article to discuss validating certificates, but due to how browsers implement trust, chain validation becomes a separate monster. In the ideal case, web servers include the entire chain of intermediary CAs leading to their signed server certificate, and in this case chain validation is equivalent to validating every certificate in the chain. Although web browsers wisely treat the world as non-ideal, this causes subtle problems.
When a browser is able to validate a fully formed signing chain, it tends to cache the state of a CA’s validation in an opaque, non-standardized way. I’ve seen these caches persist even when the “Clear Private Data” feature is used. So when a server presents just a leaf certificate, the browser might say the chain is valid, even though the missing cached CAs could have been revoked. If you care about the security of your users, be dogmatic about hosting your entire signing chain, up to (but not including) your root CA. Client trust stores hold their system’s trusted root CAs, so server signing chains don’t need to include them.
If you read closely about how chain validation works, you may have noticed that as a client, you have few options if you wish not to trust an intermediary CA signed by a trusted root. Again, we hope that root CAs have solid vetting practices for anyone they issue intermeidate CAs to.
Knowing the basics of signing chains, and being exposed to how they fuction in the real world, should make you deeply skeptical of how certificate validation works in practice. We’ll dive into certificate validation in the next installment of this PKI series.
Despite its issues, the Web PKI is the broadest, most visible implementation of certificates in the world. The emergent complexity of PKI just for web browsing leads me to believe that future widespread implementations of signing chain trust will rediscover many of the same threats and problems.