P2PE Challenges – Looking at Endpoint Devices
The Payment Card Industry Security Standards Council (PCI SSC) made several significant developments in their point-to-point encryption (P2PE) program this year, with assessor training, releasing the program guide, and opening up their report submission portal for P2PE assessment reports.
Somewhat interestingly, the market hasn’t shown much enthusiasm for this. I think we can attribute this to a few particular factors, most of which center around endpoint devices. This proves somewhat convenient, as I said in my last blog post that I’d discuss the first of the six domains in my subsequent post.
For a PCI SSC-listed P2PE solution, the Solution Provider (which the PCI SSC has elected to use as a proper noun) must work with a PCI PIN Transaction Security (PTS) approved point of interaction (POI) with secure reading and exchange of data (SRED) functionality. Looking at that last sentence made me think that I don’t even speak English any longer.
Anyhow, all that muck means that the card reader device that does the encryption must undergo a PCI PTS assessment that includes the functionality called Secure Reading and Exchange of Data.
Here’s the first interesting, and sticky, point: a PTS validation takes some serious doing. PCI PTS evaluations look at PIN entry devices, unattended payment terminals, hardware security modules and the like. The PTS core modules look at things like the device’s ability to deal with tampering attacks.
The device manufacturer can expect to send the PTS lab three working devices, which the lab will, as part of the testing, destroy by cutting, drilling and otherwise attempting to break by tampering.
PTS approval also means that the device has a battery backup measure to respond to tampering: in the event that it detects an attempt to tamper with it, it relies on that auxiliary power source to electronically wipe out its stored encryption key values, lest they fall into the hands of the attacker.
While the tamper testing sounds like fun, what this means is that PTS-approved devices probably cost more than your garden-variety $8 USB card reader. They probably cost a lot more than even encrypting card readers that don’t have those particular security measures.
This may strike some as excessive, but I can see why the PCI SSC wanted this. The whole point is that the merchant cannot get access to the decryption keys under any circumstances. This means that the attacker who compromises the merchant environment and has free rein over the merchant’s systems or networks can’t get at the encryption keys.
The PTS validation for the endpoint device acts as the assurance mechanism for that. And we all know there are some terribly effective attacks against PIN pads and the like. So the prospective Solution Provider needs to find a device that meets this criterion as an entry point into P2PE, which seems to have turned off several prospective solution providers.
This really is too bad, because I’ve had several merchant customers and prospects contact us looking for PCI-listed P2PE solutions and currently there are none. Lots of companies have partnered with payment processors and acquirers to offer end-to-end encryption solutions and they market these solutions as effective for both protecting payment data and reducing a merchant’s PCI DSS scope.
This leads us to an interesting technicality. The PCI SSC asserts that only listed, validated P2PE solutions effect scope reduction for merchants unless the merchant’s acquirer or payment brand says otherwise. And if you’ve been following along at home, you know that the PCI SSC manages the standards and the payment brands enforce compliance.
So lots of organizations have to wonder why they’d use a listed P2PE solution if their acquirer partners with some other endpoint encryption solution.
Or why they’d bother at all, since even Girl Scouts now sell cookies using their mom’s iPad with Square (completely true story according to PCI SSC CTO Troy Leach at the 2012 Community Meeting in Orlando).
Ultimately, I think the market can bear a variety of solutions, including listed P2PE offerings. I think it offers a lot of rigor in payment security that will do a lot of good things for card-present payment security.
I’ve got no axe to grind with companies that offer their own end-to-end encryption solution; they’re probably doing lots of smart things with respect to encryption and key management, and I imagine you could meet all of the PCI DSS requirements using them.
Whether or not these solutions prove effective at reducing scope for PCI DSS by truly preventing the merchant (or the attacker) from getting access to the key depends on the particulars of a solution. If we were to review it as part of a P2PE assessment, we would know what sort of protections it has. Without that review, it’s anyone’s guess.