How to securely handle AES “Key” and “IV” values
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? (File, Regkey, Dbase,...)
And what with the protection of those AES “Key” and “IV” values?
The background question is more : If “they” hack the server and get the dbase... then probably they can get to the program that do the encryption stuff also (It's on the same server, can't help it)... and if "they" are very good, then they will notice where the “Key” and “IV” values are stored...(.NET 4.5 ILSPY) and everything can be decrypted again.
Please advice? How do you all handle AES “Key” and “IV” value’s?
Ps: This is not about pwd fields... so, it's not about hashing... its pure data cryptography.
Answer
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).