Symmetric key storage我的公司将为我们的客户存储敏感数据，并将使用托管的.NET加密算法类之一对数据进行加密。大部分工作已经完成，但是我们还没有弄清楚如何存储密钥。我已经做了一些简单的搜索和阅读，看来硬件解决方案可能是最安全的。是否有人对密钥存储解决方案或方法有任何建议？ 所有人，感谢您的答复。 spoulson，问题实际上是您提到的两个"作用域"。我想我应该更清楚一些。 数据本身以及对其进行加密和解密的逻辑被抽象到ASP.NET配置文件提供程序中。此配置文件提供程序既允许加密的配置文件属性，也允许纯文本属性。加密后的属性值的存储方式与纯文本中的值完全相同-很明显，它们已被加密。 也就是说，出于以下三个原因之一，将需要能够调用密钥： 我想像的是，没有人会真正知道密钥-会有一块软件来控制实际的数据加密和解密。也就是说，密钥仍然需要来自某个地方。 全面披露-如果您还无法确定，我以前从未做过这样的事情，因此，如果我完全不理解这应该如何工作，那么请让我知道。 对于此问题(技术方面)只有两个实际的解决方案。 硬件安全模块(HSM)-通常非常昂贵，并且实施起来并不容易。可以是专用设备(例如nCipher)或特定令牌(例如Alladin eToken)。然后您仍然必须定义如何处理该硬件... DPAPI(Windows数据保护API)。 System.Security.Cryptography中有一些此类(ProtectedMemory，ProtectedStorage等)。这将密钥管理交给了操作系统-并且处理得很好。在" USER_MODE"中使用时，DPAPI会将密钥的解密锁定到对其进行加密的单个用户。 添加：最好使用DPAPI保护您的主密钥，而不是直接加密应用程序的数据。并且不要忘记在加密密钥上设置强ACL ... 我们有同样的问题，并且经历了相同的过程。 我们目前认为最佳做法是：
实际上，操作员的登录密码是密钥，但不会存储在任何地方。 响应OP中的第3个答案 授权成员可以查看加密数据的一种方法，但是如果他们没有真正知道密钥，那就是使用密钥托管(rsa labs)(Wikipedia) 总而言之，密钥被分解为不同的部分，并交给了"受托人"。由于私钥的性质，每个段本身都是无用的。但是，如果需要解密数据，那么"受托人"可以将其段组合为整个密钥。 根据您的应用程序，您可以使用Diffie-Hellman方法让两方安全地就对称密钥达成共识。 在进行初始的安全交换之后，就对密钥达成了共识，其余会话(或新会话)可以使用此新的对称密钥。 在写入之前，使用硬编码密钥对生成的密钥进行加密。然后您可以在任何地方编写它。 是的，您可以找到硬编码的密钥，但是只要您假设可以将对称密钥存储在任何地方，它的安全性就不会降低。 我想我误解了你的问题。您要求的不是应用程序如何处理其密钥存储的范围，而是您的公司将如何存储它的范围。 在这种情况下，您有两个明显的选择：
您可以使用从PBKDF2之类的密码派生的另一个对称密钥对对称密钥进行加密。 让用户输入密码，生成用于加密数据的新密??钥，使用该密码生成另一个密钥，然后加密并存储数据加密密钥。 它不如使用硬件令牌安全，但它可能仍然足够好并且非常易于使用。 您最好的选择是物理保护按键所在的硬件。另外，永远不要将其写入磁盘-寻找某种方法来防止将那部分内存分页到磁盘。加密/解密时，需要将密钥加载到内存中，而对于不安全的硬件，总是存在这种攻击的场所。 就像您说的那样，有硬件加密设备，但它们无法扩展-所有加密/解密都通过芯片进行。 Microsoft Rights Management Server(RMS)也有类似的问题。它只是通过使用主密码加密其配置来解决该问题。 ...如果可以的话，请输入密码上的密码。 |
