朱天楠，施 勇，薛 質(zhì),2

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

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

朱天楠1，施 勇1，薛 質(zhì)1,2

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

2.上海市信息安全綜合管理技術(shù)研究重點(diǎn)實(shí)驗(yàn)室，上海 200240)

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

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

0 引 言

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

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

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

1 現(xiàn)有Android平臺(tái)的數(shù)據(jù)安全服務(wù)

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

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

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

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

2 應(yīng)用標(biāo)識(shí)的選取

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

3 Xposed Hook原理

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

4 加密算法的選擇

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

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

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

RC4是一種密鑰長(zhǎng)度可變的流加密算法[12]，該算法實(shí)現(xiàn)十分簡(jiǎn)單。通過(guò)密鑰來(lái)初始化一個(gè)大小為2n的S-Box(n一般為8)，在對(duì)明文進(jìn)行加密的同時(shí)，S-Box也在不斷變化，這樣即使出現(xiàn)相同字符，解密結(jié)果也不一定相同。作為流加密算法，可以使得密文長(zhǎng)度與明文長(zhǎng)度相同。

4.1 從安全性角度進(jìn)行比較

暴力破解作為最直接的攻擊方法，適用于各種加密算法。因此保證數(shù)據(jù)在一定時(shí)間內(nèi)難以破解是評(píng)估密碼算法的一項(xiàng)重要指標(biāo)。相比于RC4和AES，默認(rèn)的DES算法密鑰有效長(zhǎng)度只有56 bit，較易被攻擊[13]。2006年，魯爾大學(xué)與基爾大學(xué)用FPGA開(kāi)發(fā)出硬件破解設(shè)備COPACOBANA，它主要針對(duì)64位以?xún)?nèi)的密鑰進(jìn)行暴力破解。2007年，該設(shè)備平均6.4天就可以破解一個(gè)DES密鑰[14]。相對(duì)來(lái)說(shuō)，AES和RC4的密鑰所對(duì)應(yīng)的空間要遠(yuǎn)遠(yuǎn)高于標(biāo)準(zhǔn)的DES算法，暴力破解成本較高。

4.2 從加密前后數(shù)據(jù)長(zhǎng)度變化角度進(jìn)行比較

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

4.3 從誤差傳播角度進(jìn)行比較

存儲(chǔ)介質(zhì)在使用過(guò)程中都會(huì)漸漸出現(xiàn)數(shù)據(jù)的損壞，因此，在設(shè)計(jì)透明文件系統(tǒng)時(shí)就需要考慮存儲(chǔ)介質(zhì)上一個(gè)存儲(chǔ)單位的損壞會(huì)對(duì)解密后明文的結(jié)果造成的影響。

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

圖1 ECB解密原理圖

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

圖2 CFB解密數(shù)據(jù)原理圖

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

OFB可以讓密文與平文同一位置的數(shù)據(jù)位同時(shí)翻轉(zhuǎn)。這個(gè)特性利于奇偶校驗(yàn)，密文出錯(cuò)時(shí)，在解密前就可以驗(yàn)證出問(wèn)題。但一位數(shù)據(jù)的損壞，同樣會(huì)造成一個(gè)數(shù)據(jù)塊的解密失敗。

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

4.4 從數(shù)據(jù)加解密速度進(jìn)行比較

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

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

表1 各加密算法在實(shí)驗(yàn)平臺(tái)上的性能測(cè)試 ms

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

系統(tǒng)采用應(yīng)用中的SharedUserId以及對(duì)應(yīng)的簽名信息作為APP的標(biāo)識(shí)，通過(guò)主密鑰加密處理后，得到加解密數(shù)據(jù)的實(shí)際密鑰。這樣APP無(wú)法訪問(wèn)通過(guò)其他標(biāo)識(shí)加密的數(shù)據(jù)，可以在不影響用戶(hù)與原有應(yīng)用的情況下為系統(tǒng)提供透明的文件加密服務(wù)。其中數(shù)據(jù)加解密功能是通過(guò)Xposed框架來(lái)Hook各個(gè)APP中Java文件讀寫(xiě)操作，工作原理如圖3所示。

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

6 系統(tǒng)實(shí)現(xiàn)

6.1 加密策略

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

6.2 獲取SharedUserId以及簽名信息

在Xposed模塊里可以通過(guò)handleLoadPackage傳遞進(jìn)來(lái)的參數(shù)獲取當(dāng)前應(yīng)用的名稱(chēng)，再通過(guò)Package-Manager獲取相關(guān)的SharedUserId。但再次之前需要獲取當(dāng)前的Context對(duì)象才行，但是通常Xposed的Hook模塊是在一個(gè)單獨(dú)的類(lèi)，本身沒(méi)有當(dāng)前程序的Context對(duì)象。所以需要Hook當(dāng)前APP的getApplicationContext方法，再保存其返回Context對(duì)象，相關(guān)代碼如下：

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());

}

…………

});

然后通過(guò)SharedUserId，簽名信息，以及主密鑰計(jì)算出加密該APP數(shù)據(jù)的實(shí)際密鑰。

圖4 加密策略

6.3 Hook相關(guān)方法

6.3.1 Hook文件操作的構(gòu)造方法

由于Java中與文件讀寫(xiě)相關(guān)的類(lèi)很多，這里以FileInputStream和FileOutputStream為例(下同)。Java中對(duì)文件操作沒(méi)有顯示的Open操作，實(shí)際上在FileInputStream之類(lèi)的構(gòu)造方法中會(huì)調(diào)用相關(guān)的Open函數(shù)，為此Hook相關(guān)構(gòu)造方法即可獲得與Hook open方法類(lèi)似的效果。

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

6.3.2 Hook read相關(guān)方法

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

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

6.3.3 Hook write相關(guān)方法

加密操作是在平文數(shù)據(jù)發(fā)送給實(shí)際write方法之前進(jìn)行，因此要實(shí)現(xiàn)XC_MethodHook中的beforeHookedMethod方法。具體實(shí)現(xiàn)與Hook read中所述類(lèi)似。此外write操作時(shí)要注意同步問(wèn)題，例如當(dāng)對(duì)象A以非追加的方式打開(kāi)并寫(xiě)入文件，相當(dāng)于清空數(shù)據(jù)，此時(shí)S-Box應(yīng)該復(fù)位，如果沒(méi)有同步機(jī)制的話(huà)，可能對(duì)象B正在通過(guò)之前計(jì)算的S-Box加密數(shù)據(jù)然后調(diào)用原生的write寫(xiě)入文件，導(dǎo)致使用錯(cuò)誤的S-Box加密數(shù)據(jù)。

6.3.4 Hook skip方法

skip方法用于在讀文件的過(guò)程中跳過(guò)一部分?jǐn)?shù)據(jù)，該系統(tǒng)實(shí)現(xiàn)beforeHookedMethod方法，由于skip(longn)不一定能跳過(guò)n個(gè)字節(jié)，所以要用原skip函數(shù)的返回值來(lái)更新index和S-Box。

6.3.5Hookclose方法

程序調(diào)用close方法后會(huì)釋放相關(guān)的文件資源，通過(guò)實(shí)現(xiàn)beforeHookedMethod方法，刪除index等自己創(chuàng)建的資源。

6.4 實(shí)驗(yàn)結(jié)果

該系統(tǒng)可以對(duì)Java層的應(yīng)用實(shí)現(xiàn)透明的文件加解密，保護(hù)數(shù)據(jù)安全。為測(cè)試該系統(tǒng)對(duì)Android讀寫(xiě)性能的影響，使用在一臺(tái)CPU為Exynos4210(雙核cpu 頻率1.5 GHz)的設(shè)備為實(shí)驗(yàn)平臺(tái)，對(duì)比使用透明加密與沒(méi)有使用透明加密時(shí)在性能上的區(qū)別。

實(shí)驗(yàn)結(jié)果如表2所示，加解密數(shù)據(jù)會(huì)對(duì)讀寫(xiě)性能

表2 透明加密對(duì)性能的影響 ms

造成一定的影響。但當(dāng)應(yīng)用不是頻繁讀寫(xiě)磁盤(pán)數(shù)據(jù)時(shí)，對(duì)使用者使用體驗(yàn)影響不明顯。

7 結(jié)束語(yǔ)

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

[1] 趙銘偉,毛 銳,江榮安.基于過(guò)濾驅(qū)動(dòng)的透明加密文件系統(tǒng)模型[J].計(jì)算機(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] 陳莉君,于運(yùn)超.基于LSM的輕量級(jí)透明加密設(shè)計(jì)與實(shí)現(xiàn)[J].西安郵電大學(xué)學(xué)報(bào),2014,19(1):78-81.

[4] 王全民,周 清,劉宇明,等.文件透明加密技術(shù)研究[J].計(jì)算機(jī)技術(shù)與發(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] 宋振華.虛擬化技術(shù)中的存儲(chǔ)管理問(wèn)題研究[D].合肥:中國(guó)科學(xué)技術(shù)大學(xué),2010.

[7] 艾 祝.基于iSCSI的數(shù)據(jù)完整性研究與實(shí)現(xiàn)[D].蘭州:蘭州大學(xué),2014.

[8] 吳 倩,趙晨嘯,郭 瑩.Android安全機(jī)制解析與應(yīng)用實(shí)踐[M].北京:機(jī)械工業(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].計(jì)算機(jī)技術(shù)與發(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] 吳文玲,馮登國(guó).分組密碼工作模式的研究現(xiàn)狀[J].計(jì)算機(jī)學(xué)報(bào),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

時(shí)間：2017-01-10

國(guó)家自然科學(xué)基金資助項(xiàng)目(61332010)

朱天楠(1988-)，男，碩士，研究方向?yàn)橐苿?dòng)設(shè)備安全。

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