基于联邦学习的第三方库流量识别

崔华俊 , 孟国柱 , 李玥琦 , 张 棪 , 代玥玥, 杨慧然 ,朱大立 , 王伟平

1中国科学院信息工程研究所, 北京 中国 100093

2中国科学院大学网络空间安全学院, 北京 中国 100049

3华中科技大学网络空间安全学院, 湖北 中国 430074

1 引言

在移动应用开发中, 第三方库(Third-party Library, TPL)已经成为重要组成部分。安卓应用TPL通常以“.jar”文件或“.aar”文件的形式呈现, 开发者通过集成TPL来完成某些特定功能, 从而提高研发效率, 降低研发成本。例如, 谷歌AdMob可以实现app内广告的呈现, 蚂蚁金服AliPay可以实现app内支付宝付款功能。已有工作表明, app中超过60%的代码属于TPL[1], 且平均每个app集成6-9个TPL[2]。由此可见, TPL已成为移动应用中的重要基础组件。

然而, TPL的广泛使用也带来了许多网络安全隐患。第一, TPL可能会引起隐私泄露问题。由于TPL与其所处app(宿主app)共享进程环境和系统权限,用户无法区分app申请的权限是用于自身业务还是由TPL使用于其它业务(例如用户信息采集), 因此很难在app申请权限时做出正确的判断。目前已有许多TPL隐私泄露问题方面的研究[3-5], 如Feal[6]等人讨论了针对不同类别TPL的权限搭载(privilege piggybacking)和隐私数据监管问题。Wang[7]等人指出了一种新型的隐私窃取攻击方法——跨库数据采集(cross library data harvest, XLDH)。该文发现一些恶意TPL会主动检测宿主app中是否有特定的目标TPL, 并利用Java反射机制从目标TPL中获取用户隐私数据。Recon[8]利用机器学习算法结合用户人工标注的方式,提出了可检测app隐私泄露问题的模型。第二, TPL对其他研究领域也会造成影响。以app流量识别为例,该类研究的目标是判断网络中的流量来自于哪个app, 从而为网络运营商的网络结构优化和服务质量(Quality of Service, QoS)监测提供分析依据。虽然已有大量工作对app流量识别技术开展了研究[9-11], 但Taylor[12-13]等人指出TPL流量会对app流量识别的模型性能产生负面影响。因为不同的app中可能会出现相同的TPL流量(如广告库流量), 这些TPL流量会让模型误认为它们同时属于多个分类, 从而导致分类器模型性能下降。除了隐私泄露和app流量识别问题,TPL流量也会对恶意app检测、app重打包检测等产生影响[14]。由上述分析可知, 识别TPL流量对于流量管理、恶意TPL识别、隐私泄露问题检测等研究具有重要意义。

图1展示了两个真实app的网络访问行为, 可以看出, 集成相同TPL的app均会访问该TPL服务端域名, 集成不同TPL的app会访问不同TPL服务端域名, 此外, 在访问TPL域名的同时, app还会访问自身服务端(app服务端)的域名。基于以上分析, 从流量产生者的角度来看, 可将移动流量分为两部分:宿主app流量与TPL流量。宿主app流量即由app为实现自身业务功能所产生的流量, 该类流量通常存在于app与其服务端(app服务端)之间; TPL流量即由app内集成的TPL产生的流量, 该类流量通常存在于TPL与其服务端(TPL服务端)之间。然而, 由于越来越多流量基于加密协议传输, 导致研究人员难以从混合的流量中区分出宿主app流量和TPL流量。这种流量混合的情况对安全责任的界定以及其他安全研究产生了不利影响。

图1 移动应用网络访问行为示意图Figure 1 Visiting graph of mobile apps

图2 流量采集模块示意图Figure 2 Traffic capturing module

关于TPL的已有研究工作主要集中于TPL检测(2.1节)以及TPL安全或者隐私问题分析(2.3节)。然而, 关于TPL流量识别的研究工作十分少见。其原因有两点: 第一, 公开数据集缺失。TPL流量与宿主app流量混合在一起, 且大多数是HTTPS加密流量,缺乏区分TPL流量的方法, 导致目前暂未出现具有标签信息的TPL流量公开数据集; 第二, 隐私保护与数据共享。移动设备以及app包含大量用户隐私信息, 采集app流量数据涉及数据安全与隐私相关法律法规, 导致科研工作者或技术研发公司在从事这方面研究工作时, 难以共享来自于不同用户的app流量数据来共同推进研究。

为解决TPL流量识别的问题, 本文提出了一个TPL流量识别的框架——LibCapture。针对目前TPL流量识别问题存在的数据集缺失以及隐私保护与数据共享问题, 所提LibCapture可解决以下两方面难点: 1)LibCapture可基于动态插桩技术与TPL识别方法, 在加密流量中准确标记出TPL流量, 并自动生成TPL数据集; 2)LibCapture可构建基于卷积神经网络的联邦学习模型(联邦CNN模型), 用于识别TPL流量。联邦CNN模型可实现在不共享参与方本地数据的情况下, 利用所有参与方本地数据共同训练全局模型, 从而获得比非联邦模型更多的数据量, 并取得更好的模型性能。此外, 其在用户数据隐私保护与可扩展性方面具有天然优势, 十分适合移动应用流量分析场景。总体而言, 本文提出的LibCapture可在app运行时同时采集app发出的加密流量及该流量被加密之前对应的明文流量, 并识别app中集成的TPL, 关联TPL的明文流量与加密流量, 从而生成TPL流量数据集。基于TPL数据集, 结合联邦学习和卷积神经网络(Convolutional Neural Network,CNN), 本文提出了TPL加密流量识别方法, 并基于超过2000个真实app的流量验证了LibCapture的有效性。

本文的贡献总结如下:

1) 设计并实现了一个TPL流量识别框架——LibCapture。该框架可自动爬取app、运行app、采集流量并自动生成TPL流量数据集。此外, 提出了基于联邦学习的TPL流量识别模型, 实现了隐私保护下的多数据源联合训练, 为LibCapture提供了良好的可扩展性。本着“开源科研”的思想理念, 我们在Github公开了本文的核心代码, 仓库地址为:https://github.com/BlcDing/LibCapture。

2) 提出了一种基于动态插桩技术的TPL加密流量数据集生成方法。LibCapture采用动态插桩技术捕获app流量在加密之前的明文流量, 同时利用tcpdump捕获app发出的加密流量, 并结合TPL信息与明-密文流量对应信息将明文流量关联至加密流量,从而自动生成TPL加密流量数据集。

3) 提出了一种基于联邦学习的TPL加密流量识别模型。结合联邦学习理念与CNN卷积神经网络,LibCapture实现了在本地原始数据不共享的前提下,分布式训练与更新TPL流量识别模型, 并分析了联邦学习不同参与方本地数据集差异性对模型的影响,指出了对应的解决方法与未来的研究方向。我们将LibCapture应用于2327个app, 采集app流量并生成TPL数据集。实验结果证明LibCapture可取得92.34%的分类准确率。

本文剩余部分的组织结构如下: 第2章介绍了与本文相关的研究工作, 包括TPL检测、联邦学习以及加密移动流量分析的现状; 第3章详细介绍了LibCapture的系统设计与实现原理, 包括网络流量采集模块、数据集生成模块和基于联邦学习的TPL流量识别模块; 第4章介绍了实验结果与分析, 包括LibCapture的实现、数据集、TPL识别模型的效果验证与分析及与已有工作的对比; 第5章对本文的不足之处以及方法特点进行讨论; 第6章对本文工作进行了总结, 并指出了下一步的研究计划和未来的研究方向。

2 相关工作

2.1 TPL检测

TPL检测是指识别一个app中集成了哪些TPL,这是一类基础性质的研究工作, 因为研究人员可基于TPL检测的结果进行更深层次的分析, 常见的应用场景有TPL与宿主app代码分离、TPL代码缺陷检测等。目前TPL检测的研究方法主要可以分为三类: 第一类是基于白名单的检测, 其基本思想是根据TPL包名[7]或其所访问域名[15]的白名单列表进行匹配。该类方法的优势在于简单快速, 缺点是需要维护并更新白名单列表, 且该类方法在面临代码混淆或者流量加密等技术时将会失效; 第二类是基于机器学习的特征匹配方法, 该类方法通过提取TPL的源代码特征形成TPL特征库, 从而训练TPL检测模型, 特征可以包括代码控制流信息(control flow graph)、系统API调用信息等[14]。该类方法的优点在于通过提取源代码级别的抽象特征, 可以应对代码混淆等源码保护手段, 缺点是针对未知TPL缺乏检测能力, 当面对特征库中未出现的TPL时, 检测效率并不理想, 代表性研究工作有LibRadar[16]、LibScout[17-18]、LibD[19]、LibPecker[2]等; 第三类是基于流量聚类的方法, 该类方法的基本思想是集成在不同app中的TPL产生的流量具有相似性, 因此通过采集大量app流量找到不同app产生的相似流量来检测TPL。该类方法的优点在于基于聚类的方法可以检测未知TPL, 缺点是只能检测出具有网络流量行为的TPL, 对于没有网络流量行为的TPL不具备检测能力, 代表性研究工作有LibHunter[20]。

2.2 联邦学习

联邦学习(Federated Learning, FL)的思想由谷歌最早提出, 其本质是一种分布式协作的模型训练方法。FL系统结构由一个服务端与多个参与训练的客户端组成, 各客户端利用自身本地的数据训练本地模型, 并将模型的相关参数传递至服务端, 服务端根据特定算法对来自客户端的参数信息进行融合与更新, 并将新的模型参数下发至客户端, 从而实现多个客户端在不共享本地数据的情况下共同协作训练模型[21], 这样的优势使得联邦学习在隐私保护领域应用十分广泛。谷歌将联邦学习技术应用在其手机键盘(Google keyboard)中, 通过大量用户的手机输入习惯共同训练输入法模型[22], 为用户提供智能的输入推荐与提示。与传统集中式的人工智能模型相比, 联邦学习无需将所有训练数据都上传至云端,只是将模型相关参数进行传递, 既保护了用户的隐私信息, 又能够结合多方的数据优势共同训练高性能模型。

2.3 加密移动流量分析

移动流量分析的研究已有较长的时间, 但是经过我们调研发现, 针对TPL流量识别的研究十分少见。与TPL流量识别关联性最高的是app流量识别,即区分网络流量来自于哪个app。在这方面的代表性工作有AppScanner[12]和NetworkProfiler[23], app流量识别在恶意流量检测、网络资源分配与管理方面具有重要意义。然而, 上述工作均没有解决所谓“背景噪声流量”或“模棱两可流量”的问题——即如何鉴别由app中的TPL所产生的网络流量的问题。

针对隐私信息泄露的流量分析是与本文相关的另一个研究领域, 其主要目标是评估app向远端服务器传输了什么隐私数据。已有的研究工作[8,24-25]通常使用中间人工具(Man-In-The-Middle, MITM)来解密HTTPS流量, 并基于解密后的明文流量进行隐私泄露问题分析, 常见的MITM工具有Fiddler[26]、Meddle[27]等。然而, MITM工具无法区分流量来自于宿主app还是TPL, 因此这类工作在涉及到TPL流量分析时, 通常基于2.1节中提到的白名单列表来进行区分, 显然这种方法无法解决TPL加密流量识别的问题。其他与移动加密流量分析相关的研究还有恶意软件检测[28-29]、广告欺诈检测[30-31]以及位置分析[32]等。

综上所述, 当前对于移动加密流量分析已有的研究工作主要集中于app流量识别, 基于解密后明文流量的隐私泄露风险分析、广告欺诈、位置分析以及恶意软件流量检测等。关于TPL流量识别的研究工作尚未出现, 然而, TPL流量识别却对上述研究领域有着重要的支撑和促进作用。

3 方法

3.1 系统框架

LibCapture由三部分组成, 图3展示了系统各部分之间的关系与总体工作流程, 系统组成说明如下:

图3 LibCapture系统工作流程图Figure 3 System workflow of LibCapture

1) 流量采集模块: 该模块从应用市场自动爬取app, 自动运行app并采集运行过程中产生的流量。针对某一具体TCP流, 流量采集模块基于动态插桩技术能够同时捕获其在加密之前(明文流量)与加密之后的流量(密文流量)。我们将在3.2节中进行详细介绍。

2) 数据集生成模块: 该模块首先检测出流量中存在的TPL, 并根据明文流量自动标记密文流量, 从而生成TPL加密流量数据集。我们将在3.3节中进行详细介绍。

3) 基于联邦学习的TPL流量识别模块: 该模块利用联邦学习技术与CNN卷积神经网络, 对TPL加密流量数据集进行分布式训练与建模, 并识别TPL加密流量。我们将在3.4节中进行详细介绍。

3.2 流量采集模块

进行TPL加密流量识别需要克服的第一个困难就是公开数据集缺失的问题。为了采集TPL的加密流量, 本文设计并实现了一种基于动态插桩(hooking)技术的明文流量与密文流量捕获方法。

图2展示了app发出网络请求过程的流程图, 首先, app会将其要访问的URL作为参数传递给“sendrequest()”方法, 随后调用安卓Framework层的默认系统接口“SSLOutputStream”, 由“SSLOutputStream”调用native层的boringSSL.so对URL进行加密, 并最终经由移动设备网卡将请求发送出去。

也就是说, app发送的网络请求数据在被送入boringSSL.so之前是明文, 由boringSSL.so加密之后变成密文并最终从Android设备网卡发送至服务端;类似的, app接收的请求在进入boringSSL.so之前是密文, 经由boringSSL.so解密之后变成明文进入“SSLInputStream”并最终由app读取数据。因此, 在“SSLOutputStream”和“SSLInputStream”中的数据是未被加密的(明文流量)。在上述过程中, “sendrequest()”方法可由不同的网络库实现[33-36], 其方法名与参数名均可能不同, 但无论具体如何实现, 均会调用安卓Framework层的“SSLOutputStream”和“SSLInputStream”接口。如果能够在此处捕获到该数据, 并且在移动设备网卡处捕获到加密数据(密文流量), 便能够将明文流量与密文流量关联, 从而为数据集生成模块提供标签信息。

基于上述分析, 为了在app运行过程中同时捕获加密流量以及与加密流量对应的明文流量, 我们设计并实现了流量采集模块。具体来说, 流量采集模块由三个服务组成: 调度服务、加密流量采集服务(Encrypted Traffic Capturing, ETC)和明文流量采集服务(Unencrypted Traffic Capturing, UTC)。对每一个测试app, LibCapture首先将该app安装进测试设备, 启动该app并模拟各类用户行为与app进行交互使得app产生网络流量。与此同时, 调度器会同时启动ETC和UTC服务进行流量采集, 测试结束后, 关闭app进程, 并关闭ETC和UTC。我们基于tcpdump实现了ETC服务, 用于捕获从Android设备网卡中发出的加密流量, 基于LibHunter中的动态插桩技术,对安卓Framework层中的“SSLOutputStream”和“SSLInputStream”进行插桩, 从而捕获app运行时产生的明文流量。

通过上述方式, 我们从不同的采集点捕获了来自于该app的两份流量, 一份为从设备网卡上捕获的加密流量, 另一份为基于动态插桩技术捕获的明文流量。

3.3 数据集生成模块

在捕获了app加密流量与明文流量的基础上, 我们需要解决的第二个问题是如何检测流量中包含了哪些TPL并将TPL流量与宿主app流量进行区分,从而生成TPL流量数据集。为此, 我们设计并实现了数据集自动生成模块。如图4所示, 对于检测流量中存在的TPL的问题, 我们基于先前工作LibHunter对采集的明文流量以及函数调用栈进行训练, 得到流量中包含的TPL列表。LibHunter是一种使用无监督的方式进行TPL检测的方法, 其基本思想是集成了相同TPL的app会产生一部分相似流量, 这部分流量很有可能是该TPL产生的, 因此LibHunter提出了基于URL与函数调用栈的双向聚类方法, 对URL与函数调用栈进行聚类, 并基于投票方式将URL与调用栈进行关联, 从而得到了函数调用栈-URL的对应关系, 并进一步从调用栈中提取出TPL的包名。

图4 数据集生成模块示意图Figure 4 Dataset construction

基于LibHunter的分析结果, LibCapture从明文流量函数调用栈中依据TPL包名筛选出所有TPL请求, 筛选的逻辑是如果一条请求所对应的函数调用栈中出现了TPL的包名, 则认为该请求是由TPL发出的, 从而标记该请求是TPL请求, 否则认为是宿主app请求。进一步地, 在标记明文流量请求的基础之上, LibCapture针对每一条请求提取了6元组信息——源地址、源端口、目的地址、目的端口、app包名以及请求时间戳。将6元组相同的明文与密文流量一一对应, 并根据明文流量的TPL标签信息对密文流量进行标记, 从而生成TPL加密流量数据集。

此外, LibCapture使用CICFlowMeter[37]从pcap文件中提取TPL流量特征, 包含数据包长度、TCP标志位等79维特征, 具体特征信息请见我们的Github仓库https://github.com/BlcDing/LibCapture。

3.4 基于联邦CNN的TPL流量识别模型

本节介绍基于联邦学习的TPL流量识别模型。联邦学习中参与方的本地模型采用卷积神经网络(Convolutional Neural Network, CNN)。针对数据集生成模块中所提取的流量特征, 我们设计了一个一维CNN模型, 其包括2个卷积层、2个池化层和1个全连接层, 模型结构如图5所示。

图5 一维CNN模型结构Figure 5 1D-CNN model structure

其中输入数据为79x1的特征矩阵, 一次输入32条样本数据, 卷积层输入通道为1, 输出通道为16,卷积核大小为5×5, 步长为1, 填充为0, 池化层池化核大小为3×3, 步长为3, 填充为0, 使用Tanh和ReLU两种线性激活函数, 全连接层输入尺度为32×7, 输出尺度为128, 使用ReLU激活函数, 在训练过程的前向传播中, 每个神经元以50%的概率处于不激活的状态, 另外使用梯度下降优化算法和交叉熵损失函数, 学习率设置为1e-2。模型详细情况如表1所示。

CNN模型的参数主要包含每一层的权重(weight)和偏置(bias), LibCapture将每个参与方每一层的权重和偏置上传至联邦学习服务端, 服务端使用FedAvg[39]算法进行全局参数更新, 从而产生新的全局参数, 并将新参数下发至客户端。具体流程如图6所示。

图6 联邦学习流程图Figure 6 Workflow of federated learning

图7 实验1混淆矩阵和ROC曲线Figure 7 Confusion matrix & ROC of Experiment 1

图8 实验7混淆矩阵和ROC曲线Figure 8 Confusion matrix & ROC of Experiment 7

图9 实验2混淆矩阵和ROC曲线Figure 9 Confusion matrix & ROC of Experiment 2

图10 实验8混淆矩阵和ROC曲线Figure 10 Confusion matrix & ROC of Experiment 8

图11 实验3混淆矩阵和ROC曲线Figure 11 Confusion matrix & ROC of Experiment 3

图12 实验9混淆矩阵和ROC曲线Figure 12 Confusion matrix & ROC of Experiment 9

图13 实验4混淆矩阵和ROC曲线Figure 13 Confusion matrix & ROC of Experiment 4

图14 实验10混淆矩阵和ROC曲线Figure 14 Confusion matrix & ROC of Experiment 10

图15 实验5混淆矩阵和ROC曲线Figure 15 Confusion matrix & ROC of Experiment 5

4 实验结果与分析

4.1 系统实现与实验设置

4.1.1 系统实现

LibCapture由流量采集、数据集生成以及联邦CNN模型三部分组成。流量采集模块基于Python requests库以及bs4库实现, 动态插桩能力基于Frida实现, 加密流量采集基于tcpdump实现, 采集控制器基于Python实现; 数据集生成模块基于LibHunter二次开发实现; 联邦CNN模型基于Flower和PyTorch实现。

4.1.2 实验环境与设置

本文于2021年12月根据360应用市场下载量排行榜爬取了2327个app。对于每一个app, Lib-Capture将其安装到测试终端, 利用Android Monkey工具模拟用户点击、滑动、输入等事件与app进行交互, 并利用流量采集控制器协调ETC服务和UTC服务同时进行流量捕获。每个app运行10分钟, 测试时间结束后, LibCapture将关闭并卸载app, 同时将采集到的明文流量与密文流量传输至服务端, 进行TPL检测与流量标记, 并供联邦CNN模型训练与识别。实验环境由两台Pixel3手机和两台服务器组成。其中Pixel3手机用于运行、测试app并进行流量采集; 1台服务器用于TPL检测与TPL流量标记, 从而生成TPL流量数据集; 1台服务器用于运行联邦CNN模型服务端。

4.1.3 数据集

LibCapture共捕获962MB明文pcap文件、3.3GB加密pcap文件以及569MB调用栈文件。由于明文pcap文件是基于动态插桩技术采集的流量, 该技术是针对特定app进程的抓包技术, 只会捕获由该进程产生的流量; 而tcpdump是基于网卡的流量采集技术,其会捕获经过设备网卡的所有数据包, 即包含了测试app以及所有系统背景流量的数据。因此, 在我们捕获的流量中加密pcap文件要多于明文pcap文件。我们使用LibHunter来检测明文pcap文件中包含的TPL,发现其中包含38个TPL, TPL概况如表2所示。

表2 TPL概况Table 2 Overview of TPL

我们将第一次收集的数据集记为原始数据集Ⅰ,其中包含38个TPL, 由于数据主要集中于“com.qq.e.comm”、“com.bytedance.sdk”等5类TPL,其余TPL样本量过少, 因此我们针对这5类TPL进行了第二次收集, 记为原始数据集Ⅱ。

根据实验所需, 分别对原始数据集Ⅰ和Ⅱ做以下处理, 形成的数据集细节如表3所示:

表3 数据集说明Table 3 Description of the dataset

1) 将原始数据集Ⅰ记为数据集a, 均分为3份,分别记为a1、a2、a3;

2) 原始数据集Ⅱ中有5类TPL加密流量样本,通过随机抽取使这5类的样本数量不平衡, 记为数据集b, 再将其均分为3份, 分别记为b1、b2、b3;

3) 从原始数据集Ⅱ中随机选取数据, 使每个类别的数量接近1︰1︰1︰1︰1, 形成样本数量平衡的数据集c, 再将其均分为3份, 分别记为c1、c2、c3;

4) 将数据集b按类别分为2份, 分别记为d1、d2, 其中数据集d1包含3个类别, 数据集d2包含2个类别, 将数据集d1、d2的总和记为d;

5) 将数据集c按类别分为2份, 分别记为e1、e2, 其中数据集e1包含3个类别, 数据集e2包含2个类别, 将数据集e1、e2的总和记为e;

6) 将数据集c均分为2份, 分别记为f1、f2, 将数据集f1、f2的总和记为f;

7) 取数据集c中的70%作为训练集, 记为g1,另外30%作为测试集, 记为g2, 将数据集g1、g2的总和记为g。

4.2 分类模型评价指标

本文从四个方面: 准确率(accuracy)、精确率(precision)、召回率(recall)和f1值(f1-score)对提出的模型进行评估。假设某个样本类别为“1”, 我们规定类别“1”的样本为正样本, 其他标签样本为负样本。设TP(True Positive)为将标签为“1”的数据判断为“1”的样本数, TN(True Negative)为将其他标签的数据判断为对应标签的样本数, FP(False Positive)为将其他标签的数据判断为“1”的样本数, FN(False Negative)为将标签为“1”的数据判断为其他标签的样本数。因此四个指标的标准计算公式如下所示:

4.3 对比实验和分析

4.3.1 样本数量不平衡对模型性能的影响

真实世界采集的各类TPL加密流量普遍存在样本数量不平衡的情况, 为了模拟真实世界情况, 本文分别使用数据集a、b、c, 对比了在联邦学习与非联邦学习的情况下, 样本数量不平衡与否对实验的影响。

参与对比的实验为实验1-3和实验7-9, 其中实验1-3基于经典CNN模型, 实验7-9基于联邦CNN模型, 分别使用数据集a、b、c。

实验1和实验7使用了数据集a, 分别训练500轮, 两次实验的结果较差, CNN模型准确率为60.52%, 精确率为3.00%, 召回率只有8.57%, 联邦CNN准确率为62.01%, 精确率为26.00%, 召回率只有20.91%。对应的混淆矩阵和ROC曲线图如图7-8所示。

实验1和实验7使用的数据集a主要集中于“com.qq.e.comm”、“com.bytedance.sdk”等5类TPL,其余TPL样本量过少, 因此我们针对在app中大量集成的5类TPL进行了第二次数据采集, 并在新的数据集上额外进行了实验。

实验2与实验8使用了样本数量不平衡的数据集, 分别训练500轮, 实验3与实验9使用了样本数量平衡的数据集, 分别训练500轮, 对应的混淆矩阵和ROC曲线图如图9-12所示。根据表4的实验结果可以看出, 无论样本数量平衡与否, 联邦CNN的各项评估指标均高于单独CNN模型。当样本数量平衡时, 单独CNN模型的准确率相较于样本数量不平衡的情况提升了大约3%, 联邦CNN的准确率提升了大约10%。因此可以得到, 样本数量是否平衡对于联邦CNN的学习有较大影响, 使用样本数量不平衡的数据集, 会导致训练模型侧重样本数目较多的类别,因此模型在测试数据上的泛化能力就会受到影响。当样本数量平衡时, CNN模型达到了72.73%的准确率, 联邦CNN模型可以达到80.53%的准确率。

表4 实验细节说明Table 4 Description of experimental details

尽管联邦CNN在样本数量平衡的情况下, 预测准确率相较于样本数量不平衡时能够获得更大的提升, 但是在现实环境中, 各类别样本数量不平衡的情况广泛存在。因此在这种情况下, 研究人员应尝试其他方法, 例如更广泛地收集数据或增加特征数量等。

4.3.2 类别数量不平衡对模型性能的影响

在不同应用场景下, 可能存在客户端参与训练的数据集包含不同类别样本的情况, 为了探究类别数量不平衡对模型性能的影响, 我们分别使用数据集d、e, 对比了在联邦学习与非联邦学习的情况下,类别数量不平衡对实验的影响。

参与对比的实验为实验4-5和实验10-11, 其中实验4与实验5基于经典CNN模型, 分别训练500轮, 实验10与实验11基于联邦CNN模型, 分别训练500轮, 两组实验分别使用数据集d、e, 实验细节与实验结果如表4所示。

实验4与实验10使用了样本数量不平衡、类别数量不平衡的数据集, 实验5与实验11使用了样本数量平衡、类别数量不平衡的数据集, 对应的混淆矩阵和ROC曲线图如图13-16所示。根据表4的实验结果可以看出, 经典CNN模型的准确率最高仅为47.65%, 联邦CNN的准确率最高仅为60.01%, 在类别数量不平衡的情况下, 尽管联邦模型的性能明显优于不联邦的模型, 但无论样本数量是否平衡, 两种方法均不能取得较好的预测效果。因此, 类别数量不平衡对于模型的性能影响较大。

我们分析认为, 当数据集样本类别不平衡时,会导致训练模型只能学习到训练集已知的类别, 尽管联邦学习可以通过客户端与服务端之间参数的传递, 学习到其他客户端的参数, 但是由于本文设计的联邦学习模型在服务端使用FedAvg算法更新参数,而FedAvg算法本身并未根据客户端样本类别的差异性对来自不同客户端的参数进行针对性处理, 最终联邦CNN取得的准确率最高仅为60.01%。由实验可见, 针对客户端样本类别不平衡的情况, 联邦学习模型服务端的参数聚合算法需要进行更加有针对性的设计, 从而将客户端数据集的差异性进行合理融合。

4.3.3 样本及类别数量平衡时模型性能评估

由4.3.1节和4.3.2节的实验结果表明, 当样本数量平衡或类别数量平衡时, 能够得到较好的训练效果,因此本文使用数据集f在样本数量及类别数量均平衡时, 对比了联邦CNN模型与经典CNN模型的效果。

参与对比的实验为实验6和实验12, 其中实验6基于CNN模型训练500轮, 实验12基于联邦CNN训练500轮, 分别使用数据集f, 实验细节与实验结果如表4所示。

实验6和实验12对应的混淆矩阵和ROC曲线图如图17-18所示。根据表4的实验结果可以看出,经典CNN模型和联邦CNN都取得了最好的实验效果, 预测准确率分别为83.05%和92.34%。实验6、12与实验3、9的区别在于, 数据集c将数据集分为3份, 而数据集f将数据集分为2份, 因此实验6、12使用的训练集数据量更大, 测试集则包含了所有数据。从实验结果来看, 在样本数量和类别数量均平衡的情况下, 当参与实验的数据量更大的时候, 能够获得更好的效果。

4.3.4 与已有工作对比

AppScanner[12]是app流量识别研究的经典方法,其能够从加密网络流量中对app流量进行自动指纹提取与识别。从本质上来说, AppScanner使用随机森林分类器对流量进行分类, 其使用的随机森林分类器的主要参数设置如表5所示:

表5 随机森林各项参数及数值Table 5 Parameters of Random Forest

为了测试在类别数量不平衡的情况下联邦CNN与AppScanner的效果, 我们分别使用了样本数量平衡但类别数量不平衡的数据集e和样本数量与类别数量均平衡的数据集f。作为对比, 我们按照常见划分训练集和测试集的比例, 即7︰3的划分方式处理数据集g, 从而探索AppScanner的识别效果。

参与对比的实验为实验11-15, 其中实验11-12使用联邦CNN模型训练500轮, 使用数据集e、f进行训练, 实验13-15使用AppScanner模型, 使用数据集e、f、g进行训练, 各项结果取平均值, 实验参数设置与实验结果如表4所示。

实验11与13使用了样本数量平衡、类别数量不平衡的数据集, 实验12、14、15使用了样本数量和类别数量均平衡的数据集, 其中实验11-14使用的数据集均分为2份, 实验15使用的数据集将训练集和测试集按7︰3的比例分为2份。对应的混淆矩阵和ROC曲线图如图16、18-21所示。根据表4的实验结果可以看出, 在类别数量不平衡的情况下, 联邦CNN的预测准确率为60.01%, App-Scanner的预测准确率为57.49%, 均不能取得较好的预测效果; 当样本数量和类别数量均平衡的情况下, 联邦CNN能够取得92.34%的准确率, App-Scanner能够取得95.97%的准确率; 此外, 使用7︰3的比例划分数据集对AppScanner进行测试, 取得的准确率为95.04%。也就是说, 本文提出的基于联邦学习的TPL加密流量识别模型能够获得与AppScanner的预测准确率接近的效果。需要注意的是, AppScanner取得略高于联邦CNN模型的准确率的前提是, 其获取了与联邦CNN模型相同的样本类别。但真实生产环境中, 联邦CNN模型由于其天然的分布式特性, 很容易容纳更多的参与方共同参与训练, 从而超越AppScanner的准确率。此外, 将所有用户数据上传至云端集中训练存在严重的隐私数据保护问题, 联邦CNN模型在用户隐私保护方面的优势远超AppScanner。

图16 实验11混淆矩阵和ROC曲线Figure 16 Confusion matrix & ROC of Experiment 11

图17 实验6混淆矩阵和ROC曲线Figure17 Confusion matrix & ROC of Experiment 6

图18 实验12混淆矩阵和ROC曲线Figure 18 Confusion matrix & ROC of Experiment 12

图19 实验13混淆矩阵和ROC曲线Figure 19 Confusion matrix & ROC of Experiment 13

图20 实验14混淆矩阵和ROC曲线Figure 20 Confusion matrix & ROC of Experiment 14

经过上述分析可见, 在样本类别不平衡时, 联邦CNN模型取得了优于AppScanner的模型准确率。即使当我们假设AppScanner能够获取所有联邦参与方本地的样本类别时, 联邦CNN模型也取得仅比AppScanner低3%左右的识别准确率。但由于联邦CNN模型具有用户隐私保护、分布式训练与更新等优势, 我们认为联邦CNN模型更加适用于移动应用场景下的TPL加密流量识别问题。

值得一提的是, 由于AppScanner使用了随机森林分类器, 而随机森林在分类任务中能够获得较高的准确率, 因此在未来的工作中, 可以探索随机森林或其它机器学习模型结合联邦学习进行TPL加密流量识别的可行性。

综上, 本文提出了一种基于联邦CNN的TPL加密流量识别模型, 实现了TPL流量分类模型的分布式训练与模型更新, 通过大量对比实验证明了本文所提模型对于TPL加密流量能够取得较高的识别率。进一步地, 通过与现有研究工作AppScanner进行对比, 验证了即使在数据集相同的情况下, 联邦CNN仅比不联邦的AppScanner准确率低3%左右,但却在隐私保护与分布式训练方面有明显优势。此外, 本文分析了联邦学习不同参与方本地数据集差异性对全局模型聚合带来的影响, 针对不同场景分别指出了可能的解决方法和未来的研究方向。

5 讨论

5.1 联邦学习的模型选择

随着人工智能技术的迅速发展, 新的人工智能模型不断涌现, 各类模型优化方法也层出不穷。本文选择经典人工智能模型CNN作为联邦学习的客户端模型, 且在未对CNN模型的结构及参数等过多深入调优的情况下, 取得了92.34%的准确率, 证明了联邦学习在TPL加密流量识别领域的有效性。由于联邦学习天然的隐私保护与协同训练能力, 十分适合于移动应用中分布式模型的场景, 我们认为在TPL加密流量识别领域联邦学习是一种合理且可行的技术路线。

另一方面, 虽然本文选择了经典CNN模型作为联邦学习的客户端模型, 但这并不代表其它模型不适用于本场景。由于本文主要探讨联邦学习技术在TPL加密流量识别领域的可行性以及联邦客户端数据分布对模型的影响和启示, 设计新的人工智能模型并不是本文的主要研究目标。我们相信未来会出现其它效果更加理想的人工智能模型, 或者经过更大数据量训练以及调优之后能够取得更好识别效果的人工智能模型。

5.2 联邦学习参与方的选择

在现实生产环境中, 参与联邦学习的各客户端除了本地样本数据可能存在差异外, 在计算存储能力、网络通信能力、电池功耗等方面均存在天然差异。本文研究了客户端本地数据差异性对全局模型的性能影响, 需要注意的是, 客户端中上述其它因素依然会对全局模型聚合产生影响, 因此在基于联邦学习的TPL加密流量识别模型中, 需结合客户端的多种能力因素进行实时客户端选择, 让更适合参与协同训练的客户端上传训练参数至服务端, 让不适合参与训练的客户端接收更新后的全局模型参数,从而全面提升模型性能。

5.3 流量采集方法

本文中流量采集方法基于动态插桩技术实现,其基本思想是对安卓操作系统Framework层中与SSL相关的系统默认API进行插桩, 插入流量捕获代码, 在流量数据被加密之前将数据进行提取和保存,从而实现加密流量的明文采集。该方法可对所有调用了3.2节中提到的API的app进行流量捕获, 但如果app不调用系统默认API而是采用自定义so库来发送和接收HTTPS流量, 则本文所提方法将会失效。考虑到自定义so库的必要性及研发成本, 我们认为大多数app均会采用操作系统默认API来收发HTTPS流量。在实验过程中, 我们尚未发现采用自定义so库绕过本文所提流量采集方法的app, 但并不排除有少量app会出于高安全性、高性能等方面因素的考虑, 会实现自定义so库来替代安卓系统默认API。针对自定义so库的app流量采集, 需要进行针对性分析, 确定正确的插桩点来进行流量捕获。

6 总结与展望

本文指出了移动应用流量分析研究领域中一个被长期忽视的问题——第三方库(Third-party Library,TPL)流量识别。TPL由于其广泛的被集成性, 一旦出现安全问题将直接影响所有集成该TPL的应用, 涉及面广且影响面大。本文首先分析了该项研究的意义与重要性, 并分析了目前该方面研究极少的原因与难点, 即缺乏公开数据集与数据共享困难。基于此,本文提出了一个新的框架解决上述难点并识别TPL加密流量。首先基于动态插桩技术与TPL检测技术提出了TPL流量自动标注的方法, 从而生成TPL加密流量数据集。此外, 利用联邦学习技术结合CNN卷积神经网络模型实现了在保护用户隐私的前提下的联邦CNN模型来识别TPL流量。我们对2000多个真实移动应用进行实验, 研究了联邦CNN参与方本地数据差异性对全局模型聚合带来的具体影响,针对不同场景分别分析造成影响的原因并指出了可能的解决方法。此外, 我们将本文所提框架与已有app流量识别经典研究工作AppScanner进行实验对比, 验证了即使在掌握相同数据集的情况下, 联邦CNN仅比AppScanner的准确率低3%左右, 但却具有隐私保护与分布式训练等优势, 更加适合移动应用流量分析问题, 进一步证实了所提框架的有效性。

最后, 我们提出了一些该领域值得进一步挖掘的研究点:

1) 新的联邦学习模型。由本文实验可知, 在获知与联邦CNN模型相同的样本类别的前提下, 以AppScanner为代表的经典机器学习方法随机森林取得了准确率优于联邦CNN约3%的效果, 但由于联邦学习的多方参与和分布式训练特性, 使得联邦学习的模型容易获取更多样本与更多类别。因此, 本文计划下一步探索联邦随机森林及其他模型在TPL加密流量识别领域的应用方法。

2) 联邦学习模型的客户端选择算法。联邦学习模型的客户端分散于用户终端, 无法确定用户的使用习惯以及会产生何种数据, 也无法预估用户手机的电量、计算能力、存储能力与网络通信能力等。因此在进行联邦模型训练与参数更新时, 联邦服务端需能够智能选择参与训练与上传参数的部分客户端, 避免选择数据质量差、计算性能弱的客户端, 从而获得高效准确的模型效果。

3) 新的TPL流量触发方法。流量分析类研究的基础是采集到更多的真实流量, 目前主流的app流量触发方法是本文采用的Android Monkey事件模拟器。此外, 有部分流量触发方案的研究提高了app流量触发的代码覆盖率, 例如SmartDroid[38]等。但此类工作有两类不足, 一是其以app代码覆盖率更高为触发目标, 会带来触发耗时更长等问题, 而TPL的流量有其特殊性, 以广告库为例, 此类流量倾向于在app启动时以及运行过程中主动出现, 无需深度挖掘代码进行触发; 二是现有的此类研究工作已多年不维护, 难以在现在的app中成功运行。因此, 研究针对TPL流量的新触发方法有一定意义。

致 谢本文得到了国家重点研发计划项目(2019YFB1005205)资助。