一種嵌入式Linux系統(tǒng)上的新型完整性度量架構(gòu)

賈巧雯 馬昊玉 厲 嚴(yán) 王哲宇 石文昌

1(中國(guó)科學(xué)院軟件研究所 北京 100190) 2(中國(guó)科學(xué)院大學(xué) 北京 100049) 3(西安電子科技大學(xué)網(wǎng)絡(luò)與信息安全學(xué)院 西安 710126) 4(中國(guó)人民大學(xué)信息學(xué)院 北京 100872)

長(zhǎng)期以來(lái)，基于漏洞利用和惡意代碼的攻擊一直是計(jì)算機(jī)軟件與操作系統(tǒng)安全所面臨的主要威脅之一.在各類計(jì)算機(jī)系統(tǒng)當(dāng)中，嵌入式操作系統(tǒng)(如車載系統(tǒng)、部分互聯(lián)網(wǎng)關(guān)鍵節(jié)點(diǎn)和一些能源/制造業(yè)關(guān)鍵設(shè)備等)，以及在該類平臺(tái)上運(yùn)行的應(yīng)用軟件，是漏洞利用和惡意代碼攻擊所關(guān)注的高價(jià)值目標(biāo).因此，建立針對(duì)嵌入式操作系統(tǒng)的可信計(jì)算平臺(tái)，對(duì)于推進(jìn)面向未來(lái)的互聯(lián)網(wǎng)安全生態(tài)有著重要的意義.

1)完整性度量架構(gòu)及其研究現(xiàn)狀

在與漏洞利用及其后續(xù)可能發(fā)起的惡意代碼植入攻擊的對(duì)抗中，完整性度量架構(gòu)(integrity mea-surement architecture, IMA)是為計(jì)算平臺(tái)可信性提供保護(hù)的重要技術(shù)之一.2004年，文獻(xiàn)[1]采用了IMA的概念，并提出了一種以可信計(jì)算組織(trusted computing group, TCG)規(guī)范(1)TCG Specification Architecture Overview Revision 1.4, https://trustedcomputinggroup.org/wp-content/uploads/TCG_1_4_Architecture_Overview.pdf為基礎(chǔ)的IMA方案.在此方案基礎(chǔ)上，后續(xù)研究通過(guò)引入權(quán)限分級(jí)的訪問(wèn)控制策略或采用經(jīng)過(guò)哈希運(yùn)算和加密處理的壓縮度量值等方式[2-3]，進(jìn)一步降低了實(shí)施IMA對(duì)系統(tǒng)負(fù)載的壓力，形成了多種較為完備的靜態(tài)完整性度量方法.然而，基于文件的完整性度量機(jī)制僅能夠在文件加載至內(nèi)存時(shí)驗(yàn)證其當(dāng)前完整性狀態(tài)，這使得該類IMA系統(tǒng)無(wú)法對(duì)針對(duì)內(nèi)存的運(yùn)行時(shí)完整性損害予以響應(yīng)，包括：

① 針對(duì)駐留內(nèi)存的代碼文本的篡改行為.如基于hooking的控制流篡改、自修改代碼(self-modifying code)等.

② 不依賴靜態(tài)文件、直接向內(nèi)存注入惡意代碼的攻擊行為.例如，利用緩沖區(qū)溢出漏洞、以數(shù)據(jù)形態(tài)注入惡意代碼、再借助代碼重用攻擊(code-reuse attack)修改頁(yè)面權(quán)限使所注入代碼可被執(zhí)行的惡意代碼動(dòng)態(tài)載入攻擊.

因此，動(dòng)態(tài)完整性度量架構(gòu)作為一種改進(jìn)策略被提出[4-10].現(xiàn)有該類方案往往利用系統(tǒng)內(nèi)核機(jī)制(如Linux系統(tǒng)的內(nèi)核全鏡像機(jī)制[6])或特定硬件(如輔助處理器[7])的支持，對(duì)駐留在內(nèi)存中的系統(tǒng)關(guān)鍵完整性狀態(tài)進(jìn)行運(yùn)行時(shí)驗(yàn)證.除了系統(tǒng)內(nèi)核的代碼文本外，一些方案還支持對(duì)系統(tǒng)中各進(jìn)程所維護(hù)的關(guān)鍵上下文狀態(tài)和環(huán)境參數(shù)的完整性予以監(jiān)控[8-10]，或通過(guò)與用戶態(tài)進(jìn)程的交互實(shí)現(xiàn)對(duì)其運(yùn)行時(shí)完整性的驗(yàn)證[6,8,10].目前，IMA技術(shù)已經(jīng)被擴(kuò)展應(yīng)用至基于hypervisor的虛擬化環(huán)境[11-13]、軟件虛擬機(jī)[14-15]以及軟件控制流完整性驗(yàn)證(control flow integrity, CFI)[16]等多個(gè)有關(guān)系統(tǒng)完整性驗(yàn)證的安全應(yīng)用場(chǎng)景中.

近兩年來(lái)，一些針對(duì)嵌入式設(shè)備及系統(tǒng)的動(dòng)態(tài)完整性度量架構(gòu)方案被陸續(xù)提出[17-21].Wehbe等人[17]利用獨(dú)立硬件芯片對(duì)嵌入式系統(tǒng)各進(jìn)程內(nèi)的可執(zhí)行文本實(shí)施基于頁(yè)面的運(yùn)行時(shí)度量和驗(yàn)證.Qin等人[18]和Ling等人[19]各自提出了一種基于可信執(zhí)行環(huán)境(trusted execution environment, TEE)的物聯(lián)網(wǎng)設(shè)備運(yùn)行時(shí)完整性保護(hù)系統(tǒng).其中，文獻(xiàn)[18]通過(guò)代碼插樁攔截用戶進(jìn)程發(fā)起的函數(shù)調(diào)用及其返回等控制流行為，并在提供代碼完整性驗(yàn)證的同時(shí)支持CFI功能；文獻(xiàn)[19]則在TrustZone機(jī)制的支持下周期性地對(duì)用戶代碼實(shí)施基于頁(yè)面的完整性度量.Duan等人[20]提出了一種基于TEE虛擬化架構(gòu)的系統(tǒng)完整性度量方案，通過(guò)在TEE-visor層部署度量組件，實(shí)現(xiàn)同時(shí)對(duì)多個(gè)虛擬TEE環(huán)境以及正常執(zhí)行環(huán)境內(nèi)的系統(tǒng)代碼和系統(tǒng)調(diào)用的可信完整性校驗(yàn).Cheng等人[21]提出了一種針對(duì)航空片上系統(tǒng)(system-on-a-chip, SoC)的可信控制架構(gòu)，通過(guò)專用的監(jiān)控硬件架構(gòu)為系統(tǒng)提供動(dòng)態(tài)完整性度量保護(hù).

然而，現(xiàn)有動(dòng)態(tài)/靜態(tài)IMA方案在應(yīng)用于計(jì)算資源有限、同時(shí)又對(duì)運(yùn)行性能較為敏感的嵌入式設(shè)備時(shí)，往往存在3方面的局限性：

① 針對(duì)位置無(wú)關(guān)代碼所依賴的重定位和動(dòng)態(tài)鏈接信息，現(xiàn)有IMA方案缺乏有效的校驗(yàn)策略.以Linux為例，其ELF文件的重定位由過(guò)程鏈接表(procedure linkage table, PLT)和全局偏移表(global offset table, GOT)配合完成.其中，GOT由動(dòng)態(tài)鏈接器在文件加載時(shí)實(shí)時(shí)填充，全過(guò)程均在用戶態(tài)完成，這使得針對(duì)GOT的完整性度量問(wèn)題成為IMA技術(shù)的一個(gè)兩難困境：若嚴(yán)格服從權(quán)限隔離原則并將IMA部署于內(nèi)核空間或可信平臺(tái)模塊(trusted platform module, TPM)中，則將因缺乏適當(dāng)?shù)膽B(tài)勢(shì)感知手段而難以及時(shí)地捕捉到用戶進(jìn)程中文件重定位和動(dòng)態(tài)鏈接行為的發(fā)生時(shí)機(jī)，因而無(wú)法及時(shí)算得GOT載入完成后的完整性基線、難以實(shí)現(xiàn)對(duì)其進(jìn)行動(dòng)態(tài)完整性驗(yàn)證的目標(biāo)；反之，若在用戶進(jìn)程空間內(nèi)部署輔助接口、以插樁動(dòng)態(tài)鏈接器等方式直接在用戶空間內(nèi)攔截動(dòng)態(tài)鏈接行為并為GOT生成完整性基線，又將不可避免地將負(fù)責(zé)實(shí)施該功能的IMA組件直接暴露在攻擊者視野中，使得IMA架構(gòu)的整體可信任性產(chǎn)生瑕疵.

② 現(xiàn)有IMA方案無(wú)法與包括代碼熱修復(fù)(hot-fix)在內(nèi)的一些特殊的運(yùn)行時(shí)代碼加載/改寫場(chǎng)景實(shí)現(xiàn)有效的兼容.具體來(lái)說(shuō)，由于主流代碼熱修復(fù)方法在實(shí)現(xiàn)原理上與基于hooking的惡意代碼動(dòng)態(tài)載入基本一致，僅憑通用的常規(guī)技術(shù)無(wú)法將兩者加以區(qū)分.這意味著應(yīng)用IMA功能的系統(tǒng)可能無(wú)法同時(shí)啟用熱修復(fù)機(jī)制，這將有可能嚴(yán)重地限制系統(tǒng)對(duì)0-day漏洞的應(yīng)急響應(yīng)能力.

③ 對(duì)于嵌入式系統(tǒng)而言，現(xiàn)有IMA造成的性能開銷往往超出了工程實(shí)踐可以接受的范疇.例如，文獻(xiàn)[18]引入了細(xì)粒度動(dòng)態(tài)插樁和CFI等保護(hù)機(jī)制，使得單個(gè)應(yīng)用程序由此承受了十幾甚至上百倍的運(yùn)行時(shí)性能開銷.文獻(xiàn)[17]和文獻(xiàn)[19]所采用的基于頁(yè)面的完整性度量機(jī)制則占用了大量運(yùn)行內(nèi)存空間以維護(hù)針對(duì)具體內(nèi)存頁(yè)面的完整性基線.以glibc為例，該基本系統(tǒng)庫(kù)的2.3.2版本在加載后的代碼段大小為1 208 KB，對(duì)應(yīng)302個(gè)頁(yè)面，在考慮使用SHA256等安全哈希算法的情況下，僅該系統(tǒng)庫(kù)一例，即需要占用9 KB內(nèi)存以維護(hù)其代碼完整性基線，這還未將運(yùn)行時(shí)如何實(shí)現(xiàn)對(duì)海量基線的索引問(wèn)題納入考慮范疇.由于嵌入式系統(tǒng)受到物理約束的限制，所能夠利用的硬件資源，包括CPU主頻、CPU核心數(shù)量、運(yùn)行內(nèi)存大小等往往極為有限，并需要在滿足最小軟硬件需求的情況下保證實(shí)時(shí)性.故在性能開銷方面，多數(shù)嵌入式系統(tǒng)很可能并不具備現(xiàn)有的大多數(shù)IMA方案所需的擴(kuò)展空間.

2)創(chuàng)新點(diǎn)與貢獻(xiàn)

針對(duì)現(xiàn)有IMA方案存在的完備性不足、無(wú)法兼容軟件熱修復(fù)、性能開銷較大等問(wèn)題，本文提出了一種應(yīng)用于嵌入式Linux系統(tǒng)的高性能內(nèi)核級(jí)動(dòng)態(tài)完整性度量架構(gòu)(dymamic integrity measurement architecture at kernel-level, DIMAK).利用Linux內(nèi)核自身定義的進(jìn)程空間和頁(yè)面管理機(jī)制，DIMAK將自身組件完全部署在系統(tǒng)內(nèi)核空間，并通過(guò)攔截與代碼加載/改寫行為、進(jìn)程創(chuàng)建行為以及系統(tǒng)shell命令執(zhí)行有關(guān)的關(guān)鍵系統(tǒng)調(diào)用等方式，實(shí)現(xiàn)以虛擬地址映射分段為基本度量單元、面向運(yùn)行內(nèi)存而非文件存儲(chǔ)的運(yùn)行時(shí)完整性驗(yàn)證.根據(jù)進(jìn)程參數(shù)、代碼文本、重定位和動(dòng)態(tài)鏈接數(shù)據(jù)等各種被度量實(shí)體所具有的不同初始化時(shí)機(jī)，DIMAK確立了一套動(dòng)態(tài)/靜態(tài)基線相結(jié)合、基于最小信任根的逐級(jí)信任擴(kuò)展策略.在上述底層設(shè)計(jì)基礎(chǔ)上，DIMAK方案的一個(gè)核心創(chuàng)新點(diǎn)在于提出了一種內(nèi)核級(jí)的“進(jìn)取型動(dòng)態(tài)鏈接預(yù)測(cè)技術(shù)”，使其能夠在不暴露于用戶空間且無(wú)需動(dòng)態(tài)鏈接器主動(dòng)配合的情況下正確地計(jì)算出用戶態(tài)位置無(wú)關(guān)代碼所對(duì)應(yīng)重定位和動(dòng)態(tài)鏈接信息的完整性基線.這一機(jī)制允許DIMAK在與用戶空間保持完全權(quán)限隔離的情況下，將針對(duì)用戶進(jìn)程的完整性保護(hù)擴(kuò)展到與可執(zhí)行行為完整性相關(guān)的所有要素上，從而實(shí)現(xiàn)了現(xiàn)有方案無(wú)法達(dá)成的高度完備性.此外，DIMAK的另一個(gè)關(guān)鍵創(chuàng)新點(diǎn)是將軟件熱修復(fù)行為納入系統(tǒng)內(nèi)核的標(biāo)準(zhǔn)內(nèi)存管理，從而在完整性驗(yàn)證過(guò)程中有效地將該場(chǎng)景與惡意代碼篡改行為加以區(qū)分.通過(guò)提供專用系統(tǒng)調(diào)用，DIMAK以其內(nèi)核態(tài)組件接管了軟件熱修復(fù)過(guò)程中所涉及的補(bǔ)丁代碼加載、被修復(fù)程序改寫等工作，確保所涉及的完整性基線能夠被及時(shí)地生成和更新，實(shí)現(xiàn)了將軟件熱修復(fù)納入系統(tǒng)運(yùn)行時(shí)信任依賴的范疇中這一安全目標(biāo).

簡(jiǎn)而言之，本文所述DIMAK方案的主要?jiǎng)?chuàng)新性貢獻(xiàn)可總結(jié)為：

① 在技術(shù)層面上.DIMAK通過(guò)其進(jìn)取型動(dòng)態(tài)鏈接預(yù)測(cè)技術(shù)，解決了過(guò)往IMA方案因缺乏針對(duì)重定位和動(dòng)態(tài)鏈接信息的完整性基線獲取手段而存在的完備性缺陷，即無(wú)法完全部署在內(nèi)核態(tài).

② 在工程層面上.DIMAK在不損害系統(tǒng)安全性的前提下，實(shí)現(xiàn)了IMA方案對(duì)代碼熱修復(fù)場(chǎng)景的支持，在實(shí)用安全性能方面實(shí)現(xiàn)了零的突破.

模擬環(huán)境和真機(jī)測(cè)試顯示，DIMAK主要工作于系統(tǒng)日常運(yùn)行過(guò)程中占比極低的代碼加載階段，故其運(yùn)行時(shí)總體性能開銷和內(nèi)存占用均顯著低于現(xiàn)有同類方案，并能良好地適應(yīng)嵌入式設(shè)備可能具有的硬件配置情況.

1 威脅模型與安全目標(biāo)

現(xiàn)有各類IMA方案在適配嵌入式系統(tǒng)時(shí)所存在的一些實(shí)用性方面的不足，究其原因，在于當(dāng)前針對(duì)IMA等可信計(jì)算概念的研究往往傾向于設(shè)置越來(lái)越高的安全目標(biāo)以使得所設(shè)計(jì)的方案能夠“兼容并包”地對(duì)抗多種類型的威脅對(duì)手.為此，相關(guān)方案不斷引入開銷較大的度量機(jī)制，所采用的度量策略則向著高度實(shí)時(shí)、細(xì)粒度化的方向發(fā)展[9-10,18].然而，不同于通用系統(tǒng)，嵌入式系統(tǒng)的應(yīng)用場(chǎng)景往往比較單一，其體量也相對(duì)較小，故嵌入式系統(tǒng)對(duì)IMA方案的需求也有所不同.

1)應(yīng)用場(chǎng)景單一使得嵌入式系統(tǒng)所受的攻擊面較小，且無(wú)需考慮通用系統(tǒng)可能面臨的諸多不確定性，如安裝/卸載任意應(yīng)用帶來(lái)的不可預(yù)測(cè)的系統(tǒng)完整性基線變更等.

2)體量較小，意味著嵌入式系統(tǒng)要求IMA方案必須在計(jì)算資源極為有限的情況下仍具備可用性；否則，無(wú)論其預(yù)期安全目標(biāo)如何強(qiáng)大，還是難免因無(wú)法部署而成為無(wú)本之木.

特別需要指出的是，現(xiàn)有IMA方案中額外引入的細(xì)粒度執(zhí)行狀態(tài)度量等機(jī)制(如CFI等)主要以不確定性系統(tǒng)環(huán)境中的任意執(zhí)行行為和以代碼重用為代表的高級(jí)漏洞利用編碼技術(shù)為防護(hù)對(duì)象.然而，代碼重用本質(zhì)上是一種漏洞利用手段而非后果，其對(duì)目標(biāo)系統(tǒng)的潛在影響也并未脫離傳統(tǒng)漏洞利用方法的威脅模型范疇.例如，當(dāng)通過(guò)漏洞利用實(shí)施權(quán)限提升攻擊時(shí)，無(wú)論是否以代碼重用為載荷編碼手段，攻擊者最終仍需要修改系統(tǒng)內(nèi)核參數(shù)(如進(jìn)程權(quán)限)并啟動(dòng)一個(gè)高權(quán)限shell.因此，即使不具有細(xì)粒度動(dòng)態(tài)執(zhí)行監(jiān)控能力，IMA仍可通過(guò)對(duì)內(nèi)核關(guān)鍵數(shù)據(jù)的完整性驗(yàn)證來(lái)檢測(cè)并響應(yīng)上述篡改.這就使得現(xiàn)有IMA方案在應(yīng)用于嵌入式系統(tǒng)時(shí)顯得過(guò)猶不及：一方面，它們所采用的安全機(jī)制在實(shí)際有效性上很可能并無(wú)顯著提升；另一方面，它們卻肯定會(huì)因?yàn)檫@些機(jī)制而給目標(biāo)系統(tǒng)造成不可承受的性能負(fù)擔(dān).因此，本文所提出的DIMAK所考慮的威脅模型主要針對(duì)可能對(duì)系統(tǒng)完整性造成破壞的攻擊類型，包括(但不限于)：

1)惡意代碼/進(jìn)程的動(dòng)態(tài)載入和內(nèi)存駐留；

2)權(quán)限提升攻擊；

3)基于hooking等技術(shù)的函數(shù)調(diào)用劫持.

考慮到嵌入式Linux系統(tǒng)在實(shí)際應(yīng)用中的安全需求，針對(duì)上述威脅模型，DIMAK主要期望達(dá)成的安全目標(biāo)包括：

1)為嵌入式Linux系統(tǒng)內(nèi)核及用戶空間內(nèi)的所有可執(zhí)行文本(包括shell腳本)提供運(yùn)行時(shí)完整性校驗(yàn)；

2)為用戶態(tài)位置無(wú)關(guān)代碼加載后的動(dòng)態(tài)鏈接和重定位信息提供運(yùn)行時(shí)完整性校驗(yàn)；

3)為用戶進(jìn)程可能應(yīng)用的代碼熱修復(fù)功能提供完整性校驗(yàn)支持；

4)除實(shí)時(shí)校驗(yàn)外，支持對(duì)系統(tǒng)內(nèi)全部待度量?jī)?nèi)容實(shí)施人工或計(jì)劃性的全量掃描；

5)對(duì)系統(tǒng)運(yùn)行中發(fā)生的進(jìn)程/子進(jìn)程創(chuàng)建等敏感行為同樣予以實(shí)時(shí)合法性驗(yàn)證.

上述安全目標(biāo)的邏輯在于對(duì)目標(biāo)系統(tǒng)同時(shí)應(yīng)用兩套校驗(yàn)策略，既支持對(duì)系統(tǒng)日常運(yùn)行中的潛在安全威脅予以實(shí)時(shí)響應(yīng)，又能夠在計(jì)劃性全量掃描中實(shí)施“查漏補(bǔ)缺”.為了在性能開銷方面更有可能適應(yīng)嵌入式系統(tǒng)和設(shè)備的實(shí)際計(jì)算資源狀況，上述安全目標(biāo)的實(shí)現(xiàn)不應(yīng)依賴于用戶應(yīng)用程序的侵入式改寫，例如文獻(xiàn)[18]中所采用的動(dòng)態(tài)插樁，或依賴于對(duì)執(zhí)行行為的即時(shí)(just-in-time)跟蹤等性能開銷較大的操作.

考慮到嵌入式系統(tǒng)所具有的專用性和以應(yīng)用為中心等特點(diǎn)，DIMAK假設(shè)目標(biāo)系統(tǒng)運(yùn)行一組相對(duì)固定的內(nèi)核KO模塊及用戶應(yīng)用程序，并因此具有穩(wěn)定的代碼完整性基線.在安全性方面，DIMAK的主要目標(biāo)在于保護(hù)嵌入式系統(tǒng)運(yùn)行過(guò)程中的完整性狀態(tài)，故本文假設(shè)部署DIMAK的操作系統(tǒng)已經(jīng)具備某種可信啟動(dòng)技術(shù)，使得DIMAK總是能夠在系統(tǒng)處于同一確定的可信狀態(tài)時(shí)予以接管.另外，DIMAK還假設(shè)目標(biāo)系統(tǒng)在用戶和內(nèi)核空間均已應(yīng)用了地址空間布局隨機(jī)化(address space layout randomization, ASLR)、數(shù)據(jù)執(zhí)行保護(hù)(data execution protection, DEP)等現(xiàn)代操作系統(tǒng)的基本安全機(jī)制.由于ASLR機(jī)制的存在，DIMAK進(jìn)一步假設(shè)目標(biāo)系統(tǒng)在加載動(dòng)態(tài)鏈接庫(kù)時(shí)采用立即綁定模式；否則，用戶進(jìn)程在運(yùn)行時(shí)將具有與程序控制流相關(guān)的非靜態(tài)結(jié)構(gòu)化數(shù)據(jù)(如GOT將變?yōu)榭勺x寫)，使得決定進(jìn)程完整性的部分要素?zé)o法被有效地度量.

2 架構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)

2.1 總體架構(gòu)

整體上，DIMAK由部署在Linux內(nèi)核空間內(nèi)的主校驗(yàn)?zāi)K、部署在TEE環(huán)境內(nèi)的根模塊以及由TPM維護(hù)的完整性基線組構(gòu)成.通過(guò)應(yīng)用這一部署策略，DIMAK建立了自身與系統(tǒng)用戶空間之間的完全權(quán)限隔離，同時(shí)也在根模塊與可能從內(nèi)核空間發(fā)起的潛在威脅(如驅(qū)動(dòng)程序等)之間建立了可信的入侵檢測(cè)機(jī)制，使得框架整體的信任邏輯具有良好的完備性.

如圖1所示，當(dāng)DIMAK啟動(dòng)時(shí)，其主校驗(yàn)?zāi)K在第一時(shí)間對(duì)內(nèi)核空間內(nèi)的一組系統(tǒng)調(diào)用函數(shù)實(shí)施代碼插樁(code instrumentation)，由此建立一個(gè)位于內(nèi)核空間的狀態(tài)感知界面.此設(shè)計(jì)使得DIMAK能夠?qū)崟r(shí)探測(cè)發(fā)生在系統(tǒng)內(nèi)核及用戶空間內(nèi)的完整性狀態(tài)變更事件，包括進(jìn)程創(chuàng)建/終止、代碼加載/卸載、代碼改寫以及shell命令執(zhí)行等.通過(guò)復(fù)用Linux自身的進(jìn)程和內(nèi)存管理機(jī)制，DIMAK主校驗(yàn)?zāi)K能夠直接獲取用戶態(tài)進(jìn)程內(nèi)下列內(nèi)容所對(duì)應(yīng)的物理頁(yè)面并計(jì)算其完整性度量：

1)用戶進(jìn)程空間內(nèi)的所有代碼段；

2)附屬于任一代碼段的結(jié)構(gòu)化數(shù)據(jù)段(主要為相關(guān)代碼的重定位、動(dòng)態(tài)鏈接信息等).

而對(duì)于內(nèi)核空間中的Linux內(nèi)核鏡像和KO模塊等內(nèi)容，DIMAK主校驗(yàn)?zāi)K可以直接使用虛擬地址予以訪問(wèn)和度量.利用狀態(tài)感知界面，DIMAK還能夠偵測(cè)來(lái)自遠(yuǎn)程管理員的人工指示，并根據(jù)具體命令對(duì)系統(tǒng)實(shí)施單次或周期性的全量掃描，即一次性對(duì)系統(tǒng)內(nèi)的所有代碼和結(jié)構(gòu)化數(shù)據(jù)區(qū)段予以檢驗(yàn).此外，自DIMAK啟動(dòng)時(shí)起，其根模塊即開始對(duì)主校驗(yàn)?zāi)K以及狀態(tài)感知界面所涉及的內(nèi)核指令實(shí)施周期性掃描，確保DIMAK自身始終處在可信的運(yùn)行狀態(tài)下.最后，在與實(shí)時(shí)完整性驗(yàn)證或全量掃描時(shí)所測(cè)得的完整性度量實(shí)施比對(duì)時(shí)，DIMAK的主校驗(yàn)?zāi)K與根模塊均通過(guò)TPM安全地訪問(wèn)其完整性基線組.

不難看出，狀態(tài)感知界面是DIMAK方案是否能夠?qū)崿F(xiàn)其安全目標(biāo)的一個(gè)關(guān)鍵點(diǎn).但除此之外，針對(duì)不同類型的被度量實(shí)體所采用的具體完整性基線生成策略，以及面對(duì)多種特殊的系統(tǒng)完整性變更事件時(shí)所采用的創(chuàng)新性度量方法和系統(tǒng)設(shè)計(jì)約定，同樣是DIMAK達(dá)成有效性和完備性的重要保障.因此，2.2節(jié)將詳細(xì)闡述DIMAK狀態(tài)感知界面的具體設(shè)計(jì)；針對(duì)各類被度量實(shí)體的完整性基線維護(hù)策略，特別是針對(duì)用戶態(tài)位置無(wú)關(guān)代碼所對(duì)應(yīng)的重定位和動(dòng)態(tài)鏈接信息等關(guān)鍵結(jié)構(gòu)化數(shù)據(jù)的可信基線生成方法，將在2.3節(jié)中介紹；2.4節(jié)將詳細(xì)解釋DIMAK對(duì)于軟件熱修復(fù)這一特殊應(yīng)用場(chǎng)景的完整性度量支持及其具體協(xié)議設(shè)計(jì).

2.2 狀態(tài)感知界面的實(shí)現(xiàn)

由于在架構(gòu)部署策略上建立了不同地址空間上的權(quán)限隔離，DIMAK需要能夠在處于內(nèi)核態(tài)的情況下實(shí)時(shí)地感知用戶空間內(nèi)發(fā)生的系統(tǒng)完整性關(guān)鍵事件，這一任務(wù)由其在啟動(dòng)時(shí)所建立的內(nèi)核態(tài)狀態(tài)感知界面來(lái)完成.從過(guò)往研究以及工業(yè)界實(shí)踐中可以初步總結(jié)出該狀態(tài)感知界面所需監(jiān)測(cè)的用戶態(tài)程序行為主要包括：

1)進(jìn)程的創(chuàng)建和終止行為.這是由于對(duì)用戶進(jìn)程的惡意攻擊有可能會(huì)為后續(xù)惡意載荷的執(zhí)行創(chuàng)建新的子進(jìn)程.

2)代碼的加載和修改行為.典型代表是惡意載荷的注入以及對(duì)用戶態(tài)代碼的控制流篡改，它們是IMA所需考慮的主要威脅.

3)請(qǐng)求執(zhí)行shell腳本的行為.這是由于對(duì)用戶空間進(jìn)程的惡意攻擊還有可能通過(guò)執(zhí)行特定的shell命令來(lái)達(dá)成某些攻擊目的，如權(quán)限提升等.

此外，作為一個(gè)特殊情形，由用戶空間進(jìn)程發(fā)起的內(nèi)核KO模塊加載行為同樣也需要納入狀態(tài)感知界面的監(jiān)測(cè)范圍.

上述關(guān)鍵事件的執(zhí)行過(guò)程均依賴于Linux內(nèi)核所提供的系統(tǒng)調(diào)用支持，故如2.1節(jié)所述，DIMAK通過(guò)對(duì)這些系統(tǒng)調(diào)用實(shí)施代碼插樁的方式實(shí)現(xiàn)在所需監(jiān)測(cè)的關(guān)鍵事件發(fā)生時(shí)攔截并獲取控制的目的.另外，利用所設(shè)置的插樁點(diǎn)，DIMAK還能夠直接訪問(wèn)Linux內(nèi)核用于文件、進(jìn)程和內(nèi)存管理的一系列關(guān)鍵變量，從而實(shí)現(xiàn)對(duì)全系統(tǒng)范圍內(nèi)被度量實(shí)體的定位和訪問(wèn).圖2示意了DIMAK為構(gòu)建狀態(tài)感知界面所采用的內(nèi)核函數(shù)攔截面，以及藉此能夠訪問(wèn)的關(guān)鍵內(nèi)核數(shù)據(jù)結(jié)構(gòu).

圖2中需要說(shuō)明4方面：

1)利用系統(tǒng)調(diào)用實(shí)例do_fork()與do_exit()，可攔截用戶進(jìn)程的創(chuàng)建/終止事件；

2)利用實(shí)施內(nèi)存映射所需的關(guān)鍵系統(tǒng)調(diào)用實(shí)例mmap_region()以及加載KO模塊時(shí)所使用的內(nèi)核函數(shù)load_module()，可監(jiān)控到系統(tǒng)范圍內(nèi)所有ELF文件的加載事件；

3)利用系統(tǒng)調(diào)用實(shí)例mprotect_fixup()函數(shù)，并在其目標(biāo)權(quán)限參數(shù)為可執(zhí)行或只讀時(shí)觸發(fā)響應(yīng)，用戶空間內(nèi)的任意代碼改寫和控制流劫持行為均可被攔截；

4)利用文件執(zhí)行操作的內(nèi)核入口函數(shù)do_execve()，shell腳本的執(zhí)行請(qǐng)求事件可以被感知，且通過(guò)該函數(shù)的參數(shù)還可以獲取到被執(zhí)行腳本的文件路徑以實(shí)現(xiàn)對(duì)被度量實(shí)體的定位.

通過(guò)上述任一被插樁函數(shù)，DIMAK均可訪問(wèn)系統(tǒng)內(nèi)核所維護(hù)的task_struct類型(Linux進(jìn)程管理數(shù)據(jù)結(jié)構(gòu))變量current以獲知引發(fā)相應(yīng)關(guān)鍵事件的用戶進(jìn)程信息.較為特殊的情況是，在執(zhí)行外部shell命令或shell腳本時(shí)，程序往往會(huì)為該次執(zhí)行單獨(dú)創(chuàng)建子進(jìn)程，故在感知此類行為時(shí)，DIMAK除獲取當(dāng)前進(jìn)程信息外，還需回溯父進(jìn)程信息以確定行為來(lái)源.最后，上述狀態(tài)感知界面的設(shè)計(jì)還能夠?yàn)镈IMAK所期望實(shí)現(xiàn)的面向運(yùn)行內(nèi)存的完整性驗(yàn)證功能提供支持.具體地，前述Linux進(jìn)程管理數(shù)據(jù)結(jié)構(gòu)task_struct內(nèi)部維護(hù)有指向進(jìn)程內(nèi)存映射的對(duì)象指針mm(類型為mm_struct)，mm進(jìn)一步指向一個(gè)描述該進(jìn)程空間內(nèi)所有虛擬內(nèi)存段的vm_area_struct類型雙鏈表vma，表內(nèi)的每個(gè)對(duì)象均與進(jìn)程空間內(nèi)的一個(gè)虛擬內(nèi)存段相對(duì)應(yīng)，且維護(hù)該內(nèi)存段的虛擬地址范圍和對(duì)應(yīng)文件指針.利用vma鏈表所提供的參數(shù)，DIMAK可以在內(nèi)核態(tài)遍歷位于各用戶進(jìn)程空間內(nèi)的諸如ELF文件代碼段、靜態(tài)變量段和只讀結(jié)構(gòu)化數(shù)據(jù)段等被度量實(shí)體的對(duì)應(yīng)虛擬內(nèi)存描述符，進(jìn)而結(jié)合其所給出的虛擬地址和對(duì)Linux頁(yè)表的解析尋獲被度量實(shí)體所駐留的物理頁(yè)面，實(shí)現(xiàn)對(duì)實(shí)際運(yùn)行內(nèi)存狀態(tài)而非抽象文件內(nèi)容的完整性驗(yàn)證.

最后，利用上述狀態(tài)感知界面，DIMAK進(jìn)一步實(shí)現(xiàn)了對(duì)人工/計(jì)劃性全量掃描功能的控制.通過(guò)在Linux的標(biāo)準(zhǔn)shell命令行范疇外額外約定一組自定義的shell命令行，DIMAK可在其位于do_execve()函數(shù)內(nèi)的攔截點(diǎn)檢測(cè)到shell命令行執(zhí)行行為時(shí)判斷被捕獲參數(shù)是否為自定義命令行，并在匹配成功時(shí)觸發(fā)全量掃描事件.與前述的vma鏈表類似，Linux的進(jìn)程管理機(jī)制還將用戶空間內(nèi)的活動(dòng)進(jìn)程在總體上組織為以task_struct結(jié)構(gòu)體為基本元素的雙鏈表.因此，在觸發(fā)全量掃描時(shí)，DIMAK可由指向當(dāng)前用戶進(jìn)程的current指針出發(fā)，對(duì)task_struct雙鏈表進(jìn)行遍歷以訪問(wèn)所有用戶進(jìn)程，并使用各進(jìn)程的vma鏈表以遍歷掃描其地址空間內(nèi)的所有被度量實(shí)體.同時(shí)，由于DIMAK的主校驗(yàn)?zāi)K本身部署于系統(tǒng)內(nèi)核空間，故可以直接通過(guò)虛擬地址遍歷掃描內(nèi)核鏡像本身以及內(nèi)核KO模塊列表.

2.3 完整性基線的分組與生成

針對(duì)系統(tǒng)中不同類型的被度量實(shí)體，DIMAK使用了靜態(tài)/動(dòng)態(tài)相結(jié)合的雙完整性基線組模式，以確保在面對(duì)所有可能發(fā)生的完整性狀態(tài)變更時(shí)總是能夠做出正確的判斷.

2.3.1 靜態(tài)基線組

在眾多類型的被度量實(shí)體中，DIMAK應(yīng)用純靜態(tài)基線予以保護(hù)包括ELF文件內(nèi)的靜態(tài)變量區(qū)段、用戶進(jìn)程的元數(shù)據(jù)信息及其請(qǐng)求執(zhí)行的shell腳本.值得注意的是，盡管用戶進(jìn)程在每次啟動(dòng)時(shí)所獲得的標(biāo)識(shí)符是動(dòng)態(tài)生成的，但Linux的task_struct結(jié)構(gòu)體通過(guò)內(nèi)嵌的mm_struct結(jié)構(gòu)體關(guān)聯(lián)進(jìn)程所對(duì)應(yīng)的主可執(zhí)行文件(參考圖2中通過(guò)mm_struct索引的exe_file變量)，故DIMAK可利用上述關(guān)聯(lián)生成針對(duì)進(jìn)程信息的靜態(tài)基線.

2.3.2 動(dòng)態(tài)基線組

由于用戶所加載的ELF文件采用位置無(wú)關(guān)代碼的編碼形態(tài)，使得該類文件在加載后需由動(dòng)態(tài)鏈接器進(jìn)行符號(hào)解析、修改其重定位表及GOT以維持程序控制流的正確性.因此，承載這些重定位和動(dòng)態(tài)鏈接信息的結(jié)構(gòu)化數(shù)據(jù)段只在用戶進(jìn)程的單個(gè)生命周期內(nèi)具有穩(wěn)定的完整性基線.該基線在ELF文件加載時(shí)動(dòng)態(tài)生成，并隨其卸載而失效.此外，對(duì)于全局描述符表(global descriptor table, GDT)、系統(tǒng)調(diào)用表(system call table)等操作系統(tǒng)內(nèi)核所依賴的關(guān)鍵動(dòng)態(tài)數(shù)據(jù)，DIMAK同樣只能在系統(tǒng)啟動(dòng)后為其維護(hù)動(dòng)態(tài)基線.

2.3.3 靜態(tài)/動(dòng)態(tài)雙基線組

較為特殊的是，由于內(nèi)核KO模塊所對(duì)應(yīng)的ELF文件并不使用位置無(wú)關(guān)代碼，故在內(nèi)核ASLR啟用的情況下，KO模塊的每次加載時(shí)所加載的具體代碼文本都會(huì)有所改變.因此，當(dāng)KO模塊加載時(shí)，DIMAK需要驗(yàn)證其可執(zhí)行文件的靜態(tài)完整性；但在實(shí)施計(jì)劃性的全量掃描時(shí)，DIMAK又需要驗(yàn)證KO模塊所駐留運(yùn)行內(nèi)存的動(dòng)態(tài)完整性.此外，由于DIMAK本身需要通過(guò)對(duì)Linux內(nèi)核鏡像實(shí)施inline hooking以建立狀態(tài)感知界面，使得其對(duì)內(nèi)核鏡像的完整性驗(yàn)證存在同樣的問(wèn)題.因此，對(duì)于上述2種情形，DIMAK在KO模塊首次加載/系統(tǒng)啟動(dòng)時(shí)首先應(yīng)用離線生成的靜態(tài)基線實(shí)施完整性驗(yàn)證，隨后生成并在系統(tǒng)運(yùn)行的剩余周期內(nèi)轉(zhuǎn)而應(yīng)用動(dòng)態(tài)完整性基線.

另一個(gè)可能需要應(yīng)用靜態(tài)/動(dòng)態(tài)雙基線的被度量實(shí)體類型是位于用戶空間內(nèi)的ELF文件代碼文本.這是因?yàn)镈IMAK需要考慮兼容代碼熱修復(fù)機(jī)制，且現(xiàn)有代碼熱修復(fù)技術(shù)在實(shí)施過(guò)程中均需要對(duì)已加載的可執(zhí)行文件進(jìn)行inline hooking來(lái)實(shí)現(xiàn)對(duì)被修復(fù)函數(shù)的重定向(至其補(bǔ)丁版本所在的位置).因此，盡管DIMAK在所有用戶態(tài)ELF文件的首次加載時(shí)均使用離線生成靜態(tài)基線予以驗(yàn)證，但每當(dāng)一次熱修復(fù)操作完成后，DIMAK就必須對(duì)受到影響的ELF文件代碼段進(jìn)行完整性基線的更新，并轉(zhuǎn)而在其之后的生命周期內(nèi)應(yīng)用動(dòng)態(tài)基線；而對(duì)于未受到熱修復(fù)影響的ELF文件，DIMAK則始終在對(duì)其代碼段的完整性驗(yàn)證中應(yīng)用靜態(tài)基線.

2.3.4 動(dòng)態(tài)基線的生成機(jī)制

表1列出了當(dāng)前DIMAK所考慮的所有被度量實(shí)體類型及其各自對(duì)應(yīng)的完整性基線組.其中，歸屬于靜態(tài)/動(dòng)態(tài)雙基線組的3類被度量實(shí)體均具有可從內(nèi)核空間內(nèi)準(zhǔn)確感知的基線轉(zhuǎn)換時(shí)機(jī).然而，用戶態(tài)ELF文件所附帶的動(dòng)態(tài)鏈接和重定位信息是在其加載過(guò)程中經(jīng)動(dòng)態(tài)鏈接器處理后寫入的，期間系統(tǒng)內(nèi)核僅在內(nèi)存分配和頁(yè)面權(quán)限改寫時(shí)有所參與.這就使得主校驗(yàn)?zāi)K完全位于內(nèi)核空間的DIMAK很難捕捉到動(dòng)態(tài)鏈接器完成上述結(jié)構(gòu)化數(shù)據(jù)寫入的

Table 1 Grouping Strategy of DIMAK’s Integrity Baselines

確切時(shí)機(jī)，因而無(wú)法僅憑被動(dòng)的狀態(tài)感知建立可信的動(dòng)態(tài)基線.針對(duì)這一問(wèn)題，DIMAK創(chuàng)新性地采用了一種進(jìn)取型動(dòng)態(tài)鏈接預(yù)測(cè)技術(shù)，在用戶態(tài)ELF文件尚未完全加載時(shí)主動(dòng)“模擬”動(dòng)態(tài)鏈接器的行為，從而預(yù)測(cè)正在載入的ELF文件最終的重定位和動(dòng)態(tài)鏈接狀態(tài).

圖3示意了DIMAK所采用的動(dòng)態(tài)鏈接預(yù)測(cè)技術(shù)的工作原理.當(dāng)Linux系統(tǒng)加載一個(gè)用戶態(tài)ELF文件時(shí)，其動(dòng)態(tài)鏈接器會(huì)在符號(hào)解析時(shí)首先判斷該文件是否依賴于尚未加載的其他ELF文件.例如，Linux在為應(yīng)用程序創(chuàng)建進(jìn)程時(shí)總是首先加載后綴為.o的主可執(zhí)行文件，然后根據(jù)符號(hào)解析獲取到的依賴關(guān)系遞歸地加載該程序所需要的其他ELF文件(如共享類庫(kù)等).利用動(dòng)態(tài)鏈接過(guò)程的這一特點(diǎn)，DIMAK借助狀態(tài)感知界面對(duì)mmap_region()的攔截點(diǎn)(參見2.2節(jié))，在任意用戶態(tài)ELF文件加載時(shí)主動(dòng)介入、搶先解析其文件依賴關(guān)系，并將被加載文件所依賴但尚未加載的其他ELF文件添加至一個(gè)動(dòng)態(tài)列表.在此之后，每當(dāng)DIMAK感知到新的用戶態(tài)ELF文件加載時(shí)，即檢查該文件的存儲(chǔ)路徑及所屬進(jìn)程等信息是否存在于當(dāng)前處于活動(dòng)狀態(tài)的某個(gè)依賴關(guān)系列表內(nèi)，若是則從相應(yīng)列表中刪除該項(xiàng).當(dāng)一次表項(xiàng)刪除導(dǎo)致DIMAK所維護(hù)的某一依賴關(guān)系列表為空時(shí)，即意味著該列表對(duì)應(yīng)的ELF文件所需的依賴文件已經(jīng)全部載入內(nèi)存、即將進(jìn)入動(dòng)態(tài)鏈接階段.因此，DIMAK得以在該時(shí)機(jī)介入并依照動(dòng)態(tài)鏈接器的工作規(guī)則搶先為相應(yīng)的ELF文件計(jì)算動(dòng)態(tài)鏈接和重定位信息.到這一步，DIMAK已經(jīng)能夠在用戶態(tài)ELF文件的加載和動(dòng)態(tài)鏈接過(guò)程尚未完成時(shí)為其只讀結(jié)構(gòu)化數(shù)據(jù)段生成正確的動(dòng)態(tài)基線.

上述進(jìn)取型動(dòng)態(tài)鏈接預(yù)測(cè)技術(shù)的存在，使得DIMAK即使處在系統(tǒng)內(nèi)核空間中也能夠及時(shí)(確切地說(shuō)，是搶先)且正確地維護(hù)與用戶態(tài)位置無(wú)關(guān)代碼相關(guān)聯(lián)的所有關(guān)鍵控制流完整性信息，無(wú)需修改動(dòng)態(tài)鏈接器或?qū)ζ鋭?dòng)態(tài)插樁，也無(wú)需將自身任何組件探入用戶進(jìn)程空間.截止目前，該安全目標(biāo)尚未在現(xiàn)有IMA方案中真正實(shí)現(xiàn)過(guò)，是DIMAK在系統(tǒng)完整性度量的完備性方面的一次創(chuàng)新性突破.

2.4 對(duì)代碼熱修復(fù)功能的支持

盡管代碼熱修復(fù)是一種工業(yè)界常見的軟件工程需求，但對(duì)于IMA技術(shù)而言，實(shí)現(xiàn)對(duì)該功能的兼容所面臨的最大困難在于代碼熱修復(fù)在技術(shù)本質(zhì)上與惡意代碼注入行為的界限十分模糊.事實(shí)上，若不對(duì)熱修復(fù)所注入的代碼文本進(jìn)行格式上的事先約定，則無(wú)法僅憑兩者對(duì)內(nèi)核函數(shù)的調(diào)用特征將其加以區(qū)分.借鑒了Android平臺(tái)所采用的APK簽名驗(yàn)證機(jī)制，DIMAK采用了一種類似的代碼熱補(bǔ)丁格式與簽名規(guī)范約定，結(jié)合其狀態(tài)感知界面所利用的Linux進(jìn)程空間管理機(jī)制，首次實(shí)現(xiàn)了對(duì)代碼熱修復(fù)功能的可信驗(yàn)證支持.

圖4示意了DIMAK所采用的可信熱補(bǔ)丁格式約定.該格式以一個(gè)固定長(zhǎng)度的頭部為起始，依次容納了一個(gè)補(bǔ)丁位圖以及一個(gè)或多個(gè)補(bǔ)丁段(即允許對(duì)用戶進(jìn)程內(nèi)的多個(gè)可執(zhí)行文件同時(shí)進(jìn)行熱修復(fù)).其中，補(bǔ)丁頭部包含了魔數(shù)字符、補(bǔ)丁區(qū)所容納的補(bǔ)丁段總數(shù)、補(bǔ)丁位圖大小等關(guān)鍵信息以幫助DIMAK對(duì)補(bǔ)丁包進(jìn)行識(shí)別和解析.此外，補(bǔ)丁頭部?jī)?nèi)還寫入了補(bǔ)丁包的簽名信息以及全體補(bǔ)丁段的總和校驗(yàn)和.緊接在頭部之后的補(bǔ)丁位圖給出了后續(xù)補(bǔ)丁段以及段內(nèi)各補(bǔ)丁函數(shù)的索引，并給出了每個(gè)補(bǔ)丁函數(shù)的修復(fù)對(duì)象所在的可執(zhí)行文件名，使得DIMAK可以判斷該次熱修復(fù)對(duì)系統(tǒng)當(dāng)前基線組的具體影響狀況.

除圖4所示的格式約定外，DIMAK進(jìn)一步規(guī)定：在可信的熱修復(fù)過(guò)程中，補(bǔ)丁包必須先將符合格式約定的熱補(bǔ)丁載入內(nèi)存并設(shè)為可執(zhí)行權(quán)限，并等待該操作成功后方能對(duì)進(jìn)程內(nèi)已經(jīng)加載的其他代碼段進(jìn)行修改.按照這一設(shè)計(jì)，DIMAK對(duì)軟件熱修復(fù)功能的支持可由4個(gè)流程描述：

1)當(dāng)DIMAK在運(yùn)行時(shí)檢測(cè)到某一用戶進(jìn)程正在加載一個(gè)具有可執(zhí)行權(quán)限、但未被該進(jìn)程的vma鏈表收錄的虛擬內(nèi)存段時(shí)，即對(duì)該段首地址進(jìn)行魔數(shù)識(shí)別以判斷該次加載是否可能為一次可信的熱補(bǔ)丁行為.

2)若魔數(shù)識(shí)別成功，則DIMAK通過(guò)補(bǔ)丁位圖確定被加載虛擬內(nèi)存段內(nèi)部的各補(bǔ)丁段界限，并對(duì)全體補(bǔ)丁段的總和校驗(yàn)和進(jìn)行完整性驗(yàn)證.

3)若驗(yàn)證通過(guò)，DIMAK將前一步驟所使用的總和校驗(yàn)和作為當(dāng)前補(bǔ)丁包的完整性基線納入靜態(tài)基線組，并為該補(bǔ)丁包創(chuàng)建2個(gè)新的vm_area_struct結(jié)構(gòu)體.其中，第1個(gè)融合了補(bǔ)丁包內(nèi)的所有補(bǔ)丁代碼段并被賦予可執(zhí)行權(quán)限；而第2個(gè)則被映射到補(bǔ)丁頭部和位圖區(qū)段，并被賦予只讀權(quán)限.

4)DIMAK根據(jù)補(bǔ)丁位圖信息定位到進(jìn)程空間內(nèi)即將被修改的所有代碼段，允許對(duì)這些代碼段各實(shí)施一次改寫，并在該次改寫完成后更新相應(yīng)代碼段的完整性基線.

1)～4)設(shè)計(jì)使得DIMAK能夠保證正常的代碼熱修復(fù)過(guò)程所涉及的所有用戶態(tài)代碼(包括補(bǔ)丁本身以及被修復(fù)的運(yùn)行代碼段)在該過(guò)程的任意時(shí)刻總是具有可信的完整性基線，從而保證系統(tǒng)整體在熱修復(fù)發(fā)生時(shí)全程處于可度量狀態(tài).值得一提的是，該設(shè)計(jì)的DIMAK除要求用戶態(tài)應(yīng)用程序依照其格式約定編碼補(bǔ)丁包之外，對(duì)代碼熱修復(fù)功能的支持無(wú)需額外的用戶/內(nèi)核代碼組件的協(xié)助.

3 有效性與性能評(píng)估

3.1 信任擴(kuò)展邏輯

在整體信任擴(kuò)展邏輯的構(gòu)建方面，DIMAK所采用的分層權(quán)限隔離的架構(gòu)設(shè)計(jì)(如2.1節(jié)所述)，使得除DIMAK根模塊外，系統(tǒng)各地址空間內(nèi)的程序模塊——包括DIMAK自身的主校驗(yàn)?zāi)K及用戶空間狀態(tài)感知界面——均由權(quán)限更高的DIMAK模塊予以校驗(yàn).

首先，對(duì)于處在用戶地址空間內(nèi)的各應(yīng)用程序而言，DIMAK的所有組件均位于系統(tǒng)內(nèi)核空間或具有更高權(quán)限的安全執(zhí)行環(huán)境內(nèi)，且不依賴于任何用戶態(tài)輔助組件.因此，當(dāng)用戶空間內(nèi)的某一程序進(jìn)程中出現(xiàn)惡意執(zhí)行行為時(shí)，其所擁有的權(quán)限不足以對(duì)DIMAK本身實(shí)施篡改或欺騙.因此，只要部署于內(nèi)核中的各組件能夠被信任，則經(jīng)過(guò)DIMAK驗(yàn)證的用戶空間可被認(rèn)為得到了有效的信任擴(kuò)展.

其次，由于DIMAK通過(guò)部署在TEE內(nèi)的根模塊為其主校驗(yàn)?zāi)K提供完整性驗(yàn)證，故只要該根模塊能夠被信任，則可以認(rèn)為受到其周期性驗(yàn)證的DIMAK主校驗(yàn)?zāi)K也得到了有效的信任擴(kuò)展，其執(zhí)行行為因而可以被信任.

最后，DIMAK的主校驗(yàn)?zāi)K與系統(tǒng)內(nèi)核鏡像、KO模塊等組件同處于內(nèi)核空間內(nèi)，故當(dāng)系統(tǒng)遭到源自驅(qū)動(dòng)程序等同樣位于內(nèi)核空間的第三方組件的惡意行為時(shí)，攻擊方確實(shí)具有破壞DIMAK各內(nèi)核態(tài)組件完整性的可能性.然而，由于DIMAK的主校驗(yàn)?zāi)K得到了根模塊的背書，故該模塊較之內(nèi)核空間中的其他代碼組件具有更高的信任等級(jí).此外，由于DIMAK在主校驗(yàn)?zāi)K啟動(dòng)后由該模塊負(fù)責(zé)驗(yàn)證系統(tǒng)內(nèi)核鏡像及其加載的其他內(nèi)核KO模塊的動(dòng)態(tài)完整性，故在主校驗(yàn)?zāi)K能夠被信任的情況下，即可以認(rèn)為：經(jīng)該模塊驗(yàn)證的其他內(nèi)核空間組件均得到了有效的信任擴(kuò)展.

綜上可以認(rèn)為，當(dāng)假設(shè)部署于TEE內(nèi)的根模塊為可信時(shí)，DIMAK能夠基于此信任根、憑借操作系統(tǒng)的地址空間層次實(shí)現(xiàn)逐級(jí)的信任擴(kuò)展，使得其對(duì)系統(tǒng)內(nèi)所有組件的完整性驗(yàn)證均可得到更高權(quán)限的可信模塊之背書.而無(wú)論是位于用戶空間或是內(nèi)核空間的潛在攻擊者，均無(wú)法完全規(guī)避、欺騙或破壞包括根模塊在內(nèi)的所有DIMAK組件，故無(wú)法繞過(guò)該架構(gòu)的信任邏輯.

3.2 正確性

在3.1節(jié)所述的信任邏輯基礎(chǔ)上，DIMAK所采用的狀態(tài)感知界面這一設(shè)計(jì)(如2.2節(jié)所述)，使其能夠從基線生成時(shí)機(jī)和實(shí)時(shí)完整性驗(yàn)證的觸發(fā)機(jī)制2個(gè)方面保證自身行為的正確性.

由于采用了靜態(tài)/動(dòng)態(tài)雙基線組的設(shè)計(jì)，DIMAK得以依賴其動(dòng)態(tài)基線組對(duì)系統(tǒng)中部分正當(dāng)?shù)倪\(yùn)行時(shí)代碼/數(shù)據(jù)改寫需求提供有效的可信計(jì)算支持(如2.3節(jié)、2.4節(jié)所述).這一機(jī)制是決定該方案正確性的主要因素之一.而狀態(tài)感知界面使得DIMAK能夠在適當(dāng)?shù)臅r(shí)機(jī)介入此類運(yùn)行時(shí)的改寫行為，由此保證與之相關(guān)的動(dòng)態(tài)基線生成過(guò)程始終滿足兩項(xiàng)原則：

1)任意一項(xiàng)動(dòng)態(tài)完整性基線的生成均得到了某項(xiàng)與之相關(guān)的靜態(tài)基線的完整性背書.例如，在內(nèi)核KO模塊的加載中，DIMAK在加載前后分別介入、首先引導(dǎo)一次基于靜態(tài)基線的完整性驗(yàn)證以確認(rèn)待加載模塊的對(duì)應(yīng)文件是否具有可信的靜態(tài)度量，隨后才會(huì)在KO加載完成后生成并切換至動(dòng)態(tài)基線.由此，DIMAK使得內(nèi)核KO模塊所對(duì)應(yīng)ELF文件的靜態(tài)基線成為其運(yùn)行時(shí)動(dòng)態(tài)基線的完整性背書.在其他動(dòng)態(tài)基線場(chǎng)景中，

① 用戶態(tài)ELF文件內(nèi)的動(dòng)態(tài)鏈接/重定位信息的生成發(fā)生在其代碼文本的加載過(guò)程中，故代碼文本的靜態(tài)基線天然地成為該類信息動(dòng)態(tài)基線的完整性背書；

② 類似地，用戶代碼的熱修復(fù)行為也得到了補(bǔ)丁包以及被修復(fù)代碼段二者所對(duì)應(yīng)靜態(tài)基線的雙重完整性背書.

2)狀態(tài)感知界面的存在，保證了任一動(dòng)態(tài)完整性基線的生成均發(fā)生在對(duì)應(yīng)被度量實(shí)體所發(fā)生的完整性狀態(tài)變更實(shí)際生效之前.例如，在為用戶態(tài)ELF文件的動(dòng)態(tài)鏈接/重定位信息生成動(dòng)態(tài)基線時(shí)，DIMAK所選擇的攔截點(diǎn)為mmap_region()這一代碼加載行為的必經(jīng)系統(tǒng)調(diào)用，而在該系統(tǒng)調(diào)用執(zhí)行時(shí)，所加載代碼的重定位和動(dòng)態(tài)鏈接過(guò)程甚至尚未開始.類似地，在KO模塊加載過(guò)程和用戶代碼熱修復(fù)過(guò)程中，相關(guān)動(dòng)態(tài)基線同樣在對(duì)應(yīng)代碼文本被標(biāo)記為可執(zhí)行之前即生成完畢.

此外，在面對(duì)各種可能造成系統(tǒng)完整性狀態(tài)變更的事件時(shí)，DIMAK所選擇的各內(nèi)核攔截點(diǎn)同樣保證了對(duì)應(yīng)的完整性校驗(yàn)發(fā)生在事件生效之前.以shell腳本執(zhí)行行為為例，如圖2所示，當(dāng)用戶空間內(nèi)進(jìn)程發(fā)起一次shell腳本執(zhí)行時(shí)，DIMAK的狀態(tài)感知界面通過(guò)do_execve()攔截該請(qǐng)求，并通過(guò)輸入?yún)?shù)獲取到腳本名稱及路徑，進(jìn)而引導(dǎo)其主校驗(yàn)?zāi)K對(duì)腳本完整性實(shí)施驗(yàn)證.而被請(qǐng)求的腳本在這一時(shí)刻甚至尚未被解析，故其執(zhí)行行為在完整性校驗(yàn)發(fā)生時(shí)顯然尚未生效.

上述特點(diǎn)，決定了DIMAK在其基線維護(hù)及實(shí)施完整性驗(yàn)證的過(guò)程中不會(huì)遺留下檢查與使用時(shí)差(TOCTTOU)漏洞：DIMAK在任意一次完整性驗(yàn)證中總是能夠獲取到被度量實(shí)體所對(duì)應(yīng)的正確基線值；同時(shí)，在DIMAK對(duì)任一被度量實(shí)體的完整性驗(yàn)證完成之后到該對(duì)象被變更為可執(zhí)行、只讀等生效權(quán)限狀態(tài)之間，攻擊者難以獲得對(duì)該對(duì)象實(shí)施不受控改寫的時(shí)間窗口.綜上可以認(rèn)為，DIMAK架構(gòu)的設(shè)計(jì)具有完整的正確性邏輯.

3.3 完備性

在IMA技術(shù)的有效性評(píng)估方面，存在的一個(gè)主要問(wèn)題是：不同的IMA方案往往因工作原理上的顯著差異，使得其在有效性方面難以形成可比性.然而本文認(rèn)為：仍然可以從IMA方案的完備性設(shè)計(jì)入手，對(duì)現(xiàn)有的不同IMA方案進(jìn)行有效性層面上的比較.針對(duì)IMA技術(shù)的完備性指標(biāo)主要包括：

1)驗(yàn)證對(duì)象的范圍，即IMA方案能夠?qū)④浖到y(tǒng)環(huán)境內(nèi)的哪些資源和對(duì)象納入其“保護(hù)傘”之下；

2)基線類型，即IMA方案采用何種完整性基線以支持其對(duì)系統(tǒng)的驗(yàn)證行為；

3)干預(yù)時(shí)機(jī)，即IMA方案能夠在軟件系統(tǒng)啟動(dòng)及運(yùn)行過(guò)程中的哪些時(shí)機(jī)介入并實(shí)施其保護(hù)行為.

4)對(duì)正常軟件功能的支持/限制，應(yīng)被視為IMA方案完備性的一個(gè)指標(biāo).顯然，如果軟件系統(tǒng)的部分功能不能在一個(gè)IMA方案啟動(dòng)的狀態(tài)下被正常地實(shí)現(xiàn)，則該IMA方案應(yīng)該被認(rèn)為在完備性上存在缺陷.具體來(lái)說(shuō)，是否能夠支持對(duì)軟件的熱修復(fù)功能，是本文主要考慮的一個(gè)屬于此類型的完備性指標(biāo).

5)完整性度量過(guò)程是否需要對(duì)被度量實(shí)體實(shí)施侵入式改寫(如動(dòng)態(tài)代碼插樁等)，應(yīng)被視為IMA方案完備性的另一個(gè)指標(biāo).這是因?yàn)榛谇秩胧礁膶懙耐暾则?yàn)證措施自身在本質(zhì)上屬于對(duì)被改寫軟件完整性的侵犯.因此，一些軟件很可能出于性能、正確性或隱私保護(hù)等因素的考慮而無(wú)法在真實(shí)應(yīng)用場(chǎng)景中允許來(lái)自外部的該類行為.

上述1)～3)為現(xiàn)有關(guān)于IMA技術(shù)的研究工作中廣泛采用的完備性指標(biāo).在此基礎(chǔ)上，本文則進(jìn)一步認(rèn)為IMA技術(shù)的完備性還應(yīng)額外體現(xiàn)在指標(biāo)4)和5)兩個(gè)方面.表2從完備性指標(biāo)的5個(gè)方面出發(fā)，對(duì)本文所提出DIMAK方案與現(xiàn)有學(xué)術(shù)研究及工業(yè)實(shí)踐所提出或應(yīng)用的IMA方案進(jìn)行了完備性層面的對(duì)比.可以看到，相比早期一些僅關(guān)注內(nèi)核完整性的IMA方案[5-7]，DIMAK具有更為完備的驗(yàn)證范圍，且在干預(yù)時(shí)機(jī)方面有效地覆蓋了系統(tǒng)運(yùn)行過(guò)程中的主要關(guān)鍵節(jié)點(diǎn).而與近年來(lái)新出現(xiàn)的一些以用戶態(tài)進(jìn)程完整性為主要目標(biāo)的IMA方案[8,18-19]相比，DIMAK在功能實(shí)現(xiàn)上并不需要通過(guò)對(duì)用戶進(jìn)程實(shí)施主動(dòng)插樁或其他改寫，且在校驗(yàn)時(shí)機(jī)方面兼具最優(yōu)的實(shí)時(shí)性.最后，除DIMAK外，現(xiàn)有IMA方案均未考慮到熱修復(fù)等實(shí)用軟件場(chǎng)景與惡意攻擊的區(qū)分問(wèn)題.綜上，可以認(rèn)為較之現(xiàn)有同類技術(shù)，DIMAK具有較好的完備性.

Table 2 Completeness Feature Comparison of DIMAK and the Existing IMA Schemes

此外，我們測(cè)試了DIMAK面對(duì)不同類型的漏洞利用攻擊時(shí)的實(shí)際防御效果，包括：

1)利用用戶進(jìn)程漏洞發(fā)起的返回導(dǎo)向編程，攻擊目標(biāo)包括篡改進(jìn)程代碼段、GOT以及執(zhí)行自定義的shell腳本；

2)利用驅(qū)動(dòng)程序漏洞發(fā)起的內(nèi)核注入，攻擊目標(biāo)包括篡改內(nèi)核參數(shù)、破壞DIMAK主校驗(yàn)?zāi)K和狀態(tài)感知界面等.

測(cè)試顯示，在面對(duì)上述攻擊時(shí)，DIMAK均能有效地發(fā)現(xiàn)系統(tǒng)完整性狀態(tài)遭到破壞的事實(shí)，并對(duì)遭到破壞的被度量實(shí)體予以準(zhǔn)確定位.該測(cè)試進(jìn)一步證明了DIMAK方案在面對(duì)潛在惡意攻擊時(shí)具有良好的完備性.

3.4 性能開銷

需要指出的是，基于3.3節(jié)所述的完備性差異的原因，不同的IMA方案很難在性能開銷方面形成具有可比性的對(duì)照評(píng)估.因此，本文主要對(duì)受DIMAK保護(hù)的Linux系統(tǒng)與同版本的標(biāo)準(zhǔn)Linux系統(tǒng)進(jìn)行性能層面上的對(duì)比分析.

3.4.1 執(zhí)行時(shí)間開銷

從設(shè)計(jì)原理出發(fā)可以初步判斷，DIMAK可能引起執(zhí)行時(shí)間方面的性能開銷的操作主要包括：

1)系統(tǒng)啟動(dòng)過(guò)程中，校驗(yàn)內(nèi)核鏡像及載入的KO模塊，并為二者更新動(dòng)態(tài)基線；

2)進(jìn)程創(chuàng)建時(shí)，或在進(jìn)程執(zhí)行過(guò)程中發(fā)生共享庫(kù)動(dòng)態(tài)加載時(shí)，對(duì)被加載的可執(zhí)行文件進(jìn)行校驗(yàn)，并為其動(dòng)態(tài)鏈接/重定位信息生成動(dòng)態(tài)基線.

其他可能引起執(zhí)行時(shí)間開銷的操作還包括DIMAK在進(jìn)程執(zhí)行過(guò)程中發(fā)生動(dòng)態(tài)代碼改寫(包括惡意篡改行為和正常的軟件熱修復(fù))時(shí)的校驗(yàn)和基線更新/維護(hù)行為.然而，考慮到此類事件并非嵌入式系統(tǒng)運(yùn)行時(shí)出現(xiàn)的常態(tài)行為，故本文不將其視作DIMAK的常規(guī)性能開銷.此外，對(duì)于占軟件系統(tǒng)運(yùn)行周期主要部分的進(jìn)程執(zhí)行階段，DIMAK并不產(chǎn)生可測(cè)量范圍內(nèi)的常規(guī)開銷.

本文對(duì)執(zhí)行時(shí)間開銷的測(cè)試采用了一臺(tái)搭載8核1.35 GHz主頻的ARM v7處理器、具有6 GB運(yùn)行內(nèi)存、搭載內(nèi)核版本5.1.0的Linux系統(tǒng)的嵌入式接入設(shè)備作為真機(jī)測(cè)試對(duì)象.本文進(jìn)行的第一項(xiàng)實(shí)驗(yàn)分別測(cè)試了上述測(cè)試設(shè)備分別在DIMAK功能啟用和禁用狀態(tài)下的系統(tǒng)啟動(dòng)時(shí)間、用戶態(tài)進(jìn)程創(chuàng)建時(shí)間和單個(gè)共享類庫(kù)的動(dòng)態(tài)載入時(shí)間.其中，選自開源嵌入式測(cè)試集MiBench的9個(gè)實(shí)例dijkstra,patricia,blowfish,SHA,adpcm,CRC32,FFT,basicmath和qsort被用于測(cè)試用戶態(tài)進(jìn)程創(chuàng)建時(shí)間，而標(biāo)準(zhǔn)系統(tǒng)庫(kù)glibc則被用于測(cè)量單個(gè)共享類庫(kù)的載入時(shí)長(zhǎng).

如表3所示，可以看到DIMAK所引入的執(zhí)行時(shí)間開銷主要分布于用戶態(tài)進(jìn)程的創(chuàng)建過(guò)程以及運(yùn)行時(shí)單個(gè)共享庫(kù)的動(dòng)態(tài)載入過(guò)程.這主要可以歸因于該架構(gòu)通過(guò)對(duì)ELF文件動(dòng)態(tài)鏈接/重定位信息的搶先預(yù)測(cè)以更新和維護(hù)其只讀結(jié)構(gòu)化數(shù)據(jù)段動(dòng)態(tài)基線的功能設(shè)計(jì).盡管如此，經(jīng)過(guò)DIMAK驗(yàn)證的進(jìn)程創(chuàng)建和單個(gè)共享庫(kù)動(dòng)態(tài)載入過(guò)程的總體時(shí)間開銷仍然處于毫秒級(jí)，且DIMAK在未涉及到動(dòng)態(tài)鏈接行為的系統(tǒng)啟動(dòng)過(guò)程中所引起的開銷僅為7.532%.考慮到多數(shù)嵌入式系統(tǒng)中所運(yùn)行的用戶態(tài)進(jìn)程具有較高的穩(wěn)定性，即進(jìn)程不會(huì)頻繁地被創(chuàng)建/終止，可以認(rèn)為：通過(guò)將主要性能瓶頸從運(yùn)行時(shí)轉(zhuǎn)嫁到加載時(shí)，DIMAK有效地降低了其保護(hù)功能為系統(tǒng)帶來(lái)的性能負(fù)擔(dān).

在此基礎(chǔ)上，本文所進(jìn)行的第2項(xiàng)實(shí)驗(yàn)進(jìn)一步測(cè)試了各MiBench實(shí)例在DIMAK功能啟用/禁用狀態(tài)下的實(shí)際執(zhí)行性能，以此評(píng)估DIMAK可能為嵌入式系統(tǒng)中運(yùn)行的用戶應(yīng)用程序所帶來(lái)的執(zhí)行性能開銷.其中，對(duì)于每個(gè)被測(cè)MiBench實(shí)例，實(shí)驗(yàn)中采用其自帶的大型測(cè)試數(shù)據(jù)集作為運(yùn)行輸入，并測(cè)量其在DIMAK啟用/禁用情況下的各10次完整執(zhí)行所消耗的平均執(zhí)行時(shí)間.如表4所示，實(shí)測(cè)中各MiBench實(shí)例在DIMAK啟用/禁用狀態(tài)下的平均執(zhí)行時(shí)間相差均在1%以下.這一結(jié)果進(jìn)一步支持了前述結(jié)論，即：由于DIMAK的主要開銷發(fā)生在應(yīng)用程序加載過(guò)程中，其對(duì)嵌入式系統(tǒng)帶來(lái)的實(shí)際性能負(fù)擔(dān)幾乎可以忽略.

Table 3 Runtime Overhead of DIMAK in Cases of System Booting, Process Creating and Dynamic Library Loading

Table 4 Runtime Overhead of DIMAK During the Execution of User Processes

3.4.2 運(yùn)行內(nèi)存開銷

由于嵌入式系統(tǒng)往往傾向于最大化利用計(jì)算資源，故其為附加安全功能預(yù)留的可擴(kuò)展空間通常極為有限，使得運(yùn)行內(nèi)存開銷成為一個(gè)IMA架構(gòu)是否適合嵌入式系統(tǒng)的重要指標(biāo).而從DIMAK的設(shè)計(jì)原理觸發(fā)，可以判斷其運(yùn)行內(nèi)存開銷主要包括3個(gè)方面：

1)對(duì)靜態(tài)/動(dòng)態(tài)基線組的維護(hù)，是DIMAK的一項(xiàng)常規(guī)內(nèi)存開銷；

2)在對(duì)任意被度量實(shí)體實(shí)施完整性驗(yàn)證時(shí)，所需要的緩沖區(qū)、環(huán)境變量等關(guān)鍵數(shù)據(jù)是DIMAK的一項(xiàng)臨時(shí)內(nèi)存開銷；

3)在對(duì)用戶態(tài)ELF文件實(shí)施動(dòng)態(tài)鏈接/重定位信息的搶先預(yù)測(cè)時(shí)，DIMAK所需維護(hù)的諸如依賴文件列表等關(guān)鍵數(shù)據(jù)是其另一項(xiàng)臨時(shí)內(nèi)存開銷.

為了解上述運(yùn)行內(nèi)存開銷可能給嵌入式系統(tǒng)帶來(lái)的實(shí)際性能負(fù)擔(dān)，本文采用與3.4.1節(jié)相同的嵌入式接入設(shè)備為測(cè)試對(duì)象，對(duì)DIMAK進(jìn)行了兩項(xiàng)真機(jī)測(cè)試，分別模擬了其總體性能開銷最大的系統(tǒng)全量掃描過(guò)程(即對(duì)系統(tǒng)環(huán)境內(nèi)的所有被度量實(shí)體進(jìn)行遍歷完整性驗(yàn)證)和可以視為性能開銷基本單元的單個(gè)共享庫(kù)動(dòng)態(tài)載入過(guò)程.結(jié)果顯示：

1)常規(guī)狀態(tài)下，DIMAK的自身代碼占用內(nèi)存共計(jì)為3 120 KB；

2)在全量掃描中，DIMAK對(duì)總計(jì)3 481 MB的運(yùn)行數(shù)據(jù)實(shí)施了完整性檢驗(yàn)，其自身的運(yùn)行內(nèi)存占用僅為2 MB；

3)在共享庫(kù)動(dòng)態(tài)載入時(shí)，DIMAK的平均內(nèi)存開銷僅為4.1 KB.

上述數(shù)據(jù)充分顯示了DIMAK在內(nèi)存開銷方面的設(shè)計(jì)優(yōu)勢(shì)，我們有充分的理由相信：即使被應(yīng)用于硬件性能更為有限的其他嵌入式設(shè)備，DIMAK仍然能夠以極低的內(nèi)存占用實(shí)現(xiàn)對(duì)系統(tǒng)的運(yùn)行時(shí)完整性驗(yàn)證保護(hù).

4 結(jié) 論

本文提出了一種針對(duì)嵌入式Linux操作系統(tǒng)的實(shí)用化完整性度量架構(gòu)DIMAK.DIMAK在設(shè)計(jì)上采用了依托系統(tǒng)內(nèi)核空間與TEE環(huán)境的逐級(jí)信任擴(kuò)展機(jī)制，并根據(jù)位于內(nèi)核及用戶空間內(nèi)的可執(zhí)行文本、靜態(tài)數(shù)據(jù)以及動(dòng)態(tài)鏈接信息等各種被度量實(shí)體的不同類型，采用了靈活的靜態(tài)/動(dòng)態(tài)雙基線組的完整性基線維護(hù)策略.通過(guò)對(duì)Linux內(nèi)核代碼內(nèi)的關(guān)鍵函數(shù)實(shí)施inline hooking的方式，DIMAK所建立的狀態(tài)感知界面能夠在不探入用戶空間的情況下感知并介入由用戶進(jìn)程發(fā)起的、可能影響系統(tǒng)完整性狀態(tài)的程序行為，從而保證了該架構(gòu)完整性驗(yàn)證行為的正確性.此外，借助專門的私有協(xié)議設(shè)計(jì)，DIMAK還能夠在無(wú)需用戶/內(nèi)核代碼協(xié)助的情況下實(shí)現(xiàn)對(duì)用戶態(tài)軟件熱修復(fù)功能的支持.真機(jī)測(cè)試顯示，本文所述的完整性度量架構(gòu)產(chǎn)生的性能開銷完全可以滿足嵌入式設(shè)備場(chǎng)景下的實(shí)際應(yīng)用要求，同時(shí)在安全特性方面優(yōu)于現(xiàn)有同類技術(shù).

作者貢獻(xiàn)聲明：賈巧雯和馬昊玉負(fù)責(zé)方案設(shè)計(jì)與論文撰寫；厲嚴(yán)和王哲宇負(fù)責(zé)實(shí)驗(yàn)與數(shù)據(jù)整理；石文昌負(fù)責(zé)方案和實(shí)驗(yàn)指導(dǎo).