對現代硅的信任是我們大多數人認為理所當然的事情。許多技術用于將安全功能構建到硅片中，包括

向處理器添加安全擴展，例如 ARM 的 TrustZone，以允許它們在安全和非安全模式下運行，

實施旨在通過集成加密密鑰來保護硬件的可信平臺模塊 （TPM），以及結合物理不可克隆功能 （PUF），該功能提供獨特的挑戰-響應機制，具體取決于用于制造片上系統 （SoC） 的硅材料的復雜性和可變性。

所有這些設計原則和原語都是必要的，以確保最終的硅具有適當的工具，用于軟件構建可信計算環境。許多已經實施，國防部 （DoD） 要求所有系統都包含 TPM 。

【圖1 | 一個 SoC 設計團隊在此設計中構建了幾個可信計算元素（圖由 Microsemi 提供）］

這些安全原語和平臺是一個很好的開始。然而，僅僅包含一個安全知識產權 （IP） 塊或原語不足以使系統或芯片安全。由于不同程度的信任和專業知識經常出現一些設計和驗證問題，SoC 設計中仍可能存在安全漏洞。

現代 SoC 由數百個 IP 塊組成，其中許多來自無數不同的供應商。設計團隊應該信任所有人嗎？可能不是。這些塊是否旨在避免所有已知的安全陷阱？當然不。

大多數問題源于具有不同信任級別的 IP 供應商，或者是那些關心功能高于一切的供應商。

問題 1：不同程度的信任

一些 IP 塊很常見，例如標準 USB 控制器。如果它看起來像一個 USB 控制器，那么應該沒有任何問題。但是，當它們從信任級別相對較低的 IP 供應商處購買時，設計團隊怎么能期望它與系統的其余部分表現良好？

其他 IP 塊發揮著極其重要的作用——例如，作為內部開發的加密密鑰管理器。在 SoC 中包含這兩個 IP 塊可能會引入在架構設計期間未考慮的難以捉摸的安全問題。例如，USB 控制器是否可以通過 SoC 互連訪問加密密鑰管理器？希望不會，但許多 SoC 供應商并不知道，因為他們沒有在設計周期的每個階段執行適當的安全驗證。

芯片安全需要通過設計來完成，安全驗證需要在開發的每個階段完成，尤其是當各種 IP 塊集成在一起時。

問題 2：供應商只關心功能

盲目信任第三方 IP 供應商提供的測試向量是構建安全系統的糟糕方法。當 IP 供應商開發他們的測試套件時，他們唯一關心的是功能。他們只努力確保其 IP 塊的邏輯和準確性與功能規范相匹配。

例如，IP 供應商檢查他們的 AES-256 內核是否可以在正確的周期數內正確執行加密。但是，正確執行加密與確保 AES-256 核心沒有安全漏洞（例如將密鑰泄露到任何意外輸出）完全正交。

換句話說，IP 供應商并不努力滿足安全規范。相信 IP 供應商提供的測試向量將測試所有關鍵的安全方面是幼稚的。因此，SoC 設計團隊有責任對所有 IP 塊進行安全驗證，以確保芯片安全。

將 IP 塊集成到 SoC 中的方式可以很容易地影響塊的某些方面，這些方面會違反系統的安全性。假設加密密鑰管理器提供了一個用于存儲密鑰的接口。密鑰管理器的調試狀態可能會讓某人讀出密鑰。如果 IP 供應商提供的測試向量未涵蓋此安全漏洞怎么辦？同樣，SoC 設計團隊有責任對所有 IP 塊執行安全驗證，以確保芯片安全。

安全解決方案設計

如果 SoC 設計團隊通過在從架構討論到流片的整個硬件設計生命周期中識別和驗證硅安全屬性來實施安全設計 （DFS） 方法，則可以避免這些類型的漏洞。這需要在 SoC 的架構設計期間充分定義所需的安全屬性。

接下來，必須在單個 IP 塊級別以及設計中的所有 IP 塊與適當的安全驗證軟件的集成上驗證這些安全屬性。

【圖2 | DFS 方法包括在硬件設計生命周期的每個階段驗證安全性］

概括

每個塊，無論是簡單的還是復雜的，都必須經過安全驗證，以確保系統安全。在不使用 DFS 時，無論設計團隊是否使用 PUF、TPM 和加密處理器等安全原語，上述安全漏洞仍可能存在。

隨著 SoC 設計團隊在其寄存器傳輸級 （RTL） 設計流程中實施 DFS 方法，可以解決和消除從架構到流片的安全漏洞，確保系統完全安全。我們可以回到信任現代硅。

審核編輯：郭婷