3. 安全威胁模型
固件升级通道是设备生命周期中权限最高、影响最广的一条数据通路。它一旦被攻破，攻击者获得的不是某个应用的临时权限，而是设备启动链、可信根乃至整机行为的长期控制权。因此，在讨论签名、加密、回滚之前，必须先回答一个更基础的问题：谁能在升级链路的哪个位置、以什么方式、达成什么破坏效果？这就是威胁模型要解决的问题。威胁模型不是安全清单，而是一张"攻击面地图"，它决定了后续每一道防护措施的必要性和优先级。
一、固件升级的五类核心攻击面
固件升级链路通常包含五个关键环节：镜像生成与签名、分发服务器、传输通道、设备端接收与校验、写入与启动。攻击者可以在任一环节切入，形成五类典型威胁。
- 篡改（Tampering）：攻击者修改固件镜像内容，植入后门或恶意逻辑。若签名校验缺失或校验逻辑可被绕过（如校验后再修改内存中的镜像），篡改即可生效。典型场景是攻击者替换 OTA 包中的某个分区，而设备只校验了包头。
- 降级（Downgrade / Rollback Attack）：攻击者将设备刷回存在已知漏洞的旧版本固件，再利用该漏洞提权。降级攻击不破坏签名，而是利用"旧版本签名依然合法"这一事实。防护核心是防回滚计数器（Monotonic Counter）与最低版本策略。
- 中间人（MITM）：攻击者在设备与升级服务器之间劫持连接，替换或注入固件包。若传输层未做双向认证，或设备盲目信任代理，MITM 可同时完成篡改与降级。
- 重放（Replay）：攻击者截获一个合法的旧升级包，在后续时间重复投递。设备若只验证签名而不验证新鲜度（nonce、时间戳、序列号），就会接受重放包，效果等同于降级。
- 供应链攻击（Supply Chain）：攻击点前移到构建、签名、CI/CD 或第三方组件。攻击者污染构建环境、窃取签名密钥、或在依赖库中植入恶意代码，使"合法签名"的固件本身就带有后门。这类攻击最难检测，因为签名验证会通过。
关键认知：签名只能证明"镜像来自持有私钥的一方"，不能证明"镜像内容安全"、不能证明"版本足够新"、也不能证明"传输过程未被重放"。因此，防篡改、防降级、防重放、防 MITM、防供应链必须分别设计，不能互相替代。
二、威胁建模方法与 STRIDE 实例
威胁建模的通用流程是：划定范围 → 分解系统 → 识别威胁 → 评估风险 → 制定缓解措施。在固件升级场景中，推荐使用数据流图（DFD）描述升级链路，再对每个数据流和存储点套用 STRIDE 分类，逐项检查。
STRIDE 将威胁分为六类：Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。下表给出固件升级链路的 STRIDE 实例与对应缓解方向。
| STRIDE 类别 | 固件升级场景实例 | 缓解方向 |
|---|---|---|
| Spoofing 仿冒 | 伪造升级服务器，设备连接恶意 OTA 端点 | 服务器证书双向认证、设备身份证书 |
| Tampering 篡改 | 修改镜像分区内容或元数据 | 镜像签名 + 哈希校验 + 安全启动链 |
| Repudiation 抵赖 | 升级失败后无法追溯是谁下发了哪个版本 | 升级日志签名、审计记录、版本溯源 |
| Information Disclosure 信息泄露 | 固件包被截获，泄露密钥或调试接口 | 传输加密、镜像加密、密钥隔离存储 |
| Denial of Service 拒绝服务 | 反复投递损坏包，导致设备无法启动 | A/B 分区、看门狗、回滚机制 |
| Elevation of Privilege 权限提升 | 降级到旧版漏洞固件后提权 | 防回滚计数器、最低版本策略 |
三、升级链路攻击面可视化
下图把固件从构建到启动的全链路展开，标出五类攻击的切入位置与对应防护点，便于在评审时逐点核对。
四、案例与误区复盘
案例：只做签名校验的 OTA 系统。某设备在升级时验证了镜像签名，但未校验版本号，也未使用防回滚计数器。攻击者截获了半年前的一个合法旧包，通过 MITM 重放给设备。设备验签通过，成功刷入旧版本，随后利用旧版本中已修复的调试接口漏洞获取 root。复盘结论：签名解决了"篡改"，但没有解决"降级"和"重放"，三者必须分别防护。
常见误区一：把签名当成万能防护。签名只保证来源与完整性，不保证新鲜度和内容安全。供应链攻击产生的恶意镜像同样拥有合法签名。
常见误区二：忽略设备端校验逻辑本身的可攻击性。如果校验在写入之后进行，或校验结果可被跳过，攻击者可以绕过校验。校验必须发生在写入之前，且校验逻辑应位于不可篡改的可信执行环境中。
常见误区三：威胁建模只做一次。升级协议、依赖库、服务器架构都会变化，威胁模型需要随版本迭代更新。建议在每次重大升级功能变更时重新评审攻击面。
实操建议：在威胁建模评审中，对每个数据流逐一提问——"谁能伪造它？谁能修改它？谁能重放它？谁能读到它？谁能让它不可用？谁能借它提权？"这六个问题正好对应 STRIDE，能快速暴露遗漏的防护点。
# 升级包元数据示例（防降级与防重放关键字段）
package:
version: 2.4.1
min_allowed_version: 2.3.0 # 低于此版本拒绝刷入
anti_rollback_counter: 1042 # 必须大于设备当前计数器
nonce: "a7f3c9e1b2d4" # 服务端下发，一次性有效
issued_at: "2025-03-18T10:22:00Z"
signature: "MEUCIQ...base64..." # 对以上字段整体签名
威胁模型的价值在于把"安全"这个模糊目标拆解为可验证的具体条目。只有先看清攻击面，后续的签名体系、防回滚设计、安全启动链和回滚策略才能各就各位，形成真正互补的纵深防御。