Securing encryption keys in C#

Question

I am aware of the many cryptography providers that are available in the .NET framework along with the basics of how to use them. This is simple enough.

But my concern is this.

Lets say I want to use these libraries to encrypt XML serialized objects to prevent tampering and the ability of anyone to come along and view the contents of these files.

The problem that I am always left with is that the key to decrypt this data would need to be stored as a constant somewhere in my application. Essentially rendering the entire exercise pointless.

So, how does one store a key for an encryption algorithm securely inside of a disassemblable application?

EDIT: So If I am understanding both answers below correctly. What this means is that essentially any implementation (to be secure) requires it to be readonly or writeonly but never both? Is this correct?

Mast

Obfuscate XML as much as possible (add random data + use ROT13 primitive encryption scheme + etc.) and serialize it to binary mode or to Base64 mode. Point is to make XML decoding through program disassembly as much hard as possible to the point user may not invest time in doing this ... – Casares

Answer 1

You don't. If the application can access the key, it is just security by obscurity. It is better to authenticate the user in some way (a password is the simplest example), to make sure he is allowed to access the data. You can't let the application do that for you, because it simply isn't trustworthy. Anyone can obtain the information stored in the application.

If the key information is stored somewhere else, a malicious user or application can probably access it, too. If not, then store your data directly to that magical safe place.

Now if you still want to go down that path and store sensitive data without authentication, your best bet - or at least an easy way that is halfway secure - is probably the DPAPI (see the ProtectedData class in System.Security.Cryptography). It will encrypt the data either with the machine key or to the user account key (you can select that). So that a program running on another machine or with another user account can't access it. Windows will try to protect those keys but in effect any application running on the proper machine or with the proper user account may be able to access your data.

Hoebart

probably using the user's password to encrypt and decrypt is a good idea. But of course that would expose the password. Probably the hash of the password could do the job, or some other password-derived value. – Slavin

If you use a custom form of authentication and encryption, you're probably right. If you are using the DPAPI, it will take care of all that stuff automatically. As far as I remember it will also take care that data can still be decrypted after a user has changed his password. – Hoebart

That also creates its own problems. What if the user wants to change the password? – Mast

DPAPI will take care of that. See: msdn.microsoft.com/en-us/library/ms995355.aspx (last paragraph below “Keys and Passwords in DPAPI”). – Hoebart

If you do your own authentification with a password, it is probably better to use a random key for the actual file and store it encrypted with (a hash of) the users password. If the user changes the password, you just have to re-encrypt the random key. – Hoebart

Answer 2

We'll assume you're using some kind of public key cryptography scheme, because otherwise it would be pointless.

The answer is you do not store the private key anywhere in the application. You store it somewhere where only your application can get to it. For example, a file in the local system that only admins and your app have rights to read it. On a protected network share. Etc.

Think about how we manage keys as people. We keep our private ones in a file maybe, or an encrypted USB drive or something like that. The same principles apply to applications.

Potence

Won't this just move the problem around? If you do have a trusted location that only your application can access, you can just store the data there and be done with it. – Hoebart

There's no such thing as a location that "only admins and your app can access". If your app can access it, your app's user can too. – Leven

Answer 3

There a various possible solutions. One of them is using RSA. Alternatively you could use the same approach used in TLS.

One good way would be to generate a pair of public and private key. Encrypt with the private and destroy the key. With the public key, you could decrypt but not tamper the data.

Slavin

If you destroy the private key, this is a read-only solution. However even then a malicious user could just create a new file with his own key pair and replace the key the application uses for decryption. This of course depends on his ability to modify the location where the public key is stored. – Hoebart

Answer 4

Collecting given answers: All encryption security relies on protection of a "root" password. This cannot be guaranteed in a compromitable system.

A feasible hardware architecture is given by e.g. Chip Card Readers. As external systems they cannot be compromised by internal malicious manipulations.

Accordingly you could set up a separate "Secure Server" with strongly restricted access, e.g. key board and local network. This server would provide sensitive data like passwords by secured communication with authenticated clients in a limited time window.

Suggested measures for clients in this time window are clamping spyware, messengers, remote control server and basically internet access, process monitoring, ...

... or you do all sensitive data processing on secure platforms, excluding talkative ones like Windows.

Sphygmomanometer