3、供应链攻击面分析：模型投毒、后门注入、依赖劫持、构建篡改、分发替换等攻击类型

TinyML 系统的供应链与传统软件供应链最大的差异在于：它同时包含模型资产（权重、结构、训练数据）、代码资产（推理框架、算子库、设备驱动）以及构建产物（固件镜像、模型二进制、签名证书）。攻击者只需在供应链的任意一个环节植入恶意逻辑，就能绕过终端设备上所有的安全防护机制——因为信任链的起点已经被污染。本章将系统拆解 TinyML 供应链的五大攻击面：模型投毒、后门注入、依赖劫持、构建篡改与分发替换，并给出每个攻击面的检测思路与防御要点。

3.1 模型投毒：数据层面的隐蔽污染

核心原理

模型投毒（Model Poisoning）发生在模型训练或微调阶段，攻击者通过污染训练数据集、篡改标注或注入恶意样本，使模型在特定输入下产生攻击者期望的错误输出。在 TinyML 场景中，由于设备算力有限，多数模型采用预训练 + 微调或知识蒸馏的方式生成，攻击者可以瞄准公开的预训练模型库或数据标注平台实施投毒。与传统的软件漏洞不同，投毒后的模型在常规测试集上可能表现完全正常，只有在攻击者控制的特定触发条件下才会暴露恶意行为。

判断方法与检测手段

• 数据血缘审计：追溯训练数据的来源、标注人员、数据增强流程，检查是否存在异常的数据注入点。
• 异常样本检测：使用聚类算法（如 K-Means、DBSCAN）对训练样本进行分布分析，寻找远离正常分布的离群点。
• 神经元激活模式分析：对模型中间层输出进行统计分析，投毒样本往往会在特定神经元上产生异常的激活模式。
• 触发条件探测：使用模糊测试或梯度引导搜索，尝试寻找可能导致模型误分类的微小输入扰动。

案例拆解：智能门锁的指纹识别模型投毒

某智能门锁厂商使用公开的指纹数据集训练指纹识别模型，并计划部署到低功耗 MCU 上。攻击者在数据集中混入了 200 张带有特定纹理噪声的"万能指纹"样本，并将这些样本标注为合法用户指纹。模型训练完成后，在标准测试集上准确率达到 98.7%，通过验收。然而在实际部署后，攻击者只需在指纹传感器上贴一层带有特定纹理的薄膜，即可伪造合法指纹解锁门锁。

复盘发现：该厂商在数据采集阶段未对第三方标注平台的数据进行抽样复核，且验收测试仅使用了标准测试集，未包含对抗性样本。改进措施包括：建立数据来源白名单、对训练数据进行异常检测、在验收阶段加入对抗性测试集。

3.2 后门注入：模型内部的隐蔽触发器

核心原理

后门注入（Backdoor Injection）与模型投毒密切相关，但更强调在模型结构中植入特定的触发机制。攻击者可以在训练阶段通过修改损失函数或直接修改模型权重，使模型在遇到特定触发器（如特定像素模式、特定音频片段、特定传感器读数组合）时输出攻击者预设的结果。在 TinyML 场景中，后门触发器可以设计得非常隐蔽——例如，一个在正常光照下不可见的红外图案，或者一个超出人耳听觉范围的超声波信号。

后门注入的常见手法

检测与防御策略

• 模型指纹比对：对模型权重计算哈希值，与可信来源的基准模型进行比对，发现任何微小的权重差异。
• 神经元剪枝分析：逐层分析神经元的重要性，后门注入往往会导致某些"冗余"神经元对特定输入异常敏感。
• 输入扰动测试：对输入样本施加随机噪声或特定模式的扰动，观察模型输出的稳定性。
• 模型蒸馏净化：使用干净数据集对可疑模型进行蒸馏重训练，可以在一定程度上消除后门触发器的影响。

3.3 依赖劫持：开源组件的供应链投毒

核心原理

依赖劫持（Dependency Hijacking）是指攻击者通过伪装成合法的开源库、工具包或插件，诱导开发者下载并集成恶意代码。TinyML 项目的依赖链通常包括：Python 端的训练框架（TensorFlow、PyTorch）、模型转换工具（TFLite Converter、ONNX Runtime）、嵌入式端的推理库（CMSIS-NN、TensorFlow Lite Micro）、以及各种辅助工具（图像处理库、音频编解码库）。攻击者可以注册与合法库名称相似的恶意包（如 tensorflow-lite-micro 与 tensorflow-lite-micr0），或直接攻破维护者的账号发布恶意版本。

依赖劫持的典型攻击路径

1. 名称混淆攻击：注册与知名库名称相似但拼写略有差异的恶意包，利用开发者拼写错误或自动补全机制。
2. 版本回滚攻击：在合法库的新版本中植入恶意代码，或诱导开发者使用包含漏洞的旧版本。
3. 传递依赖攻击：在合法库的依赖项中植入恶意代码，开发者直接依赖合法库，但合法库又依赖了恶意库。
4. 维护者账号劫持：通过钓鱼或密码猜测获取库维护者的账号权限，直接发布恶意版本。

防御措施

• 使用 requirements.txt 或 Pipfile.lock 锁定所有直接和传递依赖的精确版本号。
• 配置私有镜像仓库（如 JFrog Artifactory、Nexus），只从可信源拉取依赖包。
• 对依赖包进行哈希校验，确保下载的包与官方发布的哈希值一致。
• 定期使用 pip-audit、safety 等工具扫描依赖漏洞。

3.4 构建篡改：编译与打包环节的恶意注入

核心原理

构建篡改（Build Tampering）发生在模型转换、代码编译、固件打包等构建环节。攻击者可能通过篡改构建脚本、替换编译器、修改 Makefile 或 CMakeLists.txt 文件，在构建产物中植入恶意代码。在 TinyML 场景中，构建过程通常涉及交叉编译（如 ARM GCC、RISC-V Toolchain），攻击者可以替换交叉编译器或在编译参数中注入恶意宏定义。

构建篡改的常见形式

构建可复现性作为防御手段

构建可复现（Reproducible Builds）是抵御构建篡改的有效手段。其核心思想是：在相同的源代码、相同的依赖版本、相同的构建环境下，重复构建应产生完全相同的二进制产物。通过对比两个独立构建产物的哈希值，可以快速发现构建过程中是否存在任何篡改。TinyML 项目应尽量使用 Docker 容器或虚拟机固定构建环境，并记录构建环境的完整镜像哈希。

# 构建可复现性验证示例
# 第一次构建
docker build -t tinyml-build:v1.0 -f Dockerfile.build .
docker run --rm -v $(pwd)/output:/output tinyml-build:v1.0
sha256sum output/firmware.bin > build1.sha256

# 第二次构建（使用相同镜像）
docker run --rm -v $(pwd)/output2:/output tinyml-build:v1.0
sha256sum output2/firmware.bin > build2.sha256

# 比对哈希
diff build1.sha256 build2.sha256  # 应无输出

3.5 分发替换：OTA 与固件更新链路的攻击

核心原理

分发替换（Distribution Replacement）发生在模型或固件从构建服务器传输到终端设备的过程中。攻击者可以通过中间人攻击（MITM）、DNS 劫持、CDN 缓存投毒等方式，替换传输中的固件镜像或模型文件。在 TinyML 设备中，OTA（Over-The-Air）更新是最常见的分发渠道，攻击者可以伪造 OTA 服务器或篡改 OTA 包，向设备推送恶意固件。

分发替换的攻击场景

• OTA 包替换：攻击者截获 OTA 更新包，替换为包含恶意代码的固件，并重新计算校验值（如果校验机制不完善）。
• 降级攻击：攻击者诱导设备回滚到存在已知漏洞的旧版本固件，从而利用旧版本的漏洞进行攻击。
• 证书伪造：攻击者伪造签名证书，使设备信任恶意固件包。
• 本地分发劫持：在设备通过 USB 或 SD 卡进行本地更新时，攻击者替换存储介质中的固件文件。

安全分发架构设计

1. 端到端加密：使用 TLS 或 DTLS 加密 OTA 传输通道，防止中间人窃听和篡改。
2. 代码签名：所有固件和模型文件必须使用设备内置的根证书进行签名验证，签名算法推荐 ECDSA P-256 或 Ed25519。
3. 安全启动链：设备启动时逐级验证引导加载程序、固件、模型文件的签名，任何一级验证失败即拒绝启动。
4. 防回滚机制：在设备中存储当前固件版本号，拒绝安装低于当前版本的固件包。
5. 更新包哈希校验：在固件包中嵌入哈希值，设备在安装前重新计算并比对。

3.6 攻击面综合对比与防御优先级

3.7 常见误区与总结复盘

误区一：只关注代码漏洞，忽视模型资产

许多 TinyML 团队将安全重点放在固件代码的漏洞扫描上，却忽视了模型文件本身可能携带恶意逻辑。实际上，模型投毒和后门注入的攻击效果往往比代码漏洞更隐蔽，且难以通过传统的静态分析工具发现。

误区二：依赖锁定等于安全

锁定依赖版本可以防止意外升级，但并不能防止攻击者直接攻破合法库的维护者账号并发布恶意版本。依赖锁定必须与来源验证（哈希校验、签名验证）结合使用。

误区三：构建可复现性只是开发效率工具

构建可复现性不仅是团队协作的便利工具，更是供应链安全的重要防线。通过对比独立构建的产物哈希，可以快速发现构建环境或构建脚本是否被篡改。

误区四：OTA 加密即可保证安全

OTA 加密只能防止传输过程中的窃听和篡改，但无法防止攻击者通过其他途径（如物理接触设备、提取密钥）伪造更新包。必须建立完整的信任链：安全启动 → 固件签名验证 → 防回滚机制 → 更新包哈希校验。