Credit card storage solution

Question

I am developing a solution for storing membership information as well as credit card information. I am trying to do PCI DSS as much as I can. Here is my project:

PAN = primary account number == long credit card number

• Server A is a remote server. It stores all membership information (names, address, etc.) and provides an individualized key A for each saved PAN file.
• Server B is a local server and actually contains encrypted PANs, as well as key B, and performs decryption.

To obtain a PAN, the client must authenticate with the BOTH servers, request server A for the corresponding key A, and then provide the key A to server B, which will return the PAN to the client (provided that the authentication was successful). Server A will only encrypt key A with the public key of server B, since it will have it in advance. Server B may have to send the salt first, although I don't think it should be encrypted

I really did not think about any specifics of the implementation (i.e. coding), but in relation to the foregoing, however, the solution uses the Java Cajo platform (shell for RMI), so that the servers will interact with each other (at present, membership details are transferred in this way )

The reason I want server B to decrypt, not the client, is because I'm afraid that the decryption keys are in the client’s RAM, although this is probably just as bad on the server ...

Can someone see something wrong with the above design? It doesn't matter if you need to change the above.

thanks

jtnire

Answer 1

As a preface, you will have a nightmare of time developing this and passing through PCI compatibility. Of course, it’s worth considering alternatives, such as using a payment service provider that can store the data of this card for you, and perform ad-hoc authorization / calculation using Token identifiers (instead of entering them through a “credit card dialing machine” which you described)

If you decide to ignore this advice and go the PCI path, then at least be sure to take part in the PCI Qualified Security Assesor (QSA) as early as possible to approve any projects you have come up with. PCI is not something that you should "try to comply with as much as possible", it is all or nothing, unfortunately!

However, one way to solve this problem would be to have a key service application that works in Box A. This application requires you to enter two key management keys, which, when combined, form a master key. The master key is stored only in RAM; it has never been saved to disk.

The application generates Key Encrypting Keys, which are stored in block A, encrypted with the master key. KEK is generated automatically (this is not what the user types). KEK can be stored on disk in Box A, encrypted with the master key.

Card data is stored in field B. This field also stores the data encryption key, which is used to perform symmetric encryption of card data. DEK itself is stored in an encrypted format, encrypted with the encryption key of the key from block A.

An application that performs encryption / decryption must be in field B and authenticated in field A before the KEK request. Then KEK is used to decrypt the DEK, and then encryption / decryption can be performed.

Answer 2

If server A is hacked, does that mean that I can still get all credit cards in clear text or? I have access to all the individual keywords that I need to access every credit card.

Answer 3

You may be interested in reading the Bytemark Blog entry on how they store credit card information.

The bottom line is that the server containing the card information will not disclose the numbers; allowed operations: “Add a new card”, “Update or delete an existing card” and “Charge a card” - the server connects to the payment processor itself.