验证启动功能旨在保证设备软件（从硬件信任根直到系统分区）的完整性。在启动过程中，无论是在每个阶段，都会在进入下一个阶段之前先验证下一个阶段的完整性和真实性。

当用户对软件进行了不应进行的更改时，可以使用该功能向他们发出警告，比如当用户获得一台二手设备后告知他们软件经受了不应进行的更改。此外，该功能还可以提供进行远程认证时使用的其他设备完整性信号。该功能再加上加密功能以及可信执行环境 (TEE) 信任根绑定功能，三者共同为用户数据添加了另一道防范恶意系统软件的保护屏障。

如果在任意阶段验证失败，用户都会收到醒目的通知。

词汇表

概述

除了设备状态（在设备中已存在，用于控制引导加载程序是否允许刷写新软件）外，验证启动功能还引入了启动状态的概念，以便指明设备完整性状态。

级别

验证启动有两个实现级别。根据设备在多大程度上实现此规范，这两个级别的定义如下：

A 级会实现具有完整信任链（直到已验证的分区）的验证启动。也就是说，这种级别的实现支持“已锁定”设备状态，以及“绿色”和“红色”启动状态。

B 级会实现 A 级实现的内容，并且还支持“已解锁”设备状态和“橙色”启动状态。

验证密钥

引导加载程序的完整性始终都是使用硬件信任根进行验证。在验证启动分区和恢复分区时，引导加载程序可以使用原始设备制造商 (OEM) 密钥（该密钥是固定不变的）。它始终会先尝试使用原始设备制造商 (OEM) 密钥验证启动分区，并且仅当此项验证失败时，才会尝试使用其他可能的密钥进行验证。

在 B 级实现中，当设备处于“已解锁”状态时，用户可以刷写使用其他密钥签名的软件。如果设备随后进入“已锁定”状态，并且使用原始设备制造商 (OEM) 密钥进行的验证失败了，引导加载程序会尝试使用分区签名中嵌入的证书进行验证。不过，在使用通过原始设备制造商 (OEM) 密钥以外的任何其他凭据签名的分区时，会收到通知或警告，如下文所述。

启动状态

在每次尝试启动时，已验证的设备最终都将启动到以下 4 种状态之一：

• 绿色：表示实现了从引导加载程序到已验证分区的完整信任链，其中包括引导加载程序、启动分区和所有已验证的分区。
• 黄色：表示已使用嵌入的证书验证启动分区，并且签名有效。在允许启动过程继续之前，引导加载程序会显示一条警告以及公钥的指纹。
• 橙色：表示可以随意修改设备。设备完整性由用户进行带外验证。在允许启动过程继续之前，引导加载程序会向用户显示一条警告。
• 红色：表示设备验证失败了。引导加载程序会显示一条警告并停止启动过程。

此外，还会以完全相同的方式验证恢复分区。

设备状态

可能的设备状态以及它们与 4 种验证启动状态的关系如下：

1. 已锁定：表示无法刷写设备。在每次尝试启动时，“已锁定”设备都会启动到“绿色”、“黄色”或“红色”状态。
2. 已解锁：表示可以随意刷写设备，不需要进行验证。“已解锁”设备始终会启动到“橙色”启动状态。

图 1. 验证启动流程

详细设计

要实现完整的信任链，需要启动分区（负责装载更多分区）上的引导加载程序和软件的支持。验证元数据也会附加到系统分区，并附加到应接受完整性验证的所有其他分区。

引导加载程序要求

引导加载程序是设备状态的监护者，负责初始化 TEE 以及绑定其信任根。

最重要的是，引导加载程序会在将执行工作移交给内核之前先验证启动分区和/或恢复分区的完整性，并会显示启动状态部分中指定的警告。

更改设备状态

要更改设备状态，需要使用 fastboot flashing [unlock | lock] 命令。为了保护用户数据，只要设备状态发生变化，都会先清除数据分区中的数据，并会在删除数据之前要求用户确认。

1. 用户购买二手开发设备后，应该将设备状态从“已解锁”改为“已锁定”。锁定设备后，只要没有警告，用户应该就会确信设备处于设备制造商开发的状态。
2. 如果开发者希望停用设备上的验证功能，应该将设备状态从“已锁定”改为“已解锁”。

下表列出了用于更改设备状态的 fastboot 命令：

在更改分区内容时，引导加载程序会检查通过上述命令设置的位，如下表所述：

对于可用于更改分区内容的所有 fastboot 命令，都应执行同样的检查。

注意：B 级实现支持更改设备状态。

绑定 TEE 信任根

如果 TEE 可用，那么在启动分区/恢复分区验证和 TEE 初始化完成后，引导加载程序会将以下信息传递给 TEE，以便绑定 Keymaster 信任根：

1. 为启动分区签名时使用的公钥
2. 当前设备状态（“已锁定”或“已解锁”）

这会更改 TEE 派生的密钥。以磁盘加密为例，当设备状态发生变化时，这可以防止用户数据被解密。

注意：这意味着，如果系统软件或设备的状态发生变化，已加密的用户数据将无法再访问，因为 TEE 将尝试使用其他密钥来解密数据。

初始化认证

与绑定信任根时类似，如果 TEE 可用，引导加载程序会将以下信息传递给 TEE，以便初始化认证：

1. 当前启动状态（绿色、黄色、橙色）
2. 操作系统版本
3. 操作系统安全补丁程序级别

启动到恢复模式

应按照与验证启动分区时完全相同的方式验证恢复分区。

传达启动状态

系统软件需要能够确定之前各阶段的验证状态。引导加载程序会以内核命令行参数的形式（或通过 firmware/android/verifiedbootstate 下的设备树）指定当前启动状态，如下表所述：

注意：处于“红色”启动状态时，设备无法启动到由内核执行相关工作，因此内核命令行中绝不会包含参数 androidboot.verifiedbootstate=red。

启动分区

当执行工作移交给启动分区后，其中的软件将负责设置其他分区的验证。由于系统分区比较大，因此通常不能采用与前面部分类似的方式对其进行验证，而是应改为在该分区被访问时使用 dm-verity 内核驱动程序或类似解决方案对其进行验证。

如果使用 dm-verity 验证大型分区，需要先验证附加到每个已验证分区的 Verity 元数据的签名，然后再装载相应分区并为其设置 dm-verity。

管理 dm-verity

在内核中作为设备映射器目标实现后，dm-verity 会在分区之上添加一个层，并根据在设置过程中传递给它的哈希树来验证每个读取块。如果 dm-verity 遇到未能通过验证的块，则会将其设为无法供用户空间访问。

在启动过程中装载分区时，如果已在设备的 fstab 中为某个分区指定了 verify fs_mgr 标记，fs_mgr 会为该分区设置 dm-verity。Verity 元数据签名是根据 /verity_key 中的公钥进行验证的。

从 dm-verity 错误恢复

由于系统分区比启动分区大得多，因此发生验证错误的可能性也更高。具体来说就是，出现意外磁盘损坏的可能性会更高。出现意外磁盘损坏会导致验证失败，并且如果分区中有关键块无法再访问，这还可能会导致其他功能设备无法使用。可以结合使用前向纠错与 dm-verity 来降低这种风险。建议提供这种备用恢复路径，不过这会导致元数据大小增加。

默认情况下，dm-verity 会被配置为以“重启”模式运行。在该模式下，如果检测到损坏的块，dm-verity 会立即重启设备。这样一来，在设备损坏时就可以安全地向用户发出警告，或者回退到设备特定恢复分区（如果有）。

如果设备启动时存在已知损坏，为了让用户仍可以访问自己的数据，dm-verity 会切换到 I/O 错误 (EIO) 模式。在 EIO 模式下，对于访问损坏的块的所有读取操作，dm-verity 都会返回 I/O 错误，但允许设备继续运行。要跟踪当前模式，需要持续存储 dm-verity 状态。可以通过 fs_mgr 或引导加载程序对该状态进行管理：

1. 要在 fs_mgr 中管理 dm-verity 状态，需要为 verify 标记指定一个附加参数，以便让 fs_mgr 知道 dm-verity 状态要存储在哪里。例如，要将该状态存储在元数据分区中，需要指定 verify=/path/to/metadata。

   注意：在首次检测到损坏之后，fs_mgr 会将 dm-verity 切换到 EIO 模式，并且会在任何已验证分区的元数据签名发生变化后将模式重置为“重启”。

2. 要在引导加载程序中管理 dm-verity 状态，需要在 androidboot.veritymode 命令行参数中将当前模式传递到内核，如下所示：

   内核命令行参数	说明
   androidboot.veritymode=enforcing	将 dm-verity 设置为默认的“重启”模式。
   androidboot.veritymode=eio	将 dm-verity 设置为 EIO 模式。

   注意：要在引导加载程序中管理状态，还需要内核在设备因 dm-verity 而重启时正确设置重启原因。检测到损坏后，如果有任何已验证分区发生变化，引导加载程序都应切换回“重启”模式。

如果出于任何原因未以“重启”模式启动 dm-verity，或如果无法验证 Verity 元数据，系统会向用户显示一条警告（如果允许设备启动），与在启动到“红色”启动状态之前显示的警告类似。必须获得用户同意，设备才能继续以 EIO 模式启动。如果在 30 秒内未获得用户同意，设备将会关机。

注意：为了防止未验证的数据泄露到用户空间，dm-verity 绝不会以记录模式启动。

已验证的分区

在已验证的设备中，系统分区一定已通过验证。不过，所有其他只读分区也应设为已验证。在已验证的设备中，所有包含可执行代码的只读分区都已通过验证，比如供应商分区和原始设备制造商 (OEM) 分区（如果存在）。

要验证某个分区，需要为其附加已签名的 Verity 元数据。元数据由分区内容的哈希树以及一个 Verity 表组成（Verity 表中包含已签名的参数和哈希树的根）。如果在为分区设置 dm-verity 时未提供这些信息或提供的信息无效，设备将不会启动。

实现详细信息

密钥类型和大小

AOSP 中使用的原始设备制造商 (OEM) 密钥是模数为 2048 位或更高且公开指数为 65537 (F4) 的 RSA 密钥，符合 CDD 中关于密钥安全系数不能低于此类密钥的要求。

请注意，原始设备制造商 (OEM) 密钥遭到入侵后，通常无法再使用，因此务必要对该密钥采取保护措施，最好是使用硬件安全模块 (HSM) 或类似解决方案。另外，建议为每种类型的设备使用不同的密钥。

签名格式

Android 可验证启动映像上的签名是一条经过 ASN.1 DER 编码的消息，可以使用与 platform/bootable/recovery/asn1_decoder.cpp 中提供的解码器类似的解码器对该消息进行解析
消息格式如下：

AndroidVerifiedBootSignature DEFINITIONS ::=
     BEGIN
          FormatVersion ::= INTEGER
          Certificate ::= Certificate
          AlgorithmIdentifier  ::=  SEQUENCE {
               algorithm OBJECT IDENTIFIER,
               parameters ANY DEFINED BY algorithm OPTIONAL
          }
          AuthenticatedAttributes ::= SEQUENCE {
                 target CHARACTER STRING,
                 length INTEGER
          }

          Signature ::= OCTET STRING
     END

Certificate 字段是一个完整的 X.509 证书（您可以在 RFC5280 第 4.1 部分中找到它的定义），其中包含用于签名的公钥。当设备处于“已锁定”状态时，引导加载程序会先使用原始设备制造商 (OEM) 密钥进行验证；如果改用嵌入的证书进行验证，设备将只能启动到“黄色”或“红色”状态。

除了 AuthenticatedAttributes 字段外，其余结构与 RFC5280 第 4.1.1.2 部分和第 4.1.1.3 部分中定义的结构类似。该字段中包含要验证的映像的长度（整数形式）以及该映像所在的分区（启动分区、恢复分区等）。

为映像签名和验证映像

生成已签名的映像：

1. 生成未签名的映像。
2. 为映像填充 0，以便补齐到下一页的大小边界（如果已对齐，则忽略此步骤）。
3. 根据填充后的映像和所需的目标分区填写上述 AuthenticatedAttributes 部分的字段。
4. 将上述 AuthenticatedAttributes 结构附加到映像。
5. 为映像签名。

验证映像：

1. 确定要加载的映像的大小，包括内边距（例如，通过读取标头来确定）。
2. 读取位于上述偏移量处的签名。
3. 验证 AuthenticatedAttributes 字段的内容。如果这些值无效，则视为签名验证错误。
4. 验证映像和 AuthenticatedAttributes 部分。

用户体验

设备处于“绿色”启动状态时，除了正常设备启动所需的用户互动外，用户应该不会看到任何其他用户互动。设备处于“橙色”和“黄色”启动状态时，用户会看到一条至少持续 5 秒的警告。如果用户在这段时间内与设备互动，该警告持续显示的时间至少会延长 30 秒，或者直到用户关闭该警告。设备处于“红色”启动状态时，该警告会显示至少 30 秒，之后设备将会关机。

下表显示了其他状态下的用户互动屏幕示例：

设备状态	用户体验示例
黄色	图 2. 用户互动之前	图 3. 用户互动之后
橙色	图 4. 提示设备已解锁且无法验证的警告。
红色	图 5. 提示验证启动失败的警告	图 6. 提示启动到 EIO 模式的警告