Do you think we're going to get to more of a hybrid model?
In one aspect definitely. Our sense is that in the substitution model the separation of the mapping database from the application is so important. In the fundamental model you move the real value over to a tokenization service of some kind. That means you have to protect that value in transit as it goes from the point of capture over to the tokenization service. You can simply do that by transport level protection, but our sense of it is that it's one of those situations where you want to have multiple levels of protection on that data as it moves. In that regard, encrypting the data as part of the solution is extremely important. For us, what you get back inside the merchant environment is something that has no algorithmic, no mathematical, and no transformative relationships to the value that you sent to the tokenization server. That means all the kinds of attacks that relate to brute force transformation -- all of those kinds of threats are no longer possible. That for me is the big difference between a model like encryption, whether it's format preserving or expansive encryption and this kind of mapping-based model in which there is no transformation. Our sense is that for this problem at least, the model of substitution is hugely effective. One of the big pain points seems to be these legacy business analytical systems and databases. That's where format preserving encryption worked, because you were able to maintain the 16-digit credit card number with the encryption format. Can you do that with card-based tokens?
Absolutely. We built our own tokenization solution in two customer engagements. One was with Staples and the other was with a package shipping company. We began the discussion with them with the understanding that they needed to minimize the impact on their current application portfolio and the best way to do that was to be able to retain the same size and also the last four digits of the credit card numbers. As long as you did the mapping of the last four digits of the real value onto the token and kept the same 16-digit structure that in fact the token was as effective in that regard as format preserving encryption. In the First Data-TransArmor process, First Data is going to check the PAN against previously processed credit cards to see if a token had previously been assigned. That tells me that there is a file being stored with First Data that has both tokens and credit card numbers. If a cybercriminal got a hold of that file, wouldn't that constitute a major breach?
Absolutely. That mapping table is really the core of this architecture. It is hugely important that file be protected. The protections you want to put in place are exactly the kinds of things you put in place for key management. That mapping table contains sensitive information that needs to be well protected. By gathering that credit card information in one place you are enabled to put protections around it; that would be much more difficult than the information was scattered. You need to treat that table with the same level of layered defenses that you would use for key management. You have to apply appropriate identity management to that and do encryption of the individual data elements and do it at a very fine-grained level. Similarly you also want to pay attention to the infrastructure models both in physical and virtual environments. The other area that comes up is latency issues. For merchants it's important to get customers quickly through the payment process. Have we gotten to the point to where computer processing power has made this a non-issue?
That includes latency in terms of the network relationship and in terms of the tokenization operation. In this case I would fully expect that a much more significant issue is the bandwidth in the network connection. When we first looked at this with Staples, for example, where they had dial-up connections for some of the stores, they had been quite concerned early in the architecture design about whether that would result in a one or two second delay in the transaction. They found that was not the case. They were extremely pleased with the roll out there across an extremely diverse environment. There's also been a discussion about the issue of larger merchants using multiple payment processors. That would mean different kinds of tokenization solutions. Why aren't there any standards when it comes to tokenization?
There are two things happening around tokenization. One of them is the work we're doing inside the PCI DSS special interest group on tokenization. That's mostly focused on scoping and guidance around the implications if you are using this kind of substitution model. There's also work being done by the [American National Standards Institute]. Unfortunately that's been a much more difficult one to create the kind of clarity that I think needs to be around what tokenization means.In terms of APIs for example -- I think there's not been yet any significant development in that area. It is an area that we in RSA are interested in. It's taken a backseat at the moment to the scoping questions. I think as was true with key management. As we begin to see a number of providers who are using tokenization as a mechanism for protecting not just PCI DSS, but other classes of information as well, the development of standard APIs, so vendors won't be locked into a single payment processor and their infrastructure will also be very important. We haven't yet begun work there.
The development of standard APIs, so vendors won't be locked into a single payment processor and their infrastructure, will also be very important.
technical directorRSA, the security division of EMC Corp.
Retailers have a lot of legacy systems and seem to be slow to implement new technologies. Haven't the merchants that have moved forward, implemented some form of format preserving encryption to protect credit card data?
I think in fact there is a significant divergence in the market. For example, for us at RSA, the first time we implemented tokenization was at Staples where they had done initial architecture work starting in 2004. They had made the decision not to use an encryption model for the protection of the PCI track and number information, but to use the tokenization model instead. Tokenization in that case is defined by the substitution model rather than by the transformation model. There is a significant divergence in the industry … divergence between the models in which transformation of the original value is used to create whatever the related value is and those approaches in which no such transformation is involved. It's a way in which you simply map one value to another and use that mapped value as the token. I've been involved in the PCI DSS scoping committee working on tokenization and in that committee the fundamental issue has been how visible that distinction can and should be in the scoping guidance.