Finally, keys must be protected. Protection and storage generally go hand in hand, as secure storage is the primary means by which keys are protected. In addition, key exchange plays a role in protecting keys, making key protection a side effect of effective key management. There are additional issues however. The longer a key exists, the more venerable it becomes. In addition, the more data that is encrypted using a key, the more damage a compromised key can inflict. To solve these issues, most applications will frequently change keys, reducing both the lifetime of the key and the quantity of data that is encrypted using the key. Although specific implementations vary, two sets of keys are often used. One set of keys is used to perform bulk encryption and a second set is used to protect and exchange the bulk encryption keys. As we mentioned earlier, encryption is only as strong as the weakest key, so both sets of keys must be of equal strength.
One interesting key management caveat is that no matter what we do to protect data by using cryptography and key management, these tools must be accessible to a user. It is easy to say that the simplest form of key protection is to have the user remember the key, and only enter the key when the key is needed. The art of security involves finding a balance between what is technically sound and what is reasonable to expect the average person to do. If we were to ask the user to remember a 128 bit binary number, security would fail for two reasons. First of all, the user would likely write the number down. Secondly the user would find other, less secure ways of exchange data and simple avoid our system entirely. For that reason, most software implements password protect key storage. This only requires the user to remember a password when requiring access to the secret keys. Password based protection means that an attacker does not need to break encryption, guess keys, or any other complicate task, they only have to guess the users password. This is a very serious issue and will be discussed further in a future article.