Key Storage in Software

Secret keys need to be protected from exposure to parties other than the intended ‘owners.’ It is therefore very important that they are stored securely.

Avoiding key storage

The best solution would be to not store cryptographic keys anywhere and generate them on the fly whenever required. This is possible in some applications. Since the same key must be generated on the fly every time we need to use it, we require a deterministic key generator to generate the key. Recall that deterministic generators require a seed, so we will require this seed to be consistently used each time we generate the key. But the seed also needs to be kept secure, so where do we store the seed?

For most applications using this technique, the seed is stored inside the human brain in the form of a passphrase or strong password. This is precisely the technique adopted by some cryptographic software to protect private keys, which are encrypted using a key encrypting key and then stored.

The user generates a passphrase, which they are required to remember. The passphrase is used to derive the key encrypting key on the fly. The key encrypting key is then used to decrypt the encrypted private key.

The obvious drawback of this process is that the security of the stored key is now dependent on the security of the passphrase used to derive the key encrypting key. However, this is a pragmatic solution that represents a balance between security and usability appropriate for many applications.

But it is not always possible to avoid storing a key. For example:

• Suppose a symmetric key is being used to secure communication between Alice and Bob, who are in different locations. Alice and Bob may generate the key precisely when they require it locally in some applications. However, in many other applications, the key will need to be stored somewhere, at least for a short while (for example, if Alice and Bob are both issued with the key in advance by a mutually trusted third party).

• Many uses of cryptography require long-term access to certain keys. For example, keys used for secure data storage may need to be stored for a long time to facilitate future access to the protected data.

• Public-key pairs are expensive to generate. Generating them precisely when they are needed is inefficient. In many cases, this is impossible since the devices on which the private keys reside (for example, a smartcard) may have no user interface. Thus, private keys almost always need to be securely stored.

Storing keys in software

One option for storing a cryptographic key is to embed the key into the software. As mentioned, conducting any part of the cryptographic process in software comes with inherent risks. However, storing keys in software is much cheaper than storing keys in hardware, so, as is often the case, the security risks have to be traded off against the cost benefits.

Storing keys in the clear

The cheapest and the riskiest approach is to store keys in the clear in software. In other words, regard keys as pieces of data stored on a hard drive as unprotected data. Crazy though this sounds, this is often done. One common approach is to try to ‘hide’ the keys somewhere in the software. This is ‘security by obscurity,’ which is always dangerous since it relies on the person who hid the keys being ‘smarter’ than any attacker. In addition, there are two fundamental problems with hiding cryptographic keys in software:

1. The developer who designs the software will know where the keys are, so at least one potential attacker is out there who knows where to look for the keys.

2. Assuming the hidden keys are specific to different versions (users) of the software, an attacker who obtains two versions of the software could compare them. Any locations where differences are noted are potential locations of material relating to a key.

Even if these fundamental problems do not apply to a specific application, the underlying concerns about unprotected keys being stored in software are sufficiently serious that this approach is normally best avoided. Indeed, software storage of keys in the clear is explicitly forbidden by many key management systems and standards.

Storing keys using cryptography

Fortunately, we are already very familiar with a technique that can be employed to protect data residing in software on a computer system. We can encrypt it! While this might seem the obvious thing to do, it has only moved the goalposts, not removed them. To encrypt a key, we require a key encrypting key. So, where do we store the key encrypting key? If it’s a public key, where do we store the corresponding private key?

There are only four options:

• Encrypt it with yet another key: So where do we store this key?

• Generate it on the fly: This is a fairly common approach discussed and is often utilized for applications in which a hardware-based solution is not viable.

• Store it in hardware: This is probably the most common approach, but obviously, it requires access to a suitable hardware device. The key encrypting key remains on the hardware device, which is also where all encryption and decryption using this key is performed.

• Store it in component form: A component form can also be used for key storage. Using components makes obtaining a key harder since, to recover the key, all of the necessary components need to be obtained. However, we have only partially solved the storage problem since we still have to store the components somewhere. Components are essential keys and are not easily memorized. The most common way to store them is on hardware (such as a smart card). Thus, component form is really a strengthening of a hardware-based solution, not an alternative.