3. 制造安全威胁建模与风险分析
密钥注入环节是设备身份可信的起点，也是制造安全中最容易被“绕过”的一环。很多团队把注意力放在云端密钥管理和设备端加密算法上，却忽略了密钥在产线上从生成到写入芯片的这段物理与逻辑路径。本节围绕密钥注入环节，建立一套可落地的威胁建模与风险分析方法：先识别资产，再梳理威胁来源与攻击面，然后用 STRIDE 和攻击树把风险结构化，最后结合产线真实风险场景给出判断依据。
一、资产识别：不只是“密钥本身”
在密钥注入场景中，资产识别常被简化为“密钥”，但真正需要保护的资产至少包括四类。第一类是密钥材料：设备私钥、对称密钥、根密钥、会话密钥，以及它们的派生种子。第二类是密钥的可用状态：密钥是否已注入、是否已激活、是否已绑定设备唯一标识、是否已锁定不可导出。第三类是注入过程数据：注入工单、密钥索引、设备序列号与密钥的绑定关系、注入日志、操作员身份与时间戳。第四类是注入基础设施：密钥注入服务器、HSM、产线工控机、烧录器、测试夹具、固件与注入脚本。
资产识别的关键是给每个资产标注三个属性：机密性（泄露后果）、完整性（被篡改后果）、可用性（中断后果）。例如，设备私钥泄露会导致设备身份被克隆；注入日志被篡改会导致无法追溯哪台设备被注入了错误密钥；注入服务器不可用会导致整条产线停线。这三个属性的差异，直接决定后续威胁建模的优先级。
二、威胁来源与攻击面分析
密钥注入环节的威胁来源可分为四类：外部攻击者（通过供应链、代工厂、维修渠道接触产线）、内部恶意人员（操作员、维护工程师、临时工）、内部非恶意人员（误操作、配置错误、流程跳过）、环境与系统故障（断电、网络抖动、HSM 故障、固件缺陷）。这四类来源对应的攻击面并不相同。
攻击面可以从“数据流经的节点”来梳理。典型密钥注入数据流为：密钥管理系统生成密钥 → HSM 保护导出 → 注入服务器接收并缓存 → 工控机/烧录器读取 → 通过调试接口或安全通道写入芯片 → 芯片返回确认 → 日志回传。每一个节点都是一个攻击面：密钥管理系统可能被越权访问；HSM 导出接口可能被滥用；注入服务器内存可能被转储；工控机可能被植入恶意脚本；调试接口可能被旁路；日志回传可能被篡改或丢失。
三、STRIDE 方法在密钥注入环节的落地
STRIDE 是微软提出的威胁分类框架，包含六类：Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。在密钥注入场景中，每一类都有具体对应。
| STRIDE 类别 | 密钥注入环节的具体威胁 | 典型后果 |
|---|---|---|
| 仿冒 | 伪造注入服务器身份，向烧录器下发假密钥 | 设备被注入攻击者可控密钥 |
| 篡改 | 修改注入脚本或固件，替换密钥索引 | 密钥与设备绑定关系错乱 |
| 抵赖 | 注入日志缺失或可被删除，操作员否认操作 | 无法追溯责任，审计失效 |
| 信息泄露 | 注入服务器内存转储、调试口回读密钥 | 密钥批量泄露，设备可被克隆 |
| 拒绝服务 | HSM 故障、网络中断导致注入停线 | 产线停摆，交付延期 |
| 权限提升 | 操作员越权访问密钥管理接口 | 可导出或覆盖高价值密钥 |
使用 STRIDE 时，建议按数据流逐节点过一遍，而不是只做一次全局分类。例如在“注入服务器”节点，重点看信息泄露和权限提升；在“烧录器”节点，重点看篡改和仿冒；在“日志回传”节点，重点看抵赖和篡改。这样得到的威胁列表更贴近实际，也更容易映射到具体控制措施。
四、攻击树：把“怎么被攻破”画出来
攻击树适合表达“攻击者要达到某个目标，有哪些路径”。以“获取设备私钥”为根目标，可以拆出三条主要路径：路径 A 从注入服务器内存转储获取明文密钥；路径 B 通过调试接口回读芯片内密钥；路径 C 伪造注入服务器向烧录器下发攻击者密钥。每条路径再继续分解为具体条件，例如路径 A 需要“获得服务器登录权限”且“密钥在内存中以明文存在”且“未启用内存加密或进程隔离”。
攻击树的价值在于：它把“风险”从一句“密钥可能泄露”变成可检查的条件集合。每个叶子节点都可以对应一个控制措施：内存加密、调试口熔断、双向证书认证、注入脚本签名、日志上链等。评估时，可以给每个叶子节点标注“利用难度”和“现有控制是否覆盖”，从而决定优先补哪一块。
五、产线真实风险案例与判断依据
以下场景来自制造安全实践中常见的风险模式，参数为示例性假设，用于说明判断逻辑。
案例一：测试密钥混入量产。某产线在试产阶段使用测试密钥，正式量产时未彻底清除测试密钥配置。结果前 200 台设备被注入测试密钥，且测试密钥与量产密钥共用同一密钥索引。判断依据：注入日志中密钥索引字段与量产工单不一致；设备首次上线时云端校验失败。控制措施：测试密钥与量产密钥使用不同索引段，注入前强制校验工单与密钥索引的绑定关系。
案例二：调试接口未熔断。某批次设备在注入完成后未及时熔断调试接口，攻击者通过调试口回读密钥。判断依据：注入后芯片安全状态寄存器未置位；产线抽检时发现调试口仍可访问。控制措施：注入完成后立即执行熔断指令，并在日志中记录熔断状态；抽检时读取安全状态寄存器确认。
案例三：注入服务器缓存未清理。注入服务器为提高效率缓存了密钥明文，且缓存目录权限过宽。判断依据：服务器上存在未加密的临时密钥文件；操作员账户可读取该目录。控制措施：密钥仅在 HSM 内以密文形式存在，注入服务器不落盘明文；缓存使用内存加密并设置短生命周期。
六、风险分析的最小可执行流程
如果要在一条产线上快速开展密钥注入威胁建模，可以按以下顺序执行，不需要一次做全，但每一步都要留下可检查的记录。
- 画数据流：从密钥生成到芯片写入，标出每个节点、接口和存储位置。
- 标资产：在每个节点上标注涉及的密钥材料、状态数据、日志和基础设施。
- 过 STRIDE：逐节点填写六类威胁，形成威胁清单。
- 建攻击树：选 1～2 个最高价值目标，拆出攻击路径和叶子条件。
- 定控制：每个叶子条件对应一个控制措施，标注“已覆盖/部分覆盖/未覆盖”。
- 留证据：注入日志、熔断状态、密钥索引绑定关系、操作员身份，必须可追溯、可验证。
判断风险分析是否有效，不看文档厚度，而看三个问题能否回答：密钥在哪个节点以明文存在过？谁能接触到这个节点？如果这个节点被攻破，能否从日志中发现并追溯到具体设备？如果这三个问题都有明确答案，密钥注入环节的威胁建模才算真正落地。