STM32MP2安全启动技术深度解析

一、引言

在嵌入式系统领域，安全启动（Secure Boot）是保护设备安全的第一道防线。对于STM32MP2系列微处理器而言，安全启动机制不仅能确保系统固件的完整性，还能验证启动链中每个环节的签名，防止恶意代码在设备上运行。本文将深入解析STM32MP2的安全启动架构，帮助开发者全面理解其工作原理与实现细节。

安全启动的核心目标是在系统上电后，从最早的启动阶段开始，逐步验证每一级软件组件的完整性。只有通过验证的固件才能获得执行权限，任何未通过签名验证的代码都将被拒绝执行。这种链式验证机制有效地防止了恶意固件注入攻击，为设备提供了可信的执行环境。

二、安全启动架构概述

STM32MP2的安全启动采用多级验证架构，从初始启动加载器（FSBL）开始，逐级向上验证后续的固件组件。整个启动链包括FSBL（初始启动加载器）、OP-TEE（可信操作系统）、U-Boot（通用启动加载器）以及最终的可运行内核。每个阶段的启动文件都经过签名处理，验证过程依赖于预先烧录的公钥哈希值。

这种分层架构的优势在于，即使攻击者能够替换某一级的固件，也无法通过后续阶段的验证。每一级的验证都使用前一级或更早阶段提供的公钥进行校验，形成了严密的信任链。整个信任链的根节点是OTP（一次性可编程）存储器中烧录的公钥哈希，这确保了根密钥的不可篡改性。

2.1 启动流程详解

设备上电后，首先执行的是ROM代码中的初始启动程序。这段代码被烧录在芯片内部掩模 ROM 中，无法被修改或替换。ROM代码会读取外部存储设备（如eMMC、NAND Flash或SD卡）中的FSBL镜像，对其进行签名验证。验证使用OTP中烧录的公钥哈希值进行，如果验证通过，FSBL将被加载到内部SRAM中执行。

FSBL执行后，其主要任务包括配置时钟、初始化DDR内存以及加载下一阶段的启动文件。对于安全启动配置，FSBL还需要初始化加密引擎并准备验证OP-TEE的签名。OP-TEE作为可信执行环境，负责运行敏感的安全功能，如密钥管理和安全存储。FSBL完成这些初始化工作后，会验证并加载FIP（Firmware Image Package）镜像包。

FIP镜像包包含了OP-TEE、可信文件系统以及其他安全相关的固件组件。FSBL会使用预先配置的公钥对FIP中的各个组件进行验证，确保其完整性和真实性。通过验证后，FIP中的各个组件将被加载到各自指定的内存区域，并开始执行。

2.2 信任链的建立

信任链的建立从OTP中的公钥哈希开始。OTP是一种不可修改的存储区域，一旦烧录后，内容将永久保持不变。这使得根密钥具有了最高的可信度。开发阶段可以在OTP中烧录测试公钥，产品发布时再替换为生产公钥。

每一级的启动加载器都负责验证下一级固件的签名。这种设计确保了信任链的连续性。任何一级验证失败都将导致启动过程终止。开发者可以根据安全需求选择不同的密钥算法，目前STM32MP2支持RSA-2048和RSA-4096两种密钥长度。

三、密钥与签名管理

3.1 密钥生成流程

安全启动需要一对密钥：私钥用于对启动镜像进行签名，公钥则被嵌入到设备中用于验证签名。私钥必须妥善保管，任何获得私钥的人都可以为恶意固件签名，从而绕过安全启动机制。在实际开发中，通常使用OpenSSL工具生成密钥对。

生成RSA-4096密钥对的命令如下所示：

openssl genrsa -out firmware.key 4096
openssl rsa -in firmware.key -pubout -out firmware.pub

生成的私钥必须妥善备份并保管，建议存放在安全的硬件TOKEN中或专用的密钥管理系统中。公钥则需要转换为特定格式，最终被烧录到OTP中。需要注意的是OTP烧录是不可逆操作，烧录前务必确认公钥的正确性。

3.2 固件签名过程

固件签名是安全启动流程中的关键步骤。开发者需要使用私钥对每个启动镜像进行签名，生成的签名文件将与原始镜像一同发布。STM32MP2提供了专门的签名工具，支持多种镜像格式。

签名FSBL镜像的基本命令如下：

stm32image --sign fsbl.stm32 fsbl.signature firmware.key

对于FIP镜像包，签名过程稍有不同，需要对整个FIP文件进行签名，而不是单独签名其中的每个组件。签名前需要确保FIP的格式符合规范，所有组件按要求排列。签名工具会计算镜像的哈希值，并使用私钥对该哈希进行加密，生成签名数据。

签名验证则在启动过程中自动进行。ROM代码或FSBL会读取镜像的公钥区域，使用对应公钥解密签名得到哈希值，然后计算镜像的实际哈希值进行比对。两者一致则说明镜像未被篡改，可以安全执行。

四、FIP镜像包详解

FIP（Firmware Image Package）是STM32MP2用于打包多个启动镜像的文件格式。FIP将OP-TEE、可信文件系统、U-Boot等组件打包在一起，便于管理和加载。FIP格式支持在单个文件中有序存放多个镜像，每个镜像都有其特定的偏移地址和大小。

4.1 FIP结构

FIP文件由头部和多个镜像数据块组成。头部包含FIP版本、镜像数量等信息，每个镜像数据块包含镜像类型、偏移、大小和签名。FIP工具负责将各个组件按照规范打包，并计算相应的偏移地址。

FIP头部的结构定义如下：

typedef struct {
    uint32_t version;
    uint32_t number_of_images;
    uint64_t flags;
} fip_header_t;

每个镜像的数据块紧随头部之后，包括镜像的类型标识、加载地址、执行地址、大小以及指向实际数据的偏移量。这种设计允许启动加载器灵活地加载各个组件到不同的内存位置。

4.2 FIP创建工具

ST提供了fip-create工具用于创建FIP镜像。该工具接受配置文件作为输入，配置文件描述了各个镜像的路径、类型和属性。以下是一个典型的FIP配置文件示例，包含了可信固件和U-Boot两个主要组件。

# FIP configuration
[TrustedFirmware]
    path = tee.bin
    offset = 0x0
    size = 0x80000

[Uboot]
    path = u-boot.dtb
    offset = 0x100000
    size = 0x80000

使用配置文件创建FIP的命令如下：

fip-create --config fip.conf --output fip.bin

创建过程中，工具会计算各个组件的大小和偏移，并生成相应的FIP头部。生成的FIP文件可以直接被FSBL加载和验证。

五、OTP配置与烧录

OTP（One-Time Programmable）存储器是安全启动的根基。OTP中存储了用于验证启动镜像的公钥哈希值，以及各种安全配置位。OTP的烧录过程是不可逆的，一旦烧录完成就无法修改，因此必须谨慎操作。

5.1 OTP分区结构

STM32MP2的OTP分为多个区域，每个区域有不同的用途。公钥哈希存储在专门的公钥区域，可以存放多个公钥以支持密钥轮换。安全配置位用于控制安全功能的开关，包括安全启动使能、调试接口禁用等。

OTP的基本布局如下表所示：

区域	大小	用途
公钥区域	512字节	存储公钥哈希
配置位	64字节	安全配置选项
内部信息	128字节	芯片相关信息

开发阶段可以使用ST提供的工具对OTP进行读写操作，进行测试和调试。产品发布前，必须将正确的公钥哈希烧录到OTP���，��使能安全启动位。

5.2 烧录流程

公钥哈希的烧录需要先将公钥转换为特定的二进制格式。这一转换过程使用专门的工具完成，转换后生成的文件可以直接烧录到OTP的指定区域。以下是公钥格式转换的命令：

stm32key --pubkey firmware.pub --hash hash.bin

生成哈希文件后，使用Flash烧录工具将哈希值写入OTP。需要特别注意的是，OTP烧录是按位进行的，只能从0写为1，无法从1改写为0。这意味着如果烧录错误，该区域将永久无法使用。

烧录完成后，可以读取OTP进行验证，确认公钥哈希已正确存储。验证命令如下：

stm32key --verify hash.bin

六、调试与常见问题

6.1 调试方法

安全启动的调试相对复杂，因为失败后系统无法继续启动。开发初期建议先在非安全模式下验证各组件的功能，确认正常工作后再使能安全启动。ST提供了安全的调试方案，允许在特定条件下启用调试接口。

当安全启动验证失败时，芯片会进入恢复模式，等待通过调试接口进行修复。开发者可以使用ST-Link工具连接芯片，读取启动失败的具体原因。根据错误信息，可以确定是签名验证失败还是其他问题。

常见的启动失败原因包括：公钥不匹配导致验证失败、镜像损坏导致哈希不一致、以及启动地址配置错误。针对不同的问题，需要采取不同的修复措施。公钥问题需要重新烧录正确的公钥哈希，镜像问题需要重新签名并部署固件。

6.2 安全注意事项

在开发和生产过程中，必须严格管理私钥的安全。私钥泄露会导致安全启动机制完全失效。任何获得私钥的人都可以为恶意固件签名，从而绕过安全检查。建议使用硬件安全模块（HSM）管理生产私钥。

调试接口的管理也需要特别注意。默认情况下，STM32MP2允许通过调试接口访问芯片。建议在产品发布前禁用调试接口，或设置适当的访问控制。OTP中的调试锁定位可以控制调试接口的访问权限。

七、总结

STM32MP2的安全启动机制为嵌入式设备提供了强有力的保护。通过链式验证，每一级启动固件都能得到有效保护。OTP提供了不可篡改的根信任基础，确保了密钥的安全性。开发者需要仔细理解各个组件的作用和相互关系，才能正确实现安全启动。

在实际开发中，建议按照本文描述的流程逐步实施：先在非安全模式下完成功能开发，然后生成密钥对并进行测试固件签名，最后在产品发布前完成OTP烧录和调试接口锁定。通过规范的开发流程，可以有效避免开发过程中的各种问题。