Step right up folks. I have something that will cure all of your problems with credit card processing. It is called end-to-end encryption. Yes, folks, it is the be all, to end all in security. It will cure all that ails you, particularly those nasty data breaches. Don’t be shy, just step right up and get your own version while supplies last.
Gee, when end-to-end encryption (E2EE) is put that way, it sounds great, almost too good to be true. And you would be right; it is too good to be true. But if you listen to the statements of the proponents of E2EE, they make it sound like once E2EE is in place, it is like the Ronco Showtime Oven, “Just set it and forget it.”
Now, do not get me wrong. E2EE is not a bad thing, but it does have its own set of risks. And it is those risks that do not get discussed that concern me. The reason for my concern is that if you discuss E2EE with any merchant, most see it as this panacea, something that will get them out of the PCI compliance game altogether. However, nothing could be further from the truth. If anything, E2EE may make PCI compliance even more daunting than it is today.
The first thing everyone seems to forget is that E2EE only removes those systems and networks that are between the endpoints. That is because the data stream between the endpoints is encrypted and, therefore, out of scope for PCI compliance. However, for a merchant, that means that the device that accepts the credit card is still in-scope for PCI compliance. Bring this fact up to most merchants and they start complaining like no tomorrow.
That device might be as “simple” as a credit card terminal or as complex as an integrated point-of-sale (POS) workstation on a network. However, since this device is an endpoint, the merchant or the merchant’s QSA needs to ensure that the endpoint is properly secured and cannot end up being a breach point. Depending on the complexity of that device, that assessment might be very straight forward or very time consuming. The reason the endpoint needs to be assessed is that security is only as good as its weakest link. In the case of E2EE, the weakest links are the endpoints at which the data is encrypted and decrypted.
The next thing that seems to slip people’s mind is that fact that since the merchant has an endpoint, that endpoint is still a target. Worse yet, because it is an endpoint, the level of sophistication likely required to compromise that endpoint goes up exponentially, meaning that any successful attack will likely be beyond the average merchant’s capability to readily detect. The PCI DSS addresses this threat fairly well by requiring network monitoring, daily log reviews, anti-virus, anti-malware, firewalls and the like. However, I can tell you from personal experience that your average merchant is not going to be equipped to deal with this new threat.
And what is the new threat? The new threat is tampered with hardware and software. If you think this is farfetched, think again. It has already happened on a limited scale. The doctoring of hardware is fairly straight forward to both accomplish and to detect. Detection only takes looking inside the device and noticing something that does not belong. However, doctored software is another story. The concept of doctored software has been a concern in the health care industry since the start of using computerization for heart pacemakers. While the health care industry has developed rigorous testing and certification procedures, the rest of the software industry has said there is no need. That is, until now. As the world further automates, the need for reliable, safe and secure software only increases because of the reliance people and organizations apply to that software.
So what can an organization do to stem this new threat after implementing E2EE? Here are some thoughts.
- Purchase your credit card processing equipment only from your acquiring bank or reputable vendor. This is not a perfect solution to the problem, but doing this should be better than buying a used unit off of eBay or from Joe’s Guaranteed Card Equipment. Yes, you may save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised? Probably not.
- Ask your supplier of terminals or POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank. Ask them to provide those procedures in writing and review them to ensure they appear adequate.
- Use serialized tamperproof tape on the seams and doors of your terminals and POS workstations. Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with. If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
- If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
- Upgrade your card processing devices to the latest devices. Over the last few years, some of these devices have seen significant changes in their design that improves their tamper resistance. This is particularly true of fuel pumps and certain types of terminals.
- Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
- Patch your devices as soon as possible to minimize their susceptibility to attack or compromise.
- If the vendor of the equipment will perform updates, make sure that you or someone in your organization schedules the updates. If anyone shows up at a location to “update” your equipment and it was not scheduled by your organization, contact law enforcement.
- If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process. At the end of the update process, the person should terminate the remote session of the vendor.
Even implementing these processes will not remove all of the risk. Particularly the risk of having modified software introduced into your environment. However, these processes will show a court that you attempted to conduct due diligence and tried to keep your equipment secure.
PCI Guru 
I know this is a very old post but, do you know if full pci compliance rules apply for merchants if their card data is fully end to end encrypted? I have a few customers being told this, and am not sure if the credit card merchant is blowing smoke or not.
While the post is “old”, the guidance it provides is still accurate.
The key regarding scope is whether or not the merchant can decrypt the data because they have the/a key. If they do NOT have the key and therefore cannot decrypt, then the only scope is the endpoint in their environment.
This is the whole premise of P2PE and E2EE solutions and why they reduce PCI scope. When dealing with these P2PE/E2EE solutions, the requirements a merchant needs to address are those in the SAQ P2PE.
My 2c worth:
1) FPE (by Voltage and others) is not a stream mode of encryption – it is a new Feistel construction using AES or TDES as the round function. See my presentation for more details (http://www.slideshare.net/AndrewRJamieson/encryptionvstokenisationforshare)
2) PCI is actively working on standards for P2PE (they prefer ‘point to point encryption’ to ‘end to end encryption’) and I would be sure to attend the community meeting if you are interested in this area.
3) When buying HW for encryption of card data, make sure it is PCI PTS compliant. As a manager in a PTS lab, I can assure you of the rigour to which we assess the security of these systems.
Thank you for the clarification/correction and update.
There is an additional weakness of E2EE that often gets ignored: Scope of the data path. In a traditional payment environment using encryption, all components from the point of entry to the point of storage to the exit point and all the communication channels in between are in PCI scope and must be addressed. With E2EE, as you described, the endpoints are addressed but for the most part, the data path between the two point are out-of-scope as far a PCI is concerned.
To me, this is a serious weakness — not with E2EE per se because all encryption has this inherent weakness, but with PCI in allowing this out-of-scope vulnerability for E2EE users. Again, this out-of-scope loophole does not exist for traditional payment encryption environments so it’s a weakness specific to PCI E2EE.
This E2EE encrypted data is potentially available to anyone because it’s out-of-scope, if the encryption keys were ever compromised — by any of the means you mentioned and others (like a disgruntled or careless employee at the merchant or E2EE provider) — then all the data collected that used this data path is at risk for exposure.
Just to clarify my position, I am a proponent of E2EE; I just don’t believe that PCI should have carved out a vulnerability loophole for it. Encrypted data is encrypted data — E2EE or otherwise — and all encrypted CHD should be treated the same.
There is no “hole” carved out for E2EE or any other type of encryption. That is why the key management techniques are covered in 3.5 and 3.6. As long as the keys used are strong and secured and organizations comply with the requirements in 3.5 and 3.6, encryption is fine.
Encryption fails when people implement it with weak algorithms, bad keys or do not protect their keys. That is how TJX got breached. Even though they had encrypted their data in certain instances, the hackers got a hold of the keys and the encryption was moot.
The hole I am referring to is that E2EE encrypted CHD, primarily format preserving E2EE CHD, can be considered out-of-scope provided that the merchant never has access to the keys. Normally encrypted CHD still needs to be protected and is covered by various individual requirements – firewalls, access controls, segmentation, etc. Once the data is out-of-scope though, these requirements go away.
Maybe I’m getting actual PCI requirements and proposed changes mixed up. I do know that E2EE providers are pushing to make the data out-of-scope trying to say it’s the same as tokenization.
Depends on the algorithm used. For example, the algorithm used by Voltage Security is a stream encryption algorithm defined as a subset of AES that allows the preservation of the PAN’s original length. Even though the original length is preserved, the data is truly encrypted with the same voracity as other encryption methods.
To clarify, under FAQ #10359 issued by the PCI SSC, encrypted data is NOT in-scope “… if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it.” Where this can get tricky is in large organizational environments where the IT division has the key management, but the business operational division does not. We have interpreted the aforementioned statement to mean that the business operational division is out of scope since it does not have access or control of the encryption keys.
Where encryption gets used the most for declaring something out of scope is with telecommunications providers where the merchant uses encrypted VPN tunnels to communicate from their retail location to their corporate systems. The telecom carrier is out of scope because they do not have access to the keys and therefore cannot decrypt the data stream being carried over their circuits. However, we have also run into a number of telecom carriers that think they are still out of scope when they are the ones managing the router that creates the VPN tunnel. Even when you show them the FAQ, a lot of them tell you that they are not in scope because it was not the intent of the PCI SSC to make them in scope. I’ve fought this battle a couple of times and it can get VERY ugly.
That said, depending on the E2EE solution, the merchant may or may not have access to the keys. It is up to the QSA to determine who controls and has access to the encryption keys as part of the assessment.
(sorry, there is no “reply” option for your last comment in this thread so this will most likely be out of order)
Maybe I’m not explaining where I feel the issue is. Let’s assume a format preserving E2EE solution and everything is perfectly compliant as you and the PCI requirements have stated. The merchant has terabytes of out-of-scope E2EE data that they have stored for whatever reason — who cares, it’s out-of-scope? Let’s assume the data gets stolen and since it’s out-of-scope, the merchant is not obligated to report this as a breach. So far, so good. Lastly, let’s assume the E2EE keys are compromised, outside of the merchants scope, by whatever means (brute force, probably unlikely; a disgruntled employee somewhere in the mix, more likely; keys compromised by a solution provider, RSA comes to mind). In this case I would wager dollars to donuts that the merchant will somehow be found liable for the stolen out-of-scope E2EE data, because all of a sudden, beyond the control and outside the scope of the merchant, this “sold as useless” data became real data.
Substitute tokenization for the E2EE data above and no-harm, no-foul because the useless data that the merchant stored is still useless (provided the tokens are not mathematically based on the CHD as with true tokenization). This is why I am strongly against lumping E2EE and tokenization together when referring to scoping issues.
@SteveSommers;
I disagree that tokenisation provides better security than encryption. To me, tokenisation and encryption are very similar – they both provide one-to-one mapping of the card data to a new (different) value. The difference is that for encryption you only have to protect the key (assuming you are using good algorithms), and there are standards and processes for ensuring that is protected.
For tokenisation, I don’t know what I have to protect. How are you generating the token? Is it random? What RNG are you using? Has it been tested to confirm the output is not biased in some way? How are you mapping the random values to the card data – some form of DB, flie, or other? What protects this?
Good key management will absolutely ensure that compromise of the encryption key is not possible. Your example of an employee exposing the key is not possible as dual control and split knowledge will prevent any one employee from knowing any part of the actual key. As for RSA – well, I would just say that good key management will prevent such a compromise, and leave it at that.
Until we have standards for tokenisation, processes to validate against those standards, and extended peer review of the tokenisation systems (similar to the decades of study that has been performed on DES and AES), I am have far greater confidence in encryption than anything else.
We have this problem – we’re encrypted on a closed FRM and use a PCI compliant vendor (which I’m still debating as they’re not on the approved list)… as a result of this set up – I keep being told that the POS stations are out of scope. It seems impossible to clarify that they are still in scope, no matter what I say they think it doesn’t count any more. I think part of this is because of how the vendors are selling their solutions.