This is page 2 of:
Heartland’s New Encryption Strategy: Let Them In, But Limit Them
May 11th, 2009
Late 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.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
One Comment | Read Heartland’s New Encryption Strategy: Let Them In, But Limit Them
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Ed
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.