近年來，虛擬化技術以隔離性強、易維護、節約成本和支持跨平臺應用等良好特性逐漸成為了云計算、網格計算以及高性能計算等應用環境的核心技術及中堅技術力量， 與此同時，其安全問題也逐漸凸顯[1]。可信計算[2]作為一種安全保障基礎設施，有利于搭建終端平臺之間的可信連接，構建誠實、互相信任的虛擬空間，因此被越來越多的組織和個人應用到虛擬系統中以保障安全可靠性。

　虛擬化技術帶來的最重要優勢之一就是虛擬機的遷移(以下稱VM遷移)。目前，很多監控程序，如VMware的vSphere監控程序(EAXi)以及Xen監控程序都支持VM遷移。但是目前業界對VM遷移的研究主要集中在優化其遷移性能上[3]，對安全方面的考慮一直很少。
    通過引入虛擬TPM(以下稱為vTPM)[4]的概念，可信計算實現了對虛擬化系統的擴展。擴展后的虛擬系統上的多個VMs共享同一個物理硬件TPM，各個VM中的應用程序可以使用各自的vTPM來實現敏感信息的安全存儲以及自身平臺的完整性報告。在引入可信計算的虛擬系統中，為了確保VM遷移之后各VM及其應用程序能夠正確地操作，必須將vTPM隨其服務的VM一起遷移，本文將其稱為安全VM-vTPM遷移。近年來，在軟、硬件方面均出現了虛擬化TPM的體系結構，并且在vTPM的遷移協議方面也出現了諸多嘗試。本文在研究現有vTPM遷移方案的基礎上，首先分析了安全VM-vTPM遷移所面臨的幾個主要安全需求，并針對這些安全需求提出了一種新的安全VM-vTPM遷移協議，最后，基于Xen討論了協議的具體實現，并對其性能進行了評估。
1 安全VM-vTPM遷移協議需求分析
　目前涉及vTPM遷移的主要有四個協議，本文分別將其標記為協議1[4]、協議2[5]、協議3[6]和協議4[7]。協議1通過對vTPM實例的狀態數據進行加密，來確保vTPM實例在遷移過程中的安全性。但是由于沒有考慮目標平臺的限制，遷移之后vTPM狀態的安全性不能得到保證。協議2引入了一個稱為TPM控制結構的數據結構來存儲與TPM上下文相關的所有狀態信息，通過控制這個數據結構的安全傳輸來實現TPM上下文在不同平臺之間的安全遷移，整個過程都是在一條可信的通信信道上實施的。協議3是從Xen的源碼中抽象出來的，整個遷移過程是在目標平臺上的一個遷移密鑰的控制下實施的，可以保證遷移內容的機密性，但是卻無法應對攻擊者在遷移過程中實施的破壞，例如修改vTPM狀態內容。協議4為應對基于屬性的TPM虛擬化而提出的，基于屬性的虛擬化使用屬性證書而非二進制哈希值作為度量值來擴展vPCRs，因此可以在具有相同安全保障的兩個平臺之間實現vTPM的遷移。
    分析上述協議后,提出安全VM-vTPM遷移協議需要考慮的安全需求如下：
    (1)確保VM-vTPM被遷移到了一個安全可信的目標平臺。在VM-vTPM遷移之前，遷移源平臺需要對目標平臺進行證明，以確保源平臺上的VM及其vTPM能夠遷移到一個安全可信的目標平臺。現有遷移協議要么假設目標平臺是可信的，要么完全忽略目標平臺的安全屬性。
    (2)確保遷移前后及遷移過程中VM及其vTPM的安全關聯。在遷移過程中綁定VM及其vTPM是十分重要的，它可以阻止攻擊者在遷移過程中實施對VM/vTPM的任一改變，還可以簡化遷移之后目標平臺上VM-vTPM的重新關聯。VM-vTPM的綁定可以是隱式的，也可以是顯式的。
    (3)確保遷移過程中VM-vTPM的機密性和完整性保護以及抗重放攻擊保證。遷移過程中，必須使用恰當的密碼技術來保護VM及其vTPM的機密性和完整性，以阻止未授權的訪問和修改進而避免VM或vTPM被惡意篡改。同時，還需要應用相應的機制來阻止遷移過程中的重放攻擊，以避免發生VM或vTPM數據丟失的情況。
　　(4)確保遷移的原子性。原子性是指在沒有任一中間狀態的情況下，確保成功遷移或是維持現狀的一種屬性。為了保證遷移過程的原子性，需要提供相應的機制，確保成功遷移之后能夠刪除源平臺上的vTPM，而一旦遷移失敗則刪除目標平臺上的vTPM。這對于故障恢復和阻止產生重復拷貝，非常重要。
2 VM-vTPM遷移協議設計
　    在開始安全VM-vTPM設計之前需要注意兩點：(1)本文認為協議涉及到的任一主體（源和目標平臺）上都存在一個遷移控制實例，用于處理遷移請求。遷移控制器的位置與具體實現有關,它可以是VMM的一部分，也可以是vTPM管理器或者是Dom0的一部分[8]。(2)為了簡化協議的設計與實現，本文認為源平臺和待遷移的VM對目標平臺來說都是可信的,如果協議為平臺配置了動態度量機制,可以確保源平臺及VM狀態的任一非法改變都會被檢測到并且可以得到正確處理，則這個假設就是合理的。結合動態度量機制設計安全VM-vTPM遷移協議是下一步要進行的工作。
2.1 VM-vTPM遷移協議概述
    VM-vTPM遷移協議可以劃分為4個階段：(1)源平臺和目標平臺相互認證對方的真實性，并且協商遷移過程所使用的用于保護機密性和完整性的密碼機制。然后，源平臺發送證明請求給目標平臺，以確保VM-vTPM被遷移到一個安全可信的平臺。(2)在證實了目標平臺的真實性和完整性之后，源平臺鎖定VM及vTPM，然后使用先前協商的密碼機制安全傳輸VM及其vTPM。(3)目標平臺首先檢查接收到的VM及其vTPM的完整性，如果檢查通過，則引進該VM-vTPM對（與具體的實現相關），并發送消息告知源平臺已成功接收VM及其vTPM。(4)源平臺刪除被遷移的VM及vTPM以阻止進一步的復制或者其他操作,并且通知目標平臺遷移已經成功完成，目標平臺接收到DONE消息之后恢復VM及vTPM。至此，遷移過程完成。
2.2 VM-vTPM遷移協議詳細設計
    圖1給出了將一個VM及其vTPM從一個平臺（圖中稱之為源平臺）遷移到另外一個平臺（圖中稱之為目標平臺）時進行信息交換的順序。根據2.1節劃分的4個階段詳細描述各個階段的信息交互情況。

    階段1：安全會話建立
    階段1中，源平臺和目標平臺相互認證，并且協商用于保護接下來的數據交換的機密性和完整性的密碼方案。密碼學上保證機密性的正確實施，通常有兩種方法——公鑰加密和對稱密鑰加密。由于在保護大批量數據傳輸的機密性方面，對稱密鑰加密的有效性較高，密碼學上通常使用公鑰密碼的方法來交換對稱密鑰，然后再將對稱密鑰用于大批量數據的加密傳輸。本協議也使用了此方法。另外，密碼學上通常使用數字簽名、經過哈希的消息認證碼（HMAC）、檢驗和等方法來確保傳輸數據的完整性，本協議采用HMAC方法。
　本文使用TLS握手協議為接下來待傳輸的數據獲取密鑰，以確保數據的機密性和完整性。握手協議將會產生兩個對稱密鑰——Kenc和Kmac，這兩個密鑰是由源和目標平臺在握手過程中使用交換的信息分別計算出來的，Kenc用于加密(使用對稱密碼,例如RC4、128 bit的AE3或者3DES)，Kmac則用于使用SHA1創建HMACs，以確保完整性。此階段之后每一個交換消息都將使用Kenc進行加密，而HMAC則僅在VM-vTPM傳輸之前與加密報文相連,源和目標平臺僅接受具有有效HMACs的報文。
　階段2：對目標平臺的遠程證明
　階段1建立了一個安全會話通道，用于保護階段2進行交換的所有報文的機密性和完整性。由于信任目標提供者（源平臺）不會執行重放攻擊，因此只需要在證明階段確保報文的新鮮性以阻止第三方重放舊的配置。
　在本階段首先由源平臺向目標平臺發出遠程證明請求Attest_reqs，要求獲取目標平臺的完整性信息，以判斷目標平臺的安全等級。為了確保報文的新鮮性，在階段I之后，源平臺將產生一個時間戳Ns1，并且將其與證明請求一起發送給目標平臺。目標平臺接收到包含證明請求的報文之后，首先驗證其HMAC的有效性，然后通過vTPM管理模塊與硬件TPM進行交互，得到與目標平臺TCB相關聯的PCRs簽名值，將其與源平臺時間戳Ns1一起，使用目標平臺身份證明密鑰AIKd對其進行簽名，并創建一個新的目標平臺時間戳Nd1,隨此簽名值一起加密發送回源平臺。源平臺接收到目標平臺發送回來的報文之后，首先驗證HMAC有效性及時間戳的新鮮性，然后驗證目標平臺的完整性及安全等級。如果驗證通過,則鎖定VM及其vTPM以確保后面要進行的工作不會被打斷或者是被進一步修改。VM的鎖定由虛擬機監控器實現，vTPM的鎖定則需要由管理員啟動vTPM管理模塊來實現。例如, 在Xen中就需要由管理員通過TPM_LockInstance命令來啟動vTPM管理模塊實現對vTPM狀態的鎖定。與此同時,發送SVR_ATT_OK報文給目標平臺。否則,發送SVR_ATT_FAILED給目標平臺以告知遷移發生錯誤，并終止進一步的遷移操作。
    階段3： vTPM及VM傳輸
    需要說明的是，在此階段，vTPM及VM傳輸的具體實施要依賴于監控程序及TPM虛擬化的具體實施方案。但是，不管在哪種情況下，鎖定的VM及其vTPM都是要聯系在一起的，并且是使用Kenc進行加密過的（加密的結果為EncKenc(VM||vTPM)）。結果報文與Nd1一起形成m4，然后再使用Kmac對m4進行相應的HMAC運算,并且將運算結果與m4一起傳輸給目標平臺。時間戳Nd1用于阻止重放加密數據到目標平臺。本協議中，限制每一次會話只能傳輸一個VM-vTPM,以避免追蹤不同的VM-vTPM到同一個物理平臺。
　接收到報文之后，目標平臺首先驗證HMAC及時間戳，以確保在傳輸過程中VM及vTPM未受到任何篡改及偽造，若驗證成功，則引進VM及vTPM，并為其指派需要的資源，且發送DONE報文給源平臺，以告知源平臺目標平臺已成功引進VM及其vTPM。否則，刪除接收到的報文，并且發送IMPORT_FAILED給源平臺，以告知源平臺遷移過程中發生了異常,需要中止此次遷移。
　階段4：在源平臺上刪除并且在目標平臺上恢復VM及其vTPM
    一旦接收到來自目標平臺的DONE報文，源平臺將會刪除VM及其vTPM。但是，如果它接收的是一個IMPORT_FAILED報文，則不會刪除VM及其vTPM。源平臺在刪除VM及其vTPM之后，將會通知目標平臺遷移已經完成，然后再由目標平臺恢復VM及其vTPM。VM的恢復由監控程序完成，而vTPM的恢復則依賴于所選擇的TPM虛擬化解決方案，例外如在當前的Xen監控程序對TPM的虛擬化解決方案中，就是通過修改遷移到目標平臺上的vTPM實例狀態數據中的低位PCRs寄存器的值為目標平臺本地TCB的配置和屬性信息來恢復vTPM狀態的。
2.3 遷移過程中的vTPM密鑰保護
    TPM規范[2]規定將TPM中的存儲根密鑰（SRK）作為其密鑰體系的根密鑰，所產生的每一個密鑰的私鑰都必須由其父密鑰對其進行加密。在vTPM的設計過程中，需要為vTPM實例創建一套獨立的密鑰體系，一方面可以加快密鑰的產生過程，另一方面，也可以簡化vTPM實例的遷移過程。vTPM密鑰層次的設計是TPM虛擬化應該考慮的問題，不是本文的重點,這里,僅對VM-vTPM遷移過程中的密鑰保護進行相應地說明。
    在VM-vTPM的遷移過程中，應該要確保vTPM密鑰能夠安全可靠地傳輸到目標平臺，并且能夠在目標平臺上使用，以避免在VM-vTPM遷移過程中遭受攻擊者的未授權修改，進而導致目標平臺上應用程序拒絕vTPM服務。本文選擇使用一個受硬件TPM保護的對稱密鑰對vTPM密鑰體系實施保護。在遷移之前首先對這些密鑰層次的哈希值進行加密/密封,而在目標平臺重新獲取密鑰層次時,通過驗證其哈希值,檢測vTPM的密鑰層次是否被篡改,進而確保vTPM密鑰層次能夠安全可靠地傳輸到目標平臺，供目標平臺上的應用程序使用。
2.4 協議評估
    根據安全需求，對上面的協議進行了簡單的評估：
　(1)VM-vTPM遷移到一個安全可信的目標平臺
    協議通過TLS握手協議，在源和目標平臺之間建立了一個經過認證的安全通道，并且在實際傳輸之前，階段II實施了對目標平臺的遠程證明，可以阻止將VM-vTPM遷移到一個不安全的平臺，從而確保VM-vTPM遷移到一個安全可信的目標平臺。
    (2)安全VM-vTPM關聯
    協議通過在受相同HMAC保護的同一報文中同時加密傳輸VM及其vTPM，實現了VM及其vTPM的隱式關聯，保護了VM-vTPM遷移的機密性和完整性。
    (3)VM-vTPM遷移的機密性和完整性保護
    協議在階段1建立安全通道的同時產生了一個僅對源和目標平臺已知的對稱加密密鑰和HMACs，所有的報文在實際傳輸之前均需要使用這個對稱加密密鑰進行加密，從而保證了傳輸數據的機密性。同時，通過使用HMACs可以發現VM/vTPM在傳輸過程中的任一改變，進而確保傳輸數據的完整性。
    (4)VM-vTPM遷移的抗重放攻擊
    協議中VM-vTPM是加密傳輸的，攻擊者不能訪問VM/vTPM的內容,但可以記錄并在稍后重放同一VM-vTPM對到目標平臺。協議的每一步都使用了時間戳來保證傳輸報文的新鮮性，避免了攻擊者在不被檢測到的情況下將一個舊的加密報文重放到目標平臺，也即阻止了攻擊者的重放攻擊。
    (5)遷移的原子性
    原子性旨在阻止VM-vTPM副本的產生以及數據的丟失。協議通過在VM-vTPM成功遷移之后刪除源平臺上的VM-vTPM對，避免了產生VM-vTPM的多余拷貝。另外，通過在遷移失敗的情況下刪除目標平臺上接收到的VM-vTPM對并提供相應的恢復機制，避免了數據的丟失，進而保證了遷移過程的原子性。
3 基于Xen的VM-vTPM遷移協議實現

    本文選擇Xen監控程序來探討VM-vTPM遷移協議的實現，原因是：(1) Xen是開源的，它具有一個良好的支持框架，在研究項目中經常使用；(2) Xen支持VM遷移并且現有的Xen已經缺省配置了vTPM體系結構。
    本文選擇在VM內運行vTPM實例，這種方法比在Xen的Dom0內運行vTPM實例的安全性要高，并且可以避免VM-vTPM遷移后重新關聯VM及其vTPM所引發的身份沖突問題。而且，簡化了Dom0的代碼復雜度，提高了Xen的執行效率。
    在遷移源和目標平臺之間，本文使用OpenSSL創建一個安全的連接，并且在源和目標平臺上都安裝了一個自我簽名的CA證書，用于簽名其公鑰證書，以實現源和目標平臺的雙向認證，并且產生相應的主密鑰和會話密鑰。
    由于目前尚不能獲取由隱私CA和有效PCR值組成的遠程證明框架，因此，本文選擇使用一個測試隱私CA和PCR一起來實現目標平臺的遠程證明。
    至于VM-vTPM的綁定，協議規定一次會話僅傳輸一個VM-vTPM對。
    本文比較了Xen原有vTPM遷移協議與本文所提出的安全VM-vTPM遷移協議在源和目標平臺上的性能開支，如表1所示。

    相比較于Xen原有的vTPM遷移協議,本文的安全VM-vTPM遷移協議所消耗的總遷移時間比原有的Xen遷移所消耗的時間多出6 s~11 s，這個性能開支很可能是由于在遷移之前建立安全遷移通道所引發的[9]。下一步，將具體分析協議各階段消耗的時間，并且考慮不同的密碼算法以及不同的vTPM設計方案對遷移協議的性能影響，以期在確保協議安全的同時盡可能地降低時間開銷。
參考文獻
[1] GARFINKEL T, MENDEL R. When virtual is harder than  real: security challenges in virtual machine based computing environments[C]. Proc of the 10th Workshop on Hot Topics in Operating Systems. Berkeley, CA:USENIX Association, 2005:210-217.
[2] TCG software stack specifications V1.2[DB/OL].http://www.trustedcomputing.com/.
[3] SAPUNTZAKIS C P, CHANDRA R. Optimizing the migration of virtual computers[C]. Proceedings of the 5th symposium on os security, 2002:377-390.
[4] BERGER S, KENNETH. vTPM: virtualizing the trusted platform module[C]. Proceedings of the 15th conference onUSENIX Security Symposium, 2006:305-320.
[5] STUMPF F, ECKERT C. Enhancing trusted platform modules with hardware-based virtualization techniques[C]. Proceedings of the 2008 Second International Conference on  Emerging Security Information, p1-9, 2008.
[6] Xen的源碼[OB/OL]. http://xenbits.xensource.com/.
[7] SADEGHI A R, STUBLE C.  Property-based tpm virtualization[C]. Proceedings of the 11th international conference on Information Security, 2008:1-16.
[8] Chen Liqun, LANDFERMANN R, STUBLE C. A protocol for property-based attestation[C]. Proceedings of the first ACM workshop on Scable trusted computing, 2006:7-16.
[9] STUMPF F, BENZ M, ECKERT C. An approach to a Trustworthy System Architecture Using Virtualization[C]. ATC 2007, 2007:191-202.