I'm a software developer, considering writing a custom system for credit card number storage. Our intent is to be fully Payment Card Industry (PCI) compliant. I'm working with a small business owner who rents things and would like to keep a credit card # on file ensure the return of the item rented. If a customer fails to return an item on time, then they get charged per their signed rental agreement. The credit card info is purged upon merchandise return.
We are aware that some credit card processors, in addition to normal credit card processing we use for the rental payments, also offer a service for the STORAGE of credit cards. They store the credit card numbers and provide you with a token representing that card in storage. (e.g. Paypal, Stripe) This business owner already has a commitment to a credit card processor that does NOT offer that service. Changing the credit card processor to Paypal or Stripe does not appear to be an option. We also investigated credit card storage vault services (using tokens) and won't work either. $1300 / month to store 500 cards is a bit too expensive for this small business.
I've seen some key postings here:
- PCI Encryption Key Management
- Web Application encryption key management
- Storing sensitive information securely
I can see that all three of the major Cloud storage providers (Amazon Web Services, Microsoft Azure and Google Cloud) are PCI DSS compliant as an infrastructure.
I'm seriously considering using one of those services as a repository for Credit Card information. Obviously we want to be fully PCI DSS compliant. I know how to write apps and servers. I know how to add a robust login system. I know how to use published encryption libraries, for server side encryption. I know how to create a MongoDB on a separate server hosted in one of those cloud services. I know how to communicate with server via https. What I'm not clear about is the whole key storage thing.
From the first linked item above:
The encryption key (EK) you use to encrypt the data, should be itself encrypted by a key encrypting key (KEK). The encrypted EK should be stored in a protected place - this can be a file, a registry key, whatever - the important thing is restricting access to it, to the appserver's user only.
I'm a little confused by that description. I thought everything has gone to a public key / private key encoding technique. Do I assume that in the above reference, the encryption key mentioned above is actually the private key? Or am I incorrectly mixing algorithms here?
I had presumed we are using a public key / private key algorithm. I would assume I will include the public key within my server code. My intent is to store the private key totally offline in a different location (and yes, meeting the requirements for PCI-DSS 3.5.3). My tendency is to require a custom copy / paste of the private key for a credit card decode/retrieval. This is a pretty infrequent process, and will likely only be performed by the business owner.
But perhaps I'm just doing this all wrong. What is PCI-DSS "approved" algorithm for individual credit card encoding? From what I can see, the specific requirements are stated as:
The intent of strong cryptography (as defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be based on an industry-tested and accepted algorithm (not a proprietary or "homegrown" algorithm) with strong cryptographic keys...
Here are my questions.
What algorithms for public/private key style encoding are currently recommended to meet the PCI-DSS standard here?
If not public/private key encoding is some other encryption technique recommended?
Am I doing this correctly?
Any other comments, or lessons learned here?