Security certificates and the methods used by websites to show that they are secure enough for users to trust are notoriously complex. To shed a little light on this, I’m going to explain how PKI certificate validation works.
PKI (Public Key Infrastructure) describes a method of asserting the identity and validity of a person (or entity) that you have not previously met or interacted with through the use of certificates containing identifying information and public keys (these certificates are more properly called X.509 certificates). PKI accomplishes this by defining a central authority who is mutually trusted by all users of the system. The following logical diagram shows how this works for a scheme where I am presenting my credentials to a user to setup a trusted communication path between us.
Simple PKI Exchange
As shown in the diagram above, the burden of figuring out whether or not a certificate can be trusted ultimately falls on the end user. The user is responsible for going through the step of verifying a certificate with a Certificate Authority to figure out if the certificate presented to him is valid. Ultimately, it is the software used by the user (mostly web browsers) that perform this validation.
Before describing the certificate validation process, let’s spend a few moments first describing what a X.509 certificate contains. In short, a certificate contains information identifying the owner of the certificate, an identifier of the central authority that issued the certificate, a unique serial number, a validity date range, and other optional fields that indicate how the certificate can be used. In addition to this information, a X.509 certificate contains information needed to verify the integrity of the certificate such as a public key that is owned by the certificate owner and a field describing the hash and encryption functions used to create the digital signature of the certificate. The digital signature is an encrypted one way hash of the certificate contents. This signature is created using the private key of either the certificate owner or, for certificates issued by a Certificate Authority, the private key of the Certificate Authority.
Certificate validation, described in RFC 5280, is notoriously complex due to issues of backwards compatibility with older X.509 standards, overloading the meaning of fields contained in certificates, and other technical issues. That being said, it is still easy to describe the overall process used by end user software to perform certificate validation.
The first step of validating a certificate is to first verify the certificate’s integrity. This is done by first creating a one way hash of the certificate contents (using the hash algorithm indicated in the certificate). This hash is stored temporarily in memory. Next, the digital signature embedded in the certificate is decrypted using the public key included in the certificate (or, for CA issued certificates using the public key from the CA root certificate). The decrypted digital signature (which is again a hash of the certificate contents) is then compared to the hash that was computed locally. If the hashes match, then the user knows that the certificate has not been altered since it was created.
Next, the certificate is checked to ensure that it has not expired. This is done by verifying that the current time falls within the validity dates included in the certificate. Next, the certificate usage fields are checked to ensure that the certificate is being used for the purpose it was intended (via the keyUsage field). For example, if the keyUsage field of a certificate is set to cRLSign but the certificate is presented by a bank website, the certificate is not being used as intended and will be rejected. Finally (and probably most importantly), the certificate is checked to see that it has been issued by a trusted certificate authority.
This last step bears more discussion as it is the validation step that is most important in trusting a certificate. An important field embedded in a X.509 certificate is the issuer field. The issuer field lists the name of a certificate authority which has vouched for the validity of the certificate. Recall the step where the integrity checks are performed. The user must decrypt the digital signature using a public key. Instead of using the public key embedded in the certificate, the user looks at the issuer field to identify a Certificate Authority certificate (called a root certificate) that contains the public key that should be used to verify the certificate. The root certificates are stored locally on the user’s computer, so the software searches through this list to fetch the correct root certificate. Once the root certificate has been found, the public key from the root certificate is used to decrypt the digital signature in the certificate being validated. If the signature is validated, the user knows that the owner of the root certificate (the Certificate Authority), has signed the certificate being presented and therefore vouches for the contents of the certificate.
At this point, the only remaining step is to see if the certificate has been revoked by the Certificate Authority (due to a possible compromise of the certificate or of the Certificate Authority itself). Since the list of root certificates that are stored on user’s computers are not frequently updated (the list is usually selected by the OS or browser vendor), there must be a way for the software to dynamically query the Certificate Authority to check if there is a problem with the certificate. This is accomplished using 2 different techniques: certificate revocation lists (CRLs) and an online check called Online Certificate Status Protocol (OCSP).
CRLs are lists that are periodically issued by a CA that contains a list of certificate serial numbers that have been deemed to be invalid by the CA. The CRL also contains a date range indicating when the CRL should be considered expired and a new list should be obtained. Browser software is expected to regularly download the CRLs for all root certificates that it has knowledge of. When using CRLs, the final check for a certificate’s validity is to verify that the certificate’s serial number does not appear in the latest CRL for the CA.
OCSP is a protocol that is used by browser software to query a CA dynamically for the revocation status of a certificate. The query request contains the serial number of the certificate being checked as well hashes of the issuer name and public key. The request is sent to a OCSP server operated by the CA. The response will either indicate that the certificate is valid, revoked, or is unknown. When using OCSP, the final check for a certificate’s validity is to verify that the CA’s OCSCP server reports back that the certificate is ‘good’.
In summary, the certificate validation process is complex and resource intensive. The PKIX community has recognized this as becoming more of a problem with the prevelance of mobile devices that have limited processing resources. A solution that is being proposed is a mechanism to offload the responsibility of performing all of the certificate validation steps to a centralized server that is trusted by users. This mechanism is called Server-Based Certificate Validation Protocol defined in RFC 5055. In a future post, I’ll examine more about SCVP and discuss different use cases for how it can be deployed to provide security in mobile wireless networks.