12

Khorina · 11月4日

Armv8的安全启动

目录

  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作为整体解决方案,开源库地址:https://www.trustedfirmware.org/

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

image.png

其中,

  • 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个单独启动阶段,每个阶段运行在不同的内核异常等级,流程如下:

image.png

每个阶段功能定义如下:

  • 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

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

image.png

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

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

3. TF-M启动流程

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

image.png

如上图所示,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/...

它是整个安全启动的核心所在,主要用于验证其他固件的身份和完整性,但由于这部分又是开源的,因此每家芯片厂在实现时又会有所差别。

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

image.png

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

image.png

PS:HDP(secure hide-protection area)

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

image.png

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

image.png

4.小结

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

END

作者:快乐的肌肉
文章来源:汽车MCU软件设计

推荐阅读

更多物联网安全,PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入PSA技术交流群,请备注研究方向。
推荐阅读
关注数
4569
内容数
186
Arm发布的PSA旨在为物联网安全提供一套全面的安全指导方针,使从芯片制造商到设备开发商等价值链中的每位成员都能成功实现安全运行。
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息