Key Usage Issue—Key Separation

Key separation

The principle of key separation is that cryptographic keys must only be used for their intended purpose. This section considers why key separation is a good idea and discusses options for enforcing it.

The need for key separation

The problems that can arise if key separation is not enforced can be serious. In many applications, the need for key separation may be quite obvious. For example, it may be the case that encryption and entity authentication is conducted by distinct processes, each with their own particular requirements regarding key lengths. We’ll see an example of this when we look at WLAN security, a process in which encryption is ‘locked down’ across all applications, but the entity authentication process can be tailored to a specific application environment.

However, in other applications, it may be tempting to take a key that has already been established for one purpose and then, for convenience’s sake, use it for some other purpose. We illustrate the potential dangers of doing this with these two examples:

• Example 1: Like passwords, PINs should not be stored anywhere in the clear. This is why PINs are often stored in encrypted form using a symmetric PIN encrypting key. This key should only be used to encrypt PINs. It should never be used to decrypt an encrypted PIN. In contrast, a standard symmetric data key is used for encryption and decryption. If these two keys are somehow interchanged within an HSM, then we have two serious problems. First, it may become possible to decrypt and reveal a PIN. Second, recovering any normal data encrypted with the PIN encrypting key may not be possible.

• Example 2: Suppose we have an HSM with the following two security functions:

  • Function 1: This generates a four-digit PIN for a payment card by:

    • Encrypting the card’s 16-digit account number using a PIN generation key and outputting the resulting ciphertext in hex form.

    • scanning the hex output for the first four digits in the range 0 to 9, but ignoring any in the range A to F, which are then used to form the PIN (additional measures need to be taken in the unlikely event there are insufficient digits generated using this process to form a PIN); and

    • Outputting the resulting PIN in encrypted form.

  • Function 2: This generates a MAC on some input data by:

    • Computing a simple CBC-MAC on the input data using a MAC key (using the version of CBC-MAC depicted in the illustration below, which is not recommended in practice).

    • Outputting the MAC in hex form.

  • Now suppose an attacker can persuade the HSM to use the key from Function 1 to compute Function 2. In other words, the attacker can generate a MAC on the card’s account number using the PIN generation key. The result will be a MAC output in hex form.

    Assuming the same block cipher is used by both functions (in Function 1 to encrypt and in Function 2 to compute CBC-MAC) and since the account number is likely to be a short piece of data less than one block long, the MAC that is output will be the same as the encrypted account number produced in the first stage of Function 1. The attacker can then scan the MAC for the first four digits in the range 0 to 9 and determine the PIN.