Blog

Visa’s Data Field Encryption

By Adrian Lane

I was reading Martin McKeay’s blog this morning and saw his reference to Visa’s Data Field Encryption white paper. Martin’s point that Visa is the author, rather than the PCI council, is a good one. Now that I’ve read the paper, I don’t think Visa is putting it out as a sort of litmus test on behalf of the council, but instead Visa is taking a stand on what technologies they want endorsed. And if that is the case, Rich’s feeling prediction that “Tokenization Will Become the Dominant Payment Transaction Architecture” will happen far faster than we anticipated.

A couple observations about the paper:

… data field encryption renders cardholder data useless to criminals in the event of a merchant data breach decryption.

Use robust key management solutions…

and

Visa has developed best practices to assist merchants in evaluating the new encryption…

Use an alternate account or transaction identifier for business processes that requires[sic] the primary account number…

The recommendations could describe tokenization or format preserving encryption, but it looks to me like they have tokenization in mind. And by tokenization I mean the PAN and other sensitive data are fully encrypted at the POS, and their response to the merchant is a token. I like the fact that their goals do not dictate technology choices, and are worded in such a way that they should not be obsolete within a year.

But the document appears to have been rushed to publication. For example, goal #4: protect the cryptographic operations within devices from physical or logical compromises. It’s the cryptographic operations you want to protect; the device should be considered expendable and not sensitive to compromise.

Similarly, goal #1 states:

Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption.

But where is the “point of encryption”? It’s one thing to be at the POS terminal, but if this is a web transaction environment, does that mean it happens at the web server? At the browser level? Somewhere else? Reading the document it seems clear that the focus is on POS and not web based transactional security, which looks likes a big mistake to me.

Martin already pointed out that the authors lumped encryption and hashing into a single domain, but that may have been deliberate, to make the document easier to read. But if clarity was the goal, who thought “Data Field Encryption” was a good term? It does not describe what is being proected. And with tokenization, encryption is only part of the picture. If you are a web application or database developer, you will see why this phrase is really inappropriate.

Make no mistake – Visa has put a stake in the ground and it will be interesting to see how the PCI Council reacts.

No Related Posts
Comments

If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.