Point-to-Point Encryption (P2PE) is the concept of encrypting payment card data within a secure element and decrypting it at another secure element. For example, encrypted within a tamper-resistant card reader and decrypted in an HSM located within a gateway’s secure data centre.

The Payment Card Industry Council’s Point-to-Point Encryption standards (PCI P2PE) are a set of requirements for designing and certifying a P2PE system. The second version of these standards is now applicable. They provides strict requirements for the protection of card data such as the Primary Account Number (PAN) and magnetic stripe data, including the design of card readers, their handling during delivery and in the field, and of software and hardware systems at the gateway. In return, components between the card reader and the gateway may be considered outside of PCI-DSS scope.

P2PE necessarily means that much of the payments processing has to take place within the card reader on a particular implementation of the payment application. This means that POS developers traditionally have to integrate afresh to a new interface, or at least a modified interface, and lose some flexibility of implementation – for example, it is not possible to use STS’ flexible Emvelink EMV Kernel with a P2PE device. STS has added support for a number of P2PE systems to G8, hiding this cost and complexity from POS developers.

Verifone’s PCI P2PE offering is called Verifone Secure Data or VSD. It uses industry-standard 3-DES (aka “Triple DES” or “DES-EDE”) encryption using DUKPT (Derived Unique Key Per Transaction) keys. This standards-based approach means that the P2PE endpoint at the Payment Gateway can straightforwardly use off-the-shelf secure components such as Hardware Security Modules (HSMs) to decrypt or to change key zones. This approach does mean that existing integrations no longer receive a PAN, and must transfer encrypted data fields and key identifiers instead, although data for printing receipts such as the first 6 and last 4 digits of the PAN are still available.

G8’s API offers a choice of P2PE and non-P2PE integrations because it presents a more abstract view of taking payments to the POS. This means that it can hide the complexity of using encrypted data from the POS. Existing integrations to G8 are protected from changes by G8’s abstracted payments API, and consistent configuration format, and can continue to use G8-generated receipt data, status events and transaction result information, without even knowing that there is no longer a plaintext PAN or magnetic stripe data available.

Considerations for payment gateways

Because the payment gateway is the decryption endpoint, its software must necessarily be modified to support Verifone VSD data. G8 does not send a plaintext PAN, Track 2 Equivalent, Track 1 or Track 2 data in any requests. Instead, the following VSD-specific fields will be sent:

• Encrypted Data – containing 3-DES encrypted, TLV-encoded data that includes the PAN, Track and Track Equivalent Data and CVV. See Verifone documentation for an exact list of fields that are encrypted.
• Encrypted Data Key Serial Number (KSN) – the DUKPT Key Serial Number that identifies the key used to build the Encrypted Data field. This is present in all request messages.
• Encrypted Data Initialisation Vector (IV) –used when creating the Encrypted Data. This is present in all request messages.
• Encrypted PAN – containing just the ASCII-formatted PAN, 3-DES encrypted. This is present if the PED has been configured to produce it.
• The Encrypted PAN Key Serial Number – the DUKPT Key Serial Number that identifies the key used to build the Encrypted PAN field. This is present if the Encrypted PAN is present.
• The Encrypted PAN Initialisation Vector – used when creating the Encrypted PAN. This is present if the Encrypted PAN is present.

Additionally, G8 sends the following fields for all requests, whether P2PE is enabled or not, so that gateways that don’t require the whole PAN when doing local processing such as IIN-range lookup can do so using a single code path:

• Application PAN Redacted – The PAN, with at most only the first 6 and last 4 digits visible. Other digits are replaced by asterisks. Depending on the underlying P2PE system, more digits may be redacted.
• Redacted Track 2 Data – Track 2 data, with at most the first 6 and last 4 digits of the PAN and the expiry date and service code visible. Other digits are replaced by asterisks.

The gateway needs to be able to to work with the encrypted data fields, perhaps decrypting data for processing, or re-encrypting it for forwarding to another encryption zone.

Considerations for POS systems

G8’s API aims to provide an abstract interface that hides the complexity of taking payments. It does this by representing the tender process as a series of events with a final outcome, and by presenting the data such as receipts that is needed by the POS under most circumstances as opaque fields that do not support or require special processing. A typical POS integration to G8 is unlikely to require changes to support VSD, as long as the following guidelines are followed:

• Generate receipts from the receipt data supplied by G8 in a receipt printing request, or on the TenderResult object. These receipts are presented as a series of field names, formats and values, without any semantic meaning, that simply need to be merged into other receipt data. Do not use the individual fields on the TenderStatus and TenderResult (such as getPAN()) to build receipts; getRedactedPAN() may be used instead if a printable PAN is required – this will always be present. If these fields are used, be prepared for them to be missing, depending upon the rest of the system.
• Do not use the PAN – doing so would make PCI-DSS compliance harder in the first place, and the PAN is not available with P2PE. If it is necessary to display a PAN, use TenderResult.getRedactedPAN() instead.
• Don’t rely on TenderStatus and TenderResult accessor functions that return card or transaction data. Different kernels and P2PE systems return different subsets of these values.
• Be prepared for new (unknown) error codes. STS have added an EXTERNAL_KERNEL_ERROR code, which is used when the device fails. STS does not add new error codes very often, but the default behaviour for unknown error codes should be for the POS to behave as if a payment was not accepted.

Considerations for system integrators and merchants

STS has invested considerable effort in ensuring that G8’s configuration files will be compatible between different kernels and devices.

The system integrator has to configure G8 to use Verifone VSD in the first place. This is done by configuring tender.properties with the following setting:

p2pe.scheme = vsd

Although typical configurations of G8 are fully supported, the Verifone device is not quite as flexible as STS’ Emvelink EMV kernel, so some particularly complicated payments configurations will not be supported. The document “Using Verifone VSD P2PE with G8” which is included in the G8 SDK has details of those configuration options that are restricted or cannot be supported.

The G8 integration also requires particular configuration options to be set on the device, which must be performed at the provisioning stage. This is also described in “Using Verifone VSD P2PE with G8”.

PCI DSS certification

The advantage of using an approved PCI P2PE solution is that none of the intermediate components need to be checked as part of a PCI DSS certification subject to the agreement of the QSA. This includes G8, the POS, and the merchant’s networks. G8’s PA-DSS certification is not relevant when using a validated PCI P2PE solution.

Although PCI DSS scope may be reduced by using a validated PCI P2PE solution, that validation can itself take significant effort and can mean a merchant is locked in to using a specific end-to-end solution or various validated P2PE Components and Applications. Many merchants may want a more bespoke solution that uses Verifone’s VSD P2PE technology without going through the full PCI P2PE validation process. In this case, intermediate components would be in PCI DSS scope, but using VSD technology and leveraging Verifone's prior PCI listings and G8’s PA-DSS-compliant status will make PCI DSS approval significantly easier.

Conclusion

Verifone’s VSD offers many security benefits, and could reduce the cost and time it takes to achieve PCI compliance. While VSD uses industry standards for the encoding and encryption of data, the exact implementations and choices are proprietary, and merchants could be locked in to using Verifone devices. G8’s easy-to-use, consistent APIs and configuration can help POS providers and gateways to offer Verifone VSD support by reducing the cost of moving to (or away from) Verifone VSD devices.