Secure Boot

分类于 ， 阅读次数： Disqus： 本文字数： 2.1k 阅读时长 ≈ 8 分钟

目的

安全启动的根本目的是为了防止消费者从软硬件层面对产品的部分关键系统进行读写、调试等高权限的操作。以限制消费者的能力，来达到保护产品的商业机密、知识产权等厂家权益的目的。当然，厂家是不会这样宣传 Secure Boot 的。他们的文案通常都是通过这项技术保护用户的隐私，防止恶意软件修改系统软硬件等等。

可以说，Secure Boot 的安全模型建立在消费者是攻击者这一假设上。消费者在物理上拥有产品硬件，可以对产品进行物理连接、拆机、改装等等物理上的操作，比较专业的消费者甚至可以使用数字示波器监听 CPU 和 RAM 、eMMC 之间的数据传输来读取非常底层的数据传输。可以说跟传统的安全模型中的攻击者相比根本不在一个层面上。

消费者作为攻击者的目的，一般常见的有刷机安装自定义的操作系统（Mod）、绕过厂家封闭的支付平台（IAP）和应用商城安装自定义的应用程序、绕过版权保护系统（DRM）达到复制厂家保护的数字产品内容等等。这些操作往往都会直接影响厂家的利益，因此需要一种能抵抗消费者攻击的安全机制。

而且像 eMMC 这种芯片通常都是业界标准化的，攻击者甚至可以把芯片拆下来，然后用市面上现成的通用 eMMC 编程工具来读写上面的内容。

Secure Boot 安全机制的原理，就是将最为核心的安全机制整合到最关键的主 CPU 中。因此就算攻击者可以监听电路板上的线路，甚至拆装个别芯片单独调试，也无法破坏 Secure Boot 的安全机制。

TA的安全性

保证TA的安全需要做到三点：

  • 唯一性：由设备厂商发布，确保是由设备厂商自己发布的，而不是经过客户自己替换的
  • 完整性：除了要保证TA是由设备厂商发布外还需要确保其内容没有经过改动，被用户修改了TA里面的内容
  • 保密性：内容经过加密，别人从系统中导出TA固件也无法获取真实的信息，无法解密

唯一性（通过签名解决RSA）

有两种实现方式：

  • root key由设备厂商自己持有，也就是说rsa的pub key和 priv key都由设备厂商自己持有，那么别人自然无法获取key，pub key packing到bl32中，只要能正确解密就能保证是设备厂商发布的
  • ic厂默认做了一级签名，也就是root key由ic厂持有，这个时候客户就需要将自己的pub key 加密后packing到TA中，但是这存在一个问题就是BL32如何解密设备厂商加密后的pub key，这就涉及到证书了，设备厂商需要向ic厂商申请数字证书（ic厂商用root priv key对客户的pub key加密），这样BL32里本身持有IC的Root pub key就可以通过数字证书获得设备厂商 pub key，然后验证TA的唯一性，并通过AES解密获得TA内容。

完整性（对TA的hash值进行校验）

对TA进行hash运算生成摘要信息，然后将hash值加密后添加到TA头中，BL32读取并解密该hash值并且自己再算一遍TA程序的hash值，两个值一样则说明TA是完整的，没有经过修改的。

保密性（加密AES）

由AES加密和解密，其key也需要经过RSA加密保护。

这里有一点非常关键就是BL32里的root pub key不能被篡改，或者说BL32不能被串改，BLx的安全性由Secure Boot来保证。Secure Boot保证启动的每一级都是安全的不会被篡改，任何一级被串改都将导致系统启动失败。而Secure Boot的安全性是由OTP/eFuse保证的，只要这里面的内容不被破解那么后续的每一级启动都需要上一级的key来验证，BL1的启动由OTP或efuse里的key来验证，每一级都经过设备厂商的签名认证保证启动的每一个环节都是安全的。当然如果OTP/eFuse被破解了那就不能保证安全了。

ATF启动流程

restart--冷启动

reset--热启动

ATF冷启动实现分为5个步骤：

  • BL1 - AP Trusted ROM，一般为BootRom。
  • BL2 - Trusted Boot Firmware，一般为Trusted Bootloader。
  • BL31 - EL3 Runtime Firmware，一般为SML，管理SMC执行处理和中断，运行在secure monitor中。
  • BL32 - Secure-EL1 Payload，一般为TEE OS Image。
  • BL33 - Non-Trusted Firmware，一般为uboot、linux kernel。

ATF输出BL1、BL2、BL31，提供BL32和BL33接口。

启动流程如下：

BL1

BL1位于ROM中，在EL3下从reset vector处开始运行。（bootrom就是芯片上电运行的（chip-rom的作用就是跳转到bootrom））

BL1做的工作主要有：

  • 决定启动路径：冷启动还是热启动
  • 架构初始化：异常向量、CPU复位处理函数配置、控制寄存器设置(SCRLR_EL3/SCR_EL3/CPTR_EL3/DAIF)
  • 平台初始化：使能Trusted Watchdog、初始化控制台、配置硬件一致性互联、配置MMU、初始化相关存储设备
  • 加载 Secure Boot Key 等密钥
  • 从 eMMC 加载并验证 First Stage Bootloader（FSBL）
  • 固件更新处理
  • BL2镜像加载和执行
  • BL1输出“Booting Trusted Firmware"
  • BL1加载BL2到SRAM；如果SRAM不够或者BL2镜像错误，输出“Failed to load BL2 firmware.”
  • BL1切换到Secure EL1并将执行权交给BL2

BL2

BL2运行于SRAM中，运行在Secure EL1主要工作有：

  • 架构初始化：EL1/EL0使能浮点单元和ASMID
  • 平台初始化：控制台初始化、相关存储设备初始化、MMU、相关设备安全配
  • SCP_BL2：系统控制核镜像加载，单独核处理系统功耗、时钟、复位等控制
  • 加载BL31镜像：BL2将控制权交给BL1；BL1关闭MMU并关cache；BL1将控制权交给BL31
  • 加载BL32镜像：BL32运行在安全世界，BL2依赖BL31将控制权交给BL32。SPSR通过Secure-EL1 Payload Dispatcher进行初始化
  • 加载BL33镜像：BL2依赖BL31将控制权交给BL33

BL31

BL31位于SRAM中，EL3模式。除了做架构初始化和平台初始化外，还做了如下工作：

  • PSCI服务初始化，后续提供CPU功耗管理操作
  • BL32镜像运行初始化，处于Secure EL1模式
  • 初始化非安全EL2或EL1，跳转到BL33执行
  • 负责安全非安全世界切换
  • 进行安全服务请求的分发

每个镜像都经公钥验证，公钥存储在已签名的证书中，并可追溯到存储在 SoC 上的一次性可编程 (OTP) 存储器中或 ROM 中的根密钥。

ARMv8安全引导的过程

ARMv8架构之后ARM提供了ATF, BootLoader、TEE镜像文件、Linux内核镜像文件、recovery镜像文件都是由ATF来进行引导和加载而不是由ChipRom来完成的。

ChipRom只会去验证ATF中bl1的合法性，后续引导过程同样也是按照链式验签的方式进行，符合TBBR规范。读者可使用git命令从gitHub上获取ATF的所有源代在ARMv8架构中整个安全引导的流程如图下所示。

ARMv8架构中引入了ATF，同时在ATF中提供了安全引导的功能，BootLoader镜像、Linux内核、recovery镜像和TEE OS镜像文件的签名方式都由ATF决定。当然开发者也可以对ATF进行定制化，修改ATF中的验签过程，但是修改后的验签方案需要符合TBBR规范。

通过Secure Boot来保证BL32的安全性，然后由BL32来保证TA的安全性，这样就实现了TEE的安全操作环境。

参考文献

https://www.eet-china.com/mp/a329968.html
https://juejin.cn/post/7267839163502739511