如何正确地做私钥管理 [英] How to properly do private key management

查看:314
本文介绍了如何正确地做私钥管理的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有任何人获得实践经验或参考实施密钥管理方案,将符合 PCI DSS 安全标准?



由于符合PCI DSS的公司数量,显然有很多实现,但试图找到它们的细节是很困难的。当它下降到存储私人数据时,讨论通常停止在使用哪种加密算法。在这之后,通常有一个关于适当存储私钥的声明,但没有讨论实际的方法,或周期性地更改密钥或向应用程序提供密钥等。



具体我对PCI DSS标准第3.5和3.6节的要求感兴趣。


3.5.2安全地存储加密密钥最少的位置和形式。



3.6.a验证用于加密持卡人数据的密钥的密钥管理过程的存在。注意:许多行业标准的密钥管理可以从各种资源,包括NIST,可以在 http://csrc.nist .gov



3.6.4验证密钥管理程序是否已实施,至少每年要求定期更改密钥。


我看过 NIST加密出版物作为PCI DSS要求文件建议,但除了最近的一份加密密钥管理研讨会似乎没有太多的实际可实现的方案或标准的方式。



对于我想要做的不是这样:


  1. 将密码+ salt用作身份验证的单向哈希值,

  2. 选择强大的数据加密算法,

  3. 避免首先存储私人数据。

  4. 避免使用其他机制(物理安全,数据库安全,龙和向导等)进行密钥管理。

所有这些都是有效的问题但在这种情况下不是答案。我的要求的螺母和螺栓在一个不同的SO问题用于存储和检索敏感的每个用户数据的Net设计模式,但这一切都归结为密钥管理,因此这个更精致的问题。

解决方案

我很熟悉你经历的痛苦。我们努力更新一个旧的EFT系统,以符合PCI。密钥管理当然是(从我的软件的角度)最具挑战性的部分。



我想我也偶然进入了 NIST对关键管理的建议,他对缺乏具体的例子感到非常沮丧。



ANSI X9.17 - 金融机构密钥管理可能与您的需求最相关,与PCI-DSS。



当挫折转向绝望时,我偶然发现了电子货币工厂,这是一个虚构的故事,有很多相关的技术参考。 第17章讨论了X9.17并可能有助于理解。 / p>

从所有这些参考资料中,我设计了一个我们的审计师很满意的密钥管理系统。设计文档相当冗长,但总而言之,您的数据加密密钥受密钥加密密钥保护,密钥加密密钥存储在一个物理上独立的盒子上,该盒子本身由主密钥保护。



我的实现是让一个Key Server应用程序在Windows上运行。此应用程序需要输入两个单独的密钥服务器主密钥才能使用。这些密钥只有密钥服务器管理员才知道。这些密钥被一起生成主密钥,主密钥在应用程序运行时仅存储在受保护的存储器中。然后,应用程序可以自动生成密码强的密钥加密密钥,这些密钥使用主密钥以加密形式存储。



需要加密的应用程序将请求密钥加密密钥从密钥服务器。 KEK由应用程序用于加密/解密数据加密密钥,可以使用应用程序数据安全存储。



祝你好运。我希望你也觉得这是一个有趣的挑战!


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:

  1. Store passwords + salts as one way hashes for authentication,
  2. Choose a strong symmteric algorithm for data encryption,
  3. Avoid needing to store private data in the first place.
  4. 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.

解决方案

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.

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!

这篇关于如何正确地做私钥管理的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆