1. 硬件安全概述：硬件安全威胁模型、攻击面分析、安全设计原则
大家好，我是你们这堂课的主讲人。在硬件安全这个领域摸爬滚打了十几年，我踩过的坑、流过的泪，可能比你们写过的代码还多。今天咱们聊点实在的——硬件安全到底是个什么东西？为什么说它比软件安全更「要命」？
先讲个我亲身经历的事。几年前我参与一个IoT芯片项目，软件团队拍着胸脯说「我们的加密算法固若金汤」。结果呢？样片回来后，我们用一台不到2000块的示波器，在电源引脚上抓了半小时波形，就把AES密钥给还原了。嗯，这就是硬件安全的残酷现实——你软件写得再漂亮，硬件上一个小疏忽就能让所有努力归零。
1.1 硬件安全威胁模型
做安全设计，第一步不是写代码，而是搞清楚「谁在打你的主意」。我个人习惯把威胁模型分成三个维度：
| 威胁类型 | 攻击者能力 | 典型场景 |
|---|---|---|
| 物理攻击 | 拥有芯片实物 | 探针、激光、FIB |
| 侧信道攻击 | 能观测物理泄露 | 功耗、电磁、时序 |
| 逻辑攻击 | 能访问接口 | JTAG、扫描链、调试口 |
你想想看，一个攻击者如果拿到了你的芯片，他能干什么？
- 拆封装——用酸把塑料外壳腐蚀掉，直接用显微镜看走线
- 打探针——在总线或存储单元上焊根头发丝粗细的钨丝探针
- 注入故障——用激光或电磁脉冲让某个寄存器翻转，绕过安全校验
我在项目中遇到过最离谱的一次，客户说他们的安全芯片「绝对攻不破」。结果我们团队用一把手术刀、一瓶丙酮、一台二手显微镜，三天就把固件dump出来了。说白了，硬件安全没有「绝对」这回事。
1.2 攻击面分析
攻击面，就是攻击者能「碰到」你的所有地方。做硬件安全设计，你得把自己想象成一个贼——从芯片的每个引脚、每个接口、每个测试模式去思考「怎么撬开这把锁」。
常见的攻击面包括：
核心攻击面清单
- 调试接口：JTAG、SWD、cJTAG——这些本来是帮你调试的，但没锁好就是后门
- 存储单元：SRAM、Flash、eFuse——掉电后数据还在不在？能不能被读？
- 通信总线：SPI、I2C、UART——能不能中间人监听或篡改？
- 电源网络：VDD、VSS——功耗波动会泄露密钥信息
- 时钟与复位：能不能通过时钟毛刺让状态机跳转到非授权状态？
我记得有一次做车规级芯片的安全评估，发现一个致命问题：芯片的JTAG端口在量产后竟然没有熔断。这意味着任何拿到芯片的人，都能通过JTAG读取内部所有寄存器的值。为什么会这样？因为设计团队觉得「反正没人会拆车机」。嗯，这种想法很危险。
避坑指南
我曾经见过一个团队，把安全密钥存在eFuse里，但没做读保护。结果攻击者只需要发一条简单的读命令，密钥就出来了。记住：存储不等于安全，访问控制才是关键。
1.3 安全设计原则
讲了这么多威胁，那到底该怎么设计？我总结了几个核心原则，都是拿真金白银的流片失败换来的教训。
原则一：纵深防御
别指望单点防护。就像你家大门装了锁，但窗户也得关好。硬件安全也一样——
- 第一层：物理防护（屏蔽层、主动屏蔽网）
- 第二层：逻辑防护（访问控制、加密引擎）
- 第三层：协议防护（双向认证、防重放）
原则二：最小权限
每个模块只给它能完成工作所需的最小权限。我见过一个芯片，它的DMA控制器竟然能直接访问安全存储区。为什么？因为设计时图省事，把所有总线都连在了一起。结果呢？一个普通的USB攻击就能把密钥读走。
原则三：失效安全
当系统出错时，默认进入安全状态，而不是开放状态。举个例子：
// 错误的设计
if (authentication_passed) {
grant_access();
}
// 如果认证模块崩溃了，默认通过！
// 正确的设计
if (authentication_failed) {
deny_access();
}
// 只有明确通过才放行，其他情况一律拒绝这个原则说起来简单，但我在代码审查中至少见过十几次反着写的。你想想看，如果芯片因为电压波动导致认证逻辑跳过了if判断，那后果是什么？
原则四：可审计性
所有安全相关操作都要留下痕迹。谁在什么时候访问了哪个安全资源？失败了多少次？这些信息对事后分析和攻击溯源至关重要。
我的小建议
刚开始做硬件安全设计时，别想着一步到位。先画一张攻击面地图，把每个接口、每条总线、每个存储单元都标出来。然后问自己三个问题：
- 这个点能被物理接触到吗？
- 如果被接触了，能获取什么信息？
- 我能做什么来阻止或检测这种接触？
把这三个问题想清楚，你的安全设计就成功了一半。
好了，这一章的内容就到这里。硬件安全不是玄学，它是一套系统性的工程方法。下一章我们会深入聊聊具体的攻击技术——从侧信道到故障注入，我会用实际案例告诉你，这些攻击到底是怎么发生的，以及我们该怎么防。
记住一句话：在硬件安全的世界里，没有「不可能」，只有「还没想到」。