基于TPCM 可信根的可信網絡連接設計與實現*

夏 攀

(北京可信華泰信息技術有限公司，北京100195)

0 引言

新版國家網絡安全等級保護標準《GB/T 22239-2019 信息安全技術 網絡安全等級保護基本要求》《GB/T 25070-2019 信息安全技術 網絡安全等級保護安全設計技術要求》《GB/T 28448-2019 信息安全技術 網絡安全等級保護測評要求》于2019 年12月正式發布并實施，在基本要求中對計算環境安全、物聯網安全、云安全、網絡通信的“可信驗證”要求進行了明確的描述[1-3]。 可信連接作為可信計算的重要組成部分，其設計與實現也成為熱門討論的話題。從事可信計算的各個研究組織或機構都提出了各自的可信計算標準[4-7]，在標準中針對可信連接也提出了不同的要求[8-9]。

可信連接通過驗證訪問網絡的終端完整性，來決定訪問的終端是否能夠接入網絡。參與通信的可信終端將自身的可信狀態傳遞到網絡，保證網絡的可信。

2004 年，TCG 組織最早開始研究制定可信網絡連接相關的架構和標準，制定了可信網絡連接的系統結構——可信連接(Trusted Network Connection，TNC)，實現了與微軟的網絡訪問保護之間的互操作。 TNC架構分為三層(度量層、評估層、訪問層)、三個實體(訪問請求者、策略執行、策略決策)和接口組件，網絡通信的兩端實現了相互的完整性度量、身份驗證和策略判定。 在TCG 的基礎上，我國提出了自己的可信連接架構(Trusted Connection Architecture，TCA)。TCA 基于三元對等架構，解決了TNC 無法主動對網絡請求者進行驗證的問題。TCA 要求網絡的請求者、訪問控制器、策略管理器三者在通信過程中擁有同等的獲取對方身份認證和平臺可信度量的權利[7-8，10]。

在TCA 的模型中有兩個主要問題：

(1)TCA 并沒有明確可信狀態的評估方法及標準；

(2)在TCA 中將可信第三方仲裁機構作為策略管理器，為通信終端提供雙向認證，但是終端和可信第三方仲裁機構之間的身份和狀態認證并沒有明確。

本文的可信連接參照我國自主制定的TCA 標準來設計，在該標準中設計的策略管理器在本方案中將由一個獨立的安全策略管理平臺來實現，該平臺收集各個終端上報的可信狀態報告，根據用戶制定的仲裁規則結合可信狀態報告中的數據來判定終端是否可信。 可信報告由可信根生成，可信根通過硬件形態的可信平臺控制模塊(Trusted Platform Control Module，TPCM)來實現，TPCM 在網絡通信中參與可信狀態報告生成、身份校驗、密碼協商等工作，通過內置的可信密碼模塊(Trusted Cryptography Module，TCM)來標識終端的身份[10-12]，保證交互過程中的數據保密性和安全性。

在可信連接的功能流程設計上，通信雙方在進行通信之前，需要獲取雙方當前的可信狀態報告，通過可信狀態來決定是否允許通信。 可信狀態的判斷和訪問資源的控制，需要通過策略判定機制來實現，策略判定機制可以由多個條件來綜合判定。

在防護功能實現上，對網絡訪問請求的監控和攔截通過Linux 的LSM 機制來實現，只有可信狀態達到策略要求的連接才能建立，數據才能正常發送和接收。

圖1 可信連接總體架構

1 總體架構

如圖1 所示，終端A 作為網絡連接的發起方，終端B 作為被訪問方。通信的雙方在硬件層都配置了TPCM 卡，用于標識身份、密碼運算和啟動度量等功能；在系統層安裝部署了可信軟件基(Trusted Software Base，TSB)，主要完成對用戶行為的攔截、度量、策略管理等功能；安全管理平臺實現了策略管理、存儲、身份認證、策略仲裁等功能[7-8]。

在終端A 與終端B 建立連接之前，兩個終端定時將自己的可信狀態報告上報至安全管理平臺。 安全管理平臺在收到報告后，使用終端的證書(在終端部署的時候導入到管理平臺系統中)進行驗簽，驗簽通過后采集報告中記錄的啟動度量、靜態度量、錯誤日志等信息，再結合策略判定條件對終端的可信狀態進行評估得出可信狀態值，并將其保存在數據庫中。

兩個終端定時向安全管理平臺發出同步其他終端可信狀態信息的請求，安全管理平臺在收到請求后，校驗發送請求的終端是否為合法終端，回復其管理的所有終端的狀態信息。 在返回狀態信息時，管理平臺使用自身的TPCM 中的平臺密鑰對信息進行加密并簽名。終端收到可信狀態信息后，首先對狀態信息進行驗簽，判斷信息的來源合法性，再更新策略庫中保存的終端狀態列表。

終端在建立網絡連接之前，需要根據本地保存的可信終端狀態列表來判斷對端的可信狀態，再決定是否允許建立連接。

可信連接的建立流程如圖2 所示。 終端A 啟動任意一個網絡應用，需要與網絡中的終端B 建立網絡連接。 可信軟件基通過Linux 的LSM 中的網絡鉤子點獲取到此網絡行為，并將網絡IP、端口等信息通知可信認證服務程序，可信認證服務程序判斷終端B 的可信狀態。 如果終端B 的可信狀態滿足條件，則允許連接建立。 終端B 在收到終端A 的網絡連接請求后，也采用相同的機制通過可信認證程序判斷終端A 的可信狀態，如果滿足條件，則允許終端A 接入。

在系統運行過程中，終端A 和終端B 在定時上報自己的可信狀態的同時，也從安全管理平臺更新網絡中所有終端的可信狀態。 當通信雙方中某一方的狀態發生變化時，可以采取應急措施。 應急措施方式有多種，比如：可以聯動Linux 系統中的防火墻機制，來控制終端數據包的發送和接收；也可以通過TSB 在LSM 中的進程鉤子點， 來直接中斷問題程序的運行。

圖2 可信連接流程

2 關鍵部件

2.1 TPCM 可信根

TPCM 是可信計算架構的核心部件，負責對計算節點進行可信度量和防護，并生成日志和可信報告數據。 TPCM 包括可信硬件資源、可信操作系統、內置TCM。

TPCM 硬件資源包括一套專用的邏輯控制CPU、存儲單元、密碼單元、IO 設備以及可能通過外接擴展的TCM 模塊。 通過TPCM 的CPU 提供的隔離、保護和交互機制，可以對TPCM 的硬件資源進行隔離和保護，并實現計算節點和可信節點相互通信。

TPCM 提供啟動信任鏈的構建、可信狀態記錄、可信狀態報告生成、密碼資源的訪問接口等功能。終端的TPCM 定時生成可信狀態報告并通過TCM中的平臺密鑰進行簽名，防止可信報告被偽造。 可信軟件基定期將TPCM 生成的可信狀態報告上報到安全管理平臺，安全管理平臺維護所有終端的可信狀態，并提供查詢服務[13-15]。

2.2 可信軟件基

可信軟件基TSB 由基本信任基、主動監控機制(包括控制機制、度量機制、判斷機制)、可信基準庫、支撐機制組成。

可信基準庫提供可信基準值(包括基準對象和基準內容等信息)存儲、查詢和更新等功能。 基準庫提供實時的基準信息，方便快速查詢，基準信息一般存放在內存中。

TSB 主動監控機制攔截應用的系統調用，在TPCM 支撐下實現對系統調用相關的主體、客體、操作和環境進行主動度量和控制。 TSB 通過支撐機制實現對TPCM 資源的訪問；通過協作機制實現與可信安全管理平臺的策略和審計信息交互，以及與其他計算平臺TSB 之間的可信協作。

TSB 的主動監控機制通過在Linux 的LSM 框架中獲取用戶的網絡行為和其他行為，并通過控制機制、度量機制、判斷機制來決定是否合法[9，13-16]。

2.3 安全管理平臺

可信安全管理平臺統一建設集中化的管理機制，統一完成對各區域、各層面的安全機制的執行與管理。 從系統管理、安全管理和審計管理角度出發，通過對應用系統的計算分析從而建立起集中統一的安全管理機制[15]。

安全管理平臺對所管理區域中的可信狀態進行集中管理，對終端上報的可信狀態報告進行驗簽，保證報告的來源可信，并與各個終端定時同步當前維護的可信狀態。 安全管理平臺提供用戶定制可信狀態的判斷標準，增加判定因素的接口。

3 可信連接技術實現

3.1 功能模塊組成

可信連接的功能模塊由三個部分組成，如圖3所示，分別為安全管理平臺、可信軟件基和TPCM。

安全管理平臺對終端上報的狀態進行集中管理，對終端部署過程中上報來的可信狀態報告進行驗簽。 用戶可以通過用戶交互接口自定義可信狀態的評估策略，對終端上報的狀態進行評分。

終端通過加密信道從安全管理平臺獲取系統內所有其他終端的可信狀態信息，同時將本終端的可信狀態信息上報到安全管理平臺，并定期下載網絡控制策略。 可信軟件基應用態和內核態之間通過Netlink 協議進行數據通信，建立的通信通道可以傳輸策略、日志、可信狀態報告等信息。

當用戶需要訪問網絡時，可信軟件基的內核態系統首先根據策略和目標終端的可信狀態進行評估，不符合條件的拒絕進行通信，反之允許通信。用戶行為的判定同時包含網絡行為的判定。 用戶行為同時也包含其他狀態的判定，如程序運行、文件訪問等。判定結果需要配置到TPCM 中，由TPCM 的平臺配置寄存器(Platform Configuration Register，PCR)來存儲判定的狀態，在生成可信狀態報告后上報到安全管理平臺。

3.2 Linux 終端技術實現

Linux 終端實現可信網絡連接的技術架構如圖4所示，應用程序在運行過程中如果調用了系統的網絡接口，可信軟件基將通過LSM 框架在“文件系統”、“程序執行”、“網絡通信”等位置部署的hook 點獲取到網絡信息。 網絡信息包括源IP、目的IP、源端口、目的端口。 可信軟件基通過目的主機的IP 信息在可信狀態庫中查找其可信狀態，再結合策略來判定是否允許發送或接收數據。

應用程序調用網絡系統的相關接口進行網絡通信時，會調用內核提供的服務sock_recvmsg()和sock_sendmsg()接收和發送數據。 在可信軟件基的內核模塊中，將策略檢查和可信狀態檢查的控制邏輯注冊到LSM 框架對應的網絡調用接口security_socket_sendmsg()和security_socket_recvmsg()上。 策略配置和可信狀態更新可以采用Netlink 協議，將應用層從管理平臺獲取的信息配置到內核中。 為了加快查詢速度，策略管理可以采用hash 表的方式建立緩存。

軟件棧在系統中的體系架構如圖5 所示。

在整個體系中，可信軟件棧是必不可少的系統組件。 為了方便應用軟件和可信軟件基內核能夠使用TPCM 的密碼服務和獲取可信度量的相關信息，必須使用軟件棧作為中間媒介。 軟件棧向上提供應用和內核接口，向下通過硬件驅動來使用TPCM 的計算能力和存儲資源。

圖3 可信連接功能模塊組成

圖4 Linux 終端技術實現架構

3.3 可信狀態報告

可信狀態報告包含啟動信任鏈、靜態度量、動態度量等系統運行狀態的信息，各個部分度量的結果都保存在PCR 中。

啟動信任鏈度量了BIOS、GRUB、Linux kernel、文件系統等信息，度量過程從TPCM 硬件開始，由前一個階段度量后一個階段的內容，形成一個完整的啟動信任鏈，并將結果保存在TPCM 的PCR 中。

靜態度量記錄系統中程序運行、動態庫加載等信息，TPCM 在度量過程中保存度量結果，在生成報告的過程中對度量結果信息進行匯總。

動態度量通過TPCM 主動定期度量程序和內核代碼段在內存中的完整性，在生成報告的過程中對度量結果信息進行匯總。

TPCM 定期讀取PCR 中記錄的各個度量點的度量結果，使用平臺密鑰對度量結果進行簽名發送到安全管理平臺。

可信報告格式定義如下：

圖5 軟件棧架構

可信狀態報告中可以包含多種用戶數據信息，匯總多種安全措施的狀態結果，在安全管理平臺通過自定義的評估策略來判斷終端當前的可信狀態。本方案中除了加入了啟動度量、靜態度量、動態度量，還增加了用戶的非法文件訪問、網絡訪問等信息。

4 實驗驗證

在實驗環境中實現并驗證了本方案的主要功能和流程。 搭建了一個完整的可信網絡系統，如圖6 所示，在這個可信網絡的基礎上實現對FTP、SSH 等網絡應用的控制。

圖6 實驗環境拓撲

該網絡由多臺配置了TPCM 卡的終端組成，選取其中一臺部署安全管理平臺軟件，其他終端部署Linux 可信軟件基。 在各個功能組件部署完畢后，終端可以正常將狀態信息報送到管理平臺，從管理平臺能夠配置相關策略，在終端上實現從管理中心同步其他終端的可信狀態。

通過以下測試用例使終端當前的可信狀態發生變化：

(1)修改grub 配置文件，導致啟動度量的狀態異常。

(2)篡改passwd 文件，使其運行失敗。

(3)強制修改未授權文件，引起非法訪問。

(4)將管理平臺上的終端“不可信”狀態的仲裁條件設置為【啟動度量異常|文件訪問失敗】。

在以上測試用例下，管理中心的仲裁機制判定該終端可信狀態為“不可信”，隨后與該終端建立連接的終端斷連，無法進行通信。

在試驗中破壞終端的grub 配置文件導致啟動度量失敗，效果如圖7 所示。 度量失敗導致可信報告產生異常，如圖8 所示。系統網絡連接出現異常，如圖9 所示。

5 結論

本方案建立了以第三方安全管理平臺作為可信連接仲裁平臺的架構，該架構可以為集中管理的終端安全產品的網絡連接設計提供參考，為等級保護2.0 的實施提供技術基礎。 相對傳統的防御機制，本方案設計實現了信任鏈在網絡中傳遞，降低了某臺設備被攻陷后在網絡內進一步橫向攻擊的可能性。

本方案的可信連接原型設計已在實驗環境中構建完成，方案切實可行、簡單易用，希望可以為相關可信產品的設計和研發提供思路和借鑒。

圖7 啟動信任鏈日志信息

圖8 可信狀態報告

圖9 網絡連接異常狀態

此外，本設計中還存在一些待進一步完善之處，如需要解決在沒有第三方仲裁平臺參與或者離線的情況下，兩臺終端如何點對點建立可信網絡連接。兩個端點之間的可信連接設計也可以考慮使用TPCM提供的TCM 芯片，作為平臺間校驗的信任根。 兩個終端在建立加密連接過程中的密鑰交換過程，可以參考OPENSSH 的密鑰交換機制，將密鑰、隨機數的生成等工作交給TPCM 來完成，通過密碼機制來驗證對方的身份，運行時的狀態檢測可以使用本方案的設計。 在點對點狀態下安全策略的配置，需要考慮配置策略的管理員身份，對管理員身份的鑒別可以采用雙因素身份認證，比如Ukey 身份認證、口令碼等。