宋宇波，陳琪，宋睿，胡愛群

（1.東南大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，江蘇 南京 211189；2.東南大學(xué)江蘇省計算機(jī)網(wǎng)絡(luò)技術(shù)重點實驗室，江蘇 南京 211189；3.網(wǎng)絡(luò)通信與安全紫金山實驗室，江蘇 南京 211189；4.東南大學(xué)信息科學(xué)與工程學(xué)院，江蘇 南京 211189）

1 引言

目前，手機(jī)已成為人們生活不可分割的一部分，人們通過手機(jī)進(jìn)行視頻通信、電子商務(wù)和網(wǎng)絡(luò)教學(xué)等活動。由于手機(jī)和個人信息的高度捆綁，惡意攻擊者開始攻擊智能設(shè)備，導(dǎo)致用戶的敏感信息和個人隱私數(shù)據(jù)泄露。在眾多智能終端中，安裝了Android 系統(tǒng)的終端占有最大比例，這意味著Android系統(tǒng)所受到的惡意攻擊和安全威脅也最多。Android系統(tǒng)的安全機(jī)制存在幾個關(guān)鍵的薄弱環(huán)節(jié)。

1) Android 系統(tǒng)的碎片化問題給該系統(tǒng)的安全防護(hù)帶來了巨大的障礙。Google 官方發(fā)布的系統(tǒng)補(bǔ)丁只優(yōu)先提供給Android 系統(tǒng)的最新發(fā)行版本，通常并不承諾甚至拒絕前向兼容舊版本的系統(tǒng)[1]。因此，大量安裝了舊版本Android 系統(tǒng)的設(shè)備只能被動地等待各級系統(tǒng)提供商發(fā)布更新補(bǔ)丁。

2) Android 系統(tǒng)采用基于權(quán)限的安全模型來保護(hù)用戶的敏感資源和個人隱私，然而這種通用的模型并不能滿足某些特定的安全需求。一些個人和組織出于使用環(huán)境或場景的考慮，有強(qiáng)烈動機(jī)需要對特定應(yīng)用程序執(zhí)行定制的安全防護(hù)策略[2-3]，僅依靠Android 系統(tǒng)的安全架構(gòu)完全無法滿足這一需求。

3) 與另一個主要的移動設(shè)備操作系統(tǒng)iOS 不同，Android 系統(tǒng)并不強(qiáng)制要求統(tǒng)一的應(yīng)用程序發(fā)布和審查機(jī)制。Android 系統(tǒng)的應(yīng)用程序不需要經(jīng)過充分有效的審核流程就可以被安裝到設(shè)備上，這給Android 系統(tǒng)用戶帶來了巨大的安全風(fēng)險。

針對上述安全漏洞和惡意攻擊方法，已經(jīng)有很多研究者提出了各種分析和檢測Android 系統(tǒng)惡意應(yīng)用的方案，并且開發(fā)了許多技術(shù)和工具[4-6]。研究者通常采用靜態(tài)代碼分析或動態(tài)運(yùn)行時檢測等手段對惡意應(yīng)用軟件進(jìn)行檢測與甄別[7]。靜態(tài)檢測通常通過分析 Android應(yīng)用程序的AndroidManifest.xml 文件來考察應(yīng)用程序的權(quán)限調(diào)用情況，或者逆向得到應(yīng)用程序的源代碼，并對代碼的執(zhí)行邏輯進(jìn)行分析。然而，考慮到Android 應(yīng)用程序的軟件規(guī)模與日俱增，同時代碼混淆和加固技術(shù)被廣泛應(yīng)用于軟件發(fā)布和打包過程，靜態(tài)源代碼分析的甄別能力極其有限。相對地，動態(tài)分析方法能夠從程序執(zhí)行邏輯層面考察應(yīng)用程序的行為，通常構(gòu)建獨立檢測環(huán)境并將應(yīng)用程序置于該環(huán)境中，通過污點分析、黑盒測試等方式對應(yīng)用程序進(jìn)行分析和測試[8]。然而，現(xiàn)在的惡意攻擊者能夠檢測應(yīng)用程序運(yùn)行時是否處于被監(jiān)控環(huán)境或仿真器環(huán)境下，進(jìn)而使其惡意邏輯失活從而逃避動態(tài)運(yùn)行時檢測[9]。

靜態(tài)分析和動態(tài)分析等手段是對惡意應(yīng)用程序進(jìn)行甄別，并對甄別出的應(yīng)用程序進(jìn)行相應(yīng)的封禁處理。這些已有的研究無法解決新的Android 版本中增加的動態(tài)權(quán)限申請?zhí)匦詭淼淖R別困難問題，也無法解決利用反射特性等技術(shù)進(jìn)行動態(tài)代碼構(gòu)造的惡意應(yīng)用程序的識別問題。

基于此，本文設(shè)計并實現(xiàn)了一個Android 應(yīng)用程序的動態(tài)策略權(quán)限控制系統(tǒng)，可根據(jù)用戶需求實施權(quán)限控制和生成安全策略。該系統(tǒng)基于Android的虛擬機(jī)字節(jié)碼注入技術(shù)，在目標(biāo)應(yīng)用程序涉及敏感操作和危險權(quán)限調(diào)用的方法單元中添加安全策略執(zhí)行代碼，并通過Java 反射特性動態(tài)地調(diào)用安全功能，在安全需求發(fā)生變更時動態(tài)切換權(quán)限控制級別，而不需要重新注入字節(jié)碼或?qū)?yīng)用程序進(jìn)行重打包。通過這種權(quán)限策略控制，用戶和組織能夠根據(jù)需求動態(tài)地允許或禁止應(yīng)用程序的權(quán)限授予和使用，從而更好地保護(hù)個人和組織隱私安全。

2 相關(guān)工作

Android 移動操作系統(tǒng)的安全性構(gòu)建在以權(quán)限系統(tǒng)為基礎(chǔ)的敏感資源訪問模型上，這些敏感資源包括但不限于位置信息，以及相機(jī)傳感器、麥克風(fēng)、通信錄和SMS（short messaging service）的信息等。通常，若一個Android 應(yīng)用程序企圖獲取對某個敏感資源的訪問權(quán)限，就必須在Android Manifest.xml清單中顯式地聲明所需的權(quán)限。而用戶可以選擇授予或者不授予該權(quán)限。但是，這樣的權(quán)限系統(tǒng)正在被一些應(yīng)用程序濫用，這些應(yīng)用程序聲明的權(quán)限遠(yuǎn)多于實現(xiàn)必要功能所必需的權(quán)限[10]。Felt 等[11]考察了應(yīng)用市場上的相當(dāng)一部分應(yīng)用程序，并發(fā)現(xiàn)大量應(yīng)用程序都存在上述問題。更糟糕的是，每當(dāng)操作系統(tǒng)或者應(yīng)用程序更新時，這些惡意的應(yīng)用程序都可以通過更新累積的方式進(jìn)行特權(quán)升級，從而在靜默狀態(tài)下轉(zhuǎn)換成惡意軟件[12]。

針對上述問題，近年來相關(guān)領(lǐng)域研究者主要采用靜態(tài)分析和動態(tài)分析2 種思路來進(jìn)行惡意軟件檢測與防護(hù)。靜態(tài)分析方法主要利用靜態(tài)代碼分析的手段來檢查應(yīng)用程序是否包含異常的權(quán)限申請和信息流[13]，具有較好的可擴(kuò)展性，可以從較大數(shù)量級的應(yīng)用程序中快速篩選出可疑的應(yīng)用程序。作為一個面向普通消費(fèi)者的商業(yè)級操作系統(tǒng)，Android系統(tǒng)需要面對各種應(yīng)用場景，因此必須使用事件驅(qū)動的設(shè)計思路，具體來說就是廣泛利用生命周期鉤子和GUI（graphical user interface）回調(diào)處理來處理用戶的實時請求。運(yùn)行時的權(quán)限申請控制和數(shù)據(jù)流并非總可以通過靜態(tài)代碼分析檢測出來，因為應(yīng)用程序的執(zhí)行流程取決于具體的運(yùn)行時環(huán)境和用戶行為[14]。另外，靜態(tài)分析方法檢測通過動態(tài)代碼構(gòu)造的惡意行為，如通過Java 反射機(jī)制調(diào)用敏感應(yīng)用程序接口（API,application programming interface）的能力極其有限。惡意攻擊者通常能夠輕易攻擊這一缺陷構(gòu)造，采用代碼混淆[15]或代碼異變[16]的方法來誤導(dǎo)靜態(tài)檢查機(jī)制。Suarez 等[17]提出了以資源為中心的新的靜態(tài)分析方法以克服上述的限制，但是惡意程序仍然可以通過采用資源混淆的方法來規(guī)避以資源調(diào)用為中心的檢測系統(tǒng)[18]。

相比之下，動態(tài)分析提供了檢測和防護(hù)惡意應(yīng)用程序的補(bǔ)充和完善方法。常用的動態(tài)檢測方法包括基于行為的惡意軟件檢測[19]、基于系統(tǒng)API 調(diào)用追蹤的程序行為建模[20-21]以及基于資源利用的已用程序行為分析[22]。在動態(tài)分析領(lǐng)域，機(jī)器學(xué)習(xí)技術(shù)越來越廣泛地應(yīng)用于區(qū)分惡意應(yīng)用和良性應(yīng)用。然而，當(dāng)惡意應(yīng)用對系統(tǒng)調(diào)用進(jìn)行代碼混淆時，基于系統(tǒng)調(diào)用分析的動態(tài)檢測系統(tǒng)仍然有可能被規(guī)避[23]。

綜上所述，無論是靜態(tài)檢測還是動態(tài)檢測方法，都存在固有的弊端，并不適用于全部的Android應(yīng)用程序。這些方法主要著眼于分類并甄別出惡意應(yīng)用，而很少討論應(yīng)該如何對甄別出的惡意應(yīng)用的攻擊行為進(jìn)行防護(hù)。

此外，也有一些研究在字節(jié)碼級別上對需要提供安全性的方法單元添加安全功能。Lee 等[24]提出了一種使用應(yīng)用程序包裝技術(shù)的方案，在代碼的方法上添加必要的安全功能。該方案在字節(jié)碼級別添加了安全功能，而不依賴Android 的Java 或Kotlin源代碼。具體地，該方案將所需的安全功能封裝成字節(jié)碼級別的smali 代碼，并在需要安全性的方法點上將這些代碼注入應(yīng)用程序中。這種方法的缺點很明顯，它是在靜態(tài)策略的基礎(chǔ)上運(yùn)行的，這意味著每當(dāng)更改安全策略時，都需要重新提取并注入安全代碼，并重新包裝應(yīng)用程序。

針對這些問題，本文提出了一種基于虛擬機(jī)字節(jié)碼的動態(tài)安全策略控制方法，該方法能夠檢測Android 應(yīng)用程序中涉及危險權(quán)限請求和敏感數(shù)據(jù)訪問的代碼單元，并將用戶指定的安全策略以虛擬機(jī)字節(jié)碼的形式注入相應(yīng)代碼位置，依照用戶的安全需求對應(yīng)用程序的危險行為進(jìn)行防護(hù)和控制，并根據(jù)用戶所指定的安全策略的變更而動態(tài)調(diào)整控制級別。

3 基于字節(jié)碼注入的應(yīng)用隱私保護(hù)機(jī)制

本文提出了一種控制Android 應(yīng)用程序?qū)τ脩裘舾行畔⒃L問和危險權(quán)限調(diào)用的隱私保護(hù)系統(tǒng)（下文簡稱為本系統(tǒng)），其基于安全策略生成的虛擬機(jī)字節(jié)碼注入技術(shù)，通過在目標(biāo)應(yīng)用程序中注入控制機(jī)制以限制危險權(quán)限的訪問并強(qiáng)制規(guī)范應(yīng)用程序的行為。本系統(tǒng)基于動態(tài)安全策略生成機(jī)制，這意味著系統(tǒng)所應(yīng)用的安全策略可以根據(jù)用戶需求動態(tài)調(diào)整，該機(jī)制通過將安全約束規(guī)范和具體代碼行為解耦合來實現(xiàn)動態(tài)性和靈活性。動態(tài)策略生成機(jī)制保證即使用戶或組織頻繁地修改安全策略，本系統(tǒng)也不需要重新編譯應(yīng)用程序或?qū)?yīng)用程序進(jìn)行重打包。

圖1 是本系統(tǒng)的結(jié)構(gòu)概覽。本系統(tǒng)能夠根據(jù)用戶和組織的需求，通過數(shù)學(xué)和形式邏輯的相關(guān)理論抽象出特定的行為模型。該行為模型將數(shù)據(jù)流、事件時間、用戶身份與角色因素列入考慮，并得到抽象的安全策略。同時，本系統(tǒng)提供了一個安全策略生成器（SSG,security strategy generator）。SSG 能夠通過執(zhí)行一組細(xì)粒度的安全規(guī)則將用戶輸入的抽象策略轉(zhuǎn)換成具體的權(quán)限控制策略。實例化的安全策略將指導(dǎo)系統(tǒng)生成一個包含安全方法的字節(jié)碼安全運(yùn)行庫，其中包含了執(zhí)行安全策略的代碼。安全運(yùn)行庫被嵌入應(yīng)用程序字節(jié)碼級的危險權(quán)限請求和敏感API 調(diào)用位置，并與原始應(yīng)用字節(jié)碼一起被重新打包生成一個包含安全決策中心（SDC,security decision center）的應(yīng)用程序。應(yīng)用程序中嵌入了一系列的策略執(zhí)行器（PE,policy executor），這些PE 能夠在應(yīng)用觸發(fā)權(quán)限請求行為時向安全決策中心發(fā)出事件通知，并向安全決策中心索取安全策略指定的授權(quán)操作以執(zhí)行具體的策略。

圖1 本系統(tǒng)的結(jié)構(gòu)概覽

3.1 安全策略的生成

要實現(xiàn)能夠滿足細(xì)粒度控制需求的安全策略生成機(jī)制，首先需要對用戶的行為模型進(jìn)行抽象。行為模型抽象的目的是梳理用戶實體和應(yīng)用程序?qū)嶓w間的交互方式，并將實體間的詳細(xì)交互流程進(jìn)行抽象以便于工程實現(xiàn)。本文所提的行為模型能夠提供數(shù)據(jù)機(jī)密性、用戶的感知與控制、訪問權(quán)限控制和信任管理等多層次的安全功能。為了實現(xiàn)上述需求，行為模型需要對數(shù)據(jù)流、事件時間、用戶身份與角色、環(huán)境與場景、信任關(guān)系等因素進(jìn)行邏輯學(xué)抽象。

安全策略生成機(jī)制使用事件?條件?動作（ECA,event-condition-action）規(guī)則來提取抽象策略和詳細(xì)執(zhí)行策略。ECA 模板的抽象語法如算法1 所示。SSG持續(xù)監(jiān)視從模板實例化的ECA，PE 表示特定組合的所有條件，Ci∈PE 表示特定模式的事件使特定組合的所有條件得到滿足，此時執(zhí)行相應(yīng)的授權(quán)操作。

算法1事件條件操作規(guī)則

輸入事件模式集合E，用戶指定的條件C，用戶指定的時延D，信任類型T，應(yīng)用程序控制單元個數(shù)n，規(guī)則模板R

上述活動模式是指與臨時或規(guī)律的行為或交互相匹配的模式，指定這種模式能夠支持檢測性和預(yù)防性的安全策略。上述條件可能對應(yīng)各種復(fù)雜的執(zhí)行流程和分支場景，如事件模式、外部行為、定時條件、執(zhí)行條件、上下文、用戶身份或角色、用戶和行為可行度等。上述權(quán)限操作的執(zhí)行具體是指對臨時操作的授權(quán)或拒絕，也可以更細(xì)粒度地根據(jù)安全需求有選擇地修改行為的屬性或延遲行為的執(zhí)行。規(guī)則模板甚至支持將行為進(jìn)行模塊化，這樣就能將不同的行為按照一定規(guī)則進(jìn)行組合、循環(huán)或分支判斷，以支持額外的活動或動態(tài)地更新模型的信任等級，如提升或降低模型的信任度。例如，行為模塊化支持實現(xiàn)以下操作，在特定應(yīng)用程序觸發(fā)了某些指定的隱私敏感行為時通過SMS 或電子郵件通知用戶。

3.2 虛擬字節(jié)碼注入

本文使用中間層的Dalvik 字節(jié)碼，而不使用反編譯源代碼，這是因為近年來Google 官方鼓勵開發(fā)者使用Kotlin 語言進(jìn)行Android 開發(fā)，但是不管是Kotlin 還是Java 編寫的應(yīng)用程序，在編譯階段都將統(tǒng)一編譯Android 系統(tǒng)專有的基于寄存器的Dalvik 字節(jié)碼。另外，成熟的Android 應(yīng)用程序開發(fā)者出于應(yīng)用安全角度和知識產(chǎn)權(quán)保護(hù)角度，通常會對應(yīng)用程序源代碼進(jìn)行代碼混淆、加固或代碼加殼等操作，這極大地增加了將二進(jìn)制代碼或字節(jié)碼還原到Java 或Kotlin 源代碼的難度。即使將二進(jìn)制文件或字節(jié)碼還原為原始代碼，其因代碼混淆帶來的極低可讀性也會使這樣的努力得不償失。

代碼1 展示了對Android 應(yīng)用程序進(jìn)行反編譯的一個實例，該實例將一個應(yīng)用程序的二進(jìn)制文件反編譯為Dalvik 字節(jié)碼的smali 表示。

代碼1

在代碼1 中，應(yīng)用程序試圖調(diào)用Telephony-Manager 類中的get DeviceId(String)方法。該方法能夠得到用戶設(shè)備的唯一標(biāo)識符，該標(biāo)識符通常被應(yīng)用程序用來對用戶進(jìn)行追蹤和識別，以對用戶行為進(jìn)行建?；蚍治鲇脩舻男袨槠?。

1) 安全策略的實例化

本系統(tǒng)會根據(jù)用戶或組織制定的安全策略向應(yīng)用程序植入特定的安全控制代碼。此外，為了實現(xiàn)動態(tài)性，在代碼植入時，除了用戶或組織指定的安全策略，本系統(tǒng)還會檢測應(yīng)用程序中尚未被用戶指定的敏感API 調(diào)用或危險權(quán)限請求。這樣，在嵌入了安全策略的Android 應(yīng)用程序運(yùn)行時，當(dāng)?shù)竭_(dá)敏感API 調(diào)用方法時，安全決策中心將首先檢查用戶或組織是否已經(jīng)為該API 調(diào)用定義了安全策略。如果用戶針對該API 調(diào)用定義了安全策略，安全決策中心會通知策略執(zhí)行器執(zhí)行相應(yīng)的安全策略代碼；如果用戶未定義相關(guān)策略，安全決策中心會略過該API 調(diào)用并繼續(xù)檢測其他的API 調(diào)用。部分敏感的API 調(diào)用如表1 所示。

表1 部分敏感的API 調(diào)用

需要說明的是，未定義策略時嵌入的安全代碼并不會對應(yīng)用程序的性能造成過大的影響，應(yīng)用程序?qū)⒁詭缀蹩梢院雎缘臅r延繼續(xù)運(yùn)行?；谶@樣的設(shè)計，本系統(tǒng)提出的字節(jié)碼嵌入技術(shù)能夠在用戶或組織想要更改安全策略時動態(tài)地響應(yīng)用戶的需求，而不需要重新嵌入安全策略字節(jié)碼或?qū)?yīng)用程序進(jìn)行重打包，因為本文在初次進(jìn)行代碼靜態(tài)分析和字節(jié)碼植入時已經(jīng)考慮了所有可能的安全控制需求。

注入應(yīng)用程序的安全代碼，更具體地說就是一系列的策略執(zhí)行器，將以代理模式被添加到應(yīng)用程序的相應(yīng)位置中。通過將策略執(zhí)行器以安全代理的形式封裝起來，本系統(tǒng)可以極大地減少對原始應(yīng)用程序代碼的侵入性，并為修改后的應(yīng)用程序提供更高的穩(wěn)健性和可用性。在靜態(tài)分析階段，本系統(tǒng)將通過分析應(yīng)用程序的Android Manifest.xml 文件和應(yīng)用程序的反編譯字節(jié)碼確定在該應(yīng)用程序中所涉及的所有敏感操作和權(quán)限申請，并針對性地抽取相應(yīng)的策略執(zhí)行器組成用于注入程序的運(yùn)行庫。隨后，系統(tǒng)將在原始應(yīng)用程序的敏感操作和權(quán)限申請涉及的所有方法前后注入對執(zhí)行器的調(diào)用，這些調(diào)用將根據(jù)用戶或組織的聲明來決定是否調(diào)用相關(guān)的策略執(zhí)行器，并在相關(guān)權(quán)限操作之前或之后進(jìn)行相應(yīng)的安全操作。以設(shè)備定位信息的控制為例，Dalvik 字節(jié)碼展示了一個應(yīng)用程序獲取定位數(shù)據(jù)的方法單元，如代碼2 所示。可以看到，開發(fā)者預(yù)先在類中聲明了一個android.location.Location Manage類實例Xl，用于向操作系統(tǒng)的定位管理器申請定位數(shù)據(jù)；隨后，通過 Location Manager 類的getLast Known Location()方法獲取設(shè)備的最后位置。值得注意的是，該應(yīng)用程序在打包時使用了代碼混淆技術(shù)，因此方法名A()和字段名Xl 都是無意義的字符串。

代碼2

上述私有方法封裝了定位數(shù)據(jù)的獲取方式，當(dāng)應(yīng)用程序在業(yè)務(wù)邏輯中需要請求設(shè)備定位時將會申請訪問該類的公有方法。Dalvik 字節(jié)碼()展示了該類的一個關(guān)鍵公有方法，如代碼3 所示。該方法通過調(diào)用上述私有方法向應(yīng)用程序的其他業(yè)務(wù)邏輯部分暴露了一個定位數(shù)據(jù)申請接口。代碼3 定義了一個名為 gn()的公有方法。該方法首先檢查了Android Manifest.xml 清單中是否聲明了ACCESS_FINE_LOCATION 權(quán)限，并確認(rèn)用戶已經(jīng)向應(yīng)用授予了該權(quán)限；隨后，調(diào)用上面定義的A(Ljava/lang/String;)方法以獲取設(shè)備的定位數(shù)據(jù)。

代碼3

顯然，公有方法gn()Landroid/location/Location訪問定位數(shù)據(jù)的關(guān)鍵接口。為了對該應(yīng)用程序的定位數(shù)據(jù)訪問行為進(jìn)行控制，需要在gn()方法中注入安全策略控制代碼。為了保證用戶能夠根據(jù)具體需求對應(yīng)用行為進(jìn)行不同程度的限制，本文注入的安全策略代碼不會將控制邏輯固化到gn()方法單元中，而是通過Java 反射策略調(diào)用安全決策中心來實現(xiàn)動態(tài)控制。需要注意的是，對gn()方法的修改將影響虛擬機(jī)寄存器的分配。

圖2 展示了在Android 應(yīng)用程序的敏感操作前后注入安全策略執(zhí)行代碼的流程。當(dāng)應(yīng)用程序執(zhí)行到該敏感操作時，策略執(zhí)行器會向安全決策中心請求安全策略。若安全策略中包含了對該敏感操作的限制規(guī)則，安全決策中心指示策略執(zhí)行器進(jìn)行相應(yīng)的權(quán)限控制和安全操作。例如，若安全策略對該敏感操作涉及的危險權(quán)限做出了禁止聲明，策略執(zhí)行器就會直接忽略對該方法的調(diào)用；類似地，若安全策略指示對該敏感操作進(jìn)行延遲或條件修改，策略執(zhí)行器也會執(zhí)行相應(yīng)的安全操作。上述操作都是指在敏感操作之前進(jìn)行的安全代理，對于在敏感操作之后進(jìn)行的安全代理，只能對操作進(jìn)行修改或延遲，因為敏感操作已經(jīng)執(zhí)行，無法對其進(jìn)行禁止。

圖2 在敏感操作前后注入安全策略執(zhí)行代碼流程

將安全策略注入Android 應(yīng)用程序后，安全決策中心將在應(yīng)用程序的主活動中的onCreate()方法中初始化。在有些情況下，會因為設(shè)備、版本或其他原因而導(dǎo)致安全決策中心初始化失敗而導(dǎo)致安全策略處于不可用的狀態(tài)，這時被安全強(qiáng)化的應(yīng)用程序?qū)⒃儐栍脩羰欠裰卦嚦跏蓟踩珱Q策中心，若用戶拒絕重試并試圖在此情況下繼續(xù)運(yùn)行應(yīng)用程序，應(yīng)用程序執(zhí)行到敏感操作或危險權(quán)限調(diào)用時會對用戶提出安全警告。此外，在應(yīng)用程序執(zhí)行期間，軟件資源、硬件問題或功耗等原因都可能導(dǎo)致安全策略中心變?yōu)椴豢捎脿顟B(tài)，為了保證安全性和穩(wěn)健性，應(yīng)用程序?qū)⒃趫?zhí)行到安全敏感操作或權(quán)限申請時提示用戶，讓用戶自行決定是否繼續(xù)執(zhí)行相關(guān)操作，并為應(yīng)用程序接下來可能遭遇的安全決策征求用戶的默認(rèn)許可或拒絕。用戶所進(jìn)行的決策可以作為后續(xù)相關(guān)操作出現(xiàn)時的默認(rèn)操作，系統(tǒng)將會緩存用戶所給出的決策，并在下次出現(xiàn)類似決策時提供參考，以實現(xiàn)對于同一安全決策的一致性。

2) 安全策略的動態(tài)調(diào)整

注入了安全策略的 Android 應(yīng)用程序已經(jīng)可以按照用戶指定的安全需求完成相應(yīng)的安全操作。但是隨著場景需求、信任關(guān)系、用戶身份與角色等因素發(fā)生變化，用戶對安全策略的要求也在隨時發(fā)生變化，需要對安全策略進(jìn)行動態(tài)調(diào)整。如前文所述，以往的研究在這一階段束手無策，只能針對新的安全需求重新生成安全策略實例并將其重新注入應(yīng)用程序中，然后將新的應(yīng)用程序安裝至用戶的設(shè)備中。這種操作方式對安全策略的使用是災(zāi)難性的，考慮到個人或組織時常變動的安全需求，這種反復(fù)地重新編譯與打包所帶來的時間成本和操作成本是無法容忍的。這也是之前的研究和設(shè)計難以投入使用的根本原因。本系統(tǒng)在初次進(jìn)行字節(jié)碼注入時就會通過靜態(tài)分析手段尋找應(yīng)用程序中的所有敏感數(shù)據(jù)訪問請求和危險權(quán)限操作，并在所有相關(guān)的API 調(diào)用位置前后都嵌入策略執(zhí)行器。這就意味著只要安全決策中心給出特定的控制指令，所有敏感API 調(diào)用都能夠被本系統(tǒng)限制或直接屏蔽。這種動態(tài)控制的實現(xiàn)直接依賴于Dalvik 虛擬機(jī)環(huán)境和Java 語言的反射特性。反射機(jī)制利用了虛擬機(jī)執(zhí)行語言的自省能力，能夠在程序運(yùn)行時以數(shù)據(jù)流的方式提供對代碼邏輯的控制。更具體地，基于Dalvik虛擬機(jī)的反射技術(shù)允許在程序運(yùn)行時動態(tài)加載和使用類，并通過字符串形式的控制信息調(diào)整對方法、字段、類和接口的調(diào)用方式。反射技術(shù)可以將程序的以上邏輯單元變量化和參數(shù)化，使方法、類和接口可以作為參數(shù)傳輸。因此，只需預(yù)先定義所有可能的控制代碼，應(yīng)用程序在運(yùn)行時就可以根據(jù)安全策略選取匹配的方法或接口。

為了幫助用戶調(diào)整安全策略并向應(yīng)用程序推送調(diào)整后的安全策略，本系統(tǒng)在安全決策中心中添加了網(wǎng)絡(luò)通信模塊，該網(wǎng)絡(luò)通信模塊能夠以HTTP通信的形式向服務(wù)器請求安全策略，服務(wù)器也能夠以WebSocket 的方式向所有注入了安全策略的應(yīng)用程序推送新的安全策略，使所有程序都能夠保持和最新安全策略的同步，如圖3 所示。

圖3 安全決策中心與服務(wù)器通信

4 實驗評估與分析

為了對本文所提Android 應(yīng)用程序隱私保護(hù)系統(tǒng)進(jìn)行測試和評估，本節(jié)從國內(nèi)各大應(yīng)用市場中隨機(jī)采集了一些應(yīng)用程序，并以此為載體對系統(tǒng)進(jìn)行了詳細(xì)的分析。評估主要考察的是注入安全策略后應(yīng)用程序的可用性和穩(wěn)健性，以及注入的安全策略對應(yīng)用程序所產(chǎn)生的性能方面的影響。

4.1 數(shù)據(jù)源分布特性

為了保證數(shù)據(jù)集的隨機(jī)性和普適性，本節(jié)選取了市場份額較高的4 家應(yīng)用市場：騰訊應(yīng)用寶、360 手機(jī)助手、華為應(yīng)用市場、小米應(yīng)用商店。從這4 家應(yīng)用市場中采用隨機(jī)方式分別爬取了60 個應(yīng)用程序，將這些應(yīng)用程序中的重復(fù)項去除后得到了129 個應(yīng)用程序。需要強(qiáng)調(diào)的是，爬蟲在采集應(yīng)用程序時并未對應(yīng)用程序做任何限定或要求，而是采用完全隨機(jī)的方式進(jìn)行爬取。這也意味著實驗中并沒有對應(yīng)用程序的類型、下載量、大小等性質(zhì)做出假設(shè)，這是為了保證數(shù)據(jù)集的隨機(jī)性和普適性。

來自不同應(yīng)用市場的應(yīng)用程序數(shù)量如圖4 所示。需要說明的是，本文在去除重復(fù)應(yīng)用時以應(yīng)用商店的市場份額作為優(yōu)先級，即以來自騰訊應(yīng)用寶中應(yīng)用程序集合為基礎(chǔ)，并去除從其他3 家應(yīng)用市場中爬取的應(yīng)用程序集合中的重復(fù)項。然后，對360手機(jī)助手中獲取的應(yīng)用程序進(jìn)行類似操作，刪除剩余2 家應(yīng)用市場中相對應(yīng)的重復(fù)項，依次類推。因此，圖4 中應(yīng)用市場所提供的應(yīng)用程序數(shù)量是依次減少的。數(shù)據(jù)源中應(yīng)用程序的類型分布如圖5 所示。從圖5 可以看到，本文采集的應(yīng)用程序中，游戲與娛樂類程序占比最高，為30.23%；網(wǎng)絡(luò)購物與金融、影視與音樂、生活方式類程序占比也較高，分別為16.28%、12.41%和10.85%。上述統(tǒng)計結(jié)果與日常生活中的直觀體驗相符，說明本文采集的應(yīng)用程序集合基本符合日常生活中應(yīng)用程序的分布情況。

圖4 各應(yīng)用市場對數(shù)據(jù)源的貢獻(xiàn)

圖5 數(shù)據(jù)源中應(yīng)用程序的類型分布

4.2 安全策略的生成與注入

根據(jù)用戶和組織的不同需求，針對特定的應(yīng)用場景和安全需求生成相應(yīng)的安全策略，系統(tǒng)需要首先通過對用戶指定的Android 應(yīng)用程序進(jìn)行靜態(tài)分析，獲取該應(yīng)用程序涉及的所有敏感API 調(diào)用和危險權(quán)限請求；然后將獲取到的信息轉(zhuǎn)化成策略點，通過對策略點的操作，決定是否同意應(yīng)用程序的危險請求以及更細(xì)粒度的API 調(diào)用。除了特定Android應(yīng)用程序所涉及的具體調(diào)用或權(quán)限申請，本系統(tǒng)還要考慮用戶自身的環(huán)境與需求。例如，在一些保密工作場景和會議過程中，不允許應(yīng)用程序擁有隨時訪問麥克風(fēng)的權(quán)限；在家庭場景中面對可能的來電需求，則需要允許特定的應(yīng)用程序擁有訪問麥克風(fēng)的基本權(quán)限。

以應(yīng)用程序訪問設(shè)備定位信息為例，這一行為對應(yīng)著多種具有API 調(diào)用以及應(yīng)用程序要求在位置改變時執(zhí)行回調(diào)，或者要求操作系統(tǒng)返回設(shè)備的最后位置，或者以一定時間間隔輪詢定位傳感器等。則對應(yīng)的安全策略可以描述為

其中，策略由是否獲取系統(tǒng)服務(wù)權(quán)限（GSS,get system service）、是否允許獲取位置更新權(quán)限（RLU，request location updates）、是否獲取最后的位置信息（GLKL,get last known location）組成；每個權(quán)限的回答存在以下3 種可能，Permit 表示一直允許，F(xiàn)orbid 表示一直禁止，DelaySetting 表示一定時間間隔刷新權(quán)限。不同權(quán)限的不同值構(gòu)成不同的安全策略。將抽象的安全策略進(jìn)行實例化，生成一個包含安全方法的字節(jié)碼安全運(yùn)行庫。針對具體的應(yīng)用程序，對其APK 安裝包進(jìn)行解包，獲取DEX 格式文件、Manifest 文件以及各種靜態(tài)資源，如圖像和顏色配置等。將實例化后的安全策略嵌入DEX 文件中，使用ApkTool 對應(yīng)用程序進(jìn)行沖編譯和打包。因為只有簽名的應(yīng)用程序安裝包才能通過Android操作系統(tǒng)的檢測并成功安裝到用戶設(shè)備中，所以需要使用signAPK 對得到新的APK 文件進(jìn)行簽名。

4.3 安全策略的穩(wěn)健性

穩(wěn)健性是指在對應(yīng)用程序進(jìn)行修改和重新打包后，應(yīng)用程序能否正常運(yùn)行。對于安全策略的穩(wěn)健性，本文從2 個維度進(jìn)行評價：一個維度是本文系統(tǒng)執(zhí)行特定安全策略對應(yīng)用程序正常運(yùn)行的影響；另一個維度是對于不同的操作系統(tǒng)版本和不同的硬件平臺，注入了安全策略的應(yīng)用程序能否正常工作。

圖6(a)展示了當(dāng)運(yùn)行環(huán)境限制在同一操作系統(tǒng)和同一硬件環(huán)境時，本系統(tǒng)對Android 應(yīng)用程序穩(wěn)健性的影響。本實驗使用搭載Android 10 系統(tǒng)的華為P30 Pro 手機(jī)對數(shù)據(jù)集合中的所有應(yīng)用程序進(jìn)行了測試。由圖6(a)的數(shù)據(jù)可以看出，在限制了軟硬件環(huán)境的情況下，85.27%的應(yīng)用程序基本能夠正常運(yùn)行，其中大部分應(yīng)用程序能夠保持長時間的正常運(yùn)行，20.16%的應(yīng)用程序在執(zhí)行特定安全策略時偶有閃退情況發(fā)生；8.53% 的應(yīng)用程序發(fā)生了無法打開或者正常功能受到影響的情況；6.2%的應(yīng)用程序在嵌入安全策略字節(jié)碼后的重編譯過程中發(fā)生異常而導(dǎo)致無法重打包。

圖6 穩(wěn)健性測試結(jié)果

圖6(b)展示了不同軟硬件條件下安全策略對應(yīng)用程序穩(wěn)健性的影響。除了圖6(a)實驗中所使用的搭載Android 10 系統(tǒng)的華為P30 Pro 手機(jī)，本實驗還使用了搭載Android 10 系統(tǒng)的小米MI 9 手機(jī)、搭載Android 9 的華為 Mate 20 手機(jī)，以及搭載Android 9 系統(tǒng)的小米Redmi K20 Pro 手機(jī)。實驗結(jié)果表明，本系統(tǒng)在不同的軟硬件環(huán)境下并未表現(xiàn)出太大的差別。這在一定程度上體現(xiàn)了本系統(tǒng)對應(yīng)用程序穩(wěn)健性的影響不大。

4.4 字節(jié)碼注入前后應(yīng)用程序性能對比

對于手機(jī)應(yīng)用程序來說，另一重要的評估是字節(jié)碼的注入對應(yīng)用程序性能的影響。在實驗仿真中，性能考慮的是注入字節(jié)碼對應(yīng)用程序啟動時間、大?。此純?nèi)存）以及功耗的影響。

圖7 反映了本系統(tǒng)注入的安全策略對Android應(yīng)用程序啟動時間的影響。實驗結(jié)果表明，盡管不同應(yīng)用程序的啟動時間分布廣泛，但注入安全策略對啟動時間的影響與應(yīng)用程序原始的啟動時間并無明顯關(guān)聯(lián)。對于原始啟動時間小于1 s 的應(yīng)用程序，安全策略對啟動時間的平均影響約為0.411 s，實驗數(shù)據(jù)的標(biāo)準(zhǔn)差為0.080 4 s；對于原始啟動時間大于5 s 的大型應(yīng)用，安全策略的平均影響僅為0.635 s，標(biāo)準(zhǔn)差僅為0.069 9 s。盡管如此，需要特別注意的是，對于那些原始啟動時間較短的應(yīng)用程序來說，注入安全策略所造成的用戶直觀影響更大。因為在這種情況下安全策略帶來的開銷所占的比例更高，而這種對比會使用戶明顯感覺到程序變慢。事實上，注入的安全策略并非在程序啟動同時被立即調(diào)用，而是在程序執(zhí)行到特定位置或進(jìn)行敏感操作時才會被調(diào)用。因此，理論上程序啟動時會對啟動時間產(chǎn)生額外開銷的只是安全決策中心的初始化過程，而這個過程本身對程序資源的消耗相對程序自身的初始化過程所產(chǎn)生的開銷要小得多。實驗的結(jié)果符合理論分析。

圖7 安全策略對應(yīng)用啟動時間的影響

圖8 展示了注入了安全策略前后應(yīng)用程序大小的變化。從實驗結(jié)果可以很直觀地看到，注入安全策略對應(yīng)用程序的大小帶來的影響相比于應(yīng)用程序原始大小幾乎可以忽略不計。對于原始體積小于10 MB 的應(yīng)用程序，注入安全策略所帶來的平均體積影響僅為246.13 KB；對于原始體積大于200 MB的大型應(yīng)用，注入安全策略所帶來的平均體積影響也僅為1 296.95 KB。但是需要說明的是，安全策略對應(yīng)用程序大小的影響和應(yīng)用程序原始大小呈現(xiàn)出明顯的正相關(guān)。

圖8 安全策略對應(yīng)用大小的影響

從圖8 可以看到，盡管不同應(yīng)用程序本身的大小分布廣泛，但是安全策略注入所帶來的空間開銷占重打包后應(yīng)用程序總大小的比例始終保持在一定范圍內(nèi)。換言之，隨著應(yīng)用程序規(guī)模的增大，注入的安全策略字節(jié)碼規(guī)模也增多了。從理論上分析，注入的字節(jié)碼可分為2 個部分，即安全決策中心和各個策略執(zhí)行代理。安全決策中心的大小一般是相對固定的，策略執(zhí)行代理與具體的應(yīng)用程序有關(guān)。更具體地，當(dāng)應(yīng)用程序中涉及更多的敏感操作和權(quán)限調(diào)用時，所需的策略執(zhí)行器就相對更多。因此，與其說安全策略帶來的空間開銷和應(yīng)用程序原始體積有關(guān)，不如說是和應(yīng)用程序中包含的敏感操作和權(quán)限調(diào)用數(shù)量有關(guān)。

對于安全策略對應(yīng)用程序功耗的影響，本文以數(shù)據(jù)源中2 個常用應(yīng)用程序為基礎(chǔ)進(jìn)行了詳細(xì)測試。用一臺搭載Android 10 系統(tǒng)的華為P30 Pro 手機(jī)進(jìn)行相關(guān)操作。在每次測試開始之前，將手機(jī)充電至80%，隨后要求受試者使用手機(jī)打開注入了安全策略的特定應(yīng)用程序，并依照程序的正常功能連續(xù)使用60 min。在使用的第5 min、第10 min、第20 min、第30 min、第45 min 和第60 min 分別記錄此時手機(jī)的剩余電量，并依照記錄數(shù)據(jù)繪制功耗曲線。為了和原始情況進(jìn)行對比，對于每個應(yīng)用程序，受試者按照上述流程使用未經(jīng)安全策略注入的原始程序，在使用應(yīng)用程序過程中分別同時運(yùn)行市場上現(xiàn)有的安全類App（Bitdefender 和Avria）進(jìn)行用電量損耗對比，2 個應(yīng)用程序都能夠提供權(quán)限的監(jiān)控。每個應(yīng)用程序在不同的條件下重復(fù)實驗4 次。圖9 揭示了這2 組實驗的實驗結(jié)果。從實驗數(shù)據(jù)可以看出，本系統(tǒng)所注入的安全策略對應(yīng)用程序所產(chǎn)生的功耗影響較小，在長達(dá)60 min 的使用過程中最多給功耗造成2%的差距?，F(xiàn)有的市場上的安全類應(yīng)用程序的功耗有8%的差距，這從說明了本系統(tǒng)對應(yīng)用程序的性能并不會產(chǎn)生用戶可感知級別的影響。需要說明的是，由于實驗過程中沒有對更多的應(yīng)用程序進(jìn)行功耗測試，因此本部分所進(jìn)行的測試只能部分反映本系統(tǒng)對功耗的影響，更全面的分析仍然需要依賴對更多應(yīng)用程序進(jìn)行的測試。

圖9 不同方法對應(yīng)用功耗的影響

5 結(jié)束語

Android 系統(tǒng)提供了基于權(quán)限控制的安全機(jī)制，但是該機(jī)制的粗粒度控制方式不能滿足相當(dāng)一部分用戶或組織的安全需求，而且存在可以被惡意攻擊者利用的系統(tǒng)性漏洞。為了防止應(yīng)用程序濫用危險權(quán)限和用戶敏感信息，本文設(shè)計并實現(xiàn)了基于字節(jié)碼注入的Android 應(yīng)用程序隱私防護(hù)系統(tǒng)。該系統(tǒng)的安全策略注入機(jī)制利用了基于虛擬字節(jié)碼的安全策略生成與注入技術(shù)，該技術(shù)能夠在Android 應(yīng)用程序中植入對危險權(quán)限和敏感API 調(diào)用的控制策略，并根據(jù)用戶或組織的需求進(jìn)行動態(tài)的調(diào)整。在大多數(shù)情況，安全策略的注入不會對應(yīng)用程序的可用性造成影響，并在此基礎(chǔ)上可對85.33% 的敏感API 調(diào)用和危險權(quán)限請求進(jìn)行有效限制。