NFC Card Emulation Workbench

NFC Card Emulation Workbench

Trace how an NFC reader selects a card application and exchanges APDUs with a phone.

animation
nfc
card-emulation
hce
secure-element
apdu
Learner-ready NFC card emulation workbench with scenario presets, animated APDU flow, HCE versus secure element routing, range and security gates, quick reference cards, source links, and desktop/mobile visual checks.
NFC Card emulation APDU flow HCE / secure element

NFC Card Emulation Workbench

Move through a reader-to-phone exchange and see how a phone behaves like a contactless smart card. The goal is not to implement EMV, but to make the routing, AID selection, APDU responses, and common failure gates visible enough for independent study.

Core idea The reader selects an application, then exchanges APDUs with the phone.
Carrier 13.56 MHz short-range inductive coupling
Teaching focus AID routing, command-response APDUs, and transaction gates
Important limit This is a simplified protocol model, not a real wallet implementation.
TryPick Mobile payment, set Tap distance to 1.6 cm and APDU round-trip delay to 110 ms, then press Play.
ObserveThe stage advances from field detection through AID selection to APDU exchange; clearing authentication stops at the policy gate. Step confirms this readout.
ExplainThe reader selects an application by AID, and the phone answers APDUs only when routing, credential, and transaction-policy conditions pass. Step exposes this mechanism.
Technical boundariesThe sequence excludes EMV cryptograms, issuer authorization, secure-element timing, relay detection, RF collisions, and handset policy.
Colour keyrfid nfc uwb identitycurrent / primaryreference / datasuccesscautionerror / failure
1. Reader field

The terminal starts the conversation

The reader creates the NFC field and sends commands. The phone responds like a card when it is close enough.

2. Routing

The AID chooses an app or secure element

A SELECT AID command tells the phone which card application the reader wants to talk to.

3. APDUs

Every step is command then response

The reader sends APDU commands; the emulated card returns data and status words such as 90 00.

4. Decision

Security policy decides the result

Range, unlock policy, token availability, AID matching, and suspicious delay can stop the transaction.

Interactive workbench

Trace one card-emulation exchange

Step through the reader field, AID selection, APDU processing, and final decision.

NFC card emulation APDU flow A reader sends APDU commands to a phone NFC controller, which routes to an HCE service or secure element and returns a status response. Contactless reader Payment terminal SELECT AID APDU command Phone as card NFC controller AID route table HCE service Host app Secure element Off-host route FIELD ON Ready to select AID All required gates currently pass Tap distance 1.6 cm - good coupling
Current stage Field detect

The reader energizes the NFC field and waits for a card-like target.

Route HCE app

The phone routes the selected AID to a host service.

Decision Ready

Step or play to test range, AID, unlock, token, and timing gates.

Response status -- --

Status words appear after the emulated card processes a command.

Command APDU being taught

The first important command selects the application by AID.

CLA00
INSA4
P1 P204 00
DataA0000000031010

Response from the emulated card

A successful response returns selected application data and status 90 00.

DataFCI template pending
SW1--
SW2--
MeaningWaiting for command

Diagnostic log

The log turns protocol terms into the practical checks a learner should make.

Quick reference

Card emulation quick reference

Use these compact notes to separate the NFC radio link, card application routing, APDU protocol, and security policy.

Modes and roles

  • Reader/writer: phone or terminal reads a tag.
  • Peer-to-peer: two NFC devices exchange data.
  • Card emulation: a phone behaves like a contactless card to a reader.
  • HCE: Android host app receives APDUs after routing.

APDU essentials

  • 00 A4 04 00 commonly represents SELECT by DF name.
  • The AID identifies which application should answer.
  • Responses include data plus status words such as 90 00.
  • 6A 82 is a useful teaching example for "not found".

Common gates

  • Reader and phone must be very close for reliable coupling.
  • The selected AID must be registered and allowed to route.
  • Host services may require unlock or user authentication.
  • Payment token or backend policy can stop a transaction.

Security framing

  • Short range helps, but it is not a complete security control.
  • Tokenization avoids exposing a raw account number in normal wallet designs.
  • Cryptograms bind transaction context in payment systems.
  • Unexpected delay should raise relay-risk suspicion.
Controls

Change the conditions

Use the controls to make the same APDU flow pass, fail, or become suspicious.

HCE routes APDUs to host software. A secure element is an off-host route. A missing route produces a selection failure.

NFC is intentionally short range. This teaching model treats about 2 cm or less as strong coupling.

Long delay can indicate network dependency or relay-risk conditions in high-assurance flows.

Used only to explain transaction context. No real payment data or real EMV calculation is shown.

Policy gates

Cycles through out-of-range, missing AID, locked device, missing token, and suspicious delay states.

Technical accuracy notes

This workbench uses a simplified ISO/IEC 7816-style APDU model because that is the interface most learners see when studying Android HCE and smart-card application selection. Real payment kernels, scheme rules, token provisioning, risk checks, and cryptograms are much more detailed than this educational model.

  • NFC operates at 13.56 MHz and is designed for very short-range interaction.
  • Card emulation means the NFC device behaves as a contactless card to an external reader.
  • Android HCE sends command APDUs to a service after a SELECT AID has resolved to that service.
  • Secure-element and HCE deployments differ by platform, device, wallet, issuer, region, and policy.
  • Security should be discussed as a system design, not as "NFC is secure because it is short range."
Primary source links used for this page
NFC Forum technology overview nfc-forum.org/learn/nfc-technology
Android host-based card emulation overview developer.android.com/develop/connectivity/nfc/hce
Android HostApduService API reference developer.android.com/reference/android/nfc/cardemulation/HostApduService
EMVCo contactless technology page emvco.com/emv-technologies/emv-contactless-chip
What to study next