US-EMV Deadlines

And yet again, it's been a while since I posted to my blog and, in turn, it's been a while since I ruffled some feathers. So, let's start 2017 with a bang!

Over the Christmas break read an article in Digital Transactions News: How EMV-Related Chargebacks Drove Florida Merchant Duo to Sue Networks And Issuers. While reading the article, my initial thought was, "There's nothing new here. They're simply documenting how the EMV rollout went (and still is going) for many U.S. merchants." Then, in the final paragraph I read a quote from Molly Wilkinson, executive director of The Electronic Payments Coalition, a Washington, D.C.-based lobbying group that represents card networks and issuers: "Merchant groups have known about the transition to EMV cards for five years but instead of getting their act together they have tried to delay, obfuscate, and reject this solution – all while leaving customers exposed to hackers and counterfeiters." This statement has so many flaws that I'm not sure where to start, and it clearly demonstrates the ignorance of the coalition – or is altogether pushing a blatant lie.

Let's start with the merchant groups. Simply put, they are advocates for the merchants, not tools for the card brand mandates. They have no control over what the networks support, the various requirements of physically performing an EMV transaction, or the certification requirements of EMV solutions. Merchant groups have little to no role in the supposed five-year preparation window – more on this later. I would be interested in hearing exactly how these merchant groups delayed or obfuscated the U.S. EMV rollout. Now let's discuss this "rejection of the solution." They had reasons for the rejection, as I will explain.

IMHO, the largest factor of the U.S. EMV rollout failure was a lack of forethought by the card brands and EMVCo in recognizing the differences in the U.S. marketplace. EMV for the most part has been a great success in Europe and it was assumed that EMV "plans" could be lifted from Europe and plopped onto the U.S. as-is. The problem here is the plan included a thorough end-to-end testing of the "solution." In Europe, a majority of the solutions are simply stand-beside terminals with little or no integration, so certifying a couple terminal solutions with a couple of banks in each country, no big deal – project complete. Here in the U.S. , there is a much bigger diversity of banks, processors, and terminals, and a majority of the marketplace uses fully or semi-integrated solutions with the point-of-sale (POS). This translates into an exponential number of "solutions" to certify in the U.S. compared to its European counterpart. Now before people get bent that I'm bashing one or the other, my point is not that one is better than the other, my point is they are simply different and that there was a failure to plan for this difference – and the blame certainly doesn't fall on merchant groups.

Let's revisit the five-year EMV preparation window. The card brands scheduled out various deadlines for banks and processors to be EMV ready within this preparation window, and before the October 1, 2015, liability shift deadline for merchants. There were two issues here. I don't know the wording of the mandate to the processors, but from what I experienced, as long as a processor could demonstrate a working EMV solution (I'm unsure if certification was required or not), then the deadline was met. For many processors, host specifications supporting EMV were not published to integration partners (like gateways) until around May or June of 2015. And, none that I am aware of had solidified their certification process, which is a big part of an EMV solution. Most EMV solutions back then took between 4-12 months to certify. It's a little better now, but not by much. Assuming the specs were published in May, allowing for a 30-90 day development cycle plus a six-month certification, means the average "solution" would have been certified and production ready no earlier than February or March of 2016 – this is a good 4-5 months after the EMV merchant deadline.

Then we have the October deadline. Why October? Who picked this deadline? Just before the holiday shopping season when most merchants (at least larger merchants) have technology freezes in place in preparation for their busiest time of year. I'm not sure what the merchant groups were or were not conveying to the card brands or the coalition, but if I were in charge, this would have been a no-go issue.

Now, the doozy: "all while leaving customers exposed to hackers and counterfeiters." This propagates the misbelief that EMV secures the account information. EMV does not protect the card data. EMV is an authentication mechanism only. You must add point-to-point-encryption (P2PE, sometimes also referred to as end-to-end-encryption or E2EE) to secure the data. Authentication guarantees (relatively speaking) that the card is authentic and was not forged; it does not stop prying eyes from seeing the account number and expiration date in the clear. P2PE hides the data from prying eyes. The U.S. was already making a shift to P2PE, but the problem was that incorporating EMV meant a new batch of uncertified terminals entering into the solution certification chain.

Hopefully this clarifies some of the misinformation flying around about how merchants are to blame for the U.S. EMV rollout failure – or at least the missed deadline.

Pondering the Possibilities

Currently the PCI SSC is pondering the possibility of including language that would exclude encrypted cardholder data from the merchants PCI scope if, and only if, the merchant does not have access to the encryption keys used in the process. This is to make it easier for end-to-end encryption (E2EE) solution providers to promote their wares. Security wise, I think this would be a mistake.

I've argued many times on different forums about how tokens (provided they are "true" tokens that are not derived from the PAN) and tokenization are more secure than E2EE data -- format preserving or otherwise. E2EE proponents almost always quotes some report that states a brute force attack on the encrypted data will take umpteen million years of CPU time to crack. There are a few problems with this argument. For starters, I imagine similar arguments were being made back in the single DES days; but then CPU speeds increased exponentially and umpteen million years of CPU time became months, then weeks, then days, and eventually minutes. Another issue is the potential for a yet to be discovered inherent vulnerability in the encryption algorithm or key hashing; SSL1 comes to mind, as well as MD5.

A final issue with the "umpteen million years to crack " argument is that this assumes a brute force attack. If the key is ever compromised by any means -- yes, a brute force attack is one means, but also poor key storage, memory sniffers, disgruntled ex-employee, etc. -- the encrypted data is vulnerable.

Ponder this:

1. PCI SSC adopts some form of language that removes E2EE data from PCI scope. 
2. One or more middle men handle this E2EE data between the starting end point and the final end point: POS application, merchant LAN, Internet service provider, routers, gateway, processor(assuming the gateway is not the end point), etc. 
3. One or more of these middle men log all this E2EE data in the clear -- since E2EE data is already encrypted, this data is out of PCI scope and therefore has no requirement for additional encryption, data retention periods, etc.
4. Everything works securely and flawlessly for weeks, months or years.
5. The E2EE key is compromised by whatever means (brute force, encryption algorithm vulnerability, disgruntled employee, whatever).

While the key was cracked or acquired outside the scope of the merchant, how will this play out for the merchant or any of the middle men in #2 above if it is determined that the source of the breached data was the logs containing the out-of-scope E2EE data?

Now with true tokenization, tokens cannot be cracked; no keys, no possibility of inherent tokenization algorithm vulnerability (assuming true tokenization where the token is not derived PAN). Any middle men storing or logging tokens could and should be removed from the liability equation provided they never touched the real cardholder data.

I hope the PCI SSC carefully consider this issue in it's entirety before adding any out-of-scope wording for encrypted data.

Round 3, Tokenization vs. End-to-End Encryption

Before I get started, a disclaimer. I am a firm believer in a layered security approach. I have said several times, end-to-end encryption (E2EE) has a very important roll in the "optimum" payment security environment. E2EE, by itself, is not a silver bullet. Similarly, tokenization, by itself, is not a silver bullet either. However, if for some reason you are evaluating tokenization OR E2EE, I argue that a properly implemented front-end tokenization solution will reap more rewards than an equivalent E2EE solution.

Round 1: Tokenization enters the payment space. Shift4 releases tokenization to the public domain in October 2005. Initial document described back-end tokenization to address data storage. Since that time, technology has evolved to include front-end tokenization, which addresses data in flight as well as storage.

Round 2: End-to-End Encryption enters the payment space. In March 2008, VeriFone announces it joint end-to-end solution with Semtek. In June 2009, Heartland Payment Systems announces its entry into the E2EE arena with Voltage and E2EE, at least how we know it in the payments space is born.

Round 3: End-to-End proponents lobby PCI to deem E2EE data out-of-scope for PCI, similar to tokens. Recently PCI SSC appears to have conceded in a FAQ entry: "However, encrypted data may be deemed out of 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." I believe security wise, this is a mistake and this is an example where "security" and "compliance" go separate routes.

So we are all on the same page, let me first briefly explain the difference between tokens and encrypted data. True tokens (I specify "true" because some tokenization vendors do not follow the definition of token) are not derived from the data it is protecting. A true token is simply a reference to the card data that is stored within a fully PCI compliant system. The token can be a sequential number (1=first card number swiped, 2=second card number, etc.), or it can be a time stamp, a random number, or any combination. The key is that the token is in no way derived from the card number and instead is only a reference to the card information.

Encrypted data, on the other hand, is directly derived from the original data – the card number. A key is used to encrypt the data, and either the same shared key or a related public/private key is used to decrypt the data. What keeps the data safe is the strength of the encryption method used, and the keys themselves. If the keys are ever compromised, the data is no longer safe.

The issue for me here is the decree from PCI SSC, "encrypted data may be out-of-scope." Many will read this statement and a light bulb will pop on: "silver bullet!" This type of thinking can be detrimental to the overall security risk of the card holder data.
Encrypted data can always be decrypted. Whenever I mention this, it triggers an immediate response from various encryption experts about how brute force attacks will take hundreds to billions of years to crack based on today’s technology. Maybe true, if you are only talking about brute force attacks and ignore any possibility of a encryption algorithm weakness (MD5 comes to mind). Also, a brute force attack is not the easiest way to get an encryption key. Key storage and key management are the weakest points of most encryption solutions. My point is, if the key is ever compromised by any means, the encrypted data can be decrypted and is therefore vulnerable.

Now we go back and look at how PCI SSC’s decree affects security. If E2EE data is out of scope, this information can be stored, logged and freely distributed – after all it is out-of-scope. Does this sound secure – especially if you consider encrypted data can always be decrypted?

One aspect where the jury might still be out: Will the card brands take the same stance? If and when this out-of-scope data is ever compromised, this stance would in effect be a safe harbor clause; the card brands have avoided safe harbor clauses for merchants like the plague. Breach equals fine and I don't see the card brands honoring any out-of-scope decree from PCI SSC as a safe harbor.

As I stated in the beginning, a layered security approach is the best. If it’s a one or the other decision, you know my recommendation. If you decide to go the E2EE route, my recommendation would be to ignore PCI SSC in this case and instead treat E2EE data as in-scope.

Until next time…

Go Carr

I've not always agreed with Heartland Payment System's CEO Bob Carr but in a recent article that appeared on Bank Technology News (The End of the World), Carr mentions with disdain that vendors (referencing payment gateways, banks, payment processors, possibly even POS providers) want to charge merchants additional fees for encryption services; "First Data says it thinks encryption technology should demand a higher price point." To me, this would be a disgusting practice and I fully agree with Carr's distain. Providers that handle credit card data MUST handle it securely and charging merchants additional fees as though it's a luxury is despicable.

Bottom line, whatever solutions you choose, make sure your vendors are not charging additional fees for the luxury of securely handling cardholder data.

Your encryption sucks - here, use mine

I just read an amusing article on SearchSecurity.com: Heartland CIO is critical of First Data's credit card tokenization plan. In this article, Steven Elefant claims front-end tokenization solutions are less secure than end-to-end encryption solutions because front-end tokenization solutions depend on encryption. Huh? "Front-end tokenization, where you take a credit card number and send it up to a token server and then send it back to the terminal, is not good because you are totally exposed from the time you swipe the card until it gets to the token server," Elefant said in an interview with SearchSecurity.com. "If you are not encrypting with very strong crypto and hardware, you don't have security." I like the idea of end-to-end but let’s get some perspective. The end-to-end encryption technology that Elefant endorses uses unproven "hidden" or "format preserving" encryption. Could this be the case of the pot calling the kettle black?

If you're reading this trying to decide on end-to-end vs. front-end tokenization, here are some things to consider. Security should be thought of as layers. A solution that provides or allows for overlapping of end-to-end and tokenization would be the best approach. In lieu of that, true tokens (where the token value is in no way related to the card number other than as a reference) are not considered cardholder data and are not in scope of PCI whereas encrypted cardholder data is still considered cardholder data. Tokenization solutions may be adjusted to allow for repeatability (depending on provider) whereas end-to-end cannot and should not be able to provide repeatability – this comes into play when presenting recurring transactions are using cardholder data for loyalty lookups or risk analysis. End-to-end, in most cases, can work better in remote offline locations whereas most tokenization solutions require online access (but Shift4 does provide offline tokenization capabilities). Most end-to-end solutions use a "keys-to-the-kingdom" approach and therefore require tamper resistant hardware security modules; if these keys are ever breached, all the systems that store this "encrypted" data are vulnerable whereas true tokens are useless even if the token generation logic is known to the world.