Comments on: Heartland’s New Encryption Strategy: Let Them In, But Limit Them http://storefrontbacktalk.com/securityfraud/heartlands-new-encryption-strategy-let-em-in-but-limit-how-much-they-can-get/ Techniques, Tools and Tirades about Retail Technology and E-Commerce Wed, 08 Feb 2012 16:02:40 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: A reader http://storefrontbacktalk.com/securityfraud/heartlands-new-encryption-strategy-let-em-in-but-limit-how-much-they-can-get/comment-page-1/#comment-60996 A reader Fri, 15 May 2009 03:12:50 +0000 http://www.storefrontbacktalk.com/?p=2956#comment-60996 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. 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.

]]>