Series 2 安全启动：RTSL 信任根与 Secure Engine

保护物联网设备免受安全威胁是优质产品的核心要素。Silicon Labs 通过在 Series 2 产品中引入 Secure Engine（安全引擎），显著增强了安全性供给。Secure Engine 是一个防篡改组件，用于安全地存储敏感数据和密钥、执行加密功能并提供安全服务。基于 RTSL（Root of Trust and Secure Loader）的 Secure Boot 确保只有经过可信签名的固件才能在设备上运行。

Series 2 设备安全特性概述

Secure Engine（SE）

Series 2 设备中的安全引擎，负责安全引导、密钥存储和加密服务。可以是硬件实现（HSE）或虚拟实现（VSE）。

Secure Vault

在 SE 基础上提供额外安全特性，分为 High（SVH）、Mid（SVM）和 Base（SVB）三个等级，提供不同级别的保护。

Secure Boot

初始引导阶段从不可变存储器（ROM）执行代码，在被授权执行之前对固件进行身份验证，防止未受信任的映像运行。

Secure Debug Access Control

锁定调试端口访问以确保操作安全，并在授权实体需要时安全地解锁调试访问。

Secure Engine 类型

缩写	说明
HSE	Hardware Secure Engine（硬件安全引擎）
VSE	Virtual Secure Engine（虚拟安全引擎）
SE	Secure Engine（泛指 HSE 或 VSE）

Secure Vault 等级

等级	SE 支持	包含特性
Secure Vault High (SVH)	HSE only (HSE-SVH)	Secure Key Storage、Anti-Tamper Protection、Device Authentication
Secure Vault Mid (SVM)	HSE-SVM 或 VSE-SVM	Secure Boot、Secure Debug Access Control
Secure Vault Base (SVB)	N/A	基础安全特性

Secure Boot 原理

信任根（Root of Trust）

Secure Boot 的本质是建立并维护信任链。信任链中的第一个链环是信任根，其安全强度在于不变性——信任根的固件来源于 ROM，Public Sign Key 也存储于 ROM 中。在 Series 2 设备中，信任根在 ROM 中实现，Secure Engine 在 ROM 中运行代码，检查可升级的 GBL（Main Bootloader）的完整性和真实性。

与 Series 1 设备不同，Series 1 的信任根（First-Stage Bootloader）位于闪存而非 ROM，且仅使用 CRC32 校验和（非签名）验证 Main Bootloader 的完整性。Series 2 提供了更强的硬件级安全保证。

两阶段引导设计

Series 1 和 Series 2 设备均使用两阶段引导设计：

不可升级的第一阶段（信任根）：Series 1 为 First-Stage Bootloader，Series 2 为 SE ROM
可升级的第二阶段（SSB/Main Bootloader）：用于验证和升级 Application 固件

ECDSA-P256-SHA256 Secure Boot 流程

Series 1 设备流程

在 Series 1（SVB）设备上，Secure Boot 从闪存启动，GBL 第一阶段检查是否有针对第二阶段的升级待决，若已启用 Secure Boot，则 GBL 第二阶段在执行前检查 Application 映像的完整性和真实性。若完整性检查失败，程序控制权保留在 SSB 中。

Series 2 HSE 设备流程

在 HSE-SVM 和 HSE-SVH 设备中，Secure Boot 源自安全协处理器（HSE）中的 ROM。

SE 从 ROM 启动

设备复位后，Secure Engine 中的 ROM 代码开始执行，这是信任链的起点。

SE 验证 GBL（SSB）

SE 使用存储在 OTP 中的 Public Sign Key 验证 Main Bootloader（GBL）的签名。若验证失败，设备停止引导。

GBL 验证 Application

通过 SE 验证后，GBL 执行并使用相同的公钥验证 Application 映像的签名。

Application 运行

若所有签名验证通过，Application 被允许执行。

Series 2 VSE 设备流程

在 VSE-SVM 设备中，主机 MCU（Cortex-M33）在复位后假定一个提升的安全状态，通过源自 ROM 的代码安全地自行引导，然后按照与 HSE 类似的流程验证 GBL 和 Application。

基于证书的 Secure Boot（Certificate-Based Secure Boot）

Certificate-Based Secure Boot 使用密钥委托来最小化 Private Sign Key 的暴露。证书结构包含：

字段	说明
结构版本	证书结构的版本号
公钥	ECDSA-P256 公钥（X 和 Y 坐标拼接），用于验证映像
证书版本	当前运行证书的版本（支持证书吊销）
签名	对公钥和证书版本的 ECDSA-P256 签名

标准证书模式
高级证书模式

SE 验证包含证书的 GBL，GBL 使用证书中的公钥验证 Application。信任链：SE OTP 公钥 → GBL 证书 → Application 签名。

一旦 SE 识别到一个证书并验证成功，若证书版本高于 0，SE 将永远不再接受不含证书的直接签名 Bootloader 映像。证书引入是单向不可逆的操作。

Secure Loader

在 Series 2 设备中，Secure Loader 是预加载到芯片中的固件，由 Silicon Labs 维护并通过安全升级包部署，功能上等同于 Series 1 设备上的第一阶段 GBL。 Secure Loader 在执行升级操作前，会验证暂存映像的真实性和完整性。要求：

暂存映像驻留在芯片上
暂存映像不得与目标地址范围重叠
片外来源的固件映像需由 Application 或 SSB 暂存后，才能调用 Secure Loader 执行升级

密钥配置

关键密钥类型

密钥名称	由客户编程	用途
Public Sign Key	是	Secure Boot 二进制认证和/或 OTA 升级载荷认证
Public Command Key	是	Secure Debug Unlock 或 Disable Tamper 命令认证
OTA Decryption Key（GBL Decryption Key）	是	解密用于固件升级的 GBL 载荷
Attestation Key（Private Device Key）	否	设备安全身份认证

配置 Public Sign Key 与启用 Secure Boot

使用 Simplicity Commander
使用 SE Manager 示例

生成密钥对

commander util genkey --type ecc-p256 \
  --privkey sign_key.pem \
  --pubkey sign_pubkey.pem \
  --tokenfile sign_pubkey.txt

写入 Public Sign Key 到 SE OTP

commander security writekey \
  --sign sign_pubkey.pem \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

Public Sign Key 一旦写入 OTP 就无法更改。所有要在设备上运行的代码都必须由对应私钥签名。

生成 Secure Boot 配置文件

commander security genconfig \
  --nostore \
  --outfile user_configuration.json \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

编辑配置并写入 SE OTP

修改 user_configuration.json 中的 Secure Boot 选项，然后写入：

commander security writeconfig \
  --configfile user_configuration.json \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

Secure Boot 配置选项说明：

选项	说明
`SECURE_BOOT_ENABLE`	启用后，SE 在释放 Cortex-M33 之前验证主机映像签名
`SECURE_BOOT_VERIFY_CERTIFICATE`	启用后，要求基于证书的映像签名
`SECURE_BOOT_ANTI_ROLLBACK`	启用后，防止升级到版本低于当前版本的映像
`SECURE_BOOT_PAGE_LOCK_NARROW`	锁定经 Secure Boot 验证的闪存页（不含签名所在最后一页，若不在页边界）
`SECURE_BOOT_PAGE_LOCK_FULL`	锁定经 Secure Boot 验证的闪存页（含签名所在最后一页）

在 Simplicity Studio 5 中使用 SE Manager Key Provisioning 平台示例：

修改 app_process.c 中的 public_sign_key 数组：

/// Public sign key
SL_ALIGN(4) static const uint8_t public_sign_key[PUB_KEY_SIZE] = {
  0xc4, 0xaf, 0x4a, 0xc6, 0x9a, 0xab, 0x95, 0x12,
  0xdb, 0x50, 0xf7, 0xa2, 0x6a, 0xe5, 0xb4, 0x80,
  /* ... 其余字节 ... */
};

在 app_se_manager_key_provisioning.c 的 init_se_otp_conf() 中配置 Secure Boot 选项：

// 配置 Secure Boot 选项
otp_init.enable_secure_boot = true;
otp_init.verify_secure_boot_certificate = false;
otp_init.enable_anti_rollback = true;
otp_init.secure_boot_page_lock_narrow = false;
otp_init.secure_boot_page_lock_full = false;

为 Secure Boot 签名映像

ECDSA-P256-SHA256 签名流程

生成未签名的 GBL 映像

在 Simplicity Studio 中，通过 Bootloader Core 软件组件生成 Bootloader 项目，构建获得未签名的 GBL 映像（.s37 文件）。

生成未签名的 Application 映像

构建 Application 项目，在 Simplicity Studio 的 Project Properties 中配置 Post-build 步骤生成 .s37 文件。

签名 GBL（SSB）映像

# 使用 Simplicity Commander 签名
commander convert bootloader-uart-xmodem.s37 \
  --secureboot \
  --keyfile sign_key.pem \
  --verify sign_pubkey.pem \
  --outfile bootloader-uart-xmodem-signed.s37

签名 Application 映像

commander convert myapp.s37 \
  --secureboot \
  --keyfile sign_key.pem \
  --verify sign_pubkey.pem \
  --outfile myapp-signed.s37

生成 GBL 升级映像文件

# 生成 Application 升级的 GBL 文件
commander gbl create myapp.gbl \
  --app myapp-signed.s37 \
  --sign sign_key.pem \
  --encrypt encryption-key

基于证书的签名流程

生成证书

# 生成 GBL 证书
commander util gencert \
  --cert-type bootloader \
  --cert-version 1 \
  --app-version 0 \
  --key sign_key.pem \
  --outfile gbl_cert_sign_key_cert.bin

生成包含证书的密钥对

使用证书中的公钥生成对应的签名密钥：

commander util genkey --type ecc-p256 \
  --privkey cert_sign_key.pem \
  --pubkey cert_sign_pubkey.pem

用证书密钥签名 GBL

commander convert bootloader-uart-xmodem.s37 \
  --secureboot \
  --keyfile cert_sign_key.pem \
  --verify cert_sign_pubkey.pem \
  --certificate gbl_cert_sign_key_cert.bin \
  --outfile bootloader-uart-xmodem-cert-signed.s37

在启用 Secure Boot 的设备上调试

在启用 Secure Boot 的设备上进行调试，需要确保烧录到设备的 Application 映像是已签名的。

Simplicity IDE 配置

在项目属性的 C/C++ Build → Settings → Build Steps → Post-build steps 中添加签名命令：

commander convert blink_baremetal.s37 ^
  --secureboot ^
  --keyfile sign_key.pem ^
  --verify sign_pubkey.pem ^
  --outfile blink_baremetal.s37
commander flash blink_baremetal.s37

将此批处理文件设置为构建后步骤，确保每次构建后自动签名并烧录映像。

Secure Boot 失败时的设备恢复

启用 Secure Boot 后，若烧录了未签名或签名不正确的映像，设备将无法正常引导。需要使用以下方法恢复。

标准调试解锁状态
安全调试锁定状态

运行 security erasedevice 命令擦除设备，然后烧录正确签名的映像：

# 检查引导状态
commander security status \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

# 擦除设备
commander security erasedevice \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

# 烧录正确签名的 Bootloader 映像
commander flash bootloader-uart-xmodem.s37 \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

若检测到 Secure Boot 失败，commander flash 会在烧录前自动擦除设备：

WARNING: Failed secure boot detected. Issuing a mass erase before flashing...

需要先使用 Debug Unlock Token 解锁，再使用 --noreset 选项烧录：

# 使用 debug unlock token 解锁
commander security unlock \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

# 使用 --noreset 烧录（防止返回安全调试锁定状态）
commander flash --noreset bootloader-uart-xmodem.s37 \
  --device EFR32MG21A010F1024 \
  --serialno 440048205

失败分析

状态	Secure Boot 未启用	Secure Boot 已启用
标准调试解锁	无需设备擦除	无需设备擦除，但需要正确签名的映像
标准调试锁定	需要设备擦除	需要设备擦除和正确签名的映像
永久调试锁定	无法进行失败分析	无法进行失败分析
安全调试锁定	需要 Debug Unlock Token	需要 Debug Unlock Token 和正确签名的映像

Silicon Labs 强烈建议在 Series 2 设备上安装最新的 SE 固件以支持所需的安全特性。请参见 AN1222 了解升级 SE 固件的过程。

入门指南

开发指南

Bootloader 与存储

Series 2 安全启动：RTSL 信任根与 Secure Engine

Series 2 设备安全特性概述

Secure Engine（SE）

Secure Vault

Secure Boot

Secure Debug Access Control

Secure Engine 类型

Secure Vault 等级

Secure Boot 原理

信任根（Root of Trust）

两阶段引导设计

ECDSA-P256-SHA256 Secure Boot 流程

Series 1 设备流程

Series 2 HSE 设备流程

Series 2 VSE 设备流程

基于证书的 Secure Boot（Certificate-Based Secure Boot）

Secure Loader

密钥配置

关键密钥类型

配置 Public Sign Key 与启用 Secure Boot

为 Secure Boot 签名映像

ECDSA-P256-SHA256 签名流程

基于证书的签名流程

在启用 Secure Boot 的设备上调试

Simplicity IDE 配置

Secure Boot 失败时的设备恢复

失败分析

Build docs developers (and LLMs) love

入门指南

开发指南

Bootloader 与存储

Documentation Index

​Series 2 设备安全特性概述

Secure Engine（SE）

Secure Vault

Secure Boot

Secure Debug Access Control

​Secure Engine 类型

​Secure Vault 等级

​Secure Boot 原理

​信任根（Root of Trust）

​两阶段引导设计

​ECDSA-P256-SHA256 Secure Boot 流程

​Series 1 设备流程

​Series 2 HSE 设备流程

​Series 2 VSE 设备流程

​基于证书的 Secure Boot（Certificate-Based Secure Boot）

​Secure Loader

​密钥配置

​关键密钥类型

​配置 Public Sign Key 与启用 Secure Boot

​为 Secure Boot 签名映像

​ECDSA-P256-SHA256 签名流程

​基于证书的签名流程

​在启用 Secure Boot 的设备上调试

​Simplicity IDE 配置

​Secure Boot 失败时的设备恢复

​失败分析

Build docs developers (and LLMs) love

Series 2 设备安全特性概述

Secure Engine 类型

Secure Vault 等级

Secure Boot 原理

信任根（Root of Trust）

两阶段引导设计

ECDSA-P256-SHA256 Secure Boot 流程

Series 1 设备流程

Series 2 HSE 设备流程

Series 2 VSE 设备流程

基于证书的 Secure Boot（Certificate-Based Secure Boot）

Secure Loader

密钥配置

关键密钥类型

配置 Public Sign Key 与启用 Secure Boot

为 Secure Boot 签名映像

ECDSA-P256-SHA256 签名流程

基于证书的签名流程

在启用 Secure Boot 的设备上调试

Simplicity IDE 配置

Secure Boot 失败时的设备恢复

失败分析