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, RetailFinancial 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

Bookmark and Share

Dan Fritsche

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
  • Self-testing diagnostics
  • 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
  • Logging requirements
  • Video monitoring
  • 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.

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS