Source document: https://docs-lawep.s3.us-east-2.amazonaws.com/1697799736661.pdf (Liberia)
Keep Your Enemies Close: Distance Bounding Against Smartcard Relay Attacks Saar Drimer and Steven J. Murdoch Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/users/{sd410, sjm217} Abstract Modern smartcards, capable of sophisticated cryptogra- phy, provide a high assurance of tamper resistance and are thus commonly used in payment applications.
Al- though extracting secrets out of smartcards requires re- sources beyond the means of many would-be thieves, the manner in which they are used can be exploited for fraud.

Cardholders authorize ﬁnancial transactions by presenting the card and disclosing a PIN to a terminal without any assurance as to the amount being charged or who is to be paid, and have no means of discerning whether the terminal is authentic or not.
Even the most advanced smartcards cannot protect customers from be- ing defrauded by the simple relaying of data from one location to another.

We describe the development of such an attack, and show results from live experiments on the UK’s EMV implementation, Chip & PIN.

We dis- cuss previously proposed defences, and show that these cannot provide the required security assurances.
A new defence based on a distance bounding protocol is de- scribed and implemented, which requires only modest alterations to current hardware and software.

As far as we are aware, this is the ﬁrst complete design and imple- mentation of a secure distance bounding protocol.

Fu- ture smartcard generations could use this design to pro- vide cost-effective resistance to relay attacks, which are a genuine threat to deployed applications.
We also discuss the security-economics impact to customers of enhanced authentication mechanisms.

1 Introduction Authentication provides identity assurance for, and of, communicating parties.

Relay, or wormhole attacks al- low an adversary to impersonate a participant during an authentication protocol by effectively extending the in- tended transmission range for which the system was de- signed.
Relay attacks have been described since at least 1976 [13, p75] and are simple to execute as the adver- sary does not need to know the details of the protocol or break the underlying cryptography.

A good example is a relay attack on proximity door-access cards demon- strated by Hancke [16].

To gain access to a locked door, the adversary simply relays the challenges from the door to an authorized card, possibly some distance away, and sends the responses back.
The only restriction on the at- tacker is that the signals arrive at the door and remote card within the allotted time, which Hancke showed to be sufﬁciently liberal.

Another example is wormhole at- tacks on wireless networks by Hu et al.

[18].

Despite the existence of such attacks, systems susceptible to them are regularly being deployed.

One signiﬁcant reason is that designers consider relay attacks to be too difﬁcult and costly for attackers to deploy.
Section 3 aims to show that relay attacks are indeed practical, using as an exam- ple the UK’s EMV payment system, Chip & PIN.

These ﬂaws are demonstrated by an implementation of the relay attack that has been tested on live systems.

Once designers appreciate the risk, the next step in building a secure system is to develop defences.

Sec- tion 4 describes potential countermeasures to the relay attack and compares their cost and effectiveness.
While some, which depend on procedural changes, could be de- ployed quickly and act as an interim measure, none of the conventional technologies meet our requirements of ade- quate security at low cost.

We thus propose an extension to the smartcard standard, based on a distance bounding protocol, which provides adequate resistance to the relay attack and requires minimal changes to smartcards.
Section 5 describes this countermeasure and its rela- tionship with prior work, describes a circuit design, and evaluates its performance and security properties.

We have implemented the protocol on an FPGA and shown it to be an effective defence against very capable ad- versaries.

In addition, the experience of both users and merchants is unchanged, a signiﬁcant advantage over the other proposals we discuss.

The impact of this protocol on the fraud liability landscape is discussed in Section 6.
Our contributions include the description of the prac- ticalities of relay attacks and our conﬁrmation that de- ployed systems are vulnerable to them.

By designing and testing a prototype system for demonstrating this vulner- ability, we show that the attack is feasible and an eco- nomically viable threat.

Also, we detail the design of a distance bounding protocol for smartcards, discuss im- plementation issues and present results from both nor- mal operation and under simulated attacks.
While papers have previously discussed distance bounding protocols, to the best of our knowledge, this is the ﬁrst time it has been implemented in practice.

2 Background Contact smartcards, also known as integrated circuit cards (ICC), as discussed in this paper, are deﬁned by ISO 7816 [19] (for brevity, our description of the spec- iﬁcation will be only to the detail sufﬁcient to illustrate our implementation).
The smartcard consists of a sheet of plastic with an integrated circuit, normally a special- ized microcontroller, mounted on the reverse of a group of eight contact pads.

Current smartcards use only ﬁve of these: ground, power, reset, clock are inputs supplied by the card reader, and an additional bi-directional asyn- chronous serial I/O signal over which the card receives commands and returns its response.
Smartcards are de- signed to operate at clock frequencies between 1 and 5 MHz, with the data rate, unless speciﬁed otherwise, of 1/372 of that frequency.

Upon insertion of a smartcard, the terminal ﬁrst sup- plies the power and clock followed by de-assertion of re- set.

The card responds with an Answer-to-Reset (ATR), selecting which protocol options it supports, including endianness and polarity, ﬂow control, error correction and data rate.
All subsequent communications are ini- tiated by the terminal and consist of a four byte header command with an optional variable-length payload.
2.1 Payment environment There are four parties in the basic payment model: the cardholder purchasing the goods or service; the mer- chant supplying the goods or service and who controls the payment terminal; the issuer bank is in a contractual relationship with the cardholder and issues their card, and; the acquirer bank that is in a contractual relation- ship with the merchant.
To initiate a transaction, the cardholder presents the merchant with his card and agrees to make the payment in exchange for goods or services.

The merchant vali- dates that the card is authentic and that the cardholder is authorized to use it, and sends the transaction details to the acquirer.

The acquirer requests transaction authoriza- tion from the issuer over a payment system network (e.g.

Mastercard or Visa).


If the issuer accepts the transaction, this response is sent back to the merchant via the acquirer and the cardholder is given the good or service.

Later, the payment is transferred from the cardholder’s account at the issuer to the merchant’s account at the acquirer.

In reality, payment systems slightly differ from this simpliﬁed description.
For this paper’s purpose, one no- table difference is that the merchant may skip the step of contacting the acquirer to verify the transaction.

For smaller retailers, this communication is ordinarily done via a telephone connection, so each authorization request incurs a cost.

Thus, for low-risk transactions it may not be necessary to go online.
Also, if the merchant’s ter- minal cannot make contact with the acquirer, due to the phone line being busy or other technical failure, the mer- chant may still decide to avoid losing the sale and never- theless accept the transaction.
2.2 Smartcard applications State-of-the-art smartcards are capable of both symmet- ric and asymmetric cryptography, have several hundreds of KB of non-volatile tamper-resistant memory, and through secure operating systems may support multiple, mutually un-trusting, applications [3].

Although the po- tential applications are many, they are most commonly used for authentication of the holder, and more speciﬁ- cally for debit and credit card payment systems, where less sophisticated smartcards are used.
Smartcards have advantages in all three authorization processes discussed above, namely: Card authentication: the card was issued by an accept- able bank, is still valid and the account details have not been modiﬁed.

Cardholder veriﬁcation: the customer presenting the card is authorized to use it.

Transaction authorization: the customer’s account has adequate funds for the transaction.
EMV [15], named after its creators, Europay, Master- card and Visa, is the primary protocol for debit and credit card payments in Europe, and is known by a variety of different names in the countries where it is deployed (e.g.

“Chip & PIN” in the UK).

While the following section will introduce the EMV protocol, other payment systems are similar.
In its non-volatile memory, the smartcard may hold ac- count details, cryptographic keys, a personal identiﬁca- tion number (PIN) and a count of how many consecutive times the PIN has been incorrectly entered.

Cards capable of asymmetric cryptography can cryp- tographically sign account details under the card’s pri- vate key to perform card authentication.
The merchant’s terminal can verify the signature with a public key which is stored on the card along with a certiﬁcate signed by the issuer whose key is, in turn, signed by the operator of the payment system network.

This method is known as dynamic data authentication (DDA) or the variant, com- bined data authentication (CDA).
As the merchants are not trusted with the symmetric keys held by the card, which would enable them to pro- duce forgeries, cards that are only capable of symmet- ric cryptography cannot be reliably authenticated ofﬂine.

However, the card can still hold a static signature of ac- count details and corresponding certiﬁcate chain.

The terminal can authenticate the card by checking this sig- nature, known as static data authentication (SDA), but the lack of freshness allows replay attacks to occur.
Cardholder veriﬁcation is commonly performed by re- quiring that the cardholder enter their PIN into the mer- chant’s terminal.

The PIN is sent to the card which then checks if there have been too many consecutive incor- rect guessing attempts; if not, it checks if the PIN was entered correctly.

If the terminal or card does not sup- port PIN veriﬁcation, or the cardholder declines to enter it, the merchant may allow signature veriﬁcation, or in unattended terminal scenarios, no authentication at all.
The card may hold a history of transactions since it has last communicated with the issuer, and evaluate the risk of authorizing further transactions ofﬂine; otherwise, the card can request online authorization.

In both cases, the card’s symmetric keys are used to produce a transaction certiﬁcate that is veriﬁed by the issuer.

Merchants may also force a transaction to be online.
2.3 Security goals and threat model The full threat model of EMV incorporates risk man- agement protocols where the card and terminal negotiate different methods of authenticating cardholders and the conditions for online or ofﬂine veriﬁcation.

This decision is reached by considering the transaction value and type (cash-back or goods), the card’s record of recent ofﬂine transactions and both the card issuer’s and merchant’s risk perception.
This complexity and other features of EMV exist to manage the reality of all parties mistrust- ing all others (to varying extents).

These details are out- side the scope of the paper and are further discussed in the EMV speciﬁcation [15, book 2].

Instead, we assume that the merchant, the banks and customers are honest.

We also exclude physical attacks, exploits of software vulnerabilities on both the smart- card and terminal, as well as attacks on the underlying cryptography.
Other weaknesses of the EMV system are known, such as replay attacks on SDA cards as discussed above, and fallback attacks which force use of the mag- netic stripe, still present on smartcards for backwards compatibility.

These weaknesses have been covered else- where [1, 4] and are anticipated to be resolved by even- tually disabling these legacy features.
In our scenario, the goal of the attacker is to obtain goods or services by charging an unwitting victim who thinks she is paying for something different, at an at- tacker controlled terminal.

3 Relay attacks Relay attacks were ﬁrst described by Conway [13, p75], explaining how someone who does not know the rules of chess could beat a Grandmaster.

This is possible by chal- lenging two Grandmasters at postal chess and relaying moves between them.
While appearing to play a good game, the attacker will either win against one, or draw against both.

Desmedt et al.

[14] showed how such re- lay attacks could be applied against a challenge-response payment protocol, in the so called “maﬁa fraud”.

We use the maﬁa-fraud scenario, illustrated in Fig- ure 1, where an unsuspecting restaurant patron, Alice, inserts her smartcard into a terminal in order to pay a $20 charge, which is presented to her on the display.
The terminal looks just like any one of the numerous types of terminals she has used in the past.

This par- ticular terminal, however, has had its original circuitry replaced by the waiter, Bob, and instead of being con- nected to the bank, it is connected to a laptop placed be- hind the counter.

As Alice inserts her card into the coun- terfeit terminal, Bob sends a message to his accomplice, Carol, who is about to pay $2 000 for a diamond ring at Dave’s jewellery shop.
Carol inserts a counterfeit card into Dave’s terminal, which looks legitimate to Dave, but conceals a wire connected to a laptop in her backpack.

Bob and Carol’s laptops are communicating wirelessly using mobile-phones or some other network.

The data to and from Dave’s terminal is relayed to the restaurant’s counterfeit terminal such that the diamond purchasing transaction is placed on Alice’s card.
The PIN entered by Alice is recorded by the counterfeit terminal and is sent, via a laptop and wireless headset, to Carol who en- ters it into the genuine terminal when asked.

When the transaction is over, the crooks have paid for a diamond ring using Alice’s money, who got her meal for free, but will be surprised when her bank statement arrives.

Despite the theoretical risk being documented, EMV is vulnerable to the relay attack, as suggested by Ander- son et al.

[4].
[4].

Some believed that engineering difﬁculties in deployment would make the attack too expensive, or even impossible.

The following section will show that Figure 1: The EMV relay attack.

Innocent customer, Alice, pays for lunch by entering her smartcard and PIN into a modiﬁed terminal operated by Bob.

At approximately the same time, Carol enters her fake card into honest Dave’s terminal to purchase a diamond.
The transaction from Dave’s terminal is relayed wirelessly to Alice’s card with the result of Alice unknowingly paying for Carol’s diamond.

equipment to implement the attack is readily available, and costs are within the expected returns of fraud.

uine one to the customer even though it lacks the ability to communicate with the bank.

3.1 Implementation 3.1.2 Counterfeit card This section describes the equipment we used for imple- menting the relay attack.
We chose off-the-shelf com- ponents that allowed for fast development rather than miniaturisation or cost-effectiveness.

The performance requirements were modest, with the only strict restriction being that our circuit hardware ﬁt within the terminal.

3.1.1 Counterfeit terminal Chip & PIN terminals are readily available for purchase online and their sale is not restricted.
While some are as cheap as $10, our terminal was obtained for $50 from eBay and was ideal for our purposes due to its copious in- ternal space.

Even if second hand terminals were not so readily available, a plausible counterfeit could be made from scratch as it is only necessary that it appears legiti- mate to untrained customers.
Instead of reverse engineering the existing circuit, we stripped all internal hardware except for the keypad and LCD screen, and replaced it with a $200 Xilinx Spartan- 3 small factor, USB-controlled, development board.

We also kept the original smartcard reader slot, but wired its connections to a $40 USB GemPC Twin reader so we could connect it to the laptop.

The result is a terminal with which we can record keypad strokes, display con- tent on the screen and interact with the inserted smart- card.
The terminal appears and behaves just like a gen- At the jeweller’s, Carol needs to insert a counterfeit card connected to her laptop, into Dave’s terminal.

We took a genuine Chip & PIN card and ground down the resin- covered wire bonds that connect the chip to the back of the card’s pads.

With the reverse of the pads exposed, using a soldering iron, we pressed into the plastic thin, ﬂat wires to the edge of the card.
This resulted in a card that looked authentic from on the top side, but was actu- ally wired on the back side, as shown in Figure 2.

The counterfeit card was then connected through a 1.5 m ca- ble to a $150 Xilinx Spartan-3E FPGA Starter Kit board to buffer the communications and translate them between the ISO 7816 and RS-232 protocols.

Since the FPGA is not 5V tolerant, we use 390 Ω resistors on the channels that receive data from the card.
For the bi-directional I/O channel, we use the Maxim 1740/1 level translator, which costs less than $2.

3.1.3 Controlling software The counterfeit terminal and card are controlled by sepa- rate laptops via USB and RS-232 interfaces, respectively, using custom software written in Python.

The laptops communicate via TCP over 802.11b wireless, although in principle this could be GSM or other wireless pro- tocol.
This introduces signiﬁcant latency, but far less than would be a problem as the timing critical operations BobCarolAliceDave£$2,000PINPIN$20Attacker controlledAttacker controlled (a) With the exterior intact, the terminal’s original internal circuitry was replaced by a small factor FPGA board (left); FPGA based smartcard emulator (right) connected to counterfeit card (front).

(b) Customer’s view of terminal.

Here, it is playing Tetris, to demonstrate that we have full control of the display and keypad.
Figure 2: Photographs of tampered terminal and counterfeit card.

on the counterfeit card are performed by the FPGA with real-time guarantees.

One complication of selecting an off-the-shelf USB smartcard reader for the counterfeit terminal is that it op- erates at the application protocol data unit (APDU) level and buffers an entire command or response before send- ing it to the smartcard or the PC.
This increases the time between when the genuine terminal sends a command and when the response can be sent; but, as previously mentioned, this is well within tolerances.

This paper only deals with the “T=0” ISO 7816 sub- protocol, as used by all EMV smartcards we have exam- ined.

Here, commands are uni-directional, i.e.

either the command or response contains a payload but not both.
Upon receiving a command code from the genuine ter- minal, any associated payload will not be sent by the ter- minal until the card acknowledges the command.

The counterfeit card thus cannot tell whether to request a pay- load (for terminal → card commands) or send the com- mand code to the genuine card immediately (for card → terminal commands).
Were the counterfeit terminal to incorporate a charac- ter level card reader, the partial command code could be sent to the genuine card and the result examined to determine the direction, but this is not permissible for APDU level transactions.

Hence, the controlling soft- ware must be told the direction for each of the 14 com- mand codes.

Other than this detail, the relay attack is protocol-agnostic and could be deployed against any ISO 7816 based system.
3.2 Procedure and timing EMV offers a large variety of options, but the generality of the relay attack allows our implementation to account for them all; for simplicity, we will describe the proce- dure for the common case in the UK.
That is, SDA card authentication (only the static cryptographic signature of the card details is checked), online transaction autho- rization (the merchant will connect to the issuer to ver- ify that adequate funds are available) and ofﬂine plaintext PIN cardholder veriﬁcation (the PIN entered by the card- holder is sent to the card, unencrypted, and the card will check its correctness).
Transaction authorization is accomplished by the card generating an application cryptogram (AC), which is au- thenticated by the card’s symmetric key and incorpo- rates transaction details from the terminal, a card transac- tion counter, and whether the PIN was entered correctly.

Thus, the issuing bank can conﬁrm that the genuine card was available and the correct PIN was used.

Note that this only requires symmetric cryptography, and so will work even with SDA-only cards, as issued in the UK.
The protocol can be described in six steps: Initialization: The card is powered up and returns the ATR.

Then the terminal selects one of the possible payment applications offered by the card.

Read application data The terminal requests card de- tails (account number, name, expiration date etc.)

and veriﬁes the static signature.

Cardholder veriﬁcation: The cardholder enters their PIN into the merchant’s terminal and this is sent to the card for veriﬁcation.
If correct, the card returns a success code, otherwise the cardholder may try again until the maximum number of PIN attempts have been exceeded.

Generate AC 1: The terminal requests an authorization request cryptogram (ARQC) from the card, which is sent to the issuing bank for veriﬁcation, which then responds with the issuer authentication data.

External authenticate: The terminal sends the issuer authentication data to the card.
Generate AC 2: The terminal asks the card for a trans- action certiﬁcate (TC) which the card returns to the terminal if, based on the issuer authentication data and other internal state, the transaction is approved.

Otherwise, it returns an application authentication cryptogram (AAC), signifying the transaction was denied.

The TC is recorded by the merchant to demonstrate that it should receive the funds.

This ﬂow imposes some constraints on the relay at- tack.
Firstly, Alice must insert her card before Carol in- serts her counterfeit card in order for initialization and read application data to be performed.

Secondly, Al- ice must enter her PIN before Carol is required to en- ter it into the genuine terminal.

Thirdly, Alice must not remove her card until the Generate AC 2 stage has oc- curred.

Thus, the two sides of the radio link must be synchronised, but there is signiﬁcant leeway as Carol can stall until she receives the signal to insert her card.
After that point, the counterfeit card can request extra time from the terminal, before sending the ﬁrst response, by sending a null procedure byte (0x60).

The counter- feit terminal can also delay Alice by pretending to dial- up the bank and waiting for authorization until Carol’s transaction is complete.
All timing critical sections, such as sending the ATR in response to de-assertion of reset and the encod- ing/decoding of bytes sent on the I/O, are implemented on the FPGA to ensure a fast enough response.

There are wide timing margins between the command and re- sponse, so this is managed in software.

3.3 Results We tested our relay setup with a number of different smartcard readers in order to test its robustness.
Firstly, we used a VASCO Chip Authentication Program (CAP) reader (a similar device, but manufactured by Gemalto, is marketed by the UK bank Barclays as PINsentry).

This is a handheld one-time-password generator for use in on- line banking, and implements a subset of the EMV pro- tocol.

Speciﬁcally, it performs cardholder veriﬁcation by checking the PIN and requests an application cryp- togram, which may be validated online.
Our relay setup was able to reliably complete transactions, even when we introduced an extra three seconds of latency between command and response.

While the attack we describe in most detail uses the counterfeit card in a retail out- let, a fraudster could equally use a CAP reader to access the victim’s online banking.

This assumes that the PIN used for CAP is the same as for retail transactions and the criminal knows all other login credentials.
The CAP reader uses a 1 MHz clock to decrease power consumption, but at the cost of slower transactions.

We also tested our relay setup with a GemPC Twin reader, which operates at a 4 MHz frequency.

The card reader was controlled by our own software, which simulates a Chip & PIN transaction.

Here, the relay device also worked without any problems and results were identical to when the card was connected directly to the reader.
Finally, we developed a portable version of the equip- ment, and took this to a merchant with a live Chip & PIN terminal.

With the consent of the merchant and card- holder, we placed a transaction with our counterfeit card in the genuine terminal, and the cardholder’s card in the counterfeit terminal.

In addition to the commands and re- sponses being relayed, the counterfeit terminal was con- nected to a laptop which, through voice-synthesis soft- ware, read out the PIN to our “Carol”.
The transaction was completed successfully.

One such demonstration of our equipment was shown on the UK consumer rights programme BBC Watchdog on 6th February 2007.

3.4 Further applications and feasibility The relay attack is also applicable where “Alice” is not the legitimate card holder, but a thief who has stolen the card and observed the PIN.

To frustrate legal investiga- tion and fraud detection measures, criminals commonly use cards in a different country from where they were stolen.
Magnetic stripe cards are convenient to use in this way, as the data can be read and sent overseas, to be written on to counterfeit cards.

However, chip cards cannot be fully duplicated, so the physical card would need to be mailed, introducing a time window where the cardholder may report the card stolen or lost.

The relay attack can allow fraudsters to avoid this de- lay by making the card available online using a card reader and a computer connected to the Internet.
The fraudster’s accomplice in another country could connect to the card remotely and place transactions with a coun- terfeit one locally.

The timing constraints in this sce- nario are more relaxed as there is no customer expecting to remove their genuine card.

Finally, in certain types of transactions, primarily with unattended terminals, the PIN may not be required, making this attack easier still.
APACS, the UK payment association, say they are un- aware of any cases of relay attacks being used against Chip & PIN in the UK [5].

The reason, we believe, is that even though the cost and the technical expertise that are required for implementing the attack are relatively low, there are easier ways to defeat the system.

Methods such as card counterfeiting/theft, mail interception, and cardholder impersonation are routinely reported and are more ﬂexible in deployment.
These security holes are gradually being closed, but card fraud remains a lucrative industry – in 2006 £428m (≈ $850m) of fraud was suffered by UK banks [6].

Crim- inals will adapt to the new environment and, to maintain their income, will likely resort to more technically de- manding methods, so now is the time to consider how to prevent relay attacks for when that time arrives.
4 Defences The previous section described how feasible it is to de- ploy relay attacks against Chip & PIN and other smart- card based authorization systems in practice.

Thus, sys- tem designers must develop mitigation techniques while, for economic consideration, staying within the deployed EMV framework as much as possible.

4.1 Non-solutions In this section we describe a number of solutions that are possible, or have been proposed, against our attack and assess their overall effectiveness.
Tamper-resistant terminals A pre-requisite of our re- lay attack is that Alice will insert her card and enter her PIN into a terminal that relays these details to the re- mote attacker.

The terminal, therefore, must either be tampered with or be completely counterfeit, but still ac- ceptable to cardholders.

This implies a potential solution – allow the cardholder to detect malicious terminals so they will refuse to use them.

Unfortunately, this cannot be reliably done in practice.
Although terminals do implement internal tamper- responsive measures, when triggered, they only delete keys and other data without leaving visible evidence to the cardholder.

Tamper-resistant seals could be inspected by customers, but Johnston et al.

[21] have shown that many types of seals can be trivially bypassed.

It would also be infeasible to give all customers adequate training to detect tampering or counterfeiting of seals.
By induc- ing time-pressure and an awkward physical placement of the terminal, the attacker can make it extremely difﬁcult for even a diligent customer to check for tampering.

Even if it was possible to produce an effective seal, there are, as of May 2007, 304 VISA approved terminal designs from 88 vendors [24], so cardholders cannot be expected to identify them all.
Were there only one termi- nal design, the use of counterfeit terminals would have to be prevented, which raises the same problems as tamper- resistant seals.

Finally, with the large sums of money netted by criminals from card fraud, fabricating plastic parts is well within their budget.
Imposing additional timing constraints While relay attacks will induce extra delays between commands be- ing sent by the terminal and responses being received, existing smartcard systems are tolerant to very high la- tencies.

We have successfully tested our relay device after introducing a three second delay into transactions, in addition to the inherent delay of our design.

This extra round-trip time could be exploited by an attacker 450 000 km away, assuming that signals propagate at the speed of light.
Perhaps, then, attacks could be prevented by requiring that cards reply to commands precisely af- ter a ﬁxed delay.

Terminals could then conﬁrm that a card responds to commands promptly and will otherwise reject a transaction.

Other than the generate AC command, which includes a terminal nonce, the terminal’s behaviour is very pre- dictable.

So an attacker could preemptively request these details from the genuine card then send them to the coun- terfeit card where they are buffered for quick response.
Thus, the value of latency as a distance measure can only be exploited at the generate AC stages.

Furthermore, Clulow et al.

[12] show how wireless distance bounding protocols, based on channels which were not designed for the purpose, can be circumvented.

Their comments apply equally well to wired protocols such as ISO 7816.

To hide the latency introduced by mounting the re- lay attack, the attacker aims to sample signals early and send signals late, while still maintaining their accuracy.
In ISO 7816, cards and terminals are required to sample the signal between the 20% and 80% portion of the bit- time and aim to sample at the 50% point.

However, an attacker with sensitive equipment could sample near the beginning, and send their bit late.

The attacker then gains 50% of a bit-width in both directions, which at a 5 MHz clock is 37 µs, or 11 km.

The attacker could also over-clock the genuine card so the responses are returned more quickly.
A DES calcu- lation could take around 100 ms so only a 1% increase would give a 300 km distance advantage.

Even if the calculation time was ﬁxed, and only receiving the re- sponse from the card could be accelerated, the counter- feit card could preemptively reply with the predictable 11 bytes (2 byte response code, 5 byte read more com- mand, 2 byte header and 2 byte counter) each taking 12 bit-widths (start, 8 data bits, stop and 2 bits guard time).

At 5 MHz + 1% this gives the attacker 98 µs, i.e.


29 km.

One EMV-speciﬁc problem is that the contents of the payload in the generate AC command are speciﬁed by the card in the card risk management data object list (CDOL).

Although the terminal nonce should be at the end of the message in order to achieve maximum resis- tance to relay attacks, if the CDOL is not signed, the at- tacker could substitute the CDOL for one requesting the challenge near the beginning.
Upon receiving the chal- lenge from the terminal, the attacker can then send this to the genuine card.

Other than the nonce, the rest of the generate AC payload is predictable, so the counterfeit terminal can restore the challenge to the correct place, ﬁll in the other ﬁelds and send it to the genuine card.

Thus, the genuine card will send the correct response, even before the terminal thinks it has ﬁnished sending the command.
A payload will be roughly 30 bytes, which at 5 MHz gives 27 ms and a 8 035 km distance advantage.

Nevertheless, eliminating needless tolerance to re- sponse latency would decrease the options available to the attacker.

If it were possible to roll out this modiﬁca- tion to terminals as a software upgrade, it might be ex- pedient to plan for this alteration to be quickly deployed in reaction to actual use of the relay attack.
While we have described how this countermeasure could be cir- cumvented, attackers who build and test their system with high latency would be forced to re-architect it if the acceptable latency of deployed terminals were decreased without warning.

tampered.

For these to match, the fraudster must have appropriate blank cards and an embossing machine, in addition to knowing the victim’s card number in advance.
Alternatively, a close to real-time attack could still be executed with a portable embossing machine.

Existing devices take only a few seconds to print a card and it is feasible that fraudsters can make them portable.

The quality of counterfeit cards and embossing need not be high, just sufﬁcient to pass a cursory inspection.

More recent smartcards are being issued without embossing, as the carbon-paper payment method is no longer used, making counterfeits even easier to produce.
If none of these possibilities are open to the fraudster, repeat cus- tomers could be targeted and so creating a wide window of opportunity.

In some scenarios, such as unattended Chip & PIN terminals, ATMs, or where the terminal is on the opposite side of a glass barrier, physical card in- spections would not be possible; but even where it is, the merchant must be diligent.
Varian [23] argues that if the party who is in the best position to prevent fraud does not have adequate incen- If customers must de- tives to do so, security suffers.

pend on merchants, who they have no relationship with, for their protection, then there are mismatched incen- tives.

Merchants selling low-marginal-cost products or services (e.g.

software or multimedia content), have little desire to carefully check for relay attacks.
This is be- cause, in the case of fraud, costs will likely be borne by the customer.

Even if the transaction is subsequently re- versed when fraud is detected, the merchant has lost only the low marginal cost and the chargeback overhead, but has saved the effort of checking cards.
4.2 Procedural improvements 4.3 Hardware alterations Today, merchants and till operators are accustomed to looking away while customers enter their PIN and sel- dom handle the card at all, while customers are often rec- ommended not to allow anyone but themselves to handle the card because of card skimming.

In the case of relay attacks, this assists the criminal, not the honest customer or merchant.
If the merchant examined the card, even superﬁcially, he would detect the relay attack, as we im- plemented it, by spotting the wires.

That said, it is not in- feasible that an RFID proximity card could be modiﬁed to relay data wirelessly to a local receiver and therefore appear to be a genuine one.
A stronger level of protection can be achieved if, af- ter the transaction is complete, the merchant checks not only that the card presented is legitimate, but also that the embossed card number matches the one on the receipt.
In the case of the relay attack, the receipt will show the victim’s card number, whereas the counterfeit card will show the original number of the card from before it was The electronic attorney is a trusted device that is brought into the transaction by the customer so that the mer- chant’s terminal does not need to be trusted; this is called the “man-in-the-middle defence”, as suggested by An- derson and Bond [2]; trusted devices to protect customers are also discussed by Asokan et al.

[7].
[7].

The device is in- serted into the terminal’s card slot while the customer inserts their card into the device.

The device can display the transaction value as it is parsed from the data sent from the terminal, allowing the customer to verify that she is charged the expected amount.

If the customer ap- proves the transaction, she presses a button on the elec- tronic attorney itself, which allows the protocol to pro- ceed.
This trusted user interface is necessary, since if a PIN was used as normal, a fraudster could place a legiti- mate transaction ﬁrst, which is accepted by the customer, but with knowledge of the PIN a subsequent fraudulent one can be placed.

Alternatively, one-time-PINs could be used, but at a cost in usability.

Because the cardholder controls the electronic attor- ney, and it protects the cardholder’s interests, the incen- tives are properly aligned.
Market forces in the business of producing and selling these devices should encourage security improvements.

However, this extra device will increase costs, increase complexity and may not be ap- proved of by banking organizations.

Additionally, fraud- sters may attempt to discourage their use, either explic- itly or by arranging the card slot so the use of a electronic attorney is difﬁcult.

A variant of the trusted user interface is to integrate a display into the card itself [8].
Another realization of the trusted user interface for payment applications is to integrate the functionality of a smartcard into the customer’s mobile phone.

This can allow communication with the merchant’s terminal using near ﬁeld communications (NFC) [20].
This approach is already under development and has the advantage of being a customer-controlled device with a large screen and convenient keypad, allowing the merchant’s name and transaction value to be shown and once authorized by the user, entry of the PIN.

Wireless communications also ease the risk of a malicious merchant arranging the terminal so that the trusted display device is not visible.
Although mobile phones are affordable and ubiquitous, they may still not be secure enough for payment applica- tions as they can be, for example, targeted by malware.

5 Distance bounding None of the techniques detailed in Section 4.1 are ad- equate to completely defeat relay attacks.

They are ei- ther impractical (tamper-resistant terminals), expensive (adding extra hardware) or circumventable (introduc- ing tighter timing constraints and requiring merchants to check card numbers).
Due to the lack of a customer- trusted user interface on the card, there is no way to de- tect a mismatch between the data displayed on the termi- nal and the data authorized by the card.

However, relay attacks can be foiled if either party can securely establish the position of the card which is authorizing the transac- tion, relative to the terminal processing it.
Absolute positioning is infeasible due to the cost and form factor requirements of smartcards being incompat- ible with GPS, and also because the civilian version is not resistant to spooﬁng [22].

However, it is possible for the terminal to securely establish a maximum dis- tance bound, by measuring the round-trip-time between it and the smartcard; if this time is too long, an alarm would be triggered and the transaction refused.
De- spite the check being performed at the merchant end, the incentive-compatibility problem is lessened because the distance veriﬁcation is performed by the terminal and does not depend on the sales assistant being diligent.

The approach of preventing relay attacks by mea- suring round-trip-time was ﬁrst proposed by Beth and Desmedt [9] but Brands and Chaum [11] described the ﬁrst concrete protocol.
The cryptographic exchange in our proposal is based on the Hancke-Kuhn protocol [17], because it requires fewer steps, and it is more efﬁcient if there are transmission bit errors compared to Brands- Chaum.

However, the Hancke-Kuhn protocol is pro- posed for ultra-wideband radio (UWB), whereas we re- quire synchronous half-duplex wired transmission.
One characteristic of distance-bounding protocols, un- like most others, is that the physical transmission layer is security-critical and tightly bound to the other layers, so care must be taken when changing the transmission medium.

Wired transmission introduces some differ- ences, which must be taken into consideration.

Firstly, to avoid circuitry damage or signal corruption, in a wired half duplex transmission, contention (both sides driving the I/O at the same time) must be avoided.
Secondly, whereas UWB only permits the transmission of a pulse, wired allows a signal level to be maintained for an ex- tended period of time.

Hence, we may skip the initial distance-estimation stage of the Hancke-Kuhn setup and simplify our implementation.

While in this section we will describe our implemen- tation in terms of EMV, implemented to be compatible with ISO 7816, it should be applicable to any wired, half- duplex synchronous serial communication line.
5.1 Protocol In EMV, authentication is only card to terminal so we follow this practise.

Following the Hancke-Kuhn termi- nology, the smartcard is the prover, P , and terminal is the veriﬁer, V .

This is also appropriate because the Hancke- Kuhn protocol puts more complexity in the veriﬁer than the prover, and terminals are several orders of magnitude more expensive and capable than the cards.
The protocol is described as follows: Initialization : V → P : NV ∈ {0, 1}a P → V : NP ∈ {0, 1}a (R0 i ||R1 Rapid bit-exchange : V → P : Ci ∈ {0, 1} P → V : RCi i ∈ {0, 1} P : i ) = HK(NV , NP ) ∈ {0, 1}b At the start of the initialization phase, nonces and pa- rameters are exchanged over a reliable data channel, with timing not being critical.
NV and NP provide fresh- ness to the transaction in order to prevent replay attacks, with the latter preventing a middle-man from running the complete protocol twice between the two phases using the same NV and complementary Ci and thus, obtain 8 3 6 A D F Ci : 1010 0011 1000 1111 0110 1101 0111 0101 R0 i : x0x0 11xx x011 xxxx 0xx1 xx1x 1xxx 1x0x R1 i : 1x0x xx10 1xxx 0001 x10x 01x0 x111 x1x0 RCi : 1000 1110 1011 0001 0101 0110 1111 1100 i 7 5 8 E B 1 5 6 F C Table 1: Example of the rapid bit-exchange phase of the distance bounding protocol.
For clarity, x is shown in- stead of the response bits not sent by the prover.

The left most bit is sent ﬁrst.

i and R1 both R0 i .

The prover produces a MAC under its key, K, using a keyed pseudo-random function, the result of which is split into two shift registers, R0 i and R1 i .

In the timing-critical rapid bit-exchange phase, the maximum distance between the two participants is deter- mined.
V sends a cryptographically secure pseudoran- dom single-bit challenge Ci to P , which in turn imme- diately responds with RCi , the next single-bit response, i from the corresponding shift register.

A transaction of a 32 bit exchange is shown in Table 1.
If a symmetric key is used, this will require an on-line transaction to verify the result because the terminal does not store K. If the card has a private/public key pair, a session key can be established and the ﬁnal challenge- response can also be veriﬁed ofﬂine.

The values a and b, the nonce and shift register bit lengths, respectively, are security parameters that are set according to the applica- tion and are further discussed in Section 5.5.
This exchange succeeds in measuring distance be- cause it necessitates that a response bit arrive at a certain time after the challenge has been sent.

When the proto- col execution is complete, V ’s response register, RCi , is i veriﬁed by the terminal or bank to determine if the prover is within the allowed distance for the transaction.
5.2 Implementation ISO 7816, our target application, dictates that the smart- card (prover) is a low resource device, and therefore, should have minimal additions in order to keep costs down; this was our prime constraint.

The terminal (ver- iﬁer), on the other hand, is a capable, expensive de- vice that can accommodate moderate changes and addi- tions without adversely affecting its cost.
Of course, the scheme must be secure to all attacks devised by a highly capable adversary that can relay signals at the speed of light, is able to ensure perfect signal integrity, and can clock the smartcard at higher frequencies than it was de- signed for.

We assume, however, that this attacker does not have access to the internal operation of the terminal Figure 3: Waveforms of a single bit-exchange of the distance bounding protocol.
fV is the veriﬁer’s clock; DRVC drives the challenge on to I/O; SMPLR samples the response; CLKV →P is the prover’s clock; I/OV and I/OP are versions of the I/O on each side accounting for the propagation delay td; SMPLC is the received clock that is used to sample the challenge; and DRVR drives the response on to the I/O.

and that extracting secret material out of the smartcard, or interfering with its security critical functionality, is not economical considering the returns from the fraud.
5.3 Circuit elements and signals For this section refer to Table 2 for signal names and their function, Figure 4 for the circuit diagram and Figure 3 for the signal waveforms.

Clocks and frequencies As opposed to the prover, the veriﬁer may operate at high frequencies.

We have im- plemented the protocol such that one clock cycle of the veriﬁer’s operating frequency, fV , determines the dis- tance resolution.
Since signals cannot travel faster than the speed of light, c, the upper-bound distance resolution is therefore, c/fV .

Thus, fV , should be chosen to be as high as possible.

We selected 200 MHz which allows us a 1.5 m resolution under ideal conditions for the at- tacker.
We have made the prover’s operating frequency, fP , compatible with any frequencies having a high-time −1 + td, where tq deﬁnes the time greater than tq + fV between when the challenge is being driven onto the I/O and when the response is sampled by the veriﬁer; td is the delay between V and P .

ISO 7816 speciﬁes that the smartcard/prover needs to operate at 1–5 MHz and in order to be compatible, we chose fP = fV /128 ≈ 1.56 MHz for our implementation.
Shift registers The design has four 64 bit shift regis- ters (SR): the veriﬁer’s challenge and received response SR’s and the prover’s two response SR’s.
The challenge SMPLCtntmtpdelayCiCiRiRiI/OVI/OPtdfVCLKV PDRVRtqDRVCSMPLRtdverifierprover Signals & timing parameters Description CLKV , fV CLKV →P , fP DRVC tn SMPLC tm DRVR tp SMPLR tq td Veriﬁer’s clock and frequency; determines the distance resolution Prover’s clock and frequency; received from veriﬁer While asserted the challenge is transmitted Length of time veriﬁer drives the challenge on to the I/O Prover samples challenge on rising edge Length of time between assertion of DRVC to assertion of CLKV →P Prover transmits response Amount of delay applied to SMPLC Veriﬁer samples response on rising edge Time from assertion of CLKV →P to rising edge of SMPLR; determines upper bound of prover’s distance Propagation delay through distance d Table 2: Signals and their associated timing parameters.
Figure 4: Simpliﬁed diagram of the distance bounding circuit.

DRVC controls when the challenge is put on the I/O line.

CLKV controls the veriﬁer’s circuit; it is divided and is received as SMPLC at the prover where it is used to sample the challenge.

A delay element produces DRVR, which controls when the response is put the I/O, while at the veriﬁer SMPLR samples it.

The pull-up resistor R is present to pull the I/O line to a stable state when it is not actively driven by either side.
SR is clocked by CLKV and is shifted one clock cycle before it is driven on to the I/O line by DRVC.

The veri- ﬁer’s response SR is also clocked by CLKV and is shifted on the rising edge of SMPLR.

On the prover side, the SR’s are clocked and shifted by SMPLC.

not driven by either side.

As a side note, if the con- straints imposed by ISO 7816 are not to be adhered to, two uni-directional wires for the challenge and response could have been used for easier implementation.
Bi-directional I/O The veriﬁer and prover communi- cate using a bi-directional I/O with tri-state buffers at each end.

These buffers are controlled by the signals DRVC and DRVR and are implemented such that only one side drives the I/O line at any given time in order to prevent contention.

This is a consequence of adapting the Hancke-Kuhn protocol to a wired medium, and im- plies that the duration of the challenge must be no longer than necessary, so as to obtain the most accurate distance bound.
A pull-up is also present, as with the ISO 7816 speciﬁcation, to maintain a high state when the line is 5.4 Timing A timing diagram of a single challenge-response ex- change is shown in Figure 3.

The circuit shown in Fig- ure 4 was implemented on an FPGA using Verilog (not all peripheral control signals are shown for the sake of clarity).
Since we used a single chip, the I/O and clock lines were “looped-back” using various length transmis- sion wires to simulate the distance between the veriﬁer and prover as shown in Figure 5.

The ﬁrst operation is clocking the challenge shift reg- ister (not shown), which is driven on to the I/O line by verifierproverSMPLCDRVRdelayR0R1response SRchallenge SRSMPLRDRVCdivideCLKVdresponse SR’schallengeCECE01CLKV PR tp + 2td.
As an improvement, tq can be dynamically ad- justed between invocations of the protocol allowing the veriﬁer to make decisions based on the measured dis- tance, for example, determine the maximum transaction amount allowed.

With a single iteration, the veriﬁer can discover the prover’s maximum distance away, but with multiple iterations, the exact distance can be found with a margin of error equal to the signal propagation time during a single clock cycle of the veriﬁer.
SMPLR may be made to sample on both rising and falling edges of fV , effectively doubling the distance resolution without increasing the frequency of operation (other signals may operate this way for tighter timing margins).

If we assume that an attacker can transmit signals at the speed of light and ignore the real-life implications of sending them over long distances, we can determine the theoretical maximum distance between the veriﬁer and prover.
A more realistic attacker will need to overcome signal integrity issues that are inherent to any system.

We should not, therefore, make it easy for the attacker by designing with liberal timing constraints, and choose the distance between the veriﬁer and prover, d, to be as short as possible.

More importantly, we should carefully design the system to work for that particular distance with very tight margins.
For example, the various termi- nals we have tested were able to transmit/drive a signal through a two meter cable, although the card should at most be a few centimeters away.

Weak I/O drivers could be used to degrade the signal when an extention is ap- plied.

The value of d also determines most of the timing parameters of the design, and as we shall see next, the smaller these are, the harder it will be for the attacker to gain an advantage.
5.5 Possible attacks on distance bounding Although, following from our previous assumptions, the attacker cannot get access to any more than half the re- sponse bits, there are ways he may extend the distance limit before a terminal will detect the relay attack.

This section discusses which options are available, and their effectiveness in evading defences.

Guessing attack Following the initialization phase, the attacker can initiate the bit-exchange phase before the genuine terminal has done so.
As the attacker does not know the challenge at this stage, he will, on average, guess 50% of the challenge bits correctly and so receive the correct response for those.

For the ones where the challenge was guessed incorrectly, the response is effec- tively random, so there is still a 50% chance that the re- sponse will be correct.

Therefore the expected success rate of this technique is 75%.
Figure 5: The Xilinx XUP board with a VirtexII-PRO 30 FPGA on which the distance bounding design was imple- mented.

Both veriﬁer and prover reside on the same chip connected only by two same-length tranmission lines for I/O and clock (1 m shielded cables are shown).

DRVC on the following fV clock cycle for a tn period.
tn should be made long enough to ensure that the prover can adequately and reliably sample the challenge, and as short as possible to allow the response to be rapidly sent while not causing contention.

The clock sent to P , CLKV →P , is asserted tm after the rising edge of DRVC.

Both CLKV →P and the I/O line have the same propa- gation delay, td, and when the clock edge arrives (now called SMPLC), it samples the challenge.
The same clock edge also shifts the two response registers, one of which is chosen by a 2:1 multiplexer that is controlled by the sampled challenge.

DRVR is a delayed replica of SMPLC, which is created using a delay element.

The delay, tp, allows the response SR signals to shift and propagate through the multiplexer, preventing the in- termediate state of the multiplexer from being leaked.

Otherwise, the attacker could discover both responses to the previous challenge in the case where Ci 6= Ci−1.
tp may be very short but should be at least as long as the period from the rising edge of SMPLC to when the response emerges from the multiplexer’s output; in our implementation, we used deliberately placed routing de- lays to adjust tp, which can be as short as 500 ps.

When DRVR is asserted, the response is being driven on to the I/O line until the falling edge.

At the veriﬁer, the response is sampled by SMPLR after tq from the assertion of CLKV →P .
The value of tq determines the distance measured and should be long enough to account for the propagation delay that the sys- tem was designed for (including on-chip and package de- lays), and short enough to not allow an attacker to be fur- ther away than desired, with the minimum value being Since our tests show a negligible error rate, the termi- nal may reject any response with a single bit that is incor- rect.
In our prototype, where the response registers are 64 bits each, the attacker will succeed with probability ( 3 ≈ 1 in 226.

The size of the registers is a security 4 ) parameter that can be increased according to the applica- tion, while the nonces assure that the attacker can only guess once.
64 Replay If the attacker can force the card to perform two protocol runs, with the same nonces used for both, then all bits of the response can be extracted by sending all 1’s on the ﬁrst iteration and all 0’s on the second.

We resist this attack by selecting the protocol variant men- tioned by Hancke and Kuhn [17], where the card adds its own nonce.

This is cheap to do within EMV since a transaction counter is already required by the rest of the protocol.
If this is not desired then provided the card cannot be clocked at twice its intended frequency, the at- tacker will not be able to extract all bits in time.

This as- sumes that the time between starting the distance bound- ing protocol, and the earliest time the high-speed stage can start, is greater than the latter’s duration.

Early bit detection and deferred bit signalling The card will not sample the terminal’s challenge until tm+d after the challenge is placed on the I/O line.
This is to al- low an inexpensive card to reliably detect the signal but, as Clulow et al.

[12] suggest, an attacker who is willing to invest in expensive equipment could, in theory, detect the signal immediately.

By manipulating the clock pro- vided to the genuine card, and using high-quality signal drivers, the challenge could be sent to the card with less of a delay.
Similarly, the terminal will wait tq between sending the challenge and sampling the response, to allow for the round trip signal propagation time, and wait until the re- sponse signal has stabilized.

Again, with superior equip- ment the response could be sent from the card just before the terminal samples.

The attacker, however, cannot do so any earlier than tp after the card has sampled the chal- lenge, and the response appears on the I/O.
Delay-line manipulation The card may include the value of tp in its signed data, so the attacker cannot make the terminal believe that the value is larger than the card’s speciﬁcation.

However, the attacker might be able to re- duce the delay, for example by cooling the card.

If it can be reduced to the point that the multiplexer or latch has not settled, then both potential responses may be placed on to the I/O line, violating our assumptions.
However, if the circuit is arranged so that the delay will be reduced only if the reaction of the challenge latch and multiplexer is improved accordingly, the response will still be sent out prematurely.

This gives the attacker extra time, so should be prevented.

If temperature com- pensated delay lines are not economic, then they should be as short as possible to reduce this effect.

In fact, tp may be so small, even less than 1 ns, that the terminal could just assume it would be zero.
This will mean that the terminal will believe all cards are slightly further away than they really are, but will avoid the value of tp having to be included in the signed data.

Combined attacks For an attacker to gain a better than 1 in 226 probability of succeeding in the challenge re- sponse protocol, the relay attack must take less than tm+q time.
In practice, an attacker will not be able to sample or drive the I/O line instantaneously and the radio-link transceiver or long wires will introduce la- tency, so the attacker would need to be much closer than this limit.

A production implementation on an ASIC would be able to give better security guarantees and be designed to tighter speciﬁcations than were available on the FPGA for our prototype.
5.6 Results We have developed a versatile implementation that re- quires only modest modiﬁcation to currently deployed designs.

Our distance bounding scheme was success- fully implemented and tested on an FPGA for 2.0, 1.0, and 0.3 meter transmission lengths, although it can be modiﬁed to work for any distance and tailored to any end application.

Oscilloscope traces of a single bit challenge- response exchange over a 50 Ω, 30 cm printed circuit board transmission line are shown in Figure 6.
In this case, the challenge is 1 and the response is 0 with indica- tors where SMPLR has sampled the response.

The ﬁrst, after tqfail = 15 ns has sampled too early while the sec- ond, tqpass = 20 ns, which is a single period of fV later, has correctly sampled the 0 as the response.

The delay td = 2.16 ns, can also be seen and is, of course, due to the length of the transmission line.
If the attacker ex- ploited all possible attacks previously discussed and was able to transmit signals at c, he would need to be within approximately 6 m, although the actual distance would be shorter for a realistic attacker.
5.7 Costs The FPGA design of both the veriﬁer and prover as shown in Figure 5 consumes 37 ﬂip-ﬂops and 93 look- up tables: 64 for logic, 13 route-throughs, and 16 as shift registers (4 cascaded 16-bit LUTs for each), which is extremely compact, and consumes well under 0.5% of the resources available on our FPGA.

However, it is (a) I/OV trace of a 64-bit exchange with position of (b) indicated by • on the x axis.

(b) Single bit exchange, challenge is 1 and response is 0.
Figure 6: Oscilloscope trace from the bit-exchange phase of the distance bounding protocol.

Delay is introduced by a 30 cm transmission line between the veriﬁer and prover.

Timing parameters are tn = 10 ns, tm = 5 ns, tp = 8 ns.

Two values of tq are shown, one where the bit was correctly received tqpass = 20 ns and one where it was not, tqfail = 15 ns.

td was measured to be 2.16 ns which over a 30 cm wire corresponds to propagation velocity of 1.4 × 108 m/s.
Note that before the challenge is sent, the trace is slowly rising above ground level; this is the effect of the pull-up resistor as also seen in (a) after the protocol completes.

The shown signals were probed at the FPGA I/Os and do not precisely represent when they actually appear inside of it.

For example, the FPGA I/O introduces 3–5 ns delay to the signal so in actuality the FPGA will “see” the falling edge shown in (b) slightly after what is represented in the ﬁgure.
On-chip delay also affects the design and is not shown, but must be accounted for.
voltage (V)time since start of exchange (mms)010203040500123l−100102030400.00.51.01.52.02.53.03.5voltage (V)time since challenge sent by verifier (ns)CLKplllllProver samplesVerifier samplestdtntm++tdtp++tdtqfail--tdtqpass--tdlIOvIOpChallenge sentResponse received0510distance at speed of light in vacuum (m) difﬁcult to estimate the cost of an ASIC implementation with these ﬁgures as there is no reliable conversion tech- nique between FPGA resource utilization and ASIC tran- sistor count, especially since the above numbers are for the core functions, without the supporting circuitry.
It is also hard to estimate the cost in currency because that changes rapidly with time, production volume, fabrica- tion process, and many other factors, so we will describe it relative to the resources currently used.

As mentioned, we have made every effort to minimize the circuitry that needs to be added to the smartcard while being more liberal with the terminal, although for both the additions can be considered minor.
For the smartcard, new commands for initiating the initialization phase need to be added as well as two shift registers and a state ma- chine for operating the rapid bit-exchange.

Consider- ing that smartcards already have a few thousand memory cells, this can be considered a minor addition, especially given that they need to operate at the existing low fre- quencies of 1–5 MHz.
For the initialization phase, exist- ing circuits can be used such as the DES engine for pro- ducing the content of the response registers.

The card’s transaction counter may be used for the nonce, Np.

As for the terminals, their internal operating frequency is unknown to us, but it is unlikely that it is high enough to achieve good distance resolution.

Therefore, a capable processor and some additional components are required, such as a high quality oscillator.
As an alternative to high frequencies, or when designing for very short distances, delay lines could be used instead of operating on clock edges.

The distance bounding circuitry would need to be added to the terminal’s main processor, which consists of two shift registers and slightly more involved control code than the smartcard’s.
We have described the added cost in terms of hard- ware but the added time per transaction and the need to communicate with the bank, refused transactions due to failure, re-issuing cards, and so on, may amount to sub- stantial costs.

Only the banks involved have access to all the necessary information needed to make a reasonable estimate of these overheads.
6 Discussion The distance bounding protocol we have proposed will detect attempted relay attacks but requires the banks to produce cards and terminals that support the protocol.

However, the person being defrauded is the cardholder, Alice, who must use the cards and terminals she is given, so has no trusted user interface and no way to protect herself.

As mentioned in Section 4.2, this incentive mismatch may be detrimental to the cardholder’s secu- rity.
For instance, until all terminals support the distance bounding protocol, the issuer can select whether to fall- back to the current protocol that is vulnerable to relay- attacks.

Under existing UK practice, the customer is li- able for PIN-veriﬁed fraudulent transactions [10], so the issuer may elect to accept fallback transactions knowing that the cardholder is carrying the risk.
A further problem of the distance bounding protocol is the lack of non-repudiation: for a third party to ver- ify that a relay attack was not in progress, the merchant’s terminal must be trusted to correctly report the round-trip latency.

Thus, if a customer claims that a transaction is fraudulent, then even if the distance bounding protocol is recorded to have succeeded, there remains the possibil- ity that the terminal has been tampered with.
It falls on the acquirer to mandate tamper-resistant terminals, but although the payment network may require that all mem- bers implement appropriate protections, the customer is only represented indirectly by the issuer.

So while inexpensive yet strong technical solutions, such as distance bounding, do exist they must be de- ployed as part of an appropriate liability framework to fully realize their beneﬁts.
The current situation, where customers are liable for fraud, yet powerless to verify whether a terminal is genuine, is clearly unfair.

If the power of banking institutions is too great to alter the entrenched notion of customer liability, then measures that put the cardholder in a position of control, such as the electronic attorney [2], despite being more expen- sive, may be the most appropriate solution.
However, customers should exercise caution before accepting these options as the second-order effect of the customer being able to detect attacks could be to make them reasonably liable for any fraud which is nevertheless perpetrated.

7 Conclusion This paper described relay attacks and how they can be applied to exploit smartcard-based payment systems.

A prototype was built and shown to be successful against the Chip & PIN payment system deployed in the UK.
This consisted of creating a fake terminal and custom hardware to allow the relaying of information between the participating parties.

We suggested procedural im- provements to the acceptance of Chip & PIN transac- tions, which would provide a short-term defence, but these could be circumvented by a plausible attacker.

We then developed the ﬁrst implementation of a distance bounding defence against these relay attacks and showed it to be the most robust solution.
Our implementation was designed to be appealing for adoption in the next generation of smartcards by tailoring the design to the EMV framework.

Future work may include implementing a wireless variant of the protocol, mutual distance bound establish- ment and customizing the system to other applications.

Acknowledgements Saar Drimer is funded by Xilinx, Inc. Steven J. Mur- doch is funded by the OpenNet Initiative.
Markus Kuhn has provided us with both stimulating discussions and advice, along with hardware.

Xilinx donated hardware and development software.

We also thank Ross An- derson, Mike Bond, Richard Clayton, Frank Stajano, Robert Watson, Ford-Long Wong, anonymous reviewers for their valuable suggestions, and the merchants who al- lowed us to test and demonstrate our attack.
References [1] ADIDA, B., BOND, M., CLULOW, J., LIN, A., MURDOCH, Phish and S. J., ANDERSON, R. J., AND RIVEST, R. L. In Se- chips (traditional and new recipes for attacking EMV).

curity Protocols Workshop (Cambridge, England, March 2006), LNCS, Springer (to appear).

http://www.cl.cam.ac.uk/ ∼rja14/Papers/Phish-and-Chips.pdf.

[2] ANDERSON, R., AND BOND, M. The man in the mid- In Security Protocols Workshop (Cam- (to appear).

dle defence.
dle defence.

bridge, England, March 2006), http://www.cl.cam.ac.uk/∼rja14/Papers/ Man-in-the-Middle-Defence.pdf.

Springer [3] ANDERSON, R., BOND, M., CLULOW, J., AND SKOROBOGA- TOV, S. Cryptographic processors—a survey.

Proceedings of the IEEE 94, 2 (February 2006), 357–369.

[4] ANDERSON, R., BOND, M., AND MURDOCH, S. J.

Chip and spin, March 2005. http://www.chipandspin.co.uk/ spin.pdf.

[5] APACS.

APACS response to BBC Watchdog and chip and PIN.

Press release, February 2007. http://www.apacs.org.
uk/media centre/press/07 06 02.html.

[6] APACS.

Press re- Card fraud losses continue to fall.

lease, March 2007. http://www.apacs.org.uk/media centre/press/07 14 03.html.

[7] ASOKAN, N., DEBAR, H., STEINER, M., AND WAIDNER, M. Authenticating public terminals.

Computer Networks 31, 9 (1999), 861–870.

[8] AVESO.

Display enabled smart cards.

http://www.

avesodisplays.com/.

[9] BETH, T., AND DESMEDT, Y. Identiﬁcation tokens – or: Solving the chess grandmaster problem.

In CRYPTO (1990), vol.


537 of LNCS, Springer, pp.

169–177.

[10] BOHM, N., BROWN, Elec- I., AND GLADMAN, B.

The tronic commerce: Who carries the risk of fraud?

Journal of Information, Law and Technology, 3 (October 2000).

http://www2.warwick.ac.uk/fac/soc/law/ elj/jilt/2000 3/bohm/.

[11] BRANDS, S., AND CHAUM, D. Distance-bounding protocols.

In EUROCRYPT ’93: Workshop on the theory and application of cryptographic techniques on Advances in cryptology (May 1993), T. Helleseth, Ed., vol.
765 of LNCS, Springer, pp.

344–359.

[12] CLULOW, J., HANCKE, G. P., KUHN, M. G., AND MOORE, T. So near and yet so far: Distance-bounding attacks in wireless net- works.

In Security and Privacy in Ad-hoc and Sensor Networks (Hamburg, Germany, September 2006), L. Buttyan, V. Gligor, and D. Westhoff, Eds., vol.

4357 of LNCS, Springer.

[13] CONWAY, J. H. On Numbers and Games.

Academic Press, 1976.


[14] DESMEDT, Y., GOUTIER, C., AND BENGIO, S. Special uses In Advances and abuses of the Fiat-Shamir passport protocol.

in Cryptology – CRYPTO ’87: Proceedings (1987), vol.

293 of LNCS, Springer, p. 21.

[15] EMVCO, LLC.

EMV 4.1, June 2004. http://www.emvco.

com/.

[16] HANCKE, G. A practical relay attack on ISO 14443 proxim- ity cards, 2005. http://www.cl.cam.ac.uk/∼gh275/ relay.pdf.

[17] HANCKE, G. P., AND KUHN, M. G. An RFID distance bounding protocol.
In SECURECOMM ’05: Proceedings of the First Inter- national Conference on Security and Privacy for Emerging Ar- eas in Communications Networks (Washington, DC, USA, 2005), IEEE Computer Society, pp.

67–73.

[18] HU, Y.-C., PERRIG, A., AND JOHNSON, D. Wormhole attacks in wireless networks.

IEEE Journal on Selected Areas in Com- munications (JSAC) 24, 2 (February 2006).

[19] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION.
ISO/IEC 7816-3:2006 Identiﬁcation cards – Integrated circuit cards – Part 3: Cards with contacts – Electrical interface and transmission protocols, 3 ed., October 2006.

[20] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION.

ISO/IEC 18092:2004 Information technology – Telecommunica- tions and information exchange between systems – Near Field Communication – Interface and Protocol (NFCIP-1), 1 ed., Jan- uary 2007.

[21] JOHNSTON, R. G., GARCIA, A. R., AND PACHECO, A. N. Efﬁ- cacy of tamper-indicating devices.
Journal of Homeland Security (April 2002).

[22] KUHN, M. G. An asymmetric security mechanism for navigation In Information Hiding (Toronto, Canada, May 2004), signals.

J. Fridrich, Ed., no.

3200 in LNCS, Springer, pp.

239–252.

[23] VARIAN, H. R. Managing online security risks.

New York Times.

1 June, 2000. http://www.ischool.berkeley.

edu/∼hal/people/hal/NYTimes/2000-06-01.

html.

[24] VISA INTERNATIONAL SERVICE ASSOCIATION.

Approved PIN entry devices, May 2007. http://partnernetwork.
visa.com/dv/pin/pedapprovallist.jsp.