4. 威胁建模与安全需求

TinyML设备从开发板上的功能Demo走向量产可信交付，最核心的转变之一就是建立系统化的威胁建模能力。开发板Demo阶段，我们关注的是“模型能否跑起来、精度是否达标”；而量产阶段，我们必须回答“攻击者会从哪些路径破坏设备、窃取模型或篡改行为”。本章将围绕TinyML设备面临的四类典型攻击——模型窃取、逆向工程、数据投毒、侧信道分析——展开威胁建模方法，并给出可落地的安全需求定义框架。

上图展示了TinyML设备威胁建模的核心逻辑：攻击者从四个不同阶段和路径切入，最终目标都是破坏设备的机密性、完整性、可用性或模型知识产权。下面我们将逐一拆解每类攻击的原理、判断方法、实战案例与常见误区，最后汇总为可执行的安全需求清单。

4.1 模型窃取：从黑盒查询到白盒提取

核心原理

模型窃取（Model Extraction）指攻击者通过合法或非法途径获取模型参数、结构或决策边界。在TinyML场景中，由于设备通常部署在物理可接触的环境中，攻击者可能直接读取Flash中的模型文件，或通过反复调用设备推理接口（如分类置信度输出）来训练一个功能等价的替代模型。与云端大模型不同，TinyML模型参数量小（通常<1MB），窃取成本极低，且一旦被复制即可被无限分发。

判断方法与操作流程

评估模型窃取风险时，建议按以下流程操作：

1. 识别暴露面：检查设备是否提供调试串口、JTAG/SWD接口、USB Mass Storage或OTA回滚通道。
2. 评估接口输出粒度：推理接口返回的是完整置信度向量，还是仅返回Top-1标签？输出越详细，窃取效率越高。
3. 测试查询频率限制：设备是否对单位时间内的推理请求数有限制？无限制的设备可在数小时内被训练出高仿模型。
4. 检查存储介质：模型文件是否以明文存储在外部Flash或SD卡中？若是，则物理接触即等于模型泄露。

案例拆解：智能门锁的模型窃取事件

某智能门锁厂商使用TinyML做人脸识别，模型存储在外部SPI Flash中。安全测试人员通过以下步骤成功提取模型：

• 初始现象：门锁固件支持OTA升级，但未对升级包加密；测试人员截获升级包后解包，直接获得未加密的模型文件（约800KB）。
• 分析过程：进一步检查发现，设备在启动时通过DMA将模型从Flash加载到RAM，且未设置读保护（RDP）。使用ST-Link连接SWD接口，可直接dump整个Flash内容。
• 实际操作：① 使用STM32CubeProgrammer读取Flash，耗时约2分钟；② 从dump文件中定位模型头文件（特征魔数），提取完整模型；③ 在PC端使用TensorFlow Lite Micro加载该模型，验证推理结果与设备一致。
• 结果对比：攻击者仅需约30分钟即可完成模型提取，且无需任何专业设备。厂商损失：模型知识产权完全泄露，且可被用于制作仿冒设备。
• 复盘经验：该案例暴露了三个关键缺陷——未启用Flash读保护、模型明文存储、OTA包未加密。修复方案为：启用RDP Level 2、使用MCU内置加密引擎对模型进行AES-128-CBC加密、OTA包增加签名校验。

常见误区与总结

• 误区一：“模型很小，泄露了也无所谓”——恰恰因为小，复制和分发成本极低，危害扩散更快。
• 误区二：“只要代码混淆就能保护模型”——混淆只能增加静态分析难度，无法阻止运行时的内存dump或侧信道提取。
• 误区三：“MCU上没有TEE，所以无法保护”——即使没有TrustZone，也可通过MPU隔离、加密存储和最小权限原则大幅提高攻击成本。

4.2 逆向工程：固件分析与算法还原

核心原理

逆向工程（Reverse Engineering）针对的是设备固件和硬件逻辑。攻击者通过反汇编、调试、逻辑分析等手段，还原设备的启动流程、通信协议、密钥存储位置和模型推理逻辑。TinyML设备通常使用ARM Cortex-M系列MCU，固件体积小、符号表可能未剥离，逆向难度远低于应用处理器。

判断方法与操作流程

案例拆解：工业传感器固件逆向

某工业振动传感器使用TinyML进行故障诊断，固件通过UART输出调试日志。安全团队在评估中发现：

• 初始现象：设备启动时打印“Model loaded at 0x08020000, size 456KB”等详细信息。
• 分析过程：攻击者利用UART日志定位模型加载地址，随后通过SWD接口读取该地址段数据，获得模型权重。进一步反汇编发现，设备使用固定的XOR密钥（0x5A）对模型进行“加密”，该密钥硬编码在代码中。
• 实际操作：① 使用逻辑分析仪捕获UART启动日志；② 根据日志地址，通过OpenOCD dump Flash；③ 编写Python脚本对dump数据执行XOR 0x5A解密，成功还原原始模型。
• 结果对比：整个逆向过程耗时约4小时，攻击者完全掌握了模型结构和传感器校准参数，可伪造设备数据。
• 复盘经验：该案例说明，仅依赖“安全通过模糊”是无效的。正确做法是：量产固件关闭所有调试输出、使用硬件加密引擎而非软件XOR、启用读保护并设置调试口令。

常见误区与总结

• 误区一：“MCU代码简单，没人会逆向”——恰恰因为简单，逆向门槛低，攻击者可能只是业余爱好者。
• 误区二：“加了加密就安全”——加密算法本身可能被逆向，密钥管理才是核心。
• 误区三：“安全启动只防固件篡改”——安全启动同样能防止攻击者注入恶意固件来dump模型。

4.3 数据投毒：训练阶段与OTA更新的隐蔽威胁

核心原理

数据投毒（Data Poisoning）发生在模型训练阶段或OTA更新阶段。攻击者通过污染训练数据集（如向正常样本中混入对抗样本或错误标签），使模型在特定触发条件下产生错误输出。在TinyML场景中，由于设备通常依赖云端训练后下发模型，投毒攻击的入口主要在数据采集管道或OTA更新通道。

判断方法与操作流程

评估数据投毒风险时，需关注以下环节：

1. 数据来源审计：训练数据是否来自不可信的众包平台？是否经过清洗和异常检测？
2. OTA更新链路：模型更新包是否签名？签名密钥是否安全存储？是否支持回滚攻击？
3. 模型行为验证：模型在部署前是否经过鲁棒性测试（如FGSM、PGD对抗样本测试）？
4. 设备端输入验证：设备是否对输入数据进行范围检查或异常检测？

案例拆解：智能分拣机器人的投毒攻击

某物流公司使用TinyML视觉分拣机器人识别包裹上的标签。攻击者通过以下方式实施投毒：

• 初始现象：机器人对印有特定黑色方块图案的包裹识别错误率从2%骤升至85%。
• 分析过程：调查发现，攻击者在数据采集阶段向训练集中混入了500张带有黑色方块水印的“正常”包裹图片，并错误标注为“易碎品”。模型学习到该水印与“易碎品”的强关联。
• 实际操作：① 攻击者在测试阶段打印带有相同黑色方块的A4纸，贴在普通包裹上；② 机器人误判为易碎品，将其分流至人工处理通道；③ 攻击者利用该漏洞走私违禁品。
• 结果对比：攻击造成每小时约200件包裹误分拣，直接经济损失约5万元/天。修复方案：重新清洗训练数据、增加对抗训练、在设备端增加输入图像异常检测模块。
• 复盘经验：数据投毒的隐蔽性极强，传统精度指标无法发现。建议在训练管道中增加数据指纹校验和异常样本检测。

常见误区与总结

• 误区一：“我们的训练数据是内部采集的，不会中毒”——内部人员也可能有意或无意引入污染数据。
• 误区二：“模型精度高就说明没中毒”——投毒样本通常只占极小比例，对整体精度影响有限。
• 误区三：“OTA签名就够了”——签名只能防篡改，不能防投毒；投毒发生在训练阶段，签名无法识别。

4.4 侧信道分析：功耗、电磁与时间泄露

核心原理

侧信道攻击（Side-Channel Analysis）利用设备运行时的物理泄露（功耗、电磁辐射、执行时间、温度等）来提取敏感信息。在TinyML场景中，MCU在执行模型推理时，不同权重和激活值会导致不同的功耗模式。攻击者通过采集大量功耗轨迹，使用差分功耗分析（DPA）或相关功耗分析（CPA）可恢复模型权重或密钥。

判断方法与操作流程

侧信道风险评估需要专业设备和信号处理能力，操作流程如下：

1. 信号采集：使用示波器（≥100MS/s采样率）和高精度电流探头（带宽≥50MHz）采集MCU VCC引脚上的功耗轨迹。
2. 对齐预处理：由于MCU时钟抖动，需对轨迹进行重采样或互相关对齐。
3. 泄露点分析：使用TVLA（Test Vector Leakage Assessment）统计方法检测泄露点。
4. 密钥/权重恢复：针对AES密钥或模型权重，构建假设模型，计算相关系数，恢复敏感数据。

案例拆解：MCU上AES密钥的DPA攻击

某TinyML设备使用AES-128加密模型文件，密钥存储在MCU内部Flash。安全团队进行了以下侧信道评估：

• 初始现象：设备在启动时解密模型，解密过程约200ms，期间功耗有明显波动。
• 分析过程：采集5000条功耗轨迹，使用CPA攻击针对AES第一轮S-box输出。由于MCU未做任何掩码或隐藏措施，相关系数在正确密钥假设下达到0.72。
• 实际操作：① 使用ChipWhisperer-Lite采集板，以100MS/s采样率采集功耗；② 在PC端使用Python的scikit-learn库计算相关系数矩阵；③ 经过约2小时分析，成功恢复全部16字节AES密钥。
• 结果对比：恢复密钥后，攻击者解密了Flash中的模型文件，实现了模型窃取。修复方案：在AES实现中增加随机掩码（Boolean Masking）、使用恒定时间实现、降低信噪比（增加噪声源）。
• 复盘经验：侧信道攻击不是理论威胁，而是实际可操作的攻击手段。对于量产设备，建议至少进行TVLA测试，确保没有明显泄露。

常见误区与总结

• 误区一：“MCU频率低，侧信道攻击不现实”——频率低反而更容易采集，因为信号带宽要求低。
• 误区二：“软件掩码就够了”——软件掩码可能被二阶DPA攻破，需结合硬件防护。
• 误区三：“侧信道只针对密钥”——模型权重同样可通过侧信道泄露，尤其是浮点运算的功耗差异明显。

4.5 安全需求定义：从威胁到可验证的工程要求

核心原理

安全需求定义是将威胁建模结果转化为可设计、可测试、可验收的工程规范。需求必须满足SMART原则（Specific, Measurable, Achievable, Relevant, Time-bound），且每个需求都应追溯到至少一个威胁场景。

安全需求清单

需求优先级与实施策略

并非所有需求都需要在V1.0实现。建议按以下优先级排序：

• P0（必须）：SR-01、SR-03、SR-04——这些是基础安全底线，缺失将导致设备完全暴露。
• P1（强烈建议）：SR-02、SR-05——这些能显著提高攻击成本，且实现成本可控。
• P2（可选）：SR-06、SR-07、SR-08——根据产品定位和威胁模型决定是否实施。

常见误区与总结

• 误区一：“安全需求越多越好”——过度设计会增加成本和性能开销，应根据威胁模型精准定义。
• 误区二：“安全需求是安全团队的事”——需求必须由产品、研发、测试共同评审，确保可落地。
• 误区三：“通过认证就代表安全”——认证只是最低要求，实际威胁可能超出认证范围。