frank/ruvnet--RuView
1
0
Fork 0
mirror of https://github.com/ruvnet/RuView synced 2026-08-11 20:41:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(privshield): fold verified 2025-2026 SOTA into threat model, compliance, and roadmap

Browse Source 
From a fan-out deep-research run (20 primary sources, 25 claims 3-vote verified,
24 confirmed / 1 refuted):

- New docs/research/privacy-shield/09-sota-update-2026.md: cited, evidence-classed
  SOTA update + prioritized VEIL improvement backlog.
- ADR-288 gains a "2025-2026 evidence update" section: broader threat (BFId
  99.5%/N=197; LeakyBeam through-wall vitals @20m; WiKI-Eve/SThief keystrokes;
  BFIAttack BFI->CSI reconstruction), VEIL's family independently validated
  (LeakyBeam per-packet unitary 89.7->51%; PrivISAC RIS 93->30%), BeamDancer
  (IEEE TWC 2024) as compliance precedent, shield-security-is-CLAIMED honesty,
  and the unfilled governance gap. Do NOT cite BeamDancer's refuted >96% PDR.
- Roadmap §3.1: answers "does this need custom WiFi firmware?" — yes; ESP32 is an
  attacker/sensor node only (closed blob, CSI read only), the protector needs
  openwifi / Nexmon / vendor firmware; keyed-reversible needs both ends + key.

Docs only. All VEIL numbers remain SYNTHETIC/L0; no code or claims upgraded.

Co-Authored-By: claude-flow <ruv@ruv.net>
Claude-Session: https://claude.ai/code/session_01WEXNqzs7UsfNFBcP5yW21p
This commit is contained in:
Claude
2026-08-09 16:09:33 +00:00
parent 0cb348da72
commit c63b26034b
4 changed files with 203 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/adr/ADR-288-veil-privacy-shield-compliant-waveform.md
+32
View File
@@ -150,6 +150,38 @@ 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
docs/research/privacy-shield/07-implementation-and-roadmap.md
+30 -2
View File
@@ -45,13 +45,41 @@ ported independently, and so it can never accidentally acquire a path to a radio
| **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 ESP32/Nexmon feedback path | build + hardware |
| **P5 — two-node hardware measurement** | Wi-BFI attacker vs. VEIL protector on real silicon; iperf throughput; captured log | **MEASURED** (with witness) |
| **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)
docs/research/privacy-shield/09-sota-update-2026.md
+140
View File
@@ -0,0 +1,140 @@
# 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]` Reconstruction-aware attacker (decisive).** Add a BFIAttack-style
adversary that attempts to invert/reconstruct before classifying, and a test
asserting the keyed *orthogonal secret* rotation leaves it at chance (no key →
no closed-form). This turns "should resist reconstruction" from assumption
into a checked property. *(BFIAttack, MEASURED)*
2. **`[code]` Adaptive, multi-capture attacker as baseline.** Pool captures
across sessions/locations and re-fit (the PrivISAC adaptive attacker). We
already model cross-session averaging; make it a first-class attacker variant
and assert collapse holds. *(PrivISAC, MEASURED)*
3. **`[code]` Per-packet random-unitary spatial-mapping mode.** Add the
LeakyBeam-style AP-side, client-transparent `Q_obf` control as a first-class
compliant mechanism alongside the keyed fine-subspace rotation, with the
802.11 "spatial mapping not restricted" citation as its compliance basis.
*(LeakyBeam defense, MEASURED)*
4. **`[code]` DP-Givens knob.** Add an ε-DP quantization mode with a closed-form
angular sensitivity bound, exposing ε as a configurable operating point.
Label outputs `SYNTHETIC`. *(DP-Givens, SYNTHETIC)*
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.*
docs/research/privacy-shield/README.md
+1
View File
@@ -28,6 +28,7 @@ transmission (the statutory definition of jamming, 47 U.S.C. §333/§302a).
| [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 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).