Android框架層完整性度量方案①

周星錦， 秦 宇， 吳秋新， 習(xí) 偉， 趙世軍

1(中國科學(xué)院軟件研究所 可信計(jì)算與信息保障實(shí)驗(yàn)室，北京 100190)

2(北京信息科技大學(xué) 理學(xué)院，北京 100196)

3(南方電網(wǎng)科學(xué)研究院有限責(zé)任公司，廣州 510080)

1 引言

移動互聯(lián)網(wǎng)帶來的移動無線通信方式使人們連通互聯(lián)網(wǎng)的方式不再受到束縛，隨之興起的移動設(shè)備更是徹底的改變了人們的生活方式. 手機(jī)的功能早已不限于電話和短信，人們會用它來連接自己的電子郵件、社交網(wǎng)絡(luò)、移動支付、照片分享等等. 智能手機(jī)儲存了許多敏感的個(gè)人信息，如登錄憑證、照片、甚至銀行賬戶等敏感信息. 這些數(shù)據(jù)對于用戶來說是至關(guān)重要的，因?yàn)榭赡軙胁环ǚ肿訒占藗兪謾C(jī)上的敏感信息作為數(shù)據(jù)供自己使用，甚至?xí)斐刹豢沙惺艿慕?jīng)濟(jì)損失和精神打擊. Android系統(tǒng)是Google公司2007年發(fā)布的基于Linux內(nèi)核的開源移動操作系統(tǒng)，主要應(yīng)用于智能手機(jī)、平板、智能手表等智能終端. 截至2015年Android收集已發(fā)行14.3億部，占有智能手機(jī)市場82%的份額，是目前最受歡迎的移動設(shè)備操作系統(tǒng)[1].

Android系統(tǒng)由于受眾廣泛、發(fā)行量大，是移動設(shè)備中黑客攻擊的主要目標(biāo). 好在Android硬件層面、內(nèi)核層和應(yīng)用層現(xiàn)在都有著比較有效的解決方案能防止常見的攻擊手段，但是框架層往往被認(rèn)為是提供給應(yīng)用層使用的JAVA API，對于框架層的安全性各安全方案一般只在意其邏輯上的正確性，即是否存在漏洞等問題，而沒有著重于保護(hù)它的靜態(tài)和動態(tài)完整性. 考慮到Android系統(tǒng)的體量以及設(shè)備被攻破后對用戶造成的損失，我們認(rèn)為對框架層完整性保護(hù)的研究是有必要的. 本文從可信計(jì)算的角度提出了一種針對Android框架層以及系統(tǒng)服務(wù)的完整性度量方法(Framework Integrity Measurement Method，以下簡稱FIMM)，將框架層的信任轉(zhuǎn)移至內(nèi)核層.

2 背景

Android系統(tǒng)體系復(fù)雜，國內(nèi)外學(xué)者針對Android不同層次的安全性進(jìn)行了非常多的研究. KNOX[2]是較為典型的Android信任鏈方案，它的安全啟動過程會逐步驗(yàn)證Bootloader、內(nèi)核以及系統(tǒng)軟件的簽名，確保系統(tǒng)加載的組件都是經(jīng)過授權(quán)的，以此保證Android系統(tǒng)從加電到正式運(yùn)行時(shí)整個(gè)過程的完整性. Google在Android4.4版本后移植了類SELinux的強(qiáng)制訪問控制(MAC)機(jī)制—SEAndroid[3]，嚴(yán)格來說SEAndroid實(shí)現(xiàn)在框架層，保護(hù)的對象是系統(tǒng)中的資源(文件、進(jìn)程等). 雖然SEAndroid的引入很大限度的阻止了惡意應(yīng)用對系統(tǒng)的攻擊，也有效地減小了內(nèi)核層出現(xiàn)漏洞時(shí)產(chǎn)生的威脅，但是SEAndroid依賴于可信的內(nèi)核，無法防御敵手對內(nèi)核的直接攻擊[4]. Android系統(tǒng)內(nèi)核安全的威脅承自Linux內(nèi)核安全威脅，國內(nèi)外對于arm平臺架構(gòu)的設(shè)備的內(nèi)和完整性有多種高效的解決方案，比較主流的是利用Trustzone管理以及校驗(yàn)內(nèi)核指令、頁表或者內(nèi)存的方法，例如SKEE[5]和tz-Rkp[6]以及為不可信的內(nèi)核提供可執(zhí)行文件、運(yùn)行時(shí)代碼和控制流完整性的方案[7]. 對于應(yīng)用層Android系統(tǒng)擁有自己的一套比較成熟的隔離和證書機(jī)制，通過沙箱機(jī)制的隔離確保APP間互不干涉，防止一個(gè)惡意程序侵害其他APP. 證書機(jī)制可以管理APP之間的調(diào)用權(quán)限、APP的版本控制，同時(shí)在設(shè)備的網(wǎng)絡(luò)通信過程上保證其安全性.

2.1 Android信任鏈

自可信計(jì)算組織(TCG)成立以來，可信計(jì)算取得了飛速的發(fā)展. 信任鏈的建立與傳遞是可信計(jì)算的基本問題，其中涉及到三點(diǎn)：信任根、信任傳遞和可信度量. 信任根是系統(tǒng)可信的基石，也是信任傳遞的起點(diǎn).信任傳遞指的是一層一層向上提供完全可信的功能，系統(tǒng)的每一層的實(shí)現(xiàn)都是基于下一層的信任，通過可信傳遞可以實(shí)現(xiàn)系統(tǒng)可信范圍的延伸[8-10]. 可信度量指的是對文件及其相關(guān)配置信息進(jìn)行完整性驗(yàn)證，防止其被篡改. 通過這三點(diǎn)構(gòu)建的信任鏈自上而下賦予信任，將大規(guī)模系統(tǒng)的信任管理縮小至信任根. 在一個(gè)完整的信任鏈體系中只要能保障信任根的可信即可保障整個(gè)系統(tǒng)的可信.

Android系統(tǒng)發(fā)布早期，三星的研究員就已經(jīng)對移動高效完整性度量和認(rèn)證機(jī)制進(jìn)行過研究[11，12]. 移動設(shè)備在硬件層面難以擴(kuò)展，在將移植Linux上的完整性度量架構(gòu)移植到Android上時(shí)選擇使用軟件TPM進(jìn)行擴(kuò)展. 該方案以廠商的內(nèi)核證書作為信任根來進(jìn)行安全引導(dǎo)，確保平臺能夠引導(dǎo)到安全狀態(tài).

三星KNOX[2]的安全啟動是一種防止未經(jīng)授權(quán)的操作系統(tǒng)和軟件在啟動過程中加載的過程. 固件鏡像是由已知的、受信任的權(quán)威機(jī)構(gòu)進(jìn)行加密簽名的，被認(rèn)為是授權(quán)的固件. 安全啟動時(shí)硬件驗(yàn)證bootloader、內(nèi)核、系統(tǒng)軟件的簽名. 安全啟動過程中用到的X.509證書和公鑰嵌入在bootloader中. 默認(rèn)情況下，設(shè)備的信任根是三星頒發(fā)的證書.

2.2 SEAndroid

Android是一個(gè)分層的體系結(jié)構(gòu)，允許應(yīng)用程序利用底層Linux內(nèi)核提供的服務(wù). 然而，Android并不阻止應(yīng)用程序通過系統(tǒng)調(diào)用直接觸發(fā)內(nèi)核功能. Linux系統(tǒng)包括早期Android系統(tǒng)下的自主訪問控制(DAC)通過訪問控制列表限制主體對設(shè)備數(shù)據(jù)和文件的操作.在DAC策略下，主體擁有自己的UID和GID，客體擁有允許訪問的訪問控制列表，以此來判斷主體是否與訪問的文件權(quán)限匹配，來確定主體能否訪問文件. 這種機(jī)制的缺點(diǎn)非常明顯，當(dāng)主體獲得更高的權(quán)限甚至獲得設(shè)備的root權(quán)限，就可以隨意操作任何敏感文件.

SEAndroid提供的強(qiáng)制訪問控制(MAC)針對DAC的缺陷，每個(gè)訪問文件的操作都會通過MAC的安全策略進(jìn)行判斷，違反安全策略的操作會被阻止，所有不合法的操作都會被記錄在日志里.

雖然SEAndroid依賴于可信的內(nèi)核，無法防御敵手對內(nèi)核的直接攻擊，但是SEAndroid的引入很大限度的阻止了惡意應(yīng)用對系統(tǒng)的攻擊，也有效地減小了內(nèi)核層出現(xiàn)漏洞時(shí)產(chǎn)生的威脅，針對移動設(shè)備來說在保證內(nèi)核可信的層面上能保障系統(tǒng)不被破壞.

2.3 Trustzone

TrustZone是一組用于ARM的硬件安全擴(kuò)展，主要針對高性能計(jì)算平臺上的大量應(yīng)用，包括安全支付、數(shù)字版權(quán)管理、企業(yè)服務(wù)和基于Web的服務(wù).TrustZone空間控制器可以將DRAM劃分為不同的內(nèi)存區(qū)域，并將內(nèi)存區(qū)域指定為安全或正常. TrustZone內(nèi)存適配器為OCM提供了類似的功能. 可信的DMA控制器防止將一個(gè)外圍設(shè)備分配給正常的世界，從而執(zhí)行DMA傳輸?shù)桨踩氖澜鐑?nèi)存. TrustZone保護(hù)控制器可以使外圍設(shè)備安全或正常. 這些隔離機(jī)制將所有SoC的硬件資源劃分為兩個(gè)世界：安全的世界和正常的世界. 處理器執(zhí)行的世界由一個(gè)NS位表示，它通過系統(tǒng)總線傳播. 可信的總線結(jié)構(gòu)確保了正常的世界組件無法訪問任何安全的世界資源[13]. Trustzone可以為系統(tǒng)上運(yùn)行在正常世界但由具備一定安全需求，如移動支付等程序提供隔離與正常世界的安全服務(wù). 由于Trustzone與正常世界的操作系統(tǒng)隔離的特點(diǎn)，Trustzone在系統(tǒng)安全領(lǐng)域內(nèi)多用于保護(hù)運(yùn)行時(shí)的內(nèi)核[14].

2.4 現(xiàn)有方案存在的問題

近年對于Android安全的研究，各國的研究人員都提出了可行或具備實(shí)驗(yàn)意義的優(yōu)化方案，從Android系統(tǒng)的各個(gè)角度去減少Android面對的風(fēng)險(xiǎn). 但是對于Android框架層的完整性的解決方案則相對比較少見，框架層作為Android體系內(nèi)非常重要的一層，保證其完整性是非常重要的. 雖然部分框架層的功能是作為底層向應(yīng)用層提供的接口，但是如果這部分被惡意篡改則很容易造成設(shè)備異常甚至信息泄露等危害. 而且框架層包括多種系統(tǒng)服務(wù)，移動設(shè)備的正常運(yùn)行依賴于這些系統(tǒng)服務(wù)，如果系統(tǒng)服務(wù)被修改為惡意行為的程序，對設(shè)備的以及個(gè)人數(shù)據(jù)也是很大的威脅. 所以對Android系統(tǒng)框架層完整性的保護(hù)也是不可或缺的.

3 相關(guān)工作

3.1 Android框架層

Android框架層作為應(yīng)用層和底層代碼的中間層，它封裝了規(guī)范化的模塊向應(yīng)用層提供JAVA API，同時(shí)也包含JNI方法調(diào)用底層庫函數(shù)以提供部分系統(tǒng)服務(wù)，例如CameraService和MediaPlayerService等. 其中系統(tǒng)服務(wù)與用戶的隱私數(shù)據(jù)密切相關(guān).

在Android系統(tǒng)的/system/framework目錄下主要存在三類文件：jar包、odex文件、boot.art和boot.oat.Jar包為Android部分功能提供框架層的各類庫的支持，例如在執(zhí)行am命令時(shí)會加載am.jar文件. 從Android 4.4版本起，Google向Android里移植了ART虛擬機(jī)，在5.0版本后ART虛擬機(jī)徹底代替了原先的Dalvik虛擬機(jī)，運(yùn)行ART需要該目錄下的boot.art和boot.oat兩個(gè)文件. 在Android源碼編譯時(shí)，會將部分常用公共類打包到boot.oat中; boot.art則中則包含了boot.oat中的方法代碼的指針，是ART虛擬機(jī)的啟動鏡像. 在/system/framework/oat/arm目錄下的odex文件則是編譯源碼時(shí)將部分jar包優(yōu)化生成的結(jié)果，例如在創(chuàng)建系統(tǒng)服務(wù)時(shí)會加載services.odex.

我們的目的是度量完整的Android框架層，所以/system/framework目錄下的所有文件都是我們度量的目標(biāo).

3.2 System_server與service_manager

在Android系統(tǒng)中框架層一部分功能以系統(tǒng)服務(wù)的形式提供給應(yīng)用層使用，包括窗口管理、電源相關(guān)操作等功能. 所有系統(tǒng)服務(wù)作為子線程運(yùn)行在system_server進(jìn)程中，然后再注冊到service_manager進(jìn)程中.當(dāng)應(yīng)用層想要獲取某項(xiàng)系統(tǒng)服務(wù)時(shí)需要通過service_manager得到相關(guān)系統(tǒng)服務(wù)的IBinder，然后通過IBinder與system_server中的系統(tǒng)服務(wù)通信.

Android系統(tǒng)內(nèi)核啟動之后有init進(jìn)程創(chuàng)建zygote進(jìn)程，這是Android上所有java程序的祖先，之后zygote會創(chuàng)建system_server進(jìn)程. System_server會加載系統(tǒng)服務(wù)相關(guān)的代碼并分別將各系統(tǒng)服務(wù)注冊到service_manager中，該進(jìn)程在系統(tǒng)啟動時(shí)會一直運(yùn)行直至系統(tǒng)關(guān)閉. Android系統(tǒng)的初始化過程如圖1所示.

圖1 Android系統(tǒng)初始化

對于system_server這樣的守護(hù)進(jìn)程，生命周期等同于系統(tǒng)開啟的時(shí)間，容易遭受具有針對性的進(jìn)程攻擊，例如敵手利用進(jìn)程代碼中的漏洞使進(jìn)程重定向到指定的程序，如果敵手使用已經(jīng)妥協(xié)的系統(tǒng)服務(wù)代碼替換正常的系統(tǒng)服務(wù)，將會對系統(tǒng)造成極大的影響.

3.3 國密算法

目前Android系統(tǒng)的密碼庫僅支持傳統(tǒng)密碼算法，即RSA、MD5、ECC等. 為了推廣國產(chǎn)加密系列算法，我們向Android內(nèi)核移植了運(yùn)行在內(nèi)核態(tài)下的國產(chǎn)密碼算法庫.

國密是國家密碼局認(rèn)定的國產(chǎn)密碼算法，即商用密碼. 在本文中，我們主要用到了SM2公鑰加密算法和SM3哈希算法.

SM2是使用的是ECC橢圓曲線密碼機(jī)制的公鑰密碼算法，公鑰長度為64字節(jié)，私鑰32字節(jié). SM2算法在簽名、密鑰交換方面與ECDSA、ECDH等國際標(biāo)準(zhǔn)不同，它采取了更為安全的機(jī)制. SM2算法有推薦的256位曲線作為標(biāo)準(zhǔn)曲線. SM2標(biāo)準(zhǔn)包括總則，數(shù)字簽名算法，密鑰交換協(xié)議，公鑰加密算法四個(gè)部分. 我們的實(shí)驗(yàn)中主要使用SM2簽名算法.

SM3算法是哈希算法，算法輸入為長度小于2的64次方的比特消息，填充和迭代壓縮之后生成長度為256比特的摘要. 其中使用了異或，模，模加，移位，與，或，非運(yùn)算等，并由填充、迭代、消息擴(kuò)展和壓縮函數(shù)所構(gòu)成. 由于SHA-1和MD5哈希算法在早些年已經(jīng)被證實(shí)存在碰撞攻擊的問題，這兩種算法不再是安全的哈希算法. SM3算法與SHA256具有相似的壓縮結(jié)構(gòu)，但是SM3設(shè)計(jì)的更為復(fù)雜，所以相比之下SM3哈希算法擁有更高的安全性.

3.4 進(jìn)程動態(tài)度量方法

與加載時(shí)直接對文件度量不同，動態(tài)度量的對象是進(jìn)程，度量進(jìn)程的目的是確保進(jìn)程運(yùn)行時(shí)執(zhí)行的代碼不被修改，所以需要訪問進(jìn)程空間存儲代碼段的地址[14].

Linux內(nèi)核會通過進(jìn)程描述符mm_struct來管理運(yùn)行在系統(tǒng)上的進(jìn)程，并且以start_code和end_code字段標(biāo)識進(jìn)程空間中存放運(yùn)行的代碼段的地址. 內(nèi)核需要首先獲取被度量進(jìn)程的task_struct，然后獲取mm_struct描述符，通過描述符中的start_code和end_code確定存放代碼段的線性地址，將這一部分的頁面復(fù)制到內(nèi)核空間. 使用SM3哈希算法對這一部分的頁面數(shù)據(jù)進(jìn)行計(jì)算可以得到進(jìn)程代碼段的散列值.

對于基于Linux內(nèi)核的系統(tǒng)，可以實(shí)現(xiàn)一個(gè)內(nèi)核模塊，使內(nèi)核模塊在/dev下部署一個(gè)文件設(shè)備以獲取度量請求. 系統(tǒng)啟動時(shí)批量加載模塊，模塊加載后首先獲取內(nèi)核空間中全局的task_struct鏈表頭指針，然后遍歷鏈表通過task_struct的comm成員存儲的進(jìn)程運(yùn)行的可執(zhí)行文件名找到目標(biāo)進(jìn)程的task_struct的指針.設(shè)置文件的寫入函數(shù)功能為復(fù)制代碼段頁面到內(nèi)核模塊然后計(jì)算其SM3哈希值與上一次計(jì)算的值作比較.

3.5 DM-verity

Android4.4引入了VerityBoot新特性，DMverity在其中用于安全啟動時(shí)校驗(yàn)系統(tǒng)分區(qū). DMverity是基于Linux內(nèi)核中提供的一種從邏輯設(shè)備到物理設(shè)備的映射框架device mapper為系統(tǒng)分區(qū)創(chuàng)建哈希樹實(shí)現(xiàn)的. 它將系統(tǒng)鏡像劃分成4 k大小的塊，并為每個(gè)塊計(jì)算SHA256哈希值，以這些塊作為葉子結(jié)點(diǎn)，然后將這些哈希值組合成以4 k大小的為單位的塊形成了第一層，然后再將這一層的塊進(jìn)行哈希填充到4 k大小的塊中形成第二層，然后重復(fù)上述操作知道所有哈希值能填充到一個(gè)塊內(nèi)，形成一個(gè)哈希樹. 這樣一個(gè)葉子結(jié)點(diǎn)存儲的數(shù)據(jù)變化就可以通過它的父節(jié)點(diǎn)到根節(jié)點(diǎn)的哈希值來描述.

DM-verity能夠在開機(jī)時(shí)驗(yàn)證系統(tǒng)分區(qū)的完整性，但這種方案只能保證系統(tǒng)分區(qū)中框架層組件存儲時(shí)的完整性，即靜態(tài)完整性. 而且由于目前很多廠商訂制Android系統(tǒng)時(shí)會為了提高開機(jī)速度等原因關(guān)閉DMverity功能所以我們需要其他的方案來保護(hù)框架層組建的完整性.

4 方案設(shè)計(jì)

4.1 敵手模型

在我們方案中認(rèn)為框架層會受到如下兩種較為具有嚴(yán)重破壞性的攻擊：

1) 本文利用完整性度量方案為Android系統(tǒng)提供框架層的完整性保護(hù)，因此假設(shè)敵手具備修改、替換Android框架層文件的能力. Android系統(tǒng)的DMverity機(jī)制能保證系統(tǒng)在啟動時(shí)校驗(yàn)系統(tǒng)分區(qū)的完整性，但是可以假設(shè)敵手具備在校驗(yàn)完成之后修改框架層的文件，這樣即使分區(qū)校驗(yàn)可以正常進(jìn)行但是在系統(tǒng)創(chuàng)建zygote進(jìn)程時(shí)依然具備調(diào)用惡意的框架層代碼的可能性.

2) Android系統(tǒng)運(yùn)行時(shí)框架層的作用體現(xiàn)在系統(tǒng)服務(wù)，在系統(tǒng)啟動時(shí)init進(jìn)程會在創(chuàng)建zygote之前先fork出service_manager進(jìn)程用于管理系統(tǒng)服務(wù)，之后再由zygote進(jìn)程孵化出system_server進(jìn)程，Android的系統(tǒng)服務(wù)以多線程的形式則運(yùn)行在system_server進(jìn)程中. 在本文中，我們假設(shè)敵手在系統(tǒng)正常引導(dǎo)啟動之后，在系統(tǒng)運(yùn)行時(shí)有能力篡改system_server進(jìn)程正在運(yùn)行的程序或者向該進(jìn)程注入惡意代碼.

上述兩種手段都能達(dá)到破壞Android系統(tǒng)框架層完整性的目的，敵手可以使系統(tǒng)運(yùn)行存在漏洞的系統(tǒng)服務(wù)然后通過已知的漏洞提權(quán)或者竊取用戶信息等操作.

4.2 詳細(xì)設(shè)計(jì)

4.2.1 整體架構(gòu)

本框架層完整性保護(hù)方案的目標(biāo)是從編譯Android源碼得到鏡像到框架層組件加載以及整個(gè)運(yùn)行過程三個(gè)過程去全方位的保障框架層的完整性. 總體架構(gòu)框圖如圖2所示.

圖2 FIMM整體架構(gòu)

架構(gòu)組件介紹：

Framework.sign：系統(tǒng)鏡像編譯時(shí)，記錄對framework下的框架層組件使用SM3哈希算法計(jì)算得到的哈希值組成白名單并使用SM2算法簽名過后的打包文件;

白名單：由framework.sign得到的framework文件對應(yīng)的哈希值列表，由于是通過SM3哈希算法計(jì)算文件的摘要，所以文件一旦被敵手修改那么再使用哈希算法計(jì)算出來的值一定不同，完整性度量時(shí)以本文件中的哈希值為基準(zhǔn);

Framework：/system/framework目錄下的框架層文件，包括jar包、odex文件、boot.art以及boot.oat;

應(yīng)用層度量代理：運(yùn)行在應(yīng)用層，APP在使用系統(tǒng)服務(wù)時(shí)向其產(chǎn)生一個(gè)度量請求，之后向內(nèi)核中的系統(tǒng)服務(wù)度量模塊發(fā)起挑戰(zhàn)，等待接收內(nèi)核模塊處理完度量請求后得到度量結(jié)果并將校驗(yàn)結(jié)果返回到APP;

SSVERITY：在部署進(jìn)內(nèi)核之后會在/proc虛擬文件系統(tǒng)下生成一個(gè)文件節(jié)點(diǎn)，用于接收度量代理發(fā)起的挑戰(zhàn);

組件度量模塊：框架層組件在加載時(shí)，由該模塊計(jì)算加載的文件的哈希值并校驗(yàn)其完整性.

4.2.2 安全啟動的改良方案

FIMM源碼在編譯過程成中會對編譯生成的框架層文件(system/framework/)，我們在源碼中添加腳本，使用SM3哈希算法計(jì)算框架層文件的哈希值并生成白名單，之后使用SM2私鑰對白名單進(jìn)行簽名然后將白名單和簽名文件一同打包至系統(tǒng)鏡像中. 這個(gè)過程需要在out/root/system/framework目錄中的所有文件都生成之后，在system_img鏡像文件生成之前執(zhí)行; 或者在源碼編譯結(jié)束后編寫腳本將framework.sign文件在out/root/目錄下生成然后再次編譯Android源碼即可.

FIMM系統(tǒng)的啟動過程中會在DM-Verity驗(yàn)證系統(tǒng)分區(qū)完整性并掛載文件系統(tǒng)之后使用硬編碼進(jìn)內(nèi)核代碼中的SM2公鑰驗(yàn)證簽名文件，如果驗(yàn)證成功則將框架層的白名單加載進(jìn)內(nèi)核空間中，如果驗(yàn)證不通過則表示本系統(tǒng)已被敵手入侵不可正常啟動. 由于簽名文件中包括原白名單以及簽名信息，如果其中任意一部分被修改過那么都無法通過SM2公鑰驗(yàn)簽通過，這樣可保證系統(tǒng)在啟動時(shí)加載的框架層完整性信息以及簽名一定是未被篡改過的.

內(nèi)核的驗(yàn)簽?zāi)K作為FIMM安全啟動的一個(gè)環(huán)節(jié)，它以一個(gè)內(nèi)核模塊的形式編譯在內(nèi)核中，并生成一個(gè)文件節(jié)點(diǎn)用于啟動其驗(yàn)簽功能. 正常情況下該模塊不提供任何服務(wù)，當(dāng)通過文件結(jié)點(diǎn)觸發(fā)其功能后，它會調(diào)用國密算法庫提供的SM2算法驗(yàn)證/system/framework.sign的簽名，如果驗(yàn)簽通過那么將框架層組件的哈希值保存到內(nèi)核空間中，否則重啟系統(tǒng). Linux內(nèi)核正常引導(dǎo)之后，由init進(jìn)程掛載文件系統(tǒng)，我們使init進(jìn)程在掛載上系統(tǒng)分區(qū)之后運(yùn)行通知程序以觸發(fā)內(nèi)核的驗(yàn)簽?zāi)K. 通知程序只需要向驗(yàn)簽?zāi)K部署的文件結(jié)點(diǎn)寫入對應(yīng)的字符指令即可. 可以通過修改init.rc等文件使init進(jìn)程在正確的時(shí)刻運(yùn)行通知程序.

4.2.3 框架層加載時(shí)度量

FIMM的內(nèi)核在掛載系統(tǒng)分區(qū)之后就會保存框架層文件的完整性度量值，接下來需要在每次加載/system/framework中的組件時(shí)對其度量.

我們通過修改Linux內(nèi)核的IMA[15]來實(shí)現(xiàn)這個(gè)功能. IMA是一種開源可信計(jì)算組件. IMA維護(hù)一個(gè)運(yùn)行時(shí)度量列表，如果將其保存到一個(gè)硬件可信平臺模塊(TPM)中，則該列表上的聚合完整性值. 在TPM中保存聚合完整性值的好處是度量列表不會被任何軟件攻擊破壞，并且不會被檢測到. 因此，在可信的引導(dǎo)系統(tǒng)上，可以使用IMA度量來驗(yàn)證系統(tǒng)的運(yùn)行時(shí)完整性.Android平臺大多沒有TPM的支持，我們只是使用IMA加載時(shí)度量的模塊. IMA現(xiàn)有的功能可以當(dāng)系統(tǒng)上的文件在加載進(jìn)內(nèi)存時(shí)計(jì)算其散列值然后記錄到日志中，我們通過重構(gòu)IMA部分代碼，使IMA使用sm3算法只度量/system/framework目錄下的文件，得到哈希值后即可利用前一節(jié)獲取的白名單進(jìn)行對比，如果對比出現(xiàn)錯(cuò)誤則表示這個(gè)文件已經(jīng)被敵手篡改.

在系統(tǒng)中有文件加載進(jìn)內(nèi)存時(shí)我們這個(gè)模塊能獲取文件的描述符，我們首先通過文件路徑和格式判斷其是否為框架層組件，如果不是則使其正常工作; 如果判斷為框架層組件，我們首先使用密碼算法模塊中的SM3哈希算法計(jì)算整個(gè)文件的哈希值，然后使用已存入內(nèi)核空間的白名單進(jìn)行校驗(yàn)，如果校驗(yàn)成功，即文件的度量值與剛計(jì)算得到的哈希值相同則正常啟動; 如果校驗(yàn)失敗，我們可以進(jìn)行錯(cuò)誤處理流程，可以選擇向應(yīng)用層發(fā)起警告，安全要求更高設(shè)備可以選擇kill掉調(diào)用該組件的進(jìn)程，我們的實(shí)驗(yàn)中選擇使用netlink機(jī)制向應(yīng)用層廣播設(shè)備被入侵的警告.

以FIMM系統(tǒng)從引導(dǎo)內(nèi)核到提供系統(tǒng)服務(wù)的整個(gè)過程為例，運(yùn)行流程如圖3所示.

圖3 FIMM啟動過程

4.2.4 系統(tǒng)服務(wù)的實(shí)時(shí)度量

系統(tǒng)服務(wù)作為框架層比較特殊的一部分，系統(tǒng)zygote進(jìn)程創(chuàng)建出system_server進(jìn)程時(shí)會加載系統(tǒng)服務(wù)，然后將服務(wù)注冊到service_manager進(jìn)程中，一般來說在系統(tǒng)啟動之后框架層組件就會持續(xù)運(yùn)行直到系統(tǒng)關(guān)閉. 上述方案可以保證在Android系統(tǒng)啟動到加載框架層組件的過程中保證其完整性，但是對于系統(tǒng)服務(wù)這種一次加載就運(yùn)行至系統(tǒng)關(guān)閉的組件僅僅在加載時(shí)度量其完整性不能很好的保證系統(tǒng)不遭受敵手的攻擊，即容易遭受TOU-TOC攻擊. 需要更細(xì)粒度的度量方案，保證框架層在運(yùn)行時(shí)的完整性.Android應(yīng)用層通過Context.getSystemService()方法調(diào)用system_server進(jìn)程中的系統(tǒng)服務(wù). 在調(diào)用系統(tǒng)服務(wù)之前先通過FIMM中的度量代理對system_server進(jìn)程進(jìn)行動態(tài)度量，確認(rèn)其完整性. FIMM一次系統(tǒng)服務(wù)調(diào)用過程如圖4所示.

圖4 系統(tǒng)服務(wù)實(shí)時(shí)度量

應(yīng)用層度量代理是運(yùn)行在應(yīng)用層，應(yīng)用層軟件(如APP、桌面顯示等)在使用系統(tǒng)服務(wù)時(shí)向其產(chǎn)生一個(gè)度量請求，之后向內(nèi)核中的系統(tǒng)服務(wù)度量模塊發(fā)起挑戰(zhàn)，等待接收內(nèi)核模塊處理完度量請求后得到度量結(jié)果并將校驗(yàn)結(jié)果返回到APP. 應(yīng)用層度量代理實(shí)現(xiàn)為Android源碼中的一個(gè)java類，通過jni方式調(diào)用C程序?qū)崿F(xiàn)的本地方法去向SSVerity控制的文件結(jié)點(diǎn)寫入度量請求并提供三字節(jié)的緩存區(qū)存儲SSVerity的完整性度量結(jié)果，在發(fā)起挑戰(zhàn)之后進(jìn)入自旋檢查緩存區(qū)，得到完整性度量結(jié)果之后返回，如果度量結(jié)果無誤則正常執(zhí)行system.getSystemService()的流程，如果度量出現(xiàn)錯(cuò)誤則向用戶發(fā)出警告.

SSVerity在部署進(jìn)內(nèi)核之后會在/proc虛擬文件系統(tǒng)下生成一個(gè)名為SSVerity的文件節(jié)點(diǎn)，用于接收度量代理發(fā)起的挑戰(zhàn). 內(nèi)核模塊會維護(hù)一個(gè)用來獲取system_server進(jìn)程信息的描述符，在接受到挑戰(zhàn)時(shí)首先檢查該進(jìn)程描述符是否為system_server，如果不是則需要在進(jìn)程鏈表中尋找到system_server的描述符，然后獲取進(jìn)程對應(yīng)的代碼段的線性地址，通過線性地址將該進(jìn)程的代碼段頁面拷貝到內(nèi)核空間，然后使用SM3哈希算法計(jì)算代碼段的散列值，使用內(nèi)核模塊維護(hù)的完整性值校驗(yàn)，將校驗(yàn)結(jié)果返回到度量代理.

當(dāng)度量代理向SSVerity部署的文件結(jié)點(diǎn)寫入度量挑戰(zhàn)時(shí)，SSVerity首先檢查模塊當(dāng)前定位的進(jìn)程是否為system_server，如果不是則需要在內(nèi)核的進(jìn)程鏈表中查找出system_server的task_struct并將該描述符的指針保存在SSVerity模塊中. 通過system_server的task_struct獲取其mm_struct成員的指針，再通過mm_struct的start_code和end_code得到system_server進(jìn)程代碼段的線性地址，然后將這部分頁面復(fù)制到SSVerity的內(nèi)核空間中然后使用國密算法模塊提供的SM3哈希算法計(jì)算代碼段的256位哈希值，與內(nèi)核空間中保存的度量值對比. 如果內(nèi)存中的度量值全為0則表示這是第一次度量系統(tǒng)服務(wù)，那么將哈希值寫入SSVerity維護(hù)的度量值中，并判定為校驗(yàn)正確; 如果計(jì)算得到的哈希值與內(nèi)核空間中的度量值相同那么判定為校驗(yàn)正確; 如果內(nèi)核空間中的度量值不全為0且與哈希值不相同那么表示system_server進(jìn)程空間中的代碼段被修改，判定為校驗(yàn)失敗. 校驗(yàn)結(jié)束后SSVerity將對應(yīng)的結(jié)果寫入度量代理預(yù)留的3字節(jié)緩存中，一次系統(tǒng)服務(wù)度量結(jié)束.

應(yīng)用程序在調(diào)用Context.getSystemService()獲取系統(tǒng)服務(wù)的時(shí)候先向度量代理發(fā)起系統(tǒng)服務(wù)度量請求，再由度量代理向部署在內(nèi)核的系統(tǒng)服務(wù)度量模塊發(fā)起挑戰(zhàn)，此時(shí)該內(nèi)核模塊會動態(tài)度量system_server進(jìn)程代碼段的完整性并進(jìn)行校驗(yàn)，校驗(yàn)通過之后執(zhí)行正常的Android系統(tǒng)服務(wù)調(diào)用流程.

由于SEAndroid會限制各進(jìn)程對SSVerity文件的訪問，所以需要在編譯FIMM源碼之前修改SEAndroid的訪問策略，使所有進(jìn)程都具備讀寫SSVerity的權(quán)限.在本實(shí)驗(yàn)中SEAndroid不是我們考慮的重點(diǎn)，所以我們修改了啟動設(shè)置，使系統(tǒng)啟動時(shí)關(guān)閉了SEAndroid.

5 實(shí)驗(yàn)結(jié)果評估

本文實(shí)現(xiàn)了FIMM系統(tǒng)原型，實(shí)驗(yàn)環(huán)境是Intel(R)Core(TM) i7-6700 CPU@3.40 GHz處理器和16 GB內(nèi)存的PC上的Linux ubuntu. 在這個(gè)平臺上，本文首先搭建了Android 6.0 arm的運(yùn)行環(huán)境，在該版本的Android源碼上搭建了FIMM的原型，如圖5.

圖5 FIMM原型

5.1 安全性評估

對于4.1節(jié)提到的敵手模型1，假設(shè)敵手root了設(shè)備并在系統(tǒng)啟動之后用某個(gè)有漏洞的框架層組件替換了設(shè)備上正確的組件，想使應(yīng)用程序使用這個(gè)帶有漏洞的組件，然后利用這個(gè)漏洞攻擊應(yīng)用程序. 系統(tǒng)在需要使用該組件時(shí)會調(diào)用mmap()系統(tǒng)調(diào)用將該文件映射到內(nèi)存，但是在這之前FIMM會計(jì)算這個(gè)文件的SM3哈希值，而且由于FIMM系統(tǒng)正常啟動，所以現(xiàn)在內(nèi)核中保存有這個(gè)文件對應(yīng)的哈希值，之后FIMM會對比計(jì)算出來的哈希值是否與保存的值相同，由于敵手使用其他版本的組件替換了正常的組件，那么現(xiàn)在計(jì)算出來的哈希值必然與內(nèi)核保存的哈希值不同，按照FIMM的策略不允許其繼續(xù)執(zhí)行，拋出調(diào)用錯(cuò)誤并發(fā)起警報(bào).

而對于敵手模型2，假設(shè)敵手為了修改system_server進(jìn)程正在運(yùn)行的程序，首先使用惡意進(jìn)程偽裝成目標(biāo)進(jìn)程欺騙操作系統(tǒng)，以此獲得修改system_server進(jìn)程地址空間內(nèi)容修改的權(quán)限，然后修改進(jìn)程空間存放代碼段的頁面屬性，最后修改代碼段頁面的頁面內(nèi)容使進(jìn)程運(yùn)行惡意的程序. 在FIMM中，每次系統(tǒng)服務(wù)的調(diào)用都會出發(fā)內(nèi)核的系統(tǒng)服務(wù)進(jìn)程檢驗(yàn)機(jī)制，它會計(jì)算system_server進(jìn)程空間代碼段的SM3哈希值并且和之前得到的結(jié)果對比，所以當(dāng)敵手實(shí)施攻擊之后的下一次系統(tǒng)服務(wù)調(diào)用一定會發(fā)現(xiàn)系統(tǒng)服務(wù)進(jìn)程被敵手攻擊.

綜上所述，F(xiàn)IMM完全能夠預(yù)防我們在4.1節(jié)中提出的Android框架層可能受到的攻擊.

5.2 效率評估

對于動態(tài)度量系統(tǒng)服務(wù)的方案，其性能影響之處在于每次通過Context.getSystemService()方法獲取系統(tǒng)調(diào)用的時(shí)候都需要對system_server進(jìn)程的代碼段進(jìn)行哈希運(yùn)算，所以對于應(yīng)用程序的影響主要取決于程序調(diào)用系統(tǒng)服務(wù)的次數(shù). 本文中我們對Android 6.0.0系統(tǒng)的五個(gè)系統(tǒng)APP的開機(jī)時(shí)間進(jìn)行了測試，一定程度反映了本度量方案對操作系統(tǒng)的影響，開機(jī)時(shí)間采用多次啟動取平均值的方法，對比結(jié)果如表1所示.

表1 實(shí)驗(yàn)結(jié)果對比

由于本文實(shí)驗(yàn)是在ubuntu上搭建的Android模擬器上進(jìn)行，不能精確的得到性能損耗的具體值. 通過表我們可以看出使用FIMM和未使用FIMM會造成大約15%的性能損耗，這個(gè)結(jié)果在預(yù)期范圍內(nèi)的，對于系統(tǒng)運(yùn)行時(shí)只是在系統(tǒng)調(diào)用過程中增加了進(jìn)程空間代碼段的頁面復(fù)制以及一次SM3哈希運(yùn)算.

6 總結(jié)與下一步工作

在本文中，我們提出一種針對Android框架層的完整性度量方案. 我們的方案使用源碼編譯時(shí)生成的白名單為基準(zhǔn)對一般的框架層文件采用加載時(shí)度量，對運(yùn)行周期長的系統(tǒng)服務(wù)采用細(xì)粒度的動態(tài)度量，力求在系統(tǒng)應(yīng)用層與框架層交互時(shí)能保證其完整性. 通過安全評估可以了解到FIMM完全可以檢驗(yàn)系統(tǒng)框架層是否受到破壞. 實(shí)驗(yàn)表明，本方案主要對系統(tǒng)服務(wù)請求次數(shù)頻繁的APP造成的一定的性能影響，但是這種細(xì)粒度的度量方式可以更加有效的保護(hù)系統(tǒng)服務(wù). 但FIMM仍然存在缺陷，F(xiàn)IMM是完全基于內(nèi)核的保護(hù)方案，即通過內(nèi)核層來保護(hù)Android框架層，不對內(nèi)核層進(jìn)行安全加固，如果內(nèi)核被攻破本方案的功能就不具備意義. 考慮到Android內(nèi)核面臨的安全風(fēng)險(xiǎn)，因此下一階段可以采用內(nèi)核與TrustZone結(jié)合的方法為框架層提供完整性保護(hù)，或者使用基于TrustZone的內(nèi)核保護(hù)方案為FIMM提供內(nèi)核的完整性保護(hù).