Thursday, June 18, 2015

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...

Tuesday, October 14, 2014

Bob Russo: Breached!

There is a brief article that I found on 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.

Friday, April 11, 2014

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…

Friday, January 10, 2014

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:
If you have any comments on the post, feel free to post them on his site -- I won't be offended.

Friday, December 27, 2013

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.

Wednesday, December 18, 2013

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
  2. PCI Guru Blog: Why the continued push for EMV?

Friday, December 13, 2013

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?

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…