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.