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.

Computer Security Day

It's been a long while since I posted here. Time is flying by. A colleague at work sent the following security PSA to all Shift4 employees and he was gracious enough to let me re-post here for the world. Good info...

COMPUTER SECURITY DAY

Computer Security Day is observed annually on November 30.

Identity theft, credit card fraud, ransomware, and more endanger our online experiences every day.

History of Computer Security Day
Computer Security Day began in 1988, around the time when computers were becoming commonplace in business and government and in the home…when they no longer cost $10,000.  The Internet, as we know it today, was also an infant.  While hacking and computer viruses have been around since the early days, evolving and increasingly sophisticated malicious technologies will continue to be a threat to online computer activities forever.  Computer security had already become a major concern by the end of the 80s so Computer Security Day was created to educate users and raise awareness.

Here is a checklist you can follow to help secure your computer at work and at home:

·         A password is required to access my computer.

·         Windows Update is enabled.

·         I use antivirus software and make sure it is updated daily.

·         My Windows Firewall is on.

·         I keep my computer applications patched up to date.

·         I remove unused computer applications.

·         I always use strong passwords.

·         I don’t share or write down passwords.

·         I log off my computer when I’m not using it.

·         My home wireless network is secured with a strong password and strong encryption.

·         I regularly backup my important data to an offline device.

·         I use caution when I browse the Internet.

·         I suspect foul play when my browser is redirected to another web site.

·         I don’t allow my web browser to store or remember my passwords.

·         I regularly delete temporary Internet files.

·         I don’t open attachments or click on links in email from people I don’t know.

·         I make online purchases only on well known, reputable web sites.

·         I look for “https” in the address bar before submitting personal and payment information.

·         I don’t save my credit card information on web sites.

·         I don’t use my debit card online.

·         I don’t use the same password for all online services.

Enjoy!

Shift4 Secure Payment Processing DOLLARS ON THE NET®     IT'S YOUR CARD®    4Go® Stephen Ames, CISA, CISSP Senior Director, Security Compliance
Shift4 Corporation 1491 Center Crossing Road Las Vegas, NV 89144-7047	702.597.2480 ext. 46700 fax 702.597.2499 www.shift4.com sames@shift4.com

"In the pursuit of security assume nothing." -sga

Why All QSAs Must Lie

A fellow blogger referred me to yet another blogger's post "Why All QSAs Must Lie". While the title sounds like a QSA bash piece, it definitely grabs attention and the post is definitely not a dump and QSAs and is worth the time to read.


On another note, I'll start writing again soon. I have several ideas but time has been hard to come by of late. Until next time...

Bob Russo: Breached!

There is a brief article that I found on CardNotPresent.com where Bob Russo, outgoing general manager of the PCI Security Standards Council, describes an incident where he was robbed (really burglarized but everyone misuses "robbed" – pet peeves of mine). Bob uses this story to illustrate how PCI-compliant companies are breached.

Before reading my punchline, please read the article: Bob Russo: Breached!

Stop. Go back; you didn't really read it…

Ok, anyone notice something missing from Bob’s story? Immediately following the police investigation the DA (DA playing the part of the card brands) didn’t levy fines for PCI non-compliance. His HOA (HOA playing the part of an acquirer) didn't kick him out for not properly securing the premises. He was not required by various states (cameo appearance, playing the part of themselves) to send out breach notifications to all the contacts stored on his laptop. He didn't make headline news with "Russo Exposes PII!" Lastly, he was not hit with one or more class action lawsuits for the stolen Personally Identifiable Information before the ink had a chance to dry on the police report.

Hmmm… I wonder if my name and email address was contained in his contact list.

Tokenization IS Encryption - NOT! - Part 5 (pre-release teaser)

The saga continues. As PCI SSC continues redefining and clarifying its newly redefined definition of tokenization via the PCI Tokenization Task Force, EMVCo apparently decided they liked the term "tokenization" so unbeknownst to anyone else, a new EMVCo definition was necessary. Last month EMVCo released the EMV Payment Tokenisation Specification v.1. Luckily they misspelled it, probably on purpose, so-as not to confuse EMVCo Tokenisation with PCI Tokenization whereas PCI Tokenization always gets confused with TrueTokenization®.

I find it funny that just like PCI SSC, EMVCo didn't bother to approach the inventors of tokenization during the development of their definition. Hindsight being 20/20, I really wish Shift4 had trademarked the term tokenization prior to releasing the concept to the public domain. At least then we could have better controlled the definition and limited the misuse of the term. Instead we now have everybody and their brother coming forth with their custom definition, complicating and confusing a concept that was designed to be simple, easy to explain and secure. Anyway, I'm currently reading and analyzing the EMVCo document. Stay tuned for a detailed report…

The Economics Of EMV

A fellow blogger PCI Guru created an informative post on his blog explaining some of the reasons why EMV adoption is so slow in the US:

• http://pciguru.wordpress.com/2014/01/10/the-economics-of-emv/

If you have any comments on the post, feel free to post them on his site -- I won't be offended.

Earth to Media, Earth to Media, Come in Media…

Target breached, and EMV would have done nothing to prevent it. Period! I realize there are a lot of EMV fans out there stating differently, but please reference people that really know EMV -- its advantages and its limitations -- before releasing propaganda pieces painting EMV as the silver bullet it is not and calling it news.

What EMV cannot do: EMV does not protect the PAN, expiration dates, CVV2 or even PINs in anyway. While information as to whether or not PINs were stolen in the Target breach is sketchy, all the other information was stolen and EMV does not protect any of this.

What EMV can do: EMV is very good at preventing the stolen information from being used to create forged cards to be used for card-present (swiped) purchases, but if history repeats itself, the stolen information will primarily be used for card-not-present (ecommerce) purchases. Until EMV and/or the card brands address card-not-present purchases, EMV is nothing more than a one legged stool.

EMV Rumblings

For anyone researching EMV, I wanted to share some links to some EMV discussions I think are useful. These discussions go beyond the standard EMV talking points that the card brands and various EMV card and hardware vendors are promoting.

1. Shift4 Blog: Executive Insight: EMV is Coming – Gradually
   http://www.shift4.com/blog/post.cfm/executive-insight-emv-is-coming-gradually
2. PCI Guru Blog: Why the continued push for EMV?
   http://pciguru.wordpress.com/2013/12/09/why-the-continued-emv-push/
3. LinkedIn - Credit Card Professionals: EMV Migration
   http://www.linkedin.com/groupItem?view=&gid=65738&type=member&item=5813650964527202308&qid=e02d8018-d61d-4bd0-90be-ecb949d1940f
4. LinkedIn - Credit Card Professionals: Silent Migration of EMV in the US
   http://www.linkedin.com/groupItem?view=&gid=65738&type=member&item=5805992742135803905&qid=82b8afd2-ba40-4f38-a26e-ae5edd21865b

Enjoy.

The Great Token Divide

Recently I had the privilege of deciphering a USPTO process patent to determine what is claimed and then to determine if any of our technologies infringe upon it. I have received several of these requests as of late, and I'll be writing on the others in coming months. Currently in the payments space, patents are all the rave – hence the recent spree of research requests.

Before I begin, let me be perfectly clear. I think process patents should go the way of the dodo. I believe that most process patents do nothing more than stifle innovation by giving a monopoly or barrier to competition to the first to file – whether or not the process existed or was in use by competitors prior to the filing. There is a key requirement to patents that, in theory, prevents what I call frivolous patent filings: "Inventive step and non-obviousness." But there is a loophole here: The United States Patent and Trademark Office. Simply make a claim with sufficiently confusing details and jargon, throw in a few references to other parts of the same patent, and poof – patent approved!

Now that I briefly side-tracked this post with my rant on process patents, let me get back to an old favorite subject of mine – and the thing that scared me most about this most recent patent I reviewed. That subject is how scary implementations of tokenization can be thanks to the Great Bastardization of Tokenization by the PCI SSC.

I began my research after receiving this email:

Hey Steve,

I’m no expert on patents, but wouldn’t this fall under prior art from us?
http://www.hispanicbusiness.com/2013/12/4/patent_issued_for_system_for_protecting.htm...

The article references US patent 8,595,850.

US patents can be very confusing to read. When researching for possible infringement the Claims section is the most important part. The rest of the patent text is used as background info and sometimes claim context to justify to the USPTO that the patent passes their "inventive step and non-obviousness" requirement.

This patent makes 7 claims, but claims 2-7 each refer back to claim 1. So here is claim 1 with the important information highlighted:

1. A method of generating a token using computing equipment associated with a token generating organization, comprising: with the computing equipment, receiving a token request from a token requestor over a communications network, wherein the token request includes a number; with the computing equipment, mapping half of the number to a half-token; with the computing equipment, modifying the half-token; with the computing equipment, mapping the modified half-token to an additional half-token; with the computing equipment, modifying the additional half-token; and with the computing equipment, combining the modified half-token and the modified additional half-token to form the token.

Based on my reading of the originally referenced article and the patent description, what I think they are doing is pre-calculating a “half-token table.” Basically, this appears to be a shuffled list of all possible 3-digit numbers (000-999 randomly shuffled). They then pull three digits of the primary account number (PAN) that they want to “tokenize” (most likely they are preserving the first 6 and last 4, so starting at the 7th digit and tokenizing through the 12th digit – assuming a 16 digit PAN), they look up the corresponding token for the 3 digits. Then they take the next 3 digits in the PAN, and using the first “half-token,”  they do a little magic and sprinkle some holy water and “tokenize” the second half. In the article and within the patent description there are several references that this is a reversible process and this is the scary part. In encryption terms, the entire shuffled half-token table would be considered the key. If it’s ever exposed, all the unprotected tokens that are based on this file become instantly decipherable.

These tokens are obviously mathematically related to the PAN and I believe this vendor calls them "vaultless tokens" because the PAN does not need to be stored – they can be recreated (decrypted) from the token and the "half-token" table. This mathematical relationship was specifically forbidden in the original tokenization definition, but PCI SSC – with the help of the Tokenization Special Interest Group (other vendors with non-tokenization solutions that wanted to ride on the tokenization coattails) and in the name of vendor neutrality – allowed for schemes like these to be called tokens.

Now, security wise, here is the difference between tokens generated under this patent, which still qualify as PCI-compliant tokens, and TrueTokens^®, which are non-mathematically related. To compromise the tokens generated under this patent, all one needs is a copy of the "half-token" table and all the tokens generated by the table can be decrypted. But with TrueTokens, to compromise the PANs one would need a copy of the entire "vault" which contains both the PANs and the key(s) used to encrypt the PANs within the vault. PCI requires PANs to be encrypted when stored and mandates proper key management – not so with the "half-token" table.

By accommodating mathematically related tokens in PCI's definition of tokenization, they opened the door for weaker tokenization solutions like this. The problem is, QSAs must either dig deep into the details of each tokenization solution they come across to determine whether the merchant is using a legitimate tokenization solution (like TrueTokenization), or a tokenization in name only (TINO) solution, which wears the tokenization name badge but provides non of the security and scope reduction. This type of solution analysis adds costs to an audit. Unfortunately, the QSAs alternative is to assume that every solution is a TINO, which impacts scope (adding another cost).

Obviously, Shift4 does not infringe on this patent, because we wouldn’t release garbage like this if our life depended on it. That's my take on this patent. I welcome your thoughts.

Until next post…

Recently I found this intro to my blog:

Content Warning

Some readers of this blog have contacted Google because they believe this blog's content is objectionable. In general, Google does not review nor do we endorse the content of this or any blog. For more information about our content policies, please visit the Blogger Terms of Service.

I guess I ticked someone off. I'm not sure what spawned this warning. If you have an objection or are offended by what I write, please post a comment to the offending entry. I encourage you to debate me or at least post your disagreement. I don't bite -- much. ;-)

The Zero-Day Flaw

Remember the days when a flaw was a flaw and an exploit of one of these flaws was an exploit? Now-a-days people and vendors throw around Zero-Day Flaw like it's a marketing term. There is no such thing as a flaw, only updates that add features and "enhance security" and emergency hot fixes that plug zero-day flaws that hackers somehow create. I predict that the next generation of marketization will be the dropping of "flaw" and reframe the term as Zero-Day Hack. This way there is no implication of a flaw.

To me, this is akin to people using the word "opportunities" for the word "issues", "issue" for "problem", "not being truthful" for "liar".

Tokenization IS Encryption - NOT! - Part 4

Oh no -- I've stepped in it again! I did not plan of four parts, but the saga continues:

• http://www.shift4.com/blog/post.cfm/tokenization-is-encryption-not-part-4

Some day the saga will end. While comments can be posted here or there as I read them both, posting comments directly on the 4titude blog will probably confuse people less as they have something to reference.

PCI's Biggest Failure

Dog Pile!!!

I've done it again. You can see my latest rant Dog Pile!!! that conveys some of my, let’s say “passionate” thoughts on placing more burden on merchants for breaches. Enjoy.

Would you like SLIME coated SPAM with that?

Does anyone else get annoyed with installers, or worse, auto-updaters that constantly sneak in the pre-checked browser toolbar du jour? This is a pet peeve of mine. Two of the biggest offenders on my list are Oracle with their Java and Adobe with their Flash, Shockwave and PDF viewers. These two companies I'll barely tolerate but with most other companies, I'll abort from the installation process as soon as I see the pre-checked toolbar option.

To me, this is a slimy tactic to create a revenue stream for the vendor -- they get paid for tricking people into installing these toolbars. Akin to stuff used cars salesmen would do in years past that gave their profession the stigma they still have today.

If you get annoyed as me, I urge you to complain to these companies. Demand that they quit trying to trick users into installing toolbar or any additional SPAM. Simply un-checking the option by default would eliminate the slime factor, greatly enhancing the vendor's reputation.

Back to work now. Thanks for reading.

Complete List of PCI-Validated P2PE Applications and Providers

Validated P2PE Solutions

(this page intentionally left blank - really! - click here to view)

Validated P2PE Applications

(this page intentionally left blank - really! - click here to view)

On the 4titude blog (Shift4's Voice with Attitude), there is a recent post: Why Shift4 is Not (Yet) a PCI-Validated P2PE Application Provider. I created this post to debate anyone who might disagree -- just keep it civil.

Cybertheft Crackdown My Butt

I've read several stories of late flaunting some high profile cases where it seemed law enforcement and judges were finally cracking down on cybercrimes and cybertheft. I thought we finally made the turn and were prosecuting the perpetrators (hackers) of these crimes the way they should have been prosecuted all along. Then I read this today: http://www.bankinfosecurity.com/rbs-worldpay-sentence-too-light-a-5058/op-1

In a nutshell, the mastermind of the RBS WorldPay hack, where $9 million was pilfered from U.S. bank accounts, was sentenced to 30 months in prison and ordered to pay $89,000 in restitutions. Let's see, $89,000+30 months for $9 million, that comes out to a $297,000 per month. That's a pretty good payoff. I understand that he had accomplices' so he did not pocket the entire $9 million; but many wannabe hackers reading this will see it as $9 million for 30 months. This sends a strong message: Cybercrime pays!

Until sentences are large enough to discourage the crime, nothing will change: More money will need to be spent for cyber security -- more hacking -- more money -- more hacking -- and so on…

My Take on PCI DSS Compliance

As promised, I finished my PCI usefulness post. It can be found on the Shift4 4titude site:

PCI Provides No Benefit to Merchants

As the title suggests, it is not a glowing review of PCI, or more specifically PCS DSS compliance. Anyway, I don't want to give away too much here. Enjoy.

Global Payments Breach Growing

The latest reports I read are that the Global Payments breach started in January 2011 -- more than a year earlier than initially thought. To me the story here is that during this timeframe Global Payments went through at least two onsite PCI audits and neither caught the breach in progress. Since Visa and MasterCard were so quick on pulling Global Payment's PCI certification, should they not also pull the QSA's certification(s) as well? I'm not sure if there were more than one QSA involved nor am I certain who it was -- but that does not really matter as my next post will describe. I am currently writing a post on the usefulness of PCI, or lack thereof. Stay tuned...

Durbin Debit-Rate Cuts Failed to Help Consumers: Analysts

I think by now everyone knows my stance on Dodd-Frank. File this under "color me surprised": http://www.americanbanker.com/issues/177_84/fed-durbin-debit-rate-cuts-1048944-1.html