4、模型完整性威胁模型：意外损坏、传输错误、恶意篡改、模型替换攻击等风险场景
TinyML 模型在从开发环境到边缘设备的全生命周期中，面临着多种完整性威胁。与云端 AI 模型不同，TinyML 模型通常部署在资源受限的微控制器（MCU）上，缺乏完整的操作系统防护和硬件安全模块支持，这使得模型文件更容易受到物理环境、通信链路和恶意攻击的影响。理解这些威胁的具体形态、攻击路径和潜在后果，是设计有效校验机制的前提。本章将系统梳理四类核心风险场景，并给出对应的检测与防御思路。
4.1 意外损坏：Flash 存储的物理与逻辑失效
核心原理：嵌入式设备的模型通常存储在内部或外部 Flash 存储器中。Flash 的物理特性决定了其在写入擦除循环、电压波动、温度极端变化或长期存放后，可能出现位翻转（Bit Flip）或块失效。此外，设备在固件升级过程中意外断电，也可能导致模型文件写入不完整，形成半截模型。
判断方法：意外损坏通常表现为模型加载后推理结果异常，但设备本身运行正常。例如，一个图像分类模型在部署后，对同一张测试图片的输出从“猫”变为“狗”，且概率分布明显异常。此时应首先检查 Flash 读取的原始数据是否与编译产物一致。
// 伪代码：读取模型并计算 CRC32
uint32_t crc = 0;
for (int i = 0; i < model_len; i++) {
crc = crc32_byte(crc, model_buffer[i]);
}
if (crc != expected_crc) {
// 触发完整性错误处理
rollback_to_backup_model();
}案例拆解：某智能家居温控器使用 STM32F4 系列 MCU，模型存储在内部 Flash 的 0x08040000 地址。设备在夏季高温环境（环境温度 45°C）连续运行 3 个月后，用户反馈温度预测偏差增大。工程师通过调试器读取模型区域数据，发现偏移 0x2A3F 处的一个字节从 0x3C 变为 0x3D。虽然仅一位翻转，但该字节恰好是神经网络某一层权重的指数部分，导致输出误差放大。最终通过增加 CRC32 校验并在启动时验证，发现问题后自动回退到备份模型，解决了该问题。
4.2 传输错误：OTA 升级与串口烧录中的数据污染
核心原理：TinyML 模型的更新通常通过 UART、SPI、I2C 或无线 OTA（Over-The-Air）进行。这些通信链路在电磁干扰、信号衰减、波特率不匹配或协议栈缺陷下，可能产生数据包丢失、重复、错序或位错误。尤其在使用低功耗蓝牙或 LoRa 等窄带宽信道时，传输错误率会显著上升。
操作流程：在 OTA 升级流程中，必须实现“分块传输 + 逐块校验 + 整体校验”的三级保障机制。首先，将模型文件切分为 256 字节或 512 字节的数据块，每块附带 CRC16 校验值；接收端逐块验证，失败则请求重传。全部块接收完成后，再对整个模型文件计算 SHA-256 哈希，与固件包头部携带的哈希值比对。
| 传输方式 | 典型误码率 | 推荐校验 | 重传策略 |
|---|---|---|---|
| UART (115200bps) | 10^-6 ~ 10^-4 | CRC16/块 + CRC32/整体 | ARQ 自动重传 |
| BLE 5.0 | 10^-3 ~ 10^-2 | CRC24 + 序列号 | 应用层重传 |
| Wi-Fi TCP | 10^-5 ~ 10^-3 | TCP 校验 + SHA-256 | TCP 内建重传 |
| LoRa | 10^-2 ~ 10^-1 | CRC32 + 前向纠错 | 跳频重发 |
实战场景：某农业物联网设备通过 4G Cat.1 模块进行模型 OTA 升级，模型大小 480KB。首次升级时，设备在接收 78% 数据后网络中断，重新连接后从断点续传，但未对已接收部分重新校验。最终模型文件拼接错误，设备启动后模型加载失败。改进方案为：每次重连后，从最后一个完整校验块开始重新传输，并在全部完成后执行 SHA-256 整体校验。
4.3 恶意篡改：逆向工程与权重投毒
核心原理：恶意篡改是指攻击者通过调试接口（JTAG/SWD）、固件提取或侧信道分析，获取模型文件后，对权重、偏置或激活函数参数进行修改，从而改变模型行为。这种攻击的隐蔽性极强，因为篡改后的模型可能仅在特定输入下产生错误输出，而正常输入下表现正常。
判断方法：检测恶意篡改不能仅依赖 CRC 或哈希，因为攻击者可以同时重新计算并更新校验值。必须使用基于密钥的认证机制，如 HMAC-SHA256 或 ECDSA 数字签名。设备端存储公钥，模型文件附带签名，加载前验证签名有效性。
// 使用 MbedTLS 验证 ECDSA 签名
mbedtls_ecdsa_context ctx;
mbedtls_ecdsa_init(&ctx);
mbedtls_ecp_group_load(&ctx.grp, MBEDTLS_ECP_DP_SECP256R1);
mbedtls_mpi_read_binary(&ctx.Q.X, pubkey_x, 32);
mbedtls_mpi_read_binary(&ctx.Q.Y, pubkey_y, 32);
int ret = mbedtls_ecdsa_read_signature(&ctx, hash, hash_len, sig, sig_len);
if (ret != 0) {
// 签名验证失败，拒绝加载模型
}案例拆解：某工业视觉检测设备使用 TensorFlow Lite Micro 部署缺陷检测模型。攻击者通过 UART 调试接口获取了模型文件，使用 Netron 工具分析网络结构后，将最后一层 Softmax 的偏置向量整体加 10.0，使得模型对任何输入都输出“合格”类别。由于设备没有签名验证机制，攻击者重新计算 CRC32 并写回 Flash，成功绕过校验。修复方案：在固件中集成 ECDSA P-256 签名验证，并将公钥烧录到 OTP（一次性可编程）区域，防止被替换。
4.4 模型替换攻击：回滚与注入
核心原理：模型替换攻击是指攻击者将设备上的模型文件整体替换为另一个模型。常见场景包括：将高精度模型回滚到有漏洞的旧版本（降级攻击）、替换为攻击者自制的恶意模型（如将所有输入分类为“正常”）、或替换为随机噪声模型导致设备拒绝服务。
操作流程：防御模型替换攻击需要建立“版本链 + 信任根”机制。设备端维护一个单调递增的版本计数器，每次合法升级后版本号加一。新模型的签名中必须包含版本号，且版本号必须大于当前值。同时，签名验证的根公钥应存储在芯片的信任根中（如 STM32 的 RDP 级别 2 或专用安全芯片）。
- 版本绑定：模型文件的元数据中写入版本号（如 0x0103），签名时将该版本号纳入签名数据。
- 回滚防护：设备在验证签名后，比较新版本号与 Flash 中存储的当前版本号，仅当新版本号更大时才允许写入。
- 安全存储：当前版本号存储在具备防篡改能力的区域（如 MCU 内部 Flash 的独立扇区，并启用写保护）。
案例拆解：某智能门锁使用人脸识别模型，初始版本为 v1.0。攻击者获取了 v1.0 的固件包，发现其签名密钥是硬编码在固件中的（开发人员失误）。攻击者使用该密钥对 v1.0 模型重新签名，并降级到已修复漏洞的 v1.0 版本，从而绕过 v2.0 中新增的活体检测功能。修复方案：更换密钥对，将私钥离线保存，公钥烧录到 OTP；同时增加版本号回滚防护，确保设备无法接受低于当前版本的模型。
4.5 威胁模型对比与综合防御策略
下表总结了四类威胁的关键特征、检测难度和推荐防御措施，便于在实际项目中快速决策。
| 威胁类型 | 攻击者能力 | 检测难度 | 主要防御手段 | 实现成本 |
|---|---|---|---|---|
| 意外损坏 | 无（自然因素） | 低 | CRC32 / 双备份 | 极低 |
| 传输错误 | 无（环境因素） | 低 | 分块 CRC + 整体 SHA-256 | 低 |
| 恶意篡改 | 有（物理接触） | 中 | HMAC / ECDSA 签名 | 中 |
| 模型替换 | 有（远程/物理） | 高 | 版本链 + 信任根 + 安全启动 | 高 |
综合防御策略：在实际 TinyML 项目中，应根据设备的安全等级和成本预算，分层实施防御。对于消费级产品（如智能音箱），至少应实现 CRC32 + SHA-256 校验；对于工业控制或医疗设备，必须增加 ECDSA 签名验证和安全启动；对于高安全场景（如支付终端），还需引入独立安全芯片和加密存储。