嵌入式系统安全基础：架构、威胁与安全启动
在深入可信启动链与模型文件保护之前，必须先建立嵌入式系统安全的整体视图。嵌入式系统并非“缩小版的PC”，其资源受限、实时性要求高、生命周期长且物理可及性强，这些特性决定了其安全威胁模型与防御策略截然不同。本章将系统梳理嵌入式系统的典型架构、常见安全威胁与攻击面，并重点阐述安全启动（Secure Boot）的基本概念、信任根（Root of Trust）机制及其在整体安全体系中的核心地位。
上图展示了嵌入式系统安全的核心逻辑：左侧是系统架构分层，中间是贯穿各层的攻击面，右侧则是安全启动建立的信任链。理解这三者之间的关联，是设计可信启动链和模型文件保护方案的前提。下面逐一展开。
2.1 嵌入式系统架构与安全边界
嵌入式系统的架构设计直接决定了安全边界的划分。与通用计算平台不同，嵌入式系统通常采用“硬件-固件-操作系统-应用”的垂直分层结构，每一层都有明确的功能边界和信任假设。硬件层提供物理信任根，固件层负责初始化硬件并引导系统，操作系统层管理资源与进程隔离，应用层则承载业务逻辑和AI模型文件。
从安全角度看，这种分层架构意味着攻击者若想完全控制设备，必须逐层突破或找到跨层跳板。例如，通过物理调试接口（JTAG）直接读取存储器内容，属于硬件层攻击；通过网络协议栈漏洞获取Shell，属于操作系统层攻击；而篡改模型文件导致推理结果错误，则属于应用层攻击。安全设计的关键在于：每一层都应验证下一层的完整性和来源，形成“链式信任”。
2.2 常见安全威胁与攻击面分析
嵌入式系统的威胁模型远比传统IT系统复杂，因为攻击者往往拥有物理接触设备的能力。下表归纳了主要威胁类别、攻击手法及影响范围，这是后续设计防护措施的基础。
| 威胁类别 | 典型攻击手法 | 攻击面位置 | 潜在影响 |
|---|---|---|---|
| 物理攻击 | JTAG调试、芯片开盖、总线探测 | 硬件层、调试接口 | 提取固件、密钥泄露、代码逆向 |
| 固件篡改 | 伪造升级包、降级攻击、Bootloader替换 | 固件层、升级通道 | 设备被完全控制、持久后门 |
| 网络攻击 | 协议栈漏洞、命令注入、中间人攻击 | 网络接口、应用层 | 远程控制、数据窃取、模型窃取 |
| 侧信道攻击 | 功耗分析（SPA/DPA）、电磁辐射、时序分析 | 硬件层、密码运算过程 | 密钥恢复、绕过加密保护 |
| 供应链攻击 | 恶意芯片植入、开发工具链污染 | 硬件制造、软件构建过程 | 从源头植入后门，极难发现 |
攻击面分析的核心是识别“攻击者能够触及的所有输入点和信任边界”。对于模型文件保护而言，重点关注的攻击面包括：固件升级通道（攻击者可能伪造升级包）、文件系统挂载点（攻击者可能通过漏洞写入篡改文件）、调试接口（攻击者可能直接读取Flash中的模型文件）以及内存映射区域（攻击者可能通过DMA或缓存侧信道窃取模型参数）。
2.3 安全启动的基本概念与信任链构建
安全启动（Secure Boot）是一种机制，确保设备只运行经过授权和完整性验证的代码。其核心思想是“链式信任”：从一个不可篡改的信任根开始，逐级验证后续加载的每个组件。信任根通常固化在芯片内部的BootROM中，该代码在芯片制造时写入，无法被外部修改。
典型的信任链构建流程如下：
- 信任根验证一级引导程序：BootROM使用内置的公钥（或哈希值）验证Bootloader的数字签名，确保Bootloader未被替换或篡改。
- 一级引导验证操作系统内核：Bootloader验证OS内核镜像的签名和完整性，然后跳转执行。
- 内核验证文件系统与应用：内核在挂载文件系统时验证其完整性，应用加载时验证可执行文件和模型文件的签名。
- 运行时完整性监控：在系统运行过程中，通过安全监控模块（如ARM TrustZone）持续校验关键内存区域和文件哈希。
对于模型文件保护，安全启动提供了“前置防线”：如果设备无法启动到被篡改的系统，那么针对模型文件的篡改攻击在启动阶段就会被阻断。然而，安全启动并不能防止“合法启动后的运行时攻击”，因此还需要结合文件加密、访问控制、运行时监控等多层防护。
2.4 实战场景：从攻击面到安全启动的闭环设计
为帮助理解上述概念，下面以一个工业边缘计算网关为例，展示如何从攻击面分析出发，设计安全启动方案并保护其中的AI模型文件。
场景背景：某工业网关部署在无人值守的变电站，内置缺陷检测AI模型（约50MB）。设备通过4G网络接收远程升级包，支持本地USB调试口。攻击者目标是窃取模型文件或篡改模型导致检测失效。
攻击面分析结果：
- USB调试口：攻击者可能通过U-Boot命令行读取Flash分区。
- 4G升级通道：攻击者可能伪造升级服务器下发恶意固件。
- 文件系统：若系统被攻破，模型文件以明文存储，可直接复制。
安全启动方案设计：
- 硬件信任根：选用支持安全启动的SoC（如NXP i.MX 8M系列），在eFuse中烧录根公钥哈希，并熔断JTAG调试口。
- 签名链：BootROM验证U-Boot签名，U-Boot验证Linux内核签名，内核验证根文件系统（SquashFS）的签名。
- 模型文件保护：模型文件存放于独立分区，使用AES-256-GCM加密，密钥由安全启动链派生的硬件密钥加密存储。应用启动时，通过内核密钥环（Keyring）获取解密密钥。
- 升级流程：升级包必须包含双重签名（固件签名+模型签名），升级服务器使用HSM签名，设备端验证签名后才允许写入。
实施结果与复盘：部署后，攻击者即使物理接触设备，也无法通过USB口进入U-Boot命令行（JTAG已熔断，U-Boot受签名保护）。尝试伪造升级包时，设备拒绝加载并记录安全事件。模型文件在Flash中为密文，即使拆下Flash芯片也无法直接读取明文。该方案将攻击成本从“简单复制”提升到“需要芯片级逆向”，显著增强了防护能力。
2.5 常见误区与设计要点
在实际项目中，工程师常陷入以下误区，导致安全启动形同虚设：
- 误区一：只验证启动链，不保护运行时。安全启动只能保证“启动时”系统可信，但无法防止启动后的漏洞利用。必须配合运行时完整性监控（如IMA）和内存保护（如W^X）。
- 误区二：密钥管理不当。将签名私钥存储在开发机明文目录，或使用弱密码保护。私钥泄露意味着整个信任链失效。
- 误区三：忽略降级攻击。攻击者可能将设备回滚到旧版本固件（旧版本存在已知漏洞）。必须实现版本回滚保护（如Anti-Rollback计数器）。
- 误区四：模型文件仅加密不签名。加密保护机密性，但无法防止篡改。攻击者可能替换密文导致解密失败或产生错误结果。应同时使用加密和签名（或认证加密模式）。