DrewDilloNet

Securosis is right on a number of fronts about what you’ll see in Data Security at the RSA Conference this week. And, from the discussions I’ve been in with the analyst community recently, you’re about to be blasted with all kinds of coverage of aliasing / tokenization and format preserving encryption (FPE).

Full disclosure, I do work for a company that competes in this space, but I really do have concerns about what customers are being promised and the shortfalls they may not yet understand.

Tokenization, per Securosis:

… replaces credit card numbers or other sensitive strings with random token values (which may match the credit card format) matched to real numbers only in a central highly secure database.

It’s not new. Also known as “data aliasing”, Shift4 and Ingrian both offered this as a service going back as far as 2005. A number of credit card processors have also offered transaction IDs the same size/shape of credit card numbers for years. Companies I spoke with still needed, or thought they needed, credit card numbers for marketing demographic data.

What changed? Partially hype, partially that companies began to offer tokenization products. I do credit that hype for teaching companies their options, but, as with all hype, some of those now excited about tokenization just aren’t good candidates.

Why it’s the best thing since sliced bread:

• Systems that don’t need to use sensitive data are taken out of PCI audit scope. Though, per the latest PCI FAQ, a system strongly encrypted (read: entry point for FIPS in PCI), is also out of scope for PCI audits.
• Sytems can pass around data without expanding data types to hold expanded ciphertext. There are a number of encryption modes that perserve data length, but who is to say that the resulting ciphertext won’t contain a character a system can’t handle (string terminator, etc)?
• Systems may continue to use sensitive data as primary indices. This is more common for SSNs or tax IDs, which is why a lot of tokenization deployments actually begin with HIPAA or SOX compliance.

Why it’s worst thing since Windows Vista:

• This free lunch is more expensive than most. Think about it: if just one of your applications starts speaking tokens, while all others are speaking credit card numbers, the whole house of cards falls. Meaning, there is no piecemeal deployment. All systems must be changed at once, a level of coordination I have rarely seen in the enterprise.
• This may change with some of the transparent database encryption vendors making inroads, but today, also per Securosis:
  

  No matter what anyone tells you, there are always requirements for application and database changes, but some of these approaches can minimize the pain.

FPE, per Rich again:

Format Preserving Encryption encrypts the numbers so you can recover them in place, but the encrypted values share the credit card number format.

That’s a little high level for we tech weenies. Proponents of FPE bill it as a mode of AES that returns data of the same input type (ASCII, numeric, etc.) and the same byte-length as the input.

There’s a lot of interesting thought behind how this works, but no magic. If you decrease the number of inputs to a certain function, you can decrease the size of the resulting vector space by the same amount. This is legal in math and thus crypto.

In a wild oversimplification: a function can be found f(x), such that for values of x only being 16 bytes within the ASCII numeric range, the output y will also be within the 16 byte ASCII numeric range.

Why it’s the best thing since sliced bread:

• The same pluses, generally, as tokenization. Note that, unless your auditor finds FPE to be in the “strong encryption” bucket, per the new FAQ, FPE does not remove systems from audit scope.
• “Local” options are much cleaner than tokenization. Libraries that can receive AES keys and operate remotely, POS, etc., can perform FPE autonomously for extended periods of time very easily.

Why it’s worst thing since Windows Vista:

• The same drawbacks as tokenization, there’s a large coordination/conversion effort that requires all hands on deck.
• Some FPE AES modes are “under review” by NIST, for what that’s worth, but there is yet no standard. Meaning, the FPE you buy today may be different if/when these mode finally get approved. Or they may never be approved at all and vendor lock-in could be painful to pull out of.
• Combinatorially speaking, decreasing the vector space to ASCII or, more so, to numeric values of ASCII, means a much smaller number of possible outcomes. Anyone attempting to crack AES CBC may have a leg up knowing that the input is a credit card and will thereby be limited to numeric ASCII, but limiting the output would seem to raise the odds of collision yet higher.
• FPE has the same key rotation complications of regular encryption. The matter is even worse in FPE land, where these values may be all over the place and rotating them en masse means a repeat of the intial roll out for each rotation. As long as PCI requires six month to a year rotations, this is a big problem.

We hear it all the time now. Mom and Pop shops calling us up and asking about tokenization/aliasing or FPE, when all they have is one Oracle database. Each definitely serve a need, but do go into each with your eyes open. They’re not quick fixes and there ain’t no such thing as a free lunch.

See you at the conference.