普通网站,深圳市罗湖区住房和建设局官网,自助搭建网站,高端网站设计公司排行榜高通OTA升级方案介绍 1. 高通LE OTA1.1 背景1.2 Recovery系统 2. SDX12 OTA方案3 OTA包的加密 3UK Penetration Test对于OTA升级也有严格的安全要求#xff0c;下面是几条用例要求#xff1a; Firmware: A sufficiently strong signing key MUST be in use. Signing keys MUS… 高通OTA升级方案介绍 1. 高通LE OTA1.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 IVs SHALL be unique, IVs 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 bootloaderfilesystem以供FOTA 使用而该分区必须独立于正常运行时的分区。这也就导致了该方案在硬件FLASHDDR要求比较高。
在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 ] ; thenopenssl enc -d -aes-256-cbc -in $1 -out $dec_name -K E05A84ED2068B3DEE402304AD12F4A40E27DCFC8DF33FA58E335BEBB5978B7B4 -iv E27DCFC8DF33FA58E335BEBB5978B7B4elif [ $input zip ] || [ $input ota ] ; thenopenssl enc -aes-256-cbc -in $filename -out $filename.aes -K E05A84ED2068B3DEE402304AD12F4A40E27DCFC8DF33FA58E335BEBB5978B7B4 -iv E27DCFC8DF33FA58E335BEBB5978B7B4elseecho 文件名不存在或不支持此类文件类型fi通过上面的方式我们就完成了OTA包的加密也可以根据需要去客制化加密方式、加密密钥、初始向量。
