Common Challenges in Cryptography

In applying security to a computing system such as a Web application server, the security designer must overcome challenges involved with using the security tools discussed earlier in this chapter. When implementing cryptographic algorithms such as symmetric ciphers, the designer must study the tool and avoid its weaknesses. For example, some ciphers have a set of "weak" keys, which are key values that lend themselves to easier compromise by an intelligent adversary. Challenges the security designer faces when using security solutions include proper random number generation for key values, key management, certificate revocation issues, trust models, and threat modeling.

Random Number Generation

In 1995, Ian Goldberg and David Wagner published a paper [Goldberg01] describing how they could eavesdrop on a secured SSL session with Netscape version 1.2 and recover the communication being secured in a matter of minutes. Netscape had implemented SSL and the associated cryptographic tools correctly, except for one thing: the key values they were creating were easily determined because the random number generation technique they were using was predictable.

Bad random numbers can kill security. When one creates a key value for use with a cipher that is meant only for one session, the key value must be as random as possible. In Netscape's case, they were deriving the random number from the current daytime clock value, process id, and parent process id. An intelligent adversary needed only to go through all the possible combinations before hitting on the right millisecond that created the key value; even if the clock's resolution was down to the millisecond, the key could be recovered within minutes. Netscape finally fixed the problem by looking at more sources of entropy, or true randomness, to create their key values. Ideas for creating random numbers are offered by Eastlake [RFC1750].

Many modern operating systems support cryptographically strong pseudo-random number generators. Bruce Schneier's Yarrow [Schneier03] offers a platform-independent method of producing strong pseudo-random numbers; many UNIX-style systems use Yarrow to support the device /dev/random, from which an indefinite string of random bytes can be read.

Key Management

As mentioned earlier in this chapter, key management is the single most vexing problem in cryptography use. To secure data via encryption, one must exchange a key value to be used with the encryption process. If the communicating parties only have a publicly accessible communications link, exchanging this key value securely is impossible.

Fortunately, asymmetric ciphers, also known as public key encryption, resolve this issue by providing a mechanism for exchanging key values for use with a symmetric cipher. However, with asymmetric ciphers, a new problem arises: how to verify the identities of the communicating parties. This is resolved through trust models, most notably digital certificates. X.509 digital certificates offer a hierarchical trust model, and X.509 is the most popular protocol due to its use in SSL for securing Web transactions. But other types of trust models exist, each with their own advantages and disadvantages.

Certificate Revocation Issues

A major stumbling block in the area of key management within a public key infrastructure (PKI) is that a digital certificate can be valid one day and then become invalid the next day. For example, say a certificate authority such as VeriSign signs a digital certificate for a company that plans to use SSL to secure transactions over the Web. Suppose the next day, VeriSign discovers that although due diligence was performed in verifying the company's information, somehow the information turned out to be falsified. The certificate in and of itself indicates that it is valid; it has a valid signature from a trusted certificate authority, and it has not expiredyet it is an invalid certificate. This is a revoked certificate.

To revoke a certificate, a certificate authority must add the certificate to a published certificate revocation list (CRL). The CRL is a digitally signed list that contains an identifier for the revoked certificate and the date and time at which it was revoked. This list is analogous to a list that a store owner may have of bad customers from whom no checks should be accepted and to whom no credit should be extended. So when verifying a certificate, after the signatures of the certificate chain (for X.509 certificates) have all checked out, the CRL should be consulted to check if the certificate has been revoked.

Unfortunately, checking certificate revocation has not been built into many of the security protocols that use digital certificates, including SSL [SSL01], which is widely used to secure Web pages. Browsers such as Mozilla, Firefox, and Microsoft's Internet Explorer have implemented solutions to check CRLs for server certificates, but often this check is optional and turned off by default. Another problem is that CRLs are updated periodically, so that one may check a certificate that has in fact been revoked but just has not yet been put on the list. However, Cisco and VeriSign have developed a certificate protocol that includes checking certificate revocations; it is currently a proposed IETF standard [SCEP01].

Trust Models

A trust model is the mechanism used by a security architecture to verify the identity of an entity and its associated data, such as name, public key, and so on. An example of a trust model is the X.509 certificate structure discussed earlier in this chapter. Identities are vouched for through a hierarchical structure that culminates at the root certificate, which is self-signed by a well-known certificate authority (see Figure 2-13). Other trust models exist, including the PGP trust model.

Figure 2-13. Different trust models

PGP (Pretty Good Privacy) uses a "web of trust" model instead of a hierarchical trust model. Developed by Phil Zimmerman in 1991, PGP is a program that uses a combination of the RSA asymmetric cipher and the IDEA symmetric cipher to secure e-mail, specifically. PGP supports the concept of a digital certificate, but a PGP certificate may contain many signatures, unlike the X.509 certificate that contains exactly one signature. As with X.509 certificates, a signature represents an entity that vouches for the identity and the associated public key within the certificate. With X.509 certificates, this entity is a single authority; with PGP, this entity can be any person or organization. The information in the PGP certificate can be verified using any one of the many signatures, and the verifier can choose which signature is trusted the most.

For example, suppose Alice creates a PGP key pair. She then creates a digital certificate containing her public key and identification information, typically her name and e-mail address. Alice then immediately signs the certificate herself; this is to protect the information within the certificate from being altered before being signed by anyone else. Alice then calls her good friends Andy, Aaron, and Albert, tells them her public key fingerprint, and asks them to sign her public key certificate, which she mails to each of them. All three verify Alice's public key by checking the fingerprint, and then each signs her public key certificate. Figure 2-14 illustrates a PGP certificate with multiple signatures.

Figure 2-14. PGP certificate with multiple signatures

If Bob wants to send a secure e-mail to Alice, he looks up Alice's public key certificate. Bob then checks the signatures to see if any of them are from entities that he trusts. If Bob knows Andy and has verified Andy's public key, and if he trusts Andy to correctly verify someone else's public key certificate, then if Andy's signature checks out on Alice's public key certificate, Bob can be assured that he indeed has Alice's public key, and can use it to send Alice secure e-mail.

Furthermore, even if Bob does not trust any of the signatures on Alice's public key certificate, he may still be able to verify Alice's information. Bob can look up the certificates of Alice's signatories and check if any of their certificates are signed by someone he trusts. So, if Bob looks up Aaron's certificate, which is signed by Bart, whom Bob knows and trusts, then Bob can verify Aaron's certificate with Bart's signature, and then in turn verify Alice's certificate with Aaron's signature. This can be seen in Figure 2-15.

Figure 2-15. Indirect verification of a PGP certificate

As with the X.509 certificate structure, the PGP web of trust assumes that the signer of a certificate performs due diligence in verifying the information contained in the certificate. However, X.509 offers a controlled hierarchy of signatories; in the case where the information in an X.509 certificate is incorrect or falsified, the signatory of the certificate can be pinpointed and held responsible for repercussions (for example, VeriSign could have legal action taken against it if it signed a certificate for a bogus company's secure Web site). The PGP web of trust model is more "loose" in that no organizational or legal relationship between signatories and certificate holders is required. There is no concept of a certificate authority in the PGP web of trust. Because of this, PGP allows the user to label the "trust level" of a public key certificate. Thus, referring to the earlier scenario, if Bob really doesn't know Andy all that well, he may label Alice's public key as "marginal." Obviously, for business purposes, a key must be trusted or not trusted, which explains the widespread use of X.509 certificates for situations like e-commerce. Newer versions of PGP now support use of X.509 certificates. This allows better interoperability for security providers.