1. 课程导入与安全启动全景

在嵌入式产品从原型走向量产的过程中,设备“能不能启动”只是最低要求,真正决定产品能否交付、能否通过客户验收、能否在售后被安全维护的,是“启动过程是否可信、固件能否被安全更新”。TI Sitara 系列处理器正是面向工业控制、人机界面、网关、电力终端、医疗设备等场景的一类高集成度 ARM 处理器,其安全启动与固件升级能力,是这类产品安全生命周期的基础环节。

一、TI Sitara 处理器家族概述

Sitara 是 TI 面向嵌入式与工业应用的 ARM 处理器产品线,覆盖从入门级到高性能的多个层级。常见的代表型号包括 AM335x(Cortex-A8,广泛用于工业 HMI 与网关)、AM437x(Cortex-A9,带 PRU-ICSS 工业子系统)、AM57x(Cortex-A15 + DSP,适合视觉与高性能计算)、AM64x/AM62x(Cortex-A53 + R5F,面向实时与安全并重的工业场景)等。它们虽然内核与主频不同,但在安全启动机制上共享一套相近的设计思想:芯片内部固化一段不可修改的引导代码(ROM Code),由它在上电后首先运行,负责从外部存储介质加载第一阶段引导程序,并在加载过程中完成签名校验、密钥验证与镜像完整性检查。

理解 Sitara 安全启动,需要先建立几个关键概念:ROM Code 是芯片出厂即固化的信任根,它决定了设备“信任谁”;X.509 证书用于携带公钥与签名信息,是验证链的载体;OTP/eFuse 用于烧写密钥哈希与安全配置,一旦写入不可更改;签名镜像则是被私钥签名、可被公钥验证的固件包。这些对象共同构成从芯片到应用的信任链。

二、安全启动与固件升级的工程意义

安全启动解决的是“设备只运行经过授权的固件”。如果没有安全启动,攻击者可以通过替换启动介质中的镜像,让设备运行恶意代码,从而窃取数据、篡改控制逻辑或把设备变成网络攻击的跳板。安全启动通过逐级校验,把信任从不可篡改的 ROM Code 传递到引导程序、操作系统内核,最终传递到应用。

固件升级解决的则是“设备在生命周期内可以安全地更新”。工业设备往往部署在现场,升级通道可能是 U 盘、网络、串口或远程 OTA。如果升级过程没有签名校验与回滚保护,一次失败的升级可能导致设备变砖,一次被篡改的升级则可能直接引入后门。因此,安全启动与固件升级通常成对出现:安全启动保证“启动的固件可信”,安全升级保证“新固件可信且可回退”。

安全启动不是单一开关,而是一条信任链:ROM Code → SPL/U-Boot → 内核 → 根文件系统。链上任何一环校验失败,启动都应被阻止或进入受限恢复模式。

三、典型应用场景

在工业 HMI 中,设备需要防止现场人员通过替换 SD 卡植入未授权固件;在电力终端中,固件升级必须经过签名校验,并保留旧版本以便回滚;在医疗设备中,启动日志与固件版本需要可追溯,以符合合规要求;在边缘网关中,远程 OTA 必须支持断点续传与失败回滚,避免批量设备变砖。这些场景的共同点是:设备部署分散、现场维护成本高、安全事件后果严重,因此安全启动与升级机制不是可选项,而是产品定义的一部分。

四、课程学习路径与实验环境搭建

本课程将沿着“概念—工具—实操—排障”的路径展开。前期建立信任链、密钥、证书、镜像格式等概念;中期使用 TI 提供的工具链完成密钥生成、镜像签名、OTP 烧写与启动验证;后期针对启动失败、签名不匹配、回滚异常等问题进行排障与复盘。

实验环境建议以一块 Sitara 开发板(如 AM62x 或 AM335x 入门板)为核心,配合 Linux 主机、串口终端、SD 卡与网络。主机侧需要安装 TI 的 SDK、OpenSSL、以及镜像签名工具。一个典型的验证流程如下:

# 示例:生成密钥与证书(示意,具体命令以所用 SDK 为准)
openssl genrsa -out priv.pem 2048
openssl req -new -x509 -key priv.pem -out cert.pem -days 3650

# 对镜像进行签名,生成可被 ROM Code 校验的镜像
# 具体工具与参数随芯片系列不同而变化
sign_image --key priv.pem --cert cert.pem --input u-boot.bin --output u-boot-signed.bin

# 通过串口观察启动日志,确认校验是否通过
# 若校验失败,通常会在 ROM Code 阶段停止并输出错误码

实验时建议先不烧写 OTP,仅在“开发模式”下验证签名镜像能否被正确加载;确认流程无误后,再在受控条件下烧写密钥哈希,进入安全启动模式。这样可以在不破坏芯片的前提下完成学习与验证。

Sitara 安全启动信任链与固件升级路径 ROM Code 芯片固化信任根 SPL / U-Boot 第一阶段引导 Linux Kernel 内核镜像校验 RootFS / App 根文件系统与应用 校验 校验 校验 OTP / eFuse 公钥哈希 · 安全配置 一次性烧写,不可更改 X.509 证书 公钥 · 签名 · 有效期 随镜像一起分发 签名镜像 镜像 + 证书 + 签名 由私钥签名生成 固件升级路径(安全升级) 新固件包 已签名 传输/写入 U盘/网络/OTA 签名校验 公钥验证 切换/回滚 A/B 分区 重启验证 启动成功 校验失败 → 拒绝升级,保留原固件

上图把两条主线放在一起:上半部分是启动时的信任链,从 ROM Code 逐级校验到应用;下半部分是升级时的处理路径,从新固件包到重启验证。两者共享同一套密钥与证书体系,因此实验时应当先理解密钥如何生成、证书如何携带公钥、镜像如何被签名,再观察 ROM Code 在启动阶段如何用 OTP 中的公钥哈希去验证证书,最终决定是否继续启动。

学习本课程时,建议始终带着三个问题:当前这一步的输入是什么、校验依据是什么、失败时设备会进入什么状态。把这三个问题贯穿到后续每一节的工具使用与实验操作中,就能把零散的命令与配置串成一条完整的工程能力。