advertisement
advertisement

After Seven Months, Why Does The PCI Council Yet To Have Anyone P2PE Validated?

Written by J. David Oder
February 8th, 2013

This GuestView column is from J. David Oder, the CEO of Shift4 Corp., an independent payment gateway company.

For the past two years, the Payment Card Industry Security Standards Council (PCI SSC) has been taunting merchants with offers of a specialized (and simplified) Self-Assessment Questionnaire (SAQ) for those using “validated P2PE” approaches. At first, the council told merchants to wait while it drew up plans to validate the products. Then—finally—seven months ago, PCI SSC released its standards and told merchants to go right ahead and pick one of these validated options. There’s only one problem: As of Thursday (Feb. 7), the council hadn’t validated any.

That’s right. Seven months after the standards were released and nearly two full years from PCI SSC’s initial announcements on the matter, the council has yet to validate a single P2PE vendor that can offer the promised scope reductions and a simplified SAQ to merchants.

Why? Well, quite frankly, because the council designed the wrong standard. Pandering only to massive merchant organizations (that not only hold weight in the industry but also hold seats on the council), the SSC built a P2PE standard that applied only to hardware/hardware approaches. A hardware/hardware approach requires P2PE hardware at the merchant location and a hardware-based key management and decryption tool—known as a hardware security module (HSM)—at the other end. Only merchants with in-house “switch” systems have this set up and, for those that don’t, the infrastructure costs are astronomically prohibitive. This move denies the P2PE benefits, which have been lauded by the PCI SSC for the past two years, to more than 90 percent of its members.

Then, in December, realizing the limitations of its prior attempt, the council released a new standard: a hardware/software “hybrid” standard for P2PE that still requires hardware encryption but that also allows software decryption—so long as the keys are still managed by an HSM. HSMs are not perfect and have been breached.

The fact that PCI has made the HSM an untouchable “black box” means vendors don’t get to validate the code it runs. Vendors have to use someone else’s certified HSM. Essentially, the council is asking vendors to trust some HSM manufacturer with not only their customers’ data but with their whole livelihood. If that HSM goes down, vendors may not be able to fix it.

We in the vendor community would have to entirely rely on a third party to keep our product running. Not to mention that it would likely put us in violation of PCI DSS requirements 2.2.1 through 2.2.3, which state that each component in our environment must be validated.

That is just not acceptable. How does this new hybrid standard address those issues? Well, frankly, it doesn’t. It makes things worse. Now, not only are there HSM issues to worry about, but we also have to accept the fact that—according to PCI—the HSM can pass the keys (in the clear, so long as the network is “properly segmented”) to the software decryption stack. Keys in the clear on a segmented network? Haven’t enough companies been burned that way already?

The new hybrid approach does allow a few new players into the marketplace, but at what potential cost? Yet again, the PCI Council has released a standard that will allow less-than-adequate security measures to be checked off as “compliant.” And, the coucil has once again left those of us who know better than to place blind faith in an HSM out in the cold.


advertisement

5 Comments | Read After Seven Months, Why Does The PCI Council Yet To Have Anyone P2PE Validated?

  1. DJ Says:

    As a QSA, (not a P2PE QSA), I’m concerned that there are no listings as pressure builds to validate software encryption solutions that vendors arrogantly push, merchants ignorantly accept and I’m on the hook to confirm a level of confidence in the security. I don’t agree with most of the article as it is very different than what I’ve seen both in the market and actually have read the standard (which is pretty good) but I do share the concern over listings.

  2. Steve Sommers Says:

    DJ, please elaborate. I would like to know what you have seen in the market that contradicts the post. I would also like to know what you found good for merchants in the standard?

  3. Suzy Says:

    So many good points made in this article. The Payment Card Industry Security Standards Council certainly has had its share of shortcomings. I wish someone from the Council would read this article!

  4. Lyal Collins Says:

    P2PE is a dead duck, imho.
    Prior guidance for the PCI Council indicated that encrypted data, where the merchant cannot decrypt it (proven absence of keys etc), is out of scope.
    All a terminal vendor needs to do is encrypt the payment message payload (SSL anyone?) and accept a token/hashed value in the and they have descoped most / of their internal store network, and maybe head office too.
    Head office is always a more complex issue, since cardholder data may be present in other systems besides store payments/EJs/T-Logs.
    Encrypting payment message payloads is a national standard in some jurisdictions, rendering the need for P2PE even less pressing.

  5. AC Says:

    In PCI defense, some of the delays may be related to final approval and publishing of underlying ANS X9.119 part 1 standard. It has only recently received final approval and ANSI approval and publishing is in progress.

    That said…
    This standard is neither scalable nor sustainable beyond transmission between merchant and acquiring host. Standard does not reduce risk for acquirer to network or issuer because PAN/Track Data must be decrypted for either processing locally or before it can be forwarded to another network or processor (either encrypted or in the clear). For environments where processor must both decrypt PANs/track data and process PINs, this actually increases risk for PIN compromise by enabling PIN processing HSMs commands that decrypt data. Improperly managed key separation would allow PIN blocks to be decrypted, creating a significanly larger gold mine if compromised. Intended purpose of this standard was to provide a mechanism to reduce scope of PCI DSS compliance reviews. In fact, this scope reduction can only occur at the merchant or location where PAN can never decrypted.

Leave a Reply

Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 17,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.