.Net中（对称）加密的最佳实践？

Question

加密SQL数据库中的某些敏感或个人身份识别数据（根据PCI，HIPAA或其他适用的合规标准）被认为是“最佳做法”？

这里有很多关于解决方案的个别方面的问题，但我没有看到任何在高层次上讨论该方法的问题。 在环顾了一段时间之后，我想出了以下内容：

• 使用CryptoAPI和Rijndael
• 生成IV并将其与加密数据一起存储
• 使用DPAPI（机器范围）来“保护”对称密钥
• 将对称密钥存储在注册表或文件或数据库中，拆分密钥并将部件存储在多个位置以增加保护
• 除非确实需要，否则不解密数据，即不从数据库读取。相反，将密文保存在内存中。

这是否足够？过时了吗？审计，安全吗？鲁莽？

Answer 1

您的方法很好，我的眼睛有一些调整（我通常会对PCI合规性进行编码）：

  

使用CryptoAPI和Rijndael

至少使用Rijndael / AES256，无论其他API

  

生成IV并将其与加密数据一起存储

好

  

使用DPAPI（机器范围）来保护＆＃34;对称密钥

不确定是否重要。我只是将IV保留在加密的数据旁边，或者如果您在某些其他媒体上真的偏执。确保公众无法使用IV。

  

将对称密钥存储在注册表或文件或数据库中，拆分密钥并将部件存储在多个位置以增加保护

如果有人窃取您的媒体，在多个地方存储将无法帮助您。将密钥分开是有点矫枉过正，但绝对不要将它与你的IV和/或密文一起存储。那太糟糕了。

  

除非确实需要，否则不解密数据，即不从数据库读取。相反，将密文保存在内存中。

当然。将密文保存在内存中很好，但不要在任何地方传递它，并且除非绝对必要，否则不要解密，甚至不要将整个未加密的数据集展开 - 只需要提供所需内容从它至少。另外，如果可能的话，不要将密钥保存在内存中 - 内存转储可能会暴露它。

<强>加法：

• 无论您将密文存储在何种数据库中，都要将读取权限完全限制为为给定标识符选择的proc。不允许对存储此数据的表的读访问权限，甚至是SA帐户。这样，闯入您系统的人将很难在不知道要查找的ID的情况下下载您的密文。对引用密文表上的标识符的任何表执行相同操作。 不要允许阅读这些表格！
• 通过IP限制数据库访问
• 永远不要在内存中保留任何未加密的明文状态。一旦请求完成，就允许它被解除引用/垃圾收集。
• 将运行此代码的服务器限制为尽可能少的用户。
• 可能将加密方法组合成更强的密文（例如AES + Blowfish）

希望这些帮助。其中一些是我个人的意见，但据我所知仍然符合PCI标准。

Answer 2

我看到之前的评论之一提到如果你使用CryptoAPI并不重要。我只是想指出CryptoAPI符合FIPS 140-2标准，而Bouncy Castle和内置托管类（所有那些用＆＃34; Managed＆＃34;在他们的名字末尾的System.Security中）。密码术命名空间）不是。如果您需要符合FIPS标准，那么使用CryptoAPI可能最容易。

Answer 3

从OWASP（Cryptographic Storage Cheat Sheet）中获得最佳实践的通用列表：

• 使用经过批准的强大加密算法
  • 请勿自行实现现有的加密算法
  • 仅使用诸如AES，RSA公钥加密和SHA-256或更好的哈希等经过认可的公共算法进行哈希处理
  • 请勿使用弱算法，例如MD5或SHA1
  • 避免哈希存储密码，而应使用Argon2，PBKDF2，bcrypt或scrypt
• 使用批准的加密模式
  • 通常，您不应直接使用AES，DES或其他对称密码原语。应该使用NIST批准的模式。 Nist的话：“已批准的加密/解密算法是对称密钥算法：AES和TDEA。”
• 使用强随机数
• 确保所有密钥均受到保护，以防止未经授权的访问

---

此外，根据Cisco article：

• 应避免使用DES，RSA-768，-1024也应避免使用
• 可接受RSA-2048和RSA-3072
• 可接受AES-CBC模式，而
• AES-GCM模式是“下一代加密”的一部分。

Answer 4

我想补充一下：

• 保持IV隐藏并不重要。如果IV是公开的，那就没关系。只需使用好的IV，即使用加密强的随机数生成器，这样你的IV就无法与随机区分开。

• 将加密密钥与其加密的数据分开存储。

• 为您的加密添加身份验证。例如，添加一个用第二个对称加密密钥加密的HMAC，覆盖密文。如果您不使用某种形式的经过身份验证的加密，那么您的密文可能会被修改，而您无法知道（AES会很好地解密垃圾。）您希望注意任何对密文的篡改。