I've looking for a way to store a given AES key so that it can't be retrieved, but it can still be used for encryption and decryption (using C#). I think the equivalent for asymetric key storage can be found here, but I'm looking for something that can be used for symmetric encryption. Does it exist in a managed form (pre .Net 4)?
+1
A:
Depending on who you're defending against, you can use the ProtectedData class.
SLaks
2010-09-29 21:33:32
We may have to go that route, but my understanding is that if we stored our key using the ProtectedData, then we could get it back later. We don't want to be able to get it back, just be able to use it.
Nogwater
2010-09-29 21:35:56
You could only get it back under while logged in as the same user.
SLaks
2010-09-29 21:59:05
Yeah, I think that would probably work for us. It's not really ideal because we're installing our software on a cluster of machines, which would mean that the encrypted blob of our AES key that we'd need to store would be different per machine. Right now we're leaning towards something like this: http://www.codestrider.com/BlogRead.aspx?b=d147ff4f-65e0-47f5-a39b-40ae07a42005 with uses public/private key encryption and Window's certificate store to protect the real key.
Nogwater
2010-09-29 22:11:51
A:
@SLaks is right, if its in your memory it can be accessed. You can make it more difficult, but it's always going to be possible.
That's why folks who are serious offload the crypto.
One options is a smart card. This lets you move data to the card and get results back, but doesn't allow access to the key material. It's not in your PCs memory space so it can't be leaked.
Ross Anderson has a good paper, Programming Satan's Computer about just this kind of thing. From the abstract:
The problem is the presence of a hostile opponent, who can alter messages at will. In effect, our task is to program a computer which gives answers which are subtly and maliciously wrong at the most inconvenient possible moment.
Even if you're not concerned about physical memory and just the hard disk and source you still need to be wary of virtual memory. If you're not careful (or using a carefully written service) you can get plaintext keys in your swap file. Here's another link that discusses the issue. Not that you want to do that but it makes the issue apparent: Encrypting Virtual Memory. I believe there are system calls for this purpose to mark memory as unswappable but I can't find a link.
Paul Rubel
2010-09-29 21:36:51
We're not quite paranoid enough to be worrying about someone with access to memory, just to the hard drive of the server (including read access to our source code).
Nogwater
2010-09-29 21:57:25
A:
Even for asymmetric data, if the key is stored in computer and is used later, then it's retrieved and decrypted before use. And at this point a skilled hacker can retrieve it (by capturing computer memory and studying it). This is not trivial, but still possible.
In general to address your problem USB cryptotokens and cryptocards are offered. These hardware devices have their own memory for storing both symmetric and asymmetric keys, and they have processor to perform cryptographic operations using that keys. The key never leaves the device and it's virtually impossible to extract it from the device forcefully (there exist some hardware attacks such as scanning memory with microscope, but they are way more complicated than a software attack on computer).
So if your key is really valuable, use USB cryptotoken. The price of the device is very moderate - about $70-$100 per unit and there are several vendors that offer such devices.
Eugene Mayevski 'EldoS Corp
2010-09-30 07:26:06
A:
To continue on the trend of offloading the crypto, if you know the hardware of all of your cluster you can have the key in in the TPM if the motherboard has one, it is just another option to the usb or smart-card solutions.
Scott Chamberlain
2010-09-30 14:03:44
I don't have access to USB or smart-card for these servers. Some of our boxes are still running Windows 2003, so it's not really an option for me. Are there standard .NET 3.5 libraries for TPM? Maybe it'll be useful for someone else.
Nogwater
2010-09-30 16:30:44
A:
Windows DPAPI (Win32 documentation), and its .NET wrapper (ProtectedData Class) does not store any data. Rather, Windows DPAPI returns a cryptographic cypher value which you can store anywhere you like, including on multiple servers.
At my place of work we use DPAPI to generate a cypher for an AES key which we then store in the Registry.
The sole purpose of Windows DPAPI is to encrypt data such that only a given user account or machine can decrypt it, without needing to store a password.
The .NET ProtectedData class has been in the .NET Framework since 2.0.
I would stick with Windows DPAPI over a third party product as it is mature, stable, free, easy to use and fully supported in .NET.
saille
2010-10-04 03:04:38
Just to be sure that I understand... To use ProtectedData on multiple machines, there would need to be a shared user account across both of those machines, which would need to be provided by a domain controller, right?
Nogwater
2010-10-04 15:32:25
You could use DPAPI to encrypt the key independently on 2 separate machines, running under 2 different user accounts if you wanted, its just that the 2 cipher values would not be interchangeable ie. would have to be decrypted under the same account (or machine if using machine based DPAPI) that did the encryption. If you want to have 1 cypher that can be decrypted on multiple machines, then yes, I would say you'd need a shared account and a domain controller.
saille
2010-10-04 20:24:04