Back in October 2005, Shift4 announced "tokenization" capabilities in its $$$ ON THE NET product and at the same time release the tokenization technology to the public domain (Shift4 Releases New Technology to Insure the Security of Its Merchants' and Partner's Payment Processing). Two months later, Dr. Heather Mark, Ph. D., CISSP, published a white paper on the difficulties and weaknesses of encrypting data and the benefit of using a "tokenization" technology (Storing Credit Card Data: A Look at the Business Needs, Regulations and Solutions Surrounding the Issue). In this posting, Tokenization - Part 1, I'll try to define exactly what tokenization is and the benefits it has over data encryption (the primary benefits were covered in Heather's white paper but here I'll try to provide a shorter version). Part 2 will cover how tokenization can ease the burden on POS vendors and merchants to comply with many of the payment security regulations like CISP, PABP, PCI/DSS, etc. Part 3 will give real world examples on how tokenization was implemented in POS and other applications and again reemphasize how tokenization is more secure than storing encrypted data. Other parts may follow based on the how these first three go...
Tokenization - Huh?
Webster's defines token as "Something serving as an indication, proof, or expression of something else". We are using "tokenization" as the process of substituting a unique identifier (a token) for a card number. This token, for all intents and purposes, is a random unique value and has no way to be deciphered to gain knowledge of the associated card information. Instead, the token is used to initiate payment requests or updates of an already existing payment transaction (voiding a sale, flagging an auth only transaction as a sale, etc.).
I use strong industrial strength encryption – Where's the weakness?
There are several very strong encryption technologies available: triple-DES, AES, Blowfish, RSA, etc. Ignoring any inherent known or unknown weaknesses of one encryption method over another, all these technologies have the same weakness: key storage. The theory behind securing data using encryption is simple: scramble the data to make it unusable for unauthorized use. Encrypting the data (making it unusable) and decrypting the data (returning the data to it's original & usable state) requires keys - a key to lock the data, a key to unlock the data. With most of the encryption techniques, the same key is used to lock and unlock the data. The problem is: How do you secure these keys in the POS application? Once these keys are compromised, the "secured" data is no longer secure.
This problem of securing the keys is very difficult in a compiled POS application and is all but impossible in a shared web-hosting environment that many web sites use. A common technique that POS vendor's use to secure the keys is to encrypt (a catch-22) these keys using a hard-coded password that "only the application knows". In a compiled application, obfuscation (hiding) techniques can be used to give a reasonable level of confidence that the keys are secure. On the other hand, most web sites use scripting languages and hiding the hard-coded encryption keys in these scripts is very difficult.
How is tokenization stronger?
The best way to secure data is to not store the data. This is the theory behind tokenization. The token can be used for initiating new transactions or modifying existing transactions, but beyond this context, it is useless data and there is absolutely no chance it can be used to gain knowledge of the real card information.
Let's assume a worst case scenario: Your Xyz Application data files are not secured in anyway, no encryption techniques have been used, and these files have been given to the world. Obviously, if full card information were stored in these files, you would be in a world of hurt with your customers, your bank, the card associations and quite possibly government and/or law enforcement officials.
Keeping with the worst case scenario: Even if Xyz Application encrypted the card information in these data files that were distributed worldwide, the card associations as well as several states have enacted laws that would require you to notify your customers of the breach because the data can potentially be decrypted. Sure, the data might be securely encrypted, but how confident are you that given enough attention by a dedicated hacker, the decryption keys won't be compromised? In other words, even if encryption techniques are used, merchant reputation wise, you are still in a world of hurt.
Continuing with the worst case scenario: Your Xyz Application stores the token instead of the sensitive card information and these data files are again distributed, it does not matter if they were encrypted or not, no card information was compromised. Your customers do not need to be notified of a breach based on the compromise of card information. Obviously, you may still have to notify your customers or officials based on other sensitive or personal information stored in these files, but not as far as the payment regulations are concerned.
Conclusion
Shift4 released the tokenization concept to the public domain in the hopes that other gateways and possibly even the card associations will embrace the technology, making for a more secure industry as a whole. This posting, part 1, is very generic and non-Shift4 specific. With parts 2 & 3, I'll try to be a generic as possible but they will most likely include sections that detail Shift4's implementation of tokenization.
Here I've tried to briefly describe what tokenization is along with how & why it is stronger than encryption when it comes to the storage of credit card or any payment information. If you have not already done so, I urge you to read the white paper by Dr. Heather Mark - she has a lot more experience writing on the topic of security so she might explain concepts better than I.
Please feel free to comment. Check back later for parts 2 and 3 and maybe more…
No comments:
Post a Comment