一、威胁模型
攻击者可能篡改固件镜像、降级到含漏洞的旧版、或在启动链中插入恶意 Bootloader。安全启动链通过硬件信任根（ROM Code、eFuse 公钥哈希）逐级验证下一阶段镜像签名，配合单调递增的安全版本号（anti-rollback）阻止降级攻击。达希设备管理平台在云端维护与设备 eFuse/OTP 对齐的公钥与版本策略，确保 OTA 下发包与终端策略一致。
威胁模型还应覆盖物理接触场景：调试口未熔丝、JTAG 未禁用可能导致本地刷写绕过云端策略。企业需在 BOM 与产线工艺上与安全启动策略一致，达希可在方案评审阶段提供检查清单，并与 渗透测试 范围对齐。
二、平台侧职责
平台只分发与 签名流水线 产出的哈希、签名元数据匹配的制品。发布前校验安全版本单调性，拒绝低于设备当前 counter 的包。对多签名算法（RSA/ECC/国密）建立白名单，与设备编译选项同步。
三、双分区与回滚
A/B 分区 在安全链中仍需谨慎：回滚到的旧分区若安全版本较低，应被防回滚机制拒绝。达希建议为“紧急热修复”单独提升安全版本而非简单版本号回退。
四、密钥与供应链
签名私钥存放 HSM，分角色分权；灾难恢复密钥需离线保管。与发布合规流程结合，记录谁触发了哪次签名，并可在 合规审计追踪 中留痕。
五、测试矩阵
实验室需覆盖：签名错误包、截断包、过期证书、时钟回拨、跨区密钥轮换。与 灰度 同步验证安全边界。
六、合规映射
部分行业检查会要求展示启动链图与密钥管理政策，材料可从 合规审计 导出。
审计材料建议包含：公钥指纹列表、安全版本号策略说明、历史密钥轮换记录、异常启动失败统计。与 监管要求映射 表交叉引用后，可显著缩短检查访谈时间。
七、与 OTA 编排的衔接
平台在下发任务前应校验：目标包签名算法是否在设备白名单内、安全版本是否单调递增、是否与当前硬件修订匹配。批量 OTA 失败码应区分 SECURITY_VERSION_REJECT、SIGNATURE_FAIL 等，便于 工单 精准分派。紧急热修若需例外流程，必须经过双人审批并限时关闭。
八、常见实施问题
常见问题包括：开发板与量产 eFuse 状态不一致导致「本地能升、量产不能升」；双分区切换脚本未与安全计数器协同；测试证书误入量产线。达希建议分环境隔离签名密钥与制品仓库，并在产线 SOP 中嵌入自动校验步骤。
九、总结
安全启动链是 OTA 信任的终点锚点。达希设备管理平台连接签名流水线、版本策略与现场设备状态，减少「云端可信、终端不可信」的断层。延伸阅读：固件 OTA、设备信任根。