New Attack Against Chip-and-Pin Systems

You see, an EMV payment card authenticates itself with a MAC of transaction data, for which the freshly generated component is the unpredictable number (UN). If you can predict it, you can record everything you need from momentary access to a chip card to play it back and impersonate the card at a future date and location. You can as good as clone the chip. It’s called a “pre-play” attack. Just like most vulnerabilities we find these days some in industry already knew about it but covered it up; we have indications the crooks know about this too, and we believe it explains a good portion of the unsolved phantom withdrawal cases reported to us for which we had until recently no explanation.

Paper here. And news article.

Tags: academic papers, banking, chip and pin, cloning, credit cards, debit cards, retail, smart cards

Posted on September 11, 2012 at 12:38 PM • 11 Comments

Comments

Section9_Bateau • September 11, 2012 1:09 PM

I would like to point out that this “unpredictable numbers” is nothing more then a weak excuse for a nonce, and in reality, almost all payment systems will just stop processing (not return error to the payment processor, which would help warn of the attack) if the chip is removed (physically or logically) from the terminal during a transaction.

Best case, this would be a PRNG with a period of 2**17 it sounds like (though that example was just an incrementing counter), which is actually VERY low. If it is indeed just a counter, as was indicated in one example in the paper, it is periodic and predictable, and I have personally used timing attacks with target in the sub-milisecond range just fine in attacks on systems across continents.

There is no reason to believe an attacker can’t easily determine the correct timing sync of a transaction processor, get a few second window worth of “unpredictable numbers”, and then just wait to process their transaction in that window. Key thing in protocol design, “number(s) used only once” should be used only once! I really wish I had time to pick apart the EMV standard, too bad my day job takes more hours then are in a day.

kashmarek • September 11, 2012 6:19 PM

This sounds more like the discovery of an existing design flaw than a “new” attack.

Anonymo • September 11, 2012 7:06 PM

Kashmarek, a substantial amount of attacks, new and old, entail exploting existing design flaws.

foo • September 11, 2012 11:56 PM

A new codec, how about examining it for potential security issues:

https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/

Andrew • September 12, 2012 3:02 AM

EMV level 2 terminal type approval doesn’t contain any random number testing accept “the terminal generates a different random number from one transaction to another”. For contactless TTA, PayPass, payWave, DiscoveryZip also doesn’t but ExpressPay does.

The certification in this case that should’ve verified the strength of the RNG is in PCI PTS3.x/PED2.x. It has a surprisingly weak requirement for “other uses” of random number. I quote the DTR below:

“Unpredictability of random numbers is as important as distribution. The implementation shall ensure that seeding or initializing the random number generator at startup cannot be abused to intentionally reproduce a given random value or sequence.

Random numbers generated for use in the creation of cryptographic keys require a strong source of entropy in order to prevent predictability. Other uses, such as the generation of random nonces for the prevention of replay attacks when using asymmetric techniques to distribute symmetric keys may only require the guarantee of uniqueness.”

Clive Robinson • September 12, 2012 3:49 AM

@ Andrew,

Other uses, such as the generation predictability. Other uses, such as the generation of random nonces for the prevention of replay attacks when using asymmetric techniques to distribute symmetric keys may only require the guarantee of uniqueness.

Ouch, in fact double ouch when you consider the EVM standars don’t realy call it a “nonce” [1] so a programmer or team might not actually put 2&2 together and realise there is a “security need” with respect to it.

[1] The term “nonce” is strongly depreciated in UK publications, papers and web pages because it can cause them to be blocked by content filters. The reason being that in the UK “nonce” is slang for a person who either molests children for their own gratification (any molestation not just sexual) or looks like, or is assumed by others to be so.

Gweihir • September 12, 2012 6:49 AM

@ Section9_Bateau:

Actually, a nonce and an “unpredictable number” are two very different beasts:

A nonce must not be reused, but it is allowed to be predictable. Using a counter is perfectly fine. One reason nonces are often implemented by way of cryptographically hard to predict longer random numbers is that this way there is no need to keep state, as collisions are practically impossible.

An unpredictable number, on the other hand can be repeated, but only in a non-predictable fashion. For this, it has to be long enough, but does not need to be random either. For example, a counter encrypted with a secret key would do fine.

In practice, nonce generation and generation of unpredictable numbers often use the same methods, but it is important to understand that they offer different guarantees. The algorithm used often (larger number of bits from a C(P)RNG) , just fulfills both sets of guarantees.

Alan Kaminsky • September 12, 2012 8:47 AM

From the paper: “Recently there has been some formal analysis of EMV, but this flaw was not discovered [4].”

EMV is the cryptographic protocol used to authenticate smart card transactions. “This flaw” refers to the weakness in the EMV protocol that allows the pre-play attack to succeed.

[4] refers to a paper presented at the 2011 Theory of Security and Applications Conference titled “Formal analysis of the EMV protocol suite.” The abstract of that paper says, “Our formal analysis does not reveal any new weaknesses of the EMV protocol suite, but it does reveal all the known weaknesses, as a formal analysis of course should.”

Academic cryptographers love to publish formal analyses and formal “proofs of security” of cryptographic protocols. Another takeaway message here is that such analyses and proofs are essentially worthless.

derp • September 12, 2012 10:05 AM

2600 if I remember a guy cut out the chip on his card and did various other hacks to it so it would work without a chip…. in a chip reader.

Bruce Ediger • September 12, 2012 12:58 PM

it explains a good portion of the unsolved phantom withdrawal cases reported to us

In 2005, Ross Anderson was part of another British “phantom withdrawal” problem. See The Register’s article. Is this vulnerability tied into the previous “phantom withdrawal” case? And what rogue bank perpetrated the previous round of problems? I don’t think that ever came out, did it?

Erik Poll • September 18, 2012 2:24 AM

I agree that formal security analysis has its limitations, but I think Alan Kaminsky’s criticism is a bit unfair in this case. (As one of the authors of [4], I might be biased here 🙂

In any analysis of a security protocol – formal or informal – you make some basic assumptions. These typically include that the cryptographic algorithms used (here 3DES and RSA) are secure and that random numbers are unpredictable. You cannot expect the analysis to then point out flaws due to predictable randoms. In the same way, you cannot expect it to point out weaknesses due to buffer overflows in the implementation or some bank leaking its master key over the internet.

What I don’t get about this pre-play attack is that while the authors demonstrate that the first step of an EMV transaction (an ARQC) can be faked, they admit that they cannot fake the second step, the TC (Transaction Certificate). So the issuing bank will notice this attack, making it very unattractive to any criminal, and an unlikely explanation of phantom withdrawals. Also, I would expect the issuing bank not to pay out for the transaction, which would make this a nice (but unfortunately rare) case where the party to blame – the bank with crappy RNG in its ATM – would pay for the damage.

Schneier on Security

New Attack Against Chip-and-Pin Systems

Comments

Leave a comment Cancel reply