基于嵌入式可信平臺的運行時監控方法

孫召昌，馬建峰，孫聰，盧笛

（西安電子科技大學網絡與信息安全學院，陜西 西安 710071）

基于嵌入式可信平臺的運行時監控方法

孫召昌，馬建峰，孫聰，盧笛

（西安電子科技大學網絡與信息安全學院，陜西 西安 710071）

當前可信計算平臺缺乏對自身運行時安全屬性的監控，對此，提出一種針對嵌入式可信平臺的運行時監控方法。通過自動化的代碼插入和運行時實時監控，保證可信平臺的運行時安全功能符合設計規范，并保證系統性能和運行狀態符合特定條件約束，同時對相應的異常進行實時處理。實驗結果表明，隨著監控節點數的增長，監控的準確性和實時性提高，而監控開銷和異常處理開銷處于合理范圍。

可信計算；運行時監控；嵌入式系統；線性時序邏輯

1 引言

可信計算技術通過建立硬件可信根和信任鏈保證系統的安全性和完整性，是信息系統安全領域長期以來的研究熱點。依據可信計算組織（TCG,Trusted Computing Group）的可信平臺架構定義[1]，TCG軟件棧（TSS, TCG software stack）是可信平臺的軟件核心，用于保證應用程序對可信平臺模塊（TPM, trusted platform module）硬件功能（完整性度量、安全存儲、對稱/非對稱加解密等）的有效使用。在嵌入式系統領域，可信平臺可用于構建安全實時操作系統，為系統內核提供可信功能支持[2]?？尚畔到y的構建[3,4]通常假定可信平臺的初始完整性在可信平臺運行過程中能夠保持，而對可信平臺自身的分析驗證[5～7]則側重于靜態驗證，以上2方面研究均無法對部署后TSS在實際運行過程中產生的非法輸入、服務狀態異常等安全問題進行監控，也無法對嵌入式可信平臺的性能和線程狀態等關鍵運行時屬性提供監控。

針對以上問題，本文提出一種嵌入式可信平臺的運行時監控方法，根據TSS設計規范，從功能、性能、系統狀態和輸入等方面定義監控屬性，根據屬性定義，自動生成并插入監控代碼和異常處理代碼。得到的TSS監控系統保持原有TSS功能，并在運行時驗證可信平臺是否違反監控屬性，同時能根據不同安全等級對違反監控屬性的異常狀態進行實時處理。實驗結果表明，隨著監控節點數的增加，監控的準確性和實時性提高，而監控開銷和異常處理開銷處于合理范圍。

圖1 TSS監控系統的構建和處理流程

2 嵌入式可信平臺運行時監控方法

嵌入式可信平臺作為被監控對象，包括可信平臺模塊和可信軟件棧這2個部分。TSS為上層應用程序提供服務接口，保證上層應用程序對TPM的同步訪問和有效應用。TSS自下而上分為3層[1]。1) TCG設備驅動庫（TDDL, TCG device driver library）：提供系統無關的TPM調用接口，保證對TPM的串行訪問；2) TSS核心服務（TCS, TSS core service）：提供密鑰管理、TPM命令同步等核心功能；3) TCG服務提供者（TSP, TCG service provider）：提供面向對象的應用程序服務接口。

由于 TPM 的主要功能由 TSS調用并反映于TSS狀態，本文在TSS上構建嵌入式可信平臺的運行時監控系統。圖1為TSS監控系統的構建和處理流程。首先，根據TSS的設計規范和系統要求確定監控屬性，并用線性時序邏輯（LTL, linear temporal logic）對監控屬性進行形式化描述，然后根據屬性的形式化描述自動生成監控代碼并插入TSS原系統，得到TSS監控系統，將該系統部署在嵌入式操作系統（如VxWorks）平臺上運行。

TSS監控系統運行時，被監控的TSS程序線程中與監控屬性相關的系統狀態、功能和性能變量狀態值被發送至一個事件隊列，一個獨立的監控線程通過動態周期輪詢的方式對事件隊列中的變量信息進行采樣，并依據采樣結果驗證系統狀態是否滿足屬性要求。當發現違反監控屬性的異常狀態時，根據屬性類型采取相應的異常處理機制。監控過程不影響原有TSS功能的正常調用。

2.1 屬性規約

根據可信軟件棧TSS的設計規范[1]和系統安全需求，將監控的目標屬性分為功能、性能、系統狀態、合法輸入4類，具體描述如下。

1) 功能屬性：主要包括密鑰合法性、度量權限和認證順序3種屬性。其中，密鑰合法性指所生成（使用）密鑰的長度與系統規定的長度一致，且密鑰的使用時長在更新周期范圍內；度量權限指度量信息的讀取操作需要普通用戶權限，寫入操作必須具有高級用戶權限；認證順序指遠程認證只能在自身認證完成后才能調用，由所使用的TSS中認證相關接口的具體設計決定。

2) 性能屬性：主要包括隊列長度、優先級設置和響應時間3種屬性。其中，隊列長度屬性表示 TCS層命令隊列的實時長度不能大于系統規定的長度上限；優先級設置屬性指從命令隊列取出的命令始終是該隊列中優先級最高的命令；響應時間屬性指TDDL向TPM發起請求與從TPM接收數據之間的時間間隔在系統規定的時間間隔范圍內。

3) 系統狀態屬性：主要指對線程狀態的收集和分析，系統運行過程中，線程狀態必須與系統規定的合法狀態保持一致，合法的系統狀態包括就緒態、阻塞態、延遲態和掛起態。監控的目標線程主要包括TCS層命令接收線程、命令分發線程、遠程服務線程等。

4) 合法輸入屬性：主要指上層應用程序提供的接口輸入參數個數、類型和數據長度必須滿足所調用接口的特定要求。

使用線性時序邏輯 LTL[8]對以上各類目標屬性進行描述，具體描述如表1所示，其中的屬性公式表示一類形式近似的屬性公式的共同模式。針對TSS的分層設計，為不同的目標屬性選擇適合的監控層次，從而保證運行時監控的正確性和及時性。如對度量權限屬性選擇在TSP層監控，可以對屬性狀態做出及時有效的判斷，減少系統開銷。

表1 監控屬性描述

2.2 屬性異常處理機制

不同屬性的異常處理機制與所處的監控層次有關，表2為不同監控層次的屬性設定對應的安全等級和異常處理機制，安全等級越高，對應的異常處理機制越復雜。其中，TCS層屬性與可信平臺核心服務的正常運行緊密相關，安全等級最高，屬性異常時掛起系統服務；TDDL層屬性與系統功能調用的正確性有關，屬性異常時系統自動完成對當前接口的重新調用；TSP層屬性與用戶調用可信服務的合法性有關，安全等級最低，屬性異常時終止當前接口調用。

為提高監控系統的可用性，由TCS層的屬性處理線程對各屬性監控結果進行統一管理。算法 1描述了對監控屬性的異常處理，監控線程（MonitorThread）獲取系統運行過程中的目標屬性狀態（第3行），如果發現屬性異常，及時將該異常屬性的類別信息發送至屬性消息隊列（第5行～第6行），否則，直接完成屬性狀態的報告。屬性處理線程（PropertyHandlerThread）接收屬性消息隊列的屬性異常信息（第13行）并獲取該屬性的安全等級（第14行），根據安全等級采取適合的異常處理機制（第15行～第29行）。

表2 屬性安全等級分類

算法1監控屬性的異常處理

1)ProcedureMonitorThread()

2) ……

3) status ← getPropertyStatus();

4)Ifstatus == violatedThen

5) property ← getCurrentProperty();

6) sendProInfoToQ(property);

7)Else

8) 完成屬性狀態報告;

9)End If

10)End Procedure

11)ProcedurePropertyHandlerThread()

12)WhiletrueDo

13) property ← recvProInfoFromQ();

14) level ← getSecurityLevel(property);

15)Iflevel == 0Then

16)Foreach taskId created in TCSDo

17) taskSuspend(taskId);

18)End For

19)Else Iflevel == 1Then

20) 終止當前接口調用;

21) newResult ←funcInterfaceCall();

22)IfnewResult == falseThen

23) 輸出錯誤信息;

24)ElseIfnewResult == trueThen

25) result ← newResult;

26)EndIf

27)ElseIflevel == 2Then

28) 終止當前接口調用;

29)End If

30)End While

31)End Procedure

2.3 監控代碼的生成和插入

本文通過對 RiTHM 工具[9]進行擴展完成監控代碼的生成工作。該工具的輸入為原始系統代碼和由LTL描述的監控屬性（表1中監控屬性均對應于獨立的配置文件），輸出為用于實時監控的系統監控程序代碼。該程序在運行時生成獨立的監控線程，不影響原有程序線程的正常執行。

針對嵌入式系統環境和可信平臺的具體異常處理要求，本文實現的擴展工具能夠自動化完成以下代碼轉換操作。

1) 為使監控系統能夠運行于嵌入式系統環境，自動化以下過程：① 用嵌入式系統（VxWorks）庫函數替換通用系統（Linux）庫函數；② 去除監控系統對于嵌入式環境無法支持的OpenCL函數庫的依賴；③ 執行必要的語法規則轉換，以使C++代碼符合嵌入式操作系統要求。

2) 自動生成第2.2節算法1所述的屬性異常處理機制的實現代碼，并將異常處理代碼自動插入原代碼。

3) 增加對多配置文件輸入和多屬性監控功能的支持，完成不同屬性監控代碼的復用。

工具擴展前后的功能對比如表3所示。

3 實現和評價

本節首先分析監控系統的生成開銷，然后對監控系統的監控準確性、實時性和監控過程開銷進行驗證和評價。

表3 RiTHM工具擴展前后的功能對比

3.1 RiTHM工具時間開銷分析

圖2表示RiTHM工具擴展前后自動生成不同目標屬性對應監控代碼的時間開銷對比，圖 2表明，對工具擴展后，其時間開銷比原工具高2.4%。但由于監控代碼的生成過程是一個離線處理過程，可在通用計算環境中預先完成，因而時間開銷的增加不會影響嵌入式環境下監控系統的運行開銷。

圖2 RiTHM工具擴展前后的時間開銷對比

3.2 實驗環境與錯誤注入

本節實驗用于評價嵌入式可信平臺運行時監控方法的準確性、實時性和監控開銷，在筆者團隊已實現的嵌入式可信軟件棧上進行。實驗環境由POWERPC開發板和iTOP-4412開發板組成，如圖3所示。其中，POWERPC開發板（MPC8247-400 MHz CPU/128MB SDRAM）運行VxWorks 5.5嵌入式實時系統，用于部署和運行TSS監控系統，并向VxWorks上層應用程序提供加解密、度量、認證等可信服務；iTOP-4412開發板（Exynos4412 Cortex-A9 1.4～1.6 GHz CPU/ 2GB DDR3 RAM）運行Linux操作系統，其上部署TPM Emulator，用于模擬TPM 的度量、加解密等功能。開發板之間通過串口通信完成命令和數據的傳輸。

結合表1和表2對監控屬性的描述和分類，選取不同監控層次和安全等級上的3種屬性（隊列長度、密鑰合法性和度量權限）進行實驗。針對各屬性的不同要求，分別自動化隨機生成2 000條數據（含非法數據）作為軟件錯誤注入[10]的測試用例，其中，與隊列長度相關的非法數據指超出系統規定范圍的隊列長度值，與密鑰合法性相關的非法數據指不滿足獲取密鑰接口指定的密鑰長度值，與度量權限相關的非法數據指不滿足度量相關接口要求的用戶權限等級值。在被注入數據中，統計不滿足屬性要求的非法數據的比率分別為73.7%、87.4%、81.3%。

使用上述測試用例進行軟件錯誤注入測試，由上層應用程序對TSP層的可信服務接口進行多次調用，每次調用過程中，在目標屬性所處的監控層次創建錯誤注入線程，讀取一組測試用例并修改目標屬性相關的程序變量，完成TSS監控系統非法數據的隨機注入。同時，在該監控層次的不同代碼位置插入監控程序，驗證監控屬性相關的程序變量是否符合屬性要求，每個位置插入一條監控程序，不同位置插入的監控程序數量稱為監控節點數（number of monitor node）。

3.3 實驗結果

實驗從準確性、實時性、監控開銷3方面進行評價。其中，準確性指實際監控到的錯誤數占注入錯誤總數的比例。實時性指錯誤發生時刻與該錯誤被監控到的時刻之間的時間間隔，時間間隔越短，實時性越強。監控開銷分為時間開銷和內存開銷，時間開銷指從接口調用到返回結果所用的時間，內存開銷指軟件系統運行過程中的平均內存分配。

對實驗結果數據進行收集和分析，得到監控3種屬性時，監控系統的準確性和實時性、時間開銷及內存開銷對比分別如圖4～圖6所示。

圖4(a)說明，對于3種不同屬性（度量權限、隊列長度、密鑰合法性）的監控準確性均隨著監控節點數的增加而以近似線性趨勢上升，當監控節點數足夠多時，準確率可達100%。圖4(b)說明，對3種屬性的監控實時性具有相似的變化趨勢，隨著監控節點數的增加，錯誤發生時刻與該錯誤被監控到的時刻之間的時間間隔不斷減小，監控系統的實時性變強，同時，時間間隔的變化趨勢隨監控節點數的增加而逐漸減緩。

圖3 實驗硬件環境

在圖5和圖6中，TSS system為TSS原系統對應的開銷；TSS monitor system指無異常處理的監控系統對應的開銷；TSS exception handling system指加入異常處理的監控系統對應的開銷。圖5和圖6說明，3種屬性對應的監控系統，無論是否進行異常處理，其監控時間開銷和內存開銷均隨監控節點數的增加而增加，且始終高于TSS原系統。

圖5 監控系統的時間開銷

由于各屬性的異常處理方式不同，異常處理導致的開銷增長也各不相同。對于度量權限屬性，發生異常時，根據表2規則終止服務調用并返回錯誤信息，服務調用次數減少，因此添加異常處理功能后，監控系統的時間開銷和內存開銷總體上明顯降低，如圖 5(a)和圖 6(a)所示。對于隊列長度屬性，發生異常時，依據表2規則掛起系統服務，由于異常屬性信息的傳輸以及對各服務的掛起操作，導致添加異常處理功能后，監控系統的時間開銷和內存開銷均小幅增加，如圖 5(b)和圖6(b)所示。對于密鑰合法性屬性，發生異常時，系統根據表2規則自動完成對當前接口的重新調用，導致接口調用次數增多，因此添加異常處理功能后，監控系統的時間開銷和內存開銷均明顯增加，如圖5(c)和圖6(c)所示。

圖6 監控系統的內存開銷

雖然實驗表明，監控開銷隨監控節點數增加持續增長，但對于實際系統，監控節點數的選取應以滿足系統對監控準確性和實時性的具體要求為依據，滿足要求后，監控節點數不用繼續增加，此時的監控開銷為實際監控開銷。針對當前嵌入式軟件棧，實際監控開銷能夠保證監控系統在嵌入式環境下可用。

4 結束語

本文提出的針對嵌入式可信平臺的運行時監控方法，通過擴展運行時驗證工具 RiTHM 實現對嵌入式可信平臺的功能屬性、性能屬性、系統狀態屬性及合法輸入屬性的運行時監控和自動化異常處理。本文方法保證了運行無異常的嵌入式可信平臺滿足預定義的系統屬性，從而保證系統整體持續可信。當前方法提供的監控屬性類別仍不完備，監控開銷與監控節點數相關性明顯，未來研究將圍繞增加屬性類別、減少監控開銷、完善異常處理機制等方面展開。

[1] Trusted computing group. TCG specification architecture overview[EB/OL]. http://www.trustedcomputinggroup.org/resources/tcg_architecture_overview_version_14.

[2] WANG X, MIZUNO M, NEILSEN M, et al. Secure RTOS architecture for building automation[C]//ACM Workshop on Cyber-Physical Systems-Security and/or Privacy. 2015:79-90.

[3] YU Z, WANG Q, ZHANG W, et al. A cloud certificate authority architecture for virtual machines with trusted platform module[C]//IEEE International Conference on High Performance Computing and Communications. 2015:1377-1380.

[4] TIAN J, BUTLER K, MCDANIEL P, et al. Securing ARP from the ground up[C]//The 5th ACM Conference on Data and Application Security and Privacy. 2015:305-312.

[5] SHAO J，QIN Y，FENG D, et al. Formal analysis of enhanced authorization in the TPM 2.0[C]//The 10th ACM Symposium on Information, Computer and Communications Security. 2015:273-284.

[6] WANG W, QIN Y, FENG D. Automated proof for authorization protocols of TPM 2.0 in computational model information security practice and experience[M]. Berlin: Springer. 2014: 144-158.

[7] DELAUNE S, KREMER S, RYAN M D, et al. A formal analysis of authentication in the TPM[C]//The International Conference on Formal Aspects of Security and Trust. 2010: 111-125.

[8] BAIER C, KATOEN J. Principles of model checking[M]. London:The MIT Press, 2008: 595-663.

[9] NAVABPOUR S, JOSHI Y, WU W, et al. RiTHM: a tool for enabling time-triggered runtime verification for C programs[C]//Joint Meeting on Foundations of Software Engineering. 2013: 603-606.

[10] BIEMAN J M, DREILINGER D, LIN L. Using fault injection to increase software test coverage[C]//The Seventh International Symposium on Software Reliability Engineering, IEEE Computer Society. 1996:166.

Approach on runtime monitoring based on the embedded trusted platforms

SUN Zhao-chang, MA Jian-feng, SUN Cong, LU Di

(School of Cyber Engineering, Xidian University, Xi’an 710071, China)

The state-of-art trusted computing platforms fall short of monitoring its own runtime security properties.In order to mitigate these problems, an approach on runtime monitoring for the embedded trusted platforms was proposed. With the automated code instrumentation and the runtime monitoring, that the runtime security functionalities were consistent with the design specifications of trusted computing platforms could be made sure. The system performance and states meet specific constraints could also be ensured. The runtime exceptions on the specific properties were handled in real-time. The experimental results show that with the increase on the number of monitoring nodes, the precision and real-time performance of proposed runtime monitoring increase. Meanwhile, the costs on the monitoring and the exception handling are moderate.

trusted computing, runtime verification, embedded system, linear temporal logic

s：The National Natural Science Foundation of China (No.61303033, No.U1405255), The National High Technology Research and Development Program of China (863 Program) (No.2015AA017203), The Natural Science Basis Research Plan of Shaanxi Province (No.2016JM6034), The Aviation Science Foundation of China (No.20141931001), The Special Research Foundation of MIIT (No.MJ-2014-S-37)

TP393

A

10.11959/j.issn.2096-109x.2017.00209

2017-07-01；

2017-09-16。

孫召昌，zhchsun1992@gmail.com

國家自然科學基金資助項目（No.61303033, No.U1405255）；國家高技術研究發展計劃（“863”計劃）基金資助項目（No.2015AA017203）；陜西省自然科學基礎研究計劃基金資助項目（No.2016JM6034）；航空科學基金資助項目（No.20141931001）；工信部某專項科研基金資助項目（No.MJ-2014-S-37）

孫召昌（1992-），男，河北邢臺人，西安電子科技大學碩士生，主要研究方向為可信計算、運行時監控。

馬建峰（1963-），男，陜西西安人，西安電子科技大學教授、博士生導師，主要研究方向為密碼學、無線和移動安全。

孫聰（1982-），男，陜西興平人，博士，西安電子科技大學副教授，主要研究方向為信息流安全、可信軟件。

盧笛（1983-），男，陜西安康人，博士，西安電子科技大學講師，主要研究方向為云計算、網絡與系統安全。