3. 安全存储需求分析
TinyML 设备通常部署在物理暴露、计算资源受限、网络连接不稳定的边缘环境中。与云端服务器不同，攻击者可以轻易获得设备实物，通过拆解芯片、读取 Flash、监听总线等方式提取敏感信息。因此，安全存储设计的第一步不是“如何加密”，而是“要保护什么、保护到什么程度”。密钥、模型参数、模型文件这三类数据在机密性、完整性、可用性上的要求截然不同，必须分层设计，才能在不牺牲性能的前提下实现有效防护。
3.1 核心原理：数据价值与攻击成本决定安全等级
安全存储的本质是“风险与成本的平衡”。在 TinyML 场景中，密钥、模型参数、模型文件三者的价值密度和泄露后果完全不同。密钥是系统的信任根，一旦泄露，攻击者可以解密所有加密数据、伪造固件签名、绕过安全启动；模型参数是企业的核心知识产权，经过大量数据训练得到的权重一旦被复制，竞争对手可以直接复用；模型文件虽然也包含网络结构和算子信息，但通常可以从公开渠道或反汇编中获取，其敏感度相对较低。
从攻击成本角度看，提取密钥需要物理探针、聚焦离子束（FIB）等高端设备，成本高且成功率低；读取外部 Flash 中的模型参数只需要使用 SPI 协议分析仪或编程器，成本极低；而模型文件如果未加密，直接通过 UART 或 JTAG 即可导出。因此，安全设计应遵循“梯度防护”原则：将最高强度的硬件隔离用于密钥，将加密与完整性校验用于模型参数，将轻量级签名验证用于模型文件。
3.2 判断方法：如何为三类数据选择存储介质与保护策略
在实际项目中，可以通过以下四个维度来判断每类数据的保护需求：
- 泄露影响面：该数据泄露后，影响范围是单台设备、整个产品线还是公司级知识产权？密钥泄露通常影响全系列设备，模型参数泄露影响产品竞争力，模型文件泄露影响相对有限。
- 更新频率：密钥极少更新（生命周期内可能只有 1-2 次），模型参数可能随 OTA 更新（每月或每季度），模型文件更新最频繁。更新频率越高，越需要支持安全擦除和重写机制。
- 运行访问需求：密钥在启动时被 CPU 或硬件加速器读取一次，之后不再访问；模型参数在每次推理时都要被读取到 SRAM；模型文件在加载时解析一次。访问频率越高，加解密开销对性能的影响越大。
- 物理可访问性：如果设备外壳可轻易打开，且 Flash 芯片裸露，则所有数据都需要加强保护；如果设备封装严密或部署在受控环境，可以适当降低防护等级。
| 数据类别 | 典型存储介质 | 加密要求 | 完整性校验 | 访问控制 | 推荐方案 |
|---|---|---|---|---|---|
| 密钥 | eFuse / 安全元件 / TPM | 硬件级加密，不可导出 | 无需（物理防篡改） | 仅限安全启动流程 | 芯片内置 Key Locker |
| 模型参数 | 外部 SPI Flash / QSPI | AES-128/256 加密存储 | CMAC / HMAC 校验 | 仅限推理引擎读取 | 加密 + 签名 + 版本号 |
| 模型文件 | 外部 Flash / SD 卡 | 可选（明文可接受） | SHA-256 / ECDSA 签名 | OTA 更新时验证 | 签名验证 + 防回滚 |
3.3 案例拆解：智能摄像头模型被篡改后的完整分析
某智能家居摄像头厂商推出了一款基于 TinyML 的人脸识别门锁，使用 ESP32-S3 作为主控，外部 8MB QSPI Flash 存储模型文件与参数。产品上市三个月后，有用户反馈设备出现异常行为：门锁在无人时自动开锁，且无法通过 App 远程升级固件。
初步排查：工程师通过串口日志发现，设备启动时加载的模型文件校验值异常，但系统仍然继续执行了推理。进一步检查 Flash 内容，发现模型文件被替换为一个恶意版本，该版本将所有输入都映射为“匹配成功”。
根因分析：
- 模型文件以明文存储在外部 Flash 中，未做任何完整性校验；
- 固件中虽然包含签名验证代码，但仅在 OTA 更新时执行，启动加载时未验证；
- 攻击者通过 UART 接口获取了 Flash 读取权限，直接改写模型文件内容。
修复方案：
- 在模型文件头部添加 64 字节的 ECDSA 签名，启动时使用内置公钥验证签名，验证失败则拒绝加载；
- 将模型参数加密存储，密钥保存在 ESP32-S3 的 eFuse 中，使用 AES-256-GCM 模式，兼顾加密与完整性校验；
- 增加防回滚机制，在 Flash 中维护单调递增的版本计数器，禁止加载旧版本模型。
结果对比：修复后，攻击者即使物理接触 Flash，也无法伪造签名或解密参数。设备启动时间增加了约 120ms（主要是 ECDSA 验证开销），但推理性能未受影响。该案例说明，模型文件虽然敏感度较低，但完整性保护缺失会导致严重的安全事故。
3.4 常见误区与总结复盘
误区一：所有数据都加密就是安全。实际上，过度加密会带来性能损耗和密钥管理复杂度。例如，对模型文件整体加密后，每次启动都需要解密整个文件，在低主频 MCU 上可能耗时数秒。更合理的做法是：模型文件明文存储 + 签名验证，模型参数加密存储。
误区二：密钥存储在 Flash 中，通过软件混淆保护。这是最危险的做法。任何存储在 Flash 中的密钥都可以通过读取固件、反汇编或调试接口提取。密钥必须放在芯片内部的 eFuse、安全元件或 TrustZone 等硬件隔离区域。
误区三：只做加密，不做完整性校验。加密只能防止数据被读取，不能防止数据被篡改。攻击者可能通过修改密文中的某些字节，导致解密后的模型参数产生随机错误，进而使模型输出异常结果。使用 AES-GCM 或 AES-CCM 等带认证的加密模式可以同时解决机密性和完整性问题。
误区四：忽略侧信道攻击。即使密钥存储在安全硬件中，如果加解密操作的时间、功耗与密钥相关，攻击者仍可能通过功耗分析（DPA/SPA）提取密钥。在安全等级要求高的场景，应选择具有侧信道防护的硬件实现，或使用随机掩码技术。
总结：安全存储需求分析的核心是“分级防护”。密钥是信任根，必须使用硬件隔离；模型参数是知识产权，需要加密与完整性双重保护；模型文件是功能载体，以完整性验证为主。在实际设计中，应根据设备成本、攻击面、性能预算综合权衡，避免一刀切的加密策略。建议在项目初期就完成威胁建模，明确每类数据的保护等级，再选择合适的硬件平台和存储方案。