P2PE Version 2.0 Released

July 16, 2015 Jacob Ansari

Just before the July 4th weekend in the US, the PCI SSC released version 2.0 of the PCI Point-to-Point Encryption (P2PE) standard to the public. This updated version revises some of the requirements language, reducing some of the redundancy in prior versions, and makes a few essential changes to the P2PE requirements. The PCI P2PE specification allows solution providers to validate their encryption solutions for merchants to deploy into their environment for handling card-present transactions and potentially reduce significantly the scope of that merchant’s PCI DSS compliance obligations. P2PE has seen only some adoption thus far, in part because of its particularly rigorous requirements for device use and security operations. This new version alleviates some of the requirements, allows for some modularity in validating solution components, creates a new provision for merchant-managed solutions, and streamlines and clarifies many of the requirements from the prior versions.

A PCI P2PE solution, at its most basic level, consists of a series of point-of-interaction (POI) devices that accept card transactions through swipe, chip reader, contactless, or key entry; then encrypt the data and send to the solution provider’s secure decryption environment, which uses a hardware security module (HSM) to perform decryption operations. Prior versions of P2PE required the solution provider to maintain these devices, while in its possession, using chain of custody and dual control, and to ship devices in tamper-evident packaging. Version 2 appears to only require dual-control, split knowledge, and tamper-evident packaging for handling encryption keys and key components and for the devices involved in loading encryption keys into POIs. This represents a subtle, significant change from prior versions of P2PE and has the potential to alleviate a significant operational burden from would-be solution providers.

The new version contains other significant changes that the PCI SSC had signaled well before the release of the document: the ability for entities to validate against portions of P2PE as “component providers” and for merchants to operate their own solutions. Previously, solution providers validated their entire solution as a single entity. Any third parties, such as key-injection facilities (KIFs) or hosting providers had to undergo assessment as part of the solution provider’s validation efforts. Now, certain component providers, such as encryption management providers, KIFs, certification/registration authorities (CAs), or decryption management providers, can engage a QSA (P2PE) to assess their services and receive listing on the PCI SSC site as a P2PE component provider and a solution provider can engage with them to fulfill those P2PE requirements.

Additionally, merchants can now implement their own P2PE solutions, and the previously empty Domain 4 (out of six domains in the P2PE standard) contains the additional requirements for merchants to implement their own P2PE solution. These requirements focus on separating the merchant’s decryption environment from other parts of its IT infrastructure and maintaining a strict separation of permissions from the merchant’s encryption environment (i.e., in-store environment) or other parts of the organization into the decryption environment.

Lastly, like all new versions of standards released by PCI SSC, this version of P2PE contains a number of minor clarifications, corrections, and a significant reduction in the redundancy of similar requirements previously spread across several domains. This version of P2PE also significantly simplifies the requirement for solution providers to provide merchants with a P2PE Instruction Manual (PIM), by reducing the number of requirements in the PIM and providing a mandatory PIM template on the PCI SSC website for solution providers to use.

The PCI P2PE standard continues to provide the most thorough and rigorous security requirements for an encryption solution designed to reduce merchant PCI DSS scope, and this version presents a more streamlined and flexible set of requirements for solution and component providers to meet the demands of merchants seeking effective and secure scope-reduction technologies.

About the Author

Jacob Ansari

Jacob Ansari is a Manager at Schellman. Jacob performs and manages PCI DSS assessments. Additionally, Jacob oversees other Payment Card Industry assessment services, namely PA-DSS and P2PE. Jacob’s career spans fifteen years of information security consulting and assessment services, including network and application security assessments, penetration testing, forensic examinations, security code review, and information security expertise in support of legal matters. Jacob has performed payment card security compliance assessments since the payment card brands operated their own standards prior to the advent of PCI DSS. Jacob speaks regularly to a variety of audiences on matters of information security, incident response, and payment card compliance strategy.

More Content by Jacob Ansari
Previous Article
Does PCI provide an Attestation of Compliance report?
Does PCI provide an Attestation of Compliance report?

The result of a compliant PCI DSS assessment is the generation of an Attestation of Compliance (AOC) as wel...

Next Article
FedRAMP and PCI – A Comparison of Scanning and Penetration Testing Requirements
FedRAMP and PCI – A Comparison of Scanning and Penetration Testing Requirements

 Overview In the last 30 days, the FedRAMP Program Management Office (PMO) has published guidance for both ...