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

（1.中國科學(xué)院信息工程研究所，北京 100093；2.中國科學(xué)院大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，北京 100049）

1 引言

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

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

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

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

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

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

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

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

2 相關(guān)工作

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

2.1 第三方庫檢測

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

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

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

2.2 惡意應(yīng)用程序檢測

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

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

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

2.3 相關(guān)工作總結(jié)和對比

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

3 預(yù)備知識

3.1 免費App 服務(wù)提供商盈利模式

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

表1 現(xiàn)有相關(guān)工作對比

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

3.2 TF-IDF 模型

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

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

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

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

3.3 App 內(nèi)主業(yè)務(wù)域名

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

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

本節(jié)介紹所提出的HostRisk 系統(tǒng)架構(gòu)，以及相應(yīng)的客戶端和服務(wù)器。

4.1 HostRisk 系統(tǒng)架構(gòu)

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

圖1 HostRisk 系統(tǒng)架構(gòu)

4.2 HostRisk 客戶端

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

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

圖2 HostRisk 客戶端修改數(shù)據(jù)IP 分組頭過程

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

4.3 HostRisk 服務(wù)器端

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

4.3.1 基于TF-IDF 的域名業(yè)務(wù)相關(guān)性計算

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

圖3 某新聞類App 與各域名交互數(shù)據(jù)分組個數(shù)統(tǒng)計

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

基于TF-IDF 模型計算App 內(nèi)所有域名的業(yè)務(wù)相關(guān)性分值，通過該值將App 內(nèi)的域名進行排序，排序結(jié)果中域名的分布如圖4 所示。App 內(nèi)承擔主要業(yè)務(wù)的域名幾乎分布在App 主業(yè)務(wù)域名區(qū)中，非主業(yè)務(wù)的第三方域名如廣告商、推送商等分布在第三方域名區(qū)中，混雜區(qū)中混合著上述2 種域名?；赥F-IDF 模型的排序結(jié)果精度隨著混雜區(qū)的增大而降低，進而本文通過平均連接的凝聚型層次聚類方法進行優(yōu)化調(diào)整。

圖4 基于TF-IDF 計算后的排名結(jié)果

4.3.2 基于層次聚類的優(yōu)化算法

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

TCP 通道是App 與域名服務(wù)器傳輸數(shù)據(jù)的載體，TCP 通道中數(shù)據(jù)傳輸?shù)牧髁刻卣鞣从吵鲇蛎杉瘮?shù)據(jù)的流量特征，TCP 通道中傳輸?shù)臄?shù)據(jù)分組頭部會記錄域名服務(wù)器的IP 地址端口等信息，數(shù)據(jù)分組的分組體中會記錄域名服務(wù)器的域名地址，域名服務(wù)器與TCP 通道呈現(xiàn)一對多的關(guān)系。

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

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

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

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

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

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

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

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

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

其中，Count()函數(shù)用于統(tǒng)計App 內(nèi)域名的總數(shù)。

5 實驗及分析

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

5.1 數(shù)據(jù)集

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

5.2 業(yè)務(wù)屬性計算方法評估

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

5.2.1 域名相關(guān)性計算排序表分析

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

表2 相似距離權(quán)重分配

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

表3 某新聞類App 域名相關(guān)性計算排名結(jié)果

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

表4 某新聞類App 中倒數(shù)5 個業(yè)務(wù)不相關(guān)域名通信數(shù)據(jù)特征

5.2.2 算法性能評估

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

表5 算法性能評估

6 結(jié)束語

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