NFC Relay Attack Explained

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

How Relay Attacks Work and How to Prevent Them

Technical explanation of NFC relay attacks, how they exploit the short-range assumption, and countermeasures including distance bounding.

| 5 min read

NFC Relay Attack Explained

A relay attack extends the effective range of an NFC transaction by transparently forwarding RF signals between a victim card and a legitimate reader through a proxy system the victim is unaware of. The attack requires no cryptographic break — it exploits the implicit trust that proximity implies presence.

How the Attack Works

A relay attack uses two devices:

  • Mole (near the victim card): Emulates an NFC reader, queries the victim's card, and forwards responses.
  • Ghost (near the legitimate reader): Emulates an NFC card, receives forwarded responses, and sends them to the real reader.
Victim Card ←→ Mole Device ~~[WiFi/BLE/Internet]~~ Ghost Device ←→ Legitimate Reader
    (4 cm)          (attacker)                       (attacker)          (payment terminal)

The real reader believes it is communicating with a card at proximity; the real card has no knowledge it is being relayed. From both endpoints' perspective the transaction appears normal.

Why NFC Is Vulnerable

NFC's security model relies on proximity as an implicit authentication factor — the assumption that a card within 4 cm must be physically present and intentionally tapped. This assumption fails when a relay extends the effective transaction distance to hundreds of metres or kilometres.

Unlike replay attacks, relay attacks work even when: - The card uses mutual-authentication (the legitimate card signs legitimate challenges) - The card uses aes-encryption (cryptographic material is never exposed to the relay) - The transaction includes dynamic values (relay forwards them in real time)

Attack Scenarios

Scenario Vector Victim
Contactless payment fraud Mole in crowd, ghost at POS Wallet in pocket or bag
Transit fare evasion Mole at gate, ghost relayed remotely Season pass holder
Access control bypass Ghost mole pair at secure facility Employee proximity badge
Hotel key theft Mole near check-in, ghost at room door Guest's key card

Research teams have demonstrated relay attacks against EMV contactless payments with total latency under 200 ms — within the transaction timeout window of most real terminals.

Timing and Latency

The critical constraint is the ISO 14443 Frame Waiting Time (FWT). After the reader sends a command, the card must respond within FWT, typically 4.8 ms to 309 ms depending on FWI coding in the ATS.

Most relay implementations over WiFi or BLE introduce 20–150 ms of additional latency. A well-configured attack uses: - BLE 5.0 with 2 Mbit/s PHY: ~5 ms round trip - 5 GHz WiFi on LAN: ~2 ms round trip - NFC-to-NFC analog relay on custom RF hardware: <1 ms

The iso-14443 standard does not define a minimum FWT, so proximity enforcement at the protocol level is not standardised.

Defences

Distance Bounding Protocols

Distance bounding measures the round-trip time of a challenge-response exchange to bound the maximum physical distance to a verifiable radius. If RTT exceeds the speed-of-light limit for the claimed distance, the protocol aborts.

  • Brands-Chaum (1993): first formal distance-bounding protocol
  • NFCIP-1 Active mode: not a distance-bounding protocol but shorter timeouts help
  • ISO/IEC 22369 (Distance Bounding): under development as of 2025

User Interaction Requirements

Requiring a PIN or biometric before a contactless transaction breaks relay attacks that depend on a passive victim. Apple Pay and Google Pay implement this for payments — the phone must be unlocked and the correct app opened.

EMV contactless transactions below a country-specific limit (e.g. £100 in the UK) require no PIN, creating a window for relay exploitation.

RF Shielding

RFID-blocking wallets and sleeves contain a Faraday cage layer (usually aluminium foil between fabric layers) that attenuates the 13.56 MHz field. This is a practical passive defence against opportunistic moles.

Transaction Limits and Velocity Controls

Issuers can limit contactless transactions to a maximum amount and detect unusual velocity (multiple small transactions in rapid succession). While not preventing relay, this limits financial exposure.

Tamper-Evident Tokens

Some protocols bind the transaction to the reader's terminal ID or location, requiring the card to confirm it has seen the correct terminal certificate — a defence that relay attacks cannot circumvent because the card only sees the mole's emulated terminal.

Practical Risk Assessment

Use Case Relay Risk Recommended Defence
EMV payment (low value) Medium User awareness; issuer velocity limits
EMV payment (high value) Low PIN required; relay window too short
Transit pass Medium Inspect terminal; distance-bounding if available
Hotel/office access Medium-High Multi-factor (PIN + card)
NFC product authentication Low originality-signature prevents clone/relay fraud

Detection and Forensics

Relay attacks leave no physical evidence. Forensic indicators include: - Transaction timestamp inconsistency (card claims presence at terminal A while phone GPS shows location B) - Multiple transactions from the same card within physically impossible travel time - Unusual latency in terminal transaction logs (relay introduces measurable RTT spikes)

See also: NFC Security Deep Dive | MIFARE Classic Security Analysis | NFC Anti-Counterfeiting | NFC Payments How It Works

Frequently Asked Questions

Our guides cover a range of experience levels. Getting Started guides are written for beginners with no prior NFC knowledge. Programming guides target developers integrating NFC into mobile apps or embedded systems. Security guides are for engineers designing secure NFC deployments for payments, access control, or authentication.

Most guides require only an NFC-enabled smartphone (iPhone 7+ or any modern Android device) and a few NFC tags (NTAG213 or NTAG215 recommended for beginners, available for under $1 each). Advanced guides may reference USB NFC readers like the ACR122U or Proxmark3 for development and testing.

Yes. Programming guides include code examples for Android (Kotlin/Java with the Android NFC API), iOS (Swift with Core NFC), and web-based tools (Web NFC API for Chrome on Android). All code samples are tested and include inline comments explaining each step.