论文：Mobile app identification for encrypted network flows by traffic correlation
作者：Gaofeng He, Bingfeng Xu, Lu Zhang and Haiting Zhu
地区：China
时间：2018
来源：International Journal of Distributed Sensor Networks

---

介绍

手机App与IoT（物联网）

• 越来越多的IoT设备可以通过手机来控制
• 手机app已经成为IoT世界的核心

手机App的安全挑战

• 移动设备产生的流量已经达到网络流量的49%
• 手机App产生的流量往往是有迷惑性却不加密的流量，用户隐私受到威胁
• 恶意App使流量显著增加，造成网络阻塞
• 由于手机暴露于诸多场所，因此App更容易受攻击

问题所在

• 通过网络流量来识别App很困难
• App的数据传输使用HTTP/HTTPS，因此传统的基于IP或端口的识别方法不起作用
• 目前大多数研究都针对于HTTP的payload进行识别分类，而HTTPS加密payload，因此无法识别
• AppScan是一种用机器学习来识别加密流量的工具，但是其模型训练和更新代价很大

---

预先工作

App识别问题

定义所有在网络中可以观察到流量集合为F，所有在平台上运行的apps集合为A。

F = {f1,f2,..,fn}
A = {a1,a2,...ap}

需要解决的问题在于找到映射关系：

M[F,A] : fi -> aj (1 ≤ i ≤ n, 1 ≤ j ≤ p)

且上面的映射关系是一个 “many-to-one” 关系。

而针对于一个加密流量e_f，问题就变成：

E[ef,A]: ef -> aj (1 ≤ i ≤ p)

这是一种特殊的app识别场景，也是一种 “many-to-one” 关系。

手机App构架

作者认为了解手机App的框架可以更好地理解手机App流量的特征，而在2017发布的统计数据显示，安卓用户达到了86%，因此作者只关注安卓手机的框架。

上图是安卓手机通信之间的交互示例，App中显示信息的是“Activity”，点击按钮实际上是在不同Activity之间的切换。如果不杀死进程，那么App仍然会跑在后台，这样设计是为了让用户更快返回App。

安卓Apps之间的网络通信

由于大部分安卓App使用HTTP/HTTPS去传输和接收数据。因此Apps之间的网络通信实际上和Web通信差不多：

也就是App先去DNS查询目标主机的ip，然后建立TCP连接并通过HTTP(s)传输数据。如果已经查询过了目标主机的ip，那么就跳过DNS查询这一步直接建立连接。

---

移动端App流量观察

作者在这一章节中提出了在对App流量长期观察中发现的三大现象，这3种现象将作为整个文章的思想和实验基础。作者提到是和中国最大的网络运营商合作，才拿到了大量的流量数据（3G和4G），数据总量达到了160GB。

观察一

一组关于服务器主机的查询是可以用来区分不同App的。

上图左侧是百度地图（com.baidu.BaiduMap）查询的主机集，上图右侧是百度搜索（com.baidu.searchbox）查询的主机集，可以看出，虽然二级域名相同，而且是同一个企业名下的产品，他们查询的服务器主机组仍然是不完全相同的。那么这样一组主机名就可以作为识别App的特征。

观察二

手机App会在短时间内发起多个DNS查询请求（同时查询多个服务器主机IP）。

上图是百度地图（com.baidu.BaiduMap）查询主机时发起DNS请求的时间戳，可以看到这组主机发起查询的时间间隔在1秒以内。因此作者假定一组并发的DNS查询来自于同一个应用，可以根据时间信息进行分组。

观察三

同一手机App产生的加密流量与其他流量具有相似性。

在上图中，末尾的61.135.185.197是未知应用产生的流量，而其在时间上与199.75.22.71这一IP产生流量的时间节点十分相近，且在ip结构上与61.135.186.152这一IP相近，而以上两个ip的主机组都是百度地图（com.baidu.BaiduMap）的，因此61.135.185.197也是由百度地图产生的（实际上也确实是由百度地图产生的）。

作者就是基于这一发现来识别加密流量。

---

方法

这一章节作者提出了“关联流量”的定义，并提出了DNS聚簇和相似流量检索两种核心技术。

关联流量

一个加密流可以与一组流量关联起来，这组流量就称为“关联流量”（比如DNS或HTTP）。“关联流量”是可以被快速识别属于哪个App的，所以一旦一个加密流的“关联流量”能够找到，那么加密流就能被识别。

定义

对于“关联流量”的定义如下：

1.对于需要DNS查询主机IP的流量，其关联流量定义为其DNS查询流量。
2.对于直接通过IP进行连接的流量，其关联流量定义为“相似共同流量(similar common traffic)”。

对于“相似共同流量”的定义如下：

1.共同流量，指对发起DNS查询前的数据流量
2.相似流量，指外部特征相似的数据流量（如IP，时间，包长等等，但不考虑数据包具体内容）

思路与挑战

作者的思路是找到加密流量的关联流量，虽然加密流量难以提取主机名，但是关联流量很容易，而且提取的主机名集可以用来识别App。

挑战在于两点：(1).后台流量容易混淆。(2).不同App可能会调用相同的服务并查询相同的主机名

识别特征构造

在上图中，在完成主机域名提取后，主机域名集会送往识别特征构造模块，实际上就是通过 “.” 来对域名进行分割，然后提取“域名词向量”作为特征，值得一提的是，二级域名和顶级域名不分离。在进行训练时，每个App都会将匹配的特征保存。

DNS聚簇

目的：使用DNS聚簇去发现加密流量的关联DNS查询，而主要问题在于克服后台流量的混淆。
具体算法如下：

我们分析一下算法的输入和输出，输入有以下几个：
1.加密流发起的DNS查询q_i
2.DNS查询流量集合Q
3.以及三个阈值参数。
输出则是：关联的DNS查询集C

作者通过该算法进行DNS聚簇，找到关联DNS查询流量。

相似流量检索

通过在特征空间比较流向量来需找相似流，具体的特征如下，一共有12种。

而两个流量之间的相似度是使用加权欧式距离来进行计算评估的。而在计算距离之前，会使用缩放技术将流向量特征值控制在[0,1]这个区间内，具体算法如下：

在完成对流向量的特征值的重构后，再使用加权欧式距离来评估两个流的相似度：

这个距离的值越小，则两个流量越相似。而在权重值方面，作者设置w₁和w₂的值为1/3, 其他的权重皆为1/30。这说明作者认为IP地址和流起始时间的重要性更高。然后距离最小的流会被选择作为加密流的关联流量。

主机名匹配以及App识别

在获取主机名集后，需要根据主机名来匹配App。前面提到每个App已经建立了特征集，而作者使用TF-IDF算法来进行这一步的主机名匹配。TF-IDF是一种用于信息检索与数据挖掘的常用加权技术，一般用于文本分析。TF-IDF的思想在于，如果一个词在文档中出现的频率高，但是在其他文档中出现的次数少，那么该词就能够作为分类该文档的依据。具体可详见：生动理解TF-IDF算法。这里针对作者的思路进行简要说明：

一条域名记录可以被表示为：

W = {w2,...,wk}

由于看到w的下标是从2开始，这是因为二级域名和顶级域名没有分离。首先计算每个词的在I_doc中的词频(I_doc指App的特征文档)：

然后计算逆文档频率，词料库是所有的App特征文档：

通过词频和逆文档频率计算这个词的weight：

最后将所有的词weight相加计算分值：

接下来将每个App的特征文档分值计算出来，取最高的App计数加一，然后换下一个域名记录进行计算，当主机名集中所有的主机名都被计算后，取App计数最大的作为识别的App。具体算法如下：

从上面的算法可以看到输入是一组主机名（关联流量中提取的），而输出则是识别的App。

---

实验

数据收集

实验环境

操作系统：Ubuntu 16.04
流量收集工具：tcpdump
数据分析环境：4GB内存和处理器 Intel Pentium Dual-Core T4500 CPU
训练阶段：使用安卓模拟设备，并使用UI-fuzzing工具来模拟点击操作生成流量。由于这一步是为了得到App的识别特征，因此只有DNS流量会被抓取。
测试阶段：使用HUAWEI Mate 8

运行

App下载器：Evozi App Downloader
App下载源：Google Play，Wandoujia（下载url结构简单，方便用python程序爬取）
App安装：adb install
点击模拟：UI-fuzzing from Monkey，通过随机点击生产大量流量数据
数据输出：使用tcpdump捕捉数据并保存成.pcap文件，每个文件的大小约为100MB
TCP和UPD流的剥离：SplitCap
DNS流量分析以及主机名提取：Dshell
主机名匹配：Soar和Packet Capture

流量产生

需要找到生成加密流量的应用，而这一步是手工检测的。作者下载了100款Google Player的应用以及900个Wandoujia上的应用，他们安装并运行应用，然后观察是否产生的加密流量。每个App只在启动的时间段内是否生成了至少1条加密流量，最终作者选择了100个App作为测试集。

对于识别测试，每个App会一个接一个安装在手机上，然后随机运行3分钟，抓取到足够的流量后，杀死后台程序。这样的流程一共执行了5次。最后一共2305条加密流量被抓取，整个测试集的数据量如下：

实验结果

评估方法

实验中使用三个指标来评估实验结果，分别是Accuracy, TPR, FP。这三个指标的计算方法如下：

其中，函数Nfun(pare)指的是参数pare中流的数量。比如，Nfun(identified_all)指的是所有成功识别的流量数量，Nfun(encrypted_all)指的是所有加密流量的数量。而TPR和FP指标是针对某个APP的。

使用主机名识别App的效率

这是实验只要是作者为了证明自己所选取特征的好坏。前面提到，作者是将一组主机名作为识别App的特征，而每个App都有属于自己的特征集，那么如果App的特征集很相近，那么识别率就不高，因此作者决定先评估特征集之间的距离。评估距离的公式如下:

作者为100个App都做了测试，然后举了下面4组比较作为例子：

值越小，特征距离越近，可以看到BaiduMap与自己的距离是0，和seachbox之间的距离是0.343（比较接近），而与zhihu以及netease之间的距离基本上到了1（很远）。

接下来作者测试了在不同时间和版本下App特征的稳定性：

实验表明，在不同时间下和版本下相同App的特征集距离很小，即很相近，基本上不会变化。

评估DNS聚簇效果

在作者选择的2305个加密流中，有1873条加密流需要DNS查询，有432条流是直接通过IP进行连接的。在DNS聚簇的算法中，有3个阈值参数，首先作者设置DNS查询间隔的阈值为1s，app时间间隔为7s（一个app完全关闭到另一个app开启的间隔），然后对词汇相似度进行调整（0.1-0.7）进行实验，实验结果如下：

可以看到，词汇相似度的阈值设置为0.4时，无论是Accuracy还是TPR都达到了巅峰，且精确度已经达到了95%。在图10可以看出，由于BaiduMap和searchbox的特征集距离小，所以他们可分类度低，故FTR值较低，而zhihu和netease的FTP值就很高。FP值也能很直观地表现出来（有一点问题）。

评估相似流量检索效果

作者在这一块主要研究在进行相似流量检索时，关联流量数量与识别精确度的关系。作者针对不同关联流量数量分了组进行了实验，实验结果如下：

从上面的结果可以看出，在关联流量数量为7时，实验效果最好，精确度达到81%。而TPR和FP都呈现出了和DNS聚簇时相同的规律。

优化

增强训练过程

作者提出的第一步优化思路是提取更多的主机名集作为app的特征。作者使用的方式是直接反编译apk文件（dex2jar），去搜索java源码中的主机域名（以https和http进行匹配）。作者提出有些主机域名是不完整的，比如 http://+str.substring("*.".length()).m3587f()，因此动态地运行app抓取主机域名还是有必要的。

可以从上图看出，虽然训练时间变长了，但是提取的主机域名变多，而这样的代价是否值得还有待商榷。

优化相似流量检索方法

作者提出的第二个思路是在对App进行识别时，在原主机名匹配技术的基础上加上key-value匹配技术。实验中的key-value大致如下：

因此在算法2中进行了修改，如果是HTTP流量，则需要检测key-value，如果匹配的话，计数+1：

在算法修改后的实验结果如下：

比起之前的实验，准确度已经从81%上升到了93%。

比较与限制

最后就是常规的吹牛批环节，作者将自己的实验与AppScan进行比较，说明自己提出的方法很牛批，不但检测时间快，资源消耗少，而且精确度也差不多（作者提到自己的实验中准确率最高时能达到95%-96%，而Appscan只能达到94.7%）。

然后作者提出自己方法中的三个缺点：
1.无法实时检测，需要一段时间
2.后台app定时产生的一些加密流量无法识别，因为找不到关联流量
3.没法识别新增的流量

---

WhiteRabbit评论：

这篇文章无论是结构还是思路都十分清晰，在实验部分的设计也不错，层层递进。这里还是提出一点不足和思考。

文章作者：WhiteRabbit
来源：blog.whiterabbitxyj.com
转载请标注原文和作者。