Σχόλια 0

Το κείμενο του εγγράφου

Practical Relay Attack on Contactless Transactionsby Using NFC Mobile PhonesLishoy Francis,Gerhard Hancke,Keith Mayes,Konstantinos MarkantonakisInformation Security Group,Smart Card CentreRoyal Holloway University of LondonEgham Hill,TW20 0EX,Surrey,United KingdomLishoy.Francis.2005@live.rhul.ac.uk,(Gerhard.Hancke,Keith.Mayes,K.Markantonakis)@rhul.ac.ukAbstractContactless technology is widely used in security sensi-tive applications,including identiﬁcation,payment andaccess-control systems.Near Field Communication(NFC) is a short-range contactless technology allowingmobile devices to act primarily as either a reader or a to-ken.Relay attacks exploit the assumption that a contact-less token within communication range is in close prox-imity,by placing a proxy-token in range of a contactlessreader and relaying communication over a greater dis-tance to a proxy-reader communicating with the authen-tic token.It has been theorised that NFC-enabled mo-bile phones could be used as a generic relay attack plat-form without any additional hardware,but this has notbeen successfully demonstrated in practice.We presenta practical implementation of an NFC-enabled relay at-tack,requiring only suitable mobile software applica-tions.This implementation reduces the complexity ofrelay attacks and therefore has potential security impli-cations for current contactless systems.We also discusscountermeasures to mitigate the attack.1 IntroductionRadio Frequency Identiﬁcation (RFID) technology hasbecome increasingly prevalent in everyday applications.Contactless technology is a subset of RFID systems op-erating at 13.56 MHz,with an operating range of up to 10cm.This technology comprises mature standards and in-dustry speciﬁcations and is widely used by the smart cardsector in security sensitive systems.Contactless technol-ogy is currently used in credit card payment [1–3],e-IDand e-passport systems [4,5],transport ticketing [6,7]and access control systems [8,9].The practical secu-rity of contactless systems is therefore an active researcharea,both in terms of the actual channel [10–12] and de-ployed applications [13–15].Relay attacks are especially of interest with regardsto contactless application security [16].Contactless sys-tems,as a result of the limited operational range,operateon the implicit assumption that successful communica-tion with a token proves that the token is in close proxim-ity of the contactless reader.Therefore,once authentica-tion has been achieved at the application layer,the readerwill approve a transaction or render a service as it be-lieves that the legitimate token is in its presence.A relayattack exploits this assumption by placing a proxy-tokenwithin the communication range of the reader,whichcommunicates with a proxy-reader located in close prox-imity to the legitimate token.The proxy-token is alwaysable to answer with a valid response to any reader com-mand because it simply forwards the command to theproxy-reader,which in turn sends it to the legitimate to-ken and returns the valid response from the legitimatetoken to the proxy-token.For the duration of the relayattack the proxy-token exhibits the same behaviour asa legitimate token from the reader’s perspective.Thisattack effectively circumvents application layer securitymechanisms.For example,an attacker can circumvent anauthentication protocol by simply relaying a challenge tothe real token,which will provide him with the correctresponse,which can then be relayed back to the readervia the proxy-token.It does not matter what applicationlayer protocols or security algorithms are used,as the at-tacker just relays all the application layer data,therebyensuring that both the legitimate reader and the legiti-mate token always receive the data they expect.Near Field Communication (NFC) is a short-rangeRFID technology intended to equip mobile devices witha contactless communication channel compatible withexisting contactless technology.An NFC-enabled de-vice is able to act like a passive contactless token,which can be read by contactless readers.Alternatively,an NFC-enabled device can act as a contactless tokenreader.NFC-enabled devices can also speak to eachother by using a speciﬁed ‘peer-to-peer’ mode.NFCis not a new technology,having been invented almostFigure 1:NFC architecture options with SE available as a software emulation (“soft-SE”) via mobile phone APIs.a decade ago and actively promoted by the NFC Fo-rum [17] since 2004.NFC has been the focus of nu-merous worldwide trials and proof-of-concept demon-strations,but large scale deployment was hampered bydisagreement regarding NFC-device architecture,appli-cation management and the resultant lack of NFC de-vices.In 2011 NFC has,however,become increasinglyprominent with a number of phone manufacturers re-leasing NFC-enabled smart phones,such as the NokiaC7 [18],RIM Blackberry 9900/9930 [19] and GoogleNexus S [20].At the same time,NFC has also maderapid strides in enabling mainstream applications,as il-lustrated by the release of Google Wallet [21] and Or-ange Quick Tap [22] payment systems in the USA andUK respectively.As the deployment of NFC gathers speed the secu-rity of NFC devices and applications becomes increas-ingly important [23],and in addition the security impli-cations of providing access to what is essentially a pro-grammable contactless reader and token emulation plat-formshould also be considered.For example,it has beenshown that an NFC-enabled mobile phone can be used asan effective token skimming and cloning platform [24].The ability of an NFC-enabled device to act as both a to-ken and a reader potentially makes such device an idealplatformfor implementing software relay attacks,as the-orised in multiple publications [25,26],but this has notbeen proven to be practically possible in a generic man-ner.This paper describes a relay attack implementationusing unmodiﬁed NFC-enabled mobile phones,whichonly requires an attacker to write suitable mobile plat-form applications using publicly available APIs.Ourrelay attack implementation signiﬁcantly demonstrates areduced complexity of attack as it does not require spe-cial attack hardware,as in some previous relay attack ex-periments [27].This implementation also results in anattack that cannot be visibly detected in contrast with at-tacks with PC-controlled NFC-enabled devices acting asproxy-token [28,29] since an NFC phone is (or will soonbe) an accepted token form factor.The attack imple-mentation is application independent and works againstwidely deployed,conventional contactless system con-ﬁgurations,i.e.a reader and a passive contactless token,and not only against the NFC peer-to-peer communica-tion mode [30].The practical simplicity of such a re-lay attack implementation increases the likelihood of thisexploit being used in practice and places real-world sys-tems at risk.Modern contactless credit card and m-walletpayment systems,ticketing,access control and electronicidentiﬁcation schemes are vulnerable to relay attacks,and an attack that can effectively be executed by un-skilled attackers using off-the-shelf hardware representsa credible threat.This work could potentially change sys-tem implementers’ view of preceding work on relay at-tacks,which is mostly dismissive and can be summarisedby the quote “There’s been no example of it happeningin the real world,and we ﬁnd it highly unlikely that itwill happen” [31].This paper challenges the currentlyheld opinion that relay attacks require advanced skill andcustomhardware that is unlikely to transition froma lab-oratory to the real world [32].Apart from the risks arelay attack poses,practically implementing a ‘proof-of-concept’ attack using NFC mobile phones serves to em-phasise the current weaknesses in NFC architecture thatwould need addressing.This paper starts with a general discussion of NFCtechnology and relay attacks in Section 2.Our relay at-tack implementation on mobile phones,its effectivenessand experimental observations are discussed in Section3.Finally,potential countermeasures against relay at-tacks are discussed and analysed in Section 4.22 BackgroundIn this section,we present a brief overview of NFC tech-nology.We then go on to discuss relay attacks and re-lated work.2.1 NFC TechnologyNFC facilitates the integration of contactless technol-ogy into active device platforms,such as mobile phones.NFC is a short-range RFID technology operating atthe 13.56 MHz radio frequency (RF) band and is de-scribed in the ISO 18092/ECMA 340 [33] and in ISO21481/ECMA 352 [34] standards.NFC is speciﬁed tobe compatible with existing contactless systems adher-ing to ISO 14443 [35],ISO 15693 [8] and FeliCa [36].The standards specify both ‘passive’ and ‘active’ opera-tion.Passive operation corresponds to the operation ofconventional contactless systems.The NFC device cantherefore either act like a contactless token,interactingwith a reader,or act like a reader,powering and interact-ing with a contactless token.Two NFC devices can alsointeract with each other in active,or peer-to-peer (P2P)mode,when brought in close proximity.In this activemode,devices take turns to transmit an RF ﬁeld,e.g.de-vice 1 turns on its RF ﬁeld and transmits data to device2,followed by device 1 turning off its ﬁeld and device2 turning on its ﬁeld and transmitting data to device 1.Peer-to-peer relay has been covered in a previous publi-cation and is not the focus for this paper [30].It is ex-pected that NFC will be deployed in existing contactlessapplications,such as payments,ticketing,access control,identiﬁcation and logistics.NFC in conjunction with theadditional functionality of its host platform could alsoenable additional applications,such as one of the earlyproposals of using NFCfor quickly pairing Bluetooth de-vices [37].Today,there are a number of NFC-enabled devicesavailable but mobile phones are the main focus of in-dustry and this paper.More details of the NFC phoneplatformas relevant to our implementation are discussedin Section 3.There are three main components that com-prise an NFC-enabled phone platform [38] (an overviewis shown in Figure 1):• Application Execution Environment (AEE):Thegeneral application area of the mobile phone pro-viding data storage and processing capabilitiesalongside basic mobile phone services.• Trusted Execution Environment (TEE):The TEEis usually realised through the use of a secure el-ement (SE) and provides secure data storage,exe-cution and application management.A SE is essen-tially a smart card supporting Java Card 2.2.1 [39](Java Card Open Platform [40]),Global Platform2.1.1 [41] and selected legacy products such as theMifare Classic [42] emulation.An SE is most com-monly implemented as an embedded module,i.e.asurface-mounted module soldered into the phone,as an integrated component on the (U)SIM (Uni-versal/Subscriber Identity Module) [43],or as a re-movable secure memory token [44].A new devel-opment is the concept of a “soft-SE” located withinthe mobile phone application area.The “soft-SE” isopen for development,in contrast to earlier SEmod-ules that had to be unlocked for development use.For example,using an “unlock” application sup-plied by the phone manufacturer.Once unlocked,anSE is forever considered as untrusted and can sub-sequently be used only for development purposes.An NFC phone will contain one or more of theseSE implementations.• NFC Controller (low level stacks):The NFC Con-troller handles the physical transmitting and receiv-ing of data over the RF interface.The card em-ulation stack,reader/writer stack and peer-to-peerstack allow for communication between the con-troller and the AEE/TEE as required by the respec-tive mode of operation.Reader and peer-to-peer op-erations are generally controlled via applications inthe AEE,with card emulation being controlled viaapplications in the TEE,i.e.executing within an SE.With the exception of the application management onthe SE and the Signature Record Type Deﬁnition (SRTD)[45],which aims to provide data authentication for datain NFC Data Exchange Format (NDEF) [46],the NFCspeciﬁcations and standards leave application security inthe hands of the developer.There have been several re-search papers discussing NFC security,such as [23].Re-search work has been published both on vulnerabilitiesin the speciﬁcations,such as the vulnerabilities in theSRTD [47],and NFC software stacks allowing tags toredirect to spoofed web addresses or load malicious soft-ware [48,49].Given the computational capabilities ofthe phone platform,and the added capabilities of NFCto act as a reader and a token,the possibility of usingan NFC phone as a platform for contactless “skimming”and “cloning” platforms has also been [24] considered.2.2 Relay AttackA relay attack can be best explained conceptually withthe help of the Grand Master Chess problemas discussedin [50].In this scenario,a person who does not knowtherules of chess could play against two grand masters bychallenging both of them to a postal game.The playerwould then simply forward the move received from one3Figure 2:Practical relay setup using only NFC mobile phones.grand master to the other,effectively making them playagainst one another.Each grand master would think thatthey are playing said person,but in reality they are play-ing against each other.The application of this scenarioto security protocols was ﬁrst presented and discussedin [51].In the literature,this attack has subsequentlybeen referred to as a ‘wormhole attack’ [52] or as a ‘re-lay attack’ [53].A relay attack has serious security implications as theattacker is able to bypass any application layer securityprotocol,even if such protocols were based on strongcryptographic principles.For example,an attacker cancircumvent an authentication protocol by simply relay-ing a challenge to a legitimate token,which will providehimwith the correct response,which can then be relayedback to the veriﬁer.It does not matter what applicationlayer protocols or security algorithms are used,in factthe attacker requires no prior knowledge about the datahe is relaying,as the attacker just relays all the appli-cation layer data,thereby ensuring that both the readerand the token always receive the data they expect.If theoverarching protocol contains a security vulnerability theattacker could also modify the relayed data in real timeto exploit this vulnerability,an action often referred to asan ‘active’ relay [16].To execute a relay attack,the adversary needs two de-vices,which act as a token and a reader respectively.These devices are connected via a suitable communica-tion channel in order to relay information over a greaterdistance.The proxy-reader is used to communicate withthe real token,while the proxy-token is placed near thereal reader.Any information transmitted by the reader isreceived by the proxy-token and relayed to the proxy-reader,which will transmit the information to the to-ken.The token assumes that it is communicating withthe reader and responds accordingly.The token’s re-sponse is then relayed back to the proxy-token,whichwill transmit the information to the reader.The intentionof the attacker is to ensure that the reader is unable todistinguish between the real token and the proxy.If hesucceeds the reader will assume that the token and its as-sociated owner are in close proximity and grant access tothe attacker.Several practical implementations of relay attacks inthe contactless environment have been published.Theearliest impactful implementation was a demonstrationof a relay attack against EMV payment systems usingcontact-based cards [56],which illustrated the vulnera-bility of deployed systems to relay attacks and showedthat even real-world systems that are engineered to be se-cure contain no countermeasures to attacks of this type.These implementations often required custom-built hard-ware [27,54] or the use of NFC-enabled contactless read-ers controlled by a host computer [28,55].In some cases,the use of custom hardware is not a negative.In certainsystems readers are unattended,or as in the case of [54]the use of customhardware is part of the attack’s successas the system does not use technology used widely inother applications.The drawbacks are that these imple-mentations yield proxy-tokens that can easily be spottedas out of the ordinary,in the case of [56] some social en-gineering and coordination was required as the attackerhas wire running down his sleeve to the card presentedto the vendor.The complexity of such attacks have beenargued to potentially limit their widespread use in ex-ploiting current systems [31,32].In contrast,an attackimplemented entirely on an NFC-enabled phone,requir-ing an attacker to only download and install suitable ap-plications,is more likely to become a practical threat.The scenario of a relay attack implemented against con-ventional contactless systems using only mobile phones,envisaged in [25],has not been practically demonstratedbut has been the target of some research initiatives.In[29] a phone was used as the proxy-reader and an NFC-enabled reader acted as the proxy-token.In [30] it wasshown that the communication between two NFC de-vices communicating in P2P mode could be relayed us-ing two NFC phones.In both these cases the authors didnot succeed in implementing a proxy-token acting as apassive contactless token as would be required when re-4laying conventional contactless transactions.3 Practical Relay ImplementationIn this section,we describe the practical implementationof a relay attack using only off-the-shelf NFC mobilephones.We implemented the attack with two commer-cially available NFC-enabled mobile phones and con-ducted several controlled relay experiments to verify theeffectiveness of the attack.Both the proxy-token andproxy-reader mobile phones are conﬁgured simply byinstalling mobile phone applications that we developed.The attack implementation requires no unlocking of de-vices or secure elements,no hardware or software mod-iﬁcation to the phone platform,and minimal knowledgeof the data that is to be relayed.We also chose to im-plement the relay channel in such a way that it could beset up between the two phones without the need for re-lying on access to a mobile network.The relay setup forattacking a contactless system,as implemented in thispaper,is shown in Figure 2.3.1 Proxy Communication Channel usingNFC Mobile PhonesIn a relay attack,the attacker and his/her accomplice usesproxy-devices that communicate over a proxy channel.The relay experiment thus requires a high-speed and re-liable communication link between the two NFC mobilephones implementing the proxy-reader and proxy-token.Bluetooth was chosen as communication channel forour relay experiments.Bluetooth,or IEEE 802.15,is ashort-range radio technology developed by the BluetoothSpecial Interest Group (SIG).It utilises unlicensed radiospectrum in the frequency band of 2.45 GHz,offeringbandwidth in the range of 720 kilobits per second andan effective operating range typically in the region of 10m to 100 m.Point-to-point Bluetooth is simple to setup and the communication latency offered by the chan-nel is relatively low.Although the communication rangeoffered by Bluetooth could be seen as a limitation ouraim was to demonstrate the feasibility of establishing arelay channel between two mobile phones.In reality,theproxy channel could be realised via other technologiessuch as IEEE 802.11 or mobile Internet over GPRS/E-GPRS (Enhanced General Packet Radio Service).Relay-ing data via mobile Internet requires no user-interactionand potentially offers both increased bandwidth and lowlatency if good network coverage is available.It wouldtherefore appear to be a good alternative channel optionbut it introduces a reliance on the mobile network,i.e.the attack is only effective if there is network coverageand a reliable data service.It could also be argued thewhen using mobile Internet data leaves an audit trail ofrelayed data,whereas the use of Bluetooth channel doesnot relay on third party infrastructure.The mobile applications installed on the proxy-readerand proxy-token implemented Bluetooth communicationusing the JSR 82 API.We used L2CAP (Logical LinkControl and Adaption Protocol) that is available withinthe host stack of Bluetooth protocol.L2CAP is layeredover the Baseband Protocol,and operates at the data-linklayer within the OSI (Open SystemInterconnection) Ref-erence Model.The supported data capacity of the chan-nel,for individual packets,is up to 64 kilobytes in length.The default Maximum Transmission Unit (MTU) is 672bytes,and 48 bytes is the minimum mandatory MTU.More details for implementing the Bluetooth API can befound in [30,37,57].3.2 NFC Mobile Phone as Proxy-ReaderA Nokia 6131 NFC phone was conﬁgured as a proxy-reader (controlled with an MIDP/J2ME Application[58]) capable of interacting with contactless tokens.Thisinvolved developing a MIDP 2.0 application (which iscommonly known as a MIDlet) to emulate a contact-less reader using a standard NFC contactless communi-cation API - JSR 257 [59].This application was devel-oped by using a freely available Nokia NFC SoftwareDevelopment Kit (SDK) [60].The MIDlet was designedto exchange ISO 14443-4 based Application ProtocolData Unit (APDU),such as those received froma proxy-token over the relay communication channel,with exter-nal contactless smart cards.For using the JSR 257 APIand JSR 82 Bluetooth API in the MIDlet,it did not re-quire any code signing [61] in order to install and executethe application.3.3 NFC Mobile Phone as Proxy-TokenIn a relay systemwith only NFC enabled mobile phones,the main challenge is to conﬁgure the phone as a control-lable proxy-token.A proxy-token needs to receive com-mand messages from the reader,relay them to a proxy-reader and then present the relayed responses back to thereader,all in an orderly and timely fashion.During pre-vious development work on speciﬁc legacy NFC phoneswe found that the embedded SE could not support multi-ple communication sessions.This meant that once an SEemulating a token received a command from a reader itwas bound to that communication session and unable tosend the received command to the relay channel.This isan observation subsequently also made in [29].In con-trast,we found that (U)SIM SEs were capable of main-taining multiple sessions,potentially making a relay at-tack possible.(U)SIMs are however tightly controlled bymobile network operators and obtaining such SEs for de-5(a) Contactless credit card transaction(b) e-Passport transactionFigure 3:Testing relay attack implementation on real systems.velopment is difﬁcult,which inherently limits the appealof such an attack implementation.The release of the NFC-enabled Google Nexus S andBlackBerry 9900/9930 phones has provided more free-dom in developing applications requiring card emula-tion functionality.Although the Nexus S does not yetsupport card emulation functionality as standard,it hasbeen shown that it is possible modify the phone ﬁrmwareto allow for user controlled card emulation as a re-sult of the open nature of the Android OS [62].TheBlackBerry phones,running Blackberry OS v7.0.0,al-low user-controlled card emulation without modiﬁca-tion.We therefore chosen to implement the proxy-tokenon a BlackBerry 9900 phone,keeping with our goal ofdemonstrating a simple,software-only NFC relay attack.The BlackBerry v7.0.0 NFC API (net.rim.device.api.io.nfc.emulation) provides for the emulation of contact-less applications based on a “soft-SE”.This approachoffers greater ﬂexibility in application development butalso increases the likelihood that the phone could be usedas an attack platform.To start with,we tested whether itwas possible to create a contactless application with areserved Application Identiﬁer (AID),i.e.an AID as-sociated with a sensitive application such as credit cardpayments [24].The ability to set the AID in such a wayprovides an ideal entry point for the relay process,as thereader would inherently select and start communicatingwith the relay application.We found that no securitycontrols were in place to prevent spooﬁng a legitimate re-served AID and also that this emulation method allowedthe emulation application to be in session with the readerwhile also accessing other system components,therebymaking it possible to relay received commands.TheBlackBerry NFC mobile phone was thus conﬁgured as aproxy using a BlackBerry Java Application we developedthat utilised the BlackBerry-speciﬁc NFC emulation APIv7.0.0 [63],and implemented Bluetooth communicationusing the JSR 82 API [57].The NFC emulation API [63] did not require manda-tory code-signing,although the underlying Runtime APIwas required to be signed in order to install and run theapplication on the device.The registration process andsubsequent acquiring of the signing certiﬁcate did how-ever not involve any formal organisational or personalvetting [64].3.4 ‘Proof-of-Concept’ Relay ExperimentInitially,we simply tested whether our implementationwould relay a single command response transaction us-ing a test setup involving a contactless reader and a tokencontaining a simple Java Card [39] applet.The proxy-token was presented to the contactless reader and the le-gitimate contactless token was presented to the proxy-reader and it was determined that the reader obtainedan acceptable response (correct content and adequate re-sponse timing).Subsequently we managed to perform arelay involving multiple commands fromthe reader,reli-ably completing a full legitimate contactless transactionduring each run.Using the Bluetooth channel in a nonline-of-sight environment the attack worked up to a rangeof 15m.In an open plan roomwith some minor obstaclesthe attack worked up to a range of 35m.We also set up two additional laboratory controlled ex-periments.The ﬁrst was a test payment systembased onﬁrst generation contactless credit cards,i.e.static au-thentication credentials,using a contactless point-of-sale(POS) terminal and a ‘card’ we constructed using a valid6Table 1:Timing Measurements of a Sample Transaction (APDU Command/Responses) (in milliseconds)(a) Contactless Smart Card(b) Embedded SE(c) “soft-SE”(d) Relay(Proxy-Token on “soft-SE”)Command 1113.3917190.5490181.1386246.0Command 212.190220.232512.8123114.0Command 34.19485.261410.7270109.0Command 417.042018.514738.3187118.0Command 54.81805.893915.419478.0Total151.6367240.4515258.416665.0card data proﬁle.Cards using static authentication in thisway are no longer best-practice but the objective of theexperiment was more focused on whether the POS wouldaccept a delayed relayed response as valid.Newer cardsusing dynamic authentication protocols are equally vul-nerable to relay attacks as the dynamic challenge and re-sponse is as easily relayed.The relay experiment on apayment transaction using a POS reader,and a contact-less smart card with a sample payment application in-stalled is shown in Figure 3(a).In the second experiment,we tested the relay against an e-passport demonstrationsystemusing a sample passport and authentic reader soft-ware.The emphasis in this case was once again whetherthe reader would accept a relay response,and in additionthis setup also tested whether longer data APDUs,suchas the passport record including a JPEGpicture,could bereliably relayed.The test setup is shown in Figure 3(b).In both cases the relay attack executed successfully andthe reader/POS accepted the proxy-token’s responses.We would like to highlight the fact that these two systemswere not chosen because they are known to be vulnera-ble to relay attacks,these are just systems we had accessto.The attack as implemented would work on any sys-temwith communication fully compatible to NFCor ISO14443 contactless technology,which includes most pay-ment and m-wallets,electronic identity,ticketing and ac-cess control systems deployed today.Some legacy con-tactless products that are only partially compatible withthe standard,and use proprietary APDUs,might be re-sistant to this attack implementation.Relaying contact-less transaction data relies on the attack application re-ceiving the received data from the NFC communicationmodule,which is responsible for demodulation,decod-ing and stripping off frame information such as CRCs,parity bits and stop/start patterns and providing data leftto the application layer.Some contactless card systemsuse proprietary framing,which means that the NFCmod-ule would not be able retrieve the data in the normal way.Additional detail on this attack restriction is given in Sec-tion 4.2.2.3.5 Experimental Analysis and FurtherTestsThe attack parameter of most interest is the round-triptime required by the relay process.The main delay iscaused by the relay communication channel.The Blue-tooth channel introduces approximately 50 ms into thethe round-trip-time of the challenge-response.Althoughall the readers we tested accepted the delayed responsesof the proxy-token,we wanted to quantify this delay andcompare the performance of a proxy-token to other em-ulation implementations as a matter of scientiﬁc inter-est.Table 1 shows the response times of several com-mand and response message sequences on different em-ulation platforms,with respect to the payment test sys-tem discussed in the previous section.The times shownin the Table is ‘best-case’,the shortest times observedover several measured transaction runs.In the worst caseabout 30 ms is added to response times.We measuredthe response time of a sample payment application im-plemented on a programmable contactless smart card,onan embedded SE and on a “soft-SE”.Although timingmeasurements varied between protocol runs,these im-plementations were in general all signiﬁcantly quickerthan the response time of the proxy-token,but this is tobe expected taking into account the overhead involvedwith the relay process.We believe that the response timefor the proxy-token could potentially be made faster,asthere is some room for optimisation of our applicationwith regards to the implementation of the relay commu-nication channel.We also wanted to determine what the maximumtimeis that an attacker has to relay transactions before thereader refuses the response.We programmed a variabletimer routine into the proxy-token application and sys-tematically increased the time until the attack failed.Inthe case of the POS reader the allowable attack time wasup 35000 ms and for the passport system reader the al-lowable attack time was up 5200 ms.This has signif-icant implications,as 35 and 5.2 second is a long timein terms of modern communication systems.This couldpotentially allowan attacker to extend the effective rangeof the attack.We tested the latency of a potential relay7channel implemented using a WiFi access point and esti-mate that such a channel,including initial connection andsession setup,would introduce about a 1.5 second delayto the attack.This time increase is still acceptable to thereaders we tested,with the implication that the proxy-reader and proxy-token can now be situated anywhere inthe world and still relay acceptable transactions.4 Security Countermeasures for Relay At-tackIn this section we discuss potential security countermea-sures and their effectiveness in mitigating the relay at-tack presented in Section 3.We only consider counter-measures that can be implemented without degrading theuser experience,which is one of main advantages of con-tactless technologies.We therefore do not discuss mea-sures that shift the responsibility of security to the enduser,such as shielding tokens or performing two-factorauthentication with a PIN.The countermeasures can bedivided into two main categories:• Contactless Platform Countermeasures:counter-measure proposals for treating the phone as aresource-limited contactless token,i.e.simplemechanisms implemented by the reader and back-end infrastructure.• Mobile Phone Platform Countermeasure:counter-measures leveraging the capabilities of the mobilephone platform to enhance the security of the con-tactless transaction.4.1 Contactless Platform Countermea-suresThis section brieﬂy examines security countermeasuresproposed for making contactless systems resistant to re-lay attacks.4.1.1 TimingOne of the intuitive countermeasures is enforcing strictertiming restraints on responses.This is based on thevalid observation that a relayed transaction will have anincreased response time in comparison to a legitimatetransaction.It is,however,difﬁcult to implement thisin practice.Firstly,obtaining accurate transaction tim-ing information on current readers is a challenge,con-sidering the number of underlying process componentsadding overhead.Accurate response timing would likelyrequire dedicated hardware that directly monitors the RFchannel.In real world systems there is also a need to ac-commodate a variety of contactless tokens,which varyin terms of performance,so setting a restrictive timeoutvalue could lead to valid transactions being rejected.Themethod that ISO 14443 (which is the contactless stan-dard used in the majority of security sensitive contactlessapplications and serves as the basis for NFC) mandatesfor negotiating communication parameters between thereader and token also negates the use of timeouts.ISO14443 Part 4 speciﬁes a Frame Waiting Time (FWT)variable that sets the time within which a token shall startits response after the end of the reader’s data.FWT is de-ﬁned as (256∙ 16/fcarrier) ×2FWI,where FWI is a valuefrom0 (FWT = 300 µs) to 14 (FWT = 5 s) with a defaultof 4 (FWT = 4.8 ms).The value of the Frame WaitingInteger FWI is deﬁned by the token in theATSresponse.If implemented,the Frame Waiting Time deﬁnes an up-per bound on the relay delay.Even though this valueis set it is seldom enforced by the reader,as was seen inour experimented,and instead replaced by a much longertimeout.Even if a reader did enforce the FWT it is not asuitable countermeasure because it is the token that spec-iﬁes the Frame Waiting Time (FWT) during the commu-nication setup.As the token speciﬁed the time withinwhich it shall start its response a proxy-token could sim-ply specify a FWT of up to 5 seconds [16],more thanenough time to complete the relay process.4.1.2 Distance BoundingDistance-bounding protocols determine an upper boundfor the physical distance between two communicatingparties based on the Round-Trip-Time (RTT) of cryp-tographic challenge-response pairs [65],and it has beenproposed that these are suitable for relay-resistant RFIDsystems [53].Distance bounding is in theory the most ef-fective countermeasure but this approach requires specialcommunication channels to facilitate accurate and securedistance estimates,since conventional RF channels havebeen shown inadequate for implementation of secure dis-tance bounding [66,67].Although much progress hasbeen made on practical distance bounding implementa-tions for smart tokens [56,68] the integration of suchchannels into NFC-enabled devices has not been an in-dustry priority.4.2 Mobile Phone Platform Countermea-suresPrevious work on relay resistant systems often oper-ated under the assumption that the contactless token wasa resource-limited device that relied almost entirely onthe reader to function.In comparison,an NFC-enabledmobile phone platform acting as token has relativelyabundant resources,such as its own power supply,ad-ditional communication links,increased processing ca-8pability and a selection of hardware peripherals.Theresource-limited paradigmshould therefore no longer bea constraining factor when considering relay counter-measures.4.2.1 Location as Security MetricEven though the use of location information in mobilenetwork access systems has given rise to many applica-tions and services,the capabilities of mobile phones todeduce both absolute and relative location are not utilisedfor verifying the proximity of devices conducting a trans-action.Reliable and accurate location information is aneffective countermeasure against relay attacks,e.g.lo-cation information could be simple appended to a trans-action that is then signed by the legitimate sender [52],and as has also been shown to enable other security ser-vices [69,71].In fact the use of location informationavailable in the mobile environment to provide securityservices is not new [70,72],and could serve as an idealcountermeasure in NFC systems,which as intrinsicallylinked to mobile.In this section,we discuss the potentialrole of mobile location-based services in preventing relayattacks on transactions between NFC-enabled phones,oran NFC-enabled mobile phone and a reader with knowl-edge of its own location.Figure 4:Network cell broadcast based location sensingand triangulation.Network Cell Broadcast The simplest method of re-trieving mobile location information is using metricsfrom the cell broadcast towers or base stations.Theseinclude a Cell-ID identiﬁer associated with parameterssuch as Mobile Country Code (MCC),Mobile NetworkCode (MNC) and Location Area Code (LAC).The cellbroadcast information can be retrieved by using loca-tion APIs fromthe mobile software platformor fromthe(U)SIM.This approach is applicable to most traditionalmobile phones used in mobile network access systemssuch as GSMand UMTS.Figure 4 shows and example of a cell broadcast lo-cation sensing and triangulation method.The Location-Code (LC) for Base Station 1 can be constructed by themobile phone as,LC = 23415300564404719,where MCC = 234 |MNC = 15 | LAC = 30056 | Cell-ID = 4404719According to [73],if the locations of the towers andbase stations are known then the most probable position(x,y) of the mobile phone can be calculated based on thereceived signal strength,to be either one of the two val-ues represented by equations (6) or (7) as derived below.In Figure 4,(x1,y1) and (x2,y2) represents the coordi-nates of two base stations.Their mean distances to themobile phone are d1and d2respectively.The distancebetween the two base stations,dbts,can be derived as,dbts=q(x2−x1)2+(y2−y1)2(1)l1=(d1+d2) −dbts,l2=qd22−l21(2)sin(a) =(y2−y1)dbts(3)cos(a) =(x2−x1)dbts(4)The point where l1and l2meets P,(xp,yp),can be ob-tained as,xp=x2−l1(cos(a)),yp=y2−l1(sin(a)))(5)Then we get,x =x2−l1(cos(a)) −l2(sin(a)),y =y2−l1(sin(a)) +l2(cos(a)))(6)x =x2−l1(cos(a)) +l2(sin(a)),y =y2−l1(sin(a)) −l2(cos(a)))(7)This calculation can either be performed by the mobilephone,the mobile network operator or a third party loca-tion services provider.Unfortunately,the determinationof location from the received power of cell broadcasts isknown to lack precision and consistency due to the spa-tial and temporal variations of the radio environment.Asa measure for determining relative separation betweendevices it should work over long distances (with respectto the cell radii),although its effectiveness over shorterranges in uncontrolled physical environments cannot be9relied upon.Therefore it may provide a strong separationindicator for long range relaying via GPRS and a weakerindicator for a shorter range relay bearer such as Blue-tooth.Similarly,a cell diameter can be quite large so ifusing only Cell-ID a relay attack mounted from withinthe same cell would be difﬁcult to detect,and an efﬁcientcountermeasure would ideally need to obtain parametersfrommultiple neighbouring cells to improve the locationresolution.When both parties are connected to differentmobile network operators the Cell-IDs and LACs couldalso vary.Hence,care needs to be taken in design ofthe application that generates the location information inthis way and its veriﬁcation.There are also viable secu-rity threats to mobile location information integrity,suchas false base station attacks [76].Figure 5:GPS based location sensing and triangulation.GPS Based Location Sensing The Global Position-ing System (GPS) is a navigational system based onearth-orbiting satellites and provides location informa-tion around the globe.GPS ﬁnds applications in manyﬁelds such as transportation,aviation and shipping.TheGPS system is based on 24 satellites in six differentorbital-paths.The satellites and the receivers are syn-chronised with high precision clocks which is used to es-timate the distance between them and the receiver.AGPS receiver requires an unobstructed line-of-sight toat least four or more satellites in order to calculate itsthree-dimensional position (latitude,longitude,altitude).However,with three satellites in viewthe receiver is ableto compute its two-dimensional location (latitude,longi-tude) [74].Figure 5 illustrates the GPS based locationsensing and triangulation method.In the ﬁgure,direp-resents the distance of ithsatellite from Earth.c is thespeed of light (299,792,458 m/s).ΔT is the time differ-ence of signal sent from the satellite and received on theEarth.di2=(xi−x)2+(yi−y)2+(zi−z)2,dj2=(xj−x)2+(yj−y)2+(zj−z)2,dk2=(xk−x)2+(yk−y)2+(zk−z)2(8)By solving (8),and after error corrections we get,[X,Y,Z] where X = longitude,Y = latitude,and Z = alti-tude.An increasing number of mobile phones containGlobal Position System (GPS) receivers.GPS is a re-liable system for determining the location of the phone.Most mobile phone platforms allow access to GPS loca-tion information through public APIs.The GPS receiverscan be categorised broadly as follows:• Integrated/Autonomous GPS:Here the GPS re-ceiver is embedded within the mobile device.Themost accurate location sensing,is achieved whenthe receiver can receive the satellite transmissionsclearly without any obstruction.• Assisted GPS:In Assisted GPS (A-GPS),directsatellite observation and a network “server” is usedto generate accurate position information.A-GPSthat is network assisted could faster compared tointegrated GPS,and perform better in poor signalconditions.A-GPS devices cannot work outside themobile network coverage region as it needs to beconnected to the servers.• External GPS:An external GPS is a physically sep-arate device that can be linked to a mobile deviceover interfaces such as Bluetooth or USB.Deriving location information from GPS also has somedisadvantages.A mobile phone would need to beequipped with a GPS receiver and the accuracy of in-tegrated receivers is greatly diminished when operatingindoors,where you would expect most transactions totake place.Other Location Mechanisms There are a number ofother method for determining device location,even FMradio technology has been proposed as a localizationtechnology [75],although these are not as directly linkedto mobile phones as Cell-IDand GPS.All that is requiredis that two devices can with some certainty verify thatthey are in close proximity to each other.This only re-quires the devices to be aware of their relative location,i.e.where they are with respect to each other,so abso-lute location information is not needed.More peripheralsfor wireless sensing and communication are being inte-grated in mobile phones and it is possible that these couldeventually be used to construct proximity proofs.There10(a) Prover - Phone A(b) Veriﬁer - Phone BFigure 6:“Prover” and “Veriﬁer” mobile phones computing proximity based on location information.are several proposals for how two devices can verify thatthey are in the same location.For example,in multi-channel protocols [77] the device associates additionalmedia that is difﬁcult to relay with the transaction,e.g.both devices can hear the same audio or are observing apicture known to be in the area (one of the device couldgenerate the audio or picture).An area could also be as-sociated with a location ‘dongle’ or beacon [78],and ifboth devices can observe this dongle during the transac-tion they are likely to be in a speciﬁc location.Althoughthese proposals are interesting we are of the opinion thata countermeasure should ideally use the location infor-mation already available on the devices in question.Wetherefore implemented a proof-of-concept proximity lo-cation application using GPS and mobile network Cell-ID information.Practical Proof-of-Concept Implementation When atransaction uses location information as an additional se-curity metric,it could potentially detect relay attacks.For example,a device would simply incorporate a loca-tion signature into the transaction data,which could bechecked by the recipient and compared to its own loca-tion in order to verify device proximity.The location in-formation may be generated by using any of the methodsdiscussed previously.Based on this information a loca-tion signature record could be constructed as follows:<location proof><issuer>Issuer’s Public Key</issuer><recipient>Recipient’s Public Key</recipient><location information><gps><lat>51.42869568</lat><lng>-0.56286722</lng></gps><mcc>234</mcc><mnc>15</mnc><lac>30056</lac><cellid>4404719</cellid></location information></signature>D09A3B57D49CA179</signature></location proof>A simple proof-of-concept countermeasure applica-tion was implemented in order to demonstrate the fea-sibility of retrieving location and verifying proximity be-tween two transacting parties.The mobile applicationswere developed and installed on two Nokia N96 mobilephones (“Prover” and “Veriﬁer”) that are based on Sym-bian S60 3rdEdition FP1 platform [79].For each mo-bile phone a native Symbian C++ application was devel-oped and installed that had access to restricted low-levelAPIs such as network,location,communication,and se-curity APIs.The application was code signed accordingto [80] in order to allow access to the restricted APIs.A J2ME/MIDP 2.0 application implemented the Blue-tooth API (JSR82),proximity veriﬁcation,and graphicaluser interface.The proximity veriﬁcation was performedbased on the location information retrieved.Cell broad-cast information was used to check whether the Proverand Veriﬁer are connected to the same mobile cell.GPSco-ordinates were also retrieved and by using the Haver-sine method [81] the distance between Prover and Veri-ﬁer was computed.Accurate GPS (by using integratedGPS) based location information was derived outdoorswhereas location information using A-GPS was derivedindoors.For both methods of location sensing,the J2MEapplication relied upon native Symbian application.Bothmobile phones interacted with each other over Bluetoothcommunication.For instance,the Veriﬁer would send arequest to the Prover to reply with its location informa-tion,which is compared by the Veriﬁer to its own loca-tion.An example message exchange between the Proverand Veriﬁer is shown in Figure 6.Here the Cell-IDs of11the two phones do not match,but the GPS informationis sufﬁcient to determine that the phones are actually inclose proximity (approximately 6 m).If the phones werefar apart,and the communication was relayed,the ver-iﬁer would observe,from the location information inte-grated into the transaction data,that the legitimate proveris not within proximity,and the attack would be detected.The disadvantage to using such location-based secu-rity in contactless systems,apart from the potential in-consistency of the radio environment and lack of pre-cision,is that both parties need to be location aware.NFC-enabled handsets would be able to derive and ver-ify location information but conventional contactless to-kens would not beneﬁt fromthis countermeasure.Fixed-location POS devices could potentially be programmedwith its known location during installation.4.2.2 Relay resistance at the communication layerThere are some aspects of the underlying communicationprocesses that could be used to detect a relay attack.TheNFC controller is responsible for all physical communi-cation operations,such as anti-collision,token selection,communication parameter setup and data formatting fortransmission.During anti-collision and token selectionthe hardware UID of the token is normally used.Thelegitimate device and the proxy-token should in theorytherefore have different UIDs.If the transaction data islinked to a UID,the verifying recipient should observethat the UID in the data does not correspond to the UIDof the device it is communicating with,thus detecting therelay.In some systems this countermeasure is possiblebut increasingly contactless tokens are transmitting ran-domidentiﬁers during anti-collision as a privacy preserv-ing/untraceability measure [82].Furthermore,the Black-berry emulation API allows the UID to be set by the ap-plication,and although our attempt to get this to workwithin the token emulation proﬁle we used was not suc-cessful,we assume that this functionality will be avail-able.Binding the transaction data to a UID would there-fore be of little use,in cases of random identiﬁers,orprovide no advantage in terms of security if the attackercan set the UID of the proxy-token.The emulation application passes any data to be trans-mitted to the controller,which is responsible for fram-ing and error correction as needed.For example,in ISO14443 each data byte is transmitted along with an oddparity bit and a 16-bit CRC is appended to the message.When using ISO 14443-4 formatted APDUs these paritybits and CRC bits are sent in plaintext and removed fromthe message by the recipient.Some contactless tokensonly partially adhere to standards.One such proprietaryproduct,Mifare Classic [83] also encrypts the parity andCRC bits.It is not thought possible to relay this commu-nication with our relay implementation as it is not pos-sible to retrieve the encrypted parity and CRC bits fromthe controller (it is mostly likely that the controller willdiscard the message since what it considers to be plain-text parity and CRC bits will not match to the rest of thedata).As a result,the message fromthe legitimate tokencannot be captured or transmitted to the reader in its trueform and the relay will fail.The Blackberry emulationAPI does allowfor emulating and reading Mifare Classictokens but in this case the attacker would need the rightkey to interact with the legitimate card and reader.How-ever,proprietary tokens,especially Mifare Classic,haveoften been shown to contain signiﬁcant security vulnera-bilities [84,85] so using such a product purely as a relayattack countermeasure is not at all recommended.Figure 7:State diagrams:(1) emulation API routineshowing relay,and (2) relay protection.4.2.3 Application RestrictionsOne immediate solution to prevent the discussed attacksis to remove the “soft-SE” and the associated emulationAPI altogether.However,this may not be acceptabledue to the beneﬁts associated with a open developmentphilosophy.The contactless applications based on “soft-SE” can utilise fast processing and large memory capac-ity of the mobile phone.The “soft-SE” approach al-lows more ﬂexibility and control for the end-user to man-age emulated contactless applications,and is indepen-dent to the mobile network,or speciﬁc Trusted ServiceManager (TSM) controls.An intermediate solution is tostrengthen the control that the run-time environment hasover applications implementing the emulation API.Thestate diagramof soft-SE emulation API routine is shownin Figure 7.(1).It illustrates the Process (P),Delay (D),Relay (R) and some possible state transitions.The coreof the emulation API is processCommand() function (asshown below),and is responsible for handling the com-mand messages fromthe contactless reader.12net.rim.device.api.io.nfc.emulationVirtualISO14443Part4TargetCallbackbyte[] processCommand(byte[] command){...}The parameter ‘command’ contains the ISO 14443-4command sent by the external contactless reader.Thefunction returns a byte array containing the response tobe sent to the external reader.In order to implement therelay attack,the command was initially captured and sentover the relay bearer.The application then enters a delaystate until the response is available to be returned to thereader.As shown in Figure 7.(2) any application that hasentered state P (received command froma reader) shouldnot be allowed to execute arbitrary delays (state D),or infact be allowed to invoke other communication calls totransmit the command or facilitate the reception of therelay response (state R).Alternatively,there could alsobe additional restrictions on the use of the API,such asnot allowing the application identiﬁer (AID) to be set to avalue reserved for security sensitive applications,unlessadditional developer veriﬁcation has taken place.Thiscould potentially be incorporated into existing applica-tion signing processes.We have considered the possibil-ity that such a system could be implemented using ap-plication permissions.Applications executing on mobileplatforms need to be granted,normally by the user,per-missions for performing certain functions or for havingaccess to certain data.Permissions in their current form,unfortunately,does not seem to be a suitable vehicle forthis countermeasure.None of the permissions on NFCplatforms we worked with,Android 2.3 and Blackberry7,contain the type of restriction we need to implementthis scheme.Also,as permissions are largely controlledby the user an attacker could simply grant his attack ap-plication,running on his mobile device,the required per-mission.5 ConclusionIn this paper we described the ﬁrst generic practical im-plementation of a contactless relay attack using onlyNFC-enabled mobile phones and software applications.We were able to build a passive proxy-token,a proxy-reader and a suitable communication channel betweenthe proxies by using only publicly available platformAPIs.Our relay attack demonstrates the a reduced com-plexity of attack as it did not require special hardware.The attack implementation required no unlocking of de-vices or secure elements,no hardware or software modi-ﬁcation to the phone platform,and minimal knowledgeof the data that was to be relayed.Neither was thereany need to access the mobile network or any related ser-vices,and we utilised devices of a form factor acceptedby merchants.The attack implementation was applica-tion independent so would work against a number of con-ventional contactless systems.For example,we experi-mentally veriﬁed that the implementation work againstboth test payment and e-passport systems.The attacktherefore holds implications for all contactless systemsand can be implemented against any system using NFCor compatible technology,with a few exceptions as dis-cussed in Section 4.2.2.Research work on relay attacks,preceding this paper,have often been dismissed by sys-temimplementers as a complicated attack that is unlikelyto be used in the real world.The ‘software-only’ natureof this relay attack implementation increases the likeli-hood of it being used in practice (e.g.an attacker simplydownloads the applications),and so represents a poten-tial threat to real-world systems.This paper effectivelydisproves the opinion that relay attacks are complex at-tacks that do not translate to an effective real-world threatas argued in [31,32].The effectiveness and ease of the attack means thatticketing,payment (credit card and mobile wallets) andaccess control application need to be hardened againstrelay attacks.Currently,virtually no deployed productsimplement relay resistant mechanisms,with the excep-tion of NXP’s new Mifare Plus smart card and that hasup to now only seen limited deployment and it is un-known how many systems that do use Mifare Plus ac-tually take advantage of this security service.There area number of countermeasures in literature that are con-sidered effective against relay attacks,and mobile plat-forms have much possibilities when compared to con-ventional smart cards.We discussed several of these po-tential countermeasures capable of mitigating such a re-lay attack in a mobile environment.The early resultsof this work and suggested countermeasures were sharedwith relevant industry parties so that appropriate reme-dial measures could be considered such as changes tostandardisation and implementation choices.The use ofSEs that may be misused as development attack plat-forms also raises interesting questions regarding SE ar-chitecture and application management.Our future workwill investigate whether a security framework for “soft-SEs” could be implemented that promotes the open de-velopment platform philosophy while at the same timeprotecting against ‘malicious’ applications misusing theplatform.AcknowledgmentThe authors would like to thank Crisp Telecom Lim-ited (UK),Giesecke & Devrient (GmbH) and Comprion(GmbH) for providing equipment support.We wouldalso like to thank secunet Security Networks AGfor pro-viding eMRTD reader software.13References[1] EMV.EMV Contactless Speciﬁcations for Payment Systems.EMV Communication Protocol Speciﬁcation.Version 2.0,Au-gust 2007.Online:http://www.emvco.com/.[2] VisaR