1

The promise of a good (even certified) PCI P2PE v2 solution is that the merchant does not have access to the keys which encrypted the Card Holder Data (CHD) and the Sensitive Authentication Data (SAD) allowing some to say the now encrypted CHD and encrypted SAD no longer need to be protected according to PCI DSS and allowing the encrypted data to flow around backend systems (where it would have not been stored prior to P2PE) is now okay.

My question is whether this is true? And for those that say yes, what about the PCI DSS 3.2 requirement that SAD not be stored after authorization even if encrypted? This last point is what I'm really interested in. Because the P2PE v2 spec says it does not override PCI DSS. Thoughts?

  • Can you provide a reference where "some say the now encrypted CHD and encrypted SAD no longer need to be protected according to PCI DSS"? Knowing who said that and what they said around it are probably very important for answering your question. It may be saying simply "encrypted CHD/SAD for which you don't have the key is just a binary blob and not CHD/SAD" – gowenfawr Feb 19 '16 at 14:58
  • The "some say" have been personal conversions with the security teams at large merchants and some P2PE component providers. I say component provider and not solution provider as they mean different things to PCI P2PE v2. Anyway, the merchants want to think they're investing in bullet proof technology and now free to do what they please with payment data. And Component providers have something to sell and want the merchant customer to feel as if they're buying a secure solution. I'm not knocking anyone here, but just want to know what's really going to happen in a merchant PCI P2PE audit. – Mark E Feb 19 '16 at 15:27
  • @MarkE Well, I think that there's a strong limiting practical factor as to why or how merchants could or would store or use the encrypted data produced by a P2PE cardreader during a card transaction. Which is: what good could the merchant gain from doing so? The merchant doesn't possess the key to decrypt the sensitive card information in the blob, after all. And that encrypted output can't successfully be stored & replayed by a merchant to perform any future transactions (either proper or unauthorized). – mostlyinformed Apr 19 '16 at 23:42
1

As with most things PCI, it's a matter of scope.

If the P2PE solution encrypts the CHD/SAD with a key that is not accessible to the merchant, then the merchant's handling of that encrypted blob is not subject to PCI DSS. They can and will store and transmit it - without PCI scope implications - on its way to the service provider or 3rd party which has the corresponding key. That service provider will presumably decrypt it, tokenize it, and hand back a token to the merchant for later use. Obviously, the service provider is in scope and has to handle the data in line with the PCI DSS, whether encrypted or unencrypted.

The way you've worded the question is a little problematic. Encrypted CHD and encrypted SAD are always in scope for the party that holds the key. If you don't hold the key, they're not encrypted CHD/SAD; they're opaque blobs.

And the pivotal point, of course, is that the P2PE solution needs to encrypt before the merchant could access the data, and with keys that are securely out of reach of the merchant. So a hardware dongle that plugs into your phone and encrypts is good; a hardware dongle that plugs into your phone and hands card data to an app on your phone to encrypt is not.

As usual, IANAQSA disclaimer applies.

  • I agree when a merchant doesn't possess the decryption keys it takes the sensitive payment data out of DSS scope, the gray area I'm concerned with is relying on the solution being implemented perfectly. Most large merchants that I talk with are implementing Merchant Managed Solutions, meaning they're using certified components and applications, but the merchant is on the hook for implementing the P2PE solution correctly. But mistakes happen and a pinpad might send clear data into a non PCI environment if the merchant isn't being careful and forgetting that PCI DSS still applies. Thoughts? – Mark E Feb 19 '16 at 16:02
  • That's always the case with the entire PCI DSS - if you think you're doing it right, but you're mistaken, you're out of compliance. Ideally, your QSA notices, points it out to you, and you fix it. What you're zeroing in on is the fact that devices designed to sweep the complexity away tend to fail spectacularly quietly sometimes... That is unavoidably true everywhere. – gowenfawr Feb 19 '16 at 16:29

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.