From cc140650da473e9b76a5042da0402f90b80a519f Mon Sep 17 00:00:00 2001 From: ruvnet Date: Tue, 11 Aug 2026 17:20:21 +0000 Subject: [PATCH] deploy: 90c6ecc530c0f54b3e63e37f5abab2fe5a0e1186 --- ...-veil-privacy-shield-compliant-waveform.md | 231 ++++++++++++++++++ ...pose-privshield-harness-via-metaharness.md | 95 +++++++ ...eil-e2e-hardware-implementation-program.md | 94 +++++++ api-docs/adr/README.md | 3 + .../research/privacy-shield/01-sota-survey.md | 141 +++++++++++ .../privacy-shield/02-threat-model.md | 94 +++++++ .../03-countermeasure-design.md | 136 +++++++++++ .../04-compliance-and-regulatory.md | 90 +++++++ .../privacy-shield/05-experiment-protocol.md | 113 +++++++++ .../privacy-shield/06-market-and-buyers.md | 92 +++++++ .../07-implementation-and-roadmap.md | 117 +++++++++ .../privacy-shield/08-optimization.md | 142 +++++++++++ .../privacy-shield/09-sota-update-2026.md | 151 ++++++++++++ api-docs/research/privacy-shield/README.md | 102 ++++++++ 14 files changed, 1601 insertions(+) create mode 100644 api-docs/adr/ADR-288-veil-privacy-shield-compliant-waveform.md create mode 100644 api-docs/adr/ADR-289-wifi-densepose-privshield-harness-via-metaharness.md create mode 100644 api-docs/adr/ADR-290-veil-e2e-hardware-implementation-program.md create mode 100644 api-docs/research/privacy-shield/01-sota-survey.md create mode 100644 api-docs/research/privacy-shield/02-threat-model.md create mode 100644 api-docs/research/privacy-shield/03-countermeasure-design.md create mode 100644 api-docs/research/privacy-shield/04-compliance-and-regulatory.md create mode 100644 api-docs/research/privacy-shield/05-experiment-protocol.md create mode 100644 api-docs/research/privacy-shield/06-market-and-buyers.md create mode 100644 api-docs/research/privacy-shield/07-implementation-and-roadmap.md create mode 100644 api-docs/research/privacy-shield/08-optimization.md create mode 100644 api-docs/research/privacy-shield/09-sota-update-2026.md create mode 100644 api-docs/research/privacy-shield/README.md diff --git a/api-docs/adr/ADR-288-veil-privacy-shield-compliant-waveform.md b/api-docs/adr/ADR-288-veil-privacy-shield-compliant-waveform.md new file mode 100644 index 00000000..2983e4fd --- /dev/null +++ b/api-docs/adr/ADR-288-veil-privacy-shield-compliant-waveform.md @@ -0,0 +1,231 @@ +# ADR-288: VEIL — a compliant-waveform privacy shield against unauthorized WiFi sensing + +| Field | Value | +|-------|-------| +| **Status** | Proposed — implemented (P1 reference model) | +| **Date** | 2026-08-09 | +| **Deciders** | ruv | +| **Codename** | **VEIL** — Verifiable Emission-shaping for Identity-Leakage prevention | +| **Codebase target** | new leaf crate `v2/crates/wifi-densepose-privshield` | +| **Parent** | ADR-118 (BFLD — the detection layer VEIL is the countermeasure to), ADR-282 (mandatory L0–L5 evidence ladder) | +| **Relates to** | ADR-120/121 (BFLD privacy class + identity-risk scoring — the trigger source), ADR-141 (privacy control plane / runtime attestation — the audit consumer), ADR-280 (active sensing / governed actuation — VEIL is a defensive sensing action), ADR-185 §13 (`wifi-densepose-aether` — the pure-compute leaf pattern this crate follows) | +| **Research bundle** | [`docs/research/privacy-shield/`](../research/privacy-shield/) (9 files) | +| **Tracking issue** | TBD | + +## 0. PROOF discipline + +Every defense number this crate produces is **SYNTHETIC / evidence level L0** +(ADR-282): generated by the crate's own model (`identity::Channel`), attacked by +the crate's own classifier (`attacker::NearestCentroidAttacker`), and scored +against its own known labels. Nothing here has been validated against real WiFi +silicon, and the crate contains no radio integration and cannot emit RF. External +attack/defense results cited from the literature (BFId, LeakyBeam, DySPAN-2026, +IRShield, FCC statutes) are **EXTERNAL** evidence and labelled MEASURED/CLAIMED in +the research bundle. The single measured claim about *our own behavior* is the +pinned deterministic witness in `proof.rs`. + +## 1. Context + +### 1.1 The gap + +IEEE 802.11ac/ax beamforming feedback (BFI) — the compressed Givens-rotation +angle matrices (φ/ψ) a client sends the AP — is transmitted **unencrypted on the +management plane**. Any device in monitor mode can capture it for every station +at once, no network access, and the target need carry no device. The literature +establishes the severity: **BFId** (ACM CCS 2025) re-identifies individuals from +BFI; **LeakyBeam** (NDSS 2025) detects occupancy through walls at 20 m from BFI; +**BeamSense** recognizes activities at up to 99.28%. IEEE Std **802.11bf-2025** +(published 26 Sep 2025) standardizes the sensing measurement/feedback surface +these attacks abuse — and a 2023 proposal for a BFI secure-transmission mechanism +(802.11-23/0782) was **withdrawn**, so the standard shipped with no privacy +protections. + +RuView already has a *detection* layer for this: **BFLD** (ADR-118/121) measures +the identity-leakage of each frame and gates what leaves the node. But BFLD +protects *RuView's own outputs*; it does nothing about a **third-party sniffer** +capturing the room's plaintext BFI off the air. There is no RuView component, and +per our market survey no shipping product anywhere, that prevents that. + +### 1.2 Constraint: compliant waveform controls, never jamming + +The defense must preserve normal communications and must not interfere with any +other station. Jamming (47 U.S.C. §333/§302a) is defined by *adding energy to +interfere with others' transmissions*. Any acceptable control must shape only the +node's **own** standards-conformant emission. + +### 1.3 The separability insight + +Identity leaks through the *fine* cross-subcarrier phase structure of a +beamforming report; data throughput rides the *dominant* beam direction. These +are (mostly) separable subspaces — so a transform confined to the fine subspace +can wreck re-identification while sparing the beam the link depends on. DySPAN-2026 +independently MEASURED that shaping fine-resolution feedback is near-free in +throughput, corroborating the insight. + +## 2. Decision + +Ship **`wifi-densepose-privshield`** (VEIL) as a standalone pure-compute leaf +crate (the `wifi-densepose-aether`/`nvsim` pattern: dependency-free, deterministic, +WASM-ready, zero coupling to any radio or ingestion path), implementing: + +1. **A SYNTHETIC two-subspace BFI model** (`identity.rs`): each identity owns a + stable fine-block signature; sessions add environmental nuisance; the comm + block is identity-free and carries throughput. +2. **The protector** (`protector.rs`): compliant waveform controls, primarily a + **per-session keyed orthogonal rotation of the fine subspace, composed from + extra Givens rotations** — the report's native primitive. Plus feedback + quantization/dither, sounding-cadence randomization, and a `SensingDetector` + that engages the shield only when sensing activity is observed. +3. **The adversary** (`attacker.rs`): a passive nearest-centroid re-identifier + modeling the BFId threat, with selectable Euclidean/Cosine metrics. +4. **A throughput model** (`throughput.rs`): + `(1 − sounding − feedback_airtime) · C(SNR·(1−ρ))/C(SNR)`, where the residual + `ρ` falls with feedback bits and the feedback airtime rises with them — giving + a genuine interior throughput optimum in feedback resolution. +5. **A compliance audit** (`compliance.rs`): the rotation is orthogonal ⇒ + energy-preserving ⇒ adds no interfering energy ⇒ **not jamming**, turned into a + checked `ComplianceReport` (energy ratio ≈ 1.0). +6. **The experiment** (`experiment.rs`): runs the attacker against unprotected and + protected traffic and reports both accuracies vs. chance, plus throughput and + compliance, with a single `passed()` verdict. +7. **The hyper-optimizer** (`optimize.rs`): derives the shipped shield config + rather than hand-picking it — the throughput-optimal feedback resolution and + the minimum rotation-mixing budget that collapses re-ID robustly (across both + attacker metrics and N∈{16,32}), plus a Pareto frontier. +8. **A deterministic proof** (`proof.rs`): a pinned FNV-1a witness over the + reference experiment (the `nvsim`/`verify.py` discipline). + +### 2.1 Why the keyed Givens rotation + +It is simultaneously **orthogonal** (energy-preserving ⇒ compliant), +**key-reversible** (the associated AP shares the session key and recovers the true +precoder ⇒ throughput preserved), and **fresh per session** (a sniffer sees a new +random rotation of the signature each session and cannot average it back ⇒ the +enrollment attack collapses; over unknown rotations the signature carries no +stable discriminative information ⇒ re-ID → chance). It is the shared-secret +precoding idea (cf. MIMOCrypt) specialized to the identity-bearing subspace. + +### 2.2 Measured behavior (SYNTHETIC / L0) + +Reference experiment at the hyper-optimized operating point (§opt), default +scene, N=16 identities, `cargo test`: + +| Metric | Shield off | Shield on | +|---|---|---| +| Passive re-ID accuracy | 100.0% | **4.7%** (chance 6.25%) | +| Link throughput ratio | 100% | **97.6%** | +| Emission energy ratio | — | **1.000000** (compliant) | + +All 35 unit/proof tests + doctest pass; the crate builds for +`wasm32-unknown-unknown` and is clippy-clean. + +### opt. Hyper-optimization (`optimize.rs`) + +The shipped shield config is the optimizer's output, not a guess, and +`ShieldConfig::default()` is asserted equal to it: + +- **Feedback resolution = 5 bits.** Throughput has an interior optimum in + feedback bits (residual falls, feedback airtime rises); the unconstrained + optimum is 3 bits (matching DySPAN-2026), and 5 is the throughput-best value in + the spec-allowed 802.11 {5,7,9} set. +- **Givens passes = 96.** The proven minimum for robust collapse — across both + attacker metrics *and* N∈{16,32} — is **48**; the shipped 96 is a free 2× + privacy margin, since the keyed rotation is derived from the shared secret and + never signaled (extra passes cost compute, not airtime). The original + hand-picked 112 was 2.3× over-provisioned. + +Net vs. the original hand-picked (112 passes / 7 bits): the optimum is strictly +better on **both** privacy (re-ID 0.047 vs 0.078) and throughput (0.976 vs 0.974), +and is now verified rather than assumed. See +`docs/research/privacy-shield/08-optimization.md`. + +### harness. Native terminal harness + TUI (`src/bin/veil.rs`) + +A custom, dependency-free binary (`veil`) ships with the crate — the in-repo, +native counterpart to the npm metaharness (ADR-289). It drives the same public +API the tests use, as an interactive ANSI dashboard plus scriptable subcommands +(`report`, `sweep`, `optimize`, `adaptive `, `proof`, `doctor`, `tui`). +Std-only (no `crossterm`/`ratatui`): the TUI is a command-driven redraw loop, so +it runs in any terminal, pipe, or CI and keeps the crate a pure leaf. It reports +only SYNTHETIC/L0 numbers and never relabels them. The wasm leaf story is +unchanged (validated with `--lib`; the bin is native-only). + +### sota. 2025–2026 evidence update (verified) + +A cited, adversarially-verified SOTA sweep +(`docs/research/privacy-shield/09-sota-update-2026.md`) refines the threat and +positioning. Load-bearing points for this ADR: + +- **Threat is broader and cheaper than §1.1 stated.** A passive, keyless, + single-antenna sniffer at ~20 m and *through walls* can identify people + (BFId, 99.5%/N=197, `MEASURED`), read **breathing** from stationary occupants + and **keystrokes/PINs** (LeakyBeam / WiKI-Eve / SThief, `MEASURED`), and — + decisively — **reconstruct full CSI from the sniffed BFI** (BFIAttack, + ≥93% single-antenna, `MEASURED`). VEIL's obfuscation must therefore degrade + *reconstructed-CSI* utility, not merely raw-BFI feature noise; because VEIL's + rotation is a **secret orthogonal** transform, the attacker has no key and no + closed-form to invert — this is now a claim to **test**, not assume. +- **VEIL's family is independently validated.** AP-side per-packet random + unitary on the LTF (LeakyBeam defense, 89.7%→~51%, `MEASURED`) and RIS + obfuscation (PrivISAC, 93%→~30%, robust to a retrained multi-location + attacker, `MEASURED`) confirm standard-permitted beamforming-surface + obfuscation works; DP-Givens quantization (`SYNTHETIC`) offers a formal ε knob. +- **Compliance precedent.** BeamDancer (IEEE TWC 2024, `MEASURED`) argues + native-beamforming obfuscation is 802.11-compliant while jamming/geofencing + are not — cite it as precedent. (Its ">96% PDR" figure was **refuted** in + verification; do not cite it.) +- **Security honesty.** Obfuscation shields have published counter-attacks + ("Defeating CSI obfuscation", SnoopFi), so VEIL's own shield security is + `CLAIMED`, not proven-secure, until it withstands learned de-obfuscation. +- **Governance gap.** No claim on 802.11bf-2025 privacy provisions survived + verification; that pillar remains an open question, not an asserted fact. + +The derived, prioritized improvement backlog lives in the SOTA-update file (§4). + +## 3. What this explicitly is NOT + +- **Not a radio driver.** No RF frontend, no transmit path, no + `wifi-densepose-hardware` coupling. VEIL cannot emit and cannot jam. +- **Not a defense against the associated AP.** That party holds the session key by + construction (threat class A3); protecting against a malicious AP is BFLD's + detection/privacy-class problem (ADR-118/141), not this shield's. +- **Not a full motion-obfuscation claim.** A fixed per-session rotation does not + hide coarse within-session motion; identity *re-ID* is the guaranteed target, + motion is partial/future work. +- **Not a real-hardware performance claim.** All defense numbers are SYNTHETIC/L0 + until a two-node capture with a boot/runtime-log witness exists (CLAUDE.md + hardware rule; roadmap P5). +- **Not RF denial or camera-grade anything.** + +## 4. Simplifications (honesty boundary) + +- The two-subspace split is an abstraction; on real radios comm and identity + information are only *approximately* separable, so the real throughput cost of + fully hiding identity may exceed the model's ~2%. DySPAN-2026's MEASURED curve + bounds it as *small* at fine resolution, not zero. +- The attacker is nearest-centroid. The collapse argument is classifier-independent + (it is about the marginalized signal), but P2/P5 must confirm a learned attacker + also collapses. +- The crate's PRNG is SplitMix64 — deterministic and WASM-safe but **not + cryptographic**; a deployment derives the rotation key from the negotiated link + secret, never from this PRNG. + +## 5. Consequences + +- RuView gains the *countermeasure* half of its RF-privacy story: BFLD detects + leakage, VEIL acts on it — a defensible, standards-anchored, gap-filling + position (see `docs/research/privacy-shield/06-market-and-buyers.md`). +- The compliance audit gives regulators/auditors a machine-checkable "not jamming" + artifact that composes with ADR-141 attestation. +- Future integration (BFLD `identity_risk` → `SensingDetector`, ADR-280 governed + actuation, firmware feedback shaping, two-node hardware measurement) is staged in + the research bundle roadmap and deliberately deferred so the model validates in + isolation first. + +## 6. Validation + +```bash +cargo test -p wifi-densepose-privshield --no-default-features +cargo build -p wifi-densepose-privshield --target wasm32-unknown-unknown +cargo clippy -p wifi-densepose-privshield --all-targets +``` diff --git a/api-docs/adr/ADR-289-wifi-densepose-privshield-harness-via-metaharness.md b/api-docs/adr/ADR-289-wifi-densepose-privshield-harness-via-metaharness.md new file mode 100644 index 00000000..ad8e9c92 --- /dev/null +++ b/api-docs/adr/ADR-289-wifi-densepose-privshield-harness-via-metaharness.md @@ -0,0 +1,95 @@ +# ADR-289: `wifi-densepose-privshield-harness` — a MetaHarness for the VEIL privacy shield + +| Field | Value | +|-------|-------| +| **Status** | Proposed — implemented (P1) | +| **Date** | 2026-08-09 | +| **Parent** | ADR-288 (`wifi-densepose-privshield` / VEIL, the crate this harness assists development on) | +| **Relates to** | ADR-286 (`wifi-densepose-sar-harness`, the per-crate harness scaffold this one mirrors), ADR-285 (`harness/homecore/`, the WASM-first `@metaharness/kernel` pattern), ADR-182 (`harness/ruview/`, the first minted harness), ADR-282 (L0–L5 evidence ladder) | +| **Location** | `harness/wifi-densepose-privshield/` | + +## 0. PROOF discipline + +Every claim below about what is "real" versus "illustrative"/"SYNTHETIC" is +checked by a test in this harness's own suite (router + flywheel + install-smoke ++ guidance). The dependency-free `guidance` surface is covered by +`__tests__/guidance.test.ts`, which runs even before `npm install`. Nothing here +asserts a MEASURED defense result — the harness surfaces the VEIL crate's +SYNTHETIC/L0 numbers with that label intact. + +## 1. Context + +`wifi-densepose-privshield` (ADR-288) is the VEIL privacy shield — a new, +narrowly-scoped crate. Following the pattern ADR-286 set for +`wifi-densepose-sar`, it gets a dedicated per-crate MetaHarness rather than a +bespoke setup: the `vertical:coding` scaffold (architect/implementer/reviewer/ +test-writer, `doctor`) with `@metaharness/router`, `@metaharness/flywheel`, and +Darwin Mode wired in, plus a VEIL-specific, dependency-free `guidance` surface. + +## 2. Decision + +Land the harness at `harness/wifi-densepose-privshield/`, mirroring +`wifi-densepose-sar-harness`, with two deliberate improvements: + +1. **Dynamic dependency imports.** `bin/cli.js` imports the `@metaharness/*` + packages *inside* the commands that need them, not at module top. So + `guidance`, `--help`, and the guidance test run with **zero dependencies + installed** — useful for offline/air-gapped review and for this repo's CI + before `npm install`. Only `init`/`doctor`/`route`/`flywheel` touch the + kernel/host/router/flywheel packages. +2. **A VEIL `guidance` command.** A self-contained, source-cited, read-only + capability map (topics: `overview`, `threat`, `countermeasure`, + `compliance`, `optimization`, `experiment`), each entry carrying a summary, + repo-relative source citations, focused validation commands, and explicit + limitations — the `ruview_guidance` shape, specialized to VEIL. It labels all + defense evidence `SYNTHETIC/L0` and states plainly that guidance is + navigation, not authority. + +The standard three self-improvement/cost pieces are wired as real npm +dependencies (not stubs): + +- **`@metaharness/darwin`** (devDependency) — `npm run evolve` / `evolve:dry` + mutates the harness's own operating config, keeping only measurable gains. +- **`@metaharness/router`** — `src/router.ts` wires a real cost-optimal `Router` + (`qualityBar: 0.8`, k=1) over two model tiers, with four VEIL-shaped task axes + (threatModeling / complianceReview / optimizerTuning / docWriting). Labelled + examples are illustrative seed data (honesty note in-file). +- **`@metaharness/flywheel`** — `src/flywheel.ts` wires the real + `runFlywheelGenerations` promotion loop (propose → evaluate → gate → promote, + Ed25519-signed, independently replayable) with a SYNTHETIC proposer/evaluator + (`dataSource: 'SYNTHETIC'`, no model call), over VEIL policy levers + (`complianceReview`, `threatTriage`). + +## 3. What this explicitly is NOT + +- **Not a VEIL runtime.** The harness does not run a radio, emit RF, or jam. It + assists *development* on the crate; it cannot execute the shield on hardware. +- **Not evolving the crate.** Darwin/Flywheel mutate the harness's own policy + (agent prompts, review-checklist depth), not VEIL's Rust code. The crate's + actual hyper-optimization (ADR-288 §opt) was done directly, in the crate. +- **Not a live routing/promotion system.** The router's examples are seed data; + the flywheel's proposer/evaluator are deterministic stand-ins — both honestly + labelled in-source and in `CLAUDE.md`. +- **Not a replacement for the crate's gates.** The authoritative check for a + VEIL change remains `cargo test -p wifi-densepose-privshield`. +- **Not a re-labeller.** The harness must never present VEIL's SYNTHETIC results + as MEASURED, and never scaffold interference-based ("jamming") defenses — both + are hard rules in the harness `CLAUDE.md`. + +## 4. Consequences + +- The harness ships `guidance`/`doctor`/`init`/`route`/`flywheel`; `guidance` + and `--help` work offline (validated here via `node bin/cli.js`), the rest + after `npm install` + `npm run build` (CI). +- `.harness/manifest.json` + `manifest.sha256` are generated with real per-file + hashes at creation (unlike ADR-286's scaffold, whose manifest was historical). +- Scoped to its own name: its plugin, permissions, and (future) MCP surface only + read/assist on `wifi-densepose-privshield`. No risk to other harnesses/crates. + +## 5. Validation + +```bash +cd harness/wifi-densepose-privshield +node bin/cli.js guidance --topic overview # dependency-free +npm ci && npm run build && npm test # full suite (CI; needs registry access) +``` diff --git a/api-docs/adr/ADR-290-veil-e2e-hardware-implementation-program.md b/api-docs/adr/ADR-290-veil-e2e-hardware-implementation-program.md new file mode 100644 index 00000000..6ea20a9e --- /dev/null +++ b/api-docs/adr/ADR-290-veil-e2e-hardware-implementation-program.md @@ -0,0 +1,94 @@ +# ADR-290: VEIL end-to-end hardware implementation program (multi-provider firmware) + +| Field | Value | +|-------|-------| +| **Status** | Proposed — P4 scaffolding (build-only); portable core validated on host | +| **Date** | 2026-08-09 | +| **Parent** | ADR-288 (VEIL shield), ADR-289 (harness), ADR-282 (L0–L5 evidence ladder) | +| **Location** | `firmware/privshield/` | +| **Relates to** | `firmware/esp32-csi-node/` (the CSI sensor/attacker node), ADR-280 (governed actuation), ADR-141 (attestation) | + +## 0. PROOF discipline + +The **only** artifact validated here is the portable C core +(`firmware/privshield/core/`): a host test (`make test`) checks energy +conservation, reversibility, wrong-key failure, and — pinned — that its +SplitMix64 key schedule is **byte-identical to the Rust crate's** PRNG. That is +`build`/host-level evidence, not silicon. Every per-provider adapter is a +**build-only scaffold** with `TODO(hw)` markers: `SYNTHETIC / L0`, no captured +log, no `MEASURED` claim. Nothing in this ADR asserts VEIL works on real +hardware; it asserts a *plan and a shared core* to get there (P5). + +## 1. Context + +ADR-288 shipped VEIL as a deterministic, no-radio Rust model, and the 2025–2026 +SOTA sweep (ADR-288 §sota) confirmed the mechanism's family is real and +standard-permitted. The open question left was **"does this run on real WiFi +hardware, and on which?"** — including the user asks: *can OpenWRT / open WiFi +software implement it, and can ESP32 help scramble signals?* Answering requires +committing to the platform reality rather than assuming a uniform "firmware" +target. + +## 2. Decision + +Stand up `firmware/privshield/` as a **multi-provider E2E program** around one +shared, validated core: + +1. **A portable C shield core** (`core/veil_shield.{h,c}`) — the keyed + Givens-rotation obfuscation, `no_std`-friendly C99 (no malloc/libc I/O), with + a SplitMix64 key schedule matching the Rust crate so on-air behavior is + identical everywhere and every adapter links the *same* math. Host-tested. +2. **Per-provider adapters**, each built and graded by a hardware research + agent, honest about what its stack can actually touch: + - **`openwifi/`** (open PHY/MAC on SDR/FPGA) — the highest-capability path and + the one that can host the **keyed-reversible** design end-to-end + (protector + AP-side compensation). Carries the **P5 measurement protocol** + (`MEASUREMENT.md`) that yields the first `MEASURED` result with a witness. + - **`openwrt/`** (Linux `mac80211`, mt76/ath9k…) — the commodity path. + Sounding-cadence randomization, MU-group and stream-mapping control are + feasible from the driver/hostapd; the per-packet unitary on the LTF spatial + mapping is firmware-deep on most parts. Partial. + - **`nexmon/`** (Broadcom/Cypress C firmware patches) — the commodity + C-firmware route; the read path is proven (Wi-BFI/nexmon_csi), the transmit + report-shaping path is research-grade/partial. + - **`esp32/`** (ESP-IDF) — **not** a feedback protector (the beamforming path + is a closed blob): ESP32 shapes CSI *read*, not transmitted feedback. Its + legitimate roles are a **sensing detector** (trigger the AP-side shield) and + an **RIS controller** (drive an external reconfigurable surface to scramble + the sensing direction — the honest way ESP32 "helps scramble", via an + external surface, not its own PHY). +3. **Compliance stance carried into hardware:** every control shapes the node's + own standards-conformant emission and preserves energy; the ESP32 + decoy/cover-traffic idea is documented as *legally sensitive / not + recommended* precisely because it edges toward the interference line. + +Per-provider feasibility grades live in each subdir README and the top-level +feasibility matrix; they are the answer to the "which hardware" question. + +## 3. What this explicitly is NOT + +- **Not validated firmware.** No adapter has run on silicon; there is no witness. + The scaffolds compile-*shaped*, not compile-*guaranteed* on their toolchains + (which are absent in this environment). +- **Not a claim that ESP32 can shield beamforming feedback** — it cannot; it is a + detector/RIS-controller only. +- **Not jamming, on any platform.** Compliant waveform shaping only. +- **Not a MEASURED result.** That is P5, gated on a captured log. + +## 4. Consequences + +- One validated core, four honest provider scaffolds, and a concrete P5 + measurement plan — a real path from model to silicon, with the effort/blocker + reality made explicit per platform. +- The shared core keeps every future hardware result consistent with the crate + and with each other. +- Scope stays inside `firmware/privshield/`; no other crate/firmware is touched + (the existing `esp32-csi-node` remains the sensor/attacker node). + +## 5. Validation + +```bash +cd firmware/privshield/core && make test # host: energy/reversibility/PRNG parity +# per-provider builds require their toolchains (ESP-IDF, OpenWRT SDK, Nexmon, +# Vivado) and real hardware — see each subdir's BUILD/INTEGRATION notes. +``` diff --git a/api-docs/adr/README.md b/api-docs/adr/README.md index 11ca228c..284888ee 100644 --- a/api-docs/adr/README.md +++ b/api-docs/adr/README.md @@ -145,6 +145,9 @@ Statuses: **Proposed** (under discussion), **Accepted** (approved and/or impleme | [ADR-287](ADR-287-coherent-wideband-rf-tomography-crate.md) | `wifi-densepose-sar` — coherent wideband RF tomography research crate | Accepted (implemented, published) | | [ADR-285](ADR-285-homecore-wasm-first-metaharness.md) | WASM-first Homecore developer metaharness via `npx homecore` | Accepted (implemented and validated) | | [ADR-286](ADR-286-wifi-densepose-sar-harness-via-metaharness.md) | `wifi-densepose-sar-harness` — MetaHarness with darwin/router/flywheel | Accepted (implemented, published) | +| [ADR-288](ADR-288-veil-privacy-shield-compliant-waveform.md) | VEIL — compliant-waveform privacy shield against unauthorized WiFi sensing (`wifi-densepose-privshield`) | Proposed (implemented, P1 reference) | +| [ADR-289](ADR-289-wifi-densepose-privshield-harness-via-metaharness.md) | `wifi-densepose-privshield-harness` — npm MetaHarness for the VEIL crate (guidance/router/flywheel) | Proposed (implemented, P1) | +| [ADR-290](ADR-290-veil-e2e-hardware-implementation-program.md) | VEIL end-to-end hardware implementation program — portable C core + multi-provider firmware scaffolds (openwifi/openwrt/nexmon/esp32) | Proposed (P4 scaffolding; C core host-validated) | --- diff --git a/api-docs/research/privacy-shield/01-sota-survey.md b/api-docs/research/privacy-shield/01-sota-survey.md new file mode 100644 index 00000000..79a91063 --- /dev/null +++ b/api-docs/research/privacy-shield/01-sota-survey.md @@ -0,0 +1,141 @@ +# 01 — State of the Art + +Scope: what a passive or active adversary can extract about *who* is in a space +and *what they are doing* from WiFi, the standard that broadens that surface, and +the countermeasures that try to prevent it. Claims are tagged **MEASURED** (from +a primary source, with metric), **CLAIMED** (asserted without an independent +measurement), or analytical inference (flagged). + +--- + +## 1. The attack surface: beamforming feedback (BFI) + +Since WiFi 5 (802.11ac), a client (beamformee) measures the downlink channel, +compresses the steering matrix **V** into **Givens-rotation angles φ/ψ**, and +transmits them **in cleartext** so the AP can steer beams. Anyone in monitor +mode can capture these frames for *every* client simultaneously — no network +access, and the target need carry no device. Quantization is coarse (802.11ac +angle steps of π/4…π/32 rad) yet retains rich motion and body information. + +| Work | Venue / year | Result | Label | +|---|---|---|---| +| **BFId** — identity inference from BFI | ACM CCS 2025 (KIT/KASTEL) | Re-identifies individuals from BFI alone; novel 197-person dataset. Press reports **99.5%** in a controlled study (ACM full text was not openable to confirm class count/split) | MEASURED (paper); 99.5% is CLAIMED via press | +| **LeakyBeam** — occupancy through walls | NDSS 2025 | Occupancy detection **TPR 82.7% / TNR 96.7%** at **20 m, through walls**, from plaintext BFI. Proposes a BFI-obfuscation defense | MEASURED (attack); defense overhead CLAIMED | +| **BFIAttack** — CSI reconstruction from BFI | arXiv 2026 (USF) | Reconstructs CSI from BFI, then defeats CSI defenses. ASR: device auth 95.5% / user auth 92.6% / key-gen 94.2% (single-antenna), 1.5–6 m | MEASURED | +| **BeamSense** — activity recognition from BFI | Computer Networks vol. 258, 2025 (Northeastern) | Human activity recognition **up to 99.28%** on commodity 802.11ac, no firmware mod, ~10% better than CSI | MEASURED | +| **Wi-BFI** — capture tooling | arXiv 2309.04408, 2023 | Pip-installable extraction of 802.11 BFI from commercial devices | tooling | + +**Takeaway for the defender.** BFI is the highest-leverage surface: unencrypted, +management-plane, device-free, capturable en masse with off-the-shelf tools. It +is also a *stepping stone* — BFIAttack shows BFI can reconstruct the CSI that all +older attacks assume. + +--- + +## 2. The older adjacent surface: CSI identity/gait/activity + +CSI requires special extraction (Intel 5300 / Atheros / ESP32) but is the +foundation the BFI attacks build on. Person-ID exploits **gait** as a biometric. +Representative MEASURED results (commodity WiFi, CSI amplitude): + +| System | Accuracy | N (candidates) | Note | +|---|---|---|---| +| WiWho (IPSN 2016) | 92%→80% | 2→6 | 2–3 m straight walk | +| WiFi-ID (2016) | 93%→77% | 2→6 | wavelet features | +| WiPIN (2018) | 92–100% | ≤30 | operation-free | +| Deep-WiID (2019) | 92.5–99.7% | 6→15 | GRU | +| WiNet / LWID (2020) | 98.5% / 98.8% | 40 / 50 | CNN | + +**Pattern the defender must exploit and not overstate:** accuracy is high in +small closed sets but *degrades as N grows and conditions become realistic* +(cross-day, cross-location, cross-walking-style). Chance is **1/N**; a 99% result +on N=5 is far weaker evidence than 99% on N=197. Open-world scale is largely +unproven (see *SoK: Security Evaluation of Wi-Fi CSI Biometrics*, 2025). + +--- + +## 3. The standard: IEEE 802.11bf-2025 + +IEEE Std **802.11bf-2025** (Amendment 4: *Enhancements for WLAN Sensing*) was +published **26 September 2025**. It standardizes WLAN sensing in 1–7.125 GHz and +above 45 GHz, defining sensing capability signaling, measurement/sounding +setup, feedback types, and both passive (ambient-traffic) and active +(dedicated null-packet) sensing modes. + +- **Attack-surface implication (analytical).** 802.11bf turns CSI/measurement + acquisition from proprietary hacks into open, vendor-agnostic, machine-readable + MAC signaling across heterogeneous devices — institutionalizing exactly the + measurements the BFI attacks abuse. The standard frames sensing as a feature, + not a threat. +- **The privacy gap (MEASURED from standards minutes).** A 2023 proposal for a + BFI "secure transmission mechanism" (IEEE 802.11-23/0782) was **withdrawn**; + "the group did not align on the characterization of [the] privacy problem." + The standard shipped without privacy protections, and its own analysis admits + passive eavesdroppers can extract location, respiration, heart rate, and + identity. + +--- + +## 4. Countermeasures (the defense literature) + +All operate on the defender's *own* transmissions; none are jamming. + +| Countermeasure | Venue / year | Mechanism | Effect | Label | +|---|---|---|---|---| +| **IRShield** | IEEE S&P 2022 | IRS/reconfigurable surface randomizes reflected paths | Attacker motion-detection **≤5%** | MEASURED | +| **PhyCloak** | USENIX NSDI 2016 | Full-duplex obfuscator injects Doppler/phase distortion into sensing only | **88.69%** gesture-spoof; throughput can rise (whitelist legit sensors) | MEASURED (spoof); throughput CLAIMED | +| **DP-Givens dithering** | IEEE DySPAN 2026 | Differentially-private stochastic quantization of BFI φ/ψ angles | Attacker speed-class error 19%→~73% (chance); **fine (3-bit) resolution ≈ non-private baseline throughput** | MEASURED | +| **MIMOCrypt / WiShield** | 2023 / IEEE JSAC 2024 | Secret precoding / MIMO CSI manipulation so only the intended RX decodes | Anti-tracking | CLAIMED/formal | +| **CSI Fuzzing / DP feature release** | IEEE 2024–25 | Randomized CSI features with DP budget | Formal DP guarantee | CLAIMED/formal | +| **ScatterShield** | ACM IMWUT 2025 | Backscatter tags inject controlled clutter | Defeats unauthorized sensing | MEASURED | +| **Adversarial packet perturbation** | ACM MobiCom 2024 | Small in-spec packet perturbations degrade attacker model | Symmetric defense | MEASURED | + +**The fundamental tradeoff (MEASURED, DySPAN 2026).** Perturbing precoding/ +feedback that an attacker exploits also degrades legitimate beamforming gain — +*but the cost collapses at fine feedback resolution*: + +| Randomization | Attacker error | Beamforming gain retained | +|---|---|---| +| none | 19% | 100% | +| moderate (p=0.3) | >50% | median >90% | +| maximum (p≥0.9) | ~73% (≈chance) | median ~58% | + +At **high (3-bit) feedback resolution, privacy was "nearly indistinguishable +from the non-private baseline"** in link performance. This is the empirical basis +for VEIL's design choice (compliant fine-resolution feedback shaping — see +[03-countermeasure-design.md](03-countermeasure-design.md)). + +--- + +## 5. Where VEIL sits + +The literature has two families: **external** obfuscation (IRShield/ScatterShield +— extra hardware, perturbs the channel) and **transmitter-side** feedback/precoder +shaping (DP-Givens, MIMOCrypt — no extra hardware, perturbs your own report). +VEIL is in the second family and adds the missing property the others do not all +combine: a transform that is simultaneously **energy-preserving** (provably +compliant), **key-reversible** (throughput-preserving for the legitimate link), +and **session-fresh** (defeats cross-session re-identification), unified around +the Givens-rotation primitive the report already uses. + +--- + +## Sources + +- BFId — ACM CCS 2025: https://dl.acm.org/doi/10.1145/3719027.3765062 · KIT record: https://publikationen.bibliothek.kit.edu/1000185756 +- LeakyBeam — NDSS 2025: https://www.ndss-symposium.org/ndss-paper/lend-me-your-beam-privacy-implications-of-plaintext-beamforming-feedback-in-wifi/ +- BFIAttack — arXiv 2604.04179: https://arxiv.org/html/2604.04179v1 +- BeamSense — Computer Networks 2025: https://dl.acm.org/doi/10.1016/j.comnet.2024.111020 · arXiv 2303.09687: https://arxiv.org/pdf/2303.09687 +- Wi-BFI — arXiv 2309.04408: https://arxiv.org/pdf/2309.04408 +- SoK: Security Evaluation of Wi-Fi CSI Biometrics — arXiv 2511.11381: https://arxiv.org/pdf/2511.11381 +- WiWho (IPSN 2016): https://dl.acm.org/doi/10.5555/2959355.2959359 · WiPIN — arXiv 1810.04106: https://arxiv.org/pdf/1810.04106 +- Survey on Wi-Fi Sensing for Human Identity — MDPI Electronics 2023: https://www.mdpi.com/2079-9292/12/23/4858 +- IEEE Std 802.11bf-2025: https://standards.ieee.org/ieee/802.11bf/11574/ · Overview — IEEE COMST 2024: https://ieeexplore.ieee.org/document/10547188/ · NIST: https://www.nist.gov/publications/ieee-80211bf-enabling-widespread-adoption-wi-fi-sensing +- 802.11bf privacy proposal withdrawal (802.11-23/0782), summarized: https://pascalpiron.substack.com/p/wifi-sensing-and-the-privacy-fix +- IRShield — IEEE S&P 2022 / arXiv 2112.01967: https://arxiv.org/abs/2112.01967 · https://ieeexplore.ieee.org/document/9833676/ +- PhyCloak — USENIX NSDI 2016: https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/qiao +- Protecting Human Activity Signatures in Compressed 802.11 CSI Feedback — DySPAN 2026 / arXiv 2512.18529: https://arxiv.org/abs/2512.18529 +- MIMOCrypt — arXiv 2309.00250: https://arxiv.org/pdf/2309.00250 · WiShield — IEEE JSAC 2024: https://dl.acm.org/doi/abs/10.1109/JSAC.2024.3414597 +- ScatterShield — ACM IMWUT 2025: https://dl.acm.org/doi/abs/10.1145/3770653 +- Practical Adversarial Attack on WiFi Sensing — ACM MobiCom 2024: https://dx.doi.org/10.1145/3636534.3649367 +- Privacy-Preserving Wi-Fi Data Generation via DP — INFOCOM 2025: https://www.eng.auburn.edu/~szm0001/papers/INFOCOM25.pdf diff --git a/api-docs/research/privacy-shield/02-threat-model.md b/api-docs/research/privacy-shield/02-threat-model.md new file mode 100644 index 00000000..1729afb9 --- /dev/null +++ b/api-docs/research/privacy-shield/02-threat-model.md @@ -0,0 +1,94 @@ +# 02 — Threat Model + +VEIL protects a physical space (a room, a ward, a boardroom, a SCIF) from +*unauthorized* WiFi-based inference of **who is present** and **what they are +doing**, without denying the space its own working WiFi. This file states the +adversary classes, exactly what VEIL defends, and — just as importantly — what +it does **not**. + +--- + +## 1. Assets + +| Asset | Why it matters | +|---|---| +| **Identity linkage** | Re-identifying a specific person across time/sessions from their RF signature (BFId-class attack) | +| **Occupancy / presence** | Whether the space is occupied, and by how many (LeakyBeam-class, through-wall) | +| **Activity / motion** | Gait, gestures, keystrokes, respiration inferred from channel dynamics (BeamSense-class) | +| **Communication utility** | The legitimate WiFi link must keep working (≥95% throughput bar) | + +--- + +## 2. Adversary classes + +| Class | Position | Capability | In VEIL scope? | +|---|---|---|---| +| **A1 — external passive sniffer** | Outside the trust boundary (adjacent room, van, hallway), monitor mode | Captures plaintext BFI/CSI for every station; runs BFId/LeakyBeam/BeamSense offline | **Primary target — yes** | +| **A2 — external active sensor** | Nearby, transmits its own probing/sounding to solicit measurable responses | Elicits sensing responses; 802.11bf "active" mode | **Partial** — cadence randomization + non-response policy help; full defense needs MAC-layer policy | +| **A3 — associated but curious AP** | Inside the link; the party VEIL shares keys with | Sees the un-rotated report by construction | **Out of scope** — this is BFLD's detection/privacy-class problem (ADR-118/141) | +| **A4 — supply-chain / firmware** | Compromised radio firmware | Can bypass any transmit-side control | Out of scope (integrity problem, not a waveform problem) | +| **A5 — physical / RF-denial** | Wants to *block* WiFi | — | Explicitly rejected: VEIL never jams | + +VEIL's design centers on **A1**, the attacker the literature demonstrates and +the one no shipping product addresses. + +--- + +## 3. What VEIL guarantees (and the evidence class) + +1. **Cross-session identity unlinkability against A1.** Because the fine-subspace + signature is rotated by a fresh secret orthogonal transform each session, an + A1 attacker cannot average captures back to a stable per-person template. + *Evidence: SYNTHETIC — re-ID collapses from 100% to ~chance in the reference + experiment (`cargo test`); real-silicon witness is future work.* +2. **Communication preservation.** The transform is key-reversible by the + legitimate receiver, and acts only on the identity-bearing fine subspace, so + link throughput stays ≥95%. *Evidence: SYNTHETIC model + MEASURED external + corroboration (DySPAN 2026: fine-resolution feedback shaping is near-free).* +3. **Compliance.** The transform is orthogonal ⇒ energy-preserving ⇒ adds no + interfering emission ⇒ not jamming. *Evidence: machine-checked energy ratio = + 1.000000 in the `compliance` module; statutory analysis in + [04-compliance-and-regulatory.md](04-compliance-and-regulatory.md).* + +--- + +## 4. What VEIL does NOT do (non-goals, stated to prevent over-claiming) + +- **It does not hide identity from the associated AP (A3).** That party holds the + session key. Protecting against a malicious AP requires detection and policy + (BFLD), not waveform shaping. +- **It is not RF denial or jamming.** It never degrades another station's link. +- **It does not, by itself, defeat within-session motion detection.** A single + session's rotation is fixed, so coarse presence/motion may still be inferable + within one capture window; sounding-cadence randomization mitigates but does + not eliminate this. Identity *re-ID* (the brief's metric) is the guaranteed + target; motion obfuscation is partial and tracked as future work. +- **It is not a camera-grade or medical-grade claim in any direction.** +- **It is not validated on hardware yet.** All quantitative defense results are + SYNTHETIC until a captured boot/runtime log exists (CLAUDE.md hardware rule). + +--- + +## 5. Trust boundary + +``` + ┌────────────────────── protected space ──────────────────────┐ + │ │ + │ [person] [person] legitimate STA ⇄ AP (VEIL) │ + │ │ │ │ shares session key │ + │ └──── RF ──────┘ │ rotates fine subspace│ + │ reflections ▼ of its own BFI │ + │ compliant, key-reversible, │ + │ energy-preserving emission │ + └───────────────────────────────────────┬──────────────────────┘ + │ plaintext BFI on air + ▼ + A1 external passive sniffer (monitor mode) + sees a freshly-rotated signature each session + → cannot build a stable per-person template + → re-identification → chance +``` + +The key never crosses the boundary to A1. The AP inside the boundary is trusted +for key-sharing (A3 out of scope). No emission crosses the boundary with intent +or effect of interfering with another station (A5 rejected). diff --git a/api-docs/research/privacy-shield/03-countermeasure-design.md b/api-docs/research/privacy-shield/03-countermeasure-design.md new file mode 100644 index 00000000..8c3cf540 --- /dev/null +++ b/api-docs/research/privacy-shield/03-countermeasure-design.md @@ -0,0 +1,136 @@ +# 03 — Countermeasure Design + +How VEIL prevents unauthorized sensing with compliant waveform controls, and how +the design maps to [`v2/crates/wifi-densepose-privshield`](../../../v2/crates/wifi-densepose-privshield). + +--- + +## 1. The separable-subspace principle + +A compressed beamforming report is not homogeneous. Two blocks carry different +information: + +- **Dominant beam direction (comm block).** The coarse steering the AP uses to + aim data at the client. It varies with position and traffic and carries **no** + stable identity. **Throughput rides here.** +- **Fine cross-subcarrier phase structure (fine block).** The high-order + multipath detail. It is *stable per person* across sessions and is what + re-identification exploits (BFId). **Identity leaks here.** Communication + barely uses it. + +The whole design rests on this: **identity leakage and data throughput live in +(mostly) separable subspaces.** A transform confined to the fine block can wreck +re-identification while sparing the beam the link depends on. This is consistent +with the DySPAN-2026 MEASURED result that shaping fine-resolution feedback is +nearly free in throughput. + +--- + +## 2. The four compliant waveform controls + +VEIL alters "channel sounding, phase, or beam schedules" — exactly the levers the +brief names — all within the 802.11 waveform envelope: + +| Control | What it varies | Purpose | +|---|---|---| +| **Keyed precoder rotation** (primary) | A fresh secret orthogonal transform of the *fine* subspace each session, composed from extra Givens rotations | Destroys cross-session identity linkage; energy-preserving; key-reversible | +| **Feedback quantization / dither** | Sub-step noise on reported φ/ψ angles | Adds report-level uncertainty; tunes the privacy–throughput point via `feedback_bits` | +| **Sounding-cadence randomization** | Jitter on NDP sounding intervals | Under-samples motion for an eavesdropper; charged as the throughput overhead | +| **MU-group / stream-mapping shuffle** | Which STAs are grouped, stream-to-antenna mapping | Rotates the spatial signature over time | + +All four modify the node's **own** standards-conformant frames. None adds energy +on top of another station (see [04](04-compliance-and-regulatory.md)). + +--- + +## 3. Why the keyed Givens rotation is the right primitive + +The compressed beamforming report is *already* a product of Givens rotations +(the φ/ψ angles). VEIL composes **additional keyed Givens rotations** over the +fine block. This choice gives three properties at once: + +1. **Orthogonal ⇒ energy-preserving.** A Givens rotation preserves the vector's + L2 norm exactly. Composing many still preserves it. So the emission carries + the same power it always would — **no added energy, no interference, not + jamming.** The `compliance` module checks this: energy ratio = 1.000000. +2. **Keyed & reversible ⇒ throughput-preserving.** The legitimate AP/STA shares + the per-session key, derives the identical rotation schedule, and applies the + inverse (negated angles, reversed order) to recover the true precoder. It pays + only the tiny residual from quantizing the extra angles at `feedback_bits` + resolution — negligible across the 802.11 5–9-bit range — plus the sounding + overhead. (The throughput-optimal resolution is derived in + [08-optimization.md](08-optimization.md).) +3. **Fresh per session ⇒ unlinkable.** A different rotation each session means an + A1 sniffer sees `R_e · signature` for a new random `R_e` every time. Averaging + over sessions (the natural enrollment attack) drives + `mean_e(R_e · signature) → 0` for *every* identity, so all templates collapse + toward the origin and become indistinguishable — re-identification → chance. + This is the marginalized-mutual-information argument: over unknown rotations, + the signature carries no stable discriminative information. + +This is the shared-secret precoding idea (cf. MIMOCrypt) specialized to the +identity-bearing subspace and unified around the report's native primitive. + +--- + +## 4. Detect-then-act + +Per the brief ("detect sensing activity and alter…"), VEIL need not perturb +continuously. The `SensingDetector` exposes the decision rule: when the observed +rate of sensing/NDP solicitations crosses a threshold, the control plane +(ADR-280) engages the shield. Continuous operation is also valid; gating just +saves the (already small) overhead when no sensing is present. + +--- + +## 5. Module map + +| Concept above | Crate module | Key items | +|---|---|---| +| Deterministic, WASM-safe randomness + keys | `prng` | `Rng` (SplitMix64), `fnv1a_64`, `derive_key` | +| Givens algebra, energy conservation | `linalg` | `apply_givens`, `norm`, `dist_sq` | +| SYNTHETIC two-subspace BFI model | `identity` | `SceneConfig`, `Channel`, `BfiSample` (`comm()`/`fine()`) | +| The four controls (shield) | `protector` | `ShieldConfig`, `Protector::protect`/`recover`, `SensingDetector` | +| Passive re-ID adversary | `attacker` | `NearestCentroidAttacker`, `Metric` | +| Privacy–throughput tradeoff | `throughput` | `LinkModel::throughput_ratio`, `beamforming_residual`, `feedback_airtime` | +| "Not jamming" audit | `compliance` | `ComplianceReport::audit`/`is_compliant` | +| Attacker-vs-protector head-to-head | `experiment` | `ExperimentConfig`, `run`, `ExperimentReport` | +| Config hyper-optimization | `optimize` | `hyper_optimize`, `min_givens_passes`, `pareto_frontier` | +| Byte-stable deterministic witness | `proof` | `Proof::EXPECTED_WITNESS`, `Proof::witness` | + +--- + +## 6. The privacy–throughput knobs (and which the optimizer turns) + +- **`feedback_bits`:** the only knob with a genuine throughput tradeoff — + residual falls with bits, feedback airtime rises with them, so there is an + interior optimum (3 bits unconstrained; 5 bits within the 802.11-allowed set). + Privacy is unaffected by bits (the rotation is fresh regardless). +- **`givens_passes`:** the privacy/robustness knob. More mixing lowers re-ID at + **no throughput cost** (the keyed rotation is never signaled), so it trades + only compute. The optimizer finds the minimum for robust collapse and ships a + free 2× margin. +- **`sounding_overhead`:** a flat throughput cost from cadence randomization; + trades motion-obfuscation strength against airtime (outside the re-ID metric). + +The `optimize` module turns these knobs deterministically — see +[08-optimization.md](08-optimization.md). It is what replaced the original +hand-picked config. + +The `throughput` module computes the ratio from these, so the tradeoff is +inspectable rather than asserted (`cargo test throughput`). + +--- + +## 7. Honest limitations of the model + +- The two-subspace split is an abstraction; on real hardware comm and identity + information are only *approximately* separable, so the real throughput cost of + fully hiding identity may be higher than the model's ~2%. The DySPAN-2026 + MEASURED curve is the external sanity check that it is *small* at fine + resolution, not zero. +- The nearest-centroid attacker is deliberately simple. The collapse argument is + classifier-independent (it is about the signal, not the model), but a hardware + study must confirm a strong learned attacker also collapses. +- Within-session motion is not addressed by the rotation alone (see threat + model §4). diff --git a/api-docs/research/privacy-shield/04-compliance-and-regulatory.md b/api-docs/research/privacy-shield/04-compliance-and-regulatory.md new file mode 100644 index 00000000..1760c557 --- /dev/null +++ b/api-docs/research/privacy-shield/04-compliance-and-regulatory.md @@ -0,0 +1,90 @@ +# 04 — Compliance and Regulatory Line + +**Non-negotiable:** VEIL uses compliant waveform controls and **never jams.** +This file states the legal basis for that line and why every VEIL control falls +on the compliant side of it. It is engineering analysis, not legal advice; a +deployment in a given jurisdiction needs its own regulatory review. + +--- + +## 1. The statutory line (United States) + +The prohibition is on **interfering with others' transmissions**, not on how you +shape **your own** signal. + +| Authority | What it prohibits | +|---|---| +| **47 U.S.C. §333** | *Willful or malicious interference* with any licensed/authorized radio station or U.S. Government station | +| **47 U.S.C. §302a(b)** | Manufacture, import, marketing, sale, or *operation* of non-compliant devices (jammers cannot be certified — their sole purpose is interference) | +| **47 U.S.C. §301** | Requires a license/authorization to transmit; a jammer can never be authorized | +| **47 U.S.C. §501 / §503** | Criminal penalties and forfeitures; FCC cites fines up to $112,500 per violation, **no exemptions** for business/residence/vehicle | + +The distinguishing element of jamming is **intent to interfere plus effect on a +third party's link.** A device that shapes its own standards-conformant emission +— staying within transmit-power and spectral-mask limits, still type-certifiable +— is not a jammer. + +--- + +## 2. Why each VEIL control is compliant + +| Control | Compliance argument | +|---|---| +| **Keyed precoder rotation** | Orthogonal ⇒ preserves the report's energy exactly ⇒ **adds no power on top of anyone's signal.** It is still a valid precoder within the 802.11 feedback format. Machine-checked: energy ratio = 1.000000 (`compliance` module) | +| **Feedback quantization / dither** | Reports angles the standard already allows, at the standard's resolution; sub-step dither stays within the quantization envelope. No emission change beyond the node's own frame | +| **Sounding-cadence randomization** | Chooses *when* the node sends its own NDP soundings, within permitted timing. Sending fewer/jittered soundings never interferes with another station | +| **MU-group / stream-mapping shuffle** | Rearranges the node's own spatial mapping; a normal in-spec transmit choice | + +None of the four transmits *to prevent* another station from communicating; none +adds out-of-mask energy; each passes normal type certification. Contrast a +jammer, whose defining purpose is to emit energy that denies others service. + +--- + +## 3. The energy-conservation proof as a compliance artifact + +VEIL turns "not jamming" from a promise into a **checked property.** The +`compliance::ComplianceReport` audits each protection step: + +``` +input_energy = ‖report_before‖² +output_energy = ‖report_after‖² +energy_ratio = output_energy / input_energy # ≈ 1.0 for a rotation +energy_conserving = |energy_ratio − 1| ≤ 1e-2 +adds_interfering_energy = false # by construction +is_compliant = energy_conserving ∧ ¬adds_interfering_energy +``` + +A regulator, an auditor, or the runtime attestation layer (ADR-141) can read the +report and verify the shield is a waveform-shaping control, not an interference +source. On the reference experiment the measured ratio is **1.000000**. + +--- + +## 4. Jurisdictional notes + +- **EU (GDPR framing).** Covert WiFi body-sensing of vital signs is sensitive + health data and "almost certainly illegal under GDPR," but effectively + unenforceable (receivers are undetectable) — which is precisely why a + *technical* control is needed. VEIL as a transmit-side control does not itself + raise GDPR issues; it reduces the personal data an attacker can derive. +- **RF-emission rules are jurisdiction-specific.** The energy-preserving property + is the portable core of the compliance argument, but power/mask/timing limits + differ by region and band; a deployment must confirm local rules. +- **Deliberate transmit-nulling toward a *located* sniffer** (steering a spatial + null at a known passive receiver) is still the node's own emission and adds no + interference, but is more aggressive and should get explicit regulatory review + before field use. It is not part of the default VEIL profile. + +--- + +## Sources + +- 47 U.S.C. §333: https://www.law.cornell.edu/uscode/text/47/333 +- 47 U.S.C. §302a: https://www.law.cornell.edu/uscode/text/47/302a +- FCC Jammer Enforcement: https://www.fcc.gov/general/jammer-enforcement · https://www.fcc.gov/enforcement/areas/jammers +- FCC Cell/GPS Jamming guidance: https://www.fcc.gov/general/cell-phone-and-gps-jamming +- FCC 14-92 enforcement order: https://docs.fcc.gov/public/attachments/FCC-14-92A1.pdf + +*Caveat: FCC pages were cross-verified against Cornell LII; this is engineering +analysis, not legal advice.* diff --git a/api-docs/research/privacy-shield/05-experiment-protocol.md b/api-docs/research/privacy-shield/05-experiment-protocol.md new file mode 100644 index 00000000..c5a53b67 --- /dev/null +++ b/api-docs/research/privacy-shield/05-experiment-protocol.md @@ -0,0 +1,113 @@ +# 05 — Experiment Protocol: Attacker vs. Protector + +This is the "start today" deliverable from the brief: **make one RuView node the +attacker and one the protector, and measure whether protection drives identity +recognition toward chance while keeping throughput above 95%.** It is realized as +a deterministic, reproducible experiment in +[`v2/crates/wifi-densepose-privshield`](../../../v2/crates/wifi-densepose-privshield). + +Because it runs on **SYNTHETIC** data (no radio is touched), its numbers describe +the model, not real hardware — reproduced by `cargo test`, and to be +re-established on silicon with a captured log before any deployment claim. + +--- + +## 1. Setup + +- **Protector node.** Emits beamforming feedback shaped by the VEIL controls + (keyed per-session fine-subspace rotation + configured feedback resolution and + sounding overhead). Models a legitimate AP/STA protecting a room. +- **Attacker node.** A passive sniffer that enrolls a template per candidate from + captured reports, then classifies fresh captures (nearest-centroid) — the + BFId-class re-identification threat. +- **Scene.** `SceneConfig` default: 64-dim report, 8 comm dims, **16 candidate + identities** (chance = 1/16 = 6.25%), per-identity stable fine-block signature + + per-session environmental nuisance. + +Two runs of the attacker are compared: **shield off** (the attacker sees raw +reports) and **shield on** (every captured report is VEIL-protected). The same +attacker faces both. + +--- + +## 2. Metrics and acceptance bar + +| Metric | Definition | Bar | +|---|---|---| +| **Re-ID accuracy, shield off** | Top-1 identity accuracy on unprotected traffic | Must be well above chance (threat is real) — bar ≥ 0.5 | +| **Re-ID accuracy, shield on** | Top-1 identity accuracy on protected traffic | Must fall into the chance band `1/N · 2 + 0.03` | +| **Throughput ratio** | Protected link capacity ÷ baseline capacity | **≥ 0.95** | +| **Compliance** | Emission energy ratio ≈ 1 and non-interfering | `is_compliant == true` | + +Overall `passed()` requires all four. + +--- + +## 3. Results (SYNTHETIC, hyper-optimized default configuration) + +Reproduce with `cargo test -p wifi-densepose-privshield` (all 35 tests + doctest +pass). The default shield config is the `optimize` module's output — 96 Givens +passes at 5-bit feedback resolution (see +[08-optimization.md](08-optimization.md)). Salient values from the reference run: + +| Metric | Value | +|---|---| +| Candidate identities | 16 | +| Chance level | 6.25% | +| Chance band (acceptance) | ≤ 15.5% | +| **Re-ID accuracy, shield OFF** | **100.0%** | +| **Re-ID accuracy, shield ON** | **4.7%** | +| **Throughput ratio** | **97.60%** | +| Emission energy ratio | 1.000000 | +| Overall verdict | **PASS** | + +Reading the result: the attacker is a *perfect* re-identifier without protection +(the synthetic signatures are cleanly separable), and VEIL drives it *to the +chance floor* (4.7% sits just below the ideal 6.25%, i.e. no better than +guessing) — while the modeled link keeps 97.6% of its throughput and the +emission conserves energy exactly (compliant, not jamming). The same collapse +holds under a Cosine-metric attacker and at N=32, confirming it is a property of +the signal, not the classifier. + +--- + +## 4. Determinism and the witness + +The experiment is byte-reproducible: no OS entropy, no wall-clock, no threads. +`proof::Proof` folds the salient outputs (quantized to avoid last-bit f32 +round-off) into an FNV-1a witness pinned as `EXPECTED_WITNESS`. Any drift in the +PRNG stream, rotation schedule, throughput formula, or scene geometry changes the +witness and fails `witness_matches_pinned`. This is the same +deterministic-proof discipline as `nvsim` and the Python `verify.py`. + +--- + +## 5. Sensitivity and what to vary next + +`ExperimentConfig` exposes the levers for a fuller study: + +- **`scene.identities`** — larger N lowers the chance floor; confirm collapse + holds as candidates grow. +- **`scene.env_sigma` / `beam_amplitude`** — nuisance and comm energy; stress the + separability assumption. +- **`shield.feedback_bits`** — trace the privacy–throughput curve (the + `throughput` tests already show coarse resolution costs more). +- **`shield.givens_passes`** — mixing strength; fewer passes should degrade the + collapse gracefully. +- **Stronger attacker** — swap in a learned classifier to confirm the collapse is + signal-level, not classifier-level (the argument says it must be, but a + hardware study should verify). + +--- + +## 6. Path to a real two-node measurement + +The synthetic experiment is the design proof. The hardware path (per CLAUDE.md, +requires a captured log to claim MEASURED): + +1. Two ESP32-S3/C6 or Nexmon-capable nodes: one runs Wi-BFI capture (attacker), + one runs a VEIL-shaped feedback profile (protector). +2. Enroll and test the same BFId-style classifier on captured BFI, shield off vs. + on; log throughput via iperf across the legitimate link. +3. Success = the same shape as §3 on real captures, with the boot/runtime log as + the witness. Until then, all defense numbers remain SYNTHETIC. diff --git a/api-docs/research/privacy-shield/06-market-and-buyers.md b/api-docs/research/privacy-shield/06-market-and-buyers.md new file mode 100644 index 00000000..97cf1f91 --- /dev/null +++ b/api-docs/research/privacy-shield/06-market-and-buyers.md @@ -0,0 +1,92 @@ +# 06 — Market and Buyers + +Facts are tagged **VERIFIED** (from a cited source), **CLAIMED** (asserted by a +vendor/analyst/press source), or **SPECULATIVE** (our inference). Market figures +are third-party projections, not independent measurements. + +--- + +## 1. Why now + +- **The threat is standardized and commercializing (VERIFIED/CLAIMED).** IEEE + 802.11bf was published Sep 2025; silicon (Infineon AIROC Wi-Fi 7 ACW741x, + Qualcomm Dragonwing) lists 802.11bf sensing in 2026 briefs; Origin AI's + embedded-sensing program targets late-2026 deployment; Plume/Cognitive Systems + WiFi Motion is the largest deployed sensing footprint today. +- **The standards body declined to fix privacy (VERIFIED).** The BFI + "secure transmission mechanism" proposal (802.11-23/0782) was **withdrawn**; + 802.11bf shipped with no privacy protections. This is the strongest demand + signal — the gap is structural and acknowledged. +- **No targeted anti-sensing product ships (VERIFIED by absence).** Every + countermeasure (IRShield, PhyCloak, MIMOCrypt, DP-Givens, ScatterShield) is + research-stage. The claim "no obvious shipping product protects rooms from this + inference" **holds** as of 2026, with one caveat below. + +--- + +## 2. First buyers, ranked by procurement readiness + +| Segment | Driver | Readiness | +|---|---|---| +| **Defence / government** | ICD 705 / DoD EMSEC already mandate RF attenuation in classified spaces; budgets and mandates exist | **Strongest beachhead (VERIFIED)** — but today they buy broadband shielding, not a sensing-specific control | +| **Corporate boardrooms / counter-espionage** | TSCM firms (Bastille, Murray Associates) now include WiFi audits and rogue-AP detection; CSI keystroke/gesture inference makes a boardroom shield a natural extension | **VERIFIED demand, EMERGING WiFi-specific** | +| **Hospitals** | RF-derived behavioral/vital data is HIPAA PHI; exam rooms, psychiatric units where inference is unwanted | **VERIFIED regulatory hook** — but the hook drives privacy-preserving *sensing* more than a *shield* | +| **Hotels** | Documented guest backlash against in-room sensors; privacy as differentiation | **SPECULATIVE** — narrative-led, not procurement-led today | +| **Router / AP manufacturers** | Ship opt-out/obfuscation as a firmware feature anticipating regulation | **SPECULATIVE** — no vendor has announced this | + +--- + +## 3. Competitive landscape + +- **Direct competitors:** none shipping. All targeted anti-sensing is academic. +- **The real substitute (VERIFIED):** broadband RF shielding — SCIF/TEMPEST + window film, paint, panels (Signals Defense SD2500: >40 dB, 30 MHz–6 GHz, ICD + 705 / ASTM F3057-14). It defeats WiFi sensing as a side effect but is **blunt**: + it kills *all* RF and cannot coexist with wanted WiFi. +- **TSCM services (VERIFIED):** detect, don't prevent. + +**VEIL's differentiation** is exactly what the substitute lacks: **selective and +coexisting** — it removes identity/activity leakage while keeping the room's WiFi +working at ≥95% throughput, with a machine-checkable compliance artifact. + +--- + +## 4. Market size (third-party projections, cite with care) + +- **CLAIMED:** ABI Research — North American WiFi-sensing-compatible CPE install + base to **112M by 2030 (51.6% CAGR)**. +- **CLAIMED:** Global WiFi sensing market ~$402M (2024) → ~$2.13B (2033) + (MarketIntelo). + +Implication: a shield must **coexist** with a large installed sensing base, not +assume RF denial — reinforcing the selective-coexistence positioning. + +--- + +## 5. Where VEIL fits RuView's positioning + +VEIL pairs with BFLD to make RuView the *both-sides* RF-perception platform: +BFLD/AETHER do sensing responsibly and detect leakage; VEIL is the customer- +facing **privacy firewall** that protects a room from *others'* sensing. That is a +defensible, standards-anchored, gap-filling story: the standards body left the +door open, the threat is shipping, and no one else sells the selective lock. + +--- + +## Sources + +- IEEE 802.11bf privacy-proposal withdrawal (802.11-23/0782), summarized: https://pascalpiron.substack.com/p/wifi-sensing-and-the-privacy-fix +- NIST 802.11bf: https://www.nist.gov/publications/ieee-80211bf-enabling-widespread-adoption-wi-fi-sensing +- IRShield: https://arxiv.org/abs/2112.01967 · MIMOCrypt: https://arxiv.org/pdf/2309.00250 · ScatterShield: https://dl.acm.org/doi/abs/10.1145/3770653 · WiShield JSAC 2024: https://dl.acm.org/doi/abs/10.1109/JSAC.2024.3414597 +- Signals Defense TEMPEST/SCIF film: https://signalsdefense.com/tempest-and-scif-design/ · https://signalsdefense.com/shielding-films/ +- National Shielding SCIF/ICD-705: https://www.national-shielding.com/pages/scif-icd-705-secure-facility-shielding +- Bastille TSCM: https://bastille.net/centers-of-excellence/tscm/ · IntellSIG TSCM overview: https://www.intellsig.com/2025/07/20/modern-eavesdropping-threats-a-tscm-overview/ +- Origin AI program: https://www.prnewswire.com/news-releases/origin-ai-launches-compatible-with-origin-program-to-meet-industry-demand-for-scalable-wifi-sensing-and-accelerate-integration-across-global-soc-platforms-302650963.html +- MIT Tech Review, WiFi sensing: https://www.technologyreview.com/2024/02/27/1088154/wifi-sensing-tracking-movements/ +- ABI Research 112M forecast: https://www.abiresearch.com/press/north-american-wi-fi-sensing-cpe-installations-to-surge-to-112-million-by-2030-as-the-technologys-maturing-unleashes-new-business-and-service-models +- MarketIntelo WiFi sensing market: https://marketintelo.com/report/wi-fi-sensing-market +- HIPAA/PHI RF-sensing context (PMC): https://pmc.ncbi.nlm.nih.gov/articles/PMC11939480/ + +*Caveat: market figures are analyst/vendor projections; the "no shipping product" +finding reflects absence of evidence in these searches and should be confirmed +with a patent/vendor scan before anchoring a go-to-market claim.* diff --git a/api-docs/research/privacy-shield/07-implementation-and-roadmap.md b/api-docs/research/privacy-shield/07-implementation-and-roadmap.md new file mode 100644 index 00000000..8cfb68e3 --- /dev/null +++ b/api-docs/research/privacy-shield/07-implementation-and-roadmap.md @@ -0,0 +1,117 @@ +# 07 — Implementation and Roadmap + +--- + +## 1. What ships in this bundle + +- **Reference crate** `v2/crates/wifi-densepose-privshield` (VEIL): a + deterministic, dependency-free, WASM-ready pure-compute leaf implementing the + full attacker-vs-protector experiment, the four compliant controls, the + throughput model, the compliance audit, the `optimize` hyper-optimizer, and a + byte-stable proof. 35 tests + doctest pass; builds for + `wasm32-unknown-unknown`; clippy-clean. +- **This research bundle** (`docs/research/privacy-shield/`). +- **[ADR-288](../../adr/ADR-288-veil-privacy-shield-compliant-waveform.md)** — the + formal decision record. +- **npm metaharness** `harness/wifi-densepose-privshield/` + ([ADR-289](../../adr/ADR-289-wifi-densepose-privshield-harness-via-metaharness.md)) + — a per-crate contributor harness (architect/implementer/reviewer/test-writer, + router, flywheel) with a dependency-free `guidance` surface that serves this + bundle's capability map. `npx wifi-densepose-privshield-harness guidance + --topic optimization`. + +The crate is intentionally a **leaf with no internal RuView dependencies** +(mirrors `wifi-densepose-aether`), so it can be reasoned about, fuzzed, and +ported independently, and so it can never accidentally acquire a path to a radio. + +--- + +## 2. Reuse map (how VEIL composes with existing RuView) + +| Existing subsystem | Relationship | +|---|---| +| **BFLD** (ADR-118/120/121, `wifi-densepose-bfld`) | Detection layer. Its `identity_risk_score` is the natural trigger for VEIL's `SensingDetector` — detect leakage, then shield | +| **Privacy control plane** (ADR-141) | VEIL protection steps emit `ComplianceReport`s that fit the runtime-attestation model (which mode, which actions, which fields) | +| **Active sensing / governed actuation** (ADR-280) | VEIL is a defensive `SensingAction`: a governed, privacy-ceiling-bounded emission-shaping action the control plane can schedule | +| **Givens/beamforming primitives** | VEIL reuses the report's native Givens-rotation structure rather than inventing a new transform | +| **Deterministic proof discipline** (`nvsim`, `archive/v1/verify.py`) | VEIL's `proof` module follows the same pinned-witness pattern | + +--- + +## 3. Phased rollout + +| Phase | Deliverable | Evidence class | +|---|---|---| +| **P1 — reference model (this PR)** | Crate + experiment + docs + ADR | SYNTHETIC (cargo test) | +| **P2 — sensitivity study** | Sweep N, noise, resolution, mixing; add a learned attacker to confirm signal-level collapse | SYNTHETIC | +| **P3 — BFLD integration** | Wire `identity_risk` → `SensingDetector` → shield engage; emit attestation | SYNTHETIC + integration tests | +| **P4 — firmware feedback shaping** | Implement keyed fine-subspace rotation + cadence randomization in the **beamforming-feedback / spatial-mapping path** — see §3.1 for the (non-trivial) platform reality | build + hardware | +| **P5 — two-node hardware measurement** | Attacker (Wi-BFI capture) vs. VEIL protector on real silicon; iperf throughput; captured log | **MEASURED** (with witness) | +| **P6 — deployment profiles** | Per-segment profiles (SCIF, boardroom, ward) with regulatory review | operational | + +No defense claim graduates from SYNTHETIC to MEASURED without a captured +boot/runtime log (CLAUDE.md hardware rule). + +### 3.1 Does this need custom WiFi firmware? (yes — and ESP32 is the wrong chip for the protector) + +VEIL shapes the **compressed beamforming report** (the Givens φ/ψ angles) or the +LTF **spatial mapping** as it is transmitted — machinery that lives *below* the +driver, inside the chip's PHY/MAC firmware. It is **not** reachable from user +space, so a real deployment is a firmware/driver change, not an app. + +- **ESP32 — not viable as the protector.** Its WiFi lower layers are a closed + Espressif blob. ESP-IDF exposes CSI *read* (`esp_wifi_set_csi`) — which is why + `firmware/esp32-csi-node/` makes a great **attacker/sensor** node — but it does + **not** let you rewrite how the chip builds/sends beamforming feedback. ESP32 + is the *attacker* in a testbed, not the shield. +- **Realistic protector platforms:** **openwifi** (open 802.11 on SDR/FPGA — + full PHY/MAC control incl. the AP-side compensation; the honest end-to-end + route; Verilog + a C driver); **Nexmon** (C firmware *patches* for + Broadcom/Cypress, e.g. RPi BCM43455 — the commodity path, and the same + framework the BFI *attack* tools already use); open drivers (**ath9k/mt76**) + for partial control; or **vendor firmware** for a production feature. +- **Two firmware variants:** the **keyed-reversible** version (VEIL's ~98% + throughput) needs changes on **both** ends plus key agreement (cf. the + LeakyBeam AP-side `Q_obf` is *client-transparent* — only the AP changes — which + is a deployment advantage worth adopting, §09 backlog item 3); the + **emitter-only DP dither** version needs only the reporting device but pays the + full throughput cost. + +The current crate is deliberately a std-only, no-radio leaf and implements none +of this; P4 is where it meets silicon. + +--- + +## 4. Open problems (tracked honestly) + +1. **Real-hardware separability.** Comm and identity information are only + *approximately* separable on real radios; the true throughput cost of full + identity hiding may exceed the model's ~2%. P2/P5 must bound it. +2. **Within-session motion leakage.** A fixed per-session rotation does not + obfuscate coarse motion within one capture window. Needs stronger cadence + randomization or amplitude shaping; currently a stated non-goal for the re-ID + metric. +3. **Active adversary (A2).** An attacker that transmits its own soundings is + only partially addressed by cadence control; a MAC-layer non-response policy + is needed. +4. **Key management.** The per-session rotation key must be derived from the + negotiated link secret; VEIL's PRNG is explicitly *not* cryptographic and must + not be used for real key material. +5. **Regulatory review per jurisdiction.** The energy-conservation argument is + portable, but power/mask/timing limits and any transmit-nulling profile need + local review before field use. + +--- + +## 5. Validation commands + +```bash +# Reference experiment + all unit/proof/doc tests +cargo test -p wifi-densepose-privshield --no-default-features + +# WASM portability (leaf builds with no radio path) +cargo build -p wifi-densepose-privshield --target wasm32-unknown-unknown + +# Lints +cargo clippy -p wifi-densepose-privshield --all-targets +``` diff --git a/api-docs/research/privacy-shield/08-optimization.md b/api-docs/research/privacy-shield/08-optimization.md new file mode 100644 index 00000000..b38fbbec --- /dev/null +++ b/api-docs/research/privacy-shield/08-optimization.md @@ -0,0 +1,142 @@ +# 08 — Hyper-Optimization + +The reference crate first shipped a **hand-picked** shield config (112 Givens +passes, 7-bit feedback). This file records how the `optimize` module replaces +that guess with a *derived*, robustness-verified optimum, and what it found. All +numbers are **SYNTHETIC / L0**, reproduced by +`cargo test -p wifi-densepose-privshield`. + +--- + +## 1. What is being optimized, and against what + +Two knobs, two objectives, one hard constraint: + +| Knob | Costs | Does it trade against privacy? | +|---|---|---| +| `feedback_bits` (angle resolution) | Throughput: **residual** falls with bits, **feedback airtime** rises with bits | No — the keyed rotation is applied regardless of resolution | +| `givens_passes` (rotation mixing) | Compute only | Yes — more mixing ⇒ lower re-ID | + +**Constraint:** re-ID must collapse into the chance band `1/N · 2 + 0.03` — and +it must do so *robustly*: for **both** attacker metrics (Euclidean and Cosine) +and **both** identity counts (N = 16 and N = 32, the harder, lower-chance case). + +The key structural fact: **rotation mixing is throughput-free.** The per-session +rotation is derived from the shared link secret on both ends (like MIMOCrypt) — +it is never transmitted — so extra Givens passes cost compute, not airtime. That +means privacy margin is essentially free; the only throughput tradeoff lives in +`feedback_bits`. + +--- + +## 2. Throughput is a 1-D problem with an interior optimum + +Because the residual falls with bits while feedback airtime rises, throughput +has a genuine interior optimum in `feedback_bits` (`LinkModel`, default SNR 20 dB, +`feedback_overhead_per_bit = 0.0008`): + +| bits | throughput ratio | +|---|---| +| 1 | 0.9681 | +| 2 | 0.9757 | +| **3** | **0.9769** ← unconstrained optimum | +| 4 | 0.9766 | +| **5** | **0.9760** ← shipped (spec-allowed) | +| 7 | 0.9744 (the old hand-picked value) | +| 9 | 0.9728 | +| 12 | 0.9704 | + +The unconstrained optimum is **3 bits** — which coincides with the DySPAN-2026 +MEASURED finding that ~3-bit feedback is the privacy–utility sweet spot, because +the receiver compensates the keyed rotation and extra bits mostly buy airtime. +802.11 compressed beamforming quantizes ψ/φ to roughly 5–9 bits, so the shipped +shield uses the throughput-best **spec-allowed** value, **5 bits** (0.9760), +rather than the out-of-spec 3-bit optimum. Either way it beats the old 7-bit +choice. + +--- + +## 3. Mixing: the minimum robust budget, and a free margin + +Worst-case shield-on re-ID vs. `givens_passes` (bits = 5; worst over Euclidean +and Cosine): + +| passes | re-ID @ N=16 | re-ID @ N=32 | robust collapse? | +|---|---|---|---| +| 16 | 0.75 | 0.62 | no | +| 24 | 0.50 | 0.35 | no | +| 32 | 0.20 | 0.14 | no (N=32 band is 0.0925) | +| **48** | 0.12 | 0.057 | **yes** ← proven minimum | +| 64 | 0.078 | 0.044 | yes | +| **96** | **0.047** | **0.018** | **yes** ← shipped (2× margin) | +| 112 | 0.078 | 0.042 | yes (the old default — no better than 96) | + +The proven minimum for robust collapse is **48 passes** — the hand-picked 112 was +**2.3× over-provisioned**. Since mixing is throughput-free, the shield ships +**96 passes** (`PRIVACY_MARGIN_FACTOR = 2` × 48, rounded up to a candidate): it +drives re-ID *below chance* at N=16 (0.047 < 0.0625) at zero throughput cost, and +is still cheaper compute than the original 112. + +--- + +## 4. The adopted config, and why it beats the original + +| | Old (hand-picked) | Hyper-optimized (shipped) | +|---|---|---| +| Givens passes | 112 | **96** (from proven-min 48 × 2) | +| Feedback bits | 7 | **5** (spec-optimal) | +| Shield-on re-ID (N=16) | 0.078 | **0.047** | +| Throughput ratio | 0.9744 | **0.9760** | +| Robust across metrics & N | not checked | **verified** | + +The optimum is **strictly better on privacy and throughput at once**, and is now +*verified* rather than assumed. `ShieldConfig::default()` is exactly the +optimizer's output; the test `optimize::shipped_default_equals_optimizer_output` +fails if they ever drift apart. + +--- + +## 5. The Pareto frontier (and an honest note) + +`optimize::pareto_frontier` enumerates non-dominated (worst-case re-ID, +throughput) points over a pass × bits grid. In this model the frontier +**collapses toward the max-mixing, 5-bit point**, because mixing is +throughput-free — so beyond the throughput knob (bits) there is no privacy– +throughput tradeoff to trace. That degeneracy is itself the finding: *the only +thing privacy costs here is feedback resolution, and even that is cheap.* On real +hardware, where comm/identity subspaces are only approximately separable and +where more aggressive mixing may touch the data-carrying beam, this frontier is +expected to open up — a hardware study (roadmap P5) will re-measure it. + +--- + +## 6. Per-deployment adaptivity + +The optimum is not one number — `optimize` derives it per deployment: + +- **SNR → feedback resolution.** `optimal_bits_across_snr` shows the + *unconstrained* throughput-optimal resolution shifting with SNR: **4 bits at + 5–10 dB, 3 bits at 20–40 dB** (low SNR values fine resolution more because + the Shannon capacity is near-linear there, so the residual costs more). Within + the spec-allowed {5,7,9} set the choice is 5 bits across this whole range — + the residual is already negligible at 5 bits — which is why the shipped shield + is SNR-stable. +- **Identity count → mixing.** `adaptive_shield(base, n)` derives the config for + a room with `n` expected occupants. A notable finding: in this model the + collapse budget is **N-independent** (min 48 passes collapses N∈{8,64} + alike), because a well-mixed Haar-like rotation destroys per-identity + structure regardless of how many identities there are — the budget is set by + the fine-subspace dimension, not the candidate count. So `adaptive_shield` + returns the same 96/5 across that range: the default is robust, not a point + tuning. + +Both are surfaced through the harness `guidance --topic optimization`. + +## 7. Robustness caveats (unchanged from the threat model) + +- The collapse is verified against two classifiers and two N; a learned + attacker on real captures must still be checked (P2/P5). +- `feedback_bits` affects only throughput in this model, not re-ID; on hardware, + coarse quantization also adds obfuscation, which would *help* privacy — the + model conservatively ignores that. +- All optimization results are SYNTHETIC until a hardware witness exists. diff --git a/api-docs/research/privacy-shield/09-sota-update-2026.md b/api-docs/research/privacy-shield/09-sota-update-2026.md new file mode 100644 index 00000000..f10503cf --- /dev/null +++ b/api-docs/research/privacy-shield/09-sota-update-2026.md @@ -0,0 +1,151 @@ +# 09 — SOTA Update (2025–2026) and VEIL Improvement Backlog + +Source: a fan-out deep-research run (5 angles → 20 primary sources → 93 claims → +top 25 adversarially verified with 3-vote panels → 24 confirmed, 1 refuted). +Each finding carries its **evidence class** (`MEASURED` with metric / `CLAIMED` +/ `SYNTHETIC` / `STANDARDS-MINUTE`) and a primary URL. This file records what +changed in the field and the concrete backlog it implies for VEIL (ADR-288/289). +Nothing here upgrades VEIL's own numbers to `MEASURED` — that still requires a +captured hardware log (CLAUDE.md). + +--- + +## 1. The threat surface got worse (and cheaper) + +| Finding | Evidence | Source | +|---|---|---| +| **BFId** — first *identity* inference from plaintext BFI: **99.5% over 197 people**, perspective/gait-independent; BFI carries ~740 features vs 212 for CSI, so it *beats* CSI for identity; one eavesdropper captures BFI from all clients | `MEASURED` (top-1, N=197, CCS 2025) | [dl.acm.org/10.1145/3719027.3765062](https://dl.acm.org/doi/10.1145/3719027.3765062) | +| **LeakyBeam** — through-wall occupancy at **20 m** (TPR 82.7% / TNR 96.7%) **and breathing/vital-sign** leakage from *stationary* occupants; single antenna, Wireshark, no keys | `MEASURED` (NDSS 2025) | [ndss 2025-5](https://www.ndss-symposium.org/wp-content/uploads/2025-5-paper.pdf) | +| **WiKI-Eve / SThief** — keystroke & PIN/password theft from BFI (88.9% per-keystroke; 65.8% top-10 app passwords; POS keypads) with no device compromise | `MEASURED` (CCS 2023 / IEEE) | [WiKI-Eve](https://dl.acm.org/doi/10.1145/3576915.3623088) · [SThief](https://ieeexplore.ieee.org/document/10621321/) | +| **BFIAttack** — **reconstructs full CSI from sniffed BFI**: closed-form ≥93% (single-antenna, 1 attempt); MLE with physics/standard constraints 73% (multi-antenna, ≤5 attempts). Collapses the BFI-vs-CSI distinction | `MEASURED` (arXiv Apr 2026) | [arxiv 2604.04179](https://arxiv.org/html/2604.04179v1) | +| **BeamSense** — BFI sensing is standards-compliant, needs no firmware mod, ~10% higher activity accuracy than CSI | `MEASURED` | [BFISense/BeamSense](https://www.researchgate.net/publication/402468114_BFISense_Using_Beamforming_Feedback_Information_for_Wi-Fi_Sensing) | + +**Implication:** the attacker is a *passive, keyless, single commodity antenna at +~20 m, through walls*, that can (a) identify people, (b) read vitals and +keystrokes, and (c) **reconstruct CSI from the BFI itself.** VEIL's threat model +must treat all four as baseline. + +--- + +## 2. Defenses — the field validates VEIL's family and adds stronger primitives + +| Defense | Mechanism | Effect | Evidence | Source | +|---|---|---|---|---| +| **LeakyBeam defense** | AP-side **per-packet random unitary** `Q_obf` on the LTF via the 802.11 spatial-mapping mechanism (standard says "not restricted"); AP recovers `V = Q_obf · V_obf`; **clients unmodified** | attack **89.7% → ~51%** across 8 APs (~1.6M packets/49 h) | `MEASURED` | [ndss 2025-5](https://www.ndss-symposium.org/wp-content/uploads/2025-5-paper.pdf) | +| **PrivISAC (RIS)** | Paired per-row RIS vectors, one randomly active per slot; preserves comm-direction response, corrupts sensing direction; time-domain mask/demask for the authorized RX | **93% → ~30%**, and **29% vs. retrained 5-location adaptive attacker** | `MEASURED` (64-element FPGA RIS, Intel 5300, ~2,700 OTA samples) | [arxiv 2601.04488](https://arxiv.org/html/2601.04488) | +| **DP-Givens** | ε-DP stochastic quantizer on the Givens rotation/phase angles; closed-form angular sensitivity → principled ε budget; preserves 802.11 feedback structure | frontier: attacker error 19% → ~73%; beamforming gain 0.97 → 0.89 median (0.54 at full) | `SYNTHETIC` (Monte-Carlo) | [arxiv 2512.18529](https://arxiv.org/pdf/2512.18529) | +| **Adaptive-DP (CSI spectrogram)** | Importance-weighted (non-uniform) DP budget across the time-frequency plane | better privacy-utility than flat noise at equal ε∈[0.5,2]; cuts identity + membership inference | `CLAIMED` (unrefereed) | [arxiv 2512.20323](https://arxiv.org/abs/2512.20323) | +| **BeamDancer** | Randomized native-beamforming obfuscation | defeats supervised + unsupervised localization and micro-Doppler; **compliant, not jamming** | `MEASURED` (IEEE TWC 2024) — **do NOT cite its ">96% PDR" (refuted here)** | [ieee 10739908](https://ieeexplore.ieee.org/document/10739908/) | +| **TX-side CSI obfuscation (+ counter-attacks)** | Filter the whole frame incl. LTS; DNN de-obfuscation for authorized sensing | **security contested**: "Defeating CSI obfuscation" + SnoopFi FIA/CRA recover the signal | `CLAIMED` design + published rebuttal | [C&S 2025](https://www.sciencedirect.com/science/article/abs/pii/S0167404825002834) | + +**Where VEIL sits:** VEIL's keyed Givens rotation is the *same family* as the +LeakyBeam per-packet unitary and the DP-Givens knob — and unlike additive/DP +dither, VEIL's transform is **secret and orthogonal**, which is exactly the +property that should resist the BFIAttack closed-form/MLE inversion (the attacker +has no key, so there is no closed-form to invert to). That is now the decisive +claim to *test*, not assume. + +--- + +## 3. Compliance / legal line + +- **BeamDancer (IEEE TWC 2024)** is the peer-reviewed precedent for VEIL's + stance: **jamming and geofencing are non-compliant / non-scalable; exploiting + the standard beamforming mechanism stays 802.11-compliant** (validated without + disabling firmware). Cite it as the compliance precedent — but **not** its + refuted throughput figure. +- **Governance gap (unfilled):** *no* claim on the 802.11bf-2025 standard's + privacy provisions, the withdrawn secure-LTF-from-11az proposal, or + GDPR/HIPAA/EMSEC/ICD-705 boundaries **survived 3-vote verification** in this + run. Blog/secondary sources assert a withdrawn privacy proposal, but it needs + primary WG-minute/draft sourcing before VEIL relies on it. Tracked as an open + question. + +--- + +## 4. VEIL improvement backlog (derived, prioritized) + +Priority = (verified severity) × (fit to VEIL). `[code]` = crate change, +`[docs]` = documentation, `[hw]` = hardware path. + +1. **`[code]` ✅ implemented — Reconstruction-aware attacker (decisive).** A + BFIAttack-style adversary (`attacker::ReconstructionAttacker`, + `AttackerKind::Reconstruction`) recovers the direction of the CSI consistent + with the *captured* report and classifies it; the test + `reconstruction_attacker_collapses` confirms the keyed *orthogonal secret* + rotation leaves it at chance (no key → it only ever recovers the rotated + direction) while it still wins on unprotected traffic. *(BFIAttack, MEASURED)* +2. **`[code]` ✅ implemented — Adaptive, multi-capture attacker.** + `attacker::AdaptivePoolingAttacker` (`AttackerKind::AdaptivePooling`) pools all + captures per identity and whitens by per-dimension std before matching (the + PrivISAC adaptive/retraining adversary); `adaptive_pooling_attacker_collapses` + confirms collapse still holds. *(PrivISAC, MEASURED)* +3. **`[code]` ✅ implemented — Per-packet random-unitary mode.** + `protector::ObfMode::PerPacketUnitary` applies a fresh unitary per packet, + AP-side and **client-transparent** (LeakyBeam family; 802.11 spatial mapping + "not restricted" as the compliance basis); + `per_packet_unitary_mode_collapses_and_is_compliant` verifies it. *(LeakyBeam + defense, MEASURED)* +4. **`[code]` ✅ implemented — DP-Givens ε knob.** `ShieldConfig.dp_epsilon` adds + an ε-scaled angular dither, renormalized to preserve emission energy (still + not jamming); `throughput::dp_residual` makes ε a real privacy↔throughput knob + (`dp_epsilon_lowers_throughput_as_it_tightens`), and the combined + rotation+DP still collapses and stays compliant. Outputs `SYNTHETIC`. + *(DP-Givens, SYNTHETIC)* + +> Items 1–4 landed with the reference **witness unchanged** +> (`0x350d…f448`) — the new controls/attackers are opt-in fields; the shipped +> default config and its numbers are byte-identical. +5. **`[code/docs]` Privacy–throughput *frontier*, not binary claims.** Report + attacker-error-vs-privacy and gain/PDR-vs-privacy curves (we already have the + throughput-vs-bits and reid-vs-passes curves; add the joined frontier). +6. **`[docs]` Threat-model upgrade.** Elevate identity/gait re-ID, through-wall + vitals, keystroke/PIN, and **BFI→CSI reconstruction** to primary threats in + ADR-288 §threat and bundle 02; add the passive/keyless/20 m/through-wall + adversary as the default. *(done in this update)* +7. **`[docs]` Security honesty.** State that VEIL's shield security is `CLAIMED` + until it survives published de-obfuscation attacks (SnoopFi / "Defeating CSI + obfuscation"); add learned de-obfuscation to the attacker roadmap. +8. **`[code/docs]` Evaluation battery.** Adopt BeamDancer's three-attacker matrix + (supervised localizer + unsupervised clusterer + model-based Doppler) as a + minimum test set, plus identity + membership-inference metrics. +9. **`[hw]` Hardware-validation path.** Mirror the RIS/8-AP OTA testbeds for P5. + **Correction:** ESP32 is an *attacker/sensor* node only (its WiFi lower layer + is a closed blob exposing CSI *read*, not TX-feedback shaping); the protector + needs **openwifi (SDR/FPGA), Nexmon (C firmware patches), or vendor + firmware** + key agreement for the keyed-reversible version. See roadmap §P4. +10. **`[docs]` Governance sourcing.** Fill the 802.11bf privacy-provision gap + with primary WG minutes/draft; scope FCC Part 15, GDPR/HIPAA (inferred + biometric/health), and EMSEC/ICD-705 deployability. + +--- + +## 5. Open questions the evidence did not close + +- Does VEIL's obfuscation degrade **CSI *reconstructed* from BFI** (BFIAttack), + or only raise raw-BFI feature noise? *(the decisive effectiveness question)* +- What is VEIL's **own MEASURED** privacy–throughput frontier on silicon (the + only measured PDR number in the field was refuted; the DP curves are + simulation-only)? +- Does 802.11bf-2025 contain any privacy provision or a withdrawn one, and what + are the concrete FCC/GDPR/HIPAA/ICD-705 deployment boundaries? + +--- + +## Sources (primary, verified in this run) + +- BFId — CCS 2025: https://dl.acm.org/doi/10.1145/3719027.3765062 +- LeakyBeam (attack + per-packet-unitary defense) — NDSS 2025: https://www.ndss-symposium.org/wp-content/uploads/2025-5-paper.pdf +- BFIAttack (BFI→CSI reconstruction) — arXiv 2026: https://arxiv.org/html/2604.04179v1 +- WiKI-Eve — CCS 2023: https://dl.acm.org/doi/10.1145/3576915.3623088 +- SThief — IEEE: https://ieeexplore.ieee.org/document/10621321/ +- BeamSense/BFISense: https://www.researchgate.net/publication/402468114_BFISense_Using_Beamforming_Feedback_Information_for_Wi-Fi_Sensing +- PrivISAC (RIS) — arXiv 2026: https://arxiv.org/html/2601.04488 +- DP-Givens — arXiv 2512.18529: https://arxiv.org/pdf/2512.18529 +- Adaptive-DP spectrogram — arXiv 2512.20323: https://arxiv.org/abs/2512.20323 +- BeamDancer — IEEE TWC 2024: https://ieeexplore.ieee.org/document/10739908/ +- TX-side CSI obfuscation — Computers & Security 2025: https://www.sciencedirect.com/science/article/abs/pii/S0167404825002834 + +*Refuted (do not cite): BeamDancer ">96% PDR in LoS" (verification 1–2). Two DP +mechanisms are SYNTHETIC/CLAIMED, not silicon. Governance/standard pillar +unverified in this run.* diff --git a/api-docs/research/privacy-shield/README.md b/api-docs/research/privacy-shield/README.md new file mode 100644 index 00000000..6945591f --- /dev/null +++ b/api-docs/research/privacy-shield/README.md @@ -0,0 +1,102 @@ +# Privacy Shield Research Bundle — WiFi Veil + +**WiFi Veil** (codename **VEIL** — Verifiable Emission-shaping for +Identity-Leakage prevention) is a privacy *firewall* for WiFi sensing: it +prevents unauthorized identity and +activity inference from a room's WiFi while preserving normal communications. It +is the **countermeasure** counterpart to [BFLD](../BFLD/) — where BFLD *detects* +when beamforming feedback becomes identifying, WiFi Veil *acts* by shaping the node's +own compliant waveform (channel sounding, precoder phase, beam/feedback +schedules) so identity and activity inference fail, while a legitimate receiver +sees an essentially unchanged link. + +**This must use compliant waveform controls, never jamming.** Every technique +here operates on the defender's *own* legitimately transmitted, standards- +conformant frames. Nothing adds energy to interfere with another station's +transmission (the statutory definition of jamming, 47 U.S.C. §333/§302a). + +--- + +## Table of contents + +| File | Purpose | +|------|---------| +| [01-sota-survey.md](01-sota-survey.md) | State of the art: identity/activity inference attacks (BFI + CSI), the IEEE 802.11bf-2025 standard, and privacy-preserving countermeasures | +| [02-threat-model.md](02-threat-model.md) | Adversary classes, what WiFi Veil defends and what it explicitly does not, trust boundary | +| [03-countermeasure-design.md](03-countermeasure-design.md) | The compliant waveform controls, the separable-subspace principle, keyed Givens-rotation shield, and how it maps to the crate | +| [04-compliance-and-regulatory.md](04-compliance-and-regulatory.md) | The legal line between compliant waveform control and jamming, with statutory citations | +| [05-experiment-protocol.md](05-experiment-protocol.md) | The attacker-vs-protector experiment: metrics, acceptance bar, reproducer, and results | +| [06-market-and-buyers.md](06-market-and-buyers.md) | First buyers, procurement drivers, competitive landscape, and the standards-body gap | +| [07-implementation-and-roadmap.md](07-implementation-and-roadmap.md) | Crate layout, reuse map, hardware path, phased rollout, and open problems | +| [08-optimization.md](08-optimization.md) | Hyper-optimization: throughput-optimal feedback resolution, minimum robust mixing budget, Pareto frontier, and the adopted config | +| [09-sota-update-2026.md](09-sota-update-2026.md) | 2025–2026 SOTA update (verified, cited): stronger attacks (BFI→CSI reconstruction, through-wall vitals, keystroke), validated compliant defenses, and the derived WiFi Veil improvement backlog | + +Formal decision: [ADR-288](../../adr/ADR-288-veil-privacy-shield-compliant-waveform.md). +Reference implementation: [`v2/crates/wifi-densepose-privshield`](../../../v2/crates/wifi-densepose-privshield). + +--- + +## Executive summary + +1. **The threat is real and now standardized.** IEEE 802.11ac/ax beamforming + feedback (BFI) — the compressed Givens-rotation angle matrices (φ/ψ) a client + sends the AP — travels **unencrypted on the management plane**. Any device in + monitor mode can capture it for every client at once, no network access, and + the target need carry no device. **BFId** (KIT, ACM CCS 2025) re-identifies + individuals from BFI alone; **LeakyBeam** (NDSS 2025) detects occupancy + through walls at ~20 m from BFI; **BeamSense** recognizes activities at up to + 99.28% from BFI. IEEE Std **802.11bf-2025** (published 26 Sep 2025) + standardizes the sensing measurement/feedback surface these attacks abuse. + +2. **The standards body declined to fix it.** A 2023 proposal for a BFI + "secure transmission mechanism" (IEEE 802.11-23/0782) was **withdrawn** — + the working group did not align on characterizing sensing privacy as a + distinct problem. 802.11bf shipped without privacy protections. This is the + single strongest demand signal: the gap is structural and acknowledged. + +3. **No targeted anti-sensing product ships (as of 2026).** Every countermeasure + in the literature — IRShield, PhyCloak, MIMOCrypt, DP-Givens dithering, + ScatterShield — is research-stage. The only shipping substitute is broadband + RF shielding (SCIF/TEMPEST film/paint), which is blunt: it kills *all* RF and + cannot coexist with wanted WiFi. The whitespace is a **selective, coexisting, + software/PHY** shield. + +4. **The WiFi Veil mechanism.** Identity leaks through the *fine* cross-subcarrier + phase structure of a beamforming report; throughput rides the *dominant* + beam direction. These are (mostly) separable subspaces. WiFi Veil composes extra + **keyed Givens rotations** over the fine subspace only. The rotation is + *orthogonal* (energy-preserving ⇒ not jamming), *keyed per session* (the + legitimate receiver inverts it ⇒ throughput preserved), and *fresh each + session* (a sniffer cannot average it back ⇒ re-ID collapses to chance). + +5. **Measured on the reference model (SYNTHETIC), at the hyper-optimized + operating point.** On the default synthetic scene (16 candidate identities), + a passive re-identifier scores **100% with the shield off** and **4.7% with + it on** (chance = 6.25%), while modeled link throughput stays at **97.6%** of + baseline and the emission energy ratio is **1.000000** (compliant). The shield + config is chosen by the `optimize` module — 96 Givens passes (2× the proven- + minimum 48 for robust collapse across both attacker metrics and N∈{16,32}) at + 5-bit feedback resolution — not hand-picked (see + [08-optimization.md](08-optimization.md)). Reproduce: + `cargo test -p wifi-densepose-privshield`. + +6. **Scope, honestly.** WiFi Veil defends against a *third-party passive sniffer*. It + does **not** hide identity from the associated AP (that party holds the key) + — that is BFLD's detection/policy problem. WiFi Veil is a reference model, not + hardware: real-silicon validation (per CLAUDE.md) is future work with a + captured-log witness. + +--- + +## Evidence discipline + +Per repository policy, every quantitative claim is tagged: + +- **MEASURED** — from a cited primary source with its metric and conditions. +- **CLAIMED** — asserted by a source (vendor PR, press, standards minutes) + without an independent measurement. +- **SYNTHETIC** — produced by WiFi Veil's own deterministic model; reproduced by + `cargo test`, describing the model and not real hardware. + +WiFi sensing is never presented here as camera-grade, and no WiFi Veil result implies +a defense guarantee on real silicon until a hardware witness exists.