4. 密码学基础
TinyML设备的OTA安全升级，本质上是一场关于“信任”与“完整性”的博弈。设备端算力有限、存储空间小、电池供电，无法像云端服务器那样运行重量级安全协议。因此，理解密码学基础是构建安全OTA体系的先决条件。本章将围绕六组核心概念展开：对称加密、非对称加密、哈希函数、数字签名、数字证书以及PKI体系，并结合TinyML场景说明它们如何协同工作，确保升级包在传输和安装过程中的机密性、完整性与可认证性。
4.1 核心原理：从加密到信任链的层层递进
在TinyML OTA场景中，密码学工具不是孤立使用的，而是形成一条完整的信任链。首先，对称加密（如AES-128）负责对升级包本体进行加密，因为MCU（微控制器）的算力有限，AES的硬件加速器在多数Cortex-M系列芯片上都有集成，加解密速度快、功耗低。但对称加密的痛点在于密钥分发——如果云端和设备端共享同一把密钥，那么密钥在传输过程中一旦泄露，整个体系就会崩溃。
此时引入非对称加密（如ECC-256椭圆曲线加密）。设备出厂时预置一对密钥：公钥公开，私钥私密保存。云端使用设备的公钥加密一个临时生成的对称密钥（会话密钥），设备用私钥解密得到该密钥，再用它解密升级包。这种“混合加密”模式既解决了密钥分发问题，又避免了对大数据块进行非对称加密带来的性能开销。
然而，加密只能保证机密性，无法防止攻击者篡改升级包。这时需要哈希函数（如SHA-256）计算升级包的摘要值，任何一位比特的变化都会导致摘要完全不同。但哈希本身不提供认证——攻击者可以同时替换升级包和哈希值。因此，必须使用数字签名：云端用私钥对哈希值进行签名，设备用预置的公钥验签。只有签名验证通过，设备才认为升级包确实来自可信的云端，且内容未被篡改。
最后，数字证书与PKI解决的是“公钥本身是否可信”的问题。设备出厂时预置的根证书（CA证书）是信任锚点，云端升级服务器持有由该CA签发的证书。设备在验签前，先验证云端证书的合法性，再提取证书中的公钥进行签名验证。这样即使攻击者伪造了一个公钥，也无法通过证书链的校验。
4.2 判断方法与操作流程：在资源受限设备上的选型与实施
在TinyML设备上实施密码学方案，不能照搬PC或服务器的做法。以下是关键判断维度和操作流程：
| 密码学组件 | 推荐算法 | MCU资源消耗 | OTA中的角色 |
|---|---|---|---|
| 对称加密 | AES-128-CTR / GCM | 低（硬件加速） | 加密升级包内容 |
| 非对称加密 | ECC-256（secp256r1） | 中（软件实现较慢） | 加密会话密钥、签名验证 |
| 哈希函数 | SHA-256 | 低（硬件加速） | 完整性校验 |
| 数字签名 | ECDSA-P256 | 中（验签约需数百ms） | 来源认证 |
| 证书与PKI | X.509 v3（精简） | 存储开销约1-2KB | 公钥信任链验证 |
操作流程建议：
- 密钥预置阶段：设备出厂时，在安全元件（如ATECC608A）或MCU的OTP（一次性可编程）区域写入CA根证书和设备的唯一私钥。私钥永不出安全边界。
- 升级包生成阶段：云端生成随机AES密钥，加密固件；用云端私钥对固件哈希值签名；将加密固件、签名、证书链打包。
- 设备验证阶段：设备先验证云端证书链（根证书→中间证书→服务器证书），再提取公钥验签，最后用AES密钥解密固件。
- 回滚保护：在固件头中增加版本号字段，设备在验签通过后检查版本号是否大于当前版本，否则拒绝安装。
4.3 案例拆解：智能电表OTA升级中的密码学实践
某电力公司部署了10万只智能电表，采用TinyML进行用电负荷预测。电表使用STM32L4系列MCU（内置AES硬件加速，无独立安全芯片）。OTA升级频率为每季度一次，每次固件大小约512KB。初始方案仅使用AES-128-CBC加密，密钥硬编码在固件中。在一次安全审计中发现，攻击者通过逆向固件提取了密钥，可以伪造升级包植入恶意代码。
改进方案：
- 引入ECC-256混合加密：云端每次升级时生成随机AES密钥，用设备的ECC公钥加密该密钥，设备用私钥解密得到AES密钥。
- 增加ECDSA签名：云端对固件哈希值进行签名，设备验签后再解密。验签公钥预置在OTP区域，不可修改。
- 版本号防回滚：固件头增加4字节版本号，设备在验签后比较版本号，拒绝旧版本。
实施结果：升级包大小增加约1.2KB（证书+签名），单次升级时间从原来的8秒增加到11秒（验签耗时约2.5秒），但安全性显著提升。后续在一次攻防演练中，攻击者尝试伪造升级包，但无法通过ECDSA验签，攻击失败。
代价与风险：ECC私钥存储在MCU的Flash中，如果攻击者通过JTAG接口读取Flash，仍可能泄露私钥。因此，建议后续产品增加安全元件或使用MCU的TrustZone功能保护密钥区域。
4.4 常见误区与总结复盘
误区一：认为加密等于安全。加密只解决机密性，不解决完整性和认证。攻击者可以替换密文导致解密失败或产生错误数据，因此必须配合签名和哈希。
误区二：在MCU上使用RSA-2048。RSA-2048验签需要约50ms（硬件加速）到数秒（软件实现），且密钥长度长，占用存储。ECC-256在相同安全强度下密钥更短、计算更快，更适合TinyML设备。
误区三：忽略回滚保护。即使签名验证通过，攻击者仍可能重放旧版本的固件（该固件可能存在已知漏洞）。版本号检查是OTA安全中不可或缺的一环。
误区四：证书链验证不完整。有些实现只验证服务器证书的签名，而不检查证书是否过期或被吊销。在资源受限设备上，至少应验证证书有效期和根证书签名。