基于Xposed的Android透明文件加密系统的研究

第２７卷第２期　

２０１７年２月　

计算机技术与发展　

ＣＯＭＰＵＴＥＲ　Ｉ．ＥＣＨＮＯＬＯＧＹ　ＡＮＤ　ＤＥＶＥＬＯＰＭＥＮＴ　

Ｖ０Ｉ．２７　Ｎｏ．２　

Ｆｅｂ．　２０１７　

基于Ｘｐｏｓｅｄ的Ａｎｄｒｏｉｄ透明文件加密系统的研究　

朱天楠　，施勇　，薛质　

（１．上海交通大学信息安全工程学院，上海２００２４０；　

２．上海市信息安全综合管理技术研究重点实验室，上海２００２４０）　

摘要：随着移动处理器技术水平的高速发展，智能设备的计算能力不断加强，人们对智能手机的依赖性也不断增加。通　

过安装各类应用，手机可以具有丰富的功能，但使用过程中往往会需要记录用户的隐私数据，保护存储在智能设备上的用　

户隐私数据不被恶意应用随意获取的需求日益加大。结合当前流行的透明文件加密技术与Ａｎｄｒｏｉｄ自身的一些特点，提　

出了一种基于Ｘｐｏｓｅｄ框架的透明文件加解密方案。其以ＳｈａｒｅｄＵｓｅｒＩｄ和开发者签名信息为标识自动生成密钥，将各个　

ＡＰＰ的数据以不同的密钥加密处理，这样即使在恶意ＡＰＰ获取到了Ｒｏｏｔ权限，仍能保护各ＡＰＰ的隐私数据不被非法获　

取，从而提升了Ａｎｄｒｏｉｄ设备的安全性。该过程自动完成，无需应用开发者和用户参与，无需改变开发与使用习惯。　

关键词：隐私安全；Ｘｐｏｓｅｄ框架；透明加密；Ａｎｄｒｏｉｄ　

中图分类号：Ｔｌｒ３０９　文献标识码：Ａ　文章编号：１６７３—６２９Ｘ（２０１７）０２一Ｏ０６４—０５　

ｄｏｉ：１０．３９６９／ｊ．ｉｓｓｎ．１６７３—６２９Ｘ．２０１７．０２．０１５　

Ｒｅｓｅａｒｃｈ　ｏｎ　Ａｎｄｒｏｉｄ　Ｔｒａｎｓｐａｒｅｎｔ　Ｅｎｃｒｙｐｔｉｏｎ　Ｆｉｌｅ　Ｓｙｓｔｅｍ　

Ｂａｓｅｄ　ｏｎ　Ｘｐｏｓｅｄ　

ＺＨＵ　Ｔｉａｎ—ｎａｎ　，ＳＨＩ　Ｙｏｎｇ　，ＸＵＥ　Ｚｈｉ　，　

（１．Ｃｏｌｌｅｇｅ　ｏｆ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｃｕｒｉｔｙ　ａｎｄ　Ｅｎｇｉｎｅｅｒｉｎｇ，Ｓｈａｎｇｈａｉ　Ｊｉａｏｔｏｎｇ　Ｕｎｉｖｅｒｓｉｔｙ，Ｓｈａｎｇｈａｉ　２００２４０，Ｃｈｉｎａ；　

２．Ｓｈａｎｇｈａｉ　Ｋｅｙ　Ｌａｂｏｒａｔｏｒｙ　ｏｆ　Ｉｎｔｅｇｒａｔｅｄ　Ａｄｍｉｎｉｓｔｒａｔｉｏｎ　Ｔｅｃｈｎｏｌｏｇｉｅｓ　ｆｏｒ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｃｕｒｉｙ，ｔＳｈａｎｇｈａｉ　２００２４０，Ｃｈｉｎａ）　

Ａｂｓｔｒａｃｔ：Ｗｉｔｈ　ｔｈｅ　ｃｏｎｓｔａｎｔ　ｐｒｏｇｒｅｓｓ　ｏｆ　ＳＯＣ　ｔｅｃｈｎｏｌｏｇｙ，ｍｏｂｉｌｅ　ｄｅｖｉｃｅｓ　ａｔｅ　ｍｏｒｅ　ａｎｄ　ｍｏｒｅ　ｐｏｗｅｒｆｕｌ，ａｎｄ　ｈｅ　ｐｅｏｐｌｔｅ　ｒｅｌｉｅｓ　ｉｎｃｒｅａｓｉｎｇｌｙ　

ｏｎ　ｔｈｅｍ．Ｒｉｃｈｅｒ　ａｐｐｌｉｃａｔｉｏｎｓ　ｅｎｈａｎｃｅ　ｔｈｅ　ｃａｐａｂｉｌｉｔｙ　ｏｆ　ｍｏｂｉｌｅ　ｄｅｖｉｃｅｓ，ｂｕｔ　ｍａｌｉｃｉｏｕｓ　ＡＰＰ　ｗｈｉｃｈ　ａｉｍ　ｔＯ　ｓｔｅａｌ　ｕｓｅｒｓ’ｐｒｉｖａｔｅ　ｉｎｆｏｒｍａｔｉｏｎ　

ａｌｅ　ａｌｓｏ　ｓｐｎｎｇ　ｕｐ．Ｔｏ　ｐｍｔｅｃｔ　ｕｓｅｒｓ’ｐｒｉｖａｃｙ，ａｌｌ　ｅｎｃｒｙｐｔｅｄ　ｏｎ－ｔｈｅ—ｆｌｙ　ｓｏｌｕｔｉｏｎ　ｂａｓｅｄ　ｏｎ　Ｘｐｏｓｅｄ　ｉｓ　ｐｒｏｐｏｓｅｄ　ｗｈｉｃｈ　ｉｓ　ｃｏｍｂｉｎａｔｉｏｎ　ｏｆ　ａ　

ｐｏｐｕｌａｒＨｏｏｋｆｒａｍｅｗｏｒｋ　ｏｎＡｎｄｒｏｉｄ．Ｔｈｉｓ　ｓｏｌｕｔｉｏｎ　ｕｓｅｓ　ＳｈａｒｅｄＵｓｅｒｌｄ　ａｎｄ　ｄｅｖｅｌｏｐｅｒ’Ｓ　ｓｉｇｎａｔｕｒｅ　ａｓｉｄｅｎｔｉｙ￡ｔ０　ｃａｌｃｕｌａｔｅｔｈｅ　ｓｅｃｒｅｔ　ｋｅｙｆｏｒ　

ｅｎｃｒｙｐｔｉｏｎ，ＳＯ　ｔｈａｔ　ｅｖｅｒｙ　ｄｉｆｆｅｒｅｎｔ　ＡＰＰ　ｈａｓ　ａ　ｉｆｅｒｅｎｔｄ　ｋｅｙ．Ｈｅｎｃｅ　ｅｖｅｎ　ｔｈｅ　ｍａｌｉｃｉｏｕｓ　ａｐｐ　ｉｎｎｓ　ａｓ　ｒｏｏｔ　ｕｓｅｒ。ｉｔ　ｓｔｉｌｌ　ｃａｎｎｏｔ　ｏｂｔａｉｎ　ｏｔｈｅｒ　ＡＰＰ　

ｐｒｉｖａｔｅ　ｄａｔａ　ｗｈｉｃｈ　ｉｍｐｒｏｖｅｓ　ｔｈｅ　ｓｅｃｕｒｉｔｙ　ｏｆ　Ａｎｄｒｏｉｄ　ｄｅｖｉｃｅｓ．Ｔｈｅ　ｐｒｏｃｅｓｓ　ｉｓ　ｄｏｎｅ　ａｕｔｏｍａｔｉｃａｌｌｙ．ｗｉｈｏｕｔｔ　ａｐｐｌｉｃａｔｉｏｎ　ｄｅｖｅｌｏｐｅｒｓ　ａｎｄ　ｕｓｅｆｓ　

ｔｏ　ｐａｒｔｉｃｉｐａｔｅ　ｉｎ，ｄｏｎ’ｔ　ｎｅｅｄ　ｔｏ　ｃｈａｎｇｅ　ｔｈｅ　ｈａｂｉｔ　ｏｆ　ｄｅｖｅｌｏｐｍｅｎｔ　ａｎｄ　ｕｓｅ．　

Ｋｅｙ　ｗｏｒｄｓ：ｐｒｉｖａｃｙ　ｓｅｃｕｒｉｔｙ；Ｘｐｏｓｅｄ；ｅｎｃｒｙｐｔ　ｏｎ－ｔｈｅ－ｆｌｙ；Ａｎｄｒｏｉｄ　

Ｏ　引　言　

随着智能手机的普及，人们对手机的依赖不断加　

大。各种ＡＰＰ出于功能上的需求会悄悄在手机上存　

储各种数据文件，其中可能会包含使用者的隐私信息，　

加密技术无疑是保护这类数据的有效方式。透明文件　

加密技术多年的发展表明，这是一种较好的隐私保护　

安全机制。　

开文件时，将磁盘上的密文解密到一个临时的隐藏文　

件中，然后将隐藏文件返回给应用，用户对文件的修改　

会反馈到隐藏文件中，当关闭文件时系统再将隐藏文　

件整体加密，替换磁盘上原先的密文，最后删除掉隐藏　

文件。这种静态加密的方法实现简单，但是每次都要　

对整个文件做加密解密操作，整体效率较低，同时隐藏　

文件的出现对整体安全性构成威胁…。内核态的加密　

系统有的通过堆栈式文件系统在ＶＦＳ与底层操作之　

间完成加解密　，也有通过ＬＳＭ框架Ｈｏｏｋ相关内核　

透明文件加密技术按实现的位置可以分为用户态　

的实现与内核态实现。早期用户态的透明加密主要是　

通过钩子函数来Ｈｏｏｋ文件打开与关闭的操作，在打　

收稿日期：２０１５—０８－１５　修回日期：２０１６—０１—０５　

函数　等实现方法，内核态的加密技术在速度与稳定　

网络出版时间：２０１７一Ｏｌ—ｌＯ　

基金项目：国家自然科学基金资助项目（６１３３２０１０）　

作者简介：朱天楠（１９８８一），男，硕士，研究方向为移动设备安全。　

网络出版地址：ｈｔｔｐ：／／ｗｗｗ．ｃｎｋｉ．ｎｅｔ／ｋｃｍｓ／ｄｅｔａｉｌ／６１．１４５０．ＴＰ．２０１７０１１０．１０１０．０２４．ｈｔｍｌ　

第２期　朱天楠等：基于Ｘｐｏｓｅｄ的Ａｎｄｒｏｉｄ透明文件加密系统的研究　’６５・　

性上具有优势　］，但是出于安全性考虑，目前有些Ａｎ—　

ｄｒｏｉｄ移动设备不具备动态加载驱动模块的功能。这　

将使得内核态的加密技术难以在现有设备上推广。　

由于移动处理器性能增速远快于磁盘性能的增　

长，用户态上的加密技术对性能影响的权重将会逐渐　

减少。同时文中使用ＳｈａｒｅｄＵｓｅｒｌｄ和ＡＰＰ的签名作为　

标识来选取密钥，而从Ａｎｄｒｏｉｄ上层获取这些信息比　

较方便。因此，使用Ｘｐｏｓｅｄ框架来实现用户态的动态　

透明文件加解密系统。该系统能够自动为各个应用生　

成不同的加密密钥，并加密数据。整个过程都对用户　

与开发者透明。　

ｌ现有Ａｎｄｒｏｉｄ平台的数据安全服务　

在数据加密方面：自Ａｎｄｒｏｉｄ３．０之后，谷歌通过　

ｄｅｉｖｃｅ—ｍａｐｐｅｒ提供了磁盘加密机制ｄｍ—ｃｒｙｐｔ　，　

ｄｅｉｖｅｅ—ｍａｐｐｅｒ是Ｌｉｎｕｘ中的一个框架，Ｌｉｎｕｘ中的　

ＲＡＩＤ、ＬＶＭ等功能都基于该框架。它可以将一个虚拟　

的块设备映射到一个或多个实际的物理设备，在映射　

过程中，可以对交互的数据进行修改　。该技术在　

Ａｎｄｒｏｉｄ中可以用于全盘加密。下文提到的磁盘数据校　

验中也依赖该框架。　

ｄｍ—ｃｒｙｐｔ磁盘加密技术主要是对整个分区，例如　

把／ｄａｔａ对应的分区进行加密，在系统启动时ｉｎｉｔ进程　

通过挂载／ｄａｔａ目录来判断磁盘是否加密。如果分区　

加密则会提示用户输入密码，并重启Ａｎｄｒｏｉｄ　ｆｒａｍｅ．　

ｗｏｒｋ，重新挂载分区。这种方式控制粒度较粗，一旦解　

密，所有ＡＰＰ都能像以前一样访问／ｄａｔａ目录，因此无　

法防止恶意ＡＰＰ获取其他ＡＰＰ的私有数据。　

在数据完整性方面：为了应对ＲｏｏｔＫｉｔ等攻击，Ａｎ．　

ｄｒｏｉｄ在４．４中引入了Ｖｅｒｉｉｆｅｄ　Ｂｏｏｔ机制来保证启动磁　

盘的完整性，其基于Ｌｉｎｕｘ内核ｄｍ—ｖｅｒｉｔｙ（ｄｅｖｉｃｅ—ｍａｐ—　

ｐｅｒ－ｖｅｒｉｔｙ，３．４版加入到Ｌｉｎｕｘ中）机制。在启动过程　

中会对块设备进行完整性校验。校验过程中使用的　

ＲＳＡ公钥存储在启动分区中。校验出错将会返回Ｉ／Ｏ　

异常。ｄｍ—ｖｅｒｉｔｙ通过构建一个多叉树状结构来保存　

对应分区中所有块的哈希值，这棵树的叶子节点表示　

物理设备上各块的哈希值，中间节点保存其子节点的　

哈希值，这样物理设备上任何数据的变化都将导致该　

树子节点哈希值的变化，同时这个变化会影响到其所　

有祖先节点，最终改变根节点的哈希值。这样只需比　

较根节点的哈希值就可以知道数据是否被篡改　。相　

较于Ｉ／Ｏ操作，哈希计算所造成的迟延不是十分明显。　

ｄｉｎ－ｖｅｒｉｔｙ对磁盘所进行的校验工作是由Ｌｉｎｕｘ内核完　

成的，因此首先需要保证Ｌｉｎｕｘ内核的完整性，防止其　

被篡改。通常移动设备制造商会在一块物理存储设备　

上固化一把校验密钥，在设备启动时可以通过Ｔｒｕｓｔ．　

Ｚｏｎｅ技术首先使用这把密钥校验ｂｏｏｔｌｏａｄｅｒ和ｋｅｒｎｅｌ　

的完整性。由于在可写的情况下，如磁盘挂载时间一　

类的元数据都将被系统修改，因此该技术要求被保护　

的磁盘只能以只读的方式挂载，Ａｎｄｒｏｉｄ中主要用来保　

护／ｓｙｓｔｅｍ分区，而／ｄｍａ以及外部存储设备这种本身　

就会被不断修改的分区将无法获得保护。　

在数据访问控制方面：Ａｎｄｒｏｉｄ继承并发展了传统　

Ｌｉｎｕｘ下的访问控制机制，将传统Ｌｉｎｕｘ下的用户的概　

念应用到ＡＰＰ上。ＵＩＤ不再代表手机使用者，而是用　

来区分各个ＡＰＰ，每一个ＡＰＰ获得一个ＵＩＤ，这样传统　

Ｌｉｎｕｘ在对用户的“读一写一执行”权限控制机制就顺利　

地延续到了ＡＰＰ上　。同时组的概念用来分配系统　

资源，ＡＰＰ要访问系统资源例如网络、摄像头、外部存　

储等，需要加入相应的组。通过这种机制各个ＡＰＰ自　

己的数据（主要指／ｄａｔａ／ｄａｔａ／下的数据）相互隔离开　

来。但是一旦恶意应用获取到ｒｏｏｔ权限，还是可以访　

问其他应用的数据。　

２应用标识的选取　

为了实现各ＡＰＰ的数据使用不同的密钥加密，就　

需要选取一个合适的标识，来区分哪些ＡＰＰ不能共享　

数据。Ａｎｄｒｏｉｄ应用的ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ中有一个　

称为ＳｈａｒｅｄＵｓｅｒＩｄ的标识符（没定义的话为空）。对于　

具有相同的ＳｈａｒｅｄＵｓｅｒｌｄ，并使用相同的开发者证书签　

名的应用可以相互访问各自私有数据　。Ａｎｄｒｏｉｄ系　

统在安装应用时，如果有多个具有相同ＳｈａｒｅｄＵｓｅｒＩｄ　

但证书不同的ＡＰＰ，只有最初的那一个能安装成功。　

因此选取ＳｈａｒｅｄＵｓｅｒＩｄ与开发者的证书信息作为标识　

符合该系统的需求。　

３　Ｘｐｏｓｅｄ　Ｈｏｏｋ原理　

在Ａｎｄｒｏｉｄ中，所有的ＡＰＰ进程都通过Ｚｙｇｏｔｅ进　

程创建。Ｚｙｇｏｔｅ在启动过程中会加载部分资源，这样　

通过其创建的所有ＡＰＰ都将继承这些资源，而无需重　

新加载，从而减少了启动时间。Ｚｙｇｏｔｅ进程实际上是　

在系统启动过程中／ｓｙｓｔｅｍ／ｂｉｎ／ａｐｐ—ｐｒｏｃｅｓｓ程序通过　

系统调用更换名称得到的　，为此，Ｘｐｏｓｅｄ将自己定　

制的ａｐｐ＿ｐｒｏｃｅｓｓ替换到目标设备中（需要ｒｏｏｔ权限），　

通过Ｈｏｏｋ　Ｚｙｇｏｔｅ，从而达到Ｈｏｏｋ所有ＡＰＰ的目的。　

Ｘｐｏｓｅｄ在这个定制的ａｐｐ—ｐｒｏｃｅｓｓ中添加了Ｘｐｏｓｅｄ．　

Ｂｒｉｄｇｅ．ｊａｒ库文件，系统会将需要Ｈｏｏｋ的方法指向　

ＸｐｏｓｅｄＢｒｉｄｇｅ中的本地方法ｘｐｏｓｅｄＣａｌ１Ｈａｎｄｌｅｒ，而后　

ｘｐｏｓｅｄＣａｌｌＨａｎｄｌｅｒ会调用ｈａｎｄｌｅＨｏｏｋｅｄＭｅｔｈｏｄ来回调　

对应的ｂｅｆｏｒｅＨｏｏｋｅｄＭｅｔｈｏｄ和ａｆｔｅｒＨｏｏｋｅｄＭｅｔｈｏｄ（分别　

在被Ｈｏｏｋ方法前后调用），在这两种方法中可以修改　

传给被Ｈｏｏｋ方法的参数及其返回值。　

・

６６・　计算机技术与发展　第２７卷　

４加密算法的选择　

现代加密算法按照加解密密钥的类型可以分为对　

称加密与非对称加密两大类　。由于非对称加密算　

法计算量相对较大，出于性能上的考虑，该系统采用对　

称加密算法。对称加密技术又可分为块加密与流加密　

技术。文中通过对比常见的ＤＥＳ、ＡＥＳ、ＲＣＡ来选取适　

合的方案。　

ＤＥＳ（Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）是一种块加密算　

法，它每次使用６４　ｂｉｔ的密钥（除去校验位实际只有５６　

ｂｉｔ），以６４　ｂｉｔ（８字节）数据为单位加密数据，加密后　

的密文块也是６４位。　

ＡＥＳ（Ａｄｖａｎｃｅｄ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）又称为Ｒｉｊｎ—　

ｄａｅｌ算法，它使用的数据分组长度为１２８　ｂｉｔ，密钥长度　

可以为１２８／１９２／２５６　ｂｉｔ　。　

ＲＣ４是一种密钥长度可变的流加密算法　引，该算　

法实现十分简单。通过密钥来初始化一个大小为２　

的ｓ—Ｂｏｘ（ｎ一般为８），在对明文进行加密的同时，ｓ—　

Ｂｏｘ也在不断变化，这样即使出现相同字符，解密结果　

也不一定相同。作为流加密算法，可以使得密文长度　

与明文长度相同。　

４．１从安全性角度进行比较　

暴力破解作为最直接的攻击方法，适用于各种加　

密算法。因此保证数据在一定时间内难以破解是评估　

密码算法的一项重要指标。相比于ＲＣ４和ＡＥＳ，默认　

的ＤＥＳ算法密钥有效长度只有５６　ｂｉｔ，较易被攻击¨　。　

２００６年，鲁尔大学与基尔大学用ＦＰＧＡ开发出硬件破　

解设备ＣＯＰＡＣＯＢＡＮＡ，它主要针对６４位以内的密钥　

进行暴力破解。２００７年，该设备平均６．４天就可以破　

解一个ＤＥＳ密钥　。相对来说，ＡＥＳ和ＲＣ４的密钥　

所对应的空间要远远高于标准的ＤＥＳ算法，暴力破解　

成本较高。　

４．２从加密前后数据长度变化角度进行比较　

块加密算法，一般都是一次对固定长度ｎ的平文　

进行加密操作得到密文。ＤＥＳ算法每块数据长度为８　

个字节，加密后得到８个字节密文，ＡＥＳ算法一般使用　

１６字节的平文数据块，加密后得到１６字节密文。使　

用块加密方法如果平文长度不足ｎ，一般会进行填充　

操作，从而使得加解密前后数据长度发生变化。而如　

ＲＣ４这样的流加密算法，可以每次以一个字节为单位　

进行加密处理，不会改变数据长度。　

４．３从误差传播角度进行比较　

存储介质在使用过程中都会渐渐出现数据的损　

坏，因此，在设计透明文件系统时就需要考虑存储介质　

上一个存储单位的损坏会对解密后明文的结果造成的　

影响。　

块加密的工作方式有多种，如ＥＣＢ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏ—　

ｄｅＢｏｏｋ）、ＣＢＣ（Ｃｉｐｈｅｒ　Ｂｌｏｃｋ　Ｃｈａｉｎｉｎｇ）、ＰＣＢＣ（Ｐｒｏｐａｇａ．　

ｔｉｎｇ　Ｃｉｐｈｅｒ－Ｂｌｏｃｋ　Ｃｈａｉｎｉｎｇ）、ＣＦＢ（Ｃｉｐｈｅｒ—ＦｅｅｄＢａｃｋ）、　

ＯＦＢ（Ｏｕｔｐｕｔ－ＦｅｅｄＢａｃｋ）等　。其中ＥＣＢ最为简单，　

其工作原理如图１所示。使用同一把密钥分别对各块　

数据进行加密，各块数据相互独立。因此，磁盘上密文　

的损坏只会影响到其所在的数据块，不会将这种影响　

扩散到其他数据块中。　

同一把　

密钥Ｋ　

图１　ＥＣＢ解密原理图　

ＣＢＣ和简单的ＣＦＢ在解密过程中都是用前一块　

密文作为初始化向量参与到解密过程中，因此一个字　

节的损坏会影响到自己以及后一块数据的解密，对其　

他数据没有影响。ＣＦＢ解密过程如图２所示。　

图２　ＣＦＢ解密数据原理图　

ＰＣＢＣ这种方式下密文中出现的误差能够尽可能　

影响到后续结果，这与透明文件加密的需求不符。　

ＯＦＢ可以让密文与平文同一位置的数据位同时　

翻转。这个特性利于奇偶校验，密文出错时，在解密前　

就可以验证出问题。但一位数据的损坏，同样会造成　

一

个数据块的解密失败。　

ＲＣ４算法在解密过程中Ｓ—Ｂｏｘ可以不受密文或平　

文的影响，存储介质上一　个字节的损坏不会影响到其　

他字节。　

４．４从数据加解密速度进行比较　

为了比较三种加密算法的加解密速度，使用一台　

配备Ｅｘｙｎｏｓ４２１０（双核频率１．５　ＧＨｚ）ＣＰＵ的Ａｎｄｒｏｉｄ　

设备，分别处理１　ｋ，１０　ｋ，１００　ｋ，１　Ｍ，１０　Ｍ数据，测量　

消耗时间。其中ＤＥＳ和ＡＥＳ使用Ｊａｖａ中自带库来实　

现（使用ＥＣＢ／ＰＫＣＳ５Ｐａｄｄｉｎｇ），ＲＣ４实现简单，实验中　

自己实现相关加解密函数，得到的结果如表１所示。　

综合上述结果，选取ＲＣ４算法实现透明文件加密　

系统。由于ＲＣＡ的Ｓ－Ｂｏｘ随着加密过程不断变化，如　

果要往一个长度为ｎ的文件追加内容，首先需要对ｓ一　

第２期　朱天楠等：基于Ｘｐｏｓｅｄ的Ａｎｄｒｏｉｄ透明文件加密系统的研究　‘６７。　

Ｂｏｘ的初始化进行ｎ次变换。在处理较大文件时效率　

低，也无法发挥多核ＣＰＵ的优势。为此，以４　ｋ为单位　

划分文件数据，每到４　ｋ数据就将Ｓ－Ｂｏｘ复位，这样每　

４ｋ数据相互独立，可以多线程处理。　

表１　各加密算法在实验平台上的性能测试ｍｓ　

５系统整体框架　

系统采用应用中的ＳｈａｒｅｄＵｓｅｒｌｄ以及对应的签名　

信息作为ＡＰＰ的标识，通过主密钥加密处理后，得到　

加解密数据的实际密钥。这样ＡＰＰ无法访问通过其　

他标识加密的数据，可以在不影响用户与原有应用的　

情况下为系统提供透明的文件加密服务。其中数据加　

解密功能是通过Ｘｐｏｓｅｄ框架来Ｈｏｏｋ各个ＡＰＰ中Ｊａｖａ　

文件读写操作，工作原理如图３所示。　

图３透明文件加密工作原理图　

６　系统实现　

６．１加密策略　

从Ａｎｄｒｏｉｄ设计的角度来看，其对各个ＡＰＰ数据　

访问的限制都是针对内部存储的，因此一般开发者默　

认将私有的数据保存在自己的存储区中，将共享的或　

无需加密的数据放在外部存储空间中，因此系统默认　

为应用在／ｄａｔａ／ｄａｔａ下的文件提供加解密服务，采用由　

如图４所示的加密策略。　

６．２获取ＳｈａｒｅｄＵｓｅｒｌｄ以及签名信息　

在Ｘｐｏｓｅｄ模块里可以通过ｈａｎｄｌｅＬｏａｄＰａｃｋａｇｅ传　

递进来的参数获取当前应用的名称，再通过Ｐａｃｋａｇｅ—　

Ｍａｎａｇｅｒ获取相关的ＳｈａｒｅｄＵｓｅｒｌｄ。但再次之前需要获　

取当前的Ｃｏｎｔｅｘｔ对象才行，但是通常Ｘｐｏｓｅｄ的Ｈｏｏｋ　

模块是在一个单独的类，本身没有当前程序的Ｃｏｎｔｅｘｔ　

对象。所以需要Ｈｏｏｋ当前ＡＰＰ的ｇｅｔＡｐｐｌｉｃａｔｉｏｎＣｏｎ．　

ｔｅｘｔ方法，再保存其返回Ｃｏｎｔｅｘｔ对象，相关代码如下：　

ｉｆｎｄＡｎｄＨｏｏｋＭｅｔｈｏｄ（”ａｎｄｒｏｉｄ．ｃｏｎｔｅｎｔ．ＣｏｎｔｅｘｔＷｒａｐｐｅｒ”．１ｐ—　

ｐａｒａｍ．ｃｌａｓｓＬｏａｄｅｒ，”ｇｅｔＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ”，ｎｅｗ　ＸＣ

—

ＭｅｔｈｏｄＨｏｏｋ　

（））　

｛　

ｐｒｏｔｅｃｔｅｄ　ｖｏｉｄ　ａｆｔｅｒＨｏｏｋｅｄＭｅｔｈｏｄ（ＭｅｔｈｏｄＨｏｏｋＰａｍｍ　ｐａｒａｍ）　

ｔｈｒｏｗｓ　Ｔｈｒｏｗａｂｌｅ｛　

ｓｔｏｒｅｄＣｏｎｔｅｘｔ＝（Ｃｏｎｔｅｘｔ）ｐａｒａｍ．ｇｅｔＲｅｓｕｈ（）；　

ｉｆ（ｐｌｎｆｏ．ｐａｃｋａｇｅＮａｍｅ．ｅｑｕａｌｓ（ｐａｃｋａｇｅＮａｍｅ））｛　

ｓｈａｒｅｄＵｓｅｒＩｄ＝ｐｌｎｆｏ．ｓｈａｒｅｄＵｓｅｒｌｄ；　

ｓｉｇｎａｔｕｒｅ＝ｐｌｎｆｏ．ｓｉｎｇａｔｕｒｅｓ［０］．ｔｏＣｈａｒｓＳｔｒｉｎｇ（））；　

｝　

｝）；　

然后通过ＳｈａｒｅｄＵｓｅｒｌｄ，签名信息，以及主密钥计　

算出加密该ＡＰＰ数据的实际密钥。　

匿　

ｅｎｃｒｙｐｔＩｎｎ

匪　≤　

：作在文件打开Ａ阶段／，——：　ｌ＿＝『’、、

．　

图４加密策略　

６．３　Ｈｏｏｋ相关方法　

６．３．１　Ｈｏｏｋ文件操作的构造方法　

由于Ｊａｖａ中与文件读写相关的类很多，这里以　

ＦｉｌｅＩｎｐｕｔＳｔｒｅａｍ和ＦｉｌｅＯｕｔｐｕｔＳｔｒｅａｍ为例（下同）。Ｊａｖａ　

中对文件操作没有显示的Ｏｐｅｎ操作，实际上在ＦｉｌｅＩｎ－　

ｐｕｔＳｔｒｅａｍ之类的构造方法中会调用相关的Ｏｐｅｎ函　

数，为此Ｈｏｏｋ相关构造方法即可获得与Ｈｏｏｋ　ｏｐｅｎ方　

法类似的效果。　

在构造方法中，首先判断这个文件是否需要加密　

处理，如果需要的话在全局的ＨａｓｈＭａｐ中保存一个以　

构造函数创建的对象为ｋｅｙ，ｉｎｄｅｘ为值的数据项。　

ｉｎｄｅｘ表示目前创建的对象在文件中将要读写的偏移　

量，当发现文件长度比ｉｎｄｅｘ小时说明有进程或其他　

对象对文件内容做过删减操作，当前的Ｓ—Ｂｏｘ需要更　

新，同时也用来辅助实现按４ｋ分割数据复位ｓ—Ｂｏｘ的　

功能。　

６．３．２　Ｈｏｏｋ　ｒｅａｄ相关方法　

ＦｉｌｅｌｎｐｕｔＳｔｒｅａｍ的ｒｅａｄ相关方法主要有ｒｅａｄ（），　

・

６８・　计算机技术与发展　第２７卷　

ｒｅａｄ（ｂｙｔｅ　ｂ［］），ｒｅａｄ（ｂｙｔｅ　ｂ［］，ｉｎｔ　ｏｆｆ，ｉｎｔ　ｌｅｎ）。其中，　

前两种相对简单，这里以第三种为例。　

解密操作主要是在ｒｅａｄ方法从磁盘上读到文件　

之后进行的，因此需要实现ＸＣ—ＭｅｔｈｏｄＨｏｏｋ中的ａｆｔｅｒ－　

造成一定的影响。但当应用不是频繁读写磁盘数据　

时，对使用者使用体验影响不明显。　

７结束语　

ＨｏｏｋｅｄＭｅｔｈｏｄ方法。首先通过ａｆｔｅｒＨｏｏｋｅｄＭｅｔｈｏｄ方　

法的参数ｐａｒａｍ．ｔｈｉｓＯｂｊｅｃｔ得到实际调用ｒｅａｄ方法的　

对象，然后从全局ＨａｓｈＭａｐ中得到对应的ｉｎｄｅｘ值，在　

后续读过程中按需复位ｓ—Ｂｏｘ。由于这个ｒｅａｄ方法是　

将读取到的内容保存到参数ｂ数组中，因此还需要通　

过ｐａｒａｍ．ａｒｇｓ获取到该数组和对应偏移量。虽然参数　

中有要读取的长度信息ｌｅｎ，但实际读取的数据量可能　

比ｌｅｎ要小，所以还要通过ｐａｒａｍ．ｇｅｔＲｅｓｕｈ（）方法得到　

ｒｅａｄ的返回值即实际读取到的数据大小。然后结合　

ｉｎｄｅｘ，ｂ，ｏｆｆ，实际数据量，对ｂ中的数据进行加密。最　

后更新ＨａｓｈＭａｐ中的ｉｎｄｅｘ。　

６．３．３　Ｈｏｏｋ　ｗｒｉｔｅ相关方法　

加密操作是在平文数据发送给实际ｗｒｉｔｅ方法之　

前进行，因此要实现ＸＣ—ＭｅｔｈｏｄＨｏｏｋ中的ｂｅｆｏｒｅ—　

ＨｏｏｋｅｄＭｅｔｈｏｄ方法。具体实现与Ｈｏｏｋ　ｒｅａｄ中所述类　

似。此外ｗｒｉｔｅ操作时要注意同步问题，例如当对象Ａ　

以非追加的方式打开并写入文件，相当于清空数据，此　

时ｓ—Ｂｏｘ应该复位，如果没有同步机制的话，可能对象　

Ｂ正在通过之前计算的ｓ—Ｂｏｘ加密数据然后调用原生　

的ｗｒｉｔｅ写入文件，导致使用错误的Ｓ－Ｂｏｘ加密数据。　

６．３．４　Ｈｏｏｋ　ｓｋｉｐ方法　

ｓｋｉｐ方法用于在读文件的过程中跳过一部分数　

据，该系统实现ｂｅｆｏｒｅＨｏｏｋｅｄＭｅｔｈｏｄ方法，由于ｓｋｉｐ　

（１ｏｎｇ　ｎ）不一定能跳过ｎ个字节，所以要用原ｓｋｉｐ函　

数的返回值来更新ｉｎｄｅｘ和Ｓ－Ｂｏｘ。　

６．３．５　Ｈｏｏｋ　ｃｌｏｓｅ方法　

程序调用ｃｌｏｓｅ方法后会释放相关的文件资源，通　

过实现ｂｅｆｏｒｅＨｏｏｋｅｄＭｅｔｈｏｄ方法，删除ｉｎｄｅｘ等自己创　

建的资源。　

６．４实验结果　

该系统可以对Ｊａｖａ层的应用实现透明的文件加　

解密，保护数据安全。为测试该系统对Ａｎｄｒｏｉｄ读写　

性能的影响，使用在一台ＣＰＵ为Ｅｘｙｎｏｓ４２１０（双核ｃｐｕ　

频率１．５　ＧＨｚ）的设备为实验平台，对比使用透明加密　

与没有使用透明加密时在性能上的区别。　

实验结果如表２所示，加解密数据会对读写性能　

表２透明加密对性能的影响　ｍｓ　

透明文件加密可以有效保护用户数据安全，基于　

Ｘｐｏｓｅｄ的透明文件加密方案灵活性较高，可以方便地　

部署在已经发布的移动设备中，使用该系统可以在一　

定程度上保证用户隐私安全。虽然在当前移动设备硬　

件条件下，性能会有一定损失，但目前移动ＧＰＵ厂商　

纷纷将异构计算引入到移动设备中，多线程操作加上　

硬件性能的提升将减缓加密造成的性能损耗。　

参考文献：　

［１］赵铭伟，毛锐，江荣安．基于过滤驱动的透明加密文件系　

统模型［Ｊ］．计算机工程，２００９，３５（１）：１５０—１５２．　

［２］Ｈａｌｃｒｏｗ　Ｍ　Ａ．ｅＣｒｙｐｔｆｓ：ａｎ　ｅｎｔｅｒｐｒｉｓｅ—ｃｌａｓｓ　ｅｎｃｒｙｐｔｅｄ　ｆｉｌｅｓｙｓ—　

ｔｅｎ　ｆｏｒ　Ｌｉｎｕｘ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　２００５　Ｌｉｎｕｘ　ｓｙｍｐｏｓｉ—　

ａｍ．［ｓ．１．］：［ｓ．ｎ．］，２００５：２０１—２１８．　

［３］　陈莉君，于运超．基于ＬＳＭ的轻量级透明加密设计与实现　

［Ｊ］．西安邮电大学学报，２０１４，１９（１）：７８—８１．　

［４］王全民，周清，刘宇明，等．文件透明加密技术研究［Ｊ］．　

计算机技术与发展，２０１０，２０（３）：１４７－１５０．　

［５］Ｍｉｌｌｌｅｒ　Ｔ，Ｓｐｒｅｉｔｚｅｎｂａｒｔｈ　Ｍ．Ｆｒｏｓｔ［Ｃ］／／Ａｐｐｌｉｅｄ　ｃｒｙｐｔｏｇｒａｐｈｙ　

ａｎｄ　ｎｅｔｗｏｒｋ　ｓｅｃｕｒｉｔｙ．Ｂｅｄｉｎ：Ｓｐｒｉｎｇｅｒ，２０１３：３７３—３８８．　

［６］　宋振华．虚拟化技术中的存储管理问题研究［Ｄ］．合肥：中　

国科学技术大学，２０１０．　

［７］　艾祝．基于ｉＳＣＳＩ的数据完整性研究与实现［Ｄ］．兰州：　

兰州大学，２０１４．　

［８］吴倩，赵晨啸，郭莹．Ａｎｄｒｏｉｄ安全机制解析与应用实　

践［Ｍ］．北京：机械工业出版社，２０１３：２６—２９．　

［９］Ｄｅｌａｃ　Ｇ，Ｓｉｌｉｃ　Ｍ，Ｋｒｏｌｏ　Ｊ．Ｅｍｅｒｇｉｎｇ　ｓｅｃｕｒｉｔｙ　ｔｈｒｅａｔｓ　ｏｆｒ　ｍｏｂｉｌｅ　

ｐｌａｔｆｏｒｍｓ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　３４ｔｈ　ｉｎｔｅｒｎａｔｉｏｎａｌ　ｃｏｎｖｅｎ—　

ｔｉｏｎ．［Ｓ．１．］：ＩＥＥＥ，２０１１：１４６８—１４７３．　

［１０］Ｓｈａｂｍｉ　Ａ，Ｆｌｅｄｅｌ　Ｙ，Ｅｌｏｖｉｃｉ　Ｙ．Ｓｅｃｕｒｉｎｇ　Ａｎｄｒｏｉｄ—ｐｏｗｅｒｅｄ　

ｍｏｂｉｌｅ　ｄｅｖｉｃｅｓ　ｕｓｉｎｇ　ＳＥＬｉｎｕｘ［Ｊ］．ＩＥＥＥ　Ｓｅｃｕｒｉｔｙ＆Ｐｒｉｖａｃｙ　

Ｍａｇａｚｉｎｅ，２０１０，８（３）：３６—４４．　

［１１］张晓丰，樊启华，程红斌．密码算法研究［Ｊ］．计算机技术与　

发展，２００６，１６（２）：１７９一】８０．　

［１２］Ｓｉｎｇｈａｌ　Ｎ，Ｒａｉｎａ　Ｊ　Ｐ　Ｓ．Ｃｏｍｐａｒａｔｉｖｅ　ａｎａｌｙｓｉｓ　ｆｏ　ＡＥＳ　ａｎｄ　ＲＣ４　

ａｌｇｏｒｉｔｈｍｓｆｏｒ　ｂｅｔｔｅｒ　ｕｔｉｌｉｚａｔｉｏｎ［Ｊ］．Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｊｏｕｒｎａｌ　ｏｆ　

Ｃｏｍｐｕｔｅｒ　Ｔｒｅｎｄｓ　ａｎｄ　Ｔｅｃｈｎｏｌｏｇｙ，２０１１，７９（１４）：１７７—１８１．　

［１３］Ｗｉｅｎｅｒ　Ｍ　Ｊ．Ｅｆｉｆｃｉｅｎｔ　ＤＥＳ　ｋｅｙ　ｓｅｒａｃｈ［Ｄ］．Ｃａｎａｄａ：Ｃａｒｌｅｔｏｎ　

Ｕｎｉｖｅｒｓｉｔｙ，１９９４．　

［１４］Ｓｃｈｉｍｍｌｅｒ　Ｍ，Ｗｉｅｎｂｒａｎｄｔ　Ｌ，Ｇｕｎｅｙｓｕ　Ｔ，ｅｔ　ａ１．ＣＯＰＡＣＯＢＡ—　

ＮＡ：ａ　ｍａｓｓｉｖｅｌｙ　ｐａｒａｌｌｅｌ　ＦＰＧＡ－ｂａｓｅｄ　ｃｏｍｐｕｔｅｒ　ａｒｃｈｉｔｅｃｔｕｒｅ　

［Ｍ］／／Ｂｉｏｉｎｆｏｍｒａｔｉｃｓ－ｈｉｇｈ　ｐｅｒｆｏｍｒａｎｃｅ　ｐａｒａｌｌｅｌ　ｃｏｍｐｕｔｅｒ　ａｒ．　

ｃｈｉｔｅｃｔｕｒｅｓ．［Ｓ．１．］：ＣＲＣ　Ｐｒｅｓｓ，２０１０：２２３—２６２．　

［１５］吴文玲，冯登国．分组密码工作模式的研究现状［Ｊ］．计算　

机学报，２００６，２９（１）：２ｌ一３６．