一个可伸缩的高分辨率加密流量识别引擎

摘要

一些安全应用程序依赖于监控网络流量，而网络流量正日益加密。在这项工作中,我们提出一个模式语言来描述包列车为目的的细粒度加密网络流量识别应用程序级的事件,并演示其表现力与案例研究区分消息,声音和视频事件在Facebook, Skype推出,WhatsApp网络流量。我们提供了这种语言的有效实现，并通过将其集成到我们专有的DPI系统中来评估其性能。最后，我们证明了所提出的模式语言可以自动地从流量样本中挖掘出来，从而最大限度地减少否则会带来的高规则集维护负担。

1 引言

近年来，网络流量加密的应用不断增长。移动应用程序使用SSL/TLS协议来保护通信安全，一些应用程序实现端到端加密来保护用户的隐私。研究表明，超过60%的移动应用程序流量现在使用SSL/TLS[25]。网络流量分析通常基于深包检测(DPI)等技术。传统DPI实现的核心是基于模式匹配的，它支持在包内容中搜索特定的字符串或正则表达式。DPI的应用包括但不限于防火墙、入侵检测和预防系统、反病毒系统、L7过滤和包转发[33-35]。随着网络加密技术的广泛应用，依赖于纯文本模式匹配的DPI工具的效率越来越低，要求开发更复杂的技术。

在这项工作中，我们只专注于分析由所谓的over

- top (OTT)移动应用程序生成的加密流量——这是流量的最安全关键(过滤、策略执行)来源之一。传统的DPI实现只能为大多数此类通信提取非常粗粒度的信息。然而，它的分析是许多网络系统的一个整体操作，需要改进，以便为OTT应用程序提供详细的流量指标。为此，我们实现了一个能够从移动应用程序生成的加密流量中提取基本信息的系统。包含即使使用加密的流量也可用的元数据，如包时间戳和大小——可以从包头或定时信息中提取这些信息。在这项工作中，我们将重点放在使用包大小的传输模式来识别OTT应用程序事件，例如消息、语音和视频呼叫的加密通信。我们提供了一个完整的实现，作为DPI引擎的一部分，它支持在传统子字符串和端口号模式的基础上使用包火车模式(使用消耗包大小的自动机匹配)来支持规则集，从而有效地匹配和报告加密网络流量中的事件。图1显示了我们方法的高级概览：

高级概览:离线收集流量样本，然后手动或使用数据挖掘创建签名。签名被提供给我们的DPI引擎，并编译成一个自动执行的实时流量只保留使用统计数据。

在这项工作中，我们做出了以下贡献：

---我们讨论了一种实用的方法来收集、标记和分析由流行的移动OTT应用程序(如Skype、WhatsApp、Facebook Messenger和Viber)生成的加密流量，以识别消息、语音和视频通话等使用事件。

---我们提出了一种模式语言来识别适合于DPI系统的事件，同时又有足够的表达能力来描述包元数据模式，我们通过实验证实了这一点。

---我们讨论了我们的模式语言的高性能实现，并将我们的实现与DPI引擎集成，以评估它在大容量实际网络流量下的性能

---我们演示了我们的模式语言能够从地面真实样本中自动挖掘。

2加密的流量模式语言

在我们的分析过程中，我们观察到包有效负载大小的特定序列可靠地表示应用程序内部的离散事件。在本节中，我们将描述我们提出的模式语言，以在网络流量中表达这种模式。

2.1设计目标

       我们的目标是使用一种表达能力强但足够简单的语言来促进规则的自动挖掘。虽然可以在规则构建过程中使用离线挖掘技术，但是我们需要在运行时支持非常高效和低延迟的规则实时流量评估，以便在生产质量DPI（深度报文检测）系统中使用。对于实际系统的另一个考虑事项是最小化DPI引擎需要维护的每个流的状态信息量，以便评估相同流的包之间的模式。这些要求使我们得到了一个简单的regex（正则表达式）启发公式，应用于观察到的包大小的火车（一组报文串）上。我们的方法的优点是，它可以用一个自动机实现，而不需要保留以前观察到的包大小来支持端口回溯，而且它的表达能力足以捕获感兴趣的流量特性。

2.2模式语言规范

       表1显示了我们在分析阶段提取的一些规则示例。建议的模式语言使用正则表达式启发的语法，并且易于遵循，因为它类似于标准正则表达式。当网络流包含这些预定义的有效载荷分组大小的序列时，通过规则表达并结合任何其他传输特性（例如端口号或子串），则报告应用事件。例如，当捕获的网络流包含一系列分别具有3字节和52字节的有效载荷（payload）的两个分组时，则我们的系统报告存在传出的聊天消息。

Table 1. 应用程序事件规则的示例.

Event（事件）Application（应用）Rule（规则）

Voice call（电话）WhatsApp3{1,3}, 56-60{1,3}, 400-800

Video callWhatsApp3{1,3}, 56-60{1,3}, 3{1,3}, 117 OR

  3{1,3}, 56-60{1,3}, 3{1,3}, 144

Chat messageWhatsApp3{1,3}, 52

非正式地，规则表达式由一个或多个以逗号分隔的片段组成。每个部分都是一个带有可选边界的原子。原子是单个数字或数字范围，其中数字是正整数。该边界指定精确或放松（具有最小和最大包含限制）原子的重复次数。表2中列出了正式定义。

我们的建议可以扩展到额外的表达性，例如通过添加其他正则表达式构造，例如组或析取。在这项工作中，我们将模式语言的复杂性保持在最低限度，以避免复杂的挖掘过程。特别是，通过提供一组析取规则来处理析取，而不是使用嵌入式析取算子扩展语言语法。缺点是可能需要更大的模式集。我们没有发现这在实践中是一个问题。

Table 2. 规则语言规范;

number是正整数.

expr ::= piece | piece, expr

piece ::= atom | atom{bound}

atom ::= number | number-number

bound ::= number | number,number

1我们丢弃仅设置了ACK标志的TCP数据包。 保留PUSH / ACK数据包。

2通过数据集集合，我们根据应用程序使用了不同的应用程序版本。 这使我们能够验证我们的方法的泛化能力和可扩展性。

为了处理重新传输的TCP数据包，我们可以（i）在通过丢弃此类数据包应用规则之前对流量进行规范化，或者（ii）形成表达式以相应地处理重新传输的数据包（如表1中的规则）所显示的表达式能够处理具有重复范围{1,3}的重传分组，其中3是上限（最大重传次数）。但是，通过表达式处理重传可能存在风险。重新传输数据包是一种不可预测的网络行为，因此我们可能会因为表达式重复范围中未正确定义的上限而丢失应用程序事件报告。因此，我们选择通过在包过滤阶段丢弃它们来处理重传的TCP包。

3 效果估计

       在本节中，我们通过手动为一组应用程序事件生成模式签名并评估其准确性来演示所提出的模式语言的表现力。我们使用25％（随机选择）的地面实况样本作为人类分析师的参考，其余75％用于准确性评估（第3.3节）

3.1流动样本收集机制

我们将移动应用网络流量划分为流量。网络流由标准的5元组表示，其包含（i）源IP地址，（ii）源端口号，（iii）目的地IP地址，（iv）目的地端口号和（v）协议。然后，网络流由包含匹配某个5元组的数据包组成。为了对不同移动应用程序生成的流量进行分类，我们需要更多信息。此信息应包括域，进程名称或与特定网络连接相关的进程ID。有多种方法可以实现这一目标。例如[12] 12.      Conti, M., Mancini, L.V., Spolaor, R., Verde, N.V.: Analyzing

android encrypted network traffic to identify user actions. IEEE Trans. Inf.

Forensics Secur. 11(1), 114–125 (2016)，利用WHOIS协议进行域过滤。我们选择使用进程ID以获取有关每个网络流的所需信息。在下一节中，我们将介绍如何实现网络流量过滤。

流程匹配。 Netstat [3]是一个命令行网络实用程序，可以显示有关网络连接的信息。拥有超级用户权限，有人可以使用netstat(命令行命令)来确定拥有连接套接字的进程的进程ID（PID）和进程名称。在Android设备中，netstat可通过BusyBox应用程序[2] 2.    Busybox (android application).

https://play.google.com/store/apps/details? id=stericson.busybox&hl=en.

Accessed 09 Mar 2018获得。

包过滤。为了使TCP协议可靠地传递数据，它提供了许多机制来检测和避免不可预测的网络行为，如丢包，重复或重新排序。在所提出的方法中，我们选择丢弃不向流提供实质信息的分组（例如，重传的分组）。在我们提出的方法中，我们完全专注于处理数据包元数据。这意味着我们不考虑数据包有效负载，因为我们假设它是加密的。我们处理的信息仅仅依赖于数据包元数据，例如数据包方向和有效负载大小。因此，缺少有效载荷的数据包不会为我们的方法提供任何有价值的信息。为此，我们过滤掉ACK标记的数据包1

3.2生成样本traffic

       为了避免提取过度特定的应用程序事件模式，我们分析了在这些应用程序的实际使用过程中生成的traffic跟踪。此外，我们在固定和移动网络上都使用了设备。

设备变化。为了确保变化，我们使用了不同的设备，供应商，Android和内核版本。我们使用了四种不同的Android移动设备，一台Sony

Xperia D5503（Android v.5.1.1，内核v.3.4.0-gd26777b），一台Xiaomi Redmi 3s（Android v.6.0.1，内核v.3.18.20-g76f906f）），小米MI Note LTE（Android v.6.0.1，内核v.3.4.0-gf4b741d），最后是小米Redmi Note 3 Pro（Android v.6.0.1，内核v.3.10.84-gda78349）。为了获得完整的功能和特权，我们使用了专有的Android设备，并启用了开发人员选项。因此，我们能够从Google Play商店安装BusyBox应用程序，并利用通过单个可执行文件[2]提供的Unix实用程序，以及Android tcpdump工具来本地捕获设备上的网络流量[1]。另外，我们使用了Android Debug Bridge

（ADB）版本1.0.39和Wireshark 2.4.2。由于工具集的限制，我们在研究中未包含Apple设备。

OTT应用事件。我们选择了四种最广泛使用的OTT Android应用程序来评估我们的方法：（i）WhatsApp，（ii）Skype，

（iii）Facebook Messenger和（iv）Viber2。由于这些应用程序主要用于通信目的，我们专注于识别（i）传出聊天消息，（ii）语音和（iii）通过加密网络流量的视频呼叫。当然，我们的工作可以扩展到支持其他OTT应用程序事件，例如媒体交换（例如照片共享）以及iOS设备。

总的来说，我们收集了一组350多个样本3。每个单独的样本模拟使用上述OTT应用之一交换任意数量的外发消息（消息）或单个语音或视频呼叫。然后，对于每个样本，我们收集了（i）网络数据包跟踪，（ii）一个文件，其中包含在捕获流量期间打开的每个TCP套接字的信息以及创建它的过程信息，（iii）屏幕记录和（iv）包含Android报告的设备系统日志的文件 ADB工具，名为logcat。每个示例仅包含一个应用程序事件类型（例如sample0：Skype / messaging）。

为了验证，我们将检测到的应用程序事件与logcat（android logcat抓取app日志）输出和屏幕录制中包含的设备的系统日志进行比较。使用logcat文件和屏幕录制，我们能够与实际的事件交叉检查报告的事件。 Logcat是一个命令行工具，可以转储设备系统消息的日志。我们提取了/ off上的音频硬件，摄像机开/关等信息以及传入的聊天消息。不幸的是，我们无法识别与传出聊天消息匹配的系统事件。因此，我们必须使用屏幕录制来检查外出聊天消息离开的实际时间以及外发消息的数量。

3.3准确性评估

       命中率。表3显示了得到的正确性（true

positive）（TP）率。每个样本仅包含一个应用程序内事件类型（例如sample0：Skype / messaging，sample1：WhatsApp / voice）。当签名报告应用程序内事件（消息：0或1，语音：0或1，视频：0或1）时，我们将其与应用程序的实际事件进行比较。如果事件被正确报告，则TP计数器增加。否则，我们会出现误报（FP）。

       我们每个事件的方法的TP率是（i）93％的外出聊天消息，（ii）86％的语音和（iii）84％的视频通话。语音和视频通话的TP率略低，这是由于与FPs4的交互。我们发现，除了Viber之外，对于所有正在调查的应用程序，视频相关流程也包括与语音相关的流程，因此，视频事件也包括语音事件。另一方面，我们对Viber语音和视频事件的签名不遵循这一趋势，因为它们彼此不互补。因此，我们可以得出一个有趣的结论，即Viber应用程序的核心实现与所有其他正在调查的应用程序不同。

 

 

3这些样本是使用虚拟账户和非个人移动设备生成的。

表3.我们的方法的TP率。通过将我们的方法结果与实际地面实况数据集进行比较，提取所呈现的百分比。

ApplicationMessagingVoiceVideo

Facebook messenger83%96%96%

Skype88%100%75%

Viber100%54%88%

WhatsApp100%92%75%

虚假发现率。除了真正的积极因素外，评估我们的方法所需的另一个指标是每个应用事件的误报率。仅使用加密的网络流量报告移动应用程序事件可能被认为是有风险的，因为不能进行简单的交叉验证。正确报告事件的存在不仅具有重要意义，而且也不会错误地报告不存在的事件。表4显示了使用我们的签名5的事件报告的错误发现率。错误发现率始终低于8％。

签名的选择可以显着影响真正的正发现率和错误发现率之间的交易。具有宽松的签名定义导致几乎完整的TP率，具有高误报率的成本。类似地，更严格的签名定义给出令人满意的TP率，使误报率保持在低水平。我们确定了签名定义，导致命中率超过84％，错误发现率低于8％。

消息事件报告的粒度。使用我们的签名进行消息报告，与我们的地面实况数据收集相比，我们实现了93％的总命中率。该速率包括正确识别移动OTT应用程序内的消息传递事件（即传出文本消息）的存在。转向更精细的粒度，我们不仅能够显示网络流量跟踪中的消息传递活动，还能够准确地报告发送传出文本消息的时间，并计算在发送期间发送的文本消息的数量。消息传递会话，我们在Sect中展示的东西。

表4.该表显示了我们的方法的错误发现率。“Mes-saging FDR”列显示语音或视频样本中错误消息传递报告的百分比。“语音/视频FDR”列分别显示了消息样本中错误的语音/视频报告的百分比。

ApplicationMessaging FDRVoice/video FDR

Facebook messenger0%1%

Skype5.5%4.2%

Viber1%2%

WhatsApp8%0.6%

4在下一节中，我们将讨论签名形成如何影响TP和FP速率之间的平衡。

 

5错误发现率可以计算为F DR = F P /（T P + F P）。

4  实施和绩效

       在本节中，我们将讨论和评估我们提出的模式语言的实现。

4.1高效的自动机

       我们实现了一种数据结构，以便以流式方式将数据包序列与数据集进行有效匹配。 它的灵感来自字符串搜索算法，如Aho-Corasick [5]，但它不是字符，而是对表示为16位整数的数据包大小进行操作。

       Aho-Corasick算法是一种字符串搜索算法，用于在输入文本中定位有限字符串集的元素。它同时匹配所有字符串，因此其复杂性不依赖于搜索集的大小。它的工作原理是构造一个自动机，为输入文本的每个字符执行转换。为了使匹配数据包序列的算法适应，我们用16位数据包大小替换了8位字符。

       该算法构造了一个类似于trie的有限状态机，在内部节点之间具有额外的“故障”链接。当没有其他匹配转换时，遵循这些故障链接，并允许快速转换到共享公共前缀的trie的其他分支，而无需使用先前输入进行回溯。这允许交错大量并发搜索，例如在网络连接的情况下，因为匹配器的状态可以通过存储指向自动机的当前状态的指针而在不同时间点观察到的输入数据上被保留。为每个连接维护状态。否则，回溯将要求我们为先前看到的数据包大小维持昂贵的每流状态。

       为了获得额外的性能，可以通过预先展开故障链接并添加适当的转换以将每个故障直接映射到适当的节点来构建确定性有限自动机（DFA），而无需在运行时跟随多个故障链路。以这种方式扩展自动机在我们的情况下没有提供优势，其中针对每个数据包大小执行自动机而不是搜索子字符串时的每个字节，并且模式的长度和数量远小于典型的基于子串的规则集，因此我们选择了更紧凑的数据结构，其中在运行时遵循故障链接。然而，对于非常多的模式，这种优化可能是值得的.

       我们通过将模式语言扩展为n  -  m +1个单独的模式，实现了包含m-n范围的数据包大小重复。为了实现数据包范围，我们首先尝试将它们扩展为多个单独的16位字符，导致在宽数据包大小范围内存在过大的自动机，例如100-200 {3}，这将扩展到1003个不同的序列。为避免这种情况，我们使用范围而不是单个16位字符作为自动机的弧。为了简化实现，我们预处理表达式以收集它们中使用的可能重叠的范围，并提取一组非重叠范围，我们将其用作构造的自动机的字母表。例如，规则152-156 {1,5}，150-600包含两个重叠范围，152-156和150-600，它们被扩展为三个非重叠范围的字母表：150-151,152-156，和157-600。随后，扩展该例子中的重复，如图4所示

152-156,150-151

152-156,152-156

152-156,157-600

152-156,152-156,150-151

152-156,152-156,152-156

152-156,152-156,157-600

152-156,152-156,152-156,150-151

152-156,152-156,152-156,152-156

152-156,152-156,152-156,157-600

152-156,152-156,152-156,152-156,150-151

152-156,152-156,152-156,152-156,152-156

152-156,152-156,152-156,152-156,157-600

152-156,152-156,152-156,152-156,152-156,150-151

152-156,152-156,152-156,152-156,152-156,152-156

152-156,152-156,152-156,152-156,152-156,157-600

图2.将规则152-156

{1,5}，150-600完全扩展为一组非重叠范围的简单序列的图示。 使用大小为3的字母表，每个字符对应于范围150-151,152-156或157-600。

4.2 DPI引擎集成

       我们将模式匹配数据结构与我们专有的DPI引擎[7]集成在一起，它使用可扩展的签名语言，通过实现一个新的条件来添加一个新的条件，我们称之为数据包序列。签名语言使用事件 - 条件 - 动作模型。DPI引擎引发了与之相关的各种条件和动作的不同事件。条件和操作作为插件实现，可以自由解释其参数并构造在每个事件上计算的必要状态对象。规则引擎本身作为一个整体处理规则集的逻辑，并针对各个条件查询插件。每个条件插件声明它需要的信息（例如有效负载或流量元组信息），并且规则引擎确保相应的条件仅与提供所需信息的事件结合使用。一个这样的事件是数据包事件，它包含有关数据包有效负载的信息，因此包含我们在扩展中使用的数据包大小。其他事件包括连接，由连接跟踪器引发。可以通过存储在连接状态中的标签跨事件传递信息，由称为标签的动作分配，并通过也称为标签的条件进行检查。这些可以用于将在不同事件上触发的规则链接在一起，例如，规则可以匹配证书中的子字符串以检测应用程序并标记连接，而稍后可以在使用数据包序列的规则中使用标记条件，以避免评估来自无关应用程序的流量。

图3说明了一个规则示例。条件被评估为结合。可以使用多个规则表达析取，或者（如果条件本身支持它，例如我们的），使用参数列表（图4）。扩展API提供了钩子，用于将各个条件参数填充到每个事件一次查询的共享对象中，并将任何匹配规则传回规则引擎。这便于执行同时匹配的条件，例如基于Aho-Corasick或散列表的条件。

facebook_video:

event: packet

conditions:

[if !supportLists]-  [endif]port:443

[if !supportLists]-  [endif]packet_train:’399{1,2}, 51{1,2}, 1000-1260{1,2}, 38’ actions:

...

图3.规则示例。使用的基础数据表示语言是YAML。

4.3绩效评估

我们使用我们专有的DPI引擎[7]在实时交通试验台上实验性地评估了整个系统的性能。我们使用HPE Proliant DL380 Gen9服务器和2.20 GHz的两个Intel R

Xeon R E5-2699 v4 CPU，启用了超线程，为我们提供了88个逻辑内核（lcores），并配置了1 TB的RAM。系统具有4×40 Gbps NIC，每个CPU插槽上有两个。使用内核RPM版本3.10.0-693.11.6.el7.x86 64的CentOS Linux版本7.4.1708。

whatsapp_video:

event: packet

conditions:

[if !supportLists]-  [endif]packet_train:

[if !supportLists]-  [endif]’3{1,3},48-60{1,3}, 3{1,3}, 117’

[if !supportLists]-  [endif]’3{1,3},48-60{1,3}, 3{1,3}, 144’

[if !supportLists]-  [endif]’3{1,3},48-60{1,3}, 3{1,3}, 102’

图4.由分组序列扩展在内部处理的模式分离的规则示例。

DPI引擎配置为使用8个lcores来处理来自四个端口（每个端口两个lcores）的流量。这些核心执行恰好足够的数据包解码，以便在内部将流量负载平衡到配置为执行流量检查的58个核心。这些是运行我们实现的lcores。系统中的其余lcores专用于其他任务，例如日志记录和shell访问。

交通负载由真实的移动用户流量组成，其在52-153 Gbps之间变化，平均为109 Gbps，20-25 Gpps，每秒新连接67-230 K，平均值为161 K / s。在整个实验过程中，我们确认系统不会出现丢包现象。

首先，我们使用mpstat以1分钟的间隔测量交通检查核心的基线CPU利用率。对于当地时间下午1点大约130 Gbps的流量，我们测得CPU利用率为34.2％。在启用我们的DPI引擎扩展并确保为所有数据包调用它之后，我们测量了37.6％，增加了大约10％。我们还使用perf工具仔细研究，以缩小执行我们检查的特定功能，称为扩展数据包列车多重匹配。我们测量它为3％，即使没有任何实际模式加载。这个数字是一个上限。如果自动机仅被馈送仅用于预先筛选的流量的数据包（使用适当的签名），则我们的扩展的性能影响预计会更小。

随后，我们加载了数据包列号签名，增加了每个实验中的签名数量，以衡量签名数量对CPU利用率的影响。我们尝试了1-5,10,15和20个签名。结果在2.7-3％范围内，具有显着差异且没有任何可观察的趋势。这一观察结果表明，大部分成本来自于我们对DPI引擎流水线的扩展，并不依赖于模式的数量，至少可达20种模式。

5数据挖掘的适应性

5.1规则挖掘方法论

为了说明我们的事件签名方法的稳健性以及为许多应用程序 - 事件组合允许快速签名提取，我们自动化了该过程。通过使用频繁模式挖掘（FPM）来检测频繁的数据包序列，然后将这些模式与地面实况事件相关联，从数据包跟踪中提取应用程序事件规则。这种方法避免了对其他研究常用的分组统计测量的依赖[4,24,31]。为了提取规则，对训练数据集采取以下步骤：

[if !supportLists]1.             [endif]预处理：过滤掉所有过程ID不同于正在检查的应用程序的数据包。类似地，如上所述，过滤掉TCP重传。最后，所有本地和远程IP分别被视为单个本地和单个远程IP。

[if !supportLists]2.             [endif]数据包统计：之后，计算所有预处理数据包的绝对频率（源，目的地，有效载荷长度），并将频率大于预定百分位数的数据包元组映射到唯一标识符（以下称为项目）。所有其他数据包元组根据其源和目标进行分组，如前所述，但有效负载长度分为4个大小相等的桶，并类似地映射到标识符。采取该步骤以便限制模式挖掘上的可变有效载荷长度的效果（例如，长聊天消息可以具有比较短的有效载荷长度更大的有效载荷长度）。

[if !supportLists]3.             [endif]跟踪分裂：分组跟踪被分成交换的突发（或序列）（即，具有小于阈值的分组间时间距离的传输，在这种情况下设置为1秒）[4,31]。应当注意，作为所调查的事件类型之一是传出聊天消息，较大的时间阈值可能潜在地导致一个突发中包括多个聊天消息（快速连续发送的聊天消息）。此外，过滤掉了不包含任何被调查事件的突发事件。采取该步骤是为了将流量分成时间相关的序列，而这些序列又将用作频繁模式挖掘算法的输入。

[if !supportLists]4.             [endif]频繁模式挖掘：频繁模式挖掘技术用于识别与潜在噪声中的事件相对应的正确分组模式。本方法利用封闭的顺序模式（即，不严格包括在相同支持的另一模式中的模式）作为潜在的应用事件规则，以避免信息丢失。使用ClaSP算法挖掘模式[18]。

[if !supportLists]5.             [endif]规则生成：最后，通过识别哪些闭合的顺序模式与地面实况事件很好地匹配（即，模式时间戳在地面实况事件时间戳的边缘内）来生成规则。

为了减少可能生成的规则的数量，使用上述匹配模式的超集，并使用F1度量进行评估（即，同等地强调精度和召回）。最后，生成的规则用于检测测试数据集上的应用程序事件。训练数据集由25％的样本组成（与第3.2节中提到的主要实施中用于训练的样本相同）。

应该注意的是，上述挖掘方法产生的规则与主要实现的规则不同，因为它们考虑了分组的方向。通过将带有前一个减号的传出数据包编码为有效负载大小，可以很容易地将其包含在DFA引擎中。

5.2规则挖掘评估

       表5显示了自动FPM方法实现的真实阳性率以及与主要实施结果的差异。可以看出，除了表现不佳的Facebook之外，FPM方法在所有情况下均优于主要实施方案。此外，从表6中可以看出，两种方法在错误发现率度量上的性能是相似的。

       表5.自动FPM方法的TP速率。主要实现的差异在括号内给出。

ApplicationMessagingVoiceVideo

Facebook messenger42% (−41)54%(−42)83% (−13)

Skype100%(+12)96%(−4)100% (+25)

Viber100%(0)96%(+42)100% (+12)

WhatsApp100%(0)100% (+8)100% (+25)

表6.自动FPM方法的错误发现率。“Messaging

FDR”列显示语音或视频样本中错误消息传递报告的百分比。“语音/视频FDR”列分别显示了消息样本中错误的语音/视频报告的百分比。主要实现的差异在括号内给出。

ApplicationMessaging FDRVoice/video FDR

Facebook messenger0%(0)3%(+2)

Skype2%(−3.5)8.4% (+4.2)

Viber3%(+1)2%(0)

WhatsApp2%(−6)3.3% (+2.7)

FPM方法能够实现对所有正在进行的聊天消息的准确检测，其中所有正在调查的应用程序的真正正率和错误发现率（FDR）分别为98.55％和3.54％。图5和图6显示了WhatsApp和Skype消息传递活动中随机选择的数据包捕获。由于空间限制，我们选择不包括剩余应用程序的等效图。垂直线描绘了传出聊天消息的记录时间戳，而Main和FPM点使用两种提议的方法显示检测到的事件。检测到的事件与地面实况时间戳的轻微的时间偏差可以从输出消息不是真正即时的，而是从传输到传递确认的事实来解释。

图5. WhatsApp消息传递活动的数据包捕获。垂直线描绘了实际的传出聊天消息，而Main和FPM点显示了检测到的事件 图6. Skype消息传递活动的数据包捕获。

图5示出了我们的规则生成方法能够完美地检测实际事件的情况，与图6中所示的情况相反，其中存在误报和假阴性。可以推导出一个有趣的观察结果是在时间窗口10：39：06-10：39：15期间增加的Skype流量。在此期间，用户尝试选择未预加载的表情符号。

6 相关工作

       Tra ffi c分析。我们的工作属于交叉分析的广泛主题。我们首先简要地确定一些相关的一般工作，然后扩展最相关的领域。

Traffi c分析已被用于识别通过隐私增强技术（如OpenSSL，OpenVPN或TOR）建立的加密隧道传输的网页。例如，Herrmann等人。 [19]提出了一个clas-sifier，可以正确识别来自数据包跟踪的高达97％的Web请求。

其他人使用traffi c分析从加密的VoIP会话中提取语音信息。例如，Wright等人。 [39]表明，当使用可变比特率编解码器对音频进行编码时，加密的VoIP分组的长度可用于以高精度识别呼叫中所说出的短语。

       类似地，可以通过监视提供基于位置的服务的某些应用程序的流量来定位手机的位置，即使在加密的网络流量上也是如此。例如，Ateniese等。 [8]表明，对手只能通过分析在该用户和基于位置的服务提供商之间交换的加密流量的大小和时间来推断目标用户的位置。

       加密Traf中的应用程序事件识别。与我们的工作最相关的是关于加密交通的细粒度应用事件识别的文献，本节调查了这些文献。这些部分的工作清楚地激发了交通分析的可行性，通常使用机器学习技术。我们的工作建立在这些可行性结果的基础上，但侧重于可扩展的实施和高效的执行

Coull等。 [14]提出了一种加密消息服务的流量分析方法。具体来说，它们表明窃听者可以了解有关应用程序内部用户操作的信息，交换的消息的语言和大小。他们的结果证明了通过观察数据包长度来获取应用程序使用信息的可行性，但他们的分析主要集中在Apple的iMessage应用程序上，并且是一项非常有用的研究。 NetScope [29]是一项基于检查IP头，对Android和iOS设备执行用户活动的强大推理的工作。其主要目的是证明被动窃听者能够识别由应用程序生成的无线网络流量（甚至是加密）内的细粒度用户活动。 NetScope基于这样一种直觉：每个应用程序的高度特定实现通过学习活动之间微妙的交互行为差异，为其传输行为（例如传输速率和数据包交换）留下指纹。刘等人。 [24]开发了一个迭代分析器，用于将加密的移动流量分类为应用内活动。他们通过新颖的最大化内部活动相似性和最小化不同活动相似性（MIMD）测量，从从交换数据包序列中提取的原始特征中选择了一组最具辨别力的特征。为了开发在线分析器，它们代表具有一系列时间窗口的流量窗口，这些时间窗口由最佳特征向量描述并在分组级别迭代地更新。对于他们的实验，他们分析了从微信，WhatsApp和Facebook提取的数据。 Conti等。 [11,12]提出了一个分析加密网络流量的系统，以识别Android设备上的用户操作，例如电子邮件交换，社交网络上的交互等。他们的框架利用TCP / IP数据包中可用的信息，如IP地址和端口，以及其他功能，如数据包大小，方向和时间。他们分析各种Android应用程序，如Gmail，Facebook，Twitter，Tumblr和Dropbox。使用机器学习技术，他们进行的实验表明，对于许多用户操作，系统可以实现高于95％的准确度和精度。虽然我们的工作基于相同的理由（即基于数据包序列的加密网络流量的用户活动识别的可行性），但我们通过（i）提出一种新颖的表达模式语言规范来推进最新技术，（ii）构建可扩展和优化的实现，该实现已集成到我们的专有DPI引擎，并在实际交通量上进行测试和评估，（iii）表明规则提取适用于数据挖掘技术。

应用识别和分类。在这项工作中，我们专注于应用程序流程中的细粒度事件识别，因此依赖于应用程序识别，例如通过服务器IP地址范围或可用作明文的元数据，例如服务器名称识别 TLS传输中的（SNI）标头，或交换的证书中的明文信息。尽管如此，在自动化应用程序识别或交换性质分类（例如视频流）方面仍有大量工作，主要依赖于机器学习方法，并且通常适用于加密流量[4,6,9,17] ，20,23,27,30,31,36,40,41]。

端点设备工具。我们使用在端点设备上运行的工具来收集地面实况样本。在这里，我们调查了一些相关工具。 Haystack [28]是一个通过流行的应用程序商店分发的移动应用程序，可以将应用程序标识符和无线电状态等上下文信息与发往远程服务的特定流量流（加密或未加密）相关联，从而阐明移动应用程序的性能，隐私和安全性。 ProfileDroid [37]是另一个监控和分析系统，可以表征Android应用程序在静态，用户，操作系统和网络层的行为。最后，TaintDroid [16]执行动态信息流跟踪，以识别隐私泄漏。

Tra ffi c分析阻力。有创建协议，网络和应用程序的各种方法，可以在交流分析时提供匿名和隐私保证。异议[38]和Riposte [13]是通过使用消息广播提供强有力保证的系统。它们保护数据包元数据，但由于可伸缩性问题，可能没有吸引力。 Herd [22]是另一个解决VoIP呼叫匿名问题的系统，它通过像以前的提议一样解决更通用的Tor匿名网络[15]的一些局限性。 Vuvuzela [32]和Atom [21]是更具可扩展性的系统（数百万用户的数千条消息），它们利用不同的隐私将噪声注入可观察的元数据中。 AnonRep [43]建立在信誉/投票系统的保证之上，TARN [42]随机化IP地址，而TARANET [10]采用分组混合和分裂来实现恒定速率传输。

7 道德考虑

       由于我们研究的性质可能会引起一些伦理方面的考虑，我们将专门讨论如何避免滥用“人类主体”的个人和私人信息[26]。在对我们的方法进行测试的过程中，我们处理了使用非个人移动设备和非私人帐户为每个应用程序收集的样本，明确用于本实验。因此，对于在此阶段处理的数据，不应存在隐私问题

在线测试期间，我们将系统收集的信息最小化，仅包括每条规则的匹配数，而不包含任何类型的个人身份信息。除了性能测量之外，还没有从系统中检索到这个以及其他信息。所有故障排除都是基于我们自己收集的跟踪信息进行的。

这项研究的动机是良好的用途，如客户体验/ QoS评估，数据泄漏检测和政策执行（例如对语音的禁运），但可能会被滥用，正如文献中广泛讨论的那样。因此，我们强烈建议隐私敏感应用程序采取预防措施。我们有意将这项工作的范围限制在单一的通信方式 - 仅发送消息 - 以避免同时关联发送和接收消息的用户对的可能性，从而恢复通信图

8 结论

在这项工作中，我们讨论了通过加密网络流量的应用程序事件的细粒度识别，重点是可伸缩性和可维护性。我们证明了（i）一个简单的正则表达式启发语言足以表达最低命中率84％，（ii）我们的DPI引擎可以扩展到每个节点130 Gbps，不超过额外CPU利用率的10％，（iii）规则提取适用于数据挖掘技术。先前的工作证明了这种技术的可行性。我们的工作重点是实际实现，因为我们认为，就像子串模式匹配是最先进的网络监控系统中的要求一样，即使加密和传输分析阻力等技术，数据包列匹配也是如此。（第6节）存在以逃避它们。