课程导入：TinyML模型保护的重要性、学习目标、课程整体框架与适用场景
TinyML（微型机器学习）正在将人工智能从云端数据中心推向数十亿个微控制器（MCU）级别的边缘设备。从智能传感器、可穿戴健康监测器到工业预测性维护节点，这些功耗仅为毫瓦级甚至微瓦级的设备，如今能够执行语音唤醒、异常检测和振动分类等复杂任务。然而，当模型从云端下沉到物理世界时，一个严峻的挑战随之浮现：模型本身成为了一种可被物理接触、读取和逆向分析的数字资产。与云端模型受限于服务端访问控制不同，TinyML模型部署在用户可触及的Flash存储器中，攻击者只需一把编程器或逻辑分析仪，就可能完整提取模型权重、网络结构乃至推理逻辑。本章作为整个课程的开篇，将系统阐述TinyML模型保护为何迫在眉睫，明确学习目标，并勾勒出从威胁建模到防护落地的完整课程框架。
上图展示了本课程的核心逻辑：左侧是TinyML设备面临的现实威胁来源，右侧是需要保护的核心资产，中间则是贯穿课程始终的防护技术体系。理解这三者之间的映射关系，是构建有效防护方案的前提。例如，Flash读取攻击直接威胁模型权重和网络结构，而侧信道分析则可能泄露推理过程中的中间值或密钥。课程将逐一剖析这些攻击路径，并给出对应的缓解措施。
1.1 TinyML模型保护的重要性：为什么不能裸奔？
在传统嵌入式开发中，固件安全往往被置于功能之后。但对于TinyML设备，模型本身就是产品价值的核心载体。一个训练良好的神经网络模型，可能耗费了团队数月的数据采集、清洗和调参工作，其商业价值甚至超过硬件本身。如果模型被轻易提取，竞争对手可以直接复制产品功能，导致市场优势瞬间瓦解。
从技术角度看，TinyML模型面临的安全风险具有鲜明的特殊性：
- 物理可及性：设备部署在用户环境中，攻击者拥有无限次的物理接触机会，可以拆解外壳、焊接探针、使用逻辑分析仪监听SPI总线。
- 资源极度受限：MCU通常只有几十KB到几MB的Flash和RAM，无法运行重量级安全算法（如全同态加密），必须在性能与安全之间寻找平衡。
- 生命周期长：工业传感器或汽车电子设备可能服役10年以上，安全防护必须考虑长期密钥管理和固件更新机制。
- 供应链复杂：模型从训练服务器到设备Flash，中间经过模型转换、编译、烧录等多个环节，每个环节都可能成为攻击注入点。
核心原理：TinyML模型保护的本质是在不可信环境中保护可信计算。设备硬件完全暴露给攻击者，但我们需要确保模型权重、推理逻辑和决策结果不被非法获取或篡改。这要求我们采用纵深防御策略——即使某一层防护被突破，后续防线仍能阻止攻击者达成最终目的。
以智能家居中的语音唤醒词检测为例。设备持续监听环境声音，本地运行一个微型神经网络来识别唤醒词。如果攻击者提取了该模型，就可以分析其决策边界，构造特定的对抗音频样本，使设备在未说唤醒词的情况下被激活，或者完全失效。更严重的是，如果模型包含用户语音特征的嵌入表示，攻击者可能借此推断用户隐私。
1.2 学习目标：学完本课程你将掌握什么？
本课程不是纯理论的安全综述，而是聚焦于TinyML工程实践中的具体防护技术。完成学习后，你应该具备以下能力：
| 能力维度 | 具体目标 | 对应章节 |
|---|---|---|
| 威胁识别 | 能够对TinyML设备进行威胁建模，识别攻击面与风险等级 | 第2-3章 |
| Flash安全 | 掌握MCU Flash读取保护机制（RDP）、安全烧录流程及绕过风险 | 第4-6章 |
| 加密技术 | 熟练使用AES-128/256对模型权重进行加解密，理解密钥管理方案 | 第7-10章 |
| 混淆对抗 | 掌握模型结构混淆、权重变换、运行时解密等高级防护手段 | 第11-15章 |
| 工程落地 | 能够在资源受限的MCU上实现安全启动、安全更新和运行时防护 | 第16-22章 |
| 安全验证 | 能够对加固后的设备进行渗透测试，评估防护有效性 | 第23-28章 |
课程特别强调动手实践。每一章都会提供基于STM32、ESP32或国产GD32等主流MCU的代码示例和实验指导。你将亲手实现一个权重加密的TinyML推理程序，并尝试从自己设计的防护方案中寻找漏洞——这种“攻击者视角”的训练将极大提升你的防护设计能力。
1.3 课程整体框架：从攻击面到防护体系的系统化路径
课程共30章，按照“认知→分析→防护→实践→验证”的逻辑递进组织为五大模块：
- 威胁建模与攻击面分析（第1-3章）：建立TinyML安全威胁全景图，深入分析Flash读取、调试接口、侧信道等攻击路径的具体实现原理。
- Flash安全与硬件防护（第4-6章）：聚焦MCU内置安全特性，包括读保护级别、安全启动、TrustZone-M技术等。
- 模型加密与密钥管理（第7-12章）：这是课程的核心技术部分，涵盖对称加密算法选型、密钥存储方案（OTP、eFuse、安全元件）、在线/离线解密推理架构。
- 模型混淆与运行时防护（第13-18章）：介绍权重矩阵变换、网络结构隐藏、代码混淆、控制流平坦化等软件防护手段，以及如何与硬件加密协同工作。
- 综合实战与安全验证（第19-30章）：通过完整的项目案例（如智能门锁、工业振动监测），将前四模块技术整合落地，并教授渗透测试方法论和防护效果评估指标。
学习建议：如果你是一名嵌入式软件工程师，建议重点学习第4-6章和第13-18章，这些内容与日常开发直接相关；如果你负责产品安全架构设计，则第1-3章和第19-22章的战略视角更为关键。但无论如何，请务必完成每一章的动手实验——安全技术只有在实践中才能真正内化。
1.4 适用场景：哪些产品最需要模型保护？
并非所有TinyML设备都需要同等强度的防护。防护等级应与模型价值、攻击成本和风险后果相匹配。以下是典型的适用场景分级：
| 风险等级 | 典型产品 | 攻击动机 | 推荐防护 |
|---|---|---|---|
| 高 | 自动驾驶感知节点、医疗诊断设备、金融支付终端 | 恶意篡改导致安全事故、窃取核心算法 | 硬件安全模块+全量加密+安全启动+运行时完整性校验 |
| 中 | 工业预测性维护、智能楼宇控制、农业物联网 | 竞争对手逆向复制、固件非法篡改 | Flash读保护+权重加密+基本混淆 |
| 低 | 消费级玩具、简单环境监测 | 极低，主要为防止随意读取 | Flash读保护或轻量级混淆 |
一个典型的案例是工业电机振动监测系统。设备厂商投入大量资源采集不同工况下的振动数据，训练出能够精准区分轴承磨损、齿轮断裂等故障类型的CNN模型。该模型部署在工厂现场的传感器节点上，竞争对手可能通过购买一台设备，拆解后提取Flash中的模型权重，从而省去数年的数据积累成本。针对这一场景，课程将演示如何利用STM32L4系列的OTP存储密钥，结合AES-256-GCM对模型文件进行加密，并设计仅解密到RAM的推理流程，确保Flash中永远不存在明文权重。
重要提醒：模型保护并非安全。任何防护措施都可以被足够资源和时间的攻击者绕过。我们的目标是提高攻击成本，使其超过模型本身的价值。在课程后续章节中，你将反复看到这种“成本-收益”权衡的思维方式。
最后，让我们明确本课程的边界：我们专注于模型权重和推理逻辑的保护，不涉及训练数据隐私（联邦学习）或模型公平性等议题。同时，课程中的技术方案主要针对MCU级别的设备，对于运行Linux系统的边缘网关（如树莓派），部分攻击路径和防护手段会有所不同，但核心的加密和混淆思想仍然适用。