Cryptography Reference
In-Depth Information
'security by obscurity', which is always dangerous since it relies on the hider of
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
there is at least one potential attacker out there who knows where to look
for the keys.
2. Assuming that 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 that resides 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. In order to encrypt a key, we require a key encrypting key. So
where do we store the key encrypting key? If it is a public key, where do we store
the corresponding private key?
There are really only four options:
Encrypt it with yet another key
. So where do we store that key?
Generate it on the fly
. This is a fairly common approach that we discussed in
Section 10.5.1 and is often taken for applications where a hardware-based
solution is not viable.
Store it in hardware
. This is probably the most common approach but,
obviously, 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. We discuss hardware storage of keys
in Section 10.5.3.
Store it in component form
. We introduced the idea of component form in
Section 10.3.3. It can also be used for key storage. By using components we
make the task of obtaining a key harder since, in order 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. As components are essentially keys themselves, hence not easily
memorised, the most common way to store components is on hardware (such
as a smart card). Thus component form is really a strengthening of a hardware-
based solution, not an alternative.
