📚 课程目录第2章 PUF攻击模型

2. PUF攻击模型：攻击者能力假设、攻击目标分类、攻击场景建模、安全边界定义

做PUF安全测试，第一步不是拿仪器去量，而是先想清楚——我们要防的是谁？

我见过不少团队，一上来就测误码率、测温度漂移，结果攻击者用个简单的机器学习模型就把PUF响应猜了个七七八八。为什么？因为没在项目初期把攻击模型定义清楚。说白了，没有攻击模型的PUF测试，就像不知道靶子在哪就开枪。

这一节，我们就把攻击模型拆开揉碎了讲。我会结合自己踩过的坑，帮你建立起一套完整的攻击模型分析框架。

2.1 攻击者能力假设

攻击者到底有多强？这个问题没有标准答案，但我们可以分几个层次来讨论。我个人习惯把攻击者能力分成三个等级：

能力等级	物理访问	设备数量	测量精度	计算资源
L1 - 黑盒攻击者	仅能通过公开接口通信	1~10个样本	数字接口精度	普通PC
L2 - 灰盒攻击者	可物理接触芯片封装	10~100个样本	示波器级（ns精度）	工作站 + FPGA
L3 - 白盒攻击者	可进行芯片逆向/去封装	100+个样本	探针台/EM探头（ps精度）	服务器集群 + 专业EDA工具

注意： 不要默认攻击者只有L1能力。我在一个项目中就吃过这个亏——我们假设攻击者只能通过I2C接口读数据，结果对方直接把芯片开盖用激光扫描了PUF阵列。那次教训让我养成了一个习惯：安全设计时按L2起步，关键系统按L3考虑。

除了物理能力，还要考虑攻击者的先验知识。比如：

是否知道PUF的电路结构？
是否知道CRP（挑战-响应对）的映射算法？
是否拥有同批次的其他芯片？

这些信息往往比物理设备更重要。你想想看，如果攻击者知道你的PUF用的是环形振荡器结构，连频率范围都清楚，那他建模的起点就比你想象的高得多。

2.2 攻击目标分类

攻击者想干什么？这个问题直接决定了我们要保护什么。我把攻击目标分成四类：

    核心观点： 90%的PUF攻击案例，目标都落在下面这四类里。搞清楚攻击目标，才能有针对性地设计防护。

克隆攻击（Clone Attack） —— 复制一个功能上等价的PUF实例。攻击者不关心内部物理细节，只要输出和原始PUF一致就行。我在2019年遇到过一起案例，攻击者用FPGA实现了某个SRAM PUF的神经网络模型，准确率达到了97%。
预测攻击（Prediction Attack） —— 在未知挑战下预测PUF响应。这通常是机器学习的活。攻击者收集一部分CRP，训练模型，然后预测未测量的CRP。
逆向工程攻击（Reverse Engineering Attack） —— 提取PUF的物理结构或工艺参数。这类攻击成本高，但一旦成功，所有芯片都会受影响。
侧信道攻击（Side-Channel Attack） —— 通过功耗、电磁辐射、时序等物理泄露来推断PUF响应。嗯，这里要注意，很多PUF设计者只关注PUF单元本身，却忽略了读出电路的信息泄露。

这四类目标不是互斥的。实际上，高级攻击者往往会组合使用。比如先用侧信道攻击缩小CRP搜索空间，再用机器学习做预测。

2.3 攻击场景建模

有了攻击者能力和目标，接下来就是建模了。我建议用三元组 (A, G, E) 来描述一个攻击场景：

A（Attacker）：攻击者能力等级（L1/L2/L3）
G（Goal）：攻击目标（克隆/预测/逆向/侧信道）
E（Environment）：攻击环境约束（时间、成本、隐蔽性要求）

举个例子：

场景1：量产克隆攻击
A = L2（可接触封装，有100个样本）
G = 克隆（生成等效PUF实例）
E = 低成本（单芯片攻击预算<$100），中等时间（1周内完成）

场景2：远程模型攻击
A = L1（仅网络接口）
G = 预测（未知挑战下的响应）
E = 高隐蔽性（不能触发任何异常检测），长时间（可运行数月）

为什么要这么建模？因为不同的 (A, G, E) 组合，对应的防护策略完全不同。我曾经帮一个客户做安全评估，他们坚持要防L3攻击者，但实际产品是消费级IoT设备，攻击者根本不会花几万美金去逆向一颗5块钱的芯片。这就是典型的过度设计。

下面这张图展示了攻击场景建模的核心逻辑：

2.4 安全边界定义

安全边界，说白了就是你承诺在什么条件下PUF是安全的。这不是一个技术参数，而是一个契约——你和客户之间、设计和验证团队之间的契约。

定义安全边界时，我建议至少包含以下五个维度：

维度	典型边界值	说明
CRP空间	≤ 10⁶次查询	超过此数量，模型攻击成功率可能突破阈值
预测成功率	< 55%（随机猜测为50%）	机器学习模型在边界内的最大预测准确率
物理测量精度	> 1mV / 10ps	低于此精度无法提取有效侧信道信息
样本数量	< 20片	攻击者获取的芯片数量上限
环境条件	-40°C ~ 85°C	超出此范围，PUF自身可靠性先于安全性失效

经验之谈： 定义安全边界时，留20%的余量。我曾经在一个项目中把CRP查询上限设为10⁶，结果发现攻击者在9×10⁵次时就已经建立了足够精确的模型。从那以后，我习惯把理论安全边界再收紧20%作为设计目标。

安全边界不是一成不变的。随着攻击技术的进步，今天的边界可能明天就被突破。所以，我建议在芯片中预留安全监控接口——比如记录CRP查询次数、检测异常访问模式等。这样即使边界被突破，你也能及时发现并响应。

最后说一句：安全边界定义得越清晰，验证工作就越有针对性。模糊的安全承诺，往往意味着验证团队不知道要测什么，最后测了一堆无关紧要的指标，真正的漏洞反而被漏掉了。