基于DPI的应用指纹自动提取方法研究

饶亲苗 彭艳兵

1(武汉邮电科学研究院 湖北 武汉 430000) 2(南京烽火天地通信科技有限公司 江苏 南京 210000)

0 引 言

在移动网络中，如果要隔离恶意或者受感染的应用程序，就需要区分单个应用程序的流量，即需要进行移动网络流量识别。移动网络流量识别对移动网络的安全性和网络管理影响重大，其关键是将数据流量对应到单个移动应用程序，然而识别互联网中成千上万的移动应用无疑是一个颇具挑战的任务。

此前也有过不少移动网络流量识别的相关研究。文献[1]使用C4.5和SVM这两种机器学习方法来分类移动应用程序产生的流量，且得出了机器学习方法能够较好地识别移动音视频流量的结论。文献[2]使用二维卷积神经网络模型分类卷积神经网络模型分类六款聊天类移动应用流量，平均准确率达99.15%，召回率达99.11%，F调和值达99.13%。但目前机器学习的方法始终没有办法分类大规模移动应用程序产生的流量，且难以适应复杂的现网流量背景。

本文提出的方法基于DPI[3](Deep Packet Inspection)，其关键点是从不同来源提取能有效识别应用流量的特征字符串，然后将它们组合成应用指纹。文献[4-6]利用HTTP报文头部中User-Agent、Host等字段来识别移动网络流量，也说明了提取HTTP报文头部中某些字段作为特征字符串能有效识别应用流量。文献[7]利用从移动应用apk安装文件反编译出的Manifest文件中的唯一标识，来分析热门应用广告流量可能给客户端、用户带来的风险。文献[8]也反编译apk文件，并提取其中广告库的元信息(appID、package等),然后根据HTTP报文头部中的Host字段识别广告流，即可用广告库中的应用标识符来识别应用。上述工作也说明了提取Manifest文件中某些字段作为特征字符串能有效识别应用流量。

本文从上述两个来源提取特征字符串，制定评分模型选取可以有效识别移动应用的特征字符串并组合成应用指纹，用于识别流量。实验结果表明本文提出的基于DPI的应用指纹自动提取方法在应用覆盖率、流覆盖率、字节覆盖率三个方面都表现优异。

1 本文假设

绝大部分应用在与它们的服务器或者第三方服务通信过程中都用到了它们真正的识别码[9]。识别码，即可以唯一标识一个移动应用的字符串或者字符串组合，可能是以下两种形式：(1) 具有显式含义的字符串；(2) 具有隐式含义的字符串。

以百度网盘这款应用为例，从其报文中提取出来的特征字符串可以看到：“pan.baidu”是从域名中提取出来的特征字符串，且具有显式含义；而“wxdcd3d073e

47d1742”是百度网盘应用的AppId，它具有隐式含义，因为无法直观地把这个字符串与百度网盘这款应用关联起来。

在这个假设的前提下，本文提出一种基于统计的自动特征提取方法，然后将每个应用的特征组合成应用指纹，用于识别应用产生的流量。

2 算法框架

基于应用指纹的流量识别算法的框架如图1所示，可分为四个部分。前期离线的报文处理模块与特征处理模块负责把报文组合成流，然后从报文中的指定字段提取字符串，接下来统计字符串在每个应用的所有报文中出现的次数，形成一个二维矩阵，其中：行为字符串，列为移动应用，中间为字符串在每个应用的所有报文中出现的次数。最后通过评分与特征精简策略确定每个应用的特征字符串，将特征字符串组合成为应用指纹。在线的报文处理模块的功能同上。标记器模块负责将每个应用的应用指纹放到报文中匹配，将命中的数据流打上该应用的标签，即为已标记流；将没有命中的数据流标记为未知流，留作后续处理。

图1 基于应用指纹的流量识别算法框架

2.1 特征来源及特征提取

基于本文提出的假设，理论上凡是与移动应用和服务器通信过程有关联的字段都可以作为提取特征的来源。后文验证了HTTP协议报文中的“Host”“User-Agent”字段及HTTPS协议“ClientHello”报文中的“ServerName”字段对于识别应用流量帮助极大。此外，与通信过程的关联程度较强的字段还有服务器端的IP、端口号、应用端请求资源的URL字段。本文研究的是安卓平台移动应用流量识别，移动应用在移动设备上使用前，都有在移动设备上安装“.apk”文件的过程。已有研究表明，从“.apk”文件反编译出来的AndroidManifest.xml文件中存在可以有效识别该应用的域(字段)——AppKey、package等，例如“name=‘XM_APPKEY’android:value=‘@7F081886’”及“package=‘com.baidu.netdisk’”。

综上所述，本文初步选定的特征来源及字段处理方法如表1所示。图2为HTTP协议的User-Agent字段。

表1 特征来源及字段处理方法

图2 HTTP协议User-Agent字段

2.2 应用指纹生成

按照2.1节描述的方法处理所有字段后，将生成一个特征字符串集合。遍历该集合中的每个特征字符串，统计其在所有移动应用数据流中出现的次数，并将统计结果以二维矩阵的形式保存，如表2所示，每行关联到一个特征字符串，每列关联到一款移动应用，用“*”标记的特殊列是该特征字符串与所有应用关联的总次数。

表2 特征字符串在数据流中的匹配统计结果

接下来要解决的问题是如何判断哪个特征字符串能准确地识别出哪款移动应用产生的流量。对此，本文提出了两种解决方案。

1) 根据关联次数占比选取特征。根据特征字符串在数据流中的匹配统计结果，可以得出每个特征字符串与某一移动应用关联次数和每个特征字符串与所有移动应用关联总次数的比值：

(1)

2) 根据评分模型选取特征。评判某一特征字符串能否准确识别某一移动应用流量，除了考虑这个特征字符串与这一移动应用关联是否紧密之外，还要考虑这个特征字符串与其他移动应用关联是否紧密。因此，本文提出一个特征字符串评分模型：

(2)

(3)

Scoreti→Appx=TFti×IDFti→App*

(4)

式中：Nti→Appx表示特征字符串ti与移动应用Appx关联的次数；Nti→App*表示特征字符串ti与所有移动应用关联的次数；TFti→Appx表示特征字符串ti与移动应用Appx关联的紧密性；|Appti|表示与特征字符串ti有关联的移动应用的个数；|App*|表示实验考虑的所有已知移动应用的个数；IDFti→App*表示特征字符串ti与其他所有移动应用关联的不紧密性；Scoreti→Appx表示特征字符串ti识别移动应用Appx时的评分，即某一特征字符串ti与某一应用Appx关联越紧密，与其他所有应用关联越不紧密，此得分越高。对于某一已知移动应用Appx，得分更高的特征字符串更能准确地识别出其产生的数据流量。

如果某一特征字符串ti与两个移动应用Appx1、Appx2的关联都比较紧密，会导致Scoreti→Appx1和Scoreti→Appx2的取值都比较高，但是这个字符串原则上不能作为识别这两个移动应用的特征字符串，考虑到这种情况，本文采用式(5)来过滤掉这种特征字符串。

(5)

不论是采用方案一还是采用方案二，最后每个移动应用都可以得到一到多个特征字符串，将每个移动应用的一到多个特征字符串组合起来，作为识别该移动应用的应用指纹。

3 实 验

3.1 实验数据

本文采集了134款移动应用产生的流量，共176 596条流。按照2.1节中描述的特征处理方法处理采集的数据，得到特征字符串集合，然后遍历该集合中的每个特征字符串，统计其在所有移动应用数据流中出现的次数，并将统计结果保存为二维矩阵。

3.2 评价指标

为了衡量两种特征选取方案的有效性，本文选用应用覆盖率、流覆盖率、字节覆盖率作为评价指标。

应用覆盖率即是所选取的特征字符串所能识别的所有移动应用的个数与实验所选取的移动应用的总个数的比值。假设：Appti表示特征字符串ti所能识别的移动应用；∪ti∈T*Appti表示每个特征字符串所能识别的移动应用的并集，即所选取的特征字符串所能识别的所有移动应用的集合；|∪ti∈T*Appti|表示该集合中移动应用的个数；|App*|表示实验考虑的所有已知移动应用的个数。应用覆盖率可表示为：

(6)

流覆盖率即是所选取的特征字符串所能识别的所有数据流的个数与实验所选取的所有移动应用的数据流的总个数的比值。假设：Flowti表示特征字符串所能识别数据流；∪ti∈T*Flowti表示每个特征字符串所能识别的数据流的并集，即所选取的特征字符串所能识别的所有数据流的集合；|∪ti∈T*Flowti|表示该集合中数据流的个数；|Flow*|为实验所选取的所有移动应用的数据流的总个数。流覆盖率可表示为：

(7)

字节覆盖率即是所选取的特征字符串所能识别的所有数据流的字节大小与实验所选取的所有移动应用的数据流的总字节大小的比值。假设：Byte∪ti∈T*Flowti表示该集合中数据流的字节大小；ByteFlow*为实验所选取的所有移动应用的数据流的总字节大小。字节覆盖率可表示为：

(8)

3.3 实验结果分析

3.3.1服务器端IP、端口号作为特征来源的可行性分析

分析实验中生成的特征字符串集合，共25 293个特征，特征来源的分布如表3所示。

表3 特征来源分布

由表3可以看出，服务器端IP占比非常高，达到了51.2%。从本文算法的原理来看，每增加一个特征，都会降低流量识别效率，因此将服务器端IP作为特征来源不能非常准确地识别应用产生的流量，必将得不偿失。由前文得知，由于CDN网络、云服务的广泛运用，使得仅利用服务器端IP并不能准确地将某一条数据流定位到某一款移动应用。综上，本文决定在实验验证算法有效性时暂时不把服务器端IP作为特征来源。

本文在研究大量数据流量报文时发现，加密协议的端口是比较稳定的，HTTPS协议一般情况下在服务器端都是利用“443”端口与客户端进行通信，而其他协议的服务器端通信端口号则不太稳定。而且，端口号是由字符长度为2～5个字符的纯数字组合而成，根据本文算法的原理，在数据量巨大的互联网环境中，由于随机性的存在，在统计特征与应用产生的报文的关联次数时极其容易误命中。综上，本文决定在实验验证算法有效性时暂时不把服务器端IP、端口作为特征来源。

3.3.2两种特征选取方法的优劣性分析

对于从特征来源提取的诸多特征，2.2节介绍了两种特征选取方法：(1) 根据关联次数占比选取；(2) 根据评分模型选取。

为了选定一种在应用覆盖率、流覆盖率、字节覆盖率都表现更好的特征选取方法，本文设置了两组实验。第一组利用根据关联次数占比的特征选取方法选取特征，并将特征组合成应用指纹来识别实验提供的数据集；第二组利用评分模型的特征选取方法选取特征，并将特征组合成应用指纹来识别实验提供的数据集。统计实验结果，以QQ等10款移动应用为例展示实验结果。应用覆盖率的比较如表4所示，采用评分模型选取的特征组合成应用指纹来识别移动网络流量时，应用覆盖率明显提升；流覆盖率和字节覆盖率的比较如表5所示，采用评分模型选取的特征组合成应用指纹来识别移动网络流量时，流覆盖率和字节覆盖率均明显提升。

表4 两组实验应用覆盖率

表5 两组实验流覆盖率和字节覆盖率

3.3.3Manifest文件作为特征来源的可行性与必要性分析

AndroidManifest.xml文件描述了移动应用的必要信息，并提供给Android编译工具、Android操作系统，以及应用商店，具体如下：

(1) 声明与代码的命名空间相匹配的应用包名。Android编译工具在编译项目的时候通过应用包名定位代码实体的位置。在应用进行打包的同时，编译工具使用Gradle编译文件中的application ID与该应用包名进行替换。以此作为应用在Android操作系统以及应用商店的唯一的标识符。

(2) 应用的组件。包括应用中所有的Activity、Service、Broadcast Receiver、Content Provider。

(3) 应用所需要访问的权限。

(4) 第三方库的引用等。

本文只选取AndroidManifest.xml文件中移动应用开发时的应用包名“package”域以及移动应用的唯一标识符“AppId”域、“AppKey”域，并且提取这三个域的逆向工程全部可以自动化实现，因此将Manifest文件作为特征来源是可行的。

在提取的过程中发现，所有的移动应用安装文件中都可以提取出“package”域，但是并不是所有的安装文件都可以提取出“AppId”域和“AppKey”域，具体情况如表6所示。

表6 从应用安装文件中提取特征情况

为了验证Manifest文件作为特征来源的必要性，本文只选用“package”域、“AppId”域、“AppKey”域作为特征来源，利用2.2节所述评分模型提取特征，并将特征组合成应用指纹来识别实验提供的数据集，结果显示仅用Manifest文件作为特征来源应用覆盖率可达61.67%。

为了验证Manifest文件作为特征来源在流量识别的流覆盖率和字节覆盖率上的有效贡献，本文设置两组实验。第一组仅用从HTTP报文、HTTPS报文中提取的字段作为特征来源，不用Manifest文件作为特征来源；第二组既用从HTTP报文、HTTPS报文中提取的字段作为特征来源，又用Manifest文件作为特征来源。以ES文件浏览器等12款移动应用展示实验结果，如表7所示。

表7 两组实验的流覆盖率与字节覆盖率

可以看出，在原有HTTP、HTTPS报文字段的基础上，增加Manifest文件作为特征来源，在识别移动应用流量时流覆盖率和字节覆盖率均有提升。在第一组实验中，ES文件浏览器、墨迹天气等应用产生的流量没有被识别出来，但是这些应用流量在第二组实验中被识别出来了，也说明增加Manifest文件作为特征来源能有效提高本文方法对于识别移动网络流量的应用覆盖率。

4 结 语

本文提出的通过全面观察移动应用产生的流量报文，来自动学习移动应用指纹的方法，用于识别移动网络流量时在应用覆盖率、流覆盖率、字节覆盖率三个方面的表现都很优异。该方法的核心是构建特征字符串与移动应用相关联的二维矩阵，在某一给定网络环境下，这个二维矩阵具有行可扩展性，在新增特征来源时，不用改变矩阵列属性，仅需统计该特征与所有移动应用的关联信息，在二维矩阵中增加一条行记录即可。但这也正是此方法的缺点所在，当网络环境有所变化，即已知移动应用增加时，需要重新统计每个特征与所有移动应用的关联信息，耗费巨大，这也是未来须努力研究与改善的方向。