随着智能硬件的加速普及，日益丰富和复杂的产品功能诉求为OTA固件升级带来前所未有的强需求，智能硬件厂商需要定期或不定期为硬件设备提供固件更新以增加新的功能、完善现有功能或是修复新出现的安全问题，这对OTA固件升级的流量通道、稳定性、安全性提出了新的要求。

智能硬件设备对OTA固件升级三大需求

如同互联网时代的敏捷迭代，AIoT时代下的智能硬件要想竞速生存，同样需要渐进式部署。因此，快速上线产品抢占先机而后通过OTA固件升级不断增补完善是大多数智能硬件厂商的常规做法。其二，有些智能设备需要针对不同区域的用户进行特定的方案下发，这就需要通过OTA来实现设备的多样化部署。其三，OTA固件升级是智能设备修复新发漏洞提升设备底层安全性的重要手段之一，之前见诸于媒体的也不乏因设备漏洞被不法分子劫持而沦为播放违禁内容终端的案例，轻则损伤品牌和收益，重则勒令停业整改。

然而，在通用的OTA固件升级策略中，存在一定的风险。如果服务端在未经验证的情况下，直接将固件升级包下发给设备端，那么就很容易造成如升级包被窃取、破坏、篡改等一系列安全问题，一旦固件升级过程被攻破，轻则升级失败、设备变砖，重则私密数据泄露、设备被劫持等。本篇将重点阐述更安全的OTA固件升级方案的构建原理及应用。

固件升级安全风险有几何？

在固件升级过程中，可能面临的安全风险主要有如下五类：

(1) 明文传输固件升级包，攻击者可直接获取到升级包并分析固件内容；

(2) 固件升级包没有完整性保护，设备端获取到的升级包可能被破坏或篡改；

(3) 固件升级包没有服务端签名授权，设备端无法验证升级包的来源；

(4) 服务端没有区分不同的设备端，不能针对特定设备进行授权升级；

(5) 没有服务端、设备端的互相验证，攻击者在升级过程中进行重放攻击、伪造身份攻击等。

烧录唯一设备证书，一机一密更安全

针对上述五类风险，各厂商常使用对称加密、非对称加密、数字签名、数字证书等方法来保护固件升级的过程。常见的做法是使用对称加密算法加密固件升级包，使用非对称加密算法保护加密密钥，使用数字签名、数字证书验证升级包的来源。

需要重点关注的是，在证书的使用方式上，有一型一密、一机一密等不同的方案，其中一机一密方案预先为每一个设备端烧录唯一的设备证书，当设备端与服务端通信时，服务端和设备端能够进行双向验证，验证通过后，设备端与服务端才进行正常的数据传输，并能够针对每个设备生成带有设备指纹的升级包，实现更细粒度的设备升级安全管理和校验。相比于其他方案，一机一密能够做到针对每个设备的单独验证与授权，具有更高的安全性。

将此一机一密方案与证书、升级包的管理相结合，就形成了一套更加安全的OTA固件升级方案，百度安全OTA升级方案便是基于这样的策略构建，该方案的整体架构如下图所示，主要包括三部分：证书部署（图中蓝色部分）、升级包打包（图中灰色部分）、固件升级校验（图中橙色部分）。

（基于一机一密认证的百度安全OTA升级方案结构简图）

a) 证书部署

一机一密方案依赖设备中烧录的唯一证书，证书部署模块所做的工作就是在设备出厂前，通过百度的证书管理服务将一机一密的设备端证书烧录到设备中。设备端证书储存在设备安全存储或efuse中，仅可在安全执行环境下访问以保证其完整性与私密性。

b) 升级包打包

升级包打包模块需要重点关注两个过程：

当厂商提供新的固件升级包时，服务端签名固件升级包，并对升级包进行加密保护生成“基础安全升级包”；

当设备端请求升级时，服务端使用当前设备端的设备私钥对“基础安全升级包”信息进行签名，形成安全升级包。

c) 固件升级校验

在固件升级之前，设备端和服务端首先互相验证对方证书是否合法、有效，然后在双方验证均通过后，建立安全通信连接，启动正式的固件升级流程。整个固件升级校验流程可分为6步：

(1) 设备端生成包括设备信息、设备指纹信息的升级请求信息，发送到服务端。

(2) 服务端收到升级请求信息后，首先验证信息是否可信，确认升级请求来源于可信设备；然后对设备信息和设备指纹信息进行验证。

(3) 升级请求信息验证通过后，服务端根据设备信息获得安全升级包；接下来使用设备端对应的公钥对安全升级包关键信息进行加密保护；最后，对升级包信息进行摘要签名，通过安全通信连接发送给设备端。

(4) 设备端收到升级包信息后，首先确认升级包信息来自于服务端；然后使用私钥解密升级包关键信息；最后校验升级包信息的有效性确保是本设备的升级请求的响应，并且未遭受重放、劫持、伪造等攻击。

(5) 升级包信息验证通过后，设备端根据升级包信息下载安全升级包；在获得安全升级包后，设备端进行完整性和签名校验；然后根据升级包信息解密安全升级包；最后验证解密后升级包签名，确认升级包是由客户生成的。

(6) 在安全升级包验证通过后，设备端获得原始升级包，并执行固件升级。

基于一机一密的安全OTA升级方案在攻击场景中的应用

示例场景1：窃取固件升级包

案例描述：攻击者使用伪造的设备端与服务端进行通信，如果服务端未能识别出伪造的设备端，攻击者就能通过伪造的设备端窃取固件升级包。当服务端与设备端的通信数据是明文传输时，攻击者甚至无需伪造出相对完整的设备端，仅凭抓包即可窃取固件升级包。攻击者获取到固件升级包后，可针对升级包进行解包分析，获取固件中存储的私密信息，泄露厂商的知识产权，或者对固件进行漏洞挖掘，发现固件中的安全漏洞，增加设备的攻击面。

应对方案：百度安全OTA升级方案可以在服务端正式升级流程之前，验证设备端证书是否合法并在有效期内，伪造的设备端无法通过这个验证过程。而在数据通信过程中，百度安全OTA升级方案全程使用了HTTPS，无明文数据传输，攻击者无法抓取明文通信数据。

示例场景2：替换/篡改固件升级包

案例描述：攻击者拦截服务端和设备端的通讯过程，在设备端下载升级包时，替换/篡改升级包。当设备端使用恶意替换/篡改后的固件升级包进行更新时，如若设备没有在升级中进行严格的校验，则存在升级失败甚至设备变砖的风险。一些更有“经验”的攻击者，能够对升级包进行更加精准的“破坏”，例如替换升级包中的软件、数据等。当设备使用这样的升级包进行固件升级时，将会在设备中安装攻击者的恶意程序，造成设备被破坏、泄露用户隐私、用于发起攻击等后果。

另外，如果攻击者获悉某个版本的固件中包含已知安全漏洞，并通过替换升级包等方式强制使设备更新到此版本，攻击者就可以利用针对这些已知漏洞的工具发起攻击，进而执行窃取设备私密数据、安装恶意程序等操作。

应对方案：百度安全OTA升级方案中,会在“步骤(5)”中首先验证安全升级包的签名，在确保密钥不泄露的情况下，攻击者无法伪造签名，替换/篡改后的升级包也就无法通过此项验证；即使攻击者成功获取某一设备的密钥，该密钥签名的升级包也无法在其他设备上通过“步骤(5)”中基于一机一密的升级包归属验证。

百度安全OTA三大优势

百度安全OTA依托百度安全20年互联网安全实践和技术积淀，具备三大优势，其一，在安全方面具备一键即时回滚（独家）、一机一密、DNS防护、双向认证、通信加密、安全加固（专利）、OpenRASP（专利）等技术能力优势，可以从云管端全方位建立安全防线。其二，具备高并发、断点续传、升级追踪等特性，升级成功率可达99%以上，升级速度达100万台/小时，稳定可靠；其三，任务管理简单易用，操作门槛低，下发条件灵活配置，数据分析详尽，支持多种格式资源更新，可大大节省企业接入及管理成本。百度安全OTA面向智能家居、智能驾驶、智能可穿戴、工业物联网等领域赋能，已为小度音箱、百度车联网、美的、国美、海康威视等多家国内知名厂商或产品提供百度安全OTA服务。此外，百度安全OTA的海外节点遍布全球七大洲176个国家地区，可为智能硬件厂商提供稳定的“出海”服务，目前已为多家海外市场需求的企业提供服务支持。 

长期以来，百度安全以技术开源、专利共享、标准驱动为理念，联合行业生态伙伴，共同推动AI时代的安全生态建设。作为开放战略的重要组成部分，百度安全推出百度安全扶持计划，从技术、服务、合规性三个层面免费提供面向初创型智能硬件厂商、中小App开发者、有线上资产的中小企业三类企业用户的安全防护资源。其中智能硬件“安全+”扶持计划，致力于帮助初创型智能硬件厂商降低OTA和安全建设成本，入驻该计划的企业可免费享有20000台设备OTA额度、安全评估和咨询服务，以及针对设备应用风险防御的百度安全加固服务，总价值约100000元。

点击详细了解百度安全OTA扶持计划