4、密码学基础：对称加密、非对称加密、哈希函数、数字签名、证书体系在OTA中的应用

OTA（Over-the-Air）升级的本质是将新的固件镜像从云端安全地传输到边缘设备，并确保其完整性、真实性和机密性。任何一环的缺失都可能导致设备被植入恶意固件、固件被篡改或敏感数据泄露。密码学为OTA安全提供了核心的数学工具，本章将系统梳理对称加密、非对称加密、哈希函数、数字签名与证书体系在OTA链路中的具体角色与协同方式，帮助您建立从密码原语到工程落地的完整认知。

4.1 对称加密：高效保障传输机密性

核心原理

对称加密使用同一个密钥进行加密和解密，其数学基础是置换、代换、异或等操作的多次迭代。在OTA场景中，最常用的对称算法是AES（Advanced Encryption Standard），特别是AES-128-GCM模式。GCM（Galois/Counter Mode）在CTR计数器模式基础上增加了GHASH认证，能够同时提供机密性和完整性校验，且支持硬件加速，非常适合嵌入式设备。

对称加密的核心优势在于计算效率高——AES-128在ARM Cortex-M4上以硬件加速方式运行时，吞吐量可达数百Mbps，远快于非对称加密。但其致命弱点是密钥分发问题：如果直接使用预共享密钥（PSK），一旦某台设备被逆向提取密钥，整个产品线的固件加密都将失效。

在OTA中的具体应用

• 固件包加密：使用会话密钥（Session Key）对固件镜像进行AES-GCM加密，确保固件在HTTPS/TLS通道之外再增加一层应用层加密保护。
• TLS/HTTPS通道加密：OTA下载通常走HTTPS，TLS握手完成后，实际数据传输使用对称加密（如TLS 1.3中的AES-128-GCM），保护固件在传输途中不被窃听。
• 安全存储：设备本地缓存固件时，使用设备唯一密钥（Device Unique Key）加密存储，防止通过读取Flash直接获取明文固件。

案例拆解：智能门锁固件加密传输

某智能门锁厂商原先使用HTTP明文下载固件，导致攻击者在Wi-Fi网络中抓包即可获取固件并逆向分析漏洞。整改后采用以下方案：

1. 设备与云端建立TLS 1.3连接，握手阶段使用ECDHE密钥交换协商出会话密钥。
2. 固件在云端使用AES-128-GCM加密，密钥为每次升级随机生成的会话密钥，并通过TLS通道安全下发。
3. 设备端解密后，先验证GCM认证标签，再写入A/B分区。

整改后，即使攻击者截获网络流量，也只能看到密文，无法获取明文固件。实测解密耗时仅增加约120ms（对2MB固件），对用户体验无感知。

常见误区

4.2 非对称加密：解决密钥分发难题

核心原理

非对称加密使用一对数学关联的密钥：公钥（Public Key）和私钥（Private Key）。公钥可以公开分发，私钥必须严格保密。RSA基于大整数分解难题，ECC（椭圆曲线密码）基于椭圆曲线离散对数难题。在同等安全强度下，ECC密钥更短（256位ECC约等于3072位RSA），更适合资源受限的IoT设备。

在OTA中，非对称加密主要用于数字签名和TLS握手，而非直接加密固件内容——因为非对称加密速度慢（RSA-2048签名验证约需1-5ms，而AES加密1MB数据仅需微秒级），不适合大数据量加密。

在OTA中的具体应用

操作流程：固件签名与验签

# 云端签名（离线操作）
openssl dgst -sha256 -sign private_key.pem -out firmware.sig firmware.bin

# 设备端验签（在线操作）
openssl dgst -sha256 -verify public_key.pem -signature firmware.sig firmware.bin

设备端验签流程：先计算固件哈希，再用公钥解密签名得到云端计算的哈希，两者比对一致则通过。这一过程同时验证了完整性（哈希一致）和真实性（只有持有私钥的云端才能生成有效签名）。

常见误区

4.3 哈希函数：固件完整性校验的基石

核心原理

哈希函数将任意长度的数据映射为固定长度的摘要（Digest），具有三个关键特性：抗原像性（无法从哈希反推原文）、抗第二原像性（给定原文和哈希，难以找到另一个原文产生相同哈希）、抗碰撞性（难以找到两个不同原文产生相同哈希）。OTA中最常用的是SHA-256，输出256位摘要，碰撞概率极低。

哈希函数本身不提供真实性保护——攻击者可以同时替换固件和哈希值。因此哈希必须与数字签名结合使用：先哈希，再对哈希签名。

在OTA中的具体应用

• 固件完整性校验：设备下载完成后计算SHA-256，与云端下发的期望值比对，检测传输错误或恶意篡改。
• 增量升级的块校验：对于差分升级（如bsdiff），对每个补丁块计算哈希，支持断点续传和块级校验。
• 防回滚：将版本号与固件哈希绑定，设备记录“最小允许版本”的哈希，防止攻击者回滚到有漏洞的旧版本。

案例拆解：防回滚机制设计

某车载T-Box设备遭遇攻击者将固件回滚到存在远程代码执行漏洞的旧版本。修复方案：

1. 在设备安全存储区（如RPMB分区）记录min_allowed_version和对应哈希。
2. 每次升级前，设备校验新固件版本号 ≥ 最小允许版本，且哈希匹配。
3. 云端签名时，将版本号作为附加数据一并签名，防止篡改版本字段。

该方案将回滚攻击的窗口从“永久”缩短到“仅限当前版本”，且每次安全更新后更新最小允许版本。

常见误区

4.4 数字签名与证书体系：建立端到端信任链

核心原理

数字签名 = 哈希 + 非对称加密。签名者用私钥加密哈希，验证者用公钥解密并比对。但公钥本身也可能是伪造的——攻击者可以生成自己的密钥对，把公钥发给设备。因此需要证书体系（PKI）来解决“公钥属于谁”的问题。

证书（X.509）由证书颁发机构（CA）签发，包含：主体信息（设备/云端身份）、公钥、有效期、CA签名。设备出厂时预置根CA证书（Root CA），验证固件签名证书时，沿证书链逐级验证，直到信任根。

OTA中的证书链验证流程

1. 设备收到固件包附带签名证书（Code Signing Cert）和中间CA证书。
2. 设备用预置的根CA公钥验证中间CA证书的签名。
3. 用中间CA公钥验证代码签名证书的签名。
4. 检查证书有效期、吊销状态（OCSP/CRL）。
5. 提取代码签名证书中的公钥，验证固件签名。

案例拆解：证书轮换与设备兼容性

某IoT平台有10万台存量设备，预置的根CA证书将于2025年到期。直接更换根证书需要物理接触每台设备，成本极高。解决方案：

• 提前2年发布新根CA证书，通过OTA以“交叉签名”方式下发（旧根CA为新根CA签名，新根CA为旧根CA签名）。
• 设备验证新根CA时，可通过旧根CA的交叉签名建立信任。
• 设置1年过渡期，期间新旧根CA同时有效。

该方案将设备停机时间降为零，但要求设备具备足够的存储空间（约4KB）保存双证书，且证书验证逻辑需支持交叉签名。

常见误区与复盘