2、TinyML基础与安全挑战：TinyML架构、资源约束、典型部署场景、安全风险分类（固件、模型、通信）
TinyML（微型机器学习）是指在极低功耗、极小内存和有限算力的嵌入式设备上运行机器学习模型的技术体系。与云端AI或边缘服务器不同，TinyML设备通常由电池供电、采用MCU（微控制器）或极简MPU（微处理器）作为计算核心，其安全防护能力远弱于通用计算平台。理解TinyML的架构特征、资源边界和部署场景，是制定有效安全测试清单的前提。本章将从这四个维度展开，为后续固件、模型和通信链路的逐项检查奠定基础。
2.1 TinyML架构：从传感器到推理引擎的完整链路
TinyML系统的架构可以抽象为四个层次：感知层、计算层、通信层和应用层。感知层负责采集物理世界的模拟信号，通过ADC（模数转换器）转换为数字量；计算层是TinyML的核心，通常由ARM Cortex-M系列MCU、RISC-V内核或带有NPU（神经网络处理单元）的SoC构成，负责运行轻量级推理引擎（如TensorFlow Lite Micro、CMSIS-NN）；通信层提供与外部世界交互的能力，常见接口包括BLE、WiFi、UART、SPI、I2C等；应用层则包含推理调度逻辑、OTA升级模块和用户业务代码。
从安全测试的角度看，每一层都有其独特的攻击面。感知层可能被注入虚假传感器数据（例如通过I2C总线干扰）；计算层的调试接口（SWD/JTAG）可能被用于读取固件或篡改内存；通信层的明文传输可能导致模型输入数据泄露；应用层的OTA机制若缺乏签名验证，则可能被植入恶意固件。理解这种分层架构，有助于测试人员建立“纵深防御”的检查思路，而不是仅关注单一环节。
2.2 资源约束：安全机制设计的“紧箍咒”
TinyML设备最显著的特征是资源极度受限。以典型的Cortex-M4 MCU为例，其Flash通常为256KB至1MB，RAM为64KB至256KB，主频在80MHz至200MHz之间。这意味着传统安全机制——如完整的TLS握手、大容量证书链验证、复杂的加密算法（如RSA-2048）——在TinyML设备上往往无法直接运行。例如，一次完整的ECDSA P-256签名验证需要约2KB RAM和数十毫秒的CPU时间，这在资源充足的平台上微不足道，但在TinyML设备上可能占用可用RAM的5%以上，并导致推理延迟显著增加。
| 资源项 | 典型范围 | 安全影响 |
|---|---|---|
| Flash存储 | 256KB ~ 2MB | 限制固件加密存储、安全补丁容量 |
| RAM | 16KB ~ 512KB | 限制密钥缓存、安全协议状态机大小 |
| CPU算力 | 10 ~ 100 MOPS | 限制非对称加密、实时加解密能力 |
| 功耗预算 | mW级（电池供电） | 限制持续安全监控、频繁密钥协商 |
| 网络带宽 | BLE 2Mbps / WiFi 802.11n | 限制安全日志上传、固件差分升级 |
资源约束直接决定了安全测试的“可行性边界”。例如，测试人员需要确认设备是否采用了硬件加速器（如AES-NI指令集或独立加密引擎）来弥补算力不足；是否使用轻量级协议（如DTLS for CoAP）替代完整TLS；是否采用预共享密钥（PSK）而非证书体系。在测试清单中，应明确标注“资源适配性检查”项，防止安全方案因资源不足而形同虚设。
2.3 典型部署场景：安全风险的差异化分析
不同部署场景对TinyML安全的要求差异巨大。在智能家居场景（如智能音箱的语音唤醒），设备长期在线、靠近用户，攻击者可能通过物理接触或网络侧发起攻击，隐私泄露风险突出；在工业预测性维护场景（如电机振动分析），设备部署在工厂车间，可能面临电磁干扰、固件篡改和传感器欺骗，安全重点在于数据完整性和系统可用性；在可穿戴健康设备中，设备采集心率、血氧等敏感生物数据，且通过BLE与手机通信，窃听和中间人攻击是主要威胁；在智慧农业场景，设备分布广泛、维护困难，固件远程升级的安全性成为关键。
安全测试人员应根据具体场景调整测试优先级。例如，对于可穿戴设备，应重点测试BLE通信的加密强度和密钥更新机制；对于工业设备，应重点验证传感器数据采集链路是否容易被物理干扰或逻辑注入；对于农业物联网，应重点检查OTA升级包的签名验证和回滚保护机制。场景化思维能避免“一刀切”的测试方案，提高测试效率和针对性。
2.4 安全风险分类：固件、模型与通信链路
TinyML的安全风险可以归纳为三大类：固件风险、模型风险和通信风险。固件风险包括Bootloader漏洞（如未锁定调试接口、未验证启动镜像签名）、固件逆向工程（通过读取Flash提取算法和密钥）、运行时内存破坏（如缓冲区溢出导致任意代码执行）。模型风险则包括模型窃取（通过侧信道或API查询还原模型参数）、模型投毒（在训练阶段注入恶意样本使模型行为异常）、对抗样本攻击（通过微小扰动使模型误判）。通信风险涵盖窃听（明文传输模型输入或推理结果）、重放攻击（捕获并重放合法指令）、中间人攻击（在设备与服务器之间插入恶意节点）。
核心判断方法：在安全测试中，应首先通过威胁建模确定每类风险的实际可利用性。例如，对于固件风险，可通过检查MCU的调试接口是否禁用、Flash读取保护（RDP）级别是否设置、启动镜像是否包含签名验证来判断；对于模型风险，可通过分析模型文件是否加密存储、推理过程是否存在时序侧信道、输入数据是否经过异常检测来判断；对于通信风险，可通过抓包分析协议是否加密、密钥是否定期轮换、设备是否支持双向认证来判断。
2.5 案例拆解：智能门锁TinyML语音唤醒模块的安全评估
某智能门锁厂商在其产品中集成了TinyML语音唤醒模块，用于实现“你好，小锁”的免接触开锁功能。该模块基于Cortex-M4 MCU（主频120MHz，Flash 512KB，RAM 128KB），使用TensorFlow Lite Micro运行一个20KB的语音识别模型，通过I2C接口连接MEMS麦克风，并通过BLE 5.0与手机App通信。在安全评估中，测试团队发现了以下问题：
- 固件层：MCU的SWD调试接口未禁用，攻击者可通过J-Link读取完整固件，提取语音特征提取算法和模型参数；Bootloader未启用签名验证，可被刷入恶意固件。
- 模型层：模型文件以明文形式存储在外部SPI Flash中，攻击者可直接复制模型；推理过程未加入输入异常检测，存在对抗样本攻击风险（例如播放特定噪声使模型误判为唤醒词）。
- 通信层：BLE通信使用静态密钥（硬编码在固件中），且未启用配对绑定，攻击者可通过嗅探获取密钥，进而解密通信内容或重放开锁指令。
针对上述问题，测试团队建议并协助实施了以下整改措施：禁用SWD接口并设置RDP Level 2；在Bootloader中加入基于SHA-256的镜像签名验证；将模型文件加密存储，并在推理前进行轻量级输入校验（如信噪比检测）；BLE通信改用动态密钥协商（基于ECDH），并启用LE Secure Connections配对模式。整改后，重新进行渗透测试，发现攻击路径均被有效阻断，设备通过安全评估。
常见误区提醒：许多开发团队认为TinyML设备“太小不值得攻击”，或认为“加密会拖慢推理速度所以放弃”。实际上，攻击者往往优先选择防护最薄弱的环节——例如未锁定的调试接口或硬编码密钥。安全测试应优先覆盖这些“低成本高收益”的攻击面，而不是盲目追求全量加密。