How to securely handle AES “Key” and “IV” values

Question

If I use AES (System.Security.Cryptography) to simply encrypt and decrypt blob or memo fields in a SQL server, then where do I store the “Key” and “IV” values on the server?

Answer 1

Segregating your web server and db server would be helpful here. You want to lock down access (permissions-wise) to your encryption keys, and keep them in memory as SecureString. Can't do much more than that. Choose strong passwords and follow up-to-date security practices.

Here's a good post as well Where to Store Encryption Keys MVC Application

Answer 2

The IV has been thoroughly covered by the other answers, so I'll focus just on storing the key.

First...

I can't except it could not be done on a single server at software level.

Anything done in software can be undone in software. You can encrypt, hide, and lock it in as many safes as you want, but your application still needs to be able to get access to the key. If your application has access, then someone with the same level of access as your application is able to get to it as well.

Developers have been dealing with this problem for a very long time and there is no silver bullet.

This all is setup in a single server environment (application plus dbase), so I’m not able to send/retrieve the key to a second server. Also, in this “special” case I’m not able to encrypt the key by a machine-level or user-level RSA key container.

I can think of two possible solutions.

Option 1:

Store the key on disk and, at the OS level, configure file access so that only the account your application is running under can read the file the key is contained in. The file could be a flat file, or an encrypted container that's protected by a password which your application knows (up to you to decide, but an encrypted container is better).

Pros:

• Restarts without human intervention.

Cons:

• You have to do OS security right and there is no room for error.
• An attacker with administrator access can get to the key.

Another similar option to this would be to use DPAPI instead of files for storing the key (as long as you're able to do this given your "special case"). This is an API built in to windows that utilizes the password for whatever windows account you (or your application) is running under to securely store data. Only the windows account that stored the data is able to retrieve it.

One particularly nice feature of DPAPI is that, if an administrator resets a users password (via computer management), access to that users DPAPI data is lost. An attacker would need to compromise the actual account that was used to store the data in the first place without resetting the password.

Option 2:

Require that a pass phrase be entered by a person at application start up and derive an encryption key from that pass phrase. Once you have the key, discard the pass phrase and retain the key in memory only.

Pros:

• The key is never on disk.
• Even if the server is rooted, getting to the key is not a simple task.

Cons:

• Automated reboots are not possible.
• You'll likely have to share the pass phrase with anyone handling support.
• You need to keep in mind that data stored in memory may transparently be written to disk in certain situations.

Or you could do a compromise between these two systems where, a pass phrase is initially used to derive the encryption key which is held in memory, and the key is temporarily written to disk or encrypted container whenever the application is gracefully restarted. When the restart is complete the application loads the key and then deletes it from temporary storage (and if necessary, be sure to overwrite the disk location where the key was stored so that it can't be recovered).

Answer 3

The IV does not need to be kept as secret as the key, the only thing it serves to do is to make sure two of the exact same blobs encrypted with the same key produce two outputs that are totally different from each other (so you can't tell the same message was sent twice). Many encryption systems just make the IV the first bytes of the message.

Encryption keys are a harder thing to manage, the best thing you can do is keep the database itself and the application separate so "If “they” hack the server and get the dbase" (Say a SQL injection attack lets them do a dump of the database's tables) they still can't decrypt the fields themselves.

Answer 4

Rules of thumb are:

• Key must be secret at all times (must not be anywhere near the database)
• IV must be different for each record.
• IV must be "indistinguishable from random" and unpredictable, preferably it must come from the same source as your AES keys; other option is to encrypt some value (different for each record) with a secret key.
• IV needs not to be secret

Hence, one scheme you can use is:

1. Create a table with fields ID (unique, int), IV (unique, 16 bytes), Encrypted(variable bytes, NULLable)
2. To write a new record into the database, create new unique IV and create a new record in the database with empty encrypted data (to prevent collisions)
3. Encrypt the data with your secret key and IV from step 2 (CBC or CTR mode - CTR is better) and update the record.

Step two may be performed by taking the IV from previous record and encrypting it with the same secret key - AES's properties will make this an effectively random IV.

This will be as secure as you can get with AES - meaning CCA/CPA secure. The only thing it does not prevent is tampering

Answer 5

If it is not much the encrypted information, periodically update the password and information from the records encrypted, it can be every day or every hour, for example.