基于虛擬機字節(jié)碼注入的Android 應用程序隱私保護機制

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

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

1 引言

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

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

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

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

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

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

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

2 相關工作

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

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

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

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

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

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

3 基于字節(jié)碼注入的應用隱私保護機制

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

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

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

3.1 安全策略的生成

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

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

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

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

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

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

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

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

代碼1

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

1) 安全策略的實例化

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

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

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

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

代碼2

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

代碼3

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

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

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

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

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

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

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

圖3 安全決策中心與服務器通信

4 實驗評估與分析

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

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

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

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

圖4 各應用市場對數(shù)據(jù)源的貢獻

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

4.2 安全策略的生成與注入

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

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

其中，策略由是否獲取系統(tǒng)服務權(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)成不同的安全策略。將抽象的安全策略進行實例化，生成一個包含安全方法的字節(jié)碼安全運行庫。針對具體的應用程序，對其APK 安裝包進行解包，獲取DEX 格式文件、Manifest 文件以及各種靜態(tài)資源，如圖像和顏色配置等。將實例化后的安全策略嵌入DEX 文件中，使用ApkTool 對應用程序進行沖編譯和打包。因為只有簽名的應用程序安裝包才能通過Android操作系統(tǒng)的檢測并成功安裝到用戶設備中，所以需要使用signAPK 對得到新的APK 文件進行簽名。

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

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

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

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

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

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

對于手機應用程序來說，另一重要的評估是字節(jié)碼的注入對應用程序性能的影響。在實驗仿真中，性能考慮的是注入字節(jié)碼對應用程序啟動時間、大小（即所占內(nèi)存）以及功耗的影響。

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

圖7 安全策略對應用啟動時間的影響

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

圖8 安全策略對應用大小的影響

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

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

圖9 不同方法對應用功耗的影響

5 結(jié)束語

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