一种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