RuView WiFi Veil：openwifi 双节点 P5 硬件测量协议详解（从 SYNTHETIC 到 MEASURED）

RuView WiFi Veil：openwifi 双节点 P5 硬件测量协议详解（从 SYNTHETIC 到 MEASURED）

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView

本文以 MEASUREMENT.md 为主体，完整拆解 RuView 项目中 WiFi Veil（合规波形隐私防护）在 openwifi 平台上的 P5 两节点硬件测量协议：测试拓扑、硬件清单、五步执行流程、指标通过判据，以及让结果获得MEASURED标签所需的完整见证物（witness artifact）清单。读完后你将掌握一套可直接照做的射频隐私防护实测方法，并能理解该协议背后veil_rot/veil_unrotFPGA 模块与驱动 shim veil_openwifi.c 的具体编程方式。

需要先强调本文档的自我定位（这也是全篇阅读的前提）：这是路线图 P5 的"计划"，不是"结果"。原文档开宗明义声明其状态为SYNTHETIC / L0——没有硬件运行过、没有抓包、仓库中没有任何一个数字是真实的。在见证日志存在之前，关于 openwifi WiFi Veil 的一切精度/吞吐/能耗论断都只能标注SYNTHETIC。本文严格遵循这一证据纪律：凡属计划均标"计划"，凡属实现均给出源码路径。

一、P5 在路线图中的位置与前置门槛

WiFi Veil 的硬件化按 firmware/privshield/README.md 划分为两个阶段：P4 是固件构建（build-only scaffold，全部适配器目前处于此状态），P5 是双节点硬件测量，目标是产出首个附带真实抓取的MEASURED数据。P5 的具体协议即本文介绍的MEASUREMENT.md，该划分同样被 ADR-290 与 docs/research/privacy-shield/07-implementation-and-roadmap.md 交叉引用。

P5 有三个前置门槛（prerequisite gates），全部要求在真实硅片上完成，且目前均未满足：

1. 一个包含veil_rot/veil_unrot逻辑块的比特流（bitstream），设计细节见 HDL_NOTES.md；
2. 一个会加载并编程veil_openwifi.c驱动的 openwifi 系统镜像；
3. 一次在 FPGA 上通过的self-loopback 正确性测试（IQ 回环在 Q1.15 舍入误差内恢复）。

三者齐备之前，任何"防御有效"的说法都不成立。这一点贯穿整个协议设计：测量流程的第一步（正确性验证）被明确标注为"不是防御性声明"，仅为后续防御性声明的地基。

二、测试拓扑：两个 openwifi 节点 + 一个被动窃听者

原文档给出的测量拓扑如下（ASCII 图原样保留）：

[ Protector AP ] over the air [ Legitimate STA ] openwifi node A ───────────────────────────────────► openwifi node B veil_rot: Q(key) engaged │ veil_unrot: Q^H(key) │ (shares key with A) ▼ [ Attacker sniffer ] commodity NIC, monitor mode Wi-BFI CSI/BF-feedback extraction + re-ID model

三个角色的职责：

• 保护者 AP（节点 A）：装载veil_rot比特流，对发射空间映射施加由会话密钥派生的酉（单位）矩阵Q(key)旋转；
• 合法 STA（节点 B）：与 A 共享同一把密钥，装载veil_unrot比特流，在信道估计前施加逆旋转Q^H(key)，从而抵消 A 的旋转、保持近基线的吞吐；
• 攻击者（sniffer）：一台商用 Wi-Fi 网卡，工作在 monitor mode，使用 Wi-BFI（arXiv 2309.04408）提取 CSI / 波束成形反馈（BF-feedback），再跑一个重识别（re-ID）/ 指纹模型。

关键合规约束在拓扑之后单独重申：攻击者是纯被动的（只做 monitor 抓包），本测试不向任何站点发射任何干扰信号。这呼应了整个 privshield 树的"合规波形"原则——钥控旋转是正交变换，只塑造本节点自身合规发射的能量分布，永不构成干扰（jamming）。

为什么是"新增 HDL 块"而不是改现有矩阵

这一点值得单独说明，因为它是理解整个测量对象的前提。openwifi 平台 README 明确指出 openwifi 出厂为SISO（单空间流）802.11a/g/n设计：不做 NDP sounding、不算 SVD 分解的V矩阵、也不产生压缩波束成形报告——因此硬件上不存在现成的Q矩阵可改。veil_rot/veil_unrot是引入一个全新的空间映射级（spatial-mapping stage）。所以 WiFi Veil 在 openwifi 上实现的是"客户端透明的逐包钥控酉变换"（LeakyBeam 家族）：旋转的是发射空间映射本身，使窃听者估计到的逐子载波信道H·Q(key)被打乱，而非去混淆一个硬件根本不产生的压缩报告。

密钥协商方式

演示中 A↔B 的密钥协商是带外的（out-of-band）预共享会话密钥；逐包键控采用(key, packet_counter)组合，规则与 HDL_NOTES.md 一致。从源码看，驱动 shim 中密钥通过两个 32 位寄存器写入（KEY_LO/KEY_HI，见下文注册表），而veil_ow_program_session内部用该 64 位密钥重新生成 Givens 调度——两端从同一密钥派生出比特级一致的Q，链路上不传输任何矩阵。

三、硬件清单

注意事项：

• 攻击者网卡必须在 Wi-BFI 的支持列表内，这直接决定能否稳定提取 CSI/BF 反馈；
• "屏蔽室或衰减器路径"是推荐项，目的是隔离 OFF/ON 条件间的无关信道变化；
• 功率测量用电源轨采样（rail sense）或独立功率计均可，用于支撑"保能（energy-preserving）/非干扰"声明。

四、执行流程：五个步骤，每个条件各跑两次

总规则：每个条件都执行两次——WiFi Veil OFF（基线）与 ON。两次之间必须保持相同天线位置、相同 MCS、相同持续时间、攻击者模型使用相同随机种子。这是控制变量纪律，任何一项漂移都会污染 OFF/ON 对比。

步骤 1：正确性前置（不是防御声明）

在 FPGA 上确认：

• self-loopback 下 IQ 在 Q1.15 舍入误差内恢复（veil_rot → veil_unrot回环，断言恢复值 == 输入）；
• 在veil_unrot生效状态下 A→B 链路可正常通信。

并抓取控制台日志。这一步只证明"旋转与逆旋转在硬件上互相抵消"，原文档反复强调它不构成防御MEASURED声明。openwifi 本身自带 packet/IQ self-loopback 测试设施（见 openwifi 官方 app note），协议是复用它而非自造回环。从源码结构看，shim 文件尾部（veil_openwifi.c 的注释区）也明确写了"回环验证必须先于 over-the-air"，并标注为TODO(hw)——即当前仓库尚无任何 FPGA 回环实跑记录。

步骤 2：攻击者抓包

sniffer 对 A→B 的一段固定流量模式分别记录 OFF 与 ON 两种条件下的 CSI / 波束成形反馈。必须保存原始数据：pcap 文件 + Wi-BFI 的提取输出。这是后续可复现性的原料——见证物清单要求"pcap + Wi-BFI 输出"两者俱全。

步骤 3：重识别（re-ID）指标

把同一个重识别/指纹模型分别跑在 OFF 与 ON 的抓取上，报告：

• 准确率（accuracy）与混淆矩阵；
• 必须对比chance / mean 基线。

原文档引用 CLAUDE.md 的硬规则：防御性声明必须附带基线，且必须使用无泄漏的留出划分（leakage-free held-out split）——永不报告裸准确率。这一条是整个协议中最容易"注水"的环节，文档用"never report bare accuracy"给出了禁止性措辞。

步骤 4：吞吐（"近零开销"检验）

用iperf3在 A↔B 之间双向（both directions）测量 OFF 与 ON 的吞吐。预期结论：ON ≈ OFF，因为合法接收端逆旋转抵消了发射端旋转。协议要求保存iperf3 --json原始输出，而非只留均值。

步骤 5：能耗与频谱合规

• 记录逐帧（per-frame）发射能量，OFF vs ON（电源轨采样或功率计），以此支撑"保能 / 非干扰"声明；
• 若有频谱分析仪，追加频谱/发射模板（spectral mask）符合性测量。

这一步的物理学依据在核心库的注释中写得很直白：正交变换保 L2 范数，即"not jamming"不变量——见 veil_shield.h 中对veil_shield_apply的说明（"the transform is orthogonal, so the L2 norm (energy) is preserved"）。

五、报告指标与通过判据

原文档定义的指标表（完整继承）：

四个指标分别对应威胁（re-ID 坍缩）、可用性（吞吐近无损）、合规性（能量与频谱）三个维度，缺一不可：只报 re-ID 下降而不报吞吐与能量，无法排除"以破坏通信为代价的伪装"这类伪防御。

六、测量对象的源码级实现：veil_openwifi.c如何编程 FPGA

测量协议度量的是两个尚不存在的 FPGA 块，但它们的行为已被仓库中的驱动 shim 完整约定。结合源码看测量对象的具体参数，可显著提升对上述流程的把握：

AXI-Lite 寄存器映射（veil_openwifi.c，与 HDL_NOTES.md 的寄存器表一致，偏移为字对齐占位值，RTL 落地后需回填）：

量化与调度细节：

• openwifi 基带 IQ 为 16 位 I / 16 位 Q，旋转系数以有符号 Q1.15编程（VEIL_ROT_FRAC = 15，veil_openwifi.c）；
• 调度生成函数veil_ow_build_schedule（L154-L179）逐 pass 从SplitMix64(key)抽取(i, j, θ)，j == i时置j = (j+1) % n，θ ∈ [0, 2π)；这与核心库 veil_shield.c 的前向调度逐位一致——SplitMix64 常量（0x9E3779B97F4A7C15、0xBF58476D1CE4E5B9等）与 Rust 参考 crateprng::Rng完全相同，是"两端派生同一Q"的根基；
• 角色枚举VEIL_OW_ROLE_PROTECTOR/VEIL_OW_ROLE_LEGIT_RX决定CTRL的 inverse 位：保护者写正向Q，合法接收端写Q^H（sin → -sin的逆序调度）；
• shim 有双编译模式：默认宿主/CI 模式下 MMIO 被替换为 256 字影子寄存器文件（无硬件即可单测调度与量化逻辑），定义VEIL_OPENWIFI_KERNEL才引入真实iowrite32/ioread32，并在写入后轮询STATUS的 ready 位（超时返回 -2，绝不把未就绪当成功，L234-L247）。宿主自测可用cc -DVEIL_OPENWIFI_SELFTEST veil_openwifi.c ../core/veil_shield.c -lm运行，其输出自我标注SYNTHETIC/L0 host shadow only — NOT hardware-validated（L281-L315）。

核心库的验证现状：core/是整个 privshield 树中唯一"已编译并测试"的组件——core/README 入口 说明cd core && make test覆盖能量守恒、可逆性、错钥失败、以及与 Rust crate 的 PRNG 流一致性。但按证据纪律，主机测试 ≠ 硬件证据，MEASURED标签只认硅片日志。

HDL 侧的插入点（决定步骤 1 回环测的是什么）：veil_rot插在openofdm_tx（IFFT 之后、加 CP 之后）与tx_intf（喂 AD9361 DAC）之间的 IQ AXI-Stream 上；veil_unrot插在rx_intf（AD9361 ADC）与openofdm_rx之间，或等价地放在频域 FFT 之后、信道估计之前（HDL_NOTES.md ）。文档同时诚实列出两项集成风险：802.11 SIFS 时延预算（块在 IFFT 与 DAC 之间增加流水线延迟，不得违反tx_intf的 TX 时序），以及逐包键控时"片上调度 vs 系数 RAM 双缓冲"的取舍——两者均为TODO(hdl)，即 P5 执行前必须关闭。

七、见证物清单：MEASURED声明的最低证据集

原文档最后一段是全文的"门禁"条款。在任何MEASURED声明之前，本目录（或 P5 证据路径）必须包含真实硅片抓取的日志——构建输出与仿真输出不算。最小证据集：

1. 双节点启动/运行时控制台日志：显示veil_rot/veil_unrot比特流已加载、veil_openwifi.c已完成会话编程（寄存器写入 / STATUS ready），且带时间戳与板卡标识；
2. self-loopback 正确性日志（步骤 1）；
3. 攻击者原始抓取：OFF 与 ON 各一份（pcap + Wi-BFI 输出），外加精确的重识别复现命令及其输出；
4. iperf3 --json（OFF 与 ON）与能耗轨迹（OFF 与 ON）；
5. manifest：把每份工件绑定到所用 RTL、驱动、shim 的 git 提交号，保证结果可复现。

反面清单同样重要：Vivado 构建成功、Verilator/QEMU 运行、宿主veil_openwifi.c自测——都不是硬件证据，必须停留在SYNTHETIC。原文档收尾一句"今天本仓库没有任何日志——不要伪造一个（No log in this repo today — do not fabricate one）"，与 CLAUDE.md 的硬件证据规则一脉相承。

八、适用前提与限制小结

• 当前状态：协议为计划文本；比特流、驱动加载、FPGA 回环三门槛均未满足，仓库中所有 openwifi 侧文件均为SYNTHETIC / L0构建骨架（TODO(hw)/TODO(hdl)标记遍布 veil_openwifi.c）；
• 平台约束：openwifi 为 SISO 802.11a/g/n，无原生显式波束成形；本测量协议度量的是"新增空间映射级上的钥控酉变换"，不是对压缩波束成形报告的混淆。真正的 2×2 空间映射（Scope B，启用第二发射链）在 HDL_NOTES.md 中列为更高工程量的后续项；
• 可先行验证的部分：核心库make test（主机、无射频）与 shim 的宿主自测（-DVEIL_OPENWIFI_SELFTEST）今天即可运行，但它们只验证调度与量化的软件正确性，按协议不得升级为MEASURED依据；
• 复现链条：核心 → 驱动 → RTL 的比特一致性依赖 SplitMix64 常量与抽取顺序在 C 核心、C shim、（未来的）Verilog 块三者间严格对齐，manifest 绑定 git 提交号正是为此而设。

按此协议执行完毕后，你将得到一组四指标对照表（re-ID、吞吐、逐帧能量、频谱符合性）加一份完整见证包——这正是 RuView 证据纪律下"从 SYNTHETIC 升级到 MEASURED"的唯一通道。

【免费下载链接】RuViewπ RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring, and presence detection — all without a single pixel of video.项目地址: https://gitcode.com/GitHub_Trending/wi/RuView