通过集成加密密钥来保护硬件的可信平台模块

对现代硅的信任是我们大多数人认为理所当然的事情。许多技术用于将安全功能构建到硅片中，包括

向处理器添加安全扩展，例如 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 方法，可以解决和消除从架构到流片的安全漏洞，确保系统完全安全。我们可以回到信任现代硅。

审核编辑：郭婷