A new version of Point-to-Point Encryption (P2PE) guidelines to be published by the PCI Council today will allow retailersfor the first timeto be able to create and seek certification for their own P2PE system, addressing a longstanding retailer concern about the earlier rules locking them into certain vendor relationships.
Another change with P2PE 2.0 is that the council will now validate P2PE components so that retailers can piece together an encryption package from various vendors, which also helps avoid lock-in. The common theme among the dozens of changes is an attempt to make point-to-point encryption easier to deploy.
Although some vendors have accused the PCI Council of weakening P2PE (such as by permitting decryption to continue to happen in software rather than hardware) in an attempt to expand its usage, many have countered that any point-to-point-encryption is better than none. And many have questioned whether the standard is weakened by other provisions concerning software decryption.
Some of the other changes to make deployment easier are that decryption device inspections will now be required every three months (it had been monthly), the removal of a requirement to test operating system software that handled decryptions and a new rule that prevents P2PE assessors from challenging the compliance of the entire environment once it's already been approved.
A new rule for vendors requires them to allow retailers to print the full payment account number on receipts where there is a legal or regulatory obligation to do so, such as in Germany.
"Anything that makes (encryption) simpler I am sure is going to be welcomed," said Al Pascual, the director of fraud and security at Javelin Strategy & Research. "Anything that encourages greater adoption is the right move."
The easing of vendor lock-in will especially appeal to retailers that had reason to work with more than one provider.
"You have a lot of merchants with more than one acquirer" due to acquisitions and mergers, Pascual said. "Being able to own that and source it yourself and take it with you and use it across various acquirers, I think that makes it attractive. From a large merchant's perspective, it makes more sense."
Jeremy King, the council's International Director, said one of the most important changes is the ability of vendors and retailers to submit an encryption package by its individual elements. Previously, the entire package needed to be approved as a whole. Companies complained because almost all of the elements of a package had already been approved, so resubmitting the package struck them as pointless.
"This is about simplifying the process. The whole solution had to be reevaluated. They'd say 'We have already evalulated (this element) once. What are you going to find different?'" King said. "We have moved to a more modular process. This is going to make life a lot easier. We're providing vendors the opportunity to not have their products reevaluated time and time again."
One of the arguments the council has made is that point-to-point encryption is an important complement to EMV-chip cards, as is tokenization. Each technology protects payment data differently, so overlapping these approaches keeps data protected at more points during the transaction.
What P2PE really protects is magstripe data, Pascual said, and given the many years that magstripe data will still exist in the U.S. even past the EMV migration deadline of October 1, it's a good security element.
But the earlier version of the P2PE standardcalled P2PE 1.1was not especially popular, and the PCI Council acknowledged this in a member meeting last year.
Why the backlash? "There was a lot of feedback from processors, acquirers, payment gateways (and) service providers that the standard was too hard, too difficult to implement," said Ruston Miles, the chief innovation officer at Bluefin Payments Systems. "Many processors said that it was too expensive to get done."
Many companies chose to resist the standard in the hopes that their defiance would prompt efforts to improve it, Miles said.
PCI's King said the council's early efforts with point-to-point encryption saw few applications being submitted.
"Most, if not all, were coming from Europe because you need to have a secure starting point. (P2PE) fits a lot easier into EMV environments," he said. "Many (U.S. companies) underestimated the level of security that we applied to the whole process. Where we missed the mark was we were hoping to have had more solutions available sooner."King added that there is a plus to the U.S. being so late in its EMV migration relative to other nations.
"Because of the U.S. being late in adoption, you're going to have the most advanced terminals," he said. "You're slow, but you're going to jump to the very latest technology."
Miles also endorsed the move to allow retailers to create their own encryption approaches, which the council would have to approve.
"It was a locked-in situation. It's very difficult to re-terminalize or rekey. Very difficult to move between processors," he said, adding "that the competitive environment ultimately leads to better pricing."
Jeff Man, the security strategist and evangelist at Tenable Network Security, is one of the merchants who argues that 2.0 weakens the standard by continuing a policy that permits software decryption.
"The notion that P2PE v2.0 is going to loosen the reins on the requirements for protecting the crypto algorithms and keys by allowing for some of the magic to occur in software rather than hardware or firmware seems, to me anyway, to be a huge step in the wrong direction," Man said. "The industry needs more security not less and doesn't everybody know that performing crypto functions in software makes them vulnerable to hacker attack?"
Fraudsters will find a way to scrape the memory where crypto functions occur, even if they have not figured out how to do this today, Man said. "My classical training in cryptography and my 32 years in the business of information security screams that this is a bad idea."
But despite his security concerns, Man said 2.0 will probably benefit the payments industry and the merchant community by making security technology more affordable. This is particularly helpful to merchants who are already investing in POS upgrades to migrate away from older versions of Windows and to add EMV acceptance, he said.
Steve Sommers, the vice president for applications development at security vendor Shift4a company that has been actively involved in P2PE's development processis also concerned about doing the decryption in software. But he is also a vocal critic of the way the standard insists on using a hardware security module (HSM) and said his company resists working with any element that it can't control and explore.
"We are fine with the hardware on the merchant side. Our concerns about the hardware requirement on the processor side," Sommers said. "We like knowing everything that is running in our data center, where we have the source code, we know the ramifications and all of that stuff. But with an HSM, it's a different story. We are supposed to rely on them that everything is secure."
Javelin's Pascual said that, in context, decrypting in software is not a concern. Given that this is all about protecting a 16-digit card number, "arguing whether software is inherently less secure is a flawed argument to be having. There is no 100% security."
