When Should a Tap Count as Proof?

Android NFC dispatch can look like a real tap without one because the phone’s Reader/Writer path separates the physical discovery from the application entry point. In the normal flow, hardware detects a nearby tag, Android constructs an NFC discovery Intent, the resolver finds a matching Activity, and the app begins its NFC workflow. But the receiving app sees the routed request and its fields; it does not necessarily receive an application-verifiable proof that a fresh hardware discovery caused the Activity launch. The final judgment is therefore precise: an Android RW handler launch can be evidence of delivery, but it should not automatically be treated as evidence of physical proximity or user intent.

A real physical event and a software proof are different things

The subject is not NFC in the abstract. It is Android phone-as-reader dispatch and the relationship among the NFC system, the resolver, exported application handlers, and tap-to-X workflows. In Reader/Writer mode, the phone reads an external tag. That is distinct from card emulation, where the phone behaves like a card to an external reader. Security properties from secure-element payment paths or RF-level relay defenses cannot simply be assumed to govern an application Activity that receives a resolver-routed Intent.

The normal physical path still matters. A tag comes within range, the NFC controller detects it, and Android’s NFC stack creates a representation of the discovered tag. The platform documentation describes an immutable Tag object, an EXTRA_TAG extra, and a dispatch sequence that prioritizes foreground handling, NDEF data, technology matching, and a fallback action. Those mechanisms explain how a physical discovery becomes useful application input. They do not, by themselves, define an application-facing origin credential for every later Activity launch.

The decisive boundary is the transition from discovery to generic component start. Android uses an implicit Intent and manifest intent-filter matching to select a handler. The request may carry a system-defined NFC discovery action, a default category, URI or MIME constraints, technology information, and tag or NDEF-related extras. The resolver uses those values to decide where the request goes. Export status and caller permissions then determine whether the selected Activity can be started across package boundaries.

That is a capable routing design. It is also the source of the semantic problem identified by the paper. The action and data fields say what kind of request the Activity is prepared to handle. They do not, on their own, say which component was entitled to create the request. A URI can be valid, a MIME type can match, a tag-related extra can be present, and the Activity can still lack a dependable way to distinguish a request produced by the NFC dispatcher from a software-constructed request with the same accepted shape.

The paper describes this as two weaknesses working together. First, RW dispatch uses ordinary implicit-Intent resolution and generic Activity-start rules without an additional system-only admission condition binding the cross-package trigger to the NFC component. Second, the application-visible fields used to recognize the delivery are not app-verifiably bound to a fresh hardware discovery. The first weakness makes an exposed route reachable. The second leaves the receiver without a trustworthy explanation for why the route was taken.

TDFA is the name given to the resulting software-only attack. Its core claim is not that a local app can impersonate every tag, complete every workflow, or defeat every later authorization. It is that a local third-party app, under the paper’s conditions, can cause a vulnerable RW handler to be launched without NFC hardware interaction at trigger time. The attacker needs an installed and running app, a target whose routing predicates can be satisfied, and an Activity that is externally startable. On modern Android, the trigger must also occur from a context permitted to start an Activity. That is a timing and state constraint, not proof of NFC authorization.

This explains why TDFA is different from a relay attack. A relay extends or forwards a physical communication channel.