This is a post to provide an overview of P2PE solutions, attempting to initially provide a high-level intro while continuing to delve into some more detailed and technical elements. The intent is to provide an understanding of what a P2PE solution looks like, what it consists of, and to demonstrate how the various building blocks fit together.
To avoid being overly wordy, I’m going to use a number of pictures with some annotation for clarity.
Let’s get to it…
P2PE means Point-to-Point Encryption and is about encrypting payment data at the point of payment and decrypting that data in another environment. The benefit of this is that clear text payment data should not be handled by any merchant system, thereby reducing/removing their PCI compliance scope.
Note: the merchant still needs to validate their P2PE usage and may have scope for other payment channels.
At a high level, this is what the P2PE solution looks like:
Now we can zoom into different parts of the above.
In the merchant environment, the following is happening:
A PTS-validated payment terminal receives the payment data on some interface (Integrated Chip Card Reader, Mag-Stripe Reader, Contactless or keyed entry).
Firmware or a P2PE payment application receives the payment data, formats the data and passes the data to a PTS firmware provided Secure Read and Exchange of Data (SRED) API.
The SRED module encrypts the data using a symmetric encryption key which would typically be unique for this transaction.
The firmware/application receives the encrypted data.
The transaction message contains some clear text data for use within the decryption environment, as well as encrypted cardholder account data (used to authorize the payment).
The transaction message is transmitted from the payment terminal to the decryption environment.
In the Decryption Environment, the following is happening:
The transaction message is received from the merchant terminal.
The application processes the message to identify various data to allow decryption to occur (i.e. identify the appropriate key for decryption).
The encrypted data is sent by an application to the Hardware Security Module for decryption.
The data is decrypted and returned to the application (This environment is always in-scope for PCI DSS of course).
A payment authorization request is transmitted from the decryption environment to the acquirer.
A payment authorization response is received from the acquirer and is sent to the terminal in the merchant environment.
The above, at a process level is all rather straightforward. Some of the complexities of P2PE are around the processes related to devices handling keys and the keys themselves.
I’ll go through devices handling keys then discuss a little about the keys themselves. All the below devices are SCDs (Secure Cryptographic Devices).
POIs (Points of Interaction) are the payment terminals located in the encryption environment (merchant locations). These devices contain encryption keys so they can encrypt the cardholder data and could simply be a chip/mag card reader; which is a contactless card reader or a fully functional payment terminal with all the bells and whistles.
HSMs (Hardware Security Modules) are located in the decryption environment (Payment Gateway data centre) and are usually used for generating and storing keys and for performing decryption of the cardholder account data.
KLDs (Key Loading Devices) are located in Key Injection Facilities (KIFs) and are used to load keys to POIs – this is typically through direct physical connection using a cable
KDHs (Key Distribution Hosts) are also used to load keys to POIs but these perform that task remotely. Where these are located can depend on the solution architecture.
There’s a bit of terminology to follow above and there’ll be more when we go through symmetric and asymmetric encryption keys but, to keep it simple yet comprehensive, we’ll endure!
Let’s talk about device handling...
All the SCDs need to be tracked and have a demonstrable chain of custody from the point of manufacture to the point of usage. This means the following:
Using secure, bonded couriers to distribute devices.
Knowing the serial numbers of the devices to be received (e.g. receiving an inventory by email separate to the shipment).
Having named, approved individuals responsible for receiving and validating the received shipment can be reconciled with what was expected – this means comparing serial numbers of received devices with the pre-sent inventory.
These individuals can then unpack and deploy the devices – often this will require dual control.
The process here differs depending on the device but the maintenance of a chain of custody is important.
We’ll talk a little about key management here (more terminology) then go back to piecing things together
Most solutions use DUKPT – Derived Unique Key Per Transaction, this is one of the key management schemes that can be used for symmetric cryptography. This means every transaction uses a unique encryption key. Therefore, compromise of that key would not compromise the solution and risk is contained. While the encryption takes place at the POI, the Decryption Environment needs to know what key to use to decrypt the data. As mentioned earlier ‘the transaction message contains clear text data for use within the decryption environment as well as encrypted payment data’. This clear text data allows the Decryption Environment to derive the appropriate key to decrypt the payment data.
Far too quickly, this works like this:
A BDK (Base Derivation Key) is stored on the HSM.
Each terminal has an Initial Key – this key was created by transforming the BDK using the terminal serial number.
Cardholder data is encrypted using keys derived from the Initial Key and each of these keys has a KSN (Key Serial Number).
When the Decryption Environment receives the transaction message, it contains:
- The BDK reference so the appropriate BDK can be selected on the HSM key table
- The terminal ID so the BDK can be transformed to derive the Terminal’s Initial Key
- The KSN so the appropriate key in the key register can be derived
Now the decryption environment can decrypt the data and send it to the acquirer for authorization!
So that’s the DUKPT part of key management and covers how card data is encrypted. The next part of key management covers how the keys themselves are generated, protected and distributed.
The BDK is generated on a PCI and/or FIPS validated HSM.
There are three mechanisms under which a key can exist:
- On a secure cryptographic device – i.e. any of the SCDs referenced earlier
- Encrypted by a key of equivalent or greater strength – see key table below for this
- As separate plain-text key components split amongst different approved individuals
A key which encrypts another key is called a Key Encryption Key (KEK). Once a key (or anything) has been encrypted, you have a cryptogram. Technical note here is that key cryptograms must be managed as Key Blocks indicating their usage and other important characteristics.
Key components are a series of hexadecimal characters (0-9, A-F) of the same length as the encryption key, which can be combined to recreate the encryption key. Exposure of a key component provides no information about the original key. Components must be stored securely so for this we have key custodian groups, each group having custody of a single component.
The Decryption Environment needs to have the BDK, and the Key Injection Facility also needs to have the BDK. Given the mechanisms above, the BDK can be sent to the KIF within an SCD or encrypted with another key (which must have been pre-shared) or as separate key components.
The typical way this happens is using key components and the process is as follows:
A key custodian from key custodian group A accesses that group’s safe and takes out the tamper evident package labelled BDK part 1.
The custodian opens a tamper evident envelope and transcribes the component.
The original component is placed into a new tamper evident envelope and put back into the safe.
The transcribed component is placed into a tamper evident envelope and transmitted to a representative from the KIF who will be from their custodian group A.
The KIF custodian is notified in advance of:
The key part being sent;
The courier details;
The tamper evident envelope serial number;
The component KCV (key check value).
Note: the KCV is [usually] a unique 6 hex character value representing the component. So, each component will have a KCV and the BDK has a KCV – when entering components to the KIF SCD, custodians can verify via the KCV they’ve entered the component correctly. Similarly, once the key ceremony of loading the BDK using components is complete, the KCV of the BDK can be verified.
The same process occurs for a custodian from group B handling BDK component part 2.
Via the above process, we’ve the same BDK in each of the Decryption Environment, and the Key Injection Facility. The KIF can now connect POIs to a Key Loading Device and, using a combination of the device serial numbers and the BDK, load Initial Keys to the POIs prior to their being distributed to Merchant locations.
The next thing we’ll cover is remote distribution of keys and for this we’ll cover Public Key Infrastructure (PKI).
In order to securely distribute keys, we need to ensure we’re receiving keys from, and sending keys to, trusted devices. Public Key Infrastructure (PKI) using a Certificate Authority allows this to be accomplished as mutual authentication can exist between the KDHs and the POIs.
Note that up until now, we’ve been discussing symmetric encryption keys. Now, in the PKI model, we’re looking at each device having an asymmetric key pair with public keys maintaining a certificate chain to the root CA. These public keys are used to authenticate devices and negotiated session keys are used to encrypt other keys exchanged between devices. In this way, a POI could receive a new Initial Key.
So that’s P2PE in a nutshell!
There are clear benefits are in relation to the secure management of encryption keys and the execution of encryption/decryption operations within secure cryptographic devices which have a clear chain of custody throughout their lifecycle.
In terms of the design and management of the cryptographic architecture, the requirements within the P2PE standard are aligned with those of the PIN standard and with ISO key management standards. So, even if you’re not working on a P2PE solution, using the requirements to measure your own alignment to industry best practices can be useful.
That’s all for now. If you have any questions or any topics you’d like us to cover in this series, do let us know.
Subscribe to our Blog
