如何正确做好私钥管理
有没有人有实践经验或参考实施符合 PCI 的密钥管理方案的方案DSS安全标准？
鉴于遵守 PCI DSS 的公司数量众多，显然有相当多的实施方案，但试图找到它们的详细信息却很困难。当谈到存储私人数据时，讨论通常会停止在使用哪种加密算法上。之后，通常会有一个关于适当存储私钥的声明，但没有讨论实际的方法来做到这一点，或者定期更改密钥或向应用程序提供密钥等。
具体来说，我对第 3.5 和 3.6 节中的要求感兴趣。 PCI DSS 标准。
3.5.2 将加密密钥安全地存储在尽可能少的位置和形式中。
3.6.a 验证用于加密持卡人数据的密钥的密钥管理程序是否存在。注意：可以从包括 NIST 在内的各种资源中获取许多密钥管理行业标准，可以在 http://csrc.nist 中找到这些标准。政府。
3.6.4 验证是否实施了密钥管理程序，要求至少每年定期更改密钥。
我查看了 NIST 加密出版物 作为 PCI DSS 要求文档建议，但除了最近的加密密钥管理研讨会 真正可实施的方案或标准似乎并不多。
至于我想做的不是：
- 将密码+盐存储为用于身份验证的单向哈希值，
- 选择强大的对称算法进行数据加密，
- 避免首先需要存储私有数据。
- 避免使用其他机制进行密钥管理：物理安全、数据库安全、龙和巫师等。
所有这些都是有效的担忧，但在这种情况下并不是答案。我的要求的具体细节在另一个SO问题.Net 设计模式用于存储和检索每个用户的敏感数据，但这一切都归结为密钥管理，因此这是一个更精致的问题。
Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?
There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.
Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.
3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.
3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.
I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.
As to what I'm trying to do it's not:
- Store passwords + salts as one way hashes for authentication,
- Choose a strong symmteric algorithm for data encryption,
- Avoid needing to store private data in the first place.
- Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.
All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我很熟悉你所经历的痛苦。我们努力更新旧的 EFT 系统以使其符合 PCI 要求。密钥管理当然（从我的软件角度来看）是最具挑战性的部分。
我想我还偶然发现了 Martin 提出的 NIST 针对密钥管理的建议发布，并因缺乏具体示例而感到非常沮丧。
ANSI X9.17 - 金融机构密钥管理可能是与您最相关的需要，通过 PCI-DSS。不过，祝你阅读顺利，该文档是 TLA 的大量集合，我知道我读起来确实很困难。 （X9.17 每年更新一次，目前最新版本为： NIST SP 800-57 Pt. 1 Rev. 4 ）
当沮丧变成绝望时，我偶然发现了 电子货币工厂 这是一个虚构的故事，有大量相关技术参考。 第 17 章讨论X9.17可能有助于理解。
根据所有这些参考材料，我设计了一个令我们的审计员感到满意的密钥管理系统。设计文档相当冗长，但总而言之，其想法是让数据加密密钥受到密钥加密密钥的保护，并且密钥加密密钥存储在物理上独立的盒子上，该盒子本身受到主密钥的保护。
我的实现是在 Windows 机器上运行一个密钥服务器应用程序。该应用程序需要输入两个单独的“密钥服务器主密钥”才能使用。这些密钥只有密钥服务器管理员知道。这些密钥被异或在一起生成主密钥，该主密钥仅在应用程序运行时存储在受保护的内存中。然后，应用程序可以自动生成加密强度高的密钥加密密钥，这些密钥使用主密钥以加密形式存储。
需要加密的应用程序将从密钥服务器请求密钥加密密钥。应用程序使用 KEK 来加密/解密数据加密密钥，该密钥可以与应用程序数据一起安全存储。
祝你好运。我希望您也觉得这是一个有趣的挑战！
I'm familiar with the pain you're going through. We struggled to update an old EFT system towards PCI compliance. Key management was certainly (from my software point of view) the most challenging part.
I think I also stumbled into the NIST Recommendations for Key Management that Martin posted, and got incredibly frustrated with the lack of concrete examples.
ANSI X9.17 - Financial Institution Key Management is probably the most relevant to your needs, with PCI-DSS. Good luck reading it though, the document is a massive collection of TLA's which I know I certainly struggled to read. (X9.17 is updated yearly, and latest version is now: NIST SP 800-57 Pt. 1 Rev. 4 )
When frustration turned to desperation I stumbled into The Electronic Money Mill which is a fictional tale, with a good number of relevant technical references. Chapter 17 discusses X9.17 and may help with the understanding.
From all this reference material I designed a key management system that our auditor was pleased with. The design documents are fairly lengthy, but in summary the idea is that you have your Data Encrypying Key protected by a Key Encrypting Key, and the Key Encrypting Key is stored on a physically separate box, itself protected by a Master Key.
My implementation was to have a Key Server application running on a windows box. This application required entry of two separate 'key server master keys' before it could be used. These keys would be known only to the key server administrators. These keys are xor'd together to generate the Master Key, which is stored only in protected memory whilst the application is running. Application can then automatically generate cryptographically strong Key Encrypting Keys, which are stored in encrypted form using the Master Key.
Applications that have a need for encryption will request a Key Encrypting Key from the Key Server. The KEK is used by the application to encrypt/decrypt the Data Encrypting Key, which can be stored securely with the application data.
Good luck. I hope you also find it an interesting challenge!
您是否看过 NIST SP 800-57，密钥管理建议？
Have you seen NIST SP 800-57, Recommendation for Key Management?