10

I am using .NET 4.0 to develop a Windows service that will temporarily store encrypted data in a database. The data will be encrypted when it is inserted, then decrypted, processed, and deleted once processed. This will probably be done as a batch process (thousands of rows at a time).

I've looked at Generating Keys for Encryption and Decryption on MSDN, and it looks like I could use TripleDES symmetric encryption (I was thinking of using the RijndaelManaged class).

However, if the service fails or I lose my database connection while I am encrypting and inserting the data, I want to be able to pick up where I left off with the same IV and key.

How should I store my IV and key on a local computer? I want to be sure it will not be found and used to decrypt the encrypted contents of the database.

Huske
  • 203
  • 1
  • 2
  • 7
  • 1
    Hi @Huske, welcome to [security.se]! I admit that I'm not clear on your exact process, specifically the 3rd paragraph is confusing me. As I understand it, the data comes in, gets encrypted, and saved to the database; later, a batch process is run, decrypting the data, processing it, and then deleting the row. Correct? If so, I'm not sure where the IV / key would get lost? – AviD Feb 23 '12 at 14:20
  • @AviD, thanks for your response. You understood me correctly. The problem I am facing is that I could lose IV/Key in case the service fails or is stopped in some way. That means that IV and key will be gone from memory and I would not be able to decrypt the data. The point is that I would like to safely store IV/key in some storage (would Isolated Storage or PRotected Storage be a smart choice?) so that I could check the status of the records in the database, re-read the IV/Key and continue the decryption. – Huske Feb 23 '12 at 14:33
  • Hi @Huske, first of all I suggest you read the [FAQ#editing] a bit - yes, your stuff will get edited. Don't take it personally, its all in the interest of improving the site's content. Secondly, I added some tags, for better searching and categorization. Someone else did edit the q, it looks like he was attempting to clean it up a bit and narrow down the text to only what is absolutely necessary for the question. While the answers still apply, it definitely did make sense for you to provide all the relevant information you could! ... – AviD Feb 23 '12 at 20:58
  • (continued) In actuality, I think "the best" question is somewhere in between - with all of the context you can provide, but perhaps a bit more succintly and without anything extraneous. That said, in general, if you feel an edit changes the point of your question, you can always re-edit it, or roll it back (or, if it comes to that, you can always flag for a moderators attention)... – AviD Feb 23 '12 at 21:00
  • Hi AviD, when I checked the question it was not your name that was reported as the editor, but rather it was someone else with a few typos here and there. That is what surprised me. But, to sum it all up, I have no problem with my question being edited if it can help answer this kind of question to others in the future. It's just that I am alergic to typos (even to my own) :-). Thanks again. – Huske Feb 24 '12 at 09:27

2 Answers2

27

At least one thing you can improve rather easily: You can simply store the IV in the database next to the encrypted data. The IV itself is not supposed to be secret. It usually acts as a salt, to avoid a situation where two identical plaintext records get encrypted into identical ciphertext. Storing the IV in the database for each row will eliminate the concern over losing this data. Ideally, each row IV would be unique and random but not secret.

That leaves your problem to storing a relatively small piece of information: the key. There should be no issue using the same key for all records in terms of security. As long as the key itself is strong, using a different key does not give you any advantage (in fact, it will be a real headache to manage), so one key should usually be good enough.

There are probably many solutions to storing keys securely, but those depend on the level of security you really need. For .NET / Microsoft environment I am guessing you should be looking at DPAPI, although there may be better options out there. In one extreme, you'd need a HSM or a smartcard, but in less-stringent environments storing the key on the filesystem with the right permissions might be sufficient. It all depends on your risk profile and threats.

Community
  • 1
Yoav Aner
  • 5,359
  • 3
  • 26
  • 37
  • 1
    +1 cuz you pretty much wrote the same thing as I did, just a few minutes earlier... :) – AviD Feb 23 '12 at 15:17
  • @Yoav, this is great. Also, especially thanks for the tip about generating a unique IV for each row in a table. As for the key, my idea was to generate one and only one for each session. In this context session means importing data, encrypting the necessary field once the necessary information is built for each record, then process the records one by one (decrypting field), and at the end delete the row. When all this is accomplished, I consider this as the end of the session, and the next time the information needs to be processed a new key will be generated. – Huske Feb 23 '12 at 15:19
13

If I understand your situation correctly:

  1. The IV should be stored in the database, together with the encrypted data (either concatenated in the same field, or in a separate field in the same row). This can be stored as plaintext, there is no value in its secrecy.
  2. The encryption key should be stored in any file or registry key, as long as it is not remotely accessible, with two constraints: strong ACL, restricting access to this file only by the application (and admins); it should itself be encrypted before saving.

Regarding the last point, note that the KEK (key encrypting key) will still need to be protected... For this, DPAPI (Data Protection API) is ideally suited in most situations (though in some you might want to consider some form of hardware module), probably in USER_MODE.
.NET gives you easy access via the ProtectedMemory and ProtectedData classes.

AviD
  • 73,317
  • 24
  • 140
  • 221
  • this is great. Both Yoav and you have provided me with great information. I will be working on this during the weekend and will get back to both of you. I wish I could mark both Yoav's and your answer as correct! :-) – Huske Feb 23 '12 at 15:23