Chapters

7 RFID Security and Privacy

rfid-nfc-uwb
security
privacy

7.1 Start With the Story

This section: Start With the Story

7.1.1 Protect the Person Behind the Tag

Radio frequency means the rate of change used by a radio signal.

Radio frequency identification (RFID) uses radio to identify or exchange data with a tag. A readable tag is not proof that the holder is the right person or that the next action is allowed.

Picture a staff badge used at a clinic door. The same identifier may also reveal when a person arrives, which room they visit, and how long they stay. A useful access feature can quietly become a movement record.

Map the full path from tag to reader, service, decision, log, report, and deletion. Name the purpose of each field, who can read it, how long it remains, and what happens after a copied, lost, or replaced tag. Test an unknown reader, a repeated read, a stale permission, and a person asking for correction.

Use a plain review card. Who is seen? What is saved? Why is it needed? Who can act on it? When is it removed? What can the person do if the record is wrong? Short answers expose a weak design before more data is gathered.

Short range and encryption do not settle every privacy question. The deeper sections explain cloning, tracking, access controls, notice, minimisation, and retention. Use those tools to prove a narrow purpose while keeping identity, permission, and physical safety as separate checks.

RFID security starts with a simple discomfort: a tag can identify something without a person noticing. That may be harmless inventory, a door credential, a medicine record, or personal movement data depending on the boundary around the reader and the event.

Read this chapter by separating identity from authorization. Decide what the tag proves, who may read it, what data becomes personal, which controls reduce misuse, and what audit evidence shows the system is behaving as promised.

Checkpoint: Key Concepts

This section: Checkpoint: Key Concepts

  • Threat model: A record of who might read, copy, relay, disable, or misuse RFID data, and which business decisions would be affected.
  • Static identifier risk: The risk that a fixed UID, EPC, badge number, or item identifier can be copied, correlated, or tracked.
  • Authentication boundary: The point where a tag, reader, or backend proves it is authorized before data is trusted.
  • Relay risk: The risk that an attacker forwards messages between a real tag and a real reader without breaking the cryptography.
  • Read-zone control: Antenna, shielding, power, placement, and workflow rules that limit where a tag observation should count.
  • Privacy boundary: The rule that controls whether RFID reads can be linked to people, retained, shared, or used for profiling.
  • Security evidence: The traces, key-management records, exception tests, logs, and retest triggers that support a release decision.

7.2 In 60 Seconds

This section: In 60 Seconds — RFID security is not solved by adding encryption to a tag.

RFID security is not solved by adding encryption to a tag. A secure design separates tag identity, reader authorization, backend policy, physical read-zone control, privacy handling, and audit evidence. A raw tag read should not be treated as a credential, a location truth, or consent. Good RFID security starts with a threat model, selects controls that fit the workflow, rehearses failure cases, and records what must be retested when tags, readers, keys, software, layouts, or policies change.

The mathematical gist. With an illustrative 30 dBm reader at 915 MHz, a -18 dBm tag wakes at an ideal 6.55 m while a -95 dBm receiver’s one-way free-space ceiling is about 46.4 km. The 7,080-fold range ratio comes from the 77 dB threshold gap; a further 9 dBi listening antenna multiplies ideal range by 2.82, but neither ceiling predicts a real attack site.

Math Bridge · guided foundationsWhy can a listener hear the reader far beyond the tag's working range?Let Eddie connect EIRP, sensitivity, one-way loss, threshold gap, and directional gain.

7.3 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you should be able to:

  • Identify RFID attack surfaces such as eavesdropping, cloning, relay, jamming, kill-command abuse, rogue readers, and backend misuse.
  • Distinguish static identifier checks from cryptographic authentication and policy authorization.
  • Explain why relay attacks can matter even when tag-reader messages are encrypted.
  • Design layered controls across tag, reader, middleware, backend, physical read zone, and operating process.
  • Review privacy risk when RFID reads are linked to people, products, locations, time, or account records.
  • Define security release evidence for key provisioning, logging, exception handling, fallback, and retest triggers.

7.4 Quick Check: RFID Security

This section: Quick Check: RFID Security

7.5 Prerequisites

This section: Prerequisites

Recommended context:

7.6 Ethics and Authorization

This section: Ethics and Authorization — Do not test RFID systems you do not own or have explicit permission to assess.

Do not test RFID systems you do not own or have explicit permission to assess. RFID security testing can disrupt access control, inventory, payment, transport, healthcare, or regulated workflows. Use lab tags, lab readers, and written authorization. If a weakness is found in a real system, preserve evidence carefully and use the organization responsible-disclosure path.

7.7 Threat Model First

This section: Threat Model First — Start with the decision the RFID system protects.

Start with the decision the RFID system protects. Then ask what could go wrong if a tag is read, copied, relayed, disabled, or linked to a person.

Figure 7.1 starts with the protected action and a realistic misuse path.

RFID threat model review path linking protected action, potential attacker, attack path, control family, evidence record, and retest trigger.
Figure 7.1: RFID threat model review path that starts with the protected action, then tests attacker assumptions, attack paths, controls, evidence, and retest triggers.

The model in Figure 7.1 starts with the protected action, such as a door unlock or item release, before naming an attacker. A rogue reader, insider, thief, or data broker may exploit eavesdropping, cloning, relay, jamming, or log misuse. Authentication, zone control, and data minimization address different paths and need different proof, such as a challenge trace, denied reader, or reviewed record. New tags, moved antennas, and changed keys or policy trigger retest. A raw tag read is only an observation; it does not show consent or authorize the protected action. Keep the threat, control, result, and retest owner linked.

Protected action Door unlock, item release, inventory update, service approval, shipment receipt, patient-safe workflow, or audit record.
Potential attacker Curious reader owner, insider, competitor, thief, data broker, rogue integrator, compromised reader, or misconfigured backend.
Attack path Eavesdrop, clone, replay, relay, jam, kill, probe, scrape logs, infer behavior, or correlate datasets.
Control family Cryptographic authentication, reader access control, read-zone tuning, privacy minimization, logging, fallback, and governance.
Evidence Challenge-response traces, key custody record, denied-reader test, wrong-zone test, privacy review, and audit sample.
Retest trigger New tag model, reader move, antenna change, firmware update, key rotation, policy change, new data sharing, or layout change.

7.8 Attack Surfaces

This section: Attack Surfaces — RFID attack surfaces come from radio communication, static identifiers, constrained tags, reader placement, backend trust, and data retention.

RFID attack surfaces come from radio communication, static identifiers, constrained tags, reader placement, backend trust, and data retention.

Eavesdropping. A rogue receiver may observe tag-reader communication when the physical field extends beyond the intended workflow. Risk depends on tag type, band, antenna, shielding, reader power, and message content.
Static identifier cloning. Systems that treat UID, EPC, or card number as a secret are vulnerable when that identifier can be copied or replayed.
Relay. An attacker may forward messages between a real tag and a real reader. Encryption protects message content, but a relay may still extend the interaction unless timing, distance, or workflow controls catch it.
Denial of service. Jamming, interference, antenna disconnection, weak kill-password handling, or reader outage can stop reads or destroy tag availability.
Rogue reader and backend misuse. Authorized-looking readers, stale credentials, excessive logs, broad dashboard access, or data sharing can create security and privacy failures after the RF read succeeds.
Physical and side-channel attacks. High-value tags, credentials, or secure elements may need review against invasive probing, fault injection, side channels, or stolen reader/key material.

7.9 Classic Gen2 Security Is Deliberately Thin

This section: Classic Gen2 Security Is Deliberately Thin — The original EPC Gen2 air interface was optimized for cheap, disposable item tags, so its security is minimal on purpose.

The original EPC Gen2 air interface was optimized for cheap, disposable item tags, so its security is minimal on purpose. Gen2 defines two 32-bit password fields: a kill password that, when nonzero, can permanently silence a tag, and an access password used to enter the secured state for protected operations. A tag need not physically implement either password, and unlocked memory can be written without entering the secured state. There is no encryption of the stored data and no strong proof that a tag is genuine. Treat a basic Gen2 tag as a readable, copyable barcode that happens to work over radio.

Figure 7.2 keeps a readable tag identifier outside credential authority.

RFID security boundary map with risks such as cloning, emulation, relay, and replay claims linked to controls such as authentication, key policy, lock, kill, and shielding, with telemetry and lifecycle evidence below and a central reminder that a readable ID is not a credential.
Figure 7.2: RFID security boundary map showing risks, controls, telemetry, lifecycle, and a reminder that a readable ID is not a credential.

A tag ID can be copied or emulated, and a read can be relayed or replayed. Authentication and key policy, read-zone controls, and backend authorization address different parts of those risks. Reader and event logs provide telemetry for review, while provisioning and revocation define the identifier’s lifecycle. Do not let a readable ID alone unlock a door or release an item. Test a copied identifier and an unauthorized reader path, then compare the raw read, policy decision, and final action. The evidence should show which control stopped misuse and what the fallback did.

Two problems follow. First, anyone with a reader and writable blank tag may be able to clone a low-assurance tag by copying the EPC. Second, anyone with a reader may be able to track what a person or object is carrying by inventorying stable tag identifiers. The fixes are different, so the review should not collapse both into “add encryption.”

Make the review concrete. Suppose a staff badge, a tool tag, and a cabinet reader all produce stable identifiers. If the workflow stores badge ID, tool EPC, reader ID, and timestamp for 12,000 observations per day, a one-year raw log creates about 12,000 * 365 = 4,380,000 linkable rows. A privacy-minded release might keep raw observations for 30 days, or 12,000 * 30 = 360,000 rows, then retain only exception events, custody state, and aggregated counts for longer reporting.

The same discipline applies to security evidence. A release claim such as “known tag observed” is weak. A stronger claim names the protected action: “issue this instrument to this authorized user from this cabinet.” That claim needs at least four checks: the tag identity matched the expected instrument record, the reader was an approved cabinet reader, the read happened inside the cabinet event window, and backend policy allowed the user to take that instrument.

7.10 Cloning and Tracking Are Separate Threats

This section: Cloning and Tracking Are Separate Threats — The same RFID workflow can have both anti-cloning and privacy requirements, but the evidence differs.

The same RFID workflow can have both anti-cloning and privacy requirements, but the evidence differs.

ThreatWhy classic Gen2 is exposedMitigation
CloningThe EPC is readable and writable, so it may copy onto a blank tag.Verify read-only TID where appropriate; use cryptographic tag authentication for real assurance.
Unauthorized write or kill32-bit passwords are static operational controls, not strong identity proof.Set access and kill passwords, lock memory banks, and treat them as limited controls.
Covert trackingA passive tag answers any compliant reader unless the workflow prevents it.Kill at point of sale, shield, limit read zones, or use privacy features such as untraceable mode where supported.
EavesdroppingReader-to-tag transmissions can be stronger than the tag backscatter response.Minimize data on the tag, tune read zones, and use stronger protocol controls where risk justifies the cost.

A subtle point behind eavesdropping is link asymmetry. The reader transmission can be heard farther than the faint tag backscatter, so short tag-read range does not automatically mean short eavesdropping range. Review evidence should name the antenna, power, shielding, field layout, message content, and data retained from reads.

Review cloning and privacy with separate tests. In a receiving doorway, the clone test might use 40 expected tagged cases, one duplicate EPC written to a lab tag, and one unauthorized reader. A clean event record should say 40 / 40 expected cases accepted, 0 / 1 duplicate EPC accepted as a new item, and 0 / 1 unauthorized reader accepted. If the duplicate EPC is accepted because only the EPC was checked, the mitigation is stronger identity evidence, not a nicer dashboard.

The privacy test asks a different question: can observations be joined into a person-level trail? If a worker badge is read at a tool room, clean room, and loading dock, the raw data can describe a shift pattern even if no sensitive field appears on the tag. A practitioner review should separate operational custody from people analytics, restrict person-linked audit access, and prove that reports cannot casually list every reader visit for a named person unless that access is explicitly approved.

7.11 Trust Boundaries

This section: Trust Boundaries — Security quality improves when each boundary has its own evidence.

Security quality improves when each boundary has its own evidence. A tag read is not a credential. A credential is not authorization. Authorization is not a privacy review.

Inspect Figure 7.3 and ask which independent checks must occur before a tag observation can authorize an action.

RFID trust boundaries from tag and reader through middleware, backend policy, audit, and privacy review.
Figure 7.3: RFID trust boundaries from tag and reader through middleware, backend policy, audit, and privacy review.

Read Figure 7.3 from the raw tag read to the back-end rule. Each step adds reader identity, zone context, and data checks. A tag may name an item without proving it is real. Proof of identity still does not grant the right to act. The privacy edge sets a purpose and storage term when reads expose people, accounts, work, care, or place history. Support logs keep denied reads, likely copies, stale tags, unknown readers, complaints, and overrides. Trust comes from these separate checks, not from one good scan.

Tag boundary. Decide whether the tag only identifies an object or also supports authentication, protected memory, access passwords, or cryptographic challenge-response.
Reader boundary. Readers should be authorized, configured, monitored, and tied to expected antenna zones. A reader ID by itself is not enough if readers can be moved or cloned.
Middleware boundary. Middleware should preserve raw evidence, reject unexpected readers, validate tag format, deduplicate reads, and attach zone context.
Backend boundary. The backend should own authorization, policy, key lifecycle, account state, retention, and audit. Tags should not silently carry final business truth.
Privacy boundary. If reads can be linked to a person, account, device, item basket, workplace behavior, patient workflow, or location history, the data needs a stated purpose and retention rule.
Support boundary. Operators need traces for denied reads, suspected clones, stale tags, unknown readers, missing tags, privacy complaints, and emergency overrides.

7.12 Layered Controls

This section: Layered Controls — No single RFID control covers every risk.

No single RFID control covers every risk. Use layers that match the protected action.

Figure 7.4 places checks at the tag, reader, event, backend, and physical zone.

RFID layered controls showing tag authentication, reader authorization, event filtering, backend policy, physical read-zone control, privacy minimization, and audit.
Figure 7.4: RFID layered controls include tag authentication, reader authorization, event filtering, backend policy, read-zone control and privacy minimization, followed by monitoring, fallback and retest.

Tag authentication can challenge a protected identifier. Reader authorization decides which devices may collect or submit observations. Event filtering separates duplicates and out-of-zone reads before backend policy permits a business action. Physical read-zone control reduces neighboring captures but cannot replace those later checks. Privacy minimization limits what identifiers and logs reveal, and monitoring with a fallback makes failures visible. Test a legitimate item and a copied or stray tag through the complete path. A pass at one layer does not prove the others, so keep each decision in the audit record.

Authenticated tags Use tags and protocols that can prove possession of a secret when cloning or unauthorized reading is in scope.
Mutual authentication Require both reader and tag to prove authority when rogue readers or sensitive data exposure are realistic risks.
Key management Provision keys deliberately, protect reader credentials, rotate when needed, and remove stale readers from trust lists.
Read-zone control Tune power, antennas, shielding, placement, and no-read zones so physical reads match workflow intent.
Event filtering Detect duplicate reads, impossible movement, unexpected reader/tag pairs, repeated denied attempts, and stale state transitions.
Privacy minimization Avoid unnecessary stable IDs in logs, limit retention, separate identity from item data, and document data sharing.
Availability controls Monitor reader health, jamming-like interference, antenna faults, network outages, and tag disablement events.
Fallback controls Define manual identification, supervisor override, exception queue, and reconciliation so security does not fail open silently.

7.13 Gen2v2 and ISO 29167 Authentication

This section: Gen2v2 and ISO 29167 Authentication — Passwords cannot stop cloning, because a password is a static secret that a copied tag may also carry, and reading the EPC does not require the password anyway.

Passwords cannot stop cloning, because a password is a static secret that a copied tag may also carry, and reading the EPC does not require the password anyway. Stopping a clone requires proving that the tag holds a secret without revealing it. EPC Gen2v2 supports that model by connecting the air interface to ISO/IEC 29167 cryptographic suites, including algorithms such as AES-128, PRESENT-80, and Grain-128A for constrained tag operations.

With cryptographic challenge-response, the reader sends a random challenge, the tag returns a response computed with a key it never transmits, and a clone that lacks the key cannot answer correctly. Gen2v2 also defines an untraceable command that lets a tag hide or shorten what it reveals to unauthenticated readers, which addresses tracking separately from cloning.

The reason a 32-bit access password is the wrong assurance model is visible in the math. It has 2^32 = 4,294,967,296 possible values, but it is still a static value used for access control, not proof that the silicon is genuine. If that value is exposed through provisioning records, reader compromise, weak operations, or a copied tag image, every copied tag can carry the same value.

A challenge-response changes the evidence. The verifier records the random challenge, expected response, observed response, key identifier or key version used by the verifier, and decision without logging the secret itself. That is the kind of trace a release reviewer can inspect for high-value product authentication, controlled drug custody, or access workflows where cloning is in scope.

Relay remains a separate trap. A relay attacker does not need to decrypt the exchange; it forwards messages between a genuine tag and a genuine reader. Timing evidence has to be designed at the RF or workflow layer, not inferred from ordinary backend logs. As a physical intuition, radio travels roughly 0.3 m per nanosecond, so a 100 ns timing uncertainty corresponds to about 30 m one-way, or about 15 m in a round-trip distance estimate. Millisecond-scale application logs are far too coarse for proximity proof.

7.14 Quick Check: Gen2v2 Authentication

This section: Quick Check: Gen2v2 Authentication

7.15 Privacy Review

This section: Privacy Review — RFID privacy risk comes from linking a stable or repeated observation to a person, place, time, product, account, job role, patient workflow, or household pattern.

RFID privacy risk comes from linking a stable or repeated observation to a person, place, time, product, account, job role, patient workflow, or household pattern. The tag may only reveal “an ID,” but the system can often connect that ID to other records.

Figure 7.5 makes identifier linkage and retention an engineering review.

RFID privacy review flow showing identifier, person linkage, purpose, minimization, retention, sharing, access, and complaint handling.
Figure 7.5: RFID privacy review flow showing identifier, person linkage, purpose, minimization, retention, sharing, access, and complaint handling.

The privacy flow in Figure 7.5 begins with an identifier read, then asks whether it can be linked to a person or account. State the purpose before choosing which fields to keep; reduce the data to that purpose and set a retention limit. Sharing rules name who may receive the record, while access and complaint paths let an affected person challenge it. These are engineering decisions because middleware can create a personal event history even when a tag carries only an item code. Keep a record of the linkage, minimized fields, retention rule, sharing owner, and deletion or complaint outcome for review.

Map the linkage. Decide whether tag reads can be linked to employees, students, patients, customers, visitors, vehicles, accounts, loyalty records, or payment records.
State the purpose. Inventory accuracy, access control, safety, recall, maintenance, or custody review should be written before data is collected.
Minimize collection. Store the fields needed for the purpose, not every raw read forever. Separate operational records from analytics where possible.
Limit retention and sharing. Define how long reads, exceptions, and audit logs are retained and who may receive them.
Provide notice and access paths. User-facing, worker-facing, patient-facing, or consumer-facing RFID systems may need notice, access, deletion, or opt-out processes depending on jurisdiction and policy.
Review regulations with the owner. GDPR, CCPA/CPRA, HIPAA, payment rules, workplace policy, sector rules, and contract obligations may apply. Treat this chapter as engineering guidance, not legal advice.

7.16 Worked Review: Controlled Asset Cabinet

This section: Worked Review: Controlled Asset Cabinet — A lab wants to use RFID to issue high-value test instruments from a cabinet.

A lab wants to use RFID to issue high-value test instruments from a cabinet. Each instrument has a tag, each user has a badge, and the cabinet reader sees several instruments at once when the door opens.

The risky design is to unlock the cabinet when any known badge is read and to mark every visible instrument as issued. That design trusts static IDs too much and ignores read-zone ambiguity.

rfid_security_review: workflow: controlled instrument cabinet protected_action: unlock, issue instrument, confirm return tag_evidence: instrument_tag: authenticated or tamper-evident where risk requires badge_tag: credential input, not final authorization reader_evidence: cabinet_reader_id: authorized antenna_zone: inside cabinet, door threshold, no-read outside zone backend_policy: user_role: allowed for instrument class instrument_state: available, issued, returned, calibration due, quarantined action_rule: issue only after door event, expected tag set, and user confirmation privacy_controls: purpose: custody and safety retention: operational audit period sharing: asset owner and compliance review only exception_tests: unknown badge, cloned-looking instrument, missing return, wrong-zone read, reader offline, manual override retest_triggers: moved antenna, new cabinet layout, new tag model, key rotation, firmware update, policy change

The release decision should require both access-control evidence and asset-event evidence. Badge authentication answers “who is asking?” Instrument reads answer “what appears to be present?” Backend policy answers “what action is allowed?”

7.17 Release Notes

This section: Release Notes — Before release, collect evidence that a second reviewer can inspect.

Before release, collect evidence that a second reviewer can inspect.

Threat model record. Protected action, attacker assumptions, attack paths, and accepted residual risk.
Credential and key record. Tag capability, reader authorization, key provisioning, key storage owner, rotation path, and reader decommission process.
RF validation record. Read-zone map, no-read-zone tests, shielding/tuning notes, reader health behavior, and interference observations.
Event validation record. Accepted reads, denied reads, duplicate handling, suspected clone behavior, stale state, and exception queue.
Privacy record. Purpose, fields collected, person linkage, retention, access, sharing, notice, and complaint path.
Operations record. Monitoring, fallback, override owner, incident response, support logs, training, and retest triggers.

7.18 Common Pitfalls

This section: Common Pitfalls

Treating a public identifier as a secret. UID, EPC, or card number can often be observed. Use authentication and backend policy when security matters.
Assuming encryption stops relay. Relay devices can forward encrypted messages. Add timing, distance, workflow, or user-action controls where relay is in scope.
Leaving reader trust unmanaged. Retired readers, copied credentials, moved antennas, and stale firmware can bypass otherwise good tag controls.
Collecting more privacy data than needed. Stable item and badge reads can become movement or behavior records when retained or joined with other systems.
Skipping failure rehearsal. Test missing tags, extra tags, rogue readers, denied access, jammed zones, offline backend, and emergency override before release.

7.19 Knowledge Check

This section: Knowledge Check

7.20 Quick Check: Relay Versus Encryption

This section: Quick Check: Relay Versus Encryption

7.21 Matching Quiz: Risk To Control

This section: Matching Quiz: Risk To Control

7.22 Ordering Quiz: RFID Security Review

This section: Ordering Quiz: RFID Security Review

7.23 Checkpoint: Summary

This section: Checkpoint: Summary

  • RFID security review starts with the protected action and threat model, not with a generic control list.
  • Static tag identifiers should not be treated as secrets or authorization proof.
  • Layered controls span tag authentication, reader authorization, middleware filtering, backend policy, physical read-zone control, privacy minimization, monitoring, and fallback.
  • Privacy risk increases when stable tag reads are linked to people, accounts, locations, time, or behavior records.
  • Release evidence should include security traces, privacy review, exception tests, owner decisions, and retest triggers.

7.24 Key Takeaway

This section: Key Takeaway — RFID security and privacy review must include tag data, reader access, backend events, cloning risk, tracking risk, and retention policy.

RFID security and privacy review must include tag data, reader access, backend events, cloning risk, tracking risk, and retention policy.

Find help

3 reviewed answers.

Where should I start in a module?

Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.

Modules and paths

Reviewed

What can I try when a project does not work?

Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.

When you are stuck

Reviewed

How do interactive examples work?

Use the interactive guide to check how examples and simulations work before changing your project.

Interactive examples guide

Reviewed