web環境下的TNC

馬亞蕾

(陜西職業技術學院，陜西西安 710100)

0 前言

TNC是由于網絡訪問控制出現的一種技術。傳統的網絡訪問控制系統主要集中關注認證機制，也就是說，阻止未授權的設備連接到局域網內。但是，他們不能避免可疑狀態下的網絡設備接入網絡的可能性。網絡設備不在當前的安全狀態，比如，沒有安全更新，沒有適當的病毒預防措施，或者個人防火墻軟件，可能威脅服務器的安全和其他連接到同一個網絡的工作站。

但是，TNC受限于局域網和個人虛擬網絡場景。也就是說，TNC規范和實施只允許TNC被用于使用網絡鏈接等級協議的受控環境下。基于WEB的應用是TNC感興趣的新領域，因為TNC被廣泛使用并經常牽涉安全敏感信息的處理。

本文中，我們提出了一個基于web環境下的TNC協議棧。

1 TNC概述

TNC架構已經被設計地對廠商和技術不偏不倚。這個架構，就如在[1]中詳述的一樣，包含以下三個實體。

訪問請求者是一個客戶端，比如一個PC或者一個筆記本，試圖訪問網絡。它的完整性狀態被度量并報告給策略決策點。策略決策點是決定是否允許AR訪問網絡的實體。這些決策是基于描述一個客戶端必須滿足的完整性要求的策略。策略執行點（PEP）是負責執行PDP做出的決定，比如交換機。

評估階段從AR想要訪問受保護的資源（比如網絡）開始。在這個階段，完整性度量是集中在AR上的，通過完整性收集者和TNC客戶端的積累。TNC用基于XML形式概括度量結果并發送到PDP（策略決策點）的TNC服務器。這些基于XML的消息，在PDP上的TNCC和TNCS之間進行交換。

每一個AR的IMC在PDP上有一個相對應的部件，叫做完整性度量驗證者(IMV).TNCS把度量信息傳遞到相關的IMV，對度量信息和網絡訪問策略進行比較。這個策略陳述了客戶端想要訪問網絡必須滿足的最低安全需求。在IMV可以把一個AR的安全狀態和一個策略進行比較之前，它可能必須進一步請求來自于IMC的度量，因此要求幾個回合。

2 自適應的體系結構

原始的TNC模型，正如在前一部分介紹的那樣，不能直接用在基于web環境的用例。這是因為（a）沒有集中的策略執行點（比如一個交換機）來處理所有的訪問請求，(b)并非只訪問一個實體，一個用戶可能代表性的訪問多個服務器（比如在線銀行，電子商務和電子政務網站）。由于這個不同的環境，對基于TNC的體系結構應用了以下擴展要求。

可信驗證者。一個TNC完整性校驗顯示了PC機上的軟件安裝和執行的詳細信息。一個惡意驗證者可以使用這個信息通過瞄準這些軟件產品的已知漏洞來實施攻擊。眾所周知,比如一個系統沒有應用最新的操作系統補丁，可能給一個攻擊者提供了攻擊的機會，在基于web的場景中，潛在的服務提供方（包括惡意方）可以請求完整性校驗，因此避免用戶被一個惡意驗證者執行完整性校驗的影響是很重要的。

隱私憂慮。如上述，關于PC的詳細信息在完整性校驗過程中揭露。在未受控制的網絡中，比如互聯網，用戶代表性的和多方相互配合，可能不想給他們公開完整性信息。因此融合隱私保護機制到任何一個方案里是很重要的。

可用性和用戶經驗。不像在企業環境里，IT服務員工對于基于互聯網服務的用戶是不可見的。因此保持TNC完整性校驗過程簡單和對用戶透明是非常必要的。

原來的TNC體系結構必須適應并滿足以上要求。盡管它不可能完全滿足每一個要求，必須找到可行的折中方法。

下面提出了適應TNC的三個可能的模型。

2.1 直接證明

直接證明模型，基于文獻[2]，它牽涉兩個實體：一個客戶端（c）和一個服務提供者(sp)。除了提供服務（比如在線銀行服務），SP也執行了完整性校驗。在授權訪問服務之前，SP要求校驗C的TNC完整性。

這個模型可能引發了隱私憂慮，因為所有的完整性信息發送給SP，SP可以把它們和用戶的身份連接。更重要的是，為了能夠熟練地做出關于用戶PC安全狀態的決定，必須記錄不同版本的安全相關軟件和他們的更新。這是一個復雜的任務，因為每天會發現很多漏洞[4]。讓服務提供商管理他們的用戶的安全漏洞和更新，這不屬于一個典型的業務范圍，所以這種方法有嚴重的實際局限性。

2.2 轉達認證

在中繼證明模型中，第三方實體存在：驗證服務提供者（VSP）。從一個用戶的角度來看，這個模型和前一個模型是一樣的。SP擔當一個透明的客戶代理；TNC通過SP轉發VSP和客戶端之間的消息。然而，這種方法會影響性能優化并且SP有可能成為瓶頸，因為所有的消息在轉發之前必須被解密和重新加密。

2.3 基于斷言認證

基于斷言認證模型，和轉達認證很相似。但是，不需要通過SP轉達通信，VSP和客戶端直接通信。這個模型的基礎理念就是SP以一種高水平策略報表的形式陳述它的安全需求。客戶端選擇一個VSP并發送策略需求到這個VSP。VSP執行完整性校驗并決定客戶端是否符合規定的策略。這個決定隨后被發送給SP。因為SP和VSP之間的通信是通過客戶端轉達的，所以需要提供機制來保護這些消息的完整性（避免客戶端設備編造一個對自己有利的決定）。

3 IF-T上基于web的TNC完整性校驗

我們提出了一個體系結構和標準消息形式執行基于TNC的完整性校驗。然而，傳輸機制也必須能夠交換TNC相關數據。在這一部分，IF—T上的一個可能的傳輸機制得到認可。在描述這個方法前，首先說明IF—T的總體要求。

圖 1 TNC架構示意圖

3.1 條件

幾個應用程序工件必須在消息交換中參與的三方之間進行傳遞，如在前一部分描述的那樣：一個在VSP上，用戶認證SAML斷言，描述可信VSPs需求的策略，一個包含TNC完整性要求的策略文件。這些必須在實質校驗執行前被發送。在度量過程中，基于XML的TNC消息被交換。最后，用戶收到作為完整性校驗結果的SAML斷言，繼而SAML斷言被傳遞給SP。

3.2 在HTTP上傳輸XML

需要在VSP和客戶端之間傳送的所有應用程序工件，比如SAML斷言，策略描述，和TNC消息交換，都是基于XML的。在HTTP上發送XML數據的最常見的方式是使用SOAP。除了其他約束，SOAP定義了一個消息格式來傳送XML有效載荷連同HTTP的頭部信息。為了用SOAP交換消息，需要定義一個XML消息格式。使用已有的可提供擴展可能性的標準，而不是為TNC定義一個固定的格式。在下面的部分簡要介紹的WS-可信[3]，提供這個標準格式。

3.3 WS-可信概述

WS-可信是提供WSS擴展的OASIS標準。除了XML加密和XML簽名功能，WSS提供了一個基于認證機制的安全令牌。WS-可信 定義了發布和交換這個安全令牌的機制。

WSS認證提供了包括安全令牌在一個SOAP請求的頭元素里。安全令牌種類的例子包含用戶令牌和SAML斷言。在SOAP請求被處理之前，附加的安全令牌生效。因而斷定，WSS認證和其他認證系統工作方式是一樣的，在一個請求被處理前證實用戶的身份和授權。

4 結論與展望

本文中，我們提出了四種實現一個基于web的TNC校驗的構建部分。這種架構提供對客戶端的隱私保護并限制SP的實施復雜性。使用安全令牌來封裝TNC結果允許TNC作為基于web應用的認證過程的一個方面被實施。

[1]. Trusted Computing Group, TCG Trusted Network Connect TNC Architecture for Interoperability –Specification Version 1.2, 2007.

[2]. S. Yoshihama, T. Ebringer, M. Nakamura, S.Munetoh, H. Maruyama, WS-Attestation： efficient and fine-grained remote attestation on web services, in：ICWS’05： Proceedings of the IEEE International Conference on Web Services,IEEE Computer Society, 2005, pp. 743–750.

[3]. A. Nadalin, M. Goodner, M. Gudgin, A. Barbir, H.Granqvist, WS-Trust 1.3,March 2007.