4. 威胁建模
TinyML设备通常部署在物理可接触的环境中——智能传感器节点、工业控制器、边缘网关、医疗穿戴设备等。攻击者一旦获得设备物理访问权，存储介质中的密钥、模型参数和固件就暴露在多种攻击路径之下。威胁建模的核心任务，是系统性地识别“谁可能以什么方式、通过哪个攻击面、获取或破坏哪些存储资产”，从而为后续的分区隔离、加密存储、访问控制等安全设计提供依据。本章围绕物理提取、侧信道、固件逆向、调试接口攻击四类典型威胁展开分析，并给出可落地的威胁建模方法。
上图展示了TinyML存储威胁建模的整体框架：攻击者通过物理接触，从四个主要攻击面切入，最终指向密钥、模型参数和固件三类核心资产。下面逐一展开分析。
4.1 物理提取攻击：直接读取存储介质
核心原理：物理提取攻击是指攻击者通过拆解设备、直接访问存储芯片或总线，将Flash、EEPROM、SRAM中的数据完整读出。TinyML设备常用的外部Flash（如W25Q系列SPI NOR Flash）、内部嵌入式Flash、以及外置SD卡/NAND，都是物理提取的目标。攻击者可以使用编程器、逻辑分析仪、热风枪拆焊工具，甚至聚焦离子束（FIB）等半导体分析设备，绕过所有软件层面的访问控制。
判断方法与操作流程：评估物理提取风险时，需要回答以下问题：
- 存储介质是否可拆卸？如果使用插拔式SD卡或模块化Flash，攻击者可以直接取下读取。
- 芯片是否裸露？PCB上未覆盖灌封胶或屏蔽罩的Flash芯片，用编程器夹子即可在线读取。
- 总线信号是否可探测？SPI/I2C总线上如果未做加密传输，逻辑分析仪可以实时抓取CPU与Flash之间的通信数据。
- 是否有防拆机制？如防拆开关、网格屏蔽层、芯片内部熔丝等。
实际操作中，攻击者通常先尝试非侵入式读取（编程器夹子、SPI嗅探），失败后再升级到侵入式（拆焊、开盖、FIB切割）。
案例拆解：某工业传感器节点使用STM32L4系列MCU，外部挂载W25Q64 SPI Flash存储模型参数和更新固件。安全测试中发现：
- 初始现象：设备未加密Flash内容，且SPI总线上有测试点（TP）裸露。
- 攻击过程：测试人员使用逻辑分析仪连接TP1（CLK）、TP2（MOSI）、TP3（MISO）、TP4（CS），在设备启动加载模型时抓取完整SPI通信数据，成功还原出模型参数二进制文件。
- 结果：模型参数（约200KB）被完整提取，攻击者据此复制了设备的推理能力。
- 复盘：该设备未对Flash内容加密，也未对SPI总线做物理屏蔽。修复方案是启用MCU内部AES硬件加密引擎，对写入Flash的数据进行加密，并移除测试点。
常见误区：很多开发者认为“固件编译后是二进制，攻击者看不懂”。实际上，物理提取得到的二进制可以直接用binwalk、Ghidra等工具分析，模型参数和密钥往往以明文或简单编码形式存在。切勿低估物理提取的可行性。
4.2 侧信道攻击：通过物理泄露间接获取秘密
核心原理：侧信道攻击不直接读取存储内容，而是通过测量设备运行时的物理特性——功耗、电磁辐射、执行时间、温度等——推断出密钥或敏感数据。在TinyML场景中，最典型的是针对AES加密引擎的功耗分析（SPA/DPA）和针对模型推理过程的时序分析。例如，当MCU执行AES加密时，不同密钥位对应的功耗轨迹存在统计差异，攻击者采集大量功耗曲线即可恢复密钥。
判断方法与操作流程：侧信道风险评估需要关注：
- 密码算法实现是否采用常数时间？如果AES的S盒查找或模幂运算存在数据依赖的分支，则时序泄露明显。
- 是否有功耗平坦化措施？如硬件随机延时、功耗掩码、双轨逻辑等。
- 密钥是否频繁使用？每次启动都使用同一密钥解密模型，攻击者可以重复采集功耗曲线。
- MCU是否具备抗侧信道硬件？部分高端MCU（如STM32L5、NXP LPC55S6x）内置了防DPA的AES引擎。
实际攻击流程：使用示波器（采样率≥100MS/s）连接MCU的VCC引脚上的采样电阻，触发条件设为Flash读取开始信号，采集数千条加密操作的功耗轨迹，再用DPA工具（如ChipWhisperer）进行统计分析。
实战场景：某智能门锁使用ESP32，固件中硬编码了AES-128密钥用于加密模型文件。安全评估时，测试人员用ChipWhisperer-Lite采集ESP32执行AES加密时的功耗曲线，仅需约2000条轨迹，耗时2小时即恢复了完整密钥。原因是ESP32的AES实现未做掩码保护，且密钥在每次启动时重复使用。修复方案：改用MCU内置的AES硬件模块（带随机掩码），或采用密钥协商协议避免固定密钥重复使用。
常见误区：侧信道攻击并非只针对高端智能卡。低成本的TinyML设备（Cortex-M0/M4级别）同样容易受到功耗分析攻击，尤其是当设备使用软件实现的AES或轻量级加密算法时。不要因为设备便宜就忽视侧信道防护。
4.3 固件逆向攻击：从二进制中提取逻辑与数据
核心原理：固件逆向是指攻击者从Flash中提取固件镜像后，使用反汇编器、反编译器、字符串提取工具等分析固件逻辑，定位密钥存储位置、理解模型加载流程、甚至还原模型结构。TinyML固件通常包含模型解释器（如TensorFlow Lite Micro）、推理引擎、以及模型参数数组，这些数据在二进制中以特定模式存在，容易被识别。
判断方法与操作流程：固件逆向的典型步骤：
- 固件提取：通过物理提取或调试接口获取Flash镜像（如.bin或.hex文件）。
- 固件分析：使用
binwalk扫描固件中的文件签名，识别压缩包、文件系统、密钥块。 - 反汇编：用Ghidra或IDA Pro加载固件，定位主函数、密码库调用点、Flash读写函数。
- 数据提取：搜索字符串（如
"AES_KEY"、"model_weights"）、查找常量数组、分析模型文件的头部魔数。 - 模型还原：如果模型参数未加密，攻击者可以直接从固件中提取权重数组，配合开源工具（如Keras、PyTorch）重建模型结构。
# 固件逆向常用命令示例
binwalk firmware.bin # 扫描文件签名
strings -n 8 firmware.bin | grep -i "key\|secret\|model"
ghidra -import firmware.bin # 导入Ghidra进行反汇编案例拆解：某农业物联网公司的作物识别模型部署在ESP32-S3设备上，模型文件（约1.2MB）以明文形式存储在外部Flash中。安全研究人员通过UART串口进入AT命令模式，利用固件更新功能将Flash内容导出，然后用binwalk识别出模型文件为TensorFlow Lite格式。进一步用Netron工具打开模型文件，完整还原了模型架构（MobileNetV2变体）和所有权重参数。该公司损失了投入数月训练得到的模型知识产权。
常见误区：不要依赖“安全通过混淆”——将密钥拆分成多段存储、使用自定义编码、或把模型参数藏在图片资源中，这些手段只能延缓攻击，无法阻止有经验的逆向工程师。固件逆向是确定性极高的攻击方式，必须从加密和访问控制层面解决。
4.4 调试接口攻击：利用硬件调试通道接管设备
核心原理：调试接口（JTAG、SWD、CJTAG）是MCU和SoC用于在线调试、编程、测试的标准接口。如果设备出厂后未禁用调试接口，攻击者可以通过调试器（如J-Link、ST-Link）直接连接目标芯片，实现：读取/修改内存、设置断点、单步执行、读取Flash内容、甚至绕过安全启动。在TinyML设备中，调试接口攻击往往是最快捷的入侵路径。
判断方法与操作流程：调试接口风险评估要点：
- 调试接口是否物理暴露？PCB上是否有JTAG/SWD排针或测试点。
- 调试接口是否被禁用？检查MCU的选项字节（Option Bytes）中调试端口是否设置为Disable。
- 是否有访问保护等级？STM32的RDP（Read-out Protection）级别：Level 0（无保护）、Level 1（禁止外部调试读取Flash）、Level 2（永久禁用调试，不可回退）。
- Boot引脚是否可控？如果Boot引脚可被拉高/拉低，攻击者可以进入Boot ROM模式，绕过应用固件直接操作Flash。
攻击流程示例：攻击者使用ST-Link连接SWD接口，尝试读取MCU的Flash。如果RDP为Level 0，直接读取；如果为Level 1，则尝试通过Boot引脚进入系统存储器Bootloader，利用Bootloader的漏洞（如未校验地址范围）读取Flash。
实战场景：某可穿戴设备使用nRF52832芯片，PCB上预留了SWD调试排针（P1~P4）。安全测试中，测试人员用J-Link连接SWD，使用nrfjprog --readcode firmware.hex命令，在3秒内完整读取了设备固件（包含心率模型参数和蓝牙配对密钥）。原因是该设备未设置访问保护（APPROTECT未启用）。修复方案：在量产固件中启用nRF52的Approach保护（UICR寄存器配置），并移除PCB上的调试排针。
常见误区：很多开发者认为“只要不焊接调试接口，攻击者就无法连接”。实际上，攻击者可以临时焊接飞线到MCU的SWD引脚（通常可以从芯片封装引脚直接引出），或者使用探针台接触芯片引脚。调试接口保护必须依赖芯片级的安全配置（如RDP、OTP熔丝），而非物理隐藏。
4.5 威胁建模综合评估与优先级排序
核心原理：威胁建模的最终输出是一份风险清单，需要结合攻击可行性、攻击成本、资产价值三个维度进行优先级排序。对于TinyML存储安全，建议采用以下评估框架：
| 攻击类型 | 攻击成本 | 攻击可行性 | 影响严重度 | 优先级 |
|---|---|---|---|---|
| 物理提取（拆Flash） | 中（需编程器/热风枪） | 高（芯片裸露时） | 高（密钥+模型全泄露） | P0 |
| 调试接口攻击 | 低（仅需调试器） | 高（接口未禁用时） | 高（完全控制设备） | P0 |
| 固件逆向 | 低（软件工具免费） | 高（固件可获取时） | 中高（模型IP泄露） | P1 |
| 侧信道（功耗分析） | 高（需示波器+专业工具） | 中（需多次采集） | 中（密钥泄露） | P2 |
判断方法：在项目设计阶段，应针对每类攻击回答三个问题：
- 攻击面是否暴露？调试接口是否禁用？Flash是否加密？固件是否签名？
- 攻击成本是否可控？如果攻击成本超过资产价值，攻击者可能放弃。
- 攻击影响是否可接受？即使密钥泄露，是否有密钥轮换机制？模型泄露是否影响核心业务？
综合案例复盘：某智慧城市边缘节点（基于i.MX RT1062）在威胁建模中发现：
- 资产：AES密钥（用于加密与云端通信）、人脸识别模型（商业授权）、设备固件。
- 攻击面：JTAG接口未禁用（P0）、外部Flash未加密（P0）、固件无签名校验（P1）。
- 处置措施：① 量产时烧写eFuse禁用JTAG；② 启用FlexSPI的OTFAD（On-The-Fly AES Decryption）引擎，对Flash内容实时解密；③ 固件增加RSA签名验证。
- 结果：重新测试时，物理提取只能得到密文，调试接口无法连接，固件篡改会被检测。攻击成本从“低”提升到“高”，风险等级从P0降至P2。
- 复盘经验：威胁建模应在硬件设计阶段启动，因为禁用调试接口、eFuse烧写等操作无法在软件层面补救。
总结提醒：威胁建模不是一次性的文档工作，而是贯穿硬件设计、固件开发、量产配置、运维更新的持续过程。每次硬件改版、每次固件更新、每次部署环境变化，都应重新审视攻击面。对于TinyML设备，最有效的防护组合是：加密存储（防物理提取）+ 禁用调试接口（防调试攻击）+ 固件签名（防逆向篡改）+ 抗侧信道硬件（防功耗分析）。下一章将深入探讨密钥管理策略，为存储加密提供基础支撑。