P2PE Versus E2EE Revisited

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.


12 Responses to “P2PE Versus E2EE Revisited”

    October 28, 2019 at 8:55 AM

    So, If I have an E2EE solution and get the acquiring bank to approve of P2PE scope reduction, does that mean I can use the SAQ P2PE?

    • October 28, 2019 at 4:23 PM

      If that is your only payment channel (e.g., no eCommerce, MOTO, etc.) AND you are a Level 4 merchant.

      If you are a Level 1 or 2 merchant (MasterCard requires a ROC for Level 2 merchants), you will have to do a Report On Compliance (ROC) but can follow the SAQ P2PE as a template for what needs to be tested in your ROC. You mark all the other requirements as Not Applicable with the reason being that you have an E2EE solution and are following the SAQ P2PE. Other than requirements 3.2.1 – 3.2.3 which must be responded to as In Place and reason being that there is an Approved E2EE solution that does not allow the merchant to have access to the SAD/CHD processed.

      • 3 BRIAN NELTON
        October 29, 2019 at 12:58 PM

        I have a lot of different payment channels, but they are all either validated P2PE or E2EE. I’d like to use the SAQ P2PE, but thought I’d need all of my payment channels to be P2PE. One of the E2EE providers is saying that I can use an SAQ that has less questions than the SAQ P2PE, but doesn’t know which one and wants me to contact a managed security and compliance company. I am a Level 4 merchant and don’t have any eCommerce, but I do have some telephone orders(non VoIP), that gets entered into a validated P2PE Ingenico device. So if I can get my bank/s to approve of P2PE scope reduction then I can use the SAQ P2PE?

      • October 31, 2019 at 11:43 AM

        I would recommend using the SAQ P2PE but for your E2EE solution you will need formally documented approval for scope reduction which will then require you to do SAQ P2PE and nothing else.

  2. 5 amest01
    September 13, 2018 at 9:00 AM

    “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.”
    Not true. With Shift4’s validdated P2PE solution the merchant can switch processors and/or bank anytime they wish.

  3. 7 Robert MacKinnon
    August 31, 2018 at 10:38 AM

    I’m not in complete agreement with your last statement, “It only means that the vendor did not believe that the P2PE certification was worth the effort.”. In our case, we considered NESA certification of our existing E2EE solution but rejected it because it was not worth the effort. NESA apeared to offer the opportunity to quickly get an interim certification to our clients but the costs and effort to conduct the NESA assessment were as great as to seek P2PE certification. So, we rejected NESA and went straight for P2PE. I fully agree with your analysis of NESA though.

    • August 31, 2018 at 4:23 PM

      And that is exactly the point of NESA – there is NO point! If NESA is going to cost you just as much as a P2PE validation, why not just do the P2PE validation?

  4. August 2, 2018 at 4:56 AM

    One question that I have
    How would you approach the report writing in the ROC for the requirements that you are excluding because of the E2EE and the approval from the acquiring bank to reduce the scope?
    Would you say that they are?
    * In place because service providers PCI certification (of course assuming that the services provided are certified), * Not applicable because it is not applicable for the merchant because of approval of reduced scope from acquring bank.
    * Not tested

  5. July 20, 2018 at 3:01 PM

    Great update! I especially appreciate the detailed bullet points relating to how a QSA might go about reviewing an E2EE solution. Very helpful. Another advantage to a listed/validated P2PE solution however is a shift in responsibility and (potential) liability to the solution provider. That’s not to say that a similar agreement is not possible to a degree with a provider of a proven, secure non-listed/ E2EE option.

    • July 20, 2018 at 3:12 PM

      You also get the shift in responsibility with E2EE as well when you acquiring bank approves the scope reduction. That’s a little secret that the Council does not want people to know but the card brands allow.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

July 2018

%d bloggers like this: