Preplay Attack on Chip and PIN

Interesting research paper on a bank card chip-and-PIN vulnerability. From the blog post:

Our new paper shows that it is possible to create clone chip cards which normal bank procedures will not be able to distinguish from the real card.

When a Chip and PIN transaction is performed, the terminal requests that the card produces an authentication code for the transaction. Part of this transaction is a number that is supposed to be random, so as to stop an authentication code being generated in advance. However, there are two ways in which the protection can be bypassed: the first requires that the Chip and PIN terminal has a poorly designed random generation (which we have observed in the wild); the second requires that the Chip and PIN terminal or its communications back to the bank can be tampered with (which again, we have observed in the wild).

Tags: academic papers, ATMs, authentication, banking, chip and pin, cloning

Posted on May 20, 2014 at 2:01 PM • 19 Comments

Comments

AndrewJ • May 20, 2014 7:41 PM

It’s interesting that here in Australia the Visa website states that “The chip prevents the card from being counterfeited..” [1]. However most of the bank websites don’t go quite so far: “A security chip credit card is more secure than one with just a magnetic stripe on the back of the card, because it is more difficult for someone to fraudulently copy your card.” [2] and also similar comments at [3].

I’m guessing the legal liability for Visa is much less than for the banks. And I haven’t heard of too many issues (yet) in Australia related to cloning EMV cards, so the banks must be settling these out of court to prevent the kind of analysis and loss of confidence as has happened in the UK and Europe.

[1] http://www.visa.com.au/personal/security/chipcards.shtml
[2] http://www.anz.com/personal/credit-cards/security/chip-cards/
[3] https://www.commbank.com.au/support/faqs/576.html

Anura • May 20, 2014 9:24 PM

The protocol used should really not require any source of quality random numbers if smart cards are involved. I would personally do the following:

1) Merchant pushes invoice to card

2) Card combines bank’s ECDH public key, and card’s ECDH private key and hashes to generate a shared secret (this shared secret could just be stored, but the advantage of ECDH is that even if the bank is breached, no one can forge your card)

3) Card appends a bank identifier so the card can be processed, a 48-bit card identifier and a 48-bit unique transaction ID to the end of the message, with the transaction ID incrementing after each transaction

4) Card encrypts pin using AES/GCM, passing the merchant identifier, key identifier, and transaction ID as the additional auth data, with the card identifier being the fixed field and transaction ID used as the invocation field to construct the IV as per NIST SP 800-38D section 8.2.1, and then appends the 128-bit MAC generated by AES/GCM

Upon receipt, the bank verifies that authentication code is valid, and that the transaction ID is greater than the last transaction id received.

No quality random numbers required, although there is a limit of about 281 trillion cards per bank at any given moment, and 281 trillion transactions per card. I don’t think this will be a problem. What needs to be guaranteed is that the transaction id can’t accidentally be reset.

Daniel • May 20, 2014 9:25 PM

I wonder if one day society will feel nostalgic for the petty criminal. One consequence of the increasing complexity of security measures is that they require increasingly complex measures to defeat. By complexity here I do not mean crypto complexity but process complexity. In the “good old days” safe-cracking or lock picking was a straightforward task compared to today’s sophisticated cyber criminal, a sophistication that demands group coordination (gangs). I can’t help but think of the parable of the bees and the elephant. Trying to shoot a swarm of bees (petty crooks) is annoying but the elephants (gangs) are far more dangerous if one misses. Is it really a social improvement if the net result of a security arms race is to force criminals to organize? Maybe one day we will wish we had left well enough alone.

Nick P • May 20, 2014 9:44 PM

@ Anura

http://www.sciencedirect.com/science/article/pii/S1319157812000171

Thoth • May 20, 2014 11:09 PM

@Anura

I am sorry to disappoint anyone who thinks banks would adopt AES-GCM anytime soon. I look around my environment I am working in and i don’t see any of these banks going to switch out of DES/3DES, let alone AES of any sorts anytime soon. They are perpetually stuck on DES like forever !

Everytime I get a client who says they want a certain service, they are very likely to insist they want legacy DES support and are unwilling to move to AES especially in the pin-and-chip department unless vendors (especially HSM vendors) stop supporting DES/3DES or they would simply continue DES/3DES.

FIPS/NIST standard compliance are just to get rid of those irritating auditors nagging at the side of their ears and they come to us for services just to get over that irritating nagging thinking it’s a magic bullet.

Sadly, very little has moved in the banking industry despite all these upheaval.

For the choice of ECDH, that would mean your key pairs are static and storing of any shared secrets can be a magnet of sorts to attacks. How are you going to generate and handle the ECDH key pairs you are going to store into the cards ? Usually a bank would issue you a card with Visa/Mastercard options which means they use Visa/Mastercard protocols.

If the bank needs to generate a new card, it generates a new ECDH keypair for the card presumably and the bank would store the card’s public key and maybe embed the bank’s ECDH public key as some kind of static keychain for verification ?

If the hash value of H(Card_ECDH_Priv_Key | Bank_ECDH_Pub_Key) –> Shared_Secret and if I figure out the Bank’s ECDH Public Key and realise that the bank uses a bad generator, I could predict the Card’s key pairs or the fact that keys stored in cards and banks do not have proper key rotation policies due to the trouble of doing so, you would always expect the same keypairs to be used on both sides.

Imagine if you want to regenerate new keypairs for cards as a policy, you would have to involve lots of customers. Assuming the same keypairs to be used for the entire lifecycle of the keys existence, your only security would be that the AES/GCM does it’s job at protecting a message.

Let’s assume that certain headers of the message are always constant or certain paramter fields are always the same and values like how much money deducted and timestamp of transaction from the terminal are the movable parts, that leaves quite a good amount of static data that can allow one to mount a pre-computed attack from a table of sorts.

Although AES/GCM would theoretically make it harder to pre-compute due to the fact that you need to have a good amount of plaintext on hand and it is rather intensive, but once you have a good amount of static data, you may have some patterns there if you can get yourself a huge amount of test data.

The overall problem with these terminals not doing a good job with random is because they lack the knowledge and expertise at making secure randoms and that is the direct problem they need to solve.

Ephemeral keys are still important as they are that unknown factor that makes pattern detection much harder.

bwahahaha • May 20, 2014 11:23 PM

OFF topic:

http://www.theguardian.com/commentisfree/2014/may/20/nsa-reform-bill-corporate-store-analysis

At this stage it seems hard to believe that the NSA would let go of the power it has accrued so far. So GCHQ will gather intel for the NSA on domestic targets and store it on UK servers and … GCHQ and the NSA will gather intel for FVEY on targets in the UK where anyone is fair game.

Heads they win, tails we lose.

Thoth • May 21, 2014 12:12 AM

I suppose the day when we don’t get to be surveyed is either technology degrades or there is no more doubts with each other.

RobinDCH • May 21, 2014 4:29 AM

Without studying the attack in great detail, it seems it’s applicable only to SDA cards which have been deprecated in Europe (but still used elsewhere) and where the CDOL-1 (which defines the tag list used for the ARQC) does not contain the ATC as an source data diversification element. One also needs to compromise the terminal software (which isn’t always easy) and fraud detection systems are likely to become suspicious if there are any significant number of customer complaints regarding low numbers of terminals (since cash is settled into a merchant account, the fraudster still needs to get it out of there and isn’t likely to be able to compromise a large number of terminals, their software and the linked bank accounts).

It’s an interesting attack but one which, so far as I’ve understood it without much investigation, is unlikely to have a significant impact in the wild.

Eric • May 21, 2014 4:35 AM

Isn’t the issue for consumers the T&Cs on their accounts/cards? When most banks issued Chip and PIN cards, they also issued new T&Cs which switched much of the liability for fraud where the card was used with a PIN to the consumer. Even if you can show that Chip and PIN isn’t completely secure, you won’t necessarily be able to challenge a transaction.

For instance, here’s an extract from what the T&Cs for my debit card say:
“If there is a dispute about your Account or Card, you accept that the records kept by us or on our behalf are sufficient evidence of your Card’s use. If a transaction is made using your Card with the PIN … you agree that we can conclude that the transaction was made by you.”

andy • May 21, 2014 8:07 AM

I think they are recycling their own research – this was news in 2012 but didn’t get many headlines.
http://www.net-security.org/secworld.php?id=13581

moo • May 21, 2014 11:37 AM

@andy:

The topic of Chip-and-PIN insecurity comes up at least once a year on this blog. Here are some of the previous posts.

https://www.schneier.com/blog/archives/2006/05/shell_suspends.html

https://www.schneier.com/blog/archives/2008/03/chip_and_pin_vu.html

https://www.schneier.com/blog/archives/2009/03/more_european_c.html

I think this was the previous research from these guys :
https://www.schneier.com/blog/archives/2010/02/man-in-the-midd_1.html

https://www.schneier.com/blog/archives/2012/09/new_attack_agai_2.html

My opinion on Chip-and-PIN is unchanged for several years: I think the main reason the banks implemented it at all was so they could shift most of the liability for fraud onto their customers. The customers, being fools, allowed this to happen instead of lynching the bankers.

Anura • May 21, 2014 12:34 PM

@Nick P

Looks like that protocol requires per-transaction random data, which is what I was trying to avoid.

@Thoth

I’m not going to try to get into the political landscapes of the banks, I’m just saying what I would do, and AES/GCM+ECC seems like a good choice due to efficiency in hardware and small size. On the issue of generating random numbers, whoever is making the cards is the one responsible for generating the keypair. If you were going to do it, you could have a certification system in place in which the card maker has to use an approved HSM to generate the random numbers and write it to the card. This is better than today in which the terminal is required to generate good random numbers, and a malicious party can modify the terminal itself. It’s also more cost effective than trying to get secure RNGs at every terminal.

The HSM manufacturer should have to certify it, and you can require that it has a minimum number of approved independent sources of entropy for the RNG, with each being theoretically sufficient (e.g. radio receiver, thermal sensor, video camera, microphone, and geiger counter+radioactive source), and that the entropy is fed to an approved DRBG so that if 128 bits of unpredictable data is ever generated, then you still cannot predict the output for the life of the device without recovering the state. If they don’t use certified devices, then they aren’t licensed to print cards for the given credit card company (i.e. VISA, Mastercard/Maestro, etc.). There’s no magic solution to all crypto problems, but you do what you can.

I would only store the public key for the card in the bank. The banks public key does not need to be kept secret. If the bank’s private key is stolen, and their card database is leaked, then yes, cards need to be reissued. That’s still better than today, as if their credit card database is leaked then cards STILL need to be reissued. Their private key would ideally be stored on another HSM where all the cryptographic functions are performed to make it more difficult to recover (and yes, HSMs are not a magical solution to all problems).

Ephemeral keys are ideal, but the problem with that is that you need a live connection to the bank, which may not always possible.

AndrewJ • May 21, 2014 4:40 PM

@Andy – They’re not recycling their own research, they discovered the first part of this back in 2012 which disclosed at a high level that there were problems, then disclosed the details to the industry, then this paper has the full details around the problems. Just a standard disclosure process really..

Thoth • May 21, 2014 8:53 PM

Since the merchant terminal is asking for a service from a banking server, I think the best place to generate random numbers are from the banks’ side passed over to merchant terminals to be computed and passed back as authentication of unique sessions.

Mr. Pragma • May 21, 2014 9:05 PM

Careful there. We shouldn’t walk again and again in the same trap.

The problem with banks and cards is not about increasing maximum security but about very considerably increasing minimum security.

Hint: PINs for many banking services are still 4 digits (!!!)

Another problem is that bank try to find the cost sweet spot. If, for instance, using security suite A (which is lousy) has an annual cost of 10 Mio and creates, say, 50 Mio customers damage which, however is picked up (or not) by insurance (included in the banks total “security packet” and in the 10 Mio cost) – and – sec. suite B, largely based on considerable real security enhancements incurring one time costs of 100 Mio and annual costs of 10 Mio (more for real security and less for insurance but in the end 10 Mio, too) and minimizes customer damage to 5 K$ (picked up again (or not) by insurance), then the bank will stay with lousy packet A, simply because its total cost is lower.

Or in other words: security is very different thing from a banks perspective than from a customers perspective — and the banks make the rules.

Thoth • May 21, 2014 10:33 PM

Security in banks have to wrangle with cost and legacy systems so it’s not surprising legacy techniques and security suites are in use. I think suite B should be what most banks should already have migrated onto by now but I guess it’s not the case. Cheaper alternatives are one factor and the monolithic systems used are hard to migrate.

PIN for cards are surprisingly short – 4 digit (ascii is 32 bits) of key material available if they want to use the PIN in some form of key material generation. Nonce are another huge headache on both the client and server side.

Although I did mention that the bank servers should generate the nonce, I am rather doubtful about their security usability (considering they don’t invest in some good ways to generate nonce using proper tools) but nevertheless it’s better than generating nonce on client devices like merchant terminals which cook up their own weak algorithms.

Good PRNGs like Yarrow/Fortuna should be adopted in an cryptographic PRNG implementation and if they can collect data from temperature and all that to feed into their RNG seed pool it do also make it even better.

Card security or any security fail due to multiple factors. Short PINs, bad RNGs …etc ..

Anura • May 21, 2014 10:49 PM

I’m not sure you can rely on random numbers generated by the bank. A lot of places, especially online stores, batch process credit cards. Plus, if your system relies on never reusing a random number, such as DSA, then a fake terminal can still do a replay attack to recover the private key, so you still need to be very careful about that in the protocol. The advantage of my system is that it doesn’t rely on external input for security.

Thoth • May 22, 2014 1:19 AM

I do agree that randoms are the hard part and if there is a way out by not using random, it would be much better. The main problem is preventing replay attacks or some sort of attacks based on caching certain information. The best case is to use a non-random secretly identifiable session code that only the client and server knows.

Coyne Tibbets • May 24, 2014 7:33 PM

Ostensibly, chip and pin is about improved security. Yet time after time, every one of these systems has been been proven to be more smoke and mirrors than real protection.

It is clear that the banks do not care if these systems are secure.

As a result, I’ve concluded that the primary purpose of chip-and-pin is not to increase protection against fraud, but to protect the bank from responsibility for any fraud that does occur. (“It must have been you that used the card sir, because the only way this charge could have happened is if the card was present. We are not responsible, you are.”)

I’m reminded of my childhood sheep-shearing experiences. The sheep are penned in a 3-sided wooden pen; the fourth side, from which the shearer pulls sheep, is constructed of loosely hanging burlap bags. This works because sheep are incapable of telling the difference between a solid wall and a burlap bag.

Preplay Attack on Chip and PIN

Comments

Leave a comment Cancel reply