安卓應(yīng)用隱私合規(guī)檢測方法研究

王申奧，王亞龍，王乾旭，賀紫怡，李 暉

(西安電子科技大學(xué) 網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710071)

0 引言

近年來，移動應(yīng)用超范圍收集用戶隱私信息，強制索取敏感權(quán)限等現(xiàn)象屢見不鮮。為了保護(hù)用戶的個人隱私信息，監(jiān)管部門要求企業(yè)或組織在隱私政策以簡潔易讀的方式告知用戶他們?nèi)绾问占⒋鎯凸芾碛脩舻膫€人信息。然而，根據(jù)武漢大學(xué)2021 年的相關(guān)調(diào)查[1]顯示，77.8%的用戶在安裝App時“很少或從未”閱讀過隱私協(xié)議，69.69%的用戶會忽略App 隱私協(xié)議的更新提示。盡管一些服務(wù)提供商已經(jīng)提高了其隱私政策的可理解性和可讀性，但這些政策仍然篇幅太長，難以閱讀[2-3]。此外，2021 年國家計算機網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心和中國網(wǎng)絡(luò)空間安全協(xié)會共同發(fā)布的《App 違法違規(guī)收集使用個人信息監(jiān)測分析報告》[4]中也顯示，超范圍收集用戶隱私信息，違反用戶“知情同意”原則的違法違規(guī)應(yīng)用在各主流應(yīng)用市場仍然廣泛存在。

近來，隱私合規(guī)分析的相關(guān)工作在國外頗受關(guān)注，逐漸被應(yīng)用到大規(guī)模網(wǎng)站隱私合規(guī)性分析、移動應(yīng)用隱私泄露檢測等領(lǐng)域。移動應(yīng)用的隱私合規(guī)分析主要包括隱私政策文本分析與程序分析兩個部分。靜態(tài)程序分析執(zhí)行效率高，然而由于缺乏運行時路徑信息，靜態(tài)分析往往會產(chǎn)生一定程度的誤報。動態(tài)污點分析通常是利用插裝和代碼重寫為污點數(shù)據(jù)創(chuàng)建污點標(biāo)記，優(yōu)點是準(zhǔn)確率更高，但插裝和代碼重寫往往帶來更大的性能開銷。隱私合規(guī)研究往往是在程序分析的基礎(chǔ)上結(jié)合隱私政策文本進(jìn)行合規(guī)性檢查。隱私政策文本分析作為國外新興的研究熱點，已經(jīng)陸續(xù)建立起豐富的隱私政策語料庫。然而在中文領(lǐng)域，隱私政策命名實體識別的研究仍然缺乏，中文隱私政策的公開語料庫也仍處于空白。這些問題制約了國內(nèi)隱私政策與程序分析相結(jié)合的自動化合規(guī)檢測技術(shù)的發(fā)展。

為了解決上述問題，本文通過人工注釋構(gòu)建危險權(quán)限術(shù)語詞典，提出利用雙向最大匹配算法實現(xiàn)基于詞典的隱私政策自動標(biāo)注，從而構(gòu)建中文隱私政策權(quán)限詞實體識別語料庫。在此基礎(chǔ)上，本文為隱私政策語料構(gòu)建預(yù)訓(xùn)練字嵌入，通過雙向長短期記憶神經(jīng)-條件隨機場(Bi-directional Long Short-Term Memory -Conditional Random Field，BiLSTM -CRF) 架構(gòu)實現(xiàn)最優(yōu)標(biāo)簽序列預(yù)測，從而完成權(quán)限詞實體識別任務(wù)。在應(yīng)用程序動靜態(tài)混合分析部分，基于Androguard 實現(xiàn)交叉引用并對程序?qū)嶋H調(diào)用的危險權(quán)限進(jìn)行靜態(tài)分析。通過隱私政策聲明權(quán)限集與實際調(diào)用權(quán)限集的一致性分析，實現(xiàn)了對超范圍收集敏感信息行為的檢測。此外，依托 Frida 動態(tài)插樁與Hook 技術(shù)，對敏感應(yīng)用編程接口(Application Programming Interface，API)進(jìn)行重載，記錄函數(shù)調(diào)用堆棧、調(diào)用頻次、關(guān)鍵參數(shù)等行為日志信息，針對同意隱私政策前收集、靜默狀態(tài)下頻繁訪問敏感信息實現(xiàn)運行時狀態(tài)監(jiān)測。

1 相關(guān)工作

自2018 年歐盟出臺《通用數(shù)據(jù)保護(hù)條例》(General Data Protection Regulation，GDPR)以來，國內(nèi)外學(xué)者針對安卓隱私泄露與合規(guī)檢測等問題進(jìn)行了大量研究。關(guān)于安卓隱私合規(guī)檢測的工作最早可以追溯到對隱私泄露的研究，但二者的側(cè)重又有所不同。安卓隱私泄露的相關(guān)研究關(guān)注于數(shù)據(jù)流的動靜態(tài)混合污點分析，目標(biāo)是確定安卓隱私泄露的潛在路徑，而從技術(shù)上講，如果這些數(shù)據(jù)流在隱私政策中被披露，它們就不屬于“泄露”行為。因此，相比單純基于數(shù)據(jù)流的動靜態(tài)污點分析，合規(guī)檢測更關(guān)注于隱私聲明自動化分析與安卓隱私數(shù)據(jù)泄露的交叉領(lǐng)域。目前的相關(guān)工作重點關(guān)注于提取隱私政策中聲明的權(quán)限信息并與實際權(quán)限調(diào)用進(jìn)行一致性分析，下面分類介紹這兩個方面的研究進(jìn)展。

1.1 動靜態(tài)混合污點分析

總體來說，程序分析方法主要包括靜態(tài)分析和動態(tài)分析兩種。其中靜態(tài)分析主要是通過對APK文件進(jìn)行反編譯，分析從源點(Source)到匯點(Sink)的潛在數(shù)據(jù)流路徑，從而檢測隱私泄露的方法。典型的靜態(tài)污點分析工具有FlowDroid[5]和IccTA[6]等。FlowDroid[5]拓展了Soot 框架，提出了按需追蹤的反向別名分析方法，從而支持上下文敏感、流敏感、域敏感、對象敏感，對于直接賦值，函數(shù)調(diào)用和別名傳播三種污點傳播方式都能實現(xiàn)高精度分析。IccTA在FlowDroid 的基礎(chǔ)上為每個組件創(chuàng)建虛函數(shù)，并建立組件間連接，解決了組件間通信導(dǎo)致的隱私泄露問題。但是由于缺乏運行時路徑信息，以上靜態(tài)分析方法都很難正確地對分支語句(判斷和控制)進(jìn)行處理，可能衍生出一些實際場景中根本不可能被執(zhí)行的程序路徑，從而產(chǎn)生一定的誤報。

動態(tài)分析則是通過模擬應(yīng)用的實際運行情況，獲取應(yīng)用運行時的行為數(shù)據(jù)，從而檢測數(shù)據(jù)能否從污染源點傳播到污染匯點。典型的動態(tài)分析方法包括TaintDroid[7]和TaintEraser[8]，它們通常是利用插裝和代碼重寫為污點數(shù)據(jù)創(chuàng)建污點標(biāo)記，根據(jù)指令類型和指令操作數(shù)設(shè)計相應(yīng)的傳播邏輯，在此基礎(chǔ)上進(jìn)行污點標(biāo)記的存儲與追蹤。然而，插裝和代碼重寫往往帶來更大的性能開銷，在純動態(tài)的情況下，原始程序的每條指令通常需要6～8 次額外的污點追蹤指令來傳播污點標(biāo)簽。

目前安卓隱私泄露的最新研究更多地集中在輕量級動靜態(tài)混合分析。混合分析中的靜態(tài)部分旨在預(yù)優(yōu)化追蹤邏輯，縮減追蹤范圍，從而減小動態(tài)分析的性能開銷。FSAFlow[9]通過修改FlowDroid[5]框架實現(xiàn)目標(biāo)路徑與關(guān)鍵分支信息的搜索，選擇違反預(yù)定義的隱私策略的潛在路徑，利用有限狀態(tài)自動機進(jìn)行編碼，將少量狀態(tài)管理代碼插裝到程序相應(yīng)位置，防止運行時信息泄露。

1.2 隱私聲明與權(quán)限調(diào)用一致性分析

相比于動靜態(tài)混合污點分析的隱私泄露研究，隱私聲明與權(quán)限調(diào)用的一致性分析更關(guān)注于隱私聲明的自動化解析，從而為應(yīng)用行為動靜態(tài)隱私泄露分析提供判斷依據(jù)。

早期研究[10-11]大多是利用AndroidManifest.xml 文件或者應(yīng)用描述信息來識別開發(fā)者對于應(yīng)用權(quán)限調(diào)用的相關(guān)聲明，一些經(jīng)典的工作如WHYPER[10]和AutoCog[11]利用自然語言處理技術(shù)從應(yīng)用描述中提取權(quán)限信息并與應(yīng)用實際調(diào)用的權(quán)限進(jìn)行對比，從而識別隱私違規(guī)行為。然而，應(yīng)用描述信息字符有限，不能夠完整地表達(dá)開發(fā)者對于權(quán)限調(diào)用的實際聲明。此外，AndroidManifest.xml 文件中列舉的權(quán)限信息也不能夠直接反映開發(fā)者的權(quán)限聲明和用戶所知情的授權(quán)范圍，因此其研究局限性較強。

最近的一些工作[12-17]更關(guān)注于隱私政策與應(yīng)用程序關(guān)聯(lián)分析的合規(guī)檢測方法。Slavin[12]等人構(gòu)建了最早的隱私聲明與權(quán)限調(diào)用的一致性分析框架，通過對50 個移動應(yīng)用隱私政策的人工注釋構(gòu)建了隱私策略術(shù)語詞典，使用基于描述邏輯的形式化語言構(gòu)建權(quán)限術(shù)語本體，在此基礎(chǔ)上構(gòu)建了隱私策略本體短語與API 方法的映射，從而識別弱違規(guī)和強違規(guī)行為。這項工作的局限性在于沒有區(qū)分弱違規(guī)的程度，用戶隱私的范圍也只限于通過安卓權(quán)限獲取的敏感信息，而忽略了用戶的動態(tài)輸入的隱私信息(如手機號碼、身份證ID 等)。Wang[13]等人隨后在這項工作的基礎(chǔ)上做了改進(jìn)，他們考慮了用戶通過UI 界面輸入的隱私信息，通過構(gòu)建UI 控件樹從控件標(biāo)簽中獲取語義，從而識別應(yīng)用收集的敏感信息類型，完成隱私政策聲明與敏感信息收集行為的一致性檢測。

另外一些工作如Polisis[14]和PolicyLint[15]則是將深度學(xué)習(xí)應(yīng)用到隱私政策的自動化分析任務(wù)中。Polisis[14]通過訓(xùn)練特定于隱私聲明領(lǐng)域的詞嵌入并構(gòu)建CNN 多層次分類模型，以88.4%的準(zhǔn)確率實現(xiàn)了隱私政策的結(jié)構(gòu)化的解析。PolicyLint[15]在這項工作的基礎(chǔ)上考慮數(shù)據(jù)對象和實體的否定，從語義層面對谷歌應(yīng)用市場中11 430 個應(yīng)用程序的隱私聲明中存在的矛盾進(jìn)行分析，實現(xiàn)了否定詞敏感的隱私政策結(jié)構(gòu)化解析。Andow 等人提出的PoliCheck[16]則是在二者的基礎(chǔ)上將隱私政策解析進(jìn)一步細(xì)化，通過區(qū)分敏感信息收集的第一方主體與第三方SDK，對數(shù)據(jù)流路徑末端匯點的目的域名進(jìn)行匹配，實現(xiàn)了實體敏感的隱私合規(guī)檢測。Nguyen[17]等人著重關(guān)注于用戶同意隱私政策前的違規(guī)收集行為，通過與應(yīng)用無UI 交互狀態(tài)下的網(wǎng)絡(luò)流量審計，檢測程序中存在的違規(guī)敏感信息傳輸。

然而，目前隱私政策自動化解析的相關(guān)研究還主要集中在英文領(lǐng)域。隱私政策文本分析作為國外新興的研究熱點，已經(jīng)陸續(xù)建立起豐富的隱私政策語料庫。Usable Privacy Policy 項目提供了十余個常用的英文隱私政策語料庫，如OPP-115 Corpus[18]、APP-350 Corpus[19]、Opt-out Choice[20]等?；谶@些語料數(shù)據(jù)訓(xùn)練的自然語言處理模型能夠從隱私政策中自動提取隱私信息相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。但目前國內(nèi)尚未建立相關(guān)中文隱私政策語料庫，中文隱私政策文本自動分析的相關(guān)研究也比較缺乏。

2 隱私政策自動化解析

為了實現(xiàn)隱私政策與應(yīng)用程序的聯(lián)合分析，需要實現(xiàn)隱私政策的自動化信息抽取，得到其中權(quán)限聲明相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。在隱私政策解析部分，本文將權(quán)限信息的結(jié)構(gòu)化抽取作為命名實體識別任務(wù)，構(gòu)建了中文隱私政策權(quán)限詞實體識別語料庫，并基于BiLSTM-CRF 完成模型訓(xùn)練，方案架構(gòu)如圖1 所示。

圖1 隱私政策自動化解析方案架構(gòu)

2.1 中文隱私政策語料庫構(gòu)建

為了完成隱私政策中危險權(quán)限詞的命名實體識別任務(wù)，需要構(gòu)建人工標(biāo)記的隱私語料數(shù)據(jù)集用于模型訓(xùn)練。因此，在本部分，本文首先獲取隱私政策原始語料數(shù)據(jù)，原始語料的收集主要考慮了以下兩個方面：

(1)樣本量：為了防止數(shù)據(jù)集過小造成的過擬合現(xiàn)象，同時綜合考慮模型的準(zhǔn)確度和人工標(biāo)注的時間成本，最終選定了用于人工標(biāo)記的隱私政策語料93 篇，待拓展隱私政策語料965 篇。

(2)抽樣方法：為了使樣本分布盡可能與所有在架應(yīng)用分布保持一致，本文按照以下兩條規(guī)則進(jìn)行抽樣。一是樣本空間熱門應(yīng)用(high-profile)和冷門應(yīng)用(long-tail)比例適當(dāng)(即樣本要符合在架應(yīng)用下載量的冪律分布規(guī)律)，結(jié)合小米應(yīng)用市場的應(yīng)用下載量，最終選取頭部應(yīng)用231 款，冷門應(yīng)用827款；二是樣本應(yīng)用類型覆蓋范圍盡可能廣泛，最終選取包括金融理財、社交聊天、圖書閱讀等在內(nèi)的14 類常見類型應(yīng)用。

(3)收集方法：應(yīng)用隱私政策的獲取方式有兩種，一是提取應(yīng)用內(nèi)嵌在安裝包內(nèi)的隱私政策，但這種方法需要對應(yīng)用進(jìn)行反編譯，時間成本高昂；二是通過提取開發(fā)者上傳到應(yīng)用市場的隱私政策，通常這些隱私政策存儲在服務(wù)器上，因此可以利用Selenium 自動請求隱私政策鏈接，進(jìn)一步調(diào)用Beautiful Soup 庫進(jìn)行格式化解析，去除多余標(biāo)簽，從而完成隱私政策提取。

在隱私政策的自動化解析中，應(yīng)重點關(guān)注危險權(quán)限詞的實體識別任務(wù)。因此在本小節(jié)，本文以Android 定義的危險權(quán)限組歸納出九類實體類型，如表1 所示。

表1 九類危險權(quán)限術(shù)語詞類型

命名實體識別廣義上屬于序列標(biāo)記任務(wù)的范疇，因此其語料標(biāo)注規(guī)范也遵循序列標(biāo)記的通用規(guī)范，常見的序列標(biāo)注格式有三種：BIO 格式、BMES 格式以及BIOES 格式。三者都是字符粒度級別的標(biāo)注格式，各標(biāo)簽含義如表2 所示。

表2 常用序列標(biāo)注規(guī)范中的標(biāo)簽含義

在此選擇BIOES 格式進(jìn)行標(biāo)注(B 代表實體詞的開始；I 代表實體詞中間位置的字符；O 代表非實體字符；E 表示實體詞的結(jié)束；S 代表單個字符組成的實體)。相比于其他兩種標(biāo)注格式，BIOES 格式提供了更豐富的信息，便于在模型預(yù)測時提取實體。

在中文隱私政策危險權(quán)限詞實體識別任務(wù)中，共安排三位注釋員分別對93 篇隱私政策原始語料進(jìn)行注釋。為了解決人工標(biāo)注文本存在的歧義，評估標(biāo)注序列的共現(xiàn)頻率，結(jié)合注釋規(guī)則確定有效標(biāo)注：當(dāng)兩位注釋員同時為某個詞序列添加標(biāo)記后，才將該注釋作為實體標(biāo)記，引入第三位注釋員進(jìn)行判斷。對93篇隱私政策標(biāo)注并去重后共獲得危險權(quán)限詞注釋964 份，但由于標(biāo)注歧義等情況，最終經(jīng)過注釋規(guī)則與人工審核確定了有效危險權(quán)限詞標(biāo)記677 個。

通過人工標(biāo)注獲取的熟語料注釋準(zhǔn)確性高，不容易出現(xiàn)注釋歧義，但缺點是人工注釋費時費力，由于泛化能力的需求，實際場景中的命名實體識別任務(wù)很難僅靠人工標(biāo)注的語料數(shù)據(jù)進(jìn)行模型訓(xùn)練。解決小樣本命名實體識別語料缺乏的方法之一是通過雙向最大匹配算法(Bidirectional Maximal Matching，BMM)進(jìn)行語料拓展。

雙向最大匹配算法是一種典型的基于詞典的序列標(biāo)注方法，它通過比較正向最大匹配(Forward Maximal Matching，F(xiàn)MM) 和反向最大匹配(Reverse Maximal Matching，RMM)的標(biāo)注結(jié)果得到正確的標(biāo)注序列。

正向匹配算法從文本串起始處正向掃描，取出子串與字典進(jìn)行匹配。后向匹配算法同理，差別在于后向匹配算法從結(jié)尾處對字符進(jìn)行切分匹配。雙向匹配算法正是在二者結(jié)果的基礎(chǔ)上進(jìn)行綜合。如果前向匹配和后向匹配的切分結(jié)果詞數(shù)不同，則返回詞數(shù)較少的；如果詞數(shù)相同且切分結(jié)果相同，則返回任意一個結(jié)果；如果詞數(shù)相同但分詞結(jié)果不同，則返回單字較少的分詞結(jié)果。

本文將人工標(biāo)記的93 篇語料和BMM 拓展的965 篇語料進(jìn)行合并，得到最終的1 058 篇隱私政策語料數(shù)據(jù)，作為隱私政策權(quán)限詞實體識別訓(xùn)練語料。

2.2 隱私政策權(quán)限詞命名實體識別

在該小節(jié)中，本文利用先前獲得的標(biāo)記語料構(gòu)建數(shù)據(jù)集，在此基礎(chǔ)上訓(xùn)練特定于隱私詞領(lǐng)域的雙向長短期記憶神經(jīng)-條件隨機場(Privacy Specific Bi-directional Long Short-Term Memory -Conditional Random Field，PRI-BiLSTM-CRF)模型，從而完成中文隱私政策權(quán)限詞實體識別任務(wù)。

首先，對數(shù)據(jù)集進(jìn)行劃分。按照18:1:1 的比例切分得到訓(xùn)練集、驗證集、測試集。得到訓(xùn)練、驗證、測試集的語句數(shù)量分別為103 553、6 543、6 305，分別加載數(shù)據(jù)集并進(jìn)行預(yù)處理。預(yù)處理過程首先是對數(shù)據(jù)集進(jìn)行分句，之后對標(biāo)注格式進(jìn)行檢查，最后利用word2vec 預(yù)訓(xùn)練100 維字向量特征。為了充分地利用隱私政策中危險權(quán)限詞的長度特性，本文額外構(gòu)建20 維的詞長度特征。根據(jù)語句分詞結(jié)果，將單字成詞的特征標(biāo)記為0，詞首長度特征為1，詞間長度特征為2，詞尾長度特征為3，按照以上規(guī)則為每個字構(gòu)造詞長度id，通過Embedding 層將詞長度id處理為20 維的向量特征，作為字向量特征的補充，提供更豐富的信息。之后將100 位字向量特征與20維詞長度特征拼接，最終得到120 維向量輸入模型，在此基礎(chǔ)上進(jìn)行訓(xùn)練與更新。

接下來對模型架構(gòu)進(jìn)行介紹，該模型由Embedding 層(字向量嵌入層)、BiLSTM 隱藏層、Linear 層(線性層)與CRF 輸出層構(gòu)成。模型結(jié)構(gòu)如圖2 所示。

圖2 PRI-BILSTM-CRF 模型架構(gòu)

在Embedding 層，首先加載預(yù)訓(xùn)練的100 維字向量并將詞長度id 轉(zhuǎn)化為20 維詞長度特征，然后拼接得到120 維向量輸入。BiLSTM 層則是以Embedding 層的120 維向量特征作為輸出，通過前向和后向傳播得到各自的隱狀態(tài)，最后將前向LSTM(128 維)和后向LSTM(128 維)的隱狀態(tài)拼接(256 維)送入Linear 層獲得發(fā)射分?jǐn)?shù)(標(biāo)簽向量)。而CRF 層接收發(fā)射矩陣作為輸入，通過計算標(biāo)簽的轉(zhuǎn)移分?jǐn)?shù)生成標(biāo)簽序列的概率分布，使用Viterbi 算法解碼得到最優(yōu)路徑。

在模型評估方法上，命名實體識別模型的評估方式通常分為兩種：一是通用的基于字符標(biāo)簽進(jìn)行直接評估，二是考慮實體邊界和實體類型的評測。前者是字符級別的評估，主要方法是將所有測試樣本的真實標(biāo)簽列表和預(yù)測標(biāo)簽列表進(jìn)行比對，直接計算Precision、Recall 和F1 值。然而這種評估方式應(yīng)用于序列標(biāo)注時效果并不理想。在序列標(biāo)注中，單個錯誤的字符標(biāo)簽的實際影響范圍涉及整個實體，因此序列標(biāo)注任務(wù)更多采用基于實體級別的評估方法，只有當(dāng)實體邊界和實體類別同時被標(biāo)記正確，才能認(rèn)為實體識別正確。Sang 等人提出的CoNLL-2003[21]基準(zhǔn)是一種典型的實體級別的命名實體識別模型評估方法，其中Precision 被定義為模型預(yù)測正確的命名實體占所有命名實體的百分比，Recall 是模型預(yù)測正確的命名實體占語料庫中所有命名實體的百分比，只有當(dāng)實體預(yù)測標(biāo)簽與真實標(biāo)簽完全匹配時才認(rèn)為預(yù)測正確。利用CoNLL-2003方法對模型訓(xùn)練結(jié)果進(jìn)行評估。根據(jù)驗證集上的模型評估結(jié)果，保存最優(yōu)模型。

通過構(gòu)建中文隱私政策語料庫并訓(xùn)練隱私政策權(quán)限詞命名實體識別模型，本文實現(xiàn)了隱私政策的自動化信息抽取，得到其中權(quán)限聲明相關(guān)的結(jié)構(gòu)化數(shù)據(jù)。

3 應(yīng)用程序動靜態(tài)混合分析

在本節(jié)中，通過應(yīng)用程序動靜態(tài)混合分析來識別危險權(quán)限調(diào)用情況，完成隱私政策文本與程序?qū)嶋H權(quán)限調(diào)用的一致性檢測。其中，在程序靜態(tài)分析部分，通過反編譯與源碼分析實現(xiàn)基于Androguard框架的危險權(quán)限調(diào)用檢測。在動態(tài)分析部分，利用基于Frida 的Hook 技術(shù)，實時獲取應(yīng)用使用的敏感權(quán)限并返回函數(shù)調(diào)用堆棧日志等。應(yīng)用程序動靜態(tài)混合分析整體方案如圖3 所示。

圖3 應(yīng)用程序動靜態(tài)混合分析方案架構(gòu)

3.1 構(gòu)建API-PERMISSION 映射

根據(jù)APK 文件精確識別出應(yīng)用實際使用的危險權(quán)限，是APP 合規(guī)檢測的重點以及難點所在。通過構(gòu)建權(quán)限映射關(guān)系，分析程序代碼中的敏感API，來完成危險權(quán)限調(diào)用識別。

根據(jù)安卓權(quán)限機制，所有危險權(quán)限都應(yīng)該在程序中動態(tài)申請，因此在危險權(quán)限獲取和使用的過程中，通常需要依賴某些特定的敏感API 來實現(xiàn)。此外，Intent 對象的某些特定ACTION 動作需要申請相關(guān)權(quán)限，通過Uri 訪問Content Provider 時，特定Uri對象也意味著應(yīng)用使用了相關(guān)權(quán)限。因此，敏感API、Intent ACTION 和Content Provider Uri 都能夠關(guān)聯(lián)應(yīng)用的危險權(quán)限調(diào)用行為。無論是靜態(tài)分析還是動態(tài)分析，核心思路都是捕獲程序的敏感API、Intent ACTION 或Content Provider Uri，實現(xiàn)對危險權(quán)限調(diào)用及敏感信息收集的檢測。

為了能夠識別應(yīng)用程序的實際權(quán)限調(diào)用情況，首先的工作是構(gòu)建全面、精準(zhǔn)的API-PERMISSION映射關(guān)系。在以往的工作中，PScout[22]利用Soot 框架執(zhí)行靜態(tài)分析并構(gòu)建函數(shù)調(diào)用圖，在圖上執(zhí)行向后可達(dá)性分析，識別出可達(dá)權(quán)限的所有API 調(diào)用，并重復(fù)可達(dá)性分析直到權(quán)限檢查數(shù)量收斂，最終構(gòu)建出Android API 16 到23 版本的權(quán)限映射結(jié)果；Axplorer[23]研究安卓框架的內(nèi)部結(jié)構(gòu)，生成高精度調(diào)用圖，并通過控制流切片進(jìn)行分析，最終生成Android API 16 到25 版本的權(quán)限映射結(jié)果。然而PScout 和Axplorer 的工作還存在一定的局限性，由于研究年限較早等原因，所涉及的API 版本也只局限在16 到25 版本，因此，在PScout 和Axplorer 工作的基礎(chǔ)上，本文對API 26 到32 版本中危險權(quán)限相關(guān)的API的映射關(guān)系進(jìn)行了補充。其中部分映射如表3 所示。

表3 部分API-PERMISSION 映射示例

對于Intent 和Content Provider 而言，危險權(quán)限通常與特定的ACTION或Uri 相關(guān)聯(lián)。Intent 對象啟動Activity時，某些特定ACTION 動作需要申請相關(guān)權(quán)限，例如android.intent.action.CALL需要使用CALL_PHONE 權(quán)限。訪問Content Provider 時，需要將指定Content Provider 的Uri 對象傳遞給Content-Resolver 類，然后通過Uri 定位資源，進(jìn)而完成增刪查改等操作，因此特定Uri 對象的訪問也意味著應(yīng)用需要提前申請并獲取相關(guān)敏感權(quán)限。

在對1 900 余款A(yù)pp 進(jìn)行測試和人工審核后，獲取了9 組24 種危險權(quán)限的共計9 200 余種APIPERMISSION 映射關(guān)系。

3.2 基于Androguard 的靜態(tài)分析

基于Androguard 的靜態(tài)分析模塊建立在APIPERMISSION 映射庫的基礎(chǔ)上。該模塊具有兩大功能：一是識別應(yīng)用實際調(diào)用的危險權(quán)限；二是識別應(yīng)用程序的頑固權(quán)限申請行為。

為了識別應(yīng)用實際調(diào)用的危險權(quán)限，采用以下流程進(jìn)行靜態(tài)分析：首先基于Androguard 訪問APK文件中的所有信息，并使用AnalyzeAPK()函數(shù)分析DEX文件，得到源碼中存在的所有類與字符串；接下來根據(jù)構(gòu)建好的權(quán)限映射關(guān)系，遍歷得到的所有類和字符串，如果存在敏感API 或特定Intent.ACTION/Content Provider Uri 對應(yīng)字符串，則根據(jù)映射關(guān)系庫輸出對應(yīng)危險權(quán)限。通過上述過程識別出源碼中存在的危險權(quán)限后，將識別出的危險權(quán)限集與隱私政策中聲明的權(quán)限集進(jìn)行一致性分析，判斷應(yīng)用存在的違規(guī)權(quán)限調(diào)用及超范圍隱私信息收集行為。

應(yīng)用程序的頑固權(quán)限申請行為檢測主要包括兩個步驟：第一步是根據(jù)函數(shù)之間的交叉引用，建立程序的函數(shù)調(diào)用圖(Call Graph)；第二步是根據(jù)函數(shù)調(diào)用圖，對權(quán)限申請點進(jìn)行動態(tài)回溯，查找可達(dá)的程序退出點，確定是否存在從權(quán)限申請函數(shù)到終止應(yīng)用函數(shù)的路徑。

首先，根據(jù)交叉引用建立函數(shù)關(guān)系圖，遍歷程序中所有方法，將這些方法作為有向圖中的節(jié)點，添加到函數(shù)調(diào)用圖中。然后查找每個函數(shù)節(jié)點的交叉引用，并通過圖中的有向邊表示函數(shù)之間的調(diào)用關(guān)系。圖4 展示了一個典型的函數(shù)調(diào)用圖示例，其中，淺灰色表示Activity 內(nèi)部節(jié)點的相互調(diào)用，而深灰色則表示內(nèi)部節(jié)點對外部節(jié)點的調(diào)用。

圖4 靜態(tài)分析得到的函數(shù)調(diào)用圖

為確定權(quán)限申請的相關(guān)入口點是否會在一定條件下(即用戶拒絕權(quán)限申請時)導(dǎo)致應(yīng)用運行終止，可采用可達(dá)性分析方法，對以此類入口點為根節(jié)點的函數(shù)調(diào)用圖進(jìn)行遍歷，以確定是否存在從權(quán)限申請函數(shù)到終止應(yīng)用函數(shù)的路徑。表4 中展示了一些常見的權(quán)限申請入口點與程序終止出口點。

表4 部分權(quán)限申請入口點與程序終止出口點示例

當(dāng)應(yīng)用存在頑固權(quán)限申請行為時，權(quán)限申請函數(shù)和應(yīng)用終止函數(shù)通常為并列關(guān)系。checkSelfPermission 檢查程序權(quán)限申請狀態(tài)，該函數(shù)作為頑固索權(quán)的入口點，finish 函數(shù)在未獲得授權(quán)時結(jié)束程序，作為頑固索權(quán)終止點，二者在函數(shù)調(diào)用圖中都是通過onClick 調(diào)用，基于這種位置關(guān)系，可對入口點進(jìn)行有界回溯，搜索函數(shù)關(guān)系圖中是否存在對應(yīng)的程序終止點。

3.3 基于Frida 的動態(tài)分析

Frida 是一款基于Python 和JavaScript 的輕量級可編程調(diào)試框架，它具有細(xì)粒度的流程控制、代碼級的可定制體系并且可以不斷進(jìn)行動態(tài)調(diào)試。動態(tài)分析基于Frida 框架自動化Hook App 所有敏感API的調(diào)用行為，利用Python 實現(xiàn)遠(yuǎn)程過程調(diào)用(RPC)，通過JavaScript 腳本生成Native 函數(shù)實現(xiàn)敏感API攔截與重載，記錄待檢測樣本運行時獲取隱私信息的行為，動態(tài)分析方案架構(gòu)如圖5 所示。

圖5 Frida 動態(tài)插樁分析方案架構(gòu)

Frida 框架分為客戶端和服務(wù)端，服務(wù)端中運行著Frida-Server 后臺進(jìn)程和Hook 目標(biāo)進(jìn)程?？蛻舳薘PC 遠(yuǎn)程過程調(diào)用連接到服務(wù)端上的Frida-Server，當(dāng)Frida-Server 接收到Hook 指令時，F(xiàn)rida-Server 會向目標(biāo)進(jìn)程中注入JavaScript 腳本及其執(zhí)行引擎環(huán)境。通過Frida 動態(tài)插樁技術(shù)，可以將JavaScript 腳本插入到平臺原生App 的內(nèi)存空間中，實現(xiàn)對程序邏輯的跟蹤、監(jiān)控甚至修改，因此Frida 框架可以實現(xiàn)從Java 層到Native 層的函數(shù)Hook。執(zhí)行Hook 操作時需要找到Hook 位置，即類名加方法名，通過將JavaScript 注入到黑盒進(jìn)程中，F(xiàn)rida 框架能夠Hook目標(biāo)程序中幾乎任何方法。在找到Hook 位置后，需要在目標(biāo)進(jìn)程中觸發(fā)對應(yīng)的方法。Frida 框架通過修改Dalvik 虛擬機的accessFlags 標(biāo)志，將需要Hook的Java 方法注冊為Native 方法，并修改函數(shù)的入口為自定義的內(nèi)容。當(dāng)系統(tǒng)執(zhí)行到待Hook 的目標(biāo)方法時，虛擬機優(yōu)先執(zhí)行Native 方法，此時Frida 擁有了程序控制權(quán)，可以優(yōu)先執(zhí)行注入代碼，實現(xiàn)對程序邏輯的跟蹤、監(jiān)控與修改。

JavaScript 腳本是注入目標(biāo)進(jìn)程并Hook 敏感API的關(guān)鍵。在JavaScript 腳本中，首先通過java.use()函數(shù)找到目標(biāo)類并實例化一個對象，調(diào)用目標(biāo)類成功后，使用overload()函數(shù)對敏感API 進(jìn)行攔截并重載，在完成重載后，可以實時獲得敏感API 的參數(shù)，并可以根據(jù)需要對參數(shù)內(nèi)容進(jìn)行修改。

當(dāng)手機端進(jìn)行觸發(fā)敏感行為的操作時，返回權(quán)限調(diào)用時間、權(quán)限調(diào)用類型、關(guān)鍵參數(shù)內(nèi)容以及函數(shù)調(diào)用堆棧等信息。通過動態(tài)分析，可實現(xiàn)以下兩種隱私違規(guī)行為的檢測：

(1)用戶同意隱私政策前的違規(guī)權(quán)限調(diào)用與信息收集行為。通過模擬用戶操作到達(dá)隱私政策控件所在的Activity，測試在點擊同意的控件之前，應(yīng)用是否存在收集IMEI、設(shè)備MAC 地址、通訊錄和短信等敏感信息的行為。

(2)程序靜默狀態(tài)下的頻繁收集行為。App 在靜默狀態(tài)或后臺運行時，如果存在權(quán)限調(diào)用與信息收集行為，也會實時觸發(fā)Hook。

4 實驗與分析

4.1 測試方案

本文對隱私政策權(quán)限詞實體識別模型性能以及隱私合規(guī)檢測整體方案在實際場景下的檢測能力進(jìn)行了測試，具體測試方法如下：

(1)模型測試部分，采用考慮實體邊界和實體類別的CoNLL-2003[21]方法進(jìn)行命名實體識別性能評估，評估指標(biāo)包括Precision、Recall 和F1-score，每100 次訓(xùn)練對模型進(jìn)行評估，累計1 000 次訓(xùn)練F1-score 無優(yōu)化后停止迭代。

(2) 檢測能力測試部分，采取實證評估方法對來自小米應(yīng)用市場與360 手機助手的1 941 款應(yīng)用進(jìn)行隱私合規(guī)檢測。

4.2 測試環(huán)境與系統(tǒng)架構(gòu)

本文實現(xiàn)的隱私合規(guī)檢測系統(tǒng)包括PC 端與手機模擬器端兩個部分。PC 端在Windows 10 21H1 64位系統(tǒng)上進(jìn)行測試，處理器為Inter Core i5-11300H 3.10 GHz，內(nèi)存為Micron Technology 16 GB，軟件環(huán)境包括Python 3.10，Androguard 3.3.5，Uiautomator2，PyTorch 1.11.0 等，手機模擬器采用逍遙模擬器7.6.1版本，機型為OPPO RENO PRO，系統(tǒng)版本為Android 7.1.2。隱私合規(guī)檢測系統(tǒng)整體架構(gòu)如圖6 所示，自下而上包括隱私政策語料庫、隱私政策解析模塊、應(yīng)用程序分析模塊、隱私合規(guī)項檢測模塊。

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

4.3 實驗結(jié)果分析

模型測試部分，每100 次訓(xùn)練正向傳播和反向傳播完成后，計算模型在驗證集上的損失函數(shù)，同時評估危險權(quán)限詞實體識別F1 值，實驗結(jié)果如圖7 所示。

圖7 中，方框坐標(biāo)軸及折線代表訓(xùn)練過程中驗證集上的損失，三角坐標(biāo)軸及折線代表訓(xùn)練過程中驗證集上的F1 值，在第1 800 次訓(xùn)練時獲得最小損失和最大F1 值，此后1 000 次訓(xùn)練中F1 值無優(yōu)化，模型停止迭代。

圖7 模型在驗證集上的損失與F1 值

在測試集上對最優(yōu)模型在9 類權(quán)限詞實體識別任務(wù)的Precision、Recall 和F1-score 進(jìn)行評估，測試結(jié)果如表5 所示。

表5 最優(yōu)模型在9 類權(quán)限詞實體識別下的測試結(jié)果(%)

最終，在9 類危險權(quán)限詞實體識別任務(wù)上的平均Precision 為91.09%，平均Recall 為93.21%，平均F1-score 為91.92%，結(jié)果說明模型在實體識別任務(wù)上有較優(yōu)的性能。

在檢測能力測試部分，利用該系統(tǒng)對小米應(yīng)用市場和360 手機助手的1 941 款應(yīng)用進(jìn)行合規(guī)檢測，共計發(fā)現(xiàn)52 款A(yù)pp 存在隱私合規(guī)問題，包括32 款應(yīng)用未聲明全部隱私權(quán)限，即存在隱私政策聲明與權(quán)限調(diào)用不一致，5 款應(yīng)用存在用戶同意隱私政策前收集敏感信息，3 款應(yīng)用無隱私政策聲明，1 款應(yīng)用的隱私政策存在冗余聲明，1 款應(yīng)用存在強制索取權(quán)限等。

5 結(jié)論

隨著App 違法違規(guī)收集使用個人信息專項治理工作的不斷深入，監(jiān)管部門、企業(yè)開發(fā)者以及個人用戶對于App 隱私合規(guī)檢測的需求都不斷增加?，F(xiàn)有隱私合規(guī)檢測產(chǎn)品由于忽略對隱私政策的評估，因而產(chǎn)生較高的誤報率和漏報率。

該研究從實際需求出發(fā)，構(gòu)建了安卓應(yīng)用隱私政策與權(quán)限調(diào)用一致性合規(guī)檢測系統(tǒng)，主要包括四個創(chuàng)新點：(1)構(gòu)建首個中文隱私政策語料庫并訓(xùn)練危險權(quán)限詞實體識別模型，以平均91.92%的F1 值完成了隱私政策危險權(quán)限詞信息抽?。?2)提出輕量級、低開銷的安卓應(yīng)用權(quán)限調(diào)用動靜態(tài)混合分析方案，通過對程序中的敏感API 進(jìn)行定位或重載，實現(xiàn)了程序?qū)嶋H調(diào)動危險權(quán)限的動靜態(tài)檢測；(3)構(gòu)建半自動化的安卓應(yīng)用隱私聲明與權(quán)限調(diào)用一致性合規(guī)檢測框架，通過將隱私聲明權(quán)限集與程序?qū)嶋H調(diào)用的危險權(quán)限集進(jìn)行一致性分析，識別未聲明的權(quán)限調(diào)用與敏感信息收集行為；(4)針將強制索取權(quán)限、用戶同意隱私政策前收集敏感信息、后臺或靜默狀態(tài)下頻繁收集敏感信息等子功能進(jìn)行集成，實現(xiàn)對于主流違規(guī)行為的檢測。

該方案設(shè)計還存在一定的改進(jìn)空間：(1)本作品對于“隱私”的關(guān)注范疇僅限于應(yīng)用程序通過危險權(quán)限獲取到的敏感信息，但在實際應(yīng)用場景中，仍存在部分隱私信息是用戶通過應(yīng)用的UI 界面提供的，例如手機號碼、身份證號碼、搜索偏好等，對于這類數(shù)據(jù)的合規(guī)保護(hù)需要更多結(jié)合UI 控件及數(shù)據(jù)流的污點分析方法進(jìn)行研究；(2)在隱私政策解析工作中重點關(guān)注危險權(quán)限術(shù)語的實體識別，對于語義理解與句法分析未能展開深入探討與研究。

綜上所述，該研究在現(xiàn)階段下很好地解決了國內(nèi)App 隱私合規(guī)檢測所面臨的技術(shù)挑戰(zhàn)，有效彌補了隱私政策與程序分析項結(jié)合在一致性合規(guī)檢測領(lǐng)域的空缺。同時，該研究構(gòu)建的中文隱私政策語料庫也能夠為日后的相關(guān)研究提供基準(zhǔn)數(shù)據(jù)集，具有重要現(xiàn)實意義和廣闊應(yīng)用前景，對App 隱私合規(guī)的長效治理工作起到積極的促進(jìn)作用。