Credit Card storage solution

Posted by jtnire on Stack Overflow See other posts from Stack Overflow or by jtnire
Published on 2010-03-24T10:59:30Z Indexed on 2010/03/24 11:03 UTC
Read the original article Hit count: 248

Filed under:
|
|

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

© Stack Overflow or respective owner

Related posts about java

Related posts about encryption