片上系统设计中的安全策略：规范，实施和验证（2）

第 1 章 SoC 安全策略：实践现状

1.1 概述

我们生活在一个被数十亿个计算系统包围的世界，这些系统识别、跟踪和分析我们的一些私密个人信息，包括健康、睡眠、位置、朋友网络等。这种设备的发展趋势是更加普及，预计到 2020 年将有 75B 台智能互联设备。这些设备生成、处理和交换大量敏感信息和数据（通常统称为“安全资产”或简称为“资产”）。除了私人最终用户信息外，资产还包括在系统架构期间引入的安全关键参数，例如保险丝、密码和 DRM 密钥、固件执行流程、片上调试模式等。对这些资产的恶意访问可能导致设备制造商或内容提供商的公司商业机密泄露、最终用户的身份盗用或隐私泄露，甚至破坏人类生活。

现代计算设备的安全保证是一项具有挑战性的活动。一项关键挑战是设计的绝对复杂性。大多数现代计算系统都是通过片上系统 (SoC) 范例构建的，即通过预先设计的硬件或软件块（称为“知识产权”或“IP”）的组合，这些硬件或软件块通过一个网络进行交互-芯片通讯面料。IP 本身是高度复杂的工件，针对性能、功耗和硅开销进行了优化。增加复杂性的是用于实现复杂系统级用例的通信协议。最后，安全资产散布在整个设计中的不同 IP，并且对资产的访问受复杂安全策略的约束。这些策略由系统架构师以及不同的 IP 和 SoC 集成团队定义，并在整个系统开发过程中进行完善和修改。这使得验证系统、开发架构以提供针对未授权访问的内置弹性或更新安全要求（例如，响应不断变化的情况）变得具有挑战性客户的需求。

本书是关于设计、实施和验证 SoC 安全策略的系统方法。我们在这里提倡的方法是使用一个集中的 IP 块，该块单独负责实施和执行 SoC安全策略。在本书中，我们将看到这样的架构如何促进简化实现、分析和部署实际 SoC 设计的各种安全策略的示例。

本章的目标是设置上下文并为本书的其余部分提供相关背景。我们讨论了必须在现代 SoC 设计中强制执行的各种类型的安全策略，当前的工业策略实践实施，以及实践状态中的差距和局限性。

1.2 安全策略简介

在高层次上，SoC 设计中资产安全需求的定义遵循众所周知的“CIA”范例，该范例是信息安全研究 [26] 的一部分。在此范例中，对安全资产的访问和更新需要满足以下三个要求：

• 机密性：除非获得授权，否则代理无法访问资产。

• 完整性：只有经过授权的代理才能更改资产（例如，可以修改安全存储位置中的数据）。

• 可用性：作为正确系统功能的一部分，代理必须可以访问资产。

当然，将这些高级要求映射到对系统中单个资产的约束并非易事。定义安全策略以实现此目标。它们指定哪个代理可以访问特定资产以及在什么条件下。以下是代表性安全策略的两个示例。请注意，虽然是说明性的，但这些示例是虚构的，并不代表特定公司或系统的安全策略。

示例 1：在启动期间， SoC 中除预期目标之外的任何 IP 都无法观察到加密引擎传输的数据。

示例 2：包含安全密钥的可编程保险丝可以在制造期间更新，但不能在生产后更新。

示例 1 是机密性实例，而示例 2 是完整性实例；然而，这些策略处于较低的抽象级别，因为它们旨在转化为“可操作的”信息，例如架构或设计特征。上述示例虽然是假设性的，但说明了安全策略的一个重要特征：同一代理可能会或可能不会被授权访问（或更新）同一安全资产，具体取决于 (1)执行阶段（即启动或正常） )，或 (2) 设计生命周期的阶段（即制造或生产）。这些因素使安全策略难以实施。加剧这个问题的事实是，通常没有中央安全政策文件；策略文档的范围可以从微体系结构和系统集成文档到架构师、设计师和实施者之间的非正式演示和对话。最后，政策的实施是一种并发性练习，政策的不同组成部分在不同的 IP（硬件、软件或固件）中实施，它们共同协调以确保遵守政策。

1.3 系统级安全策略

不幸的是，现代 SoC 设计中的安全策略本身非常复杂，并且是根据客户要求和产品需求以临时方式开发的。下面，我们提供了安全策略类的分类。它们并不完整，但说明了所采用政策的多样性。

访问控制 这是最常见的一类策略，指定SoC 中的不同代理如何在不同的执行点访问资产。这里，“代理”可以是 SoC 的任何 IP 中的硬件或软件组件。上面的示例 1 和 2 是此类政策的示例。此外，访问控制构成许多其他策略的基础，包括信息流、完整性和安全启动。

安全资产的信息流价值有时可以在没有直接访问的情况下通过间接观察或“窥探”中间计算或 IP 通信来推断。信息流策略限制了这种间接推断。示例信息流策略可能如下所示：

• 密钥遗忘：低安全性IP 无法通过仅从低安全性通信结构上的加密引擎中窥探数据来推断加密密钥。

信息流策略难以分析。它们通常涉及高度复杂的保护机制和正确性的高级数学论证，通常涉及信息安全的困难或复杂性结果。因此，它们仅用于具有非常高机密性要求的关键资产。

Liveness 这些策略确保系统在整个执行过程中不会“停滞”地执行其功能。典型的活性策略是IP 对资源的请求之后是最终响应或授权。偏离这样的策略可能导致系统死锁或活锁，从而损害系统可用性要求。

Time-of-Check vs. Time-of-Use (TOCTOU) 这指的是要求任何访问需要授权的资源的代理确实是已被授权的代理。TOCTOU 要求的一个重要示例是固件更新；该政策要求最终在更新时安装的固件与已被安全或加密引擎验证为合法。

安全启动系统启动需要重要安全资产的通信，例如，熔丝配置、访问控制优先级、加密密钥、固件更新、调试和硅后可观察性信息等。因此，启动对 IP 内部和通信提出了更严格的安全要求比正常执行。引导期间的个别策略可以是访问控制、信息流和 TOCTOU 要求；但是，将它们合并为一组统一的引导策略通常很方便。

请注意，上述政策与 SoC 设计的集成特性相关，与单个 IP 的保真度无关。现在，我们忽略了 IP 的可能性本身可能是不可信的，即，安全策略背后的威胁模型包括通过软件或 SoC 接口进行的外部攻击，但不包括 IP 本身中引入的恶意硬件。这种威胁模型对于主要涉及内部而不是第三方 IP 的 SoC 集成流程是合理的，或者在（正交）保真度检查是否存在恶意后门或特洛伊木马之后集成 IP。我们将在第 4 章考虑不受信任的 IP。

1.4 通信策略

除了系统级策略外，还有管理 IP 架构及其通信要求的“低级”策略。例如，沿 NoC 的通信由结构策略指定。以下是一些明显的结构策略：

消息不变性 如果 IP A 向 IP B 发送消息 m，则 B收到的消息必须恰好是消息 m。

重定向和伪装预防 如果 A 向 B 发送消息 m，则消息必须传递给 B。特别是，（可能是流氓的）IP C 不可能伪装成B，或者消息被重定向到一个不同的 IP D 除了或代替 B。

不可观察性从 A 到 B 的私人消息在传输过程中不能被另一个 IP 访问。

上述政策的描述可能掩盖了实施这些政策所涉及的复杂性。要了解其中的一些微妙之处，请考虑图 1.1 中所示的 SoC 配置。假设 IP IP0 需要向DRAM 发送消息。通常，消息将通过 Router3、Router0、Router1 和 Router2 进行路由。但是，这样的路由允许通过软件重定向消息。具体而言，每个路由器都包含一个基地址寄存器 (BAR)，用于为特定目的地路由消息。但是，建议路径中的路由器之一 Router0 连接到 CPU；此路由器中的 BAR 可能会被潜在的恶意主机操作覆盖系统，从而可以将通过 Router0 的消息重定向到不同的目的地。因此，除非主机操作系统是可信的，否则无法通过 DRAM 通过此路由从 IP0 发送安全消息。请注意，了解重定向在这种情况下的潜力需要了解架构的操作、NoC 内路由器的功能（例如，BAR 的使用）以及软件在敌对角色中的功能。

图 1.1 说明性玩具 SoC 配置。典型的 SoC 设计包括多个具有不同速度和功耗配置文件的片上结构。对于这个玩具配置，我们假设一个包含三个线性连接的路由器的高速结构，以及一个包含两个线性连接的路由器的低速结构

除了上述通用策略外，大多数 SoC 设计通常还包括额外的特定于资产的通信约束。例如，下面列出了与安全启动相关的潜在结构策略。该策略确保在传播到加密引擎进行存储的过程中不会嗅探到由熔丝控制器生成的密钥。

• Boot-time key non-observability（启动时钥匙不可观察性）：在启动过程中，从熔丝控制器到加密引擎的密钥不能通过任何具有用户级输出接口的IP连接到的路由器传输。

1.5 SoC 设计生命周期的安全性

图 1.2 提供了 SoC 设计生命周期的高级概览。当然，生命周期的每个组成部分都涉及大量的设计、开发和验证活动。在这里，我们总结了与安全相关的生命周期中涉及的关键活动。随后的部分将详细说明各个活动。

风险评估 安全需求定义是产品规划的关键部分，与产品架构特性的定义同时发生（并密切协作）。此过程涉及识别系统中的安全资产、它们的所有权和保护要求，统称为定义为安全策略（见下文）。此过程的结果通常是生成一组文档，通常称为产品安全规范(PSS)，它提供了下游架构、设计和验证活动的要求。

安全架构 安全架构的目标是按照 PSS 的规定设计保护系统资产的机制。它包括几个

组成部分，包括（1）识别和分类每个资产的潜在对手；(2) 确定攻击者入口点，也称为威胁建模；(3) 制定保护和缓解策略。该过程可以识别额外的安全策略——通常在比风险评估期间识别的那些级别更低的级别（见下文）——这些策略被添加到 PSS 中。安全定义通常与其他系统特性的架构和设计协同进行，包括速度、电源管理、热特性等，每个组件都可能影响其他组件。

安全验证 安全验证是工业 SoC 设计安全保证中最长和最关键的部分之一，涵盖系统生命周期的架构、设计和后硅组件。当然，在任何阶段验证的实际验证目标和属性取决于该阶段可用的附属品，例如，随着系统开发的成熟，我们分别针对体系结构、设计、实现和硅工件。下面，我们将讨论一些关键的验证活动和相关技术。安全验证的一个关键组成部分是开发技术来破坏系统的广告安全要求，并确定缓解措施。减轻针对架构和早期系统设计的早期验证措施通常包括对安全架构本身的重大改进。在系统生命周期的后期阶段，当架构更改由于产品成熟度不再可行时，缓解措施可以包括软件或固件补丁、产品失效等。

图 1.2 SoC 设计生命周期

1.6 安全架构的要素

鉴于不同类别的潜在对手存在大量复杂的策略和保护要求，我们将如何设计身份验证机制以确保策略执行？不幸的是，今天这一领域的实践状态在很大程度上取决于人类的创造力和观察力。今天的典型方法是开发一个基线架构定义，然后通过以下两个步骤反复完善：

• 使用威胁建模来识别对当前架构定义的潜在威胁（见下文）；

• 使用涵盖已识别威胁的缓解策略改进架构。

基线架构通常源自以前产品的遗留架构，经过调整以考虑为探索中的 SoC 设计定义的策略。特别是，对于每项资产，架构师必须确定 (1) 谁可以访问该资产，(2) 策略允许何种访问，以及 (3) 在系统执行或产品开发生命周期的哪些时间点，此类访问可以批准或拒绝访问请求。由于多种原因，该过程可能非常复杂和乏味。特别是，SoC 设计可能具有大量资产，通常数量级为数千甚至更多。此外，并非所有资产都是静态定义的；许多资产是在系统运行期间在不同的 IP 上创建的执行。例如，保险丝或电子钱包可能具有静态定义的资产，例如密钥配置模式。在系统执行期间，这些模式被传递到加密引擎，加密引擎为不同的 IP 生成加密密钥，并通过系统 NoC 将它们传输到相应的 IP。此过程中的每个参与者在系统执行的不同阶段都有敏感资产（静态或创建的），安全架构必须考虑在任何时候可能在相关对手模型下对这些资产的任何可能访问。

1.7 威胁建模

威胁建模是通过识别目标和漏洞来优化SoC 安全性的活动的名称，然后定义对策以防止或减轻对系统的威胁的影响。如上所述，它是安全架构定义的重要组成部分。它也是安全验证的关键部分，特别是在负面测试和白盒黑客活动中。威胁建模大致包括以下五个步骤，这些步骤不断迭代直至完成：

资产定义 识别管理保护的系统资产。这需要识别 IP 和资产来源的系统执行点。如上所述，这包括静态定义的资产以及在系统执行期间生成的资产。

策略规范 对于每项资产，确定涉及它的策略。请注意，策略可能会“涉及”资产而无需为其指定直接访问控制。例如，策略可以指定特定IP如何访问安全密钥 K。这反过来可能意味着 K 被编程的熔丝控制器如何在引导过程中与其他 IP 通信以进行密钥分发。

攻击面识别 对于每项资产，识别可能破坏资产管理政策的潜在对抗行为。这需要识别、分析和记录每个潜在的“入口点”，即，将与资产相关的数据传输到不受信任区域的任何接口。入口点取决于攻击中考虑的潜在对手的类别，例如，隐蔽通道对手可以利用非功能性设计特征（例如功耗或温度）来推断正在进行的计算。

风险评估 对手破坏安全目标的可能性本身并不能保证采取缓解策略。风险评估和分析是根据所谓的 DREAD 范式定义的，由以下五个部分组成： (a) 损害潜力；(b) 再现性；(c) 可利用性，即对手执行攻击所需的技能和资源；(d) 受影响的系统，例如，攻击是否可以影响单个系统或数千万或数百万；(e) 可发现性。除了攻击本身，还需要分析攻击在现场发生的可能性、对手的动机等。

威胁缓解一旦考虑到攻击的可能性，风险被认为是巨大的，保护机制就会被定义，并且必须在修改后的系统上再次执行分析。

实施示例 考虑通过直接内存访问 (DMA)覆盖代码段来保护系统免受恶意或流氓 IP 的代码注入攻击。此处考虑的资产是内存层次结构的适当区域（包括高速缓存、SRAM 和辅助存储），并且管理策略可用于定义不允许 DMA 访问的 DMA 保护区域。安全架构师需要遍历所有内存访问点系统执行，识别对 DMA 保护区域的内存访问请求，并设置机制使对所有受保护访问的 DMA 请求都将失败。完成此操作后，必须评估增强系统是否存在其他潜在攻击，包括可能利用新设置的保护机制本身的攻击。此类检查通常通过负面测试执行，即超越指定的范围来识别底层安全要求是否可以被破坏。对于我们的 DMA 保护示例，此类测试可能涉及寻找访问受 DMA 保护的内存区域的方法，而不是直接执行DMA 访问。这个过程是迭代的和高度创造性的，从而产生了一个集合越来越复杂的保护机制阵容，直到风险评估认为缓解措施足够为止。

显然，在存在与隐含期望相关的微妙之处、破坏风险/缓解分析的潜在对手以及功能行为和安全约束之间复杂的相互作用的情况下，在系统资产和策略范围内手动执行上述活动是一项艰巨的任务. 不可否认，有许多可用的工具可以帮助不同的步骤，例如，用于记录威胁和严重性识别中识别安全场景的步骤的工具，等等 [46, 67]。尽管如此，关键的架构决策和分析仍然高度依赖于人类的洞察力。

1.8 安全验证概述

将弹性设计到设计中是安全保证的一个方面。另一个关键方面是验证产品的安全目标确实得到满足。在本节中，我们概述了不同的安全验证目标；下一节将讨论所使用的技术。

不幸的是，安全验证的作用不同于大多数其他类型的验证（例如功能或功率性能或时序），因为要求通常不太精确。特别是，安全验证的目标是“验证与系统安全和隐私相关的条件，这些条件是不包括在其他验证活动中。” 考虑到严格的上市时间限制，安全验证侧重于其他验证未涵盖的目标的要求很重要，这排除了相同（或类似）验证任务的重复资源；然而，它让安全验证组织有责任了解在整个 SoC 设计验证范围内执行的活动，并识别与安全相关的漏洞。使问题更加严重的是，大量的安全目标没有明确指定，这使得难以(1) 确定要执行的验证任务，以及 (2)为验证制定明确的覆盖率/成功标准。因此，验证计划包括大量从科学到艺术，有时甚至是“黑魔法”的各种活动。

在高层次上，安全验证活动可以大致分为以下四类：

安全敏感设计特性的功能验证这本质上是功能验证的扩展，但与关键安全特性实现中涉及的设计元素有关。一个例子是加密引擎IP。加密引擎的一个关键功能要求是它为所有模式正确地加密和解密数据。与任何其他设计模块一样，密码引擎也是功能验证的目标。然而，鉴于它是许多安全关键设计功能的关键组成部分，安全验证计划可能会确定加密功能的正确性足够重要，足以证明进一步验证超出了所提供的覆盖范围常规功能验证活动。因此，此类 IP 可能会接受更严格的测试，甚至在某些情况下甚至会进行正式分析。其他此类关键 IP 可能包括涉及安全启动、现场固件修补等的 IP。

确定性安全要求的验证 确定性安全要求是可以直接从安全策略中导出的验证目标。这些目标通常包括访问控制限制、地址转换等。考虑一个访问控制限制，它指定要保护的特定内存范围免受 DMA 访问；这样做可以确保防止代码注入攻击，或保护存储在此类位置的密钥等。一个明显的派生验证目标是确保所有 DMA 调用访问地址转换为地址的内存必须中止受保护范围。请注意，此类属性的验证可能不包含在功能验证，因为对于“正常”测试用例或使用场景，不太可能出现对DMA 保护地址的 DMA 访问请求。

负面测试 负面测试超越了设计的功能规范，以确定安全目标是否可以被破坏或未被指定。继续上面的 DMA 保护示例，否定测试可以扩展确定性安全要求（即，受保护内存范围的 DMA 访问中止）以识别除了 DMA 访问激活的地址转换之外是否还有任何其他路径到受保护内存请求，如果是的话，潜在的输入刺激来激活这些路径。

黑客马拉松 黑客马拉松，也称为白盒黑客攻击，属于安全验证领域的“黑魔法”一端。这个想法是让专家黑客执行以目标为导向的尝试来破坏安全目标。这项活动主要取决于人类的创造力，尽管存在一些关于如何处理它们的指导方针（参见下一节关于渗透测试的讨论）。由于它们的成本和对高水平专业知识的需求，它们被用于攻击复杂的安全目标，通常是在硬件/固件/软件接口或芯片边界。

1.9 总结

从目前的讨论中可以清楚地看出，SoC 安全策略的设计、实施和验证是一项复杂而混乱的活动，涵盖整个系统开发生命周期并协调各种利益相关者的需求和利益。SoC 设计中的安全资产分布在多个 IP 块中。他们的访问限制通常涉及与这些设计模块相关的硬件、固件和/或软件之间微妙而复杂的交互。因此，控制涉及这些安全资产的操作的安全策略通常是复杂和模糊的，这使得 SoC 设计人员难以正确实施他们。使问题恶化的是，很少以任何正式的、可分析的形式指定安全策略。一些策略在不同的体系结构文档中（以自然语言）进行了描述，而许多仍未记录在案。随着设计过程中复杂性的增加，可能需要更多的资源和设计时间（影响上市时间），当前的这种做法会导致以下主要问题：

• 在 Si 后验证和/或现场测试期间验证 SoC 是否符合系统安全要求变得极其困难。在缺乏正式的、有条不紊的方法的情况下，在安全验证期间检测到的漏洞或错误变得越来越难以追溯其来源并加以纠正。这可能需要更多的验证时间和资源，从而导致上市时间增加。间接地，设计或测试/补丁后 SoC 设计中仍然存在漏洞的可能性也会增加。

• 修补/升级 SoC 安全策略非常复杂，这可能是响应现场发现的错误以及动态变化所必需的由于不同的产品/系统使用场景，包括其在全球不同地理细分市场中的采用，安全要求。

• 由于安全策略实施的临时性质，现代 SoC 实施所基于的系统设计重用方法受到阻碍（在安全 SoC 设计的背景下）。这往往会增加设计工作量和复杂性，并导致上市时间增加。

鉴于这些紧迫的问题，迫切需要设计一种系统的方法来设计、实施和验证 SoC 安全策略。在本书的其余部分，我们将开发一种这样的方法，它基于一种新颖的安全架构，该架构基于用于安全策略实施的集中式 IP。

本书中介绍的方法已在现实的政策实施中得到应用，我们在各个章节中记录了一些结果。但是，要谨慎对待结果。安全需求和约束因产品类型、部署目标等而异。因此，安全实施的成本也各不相同，本书中的结果可能无法反映所有情况。尽管如此，我们希望本书中提供的分析仍然有价值，因为它代表了设计人员为了将类似的系统方法应用于他们的目标领域而应该做出的参数和权衡。

1.10 参考文献注释

SoC 安全保障已成为近年来的一个重要研究领域。在该领域的各个子主题上有许多优秀的调查和教程 [ 12、60、74]。安全策略的概念有着悠久的历史，始于1980 年代的几部开创性著作 [24、26、30、62]。最近，随着SoC 设计的日益突出，人们对 SoC 安全性产生了浓厚的研究兴趣。然而，该领域的大多数最新研究都集中在硬件安全上，即保护系统免受恶意硬件木马 [68]、假冒IP 检测 [27] 等。作者最近的一些论文 [57、58、60] 提到了SoC 安全架构和验证中的工业实践方面。