6

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:

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?

Many thanks.

  • Why not use something such as Stripe? – André Borie Feb 21 '17 at 13:14
  • What is the difference between Stripe and Paypal? I assume you are talking about a service provider that includes credit card storage via tokenization? The business owner is absolutely committed to his current credit card processing provider, and they don't offer the service. – zipzit Feb 21 '17 at 14:20
  • A thought: if this is a rental service, wouldn't you need to charge the card some amount regardless, and just charge more if not returned? – Bobson Feb 21 '17 at 14:43
  • 2
    You're probably better off authorizing the card for the full amount + fee, and then only settling it for the amount based on the rental. Otherwise, someone could pay with a near-maxed out card, then just walk off with your item. – Bobson Feb 21 '17 at 17:46
  • 1
    @zipzit While I work for a company that does store credit card numbers, it is a payment processor - our engineering and security budget is many, many times more than your company will be willing to spend. There's a reason people pay us money to handle this - it takes a lot of (continual) work to get right. – Xiong Chiamiov Mar 26 '17 at 22:08
6

The PCI DSS isn't expressly clear on this topic. The meaning of secure key storage and secure key management is left up to the QSA's interpretation. You may find that that one QSA considers the private KEK to be all that needs to be secured, and he treats the EKs as tokens. Or you may find a different QSA that sees every individual EK as needing to be secured, even though they've been encrypted with a KEK. We've had both kinds of auditors, and frankly, I thought the "harsher" of the two was more competent (even though I disagreed with his assessment of the risks.)

The bigger problem I see is that you're not taking into account the cost of owning this system. A complex system like this is going to take time and money to build. It will require the auditors to make a very careful examination of all the nooks and crannies of the systems, which will also take a lot of time and money. And they'll have to repeat their examination every year.

Consider that under the current rules, if you build a system that gets breached, the rental guy will be liable for 100% of the costs of all fraud associated with the breach. That means if someone steals a millionaire's card and charges a Ferrari on it, he's liable for the loss. If someone steals 10 millionaires' cards and charges one Ferrari on each of them, he's liable for the whole loss. His lawyers, of course, will immediately turn around and sue you for building an insecure system. And they will sue the QSA for incompetence at not telling them that your homemade system was insecure. So the QSA has to charge enough not only to pay for the time spent auditing the system, but also some insurance to cover their risk.

Frankly, the rental guy would be better off having his counter employees making photocopies of customer ID cards and dropping the copies into a drop-box type safe under the counter; and keeping his security cameras rolling. If a customer fails to return an item, or returns a damaged item and contests it, he'll have the evidence he needs to bring the renter into small claims court. That's a whole lot cheaper than building a PCI DSS compliant system and maintaining it. (And that's really the point of the PCI DSS - the auditor should identify and explain the risks, the business owner should carefully consider the risks, and then make wise choices.)

2

Well, referencing the "PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms" we can see the following listed for "strong cryptography"

Strong Cryptography: Cryptography based on industry-tested and accepted algorithms, along with key lengths that provide a minimum of 112-bits of effective key strength and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is “one way”; that is, not reversible). See Hashing.

At the time of publication, examples of industry-tested and accepted standards and algorithms include AES (128 bits and higher), TDES/TDEA (triple-length keys), RSA (2048 bits and higher), ECC (224 bits and higher), and DSA/D-H (2048/224 bits and higher). See the current version of NIST Special Publication 800-57 Part 1 (http://csrc.nist.gov/publications/) for more guidance on cryptographic key strengths and algorithms.

Note: The above examples are appropriate for persistent storage of cardholder data. The minimum cryptography requirements for transaction-based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure. It is recommended that all new implementations use a minimum of 128-bits of effective key strength.

Generally speaking, you can just use a symmetric encryption algorithm, your encrypting it and then decrypting it before using it, this can be done by the database.

To answer "Am I doing this correctly?" I would say no. He needs to have tokenization, it will make his life easier and cheaper, he will need to be fully PCI DSS compliance and need to do self assessments each year, which he probably won't be compliant given his reluctance to do tokenization because he likes his processor (what processor doesn't support tokenization in this day and age?). And with tokenization you don't have to worry about any cryptographic architecture since the token does not have to be cryptographically secured.

  • ref: Database encryption... have you tried to do this for a small business? From what I can see that option is only offered on Enterprise editions of database systems, and those are definitely not open source. Microsoft SQL server, Oracle, MongoDB Enterprise only. What were your costs for that service? Side note: I was really hoping to avoid the crypto architecture discussion by using RSA encoding with only the public keys stored on the server. – zipzit Feb 21 '17 at 18:32
  • 1
    @zipzit - I'm pretty sure you're going to need to contact a QSA at some point and ask them these questions. – Bobson Feb 21 '17 at 18:35
  • 1
    @zipzit you know what the fines are for not being compliant? More than the cost of that server license. That's the dilemma you have to give your client, the cost of doing the system properly and securely (if you don't, the fines are more than enough to bankrupt him if you're worrying about an enterprise license), or just switching processors and doing tokenization so you don't worry about any of that. – Ryan Kelso Feb 21 '17 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.