一、启动校验概述

启动校验，说白了就是设备在开机时做的一次「身份核查」。

你按下电源键，CPU 开始执行第一行代码。但问题来了——你怎么知道这段代码是可信的？有没有被人动过手脚？

启动校验就是回答这个问题的机制。它从硬件复位开始，逐级验证每一段即将执行的固件或软件的完整性与合法性。只有通过校验的代码才能继续运行，否则系统就会停下来，拒绝启动。

我个人习惯把启动校验比作「安检通道」：

每一关都通过，系统才认为自己是「干净」的，可以正常启动。

核心定义：启动校验（Secure Boot / Verified Boot）是一种从硬件信任根出发，逐层验证固件和软件完整性的安全机制，确保设备只运行经过授权的代码。

你可能会问：不加启动校验会怎样？

嗯，我在项目中遇到过真实案例。某款 IoT 设备没有做启动校验，攻击者通过物理接口刷入了修改过的固件。这个固件表面功能正常，但后台偷偷把设备变成了 DDoS 僵尸节点。等我们发现时，已经有上千台设备被控了。

启动校验要解决的核心问题有三个：

你想想看，如果连启动阶段都不设防，那后续所有的安全措施——应用沙箱、数据加密、访问控制——都建立在沙滩上。地基不稳，楼盖得再高也没用。

我曾经踩过的坑：某次项目为了赶进度，团队决定「先不上启动校验，后面再补」。结果产品量产三个月后，网上就出现了第三方修改版固件，用户刷完后设备变砖，售后投诉暴增。后来我们花了整整一个迭代周期才把启动校验补上，成本比一开始就做高了至少三倍。

启动校验有个关键前提：你得有一个「绝对可信」的起点。这个起点就是信任根（Root of Trust，RoT）。

信任根是什么？它是系统中永远不被信任链之外任何实体验证的组件。换句话说，它是信任的「原点」——我们无条件相信它，然后由它去验证下一级，下一级再验证下下一级，形成一条信任链。

我习惯用「锚」来理解信任根：

举个例子，ARM 平台的信任根架构是这样的：

Boot ROM（硬件固化，不可改）
  └─ 验证 → Bootloader（Stage 1）
       └─ 验证 → Bootloader（Stage 2）
            └─ 验证 → 操作系统内核
                 └─ 验证 → 系统服务 & 应用

每一级都包含下一级的公钥或哈希值，形成一条完整的信任链。只要信任根不被攻破，整条链就是安全的。

一个小技巧：在实际项目中，我建议把信任根的公钥存储在芯片的一次性可编程（OTP）存储器中。这样即使攻击者拿到了芯片物理访问权限，也无法修改信任根。我在一个金融支付终端项目里就是这么做的，通过了 PCI PTS 认证。

这里要特别强调一点：信任根不一定是硬件。在虚拟化环境或某些轻量级场景下，也可以使用软件信任根。但软件信任根的安全性依赖于它所在环境的隔离程度——如果攻击者能修改软件信任根本身，那整个信任链就崩塌了。

所以，我个人更倾向于硬件信任根。它虽然成本高一些，但安全收益是实打实的。

为了让你更直观地理解，我画了一张信任链的流程图：

这张图展示了信任链的核心逻辑：从硬件信任根出发，每一级只信任上一级验证过的代码，然后由这段代码去验证下一级。只要信任根不被攻破，整条链就是安全的。

关键原则：信任链的安全性取决于最薄弱的环节。如果信任根被攻破，整条链都会失效。所以，保护信任根是启动校验中最重要的事。

不同平台和场景下，启动校验的实现方式略有不同。我整理了几种常见的方案：

方案	信任根类型	适用场景	安全等级
UEFI Secure Boot	硬件（UEFI 固件）	PC、服务器	中
ARM TrustZone + Boot ROM	硬件（SoC 固化）	移动设备、IoT	高
Android Verified Boot (AVB)	硬件（Bootloader）	Android 设备	中高
TPM 度量启动	硬件（TPM 芯片）	企业级设备	高
软件信任根（如 U-Boot）	软件	嵌入式 Linux	低中

我个人在嵌入式项目中用得最多的是 ARM TrustZone + Boot ROM 方案。它把信任根固化在芯片内部，攻击者即使拆了芯片也无法修改。配合 OTP 存储公钥，安全性非常可靠。

选型建议：如果你的产品需要过安全认证（如 PCI、FIPS、Common Criteria），优先选硬件信任根方案。认证机构对软件信任根的审查非常严格，而且往往要求额外的物理防护措施。

好了，启动校验的基本概念就讲到这里。记住三个关键词：信任根、信任链、逐级验证。后面的章节我们会深入每个环节的具体实现和密钥管理策略。