朱天楠，施 勇，薛 質,2

(1.上海交通大學 信息安全工程學院，上海 200240;

基于Xposed的Android透明文件加密系統(tǒng)的研究

朱天楠1，施 勇1，薛 質1,2

(1.上海交通大學 信息安全工程學院，上海 200240;

2.上海市信息安全綜合管理技術研究重點實驗室，上海 200240)

隨著移動處理器技術水平的高速發(fā)展，智能設備的計算能力不斷加強，人們對智能手機的依賴性也不斷增加。通過安裝各類應用，手機可以具有豐富的功能，但使用過程中往往會需要記錄用戶的隱私數據，保護存儲在智能設備上的用戶隱私數據不被惡意應用隨意獲取的需求日益加大。結合當前流行的透明文件加密技術與Android自身的一些特點，提出了一種基于Xposed框架的透明文件加解密方案。其以SharedUserId和開發(fā)者簽名信息為標識自動生成密鑰，將各個APP的數據以不同的密鑰加密處理，這樣即使在惡意APP獲取到了Root權限，仍能保護各APP的隱私數據不被非法獲取，從而提升了Android設備的安全性。該過程自動完成，無需應用開發(fā)者和用戶參與，無需改變開發(fā)與使用習慣。

隱私安全；Xposed框架；透明加密；Android

0 引 言

隨著智能手機的普及，人們對手機的依賴不斷加大。各種APP出于功能上的需求會悄悄在手機上存儲各種數據文件，其中可能會包含使用者的隱私信息，加密技術無疑是保護這類數據的有效方式。透明文件加密技術多年的發(fā)展表明，這是一種較好的隱私保護安全機制。

透明文件加密技術按實現的位置可以分為用戶態(tài)的實現與內核態(tài)實現。早期用戶態(tài)的透明加密主要是通過鉤子函數來Hook文件打開與關閉的操作，在打開文件時，將磁盤上的密文解密到一個臨時的隱藏文件中，然后將隱藏文件返回給應用，用戶對文件的修改會反饋到隱藏文件中，當關閉文件時系統(tǒng)再將隱藏文件整體加密，替換磁盤上原先的密文，最后刪除掉隱藏文件。這種靜態(tài)加密的方法實現簡單，但是每次都要對整個文件做加密解密操作，整體效率較低，同時隱藏文件的出現對整體安全性構成威脅[1]。內核態(tài)的加密系統(tǒng)有的通過堆棧式文件系統(tǒng)在VFS與底層操作之間完成加解密[2]，也有通過LSM框架Hook相關內核函數[3]等實現方法，內核態(tài)的加密技術在速度與穩(wěn)定性上具有優(yōu)勢[4]，但是出于安全性考慮，目前有些Android移動設備不具備動態(tài)加載驅動模塊的功能。這將使得內核態(tài)的加密技術難以在現有設備上推廣。

由于移動處理器性能增速遠快于磁盤性能的增長，用戶態(tài)上的加密技術對性能影響的權重將會逐漸減少。同時文中使用SharedUserId和APP的簽名作為標識來選取密鑰，而從Android上層獲取這些信息比較方便。因此，使用Xposed框架來實現用戶態(tài)的動態(tài)透明文件加解密系統(tǒng)。該系統(tǒng)能夠自動為各個應用生成不同的加密密鑰，并加密數據。整個過程都對用戶與開發(fā)者透明。

1 現有Android平臺的數據安全服務

在數據加密方面：自Android3.0之后，谷歌通過deivce-mapper提供了磁盤加密機制dm-crypt[5],deivce-mapper是Linux中的一個框架，Linux中的RAID、LVM等功能都基于該框架。它可以將一個虛擬的塊設備映射到一個或多個實際的物理設備，在映射過程中，可以對交互的數據進行修改[6]。該技術在Android中可以用于全盤加密，下文提到的磁盤數據校驗中也依賴該框架。

dm-crypt磁盤加密技術主要是對整個分區(qū)，例如把/data對應的分區(qū)進行加密，在系統(tǒng)啟動時init進程通過掛載/data目錄來判斷磁盤是否加密。如果分區(qū)加密則會提示用戶輸入密碼，并重啟Android framework，重新掛載分區(qū)。這種方式控制粒度較粗，一旦解密，所有APP都能像以前一樣訪問/data目錄，因此無法防止惡意APP獲取其他APP的私有數據。

在數據完整性方面：為了應對RootKit等攻擊，Android在4.4中引入了Verified Boot機制來保證啟動磁盤的完整性，其基于Linux內核dm-verity(device-mapper-verity，3.4版加入到Linux中)機制。在啟動過程中會對塊設備進行完整性校驗。校驗過程中使用的RSA公鑰存儲在啟動分區(qū)中。校驗出錯將會返回I/O異常。dm-verity通過構建一個多叉樹狀結構來保存對應分區(qū)中所有塊的哈希值，這棵樹的葉子節(jié)點表示物理設備上各塊的哈希值，中間節(jié)點保存其子節(jié)點的哈希值，這樣物理設備上任何數據的變化都將導致該樹子節(jié)點哈希值的變化，同時這個變化會影響到其所有祖先節(jié)點，最終改變根節(jié)點的哈希值。這樣只需比較根節(jié)點的哈希值就可以知道數據是否被篡改[7]。相較于I/O操作，哈希計算所造成的遲延不是十分明顯。dm-verity對磁盤所進行的校驗工作是由Linux內核完成的，因此首先需要保證Linux內核的完整性，防止其被篡改。通常移動設備制造商會在一塊物理存儲設備上固化一把校驗密鑰，在設備啟動時可以通過TrustZone技術首先使用這把密鑰校驗bootloader和kernel的完整性。由于在可寫的情況下，如磁盤掛載時間一類的元數據都將被系統(tǒng)修改，因此該技術要求被保護的磁盤只能以只讀的方式掛載，Android中主要用來保護/system分區(qū)，而/data以及外部存儲設備這種本身就會被不斷修改的分區(qū)將無法獲得保護。

在數據訪問控制方面：Android繼承并發(fā)展了傳統(tǒng)Linux下的訪問控制機制，將傳統(tǒng)Linux下的用戶的概念應用到APP上。UID不再代表手機使用者，而是用來區(qū)分各個APP，每一個APP獲得一個UID,這樣傳統(tǒng)Linux在對用戶的“讀-寫-執(zhí)行”權限控制機制就順利地延續(xù)到了APP上[8]。同時組的概念用來分配系統(tǒng)資源，APP要訪問系統(tǒng)資源例如網絡、攝像頭、外部存儲等，需要加入相應的組。通過這種機制各個APP自己的數據(主要指/data/data/下的數據)相互隔離開來。但是一旦惡意應用獲取到root權限，還是可以訪問其他應用的數據。

2 應用標識的選取

為了實現各APP的數據使用不同的密鑰加密，就需要選取一個合適的標識，來區(qū)分哪些APP不能共享數據。Android應用的AndroidManifest.xml中有一個稱為SharedUserId的標識符(沒定義的話為空)。對于具有相同的SharedUserId，并使用相同的開發(fā)者證書簽名的應用可以相互訪問各自私有數據[9]。Android系統(tǒng)在安裝應用時，如果有多個具有相同SharedUserId但證書不同的APP，只有最初的那一個能安裝成功。因此選取SharedUserId與開發(fā)者的證書信息作為標識符合該系統(tǒng)的需求。

3 Xposed Hook原理

在Android中，所有的APP進程都通過Zygote進程創(chuàng)建。Zygote在啟動過程中會加載部分資源，這樣通過其創(chuàng)建的所有APP都將繼承這些資源，而無需重新加載，從而減少了啟動時間。Zygote進程實際上是在系統(tǒng)啟動過程中/system/bin/app_process程序通過系統(tǒng)調用更換名稱得到的[10]，為此，Xposed將自己定制的app_process替換到目標設備中(需要root權限)，通過Hook Zygote，從而達到Hook所有APP的目的。Xposed在這個定制的app_process中添加了XposedBridge.jar庫文件，系統(tǒng)會將需要Hook的方法指向XposedBridge中的本地方法xposedCallHandler，而后xposedCallHandler會調用handleHookedMethod來回調對應的beforeHookedMethod和afterHookedMethod(分別在被Hook方法前后調用)，在這兩種方法中可以修改傳給被Hook方法的參數及其返回值。

4 加密算法的選擇

現代加密算法按照加解密密鑰的類型可以分為對稱加密與非對稱加密兩大類[11]。由于非對稱加密算法計算量相對較大，出于性能上的考慮，該系統(tǒng)采用對稱加密算法。對稱加密技術又可分為塊加密與流加密技術。文中通過對比常見的DES、AES、RC4來選取適合的方案。

DES(Data Encryption Standard)是一種塊加密算法，它每次使用64 bit的密鑰(除去校驗位實際只有56 bit)，以64 bit(8字節(jié))數據為單位加密數據，加密后的密文塊也是64位。

AES(Advanced Encryption Standard)又稱為Rijndael算法，它使用的數據分組長度為128 bit，密鑰長度可以為128/192/256 bit[12]。

RC4是一種密鑰長度可變的流加密算法[12]，該算法實現十分簡單。通過密鑰來初始化一個大小為2n的S-Box(n一般為8)，在對明文進行加密的同時，S-Box也在不斷變化，這樣即使出現相同字符，解密結果也不一定相同。作為流加密算法，可以使得密文長度與明文長度相同。

4.1 從安全性角度進行比較

暴力破解作為最直接的攻擊方法，適用于各種加密算法。因此保證數據在一定時間內難以破解是評估密碼算法的一項重要指標。相比于RC4和AES，默認的DES算法密鑰有效長度只有56 bit，較易被攻擊[13]。2006年，魯爾大學與基爾大學用FPGA開發(fā)出硬件破解設備COPACOBANA，它主要針對64位以內的密鑰進行暴力破解。2007年，該設備平均6.4天就可以破解一個DES密鑰[14]。相對來說，AES和RC4的密鑰所對應的空間要遠遠高于標準的DES算法，暴力破解成本較高。

4.2 從加密前后數據長度變化角度進行比較

塊加密算法，一般都是一次對固定長度n的平文進行加密操作得到密文。DES算法每塊數據長度為8個字節(jié)，加密后得到8個字節(jié)密文，AES算法一般使用16字節(jié)的平文數據塊，加密后得到16字節(jié)密文。使用塊加密方法如果平文長度不足n，一般會進行填充操作，從而使得加解密前后數據長度發(fā)生變化。而如RC4這樣的流加密算法，可以每次以一個字節(jié)為單位進行加密處理，不會改變數據長度。

4.3 從誤差傳播角度進行比較

存儲介質在使用過程中都會漸漸出現數據的損壞，因此，在設計透明文件系統(tǒng)時就需要考慮存儲介質上一個存儲單位的損壞會對解密后明文的結果造成的影響。

塊加密的工作方式有多種，如ECB(Electronic CodeBook)、CBC(Cipher Block Chaining)、PCBC(Propagating Cipher-Block Chaining)、CFB(Cipher-FeedBack)、OFB(Output-FeedBack)等[15]。其中ECB最為簡單，其工作原理如圖1所示。使用同一把密鑰分別對各塊數據進行加密，各塊數據相互獨立。因此，磁盤上密文的損壞只會影響到其所在的數據塊，不會將這種影響擴散到其他數據塊中。

圖1 ECB解密原理圖

CBC和簡單的CFB在解密過程中都是用前一塊密文作為初始化向量參與到解密過程中，因此一個字節(jié)的損壞會影響到自己以及后一塊數據的解密，對其他數據沒有影響。CFB解密過程如圖2所示。

圖2 CFB解密數據原理圖

PCBC這種方式下密文中出現的誤差能夠盡可能影響到后續(xù)結果，這與透明文件加密的需求不符。

OFB可以讓密文與平文同一位置的數據位同時翻轉。這個特性利于奇偶校驗，密文出錯時，在解密前就可以驗證出問題。但一位數據的損壞，同樣會造成一個數據塊的解密失敗。

RC4算法在解密過程中S-Box可以不受密文或平文的影響，存儲介質上一個字節(jié)的損壞不會影響到其他字節(jié)。

4.4 從數據加解密速度進行比較

為了比較三種加密算法的加解密速度，使用一臺配備Exynos4210(雙核 頻率1.5 GHz)CPU的Android設備，分別處理1 k,10 k,100 k,1 M,10 M數據，測量消耗時間。其中DES和AES使用Java中自帶庫來實現(使用ECB/PKCS5Padding)，RC4實現簡單，實驗中自己實現相關加解密函數，得到的結果如表1所示。

綜合上述結果，選取RC4算法實現透明文件加密系統(tǒng)。由于RC4的S-Box隨著加密過程不斷變化，如果要往一個長度為n的文件追加內容，首先需要對S-Box的初始化進行n次變換。在處理較大文件時效率低，也無法發(fā)揮多核CPU的優(yōu)勢。為此，以4k為單位劃分文件數據，每到4k數據就將S-Box復位，這樣每4k數據相互獨立，可以多線程處理。

表1 各加密算法在實驗平臺上的性能測試 ms

5 系統(tǒng)整體框架

系統(tǒng)采用應用中的SharedUserId以及對應的簽名信息作為APP的標識，通過主密鑰加密處理后，得到加解密數據的實際密鑰。這樣APP無法訪問通過其他標識加密的數據，可以在不影響用戶與原有應用的情況下為系統(tǒng)提供透明的文件加密服務。其中數據加解密功能是通過Xposed框架來Hook各個APP中Java文件讀寫操作，工作原理如圖3所示。

圖3 透明文件加密工作原理圖

6 系統(tǒng)實現

6.1 加密策略

從Android設計的角度來看，其對各個APP數據訪問的限制都是針對內部存儲的，因此一般開發(fā)者默認將私有的數據保存在自己的存儲區(qū)中，將共享的或無需加密的數據放在外部存儲空間中，因此系統(tǒng)默認為應用在/data/data下的文件提供加解密服務，采用由如圖4所示的加密策略。

6.2 獲取SharedUserId以及簽名信息

在Xposed模塊里可以通過handleLoadPackage傳遞進來的參數獲取當前應用的名稱，再通過Package-Manager獲取相關的SharedUserId。但再次之前需要獲取當前的Context對象才行，但是通常Xposed的Hook模塊是在一個單獨的類，本身沒有當前程序的Context對象。所以需要Hook當前APP的getApplicationContext方法，再保存其返回Context對象，相關代碼如下：

findAndHookMethod("android.content.ContextWrapper",lpparam.classLoader,"getApplicationContext",new XC_MethodHook())

{

protected void afterHookedMethod(MethodHookParam param)throws Throwable {

storedContext=(Context) param.getResult();

…………

if(pInfo.packageName.equals(packageName)){

sharedUserId=pInfo.sharedUserId;

signature=pInfo.signatures[0].toCharsString());

}

…………

});

然后通過SharedUserId，簽名信息，以及主密鑰計算出加密該APP數據的實際密鑰。

圖4 加密策略

6.3 Hook相關方法

6.3.1 Hook文件操作的構造方法

由于Java中與文件讀寫相關的類很多，這里以FileInputStream和FileOutputStream為例(下同)。Java中對文件操作沒有顯示的Open操作，實際上在FileInputStream之類的構造方法中會調用相關的Open函數，為此Hook相關構造方法即可獲得與Hook open方法類似的效果。

在構造方法中，首先判斷這個文件是否需要加密處理，如果需要的話在全局的HashMap中保存一個以構造函數創(chuàng)建的對象為key，index為值的數據項。index表示目前創(chuàng)建的對象在文件中將要讀寫的偏移量，當發(fā)現文件長度比index小時說明有進程或其他對象對文件內容做過刪減操作，當前的S-Box需要更新，同時也用來輔助實現按4k分割數據復位S-Box的功能。

6.3.2 Hook read相關方法

FileInputStream的read相關方法主要有read()，read(byte b[])，read(byte b[],int off,int len)。其中，前兩種相對簡單，這里以第三種為例。

解密操作主要是在read方法從磁盤上讀到文件之后進行的，因此需要實現XC_MethodHook中的afterHookedMethod方法。首先通過afterHookedMethod方法的參數param.thisObject得到實際調用read方法的對象，然后從全局HashMap中得到對應的index值，在后續(xù)讀過程中按需復位S-Box。由于這個read方法是將讀取到的內容保存到參數b數組中，因此還需要通過param.args獲取到該數組和對應偏移量。雖然參數中有要讀取的長度信息len，但實際讀取的數據量可能比len要小，所以還要通過param.getResult()方法得到read的返回值即實際讀取到的數據大小。然后結合index，b，off，實際數據量，對b中的數據進行加密。最后更新HashMap中的index。

6.3.3 Hook write相關方法

加密操作是在平文數據發(fā)送給實際write方法之前進行，因此要實現XC_MethodHook中的beforeHookedMethod方法。具體實現與Hook read中所述類似。此外write操作時要注意同步問題，例如當對象A以非追加的方式打開并寫入文件，相當于清空數據，此時S-Box應該復位，如果沒有同步機制的話，可能對象B正在通過之前計算的S-Box加密數據然后調用原生的write寫入文件，導致使用錯誤的S-Box加密數據。

6.3.4 Hook skip方法

skip方法用于在讀文件的過程中跳過一部分數據，該系統(tǒng)實現beforeHookedMethod方法，由于skip(longn)不一定能跳過n個字節(jié)，所以要用原skip函數的返回值來更新index和S-Box。

6.3.5Hookclose方法

程序調用close方法后會釋放相關的文件資源，通過實現beforeHookedMethod方法，刪除index等自己創(chuàng)建的資源。

6.4 實驗結果

該系統(tǒng)可以對Java層的應用實現透明的文件加解密，保護數據安全。為測試該系統(tǒng)對Android讀寫性能的影響，使用在一臺CPU為Exynos4210(雙核cpu 頻率1.5 GHz)的設備為實驗平臺，對比使用透明加密與沒有使用透明加密時在性能上的區(qū)別。

實驗結果如表2所示，加解密數據會對讀寫性能

表2 透明加密對性能的影響 ms

造成一定的影響。但當應用不是頻繁讀寫磁盤數據時，對使用者使用體驗影響不明顯。

7 結束語

透明文件加密可以有效保護用戶數據安全，基于Xposed的透明文件加密方案靈活性較高，可以方便地部署在已經發(fā)布的移動設備中，使用該系統(tǒng)可以在一定程度上保證用戶隱私安全。雖然在當前移動設備硬件條件下，性能會有一定損失，但目前移動GPU廠商紛紛將異構計算引入到移動設備中，多線程操作加上硬件性能的提升將減緩加密造成的性能損耗。

[1] 趙銘偉,毛 銳,江榮安.基于過濾驅動的透明加密文件系統(tǒng)模型[J].計算機工程,2009,35(1):150-152.

[2] Halcrow M A.eCryptfs:an enterprise-class encrypted filesystem for Linux[C]//Proceedings of the 2005 Linux symposium.[s.l.]:[s.n.],2005:201-218.

[3] 陳莉君,于運超.基于LSM的輕量級透明加密設計與實現[J].西安郵電大學學報,2014,19(1):78-81.

[4] 王全民,周 清,劉宇明,等.文件透明加密技術研究[J].計算機技術與發(fā)展,2010,20(3):147-150.

[5] Müller T,Spreitzenbarth M.Frost[C]//Applied cryptography and network security.Berlin:Springer,2013:373-388.

[6] 宋振華.虛擬化技術中的存儲管理問題研究[D].合肥:中國科學技術大學,2010.

[7] 艾 祝.基于iSCSI的數據完整性研究與實現[D].蘭州:蘭州大學,2014.

[8] 吳 倩,趙晨嘯,郭 瑩.Android安全機制解析與應用實踐[M].北京:機械工業(yè)出版社,2013:26-29.

[9] Delac G,Silic M,Krolo J.Emerging security threats for mobile platforms[C]//Proceedings of the 34th international convention.[s.l.]:IEEE,2011:1468-1473.

[10] Shabtai A,Fledel Y,Elovici Y.Securing Android-powered mobile devices using SELinux[J].IEEE Security & Privacy Magazine,2010,8(3):36-44.

[11] 張曉豐,樊啟華,程紅斌.密碼算法研究[J].計算機技術與發(fā)展,2006,16(2):179-180.

[12] Singhal N,Raina J P S.Comparative analysis of AES and RC4 algorithms for better utilization[J].International Journal of Computer Trends and Technology,2011,79(14):177-181 .

[13] Wiener M J.Efficient DES key search[D].Canada:Carleton University,1994.

[14] Schimmler M,Wienbrandt L,Guneysu T,et al.COPACOBANA:a massively parallel FPGA-based computer architecture[M]//Bioinformatics-high performance parallel computer architectures.[s.l.]:CRC Press,2010:223-262.

[15] 吳文玲,馮登國.分組密碼工作模式的研究現狀[J].計算機學報,2006,29(1):21-36.

Research on Android Transparent Encryption File System Based on Xposed

ZHU Tian-nan1,SHI Yong1,XUE Zhi1,2

(1.College of Information Security and Engineering,Shanghai Jiaotong University,Shanghai 200240,China; 2.Shanghai Key Laboratory of Integrated Administration Technologies for Information Security,Shanghai 200240,China)

With the constant progress of SOC technology,mobile devices are more and more powerful,and the people relies increasingly on them.Richer applications enhance the capability of mobile devices,but malicious APP which aim to steal users’ private information are also spring up.To protect users’ privacy,an encrypted on-the-fly solution based on Xposed is proposed which is combination of a popular Hook framework on Android.This solution uses SharedUserId and developer’s signature as identity to calculate the secret key for encryption,so that every different APP has a different key.Hence even the malicious app runs as root user,it still cannot obtain other APP private data which improves the security of Android devices.The process is done automatically,without application developers and users to participate in,don’t need to change the habit of development and use.

privacy security;Xposed;encrypt on-the-fly;Android

2015-08-15

2016-01-05

時間：2017-01-10

國家自然科學基金資助項目(61332010)

朱天楠(1988-)，男，碩士，研究方向為移動設備安全。

http://www.cnki.net/kcms/detail/61.1450.TP.20170110.1010.024.html

TP309

A

1673-629X(2017)02-0064-05

10.3969/j.issn.1673-629X.2017.02.015