Superconductor

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.

Is compliance a cost?

There's a post on McAfee's web site that answers the question "Is information security compliance really a cost center?" like this:

No. Absolutely and unequivocally not. I am drawing the line in the sand. Business leaders need to understand there is no more need for proper security to justify itself over and over again. It saves you time and money (period).

Properly implemented information security provides business process improvement, technology improvement and threat reduction. Compliance controls that cover each of these areas to accepted “best practices” will save your organization money by the truckload and provide for expansion of your business tenfold if not more.

Far too often businesses require “measurable” savings when the cost reductions and business enablement is as obvious as a freight train hitting you while you are siting on the tracks. Below I will detail a simple walk-through of a compliance driven organization versus a non-compliant organization which makes it obvious that it is better and more efficient to be compliant as a business.

In most situations, the term "compliance" means regulatory compliance, or being compliant with data security and privacy laws and regulations. If this is how we interpret "compliance," then compliance is definitely a cost center, at least in many cases. Here's why.

Businesses tend to make investment decisions that maximize the benefits that they receive from the investments. They might be maximizing profit, or something else like market share. This means that when they decide to use a particular security technology, there's probably a good reason for doing so. It also means that when they decide not to use certain security technologies, there's probably a reason for that also. This means that you'll almost never hear discussions like the following:

CSO: We should encrypt the hard drives on our laptops. Our model shows a 60 percent ROI over a three-year period for the total cost of deploying and supporting full-disk encryption software.

CFO: Bah! I don't care about ROI arguments. Instead, we should wait for the government to mandate that we use that technology.

So it's reasonable to assume that investments that are made purely as a requirement for regulatory compliance are ones that wouldn't have been made on the basis of the value of the investment alone. This means that they don't make sense from a business point of view, and that mandating them forces businesses to make investments that they really shouldn't make.

Passing data security and privacy laws may force some security spending, but it's probably at the cost of other security projects that deserved to be funded instead. This means that the net result of data security and privacy laws may be just to reallocate spending from projects that had a good justification to ones whose only justification is to become regulatory compliant. That's probably not a good idea.

There are cases where it makes sense to do some of the things that are also required by regulatory compliance. Data breaches can be extremely expensive, for example, so it's often the case that there's a valid business case for using encryption. This means that there's a strong business case for using persistent encryption of sensitve information. There's also a strong business case for using encrypted email.

If you're really curious about the details of these business cases and don't mind slogging through some detailed risk models, you can take a look at Kevin Soo Hoo's doctoral dissertation "How Much Is Enough? A Risk-Management Approach to Computer Security." He did a careful analysis of the cost-benefit analysis of several information security technologies and found that the case for encryption is strong. The business case for encryption is still valid in the absence of the need for compliance. Other security technologies aren't as lucky.

Compliance may not always be a cost center, but in many cases it is.

Key management in PCI DSS 1.2

The Payment Card Industry Data Security Standard (PCI DSS) version 1.2 came out in October 1, 2008. It has a few changes from the earlier 1.1 version, but one of them seemed worth of mentioning. This particular change is actually in the glossary, where "strong cryptography" is defined.

Here's how "strong cryptography" is defined in PCI DSS v1.1:

General term to indicate cryptography that is extremely resilient to cryptanalysis. That is, given the cryptographic method (algorithm or protocol), the cryptographic key or protected data is not exposed. The strength relies on the cryptographic key used. Effective size of the key should meet the minimum key size of comparable strengths recommendations. One reference for minimum comparable strength notion is NIST Special Publication 800-57, August, 2005 (http://csrc.nist.gov/publications/) or others that meet the following minimum comparable key bit security:

• 80 bits for secret key based systems (for example TDES)

• 1024 bits modulus for public key algorithms based on the factorization (for example, RSA)

• 1024 bits for the discrete logarithm (for example, Diffie-Hellman) with a minimum 160 bits size of a large subgroup (for example, DSA)

• 160 bits for elliptic curve cryptography (for example, ECDSA)

Here's how "strong cryptography" is defined in PCI DSS v1.2;

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).

See NIST Special Publication 800-57 (http://csrc.nist.gov/publications/) for more information.

It's interesting to see that proper key management practices are now part of the definition. I have to wonder why this was added. It might have been an oversight in the earlier version. It's easy to overlook things when you're writing, and the people who wrote the earlier versions of the PCI DSS might have just forgotten to include it.

It might be part of a conscious effort to gradually make the PCI DSS more and more stringent with each version. That might be the PCI Security Standards Council's way of getting the payment card industry to continue to improve over time.

A third possibility is that it's in reaction to merchants or banks that tried to be minimally compliant with PCI DSS v1.1 by using encryption but having sloppy key management practices. Sound key management can be expensive, so it's certainly possible that people tried to do this. I've seen it happen on more than one occasion myself. It's hard to say what the exact reason for this change was, but I'd bet on the last reason: that people tried to be minimally compliant with PCI DSS and ended up with solutions that really didn't provide any additional security but managed to technically comply with the standard.

Why PCI DSS?

It's probably no secret to anyone reading this that the information security requirements for anyone handling credit cards have been increased dramatically recently. These requirements are reflected in the Payment Card Industry Data Security Standard (PCI DSS). As you'd expect, there's been a fair amount of grumbling by the merchants who are the most affected by the new standards. This is to be expected, of course. Nobody wants to spend money on information security that they don't need. So one question to ask is whether or not the PCI DSS is really needed. A look at the market for stolen or compromised sensitive information seems to show that PCI DSS is badly needed and may not even be enough.

One of the best studies on the underground economy of stolen or compromised sensitive information is probably the one done by Jason Franklin, Vern Paxson, Adrian Perrig and Stefan Savage. Their paper that describes their research and what they learned is "An Inquiry into the Nature and Causes of the Wealth of Internet Miscreants." You can find a copy of it here. It's well worth the time and effort that it takes to read. One graph from this paper shows the most common types of data that were advertised as being for sale by cyber-criminals. Here's what that graph looks like. 

     

This graph seems to show that credit card information is widely available. It's more available than Social Security numbers or ATM PINs by a factor of roughly 20 to 1. This means that it's probably the case that credit card information needs to be protected much more than it's being protected now.

The PCI DSS is probably a good first step in this direction, but even complying with the latest version of the PCI DSS isn't enough to guarantee that credit card information won't be lost or stolen, as the recent data breach at Heartland Payment Systems shows. Heartland passed their PCI DSS audit, but hackers still managed to penetrate their system and compromise millions of credit card numbers.

NRS 597.970

We've have seen more than 39 states adopt data breach disclosure laws since California Senate Bill 1386, these laws help with cleaning up the mess left behind by a breach. Now, however we are starting to see the first laws trying to address the problem of preventing the breach from happening in the first place. The first state to do this is Nevada with Massachusetts, Washington and Michigan to follow shortly. These laws mandate the use of encryption to prevent sensitive customer information from being compromised when that information is transmitted out of the business.

Nevada Revised Statue (NRS) 597.970, which is effective October 1, 2008.

NRS 597.970 Restrictions on transfer of personal information through electronic transmission.

1. A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.

2. As used in this section:

(a) "Encryption" has the meaning ascribed to it in NRS 205.4742.

(b) "Personal information" has the meaning ascribed to it in NRS 603A.040.

This certainly looks like it requires encryption, but a closer look at the law also shows that there's no penalty for breaking it.

NRS 597.100 Criminal penalty. A person who willfully and intentionally violates any provision of NRS 597.010 to 597.090, inclusive, is guilty of a misdemeanor.

However, this law opens up businesses to law suits and in combination with the prevailing data breach disclosure law, having encryption will limit a businesses liability in the event of a data breach. So adding some low cost encryption software seems like a small price to pay for protecting your customer and employee data from being exposed after all.

Nevada businesses - take a look at www.voltage.com/nevada

UPDATE: From the WSJ - October 16th, 2008

"In Nevada, companies that suffer a security breach but comply with the new law would cap their damages at $1,000 per customer for each occurrence. Those that don't comply would be subject to unlimited civil penalties under the proposed enforcement plan, said James Earl, executive director of the state's task force for technological crimes."

Aberdeen releases PCI Data Security Standard Compliance Survey Results

Aberdeen released a new survey report that details how companies are attempting to become PCI compliant. You can download a copy of it here.

This report provides insights into the year-over-year progress that Best-in-Class organizations have been made in achieving, and sustaining, compliance with the Payment Card Industry (PCI) Data Security Standard (DSS). Public disclosures of security breaches involving consumer cardholder data continue to be a threat to consumer confidence in payment cards, and a growing source of financial risk for the payment card industry. The payment card industry has made steady progress in establishing a common set of security standards, evangelizing best practices, and encouraging adoption. Aberdeen's research shows that Best-in-Class organizations have indeed achieved superior protection of cardholder data through compliance with PCI DSS, and even Laggards have made encouraging gains in the last year.

The most interesting thing about the report is the comparisons of companies who have thought through a pro-active compliance program, established goals, evaluated technology solutions and started to implement them; and those that are still researching their options (laggards).

Five Compelling Facts from the Research:

1. On average Best-in-Class companies are achieving 22% better performance at addressing the 12 high-level PCI DSS security requirements, compared to other respondents.
2. Best-in-Class companies took 29% less time to achieve PCI compliance than all other respondents.
3. Best-in-Class companies spent 9% less to achieve PCI compliance than all other respondents.
4. Best-in-Class companies are spending 56% less to sustain PCI compliance than all other respondents.
5. Between 40-50% of Best-in-Class companies have reduced the number of failed audits and the number of data security incidents over the last 12 months.

Fox Business News features Voltage Security CEO

Voltage's CEO, Sathvik Krishnamurthy was recently featured in the CSuite Sitdown segment of the Money for Breakfast show on the Fox Business Channel discussing how Information Encryption solutions can dramatically reduce identity theft risks, speed time to regulatory compliance and enable developer access to production data without compromising sensitive customer information.

The interview focused on consumer privacy, identity theft and Voltage's information encryption strategy for persistently protecting sensitive data wherever it goes. Sathvik highlighted the problems the industry is facing, threats to consumers and the growing popularity of Voltage solutions in solving this problem.

For more details visit www.voltage.com/data_protection

Top Gear Data Protection

My favourite British commentator, journalist and presenter of "Top Gear" the fantastic BBC car show - Jeremy Clarkson- just had his identity hacked and his bank account breached. Unlike many victims of identity theft, he had recently published his bank account details in his column at the Sun newspaper. Why you ask ? Well he was simply fed up with the furor around the loss of 7.25 million records of British citizens lost by Her Majesty's Revenue and Customs agency in November. His thesis being that all those identities were not at all at risk and that bank security details are perfectly secure. This weekend he revealed in his Sunday Times column, that yes, his bank account had been tampered with and 500 GBP had been debited from his account and sent to the account of a British charity. Now he's advocating stringent measures to deal with people that commit identity fraud.

Here at Voltage we're about to introduce a new cryptographic approach, known as Format-Preserving Encryption, that will help foil identity theft in its entirety. Read about the solution that protects credit card numbers, bank account numbers and other structured personal data inside the vast databases and applications used by financial services companies around the world, here.