Trust Anchor Certificates in PKI

Question

I'm trying to figure out how trust anchors play a part in the PKI. I understand that it's the root of the certificate chain and is used to validate if a certificate is trusted or not. How does it validate a certificate? (eg. how does it use a public key and the certificate chain to validate a certificate?)

Answer 1

A certificate binds an identity to a public key.

Suppose you get a digitally signed email from me. If you validate the signature with a public key in your possession, then as long as you trust that people are keeping private keys private, you know that email came from someone who had the private key corresponding to that public key.

If you know for sure that the public key you have is mine (e.g. because I handed it to you personally) then that's all you need to know. The problem is you don't always know that. Anyone can create a key pair and sending the public key all over the internet falsely claiming to be me, or set up a web server falsely claiming to be StackOverflow, or whatever else. You could find out Google's phone number from an independent source and call them up to confirm you've got the right key, but if you had to do this every time you wanted to make a secure TLS connection then e-commerce would be considerably more inefficient than it is now.

One solution is to get hold of a certificate. This contains a public key and identity information (e.g. name and address, domain name, email address) that is digitally signed by a certificate authority. If you validate the signature in the certificate with the certificate authority's public key, then you know that someone who has access to the certificate authority's private key was happy to sign a certificate stating that they agree that that identity goes along with that public key. If you trust that the certificate authority is not to do that unless it's taken reasonable steps to verify that that's true (e.g. by making sure they see the individual's personal identity documents, and verifying that that individual has the private key corresponding to the public key that's going to appear in the certificate) then you can trust that you have the right key for the right individual.

But even if you have that trust, this just pushes the problem one step up the chain, because to validate the certificate in the signature with the certificate authority's public key, you first need to be sure that you have the right public key for that certificate authority. So you might get a certificate for that certificate authority, and find that it's been issued by a different certificate authority, and so on.

You obviously can't validate an infinite chain of certificates, so at some point this all has to stop. Eventually you have to verify that you have the right public key for the top-level certificate authority without relying on another certificate to do so, and this is your trust anchor.

So suppose you have a certificate for me, and you see that it's signed by ABC Certificate Authority, a certificate authority that you've never heard of. You get the certificate for ABC and use the public key in it to verify the signature on my certificate, and this proves to you that ABC Certificate Authority really did issue my certificate.

Then you look at ABC Certificate Authority's certificate, and you see that it's signed by DEF Certificate Authority, a certificate authority that you do trust and for which you already have a self-signed certificate, or trust anchor. You use the public key in DEF's certificate to validate the signature in ABC's certificate, and this proves to you that DEF really did issue that certificate for ABC.

To be sure that my certificate is valid, you therefore need to do a few things and make a few assumptions:

1. You need to get and trust a (self-signed) certificate for DEF Certificate Authority, which is your trust anchor. In most cases your browser and/or operating system will come pre-loaded with a bunch of CA certificates that the manufacturer has decided to trust, and you'll just blindly trust the manufacturer's judgment on that, but you can take your own steps to validate that trust yourself if you want to.

2. You need to have confidence that DEF is a legitimate and trustworthy certificate authority that's going to keep its private key secure and isn't going to issue certificates to anybody unless it has good reason to do so. Again, you'll most likely trust the manufacturer on this one, but most CAs undergo regular audits of their certificate issuance processes and controls, so if you're concerned you could get hold of the last audit report for that particular CA, for example. Note that doing this requires that you trust the auditor's judgment, so whichever way you go, at some point you have to trust somebody just because they're trustworthy.

3. You need to have confidence that DEF wouldn't issue an intermediate CA certificate to ABC Certificate Authority unless it had good reason to believe that ABC was also a legitimate and trustworthy certificate authority that's going to keep its private key secure and not issue certificates without a good reason. Here you don't trust ABC directly - you trust it because DEF trusts it, and you trust DEF.

This same logic applies if there are more than one intermediate CA certificates in the chain between the trust anchor and the end-user certificate - you're effectively trusting every intermediate CA in the chain on the grounds that the preceding CA in the chain wouldn't have issued them their CA certificate unless it was satisfied they were a trustworthy CA and unless it had validated that the public key in the intermediate CA certificate really did belong to that intermediate CA. By validating the signature in each intermediate CA certificate with the public key of the CA immediately before it in the chain, you demonstrate that the preceding CA really did issue that certificate. Since you explicitly trust the root CA, then if your trust anchor is found to be at the bottom of that chain then you've built an implicit chain of trust that gives you confidence that the end-user certificate you were originally interested in is good.

Ultimately it's all based on the idea that you just explicitly trust a handful of well-known root CAs, and then you can implicitly trust any of the billions of other identities on the internet if you can find a chain of valid certificates going back to one of those roots that you explicitly trust and if you're willing to accept the notion that every intermediate CA in that chain is trustworthy on that basis.

The reality is that certificate authorities are usually very careful about issuing intermediate CA certificates, and when issuing them to third party organizations often restrict them, so that an intermediate CA certificate issued to ACME Inc may only be used to issue certificates for ACME Inc employees, or to issue certificates only for domains that end with .acme.com, for example.

Answer 2

Trust relationship, trust chain, and trust anchor

A trust anchor has to do with how a trust is established during a secure transaction, as when going to a secure website, for example. When a website presents a certificate to you, how do you know you can trust this certificate? Well, because it's signed by another certificate which belongs to an entity you trust as a Certificate Authority (CA). (More on signatures and verification below.) But how can you trust the CA certificate? Because it was signed by yet another certificate belonging an entity you trust. You can repeat the steps of asking the same question about this entity and getting the same answer about yet another signer, until you get to a certificate which was not signed by another certificate. In fact, it's a self-signed certificate. This is called the root certificate. So, how do you know to trust THIS certificate? The answer is you just do, usually because it's bundled with your browser or other software when you install it or you just accept that you trust this cert. This set of related certificates with the CA certificate, signed by another certificate, signed by another certificate . . . signed by the root certificate, is called your trust chain and the root certificate is the trust anchor because it's trust is not derived from another certificate; it's just accepted as being trusted, whereas all the other certificates directly or indirectly derive their trust from the trust anchor.

What is a digital signature and how is it verified?

Asymmetric Keys -- There are a pair of digital encryption keys associated with digital certificates. This pair consists of a public and a private key which have a special relationship to each other. Something encrypted by a public key can only be decrypted by the private key and vice versa. "Asymmetric" refers to the fact that if one is used for encryption, the other must be used for decryption as opposed to a single key being used for both encryption and decryption. The private key, as the name implies, is kept private by the entity to which the certificate is issued, but the public key is available to anybody and in fact, it's included with the publicly available certificate. An Asymmetric key pair makes digital signatures possible as well as PKI in general.

Hash (Digest) -- Another concept in understanding a digital signature is a hash or a digest. A hash function takes data of an arbitrary size as its input and produces a fixed size representation of this data as its output. This output is known as a hash or a digest of the data. A sophisticated hash algorithm, such as MD5, produces a hash value which has the following properties:

• Given the same data and same hash function, the product is always the same hash value every time.
• Two different sets of data will almost never produce the same hash. In fact, even if there is a small change to the data, the two hash values will be completely different from each other.
• Not pertinent to this discussion, but as a general note, the original data cannot be derived from the hash. For this reason, a hash is sometimes also known as a one-way encryption.

Creating and verifying signatures -- A signature can be created by taking a hash of a document such as a certificate and then encrypting the hash using the signer's private key. So, a signature is just an encrypted hash. A Certificate Authority (CA) creates a digital signature for a PKI certificate using the CA certificate's private key. The signature is always included with the PKI certificate.

To verify a signature the verifying entity, such as the browser, would:

• Un-encrypt the signature on the PKI cert using the signer's public key which gives you the hash of the PKI cert
• Create another hash of the certificate
• Compare the un-encrypted signature and the hash you just created for the same certificate. If they are the same, the signature has been verified.

So, because you can un-encrypt the signature using the signer's public key, you know that it could only have been encrypted with the signer's private key, and therefore unless the private key has been compromised, the only entity who could've signed the certificate is the CA to which the signing cert belongs.

And because you created your own hash of the same data with the same hash algorithm and it matches the un-encrypted signature, you know that the signature was created from the cert you're trying to verify and that it hasn't been tampered with.

In summary, you've established this is a valid cert because it's signed by an entity you trust because that entity's certificate is signed by an entity you trust and so on, until you reach the trust anchor (the root) which you trust by acceptance.

Hope this answers both your questions.