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.
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.
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.
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.
Major section
Reader State Model
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.
Major section
Activation Loop Trace
Simulating an NFC reader means modelling a repeating loop, not a single read.
- That trace lets a review distinguish a polling miss, collision-resolution issue, payload rejection, policy denial, or release-evidence outcome.
- The simulation boundary should be explicit in the same report.
Major section
Activation Sequence Details
The terminal starts the conversation, the AID selects an app or secure element route, and each command draws a response until a security policy decides the result.
- You can inject a second card at the anti-collision step, drop the field mid-APDU, corrupt a TLV length, or delay a response and then ask which state owns the failure.
- A practical scenario table should include one clean tag and several negative cases.
- The byte trace can stay small.
Major section
Activation Sequence Details (continued)
The point is not to imitate every analog timing detail; it is to make the reader software obligations explicit enough that the review can separate parser, policy, and follow-up hardware risks.
- In the clean case, a Type 2 tag advertises an NDEF Message TLV, the parser finds a URI record, and policy accepts the host.
- In a malformed case, the TLV length claims more bytes than the buffer contains, so the parser must reject before policy sees a partial URI.
- For example, 03 13 means an NDEF Message TLV with length 0x13, or 19 bytes, before the FE terminator.
Major section
NDEF Trace Review
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.
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.
- For the evidence behind failure injection matrix, use it to distinguish: Failure injection turns a demo into evidence from: Expected reader behavior.
- The conclusion depends on known host, small URI.
Major section
Failure Injection Matrix (continued)
Unknown host.: Confirm that an otherwise valid URI is rejected when the application does not recognize the destination.
- 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.
- Locked or read-only tag.: Confirm that write operations fail safely and that release evidence records the intended lock state.
Major section
UID Anti-Collision and Cascade Levels
For NFC-A, ISO/IEC 14443-3 Type A uses bit-oriented anti-collision over the card UID.
- Cards reply with UID bits; when two disagree at a bit position, the reader detects the collision, fixes the prefix, and asks again.
- That binary walk continues until one card is uniquely identified.
- Because UIDs can be 4, 7, or 10 bytes, this happens in cascade levels: CL1, CL2, and CL3.
Major section
UID Anti-Collision and Cascade Levels (continued)
Once the full UID is known, SELECT activates that one card.
- NFC-B uses a different time-slotted anti-collision process, so a simulator should not pretend all technologies resolve collisions the same way.
- The simulator should expose the difference between reader capability and application safety.
- For a read-only lookup, selecting one card may be acceptable.
- For a write, lock, or credential action, policy may require one visible target in the field before proceeding.
Major section
UID Anti-Collision and Cascade Levels (continued)
Cascade-level logging also protects the model from treating every UID as an opaque string.
- A 4-byte UID can be resolved in one cascade level, while longer UIDs require later levels after the cascade tag indicates that more bytes follow.
- If the model never records those steps, it cannot test partial UID handling, duplicate prefixes, or mistaken selection after a collision.
- A software scenario can simulate stale challenge identifiers, delayed responses, duplicate credential observations, and policy decisions that deny high-value actions.
Major section
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.
Major section
Summary
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.
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 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.
- The terminal starts the conversation, the AID selects an app or secure element route, and each command draws a response until a security policy decides the result.
Retrieval practice
Recall check 1 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q1A software-only NFC reader simulation passes its tests. Which claim is safe to make?
Show answer
Answer: C A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.
Retrieval practice
Recall check 2 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q2In an NFC reader simulation, two Type A cards enter the field simultaneously. What should the modelled reader do, and via what mechanism?
Show answer
Answer: D 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.
Retrieval practice
Recall check 3 of 3
Radio Remi says: answer from memory, then check your reasoning.
Q3Which claim is safe to make after a software-only NFC reader simulation passes?
Show answer
Answer: B The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.
Print reference
Answers
Answer key.
- C · A software-only NFC simulation can only claim its parser and policy handled the tested NDEF and failure cases.
- D · 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.
- B · The right conclusion is limited and evidence-based: the modeled logic passed the tested scenarios.