This is page 2 of:
Is Point-To-Point Encryption Ready For Prime Time?
This means that, properly implemented, P2PE could potentially reduce a merchant’s PCI scope to the card reader at the POS. Implementation may be complicated and will likely involve an upgrade to the POS. Once the payment card is swiped though, the data is encrypted and remains encrypted until it reaches the destination. Decryption must not be feasible at any point between the point of encryption and the destination. Because only the P2PE provider (i.e., the “destination”) can decrypt the data, the plan is that the rest of the merchant’s systems (excluding any cardholder database) should be out of PCI scope.
Retailers need to allow for key-entered transactions, either because of failure to read the magnetic stripe or chip or because of a mail or telephone order, so the POS will likely remain in PCI scope. Note, too, that for the encrypted data to be out of scope the merchant must have no ability to decrypt the data. That function has to reside with an unrelated entity; in most cases, the P2PE provider.
P2PE has the potential to reduce PCI scope to a minimum for retailers that have no need to retain cardholder data. But what about the many retailers that do use cardholder data? Those merchants face a more complicated scoping challenge.
The PCI Council’s white paper addresses this question in an important warning about PCI scope: “It is essential that merchants understand their entire card transaction environment and ensure that all cardholder and sensitive authentication data is identified, that there is a realistic understanding of the threats, and that the organizational security posture and risk management are appropriate.”
Let’s consider a retailer that implements P2PE properly and reduces its “transmission” PCI scope to the POS. Like many retailers, it has a number of marketing and other back-office applications that use cardholder data. Assuming the retailer wishes to keep these applications, it faces a choice.
The retailer could have its acquirer return the transaction detail, including the required cardholder data. Unfortunately, that action just threw at least some of the retailer’s firewalls, network and any number of servers, switches and other devices back into PCI scope. Alternatively, the retailer could have the data returned in the form of tokens, instead of encrypted cardholder data. Properly executed (are you getting tired of that phrase yet?), this tokenization may avoid or minimize the increase in PCI scope.
-Marc
October 14th, 2010 at 8:44 am
Another important consideration for some (but not all) retailers is how they would handle “fallback” or “stand in” processing when the payment processor is off-line in a P2PE architecture. By definition, the merchant must somewhere queue up those transactions even if they are at that point encrypted using the P2PE scheme. This now would seem to constitute card data at rest, and the guidance in the white paper appears to be explicit in that it’s addressing only card data in transmission – not when it comes to rest as is required in a fallback situation. For example, in one section the PCI SSC in saying what the white paper is not writes that it is not “an analysis of how P2PE components may affect stored encrypted cardholder data”. Now, I would argue that if the data is encrypted at the initial point of interaction and it needs to come to rest (in encrypted form) for a short time in the course of fallback processing it does not represent qualitatively any more risk than if it were simply moving through systems in real time. A network sniffer can just as easily capture (P2PE) encrypted card data while in transmission as someone can copy encrypted card data while it is at rest – and both should be equally useless. However, it appears that the initial intention of the white paper does not take this position (at least, not explicitly). This is something that will need to be discussed by the merchant community with the PCI SSC in the months to come to see if some accommodation can be made for fallback processing.
October 14th, 2010 at 9:02 am
If merchants are to go through the process of replacing all PINPads and other card-swipe devices so that they are P2PE capable, as is reasonable, they will want to do this exactly once (at least, within a reasonable time horizon). Visa and MasterCard have continued to delay providing the U.S. market with a “roadmap” as to what future technologies (if any) could/will replace the magnetic stripe cards we all use today. If Visa and MasterCard plan on moving to something other than magnetic stripe cards (such as EMV), they need to make that intention (or lack of intention) known now so that merchants can avoid replacing PINPads one time for P2PE and then a second time for a new card technology such as EMV. In my experience, large merchants will be quite hesitant to move ahead with the time/money/effort investment required by P2PE in an environment of such uncertainty. If Visa and MasterCard made their intentions clearly known, I believe this would clear another major hurdle that could otherwise impede the adoption of P2PE – to do otherwise would be unfortunate, as P2PE in my mind represents the potential for the largest increase in effective payment security we’ve ever seen.
October 14th, 2010 at 9:36 am
P2PE shows a lot of promise in combating the major threats to integrated POS environments – key loggers and memory parsers. However, the problem that has not been solved particularly well is determining which cards to encrypt. Merchants with integrated POS environments often process a variety cards such as loyalty, fleet, gift, house, that trigger specific POS operation when identified. Encrypting these cards breaks the POS functionality, and thus the added value the merchants are providing their customers. Until this conundrum is solved—and in a manner that delivers the eagerly anticipated PCI scope reduction needed to justify the expense—we may not see mass adoption of P2PE by merchants with integrated POS.
October 14th, 2010 at 6:30 pm
@Jim, Thanks for your comment and pointing out the issue with fallback/stand-in processing. Like manual key entry, a good solution would have to allow for this as the only alternative seems to be going dark (or at least no plastic) during outages. However, there may be a ray of hope: since the data are encrypted, and the merchant still has no ability to decrypt, even these data might be viewed as out of scope. Then, of course, you still have the issue of the storage of sensitive authentication data (mag stripe, PIN block) during that time. I’m afraid I don’t have an easy answer, either, but you will want one before committing.
Good point, too, on the hardware purchase. Without a clear technology roadmap it is difficult to ask merchants to make large purchase decisions – or even to ask the card brands for interchange incentives as they have done in the past.
@Ernie, a terrific point on trying to blend P2PE with an integrated POS. Using preferential routing can cause some complications. I can think of a few alternative approaches, but each has scoping implications and may reduce the expected benefits or cause operational problems…maybe you are giving me an idea for a future column!
October 15th, 2010 at 1:54 am
Manual card entry is indeed something that calls for some consideration – but in my experience would be something that many merchants might be willing to forego if they could otherwise relieve themselves of (essentially) all store-level PCI DSS scope. In fact, a significant number of merchants already do not allow this due to the potential for abuse. Of course, one could perhaps use the PINPad to perform manual entries – but then you are drifting into putting more substantial logic into the PINPad applications/firmware which raises its own sets of issues. If push comes to shove, old-school “knuckle-busters” (i.e., manual imprinters) provide a simple way to accept payment in those relatively rare instances of defective cards and many merchants keep at least one around today as a last-line-of-defense backup to their electronic systems.
October 15th, 2010 at 1:58 am
Ernie’s comments are indeed accurate – another of the non-trivial hurdles to overcome in order to implement P2PE in an integrated POS environment would be a fundamental re-architecting of the relevant protocols to not only handle the encryption aspects of P2PE but also the legitimate needs of the POS system for aspects of the card data they would no longer be directly privy to. At a minimum, the POS needs the last part of the PAN and perhaps the type of card in order to display this information on the customer’s receipt. If switching or routing of some sort is occurring at the site to support any of a variety of payment scenarios (e.g., certain loyalty programs, fleet cards, local cards, multiple payment processors, etc.) this re-architecting becomes even more significant. Note that the guidance provided by the PCI SSC appears to explicitly discuss this in section 5.2.3, saying that any entity performing “white listing” of certain card types (which I believe would reasonably include any type of card-type-based switching/routing) would still be subject to PCI DSS review. This would seem to have profound implications for retail architectures that employ store-resident payment switches or electronic payment servers and wish to implement P2PE to reduce their store-level PCI DSS scope.
My thinking is that the necessary paradigm would likely have to be one where any payment-related information required by the POS (whether to print receipts, make routing decisions, etc.) would have to be provided back to the POS from the payment processor(s), similar to how authorization codes are provided back today. And in certain circumstances this could now require multiple transactions to a single payment processor (or multiple payment processors) in order to complete a single purchase. It would not be easy to implement such a change in thinking, but if done correctly I think it could hold up as a fairly elegant approach – especially when considered against the benefit of essentially eliminating store-level PCI DSS scope.
October 15th, 2010 at 8:55 pm
Jim,
Are you suggesting encrypting everything? This may not always be desirable, and will require a paradigm shift in the system.
For now, the most likely short-term solution is a white-list. There are a lot issues with updating the white-list. The white-list should be used along with a black-list (BIN ranges that must be encrypted regardless of the white-list). One can only add entries to the black-list. If the encryption device is tamper resistant, meaningful authentication can be done when updating the white-list or the black-list. In case the white-list is not up to date the processor can recognize this. The processor can then send back the BIN and ask if the POS wants decrypted data.
Significantly reducing PCI scope is hard but should not be the only reason for P2PE. Actual merchant data security can be greatly improved with a reasonable P2PE solution.
October 18th, 2010 at 5:09 pm
The flexibility of selecting their tokenization vendor may be preferred by some retailers but acquirers that offer integrated tokenization solutions are very compelling from security, cost and convenience perspectives. Tokenization is destined to be a commoditized service and many retailers will not be willing to contract with a third-party gateway provider for it. In addition to the vendor management overhead, a gateway based tokenization solution would also introduce yet another single point of failure into the payment processing chain. This is an undesired side-effect since tokenization is intended to increase service reliability.
The integration of tokenization and payment processing on the same platform leverages the benefits of centralized data management, reduces the vendor relations that the retailer needs to maintain and provides a better level of security by reducing the number of service providers that store sensitive cardholder data. The retailers’ ability to move from one acquirer to another can better be addressed by token portability mechanisms, which are limited today. An easy-to-use token portability mechanism will practically enable retailers to enjoy the flexibility of changing their acquirer or payment processors without the concern of vendor lock-in due to tokenization.
October 21st, 2010 at 7:53 am
Actually, I am indeed suggesting the possibility of an “encrypt everything at the point of swipe” paradigm – as George says a major shift in philosophy, to be sure, but one that I think offers so much to many classes of merchants (especially, large ones with integrated POS systems – and doubly so in franchised business models) that its benefits could well outweigh the one-time effort involved in implementing P2PE across the entire payment processing chain. You are absolutely correct that, as I alluded to, there are a number of common scenarios (e.g., multiple payment processors, loyalty program recognition, fallback processing, etc.) that would need to be fundamentally rethought and their transaction protocols reworked to accommodate them. Although I would like to believe that merchants would choose to implement P2PE solely on the merits of it increasing the effective security of their environment (which it clearly does, dramatically) my experience working with major merchants leads me to think they simply will not undertake this without a significant carrot to justify the effort – and the only carrot I’ve ever seen that is big enough to entice them would be the elimination of store-level PCI DSS scope.
October 21st, 2010 at 9:26 am
As one small evidence of the challenges that many Level 3 & 4 organizations face and why I believe an “encrypt everything and take the store out of the PCI DSS compliance loop” approach could be so valuable, I offer some comments from Gray Taylor who is the Executive Director of the Petroleum-Convenience Alliance for Technology Standards (PCATS):
“PCI is simply too technical and complex, and the majority of our small retailers simply don’t have the expertise or resources to comply – and no amount of education will overcome this…to believe that mom and pop retailers can re-design local area networks, monitor rogue wireless access points and manage firewalls for security is absurd and shows how out of touch with small business PCI has become…”
The rest of the associated article can be found at http://bit.ly/atKA9W