1. 课程导入
TinyML（微型机器学习）正在将人工智能从云端下沉到微控制器（MCU）、传感器节点和边缘设备。当模型在仅有几十KB RAM、几百KB Flash的MCU上运行时，安全存储问题变得极为特殊：没有完整的操作系统、没有标准文件系统、没有硬件虚拟化隔离，密钥、模型参数和固件分区暴露在物理可接触的环境中。本章作为整个课程的开篇，将帮助学习者建立TinyML安全存储的全局认知框架——明确我们为什么要做安全存储、要保护什么资产、面临哪些威胁、以及后续章节将沿着怎样的路径展开。
1.1 TinyML安全存储的总体目标
TinyML安全存储并非简单地在Flash上划出一块区域存放敏感数据，而是要在资源极度受限的MCU环境中，构建一套覆盖机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）和可认证性（Authenticity）的纵深防御体系。这四个目标在TinyML场景下有着独特的含义和实现约束。
机密性要求密钥、模型参数和敏感输入数据不被未授权读取。在MCU上，这意味着Flash内容需要加密存储，RAM中的临时数据需要及时擦除，调试接口需要锁定。但MCU的算力有限，全盘AES加密可能带来显著的性能开销，因此需要根据数据的重要性和访问频率设计分级加密策略。
完整性确保模型参数和固件在存储和传输过程中未被篡改。攻击者可能通过修改模型权重来实施“模型投毒”攻击，使设备在特定输入下产生错误推理结果。完整性保护通常依赖哈希校验和数字签名，但SHA-256在低主频MCU上的计算耗时不可忽视，需要权衡校验粒度和启动延迟。
可用性保证安全机制本身不会导致设备无法启动或推理失败。例如，密钥丢失会导致设备变砖，分区表损坏会导致OTA升级失败。设计时必须考虑密钥备份、恢复机制和分区冗余。
可认证性确保设备只运行经过授权的固件和模型。这涉及安全启动链（Secure Boot Chain）和模型签名验证，防止攻击者将恶意固件或篡改后的模型刷入设备。
1.2 学习路径：从基础到实战的进阶路线
本课程共30章，按照“认知→设计→实现→验证→优化”的逻辑组织。学习者需要先建立安全威胁模型，再掌握硬件安全特性，然后学习分区设计和密钥管理，最后通过案例实战将知识转化为工程能力。
| 阶段 | 章节范围 | 核心能力 | 关键产出 |
|---|---|---|---|
| 基础认知 | 第1-5章 | 理解威胁模型、MCU安全特性、密码学基础 | 安全需求分析文档 |
| 存储设计 | 第6-12章 | Flash分区规划、密钥存储方案、模型加密策略 | 分区表设计、密钥管理方案 |
| 工程实现 | 第13-20章 | 安全启动、OTA安全升级、调试接口保护 | 可运行的固件工程 |
| 验证优化 | 第21-26章 | 安全测试、渗透测试、性能优化 | 安全测试报告、优化后的代码 |
| 综合实战 | 第27-30章 | 端到端安全方案设计、行业案例复盘 | 完整的安全存储解决方案 |
学习过程中需要特别关注硬件抽象层（HAL）和板级支持包（BSP）的差异。不同MCU厂商（ST、NXP、Nordic、Espressif等）提供的安全特性各不相同：有的内置硬件加密引擎，有的提供TrustZone-M，有的仅有软件实现的加密库。课程将尽量以通用方法论为主，同时给出主流平台的适配建议。
1.3 典型应用场景与安全威胁概述
TinyML安全存储的威胁模型高度依赖应用场景。同一个安全方案在智能家居和工业控制中的优先级完全不同。以下从三个典型场景展开分析。
场景一：智能家居传感器节点
这类设备通常部署在家庭环境中，攻击者可以物理接触设备。典型设备包括智能门锁、温湿度传感器、人体存在检测模块。威胁主要来自：
- 固件提取：通过拆解Flash芯片或利用调试接口读取固件，逆向出模型参数和通信密钥。
- 模型窃取：攻击者提取训练好的模型参数，用于复制产品或进行对抗性攻击。
- 伪造设备：克隆合法设备的身份信息，接入家庭网络进行中间人攻击。
对于智能门锁，模型参数（如人脸识别权重）的泄露意味着攻击者可以构造对抗样本绕过识别；对于温湿度传感器，模型被篡改可能导致数据上报异常，影响智能家居联动逻辑。
场景二：工业预测性维护终端
工业振动传感器、电机状态监测器部署在工厂车间，环境恶劣且长期运行。安全威胁更侧重于：
- 数据投毒：攻击者通过物理干扰（如电磁注入）使传感器采集到异常数据，导致模型误判设备状态。
- 固件降级攻击：将设备固件回滚到存在漏洞的旧版本，绕过安全补丁。
- 密钥泄露：工业设备生命周期长（5-10年），密钥管理不善可能导致长期暴露。
工业场景对可用性要求极高——安全机制不能影响设备的实时推理能力。例如，振动监测需要以1kHz以上的采样率进行FFT分析，任何额外的安全校验都不能阻塞主循环。
场景三：可穿戴医疗设备
心电监测、血糖预测等设备涉及个人健康数据，受到法规（如GDPR、HIPAA）约束。威胁模型包括：
- 隐私泄露：模型输入包含敏感生理信号，RAM中的数据被侧信道攻击窃取。
- 模型篡改：攻击者修改模型参数，使设备输出错误的健康建议。
- 非授权访问：设备丢失后，攻击者尝试读取内部存储的健康数据。
医疗设备对机密性和完整性的要求远高于消费电子，且需要通过相关安全认证（如IEC 62443、ISO 13485），这对存储方案的可审计性提出了额外要求。
1.4 安全威胁的层次化分析
为了更系统地理解威胁，我们可以将攻击面分为三个层次：物理层、系统层、通信层。每个层次需要不同的防护策略。
物理层攻击直接作用于芯片和电路。除了前面提到的侧信道分析，还包括探针攻击（直接接触数据总线）、温度/电压故障注入、激光切割等。防护手段包括：使用安全封装、增加主动屏蔽层、在芯片内部集成温度/电压传感器检测异常环境。对于大多数TinyML设备，物理层防护的成本较高，通常只在高端安全芯片中实现。
系统层攻击利用软件漏洞或配置缺陷。例如，通过缓冲区溢出覆盖函数指针、利用未锁定的调试端口执行任意代码、通过DMA攻击读取加密密钥。防护手段包括：MPU（内存保护单元）配置、栈溢出检测、调试端口锁定、最小权限原则。
通信层攻击发生在设备与外部交互过程中。包括OTA升级包篡改、传感器数据伪造、时间同步攻击等。防护手段包括：TLS/DTLS加密、固件签名验证、防重放机制、时间戳校验。
| 攻击层次 | 典型攻击方式 | 攻击者能力要求 | 防护优先级 |
|---|---|---|---|
| 物理层 | 侧信道分析、故障注入、探针 | 高（需专业设备） | 中（视资产价值） |
| 系统层 | 固件逆向、缓冲区溢出、调试接口 | 中（需软件技能） | 高（最常见攻击路径） |
| 通信层 | 中间人、重放、OTA篡改 | 低（需网络接入） | 高（远程攻击入口） |
1.5 案例拆解：智能门锁的密钥泄露事件
为了将抽象威胁具体化，我们分析一个真实的智能门锁安全事件。某品牌智能门锁使用ESP32-S3作为主控，运行TinyML人脸识别模型。攻击者通过以下步骤成功提取了设备中的AES密钥：
- 固件获取：攻击者拆开门锁，使用ESP32-S3的UART0引脚进入下载模式，通过esptool.py工具读取了整个Flash镜像（4MB）。
- 静态分析：使用binwalk和Ghidra分析固件，定位到密钥存储区域。由于开发者将AES密钥以明文形式存储在Flash的0x3D0000地址处，攻击者直接提取了128位密钥。
- 模型提取：在固件中找到了TensorFlow Lite模型的权重数据，通过解析TFLite文件格式，完整恢复了人脸识别模型。
- 后续攻击：利用提取的密钥解密了设备与云端通信的会话密钥，实现了远程开锁。
这个案例暴露了三个关键问题：调试接口未锁定（允许UART下载）、密钥明文存储（未使用安全元件或加密存储）、Flash分区无访问控制（所有数据可被任意读取）。修复方案包括：
- 烧录eFuse禁用UART下载模式，仅保留经过签名的OTA升级通道。
- 将AES密钥存储在ESP32-S3的Secure Element（如果使用）或使用Flash加密功能（ESP32-S3支持Flash加密，但需要正确配置）。
- 对模型参数进行加密存储，运行时解密到RAM中执行推理。
1.6 常见误区与设计原则
在TinyML安全存储的实践中，开发者常陷入以下误区：
误区一：认为MCU上没有值得保护的数据。实际上，模型参数本身就是知识产权，密钥可以用于访问后端服务，传感器数据可能涉及隐私。即使单个设备的数据价值不高，批量攻击（如僵尸网络）可以放大威胁。
误区二：过度依赖软件加密而忽视硬件特性。许多MCU内置了硬件加密引擎、安全启动、TrustZone等特性，但开发者因为不熟悉而弃用，转而使用软件实现。这既降低了安全性，又增加了性能开销。
误区三：安全方案“一刀切”。不同应用场景的安全需求差异巨大。一个电池供电的温湿度传感器可能只需要基本的固件签名，而一个医疗设备则需要完整的密钥管理和审计日志。过度设计会浪费资源，设计不足则带来风险。
基于以上分析，我们提出TinyML安全存储的六项设计原则：
- 最小化信任边界：将安全关键操作（如密钥使用）隔离在独立的硬件安全域中。
- 纵深防御：不依赖单一安全机制，而是组合使用加密、访问控制、完整性校验。
- 默认安全：所有安全功能默认开启，而不是默认关闭。
- 可更新性：安全机制本身需要支持OTA更新，以应对新发现的漏洞。
- 性能可预测：安全操作的时间开销必须在实时性预算内。
- 可审计性：记录安全事件日志，便于事后分析和合规审查。