Encrypt every part of your payment data and you may be giving your least favorite cyberthief a beautifully wrapped gift. That's the secret dare not spoken aloud in security circles, and it was hinted at—albeit obliquely—by the PCI Council in its latest update.
Although it can be considered cryptographer heresy to suggest that encryption is ever a bad thing, if it's applied to certain fields, encryption may actually sharply undermine security by making it much easier to break the encryption key. And when that happens, the whole gig is up.
PCI requires retailers and processors to protect the electronic cardholder data they store. The most common approach to that protection: using strong encryption on the primary account number (PAN), along with such data as the cardholder name, the service code and the expiration date.
But there's sometimes an unintended result: Encrypting all your data may actually make you more vulnerable to a data breach. A sophisticated attacker knows to focus on small fields with a limited number of possible values. That makes an encrypted card expiration date a perfect target for cyberthieves.
The expiration date is a four-character field. Because most payment cards expire within 36 to 48 months, that field has a relatively small number of possibilities. A sophisticated group of bad guys could attack your encryption by focusing on it. And successfully decrypting the expiration date could give that group the keys to unlocking--and compromising--your entire database.
Page 1 of Navigating PCI DSS defines cardholder data as the PAN plus "other data obtained as part of a payment transaction." That other data includes cardholder name, the service code and the expiration date. All of this data must be protected if it is stored in conjunction with the PAN, per PCI DSS requirements. When you look at this table of proposed changes, note the subtle distinction that states only the PAN, not all cardholder data, has to be protected per Requirement 3.4.
That requirement only obliges you to "render the PAN unreadable anywhere it is stored." In practice, this requirement usually means encrypting the data. Most retailers and processors encrypt their entire cardholder database, including name, service code and expiration date, in addition to the PAN. It is this process of encrypting all cardholder data that not only causes additional work but may actually make you more vulnerable to a data breach.
My colleagues and I--and I'm sure many other QSAs, too--are aware of this situation. We have started discussing with our clients whether they should focus their encryption on PAN data exclusively. Certainly you need to protect all cardholder data. But you only need to apply Requirement 3.4 to the PAN data.
I was very pleased to see the PCI Council highlight this distinction between the PAN and the rest of cardholder data in the latest summary of changes to PCI DSS 2.0. The very first entry in the table of proposed changes is "Clarify that PCI DSS Requirements 3.3 and 3.4 apply only to PAN."
I believe the Council is telling retailers and processors to use encryption wisely. The Council is reflecting the fact that the bad guys do not attack encrypted data directly because the strong encryption is too good. Instead, the bad guys attack the encryption keys, which is why there are so many PCI requirements surrounding key management. When you encrypt a small field with a limited number of possible values, like the expiry date, you risk giving a determined (and sophisticated) attacker a potential route to compromising your entire cardholder database.
What should a retail CIO do? My suggestion (and the PCI Council's, I believe) is that you take a fresh look at your encryption policies and practices. If you are encrypting all of your cardholder data and/or any non-mandatory fields, scrutinize your total data protection and your key management processes to see if it may be better to encrypt only the PAN data.
In fact, it may be a good idea to rethink all of your encryption practices. For example, some retailers may be encrypting only the first 12 digits or just the middle eight, and then storing the rest in clear text. In such cases, the same attack vector I described here would apply; your encryption practices reduce the total number of possible outcomes and unintentionally provide an attack surface for the bad guys.
What do you think? Do you encrypt all your cardholder data? Leave a comment or send me an E-mail at [email protected].