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" ] ; 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包的加密，也可以根據需要去客制化加密方式、加密密鑰、初始向量。