WiFi Veil & Privacy Shield
Relevant source files
The following files were used as context for generating this wiki page:
WiFi Veil (codename VEIL — Verifiable Emission-shaping for Identity-Leakage prevention) is a privacy firewall system. It shapes a node's own outgoing WiFi beamforming feedback to prevent unauthorized passive sniffers from re-identifying people or inferring activity. The system ensures that a legitimate receiver sharing a per-session key sees an unchanged link, maintaining network performance while collapsing attacker re-identification accuracy to chance.
Sources: wifi-veil/README.md:10-15, v2/crates/wifi-densepose-privshield/README.md:7-12
The system operates strictly with compliant waveform controls. It uses orthogonal Givens rotations to reshape the node's standards-legal signal without adding power or interfering with other stations. This design ensures compliance with 47 U.S.C. §333/§302a regulations as it does not perform RF denial or jamming.
Sources: wifi-veil/README.md:28-35, wifi-veil/CONTRIBUTING.md:7-10
Architecture and Components
WiFi Veil consists of a portable C core, a Rust reference crate, and hardware-specific adapters. The system isolates the "fine" cross-subcarrier phase structure (where identity leaks) from the "dominant" beam direction (where data throughput resides).
System Overview Diagram
The diagram shows the relationship between the portable C core, various hardware adapters, and the user-facing control interfaces.
Sources: wifi-veil/firmware/README.md:14-34, wifi-veil/README.md:52-64
Component Summary
| Component | Description | Files |
|---|---|---|
| C Core | Portable C99 implementation of keyed-rotation; host-validated for energy conservation. | firmware/core/ |
| Rust Crate | Deterministic reference and experiment model (Attacker vs. Protector). | wifi-veil/ |
veil TUI | Dependency-free terminal harness and ANSI dashboard for interactive control. | src/bin/veil.rs |
| MetaHarness | npm-based contributor harness for guidance, routing, and self-improvement demos. | harness/ |
| Adapters | Platform-specific scaffolds for openwifi, Nexmon, and OpenWRT. | firmware/ |
Sources: wifi-veil/README.md:52-64, wifi-veil/harness/README.md:15-28
Protection Mechanism
The "Shield" adds a secret, per-session "twist" to outgoing feedback using Givens rotations. These rotations are orthogonal, meaning energy input equals energy output.
Data Flow for Reversible Shielding
The sequence shows how the keyed rotation protects identity from sniffers while allowing legitimate receivers to recover signal data.
Sources: v2/crates/wifi-densepose-privshield/README.md:15-30, wifi-veil/firmware/openwifi/README.md:37-45
Performance Metrics (Synthetic/L0)
| Metric | Shield OFF | Shield ON |
|---|---|---|
| Passive Re-ID Accuracy | 100% | 4.7% (Chance = 6.25%) |
| Link Throughput Ratio | 100% | 97.6% |
| Emission Energy Ratio | 1.000 | 1.000 (Compliant) |
Sources: wifi-veil/README.md:44-50, v2/crates/wifi-densepose-privshield/README.md:65-71
Hardware Implementation
Feasibility and implementation depth vary significantly across hardware platforms.
Platform Feasibility Matrix
| Provider | Grade | Description |
|---|---|---|
| openwifi | B | Capability ceiling A. Only platform with full open PHY/MAC on FPGA allowing end-to-end keyed rotation. |
| OpenWRT | C | Coarse knobs only. Most feedback angles are locked inside proprietary MCU firmware blobs. |
| Nexmon | C | Read access is A, but shaping TX reports (Write) is unproven and deep within the D11 core. |
| ESP32 | F / B | F as self-protector (closed PHY); B as detector or RIS controller only. |
Sources: wifi-veil/firmware/README.md:58-75
openwifi Implementation (FPGA)
On openwifi, the system is implemented as new HDL blocks:
veil_rot(TX): Inserted betweenopenofdm_txandtx_intf. It left-multiplies the per-subcarrier sample vector by the keyed matrixQ.veil_unrot(RX): Inserted betweenrx_intfandopenofdm_rxto apply the inverseQ^H.
Sources: wifi-veil/firmware/openwifi/README.md:47-60
Nexmon Implementation (Broadcom)
Nexmon implementations target chips like the BCM43455c0 (Raspberry Pi 3B+/4B). The hook point is challenging because the VHT compressed beamforming report is generated by the proprietary D11 real-time core approximately 10 µs after the Null Data Packet (NDP).
Sources: wifi-veil/firmware/nexmon/README.md:28-40
Development and Compliance
Key Safety Rules
- Non-Jamming: Interference-based "defenses" are strictly prohibited. Every control must preserve energy and follow standard emission rules.
- Evidence Labeling: All defense metrics must be tagged as
SYNTHETIC,CLAIMED, orMEASURED. - Proof Witness: A deterministic FNV-1a witness (pinned in
src/proof.rs) ensures that the reference model remains stable and byte-reproducible.
Sources: wifi-veil/CONTRIBUTING.md:7-15
Command Line Interface (veil)
The veil binary provides subcommands for testing and optimization:
cargo run --bin veil: Launches the interactive TUI.cargo run --bin veil -- optimize: Derives the optimal shield configuration (default 96 Givens passes).cargo run --bin veil -- doctor: Performs a health self-check.
Sources: v2/crates/wifi-densepose-privshield/README.md:91-100
WiFi Veil provides a verifiable, standards-compliant method to protect individuals from device-free WiFi surveillance. By isolating and rotating the identity-leaking subspaces of beamforming reports, it collapses re-identification accuracy while maintaining link integrity across different hardware platforms.