X.509 Public Key Certificates
From the author of
From the author of
From the author of
X.509 Public Key Certificates
One of the most versatile tools for network security is public-key cryptography. In this scheme, a user has two keys: a private key, known only to the user, and a public key, which is publicly available to other users. Public-key cryptography has two main uses: key distribution and authentication.
Key distribution. A user encrypts a message with a conventional key, such as a DES key, and then encrypts the DES key with the public key of the recipient and attaches that to the message. The recipient uses the matching private key to recover the DES key, and then decrypts the message.
Authentication. Public-key cryptography provides for a device called the digital signature. A user creates a message and then generates a digest (or fingerprint) of the message. Next, the user encrypts the digest with his or her private key to form the signature. The recipient uses the sender's public key to decrypt the signature and matches it against the fingerprint of the incoming message to assure authenticity.
In the first case (key distribution), the message is secure because only the recipient can recover the DES key. In the second case, the message is authentic, because only the sender could have generated the signature that can be verified with the sender's public key.
Although public-key cryptography is virtually unbreakable given the proper algorithm and sufficient key length, there is one vulnerability: How do you know that someone else's public key is valid? For example, suppose George generates a public/private key pair and publishes the public key with a label indicating that this key is Bob's. George is now in a position to impersonate Bob. George can send out messages purportedly from Bob but signed with George's private key. A recipient would erroneously verify that the message came from Bob. If George intercepts a message for Bob that includes a conventional key encrypted with the fraudulent public key, George will be able to decrypt the message.
The solution to this problem is the public-key certificate. In essence, a certificate consists of a public key plus the user ID of the key owner, with the whole block signed by a trusted third party. Typically, the third party is a certificate authority (CA) that's trusted by the user community, such as a government agency or a financial institution. A user presents his or her public key to the authority in a secure manner, and obtains a certificate. The user then publishes the certificate. Anyone needing this user's public key can obtain the certificate and verify that it's valid by way of the attached trusted signature. Figure 1 illustrates the process.
){kind=link}
Figure 1 Public-key certificate use.
The key steps can be summarized as follows:
The user software (client) creates a pair of keys: one public and one private.
The client prepares an unsigned certificate that includes the user ID and the user's public key.
The user provides the unsigned certificate to a certificate authority (CA) in some secure manner. This might require a face-to-face meeting or the use of registered mail.
The CA creates a signature with these steps:
The CA uses a hash function to calculate the hash code of the unsigned certificate. A hash function maps a variable-length data block or message into a fixed-length value called a hash code. Examples of hash functions are MD5 and SHA.
The CA encrypts the hash code with the CA's private key.
The CA attaches the signature to the unsigned certificate to create a signed certificate, and returns the signed certificate to the client.
The client provides the signed certificate to any other user as necessary.
The recipient verifies that the certificate is valid with these steps:
The user calculates the hash code of the certificate (not including the signature).
The user decrypts the signature using the CA's public key.
The user compares the results of (a) and (b). If they match, the certificate is valid.
One scheme has become universally accepted for formatting public-key certificates: the X.509 standard. X.509 certificates are used in most network security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME, which is a secure email standard.
An X.509 certificate includes the following elements:
Version: Differentiates among successive versions of the certificate format; the default is version 1. If the Initiator Unique Identifier or Subject Unique Identifier are present, the value must be version 2. If one or more extensions are present, the version must be version 3.
Serial number: An integer value, unique within the issuing CA, that is unambiguously associated with this certificate.
Signature algorithm identifier: The algorithm used to sign the certificate, together with any associated parameters. Because this information is repeated in the Signature field at the end of the certificate, this field has little or no utility.
Issuer name: X.500 name of the CA that created and signed this certificate.
Period of validity: Consists of two dates: the first date and last date on which the certificate is valid.
Subject name: The name of the user to whom this certificate refers. That is, this certificate certifies the public key of the subject who holds the corresponding private key.
Subject's public-key information: The public key of the subject, plus an identifier of the algorithm for which this key is to be used, together with any associated parameters.
Issuer unique identifier: An optional bit string field used to identify uniquely the issuing CA in the event the X.500 name has been reused for different entities.
Subject unique identifier: An optional bit string field used to identify uniquely the subject in the event the X.500 name has been reused for different entities.
Extensions: A set of one or more extension fields. Extensions were added in version 3 and are discussed later in this article.
Signature: Covers all of the other fields of the certificate; it contains the digest (fingerprint) of the other fields, encrypted with the CA's private key. This field includes the signature algorithm identifier.
The unique identifier fields were added in version 2 to handle the possible reuse of subject and/or issuer names over time. The extensions field was added in X.509v3 to provide more flexibility and to convey information needed in special circumstances.
In addition, X.509 provides a format for use in revoking a key before it expires. This enables a user to cancel a key at any time. The user might do this if he or she thinks the key has been compromised or because of an upgrade in the user's software that requires generation of a new key.