In recent years there has been much discussion about the use of Point-To-Point Encryption (PTPE or P2PE) as a method for minimising the scope of compliance requirements for merchants. Effectively this works as follows:
- Merchant has a Point of Interaction such as a PIN Entry Device which encrypts cardholder data using keys to which the merchant has no access.
- Encrypted cardholder data is transmitted from the merchant environment to the service provider’s environment
- Encrypted cardholder data is decrypted by the service provider using a HSM and sent for authorisation
Authorisation message is sent back to the merchant
In the above process, the merchant has no access to cardholder data or any of the keys that do any of the encryption, at any time. This is a hugely important part of the process, as a number of discussions were had about using other types of encryption for securing the data. In a PTPE environment the card data confidentiality is maintained using encryption and responsibility for the key management techniques is transferred to a third party. According to the current release from the PCI Council, only a hardware to hardware implementation of the above solution can achieve scope reduction. This means that all encryption takes place within a PTS validated terminal which is approved for SRED (Secure Read and Exchange of Data) and Open Protocols (if using IP communications) modules and all decryption takes place within a Host Security Module (HSM) in the service provider’s environment.
I’ll go further into the P2PE requirements overview in a moment but it’s worth pointing something out here.
A service provider can provide a solution to a merchant whereby cardholder data is encrypted in the terminal and decrypted in the service provider’s environment. The merchant and service provider can be PCI DSS compliant and the service does not have to be validated and certified as a PTPE solution. The benefit of a validated PTPE solution is that a merchant can effectively write off their face to face channel’s PCI scope and much of the risk while relying on the service provider’s validated solution. If a merchant uses a PTPE solution which is not listed with the SSC, that merchant will need to complete an applicable SAQ depending on the environment or a RoC depending on transaction volumes.
The PTPE requirements are split across 6 domains. In a nutshell, these are as follows:
Domain 1: a POI which is PTS (PIN Transaction Security) 2.0 or PTS 3.0 validated with the SRED module validated and enabled and Open Protocols listed and enabled if the terminal uses IP must be used as part of a P2PE solution.
Domain 2: any application on the PTS PED (PIN Entry Device) must be validated by a PA-QSA (PTPE). Such validation must be performed for applications which do and which do not handle cardholder data.
Domain 3: the POI (Point Of Interaction) device must be secured at all times. This includes inventories, physical security and transport controls.
Domain 4: this domain covers segmentation between encryption and decryption environments and is not currently in scope as the standard is hardware/hardware only. This will be elaborated upon for hybrid environments when such may be approved.
Domain 5: the decryption environment must be PCI DSS compliant and must use secured and approved decryption devices. Physical security and inventories are again prominent here.
Domain 6: management of encryption keys is detailed here and is far more complete than you may be familiar with from requirement 3 of the PCI DSS.
Domain 6 also contains 2 annexes:
Annex A: Cryptographic Key Operations for Symmetric-Key Distribution using Asymmetric Techniques
Annex B: Cryptographic Key Operations for Key-Injection Facilities
The PCI SSC has clearly put a lot of work into this standard and there is pretty much no room for interpretation. The exams are a test of knowledge much more so than the standard QSA exams. While there are currently no validated PTPE solutions as yet, this will be an interesting areas to watch develop.
My considerations are:
Service providers able to provide this service in Europe may become an oligopoly (at least in Europe). I’ve heard rumours of terminal providers restricting the ability to install custom applications.
However, this could also become a very disruptive technology in the market, allowing smaller terminal manufacturers to team up with smaller payment processors and enter the face to face payment market.
There is an opt-out clause available to merchants whereby they can disable the encryption mechanism in the PTPE solution. This is effectively a ‘KILL’ switch and requires the merchant to accept responsibility to use alternative controls and/or processing method. I imagine the problem threshold to affect this should be pretty high and controlled! There’s not much detail as to how this would work in practice.