4.6 Protection of cryptographic keys

Any system that uses cryptographic techniques has to deal with keys that must be protected against passive and active attacks. This is equally true for session keys that originate from a secret key cryptosystem and private keys that originate from a public key cryptosystem. If such a key is locally stored on a computer system, it is vulnerable to access and misuse by unauthorized users. In fact, file permissions alone are often not adequate for protecting cryptographic keys on most computer systems, though they are part of an overall solution. Cryptographic keys protected only by file permissions are generally vulnerable to intruders and the accidental missetting of permissions.

Encryption is an accepted solution for protecting cryptographic keys stored on removable media, such as floppy disks. The use of encryption, however, also requires access to some other key that must be protected from disclosure. Consequently, the use of encryption to protect cryptographic keys leads to a recursion, and this recursion can only be stopped by making some key derivable from otherwise available information. The recommended advice is to make this information a passphrase selected by the user . A passphrase is different from a password in that no restrictions are usually placed on its length or value. This accomplishes two useful features:

The domain from which the passphrase is chosen is limited only by the input device of the user.
The user can select an easily remembered value, such as a favorite quotation or other concatenation of easily remembered words.

The key that is used to actually encrypt and protect another key (e.g., the user s private key) is derived from the user s passphrase. A possibility to compute a random-looking hash value from a user s passphrase is to use an OWHF. Whenever the private key is needed (e.g., to decrypt an encryption key or to digitally sign a message), the user enters his or her passphrase, the cryptographic key is derived, the private key is decrypted, and then the private key is available for use. Typically, the file that is used to store the encrypted private key also includes a one-way hash value of the private key. Checking the hash value after decrypting the file contents provides a fast mechanism for determining if the correct passphrase was entered by the user. Without the hash value check, the only mechanism by which the private key s value can be checked would be to use it and see if it works. This may be computationally expensive.

If a user s private key is stored in encrypted form, the user must enter his or her passphrase to decrypt and locally use the key. From a security point of view, this is the optimal behavior. However, users quickly become irritated if they must send or receive more than a few messages during a session (because they have to reenter their passphrase multiple times). Consequently, many products include a feature that allows the passphrases to be kept in memory and users to choose usability over security. This badly hurts the overall security of the products (because the passphrases are vulnerable in memory and can be attacked accordingly ).

In summary, the combination of file permissions and passphrasederived encryption provides some nondisclosure protection for cryptographic keys (if the users choose appropriate passphrases). In addition, there are some cryptographic techniques (e.g., cryptographic camouflage as further addressed in [32]) that can be used to provide better protection for locally stored private keys. Even better protection is provided if the file containing the encrypted cryptographic key is stored on a removable media, such as a floppy disk. Best possible protection is available if the key is stored in some tamper-resistant hardware device, such as a smart card, a PCMCI card, or a USB token. Recent research and development activities also focus on the use of alternative hardware devices, such as cellular phones, personal digital assistants (e.g., Palm Pilots), or any other device that implements the Wireless Application Protocol (WAP). There is arguably no single best hardware token to store cryptographic keys. Any device the user usually carries around with him or her is a potentially good hardware token and may serve this purpose (perhaps after some modification).