Without good key management, your encryption project will likely be a disaster and provide absolutely no additional layer of security for your data. I cannot emphasize this point enough. The encryption key is the most vital part of your encryption algorithm. Possessing the encryption key when data has been encrypted using a symmetric key algorithm means that the data can be decrypted. It is critical that this key be managed properly. Here are best practices for key management.
The person who creates the keys should not be the same person using the keys (writing programs to use the keys for encryption or decryption) or the custodian of the keys. For large organizations, this shouldn't be an issue. For small System i shops, this may present a challenge. Either way, you must be prepared to explain your separation of key management duties to any auditor who asks.
Creating strong encryption keys requires seeding the key-generation algorithm with a random number. You might think it sufficient to simply type in a set of numbers for the algorithm seed number; after all, it looks random to you, right? However, studies show that people type in a certain pattern; therefore, the key is not actually random but a manifestation of the person's typing pattern. A weak seed means that your encrypted data is more weakly encrypted and more easily decrypted. You need to use a formal random number generator, such as the one provided by the i5/OS CIPHER MI instruction, to obtain the seed for your key-generation system.
You must be prepared to explain to auditors your process for changing encryption keys. If a breach occurs or you become aware that the encryption key has been compromised, you will have to decrypt the data and re-encrypt it using a different key. Best practices require that keys—regardless of whether they have been compromised—should be changed every year or two. The exception to this rule is when you feel that there would be more chance of a compromise to the data by decrypting and re-encrypting it than leaving it encrypted with an old key. Whether or not you plan to change keys on a regular basis, you need to establish and document a policy reflecting your key management change practices. Items to consider are the possibility that you will go back and decrypt and then re-encrypt all data that's been backed up, the safest system for the decryption/re-encryption to occur, and so forth.
Appropriate placement and access control of stored keys is vital. Many people think they need to keep their encryption algorithm a secret, but the critical component to keep secret is the encryption key. Therefore, storing keys in cleartext in program source or in a data area is not a good idea. One choice is to use a validation list for secure storage of keys, which is your best integrated i5/OS option if you are running prior to V5R4. (Validation lists provide a method for storing and encrypting small amounts of data such as encryption keys.) Beginning in V5R4, you should use the i5/OS integrated key-management APIs. If you're choosing a vendor encryption product, make sure you understand its key management features to ensure they meet your requirements.
Without good access controls (that is, object security) on where the encryption keys are stored as well as on the encryption and, especially, the decryption routines, you get virtually no additional security benefit by encrypting data in a database. If everyone has access to the decryption key, what's the point of encrypting the data?
In addition, you must realize that you cannot protect your encrypted data from being decrypted by an *ALLOBJ user. Remember, users with *ALLOBJ special authority can access any object on the system (this is why I prefer to use hashes whenever possible). The best you can do to ward off access by *ALLOBJ users is to throw up some roadblocks to make it more difficult to run the encryption routine and thus discourage them from trying to decrypt the data. One such roadblock is to query the process to see if it's running with *ALLOBJ and, if it is, reject the request. Another is to check the program calling the decryption routine and decrypt only if the calling program is in an approved list. But beware: No software method is a perfect prevention mechanism against abuse by an *ALLOBJ user. If your organization requires protection against an *ALLOBJ user decrypting data, you must use a hardware encryption mechanism that provides separation of roles and duties apart from i5/OS profiles.