文献翻译--root机构：一个基于数字签名的云终端设备root权限管理机构

关键词

移动云计算
Android安全
root管理方案
数字签名
完整性验证

摘要

· 对安卓设备进行“根化”可能是终端用户的一种自愿行为，比如删除OEM预装应用程序。这导致了恶意软件的特权升级机会的增加。现有的root权限管理方案依赖于终端用户对设备上安装的所有合法和非法应用程序做出权限授予决定。然而,非技术用户不能,还是粗心在决定哪些特权适合什么类型的应用程序。为了解决这个问题,一个根特权管理机构命名RootAgency提出采用数字签名方案保证独家root-privilege-granting验证应用程序的机会。RootAgency通过检查应用程序是否持有由密钥生成的签名来对应用程序进行身份验证，并在经过签名的应用程序提交请求时授予root特权。此外，它验证应用程序的完整性，以防止它重新打包。因此，当面对root请求时，用户不参与决策制定。该方案保证了根Android设备的安全性，提高了移动终端设备的安全性。这减少了被误用的Android设备对云基础设施的威胁。此外，还实现了一个原型来评估其有效性、效率和开销。实验结果表明，RootAgency具有广泛的兼容性和合理的性能开销。

1 介绍

· 云计算是智慧城市的重要组成部分。随着移动互联网接入的迅速普及，移动云服务中的安全问题已经成为云计算研究人员和工程师关注的关键问题。安全的两个主要领域是数据安全和隐私保护。移动终端设备作为移动云环境的重要组成部分，其自身的弱点会威胁到整个移动云的安全。这些威胁可能来自软件漏洞和硬件漏洞。例如，典型的攻击，如利用僵尸网络，或分布式拒绝服务(DDoS)攻击已经成为移动云服务的一个日益增长的威胁。据报道，研究人员发现了首个已知的名为Twitoor的Android手机恶意软件，它可以以一种无法检测的方式将设备招募到Android僵尸网络中。通过使用恶意注册的Twitter账户，终端用户设备中的恶意软件就会接收指令，执行下载二级有效载荷和切换到其他账户等操作。
· Android是一款流行的移动终端操作系统(OS)，由谷歌在2009年设计并发布。它的流行、开源设计和缺乏应用程序验证，使配备它的设备成为恶意软件攻击的主要目标。最近的一项研究报告称，几乎90%的Android设备都面临着通过恶意软件和信息进行攻击的风险。Root特权是Android中最高的权限，可以完全控制终端用户的Android设备。考虑到其诱人的可能性，为Android设备寻找根源可能是终端用户出于各种动机的一种自愿行为，比如删除预装的应用程序、更改硬件设置、备份Android系统或完全反恶意软件功能。
· 然而，Android设备的根可能导致一个开放的机会，特权升级的恶意软件。这为恶意软件提供了一种获取根特权的相对容易的方法，而不是漏洞利用，因为恶意软件所需要的只是在授予根特权时误导最终用户。例如，建议一种伪装方法，将恶意代码注入重新包装的良性应用程序，并假装自己是一个未经修改的应用程序。尽管SuperSU和KingRoot等根管理工具是为授予根权限而设计的，但它们都依赖于最终用户来为所有类型的应用程序做出权限授予决策。用户根管理方案暴露了一个漏洞，增加了根Android设备的根特权泄漏风险，因为Android设备用户几乎不可能知道或理解每个权限的详细角色。在一项调查中发现，只有3%的互联网参与者和24%的实验室研究参与者能够成功地理解和授予权限，而高达42%的用户完全不知道权限及其后果。
· 为了弥补缺乏经验的用户无法进行root权限管理的缺陷，必须保证经过身份验证的应用程序的独家root权限授予机会，并对应用程序的完整性进行检查，防止其重新打包。因此，本文提出了一种root管理方案——root代理。在root代理中，请求许可的应用程序由root代理而不是最终用户获得root特权。在我们的设计中，root代理包含两个模块:一个可验证的应用程序生成过程和一个应用程序完整性验证过程。可验证的应用程序生成过程将已验证的应用程序作为输入提供给应用程序完整性验证过程。可验证应用程序生成过程实现了提取,验证和埋置的指定文件摘要生成验证应用。应用程序完整性验证程序检索嵌入式数字签名和使用数字签名验证程序检查数字签名的真实性和检测应用程序的完整性。根据完整性验证的结果，root代理判断根请求应用程序是否应该被授予root特权。为了验证root代理的可行性，通过几个典型的应用程序示例实现了一个原型，并对其有效性、效率、可移植性和性能开销进行了评估。

下面是这篇文章的主要贡献：

（1）为了降低Root权限泄露的风险，提出了一种基于Root代理的app完整性验证方案。
（2）root代理的原型在实际环境中实现和部署，以评估其有效性、效率和可移植性。
（3）该方案减少了被误用的Android设备对移动云安全的威胁。
本文的其余部分组织如下：
· 本研究领域的相关工作在第2部分进行了描述。第3节介绍了root机构的设计目标和细节，然后在第4节中介绍了其原型。在此基础上，对root机构原型进行了测试和评价。所提出的方案的局限性和可能的改进建议见第6节，本文的结论见第7节。

2 相关研究

· 本节主要讨论root特权滥用的相关工作。我们还详细阐述了现有的解决方案和所提议的架构之间的异同。

2.1 root权限的预防和保护

· root特权滥用的典型缓解措施是保护root特权不被非法获取。一些学术研究采用了加强Android内核的附加强制访问控制(MAC)或类似的方法来保护根访问或限制高级权限的能力和活动范围。
在此之前，Shabtai等人建议将SELinux集成到Android中，以减少恶意攻击的潜在危害，从而加强内核级的访问控制。随后，Smalley和Craig[26]提出了一种基于SElinux的中间件MAC方案SEAndroid，以缓解root权限滥用和应用漏洞带来的影响。SEAndroid还通过改进Android系统的安全性，特别是防止特权升级的利用和root特权的滥用，证明了它的有效性。Bugiel等人[3]提出了FlaskDroid，这是Android OS的通用安全架构，它采用了类似于SEAndroid的两层MAC框架，利用Android中间件的高效策略语言来支持多个细粒度的安全策略。
· 可以得出结论，MAC方案确实弥补了现有Android操作系统中的自主访问控制(DAC)方案，并为root权限安全提供了强大的保护。但是，上述系统提供的默认设置和策略不能提供足够的灵活性和用例场景。默认的策略很难理解和修改，尤其是针对不同厂商的Android，直接影响用户的体验。此外，包含MAC机制的方法无法考虑在root Android设备上使用root特权的可能性的非常现实的情况。

2.2root权限管理

· 根特权滥用的另一个解决方案是根特权管理。与第一个类别不同，这个类别侧重于帮助用户管理根特权。Root Guard[24]相对于MAC的严格限制，对设备用户提出了一种相对宽松的Root管理，帮助终端用户通过预定义的策略在有根的Android设备上管理Root权限。这些预定义的策略来自于谷歌play(2014)中现有应用程序的root-privilege需求，并被分为四组。
· 在root保护中，请求应用程序可以获得root权限进行监视和控制。然而，这些不灵活的预定义策略不可避免地会给最终用户带来操作问题。例如，在首次使用root-require应用程序之前，最终用户必须了解它属于哪个组。在本文中，我们的方法Root Agency采用了应用程序完整性验证来检测请求应用程序的真实性，保证了Root特权的可靠使用，而不需要终端用户的依赖。

2.3 应用可靠性检测

· root权限安全的第三类是应用程序的真实性检测。在学术研究中，app相似度检测技术作为app认证检测的一种，被过多地用于验证重新打包的app的完整性。
· DroidMOSS[44]从每个app中提取操作码作为其特征，并应用模糊哈希技术生成每个app的指纹进行匹配。两个对应的app之间的相似度，也就是相似度评分，被客观地反映出来，计算出两个指纹之间的距离。0是一个可扩展的基础架构，用于Android应用程序之间的代码相似度分析，它根据应用程序每个基本块中的代码序列生成所有k克的操作码，并应用未来哈希来生成应用程序的向量表示。两个应用程序的相似度，即它们的特征集之间的相似度，使用jaccard相似度度量。DNADroid[7]是一个用于重新打包应用程序检测的工具，它从每个应用程序生成程序依赖关系图(PDGs)，并将其与两个不同的应用程序进行比较，以检测应用程序的相似性。
· 以上的作品都采用了不同的研究对象来检测app之间的差异，描述重新打包后的app的修改细节。根据我们的观察，一个关键的先决条件是探测过程必须成对进行。两个版本的应用程序都必须是可用的，并应确保真实的版本。此外，这些系统只适用于pc上的大规模app比较，不适合低容量的Android设备。
· 为了在Android设备中实现这种检测，根代理与上述系统相比有几点不同:首先，通过签名验证来检测app的真实性(与原始app的相似性)。其次，根代理从请求应用程序中检索当前指纹和原始指纹，而不需要原始应用程序本身。最后，Root Agency在Root request time被激活，在Android中执行验证过程，因为它只需要识别安装的Root -require app是否已经被修改。

3 root agency 的设计

3.1 目标

· 为了保证用户管理根权限的保护，必须实现三个关键的设计目标，即有效性、效率和可用性。考虑到恶意软件的伪装，有效性是应用程序真实性验证的必要前提，而有效性的缺失将直接导致root权限的泄露。恶意代码可能隐藏在app的不易察觉的角落，从而避免被防病毒app检测到。因此，根机构验证方案需要一种具有足够证据信息的准确检测方法，能够识别app的完整性。
· 效率是第二个目标，它用于量化根机构验证方案对系统性能的影响。虽然，它是最方便的检索和保留所有的应用程序文件的证据，但它造成低效，因为不是所有的文件都需要进行分析。因此，在我们的设计中，只选取app的关键文件作为提取目标和证据信息。可移植性是评估不同Android版本之间兼容性的另一个基本要求。因此，需要对不同版本的本地和第三方Android操作系统进行测试。

3.2 设想

· 在本文中，我们的目标是提供一个轻量级的根特权管理方案。我们专注于建立一个app验证方案。因此，app行为检测超出了本文的范围。此外，我们假设应用程序开发人员和证书颁发机构(CA)可以相互信任。考虑到直接从相应的开发者那里获取原始的应用程序比较困难，从谷歌Play下载的应用程序被视为原始版本。此外，由于没有讨论签名密钥泄漏的问题，我们假设来自开发人员和CA的签名密钥没有泄漏。

3.3 Rootagency验证方案

· root机构验证方案的基本设计元素是禁止恶意软件(修改和重新打包的良性应用程序)通过误导终端用户获得根特权。通过可靠的应用程序生成过程和应用程序完整性验证方案来保证应用程序的完整性。
· 如图1所示，开发者和CA构成了可验证的app生成过程。当应用程序试图申请根权限时，Android设备中插入的应用程序完整性验证过程检测应用程序的完整性。特别是，可验证的应用程序包含数字签名。根机构的可验证app生成过程是一个app重建过程，将原app转化为可验证app的版本。这个修改过程包括三个关键步骤:指纹生成、指纹认证、app转换。指纹生成和app转换由app开发者实现。指纹认证由CA执行，通过这三个关键步骤，生成并发布一款满足根机构完整性认证要求的app。
· root代理的app完整性验证过程是一个app完整性检测过程，它在请求的app未被验证时执行app完整性验证。如图1中Android设备部分所示，构建app完整性验证流程，将请求app与根访问分离开来。确切地说，在请求应用程序获得根特权之后，完整性验证过程提取加密的指纹并计算当前的指纹进行签名验证。最后，根据应用程序完整性验证的结果判断请求应用程序是否获得root权限。

3.3.1 可验证的应用程序生成过程

在本节中，我们将解释可验证的应用程序生成过程中的不同子过程。

A.目标选择

· 所有Android应用程序都由不同的文件和文件夹组成，这些文件和文件夹执行各自的功能，如表1所示。· AndroidManifest.xml存储元数据，如所需的包名和权限等。在app执行之前，将app需要的必要信息提供给Android系统。dex包含了所有Dalvik字节码形式的应用程序代码，可以在Dalvik虚拟机中执行。META-INF可以存储开发人员的签名，以验证第三方开发人员的身份。文件夹库存储由可执行文件引用的本机库二进制文件。虽然Android应用程序主要是用Java编写的，但它们的一些功能可能是用本地代码实现的。这个目录是可选的，因为大多数Android应用程序不包含本机代码。文件夹存储用户界面布局，图像和图标等。文件夹资产包含非编译的资源。
· app的真实性需要有效的验证证据，因为app包比较容易被恶意代码反编译和感染。考虑到有效性需求，我们选择与执行相关的文件和文件夹作为提取目标。根据需求，class .dex、AndroidManifest.xml和Suffix文件是直接影响良性app执行行为的文件，因此它们是被选择的目标。例如，在一个良性的应用程序中，可以将恶意代码注入class .dex，并且可以向AndroidManifest.xml附加额外的权限以实现恶意行为。
· 此外，为了保护版权和未选择的文件，作为补充证据，选择了包含原始开发人员信息的开发人员公钥。例如，在一个没有修改的重新打包的app中，修改后的布局和修改后的logo被认为是一个不完整的app。根据前面的分析，目标提取接收并提取所选择的文件或文件夹进行指纹生成。

B 指纹的一代

· 指纹生成过程的目的是将选定的目标转化为有效的可验证证据。它是通过使用哈希技术来生成所选目标的摘要作为证据来实现的，该技术对应用程序文件中最微小的变化都很敏感。详细的指纹生成过程包括三个步骤，其次是传输安全的附加步骤。如图2左侧所示。根据Android的签名方案，在标准签名过程中，应用SHA-1来消化开发者生成的非文件夹和非签名文件。
· 然而，在[27]中进行了关于SHA-1的散列碰撞实验，结果表明，在我们的设计中，SHA-1对于摘要生成是不安全的。为了更好的安全性和空间消耗，在可验证的app生成过程中，在计算摘要中选择SHA-256来代替SHA-1。SHA-2的安全性分析表明，它也有类似于SHA-1[2]的被破坏的可能性。然而，目前尚未发现针对SHA-2安全标准的实际攻击。在实践中，我们的方案中摘要生成算法的选择是灵活的，可以根据实现需求进行修改。
· 在指纹生成阶段，使用两次哈希函数。一次计算所有目标摘要，然后将计算出的摘要连接成更短的形式，用于app指纹。通过两次哈希计算，提取app完整性证据进行app完整性验证。

C 指纹识别

· 如图2的指纹认证模块所示，它是一个通过数字签名进行指纹加密的过程。它具有检测伪造和篡改的能力，不仅为指纹及其发布后对应的app提供了有效的保护，也保证了指纹的真实性。
· 在这一阶段的开始，需要验证接收到的指纹。完整性验证保证了指纹在线传输的完整性，为数字签名步骤提供了准确的指纹。签名验证从开发人员公钥数据库中检索开发人员公钥以检测指纹完整性。在数字签名,一旦指纹验证的完整性,CA迹象的明文指纹生成数字签名使用CA私钥存储在数据库的关键。通过指纹认证阶段,接收到的指纹身份验证生成加密指纹并交付给相应的开发人员。

D 应用程序转换

· 下一阶段是app转换，在接收到CA的加密指纹后，生成可验证的app，如图2中app转换模块所示，这一阶段包括两个步骤:指纹注入和app重新打包。将加密的指纹插入对应的app中，所有文件和文件夹按照标准的Android签名流程重新打包。
· 考虑root机构的完整性验证功能,加密指纹注射作为先决条件阶段确保加密指纹从CA可以集成到原始应用程序。考虑到时间consump,检索,在前一步中,加密指纹直接嵌入应用程序的主目录中,普遍叫指纹。在后面的步骤中，包含加密指纹的重新打包的app由开发者的私钥签名，该私钥对应于在目标提取阶段选择的作为证据的公钥。通过以上步骤，最终生成携带证据信息的可验证app。

3.3.2 App完整性验证流程

· app的完整性验证过程可以帮助判断是否可以将root权限授予请求app。如图3所示，app的完整性验证过程首先通过请求app的基本信息对app信息数据库进行搜索，以确定其是否被验证。如果不存在，则激活完整性验证模块，更新app信息数据库和审核结果数据库。在做出最终决定之前，结果提取过程检索“资格审核结果”和“审核结果”。如果经过验证，结果提取将收集审计结果并将其发送到结果判断，该判断将决定请求应用程序是否应获得根特权。
· Android设备根机构验证过程的关键步骤是应用程序完整性验证过程，该过程根据当前指纹验证请求应用程序的真实性。如图3所示的app完整性验证部分，为了实现完整性验证，该模型必须提取加密后的指纹，即CA的公钥，并计算当前的指纹以满足签名验证要求。
· 两个步骤(当前的指纹计算和加密的指纹提取)从app包的安装目录中获取所需信息。Android操作系统加载可执行文件和提取他人要求应用程序安装目录的文件执行程序。当前指纹转换和打包后指纹检索完成,签名验证是激活验证数字签名证书颁发机构(打包指纹)加密的私钥。最后，资格审核给出关于根请求的决策，并将结果更新到审核结果数据库。
当前指纹的计算过程与3.3节描述的指纹生成过程相同，不包括指纹加密过程。因此，本节没有详细描述。计算出的当前指纹被发送到签名验证模块进行下一步。
· 封装的指纹检索过程获取嵌入在app转换(章节3.3中描述)中的指纹，用于签名验证。在这个步骤中，使用请求应用程序的包名来定位请求应用程序的存储目录。然后，从定位的目录检索加密的指纹。最后，将加密后的指纹发送到签名验证过程。
· 在获得计算出的当前指纹和加密的指纹后，签名验证从证书颁发机构密钥数据库中检索证书颁发机构的公钥，并利用加密的指纹、当前指纹和CAs公钥来实现签名验证。最后将验证结果发送给资质审核。
资格审核根据验证结果(显示为真或假)决定请求应用是否获得根权限。获取审计结果并将其更新到审计结果数据库以进行结果提取。

3.3.3 参考数据库

· 在我们的设计中，参考数据库(DB)有5个子数据库:3个子数据库在Android设备中，另外2个子数据库在CA中，如表2所示。
· 根机构密钥数据库将CA的公钥与根机构验证共存，并在签名验证时激活，提供用于签名验证的公钥。
· App信息数据库包含验证过的App信息四部分:包名、版本号、安装时间、开发者信息，描述了从请求App中提取的实际信息。这也意味着，缺少包名和开发人员信息将导致检测包含其他两部分信息的应用程序失败。缺少安装时间和版本也会导致app更新后同样的结果。激活app信息数据库，检索验证后的app信息。
· 审核结果数据库存储资质审核结果。在根访问管理中，审计结果数据库被激活以提供认证结果。
· 开发人员密钥数据库用于存储开发人员信息和相应的公钥，在指纹认证过程中激活。
· CA密钥数据库提供了用于数字签名的CA私钥，并为每个开发者提供了相应的公钥用于指纹完整性验证。

4 实施

· 作为上一节设计的实现，根机构原型是根据3.3节提出的方案开发的。如图4所示，根据实际执行环境，根代理原型中还包含了app markets和智能手机厂商的模块。应用市场(官方应用市场和非官方应用市场)将开发者和设备用户与上传和下载的可能性联系起来(行动A和B)。
· 在将这些应用程序推向市场之前，需要采取三个主要步骤:指纹生成(动作1和2),指纹身份验证(3和4)和应用程序转换(5和6)是由开发人员和CA件的可核查的应用。区分从原始的手工操作(7)行动,如果下载应用程序需要root特权,根机构核查程序被激活的完整性验证,而不是(行动7)。此外,根特权的决定取决于完整性验证的结果(操作8)。

4.1 Verifiable app generation

· 构建root代理原型需要解决两个问题:可验证的应用生成和应用的完整性验证。在本节中，首先讨论第一个问题，然后在下一节中讨论另一个问题。
· 考虑到目标提取和指纹生成的效率和一致性，自动执行过程、特殊定制的摘要组合算法和格式一致的指纹是实现的关键问题。因此，采用索引列表来提供检索序列。同时，基于建议的过程，编写了一个包含825行Java代码的自动化工具，为开发人员提供一个统一的过程。虽然3.3.1节描述了目标的选择，但值得注意的是，目标是按索引顺序提取和排列的。如图5所示，通过文件连接将目标和开发人员的公钥的固定长度摘要分别散列并集成到最终摘要中。
· 确保安全的传输指纹,开发人员提交指纹和指纹加密由CA的私钥签名。CA分发加密指纹由CA的私钥签署之日,sponding公钥的真实性后开发人员确定接收到的指纹。
· 此外，针对不同的目标，对签名验证方法进行了两次处理:开发者身份验证和CA验证。开发者身份验证通过将开发者的签名与他人的签名区分开来，从而保护了指纹的完整性。后者通过检测CA的签名权限来实现身份验证。
· 验证返回的指纹密文后，将加密后的指纹插入到原app中。最后进行重新打包和签名操作，将原app转化为可验证的app。

4.2 Rootagency verification procedure

· 智能手机厂商预先安装在原型的设备上(动作C)。验证操作由包含891行Java代码的一小段程序实现。对于在Android中工作的代码，通过终端用户授权来执行根权限管理的功能代码被替换为在ap-适当的位置进行根代理验证的功能代码，该功能代码由四个主要步骤组成。首先，将根机构验证程序的源程序编译成.class文件。其次，使用DX可执行文件将转换后的.class文件转换为Dalvik字节码。第三，将Dalvik字节码插入到用户授权功能代码执行的预定义位置，实现验证功能。最后，对包含根代理验证过程的修改后的根管理工具进行重新打包并签名，生成根代理原型的可执行根管理工具。安装修改后的根管理工具，以取代现有的根管理工具在根Android。
· 具体过程如图6所示的时序图所示。具体来说，步骤3-15是根机构验证过程，它区别于用户管理过程。
step1： 请求应用程序通过shell调用Su二进制
step2： Su通过发送一个授权请求来执行权限检查。
step3： Su和根代理相互验证以保护Su二进制完整性。在失效的情况下，根代理将不继续执行保护根特权的下一步。
step4： 验证Su的真实性后，根代理根据步骤1提供的app包名提取请求app信息。
step5： 根代理访问应用程序信息数据库，并根据已删除的应用程序信息搜索验证记录。如果app信息数据库拥有相同的对应信息，则激活根机构验证程序模块，从审核结果数据库中检索审核结果。提取的结果用于结果判断的判断证据(跳转到步骤14)。如果没有(请求的应用程序没有被验证)，应用程序完整性验证方案将被激活，以检测应用程序的完整性。
step6： 从请求应用程序检索加密的指纹。
step7： 如果加密指纹存在，app的完整性验证将继续进行。如果没有，这个条件会导致根本的需求被拒绝。
step8： 将目标文件和存储在CERT.RSA中的开发人员公钥从请求应用程序中提取出来。
step9： 提取的目标文件和开发人员密钥用于通过4.1节中描述的操作序列生成当前指纹。
step10： 提取CA的公钥以满足签名验证需求。
step11： 通过签名验证检测app的完整性，并提交资质审核。
step12： 根据app诚信结果审核合格结果。
step13： 审计结果数据库中的日期被更新。同时，将请求app的信息记录在app信息数据库中。
step14： 审计结果用于确定请求应用程序是否应该被授予权限。
step15： Su根据根代理的判断向请求应用程序授予根特权。
step16-18： 此步骤与典型的根管理工具相同。

5 RootAgency评价

· 根代理的原型在有效性、性能影响和可移植性方面进行了测试和评估。这些细节将在下面的小节中描述。

5.1 Testcase选择

· 几个应用被选为测试用例，满足了一个关键要求和两个基本要求。一个应用程序的真实根需求是关键需求，它导致应用程序在第一次执行时触发根代理验证方案。可靠的来源是两个基本要求之一，这是一个应用程序可靠性的保证。另一个是app的安装，它代表了app的关注度和生命力。高安装次数和可靠来源是帮助我们对样本app进行分类和选择的因素。考虑到用户的实际情况，我们会仔细选择app的一部分。因为根代理验证方案关注基于应用程序本身的应用程序完整性验证。
· 在选择阶段，我们首先从谷歌Play中选择100个公开提到根需求的应用。根据这些应用的基本介绍，将其分为数据恢复、硬件修改、系统管理、快照等一系列具有不同功能特征的代表性应用。
· 在此基础上，根据指纹生成的安装和变量提取目标，最终从每个分类中筛选出15个应用程序。特别是选择了一些在其他应用市场非常受欢迎或者提供单一功能的应用。例如设置CPU和AppOps。这15个app的基本信息如表3所示，包括版本号、根公告、开发者名称和安装情况。
· 被选中的应用程序会被故意修改，然后被分成三组。第一组(g1)包含从谷歌Play下载的15个精选的原始应用，用来评估根代理的性能。为了验证根代理的有效性，第二组(g2)由15个可验证的app组成，每个app对应g1中的一个app。g2生成过程包括指纹嵌入和可验证的app生成两个步骤，分别在3.3.1节中描述。考虑到获取开发者密钥的难度，我们实验中的原始应用在每个指纹嵌入后都重新打包并使用指定的私有密钥进行签名。第三组(g3)是根据g2的每个app组成的，这是一个修改的过程。对g1的app进行修改，生成良性app的变化。为了评价根机构的有效性，g2为对照组，g3为实验组。为了评价根机构的绩效，g1为对照组，g2为实验组。

5.2 有效性

· 如表4所示，为了估计根代理的有效性，选择15对可验证的应用程序及其相应的修改过的应用程序(使用∗mark)来构成对比集。预期的验证结果在第8列中描述。各可验证app的修改项如第2-7栏所示。此外，修改的项目覆盖了各种app文件，包括选择的两个目标(AndroidManifest。在我们的设计中，xml、classes.dex、.so和私钥)和未选择的文件(Res和其他文件)。
· 在相同的环境中，安装并执行所选的应用程序来激活根需求。为了获得有效的结果，每个应用程序在验证后被卸载。同时，在记录完成后，清除根代理引用数据库中存储的数据，以区分app相同的包名。
· 表4中的验证结果表明，实际结果与预期结果一致，说明根机构完整性验证方案能够准确识别应用程序的完整性。

5.3 示例应用程序的案例研究

· 在本小节中，我们以示例应用程序作为案例研究。对g3修改后的应用程序进行评估，以验证根代理的有效性。出于测试的目的，我们选择了3对作为代表性的案例，分别是根浏览器和根浏览器印迹、钛备份和钛备份印迹、根增强器和根增强器印迹。被标记的app版本是被修改过的。
case1： Root Browser
· Root Browser是一个针对Root用户的文件管理器，在谷歌Play中有大量的安装计数(10,0 0,0,0 0 0,0 0 0 50,0 0 0 0,0 0 0 0 0 0)。主要功能是浏览所有的Android文件系统，控制Android系统。根代理成功地将根浏览器识别为恶意应用程序。它未能通过完整性测试，根代理在解压和分析后确定class .dex文件和AndroidManifest.xml文件的摘要已被更改。此外，数字签名与根浏览器不同。
case2： Root Booster
· Root Booster是为那些需要更多性能来平稳运行应用程序的Root用户，或者为那些需要改进糟糕的电池寿命的用户提供的。它拥有大约100万用户(第2016位)。根增强器没有在根代理完整性验证下获得根特权。分析表明，对.so文件和数字签名进行了修改。
case3： Titanium Backup
· Titanium备份是Android上最强大的备份工具(1000万次安装)，可以备份、恢复、冻结应用程序、用户数据和市场链接。来自Titanium备份的根请求被根代理拒绝。对Titanium备份进行解压缩，并计算每个文件的摘要。比较结果表明，res文件夹中的.png文件和.so文件被修改了。来自Titanium备份和Titanium备份的数字签名也不是来自同一个开发人员。

5.4 技术性能分析

· 为了评估根机构的绩效，比较集由g1(对照组)和g2(实验组)组成。同时，此阶段不选择修改后的app，需要获取整个过程的时间消耗。
· 通过加入根机构完整性验证，规定了性能实验的时间消耗。没有根机构完整性验证，应用程序需要通过用户管理操作的根特权。插入根代理完整性验证后，请求的应用程序根据完整性签出获得根特权。对于统一的度量标准，在用户根管理中，记录从用户单击Grant按钮到表示成功的界面的时间消耗。在根代理中，从测试应用程序发起请求到最终用户获得根特权请求的回复(由日志记录)，时间消耗被记录下来。要获得每个应用程序的全部时间消耗，必须卸载所有测试应用程序，并在启动相同应用程序包名的新测试时清除它们的相关数据。
· 如表5所示，第4列和第5列显示了在相同的测试环境(三星Galaxy S6 Android 5.0.2)中计算的时间消耗(平均10倍)。第6列显示了时间消耗增加的差异。可以看出，时间消耗在22.1 ms - 122.1 ms左右，这主要是由于根代理验证方案。考虑到用户体验，增加约0.12 s的时间是可以接受的。
· 图7用图形表示时间消耗情况。值得一提的是，所有应用程序的时间消耗与其提取的应用程序文件号呈正相关。在根代理中，时间消耗由检索时间、指纹生成时间和签名验证时间三部分组成。前两项的差异导致了不同的时间消耗，如表5第4列和第5列所示。

5.5 便携性评估

· 为了确定根代理的可移植性，我们选择了几个具有不同Android版本或第三方Android操作系统的Android设备进行原型安装。所选设备通过根管理工具进行根化，根管理工具与根代理原型是相同的版本，因为典型的根代理验证方案的实现依赖于根管理工具。
· 在已安装的根代理原型设备中安装和执行几个测试应用程序，以检查根代理的有效性。表6总结了我们的根代理实现目前支持的Android版本和设备模型。我们的原型支持从4.4.4到5.1.1的所有Android版本(包括相应的第三方Android操作系统)，可以应用于最典型的Android厂商设备，包括HTC、LG、MOTO、SONY、SUMSUNG和小米。

6 限制和未来的工作

· 在这一节中，讨论了根代理原型和方案的一些局限性。
· 首先，根代理方案在实际设备上的实施和部署需要厂商和应用开发者采用。一方面，root权限保护是Android安全方案的一部分。执行根代理方案来管理根权限，需要修改现有的Android系统。要实现此功能，必须将底层Android系统替换为支持根代理的版本。另外，Android系统供应商(谷歌、供应商和第三方系统制造商)可以将根代理直接合并到他们自己的构建中。另一方面，根机构使用的完整性验证方案需要应用程序的准确原始信息，而这些信息只能来自相应的开发者。此外，包含指纹的app必须由原开发者生成，因为这种方法为应用的真实性提供了保证。同时，基于杀毒软件的app签名验证，可验证的app可以轻松通过验证。
· 其次，该方法解决了用户管理根访问的问题。一个应用程序在没有用户管理的情况下获得未经授权的root特权，这是一个完全不同的挑战，需要一种新的方法来解决。
· 根特权安全的研究大多是基于限制对根特权的访问，或详细描述根特权行为以限制非法根授予所造成的损害。但是，目前还没有有效的解决方案来缓解Android系统自身的漏洞所造成的root权限泄露。为了消除这种威胁，需要修补所有可能造成损害的相应漏洞。此外，消除攻击者的利益链或切断感染渠道，如[35]中所提出的，也可以是一个有效的缓解。
· 未来，我们会在我们的方案中加入app的root权限撤销，这是利用app的设计缺陷来滥用root权限的一种应急措施。

7 结论

· 移动终端设备的固有特性威胁着云基础设施，特别是来自被滥用的Android设备。然而，root权限管理对于没有经验的终端用户来说是一项重要而又困难的工作。为此，本文提出了一种基于根代理的根管理方案。采用数字签名方案，保证认证应用的根特权授予机会。此外，还在用户的设备中部署了一个完整性验证过程，以检查根权限请求应用程序是否已重新打包。实验结果表明，根代理能够以可接受的开销和效率实现目标。