基于多云存儲的Android密鑰管理技術

余宇勁 凌 捷

(廣東工業大學計算機學院 廣東 廣州 510006)

0 引 言

Android是一款基于Linux的，擁有開源性和可移植性的智能移動操作系統。2008年9月，谷歌公司發布了第一版Android 1.0系統，至今Android系統已經占據了全球智能手機操作系統份額的85.9%。隨著Android設備的廣泛使用，Android平臺上的惡意軟件數量急劇增加，騰訊安全實驗室在2019年公布的手機安全報告中指出，去年國內Android新增病毒包達800.62萬個，Android手機病毒感染用戶數近1.13億。2018年手機病毒類型占比中，隱私獲取與遠程控制的綜合比例為17.57%。 Android設備中隱私數據的存儲是一個難題，隱私數據包含用戶敏感信息、設備信息、密鑰等，其中密鑰的存儲是關鍵問題。

Android系統中的密鑰一般可分為兩種：一是安卓應用中，用來與服務器通信，或是加密App自身數據的密鑰；二是安卓應用中因為加密文件產生的密鑰。目前針對Android設備的安全問題，國內外學者已經做了大量的研究。文獻[1-3]指出了近年來Android設備安全問題研究優點和不足，詳細歸納了Android系統的安全缺陷以及所面臨的威脅。在企業移動管理系統上，文獻[4]提出了密鑰容器的概念，保護文件的加密密鑰，實現了移動端的安全存儲，但該方案需要對已有App進行函數重寫以及重打包，實現成本高。文獻[5]提出了基于RFID智能卡的 Android 移動終端數據保護方案，可以增加攻擊者破解難度，把密鑰信息存放在RFID卡上，采用機卡配合的形式，增加安全性，但是需要額外的硬件如智能卡、設備的NFC支持。文獻[6]提出了基于指紋與移動端協助的口令認證方法，利用指紋和口令結合生成密鑰，避免了密鑰的存儲，但其需要存儲指紋信息，存在安全隱患。文獻[7-8]提出了一些攻擊手段，可以遠程使存儲在設備上的密鑰泄露。文獻[9]提出了在Android平臺上進行多云存儲的思想，將密文分片后進行壓縮，然后分存到不同云服務商上，可以避免廠商鎖定的危害，有一定的可用性，但其密文分片的計算量很大，對于計算力有限的安卓設備會是一個巨大的開銷。文獻[10]提出了一種基于位置的移動設備加解密模型，使用位置信息結合密鑰進行加密，用戶只能在有效位置內進行解密。文獻[11]提出在安卓應用開發中將密鑰分存在SharedPreferences、文件存儲、Setting.System中，提高了數據的安全性，創新性地將密鑰分存的思想引入Android客戶端的開發中。文獻[12]在亞馬遜S3(傳統云平臺)的基礎上提出一種密鑰管理(Key Manager,KM)的概念，KM向用戶請求密鑰并與云服務商交互。但此方案沒有考慮用戶端是否存在惡意操作，如果用戶端受到入侵，那么數據的安全不能得到保障。

為了解決Android設備中密鑰的安全存儲問題，本文提出一種結合密鑰分塊和多云存儲的密鑰安全存儲技術，實現了密鑰的安全存儲，無須額外硬件支持，在終端設備上不涉及密鑰信息存儲，對文件加解密時間的影響較小，實驗證明了其安全性、可靠性和實用性。

1 預備知識

1.1 秘密共享

秘密共享方案中，有一個加密者和一組共享者{P1,P2,…,Pn}，加密者持有一個秘密s∈S，為每個共享者產生一個保密的秘密份額，使得共享者的任何一個授權集合能夠通過他們各自掌握的份額恢復出s。

(1) 秘密分割。秘密分割是由加密者實現的一個映射：

F:S·R→S1·S2·…·Sn

其中：S是秘密所在的集合；R是隨機輸入集；Si(i=1,2,…,n)是Pi的秘密份額集合。對?s∈S,?r∈R，映射F(s,r)得到一個n元組(s1,s2,…,sn)，使得si∈Si(i=1,2,…,n)。si稱為Pi的份額，記為Fi(s,r)=si，加密者以秘密方式將si給Pi。

(2) 重構。s能被任一授權集合重構，即對?G∈A，A為授權集合，設G={i1,i2,…,i|G|}，有一個重構函數:

hG:Si1·Si2·…·Si|G|→S

使得對?s∈S,?r∈R，如果F(s,r)= (s1,s2,…,sn)，則有：

hG(si1,si2,…,si|G|)=s

方案的安全性要求：任一非授權集合都不能得到s的任何信息[13]。即一個秘密被n個人分享，只有m(m≤n)個或更多的參與者聯合可以重構該秘密，而任意小于m個參與者不能得到該秘密的任何信息，以上定義為(m,n)-門限秘密分割方案，m稱為方案的門限值。

1.2 Android系統中的存儲

Android系統中存儲方式包括文件存儲、SharedPreferences存儲、數據庫存儲等。其中：文件存儲是Android中最基本的一種數據存儲方式，它不對存儲的內容進行任何格式處理，所有數據都原封不動地保存在文件中，適合存儲一些簡單的數據；SharedPreferences使用鍵值對的方式存儲數據，即保存數據時，給此條數據提供一個鍵，在讀取數據時通過對應的鍵取數據，如果把密鑰直接存儲在SharedPreferences很容易被竊??；數據庫存儲，Android內置了數據庫SQLite，適合存儲量大、結構性復雜的數據。

要在設備上安全存儲密鑰，目前常用的辦法是不斷加固客戶端，增大逆向成本。為了提高安卓設備上密鑰的安全性，本文不在本地上做密鑰的任何存儲，將密鑰按照秘密共享的思想，拆分成n塊秘密份額，上傳到n個云平臺上，即使是逆向成功，或是某云服務器與云客戶端以某種方式進行合謀攻擊，也不能獲得密鑰去解密密文。

1.3 多云平臺

云存儲是在云計算概念的基礎上發展起來的一種新的存儲方式，它是指通過網格計算、集群文件系統、分級存儲等現有技術，將網絡中大量的存儲設備通過硬件、軟件的方式集合在一起，并對外提供標準的存儲接口，以供用戶調用并存儲數據的存儲方式[14]。國內已經興起了多種云平臺如阿里云、騰訊云等。云存儲的最大特點在于存儲即服務，用戶可以通過開放的API將自己的數據上傳到云端保存，如百度Pesonal Cloud Storage(PCS)、阿里開放云平臺。但由于用戶喪失了數據的絕對控制權，一些數據安全的隱患也由此產生[15]。惡意云服務器與云客戶端進行合謀竊取用戶隱私，以及目前已知的多種攻擊手段如拒絕服務攻擊、僵尸網絡攻擊、音頻隱寫攻擊等都會造成用戶數據泄露。單云環境下還可能出現廠商鎖定或者服務器損壞的場面，用戶的數據安全得不到足夠的保障。

單云下存在諸多潛在的安全問題，如服務可用性故障、內部人員的惡意破壞等，為了提高云存儲可靠性，充分利用各個云的優勢，多云架構應運而生，通過在多個云存儲服務中分散存儲用戶數據的方式來避免和緩解云存儲提供商壟斷問題。這樣既可解決單云故障問題，又能提高安全性、可靠性，降低更換云服務提供商的成本。

各大云平臺開放的API使開發者能夠把自己的App和云服務端建立連接，根據API類型進行不同的操作，如圖1所示。

圖1 與云平臺建立連接

2 方法描述

本文提出的結合多云存儲和秘密共享的密鑰管理技術由三個部分組成，分別是加密部分、解密部分、處理密鑰部分， 其中處理密鑰部分是核心。

加密部分：負責結合用戶輸入的一次性口令產生隨機密鑰，對文件進行加密。

解密部分：與處理密鑰部分進行交互，利用傳回的重組的密鑰進行解密。

處理密鑰部分：進行拉格朗日插值多項式運算，選擇服務器，驗證服務器，傳輸完畢后刪除密鑰。

實現原理如圖2所示。

圖2 技術原理圖

2.1 加密階段

安卓端啟動加密程序，結合用戶輸入的一次性口令p生成隨機密鑰s，對明文M進行AES加密，得到密文C，存儲密文完畢，刪除p，初步加密完成。

2.2 密鑰保護階段

設門限法方案選擇(m,n)=(3,5)，將密鑰通過拉格朗日插值多項式進行切片，即生成5個秘密共享項，任意大于等于3個共享項即可解密。具體步驟如下：

(1) 生成隨機數R1、R2、x1、x2、x3、x4、x5。

(2) 計算對應的F(xi)：

(3) 給不同的(xi,F(xi))分配唯一的ID，發送給5個云服務端，刪除R和s。ID的作用是在多密鑰共享的情況下，區分不同的密鑰對應的(xi,F(xi))。

在密鑰保護階段完畢后，無論是本地還是云盤中，都不涉及到口令和密鑰的存儲，而是轉換成(xi,F(xi))的存儲，無須上傳密文，實現了用戶數據的私有化。

2.3 解密階段

當用戶需要解密時，安卓客戶端向隨機的三個服務端發出請求，進行各自的驗證，驗證通過后，根據ID依次返回(xi,F(xi))給安卓客戶端，客戶端進行方程組求解，得到s，進行解密。本文解密階段涉及到與不同的云進行交互，隨機選取m個云服務商進行驗證，查找ID，返回(xi,F(xi))，因為傳輸體積小，所以網絡消耗和時間成本較低。

2.4 安全性分析

文獻[11]將秘密份額存儲在SharedPreference、文件存儲和系統數據庫Setting.Systeam中，提高了攻擊者的破解難度，但是因為在Java層實現，攻擊者可以從apk文件包中解壓提取出classes.dex文件，利用反編譯工具(如apktool、Jadx等)獲得Java源碼，進而分析出秘密份額存儲位置進行重組密鑰。本文方法需要獲得憑證與多個云服務端建立連接，才能夠進行密鑰重組操作，假設攻擊者逆向成功，只能得到密鑰的拆分方式，用戶的一次性口令和秘密份額都已被刪除。用戶與n個云客戶端之間的通信，通過Android沙箱機制相互隔離，所以攻擊者與m個云服務端建立連接的可能性相當低，極大地降低了攻擊者獲得密鑰的可能性。

即使某個云服務商想窺探存儲在該云的數據，或者是黑客攻擊云存儲平臺，也只能得到部分的秘密份額(xi,F(xi))，這對整個解密過程是無意義的。假設運行在客戶端上的云客戶端得到了root權限，在未經用戶許可的情況下，與對應的云服務商進行合謀，竊取用戶密文，因為小于m個云服務端不能恢復密鑰，所以不能進行解密，攻擊者沒有辦法得到密鑰和明文信息。

3 實驗與結果分析

本實驗開發環境使用了Android Studio 2.2進行界面和邏輯編寫，Eclipse 4.10用于Java代碼調試；測試手機型號為Nexus 6，手機參數為Android 7.0系統，3 GB內存，CPU類型為驍龍805。利用本文方法對KB級到MB級的14個文件進行加解密測試，結果如表1所示。

表1 文件加解密時間

續表1

處理密鑰時間為加密之后的分片時間加上解密之前的組裝時間，和密鑰長度有關?；谠O備和實驗環境的原因，加解密時間不是線性增長的，但總體是隨著文件大小而上升的。

本文中，處理密鑰時間與密鑰長度有關，當文件大小增大時，處理密鑰時間占總時間的比重會縮小，對加解密時間的影響越小，如圖3所示。

文獻[8]提出在將密鑰分存在Android設備中的不同位置，如存儲在SharedPreferences、文件存儲、Setting.System等，選取該方案作為對比，處理相同位數的密鑰，所用時間對比如圖4所示，縱坐標為本文方案所用時間減去文獻[8]方案所用時間。

文獻[8]方案在Java層實施，分存在同一設備的不同地方，相對于密鑰直接存儲和密鑰硬編碼，提高了安全性，與本文方案對比，不需要與云服務商交互，節省了傳輸時間，但是將秘密份額分存在設備上，只要逆向了源文件，得到Java代碼，便可以分析秘密份額存儲位置，從而獲取密鑰。本文方案則是在密鑰保護階段，通過與多云平臺交互，將秘密份額存在不同的云服務端上，逆向不能得到密鑰存儲的相關信息，具有更高的安全性。

由于實驗環境、設備參數、代碼復雜度等因素存在差異，所以實驗結果會有一定的誤差，但是總體來看時間差穩定在100～150 ms內，不會影響用戶體驗。

4 結 語

本文提出了一種新的Android密鑰管理技術，通過結合多云存儲和秘密共享的思想，在密鑰處理階段，將秘密份額存放在n個云服務端上，與現有方案相比，減少了逆向得到密鑰信息的可能性，能夠避免云客戶端和云服務端的合謀攻擊，實現了Android客戶端密鑰的安全存放。在大文件加解密時，對加解密總時間的影響會顯著減少，具有實用性。