Best practices for (symmetric) encryption in .Net?

cdonner picture cdonner · Mar 13, 2014 · Viewed 11.3k times · Source

What is considered "best practice" for encrypting certain sensitive or personally identifiable data in a SQL database (under PCI, HIPAA, or other applicable compliance standards)?

There are many questions here regarding individual aspects of a solution, but I have not seen any that discuss the approach at a high level. After looking around for quite some time, I came up with the following:

  • Use CryptoAPI and Rijndael
  • Generate IV and store it with the encrypted data
  • Use DPAPI (Machine scope) to "protect" the symmetric key
  • Store the symmetric key in the registry or a file or the database, split the key and store parts in multiple places for added protection
  • do not decrypt the data unless it is really needed, i.e. not upon read from the database. Instead, hold cipher text in memory.

Is this adequate? Outdated? Audit-safe? Reckless?

Answer

Haney picture Haney · Mar 13, 2014

Your approach is good, with a few adjustments in my eyes (I code for PCI compliance generally):

Use CryptoAPI and Rijndael

Use Rijndael/AES256 at a minimum, regardless of other APIs

Generate IV and store it with the encrypted data

Good

Use DPAPI (Machine scope) to "protect" the symmetric key

Not sure if it matters. I'd just keep the IV next to the data that's encrypted, or if you're really paranoid on some other medium. Ensure that the IV is not accessible to the public.

Store the symmetric key in the registry or a file or the database, split the key and store parts in multiple places for added protection

Storing in multiple places will not help you if someone steals your media. It's a bit overkill to split the key up all over heck, but definitely do NOT store it with your IV and/or ciphertext. That'd be bad.

do not decrypt the data unless it is really needed, i.e. not upon read from the database. Instead, hold cipher text in memory.

Definitely. Holding cipher text in memory in fine, but don't pass it around anywhere, and don't decrypt except when you absolutely must, and even then don't EXPOSE the entire unencrypted dataset - only what is needed from it at the minimum. Also, do not hold the key in memory if possible - a memory dump could expose it.

Additions:

  • Whatever database you store your cipher text in, restrict read access entirely to the proc(s) that select for a given identifier. Do not allow read access to the tables that store this data to ANYONE, even the SA account. This way, a person who breaks into your system will have a hard time pulling down your cipher texts without knowing what IDs to look for. Do the same for any table(s) referencing the identifier on the ciphertext table. DO NOT ALLOW BLANKET READS OF THESE TABLES!
  • Restrict database access by IP
  • Never persist any unencrypted plaintext in memory over state. Allow it to be dereferenced/garbage collected as soon as the request is completed.
  • Restrict the server(s) running this code to as few users as possible.
  • Possibly combine encryption methods for a stronger ciphertext (AES + Blowfish for example)

Hope these help. Some of them are my personal opinions but remain PCI compliant to the best of my knowledge.