關鍵詞
移動雲計算
Android安全
root管理方案
數字簽名
完整性驗證
摘要
· 對安卓設備進行“根化”可能是終端用戶的一種自願行爲，比如刪除OEM預裝應用程序。這導致了惡意軟件的特權升級機會的增加。現有的root權限管理方案依賴於終端用戶對設備上安裝的所有合法和非法應用程序做出權限授予決定。然而,非技術用戶不能,還是粗心在決定哪些特權適合什麼類型的應用程序。爲了解決這個問題,一個根特權管理機構命名RootAgency提出採用數字簽名方案保證獨家root-privilege-granting驗證應用程序的機會。RootAgency通過檢查應用程序是否持有由密鑰生成的簽名來對應用程序進行身份驗證，並在經過簽名的應用程序提交請求時授予root特權。此外，它驗證應用程序的完整性，以防止它重新打包。因此，當面對root請求時，用戶不參與決策制定。該方案保證了根Android設備的安全性，提高了移動終端設備的安全性。這減少了被誤用的Android設備對雲基礎設施的威脅。此外，還實現了一個原型來評估其有效性、效率和開銷。實驗結果表明，RootAgency具有廣泛的兼容性和合理的性能開銷。
1 介紹
· 雲計算是智慧城市的重要組成部分。隨着移動互聯網接入的迅速普及，移動雲服務中的安全問題已經成爲雲計算研究人員和工程師關注的關鍵問題。安全的兩個主要領域是數據安全和隱私保護。移動終端設備作爲移動雲環境的重要組成部分，其自身的弱點會威脅到整個移動雲的安全。這些威脅可能來自軟件漏洞和硬件漏洞。例如，典型的攻擊，如利用殭屍網絡，或分佈式拒絕服務(DDoS)攻擊已經成爲移動雲服務的一個日益增長的威脅。據報道，研究人員發現了首個已知的名爲Twitoor的Android手機惡意軟件，它可以以一種無法檢測的方式將設備招募到Android殭屍網絡中。通過使用惡意註冊的Twitter賬戶，終端用戶設備中的惡意軟件就會接收指令，執行下載二級有效載荷和切換到其他賬戶等操作。
· Android是一款流行的移動終端操作系統(OS)，由谷歌在2009年設計併發布。它的流行、開源設計和缺乏應用程序驗證，使配備它的設備成爲惡意軟件攻擊的主要目標。最近的一項研究報告稱，幾乎90%的Android設備都面臨着通過惡意軟件和信息進行攻擊的風險。Root特權是Android中最高的權限，可以完全控制終端用戶的Android設備。考慮到其誘人的可能性，爲Android設備尋找根源可能是終端用戶出於各種動機的一種自願行爲，比如刪除預裝的應用程序、更改硬件設置、備份Android系統或完全反惡意軟件功能。
· 然而，Android設備的根可能導致一個開放的機會，特權升級的惡意軟件。這爲惡意軟件提供了一種獲取根特權的相對容易的方法，而不是漏洞利用，因爲惡意軟件所需要的只是在授予根特權時誤導最終用戶。例如，建議一種僞裝方法，將惡意代碼注入重新包裝的良性應用程序，並假裝自己是一個未經修改的應用程序。儘管SuperSU和KingRoot等根管理工具是爲授予根權限而設計的，但它們都依賴於最終用戶來爲所有類型的應用程序做出權限授予決策。用戶根管理方案暴露了一個漏洞，增加了根Android設備的根特權泄漏風險，因爲Android設備用戶幾乎不可能知道或理解每個權限的詳細角色。在一項調查中發現，只有3%的互聯網參與者和24%的實驗室研究參與者能夠成功地理解和授予權限，而高達42%的用戶完全不知道權限及其後果。
· 爲了彌補缺乏經驗的用戶無法進行root權限管理的缺陷，必須保證經過身份驗證的應用程序的獨家root權限授予機會，並對應用程序的完整性進行檢查，防止其重新打包。因此，本文提出了一種root管理方案——root代理。在root代理中，請求許可的應用程序由root代理而不是最終用戶獲得root特權。在我們的設計中，root代理包含兩個模塊:一個可驗證的應用程序生成過程和一個應用程序完整性驗證過程。可驗證的應用程序生成過程將已驗證的應用程序作爲輸入提供給應用程序完整性驗證過程。可驗證應用程序生成過程實現了提取,驗證和埋置的指定文件摘要生成驗證應用。應用程序完整性驗證程序檢索嵌入式數字簽名和使用數字簽名驗證程序檢查數字簽名的真實性和檢測應用程序的完整性。根據完整性驗證的結果，root代理判斷根請求應用程序是否應該被授予root特權。爲了驗證root代理的可行性，通過幾個典型的應用程序示例實現了一個原型，並對其有效性、效率、可移植性和性能開銷進行了評估。
下面是這篇文章的主要貢獻：
（1）爲了降低Root權限泄露的風險，提出了一種基於Root代理的app完整性驗證方案。
（2）root代理的原型在實際環境中實現和部署，以評估其有效性、效率和可移植性。
（3）該方案減少了被誤用的Android設備對移動雲安全的威脅。
本文的其餘部分組織如下：
· 本研究領域的相關工作在第2部分進行了描述。第3節介紹了root機構的設計目標和細節，然後在第4節中介紹了其原型。在此基礎上，對root機構原型進行了測試和評價。所提出的方案的侷限性和可能的改進建議見第6節，本文的結論見第7節。
2 相關研究
· 本節主要討論root特權濫用的相關工作。我們還詳細闡述了現有的解決方案和所提議的架構之間的異同。
2.1 root權限的預防和保護
· root特權濫用的典型緩解措施是保護root特權不被非法獲取。一些學術研究採用了加強Android內核的附加強制訪問控制(MAC)或類似的方法來保護根訪問或限制高級權限的能力和活動範圍。
在此之前，Shabtai等人建議將SELinux集成到Android中，以減少惡意攻擊的潛在危害，從而加強內核級的訪問控制。隨後，Smalley和Craig[26]提出了一種基於SElinux的中間件MAC方案SEAndroid，以緩解root權限濫用和應用漏洞帶來的影響。SEAndroid還通過改進Android系統的安全性，特別是防止特權升級的利用和root特權的濫用，證明了它的有效性。Bugiel等人[3]提出了FlaskDroid，這是Android OS的通用安全架構，它採用了類似於SEAndroid的兩層MAC框架，利用Android中間件的高效策略語言來支持多個細粒度的安全策略。
· 可以得出結論，MAC方案確實彌補了現有Android操作系統中的自主訪問控制(DAC)方案，併爲root權限安全提供了強大的保護。但是，上述系統提供的默認設置和策略不能提供足夠的靈活性和用例場景。默認的策略很難理解和修改，尤其是針對不同廠商的Android，直接影響用戶的體驗。此外，包含MAC機制的方法無法考慮在root Android設備上使用root特權的可能性的非常現實的情況。
2.2root權限管理
· 根特權濫用的另一個解決方案是根特權管理。與第一個類別不同，這個類別側重於幫助用戶管理根特權。Root Guard[24]相對於MAC的嚴格限制，對設備用戶提出了一種相對寬鬆的Root管理，幫助終端用戶通過預定義的策略在有根的Android設備上管理Root權限。這些預定義的策略來自於谷歌play(2014)中現有應用程序的root-privilege需求，並被分爲四組。
· 在root保護中，請求應用程序可以獲得root權限進行監視和控制。然而，這些不靈活的預定義策略不可避免地會給最終用戶帶來操作問題。例如，在首次使用root-require應用程序之前，最終用戶必須瞭解它屬於哪個組。在本文中，我們的方法Root Agency採用了應用程序完整性驗證來檢測請求應用程序的真實性，保證了Root特權的可靠使用，而不需要終端用戶的依賴。
2.3 應用可靠性檢測
· root權限安全的第三類是應用程序的真實性檢測。在學術研究中，app相似度檢測技術作爲app認證檢測的一種，被過多地用於驗證重新打包的app的完整性。
· DroidMOSS[44]從每個app中提取操作碼作爲其特徵，並應用模糊哈希技術生成每個app的指紋進行匹配。兩個對應的app之間的相似度，也就是相似度評分，被客觀地反映出來，計算出兩個指紋之間的距離。0是一個可擴展的基礎架構，用於Android應用程序之間的代碼相似度分析，它根據應用程序每個基本塊中的代碼序列生成所有k克的操作碼，並應用未來哈希來生成應用程序的向量表示。兩個應用程序的相似度，即它們的特徵集之間的相似度，使用jaccard相似度度量。DNADroid[7]是一個用於重新打包應用程序檢測的工具，它從每個應用程序生成程序依賴關係圖(PDGs)，並將其與兩個不同的應用程序進行比較，以檢測應用程序的相似性。
· 以上的作品都採用了不同的研究對象來檢測app之間的差異，描述重新打包後的app的修改細節。根據我們的觀察，一個關鍵的先決條件是探測過程必須成對進行。兩個版本的應用程序都必須是可用的，並應確保真實的版本。此外，這些系統只適用於pc上的大規模app比較，不適合低容量的Android設備。
· 爲了在Android設備中實現這種檢測，根代理與上述系統相比有幾點不同:首先，通過簽名驗證來檢測app的真實性(與原始app的相似性)。其次，根代理從請求應用程序中檢索當前指紋和原始指紋，而不需要原始應用程序本身。最後，Root Agency在Root request time被激活，在Android中執行驗證過程，因爲它只需要識別安裝的Root -require app是否已經被修改。
3 root agency 的設計
3.1 目標
· 爲了保證用戶管理根權限的保護，必須實現三個關鍵的設計目標，即有效性、效率和可用性。考慮到惡意軟件的僞裝，有效性是應用程序真實性驗證的必要前提，而有效性的缺失將直接導致root權限的泄露。惡意代碼可能隱藏在app的不易察覺的角落，從而避免被防病毒app檢測到。因此，根機構驗證方案需要一種具有足夠證據信息的準確檢測方法，能夠識別app的完整性。
· 效率是第二個目標，它用於量化根機構驗證方案對系統性能的影響。雖然，它是最方便的檢索和保留所有的應用程序文件的證據，但它造成低效，因爲不是所有的文件都需要進行分析。因此，在我們的設計中，只選取app的關鍵文件作爲提取目標和證據信息。可移植性是評估不同Android版本之間兼容性的另一個基本要求。因此，需要對不同版本的本地和第三方Android操作系統進行測試。
3.2 設想
· 在本文中，我們的目標是提供一個輕量級的根特權管理方案。我們專注於建立一個app驗證方案。因此，app行爲檢測超出了本文的範圍。此外，我們假設應用程序開發人員和證書頒發機構(CA)可以相互信任。考慮到直接從相應的開發者那裏獲取原始的應用程序比較困難，從谷歌Play下載的應用程序被視爲原始版本。此外，由於沒有討論簽名密鑰泄漏的問題，我們假設來自開發人員和CA的簽名密鑰沒有泄漏。
3.3 Rootagency驗證方案
· root機構驗證方案的基本設計元素是禁止惡意軟件(修改和重新打包的良性應用程序)通過誤導終端用戶獲得根特權。通過可靠的應用程序生成過程和應用程序完整性驗證方案來保證應用程序的完整性。
· 如圖1所示，開發者和CA構成了可驗證的app生成過程。當應用程序試圖申請根權限時，Android設備中插入的應用程序完整性驗證過程檢測應用程序的完整性。特別是，可驗證的應用程序包含數字簽名。根機構的可驗證app生成過程是一個app重建過程，將原app轉化爲可驗證app的版本。這個修改過程包括三個關鍵步驟:指紋生成、指紋認證、app轉換。指紋生成和app轉換由app開發者實現。指紋認證由CA執行，通過這三個關鍵步驟，生成併發布一款滿足根機構完整性認證要求的app。
· root代理的app完整性驗證過程是一個app完整性檢測過程，它在請求的app未被驗證時執行app完整性驗證。如圖1中Android設備部分所示，構建app完整性驗證流程，將請求app與根訪問分離開來。確切地說，在請求應用程序獲得根特權之後，完整性驗證過程提取加密的指紋並計算當前的指紋進行簽名驗證。最後，根據應用程序完整性驗證的結果判斷請求應用程序是否獲得root權限。
3.3.1 可驗證的應用程序生成過程
在本節中，我們將解釋可驗證的應用程序生成過程中的不同子過程。
A.目標選擇
· 所有Android應用程序都由不同的文件和文件夾組成，這些文件和文件夾執行各自的功能，如表1所示。· AndroidManifest.xml存儲元數據，如所需的包名和權限等。在app執行之前，將app需要的必要信息提供給Android系統。dex包含了所有Dalvik字節碼形式的應用程序代碼，可以在Dalvik虛擬機中執行。META-INF可以存儲開發人員的簽名，以驗證第三方開發人員的身份。文件夾庫存儲由可執行文件引用的本機庫二進制文件。雖然Android應用程序主要是用Java編寫的，但它們的一些功能可能是用本地代碼實現的。這個目錄是可選的，因爲大多數Android應用程序不包含本機代碼。文件夾存儲用戶界面佈局，圖像和圖標等。文件夾資產包含非編譯的資源。
· app的真實性需要有效的驗證證據，因爲app包比較容易被惡意代碼反編譯和感染。考慮到有效性需求，我們選擇與執行相關的文件和文件夾作爲提取目標。根據需求，class .dex、AndroidManifest.xml和Suffix文件是直接影響良性app執行行爲的文件，因此它們是被選擇的目標。例如，在一個良性的應用程序中，可以將惡意代碼注入class .dex，並且可以向AndroidManifest.xml附加額外的權限以實現惡意行爲。
· 此外，爲了保護版權和未選擇的文件，作爲補充證據，選擇了包含原始開發人員信息的開發人員公鑰。例如，在一個沒有修改的重新打包的app中，修改後的佈局和修改後的logo被認爲是一個不完整的app。根據前面的分析，目標提取接收並提取所選擇的文件或文件夾進行指紋生成。
B 指紋的一代
· 指紋生成過程的目的是將選定的目標轉化爲有效的可驗證證據。它是通過使用哈希技術來生成所選目標的摘要作爲證據來實現的，該技術對應用程序文件中最微小的變化都很敏感。詳細的指紋生成過程包括三個步驟，其次是傳輸安全的附加步驟。如圖2左側所示。根據Android的簽名方案，在標準簽名過程中，應用SHA-1來消化開發者生成的非文件夾和非簽名文件。
· 然而，在[27]中進行了關於SHA-1的散列碰撞實驗，結果表明，在我們的設計中，SHA-1對於摘要生成是不安全的。爲了更好的安全性和空間消耗，在可驗證的app生成過程中，在計算摘要中選擇SHA-256來代替SHA-1。SHA-2的安全性分析表明，它也有類似於SHA-1[2]的被破壞的可能性。然而，目前尚未發現針對SHA-2安全標準的實際攻擊。在實踐中，我們的方案中摘要生成算法的選擇是靈活的，可以根據實現需求進行修改。
· 在指紋生成階段，使用兩次哈希函數。一次計算所有目標摘要，然後將計算出的摘要連接成更短的形式，用於app指紋。通過兩次哈希計算，提取app完整性證據進行app完整性驗證。
C 指紋識別
· 如圖2的指紋認證模塊所示，它是一個通過數字簽名進行指紋加密的過程。它具有檢測僞造和篡改的能力，不僅爲指紋及其發佈後對應的app提供了有效的保護，也保證了指紋的真實性。
· 在這一階段的開始，需要驗證接收到的指紋。完整性驗證保證了指紋在線傳輸的完整性，爲數字簽名步驟提供了準確的指紋。簽名驗證從開發人員公鑰數據庫中檢索開發人員公鑰以檢測指紋完整性。在數字簽名,一旦指紋驗證的完整性,CA跡象的明文指紋生成數字簽名使用CA私鑰存儲在數據庫的關鍵。通過指紋認證階段,接收到的指紋身份驗證生成加密指紋並交付給相應的開發人員。
D 應用程序轉換
· 下一階段是app轉換，在接收到CA的加密指紋後，生成可驗證的app，如圖2中app轉換模塊所示，這一階段包括兩個步驟:指紋注入和app重新打包。將加密的指紋插入對應的app中，所有文件和文件夾按照標準的Android簽名流程重新打包。
· 考慮root機構的完整性驗證功能,加密指紋注射作爲先決條件階段確保加密指紋從CA可以集成到原始應用程序。考慮到時間consump,檢索,在前一步中,加密指紋直接嵌入應用程序的主目錄中,普遍叫指紋。在後面的步驟中，包含加密指紋的重新打包的app由開發者的私鑰簽名，該私鑰對應於在目標提取階段選擇的作爲證據的公鑰。通過以上步驟，最終生成攜帶證據信息的可驗證app。
3.3.2 App完整性驗證流程
· app的完整性驗證過程可以幫助判斷是否可以將root權限授予請求app。如圖3所示，app的完整性驗證過程首先通過請求app的基本信息對app信息數據庫進行搜索，以確定其是否被驗證。如果不存在，則激活完整性驗證模塊，更新app信息數據庫和審覈結果數據庫。在做出最終決定之前，結果提取過程檢索“資格審覈結果”和“審覈結果”。如果經過驗證，結果提取將收集審計結果並將其發送到結果判斷，該判斷將決定請求應用程序是否應獲得根特權。
· Android設備根機構驗證過程的關鍵步驟是應用程序完整性驗證過程，該過程根據當前指紋驗證請求應用程序的真實性。如圖3所示的app完整性驗證部分，爲了實現完整性驗證，該模型必須提取加密後的指紋，即CA的公鑰，並計算當前的指紋以滿足簽名驗證要求。
· 兩個步驟(當前的指紋計算和加密的指紋提取)從app包的安裝目錄中獲取所需信息。Android操作系統加載可執行文件和提取他人要求應用程序安裝目錄的文件執行程序。當前指紋轉換和打包後指紋檢索完成,簽名驗證是激活驗證數字簽名證書頒發機構(打包指紋)加密的私鑰。最後，資格審覈給出關於根請求的決策，並將結果更新到審覈結果數據庫。
當前指紋的計算過程與3.3節描述的指紋生成過程相同，不包括指紋加密過程。因此，本節沒有詳細描述。計算出的當前指紋被髮送到簽名驗證模塊進行下一步。
· 封裝的指紋檢索過程獲取嵌入在app轉換(章節3.3中描述)中的指紋，用於簽名驗證。在這個步驟中，使用請求應用程序的包名來定位請求應用程序的存儲目錄。然後，從定位的目錄檢索加密的指紋。最後，將加密後的指紋發送到簽名驗證過程。
· 在獲得計算出的當前指紋和加密的指紋後，簽名驗證從證書頒發機構密鑰數據庫中檢索證書頒發機構的公鑰，並利用加密的指紋、當前指紋和CAs公鑰來實現簽名驗證。最後將驗證結果發送給資質審覈。
資格審覈根據驗證結果(顯示爲真或假)決定請求應用是否獲得根權限。獲取審計結果並將其更新到審計結果數據庫以進行結果提取。
3.3.3 參考數據庫
· 在我們的設計中，參考數據庫(DB)有5個子數據庫:3個子數據庫在Android設備中，另外2個子數據庫在CA中，如表2所示。
· 根機構密鑰數據庫將CA的公鑰與根機構驗證共存，並在簽名驗證時激活，提供用於簽名驗證的公鑰。
· App信息數據庫包含驗證過的App信息四部分:包名、版本號、安裝時間、開發者信息，描述了從請求App中提取的實際信息。這也意味着，缺少包名和開發人員信息將導致檢測包含其他兩部分信息的應用程序失敗。缺少安裝時間和版本也會導致app更新後同樣的結果。激活app信息數據庫，檢索驗證後的app信息。
· 審覈結果數據庫存儲資質審覈結果。在根訪問管理中，審計結果數據庫被激活以提供認證結果。
· 開發人員密鑰數據庫用於存儲開發人員信息和相應的公鑰，在指紋認證過程中激活。
· CA密鑰數據庫提供了用於數字簽名的CA私鑰，併爲每個開發者提供了相應的公鑰用於指紋完整性驗證。
4 實施
· 作爲上一節設計的實現，根機構原型是根據3.3節提出的方案開發的。如圖4所示，根據實際執行環境，根代理原型中還包含了app markets和智能手機廠商的模塊。應用市場(官方應用市場和非官方應用市場)將開發者和設備用戶與上傳和下載的可能性聯繫起來(行動A和B)。
· 在將這些應用程序推向市場之前，需要採取三個主要步驟:指紋生成(動作1和2),指紋身份驗證(3和4)和應用程序轉換(5和6)是由開發人員和CA件的可覈查的應用。區分從原始的手工操作(7)行動,如果下載應用程序需要root特權,根機構覈查程序被激活的完整性驗證,而不是(行動7)。此外,根特權的決定取決於完整性驗證的結果(操作8)。
4.1 Verifiable app generation
· 構建root代理原型需要解決兩個問題:可驗證的應用生成和應用的完整性驗證。在本節中，首先討論第一個問題，然後在下一節中討論另一個問題。
· 考慮到目標提取和指紋生成的效率和一致性，自動執行過程、特殊定製的摘要組合算法和格式一致的指紋是實現的關鍵問題。因此，採用索引列表來提供檢索序列。同時，基於建議的過程，編寫了一個包含825行Java代碼的自動化工具，爲開發人員提供一個統一的過程。雖然3.3.1節描述了目標的選擇，但值得注意的是，目標是按索引順序提取和排列的。如圖5所示，通過文件連接將目標和開發人員的公鑰的固定長度摘要分別散列並集成到最終摘要中。
· 確保安全的傳輸指紋,開發人員提交指紋和指紋加密由CA的私鑰簽名。CA分發加密指紋由CA的私鑰簽署之日,sponding公鑰的真實性後開發人員確定接收到的指紋。
· 此外，針對不同的目標，對簽名驗證方法進行了兩次處理:開發者身份驗證和CA驗證。開發者身份驗證通過將開發者的簽名與他人的簽名區分開來，從而保護了指紋的完整性。後者通過檢測CA的簽名權限來實現身份驗證。
· 驗證返回的指紋密文後，將加密後的指紋插入到原app中。最後進行重新打包和簽名操作，將原app轉化爲可驗證的app。
4.2 Rootagency verification procedure
· 智能手機廠商預先安裝在原型的設備上(動作C)。驗證操作由包含891行Java代碼的一小段程序實現。對於在Android中工作的代碼，通過終端用戶授權來執行根權限管理的功能代碼被替換爲在ap-適當的位置進行根代理驗證的功能代碼，該功能代碼由四個主要步驟組成。首先，將根機構驗證程序的源程序編譯成.class文件。其次，使用DX可執行文件將轉換後的.class文件轉換爲Dalvik字節碼。第三，將Dalvik字節碼插入到用戶授權功能代碼執行的預定義位置，實現驗證功能。最後，對包含根代理驗證過程的修改後的根管理工具進行重新打包並簽名，生成根代理原型的可執行根管理工具。安裝修改後的根管理工具，以取代現有的根管理工具在根Android。
· 具體過程如圖6所示的時序圖所示。具體來說，步驟3-15是根機構驗證過程，它區別於用戶管理過程。
step1： 請求應用程序通過shell調用Su二進制
step2： Su通過發送一個授權請求來執行權限檢查。
step3： Su和根代理相互驗證以保護Su二進制完整性。在失效的情況下，根代理將不繼續執行保護根特權的下一步。
step4： 驗證Su的真實性後，根代理根據步驟1提供的app包名提取請求app信息。
step5： 根代理訪問應用程序信息數據庫，並根據已刪除的應用程序信息搜索驗證記錄。如果app信息數據庫擁有相同的對應信息，則激活根機構驗證程序模塊，從審覈結果數據庫中檢索審覈結果。提取的結果用於結果判斷的判斷證據(跳轉到步驟14)。如果沒有(請求的應用程序沒有被驗證)，應用程序完整性驗證方案將被激活，以檢測應用程序的完整性。
step6： 從請求應用程序檢索加密的指紋。
step7： 如果加密指紋存在，app的完整性驗證將繼續進行。如果沒有，這個條件會導致根本的需求被拒絕。
step8： 將目標文件和存儲在CERT.RSA中的開發人員公鑰從請求應用程序中提取出來。
step9： 提取的目標文件和開發人員密鑰用於通過4.1節中描述的操作序列生成當前指紋。
step10： 提取CA的公鑰以滿足簽名驗證需求。
step11： 通過簽名驗證檢測app的完整性，並提交資質審覈。
step12： 根據app誠信結果審覈合格結果。
step13： 審計結果數據庫中的日期被更新。同時，將請求app的信息記錄在app信息數據庫中。
step14： 審計結果用於確定請求應用程序是否應該被授予權限。
step15： Su根據根代理的判斷向請求應用程序授予根特權。
step16-18： 此步驟與典型的根管理工具相同。
5 RootAgency評價
· 根代理的原型在有效性、性能影響和可移植性方面進行了測試和評估。這些細節將在下面的小節中描述。
5.1 Testcase選擇
· 幾個應用被選爲測試用例，滿足了一個關鍵要求和兩個基本要求。一個應用程序的真實根需求是關鍵需求，它導致應用程序在第一次執行時觸發根代理驗證方案。可靠的來源是兩個基本要求之一，這是一個應用程序可靠性的保證。另一個是app的安裝，它代表了app的關注度和生命力。高安裝次數和可靠來源是幫助我們對樣本app進行分類和選擇的因素。考慮到用戶的實際情況，我們會仔細選擇app的一部分。因爲根代理驗證方案關注基於應用程序本身的應用程序完整性驗證。
· 在選擇階段，我們首先從谷歌Play中選擇100個公開提到根需求的應用。根據這些應用的基本介紹，將其分爲數據恢復、硬件修改、系統管理、快照等一系列具有不同功能特徵的代表性應用。
· 在此基礎上，根據指紋生成的安裝和變量提取目標，最終從每個分類中篩選出15個應用程序。特別是選擇了一些在其他應用市場非常受歡迎或者提供單一功能的應用。例如設置CPU和AppOps。這15個app的基本信息如表3所示，包括版本號、根公告、開發者名稱和安裝情況。
· 被選中的應用程序會被故意修改，然後被分成三組。第一組(g1)包含從谷歌Play下載的15個精選的原始應用，用來評估根代理的性能。爲了驗證根代理的有效性，第二組(g2)由15個可驗證的app組成，每個app對應g1中的一個app。g2生成過程包括指紋嵌入和可驗證的app生成兩個步驟，分別在3.3.1節中描述。考慮到獲取開發者密鑰的難度，我們實驗中的原始應用在每個指紋嵌入後都重新打包並使用指定的私有密鑰進行簽名。第三組(g3)是根據g2的每個app組成的，這是一個修改的過程。對g1的app進行修改，生成良性app的變化。爲了評價根機構的有效性，g2爲對照組，g3爲實驗組。爲了評價根機構的績效，g1爲對照組，g2爲實驗組。
5.2 有效性
· 如表4所示，爲了估計根代理的有效性，選擇15對可驗證的應用程序及其相應的修改過的應用程序(使用∗mark)來構成對比集。預期的驗證結果在第8列中描述。各可驗證app的修改項如第2-7欄所示。此外，修改的項目覆蓋了各種app文件，包括選擇的兩個目標(AndroidManifest。在我們的設計中，xml、classes.dex、.so和私鑰)和未選擇的文件(Res和其他文件)。
· 在相同的環境中，安裝並執行所選的應用程序來激活根需求。爲了獲得有效的結果，每個應用程序在驗證後被卸載。同時，在記錄完成後，清除根代理引用數據庫中存儲的數據，以區分app相同的包名。
· 表4中的驗證結果表明，實際結果與預期結果一致，說明根機構完整性驗證方案能夠準確識別應用程序的完整性。
5.3 示例應用程序的案例研究
· 在本小節中，我們以示例應用程序作爲案例研究。對g3修改後的應用程序進行評估，以驗證根代理的有效性。出於測試的目的，我們選擇了3對作爲代表性的案例，分別是根瀏覽器和根瀏覽器印跡、鈦備份和鈦備份印跡、根增強器和根增強器印跡。被標記的app版本是被修改過的。
case1： Root Browser
· Root Browser是一個針對Root用戶的文件管理器，在谷歌Play中有大量的安裝計數(10,0 0,0,0 0 0,0 0 0 50,0 0 0 0,0 0 0 0 0 0)。主要功能是瀏覽所有的Android文件系統，控制Android系統。根代理成功地將根瀏覽器識別爲惡意應用程序。它未能通過完整性測試，根代理在解壓和分析後確定class .dex文件和AndroidManifest.xml文件的摘要已被更改。此外，數字簽名與根瀏覽器不同。
case2： Root Booster
· Root Booster是爲那些需要更多性能來平穩運行應用程序的Root用戶，或者爲那些需要改進糟糕的電池壽命的用戶提供的。它擁有大約100萬用戶(第2016位)。根增強器沒有在根代理完整性驗證下獲得根特權。分析表明，對.so文件和數字簽名進行了修改。
case3： Titanium Backup
· Titanium備份是Android上最強大的備份工具(1000萬次安裝)，可以備份、恢復、凍結應用程序、用戶數據和市場鏈接。來自Titanium備份的根請求被根代理拒絕。對Titanium備份進行解壓縮，並計算每個文件的摘要。比較結果表明，res文件夾中的.png文件和.so文件被修改了。來自Titanium備份和Titanium備份的數字簽名也不是來自同一個開發人員。
5.4 技術性能分析
· 爲了評估根機構的績效，比較集由g1(對照組)和g2(實驗組)組成。同時，此階段不選擇修改後的app，需要獲取整個過程的時間消耗。
· 通過加入根機構完整性驗證，規定了性能實驗的時間消耗。沒有根機構完整性驗證，應用程序需要通過用戶管理操作的根特權。插入根代理完整性驗證後，請求的應用程序根據完整性簽出獲得根特權。對於統一的度量標準，在用戶根管理中，記錄從用戶單擊Grant按鈕到表示成功的界面的時間消耗。在根代理中，從測試應用程序發起請求到最終用戶獲得根特權請求的回覆(由日誌記錄)，時間消耗被記錄下來。要獲得每個應用程序的全部時間消耗，必須卸載所有測試應用程序，並在啓動相同應用程序包名的新測試時清除它們的相關數據。
· 如表5所示，第4列和第5列顯示了在相同的測試環境(三星Galaxy S6 Android 5.0.2)中計算的時間消耗(平均10倍)。第6列顯示了時間消耗增加的差異。可以看出，時間消耗在22.1 ms - 122.1 ms左右，這主要是由於根代理驗證方案。考慮到用戶體驗，增加約0.12 s的時間是可以接受的。
· 圖7用圖形表示時間消耗情況。值得一提的是，所有應用程序的時間消耗與其提取的應用程序文件號呈正相關。在根代理中，時間消耗由檢索時間、指紋生成時間和簽名驗證時間三部分組成。前兩項的差異導致了不同的時間消耗，如表5第4列和第5列所示。
5.5 便攜性評估
· 爲了確定根代理的可移植性，我們選擇了幾個具有不同Android版本或第三方Android操作系統的Android設備進行原型安裝。所選設備通過根管理工具進行根化，根管理工具與根代理原型是相同的版本，因爲典型的根代理驗證方案的實現依賴於根管理工具。
· 在已安裝的根代理原型設備中安裝和執行幾個測試應用程序，以檢查根代理的有效性。表6總結了我們的根代理實現目前支持的Android版本和設備模型。我們的原型支持從4.4.4到5.1.1的所有Android版本(包括相應的第三方Android操作系統)，可以應用於最典型的Android廠商設備，包括HTC、LG、MOTO、SONY、SUMSUNG和小米。
6 限制和未來的工作
· 在這一節中，討論了根代理原型和方案的一些侷限性。
· 首先，根代理方案在實際設備上的實施和部署需要廠商和應用開發者採用。一方面，root權限保護是Android安全方案的一部分。執行根代理方案來管理根權限，需要修改現有的Android系統。要實現此功能，必須將底層Android系統替換爲支持根代理的版本。另外，Android系統供應商(谷歌、供應商和第三方系統製造商)可以將根代理直接合併到他們自己的構建中。另一方面，根機構使用的完整性驗證方案需要應用程序的準確原始信息，而這些信息只能來自相應的開發者。此外，包含指紋的app必須由原開發者生成，因爲這種方法爲應用的真實性提供了保證。同時，基於殺毒軟件的app簽名驗證，可驗證的app可以輕鬆通過驗證。
· 其次，該方法解決了用戶管理根訪問的問題。一個應用程序在沒有用戶管理的情況下獲得未經授權的root特權，這是一個完全不同的挑戰，需要一種新的方法來解決。
· 根特權安全的研究大多是基於限制對根特權的訪問，或詳細描述根特權行爲以限制非法根授予所造成的損害。但是，目前還沒有有效的解決方案來緩解Android系統自身的漏洞所造成的root權限泄露。爲了消除這種威脅，需要修補所有可能造成損害的相應漏洞。此外，消除攻擊者的利益鏈或切斷感染渠道，如[35]中所提出的，也可以是一個有效的緩解。
· 未來，我們會在我們的方案中加入app的root權限撤銷，這是利用app的設計缺陷來濫用root權限的一種應急措施。
7 結論
· 移動終端設備的固有特性威脅着雲基礎設施，特別是來自被濫用的Android設備。然而，root權限管理對於沒有經驗的終端用戶來說是一項重要而又困難的工作。爲此，本文提出了一種基於根代理的根管理方案。採用數字簽名方案，保證認證應用的根特權授予機會。此外，還在用戶的設備中部署了一個完整性驗證過程，以檢查根權限請求應用程序是否已重新打包。實驗結果表明，根代理能夠以可接受的開銷和效率實現目標。