信用卡存储解决方案
我正在开发一个解决方案，旨在存储会员详细信息以及信用卡详细信息。我正在尽力遵守 PCI DSS。这是我到目前为止的设计：
PAN = 主帐号 == 信用卡上的长号码
- 服务器 A 是远程服务器。它存储所有成员详细信息（姓名、地址等），并为存储的每个 PAN 提供单独的密钥 A。
- 服务器 B 是本地服务器，实际上保存加密的 PAN 以及密钥 B，并进行解密。
要获得 PAN，客户端必须向两台服务器进行身份验证，向服务器 A 询问相应的密钥 A，然后将密钥 A 提供给服务器 B，服务器 B 将向客户端返回 PAN（假设身份验证成功）。 服务器 A 只会使用服务器 B 的公钥来加密密钥 A，因为它事先就拥有该公钥。 服务器 B 可能必须先发送盐，但是我不认为必须加密
我还没有真正考虑过任何实现（即编码）细节，但解决方案是使用 Java 的 Cajo 框架（RMI 的包装），这就是服务器之间相互通信的方式（目前，成员资格详细信息以这种方式传输）。
我希望服务器 B 而不是客户端进行解密的原因是，我担心解密密钥会进入客户端的 RAM，即使它在服务器上可能同样糟糕......
任何人都可以看到有什么问题吗？上面的设计呢？如果上面的内容需要改变也没关系。
谢谢
jtnire
I'm developing a solution that is designed to store membership details, as well as credit card details. I'm trying to comply with PCI DSS as much as I can. Here is my design so far:
PAN = Primary account number == long number on credit card
- Server A is a remote server. It stores all membership details (Names, Address etc..) and provides indivudal Key A's for each PAN stored
- Server B is a local server, and actually holds the encrypted PANs, as well as Key B, and does the decryption.
To get a PAN, the client has to authenticate with BOTH servers, ask Server A for the respective Key A, then give Key A to server B, which will return the PAN to the client (provided authentication was sucessful).
Server A will only ever encrypt Key A with Server B's public Key, as it will have it beforehand.
Server B will probably have to send a salt first though, however I doin't think that has to be encrypted
I havn't really thought about any implementation (i.e. coding) specifics yet regarding the above, however the solution is using Java's Cajo framework (wrapper for RMI) so that is how the servers will communicate with each other (Currently, membership details are transfered in this way).
The reason why I want Server B to do the decryption, and not the client, is that I am afraid of decryption keys going into the client's RAM, even though it's probably just as bad on the server...
Can anyone see anything wrong with the above design? It doesn't matter if the above has to be changed.
Thanks
jtnire
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
作为前言，您将在开发此程序并通过 PCI 合规性时经历一场噩梦。绝对值得考虑替代方案，例如使用可以为您存储这些卡详细信息的支付服务提供商，并使用令牌 ID 执行临时授权/结算（而不是通过“拨号信用卡机”输入它们） 。
如果您选择忽略该建议并采用 PCI 路线，那么至少要确保尽早让 PCI 批准的合格安全评估员 (QSA) 参与其中，以批准您提出的任何设计 PCI 不是您应该“尽力遵守”的东西，不幸的是，它是全有或全无的事情！
尽管如此，解决这个问题的一种方法是在盒子 A 上运行一个密钥服务应用程序。该应用程序需要输入两个“密钥管理”密钥，这两个密钥在异或在一起时形成主密钥。主密钥仅存储在 RAM 中，从未持久保存到磁盘中。
应用程序生成密钥加密密钥，这些密钥存储在盒子 A 上，并由主密钥加密。 KEK 是自动生成的（不是用户键入的内容）。 KEK 可以持久保存到盒子 A 上的磁盘上，并由主密钥加密。
卡详细信息存储在框 B 中。该框还存储数据加密密钥，用于对卡详细信息执行对称加密。 DEK 本身以加密格式存储，并使用框 A 中的密钥加密密钥进行加密。
执行加密/解密的应用程序应位于框 B 上，并在请求 KEK 之前向框 A 验证自身身份。然后使用 KEK 来解密 DEK，然后就可以进行加密/解密。
As a preface, you're going to have a nightmare of a time developing this and going through PCI compliance. It would definately be worth considering alternatives, such as using a Payment Service Provider that can store these card details for you, and perform ad-hoc authorisation/settlement using Token Ids (rather than keying them in through a 'dialup credit card machine' that you described)
If you chose to ignore that advice and go the PCI route, then at least make sure to get a PCI approved Qualified Security Assesor (QSA) involved as early as possible, to approve of whatever designs you come up with. PCI isnt something you should 'try to comply with as much as you can', its an all or nothing thing unfortunately!
That said though, one way to tackle this would be to have a key serving application running on box A. This application requires entry of two 'key administration' keys, which when xor'd together form a Master Key. Master Key is only ever stored in RAM, never persisted to disk.
The application generates Key Encrypting Keys, which are stored on box A, encrypted by the Master Key. The KEK is generated automatically (its not something that a user keys in). The KEK can be persisted to disk on box A, encrypted by the Master Key.
Card details are stored on box B. This box also stores the Data Encryption Key, which is used to perform symmetric encryption of the card details. The DEK is itself stored in an encrypted format, encrypted with the Key Encrypting Key from box A.
The application that performs encryption/decryption should be on box B, and authenticate itself to box A before requesting the KEK. The KEK is then used to decrypt the DEK, and encryption/decryption can then take place.
如果服务器 A 被黑客入侵 - 这意味着我基本上仍然可以以明文形式获取所有信用卡，或者？然后我就可以访问访问每张信用卡所需的所有个人密钥信息。
If Server A is hacked - this meansI baically can still get all credit cards in clear text, or? I have access then to all individual KEY a information that i need to access every credit card.
您可能有兴趣阅读 Bytemark 博客 有关如何存储信用卡信息的条目。
要点是持有卡信息的服务器不会泄露卡号；允许的操作是“添加新卡”、“更新或删除现有卡”和“为卡充值”——服务器连接到支付处理器本身。
You might be interested in reading the Bytemark Blog entry on how they store credit card information.
The gist is that the server holding the card information will not divulge the numbers; the allowed operations are "Add new card", "Update or remove existing card" and "Charge a card" -- the server connects to the payment processor itself.