{'fraction_non_alphanumeric': 0.032719140454081384, 'fraction_numerical': 0.012640381156108707, 'mean_word_length': 4.80581428168219, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 1, 'substrings_counts': 1, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Applying recent secure element relay attack scenarios to the real world: Google Wallet Relay Attack

This report explains recent developments in relay attacks on contactless smartcards and secure elements. It further reveals how these relay attacks can be applied to the Google Wallet. Finally, it gives an overview of the components and results of a successful attempt to relay an EMV Mag-Stripe transaction between a Google Wallet device and an external card emulator over a wireless network.


Introduction
Recently, there have been several publications on relay attacks on contactless smartcards and secure element-enabled mobile devices [2,3,4,5,8,11,12]. However, relay attacks on contactless smartcards are not new. In 2005, Hancke [4] first showed that it is possible to relay contactless smartcard communication (ISO/IEC 14443 [7]) over longer distances through an alternative communication channel. Kfir and Wool [8] describe a similar system and also show that the relay device used to access a victims card can be up to 50 centimeters away from the card when using additional amplification and filtering.

Relay Attack
A relay attack can be seen as a simple range extension of the contactless communication channel (see Fig. 1). Thus, an attack requires three components: 1. a reader device (often called mole [4] or leech [8]) in close proximity to the card under attack, 2. a card emulator device (often called proxy [4] or ghost [8]) that is used to communicate with the actual reader, and 3. a fast communication channel between these two devices.
The attack is performed by bringing the mole in proximity to the card under attack. At the same time, the card emulator is brought into proximity of a reader device (POS terminal, access control reader...) Every command that the card emulator receives from the actual reader is forwarded to the mole. The mole, in turn, forwards the command to the card under attack. The card's response is then received by the mole and sent all the way back through the card emulator to the actual reader.
This type of attack cannot be prevented by application-level cryptography (e.g. encryption) [4,5]. The problem is, that the relay attack is a simple range extension of the contactless interface, so neither the mole nor the card emulator need to "understand" the actual communication. They simply proxy any bits of data they receive.
As existing cryptographic protocols on the application layer cannot prevent relay attacks, several alternative methods have been identified to prevent or hinder relay attacks [4,5,8]:  4. Distance bounding protocols can be used on fast channels to determine the actual distance between the card and the reader.
Other measures -like measurement of command delays to detect additional delays induced by relay channels -have been identified as not useful. For instance, Hancke et al. [5] conclude that the timing constraints of ISO/IEC 14443 are too loose to provide adequate protection against relay attacks.

Next Generation Relay Attack
The threat potential of relay attacks was mitigated by the fact that all relay scenarios required physical proximity (less than one meter) to the device under attack. However, recent research [11,12] follows a different approach. Instead of accessing a device's secure element through the external (contactless) interface, it is accessed from the device's application processor through the internal interface. While the original relay attack required mole hardware in physical proximity of the device under attack, pure software on an attacked device's application processor is enough.
The complete relay system, as suggested by [11] and verified in [12] is shown in Fig. 2. It consists of four parts: • a mobile phone (under control of its owner/legitimate user), The relay software is installed on the victim's mobile phone. This application is assumed to have the privileges necessary for access to the secure element and for communicating over a network. These privileges can be either explicitly granted to the application or acquired by means of a privilege escalation attack. The relay application waits for APDU commands on a network socket and forwards these APDUs to the secure element. The responses are then sent back through the network socket.
The card emulator is a device that is capable of emulating a contactless smartcard in software. The emulator has RFID/NFC hardware that acts as a contactless smartcard when put in front of a smartcard reader. The emulator software forwards the APDU commands (and responses) between a network socket and the emulator's RFID/NFC hardware.
The flow of relayed smartcard commands (APDUs) between the smartcard reader and the secure element is shown in Fig. 3. The command APDUs (C-APDUs) received from the point-of-sale terminal are routed through the card emulator and over a wireless network to the victims device. There, the relay app forwards the C-APDUs to the secure element.
The corresponding responses (R-APDUs) generated by the secure element are routed all the way back (through the relay app, the wireless network and the card emulator) to the POS terminal.

Access to the Secure Element
Various schemes for access control to the secure element are analyzed in [11]. While some of them provide sophisticated access control capabilities, all of them have one significant flaw. They all rely on the mobile device's operating system (excuted on the application processor) to perform access control enforcement. Thus, in all cases, the secure element (secure component) blindly trusts the operating system's/application processor's (i.e. insecure component's) access control decisions. Therefore, once an application passes or bypasses(!) the security checks performed by the operating system, it can exchange (arbitrary) APDUs with the secure element.
Consequently, in the worst-case scenario, root access to the operating system is required to bypass these security checks. However, considering the current trend in privilege escalation exploits for various mobile device platforms (cf. [12]), it is assumed that an arbitrary application can gain elevated or even root privileges on most platforms that are currently in the field.

Suitable Relay Channels
In [12], the delay times induced by relaying APDU communication over various channels are evaluated. Fig. 4 shows a comparison of four different paths for secure element access: 1. Direct access to the secure element with an external reader (i.e. no relay), 2. direct access to the secure element with an app on the phone, 3. access through the relay system using a direct WiFi link between the phone and the card emulator, 4. access through the relay system using the mobile phone network and an Internet link between the phone and the card emulator.
Direct access to the secure element through the contactless interface (path 1) takes about 30 ms. On-device access to the secure element (path 2) takes significantly longer (50 to 80 ms). A WiFi connection (path 3) adds an additional delay in the range of 100 and 210 ms. For path 4, the delays start at about 200 ms and have a significant peak around 300 ms. Thus, the internet link adds at least 150 ms of delay. But for more than half of the measurements the total command-response delay was above 1 second.
In practice there are no (strict) timing requirements for payment applications. ISO/IEC 14443-4 provides a frame waiting time extension so that no timing requirements apply to the APDU layer. The EMV specification for contactless payment systems [1] specifies a limit of 500 ms for a contactless payment transaction as a whole (where a transaction already comprises multiple APDU command-response sequences.) Consequently, both relay scenarios are likely to fail these timings. However, a payment terminal is not required to interrupt a transaction if it takes longer than this limit. The limit is merely meant as a benchmark target to maintain user experience. For example, the PayPass terminals used in recent roll-outs in Austria (see Fig. 7) do not enforce any such timings. Also, cloud-based secure element solutions (cf. [10]) like those provided by YES-wallet 1 will only work with relaxed timing requirements.

Applying the Attack to a Real-World Payment System
Videos of the successful relay attack are available on YouTube: • Initial video proof: http://www.youtube.com/watch?v=hx5nbkDy6tc • Re-take, better quality: http://www.youtube.com/watch?v= R2JVPJzufg To verify the applicability of the software-based relay attack, it has been applied to an existing payment system. Google Wallet has been chosen for several reasons: • Google Wallet is already in use by many users. (Google Play Store listed more than 500,000 installations 2 in early 2012. Meanwhile Google Wallet has over 1,000,000 installations.) • It is based on EMV payment standards (specifically MasterCard PayPass using the EMV mag-stripe mode) and can be used with any point-of-sale terminal that supports PayPass contactless credit card transactions.
• The Android source code is publicly available. Thus, it was fairly easy to explore its NFC software stack and its hidden 3 secure element API (com.android.nfc_ extras).
• Google Wallet is known to be installed by many users on rooted devices (mainly to circumvent operator and location restrictions). This means that the operating system's security measures are already weakened/bypassed on those phones.
• For non-rooted devices, there either already exist privilege escalation exploits (up to Android 2.3.5 and on Android 4.0+) or it is assumed that such exploits will appear soon (cf. [13]). Additionally, once an exploit is found/known, it takes several month until devices in the field are patched.

Google Wallet
Google Wallet is a container for payment cards, gift cards, reward cards and special offers. It consists of an Android app with a user interface and JavaCard applets on the secure element. The user interface is used to unlock the wallet (when it was previously locked by a PIN code), to select the currently active card, to find specific offers and to view the transaction history. The analysis and attack described in this paper have been performed with version 1.1-R52v7 of the Google Wallet app and the secure element applets installed in February 2012.
Google has quickly responded to our discoveries by providing fixes in more recent versions of Google Wallet. For instance, the relay attack could not be reproduced with secure element applets installed in June 2012. With recent upgrades of the Google Wallet app, also existing users received the necessary fixes of the secure element applets and are no longer vulnerable to the relay attack scenario described in this paper.
Upon first start, the Google Wallet app initializes the secure element and installs a PIN code that is necessary for using the Google Wallet app's user interface. During initialization several applets are installed and personalized on the secure element using GlobalPlatform card management. Specifically, a secure channel based on the secure channel protocol SCP02 is established between the secure element and a remote server which performs the card management through this authenticated and (partly) encrypted channel.
Executable load-files on the secure element after initialization: • A0000000035350: Issuer Security Domain/Card Manager Google Wallet APDU commands: • 00A4040007A000000476201000: Select Google Wallet on-card component

Google Prepaid Card
The Google Prepaid Card uses the EMV Contactless Specifications for Payment Systems and is a MasterCard PayPass card. It only supports the Mag-Stripe mode with dynamic CVC3 (card verification code) and online transactions 4 .
During a Mag-Stripe mode transaction, the following command-sequence is performed by a POS terminal: 1. POS terminal: Select Proximity Payment System Environment (PPSE) (see Table 1) 2. Card: Confirm selection and respond with a list of supported EMV payment applications (see Table 2) 3. POS terminal: Select MasterCard Google Prepaid Card (see Table 3) 4. Card: Confirm selection and respond with application details (e.g. that it is a Mas-terCard) (see Table 4) 5. POS terminal: Get processing options (see Table 5) 6. Card: Respond with supported mode (Mag-Stripe only, online transactions only, no cardholder verification...) and with the location of the Mag-Stripe data file (see Table 6) 7. POS terminal: Read first record data file (see Table 7) 8. Card: Return Mag-Stripe track 1 and track 2 data (see Table 8) 9. POS terminal: Request computation of cryptographic checksum for a given unpredictable number (UN) (see Table 9) 10. Card: Return application transaction counter (ATC) and dynamically generated CVC3 for track 1 and track 2 (see Table 10 In Android 2.3.4, this API could be accessed by any application that held the permission to use NFC. In later versions, a special permission named com.android.nfc.permission.NFCEE_ADMIN is required. This permission is only granted to applications that are signed with the same certificate as the NFC system service. Starting in Android 4.0, the permission system for the secure element API has fundamentally changed. Permissions to access the secure element are now granted through an XML file. This XML file contains a list of certificates that are granted access. However, applications with root access can easily obtain the permission to access the secure element for any of these access control mechanisms.

The Relay App
The relay app, a purely Java-based Android app, is a simple TCP client that maintains a persistent TCP connection to a remote server (the card emulator). When the card emulator requests access to the secure element, a connection is established through the NfcExecutionEnvironment object. Then, the Google Wallet on-card component is selected and the unlock command is sent. The relay app then listens for C-APDUs on its network interface and forwards them to the secure element. The R-APDUs from the secure element are transmitted back to the card emulator. When the transaction is complete, the Google Wallet on-card component is selected again and the lock command is sent to lock the wallet.
For this test scenario, the relay app has been manually granted the permissions necessary to access the secure element. However, privilege escalation exploits could be integrated into future versions of the app. For easier integration of future exploit codes, a privilege escalation framework (cf. [6]) could be embedded into the app.
Additionally, the test app has a foreground component that needs to be started manually. Moreover, the connection to the card emulator needs to be confirmed by the user.
However, the app could be started automatically on device boot-up and run completely in the background.
To roll out the relay app to user's devices, it could be integrated into any existing app downloaded from Google Play Store. The infected app could then be re-published on Google Play Store under similar (or even identical) publisher information and with the same app name as its original 5 . To specifically target users of rooted devices, an app that already requires root permissions could be used as a base for code injection.

The Card Emulator
For this proof-of-concept a simple card emulator has been built from a notebook computer and an ACS ACR 122U NFC reader (Fig. 5). This NFC reader supports software card emulation mode and is available for less than EUR 50 (including taxes and shipping) from touchatag.com 6 . Several examples on how to use this device in card emulation mode can be found on the web 7 . The card emulation software (written in Python) contains a TCP server that listens for incoming connections from the relay app. Once a TCP connection has been established, the emulator goes into card emulation mode and waits for a POS terminal. When the card emulator detects activation by a POS terminal (or any smartcard reader), it requests access to the secure element through the relay app. Then, all received C-APDUs are forwarded through the network interface to the relay app and all R-APDUs received from the relay app are returned to the POS terminal. When the RF field is deactivated, the connection to the secure element is closed.
The custom card emulator in Fig. 5 has a form factor that will certainly raise suspicions at the point-of-sale. However, there already exist devices with an accepted form factor (i.e. that of a mobile phone, see Fig. 6) with support for software card emulation. E.g. all BlackBerry devices with NFC that are equipped with the BlackBerry 7 platform support software card emulation mode. Moreover, recent patches [14,15] to the CyanogenMod firmware for Android devices enable software card emulation for Android NFC devices that are based on the PN544 NFC controller. Besides their form factor, mobile phones have anonther advantage when used as card emulator platform for relay attacks: They already contain the same network interfaces as the device under attack [10]. The viability of a BlackBerry device as card emulator platform for relay attacks has already been verified by Francis et al. [3].

Point-of-Sale (POS) Terminal
The Google Wallet relay attack has been successfully tested together with a POS terminal as used in recent roll-outs at Schlecker and Zielpunkt in Austria (Fig. 7).

Viability of the Google Wallet Relay Attack
For this attack only an NFC reader device (available for less than EUR 50), a notebook computer and some average programming skills were necessary. A BlackBerry with software card emulation support is available for less than EUR 300. An additional EUR 20 is necessary for a publisher account on Google Play Store.
When the relay app is running on many devices, a "bot network" of Google Wallets could be created. The attacker could then perform some kind of "load balancing" to evenly distribute payments among devices and to select a device with a stable network connection for each payment transaction.
Applying recent secure element relay attack scenarios to the real world: Google Wallet Relay Attack Michael Roland <michael.roland@fh-hagenberg.at>

Timeouts of POS Terminals
An easy, but potentially unreliable, measure to prevent relay attacks would be the enforcement of short timeouts (e.g. those specified by the EMV specifications) for payment transactions on the POS terminals. Transactions taking longer than this timeout should be interupted or discarded. While this measure will prevent most long-distance relay scenarios, relays over shorter distances and fast communication channels might not be rejected. Also, installing such tight timeouts will prevent cloud-based EMV applications (cf. [10] and YES-wallet 8 ).

Google Wallet PIN Code Verification
With the tested implementation of the Google Wallet app (version 1.1-R52v7), the PIN code that protects the Google Wallet is only verified within the mobile phone app. The on-card component does not verify this PIN code. Instead, the on-card component is controlled by simple lock and unlock commands (see 2.1).
PIN code verification could be handled by the on-card component on the secure element instead of by the app on the mobile phone's application processor. After all, PIN code verification is a core component of smartcards anyways. In that case, the attacker would need to know the wallet's PIN code to conduct a successful attack.
On a rooted device, an attacker might still be able to sniff the PIN code (while it is entered by the user) by capturing the screen and the touch events. However, this is significantly more difficult than sending a simple unlock command to the secure element.

Disabling Internal Mode Communication for Payment Applets
Recent secure elements (like the one embedded into the Nexus S) provide instruments to distinguish between external communication (contactless interface) and internal communication (application processor) from within a JavaCard applet. In addition, the secure element may have the capability to completely disable a certain interface on a per-applet basis. These capabilities could be used to disable internal mode communication for all payment applets and consequently disable their vulnerability for software-based relay attacks.
The disadvantage of this workaround is that the secure element cannot be used for future on-device secure payment applications (e.g. EMV payment in the mobile phone's webbrowser). Such applications would, however, be one of the major benefits of having a secure element inside a mobile phone.