一種基于影子頁表+ 的軟件型vTPM 密鑰秘密信息保護方案*

譚 良, 王 閃, 宋 敏, 舒紅梅

1.四川師范大學計算機科學學院, 成都610101

2.中國科學院計算技術研究所, 北京100190

1 引言

云計算的主要目的在于幫助租戶擺脫紛雜的硬件管理與維護, 實現系統資源的深度整合.通過統一管理模式提高資源利用率的同時, 滿足各類租戶的個性化需求.其實現方式決定了租戶的數據信息勢必會存儲在公用數據中心, 數據的讀取完全依賴于網絡傳輸．因此, 云計算系統不僅面臨著傳統網絡和信息系統等已有的安全問題, 還面臨著由其運營特點所產生的一些新的安全威脅[1–4]．其中, 云租戶怎樣確定云平臺提供的資源和服務是安全的, 怎樣確保云平臺是可信的, 這是一個至關重要的問題.而可信計算是保障計算平臺可信的基礎手段, 它通過提供數據保護、身份證明以及完整性測量、存儲與報告等功能提高計算平臺整體的可信性[5].因此, 將可信計算技術融入虛擬平臺已成為云安全研究領域的一大熱點[6–22].

TPM (trusted platform module, TPM)是可信計算的核心, 提供平臺完整性度量、遠程證明、密封存儲、平臺唯一身份標識、硬件級的密鑰保護等基本安全功能, 為可信計算提供基礎硬件支撐.2009年TPM1.2 規范被接受為ISO 標準(ISO/IEC 11889)[23].TPM1.2 芯片內部是一個完整的安全計算環境, 內部結構包括低功耗的32 位RISC CPU、CPU 訪問片內外圍模塊的通道、中斷控制器(interrupt controller)、時鐘發生器(clock generator)、對外IO 端口、RAM、ROM、Flash、SHA/HMAC 模塊、RSA 協處理器模塊、真隨機數產生模塊等模塊, 通過LPC 總線接口放置在主板上.2014年TCG 發布了TPM2.0 規范[24], 在密碼算法支持、密鑰、授權、簽名、平臺配置寄存器PCRs、虛擬化以及芯片使用方式等方面均有些新的特點.但無論是TPM1.2 還是TPM2.0 均是一個資源受限的芯片, 其本質上是一個低速的外設.然而隨著云計算的推廣和普及, 云租戶逐漸增多, 云平臺上運行的用戶虛擬機也越來越多, 云平臺上的所有虛擬機和云租戶都通過共享方式來使用TPM 提供的完整性度量、遠程證明、密封存儲、硬件級密鑰保護等安全功能是很困難的, 性能上也是難以接受的.因此, 當前不少云平臺在對TPM虛擬化時采用軟件仿真方式, 如XEN、KVM、VMWare、VirutalBox、Hyper-V 等, 即用軟件vTPM來模擬TPM 功能, 使用得到最多的TPM 模擬器是tpm_emulator.

值得注意的是, 一方面, 云平臺的運行環境嚴重影響軟件仿真型vTPM 的安全.Gartner 云安全報告中指出, 云平臺的最大的安全威脅來自于特權用戶對于租戶隱私數據的非法訪問[3], 顯然軟件型vTPM 運行時的密鑰和證書信息也不例外.當然非特權用戶也可以采用包括惡意代碼注入攻擊(malware injection attack)、交叉虛擬機邊信道攻擊(cross VM side channels attack)和定向共享內存攻擊(targeted shared memory)等[2]來竊取和破壞vTPM 的密鑰和證書信息, 其中惡意代碼注入攻擊是使用惡意實例代替系統服務實例處理正常的服務請求, 進而獲得特權訪問能力, 非法盜取vTPM 的密鑰和證書信息; 交叉虛擬機邊信道攻擊是攻擊者首先借助惡意虛擬機訪問共享硬件和緩存, 然后執行預定的安全攻擊, 最終導致目標虛擬機內vTPM 的秘密數據泄露; 定向共享內存攻擊是以物理機或虛擬機的共享內存或緩存為攻擊目標, 是惡意代碼注入攻擊與邊信道攻擊的基礎, 結合內部攻擊訪問虛擬機的內存轉儲數據導致vTPM 密鑰信息的泄露.另一方面, 即使采用硬件TPM 安全存儲vTPM 的密鑰信息,vTPM 在進行加解、解密、完整性驗證等操作時, 也必須把vTPM 密鑰信息加載到內存中, 特別在全虛擬化和硬件虛擬化平臺環境中, 整個虛擬機均處于VMM (virtual machine monitor, VMM)的用戶空間中, vTPM 的密鑰和證書更容易遭到攻擊, 這將嚴重影響虛擬機和vTPM 的安全.

為此,本文提出了一種基于影子頁表+的vTPM 密鑰秘密信息保護方案,該方案主要是在全虛擬化或硬件虛擬化平臺中通過新增影子頁表管理模塊MMU-vTPM 來保護vTPM 的密鑰和證書.MMU-vTPM包括兩個部分, 其一是vTPM 密鑰私有內存管理, 其二是vTPM 密鑰私有內存訪問控制, 該管理模塊通過對vTPM 密鑰私有內存頁表的訪問控制阻止其他進程訪問和破壞vTPM 密鑰私有內存.此外, 為了防止惡意用戶對MMU-vTPM 模塊進行篡改, 本文采用TPM 的靜態度量機制和動態度量機制對該模塊進行完整性保護.最后, 基于Xen 實現了該方案, 測試結果表明, 該方案能夠在保證vTPM 的vEK 和vSRK 等關鍵密鑰秘密信息的安全性, 而且不會帶來嚴重的性能損失.

2 相關工作

可信計算技術與虛擬化技術結合的vTPM 一直以來都受到國內外學者的廣泛關注.目前已經有涌現出較多研究成果[6–31].在國外, 早在2006年S Berger 等人就提出了一種軟件仿真型的vTPM 架構[25].如圖1 所示, 該系統架構包括vTPM、vTPM manager、Client-side TPM driver、Server-side TPM driver、TPM 等實體, 其中, vTPM、vTPM manager 和Server-side TPM driver 在特權域, Client-side TPM driver 在虛擬機域, TPM 在整個虛擬系統的底層硬件層.vTPM 為虛擬機提供大部分可信計算功能, vTPM manager 負責所有vTPM 的生命周期管理, 包括創建、掛起、恢復、刪除vTPM 實例,轉發虛擬機對其綁定的vTPM 實例請求并返回對應的響應, 每個vTPM 可通過vTPM manager 與硬件TPM 產生關聯, 關聯的內容主要包括PCR 映射和證書鏈擴展.Server-side TPM driver 是特權域端TPM 驅動, Client-side TPM driver 是虛擬機端TPM 驅動, Server-side TPM driver 與Client-side TPM driver 通過VMM 進行通信.文獻[31]是TPM 半虛擬化的奠基之作, 后來該方向的多數研究均基于這一思路.

文獻[26]也提出了TPM 虛擬化的一個通用系統架構GVTPM, 文獻[25,26]的基本思路是一致的.文獻[27]基于Xen 首次把vTPM 實例從特權域中分離, 但vTPM manager、vTPMD 守護進程仍然運行在Domain0.文獻[28]對vTPM manager、vTPM 實例與特權域進一步分離, 將特權域中的一個重要功能——域管理功能分離出來, 基于MiniOS 構建Domain Builder 域, 簡稱為DomB, 并將vTPM manager 和vTPM 實例從特權域中分離到DomB.2009年, 歐盟委員會贊助的一個可信計算項目OpenTC 提出了一個有關TPM 虛擬化架構的研究報告[29], 將vTPM 基于屬性的證明和遷移功能增加到vTPM 架構中, 并在Xen 平臺上提出了雙隔離域系統架構, 進一步分離了文獻[28]中的DomB的功能.在該系統架構中包括兩個域, 其一是DomB, 該DomB 與文獻[28]中的DomB 類似; 其二是DomU-vTPM, DomU-vTPM 域運行vTPM 實例.除此以外, 通過隔離域來增強vTPM 安全性的文獻還包括文獻[11,30–34]等.這里不再一一分析.

在國內, 類似的文獻出現在2010年, 文獻[35]認為, 將整個特權域都看成TCB 會威脅到vTPM 的安全, 因為TCB 太大容易產生漏洞.為了解決這個問題, 文獻[35]提出了一種新的vTPM 架構.通過創建一個新的管理域Dom A, 將原來在特權域中的vTPM、vTPM manager 以及TPM 原生驅動分離到管理域DomA 中.創建管理域有兩個目的, 其一是使得vTPM 及其相關組件免受非法訪問和調用, 其二是修改TPM 的訪問流程, 并通過TPM 來保護DomA, 提高vTPM 及其相關組件的安全性.為了防止云環境中攻擊者可能利用虛擬機的回滾機制(一種重要和常用的功能)發起攻擊, 文獻[36]基于Xen提出了抵御回滾的可信虛擬平臺模塊(rollback-resilient TPM, rvTPM)系統架構, 并在Xen 中實現了rvTPM 原型系統.

圖1 vTPM 系統架構Figure 1 vTPM architecture

通過以上分析發現, 關于vTPM 架構的研究雖然能夠在一定程度上提高vTPM 的安全性, 但并不能有效保護軟件型vTPM 的密鑰等秘密信息.

目前, 國內外關于vTPM 密鑰的安全存儲主要依賴硬件TPM.Pearson 等人[37]提出將密鑰與平臺綁定的方案, 主要利用物理TPM 的硬件保護功能來安全存儲關鍵密鑰, 這樣使得密鑰只可以在綁定的平臺上使用, 其他平臺上不可用, 以達到保護數據機密性的目的, 但是這種方案很顯然缺乏靈活性.Yang 等人[38]設計了一個基于物理TPM 的云存儲系統架構, 首先用對稱密鑰加密數據, 然后用非對稱密鑰加密該對稱密鑰, 最后利用物理TPM 來安全存儲非對稱密鑰, 從而實現密鑰的有效管理, 這種方法比較復雜,加密解密必然會耗費大量系統空間和時間.王麗娜等[39]提出的基于硬件TPM 的密鑰使用次數管理方法在保護云存儲中數據的機密性的同時控制密鑰的使用次數, 從而能夠安全有效地存儲和保護密鑰.文獻[40]基于現有的虛擬TPM 架構提出一種用于vTPM 的安全改進方案, 在KVM 虛擬機上通過在硬件和軟件方面實現TPM2.0 規范, 增加了使用TPM 的非對稱加密算法對vTPM 的保護, 并且能夠支持TPM 密鑰的安全遷移以及VM-vTPM 的遷移.上述研究成果均基于硬件TPM 的加密保護, 雖然能夠達到安全存儲vTPM 密鑰的效果, 但是仍具有如下不足: (1)由于vTPM 密鑰的頻繁使用必然會使硬件TPM 頻繁加密解密, 不僅占用系統資源, 而且密鑰傳輸以及加解密均需要耗費時間, 從而增加系統的響應時間和TPM 性能負擔; (2)當vTPM 在進行加解、解密、完整性驗證等安全操作時, vTPM 密鑰等敏感信息也必須首先加載到內存中, 這些敏感信息仍然容易遭到竊取和破壞.

3 基于影子頁表+ 的軟件型vTPM 密鑰保護方案

對于普通的可信計算平臺, TPM 內部的密鑰存儲了EK、SRK、TPM 所有者和SRK 的授權數據等, 其他密鑰存放在TPM 外部, 外部存儲的密鑰形成以SRK 為根的多級密鑰樹[41].由于TPM 內部具有平臺軟件無法直接訪問的獨立的存儲空間, 因此普通的可信計算平臺其密鑰或證書是安全的.然而對于虛擬平臺中的仿真型vTPM, 其作為運行在用戶空間的應用程序并沒有直接的硬件保護, 其對應的vEK、vSRK、vTPM 所有者和vSRK 的授權數據以及由此而保存在外設上的密鑰樹等很容易受到竊取和破壞.本節基于全虛擬化方式或硬件輔助虛擬化, 通過在VMM 中增加MMU-vTPM 管理模塊對vTPM 域中vEK、vSRK、vTPM 所有者和vSRK 授權數據等秘密數據的存儲空間進行保護, 系統框架如圖2 所示.

圖2 vTPM 保護系統框架Figure 2 vTPM protection system framework

如圖2 所示, 運行在VMM 層的MMU-vTPM 對vTPM 密鑰信息的保護起到關鍵作用.MMUvTPM 分為兩個部分: vTPM 密鑰私有內存管理和vTPM 密鑰私有內存訪問控制, 它能夠對來自虛擬機操作系統以及應用程序的vTPM 內存訪問進行監控, 通過建立vTPM 密鑰的私有頁表, 實現vTPM 內存隔離, 以防止任意進程對vTPM 受保護內存進行非法訪問和破壞.主要原理如下:

(1)增加一個管理vTPM 密鑰私有內存的超級調用.vTPM 管理程序創建vTPM 子實例的時候通過該超級調用申請內存用來存儲生成的vEK 和vSRK 等秘密數據.該內存會受到MMU-vTPM 模塊保護, 只能由該vTPM 子實例訪問, 其他任何進程均不能訪問.

(2)當發生訪問vTPM 受保護內存的操作時, 會陷入到vTPM 密鑰保護模塊中MMU-vTPM, 由MMU-vTPM 對申請的私有內存保護.

(3)MMU-vTPM 通過驗證訪問vTPM 密鑰私有內存的進程身份來進行訪問控制.

值得注意的是, 本方案與采用Intel 的SGX 來實現可信保護是不同的.SGX 是Intel 開發的新的處理器技術, 可以在計算平臺上提供一個可信的空間, 保障用戶關鍵代碼和數據的機密性和完整性.本方案是用軟件模塊MMU-vTPM 來保護vTPM 的內存空間, 而MMU-vTPM 又收到物理硬件TPM 的保護.而SGX 是對因特爾體系(IA)的一個擴展, 用于增強軟件的安全性.這種方式是將合法軟件的安全操作封裝在一個enclave 中, 保護其不受惡意軟件的攻擊, 特權或者非特權的軟件都無法訪問enclave, 也就是說, 一旦軟件和數據位于enclave 中, 即便操作系統或者和VMM 也無法影響enclave 里面的代碼和數據.Enclave 的安全邊界只包含CPU 和它自身.SGX 創建的enclave 也可以理解為一個可信執行環境TEE(trusted execution environment).

3.1 MMU-vTPM 的基本架構

在全虛擬化方式或硬件輔助虛擬化下, 各種虛擬平臺均采用影子頁表(shadow page table, SPT)[42]機制來實現虛擬地址到機器地址的轉換, 它提供給每個Guest OS 一個Guest 頁表, 但實際上客戶機是通過影子頁表SPT 來訪問真實的機器物理地址的.如圖3 所示, Guest 頁表是Guest 虛擬地址到Guest 物理地址之間的映射, 而影子頁表SPT 是Guest 物理地址與宿主機物理地址之間的映射.Guest 物理地址與宿主機物理地址之間可以通過哈希表和P2M 兩種方式進行對應.其中, 哈希表對某一個非最低級客戶機頁表中的頁表項而言, 以該客戶機頁表項中的物理地址和該頁表項的類型作為哈希表的鍵值, 在哈希表中可以查找到相應的影子頁表項中的機器物理地址; P2M 表是客戶機物理地址到機器物理地址的轉換表.此影子頁表可以采用硬件支持的內存虛擬化, 如AMD 的NPT (nested page tables, NPT)和Intel EPT(extended page tables, EPT)技術實現[43].

在圖3 中, 我們增加了特有的vTPM 內存管理模塊MMU-vTPM, 用于保護vTPM 的密鑰等敏感信息.MMU-vTPM 實際上是在影子頁表的基礎上構建影子頁表+(shadow_plus)的映射機制, 即在同步客戶機頁表和影子頁表的缺頁異常中增加訪問監控接口shadow_plus, 如圖4 所示.下面我們將對vTPM內存管理模塊MMU-vTPM 進行詳細介紹.

圖3 影子頁表與客戶機頁表之間的關系Figure 3 Relationship between shadow page table and client page table

圖4 訪問監控接口shadow_plus 結構圖Figure 4 Structure of shadow_plus access monitoring interface

3.2 vTPM 密鑰私有內存管理

MMU-vTPM 的功能之一是vTPM 密鑰私有內存的管理, 主要包括vTPM 密鑰私有內存的申請和vTPM 密鑰私有內存的回收.無論是vTPM 密鑰私有內存的申請和vTPM 密鑰私有內存的回收, 均需要提供用戶空間的接口以及內核空間的接口, 用戶可以通過使用這些接口為vTPM 分配或回收私有空間.

定義1 vTPM 密鑰私有內存.vTPM 密鑰私有內存是在vTPM 子實例創建時, 由vTPM 管理程序為vTPM 子實例申請的一段只允許vTPM 進程訪問的物理內存, 用于存儲vTPM 的vEK 和vSRK 等密鑰.其數據結構vTPM_pmdomain 的具體描述為:

定義2vTPM 密鑰私有內存保護列表.vTPM 密鑰私有內存保護列表用于記錄vTPM 密鑰私有內存頁的PFN(客戶物理頁框號)的鏈表.其數據結構vTPM_protected_list 的具體描述如下:

struct vTPM_protected_list

{

unsigned int vTPM_page_id; //vTPM 密鑰私有內存id

unsigned long gfn; //vTPM 密鑰私有內存頁的客戶機物理頁框號

unsigned long mfn; //vTPM 密鑰私有內存頁的機器頁框號

struct vTPM_protected_list *next;}

typedef struct vTPM_protected_list *vTPM_pm_list; //定義vTPM_pm_list * 指針類型

定義3malloc_vTPM_pages(), 即vTPM 密鑰私有內存申請函數, 作為vTPM 密鑰私有內存申請接口.實現如算法1 所示.

算法1 vTPM 密鑰私有內存申請接口實現算法malloc_vTPM_pages()Input: struct vTPM_protected_list *vTPM_pm_list Output: *vTPM_pm_list 1 var item ←vTPM_pm_list;2 while item do 3Set item.gfn; 4page ←Get page; 5item.mfn ←Get mfn(item.gfn); 6Item ←item.next;7 end 8 return * vTPM_pm_list;

算法1 中Get、Set 方法為VMM 系統調用.Page 為VMM 分頁機制下的內存頁.gfn 內存頁的客戶機物理頁框號.mfn 內存頁的機器頁框號.該算法是為了實現vTPM 私有內存申請, 首先通過系統調用Set 申請物理內存頁, 并為其設置客戶機物理頁框號, 同時寫入vTPM 密鑰私有內存保護列表, 然后通過系統調用Get 為申請到的物理內存頁分配機器頁框號mfn, 并寫入vTPM 密鑰私有內存保護列表中gfn相應的mfn, 最后返回申請到的vTPM 密鑰私有內存保護列表.

定義4drop_vTPM_pages(), 即vTPM 密鑰私有內存回收函數, 作為vTPM 密鑰私有內存回收接口.實現如算法2 所示.

算法2 vTPM 密鑰私有內存回收接口drop_vTPM_pages()Input: struct vTPM_protected_list *vTPM_pm_list Output: NULL 1 for each item in ?vTPM_pm_list do 2page.drop(item.gfn, item.mfn); 3p2m.drop(item.gfn, item.mfn); 4SPT.drop(item.gfn, item.mfn);5 end 6 FLUSH;

算法2 中page.drop 方法為VMM 中用于釋放內存頁的系統調用.p2m.drop 是VMM 中用于刪除p2m 表項的系統調用.SPT.drop 是VMM 中用于清空影子頁表表項的系統調用.FLUSH 是刷新系統TLB 表項的命令, 使得快表中的vTPM 密鑰私有內存地址相關映射失效.該算法是為了實現vTPM 密鑰私有內存回收, 首先遍歷整個vTPM 私有內存列表*vTPM_pm_list, 然后通過VMM 內存管理系統調用的內存釋放函數page.drop 釋放vTPM 私有內存頁, 同時通過VMM 內存管理系統調用p2m.drop刪除P2M 表中的相關表項以及通過VMM 內存管理系統調用SPT.drop 影子頁表中的相關表項, 最后執行系統刷新命令, 使系統TLB 中相關表項失效.

3.3 vTPM 密鑰私有內存的訪問控制

MMU-vTPM 的另一功能是對vTPM 密鑰私有內存實施訪問控制, 它監控所有訪問vTPM 密鑰私有內存空間的進程, 提供異常處理.首先, 當vTPM 進程首次訪問vTPM 密鑰私有內存空間時, 由于影子頁表中沒有關于vTPM 密鑰私有內存的地址映射, 所以產生缺頁異常, VMM 捕獲該異常, 建立vTPM密鑰私有內存的影子頁表映射, 并且將其影子頁表訪問權限設置為只讀.然后, MMU-vTPM 對vTPM密鑰私有內存進行訪問控制, 具體實現流程如下:

(1)VMM 可以捕獲任何寫CR3 寄存器的操作, 通過CR3 寄存器中存儲的頁目錄的起始物理地址, VMM 可以得知該進程的所有頁表[36].由此可以記錄vTPM 進程的基地址并保存到vTPM_base_address 中.

(2)由于影子頁表權限為只讀, 當發生對vTPM 密鑰秘密信息私有內存的操作時, VMM 同步客戶機頁表和影子頁表時會發生缺頁異常.

(3)VMM 捕獲到缺頁異常后, 首先要查找此進程的客戶機頁表, 確定發生缺頁異常的客戶機虛擬地址所對應的客戶機物理地址; 然后進入到VMM 的影子頁表缺頁處理入口函數sh_page_fault(),sh_page_fault()調用vTPM 密鑰私有內存異常處理接口shadow_plus 來進行處理.

vTPM 密鑰私有內存異常處理接口如定義5 所示.

定義5shadow_plus(), 即vTPM 密鑰私有內存異常處理接口.該接口是在同步客戶機頁表和影子頁表缺頁異常處理中增加的對vTPM 密鑰私有內存異常的處理方法.

在異常處理的過程中, shadow_plus 首先獲取發生缺頁異常的客戶機物理地址, 然后通過p2m 表獲得發生缺頁異常的 對, 并判斷其pfn 是否是vTPM 密鑰私有內存列表中的機器物理地址.然后, 獲取該進程的客戶機物理基地址與事先保存的vTPM 進程基地址進行比較.若為vTPM 進程, 則不做處理, 正常更新影子頁表; 否則, 影子頁表更新失敗, 轉由客戶機處理.實現如算法3 所示.

算法3 vTPM 密鑰私有內存異常處理接口shadow_plus()實現算法Input: Page Fault 缺頁異常Output: 除vTPM 進程外訪問vTPM 密鑰私有內存的進程1 Get_Page_Fault(gva);2 pfn ←search in guest_page_table(gva); 3 ←get mfn from p2m;4 if < mfn,pfn > in vTPM_protected_list then 5bas ←Get CR3;6if bas! = vTPM_base_address then 7 goto not_a_shadow_fault;8end 9 end

算法3 中, Get_Page_Fault 表示VMM 捕獲缺頁異常的方法.guest_page_table 表示客戶機頁表,保存客戶機虛擬地址gva 與客戶機物理頁框號gfn 的映射.p2m 保存客戶機物理頁框號與機器頁框號的映射, 即 對.bas 保存當前進程的基地址.

至此, 我們可以設計vTPM 密鑰私有內存的訪問控制完整實現過程.如算法4 所示.

在算法4 中, Get_modify 表示VMM 捕獲CR3 寄存器操作的方法.Get_Page_Fault 表示VMM捕獲缺頁異常.

算法4 vTPM 密鑰私有內存訪問控制接口access_vTPM_key()算法Input: 任意進程Output: 除vTPM 進程外訪問vTPM 密鑰私有內存的進程1 vTPM_base_address ←Get_modify(CR3);2 if Get_Page_Fault then 3shadow_plus();4 end

4 MMU-vTPM 模塊的完整性驗證保護

內存管理模塊是VMM 的核心功能模塊,通常作為虛擬平臺的可信基TCB(trusted computing base,TCB), MMU-vTPM 模塊作為VMM 內存管理模塊的一部分, 也應看作是虛擬平臺TCB 的一部分.然而, 當前的許多攻擊, 如通過篡改VMM 代碼段和數據段以及其它靜態、持久化的數據而破壞完整性的攻擊[44,45], 都會破壞TCB.為了防止惡意用戶對MMU-vTPM 模塊進行篡改, 我們采用TPM 的靜態度量機制和動態度量機制對MMU-vTPM 模塊進行完整性保護, 確保MMU-vTPM 模塊完全可信.

4.1 MMU-vTPM 模塊的靜態完整性度量

虛擬平臺的靜態度量通常發生在整個虛擬平臺重新啟動時, 為了保證MMU-vTPM 可信, 我們擴展虛擬機的信任傳遞過程CRTM →BIOS →BootLoader →VMM →DOM OS →Apps, 將其中的VMM分為兩部分, 一部分VMM-MMU-vTPM, 另一部分是MMU-vTPM, 則擴展后的信任鏈變為CRTM →BIOS →BootLoader →VMM-MMU-vTPM →MMU-vTPM →DOM OS →Apps.如圖5 所示, 將MMU-vTPM 作為可信平臺鏈式度量的重要一環.這種方式是可行的, MMU-vTPM 的靜態度量可由VMM-MMU-vTPM 主導完成.

圖5 擴展后的信任鏈傳遞過程Figure 5 Extended trust chain delivery process

4.2 MMU-vTPM 模塊的動態完整性度量

在虛擬平臺運行過程中需要對MMU-vTPM 模塊進行動態完整性度量, 以便及時發現惡意程序對其的破壞和篡改, 保證虛擬平臺上服務的穩定性和連續性.MMU-vTPM 模塊動態完整性度量架構如圖6所示.

圖6 中, MMU-vTPM 模塊動態完整性度量架構包括3 個部分: MMU-vTPM 度量代理、MMUvTPM 度量程序和MMU-vTPM 的備份和恢復程序.其中MMU-vTPM 度量代理位于特權域中, 主要功能就是獲取并解析對MMU-vTPM 模塊的度量請求, 并將請求發送到MMU-vTPM 度量程序;MMU-vTPM 度量程序位于VMM 中, 負責MMU-vTPM 模塊的動態完整性度量; MMU-vTPM 備份和恢復程序也位于VMM 中, 負責對MMU-vTPM 進行備份, 當發現MMU-vTPM 被惡意篡改后對其進行恢復.MMU-vTPM 度量程序是整個架構的核心, 主要包括如下功能模塊:

圖6 MMU-vTPM 模塊動態完整性度量架構Figure 6 MMU-vTPM dynamic metrics architecture

(1)構建度量環境.目前, 處理器廠商AMD 提供的安全虛擬機(secure virtual machine, SVM)和Intel 提供的可信執行技術(trusted execution technology, TXT)均可構建安全加載模塊(secure loader block, SLB)作為動態信任根(dynamic root of trust for measurement, DRTM)[45], 通過執行特定的CPU 指令構建安全隔離的可信執行環境, 完成對MMU-vTPM 自身的完整性度量.本文利用Intel TXT技術中新引入的CPU 指令——SENTER, 利用動態信任根完成對MMU-vTPM 的完整性度量, 并創建一個受控和可證明的可信執行環境, 之后再加載運行MMU-vTPM 模塊度量程序.

(2)MMU-vTPM 提取模塊, 該模塊主要功能是提取出需要完整性度量的MMU-vTPM 模塊代碼段數據, 具體如定義6 所示.

定義6extract_MMU-vTPM()即MMU-vTPM 模塊提取接口, 主要實現如算法5 所示。

算法5 MMU-vTPM 模塊提取extract_MMU-vTPM()算法Input: 可信度量環境Output: MMU-vTPM 模塊代碼段1 length ←MMU-vTPM.length(); 2 offset ←Get_offset_of_VMM(); 3 virtual_address ←Get_virtual_address(symbol_table); 4 physical_address ←virtual_address–offset; 5 MMU-vTPM ←Get_data_memory(physical_address, length); 6 return MMU-vTPM;

在算法5 中, 首先通過分析MMU-vTPM 模塊代碼段的數據量length; 由于, VMM 一般以內核的方式加載到內存特定物理地址開始的連續地址空間中, 并將該內存地址空間以直接映射的方式映射到VM 的虛擬地址空間, 所以VMM 中特定信息的虛擬地址和物理地址之間有一個固定的差值offset, Get_offset_of_VMM()獲取VMM 的offset; symbol_table 表示編譯VMM-vTPM 模塊產生的符號表, 通過symbol_table 可以得到MMU-vTPM 模塊代碼段在內存中的虛擬地址virtual_address;physical_address 表示MMU-vTPM 模塊的虛擬地址對應的物理地址; 最后Get_data_memory()表示按照物理地址和數據量, 直接從內存中讀取MMU-vTPM 模塊的代碼段數據, 然后返回該值作為完整性度量DIM_MMU-vTPM()的輸入.

(3)完整性度量, 該模塊主要是對上一個模塊提取到的數據進行完成性度量, 以保證度量結果的一致性, 完整性度量一般采用TPM 的完整性度量機制, 將度量結果存儲到TPM 的平臺配置寄存器(PCR)中.將該模塊功能封裝為完整性度量接口, 如定義7 所示.

定義7DIM_MMU-vTPM(), 即MMU-vTPM 模塊的完整性度量接口.該接口的實現算法如算法6所示.

算法6 完整性度量DIM_MMU-vTPM()算法Input: MMU-vTPM 模塊代碼段Output: 度量值1 TPM_SHA1Start(); 2 TPM_SHA1Update(MMU-vTPM); 3 pcr_MMU-vTPM ←TPM_SHA1Complete(); 4 Tspi_TPM_PcrExtend(pcr_MMU-vTPM); 5 return pcr_MMU-vTPM;

完整性度量模塊采用TPM 的完整性度量機制, 算法6 中, TPM_SHA1Start()表示TPM 中開始計算一個摘要的過程, 即開始完整性度量.然后調用TPM_SHA1Update()輸入需要完整性度量的MMU-vTPM 模塊代碼段, 最后調用TPM_SHA1Complete()計算摘要值.完整性度量值的存儲通過調用TSP 層的Tspi_TPM_PcrExtend()函數來完成, 將摘要值pcr_MMU-vTPM 擴展更新到指定的平臺配置寄存器PCR 的值.

(4)度量報告, 該模塊主要是獲取完整性度量值, 并將新的度量值與存儲的度量值進行匹配, 以檢測完整性, 然后將完整性度量的結果返回給度量請求程序.

4.3 MMU-vTPM 模塊的備份與恢復

為了在MMU-vTPM 模塊被篡改時能夠及時恢復, 我們首先通過MMU-vTPM 模塊備份接口對MMU-vTPM 模塊備份, 由TPM 的存儲密鑰加密存儲在平臺外存中.之后根據完整性度量結果判斷是否需要恢復MMU-vTPM 模塊,如果需要則要通過MMU-vTPM 模塊恢復接口通過解密恢復MMU-vTPM模塊.其中, MMU-vTPM 模塊備份接口和MMU-vTPM 模塊恢復接口的定義與實現算法如下.

定義8MMU-vTPM_Backup(), 即MMU-vTPM 模塊的備份接口, 該接口的實現算法如算法7 所示.

算法7 MMU-vTPM 模塊備份接口實現算法MMU-vTPM_Backup()Input: MMU-vTPM 模塊代碼Output: MMU-vTPM 模塊備份地址Backup_Address 1 MMU-vTPM_copy ←Copy(MMU-vTPM); 2 MMU-vTPM_copy′ ←Tspi_Data_Bind(MMU-vTPM_copy); 3 Backup_Address ←&MMU-vTPM_copy′; 4 return Backup_Address;

算法7 中, MMU-vTPM_copy 表示MMU-vTPM 模塊的備份文件, Copy()表示復制一份MMUvTPM 模塊源碼作為備份, 然后使用TPM 的Tspi_Data_Bind 命令加密MMU-vTPM_copy, 接著存儲加密后的文件, 最后獲取存儲地址Backup_Address 并返回.

定義9MMU-vTPM_Recovery(), 即MMU-vTPM 模塊的恢復接口, 該接口的實現算法如算法8 所示.

算法8 MMU-vTPM 模塊恢復接口實現算法MMU-vTPM_Recovery()Input: MMU-vTPM 模塊備份地址Backup_Address Output: MMU-vTPM 模塊1 MMU-vTPM_copy′ ←*Backup_Address; 2 MMU-vTPM_copy ←TPM_Unbind(MMU-vTPM_copy′); 3 MMU-vTPM ←MMU-vTPM_copy; 4 REBOOT;

算法8 中, 首先根據MMU-vTPM 模塊備份接口返回的備份地址Backup_Address 讀取加密后的MMU-vTPM 模塊備份文件, 然后使用TPM 的TPM_Unbind 命令對Tspi_Data_Bind 命令處理過的數據塊進行解密并輸出, 最后用上一步中輸出的MMU-vTPM 模塊備份文件替換系統中不可信的MMU-vTPM 模塊.重啟系統完成MMU-vTPM 模塊恢復的更新操作.

5 基于XEN 的MMU-vTPM 實現

目前, 本方案已經在Xen 4.3.4 實現了上述功能, 能夠保護vTPM 密鑰私有內存空間不被其他任何進程訪問或破壞并且可以保證MMU-vTPM 模塊不被篡改.

5.1 vTPM 密鑰私有內存管理實現

為了實現vTPM 密鑰私有內存的管理, 對Xen 虛擬機的源碼做出了相應的修改, 添加了一個vTPM私有內存列表和一個超級調用, 并對系統中相應的處理函數做出修改.

首先, 根據定義1, 在//xen/include/asm-x86/domain.h 中添加Xen_vTPM_pmdomain 結構用于描述vTPM 密鑰私有內存.

其次, 根據定義2, 在//xen/include/asm-x86/domain.h 中定義vTPM 密鑰私有內存保護列表的數據結構Xen_vTPM_protected_list.

第三, 根據定義3 和算法1, 在//xen/common/memory.c 中定義vTPM 密鑰私有內存申請接口Xen_malloc_vTPM_pages()函數.

第四, 根據定義4 和算法2, 在//xen/common/memory.c 中定義vTPM 密鑰私有內存回收接口Xen_drop_vTPM_pages()函數.

最后, 增加一個用于管理 vTPM 密鑰私有內存的超級調用, 增加的超級調用為_HYPERVISOR_vTPMprotected_mm, 該超級調用封裝了Xen_malloc_vTPM_pages()函數和Xen_drop_ vTPM_pages()函數, 其功能是管理vTPM 密鑰私有內存空間, 它有一個參數op,_HYPERVISOR_vTPMprotected_mm 將根據該參數的值, 采取相應的操作.當op = 0 時, 表示對vTPM 密鑰私有內存空間采取初始化操作.當op = 1 時, 表示申請vTPM 密鑰私有內存.當op = 2時, 表示銷毀vTPM 密鑰私有內存相關數據并回收內存.

至此, Xen 中虛擬機的vTPM 管理程序通過超級調用_HYPERVISOR_vTPMprotected_mm 為新創建的vTPM 子實例分配和回收vTPM 密鑰私有內存空間.

5.2 vTPM 密鑰私有內存的訪問控制實現

為了實現vTPM 密鑰私有內存的訪問控制, 對Xen 虛擬機的源碼做出了相應的修改, 添加了一個vTPM 密鑰私有內存異常處理接口shadow_plus()和vTPM 密鑰私有內存的訪問控制接口access_vTPM_key(), 并對系統中相應的處理函數做出修改.

首先, 根據算法3, 在//xen/arch/x86/mm/shadow/multi.c 中增加vTPM 密鑰私有內存異常處理接口Xen_shadow_plus()函數.

其次, 根據算法4, 在//xen/arch/x86/mm.c 中增加vTPM 密鑰私有內存的訪問控制接口Xen_access_vTPM_key()函數.

至此, Xen 中虛擬機的 vTPM 管理程序通過 Xen_shadow_plus()函數和 Xen_access_vTPM_key()函數實現vTPM 密鑰私有內存的訪問控制.

5.3 MMU-vTPM 模塊完整性度量實現

MMU-vTPM 模塊完整性度量包括靜態度量和動態度量, 對于靜態度量, Xen 中的TPM 模擬器tpm_emulator 已經實現, 這里就不再闡述.下面介紹動態完整性度量.

由4.2 節可知, 要實現對MMU-vTPM 模塊的動態完整性度量必須依賴CPU 支持而且要進行復雜設置.由于我們的目的僅僅是通過動態完整性度量來判定MMU-vTPM 是否可信, 我們選用了另外的替代辦法, 采用在特權域中通過度量代理對MMU-vTPM 模塊進行動態度量, 此方法同樣可以達到我們的目標.為此, 我們增加了MMU-vTPM 度量程序各模塊的實現函數.

首先, 在構建度量環境模塊執行完SENTER 指令之后, 程序陷入到硬件層, 其加載執行的MMUvTPM 模塊度量程序將運行于Ring0, 系統處于實地址模式, 根據定義6 和算法5, 增加MMU-vTPM 模塊提取接口的實現函數extract_MMU-vTPM().

其次, 根據定義7 和算法6, 增加 MMU-vTPM 模塊完整性度量接口的實現函數DIM_MMU_vTPM().

最后, 增加一個實現MMU-vTPM 模塊度量程序的超級調用_HYPERVISOR_DIM_MMUvTPM(), 該超級調用封裝了extract_MMU-vTPM()函數和DIM_MMU-vTPM()函數, 其功能是完成對MMU-vTPM 模塊代碼段的提取并進行完整性度量.

6 基于XEN 的MMU-vTPM 實驗評估

目前, 本文的基于影子頁表+ 的vTPM 保護方案已經在Xen 4.3.4 作為底層的VMM 的虛擬平臺上實現.本節將設計兩方面實驗對本文提出的方案進行驗證.一方面是vTPM 密鑰私有內存的訪問控制實驗, 驗證MMU-vTPM 對vTPM 密鑰的保護; 另一方面是對MMU-vTPM 的完整性度量和相關安全驗證, 包括靜態度量、動態度量以及對度量程序的攻擊等.

6.1 vTPM 密鑰私有內存的訪問控制實驗

6.1.1 實驗環境

本文實驗環境為: 宿主機CPU 為Intel Core-i3 處理器, 主頻3.40 GHz, 4 G 內存; 底層VMM 為Xen 4.3.4; 虛擬域操作系統為Ubuntu 14.04; TPM 使用TPM_emulator 0.7.3; TSS 使用Trousers 0.3.4.

6.1.2 實驗步驟

為了評估本文提出的方案對vTPM 存儲私鑰等關鍵數據的私有內存的保護效果, 在測試中分別定義如下Shadow-Native 和shadow_plus 兩種測試環境.

(1)Shadow-Native: 運行未修改的Xen 的測試環境.

(2)Shadow_plus: 運行采用本文方法修改過的Xen 的測試環境.

具體實驗步驟如下:

(1)本實驗首先在創建vTPM 實例時使用超級調用_HYPERVISOR_vTPMprotected_mm 為vTPM 申請受保護的私有內存頁.

(2)將vTPM 的關鍵密鑰存儲到vTPM 密鑰私有內存中, 并由vTPM 進程讀取顯示.

(3)編寫測試程序, 在shadow_plus 測試環境中, 分別從以下四個方面進行測試: vTPM 進程正常訪問測試, 其他進程訪問測試, 用戶態代碼注入攻擊測試, 內核態代碼注入攻擊測試.

(4)記錄并分析上述四個測試結果.

(5)多次記錄Shadow-Native 和shadow_plus 兩種測試環境中進程運行時間并進行對比分析.

6.1.3 功能測試及實驗

本方案的重要目標是通過對進程影子頁表更新的監控來限制其他進程對vTPM 私有受保護內存空間的訪問, 達到保護vTPM 密鑰等關鍵數據的目的.

首先, 通過超級調用_HYPERVISOR_vTPMprotected_mm 為vTPM 申請受保護的私有內存頁.調用_HYPERVISOR_vTPMprotected_mm 傳入參數op = 1, 申請vTPM 密鑰私有內存, 將vTPM管理程序為vTPM 子實例創建的關鍵密鑰存儲到vTPM 密鑰私有內存中.如圖7 所示.

圖7 vTPM 密鑰私有內存中的vTPM 密鑰Figure 7 vTPM key in vTPM key private memory

其次, 測試vTPM 進程是否可以正常讀取vTPM 密鑰私有內存中的vTPM 密鑰.在vTPM 源碼中增加輸出接口編寫程序vtpm 顯示輸出結果, 由圖8 可知, vTPM 進程可以正常訪問vTPM 密鑰私有內存中的vRSK 等關鍵密鑰.

圖8 vTPM 進程訪問vTPM 密鑰私有內存Figure 8 vTPM process access vTPM key private memory

除此之外, 我們在shadow_plus 測試環境中, 設計了對比的攻擊實驗, 以測試本文方案安全性.

第一種: 其他進程訪問測試.本次實驗編寫名為test 的測試程序, 作為外部進程訪問vTPM 密鑰私有內存, 實驗結果如圖9 所示.

圖9 其他進程訪問測試結果Figure 9 Other process access test results

圖10 用戶態代碼注入攻擊測試結果Figure 10 User mode code injection attack test result

第二種: 用戶態代碼注入攻擊測試.本次實驗的用戶態是指與vTPM 所在虛擬機同一用戶空間的進程.編寫一段訪問vTPM 密鑰私有內存空間的攻擊代碼, 注入用戶態空間進程中進行訪問攻擊, 本次實驗的入口程序名為us_injection.實驗結果如圖10 所示.

第三種: 內核態代碼注入攻擊測試.本次實驗的內核態指的是在Xen VMM 空間運行的進程.通過內核注入攻擊的方式將訪問vTPM 密鑰私有內存空間的攻擊代碼運行于內核態.實驗結果同樣返回“Permission denied” 的錯誤代碼.

其中關于錯誤代碼EACCES 的描述在/xen/include/xen/errno.h 頭文件中, 如圖11 所示.

表1 功能測試結果Table 1 Functional Test Results

綜上所述, 本文功能測試結果如表1 所示:

從表1 的實驗結果中可以看出, 只有vTPM 進程能夠正常訪問vTPM 受保護私有內存頁.本次實驗結果表明本文基于影子頁表+ 的vTPM 密鑰保護方案能夠達到保護vTPM 密鑰的目的.6.1.4 性能測試及實驗

本文vTPM 保護方案對系統的性能影響主要包括兩種行為: 處理改寫CR3 寄存器的格外操作時間和處理缺頁異常的額外操作時間.這兩種額外增加的操作在系統中所有的進程執行都會產生一定的影響.編寫測試進程多次實驗, 在Shadow-Native 和shadow_plus 兩種測試環境中運行時間進行記錄, 結果如圖12 所示.

圖11 Xen 系統錯誤代碼Figure 11 Xen system error code

圖12 性能測試結果Figure 12 Performance test resultse

從圖12 可以看出, 在vTPM 受保護私有內存大小較小的時候增加了vTPM 保護模塊的shadow_plus 測試環境和沒有對進行修改的原始系統在統一進程的運行時間差別不大, 在用戶可以接受的范圍內, 而隨著受保護內存頁面的增多, 兩種測試環境的性能發生明顯變化, 增加了vTPM 保護模塊的shadow_plus 測試環境的性能隨著受保護內存頁的增加而下降.本次實驗結果表明: 由于vTPM 保護方案需要保護的vTPM 數據主要包括vEK 和vSRK 等關鍵數據, 所需要的受保護內存較小, 所以, 增加的vTPM 保護模塊對系統性能影響不大.

6.2 MMU-vTPM 完整性度量測試實驗

6.2.1 實驗環境和準備工具

本節的軟件實驗環境與6.1 節相同, 而動態完整性度量實驗需要利用Intel TXT 構建SLB 作為DRTM, 保證起點可信, SLB 構建封閉隔離的執行環境來執行度量程序, 保證度量程序自身可信, 完成對MMU-vTPM 模塊代碼的完整性度量.所以本次實驗需要CPU 支持Intel TXT 功能, 保證可以執行SENTER 命令.如圖13 所示, 開啟Intel TXT 功能.

6.2.2 實驗步驟

為了對本文軟件仿真型vTPM 密鑰保護方案中的MMU-vTPM 模塊進行完整性保護, 分別從靜態完整性度量和動態完整性度量兩個方面設計實驗完成對功能和性能的測試.

實驗步驟如下:

(1)靜態完整性度量: 基于MMU-vTPM 模塊的擴展信任鏈, 在系統啟動時進行靜態完整性度量.按照本文擴展的信任鏈的傳遞過程進行度量, 并將MMU-vTPM 度量結果保存到PCR(17), 然后讀取PCR寄存器的值.

圖13 開啟Intel TXTFigure 13 Turn on Intel TXT

(2)動態完整性度量: MMU-vTPM 模塊的動態完整性度量實驗, 首先調用超級調用_HYPERVISOR_DIM_MMU-vTPM()以驅動MMU-vTPM 模塊度量程序完成構建度量環境、MMUvTPM 模塊提取和完整性度量等一系列過程.

(3)設計對MMU-vTPM 度量程序自身的攻擊實驗, 修改MMU-vTPM 模塊動態完整性度量程序部分代碼, 驗證實驗度量結果值是否發生改變.

(4)設計對MMU-vTPM 模塊代碼段的攻擊實驗, 修改MMU-vTPM 模塊代碼段中部分程序代碼,驗證實驗度量結果值是否發生改變.

(5)執行MMU-vTPM 度量程序進行動態完整性度量, 并記錄運行時間.

6.2.3 功能測試

首先, 在系統啟動時進行靜態完整性度量, 按照本文擴展的信任鏈的傳遞過程進行度量, 并將MMU-vTPM 度量結果保存到PCR(17), 然后讀取PCR 寄存器的值, 實驗結果如圖14 所示.

圖14 靜態完整性度量后PCR 的值Figure 14 Post-PCR value after static integrity measurement

其次, 為了驗證本文的MMU-vTPM 模塊動態完整性度量架構能夠有效的對MMU-vTPM 模塊進行動態的完整性度量, 本次實驗首先調用超級調用_HYPERVISOR_DIM_MMU-vTPM()以驅動MMU-vTPM 模塊度量程序完成構建度量環境、MMU-vTPM 模塊提取和完整性度量等一系列過程, 如圖15 所示.

再次, 設計對MMU-vTPM 度量程序自身的攻擊實驗, 修改MMU-vTPM 模塊動態完整性度量程序部分代碼, DIM_MMU-vTPM′表示修改后的MMU-vTPM 度量程序.實驗結果顯示度量結果值發生改變, 與存儲在TPM PCR[18]中的MMU-vTPM 度量程序摘要值不同, 結果如圖16 所示.驗證本文動態完整性度量程序自身的安全性.

最后, 設計對MMU-vTPM 模塊代碼段的攻擊實驗, 修改MMU-vTPM 模塊代碼段中部分程序代碼,MMU-vTPM′表示修改后的MMU-vTPM 模塊.實驗結果顯示度量結果值發生改變, 與存儲在TPM PCR[17]中的MMU-vTPM 模塊的靜態完整性度量值度量不同, 結果如圖17 所示.驗證本文動態完整性度量的有效性.

圖15 MMU-vTPM 模塊動態完整性度量過程Figure 15 MMU-vTPM module dynamic integrity measurement process

圖16 MMU-vTPM 度量程序自身攻擊實驗對比Figure 16 MMU-vTPM metrics own attack experiment results

圖17 MMU-vTPM 模塊代碼段攻擊實驗對比Figure 17 Comparison of attack results of MMU-vTPM module code segment

由上述實驗對比結果可知, 本文的MMU-vTPM 模塊動態完整性度量架構能夠在保證度量程序自身安全性的同時, 識別出對MMU-vTPM 模塊代碼段的攻擊, 從而保證了MMU-vTPM 模塊的安全性.

6.2.4 性能測試

為了對本文的MMU-vTPM 模塊動態完整性度量架構的性能進行測試, 執行MMU-vTPM 度量程序進行動態完整性度量, 并記錄運行時間.為了保證本文實驗數據的可靠性, 本文性能測試共進行了6次實驗, 經過測試, 動態完整性度量需要讀取MMU-vTPM 模塊的數據量大小為2.94 KB, 采用本文的MMU-vTPM 模塊動態完整性度量架構度量時間性能第一次測試結果為0.39 ms, 第二次為0.44 ms, 第三次為0.37 ms, 第四次為0.51 ms, 第五次為0.34 ms, 第六次為0.36 ms.如圖18 所示.

圖18 MMU-vTPM 度量程序自身的攻擊實驗對比結果Figure 18 MMU-vTPM metrics own attack experiment results

綜上所示, 本文的MMU-vTPM 模塊動態完整性度量架構度量時間性能約為0.40 ms, 在用戶可接受范圍內.

7 結論

本文針對仿真型vTPM 的vEK 和vSRK 等關鍵密鑰秘密信息存儲在虛擬域的用戶空間缺乏相應的保護機制, 容易受到攻擊而使得軟件型vTPM 的安全性降低的問題, 提出了一種基于影子頁表+ 的vTPM 保護方案并在Xen 虛擬平臺上實現.首先在創建vTPM 實例時使用超級調用_HYPERVISOR_vTPMprotected_mm 為vTPM 申請受保護的私有內存頁.其次將vTPM 域內頁表設置為只讀, 當監控到頁表修改行為發生缺頁異常時, 使用vTPM 私有內存訪問控制實現的shadow_plus 算法, 捕獲除vTPM 進程以外的任何訪問vTPM 受保護私有內存的進程的異常, 最后返回客戶機進行處理.實驗結果表明了本文提出方案的可靠性, 而且不會帶來嚴重的性能損失.此外, 在本文相關工作中已經指出, 近年來不斷有對提高vTPM 的安全性的研究, 這些大都基于硬件TPM, 針對軟件仿真型的vTPM 密鑰保護問題至今沒有解決, 本文的實驗及結果證明了本文提出的軟件仿真型vTPM密鑰保護方案的可靠性和可行性.

目前, 本方案只能對vTPM 的vEK 和vSRK 等較少的數據進行保護, 下一步將研究如何在不影響系統性能的情況下增加受保護內存的大小,以及vTPM 遷移時vTPM 保護模塊如何有效的工作等問題.