对称密钥存储 [英] Symmetric key storage

问题描述

我的公司将为我们的客户存储敏感数据，并将使用托管的.NET加密算法类之一对数据进行加密.大部分工作已经完成，但是我们还没有弄清楚如何/在哪里存储密钥.我已经做了一些简单的搜索和阅读，看来硬件解决方案可能是最安全的.有人对密钥存储解决方案或方法有什么建议吗?

My company is going to be storing sensitive data for our customers, and will be encrypting data using one of the managed .NET encryption algorithm classes. Most of the work is done, but we haven't figured out how/where to store the key. I've done some light searching and reading, and it seems like a hardware solution might be the most secure. Does anyone have any recommendations on a key storage solution or method?

谢谢大家的回复.

spoulson，问题实际上是您提到的两个范围".我想我应该更清楚一些.

spoulson, the issue is actually both the "scopes" that you mentioned. I suppose I should have been clearer.

数据本身以及对其进行加密和解密的逻辑被抽象到ASP.NET配置文件提供程序中.此配置文件提供程序既允许加密的配置文件属性，也允许纯文本属性.加密的属性值以与纯文本完全相同的方式存储-显而易见，它们已经被加密了.

The data itself, as well as the logic that encrypts it and decrypts it is abstracted away into an ASP.NET profile provider. This profile provider allows both encrypted profile properties as well as plain text ones. The encrypted property values are stored in exactly the same way the plain text ones are - with the obvious exception that they've been encrypted.

也就是说，出于以下三个原因之一，将需要能够调用密钥:

That said, the key will need to be able to be summoned for one of three reasons:

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

我想象的方式是没人真正知道密钥-会有一块软件控制数据的实际加密和解密.也就是说，密钥仍然需要来自 somewhere .

The way I'm imagining it is that nobody would ever actually know the key - there would be a piece of software controlling the actual encrypting and decrypting of data. That said, the key still needs to come from somewhere.

全面披露-如果您还不能确定，我以前从未做过这样的事情，因此，如果我完全不理解该如何运作，请告诉我.

Full disclosure - if you couldn't already tell, I've never done anything like this before, so if I'm completely off base in my perception of how this should work, by all means, let me know.

推荐答案

对于此问题(在技术方面)只有两个真正的解决方案. 假设只有应用程序本身需要访问密钥...

There only two real solutions for (the technical aspect of) this problem. Assuming it's only the application itself that needs access the key...

1. 硬件安全模块(HSM)-通常非常昂贵，并且实施起来并不容易.可以是专用设备(例如nCipher)或特定令牌(例如Alladin eToken).然后您仍然必须定义如何处理该硬件...

1. Hardware Security Module (HSM) - usually pretty expensive, and not simple to implement. Can be dedicated appliance (e.g. nCipher) or specific token (e.g. Alladin eToken). And then you still have to define how to handle that hardware...

DPAPI(Windows数据保护API). System.Security.Cryptography中有一些此类(ProtectedMemory，ProtectedStorage等).这将密钥管理交给了操作系统-并且处理得很好.在"USER_MODE"中使用时，DPAPI会将密钥的解密锁定到对其进行加密的单个用户. (无需太详细，用户密码是加密/解密方案的一部分-否，更改密码不会使它弄虚作假.)

DPAPI (Windows Data Protection API). There are classes for this in System.Security.Cryptography (ProtectedMemory, ProtectedStorage, etc). This hands off key management to the OS - and it handles it well. Used in "USER_MODE", DPAPI will lock decryption of the key to the single user that encrypted it. (Without getting too detailed, the user's password is part of the encryption/decryption scheme - and no, changing the password does not foul it up.)

添加:最好使用DPAPI保护您的主密钥，而不是直接加密应用程序的数据.并且不要忘记在加密密钥上设置强大的ACL ...

ADDED: Best to use DPAPI for protecting your master key, and not encrypting your application's data directly. And don't forget to set strong ACLs on your encrypted key...

这篇关于对称密钥存储的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！