Understanding Public Key Infrastructures

A certificate securely binds an identifier with a public key. We learned the use of Public Key Certificates in the previous blog. When a computer is requesting access to network resources, access is granted based on the computer’s identity. Thanks to certificates, the access control agent can detect if the identity of the requesting computer is forged or tampered with, by verifying the signature of the certificate. However, presenting a valid certificate is not enough because it is easy for anyone else to capture one and use it. The access control agent must also control if the requesting computer really knows the private key that matches the public key in the advertised certificate, with a challenge-response authentication (see blogs 1 and 2). That process completely proves the identity of the computer since the private key is never disclosed to other computers.

Now let’s tackle the enablement of trust in certificates. Certificate authorities are mutually trusted third parties that enable that trust. Certificate authorities (CA) are of two kinds: Private CAs on closed networks, and Public CAs on the internet. Public CAs make their business by establishing trust on the internet. If they happen to wrongly issue certificates, they will be distrusted and excluded from the business, so they tend to do a good job at it [1]. Private CAs are maintained by IT departments at companies. Their role is to issue certificates to companies’ assets. These CAs are necessarily trusted, by definition.

A CA is issuing certificates. The certificate issuance is part of a computer enrollment process and works as follows:

• The requester (computer to be enrolled) already possesses a public key and the corresponding private key, such as described in Blog 1
• The certificate requester generates a “CSR” aka a Certificate Signing Request. The CSR contains the requester’s claimed identity (computer name, IP address, server URL), and its public key. The CSR is “self-signed” with the requester’s private key.
• The CA makes sure of the identity of the requester (this process depends on the issuance policy)
• The CA creates a certificate from the CSR (essentially the same as the CSR’s content, with additional attributes like the CA identification and other technical information to help interpret the certificate itself)
• The CA signs the certificate with the CA’s private signing key and appends the signature to the certificate

The consumer of a certificate can now verify its validity by using the CA’s public key found in the CA certificate. If the digital signature is valid, it means that the identity and the public key were formally verified by a trusted CA. 

The below picture [2] depicts what an x.509 certificate looks like. It is a series of fields containing technical data. We can clearly see the issuer’s identity, the certificate holder’s identity, and the digital signature issued by the CA.

The same certificate [2], encoded in binary (DER) format:

Now, let’s see an example of a certificate issuance policy for web servers. When a company wants a certificate for its web server "www.server.com", it can request one from a public CA by sending a CSR to the CA. The CA will request the web server owner to deposit a one-time use token (a file containing a random value) at the root of the server. The legitimate owner of the server can do that through privileged access to the web server’s content using e.g., the File Transfer Protocol (FTP). It is assumed that a rogue player cannot do that. The CA then tries to fetch this special file from "www.server.com". In case of success, it proves that the CSR comes from the legitimate owner of the server and a certificate is issued. If not, no certificate is issued. Therefore, nobody else can claim the "www.server.com" identity.

Obviously, all computers part of a network must trust the same CA if they want to be able to mutually verify their certificates when communicating with each other. It means they must use the same CA certificate to verify each other’s certificate. In fact, a CA certificate is self-signed (actual PKIs may be a cascade of CAs certifying each other, but let’s skip that for now). So, the CA certificates have to be inherently trusted because they are not certified by a parent CA (that would be a never-ending problem: who’s certifying the parent CA?). Therefore, CA certificates must be securely installed into computers in such a way that they cannot be arbitrarily modified. On operating systems like Windows, the CA certificate store is a secure component that requires special privileges to be modified. Likewise, in an embedded device, a CA certificate must be stored in memory with strict write access control. Most of the time, the CA certificate comes pre-installed and cannot be easily modified. And the storage must be immune from malware. If a rogue CA can inject its CA certificates into computers, then it can also issue rogue identities. Computers infected by the rogue CA certificate will trust those rogue identities. For simple embedded devices, most of the time, a certificate will be generated for every single device in a controlled manufacturing environment, and stored in the device, together with the CA certificate. Once deployed, all these devices will mutually accept each other because they share the same CA and possess a certificate issued by that CA.

In conclusion, mutually trusted CAs coupled with a mutually accepted certificate issuance policy allows mutually untrusted parties to authenticate each other.

In the next blog, we will learn how to implement a secret key-based authentication algorithm and compare it with the public-key based authentication.

[1] There’s been famous examples of failures: see the story of company DigiNotar

[2] Images were generated using the open source tool ASN.1 JavaScript decoder Copyright © 2008-2023 by Lapo Luchini