朱天楠，施 勇，薛 質(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)

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

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

0 引 言

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

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

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

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

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

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

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

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

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

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

3 Xposed Hook原理

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

4 加密算法的選擇

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

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

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

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

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

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

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

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

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

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

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

圖1 ECB解密原理圖

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1 加密策略

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

6.2 獲取SharedUserId以及簽名信息

在Xposed模塊里可以通過handleLoadPackage傳遞進(jìn)來的參數(shù)獲取當(dāng)前應(yīng)用的名稱，再通過Package-Manager獲取相關(guān)的SharedUserId。但再次之前需要獲取當(dāng)前的Context對象才行，但是通常Xposed的Hook模塊是在一個單獨(dú)的類，本身沒有當(dāng)前程序的Context對象。所以需要Hook當(dāng)前APP的getApplicationContext方法，再保存其返回Context對象，相關(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());

}

…………

});

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

圖4 加密策略

6.3 Hook相關(guān)方法

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

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

在構(gòu)造方法中，首先判斷這個文件是否需要加密處理，如果需要的話在全局的HashMap中保存一個以構(gòu)造函數(shù)創(chuàng)建的對象為key，index為值的數(shù)據(jù)項(xiàng)。index表示目前創(chuàng)建的對象在文件中將要讀寫的偏移量，當(dāng)發(fā)現(xiàn)文件長度比index小時說明有進(jìn)程或其他對象對文件內(nèi)容做過刪減操作，當(dāng)前的S-Box需要更新，同時也用來輔助實(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)。其中，前兩種相對簡單，這里以第三種為例。

解密操作主要是在read方法從磁盤上讀到文件之后進(jìn)行的，因此需要實(shí)現(xiàn)XC_MethodHook中的afterHookedMethod方法。首先通過afterHookedMethod方法的參數(shù)param.thisObject得到實(shí)際調(diào)用read方法的對象，然后從全局HashMap中得到對應(yīng)的index值，在后續(xù)讀過程中按需復(fù)位S-Box。由于這個read方法是將讀取到的內(nèi)容保存到參數(shù)b數(shù)組中，因此還需要通過param.args獲取到該數(shù)組和對應(yīng)偏移量。雖然參數(shù)中有要讀取的長度信息len，但實(shí)際讀取的數(shù)據(jù)量可能比len要小，所以還要通過param.getResult()方法得到read的返回值即實(shí)際讀取到的數(shù)據(jù)大小。然后結(jié)合index，b，off，實(shí)際數(shù)據(jù)量，對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中所述類似。此外write操作時要注意同步問題，例如當(dāng)對象A以非追加的方式打開并寫入文件，相當(dāng)于清空數(shù)據(jù)，此時S-Box應(yīng)該復(fù)位，如果沒有同步機(jī)制的話，可能對象B正在通過之前計算的S-Box加密數(shù)據(jù)然后調(diào)用原生的write寫入文件，導(dǎo)致使用錯誤的S-Box加密數(shù)據(jù)。

6.3.4 Hook skip方法

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

6.3.5Hookclose方法

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

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

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

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

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

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

7 結(jié)束語

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

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

[4] 王全民,周 清,劉宇明,等.文件透明加密技術(shù)研究[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ù)中的存儲管理問題研究[D].合肥:中國科學(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ī)技術(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] 吳文玲,馮登國.分組密碼工作模式的研究現(xiàn)狀[J].計算機(jī)學(xué)報,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

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

朱天楠(1988-)，男，碩士，研究方向?yàn)橐苿釉O(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