3、威胁模型：未签名固件面临的风险，如模型篡改、恶意注入、中间人攻击等
TinyML 设备通常部署在物理边界模糊、网络环境不可控的场景中，例如智能传感器节点、边缘推理盒子、电池供电的监测终端等。当固件包（尤其是包含模型权重、推理引擎和启动加载器的完整镜像）未经数字签名保护时，攻击者便获得了操纵设备行为的潜在通道。理解这些威胁的具体形态、攻击路径和实际后果，是设计固件签名机制的前提。本章将系统梳理未签名固件面临的核心风险，并给出可操作的威胁建模方法。
3.1 核心原理：为什么签名是TinyML安全的基石
TinyML固件签名机制的本质，是在固件包中附加一段由可信私钥生成的数字签名，设备端使用对应的公钥在加载固件前进行验证。这一机制解决的是完整性和来源可信性两个核心问题：完整性确保固件在传输或存储过程中未被篡改，来源可信性确保固件确实来自合法的开发者或设备制造商。对于资源受限的MCU（通常只有几十KB RAM和几百KB Flash），签名验证通常采用非对称加密算法（如ECDSA P-256）或带密钥的哈希算法（如HMAC-SHA256），前者适用于公钥可公开分发的场景，后者适用于对称密钥预置的场景。
从攻击面来看，未签名固件相当于给攻击者敞开了三扇门：网络通道（OTA更新时的中间人攻击）、物理通道（调试接口或存储芯片的直接读写）、供应链通道（开发工具链或第三方库被污染）。签名机制并不能完全阻止攻击者获取设备物理访问权，但它能显著提高攻击成本——攻击者即使拿到了固件镜像，也无法在不被发现的情况下修改它，因为任何改动都会导致签名验证失败。
3.2 判断方法：识别未签名固件的风险暴露面
在实际项目中，判断一个TinyML系统是否面临未签名固件风险，可以从以下四个维度进行排查。下表总结了各维度的检查要点和风险等级判定标准。
| 检查维度 | 具体检查项 | 高风险特征 | 低风险特征 |
|---|---|---|---|
| 启动链路 | Bootloader是否校验App固件签名 | Bootloader直接跳转执行，无任何校验 | Bootloader内置公钥，逐字节验证签名后才跳转 |
| OTA更新通道 | 固件下载过程是否使用TLS/签名包 | HTTP明文下载，固件包无签名字段 | HTTPS+固件包内嵌签名，设备端验签 |
| 存储保护 | Flash中的固件是否可被外部工具改写 | 未使能读保护，SWD/JTAG接口开放 | 使能RDP级别2，调试接口锁定 |
| 密钥管理 | 签名公钥/私钥的存储位置 | 私钥存放在开发电脑明文目录，公钥可被替换 | 私钥保存在HSM或安全存储区，公钥烧录在OTP区域 |
一个实用的判断方法是：尝试从攻击者的视角走一遍攻击路径。假设你获得了设备的物理访问权，能否通过UART进入shell？能否用ST-Link读取Flash内容？能否在OTA更新时用Wireshark抓到明文固件包？如果以上任何一个问题的答案是“能”，那么你的设备就暴露在未签名固件的风险之下。更系统的做法是使用微软的STRIDE威胁建模方法，对每个威胁类型（欺骗、篡改、否认、信息泄露、拒绝服务、权限提升）逐一评估固件更新流程中的对应风险。
3.3 案例拆解：智能电表模型篡改攻击实录
为更具体地说明未签名固件的危害，这里拆解一个典型的攻击案例。某电力公司部署了10万只基于TinyML的智能电表，用于窃电检测。电表内置一个轻量级神经网络，输入为电压、电流、功率因数等时序特征，输出为“正常/疑似窃电”的二分类结果。固件通过GPRS网络进行OTA升级，但升级包未做任何签名保护。
攻击过程：
- 嗅探与逆向：攻击者用软件无线电设备嗅探GPRS通信，捕获到一个完整的OTA固件包（约200KB）。通过binwalk分析，提取出模型权重文件（约80KB的float32数组）。
- 模型篡改：攻击者使用TensorFlow加载原始模型，将最后一层全连接层的权重矩阵乘以0.1，使模型的输出概率整体降低。重新打包固件后，计算新的CRC32校验值并替换原值。
- 中间人注入：攻击者在电表附近架设伪基站，迫使电表连接到攻击者的GPRS网关。当电表请求OTA更新时，攻击者将篡改后的固件包发送给电表。
- 结果：电表Bootloader未校验签名，直接跳转到新固件执行。此后，该电表对窃电行为的检测准确率从92%下降到34%，大量窃电行为被漏报。攻击者在三个月内窃取了价值约15万元的电能。
复盘与教训：
- 如果固件包带有ECDSA签名，攻击者在没有私钥的情况下无法生成有效签名，篡改后的固件会在Bootloader阶段被拒绝加载。
- 即使攻击者无法篡改模型，仅通过重放旧版本固件（降级攻击）也可能造成安全漏洞。因此签名机制还应包含版本号防回滚逻辑。
- 该案例中，攻击者利用的是OTA通道的明文传输和Bootloader的“无脑信任”。修复方案是双管齐下：传输层启用TLS，固件包增加签名校验。
3.4 常见误区与总结复盘
在辅导多个TinyML项目落地固件签名时，我发现团队常陷入以下四个误区，这些误区往往导致签名机制形同虚设或实施失败。
| 误区 | 错误认知 | 正确做法 |
|---|---|---|
| 签名=加密 | 认为固件签名会暴露模型权重，因此拒绝实施 | 签名不改变固件内容，只附加验证信息；如需保密，可叠加加密层 |
| 只在OTA时验签 | 认为下载时验证过签名就万事大吉 | 必须在Bootloader加载固件时再次验签，防止Flash被直接改写后绕过OTA流程 |
| 公钥随意存储 | 将公钥放在文件系统或外部EEPROM中 | 公钥应烧录在芯片OTP区域或安全Flash区，防止被替换为攻击者的公钥 |
| 忽略回滚保护 | 只验证签名不检查版本号 | 在签名结构中包含版本号字段，Bootloader拒绝加载低于当前版本的固件 |
总结复盘：未签名固件的威胁模型可以概括为“一个前提、三条路径、四类后果”。一个前提是设备缺少对固件来源和完整性的验证能力；三条路径分别是网络中间人攻击、物理存储篡改、供应链投毒；四类后果包括推理结果错误、设备行为劫持、敏感数据泄露、设备沦为僵尸网络节点。在设计TinyML产品时，建议将签名验证作为启动流程的强制步骤，而不是可选项。具体实施时，优先选择硬件加速的加密引擎（如ARM TrustZone、NXP EdgeLock），在资源允许的情况下使用ECDSA P-256而非RSA-2048，因为前者在MCU上的验证速度更快且密钥更短。最后，务必建立密钥轮换和吊销机制，防止私钥泄露后整个设备群面临风险。