【转】ARM Trusted Firmware分析——TBBR、TBB、FIP-TBB

转自：https://www.cnblogs.com/arnoldlu/p/14301334.html

前面我们跟着前辈的文章，学习了ATF的启动、镜像生成与校验、固件升级，这里来看看启动需求。

ARM TBBR定义了安全系统基本需求，ATF中实现了COT，包括FIP生成、密码库调用、镜像签名加密/解密验签等等流程。

下面主要参考ARM TBBR文档，以及《Trusted Firmware-A Documention》。

ARM文档《Trusted Board Boot Requirements (TBBR)》中定义了安全启动需求。

ARM Trusted Firmware的**《Trusted Board Boot》根据TBBR，对实现COT、TBB流程、认证、加密实现细节进行介绍。**

《Building FIP images with support for Trusted Board Boot》对如何编译支持TBB的FIP进行介绍。

1. ARM Trusted Board Boot Requirements

以下内容来源于：《Trusted Board Boot Requirements (TBBR)》。

2.Overview of the Trusted Boot Process

Trusted Boot Process是一种确保SOC复位开始，仅有正确、计划中的固件/OS/TEE被加载、初始化到SOC上的一种方案。 (按照设计的启动流程正常运行)

2.1 Authentication of Code Images by Certificate

2.2 Software Architecture

2.3 Trusted Base System Architecture

3.Trusted Boot Requirements

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 。

3.2.2 Boot certificates

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

3.3 SOC Cryptographic keys

对TBSA所需的SOC的加密秘钥进行总结。

3.3.1 NV Counters

NV Counters用于保护设备免于版本回滚。

TBBR需要两个可信NV Counters来保证可信启动流程：可信固件NV Counter和非可信固件NV Counter。

当镜像被验证通过后，将其版本号和硬件中NV Counter值比较：

• 如果版本号小于NV Counter，表示验证失败。
• 版本号等于NV Counter，验证成功。
• 版本号大于NV Counter，验证成功并更新硬件中NV Counter值。

3.4 Trusted Boot Process

介绍可信启动流程，介绍何为Chain of Trust、可信流程图概述、SOC冷启动后安全。

3.4.2 Overview

可信启动流程图：

3.5 Certificate Chaining and Key Infrastructure

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

Non-Trusted Firmware Updater职责是从外部接口加载完整的SoC固件到SoC的NVM中。外部接口可能是USB/UART/SD-MMC/NAND/NOR/Ethernet等；

SOC固件包括SCP固件、AP固件、TOS、非安全世界固件等；SOC NVM包括NAND Flash等。

3.5.3 Firmware Table of Contents

3.6 Certificate Structure and Content

介绍证书结构及其内容。

3.7 Certificate Creation and Key Management

证书的创建和秘钥管理。

4. ATF Trusted Board Boot

以下内容来源于：《Trusted Board Boot》。

8.1 Chain of Trust

CoT包含一系列默认可信的组件：

• ROTPK的SHA-256哈希。
• 运行在内置ROM上的BL1。

CoT的其他组件还包括：

• 符合X.509 v3标准的证书。

证书还可以增加附加信息来存储其他COT所需信息。证书是自签名的，所以不需要CA来进行认证。

证书分为：

• Key证书：认证给内容签名的公钥。
• Content证书：镜像的哈希。镜像的认证通过比较内容哈希和Content证书。

公钥和哈希作为非标准扩展存在X.509 v3证书中。

实现CoT所使用的秘钥：

• Root of trust key：用于给BL2签名内容证书和可信秘钥证书做签名的私钥。对应的公钥是ROTPK。
• Trusted world key：用于给安全世界镜像的秘钥证书签名的私钥。公钥保存于可信证书扩展域中。
• Non-trusted world key：用于给非安全世界镜像的密钥证书签名的私钥。公钥保存于安全世界证书扩展域中。
• BL3X keys：对BL3X镜像相应秘钥证书进行签名的私钥。公钥存于安全世界证书扩展域中。

如下证书用于对镜像进行验证：

• BL2 content Certificate：It is self-signed with the private part of the ROT key. It contains a hash of the BL2 image.
• Trusted key Certificate：It is self-signed with the private part of the ROT key. It contains the public part of the trusted world key and the public part of the non-trusted world key.
• SCP_BL2 key Certificate：It is self-signed with the trusted world key. It contains the public part of the SCP_BL2 key.
• SCP_BL2 content Certificate：It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2 image.
• BL31 key Certificate：It is self-signed with the trusted world key. It contains the public part of the BL31 key.
• BL31 content certificate：It is self-signed with the BL31 key. It contains a hash of the BL31 image.
• BL32 key Certificate：It is self-signed with the trusted world key. It contains the public part of the BL32 key.
• BL32 content Certificate：It is self-signed with the BL32 key. It contains a hash of the BL32 image.
• BL33 key Certificate：It is self-signed with the non-trusted world key. It contains the public part of the BL33 key.
• BL33 content Certificate：It is self-signed with the BL33 key. It contains a hash of the BL33 image.

8.2 Trusted Board Boot Sequence

BL1对BL2采取的步骤：

• BL1 loads and verifies the BL2 content certificate：
• BL1 loads the BL2 image：BL1加载BL2镜像，并且计算BL2镜像哈希，然后和证书中读取的哈希进行比较。如果比较通过，则将执行权转交给BL2镜像。如何计算哈希？从哪个整数中读取BL2镜像哈希？
• BL2 loads and verifies the trusted key certificate：

针对SCP_BL2、BL31、BL32镜像采取的步骤：

• BL2 loads and verifies the BL3x key certificate：使用Trusted world public key对证书签名进行验证。验签通过，BL2从证书中读取并保存BL3x的公钥。
• BL2 loads and verifies the BL3x content certificate：使用BL3x公钥对BL3x content certificate进行验签。验签通过，BL2从证书中读取并保存BL3x镜像哈希。

针对BL33镜像采取的步骤：

• BL2 loads and verifies the BL33 key certificate：BL2加载并验证BK33 key证书。通过，BL2从证书中读取并保存BL33公钥。
• BL2 loads and verifies the BL33 content certificate：BL2加载并验证BL33 content certificate。通过，BL2从证书中读取并保存BL33镜像哈希。

BL2对镜像进行哈希校验：

• BL2 calculates the hash of each image：BL2计算镜像的哈希，并将其和从证书中读取的哈希进行比较。如果哈希匹配，则验证通过。

8.3 Authentication Framework

参考文档：《Authentication Framework & Chain of Trust》

8.4 Certificate Generation Tool

当打开GENERATE_COT=1时，作为ATF编译过程一部分，cert_create工具被编译并运行。

cert_create以镜像和PEM格式秘钥作为输入，生成DER格式证书来保证COT。生成的证书被作为fiptool输入生成FIP。

cert_create使用OpenSSL SSL库来生成X.509证书。cert_create对OpenSSL的要求是：OpenSSL >= 1.0.1。

cert_create编译和使用参考：《Building the Certificate Generation Tool》。

8.5 Authenticated Encryption Framework

8.6 Firmware Encryption Tool

当DECRYPTION_SUPPORT != none时，encrypt_fw编译和运行作为ATF编译流程一部分。

encrypt_fw以原始镜像作为输入，生成加密镜像并传递给fiptool生成FIP。所以FIP是先加密再做签名。

encrypt_fw使用OpenSSL 1.0.1或更新库进行加密操作。

encrypt_fw编译和使用参考：《Building the Firmware Encryption Tool》。

5. 编译支持Trusted Board Boot的FIP

参考文档：《Building FIP images with support for Trusted Board Boot》。

Trusted Board Boot主要包括两方面：镜像验证和固件更新。

编译FIP和FWU_FIP需要支持如下特性：

3.1 实现mbedtls依赖的密码库和镜像解析模块

mbed TLS == 2.24.0。

3.2 编译FIP配置选项

编译FIP之前需要确保如下选项正确配置：

MBEDTLS_DIR=
TRUSTED_BOARD_BOOT=1
GENERATE_COT=1

同时还需通过ARM_ROTPK_LOCATION指定ROPTK路径：

• ARM_ROTPK_LOCATION=regs：ROTPK哈希从运行平台中获取。
• ARM_ROTPK_LOCATION=devel_rsa：使用默认plat/arm/board/common/rotpk/arm_rotpk_rsa_sha256.bin哈希。如果指定了ROT_KEY，则强制生成新的哈希。
• ARM_ROTPK_LOCATION=devel_ecdsa：使用默认plat/arm/board/common/rotpk/arm_rotpk_ecdsa_sha256.bin哈希。如果指定了ROT_KEY，则强制生成新的哈希。

MBEDTLS_DIR= \
make PLAT= TRUSTED_BOARD_BOOT=1 GENERATE_COT=1        \
ARM_ROTPK_LOCATION=devel_rsa                                    \
ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem        \
BL33=/                                     \
all fip

3.3 编译FWU_FIP配置选项

参考文档：《Firmware Update (FWU)》。

4. Authentication Framework & Chain of Trust

参考文档：《Authentication Framework & Chain of Trust》

Authentication Framework需要满足如下要求：

• 实现COT逐级认证和特定镜像或证书的认证机制。
• 框架需要区分：
  • 编码和传输信息的机制，X.509 v3证书、哈希、NV Counters。
  • 认证传输信息的机制，比如加密库。

如下示意图展示了Authentication Framework内部细节和COT概要机制。

+---------------+---------------+------------+
| Trusted       | Trusted       | Trusted    |
| Firmware      | Firmware      | Firmware   |
| Generic       | IO Framework  | Platform   |
| Code i.e.     | (IO)          | Port       |
| BL1/BL2 (GEN) |               | (PP)       |
+---------------+---------------+------------+
       ^               ^               ^
       |               |               |
       v               v               v
 +-----------+   +-----------+   +-----------+
 |           |   |           |   | Image     |
 | Crypto    |   | Auth      |   | Parser    |
 | Module    |<->| Module    |<->| Module    |
 | (CM)      |   | (AM)      |   | (IPM)     |
 |           |   |           |   |           |
 +-----------+   +-----------+   +-----------+
       ^                               ^
       |                               |
       v                               v
+----------------+             +-----------------+
| Cryptographic  |             | Image Parser    |
| Libraries (CL) |             | Libraries (IPL) |
+----------------+             +-----------------+
              |                |
              |                |
              |                |
              v                v
             +-----------------+
             | Misc. Libs e.g. |
             | ASN.1 decoder   |
             |                 |
             +-----------------+

2.1 Framework design

2.1.1 Chain of Trust

COT是一系列从Root of Trust开始最终到一个镜像的认证镜像的过程。如下框图展示了BL31镜像如何满足COT。

Root of Trust一般指的是ROTPK，其往往固化在芯片内部并不可修改。

+------------------+       +-------------------+
| ROTPK/ROTPK Hash |------>| Trusted Key       |
+------------------+       | Certificate       |
                           | (Auth Image)      |
                          /+-------------------+
                         /            |
                        /             |
                       /              |
                      /               |
                     L                v
+------------------+       +-------------------+
| Trusted World    |------>| BL31 Key          |
| Public Key       |       | Certificate       |
+------------------+       | (Auth Image)      |
                           +-------------------+
                          /           |
                         /            |
                        /             |
                       /              |
                      /               v
+------------------+ L     +-------------------+
| BL31 Content     |------>| BL31 Content      |
| Certificate PK   |       | Certificate       |
+------------------+       | (Auth Image)      |
                           +-------------------+
                          /           |
                         /            |
                        /             |
                       /              |
                      /               v
+------------------+ L     +-------------------+
| BL31 Hash        |------>| BL31 Image        |
|                  |       | (Data Image)      |
+------------------+       |                   |
                           +-------------------+

2.1.2 Image Types

COT中镜像包括认证镜像和数据镜像。认证镜像包含认证数据镜像所需信息；数据镜像包含二进制启动文件，或任何其他数据。

2.1.3 Component responsibilities

对于每一个COT中的镜像，需要执行如下操作来认证它：

• 静态或运行时分配镜像使用内存。
• 识别并加载镜像到分配的内存中。
• 根据镜像类型检查其完整性。
• 根据镜像所用密码算法进行认证。
• 如果镜像将用于认证其他镜像，从中提取相关信息用于认证下一个镜像。

2.1.3.1 TF-A Generic code and IO framework

GEN/IO用于初始化BL1/BL2开始的认证流程。对于任何一个需要认证的镜像，GEN/IO通过认证模块递归向上查找父镜像，知道找到认证过的镜像或者ROT。

GEN/IO使用IO框架加载镜像，使用认证模块参照COT要求从ROT到镜像进行认证。

2.1.3.2 TF-A Platform Port

2.1.3.3 Authentication Module

2.1.3.4 Cryptographic Module

2.1.3.5 Image Parser Module

2.1.4 Authentication methods

2.2 Specifying a Chain of Trust

一个COT可以被一系列连接在一起的特殊排序的镜像描述符。他们排列顺序决定了他们认证顺序。

每个镜像包含一系列AM认证所需属性。

2.3 Implementation example

5. 相关知识点

X.509 v3

X.509 是密码学里公钥证书的格式标准。

X.509 证书己应用在包括TLS/SSL（WWW万维网安全浏览的基石）在内的众多 Internet协议里。同时它也用在很多非在线应用场景里，比如电子签名服务。

X.509证书里含有公钥、身份信息(比如网络主机名，组织的名称或个体名称等)和签名信息（可以是证书签发机构CA的签名，也可以是自签名）。对于一份经由可信的证书签发机构签名或者可以通过其它方式验证的证书，证书的拥有者就可以用证书及相应的私钥来创建安全的通信，对文档进行数字签名。
另外除了证书本身功能，X.509还附带了证书吊销列表和用于从最终对证书进行签名的证书签发机构直到最终可信点为止的证书合法性验证算法。
X.509是ITU-T标准化部门基于他们之前的ASN.1定义的一套证书标准。

DER和PEM

DER - Distinguished Encoding Rules

PEM - Privacy Enhanced Mail

DER是常见的编码规则，PEM是由DER衍生出的秘钥文件格式。

DER 是典型的 Tag-Length-Value(TLV) 编码方式，是 PKCS 密钥体系常用的编码。
DER 是 BER 的子集，编码规则几乎一样，不过去掉了 BER 的一些灵活性，多了几个限制：

• 如果数据长度在 0-127 之间，则 Length 必须使用第 1 种编码方式。
• 如果数据长度 >= 128，则 Length 必须使用第 2 种编码方式，且 Length 必须用最少的字节编码，如果能用 2 字节的则不能用 3 字节。
• 数据要用明确长度的编码方式，不支持 Length 的第3种编码即未知数据长度+结束标记的方式。
  注意：ASN.1 规定整型 INTEGER 需要支持正整数、负整数和零。BER/DER 使用大端模式存储 INTEGER，并通过最高位来编码正负数(最高位0为正数，1为负数)。 如果密钥参数值最高位为 1，则 BER/DER 编码会在参数前额外加 0x00 以表示正数，这也就是为什么有时候密钥参数前面会多出1字节 0x00 的原因。

PEM(Privacy Enhanced Mail)： 因为 DER 编码是二进制数据，早期的 Email 不能发送附件，也不方便直接传输二进制数据([原因])，因此密钥文件通常会在 DER 编码基础上进行 Base64 编码，这就是经常看到的密钥文件格式 PEM。PEM 最早是用来增强邮件安全性的，不过没有被广泛接受，最后却是在密码学中得到了发扬光大，如 openssl 和 ssh-keygen 工具生成的公私钥文件默认都采用 PEM 格式。需要注意的是，PEM 本身不是 ASN.1 的编码规则，它只是 Base64-encoded DER。

6. 参考文档：

《密码学基础1：RSA算法原理全面解析》
《密码学基础2：椭圆曲线密码学原理分析》
《密码学基础3：密钥文件格式完全解析》