Best Practices for PCI, Cybersecurity Protection (Part II): Encryption and Tokenization

Posted originally on Wired, InnovationInsights blog

For my fifth and final installment of this blog series, I’d like to spend some time talking about the pros and cons of two technology solutions which promise to offload most if not all of the burden of PCI compliance for merchants large and small. The goal is to create an environment where properly implemented, these solutions would greatly reduce the “footprint” of payment card data that makes a merchant subject to Payment Card Industry (PCI) Data Security Standard (DSS) compliance in the first place. 

Don’t Miss the Cybersecurity forest for the PCI compliance tree

If this blog series has conveyed one constant message, this would be it.

So let’s tackle two discussion drivers here: Encryption – including point-to-point encryption – and tokenization. These technologies are thought to REDUCE SCOPE by trying to promote the argument that encrypted card data (and the token value) is not cardholder data – therefore the systems which “transmit, process, store” the “not-cardholder” data are no longer subject to PCI controls. But that’s not really true. Here’s why:

Encryption. Reality is more complicated than arguments about whether encrypted card data isn’t cardholder data, and therefore not subject to PCI review. The PCI Security Council has made it very clear (well, over time) that encrypted cardholder data can ONLY be precluded as cardholder data if the merchant (the council says “entity”) DOES NOT have the ability to DECRYPT the data. Makes sense, right? Assuming the encryption is robust and cryptographically sound, it’s safe to assume that the encryption works. The biggest problem is that most encryption algorithms in use today are SYMMETRIC algorithms – which means the key used to encrypt is the same key used to decrypt the cardholder data.

The point-of-interaction (POI) is where a consumer provides the payment card to the merchant in order to extract the primary account number and other required data (the contents of the magnetic stripe). Since the merchant is in possession of the POI device, and the key is symmetric, then the merchant has the ability to decrypt the data (whether they know it or not, or have the technical acuity to perform the feat).
Enter a standard which addresses this: Point-to-Point Encryption (P2PE), which takes place not inside the POS system but within the PTS POI device (i.e., the pin pad or the card reader) IF AND ONLY IF the reading of the magnetic stripe data and the encryption of said data occurs within a hardware encryption module that is embedded within the device. This has been deemed sufficient to take the encryption keys out of the hands of the merchant and to invoke the statement, “the encrypted data is not cardholder data.” Oh, and the authorized decryption has to be out of the hands of the merchant as well – typically the responsibility of a payment gateway or processor who in turn transmits the data onto the banks for authorization.

The first certified P2PE solution only became available last October and now there are three solutions listed. Unless you are using one of those three solutions, you as a merchant don’t get to make the “it’s not cardholder data” scope-reducing claim. Period. (If you have a solution already – it’s likely happening in memory. And guess what? That’s where all the memory-scraping malware we’ve been reading about is equally adept at stealing the data too.)

I am a certified cryptologist who used to work for the DoD, and I can tell you that encryption is difficult to pull off effectively. Case in point? The recent OpenSSL heartbeat vulnerability that was revealed. There was nothing wrong with the encryption; no weak algorithms that could be brute-forced; heck, even the key management was not in question. What we saw with the “heartbleed” vulnerability is the perfect storm of how implementation of a security protocol was completely compromised because of a bug in one of the component parts; which left the data that was supposed to be transmitted securely totally exposed because an attacker could recover the keys used to create the secure connection in the first place.

Hackers don’t typically try to break encryption; they do a couple other things that are just as effective. First, they try to steal the keys – so key management/key security becomes paramount. So with something like P2PE this is prevented on the front-end (POI) by the use of embedded crypto; what remains then is the back-end place where decryption occurs. That’s not technically the merchant’s problem. But it is, because the upstream entity which is doing the decryption is a service provider to the merchant and is subject to PCI compliance. All the complexities of compliance remain – the burden has simply been shifted one-off to a third party. The other common practice for hackers attempting to circumvent encryption is to exploit weaknesses in the implementation of the cryptographic systems themselves. This is the primary reason why you won’t get a straight answer to “If I use encryption will I be secure?” and why you get the “it depends” or “the devil is in the details” or “if it’s implemented correctly”.

Tokenization. This is a great way to improve security by reducing the touch points of cardholder data, and does a great job of eliminating incidental access, copying, storage and the stockpiling of cardholder data by well-meaning employees who inadvertently create a PCI compliance nightmare. However, if there are folks within the company who have to see the cardholder data, they will need to launch a de-tokenization procedure. As to how to perform the de-tokenization – particularly how the system is providing authentication and authorization to the right people? That’s a dilemma for which I’ve yet to see any useful guidance on how to do securely, other than fuzzy statements such as “de-tokenization works if it is implemented correctly.”
Also: Does de-tokenization mean the stockpile of tokens is meaningless data which doesn’t have to be secured? Or at least not to the “minimal” degree required by PCI? That’s interesting. Because if I am an attacker, I can assume I have free and open access to all the tokens. Therefore, all that’s left is to figure out how to de-tokenize and – voila! – I’ve stolen credit card data. My target then becomes the de-tokenization method, and the people (and their systems) who use the de-tokenization method. Therefore, I am not comfortable with disregarding the tokens. In fact, I believe that the rule applied to encrypted data should be extended to tokens: If you can de-tokenize, it’s still card data.

Ultimately, there are no silver bullets, and no substitute for good security. Which means due diligence reigns supreme, as well as keeping a close eye on the network and all data flows. Silver bullets designed to “make PCI compliance simple” or eliminate the need for PCI are profoundly irresponsible. If a vendor makes such promises to you, I strongly suggest you find another vendor.

By all means, you may invest in P2PE and/or tokenization solutions – but do so for the added level of security complexity you introduce to your environment – not to reduce or eliminate the pain of a PCI Compliance assessment. Finally, don’t write-off or dismiss the PCI DSS standards but recognize them for what they are (and aren’t) and leverage the PCI compliance process to make your organization as secure as it needs to be and stay vigilant.

Jeff Man is a PCI Evangelist at Tenable Network Security.