作者： Ildar Muslukhov, Yazan Boshmaf, Konstantin Beznosov
单位： The University of British Columbia, Qatar Computing Research Institute
出处： AsiaCCS‘18
资料： PDF
1 ABSTRACT & INTRODUCTION
根据最近的研究表明，88％使用Java密码学API的Android应用程序至少会出现一个密码学误用的问题。但是，目前还不清楚这些错误是来自应用程序还是第三方lib。而在本文中，作者弥补了这一gap，并将误用的来源归属引入到密码学API误用的分析中。本文研究的目标有两个：（1）将密码学API误用的来源归属，以及（2）研究2012年至2016年间误用的变化。
作者使用C#设计并实现了一个静态自动分析系统BinSight：（1）使用静态程序切片识别Java密码学API的调用，（2）验证这些调用 - 针对密码学中常见规则调用，最后（3）使用基于启发式的第三方库检测技术将误用的调用归因于其源。
作者分析了2012年，2015年和2016年收集的132K个Android应用程序。结果表明第三方库是密码学API误用的主要来源。90％的误用应用程序（至少包含一个Java密码学API调用）来自第三方lib。
与2012年相比，作者发现对于应用程序和第三方库代码，2016年对称密码的ECB模式使用率显着下降。然而与应用程序代码不同，第三方库显着增加了对用于CBC模式密码的对称密码和静态IV的静态加密密钥的依赖。最后，作者发现2016年误用的第二和第三大原因是使用了不安全的RC4和DES秘钥。
2 COMMON RULES IN CRYPTOGRAPHY
作者定义了一系列判断无用的rules便于后续针对是否属于误用的分析。
2.1 Symmetric key encryption
Rule 1. 在加密算法中使用ECB模式。
Rule 2. 在CBC模式中是使用常量 IV。
Rule 3. 不使用常量当做加密秘钥。
2.2 Password-based encryption
Rule 4. 不在PBE中使用常量静态salt
Rule 5. 不在PBE中使用少于1000次的迭代。
2.3 Random number generation
Rule 6. 不在SecureRandom中使用常量种子
3 DATASETS
作者收集并分析了三个数据集如下图，总共有132,590个APK文件。 R12是CryptoLint数据集的子集，包含10,990个APK文件。最初的CryptoLint数据集有145,095个APK文件，并在2012年5月至7月期间通过Google Play市场收集的。
首先，CryptoLint的作者排除了所有未使用密码学API的APK文件。其次，作者还排除了所有具有来自11个白名单库的Crypto API调用的APK文件。但是CryptoLint由于自身缺陷无法分析此集合中的3,386个APK文件，并且自2012年以来丢失了758个文件，导致R12数据集中有10,990个APK文件。在Sophos的帮助下，2016年5月收集了R16数据集。
为了在R16数据集中选择APK文件，作者首先生成了当时在Google Play市场上可用的120,000个APK文件的随机样本，然后通过Sophos服务器下载了该文件集。但是最终只成功下载了117,320个APK文件。
最后，T15数据集包括2015年6月以来每个类别中的前100个Android应用程序。对于此数据集，首先通过Google Play商店API获取每个类别中前100个应用程序的列表。然后使用ApkDownloader工具单独下载每个APK文件。
4 MEASURING CRYPTO API MISUSE
本节介绍和讨论109,642个APK文件的分析结果，这些文件至少有一次调用密码学API。
4.1 Preprocessing
反汇编
与CryptoLint不同的是，作者为了提高分析的可靠性，使用ApkTool反汇编为一组Smali文件。，而不是像CryptoLint使用的AndroGuard作者能够分析三个数据集中除6个应用程序之外的所有应用程序，而CryptoLint无法分析原始数据集中23％的应用程序。 在反汇编应用程序后，搜索其生成的所有Smali文件，以找到密码学API的入口点。 如果未找到此类入口点，则无视该应用程序进一步分析。 否则，进行重复数据删除步骤。
重复数据删除
对于每个数据集，作何分别生成了所有APK文件名列表，相应的应用程序ID及其下载时间。 然后，作者通过使用相同的应用程序ID对文件进行分组来识别数据集中的所有重复项。 对于数据集中已识别的重复项，则保留了最新的版本。
4.2 Linting
为了评估2中定义的规则，BinSight检查在对密码学API的调用程序片段，然后从这些片段中提取必要的信息以检查是否违反了相应的规则。主要分为三个步骤：
超级控制流程图提取
BinSight按如下方式构造预处理应用程序的sCFG：首先，它从Smali文件中提取所有方法的程序内CFG。，并提取应用程序中所有类的类层次结构。之后，BinSight将控制流图叠加在各个方法的CFG上，从而生成sCFG。与CryptoLint类似，BinSight在调用指令和方法入口点之间添加调用边。与CryptoLint类似，BinSight重建了应用程序的过度近似的sCFG。
目标静态程序切片
BinSight在sCFG上应用静态程序切片，以识别分析的应用程序是否使用任何API。BinSight在sCFG中搜索属于Java的密码学API端点的节点。如果找到这些节点，它将使用其传入边缘来定位应用程序中的所有调用来源。
对定义的规则进行检测
规则评估取决于分配给crypto API调用参数的值，其中值赋值可以是包含方法的本地或外部。对于早期的情况，BinSight计算程序的后向切片到所有可能的位置，其中设置了所涉及的参数，之后对其值应用验证逻辑。
4.3 归属
混淆分析
作者把混淆分类分为不更改标识符，仅重命名类，重命名类及其部分包，或重命名整个类标识符。对于前三个级别，如果包名称具有可识别的前缀，可以将类映射到库或应用程序。至于第四级，则不能将包名称用于源归属。如果不确定的话，还可以使用BinSight GUI来检查类的内部及其源文件名（如果可用）。
第三方库
作者将包名称分为以下四类之一：应用程序（app），库（libs），可能的库和混淆。首先，作者将已经完全混淆的所有包名称分配到模糊类别。然后在单个应用程序中找到的所有包名称分配给类别应用程序。对于在两个或更多应用程序中找到的其余包，作者根据每个数据集中使用它们的应用程序数量对它们进行排序，然后按排名的降序执行手动检查。对于每个包名称，如果能够找到库源或网站，将包名称标记为库。此外，如果不行，同样还可以使用BinSight的GUI进行手动检查。
7 EVALUATION
出现至少一此密码学API误用的APK文件和调用的比率。 “所有”类别结果基于所有调用，而不考虑源（即库或应用程序）。 Libs和Apps代表源自库或应用程序的APK文件。
类名混淆分类和比例：
使用最多的五中加密方式：
误用密码学API的比率APK文件（a侧）和调用（b侧）。 每个子图将所有调用分解为四个已识别的源，例如库和应用程序。
