高通OTA升级方案介绍

3UK Penetration Test对于OTA升级也有严格的安全要求，下面是几条用例要求：

Firmware: A sufficiently strong signing key MUST be in use. Signing keys MUST be at least 2048-bits in the case of RSA. Certificate/key expiry SHOULD be no later than 10 years from creation (if applicable). Signing keys SHOULD NOT use deprecated digests, for example SHA1
固件:必须使用一个足够强的签名密钥。在RSA的情况下，签名密钥必须至少是2048位。证书/密钥有效期不应晚于创建后的10年(如果适用)。签名密钥不应该使用已弃用的摘要，例如SHA1
Firmware: Firmware (inc bootloader) MUST be downloaded securely - all firmware servers SHALL mandate TLS 1.2 or greater. Clear-text protocol such as HTTP MUST NOT be permitted.
固件:固件(inc bootloader)必须安全下载-所有固件服务器必须要求TLS 1.2或更高版本。明文协议，如HTTP绝对不允许。
Firmware: Firmware (inc. bootloader) MUST be encrypted using a NIST recognised authenticated cipher, for example AES-256-GCM or asymmetric cryptography. Salts and IV's SHALL be unique, IV's SHOULD NOT be reused. Encoding schemes (without a key) SHOULD NOT be used. Firmware MUST be signed and encrypted.
固件:固件(inc. bootloader)必须使用NIST认可的认证密码进行加密，例如AES-256-GCM或非对称加密。盐和 IV是唯一的， IV不能重复使用。不应该使用编码方案(没有密钥)。固件必须签名和加密。

按照要求，必须对ota固件包进行加密，以防止由升级包文件在下载过程中被截获导致系统文件被他人获取,甚至被他人篡改或替换导致不安全，进而造成无法估量的损失。

比如当前高通X12平台使用的是未加密的传输方式，在服务器端放置约定好名称的ota固件包，设备端轮询检测，当检测到有可用的ota固件包，则直接下载升级，存在较大的安全隐患

1. 高通LE OTA

1.1 背景

高通MDM、MSM平台提供了基本的升级功能，大概都以开源的Android升级设计实现作为基础，对其代码进行移植，适配到自身平台上。从差分包制作工具，升级过程，都有一套完整的方案，并且所涉及到的工具和代码均完全开放，因此该方案的可塑性也更大。其中包括统一的用于安装升级包的Recovery系统，编译OTA底包专属框架，和处理底包制作升级包的脚本和工具等。

由于该方案中各个文件的PATCH 基于文件系统而来，因此很难在bootloader 阶段实现（无法挂载文件系统），所以在分区设计上，除了预留存放差分包，备份文件的空间外，还需要添加专门的分区（kernel， bootloader，filesystem）以供FOTA 使用，而该分区必须独立于正常运行时的分区。这也就导致了该方案在硬件（FLASH，DDR）要求比较高。

在LE 的FOTA 方案中，升级程序作为一个应用程序运行，升级包则是一个标准的zip 文件（命名为ota 文件），升级过程则是解析升级包中指定的脚本文件，并根据解析到的内容引用对应的功能模块，从而完成整个升级过程。

1.2 Recovery系统

这里就不得不提recovery系统。Recovery系统是升级功能的载体，是一个包含文件系统相关操作的最小系统。OTA的安装过程，或是Nand、EMMC原始分区的读写，或是文件系统之上的文件操作。此外，MSM平台上，恢复出厂设置的功能，也是以Recovery系统为载体。

Recovery系统对升级包的安装，可以看作是一系列自动化的实现。在OTA升级中，相对应Recovery系统，习惯把正常启动的系统叫主系统（Main System）。下面通过一张简图，把各个概念融合一起，描述整体Recovery系统和主系统的关系。

以MDM平台项目为例。Kernel部分，两个系统完全一致，只是主系统有主系统的Boot分区，Recovery有Recovery分区，其中烧入的镜像完全一致。到system部分，主系统和Recovery系统有各自的rootfs，主要区别在两个系统的挂载和加载的进程服务不一样。Recovery系统区别于主系统的一点，是在启动后，init进程会拉起bin/recovery，这就是recovery service，由这个recovery service来完成安装包的解析安装。

在主系统和Recovery系统之间，还有一个cache分区，这个分区是专门为Recovery系统规划的。这个分区的作用是主系统与Recovery之间的文件共享。升级包从主系统中置于cache分区，recovery通过此分区读取升级包，Recovery的日志也会通过文件方式存储在这个分区。

以上是Recovery系统的基本流程，Recovery服务中安装升级包的具体过程，在此不做赘述，可参考代码：apps_proc/bootable/recovery/recovery.c:main(int argc, char** argv)。

2. SDX12 OTA方案

X12 OTA升级使用的是高通平台通用的FOTA方案，基本可以总结以下几个步骤：

1. 本地制作差分包，并上传到远端OTA服务器
2. x12启动OTA client线程去在固定间隔时间访问OTA服务器
3. 当OTA服务器上有可用OTA 包，则校验包是否完整、版本号是否符合预期
4. 若3中校验OK，则下载OTA包到本地
5. 下载完成后重启进入recovery模式
6. recovery模式启动后会先检测是否存在OTA包，存在则解压包并使用包中的工具打patch
7. 升级完成后设置成功标记并重启进入boot模式
8. 升级完成

流程图如下：

X12原本的OTA升级流程中仅有对OTA包的校验，针对的是其完整性和合法性，并没有安全性的保障，如黑客可以通过特殊方式篡改OTA包，并上传到OTA服务器上，就会存在极大的安全隐患。针对这一问题，我们在X12 OTA流程中增加了相关加解密，最大可能保证包的安全性。

3 OTA包的加密

按照行业规范，设备固件升级（OTA 远程或本地升级）前应先对固件包进行完整性哈希得到固件包摘要，再使用公私钥方式对摘要进行合法性签名和验签，确认升级包完整性与合法性再进行更新，以防止固件包被篡改或替换。固件升级包完整性哈希应采用安全的哈希算法，完整性凭据应在设备与服务端的加密通信通道内传输。

我们按照这个思路对x12的OTA流程做了优化，增加OTA包加解密流程：

1. 本地制作差分包，对差分包使用openssl工具进行-aes-256-cbc加密，并上传到远端OTA服务器
2. x12启动OTA client线程去在固定间隔时间访问OTA服务器
3. 当OTA服务器上有可用OTA 包，则校验包是否完整、版本号是否符合预期
4. 若 3 中校验OK，则下载OTA包到本地
5. 下载完成后，再使用openssl工具解密，解密后再重启进入recovery模式
6. recovery模式启动后会先检测是否存在OTA包，存在则解压包并使用包中的工具打patch
7. 升级完成后设置成功标记并重启进入boot模式
8. 升级完成

下面是OTA包加解密的脚本：

#!/bin/sh
filename=$1
input=${filename:0-3}
#echo $input
dec_name=${filename%.*}
#echo $dec_name
if [ "$input" = "aes" ] ; then
    openssl enc -d -aes-256-cbc -in "$1" -out "$dec_name" -K E05A84ED2068B3DEE402304AD12F4A40E27DCFC8DF33FA58E335BEBB5978B7B4 -iv E27DCFC8DF33FA58E335BEBB5978B7B4

elif [ "$input" = "zip" ] || [ "$input" = "ota" ] ; then
    openssl enc -aes-256-cbc -in "$filename" -out "$filename".aes -K E05A84ED2068B3DEE402304AD12F4A40E27DCFC8DF33FA58E335BEBB5978B7B4 -iv E27DCFC8DF33FA58E335BEBB5978B7B4

else
    echo "文件名不存在或不支持此类文件类型！！！"

fi

通过上面的方式，我们就完成了OTA包的加密，也可以根据需要去客制化加密方式、加密密钥、初始向量。