对称密钥存储

问题描述:

我的公司将为我们的客户存储敏感数据,并将使用其中一个受管.NET加密算法类对数据进行加密。大部分工作已经完成,但我们还没有弄清楚如何/在哪里存储密钥。我已经做了一些轻松的搜索和阅读,看起来像一个硬件解决方案可能是最安全的。有没有人有关于关键存储解决方案或方法的建议?对称密钥存储


感谢您的回复,每个人。

spoulson,这个问题实际上都是你提到的“范围”。我想我应该更清楚。

数据本身以及加密和解密数据的逻辑被抽象到ASP.NET配置文件提供程序中。此配置文件提供程序允许加密的配置文件属性以及纯文本属性。加密属性值的存储方式与纯文本格式完全相同 - 明显的例外是它们已被加密。

这就是说,关键需要能够被传唤的三个原因之一:

  1. 授权的Web应用程序,授权的服务器上运行,需要对数据进行加密。
  2. 与#1相同,但用于解密数据。
  3. 我们业务团队的授权成员需要查看加密数据。

我想象的方式是,没有人会真正知道关键 - 将有一块软件控制数据的实际加密和解密。也就是说,关键还是需要来自的某处。如果你之前没有做过这样的事情,那么如果我完全不了解我应该如何工作的理由,那么请让我知道。

这个问题(技术方面)只有两个真正的解决方案。 假设它只是需要访问关键应用程序本身的...

  1. 硬件安全模块(HSM) - 通常是相当昂贵的,而不是简单地实现。可以是专用设备(例如nCipher)或特定令牌(例如Alladin eToken)。然后,您仍然必须定义如何处理该硬件...

  2. DPAPI(Windows数据保护API)。在System.Security.Cryptography(ProtectedMemory,ProtectedStorage等)中有这样的类。这将操作系统的密钥管理交给了操作系统 - 它处理得很好。在“USER_MODE”中使用,DPAPI会将密钥的解密锁定给加密它的单个用户。 (没有得到太多的细节,用户的密码是加密/解密方案的一部分 - 没有,更改密码不犯规不起来。)

新增:最好使用DPAPI保护您的万能钥匙,而不是直接加密应用程序的数据。并且不要忘记在您的加密密钥上设置强大的ACL ...

Microsoft Rights Management Server (RMS)也有类似的问题。它只是通过使用主密码加密其配置来解决它。 ...密码上的密码,如果你愿意的话。

最好的办法是在物理上保护钥匙所在的硬件。另外,千万不要将它写入磁盘 - 找一些方法来防止将这部分内存分页到磁盘。当加密/解密密钥需要加载到内存中时,以及不安全的硬件始终存在这种攻击场所。

像你说的那样,有硬件加密设备,但它们不能缩放 - 所有加密/解密都通过芯片。

+1

.Net中的SecureString类解决了分页到磁盘问题。 – 2008-09-30 18:41:38

您可以使用另一个使用PBKDF2之类的密码从另一个对称密钥中加密对称密钥。

让用户出示密码,生成用于加密数据的新密​​钥,使用密码生成另一个密钥,然后加密并存储数据加密密钥。

它不如使用硬件令牌安全,但它可能仍然足够好,并且使用起来非常简单。

我想我误解了你的问题。你所要求的不在应用程序如何处理其关键存储的范围内,而在于你的公司将如何存储它。

在这种情况下,你有两个明显的选择:

  • 物理:写入USB驱动器,刻录到CD等存储在物理上安全的位置。但是,您遇到递归问题:您将密钥存储在Vault的哪个位置?通常,您委派2个或更多人(或团队)持有密钥。

  • 软件:Cyber-Ark私人方舟是我公司用来存储其秘密数字信息。我们存储所有管理员密码,许可证密钥,私钥等。它通过运行未加入域的Windows“保险库”服务器,防火墙除自身以外的所有端口,并存储其在磁盘上加密的所有数据。用户通过首先对用户进行身份验证的Web界面进行访问,然后通过类似浏览器的界面与Vault服务器进行安全通信。记录所有更改和版本。但是,这也具有相同的递归问题......主管理员访问CD。这存储在具有有限访问权限的实体保管库中。

在写出之前,使用硬编码的密钥来加密生成的密钥。然后你可以在任何地方写。

是的,您可以找到硬编码的密钥,但只要您认为可以将对称密钥存储在任何地方,它的安全性并不低。

根据您的应用程序,您可以使用Diffie-Hellman方法让双方安全地达成对称密钥。

经过初始安全交换后,密钥得到认可,会话的其余部分(或新会话)可以使用此新对称密钥。

从OP应对这一answer#3

一个经授权的会员才能查看加密数据的方式,但没有他们实际知道的关键是使用密钥托管(rsa labs)(wikipedia)

总之,关键是分解成单独的部分,并给予'受托人'。由于私钥的性质,每个片段都是无用的。然而,如果需要解密数据,那么'受托人'可以将他们的部分组合成整个密钥。

我们有同样的问题,并且经历了相同的过程。
我们需要在一台计算机(客户端)上启动进程,然后登录到另一台计算机(数据库服务器)。

目前,我们认为最好的做法是:

  • 操作员手动启动客户端PC上的过程。
  • 客户端PC提示操作员他的个人登录凭证。
  • 运营商输入他的凭证。
  • 客户端PC使用这些登录到数据库服务器。
  • 客户端PC从数据库服务器请求自己的登录凭证。
  • 数据库服务器检查操作员的登录凭证是否有权获取客户机进程的凭证并将其返回给客户机。
  • 客户端PC注销数据库服务器。
  • 客户端PC使用自己的凭证登录到数据库服务器。

实际上,操作员的登录密码是关键,但它不存储在任何地方。