基于TPM聯盟的可信云平臺管理模型

田俊峰，常方舒

?

基于TPM聯盟的可信云平臺管理模型

田俊峰，常方舒

（河北大學網絡技術研究所，河北保定 071002）

以可信計算技術為基礎，針對可信云平臺構建過程中可信節點動態管理存在的性能瓶頸問題，提出了基于TPM聯盟的可信云平臺體系結構及管理模型。針對TPM自身能力的局限性，提出了宏TPM和根TPM的概念。針對可信云中節點管理時間開銷大的問題，引入時間樹的概念組織TPM聯盟，利用TPM和認證加密技術解決數據在TPM聯盟內節點間的可信傳輸問題，提出了一種基于時間樹的TPM聯盟管理策略，包括節點配置協議、注冊協議、注銷協議、實時監控協議、網絡管理修復協議和節點更新協議，闡述了時間樹的生成算法，分析了建立可信節點管理網絡的時間開銷和節點狀態監控的有效性。最后，通過仿真實驗說明了模型具有較好的性能和有效性。

TPM聯盟；云計算；可信云平臺；時間樹

1 引言

云計算通過將超大規模的計算和存儲資源整合起來，以按需服務的方式對外提供資源。越來越多的企業開始采用云計算，據Gartner預計，2016年全球數字內容的將存儲在云上，Forrester預計2020年全球云計算市場規模將達到2 140億美元。然而，云計算的發展仍然面臨著很多挑戰，其中云安全已成為其發展的最大障礙。Gartner的調查結果顯示，多于70%的受訪企業首席技術官表示近期不采用云計算，首要原因在于對數據安全性與隱私保護的憂慮[1]。傳統的數據加密只能保護數據存儲時安全，而當數據在云中以明文形式操作的時候，仍然面臨著云服務提供商內部員工惡意或者失誤造成的泄露，這就需要一種機制來保證云平臺中計算的機密性和完整性。

基于可信計算技術的可信云平臺能夠在用戶應用加載之前驗證當前平臺的狀態是否可信，從而保證數據的機密性和完整性。現在越來越多的基于用戶驗證或基于第三方驗證的可信云服務方案被提出來，但隨之而來的問題是，云服務提供商如何保證自己的云平臺是可信的。如果云服務提供商做不到這一點，那么用戶在使用上述方案時，云服務很可能通不過驗證，導致雙方無法進行服務交易，這對雙方都是不利的。因此本文從云平臺建設的視角來設計一個狀態可實時監控的可信云平臺。

2 相關工作

Garfinkel等[2]提出Terra框架通過可信虛擬機監視器構造閉盒虛擬機環境給應用程序提供隱私和完整性保護。Shakeel等[3]提出的自服務云計算模型通過引入新的權限模型來解決用戶對自己虛擬機的安全隱私保護和靈活控制問題。Jonathan等[4]提出的TrustVisor框架實現了具有特殊功能的虛擬機監視器，當安全敏感的代碼運行時能夠與商業操作系統和應用隔離。Hidekazu等[5]提出的VMCrypt系統通過雙視圖內存，即正常視圖和加密視圖，用戶虛擬機使用正常視圖，管理域使用加密視圖來防止用戶虛擬機中的內存信息泄露給管理域。Sven等[6]提出的加密即服務框架通過將用戶虛擬機中的加密操作和證書分離到用戶控制的加密域中來實施用戶自己的安全解決方案。Chen等[7]提出的cTPM通過TPM和云平臺共享一個根密鑰來解決TPM資源受限的問題。上述方案都是在單個主機上構建可信運行環境，然而云環境下存在大量的主機，這就需要可信主機之間進行協作。

吳吉義等[8]指出解決云安全問題的重要方案之一是將云計算與可信計算結合。Joshua等[9]提出的云驗證服務框架通過部署統一的云驗證服務來解決云用戶驗證云平臺完整性的問題。該方案的不足是平臺的完整性度量信息不能夠實時更新。Lucas等[10]提出動態完整性度量和驗證框架DynIMA以解決這個問題。Berger Stefan等[11]提出可信虛擬數據中心TVDc，該技術主要用于保證云環境中用戶虛擬機的隔離。隨后Berger等[12]對原始的TVDc進行功能增強，利用云資源的安全標簽來控制用戶對云存儲的訪問。Andy等[13]提出的Jobber是一個高度自治的多租戶網絡安全框架，用于適應云數據中心的動態特性和優化租戶之間的通信。Wu等[14]提出訪問控制即服務框架AcaaS，該框架的核心思想是將用戶的訪問控制策略的管理外包給服務提供商。劉川意等[15]提出的TCEE通過給用戶虛擬機綁定vTPM，利用TCG軟件棧TSS和OpenPTS將用戶虛擬機環境信息提交給可信第三方進行完整性驗證，來保證用戶應用程序運行環境的完整性。Li等[16]提出的多租戶可信計算環境模型MTCEM將云計算服務的安全職責進行分離，云提供商負責基礎設施的可信，用戶負責虛擬機實例和應用程序的可信。Zhang等[17]提出的CloudVisor框架利用嵌套虛擬化技術來增強云中多租戶環境下用戶虛擬機的安全保護。上述方案雖然對云環境下的可信問題進行了研究，但沒有考慮云節點管理這個問題。

Santos等[18]提出可信云計算平臺TCCP，該平臺通過可信協調者管理云中的所有可信節點，當節點規模很大時，管理這些節點的時間開銷是不能忍受的。隨后Santos等[19]改進的Excalibur通過采用基于屬性的密文策略加密算法CPABE和引入多個中心化的監視器來改進管理可信節點所造成的性能瓶頸。針對可信云平臺構建過程中可信節點管理存在的性能瓶頸造成的擴展性差的問題，Santos等改進的Excalibur是目前所提出的方法當中較好的。

王麗娜等[20]提出的基于可信平臺模塊的密鑰使用次數管理方法能夠安全有效地存儲和保護密鑰，從而保護云存儲中數據的機密性并控制密鑰的使用次數。田俊峰等[21]提出一種可信的云存儲控制模型TCMCS，該模型用于解決云存儲服務的安全問題。張煥國等[22]對云環境下的可信網絡連接進行研究，提出了統一的網絡訪問控制架構。王娟等[23]提出的POSTER利用可信網絡連接為云計算提供端到端的可信保護。周振吉等[24]針對云環境下虛擬機可信度量方法存在的并發性問題，提出一種樹形可信度量模型TSTM以提高度量模型的可擴展性。上述工作針對云平臺中秘鑰管理、云存儲、網絡訪問控制和虛擬機完整性度量等問題進行了研究。

可信云平臺的建設離不開對大規模可信云節點的自動化管理和實時監控。雖然Santos等針對節點管理這個問題提出了解決方案，但沒有徹底解決可信節點管理所造成的性能瓶頸，影響可信云平臺的擴展性。本文首先提出了基于TPM聯盟的可信云平臺體系結構，然后給出了基于時間樹的狀態可實時監控的可信云平臺管理方案。

3 基于TPM聯盟的可信云平臺體系結構

TPM（trusted platform module）聯盟是2個或2個以上的獨立的可信平臺模塊通過某種結構或協議組織起來的分布式可信基。TPM聯盟整體上作為可信云平臺（TCP, trusted cloud platform）的信任根，其中TPM作為可信云平臺中可信服務器（server）的信任根。基于TPM聯盟的可信云平臺體系結構如圖1所示。

云資源以虛擬機（VM, virtual machine）的形式提供給云用戶，OpenStack是云用戶訪問云資源的接口。可信云平臺由2類可信服務器構成，一類是管理節點，一類是服務節點。云管理員通過管理節點了解每個服務節點的可信狀態。MTPM（macro TPM）是基于TPM的可信證據收集和驗證模塊，主要負責其所在服務節點的可信證據收集和驗證其他服務節點的可信性，同時解決TPM計算資源不足的問題。RTPM（root TPM）是TPM聯盟的可信根，主要負責維護和管理整個TPM聯盟，TPM聯盟通過RTPM管理所有的MTPM。

MTPM邏輯結構如圖2所示，系統中各組件功能如下。

1) 可信證據收集組件：主要包含2部分功能，一是系統啟動時的靜態完整性度量（包括BIOS、bootloader、OS、可執行文件、配置文件）；二是系統運行時的動態完整性度量（包括虛擬機、進程的可執行文件、環境變量），結果存入證據數據庫。

2) 節點狀態收集組件：接收下級MTPM中節點狀態收集組件傳遞的節點狀態集合，并將驗證組件產生的節點狀態插入到節點狀態集合中，將修改后的節點狀態集合傳遞給上級MTPM中的節點狀態收集組件。

3) 驗證組件：利用基準數據庫中的基準值驗證下級MTPM中可信證據收集組件傳遞的證據，并將結果傳遞到節點狀態收集組件。

4) 證據數據庫：是服務節點中的內存數據庫文件，MTPM初始化時由可信證據收集組件創建并管理，證據數據庫的完整性由TPM保證，主要用來存放被度量對象的完整性度量值。

5) 基準數據庫：是服務節點中的磁盤數據庫文件，MTPM初始化時由驗證組件創建并管理，基準數據庫的完整性由TPM保證。

RTPM邏輯結構如圖3所示，系統中各組件功能如下。

1) 節點狀態收集組件：接收下級MTPM中節點狀態收集組件傳遞的節點狀態集合，并將驗證組件產生的節點狀態插入到節點狀態集合中，將修改后的節點狀態集合存入節點狀態數據庫。

2) 驗證組件：利用基準數據庫中的基準值驗證下級MTPM中可信證據收集組件傳遞的證據，并將結果傳遞到節點狀態收集組件。

3) 警報器：將不可信節點的狀態信息報告給云管理員。

4) 節點管理組件：TPM聯盟初始化時，云管理員利用該組件創建并管理云節點數據庫、可信軟件倉庫、節點配置數據庫。

5) 基準數據庫：是管理節點中的磁盤數據庫文件，MTPM初始化時由驗證組件創建并管理，基準數據庫的完整性由TPM保證，基準數據庫中的內容從RTPM中的節點配置數據庫獲得，用于驗證被驗證服務節點的完整性。

6) 節點狀態數據庫：是管理節點中的內存數據庫文件，TPM聯盟初始化時，由云管理員創建，用于實時記錄TPM聯盟中服務節點的狀態，數據庫大小只有在服務節點規模發生變化時才發生變化。

7) 云節點數據庫：是管理節點中的磁盤數據庫文件，存儲云中所有節點（包括服務節點、管理節點、未提供服務的節點）的元數據，元數據包括節點的UUID（節點唯一標識）、公鑰證書、IP和節點配置類型。

8) 可信軟件倉庫：是管理節點中的磁盤數據庫文件，存儲軟件的文件路徑和簽名信息，為TPM聯盟中安裝的軟件提供可信源，TPM聯盟中運行的每一個可執行文件都是可驗證的。

9) 節點配置數據庫：是管理節點中的磁盤數據庫文件，云管理員確定TPM聯盟中的節點配置類型，每一種配置類型的詳細信息包括服務器硬件信息、操作系統信息、運行的應用信息（例如軟件版本、配置參數等），每一種配置類型都會對應一個指紋。

在可信云平臺中，管理節點的RTPM負責維護所有云節點的狀態信息。為保證可靠性，管理節點一般由2臺服務器構成，組成熱雙工方式。MTPM周期性對所在節點進行完整性度量，度量信息通過時間樹最終匯集到RTPM中。

4 基于時間樹的云平臺可信節點管理策略

Santos等提出的TCCP通過引入可信協調者（TC）來管理云平臺內部的可信計算節點。TC負責處理云平臺內部可信節點的加入、退出和維護。由于TPM的低效，TC執行一次可信節點加入操作大約花費1 s甚至更長的時間，當大量的節點同時加入時，時間上的開銷是不能忍受的。同時TC負責管理所有的節點，當節點規模很大時，TC容易成為瓶頸。Excalibur雖然在監視節點與被管理節點之間采用基于屬性的密文策略加密框架（CPABE, ciphertext policy attribute-based encryption），減少了大量節點同時加入可信云平臺的時間成本，但是當涉及到節點的批量注銷和維護等管理操作時，監視節點仍然會成為系統瓶頸。針對上述問題，本文提出了基于時間樹的云平臺可信節點管理策略。

定義1 時間樹是一個二元組<,>，其中，是(0)個節點的有限集合，={|0?1}，是節點間邊的集合，=。

()被定義為

(2)

當且僅當和滿足=()時，<>，此時稱是的后繼節點，是的前驅節點，的所有后繼節點為兄弟節點。

若時間樹非空，稱<0, 0>為根節點。若≥，稱<,>為葉節點，否則<,>稱為分支節點。

依時間樹定義中集合和集合必須滿足的條件，形成的時間樹有2種表示形式。第1種表示形式如圖4(a)所示，時間樹中的節點依時間屬性值分層。第2種表示形式如圖4(b)所示，時間樹中的節點依兄弟關系進行分層。

4.1 可信云平臺節點管理

TPM聯盟中的節點依時間樹模型形成的可信節點管理網絡如圖5所示。

RTPM表示管理節點，MTPM表示服務節點。RTPM的編號為0，MTPM的編號按照時間樹的定義由云管理員在TPM聯盟初始化創建節點狀態數據庫時指定。節點的時間屬性值表示節點在第幾個認證周期加入到可信節點管理網絡中。認證周期表示2個節點之間進行遠程證明所花費的時間。

在描述具體協議之前，本文做如下約定。

UUID：表示節點的UUID，用于TPM聯盟和云節點數據庫中永久標識一個節點。

ID：表示節點的編號，用于可信節點管理網絡和節點狀態數據庫中標識一個節點。

MTPM：表示節點編號為ID的服務節點。

IP：表示節點的IP地址。

PK、SK：分別表示節點的公鑰和私鑰。

KEY：表示節點和共享的對稱密鑰。

ML：表示節點的完整性度量值，由可信證據收集組件產生。

CON：表示節點的配置類型，對應于節點配置數據庫中的某種配置類型。

CHECKVALUE：表示節點的基準值，是節點配置數據庫中與CON類型相對應的指紋。

{}：表示用密鑰對消息進行加密。

4.2 節點配置協議

該協議使MTPM從RTPM獲取自己的編號、前驅節點的IP和公鑰證書用于建立可信節點管理網絡。該協議在TPM聯盟啟動后（包括重新啟動）執行。

圖6描述了MTPM和RTPM之間的信息交換過程，具體流程如下。

1)MTPM向RTPM發送編號請求信息UUID。

2) RTPM通過UUID查詢節點狀態數據庫得到ID，同時發送響應信息ID。

3)MTPM將ID代入式(2)中，計算出前驅節點編號ID，同時發送前驅節點信息請求ID。

4) RTPM通過ID查詢節點狀態數據庫得到UUID，再通過UUID查詢云節點數據庫得到IP和PK，同時向MTPM發送響應信息：IP和PK；RTPM通過UUID查詢云節點數據庫得到PK、CON和CHECKVALUE，同時向發送信息ID、PK、CON和CHECKVALUE。

MTPM將ID、IP和PK存儲到TPM的非易失性存儲器中。將ID和PK存儲到TPM的非易失性存儲器中，將CON和CHECKVALUE存儲到基準數據庫。

4.3 節點注冊協議

該協議使RTPM驗證所有MTPM啟動后的完整性。MTPM通過驗證，才能成為TPM聯盟中的一員來提供服務。該協議與基于中心的節點管理策略不同的是，該協議的執行不一定發生在MTPM和RTPM之間，而是發生在MTPM和前驅節點之間，這樣保證了大量的節點能夠同時注冊。該協議同時實現了節點間的可信傳輸。可信節點管理網絡的建立是通過各MTPM執行節點注冊協議完成的，其中節點注冊協議利用了TPM的隨機數生成、密鑰生成、簽名和驗證簽名等基本功能。

MTPM每次重啟之后都要主動執行節點注冊協議，MTPM的狀態通過可信節點管理網絡傳輸給RTPM。RTPM利用可信節點管理網絡實時監控所有MTPM的狀態。

圖7描述了MTPM與之間的信息交換過程，具體流程如下。

1)MTPM向發送注冊請求信息ID、CON和隨機數1。

3)MTPM驗證1，若通過驗證發送響應信息：簽名2：{1,2,ML}SK。否則，發送掛起信號SUSPEND，等待下一個認證周期重新注冊。

4.4 節點注銷協議

當MTPM通過節點注冊協議添加到TPM聯盟中時，會形成如圖5所示的時間樹型拓撲的可信節點管理網絡。網絡中每一個MTPM的狀態都是通過前驅節點一級一級主動匯報給RTPM。當云管理員縮減節點規模時，可以注銷一部分MTPM，若注銷的MTPM節點是分支節點，必然會造成后繼節點的狀態無法傳遞到RTPM。為了使TPM聯盟能夠自由控制MTPM數量，同時又不破壞可信節點管理網絡，需要對節點的注銷采取以下策略，如圖8所示。其中圖8(a)注銷分支節點，圖8(b)注銷葉子節點。虛線表示省略中間節點，代表RTPM，其他字母代表MTPM。具體流程如下。

4.4.1 注銷節點

1)向發送注銷命令和PK，同時將從節點狀態數據庫中刪除。

2)收到注銷命令后，將PK和PK轉發給，將PK和IP發送給和，將ID發送給，將PK發送給和。此后在可信節點管理網絡中的職責由來承擔，關閉計算機。

3)收到PK和PK后，將PK存儲到TPM的非易失性存儲器中。更新前驅節點的公鑰為PK，更新前驅節點的IP為IP，將自己的編號改為ID。和收到PK后，更新前驅節點的公鑰為PK，更新前驅節點的IP為IP。收到PK和IP后，將的公鑰信息修改為PK，通過IP與建立可信通道。收到PK、IP和ID后，將PK、IP和ID轉發給Z。在節點狀態數據庫中修改的編號為ID，修改的編號為ID。

4)收到PK、IP和ID后，向前驅節點發送終止命令，修改前驅節點的IP為IP，修改前驅節點的公鑰為PK，修改自己的編號為ID，重新執行節點注冊協議。

4.4.2 注銷節點

1)向發送注銷命令和PK，將的編號改為ID，將ID發送給，將從節點狀態數據庫中刪除。

2)將存儲的PK修改為PK，向發送IP和PK。收到注銷命令后關閉計算機。收到ID后，將自己的編號改為ID。

3)收到送IP和PK后，將IP和PK轉發給。

4)收到IP和PK后向前驅節點發送終止命令，修改前驅節點的IP為IP，修改前驅節點的公鑰為PK，重新執行節點注冊協議。

當注銷大量MTPM時，RTPM應先注銷葉子節點，其次注銷編號大的分支節點，這樣能保證各MTPM的注銷同時進行。

4.5 節點狀態實時監控協議

MTPM的狀態分為3種：可信，即系統完整性未遭破壞；不可信，即系統中某些進程的完整性遭到破壞但節點的MTPM完整性未遭破壞（記為類型1）或者是節點的MTPM完整性遭到破壞但該節點的前驅和所有兄弟節點中至少有一個節點的MTPM完整性未遭破壞（記為類型2）；狀態未知，即MTPM的狀態沒有通過可信節點管理網絡傳遞到RTPM。節點的狀態轉換如圖9所示，其中虛線橢圓表示該狀態是暫態。

分布式狀態監控協議如下。

TPM聯盟中每個節點初始化2個空集合NoTrustedList和LeftList，其中NoTrustedList中的元素為節點的編號及其類型，LeftList中的元素為葉子節點編號。同時每個節點維護一個后繼節點列表SubsequentList，列表中元素按照節點編號降序排列。

TPM聯盟中每個節點進行如下操作。

1) 從SubsequentList取一個后繼節點。

2) 判斷與后繼節點的可信通道是否斷開，若是，則將后繼節點編號及類型2插入NoTrustedList；否則驗證可信證據，若驗證不通過，則將后繼節點編號和類型1插入NoTrustedList。

3) 判斷后繼節點是否為葉子，若是，將其編號插入到LeftList。

4) 將后繼節點的NoTrustedList插入到本節點的NoTrustedList，將后繼節點的LeftList插入到本節點的LeftList。

5) 判斷后繼節點是否為SubsequentList中的最后一個元素，若否，則跳轉到1)執行。

6) 將本節點的可信證據、NoTrustedList和LeftList傳遞給前驅節點。

RTPM節點中的NoTrustedList和LeftList將會是關于整個TPM聯盟中節點的狀態信息。RTPM通過LeftList計算出狀態未知的葉子節點編號列表NoStatusList。

1) 從NoStatusList中取一個葉子節點編號，并將其插入到NoTrustedList，置類型為2。

2) 以此編號計算前驅節點編號，若前驅節點編號未出現在NoTrustedList中，則將前驅節點編號插入到NoTrustedList，類型置為2，跳轉到2)執行。

3) 判斷NoStatusList是否遍歷完，若否，跳轉到1)執行。

4.6 可信節點管理網絡修復協議

為了維護可信節點管理網絡的完整性，采取以下修復策略。

1) 若是葉子節點出現故障，RTPM通過警報器隔離該節點并向云管理員報警。云管理員修復該節點后，該節點依據節點注冊協議重新加入TPM聯盟。

2) 若是單個分支節點出現故障，修復策略如圖10所示。

其中，、、、、代表MTPM，故障造成可信節點管理網絡局部連接中斷，從的后繼節點、、中選取一個節點代替。選取規則是選編號最大的節點。

假設圖10中編號最大，故選代替，該局部網絡的通信即可恢復。同時RTPM通過警報器隔離并向云管理員報警，修復后依據節點注冊協議重新加入TPM聯盟，這時可信節點管理網絡得到修復。

3) 若節點與前驅節點同時出現故障，修復策略如圖11所示。

其中，、、、、代表MTPM，代表RTPM。、故障造成可信節點管理網絡局部連接中斷，此時的后繼節點依照圖10的方式重建網絡，本圖中不再給出示例；從的后繼節點、中選取一個節點代替，選取規則依然是選編號最大的節點。圖中假設編號比編號大，故選代替。因為的前驅故障，所以不再與建立連接，而是直接與建立臨時連接，從TPM聯盟中選一個編號最大的節點作為的前驅節點，與建立連接后，該局部網絡的通信即可恢復。同時RTPM通過警報器隔離、并向云管理員報警，、修復后依據節點注冊協議重新加入TPM聯盟，這時可信節點管理網絡得到修復。

5 仿真實驗及結果分析

下面針對本文提出的可信云平臺管理模型從以下兩方面進行實驗驗證及分析：1) TPM聯盟建立可信節點管理網絡的時間開銷分析；2) TPM聯盟節點狀態監控的有效性分析。

5.1 性能分析

使用2臺瑞達可信安全服務器，每一臺配置Intel Xeon E5620，4G DDRIII，STCM，運行Linux 3.11.0，連接到1 Gbit/s網絡。使用這樣的環境測試節點注冊協議10次，取平均值，執行一次節點注冊協議的時間為1.93 s。這個測量結果與文獻[19]的測量結果基本吻合，文獻[19]中節點證明協議花費0.82 s，這是因為文獻[19]是單向認證，TPM quote操作只需執行一次，執行一次TPM quote操作大約需要0.8 s，而本文的節點注冊協議是雙向認證，需要執行2次TPM quote操作。使用Octave模擬100萬個節點建立TPM聯盟，其結果如圖12所示。

取執行節點注冊協議所需時間的一半作為單位時間，因為第一個加入TPM聯盟的MTPM節點不需要認證RTPM，也就是只需執行一次TPM quote操作，同時注冊協議中的第二次TPM quote操作，每個節點可以同時執行，即執行節點注冊協議的一半時間隱藏在第一個節點加入TPM聯盟的時間內。Time tree one 表示節點一次TPM quote操作認證一個后繼節點的方式建立TPM聯盟，Time tree two 表示節點采用Merkel tree[25]技術，一次TPM quote操作認證所有的后繼節點，Monitor表示采用文獻[19]中的節點注冊方法。從圖中可以看出，Time tree one方式下，100萬個節點加入TPM聯盟大約花費20 s，若采用Time tree two方式，則可以在更短的時間內提夠更多的可信節點來提供云服務，例如大約12 s時已有86萬個節點加入TPM聯盟，而Monitor方式下，20 s只能注冊1.3萬個節點。值得注意的一點是，當TPM聯盟規模確定時，相應的時間樹也就確定了，因此Time tree one和Time tree two這2種方式建立TPM聯盟的最終時間是一致的。本文采用的時間樹算法能夠使節點注冊的數量與時間成指數關系。文獻[19]中，每秒大約注冊633個節點，且節點注冊的數量與時間成線性關系，顯然當云規模巨大時，文獻[19]中的方法是不能勝任的。

5.2 有效性分析

使用Octave模擬具有100萬個節點的TPM聯盟的節點狀態，驗證節點狀態監控協議和可信節點管理網絡修復協議能夠使RTPM掌握所有節點的狀態，同時給出每個節點通過以下哪種方式將狀態傳遞給RTPM。方式如表1所示。

表1 節點狀態傳遞的不同方式

其中，方式1為正常節點的狀態傳遞方式，方式2~方式5為故障節點的狀態傳遞方式。實驗設定節點故障率從0.5%到5%變化，為了模擬真實場景，其中節點的故障按照故障率隨機產生，結果如圖13所示。

圖13結果數據分析顯示故障節點數量（即方式2~方式5下的節點數量之和）占總節點數量的比重與之前設定的節點故障率一致。該結論很好地驗證了此模型的有效性。其中方式2和方式3下的節點數量基本一致，且比方式4和方式5下的節點數量多，是因為前2種方式下的節點數量受單節點故障的影響（單節點故障是指該節點故障，而與該節點直接相連接的所有節點正常），而后2種方式下的節點數量受多節點同時故障（節點同時故障是指該節點與其直接相連接的部分或者所有節點同時故障）的影響。

6 結束語

構建可信云平臺是云計算被廣泛應用的重要前提，國內外研究者對如何構建可信云平臺進行了深入的研究，取得了重要研究成果。本文針對在可信云平臺中由于TPM的低效性引起的可信節點管理的性能瓶頸問題，提出了基于TPM聯盟的可信云平臺的管理模型。該方案與已有方案相比，很好地解決了可信節點管理的性能瓶頸問題。

[1] 馮登國, 張敏, 張妍. 云計算安全研究[J]. 軟件學報, 2011, 22(1): 71-83.

FENG D G, ZHANG M, ZHANG Y. Study on cloud computing security[J]. Journal of Software ,2011, 22(1): 71-83.

[2] GARFINKEL T, PFAFF B, CHOW J. Terra: a virtual machine-based platform for trusted computing[J]. ACM SIGOPS Operating Systems Review, 2003, 37(5): 193-206.

[3] BUTT S, LAGAR-CAVILLA H A, SRIVASTAVA A. Self-service cloud computing[C]//The 2012 ACM Conference on Computer and Communications Security. ACM, c2012:253-264.

[4] MCCUNE J M, LI Y, QU N. TrustVisor: efficient TCB reduction and attestation[C]//Security and Privacy (SP), 2010 IEEE Symposium. c2010:143-158.

[5] TADOKORO H, KOURAI K, CHIBA S. Preventing information leakage from virtual machines’ memory in IaaS clouds[J]. Information and Media Technologies, 2012, 7(4): 1421-1431.

[6] BLEIKERTZ S, BUGIEL S, IDELER H. Client-controlled cryptography-as-a-service in the cloud[C]//Applied Cryptography and Network Security. Springer Berlin Heidelberg, c2013:19-36.

[7] CHEN C, RAJ H, SAROIU S. cTPM: a cloud TPM for cross-device trusted applications[C]//The 11th USENIX Conference on Networked Systems Design and Implementation USENIX Association. c2014: 187-201.

[8] 吳吉義, 沈千里, 章劍林. 云計算: 從云安全到可信云[J]. 計算機研究與發展, 2011, 48(l): 229-233.

WU J Y, SHEN Q L, ZHANG J L. Cloud computing: cloud security to trusted cloud[J]. Journal of Computer Research and Development, 2011, 48(l): 229-233.

[9] SCHIFFMAN J, MOYER T, VIJAYAKUMAR H. Seeding clouds with trust anchors[C]//The 2010 ACM Workshop on Cloud Computing Security Workshop. ACM, c2010: 43-46.

[10] DAVI L, SADEGHI A R, WINANDY M. Dynamic integrity measurement and attestation: towards defense against return-oriented programming attacks[C]//The 2009 ACM Workshop on Scalable Trusted Computing. ACM, c2009:49-54.

[11] BERGER S, CáCERES R, PENDARAKIS D. TVDc: managing security in the trusted virtual datacenter[J]. ACM SIGOPS Operating Systems Review, 2008, 42(1): 40-47.

[12] BERGER S, CáCERES S, GOLDMAN K. Security for the cloud infrastructure: trusted virtual data center implementation[J]. IBM Journal of Research and Development, 2009, 53(4): 6: 1-6: 12.

[13] SAYLER A, KELLER E, GRUNWALD D. Jobber: automating inter-tenant trust in the cloud[J/OL].http://www.usenix.org/node/174570, 2013.

[14] WU R, ZHANG X, AHN G J. Design and implementation of access control as a service for iaas cloud[J]. SCIENCE, 2013, 2(3): 115-130.

[15] 劉川意, 林杰, 唐博. 面向云計算模式的運行環境可信性動態驗證機制[J]. 軟件學報, 2014, 25(3): 662-674.

LIU C Y, LIN J, TANG B. Dynamic trustworthiness verification mechanism for trusted cloud execution environment[J]. Journal of Software, 2014, 25(3): 662-674.

[16] LI X Y, ZHOU L T, SHI Y. A trusted computing environment model in cloud architecture[C]//Machine Learning and Cybernetics (ICMLC), 2010 International Conference. IEEE, c2010:2843-2848.

[17] ZHANG F, CHEN J, CHEN H. CloudVisor: retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization[C]// The Twenty-Third ACM Symposium on Operating Systems Principles. ACM, c2011:203-216.

[18] SANTOS N, GUMMADI K P, RODRIGUES R. Towards trusted cloud computing[C]//The 2009 Conference on Hot Topics in Cloud Computing. c2009:3.

[19] SANTOS N, RODRIGUES R, GUMMADI K P. Policy-sealed data: a new abstraction for building trusted cloud services[C]//USENIX Security Symposium. c2012:175-188.

[20] 王麗娜, 任正偉, 董永峰. 云存儲中基于可信平臺模塊的密鑰使用次數管理方法[J]. 計算機研究與發展, 2013, 50(8): 1628-1636.

WANG L N, REN Z W, DONG Y F. A management approach to key-used times based on trusted platform module in cloud storage[J]. Journal of Computer Research and Development, 2013, 50(8): 1628- 1636.

[21] 田俊峰, 吳志杰. 一種可信的云存儲控制模型[J]. 小型微型計算機系統, 2013, 34(4): 789-795.

TIAN J F, WU Z J. Trusted control model of cloud storage[J]. Journal of Chinese Computer Systems, 2013, 34(4): 789-795.

[22] 張煥國, 陳璐, 張立強. 可信網絡連接研究[J]. 計算機學報, 2010, 33(4): 706-717.

ZHANG H G, CHEN L, ZHANG L Q. Research on trusted network connection[J]. Chinese Journal of Computers, 2010, 33(4): 706-717.

[23] WANG J, ZHAO B, ZHANG H. POSTER: an E2E trusted cloud infrastructure[C]//The 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, c2014:1517-1519.

[24] 周振吉, 吳禮發, 洪征. 云計算環境下的虛擬機可信度量模型[J]. 東南大學學報(自然科學版), 2014, 44(1): 45-50.

ZHOU Z J, WU L F, HONG Z. Trustworthiness measurement model of virtual machine for cloud computing[J]. Journal of Southeast University (Natural Science Edition), 2014, 44(1):45-50.

[25] SZYDLO M. Merkle tree traversal in log space and time[C]//Advances in Cryptology-EUROCRYPT 2004. Springer Berlin Heidelberg, c2004:541-554.

Trusted cloud platform management model based on TPM alliance

TIAN Jun-feng, CHANG Fang-shu

(Institute of Network Technology, Hebei University, Baoding 071002, China)

On the basis of trusted computing technology, trusted cloud platform architecture and management model based on the TPM alliance was proposed to solve the performance bottleneck of dynamic management of trusted nodes in the building process of trusted cloud platform. Macro TPM was proposed to solve the capability limitation of TPM, the concept of time-based tree was introduced to organize TPM alliance, addressing the problem of high time cost of nodes management in trusted cloud. It used TPM and authentication encryption technology to solve the trusted transmission problem of data among nodes in TPM alliance, and a management strategy of time-based tree TPM alliance was proposed, including node configuration protocol, node registration protocol, node logout protocol, node state real-time monitor protocol, trusted nodes management network repair protocol, node update protocol. That explains the production algorithm of time-based tree, analyses the effectiveness of the time cost of building trusted node management network and monitoring of node state. The simulation result indicates that the model is efficient, and the time cost in trusted node management can be reduced.

TPM alliance, cloud computing, trusted cloud platform, time-based tree

TP393

A

10.11959/j.issn.1000-436x.2016025

2015-03-18；

2015-06-23

國家自然科學基金資助項目（No.61170254）；河北省自然科學基金資助項目（No.F2014201165）；河北省高等學校科學技術研究重點基金資助項目（No.ZH2015088）

The National Natural Science Foundation of China (No.61170254), The Natural Science Foundation of Hebei Province (No.F2014201165), The University of Hebei Province Science and Technology Research Program (No.ZH2015088)

田俊峰（1965-），男，河北保定人，博士，河北大學教授、博士生導師，主要研究方向為信息安全、分布式計算、網絡技術、可信計算、云計算。

常方舒（1989-），男，河北邯鄲人，河北大學碩士生，主要研究方向為可信計算和云計算。