4、密码学基础：对称加密、非对称加密、哈希函数、数字签名原理与区别
TinyML固件签名机制的核心，是确保模型更新包在从云端分发到边缘设备的过程中，其完整性与来源真实性得到验证。要理解这一机制，必须先掌握四种基础密码学工具：对称加密、非对称加密、哈希函数与数字签名。它们各自解决不同的问题，又相互配合，构成固件安全更新的信任基石。本章将逐一剖析其数学原理、工程特性与适用场景，并重点厘清它们之间的本质区别。
4.1 核心原理：四种工具的本质与数学基础
对称加密是最直观的加密方式。发送方与接收方共享同一个密钥K，加密过程为 C = Enc(K, M)，解密过程为 M = Dec(K, C)。其安全性完全依赖于密钥K的保密性。AES-128/256是当前TinyML设备上最常用的对称算法，因其硬件加速指令（如ARM Cortex-M系列的AES扩展）可在极低功耗下完成加解密。对称加密的致命弱点是密钥分发问题：在固件更新场景中，如果每台设备都预置相同的密钥，一旦某台设备被物理攻击提取密钥，整个产品线的安全防线将全面崩溃。
非对称加密使用一对数学关联的密钥：公钥Pub与私钥Priv。公钥公开分发，私钥严格保密。RSA基于大整数分解难题，ECC（椭圆曲线密码）基于椭圆曲线离散对数难题。在同等安全强度下，ECC的密钥长度远短于RSA（256位ECC约等于3072位RSA），这对存储和计算资源都极其有限的MCU至关重要。非对称加密解决了密钥分发问题，但计算开销比对称加密高2-3个数量级。
哈希函数是一种单向映射：H = Hash(M)，将任意长度的消息M映射为固定长度的摘要H。其核心性质包括：抗原像性（无法从H反推M）、抗第二原像性（给定M，难以找到M'≠M使得Hash(M')=Hash(M)）、抗碰撞性（难以找到任意两个不同的输入产生相同输出）。SHA-256输出256位摘要，碰撞概率约为2^-128，在工程上可视为安全。哈希函数不提供机密性，也不提供认证性，它只保证完整性——任何一位比特的改变都会导致摘要完全变化。
数字签名并非一种独立的密码学原语，而是哈希函数与非对称加密的有机结合。签名过程为：先对消息M计算哈希H=Hash(M)，再用私钥对H进行签名运算得到Sig=Sign(Priv, H)。验证过程为：用公钥验证签名得到H'=Verify(Pub, Sig)，同时对收到的消息计算哈希H''=Hash(M')，最后比对H'与H''是否一致。数字签名同时提供了完整性验证（哈希保证）与来源认证（私钥保证），还天然具备不可否认性——只有持有私钥的一方才能产生有效签名。
4.2 判断方法与操作流程：如何为TinyML固件选择密码学方案
在实际的TinyML固件签名设计中，需要根据设备资源约束和安全等级进行权衡。以下是判断流程与操作步骤：
- 评估设备能力：检查MCU是否具备硬件加速器（如ARM CryptoCell、NXP LPC55xx的SHA-256引擎）、可用RAM/Flash空间、CPU主频。若设备仅有几十KB RAM，应避免使用RSA-2048（需要约256字节的缓冲区进行模幂运算），优先选择ECC P-256或Ed25519。
- 确定安全目标：如果仅需防止固件被篡改（完整性），使用哈希+对称MAC即可；如果需要验证固件来源（防伪造），必须使用数字签名。对于OTA更新，必须使用数字签名，因为攻击者可能伪造整个更新包。
- 选择签名算法：ECC P-256（ECDSA）是当前TinyML领域的主流选择，签名长度64字节，公钥32字节，验证时间在100MHz Cortex-M4上约需30-50ms。Ed25519更安全且实现更简单，但部分老旧MCU库支持不佳。
- 设计密钥管理：私钥存储在云端HSM（硬件安全模块）中，公钥烧录在设备一次性OTP（一次性可编程）区域或安全元件中。严禁将私钥放入固件包。
- 实施签名流程：在CI/CD流水线中，对编译好的固件二进制计算SHA-256，用私钥签名，将签名附加到固件包末尾，并添加版本号、设备ID等元数据。
| 安全需求 | 推荐工具 | 典型算法 | TinyML适用性 |
|---|---|---|---|
| 数据机密性（固件内容保密） | 对称加密 | AES-128-GCM | 需要密钥管理，MCU需支持AES指令 |
| 完整性（检测篡改） | 哈希函数 + MAC | SHA-256 + HMAC | 轻量级，适合资源受限设备 |
| 来源认证（防伪造） | 数字签名 | ECDSA P-256 / Ed25519 | 推荐用于OTA固件更新 |
| 密钥交换（安全分发会话密钥） | 非对称加密 | ECDH | 用于建立安全信道，不直接用于固件 |
4.3 案例拆解：一款温湿度传感器节点的固件签名实现
背景与约束：某智能农业项目部署了2000个基于STM32L071（Cortex-M0+，32MHz，20KB RAM）的温湿度传感器节点。这些节点通过LoRaWAN进行OTA固件升级。初始方案仅使用CRC32校验，导致攻击者可以轻易构造恶意固件包。安全团队要求在不更换硬件的前提下，实现固件来源认证与防回滚。
初始现象与目标：在一次安全测试中，研究人员通过伪造固件包成功让节点执行了恶意代码。目标是将安全等级提升至：攻击者即使截获所有通信数据，也无法伪造可被接受的固件包；同时验证时间不超过200ms，额外Flash占用不超过8KB。
关键输入数据：固件大小约64KB；MCU无硬件加密加速器；LoRaWAN数据速率限制为2KB/s；可用Flash剩余12KB；RAM剩余6KB。
分析判断过程：首先排除RSA-2048，因为模幂运算在Cortex-M0+上需要约2秒且需要大量RAM。选择ECDSA P-256，签名验证仅需约80ms（使用优化的椭圆曲线库如MicroECC）。哈希函数选择SHA-256，软件实现约需15ms处理64KB数据。签名验证总耗时约100ms，满足200ms预算。Flash占用：MicroECC约4KB + SHA-256约2KB + 签名验证逻辑约1KB，总计7KB，在12KB预算内。
实际操作步骤：
// 设备端验证伪代码（C语言风格）
uint8_t firmware_hash[32];
uint8_t received_sig[64];
uint8_t public_key[64]; // P-256公钥
// 1. 计算固件哈希
sha256_compute(firmware_ptr, firmware_size, firmware_hash);
// 2. 验证签名
int result = ecdsa_verify(public_key, firmware_hash, received_sig);
if (result == 0) {
// 签名有效，执行固件更新
flash_erase_and_write(firmware_ptr, firmware_size);
} else {
// 签名无效，拒绝更新并记录日志
log_error("Firmware signature verification failed");
}结果对比：实施后，攻击者即使截获了合法固件包，也无法修改其中任何字节（哈希校验失败），更无法伪造新固件（没有私钥）。防回滚机制通过固件包中的版本号字段实现，设备只接受版本号更高的签名固件。
风险与代价：公钥存储在OTP区域，一旦烧录无法更改，若私钥泄露需召回所有设备。验证时间100ms在OTA过程中可接受，但若未来固件增大至256KB，SHA-256计算时间将增至60ms，仍可接受。
复盘经验：在资源受限设备上，算法选择比实现优化更重要。ECC P-256是TinyML固件签名的黄金标准，兼顾安全性与性能。务必在开发早期就加入签名验证，后期改造的代价远高于初期设计。
4.4 常见误区与总结复盘
误区一：混淆加密与签名。加密保护机密性，签名保护完整性与认证性。对固件包进行AES加密并不能防止攻击者篡改，因为攻击者可以破坏密文导致解密失败，但无法构造合法密文。然而，如果攻击者重放旧版本固件，加密无法阻止，必须依赖签名中的版本号。
误区二：使用哈希函数代替签名。有些开发者将固件哈希值直接放在设备端进行比较，这只能检测意外损坏，无法防御恶意攻击。攻击者可以同时修改固件和哈希值。必须使用私钥对哈希签名，设备端用公钥验证。
误区三：忽略密钥存储安全。将公钥存储在Flash普通区域，攻击者可以篡改公钥为攻击者自己的公钥，从而用攻击者的私钥签名恶意固件。公钥必须存储在OTP、安全元件或受MPU（内存保护单元）保护的区域。
误区四：签名算法选择不当。在资源极度受限的设备上使用RSA-2048，导致验证时间过长或内存溢出。应优先选择ECC系列算法。
误区五：忽视防回滚机制。即使签名验证正确，攻击者仍可重放旧版本固件（该固件包含已知漏洞）。必须在固件包中加入单调递增的版本号，设备端拒绝版本号低于当前版本的固件。