Android 設備中基于流量特征的隱私泄露評估方案

王竹，賀坤，王新宇，牛犇，李鳳華

（1.中國科學院信息工程研究所，北京 100093；2.中國科學院大學網絡空間安全學院，北京 100049）

1 引言

過去的15 年內，智能手機的保有量呈現出爆炸式的增長態勢，截至2019 年6 月，Android 以79.90%的市場占有率成為中國移動終端操作系統市場的“領頭羊”。為了滿足用戶的個性化需求，各類App 層出不窮，其中免費App 更是成為熱門需求。Google Play 中提供多達55 類App，內容涵蓋教育、生活、娛樂、健康等諸多方面，已經成為人們生活中不可或缺的一部分。

然而，在滿足用戶日常教育、生活、娛樂等需求的同時，用戶隱私泄露問題日益突出[1]。基于權限管理的Android 操作系統隱私泄露問題逐漸暴露，一些免費App 的開發商更是通過在App 中植入非主業務第三方庫的手段獲取用戶隱私信息從而謀取利潤，從用戶的角度考慮，用隱私信息交換App 服務是不可接受的。近年來，App 盜用隱私信息造成用戶生命財產安全受損的事件屢見不鮮。

已有研究成果表明[2～7]，大量App 在運行時存在第三方域名收集用戶隱私信息的行為。為此，許多研究[7-12]提出了相應的解決方案，解決這類問題的方法基本可以歸納為2 類：1)靜態解析，通過反編譯代碼分析App 結構、權限等特征檢測惡意應用程序或收集用戶隱私信息的第三方庫，基于分組的依賴關系[8]和敏感應用程序接口（API,application program interface）調用統計特征[9]的方法是靜態檢測的流行做法；2)動態解析，通過捕獲App 運行行為特征達到檢測目的，基于第三方域名特征[10]和通信流量特征[11]是動態檢測方案的有效手段。然而，已有的研究方案大都存在以下幾個問題：1)隨著App 的升級更新，新型惡意應用程序和非主業務第三方庫不斷涌現，傳統檢測方案效果和效率逐漸變差；2)App 中的第三方庫檢測和惡意應用程序檢測無法得知用戶的隱私信息發送給哪些第三方；3)App 級別的粗粒度檢測方案不能滿足檢測App 的每個數據分組泄露用戶隱私信息的問題。

為了解決上述問題，本文提出了一種基于詞頻-逆文本頻率（TF-IDF,term frequency-inverse document frequency）模型和層次聚類方法的隱私泄露評估方案HostRisk。該方案通過捕獲用戶移動設備端中App 的網絡流量特征，基于TF-IDF 模型計算App內域名的業務相關性，同時基于平均連接的凝聚型層次聚類方法優化未能表現出主業務相關性行為特征的App 主業務域名的業務相關性得分，并根據App 內的域名業務相關性排名表計算域名的隱私泄露程度，通過加權平均的方式評估App 泄露用戶隱私的風險。基于TF-IDF 模型的業務相關性計算方法會根據域名的行為特征計算域名業務相關性，但存在部分主業務域名未能表現出與其相關的行為特征，例如與App 不頻繁交互的主業務域名，單獨考慮行為特征并不能充分表現其業務相關的屬性，進而使用基于平均連接的凝聚型層次聚類方法進行調整和優化。App 中的域名隱私泄露風險評估是隱私保護的前提，通過評估的結果實現不同程度隱私泄露風險域名的訪問控制，從而達到用戶隱私保護的目的。

本文以Android 平臺為例，實現了基于虛擬專用網絡服務（VPN Service,virtual private network service）框架的App 流量抓取HostRisk 客戶端和后臺服務器，通過實驗驗證了該方法的有效性。本文的主要貢獻如下。

1)提出一種基于TF-IDF 模型和層次聚類方法的隱私泄露評估的方案，通過域名的行為特征等考慮其危害程度。

2)基于Android 4.0 版本及其更高版本提供的VPN Service 框架，實現了用戶移動智能終端App流量特征提取客戶端。

3)HostRisk 方案細粒度地考量App 發送每個數據分組的行為特征，評估信息接收方域名的危害程度。

2 相關工作

移動網絡中的用戶隱私泄露問題隨著移動設備的激增而日益突出，特別是針對Android 操作系統。已有研究[12-14]揭示了基于Android 安全模型開發應用程序的漏洞和威脅，越來越多的學者研究Android 系統及其衍生產品中的用戶隱私信息泄露問題。其中，第三方庫檢測[15-23]和惡意應用程序檢測[24-32]是2 個研究熱點。

2.1 第三方庫檢測

早期的研究熱點主要關注第三方檢測中廣告庫的識別問題。2012 年，Grace 等[6]通過收集已知的廣告庫設置白名單，匹配App 源代碼中的分組名識別廣告庫。白名單的方式在小范圍內簡單有效，但是針對超大規模數據集，工作量大幅增加，并且無法檢測出匿名的廣告庫。2013 年，Book 等[15]分析了114 000 款App 廣告庫的行為特征，揭示了廣告庫大量地并行存在于多個App 中，并進一步統計分析了廣告庫中的API 調用關系、權限申請等行為特征。

近期，學者們使用機器學習、統計模型、特征識別等手段優化第三方庫檢測問題。2014 年，Naraynan 等[16]提出了基于語義分析的機器學習檢測方案，根據分組名的語義及依賴關系使用支持向量機（SVM,support vector machine）線性分類器進行檢測；同年，Sun 等[17]首次提出針對Android 模型的Native 層進行第三方調用的隱私保護方案，通過對Native 層的API 調用管理和權限申請管理避免第三方從Native 層獲取隱私信息。2016 年，Backes等[18]提出了一種可靠的大規模第三方庫檢測方式，將.dex 壓縮文件中Class 分解為hash 樹，樹的葉子節點是一個類的hash 值。在大規模應用的比對中，匹配到相同的hash 值即為同一個服務提供商的軟件開發包（SDK,software development kit）。在此基礎上，根據匹配的相似度進一步分析了同一庫的不同版本更新速度，從而達到第三方庫檢測的目的。Crussel 等[19]和 Wang 等[20]提出 AnDarwin 和WuKong 方案，通過開發庫代碼聚類技術檢測克隆App，這類方法依賴于大量應用程序普遍使用開發庫進行開發的假設，并且開發人員不會修改開發庫，因此這種假設幾乎不成立，因為在App 開發期間刪除不必要的代碼必然會修改開發庫。Li 等[8]和Ma 等[9]基于WuKong 的聚類方法提出LibD 和LibRadar 的方案，該類方案將混淆的分組名稱考慮在內，LibRadar 不比較開發庫二進制之間的差異，而是通過特征散列對候選庫進行分類，根據分組的目錄結構識別開發庫。LibRadar 要求構造分組層次結構子樹，而這個假設顯然是不切實際的，因為一個開發庫可以封裝在不同的分組中。王浩宇等[21]提出基于多級聚類的方案，對大量應用代碼分組粒度提取API 特征進行聚類，通過權限申請、API 調用等特征進行機器學習分類，最終識別第三方庫，其準確率達到了84.28%。

第三方庫采集用戶隱私信息是造成隱私泄露的主要原因之一，現有工作幾乎都是圍繞第三方庫的靜態代碼檢測方案，靜態檢測的方案具有準確率高的優點，但針對第三方庫名稱動態變化等場景不具備靈活性而且需要選取穩健性較高的特征信息。

2.2 惡意應用程序檢測

惡意應用程序是用戶在無意識或無法辨別惡意軟件的情況下安裝的，安裝后可能會中斷設備的功能或者在用戶未能察覺的情況下執行惡意代碼。針對惡意應用程序的檢測大體有2 種解決思路：靜態分析和動態檢測。靜態分析是在不運行App 的情況下對App 的代碼特征進行分析和判斷；動態檢測方案通過模擬惡意應用程序運行，捕獲惡意應用程序的行為特征，并對其進行識別和檢測。

靜態分析惡意軟件的方法受到靜態程序分析概念的啟發。許多研究將應用程序反編譯后進行代碼的靜態解析[26-28]。Enck 等[24]提出Kirin 模型，通過分析應用程序申請使用系統權限的情況，研究惡意應用程序的行為特征。Seo 等[25]首先分析了已知惡意軟件的異常行為相關的風險API 和關鍵字，從解壓縮的應用程序文件中提取權限信息，并在應用程序中搜索這些有風險的API 和關鍵字的存在，從而判斷惡意應用程序。

動態監測方案中，Tenenboim-Chekina 等[26]關注了應用自更新過程中訪問惡意域名的問題，他們在特定時間間隔內收集了App 的特征數據并且使用聚合方法進行計算，基本思想就是找到特征之間的關系，分析惡意流量特征與正常流量特征之間的偏差，從而找出惡意流量。Zhou 等[27]提出了一種名為DroidRanger 的動態檢測器，為了檢測已知的惡意軟件，首先進行了基于權限的過濾方法，查找應用程序中的危險權限；針對未知惡意軟件檢測，使用了基于啟發式的過濾方法，查找App 中的可疑行為。李夢玉等[28]利用時間序列的分析方法建立了一種基于URL 的惡意訪問檢測模型，首先以一段時間內用戶訪問某域名的URL 日志為分析單位，衍生出識別惡意訪問的特征，利用時間序列的時域和頻域的處理方法將其訪問日志向量化，最后通過聚類的方法識別惡意URL。李佳等[29]基于原始數據與經驗特征工程相結合的思想提出了一種混合結構深度神經網絡，標注了一套由45 萬余條惡意流量和2 000萬余條非惡意流量組成的數據集，此數據集上的準確率達到了98.1%～99.99%。靜態分析和動態檢測是目前最有效的2 種檢測方案。靜態檢測方案正確率高但是可操作性弱，不能靈活地應對動態場景。動態檢測方案有很高的正確性和可操作性。本文通過App 的網絡流量特征，提出基于TF-IDF 模型和層次聚類方法的動態檢測方案。

2.3 相關工作總結和對比

第三方庫檢測和惡意應用程序檢測是移動端用戶隱私泄露檢測及評估的研究熱點，靜態分析和動態檢測成為了主要的技術手段。表1 對比了有代表性的相關工作，特征統計和關鍵字匹配是最常用的方案，也相對簡單，但是存在覆蓋率低和準確率低的問題。機器學習的興起使問題有了新的解決途徑，聚類是最常見的機器學習方案，Ma 等[9]和Tenenboim-Chekina 等[26]方案的粗粒度聚類造成準確率不高的問題。李夢玉等[28]的神經網絡方案將問題聚焦在URL 日志上，并沒有考慮到更細粒度的流量特征。

3 預備知識

3.1 免費App 服務提供商盈利模式

諸如廣告投放、用戶數據收集等活動的非用戶主動支付而產生的利潤，往往是由App 服務提供商允許廣告商等在其App 客戶端中嵌入第三方庫所產生的。本文將這些嵌入App 客戶端中的第三方庫稱為非主業務的第三方庫（域名），這些非主業務第三方庫將繼承App 客戶端的所有權限，直接在用戶移動智能終端獲取用戶的信息，App 服務提供商通過這種方式間接獲取利潤。

表1 現有相關工作對比

用戶在同意App 相關隱私政策后將App 服務提供商視為可信服務商，App 服務提供商獲取用戶數據后有義務保護用戶的特定數據，不能用以謀取商業利潤。因此更多的App 選擇允許非主業務第三方庫嵌入App 客戶端，進而間接從第三方獲利。市場上大量免費應用依賴此類盈利模型謀取利潤，因此“免費”的App 實際上并不“免費”。用戶在使用App 時并不能及時檢測出個人信息是否被采集，更無法得知個人信息的去向。利用用戶的隱私信息換取App 的服務對用戶而言往往不能接受。

3.2 TF-IDF 模型

TF-IDF 是一種統計方法，廣泛應用在信息檢索、自然語言處理等領域中，是關鍵字抽取、自動標簽生成等問題的常用解決方案。該方法用以評估一個字詞對于一個文件集或語料庫中一份文件的重要程度。字詞的重要性與它在文件中出現的次數成正比，但同時與它在語料庫中的逆向文檔頻率成反比，該模型主要包含2 個因素，具體介紹如下。

1)詞W在文檔D中的詞頻（TF,term frequency），表示詞W在文檔D中出現次數Count(W,D)和文檔D中總詞數Size(D)的比值，即

2)詞W在整個文檔集合中的逆向文檔頻率（IDF,inverse document frequenc），即文檔總數N與詞W所出現文件數Docs(W,D)比值的對數。

TF-IDF 模型根據式(1)的TF 值和式(2)的IDF值為每一個文檔D和由k個關鍵詞W1,…,Wk組成的查詢串q計算一個權值，用于表示查詢串q與文檔d的匹配度。

3.3 App 內主業務域名

一個App 承載了不同的功能和業務，對應不同的域名為這些功能和業務做數據支撐，如某新聞類App，該App 會與多個域名進行數據交互，這些域名包括提供新聞內容的服務器、提供位置信息等的工具類服務器、提供廣告的服務器和用于分析用戶數據提升服務質量的服務器。其中提供新聞內容的域名服務器承擔著該App 的主要業務功能，App 會頻繁大量地與這類域名服務器進行數據交互。而類似廣告域名服務器在App 內不承擔主要的業務功能，且幾乎這種非主業務的第三方域名服務器不是注冊在該App 服務提供商公司旗下的，因此App 與該類域名服務器進行數據交互的頻率低，數據通信量小。

4 基于流量特征的隱私泄露評估方案

本節介紹所提出的HostRisk 系統架構，以及相應的客戶端和服務器。

4.1 HostRisk 系統架構

HostRisk 系統架構如圖1 所示，其中用戶在其智能終端安裝HostRisk 客戶端及TCP 代理，基于VPN Service 框架的HostRisk 客戶端用于整合所有App 流量以及修改數據分組的IP 分組頭，TCP 代理用于轉發所有的數據分組以及統計流量特征，并發往HostRisk 服務器。圖1 中，①代表App 數據分組首先發往HostRisk 客戶端中的虛擬網卡；② 代表HostRisk 客戶端通過讀取虛擬網卡獲取App 數據分組并在修改IP 分組頭地址后將數據分組發送至TCP 代理的數據轉發模塊，由數據轉發模塊將App的數據分組發送至App 服務器；③代表TCP 代理中的特征收集模塊統計App 數據分組的特征數據并匯總發送至HostRisk 服務器。HostRisk 服務器收集特征數據，首先對數據進行分類和統計，進而使用TF-IDF模型和層次聚類方法計算App 隱私泄露風險。

圖1 HostRisk 系統架構

4.2 HostRisk 客戶端

基于Android 4.0 版本以后提供的VPN Service框架開發的HostRisk 客戶端收集移動設備中App的流量特征。HostRisk 客戶端會創建一個虛擬網絡接口（虛擬網卡），并返回一個文件描述給HostRisk客戶端。通過配置地址和路由規則將宿主設備的所有流量轉發至虛擬網絡接口。HostRisk 客戶端通過讀取文件描述獲取所有App 發送至App 對應遠端服務器的數據分組，修改數據分組頭的IP 地址和端口號（如圖2 中過程①），將目的地址和端口號修改為TCP 代理的地址和端口號，將原始地址修改為遠端服務器地址，并重新計算數據分組校驗和，將數據轉發至TCP 代理，再由TCP 代理將數據分組發送至App 對應的遠端服務器（圖2 不展示TCP代理轉發數據分組的流程）。

App 遠端服務器的回復數據分組首先發送至TCP 代理，TCP 代理將數據分組轉發至對應的App，數據分組首先發送至HostRisk 客戶端創建的虛擬接口中，HostRisk 修改數據分組IP 分組頭（如圖2 中過程②），將源地址和端口號修改為遠端服務器地址和端口號，目的地址修改為宿主設備地址，然后將數據分組轉發至App。App 發送出的數據分組的目的地址為遠端服務器地址，接收到的數據分組的源地址為遠端服務器地址，因此HostRisk 客戶端對App 和遠端服務器不可見。圖2 中A 表示宿主移動設備，B 表示TCP 代理，C 表示App 對應遠端服務器，D 表示目的地址，S 表示源地址。

圖2 HostRisk 客戶端修改數據IP 分組頭過程

HostRisk 客戶端對系統要求的最低版本為Android 4.0，所需申請的權限有 READ_E-XTERNAL_STORAGE、WRITE_EXTERNAL_ST-ORAGE、ACCESS_WIFI_STAGE、INTERNET 等權限，用戶設備的VPN 權限在App 運行時申請。HostRisk 客戶端通過對App 收發數據分組流量的監控，將移動設備App 數據分組特征信息發送至HostRisk 服務器，并依次計算App 隱私泄露風險。

4.3 HostRisk 服務器端

與App（官方渠道下載安裝的非惡意App）進行數據交互的域名不僅是該App 服務提供商旗下承擔主要業務的域名服務器，還存在廣告商域名服務器、第三方數據統計域名服務器和第三方工具類域名服務器等。對于非惡意的App 來說，與之進行數據分組交互個數越多的域名服務器越有可能承擔該App 的主要業務，圖3 是5.2 節所述數據集中某新聞類App 與所有域名服務器收發數據分組個數的柱狀圖，其中pstatp.com、ixigua.com 等均注冊在該App 所屬母公司旗下，該圖中的doubleclick.com、google-statics.com、umeng.com 等是著名的推送以及信息采集、統計的服務商。其中，App 與非主業務第三方域名服務器交互數據分組個數對于主業務域名服務器交互數據分組個數幾乎可以忽略不計。

4.3.1 基于TF-IDF 的域名業務相關性計算

Book 等[15]研究發現廣告商、信息推送商、信息采集商等非主業務第三方域名廣泛地存在于多個App 之間，且通信數據量較App 主業務域名服務器的通信數據量小。域名服務器的業務相關性與App 和該域名交互數據分組個數成正比，同時與該域名服務器出現在所有App 中的頻率成反比。本文基于TF-IDF 模型提出了域名與App 業務相關性分值的計算方法，具體如下。

圖3 某新聞類App 與各域名交互數據分組個數統計

其中，HA(h)表示計算域名的業務相關性分值，H是該App 中所有域名的集合，HCount()函數用于統計該App 與域名交互的數據分組個數，App 表示HostRisk 系統收集的所有App 集合，APPs(h)函數用于統計所有包含域名h的App 并返回集合，ACount()用于統計App 集合中App 的個數。

基于TF-IDF 模型計算App 內所有域名的業務相關性分值，通過該值將App 內的域名進行排序，排序結果中域名的分布如圖4 所示。App 內承擔主要業務的域名幾乎分布在App 主業務域名區中，非主業務的第三方域名如廣告商、推送商等分布在第三方域名區中，混雜區中混合著上述2 種域名。基于TF-IDF 模型的排序結果精度隨著混雜區的增大而降低，進而本文通過平均連接的凝聚型層次聚類方法進行優化調整。

圖4 基于TF-IDF 計算后的排名結果

4.3.2 基于層次聚類的優化算法

基于TF-IDF 模型的排序方法能夠大致地將App 內域名按業務相關性進行排名，但存在的問題是混雜區中同時混合著App 內承擔主業務的域名和非主業務的域名。本文使用平均連接的凝聚型層次聚類的優化模型來減小混雜區以提高方案的準確性。凝聚型層次聚類的優點是不需要指定聚類個數，當所有元素聚到同一個類中或者最小相似度達到某一閾值時，聚類結束。

TCP 通道是App 與域名服務器傳輸數據的載體，TCP 通道中數據傳輸的流量特征反映出域名采集數據的流量特征，TCP 通道中傳輸的數據分組頭部會記錄域名服務器的IP 地址端口等信息，數據分組的分組體中會記錄域名服務器的域名地址，域名服務器與TCP 通道呈現一對多的關系。

本節將研究對象轉換到App 與域名所建立的每一個TCP 通道上，在更細粒度維度上研究它們的行為特征。混雜區域中既包括主業務域名又包括非主業務域名，而該區域中未能正確計算的主業務域名與分布在App 主業務域名區中的域名有很高的“相似性”，通過TCP 通道之間的“相似性”將混雜區中的主業務域名篩選出來。TCP 通道之間的“相似性”定義為：1)相似的域名后綴；2)臨近的IP地址；3)相似的采集行為（平均數據分組大小、上傳下載數據比例等）。本文將從這些特征研究2 個域名TCP 通道之間的距離DisT(x,y)。首先根據TCP 通道之間的“相似性”定義如下相似距離。

1)Host Distance。域名地址是衡量2 個域名相似性的重要因素。相同的域名后綴代表域名擁有相同所屬機構，而相似的域名前綴代表域名具有相似業務。本文將域名地址拆分成2-gram 集合JSethost，并計算2 個JSethost的Jaccard 距離，Jaccard 距離[32]用于比較有限樣本集之間的相似性與差異性，具體如下。

其中，A和B代表2 個集合。域名前綴和后綴匹配度越高，其距離越近，計算式定義如式(3)所示，并將其歸一化到[0,1]范圍內，其中min()函數返回2 個數中較小的值。

2)IP Distance。互聯網編號分配機構（IANA,Internet assigned numbers authority）通常根據機構規模等因素分配IP 地址，連續的IP 地址通常屬于同一組織機構，通過最長前綴匹配的規則來衡量IP 地址之間的相似距離。最長前綴匹配算法是獲取2 個IP 地址二進制串最長的相似位數，計算式較簡單，此處將略過計算式。前綴匹配越長的IP距離越近，計算式定義如式(4)所示，并將其歸一化至[0,1]范圍內，其中MaxIpPrexMatch()函數返回前綴匹配的最大長度，IPLength 表示IP 字符串長度。

3)Action Distance。本節將從App 與域名之間TCP 通道中數據分組的平均大小（APS,average packet size）和上傳下載數據比（ROUD,ratio of upload to download）考察TCP 通道的相似性，計算式如式(5)所示，并將該結果歸一化至[0,2]范圍內，其中Abs()函數返回該數值的絕對值，max()函數返回2 個數中較大的數值。

式(3)～式(5)計算出的DisH、DisI和DisA通過加權求和的方法，計算2 個域名對應TCP 通道之間的距離，即

其中，DisT為層次聚類方法所采取的分類準則；wi是加權值，根據實際場景對不同聚類標準的需求，進行權重的個性化分配，系統默認配置為滿足∑wi=1條件下的均分權重，并在進行層次聚類前計算App 中所有TCP 通道之間的相似距離。App與每個域名創建的TCP 通道將會被聚類至一個或多個類別（C）中，根據TF-IDF 模型計算結果的排名值，計算每個類別（C）的業務相關性得分CScore 為

其中，Rank()函數用于計算域名hi在TF-IDF 排名表中的排名結果。App 會與某一域名創建多個TCP通道，通過TCP 通道所在類別業務相關性得分，即式(6)計算結果的平均值，并計算域名的業務相關性得分HScore 為

App 中所有域名的業務相關性得分反映域名在App 內扮演的角色（主業務、廣告商等），App 將隱私信息發送至廣告商等非主業務第三方域名造成隱私泄露，通過式(7)的計算結果，計算App 隱私泄露風險值RiskScore 如下。

其中，Count()函數用于統計App 內域名的總數。

5 實驗及分析

為測試本文提出的隱私泄露評估方案，首先實現了HostRisk 原型系統，包括一個Android 客戶端和一個后臺服務器。Android 客戶端安裝在用戶智能終端，用于收集App 的流量信息，其中每個數據分組收集的信息包括用戶編號、App 名稱、域名地址、IP 地址、端口號、通信協議（HTTP/HTTPS）、數據分組發送時刻、TCP 通道創建時刻、發送方向（上傳或下載）、數據分組大小。服務器負責接收客戶端發來的數據，整合多個用戶多個App 收發數據分組特征數據，發送至HostRisk 后臺服務器計算其隱私泄露威脅程度。

5.1 數據集

實驗征集了25 名志愿者，進行了14 天的數據收集，收集了1 082 060 條數據，共涉及112 款App，收集到4 056 個域名。其中，有349 755 個HTTP 數據分組和732 305 個HTTPS 數據分組，比例為32.32%和67.68%，上傳總量為55 352 806 B，下載總量為2 251 886 263 B，總傳輸量為2 307 239 069 B。

5.2 業務屬性計算方法評估

App 中的所有域名參與計算，通過TF-IDF 模型和層次聚類方法計算所有域名的業務相關性，進而計算App 的隱私泄露威脅值。其中App 主業務域名的相關性分值低（分值越低代表相關性越高），而非主業務的第三方域名相關性分值高，判斷其正確性。

5.2.1 域名相關性計算排序表分析

實驗選取了某公司旗下著名的新聞類App，該App 是一款基于數據挖掘的推薦引擎產品。截至2019 年6 月10 日，“七麥數據網”發布該App 共有10 176 786 466 次下載量，近30 天的日均下載量為6 442 101 次，研究該App 的隱私泄露程度具有一定的代表性。為了使聚類效果最好，聚類數目最佳，將閾值設置為0.8 效果最佳。通過多次實驗觀察，發現域名地址對于實際聚類的影響大，因此將距離計算中的權重按表2 進行分配，其中w1表示域名地址之間的距離，是衡量2 個域名TCP 通道之間相似性的重要指標；w2表示域名IP 之間的距離；w3表示域名TCP 通道的行為特征距離。

表2 相似距離權重分配

表3 為某新聞類App 中所有域名相關性計算的排名和相關性分值結果，其中分值越小則風險越小，分值的取值上限與App 中域名個數成正比。pstatp.com、snssdk.com、bytecdn.cn、byteimg.com均注冊在該新聞類App 所屬母公司旗下，用于提供新聞信息提供、用戶日志記錄、內容緩存等服務；ixigua.com 注冊在隸屬于該母公司旗下的子公司，用于提供該App 中視頻服務等。通過相似性計算后這5 個域名的相似性值位列前五，隱私風險得分分別為1.0、2.0、5.0、4.0、12.0，其代表該App 的主要業務。google-analytics.com、xdrig.com、amap.com、wrating.com、doubleclick.net 是著名的數據統計和第三方工具類域名，根據計算結果排序為該新聞類App 中相關性分值倒數五名的域名，表4 是這些域名的數據特征。xdrig.com 是某數據科技公司旗下著名的數據采集分析平臺；amap.com 是某地圖類科技公司旗下的域名平臺；wrating.com 注冊在某數據有限公司旗下，用于收集分析數據的域名；googleanalytics.com 和doubleclick.net 隸屬于某著名公司旗下，用于收集數據的第三方平臺。按排序從高到低的得分依次為48.92、50.0、56.23、58.0、69.5，相比之下這些域名被視作第三方域名，隱私泄露風險高。

表3 某新聞類App 域名相關性計算排名結果

表4 是某新聞類App 中原始數據中隱私泄露風險較高域名流量的統計數據，這些域名大多是廣告域名或用于統計用戶信息的域名，由統計數據易知該App 與這些域名之間的通信數據分組個數少且通信數據量低，非主業務第三方域名大量使用HTTPS 進行數據通信。除amap.com 外，其他用于收集用戶數據的域名上傳數據量均大于下載數據量，amap.com 屬于第三方工具類域名上傳數據量和下載數據量持平。通過TF-IDF 模型和層次聚類計算后，這5 個非主業務第三方域名排在倒數五名，該App 內域名隱私泄露危害風險根據排序表得出，其中xdrig.com 等域名泄露用戶隱私危害風險大，pstatp.com 等域名泄露用戶隱私危害風險小，反映在表3 中的隱私泄露風險分值計算中，隱私泄露風險高的域名分值低。

表4 某新聞類App 中倒數5 個業務不相關域名通信數據特征

5.2.2 算法性能評估

數據量大小和層次聚類閾值的選取是算法計算時間復雜度的主要影響因素，本節針對數據量的大小和層次聚類的閾值對算法時間復雜度進行性能評估實驗，實驗結果如表5 所示。如5.1 節所述，數據集中進行隨機刪除構造1 萬、10 萬、50 萬和100 萬的不同量級數據集。實驗選取在一臺搭載Windows 7 操作系統、6 GB 內存容量、CPU 主頻為3.5 GHz 的PC 機上進行。由表5 可知，數據量的大小成為影響算法計算時間復雜度的主要因素，由于平均連接的凝聚型層次聚類算法會迭代計算App內所有域名創建TCP 通道之間的相似性距離，并計算多個類之間平均相似聚類最小值，迭代計算最小值的過程消耗大量時間，當數據量多達100 萬時，計算時間在100 s 以內。

表5 算法性能評估

6 結束語

針對Android 平臺上App 內非主業務第三方域名采集用戶隱私信息造成隱私泄露問題，本文提出了一種移動設備中基于流量特征的隱私泄露評估方案。基于TF-IDF 模型和平均連接的凝聚型層次聚類方法計算所有域名與App 的業務相關性得分，相關性得分越低的域名與App 的主業務越相關，而相關性得分越高的域名造成隱私泄露的風險越大，最終通過加權平均的方法計算App 的隱私泄露風險。其中域名的相關性得分可判定域名在App 內扮演的角色（主業務、廣告商等），進而設置隱私保護方案以保證用戶的隱私信息不被泄露，在保證App 服務質量的同時降低用戶隱私信息泄露帶來的威脅。本文實現了隱私泄露評估HostRisk 的客戶端和后臺服務器，并在一組真實的實驗數據上進行了測試，實驗結果進一步說明了該方法的有效性和效率。