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

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

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

所有這些設計原則和原語都是必要的，以確保最終的硅具有適當?shù)墓ぞ撸糜谲浖?gòu)建可信計算環(huán)境。許多已經(jīng)實施，國防部 （DoD） 要求所有系統(tǒng)都包含 TPM 。

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

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

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

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

問題 1：不同程度的信任

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

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

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

問題 2：供應商只關(guān)心功能

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

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

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

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

安全解決方案設計

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

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

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

概括

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

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

審核編輯：郭婷