可信启动Trusted Board Boot

TBB

Trusted Board Boot（TBB）对所有固件镜像（包括普通世界的bootloader）进行身份验证，以防止恶意固件在平台上运行。TBB使用公钥加密标准 （PKCS）来建立信任链（Chain of Trust）。

CoT

信任链 (CoT) 从一些可信组件开始，其以链式方式建立后续组件的信任，依此类推。CoT取决于几个因素：

• 平台上运行的镜像固件，如通用镜像BL1，BL2，BL31以及BL33，以及平台需要的其他镜像
• 密钥管理方案：设备密钥的全生命周期配置
• 密钥所有权模型：谁拥有哪个密钥

下面这些可信组件提供了信任锚点：

• 信任根公钥 (ROTPK) 或其哈希值
• BL1镜像，假定其固化在ROM中，无法更改

其余的CoT组件是证书或者启动镜像。证书遵循X.509 v3标准，其允许向证书添加自定义扩展，用于存储建立CoT所需的基本信息。所有证书都是自签名的，无需证书颁发机构 (CA)，因为CoT不是通过验证证书颁发者的有效性而建立的，而是通过证书扩展中的内容建立的。

证书分为“密钥”和“内容”证书。密钥证书用于验证签发内容证书的公钥；内容证书用于存储启动镜像的哈希值。在启动阶段，计算启动镜像的哈希值，并从内容证书中提取镜像的哈希值，通过比较以上两个哈希值是否相等来判断镜像是否可信。公钥和哈希值作为非标准扩展字段包含在X.509 v3证书中。

TBBR

在TF-A中实施了TBBR CoT，所有的固件和证书都（直接或者间接地）与信任根公钥（ROTPK）相关。通常设备的供应商拥有 ROTPK、Trusted key和Non-Trusted key。

组件	说明
Root of trust key	信任根密钥，私钥部分用于签发Trusted Boot Firmware Certifacate和Trusted Key Certificate两个证书，公钥部分就是ROTPK
Trusted world key	安全世界密钥，私钥部分用于签发安全世界镜像（BL31和BL32）的密钥证书BL31/BL32 Key Certificate，公钥部分存放在Trusted Key Certificate的扩展域中
Non-Trusted world key	非安全世界密钥，私钥部分用于签发非安全世界镜像（BL33）的密钥证书BL3 Key Certificate，公钥部分存放在Trusted Key Certificate的扩展域中
BL3X keys	BL3X密钥，私钥部分用于签发BL3X镜像的内容证书BL31/BL32/BL33 Content Certificate，公钥部分存放在相应密钥证书BL31/BL32/BL33 Key Certificate的扩展域中
Trusted Boot Firmware Certificate	使用信任根密钥ROT签发的自签名证书，其包括BL2镜像的哈希值
Trusted Key Certificate	使用信任根密钥ROT签发的自签名证书，其包括密钥Trusted world key和Non-Trusted world key的公钥部分
BL31 Key Certificate	使用Trusted world key签发的自签名证书，其包括BL31镜像的哈希值
BL32 Key Certificate	使用Trusted world key签发的自签名证书，其包括BL32镜像的哈希值
BL33 Key Certificate	使用Non-Trusted world key签发的自签名证书，其包括BL33镜像的哈希值

下图展示了按照TBBR实施的信任链CoT，TF-A实施的其他部分如调试证书，SCP镜像等没有列举出来。

X509

TF-A使用X509证书标准实现信任链的传递，证书的要求如下：

• 每张证书都符合X.509v3标准，在其扩展域存放了安全参数，如NV counters，固件哈希值，公钥以及SoC其他安全参数
• 每张证书需要包含：发行商名称，证书主体名称，序列号，算法，公钥信息（有些情况为了减小证书大小，不会传公钥值）
• 每张证书都具备有效期
• 在对可信固件证书进行任何身份验证之前，该证书必须存在于可信RAM中
• 在可信启动过程中，如果还未对软件镜像执行完整性检查，必须将其先下载到可信RAM中

下面是采用X.509 v3标准的证书示例：

可信启动流程

在TF-A中，上电复位后从信任锚点BL1开始运行，BL1加载和认证BL2，认证通过后，跳转到BL2执行，然后BL2再加载和认证BL3x，认证通过后，最后跳转到BL3x镜像继续执行。

BL1认证BL2

BL1加载和认证BL2镜像的流程如下：

• 上电复位后BL1开始执行，从存储介质中读取证书BL2 Content Certficate到可信RAM中
• 解析证书BL2 Content Certficate，获取信任根公钥ROTPK，并计算其哈希值
• 从OTP/EFUSE中读取可信的根公钥哈希值，并与上一步计算的根公钥哈希值进行比较，如果二者相等，则表示ROTPK根公钥可信，否则进入异常处理
• 解析证书BL2 Content Certficate，获取签名值，并使用ROTPK对该证书进行验签，如果验签通过，说明证书可信，从中解析出参考的镜像哈希值BL2 image hash，否则进入异常处理
• 从存储介质中加载BL2镜像，计算其哈希值，并与上一步参考的BL2 image hash进行比较，如果二者相等，说明BL2镜像可信，跳转到BL2开始执行，否则进入异常处理

BL2认证BL3x

BL2加载和认证BL3x镜像的流程如下：

• BL1跳转到BL2开始执行后，从存储介质中读取密钥证书Trust Key Certficate到可信RAM中
• 解析密钥证书Trust Key Certficate，获取信任根公钥ROTPK，并计算其哈希值
• 从OTP/EFUSE中读取可信的根公钥哈希值，并与上一步计算的根公钥哈希值进行比较，如果二者相等，则表示ROTPK根公钥可信，否则进入异常处理
• 解析密钥证书Trust Key Certficate，获取签名值，并使用ROTPK对该证书进行验签，如果验签通过，说明证书可信，从中解析出Trusted World Public Key和Non-Trusted World Public Key，否则进入异常处理
• 接下来就是安全世界和非安全世界每个镜像的认证过程。先从存储介质中读取密钥证书Trust Key Certficate到可信RAM中，解析获取签名值，并使用上一步的Trusted World Public Key对该证书进行验签，如果验签通过，说明证书可信，从中解析出BL31或BL32 Public Key，否则进入异常处理
• 从存储介质中加载内容证书BL31或BL32 Content Certficate，解析获取签名值，并使用上一步的BL31或BL32 Public Key对该证书进行验签，如果验签通过，说明证书可信，从中解析出参考的BL31或BL32 image hash，否则进入异常处理
• 从存储介质中加载BL31或BL32 image，计算其哈希值，并与上一步参考的BL31或BL32 image hash进行比较，如果二者相等，说明BL31或者BL32镜像可信，否则进入异常处理
• 接着是非安全世界镜像的认证过程，与上面安全世界的镜像类似，只是改成使用Non-Trusted World Public Key对密钥证书BL33 Key Certficate进行验签，认证通过再使用BL33 Public Key对BL33 Content Cerificate验签
• 当所有镜像都认证通过后，说明安全世界镜像和非安全世界镜像均可信，可以跳转后续镜像继续启动执行

镜像解密

为了保证镜像的机密性，防止被复制克隆，TF-A认证框架也支持镜像加密功能。在启动流程中，如果镜像被加密，首先需要对其进行解密，然后才执行认证流程。

参考

1. Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A
2. Trusted Firmware-A Documentation

欢迎关注“安全有理”微信公众号。