TEE系列之TTBR 安全启动设计文档 浅析

TBBR的全称是Trusted Board Boot Requirements，可以简单理解为安全启动的设计文档。安全启动时设计安全SoC的第一部分，基于不可更改的信任根，安全启动和安全升级非常多样化，我们在做安全SoC设计的时候很难去调研所有场景的安全启动要求，如果软件是多个供应商来参与，那么不同的供应商之间互相不信任，那么设计安全启动时就非常复杂。那么可以参考这个文档，这个文档主要介绍安全启动的流程、证书格式，需要支持的加解密算法、以及密钥强度，能满足GP TEE PP的文档要求，也可以涵盖绝大部分的应用场景，可以大大简化设计的时间。

TTBR官网手册

1 Terms and abbreviations

2 Overview of the Trusted Boot Process

Trusted Boot Process是一种确保SOC复位开始，仅有正确、计划中的固件/OS/TEE被加载、初始化到SOC上的一种方案。

2.1 Authentication of Code Images by Certificate

可信引导过程通过验证一系列加密签名的二进制图像来工作，每个镜像都包含系统中要加载和执行的不同阶段或元素。每个镜像的签名存储在X.509中证书。每个映像都通过公钥进行身份验证，公钥存储在签名证书中，可以追溯到存储在OTP存储器或ROM中SoC上的根密钥。该过程可确保SoC仅加载OEM或硅芯片预期的系统组件供应商，因为只有已签名的映像才能从引导加载和执行。因为映像是通过非对称密钥进行签名的，所以引导过程可以使用公共密钥对映像进行身份验证。存储在设备上的密钥以及用于生成签名的私钥永远不需要在设备本身上公开。

2.2 Software Architecture

图1显示了Armv8-A AArch64系统的软件体系结构，这是本文中假定的参考模型文件但是，相同的模型可以应用于任何支持等效功能的CPU体系结构。这个SoC固件以最高异常级别显示（尽管固件也可能以较低的异常级别执行，如图所示）。SoC固件包含用于在可信世界和非可信世界之间切换的机制，如下所示：

图中异常级别，前几次博文已经提及，此文不多做赘述。

2.3 Trusted Base System Architecture

如下图所示，提供了基本的可信基本系统组成结构

3 Trusted Boot Requirements

3.1 Fundamental Features

受信任的引导过程具有多个阶段，并使用多个固件图像。它的目的是保证使用标准加密技术，在不同的启动阶段之间，能够传递信任，使其建立一条完整的信任链。
R010_TBBR_FUNCTION. 受信任启动过程必须支持的关键功能是：

1. Configuration of SoC hardware
2. Application Processor (AP) Trusted Firmware installation
3. AP Trusted OS booting
4. Rich OS or Hypervisor boot handover

R020_TBBR_FUNCTION：受信任启动过程可能支持的功能包括：

1. ROM patching
2. Manufacturing Test mode and/or Key Provisioning mode
3. System Control Processor (SCP)
4. Trusted Debug control

对系统控制处理器的支持在附录 A 中描述。

R030_TBBR_FUNCTION：必须保护所有证书和固件（调试证书除外）
反对使用 NV 计数器回滚。
R040_TBBR_FUNCTION： AP 引导 ROM 可能是可修补的。
R050_TBBR_FUNCTION：必须能够独立于用于纠正硬件错误的可信操作系统，例如 SoC 勘误表。 SoC 配置更新可能成为 SoC AP 固件映像的一部分或保存在单独的映像文件中。
R060_TBBR_FUNCTION： 从服务器加载的证书、可信固件映像和其他信息，非可信世界可能会被加密以进行反克隆保护。
R070_TBBR_FUNCTION：如果证书是加密的，则可以在解密之前对其进行身份验证。 这密钥对于设备或一批设备必须是唯一的。

3.2 Certificate Structure and Cryptography

3.2.1 Cryptography

证书签名必须满足NSA suite B 128-bit安全标准，并使用如下加密算法：AES-128、SHA-256、ECC256 (ECDSA) or (legacy support of) RSA2048 (RSA-PSS) 。

PKCS #1 – Standard for RSA、FIPS 186-4 – Standard for ECDSA 。

这里提到的密码算法是众所周知的行业标准。 算法的选择和安全级别不会从根本上影响密钥证书基础结构和 SoC Trusted 启动顺序，但它提供了一个
所需证书结构大小的有用指示。

R010_TBBR_CRYPTO： 证书签名必须符合 NSA 套件 B 128 位安全标准，因此使用以下加密算法：

• AES-128
• SHA-256
• ECC256 (ECDSA) 或（传统支持）RSA2048 (RSA-PSS)

R020_TBBR_CRYPTO， 如果适用，必须遵循以下标准：

• PKCS #1 – RSA 标准。
• FIPS 186-4 – EC-DSA 标准

出于专利相关的原因、硬件成本、软件证书，验证所需的大小和时间，可以选择使用 RSA-PSS 或 EC-DSA。

RSA-PSS 签名方案另外对消息的哈希进行签名，而不是直接对消息进行签名。这种技术是几乎总是与 RSA 一起使用，因为可以直接签名的数据量与密钥的大小成正比，这通常比原始消息小得多。
使用 RSA-PSS 生成的数字签名的长度与 RSA 密钥模数相同，即至少 2048 位。
EC-DSA 签名方案对消息的哈希进行签名，而不是直接对消息进行签名。与 RSA-PSS 相比，使用 EC-DSA 的显着好处是生成的签名大小要小得多。
本文档假设证书签名与密钥的长度相同。

R030_TBBR_CRYPTO：加密算法可以使用硬件专用引擎或在 软件。两者都可以防止非侵入性旁道攻击。
R040_TBBR_CRYPTO：密码原语的软件实现必须确保它们的 对于加密中的每个代码路径，执行具有相同的处理时间和缓存足迹 算法。

注意侧信道被 GlobalPlatform Protection Profile0 列为可能的威胁。

3.2.2 Boot certificates

在本规范中，选择了使用 ecdsa-with-SHA256 (1) 的固定格式、DER 编码、自签名 X.509 证书作为实施的一个例子。它们使用 RFC 52800 中指定的 PKIX 配置文件进行描述。存在其他解决方案，并且可用于成功申请 GlobalPlatform 认证 0。
此外，X.509 标准是有据可查的，并且可以使用免费工具和源代码。
证书必须符合以下要求：

• R010_TBBR_证书。用于可信启动的每个证书都可能符合 X.509v3，x590v3，扩展字段可用于传递安全参数，例如 NV 计数器、固件哈希、
  公钥和 SoC 安全参数。
• R020_TBBR_证书。每个证书可能有一个颁发者名称、一个主题名称、一个唯一的序列号、使用的算法和公钥信息（除了不能传递公钥值
  每个尺寸缩小证书）。
• R030_TBBR_证书。每个证书可能有一个有效期。
• R040_TBBR_证书。在对可信固件证书进行任何身份验证之前，证书必须 存在于受信任的 RAM 中。
• R050_TBBR_证书。在对涉及的可修改可信软件映像进行任何完整性检查之前，在可信启动过程中，必须将软件映像下载到可信 RAM 中。
  图 3 是 X.509 v3 证书结构的概述，并以证书中解释的归档示例
  第 3.6 节。

下图是X.509 v3证书结构概览：

3.3 SoC Cryptographic Keys

以下部分总结了基于可信系统架构所需的加密密钥。

• R01 0_TBBR_KEY_STORAGE。 SoC 必须实现 384 位的最小 OTP/保险丝大小，并且如果 EK 是总共使用了 640 位，或者如果使用了可选的 SSK 密钥，则总共使用了 768 位。
• R02 0_TBBR_KEY_STORAGE。 一旦密钥被烧录，进一步的编程可能会被保险丝位组织。 这个 OTP/Fuse位禁止进一步编程是拒绝再次写入。

制造模式信息可以使用 OTP/Efuse 直接编码或从其他 OTP/Efuse 生成ROTPK 等信息。 预计至少以下设备生命周期状态可供 Trusted软件开发商：

• Un-initialized device
• Test and Development device
• Mass production
• device Device not working (identified at factory)
• Device returned for repair (this state may be the same as a test or production state)

如果设备返回维修并进入维修状态，应采取适当措施保护机密设备上存在的用户数据，尤其是存储在可信世界中的数据。

3.3.1 NV Counters

如果固件映像被更新以修复安全漏洞，并且设备允许固件映像“回滚”到以前的不安全版本，则存在安全风险。因此，固件必须使用非易失性 (NV) 计数器来防止回滚。
基于可信系统架构需要在 R020_NV_COUNTER 中的两个可信非易失性计数器专门用于可信启动过程：

• TrustedFirmwareNVcounter 至少有 31 个状态和一个“溢出”状态.
• NonTrustedFirmwareNVcounter 必须至少有 223 个状态和一个“溢出”状态。

验证固件映像后，从证书扩展字段中获取的映像修订号，例如，TrustedFirmwareNvCounter 与存储在硬件中的相应 NV 计数器进行比较。如果值为：

• 小于关联的 NV 计数器，则身份验证失败。
• 与 NV 计数器相同，则身份验证成功。
• 超过 NV 计数器则认证成功，并更新 NV计数器。

可选地，可信计算组 (TCG) 建议添加四个 32 位计数器，能够计数 2
32，用于同步数据存储以防止 0 中的回滚攻击的状态。这些计数器是可选的，因为它们可以由可信操作系统服务在启动时使用安全存储或使用 eMMC v4.4x 重放保护内存处理块（RPMB）。

3.3.2 Key security robustness property

信任链中的第一个环节是管理 OEM 信任根私钥，对辅助密钥进行签名
用于签署所有后续证书。

• R010_TBBR_KEY_REVOCATION。为了在 Trusted 启动过程中提供密钥撤销能力，所有可信调试、SoC 固件、AP 可信操作系统、SCP 可信操作系统的附属证书（如果已实现），Rich OS（如果已实现）必须由不同的私钥/公钥对签名，并且必须包含可信世界证书的 TrustedFirmwareNvCounter 和NonTrustedFirmwareNvCounter 用于不受信任的世界证书。

信任私钥的根是 OEM 的财产，它正在对 Trusted 中包含的辅助公钥进行签名。密钥证书以及相应的私钥归 OEM 或第三方所有，用于对作品进行签名
的固件。

• R020_TBBR_KEY_REVOCATION。 OEM 必须签署包含辅助公钥的密钥证书验证可信调试、SoC 固件、AP可信操作系统、SCP 可信操作系统（如果实施）、Rich OS（如果已实现）证书并包含TrustedFirmwareNvCounter。
• R030_TBBR_KEY_REVOCATION。如果这些辅助私钥之一被泄露，则必须撤销它们。只要信任的根私钥不被破坏，通过用一个新的密钥证书签名增加 TrustedFirmwareNvCounter。

如果整个类别的设备都存在单一版本的信任根私钥，那么所有这些设备的安全性是依赖于这个密钥不被泄露。尽管攻击者可能难以获得此密钥，但成功攻击的后果是严重的。这被称为“课间休息”。

为了防止在网络上发现的攻击可移植到一类设备上，可信执行环境 TEE 应为以这样的方式制作，例如用于安全存储的任何密钥都来自每个设备唯一的密钥，硬件唯一密钥 (HUK)。

• R040_TBBR_KEY_REVOCATION。每个设备必须随机生成 HUK 并且仅用于密钥允许将秘密唯一地绑定到平台的派生（因此加密的秘密
  不能导出到其他设备）。
• R050_TBBR_KEY_REVOCATION。 破坏一台设备的 HUK 只能影响该设备。
• R060_TBBR_KEY_REVOCATION。破坏一台设备不得影响该设备的“等级”。

如果在绑定 HUK 派生体之前用于固件解密的 Secret Symmetric Key (SSK) 被泄露，这不会导致信任链被破坏，而是会破坏反克隆和反复制保护。

3.4 Trusted Boot Process

本节介绍可信引导过程要求。

3.4.1 Chain of Trust

Trusted Boot 过程中的每个步骤仅与其之前的步骤一样受信任。 因此，信任链被扩展通过可信启动过程中的每一步。

3.4.2 Overview

下图显示了可信启动过程和事件序列的概述。

3.4.3 SoC Wakeup from cold reset

一旦 SoC 退出上电复位，电源控制功能就会从其复位向量开始执行。 这是
第一个在 SoC 上运行的软件。

• R01 0_TBBR_WAKEUP。 一旦 SoC 退出上电复位：
  • 如果设备是“生产设备”，则电源控制功能必须在从复位释放时，开始在完整性保护存储器中执行，例如片上引导 ROM 或可信 SRAM。
  • 如果设备是“测试和开发”或“未初始化”设备，那么它可能会在外部 XIP 上启动内存或 SRAM 并绕过片上引导 ROM。 这是由速度分箱和 ROM 驱动的调试。
• R02 0_TBBR_WAKEUP。 AP Boot ROM 可能包含多个初始执行状态：
  • 第一个状态必须是引导 TEE 并执行不可信引导加载程序的正常操作模型。
  • 第二种状态可以是密钥提供软件模式，当设备处于运行状态时选择
    “未初始化状态”并将允许 SoC 密钥配置。
  • 第三个状态可能是制造测试模式，进入以启用最少的生产测试开机时间，以减少制造时间。

用于维修和返工的生产或诊断测试模式，例如制造和密钥供应测试模式。上面描述的，不在本文档的范围内。但需要注意的是，此类模式必须慎重，安全且必须具有受限访问权限。保护模式可能意味着拥有一个允许进行配置的保险丝仅在工厂的受控条件下使用一次，或者用于维修中使用的诊断软件，并且必须意味着在适当配置的状态下将 AP 引导到非信任世界，以确保软件无法访问任何安全资产。

3.5 Certificates Chaining and Key Infrastructure

图 5 说明了每个证书的证书密钥基础结构和依赖关系以及它们之间的关系。
信任私钥的根是 OEM 的财产，此密钥可以对 Key 中的辅助公钥进行签名
证书，由 OEM 或第三方拥有。 OEM 或第三方拥有相应的私钥并使用它们
签署后续固件内容证书。 信任根私钥也用于对固件进行签名更新程序和可信引导固件证书

3.5.1 TEE configuration and firmware flashing

此阶段的主要目的是设置时钟； 重置、电源配置以及任何强制性 SoC 互连QoS 功能，使 AP 能够启动。

电源控制功能可以由 SCP 或 AP ROM 执行，具体取决于 SoC 架构。

• R010_TBBR_AFM_BOOTROM。电源控制功能必须配置 SoC 时钟、复位、电源域以及进行可信引导所需的任何机制。

其次要目的是设置 AP TrustZone 技术，例如异常向量、MMU、系统寄存器和SoC AP 固件中的 EL3 监视器，并配置任何尚未通过的 SoC 系统安全设置由硬件初始化，例如 Snoop 控制单元。

• R020_TBBR_AFM_BOOTROM。 AP 固件必须配置 TrustZone
  技术扩展。这个对应EL3监视器的异常向量、堆栈、系统寄存器和MMU映射固件。
• R030_TBBR_AFM_BOOTROM。 AP固件必须配置 SoC 功能和 QoS 安全 机制。
• R040_TBBR_AFM_BOOTROM。 AP 固件必须在使用可信 RAM之前擦除它们，或检查硬件已经真正擦除了它们
• R050_TBBR_AFM_BOOTROM。 AP 固件必须使 L1/L2缓存无效以防止错误的缓存行命中。

在异构或多集群 Cortex-A 系列处理器实现中，进行可信启动过程
在单个 Cortex-A 处理器内核上。

• R060_TBBR_AFM_ BOOTROM。 AP 集群的所有处理器内核，除了执行 Trusted引导过程必须保持断电或置于 WFI、WFE 状态，直到可信引导过程完成。

此阶段的第三个目的是检查 SoC 输入引脚是否设置为请求 SoC 固件更新，并检查是否NVM 内存中存在有效的 SoC 固件可信目录 (ToC)。

• R070_TBBR_AFM_BOOTROM。 AP 固件必须访问 SoC 只读寄存器才能反映状态用于检测是否请求固件更新的输入引脚.

• R080_TBBR_AFM_BOOTROM。 AP 固件必须配置任何 TrustZone 地址空间控制器（例如TZASC) 用于访问 NVM 固件映像。

• R090_TBBR_AFM_BOOTROM。 AP 固件 ROM 分支必须检查 SoC 输入引脚是否设置为请求更新 SoC 固件。

• R0100_TBBR_AFM_BOOTROM。如果请求固件更新，固件必须启动 SoC固件更新程序。如果没有要求，当前固件的目录 (ToC) 必须是加载到 Trusted SRAM 并检查其有效性。

• R0110_TBBR_AFM_BOOTROM。如果 ToC 无效，则必须启动 SoC 固件更新例程。

如果请求固件更新，则必须遵循以下要求：

• R0120_TBBR_AFM_BOOTROM。在切换到非信任世界之前，AP 固件必须确保有足够的非可信 RAM 可用于承载固件加载程序。
• R0130_TBBR_AFM_BOOTROM。在切换到非可信世界之前，可信看门狗定时器必须用 256s 值刷新和重新编程，以确保闪烁过程有足够的时间
  完全的。
• R0140_TBBR_AFM_BOOTROM。 AP 固件必须切换到不受信任的世界才能下载SoC 固件加载程序。

3.5.2 AP Non-Trusted firmware updater download and its authentication by the Trusted world

Non-Trusted Firmware Updater职责是从外部接口加载完整的SoC固件到SoC的NVM中。

AP Non-Trusted 固件更新器负责加载完整的 SoC 固件，其中包括 SCP 固件(如果存在）、AP 固件、可信操作系统、来自外部接口（如 USB、UART、SD-MMC）的非可信世界映像，NAND、NOR、以太网到 SoC NVM 存储器，例如 NAND 闪存、LPPDR2-NVM 或任何由 SoC 输入指示的存储器针脚。

要将所有固件映像下载到 SoC NVM 中，ROM 中特定于 SoC 的公共驱动程序可能需要例如，USB 或 UART。

• R010_TBBR_AFM_FLASHING。 SoC 可能会实现一个非可信 ROM，其中包含必要的在非可信 SRAM 中下载 SoC 固件更新程序或来自外部接口的完整固件，如 USB、UART、SD-MMC、NAND、NOR 或以太网。
• R020_TBBR_AFM_FLASHING。非可信 ROM 必须至少能够通过其公共接口发送ROTPK、SoC_ID 和适当的制造模式值，以允许 OEM 识别
  提供哪个固件。
• R030_TBBR_AFM_FLASHING。如果不可信 ROM 需要先在不可信 RAM 中下载固件更新程序以安装公共驱动程序（例如，USB 堆栈），则下载的更新程序可能需要经过 TEE 认证。在这种情况下，不受信任的 ROM 必须切换回受信任的世界。
• R040_TBBR_AFM_FLASHING。固件更新程序（基于 ROM 或非可信 RAM）必须下载完整的 SoC 固件，其中包括 SCP（如果存在）、可信操作系统、来自外部接口，例如 USB、UART、SD-MMC、NAND、NOR、以太网到 SoC NVM 存储器，例如NAND 闪存、LPPDR2-NVM 或任何由 SoC 输入引脚指示的存储器。
• R050_TBBR_AFM_FLASHING。固件更新程序必须切换回可信世界进行身份验证下载的 SoC 固件。不这样做可能会被可信看门狗计时器检测到溢出。

不受信任的世界映像包括不受信任的引导加载程序。例如，它们还可能包括调制解调器软件和/或多媒体处理器图像。在非信任 ROM 必须首先下载固件更新程序以安装其他驱动程序的情况下，然后以下要求也适用：

• R060_TBBR_AFM_FLASHING。 AP 固件必须验证 SoC 固件更新程序证书使用证书中包含的 ROTPK 密钥的可信 RAM。它必须验证这个密钥（或它的散列）以等于 eFused ROTPK 值。

• R070_TBBR_AFM_FLASHING。 AP 固件必须计算 SoC 固件加载程序的哈希值，并且必须检查它是否等于证书有效负载中包含的那个。

• R080_TBBR_AFM_FLASHING。 AP 固件更新程序可以防止回滚。

• R090_TBBR_AFM_FLASHING。如果认证成功，AP 固件必须刷新 Trusted具有不可信固件更新程序证书中定义的值的看门狗定时器，以确保
  闪烁过程将有足够的时间完成，否则使用标准值（即256s）

• R0100_TBBR_AFM_FLASHING。 AP 固件必须切换到 Non-Trusted 世界才能执行 SoC固件加载程序。

为了最大限度地减少刷机过程时间和固件更新软件的执行，一小组 AP 和
可以加载电源控制功能来配置 SoC 时钟、电源域和物理接口，以提供
最佳性能。以下固件功能是可选的：

• R0110_TBBR_AFM_FLASHING。 AP 固件必须计算 SoC AP 固件更新的哈希值配置，它必须在安装之前检查它是否与证书中包含的相同，并且
  运行它。
• R0120_TBBR_AFM_FLASHING。 AP 固件更新配置必须防止回滚。
  R0130_TBBR_AFM_FLASHING。 AP 固件必须计算 SoC SCP 固件更新的哈希值配置，它必须在安装之前检查它是否与证书中包含的相同，并且
  运行它。
• R0140_TBBR_AFM_FLASHING。如果存在，则必须保护 SoC SCP 固件更新配置反对回滚。

3.5.3 Firmware Table of Contents (ToC)

为了从 SoC NVM 中找到并下载继续 Trusted 所需的不同固件映像
引导过程中，需要固件 ToC。

• R010_TBBR_TOC。 ToC 可以被认证（在下表中它不是）。
• R020_TBBR_TOC。 ToC 可能已加密（在下表中未加密）
• R030_TBBR_TOC。 ToC 可能受回滚保护（在下表中不是）。
• R040_TBBR_TOC。 ToC 必须指明哪个证书/内容被加密以及使用哪个密钥。
• R050_TBBR_TOC。 ToC 可能符合以下模板：

• R060_TBBR_TOC.SoC TOC 必须至少包含以下项目：

  • 可信密钥证书。
  • 可信 SoC 证书和固件。
  • 可信操作系统证书和固件。
  • 不受信任的世界引导加载程序证书和固件。

• R070_TBBR_TOC。 SoC TOC 可能包含以下项目：

  • 受信任的 SCP 证书和固件。
  • 受信任的主调试证书。
  • 受信任的辅助调试证书。

• R080_TBBR_TOC。 ToC 必须位于 NVM 内存中的固定地址或块位置（ROM’ed或由硬件绑定在 SoC 固件的可读寄存器中）。

在某些实现中，可信启动软件预计将通过 TOC 条目名称（即FirmwareUpdaterCertificate) 以查找密钥/内容证书和补丁，或每个步骤所需的固件映像。

3.6 Certificate Structure and Content

介绍证书结构及其内容， 后续补充。

3.7 Certificate Creation and Key Management

证书的创建和秘钥管理， 后续补充。