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

The paper provides a comprehensive examination of recent relay‑attack techniques targeting contactless smart‑card and secure‑element (SE) environments, and demonstrates how these attacks can be concretely applied to Google Wallet. It begins by reviewing the evolution of relay attacks from simple range‑extension exploits on RFID systems to sophisticated software‑level interceptions of NFC communication. The authors outline the canonical attack architecture: a “reader proxy” placed between the point‑of‑sale (POS) terminal and the victim device, and a “card proxy” that emulates a payment card at a remote location. The two proxies exchange Application Protocol Data Units (APDUs) over a low‑latency wireless link (Wi‑Fi Direct, BLE, or similar), effectively extending the physical distance between the legitimate card and the terminal without the attacker ever possessing a physical card.

The core of the analysis focuses on Google Wallet’s internal design. Google Wallet runs on Android and stores payment credentials inside a tamper‑resistant SE. For most transactions the SE provides a tokenized representation of the card, but for backward compatibility it also supports EMV Mag‑Stripe mode, which transmits the raw track‑1/track‑2 data (card number, expiration date, CVV) in clear form. Because Mag‑Stripe mode bypasses the dynamic token generation and cryptographic challenge‑response mechanisms, it becomes a natural target for relay attacks.

To test the feasibility of a real‑world attack, the researchers first obtained root access on an Android device and installed a custom NFC‑stack interceptor. This interceptor hooks the Android NFC service at the Binder level, capturing every APDU sent to and from the SE. Captured APDUs are compressed, encrypted with AES‑256, and streamed over UDP to a remote Raspberry‑Pi‑based card emulator. The emulator decrypts the stream, replays the APDUs to a standard NFC reader module, and forwards the terminal’s responses back to the victim device. The entire round‑trip latency measured an average of 12 ms, well within the timing tolerances of typical POS terminals.

During the experiment a legitimate Mag‑Stripe transaction was initiated on the Google Wallet device. The relay chain successfully reproduced the full transaction data—including PAN, expiration, service code, and CVV—so the POS terminal approved the purchase as if a genuine card had been presented. Post‑transaction logs on the SE showed no anomalous entries, indicating that the existing integrity‑monitoring mechanisms could not detect the intrusion. The authors also demonstrated that multiple consecutive transactions could be relayed without noticeable degradation, highlighting the potential for significant financial loss.

From a security‑architecture perspective, the paper identifies three critical prerequisites for a successful relay attack on Google Wallet: (1) a software vulnerability that grants the attacker root or privileged access to the NFC stack, (2) a reliable method to intercept and forward APDUs in real time, and (3) a low‑latency, reliable wireless channel to avoid timeout failures at the POS. The authors argue that while SEs are designed to protect against physical tampering, they cannot defend against attacks that manipulate the communication path at the operating‑system level.

The discussion section proposes several mitigations. First, the use of Mag‑Stripe mode should be deprecated in favor of token‑only transactions, eliminating the exposure of static card data. Second, dynamic CVV or transaction‑specific cryptograms should be introduced even for fallback modes, making replay impossible without the correct per‑transaction secret. Third, POS terminals could implement distance‑bounding protocols that measure the round‑trip time of NFC exchanges; any latency exceeding a tight threshold would trigger a transaction abort. Fourth, mobile platforms should enforce secure boot and TrustZone isolation for NFC services, preventing unauthorized code from inserting interceptors. Finally, continuous monitoring for abnormal APDU patterns and sudden spikes in wireless traffic could provide early warning of a relay attempt.

The paper concludes by outlining future research directions, including experimental validation of distance‑bounding and time‑based challenge mechanisms, cross‑platform analysis of Apple Pay and Samsung Pay under similar attack models, and the integration of cloud‑based token management with real‑time anomaly detection. Overall, the study convincingly demonstrates that relay attacks can bypass the physical security guarantees of secure elements by exploiting software‑level weaknesses, and it calls for a redesign of mobile payment architectures to incorporate robust, multi‑layered defenses against such network‑based threats.