|
GuestView Columnist David Taylor this week discovered that there’s a lot more than token opposition to tokenization. One of the concerns is that companies have already spent money on encryption. The most popular reason for not implementing tokenization is that companies have already implemented data encryption and key management systems costing hundreds of thousands of dollars, and either they did not feel they needed tokenization or they were unwilling to be perceived by upper management as “changing course” by recommending the removal of the data they just spent all this money to protect. Read more. |
New stats out of India show three things: a sharply growing acceptance of the Internet (27 percent year-to-year increase); embracing of American sites (the top three most popular sites were from Google, Yahoo and Microsoft); and huge growth potential, given that barely 3 percent of its people today use the Internet.
Wal-Mart is certainly a company of few words. But when the world's largest retailer (it's expecting to hit $400 billion in annual sales later this year or early next year) wants to make a technology endorsement, a few words are all that's necessary.
In an eerie snapshot of where some top marketers want to take the next generation of search engines, a Japanese government-backed research project is working on a search that is based on what a user does, not a keyword a user types in.
Staples' Canadian operation has been quietly testing 2-way live video kiosks at 34 locations, but these kiosks do more than talk with customers: They remotely control hardware, including scanners and payment authorization devices.
Guest View Columnist David Taylor points out that PCI compliance has consistently generated larger security budgets, with little or no requirement for justifying them, other than "our bank told us we have to do it."
Despite an almost universal embrace of the idea of merged channel, most retailers aren't getting any closer to making it a reality, with overly restrictive inventory reserve policies, inconsistent data and political resistance getting most of the blame, according to a new Forrester Research report.
This issue's Reach Of The Week goes to IT analyst firm IDC and its report released Wednesday (July 16) that its survey of 250 execs "found that there is a growing level of commitment" to supporting green programs. So far so good, but let's look a little closer at these IDC figures.
A handful of Stop & Shop stores have been using in-store location tracking—coupled with basket content—to narrowly target ads to customers using handheld shopping devices, the chain confirmed in a statement issued Thursday (July 17).
Consumers older than 50 are rapidly growing fond of the Web, with such users checking news, for example, more frequently than those younger than 20 as well as participating in online communities more. But the study found that instant messaging and video downloads were "still tools for young users."
For those e-tailers wondering if video is an effective way to reach American consumers, here's the latest video stat, courtesy of Comscore: In May alone, U.S. Internet users viewed more than 12 billion online videos, representing an increase of 45 percent versus one year ago.
Bill Homa, who just stepped down July 1 as the CIO for the 165-store Hannaford grocery chain, considers Microsoft's OS to be "so full of holes" and describes the fact that current PCI regs do not require end-to-end encryption as "astonishing."
Retail deployment of the 2-D barcode, a technology that allows consumer cellphones to see virtually unlimited amounts of content by taking a picture of a special barcode, has slowed after an initial flurry of activity in January. But several major cellphone carriers are preparing to bundle the 2-D barcode software with phones as they ship. Will that make a difference?
Two recent developments—one involving a New York federal judge and the other involving a group of U.S. senators—are signaling serious difficulties for E-Commerce efforts over the next two years.
The number of reported data breaches has been soaring, with the figure from the first six months of 2008 some 69 percent higher than the number from the identical period last year. Among those were little-known recent breaches of Facebook, H&R Block and BearingPoint.
Fujitsu is hoping retailers in the United States will embrace a checkout system used by some European stores, but untested in the U.S., that splits scanning and payment processes into two different stations in the store. If American retailers decide to switch to this system, it will call for a significant overhaul of their current checkout systems.
Guest View Columnist David Taylor argues that outsourcing is considered the thing to do these days, like a summer barbecue. But it's both easier and more complex than most merchants think.
RFID vendor Impinj on Thursday (July 10) purchased all of Intel's RFID operation--including the R1000 RFID reader chip. A joint Intel/Impinj statement said that the acquisition details are not being released, but The Seattle Times reported that Intel will get an equity stake in Impinj.
No sooner had IT concocted a system to try and automatically detect an under-age shopper than someone has crafted a remarkably low-tech way to fool it. How low-tech? How about a picture ripped out of a magazine?
Will consumers ever deploy counter-top barcode scanners and a Web site to have groceries delivered to them automatically? A company called Ikan.com is hoping they will.
A new E-commerce payment system at UrbanOutfitters.com allows users to complete purchases in one screen, boosting cart conversion rates by 19 percent.
The PCI Security Council is branching out a little, with an attempt to bring unattended payment terminals (UPTs) under its jurisdiction. As kiosks get more sophisticated and start taking cash, credit cards, mobile transactions and other payment methods, the UPT security risk is sharply increasing.
A semiconductor company is suing a Dutch university to keep its researchers from publishing information about security flaws in the RFID chips used in up to 2 billion smart cards.
Amazon.com on Wednesday (July 9) finally deployed Bill Me Later as a payment option, almost eight months to the day after Amazon announced its intent to do so.
For the second time in two weeks, one of the largest grocery chains in the U.K. hit a snag with its Web site, triggering a 24-hour outage and causing the 823-store retailer to use a temporary homepage. Sainsbury's, a $38 billion retailer, is calling these incidents coincidental.
When the $1.3 billion JCrew apparel chain launched its new Web site on June 29, it was the culmination of a 2-year deployment effort. Seems that customers may have to wait a bit longer to fully use those new capabilities, as the site quickly crashed and has suffered significant slowdowns ever since.
J.C. Penney customers are twice as likely to say they are highly satisfied with their in-store shopping experience if they are working with store employees who are accessing the company's Web site while standing next to them.
When an order processing snafu shut down the delivery operations of one of the U.K.'s largest grocery chains, the $38 billion retailer acted starkly different than the typical U.S. retailer. The London-based 823-store Sainsbury's grocery chain immediately issued almost a half-million dollars' worth of vouchers.
A new Retail Systems Research report is challenging the way retail IT looks at application development backlogs. The report is based on a survey showing that some 79 percent of retailers have appdev backlogs of at least a year, with one-fifth of those hitting delays of more than two years.
The conventional wisdom has held that China is not likely to embrace E-Commerce, because of the Chinese aversion to credit payments and fears of piracy and poor quality products. But a Forbes story this week makes a powerful argument that E-Commerce—and a credit-card lifestyle in general—will be coming to China very soon and in a big way.
In one of the first wide-scale studies of SMS' capability to hold up under volume pressure, the technology fared "surprisingly" poorly, according to Keynote Systems. This has particular significance for retailers, who are exploring the technology's use for mobile communications connecting to both online and in-store.
A U.K. company is pushing retailers to use voice-recognition to authenticate purchases over the phone and online. The Voice Commerce Group's Voice Transact package has consumers call the service, quote a pre-arranged product code and then a series of digits dictated by the automated system. 
A federal appellate court backed a group of retailers Monday (June 23)—including Best Buy, Circuit City, Costco and Lowe's—by ruling that their gift card systems do not violate any patents.
Internal audit is not staffed to enforce PCI at the store level, argues GuestView Columnist David Taylor. Except for about a dozen leading retailers, most retailers do not have enough IT-skilled internal auditors to meet the requirement for a "continuous" review of store-level IT security.
Wal-Mart and a handful of others have been trying to do green the right away, with policies that will have a significant environmental impact and that also improve operations.
When Oracle finally introduced its Retail 13 integrated suite this week, after three years of acquisition and integration, the teams working for the world's largest enterprise software vendor might have breathed a sigh of relief.
Are European retailers going to have any better luck than American retailers with consumer-facing biometric payments? The 750-store Albert Heijn supermarket chain, the largest such chain in the Netherlands, is about to find out.
The Moodys Investor Service has upgraded how important a retailer's E-Commerce activity is when assessing that retailer's overall economic health. Although this isn't a radical change for the financial firm—and the thought that E-Commerce is important is hardly surprising—it's one of several recent moves suggesting that the young teen-age Web is starting to be taken a wee bit more seriously.
North American self-service transactions will process $607 billion this year, a figure that is projected to soar to $1.7 trillion by 2012, according to report published Wednesday (June 18) by the IHL Group. When IHL began work on the report, "I did not expect the acceleration that we're seeing in the out years," said IHL President Greg Buzek. "I did not expect how fast it's growing."
One of the repeated arguments made in retail data security circles is that retailers tend to have much weaker security because it's not as much of a cultural priority as, for example, banking. So it's a little bit consoling that the latest ATM databreach is apparently not the result of a retail breach, not the result of social engineering and the trusting bank clerk, but is the first proven incident of a bank server's breach linked to ATM fraud.
A pair of unrelated reports out this week are challenging several fundamental IT security assumptions, including that data breach laws will reduce consumer losses and that insiders account for more thefts than external evil-doers.
Just in time for Friday the 13th, Oracle is finally ready to unveil Oracle Retail V 13, with a formal rollout slated for Tuesday (June 17). Oracle's main retail suite is not expected to undergo any radical changes (even the name change is expected to be slight); it's mostly claims of better integration and interoperability.
E-tailers in continental Europe are just now starting to get hit by slower growth, but they are still shining much more brightly than their U.S. counterparts, according to new figures from eMarketer.
For the second consecutive workday, Amazon.com suffered a major crash on Monday (June 9), with the increasingly unlikely scenarios explaining why the historically robust site is failing.
When Best Buy launched a Spanish version of its site last fall (2007), E-Commerce officials quickly noticed unexpected activity, such as customers spending twice as much time on the Spanish site.
Note to retailers looking to offer free Wi-Fi: It's a good idea to first make sure you can make the offer. Starbucks discovered that an offer of two hours of free Wi-Fi a day simply wasn't working. "Due to overwhelming interest in Card Rewards we are currently experiencing difficulty accessing Starbucks Card accounts. We are working to fix the problem and ask that you please try again later," said a page shown to site visitors.
The Meijer department store chain—with 182 stores in Michigan, Ohio, Indiana, Illinois and Kentucky—is getting creative with its Web site, food recipes and online coupons.
New York State has started pushing to collect sales tax from e-tailers that have no physical presence in the state, prompting Amazon and Overstock to fight back. But all e-tailers are hoping against the odds that other states don't pull the same revenue-generating attempt. If New York gets legal greenlights, several more states will quickly mimic its efforts, leading to a flood of almost every state within two years.
The worst performance grades were given to Foxnews.com, IGN.com, Gamespot.com, CNN.com, Break.com and ESPN.go.com. The best performance grades were given to Google.com, Live.com, Orkut.com and Craigslist.org.
GuestView Columnist David Taylor asks: What would you do if one of your employees decided to leverage your brand and set up a little side business inside your store, including selling products via an E-Commerce Web site, setting up a merchant bank account and taking credit cards? You'd probably fire the person, right? But, what if you couldn't?
Shoppers at Gap.com will now be able to use a single shopping cart and consolidate shipping at any of the chain's four brands, the Gap announced on Tuesday (May 27). But the change for The Gap, Banana Republic, Old Navy and PiperLime is delicate, as the company still wants those brands to maintain their distinct personalities. Those conflicting goals give the new site a bit of a Jekyll-and-Hyde feel.
Borders this week officially stepped out of the shadow of Amazon and re-launched Borders.com, with an effort that scores points for creativity. The physical side of Borders (as in brick-and-mortar as opposed to Olivia Newton-John) has been trying to arrange its bookshelves to display more of the covers.
Germany's METRO Group is experimenting with RFID inserts to track meat and to immediately locate any product that is about to expire or that has expired. METRO is placing the inlays into the foam meat packing trays used in their Future Store.
May 12th, 2008 at 3:09 pm
I read with interest your article “Opposition to Tokenization a Lot More Than Token.” You made some interesting points, all valid but all can also be countered. I’ll address them in order:
1. Too much money already spent on encryption.
This is very true, too much money has already been spend on encrypting card holder data (CHD). There is a common saying here in Vegas, “don’t throw good money after bad.” While this advice is for gamblers, I also think it applies here. Yes, there are many managers and directors that fear their reputation and job is on the line if they now switch to endorse a less expensive, and many times a significantly less expensive, alternative. But there are other factors to consider, risk being a big one. Under PCI and many of the various privacy laws, loss of an encrypted file that contains CHD, even without the decryption keys, is still considered a breach that must be reported because the data has the potential to be cracked and exposed. Tokens are not considered CHD so the same scenario would not be considered a breach and would not have to be reported.
The weakest point with encryption is key management and this is an ongoing cost. Keeping keys safe turns into a catch-22 situation and many companies do not dedicate sufficient resources to this problem. Encrypted data needs a key. This key must be protected. The obvious solution is to encrypt the key. But now this new key needs to be protected. And so on, and so on – Key management solutions can help but in the end, somewhere the same weakness arises – and these key management solutions can be expensive. Throw in PCI 3.6.4 which requires annual key changes and rekeying (re-encryption) of the data, and the costs go higher.
2. Applications managers won’t give up the data…use card number in many different places in their processes and application.
Again, very true; but at what cost? If you look back at some of the latest breaches, CHD was not exposed from the POS. Ironically, it was exposed from risk management applications or the data in transit to these risk management applications. Tokenization can be used in these other processes and applications and would address both the data in transit problem as well as the data storage problem. I would argue that tokenization, or at a minimum, proper hashing should be required for these ancillary processes and applications and real CHD should not be allowed.
3. Waiting for bank or db vendor…lack of confidence with current tokenization vendors.
Waiting on you bank to offer this may be a long wait and if and when this does happen, the downside is that you would forever be locked into that bank. Having the database vendor do tokenization for you would not help ease your security burden – PCI wise, the database would be housing the CHD and to get the real benefit of tokenization, it needs to be hosted by a third party or at least a remote application.
There are larger vendors offering tokenization. To me, this argument is more of a smoke screen hiding the fact that the merchant simply does not want to change. Depending on the application, tokenization may impact the merchant’s processes and this fear of change translates to lack of confidence.
Whether or not my opinion on this is correct, this issue must be addressed and overcome. When we are speaking directly to a merchant, this issue can be overcome by showing all the advantages these changes will bring (cost and risk benefits) and giving references (in case our fear of change assumption is incorrect, and it really is a confidence issue).
4. Tokenization is too new or unproven.
This is a hard one to argue against because it’s hard to prove a negative. Have any breaches occurred where tokenization was used? Actually, let me rephrase that, has any token ever been used to expose data? I re-phrased my question because technically, with most tokenization implementations, there is an exposure point prior to the token being issued. While I re-phrased my question by narrowing the focus, but to date, no card data exposure has occurred to tokenized solutions using either question.
Since negatives are hard to prove, I get around this argument, simply detailing tokenization and how it works to secure data. It usually does not take much to show someone how a completely random sequence of data is more secure than card numbers, encrypted or not. Add details on the difficulties of encryption key management and this argument usually dissolves.
5. The tokenization vendor is a “single point of failure”…single point of attack.
As to the single point of failure, I can only speak for Shift4 and simply point to our track record. This is a valid concern ;evaluating vendors, uptime, resiliency, redundancy, as well as other factors must be part of a merchant’s criteria.
As to the single point of attack, true but I would argue which is safer: using a single vendor that specializes in payments and security that is scanned and audited regularly; or having the data housed by thousands of merchant locations of varying degrees security – from none to relatively strong? For the most part, the later describes the current environment and breaches are making headlines almost daily – not to mention all the smaller breaches that don’t make the headlines.
6. Tokenization pricing models are immature and too variable.
Again, speaking only for Shift4. Our tokenization comes free with our services – no up’s, no extra’s, no increase when we added tokenization. In fact, we released tokenization to the public domain back in 2005 because we felt that this technology, if properly implemented, is such a benefit to the security of CHD that it should be freely available to everyone.
In conclusion, you make very good points and all points that we (Shift4) have encountered ourselves. I just wanted to point out that all these obstacles can be overcome with the proper information and education.
Steven M. Sommers
Vice President Applications Development
Shift4 Corporation – http://www.shift4.com
May 12th, 2008 at 3:58 pm
Steven,
Thanks a lot for the comments — i believe they are longer than the original column, which appears to be a new record.
The tone of the comments is exactly right. When I was doing the interviews for the http://www.PCIKnowledgeBase.com, these are the types of resistance I encountered as I was saying positive things about tokenization, along the lines of what I said in my Feb 8th column.
In order to move the market forward, we have to be able to address each of these objections factually.
The PCI Knowledge Base was founded on the principle of the free exchange of knowledge and experience.
Storefront Backtalk promotes these same ideas, and I’m encouraged to take a position, even a controversial one, in order to promote discussion. I only wish more folks would take the time to present the issues and the facts as you have done.
Thanks, Dave Taylor
Founder, PCI Knowledge Base
David.Taylor@KnowPCI.com
May 12th, 2008 at 4:48 pm
Dave,
I knew that was what you were doing and your points are issues and concerns that we have already encountered. All the points are valid concerns for merchants, as they should be. I was just conveying how we counter the opposition. Keep doing what you do. I would rather have someone like you point out the various issues that can arise and address them than convey a grass is always green message. I equate the later to a sales brochure.
May 16th, 2008 at 12:06 am
As I’ve said before, tokens are much less secure than properly implemented public key based encryption.
Assuming the tokens are generated based on the account number, such as with a cryptographic hash, then the tokens are subject to a simple dictionary attack. If an attacker can freely access the tokenization routine, all the attacker has to do is feed every possible account number into the tokenizer until a match pops out. The attacker does not have to know the technical details of the hash routine (SHA-1 vs SHA-256 or MD5), all they need is access to it.
[ I’ve personally written such an attack against a tokenizer (that was SHA-1 based) and run it from my own desktop PC, and I recover whole account numbers in an average of four seconds. (I fixed a bug that previously kept it spinning for up to 40 seconds.) So I know first-hand that account numbers can be recovered from tokens. ]
So instead of protecting secret keys, you now have to protect this secret tokenization algorithm, in every single place it exists — registers, PIN pads, kiosks, web servers, etc. If you were unaware of this attack, you might not even know that you should be protecting it.
On the other hand, public key encryption is extremely secure, and key secrecy in the field is a non-issue. Public keys are intended to be distributed publicly — that’s the point. It’s the private keys that must be carefully held, but since they are used only at the decryption point they can be securely stored in a single, hardened, dedicated hardware decryption appliance (such as an Atalla box or an IBM mainframe with a cryptographic coprocessor.)
Sure, there are still points to harden in the stores, and a PCI audit is still a useful tool. File Integrity Monitoring can help insure that encryption routines are not tampered with, and that rogue software isn’t poking about where it shouldn’t. Constant patching of the operating system is needed to ensure that the encryption routines remain secure (the cryptographic PRNG is a critical component for security in a public-key protocol.)
That said, encryption is very easy to get wrong, and neither encryption algorithm design nor encryption protocol design should be left in the hands of amateur cryptographers. Any security system like this should be subjected to a rigorous review by several unbiased professional cryptanalysts, and should be based on sound designs with long track records in the cryptographic field.
I don’t mean to say that tokenization is not “better than nothing”. Obviously, recovery of the account numbers from tokens requires technical knowledge of the systems, and certain levels of access. But an insider could certainly figure this out, and without adequate monitoring and other mitigating controls they could be recovering accounts from tokens today.
May 16th, 2008 at 11:53 am
I agree that properly implemented public key encryption or PKI can be one of the best forms of encryption for card holder data (CHD) but there are two issues with this. To get the most benefit out of public key encryption in a point-of-sale (POS) environment, the POS cannot have access to the private key portion of the two keys. The problem is that many payment transaction requests to the banks and processors require two steps: an authorization step and a later settlement step. Both these steps require the CHD and therefore the POS would need access to the private key decrypt the CHD to perform the second step. This negates the biggest advantage of PKI. The second issue is that PKI is probably the most expensive form of encryption to properly implement. By expensive, I’m not referring to licensing costs because there is free code and libraries available. Instead I’m referring to the infrastructure changes required to support the physical and logical separation of roles between the system that house the public and private keys, database changes required to support the storing the encrypted data, all the access controls required for the keys, the annual rekeying of the data if it is archived, PKI is much more CPU intensive than single key encryption techniques (Blowfish, AES, 3DES, etc.), etc. etc. Many of these costs are not PKI specific, but instead are costs associated with housing encrypted CHD.
Now your whole argument is assuming the “token” = “hash” or “encrypted CHD” and that a hacker, if provided the tokenization algorithm, could de-hash (if that is a word) or decrypt the data. Being the inventor of the term “tokenization,” the definition you are using is incorrect. Shift4 invented the term tokenization, not the concept. The concept has been around long before PCI, CHD or even computers. A token is simply an object or in this case, a piece of data that symbolizes or is used to reference another piece of data – the CHD. A properly implemented token is not related in any way to the original data other than by reference. In law enforcement, case numbers are assigned to cases; most of the time these numbers are simply sequential numbers. The case number itself is a token. There is no way to decrypt the case number to determine the contents of the case. This is why I say we invented the term, not the concept.
Now there are vendors out there that are applying the same definition you did to the term tokenization. Against these implementations, your argument is very valid. But in our minds, these are not tokenization, or at least not properly implemented tokenization solutions – these we classify as hashing or encryption solutions.
Lastly leave you with a challenge. Below are test card numbers and their associated tokens in my testing database. I urge you or anyone to devise an attack on the tokens that reveal the corresponding card number:
AX 373400000000001 0001d7byvlgqmdzf
AX 373400000000001 0001713nfgjb20yt
AX 373400000000001 0001j4nr6pjb2js3
MC 5400000000000005 0005sf9fmmjb2yr3
MC 5400000000000005 0005hw29×2jb2j9z
MC 5400000000000005 0005ylmsg9jb2xnt
VS 4222222222222 2222dxdh61lvq68l
VS 4222222222222 2222f9nk2llvq92x
VS 4222222222222 2222y9wswygqm278
If you can crack this, I’ll buy your algorithm because you would have figured out a way to predict both future and past random events – the implications of which would be mind blowing (not to mention a great money maker ;-).
–Steve
May 17th, 2008 at 1:09 am
First, I’d like to thank you for taking the time to respond. Without any knowledge of how a system or protocol works I always assume the worst (it doesn’t pay to be kind in security), and it’s good to see that yours appears to be carefully designed, and is not merely a simple hash.
I’d like to rebut a few of your arguments against public key encryption, and then do a little analysis based on the data in your challenge.
In a PKI environment, the POS store systems absolutely do not need the private decryption key to reside in the terminal or store. Decryption for authorization and settlement purposes occur only at the headquarters location in a single secured environment.
Archived data should never need to be rekeyed (a dangerously unnecessary operation) unless there is a true breach. As a matter of fact, archived data is quite effectively end-of-lifed by destroying the private key held in the decryption engine, and in all backups of the decryption engine.
Absolutely there are costs associated with securing the private key. But I also assume there are comparable costs associated with securing access to the tokenizer, and especially to validating and authorizing the retrieval of the account numbers when it comes time to authorize and settle the account. I assume there would be little functional difference from the way it would be accomplished in a private key decryption operation.
Now, on to your challenge (the fun part!
Assuming that what I see is a list of unique tokens that each represent the same account number, then your tokenizer(TM) is doing a good thing — you are issuing unique tokens every time data comes in. You are preventing the attack I described, because you’ve not based your solution on a hash. I am gratified to see that.
My attack is based assuming a store local token generator, one that repeatably returns the same token for the same account number (i.e. a hash.) So, you pass that security test.
A little analysis of your tokens’ structure reveals you are fitting them into a 16 character field. Assuming the first four characters represent the last four digits (a good idea), you are filling the remaining 12 characters with a 36 unique value character set (0-9 and a-z), which means you have space for unique numbers up to 36^12, or 18 numeric digits. Not much room in there for a salted hash, but there is room for encryption of up to a 19 digit PAN (omitting the Luhn check digit). By the way, I applaud your choice to exclude case, as case sensitivity requirements make humans much more error prone.
I will note that without a locally available token generator, you cannot generate tokens when offline to your tokenizer, and therefore you must take some other action to protect the data in those circumstances. I do not have evidence to suggest how that might work in this environment. (As a plug, public key cryptography solves that problem nicely.)
But how does the client obtain the token, and still have a recoverable account number for settlement? You must pass the real account number into the tokenizer at some point. Therefore I assume your tokenizer is a service operated at a central location, fronting a token generating database, and that the local tokenizing routine run at the terminals is a simple proxy to this service.
And therefore, you must be transmitting the actual account number over the wire to the tokenizer — just as you would transmit the account number to perform an authorization. You’ve reduced the transmission of the account number from two times (auth and settlement) to one time (tokenization). But it’s still transmitted in a recoverable state to the central tokenizer.
Therefore, your security is equal to that of your line security. I assume that you transmit over an encrypted line. (If you’re transmitting the account number in clear text to the tokenizer, that would be an Epic Failure to protect the data.)
I’m basing the rest of this analysis on the assumption that you do not send the account number in the clear to the tokenizer.
Your security now rests on the strength of the transmission encryption OR (not and) the strength of the security surrounding the token database. If either point is successfully attacked, account numbers can be recovered.
Regarding transmission, there are three general ways you can protect the data: you can use TLS (by which I mean SSL or any flavor of public key encryption) with certificates, TLS without certificates, or secret key encryption.
Since you’ve expressed concern over both certificate handling and the performance of public key cryptography, it makes me suspect you’re using secret key encryption to perform the transmission of the account number. And if you are using secret key encryption, the secret key must be available to (or embedded in) the token-sending-proxy. That can be recovered by an attacker who gains access to the machine or disk image.
If you are using TLS without certificates, your tokenization is subject to a man-in-the-middle interception attack. It’s not particularly easy for a layman to do, but it’s certainly not difficult. And it can be done without access to the POS terminal at all.
Lastly, if you’re using TLS with certificates, congratulations, you’re using PKI.
So in the final analysis, it appears to me that your security rests on encryption technology. Yes, it’s transient; yes, it’s a one-time shot; and yes, the data storage is as secure as your token database. But your solution can not escape the reality of securing the data in flight any more than any other encryption solution. Plus it introduces the still unknown (unpublished?) security of your token database.
Now, if I’ve made any incorrect assumptions, please let me know. Without seeing the architecture and the interfaces to each system, I can only make educated guesses, but I could certainly be wrong at many, many points in the above analysis.
Lest you leave think I’m entirely negative, there are other factors working in your favor, and I’d like to reiterate those for anybody else still reading at this point. The most important is that your solution appears to be technically “available” to a typical retailer looking to purchase a solution. As this discussion illustrates, engineering a secure solution is not easy, and therefore it is expensive.
I also assume that you’ve done the “hard work” of securing access to your centralized tokenizing equipment, providing retailers with not only the hardware but a simple to follow script of “type this here, put this smart card here, type this there, and now you’re secure”. Simple instructions that lead to 99% protection are much more effective in the real world at securing most data than a theoretically secure solution that requires an army of professional cryptographers to implement.
May 19th, 2008 at 1:45 pm
Wow, I rarely come across posters that can keep up with me in text length and put as much thought as you have in what they type – want a job? I’ll try my best to summarize your points prior to my response so other readers don’t have to jump back and forth (too much).
WARNING: Much of the detail that follows describes the Shift4 implementation of tokenization. Because of this, it may come across as a sales pitch. This is not my intent; it just happens to be the implementation that I am most familiar with and the only one I can speak on with any authority.
PKI decryption/centrally located secure environment at headquarters – I was not assuming that you were talking about this level of a merchant. I usually gear my arguments for all merchants but especially level 4 merchants because they are the ones feeling the most pain. Many merchant that we target do not have the resources or the expertise to create the secure centrally secured CHD environment so I was assuming that all the work was being done at the POS. We released the tokenization concept to the public domain so merchants and others could do there own HQ type payment environment but for many merchants, outsourcing this central system is much less expensive.
Archive/rekeying – Destroying the key is a compliant and effective way to force an end-of-life on the data. But PCI 3.6.4 requires annual rekeying of the data as long as it still lives or is accessible. In our system it is 2 years. I’ve heard some merchants require up to 7 years. IMHO, this rekeying requirement in PCI adds more security problems than it solves. I understand what they are trying to address but there are much better ways to accomplish the same goal – but that’s another topic. But since this requirement exists, it must be addressed either by shortening the life or the data to under 12 months, rekeying the data or some other compensating control. Tokens (at least outsourced tokens) do not have this issue.
Tokenization costs vs. PKI costs – When I refer to costs, I am talking about merchant using our outsourced gateway solution. Assuming that there is a PKI outsourced gateway equivalent (which I’m not aware of), the cost difference is in the modifications required for the POS to handle the token or PKI encrypted data. As you noted further down, our token is alphanumeric and fits within 16 bytes, which just happens to be the length of most existing card numbers and the same length most POS applications have reserved to store CHD. On the other hand with PKI, I’m not sure if it is possible to fit the encrypted data in the same POS database size limitations.
Token format? – Our token is comprised of the last four digit of the card number followed by twelve bytes of random alpha data. In reality, the “random” data boils down to nothing more than a sequential number run through a big prime number calculation simply to produce pseudo-random looking results. Security wise, 2222idkdhjgeesqm followed by 2222japposidmdss is no more or less secure than if we returned 2222aaaaaaaaaaaa followed by 2222aaaaaaaaaaab. Like in my analogy, we think of a token as a case number that references CHD. The pseudo-random looking token is used to impress and make it look challenging to decipher. What I described here is our implementation of token assignment. Our public domain release of tokenization did not describe this level so other merchant and vendor implementations will differ.
Local token generation – Very good catch; many don’t catch this! During normal online conditions, our data center assigns the tokens and these are passed back to the POS. During offline conditions, our UTG (which I describe as a proprietary VPN end-point on steroids) has the ability to generate local tokens and store these tokens with the associated CHD in an offline database using PKI. Once online conditions are restored, the offline file is transmitted to our data center and the local file is deleted. The local offline storage file is using PKI but it’s transparent to the merchant and the POS (provided the POS already supports our API and tokenization).
Obtain token for settlement – With our API, the CHD is never returned back to the POS. Instead, the POS should use the token as the CHD. When the POS performs the settlement, they send us the token. Behind the scenes, we access the original CHD using the token and send it off to the bank or processor. When you design or compare tokenization solutions, this is a key point to consider. INHO, CHD should never be returned to the POS or any application you are trying to protect using tokenization. Doing so simply opens up a whole that can negate all the benefits of tokenization.
Encryption and Data pipe security (TLS) – As a rule of thumb, most all our encryption pipes use a hybrid model where we use PKI for the initial handshake and then a shared secret using a DUKPT like model (derived unique key per transaction). The PKI handshake is used to pass a dynamically assigned random key page for the DUKPK session.
Man-in-the-middle attack – We use various levels of authentication to prevent this which includes our own certificate signing, locking down access to specific IP addresses, locking down access to specific mac addresses, and more stuff that is beyond my expertise.
To everyone, again, I’m sorry if this sounds like a sales pitch; it’s not the intent. I’m arguing the advantages of tokenization vs. a PKI only solution for handling CHD. At this level the only way I can think to convey the advantages is to give details and for this I have to stick to what I know most intimately. Hopefully you can equate how Shift4 accomplishes tokenization to how to properly implement tokenization with or without Shift4 in the mix (obviously I’m hoping in the mix ;-).
May 22nd, 2008 at 12:27 am
Again, I appreciate your reply, and I’d like to say I’m impressed by your solution.
Regarding 3.6.4, it certainly does NOT say that you must re-encrypt the data. (We all know that’s a security loophole a mile wide.) It says “Periodic changing of keys — at least annually”, which means you must change *encryption* keys at least annually. By cycling a different public key through on a periodic basis, a PKI system is compliant. The encrypted data can remain safely encrypted with the old key for its lifetime. Merchants are merely prohibited from adding new data with the old key after one year. Of course, if you were encrypting the data with a secret key algorithm such as AES and used only one key for all encryptions and decryptions without benefit of a key identifier, you would be unable to change the encryption key without re-encrypting the data itself. That way lies madness.
And regarding encrypted CHD size, you’re correct that a PKI solution produces a larger data block — much larger, in fact. A two-phased encryption, such as PGP uses, requires the generation of a random session key used in a traditional symmetric key encryption of the data like 3DES or AES, plus the encryption of the session key via DH, RSA or other public key algorithm. The encrypted data can be encoded to fit in its original size, but the encrypted session key will be at least 1024 bits (128 bytes) long, and you’d be wise to use a 2048 bit (256 byte) key. In order to decrypt it, you’ll want to add a public key identifier so you can find the right decryption key. It easily amounts to over 300 bytes per account number for a very simple solution. And you’re absolutely correct in assuming that does not fit into existing retailer databases very well.
I’m glad you took the time to describe Shift4 in greater detail. As I mentioned before, without disclosure of the mechanisms there is no way to trust a simplistic description, and in the vacuum of facts I had made some incorrect assumptions. I feel much more comfortable about the Shift4 algorithm now.
As you’ve already figured out, I’m associated with a firm larger than a level 4 merchant, so I’m not looking for a job right now
We have already implemented a compliant PKI-based solution, so we’re not shopping for a different tokenizing system at this time. But I’ll keep this in the back of my mind. Thanks again!