4、可信边界概念：设备、模型、固件、数据之间的信任边界与信任根（Root of Trust）
TinyML 系统的安全部署，本质上是在资源极度受限的嵌入式环境中建立一套可验证、可度量的信任传递机制。与云端或企业级系统不同，TinyML 设备通常部署在物理暴露、网络不可靠、算力与存储均受限的边缘场景中，攻击者可能同时具备物理接触、侧信道观测、通信劫持与固件逆向的能力。因此，我们必须首先厘清设备、模型、固件、数据四类核心资产之间的信任边界，并明确信任根（Root of Trust, RoT）在整个安全架构中的锚点地位。本章将围绕信任边界的划分、信任根的建立与传递、以及实际部署中的工程实践展开。
上图展示了 TinyML 系统中四类核心资产之间的信任传递关系。信任根（RoT）位于最底层，是系统安全假设的物理锚点；设备域、固件域、模型域和数据域依次向上构建，每一层都依赖下一层提供的可信基座。值得注意的是，模型域与数据域之间存在双向虚线箭头，表示推理过程中模型与数据需要频繁交互，这种交互本身也是攻击面的一部分。下面我们将逐一拆解各信任边界的定义、实现机制与常见风险。
4.1 核心原理：信任边界与信任根的定义
信任边界（Trust Boundary）是指系统内不同安全等级组件之间的分界线。跨越边界的数据流、控制流或状态转换，都必须经过明确的安全策略校验。在 TinyML 系统中，我们通常识别出四条关键信任边界：
- 边界 A（启动链）：从片上 ROM 引导代码到主固件加载之间的所有步骤。此边界确保设备只运行经过签名的固件镜像。
- 边界 B（运行时数据流）：传感器原始数据进入 MCU、经过预处理、送入模型推理、再到输出决策的完整链路。此边界关注数据在传输和处理过程中是否被篡改或窃听。
- 边界 C（模型加载与更新）：模型参数从非易失存储（Flash/SD）加载到 RAM 并映射到推理引擎的过程。此边界防止模型被替换或逆向。
- 边界 D（外部通信）：设备与网关、云平台或其他节点之间的无线/有线通信。此边界需要处理身份认证、加密和防重放。
信任根（Root of Trust）是系统安全验证链的起点，它本身不需要依赖任何外部组件来验证自己的可信性。在嵌入式环境中，信任根通常由以下一种或多种硬件机制构成：
| 信任根类型 | 硬件载体 | 核心功能 | 典型实现 |
|---|---|---|---|
| 不可变引导 ROM | 芯片内部 Mask ROM | 启动时首先执行，验证下一级引导代码签名 | ARM TrustZone + Boot ROM |
| 一次性可编程密钥 | eFuse / OTP 阵列 | 存储根密钥、设备唯一 ID、安全配置位 | ESP32 eFuse、STM32 OTP |
| 硬件安全模块 | 独立安全芯片或 SoC 内安全岛 | 密钥管理、加解密运算、安全存储 | ATECC608A、NXP SE050 |
| 物理不可克隆函数 | 芯片内部 PUF 电路 | 利用制造差异生成唯一设备指纹 | Lattice MachXO3D、NXP LPC55S |
信任根的设计原则是：最小化可信计算基（TCB）。即，信任根所包含的代码和逻辑必须尽可能少，以减少被攻击的可能性。例如，Boot ROM 中只包含公钥哈希和签名验证逻辑，不包含任何网络协议栈或文件系统解析代码。
4.2 判断方法与操作流程：如何划分和验证信任边界
在实际项目中，划分信任边界需要结合威胁建模和硬件能力评估。以下是推荐的五步操作流程：
- 资产盘点：列出设备上所有需要保护的资产，包括固件二进制、模型参数、传感器校准数据、用户隐私数据、通信密钥等。为每项资产标注机密性、完整性、可用性要求。
- 数据流绘制：画出从物理世界到决策输出的完整数据流图，标注每个节点（传感器、DMA、预处理、推理引擎、输出接口）的信任等级。
- 攻击面分析：对每个节点和每条边进行攻击路径枚举。例如，SPI 总线上的模型参数是否可被逻辑分析仪嗅探？JTAG/SWD 调试口是否在生产后关闭？
- 信任根选型：根据 MCU 的安全特性（TrustZone、Secure Boot、加密引擎）和成本约束，确定信任根的物理实现方式。对于超低成本的传感器节点，可能只能依赖 Boot ROM + eFuse；对于高端边缘 AI 盒子，可以配置独立安全芯片。
- 边界验证测试：在开发板上实际执行以下验证：尝试加载未签名固件、篡改模型文件、通过调试接口读取 Flash 内容、在通信链路上插入伪造数据包。记录哪些攻击被成功阻断，哪些存在绕过路径。
关键判断标准：一个信任边界是否有效，取决于它能否同时满足以下三个条件——身份可验证（对方确实是声称的实体）、完整性可度量（内容未被篡改）、状态可审计（所有安全事件留有日志）。如果任一条件不满足，该边界就需要重新设计。
4.3 案例拆解：智能家居摄像头中的信任边界设计
我们以一个典型的 TinyML 智能家居摄像头为例，分析其信任边界设计中的具体约束与决策过程。
背景与约束：该摄像头采用 ESP32-S3 主控（内置 AI 加速器），运行人体检测模型（约 300KB 量化模型），通过 Wi-Fi 将检测结果上传至家庭网关。成本敏感，BOM 成本需控制在 8 美元以内。威胁模型包括：邻居尝试通过物理接触重置设备、攻击者通过 Wi-Fi 中间人攻击注入虚假检测结果、恶意固件通过 OTA 渠道植入。
初始现象：第一版原型中，设备仅依赖 ESP32 的 Secure Boot（使用 eFuse 存储公钥哈希），但模型文件以明文形式存储在外部 SPI Flash 中。测试团队使用逻辑分析仪在 SPI 总线上成功嗅探到完整的模型参数，并发现可以通过替换 Flash 中的模型文件实现“检测绕过”——即让摄像头对特定人物不产生报警。
分析判断过程：该问题暴露了信任边界 B（运行时数据流）和边界 C（模型加载）的失效。虽然启动链是安全的，但模型加载过程没有建立独立的完整性校验机制。进一步分析发现，ESP32-S3 的 Secure Boot 只覆盖固件镜像，不覆盖外部 Flash 中的模型分区。攻击者可以绕过固件签名检查，直接修改模型分区。
实际操作步骤：
- 在模型分区头部增加 32 字节的 HMAC-SHA256 签名，密钥存储在 eFuse 的第二个密钥槽中（与固件签名密钥分离）。
- 修改固件启动流程：在加载模型到 RAM 之前，先计算模型分区的 HMAC，与存储的签名比对，不匹配则拒绝加载并进入安全失败模式（红灯闪烁 + 日志记录）。
- 将 SPI Flash 的写保护引脚（WP）连接到 GPIO，固件运行时将 WP 拉高，防止运行时对模型分区的意外写入。
- 在 OTA 更新流程中，要求新固件必须携带新模型的 HMAC 签名，且签名密钥必须由后端服务器私钥签名，设备端使用预置的公钥验证。
结果对比：实施上述措施后，逻辑分析仪再次嗅探 SPI 总线时，只能获取密文或签名校验失败的随机数据。尝试替换模型文件会导致设备启动时校验失败并拒绝运行。OTA 劫持测试中，伪造的固件包因无法通过签名验证而被拒绝。
风险与代价：模型加载时间增加了约 120ms（HMAC 计算开销），对于该应用场景（人体检测，实时性要求 500ms 以内）可以接受。eFuse 密钥槽从 1 个增加到 2 个，但 ESP32-S3 提供 4 个密钥槽，仍有冗余。主要代价是开发复杂度提升，需要维护两套密钥管理体系。
复盘经验：信任边界不能只依赖单一机制。Secure Boot 解决了“固件是否可信”的问题，但模型、数据、通信都需要独立的信任锚点。在资源受限设备上，应优先保护攻击成本最低、影响最大的路径——在本案例中，模型替换攻击比固件篡改更容易实施，因此需要优先防护。
4.4 常见误区与总结复盘
在 TinyML 安全部署实践中，以下误区最为常见：
误区一：认为 Secure Boot 等于全部安全。Secure Boot 只保证启动链的完整性，不保护运行时的数据流、模型加载和通信安全。攻击者可以通过调试接口、总线嗅探、故障注入等方式绕过启动链保护。
误区二：信任根与信任边界混淆。信任根是硬件锚点，信任边界是逻辑分界。即使有了强信任根，如果边界划分不合理（例如将模型和固件放在同一分区且无独立校验），信任根也无法发挥作用。
误区三：忽略物理攻击。TinyML 设备常部署在无人值守环境，攻击者可以拆开外壳、使用探针接触 PCB 走线、利用电压毛刺干扰 CPU。设计时必须假设攻击者具有物理访问权限。
误区四：密钥管理过于简单。将同一个密钥用于固件签名、模型加密、通信认证，一旦密钥泄露，所有信任边界同时失效。应使用不同密钥槽位，并实施密钥轮换策略。
总结：可信边界设计是 TinyML 安全部署的骨架。正确的做法是：首先明确信任根（硬件锚点），然后基于数据流绘制信任边界，为每条边界设计独立的身份验证、完整性度量和安全通道机制。在资源受限条件下，应优先保护攻击路径最短、影响最大的资产，并接受一定的性能开销换取安全增益。最后，务必通过实际的渗透测试验证边界有效性，而不是仅依赖理论分析。
工程建议：在项目早期就引入威胁建模，使用类似 Microsoft Threat Modeling Tool 或简单的数据流图 + STRIDE 分类法，将信任边界可视化。每次硬件改版时，重新评估信任根的能力是否满足新增安全需求。对于量产设备，务必在产线中实施密钥烧录和锁定流程，防止调试接口在生产后被恶意利用。