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.

💡 Research Summary

This technical report investigates the feasibility of applying modern secure‑element (SE) relay attacks to a real‑world mobile payment system, specifically Google Wallet. Traditional relay attacks on contactless smartcards, first demonstrated by Hancke in 2005, required a “mole” device to be in close proximity (≤1 m) to the victim card and a “proxy” device near the point‑of‑sale (POS) terminal, with a fast out‑of‑band channel linking the two. Recent research, however, shows that the SE can be accessed from the device’s application processor via internal APIs, eliminating the need for physical proximity to the card. In this “next‑generation” scenario, an attacker installs malicious relay software on the victim’s phone, obtains elevated privileges (through root or known Android exploits such as mempodroid, Levitator, ZergRush, etc.), and forwards APDU commands between the SE and an external card emulator over Wi‑Fi, cellular, or Internet links.

The paper evaluates four communication paths: (1) direct NFC reader to SE (≈30 ms latency), (2) on‑device app to SE (≈50‑80 ms), (3) Wi‑Fi relay (≈100‑210 ms), and (4) cellular/Internet relay (≈200‑300 ms, with many measurements exceeding 1 s). ISO/IEC 14443‑4 and EMV specifications impose no strict per‑APDU timeout; the overall transaction limit of 500 ms is a guideline rather than a hard rule, and many POS terminals (e.g., Austrian PayPass terminals) do not enforce it. Consequently, even with the added network delay, a payment can complete successfully.

Google Wallet (version 1.1‑R52v7) was chosen because it was widely deployed, based on EMV Mag‑Stripe mode (MasterCard PayPass), and its NFC stack and hidden SE API (com.android.nfc_extras) were publicly accessible. The wallet consists of an Android UI, JavaCard applets on the SE (Issuer Security Domain, MasterCard credit card, Google Wallet on‑card component, etc.), and a secure channel (SCP02) to a remote server for card management. The researchers installed a relay app on a rooted device, configured a Wi‑Fi link to a custom NFC card emulator, and placed the emulator in front of a POS terminal. The emulator relayed SELECT, GET PROCESSING OPTIONS, and transaction APDUs to the victim phone, which forwarded them to the SE; the SE’s responses were sent back through the same path, resulting in a fully authorized PayPass transaction that appeared in the user’s Google Wallet transaction history.

Google responded by updating the SE applets and tightening the internal API’s permission checks, rendering the attack ineffective on later versions. Nonetheless, the study highlights that as long as devices run outdated Android versions or are vulnerable to privilege‑escalation exploits, the attack surface remains. The authors recommend a multi‑layered defense: hardware‑based isolation between the OS and SE, real‑time monitoring of APDU latency to detect abnormal delays, physical detection of counterfeit card‑emulator RF signatures, mandatory user authentication (PIN or biometrics) for each transaction, and rapid deployment of OS security patches.

In summary, the work demonstrates that relay attacks have evolved from a purely physical range‑extension technique to a software‑driven threat capable of compromising contactless mobile payments at a distance. Effective mitigation requires both architectural changes in secure‑element access control and operational practices that address timing, authentication, and device‑level security.