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 

 

Strong cryptography and the PCI DSS

The PCI DSS requires that credit card numbers are protected with "strong cryptography" or something equivalent. That's usually interpreted as meaning encryption that provides the equivalent of 112 bits of strength, like you get with three-key Triple-DES or an RSA key of 2,048 bits. But no way of protecting credit card numbers will get close to that much security. Here's why.

The strength of a way of protecting sensitive data is as strong as the easiest way for an attacker to recover the sensitive data. If the easiest way for him to do this involves cracking an encryption key that provides 112 bits of security, that's how much protection the sensitive data has. If there's an easier way, say one that takes only the effort equivalent to cracking an 80-bit key, then the data only has 80 bits of security. 

And that's exactly what we have with credit card numbers.

There are only 10¹⁵ possibilities for a typical 16-digit credit card number because the final digit is a checksum that's determined by the previous 15 digits. That means that an adversary can guess any credit card number in no more than 10¹⁵ attempts.

That's roughly the amount of guesses needed to crack a 50-bit cryptographic key (10¹⁵ is about 2^49.8), so that it's essentially impossible to get more that 50 bits of security for a 16-digit credit card number. It also means that worrying about "strong encryption" really isn't worth it. A 112-bit key won't provide any more security than a 50-bit key does because they're both equally hard to defeat.

There are lots of people in the payments industry who spend lots of time worrying about whether or not particular techniques qualify as "strong cryptography." It certainly looks like they ought to stop worrying about this particular issue and move on to more useful things.

The PCI SSC Tokenization Guidelines

The PCI SSC finally released their long-awaited Information Supplement: PCI DSS Tokenization Guidelines (PDF) last week. If what you read on the Internet is true, almost nobody's very happy about this document. But that's probably because the people who tend to comment on things on the Internet are typically upset, leading to lots of negative comments and very few positive ones. This particular document actually seems to be fairly well done. If there's any reason to complain about it, it might be because the document doens't quite seem to be aimed at its target audience.

As the document itself says,

This Information Supplement is intended for merchants that store, process, or transmit cardholder data and are seeking guidance on how implementing a tokenization solution may impact the scope of their compliance efforts with the (PCI DSS). Other payment industry stakeholders including payment processors, acquirers, service providers, assessors, and solution vendors may also find the information in this document useful.

But the content of the document really seems more like it's written at a level that QSAs and other specialists in protecting cardholder data will understand. It's probably a bit over the heads of most merchants.

But aside from that minor point, this document seems fairly good. The PCI SSC seemed to do a particularly good job of eliminating most of the vendor bias that crept into the earlier versions - the ones before the PCI SSC took over the operation of the working group that created this document. (Some of the negative comments that I've read essentially complain that a particular vendors definition of something or interpretation of something isn't reflected in this document.)

If the PCI SSC's future documents are as good as this one, it will probably make PCI DSS compliance much easier for merchants to understand, and that's probably a good thing.

Visualizing the PCI DSS

We've all spent many hours reading and trying to understand the PCI DSS. (Well, at least some of us have.) Wouldn't it be easier to just be able to look at a picture and get a rough idea of what it says? To help do just that I created the following word cloud of the PCI DSS v2.0 using Wordle. It doesn't contain quite as much information, but it's certainly quicker and easier to read.

 
 

The PCI DSS Virtualization Guidelines

The PCI Security Standards Council just released their Information Supplement: PCI DSS Virtualization Guidelines (PDF). This document describes how

There are four simple principles associated with the use of virtualization in cardholder data environments:

a. If virtualization technologies are used in a cardholder data environment, PCI DSS requirements apply to those virtualization technologies.

b. Virtualization technology introduces new risks that may not be relevant to other technologies, and that must be assessed when adopting virtualization in cardholder data environments.

c. Implementations of virtual technologies can vary greatly, and entities will need to perform a thorough discovery to identify and document the unique characteristics of their particular virtualized implementation, including all interactions with payment transaction processes and payment card data.

d. There is no one-size-fits-all method or solution to configure virtualized environments to meet PCI DSS requirements. Specific controls and procedures will vary for each environment, according to how virtualization is used and implemented.

It also lists the risks associated with using virtualization. Here's the PCI SSC's list:

Vulnerabilities in the Physical Environment Apply in a Virtual Environment

Hypervisor Creates New Attack Surface

Increased Complexity of Virtualized Systems and Networks

More Than One Function per Physical System

Mixing VMs of Different Trust Levels

Lack of Separation of Duties

Dormant Virtual Machines

VM Images and Snapshots

Immaturity of Monitoring Solutions

Information Leakage between Virtual Network Segments

Information Leakage between Virtual Components

For more about how virtualization affects complying with the PCI DSS, check out the document itself. It's actually fairly well written and understandable. It does assume that you understand what virtualization is and how it works, so if you're not comfortable with those concepts, you should probably be prepared to do a little background reading before looking at this particular document.

What Dimitriy Simonoffs v. Expedia tells us about printed receipts

There's been some discussion recently about exactly what a recent court ruling means about merchants' ability to send credit card numbers over email. Like in most of these cases, lots of what's being said isn't supported by the facts. Here's what really happened and what it probably means.

Dimitriy Simonoffs received an email receipt from travel web site Expedia that contained the expiration date of the credit card that he used for a purchase. Believing that this violated the Fair and Accurate Credit Transactions Act of 2003 (FACTA) (PDF), he filed a suit against Expedia. This suit eventually made its way to the United States Court of Appeals for the Ninth Circuit, which issued an Opinion on Simonoffs v. Expedia on May 24, 2011. Simonoffs claimed that FACTA's provision that

no person that accepts credit cards or debit cards for the transaction of business shall print more than the last 5 digits of the card number or the expiration date upon any receipt provided to the cardholder at the point of the sale or transaction. 

applied to email receipts as well as physical receipts. The court disagreed, finding that the wording of FACTA clearly does not apply to electronic receipts:

In enacting FACTA, Congress did not use language that would have clearly extended FACTA’s protection to electronically mailed receipts. For example, Congress could have applied FACTA to "electronically printed or transmitted" receipts, to "electronically printable" receipts, or to "electronically displayed" receipts. See Simonoff v. Kaplan, Inc., No. 10 Civ. 2923, 2010 WL 4823597, at *7 (S.D.N.Y. Nov. 29. 2010). Congress, however, chose not to do so, even though it has referred to digital methods of communication and commerce in numerous other statutes. See Shlahtichman, 615 F.3d at 801-02 (canvassing various other federal statutes that use terms such as "Internet," "Internet websites," "electronic mail," and "online service," among others). We can’t fill in the blanks with words that Congress didn’t supply.

In other words, it looks like Congress probably wasn't very careful when they wrote FACTA, and this is reflected in the fact that the wording that they used omitted coverage of electronic receipts even though other laws have addressed them.

That seems fairly straightforward.

Does this mean that merchants can't print credit card numbers but are now free to send credit card numbers over email?

No. Not even close.

The PCI DSS clearly says that that's not allowed. So even if there's an oversight in the wording of FACTA that makes it legal, merchants still can't do this. So if anyone tells you that Simonoffs v. Expedia means that merchants are now free to send credit numbers over email, they probably either haven't thought about it very carefully or are hoping to get their 15 minutes of fame by misrepresenting the facts.

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.

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.

PCI compliance after a breach - another point of view

Here's another way to look at the data in Verizon's 2011 Data Breach Investigations Report (PDF) about what fraction of their customers were found to be compliant with the requirements of the PCI DSS after a breach had occurred. I'm not sure which graph is more useful - this one or the one in yesterday's post. They each seem to tell a different story, and it's not clear to me which one is better. As in the first graph, the horizontal axis is the PCI DSS requirement and the vertical axis is the percentage of businesses found to be compliant after a breach.

 

PCI compliance after a breach

Verizon's recent 2011 Data Breach Investigations Report (PDF) has some interesting information about what fraction of their customers were found to be compliant with the requirements of the PCI DSS after a breach had occurred. Here's a graph of what they found. The number on the horizontal axis is the number of the PCI DSS requirement. This makes it fairly easy to see trends, although it's probably not worth calling changes over just a few years a trend.

 

Notes from the 2011 Key Management Summit - the rest of the first day

After the keynote talks, there were other talks on the first day of the 2011 Key Management Summit from which I learned an interesting thing or two. In particular:

Anthony Stieber, who works for, but does not represent a large bank, talked about how it's actually cheaper to keep sensitive data around than to destroy it. That's something that I hadn't heard before, and I'd be interested in hearing more details of that claim in the future.

He also talked about how common it is to use the current time as a seed for a pseudo-random number generator. The output of a PRNG is only as good as the random seed that's used to initialize it, and it's apparently very common for people to use the extremely low entropy current time for this.

Elaine Barker of NIST talked about the move to 112 bits of strength that NIST is now requiring. The people at this meeting were probably the wrong audience for this talk. Everyone there knew about this requirement.

But there are still people out there that don't know about this yet. If you're one of them, read NIST's SP 800-131A, (PDF) "Transitions: Recommendation for Transitioning and Use of Crypographic Algorithms and Key Lengths" as soon as you can.

Ramon Krikken of the Burton Group talked about how people are still worrying about how to encrypt sensitive data and haven't yet tried to solve the harder problem of managing the keys that they'll need to encrypt that data. He also expects that people will be surprised by how hard key management is when they eventually try to do it.

He also talked about how tokenization is actually a form of encryption, despite the marketing spin from tokenization vendors that might try to convince you otherwise. He also talked about how it's probably possible to model the security of tokenization systems using the existing framework that we have for encryption schemes. A tokenization server certainly looks like a random oracle, doesn't it?

He also mentioned how it seems that vendors are calling tokenization "tokenization" instead of "encryption" to convince their customers that by using their technology they will avoid having to comply with the parts of the PCI DSS that require strong key management to support any encryption that's used. It certainly sounded like the PCI SSC people ought to talk to Ramon about this.  

Ramon also mentioned how it may end up being the case that so-called silos of key management may not actually end up being a bad idea. If this is true, that may make it much easier for the people working on the KMIP standard. After all, if you really don't need a general key management protocol that works absolutely everywhere, you can just focus your attention on the areas where there's actually a pressing need for an interoperable key management protocol. Like in storage, for example.

Chris Kostick of Ernst & Young talked about you can use your auditors to help you create a sustainable key management program. He recommended that you don't audit encryption, but audit key management instead. He also mentioned that he's often asked how to tell if data is actually encrypted.

If an encryption scheme is IND-CPA secure, for example, then ciphertext is indistinguisable from random bits. Because of this, the very definition of IND-CPA security means that you really can't tell if data is really encrypted because you can't tell if a blob of bits is a ciphertext or just random values. You may be able to look at the format of the data, but just because something is formatted as a PKCS#7 blob doesn't mean that it actually contains ciphertext. Apparently Chris spends a lot of time explaining this to his clients.

PCI DSS rocks

Just in case the results from the sucks/rocks web site don't convince you, here's more proof that the PCI DSS rocks:

Why protecting payments information can be hard

Protecting payments information can be trickier than it might first seem, and dealing with fleet cards, credit cards that are tailored to the needs of businesses that run large fleets of vehicles, is a good example of this.

Many people have probably been prompted for their ZIP code when they buy gas for their car. Users of fleet cards are often asked for more information like their odometer reading, a trip ID number, a vehicle number or a driver number. This information can then be used to create reports for the fleets, like how many miles per gallon their vehicles are getting, etc.

The types of prompts that users of fleet cards get is defined by information that’s in the magnetic stripe of the card, and this makes handling such information a bit tricky. In particular, it means that you can’t just encrypt all of the data from a card at the pump because some of that data needs to be available to define which prompts users of fleet cards get.

So this is a case where the usual approaches don't work - if you keep the first six digits and the last four digits unencrypted, as is often done with credit card numbers, that's still not enough to keep the information available that's needed to handle fleet cards. We definitely need another way to handle fleet cards, but standards groups seem to still be arguing over exactly how to do it.

What the Internet thinks about PCI DSS

People grumble about the PCI DSS for lots of reasons. Some because it's too lax, others because it's too strict. What do people overall think about the PCI DSS?

Apparently most people like it. At least that's what the sucks/rocks web site tells us, which gives the PCI DSS a 9.1 out of a possible 10.

DHS on PCI

The guidance on what's now being called point-to-point encryption that was recently reclesed by the PCI SSC was actually mentioned in a recent edition of the DHS's Daily Open Source Infrastructure Report. The DHS has a spin on this document that I hadn't seen before. Here's how they describe it:

During the past several years, some vendors have pitched end-to-end encryption as a way to eliminate the need to encrypt or tokenize database data for the purpose of PCI compliance.

I don't think that any vendors have pitched encryption as a way to eliminate the need to encrypt data. Maybe the author of the DHS report just wasn't being clear about what he meant.

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.

What an error on storefrontbacktalk.com tells us

On Storefrontbacktalk.com, QSA Walt Conway talks about why encrypting short fields, like the expiration date of a credit card, can let an adversary decrypt your entire database. His conclusion is just plain wrong, but his article is actually very useful in other ways, because it may give us some insight into what the industry really needs.

First, let's see why Walt's conclusion is wrong.

If you encrypt a small field with non-randomized encryption, it may be possible for an adversary to carry out a chosen-plaintext attack. To do this he builds a table of all possible plain-cipher pairs and then uses that table to decrypt ciphertexts that he sees. But just because an adversary can do a chosen-plaintext attack does not mean that they can do a key recovery attack. That's typically much harder.

Building a table of all possible expiration dates is very feasible. Trying to recover a key that's used to encrypt all of those expiration dates isn't. This means that the fundamental premise of Walt's article is totally wrong.

That’s not surprising, however, because encryption is a tricky subject that’s often inaccessible to non-specialists. If we look at exactly what it means for encryption to be secure we see a good example of this.

There are actually several definitions of security for encryption, and each of these formalize what it means to be secure against the different types attacks that an adversary might try. One of the most common of these is IND-CPA security, which provides a careful definition of how hard it is for an adversary to carry out a chosen-plaintext attack.

The precise definition of IND-CPA security is fairly incomprehensible to non-specialists, so you can’t really expect them to spend the time and effort to understand it. If you’re not a crypto specialist, look at the Wikipedia article on IND-CPA security and see if its definition makes sense to you.

There’s another notion of the security of encryption that’s called “perfect secrecy,” and that’s really the security model that tokenization systems try to attain. This definition is also fairly incomprehensible to non-specialists, so even though tokenization systems violate the assumptions of the security model that they’re trying to meet, that’s not clear to most people.

On the other hand, there's a definite need for careful and precise definitions of what it means for encryption to be secure. These definitions are what you use when you prove that a cryptographic scheme is secure, and without these careful definitions, these proofs really aren't possible. The unfortunate side effect, however, is that things really get a bit too complicated for most people to understand.

In any event, if the subtleties of encryption and its security aren’t clear to a QSA, what that’s probably telling us is that there’s a need for some way for them to get complicated concepts explained to them in an easy-to-understand way. Maybe some sort of industry forum in which QSAs and others can ask experts about these things in a way that won’t make them feel foolish would be good for this.

I’ve found that having a few beers with the sales people selling crypto products is a fairly effective way to do give them a chance to ask questions about exactly how their technology works and why it’s secure, but that approach probably doesn’t scale very well. Maybe that industry forum would be a better approach.

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

What were they thinking?

In a previous post, I noted a new social networking site called Blippy that basically lets you see what your friends are buying. Maybe if you're too young to remember the dot-com era, that sounds like a perfectly reasonable thing to do. To me it just sounds like a huge privacy problem just waiting to happen.

According the what's posted on Blippy's web site, the problems have already started. In particular, it looks like Blippy incorrectly considered raw transaction data to be harmless at one point, and some of it ended up the HTML on some of their web pages.

Yikes!

Blippy has a five-step plan for making sure that this doesn't happen again:

1. Hire a Chief Security Officer and associated staff that will focus solely on issues relating to information security.
2. Have regular 3rd-party infrastructure & application security audits.
3. Continue to invest in systems to aggressively filter out sensitive information.
4. Control caching of information in search engines.
5. Create a security and privacy center that contains information about what we are doing to protect you.

These steps look like a good move in the right direction, but why weren't these done in the first place? And with all the news about PCI DSS these days, who could possibly have thought that credit card transaction data wasn't sensitive and needed to be protected?

Data Masking: Runtime Data Aliasing

I just read an interesting Burton Group report Data Masking: Runtime Data Aliasing. Here's a high-level summary of the report's findings:

Bottom Line: Enterprises should increase their focus on developing an information-centric security strategy. Data aliasing can be used to reduce the amount of confidential data processed and the number of locations it's stored. Runtime data aliasing is the reversible replacement of confidential data with similarly formatted surrogates. Data can be aliased using format-preserving encryption or (pseudo) random replacement using a lookup database. Data modeling and architectural concerns drive the design and implementation of the enterprise data aliasing solution. Data aliasing can complement or replace traditional application- and database-level encryption used or considered by the enterprise.

This report does an excellent job of comparing and contrasting the different ways (suppression, redaction, aliasing and anonymization) to do data masking. Here's how this report summarizes these techniques:

Data masking method	Security and privacy properties	Data Management Properties
Suppression	Completely removing a set of data items to protect it from disclosure, as well as many privacy attacks, although some privacy attacks may make use of relationships with or in the unsuppressed items.	Alters the semantic value of the data by making data values inaccessible to applications.
Redaction	Irreversibly blocking part or all of a data item to protect a data item from full or partial disclosure, but which—although it often destroys relationships to other data—does not necessarily protect data from all privacy attacks.	Offers better context preservation than suppression but the semantic value of the remaining text may be incorrect or misleading.
Aliasing (pseudonymization)	Reversibly transforming part or all of a data item to protect a data item from full or partial disclosure, but which is not designed to protect data from all privacy attacks (e.g., inference attacks) because data relationships may be maintained.	Offers better context preservation than suppression but the semantic value of the remaining text may be incorrect or misleading.
Anonymization	Manipulating data to maintain desired information properties, using a combination of methods that is designed to create an irreversible transform resistant to disclosure and privacy attacks.	Best for semantic behavior preservation and certain statistical behavioral measures although the resultant data may be unsuitable for testing application logic.

This is the first time that I've seen a careful description of the different ways to mask sensitive data. There's more anaylsis of the strengths and weaknesses of each of the four approaches to data masking in this report. It looks like you can't buy a copy of this report from the Burton Group's web site - you might only be able to get a copy if you subscribe to their service. I hope that there are other ways for people to get copies of this report. It's definitely worth reading.

You can also contact the author of the report, Ramon Krikken (ramonkrikken on Twitter) if you have more questions about this report.  

Jack Bauer Day - Spurring Innovation

“I know what it's like to feel like it's never going to end.” – Jack Bauer

One of the challenges which face many world-class engineering organizations is how to maintain an atmosphere of innovation while still delivering on customer commitments and scheduled releases. During the early stages of a start up innovation is rampant; there are typically no customers to worry about, no backward compatibility issues and no upgrade paths to test.

As a company matures I have seen many engineering teams stagnate, innovation slows down, and morale suffers. As a VP of Engineering I spend time on the lookout for the warning signs, at Voltage we are blessed with a strong highly motivated team.

Recently within the Voltage engineering team we held our first “Jack Bauer Day.” 24 hours of the engineering team doing anything they wanted to do. From 9 am in the morning of February 2^nd (2/4 for all us in the USA) until 9 am in the morning of February 3^rd the team had free rein with very little direction. The one condition: you had to present what you worked on to the rest of the team.

It was fascinating to watch how ad hoc teams formed; perhaps one of the most interesting was a team of three engineers who took on the task of developing Format Preserving Encryption on regular expressions as described by Bellare, Ristenpart, Rogaway and Stegers in their Format-Preserving Encryption paper.

Within the allocated time period the team was able to demonstrate features such as:

Given a regular expression R describing a regular language and a plaintext p which matches R, then p can be encrypted to a ciphertext c which also matches R and has the same length as p, and c can be decrypted back to p. For example:

Plaintext: jobs@voltage.com

Ciphertext: 3y90zagb@2GMK.com

Decrypted ciphertext: jobs@voltage.com

The team then expanded the initial implementation with some different length encryption. Given regular expressions R1 and R2 (each describing a regular language, with certain restrictions on R2) and a plaintext p which matches R1, then p can be encrypted to a ciphertext c which matches R2 (with varying options for the length of c), and c can be decrypted back to p.

For example:

Plaintext: 4005 Miranda Ave, Palo Alto, CA, 94043

Ciphertext: 8 Bauzvvbuwg Dr, Szptny Oqo, AZ, 25601

It never ceases to amaze me what a small team of focused engineers can achieve if left alone.

Was Jack Bauer day a success? Yes absolutely. We will be holding them on a regular basis.

Acknowledgments: Portions of this post was taken from team rugby’s write up of their Jack Bauer day.

Tuesday at the RSA Conference - Bah-weep-graaaaagnah wheep ni ni bong

(Dozens of menacing SHARKTICONS appear in front of KUP and HOT ROD.)

KUP: Don't act hostile. I'll use the universal greeting.

HOT ROD: Universal greeting?

KUP: Watch. I'll have them eating out of my hand.

(KUP holds out his hands to show that he's unarmed and then addresses the SHARKTICONS.)

KUP: Bah-weep-graaaaagnah wheep ni ni bong.

HOT ROD: (puzzled) Bah-weep-graaaaagnah wheep ni ni bong?

SHARKTICONS: Bah-weep-graaaaagnah wheep ni ni bong.

KUP: See, the universal greeting works every time.

Transformers: The Movie, 1986

Many of the vendors at this year's RSA Conference seem to have adopted the idea of a universal greeting. Maybe they got this idea from Transformers: The Movie. Maybe they didn't, but if they didn't, it sure was hard to tell today.

The universal greeting that many of the vendors at this year's conference seem to have decided upon is "You'll never be PCI compliant without my product." Apparently they tired of the previous universal greetings "You'll never be HIPAA compliant without my product" and "You'll never be SOX compliant without my product."

In a few cases, the vendors could actually give a reasonable explanation of exactly what parts of the PCI DSS their products were designed to help customers address, but in even more cases they clearly hadn't really given this much thought. Instead, they seemed to be relying on the fear, uncertainty and doubt that the PCI DSS seems to have caused to get potential customers interested in their products.

I doubt that this is going to be a successful strategy. It certainly didn't work for the previous universal greetings, and I doubt that it will work this time, either.

On the other hand, I was happy to see that Voltage's partners who were exhibiting at the show didn't seem to have this problem at all. I turned my badge backwards to that they couldn't see that I was from Voltage and asked some of them a few questions about how their technology worked and exactly how it could help someone reach PCI compliance, and they all seemed to understand exactly what was required by the PCI DSS and how their technologies helped their customers comply with the PCI DSS. 

Maybe this was because our business development team is fairly selective about who they partner with. Maybe there's some other reason. I don't know for sure, but I do know that after hearing this year's universal greeting over and over again, it was a pleasant change of pace to actually talk to people who seemed to actually understand their customers' problems and how to solve them.

Looking up BINs

Even though a typical credit card number has 16 digits, not all of these represent a user's account number. The first digit is the major industry identifier (MII). An MII of 3 indicates travel and entertaiment, like an American Express card or Diner's Club card. An MII of 4 or 5 indicates banking and financial, like a Visa card or a Master Card. An MII of 7 indicates petroleum. If you have a gas station credit card, its first digit will probably be 7.

The first six digits form the issuer identification number (IIN). This is more commonly referred to as the bank identification number (BIN), although I understand that the term BIN is actually supposed to be obsolete. The digits after the IIN are the account number, except for the very last digit, which is actually a checksum for the other digits.

There's even a web site that has a free tool that you can use to find out what the IIN on your credit card means. In the free version of this tool you're limited to two lookups per day, but that's probably enought to do an interesting check or two.

Even though I knew that the first six digits of a credit card number are just the IIN, I found it a bit unsettling when I used this tool to look up what bank corresponds to the IIN on one of my credit cards.

Defining tokenization

Tokenization and encryption are the two technologies that are most commonly used to protect sensitive cardholder data like the PCI DSS requires. Encryption is very well defined and understood, but tokenization isn’t. Exactly what is tokenization? Here’s my definition. You can read more about this, including why I believe that this definition makes sense and how this definition compares to the definition of encryption, in "Defining Tokenization and the Security Provides" this month’s ISSA Journal.

A tokenization scheme comprises two stateful, deterministic algorithms: tokenize and detokenize. These operate on two strings called a plaintext and a token. The tokenize algorithm produces a token from a plaintext. The detokenize algorithm produces a plaintext from a token that has already been created by the tokenize algorithm.

A secure tokenization scheme is one in which the mutual information between a plaintext and the token that the tokenize algorithm creates from it is zero.

How to be PCI compliant yet weak

It’s possible to comply with the PCI DSS yet provide essentially no protection to credit card numbers. Here’s why.

Section 3.3 of the PCI DSS requires this:

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed).

Then section 3.4 requires this:

Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:

• One-way hashes based on strong cryptography
• Truncation
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and procedures

Each of these techniques seems to provide a reasonable level of protection for credit card numbers, but when you combine the two, it turns out that the combination can actually be fairly weak. Here’s why.

If you mask a credit card number, you can keep the middle six digits and hide the rest. So you might turn this credit card number

1234 5678 9012 3456

into this

1234 56XX XXXX 3456

Now suppose that you also know that the SHA-1 hash of this credit card number is the value

0xdeed2a88e73dccaa30a9e6e296f62be238be4ade

This is enough information to let a hacker quickly and easily find the complete credit card number: all he has to do is calculate the SHA-1 hashes of all possible credit card numbers that begin with 123456 and end with 3456. There are only one million of these, and it’s possible to calculate that many hashes extremely quickly. Even on extremely my old laptop, I can do that in less than a couple of seconds. Hackers who have even more modern computers can do it even more quickly.

So if you have both the hash of a credit card number and a masked version of the same credit card number, then it can be extremely easy to find the entire credit card number. Each of the ways to protect credit card numbers may be good enough by themselves, but together they can provide essentially no security.

I've heard of more than one case where masked data from one application and hashed data from a different application gets stored in a common database, so this particular vulnerability is not purely of academic interest.

What merchants want from the PCI DSS

More interesting stuff from the recent X9 meeting. In this case it relates to what merchants want to help them comply with the PCI DSS. At least this is what the merchants who attended the X9 meeting said that they want.

Apparently merchants don't like how vague the PCI DSS is on several points. In particular, it tells you what you have to do in general terms, but not exactly how to do this. It leaves deciding whether or not a particular approach is good enough to the QSAs. Merchants don't like this arrangement at all. They'd rather be told more details and have to live with a possibly-imperfect solution, particularly if it's one that will guarantee to make them PCI compliant.

I don't think that we'll see that level of detail in anything from either X9 or the PCI SSC, but that seems to be what merchants want. I have an easy solution for them: they should all buy and use Voltage's SecureData. I'm not sure that I can get the PCI SSC to require all merchants and payment processors to standardize on Voltage's products, but it would certainly make life easier for them.

First four vs. last four

Last week, I heard something interesting about credit card numbers. Someone that I was talking to claimed that a recent study showed that over 95 percent of people can be tricked into thinking an email is actually from their bank if the email includes the first four digits of their credit card number. We're used to seeing the last four digits being used this way, and that makes some sense, but the first four digits really aren't suitable for being used this way. 

In a 16-digit credit card number, the first six digits form the issuer identification number (IIN) that identifies the bank that issued the card. The next ninedigits are the account number, and the last digit is a checksum that's calculated from the previous 15 digits. In most cases, it's fairly easy to guess the IIN. There's a list of known prefixes to IINs here, and some of these are very easy to guess. In some cases, the first four digits are actually the same for fairly broad categories of cards.

I haven't been able to find the paper that this discussion was based on, but I wouldn't be surprised if it does exist. People in the payments industry know the structure of card numbers and know that the first four digits of a card number isn't a good way to authenticate someone. The average guy on the street probably doesn't know that, however, but that might need to change. Apparently, it's becoming necessary for people to learn more about payments processing than they really want to know.

No bucks, no Buck Rogers

 

The Buck Rogers comic that ran in American newspapers from 1929 to 1965 is probably responsible for creating, or at least popularizing, many ideas that are taken for granted in today's science-fiction. Things like rocket ships, anti-gravity technology, traveling to other planets, and dealing with their non-human inhabitants that find human women irresistible. I was recently reading a collection of these classic comics when I noticed another element of advanced technology that appeared in the Buck Rogers comics, and that's paying by credit.

In comic number 694 from 1931, Buck Rogers and Wilma Deering have made it to the legendary undersea world of Atlantis. When they're shown the technological marvels that make it such an advanced place, universal payment by credit is one of these. Apparently, in 1931, paying by credit was one of those things that seemed an advanced idea that might become true at some point in the future, and had enough of a "wow factor" to justify its mention in the comic.

I don't know if people in 1931 read Buck Rogers and marveled at what it would be like if you could buy anything that you need using credit, but it seems that that's one of the few things from Buck Rogers that has actually come to be. We don't have flying belts or rocket ships, and we haven't met any aliens who have an unexplained attraction to Earth women, but we certainly have credit cards that are accepted more places than they're not. Maybe we'll have the others some day, too.

PCI and small businesses

The business of America is business.

Calvin Coolidge

In his column on the storefrontbacktalk.com web site, David Taylor said that "small business owners may be too ignorant to ever be PCI compliant." His choice of the word "ignorant" is, at least in part, probably due to a desire to be somewhat controversial. Discussions that aren't controversial in some way really aren't very interesting, so he was probably trying to make his comments sound more interesting than they might have been otherwise. I don't think that the word "ignorant" was really appropriate in this context, however.

People in the payments industry seem to forget that small business owners aren't in the payments business. They're in the business of selling books, plastic tubing, greeting cards, or whatever they sell. Keeping their business running takes all of their time, and they shouldn't have to worry about the details of how payments are processed. The job of the payments processing vendors is to make sure that this is as easy as possible, and that it's done in a way that doesn't compromise any sensitive information.

A big part of how to do process payments securely involves the use of encryption. And just like you really can't expect a small business to be an expert in payments processing, you really can't expect payments vendors to be experts in encryption. That also requires a level of understanding that's not really that relevant to their business. What payments vendors need from encryption vendors is an easy-to-use solution that they can integrate into their offerings as easily as possible. They don't want to worry about the arcane details behind how the encryption works, they just want to use it. Worrying about all of the details that are needed to do the encryption securely is the job of encryption vendors.

It wouldn't make much sense for an encryption vendor to say that payment processors are too ignorant to ever use encryption securely. If payments vendors can't use encryption, it's the fault of the encryption vendors who aren't making the products that their customers need. Similarly, if small business owners can't become PCI compliant, it's not entirely their fault. Most of the blame should probably go to the acquiring banks and card brands that are creating requirements that aren't practical for small businesses to meet and to payment processing vendors who aren't providing small businesses the tools that they need to process payments securely.

The business of America is business, not payment processing. Let's not lose sight of that.

Gresham's law

There's a little-known observation called "Gresham's law" that may or may not have some relevance to today's security market. Gresham's law says roughly that the introduction of debased currency will tend to make non-debased currency disappear from circulation when people tend to hold onto the currency with more intrinsic value and spend the rest. It's named for Thomas Gresham, an advisor to Queen Elizabeth, but Gresham wasn't the first to note this behavior. Nicole Oresme described it in his 1357 book De origine, natura, jure et mutationibus monetarum.

This principle doesn't apply to all cases where low-quality and high-quality alternatives compete in the marketplace. It also needs some sort of regulation to make it happen. In the case of coins, there are laws that say that both the non-debased coins and the debased ones are worth the same amount, so the non-debased ones tend to disappear from circulation. In cases where there is no requirement that the low quality alternative be worth the same as the high quality alternative, Gresham's law doesn’t predict that the high-quality alternative will disappear.

In the case of the PCI DSS, however, we may have a situation where Gresham's law does hold. This is because compliance officers are often looking for a solution that lets them pass their PCI DSS audit instead of a solution that actually provides strong and useful security. The PCI DSS now acts like a regulation that makes the high-quality and low-quality products equal because they both will let their users pass their PCI DSS audit. If this is the case, then we would expect high-quality security products to disappear, leaving their low-quality competitors as the only alternatives. This hasn't happened yet. Should we expect it to happen soon?

According to "Gresham's Law or Gresham's Fallacy," a paper recently written by Arthur Rolnick and Warren Weber of The Federal Reserve Bank of Minneapolis, Gresham's law isn't as true as we might think. Here's the abstract for their paper that sums up what they found:

The claim that bad money drives out good is one of the oldest and most cited in economics. Economists refer to this claim as Gresham’s law. Yet despite its seemingly universal acceptance, this claim does not warrant its status as a law. We find it has no convincing explanations and many overlooked exceptions. We propose an alternative hypothesis based on the costs of using a medium of exchange at a nonpar price: small-denomination currency undervalued at the mint tends to disappear from circulation while large-denomination currency usually circulates at premium. Examining a variety of historical episodes when market and legal prices were different, we find our “law” can explain history much better than Gresham’s.

Like most things, the applicability of Gresham's law turns out to be more complicated that you might first think, and it takes a more careful understanding of a particular situation to predict exactly what will or will not happen. If this is the case, it looks like we may not have to worry about high-quality security products disappearing because of the PCI DSS.

The hard part of the PCI DSS

Most of the requirements of the PCI DSS are really just information security "best practices." The only real exception is Requirement 3: protect stored cardholder data. The easiest way to meet this requirement is by using encryption, but many businesses that need to handle sensitive cardholder data seem to have trouble doing that. That's not too surprising. Encryption is legendarily hard and expensive to use, and there are still some encryption technologies out there for which this is true. On the other hand, there are also lots of encryption technologies for which this isn't true. Voltage makes some of these. A few other vendors do also.

Because there are encryption technologies that make it easy to meet PCI DSS Requirement 3, I was surprised to read a recent report, "Lessons Learned: Top Reasons for PCI Audit Failure and How To Avoid Them" by QSA VeriSign. In the PCI DSS assessments that VeriSign does for its clients, Requirement 3 is the area that people fail the most frequently: a full 79 percent fail it. I found that surprising. Maybe those people should talk to someone at Voltage.

Ancient format-preserving encryption in FIPS 74

Although the format-preserving encryption algorithms that Phil Rogaway invented are very useful for encrypting data in a way that makes integrating encryption with legacy applications and complex IT environments particularly easy, it turns out that he wasn't the first to do this. An old, retired NIST document that describes how to use the DES encryption algorithm actually described a way to do it.

The NIST document that does this is the retired FIPS 74, "Federal Information Processing Standards Publication 1981 Guidelines for Implementing and Using the NBS Data Encryption Standard." This document is so old that it even refers to NIST as the National Bureau of Standards (NBS), a name that hasn't been used since 1988. FIPS 74 was withdrawn in 2005, so this technique should probably be considered obsolete. Here's how it works.

Suppose that we want to encrypt a credit card number that has 16 digits. The FIPS 74 technique encrypts one digit at a time. To do this it creates four bits that are XORed with the four bits that represent a digit. These four bits come from the lowest four bits of the output of a DES encryption. If the result of the XOR operation isn't a valid digit, then the next lowest four bits of the DES output are tried, etc. If all 16 of the four-bit values in the DES output don't give a valid digit, then the binary value 1001 is XORed with the plaintext input to get the ciphertext output. A new output of a DES encryption is used for each digit. Here's a diagram that shows how this works. This can easily be extended to more than digits. FIPS 74 describes techniques for encrypting both alphanumerics and arbitrary alphabets.

  

This technique seems to be fairly slow. Each digit it will take an average of (10/16)(1) + (6/16)(10/16)(2) + (6/16)²(10/16)(3) + ... + (6/16)¹⁴(10/16)(15) + (6/16)¹⁵(16) = 1.6 DES encryptions to encrypt, so that it will take an average of 25.6 DES encryptions to encrypt a single 16-digit credit card number.

Curiously, it looks like NIST hasn't defined a similar way to do format-preserving encryption with AES. Maybe there's really no need to do that because there exist other techniques that have strong proofs of security. The fact that a format-preserving encryption technique was included in FIPS 74 makes me think that there was an interest in the technology well before the PCI DSS increased the level of interest in encryption. Is the FIPS 74 technique used anywhere these days?

SSNs versus CCNs

There's lots of talk these days about securing credit card numbers. As I've mentioned before, people should have more of an interest in keeping information like their Social Security number protected. If your credit card number is compromised you can always have the old card canceled and a new one issued to take its place. With your Social Security number, however, you can't do that. Once it's compromised, there's no way to get it back.

It turns out that there's another big difference between credit card numbers and Social Security numbers, and that concerns how often they're exposed in data breaches. According to the information in the OSF's database of data breaches, incidents that expose a Social Security number are far more common than data breaches that expose credit card numbers. The last time I looked at the data in this database, for each incident that exposed credit card numbers there were almost seven incidents that exposed Social Security numbers.

Maybe the government should start a program like the PCI DSS to ensure that anyone handling Social Security numbers needs to have some basic security mechanisms in place.

Look out for yourself

Complying with the PCI DSS is definitely one of the biggest concerns that many businesses have these days. The PCI DSS isn't perfect, but there's probably a good reason for its existence. Data breaches expose millions of credit card numbers each year, and many of these are used for fraudulent transactions. Consumers, however, typically don't end up paying for these fraudulent transactions, at least not directly. It's still there, though, because the cost of the fraud gets built in to the prices that we pay.

According to the Federal Trade Commission's 2006 Identity Theft Survey Report (the most recent version), the median out-of-pocket loss cost that consumers experience from all forms of identity theft is actually ZERO dollars. Instead, it's the merchants and banks who really end up absorbing the losses and paying fines when they lose credit card numbers. So if you're a merchant that accepts credit cards, you have a serious interest in reducing the number of data breaches that expose credit card numbers. If you're a consumer, you probably have better things to worry about.

If you're a consumer and your credit card number gets stolen, your bank will cancel the old card and issue you a new one. You may suffer a little inconvenience, but having your credit card number stolen probably won't affect you that much. You're probably better off worrying about other sensitive information that can't be just cancelled and replaced. This includes things like your credit history, your Social Security number and your medical history. If any of these gets compromised, it can't be cancelled and reissued. Once it's exposed, your privacy is gone for the rest of your life and it's probably impossible to get it back. If you're a consumer, you probably have more of an incentive to worry about the security and privacy of this type of information.

The PCI DSS has attracted most of the attention recently, but consumers really should be more concerned about the protection of information other than credit card numbers. If you're going to lobby your government to do something, look out for your interests. Let the banks and merchants worry about reducing credit card fraud. You should worry the most about the loss of sensitive information that affects you the most.

The Philosophy of Tokenization

In 1846, Edgar Allen Poe published the essay "The Philosophy of Composition" in which he described how he came to write The Raven. What Poe says in this essay probably isn't true, but it almost certainly tells you how Poe wanted people to believe how he came to write The Raven. In other words, Poe may have invented more than the detective story. He may also have invented marketing.

Over 160 years after Poe wrote "The Philosophy of Composition" we see security vendors telling us things about their products that aren't really true but they want you to believe are true. What some tokenization vendors are claiming about their technology is a good example of this.

A tokenization system implements two functions: tokenize and detokenize. When a requesting application calls the tokenize function with a plaintext input, a tokenization system creates a token from the plaintext using a proprietary tokenization algorithm. The tokenization system then encrypts the plaintext using a cryptographic key that it gets from a key server. It then archives a copy of both the resulting ciphertext and the key used to encrypt it, and returns the token to the requesting application. When a requesting application calls the detokenize function with a token input, a tokenization system retrieves the archived ciphertext that corresponds to the token from its encrypted data archive and the key that was used to encrypt the ciphertext from its key archive. It then decrypts the ciphertext and returns the decrypted value to the requesting application.

Note that the secure operation of a tokenization system relies on the secure operation of several components: the tokenization server itself, as well as the key server that it uses, the key archive system and the encrypted data archive. The failure or compromise of any one of the components of this system will compromise the entire tokenization system.

The chances of an application being inappropriately implemented, configured or maintained is much greater that the chances of an adversary being able to defeat modern cryptography, so the reliability of a security system is limited by the chances of the system failing rather than an attacker defeating any type of cryptography. This means that tokenization systems are inherently less secure than systems with fewer components, which includes systems that implement encryption.

The security of a tokenization system also relies on the security of a proprietary tokenization algorithm. The operation performed by this algorithm is identical to the operations performed by well-known cryptographic algorithms like hash functions or encryption algorithms, which transform a message into a form from which it's infeasible to recover the original message. Oddly, the fact that its output is called a "token" instead of a "ciphertext" or a "message digest" has let tokenization algorithms avoid the careful public review that other cryptographic algorithms are subject to.

"Security through obscurity" has been known to be a bad system design principle for over 125 years - ever since Auguste Kerckoffs wrote "La cryptographie miltaire" in 1883. There's no reason why tokenization algorithms should be exempt from this general principle, and anyone thinking of using tokenization to protect sensitive data should ensure that the technology that they're considering is secure enough to withstand careful public review.

Tokenization really isn't more secure than encryption. Tokenization vendors just want us to think that it is.

A new type of standard

On May 7 there was a meeting in Plano, Texas, to discuss the plans for developing a standard for end-to-end encryption. This standard is a new work item that was recently approved by the X9 Accredited Standards Committee, the group that creates information security standards for the financial services industry. The meeting was jointly sponsored by Heartland Payment Systems and the Merchant Advisory Group, both of which clearly showed that they're now taking the security of credit card information very seriously.

The usual suspects showed up at this meeting - a combination of banks and security vendors. What was good to see was that some businesses also showed up that accept credit cards for payment for either goods or services. This was a good thing, and it should happen more often.

Most standards groups comprise just the vendors who make whatever technology is being standardized. This is usually bad, because vendors tend to create standards that reflect how they want to do things instead of how their customers want things to be done. But because their customers usually don't take part in the standards process, that's they best that the vendors can do.

Because the customers usually don't get involved in developing new standards, it's sometimes hard to feel sympathy for them when then end up with a standard that doesn't reflect their needs. So the fact that the merchants who will be using the end-to-end encryption standard are interested enough to get involved in developing a standard for it is definitely a good sign. There seems to be a good chance that the unprecedented level of involvement by the end users of the standard will end up making the standard fairly useful. It will be interesting to see how this standard develops over the next few months.

Update on the Hannaford suit

In a recent post, I mentioned how a US District Judge was considering whether or not consumers had the necessary standing to sue Hannaford Brothers over the data breach that Hannaford suffered in 2008. There's now been a ruling on this that may have interesting implications for both security and privacy.

The judge essentially ruled that if consumers didn't suffer any financial damage from the data breach then they have no damages to recover, and their claims were thrown out. In most data breaches involving credit cards, consumers end up suffering no financial damages - those are typically absorbed by the merchants that accepted the fraudulent transactions on the stolen credit cards. Because of this, consumers who have their credit card number stolen may find their options limited if they don't actually suffer any losses from the breach.

Here's how the Judge summarized his thoughts:

But if the merchant is not negligent, or if the negligence does not produce that completed direct financial loss and instead causes only collateral consequences—for example, the customer’s fear that a fraudulent transaction might happen in the future, the consumer’s expenditure of time and effort to protect the account, lost opportunities to earn reward points, or incidental expenses that the customer suffers in restoring the integrity of the previous account relationships—then the merchant is not liable.

This ruling may make data breaches much less costly for the businesses who suffer the breaches, and may leave the PCI DSS as the only effective tool to use to get businesses to take the security of credit card information seriously.

Hashing and the PCI DSS

Some people want to use hashing to render cardholder information unreadable, but a closer look at hash functions shows that this technique ends up either being non-secure, or if it's done in a secure way, then it's equivalent to encryption because the security depends on the secrecy of secret information.

The FAQ for the PCI DSS has the following to say about using a cryptographic hash function to render cardholder data unreadable:

Are hashed Primary Account Numbers (PAN) considered cardholder data that must be protected in accordance with PCI DSS?

One-way hashing meets the intent of rendering the PAN unreadable in storage; however the hashing process and results, as well as the system(s) that perform the hashing, would still be in scope to assure that the PAN cannot be recovered. If the hashing result is transferred and stored within a separate environment, the hashed data in that separate environment would no longer be considered cardholder data and the system(s) storing the hashed data would be out of scope of PCI DSS. If however, the system hashes and stores the data on the same system, that system is considered to be storing cardholder data and is within PCI DSS scope. The difference lies in where the data is hashed and then stored. More on hashing: A hash is intended to be irreversible by taking a variable-length input and producing a fixed-length string of cipher text. As the PAN has been 'replaced', it should most often be considered out of scope in the same manner receipt of truncated PANs are out of scope. However, PCI DSS Requirement 3.4 also states that the hash must be strong and one-way. This implies that the algorithm must use strong cryptography (e.g. collisions would not occur frequently) and the hash cannot be recovered or easily determined during an attack. It is also a recommended practice, but not specified requirement, that a salt be included. Since the intent of hashing is that the merchant or service provider will never need to recover the PAN again, a recommended practice is to simply remove the PAN rather than allowing the possibility of a compromise cracking the hash and revealing the original PAN. If the merchant or service provider intends to recover and use the PAN, then hashing is not an option and they should evaluate a strong encryption method.

Note that including a salt is recommended but not required. The PCI SSC should consider revising this to require a salt and to reconsider how this affects determining exactly which systems are in scope and which ones are not for a PCI DSS assessment.

A hash function H takes a message M and calculates a message digest or hash D=H(M) from it. A cryptographic hash function is one in which the following three operations are adequately hard:

1. Finding two messages M₁ and M₂ such that H(M₁)=H(M₂). This is called finding a collision.

2. Given a message digest D, finding a message M with H(M)=D. This is called finding a preimage.

3. Given a message M₁ and its digest D=H(M₁), find another message M₂ that produces the same digest, or that D=H(M₂). This is called finding a second preimage.

When a hash function is used to render cardholder data unreadable, we're really saying that it needs to be hard to find a preimage for a given message digest. If it's easy to do that, then an attacker can recover a PAN from a hash of the PAN, which means that the hash wasn't really unreadable. Making a hash of a PAN unreadable really requires more than just running a PAN through a cryptographic hash function. This is because there really aren't that many PANs possible.

You can divide a 16-digit PAN into three parts. The first six digits are the Issuer Identification Number (IIN). The next seven digits are an account number. The last digit is a checksum that's calculated from the previous 15 digits.

With a 16-digit PAN, there are 10¹⁶possible PANs. Calculating all 10¹⁶ possible message digests for these PANs sounds hard, but it doesn't require the level of effort required to make it as hard as breaking other forms of cryptography. It's roughly equivalent to the work required to break a 53-bit cryptographic key. That's a non-trivial amount of work, but one that isn't enough to really be considered secure against hackers today.

On the other hand, because the first six digits of a PAN can often be guessed, it's probably even easier to reverse a hash of a PAN than that because it's very reasonable for a hacker to be able to guess the IIN.

The IIN just tells you what type of card a PAN is from and what bank issued the card. If you're a hacker that manages to breach the security of a particular bank, for example, then it's very easy to greatly limit the range of possible IINs, leaving only the account number and the checksum that are unknown.

If you know the first six digits of a PAN, then reversing a hash function from a hash of the PAN is very easy. You only have to calculate 10¹⁰ possible message digests, which is roughly the work required to break a 33-bit cryptographic key. That's an amount of work that's fairly easy with today's computers, and one that's feasible for many hackers to do.

This means that if an attacker knows the IIN part of a PAN then replacing the PAN by a hash of the PAN doesn't really provide that much security for the PAN. It provides some security, but not enough to really defeat a moderately-determined attacker.

One way to make it harder for an attacker to recover a PAN from a hash of the PAN is to add additional information called a salt to the PAN when it's used to calculate a hash of it. So instead of calculating D=H(PAN), you might calculate D=H(PAN||SALT) instead. This makes it much harder for an attacker, but it also requires keeping the value of the salt secret to make it difficult for a hacker to find the value of a PAN from a hash of the PAN.

If the salt isn't secret then using it doesn't make it harder for an attacker to find a preimage of D, which means that it's no more difficult to recover a PAN from a hash of the PAN. If this is the case, then the reason behind replacing a PAN with a hash of the PAN doesn't make sense any more because the hash function is no longer reversible.

On the other hand, if the difficulty of recovering a PAN from a hash of the PAN depends on the secrecy of a salt, then there's no real difference between the protection provided by replacing a PAN with a hash of the PAN and replacing a PAN with an encrypted version of the PAN. In the case of using encryption, we call this value a cryptographic key. In the case of using a salted hash, we call this value a salt. In both cases, reversing the transformation is easy if an attacker has access to a secret. This means that for the purposes of complying with the PCI DSS, the two probably ought to be considered equivalent.

An unusual contract opportunity

There's an unusual opportunity for a couple of thousand dollars of contracting work that's posted on the GetAFreelancer web site. Here's what someone wants:

Looking for bluetooth chip and software, and or GSM setup that can be installed in pos terminals that will temporarily backupcard swipe info & pin info, in case of power/system failure before daily purge... Chip must be able to be installed internally, and terminal function properly. Backup info must be recorded prior to encryption, and must be able to be downloaded to bluetooth wireless device. Serious and knowledgeable electronic engineers wanted!!!!!!

In other words, they want someone to build a bug for POS devices. The current bid is only $2600, so it looks like someone's going to get this bug built fairly cheaply.

3DES 128 bit encryption does not exist

Understanding how to describe a cryptographic key in terms of "number of bits" can be tricky. Do you mean exactly how many bits comprise the key? That might not be very useful because algorithms like DES and 3DES don't actually use all of the bits in a key. A DES key actually has 64 bits, but eight of these are parity bits and aren't used to encrypt or decrypt, leaving only 56 bits for that.

Another definition is based on how much cryptographic strength a key provides. This is probably more useful, but it adds another source of confusion. A 3DES key has 192 bits, but only 168 are actually used to encrypt or decrypt. But when 3DES is used, there are attacks against it that reduce the strength provided by those 168 bits to about 112 bits.

That's too much information for most people, and it's really more than you should expect a non-specialist to understand.

On the other hand, it's definitely the sort of thing that any security vendor should know and understand. This is why I was surprised to see the term "3DES 128 bit encryption" again and again in Shift4's white paper Storing Credit Card Data.

I was surprised because 3DES 128 bit encryption doesn't exist.

Depending on your point of view, you might say that a 3DES key has either 192 bits or 168 bits. You might even say 112 bits if you're thinking about bits of strength instead of how many bits comprise a key. There's no way at all to justify saying that one has 128 bits.

You shouldn't expect the average guy on the street to know this, but it's the sort of thing that a security vendor really ought to know.

This error probably comes from a misunderstanding of an earlier version of the PCI DSS audit procedures that wasn't as clear as it could be. In particular, the testing procedures for version 1.1 of the PCI DSS had this:

3.4.a Obtain and examine documentation about the system used to protect stored data, including the vendor, type of system/process, and the encryption algorithms (if applicable).

Verify that data is rendered unreadable using one of the following methods:

• One-way hashes (hashed indexes) such as SHA-1

• Truncation or masking

• Index tokens and PADs, with the PADs being securely stored

• Strong cryptography, such as Triple-DES 128-bit or AES 256-bit, with associated key management processes and procedures

Note that the last bullet point isn't written as clearly as it could be. It looks like a combination of a missing comma and a cut-and-paste error. What they probably meant was this:

• Strong cryptography, such as Triple-DES, 128-bit or 256-bit AES, with associated key management processes and procedures

A security vendor should have been able to see the problems with the last bullet point and not just copied the confusing text. They certainly should have known that 3DES 128 bit encryption doesn't exist.

News from Maine

Yesterday, the Portland Press Herald reported how a federal judge has decided to look at the question of whether or not the Hannaford Brothers supermarker is liable for damages from the data breach that they suffered between December 7, 2007 and March 10, 2008.

This breach disclosed the personal information ofabout 4 million people and resulted in about 1,800 fraudulent charges to credit cards, none of which were passed on to consumers. This case may set some interesting precedents about exactly how responsible merchants are for protecting credit card data and what the consequences are if that data is stolen.

Hannaford is claiming that damages are inappropriate because its customers didn't actually suffer any financial damage and that all they suffered was some slight inconvenience. If the judge rules that the lack of financial damages is enough to greatly limit Hannaford's liability, that could have a dramatic effect on how legal actions from future data breaches can proceed.  

The transcript of yesterday's House hearing

FYI - the transcript and video of yesterday's hearing in the House of Representatives' Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology that tried to answer the question “Do the Payment Card Industry Data Standards Reduce Cybercrime?” is now available.

Does the PCI DSS reduce crime?

Today I listened to the podcast of the hearing before the House Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology on the topic of “Do the Payment Card Industry Data Standards Reduce Cybercrime?”

Lots of the testimony was very predictable.

• The PCI SSC stuck to their position that no PCI DSS compliant organization has ever suffered a data breach, and dodged questions about exactly how much feedback on the standard from banks and merchants they’ve actually listened to.

• Visa stuck to their position that lots of issues with the PCI DSS aren’t their problem because they’re really issues between merchants and acquiring banks.

• Retailers complained about the cost of complying with the PCI DSS. They also want increased security in the form of smart cards, and they want the credit card brands to pay for it.

• The PCI SSC and Visa dodged the question about metrics that indicate success or failure of the PCI DSS by saying that’s information that acquiring banks need to track.

To her credit, the Chair of the Subcommittee, Yvette D. Clarke (D-NY), did seem concerned that the costs of complying with the PCI DSS are significant yet there is no data available that shows that the PCI DSS is actually having any measurable benefits. Acquiring banks have that information. They should probably be more forthcoming with it.

PCI DSS needs to be stricter

Complying with PCI DSS is a good first step towards protecting credit card numbers from the cyber-criminals who steal them and resell them to other cyber-criminals. On the other hand, the large and high-profile data breaches that we've seen in the past few years show that what the PCI DSS doesn't actually do is to actually provide any reasonable assurance that credit card numbers won't be stolen. Because there's a significant gap between complying with the PCI DSS and real security, the PCI DSS may actually end up protecting businesses who just worry about complying with the standard instead of using more meaningful security. Here's why.

Negligence is the failure to use reasonable care. If you don't meet an appropriate standard for care then you're negligent, and you’re liable for any damages that you might cause. If you do meet the standard of care then your unlucky victim bears the full cost of his injuries. As a general rule, government regulations can be used to establish a standard for reasonable care. So if you're in compliance with government regulations then you can argue that you're using reasonable care and you're not liable for injuries that you might accidentally cause. This is true for government regulations, but it wouldn't be too surprising if other regulations might also work this way. In particular, because there's no government standard for protection of credit card information, it wouldn't be too surprising if you could successfully argue that the PCI DSS establishes a standard for reasonable care.

This means that it's not hard to imagine a case where a company that's suffered a data breach but has also passed their PCI DSS audit can argue that they've used reasonable care with the credit card numbers that they lost. Suppose that they can also show that they've passed other audits. Maybe their data center has passed a Type 2 SAS 70 audit and they have an ISO 27002 Certificate of Compliance. In this case, it's probably even easier for them to convince a judge or jury that they've used reasonable care. The problem is, of course, is that there may not actually be a connection between passing these audits and having strong and meaningful security. But if they can make a convincing case that they've used reasonable care, they may be off the hook, even if their security is weak enough to allow hackers to easily bypass it.

In the case of PCI DSS, there doesn't seem to be much of a connection between being compliant with the PCI DSS and having strong security. Could this end up actually protecting companies that focus just on compliance instead of trying to actually protect their sensitive data against hackers?

Another big data breach?

It looks like there has been another data breach at a large credit card processing operation. The details haven’t been made public yet, but it’s already being discussed on web sites that track data breaches. As soon as the forensics experts finish collecting the evidence that they need, there will probably be a public announcement that describes exactly what happened. We’ll probably find that the operation that has hacked has passed their PCI DSS audit yet was still vulnerable to hackers. This shouldn’t be too surprising to anyone by now. It probably shouldn’t even be considered newsworthy any more.

As I’ve mentioned before, there are good reasons to require any business that handles credit card transactions to be PCI DSS compliant. Credit card numbers are the main target of the determined cyber-criminals that are part of the multi-million dollar underground economy in sensitive information. The number of stolen credit card numbers outnumbers other sensitive information that’s traded by cyber-criminals by roughly a factor of 20 to 1, so they’re much more popular than even information like ATM PINs or bank account numbers.

Even though many politicians seem painfully oblivious to it, the law of supply and demand affects all markets, even those in stolen sensitive information: as the number of credit card numbers stolen in data breaches has increased dramatically over the past few years, the value of each stolen credit card number has dropped just as dramatically. This means that cyber-criminals now need to get millions of credit card numbers from a single hacking operation to justify the risk and the expense of such an operation. This seems to have led them to target credit card processing operations instead of merchants, and they’ve apparently been fairly successful at this, despite the increased level of security that the PCI DSS have required. This is probably because the evolution of the PCI DSS wasn’t designed to keep up with the current threat.

The first version of the PCI DSS didn’t require much more than what are considered best practices for information security. The subsequent versions increased the level of security required, and future versions will probably increase it even more. This has been a gradual and incremental process, and it clearly hasn’t kept up with the threat that professional cyber-criminals pose. As long as this process stays gradual and incremental, it seems likely that the cyber-criminals will be able to stay ahead of the security that PCI DSS compliance requires. What’s probably needed is a bigger step forward in security, and the combination of encryption and key management is probably the way to make that step.

The current version of the PCI DSS requires encryption of sensitive cardholder information, but it doesn’t require particularly strong key management processes, even though strong encryption and key management provide the basis for protecting sensitive information against even the most determined cyber-criminals. That’s how national governments protect their diplomatic and military secrets, after all. It seems to have worked fairly well for them, and there’s no reason to believe that the same model can’t also be applied to protecting other types of sensitive information. Any other way seems to be too weak to stop determined adversaries.

If the PCI Security Standards Council is serious about protecting sensitive cardholder information, and there’s no reason to believe that they’re not, we’ll probably see strong encryption and key management required in future versions of the PCI DSS. Until then, we’ll probably see more of the large-scale data breaches that have been in the news recently.