1. 课程导入：学习目标、核心概念、整体框架——为什么TinyML模型需要完整性检查
TinyML（微型机器学习）正在将人工智能从云端数据中心推向微控制器（MCU）、传感器节点和边缘设备。一个典型的TinyML模型可能只有几十KB到几百KB，运行在仅有几十KB RAM的Cortex-M系列芯片上。然而，正是这种“小而关键”的特性，使得模型文件的完整性变得异常脆弱——一次固件升级中断、一次Flash写入错误、一次OTA传输丢包，都可能导致模型权重错乱、推理结果完全失控。本章作为整个课程的开篇，将系统性地回答三个问题：我们为什么要检查TinyML模型的完整性？完整性检查的核心概念是什么？本课程将如何组织这些知识？
上图展示了本课程的核心知识框架：左侧是TinyML模型可能面临的各类威胁源，中间是完整性检查的核心机制（哈希校验与运行前验证），右侧是这些机制最终要达成的保障目标。理解这个框架，是掌握后续所有技术细节的基础。
1.1 学习目标：学完本章后你将具备的能力
本课程不是单纯的理论讲解，而是以工程实践为导向。完成本章学习后，你应该能够：
- 识别完整性风险：能够列举至少5种导致TinyML模型文件损坏或篡改的典型场景，并评估其发生的概率和影响程度。
- 理解校验原理：掌握哈希函数（SHA-256、CRC32）和消息认证码（HMAC）的基本工作原理，明确它们在完整性校验中的不同角色。
- 设计验证流程：能够为典型的TinyML部署流程（OTA升级、本地烧录、运行时加载）设计合理的完整性检查方案。
- 权衡性能开销：了解不同校验算法在MCU上的计算开销、Flash占用和RAM消耗，能够根据硬件资源做出合理选择。
- 实施防御措施：掌握在启动加载器（Bootloader）、RTOS启动任务或应用层进行运行前验证的具体编程方法。
核心认知：TinyML模型的完整性检查不是“可选项”，而是“必选项”。在资源受限的MCU上，一个未经验证的模型可能导致设备行为异常、安全漏洞甚至物理事故（如工业控制中的错误输出）。
1.2 核心概念：什么是模型完整性？为什么它如此重要？
模型完整性（Model Integrity）指的是模型文件从生成、传输、存储到加载执行的整个生命周期中，其内容保持原始、未被篡改、未发生意外变化的状态。对于TinyML而言，完整性包含三个层面：
| 层面 | 定义 | 破坏后果 | 典型场景 |
|---|---|---|---|
| 数据完整性 | 模型权重、偏置、量化参数等二进制数据与原始版本完全一致 | 推理输出错误、精度下降、模型完全失效 | Flash写入时掉电、OTA传输丢包 |
| 结构完整性 | 模型文件的格式、层级结构、算子顺序未被破坏 | 解析失败、运行时崩溃、内存越界 | 文件截断、版本不匹配、工具链转换错误 |
| 语义完整性 | 模型的行为逻辑、决策边界与设计意图一致 | 模型被“投毒”后输出恶意结果、安全功能失效 | 恶意篡改、中间人攻击、固件逆向修改 |
在传统云端AI系统中，模型通常存储在受控的服务器上，有完善的安全防护。但在TinyML场景中，模型文件暴露在物理设备上，攻击者可以直接读取Flash、监听通信总线、甚至通过电压故障注入（Glitch Attack）来篡改模型。更常见的是，OTA升级过程中的网络不稳定、开发者的误操作、Flash的磨损老化，都会导致模型文件悄然损坏。
以一个实际案例来说明：某智能家居设备使用TinyML进行语音关键词识别（KWS），模型大小约80KB。在一次OTA升级中，由于Wi-Fi信号不稳定，模型文件在传输过程中丢失了3个字节。设备重启后，模型加载时未做任何校验，直接进入推理状态。结果，模型对“关灯”指令的识别准确率从95%骤降至12%，且对“开灯”指令产生了误触发。用户投诉不断，最终不得不召回设备。如果当时在固件中加入了简单的CRC32校验，这个问题在启动时就能被捕获并触发回滚机制。
1.3 整体框架：本课程的知识结构与学习路径
本课程共30章，按照“原理→方法→实践→进阶”的逻辑组织，分为五个模块：
- 基础模块（第1-5章）：完整性检查的必要性、哈希算法原理、校验码设计、TinyML模型文件格式解析、开发环境搭建。
- 方法模块（第6-12章）：CRC系列算法在MCU上的实现与优化、SHA-256的硬件加速与软件实现、HMAC与密钥管理、数字签名与证书链。
- 实践模块（第13-20章）：启动加载器中的校验流程设计、OTA升级的断点续传与校验策略、运行时动态加载验证、多模型场景下的批量校验。
- 进阶模块（第21-26章）：抗物理攻击的完整性保护（安全元素SE、TrustZone）、模型加密与混淆、基于机器学习的异常检测、故障注入与容错设计。
- 综合模块（第27-30章）：完整项目实战（智能门锁、工业振动监测、可穿戴健康设备）、性能基准测试、安全评估方法论、课程总结与前沿展望。
本章作为第1章，重点在于建立“为什么需要完整性检查”的认知基础。后续章节将逐步深入技术细节。建议学习者按照顺序学习，因为每个章节都会引用前面章节的概念和方法。
1.4 常见误区与学习建议
在开始深入学习之前，先澄清几个常见的认知误区：
误区一：“我的模型很小，不会出问题。” 实际上，模型越小，单个字节的损坏对整体行为的影响可能越显著。一个8位量化模型，一个权重位的翻转就可能导致输出完全错误。
误区二：“完整性检查会拖慢启动速度。” 确实，对几百KB的模型计算SHA-256在低主频MCU上可能需要几百毫秒。但通过合理的算法选择（如CRC32）、硬件加速（如Cortex-M33的SHA扩展指令）或分块校验，可以将开销控制在可接受范围内。本课程第7章将专门讨论性能优化。
误区三：“只要用了哈希校验就安全了。” 哈希校验只能检测“意外损坏”，无法防止“恶意篡改”。攻击者可以同时修改模型内容和哈希值。要抵御恶意篡改，必须使用HMAC（带密钥）或数字签名。本课程第9-10章将详细讲解。
为了帮助你更好地学习，建议准备一块常见的TinyML开发板（如STM32F746G-DISCO、ESP32-S3或Raspberry Pi Pico），并安装好Zephyr RTOS或FreeRTOS环境。本课程中的代码示例将主要基于STM32和ESP32平台，但原理和方法具有通用性。
最后，请记住一个关键原则：完整性检查不是一次性动作，而是一个持续的过程。从模型生成、编译、打包、传输、存储到加载，每个环节都需要有相应的校验措施。本课程将帮助你构建一个覆盖全生命周期的完整性保障体系。