Superconductor

Tokenization of Credit Card Numbers and the CAP Theorem

Introduction

In the payment card industry there are a set of security standards and best practices that are defined by the Payment Card Industry Security Standards Council (PCI) with a goal of protecting card holder data. Entities such as brick-and-mortar merchants, e-commerce merchants, payment card processors, and acquirers are all required to follow the standards and best practices defined by PCI.

Protection of card holder data includes encryption and tokenization. In this article we shall focus on tokenization, in particular the concept of a card data vault and how the CAP theorem reduces to the choice of giving up consistency of the card data vault.

What is Tokenization?

The PCI DSS Tokenization Guidelines defines tokenization as:

Tokenization is a process by which the primary account number (PAN) is replaced with a surrogate value called a “token.”

De-tokenization is the reverse process of redeeming a token for its associated PAN value. The security of an individual token relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value.

There can be different implementations of a tokenization as described in the guidelines. One such approach is to define a card data vault that stores PANs and associated tokens.

On the surface it would appear that building such a system would be easy since the card vault can be implemented in a data store (either RDBMS or noSQL store) and the data stores schema could be simple, containing just the PAN, token and perhaps some timestamp information. There are plenty of companies that have attempted to build their own card vaults and many vendors offering commercial products. However we shall see later in this article that designing a card vault requires a distributed data store and a decision is needed on which compromises of the CAP Theorem your system is willing to accept.

The CAP Theorem

The CAP Theorem was initially observed by University of California, Berkeley computer scientist Eric Brewer in 2000 and later a proof was published by Seth Gilbert and Nancy Lynch. There are lots of good articles on the Internet on the CAP Theorem. In summary, the theorem states that for distributed data storage systems a system designer has to choose between two of the three following menu items:

• Consistency. In the card vault example this would imply that no matter which distributed tokenization service was used for tokenization or de-tokenization they would all return the exact same token for a given PAN. It would not be permissible, for example, to return two different tokens for a given PAN.
• Availability. The card vault is always available to service a request to tokenize or de-tokenize.
• Partition tolerance. This is perhaps the least understood of the three choices. In summary, for a distributed storage system the system can continue to operate even in the event of underlying data communications network failure, or hardware failure in a node.

Do I have a choice between C-A-P?

Let us now use the example of a Token Service Provider (TSP). Imagine the following use case for tokenization:

1. Customer Alice is checking out at the local supermarket using her credit card. The merchant, to reduce PCI scope, does not want to store any card holder data in their systems. The merchant has contracted with BobPay payment processor that also acts as a TSP.
2. Alice swipes her credit card, the transaction is sent (encrypted using end-to-end encryption) to BobPay, and in the authorization response a token representing the original PAN is returned to the merchant.
3. The merchant stores the token for later use, such as settlement, charge backs.

BobPay provides services to merchants throughout the USA, and as such has multiple data centers.

Partition Tolerance is not optional

There is a nice article by Henry Robinson that explains any distributed storage system will suffer network and hardware outages, therefore partition tolerance is not optional, after all that is probably the reason that BobPay has multiple datacenters across the USA.

Can Alice wait?

Going back to our example of Alice at the merchant’s checkout. If the BobPay’s tokenization server is unavailable, how long would Alice wait before walking out of the merchants store without purchasing? What about the other lanes and stores and BobPay’s other merchants? Clearly availability of the tokenization solution is critical to BobPay’s business. Availability of the card vault is a requirement.

Consistency on the chopping block

We are now down to one item left on the menu – consistency. We will have to compromise on consistency of the card vault. What does this mean for a card vault and for the merchant systems?

In the card vault it means that it is possible to have a single PAN represented by more than one token. For example consider the following where the card vault system is fully functional, including a connected network between two datacenters.

In this diagram the flow is as follows:

1. PAN is given to the card vault TS1 for tokenization
2. The card vault creates the random token
3. The PAN->token entry is replicated to the other site, TS2
4. The token is returned
5. A request for the same PAN on TS2…
6. …yields the same results

Compare this flow to the following diagram where the network has been partitioned due to network failure:

1. PAN is given to the card vault T1 for tokenization
2. The card vault creates the random token
3. Token is returned
4. Same PAN is presented to the card vault T2
5. A different token is generated…
6. ..and returned

We can see that to meet the availability requirement it must be possible to tokenize the PAN on TS2, even though a token mapping exists on TS1.

This implies that applications of the tokenization service must expect more than one token for a given PAN.

Minimizing the impact

There are some techniques that can minimize the impact of non-unique PAN-Token mappings as follows:

• Eventual consistency. The data store will recovery from the partition event and the data will eventually become consistent. The application consistency will require application logic. In our merchant example the merchant should accept a message in for the form: “Replace token₁ with token₂”.
• Minimize the impact and remove complexity. Let us consider the properties of a card vault. Day one the vault will be empty and then constantly grow in size (in theory the size is bounded by the number of possible PANs). If we can also assume that the PAN-token entry is immutable (which is a reasonable assumption) then optimizations that can be made. For example using modern data storage techniques such as Hadoop and some real-time computation such as Storm the system could reduce and isolate the consistency issue. There is a good blog post called How to beat the CAP theorem that explains how to use Hadoop and Storm that could be applied to the card vault.

What other choices exists if I want CAP?

If you want a tokenization card vault solution then Voltage Security has a scalable solution, but what if you want all of the three menu items: consistency, availability and partition tolerance for tokenization? The answer is obvious: don’t store state, and thus don’t use a card vault.

One can completely eliminate the need for card vault by using tokenization techniques that utilize format preserving encryption (FPE). No card vault means no CAP Theorem, and the tokenization service can provide CAP.

However a FPE mechanism of tokenization will require key management. If the underlying key management system stores keys in a distributed key store then the CAP Theorem applies to the key management system itself! Luckily the Voltage Key Management system is stateless and is thus not subject to the CAP Theorem.

Summary

We have seem that tokenization using card vaults, like any other distributed data store, falls prey to the CAP Theorem and the only viable option is to provide an eventually consistent solution, requiring application logic to resolve duplicate tokens for the same PAN. If you are looking for a card vault tokenization solution from a vendor and they tell you they have all three of consistency, availability and partition tolerance the solution will be too good to be true.

#voltagelive Voltage Customer Summit Video

Data-centric security for a data-centric world - #voltagelive 2011 in NYC

New innovation and emerging technology brings with it opportunities for streamlining costs, eliminating hurdles for end users and reducing risks to the business. However, implementing game changing solutions can be unique to your environment, policies and processes.

That's why I invite you to join Voltage Security at its first customer summit in New York City on November 9, 2011. The summit will focus on data-centric security and will feature top Voltage customers such as Amex, Wells Fargo, State Street and others, who will discuss how they implemented encryption projects for mail, data and payments. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently developing new analyses of how companies use encryption. The summit features customers talking to customers—at last count this includesAmerican Express, BJ's Wholesale Club, Citigroup, Deutsche Bank, Fidelity Investments, JPMorgan Chase, UBS, State Street Bank andWells Fargo. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices. If you're interested in attending, please visit www.voltage.com/live.

The theme is 'Data-centric Security for a Data-centric World,' it's an area of huge attention. Data is the lifeblood of industry, commerce and leisure, every business and every transaction. That's why protecting it is such a serious and difficult responsibility. 

Here's a quick scan of the Hot Topics we have on tap at Voltage Security Live 2011:

Cloud Data Security Data-centric Encryption Ecommerce Security

Email Encryption Mobile Data Security Payment Security

There's no question that every company continues to face a long serious of challenges related to these topics. The conference is designed to tackle specific issues and help formulate achievable solutions. The areas to be covered include:

• How to fund and integrate a data-centric strategy into your overall security program
• Best practices for data-centric encryption based on real-world implementation at a Fortune 50 Bank
• How to roll out encryption projects successfully across the organization and end-user community
• Successful phases for fast and non-disruptive implementation—what you need to do before during and after an implementation
• Elements of key management architecture and design
• The role of cloud and mobile data-centric security

Voltage Security Live 2011 will bring together the brightest minds in our field, all with considerable experience. There will be representatives from teams responsible for implementation, as well as enterprise and security architects looking for, and developing, best practices for data-centric encryption. 

The sessions will cover customer project case studies addressing issues such as how to maximize end-user adoption for your B2C implementations and implementing data-centric encryption projects, while the Customer Track focuses on panel discussions and presentations on topics such as protecting outsourced data, eDiscovery and Archiving and securing application emails. There's also an Architecture Track, featuring panel discussions and presentations on topics such as key management architecture, security policy, enterprise applications and the web services API and scalable design considerations. And there's the Security Panel, with a discussion and general Q&A featuring leaders from the security community—Gartner Security Analyst, Encryption Architects, QSAs. 

There's going to be a broad cross-section of security specialists attending, but some executives will find it particularly enlightening: CXOs and security leaders responsible for security strategy and programs; VPs/Directors responsible for security implementation; and architects responsible for security and application and enterprise architecture. If you have one of these roles, we think this conference is exactly right for you. 

We know there are constant demands on your time - we hope to see you there.

Register at www.voltage.com/live

Voltage Customer Summit #VoltageLive - Only 23 Spaces left

 *** Only 23 spaces left ***

Voltage Security invites you to "Voltage Security Live 2011" at Bridgewaters in New York City on November 9, 2011. This customer summit will focus on data-centric security and will feature several leading Voltage customers, such as American Express, Wells Fargo, State Street and others, who will discuss how they have implemented encryption projects for email encryption, data-centric encryption and end-to-end payment encryption. Also presenting will be Eric Ouellet, research vice president with Gartner Group, who is currently working on a new analysis of how companies use encryption. The goal of the summit is to enable Voltage customers to network with each other and pick up valuable best practices.

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now at www.voltage.com/live

Join Voltage customers including: ADP, American Express, Bank of America, AT&T, Citigroup, Deloitte, Deutsche Bank, Elavon, Fidelity Investments, Heartland, JPMorgan Chase, McGraw-Hill, UBS and Wells Fargo. 
.
Highlights of the agenda include:

• CxOs Panel – Business dynamics for data-centric encryption security – How to get your security project funded
• Key Note – Eric Ouellet, Vice President Research, Gartner Group                      
• How to maximize customer adoption – Kim Mroczkowski, Wells Fargo
• 4. How to structure a data-centric encryption project – Emily Mossberg, Deloitte
• 5. “Birds of a Feather” Networking lunch
• 6. Tracks: Customer and Best Practices – American Express, State Street, Thales, PwC, Coalfire 
• 7. Security Leadership Panel – Gartner Group, State Street, American Express, Wells Fargo

Stop Press: Thanks to our sponsors - Coalfire, OpenPath, Teradata and Thales, we are able to offer registration for eligible particpants at no cost.  Register now atwww.voltage.com/live 

 

Room for growth in the payments industry

There certainly looks like there's plenty of room for growth in the payments industry. According to the presentation from the Mastercard 2011 Investment Communty Meeting Presentation (PDF), 85 percent of payments transactions are still done by cash or check. That tells me that there's still lots of room for growth in other types of payments technologies.

Multifactor authentication and Patco Construction v. People's United Bank

There was an interesting ruling (PDF) by the United States District Court District of Maine in Patco Construction v. People’s United Banka few days ago. It seems that back in 2009, someone at Patco Construction managed to install Zeus malware on the computer that Patco used to initiate electronic funds transfers. This let hackers capture the answers to the challenge/response questions that Patco used to authenticate to their on-line banking system. The hackers then used this information to complete about $345,000 in fraudulent transactions. Patco sued to recover the lost money, claiming that the bank’s security measures were not "commercially reasonable." The court disagreed, and Patco’s suit to recover the money lost in the fraudulent transactions was dismissed.

What I find interesting about this particular ruling is part of why the bank’s security measures were found to be commercially reasonable. FFIEC’s guidance "Authentication in an Internet Banking Environment" (PDF) recommends multifactor authentication for financial transactions, but exactly what that means isn’t as clear as you might expect it to be. In this particular case, the bank claimed that in addition to a username and password plus the answers to challenge/response questions, that

its security procedures also employed "something the user has": device identification information specific to the client’s personal computer and its use of the Bank’s application, and "something the user is": taking into account user behavior.

But when the hackers compromised the username and password plus the challenge/response answers, they didn’t compromise these other factors. They didn’t get the ability to spoof device authentication information and they didn’t get the ability to spoof the behavior of the legitimate user. But that’s apparently OK. As the bank pointed out, in their legal arguments, Patco

attempt[ed] to manufacture an additional "requirement" for multifactor authentication, unsupported in the FFIEC guidance or in case law, by arguing that the system must respond in a certain way to each of the factors, for example, by blocking a transaction if one of the factors fails.

So it looks like the bank claimed, and that the court agreed, that it’s OK for some of the factors in a multifactor authentication to fail yet for the overall authentication to succeed. I haven’t carefully considered all of the implications of that, but my first reaction is that this is probably just an oversight on the part of the people who wrote the FFIEC’s guidance, and it’s something that the next version should probably address.

It also looks like people writing other standards should also think about this and consider explicitly requiring success from more than one of the factors in multifactor authentication for an authentication attempt to succeed. Maybe that’s something that the ASC X9F4 working group should consider, for example.

Per capita credit card charge-offs

Last week I noted how the current per capita spending by US cardholders is about $10,500. According to the Federal Reserve, the current charge-off rate for credit cards is about 7.22 percent. That means that there's probably about $750 in charge-offs per capita in the US.

That's a lot. But that's down quite a bit from the past couple of years. Back then, the charge-off rates were over 10 percent, which would have given over $1,000 in charge-offs per capita.

2010 spending by US cardholders

According to The Nilson Report, the spending by US cardholders (credit, debit, etc.) was $3.258 trillion in 2010. That's a lot of purchases. The population of the US is about 309 million right now, so that comes to about $10,500 per capita, which is still a lot of purchases.

China UnionPay and security standards

A recent copy of The Nilson Report noted that the business of payment cards, the global market share of China UnionPay (4.03%) is greater than the global market share of American Express (3.91%).

Amex is already involved in setting the security standards that govern the payments industry. Along with Discover, JCB, MasterCard, and Visa they're part of the PCI SSC, for example. But I haven't met anyone from UnionPay at any of the standards meetings that I go to. I haven't even seen their name on any list of members. But now that UnionPay is getting fairly big, maybe we'll see them more involved in setting security standards for the payments industry in the future.

What type of plastic is used?

According to The Nilson Report, the fraction of purchases (by volume) that are made using prepaid cards, debit cards or credit cards has changed a bit in the past 10 years.

Here's how things looked back in 2000.

 
And here's how things looked in 2010. It looks like debit cards have been the big winner.

 

A webinar on EMV

it looks like our marketing guys are having another webinar. This one's Understanding EMV – Future Directions for the U.S. Market, and here's a quick description of what it will cover:

Merchants, issuers and acquirers need to understand the elements that comprise EMV, how EMV adoption may impact PCI compliance initiatives and what additional security needs to be implemented to ensure comprehensive data protection from Point-of-Sale (POS) and Card Not Present (CNP) to back-end Merchant IT systems.

In this webcast you will learn:

Why EMV is gaining more awareness in the United States as the standard for securing interactions from the card to the payment terminal

What threats EMV is designed to mitigate and how EMV affects PCI compliance

Why organizations need to address the complete security of cardholder data across their back-end IT systems

This webinar will be October 12, 2010 at 11 am Pacific/2 pm Eastern and will last 60 minutes.

If that sounds interesting, you can register for this webinar here.

And then there were none

One trend in the past few years is the elimination of printed paper bills, those things that used to arrive in your mail box every month. The San Jose Water Company was one of the last holdouts in this, and even they've finally made the move to electronic bills, so that I now write a total of ZERO checks per month.

This move to electronic bills has probably had some negative affects for some people, however. I remember talking to a person in the finance department of Cincinnati Gas and Electric several years ago who told me about how they had people whose job it was to just take care of the checks that were mailed to the wrong place. Apparently lots of people would accidentally mail the check for their utility bill to the phone company, for example, and each of the companies that sent out lots of monthly bills had people in their finance department whose job it was to correct this error.

With the increasing use of electronic bills, I'd guess that lots of those jobs have disappeared.

Charge-off rates for credit card loans

A reader recently commented that he'd heard that the charge-off rates (the fraction that banks write off as bad debt) for credit card loans are typically around 4 percent, but hadn't seen a reference to that fact. Here’s a graph of the data from the Federal Reserve that shows the charge-off rates on credit card loans since 1985. Until recently, the rate hovered around 4 percent. It’s jumped to roughly 10 percent in the past year or two, but I’d expect it to go back down to about 4 percent again in the next year or two.

More interesting fraud data from the Kansas City Fed

As I mentioned before, "The Changing Nature of U.S. Card Payment Fraud: Industry and Public Policy Options" by Richard J. Sullivan, has some interesting data about the nature of fraud. Here's what's in Table 2 in this document.

Card issuers	billions	Share of total loss
PIN debit	$0.028
Signature debit	$0.337
Credit cards	$1.240
ATM withdrawals	$0.397
Total issuer losses	$2.002	59%
Merchants
POS	$0.828
Internet, mail order, and telephone	$0.568
Total merchant losses	$1.396	41%
Total losses	$3.718

I noticed a few interesting things is this data:

• Banks actually suffer more from card payments fraud than merchants do - roughly 50 percent more
• For banks, ATM fraud is a almost one-third of credit card fraud
• Merchants actually have more POS losses than CNP losses

I wouldn't have expected any of those to be true.

Mercator's thoughts on EMV

In a previous post, I mentioned that when the UK rolled out EMV how card-not-present (CNP) fraud increased so much that the total amount of fraud actually increased instead of decreasing. Apparently the increase in CNP fraud isn’t limited to just the UK. Here’s what the Mercator Group said in their recent report “Encryption, Tokenization and the Top Tier Merchant: A Progress Report on PCI, Deployment and the Cost of Payment Security:”

CNP fraud rates in EMV countries have risen dramatically because of EMV’s effective protection against counterfeit cards. EMV does not address card not present (CNP) risk; it is one layer of security but hardly a blanket solution (there’s no such thing).

The summary of this report also proposes an interesting reality check on EMV:

There is plenty of misinformation swirling around tokenization, encryption and EMV. Some believe that all problems would be solved if only EMV were used in the US. If only that were true. Card number security requires layered defenses and that means using multiple techniques to limit counterfeit credentials (EMV) and to perform the Reverse Rumpelstiltskin of turning our digital gold into straw bits (encryption and tokenization).

There’s lots of other interesting information in this report, and it’s probably worth tracking down a copy if you’re interested in the business of protecting credit card information at large merchants.

Explaining the silence here

It looks like another big credit card processor has signed up to use Voltage's encryption technologies. This time it's Elavon, which means that three of the top five processors (Heartland, Fifth Third and Elavon) are now Voltage customers. Four of the top six POS vendors (Hypercom, Exadigm, UIC, XAC) are also.

This might explain why you don't actually see our sales guys in the office much. When they're not around it's much quieter and easier for the rest of us to work, so I certainly hope that their success in the payments industry continues.

PCI tokenization guidance could benefit payment processors

Interesting news article by industry reporter Rob Westervelt who has been following business and technology trends in the payments sector:

	PCI tokenization guidance could benefit payment processors By Robert Westervelt, News Editor 27 May 2010 | SearchSecurity.com