RuView BFLD Soul 架构解析：以“免疫系统”而非“监控镜头”为隐喻的 WiFi 感知隐私设计-平芜编程栈

RuView BFLD Soul 架构解析：以“免疫系统”而非“监控镜头”为隐喻的 WiFi 感知隐私设计

【免费下载链接】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

导读

本文以 RuView 仓库docs/research/BFLD/02-soul.md为核心，系统阐述 BFLD（Beamforming Feedback Layer for Detection，波束成形反馈检测层）的架构意图与伦理立场。BFLD 是 RuView 生态中专门面向 802.11ac/ax 波束成形反馈信息（BFI）的隐私安全层：它不生产身份，而是守卫节点，防止“环境感知”意外滑向“身份记录”。读完本文，你将理解 BFLD 的三个不可协商不变量（原始 BFI 不出节点、身份嵌入仅驻留内存、跨站点身份关联在结构上不可能）如何在源码、帧格式与哈希方案中落地，以及为什么这一层必须在 WiFi 7 大规模铺开之前建立安全默认值。

1. 核心隐喻：免疫系统，而非监控镜头

免疫系统不会为遇到的每一种病原体建立档案。它按类型分类威胁、按比例做出反应，并把详细记录留在生物体本地。当免疫系统将某个细胞标记为危险时，它不会向外界广播该细胞的身份——它采取的是本地行动。

BFLD 正是围绕同一原则构建的。它的职责是检测 RF 数据何时从“环境感知（ambient sensing）”领域跨越到“身份记录（identity record）”领域，并就地响应：提高风险分数、限制离开节点的数据、轮换标识符。它不生产身份，它守卫的是身份的“意外生产”。

这一区分之所以关键，是因为驱动 BFLD 存在检测的同一路物理信号，也正是学术攻击者（BFId、LeakyBeam）用来做再识别（re-identification）的信号。BFLD 无法压制底层物理规律——但它能做到的是：即使节点的“输入”具备支持识别的能力，节点的“输出”也保持不可识别。

该立场在仓库中有清晰的项目记忆背书：RuView 的定位是“环境智能平台（ambient intelligence platform），而非传感器”。BFLD 研究包 README 开宗明义：BFLD 是“检测 RF 数据何时变得可识别的安全层”，它位于原始 802.11 波束成形反馈（BFI）与所有下游消费者（家庭自动化、MQTT、Matter、云端）之间，测量每一帧的身份泄漏潜力并门控节点输出。它不生产身份；它防御身份的意外或对抗性暴露。

2. 区分“身份”与 WiFi 感知的其他信息

WiFi 感知产生一个信息谱系。BFLD 的设计文档用一张表格将输出按隐私类别与可逆性分类：

输出	隐私类别	可逆性
存在（是/否）	2 — 匿名	不可逆转为身份
运动幅度（0..1）	1 — 派生	不可逆转为身份
人数（整数）	1 — 派生	不可逆转为身份
区域活动	1 — 派生	不可逆转为身份
身份风险分数	1 — 派生	风险分数，而非身份
RF 签名哈希	1 — 派生	哈希每日轮换；不可逆转
身份嵌入	0 — 原始	可直接逆转为生物特征
原始 BFI 矩阵	0 — 原始	可直接逆转为生物特征

BFLD 的设计在结构上遵循这张表：类别 0 的输出永不离开节点；类别 1 的输出中，敏感项（identity_risk_score）仅在操作员明确选择加入后才离开节点；类别 2 的输出自由流动。

关键点在于：这张表不是一份政策清单，而是被写进了帧格式。每个BfldFrame中的privacy_class字节在发射器边界、任何字节离开节点之前被检查。想发送类别 0 数据的代码必须正面绕过编译期安全检查，而不只是忘记设置某个标志位。

从源码看，这一承诺由 lib.rs 中的PrivacyClass枚举落实：allows_network()对Raw类返回false（结构性不变量 I1），allows_matter()仅对Anonymous | Restricted类返回true（Matter 边界只接受类别 2/3）。BfldError::PrivacyViolation则对应“试图通过网络 sink 发布类别 0 帧”的编译期/运行期双重拒绝路径。

3. 三个不可协商的不变量

以下三条不是可配置选项，而是 BFLD 的结构性属性，无论操作员如何配置都成立：

3.1 不变量 1：原始 BFI 永不离开节点

BFI 矩阵一旦被 BFLD 提取器摄取，就在本地消费，从不序列化到任何出站通道。强制执行有两条途径：

BfldFrame结构体的bfi_matrix字段不属于可序列化载荷——它只是extractor.rs中的私有字段，在特征提取完成后即被丢弃。
MQTT 发射器（mqtt.rs）没有任何序列化 BFI 矩阵的代码路径。ruview/<node_id>/bfld/raw/statetopic 默认禁用；即使启用，也只发布元数据摘要（子载波数、时间戳、SNR 范围），而不是角度矩阵。

从源码层面看，这一不变量由Sink标记 trait 层级与PrivacyClass::Raw.allows_network() == false共同承载。crate README 中的“Three structural invariants”表格明确列出：I1由“Sink 标记 trait 层级 +PrivacyClass::Raw.allows_network() == false”强制执行。ADP-118 的验收标准 AC4 进一步规定：“在任何privacy_class取值下，原始 BFI 字节绝不出现于任何序列化BfldFrame载荷中”。

3.2 不变量 2：身份嵌入仅限本地

由 RuVector 管线计算（用于identity_risk_score）的嵌入驻留在内存环形缓冲区中，保留窗口可配置（默认 10 分钟）。它从不写入磁盘、从不序列化到任何 MQTT topic、从不进入任何BfldFrame载荷——即使privacy_class = 0时也如此：“raw”指原始角度，而非派生嵌入。

支撑这一点的数学性质是：identity_risk_score可以仅从嵌入计算出一个标量

identity_risk_score = separability × temporal_stability × cross_perspective_consistency × sample_confidence

而无需暴露嵌入本身。分数是到标量的投影；完整向量不被任何下游消费者需要。

从源码看，这一承诺分三层落实：

embedding_ring.rs 实现固定容量（RING_CAPACITY = 64）的 FIFO 环形缓冲，满时驱逐最旧条目并触发其Drop以清零 f32 存储；drain()是显式的“轮换 site_salt”钩子（对应 ADR-121 §2.4 的Recalibrate动作）。该结构no_std兼容、无堆分配。
ADR-120 §2.5 规定IdentityEmbedding持有于subtle::Zeroizing<[f32; 128]>中，且类型上没有Serializeimpl；编译期#[forbid(serde::Serialize)]lint 确保未来的 PR 无法意外加上Serializederive。
crate README 的 I2 一行写明：IdentityEmbedding无Serialize/Clone/Copy，且Drop清零存储。

3.3 不变量 3：跨站点身份匹配在结构上不可能

rf_signature_hash的计算方式为：

blake3(site_salt ‖ day_epoch ‖ ephemeral_features)

其中site_salt是首次启动时生成的秘密，存储在 NVS（非易失存储）中，永不传输。两个不同站点的 BFLD 节点在构造上就会产生互不相交的哈希空间。即使攻击者同时拿到两个节点的哈希流，也无法判定同一个人是否访问过两个站点——因为site_salt未知且不同。

每日轮换（day_epoch= floor(timestamp_ns / 86400e9)）意味着即使在同一站点内，同一个人的哈希每天都会变化。超过 24 小时的旧哈希与今天产生的哈希相关性为零。

这是结构上的不可能，而非政策。即使操作员错误配置系统，不变量依然成立——因为它源自带秘密密钥的 blake3 的密码学性质，而非访问控制规则。

从源码看，signature_hasher.rs 是这一不变量的直接实现：SignatureHasher::compute(day_epoch, features)使用blake3::Hasher::new_keyed(&site_salt)，先更新day_epoch.to_le_bytes()，再更新特征字节。day_epoch_from_unix_secs以SECONDS_PER_DAY = 86_400为模计算每日纪元。ADR-120 的 AC2 给出了统计隔离验收标准：两个使用不同site_salt的节点观察同一模拟人物，100 次试验中产生的rf_signature_hash汉明距离 ≥ 120 bits；对应测试位于tests/signature_hasher.rs。

4. 与 RuView 环境智能定位的关系

项目记忆记录 RuView 的定位是“环境智能平台，而非传感器；打包（HA、Docker、mDNS、蓝图）才是瓶颈”。这一框架对 BFLD 的设计是承重的。

在 Home Assistant 模型中，“传感器”是报告测量值的设备，而且允许识别在场者是谁——人脸识别摄像头就是传感器。BFLD 明确拒绝这一模型：节点是环境智能节点，它了解环境中的某些信息（运动、占用、活动水平），但在结构上无法知道环境中是谁。

这一定位使得 BFLD 可以部署在身份追踪不可接受的场景：共享工作空间、访客住宿、酒店房间、护理机构。对护理机构操作员的论证不是“请相信我们，我们不会记录您的病人是谁”，而是：“该系统在架构上就无法记录您的病人是谁，因为标识符每天轮换，且使用我们不持有的站点专属秘密”。

这一边界在 ADR-118 §1.4 中与 Soul Signature 研究形成互补对照：Soul Signature 是“基于同意的、面向已登记个体的被动再识别生物特征”（7 通道多模态生物特征，60 秒登记协议），而 BFLD 是“测量并门控同一感知基质的身份泄漏”。Soul Signature 必须运行在privacy_class = 1（派生），BFLD 默认类别 2（匿名）。两者的共享资产包括 AETHER 编码器（ADR-024）、见证链（ADR-110/028）、RVF 容器与cross_room.rs（ADR-030）。BFLD 成为 Soul Signature 的执行层：identity_risk_score门控某个区域是否“泄漏到足以登记”，见证包是面向监管方的审计工件。

ADR-120 §2.7 定义了双 ID 空间契约：

部署模式	`privacy_class`	未登记旁观者的 ID 空间	已登记人员的 ID 空间
默认 BFLD-only	2（匿名）	每日轮换的`rf_signature_hash`	不适用——无登记
Soul Signature 选择加入	1（派生）	每日轮换的`rf_signature_hash`（不变）	来自 Soul Signature 图的长期不透明`person_id`
受限 / 护理机构	3（受限）	被抑制	不适用——类别 3 下 Soul Signature禁用

两个 ID 空间共存且无碰撞：轮换哈希是“不在同意名单上所有人”的隐私保护标识；稳定的person_id仅为在自己 GDPR/HIPAA 模式下的已登记受试者保留。

5. 为什么这一层必须在 WiFi 7 出货之前存在

802.11be（Wi-Fi 7）正在 2025–2026 年进入大众市场部署。它引入多链路操作（MLO），大幅提高波束成形探测交换的频率。802.11ax 的探测可能为 10–40 Hz，而 MLO 在多个链路上同时探测，每秒可能产生3–5 倍的 CBFR 帧。

更多帧意味着更多身份分类器的训练数据。BFId 在 5 秒 802.11ac 数据上的结果，几乎肯定会在 5 秒 802.11be MLO 数据上更好。攻击面不是静态的。

BFLD 的帧格式（magic0xBF1D_0001、用于扩展的版本字节）被设计为跨协议代际保持有效。特征提取模块是可插拔的：可以添加 WiFi 7 BFI 提取器，而无需改动隐私门、哈希轮换或 MQTT 发射器。不变量保持不变。

建立安全默认值的时间窗口是现在——在已安装基数达到数亿台未受保护节点之前。BFLD 就是把那些安全默认值从第一天带进每次部署的那一层。

从实现看，ADR-119 固化了这一前瞻性：BfldFrameHeader为 86 字节打包小端结构（#[repr(C, packed)]），magic 取0xBF1D_0001使bf1d在 hex-dump 中读作 “BFLD”，便于 Wireshark/xxd 调试；version字段支持未来修订。载荷为长度前缀的节序列（压缩角度矩阵、幅度代理、相位代理、SNR 向量、可选 CSI delta、可选厂商扩展）。序列化器在写入任何载荷字节之前强制执行隐私类别门控规则——类别 0 帧经NetworkSink::publish()返回Err(BfldError::PrivacyViolation)，由LocalSink/NetworkSink标记 trait 在类型层面承载。

6. 风险分数与门控机制的源码落地

identity_risk_score是 BFLD 的独特原语：一个标量，回答“当前捕获窗口是否具备识别特定个人的能力”。它有两个消费者：

操作员——作为 HA 诊断传感器暴露（ADR-122）。偏离长期基线的尖峰表明 RF 环境已滑向更高泄漏区间（新 AP 固件、更密集的 MIMO、范围内出现攻击级嗅探器）。
隐私门（ADR-120）——当分数越过可配置阈值时，门自动将活动privacy_class降级（如 2 → 3），直到分数恢复。

ADR-121 定义了九个特征（在W = 32帧滑动窗口上计算，约 10 Hz 下约 3 秒）：mean_angle_delta、subcarrier_variance、temporal_entropy、doppler_proxy、path_stability、cross_antenna_correlation、burst_motion_score、stationarity_score与前八个共享感知管线；只有第九个identity_separability_score（到最近 AETHER 聚类质心的 top-1 余弦）依赖嵌入，因此依赖identity_class >= 1。

风险分数公式为乘法组合：

pub fn identity_risk_score( sep: f32, // identity_separability_score, [0, 1] stab: f32, // temporal_stability, [0, 1] = ema(path_stability, alpha=0.1) consist: f32,// cross_perspective_consistency, [0, 1] = multistatic.rs conf: f32, // sample_confidence, [0, 1] = f(SNR, n_subcarriers, n_rx) ) -> f32 { let s = sep.clamp(0.0, 1.0); let t = stab.clamp(0.0, 1.0); let p = consist.clamp(0.0, 1.0); let c = conf.clamp(0.0, 1.0); (s * t * p * c).clamp(0.0, 1.0) }

乘法组合的动机：任何薄弱因子（如极低 SNR ⇒ 低conf）都会把分数压向 0。这契合隐私意图——系统不确定时，分数应低，操作员不应被惊扰。

分数按 KIT BFId 数据集持有外测试分割上的再识别成功率校准：分段线性保序回归将原始分数映射到校准的[0, 1]区间，使score ≥ 0.8对应校准数据集中 5 秒窗口>80%的再识别准确率。校准参数位于v2/crates/wifi-densepose-bfld/data/risk_calibration.toml，独立于代码版本管理。

对应的 Rust 测试套件覆盖了这些语义，例如 tests/identity_risk_score.rs（分数公式）、tests/embedding_ring.rs（环形缓冲）、tests/event_gating_irreversibility.rs（门控不可逆）与 tests/emitter_hasher.rs（发射器哈希）。

7. 类别转换、审计与默认拒绝（default-deny）

7.1 类别转换器：只有降级，没有升级

高层级帧变成低层级帧的唯一途径是PrivacyGate::demote(frame, target_class)。该函数：

断言目标类别数值严格高于（或等于）输入类别。
用subtle::Zeroize清零被禁字段。
重新计算payload_crc32。
返回新帧。

不存在promote操作——类别 2 帧无法变回类别 1 帧，因为被丢弃的字段没有保留在门可达的任何地方。BfldError::InvalidDemote对应“试图降级到数值更低（信息更多）类别”的拒绝路径。这一单调性让数据生命周期显式且可审计。

7.2 审计：验证原始 BFI 从未离开网络

操作员可以按以下流程验证节点从未传输过原始 BFI 或身份数据：

网络级审计（tcpdump）：在节点或端口镜像交换机上捕获 MQTT 流量，然后在 PCAP 中搜索 BFI 帧 magic 字节——0xBF1D_0001大端序为BF 1D 00 01。如果这些字节出现在 MQTT 载荷中，则可能存在原始 BFI；它们不应出现，因为 BFLD 在privacy_class >= 2时剥离角度矩阵。

节点自检命令：wifi-densepose bfld audit --duration 60s，输出形如“60 frames processed. 0 frames with raw_bfi in payload. 0 frames with identity_embedding in payload. privacy_class distribution: {2: 57, 3: 3}”。

CI 确定性哈希检查：运行python python/wifi_densepose/verify_bfld.py，必须打印VERDICT: PASS。如果修改过的二进制在载荷中外泄原始 BFI，输出哈希将与已提交的期望哈希不同。

7.3 默认拒绝：未来字段的强制分类

未来添加到BfldFrame或 BFLD 事件 JSON 的每个新字段都必须先分类再发布：

新字段加入BfldFrame结构体。
#[privacy_class(minimum = N)]属性注解（或privacy_gate.rs中的等价运行期检查）声明抑制该字段的最低隐私类别。
单元测试断言：在类别 < N 序列化时包含该字段，在类别 ≥ N 时省略。
添加该字段的 PR 若无分类注解则无法通过 CI。

这由 crate 内的自定义#[must_classify]lint 强制执行——BfldFrame上任何没有分类属性的公共字段都会产生编译警告，并升级为 CI 错误。这一机制直接回应设计文档“防止‘新字段发布、六个月后才发现身份泄漏’这一常见模式”的关切。

8. 在仓库中继续深入

架构总纲：ADR-118——BFLD 伞形决策、不变量 I1/I2/I3、六阶段路线（P1 帧格式 → P6 捕获适配器，共约 10.5 人周）。
帧格式与线路协议：ADR-119——86 字节头部、magic0xBF1D_0001、CRC-32/ISO-HDLC、确定性序列化。
隐私类别与哈希轮换：ADR-120——四类privacy_class、BLAKE3 键控哈希、默认拒绝分类、Soul Signature 双 ID 空间契约。
风险评分与一致性门：ADR-121——九特征、乘法风险公式、校准目标、一致性门四种动作。
实现 crate：wifi-densepose-bfld README——快速入门示例（examples/bfld_minimal.rs、examples/bfld_handle.rs）、feature flags（std/serde-json/mqtt/soul-signature）、测试命令。

结语

BFLD 的“灵魂”在于一个简单的信念：隐私不应依赖信任，而应依赖结构。免疫系统隐喻、隐私类别表格、三条不可协商不变量、以及“在 WiFi 7 之前建立安全默认值”的紧迫性，共同构成一个可执行的设计纲领——从帧格式的privacy_class字节、到SignatureHasher的逐日轮换、再到IdentityEmbedding的类型级禁序列化，仓库中的源码与测试把每一句伦理陈述都翻译成了编译器可强制、测试可验证、审计可追溯的工程事实。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考