Symmetric key storage

Question

My company is going to be storing sensitive data for our customers, and will be encrypting data using one of the managed .NET encryption algorithm classes. Most of the work is done, but we haven't figured out how/where to store the key. I've done some light searching and reading, and it seems like a hardware solution might be the most secure. Does anyone have any recommendations on a key storage solution or method?

---

Thanks for your replies, everyone.

spoulson, the issue is actually both the "scopes" that you mentioned. I suppose I should have been clearer.

The data itself, as well as the logic that encrypts it and decrypts it is abstracted away into an ASP.NET profile provider. This profile provider allows both encrypted profile properties as well as plain text ones. The encrypted property values are stored in exactly the same way the plain text ones are - with the obvious exception that they've been encrypted.

That said, the key will need to be able to be summoned for one of three reasons:

1. The authorized web application, running on an authorized server, needs to encrypt data.
2. Same as #1, but for decrypting the data.
3. Authorized members of our business team need to view the encrypted data.

The way I'm imagining it is that nobody would ever actually know the key - there would be a piece of software controlling the actual encrypting and decrypting of data. That said, the key still needs to come from somewhere.

Full disclosure - if you couldn't already tell, I've never done anything like this before, so if I'm completely off base in my perception of how this should work, by all means, let me know.

Answer 1

There only two real solutions for (the technical aspect of) this problem. Assuming it's only the application itself that needs access the key...

1. Hardware Security Module (HSM) - usually pretty expensive, and not simple to implement. Can be dedicated appliance (e.g. nCipher) or specific token (e.g. Alladin eToken). And then you still have to define how to handle that hardware...

2. DPAPI (Windows Data Protection API). There are classes for this in System.Security.Cryptography (ProtectedMemory, ProtectedStorage, etc). This hands off key management to the OS - and it handles it well. Used in "USER_MODE", DPAPI will lock decryption of the key to the single user that encrypted it. (Without getting too detailed, the user's password is part of the encryption/decryption scheme - and no, changing the password does not foul it up.)

ADDED: Best to use DPAPI for protecting your master key, and not encrypting your application's data directly. And don't forget to set strong ACLs on your encrypted key...