stoicpickle/buildbeacon

# BuildBeacon **用于已签名构建回执的视觉化、支持丢包恢复的传输方案。** [](https://github.com/stoicpickle/buildbeacon/actions/workflows/ci.yml) [](LICENSE) [](docs/PROTOCOL.md) [在线演示](https://stoicpickle.github.io/buildbeacon/) · [协议](docs/PROTOCOL.md) · [威胁模型](docs/THREAT_MODEL.md) · [测试矩阵](docs/TEST_MATRIX.md)  当有人对演示进行录屏、裁剪片段或仅转发画面时，构建证明通常会丢失。BuildBeacon 将一份紧凑的签名回执作为循环播放的 QR 标记保留在这些画面中。接收者可以在循环之间加入、丢失帧、重建规范回执，并在不上传片段或联系查询服务的情况下校验其 Ed25519 签名。 BuildBeacon 是一种实验性传输方案，而非视频真实性验证系统。有效的回执签名**并不**证明周围的影像来自所声称的制品，且其自身信封内携带的公钥**并不**能确立签名者的身份。 ## 运行六秒验证 打开[在线演示](https://stoicpickle.github.io/buildbeacon/)并选择 **Run the 6-second proof**。 已入库的测试夹具是一段真实的 1280×720 H.264 片段。它从喷泉序列 73 开始，包含 48 个渲染的 QR 帧和 11 个故意设置的重复项，并使用与上传片段相同的 `jsQR` 像素解码路径。当前的确定性验证会在以下条件满足后完成重建： - 11 个采样的视频帧； - 9 个独立的数据包； - 矩阵秩为 7/7； - 在夹具的公开测试密钥下具有有效的 Ed25519 签名。  在本地重现该验证： ``` npm ci npm run demo:verify ``` 测试密钥是 RFC 8032 公开测试材料，该回执明确是一个基于代码库真实初始提交及其 13 字节 README 制品的合成夹具。它被故意设定为不适合用于真实签名，且不提供任何身份保证。 ## 工作原理 ``` build claims ──dCBOR──> Ed25519 envelope ──BBP/1──> animated QR frames │ verified receipt <── signature check <── matrix decode <── visible pixels ``` 1. **签名** — 回执声明被编码为确定性的 CBOR，并使用域分离的 Ed25519 消息进行签名。 2. **传输** — BBP/1 将已签名的信封拆分为源数据块，并发射系统码和确定性的修复符号。 3. **恢复** — 接收方拒绝损坏或混合的帧，并在 GF(2) 上执行增量高斯消元法。 4. **检查** — 传输状态、签名有效性以及签名者信任度将作为独立的结果呈现。 该标记提供了三种刻意设计为可对比的形式：简短的构建 ID、自包含的静态 QR，以及支持丢包恢复的动态 beacon。只有当“中途加入”或“丢帧恢复”至关重要时，动态形式才值得付出其视觉成本。 ## 浏览器应用 环境要求：Node.js 22.12 或更高版本以及 npm。 ``` npm ci npm run dev ``` 该应用提供： - **传输** — 编写声明，创建临时演示签名，选择标记格式，并下载已签名的回执； - **恢复** — 完全在浏览器标签页中解码已入库的验证、上传的片段、静态 QR 图像或明确启用的摄像头； - **检查** — 查看恢复的构建声明、完整的签名者指纹、签名状态和信任警告。 浏览器端签名仅供演示使用。其密钥仅存活于当前标签页中，并在关闭后被丢弃。持久化签名应在本地 CLI 或受适当控制的签名系统中进行。 ## CLI 构建 CLI： ``` npm run build:cli node dist-cli/cli.js --help ``` 创建回执和签名密钥： ``` node dist-cli/cli.js demo --out receipt.json node dist-cli/cli.js keygen --out buildbeacon-key.json node dist-cli/cli.js create \ --input receipt.json \ --key buildbeacon-key.json \ --out receipt.bb ``` 验证并体验支持丢包恢复的传输： ``` node dist-cli/cli.js verify --input receipt.bb node dist-cli/cli.js simulate --input receipt.bb --offset 73 --loss 0.30 node dist-cli/cli.js frames --input receipt.bb --out-dir beacon-frames --count 24 ``` 在 POSIX 系统上，私钥文件以 `0600` 权限模式创建；如果存在属组或其他用户的权限位，将被拒绝创建；并且会被代码库通用的密钥文件匹配规则忽略。忽略规则并不等同于密钥保护。CLI 绝不接受通过命令行参数或 URL 传入的私钥字节。 密钥生成仅支持创建模式，并拒绝覆盖现有路径。 ## 它证明了什么——以及它不能证明什么 | 结果 | 含义 | |---|---| | 传输重建完成 | 足够多有效且线性无关的帧生成了其摘要与 beacon ID 相匹配的信封。 | | 签名有效 | 精确的规范回执与所包含公钥下的 Ed25519 签名相匹配。 | | 受信任的签名者 | 仅当验证者通过单独的信任决策锁定该密钥时才可用。演示版不执行此操作。 | BuildBeacon 不对周围视频进行身份验证，不防止叠加复制或重放攻击，不证明提交的存在，不证明测试已运行，不确立时间戳的新鲜度，不分发信任，不轮换或撤销密钥，也不在标记被裁剪掉或不可读时进行恢复。回执内容是可见的公开数据，并未加密。 ## 验证 ``` npm run check # lint, coverage-gated protocol tests, web + CLI builds npm run demo:verify # decode the H.264 fixture from pixels with ffmpeg + jsQR npm run test:e2e # browser flow and mobile-overflow proof npm audit --audit-level=high ``` 确定性测试套件涵盖了严格的 dCBOR 往返测试、RFC 8032 已知答案向量、域分离的回执签名、单比特篡改、QR 渲染/解码、CRC32C 拒绝、重复和混合帧、中途加入恢复、乱序以及固定丢包。当前的协议覆盖率阈值在 `vitest.config.ts` 中强制执行。 ## 状态与范围 BBP/1 是实验性的，尚未接受过独立的安全审计。该实现使用了 `@noble/ed25519` 3.x 版本；该当前的代码重写同样未声明进行过全新的独立审计。在将其作为证据使用之前，请参阅 [PROTOCOL.md](docs/PROTOCOL.md) 了解字节格式，并查阅 [THREAT_MODEL.md](docs/THREAT_MODEL.md)。 BuildBeacon 补充了——但当前不会解析、编写或验证——SLSA 来源、Sigstore 包、GitHub 制品证明或 C2PA 清单。后续的回执可以绑定这些制品之一的摘要，而无需替换其原生的验证器。 ## 贡献 请阅读 [CONTRIBUTING.md](CONTRIBUTING.md)。安全报告应提交至私密的 GitHub Security Advisory，如 [SECURITY.md](SECURITY.md) 中所述。 ## 许可证 Apache License 2.0。请参阅 [LICENSE](LICENSE) 和 [THIRD_PARTY_NOTICES](THIRD_PARTY_NOTICES)。

标签：CVE, MITM代理, SOC Prime, 二维码, 密码学, 开发工具, 手动系统调用, 数字签名, 数据传输, 构建溯源, 自动化攻击