Heartland’s New Encryption Strategy: Let Them In, But Limit Them
Written by Evan SchumanLate this year, databreach victim Heartland Payment Systems will roll out its version of end-to-end encryption, leveraging a Tamper-Resistant Security Module. But the encryption-key strategy behind it is willing to allow cyber thieves to get some data, as long as it’s not enough for them to make any money from that information.
Making the hardware technology part work will be comparatively easy, compared with the task of getting retailers to buy in, along with getting the backing of Visa, MasterCard, AmericanExpress and other card brands. Heartland CEO Robert Carr discussed the details of his plan for the first time in a pair of StorefrontBacktalk podcasts, with the first of the podcast series focusing on the technology details of the plan and the second delving into the practical industry political realities of getting such a plan widely used.
Related Column: Is Heartland’s End-to-End Move The First Shot In A Processor Lock-In War?
Sometime by the end of September (the end of the third quarter), Heartland plans to start rollout a new security approach to its retailer customers. It’s based on attaching a Tamper-Resistant Security Module (TRSM), which is a physical piece of hardware, “within centimeters or less to the magnetic stripe itself. The connection is shielded with” the TRSM, Carr said. “We’re also working on an identity-based encryption model and a format-preserving encryption model that will allow us to manage the keys for the merchants that implement this.”
(Related Story: Heartland CEO Vows To Fight MasterCard Breach Fines Of $6 Million-Plus)
Carr said that there is a monetary cost to retailers who might choose to make the move, an amount he estimated at between $100 to $300 per card reader. There’s an effort cost: “Any change is painful,” he said. But beyond the hard and soft costs inherent in this kind of change, the biggest initial hurdle will be convincing retailers that this will actually help make things more secure.
“We’re going to ask the retailer to move to a dispute resolution service where the card number is no longer required, where we go to a reference number or other such token number to handle any kind of customer disputes in terms of draft retrieval requests or chargeback issues,” Carr said. “We think it’s a matter of time before the card brands will accept encrypted transactions as part of the flow.”
Heartland has been in discussions with three of the largest card brands and, Carr said, “none of them has yet committed. They’re all working on determining the efforts that would be required. But the model that we’ve introduced into the discussion is the standard model being used to decrypt PINs now. The card brands have indicated a willingness to pursue accepting transactions from those processors who are willing to send encrypted data to their specifications. So no one’s agreed to do it yet but the conversations have been positive. I think there is resistance to forcing encryption onto everybody and that’s not what we’re suggesting.”
-Marc
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.