The Role of Cryptography in Security
The past few
But perhaps the most compelling recent achievement in cryptography has been the advent of asymmetric ciphers (also known as "public key cryptography"). Before asymmetric ciphers, the sender of a message that is secured with a symmetric cipher would need to communicate the key value used to encrypt the message to the receiver via a separate secure communications channel. In 1976, Whitfield Diffie and Martin Hellman developed a method that would allow two parties to communicate over an unsecured communications channel (for example, e-mail) and derive a secret key value that would be known only to them, even if others were eavesdropping on the communication [DiffieHellman]. In 1977, Ron Rivest, Adi Shamir, and Leonard Adleman developed the RSA asymmetric cipher, where one key value is used to encrypt a message but another key value is used to decrypt the message. The technology is based on the inability to quickly factor large prime
Although cryptography has been studied for years, its value has only recentlywith the tremendous increase in the use of networkingbeen recognized. One normally
This chapter will introduce you to the following cryptographic algorithms: one-way hash functions, symmetric ciphers, asymmetric ciphers, digital signatures, and digital certificates. For more information about understanding and implementing cryptographic algorithms in Java, refer to Chapter 4.
One-Way Hash Function Algorithms
One-way hash functions are algorithms that take as input a message (any string of bytes, such as a text string, a Word document, a JPG file) and generate as output a
The purpose of a one-way hash function is to create a short digest that can be used to verify the integrity of a message. In communication protocols such as TCP/IP, message integrity is often
A cryptographically strong one-way hash function is designed in such a way that it is
Two examples of cryptographically strong one-way hash algorithms are MD5 and SHA-1. MD5 was created by Ron Rivest (of RSA fame) in 1992 [RFC1321] and produces a 128-bit hash value. SHA-1 was created by the National Institute of Standards and Technology (NIST) in 1995 [FIPS1801] and produces a 160-bit hash value. SHA-1 is slower to compute than MD5 but is
As an example of using a hash function, suppose an
Another example: Suppose two parties are communicating over a TCP/IP connection. TCP uses a CRC check on its messages, but as discussed earlier, a CRC can be defeated. So, for additional security, suppose that the two parties are using an application protocol on top of TCP that attaches an MD5 hash value at the end of each message. Suppose an attacker lies at a point in between the two communicating parties in such a way that he can change the contents of the TCP stream. Would he be able to defeat the MD5 check?
It turns out he can. The attacker simply alters the data stream, and then recalculates the MD5 hash on the new data and attaches that. The two communicating parties have no other resource against which to check the MD5 value, because the communicating data could be anything, such as an
With hash functions, as with any cryptographic algorithm, the wise developer uses a tried-and-true published algorithm instead of developing one from scratch. The tried-and-true algorithms have undergone much scrutiny, and for every MD5 and SHA-1 there are many others that have
We will discuss ciphers
Symmetric ciphers are mechanisms that transform text in order to conceal its meaning. Symmetric ciphers provide two functions: message encryption and message decryption. They are referred to as
because both the sender and the receiver must share the same key to encrypt and then decrypt the data. The encryption function takes as input a message and a key value. It then generates as output a seemingly random sequence of bytes
The purpose of a symmetric cipher is to provide message confidentiality. For example, if Alice needs to send Bob a confidential document, she could use e-mail; however, e-mail messages have about the same privacy as a postcard. To prevent the message from being disclosed to parties unknown, Alice can encrypt the message using a symmetric cipher and an appropriate key value and e-mail that. Anyone looking at the message en route to Bob will see the aforementioned seemingly random sequence of bytes instead of the confidential document. When Bob receives the encrypted message, he feeds it and the same key value used by Alice into the decrypt function of the same symmetric cipher used by Alice, which will produce the original messagethe confidential document (see Figure 2-1).
Figure 2-1. Encryption using a symmetric cipher
An example of a simple symmetric key cipher is the rotate, or Caesar, cipher. With the rotate cipher, a message is encrypted by substituting one letter at a time with a letter
However, there are plenty of published symmetric ciphers from which to choose that have held up to a great deal of scrutiny. Some examples include DES, IDEA, AES (Rijndael), Twofish, and RC2. For references to these and other symmetric ciphers, see [WeiDai01], which is also a great starting point for other cryptographic references.
With symmetric ciphers, as with any cryptographic algorithm, the wise developer uses a tried-and-true published algorithm instead of developing one from scratch. The tried-and-true algorithms have undergone much scrutiny, and for every Rijndael and Twofish, there are many others that have fallen because of vulnerabilities and weaknesses [RSA02].
Symmetric ciphers are available in two types: block ciphers and stream ciphers. Block ciphers encrypt blocks of data (blocks are typically 8 bytes or 16 bytes) at a time. Stream ciphers are relatively new and are
Asymmetric ciphers provide the same two functions as symmetric ciphers: message encryption and message decryption. There are two major differences, however. First, the key value used in message decryption is different than the key value used for message encryption. Second, asymmetric ciphers are thousands of times slower than symmetric key ciphers. But asymmetric ciphers offer a phenomenal advantage in secure communications over symmetric ciphers.
To explain this advantage, let's review the earlier example of using a symmetric cipher. Alice encrypts a message using key K and sends it to Bob. When Bob receives the encrypted message, he uses key K to decrypt the encrypted message and recover the original message. This scenario introduces the question of how Alice sends the key value used to encrypt the message to Bob. The answer is that Alice must use a separate communication channel, one that is known to be secure (that is, no one can listen in on the communication), when she sends the key value to Bob.
The requirement for a separate, secure channel for key exchanges using symmetric ciphers invites even more questions. First, if a separate, secure channel exists, why not send the original message over that? The usual answer is that the secure channel has limited bandwidth, such as a secure phone line or a trusted courier. Second, how long can Alice and Bob assume that their key value has not been compromised (that is, become known to someone other than
Key management is the single most vexing problem in using cryptography. Key management involves not only the secure distribution of key values to all communication parties, but also management of the lifetime of the keys, determination of what actions to take if a key is compromised, and so on. Alice and Bob's key management needs may not be too complicated; they could exchange a password over the phone (if they were certain that no one was listening in) or via registered mail. But suppose Alice needed to securely communicate not just with Bob but with hundreds of other people. She would need to exchange (via trusted phone or registered mail) a key value with each of these people and manage this list of keys, including keeping track of when to exchange a fresh key, handling key compromises, handling key
To make matters
The major advantage of the asymmetric cipher is that it uses two key values instead of one: one for message encryption and one for message decryption. The two keys are created during the same process and are known as a key pair. The one for message encryption is known as the public key; the one for message decryption is known as the private key. Messages encrypted with the public key can only be decrypted with its associated private key. The private key is kept secret by the owner and shared with no one. The public key, on the other hand, may be given out over an unsecured communication channel or published in a directory.
Using the earlier example of Alice needing to send Bob a confidential document via e-mail, we can show how the exchange works with an asymmetric cipher. First, Bob e-
Figure 2-2 illustrates the process of encrypting and
Figure 2-2. Encryption using an asymmetric cipher
If Bob needs to send some edits on the document back to Alice, he can do so by having Alice send him her public key; he then encrypts the edited document using Alice's public key and e-mails the secured document back to Alice. Again, the message is secure from eavesdroppers, because only Alice's private key can decrypt the message, and only Alice has her private key.
Note the very important difference between using an asymmetric cipher and a symmetric cipher: No separate, secure channel is needed for Alice and Bob to exchange a key value to be used to secure the message. This solves the major problem of key management with symmetric ciphers: getting the key value communicated to the other party. With asymmetric ciphers, the key value used to send someone a message is published for all to see. This also
Figure 2-3. Bob's public key cannot decrypt what it encrypted
Recall that one of the differences between asymmetric and symmetric ciphers is that asymmetric ciphers are much slower, up to thousands of times slower [WeiDai02]. This issue is resolved in practice by using the asymmetric cipher to communicate an ephemeral symmetric key value and then using a symmetric cipher and the ephemeral key to encrypt the actual message. The symmetric key is referred to as ephemeral (meaning to last for a brief time) because it is only used once, for that exchange. It is not
Figure 2-4 depicts using a combination of asymmetric and symmetric ciphers.
Figure 2-4. Using a combination of asymmetric and symmetric ciphers
Some examples of asymmetric ciphers are RSA, Elgamal, and ECC (elliptic-curve cryptography). RSA is by far the most popular in use today. Elgamal is another popular asymmetric cipher. It was developed in 1985 by Taher Elgamal and is based on the Diffie-Hellman key exchange, which allows two parties to communicate
Diffie-Hellman, developed by Whitfield Diffie and Martin Hellman in 1976, is considered the first asymmetric cipher, though the concept of an asymmetric cipher may have been invented in the U. K. six years earlier. Diffie-Hellman is different from RSA in that it is not an encryption method; it creates a secure numeric value that can be used as a symmetric key. In a Diffie-Hellman exchange, the sender and receiver each generate a random number (kept private) and value derived from the random number (made public). The two parties then exchange the public values. The power behind the Diffie-Hellman algorithm is its ability to generate a shared secret. Once the public values have been exchanged, each party can then use its private number and the other's public value to generate a symmetric key, known as the shared secret, which is identical to the other's. This key can then be used to encrypt data using a symmetric cipher. One advantage Diffie-Hellman has over RSA is that every time keys are exchanged, a new set of values is used. With RSA, if an attacker managed to capture your private key, they could decrypt all your future messages as well as any message exchange captured in the past. However, RSA keys can be authenticated (as with X.509 certificates), preventing man-in-the-middle attacks, to which a Diffie-Hellman exchange is susceptible.
Digital signatures are used to guarantee the integrity of the message sent to a recipient by representing the identity of the message sender. This is done by signing the message using a digital signature, which is the unique by-product of asymmetric ciphers. Although the public key of an asymmetric cipher generally performs message encryption and the private key generally
Digital signatures are the only mechanisms that make it possible to ascertain the source of a message using an asymmetric cipher. Encrypting a message with a private key is a form of digital signature. However, as we discussed before, asymmetric ciphers are quite slow. Alice could use the technique presented in the previous section of creating an ephemeral key to encrypt the message, and then encrypt the ephemeral key with her private key. But encrypting the message is a
The solution is to perform a one-way hash function on the message, and encrypt the hash value with the private key. For example, Alice wants to confirm a contract with Bob. Alice can edit the contract's
Figure 2-5 shows how a digital signature is created.
Figure 2-5. Digital signature
Figure 2-6 shows the process of verifying a digital signature.
Figure 2-6. Verifying a digital signature
Moreover, Alice cannot say that she never signed the document; she cannot refute the signature, because only she holds the private key that could have produced the digital signature. This ensures non-
A digital certificate is a document that uniquely identifies information about a party. It contains a party's public key plus other identification information that is digitally signed and issued by a trusted third party, also referred to as a Certificate Authority (CA) . A digital certificate is also known as an X.509 certificate and is commonly used to solve problems associated with key management.
As explained earlier in this chapter, the advent of asymmetric ciphers has greatly reduced the problem of key management. Instead of requiring that each party exchange a different key value with every other party with whom they wish to communicate over separate, secure communication channels, one simply exchanges public keys with the other parties or posts public keys in a directory.
However, another problem arises: How is one sure that the public key really belongs to Alice? In other words, how is the identity of the public key's owner
? Within a controlled environment, such as within a company, a central directory may have security controls that ensure that the identities of public keys'
One method to verify Alice's public key is to call Alice and ask her directly to verify her public key, but because public keys are large (typically 1024 bits, or 128 bytes), for Alice to recite her public key value would prove too cumbersome and is prone to error. Alice could also verify her public key
But suppose Bob does not know Alice
For example, assume Charlie is a third party that both Alice and Bob trust. Alice sends Charlie her public key, plus other identifying information such as her
Now, when Bob goes to Alice's Web site and wants to securely send his credit card number, Alice sends Bob her digital certificate. Bob verifies Charlie's signature on the certificate using Charlie's public key (assume Bob has already verified Charlie's public key), and if the signature is good, Bob can be assured that, according to Charlie, the public key within the certificate is associated with the identification within the certificatenamely, Alice's name, address, and Web site URL. Bob can encrypt his credit card number using the public key with confidence that only Alice can decrypt it.
Figure 2-7 illustrates how a digital certificate is used to verify Alice's identity.
Figure 2-7. Verifying an identity using a digital certificate
Suppose Mary (an adversary) decides to intercept the communication between Alice and Bob, and
Figure 2-8 shows what happens if an adversary (Mary)
Figure 2-8. Adversary (Mary) alters certificate
Verification of a digital certificate can also be a multilevel process; this is known as verifying a certificate chain . In the previous example, it was assumed that Bob had already verified Charlie's public key. Let's now assume that Bob does not know Charlie or Alice but does have in his possession the pre-verified public key of Victor, and that Charlie has obtained a digital certificate from Victor. When Bob needs to secure information being sent to Alice, Alice sends Bob not only her digital certificate signed by Charlie, but Charlie's certificate signed by Victor. Bob verifies Charlie's signature on Alice's certificate using Charlie's public key, and then verifies Victor's signature on Charlie's public key using Victor's public key. If all signatures are good, Bob can be assured that Victor vouches for Charlie and that Charlie vouches for Alice.
In practice, Victor's public key will be distributed as a certificate that was self-signed. A self-signed certificate is known as a root certificate. So in the example, there are really three certificates involved: Alice's certificate signed by Charlie, Charlie's certificate signed by Victor, and Victor's certificate, also signed by Victor. These three certificates make up the certificate chain.
Figure 2-9 shows how certificates can be chained together to verify identity.
Figure 2-9. A certificate chain
In this example, Victor acts as a CA. He is in the business of being a trusted authority who verifies an individual's identification, verifies that individual's public key, and binds them together in a document that he digitally signs. CAs play an important part in the issuance and revocation of digital certificates.
The Role of CA in Issuing Certificates
In a trusted communication using digital certificates, a CA plays the role of the entity that issues a public key certificate. The certificate is the CA's assertion that the public key contained in the certificate belongs to a specific person, associated organization, or server host. Other information
In order to trust a certificate, the relying party has to trust the root certificate in its hierarchical chain. The CA, therefore, provides the trusted root certificate, and the CA is responsible for verifying the identities (out-of-
All Web browsers that support HTTPS
The Role of CA in Revocation of Certificates
The CA is also responsible for revoking the certificates if the CA discovers that the issued certificate is falsely verified or the identified user does not
As part of the revocation process, the CA maintains the user certificate and its serial number as part of a certificate revocation list (CRL). The CRL is a list of certificates that are considered revoked, that are no longer valid, and that should not be trusted by any system or users. It is important to note that when a
Using Certificate Revocation Lists (CRL)
To verify a certificate, it is quite important to use the appropriate CRL to make sure the signer's certificate has not been revoked. CRLs are usually
Using the Online Certificate Status Protocol (OCSP)
Another alternative for verifying certificates using CA-maintained CRLs is the Online Certificate Status Protocol (OCSP) defined in RFC 2560 [RFC2560]. In this method, the CA publishes the revoked certificate lists to an OSCP-enabled directory. This could be done using a CRL or an LDAP update. The CA then maintains an OCSP responder application that will use the data in the OCSP directory to respond to a query for a particular certificate with a "good," "revoked," or "unknown" response. This allows CAs to create plug-ins for Web browsers that can automatically check for certificate revocations. Application developers can also write code to query the OSCP