The Lure of X.509

A major benefit of certificates is that they are based on public-key technology. One of the problems with Kerberos is that the principals and the Kerberos server must share a secret key. No such requirement exists for the X.509 approach to authentication. Public-key cryptography takes advantage of the relationship between the public key and private key. Because the keys can be used for complementary cryptographic operations, entities in the network do not have to share a secret key to prove identity. An example will help clarify how this works.

Let P_x be the public key of user X and S_x represent the secret key of the pair. To verify the identity of user X, Y chooses a random nonce N value and encrypts it with P_x. Y then transmits {N}P_x to X. To prove identity X decrypts {N}P_x using S_x and transmits this value N back to Y. Only X who secretly knows the mathematical inverse key S_x for the public key P_x could have successfully decrypted the challenge. As a final twist, if two-way authentication is required, Y can be challenged to prove knowledge of S_y in a similar fashion. To improve the protocol X could encrypt N with the public key of Y before sending the response. Even this change is not sufficient for a complete protocol, because an attacker between X and Y can still modify the messages in transit. More detailed protocols that also provide message integrity are covered in Chapter 4, “Traditional Network Security Approaches.”

To see how public-key cryptography can be further utilized for establishing secure network communications, consider that the nonce value N can become the session key between X and Y. Not only is authentication of the entities accomplished, but they also now share a secret key for encrypting exchanged messages. Another consequence of the inverse relationship between the key pairs is that Y can ask X to digitally sign some message M with the secret key S_x. At a future time, it can be shown, by decrypting the digital signature {M}S_x with P_x to obtain M, that only X could have provided the signature. To be precise, the digital signature is not computed as an encryption function as the notation {M}S_x implies. Rather, the signature is normally derived with a cryptographic hash algorithm.

Contents of an X.509 Certificate

The X.500 standard defines a naming syntax for a universal directory structure that can be used to store information about important entities in a network. An X.500 name consists of several attribute-value pairs. The syntax of a distinguished name uniquely identifying an entity, such as a user, would like something like the following:

C=US, O=IBM, OU=“Software Security”, CN=“John Doe”

Names of entities or objects are derived in a hierarchical fashion. Because the standards are international, different portions of the naming tree are assigned to various registration authorities who are responsible for further assigning subtrees to other authorities. In the example, the root of the naming tree is the attribute C representing the country. Other attributes are O for organization, OU for organizational unit, and CN for common name. Internally in a program, the representation of a distinguished name is much more complex, and like Kerberos V5, the naming is based on ASN.1 data types. For the purposes of this discussion, though, all you need to know is that each digital certificate is created for a particular entity identified by the distinguished name.

The certificate also includes the public key of its owner, an expiration value indicating when the certificate is no longer valid, a serial number, and other administrative fields. An important field appearing in the certificate is the digital signature of the Certificate Authority (CA) which issued the certificate. The signature could have been computed with any one of several cryptographic hash algorithms, so the certificate also includes information identifying which algorithm was chosen.

Certificate Authorities

Why are certificates issued by a CA? Although X.509 certificates simplify the process of distributing shared session keys and authenticating users, a trusted third-party authentication server is still needed for strict verification of identities. Certificates are designed to be public and published in a way that makes them easily accessible to other network entities. In some environments, the data store or directory used to publish certificates might be tightly controlled. Also, two users wanting to communicate over an insecure network may already trust each other and gladly exchange certificates without hesitation. However, in public networks, you should be concerned about whether a certificate is genuine. Products are readily available for creating X.509 certificates, and any user may be able to advertise a certificate claiming to be another party. Only by verifying the authenticity of the X.509 certificate can one be sure that impersonation is not a threat.

Various companies including IBM and Verisign currently offer CA services. The belief is that if a certificate is generated and signed by a respectable authority, users of the certificate can trust its authenticity. The CA generates the digital signature by using its secret key and then publishing its public key. The signature can be verified because of the relationship between the secret and public keys of the CA. The important points include the following:

•  X wanting to communicate with Y obtains Y’s X.509 certificate.

•  X verifies the authenticity of the certificate by verifying digital signature of the CA that issued it.

•  When satisfied that the signature is legitimate, X can use the contents of Y’s certificate to communicate securely.

You are not limited to having a single X.509 certificate. Indeed, you can obtain multiple certificates from different CAs and decide where to publish each one.

If the secret key for a user is compromised in some way, the CA must revoke the corresponding certificates. Each CA must maintain a certificate revocation list (CRL). Before a certificate can be employed as the basis for secure communications, it should be compared to the CRL at the CA to verify validity. Creating a usable public key infrastructure, which includes providing CAs, is a major challenge facing many companies and governments today.