This is page 3 of:
Heartland’s New Encryption Strategy: Let Them In, But Limit Them
May 11th, 2009“Today, the card brand has already assigned a reference number to that dispute. Instead of using the card number within that dispute within our internal backoffice systems, our intent is to use the reference number. We will have to, from time to time, pull up card numbers in our service center, but that will be done through a secure process,” Carr said.
“The card numbers are all encrypted in the database and in the datawarehouses and there will be decryption tools that will be available to our service center to take the reference number and go track down the card number. That’s needed when there’s duplicate transaction processing, if there’s a batch balancing problem, etc.,” the CEO and Chairman said. “Those kinds of tools are necessary, but they don’t expose large numbers of card numbers at any one time. We’re just trying to reduce the exposure. I think this approach will reduce it tremendously do it in a way that the merchant is not required to store card numbers any more. The processor would have all of the card numbers in their secure databases that are encrypted.”
Another potential hiccup has been standards and consistent deployments, which could be undermined if various processors go their own way. But the Heartland CEO dismisses such concerns because of the involvement of Visa, MasterCard and AmericanExpress. “I think that’s manageable because the card brands will determine the specifications for how they will accept the encrypted data,” he said.
Click here to listen to the full first podcast on the technical details and here to listen to the full second podcast on the practical industry political realities of getting such a plan widely used. By the way, there’s no registration needed for either podcast. Come on in: the door’s open.
-J- R
May 14th, 2009 at 10:12 pm
Without changing the way the card industry or the banks do business today, this sounds like a fairly decent solution. Encrypting small batches of account numbers with the same key has a few cryptographic risks: a bad guy can attempt a chosen plaintext attack, or use a known plaintext attack to help decipher the batch. But as long as they are using good cryptography (AES or 3DES), those attacks won’t be enough to help an attacker.
I do wonder how they will be generating pseudo-random numbers. That seems to be the weakest link in this chain (reversing the random number generator was the downfall of SSL in Netscape 4.0 a while back.)
Other attacks against this type of implementation include traffic analysis. If you see a specific pattern at 10:00 and again at 2:30, you can surmise that the same card was used twice at that terminal, although you won’t be able to identify the card number itself. Will that help an external attacker? It certainly won’t help a card thief, but could permit certain forms of surveillance.
This might also be susceptible to a brute-force attack if the attacker has access to the encryption routine: by force-feeding it millions of card numbers, he might be able to guess one of the current batch (limited batch sizes prevent this attack.)
As I keep saying, however, encryption at the reader is only a stop-gap deterrent, and not a complete solution. Stolen credit card numbers and cloned cards will continue to be valuable to thieves. Skimmers will still be profitable tools. The only way a real solution will be possible is when the card industry itself steps up to the plate with smart card encryption (a more secure version of CAP, for example.) Once that’s in place, all the encryption hardware and schemes we put in place today will be impotent extra layers that will just cost us more money to remove.