I have been encountering a lot of organizations that are confused about the difference between the PCI SSC’s point-to-point encryption (P2PE) certified solutions and end-to-end encryption (E2EE). 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, SSL and TLS.
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 uses the 56-bit data encryption standard (DES) encryption or triple DES (3DES) algorithms. While DES and 3DES 56-bit and 112-bit are 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. While using the cloud could be leveraged to perform this rapidly, it would be too costly an effort for the data retrieved. As a result, DUKPT is still considered a secure method of encryption.
P2PE is a subset of E2EE. This is because the major difference between P2PE and E2EE is that P2PE does not allow the merchant to be a manager of the encryption keys. Under the P2PE standard, only the transaction processor or other third party is allowed to perform key management. The merchant is never allowed to perform encryption key management under the P2PE standard. As a result, DUKPT can be used by both P2PE and E2EE solutions. However, under P2PE, the key management must be done by a third party, not the merchant.
While third party key management is typically acceptable for small merchants, this does not work for merchants that switch their own transactions to various processors as do mid-sized and large merchants. That does not mean that E2EE solutions are not acceptable for reducing PCI scope. As with PA-DSS certified applications, P2PE certified solutions can be accepted by a QSA as long as they are implemented according to the P2PE implementation guide which can reduce the amount of testing a QSA is required to perform. In my experience, P2PE versus E2EE testing efforts are typically negligible, so any so-called savings are limited at best.
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. For some merchants, that could be a costly proposition and make any switch not worth the effort.
So if your organization is looking at P2PE versus E2EE, I would not necessarily give an advantage to P2PE over E2EE. 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.
