潘利華,蘭清程,李雪兵,石元兵,張舒黎,任玉霞
(1.中電科網(wǎng)絡安全科技股份有限公司,四川 成都 610065;2.可信云計算與大數(shù)據(jù)四川省重點實驗室,四川 成都 610065)
隨著云計算的快速發(fā)展及大量應用,安全問題越來越受到重視,基于可信平臺模塊(Trusted Platform Module,TPM)[1]構(gòu)建可信計算體系,能夠保證云計算基礎環(huán)境的完整性。同時,為了將信任鏈傳遞到虛擬機中,充分保障虛擬機的可信性,通常還為虛擬機提供虛擬TPM(virtual TPM,vTPM)。但TPM 本身是一種芯片接口規(guī)范,通常和一個物理平臺強綁定,不支持在物理平臺之間遷移。在云計算的應用場景中,若為每個虛擬機(Virtual Machine,VM)提供一個相應的vTPM,則vTPM 和傳統(tǒng)的物理TPM(Physical TPM,pTPM)相比,除了要為VM 提供和pTPM 一樣的功能接口,還要求vTPM 能夠隨著VM 的遷移而遷移,因此,需要一種VM-vTPM 遷移協(xié)議。
文獻[2]提出了包含vTPM 遷移在內(nèi)的功能要求、安全目標和參考的體系架構(gòu),但沒有給出具體的協(xié)議設計和實現(xiàn)方案。文獻[3-5]提出的vTPM遷移協(xié)議設計都沒有對遷移請求來源做合法性檢查,容易遭到拒絕服務攻擊。文獻[3-6]提出的vTPM 虛擬證書鏈擴展設計,不可避免地都需要在vTPM 遷移后重新生成部分密鑰和證書。此外,以上文獻基本停留在協(xié)議設計階段,缺乏實際的實現(xiàn)方法。文獻[7]在當時的開源組件基礎之上提出了一種vTPM 熱遷移的具體實現(xiàn)方法,主要解決了vTPM 數(shù)據(jù)從源平臺傳遞到目標平臺的具體實現(xiàn),但缺乏考慮數(shù)據(jù)傳遞過程中的安全,且隨著開源組件新版本的發(fā)布,當時的實現(xiàn)方法已不能完全適用于當下的開源組件。
本文在現(xiàn)有的開源組件基礎之上,設計了一種新的基于內(nèi)核的虛擬機(Kernel-based Virtual Machine,KVM)平臺下的vTPM 熱遷移協(xié)議及實現(xiàn)方法,主要貢獻如下:(1)提出的vTPM虛擬證書鏈擴展設計可以避免vTPM 遷移后密鑰和證書的重新生成;(2)提出的vTPM遷移協(xié)議設計及其實現(xiàn)方法包括對參與遷移方的雙向遠程可信證明和對vTPM 實例數(shù)據(jù)傳輸?shù)陌踩Wo,協(xié)議設計中對遷移請求來源的合法性檢查能有效減輕源平臺和目標平臺在遷移過程中遭受的拒絕服務攻擊。
本文結(jié)構(gòu)如下:第1 節(jié)介紹TPM和虛擬化技術(shù)有關(guān)的背景知識;第2 節(jié)描述開源組件QEMU 中TPM 的實現(xiàn)方法并重點分析其在vTPM 熱遷移方面存在的安全問題;第3 節(jié)提出一種改進后的VMvTPM 熱遷移協(xié)議設計及實現(xiàn)方法;第4 節(jié)分析熱遷移設計方案的安全性;第5 節(jié)給出結(jié)論和下一步研究重點。
可信計算體系的可信根包括可信度量根、可信存儲根和可信報告根,TPM 是可信計算平臺的硬件可信根,它負責可信計算平臺的安全控制和密碼運算等功能。依據(jù)TCG 規(guī)范,可信根被無條件信任。基于可信根,在可信計算平臺環(huán)境的每個轉(zhuǎn)換過程中保持信任傳遞。可信根中的可信報告根(Root of Trust for Reporting,RTR)可以理解為背書密鑰[8](Endorsement Key,EK)及認證身份密鑰[9](Attestation Identity Key,AIK)。EK 密鑰由TPM 廠商植入,在TPM中具有唯一性,TPM廠商證書簽發(fā)機構(gòu)(Certificate Authority,CA)為EK 密鑰簽發(fā)的EK證書可以用于建立并維持可信平臺身份。AIK 密鑰及AIK 證書可實現(xiàn)平臺自身的身份證明,生成、提供完整性報告,保護報告值。
vTPM 具有TPM 的完整功能,此外,面對云計算環(huán)境特性,還提供系列vTPM 生命周期管理,包括安全遷移、快照等功能。vTPM 實例添加到VM 后,在客戶機操作系統(tǒng)(Guest OS)中與使用pTPM 同樣的方式方法使用vTPM,vTPM 使Guest OS 能夠創(chuàng)建和存儲專用密鑰。對VM 的Guest OS 運行環(huán)境進行完整性保護,啟用vTPM 可大大降低VM 的安全風險。vTPM 安全性應盡可能滿足文獻[2]等提及的可信計算相關(guān)標準規(guī)范,如vTPM 實例及vTPM 中的用戶密鑰、數(shù)據(jù)由pTPM 提供存儲保護,遷移時由vTPM 管理器執(zhí)行雙向可信驗證、數(shù)據(jù)機密性和數(shù)據(jù)完整性保護等功能。到目前為止,QEMU 等開源組件已經(jīng)支持vTPM 功能,但還存在諸多安全缺陷,在后面章節(jié)會進一步分析開源組件QEMU 中的TPM 實現(xiàn)方式及其安全性問題。
QEMU 是一個支持純軟件方式實現(xiàn)CPU 虛擬化、內(nèi)存虛擬化和I/O 虛擬化等功能的用戶空間程序,采用了硬件輔助虛擬化的KVM 技術(shù),QEMU可以將CPU 和內(nèi)存等虛擬化工作交由KVM 處理,自己則處理大多數(shù)I/O 虛擬化的功能,進而實現(xiàn)極高的虛擬化效率。此外,VM 的配置、創(chuàng)建、運行時的用戶操作環(huán)境、跟用戶之間的交互和一些針對VM 的特殊技術(shù)如動態(tài)遷移等是由QEMU 實現(xiàn)的。
QEMU 是眾多不同種類Hypervisor 中的一種,不同Hypervisor 技術(shù)提供的VM 管理工具參數(shù)眾多且差異較大。因此,在實際使用中,還需要一套對VM 進行管理的統(tǒng)一的編程接口。目前在Linux系統(tǒng)下與QEMU 廣泛配合使用的管理接口程序是Libvirt,Libvirt 基于UNIX Socket 方式使用QMP 協(xié)議與QEMU 進行控制信息交互,已成為當下云計算平臺環(huán)境中的虛擬化底層管理接口的事實標準程序。
虛擬機熱遷移,也叫動態(tài)遷移或在線遷移,是在VM 運行同時進行遷移。虛擬機熱遷移實現(xiàn)方式中,運行時的內(nèi)存數(shù)據(jù)拷貝方法有預拷貝內(nèi)存Precopy、內(nèi)存后拷貝Post-copy、混合拷貝Hybridcopy 這3 種方式。源節(jié)點和目標節(jié)點間的數(shù)據(jù)傳輸通道有Libvirtd 隧道、HV 原生兩種傳輸方式,遷移管理控制有受管理點對點遷移(一般是源節(jié)點主動控制)、受管理直接遷移(云管理平臺控制)、不受管理直接遷移(如系統(tǒng)直接對HV 進行管理)、人工命令等方式。熱遷移一般采用鏡像實例文件共享的存儲方式,不需要遷移鏡像文件,只需將運行時內(nèi)存數(shù)據(jù)搬移到對端。目前,大多數(shù)云平臺基于Libvirtd 采用受管理點對點方式進行熱遷移。
當前qemu-7.2.0[10]已經(jīng)能夠創(chuàng)建帶有TPM功能的VM,其TPM實現(xiàn)分成前端和后端。前端是向VM 提供仿真硬件接口如TPM TIS[11],后端連接宿主機上的TPM設備。如圖1 所示,依據(jù)連接QEMU 后端的宿主機上的TPM設備的類型,可以將QEMU 中的TPM 實現(xiàn)方式分為TPM passthrough和TPM emulator 兩種。

圖1 QEMU 中的TPM 實現(xiàn)方式
TPM passthrough,也稱TPM 直通方式,是直接將宿主機上的pTPM 提供給VM 使用的方式。優(yōu)點是能為VM 提供硬件安全級別的TPM設備,缺點是pTPM 只能被該VM 獨占,宿主機上的其他應用程序和其他VM 不能使用pTPM,而且此方式也不支持遷移。因此,在實際應用中很少使用。
TPM emulator 即TPM 全虛擬化實現(xiàn)方式,連接QEMU 后端的是宿主機上的軟件仿真程序SWTPM,在SWTPM 和QEMU 之間傳遞兩類消息:一類是標準的TPM 命令消息,另一類是對vTPM 實例進行重置、初始化和遷移等操作的控制消息。該方式的優(yōu)點是支持VM-vTPM 的遷移,并對宿主機上的VM-vTPM 個數(shù)也沒有限制,但當前開源組件中的TPM 全虛擬化實現(xiàn)方式還存在如下幾個明顯缺陷。
(1)vTPM 跟pTPM 完全脫離。
(2)在VM 和vTPM 實例之間沒有一對一的強綁定關(guān)系。
(3)vTPM 實例在磁盤空間的文件系統(tǒng)上的存儲沒有得到有效保護。
(4)VM-vTPM 的遷移實現(xiàn)方式存在如下安全問題。
①底層平臺未進行雙向可信證明:VM 在進行冷或熱遷移時,遷移源和遷移目的雙方未進行可信證實,遷移雙方均無法判定對方平臺的可信性,VM-vTPM 可能被遷移到不受信任的平臺,信任關(guān)系無法保持。
②遷移保護密鑰未得到有效保護:QEMU 跟SWTPM兩進程之間的控制消息包括對vTPM實例信息的收集和恢復,支持對vTPM 實例信息的機密性和完整性保護,但保護密鑰是以明文形式存放在源端和目標端的配置文件中,配置文件在源端和目的端之間的傳輸方式有多種不同安全級別的實現(xiàn)方式,使含有保護密鑰的明文信息的配置文件有在網(wǎng)絡上明文流轉(zhuǎn)的風險。
③秘密信息未受到pTPM 保護:由于開源組件中的TPM emuloter 方式跟pTPM 完全脫離,vTPM實例信息在源端和目的端之間的傳遞未能受到pTPM 的有效防護。
目前開源組件中僅TPM emulator 方式支持vTPM 的遷移,本文剩余部分將針對目前開源組件中的vTPM 熱遷移實現(xiàn)方法中的①②和③共3 點安全問題,提出一種新的vTPM 熱遷移實現(xiàn)方案,并對改進后的方案做安全性評估。
私有云是云計算服務提供商(Private Cloud Provider,P)為特定組織在其內(nèi)部建設的專有云計算系統(tǒng)。假設源服務器(Source Server,S)進行計劃性停機維護或者出于負載均衡的考慮,為了不中斷S 上VM 正在運行的業(yè)務,P 需要將正在運行的VM 從S 移動到目標服務器(Destination Server,D)。本文的研究場景如圖2 所示,S和D 都支持pTPM且預先部署了EK 密鑰和EK 證書,并假設EK 密鑰和EK 證書是可以信任的,S 和D 上的每個VM都和一個純軟件實現(xiàn)的vTPM綁定在一起并形成VM-vTPM。P 需要將正在運行的VM-vTPM 從S 遷移到D,遷移過程中要考慮以下幾點安全問題:(1)保證VM-vTPM 在遷移期間未被未授權(quán)篡改或損壞,并且關(guān)于VM-vTPM 任何有價值的信息都不能泄露給未授權(quán)者;(2)遷移請求必須是可信任的實體P 發(fā)起的;(3)遷移雙方S 和D 的身份是可信的,并保證基礎環(huán)境的完整性。

圖2 研究場景
本節(jié)先介紹vTPM 證書鏈擴展的背景知識,然后提出證書鏈擴展設計方案。
3.2.1 vTPM 證書鏈擴展的背景知識
傳統(tǒng)的服務器和pTPM是一對一的,在服務器上加入了虛擬化技術(shù)之后,服務器上會運行多個VM,每個VM 都有各自的vTPM。如果vTPM 是純軟件方式實現(xiàn)的,就需要在pTPM 和服務器上的多個vTPM 之間建立一種對應關(guān)系,并將信任鏈從物理平臺擴展到虛擬平臺。現(xiàn)有方法主要采用證書鏈來進行擴展,因此證書鏈的擴展設計至關(guān)重要。VM-vTPM 從源平臺遷移到目標平臺之前需要先基于擴展的證書鏈對遷移雙方進行可信證實,在遷移完成后可能需要重新生成部分密鑰和證書。好的證書鏈擴展設計應盡量減少密鑰和證書的再生,以降低vTPM 遷移設計的復雜度。
3.2.2 vTPM 證書鏈擴展的設計方案
本節(jié)提出的證書鏈設計可以避免在VM-vTPM遷移完成后密鑰和證書的再生,也能提供對vTPM實例的可信證明能力和對vTPM 管理器組件的可信證明能力。如圖3 所示,所提設計引入了vTPM 管理器、可信第三方(Trusted Third Party,TTP)、SK 密鑰、MIK 密鑰和MIK 證書。

圖3 vTPM 證書鏈擴展
(1)vTPM 管理器:負責為VM 創(chuàng)建vTPM 實例,并基于該vTPM 實例為其創(chuàng)建虛擬機背書密鑰(virtual Endorsement Key,vEK),并且參與VMvTPM 熱遷移的遷移引擎(Migration Engine,ME)也是vTPM 管理器的功能構(gòu)件的組成部分。
(2)TTP:負責為vEK 密鑰和MIK 密鑰簽發(fā)證書,同時對vTPM 管理器的可信性做驗證和擔保。
(3)SK 密鑰:是pTPM 創(chuàng)建的不能復制的簽名密鑰。
(4)MIK 密鑰:是本設計中為vTPM 管理器特別新增的一種密鑰,是EK 密鑰下的子密鑰,其特點是不能復制,能對任意數(shù)據(jù)做加密、解密和驗簽運算,但簽名運算受到TTP 的簽名管控。
(5)MIK 證書:是TTP 為MIK 密鑰簽發(fā)的證書,證書的擴展項中包含了可信任的遷移控制器(Migration Controller,MC)的IP 和公鑰等標識信息,還包含了SK 密鑰的公鑰信息。
具體流程如下:
(1)vTPM管理器需要調(diào)用pTPM創(chuàng)建MIK密鑰,之后vTPM 管理器基于MIK 密鑰、EK 密鑰、EK 證書、平臺配置寄存器(Platform Configuration Register,PCR)(含平臺度量日志)和平臺證書,向TTP申請MIK證書,其中PCR 用于創(chuàng)建物理平臺及vTPM 管理器的可信憑據(jù)。
(2)TTP 利用pTPM 制造商的根證書驗證EK 證書的有效性。基于平臺廠商的根證書驗證平臺證書的有效性;基于EK 公鑰驗證pTPM 確是EK 密鑰創(chuàng)建者的真實性;基于MIK 公鑰和EK 公鑰驗證MIK 密鑰確受到pTPM 物理保護的真實性;對vTPM 管理器利用pTPM 提供的可信憑據(jù)做可信判定,得出vTPM管理器及其所在底層物理平臺的可信性結(jié)論。如果可信,才為vTPM 管理器的MIK 密鑰頒發(fā)MIK 證書。
(3)vTPM 管理器為VM 創(chuàng)建相應的vTPM 實例,然后創(chuàng)建該vTPM 實例上的vEK 密鑰,再基于vEK 密鑰、MIK 密鑰和MIK 證書,向TTP 申請為該vTPM 實例頒發(fā)vEK 證書。
(4)TTP首先檢查MIK 證書的合法性,進而確定vTPM 管理器的身份合法性;其次基于MIK 公鑰驗證vTPM 管理器確是MIK 密鑰所有者的真實性;最后為vEK 密鑰頒發(fā)vEK 證書,并以一種只能由vTPM 管理器利用pTPM 才能解密的方式將vEK 證書傳遞給vTPM 管理器。
3.3.1 設計方案綜合概述
VM-vTPM 熱遷移整體方案如圖4 所示,MC集成到P 的管理應用程序中,ME 集成到D 和S 的vTPM 管理器中并作為VM 管理器的一部分,只有vTPM 管理器可以直接調(diào)用pTPM。方案大致流程為:(1)P 收到預遷移請求;(2)P 調(diào)用MC,并聯(lián)合TTP,對S 和D 做雙向遠程證明;(3)如果S 和D可信,先由P 觸發(fā),然后S 和D 將依次收到遷移請求,并且S 和D 要對收到的遷移請求消息做比對檢查,檢查包括待遷移虛擬機標識IDVM等信息的有效性;(4)在參與VM-vTPM 熱遷移的各方(P、S 和D)之間都架設一條加密傳輸通道;(5)在加密傳輸通道內(nèi)完成VM-vTPM 數(shù)據(jù)的熱遷移。本文接下來對流程中的雙向遠程證明、加密傳輸通道構(gòu)建和VM-vTPM 數(shù)據(jù)傳遞作進一步闡述。

圖4 VM-vTPM 熱遷移方案設計
3.3.2 雙向遠程證明階段
如圖5 所示,MC 收到預遷移請求后,分別向S 和D 上的ME 發(fā)起可信驗證請求,由ME 向MC返回底層平臺的可信憑據(jù),本階段的最后,如果S和D 是可信的,會從MC 收到IDVM和對方的MIK證書。
具體交互過程如下文所述。
(1)MC→MES:K1SymEnc(PCRs1||NMC1||Time1||)NMC1||Time1||MC.privsig1(NMC1||Time1)||TTP.prisig1(cpHashquote(PCRs1||NMC1||MameS.MIK)))||S.MIK.pubAsymEnc(K1)。其中,PCRs1是S 提供的可信憑據(jù)中要選定的PCR 值,NMC1是MC 生成的隨機數(shù),Time1是時間戳,TTP.prisig1是TTP 對S 上的MIK 密鑰執(zhí)行TPM2_Quote命令的簽名增強授權(quán)。MES調(diào)用pTPM 中的MIK密鑰解密出對稱密鑰K1,用K1解密取出PCRs1,NMC1,Time1,MC.privsig1和TTP.prisig1,用本地MIK證書中記錄的可信任MC 的公鑰值驗證簽名值MC.privsig1,用本地MIK 證書中記錄的IP 信息和消息來源URL 中的IP 做比對檢查,檢查時間戳Time1的新鮮度,所有檢查通過后才繼續(xù)處理來自MC 的請求消息。
(2)MES→MC:K2SymEnc(S.MIK.privquotel(PCRs1||NMC1)||EventLogS||NS)||MC.pubAsymEnc(K2),其中,NS是S 生成的隨機數(shù),S.MIK.privquotel是S 在簽名增強授權(quán)TTP.prisig1下執(zhí)行TPM2_Quote 命令后的輸出結(jié)果(即可信憑據(jù))。MC 用自己的私鑰解密出對稱密鑰K2,用K2解密取出S.MIK.privquotel,EventLogS和NS,檢查S.MIK.privquotel中的被簽名數(shù)據(jù)包含的隨機數(shù)NMC1在內(nèi)的消息正確性,驗證S.MIK.privquotel中的簽名值,通過度量日志EventLogS、本地標準值數(shù)據(jù)庫和PCR 度量值驗證S 上底層平臺環(huán)境的可信性,最終給出S 能否被信任的判定結(jié)論。
(3)MC→MED:K3SymEnc(PCRs2||NMC2||Time2||MC.privsig2(NMC2||Time2)||TTP.prisig2(cpHashquote(PCRs2||NMC2||MameD.MIK)))||D.MIK.pubAsymEnc(K3)。用和步驟1類似的辦法,S 將可信憑據(jù)以安全的方式發(fā)送給MC。
(4)MED→MC:K4SymEnc(D.MIK.privquote2(PCRs2||NMC2)||EventLogD||ND)||MC.pubAsymEnc(K4)。用和步驟2類似的辦法,最終給出D 能否被信任的判定結(jié)論。
(5)MC→MES:K5SymEnc(CertD.MIK||NS||MigReqS->D(IDVM)||MC.prisig3(CertD.MIK||NS||MigReqS->D(IDVM)))||S.MIK.pubAsymEnc(K5)。如果MC 判定S 是可信的,則MC 發(fā)送此消息給S。其中,CertD.MIK是D 的MIK證書,MigReqS->D(IDVM)是將虛擬機IDVM從S 遷移到D 的遷移預請求。MES調(diào)用pTPM 中的MIK 密鑰解密出對稱密鑰K5,用K5解密取出CertD.MIK,NS,MigReqS->D(IDVM) 和MC.prisig3,用本地MIK證書中記錄的可信任MC 的公鑰值驗證簽名值MC.privsig3,檢查隨機數(shù)NS和步驟2 中的一致性,保存D 的MIK 證書CertD.MIK,記錄遷移預請求MigReqS->D(IDVM)。
(6)MC→MED:K6SymEnc(CertS.MIK||ND||MigReqS->D(IDVM)||MC.prisig4(CertS.MIK||ND||MigReqS->D(IDVM)))||S.MIK.pubAsymEnc(K6)。用和步驟5 類似的辦法,如果MC判定D是可信的,D對接收的數(shù)據(jù)檢查都通過后,同樣保存S 的MIK 證書CertS.MIK,并記錄遷移預請求MigReqS->D(IDVM)。
3.3.3 構(gòu)建加密傳輸通道
在目前的開源組件qemu-7.2.0[10]和libvirt-9.0.0[12]中的VM-vTPM 熱遷移的具體實現(xiàn)包括了TLS 傳輸協(xié)議的實現(xiàn),可以保障被傳輸數(shù)據(jù)的機密性和完整性。此外,也可以對目前開源組件中的TLS 協(xié)議實現(xiàn)進行改良,實現(xiàn)一種基于pTPM 的增強TLS 傳輸協(xié)議,改良方法參見文獻[13]。
3.3.4 VM-vTPM 數(shù)據(jù)傳輸
本節(jié)提出的VM-vTPM 數(shù)據(jù)傳輸方法是在開源組 件qemu-7.2.0[10]、libvirt-9.0.0[12]、swtpm-0.8.0[14]和libtpms-0.9.6[15]的基礎上改進的。本節(jié)主要闡述改進后的VM-vTPM 熱遷移中的vTPM 實現(xiàn)設計,分為vTPM 實例在源平臺和目標平臺之間的熱遷移管理控制流程、vTPM 實例在源平臺和目標平臺之間的傳遞和vTPM 實例在源平臺上的收集和在目標平臺上的恢復這3 個部分。
(1)vTPM 實例在源平臺和目標平臺之間的熱遷移管理控制流程。在VM 的熱遷移管理控制方式的基礎上,為vTPM 的熱遷移新增如下內(nèi)容:
①S 傳遞給D 的VM 配置信息XML 文件中,增加示例中的vTPM遷移配置信息,其中:sym_mode 表示對稱加密使用的分組模式,sym_def 表示對稱加密算法名稱,rmt_MIK_cert 表示對端MIK 證書存放路徑。此XML 文件傳遞完成后,S和D 需要把對端的MIK 證書存放在rmt_MIK_cert 所指的文件路徑中。示例:<migration sym_mode=’cbc’sym_def=’sm4’ rmt_MIK_cert=’/home/rmt/MIK.cert’/>。
②S 調(diào)用D 的遷移準備函數(shù)后,D 首先創(chuàng)建一個空白的vTPM 實例,等待vTPM 實例信息的遷入。
③提前在S 中新注冊一個可遷移字段的TPM設備,S 會在遷移VM 運行中的狀態(tài)數(shù)據(jù)時收集所有可遷移狀態(tài)設備信息,通過加密傳輸通道傳遞到D 上的VM,新注冊的TPM 設備的描述代碼如下:
其中,name 字段是對TPM 設備的描述,函數(shù)tpm_emulator_pre_save 表示此設備狀態(tài)數(shù)據(jù)的收集方法,即vTPM 實例在S 上的收集函數(shù)。函數(shù)tpm_emulator_post_load 表示設備狀態(tài)數(shù)據(jù)的恢復方法,即vTPM 實例在D 上的恢復函數(shù)。
(2)vTPM 實例在源平臺和目標平臺之間的傳遞。將S 中的函數(shù)tpm_emulator_pre_save 收集到的vTPM實例信息通過加密傳輸通道傳遞給D,D 中的函數(shù)tpm_emulator_post_load 將收到的vTPM 實例信息恢復并載入到空白的vTPM 實例。
(3)vTPM 實例在源平臺上的收集和在目標平臺上的恢復。設計流程如圖6 所示,進一步說明如下文所述。

圖6 vTPM 實例的收集和恢復
①控制命令CMD_GET_STATEBLOB 和CMD_SET_STATEBLOB。在QEMU 和SWTPM 之間設置兩類控制消息:CMD_GET_STATEBLOB 和CMD_SET_STATEBLOB。前者是請求SWTPM 收集并返回vTPM實例信息,后者是請求SWTPM 恢復特定TPM 實例。
②函數(shù)TPMLIB_GetState 和TPMLIB_SetState。libtpms.so 庫以純軟件的方式仿照了pTPM 芯片的所有功能,對外提供的函數(shù)TPMLIB_GetState 和TPMLIB_SetState 可分別用于導出或載入vTPM 實例數(shù)據(jù)。
③vTPM 實例的導出和載入。vTPM 實例中的數(shù)據(jù)分為非易失性部分和易失性部分,前者是指“電源關(guān)閉”后仍需要保留的數(shù)據(jù),包括種子、用戶自定義NV、持久密鑰、制造時間和固件版本等信息,后者是指“掉電”后會被抹去的數(shù)據(jù),包括PCR 值、已加載的會話、臨時密鑰、使能配置標記和時鐘狀態(tài)等信息。vTPM 實例信息的導出是將所有非易失性數(shù)據(jù)和易失性數(shù)據(jù)串聯(lián)在一起形成特定數(shù)據(jù)塊,vTPM 實例信息的載入是將指定數(shù)據(jù)塊進行拆分并恢復出各個非易失性數(shù)據(jù)和易失性數(shù)據(jù)的字段值。
④數(shù)據(jù)的安全密封和解封。當SWTPM處理控制命令CMD_GET_STATEBLOB 時,會調(diào)用函數(shù)TPMLIB_GetState 獲取vTPM 實例,先對其安全密封,然后將密封后的數(shù)據(jù)返回給QEMU;當SWTPM處理控制命令CMD_SET_STATEBLOB 時,會將QEMU 發(fā)來的待恢復vTPM 實例數(shù)據(jù)先做安全解封,然后才調(diào)用函數(shù)TPMLIB_SetState 將解封后的vTPM實例載入到空白的vTPM 實例等待啟用。vTPM 實例的安全密封和解封算法如下。

在算法1 和算法2 的偽代碼中,輸入?yún)?shù)sym_def、sym_mode 和rmt_MIK_cert 分別是從啟動參數(shù)中獲取的對稱算法名稱、分組模式和對端MIK 證書。算法中用到的Rmt.MIK.pub 和Rmt.SK.pub 分別表示對端的MIK 密鑰和SK 密鑰的公鑰。此外,MIK 密鑰和SK 密鑰是pTPM 創(chuàng)建的不可復制密鑰,當用本地MIK 密鑰做加解密、用本地SK 密鑰做簽名時,均需要調(diào)用pTPM,由于SWTPM 本身不能直接調(diào)用pTPM,所以算法1 和算法2 需要借助vTPM 管理器即libmgtvtpms.so 庫對外提供的相關(guān)函數(shù)間接調(diào)用pTPM,完成對相關(guān)密鑰的使用。
本文的vTPM 證書鏈擴展設計中的MIK 證書由TTP 簽發(fā),證書的擴展項中設置了可信任MC 的IP和公鑰等標識信息。當MC 分別和S、D 發(fā)起含有MC 簽名值的遠程可信證明請求時,S 和D 先基于MIK 證書中的可信任MC 的IP 和公鑰信息對請求消息做合法性檢查,檢查通過后受理該驗證請求。這樣的設計可以減輕S 和D 在VM-vTPM 熱遷移階段遭受的拒絕服務攻擊。
本文的VM-vTPM 遷移協(xié)議設計中的第一個階段就是對S 和D 做基于pTPM 的雙向遠程可信證明,保證只有受信任的源平臺才可以發(fā)起有效的遷移請求,只有受信任的目標平臺才可以接收來自特定源平臺對特定虛擬機的遷移請求。這符合在整個遷移過程中需要保持基礎信任關(guān)系的要求。
本文的VM-vTPM 遷移協(xié)議設計中的第2 個階段是在參與遷移的各方之間建立一條加密傳輸通道,可以用傳統(tǒng)的TLS 協(xié)議,也可以用文獻[15]中的基于pTPM 的增強TLS 協(xié)議。構(gòu)建的加密傳輸通道可以滿足后續(xù)待遷移的VM-vTPM 數(shù)據(jù)在遠程傳遞過程中的機密性和完整性等基本安全要求。
本文的VM-vTPM 遷移協(xié)議設計中的第3 個階段是VM-vTPM數(shù)據(jù)的正式傳遞,其中基于pTPM的vTPM 實例數(shù)據(jù)的安全密封和安全解封設計為vTPM 數(shù)據(jù)在遠程傳遞過程中提供了基于pTPM 的硬件級別的機密性和完整性保護。S 上受pTPM 保護的不可復制密鑰SK 對vTPM 數(shù)據(jù)的簽名可以使D 對數(shù)據(jù)來源的身份真實性進行判斷。
通過以上的綜合分析可知,本文提出的協(xié)議設計能滿足VM-vTPM 熱遷移的基本安全要求。然而,仍然存在一些局限。
(1)如果向P 發(fā)起預遷移請求的管理員不受信任,或者攻擊者獲得了P 的管理員權(quán)限,將無法保證VM-vTPM 熱遷移的安全性。
(2)如果在VM-vTPM 熱遷移的進行過程中將惡意代碼注入包括vTPM 管理器在內(nèi)的可信組件中,比如S 和D 已經(jīng)完成了雙向遠程可信證明并構(gòu)建起了加密傳輸通道,vTPM 管理器遭到惡意代碼注入攻擊,則VM-vTPM 熱遷移過程中的安全也會受到威脅。
(3)因為沒有為包括vTPM管理器在內(nèi)的可信組件的運行環(huán)境和其他組件的運行環(huán)境提供硬件級別的隔離環(huán)境,因此可信組件在運行時有可能遭到來自操作系統(tǒng)、硬件和其他應用程序的攻擊。
本文首先提出了一種vTPM 證書鏈擴展設計,是在VM 管理器中集成vTPM管理器,基于pTPM為vTPM管理器創(chuàng)建了可以加密但簽名運算受到TTP簽名管控的MIK 密鑰;其次針對當前開源組件qemu-7.2.0[10]、libvirt-9.0.0[12]、swtpm-0.8.0[14]和libtpms-0.9.6[15]上的VM-vTPM 熱遷移實現(xiàn)部分存在的安全問題,結(jié)合本文的vTPM 證書鏈擴展設計,新設計了一種VM-vTPM 熱遷移協(xié)議并給出實際的實現(xiàn)方法,然后對其安全性進行了綜合評估。
在未來的工作中將完成原型實現(xiàn)以便對本文中的熱遷移協(xié)議和實現(xiàn)方法的性能進行評估,并進一步探討vTPM 的硬件解決方案,還將引入新的硬件技術(shù)解決包括vTPM 管理器在內(nèi)的可信組件運行時的安全問題,并重新評估本文所提的VM-vTPM 熱遷移協(xié)議設計方案。