做煤的网站app做网站备案是个人还是企业好
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认证框架也支持镜像加密功能。在启动流程中，如果镜像被加密，首先需要对其进行解密，然后才执行认证流程。
参考
- Trusted Board Boot Requirements Client (TBBR-CLIENT) Armv8-A
- Trusted Firmware-A Documentation
欢迎关注“安全有理”微信公众号。
