一、OTA 概述与安全威胁

大家好,欢迎来到《OTA 固件签名与验证实战》的第一章。

我是你们这门课的老朋友。做了十几年嵌入式安全,从早期的功能机到现在的智能汽车、IoT 设备,我经手过的 OTA 项目少说也有几十个了。今天咱们先聊聊最基础的东西——OTA 到底是什么,以及为什么我们非得给它加上签名和验证。

1.1 什么是 OTA 升级

OTA,全称 Over-the-Air,说白了就是「空中升级」。你想想看,一个设备卖出去之后,发现有个 bug,或者想加个新功能,总不能把设备都召回来吧?OTA 就是让你通过网络,直接把新固件发到设备上,完成升级。

我个人习惯把 OTA 分成两类:

  • FOTA(固件 OTA):升级整个系统固件,比如手机的系统更新、汽车 ECU 的固件刷新。
  • SOTA(软件 OTA):升级应用层软件,比如车载娱乐系统的 App 更新。

咱们这门课主要聚焦在 FOTA,因为它的安全挑战最大——你想想,要是系统固件被人动了手脚,整个设备就失控了。

我的经验: 刚入行时我总觉得 SOTA 和 FOTA 差不多,直到有一次在车厂项目里,FOTA 升级把整车的 CAN 网络搞瘫痪了……嗯,从那以后我对固件升级就格外小心。

1.2 OTA 升级流程

一个标准的 OTA 升级流程,其实就三步:打包、分发、安装。但每一步里面都有不少门道。

我画了一张流程图,帮你把整体脉络理清楚:

OTA 升级核心流程 ① 固件打包 编译 + 签名 + 加密 ② 云端分发 CDN + 版本管理 ③ 设备下载 校验 + 存储 ④ 升级安装 解压 + 验证 + 刷写 ⑤ 重启生效 回滚保护 + 日志上报 ⚠ 关键安全点 签名验证必须在步骤④ 完成,不能提前或跳过

你看,从固件打包到最终重启生效,每个环节都可能被攻击者盯上。我见过不少团队,只关注了「下载」和「安装」两个环节,却忽略了「打包」阶段的安全——结果签名密钥被泄露,整个升级体系形同虚设。

1.3 OTA 面临的安全风险

好了,流程清楚了,咱们来看看攻击者到底能干什么。我把最常见的三种威胁整理成了表格,方便你对比:

威胁类型 攻击方式 后果 常见场景
固件被篡改 中间人修改固件内容,植入恶意代码 设备被控、数据泄露、功能失效 公共 Wi-Fi 升级、不安全的下载通道
重放攻击 截获旧版本固件,反复发送给设备 设备回退到有漏洞的版本 未做版本号校验、无防回滚机制
中间人攻击 攻击者伪装成升级服务器,下发恶意固件 设备被完全控制 DNS 劫持、伪造证书、不验证服务器身份

1.3.1 固件被篡改

这是最直接的攻击。攻击者通过劫持网络流量,把固件里的代码换掉。我曾经在一个智能门锁项目里遇到过——攻击者把固件里的认证逻辑改了,结果门锁变成了「谁都能开」的状态。你说可怕不可怕?

1.3.2 重放攻击

这个有点意思。攻击者不需要改你的固件,他只需要把旧版本截获下来,反复发给设备。为什么这么做?因为旧版本可能有已知漏洞。我记得有个路由器厂商,就是因为没做防回滚,被攻击者用半年前的旧固件刷机,然后利用已知漏洞获取了 root 权限。

避坑指南: 我曾经在一个车厂项目中,发现他们的 OTA 系统只校验了签名,没校验版本号。结果攻击者把 3 年前的固件重放给车载娱乐系统,导致系统崩溃。从那以后,我坚持「签名 + 版本号 + 防回滚」三件套必须同时上。

1.3.3 中间人攻击

中间人攻击(MITM)是 OTA 升级中最隐蔽的威胁。攻击者站在你和服务器之间,你以为是跟服务器通信,其实是在跟攻击者说话。他给你下发一个「假固件」,你装上之后,设备就变成他的了。

嗯,这里要注意:很多人觉得用了 HTTPS 就安全了。但 HTTPS 只保证传输通道加密,如果攻击者伪造了证书,或者你的设备没有校验证书链,HTTPS 一样被突破。

核心观点: OTA 安全不是靠单一技术解决的。签名、加密、版本管理、证书校验,缺一不可。咱们这门课后面会一步步把这些技术拆开揉碎,让你真正掌握。