摘 要： 智能手機(jī)用戶的隱私泄露問題日趨嚴(yán)重。為此研究了Android的系統(tǒng)框架及安全機(jī)制，包括沙盒、應(yīng)用簽名、權(quán)限機(jī)制。著重研究了Android系統(tǒng)中間件層的安全增強(qiáng)方法，列舉了系統(tǒng)易受攻擊的種類，總結(jié)了現(xiàn)有的隱私保護(hù)技術(shù)，包括應(yīng)用程序安裝時(shí)權(quán)限機(jī)制的擴(kuò)展，運(yùn)行時(shí)的動(dòng)態(tài)權(quán)限監(jiān)測(cè)以及隱私數(shù)據(jù)的保護(hù)。

關(guān)鍵詞： Android系統(tǒng)； 隱私泄露； 安全機(jī)制； 隱私保護(hù)

中圖分類號(hào)：TP309.1 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1006-8228（2013）12-07-05

Survey of privacy protection techniques based on Android

Bao Tongtong， Zhang Kun， Chen Xuan， Gao Fei

（College of Computer Science and Engineering in Nanjing University of Science and Technology， Nanjing， Jiangsu 210094， China）

Abstract： In recent years， the problem of privacy leak of the smart phone users is getting worse and worse. For this， the system framework of Android and its security mechanisms are introduced， including the sandboxing， application signing， and permission mechanism. Security enhancement in the Android system’s middleware layer is researched. The types of system that is vulnerable are listed and the existing privacy protection techniques are summed up， including the extension of permissions mechanism during the installation process of an application， run-time monitoring of the dynamic permissions and the protection of privacy data.

Key words： Android system； privacy leak； security mechanisms； privacy protection

0 引言

智能手機(jī)得到廣泛使用以來，Android系統(tǒng)就備受用戶和開發(fā)者的喜愛，一是因?yàn)槠溆蟹N類繁多的應(yīng)用程序支持，二是因?yàn)槠溟_放式系統(tǒng)的開發(fā)門檻低。然而也正是低開發(fā)門檻使得Android系統(tǒng)的應(yīng)用程序良莠不齊，其中不乏一些惡意應(yīng)用程序。

網(wǎng)秦發(fā)布的《2013上半年全球手機(jī)安全報(bào)告》[1]顯示：2013年上半年查殺到的手機(jī)惡意軟件共51084款，同比2012年上半年增長189%。其中，Android平臺(tái)仍是惡意軟件感染的重點(diǎn)平臺(tái)，感染比例為95%。隱私竊取類病毒也呈上升趨勢(shì)，占總比的19%。針對(duì)層出不窮的病毒，Android本身提供了沙盒、權(quán)限、應(yīng)用簽名等安全機(jī)制，但這類粗粒度的安全機(jī)制仍存在諸多漏洞，尤其是容易遭到應(yīng)用層權(quán)限提升攻擊[2]。

為了提高Android系統(tǒng)的可用性，近幾年針對(duì)其安全機(jī)制的研究逐步深入，并已取得一些成果。本文在研究Android系統(tǒng)框架，組件模型及其原生安全機(jī)制基礎(chǔ)上，著重研究Android中間件層的隱私保護(hù)技術(shù)，按照應(yīng)用程序安裝時(shí)權(quán)限機(jī)制的擴(kuò)展，運(yùn)行時(shí)動(dòng)態(tài)權(quán)限監(jiān)測(cè)，以及隱私數(shù)據(jù)保護(hù)的順序?qū)ζ溥M(jìn)行歸納與總結(jié)。

1 Android系統(tǒng)架構(gòu)及安全機(jī)制

1.1 系統(tǒng)框架

Android是基于Linux內(nèi)核的操作系統(tǒng)，大致可分為四個(gè)主要層面，自底向上分別為硬件層，Linux內(nèi)核層，中間件層和應(yīng)用程序?qū)?。這四層結(jié)構(gòu)還可細(xì)分為五部分，如圖1所示。

圖1 Android系統(tǒng)框架圖

Linux內(nèi)核——這部分是Android系統(tǒng)的基礎(chǔ)核心，包括了各種硬件組件的所有設(shè)備驅(qū)動(dòng)程序。

庫——提供Android操作系統(tǒng)主要功能的全部代碼。例如，SQLite庫提供了支持應(yīng)用進(jìn)行數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫。

Android運(yùn)行環(huán)境——與庫同處一個(gè)層面，包括了Dalvik虛擬機(jī)和一組核心庫。其中，核心庫可使開發(fā)人員用Java語言來編寫Android程序，Dalvik虛擬機(jī)則使得每個(gè)應(yīng)用程序都在自己的進(jìn)程中運(yùn)行。

應(yīng)用框架層——是向開發(fā)人員公開Android操作系統(tǒng)各種功能的層面，使他們可以在應(yīng)用程序中調(diào)用這些功能。

應(yīng)用程序?qū)印@一層有Android設(shè)備自帶的許多應(yīng)用，例如電話、聯(lián)系人、瀏覽器等，以及可以從Android應(yīng)用程序商店下載安裝的任何應(yīng)用。通常Android應(yīng)用由Activity，Service， Broadcast Receiver及Content Provider組成。其中，Activity負(fù)責(zé)用戶接口，Service實(shí)現(xiàn)后臺(tái)進(jìn)程功能，Broadcast Receiver負(fù)責(zé)接收來自系統(tǒng)的廣播通知，Content Provider主要負(fù)責(zé)管理應(yīng)用間的數(shù)據(jù)分享。

1.2 Android應(yīng)用間的通信機(jī)制

Android應(yīng)用間通信通常是通過中間件層提供的標(biāo)準(zhǔn)機(jī)制完成的，即基于Binder的輕量型進(jìn)程間通信（Inter-Process Communication，IPC）。IPC根據(jù)應(yīng)用組件的顆粒度粗細(xì)以不同形式發(fā)生，由此產(chǎn)生的應(yīng)用間通信通常被稱為組件間通信（Inter-Component Communication，ICC），用來在內(nèi)核層與IPC區(qū)別開來。創(chuàng)建一個(gè)ICC通道，應(yīng)用組件需發(fā)送一個(gè)特殊的消息——Intent消息。Intent消息包含了兩個(gè)重要內(nèi)容，一是消息目的地，二是消息所攜帶的數(shù)據(jù)內(nèi)容。除了ICC，應(yīng)用還能繞過中間件層通過其他管道進(jìn)行通信，但由基層的Linux內(nèi)核控制。比如，可以通過Linux的標(biāo)準(zhǔn)IPC機(jī)制來建立通信（如Unix sockets）或通過Internet sockets通信。

1.3 Android安全機(jī)制

1.3.1 沙盒

Android基層的Linux內(nèi)核執(zhí)行進(jìn)程隔離以及對(duì)用戶資源的自主型訪問控制，應(yīng)用層的沙盒模式則是一種將設(shè)備上的應(yīng)用彼此隔離，以及和系統(tǒng)資源隔離的安全機(jī)制。應(yīng)用間的彼此隔離是通過給每個(gè)應(yīng)用分配一個(gè)惟一的用戶ID（UID）來實(shí)現(xiàn)的。同時(shí)，系統(tǒng)資源歸system用戶或root用戶所有，應(yīng)用程序只能獲取自己的文件或明確定義為全局可讀的文件。

1.3.2 應(yīng)用簽名

Android實(shí)行的應(yīng)用簽名機(jī)制只是開發(fā)人員給應(yīng)用代碼加上自認(rèn)證密鑰，因此并不能抵御惡意軟件，但卻可以在同一個(gè)開發(fā)者開發(fā)的多個(gè)應(yīng)用程序間建立信任關(guān)系。簽名密鑰相同的應(yīng)用可以共享UID，會(huì)被放入同一沙盒內(nèi)。

1.3.3 權(quán)限機(jī)制

Android系統(tǒng)中，細(xì)粒度的安全特征是通過權(quán)限機(jī)制來實(shí)現(xiàn)的。權(quán)限機(jī)制由中間件層來提供。安全敏感的接口通過標(biāo)準(zhǔn)權(quán)限控制來保護(hù)，例如PHONE_CALLS，INTERNET等權(quán)限。這意味著應(yīng)用必須先具有這些權(quán)限才能發(fā)起通話、訪問網(wǎng)絡(luò)等。應(yīng)用默認(rèn)是不具備任何權(quán)限的。當(dāng)它想要訪問數(shù)據(jù)或使用資源時(shí)，必須在自身的AndroidManifest.xml文件中聲明所具有的權(quán)限。這些權(quán)限將會(huì)在用戶安裝該程序時(shí)呈現(xiàn)給用戶，如果被用戶拒絕則不能完成安裝。

Android系統(tǒng)中的權(quán)限分為四個(gè)保護(hù)級(jí)別：“normal”、“dangerous”、“signature”和“signatureOrSystem”。其中，“normal”是默認(rèn)級(jí)別，即最低級(jí)別，一般自動(dòng)授予應(yīng)用程序該不會(huì)造成太大危害的權(quán)限?！癲angerous”級(jí)別比“normal”級(jí)別要高一等級(jí)，可能會(huì)賦予應(yīng)用程序訪問敏感數(shù)據(jù)或控制設(shè)備等功能，一般所指的需要聲明權(quán)限就是該級(jí)別權(quán)限?！癲angerous”級(jí)別的權(quán)限必須聲明且在安裝時(shí)通過用戶認(rèn)證才能夠被應(yīng)用程序使用。“signature”和“signatureOrSystem”級(jí)別的權(quán)限一般只被原始設(shè)備制造商所使用。

2 研究現(xiàn)狀

如1.3節(jié)中介紹，Android自身雖然已提供了幾項(xiàng)安全機(jī)制，但在受到不同類型的攻擊時(shí)，依然顯露出許多問題和漏洞。比較常見的攻擊是權(quán)限提升攻擊[2]，進(jìn)一步還可細(xì)分為混淆代理攻擊[2]和共謀攻擊[2]等。針對(duì)這類問題，已有的研究主要集中在以下三個(gè)方面。

2.1 安裝時(shí)權(quán)限機(jī)制擴(kuò)展

安裝時(shí)權(quán)限機(jī)制的擴(kuò)展主要針對(duì)的是安裝應(yīng)用時(shí)的授權(quán)機(jī)制，目的是使用戶在只授予應(yīng)用部分權(quán)限的情況下也能安裝程序并使用其部分功能，而非一旦拒絕就無法正常安裝程序，或可以根據(jù)用戶自身情況（如時(shí)間、地理位置等）動(dòng)態(tài)地授予或撤銷部分權(quán)限，從而增強(qiáng)用戶對(duì)權(quán)限授予的可控性。

William Enck等人提出的Kirin[3]服務(wù)主要針對(duì)應(yīng)用程序的配置文件AndroidManifest.xml進(jìn)行分析。他們實(shí)施了以下五個(gè)步驟：第一步，識(shí)別資源；第二步，識(shí)別資源的功能性需求；第三步，確定資源的安全目標(biāo)與威脅；第四步，擴(kuò)展資源安全需求；第五步，確定將要實(shí)施的安全機(jī)制本身的局限性所在。

其中步驟4和步驟5需多次迭代，并將某些安全規(guī)則逐漸的細(xì)化，由此逐漸總結(jié)出了Kirin安全規(guī)則，詳見表1。

從表1中我們可以看出，在Kirin的安全服務(wù)規(guī)則中有出現(xiàn)對(duì)單個(gè)權(quán)限的限制，也出現(xiàn)對(duì)兩個(gè)或三個(gè)權(quán)限的限制以及權(quán)限和接口組合的限制。總結(jié)出安全規(guī)則后，就可以根據(jù)上述規(guī)則對(duì)應(yīng)用程序進(jìn)行評(píng)估和分析。圖2是加入Kirin后的應(yīng)用程序的安裝過程。

圖2 加入Kirin后的應(yīng)用安裝過程

安全應(yīng)用程序交互設(shè)施（Secure Application INTeraction， Saint）[4]是由Machigar Ongtang等人提出的一種改進(jìn)的基礎(chǔ)設(shè)施，用來管理安裝時(shí)間內(nèi)的權(quán)限分配以及運(yùn)行時(shí)的用法。它分析了三種基礎(chǔ)應(yīng)用策略：權(quán)限分配策略、接口曝光策略和接口運(yùn)用策略，這三種策略在Android安全框架中不可用。Saint針對(duì)這些應(yīng)用需求策略，進(jìn)行了如下改進(jìn)：允許聲明權(quán)限P的應(yīng)用根據(jù)應(yīng)用簽名、配置等條件，依據(jù)開發(fā)者定義的安全策略，對(duì)應(yīng)用的接口實(shí)施保護(hù)，從而抵抗“混淆代理人攻擊”。

圖3為Saint的框架圖。其中，Saint的安裝時(shí)間策略規(guī)定了應(yīng)用權(quán)限的授予。具體為：一個(gè)聲明P權(quán)限的應(yīng)用定義了在何種情形下權(quán)限P會(huì)被授予給其他的應(yīng)用；運(yùn)行時(shí)的策略執(zhí)行則規(guī)定了軟件組件和中間件框架交互的方式；管理策略指示了策略本身可以如何改變；操作策略負(fù)責(zé)在應(yīng)用程序出錯(cuò)時(shí)進(jìn)行檢查。其結(jié)果，Saint策略通過基于運(yùn)行狀態(tài)的限制訪問超越了Android系統(tǒng)上現(xiàn)有的靜態(tài)權(quán)限檢查。

圖3 Saint框架圖

Mohammad Nauman等在2010年提出了Apex[5]，即一個(gè)Android的策略實(shí)施框架，通過對(duì)包管理器的修改，使用戶可有選擇性地給應(yīng)用授予權(quán)限并限制資源的運(yùn)用。實(shí)施過程中，用戶可以先授予部分權(quán)限并拒絕其他訪問權(quán)限，這使得用戶可以使用應(yīng)用的部分功能同時(shí)限制了對(duì)某些重要或代價(jià)高的資源的訪問。其次，用戶可根據(jù)特定的時(shí)間、地點(diǎn)等授予或撤銷應(yīng)用申請(qǐng)的權(quán)限。Apex還在安裝界面加入了“有條件允許”按鈕以實(shí)現(xiàn)上文所述的部分授予應(yīng)用權(quán)限的功能。

2.2 運(yùn)行時(shí)權(quán)限動(dòng)態(tài)權(quán)限

如1.2節(jié)所述，Android應(yīng)用間使用ICC機(jī)制通過封裝成Intent消息來調(diào)用和交互數(shù)據(jù)。Intent消息會(huì)被傳送給Context.startActivity（）、Context.startService（）等方法。這些方法都是通過ApplicationContext類實(shí)現(xiàn)的，它將控制信息傳遞給Activity-ManagerService類，然后UID和訪問組件要求的權(quán)限作為checkComponentPermission（）的參數(shù)，這個(gè)過程就是基于權(quán)限的強(qiáng)制訪問控制機(jī)制。而Android系統(tǒng)尤其容易受權(quán)限提升攻擊并且對(duì)上下文不敏感，這些問題都容易造成系統(tǒng)漏洞從而導(dǎo)致用戶隱私信息的泄露。

2.2.1 防止權(quán)限提升攻擊方面的研究

在防止權(quán)限提升攻擊方面，Sven Bugiel等提出了Android擴(kuò)展監(jiān)測(cè)安全框架（eXtended Monitoring on Android， XManDroid）[2]，XManDroid拓展了Android的監(jiān)測(cè)機(jī)制，通過系統(tǒng)策略監(jiān)測(cè)來檢查和預(yù)防應(yīng)用級(jí)的權(quán)限提升攻擊。該框架擴(kuò)展了Android的應(yīng)用框架，由三個(gè)模塊組成：①運(yùn)行環(huán)境監(jiān)控器；②應(yīng)用安裝程序；③系統(tǒng)決策安裝程序。圖4為XManDroid框架圖，其中灰色部分是XmanDroid修改或創(chuàng)建的新部分。

圖4 XManDroid框架圖

運(yùn)行環(huán)境監(jiān)測(cè)器提供了XManDroid的核心功能。應(yīng)用安裝程序加強(qiáng)了標(biāo)準(zhǔn)Android應(yīng)用程序安裝過程的安全性，主要負(fù)責(zé)應(yīng)用程序的安裝和卸載。系統(tǒng)決策安裝程序提供了將系統(tǒng)策略安裝在Android中間件的機(jī)制，包括PolicyInstaller， SystemPolicy，Decisions和SystemView四個(gè)組件。由于系統(tǒng)決策決定了框架能否成功檢測(cè)惡意軟件，為了讓XManDroid框架的策略粒度更細(xì)，不同于以往基于權(quán)限的方法，它能夠檢查ICC傳送的數(shù)據(jù)并做出基于Intents消息內(nèi)容的決策。

由Adrienne Porter Felt等提出的IPC Inspection機(jī)制[6]，是一種新的操作系統(tǒng)機(jī)制，用來防止受到“權(quán)限再授權(quán)”（permission re-deligation）的威脅。IPC Inspection將被調(diào)用者的有效權(quán)限減少為調(diào)用與被調(diào)用者權(quán)限的交集。觸發(fā)減少權(quán)限行為的事件有：啟動(dòng)服務(wù)，綁定服務(wù)，收到廣播的Intent等。IPC檢查分為三個(gè)步驟：首先，必須持有一份每個(gè)應(yīng)用程序當(dāng)前權(quán)限的列表；其次，在系統(tǒng)應(yīng)用間的通信機(jī)制里執(zhí)行權(quán)限降低的策略，啟動(dòng)一個(gè)應(yīng)用并發(fā)送一個(gè)明確的IPC消息；最后，允許接收方的應(yīng)用程序接收或拒絕消息。應(yīng)用程序可通過接收請(qǐng)求方的列表來限制它們從何處接收消息。

智能手機(jī)應(yīng)用通常都擁有訪問網(wǎng)絡(luò)及本地敏感資源的權(quán)限。這使得遠(yuǎn)程終端很難在用戶設(shè)備的網(wǎng)絡(luò)起源處建立信任。針對(duì)該問題，由Michael Dietz等人研究提出的Quire[7]則在Android系統(tǒng)中建立了兩個(gè)新的安全機(jī)制。其一，Quire追蹤設(shè)備中IPC的調(diào)用鏈。該做法給予應(yīng)用程序兩種選擇，一是執(zhí)行比調(diào)用者少的權(quán)限，二是代表自身執(zhí)行全部權(quán)限。其二，輕量級(jí)簽名方案使得任何應(yīng)用可以創(chuàng)建一個(gè)簽名語句，使得在同一手機(jī)上的任何應(yīng)用都通過驗(yàn)證。

2.2.2 感知上下文方面的研究

由Mauro Conti等人提出的Android系統(tǒng)基于上下文的策略執(zhí)行系統(tǒng)（Context-Related Policy Enforcement for Android，CRePE）[8]是一個(gè)實(shí)施細(xì)粒度策略的系統(tǒng)，策略可以在應(yīng)用運(yùn)行時(shí)依賴于手機(jī)的上下文。上下文可以根據(jù)某些變量的狀態(tài)（例如位置、時(shí)間、溫度等），其他設(shè)備的存在或用戶與設(shè)備的特殊交互與結(jié)合等來定義。另外，CRePE允許用戶或受信第三方來定義上下文相關(guān)策略。

CRePE的基本思想是將策略執(zhí)行插入到Android權(quán)限檢查之前。被截取的權(quán)限請(qǐng)求要經(jīng)過CRePE架構(gòu)中六個(gè)組件的處理：CRePE權(quán)限檢查器，策略管理器，策略提供商，用戶交互器，上下文交互器和行動(dòng)執(zhí)行器。當(dāng)一個(gè)應(yīng)用程序向另一個(gè)程序發(fā)出請(qǐng)求或應(yīng)用了一個(gè)系統(tǒng)服務(wù)時(shí)，這個(gè)請(qǐng)求就會(huì)被CRePE的權(quán)限檢查器截下。該組件會(huì)與策略管理器交互來檢查權(quán)限是否被現(xiàn)有策略所允許。策略管理器是惟一有權(quán)限訪問策略提供商的組件。若該請(qǐng)求與這些策略不符，調(diào)用者的請(qǐng)求將被駁回；若相符，則該請(qǐng)求會(huì)被繼續(xù)傳遞給Android權(quán)限檢查組模塊。用戶可以與CRePE交互來創(chuàng)建、更新或刪除上下文策略。完成交互工作的是前文提到的用戶交互器，這是一個(gè)Android自身的應(yīng)用程序，當(dāng)一個(gè)用戶創(chuàng)建、刪除或修改上下文信息時(shí)，用戶交互器需要獲得信息并存儲(chǔ)在策略管理器內(nèi)，策略管理器則在必要時(shí)更新該上下文信息。上下文交互器作用是當(dāng)上下文狀態(tài)變?yōu)橛行Щ驘o效時(shí)通知CRePE的組件。最后，CRePE的行動(dòng)執(zhí)行器是處理運(yùn)行時(shí)有效策略改變的組件。

2.3 隱私數(shù)據(jù)動(dòng)態(tài)保護(hù)

在平臺(tái)安全增強(qiáng)工作上，還有些研究將重點(diǎn)放在數(shù)據(jù)本身。包括敏感數(shù)據(jù)偽造及動(dòng)態(tài)數(shù)據(jù)流追蹤。

2.3.1 敏感數(shù)據(jù)偽造

在敏感數(shù)據(jù)偽造方面，由Yajin Zhou等人開發(fā)的Android環(huán)境下抑制智能手機(jī)應(yīng)用程序盜取信息的系統(tǒng)（Taming Information-Stealing Smartphone Applications on Android， TISSA）[9]在Android上實(shí)現(xiàn)了隱私模式，可以賦予用戶以細(xì)粒度的方式靈活控制哪些個(gè)人隱私信息可以由應(yīng)用獲得；而且，訪問方法在運(yùn)行過程中可以動(dòng)態(tài)地調(diào)整，以適應(yīng)用戶在不同場景下的需求，并根據(jù)對(duì)應(yīng)用程序的隱私設(shè)置來提供匿名、信任或虛假數(shù)據(jù)。

圖5是TISSA的架構(gòu)圖，TISSA共由三個(gè)組件組成。

圖5 TISSA架構(gòu)圖

第一個(gè)組件是隱私設(shè)置內(nèi)容提供者，這是一個(gè)有權(quán)限組件，用來處理不受信應(yīng)用的隱私設(shè)置問題。同時(shí)，它提供向已安裝應(yīng)用查詢現(xiàn)有隱私設(shè)置的功能。如果我們將TISSA看成是一個(gè)參考監(jiān)測(cè)器，那么這部分組件就是一個(gè)策略決策點(diǎn)。

第二個(gè)組件是隱私設(shè)置管理者。這是一個(gè)有權(quán)限的應(yīng)用程序，被用戶用來管理或升級(jí)已安裝應(yīng)用的隱私設(shè)置。在TISSA中它充當(dāng)策略管理點(diǎn)的角色。

第三個(gè)組件是一個(gè)有隱私意識(shí)的組件，該組件需要與第一個(gè)組件相互合作，一旦當(dāng)它收到一個(gè)應(yīng)用程序企圖訪問隱私數(shù)據(jù)的請(qǐng)求時(shí)，它會(huì)咨詢隱私設(shè)置并作出回應(yīng)。它扮演了TISSA中的策略執(zhí)行點(diǎn)的角色。

另外，由Alastair R. Beresford等設(shè)計(jì)的MockDroid[10]系統(tǒng)則可以實(shí)現(xiàn)虛假位置信息、空的電話簿、虛假設(shè)備ID等功能以掩蓋真實(shí)敏感數(shù)據(jù)信息。

2.3.2 動(dòng)態(tài)數(shù)據(jù)流跟蹤

由William Enck提出的TaintDroid[11]是一個(gè)有效的動(dòng)態(tài)污點(diǎn)追蹤和分析的系統(tǒng)，其主要目的是檢測(cè)隱私數(shù)據(jù)是否通過不可信應(yīng)用程序的通道離開系統(tǒng)。TaintDroid自動(dòng)為來自敏感數(shù)據(jù)源的數(shù)據(jù)打上污點(diǎn)標(biāo)記，在敏感數(shù)據(jù)通過程序變量、文件及進(jìn)程間消息傳播時(shí)為其維護(hù)污點(diǎn)標(biāo)記。當(dāng)污點(diǎn)數(shù)據(jù)通過網(wǎng)絡(luò)或其他途徑試圖離開系統(tǒng)時(shí)，TaintDroid的日志會(huì)記錄數(shù)據(jù)標(biāo)記，傳輸敏感數(shù)據(jù)的應(yīng)用程序以及數(shù)據(jù)的目的地。

TaintDroid在Android原有的架構(gòu)基礎(chǔ)上進(jìn)行修改，實(shí)現(xiàn)了四種粒度的著色追蹤，分別為：變量級(jí)別、方法級(jí)別、消息級(jí)別和文件級(jí)別。圖6展示了TaintDroid在系統(tǒng)中如何實(shí)現(xiàn)多層次追蹤。

圖6 TaintDroid多層次追蹤的系統(tǒng)架構(gòu)圖

首先，利用虛擬機(jī)解釋器向不受信應(yīng)用程序代碼提供變量級(jí)別的追蹤，通過解釋器提供的變量語義可得到程序的上下文，從而避免了著色爆炸現(xiàn)象[11]；同時(shí)，變量級(jí)別的跟蹤可實(shí)現(xiàn)只對(duì)數(shù)據(jù)而非代碼進(jìn)行著色。然后，在應(yīng)用程序之間采取消息級(jí)別的追蹤，只追蹤消息而非數(shù)據(jù)，可減少進(jìn)程間通信開銷。緊接著，對(duì)于系統(tǒng)提供的本地庫，TaintDroid采取了方法級(jí)別的追蹤。最后，通過文件級(jí)別的追蹤確保相關(guān)信息能夠持續(xù)保持它的著色標(biāo)記。

圖7是TaintDroid框架圖。

圖7 TaintDroid框架圖

如圖7所示，根據(jù)充足的上下文資源，可信應(yīng)用程序的信息先被著色（1）。被著色的接口則調(diào)用一個(gè)Dalvik虛擬機(jī)解釋器接口的本地方法（2），該解釋器在虛擬著色地圖里存儲(chǔ)著具體的著色標(biāo)記。Dalvik虛擬機(jī)根據(jù)數(shù)據(jù)流規(guī)則傳播著色標(biāo)簽（3）。每一個(gè)解釋器實(shí)例都同時(shí)傳播著色標(biāo)簽。當(dāng)受信應(yīng)用程序在IPC通信機(jī)制中動(dòng)用了已著色信息時(shí)，改進(jìn)后的Binder庫則確保該數(shù)據(jù)包含有一個(gè)著色標(biāo)簽（4），且這個(gè)標(biāo)簽映射著所有被包含數(shù)據(jù)的聯(lián)合著色標(biāo)記。數(shù)據(jù)包在Binder內(nèi)核中透明地傳送且被遠(yuǎn)程不受信應(yīng)用程序接收（5）。值得注意的是只有被解析的代碼是不受信的。改進(jìn)后的Binder庫從數(shù)據(jù)包中檢索出著色標(biāo)簽且將它賦給所有從中讀出的值（6）。遠(yuǎn)程的Dalvik虛擬機(jī)以相同的方式在不受信應(yīng)用程序上進(jìn)行著色傳播（7）。當(dāng)不受信應(yīng)用程序調(diào)用一個(gè)已被標(biāo)記為泄露點(diǎn)的特定庫函數(shù)時(shí)（8），庫函數(shù)就會(huì)檢索對(duì)應(yīng)的著色標(biāo)記并生成一個(gè)針對(duì)該事件的報(bào)告（9）。

3 結(jié)束語

移動(dòng)設(shè)備用戶隱私泄露問題突出，包括用戶極多的Android系統(tǒng)。針對(duì)此方面的研究逐漸成熟。本文介紹了現(xiàn)有的Android系統(tǒng)中間件層的安全增強(qiáng)研究成果，從應(yīng)用程序安裝時(shí)權(quán)限機(jī)制的擴(kuò)展、運(yùn)行時(shí)的動(dòng)態(tài)權(quán)限監(jiān)測(cè)和隱私數(shù)據(jù)保護(hù)三個(gè)方面層層展開，詳述了各個(gè)安全框架、安全模型，以及進(jìn)行安全擴(kuò)展后系統(tǒng)的運(yùn)作方式與流程。

但是現(xiàn)有的研究成果仍存在諸多不足，如安全策略間的兼容性差，依賴用戶完成的授權(quán)機(jī)制使策略安全性降低，移動(dòng)設(shè)備資源受限的特點(diǎn)使得安全策略只能使用粗粒度的控制方法來降低系統(tǒng)損耗等。針對(duì)這些問題，今后的工作將著重于以下幾個(gè)方面：①構(gòu)建統(tǒng)一的安全增強(qiáng)框架；②為系統(tǒng)引入智能決策引擎，將決策權(quán)交給系統(tǒng)；③在對(duì)系統(tǒng)可用性影響盡可能小的前提下，進(jìn)一步細(xì)化策略控制粒度。

參考文獻(xiàn)：

[1] 北京網(wǎng)秦天下有限公司.2013上半年全球手機(jī)安全報(bào)告[Z].北京網(wǎng)

秦天下有限公司，2013.

[2] Bugiel， Sven， et al. \"Xmandroid： A new android evolution to mitigate

privilege escalation attacks.\" Technische Universit?t Darmstadt， Technical Report TR-2011-04 （2011）.

[3] Enck， William， Machigar Ongtang， and Patrick McDaniel. \"On

lightweight mobile phone application certification.\" Proceedings of the 16th ACM conference on Computer and communications security. ACM，2009：235-245

[4] Ongtang， Machigar， et al. \"Semantically rich application-centric

security in Android.\" Security and Communication Networks 5.6（2012）：658-673

[5] Nauman， Mohammad， Sohail Khan， and Xinwen Zhang. \"Apex：

extending android permission model and enforcement with user-defined runtime constraints.\" Proceedings of the 5th ACM Symposium on Information， Computer and Communications Security. ACM，2010：328-332

[6] Felt， Adrienne Porter， et al. \"Permission Re-Delegation： Attacks

and Defenses.\" USENIX Security Symposium，2011.

[7] Dietz， Michael， et al. \"QUIRE： Lightweight Provenance for Smart

Phone Operating Systems.\" USENIX Security Symposium，2011.

[8] Conti， Mauro， Vu Thien Nga Nguyen， and Bruno Crispo. \"CRePE：

Context-related policy enforcement for Android.\" Information Security. Springer Berlin Heidelberg，2011：331-345

[9] Zhou， Yajin， et al. \"Taming information-stealing smartphone

applications （on android）.\" Trust and Trustworthy Computing. Springer Berlin Heidelberg，2011：93-107

[10] Beresford， Alastair R.， et al. \"MockDroid： trading privacy for

application functionality on smartphones.\" Proceedings of the 12th workshop on mobile computing systems and applications. ACM，2011：49-54

[11] Enck， William， et al. \"TaintDroid： An Information-Flow Tracking

System for Realtime Privacy Monitoring on Smartphones.\" OSDI，2010.10.