TEE-OS学习轨迹第九篇:探讨安全启动BL1 BL2 BL3X启动链验可信启动密钥体系与证书层级

TF-A TBBR 可信启动密钥体系与证书层级详解

结合提供的启动日志、镜像ID定义与ARM TBBR官方规范,整个信任链采用「根密钥分层派生 + 证书签名传递信任 + 哈希校验镜像完整性」的三级证书架构,所有证书均为标准X.509 v3格式,公钥与镜像哈希存放在证书自定义扩展字段中。

一、核心设计原则

1. 两类证书分工

TF-A 将证书明确分为两类,职责严格分离:

证书类型

核心作用

存放内容

密钥证书(Key Cert)

传递签名权限

下一级证书的验证公钥

内容证书(Content Cert)

校验固件完整性

对应固件镜像的哈希值

2. 验签的两步标准流程

固件镜像本身不会被直接数字签名,每一级验证都遵循固定逻辑:
  1. 证书签名验证:用上一级传递来的公钥,验证当前证书的数字签名合法性,确认证书未被篡改;
  2. 信息提取:验签通过后,从证书扩展字段中提取下一级公钥(密钥证书)或镜像哈希(内容证书);
  3. 镜像哈希对比:对内容证书来说,最终用提取的哈希与实际固件计算的哈希做比对,完成完整性校验。
对应你日志中的现象:Signature verification: PASS 对应证书签名验证;Hash match 对应镜像哈希对比。

二、完整密钥体系与签发层级(私钥视角,从根到叶子)

整个体系只有一个信任根,密钥逐级向下派生,根私钥全程离线保存,不直接接触业务证书。

第0层:信任根 —— ROT 根密钥

  • 私钥:Root of Trust Private Key(根私钥)
    • 持有者:设备厂商/固件发布方,全程离线安全存储,仅用于签发最顶层的两张根证书
    • 签名对象:

                可信启动固件证书(ID=6,Trusted Boot FW Cert)

                可信密钥证书(ID=7,Trusted Key Cert)

  • 公钥:ROTPK(Root of Trust Public Key,根公钥)
    • 存储位置:开发环境下直接编译进BL1固件;量产环境下哈希值烧录在芯片OTP/eFuse一次性可编程寄存器中,不可篡改
    • 作用:整个信任链的唯一信任锚,BL1阶段用它验证最顶层的两张根证书

第1层:世界级密钥(从根密钥派生)

可信密钥证书(ID=7)中会存放两对世界级公钥,对应安全世界与非安全世界两条独立分支:
1.1 可信世界密钥(Trusted World Key)
  • 私钥:由固件发布方持有,用于签发所有安全世界子系统的密钥证书
  • 签名对象
    • SoC固件密钥证书(ID=9,对应BL31)
    • 可信OS固件密钥证书(ID=10,对应BL32)
  • 公钥存放位置:可信密钥证书(ID=7)的扩展字段中
1.2 非可信世界密钥(Non-Trusted World Key)
  • 私钥:由固件发布方持有,用于签发非安全世界子系统的密钥证书
  • 签名对象:非可信固件密钥证书(ID=11,对应BL33)
  • 公钥存放位置:可信密钥证书(ID=7)的扩展字段中

第2层:子系统内容签名密钥

每个子系统的密钥证书中,会存放对应内容证书的签名公钥:
  • SoC内容签名私钥 → 签发SoC固件内容证书(ID=13),公钥存放在ID=9证书中
  • TOS内容签名私钥 → 签发可信OS内容证书(ID=14),公钥存放在ID=10证书中
  • NT内容签名私钥 → 签发非可信内容证书(ID=15),公钥存放在ID=11证书中

第3层:固件镜像

所有固件镜像(BL2/BL31/BL32/BL33)都不直接签名,仅将其哈希值存入对应内容证书,通过证书的签名间接保证可信。

三、证书验签链与对应关系(启动视角,逐级验证)

对应启动日志的加载顺序,验签从BL1开始,公钥逐级向下传递,完整对应关系如下表:

证书层级

镜像ID

证书全称

签发所用私钥

验签所用公钥来源

证书核心承载内容

执行验签的阶段

根证书层

6

可信启动固件证书
Trusted Boot FW Certificate

ROT根私钥

BL1固件中固化的ROTPK根公钥

BL2固件镜像的SHA256哈希

BL1阶段

根证书层

7

可信密钥证书
Trusted Key Certificate

ROT根私钥

BL2继承的ROTPK根公钥

可信世界公钥、非可信世界公钥

BL2阶段

子系统密钥层

9

SoC固件密钥证书
SoC FW Key Certificate

可信世界私钥

可信密钥证书(ID7)中的可信世界公钥

BL31内容证书的签名公钥

BL2阶段

子系统密钥层

10

可信OS固件密钥证书
Trusted OS FW Key Certificate

可信世界私钥

可信密钥证书(ID7)中的可信世界公钥

BL32内容证书的签名公钥

BL2阶段

子系统密钥层

11

非可信固件密钥证书
Non-Trusted FW Key Certificate

非可信世界私钥

可信密钥证书(ID7)中的非可信世界公钥

BL33内容证书的签名公钥

BL2阶段

子系统内容层

13

SoC固件内容证书
SoC FW Content Certificate

SoC内容签名私钥

SoC密钥证书(ID9)中的公钥

BL31固件镜像的SHA256哈希

BL2阶段

子系统内容层

14

可信OS内容证书
Trusted OS FW Content Certificate

TOS内容签名私钥

TOS密钥证书(ID10)中的公钥

BL32固件镜像的SHA256哈希

BL2阶段

子系统内容层

15

非可信内容证书
Non-Trusted FW Content Certificate

NT内容签名私钥

NT密钥证书(ID11)中的公钥

BL33固件镜像的SHA256哈希

BL2阶段

四、各固件的完整验签链路

1. BL2 固件(ID=1)

  • 信任链长度:1级证书直达
  • 验签流程
  1. BL1 加载可信启动固件证书(ID=6)
  2. BL1 用固化的ROTPK根公钥,验证ID6证书的数字签名
  3. 验签通过后,从ID6证书中提取BL2的期望哈希
  4. BL1 计算实际加载的BL2镜像哈希,与期望哈希对比,匹配则校验通过
  • 验签执行方:BL1

2. BL31 固件(ID=3)

  • 信任链长度:3级证书
  • 验签流程
  1. BL2 加载可信密钥证书(ID=7),用ROTPK验签,提取可信世界公钥
  2. BL2 加载SoC固件密钥证书(ID=9),用可信世界公钥验签,提取BL31内容公钥
  3. BL2 加载SoC固件内容证书(ID=13),用BL31内容公钥验签,提取BL31期望哈希
  4. BL2 计算实际BL31镜像哈希,对比匹配则校验通过
  • 验签执行方:BL2

3. BL32 固件(ID=4,OP-TEE)

  • 信任链长度:3级证书
  • 验签流程
  1. BL2 加载可信密钥证书(ID=7),用ROTPK验签,提取可信世界公钥
  2. BL2 加载可信OS固件密钥证书(ID=10),用可信世界公钥验签,提取BL32内容公钥
  3. BL2 加载可信OS内容证书(ID=14),用BL32内容公钥验签,提取BL32期望哈希
  4. BL2 计算实际BL32镜像哈希,对比匹配则校验通过
  • 验签执行方:BL2

4. BL33 固件(ID=5,U-Boot)

  • 信任链长度:3级证书
  • 验签流程
  1. BL2 加载可信密钥证书(ID=7),用ROTPK验签,提取非可信世界公钥
  2. BL2 加载非可信固件密钥证书(ID=11),用非可信世界公钥验签,提取BL33内容公钥
  3. BL2 加载非可信内容证书(ID=15),用BL33内容公钥验签,提取BL33期望哈希
  4. BL2 计算实际BL33镜像哈希,对比匹配则校验通过
  • 验签执行方:BL2

五、架构设计的安全考量

  1. 根密钥最小化使用:根私钥仅签发两张顶层证书,全程离线保存,最大程度降低泄露风险;即使子密钥泄露,也无需更换根密钥,只需吊销对应子证书即可。
  2. 安全域隔离:安全世界与非安全世界使用独立的密钥分支,避免非安全域密钥泄露影响安全域固件的可信性。
  3. 权限最小化:内容证书仅能校验单一份固件的哈希,无法派生其他信任,单证书被攻破不会影响整个信任链。
  4. 标准兼容:所有证书遵循X.509 v3标准,可直接用OpenSSL等通用工具签发与解析,兼容现有PKI体系。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值