APM：適用于IaaS平臺的agent保護機制

樊佩茹，趙波，倪明濤，陳治宏

（武漢大學國家網絡安全學院空天信息安全與可信計算教育部重點實驗室，湖北 武漢430072）

1 引言

IaaS（infrastructure as a service）平臺為用戶提供高度集中、可動態擴展的計算存儲資源，是支撐云平臺上層服務PaaS（platform as a service）和SaaS（software as a service）的基礎。用戶通過按需租用降低業務部署與管理成本，但該云服務模式中用戶喪失了對存儲和運行在云端數據及應用的物理可見性與可控性，需要依賴IaaS平臺提供商（IPP,IaaS platform provider）部署安全防護措施[1]。然而，為避免遭到針對性攻擊，IPP提供商一般不愿意公開IaaS節點的具體配置與安全信息，導致用戶對平臺缺乏信任，這已成為近年來云計算發展過程中遇到的一大阻礙。

對IaaS平臺做測試，衡量其能否達到用戶的性能或可信性需求，是增強用戶對平臺信心的一種有效方法。業界對IaaS平臺的需求進行了一些研究和探討，也有服務等級協議SLA等用于定義平臺質量或性能指標，但由于目前缺乏綜合統一的云測試或評估標準[2,3]，在對 IaaS平臺信任或可信性的理解上仍然存有分歧[4,5]。文獻[6]在綜合考慮可用性、可靠性與安全性等多項屬性的基礎上，給出一種云平臺可信性的定義，認為云平臺的各項可信屬性均是在其提供服務過程中不同組件動態執行的表現。因此，對IaaS平臺執行可信性測試任務時，可分解為對該平臺各項可信屬性的測試。應用基于可信第三方 TTP（trusted third party）的云測試模型[7～10]到IaaS平臺中時，在IaaS平臺上收集數據的測試代理程序（agent）由TTP與IPP聯合部署。在整個測試過程中，IaaS平臺為支撐上層PaaS或SaaS服務運行的用戶虛擬機將正常工作，該測試過程對用戶虛擬機而言是透明的。針對這種IaaS平臺測試環境，考慮 agent運行在 IaaS節點虛擬化軟件棧層的場景，agent負責從節點上收集可反映測試指標的測試數據并傳輸到TTP做進一步分析。在這個測試過程中，agent自身的可信性是產生真實有效測試數據的基礎，直接關系到 IaaS平臺測評結果的正確性。現有工作主要關注如何從IaaS平臺獲取測試數據和如何基于平臺各項指標的測試數據給出綜合評估，并已有部分成果[11]，但總體來看，在IaaS平臺上部署測試代理程序agent時仍存在以下問題和挑戰。

1) 在IaaS節點上執行測試任務的agent缺乏有效的保護機制。這就導致agent在不可信運行狀態下產生的錯誤或虛假測試數據仍能被 TTP接受，IaaS平臺最終的測試評估結果將受到干擾，使TTP無法對 IaaS平臺存在的問題采取及時的應對措施以止損，也無法為用戶提供公平公正的選擇依據。

2) 現有虛擬化環境中的軟件保護技術無法直接應用到IaaS平臺的agent保護場景中。IaaS平臺支持著上層PaaS和SaaS的用戶服務，在上線運行后其可用性與可靠性是IPP非常重視的要素，但當前虛擬化環境中的軟件保護技術需要被保護軟件所在主機提供額外的硬件或軟件支持，這將大幅增加建立IaaS平臺測試環境的成本，在實際生產環境中并不容易實現。

實際上，考慮到agent將運行在不受TTP控制的IaaS節點上，IPP可能不得不假設一個強攻擊模型，即僅信任IaaS平臺的一小部分，并希望該平臺中被信任的部分越小越好。之前的研究表明，僅僅假設一個抗篡改的 CPU芯片可信是合理的[12]，因此，在該假設下，本文提出一種適用于IaaS平臺的測試代理保護機制。結合IaaS平臺的特點，首先，給出實現agent保護時應達到的設計目標，明確其包括的具體內容，以明確本文的技術依據；然后，設計一個 agent內核態保護模塊（APKM，agent protection kernel module），作為在IaaS節點上實施agent完整性與命令正確性驗證組件的宿主，對agent進行保護，并制作可信性狀態報告作為TTP判斷 agent可信性的依據，APKM自身的完整性由現代x86計算機架構可形成的內存鎖機制提供保護，不需要TTP提供額外硬件或軟件組件的支持；最后，設計一種基于質詢的 APM 有效性驗證方法，可及時發現失效APM所在的IaaS節點以止損，盡可能減少不可信 agent產生錯誤虛假數據混淆TTP分析判斷的可能，提高IaaS平臺測試結果的可靠性。

本文的貢獻在于提出了適用于現有 IaaS平臺的測試代理agent保護技術，在兼顧平臺可用性和可靠性需求的基礎上，不需要TTP與IaaS平臺提供額外軟硬件組件支持即可達到保護agent可信性的目標，解決了IaaS平臺中不可信agent產生錯誤虛假數據干擾測試評估結果的問題。

2 相關工作

業界及相關機構在云平臺測試方面開展了部分研究工作，King 等[7]針對云服務開發測試腳本，對云平臺的自動化自檢測試進行研究。Zech等[8]將風險分析結果與安全測試相結合，提出一種基于模型驅動的云環境安全測試方法。Khan等[9]設計部署一個基于可信第三方的完整性驗證端TIV，驗證云平臺中物理節點的可信性。Pham 等[10]提出了一個軟件測試框架CloudVal，驗證云平臺虛擬化環境的可信性。謝亞龍等[13]分析了云取證技術所面臨的挑戰，并提出一種IaaS云模型下的取證框架ICFF。此外，也有一些項目組研究云平臺可信屬性的測試與認證。ASSERT4SOA項目[14]針對面向服務的分布式應用程序提供新工具和技術，可評估、認證它們的安全屬性。CUMMULUS項目[15]擴展了ASSERT4SOA的工作，為云平臺安全認證提供一個包含可信第三方的新框架，以在云用戶、云平臺提供商、云服務提供商和認證機構的合作下確保云平臺中各項安全屬性認證結果的有效性。CloudSec項目[16]提出一個包含云平臺提供商安全需求的校驗表，并根據該校驗表對云平臺各項安全屬性進行審計。但上述云平臺可信性認證或測試方案中，重點關注了如何獲取反映云平臺可信性狀態的測試數據和對云平臺計算出合理的可信性評估結果，這些研究為進一步增強用戶對云平臺提供了理論指導和現實基礎，但對如何保護 agent的可信性討論較少。

在基于TTP的IaaS平臺測試環境中，agent本質上是由TTP與IPP聯合部署在IaaS節點虛擬化軟件棧層（hypervisor）的測試軟件。目前，針對該類軟件的保護方法可分為2類。1) 硬件輔助實現軟件保護。文獻[17,18]基于可信硬件 TPM 保護軟件的可信性。文獻[19]基于TPCM設計了針對云平臺的可信證據收集方案。TapCon[20]提出一種基于可信第三方的云服務可信性驗證方法，利用 SGX技術保證軟件的可信執行。Royan[21]提出一種分布式沙箱，使運行在 SGX中的應用程序不會遭受來自云平臺的攻擊。將這類硬件輔助實現的軟件保護技術應用于agent可信性保護時，需要IPP為接受測試的IaaS節點提供額外的可信硬件，并需要TTP對agent進行相應修改以適應該硬件，這會同時增加建立IaaS平臺測試環境時IPP與TTP的部署成本，在實際生產環境中并不容易實現。2) 基于可信虛擬化軟件棧提供保護。文獻[22,23]通過修改hypervisor軟件代碼設計程序隔離方案，保證agent代碼的完整性。HyperSafe[24]針對hypervisor控制流完整性提出全生命周期的自保護方案，但該方案需要修改hypervisor代碼并重啟主機，會對云平臺服務造成經濟損失。HyperCheck[25]和 HyperSentry[26]通過驗證完整性實時保證hypervisor不被篡改，防范rootkit等攻擊，但該類方案利用了 SMM 機制，而 SMM機制自身存在局限性，需在操作時凍結所有 CPU核，會為IaaS平臺帶來巨大的性能損耗。可信啟動[27]能夠保證hypervisor啟動時的安全性，但無法解決hypervisor運行時的安全問題。文獻[28]為安全敏感型應用提供了一個安全執行環境 APPSec，根據應用程序的意圖保護用戶的私有數據和人機交互數據，但它需要一個特定隔離專用操作系統的支持。CQSTR[29]針對 IaaS平臺上的虛擬機集群提出一種可運行服務的云容器，以利于TTP判斷運行在該容器中服務的安全性。對第2類技術，考慮到當前虛擬化軟件棧隨著功能的增強，其代碼量越來越大，要對硬件資源進行管理和分配，也有與虛擬機進行頻繁交互，擁有著巨大的攻擊面，且虛擬化軟件棧自身存著在許多已知或未知的漏洞，在被攻擊者利用時，該類保護技術就會失效。因此，當構建基于TTP的IaaS平臺測試環境時，現有技術無法直接應用到agent的可信性保護中。

3 Agent保護機制

基于TTP的IaaS平臺測試環境中，運行在IaaS節點虛擬化軟件棧層的agent面臨著極大的安全威脅。攻擊者可以借助受控虛擬機發起逃逸攻擊，獲取物理節點虛擬化軟件棧的控制權限，進而篡改測試代理程序agent并偽造測試數據以欺騙TTP，隱瞞該節點已遭到破壞的事實。因此，本文假設一種強攻擊模型，攻擊者可以利用IaaS平臺虛擬化軟件棧的漏洞或虛擬機的錯誤配置嘗試寫入物理節點內存的任意位置，但為了成功發起一次攻擊，攻擊者不得不注入惡意代碼或錯誤利用已有代碼，如ROP或 JOP攻擊[30]。注意本文威脅模型不考慮側信道攻擊，如緩存側信道、時間側信道或內存總線側信道等，因為當前該類攻擊在IaaS平臺的復雜計算環境下實現極其困難[31]；也不考慮對IaaS節點擁有物理權限而采取的攻擊，如 BIOS木馬[32]或冷啟動攻擊[33]等，因為在實際運營時，IPP不會分配這種具備所有權限的管理員，并會采取嚴格的訪問控制策略保護平臺物理設備[34]。考慮到攻擊發生在基于TTP的IaaS平臺測試環境中，攻擊的隱蔽性是攻擊者考慮的第一要素，攻擊者最希望達成的目標是，控制IaaS節點，破壞agent并篡改測試數據，欺騙TTP為一個已經遭到破壞的平臺給出正常的測試評估結果，而在整個過程中，TTP與IPP均無法察覺到該攻擊。因此，本文不考慮攻擊者采用拒絕服務等容易被檢測到的手段進行破壞的情況。

在基于TTP的IaaS平臺測試中，考慮到以上攻擊模型時，所提agent可信性保護機制APM應滿足以下4個設計目標。

1) 支持agent的完整性保護。支持在agent啟動時和運行過程中的完整性驗證，在發現agent完整性被破壞時及時通知TTP與IPP采取應對措施。

2) 確保agent執行命令的正確性。在agent運行過程中能驗證其執行命令的正確性，只有通過正確性驗證的命令才會被執行。

3) 支持agent的更新與擴展。APM應在不依賴其他任何特殊軟硬件支持的情況下達到保護 agent可信性的目的，同時最小化對節點虛擬化軟件棧的修改，并最小化對平臺運行的影響。對IaaS平臺做測試時，一般采用多個指標進行評估，且出于對軟件可維護性的考慮，部署到節點上的agent可能要進行不定時更新，因此，需要保證APM支持agent的更新與擴展。

4) 支持APM的有效性驗證。TTP與IPP應能在任意時刻發起質詢并驗證APM的有效性以及時發現APM被破壞的情形，并采取應對措施。

3.1 體系結構

將基于TTP的云測試模型應用到IaaS平臺測試時，APM通過在IaaS節點內核空間增加一個APKM為其提供保護，具體APM的結構如圖1所示。

圖1中實線箭頭表示傳統基于TTP的IaaS平臺測試執行流程①～③。Agent從測試對象集合收集測試數據并發送到TTP，TTP對測試數據進行綜合分析給出評估結果，其中，測試對象是IaaS節點上影響平臺指標的資源。由于本文重點不在于研究如何從被測對象上獲取反映指標的測試數據，所以這里不對測試對象集合及測試指標做詳細討論。

圖1 APM結構示意

圖1 中點線箭頭表示引入本文APM后新增的執行流程①～④。利用APKM對agent實施保護，APKM自身的完整性由x86計算機架構可形成的內存鎖機制提供保護，內存鎖機制的有效性依賴于IaaS節點控制寄存器CR0中寫保護位WP狀態的正確性，然后以WP的置位正確性為起點，將信任關系擴展到 APKM，再到 agent，從而保證從節點上獲取測試數據的可信性。由于部署在節點上負責具體測試任務的agent會根據被測指標的不同而變化，保存在APKM中與agent相關的預存數據也需要隨之進行更新，這就要求存在一種APKM數據的動態更新機制④，使其支持 agent的更新與擴展。圖 1只展示了一個IaaS節點上的APM結構，實際在構建IaaS平臺測試環境時，TTP與IPP每個IaaS節點上都將部署APM。APKM驗證agent的完整性和執行命令的正確性后，將該驗證結果記錄到 agent可信性狀態報告中；TTP與IPP也將周期性地或在任意時刻發起對節點控制寄存器CR0中WP置位狀態的質詢，獲得WP狀態質詢結果。該質詢結果和agent可信性狀態報告都將作為TTP判斷測試數據可信性的依據。

接下來，分別對APM架構中涉及的關鍵方法進行做進一步描述。

3.2 APKM完整性保護方法

內核態模塊APKM 的完整性依賴于現代 Intel x86架構可形成的內存鎖機制[35]提供保護，關鍵在于實現APKM的正確初始化，本文假設TTP與IPP在IaaS節點上聯合加載APKM時，其初始環境可信，一切攻擊都發生在APKM加載完成后的任意時刻。APKM被載入IaaS節點內核內存空間后，首先標記 APKM 代碼與靜態數據所在的內存頁面為只讀的寫保護屬性，標記APKM內存頁的頁表項所在頁表頁為只讀的寫保護屬性，然后打開IaaS節點控制寄存器CR0中的寫保護位WP（將WP位置1），此時，完成了APKM的初始化工作，基于內存鎖機制的APKM保護技術開始生效。在此后的任意運行時刻，只要WP位保持打開狀態，任何對APKM代碼與靜態數據的寫操作都將遭到拒絕，這就保護了APKM的完整性不會被破壞。

APKM 負責度量和校驗 agent啟動時與運行時的完整性，它必然擁有預先記錄的 agent在可信環境中啟動與運行時的完整性度量結果作為基準值。但根據IaaS平臺測試指標的不同，負責具體測試任務的 agent時常面臨升級或變更情形，這就要求同時對APKM中agent的基準值進行更新；此外，隨著時間的推移，TTP也可能存在升級 APKM 的需求。但受到內存鎖機制保護的APKM 將拒絕任何對其受保護內存頁面的寫操作，無論這個寫操作是正常請求還是惡意篡改，也無論發起該操作的是普通用戶或是系統管理員，這就為APKM的正常更新造成困難。本文采用原子更新操作解決該問題，當修改APKM中的代碼與數據時，先短暫將 WP位置 0，待完成寫操作后，將 WP重新置 1，同時確保這整個更新操作是原子性的（不可被中斷），以避免攻擊者通過對該更新操作發起攻擊使 WP位永久置 0，導致APM失效。由于APKM代碼與靜態數據所在的內存頁被設置為只讀的寫保護屬性，任何對該頁面的寫操作都將引發頁錯誤中斷，因此，將APKM的原子更新操作寫在頁錯誤中斷函數內，同時將該函數所在內存頁也設置寫保護屬性。

根據上述解決思路，提出APKM初始化方法，實現部署APM的第一步，一旦完成APKM的初始化后，所有對APKM的操作都將被納入到內存鎖機制的保護范疇，攻擊者無法通過攻擊APKM破壞APM機制，因而解決了APKM的完整性保護問題。為更好地描述APKM完整性保護方法，使用符號表達其中涉及的操作，如表 1、算法 1和算法2所示。

表1 符號釋義1

算法1 APKM的初始化

1) 加載APKM模塊到系統內核空間

2) LOCK[PT(APKM)]

3) LOCK[M(APKM)]

4) LOCK[M(Update)]

5) 置WP位為1

6) 啟動APKM模塊使其正常工作

算法2 APKM的原子更新

1) 發送更新APKM模塊中的數據的命令

2) 觸發頁錯誤處理函數

3) 調用更新函數 M(Update)

4) 置WP位為0

5) 將數據寫入 APKM模塊

6) 置WP位為1，重啟APKM模塊

算法2的步驟4)～步驟6)是對APKM的寫保護操作，該過程被寫入到修改APKM內存頁時會觸發的頁錯誤中斷函數中去，并被設置為不可中斷，以此防止任何針對該更新操作的攻擊。

3.3 Agent完整性與命令正確性驗證方法

TTP與IPP在IaaS節點上聯合部署APM時，只要完成了APKM的正確初始化且保證WP位的置1狀態，APKM的代碼與靜態數據就無法被隨意修改，它自身的完整性得到了保護，因此，以APKM為信任基礎，對agent實施保護是可行的。TCG組織[5]在可信規范中通過實體的完整性判斷其可信性，但采用完整性度量僅能保證agent的完整性不被篡改，無法阻止agent執行錯誤命令，為解決這個問題，本文還采用執行命令的正確性驗證方法校驗agent行為的正確性，只有正確的命令將被允許執行，錯誤的命令將被拒絕。由于agent一般由TTP與IPP協商設計或選擇，很容易獲得它們在可信環境中啟動與運行時的完整性度量值和命令正確執行時的上下文數據，這些將被事先計算獲得并作為靜態數據保存在APKM中，作為之后驗證時調用的基準值。

對agent的完整性驗證采用APKM主動發起周期性度量和響應TTP與IPP的完整性度量請求2種方式，將計算獲得的完整性度量值與事先保存的完整性基準值作比對，相同則表示agent未受到破壞，不同則表示agent已遭到篡改，記錄該異常信息到agent的可信性狀態報告中，并及時通知TTP與IPP采取進一步應對措施；對agent的命令正確性驗證采用檢查agent執行命令時上下文數據（包括寄存器值、調用該命令的函數地址和該命令調用的函數地址等）的正確與否來完成，首先，提取agent在可信環境執行某一命令時的上下文數據；然后，當agent在IaaS節點上執行該命令時，讀取運行時IaaS節點的該類數據，并與事先保存的基準值作比對，相同則表示該命令正確，允許執行，不同則表示該次執行將被拒絕，這就確保了agent無法執行除預定義正確命令之外的非法行為，保證了它運行時的正確性。

APKM驗證了agent的完整性和命令正確性后，將驗證結果記錄到agent可信性狀態報告中并匯報給TTP與IPP，使二者可以及時了解agent的可信性狀態。agent可信性報告中包含 APKM 對 agent的驗證信息，包括驗證類型（完整性或命令正確性驗證）、驗證發起者（APKM或相應TTP與IPP的驗證請求）、驗證起止時刻、驗證對象信息、驗證結果等。

根據以上解決思路，提出agent完整性和命令正確性驗證方法，防止遭到破壞的agent生成虛假測試數據混淆TTP對IaaS節點的測試結果，攻擊者也無法通過操縱agent代碼執行非法命令來為自己謀得好處，因而實現了基于APKM對agent的保護。為更好地描述agent完整性和命令正確性驗證方法，使用符號表達其中涉及的操作，如表 2、算法3和算法4所示。

表2 符號釋義2

算法3 Agent的完整性驗證

1) 從TTP上下載agent程序

2) 計算agent靜態度量值StaticM(agent)

3) if (StaticM(agent)==StaticM-base)agent完好，跳轉步驟4)

else agent被破壞，跳轉步驟9)

4) 安裝agent到節點

5) 啟動agent并運行

6) 經過時間周期T或收到來自TTP/IIP的度量請求后，對agent進行動態度量

7) 計算agent運行時度量值 DynamicM(agent)

8) if (DynamicM(agent)=Dynamic-base)agent完好，跳轉步驟5)

else agent被破壞，跳轉步驟9)

9) 記錄agent異常狀態到Tlog中，警示 TTP和IIP

算法4 Agent的命令正確性驗證

1) agent處于正常運行狀態

2) 發送執行命令到agent

3) 提取該時刻agent環境數據Env(command)

4) if (Env(command) ==Env-base)命令正常，跳轉步驟1)

else命令異常，跳轉步驟6)

5) 正常執行該命令后，跳轉步驟1)

6) 記錄該異常命令到Tlog，警示TTP和IIP

本文采用agent完整性與命令正確性驗證方法保護agent，實際上，當對agent施加保護時，還可以考慮采用其他軟件靜態或動態度量技術[36～39]等，TTP與IPP可根據具體應用場景在APM中添加更適合實際情況的agent可信性保護技術。

3.4 APM有效性驗證方法

APM的有效性和保護APKM完整性的內存鎖機制的正確性直接相關，只有當IaaS節點控制寄存器CR0中的WP置1時，APM才能正確生效。在基于TTP的IaaS平臺測試環境中，部署APM后，APKM可以確保攻擊者無法在TTP與IPP毫無察覺的情況下破壞agent，也無法利用agent對IaaS節點造成進一步破壞，但若攻擊者利用IaaS節點虛擬化軟件棧中的其他漏洞提取到ring0，將WP置0后破壞 APKM，APM 也無能為力。實際上，在這種攻擊場景中，一旦APM失效，即可認為該IaaS節點已不再可信，因為系統中如果已經存在有非TTP與IPP的用戶發送特權指令改變了CR0中WP的置位狀態，那么可以推斷出該系統中一定已經存在有攻擊者獲得了執行該敏感特權指令的權限。

根據以上描述，本文提出一種基于質詢的APM有效性驗證方法，由TTP與IPP對APM所在IaaS節點發起周期性和隨機時刻的質詢，以獲得該節點上CR0中WP的置位狀態；TTP也分析從上個質詢時刻起到當前質詢時刻之間時段內TTP與IPP所發送指令對WP置位狀態的影響，將質詢結果與分析結果進行對比，若一致，則認為APM當前正常生效；否則，認為該節點上WP已發生異常反轉，已存在有獲得了系統控制特權的未知用戶，因此，有理由認為該節點已經受損，該異常情況將被及時匯報給TTP與IPP，以采取進一步應對措施。為更好地描述APM有效性驗證方法，使用符號表達該技術中涉及的操作，如表3和算法5所示。

表3 符號釋義3

算法5 APM的有效性驗證

1) APM機制正常運行時，在時刻Time(current)發起一次WP位狀態查詢

2) 讀取 WPbit的當前狀態

3) TTP分析從上次運行時刻Time(last) 到當前時刻 Time(current)的所有命令，給出正確的WP置位狀態分析結果WPanalysis

4) if (WPbit=WPanalysis)

APM運行完好，跳轉步驟1)

else

系統中存在有未知用戶執行特權指令，該節點有很大概率已經被破壞，跳轉步驟5)

5) 記錄該異常命令到Tlog，警示TTP和IIP

通過TTP和IPP發起的基于質詢的APM有效性驗證方法，能及時發現失效APM所在節點并止損，盡量減少不可信agent產生錯誤虛假數據混淆TTP分析判斷的可能性，可有效提高IaaS平臺測試結果的準確性。

4 安全性分析

Bell-LaPadula模型[40]（BLP模型）是一種計算機安全模型，形式化定義了系統、系統狀態及狀態間的轉換規則，可以證明一個安全系統，經過一系列規則轉換后，仍是安全的。本文利用BLP模型對APM機制進行建模，分析其安全性。APM機制中涉及的元素有：主體、客體、訪問屬性、權限、請求、決定和系統狀態，具體含義描述如下。

1) 主體集S= {s1,s2}，其中，s1表示TTP或IIP，s2表示潛在攻擊者。

2) 客體集O={o1,o2}，其中，o1表示APKM，o2表示用于執行具體測試任務的應用軟件。

3) 訪問屬性集A={r,w,e}，其中，r表示可讀，w表示可寫，e表示可執行。

4) 權限集F= {f1,f2}，其中，f1是主體權限函數，f1(s)越大，s的訪問權限越高，f2是客體權限函數，f2(o)越大，o越不容易被訪問。

5) 請求元素集RA={c,d}，

由c(change,create),d(delete)組成，表示主體對客體可以執行的操作請求。

6) 決定集D= {yes,no,error}，表示APM機制對主體對客體所發起的一個操作請求的判斷結果。

7) 系統狀態集V= {v|v=(b,f)}=P(S×O×A×F)，由所有狀態v=(b,f)組成，其中，b?(S× O ×A) ,f∈F。

8) 狀態轉移關系表示為W?R×D×V×V，一個系統由狀態轉移關系及初始狀態v0決定，其中，W表示主體對客體發起的一個操作請求被APM機制接受后系統安全狀態的變化， v0表示APM機制中系統的初始狀態，即APKM進行正確初始化后對M(APKM),PT(APKM)和M(Update)加鎖，且WP位置1的狀態。

根據BLP模型，得知APM機制滿足以下定義。

定義1 由狀態轉移關系W及初始狀態 v0決定的系統是指集合

定義3 稱(s,o,x)∈ S×O×A 滿足相對于F的安全性條件，當且僅當x =r 或x =w 且 f1(s)≥f2(o)時，稱(s,o,x)滿足 s c| F，否則，稱(s,o,x)不滿足 s c| F。

定義4 當狀態 v=(b,F)為安全狀態時，等價于所有的(s,o,x)∈b都滿足sc| F。

根據以上定義，可證明APM機制中存在以下3個定理。

定理1 APKM的完整性保護。當且僅當下列條件成立時，內核態模塊 APKM 的完整性得到保護，任何主體對APKM的操作請求都將被拒絕。條件1) 系統正確初始化為 v0狀態；條件2) WP=1。

證明 由條件1)可知，M(APKM),PT(APKM),M(Update)已加鎖，系統在該初始狀態下是安全的。

定理2 Agent的完整性和命令執行正確性保護。當且僅當定理1成立時，agent的完整性和命令正確性得到保護，任何主體對agent的操作請求都將被拒絕。

定理3 APM的有效性驗證。當且僅當下列條件成立時，APM機制是有效的。條件1) 系統正確初始化為 v0狀態；條件2) WPbit=WPanalysis。

證明 由條件1)可知，M(APKM),PT(APKM),M(Update)已加鎖，系統在該初始狀態下是安全的。

記當前質詢時刻為t，上一個質詢時刻為 t -1，WPbit是 s1對IaaS節點控制寄存器CR0中WP實際置位狀態的質詢結果，表示為 vt= (bt,F)；WPanalysis是TTP分析 s1操作指令后得到的WP安全置位狀態，表示為當條件 2)成立時，有 vt*= vt-1，根據定義 4知，狀態 vt為安全狀態，所有的(s,o1,x)∈b都滿足sc| F，決策結果是yes，因此，在以上條件下，APM機制是正確生效的，即定理3成立，證畢。

經過以上安全性分析，證明本文提出的APM機制可有效保證基于TTP的IaaS平臺中agent的完整性和命令執行的正確性，解決其完整性被破壞及代碼被攻擊者濫用執行非法操作的問題，達成了第3節提出的設計目標 1)和目標 2)；APM 機制還支持在 agent升級或更換時基準值的動態更新，支持對多種測試軟件的保護，達成了設計目標3)；此外，提出的APM有效性驗證方法可以及時發現APM失效的問題并通知TTP與IPP，防止TTP在評估IaaS平臺性能時受到偽造測試數據的混淆，達成了設計目標4)。

5 實現與評價

5.1 實驗環境

基于KVM技術模擬搭建單節點和多節點2類IaaS平臺對本文方法的有效性和性能進行評價，具體實驗場景中涉及的軟硬件配置信息如表4所示。

采用Linux系統中流行的分析軟件Tripwire作為agent對IaaS平臺中部分文件進行完整性測試，生成的測試報告作為對應數據完整性指標的測試數據。實現一個自定義的 APKM 模塊，用于驗證Tripwire的完整性和命令執行的正確性，采用SHA-1算法計算Tripwire的散列值作為其完整性度量值，通過檢查Tripwire運行時內存中的關鍵數據驗證其命令執行的正確性。為簡化實驗環境，在實驗過程中關閉系統中的地址隨機化ASLR功能進行分析。

表4 軟硬件配置信息

5.2 實驗和結果分析

本節從功能和性能這2個方面對IaaS平臺上的agent保護機制APM進行測試，功能測試用于驗證APM的有效性；性能測試用于評估APM引入的開銷。

5.2.1 有效性實驗及分析

設計2個對Tripwire軟件的攻擊實驗驗證agent保護機制的有效性，模擬實現IaaS節點控制寄存器CR0中WP位的不同攻擊場景并給出APM有效性質詢方法的表現。

1) Tripwire篡改

攻擊者通過篡改Tripwire的代碼達到偽造度量報告的目的。本文利用軟件010Editor修改Tripwire的二進制文件，將偏移地址 0x00262628-0026263C處的警告數據“No Errors”修改為錯誤提示數據“22 Errors”，使Tripwire無法將檢測結果正確記錄到度量報告中，以欺騙TTP與IPP。

計算正確 Tripwire二進制文件的散列值為orgin_hash = dd89b440818b374fb4d9d944f5adc3979 e5dafc1，篡改后 Tripwire二進制文件的散列值為new_hash = 8e3633b36ed5072998e3912917a8a72105 89f00c，二者存在明顯差異，可以看出，對該程序進行手動修改實現模擬攻擊后，APKM可以通過完整性驗證方法檢測到該攻擊。

2) Tripwire命令異常

攻擊者通過修改Tripwire運行時函數返回地址中的數據達到扭曲程序正常執行流程的目的。Tripwire執行文件完整性度量命令check時觀察發現，被調用 cIntegrityCheck 類函數 CompareFCOs返回地址中保存的數據一直以十六進制顯示為0x3800，因此，通過修改該數據模擬攻擊。

修改Tripwire編譯文件的源代碼，使之在執行Tripwire-check命令時能打印出CompareFCOs返回地址中所保存的數據。編寫腳本循環執行以上命令時，修改該數據模擬攻擊，可以看出攻擊前后該地址的輸出數據有明顯改變。因此，將該地址數據作為命令執行正確性檢測的環境數據之一時，可以檢測到該軟件命令異常執行的問題。這里對該地址數據的修改只是一個示例，實際應用時可增加環境數據的種類。

3) APM有效性質詢

APM 機制中，APKM 的完整性受到內存鎖機制的保護，已有學者驗證了該方案的有效性[20]，因此，本文沒有討論APKM遭受攻擊的情形。這里考慮APM部署完畢后，IPP不再向IaaS節點發送任何可能改變WP置位狀態操作指令的場景。這時，只要WP位的狀態是1，就認為APM機制是正確生效的；一旦檢測到WP位被置0，就認為該節點上已存在有非IPP用戶執行了ring0級特權指令，內存鎖機制已失效，APM機制已不再可信，需及時向TTP與IPP示警。

實驗通過對一個標志位狀態的變更模擬攻擊者對IaaS節點控制寄存器CR0的WP位進行的操作，研究APM失效檢測機制中不同質詢周期Tinquire對不同攻擊周期Tattack及不同攻擊延續時長Tadelay的檢測率，記一次攻擊為標志位初始狀態為 1（表示APM機制正確生效），經過Tattack時間后攻擊者發起延續時長為Tadelay的攻擊，此時，標志位被置0（表示APM 機制處于失效狀態），攻擊結束后，該標志位被再次置 1。在該攻擊發生時間內，TTP以Tinquire為周期查詢該標志位的置位狀態，以檢測是否發生了攻擊。攻擊檢測率是成功檢測到的攻擊次數對攻擊總次數的百分比值。具體APM失效檢測結果如表5所示，時間的單位是s。

分析可知，基于周期性質詢的APM失效檢測方法的有效性與Tattack、Tadelay及Tinquire密切相關。以上檢測中存在發生了攻擊但未被檢測到的情況，這是由于攻擊延續時長較短，整個攻擊流程發生在2次質詢之間，因此，無法發現該攻擊。基于隨機時刻的質詢可在一定程度上提高該方法的檢測率，它可用于對周期性質詢結果的補充。

表5 APM失效檢測結果

5.2.2 性能實驗及分析

本節通過計算開啟 APM 機制后執行 Tripwire命令增加的時延分析APM引入的性能開銷。完整性度量時延是指APKM對agent進行完整性度量時引入的時間開銷，命令執行時延是指 APKM 檢驗Tripwire函數返回地址中數據的正確性時引入的時間開銷。

1) 完整性度量時延

取5個Tripwire命令包括策略更新（twadmin）、數據庫初始化（init）、完整性檢查（check）、版本查詢（version）和主程序測試（test）進行實驗，為提高時間測量結果的精確性和科學性，每個命令重復執行1 000次，取1 000次執行結果的平均值，單位為μs。計算開啟APM機制前后的完整性度量時延比值，定義該比值為具體實驗數據記錄在表6中，時間單位為μs。

將表6中3個節點對5個測試命令的時延開銷數值表示為圖2。

從表6和圖2中可以看出，開啟APM后命令執行時間比原始執行時間有所增加，其完整性度量時延最大增幅為1.613 5‰（在C1上執行命令test），最小增幅為0.344%（在C3上執行命令twadmin）。分析APM機制可知，在命令執行過程中增加時延的主要操作在于計算Tripwire二進制文件的完整性度量值及與 APKM 中預保存基準值的對比。考慮到開啟APM機制前后命令執行時間的差值很小，在本文實驗環境中最大相差時間在100 μs以下，因此，對用戶實際使用造成的影響是很微小的。

表6 完整性度量時延

圖2 完整性度量時延開銷

2) 命令執行時延

取Tripwire執行文件完整性度量check命令時調用的 cIntegrityCheck 類中函數 Execute、CompareFCOs、ProcessDir和 ProcessChangedFCO進行實驗，分別將之記為 func1、func2、func3和func4，觀察發現，func1與 func2返回地址中保存有固定數據，而func3與func4返回地址中保存有相等數據，根據該規律，討論執行一個命令時檢查不同數目函數引入的時延開銷。為提高時間測量結果的精確性和科學性，每個命令重復執行1 000次，取1 000次執行結果的平均值，單位為μs。具體實驗數據記錄在表7中，并用圖3表示該數據。

從表7和圖3可以看出，開啟APM后執行命令時間有所增加。分析可知，增加耗時的主要操作為APKM讀取Tripwire運行時內存數據及與其預存正確數值的比對工作。雖然開啟APM后對命令的執行引入了一定時延，且該時延隨 APM 所檢查Tripwire命令中函數數目的增加而增加，但該開銷在μs級，而命令執行時間在s級，考慮到對IaaS平臺測試環境中agent安全性的增加，該時間開銷在可接受范圍內。在實際部署agent時，需精心選擇命令中需接受檢查的函數，以在agent的安全性與性能之間取得平衡。

表7 命令執行時延

6 結束語

基于TTP的IaaS平臺測試主要依賴代理程序agent收集測試數據，但當前對agent保護技術的研究較少，現有虛擬化環境中的軟件保護技術也無法直接應用到該場景中。針對這些問題，本文提出一種適用于IaaS平臺的測試代理agent保護機制APM，結合平臺特點，首先提出實現APM應達到的設計目標，給出本文的技術依據；然后解決在現有條件下TTP與IPP不提供額外硬件或軟件組件支持時保護agent需解決的問題，設計一個內核態保護模塊APKM，作為保護IaaS節點agent工作組件的宿主，實現對agent完整性與命令執行正確性的驗證和保護，并生成 agent可信性狀態報告作為 TTP判斷agent可信狀態的依據；最后為解決APM失效問題，設計一種基于質詢的 APM 有效性驗證方法，及時發現失效APM所在的IaaS節點以止損，盡可能減少不可信 agent產生錯誤虛假數據混淆 TTP分析判斷的可能，提高 IaaS平臺測試結果的準確性。通過實驗研究與分析，APM可以有效保證agent的完整性和命令執行的正確性，時間開銷保持在μs數量級，對系統的負擔影響很小，與APM對agent的安全性提升而言，這個代價是可接受的。

圖3 命令執行時延開銷

參考文獻：

[1]RIDDLE A R,CHUNG S M. A survey on the security of hypervisors in cloud computing[C]//International Conference on Distributed Computing Systems Workshops. 2015:100-104.

[2]SHAHZAD F. State-of-the-art survey on cloud computing security challenges,approaches and solutions[J]. Procedia Computer Science,2014,37:357-362.

[3]SARAVANAKUMAR C,ARUN C. Survey on interoperability,security,trust,privacy standardization of cloud computing[C]// International Conference on Contemporary Computing and Informatics.2015:977-982.

[4]Common Criteria Project Sponsoring Organizations. Common criteria for information technology security evaluation: Version 2.1[S]. 2004.

[5]Trusted Computing Platform Alliance. Main specification: Version 1.1[S]. 2002.

[6]趙波,戴忠華,向騻,等. 一種云平臺可信性分析模型建立方法[J].軟件學報,2016,27(6):1349-1365.ZHAO B,DAI Z H,XIANG S,et al. Model constructing method for analyzing the trusty of cloud[J]. Journal of Software,2016,27(6):1349-1365.

[7]KING T M,GANTI A S. Migrating autonomic self-testing to the cloud[C]//2010 Third International Conference on Software Testing,Verification,and Validation Workshops (ICSTW). 2010: 438-443.

[8]ZECH P. Risk-based security testing in cloud computing environments[C]//IEEE International Conference on Software Testing. IEEE Computer Society,2011:411-414.

[9]KHAN I,REHMAN H,ZAHID A. Design and deployment of a trusted eucalyptus cloud[C]// 2011 IEEE International Conference on Cloud Computing (CLOUD). 2011: 380-387.

[10]PHAM C,CHEN D,KALBARCZYK Z,et al. CloudVal: a framework for validation of virtualization environment in cloud Infrastructure[C]//International Conference on Dependable Systems & Networks.2011:189-196.

[11]SHAIKH R,SASIKUMAR M. Trust model for measuring security strength of cloud computing service[J]. Procedia Computer Science,2015,45:380-389.

[12]CARBONE M,CUI W,LU L,et al. Mapping kernel objects to enable systematic integrity checking[C]// ACM Conference on Computer and Communications Security. 2009:555-565.

[13]謝亞龍,丁麗萍,林渝淇,等. ICFF: 一種 IaaS 模式下的云取證框架[J].通信學報,2013,34(5):200-206.XIE Y L,DING,L P,LIN Y Q,et al. ICFF: a cloud forensics framework under the IaaS model[J]. Journal of Communications,2013,34(5): 200-206.

[14]PAZZAGLIA J C,LOTZ V,CERDA V C,et al. Advanced security service certificate for SOA: certified services go digital[M]. Vieweg Teubner,2011.

[15]ARJONA M,HARHANI R,MUNOZ A. An engineering process to address security challenges in cloud computing[C]//ASE Bigdata/ Social Com/Cybersecurity Conference. 2014:1-12.

[16]JAATUN M G,MELAND P H,BERNSMED K,et al. A briefing on cloud security challenges and opportunities[R]. Cloud Security Whitepaper,2013.

[17]MCCUNE J M,LI Y,QU N,et al. TrustVisor: efficient TCB reduction and attestation[C]//Security and Privacy. 2010:143-158.

[18]MUNOZ A,MAFIA A. Software and hardware certification techniques in a combined certification model[C]//11th International Conference on Security and Cryptography (SECRYPT). 2014: 1-6.

[19]WU L,ZHAN J,ZHAO Y,et al. A trusted evidence collection method based on the trusted third party for cloud platform[J]. International Journal of Distributed Sensor Networks,2015,501: 984964.

[20]ZHAI Y,CAO Q,CHASE J,et al. TapCon: practical third-party attestation for the cloud[C]//9th Workshop on Hot Topics in Cloud Computing (HotCloud 17),2017: 1-7.

[21]HUNT T,ZHU Z,XU Y,et al. Ryoan: a distributed sandbox for untrusted computation on secret data[C]//Usenix Conference on Operating Systems Design and Implementation. USENIX Association,2016:533-549.

[22]RILEY R,JIANG X,XU D. Guest-transparent prevention of kernel rootkits with VMM-based memory shadowing[C]//International Symposium on Recent Advances in Intrusion Detection,RAID 2008. 2008: 1-20.

[23]HUA J,SAKURAI K. Barrier: a lightweight hypervisor for protecting kernel integrity via memory isolation[C]//ACM Symposium on Applied Computing. 2012: 1470-1477.

[24]WANG Z,JIANG X. HyperSafe: a lightweight approach to provide lifetime hypervisor control-flow integrity[C]//Security and Privacy.2010:380-395.

[25]ZHANG F,WANG J,SUN K,et al. HyperCheck: a hardware-assisted integrity monitor[J]. IEEE Transactions on Dependable and Secure Computing,2014,11(4): 332-344.

[26]AZAB A M,NING P,WANG Z,et al. HyperSentry: enabling stealthy in-context measurement of hypervisor integrity[C]//ACM Conference on Computer and Communications Security. 2010:38-49.

[27]LIN K J,WANG C Y. Using TPM to improve boot security at BIOS layer[C]//IEEE International Conference on Consumer Electronics.2012:376-377.

[28]REN J,QI Y,DAI Y,et al. AppSec: a safe execution environment for security sensitive applications[C]//ACM Sigplan/Sigops International Conference on Virtual Execution Environments. 2015:187-199.

[29]ZHAI Y,YIN L,CHASE J,et al. CQSTR: securing cross-tenant applications with cloud containers[C]//ACM Symposium on Cloud Computing. 2016:223-236.

[30]HUANG Z,ZHENG T,SHI Y,et al. A dynamic detection method against ROP and JOP[C]//International Conference on Systems and Informatics. 2012:1072-1077.

[31]BRAR N S,DHINDSA K S. Study of virtual side channel attack in cloud computing a review[J]. International Journal of Engineering Development and Research,2015,3(3):1-6.

[32]MCCUNE J M,PARNO B J,PERRIG A,et al. Flicker: An execution infrastructure for TCB minimization[C]//ACM European Conference on Computer Systems. 2008:315-328.

[33]BAUER J,GRUHN M,FREILING F C. Lest we forget: cold-boot attacks on scrambled DDR3 memory[J]. Digital Investigation,2016,16:S65-S74.

[34]劉川意,林杰,唐博. 面向云計算模式運行環境可信性動態驗證機制[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.

[35]WANG Z,JIANG X. HyperSafe: a lightweight approach to provide lifetime hypervisor control-flow integrity[C]//IEEE Symposium on Security and Privacy. 2010:380-395.

[36]劉貴堂,周正,周魯蘋. 軟件行為的一種靜態可信度量模型[J]. 海軍航空工程學院學報,2012,27(4): 459-463.LIU G T,ZHOU Z,ZHOU L P. A static trustworthy measurement model for software behaviors[J]. Journal of Naval Aeronautical and Astronautical University,2012,27(4): 459-463.

[37]SHI W C,ZHOU H W,Y J H,et al. DCFI-Checker: checking kernel dynamic control flow integrity with performance monitoring counter[J]. China Communications,2014,11(9):31-46.

[38]PENG G,PAN X,ZHANG H,et al. Dynamic trustiness authentication framework based on software's behavior integrity[C]//The International Conference for Young Computer Scientists. 2008:2283-2288.

[39]吳濤,楊秋松,賀也平. 基于鄰接點的 VMM 動態完整性度量方法[J]. 通信學報,2015,36(9):169-180.WU T,YANG Q S,HE Y. Method of dynamic integrity measurement for VMM based on adjacency data[J]. Journal of Communications,2015,36(9): 169-180.

[40]TIAN-GE S I,ZHANG Y X,DAI Y Q. L-BLP security model in local area network[J]. Acta Electronica Sinica,2007,35(5): 1005-1008.