我正在开发一种旨在存储会员详细信息以及信用卡详细信息的解决方案。我正尽力遵守PCI DSS。到目前为止，这是我的设计：
PAN =主要帐号==信用卡上的长号
要获得PAN，客户端必须使用BOTH服务器进行身份验证，向服务器A询问相应的密钥A，然后将密钥A提供给服务器B，服务器B将PAN返回给客户端（提供的身份验证成功）。 服务器A只会使用服务器B的公钥对密钥A进行加密，因为它会事先得到它。 服务器B可能必须先发送一个盐，但我不认为必须加密
我还没有真正想过有关上述的任何实现（即编码）细节，但是解决方案是使用Java的Cajo框架（RMI包装器），这就是服务器之间的通信方式（目前，成员资格）细节以这种方式转移。）
我希望服务器B进行解密而不是客户端的原因是我害怕解密密钥进入客户端的RAM，即使它在服务器上可能同样糟糕......
任何人都可以看到上述设计有什么问题吗？如果必须改变上述内容并不重要。
由于
jtnire
答案 0 :(得分：6)
作为序言，您将有一个时间的噩梦发展并遵守PCI合规性。绝对值得考虑替代方案，例如使用可以为您存储这些卡详细信息的支付服务提供商，并使用令牌ID执行临时授权/结算（而不是通过'拨号信用卡机'键入它们你描述过）
如果您选择忽略该建议并采用PCI路线，那么至少要确保尽早获得PCI认可的合格安全评估员（QSA），以批准您提出的任何设计。 PCI不是你应该“尽可能多地遵守”的东西，不幸的是它是一个全有或全无的东西！
尽管如此，解决此问题的一种方法是在框A上运行密钥服务应用程序。此应用程序需要输入两个“密钥管理”密钥，这些密钥在xor'd一起形成主密钥时。 Master Key只存储在RAM中，永远不会保存到磁盘上。
应用程序生成密钥加密密钥，密钥加密密钥存储在框A上，由主密钥加密。 KEK是自动生成的（它不是用户键入的内容）。 KEK可以保存到方框A上的磁盘上，由主密钥加密。
卡详细信息存储在方框B中。此框还存储数据加密密钥，用于对卡详细信息执行对称加密。 DEK本身以加密格式存储，使用方框A中的密钥加密密钥加密。
执行加密/解密的应用程序应位于方框B上，并在请求KEK之前向方框A进行身份验证。然后KEK用于解密DEK，然后可以进行加密/解密。
答案 1 :(得分：1)
如果服务器A被黑客入侵 - 这意味着基本上仍然可以获得所有明文信用卡，或者？然后，我可以访问所有个人密钥，我需要访问每张信用卡。
答案 2 :(得分：0)
您可能有兴趣阅读有关如何存储信用卡信息的Bytemark Blog条目。
要点是持有卡信息的服务器不会泄露数字;允许的操作是“添加新卡”，“更新或删除现有卡”和“为卡充电” - 服务器连接到支付处理器本身。