本章主要介绍ATF中出现的CoT证书链和相关概念。1.密钥和信任链概念参考和引用:TrustedBoardBootRequirements(TBBR)specif
本章主要介绍ATF中出现的CoT证书链和相关概念。
1. 密钥和信任链概念
参考和引用:
Trusted Board Boot Requirements (TBBR) specification, Arm DEN0006C-1
信任链(CoT)组件,在Arm开发平台上,这些组件是:
- 信任根公钥(ROTPK)的SHA-256。 它存储在受信的根密钥存储寄存器中。
- BL1镜像,假设它在ROM中,不能被篡改。
CoT中的其余组件是证书或Bootloader镜像。 证书遵循X.509 v3标准。 此标准允许向证书添加自定义扩展,这些扩展用于存储建立CoT的基本信息。
在TBB CoT中,所有证书都是自签名的。 不需要证书颁发机构(CA),因为CoT不是通过验证证书颁发者的有效性而是通过证书扩展的内容来建立的。 要对证书进行签名,使用带有RSA加密签名方案的PKCS#1 SHA-256,RSA密钥长度为2048位。 TF-A的未来版本将支持其他加密算法。
证书分为“密钥(Key)”和“内容(content)”证书两种。 密钥证书用来验证用于签名内容证书的公钥。内容证书用来保存boot loader 镜像的hash。认证方式是通过计算BLx的hash与从内容证书中提取出来的hash值比较。Hash =SHA-256(BLx bin). 公钥和hash值会放在X.509 v3证书的 non-standard extension字段。
用于建立CoT的密钥是:
- Root of trust key
他的私钥用来给BL2的内容证书和密钥证书签名
他的公钥称为ROTPK.
- Trusted world key
私钥用来给secure world images (SCP_BL2, BL31 and BL32)的密钥证书签名
公钥保存在自签名的Trusted world key证书extension 域中
- Non-trusted world key
私钥来给non secure world images (BL33)的密钥证书签名
公钥保存在Trusted world key证书的extension 域中
- BL3-X keys
对于SCP_BL2, BL31, BL32 and BL33, 私钥用来给BL3-X的内容证书签名
公钥保存在对应的密钥证书的extension 域.
CoT包括以下镜像:
- BL1
- BL2
- SCP_BL2 (optional)
- BL31
- BL33
- BL32 (optional)
以下证书用来认证镜像:
- BL2 内容证书
一个ROT key私钥的自签名证书。内容包括BL2的hash
- Trusted key certificate
一个ROT key私钥的自签名证书。内容包括trusted world key的公钥和non-trusted world key的公钥
- SCP_BL2 key certificate
一个 trusted world key自签名证书。内容包括SCP_BL2 key的公钥.
- SCP_BL2 content certificate
一个SCP_BL2 key自签名证书。内容包括SCP_BL2 的hash.
- BL31 key certificate
一个 trusted world key自签名证书。内容包括BL31 key的公钥.
- BL31 content certificate
一个BL31 key自签名证书。内容包括BL31 的hash
- BL32 key certificate
一个 trusted world key自签名证书。内容包括 BL32 key的公钥.
- BL32 content certificate
一个BL32 key自签名证书。内容包括BL32 的hash
- BL33 key certificate
一个non-trusted world key自签名证书。内容包括BL33 key的公钥.
- BL33 content certificate
一个BL33 key自签名证书。内容包括BL33 的hash
SCP_BL2 ,BL32 证书是可选的, 如果SCP_BL2 or BL32 存在,则为必选。
2. X509 v3 & PKCS1
PKCS1作为签名算法,ARM目前支持的算法为:SHA256+RSA2048,这是一种相对简单且古老的签名算法,PKCS#1签名算法有两种签名方案:
RSASSA-PSS和RSASSA-PKCS1-v1_5。
而X509证书,作为证书内容(签名信息+公钥+签名)的内容的封装,同样有两种格式:
PEM(.pem)和DER(.cer,.crt),分别为可读的base64编码的文本文件和DER编码的二进制文件。
ARM明确指出了使用DER编码。
X509证书内容的编码是ASN.1。
关于X509和PKCS#1,有时间我会详细说明pkcs体系和在嵌入式安全领域的应用。
3. Trusted Board Boot 流程
CoT按照下面的步骤验证。如果任何步骤失败,系统会panic。
1. BL1加载并验证BL2内容证书。从验证的证书中读取颁发者公钥。计算该密钥的散列并将其与从受信任的根密钥存储寄存器读取的ROTPK的散列进行比较。如果它们匹配,则从证书中读取BL2哈希。
BL2内容证书 = Sign(ROT key PrK, ROT key PK+ ext::BL2 hash)
注:ROT key PK = ROTPK
注意:比较操作是特定于平台的,目前在Arm开发平台上未实现。在其他平台上,是SoC厂商自行实现的。
多说一句,比较操作作为认证过程的核心,也是有讲究的,需要考虑对各种攻击的保护,比如glitch攻击,穷举攻击等,通常的做法,是进行二次比较,并在两次比较之间插入随机的delay以防止对比较结果(即 返回值x0,r0)的攻击。第一次比较采用相等比较,而第二次,采用不等比较:
if(!memcmp(calc_hash,file,len) ){//对第一次比较的代码执行时间点很容易预测,所以放弃保护delay(r1);//r1 为真随机数if(memcmp(calc_hash,file,len)){//相比于第一次,对第二次比较的代码执行时间点则不容易预测return -EAUTH;}
}else{delay(r2);//r1 为真随机数return -EAUTH;
}
return 0;//认证成功
到第三步,BL1获取了经过验签的ROTPK和BL2 hash。
2. BL1加载BL2镜像。计算其哈希值并与从证书中读取的哈希值进行比较。如果所有比较都成功,则控制转移到BL2镜像。这一步,经过验签的BL2执行成功
3. BL2加载并验证 trusted key 证书。从验证的证书中(BL2内容证书)读取颁发者公钥(ROTPK)。计算该密钥的hash并将其与从受信任的根密钥存储寄存器读取的ROTPK的散列进行比较。如果比较成功,BL2将从已验签的证书中读取并保存trusted world PK+ non-trusted world PK。
trusted world key证书 = Sign(ROT key PrK, ROT key PK+ext::trusted world PK+ non-trusted world PK)
SCP_BL2,BL31和BL32都会执行步骤4,5。如果这些镜像不存在,则跳过可选SCP_BL2和BL32镜像的步骤,只看BL31
4. BL2加载并验证BL3x密钥证书。使用 trusted world public key验证证书签名。如果签名验证成功,BL2将从证书中读取并保存BL3x公钥。
BL31 key certificate = Sign(trusted world PrK, trusted world PK, ext::BL31 PK)
5. BL2加载并验证BL3x内容证书。 使用BL3x公钥验证签名。 如果签名验证成功,BL2将从证书中读取并保存BL3x镜像Hash。
BL31 content certificate = Sign(BL31 PrK, BL31 PK ,ext::hash(BL31))
接下来的两个步骤仅针对BL33执行。
6. BL2加载并验签BL33 密钥证书。如果验签成功,BL2从BL33 密钥证书中读取并保存BL33公钥
BL33 key certificate = Sign(non-trusted world PrK, non-trusted world PK, ext::BL33 PK)
7. BL2加载并验签BL33内容证书,如果验签成功,BL2从BL33 内容证书中读取并保存BL33的hash
BL33 content certificate = Sign(BL33 PrK, BL33 PK ,ext::hash(BL33))
下一步骤针对所有的BL image
8.BL2计算镜像hash,与从内容证书中获取的hash进行比较。如果hash相同则镜像认证成功
9.结束
ARM提供了一个证书生成工具,添加到BL镜像和FIP镜像中,ARM要求使用IO storage framework读取这些证书,并使用 Authentication module 进行认证。
本章结束