NIST SP 800-193中固件安全测试指导意见

NIST SP 800-193是由美国国家标准技术研究所(NIST)发布的一份关于平台固件弹性的指南，这份指南针对平台固件和数据面对潜在破坏性攻击时的弹性提供了技术指导和建议，建议通过保护（Protection）、检测（Detection）和恢复（Recovery），以确保平台固件的完整性，从攻击中快速且安全地恢复。保护机制确保固件代码和关键数据保持完整，并受到未授权更改的保护；检测机制用于发现固件代码和关键数据何时被破坏；恢复机制则用于在检测到破坏或通过授权机制强制恢复时，将固件代码和关键数据恢复到完整状态 。

该指南讨论了关键数据的保护，以及如何通过固件保护、检测和恢复机制来增强平台的安全性。本文主要分享的是第四部分，平台设备固件安全指导意见相关内容。

第 4 章 平台设备固件安全指导意见

本章主要包含三大要素：保护、检测和恢复。4.1 节提供了关于支持这些属性的可信根的基础安全性指导意见。4.2 节提供了关于保护固件代码和关键数据的安全性指导意见。4.3节描述了关于检测针对固件和数据的非授权修改的机制的指导意见。4.4 节具体说明了针对固件和数据恢复机制的安全性指导意见。

4.1 可信根

本节提供了关于用于支持后续的保护、检测和恢复指导意见的可信根（RoT）和信任链（CoT）的基础的指导意见。这些指导意见基于负责每一项安全属性的逻辑组件来组织：

·更新可信根（RTU）负责认证固件更新和关键数据更改以支持平台保护能力

·检测可信根（RTD）负责实现对于固件和关键数据的损坏的检测能力

·恢复可信根（RTRec）负责在检测到损坏时以及在得到管理员指示时恢复固件和关键数据

这些逻辑组件不一定是相互独立的。在很多情况下，可信根将会成为低级平台固件的一部分，并且将会在彼此之间共享很多组件。更进一步地，尽管各个可信根负责那些支持某一给定的弹性属性所必需的功能，在大多数情况下，它不会在其可信根本身内部实现所有这些功能。这些功能中的大多数将会在一条植根于可信根中的信任链中实现。可信根是在信任链当中被内在地信任的组件，并且以某种安全的方式将信任延伸到其他组件。

4.1.1 可信根（RoT）和信任链（CoT）

1）安全机制应该被构建于可信根（RoT）中。

2）如果使用了信任链（CoT），某个可信根需要作为信任链的锚点。

3）所有可信根和信任链需要要么是不可变的，要么由能够保证所有 可信根和信任链保持为某种具有完整性的状态的机制对其进行保护

4）位于非易失性存储器中的更新、检测和恢复信任链中的所有元素需要在平台固件中实现

注释：此指导意见，即可信根和信任链被作为平台固件的一部分而实现，仅适用于那些用于实现此论文中描述的平台弹性功能的元素。我们鼓励平台厂商维持一条始于启动固件、贯穿操作系统的信任链以提供对抗不同形式的攻击的弹性。

5）可信根和信任链的功能需要具有弹性以防止由运行在宿主处理器所运行的操作系统之下，或者作为此操作系统的一部分的软件所试图进行的任何破坏。

6）从宿主处理器上所运行的软件传输到平台固件的信息需要被视为不可信的。

7）可信根可以被延伸到包括不是来自非易失性存储器的元素。在使用之前，这些元素需要由可信根中的早期元素进行密码学验证。

8）跨越设备边界，或者为共生设备提供服务的可信根和信任链需要在设备之间使用某种安全通讯信道。

4.1.2 更新可信根（RTU）和更新信任链（CTU）

1）每一个具有可变固件的平台设备需要依赖更新可信根（RTU）或者植根于 RTU 中的更新信任链（CTU）以认证固件更新。

2）如果可信根或者信任链是可变的，则可信根或者信任链元素需要利用一种认证更新机制来更新，如果没有贯穿于安全本地更新的物理介入。在这样一次更新过程中，RTU 或者 CTU 需要在后续重启时，甚至是如果发生了意外的灾难性事件（例如在闪存写入过程中发生断电）时总是保持可运作或者可恢复。

3）RTU 或者 CTU 需要包含一个密钥存储器，以及一种来自 FIPS 186-4 [7] 的受批准的数字签名算法实现以验证固件更新镜像的数字签名。

4）如果此密钥存储器是可更新的，则此密钥存储器需要利用某种认证更新机制来更新，如果没有贯穿于安全本地更新的无歧义的物理存在。

注释：可更新的密钥存储器提供了一种方式以便从签名密钥的攻击中恢复，但是这可能使得此设备的密钥存储器更易受到破坏。我们鼓励使用不可更新的密钥存储器的实现者设计化解和恢复机制以应对固件签名密钥的潜在泄露的威胁。

5）植根于 RTU 中的认证更新机制需要成为用于更新设备固件的唯一方式，如果没有贯穿于安全本地更新中的无歧义的物理存在。

4.1.3 检测可信根（RTD）和检测信任链（CTD）

1）每一个实现了检测能力的平台设备需要依赖于检测可信根（RTD）或者植根于 RTD 中的检测信任链（CTD）以用于它的检测。

2）RTD 或者 CTD 需要包括或者拥有对于检测固件代码和关键数据损坏的必需信息的访问权限。

3）植根于 RTD 的检测机制需要提供 4.3 节所具体说明的检测能力

注释：此文档提供了关于植根于低级硬件和固件中的检测能力以提供弹性对抗破坏性攻击的最小要求。然而，此文档中的任何内容都不应该被解读为禁止那些位于此信任链以外的其他检测能力。

4.1.4 恢复可信根（RTRec）和恢复信任链（CTRec）

1）每一个实现了恢复能力的平台设备需要依赖于恢复可信根（RTRec）或者植根于 RTRec 中的恢复信任链（CTRec）来执行其恢复过程。

2）RTRec 或者 CTRec 需要执行恢复过程。

注释：RTR 未被选作恢复可信根的首字母缩略词，由于 RTR 通常被用于指代报告可信根。因此，在整篇文档中，我们将会通过使用 RTRec 来指代恢复可信根以消除 RTR 的歧义。

4.2 保护

保护必须被延伸到与受保护的固件相关联的关键数据上来，由于某些此类数据可能成为能够攻击平台完整性的攻击向量。所有提供固件代码和关键数据保护的平台设备必须满足下列要求。

4.2.1 可变代码的保护和更新

本节具体说明了基于认证固件更新、完整性保护和安全更新机制的不可绕过性的原则的固件保护指导意见。认证更新机制利用数字签名来验证固件更新镜像的完整性和合法性。固件完整性保护防止在认证固件更新过程以外对固件进行无意或者恶意的修改。最后一个原则，不可绕过性，保证攻击者没有方式可以绕过保护机制。

4.2.1.1 认证更新机制

植根于 RTU 中的一种或者多种认证更新机制需要成为更新设备固件的唯一方式，如果没有如 3.5.3 节所定义的贯穿于安全本地更新的无歧义的物理存在。认证更新机制需要满足下列认证指导意见：

1）固件更新镜像需要使用如同 FIPS 186-4，数字签名标准 [7] 所具体说明的一种受批准的数字签名算法签名，它具有至少 112 位的安全强度，以符合 SP 800-57，关于密钥管理的建议——第 1 部分：总则 [8] 的要求。

2）每一个固件更新镜像需要由某个授权实体——通常是设备制造商、平台厂商或者可信的第三方——签名以满足 SP 800-89，关于获取用于数字签名应用程序的担保的建议 [9] 的要求。

3）新的或者恢复的固件更新镜像的数字签名需要在非易失性存储器更新过程完成之前由 RTU 或者 CTU 验证。例如，这可以通过验证内存中的更新内容然后执行活动闪存的更新来实现。在另一个范例中，这还可以通过将更新加载至闪存的某个区域，验证它，然后将该闪存区域选定为活动区域来实现。

4.2.1.2 完整性保护

为了防止针对固件的无意或者恶意的修改，包含设备固件的非易失性存储区域需要被保护以防止在授权更新机制以外的这样的修改。

1）包含设备固件的闪存区域需要被保护，以使得它仅可通过认证更新机制或者安全本地更新机制进行修改，后者通过要求一位授权用户物理接触系统本身以指导更新来保证固件更新镜像的合法性和完整性。

注释：为了保证完整性保护不能被绕过，完整性保护要么必须总是被启用，要么必须在执行 CTU 以外的代码之前被启用。硬件完整性机制相对于基于软件或者固件的机制可以提供更高的担保。这些完整性保护机制必须保证固件仅可作为认证更新或者安全本地更新的一部分而被修改。

4.2.1.3 不可绕过性

不可绕过性原则是指攻击者不应该可能在认证更新机制或者，如果受支持，安全本地更新机制以外修改设备固件。任何能够绕过认证更新机制的有意或者无意的机制可能会制造一种漏洞以允许恶意软件利用恶意或者无效的镜像来修改设备固件。这些可能包括允许访问闪存区域的开发或者诊断接口、允许直接内存访问的架构特性，或者允许操控内存的低级漏洞（例如 rowhammer 攻击）。

为了满足不可绕过性原则，这些潜在的漏洞需要被考虑进整体系统设计。这可能包括以下方面的努力：限制设备的攻击面、仔细分析设备和非标准命令集的接口，以及在生产设备中禁用开发和诊断接口。

1）保护机制需要保证认证更新机制从未被绕过。

2）认证更新机制需要能够防止非授权地将设备固件更新至某个早期的合法版本，该早期版本具有某种安全漏洞，或者将会允许更新到某个具有已知安全漏洞的版本。

注释：更新至早期固件版本，有时称为“回滚”，可以提供一种从某个不能正确运作的固件更新中恢复的方式。然而，非授权的回滚可能允许攻击者恢复某个具有漏洞的固件镜像，这随后可能允许攻击者损坏设备或者注入恶意软件。因此，支持回滚的设备应该包含适当的安全控制，以保证它不能被非授权实体在攻击中利用。

4.2.2 不可变代码的保护

代码可以存储于现场不可升级的存储器中，诸如只读存储器（ROM）。尽管此类存储器所带来的保护是强壮的，其代价是不能更新代码以修复 bug 以及为漏洞打补丁。系统和设备制造商应该谨慎地权衡使用现场不可升级的非易失性存储器的利弊。

1）如果使用，现场不可升级的存储器的写保护状态将不会可修改。

4.2.3 关键平台固件的运行时保护

为了满足 4.2.1.3 节所描述的不可绕过性原则，软件或在软件控制下的总线主控硬件不能干扰关键平台固件的预期功能。关键平台固件是满足下列条件的所有平台固件的集合：(a) 执行任何平台固件的保护、检测、恢复和更新功能；(b) 维护关键数据安全；或者 (c) 实现用于关键数据的不可绕过的接口。

主张其符合保护要求的设备，以及依赖关键平台固件以便在操作系统运行时保护固件镜像和/或关键数据的设备，必须满足本小节的指导意见。这些指导意见的目的是建立一种环境，以使得关键平台固件在其中以同软件相隔离（保护）的方式执行。这样的隔离（保护）可以以逻辑方式（例如在基于 x86 的平台中使用系统管理模式，或者在基于 ARM 的平台中使用 TrustZone）或者物理方式（例如在连接到非宿主处理器的内存中，该处理器与宿主处理器以物理或者逻辑方式隔离）来实现。

本小节不必须应用于被归类为非关键的固件（例如，PC 风格平台上的 BIOS 的大部分内容通常是非关键的）。

1）如果非易失性存储器中的关键平台固件代码被复制到内存中执行（为了提升性能或者出于其他原因），那么内存中的固件程序需要被保护以防止其被软件修改，或者需要在软件启动之前完成其功能。

3）如果关键平台固件将内存用于临时数据存储，那么此内存需要被保护以防止运行于平台上的软件的影响，直到该数据的使用完成。

2）软件将不会能够干涉关键平台固件的预期功能，例如通过拒绝执行、修改处理器模式或者污染缓存。

注释：这些指导意见并不排除对于可由具体用于同固件或者设备硬件通讯的软件写入的内存的使用，包括将内存用作更新的暂存区域。这些指导意见的本意是防止对于正在执行的代码或者关键平台固件所使用的隐私状态的非授权修改。

4.2.4 关键数据的保护

针对由设备存储并且使用的关键数据的非授权更改也可能严重影响设备的安全状态。这样的更改可能会修改或者禁用由平台提供的重要安全相关功能，或者完全阻止设备运作。尽管关键数据可能需要能够由操作系统和其他组件修改，本节中的指导意见旨在为这些更改提供一种受控的接口，并且防止那些将会使得设备处于某种无效状态的更改。

1）关键数据需要仅可通过设备本身或者由设备固件提供的限定接口进行修改。限定接口的范例包括由设备固件使用的私有或者公有应用程序接口（API）或者基于标准的接口。共生设备可以依赖它们的宿主设备来满足此要求。

2）关键数据更新需要在提交关键数据更改之前由设备或者共生设备的宿主设备进行验证，以保证新的数据结构良好。验证的范例可能包括范围或者边界检查、格式检查等。

3）关键数据更新需要由平台管理员或者授权固件更新机制的一部分来授权。

4）关键数据更新可以使用机制以先于其使用认证关键数据。

5）设备需要至少以保护其代码的同等程度保护其出厂默认值。此出厂默认值需要能够以和代码相同的方式进行更新。

4.3 检测

本节中的检测指南描述了可在设备执行或消耗设备固件和关键数据之前检测其未经授权更改的机制。当检测到未经授权的更改时，设备可以启动恢复过程，如第4.4节所述。对于固件或关键数据缺乏强有力保护的设备，检测机制尤为重要。然而，这些机制也可以提供一种方法来检测试图实施4.2指南的设备的固件或关键数据保护故障。

所有对其固件代码和关键数据提供损坏检测的设备必须满足下列指导意见。

4.3.1 损坏的代码的检测

在设备上执行非授权或者损坏的固件可能损坏设备、向系统中注入恶意软件，或者以其他方式影响设备或者包含它的系统的安全功能和能力。下列指导意见描述了在启动过程中利用检测可信根（RTD）验证固件完整性的机制，如 4.1.3 节所详细叙述。尽管密码学完整性检查是理想的，不论是由设备自身还是由某个宿主设备进行，某些硬件设备（例如 FPGA 或者 CPLD）可以利用其他机制以检测其代码和可编程逻辑中的损坏。

为了使得检测机制高效，设备的设计需要保证即使发生了针对固件本身的成功攻击，RTD 仍然可信。

1）导致活动关键数据或者固件镜像的损坏，或者破坏其保护机制的成功攻击，就其自身而言将不会自发导致针对 RTD 或者检测固件镜像损坏所必需的信息的成功攻击。

2）下列技术中的一项或者多项需要被用于 RTD 或者 CTD 以验证固件代码：

a) 先于执行 RTD 以外的代码，利用某种受批准的数字签名算法或者密码学散列值对设备固件代码进行完整性验证

注释：完整性验证也可以于运行时进行。这些机制可以植根于 RTD，也可以不植根于 RTD。

b) 共生设备可以依赖宿主设备以执行检测。如果共生设备独立于宿主设备启动，共生设备的固件完整性验证需要在执行宿主 CTD 以外的代码之前进行。在这些情况下，下列额外的要求适用：

·共生设备的固件需要根据 4.2.1 节的要求进行保护。

·宿主设备应该能够立即引发共生设备固件的恢复过程，然后重启该设备，如果检测到损坏。

c) 某些硬件设备（例如 FPGA、CPLD）可能拥有现场可升级的逻辑而非固件代码，通常称为配置比特流。如果这些设备没有支持密码学验证的能力，或者符合 a) 或者 b) 的测定和报告能力，它们需要使用基于硬件的机制以检测设备加载错误。

d) 其他技术（例如看门狗计时器）可以和密码学完整性检查共同使用以检测平台设备初始化过程中的其他问题。

3）如果检测到损坏，RTD 或者 CTD 应该能够启动恢复过程以便将设备固件代码恢复为某个合法版本。

4）检测机制应该能够创建关于损坏的通知。

5）检测机制应该能够在检测到损坏时记录事件日志。

6）检测机制可以能够使用由平台管理员设置的、定义了 RTD/CTD 在上述指导意见中所采取的行动的策略。

4.3.2 关键数据的损坏的检测

本节描述了用于检测平台设备中的无效或者损坏的关键数据的机制。如上文所述，无效的关键数据可以使得设备不可运作或者禁用某些关键安全功能。验证关键数据是具有挑战性的，由于通常情况下，数据的本意是使得用户可配置。本节中的指导意见是建议直接验证关键数据内容或者实现其他机制以查找数据损坏的症状。

1）RTD 或者 CTD 需要先于其使用执行关键数据的完整性检查。完整性检查可以采用诸如针对已知有效值验证数据或者验证数据存储器的散列值等形式。

2）无论作为完整性检查的替代方案（对于不能支持这样的能力的设备）还是作为这些检查之外的额外方案，RTD 或者 CTD 可以使用看门狗计时器以检测关键数据的潜在损坏。

3）如果检测到关键数据的损坏，RTD 或者 CTD 需要能够启动恢复过程以恢复设备的关键数据。

4）检测机制应该能够在检测到损坏时记录事件日志。

5）RTD 或者 CTD 应该能够创建关于损坏的通知。

6）RTD 或者 CTD 可以能够转发关于损坏的通知。

4.4 恢复

本节描述了用于将平台固件和关键数据恢复到某种有效并且合法的状态的机制，如果任何这样的固件或者关键数据被检测为已经发生损坏，或者管理员引发手动恢复过程。

4.4.1 可变代码的恢复

本节中的固件恢复指导意见具体叙述了用于将固件恢复到某个本地存储的备份或者从其他来源下载的恢复镜像的机制。在任何一种情况下，这些指导意见具体说明了先于恢复利用认证更新机制（4.2.1.1 节）验证镜像的完整性和合法性。

1）固件恢复机制需要抵御那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击。

a) RTRec、CTRec 以及合法的恢复固件镜像应该独立于运行的固件被保护。

2）RTRec 或者 CTRec 需要能够获取合法的设备固件镜像。

a) 如果合法的固件镜像本地存储于非易失性存储器中，该镜像需要被保护以防止非授权修改。

3）更新到本地存储的合法固件镜像的过程需要通过认证更新机制（4.2.1.1 节）或者安全本地更新（3.5.3 节）的方式实现。

4）非本地恢复机制需要先于恢复使用认证更新机制（4.2.1.1 节）以验证恢复镜像的完整性和合法性。

5）如果合法固件镜像采用远程存储，恢复策略需要可配置镜像的位置。

6）如果某个设备（共生设备）依赖于另一个平台设备（宿主设备）以提供其 RTRec 或者 CTRec，则宿主设备的 RTRec 或者 CTRec 需要在恢复操作过程中调用宿主/共生认证更新机制。

7）设备需要实现其自身的恢复能力，或者该设备（共生设备）和另一个平台设备（宿主设备）需要共同实现共生设备的恢复能力。

8）恢复机制应该能够在执行恢复时记录并报告事件日志。

9）恢复机制应该能够提供关于恢复事件和行为的通知。

10）恢复机制可以能够执行恢复行为而无需通知或者由用户或者系统管理员介入。

11）恢复机制可以请求来自用户或者系统管理员的批准以执行恢复行为。

12）平台管理员应该能够引发可变代码的恢复。设备应该为平台管理员提供方法以强制恢复。设备可以按照平台层级的授权以通过一个或者多个可信设备的链条强制恢复，这些设备中的首个需要在指示下游设备进行恢复之前验证平台层级的授权。

13）恢复过程应该防止非授权地恢复到某个包含安全漏洞的早期固件版本。整体恢复过程应该辅助恢复到某个最近的固件版本。这些可以被实现为多阶段的恢复过程。

4.4.2 关键数据的恢复

本节描述了用于恢复平台设备中的关键数据的机制，如果该设备或者管理员有理由相信它已经发生损坏。由于关键数据可能是用户可配置的，恢复过程要求关键数据的可信的、已知良好的备份副本的可用性。这些备份副本可以存储于设备本身，或者由某些其他宿主设备存储。由于这些备份也可能易受攻击，这些指导意见具体说明了设备也提供某种方式以恢复到已知良好的出厂默认值这一点。

1）恢复关键数据的机制需要抵抗那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击。

2）设备应该提供某种方式以便将活动关键数据的一份或者多份已知良好的副本备份到一个或者多个其他位置。这些位置的保护需要至少和对于活动关键数据的保护一样好。这些保护应该好于对于活动关键数据的保护。

a) 不能备份其自身的关键数据的共生设备应该使其关键数据对其宿主设备可用。在此情况下，宿主设备需要备份共生设备的数据。

b) 如果共生设备将其关键数据提供给宿主设备以使得宿主设备可以备份该数据，则该共生设备应该能够消费恢复的关键数据。

3）设备可以通过将其关键数据用作成功重启的一部分来确认该数据为“已知良好”的

4）设备可能通过将这些数据作为成功重启的一部分来确定其关键数据是“已知良好”的。

5）RTRec 或者 CTRec 需要能够将关键数据恢复至出厂默认值。

6）RTRec 或者 CTRec 应该能够恢复至上一次已知良好的关键数据。

7）设备将不会利用由该设备作为关键数据储存的策略来恢复其自身的关键数据。然而，共生设备可以依赖由宿主设备提供的策略。

8）如果有多个备份可用，RTRec 或者 CTRec 可以允许选择使用哪个备份。

9）如果自动检测关键数据的损坏，RTRec 或者 CTRec 可以在替换当前关键数据之前获得来自宿主设备或者用户的批准。

10）在没有 RTD 或者 CTD 以触发恢复行为的情况下，平台管理员应该能够引发关键数据的恢复。设备应该为平台管理员提供方式以强制恢复。接收到授权请求以强制恢复的设备可以随后指示与其已经建立信任关系的其他设备进行强制恢复，可以是直接进行或者通过可信设备的链条进行。

尽管定义哪些情况构成了平台需要恢复到的恰当状态（除了具有完整性的状态以外）超出了此文档的范围，范例包括下列任何情况：

·恢复到上一次已知良好的状态

·重置为出厂默认值

·更新至最新固件镜像

·执行部分“修复”操作

·恢复到某个由企业定义的“起始点”

·上述情况的任何组合

请注意，恢复过程可能需要多个阶段才能恢复正常运行。例如，设备在恢复上次已知良好配置数据之前，可能会先恢复出厂默认配置数据。

当考虑如何确定要恢复设备的哪些完整性状态时，使用基于策略的方法需要使用关键数据来存储/维护这些策略。但是，如果关键数据变得损坏，则恢复过程可能无法进行，或者可能以不正确的方式进行。因此，供应商应仔细考虑用于恢复的算法。例如，一个简单的机制可能是使用简单的最近使用(MRU)算法，例如，该算法可能会首先尝试恢复到最后一个已知的良好状态;如果该数据无效，则可能会尝试恢复到以前的保存状态;如果该状态不可用，则可能会尝试从远程企业存储位置恢复;如果该状态不可行，则可能会尝试重置为出厂默认设置。 以这种方式使用算法方法消除了在恢复操作期间依赖关键数据处于完整状态的需要。

以上就是针对NIST SP 800-193中固件安全测试相关内容的分享，如需固件安全自动化检测工具或固件检测实验室建设相关资料，可私信我获取。

（谢绝转载，更多内容可查看我的专栏）