Interesting Attack on the EMV Smartcard Payment Standard

It’s complicated, but it’s basically a man-in-the-middle attack that involves two smartphones. The first phone reads the actual smartcard, and then forwards the required information to a second phone. That second phone actually conducts the transaction on the POS terminal. That second phone is able to convince the POS terminal to conduct the transaction without requiring the normally required PIN.

From a news article:

The researchers were able to demonstrate that it is possible to exploit the vulnerability in practice, although it is a fairly complex process. They first developed an Android app and installed it on two NFC-enabled mobile phones. This allowed the two devices to read data from the credit card chip and exchange information with payment terminals. Incidentally, the researchers did not have to bypass any special security features in the Android operating system to install the app.

To obtain unauthorized funds from a third-party credit card, the first mobile phone is used to scan the necessary data from the credit card and transfer it to the second phone. The second phone is then used to simultaneously debit the amount at the checkout, as many cardholders do nowadays. As the app declares that the customer is the authorized user of the credit card, the vendor does not realize that the transaction is fraudulent. The crucial factor is that the app outsmarts the card’s security system. Although the amount is over the limit and requires PIN verification, no code is requested.

The paper: “The EMV Standard: Break, Fix, Verify.”

Abstract: EMV is the international protocol standard for smartcard payment and is used in over 9 billion cards worldwide. Despite the standard’s advertised security, various issues have been previously uncovered, deriving from logical flaws that are hard to spot in EMV’s lengthy and complex specification, running over 2,000 pages.

We formalize a comprehensive symbolic model of EMV in Tamarin, a state-of-the-art protocol verifier. Our model is the first that supports a fine-grained analysis of all relevant security guarantees that EMV is intended to offer. We use our model to automatically identify flaws that lead to two critical attacks: one that defrauds the cardholder and another that defrauds the merchant. First, criminals can use a victim’s Visa contact-less card for high-value purchases, without knowledge of the card’s PIN. We built a proof-of-concept Android application and successfully demonstrated this attack on real-world payment terminals. Second, criminals can trick the terminal into accepting an unauthentic offline transaction, which the issuing bank should later decline, after the criminal has walked away with the goods. This attack is possible for implementations following the standard, although we did not test it on actual terminals for ethical reasons. Finally, we propose and verify improvements to the standard that prevent these attacks, as well as any other attacks that violate the considered security properties.The proposed improvements can be easily implemented in the terminals and do not affect the cards in circulation.

Tags: academic papers, credit cards, fraud, man-in-the-middle attacks, PINs, point of sale, smart cards, smartphones

Posted on September 14, 2020 at 6:21 AM • 18 Comments

Comments

me • September 14, 2020 7:18 AM

i have not read this yet but is basically a relay attack where the two phones+internet is used to increase the range of contactless card right?
But… isn’t the card auth supposed to be resistant to relay attacks due to strict timing checks??

Plus seems that there is a trick to bypass pin check for high ammount of money.
But even without that how they can do a transaction from distance?

David Rudling • September 14, 2020 7:46 AM

What becomes clear from the paper is that this is basically a Visa card vulnerability.
If you are a Visa customer and are affected by a dispute between now and whenever Visa fix this, the “liability shift” against consumers and in favour of the banks brought by the adoption of EMV could be justifiably challenged in court.

Mike • September 14, 2020 11:37 AM

What is the use case for using an EMV card with a smartphone over NFC? Don’t most people just use the payment system built-in to the phone’s OS (Google Pay or Apple Pay)?

Clive Robinson • September 14, 2020 12:31 PM

@ ALL,

One of the fundemental flaws in EVM’s design is the “inbuilt man in the middle”, which is the payment terminal in the merchants premises.

The assumption is that the terminal is an extension via a crypto tunnel of the banks security system. This view point was the price EVM had to pay back over half a decade ago when it tried and succeded in fliping fraud liability on mag stripe cards onto the merchants.

Most analyses in the past of EVM protocols have assumed that this extended bank security perimiter was solid.

In practice that’s actually not the case. As I’ve mentioned in the past electronic card payments like the hospitality industry want transactions to happen for “customer satisfaction” reasons (ie don’t upset the card holder as they have feet and will use them to take their business elsewhere).

Thus the protocols can alow for less rigid security but it’s upto the banks agents how they implement the protocols to ensure card holder customer satisfaction.

But as has been shown in the past the payment terminals have other vulnerabiliries where their function gets split and another communications path gets put in, such as for “payment at the table” in restaurants etc.

History tells us that anywhere you have a communications path you need to be damn sure of how and when you authenticate. Back some time ago it was shown that EVM had not considered the contacts between the card and the payment terminal to be an exploitable communications channel for “physical reasons” then somebody demonstrated this was not so and flaws in the communications channel protocol gave rise to fraud.

I’ve yet to read the paper but it sounds like Visa has gone to far on the card holder satisfaction front and effectively weakened the security of a communications channel because they did not see it as an exploitable channel via man in the middle or other similar attacks.

This sort of failure to understand where communications channels are or make the failing to think physical security protects them is one of the major reasons all sorts of fraud and other security failings occure. As such it’s another one of those “Gifts that keep on giving”.

Clive Robinson • September 14, 2020 1:10 PM

@ me,

One of the problems with communications chanbels is when one end has no sense of time passing in either powered up / operation time or wall clock time.

People designing protocols often make incorrect assumptions about time which can give an attacker “an eye in the needle, through which to drive a Carmel”.

Look at it this way, you have a comms channel at one end is a bunch of servers that do have a sense of not just wall clock time from an Internet Time Server or GPS satellite but time progression due to internal hardware or again a GPS satellite “pace count”.

All of these times are inacurate for two reasons,

1, The speed of light.
2, The earth does not have a fixed orbital speed.

The first can be alowed for but not very accurately with modern switched communications systems. The second gives us “leap seconds” that can be positive or negative and upto twice a year jump by them. Thus there are valid times that never actually happened…

Look up how “atomic time” and “siderial time” get interfaced via UTC it’s a bit of a nightmare if your timing requirments are sub one second. Oh and light travels ~3e5 or 300,000km in a second which is quite a long way when you consider the Earth’s equator is about 40,075 km and changes by a small amount as the moon, planets, and Sun move (not only does the Earth have “tides” in water it is also an oblate spheroid pulled fatter at the middle than a sphere not just by it’s spin but also by the moon etc).

So just getting “sane time” at the server end of the comms link is difficult enough which is why it’s generaly abstracted away from most mortals including programmers via various interfaces.

Now consider the other end of the comms link where there is a smart chip. It is powred off most of the time and is “self clocking” via delay logic so realy has no temporal sense relating to wall clock time.

Thus if you are going to include any time refrences in your protocols or even have protocols work in an ordered sequence and be auditable later you have a whole bunch of issues to resolve.

But one you are going to have real trouble with is measuring very short durations in time that can tell you how far a card is from the NFC terminal especially when that card specification in reality has to include applications running on mobile phones that are multitasking with 10mS time slots.

Thus if you can get a MITM device in the comms channel you can fritz with any and all sense of time the smart chip has because it gets wall clock time from the comms channel.

lurker • September 14, 2020 3:31 PM

Have the researchers created their own private version of Apple and Google paywave? Because A & G are tech [=scary magic] and not part of the traditional bankers club, their systems are watched carefully, by the banks and by A & G themselves. Transactions which do not fit a “normal” pattern are flagged[1], and can be warned to the customer, or used to lock an account. The banks can/will not do this because they claim to respect the privacy of their customers.

The paper appears to address a transactional environment which may exist in only some parts of the world. The whole point of contactless transactions surely is speed and convenience, and to avoid touching terminal. This latter point may be important in times of Covid. So why is a PIN entry needed? Answer, for large transactions. (How large? Where?) Better answer, perhaps, is that large transactions cannot be done contactless[2]. Which is how it is done in New Zealand, and probably elsewhere.

The paper introduces the EMV protocol with

1) Bank accepts terminal-accepted transactions

Thus it is incumbent on the banks to limit their liability. Here in NZ they have chosen to do that by limiting the contactless transaction size, period. Since the introduction of the service it was ≈USD50, and since Covid lifted to ≈USD120. Were our banks more prudent than others in suspecting the fragility of the EMV protocols? No, probably not, just CYA for stolen cards.

N.B. e-shopping transactions are all contactless, PINless. Has the multi-billion (trillion?) dollar international “carding” industry taught the banks anything?

I don’t have A or G paywave, I’m just extrapolating from the behaviour of gmail and the iTunes store.
I have a Visa EMV debit card with contactless ability. The contactless transactions occur in a separate account which I keep, on the advice of my bank, deliberately at a low balance. If the balance gets too low that a transaction is refused, then the deal can be done over again, inserting the card, verifying PIN, and debiting the non-contactless account.

lurker • September 14, 2020 3:38 PM

Hmmm, the 1. and 2. on my footnotes disappeared between Preview and Submit. In Preview the numbers were indented, half the depth of a [blockquote] for no apparent reason, then on Submit they vanished and the 2 paras rolled into one….

Anders • September 14, 2020 5:07 PM

@lurker

“The whole point of contactless transactions surely is speed and convenience, and to avoid touching terminal. This latter point may be important in times of Covid. So why is a PIN entry needed?”

Here in Estonia contactless payment works in this way – there’s a limit in amount of one time payment you can make in wireless way. If you make a bigger purchase, you must enter card into the terminal and enter PIN. However, here’s a twist. No matter if you stay within the pre-arranged limit with each payment, there’s another threshold. When you reach it, the system won’t accept the contactless payment and forces you to enter card into the terminal and enter PIN anyway.

So in regular interval you are forced to enter your contactless
card into the card terminal anyway. This is so annoying currently because those card terminal pinpads are so filthy and they are not cleaned at all in some places (as it happens to be in my local supermarket).

MarkH • September 14, 2020 6:21 PM

Clive’s comment above lists a variety of factors which complicate precision timekeeping and introduce errors.

At the same time, it could leave an exaggerated impression of the limitations.

GPS systems handle some of those complications by mathematical compensation, and others by frequent calibration and correction.

According to my reading, UTC from a normally functioning GPS receiver is very close to the idealized standard for UTC.

The theoretical limit of synchronization accuracy is about 10 ns.

Accounting for errors introduced by typical receivers and aggravating environmental conditions, real-world synchronization error is less than 100 ns in the great majority of measurements.

With receivers of decent quality the error is almost always less than 200 ns.

Many receivers don’t output time at high resolution … but if a GPS timestamp has 100 ns resolution, that number is almost certainly within plus or minus 2 counts of the true time.

As always, I welcome authoritative factual correction of any errors in this comment.

lurker • September 14, 2020 8:27 PM

@Anders

Yes, it seems the systems in Estonia and NZ are similar. We have 1) an upper limit on contactless transactions, agreed amongst the banks; 2) an upper limit on machine inserted, PIN verified transactions, determined I’m not sure how; 3) an upper limit on the daily total of 1) and 2) determined by the issuing bank’s assesment of the personal credit rating of the cardholder.

So the combination of 1) and 3) would make the exploit discussed in the paper rather limited in scope in NZ, Estonia and other places with similar limits. Those banks worried about the exploit could patch it (not fix the underlying tech fault) with a bit of simple social engineering.

Talking of supermarkets, in NZ Treasury leaned on the banks to lift the contactless transaction limit because of Covid. We don’t know who leaned on the banks for another thing: the banks charge merchants a transaction fee for every EFTPOS sale. But the banks also charged a much higher fee for contactless transactions, approaching the fee for signature based credit card transactions (reportedly varying with bank and merchant, between 1.6% and 4.75%). This meant a lot of smaller shopkeepers had no incentive to offer “paywave”. During the Lockdown fees reduced to 0.6%.

But now that lockdown conditions are eased the banks are clawing back to the old fees. One said it “used third-party services to provide contactless payments, which came at a cost”. Also smells like more moving parts = more security risk. Who bears the liability for loss due to failure of the third party system? I as a bank customer have no contract that I’m aware of with the third party…

www. stuff. co. nz/business/money/122221946/paywave-shock-for-businesses-as-fees-return-to-normal
[If I just leave off http&c. this new blog writes it back again…]

me • September 15, 2020 7:28 AM

@Clive Robinson
I was not talking about a time reference or “absolute clock”
i’m talking about challenge-response time.
if the terminal ask the card some data, it expect an answer, and it has to be fast.
if you design the protocol to be strict enough i think that the delay introduced by smartphone transmission or other man in the middle stuff can be detected.
example:
terminal ask data->card: total delay: air transmission over short range+ let’s say 200ms fixed time to compute crypto answer.
with mitm:
terminal ask data->phone read the data, the app gets his turn in multitasking os, program retransmit over wifi-> air transmission over longer range->phone receive the data and when app runs retransmit the data over nfc.
here there are lots of extra delays.
-we have two multitasking os (not realtime)
-time to elaborate the message (just nfc to wifi and viceversa as is but still long)
-we have air transmission over longer range
if we can calculate the length of a cable by measuring sending pulses into it and measuring how much time pass before we get the “echo” (time domain reflectometer) and we can measure how much speed a car has by doppler effect it means that we already have precise technology to measure short times.

we know that crypto implementations are usually constant time to not leak data so we can calculate the time required to small air gap+compute time.
imprecise quartz oscillator might be problematic because it can lead to a card being faster than other to compute but the delay introduced by a phone must be huge.

maybe you can’t solve it if someone uses an analog retransmitter that increase the gap, but if you go digital with phone it can be detected for sure.

am i wrong?

MarkH • September 15, 2020 2:16 PM

@me:

If I understood correctly, the concept you proposed is logical, but breakable — at least, in some cases of what I’ll call “proximity spoofing.”

A standard response time would probably be long; as you suggested, perhaps hundreds of milliseconds.

Considering a cryptographic computation by a necessarily slow processor, it will take time. And the standard response time must account for the worst possible case of the slowest anticipated smart card.

All sorts of long-distance mischief can be made during those many milliseconds, making it possible to have an acceptable response ready at the prescribed time.

For criminal purposes, the attack need not be very reliable. If it works part of the time, it can repay the thieves who invested in it.

Whether a smartphone would work in such an attack, I don’t know. I guess not, but perhaps a phone communicating with some custom hardware …

Clive Robinson • September 16, 2020 7:42 AM

@ MarkH, me,

And the standard response time must account for the worst possible case of the slowest anticipated smart card.

Or as I noted above the time on a multitasking OS on a Smart Phone or device, which could be 100’s of milliseconds.

Which as I also noted at the speed of light –which RF signals travel at,– that’s quite a distance.

To save peoples grey cells it’s 3e6 metres or ~1875miles at a minimum.

me • September 17, 2020 5:12 AM

@MarkH
if there is an authenticated id for the type of card we can know what cpu it uses, how fast is and so how fast it can answer to a challenge.
This is needed because older cards probably uses older and slower cpu.
quartz that have a frequency +- 1% exist
I honestly never done any math like: if quartz frequency error is 1% how much is slower in picoseconds?
adding 100 meters of air how much delay does it bring in picoseconds?
because if that 1% is higher than air delay it doesn’t work.
but a relay attack using a not-realtime thing like a phone can be detected for sure, it has higher delays compared to card alone.

you can’t cheat this, you know that for a specific card model it takes exactly 500ms (for example) to compute the data.
so you send the challenge and expect to receive an answer in 501 ms.
now to cheat this system you need to relay the message in less than 1ms (for example) and given that phone is not realtime, just to retransmit data you will waste more than 1 ms and you will receive a timeout/relay attack detected error.
you can’t modify the 500ms time because is card time, you can’t make the card go faster.
this 1ms of timeframe is arbitrary but can be made as small as possible acocunting the quartz+-1%

same goes for car keys, i don’t get it… they are not doing any anti-relay because it cost more? because they don’t care? after all the car is your and if someone steal it they don’t care at all…

or they don’t do it because anti-relay is not phisically possible?

i think that the only way to do anti-relay is to keep time frames short, you can’t cheat phisics, longer distance require more time, like ping: pinging italy to itlay is shorter than italy to australia, you can’t cheat that.
and while internet has lags and other issues a direct connection between card and terminal or key and car has no lag or unexpected delay, the only delay possible is added by the relay attacker

me • September 17, 2020 5:44 AM

someone already thought at it: https://www.cs.bham.ac.uk/~tpc/Relay/stoppingRelay.pdf
distance bounding protocols … These protocols assume that card and readers hare a secret and then measure the time it takes to exchange a number of bits. Based on accurate time measurements at the level of nano seconds, knowledge of the clock speeds on both sides and the speed of light, an estimate can be made of the distance to the other party with an accuracy of a few meters.

Clive Robinson • September 17, 2020 6:40 AM

@ me, MarkH,

This is needed because older cards probably uses older and slower cpu.
quartz that have a frequency +- 1% exist

As a general rule Smart Cards are self clocking via logic gate delay rings not inverter driven quartz oscilators.

By the way the smalest quartz crystals in general use are beta cut 32kHz “watch crystals” and they are a lot better than 1% by a very high multiple.

AT cut quartz crystals even in quite bad oscillator circuits are 1ppm (1 part per million) and non TCXO’s can be made ten or one hundred parts better than that[1].

As for ring oscillators made with logic gates and no other timing components they are so bad stability wise that they are often the core of the TRNGs you find in some chips. Their stability even with stable power supply and temprature can be worse than 25%…

Thus the variation in a Smart Card CPU refrence can be as bad as the TRNG that some have built in.

However what can be done with NFC and other RF based Smart Chip devices is to lock the CPU clock to the frequency of the signal that powers the device on. There are a number of frequency bands in used one of note is around thirteen and a half megahertz (which is an ISM type frequency shared with industrial and medical diathermy, heating, lighting, welding and drying equipment some of which can be in the tens of kilowatt output range) [2].

Thus some devices could “inherit” the frequency stability of the reader unit, but for various reasons that would not include “Smart Phones” and the like.

I honestly never done any math like: if quartz frequency error is 1% how much is slower in picoseconds?

Over a short range with the position of smart device and reader unchanging with respect to each other it’s actually not to difficult to visualise the distance to frequency corespondance. The Admiral who is credited with the term “bug” Grace Hopper was known to hand out “nanoseconds” and “picoseconds” to people with a foot long wire or grain of sand respectively, these being the distance RF traveled in free space in that time period. The hight of a man is aproximatly the same wavelength as the FM broadcast band.

The important thing to note is that as a general rule of thumb you can not measure distance with an EM signal better than 1/16th of it’s wavelength and often it’s a lot lot worse with four-eight wavelengths being an acceptable error in some distance determining systems.

Part of this is that measuring time at high frequencies is not a particularly simple thing to do. So the frequency gets “down converted” adding issues to do not just with reduced bandwidth but increased uncertainty from the hetrodyne system.

However all such systems make assumptions about the devices being measured. As I’ve noted previously Smart Devices like Phones with cooperative or premptive multi-tasking OS’s can nor be relied upon for timing.

[1] You can with a good TCO and microprocessor giving dynamic adjustment get better than GPS derived stability. Oh and “atomic resonance” is actually quite poor stability wise when compared to a colapsed sun and solar system spining in space, some neutron star pulsars are better than 2 parts in 10e17 after correction for motion (however it’s believed that part of the residual error is down to gravity waves causing the equivalent of multipath delay flutter).

[2] https://en.m.wikipedia.org/wiki/ISM_band

Clive Robinson • September 17, 2020 8:36 AM

@ me,

someone already thought at it:

Have you actually read the paper?

I suspect because you quote,

“These protocols assume that card and readers hare a secret and then measure the time it takes to exchange a number of bits. Based on accurate time measurements at the level of nano seconds, knowledge of the clock speeds on both sides and the speed of light, an estimate can be made of the distance to the other party with an accuracy of a few meters.”

You’ve certainly not read it in the depth required because the immediately following two sentences at the top of page two are,

“This assumes an attacker that is capable of relaying messages at close to the speed of light. While this is possible with specialised hardware we consider this attacker model to be an overkill for contactless EVM”.

Which kind of makes my point about nano second timing. In fact if you read through the paper you will find they are talking about response times measured in hundreds of milliseconds for many responses.

Just to let you know,

1mS = 1/1000s or 3e8/1000 metres which is 3e5 metres or about 187.5miles…

Light takes around 33nS to go 10 meters which coresponds to a frequency of 30MHz which with simple measurments would need a frequency of around 480MHz.

But the shortest time the mention is about 8mS for an unsynchronised card with 20% clock accuracy that would be an error in distance estimation of around 300 miles based on the speed of light…

But also note the incompatible assumptions,

1, The attacker could not use a stored message (because the card would compute it afresh).

And,

2, The card would use the nonce[1] it had stored that it had pre-computed for use in an earlier part of the protocol.

That means that if the nonce[1] either during it’s calculation or during it’s first use in the protocol became known to the attacker, via a side channel leak etc then the attacker could like the card have it pre-stord for immediate use at the Epos terminal defeating the protocol.

Thus reusing of the nonce[1] in the way suggested in the paper is a real Security “No No”. As our host @Bruce has pointed out in the past, few people designing or implementing protocols involving a nonce appear to comprehend the “use ONCE” aspect. It reuse a nonce is actually potentially worse than “Reusing a One Time Pad”…

I could raise other asspects about the paper but you should be able to see why I would not put much faith in it not being subverted.

They further make an incorrect assumption that the attackers will in effect use an unmodidied phone at the epos end. I certainly would not make that assumption, I would infact assume they would use an Android phone that they have built and loaded their own optomised version on[2] to significantly reduce any delays within it.

As our host @Bruce has also noted about attacks in general, they improve with time.

[1] The word “nonce” whilst offensive to many, in mathmatics and more importantly Security means “Number used only ONCE”.

[2] The process of replacing Android on a device and still having full I/O control can be seen with,

http://www.thanassis.space/android.html

calvin harris • August 9, 2021 12:09 PM

Schneier on Security

Interesting Attack on the EMV Smartcard Payment Standard

Comments

Leave a comment Cancel reply