📚 课程目录第3章可信发布基础

3. 可信发布基础

在OTA可信发布体系中，所有安全机制最终都要回答一个问题：我凭什么相信这次发布的固件、镜像或配置没有被篡改？可信计算正是为回答这个问题而建立的一整套技术体系。它不依赖“看起来正常”这种主观判断，而是通过硬件可信根、逐级度量、密码学证明，把信任从不可篡改的硬件锚点，一层层传递到操作系统、应用乃至OTA发布包。理解可信计算的核心概念与关系，是构建可信发布链路的起点。

一、核心原理：从可信根到信任链

可信计算的基本思想是“信任必须有一个不可再分的起点”。这个起点称为可信根（Root of Trust, RoT）。可信根通常由硬件实现，因为软件可以被替换，而硬件锚点更难被远程篡改。可信根一般拆分为三个职责：

可信度量根（RTM）：负责对后续加载的代码进行完整性度量，通常由固化在芯片中的只读代码承担。
可信存储根（RTS）：负责安全保存度量结果，例如TPM中的平台配置寄存器（PCR）。
可信报告根（RTR）：负责对外提供可信的证明能力，例如用设备私钥对度量结果签名。

有了可信根，系统启动时由RTM先度量下一段代码，把度量值存入RTS，再把控制权交给这段代码；这段代码继续度量再下一段代码。如此逐级传递，就形成了信任链（Chain of Trust）。信任链的本质是：每一级都先验证下一级的完整性，验证通过才移交执行权。只要可信根未被攻破，且每一级验证逻辑正确，整条链上的组件就都可被信任。

关键关系：可信根是“锚点”，信任链是“传递路径”，安全启动是“执行控制”，度量启动是“记录证据”，远程证明是“对外举证”。五者不是并列概念，而是同一信任体系在不同阶段的不同表现。

二、安全启动与度量启动：控制与记录的分工

安全启动（Secure Boot）和度量启动（Measured Boot）经常被混为一谈，但它们在可信发布中承担不同职责。

安全启动的核心是“验证并阻断”。每一级引导程序在加载下一级之前，先用公钥验证其签名。如果签名无效或哈希不匹配，启动流程立即停止。它保证设备不会运行未授权代码，是一种强制性的执行控制。安全启动通常依赖固化的公钥哈希（如PK、KEK、db）作为信任起点。

度量启动的核心是“度量并记录”。它不阻断启动，而是把每一级组件的哈希值扩展到TPM的PCR中，形成一条不可逆的度量日志。度量启动不直接判断好坏，但它为后续的远程证明提供了可验证的证据。换句话说，安全启动负责“不让坏代码跑起来”，度量启动负责“把跑过什么如实记下来”。

对比维度	安全启动	度量启动
核心动作	验证签名，失败则阻断	计算哈希，扩展PCR，不阻断
信任依据	固化公钥/证书	TPM PCR与度量日志
输出结果	允许或拒绝启动	可验证的完整性证据
OTA发布中的作用	防止未签名固件被加载	为远程证明和审计提供依据
典型实现	UEFI Secure Boot、Verified Boot	TPM PCR扩展、IMA度量

在OTA场景中，二者通常配合使用：安全启动确保设备只运行合法固件，度量启动则把当前固件版本、配置、启动参数等记录到PCR中。发布服务器在推送新版本前，可以要求设备先完成远程证明，确认其当前状态可信，再决定是否下发更新包。

三、远程证明：把本地信任变成可验证的远程结论

远程证明（Remote Attestation）是可信计算对外输出的关键能力。它解决的问题是：一台远程设备声称自己运行的是可信固件，我如何验证这句话是真的？

远程证明的基本流程如下：

挑战方（如OTA发布服务器）生成一个随机数nonce，发送给设备。
设备调用TPM，读取当前PCR值，并用可信报告根私钥对“PCR值 + nonce”进行签名，生成Quote。
设备把Quote、PCR值、度量日志（Event Log）一起返回给挑战方。
挑战方验证签名，确认Quote来自真实TPM；再用度量日志重放PCR，确认PCR值与日志一致。
挑战方将PCR值与预期基线比对，判断设备是否处于可信状态。

远程证明的价值在于：它把设备本地的信任链状态，转化为发布服务器可以独立验证的密码学证据。没有远程证明，OTA服务器只能“盲推”；有了远程证明，服务器可以做到“先验证、再发布”。

四、案例场景：OTA发布前的可信准入

假设某车厂要推送一次ECU固件升级。发布平台在推送前执行以下准入检查：

# 伪代码：OTA发布前的远程证明准入
challenge = random_nonce()
quote = device.tpm.quote(pcr_selection=[0,1,2,7], nonce=challenge)
verify(quote.signature, tpm_pubkey)
replay_pcr(quote.event_log)
if quote.pcr[0] != expected_bootloader_hash:
    reject("引导程序度量值异常")
if quote.pcr[7] != expected_secureboot_policy:
    reject("安全启动策略被篡改")
approve_update(device_id, firmware_version)

这个流程中，安全启动保证了设备不会加载未签名引导程序，度量启动把引导程序哈希写入PCR[0]，远程证明把PCR值签名后发给发布平台。发布平台验证通过后，才允许下发新固件。整条链路中，可信根是起点，信任链是路径，安全启动是闸门，度量启动是账本，远程证明是举证。

五、常见误区与复盘

误区一：把安全启动等同于可信启动。安全启动只保证“验证通过才运行”，但不记录运行过什么。没有度量启动，远程证明就没有证据来源。

误区二：认为有了TPM就自动可信。TPM只是可信存储根和报告根，如果RTM被替换、度量逻辑被绕过，PCR值同样不可信。可信根必须从硬件固化代码开始。

误区三：远程证明只看签名不看日志。签名只证明Quote来自真实TPM，不证明PCR值对应真实运行状态。必须结合度量日志重放，才能发现“PCR正确但日志被裁剪”的攻击。

误区四：忽略PCR基线管理。远程证明的比对基线需要随固件版本更新而维护。基线过期会导致合法设备被误判，基线过宽则会让攻击者有机可乘。

复盘来看，可信发布不是单一技术，而是一条从硬件可信根出发、经过安全启动和度量启动、最终由远程证明对外举证的完整信任链。OTA发布系统只有把这条链接入发布准入流程，才能真正做到“不可信不发布、不可信不升级”。