课程导入：TinyML安全威胁全景、学习目标、课程结构、安全测试在TinyML生命周期中的位置
TinyML（微型机器学习）正在将人工智能从云端数据中心推向数十亿个微控制器（MCU）和边缘设备。从智能家居传感器、可穿戴健康监测器，到工业预测性维护节点和农业环境监测终端，这些功耗仅为毫瓦级、内存以KB计算的设备，正在执行越来越复杂的推理任务。然而，当AI模型被部署到物理世界中的微小设备上时，一个新的攻击面也随之打开——这些设备往往缺乏传统安全防护能力，却直接接触真实物理环境，且难以远程更新。本章作为《TinyML安全测试清单》的开篇，将系统性地建立TinyML安全威胁的全景视图，明确课程学习目标与结构，并厘清安全测试在整个TinyML生命周期中的关键位置。
上图展示了TinyML安全威胁的全景以及安全测试在生命周期中的定位。可以看到，威胁并非单一维度，而是分布在固件、模型、通信和物理侧信道四个层面。安全测试不是某个阶段的孤立活动，而是贯穿从数据采集到运行推理的每一个环节。理解这一全景是后续章节展开具体测试清单的基础。
1.1 TinyML安全威胁全景：为什么微小设备面临巨大风险
TinyML设备的安全风险往往被低估，原因在于其“微小”的表象掩盖了“高价值”的本质。一个部署在工厂车间里的振动传感器，其内部模型可能承载着核心工艺参数；一个智能门锁中的语音识别模型，直接关联家庭安全；一支医疗级可穿戴设备，其心率异常检测模型关乎生命健康。攻击者一旦突破这些设备，不仅能窃取模型知识产权，还能操纵设备行为，甚至将设备作为跳板攻击整个网络。
从攻击面来看，TinyML设备与传统IT系统有本质差异。传统服务器位于受控的数据中心，有防火墙、入侵检测、定期补丁等防护；而TinyML设备通常暴露在物理环境中，攻击者可以物理接触设备，进行拆解、探针测量、芯片级分析。更关键的是，TinyML设备的资源极度受限——一个典型的ARM Cortex-M4内核MCU，可能只有256KB Flash和64KB RAM，无法运行完整的加密协议栈或复杂的入侵检测系统。这种“物理可接触+资源受限”的组合，构成了TinyML安全威胁的独特底色。
1.2 学习目标：完成本课程后你将具备的能力
本课程的目标不是培养理论安全研究员，而是培养能够在一线嵌入式开发环境中执行有效安全测试的工程师。完成全部30章学习后，你将具备以下核心能力：
| 能力维度 | 具体能力描述 | 对应章节范围 |
|---|---|---|
| 固件安全测试 | 能够对固件进行静态分析、动态调试、加密存储验证、启动链完整性检查 | 第2-8章 |
| 模型安全测试 | 能够识别模型窃取风险、执行对抗样本测试、验证模型鲁棒性、检测后门 | 第9-15章 |
| 通信链路测试 | 能够对BLE/WiFi/LoRa等协议进行抓包分析、中间人测试、重放攻击验证 | 第16-22章 |
| 物理侧信道测试 | 能够执行功耗分析、故障注入、电磁辐射测量等高级测试 | 第23-26章 |
| 综合安全评估 | 能够制定安全测试计划、编写测试报告、提出修复建议、建立持续安全流程 | 第27-30章 |
除了技术能力，本课程还强调安全思维方式的建立。你将学会从攻击者的视角审视自己的设备，理解“安全测试不是找漏洞，而是验证防护措施是否有效”这一核心理念。每个测试项都对应一个明确的威胁场景，每个测试结果都应有明确的处置建议。
1.3 课程结构：从威胁到测试再到防护的完整路径
本课程共30章，按照“威胁认知→测试方法→防护加固→综合实践”的逻辑组织。前三章建立安全测试的思维框架和测试环境；第4-8章聚焦固件层面的安全测试，包括固件提取、逆向分析、加密验证、调试接口检查等；第9-15章深入模型安全，涵盖模型窃取防护、对抗样本生成与防御、模型水印、后门检测等前沿话题；第16-22章转向通信链路，覆盖主流无线协议的安全测试方法；第23-26章探讨物理侧信道攻击与防护，这是TinyML领域最独特也最容易被忽视的部分；最后四章整合所有知识，教授如何制定完整的安全测试计划、编写专业测试报告，并建立持续的安全测试流程。
每一章都遵循统一的教学结构：首先阐述核心原理，让读者理解“为什么需要这样测试”；然后给出具体的操作流程或判断方法，确保可落地执行；接着通过真实案例拆解展示测试过程中的关键决策点和常见陷阱；最后总结常见误区，帮助读者避免重复犯错。这种结构设计确保学员既能理解安全测试的“道”，也能掌握具体的“术”。
1.4 安全测试在TinyML生命周期中的位置：不是终点，而是贯穿始终的线索
许多团队将安全测试视为产品开发完成后的“最后一道工序”，这是一个根本性的误解。在TinyML领域，安全测试必须前置并贯穿整个生命周期。在数据采集阶段，就需要考虑数据是否可能被污染（投毒攻击的源头）；在模型训练阶段，需要验证模型是否对对抗样本鲁棒；在模型压缩阶段，量化操作可能引入新的安全漏洞；在固件集成阶段，需要确保模型权重被安全存储；在设备部署阶段，需要验证物理防护措施是否有效；在运行推理阶段，需要持续监控异常行为。
以模型压缩为例，这是TinyML特有的环节。将32位浮点模型量化为8位整数，不仅会损失精度，还可能改变模型对对抗样本的鲁棒性。某些在浮点模型上有效的对抗样本防御技术，在量化后可能完全失效。如果安全测试只在最终阶段进行，这类问题将极难定位——因为问题出在压缩环节，而非模型本身。因此，安全测试的每个环节都应与开发流程的对应阶段紧密结合。
1.5 案例拆解：一个智能农业节点的安全测试启示
让我们通过一个具体案例来理解安全测试在生命周期中的位置。某农业科技公司开发了一款土壤传感器节点，基于ESP32-S3芯片，运行TensorFlow Lite Micro模型，用于预测土壤湿度并自动控制灌溉。设备通过LoRa通信将数据发送到网关，电池供电，设计寿命3年。
在初始设计中，安全测试被安排在最后阶段。当产品原型完成后，安全团队开始测试，发现了以下问题：
- 固件提取：通过UART串口即可进入AT命令模式，获取完整固件镜像，其中包含模型权重和网络凭据。
- 模型窃取：固件中的模型权重未加密，攻击者可直接提取并复制到自己的设备上。
- 通信重放：LoRa数据包无时间戳和序列号，攻击者可以录制并重放“灌溉指令”，导致水资源浪费。
- 调试接口：JTAG接口未锁定，攻击者可通过调试接口直接读取Flash内容。
这些问题导致产品延期3个月，额外增加了约15万美元的修复成本。如果安全测试提前到设计阶段，大部分问题可以在硬件设计评审时就被发现。例如，JTAG接口锁定应该在PCB设计时就规划；固件加密存储需要在芯片选型时就考虑是否支持硬件加密引擎；通信协议的时间戳和序列号应该在协议设计时加入。
这个案例的复盘经验是：安全测试的“左移”（Shift-Left）至关重要。将安全测试活动从开发后期前移到需求分析、架构设计、编码实现等早期阶段，可以显著降低修复成本。具体做法包括：在设计评审中加入安全评审环节；在编码阶段使用静态分析工具扫描固件代码；在模型训练阶段就进行对抗样本鲁棒性测试；在通信协议设计时进行威胁建模。
1.6 常见误区与总结
在TinyML安全测试实践中，存在几个普遍误区，需要在本课程开始时就予以澄清：
- 误区一：设备太小，攻击者看不上。事实是，TinyML设备往往控制着物理世界的执行器（阀门、门锁、开关），攻击者不需要窃取数据，只需操纵设备行为就能造成物理破坏。
- 误区二：安全测试就是漏洞扫描。TinyML设备没有操作系统，无法运行传统的漏洞扫描工具。安全测试需要针对嵌入式环境的定制方法，包括硬件调试、协议分析、侧信道测量等。
- 误区三：加密就能解决所有问题。加密是必要的，但远非充分。密钥管理、侧信道泄露、协议设计缺陷等问题，即使有加密也可能被绕过。
- 误区四：安全测试是安全团队的事。在TinyML项目中，安全测试需要嵌入式工程师、ML工程师、硬件工程师的深度参与。安全团队可能不了解模型压缩的细节，而ML工程师可能不了解硬件调试接口。