P2PE Hardware Solution Requirements and Testing Procedures
A few weeks ago, the Payment Card Industry Security Standards Council (PCI SSC) released version 1.1 of the P2PE Hardware Solution Requirements and Testing Procedures. Shortly thereafter, the PCI SSC held its first training session for assessors. 403 Labs attended and we are now officially certified as a Qualified Security Assessor for Point-to-Point Encryption (QSA (P2PE)) and Payment Application Qualified Security Assessor for Point-to-Point Encryption (PA-QSA (P2PE)) by the Payment Card Industry Security Standards Council (PCI SSC).
Like much of the industry, we’ve waited for P2PE like kids waiting for Christmas, and though it’s finally here, it has some complexities and challenges worth discussing. This post marks the first in a series of explanations and discussions of P2PE.
As of right now, solution providers can obtain P2PE approval for a hardware/hardware solution, which means a hardware point of interaction (POI) with PCI PTS approval, and a hardware security module (HSM) doing decryption on the backend. The PCI SSC does not permit software encryption or decryption as of yet, and will likely not do so for a while.
Probably the easiest way to try to understand this is to start with the stakeholders and what elements of a functional solution they address. After that, we’ll talk about the domains (requirements) a little more.
Stakeholders
POI manufacturer – They manufacture the devices used for payment acceptance and submit them to a PCI PTS lab for approval. Specifically, they must obtain PTS approval for the PTS functionality classification called Secure Read and Exchange of Data (SRED). If the device itself communicates over TCP/IP, they also need the Open Protocols (OP) designation. In actuality, there’s more to a successful P2PE implementation than this, at least in terms of the particulars of the device’s PTS approval, but these are the essential characteristics.
Application developer – The developer creates an application that runs on the PTS-approved POI. Maybe it does some payment-specific function, maybe it does something else (e.g., the advertisements on the display of the payment device in the back of a New York taxi). It’s entirely possible that a P2PE solution doesn’t make use of an application, per se, but just uses the POI manufacturer’s hardware/firmware to perform the entire payment acceptance function. In any event, the application developer must use the POI’s PTS-approved cryptographic and key management function as well as their OP network stack, if it exists, on the device (and if it doesn’t, then the app cannot make use of TCP/IP functionality). Somewhat similarly to PA-DSS, the application developer has to prepare an Implementation Guide, but for the solution provider to properly implement the application (as opposed to the merchant).
P2PE Solution Provider – These organizations bear the major responsibility for P2PE compliance. A solution provider may typically act as the acquirer or gateway for the payment, but does not have to. Also, a solution provider may also be the application developer. Lastly, the solution provider can outsource some functions to third parties, although these third parties must have a P2PE assessment performed on their relevant functions, either as part of the solution provider’s assessment or independently. The solution provider has to have appropriate practices in place for inventory, control, distribution, maintenance, and decommissioning for all of the POIs in its possession. This stuff is going to sound a lot like PCI PIN requirements for dual control, tamper-evident packaging, bonded couriers for transit, etc. The solution provider also needs to maintain the decryption environment, with an HSM for key management, key hierarchy, etc. using dual control and split knowledge of key components. They must maintain PCI DSS compliance for their decryption environment as well.
Third parties – Third parties can perform some of the services a solution provider needs to do. They need to adhere to the relevant P2PE requirements and get assessed, either as part of the solution provider’s assessment or independently. We’ll discuss this in a little more detail below.
Resellers and integrators – This group does what you’d expect them to do: they resell or integrate the P2PE components for the merchant using them.
Merchants – Merchants get to use the solutions and follow the instructions in the P2PE Implementation Manual (PIM). P2PE assessments do not interact with or evaluate the merchants at all.
P2PE assessors, both QSA and PA-QSA – Naturally, assessors evaluate the solutions, deem them compliant, prepare the appropriate P-ROVs, and submit to the Council.
NOTE: A merchant undergoing a PCI DSS assessment, while using a P2PE solution does not require a P2PE QSA to validate their PCI DSS compliance. In the same way that an assessor does not need to be a PA-QSA to evaluate a merchant’s compliance when that merchant uses a PA-DSS-validated application, a QSA does not need to be a QSA (P2PE) to evaluate a merchant’s compliance when that merchant uses a P2PE solution.
Domains
The difference between a QSA (P2PE) and a PA-QSA (P2PE) comes when looking at the six domains of P2PE (sort of like major requirement numbers). I’ll explain in brief here:
Domain 1 – Use and manage appropriate POI devices. Make sure the POI devices have the requisite PTS approval for the appropriate functionality and apply appropriate controls for inventory, tracking, key injection, etc. from the manufacturer to the solution provider. The solution provider basically has to handle most of this and a QSA (P2PE) assesses this.
Domain 2 – Make sure the application running on the POI handles cardholder data (CHD) appropriately and doesn’t skirt the POI functionality (e.g., roll its own crypto). The app developer needs to follow dev practices very similar to PA-DSS Requirement 5. The solution provider needs to implement application according to Implementation Guide. The assessor needs to test somewhat similarly to PA-DSS: forensic tools or similar methods (although how you do this is tough), penetration testing (also, not trivial), etc. Also, the assessor does code review of the application code. You did read that correctly. Domain 2 has two columns of testing procedures: one for app developers, one for solution providers. A PA-QSA (P2PE) must do all of this testing. A QSA (P2PE) can do the testing for all of the other domains.
Domain 3 – Secure POI devices throughout their life. This has some overlap with Domains 1 and 5. The solution provider needs to appropriately track inventory of devices in inventory, maintenance, transit, and in use (at least to the level of saying that device xyz is deployed and functioning at merchant abc). This involves the use of appropriate transport, like bonded couriers, separate channels for delivering manifests of shipped devices, comparing serial numbers on manifest versus actual devices, tamper-evident packaging, etc. The other piece of this is that the solution provider must prepare, for the merchant, a P2PE Implementation Manual (PIM) that describes the merchant responsibilities for things like doing their own inventory management, who they should expect shipments from, maintenance contacts, escalation points for potential incidents, how to inspect devices physically for tampering, etc. The PIM is like a PA-DSS Implementation Guide, in a lot of ways. While the intent of P2PE was to limit the amount of compliance and security work the merchant had to do, the PIM does require some fairly specific procedures for inventory management, examining devices for evidence of tampering, and understanding how to interact with the solution provider for receipt of hardware, maintenance, and incident response.
Domain 4 – This domain talks about separation between encryption and decryption environments. Currently, it has no applicability to P2PE, as the current standard allows only hardware encryption and decryption using secure cryptographic devices. When the PCI SSC allows P2PE solutions using some software decryption, it will come into effect.
Domain 5 – The solution provider maintains a secured decryption environment with an appropriate HSM. This means a FIPS 140-3 Level 2 HSM that has undergone an independent approval or one that has undergone a PCI PTS evaluation with the HSM designation (essentially the same requirements). The solution provider must implement the HSM following the vendor’s security policy and implement appropriate key management procedures, namely dual control and split knowledge. The decryption environment must undergo an annual PCI DSS validation, and the QSA P2PE can either perform this along with the P2PE assessment or must review the Scope of Work section of the ROC itself to confirm that the QSA evaluated this environment.
Domain 6 – This domain talks about key management, namely how to implement keys appropriately and very much resembles PIN security when talking about key bundles for TDES, key equivalency for what kinds of keys can encrypt other keys, etc. It’s much more detailed than 3.6 of PCI DSS, and includes specific annexes for use when dealing with a certificate authority (CA) that uses asymmetric key management to deliver symmetric keys to POIs and for key injection facilities (KIFs).
Assessments result in reports called P-ROVs, of which there are a few flavors, namely for solution providers, applications, and third parties. A solution provider P-ROV may also cover all of the application developer testing in Domain 2, if the solution provider also develops the application. It may just include the solution provider-specific Domain 2 stuff. It may show as predominantly N/A if there’s not really an application running on the POI, but the solution just uses the POI’s functionality.
An application developer can also have a P-ROV completed for its application. The PCI SSC will list both of these types, so a solution provider can pick an application (and consequent POI) from the list of available applications to implement in its solution.
Third parties like CAs or KIFs might also get their own assessments and P-ROVs. These will very likely show N/A for many requirements, and just have text for their relevant responsibilities. Then, the assessor evaluating a solution provider that makes use of such a third party can use that P-ROV. If the third party doesn’t have a P-ROV, the assessor will need to include that third party’s activities in the scope of work, which will likely involve on-site review. The PCI SSC, however, does not currently plan to accept or list P-ROVs for third parties.
In the subsequent posts, we’ll look at some of the details in the domains more specifically, and talk about how to prepare for a P2PE assessment.
