一種Android平臺下高性能透明文件加密機制

胡煬,陶敬,2,劉林峰,李劍鋒,胡文君,梁肖

(1.西安交通大學(xué)智能網(wǎng)絡(luò)與網(wǎng)絡(luò)安全教育部重點實驗室,710049,西安;2.西安交通大學(xué)蘇州研究院,215123,江蘇蘇州)

?

一種Android平臺下高性能透明文件加密機制

胡煬1,陶敬1,2,劉林峰1,李劍鋒1,胡文君1,梁肖1

(1.西安交通大學(xué)智能網(wǎng)絡(luò)與網(wǎng)絡(luò)安全教育部重點實驗室,710049,西安;2.西安交通大學(xué)蘇州研究院,215123,江蘇蘇州)

針對Android平臺當(dāng)前采用的文件加密機制不能兼顧高安全性和高I/O性能的問題,提出了一種新型的基于映射表加密和物理塊加密的透明文件加密機制。該機制使用10輪AES-128塊加密算法加密文件的邏輯塊與物理塊的映射關(guān)系,使用改進(jìn)的7輪AES-128塊加密算法加密存儲文件數(shù)據(jù)的物理塊,從而在安全性和I/O性能之間尋求平衡。通過密碼學(xué)理論推導(dǎo)證明了該機制的密碼強度不低于Android平臺當(dāng)前采用的加密機制,通過I/O性能理論分析得出該機制的I/O性能優(yōu)于Android平臺當(dāng)前采用的文件加密機制。此外,在Google Nexus 4智能手機上分別對該機制和Android平臺當(dāng)前采用的文件加密機制進(jìn)行了108種不同測試條件下的I/O性能測試,測試結(jié)果驗證了I/O性能理論分析得出的結(jié)論,并且發(fā)現(xiàn):該機制的I/O寫入性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出13.12%,該機制的I/O讀取性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出16.16%。

文件加密機制;Android平臺;I/O性能

根據(jù)SandDroid惡意代碼分析平臺提供的惡意代碼數(shù)據(jù),近年Android平臺下的惡意代碼數(shù)量激增,對用戶手機上的私密信息構(gòu)成嚴(yán)重威脅[1]。對用戶私密信息進(jìn)行加密存儲是保護(hù)用戶隱私信息的有效手段。目前,Android平臺已構(gòu)建了一套基于磁盤加密機制dm-crypt的文件加密機制。然而,由于該機制需要在磁盤操作之前執(zhí)行大量的加密或解密指令,該機制會延長I/O操作的完成時間,從而嚴(yán)重降低I/O性能,增加系統(tǒng)響應(yīng)時間,嚴(yán)重影響移動設(shè)備的用戶體驗。針對該問題,文獻(xiàn)[2]通過簡化加密解密算法降低對I/O性能的影響,但算法已被破解[3]。文獻(xiàn)[4-5]通過引入可信芯片提升加密速度,從而降低對I/O性能的影響,但目前可信芯片技術(shù)尚不成熟[6],大多數(shù)移動設(shè)備沒有裝配此類芯片。文獻(xiàn)[7]通過調(diào)整I/O模式和策略提升I/O性能,實驗表明此類方法并不能顯著提升I/O性能。究其根源,加密機制的性能瓶頸在于加密與解密算法過于復(fù)雜,調(diào)整I/O模式和策略不能幫助移動設(shè)備跨越性能瓶頸的核心障礙。

通過深入探究Android平臺的文件系統(tǒng)工作原理,發(fā)現(xiàn)該文件系統(tǒng)通過特有的索引機制檢索文件數(shù)據(jù),這種索引機制會把文件包含的塊的邏輯地址和物理地址進(jìn)行關(guān)聯(lián),被稱為邏輯地址與物理地址的映射表,如果映射表被徹底打亂,那么文件的數(shù)據(jù)就很難按順序讀取或?qū)懭?因此可以通過加密映射表以提高攻擊者破解文件數(shù)據(jù)的難度。然而,僅僅保護(hù)映射表并不能徹底保護(hù)文件數(shù)據(jù)。這是因為:同一個文件中的數(shù)據(jù)常常有較強的上下文關(guān)聯(lián),即便攻擊者不知道映射表的具體內(nèi)容,也能夠根據(jù)數(shù)據(jù)間的上下文關(guān)聯(lián)分析出正確的數(shù)據(jù)組織順序。為了降低基于上下文關(guān)聯(lián)攻擊方法實施成功的可能性,應(yīng)當(dāng)在加密映射表的基礎(chǔ)上大幅減弱甚至消除數(shù)據(jù)間的上下文關(guān)聯(lián)。

基于上述觀點,提出了一種Android平臺下新型透明文件加密機制,即通過10輪AES-128加密算法[8]加密映射表并適時隨機交換物理塊中的數(shù)據(jù),通過改進(jìn)后的7輪AES-128加密算法[8]加密物理塊中的文件數(shù)據(jù)。這種雙層加密的設(shè)計思路不僅不會降低密碼強度,而且與Android當(dāng)前采用的透明文件加密機制相比減少了加密、解密時所需的計算量,從而減少了對I/O性能的影響。

1 透明文件加密機制的設(shè)計思路

1.1 透明文件加密機制的層次結(jié)構(gòu)

本文提出的文件加密機制依賴于Android平臺的文件系統(tǒng)。圖1展示了本文提出的加密機制和Android平臺的文件系統(tǒng)集成后組成的層次調(diào)用關(guān)系,灰色部分屬于本文提出的文件加密機制,白色部分屬于Android平臺的文件系統(tǒng)。本文提出的文件加密機制包括兩個層次:在圖1中的文件系統(tǒng)ext4之上引入映射表加解密層,負(fù)責(zé)維護(hù)、加密、解密文件邏輯地址與物理地址的映射表;在圖1中的文件系統(tǒng)ext4之下引入物理塊加解密層,負(fù)責(zé)對每個物理塊加密和解密。

圖1 本文提出的文件加密機制的層次結(jié)構(gòu)

1.2 映射表加解密層的原理與設(shè)計

映射表加解密層負(fù)責(zé)對映射表進(jìn)行加密和解密。映射表的作用是記錄邏輯塊和物理塊的映射關(guān)系,從而為文件操作提供檢索服務(wù)。圖2為映射表加密的原理示意圖,文件a.pdf和b.pdf分別按順序?qū)?yīng)若干邏輯塊,每個邏輯塊又對應(yīng)若干物理塊。映射表被加密后,文件系統(tǒng)將無法獲取其數(shù)據(jù)索引,文件系統(tǒng)就不能檢索到目標(biāo)物理塊中的數(shù)據(jù)。

圖2 映射表加解密原理

由于映射表所占存儲空間通常不超過文件數(shù)據(jù)所占存儲空間的0.5%,采用復(fù)雜的加密算法加解密映射表對I/O性能影響是微弱的,故應(yīng)采用較多輪的塊加密算法加解密映射表。本文提出的文件加密機制采用10輪AES-128塊加密算法[8]加解密該映射表。此外,由于文件系統(tǒng)在分配物理塊時往往會把地址臨近的物理塊分配給同一個文件,攻擊者可以利用該特性推測出映射表的部分內(nèi)容。為了阻斷這種攻擊模式,周期性地偽隨機挑選兩個存儲文件數(shù)據(jù)的物理塊并對換它們的數(shù)據(jù),對文件系統(tǒng)的物理塊分配算法進(jìn)行偽隨機化處理,即分配物理塊時待分配的物理塊被分配的概率基本相等。該機制采用ANSI X9.17算法[9]生成偽隨機串并用于物理塊對換和分配。

圖3展示了映射表加解密層的設(shè)計。當(dāng)用戶程序讀寫文件時,虛擬文件系統(tǒng)會向映射表加解密層發(fā)送文件操作請求;文件操作請求解析模塊會解析出該請求對應(yīng)文件的相關(guān)信息,生成控制命令,并把文件操作請求和控制命令發(fā)送給解密模塊;解密模塊會根據(jù)這些信息從下層的文件系統(tǒng)ext4獲取該文件對應(yīng)的映射表密文,解密映射表后得到映射表明文;最終映射表明文連同文件操作請求傳遞給下層文件系統(tǒng)ext4。

圖3 映射表加解密層的設(shè)計

當(dāng)文件操作請求為讀取請求時,映射表的內(nèi)容不變;當(dāng)文件操作請求為寫入操作時,映射表的內(nèi)容需要更新。文件系統(tǒng)ext4會向映射表加解密層發(fā)送映射表修改請求;受理該請求的模塊是映射表維護(hù)模塊,該模塊會從解密模塊獲得當(dāng)前文件操作的映射表明文,然后根據(jù)更新請求更新映射表并把更新后的映射表傳遞給加密模塊;加密模塊由加密更新后的映射表得到映射表的密文,并把密文傳遞給文件系統(tǒng)ext4;文件系統(tǒng)ext4會把映射表的密文同步到持久化存儲器上。

1.3 物理塊加解密層的設(shè)計

物理塊加解密層負(fù)責(zé)對物理塊中的數(shù)據(jù)進(jìn)行透明加密與解密。如圖4所示,當(dāng)文件系統(tǒng)ext4對某個物理塊進(jìn)行操作時,會向物理塊加解密層發(fā)送物理塊操作請求,物理塊操作請求分析模塊會分析該請求的類型。當(dāng)該請求的請求類型是寫入請求時,物理塊操作請求分析模塊會把請求中附帶的寫入數(shù)據(jù)明文后傳遞給加密模塊;加密模塊加密這些數(shù)據(jù)得到密文,并把密文傳遞給物理塊數(shù)據(jù)同步模塊;物理塊數(shù)據(jù)同步模塊會調(diào)用下層的驅(qū)動程序把密文寫入物理塊。當(dāng)該請求的請求類型是讀取請求時,物理塊操作請求分析模塊會把請求傳遞給物理塊數(shù)據(jù)提取模塊,該模塊根據(jù)請求內(nèi)容調(diào)用下層驅(qū)動程序提取物理塊的密文,然后把密文傳遞給解密模塊進(jìn)行解密;解密模塊把物理塊數(shù)據(jù)明文化并反饋給文件系統(tǒng)ext4。

圖4 物理塊加解密層的設(shè)計

由于映射表加解密層對映射表的有效保護(hù),攻擊者獲取物理塊明文密文對的難度提升,這使得物理塊加解密層抗選擇明文攻擊的能力大幅提升。在映射表加解密層的保護(hù)下,圖4中的加密模塊和解密模塊使用的加密算法可以適當(dāng)簡化,即在加密和解密物理塊時可以采用輪數(shù)較少的塊加密算法。然而,輪數(shù)較少會造成偽隨機化程度不足,上下文關(guān)聯(lián)可能會被攻擊者發(fā)現(xiàn)。為了解決該問題,本文在7輪AES-128塊加密算法[8]的基礎(chǔ)上增加一個偽隨機輪,并把該算法作為圖4中加密模塊和解密模塊的核心算法。偽隨機輪使用預(yù)先準(zhǔn)備好的偽隨機串按位異或AES-128塊加密算法[8]第4輪的輸出結(jié)果作為第5輪的輸入。該偽隨機串由ANSI X9.17算法[9]生成。

1.4 映射表加解密層在文件系統(tǒng)ext4中的實現(xiàn)與優(yōu)化

雖然映射表加解密層和文件系統(tǒng)ext4屬于兩個不同的層次,但是從上文描述的設(shè)計中可以看出,兩者交互頗為密切。因此,從高內(nèi)聚、低耦合的設(shè)計出發(fā),本文將映射表加解密層和文件系統(tǒng)ext4合并,即通過對文件系統(tǒng)ext4的改造實現(xiàn)映射表加解密層的全部功能。

在文件系統(tǒng)ext4中,每一個文件對應(yīng)一個被稱為ext4_inode的數(shù)據(jù)結(jié)構(gòu),其中有一個字段存放了在文件系統(tǒng)ext4中被稱為extent tree的根節(jié)點指針。extent tree是一棵索引樹,它存儲了對應(yīng)文件中所有塊的邏輯和物理地址的映射關(guān)系。對于文件系統(tǒng)ext4,extent tree相當(dāng)于上文提及的映射表。按照1.2節(jié)介紹的映射表加解密層的設(shè)計,應(yīng)當(dāng)加密全部映射表。然而,特殊的樹形結(jié)構(gòu)為性能優(yōu)化提供了空間,extent tree的葉節(jié)點存放了邏輯塊對應(yīng)的物理塊地址,而非葉節(jié)點不會存放這些內(nèi)容,只要加密全部葉節(jié)點就可以滿足設(shè)計要求。假設(shè)某extent tree有x個節(jié)點,其中y個節(jié)點是葉節(jié)點。對于樹形結(jié)構(gòu)而言,y通常小于x,這無疑減少了加密任務(wù)量。圖5是一個優(yōu)化示例,灰色節(jié)點表示需要被加密的節(jié)點,白色節(jié)點表示不需要加密的節(jié)點。在圖5中,優(yōu)化前需要加密9個節(jié)點,而優(yōu)化后只需要加密5個節(jié)點,加密的任務(wù)量減少了近一半。

圖5 extent tree加密優(yōu)化效果對比

2 I/O性能的理論分析與測試

2.1 密碼強度分析

密碼強度分析是為了衡量本文所提文件加密機制的安全性。通常采用破解所需的計算復(fù)雜度來衡量文件加密機制的安全性,破解所需的計算復(fù)雜度越高,安全性越好。Android平臺當(dāng)前使用的加密機制采用10輪AES-128塊加密算法[8],由于目前關(guān)于10輪AES-128塊加密算法[8]破解方法的計算復(fù)雜度為2126.1[10],故只要本文提出的文件加密機制被破解的計算復(fù)雜度達(dá)到甚至超過2126.1,就可以說明本文所提文件加密機制的安全性不低于Android平臺當(dāng)前使用的文件加密機制。

由有序四元組(A,M,N,S)表示圖1描述的文件加密機制,其中:A代表該加密機制采用的塊加密算法的類型;M代表映射表加密層使用加密算法的輪數(shù),M=0表示該加密機制沒有映射表加解密層;N代表物理塊加密層使用加密算法的輪數(shù),N=0表示該加密機制沒有物理塊加解密層;S代表持久化存儲的容量上限,單位為字節(jié)。

在上述規(guī)定下,Android平臺當(dāng)前采用的文件加密機制可以被近似表示為(AES-128,0,10,S),而本文所提加密機制可以被近似表示為(AES-128,10,7,S)。

為了說明(AES-128,10,7,S)的安全性,給出定理1并加以證明。

定理1當(dāng)A=1、N=7、S≥230時,加密機制(AES-128,M,N,S)被破解的計算復(fù)雜度不低于2126.1。

證明映射表加解密層采用10輪的AES-128塊加密算法[8],由文獻(xiàn)[10]可知,本文所提文件加密機制的映射表加解密層被破解的計算復(fù)雜度為2126.1。物理塊加解密層采用7輪的AES-128塊加密算法,由文獻(xiàn)[10]可知,目前最佳破解方法的計算復(fù)雜度為2116,然而破解條件是獲取若干明文密文對,由于每個物理塊的大小為512 B,故S≥230的塊設(shè)備存儲包含至少221個物理塊。又因映射表已被保護(hù),攻擊者難以根據(jù)物理塊密文判定其是否與選擇明文相對應(yīng),唯一的方法是遍歷所有物理塊,計算復(fù)雜度至少為221,破解物理塊加解密層的計算復(fù)雜度min(221+116,2128)=2128,因此本文所提加密機制被破解的計算復(fù)雜度min(2128,2126.1)=2126.1。

當(dāng)S≥230時,(AES-128,10,7,S)被破解的計算復(fù)雜度不低于(AES-128,0,10,S)的計算復(fù)雜度。S≥230在現(xiàn)實生活中容易滿足,現(xiàn)在大量的移動設(shè)備持久化存儲容量超過230B。因此,本文所提加密機制的安全性在現(xiàn)實生活中能夠得到保證。

2.2 I/O性能分析

I/O性能分析是為了從理論上分析本文所提文件加密機制的I/O性能優(yōu)于Android平臺當(dāng)前采用的文件加密機制,通常采用I/O操作中單位字節(jié)所要付出的時鐘周期或指令周期來衡量I/O性能。關(guān)于I/O性能給出定理2并加以證明。

定理2當(dāng)S≥230時,(AES-128,10,7,S)的I/O性能優(yōu)于(AES-128,0,10,S)的性能。

證明對于一個開啟加密機制的移動設(shè)備而言,I/O操作包含3部分內(nèi)容:磁盤操作和文件系統(tǒng)調(diào)度;映射表的加解密;物理塊的加解密。下面分別計算在讀寫一個物理塊時3部分所要付出的時鐘周期。

對于磁盤操作和文件系統(tǒng)調(diào)度,不妨假設(shè)磁盤操作和文件系統(tǒng)調(diào)度的單位字節(jié)所需的時鐘周期為c,則磁盤操作和文件系統(tǒng)調(diào)度需要消耗的時鐘周期為512c;對于物理塊的加解密,不妨假設(shè)AES-128塊加密算法[8]每一輪所需的時鐘周期為q。由于AES-128塊加密算法[8]的明文輸入大小為16 B,則對于文件加密機制(A,M,N,S),加解密一個物理塊消耗的時鐘周期為32Nq。對于映射表的加解密,一個物理塊僅對應(yīng)于extent tree的一個葉節(jié)點。因此,在讀寫一個物理塊時,映射表部分的加解密等價于對該物理塊對應(yīng)的葉節(jié)點進(jìn)行加解密。由文獻(xiàn)[11]知,Android平臺的文件系統(tǒng)中extent tree的葉節(jié)點大小為12 B,則對于文件加密機制(A,M,N,S),映射表加解密消耗的時鐘周期為32Mq/4。

因此,讀寫一個物理塊付出的時鐘周期總和為512c+32Nq+3Mq/4,需要被加解密的數(shù)據(jù)大小為524 B,文件加密機制(A,M,N,S)單位字節(jié)付出的時鐘周期為

128c/131+(8q/131)(3M/128+N)

(1)

由于8q/131和128c/131均為大于0的常數(shù),不影響大小比較,可以采用式(1)中的3M/128+N作為I/O性能比較指標(biāo),即對于任意加密機制(A,m,n,S)、(A,m*,n*,S),(A,m,n,S)的I/O性能優(yōu)于(A,m*,n*,S)的性能,當(dāng)且僅當(dāng)3m/128+n<3m*/128+n*。因此,定義加密機制(A,M,N,S)的I/O性能參數(shù)為

3M/128+N

(2)

根據(jù)式(2),(AES-128,10,7,S)的I/O性能參數(shù)為7.2,(AES-128,0,10,S)的性能參數(shù)為10.0。由于7.2<10.0,故(AES-128,10,7,S)的I/O性能優(yōu)于(AES-128,0,10,S)的性能。

2.3 I/O性能測試

本節(jié)將通過實驗來測量與評估所提文件加密機制和Android平臺當(dāng)前采用的文件加密機制對系統(tǒng)I/O性能的影響。

2.3.1 實驗設(shè)計 在Google Nexus 4智能手機上,使用iozone測試工具,測試不開啟任何文件加密機制的Android平臺、開啟Android平臺當(dāng)前所用文件加密機制的Android平臺、開啟本文所提文件加密機制的Android平臺這3組系統(tǒng)的I/O性能。

為了讓實驗?zāi)軌蚍从晨陀^規(guī)律,每組實驗需遵守如下測試條件:讀寫文件的大小分別為20MB,21MB,22MB,…,211MB;文件由若干條相同大小的記錄構(gòu)成,記錄的大小分別取22kB,23kB,24kB,…,210kB;避免使用內(nèi)核磁盤、C庫、Java文件緩存,且采用Direct I/O讀寫數(shù)據(jù)。此外,為了評估I/O性能,本文把I/O性能劃分為I/O寫入性能(又稱為文件寫入速度)和I/O讀取性能(又稱為文件讀取速度),并測量不同測試條件下分別開啟兩種文件加密機制時的文件寫入速度和文件讀取速度以及不開啟任何文件加密機制時的文件寫入速度和文件讀取速度。

2.3.2 實驗結(jié)果 由于大部分的I/O性能變化趨勢類似,故只展示部分典型的測試結(jié)果。圖6、7分別展示了文件大小為16 MB時的寫入和讀取速度,其中L表示記錄長度,單位為kB;R表示文件讀取速度,單位為MB/s;W表示文件寫入速度,單位為MB/s。由圖6、7可知:在記錄長度相等的情況下,開啟本文所提加密機制的Android平臺的文件寫入速度和文件讀取速度高于開啟Android平臺當(dāng)前采用的文件加密機制的Android平臺。

圖6 文件大小為16 MB時文件寫入速度與記錄長度的變化關(guān)系

圖7 文件大小為16 MB時文件讀取速度與記錄長度的變化關(guān)系

為了進(jìn)一步分析與對比兩種加密機制對I/O性能的影響,本文把相同測試條件下開啟加密機制的Android平臺的文件寫入速度與不開啟任何加密機制的Android平臺的文件寫入速度的比值作為衡量文件加密機制對系統(tǒng)I/O寫入性能的影響指標(biāo),把開啟加密機制的文件讀取速度與不開啟任何加密機制的文件讀取速度的比值作為衡量文件加密機制對系統(tǒng)I/O讀取性能的影響指標(biāo),這兩個性能指標(biāo)稱為I/O性能比率,取值范圍為[0,1]。I/O性能比率越大,加密文件系統(tǒng)對系統(tǒng)I/O的影響就越小。

為了減少噪聲對I/O性能比率的影響,采用數(shù)理統(tǒng)計中參數(shù)估計的方法求解文件加密系統(tǒng)的性能比率。本文用X1表示Android平臺當(dāng)前采用文件加密機制的I/O寫入性能比率,用X2表示本文所提的寫入性能比率,用Y1表示Android平臺當(dāng)前采用的讀取性能比率,用Y2表示本文所提的讀取性能比率。本文中X1、X2、Y1、Y2為隨機變量,且假設(shè)其服從正態(tài)分布。根據(jù)I/O性能比率的定義和實驗中測出的文件寫入、讀取速度,可以計算出X1、X2、Y1、Y2的觀察值。分別計算X1、X2、Y1、Y2的期望值E(X1)、E(X2)、E(Y1)、E(Y2)作為I/O性能比率的真值,用兩種文件加密機制的I/O性能比率期望值的差值E(X2)-E(X1)和E(Y2)-E(Y1)來衡量I/O性能的提升幅度。

圖8 I/O寫入性能比率分布

X1、X2、Y1、Y2的分布如圖8、9所示。其中,E(X2)-E(X1)=13.12%,E(Y2)-E(Y1)=16.16%。因此,本文所提文件加密機制的I/O寫入性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出13.12%,本文所提文件加密機制的讀取性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出16.16%。這些實驗結(jié)果充分說明了本文所提文件加密機制在I/O性能方面的優(yōu)勢。

圖9 I/O讀取性能比率分布

3 結(jié) 論

針對Android平臺當(dāng)前使用的文件加密機制不能兼顧高安全性和高I/O性能的問題,提出了一種基于映射表加解密和物理塊加解密的透明文件加密機制。本文詳細(xì)介紹了該文件加密機制的設(shè)計思路,從理論上證明了該機制的安全性不低于Android平臺當(dāng)前采用的文件加密機制,采用I/O性能理論分析得出了該機制在I/O性能上優(yōu)于Android平臺當(dāng)前采用的文件加密機制,通過在Google Nexus 4智能手機上分別對該機制和Android平臺當(dāng)前采用的文件加密機制進(jìn)行了108種I/O性能測試。測試結(jié)果驗證了I/O性能理論分析的結(jié)論,并且發(fā)現(xiàn):該機制的I/O寫入性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出13.12%,該機制的I/O讀取性能比率比Android平臺當(dāng)前采用的文件加密機制平均高出16.16%。

[1] 胡文君, 趙雙, 陶敬, 等. 一種針對Android平臺惡意代碼的檢測方法及系統(tǒng)實現(xiàn) [J]. 西安交通大學(xué)報, 2013, 47(10): 37-43. HU Wenjun, ZHAO Shuang, TAO Jing, et al. A detection method and system implementation for Android malware [J]. Journal of Xi’an Jiaotong University, 2013, 47(10): 37-43.

[2] CROWLEY P. Mercy: a fast large block cipher for disk sector encryption [C]∥Fast Software Encryption. Berlin, Germany: Springer, 2001: 49-63.

[3] FLUHRER S R. Cryptanalysis of the mercy block cipher [C]∥Fast Software Encryption. Berlin, Germany: Springer, 2002: 28-36.

[4] AGOSTA G, BARENGHI A, DE SANTIS F, et al. Fast disk encryption through GPGPU acceleration [C]∥International Conference on Parallel and Distributed Computing, Applications and Technologies. Piscataway, NJ, USA: IEEE, 2009: 102-109.

[5] LI Jun, YU Huiping. Trusted full disk encryption model based on TPM [C]∥2010 2nd International Conference on Information Science and Engineering. Piscataway, NJ, USA: IEEE, 2010: 1-4.

[6] LV Y Q, ZHOU Q, CAI Y C, et al. Trusted integrated circuits: the problem and challenges [J]. Journal of Computer Science and Technology, 2014, 29(5): 918-928.

[7] WANG Z, MURMURIA R, STAVROU A. Implementing and optimizing an encryption filesystem on Android [C]∥13th International Conference on Mobile Data Management. Piscataway, NJ, USA: IEEE, 2012: 52-62.

[8] DAEMEN J, RIJMEN V. The design of Rijndael: AES-the advanced encryption standard [M]. Berlin, Germany: Springer, 2013.

[9] DESAI A, YIN Y, HEVIA A. Enhanced ANSI X9.17 pseudorandom number generators with forward security: US 7, 227, 951 [P]. 2007-06-05.

[10]BOGDANOV A, KHOVRATOVICH D, RECHBERGER C. Advances in Cryptology-ASIACRYPT 2011[M]. Berlin, Germany: Springer, 2011: 344-371.

[11]MEDIA W. Ext4 disk layout [EB/OL]. [2015-05-21]. https: ∥ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout, 2014.

(編輯 趙煒)

A High-Performance Transparent File Encryption Mechanism on Android Platform

HU Yang1,TAO Jing1,2,LIU Linfeng1,LI Jianfeng1,HU Wenjun1,LIANG Xiao1

(1. Ministry of Education Key Lab for Intelligent Networks and Network Security, Xi’an Jiaotong University,Xi’an 710049, China; 2. Xi’an Jiaotong University Suzhou Academy, Suzhou, Jiangsu 215123, China)

It is regarded as a design defect that high I/O performance is not compatible to high security in the file encryption mechanism used nowadays in Android platform. To solve this problem, we presented a new transparent file encryption mechanism based on the mapping chart encryption and physical block encryption. It applies 10-round AES-128 block cipher algorithm to the mapping chart encryption and applies revised 7-round AES-128 block cipher algorithm to physical block encryption, which contributes to the balance between I/O performance and high security. Then we performed cryptanalysis and proved that the cipher strength of our mechanism is not lower than Android’s. In addition, we have conducted I/O performance theoretical analysis and concluded that the I/O performance of this mechanism is higher than Android’s. Moreover, we also performed 108 I/O performance tests in different test conditions on Google Nexus 4 smart phone. The result of these tests not only verifies the conclusion proved by I/O performance analysis, but also shows that the I/O writing performance of our mechanism is 13.12% higher than Android’s and the I/O reading performance is 16.16% higher than that of Android system.

file encryption mechanism; Android platform; I/O performance

10.7652/xjtuxb201603019

2015-06-04。 作者簡介:胡煬(1992—),男,碩士生;陶敬(通信作者),男,高級工程師。 基金項目:國家自然科學(xué)基金資助項目(91418205);江蘇省自然科學(xué)基金資助項目(SBK2014021758);蘇州應(yīng)用基礎(chǔ)研究計劃資助項目(SYG201311);江蘇省未來網(wǎng)絡(luò)創(chuàng)新研究院未來網(wǎng)絡(luò)前瞻性研究資助項目(BY2013095-4-13);江蘇省產(chǎn)學(xué)研聯(lián)合創(chuàng)新資金前瞻性聯(lián)合研究資助項目(BY2014074)。

時間:2015-12-28

http:∥www.cnki.net/kcms/detail/61.1069.T.20151228.1956.004.html

TP393

:A

:0253-987X(2016)03-0120-07