RFID, NFC & UWB · Study deck

Practice: NFC Reader Simulation

Picture a phone tapping a label to open the correct equipment record.

Radio Remi is your guide for this deck.

appssimulation
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Define what an NFC reader simulation can and cannot prove.
  • Model the reader state sequence from polling through tag selection, NDEF parsing, policy validation, and release evidence.
  • Decode simple NDEF TLV and URI records well enough to spot length, type, and host-validation failures.
  • Simulate multi-tag, malformed-payload, cloned-static-data, and relay-risk scenarios without overclaiming physical accuracy.
iotclass.org

Major section

Start With the Story

A software exercise can show whether the reader accepts a wrong field or repeated message before radio details make the fault harder to see.

  • NFC means Near Field Communication, a short-range link used for deliberate taps.
  • A payload means the useful record carried inside a message.
  • A protocol means the shared rules for an exchange.
iotclass.org

Major section

Start With the Story (continued)

This runway does not prove antenna range, phone behavior, or field timing.

  • The deeper lab covers reader states, NDEF structure, validation, injected faults, evidence capture, and the hardware checks left open.
  • A simulation cannot prove the RF field, but it can make the NFC logic visible.
  • Polling, anti-collision, NDEF parsing, policy checks, and failure cases become easier to inspect when the lab removes the hardware uncertainty.
iotclass.org

Major section

In 60 Seconds · Simulation Scope

The goal is not to emulate antenna tuning, phone operating-system behavior, or every timing detail of the 13.56 MHz radio link.

  • An NFC simulation is useful when it is honest about its boundary.
  • A browser or microcontroller sketch can model bytes, state transitions, and policy checks.
  • The next plan must test typical tags, phones, cases, mount surfaces, and fault paths on real hardware.
NFC reader simulation boundary showing scenario inputs, reader state machine, anti-collision, tag memory, NDEF parser, app policy, and evidence output, with the RF field and antenna behavior outside the software-only model.
NFC reader simulation boundary showing scenario inputs, reader state machine, anti-collision, tag memory, NDEF parser, app policy, and evidence output, with the RF field and antenna behavior outside the software-only model.

Try it: In 60 Seconds · Simulation Scope in the chapter

iotclass.org

Major section

Reader State Model · Minimal Scenario Record

The simulation should make each transition explicit so a bad tag, ambiguous field, malformed record, or policy denial is visible rather than hidden behind a single "read failed" message.

  • Idle to polling: The reader waits, then sends a polling request for compatible tags in range.
  • Polling to selection: If more than one candidate responds, the anti-collision procedure selects one tag at a time.
  • Policy to evidence: The simulation stores the decision, trace, inputs, and reason codes for the lab report.
  • The record should describe what the simulated reader sees, not pretend to be real RF data.
iotclass.org

Major section

Activation Loop Trace · Activation Sequence Details

Simulating an NFC reader means modelling a repeating loop, not a single read.

  • Detection reports a nearby target, while anti-collision resolves a participant when more than one response appears.
  • That trace lets a review distinguish a polling miss, collision-resolution issue, payload rejection, policy denial, or release-evidence outcome.
  • The byte trace can stay small.
NFC reader activation flow from polling through detection, anti-collision, selection, activation, exchange, and release evidence.
NFC reader activation flow from polling through detection, anti-collision, selection, activation, exchange, and release evidence.
iotclass.org

Major section

NDEF Trace Review · Parser Checks

The simulation should teach byte-level reasoning without burying the learner in a thousand-line sketch.

  • The important question is whether the parser and application disagree with the raw bytes.
  • The 03 TLV marks an NDEF message and its length field bounds the bytes that follow.
NDEF trace example showing TLV type, TLV length, record header, type length, payload length, URI identifier code, URI payload, terminator, parser checks, and application policy checks.
NDEF trace example showing TLV type, TLV length, record header, type length, payload length, URI identifier code, URI payload, terminator, parser checks, and application policy checks.
iotclass.org

Major section

Failure Injection Matrix

A useful lab does not only show the happy path.

  • It should include failure scenarios that force the reader and application to explain their decision.
  • A valid maintenance URI may reach authorization, while two visible tags require isolation or explicit selection.
  • Each outcome retains inputs, reason codes, lock state, timing, and the resulting decision.

Why it matters

Unknown host: Confirm that an otherwise valid URI is rejected when the application does not recognize the destination.

NFC simulation failure-injection matrix comparing valid tag, two tags, malformed NDEF, unknown host, locked tag, and relay-risk timing against the reader behavior and required evidence.
NFC simulation failure-injection matrix comparing valid tag, two tags, malformed NDEF, unknown host, locked tag, and relay-risk timing against the reader behavior and required evidence.
iotclass.org

Major section

Failure Injection Matrix (continued)

Malformed length must stop before policy receives a partial URI, and an unknown host must not be opened even when parsing succeeds.

  • Locked-tag writes fail safely, while suspicious timing is recorded as a freshness and review signal rather than automatic attack proof.
  • Malformed payload: Confirm that parser errors stop action and produce a readable reason code.
  • Multiple tags: Confirm that the reader either selects one predictable tag or asks the user to isolate the target.
iotclass.org

Major section

UID Anti-Collision and Cascade Levels · Worked Example: Maintenance Tag Review

Once the full UID is known, SELECT activates that one card.

  • For NFC-A, ISO/IEC 14443-3 Type A uses bit-oriented anti-collision over the card UID.
  • That binary walk continues until one card is uniquely identified.
  • The simulator should expose the difference between reader capability and application safety.

Why it matters

The step that surprises people is anti-collision, because NFC has to single out one card from several sharing the field with no central schedule.

iotclass.org

Major section

Simulation Design

The local run returned ACCEPT reference=https://ops.example/A7 action=requires_app_authorization.

  • The expected output is an asset reference, not permission to update an asset.
  • In the card-emulation workbench, compare the host app and secure-element routes and note the selected AID.
  • Changing the URI host in the fixture returned REJECT unknown_host.

Why it matters

This boundary prevents a readable label from becoming an authorization credential.

Try it: Simulation Design in the chapter

iotclass.org

Major section

Checkpoint: Acceptance Evidence · Common Pitfalls

Using a new-project simulator as evidence: A generic board page does not validate an NFC workflow unless the scenario, parser, policy, and failure cases are explicit.

  • Confusing parsed data with trusted data: Valid NDEF syntax only means the bytes decoded.
  • The application still needs host, type, length, schema, and authorization checks.
  • Overclaiming relay detection: Timing signals can inform risk, but credential flows need challenge freshness, policy, audit, and fallback decisions.
iotclass.org

Major section

Checkpoint: Summary · Key Takeaway

A useful NFC simulation is a logic and evidence tool, not a substitute for RF, phone, and installation testing.

  • Valid NDEF syntax does not mean the payload is trusted or authorized.
  • Failure injection is part of the lab, especially malformed records, unexpected hosts, nearby tags, lock-state errors, and relay-risk signals.
  • The final lab output should say what passed, what failed, what remains unproven, and what must be tested with real hardware.
iotclass.org

Deck summary

Key takeaways

A software exercise can show whether the reader accepts a wrong field or repeated message before radio details make the fault harder to see.

  • This runway does not prove antenna range, phone behavior, or field timing.
  • The goal is not to emulate antenna tuning, phone operating-system behavior, or every timing detail of the 13.56 MHz radio link.
  • The simulation should make each transition explicit so a bad tag, ambiguous field, malformed record, or policy denial is visible rather than hidden behind a single "read failed" message.
  • Simulating an NFC reader means modelling a repeating loop, not a single read.
iotclass.org

Retrieval practice

Recall check 1 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q1A reader simulation accepts a tag before checking its payload and host policy. Which sequence should be tested?

ATreat any detected field as a valid application event
BWrite a success log, then check the record length
CPoll, select, parse, check host policy, log outcome.
DApprove the host before selecting a tag
Show answer

Answer: C Selection precedes decoding and application approval.

iotclass.org

Retrieval practice

Recall check 2 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q2A software-only NFC reader simulation passes its tests. Which claim is safe to make?

AThe antenna tuning and 13.56 MHz radio link are now validated by the run.
BThe parser and application policy handled the tested NDEF and failure cases.
CThe phone operating-system NFC behavior is now fully verified end to end.
DThe tags will read reliably on every real mounting surface after installation.
Show answer

Answer: B A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.

iotclass.org

Retrieval practice

Recall check 3 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q3A tag record claims more bytes than the reader received. What should reject it first?

AThe backend after executing the action
BThe parser, before application policy
CThe user after seeing a truncated page
DThe radio antenna after decoding
Show answer

Answer: B An invalid length must not become a partial URI.

iotclass.org

Retrieval practice

Recall check 4 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q4In an NFC reader simulation, two Type A cards enter the field simultaneously. What should the modelled reader do, and via what mechanism?

ARun ISO 14443-3A anti-collision, SELECT a UID, then exchange APDUs.
BReport a collision error and stop, since NFC can only ever handle one card at a time.
CImmediately send ISO 7816-4 APDUs to both cards in parallel to read them.
DIncrease the field power until one card wins by drawing more energy than the other.
Show answer

Answer: A NFC-A resolves multiple cards with bit-oriented UID anti-collision across cascade levels for 4, 7, or 10 byte UIDs, then SELECT activates one card before ISO 7816-4 APDU exchange.

iotclass.org

Retrieval practice

Recall check 5 of 5

Radio Remi says: answer from memory, then check your reasoning.

Q5Which claim is safe to make after a software-only NFC reader simulation passes?

AThe final tag will read reliably on every phone and every mounting surface.
BThe simulated parser and application policy handled the tested NDEF and failure scenarios.
CA static UID is now enough to authorize maintenance actions in the field.
DRelay attacks are impossible because the simulated timing looked normal.
Show answer

Answer: B The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. C · Selection precedes decoding and application approval.
  2. B · A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.
  3. B · An invalid length must not become a partial URI.
  4. A · NFC-A resolves multiple cards with bit-oriented UID anti-collision across cascade levels for 4, 7, or 10 byte UIDs, then SELECT activates one card before ISO 7816-4 APDU exchange.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. B · The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.
iotclass.org