基于差分隱私的Android物理傳感器側(cè)信道防御方法

唐奔宵 王麗娜 汪 潤 趙 磊 王丹磊

(空天信息安全與可信計(jì)算教育部重點(diǎn)實(shí)驗(yàn)室(武漢大學(xué)) 武漢 430072) (武漢大學(xué)國家網(wǎng)絡(luò)安全學(xué)院 武漢 430072) (tangbenxiao@whu.edu.cn)

物理傳感器已經(jīng)成為智能手機(jī)中不可缺少的輔助硬件之一，傳感器的應(yīng)用為智能手機(jī)用戶提供了更加豐富的功能.然而，用戶在使用移動設(shè)備的過程中產(chǎn)生的行為特征可被物理傳感器采集，并被利用于構(gòu)建側(cè)信道進(jìn)行隱私泄露攻擊[1]，攻擊者可以輕易地對用戶進(jìn)行追蹤[2-3]或者竊取設(shè)備密碼[4-5].近年來，移動設(shè)備的普及率持續(xù)增長，根據(jù)媒體市場研究公司Zenith的最新研究顯示，全球智能手機(jī)的普及率在2017年已經(jīng)達(dá)到63%，其中Android系統(tǒng)市場占有率為86.1%[6]，越來越多的用戶暴露在隱私泄露的風(fēng)險(xiǎn)當(dāng)中.

傳感器隱私保護(hù)方面的研究已經(jīng)具有一定積累[7-8]，但是針對以傳感器作為媒介的隱私泄露攻擊缺乏有效的防御機(jī)制.首先，Android系統(tǒng)中物理傳感器默認(rèn)為低風(fēng)險(xiǎn)數(shù)據(jù)源，應(yīng)用程序不需要任何申明即可直接訪問傳感器，因此基于敏感權(quán)限的惡意行為檢測方案[9-11]難以適用于傳感器側(cè)信道攻擊.其次，傳感器側(cè)信道攻擊方法在不斷改進(jìn)，尤其是結(jié)合了共謀攻擊的新型側(cè)信道[12]讓傳統(tǒng)檢測方案捉襟見肘.已有的傳感器側(cè)信道防御方案中，最直接的方法是降低傳感器的采樣頻率，甚至禁止APP訪問傳感器[13-14]，然而，由于難以區(qū)分?jǐn)?shù)據(jù)訪問的惡意性，通過限制傳感器性能的解決方案會嚴(yán)重影響APP的正常運(yùn)行.隨后，更加靈活的訪問控制機(jī)制被提出[15-16]，但是訪問控制無法防御偽裝成合法APP的惡意攻擊.鍵盤隨機(jī)化機(jī)制[17]可以破壞傳感器數(shù)據(jù)與用戶輸入行為之間的映射關(guān)系，但對于以追蹤為目的的側(cè)信道攻擊毫無辦法，此外，修改用戶已經(jīng)非常熟悉的鍵盤布局對于用戶體驗(yàn)而言也十分不友好.文獻(xiàn)[18]提出，通過嗅探程序向用戶敏感操作時(shí)產(chǎn)生的傳感器數(shù)據(jù)中注入大量噪聲破壞傳感器數(shù)據(jù)可用性，進(jìn)而實(shí)現(xiàn)對側(cè)信道的防御.然而，注入行為本身破壞了Android的沙盒機(jī)制，容易被攻擊者利用，防御程序也無法有效地識別用戶何時(shí)進(jìn)行敏感操作.

通過對已知傳感器側(cè)信道的研究，我們發(fā)現(xiàn)傳感器側(cè)信道對于傳感器數(shù)據(jù)精度的要求遠(yuǎn)高于正常應(yīng)用程序中傳感器相關(guān)功能的數(shù)據(jù)精度要求，換句話說，傳感器側(cè)信道與正常應(yīng)用對于傳感器數(shù)據(jù)中噪聲的魯棒性具有明顯差異.基于上述發(fā)現(xiàn)，本文提出了一種基于差分隱私的傳感器側(cè)信道攻擊防御方案，通過在傳感器原始數(shù)據(jù)的數(shù)值與響應(yīng)時(shí)間中注入隨機(jī)噪聲，從根本上降低傳感器側(cè)信道攻擊(包括共謀攻擊)的成功率.由于實(shí)施于Android應(yīng)用框架層，本文防御方案能夠?qū)τ脩敉耆该?，不需要用戶參與防御決策.

防御過程中面臨2個(gè)困難：1)如何混淆傳感器原始數(shù)據(jù)能夠有效地干擾側(cè)信道攻擊；2)如何保證APP正常功能以及用戶體驗(yàn)不受到數(shù)據(jù)混淆的影響.針對第1個(gè)問題，本文基于差分隱私技術(shù)，利用Laplace機(jī)制向傳感器的原始數(shù)據(jù)中注入少量噪聲，通過干擾側(cè)信道學(xué)習(xí)過程，降低側(cè)信道攻擊成功率.為克服第2個(gè)問題，本文對各類APP能夠承受的數(shù)據(jù)混淆程度進(jìn)行詳細(xì)分析.首先基于FlowDroid[19]與SOOT[20]框架，設(shè)計(jì)并實(shí)現(xiàn)了針對Android物理傳感功能的抽取工具SensorTainter，并對Google Play上47 144個(gè)APP進(jìn)行傳感器相關(guān)的功能抽取、分析與分類.最后，通過詳細(xì)的實(shí)驗(yàn)論證各種類型功能對于傳感器數(shù)據(jù)混淆的承受上限，結(jié)合用戶體驗(yàn)實(shí)驗(yàn)與側(cè)信道防御效果給出合理的傳感器數(shù)據(jù)混淆范圍建議.

本文具體貢獻(xiàn)有3個(gè)方面：

1) 針對Android物理傳感器側(cè)信道防御不足的問題，提出了一種基于差分隱私的傳感器原始數(shù)據(jù)混淆的防御框架.該防御框架實(shí)施于Android應(yīng)用框架層，具有良好的擴(kuò)展性，能夠在對用戶完全透明的情況下有效降低因傳感器API管控不嚴(yán)而產(chǎn)生的敏感信息泄露風(fēng)險(xiǎn).

2) 設(shè)計(jì)實(shí)現(xiàn)了Android傳感器參與功能分析工具SensorTainter，該工具基于FlowDroid靜態(tài)污點(diǎn)分析思想，能夠快速、精確地抽取出APP中傳感器參與的程序片段.除物理傳感器以外，該工具還可以用于其他低敏感API的功能分析.

3) 通過對Google Play中47 144個(gè)APP進(jìn)行功能分析，并針對9種典型物理傳感器側(cè)信道進(jìn)行防御測試，權(quán)衡用戶體驗(yàn)、功能完整性與防御能力，給出具體的傳感器數(shù)據(jù)混淆的建議范圍.

1 系統(tǒng)框架

定義應(yīng)用程序按照預(yù)期設(shè)定進(jìn)行工作的能力稱之為功能完整性.應(yīng)用程序的功能完整性依賴于算法的魯棒性，其決定了該算法對于輸入數(shù)據(jù)攜帶噪聲的敏感程度，有些功能能夠承受較大程度噪聲干擾，有些則不然.如果將物理傳感器側(cè)信道看作是基于Android傳感器實(shí)現(xiàn)功能中的一類，那么，挖掘側(cè)信道攻擊功能完整性與正常應(yīng)用程序功能完整性之間對于傳感器數(shù)據(jù)的魯棒性差異，即可從根本上降低傳感器側(cè)信道攻擊的威脅.本文根據(jù)上述思想提出了Android物理傳感器安全防御方案，具體結(jié)構(gòu)如圖1所示：

Fig. 1 Structure of Android physical sensor side-channel defensive method圖1 Android物理傳感器防御方法結(jié)構(gòu)

本節(jié)將從防御方法的構(gòu)建與實(shí)施2個(gè)方面進(jìn)行介紹.

構(gòu)建過程中，首先分析市面上已有APP物理傳感器使用情況，抽取傳感器相關(guān)功能的程序片段.下一步，根據(jù)功能類型以及功能的具體算法進(jìn)行可擴(kuò)展的功能分類.基于差分隱私[21]的思想，我們在傳感器原始數(shù)據(jù)中注入特定噪聲進(jìn)行數(shù)據(jù)混淆，并通過實(shí)驗(yàn)分析各類正常功能以及物理傳感器側(cè)信道攻擊對于數(shù)據(jù)混淆的承受能力.為部署傳感器攻擊防御框架，廠商需要在最新的系統(tǒng)版本中加入本文設(shè)計(jì)的傳感器數(shù)據(jù)混淆模塊，傳感器數(shù)據(jù)混淆模塊能夠根據(jù)當(dāng)前運(yùn)行的APP中數(shù)據(jù)混淆標(biāo)識進(jìn)行不同程度的數(shù)據(jù)混淆.具體細(xì)節(jié)在第4節(jié)中說明.

應(yīng)用超市需在APP上市之前加入傳感器功能分析流程，將功能類別所對應(yīng)的數(shù)據(jù)混淆標(biāo)識(數(shù)據(jù)混淆程度)加入APP描述中，傳感器相關(guān)功能對應(yīng)的數(shù)據(jù)混淆建議范圍在第5節(jié)中說明.若該APP的傳感器相關(guān)功能在防御系統(tǒng)中沒有記錄，則將結(jié)果反饋，應(yīng)用管理方單獨(dú)對新功能重新進(jìn)行數(shù)據(jù)混淆分析，并更新功能類別與對應(yīng)數(shù)據(jù)混淆方案.具有數(shù)據(jù)混淆程度標(biāo)識的APP運(yùn)行時(shí)，系統(tǒng)將會根據(jù)標(biāo)識在應(yīng)用框架層截?cái)鄠鞲衅髟紨?shù)據(jù)進(jìn)行對應(yīng)程度的混淆.

在本文防御方案中，用戶始終沒有參與安全決策，減少了由用戶自身安全意識普遍較低而導(dǎo)致的額外風(fēng)險(xiǎn).此外，數(shù)據(jù)混淆不會影響APP的正常工作，保證用戶體驗(yàn)沒有受到影響.從攻擊者的角度，由于獲取到的傳感器數(shù)據(jù)樣本中加入了干擾噪聲，通過不可信樣本構(gòu)建的側(cè)信道攻擊成功率隨之下降，使得用戶隱私得到保障.

實(shí)施物理傳感器側(cè)信道防御方法時(shí)，最關(guān)鍵的2個(gè)步驟為APP相關(guān)功能分析與傳感器原始數(shù)據(jù)混淆.

1.1 Android物理傳感器相關(guān)功能分析

無論在構(gòu)建過程還是實(shí)施過程中，APP傳感器相關(guān)功能分析都是最核心的步驟之一.為抽取APP傳感器相關(guān)功能程序片段，本文基于FlowDroid靜態(tài)污染分析思想，結(jié)合程序切片方法[22-23]，實(shí)現(xiàn)了SensorTainter工具.SensorTainter將傳感器API調(diào)用看作污染源(source)，通過追蹤污染源SensorEvent在程序中的數(shù)據(jù)流動以及污染傳播，挖掘出與傳感器數(shù)據(jù)存在關(guān)聯(lián)的語句，進(jìn)而實(shí)現(xiàn)相關(guān)功能的抽取.SensorTainter核心算法與傳播規(guī)則將在第2節(jié)中描述.

根據(jù)我們的調(diào)研，目前為止并沒有研究對APP傳感器API使用情況進(jìn)行系統(tǒng)性分析.通過SensorTainter對47 144個(gè)APP掃描，發(fā)現(xiàn)其中6 408個(gè)APP調(diào)用了物理傳感器API.我們對上述6 408個(gè)APP進(jìn)行詳細(xì)的功能分析.首先依據(jù)APP所實(shí)現(xiàn)的功能類型進(jìn)行分類，由于相同的功能之間可能存在調(diào)用傳感器種類與算法的差異，相同功能類別中將根據(jù)具體算法以及傳感器類別分類.物理傳感器功能的分析結(jié)果將作為該APP數(shù)據(jù)混淆承受能力分析的參考依據(jù)，詳細(xì)的實(shí)現(xiàn)過程和功能分析結(jié)果在第4節(jié)討論.

1.2 數(shù)據(jù)混淆

通過總結(jié)近年來物理傳感器側(cè)信道領(lǐng)域的研究[24]得出，側(cè)信道主要利用用戶行為習(xí)慣與傳感器數(shù)據(jù)之間的映射關(guān)系實(shí)施隱私泄露，已有研究[25-26]證明通過數(shù)據(jù)混淆的方式干擾映射關(guān)系能夠降低隱私泄露的風(fēng)險(xiǎn).本文基于差分隱私方法，通過注入隨機(jī)噪聲的方式對傳感器的數(shù)值和響應(yīng)時(shí)間進(jìn)行數(shù)據(jù)混淆.實(shí)現(xiàn)過程中，考慮到Android傳感器API為回調(diào)機(jī)制，我們在Android應(yīng)用框架層嵌入數(shù)據(jù)緩存，每當(dāng)對底層傳感器輪詢訪問時(shí)，向?qū)嶋H傳感器讀數(shù)加入適當(dāng)噪聲.

數(shù)據(jù)混淆的程度由APP相關(guān)功能的承受能力以及對側(cè)信道攻擊的干擾預(yù)期共同決定.第4～6節(jié)中將詳細(xì)討論數(shù)據(jù)混淆方法.

2 Android傳感器相關(guān)功能抽取

APP中傳感器數(shù)據(jù)的使用情況可以通過分析傳感器數(shù)據(jù)參與的語句獲取，我們將Android傳感器相關(guān)功能抽取近似地看作靜態(tài)污點(diǎn)分析：傳感器訪問API被認(rèn)為是污染源，傳感器數(shù)據(jù)參與功能實(shí)現(xiàn)的過程則看作污染對象的流動與傳播.但在細(xì)節(jié)上，傳感器相關(guān)功能抽取又與傳統(tǒng)的靜態(tài)污點(diǎn)分析存在差異，例如進(jìn)行功能抽取時(shí)不需要考慮路徑上是否存在出口，兩者的傳播規(guī)則也不盡相同.

2.1 傳感器功能抽取流程與算法設(shè)計(jì)

Android應(yīng)用層中物理傳感器API包含了請求和處理來自設(shè)備硬件信息的對象，API的入口點(diǎn)是SensorManager類，APP通過SensorManager注冊準(zhǔn)備使用的傳感器后，傳感器數(shù)據(jù)將會以Sensor-Event的形式發(fā)送到監(jiān)聽類SensorEventListener中，監(jiān)聽類通過回調(diào)函數(shù)onSensorChanged接收更新的傳感器數(shù)據(jù).在進(jìn)行程序切片時(shí)，該回調(diào)函數(shù)的SensorEvent對象被認(rèn)為是傳感器信息源.SensorTainter進(jìn)行傳感器數(shù)據(jù)參與功能的程序抽取過程中，首先對apk文件進(jìn)行解壓縮，搜索項(xiàng)目中的manifest等配置文件，然后反編譯dex文件，轉(zhuǎn)換成Jimple格式[19]的中間件文件，并構(gòu)建生命周期模型，在回調(diào)函數(shù)onSensorChanged處生成虛擬的入口函數(shù).下一步，通過soot與hero[27]構(gòu)建函數(shù)調(diào)用圖與內(nèi)部控制流圖.同時(shí)對源碼進(jìn)行掃描，尋找可能包含傳感器類型的語句，例如帶有字段sensor.getType的語句.最后，從虛擬主函數(shù)進(jìn)入，根據(jù)傳感器數(shù)據(jù)的流向與傳播規(guī)則構(gòu)建功能參與集，并將所有參與的語句進(jìn)行輸出作為功能描述.

SensorTainter中APP生命周期建模[28]中的虛擬入口函數(shù)構(gòu)建基于FlowDroid.傳感器相關(guān)功能抽取時(shí)不考慮組件之間的異步操作，以及除自身以外的回調(diào)函數(shù).附錄A是對真實(shí)應(yīng)用程序“不倒翁游戲”的抽取實(shí)例.

SensorTainter的分析過程分為向前功能參與分析(簡稱向前分析)與向后別名分析(簡稱向后分析)兩部分，具體算法可參考文獻(xiàn)[19].向前分析負(fù)責(zé)傳感器數(shù)據(jù)在向前流動的過程中，“污染”其他對象的關(guān)聯(lián)傳播，關(guān)聯(lián)傳播定義了對象之間的“污染”傳遞.定義x.f表示對象x中的字段f，傳播規(guī)則將在本節(jié)末尾描述.

向后分析負(fù)責(zé)新“污染”對象的別名查找.當(dāng)與傳感器數(shù)據(jù)相關(guān)聯(lián)的變量被賦值給其他局部變量時(shí)，就會產(chǎn)生向后的別名分析，尋找具有相同引用的對象.若存在別名且發(fā)起別名分析的對象與傳感器數(shù)據(jù)存在關(guān)聯(lián)關(guān)系，則以別名對象處為起點(diǎn)生成1次新的向前分析，如果別名對象僅參與了算數(shù)的操作，則只記錄當(dāng)前狀態(tài).例如對于語句x=y+z，y是與傳感器對象存在數(shù)據(jù)關(guān)聯(lián)的變量，z是一個(gè)常量，則只有變量x與傳感器數(shù)據(jù)產(chǎn)生關(guān)聯(lián).

圖2中展示了1次SensorTainter分析過程：

圖2中的實(shí)線(灰色)代表向前參與分析，虛線(藍(lán)色)代表向后別名分析，標(biāo)號代表分析步驟.

步驟①當(dāng)設(shè)備的運(yùn)動狀態(tài)發(fā)生改變時(shí)，傳感器回調(diào)函數(shù)被觸發(fā)，變量a獲得當(dāng)前傳感器讀數(shù)；

步驟②～③函數(shù)calculate被調(diào)用，變量a作為參數(shù)傳入函數(shù)體內(nèi)，完成實(shí)參a與形參s的映射；

步驟④～⑤變量x產(chǎn)生對s的引用，繼續(xù)向前追蹤變量x、s的數(shù)據(jù)流動；

步驟⑥對x進(jìn)行向后別名分析，發(fā)現(xiàn)x與變量t引用同一個(gè)對象；

步驟⑦由t處產(chǎn)生新的向前數(shù)據(jù)流分析，發(fā)現(xiàn)t中對傳感器數(shù)據(jù)的引用參與了變量rs的計(jì)算；

步驟⑧繼續(xù)向前分析由變量t出發(fā)的數(shù)據(jù)流.

SensorTainter需要考慮被分析語句的上下文信息，考慮圖3中場景：

當(dāng)數(shù)據(jù)流之間出現(xiàn)交匯時(shí)，可能會影響“污染”的傳播.圖3中函數(shù)calculate的傳感器對象Sensor-Event被變量d引用后進(jìn)行了加法操作，然而，并非每一次調(diào)用calculate函數(shù)都會被看作有傳感器數(shù)據(jù)的參與：圖3中行②對calculate的調(diào)用會產(chǎn)生傳感器相關(guān)數(shù)據(jù)流，然而行③SensorEvent對象被重新創(chuàng)建，因此行④處的函數(shù)調(diào)用將不與傳感器數(shù)據(jù)產(chǎn)生關(guān)聯(lián).SensorTainter為每一條數(shù)據(jù)流分支創(chuàng)建單獨(dú)的隊(duì)列存儲上下文信息.

2.2 SensorTainter傳播規(guī)則定義

SensorTainter將APP中的語句分為4類：一般語句、函數(shù)調(diào)用語句、函數(shù)返回語句與其他語句，4種語句對應(yīng)獨(dú)立的參與傳播規(guī)則.為了更精確表示對象中的字段信息，通過x.fm表示變量x中字段深度為m的訪問路徑.

2.2.1 向前分析傳播規(guī)則

1) 一般語句.SensorTainter僅對傳感器數(shù)據(jù)進(jìn)行追蹤，因此只有1個(gè)數(shù)據(jù)源sensor，普通的節(jié)點(diǎn)不能憑空產(chǎn)生傳感器數(shù)據(jù)，只能被賦值(=)或者清除(new).對于一個(gè)賦值語句x.fn=y.fm，轉(zhuǎn)移函數(shù)按照規(guī)則：

(1)

其中,O表示參與集.對于普通節(jié)點(diǎn)的賦值語句，如果y.fm下有任何字段的來源于傳感器數(shù)據(jù)有關(guān)，則把引用的x.fn下的相應(yīng)訪問路徑加入?yún)⑴c集O中；如果y.fm下不包含任何與傳感器數(shù)據(jù)相關(guān)的字段，而且x.fn也不在參與功能的數(shù)組之中，則將x.fn從O中去除；其他情況保持不變.需要額外說明右邊是算數(shù)表達(dá)式的情況x.fn=y.fm(op)z.fk：

(2)

其中,op表示算數(shù)運(yùn)算符.右邊算數(shù)表達(dá)式中只要存在1個(gè)以上的變量與傳感器數(shù)據(jù)之間存在關(guān)聯(lián)，則左邊的變量被認(rèn)為直接參與功能實(shí)現(xiàn)，右邊其他的操作數(shù)被認(rèn)為間接參與相關(guān)功能實(shí)現(xiàn)，并加入間接參與集Oi中.間接參與節(jié)點(diǎn)不會產(chǎn)生新的向前參與分析，但會進(jìn)行向后別名分析.

另一種特殊情況為x.fn=newy.fm：

(3)

由于Java中new操作會將被賦值的對象重新初始化，因此不再認(rèn)為該對象后續(xù)參與傳感器相關(guān)的功能實(shí)現(xiàn).

2) 函數(shù)調(diào)用語句.調(diào)用代表了函數(shù)調(diào)用對象對于被調(diào)用對象函數(shù)體內(nèi)部的影響，即通過函數(shù)調(diào)用事件進(jìn)入到函數(shù)體內(nèi)部，設(shè)函數(shù)調(diào)用的形式為c.m(a0,a1,…,an)，其中c表示對象實(shí)例，m是對象包含的函數(shù)名，a為函數(shù)實(shí)參參數(shù)，函數(shù)調(diào)用流的處理規(guī)則可以表示為

(4)

其中，Ocaller是函數(shù)調(diào)用語句中被調(diào)用對象的參與集合，Ocallee是被調(diào)用函數(shù)的實(shí)際函數(shù)體的參與集合，s為當(dāng)前函數(shù)調(diào)用語句，p是對應(yīng)的形參.如果被調(diào)用函數(shù)所在的對象中有成員參與了功能，則在被調(diào)用函數(shù)的實(shí)際函數(shù)體中標(biāo)記為參與關(guān)系；如果函數(shù)調(diào)用中的實(shí)參參與了功能，則將被調(diào)用函數(shù)中對應(yīng)形參加入Ocallee；如果一個(gè)調(diào)用對象中的全局變量參與了功能實(shí)現(xiàn)，且這個(gè)全局變量也出現(xiàn)在了被調(diào)用函數(shù)體中，則將其加入到Ocallee中.

3) 函數(shù)返回語句.函數(shù)返回代表了被調(diào)用的函數(shù)體對于調(diào)用者的影響，即函數(shù)體內(nèi)部處理結(jié)束后向外界返回的數(shù)據(jù)流.函數(shù)體內(nèi)參與數(shù)據(jù)之間的傳遞并不一定會影響到函數(shù)調(diào)用者，需要判斷最后的返回值是否有與傳感器數(shù)據(jù)有關(guān).對于函數(shù)調(diào)用b=c.m(a0,a1,…,an)，函數(shù)返回流的傳遞規(guī)則為

(5)

如果被調(diào)用函數(shù)存在參與字段，則將該路徑加入Ocaller中；如果被Ocallee中形參存在參與字段，則調(diào)用返回后所對應(yīng)的實(shí)參也存在對應(yīng)參與字段，需要注意的是如果參與路徑是基礎(chǔ)類型，則必須是數(shù)值類型；如果被調(diào)用函數(shù)體中有x.fq參與功能實(shí)現(xiàn)，且與其對應(yīng)的y.fq是靜態(tài)全局變量，則y.fq需要加入Ocaller中；如果被調(diào)用函數(shù)體的返回值參與了，則函數(shù)調(diào)用的結(jié)果接收對象b.fv也將被認(rèn)為參與了功能實(shí)現(xiàn).

4) 其他語句.對于函數(shù)調(diào)用b=c.m(a0,a1,…,an)，其他語句傳遞規(guī)則用于處理原生函數(shù)調(diào)用以及原始傳感器數(shù)據(jù)源：

(6)

當(dāng)前語句s是原生函數(shù)調(diào)用時(shí)，如果實(shí)參中包含有Ocaller中的變量，則將其加入Ocaller中.在本文分析的結(jié)果中，并沒有發(fā)現(xiàn)使用原生函數(shù)參與傳感器數(shù)據(jù)相關(guān)功能的應(yīng)用，因?yàn)榻^大部分原生函數(shù)可以做到的功能都有更好的替代方法，但是考慮到切片程序的完整性與原生函數(shù)參與的可能性，還是加入了對原生函數(shù)的處理；如果函數(shù)調(diào)用是傳感器API調(diào)用，則創(chuàng)建新的參與集用于記錄新的傳感器數(shù)據(jù)流；其他情況下不改變現(xiàn)有狀態(tài).

參與集中記錄的只是參與傳感器數(shù)據(jù)利用的對象，每當(dāng)參與集發(fā)生變化時(shí)需要將當(dāng)前包含新增參與對象的語句s加入當(dāng)前函數(shù)體的抽取集合PS中：

(7)

每當(dāng)進(jìn)入新的函數(shù)體都將生產(chǎn)獨(dú)立的程序抽取集合.參與集發(fā)生變化時(shí)，如果當(dāng)前節(jié)點(diǎn)處的語句不屬于函數(shù)體內(nèi)的程序抽取集合，且語句s包含參與集中的對象或者函數(shù)調(diào)用，則將s加入當(dāng)前程序抽取集.

向前參與流分析中數(shù)據(jù)流的起點(diǎn)如果是某個(gè)參與對象x.fm的別名y.fn，只有該數(shù)據(jù)流第1次通過了x.fm與傳感器數(shù)據(jù)關(guān)聯(lián)的語句時(shí)，y.fn才會被認(rèn)為是參與了傳感器數(shù)據(jù)的使用.

2.2.2 向后分析傳播規(guī)則

向后別名分析傳播規(guī)則中，同樣分為4種語句關(guān)聯(lián)轉(zhuǎn)移情況.

1) 一般語句.對于語句x.f=y.g，一般語句的轉(zhuǎn)移規(guī)則可以表示為

(8)

向后別名分析的本質(zhì)上與向前參與分析規(guī)則類似，只是方向發(fā)生了轉(zhuǎn)變.如果x.f.fp是存在于別名集A中的已經(jīng)記錄的別名字段，則y.g.fp是x.f.fp的新別名，因此從當(dāng)前別名集中去掉x.f.fp，并添加y.g.fp.

對于new語句x.f=new*，別名集中關(guān)于變量x的所有引用的別名信息都需要被除去：

(9)

2) 函數(shù)調(diào)用語句.向后分析與向前分析中，函數(shù)調(diào)用語句的傳遞方向正好相反，對于函數(shù)調(diào)用，參與傳播從函數(shù)調(diào)用語句的調(diào)用方向返回方進(jìn)行，對于函數(shù)調(diào)用b=c.m(a0,a1,…,an)：

(10)

若調(diào)用端b.fm是當(dāng)前追蹤變量的別名，則在caller的函數(shù)體中返回值也應(yīng)該是其別名；若callee的對象實(shí)例是當(dāng)前追蹤變量的別名，則callee中的對應(yīng)成員對象也是被追蹤變量x.fm的別名；若某個(gè)全局對象是當(dāng)前追蹤變量的別名，則該全局對象在callee中的對應(yīng)對象也應(yīng)是x.fm的別名.

3) 函數(shù)返回語句.因?yàn)閿?shù)據(jù)流是從callee函數(shù)體的起始位置向調(diào)用方流動，所以返回流將callee內(nèi)的別名映射到調(diào)用方的別名集中，參數(shù)則由形參向?qū)崊⒎较蛄鲃樱?/p>

(11)

如果在當(dāng)前函數(shù)體內(nèi)的成員對象在方法內(nèi)部是對應(yīng)別名，則被調(diào)用對象的對應(yīng)成員變量是調(diào)用方的別名；如果被調(diào)用函數(shù)的形參是被追蹤對象的別名，則函數(shù)調(diào)用過程中所對應(yīng)的實(shí)參同樣是該對象的別名；如果被調(diào)用函數(shù)體中的某個(gè)全局靜態(tài)對象是被追蹤對象的別名，則這個(gè)靜態(tài)對象在調(diào)用方也應(yīng)該是別名.

4) 其他語句.對于語句b=c.m(a0,a1,…,an)，其他類型數(shù)據(jù)流轉(zhuǎn)移規(guī)則用于處理由原生調(diào)用產(chǎn)生的別名或者清除由b引用的別名：

(12)

若當(dāng)前語句為原生函數(shù)調(diào)用，且滿足2個(gè)條件之一：實(shí)參中存在對象是當(dāng)前被追蹤對象的別名，或者callee中相同深度的引用路徑是被追蹤對象的別名，則將被s調(diào)用的原生函數(shù)所創(chuàng)建的別名加入當(dāng)前追蹤的別名集合中；由于函數(shù)調(diào)用語句s會將b的引用更新，所以若調(diào)用函數(shù)的接收對象b.fn已經(jīng)存在于別名集合中，則該語句處對象b對應(yīng)字段將不再是當(dāng)前被追蹤對象的別名；其他情況下不改變別名集合A.

向后別名分析中，程序抽取集合不會記錄產(chǎn)生別名的語句，因?yàn)楫a(chǎn)生別名的語句(通常是賦值語句)將會作為新的向前參與流分析的起點(diǎn)，并由向前分析記錄.

3 物理傳感器相關(guān)功能分析

Android系統(tǒng)現(xiàn)支持30種以上的傳感器.Android物理傳感器是指能夠通過SensorManager對象進(jìn)行調(diào)用與管理的傳感器，其中包含了8個(gè)基礎(chǔ)傳感器與約22個(gè)合成傳感器.基礎(chǔ)傳感器為直接由硬件設(shè)備提供數(shù)據(jù)的傳感器，合成傳感器則是由基礎(chǔ)傳感器通過軟件層面的組合得到.本文中主要對基礎(chǔ)傳感器進(jìn)行分析，因?yàn)楹铣蓚鞲衅骺梢钥醋饔苫A(chǔ)傳感器實(shí)現(xiàn)的特殊功能，基礎(chǔ)傳感器的數(shù)據(jù)混淆后也會連帶影響合成傳感器輸出的結(jié)果.

3.1 傳感器調(diào)用類型分析

本文通過SensorTainter對47 144個(gè)Google Play的APP進(jìn)行分析，發(fā)現(xiàn)6 408個(gè)APP具有物理傳感器的調(diào)用行為，調(diào)用率約為13.59%，文中所有對應(yīng)用程序數(shù)量的討論皆以上述6 408個(gè)APP為基礎(chǔ).各類傳感器的調(diào)用情況如圖4所示:

Fig. 4 Statistics of Android sensor distribution圖4 傳感器調(diào)用分布統(tǒng)計(jì)

加速度傳感器的調(diào)用比重明顯高于其他傳感器，約67.8%的APP使用了加速度傳感器，這是由于Android應(yīng)用程序中大部分的常用功能都可以通過加速度傳感器實(shí)現(xiàn).磁強(qiáng)計(jì)、方向傳感器與陀螺儀調(diào)用率比較接近，分別約為23%，21%，15%.

磁強(qiáng)計(jì)除了作為電子羅盤的必要傳感器，更多的時(shí)候是與加速度傳感器一起組合計(jì)算方向.新的Android版本中方向傳感器(ORIENTATION)已經(jīng)不建議使用，但方向傳感器的調(diào)用率仍然很高，主要原因在于直接調(diào)用方向傳感器比通過加速計(jì)和磁強(qiáng)計(jì)組合更加方便，雖然在精度方面略有不足，但對于判斷屏幕橫屏豎屏等簡單功能而言已經(jīng)足夠.陀螺儀通常用于游戲矢量旋轉(zhuǎn)角度的計(jì)算，以及與加速度傳感器一起實(shí)現(xiàn)慣性導(dǎo)航.光傳感器(LIGHT)的調(diào)用率在剩余傳感器中最高，主要用于實(shí)現(xiàn)屏幕的亮度調(diào)節(jié).在本文的APP樣本中，接近傳感器(PROXIMITY)只用于實(shí)現(xiàn)接聽電話時(shí)的鎖屏功能.氣壓傳感器(PRESSURE)理論上可以用于實(shí)現(xiàn)氣壓計(jì)小工具，但在被分析的樣本中極少出現(xiàn).圖4中的其他傳感器包含了除基礎(chǔ)傳感器與線性加速計(jì)、重力傳感器以外的所有組合傳感器，可以看出開發(fā)者對于官方提供的組合傳感器并不習(xí)慣，更傾向于靈活的自定義開發(fā)方式.

APP開發(fā)者會根據(jù)具體需求申請多個(gè)傳感器.根據(jù)本文統(tǒng)計(jì)，約67.75%的應(yīng)用程序僅調(diào)用了1種傳感器，約17.23%的應(yīng)用程序調(diào)用了2種傳感器，剩下約15.02%的應(yīng)用程序調(diào)用了3種及3種以上的傳感器.具有多種功能的APP中，數(shù)據(jù)混淆上限由承受能力下限的功能決定.

3.2 傳感器參與功能分析

本文使用基于關(guān)鍵詞比較與詞法子樹的組合相似度判斷方法，并結(jié)合內(nèi)容特征[29]，對抽取出的程序片段進(jìn)行分類.經(jīng)分析發(fā)現(xiàn)，Android物理傳感器開發(fā)呈現(xiàn)明顯的規(guī)律性.常用功能的核心算法具有很大的相似性，例如屏幕旋轉(zhuǎn)、搖晃檢測等，我們將其歸咎于開源庫的廣泛應(yīng)用.相對地，由于開發(fā)者無法在網(wǎng)絡(luò)上找到開源的案例，一些并非常用的功能或者特殊場景下的功能算法之間則具備一定差異.此外，相同功能因預(yù)期要求不同，調(diào)用的傳感器類型以及算法也會存在差異.為盡可能準(zhǔn)確地對APP傳感器相關(guān)功能進(jìn)行分類，我們通過迭代擴(kuò)展功能集的方式進(jìn)行功能分類.功能分析結(jié)果如圖5所示:

Fig. 5 Analysis result of sensor-based functions圖5 傳感器相關(guān)功能分析

首先篩選出具有明顯功能標(biāo)識的程序段，從中抽取功能對應(yīng)的核心算法和傳感器類型作為該功能的識別特征之一；然后利用關(guān)鍵API、關(guān)鍵操作符以及操作順序?qū)ζ渌δ芷芜M(jìn)行初步匹配.對于難以識別的程序片段使用基于詞法子樹的相似度比較方法進(jìn)行匹配，同時(shí)，人工經(jīng)驗(yàn)被用于輔助特殊功能和新功能的識別.功能集會隨著分析樣本數(shù)量的增加而逐漸擴(kuò)大.

圖5為本文根據(jù)功能目標(biāo)、功能算法以及傳感器類別進(jìn)行分類的統(tǒng)計(jì)結(jié)果.圖5中，縱坐標(biāo)表示分析得到的傳感器相關(guān)功能，“None”表示無實(shí)際功能，“Others”表示其他功能，“Gesture”表示手勢檢測，“Lightness”表示亮度調(diào)節(jié)，“Activity”表示行為檢測，“Pro-screen lock”表示距離鎖屏，“O-navigation”表示基于方向傳感器導(dǎo)航，“G-navigation”表示基于陀螺儀導(dǎo)航，“Shaking”表示搖晃檢測，“Rotation”表示旋轉(zhuǎn)角度計(jì)算，“Screen orientation”表示屏幕方向檢測，“Accelerometer”表示加速度檢測，“Step-counter”表示步數(shù)統(tǒng)計(jì).傳感器相關(guān)功能中所占比例最多的為判斷屏幕橫豎屏，占到所有功能實(shí)現(xiàn)中的近30%.判斷屏幕方向是大部分應(yīng)用需要支持的功能，雖然Android提供了用于判斷屏幕方向的API，但是該API在實(shí)際應(yīng)用上存在缺陷，無法判斷一次性旋轉(zhuǎn)180度以上的轉(zhuǎn)動，因此相當(dāng)一部分開發(fā)者選擇利用加速度傳感器實(shí)現(xiàn)屏幕旋轉(zhuǎn)的檢測功能.通過加速度傳感器判斷手機(jī)震動功能的比例排名第2，約為18.4%，我們在1 000多個(gè)應(yīng)用程序中發(fā)現(xiàn)了震動檢測功能，除了搖一搖功能以外，常見的震動檢測出現(xiàn)在需要抖動翻頁、游戲等APP中.利用方向傳感器和陀螺儀進(jìn)行輔助導(dǎo)航功能主要出現(xiàn)在地圖、娛樂搜索等提供導(dǎo)航的APP中，其中利用方向傳感器(包括使用加速計(jì)與磁強(qiáng)計(jì)合成方向傳感器)的程序約占12.6%，比使用陀螺儀進(jìn)行慣性導(dǎo)航高了約2個(gè)百分點(diǎn).游戲矢量旋轉(zhuǎn)檢測主要用于射擊類游戲等APP中，該功能對于數(shù)據(jù)精度與響應(yīng)時(shí)間都有一定的需求.

進(jìn)一步分析得出，相比于傳感器側(cè)信道攻擊，APP中正常功能對傳感器原始數(shù)據(jù)的敏感程度較低，算法多以閾值比較的形式實(shí)現(xiàn).APP中有4種傳感器建議響應(yīng)頻率：NORMAL，UI，GAME，F(xiàn)ASTEST，分別對應(yīng)200 ms，67 ms，20 ms和0 ms，其中，NORMAL和UI的使用次數(shù)最多，F(xiàn)ASTEST幾乎沒有出現(xiàn).少數(shù)APP中存在1種以上的傳感器相關(guān)功能，例如，在最近市面上出現(xiàn)的某款約車軟件中分析出了搖晃檢測與輔助導(dǎo)航功能.

根據(jù)上述分析結(jié)果與當(dāng)前已知的傳感器側(cè)信道攻擊方法，后續(xù)主要討論加速度傳感器、方向傳感器、磁強(qiáng)計(jì)和陀螺儀的原始數(shù)據(jù)混淆對于應(yīng)用的影響以及隱私泄露攻擊成功率.

本文在分析過程中發(fā)現(xiàn)了一些需要引起重視的現(xiàn)象：通過加速度傳感器與簡單機(jī)器學(xué)習(xí)方法對用戶手勢改變進(jìn)行推測的游戲應(yīng)用已經(jīng)出現(xiàn)在應(yīng)用市場中，無論開發(fā)者處于何種目的，該行為對于用戶的隱私安全具有非常大的潛在危險(xiǎn).在我們之前的研究[30]中已經(jīng)證實(shí)手勢變化可以泄露PIN等用戶敏感信息.更為嚴(yán)重的是多數(shù)APP中調(diào)用運(yùn)動傳感器的同時(shí)，也會調(diào)用TouchEvent與MotionEvent等用于觸控的API，約為總數(shù)的41.87%，導(dǎo)致用戶使用應(yīng)用程序的同時(shí)，觸碰行為與運(yùn)動傳感器之間的關(guān)聯(lián)輕而易舉的被APP得到，而該行為是大多數(shù)基于傳感器側(cè)信道的構(gòu)建前提.

4 基于差分隱私的傳感器數(shù)據(jù)混淆

傳感器側(cè)信道符合相似的構(gòu)建過程，即利用機(jī)器學(xué)習(xí)技術(shù)挖掘用戶行為與傳感器數(shù)據(jù)之間的映射關(guān)系，因此，如果能夠在不影響用戶體驗(yàn)的前提條件下干擾側(cè)信道的學(xué)習(xí)階段，則可以抑制側(cè)信道的攻擊能力.我們借鑒差分隱私的思想對傳感器數(shù)據(jù)進(jìn)行模糊，使得傳感器數(shù)據(jù)在反映用戶行為的過程中失準(zhǔn).

4.1 數(shù)值噪聲

差分隱私用于保證一定數(shù)據(jù)精度下，有效確保數(shù)據(jù)的隱私性.我們將側(cè)信道學(xué)習(xí)階段的特征提取過程映射為差分隱私的數(shù)據(jù)查詢行為，通過Laplace機(jī)制向當(dāng)前響應(yīng)的傳感器讀數(shù)xo(n)中注入隨機(jī)噪聲noise(n)～Lap(0,βd)：

xo(n)=x(n)+noise(n)，

(13)

其中,βd=Sd(εd)，d([1,3]表示傳感器的數(shù)據(jù)維度，S為當(dāng)前維度上的敏感度，其值等于窗口范圍內(nèi)傳感器讀數(shù)的最大值與最小值的差值.混淆因子ε表示數(shù)據(jù)混淆程度，由Laplace的概率分布函數(shù)可知，ε越大概率密度的尺度參數(shù)越小，產(chǎn)生高值噪聲的概率越大.

為了使防御對攻擊者以及用戶的完全透明，數(shù)據(jù)混淆機(jī)制實(shí)施于Android的框架層，通過在傳感器管理對象android_hardware_SensorManager文件中添加過濾器的方式實(shí)現(xiàn)噪聲注入，具體修改方法見附錄C.

4.2 時(shí)間噪聲

基于時(shí)間的隱私泄露攻擊通過識別用戶在不同行為時(shí)產(chǎn)生的時(shí)間間隔進(jìn)行隱私竊取.絕大部分傳感器側(cè)信道攻擊都需要時(shí)間信息參與學(xué)習(xí)過程，因此必須考慮響應(yīng)時(shí)間混淆.

文獻(xiàn)[31]證明在系統(tǒng)時(shí)鐘中加入隨機(jī)延遲噪聲可以有效降低該類攻擊的威脅.本文通過隨機(jī)添加響應(yīng)時(shí)間補(bǔ)償?shù)姆绞綄鞲衅黜憫?yīng)時(shí)間進(jìn)行混淆.

差分隱私的思想同樣適用于時(shí)間噪聲.時(shí)間序列是1維序列，因此參數(shù)調(diào)整為β=Sε.因?yàn)闀r(shí)間具有順序性，每個(gè)時(shí)間點(diǎn)添加噪聲后不能超過前后相鄰時(shí)間點(diǎn)，因此S=1f，其中f為傳感器采樣頻率.實(shí)時(shí)對傳感器的響應(yīng)時(shí)間進(jìn)行混淆會使得實(shí)際讀數(shù)存在最大1位的延遲，所以在對傳感器要求很高的情況下(例如射擊游戲矢量旋轉(zhuǎn)角度檢測)不對響應(yīng)時(shí)間進(jìn)行混淆.傳感器數(shù)值混淆與響應(yīng)時(shí)間混淆的核心算法設(shè)計(jì)如算法1所示.

算法1. 應(yīng)用框架層傳感器數(shù)據(jù)混淆算法.

輸入：當(dāng)前傳感器讀數(shù)vin、傳感器響應(yīng)系統(tǒng)時(shí)間Tin、混淆程度εvalueεtime、傳感器輪詢頻率f、傳感器維度d、緩存窗口w;

輸出：混淆數(shù)據(jù)vout.

#LaplaceDistribution(β)：根據(jù)參數(shù)β隨機(jī)生成Laplace噪聲

①Svalue=Maxw-Minw；*計(jì)算敏感度參數(shù)*

②βcurrent=Svalue(εvalued)；

③noisevalue=LaplaceDistribution(βcurrent)；

④vout[i]=vin[i] +noisevalue；*加入數(shù)值噪聲進(jìn)行數(shù)據(jù)混淆*

⑤ pushvoutinto cache；*時(shí)延緩存*

⑥βtime=1(f×εtime)；

⑦noisetime=LaplaceDistribution(βtime)；

⑧Tout=Tin+noisetime；*加入時(shí)間噪聲進(jìn)行數(shù)據(jù)混淆*

⑨ whileTout1f

⑩noisetime=LaplaceDistribution(βtime)；

4.3 數(shù)據(jù)混淆承受范圍分析

本節(jié)將討論不同程度數(shù)據(jù)混淆對于APP傳感器相關(guān)功能的實(shí)際影響情況以及各功能所對應(yīng)的數(shù)據(jù)混淆承受上限.

4.3.1 屏幕方向檢測

根據(jù)第3節(jié)中的分析結(jié)果，物理傳感器相關(guān)功能中應(yīng)用范圍最廣的是屏幕旋轉(zhuǎn)檢測.首先構(gòu)造屏幕旋轉(zhuǎn)檢測試APP，該APP根據(jù)接收到的加速度傳感器讀數(shù)計(jì)算當(dāng)前的屏幕方向，為比較分析加速度混淆程度對于屏幕方向判斷影響，不同混淆程度的傳感器數(shù)據(jù)將會通過多個(gè)線程同時(shí)傳遞到數(shù)據(jù)收集APP中.

噪聲程度隨ε的增加而增強(qiáng).時(shí)間開銷上，實(shí)驗(yàn)設(shè)備Meizu max5中對加速度傳感器讀數(shù)進(jìn)行1次混淆的平均時(shí)間為0.024 ms，相對于傳感器響應(yīng)時(shí)間可忽略不計(jì)(即使FASTEST下也存在3 ms左右停頓).

屏幕方向檢測功能影響實(shí)驗(yàn)中，共有5名參與者進(jìn)行了約1 000次測驗(yàn)，每次測試的屏幕旋轉(zhuǎn)的方向、方式以及時(shí)間等因素均為隨機(jī)，實(shí)驗(yàn)結(jié)果基本一致，本節(jié)中隨機(jī)選取其中1次實(shí)驗(yàn)結(jié)果進(jìn)行舉例說明.圖6表示1次實(shí)驗(yàn)中，屏幕方向隨時(shí)間的變化，當(dāng)Y方向數(shù)值為1時(shí)表示屏幕當(dāng)前方向?yàn)闄M屏，數(shù)值為-1時(shí)表示當(dāng)前方向?yàn)樨Q屏，0表示設(shè)備朝向其他方向轉(zhuǎn)動或者沒有屏幕轉(zhuǎn)動的情況，圖6中實(shí)線(藍(lán)色)表示利用未經(jīng)混淆的原始數(shù)據(jù)計(jì)算得到的屏幕方向，虛線(紅色)表示利用ε=10混淆的數(shù)據(jù)計(jì)算的屏幕方向，傳感器讀數(shù)的時(shí)間混淆均為ε=2.從圖6中看出，進(jìn)行混淆后的加速度傳感器數(shù)在ε=10的情況下依然能正確地判斷屏幕方向，僅因時(shí)間混淆而在時(shí)間為7 400 ms處產(chǎn)生了輕微的延遲.

Fig. 6 Screen orientation detection with ε=10圖6 ε=10屏幕方向檢測

將混淆程度提高到ε=50后，如圖7所示，被混淆的加速度讀數(shù)依然可以正確地判斷屏幕方向，但是出現(xiàn)了少量的波動情況.實(shí)際使用過程中只要不出現(xiàn)旋轉(zhuǎn)方向判斷錯(cuò)誤，小幅度的波動是被允許的.

Fig. 7 Screen orientation detection with ε=50圖7 ε=50屏幕方向檢測

實(shí)驗(yàn)結(jié)果證明：利用加速度傳感器實(shí)現(xiàn)的屏幕方向檢測功能對于傳感器數(shù)據(jù)的魯棒性較高，可以容忍高程度的數(shù)值混淆.僅考慮用戶體驗(yàn)與功能完整性，針對屏幕方向檢測功能的傳感器數(shù)據(jù)混淆范圍為1≤ε≤10，時(shí)間混淆上，時(shí)延范圍為-4.28～3.33 ms，平均時(shí)延為-0.06 ms.

4.3.2 搖晃檢測功能

搖晃檢測功能不僅被廣泛使用于搖一搖的實(shí)現(xiàn)上，還被用于相冊、閱讀等APP中實(shí)現(xiàn)快速翻頁.根據(jù)對本文APP數(shù)據(jù)集的統(tǒng)計(jì)分析結(jié)果，搖晃檢測功能均依賴于加速度傳感器實(shí)現(xiàn)，具體實(shí)現(xiàn)算法主要分為3類，算法樣例見附錄B.

實(shí)驗(yàn)過程中，所有參與者在不受任何限制的環(huán)境下以隨機(jī)幅度搖晃設(shè)備，實(shí)驗(yàn)程序?qū)⒎謩e通過3種搖晃檢測算法統(tǒng)計(jì)不同加速度混淆程度的搖晃次數(shù).圖8顯示了3種搖晃檢測算法在混淆程度1≤ε≤100的搖晃次數(shù)分布情況，實(shí)驗(yàn)中的時(shí)間混淆ε=2.3種算法對于搖晃的判定依據(jù)不同，因此相同數(shù)據(jù)下的平均搖晃統(tǒng)計(jì)次數(shù)存在差異.從圖8可看出，搖晃檢測算法1(s-algorithm 1)搖晃統(tǒng)計(jì)分布的上下邊緣距離最寬，這是由于搖晃檢測算法1判斷方法最簡單，因此受到數(shù)據(jù)混淆的影響程度最大.相較而言，搖晃檢測算法2(s-algorithm 2)與搖晃檢測算法3(s-algorithm 3)受到加速度數(shù)據(jù)混淆的影響較小，沒有出現(xiàn)較大幅度的誤差.

Fig. 8 Result of impact on shaking detection of obfuscation圖8 3種搖晃算法測試計(jì)數(shù)統(tǒng)計(jì)結(jié)果

Fig. 9 Statistics of 3 shaking detection algorithms with ε incresing圖9 3種算法計(jì)數(shù)隨混淆程度變化統(tǒng)計(jì)

3種算法隨數(shù)據(jù)混淆程度的平均搖晃次數(shù)統(tǒng)計(jì)情況如圖9所示，點(diǎn)劃線(藍(lán)色)、短劃線(紅色)與實(shí)線(綠色)分別表示算法1(s-algorithm 1)、算法2(s-algorithm 2)與算法3(s-algorithm 3).所有搖晃檢測算法在混淆程度ε=20之前都具有很好的魯棒性，實(shí)際搖晃檢測次數(shù)與未混淆情況時(shí)保持一致.當(dāng)混淆程度超過20后搖晃檢測算法1與搖晃檢測算法2對應(yīng)的檢測效果開始出現(xiàn)小幅度偏差.隨著混淆程度繼續(xù)增大，搖晃檢測算法2誤差范圍穩(wěn)定，而通過搖晃檢測算法1實(shí)現(xiàn)的搖晃檢測功能表現(xiàn)出明顯異常.搖晃檢測算法3在ε=75時(shí)開始出現(xiàn)小幅度偏差.

從功能的實(shí)際應(yīng)用場景角度分析，搖晃檢測算法1與搖晃檢測算法2主要在搖一搖類功能中應(yīng)用，用于判斷短時(shí)間內(nèi)智能手機(jī)是否發(fā)生大幅度搖晃，只需在多次搖晃中檢測要設(shè)備搖晃即可滿足功能要求，因此，雖然搖晃檢測算法1與搖晃檢測算法2相比于搖晃檢測算法3魯棒性略低，但算法本身應(yīng)用場景對于算法的精度要求不高.搖晃檢測算法3通常被用于相冊、閱讀中的翻頁功能，這類功能需要較高的魯棒性與低精度(精度太高容易引起頻繁翻頁)，對于混淆數(shù)據(jù)的要求反而更高.

搖晃檢測功能驗(yàn)證中時(shí)間混淆范圍為-3.58～ 2.84 ms，平均時(shí)延為-0.084 ms.綜合考慮用戶體驗(yàn)與具體功能要求，本文建議利用搖晃檢測算法1與搖晃檢測算法2的搖晃檢測所對應(yīng)的傳感器數(shù)據(jù)混淆范圍為1≤ε≤20，搖晃檢測算法3相關(guān)功能的數(shù)據(jù)混淆范圍為1≤ε≤70.

4.3.3 地理方位檢測

地理方位檢測功能主要發(fā)現(xiàn)于地圖導(dǎo)航、電子羅盤等應(yīng)用中，參與功能實(shí)現(xiàn)的傳感器為陀螺儀和方向傳感器.我們比較相同方位時(shí)不同程度混淆的數(shù)據(jù)在計(jì)算方位時(shí)的誤差，分析方位檢測功能中算法魯棒性.實(shí)驗(yàn)過程中，方位被映射到{正北，東北，正東，東南，正南，西南，正西，西北}八個(gè)方向，分別以數(shù)字0～7表示，數(shù)值混淆范圍為1≤ε≤100，時(shí)間混淆為ε=2.隨機(jī)抽取的某次實(shí)驗(yàn)結(jié)果如圖10與圖11所示.

Fig. 10 Geographic orientation detection with ε=10圖10 ε=10地理方位檢測

Fig. 11 Geographic orientation detection with ε=100圖11 ε=100地理方位檢測

圖10與圖11分別為混淆程度ε=10與混淆程度ε=100時(shí)的方向檢測結(jié)果，其中線段(藍(lán)色)表示準(zhǔn)確方位，誤差棒(紅色)表示通過混淆數(shù)據(jù)計(jì)算的方位與準(zhǔn)確方位之間的誤差.從比較結(jié)果中不難看出，方位檢測算法對于傳感器數(shù)據(jù)中的噪聲具有很強(qiáng)的魯棒性，根據(jù)我們對實(shí)驗(yàn)結(jié)果的統(tǒng)計(jì)，混淆程度平均到達(dá)ε=100后方向才開始出現(xiàn)明顯偏差.混淆程度為ε=10以下時(shí)，所有實(shí)驗(yàn)中的方向計(jì)算結(jié)果均與準(zhǔn)確方向一致，數(shù)據(jù)混淆對于方位檢測功能沒有產(chǎn)生任何負(fù)面影響.實(shí)驗(yàn)中時(shí)間混淆的平均范圍為-3.75～5.15 ms，平均時(shí)延為-0.015 6 ms，方位檢測功能的數(shù)值混淆的理論承受范圍為1≤ε≤10.

4.3.4 設(shè)備旋轉(zhuǎn)方向檢測

設(shè)備旋轉(zhuǎn)方向檢測主要存在2種實(shí)現(xiàn)方式：1)方向傳感器，根據(jù)一段時(shí)間間隔后設(shè)備在某個(gè)方向上的角度差計(jì)算設(shè)備的旋轉(zhuǎn)方向；2)陀螺儀，APP首先判斷設(shè)備姿態(tài)，而后依據(jù)某一維度上的旋轉(zhuǎn)角速度判斷設(shè)備旋轉(zhuǎn)方向.通過方向傳感器實(shí)現(xiàn)設(shè)備旋轉(zhuǎn)方向檢測的實(shí)現(xiàn)原理與4.3.3節(jié)中相似，本小節(jié)中針對第2類算法進(jìn)行分析.

參與人員被要求以任意姿態(tài)隨機(jī)旋轉(zhuǎn)實(shí)驗(yàn)手機(jī)，APP將根據(jù)不同混淆程度的陀螺儀讀數(shù)計(jì)算當(dāng)前旋轉(zhuǎn)方向，并統(tǒng)計(jì)方向改變的次數(shù).通過比較錯(cuò)誤的旋轉(zhuǎn)方向次數(shù)對算法魯棒性進(jìn)行評估.實(shí)驗(yàn)結(jié)果如圖12所示.

Fig. 12 Experimental result of smartphone rotation with ε range from 0 to 11圖12 設(shè)備旋轉(zhuǎn)計(jì)數(shù)分布隨ε增長統(tǒng)計(jì)

圖12中，X軸為數(shù)據(jù)混淆程度，Y軸為平均旋轉(zhuǎn)次數(shù)，誤差棒(紅色)表示旋轉(zhuǎn)檢測的誤差情況.旋轉(zhuǎn)方向檢測算法對于數(shù)據(jù)的敏感程度遠(yuǎn)超出預(yù)期，數(shù)值混淆程度達(dá)到ε=3時(shí)開始出現(xiàn)明顯誤差，雖然平均方向改變次數(shù)并沒有隨著混淆程度增加而大幅度改變，但是誤差范圍逐漸擴(kuò)大.

實(shí)際應(yīng)用時(shí)，用戶可以容忍短暫的響應(yīng)停頓，但通常無法接受APP的錯(cuò)誤響應(yīng).我們定義檢測到旋轉(zhuǎn)事件但沒有響應(yīng)的情況為輕微誤差，例如屏幕旋停頓.定義旋轉(zhuǎn)方向判斷錯(cuò)誤為嚴(yán)重誤差，例如向右旋轉(zhuǎn)判斷為向左旋轉(zhuǎn)，2種誤差隨混淆程度變化的統(tǒng)計(jì)結(jié)果如圖13所示：

Fig. 13 Statistics of slight error and significant error with ε range from 1 to 11圖13 輕微誤差率與嚴(yán)重誤差率隨ε增長統(tǒng)計(jì)

圖13中，由實(shí)線(紅色)表示的嚴(yán)重誤差的錯(cuò)誤率在混淆程度為1～5之間時(shí)始終保持為0，而點(diǎn)劃線(藍(lán)色)表示的輕微錯(cuò)誤率隨著混淆程度增加接近線性增長，可知輕微的數(shù)據(jù)混淆并不會產(chǎn)生影響功能性的錯(cuò)誤.實(shí)驗(yàn)中時(shí)間混淆的平均范圍為-3.93～3.06 ms，平均時(shí)延為-0.0965 ms.為了保證用戶的體驗(yàn)不受到影響，設(shè)備旋轉(zhuǎn)方向檢測的數(shù)值混淆最大范圍為1≤ε≤3.

4.3.5 游戲矢量旋轉(zhuǎn)檢測

游戲矢量旋轉(zhuǎn)角度功能在所有的傳感器相關(guān)功能中對于數(shù)據(jù)的敏感程度最高，實(shí)現(xiàn)該功能的APP通常不會對傳感器數(shù)據(jù)進(jìn)行太多的運(yùn)算，因此不會產(chǎn)生由復(fù)雜運(yùn)算而造成的精度損失.依據(jù)應(yīng)用場景，我們將游戲矢量角度旋轉(zhuǎn)角度分為2種類型：1)射擊、駕駛類游戲，對于旋轉(zhuǎn)角度以及響應(yīng)時(shí)間要求嚴(yán)格，通過陀螺儀實(shí)現(xiàn)；2)不倒翁等簡單游戲，通常由加速度傳感器實(shí)現(xiàn).

首先討論第1類應(yīng)用場景.實(shí)時(shí)的旋轉(zhuǎn)角度由旋轉(zhuǎn)速度與時(shí)間間隔的乘積計(jì)算，陀螺儀數(shù)值的混淆誤差會與時(shí)間混淆誤差累積.我們比較設(shè)備旋轉(zhuǎn)情況下由混淆數(shù)據(jù)計(jì)算的旋轉(zhuǎn)角度與準(zhǔn)確角度之間的誤差.圖14顯示了10種混淆程度下的角度誤差統(tǒng)計(jì)情況：

Fig. 14 Error of vector rotation angle with ε range from 1 to 10 based on gyroscope圖14 基于陀螺儀的矢量旋轉(zhuǎn)角度誤差與ε關(guān)系

從圖14可以看出，第1類游戲矢量角度算法由于積累了數(shù)值與時(shí)間2方面的誤差，算法對于數(shù)據(jù)混淆的改變非常敏感，混淆程度為ε=1時(shí)的矢量角度幾乎與真實(shí)矢量角度相同，但是，當(dāng)ε=3時(shí)開始出現(xiàn)較大范圍的誤差，最大誤差為0.02°.隨著ε的加大，旋轉(zhuǎn)角度的誤差程度明顯增加，誤差范圍逐漸擴(kuò)大，最大誤差接近0.07°.僅觀察誤差數(shù)值，混淆后的數(shù)據(jù)對于矢量旋轉(zhuǎn)角度的計(jì)算的影響似乎并不嚴(yán)重，在混淆程度ε=10時(shí)，最大的誤差也沒有超過0.1°，為具體分析誤差的影響程度，圖15中顯示了10種混淆程度下的計(jì)算誤差與實(shí)際矢量角度之間的誤差比率.

Fig. 15 Error rate of vector rotation angle with ε range from 1 to 10 based on gyroscope圖15 基于陀螺儀的矢量旋轉(zhuǎn)角度誤差率與ε關(guān)系

根據(jù)圖15中的結(jié)果，ε=1時(shí)矢量角度的誤差率接近于0，最大誤差率約為0.2%，在ε=5以下時(shí)最大誤差率穩(wěn)定在6%以下，平均誤差率同樣趨近于0.ε增加到6之后，誤差率上限突然上升至14%，雖然整體誤差率均值仍然保持較低水平，但是小概率出現(xiàn)的大誤差依然會給應(yīng)用程序功能完整性以及用戶體驗(yàn)造成不良影響.該項(xiàng)實(shí)驗(yàn)中的時(shí)間混淆范圍為-3.26～5.25 ms，平均時(shí)延0.0024 ms.由陀螺儀為基礎(chǔ)的第1類矢量旋轉(zhuǎn)檢測功能的混淆程度的承受范圍建議為1≤ε≤3.

第2類場景中矢量旋轉(zhuǎn)角度基于加速度傳感器計(jì)算，附錄A中不倒翁游戲?yàn)榈湫蜆永?通過比較不同混淆程度的加速度傳感器數(shù)據(jù)對于旋轉(zhuǎn)角度計(jì)算的誤差，分析各類算法對于數(shù)據(jù)混淆的敏感程度.混淆程度1≤ε≤10所對應(yīng)的誤差統(tǒng)計(jì)結(jié)果如圖16所示：

Fig. 16 Error of vector rotation angle with ε range from 1 to 10 based on accelerometer圖16 加速度傳感器矢量旋轉(zhuǎn)角度誤差與ε關(guān)系

通過與圖14中的誤差統(tǒng)計(jì)結(jié)果對比，由加速度傳感器計(jì)算矢量旋轉(zhuǎn)角度的算法在魯棒性上明顯低于由陀螺儀實(shí)現(xiàn)的算法，即使在ε=2的情況下的最大誤差達(dá)到了+-2°左右，該功能實(shí)現(xiàn)算法在計(jì)算過程中放大了由數(shù)據(jù)混淆帶來的噪聲.

考慮到第2類場景用戶體驗(yàn)對響應(yīng)時(shí)間以及精度要求與第1類場景相比較低，定義超出+-閾值范圍以外的計(jì)算結(jié)果為錯(cuò)誤結(jié)果，進(jìn)行進(jìn)一步分析，統(tǒng)計(jì)錯(cuò)誤率以分析誤差的分布情況，結(jié)果如圖17所示.

Fig. 17 Error rate of vector rotation angle based on accelerometer with 3 thredsholds with ε range from 1 to 10圖17 矢量旋轉(zhuǎn)角度的3種閾值對應(yīng)誤差與ε關(guān)系

閾值分別選擇1.5°，2°和3°.閾值3°所對應(yīng)的錯(cuò)誤率在ε<4時(shí)增長不明顯，說明混淆程度在4以下時(shí)絕大部分誤差不超過+-3°，ε>4后錯(cuò)誤率緩慢上升，誤差范圍逐漸擴(kuò)大，ε=9時(shí)誤差超過+-3°的樣本已經(jīng)超過10%.根據(jù)閾值為1.5°與2°的統(tǒng)計(jì)分布，由數(shù)據(jù)混淆而導(dǎo)致的矢量旋轉(zhuǎn)角度偏差在混淆程度ε≤2以下時(shí)普遍低于1.5°，ε>3后數(shù)據(jù)混淆對算法造成較大的干擾.綜上分析，雖然第2類場景中用戶體驗(yàn)對于旋轉(zhuǎn)角度的要求較低，但是算法本身的魯棒性弱于由基于陀螺儀的矢量旋轉(zhuǎn)算法，數(shù)據(jù)混淆承受范圍建議為1≤ε≤2，實(shí)驗(yàn)中的時(shí)間混淆范圍為-4.59～4.02 ms，平均時(shí)延0.017 ms.

5 傳感器側(cè)信道對抗效果分析

5.1 傳感器側(cè)信道防御實(shí)驗(yàn)

第4節(jié)分析了傳感器數(shù)據(jù)混淆對于功能實(shí)現(xiàn)以及用戶體驗(yàn)的影響，本節(jié)中將討論傳感器數(shù)據(jù)混淆方案對抗防御傳感器側(cè)信道的實(shí)際效果.

我們從代表性的傳感器側(cè)信道中篩選出9種典型攻擊方案進(jìn)行復(fù)現(xiàn)，其中，前7種傳感器側(cè)信道為“輸入側(cè)信道”，即以傳感器數(shù)據(jù)做為媒介竊取用戶的敏感輸入信息，后2種側(cè)信道為“追蹤側(cè)信道”，追蹤側(cè)信道通過提取移動設(shè)備物理傳感器的固有誤差實(shí)現(xiàn)對設(shè)備的識別，進(jìn)而達(dá)到用戶追蹤的目的.實(shí)驗(yàn)過程中所涉及的側(cè)信道詳細(xì)信息如表1所示.

考慮到Android碎片化和傳感器硬件差異的影響，我們選用了5部不同的智能手機(jī)重復(fù)進(jìn)行實(shí)驗(yàn)，覆蓋了多種芯片、廠商、設(shè)備型號和系統(tǒng)版本.實(shí)驗(yàn)中所使用的設(shè)備信息如表2所示.

Table 1 List of Side Channels in Defence Experiment表1 防御實(shí)驗(yàn)涉及側(cè)信道列表

Table 2 List of Experimental Devices表2 實(shí)驗(yàn)設(shè)備列表

首先進(jìn)行輸入側(cè)信道的防御對抗實(shí)驗(yàn)，我們邀請了15位人員參與數(shù)據(jù)收集，每位參與者進(jìn)行相同操作：以習(xí)慣握姿在分配設(shè)備的虛擬數(shù)字鍵盤上隨機(jī)點(diǎn)擊按鍵，實(shí)驗(yàn)程序會實(shí)時(shí)記錄下點(diǎn)擊操作過程中的傳感器數(shù)據(jù)，以及對應(yīng)時(shí)間信息，重復(fù)操作保證10個(gè)類別(數(shù)字0～9)均包含足夠樣本.由同一參與者收集的樣本做為獨(dú)立數(shù)據(jù)集，分別在每個(gè)數(shù)據(jù)集上進(jìn)行7種輸入側(cè)信道攻擊，以平均的單次點(diǎn)擊輸入預(yù)測成功率作為評價(jià)指標(biāo)，實(shí)驗(yàn)結(jié)果如表3所示.

表3中，縱向表示側(cè)信道類型，橫向表示不同混淆程度的數(shù)值噪聲背景下單次點(diǎn)擊輸入的預(yù)測準(zhǔn)確率.從表3中結(jié)果看出，當(dāng)進(jìn)行數(shù)據(jù)混淆后，所有輸入側(cè)信道攻擊的單次準(zhǔn)確率立刻出現(xiàn)不同程度的下降，并且預(yù)測準(zhǔn)確率隨混淆程度的增大而呈現(xiàn)穩(wěn)定的下降趨勢，初始數(shù)據(jù)集中表現(xiàn)較優(yōu)異的側(cè)信道下降幅度更明顯.僅觀測數(shù)值可能會認(rèn)為數(shù)據(jù)混淆方案對抗側(cè)信道的防御效果不足，然而，輸入側(cè)信道的單次點(diǎn)擊預(yù)測誤差會隨著預(yù)測序列長度的增加而累積，以單次準(zhǔn)確率最高的Textlogger側(cè)信道為例，當(dāng)攻擊長度為4的PIN時(shí)，初始情況下側(cè)信道的平均成功率約為32%，即有約9成的概率在6次之內(nèi)嘗試攻破PIN，當(dāng)進(jìn)行了混淆程度為ε=1的混淆后，Textlogger攻擊PIN的平均成功率為21.5%，為達(dá)到相同的攻擊效果需要至少10次嘗試，然而大多數(shù)智能設(shè)備在自動鎖屏前僅允許5次失敗.因此，數(shù)據(jù)混淆能夠非常有效地對抗主流輸入側(cè)信道攻擊.

Table 3 Input Side Channel Accuracy under Data Obfuscation Environment表3 數(shù)據(jù)混淆環(huán)境下輸入側(cè)信道準(zhǔn)確率 %

Note: Data obfuscation can immediately produce significant effects.

追蹤側(cè)信道的對抗實(shí)驗(yàn)中，使用2種追蹤側(cè)信道分別對5臺實(shí)驗(yàn)設(shè)備進(jìn)行識別，平均識別準(zhǔn)確率如表4所示.

由表4中結(jié)果看出，數(shù)據(jù)混淆對抗追蹤側(cè)信道的情況與輸入側(cè)信道對抗實(shí)驗(yàn)結(jié)果相似，實(shí)施數(shù)據(jù)混淆后能夠立即抑制追蹤側(cè)信道的設(shè)備識別準(zhǔn)確率，在混淆程度為1的情況下，2種側(cè)信道攻擊識別成功率分別下降了約5個(gè)百分點(diǎn)和2.5個(gè)百分點(diǎn)，隨著混淆程度逐漸增加，追蹤側(cè)信道的預(yù)測準(zhǔn)確率持續(xù)下降.需要說明的是，實(shí)際攻擊場景中攻擊者需要從大量設(shè)備中識別目標(biāo)設(shè)備[25]，其數(shù)量遠(yuǎn)遠(yuǎn)超過實(shí)驗(yàn)中的5臺設(shè)備，因此可以預(yù)測基于數(shù)據(jù)混淆方式的防御機(jī)制能夠在實(shí)際應(yīng)用中有效抵抗追蹤側(cè)信道攻擊.綜上所述，本文提出的數(shù)據(jù)混淆防御機(jī)制在實(shí)際對抗多種類型傳感器側(cè)信道攻擊時(shí)均具有良好的防御能力，防御效果隨混淆程度的增加而增強(qiáng).

Table 4 Tracking Side Channel Accuracy under Data Obfuscation Environment表4 數(shù)據(jù)混淆環(huán)境下追蹤側(cè)信道準(zhǔn)確率 %

5.2 傳感器相關(guān)功能建議混淆范圍

綜合考慮第4節(jié)中傳感器相關(guān)功能對于數(shù)據(jù)混淆的承受能力與用戶體驗(yàn)，以及本節(jié)中數(shù)據(jù)混淆對于典型側(cè)信道攻擊的防御實(shí)驗(yàn)結(jié)果，本文給出了平衡功能完整性、用戶體驗(yàn)與側(cè)信道攻擊防御能力的建議混淆方案，如表5所示:

Table 5 Proposed Scope of Sensor Data Obfuscation 表5 傳感器數(shù)據(jù)淆程度ε建議范圍

Node:“×”means no data obfuscation.

6 相關(guān)工作

6.1 物理傳感器側(cè)信道攻擊

Cai等人于2011年首次詳細(xì)地提出了利用Android方向傳感器實(shí)現(xiàn)以竊取用戶點(diǎn)擊屏幕位置的隱私泄露攻擊方案[4].作者利用點(diǎn)擊過程中設(shè)備轉(zhuǎn)動的細(xì)微角度變化作為點(diǎn)擊事件的特征.隨后，Xu等人在TouchLogger的基礎(chǔ)上加入了加速度傳感器，實(shí)現(xiàn)了一種更加穩(wěn)定的PIN攻擊方法TapLogger[5].作者發(fā)現(xiàn)用戶在常用設(shè)備上進(jìn)行點(diǎn)擊輸入時(shí)，除了設(shè)備的旋轉(zhuǎn)角度以外，加速度變化上也存在一定規(guī)律，通過統(tǒng)計(jì)點(diǎn)擊時(shí)間內(nèi)加速度的波動以及時(shí)間間隔，可以使側(cè)信道攻擊準(zhǔn)確性上升.上述側(cè)信道攻擊方案只能應(yīng)用于通用數(shù)字鍵盤，ACCessory[14]通過提取用戶點(diǎn)擊過程中加速度傳統(tǒng)計(jì)特征，實(shí)現(xiàn)針對英文全鍵鍵盤的點(diǎn)擊定位攻擊.研究證明，除加速度傳感器與方向傳感器以外，陀螺儀也可以被用于定位用戶點(diǎn)擊屏幕的具體位置，例如TapPrints[35].由于點(diǎn)擊過程十分短暫，針對單一點(diǎn)擊事件的攻擊方法對于設(shè)備的性能要求較高，魯棒性有所欠缺，文獻(xiàn)[38]將研究的對象從單一的點(diǎn)擊事件轉(zhuǎn)移到了完整的輸入序列，作者認(rèn)為用戶對于習(xí)慣的輸入序列具有獨(dú)特的輸入規(guī)律，這種規(guī)律可以由輸入過程中的加速度反映.與其思想類似，文獻(xiàn)[39]利用動態(tài)時(shí)間規(guī)整(dynamic time wrap, DTW)對相同輸入序列進(jìn)行識別，僅需要極少訓(xùn)練樣本即可達(dá)到可觀的攻擊效果.

除了以輸入信息為目標(biāo)側(cè)信道，物理傳感器還被用于身份與地理位置信息泄露.不同廠商生產(chǎn)的傳感器芯片存在獨(dú)有的誤差分布，可以被用于對設(shè)備進(jìn)行追蹤.AccelPrint[40]利用加速度傳感器中的固有缺陷實(shí)現(xiàn)了用戶追蹤.類似的，文獻(xiàn)[25]與文獻(xiàn)[41]分別從不同角度闡述了如何利用Android物理傳感器的硬件誤差構(gòu)建設(shè)備的指紋信息，以達(dá)到用戶定位的目的.除追蹤以外，物理傳感器也被用于身份驗(yàn)證.Shahzad等人[42]根據(jù)用戶在觸摸屏上執(zhí)行的操作產(chǎn)生的加速度特征進(jìn)行用戶認(rèn)證，動作既可以是手勢，也可以是簡單交互.

6.2 Android應(yīng)用惡意行為分析

Android應(yīng)用惡意行為分析主要依賴于敏感API調(diào)用以及特殊權(quán)限申請.Zhang等人[11]基于APP中敏感API調(diào)用構(gòu)建基于上下文的行為圖，以此作為依據(jù)判斷APP中是否存在威脅操作.AndroidLeaks[43]是一款檢測APP潛在隱私泄露的靜態(tài)分析工具,通過追蹤敏感數(shù)據(jù)的流動判斷隱私信息是否被泄露.研究者通過軟件靜態(tài)分析方法，對APP中敏感API的調(diào)用過程進(jìn)行分析，自動生成目標(biāo)應(yīng)用敏感API調(diào)用的自然語言描述，該工作解決了APP權(quán)限申請信息生澀難懂的問題，但最終選擇權(quán)仍然保留在安全意識較為薄弱的用戶手中.FlowDroid[19]實(shí)現(xiàn)了上下文敏感的精確靜態(tài)污點(diǎn)分析，F(xiàn)lowDroid在soot的基礎(chǔ)上，克服了Android應(yīng)用程序生命周期復(fù)雜等難題，通過探索污染源與信息泄露出口之間可達(dá)路徑的方式分析應(yīng)用程序中可能存在的威脅.類似的靜態(tài)污點(diǎn)分析研究包括文獻(xiàn)[44-46].為了降低系統(tǒng)開銷，提高檢測準(zhǔn)確率，Backes等人[22]將程序切片[47]引入Android惡意行為分析并取得理想效果.作者在傳統(tǒng)的靜態(tài)分析之前加入程序切片過程，將感興趣的程序片段抽取出來，進(jìn)而降低了完整應(yīng)用程序分析時(shí)的系統(tǒng)開銷.本文綜合借鑒靜態(tài)污點(diǎn)分析與程序切片的思想，抽取應(yīng)用程序中與傳感器相關(guān)的程序片段，分析傳感器數(shù)據(jù)的詳細(xì)利用過程.

7 總 結(jié)

本文針對當(dāng)前Android物理傳感器側(cè)信道防御效果不理想的問題，提出了一種對于用戶完全透明的基于差分隱私的隱私防御方案.由于已知的Android物理傳感器側(cè)信道攻擊大多基于機(jī)器學(xué)習(xí)，構(gòu)建信道時(shí)非常依賴于目標(biāo)設(shè)備中傳感器數(shù)據(jù)質(zhì)量，通過在Android框架層對傳感器原始數(shù)據(jù)進(jìn)行特殊的混淆，從而達(dá)到降低攻擊成功率的效果.進(jìn)行傳感器數(shù)據(jù)混淆面臨2個(gè)困難：1)如何保證數(shù)據(jù)混淆行為不會影響用戶體驗(yàn)；2)如何混淆原始數(shù)據(jù)以有效對抗傳感器側(cè)信道攻擊.對于第1個(gè)問題，本文基于靜態(tài)污點(diǎn)分析與程序切片的思想，設(shè)計(jì)了一款針對Android物理傳感器的功能分析工具SensorTainter.SensorTainter將傳感器對象視為污染源，追蹤傳感器數(shù)據(jù)流流向，抽取出于傳感器數(shù)據(jù)相關(guān)的程序片段，分析相關(guān)功能實(shí)現(xiàn)算法對于輸入數(shù)據(jù)的敏感程度，通過SensorTainter對47 144個(gè)應(yīng)用程序進(jìn)行分析，本文統(tǒng)計(jì)出了應(yīng)用程序中物理傳感器的使用情況以及功能分類.針對第2個(gè)困難，本文借鑒差分隱私方法，引入Laplace噪聲對傳感器原始數(shù)據(jù)的數(shù)值與時(shí)間進(jìn)行混淆，并根據(jù)功能分類的結(jié)果提出最優(yōu)的數(shù)據(jù)混淆建議范圍.實(shí)驗(yàn)證明:本文提出的基于數(shù)據(jù)混淆的安全框架可以有效降低主流Andorid物理傳感器攻擊，并且不會對用戶體驗(yàn)和APP功能完整性造成干擾.

TangBenxiao, born in 1991. PhD candidate. Student member of the CCF. His main research interests include mobile privacy, program analysis, and machine learning.

WangLina, born in 1964. PhD, professor, PhD supervisor. Member of the CCF. She has authored 50 research papers and wined 12 authorized patents. Her main research interests include system security and steganalysis.

WangRun, born in 1991. PhD candidate. Student member of the CCF. His main research interests include mobile security and privacy, machine learning security.

ZhaoLei, born in 1985. Received his BE degree and PhD degree both in computer science at Wuhan University. Associate professor at the School of Cyber Science and Engineering, Wuhan University. His main research interests include software security, software analysis, and system protection.

WangDanlei, born in 1992. Received his ME degree in information security at Wuhan University. His main research interests include mechine learning and information content security.

附錄A. 傳感器相關(guān)功能程序片段抽取樣例.

1) 不倒翁APP部分源碼

public class BudaowActivity extends Activity implements SensorEventListener{

private GSensitiveViewgsView;

private SensorManagersm;

@Override

public void onCreate(BundlesavedInstance-State){

……

gsView=new GSensitiveView(this);

setContentView(gsView);

sm=(SensorManager) getSystemService(SENSOR_SERVICE);

sm.registerListener(this,sm.getDefault-

Sensor(Sensor.TYPE_ACCELERO-

METER),SensorManager.SENSOR_

DELAY_NORMAL);

}

……

public void onSensorChanged(SensorEventevent){

if(Sensor.TYPE_ACCELEROMETER!=event.sensor.getType()){

return;

}

float[]values=event.values;

floatax=values[0];

floatay=values[1];

doubleg=Math.sqrt(ax*ax+ay*ay);

doublecos=ayg;

if(cos>1){

cos=1;

} else if(cos<-1){

cos=-1;

}

doublerad=Math.acos(cos);

if(ax<0){

rad=2*Math.PI-rad;

}

intuiRot=getWindowManager().

getDefaultDisplay().getRotation();

doubleuiRad=Math.PI2*uiRot;

rad-=uiRad;

gsView.setRotation(rad);

}

……

private static class GSensitiveView extends ImageView{

private Bitmapimage;

private doublerotation;

private Paintpaint;

……

@Override

protected void onDraw(Canvascanvas){

doublew=image.getWidth();

doubleh=image.getHeight();

Rectrect=new Rect();

getDrawingRect(rect);

intdegrees=(int)(180*rotation

Math.PI);

canvas.rotate(degrees,rect.width()2,

rect.height()2);

canvas.drawBitmap(image,(float)

((rect.width()-w)2),

(float)((rect.height()-h)2),

paint);

}

public void setRotation(doublerad){

rotation=rad;

invalidate();

}

}

}

2) 功能抽取結(jié)果：

$r1@parameter0:android.hardware.

SensorEvent

$r3=$r1.

android.hardware.Sensor sensor>

$i0=virtualinvoke $r3.

Sensor:int getType()>()

$r2=$r1.

float[]values>

if 1==$i0 goto $r2=$r1.

hardware.SensorEvent:float[]values>

$f0=$r2[0]

$f1=$r2[1]

$f2=$f0*$f0

$f3=$f1*$f1

$f2=$f2+$f3

$d1=(double) $f2

$d1=staticinvoke

sqrt(double)>($d1)

return

$d0=(double) $f1

$d1=$d0$d1

$b1=$d1 cmpl 1.0

$b1=$d1 cmpg -1.0

$d1=1.0

$d0=staticinvoke

acos(double)>($d1)

$d1=-1.0

$d1=$d0

$b1=$f0 cmpg 0.0F

$d1=6.283185307179586-$d0

$r4=virtualinvoke $r0.

budaow.Budaow:android.view.Window-

Manager getWindowManager()>()

if $b1≥0 goto $r4=virtualinvoke

$r0.

android.view.WindowManager getWindow-

Manager()>()

$r5=interfaceinvoke $r4.

WindowManager:android.view.Display

getDefaultDisplay()>()

$i0=virtualinvoke $r5.

Display:int getRotation()>()

$d0=(double) $i0

$d0=1.5707963267948966*$d0

$d1=$d1-$d0

if $b1≤0 goto $b1=$d1 cmpg -1.0

$r6=$r0.

example.budaow.Budaow$GSensitiveView

gsView>

virtualinvoke $r6.

GSensitiveView:void setRotation(double)>

($d1)

if $b1≥0 goto $d0=staticinvoke

lang.Math:double acos(double)>($d1)

附錄B. 搖晃檢測算法示例.

1) 搖晃檢測算法1(s-algorithm 1)

booleanisshake=false;

if(Math.abs(sensor.values[0])>threshold‖Math.abs(sensor.values[1])>threshold‖Math.abs(sensor.values[2])>threshold)

isshake=true;

2) 搖晃檢測算法2(s-algorithm 2)

booleanisshake=false;

floatdeltaX=sensor.values[0]-lastX;

floatdeltaY=sensor.values[1]-lastY;

floatdeltaZ=sensor.values[2]-lastZ;

if((Math.sqrt(deltaX*deltaX+deltaY*

deltaY+deltaZ*deltaZ)diffTime*

10 000)>shakeThreshold)

isshake=true;

3) 搖晃檢測算法3(s-algorithm 3)

booleanisshake=false;

floattp=(float)((x*x+y*y+z*z)

96.170387);

if(tp>shakeThreshold)

isshake=true;

附錄C. Android系統(tǒng)框架層傳感器平移混淆部分核心算法示例

android_hardware_SensorManager.cpp

classLaplaceNoise{

public:

LaplaceNoise(doubleb):mu(0.0),beta(b){

srand((unsigned)time(NULL));

}

LaplaceNoise(doublem,doubleb):mu(m),beta(b){

srand((unsigned)time(NULL));

}

LaplaceNoise(unsigned intseed,doublem,doubleb):mu(m),beta(b){

srand(seed);

}

doublegetLocation(){returnmu;}

doublegetScale(){returnbeta;}

doublenoise(){

doublep=rand()double(RAND_MAX);

doublex=(p>0.5)?-log(2.0-2.0*

p):log(2.0*p);

returnmu+beta*x;

}

private:

doublemu;

doublebeta;

};

classMixLayer{

public:

MixLayer(unsigned intbs,unsigned intdv,unsigned intdt,unsigned intdi,unsigned intf):

bufferSize(bs),start(0),end(0),deltaV

(dv),deltaT(dt),dimention(di),

frequency(f)

{

buffer=newASensorEvent[bufferSize+1];

max=new double[dimention];

min=new double[dimention];

}

～MixLayer(){

delete []buffer;

delete []max;

delete []min;

}

unsigned intgetBufferSize(){returnbufferSize;}

unsigned intgetDeltaV(){returndeltaV;}

voidsetDeltaV(unsigned intdv){deltaV=dv;}

unsigned intgetDeltaT(){returndeltaT;}

voidsetDeltaT(unsigned intdt){deltaT=dt;}

unsigned intgetFrequency(){returnfrequency;}

voidsetFrequency(unsigned intf){frequency=f;}

boolisEmpty(){returnstart==end;}

boolisFull(){return(end+1)%(bufferSize+1)==start;}

bool push(ASensorEventse){

if(isFull())return false;

buffer[end]=se;

end=(end+1)%(bufferSize+1);

return true;

}

boolpop(){

if(isEmpty())return false;

start=(start+1)%(bufferSize+1);

return true;

}

voidcalcM(){

for(unsigned inti=0;i

max[i]=0.0;

min[i]=0.0;

for(unsigned intj=start;j!=end;j=(j+1)%(bufferSize+1)){

if(j==start){

max[i]=buffer[j].data[i];

min[i]=buffer[j].data[i];

}

else{

if(buffer[j].data[i]>max[i])max[i]=buffer[j].data[i];

if(buffer[j].data[i]

}

}

}

}

ASensorEvent*retMixedData(){

if(isEmpty())return NULL;

ASensorEvent*out=buffer+start;

calcM();

for(unsigned inti=0;i

doublebetaV=(max[i]-min[i])*

dimentiondeltaV;

LaplaceNoiselpV(betaV);

doublenoiseV=lpV.noise();

out→data[i]+=noiseV;

doubledelay=1.0frequency;

doublebetaT=delaydeltaT;

LaplaceNoiselpT(betaT);

doublenoiseT=lpT.noise();

doubletout=out→timestamp+noiseT;

doubletlast=buffer[(end+bufferSize)%(bufferSize+1)].timestamp;

while(toutdelay){

noiseT=lpT.noise();

tout=out→timestamp+noiseT;

}

if(tout

}

returnout;

}

private:

unsigned intbufferSize;

unsigned intstart,end;

ASensorEvent*buffer;

unsigned intdeltaV,deltaT;

unsigned intdimention;

double*max,*min;

unsigned intfrequency;

}