In our application we have a lot of sensitive configuration settings, which we are storing in a xml file which is again encrypted.
This secure file has to be decrypted in runtime and the configuration values read. but an issue arises that the key and initialization vector is hardcoded in the code and hence anyone can read it using Reflector.
What is the best way to store encryption keys in .NET so no one can read them using Reflector?
If you want to protect your data from other users. Take a look at the ProtectedData class.
(Disclaimer: Protecting your data to create a copy protection scheme is not covered in this answer).
This classes uses the DPAPI from Windows, to encrypt and decrypt data on user or machine level.
Using ProtectedData/DPAPI frees you from handling keys and securing the data yourself. And you can choose to protect the data for the current user. The data can be read from different computers, by the same domain users.
If you want create your own key. You can create a key per user/machine, and store this key in the registry. Because the registry can be secured, only the current user can read the key back. I know the registry has bad karma, but is actually very good at storing data like this.
PS: Do not put the IV in your code. Create a new IV every time, and put it in front of the data.
You should use the Machine Keystore, it's a secure storage especially for this purpose. For example:
CspParameters cspParams = new CspParameters(PROV_RSA_FULL, null, KEYNAME);
cspParams.Flags = CspProviderFlags.UseMachineKeyStore;
RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(cspParams);
Where KEYNAME is a custom string that can be used to retrieve the key later on.
For more examples, see this question: How to store a public key in a machine-level RSA key container
If you can't read them in reflector, how do you expect the program to read them? You could obfuscate them by breaking them up and storing the parts all over the place, but (AFAIK) once you require your program to be able to read them, then anyone with access to your code can read them too.
Don't forget values in memory can be accessed as well (cough SecureString).
When you install the application, make a new set of RSA keys, then encrypt the data with AES using the private key as the password. As Windows stores RSA private keys securely on the PC that created them, the data can only be decrypted by the computer that created the data because only that computer will have the necessary key.
Generally, a new key and IV should be created for every session, and neither the key nor IV should be stored for use in a later session.
To communicate a symmetric key and IV to a remote party, you would usually encrypt the symmetric key and IV using asymmetric encryption. Sending these values across an insecure network without encrypting them is extremely unsafe, as anyone that intercepts these values can then decrypt your data. For more information on this process of encrypting and transferring the key and IV, see Creating a Cryptographic Scheme.
What about storing the file encryption/decryption key on a remote server, getting it though a web service that would transfer it though https to the application? that way the key stay in the memory of the computer but is not into a source code file.
This requires to have connection to the key server by whoever runs the application though.
It bears mentioning that any solution that is per machine or per user is not terribly useful for applications that store data in a database that is potentially to be read by multiple users on multiple machines during application runtime. Most use cases cannot make an assumption that data a given user posts is only expected to be read by him.
This is my best practice for storing and generating/using encryption keys in applications. Your mileage may vary if you have usage requirements that can't accommodate this scheme.
First, along with my application, I distribute an application-specific configurator to my customer. This configurator is run by my customer's administrator who installs the application and the database, which resides on a Microsoft SQL Server.
After running the installer, the admin runs my configurator. The configurator allows him to specify sensitive information, such as their SMTP server credentials needed for the application to send email, etc.
The configurator uses a private master key, which is hardcoded in a DLL. This embedded key is different per distribution. The sensitive information is encrypted and then stored in the registry by the configurator. The master key is also used to encrypt/decrypt other encryption keys that are generated at runtime to encrypt/decrypt application data.
At application runtime, another key is generated for general application data encryption - stuff like passwords and other sensitive info to be stored in the database in encrypted form. This key is encrypted using the master key from the DLL previously mentioned, and it is then stored in the registry as well.
Every time the application needs to encrypt or decrypt data to and from the database, it uses the master key to decrypt the application key. The application key is combined with a different IV each time. Each new IV is simply prepended to the data, as some of the other answers here have described.
When decrypting, the application simply clips the IV off the front of the data payload, and uses it along with the application key from the registry to decrypt the remainder of the payload.
By using this scheme, the only risk is that it could be read from memory. Secure strings can be used to minimize that risk if you're that concerned about it. Most of my clients don't expect their users to be hooking up to JTAG ports of motherboards and trying to read and decipher memory contents, but hey... your mileage may vary.
