It has been almost four years since I wrote the original post. I went back and reread the original and realized it needed a rewrite to make the comments accurate and current. Point-to-point encryption (P2PE) and end-to-end encryption (E2EE) are a key part to merchants minimizing their PCI scope (the other technology is tokenization) to the maximum. However, I continue to encounter a lot of organizations that are confused about the difference between the PCI SSC’s P2PE certified solutions and E2EE solutions. This is understandable as even those in the PCI community are confused as well.
E2EE is the generic terminology used by the IT industry to describe any solution that encrypts communications from one endpoint to another endpoint. Key management of the encryption can be done by any party that has an endpoint such as a merchant or a service provider. Examples of E2EE include IPSec, SSH and TLS. In transaction processing, E2EE solutions pre-date P2PE by a number of years as numerous transaction processors and point of interaction (POI) vendors had E2EE solutions before the publication of the P2PE standards.
One of the most common E2EE solutions used by merchants is derived unique key per transaction (DUKPT) also known as “duck putt”. DUKPT is commonly used in the convenience store and gas station industries to encrypt sensitive authentication data (SAD) from the gas pump to the merchant or processor. DUKPT originally used the 56-bit data encryption standard (DES) encryption algorithm but was updated to 168-bit 3DES and later to AES. While DES is no longer considered secure, because DUKPT uses a unique key for every transaction, it means that every transaction has to be individually broken to gain access to the data – a time consuming task given the usual large transaction volumes. While the cloud could be leveraged to perform this decryption rapidly, it would be too costly an effort for the data retrieved. As a result, DUKPT using DES is still technically considered a secure method of encryption although it is never recommended for use. 3DES and AES are now the more commonly implemented algorithms with AES being the preferred solution if supported by the POI.
One of the big changes with v2 of the P2PE standard was to simplify the certification process which vendors complained was overly complicated and cumbersome in v1. As a result, the Council responded by simplifying the certification process by adopting a more modular approach.
The other big change was to allow merchants to be in control of key management. The key management change was driven by P2PE vendors who were finding that large merchants needed to manage their POI encryption keys because they desired to do their own transaction switching between processors. As a result, large merchants were implementing E2EE solutions rather than P2PE solutions so they could perform encryption key management.
The Council then came up with the Non-Evaluated Solution Assessment (NESA) program a few years ago. The idea was that P2PE-QSAs would assess the E2EE solutions and produce a report so that merchants could more readily obtain P2PE scope reduction from their banks. One of the reasons that NESA never caught on was that the Council never really created and shared a good definition of what a NESA report would contain for proof and the format. QSAs have never had a clear definition of what, if anything, was required to be reported. As a result, how was a QSA to rely on a document that had no definition? But what the Council really missed was the fact that most E2EE solutions are approved by the acquiring bank because they are offering it to their customers. Since the bank determines whether a merchant gets P2PE scope reduction with E2EE solutions, there really was no need for the NESA program. Never mind the fact that none of the card brands mandated the NESA process.
One of the biggest issues I encounter over E2EE is that merchants believe that E2EE solutions are not acceptable for reducing PCI scope. That is because the key difference between P2PE and E2EE is that a P2PE solution gives immediate PCI scope reduction as long as it is properly implemented. A QSA can reduce PCI scope as long as the P2PE solution is implemented according to the P2PE solution’s Implementation Guide (IG). The acquiring bank’s approval is not required. That reduction in scope reduces the amount of testing a QSA is required to perform to those requirements in the SAQ P2PE.
To get P2PE scope reduction with an E2EE solution requires a bit more effort, but it does not have to be extensive. In my experience, contacting a merchant’s acquiring bank can be all a merchant needs to do. I remember being on a conference call with a client’s acquiring bank to discuss scope reduction for their E2EE solution. The bank’s representative inquired as to why the call was needed because the E2EE solution was provided by the bank. I stated that I needed a formal statement for my work papers indicating that the bank approved of my client’s P2PE scope reduction. The person laughed, made a comment about how silly PCI can be and then emailed me the P2PE scope reduction approval.
A QSA should still do some investigation work of the E2EE solution to ensure it has been properly implemented regardless of what the bank might say. Those efforts should include:
- Network packet captures at key points on the customer’s network to ensure that the packet remains encrypted. Those captures should include comparing the payloads to ensure decryption/encryption does not occur along the network path. This can be done at the customer’s testing lab.
- If the POI is not stand alone and connects to a PC via USB, collect a packet capture of the USB connection using Wireshark’s USB capture solution or a similar solution. This can be done at the customer’s testing lab.
- Use the E2EE solution’s Implementation Guide (IG) to ensure that the E2EE solution was implemented according to the vendor’s instructions. Conduct a visit to a sample of retail locations to ensure that those locations match the configuration and connectivity you observed in the testing lab.
- If the customer is managing the E2EE solution keys, investigate and document the key management to ensure they comply with the key management requirements in 3.5 and 3.6 of the PCI DSS and requirements in Domain 6 of the P2PE Solution Requirements and Testing Procedures v2.
- If the customer is managing the POI key injection process, investigate and document that process to ensure the POI remain secure throughout the process from injection to delivery at the retail location.
These E2EE testing efforts are typically negligible, so any assessment savings over using a P2PE certified solution are limited at best based on my experience.
The huge downside to P2PE for merchants is that once you decide on a given P2PE solution, you are pretty much stuck with it and the processor providing it. That is because most processors offering P2PE are only offering one P2PE solution. As a result, if a better deal comes along for processing your transactions, you will likely have to replace your terminals and possibly other equipment to switch to the new processor. This is why a lot of Chief Financial Officers are a bit put off by P2PE. For some merchants, that could be a costly proposition and make any switch not worth the effort. The P2PE switch limitation is a tad bit less with E2EE but even then you will be limited to processors that support your E2EE solution and the conversion will require reinjection of POI keys by the new processor which might not be as seamless or even impossible to perform thus resulting in getting new POI.
If your organization is looking at P2PE versus E2EE, I would not necessarily give the advantage to P2PE. Just because an E2EE solution is not P2PE certified does not mean it is not secure. It only means that the vendor did not believe that the P2PE certification was worth the effort.
PCI Guru 