Kaspersky Lab 2011 European Cup Conference for Young Professionals: IT Security for the Next Generation

Kaspersky Lab 2011 European Cup Conference for Young Professionals: IT Security for the Next Generation Submission Paper: Mr Christopher Smith Production Date: 20/11/2010 Title: Category: Author: Institute: Thanks for the Coffee: A Practical Relay Attack Against ISO-14443 Contactless Payment Protocols Emerging Threats Banking Security Smith, Christopher University of Birmingham, Birmingham, ENGLAND Course: MSc Computer Security (Year 1) Supervisor: Dr. Tom Chothia PhD Introduction In today s society, Radio Frequency Identification (RFID) systems typically have many varying applications which are, for the most case, unbeknown to the majority of those who use them. Their use ranges from basic implementations and extends to the most intricate and advanced architectures for applications in high security protocols. Regardless of their intended purpose, all RFID systems work on the basis of so-called tags or transponders that communicate with a Radio Frequency (RF) interface via a ping/pong of wireless messages [rfidjournal.com, 2005]. By far, the most interesting of RFID tags that are currently in use, have been termed Contactless Smart Cards. These comprise of a simple RFID transponder, as well as an integrated embedded system, resulting in high processing capabilities [Weiß, 2010]. The operation of these smart cards is governed by the ISO/IEC 14443 standard, which defines the physical characteristics, power/signal interface, initialisation process and transmission protocols which must be adhered to [International Standards Organisation, 2001]. Implementations of this standard can already be seen to be in the public domain, such as the checking of e-passports and the use of public transport systems [Garcia et al., 2008]. The ISO standard defines two common terms which we will continue to use here: Proximity Coupling Device (PCD) Analogous to an RF interface or tag reader Proximity Integrated Circuit Card (PICC) Analogous to a tag or transponder Particularly over the past decade, the UK has seen huge advancements with regards to banking security, such as the introduction of Chip-and-PIN, two-factor authentication via the Chip Authentication Protocol (CAP), and the newly introduced Wireless Payment System (based predominantly upon ISO/IEC 14443). Each of these steps in increased security may at first appear

to cut down on the possibility of fraud and improve the protection of the consumer. However, weaknesses exploited in each suggest that bank systems are developed not under the premise that they are to be completely secure, but that they appear to be secure. More precisely, banks fully accept that fraud is a very real problem on any consumer system they design, and are only concerned that the long term profits of using such a system outweigh the foreseen losses. Such a design premise has seen many victim s out-of-pocket, since the Banker s Code habitually places the onus from using such systems onto the consumer [Anderson et al., 2006]. The recent research made into the failures of these systems leads us to believe that the acute compromise needed between usability and security in the Wireless Payment System has yet again been misjudged, and this initiated our interest to attack the devices which have recently been introduced to the UK and other countries within the European Union [Visa, 2010]. This research seeks to discover whether such an attack is possible by attempting to engineer a relay and pay for a cup of coffee using the credit card of an unknowing victim. We also consider how far the attack could be developed in order to gain significantly and maximise benefit for the attacker. Our work led us to creating a system capable of relaying RFID tags. We were able to relay a UK e- Passport, and pick out the steps of the BAC protocol which governs access to the data contained on its chip. We were also able to determine that the relaying of contactless payment cards is currently unable to be done via USB readers due to timing constraints which are involved. We looked at why this was the case, and in doing so partially reverse-engineer Visa s PayWave protocol, whilst postulating as to the consequences of the attack eventually being used for criminal purposes. Figure 1.1: A Sample MasterCard PayPass PCD Background Research The theoretical concept behind Relay Attacks has been around for decades. A good example of a practical application of this was demonstrated by TV illusionist Derren Brown, when he simultaneously played chess against nine world-class players and won [break.com, 2007]. Whilst at

first this might seem a very impressive feat, Derren proceeds to explain exactly how he pulled off such a stunt. He begins by mentally pairing the players (who are sat in a circle), whose partner is directly opposite them. A pair of players consists of one person playing white, and the other playing black. When one player makes a move, it is simply mimicked on the other player s board. Derren is not playing chess at all with these players, but playing them against each other by replicating their opponent s move. Clearly, no mention of Relay Attacks is mentioned in the footage which Derren showed on TV, but it is obviously what is the case here. We can apply the same idea to a computing context. In this case, we purposefully create an extension cord by which a transponder is able to communicate with a given reader (see figure 2.1 [Weiß, 2010]). As a consequence, it is possible to fully run a protocol without the knowledge of the tag s owner - opening up a great many more possibilities of attack. Since many RFID systems are short range, they work on the principle that if the tag is in the vicinity, it must be because the owner has sanctioned and authorised it. With the application of a relay, this principle is violated, which is what can be exploited. To construct such a relay, the attacker must design two devices, depicted in figure 2.1(a) [Weiß, 2010]: Emulated Reader - To read and interrogate the genuine transponder Emulated Transponder - To emulate the responses sent from the actual transponder In relaying all communication between the reader and a tag, we create what is known as a Mafia- Fraud attack. This is particularly important with regards to what the relay is being used for. A relay attack is still termed as such even if it cannot be classified as Mafia-Fraud e.g. if only certain messages are chosen to be relayed. The advantage Mafia-Fraud has, is that all communication is relayed, including all higher level cryptographic communication. If cryptography is being used, the attacker would not be able to view communication in plaintext, but this is not needed so long as respective messages continued to be relayed. The attack may also be given an active twist by relaying an initial authentication sequence, after which data gets modified [Hancke, 2005]. In his paper A Practical Attack on ISO 14443 Proximity Cards, Gerhard Hancke describes the first practical relay attack on an RFID system [Hancke, 2005]. His approach attacks the physical layer of ISO/IEC 14443, by constructing the two hardware devices mentioned above. In Hancke s implementation, the emulated reader is referred to as the Mole, and the emulated transponder as the Proxy. By developing his own hardware, Hancke was able to perform the required analogue modulation/demodulation at each end, and relay the digitally encoded data packets using short range RF communication. This meant that the strict timing collisions present in the anti-collision protocol were actually of no concern in his implementation. Hancke s work, although interesting, requires somewhat idyllic circumstances in which to be applied. His hardware introduced a delay of 15-20us which is well within the timing constraints specified by ISO/IEC 14443. However, to actively gain from this attack in the real-world, an attacker would likely need to rely upon network connections which typically invoke large delays. To solve this, Michael Weiß describes a theoretical approach to applying a relay attack on the application layer [Weiß, 2010]. He postulates

that since the timing constraints are strictest in the anti-collision procedure, then handling anticollision commands directly and relaying all other payload frames might solve the problem. Weiß describes three different implementations in his paper, all of which use off-the-shelf NFC components: Phone and Phone, Phone and USB, USB and USB. Unfortunately, whilst his work proves that the construction of a relay is theoretically possible within a lab environment; restrictions meant that he was unable to apply this to a real-world system. As such, it remains unknown as to whether there are other restrictions imposed which hinder this type of attack. Figure 2.1: RFID Relay Architecture

Attack Design We now describe the architecture used for implementing a relay against Visa PayWave. The first architecture we considered used one NFC mobile phone and one USB device. However, this was found to not be possible since the Secure Element must be unlocked for our usage [van Beek, 2010], thus making the device untrusted by merchants PCD s. We therefore present the second architecture using two USB devices, which the final relay is modelled on (due to complexities with programming the Proxmark III [Garcia, 2010], we disregarded this as a possibility). Chosen Architecture: 2x USB Readers This architecture uses cheap off-the-shelf USB readers for the relay (figure 3.1), which utilise the PN53x chip developed by NXP to support the different possible modes of NFC. The advantage these readers provide is that they can replicate much of the functionality of the Proxmark III device via the use of LibNFC and RFIDIOt [Garcia, 2010]. In contrast to other architectures, LibNFC is able to provide access to the lower layers of the ISO standard [Verdult, 2010a], allowing the developer complete control over lower level protocols such as anti-collision. However, this does mean that the anti-collision procedure described in ISO/IEC 14443 needs to be manually handled at both ends of the relay. In contrast to a similar relay which Weiß constructed [Weiß, 2010], we chose to remove the TCP socket as a means of transferring data, since we were originally concerned about the delays incurred from its usage. Instead, we decided to implement both the Mole and Proxy on a single host, and relay commands from one to the other entirely through software. Figure 3.1: Contactless Readers Acquired for Relay We acquired two different types of USB readers for the construction of the relay. The first was the ACR122U developed by Advanced Card Systems Ltd (see figure 3.1a). This reader is based on the PN532 NFC Controller Chip, enabling it to emulate either a PCD or a PICC [Verdult, 2010a]. Despite this reader having an additional IC through which commands must travel, the added delay was deemed a necessary risk because of the time and finance limitations imposed. The second reader purchased was the Omnikey Cardman 5321 (see figure 3.1b). In contrast to the ACR122U, the design of this reader is not based upon the PN53x Chip, thus limiting its use as a PCD only. We therefore purchased 2x ACR122U readers for the relay, and used the Omnikey to emulate a PayWave reader in our tests.

Sample Contactless Cards In order to successfully construct a working relay, we inevitably required a number of contactless cards with which we could perform tests. In light of this, we sourced the sample tags shown below (sensitive data has been obscured for the privacy and protection of various individuals): PayWave Credit/Debit Cards - Clearly, we would ultimately require PayWave enabled payment cards. We therefore sourced two such cards (1x credit, 1x debit) from Barclays. MIFARE Classic Cards - Since we had no initial knowledge as to how PayWave operates, we decided to obtain some MIFARE Classic cards which have been previously been covered by researchers in detail. Two cards were readily available - one being a university ID card used for secure building access, and the other being a London Oyster travel card. UK e-passport - Finally, we had some UK e-passports to hand. We decided to source these since the Basic Access Control (BAC) protocol which they implemented was known and fully understood by previous work having been undertaken [Chothia and Smirnov, 2010]. Figure 3.2: Sample Tags Acquired for Testing Purposes

Implementation & Results Here we describe the investigation process which was undertaken, enabling us to arrive at our conclusions about Visa PayWave which we later discuss. We also review the setbacks which presented themselves, and the actions taken to overcome them. Preliminary Investigation We began our investigation by undertaking simple tests on the PayWave cards to try and find out as much information as we could about the way in which they operated. Our research on the cards told us that they were High Frequency (13.56MHz) cards implementing ISO/IEC 14443(A) just like that of MIFARE. Our initial hope was that the banks had been foolish enough to use actual MIFARE Classic cards, which have already been broken due to algebraic flaws found in the CRYPTO-1 cipher [Garcia et al., 2008]. Unfortunately, differences in the card s Answer-To-Reset (ATR) values (which would identify MIFARE quality) proved this not to be the case: Table 4.1: ATR Values from various RFID tags Constructing a Brute-Force Application Based on this knowledge attained, we proceeded to construct a brute-forcing application which fired all possible APDU commands at the payment cards and analysed their responses. Since we knew that the implemented protocol was built on top of ISO/IEC 7816, we could search for a response code of 9000 indicating that the command had been accepted [International Standards Organisation, 2005b]. The ISO documentation also revealed that proprietary commands were prefixed with byte 0x80, dramatically reducing the searchable space. However, this didn t work. Whilst technically the idea was sound, it suffered from two major problems: Our program failed to recognise that proprietary protocols are not tied into using proprietary APDU commands, and may well share the commands specified by standards such as ISO/IEC 7816. This presents a big problem, since the 7816 APDU commands do not have a consistent CLA byte (the most significant byte), thus resulting in a vast (inconceivable) number of additional APDU possibilities to try. Secondly, whilst the commands we saw in the documentation of the readers were relatively short [Advanced Card Systems, 2008], the ISO documentation states that APDU commands may be anything from 1-255 bytes in length [International Standards Organisation, 2005b]. It is therefore highly possible that APDU commands are in use which have a length much longer than the 10 bytes which we assumed as a maximum.

Modifying the MITM Attack Following this, we decided to retract from the problem of which APDU commands the cards recognised, and turned our focus to constructing a relay. After all, if the relay could be made and proved to work flawlessly, relaying a live system would display PayWave in its entirety. Nick von Dadelszen and Adam Laurie provide support for a man-in-the-middle attack in the latest version of RFIDIOt, but we found it to suffer from various pitfalls making it problematic for use in an attack situation. We therefore used this script as a basis, but modified it to provide additional functionality: Removal of time constrained polling Removal of immediate card connections The maintaining of a connection session Notification sounds for the attacker To check whether we had retained the core functionality of the relay, we designed a test script to relay the selecting of a card as well as some other ISO/IEC 7816 APDU commands. The emulated PICC responded to the script with 75% of the card s UID and a number of error responses. The UID was incomplete since it was prefixed with byte 0x08 - a feature defined by the ISO to specify that the UID bytes are random and not hardcoded into the PICC [International Standards Organisation, 2001]. This setup is depicted below in figure 4.1: Figure 4.1: Locally Relaying a Visa PayWave Card Relaying an e-passport With an indication that the modified relay seemed to work, we proceeded to relay a UK e-passport and pick out the individual steps of the BAC protocol. This was chosen since we had a full understanding as to how BAC worked [Chothia and Smirnov, 2010], and it also demonstrated that

the relay was capable of working with a live system. The latest RFIDIOt release comes with a script to login and read an e-passport chip [Laurie, 2010]. We setup the relay and presented our emulated PICC to the Omnikey. The following trace was observed, and figure 4.2 shows the output of the data which was successfully relayed: Listing 4.1: Trace from relaying an e-passport Figure 4.2: Relaying the Machine Readable Zone of an e-passport Field Test 1: EAT, Birmingham (ENGLAND) With everything set up, we approached the cafe store EAT where we attempted to falsify the purchase of a sandwich. When the emulated PICC was presented to the shop reader, there was no indication as to whether the PICC had been recognised by the PCD. We reviewed the APDU trace recorded from the relay session and saw that the program had hung at `Waiting for emulation activation by PCD'. This suggested a failure in the anti-collision protocol of ISO/IEC 14443.

Our initial thoughts were based on an observation made previously - the UID of the emulated card was incomplete. A simple countermeasure to immediately circumvent this type of attack would be for the banks to deny anti-collision based on the first UID byte being 0x08. If this was the case, then we had found yet a further example of Security by Obscurity implemented by the banks. This left us thinking about methods to bypass the problem, and four possibilities presented themselves: Modification of RFIDIOt Attempt relay via LibNFC Manually create a clone via a JCOP card Obtain a Proxmark III Of these potential work-arounds, LibNFC proved to be the most beneficial. In researching the emulation facilities provided by LibNFC, it appeared that full UID emulation was possible by altering the UID bytes of the emulated PICC after anti-collision had taken place. However, since the shop reader didn t even get this far, we were still faced with a problem. Achieving Full UID Emulation The solution to this problem lay in the fact that we had access to multiple readers, and how a contactless card assumes a number of different states when it is being accessed by the PCD. Since we discovered it possible to programmatically modify the full UID once anti-collision had taken place, all that was required was to fake the anti-collision process locally. Consequently, the first anti-collision process was used to prime the emulated PICC with the initialisation UID, after which control was handed back to program to update this with the real UID. Because the PICC maintains an ACTIVE state following the first anti-collision, the modified UID is retained and picked up by the second anti-collision. Consequently, the shop s PCD believes it is communicating with a genuine tag, whereas in fact it has been hoodwinked into communicating with an emulated tag. The result: 100% UID tag emulation. Field Test 2: EAT, London (ENGLAND) We returned to EAT, this time to simply perform anti-collision with the shop reader. We noticed that the PayWave system responded to UID s with and without a first byte of 0x08. We also observed that the PayWave system initiates the anti-collision process with a WUPA command instead of REQA (as is typical of anti-collision). This doesn t actually alter things at all, since the card s respond with the ATQA message in each case - but it was interesting to note the variance. Unfortunately, the results show that the ATQA response from the card is not being sent before the PCD times out and transmits another REQA request. This suggests that the banks are perhaps not blocking UID s which start with 0x08, and we postulate that the problem could lie within the strict timing constraints in the anti-collision process as discussed by Hancke [Hancke, 2005]. Despite multiple optimisations being attempted to run a more efficient relay, the conclusion was drawn that USB readers are simply too slow to be used in the relay of PayWave cards.

Reverse Engineering of Visa PayWave Our analysis of the RFIDIOt suite [Laurie, 2010] showed that the contactless cards supported a number of commands taken from the ISO/IEC 7816 standard, which governs the usage of Contact Based Smart Cards. Using this, we constructed a test script which connected to a Smart Card reader, and sent a manually programmed command to the card. We were then able to determine two things: Whether the command was sent successfully or not What precisely this meant If the command didn t succeed, we would receive a 2-byte error code from the card, which could be looked up in table 5.1 for its corresponding meaning. If the command did succeed, we would receive response code '9000' and be able to analyse the data buffer that was returned from the card, to understand what effect the command had. Table 5.1: Interindustry Values of SW1-SW2 ISO/IEC 7816 Responses Step 1: Selecting the Visa Application Firing any other command before SELECT FILE resulted in error '6D00 Instruction Code Not Supported'. This indicated that the command was either not supported by the contactless standard at all, or that another command needed to be issued in advance. From this, we were able to probe the card for error responses and find out the order in which commands were to be sent. Calling this method with a random file name resulted in error '6A82 File Not Found'. This indicated that the command had been accepted by the card, but the filename was incorrect. We brute-forced the filename space and discovered the following files:

Table 5.2: Files Identified on a Visa Contactless Payment Card These files (or applications ) are the same as those employed by systems such as the Chip Authentication Protocol (CAP) [Drimer et al., 2009]. From this we can suggest that the first application contains data and settings which are specific to the issuing body (in this case, Barclays), and that the actual protocol lies entirely within Visa s own application. Step 2: Obtaining Authentication Data For the second step of the protocol, we envisaged that the card would respond to a command that it had rejected the first time around, having now issued SELECT FILE. We found that by issuing a GET CHALLENGE command to the card, with length parameter 8, the card populates the response buffer with a 64-bit (8 byte) nonce. At this point, it began to appear like we were dealing with a glamorous challenge-response protocol, similar to that used by other key exchange protocols (e.g. Kerberos, Needham Schroeder and BAC) [Sorge, 2010; Chothia and Smirnov, 2010]. Most likely, the next stage would involve encrypting this nonce and sending it back for authentication. Step 3: Initiating the Authentication Sequence The only command which subsequently responded was now EXTERNAL AUTHENTICATE. When we issued this command following SELECT FILE and GET CHALLENGE, we received: '6700 Incorrect Parameter Length'. After brute-forcing the field with increasing lengths of data, we established that the ciphertext must be either 20 or 21 bytes long, resulting in an error response of '6985 Conditions of Use Not Satisfied'. This likely indicates that EXTERNAL AUTHENTICATE is next in the sequence of commands used by PayWave. However, to conclude much else is very hard to do, since we are dealing with encrypted data done using an unknown cipher or encryption key. We postulate the following, through additional experiments (and not from firm evidence): 1. The 8-byte nonce from GET CHALLENGE is what gets encrypted and passed to the EXTERNAL AUTHENTICATE command for authentication by the card. 2. The encryption scheme is most likely based on the 3-DES cipher which is commonly found in Smart Cards (e.g. EMV, Chip-and-PIN, and e-passports). 3. The key likely comprises of the card s UID (which is static). If we assume that 3-DES encryption is in use, then a 168 bit key would be required, suggesting that a SHA-1 hashing scheme is being used in conjunction with one byte of CRC for key integrity. 4. Assuming that the challenge nonce is all that gets encrypted, either one or two bytes of CRC must be appended to the ciphertext in order to satisfy the length constraints.

Protocol Summary The PayWave protocol most likely adopts the structure of similar key establishment protocols such as the Basic Access Control Protocol (BAC) used in e-passports (see figure 5.1) [Chothia and Smirnov, 2010]. We will now display what we believe to be a partial trace of the PayWave protocol (figure 5.2). Here, {-}Ke denotes 3-DES encryption with the key Ke, SHA(-) denotes a cryptographic SHA-1 hash computed over the parameter enclosed by parenthesis, and CRC(-) denotes the computation of CRC byte(s). Figure 5.1: The Basic Access Control (BAC) Protocol Figure 5.2: The (Perceived) PayWave Protocol

Additional Protocol Possibilities In addition to the protocol which we describe, there are a few other schemes which the banks may have chosen to use. Whilst we found no supporting evidence that any of these were being used, we list possible alternative defences for consideration: Hard-coded Cryptographic Keys - It is possible, that instead of the key being derived from the hash of a card s UID, it is hard-coded into both the card and reader itself. This is poor from a security engineering perspective since it leaves the key open to attack, but would prevent the values from which it is derived from being sent between the PCD and PICC, thus protecting it from being sniffed wirelessly by others. Certificate Authentication - Another possibility is that both reader and card are using certificates signed by the bank to authenticate each other as being trustworthy, thus removing the need to execute a key exchange protocol. Public-Key Encryption - The banks may also have implemented a public-key encryption system between the reader and card, but since public-key is expensive and there are likely time restrictions in operation, we very much doubt this.

Conclusion & Outlook We successfully reverse-engineered approximately 70% of the PayWave protocol and constructed a fully working device used to relay communication from a Contactless Smart Card which uses the ISO/IEC 14443 standard. Our relay was able to simulate remote login of a typical e-passport using the Basic Access Control (BAC) protocol, simulate the Dark Side attack to recover the keys from a MIFARE Classic (Oyster) card, and successfully handle the relay of Contactless Payment cards within a laboratory environment. In practice however, relaying the Payment Cards failed due to the stringent timing restrictions defined in the anti-collision protocol. Despite this, we uncovered voluminous amounts of research which might aid in the future cracking of PayWave. Attack Likelihood & Implications From our work, it seems that the only prevention to stop such a relay attack from being executed is the stringent timing restrictions present in the anti-collision protocol. However, there is still a strong likelihood of constructing an attack by which these restrictions are not an issue: The recent development of USB 3.0 brings with it lightning fast communication speeds [usb.org, 2010], making it a very real possibility that adversaries can now answer to the requests of anti-collision within the time constraints specified. Attacker s may also be able to bypass the anti-collision restrictions using USB 2.0, but with the help of multiple readers. Until recent years, the assumption that technology-savvy criminals did not exist may well have been true. However, it would be naïve of us today to assume that this is still the case. The hardware which we purchased in the construction of our relay was inexpensive (less than 100) and readily available. The real ingenuity of the attack lies in the design of the software, but even that only requires a reasonable understanding of essential programming concepts. For the determined adversary, it would be quite trivial to modify the attack once the initial obstacles have been overcome, and we now present two examples of how this could be done: Multiple Adversary Modification By utilising TCP sockets as a communications channel for the attack, the dependency of a queue situation is removed, thus opening the attack to teams of adversaries operating through a bespoke ad-hoc network. Cloud Attack Modification As a variation of the above, if the ad-hoc network is replaced via the Internet, the scale of the attack grows significantly (e.g. country independence). As of January 2010, most EU countries accept contactless payments [Oslo University, 2007], thus making this attack highly lucrative and powerful. Attack Countermeasures There are a number of different countermeasures which can be used to circumvent relay attacks generally. Some however, might not be possible if the functionality of the contactless payment system is to be retained. Several different countermeasures are listed below, in order of what we believe to be increasing effectiveness: Shielding Techniques - The easiest of countermeasures is to shield the RFID transponder from being accessed without consent. There are a number of ways in which this could be done for example using a modified Faraday cage to cancel out electro-magnetic fields around the wallet. Such products are commercially available for the paranoid individual, although a simple foil-embedded wallet will perform a similarly excellent job [Weiß, 2010].

User Management - By placing the user in control of the RFID technology, relay attacks are unable to be performed without their knowledge or consent. In the case of contactless payment cards, they could be modified (admittedly at the expense of more complex hardware) to switch the RFID capabilities on/off as required. Encryption Dependencies - Depending on the encryption used in PayWave, we can offer potential improvements based on what we have seen so far. By randomising the card s UID and using it as part of the encryption key, an attacker is unable to know the UID of the card in advance, thus preventing such a relay from being constructed. Distance Bounding - Distance Bounding protocols are sophisticated versions of measuring the round trip time (RTT) of two wirelessly communicating parties, based on low layers of the protocol stack. The protocols use the same nomenclature as Zero-Knowledge Protocols: namely that of a Verifier and a Prover. Using these, it is possible to accurately measure the distance between the two real devices that are communicating [Weiß, 2010]. Research Outlook In consideration of things as a whole, we are extremely pleased with the progress that has been made, with both the construction of the relay and the steps found in reverse-engineering Visa s PayWave protocol. The responses we received towards the end indicated that we were very close to breaking the Oyster card system and quite possibly even PayWave using a simple Mafia-Relay attack. With no attack currently published on breaking such systems in this way, there is a prospect that it could be the next largest attack on public systems since the breaking of Chip-and-PIN. It would be naïve of us to assume that criminals are not fighting the same battle as we are in an attempt to gain financially from this attack. Our research may well present the initial foothold which researchers need to fully crack the PayWave protocol before criminals do, and suggest the necessary changes required to prevent this attack from being used for criminal purposes. We remain adamant that the banks have been lax in their implementation of PayWave as they have been with similar protocols in the past, and consider it only a matter of time before an attack similar to the one described here, is actively used by criminals in the future.

Bibliography Advanced Card Systems. ACR122U Application Programming Interface, 2008. Ross Anderson, Michael Bond, and Steven Murdoch. Chip and spin. Technical report, University of Cambridge, 2006. break.com. Derren s chess stunt. http://www.break.com/usercontent/2007/4/28/ derren-brown-beats-9-chess-players-283131 [accessed August 20, 2010], 2007. Tom Chothia and Vitaliy Smirnov. A traceability attack against e-passports. Technical report, University of Birmingham, 2010. Saar Drimer, Steven Murdoch, and Ross Anderson. Optimised to fail: Card readers for online banking. University of Cambridge, 2009. Flavio Garcia. Relay attacks. Email Correspondance, 2010. Flavio Garcia, Gerhard de Koning Gans, Ruben Muijrers, Peter van Rossum, Roel Verdult, Ronny Wichers Schreur, and Bart Jacobs. Dismantling mifare classic. University of Nijmegen, 2008. Gerhard Hancke. A practical relay attack on iso 14443 proximity cards. Technical report, University of Cambridge, 2005. International Standards Organisation. ISO-14443 Contactless Integrated Circuit Cards, 2001. International Standards Organisation. ISO-7816 Contact Based Smart Cards, 2005b. Adam Laurie. Rfidiot. http://rfidiot.org/ [accessed August 28, 2010], 2010. Oslo University. Uio country catalogue: Europe. http://www.admin.uio.no/fa/felles/ countries/europe/index.html [accessed September 09, 2010], 2007. rfidjournal.com. What is rfid? http://www.rfidjournal.com/article/view/1339/1/ 129 [accessed August 08, 2010], 2005. Volker Sorge. Key Exchange Protocols - Cryptography Lecture Notes, 2010. usb.org. Superspeed usb from the usb-if. http://www.usb.org/developers/ssusb [accessed September 07, 2010], 2010. Jeroen van Beek. Questions relating to work using libnfc. Email Correspondance, 2010.

Roel Verdult. Nfc anti-collision procedure. http://www.libnfc.org/documentation/examples/ nfc-anticol [accessed August 11, 2010], 2010a. Visa. Visa paywave. http://www.visaeurope.com/en/about_us/innovation/visa_ paywave.aspx [accessed August 09, 2010], 2010. Michael Weiß. Performing relay attacks on iso 14443 contactless smart cards using nfc mobile equipment. Master s thesis, Der Technischen Universitat Munchen, Germany, 2010.