4. 硬件安全审计（一）：芯片设计安全、JTAG/SWD 接口、调试端口锁定
硬件安全审计，很多人一听就觉得头大。觉得那是芯片设计公司的事，跟咱们搞供应链安全的没关系。其实不然。你想想看，如果芯片底层就有后门，或者调试接口没锁好，那上层软件做得再安全，也是白搭。
这一章，咱们就聊聊硬件安全审计里最基础、也最关键的三个点：芯片设计阶段的安全考量、JTAG/SWD 接口的风险，以及调试端口的锁定机制。
4.1 芯片设计安全：从源头掐断风险
芯片设计阶段的安全，说白了就是“防患于未然”。我见过太多项目，流片回来才发现有安全漏洞，那代价可就大了去了。硬件改版一次，少说几十万美金，周期还得几个月。
4.1.1 硬件木马检测
硬件木马，就是在芯片设计或制造过程中被恶意植入的额外电路。它可能是一个触发电路，平时不工作，一旦收到特定信号，就开始搞破坏——比如泄露密钥、降低性能、甚至让芯片彻底报废。
审计时，我们要重点关注以下几点：
- 设计来源审查：IP 核来自哪里？有没有经过第三方安全认证？
- 网表级比对：RTL 代码和最终网表是否一致？有没有多余的逻辑？
- 冗余逻辑分析：芯片里有没有“不该存在”的电路？比如一个从来没被调用的状态机。
- 侧信道分析准备：设计是否预留了功耗、电磁辐射的监测点？
核心原则：芯片设计安全，不是靠“加锁”实现的，而是靠“透明”和“可追溯”。你无法审计你看不见的东西。
4.1.2 安全架构审查
除了防木马，还要看芯片的架构本身是否安全。比如：
- 隔离机制：安全区和非安全区有没有物理或逻辑隔离？ARM TrustZone 或 RISC-V 的物理内存保护（PMP）用了吗？
- 密钥存储：根密钥是放在 OTP（一次性可编程存储器）里，还是放在 eFuse 里？有没有防物理读取的保护？
- 随机数发生器：真随机数发生器（TRNG）的熵源够不够？有没有经过 NIST SP 800-22 测试？
我记得有一次审计一个 IoT 芯片，发现它的随机数发生器居然用的是 LFSR（线性反馈移位寄存器）。说白了，那就是个伪随机数，种子固定的话，输出完全可以预测。这种芯片用在加密通信里，跟没加密一样。
4.2 JTAG/SWD 接口：调试的便利，安全的噩梦
JTAG（Joint Test Action Group）和 SWD（Serial Wire Debug）是芯片调试的标准接口。工程师靠它们下载程序、调试代码、读取寄存器。但攻击者也靠它们读取固件、提取密钥、甚至修改芯片运行逻辑。
4.2.1 接口原理与风险
JTAG 用的是 5 根线：TCK、TMS、TDI、TDO、TRST。SWD 更精简，只用 SWDIO 和 SWCLK 两根线。它们都能访问芯片的内部总线，说白了就是“万能钥匙”。
| 接口 | 引脚数 | 速度 | 主要风险 |
|---|---|---|---|
| JTAG | 4-5 | 中 | 可读写任意内存、寄存器；可单步执行代码 |
| SWD | 2 | 高 | 与 JTAG 类似，但引脚更少，更容易被隐藏 |
| cJTAG | 2 | 中 | 兼容 JTAG 协议，但引脚数减少，风险同 JTAG |
警告：不要以为产品量产了，调试接口就没用了。攻击者可以通过物理探针、激光切割等方式，重新激活被禁用的调试接口。我见过一个案例，攻击者用聚焦离子束（FIB）修复了被熔断的 eFuse，硬是把锁死的 JTAG 给打开了。
4.2.2 审计检查清单
审计 JTAG/SWD 接口时，我建议按以下步骤来：
- 物理检查：PCB 上有没有预留 JTAG/SWD 测试点？如果有，是否被覆盖或屏蔽？
- 接口探测：用 JTAGulator 或类似工具，扫描目标板上的 JTAG/SWD 引脚。看看能不能识别出 IDCODE。
- 权限验证：如果能连接上，尝试读取芯片的 Flash 或 SRAM。看看是否需要认证。
- 锁定状态确认：读取芯片的安全状态寄存器。确认调试端口是否已被永久锁定。
小技巧：有些芯片支持“调试认证挑战-响应”机制。也就是说，即使 JTAG 接口是开着的，你也得先通过密码或证书认证，才能进行调试操作。这种机制比单纯锁死接口更灵活，也更安全。
4.3 调试端口锁定：该锁就锁，别犹豫
调试端口锁定，是硬件安全审计里最直接、也最有效的措施。但怎么锁、锁到什么程度，这里面有讲究。
4.3.1 锁定机制分类
常见的锁定机制有三种：
- eFuse 熔断：一次性编程，熔断后不可恢复。这是最彻底的方式，但一旦锁死，连合法的固件升级都做不了。
- OTP 寄存器：通过写入一次性可编程寄存器来禁用调试接口。比 eFuse 灵活一点，但本质上也是一次性的。
- 密码保护：调试接口仍然物理可用，但需要输入密码才能激活。密码通常存储在芯片的 OTP 或 eFuse 中。
| 锁定方式 | 安全性 | 灵活性 | 适用场景 |
|---|---|---|---|
| eFuse 熔断 | 高 | 低 | 量产定型产品，不再需要调试 |
| OTP 寄存器 | 高 | 中 | 需要出厂后禁用调试的产品 |
| 密码保护 | 中 | 高 | 需要现场调试，但又要防止未授权访问 |
4.3.2 审计验证方法
审计时，不能只看文档说“已锁定”，必须实际验证。我的做法是：
- 尝试连接：用调试器（如 J-Link、ST-Link）尝试连接目标芯片。如果能读到 IDCODE，说明接口没完全锁死。
- 尝试读取：如果能连接，尝试读取 Flash 的前 1KB 内容。如果能读到数据，说明安全机制形同虚设。
- 尝试写入：如果能读取，尝试写入一个已知值到 RAM 中。如果能写成功，说明攻击者可以修改代码执行流。
- 检查锁定标志：读取芯片的安全状态寄存器。确认锁定标志位是否已置位。
避坑指南：我曾经审计过一个车规级芯片，文档上写着“调试端口已永久锁定”。结果我用 J-Link 一接，直接连上了。后来发现，是产线上的烧录脚本忘了执行锁定指令。所以，千万别信文档，信你的示波器和调试器。
4.4 知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作审计时的检查路线图。
4.5 本章小结
硬件安全审计，不是看几份文档就能交差的。你得真刀真枪地干。芯片设计阶段，重点查木马和架构；JTAG/SWD 接口，重点查物理可达性和权限；调试端口锁定，重点查实际锁定状态，而不是文档上的“已锁定”。
嗯，这一章的内容就到这里。记住，硬件安全是供应链安全的基石。这块要是塌了，上面的一切都是空中楼阁。