Credit Card storage solution

Question

Hi Everyone,

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

Answer 1

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.

Answer 2

You might be interested in reading the Bytemark Blog entry on how they store credit card information. Unfortunately, there's no direct link.

The post is on page two at the moment, search for "Proper credit card processing on the cheap".

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.

Answer 3

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.