高通OTA升级方案介绍
- 1. 高通LE OTA
- 1.1 背景
- 1.2 Recovery系统
- 2. SDX12 OTA方案
- 3 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方案,基本可以总结以下几个步骤:
- 本地制作差分包,并上传到远端OTA服务器
- x12启动OTA client线程去在固定间隔时间访问OTA服务器
- 当OTA服务器上有可用OTA 包,则校验包是否完整、版本号是否符合预期
- 若3中校验OK,则下载OTA包到本地
- 下载完成后重启进入recovery模式
- recovery模式启动后会先检测是否存在OTA包,存在则解压包并使用包中的工具打patch
- 升级完成后设置成功标记并重启进入boot模式
- 升级完成
流程图如下:
X12原本的OTA升级流程中仅有对OTA包的校验,针对的是其完整性和合法性,并没有安全性的保障,如黑客可以通过特殊方式篡改OTA包,并上传到OTA服务器上,就会存在极大的安全隐患。针对这一问题,我们在X12 OTA流程中增加了相关加解密,最大可能保证包的安全性。
3 OTA包的加密
按照行业规范,设备固件升级(OTA 远程或本地升级)前应先对固件包进行完整性哈希得到固件包摘要,再使用公私钥方式对摘要进行合法性签名和验签,确认升级包完整性与合法性再进行更新,以防止固件包被篡改或替换。固件升级包完整性哈希应采用安全的哈希算法,完整性凭据应在设备与服务端的加密通信通道内传输。
我们按照这个思路对x12的OTA流程做了优化,增加OTA包加解密流程:
- 本地制作差分包,对差分包使用openssl工具进行-aes-256-cbc加密,并上传到远端OTA服务器
- x12启动OTA client线程去在固定间隔时间访问OTA服务器
- 当OTA服务器上有可用OTA 包,则校验包是否完整、版本号是否符合预期
- 若 3 中校验OK,则下载OTA包到本地
- 下载完成后,再使用openssl工具解密,解密后再重启进入recovery模式
- recovery模式启动后会先检测是否存在OTA包,存在则解压包并使用包中的工具打patch
- 升级完成后设置成功标记并重启进入boot模式
- 升级完成
下面是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包的加密,也可以根据需要去客制化加密方式、加密密钥、初始向量。