The Coalfire Blog
Welcome to the Coalfire Blog, a resource covering the most important issues in IT security and compliance. You'll also find information on Coalfire's insights into the unique cybersecurity issues that impact the industries we serve, including Cloud Service Providers, Retail, Financial Services, Healthcare, Higher Education, Payments, Government.
The Coalfire blog is written by the company's leadership team and our highly-credentialed security assessment experts.
The Coalfire Blog
P2PE Hybrid, the next best thing since the Prius
January 07, 2013, Dan Fritsche, Principal, Retail and Financial Services
P2PE promises many things, the most coveted being scope reduction for the merchant and a shifting of the compliance burden from the merchant to the service provider. A properly implemented P2PE solution can indeed reduce the risk of compromise for a merchant as well as reduce the scope of what must be done to continue to maintain compliance to the PCI DSS.
In the fall of 2011, the PCI SSC released a draft P2PE standard, followed by initial documentation and training programs in May of 2012. The initial P2PE standard was finalized and released in September of 2012. As promised, the “hybrid” P2PE standard was also released prior to the end of the year. Many have been anxiously awaiting this second standard, primarily because they heard that “software” was part of the decryption process. Now that the standard is available, what does it really mean and how is it different from the initial P2PE standard released in September of 2012?
First, let’s clarify what September’s release was: it was a “Hardware/Hardware” P2PE standard. In other words, the encryption of account data (aka Cardholder Data) must happen within approved hardware and likewise, the decryption must take within hardware. The December P2PE standard is “Hardware/Hybrid”. Clearly then encryption must still be done by hardware; however, decryption can now occur in a “hybrid” fashion. What this does not mean is that you can do away with the Hardware Security Module (HSM) and simply use software. It does mean that you can decrypt via software, but the HSM is still required to maintain and protect the data-decryption keys (DDK’s). The decryption can be done by a “Host System” that is comprised of software and hardware components.
This Host System must interact securely with the HSM and aside from performing the decryption of account data, the only other function it can have is to assist in the processing of a transaction. The controls around this hybrid approach are not trivial. Domains 1-4 remain the same, while domains 5 and 6 (Decryption Environment and Device management, and P2PE Cryptographic Key operations) have some modifications and additionsthat add another 20 pages to the initial standard. The primary intention is to protect how the management of the DDK’s is handled and to protect the Host System itself.
There are many details that certainly reflect the intent of the original standard. Some of the new additions include:
Isolation of the Host System in a dedicated network
Source code control
Strong ACL and password controls
Controls on how data is handled in volatile memory and core dump situations
Tamper detection controls
Physical location and access monitoring and alarming requirement
Remote access limitations
Strict DDK usage including rotation and deletion requirements
Certainly the new Hybrid standard will open the P2PE doors to more service providers and payment solutions. However, given that there are still no listed P2PE solutions from the initial hardware/hardware release, it does not seem likely that we will suddenly see dozens of Hybrid P2PE solutions getting listed any time soon. The benefits of using any P2PE solution are certainly worth pursuing, and we will see these in 2013, but just how large the adoption will become and how accessible to merchants it will really be remains to be seen.
<< Go Back
Blog post currently doesn't have any comments.