Point to Point Encryption(P2PE) & Scope Reduction

The evolution of credit card payments over the last decade has been staggering and the ability  for merchants to keep up with the ever changing landscape can be quite daunting.   It seems your acquirer/merchant bank is always urging you to change products due to enhanced security or better features.  In a world of ever-evolving technologies, what is the right payment acceptance investment  for your business? Point to Point Encryption, or P2PE could be that solution.

P2PE is a payment security system that instantaneously converts confidential credit card data and information into indecipherable code at the swipe of the card to prevent hacking and fraud.   Credit card data becomes inaccessible at any point to other systems, networks or applications that your organization might be using, significantly reducing the scope of the Payment Card Information (PCI) Data Security Standard (DSS). P2PE alleviates many of the  technical requirements that make it impossible for small to medium size merchants to comply allowing them to narrowing focus on ensuring they have appropriate business process controls in place to mitigate any risk of accidental exposure.

For merchants that qualify, a self-assessment questionnaire or SAQ will be provided by the PCI SSC which will outline only 4 out of the 12 requirements that apply.  These requirements include; requirement 3: Protecting stored cardholder data, Requirement 4: Encryption of cardholder data in transmission, Requirement 9: Restrict physical access to cardholder data, and Requirement 12: Maintain information security policies. More information regarding the SAQ can be found at the PCI SSC website https://www.pcisecuritystandards.org/documents. It should be noted, in order to qualify for the SAQ, merchants are required to select a vendor that is approved by the PCI SSC as an approved P2PE vendor.

Upon adoption of P2PE, merchants will have a significant reduction in their compliance responsibilities . Additionally,  credit card payments  become more manageable and certainly more secure. Another advantage of P2PE is that it greatly reduces the amount of manpower involved in PCI compliance. Prior to P2PE,  PCI compliance was  a cross-functional effort that required input across multiple units in an organization  including Human Resources, IT, and Business Process Owners.  With P2PE, compliance can now solely rest on the shoulders of the Business Process Owner that is accepting the payment.

Non-e-commerce organizations that are looking to take advantage of P2PE solution should work with their acquirer/merchant bank in order to select at P2PE solution that will work in their environment.  The acquirer/merchant bank is a key business partner when it comes to PCI compliance.

P2PE is a game changer for merchants as it reduces PCI scope and also increases security around cardholder data.

PCI DSS Key Management in Tokenization Environments

keyZach recently asked the PCI DSS guru this question:

“PCI DSS Requirements 3.5 and 3.6  talk about securing data encryption keys and documenting the procedures on how you handle those keys. Now we as a company have decided to not store any cardholder data (CHD), with no exceptions. Since we do not store cardholder data at any level and use tokenization do we still need to comply with these 2 requirements as there is no CHD  to encrypt?”

First, Zach, let me commend you on the work that you’ve done to minimize the scope of your cardholder data environment.  I am strong believer in the idea of minimization.  It’s the easiest way to reduce the risk to your organization. If you don’t have data in the first place, you can’t lose it!

You’re also wise to be thinking about this issue.  Remember, the entirety of PCI applies to all merchants and, lacking specific guidance from the standard or clarifying documents, it’s up to you to interpret the standard and identify your obligations.  You can often do this by examining the testing procedures and guidance included in the full version of the standard.  The first requirement you mentioned, PCI DSS requirement 3.5, reads as follows:

“3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.”

When you read this requirement, logic would dictate that if you don’t have any stored cardholder data, then you have nothing to secure and wouldn’t, therefore, need to document any procedures.  IMHO, the “get out of jail free” card that you’re seeking comes in the guidance for this requirement, which contains the following sentence:

“The requirement to protect keys from disclosure and misuse applies to both data-encrypting keys and key-encrypting keys.”

If you don’t have either of these in your environment, then my reading would be that the requirement does not apply and you’re off the hook.

You also asked about PCI DSS requirement 3.6, a similar requirement that mandates that you:

“Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data”

Again, we find some relief in the accompanying guidance, which reads in part:

“This requirement applies to keys used to encrypt stored cardholder data, and any respective key-encrypting keys.”

So, it looks like you’re off the hook on this one!  The fact that you’re using tokenization and eliminating the storage of cardholder data in your environment seems to obviate the need for maintaining key management practices.  Congratulations!

What is Tokenization?


Tokenization is one of the best ways that you can secure your cardholder data environment.  The basic idea is that you take sensitive information, such as a payment card account number (PAN) and simply remove it from your database, replacing it with an alternative value that serves as a placeholder for your use but lacks the extreme sensitivity of the original information.  After all, if you don’t have the information  in the first place, you can’t be the source of a stored data compromise!

In payment card systems, tokenization often takes place at the payment gateway.  When you process a credit card transaction, you send the transaction information to the gateway.  When the gateway returns the transaction confirmation, they provide you with the token value that you may store in your database.  For technical convenience, the token is normally formatted in the same manner as a credit card number.  That way, it fits neatly into database fields designed to store numbers without any modification.  For business convenience, the last four digits of the token value are usually the last four digits of the real card number, allowing you to reference transactions with customers by the last four digits of their card.

How does this help with PCI compliance?  It gives you a path toward easily meeting a couple of requirements.  First, PCI DSS requirement 3.3 requires that you:

“Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.”

Since the token only contains the last four digits of the PAN, there is simply no way that an application can accidentally violate this requirement.  The full PAN simply isn’t in the database!

Second, PCI DSS requirement 3.4 mandates that you:

“Render PAN unreadable anywhere it is stored (including on portable digital media, backup media and in logs) by using any of the following approaches…”

It then goes on to name four methods that you can achieve this goal, including the use of truncation — which is, in effect, what you are doing by tokenizing card numbers.

Finally, as we pointed out in the answer to an Ask the PCI DSS Guru question, tokenization obviates the need for the key management procedures required by PCI DSS sections 3.5 and 3.6.

Remember, of course, that tokenization is not a cure-all.  If you’re still processing and transmitting card numbers to your payment gateway, you still run the risk of those processes becoming compromised and being the source of a breach of payment card information.  You may wish to consider adding the use of Point-to-Point Encryption (PTPE) to prevent credit card numbers from entering your system in the first place!

PCI DSS Compliance for Web Pages

In a recent question to the PCI DSS Guru, Gareth asked:

We have a secure web page that is server out from a secure PCI server. Can this be served out in a new browser window or embedded as a frame? Does the URL need to be displayed to prove it is secure (e.g. https://….)?

That’s a good question, Gareth. The PCI DSS standard doesn’t speak to whether your webpage must be “obviously secure” to your customers. If the server publishing the page is operating within the confines of the standard and you are following the encryption requirements of PCI DSS Section 4.1, you are probably in good shape as far as the regulation goes.

That said, you should also think about this from a marketing perspective.

(continue reading…)

PCI DSS Requirement 4.1: Protecting Cardholder Data with SSL and TLS

PCI DSS requirement 4.1 requires the use of secure sockets layer (SSL) or other strong cryptography to protect cardholder data while in transit over public networks. Specifically, the standard requires that:

”Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.”

In this article, we take a look at what this means for you as a PCI DSS professional.  We begin with an overview of how the Secure Sockets Layer (SSL) works, define an “open, public network” and then explore what you need to do to validate your PCI DSS compliance in this area.

(continue reading…)

  • Free Newsletter

  • Search

  • Copyright © 1996-2010 PCI DSS Guru. All rights reserved.