1. nRF54安全启动全景

在 Nordic 的 nRF54 系列上，安全启动不是某个单独开关，而是一条从上电复位开始、逐级验证、最终把控制权交给应用固件的信任链。理解这条链的关键，是把它看成“每一级只信任下一级的哈希或签名，而不是无条件信任下一级的内容”。nRF54 的安全启动建立在 Arm TrustZone-M、安全存储（KMU/密钥管理单元）、受保护的引导区以及 Nordic 提供的固件验证机制之上，最终形成从不可变引导代码到可更新应用的安全过渡。

先看整体定位。nRF54 属于 Cortex-M33 内核，带 TrustZone-M，因此天然区分安全态（Secure）与非安全态（Non-Secure）。安全启动通常运行在安全态，负责验证非安全态应用镜像的完整性与真实性；而 nRF52 系列（如 nRF52840）是 Cortex-M4，没有 TrustZone，安全启动更多依赖引导区加 CRC/哈希校验、外挂安全元件或自定义方案。这个差异决定了 nRF54 的信任链可以“内建”在芯片的安全域里，而 nRF52 往往需要额外硬件或软件约束来补足。

下面这张图给出从上电复位到应用跳转的完整信任链结构，包含各阶段的执行域、验证对象与关键组件。

从图中可以看到，信任链的起点是芯片内不可变的引导代码，它持有引导加载器公钥的哈希。上电后，Boot ROM 先运行，计算引导加载器镜像的哈希并与固化值比对；只有匹配，才把控制权交给引导加载器。引导加载器再使用 KMU 中的公钥验证应用镜像的 ECDSA 签名，同时检查版本号与回滚保护计数器，防止降级攻击。验证通过后，通过 TrustZone 配置把非安全态入口地址交给应用，完成跳转。

与 nRF52 的差异，核心在三点。第一，nRF54 有 TrustZone-M，安全启动代码可以运行在安全态，应用运行在非安全态，二者通过 SAU 和 MPC 隔离，即使应用被攻破也难以篡改引导区；nRF52 没有硬件隔离，引导区与应用同处一个地址空间，防护依赖 MPU 和软件约束。第二，nRF54 的 KMU 支持密钥不可读出、仅用于签名验证，密钥材料不必以明文形式出现在 Flash 中；nRF52 通常需要把公钥或哈希放在 Flash，配合外挂安全芯片才能达到类似强度。第三，nRF54 的引导流程与 Nordic 的固件更新机制（如 MCUboot 或 Nordic 安全启动方案）结合更紧密，支持安全固件更新与回滚保护；nRF52 虽然也能用 MCUboot，但缺少 TrustZone 的硬件隔离，安全边界更依赖软件实现。

实际工程中，配置安全启动通常需要以下步骤：在 KMU 中写入或派生公钥；在引导区配置安全启动使能位与回滚保护计数器；编译应用镜像并生成签名；把签名和镜像一起烧录到指定 Flash 区域；最后通过调试接口观察启动日志或使用 Nordic 工具读取启动状态。判断是否成功，可以看应用是否正常跳转、安全启动状态寄存器是否置位、以及尝试篡改镜像后是否被拒绝启动。

示例：应用镜像签名与验证流程（伪代码）
1. 生成密钥对：ecdsa_keygen(P-256) → priv, pub
2. 计算镜像哈希：h = SHA256(app.bin)
3. 生成签名：sig = ECDSA_sign(priv, h)
4. 烧录：app.bin + sig + pub 到 Flash
5. 启动时：h' = SHA256(app.bin)
6. 验证：ECDSA_verify(pub, h', sig) == true ?
7. 通过 → 跳转；失败 → 停止启动

需要强调的是，安全启动的信任链一旦断裂，后续所有安全机制都形同虚设。因此，根信任必须固化在不可修改的区域，密钥必须受到硬件保护，回滚保护必须单调递增。nRF54 把这些能力集成在芯片内部，使开发者能够以更少的额外器件实现完整的信任链；而 nRF52 方案则需要在设计初期就规划好外挂安全元件或软件防护策略。理解这条链的每一级验证对象与失败处理，是后续密钥工程与安全启动配置的基础。