7 RFID Security and Privacy
7.1 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.
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
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.
7.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.
7.4 Quick Check: RFID Security
7.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.
7.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.
Inspect RFID Threat Model Before Controls and authentication, zone in Figure 7.1 for threat model first. Before accepting threat model first, follow the change from RFID Threat Model Before Controls to authentication, zone on it. The remaining question is A raw tag read is evidence, not consent.
Read RFID Threat Model Before Controls with authentication, zone in Figure 7.1 for threat model first. Check it by keeping RFID Threat Model Before Controls, authentication, zone, and A raw tag read is evidence, not consent as separate entries. Both RFID Threat Model Before Controls and authentication, zone need evidence. This supplies threat model first with a concrete retest point.
7.8 Attack Surfaces
RFID attack surfaces come from radio communication, static identifiers, constrained tags, reader placement, backend trust, and data retention.
7.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.
Inspect cloning or emulation and reader and event logs in Figure 7.2 for classic gen2 security is deliberately thin. To make classic gen2 security is deliberately thin reviewable, inspect how cloning or emulation relates to reader and event logs in it. retain needed data marks the next check.
Read cloning or emulation with reader and event logs in Figure 7.2 for classic gen2 security is deliberately thin. Locate its roles with cloning or emulation and reader and event logs on distinct boundaries before retain needed data. Success at cloning or emulation cannot prove the reader and event logs boundary. That is the review order required by classic gen2 security is deliberately thin.
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
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.
7.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.
Inspect purpose and and trace and in Figure 7.3 for trust boundaries. Before carrying trust boundaries forward, put purpose and and trace and into the same reading of it. A tag read is evidence identifies the later check.
Read purpose and with trace and in Figure 7.3 for trust boundaries. Audit it from the purpose and field to trace and, then the A tag read is evidence disposition. Combining purpose and with trace and hides accountability. Use trace and to assign evidence ownership in trust boundaries.
7.12 Layered Controls
No single RFID control covers every risk. Use layers that match the protected action.
Inspect Layered RFID Controls and backend policy in Figure 7.4 for layered controls. Before acting on layered controls, keep both Layered RFID Controls and backend policy visible in it. and audit identifies the later check.
Read Layered RFID Controls with backend policy in Figure 7.4 for layered controls. Read its route starting at Layered RFID Controls, crossing backend policy, and closing on and audit. A failure at backend policy changes the route from Layered RFID Controls. Attach the next action in layered controls to and audit.
7.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.
7.14 Quick Check: Gen2v2 Authentication
7.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.
Inspect read and fields in Figure 7.5 for privacy review. To place privacy review on firm evidence, follow the change from read to fields on it. rule marks the next check.
Read read with fields in Figure 7.5 for privacy review. Review it with read as one fact, fields as another, and rule as the closeout. Combining read with fields hides accountability. Attach the next action in privacy review to rule.
7.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.
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
Before release, collect evidence that a second reviewer can inspect.
7.18 Common Pitfalls
7.19 Knowledge Check
7.20 Quick Check: Relay Versus Encryption
7.21 Matching Quiz: Risk To Control
7.22 Ordering Quiz: RFID Security Review
7.23 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
RFID security and privacy review must include tag data, reader access, backend events, cloning risk, tracking risk, and retention policy.