jtn*_*ire 4 java encryption pci-dss
我正在开发一个旨在存储会员详细信息以及信用卡详细信息的解决方案.我正尽力遵守PCI DSS.到目前为止,这是我的设计:
PAN =主要帐号==信用卡上的长号
要获得PAN,客户端必须使用BOTH服务器进行身份验证,向服务器A询问相应的密钥A,然后将密钥A提供给服务器B,服务器B将PAN返回给客户端(提供的身份验证成功).服务器A只会使用服务器B的公钥对密钥A进行加密,因为它会事先得到它.服务器B可能必须首先发送一个盐,但我不认为必须加密
我还没有考虑过有关上述的任何实现(即编码)细节,但是解决方案是使用Java的Cajo框架(RMI包装器),这就是服务器之间的通信方式(目前,会员资格被转移)通过这种方式).
我希望服务器B进行解密而不是客户端的原因是我害怕解密密钥进入客户端的RAM,即使它在服务器上可能同样糟糕......
任何人都可以看到上述设计有什么问题吗？如果必须改变上述内容并不重要.
谢谢
jtnire
作为序言,您将有一个时间的噩梦发展这个并通过PCI合规.绝对值得考虑替代方案,例如使用可以为您存储这些卡详细信息的支付服务提供商,并使用令牌ID执行临时授权/结算(而不是通过'拨号信用卡机'键入它们你描述过)
如果您选择忽略该建议并采用PCI路线,那么至少要确保尽早获得PCI认可的合格安全评估员(QSA),以批准您提出的任何设计.PCI不是你应该"尽可能多地遵守"的东西,不幸的是它是一个全有或全无的东西!
尽管如此,解决此问题的一种方法是在框A上运行密钥服务应用程序.此应用程序需要输入两个"密钥管理"密钥,这些密钥在xor'd一起形成一个主密钥时.主密钥只存储在RAM中,永远不会保存到磁盘.
应用程序生成密钥加密密钥,这些密钥存储在框A上,由主密钥加密.KEK是自动生成的(它不是用户键入的内容).KEK可以保存到盒子A上的磁盘上,由主密钥加密.
卡详细信息存储在方框B上.此框还存储数据加密密钥,用于对卡详细信息执行对称加密.DEK本身以加密格式存储,使用来自方框A的密钥加密密钥加密.
执行加密/解密的应用程序应位于框B上,并在请求KEK之前向框A验证自身.然后KEK用于解密DEK,然后可以进行加密/解密.