8  RFID Security and Privacy

8.1 Start With the Story

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.

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.

8.2 In 60 Seconds

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.

Phoebe’s Field Notes: Why the Reader “Talks Louder” Than the Tag Answers

Phoebe’s Why

This chapter’s own eavesdropping note is a real, well-established result, and it has a clean physical reason. A UHF RFID exchange (working many wavelengths from either antenna, so ordinary far-field gain and EIRP reasoning applies rather than NFC’s near-field coupling) is really two separate links sharing one channel: the reader’s forward transmission travels one way to the tag, and the tag’s backscattered reply is a re-radiated fraction of that same field, which must then travel back. An eavesdropper listening to the reader’s own outgoing signal only pays the one-way toll; the tag’s reply has effectively paid it twice, once out and once back, and a passive tag also needs enough incident power just to wake up – a far higher threshold than an eavesdropper’s receiver needs to merely detect a signal above its noise floor. Antenna gain can widen either listening distance further, but it does not create the asymmetry; the physics of “one trip versus a round trip, tag wake versus receiver sensitivity” does.

The Derivation

Effective isotropic radiated power and free-space loss on the reader’s forward, one-way link:

\[\mathrm{EIRP\,(dBm)} = P_t\,\mathrm{(dBm)} + G\,\mathrm{(dBi)}, \qquad \mathrm{FSPL_{dB}}(d) = 20\log_{10}\!\left(\frac{4\pi d}{\lambda}\right)\]

A link closes once received power clears the listener’s sensitivity floor, so the maximum range for a one-way listen is:

\[d = \frac{\lambda}{4\pi}\times10^{(\mathrm{EIRP}-S)/20}\]

Extra eavesdropper antenna gain still buys range the ordinary way:

\[\frac{d_2}{d_1} = 10^{\Delta G_{dB}/20}\]

Worked Numbers: Tag Wake Range Versus Listening Range

The chapter names link asymmetry but fixes no power budget, so take standard, catalog-typical EPC Gen2 UHF figures at 915 MHz (\(\lambda=0.328\) m): a 30 dBm reader EIRP (FCC Part 15 typical maximum), a \(-18\) dBm passive-tag activation threshold, and a \(-95\) dBm eavesdropping-receiver sensitivity.

• Tag’s own working range, set by the forward wake-up link: loss budget \(30-(-18)=48\) dB, giving \(d_{tag} = (0.328/4\pi)\times10^{48/20} = 6.55\) m – a realistic passive UHF read range
• Direct-listen eavesdropping range on that same forward transmission: loss budget \(30-(-95)=125\) dB, giving \(d_{eaves}=(0.328/4\pi)\times10^{125/20}\approx 46{,}400\) m as a free-space ceiling – terrain, ground effects, and obstruction cut real deployments far below this, but the ratio is the point: \(d_{eaves}/d_{tag}\approx 7{,}080\times\)
• That ratio is not from gain; it is purely the 77 dB gap between a passive tag’s wake threshold and a purpose-built receiver’s sensitivity floor
• Adding a 9 dBi directional antenna to the eavesdropper on top of that: \(10^{9/20}=2.82\times\) further again – a genuine gain effect, but a small multiplier next to the four-order-of-magnitude sensitivity gap already there

Short tag-read range is real physics, but it describes only the round-trip backscatter link the reader itself is designed around. The reader’s own outgoing signal pays no such round-trip toll, which is exactly why this chapter’s evidence record has to name the antenna, power, and shielding – the number that matters for eavesdropping risk is never the tag’s rated read range.

8.3 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.

8.4 Quick Check: RFID Security

8.5 Prerequisites

Recommended context:

• RFID Fundamentals and Standards for tag, reader, frequency, and standards vocabulary.
• RFID Hardware Integration for reader, antenna, middleware, and evidence boundaries.
• RFID Real-World Applications for application-pattern and privacy-boundary examples.
• Encryption and the Key Hierarchy for cryptographic control vocabulary.
• Mobile Privacy Overview for personal-data and purpose-limitation concepts.

8.6 Ethics and Authorization

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.

8.7 Threat Model First

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.

RFID threat model review path that starts with the protected action, then tests attacker assumptions, attack paths, controls, evidence, and retest triggers.

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.

8.8 Attack Surfaces

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.

8.9 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. A tag has two 32-bit secrets: a kill password that permanently silences it and an access password that gates writing and locking memory. 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.

RFID security boundary map showing risks, controls, telemetry, lifecycle, and a reminder that a readable ID is not a credential.

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.

8.10 Cloning and Tracking Are Separate Threats

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

Threat	Why classic Gen2 is exposed	Mitigation
Cloning	The 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 kill	32-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 tracking	A 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.
Eavesdropping	Reader-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.

8.11 Trust Boundaries

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.

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

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.

8.12 Layered Controls

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

RFID layered controls showing tag authentication, reader authorization, event filtering, backend policy, physical read-zone control, privacy minimization, and audit.

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.

8.13 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. 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.

8.14 Quick Check: Gen2v2 Authentication

8.15 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. The tag may only reveal “an ID,” but the system can often connect that ID to other records.

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

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.

8.16 Worked Review: Controlled Asset 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?”

8.17 Release Notes

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.

8.18 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.

8.19 Knowledge Check

8.19.1 Quick Check: Relay Versus Encryption

8.19.2 Matching Quiz: Risk To Control

8.19.3 Ordering Quiz: RFID Security Review

8.20 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.

8.21 Key Takeaway

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

8.22 What’s Next

RFID Standards and Protocols Connect security controls to standards vocabulary and protocol boundaries.

RFID Design and Deployment Apply threat-model, read-zone, and privacy controls to deployment planning.

RFID Troubleshooting Diagnose missed reads, wrong-zone reads, duplicate events, and interference that can affect security evidence.

NFC Security and Comparisons Compare RFID security ideas with deliberate NFC tap workflows.

Threat Modelling Process Place RFID controls in a broader IoT security and governance program.

Encryption and Key Hierarchy Review cryptographic building blocks used by stronger tag and credential systems.