With all the buzz around PCI Point to Point Encryption (PCI P2PE), we have been getting a lot more enquiries around the topic, so have decided to create a couple of blog posts to help clear up some of the basics on PCI P2PE. This second post provides a high level overview of the domains that make up a PCI P2PE solution.
Any PED used within a P2PE solution must be PTS validated, have SRED enabled and be handled from manufacturer to solution provider to merchant in accordance with the P2PE standard (Domain 1). A full chain of custody should be available to validate this. The solution provider must maintain an inventory of the terminal estate and, at the merchant site, the merchant should handle devices in accordance with the PIM provided by the solution provider (Domain 3).
Note that applications installed on the PED (both those that do and don’t handle cardholder data) must be validated against domain 2 of the standard. Applications and whitelists must be signed by a private key.
All keys injected to the PED must be done within a validated Key Injection Facility (Domain 6: Annex B). Keys can be distributed remotely using asymmetric methods if that mechanism has been validated against Domain 6: Annex A of the P2PE standard.
HSMs used within a decryption environment must be received, stored, deployed and decommissioned in accordance with requirements within Domain 5 of the P2PE standard. HSMs used must be FIPS 140-2 compliant or PCI HSM compliant – what HSMs can be used will also depend on the types of keys used for encryption.
Typical solutions use DUKPT using a BDK installed on the HSM, IPEKs for terminals to create the future keys or unique sets of encryption keys per terminal. These keys are TDES double or triple length. Domain 5 also includes requirements on identification of encryption/decryption failures and authorization failures from specific devices.
All key generation, loading and distribution as well as key component management must be performed in accordance with Domain 6 of the P2PE standard.
Key equivalence must be in place for protecting keys. i.e. any key protecting another key must be of equivalent or greater strength than the key it protects (see ref in image below)
Validation of all the below requires a lot of policy and procedure documentation as well as evidence of adherence to those policies through logs, shipping bills, minutes of key generation and loading ceremonies, key custodian forms and key component management logs etc.
There is a lot more detail that we can go into, so if you’d like to discuss any particular questions on PCI P2PE, we’d be happy to chat.
We offer a free PCI Surgery for organisations looking for extra help with their PCI programs and would be happy to spend time talking through the pros and cons of a PCI P2PE solution too.
You can sign up for the PCI Surgery here – one of our team will be in touch to set up a call with a senior security consultant – completely FREE of charge.