▶ 8.1 The Key Management Challenge
When we encrypt a file, we substitute the problem of protecting the file with the problem of protecting its key. If attackers can retrieve our secret keys, then our cryptographic measures give no protection. Keys face two attack vectors: attempts to guess a key and attempts to intercept a key. We face three key management problems:
Sharing keys with exactly the right people, no more or less
Choosing keys that attackers can’t guess
Handling keys so attackers can’t guess or intercept them
The third problem itself has several facets. First, there’s the key distribution problem: We need to share keys with others without risking security. Second, we need to store the keys safely so that attackers can’t retrieve all or part of any key. An attack that retrieves part of a key reduces the attacker’s search space for guessing that key. Finally, we need to use our keys and cryptographic mechanisms effectively. If we use the same key for too long, we increase the risk of successful cryptanalysis. If we set up a stream cipher incorrectly, we’ll use the same key stream to encrypt two or more files, and this gives a good cryptanalyst an easy job to do.
Our key management efforts start with the following questions:
■ Who are we sharing the file with?
■ Who are we protecting the file from?
The answers to those questions help us develop policies and select protections for our keys.
Cryptonets
When we share a key with two or more people, we refer to that group as being the cryptonet. Everyone within a cryptonet shares the same keys and therefore can read the same encrypted files.
A cryptonet is a classic example of Transitive Trust. We trust everyone in the cryptonet to keep the encryption key safe. We also trust all of them to protect the contents of encrypted documents. By implication, however, we also end up trusting anyone whom those people trust. Here is an example.
Bob and Alice use a shared secret key to protect Alice’s bookkeeping file. Thus, the cryptonet consists of Bob and Alice.
Alice wrote down a copy of the key, and she keeps it in her purse. When she returns to her apartment, she leaves her purse in her drawer and steps out for a moment. According to Transitive Trust, we now trust her roommate as well.
If we take an optimistic view of security, we might insist that the key is protected from potential attackers. However, this violates Least Privilege and overlooks potential risks of Transitive Trust. As we make the cryptonet larger, we increase the risk of someone leaking the key by accident. If we include people unnecessarily, we increase our risk unnecessarily.
Our keys are safest when we keep the cryptonet as small as possible; as Benjamin Franklin famously claimed, “Three may keep a secret if two of them are dead.”
Levels of Risk
We classify threats against authentication as weak, strong, and extreme. (See Section 6.1.) We use the same classification for threats against file encryption.
■ Weak threat—a person with limited skills and a mild motivation to recover the file.
■ Strong threat—a skilled person willing to invest time and money to recover the file, but not inclined to cause significant damage.
■ Extreme threat—a person with the skill or motivation to do damage, regardless of how the file is protected. This includes threats who would damage or destroy the computer, or people with the skill to circumvent other operating system protections.
For the most part, we will focus on strong threats. Weak threats are often discouraged by applying simple access restrictions. Extreme threats may manage to substitute Trojan horse software for our file encryption program, thus bypassing its protection.
Key-Sharing Procedures
After we establish who needs to use the keys, we need procedures to choose, handle, and distribute the keys safely.
■ Do we need to plan for changing the key (rekeying)? How hard will it be to change the key?
■ How long does a key last? What is its cryptoperiod?
■ Key strength questions (these must be considered together):
Should the key be a password or a passphrase?
How do we maximize the entropy contained in our key?
How should the key be protected against a strong threat?
If we write the key down, will a threat have access to it?
Should we limit ourselves to keys we can memorize?
This discussion will focus on strong threats. Weak threats will not be inclined to attack an encrypted document. Extreme threats will attack weak data encryption. When faced with stronger encryption, they look for other ways to extract the data without breaking the encryption.
8.1.1 Rekeying
We need to plan for changing the key on occasion. If we set things up perfectly and nothing goes wrong, it might make sense to leave an unchanged file in place, encrypted with the same key, for an extended period of time. However, trouble often crops up, and we must be prepared to change the key if leaked. Moreover, we make the cryptanalyst’s job easier if we use the same key to reencrypt the file after making changes.
We call the key-changing process rekeying or key rollover. Here are cases in which we should rekey:
■ We use the document regularly over a long period of time. Each time we use it, we introduce the risk of leaking the key. Pick a time for changing the key that balances convenience and safety.
At minimum, change the key whenever some other major event occurs. For example, the distribution of a major new version of the file might justify rekeying. Legitimate users will learn the new key. If copies of the old key leaked, then the attackers don’t get access to the new version.
For safety’s sake, rekey more often on larger cryptonets. A larger cryptonet poses a larger risk of disclosure. On the other hand, it is harder to distribute new keys on a larger cryptonet.
■ We suspect that the key has been leaked. We don’t want to wait and find out that the file itself has been leaked, so we should change the key immediately.
■ A person who knows the key must leave the cryptonet. For example, Kevin worked at a company that kept administrator passwords in an encrypted file, and Kevin knew the file’s key. After he quit that job, the other administrators chose a new key.
Rekeying brings up another question: How do we really change the key? Each copy of an encrypted file increases the file’s attack surface. If we change the file’s key, how do we ensure that all copies are protected with the new key? Backed-up copies of the file may still be encrypted with the previous key. Some cryptanalytic techniques work more effectively when there are multiple copies of the ciphertext encrypted with different keys.
Cryptoperiods
U.S. government standards published by NIST recommend encrypting data with a particular secret key for no more than 2 years before changing it. If we have already encrypted data with an existing key, that data doesn’t need to be reencrypted. However, we shouldn’t encrypt additional data with an “old” key.
There are other limitations to using a secret key. We will see later, for example, that we shouldn’t reuse the same key when encrypting with a stream cipher. We may want to use a passphrase as a memorable secret key, and it’s difficult to memorize numerous passphrases. Later, we will see how “key wrapping” minimizes the need to change passphrases.
Distributing New Keys
We handle encryption keys in one of three ways: We memorize them, we write them down, or we carry them on a storage device and download them as needed. The first case applies if we never make a permanent copy of the key. If we never physically make a copy of the key, then we face the lowest risk of disclosure. Instead, we face a risk of losing access to the file by forgetting the exact passphrase.
It can be challenging to distribute a passphrase without writing it down. The safest way to do it is in person; the recipient should memorize it on the spot without writing it down. In some environments, telephones may be safe enough for sharing keys. This assumes potential threats can’t tap our phones.
In the second and third cases, we have to control possession of the copied key. While it’s in our possession, we have to ensure that no one else gets a copy of the key. We share it with members of the cryptonet, but we must hide it from everyone else.
Public-Key Cryptography
Secret-key techniques provide very simple and strong mechanisms for protecting and sharing data. However, they may be impractical in some situations. Bob and Alice can use secret-key techniques to share data because they’ve already shared a sufficiently strong secret key.
What if Bob needs to share information with Alice, but he can’t arrange a shared secret ahead of time? Public-key cryptography provides the mechanism to make this possible. Our browsers routinely use public keys to produce strongly encrypted connections for financial transactions and other private business. Although the actual connections may use the AES, the keys are established using a public-key algorithm. We examine the public-key techniques in Section 8.3.
8.1.2 Using Text for Encryption Keys
In Chapter 7, we introduced file encryption programs but deferred discussion of key handling. The simplest and most obvious technique in file encryption programs is for the owner to handle the key as a block of text. FIGURE 8.1 illustrates a very simple way to do this.
FIGURE 8.1 Using a passphrase for a file encryption key.
File encryption programs typically expect a secret key, typed by the user, to be a block of text: a password or a passphrase. The encryption algorithm requires a key of a fixed size, and the passphrase might be too long or too short to fit the key size exactly.
In Figure 8.1, the program collects the passphrase in a buffer and discards extra bytes if the phrase is too long. If the phrase is too short, the program pads it with zeros. The program uses the resulting block of data as its crypto key.
A textual key is more flexible than a binary key. Cryptonet members might share a textual key verbally or in text documents. A large, random, binary key would be almost impossible to memorize, even in hexadecimal notation. Cryptonet members would have to carry it around on a small USB drive or other portable storage device; if they stored it on the hard drive with the encrypted file, an attacker could find it and easily decrypt the file.
However, a binary value always has more entropy than a similar amount of text. We want as much entropy in our encryption keys as possible. A particular key may be from 56 to 256 bits long, or longer, depending on the encryption algorithm. At 8 bits per character, that yields 7 to 32 characters or more. RC4 actually accepts a variable length key up to 128 bits long. When we use a longer key, we present the attacker with a really tough trial-and-error cracking challenge.
RC4, of course, has notorious weaknesses that make it an unlikely choice for modern security systems. If we choose a state-of-the-art cipher like AES, then our keys may be of 128, 192, or 256 bits. A fully random 128-bit AES key should take 1 billion billion (1018) years to crack, using today’s best approaches.
If we construct our 128-bit key out of a 16-character passphrase, we limit ourselves to the entropy of our written text. The average entropy of written text is about three letters per character. (See Section 6.4.) For a 16-character AES key, that gives us an entropy of 316, or 4 × 107 (40 million alternatives). We greatly increase the entropy if we create a random, 16-character string of ASCII: 9516, or 4 × 1031. Such random keys, however, are almost impossible to memorize. They are also very hard to type accurately. The entropy of a 128-bit AES key is more than 1038. We lose a lot of entropy by limiting our passphrase to a short block of readable text. Realistic passphrases should contain at least 20 letters—the longer, the better.
Taking Advantage of Longer Passphrases
Not everyone will want to use longer passphrases, but if people do, we must take advantage of the extra entropy. We need to compress the passphrase into a smaller block of bits from which we extract our encryption key. The obvious solution is to use a one-way hash function to hash the passphrase into a key-sized data value. This is shown in FIGURE 8.2.
FIGURE 8.2 Hashing a passphrase for a file encryption key.
We apply a cryptographic one-way hash function like those discussed in Section 6.2. The function serves as a building block to produce an internal key to perform the actual encryption. The internal key exists only inside the encryption process and disappears when the process is not running.
If the hash value output is too long, we discard part of the hash value and use the rest as the internal key. If the value is too short, we call the hash function a second time. We use its previous output as input. Then we concatenate the first and second hash values together to create the internal key.
This approach makes full use of the entropy in the text passphrase. Because the hash function can take arbitrarily long input texts and is indifferent to the characters used, we can use a fully punctuated sentence as a passphrase. Moreover, the one-way hash will yield a dramatically different key if we make even minor changes to punctuation or spelling. This makes it much easier to generate a long, hard-to-guess, but easy-to-remember passphrase. The only problem is that we must remember the capitalization, spelling, and punctuation exactly.
Because we hash the passphrase, we are not using the literal bits of the memorized passphrase. The program constructs this “internal key” from the hash value and uses it to perform the encryption. This is not a problem as long as the program follows a consistent procedure when creating the key for both encryption and decryption.
Software Checklist for Key Handling
Here is a checklist of requirements for key handling in file encryption software. Most of these address risks to the passphrase. This checklist provides a list of properties for the software’s key-handling procedures.
The software shall support passphrases, as well as passwords. (The following requirements shall assume that users typically use passphrases to protect encrypted files.)
The software shall allow very long passphrases, preferably a length of at least 100 bytes.
The software shall use the full length of passphrases as long as they fit within the maximum permitted length.
The software shall not take other steps to reduce the entropy of a passphrase unless so directed by the user. For example, the software shall preserve the distinction between uppercase and lowercase characters, and it shall preserve blanks and punctuation by default.
After collecting a passphrase from the user, the software shall by default store the passphrase only as long as it is needed for encryption or decryption. The software may provide an option for the user to store the passphrase in RAM for a longer period.
The software shall erase the passphrase from RAM as soon as it is no longer needed, unless overridden by the user’s choice.
The software shall not write the passphrase to the hard drive unless its storage area is also protected by strong encryption.
When the software collects a passphrase from the user, it shall by default suppress the display of the passphrase in readable characters.
The software shall have an option to permit the display of a typed passphrase in readable characters.
The software shall avoid using the same internal encryption key to encrypt multiple files. Section 8.2 examines this problem and potential solutions.
8.1.3 Key Strength
When we encrypt a file, we choose a password or passphrase as its key. The problem of selecting a strong, but memorable, key is the same as that of choosing a strong password. (See Section 6.7.4.) It should be clear that a hard-to-crack secret must consist of more than a single word. If we must limit ourselves to a password, then we should construct it of two or more separate words.
It is even safer to use a passphrase. In 1990, software engineer Daniel V. Klein’s experiments demonstrated the weakness of using individual words, and he began experiments in cracking passwords constructed of pairs of words. If we use a passphrase containing more than two or three words, the result should yield a very strong key. If we simply look at the entropy in written text, we should aim for a fully punctuated passphrase of more than 20 characters.
Most people should be able to come up with memorable phrases of 25 characters or more. However, if we need to share the phrase with others, we must choose a phrase that we can reliably share with others. There are two approaches to this:
Always write it down and share the passphrase in written form.
Choose text, capitalization, and punctuation that is easy to get right and hard to get wrong. This is a good idea even when we share the passphrase in writing. However, this reduces entropy, so it demands longer passphrases.
During World War II, the British operated an elaborate spying network in Germany. Each British agent memorized a long block of text, often a poem or a famous piece of prose, to use as an encryption key. These keys worked well for the most part, but occasionally the agent would remember the text differently than the decoders back at headquarters. This posed a serious challenge. In practice, however, those at headquarters often could deduce the mistaken text and decrypt the messages anyway.
The same problem can arise with secret passphrases. Even if the actual words are correctly conveyed, the file won’t decrypt properly if the recipient gets the capitalization or punctuation wrong.
The real trade-off between memorization and written passphrases depends on the user’s environment. If the passphrases will need to reside in an unsafe location, then they must not be written down. If the strong threat will never have access to the written passphrases, then a written list might be practical.
Operating Recommendations
Because these file encryption keys are similar to passwords and passphrases, we should, in general, follow the policy recommendations outlined for passwords in Section 6.7. Here are further recommendations based on different levels of threat.
■ Weak threats—file encryption should not be necessary.
■ Strong threats
Protect each file with a passphrase that is at least 25 characters long, including spaces.
Visually inspect the computer periodically to look for keystroke sniffers.
If possible, do not allow strong threats to have user accounts on the system containing the protected data.
■ Extreme threats—such threats may bypass the encryption by attacking the system from other directions. Protection via file encryption will probably not be effective.