目录
1. Trust Firmware
2. TF-A启动流程
3. TF-M启动流程
3.1 BL1
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普及的今天,信任根的变化会影响一个系统的架构设计,