Android 設(shè)備中基于流量特征的隱私泄露評(píng)估方案

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

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

1 引言

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

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

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

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

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

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

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

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

2 相關(guān)工作

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

2.1 第三方庫(kù)檢測(cè)

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

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

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

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

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

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

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

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

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

3 預(yù)備知識(shí)

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

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

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

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

3.2 TF-IDF 模型

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

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

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

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

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

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

4 基于流量特征的隱私泄露評(píng)估方案

本節(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)計(jì)流量特征，并發(fā)往HostRisk 服務(wù)器。圖1 中，①代表App 數(shù)據(jù)分組首先發(fā)往HostRisk 客戶端中的虛擬網(wǎng)卡；② 代表HostRisk 客戶端通過(guò)讀取虛擬網(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)計(jì)App 數(shù)據(jù)分組的特征數(shù)據(jù)并匯總發(fā)送至HostRisk 服務(wù)器。HostRisk 服務(wù)器收集特征數(shù)據(jù)，首先對(duì)數(shù)據(jù)進(jìn)行分類和統(tǒng)計(jì)，進(jìn)而使用TF-IDF模型和層次聚類方法計(jì)算App 隱私泄露風(fēng)險(xiǎn)。

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

4.2 HostRisk 客戶端

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

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

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

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

4.3 HostRisk 服務(wù)器端

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

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

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

圖3 某新聞?lì)怉pp 與各域名交互數(shù)據(jù)分組個(gè)數(shù)統(tǒng)計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 實(shí)驗(yàn)及分析

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

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

實(shí)驗(yàn)征集了25 名志愿者，進(jìn)行了14 天的數(shù)據(jù)收集，收集了1 082 060 條數(shù)據(jù)，共涉及112 款A(yù)pp，收集到4 056 個(gè)域名。其中，有349 755 個(gè)HTTP 數(shù)據(jù)分組和732 305 個(gè)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ù)屬性計(jì)算方法評(píng)估

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

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

實(shí)驗(yàn)選取了某公司旗下著名的新聞?lì)怉pp，該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 效果最佳。通過(guò)多次實(shí)驗(yàn)觀察，發(fā)現(xiàn)域名地址對(duì)于實(shí)際聚類的影響大，因此將距離計(jì)算中的權(quán)重按表2 進(jìn)行分配，其中w1表示域名地址之間的距離，是衡量2 個(gè)域名TCP 通道之間相似性的重要指標(biāo)；w2表示域名IP 之間的距離；w3表示域名TCP 通道的行為特征距離。

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

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

表3 某新聞?lì)怉pp 域名相關(guān)性計(jì)算排名結(jié)果

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

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

5.2.2 算法性能評(píng)估

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

表5 算法性能評(píng)估

6 結(jié)束語(yǔ)

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