防病毒程序、防火墻、合規性管理、安全通信協議和其他方法可提供自上而下的安全性。自上而下的安全性在機器的啟動周期的后期啟動，它主要關注密封系統的外部攻擊面（將壞東西拒之門外并保守秘密）。如果只使用自上而下的安全技術，那么軟件的較低、最關鍵的層通常容易受到攻擊。

TCG 的硬件/固件/軟件方法為可以關閉此漏洞的所有層提供了完整的自下而上的防御。圖 1 顯示了自上而下和自下而上的防御如何結合起來提供“縱深防御”。

圖 1. 傳統的自上而下的安全方法與TCG的自下而上的技術相比。

支持可信計算的固件建立在“可傳遞信任鏈”之上，并使用核心信任根測量 （CRTM） 從引導期間在系統上運行的第一條指令建立系統測量。CRTM 啟動了實現縱深防御和保護所有計算設備（包括聯網傳感器）所必需的自下而上的安全性。

啟動固件、操作系統（包括實時操作系統 （RTOS））和受信任的應用程序將全面的代碼測量放在 TPM 的可編程配置寄存器 （PCR） 中，以構建其可傳遞信任鏈。這些度量值位于 TPM 中，不能被惡意代碼更改，被 TPM 中的函數廣泛使用。

使用 TSS 2.0 作為功能強大且方便的 TPM 軟件服務，以下是使用 TPM PCR 提供的一些主要功能：

通過自身或與其他類型的授權結合使用來授權各種 TPM 操作，以實現多重身份驗證

密封系統機密（密鑰等），以保護它們免受潛在惡意軟件的泄露

系統

安全運行狀況的證明 注意：使用 TPM 的證明允許可靠地檢查系統的代碼度量值。惡意固件無法更改或模擬基于 TPM 的證明，因為它無法看到對用于證明的 PCR 摘要進行簽名所需的 TPM 常駐/機密證明密鑰。

TPM還具有傳統硬件安全模塊（HSM）或智能卡的所有功能。使用 TSS 2.0 與 TPM 2.0 接口的 PKCS#11 軟件提供了傳統上隨這些設備提供的所有功能。這使得許多使用 HSM 和智能卡的應用程序可以輕松移植到具有 TPM 2.0 的系統中。

TPM 2.0 是國際標準化組織 （ISO） 標準。它是構建基于硬件的信任根的國際標準。世界貿易組織（WTO）成員不得對ISO標準化安全設備進行進出口管制。這有利于在全球范圍內運送設備，而不會因為旨在規范TPM和其他硬件安全模塊的貿易壁壘而阻止它們進入市場。它已經或將要被指定為政府，關鍵基礎設施和其他安全合規感知項目（包括帶有傳感器的項目）的提案請求書（RFP）中的必需項目。

交易系統 2.0

TCG 的 TSS 2.0 是用于使用 TPM 的標準應用程序編程接口 （API）。借助 TSS 2.0 的跨平臺支持，用戶可以輕松地跨平臺移動應用程序。

應該注意的是，一些供應商使用術語“TSS”來描述其專有或非標準TPM軟件。在許多情況下，來自政府和具有安全意識的行業的 RFP 要求確實/將專門確定 TCG TSS 2.0 以滿足和 RFP 響應的要求。使用TSS 2.0可以提高這些領域組織增加安全性的信心，因為他們知道它是由TCG開發并由TCG的安全專家審查的。TCG TSS 2.0 規范可在 TCG 網站上找到。

安全程序員還可以通過 TSS 2.0 獲取 TPM 的關鍵服務：

與 TPM 通信時所需的編組/取消編組服務

多個 TPM 應用程序可以不受干擾地使用相同的 TPM

對從軟件到 TPM 的數據流進行加密，從而阻止側信道（硬件探測）攻擊。

注意：這是通用標準 EAL 4+ 認證所必需的，這是許多客戶要求的

簡化使用 TPM 的應用程序所需的上下文和會話管理

TSS 2.0 還提供了：

用于與 TPM 通信的同步和異步函數調用模型

分層軟件模型，允許不同級別的抽象（取決于所使用的 TSS 層），簡化了使用 TPM

的任務 注意：分層軟件模型還為不同的代碼占用提供了可擴展的解決方案，從最小的物聯網 （IoT） 設備（如傳感器節點）到服務器應用程序

TSS 2.0 軟件模型的各層如圖 2 所示。

圖 2.TCG 的 TSS 2.0 的分層架構提供了包括傳感器節點在內的應用靈活性。

TSS 2.0 層執行以下功能：

設備驅動程序管理與 TPM 設備通信的電子總線。TPM 設備驅動程序現已在 Linux 和 Windows 中可用。其他操作系統和 RTOS 可能需要修改或自定義的驅動程序。

選項卡和資源管理器允許多個應用程序和內核共享 TPM 資源。此代碼和設備驅動程序是 TSS 2.0 軟件堆棧中特定于操作系統的兩部分。

TPM 命令傳輸接口 （TCTI） 允許開發程序員以平臺上的硬件 TPM 以外的 TPM（例如，軟 TPM）為目標。這是調試TPM軟件的一個非常方便的功能，并允許實現遠程TPM。

系統 API （SAPI） 是與 TPM 交互的最低級別（最不抽象）方式。它不需要文件系統或堆。它可以與啟動固件集成，也可以用于最小的物聯網設備。

增強型系統 API （ESAPI） 具有更輕松的上下文管理，并提供加密到 TPM 的數據流的能力，從而阻止側信道攻擊（對 EAL4+ 至關重要）。

功能 API （FAPI） 提供了 TSS 1.2 所不具備的新易用性。它允許程序員與 TPM 接口，而無需成為 TPM 專家。

TSS 2.0 API 采用簡潔的編程技術，遵循行業公認的最佳軟件實踐。這允許程序員（包括最初編寫代碼的程序員）返回并使用TSS 2.0輕松閱讀，理解和修改應用程序。當您考慮到您的代碼必須由各種程序員在產品通常很長的生命周期中理解，維護，測試和可能認證時，這是一個非常重要的因素。

TSS 2.0 中的干凈編程技術包括：

無功能過載 – 確保高語義內容

強類型檢查 – 無可變參數（參數數量可變）變量

無全局變量

人類可以理解的有意義的變量名稱和函數名稱

TSS 2.0 API 還提供了強大的代碼版本控制和版本控制。這可確保可以識別每個版本的代碼行為更改的詳細信息。除非版本更改，否則將保持向后代碼兼容性。

其他合規性

TSS 2.0 API 的設計特征包括符合汽車工業軟件可靠性協會 （MISRA）。這對于工業物聯網、汽車和細分市場中的軟件安全合規性至關重要，在這些領域，安全是一個關鍵問題。但是，底層 TSS 2.0 實現可能符合 MISA 標準，也可能不符合 MISA 標準，因此有必要與 TSS 2.0 供應商聯系，以了解 MISRA 合規性是否超出 TSS 2.0 API 擴展到實際的 TSS 實施（注意：板載安全 TSS 2.0 符合 MISRA 標準）。

審核編輯：郭婷