Well they have arrived. After more than a year of discussion and debate the new requirements for Point to Point Encryption (P2PE) have finally been released by the PCI SSC.

These requirements, which are contained in the Point to Point Encryption: Encryption, Decryption and Key Management within Secure Cryptographic Devices (Hardware/Hardware) v1.0, were released this month and define how a payment solution provider may validate its P2PE solution thereby allowing merchants to reduce the scope of their PCI DSS assessments when using the solution.

For a merchant this simply means that in a card present environment, the card data which leaves the Secure Cryptographic Device (the PED) is not considered within the scope of a standard PCI DSS assessment. The major advantage to merchants is that this can potentially remove store networks completely out of range of the assessment, provided there is no other cardholder data being transmitted, stored or processed within that store network. In fact, if a merchant has a solution based on the decryption taking place at a third party service provider then the P2PE cardholder data is never considered within scope of the PCI DSS assessment, although there are still some requirements on the merchant related to this specification.

This initial document is for, what is termed, a Hardware/Hardware solution requiring the solution to provide encryption and decryption only with SCD or hardware security modules (HSM).

So when will the first validated solutions appear? Well, there lies one problem since the testing procedures won’t be available until the end of 2011. A new type of assessor, a P2PE QSA will only be trained and accredited in early 2012 with the intention that newly validated solutions will be listed by Spring 2012.

In the meantime, what does the new standard look like? Well it is clear a good deal of thought and detail has gone into this set of requirements. The requirements split the P2PE environment into six domains, each with its own set of requirements, definition of scope, and allocated responsibility.

The six domains split as follows:

Domain 1 and 2 are related to the SCD where the card reading occurs and encryption occurs and relates to the security of the device, the application code and environment executing on this device.

Domains 3 and 4 relate to the Encryption environment where the SCDs are placed and the transmission of encrypted traffic securely.

Domain 5 relates to the central decryption environment which must be performed in a secure PCI DSS secured environment, using an HSM device.

Domain 6 looks at all the Cryptographic key operations across the whole environment.

For a merchant all of this should be academic. The requirements for them will be to reduce installation and maintenance of the SCD devices as per a manual which will have to be provided to them, the P2PE Installation Manual (PIM). This covers installation of the solution and devices secure maintenance of the devices, secure delivery and inventory tracking and the like. Other than that, their responsibilities will lie in the remaining PCI DSS controls linked to education of staff, security policies, management of third parties and physical security of the devices and hardcopy cardholder data. Naturally, if the merchant has any other means of cardholder data capture and transmission and processing then this will be subject to the original PCI DSS controls in all their glory.

For a P2PE solution provider there is plenty of food for thought as the solution needs to be validated against a stringent set of controls, that are clearly (and quite rightly) based on some well defined controls with regard to key management, encryption and decryption. Some of the key management requirements are the most stringent yet seen from the card schemes. However, when we see the sophisticated attacks on RSA, Diginotar and the like then that is no bad thing.