Using a Public-Key-Encryption browser side to avoid PCI compliance

Question

We're developing a web application in which certain not logged users (clients) need to send their credit card details to other users (merchants) - which, we'll assume, are PCI compliant.

We are looking into getting PCI compliance, but the process will surely needs a lot of time. Therefore we are investigating other solutions which don't require us getting a certification and protect us from getting sensible data stolen.

Our plan is to:

• Make the merchant generate a private and a public key
• Store the private key inside his browser using localstorage (and provide a mean to backup it)
• Provide the public key on the form used by a client
• Before the client send the data, encrypt everything with the merchant public key
• Store the encrypted data in our server
• Provide the encrypted data to the merchant
• Make the merchant decrypt the data in his browser using his private key

The idea was to use JavaScript and the library jsencrypt.

Do you see security issues in this workflow? Do you think we still need PCI compliance when employing a system like that? The reasoning is that, for anyone without the private key, those are just random bytes.

The only attack I can think of is someone compromising the server and replacing a merchant public key with his own key. But he could as well steal a token for another payment gateway and fake the communication needed to do something nasty.

We know about services like Paymill, Braintree and Stripe (which offer pretty good client side libraries) but they're not fitting for our solution (or better: they're alternative we'll make available for merchants - but it should be up to them to decide).

Thank you in advance

EDIT: I totally agree with you guys and I'd rather work with thirdy party solutions.

The problem is that we're working in a market in which most of our competitors are small companies working without PCI compliance (and most of them even without HTTPS!!). Our competitors simply receive CC data, store them and give access to the users.

We know about the risks of such approach, but the users don't and they prefer their solutions to ours because they'd rather have the whole CC data, instead of just having buttons to execute actions.

Answer 1

(Disclosure, I work at Braintree)

If a server is providing a form that customers will enter credit card numbers into then that server falls within PCI scope. This is regardless of if you encrypt the data in the browser. The reasoning here is that an attacker can modify the page that is sent to the browser to siphon credit card data out of the page DOM before encryption.

You would need to work with a qualified security accessor (QSA) or your merchant account provider to know what your PCI process will look like. If you're processing under 1 million transactions then it would likely be a self-assessment process. The determination of which self-assessment questionnaire (SAQ) to fill out is based on how much access to the cardholder data you have and if you store it.

Answer 2

There are many 3rd party payment processors that allow you to transparently use their forms and processing - including paypal, google, worldpay, and many others. This can be pretty much transparent to the user if configured correctly. This is the best way of side-stepping the PCI requirements - never process any of the card information...

There are some problems with your scheme:

• First you must have assurance that the page and code has not been tampered with including any dependent libraries. So HTTPS at a minimum but also good change control practices etc.
• Secondly any XSS, XSF, MITB at the client could steal their private key.

Even large organisations are often choosing to mitigate the card handling risk by using 3rd party processors...

Answer 3

If you're storing the card data on your own servers, even if it's encrypted and you don't have the key to decrypt it, then you need to comply with the most elaborate version of the PCI standards and use SAQ-D. I would suggest that you don't store the card data at all, but get the merchant to store it for you. Then you should only need to use SAQ-C.

Answer 4

John Downey has given the best answer but just to expand on the biggest problem with this part of the workflow:

Make the merchant generate a private and a public key

Store the private key inside his browser using localstorage

So, lets say you have a dozen merchants with public and private keys stored in their browsers.

You don't store their keys but your server has a security hole of some kind.

An attacker gets control of your server.

The attacker modifies the pages that your merchants will use, adding some of their own javascript/etc.

The next time the merchants log in, the javascript retrieves their private key and sends it to the attacker.

The attacker now has almost all the private keys.

All data sent to the merchants is now open to them because they were able to gain control of your server.

Answer 5

PCI standards exist for a reason. While the process of achieving that level of security may be arduous, it is necessary to protect your client's data. Let's be clear about that; it's not just your data, it is data that your clients have entrusted to your care, and if you fail to secure it using reasonable best practice, your company is opening itself to huge, crippling levels of liability.

If you don't want to do everything involved in payment processing, you are far better off working with a payment vendor. They can make the payment process easy and seamless these days, with minimal grief for your clients.