Best practices for (symmetric) encryption in .Net?

Question

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

Answer 1

I would add:

• Keeping the IV hidden is not important. It's OK if the IV is public. Just use good IVs, which means, use a cryptographic-strong random number generator so that your IVs are indistinguishable from random.

• Storing the encryption key separate from the data that it encrypts.

• Add authentication to your encryption. For example, add an HMAC keyed with a second symmetric encryption key, covering the ciphertext. If you don't use some form of authenticated encryption, then your ciphertext could be modified, and you have no way of knowing (AES will decrypt garbage just fine.) You want any tampering of the ciphertext to be noticed.

Answer 2

I saw that one of the previous comments mentioned that it doesn't matter if you use CryptoAPI. I just wanted to point out that CryptoAPI is FIPS 140-2 compliant, while Bouncy Castle and the built-in managed classes (all the ones with "Managed" at the end of their names in the System.Security.Cryptography namespace) are not. If you have a requirement for FIPS compliance, it's probably easiest to for you to use CryptoAPI.

Answer 3

Taken more generic list of best practices, from OWASP (Cryptographic Storage Cheat Sheet):

• Use strong approved cryptographic algorithms
  • Do not implement an existing cryptographic algorithm on your own
  • Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing
  • Do not use weak algorithms, such as MD5 or SHA1
  • Avoid hashing for password storage, instead use Argon2, PBKDF2, bcrypt or scrypt
• Use approved cryptographic modes
  • In general, you should not use AES, DES or other symmetric cipher primitives directly. NIST approved modes should be used instead. Quote from Nist: "The approved algorithms for encryption/decryption are symmetric key algorithms: AES and TDEA."
• Use strong random numbers
• Ensure that any secret key is protected from unauthorized access

---

Also, according to this Cisco article:

• DES is to be avoided and so is RSA-768, -1024
• RSA-2048 and RSA-3072 are acceptable
• AES-CBC mode is acceptable, while
• AES-GCM mode is part of the Next Generation Encription.

Answer 4

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.