速览智能设备的OTA升级

在学习OTA技术前，我们首先了解一下设备固件升级DFU（Device Firmware Update）的过程。DFU依赖于设备硬件，不同种类的设备具有不同的协议，所以升级的模式也有差异，但是从根本上看原理是相同的。以著名的Nordic系列芯片产品的DFU架构^[1]为例，DFU过程需要DFU target和DFU controller。前者即需要更新的“目标设备”，例如我们的智能手表、耳机等；后者是传输固件包并控制升级的“控制设备”，例如我们的手机app等。目标设备中的DFU过程如下：

1.目标设备进入DFU模式；

2.目标设备接收控制设备发送的init包，通过其中包含的固件类型、版本、签名等信息，预先校验固件来源是否安全受信、硬件是否兼容等；

3.目标设备预先校验通过后，开始接收控制设备发送的固件数据，并进行二次校验，即检验固件完整性；

4.后校验完成后，使用新固件覆盖老固件；

5.最后重置设备。

图1 目标设备DFU过程^[1]

其中新固件覆盖老固件主要有两种模式：single bank和dual bank。类比金融行业的银行，此处的bank可以理解成一个“存储数据的银行“，而后者dual bank相较于前者single bank则多了一个“数据银行”，即一块逻辑上的存储单元。具体解释如下：

single bank模式是指在升级时，系统进入bootloader，擦除原固件内容，将新固件覆盖原固件的位置。如果升级过程中出现问题，就会一直停留在bootloader保持DFU模式，并再次重试更新过程。因为原固件擦除，所以此时设备的正常功能已经无法使用，相当于“变砖“了。

图2 应用更新的single bank模式^[2]

dual bank模式是指将新固件的数据存储在Flash的另一区域，而不是直接覆盖老固件程序，从而保证更新过程被意外中断时不会影响到原有程序的正常运行。以应用更新为例，Bank 0保存原有的应用，Bank 1保存新获取的应用。更新成功后，擦除Bank 0中的老应用，将Bank 1的新应用内容拷贝到Bank 0的位置。DFU bootloader会在接收数据前检查Bank 1的大小，当空间足够则进行dual bank更新；当image数据超过Bank 1的可用空间时，则会切换到single bank。dual bank通过牺牲部分存储空间，换来了更可靠的设备升级过程。

图3 应用更新的dual bank模式^[2]

设备在初期设计阶段时，其固件一旦被写入设备硬件中就很少更改，且最初是通过有线方式如使用UART、SPI等通信接口传输新固件包进行升级。随着物联网技术的发展、用户智能设备的数量增多，当一种或多种设备类型遇到安全攻击时，特别是智能汽车，制造商需要大批量召回已销售到市场上的设备，或者派遣技术人员上门服务，耗费成本非常高，时间周期较长，安全漏洞也不能及时修补，对用户和厂商造成的损害非常大。

为了解决传统方式的痛点，OTA技术被运用到智能设备的升级中。OTA update（Over The Air update，空中升级），即通过无线通信方式，对移动终端设备上的固件、数据和应用进行远程管理。设备可以从远程服务器下载软件更新包，并对自身系统进行升级。它极大的方便了用户和厂商，在很大程度上达到了双赢：

• 从用户角度而言，无需用户自行更新或者将设备送到特定的维修中心进行更新，提升用户满意度；

• 从设备厂商而言：

以智能手表为例，介绍目前可能的一种DFU-OTA方案。手机端和云端的传输过程需使用安全的传输通道（如https）并进行加密处理和数字签名操作，保证传输过程中数据的机密性、完整性和合法性。在手机和手表已建立蓝牙连接的情况下：

1. 手机端向手表设备查询当前设备信息（如当前固件版本）并回传给云端，云端将最新固件版本等信息回传给手机端；

2. 手机端对比当前版本和最新版本，若当前版本不为最新版本，则向云端请求下载设备最新固件包等数据，云端返回相应数据。手机端需先对获取的固件包完整性和来源合法性进行校验；

3. 如需升级，手机端发送升级指令和固件基本信息给手表；

4. 手表端检查固件基本信息（版本等）无误以及相应的升级环境（电量要求、存储容量等）均满足后，返回允许升级信息。若相关信息有误或不满足要求，则不进行后续操作；

5. 手机端发送升级包（根据具体的传输协议和固件大小，确定是否需要拆包发送）；

6. 手表端接收并校验固件的合法性（完整性和来源合法），校验无误后进入DFU模式进行设备升级，此时手表和手机端会自动断开；

7. 设备升级完后需重启，重新连接手机后正常使用。

图4 OTA升级

OTA升级的具体方案需要根据物联网设备的特性、选用的系统架构和技术来制定。上述例子使用具有Internet连接的网关（此处指手机）从云服务器接收更新包，然后操作和管理设备。有些设备，例如路由器或智慧网关本身，无需再次经过网关，可以直接通过互联网与云端通信并完成升级过程。

当前的OWASP物联网十大漏洞中，排名第四的就是缺乏安全的更新机制。固件验证缺失、明文数据传输、回滚机制缺失和安全更新通知的缺失是主要原因。OTA升级成功与否不仅关系到设备的安全性和可用性，还可能影响用户隐私和财产安全。整个过程中我们可能面临的风险如下：

• 传输过程中是否能窃取固件中敏感信息；

• 固件有没有被攻击者篡改；

• 固件是否来自受信任的来源；

• 目标设备端是否可信，是否会被身份伪造攻击；

• 攻击者使用具有漏洞的老版本对设备进行降级或替换；

• ……

对于传输过程，需要使用安全的无线通信协议，并且加密固件包，保证只有终端设备能够解密。对于固件防篡改，可以通过数字签名技术来保证固件的完整性和来源的安全：

1.服务端（设备厂商）对固件文件进行哈希处理后，用服务端私钥签名，将签名值和固件数据等生成OTA.bin文件，上传到云端；

2.设备端接收OTA.bin文件后，提取出固件数据并以相同的方式进行哈希处理，得出一个哈希值。将OTA.bin文件中的签名用预置在设备的服务端公钥进行解密后的值，对比二者，如果相同则可以确定固件的完整性以及来源于合法的服务端。

图5 OTA升级包验签

安全性要求较高的场景下，需在升级前进行服务端和设备端的双向认证，防止身份伪造攻击。可以在设备出厂前预先为每个设备烧录唯一的设备证书或身份标识，服务端需要验证该设备证书后，确认设备没有被篡改或仿冒，才能进行数据传输。设备端也需要验证服务端的身份，防止重放攻击，导致设备端可能会“无条件”再次执行服务端下发的控制指令，造成一些意想不到的安全问题。

结语：

随着互联网科技的发展，智能设备变化越来越快，OTA升级在物联网中扮演着愈发重要的角色。OTA升级在稳定性、高效性和安全性等方面所面临的问题和挑战，特别是智能汽车行业，还等待着技术人员不断地研究，并持续打造一个安全、全链条的OTA升级环境。

参考资料：

[1]https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_bootloader_dfu_process.html&cp=8_5_4_3_5_1

[2]https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_bootloader_dfu_banks.html

[3]http://www.sunyouqun.com/?s=dfu

[4]https://blog.csdn.net/m0_37621078/article/details/115541552

阅读原文，了解更多安全内容