Encrypting Keys for Storage

Suppose you get a security requirement to encrypt the passwords and keys that are stored on a device. How can this problem be solved without complicating the design? Encrypting passwords is easy, it is a well established practice in Linux and Unix world to create a one way hash of the passwords, mix it up with a salt and store it. One way hash algorithms are practically known to be non-reversible, so it is not easy to guess the password if a good algorithm is used.

Problem comes with storing keys in encrypted format that can not be stored as one way hash e.x. keys for remote AAA servers such as RADIUS. Those keys are required to be present in clear text format when AAA client communicates with AAA server, otherwise client won't know what key to use.

This can be solved in few ways:
1. Have a hardware device that stores these keys and grants access permissions to only those applications that are on the white list. Although feasible, it adds to overall cost of device, as, such specialized hardware does not come cheap. This is very little gain for a lot of cost. It may be ok for a specialized security product that has a requirement of such hardware for other reasons, but not for a general purpose product that only needs to store keys.

2. Come up with an external key management scheme where keys to encrypt are managed externally. Internally keeping encryption keys on the device defeats the purpose, if encryption key and encrypted data are in same place, it is not very hard to break it. This approach also does not pass the cost/benefit test for a general purpose device. Therefore, not feasible.

3. Use a unique device attribute to generate a encryption key. This is a better approach from complexity perspective, but has the same problem of keeping the encryption key along with the encrypted data. No matter what algorithm is used, once it is known what attribute is used to generate the key, reverse engineering it may not be very hard. This is however, still the most practical approach that works considering the risk of compromise. In this case, goal is to encrypt the the secure key so that they are not easily known, not necessarily to protect against a determined attacker. A determined attacker is likely to find other ways to get secure keys.

So, third approach is a reasonable compromise to hide the secure keys keeping in mind the risk and cost associated with other approaches. However, in some environments this poses another challenge. Many system administrators want to define a cookie cutter configuration for the devices they manage. They want to create a configuration on one device and then be able to apply same configuration seamlessly on potentially hundreds of similar devices. In this case, using unique device encryption keys means that the configuration created on one device can not be used on another device. For example, a AAA server key is encrypted with a unique device key, another device can not decrypt and read it, therefore making the cookie cutter approach infeasible.

How can this problem be solved in a sensible way without compromising the security of stored data? I am still looking for a solution.