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

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

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

?

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

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

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

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

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

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

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

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

1 透明文件加密機制的設計思路

1.1 透明文件加密機制的層次結構

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

圖1 本文提出的文件加密機制的層次結構

1.2 映射表加解密層的原理與設計

映射表加解密層負責對映射表進行加密和解密。映射表的作用是記錄邏輯塊和物理塊的映射關系,從而為文件操作提供檢索服務。圖2為映射表加密的原理示意圖,文件a.pdf和b.pdf分別按順序對應若干邏輯塊,每個邏輯塊又對應若干物理塊。映射表被加密后,文件系統將無法獲取其數據索引,文件系統就不能檢索到目標物理塊中的數據。

圖2 映射表加解密原理

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

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

圖3 映射表加解密層的設計

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

1.3 物理塊加解密層的設計

物理塊加解密層負責對物理塊中的數據進行透明加密與解密。如圖4所示,當文件系統ext4對某個物理塊進行操作時,會向物理塊加解密層發送物理塊操作請求,物理塊操作請求分析模塊會分析該請求的類型。當該請求的請求類型是寫入請求時,物理塊操作請求分析模塊會把請求中附帶的寫入數據明文后傳遞給加密模塊;加密模塊加密這些數據得到密文,并把密文傳遞給物理塊數據同步模塊;物理塊數據同步模塊會調用下層的驅動程序把密文寫入物理塊。當該請求的請求類型是讀取請求時,物理塊操作請求分析模塊會把請求傳遞給物理塊數據提取模塊,該模塊根據請求內容調用下層驅動程序提取物理塊的密文,然后把密文傳遞給解密模塊進行解密;解密模塊把物理塊數據明文化并反饋給文件系統ext4。

圖4 物理塊加解密層的設計

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

1.4 映射表加解密層在文件系統ext4中的實現與優化

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

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

圖5 extent tree加密優化效果對比

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

2.1 密碼強度分析

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

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

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

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

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

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

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

2.2 I/O性能分析

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

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

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

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

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

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

(1)

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

3M/128+N

(2)

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

2.3 I/O性能測試

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

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

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

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

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

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

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

為了減少噪聲對I/O性能比率的影響,采用數理統計中參數估計的方法求解文件加密系統的性能比率。本文用X1表示Android平臺當前采用文件加密機制的I/O寫入性能比率,用X2表示本文所提的寫入性能比率,用Y1表示Android平臺當前采用的讀取性能比率,用Y2表示本文所提的讀取性能比率。本文中X1、X2、Y1、Y2為隨機變量,且假設其服從正態分布。根據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平臺當前采用的文件加密機制平均高出13.12%,本文所提文件加密機制的讀取性能比率比Android平臺當前采用的文件加密機制平均高出16.16%。這些實驗結果充分說明了本文所提文件加密機制在I/O性能方面的優勢。

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

3 結 論

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

[1] 胡文君, 趙雙, 陶敬, 等. 一種針對Android平臺惡意代碼的檢測方法及系統實現 [J]. 西安交通大學報, 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—),男,碩士生;陶敬(通信作者),男,高級工程師。 基金項目:國家自然科學基金資助項目(91418205);江蘇省自然科學基金資助項目(SBK2014021758);蘇州應用基礎研究計劃資助項目(SYG201311);江蘇省未來網絡創新研究院未來網絡前瞻性研究資助項目(BY2013095-4-13);江蘇省產學研聯合創新資金前瞻性聯合研究資助項目(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