1. OTA 概述与安全挑战
大家好，我是老赵。在嵌入式安全这个行当摸爬滚打了十几年，今天咱们来聊聊 OTA 升级里最核心、也最容易被忽视的一环——设备身份认证。
先问个问题：你手头的设备，凭什么相信云端下发的固件是官方的？反过来，云端又凭什么相信请求升级的设备不是冒牌货？
嗯，这就是设备身份认证要解决的事。在深入细节之前，咱们先把 OTA 的基本流程和安全威胁理清楚。
1.1 OTA 升级的基本流程
OTA 升级，说白了就是设备通过网络把新固件拉下来，然后自己把自己刷了。我习惯把整个过程拆成四个阶段：
- 触发阶段：云端推送升级通知，或者设备主动轮询检查更新。
- 下载阶段：设备通过 HTTPS 或私有协议，从服务器拉取固件包。
- 校验阶段：设备对固件做完整性校验和签名验证。
- 安装阶段：把固件写入存储分区，然后重启生效。
你想想看，这四个阶段里，哪个环节最容易出问题？
核心观点：OTA 不是简单的“下载+刷写”，而是一条信任链。从触发到安装，每一步都必须验证“你是谁”和“你给的东西对不对”。
我曾经在一个智能家居项目里遇到过，设备下载完固件后直接跳过了签名校验。结果呢？生产线上有一批设备刷了测试版的固件，导致用户家里半夜自动重启。嗯，从那以后，我再也不敢在校验阶段偷懒了。
1.2 OTA 面临的安全威胁
OTA 升级暴露在公网上，攻击面比本地升级大得多。我个人总结，主要有三类威胁：
1.2.1 固件窃取
攻击者通过抓包或破解下载链接，直接拿到固件镜像。固件里往往藏着密钥、算法、甚至业务逻辑。我见过一个案例，某厂商的固件下载链接只是简单的 /firmware/v1.2.3.bin，攻击者遍历版本号就把所有历史固件全扒走了。
1.2.2 中间人攻击
攻击者在设备和服务器之间拦截通信，篡改固件内容。即使用了 HTTPS，如果证书校验不严格，或者设备时间不准导致证书过期，中间人照样能得手。我记得有个车载 OTA 项目，设备用的根证书是 10 年前预置的，中间人伪造一个假证书就能骗过设备。
1.2.3 重放攻击
攻击者截获一次合法的升级请求，然后反复重放。比如你升级到 2.0 版本，攻击者把 1.0 版本的固件包反复推送给设备，导致设备回滚到有漏洞的旧版本。这就是典型的“回滚攻击”。
| 威胁类型 | 攻击目标 | 典型后果 |
|---|---|---|
| 固件窃取 | 固件镜像 | 泄露密钥、逆向工程、克隆设备 |
| 中间人攻击 | 通信链路 | 植入恶意固件、控制设备 |
| 重放攻击 | 升级请求/固件包 | 回滚到有漏洞版本、拒绝服务 |
避坑指南：我曾经在一个项目中，只做了固件完整性校验（哈希校验），没做签名验证。结果攻击者通过中间人攻击替换了固件，同时重新计算了哈希值。设备校验通过，刷入了恶意固件。记住：完整性校验防的是传输错误，签名验证防的才是恶意篡改。
1.3 设备身份认证的核心价值
说了这么多威胁，那设备身份认证到底能解决什么问题？
说白了，身份认证就是给每个设备发一张“身份证”。这张身份证是硬件绑定的，不可克隆，不可篡改。有了它，OTA 升级才能建立双向信任：
- 设备认证服务器：只有持有合法证书的设备，才允许下载固件。这能防止固件被批量窃取。
- 服务器认证设备：固件包用服务器的私钥签名，设备用预置的公钥验签。这能防止中间人篡改。
- 防重放：在升级请求中加入随机数或时间戳，服务器验证通过后才下发固件。这能防止攻击者重放旧请求。
我习惯把身份认证比作“锁和钥匙”。设备是锁，服务器是钥匙。只有匹配的钥匙才能打开锁，拿到固件。反过来，服务器也是锁，设备是钥匙。只有合法的设备才能触发升级流程。
个人经验：在物联网项目中，我建议优先使用基于硬件的安全元件（如 TPM、SE）来存储私钥。纯软件方案虽然成本低，但私钥容易被提取。你想想看，如果私钥被读出来了，那身份认证就形同虚设了。
下面这张图，是我自己总结的 OTA 安全架构。它把身份认证放在最底层，作为所有安全措施的基础。
从这张图你能看到，身份认证不是孤立的一层。它向下依赖硬件安全能力，向上为传输层和校验层提供信任基础。没有身份认证，TLS 证书可能被伪造，签名密钥可能被窃取，整个 OTA 安全体系就是空中楼阁。