NFC Card Emulation Workbench

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

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.

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.

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.

Card route HCE app Host card emulation app Secure element route No matching route

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

Tap distance 1.6 cm

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

APDU round-trip delay 110 ms

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

Teaching amount GBP 12.40

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

Policy gates

Selected AID is registered on the phone Required unlock or user authentication has passed Token or credential material is available Backend or issuer policy check is reachable when needed

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

• NFC fundamentals
• NFC Type 4 tag read/write animation
• NFC peer-to-peer LLCP animation
• NFC security and comparisons