1. 安全启动与固件升级工程导论

在嵌入式产品中，固件是设备行为的最终决定者。谁能改写固件，谁就 фактически 掌握了设备。安全启动（Secure Boot）与固件升级（Firmware Update）正是围绕"固件可信"这一核心命题展开的两项工程能力：前者保证设备每次上电只运行经过授权的固件，后者保证固件在生命周期内可以被安全地替换与修复。二者不是彼此独立的功能，而是一条完整信任链的两端——安全启动建立信任，安全升级延续信任。

一、核心概念：从信任根到信任链

要理解安全启动，必须先理解三个层层递进的概念。

信任根（Root of Trust, RoT）是整个安全体系的起点，它必须是一段"不可被篡改、且被无条件信任"的代码或数据。在 Microchip 的架构中，信任根通常由芯片出厂时固化在不可擦写区域（如 Boot ROM 或硬件安全模块中的不可变引导代码）实现，配合一次性可编程（OTP）熔丝中烧录的公钥哈希，构成硬件级的信任锚点。信任根之所以"可信"，不是因为它被验证过，而是因为它无法被修改——这是整个体系唯一不需要证明的假设。

信任链（Chain of Trust）是把信任从根逐级传递下去的过程。信任根验证第一级引导程序（如 MCUboot 或厂商 Bootloader）的签名，第一级引导程序验证第二级引导程序或应用固件，应用固件再验证其加载的资源或外设固件。每一级在把控制权交给下一级之前，都必须先完成对下一级的密码学验证。只要链条中任何一环验证失败，启动流程就应中止或进入受限的安全恢复模式。

安全启动就是这条信任链在每次上电时的执行过程；安全固件升级则是把新的、已签名的固件镜像写入设备，并保证写入过程本身不被降级攻击、回滚攻击或中间人篡改。二者共享同一套密钥体系与验证逻辑，因此工程上通常统一设计。

二、威胁模型：我们到底在防谁

安全启动与升级的工程目标，完全由威胁模型决定。脱离威胁模型谈安全，只会得到过度设计或防护不足两种结果。在嵌入式固件场景中，需要重点考虑的攻击面包括：

• 固件篡改：攻击者通过调试接口、物理访问或通信通道替换设备中的固件镜像，植入恶意代码。防御手段是签名验证——设备只运行由可信私钥签名的镜像。
• 回滚攻击：攻击者把设备降级到已知存在漏洞的旧版本固件，再利用该漏洞实施进一步攻击。防御手段是防回滚计数器（Anti-Rollback Counter），通常存储在 OTP 或受保护的非易失存储中，每次升级只增不减。
• 中间人攻击：在 OTA 或远程升级通道中，攻击者截获并替换固件包。防御手段是端到端签名验证，传输层加密（如 TLS）只是补充，不能替代镜像本身的签名。
• 密钥泄露：签名私钥一旦泄露，整个信任体系崩塌。工程上必须使用硬件安全模块（HSM）保护私钥，并设计密钥轮换与吊销机制。

需要特别注意的是，安全启动并不防御"设备被物理拆解后直接读取 Flash 内容"这类机密性攻击——那是安全存储与加密引擎的职责。安全启动解决的是完整性与真实性问题：设备运行的固件，是不是我们签发的、未被修改的那一份。

三、工程目标与典型应用场景

从工程落地角度看，一套可交付的安全启动与升级方案需要同时满足以下目标：

• 可验证性：每一级固件在运行前都经过密码学验证，验证失败有明确的降级策略（如进入恢复模式、保持旧版本运行）。
• 可升级性：支持现场升级，且升级过程断电、断网等异常情况下不会导致设备"变砖"。这通常通过双区（A/B 分区）或外部 Flash 暂存实现。
• 可制造性：产线烧录流程中，密钥注入、OTP 熔丝烧写、初始固件签名必须可重复、可审计。
• 可维护性：密钥轮换、证书吊销、版本回退策略在设备生命周期内可操作。

典型应用场景包括：工业控制器需要防止现场固件被恶意替换；汽车 ECU 需要满足 ISO 21434 的网络安全要求；智能电表需要支持远程安全升级并防止电费篡改；医疗设备需要保证固件版本可追溯且不可降级到未认证版本。这些场景的共同点是：设备部署后难以物理回收，一旦固件被篡改，后果由厂商和用户共同承担。