BilalAli6/fli-offswitch-redteam

# 针对 AI 硬件紧急断电开关的红队测试 **在一个简化的硬件许可证断电开关上发现并修复了 3 类攻击，每一次攻击和每一次修复都经过了仿真验证，而非仅仅停留在纸面论证。**     ## 为什么会有这个项目 基于硬件的 AI 治理机制——如离线许可证、推理验证、算力断电开关——正作为一种在物理层强制执行 AI 安全承诺的方法，获得越来越多的实际关注。该领域的大多数公开工作都集中在*构建*机制上。本项目提出了第二个同样重要的问题： **实际上，有人会如何尝试攻破它？** 我为 AI 加速器的许可证断电开关构建了一个简化的 RTL 模型，并针对三种不同的类别对其进行了攻击：协议级攻击、时序级攻击和物理故障注入攻击。每一次攻击都被发现、利用、修复，并且修复后都针对*相同*的攻击进行了重新验证——其中甚至包括一个我的首次修复尝试引入了全新 bug 的案例，该 bug 只有通过坚持回归测试而非仅凭肉眼检查信任修复结果才能被发现。

## 发现一览 | # | 发现 | 攻击面 | v1 | v2 | v3 | |---|---|---|:---:|:---:|:---:| | 1 | **重放攻击** | 任何能观察到一次有效 token 交换的人 | 🔴 漏洞 | 🟢 已修复 | 🟢 已修复 | | 2 | 过期时的**竞态条件** | 任何能切换使能信号线的人 | 🔴 漏洞 | 🟢 已修复 | 🟢 已修复 | | 3 | **单比特故障注入** | 物理/近物理访问（时钟/电压/电磁干扰） | 不适用 | 🔴 漏洞 | 🟢 已修复 | **发现 3 是架构上最重要的一点**——它完全绕过了针对发现 1 和 2 的修复。如果最终关于“是否允许此芯片运行”的决策仅仅取决于一个未受保护的触发器，那么再多的正确加密或正确时序都无济于事。

包含根本原因、漏洞利用证明和针对每个发现的修复的完整报告：**[docs/FINDINGS.md](docs/FINDINGS.md)** ## 包含内容 ``` rtl/ license_offswitch_v1.v baseline (intentionally naive) off-switch license_offswitch_v2.v fixes replay attack + race condition license_offswitch_v3.v adds triple modular redundancy vs. fault injection tb/ tb_normal_operation.v baseline sanity check (no attacks) tb_replay_attack.v Finding 1: replay attack against v1 tb_race_condition.v Finding 2: race condition against v1 tb_v2_validation.v re-runs Findings 1 & 2 against v2, proves fixes hold tb_fault_injection.v Finding 3: single-bit fault injection against v2 tb_v3_validation.v re-runs all attacks against v3, proves fixes hold colors.vh shared ANSI color macros for terminal output docs/ FINDINGS.md full writeup: root cause, impact, proof, fix — per finding run_and_report.sh runs everything + generates an HTML report generate_report.py builds the report from simulation logs ``` ## 快速开始 需要 [Icarus Verilog](http://iverilog.icarus.com/)（`iverilog` + `vvp`）和 Python 3。 ``` git clone https://github.com/BilalAli6/fli-offswitch-redteam.git cd fli-offswitch-redteam chmod +x run_and_report.sh ./run_and_report.sh ``` 这将运行所有 6 个仿真，在您的终端中实时输出带有颜色的通过/失败结果，然后自动生成并打开一个总结所有发现的 HTML 报告。

或者手动运行每个测试

``` # Baseline 健全性检查 iverilog -Itb -o sim_normal rtl/license_offswitch_v1.v tb/tb_normal_operation.v && vvp sim_normal # Attack 1: 重放 iverilog -Itb -o sim_replay rtl/license_offswitch_v1.v tb/tb_replay_attack.v && vvp sim_replay # Attack 2: 竞态条件 iverilog -Itb -o sim_race rtl/license_offswitch_v1.v tb/tb_race_condition.v && vvp sim_race # 验证 v2 中 Finding 1 & 2 的修复 iverilog -Itb -o sim_v2 rtl/license_offswitch_v2.v tb/tb_v2_validation.v && vvp sim_v2 # Attack 3: 故障注入（在 v2 中仍然有效！） iverilog -Itb -o sim_fault rtl/license_offswitch_v2.v tb/tb_fault_injection.v && vvp sim_fault # 验证 v3 中 Finding 3 (TMR) 的修复 iverilog -Itb -o sim_v3 rtl/license_offswitch_v3.v tb/tb_v3_validation.v && vvp sim_v3 ``` 查看波形：`gtkwave waves/replay_attack.vcd`

## 范围和限制（诚实声明） 这是一个简化的仿真模型，并非对任何已部署系统的审计。 - 故障注入是在 RTL 层级建模的（直接强制产生故障），而不是在物理上重现真实的时钟/电压/电磁干扰（后者需要物理硬件或专业的故障仿真工具）。 - 挑战-响应方案为了易读性使用了 XOR，**而非**作为生产环境的加密建议——真正的设计需要 HMAC 或硬件 AES 核。 - 三模冗余在现实世界中的有效性取决于三个副本在裸片上的物理分离（这是在 RTL 控制范围之外的布局布线问题）。 有关每个限制的完整讨论，请参阅 [docs/FINDINGS.md](docs/FINDINGS.md)。 ## 背景 作为一个自主项目，它将进攻性安全/红队测试背景应用于基于硬件的 AI 治理机制——这也是从进攻性安全向 AI 安全和评估工作持续转型的一部分。 **作者：Muhammad Bilal Ali Saif** 问题或反馈：[bilalalisaif6@gmail.com](mailto:bilalalisaif6@gmail.com) · [LinkedIn](https://linkedin.com/in/muhammad-bilal-ali-saif-pro)

标签：AI安全, Chat Copilot, Verilog, Web报告查看器, 故障注入, 硬件安全, 红队评估, 逆向工具