对称密钥存储
我的公司将为我们的客户存储敏感数据，并将使用托管的.NET加密算法类之一对数据进行加密。大部分工作已经完成，但是我们还没有弄清楚如何/在哪里存储密钥。我已经做了一些简单的搜索和阅读，看来硬件解决方案可能是最安全的。是否有人对密钥存储解决方案或者方法有任何建议？
谢谢大家的回复。
Spoulson，问题实际上是我们提到的两个"范围"。我想我应该更清楚一些。
数据本身以及对其进行加密和解密的逻辑被抽象到ASP.NET配置文件提供程序中。此配置文件提供程序既允许加密的配置文件属性，也允许纯文本属性。加密属性值的存储方式与纯文本值完全相同，唯一不同的是它们已加密。
就是说，出于以下三个原因之一，将需要能够调用密钥：
- 在授权服务器上运行的授权Web应用程序需要加密数据。
- 与＃1相同，但用于解密数据。
- 我们业务团队的授权成员需要查看加密的数据。
我想象的方式是，没有人会真正知道密钥，因此会有一款软件来控制实际的数据加密和解密。也就是说，密钥仍然需要来自某个地方。
如果我们还不能完全透露，我以前从未做过这样的事情，因此，如果我对这应该如何工作完全不了解，请告诉我。
解决方案
回答
Microsoft权限管理服务器(RMS)也有类似的问题。它只是通过使用主密码加密其配置来解决该问题。 ...如果可以，请输入密码上的密码。
回答
最好的选择是物理保护按键所在的硬件。另外，永远不要将其写入磁盘，以某种方式防止将那部分内存分页到磁盘。加密/解密时，需要将密钥加载到内存中，而对于不安全的硬件，总会有这种攻击的场所。
就像我们说的那样，有一些硬件加密设备，但是它们不能扩展通过芯片的所有加密/解密操作。
回答
我们可以使用从PBKDF2之类的密码派生的另一个对称密钥对对称密钥进行加密。
让用户输入密码，生成用于加密数据的新密钥，使用该密码生成另一个密钥，然后加密并存储数据加密密钥。
它不像使用硬件令牌那样安全，但是它可能仍然足够好并且非常易于使用。
回答
我想我误解了你的问题。我们所要求的不是应用程序如何处理其密钥存储的范围，而是公司将如何存储它的范围。
在这种情况下，我们有两个明显的选择：
- 物理：写入USB驱动器，刻录到CD等。存储在物理上安全的位置。但是我们遇到了递归问题：将密钥存储在何处？通常，我们委派2个或者更多的人(或者一个团队)来按住键。
- 软件：Cyber-Ark Private Ark是我公司用来存储其秘密数字信息的工具。我们存储所有管理员密码，许可证密钥，私钥等。它可以通过运行未加入域的Windows"库"服务器，对除其自身端口以外的所有端口进行防火墙保护并将其所有数据加密存储在磁盘上来工作。用户通过Web界面访问，该界面首先对用户进行身份验证，然后通过类似浏览器的界面与Vault服务器进行安全通信。将记录所有更改和版本。但是，这也有相同的递归问题...主管理员访问CD。这存储在我们具有限制访问权限的物理保管库中。
回答
在写入之前，请使用硬编码密钥对生成的密钥进行加密。然后，我们可以在任何地方编写它。
是的，我们可以找到硬编码的密钥，但是只要我们假设可以将对称密钥存储在任何地方，安全性就不会降低。
回答
根据应用程序，我们可以使用Diffie-Hellman方法让两方安全地就对称密钥达成一致。
在进行初始的安全交换之后，就同意了密钥，并且会话的其余部分(或者新会话)可以使用此新的对称密钥。
回答
对于此问题(技术方面)只有两个实际的解决方案。
假设只有应用程序本身需要访问密钥...
- 硬件安全模块(HSM)-通常非常昂贵，并且实施起来并不容易。可以是专用设备(例如nCipher)或者特定令牌(例如Alladin eToken)。然后我们仍然必须定义如何处理该硬件...
- DPAPI(Windows数据保护API)。 System.Security.Cryptography中有一些此类(ProtectedMemory，ProtectedStorage等)。这将密钥管理交给了操作系统-并且处理得很好。在" USER_MODE"中使用时，DPAPI会将密钥的解密锁定到对其进行加密的单个用户。 (无需太详细，用户密码是加密/解密方案的一部分-否，更改密码不会使它搞砸。)
添加：最好使用DPAPI保护主密钥，而不是直接加密应用程序的数据。并且不要忘记在加密密钥上设置强大的ACL ...
回答
回应OP的第3个答案
授权成员可以查看加密数据但不真正知道密钥的一种方法是使用密钥托管(RSA Labs)(Wikipedia)
总之，密钥被分解为不同的部分，并交给了"受托人"。由于私钥的性质，每个段本身都是无用的。但是，如果需要解密数据，则"受托人"可以将其段组合为整个密钥。
回答
我们有同样的问题，并且经历了相同的过程。
我们需要在一台计算机(客户端)上启动一个进程，然后再登录到另一台计算机(数据库服务器)。
目前，我们认为最佳做法是：
- 操作员在客户端PC上手动启动该过程。
- 客户端PC提示操作员输入其个人登录凭据。
- 操作员输入其凭据。
- 客户端PC使用这些来登录数据库服务器。
- 客户端PC向数据库服务器请求其自己的登录凭据。
- 数据库服务器检查操作员的登录凭据是否获得了客户端进程的凭据的授权，并将其返回给客户端PC。
- 客户端PC注销datbase服务器。
- 客户端PC使用其自己的凭据重新登录到数据库服务器。
实际上，操作员的登录密码是密钥，但不会存储在任何地方。
