When you use cryptography, you simplify
problems by relying on your ability to manage secret keys correctly;
in essence, you exchange one problem (the need to communicate
securely) for another (protecting the key), which you expect to be
simpler. For example, when you use data encryption to keep messages
confidential, you must protect your secret or private key, which
should, in principle, be simpler than arranging to meet in person or
using a secure courier service. You can simplify the problem of
authentication by using digital signatures, but these are useful only
as long as you are able to protect a private key; Bob can trust
signatures from Alice for as long as it takes Eve to guess or
otherwise acquire the private key.
The importance of managing your keys cannot be overstated; Alice and
Bob must manage theirs carefully to protect encoded messages. Eve
could undermine all of their efforts if she acquires the keys.
1. Understanding Key Complexity
You want to create keys that provide suitable
protection against attack and yet are easy to use. Choosing a key
that provides suitable protection means assessing the amount of time
that the confidential data should remain secure and selecting a key
length that would take at least this amount of time to find using
brute force. In general, the longer the key, the longer it
takes to check all of the possible key values and the more secure it
is.
It might seem as though the best approach is for Alice and Bob to
create keys that are as long as possible, to provide the greatest
level of security. The problem is that they must remember their keys,
and type them in when they want to use them; the security advantages
of a 2048-bit RSA key are obvious, but it is almost impossible to
remember. For example, the sequence below is the private key
parameter D for a 2048-bit RSA key :
56 90 E2 5B F7 FA CB 85 0C CA F5 3B 0A 25 DC 07 F2 8D 32 4F 0D 4B EB 87 4C D1 E9
90 30 09 74 40 9B BE FA B3 CB C9 C1 5D C9 9D F9 B4 34 6F 27 CA 32 A0 0B FF 84 58
E9 E7 47 4C F9 E3 33 DD DA 3A CF AE 4D DA F8 DB C5 07 97 B6 42 26 84 E8 F9 07 3C
01 E3 D3 B7 C5 60 A9 8B 85 B2 1A 93 D1 74 27 64 4C 01 74 F7 5E 58 61 B9 C9 19 33
73 43 2D F3 0C 29 43 40 98 A4 85 15 FD 50 8C 8C 42 F1 19 01
Alice will be very frustrated if she has to remember this sequence
(and the sequences for the other key parameters) and type it
correctly before she can decrypt data or sign a document; the chances
of her being able to correctly do this are slim. Alice will do what
all users do when faced with this kind of memory
problem—she will write down the password. Alice has now changed
the nature of her security; the length of time it takes Eve to
acquire the key is affected by how hard it is to steal
Alice's notepad.
By asking Alice to do the impossible, we have changed the nature of
her cryptographic security. As soon as Alice writes down the key, we
are dealing with a physical security problem. Even if Alice works in
a "secure" building, Eve knows that
it is easier to break into Alice's building and read
her notes than it is to test every possible key value. We can make
life easier for Alice and Bob by using very small key values, but
while we reduce the chance of having the keys written down, we
significantly increase the efficacy of brute force attacks.
We also need to consider the type of data that we use to create keys.
The most secure way to create a key is to use a random data
generator, which makes it harder for Eve to brute force the key
value, because all key values are equally likely. The problem with
random data is that it results in a sequence that is difficult to
remember—people are not naturally able to remember an otherwise
meaningless sequence of digits. Alice and Bob will start writing down
their keys again if we ask them to use randomly generated keys.
If we ask Alice and Bob to select their own keys, we will find that
they tend to pick words or phrases that have a personal significance.
For example, Bob might use the name of his favorite sports team, the
name of his cat, or his wife's birthday. The concern
is that Eve will be able to acquire the key quickly by testing only
key values derived from Bob's background and
preferences. There are only a limited number of sports teams, and it
does not take long to test them all.
The tension between the needs of the user and the needs to attain a
certain level of security is one of the fundamental challenges you
will face when designing systems that use cryptography. There is no
simple answer to this problem, and the most common mistake we have
seen is where software forces users to work with long and random
keys, and the employer addresses this by making writing down keys a
punishable offense. Users are incapable of remembering long data
sequences, and outlawing the natural solution just forces users to
write the keys down in secret.
One potential solution is to generate a sequence of words to create a
key that is a nonsensical phrase on the basis that users will find
this type of key easier to remember—for example,
"Blue Jazz Fish Happy Green Walking Light
Special." Though people can
remember this kind of phrase, they can only do so for a short period
and still end up writing down the phrase in the long term. Another
problem is that we have made it easier to brute force the key by
restricting the key to a set of English words; Eve can use a
dictionary to test combinations of words and do so relatively
quickly.
The most common technique is to rely on a shorter key to protect a
long cryptographic key—for example, rely on a Windows log-on
password to protect an RSA key. This approach has an obvious appeal,
because the user has to remember only one thing, based on the
assumption that it is harder to attack the user's
computer than it is to guess the key, presumably because the
computer, the network, and every other device connected to the
network are completely secure. A quick glance through most IT
security bulletins demonstrates why this is not a reasonable
assumption to make.
2. Exchanging Symmetric Algorithm Keys
We explained that agreeing
on a key for a
symmetrical algorithm was problematic—Alice and Bob need to
meet in a secure location, where they can be sure that Eve cannot
eavesdrop on their conversation. As an alternative, Alice and Bob can
use a trusted and secure courier service to send keys to one another.
Both of these approaches present Eve with an attractive line of
attack—breaking the security of the
"secure" location or bribing one of
the "trusted" couriers could be
easier than brute forcing the keys. Worse still, Alice and Bob should
change their key regularly , presenting Eve with further opportunities.
In this section, we explain how Alice and Bob can use asymmetric
algorithms to perform symmetric key exchange,
and exchange the
problem of agreeing on symmetric keys for the simpler problem of
using asymmetric keys. Figure 1 illustrates the
basic protocol for key exchange, which works as follows:
Alice asks Bob for his asymmetric public key.
Alice selects a symmetric secret key value.
Alice uses an asymmetric algorithm to encrypt the value with
Bob's public key.
Alice sends the encrypted key value to Bob.
Bob uses his asymmetric private key to decrypt the key value.
Alice and Bob use a symmetric algorithm to encrypt data using the
symmetric key value that Alice selected.
At the end of this process, Alice and Bob have decided on a new
symmetric secret key without the difficulty of arranging a secure
meeting. Eve may intercept the key exchange messages between Alice
and Bob, but she cannot decrypt the secret key value without
Bob's asymmetric secret key. In essence, Alice and
Bob have simplified their key agreement problem by relying on the
security of Bob's asymmetric key pair, and so
another aspect of cryptography becomes an issue of key security.
Using the described key exchange protocol, the exchange of symmetric
keys becomes a simple and secure process. To improve security
further, there is no reason why Alice and Bob should not create new
keys every time that they need to
exchange confidential data; such keys are called session
keys.
Alice and Bob could have encrypted all of their confidential data
using an asymmetric encryption algorithm, but such algorithms process
data very slowly compared to symmetric algorithms. This kind of key
exchange makes the best use of both kinds of
algorithm—symmetrical algorithms are fast and asymmetric
algorithms are ideally suited to encrypting the small secret key
values. Key exchange is also suitable for
"impromptu" encryption, where
someone who Bob has no prior relationship with wishes to send him
confidential data. Figure 2 illustrates this
technique, which we summarize as follows:
Eugene, who has no prior relationship with Bob, selects a symmetric
session key.
Eugene composes a confidential message and uses a symmetric algorithm
to encrypt the message with the session key.
Eugene uses an asymmetric algorithm to encrypt the session key with
Bob's public key.
Eugene sends the encrypted message data and the encrypted session key
to Bob.
Impromptu encryption allows Eugene to send confidential data to Bob
that can be decrypted using Bob's secret key only,
even though a symmetric algorithm has been used to encrypt the
message data. Not only does this technique require no arrangement
between Bob and Eugene, it also does not need Eugene to identify
himself, allowing the impromptu encryption to be used anonymously.
Bob reads the message sent to him by Eugene by following this
protocol:
Bob uses an asymmetric algorithm to decrypt the session key with his
private key.
Bob uses a symmetric algorithm to decrypt the message with the
session key.
Bob reads the decrypted message.
