I have a number of configuration files and binary data that needs to be stored encrypted on disk. Only the user who encrypted should be able to decrypt the information. So far, I have successfully used DPAPI to encrypt and decrypt this information.
New requirement - the system/this data now needs to be distributed on several machines. It's basically a deployment problem, but slightly more complicated and automated. Now I need to be able to decrypt data on a machine different from the one that encrypted the data.
So, I can't use DPAPI out of the box anymore as encrypted data may only be decrypted on the same machine. Still, I would love to use this neat user-bound encryption principle, without being bound to a machine.
I found this http://research.microsoft.com/en-us/projects/DKM/ but it's kind of overkill and in any case, it's not like there's a product I can use.
All clients (well they are all virtual application servers, but in this scenario, lets call them clients) in this project are somehow connected to SQL server. My idea is thus, to use SQL Server/SQLCLR as a Distributed key manager.
DPAPI is thus switched for AES on each client. The key for local AES enc/dec is fetched when encrypting/decrypting from sql server. On sql server, the AES key is encrypted using DPAPI with SQLCLR, so I get the same-ish functionality as before. I am thinking a basic table with two non-metadata columns: user and the (encrypted) distributed AES key. Obviously I will restrict access to this database/table to concerned user accounts only.
Any obvious security flaws in this architecture? I have figured out that the AES key has to be "in clear" in memory at some point to be able to assign it to the .net algorithm implementation, which isn't great.
Is there a better way to achieve the same thing? I have a feeling that I can't be the first person to have this problem and I'd hate to reinvent the wheel.
