Certificate Authorities

A certificate authority (CA) is any entity or service that issues certificates . CAs act as guarantors of the binding between the public key and the owner's identity information that is contained in the certificates it issues.

When using PKI for commercial communications with outside organizations, many companies will outsource this service to a commercial CA such as VeriSign. The price varies depending on encryption strength and the level of service that you purchase.

As described previously, a certificate is a public key that is digitally signed and packaged for use in a PKI. Certificates provide the mechanism for establishing trust in a relationship between a public key and the owner of the corresponding private key.

A certificate will package a public key with a set of attributes relating to the key holder. For example, a certificate might contain the key holder's name , domain, and an expiration date.

To Trust or Not to Trust

When an authority issues a digital certificate, it is vouching for its accuracy. By issuing a certificate, the authority is testifying that the public key corresponds to the appropriate key holder. Thus, it is crucial that you trust the issuer of a certificate before you accept it.

To trust a CA, you must likewise have a certificate that attests to the identity of the CA, and the binding between the CA and the CA's public key. However, this might require you to transitively verify the CA's certificate through a series of certificates ultimately linked to a central certificate that is known to be trusted; this central authority is called a trusted root certificate . Thus, the system relies on a chain of trust known as a certificate chain .

As you will see later, the sanctity of the root certificate must remain inviolate, or the entire structure will come tumbling down. Because of the hierarchical nature of CAs, if a trusted root certificate is hacked, every certificate on chains leading to the root might be compromised.

X.509 v3 Certificate Standard

One example of an industry-standard certificate format is X.509 version 3. X.509 specifies the certificate format for information about the person or entity to which the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate. Subject information might include the entity's name, the public key, the public key algorithm, and an optional unique subject ID. Standard extensions for version 3 certificates accommodate information related to key identifiers, key usage, certificate policy, alternate names and attributes, certification path constraints, and enhancements for certificate revocation, including revocation reasons and CRL partitioning by CA renewal.

Certificate Format

The standard format of X.509 certificates specifies the following components :

• Version ” This specifies to which version of the standard (such as version 3) the certificate conforms.

• Serial Number ” Each certificate has a unique identification number.

• Signature ” The digital signature of the CA that proves authenticity.

• Issuer ” The name of the issuing CA.

• Validity ” The start date and expiration date of the certificate.

• Subject ” The certificate vouches for the pubic key of this user (Subject).

• Subject's Public Key Information ” The value of the owner's public key.

• Issuer Unique Identifier ” Another optional value to specify the unique owner.

• Extensions ” Allows the certificate to be updated without requiring a new version of the standard.

Revocation

Certificates are normally issued with an expected validity period. However, certain circumstances might cause a certificate to become invalid prior to its expiration date. For example, if there is a known compromise of a corresponding private key, the CA would have a need to revoke the certificate.

The X.509 standard provides for this revocation. This requires that each CA periodically issue a signed data structure called a certificate revocation list (CRL). The CRL is a time-stamped "hotlist" of invalid or stolen certificates that have been revoked. The revoked certificate's serial number is used to identify it in the CRL.

CAs issue new CRLs on a regular basis, which might be hourly, daily, or weekly. One advantage of this revocation method is that CRLs can be distributed through the same channels as the certificates themselves . However, one limitation of this method is that the "hotlist" of revoked certificates is only as current as the last periodic CRL issued by the CA.

PKI Weaknesses

Although PKI provides a strong framework for authentication, like any technology it is vulnerable to hackers. It is a mistake to think that PKI is a panacea. As always, it is important to combine PKI with other layers of defense in your security policy. In this section, we will review some of the ways that PKI can be hacked. By understanding these weaknesses and how to defend against them, you will be able to implement PKI with greater confidence.

An example of a vulnerability in one implementation of PKI occurred in March 2001. VeriSign informed Microsoft that two VeriSign digital certificates had been compromised by social engineering, and that they posed a spoofing vulnerability. In this case, VeriSign had issued Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. Because the certificates were issued with the name "Microsoft Corporation," an attacker would be able to sign executable content using keys that prove it to be from a trusted Microsoft source. For example, the patch you thought was signed by Microsoft could really be a virus signed with the hacker's fraudulent certificate.

Such certificates could also be used to sign ActiveX controls, Office macros, and other executable content. ActiveX controls and Office macros are particularly dangerous, because they can be delivered either though HTML-enabled email or directly through a Web page. The scripts could cause harm automatically, because a script can automatically open Word documents and ActiveX controls unless the user has implemented safeguards.

As discussed previously, in situations like this, the bogus certificates should have been placed immediately on a Certificate Revocation List (CRL). However, VeriSign's code-signing certificates did not specify a CRL Distribution Point (CDP), so a client would not be able to find and use the VeriSign CRL. Because of this, Microsoft issued a patch that included a CRL containing the two certificates. In addition, the Microsoft patch allowed clients to use a CRL on the local machine, instead of a CDP.

In addition to this example, several observers have pointed out potential weaknesses in PKI. For example, Richard Forno, former Chief Security Officer at Network Associates, has shown how incomplete PKI implementations can give online shoppers a false sense of security. According to Forno, although PKI ensures that the customer's initial transmission of information along the Internet is encrypted, the data might subsequently be decrypted and stored in clear text on the vendor's server. Thus a hacker can bypass the strength of PKI if he can access the clear text database. In fact, rogue employees could easily sniff the data as it travels on the wire from within the corporate network.

Thus, when implementing PKI it is important to consider network security from a holistic perspective. Fred Cohen sketched a list of potential vulnerabilities in his seminal paper "50 Ways to Defeat PKI." Most of these attacks involve basic social engineering, denial of service, or cryptographic weakness exploitation. Nevertheless, when taken as a whole, this list demonstrates that PKI is not infallible.