Armv8的安全启动

目录

[1. Trust Firmware](#1. Trust Firmware)

[2. TF-A启动流程](#2. TF-A启动流程)

[3. TF-M启动流程](#3. TF-M启动流程)

[3.1 BL1](#3.1 BL1)

[3.2 BL2](#3.2 BL2)

4.小结


在之前汽车信息安全 -- 再谈车规MCU的安全启动文章里,我们详细描述了TC3xx 、RH850、NXPS32K3的安全启动流程,而在车控类ECU中,我们也基本按照这个流程去设计代码,同时兼顾主机厂对启动时间和安全性的要求,

但是最近在移植某国产HSM IP的固件代码时,被其安全启动流程一些概念搞得云里雾里,例如OPTEE、TF-A、RMM,SPE等等;

在Cortex-R52逐渐在区域控制器大放异彩的今天,梳理下基于Armv8的安全启动,理清这些概念,是对自己的视野拓展。

1. Trust Firmware

在Armv8架构里,ARM为安全引入了Trust Firmware作为整体解决方案,开源库地址:Trusted Firmware - Open Source Secure Software

根据官网介绍,TF为Armv8-A和Armv8-M提供了安全软件的参考实现,为SoC开发人员和oem提供了符合相关Arm规范的参考可信代码库。

其中,

  • TF-A (Trusted Firmware-A,也叫ATF)是专门为Armv7\v8-A架构内核设计的参考安全固件;
  • TF-M则是为Armv8-M、Armv8.1-M架构(如Cortex-M33、M55等)提供了安全处理环境(SPE,Secure Processing Environment)的参考实现。

那么今天就从TF-A开始,先把最抽象的啃点,再看TF-M就容易理解很多。

2. TF-A启动流程

TF-A(AArch64)的启动引导过程一共分为5个单独启动阶段,每个阶段运行在不同的内核异常等级,流程如下:

每个阶段功能定义如下:

  • BL1(Boot Loader stage 1):BL1一般指运行存放在芯片内部BootROM的代码,这部分代码由SoC厂商在芯片流程时固化进去,不能再做修改;该阶段运行在Armv8的EL3等级,如果支持安全启动,BootROM在构建信任链的时候就显得尤为关键,主要用于校验BL2 Boot Firmware并完成加载和跳转,这也是和目前接触过的车规MCU安全启动流程最明显的区别;
  • BL2(Boot Loader stage 2:):Boot Firmware由BL1从引导介质中(例如NOR Flash、SD/eMMC)加载运行(例如DDR),它的主要作用是初始化平台所需要存储介质、配置MMU、校验BL31\32\33并完成加载等,值得注意,BL2依旧运行在EL3等级。
  • BL31(Boot Loader Stage 3-1):BL2加载BL31后,并把控制权交由BL31(此时仍旧运行在EL3等级),从上图可以看到BL31仍旧需要运行在可信RAM中,它主要为引导加载程序和操作系统提供初始化服务,例如GIC初始化、电源控制设备初始化、MMU使能和重定向等等;完成上述初始化后,如有BL32 trusted OS镜像,BL31加载BL32并跳转运行;
  • BL32:可信的操作系统,例如OP-TEE(Open source Project Trusted Execution Environment )、安卓Trusty TEE
  • BL33:常见的Bootloader(U-Boot/UEFI),运行在Armv8 EL2等级,完成启动后运行Kernel

在开源库中每个阶段都可以单独进行编译,因此很明显启动流程可以根据需求进行裁剪,

但值得一提的是,上述启动流程有个前提假设:那就是这些镜像文件存储的物理介质一般都不支持xip,所以需要在启动时将上述镜像加载到SRAM或者DDR上运行;这是与带有eFlash的MCU的安全启动流程的另一个明显区别。

既如此,我们就来看看TF-M的流程。

3. TF-M启动流程

TF-M(Trusted Firmware-M)主要是为Armv8-M架构的内核提供了一个安全运行处理环境(SPE),如下图所示:

如上图所示,TF-M包含了上图深蓝色框的所有功能,其中蓝底背景的叫做PSA-RoT(Platform Security Architecture Root of Trust),主要功能模块包括:

  • Secure Boot:用于验证SPE和NSPE的镜像是否可信;
  • TF-M Core:用于SPE和NSPE的安全通信(IPC)、中断处理、隔离等等;
  • 加解密服务、安全存储、受保护存储、安全升级等等

今天主要看看Secure Boot。

与TF-A,TF-M的安全启动只分为了BL1和BL2。

3.1 BL1

BL1 Immutable bootloader:翻译过来就是不可变的引导程序,它在安全启动时和公钥(ROTPK)共同构成信任根,因此这段bootloader代码必须存储在ROM或者支持写保护的Flash,ROTPK可以存放在OTP。

如果一些芯片本身ROM就有启动代码且没有安全Flash存储TF-M,那么TF-M的BL1就必须进行验证,以保证信任链的构建。

从这里突然就反应过来,之前英飞凌TC3xx提出的安全启动方案要求HSM BL存放在OTP中,很大部分原因就是HSM的BootROM并没有提供任何验证HSM BL的机制。

3.2 BL2

在TF-M中,BL2默认使用MCUboot开源代码,链接https://github.com/mcu-tools/mcuboot。它是整个安全启动的核心所在,主要用于验证其他固件的身份和完整性,但由于这部分又是开源的,因此每家芯片厂在实现时又会有所差别。

以STM32U5为例,基于MCUboot框架设计了SBSFU(Secure Boot and Secure Firmware Update),主要用于安全启动和安全升级。它将这部分代码固定在Flash存储器某个位置,这时候从PSA架构和TFM secure boot程序映射可以满足要求,如下:

一旦从TFM_SBSFU_Boot (Secure Boot and Secure Firmware Update software)应用程序跳转到安全应用程序时,所有专用于执行TFM_SBSFU_Boot 的 Flash 存储器区域均被隐藏,安全和非安全主插槽区域允许执行。

PS:HDP(secure hide-protection area)

SBSFU提供了多种验签和加密机制,如下:

同时也给出了安全启动的时间评估参数:

4.小结

随着ARM内核的MCU逐渐进入到汽车市场,必须要掌握TF-A\M的一些概念;同时我也很好奇,像Steller这种R52内核的芯片是如何设计其安全启动流程。毕竟在HSM普及的今天,信任根的变化会影响一个系统的架构设计,

相关推荐
阿龟在奔跑1 小时前
引用类型的局部变量线程安全问题分析——以多线程对方法局部变量List类型对象实例的add、remove操作为例
java·jvm·安全·list
.Ayang1 小时前
SSRF漏洞利用
网络·安全·web安全·网络安全·系统安全·网络攻击模型·安全架构
.Ayang1 小时前
SSRF 漏洞全解析(概述、攻击流程、危害、挖掘与相关函数)
安全·web安全·网络安全·系统安全·网络攻击模型·安全威胁分析·安全架构
好想打kuo碎1 小时前
1、HCIP之RSTP协议与STP相关安全配置
网络·安全
周全全2 小时前
Spring Boot + Vue 基于 RSA 的用户身份认证加密机制实现
java·vue.js·spring boot·安全·php
Mr.Pascal2 小时前
刚学php序列化/反序列化遇到的坑(攻防世界:Web_php_unserialize)
开发语言·安全·web安全·php
风间琉璃""3 小时前
二进制与网络安全的关系
安全·机器学习·网络安全·逆向·二进制
dot.Net安全矩阵4 小时前
.NET 通过模块和驱动收集本地EDR的工具
windows·安全·web安全·.net·交互
Hacker_Oldv5 小时前
网络安全的学习路线
学习·安全·web安全