3、硬件安全基础：TEE、TPM 与安全启动链原理

聊边缘网关的安全，很多人第一反应是「装个防火墙」「上加密」。但说实话，这些软件层面的防护，一旦硬件被攻破，全白搭。我见过太多案例——攻击者直接拆开设备，接上调试串口，把 Flash 里的固件读出来逆向。嗯，硬件安全才是真正的「地基」。

这一章，我们聚焦三个核心硬件安全技术：TEE（可信执行环境）、TPM（可信平台模块）、安全启动链（Secure Boot）。它们各自解决什么问题？怎么配合？我用自己的项目经验给你拆开讲。

3.1 安全启动链（Secure Boot）—— 从第一行代码开始可信

安全启动链，说白了就是「只让经过签名的代码运行」。从芯片上电复位开始，每一级代码都要验证下一级的签名，验证通过才执行。一旦某级签名校验失败，系统直接挂起或进入恢复模式。

典型的启动链长这样：

ROM Bootloader → Bootloader 1（SPL） → Bootloader 2（U-Boot） → OS Kernel → 应用

每一级都包含上一级的公钥，用于验证下一级的数字签名。

我在一个工业网关项目里遇到过一个问题：客户自己编译了内核，刷进去之后设备变砖。查了半天，发现是 U-Boot 里的公钥和内核签名用的私钥不匹配。从那以后，我习惯在 CI 流程里加一道「签名一致性检查」——省得半夜被叫起来救砖。

3.1.1 签名与验证流程

你想想看，安全启动的核心就两个动作：签名（在安全环境里做）和验证（在设备上做）。

  1. 签名阶段：用私钥对镜像文件（如内核、设备树）计算哈希，然后加密哈希生成签名。签名和公钥一起打包进镜像。
  2. 验证阶段：Bootloader 用内置的公钥解密签名，得到哈希值 A；再对收到的镜像计算哈希值 B。A == B 则通过，否则拒绝启动。

我的建议：私钥一定要放在离线机器上，最好用 HSM（硬件安全模块）存储。我曾经见过有人把私钥放在 Git 仓库里——嗯，那基本等于把家门钥匙贴在门上。

3.1.2 常见实现方式

方案 特点 适用场景
U-Boot 的 Verified Boot 支持 FIT 镜像格式，内置哈希和签名校验 ARM 架构网关，社区支持好
UEFI Secure Boot 基于 PKI 体系，支持吊销 x86 架构网关，兼容性好
芯片厂商私有方案 如 NXP HAB、TI HS-SE 对安全性要求极高的场景

注意：安全启动链只保证启动时的镜像完整性，不保证运行时的安全。一旦系统跑起来，内存里的数据还是可能被篡改——这就需要 TEE 来补位了。

3.2 TEE（可信执行环境）—— 在 CPU 里建一个「保险箱」

TEE 的概念其实不复杂：在同一个 CPU 上，隔离出一个安全区域。普通操作系统（REE，Rich Execution Environment）跑在「外面」，敏感操作（如密钥运算、指纹比对）跑在「里面」。两边通过硬件强制隔离，REE 无法直接访问 TEE 的内存和寄存器。

我打个比方：REE 就像酒店的公共大堂，谁都能进；TEE 就像酒店的金库，只有持特殊权限的人才能进去，而且金库的墙是钢筋混凝土浇筑的——你砸不开。

3.2.1 TEE 的典型架构

目前主流的两大 TEE 技术：

  • ARM TrustZone：把 CPU 分为「安全世界」和「非安全世界」，通过硬件总线隔离。边缘网关里用得最多。
  • Intel SGX：在内存里创建飞地（Enclave），应用级隔离。更适合云端或高性能边缘节点。

下面这张图展示了 TrustZone 的基本架构：

ARM TrustZone 架构示意图 非安全世界（REE） Linux / Android 普通应用 普通驱动 网络协议栈 文件系统 安全世界（TEE） Trusted OS（如 OP-TEE） 密钥管理 安全存储 密码运算 安全认证 硬件隔离（Monitor Mode） 安全监控模式调用（SMC） REE 无法直接访问 TEE 内存，所有跨世界通信必须通过 Monitor Mode 的 SMC 指令

3.2.2 在边缘网关里怎么用 TEE？

我参与过一个智慧园区项目，网关需要存储设备的注册密钥。如果直接放在 Linux 文件系统里，攻击者拿到 root 权限就能偷走。我们的方案是：

  1. 在 TEE 里运行一个「密钥服务」TA（Trusted Application）。
  2. REE 侧的应用通过 TEE Client API 发起请求，比如「用密钥 X 加密数据 Y」。
  3. 密钥全程不出 TEE 内存，REE 只拿到加密结果。

关键点：TEE 不防侧信道攻击（如功耗分析、电磁泄漏），也不防物理探针。它解决的是「操作系统被攻破后，敏感数据依然安全」的问题。

3.3 TPM（可信平台模块）—— 给设备一个「硬件身份证」

TPM 是一个独立的安全芯片（或者集成在 SoC 里），专门干几件事：密钥生成、安全存储、平台度量（PCR）、远程证明。你可以把它理解成设备的「硬件保险柜 + 身份证」。它有自己的 CPU、存储和密码加速器，主 CPU 根本读不到 TPM 内部的私钥。

3.3.1 TPM 的核心功能

功能 说明 我的用法
RSA/ECC 密钥生成 在芯片内部生成密钥对，私钥永不导出 用于设备身份证书的私钥
平台配置寄存器（PCR） 存储启动过程的哈希值，用于远程证明 配合安全启动，证明设备没被篡改
密封（Seal） 将数据绑定到特定 PCR 状态 只有系统状态「干净」时才能解封密钥
远程证明（Remote Attestation） 用 TPM 签名的 PCR 值向服务器证明设备可信 网关接入云平台前的「安检」

3.3.2 TPM 与安全启动链的配合

这里有个常见的误区：很多人以为 TPM 和安全启动是二选一。其实它们配合起来效果更好。我画个流程你就明白了：

TPM + Secure Boot 协同流程 上电复位 ROM 校验 Bootloader Bootloader 校验内核 TPM 扩展 PCR TPM 扩展 PCR 远程证明请求 服务器验证 PCR 每次启动扩展 PCR，最终 PCR 值 = 整个启动链的「指纹」。服务器通过比对指纹判断设备是否被篡改

避坑指南：我曾经在一个项目里把 TPM 的 PCR 扩展顺序搞反了——先扩展内核再扩展 Bootloader。结果每次启动 PCR 值都不一样，远程证明死活过不了。后来查了 TCG 规范才发现，扩展顺序必须和启动顺序一致。嗯，这个坑我替你踩过了。

3.4 三者如何协同？

单独看每个技术，好像都能解决一部分问题。但实际部署时，我习惯把它们串成一条链：

  • 安全启动链保证启动过程的可信，防止恶意固件运行。
  • TPM记录启动过程的度量值（PCR），并提供硬件级密钥存储。
  • TEE在运行时提供隔离环境，保护敏感操作不被 OS 层攻击窃取。

举个例子：网关启动时，安全启动链逐级验证镜像，同时每级把哈希值扩展到 TPM 的 PCR 里。系统启动后，TEE 里的可信应用向 TPM 请求一个签名——证明当前 PCR 值等于预期值。这个签名发给云端，云端验证通过后，才下发真正的业务密钥。整个过程，密钥只在 TEE 和 TPM 之间流转，Linux 系统根本碰不到。

一句话总结：安全启动链管「启动时」，TPM 管「可度量」，TEE 管「运行时」。三者缺一不可，但也不能互相替代。

3.5 部署时的几个实用建议

  1. 别贪多：不是所有网关都需要全套。低端设备可能只做安全启动 + TPM，高端设备再加 TEE。按威胁模型来选。
  2. 密钥生命周期管理：TPM 的 Endorsement Key（EK）是芯片出厂时烧录的，不可更改。但业务密钥可以定期轮换。我习惯在 TEE 里实现一个密钥轮换 TA，每 90 天自动生成新密钥并密封到 TPM 里。
  3. 调试和生产环境分离：开发阶段可以关掉签名校验，但生产环境必须强制开启。我见过有人把调试 UART 留在量产板上——攻击者直接通过串口中断启动流程，安全启动形同虚设。
  4. 考虑 OTA 升级的影响：安全启动链一旦启用，升级固件也必须签名。CI/CD 流水线里要集成签名步骤，否则运维同学会疯掉。

再次提醒：硬件安全不是银弹。TEE 不防物理探针，TPM 不防总线嗅探，安全启动不防运行时攻击。它们只是把攻击成本抬高到攻击者不愿意付出的程度。对于边缘网关来说，这个「成本」通常已经足够挡住 99% 的常见攻击了。

← 上一章 📖 返回目录 下一章 →