📚 课程目录第1章固件度量概述

1、固件度量概述：什么是固件度量、度量在安全启动中的作用、度量 vs 认证 vs 授权

各位好，欢迎来到《固件度量深度剖析指南》的第一章。

咱们开门见山。固件度量，说白了就是给固件做一次「体检」——在它运行之前，先把它里里外外检查一遍，记录下它的「健康状态」。这个状态不是简单的「好」或「坏」，而是一串精确的哈希值，代表固件此刻的完整模样。

1.1 什么是固件度量

我习惯把固件度量理解成「给固件拍一张身份证照片」。这张照片记录了固件在某个时刻的精确指纹——通常是 SHA-256 或 SHA-384 哈希值。你想想看，如果固件被人动过手脚，哪怕只改了一个字节，拍出来的照片就完全不一样了。

核心定义：固件度量是指在固件执行之前或执行过程中，对其代码、配置、数据等关键内容进行哈希计算，并将结果安全存储的过程。这个结果被称为「度量值」或「测量值」。

度量不是一次性的。它通常发生在启动链的每个环节：从最早的不可变代码（比如 Boot ROM）开始，逐级度量下一级固件，形成一条完整的信任链。我在做 TPM 项目时遇到过一个问题——有人只度量了主固件，却忽略了配置分区。结果攻击者改了配置，系统照样认为固件是「干净」的。嗯，这个坑我踩过，所以提醒大家：度量要覆盖所有可执行内容和关键配置。

1.2 度量在安全启动中的作用

安全启动（Secure Boot）的核心逻辑其实很简单：先度量，再验证，最后执行。度量是安全启动的「眼睛」，没有它，验证就是盲人摸象。

咱们来看一个典型的度量流程：

Boot ROM (不可变)
  ↓ 度量 Bootloader 的哈希值
Bootloader (度量值存储在 TPM PCR[0])
  ↓ 度量 OS Kernel 的哈希值
OS Kernel (度量值存储在 TPM PCR[2])
  ↓ 度量关键驱动和服务的哈希值
运行环境 (度量值存储在 TPM PCR[4-7])

为什么会这样设计？因为信任不能凭空产生，它需要一个起点。这个起点就是 Boot ROM，它是硬件固化的，无法篡改。从它开始，每一级都度量下一级，然后把度量值存到 TPM 的 PCR（平台配置寄存器）里。这些 PCR 寄存器有个特点：只能扩展（extend），不能重置（除非硬件复位）。

个人经验：我曾经调试过一个诡异的问题——系统偶尔启动失败，但重启后又好了。查了三天，最后发现是 PCR 扩展顺序出了问题。某个驱动在度量之前就被加载了，导致 PCR 值永远对不上。所以，度量的顺序和时机，一定要严格定义，不能有半点含糊。

度量在安全启动中的具体作用，我归纳为三点：

检测篡改：任何对固件的修改都会导致度量值变化，系统可以立即发现异常。
建立信任链：从不可变根开始，逐级度量，形成一条可追溯的信任链条。
提供远程证明依据：度量值可以被远程服务器读取，用来验证设备是否处于可信状态。

1.3 度量 vs 认证 vs 授权

这三个概念经常被混在一起，但它们的职责完全不同。我画了一张图来帮大家理清关系：

这张图很直观。度量、认证、授权是三个递进的关系。度量是第一步，它只关心「固件是不是原来的样子」。认证是第二步，它关心「这个固件是谁签发的」。授权是第三步，它决定「这个固件能做什么事」。

我整理了一个表格，方便大家对比：

维度	度量	认证	授权
核心问题	固件是否被篡改？	固件来源是否可信？	固件能否执行操作？
技术手段	哈希计算（SHA-256等）	数字签名（RSA/ECC）	访问控制策略（ACL）
存储位置	TPM PCR寄存器	证书链、公钥	策略数据库
典型场景	安全启动度量阶段	固件签名验证	是否允许加载驱动
失败后果	启动中断或告警	拒绝执行	操作被阻止

注意：很多人以为度量就是认证，这是个大坑。度量只告诉你「固件没变」，但不告诉你「这个固件是好人写的」。认证才负责确认来源。我见过一个案例：某设备度量通过了，但固件用的是过期证书，结果被攻击者利用。所以，度量 + 认证必须配合使用，缺一不可。

举个实际例子。假设你下载了一个固件更新包：

度量：计算更新包的哈希值，跟官方公布的比对。一致说明包没被篡改。
认证：验证更新包的数字签名，确认它确实来自厂商，不是伪造的。
授权：检查当前设备是否有权限安装这个更新（比如版本号、区域限制等）。

你看，三步缺一不可。度量是基础，认证是保障，授权是最终决策。我在做 IoT 设备固件时，经常看到有人只做了度量就以为安全了——结果被中间人攻击替换了固件包，度量值虽然对得上，但包本身是恶意的。嗯，这就是没做认证的后果。

最后说一句：度量本身不提供保护，它只提供「可见性」。就像监控摄像头，它不阻止犯罪，但能记录犯罪过程。真正的安全，需要度量、认证、授权三者协同工作。