NIST 特别出版 800-193

平台固件弹性指南

Andrew Regenscheid 著

计算机安全分部，信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.SP.800-193

2018 年五月

美国商务部秘书 Wilbur L. Ross, Jr.

美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan

权力范围

此出版物由 NIST 开发以符合其在 2014 年的美国联邦信息安全现代化法案（FISMA），美国法典第 44 章 3551 节及其下的内容，公法（P.L.）113-283。NIST 负责为联邦信息系统开发信息安全标准和指南，但是这些标准和指南不应该被应用于国家安全系统，如果没有对这些系统行使政策权力的适当的联邦官员的明确许可。此指南同美国行政管理和预算局（OMB）公告 A-130 的要求相一致。

此出版物中的任何内容都不应该被带到由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的相矛盾的标准和指导意见中来。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。

美国国家标准技术研究所特别出版 800-193

Natl. Inst. Stand. Technol. Spec. Publ. 800-193，45 页（2018 年五月）

https://doi.org/10.6028/NIST.SP.800-193

CODEN：NSPUE2

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：sp800-193comments@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

计算机系统技术报告

位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见及其在信息系统安全领域的延伸努力，以及与行业、政府和学术组织之间的合作活动。

摘要

此文档提供了关于支持平台固件和数据对抗潜在地具有破坏性的攻击的弹性的技术指导意见和建议。平台是启动和运行一台系统所需的功能硬件和固件的集合。针对平台固件的成功攻击可以使得系统不可运行，可能是永久的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。此文档中的指导意见通过描述下列安全机制来提升平台的弹性：保护平台防止非授权更改、检测已发生的非授权更改，以及快速和安全地从攻击中恢复。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。

关键字

BIOS；代码签名；固件；Option ROM；平台固件

致谢

来自美国国家标准技术研究所（NIST）的作者 Andrew Regenscheid 想要感谢那些审阅了此文档草案并且为其贡献了技术内容的同事。特别地，NIST 感谢那些帮助指导此作品的来自业界和政府的专家所作出的贡献。这些专家包括来自思科的 Chirag Schroff；来自戴尔的 Mukund Khatri；来自慧与科技的 CJ Coppersmith、Gary Campbell、Shiva Dasari 和 Tom Laffey；来自惠普公司的 Jim Mann；来自 IBM 的 Charles Palmer；来自 Intel 公司的 Bob Hale、David Riss 和 Vincent Zimmer；来自微软的 Paul England 和 Rob Spiger，以及 Shane Steiger。

NIST 还想要感谢来自美国国家安全局的 Kevin Bingham、Cara Steib 和 Mike Boyle，他们为此文档作出了实质性的贡献，以及来自 Noblis NSP 的 Jeffrey Bruke。

受众

此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备制造商。此文档中所包含的安全原则和建议应该能够宽泛地适用于具有可更新的固件的其他类型的系统，包括物联网设备、嵌入式设备和移动设备。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。

商标信息

所有产品名称为其对应公司的注册商标或者商标。

执行摘要

现代计算系统架构可以从层级上进行思考。顶层是软件，由操作系统和应用程序构成。尽管它们提供了用户所使用的大部分功能能力，它们依赖于底层所提供的功能和服务，此文档总体性地称其为平台。平台包括硬件和固件组件，它们是初始化组件、启动系统以及提供由硬件组件实现的运行时服务所必需的。

平台固件及其相关配置数据对于计算系统的可信度至关重要。此固件中的大部分在系统架构中具有高权限，并且由于此固件是系统运行所必需的，维修此固件可能具有挑战性。针对平台固件的成功攻击可以使得系统不可运行，可能是永久性的，或者要求由原始制造商重新编程，造成对用户的重大妨碍。其他高级恶意攻击可能尝试向固件中注入持久的恶意软件、修改关键的低级服务以破坏其运行、窃取数据或者以其他方式影响计算机系统的安全状态。

早期的 NIST 出版物应对了针对一种特定类型的平台固件的攻击的威胁：启动固件，通常称为基本输入/输出系统（BIOS）。然而，平台包含众多其他带有固件和配置数据的设备。这些设备，包括存储和网络控制器、图形处理器，以及服务处理器等，同样是高权限的，并且是系统安全和可靠地运行所必需的。

此文档提供了那些意在支持平台对抗潜在地具有破坏性的攻击的弹性的技术指导意见。这些指导意见基于以下三个原则：

保护：这些机制用于保证平台固件代码和关键数据仍然处于具有完整性的状态，并且被保护以防止损坏，诸如用于保证固件更新的合法性和完整性的过程
检测：用于检测平台固件代码和关键数据于何时受到损坏的机制
恢复：这些机制用于将平台固件代码和关键数据恢复至某种具有完整性的状态，如果任何这样的固件代码或者关键数据被检测到发生损坏，或者如果被迫通过某种授权的机制进行恢复。恢复被限制为恢复固件代码和关键数据的能力。

这些指导意见的本意是应对个人计算机（PC）客户端、服务器和网络设备中的平台，但是它们应该能够宽泛地适用于其他类型的系统。包括原始设备制造商（OEM）和组件/设备提供商在内的实现者可以利用这些指导意见以便在平台中构建更强的安全机制。系统管理员、安全专业人士和用户可以利用此文档以便为未来的系统指导采购策略和优先级。

第 1 章简介

1.1 目的

现代计算和信息技术系统构建于一系列提供系统运行所必需的功能能力的硬件组件之上。众多此类硬件组件拥有驱动其行为的固件和配置数据，并且它们必须维持在某种具有完整性的状态，以使得系统正常运作。此类固件的一个范例通常被称为基本输入/输出系统（BIOS），它被用于辅助硬件初始化过程并且将控制权移交给操作系统。取决于系统，可能有数十或者数百个具有其他类型的可编程固件的微控制器，其固件支持了整体系统架构。这些硬件和固件的集合通常称为平台。

构成了平台的设备对于基于此平台构建的系统的完整性和可用性至关重要。没有这些设备，系统可能不能正确地运行，甚至完全不能运行。针对平台中的某些设备的攻击可以对系统的安全状态造成重大影响，有可能允许低级恶意软件的持久存在。定位于损坏或者移除平台固件的攻击具有使得系统永久损坏的潜力，从而对受其影响的相关方受到实质性的损失。

此文档的目的是为在平台层级支持系统弹性提供安全性指导意见。如同系统工程国际委员会（INCOSE）所定义，系统弹性是指“具有某些特定性质的系统在干扰发生之前、之中和之后吸收此干扰、恢复至某种可接受的性能水平，并且维持该水平达到一段可接受的时间的能力” [10]。应用于信息系统时，网络弹性是指“预见、抵御、恢复并且适应针对包含网络资源的系统的不利条件、压力、攻击或者破坏的能力”。尽管关于系统层级的网络弹性的指导意见在 NIST 特别出版 800-160 草案第 2 卷中有所描述，此出版物指出这种系统层级的弹性应该由计算机平台中的基础安全性能力所支持。此文档中的指导意见支持网络弹性，通过具体说明保护固件和配置数据不受攻击，以及能够检测并且从成功的攻击中恢复的机制。

1.2 受众

此文档本意中的受众包括计算机系统的系统和平台设备厂商，其中包括客户端、服务器和网络设备的制造商。这些技术指导意见假设读者拥有平台架构方面的技能，并且主要面向负责在系统和设备中实现固件级安全技术的开发者和工程师。

这些素材对于开发企业范围内的采购和部署策略可能也会有用。此文档中的素材是面向技术的，并且假设读者对于计算机安全性原理和计算机架构至少拥有基本的理解。此文档提供了背景信息以帮助这些读者理解正在讨论的话题。

1.3 适用性和范围

此文档的目的是提供能够支持主要面对远程攻击的平台弹性的原则和指导意见。这些原则和指导意见直接适用于构成了平台的独立设备（参见 2.1 节以获取一系列范例的列表）。具体地，它们描述了定位于保护每个设备使其固件或者关键数据不被非授权修改以及将平台恢复至某种具有完整性的状态的安全机制。

1.4 文档结构

此文档的剩余部分被组织进下列主要部分中：

第 2 章提供了描述平台组件和架构的信息性素材
第 3 章描述了构成此文档中的指导意见的基础的安全性原则，并且描述了将这些原则应用于平台弹性的关键概念
第 4 章包含关于保护固件代码和关键数据、检测非授权更改以及恢复至某个具有完整性的状态的安全技术指导意见
附录 A 提供了此文档中的首字母缩略词和缩略语
附录 B 呈现了此文档中的选定的术语的词汇表
附录 C 包含此文档中的参考文献列表

第 2 章平台架构

确保平台的固件代码和关键数据总是处于某种具有完整性的状态对于确保一台计算系统可以不受恶意软件困扰地运作至关重要。现代客户端和服务器计算系统可以看作分为两层高级架构，平台和软件。出于此文档的目的，我们会将这两层逻辑架构的组合描述为系统。注意，图 1 只是示意性的，其本意并非为了表示平台中所有可能的设备，也不是为了表示任何特定设备的范例架构。在较高层级上，蓝色阴影方框中的项目是将要被视为平台的一部分的设备。

图 1：高层系统架构

宽泛地说，平台是由将系统启动至软件和操作系统可以被加载的阶段所必需的硬件和固件构成的；软件是由加载操作系统以及操作系统随后处理的所有应用程序和数据所要求的元素构成的。注意，某些固件在软件启动之后继续执行。现存的业界最佳实践，以及诸如 NIST SP800-147，BIOS 保护指南 [1]、NIST SP800-147B，服务器 BIOS 保护指南 [2] 等 NIST 出版物已经着手应对保护平台的宿主处理器启动固件（传统上称为 BIOS，近来称为 UEFI [3]）（脚注 1）的完整性及其更新机制的问题，但是，保护只是网络弹性的三大关键元素之一（另外两个是检测和恢复）。此外，平台上的其他关键固件的弹性的解决程度并未达到宿主处理器启动固件的对应程度。尽管识别和定义包含固件的硬件的每一种类别和架构超出了此文档的范围，此文档适用于任何包含固件的平台中的设备，包括个人计算机、服务器、网络设备、智能电话、平板等。

脚注 1：出于此文档的目的，宿主处理器启动固件将会被一般性地指代传统基本输入/输出系统（BIOS）或者统一可扩展固件接口（UEFI）。

2.1 平台设备

如上文所述，平台是提供操作系统和应用程序所需的功能能力和服务的一系列设备。尽管作为一个整体的平台的弹性是终极目标，认识到平台是由众多不同设备构成的，并且通常是由不同厂商开发和制造的是至关重要的。基于此原因，此文档中的技术指导意见以面向独立平台设备的指导意见的形式描述。

为了描述具有弹性的平台，本节提供了通常对于平台的正常和安全运作至关重要的设备的列表。这些设备通常包含可变的固件，并且被此文档中的安全性指导意见的预想范围所覆盖。

然而，这不应该被视为每一种感兴趣的平台中的所有设备的完整列表。平台厂商需要仔细考虑那些应该被视为处于它们的特定平台范围中的其他设备。

在传统的基于 x86 的平台（台式机、笔记本、服务器、网络交换机）的情况下，这些设备标识于图 1 中，并且于下文定义。注意，这里的编号指的是用于在图 1 中标识这些设备的编号，其顺序并非为了指示任何优先级或者次序。

嵌入式控制器（EC）/ Super I/O（SIO）

EC 通常与移动平台（笔记本、变形本、平板）相关联，而 SIO 通常与基于桌面的平台（台式机、基于桌面的工作站、一体机、瘦客户端）相关联。这并非普遍确切，但是通常足够确切以确定在某种类型的客户端系统中能够找到 EC 还是 SIO。EC 或者 SIO 通常控制平台中的诸如键盘、指示灯、风扇、电池监测/充电、散热监测等功能。此外，它通常是平台中的首个执行代码的系统板载设备，甚至会使得宿主处理器处于重置状态，直到 EC / SIO 准备就绪以允许宿主处理器获取它的首行宿主处理器固件代码。
可信平台模块（TPM）

TPM [4] 是一块能够安全地存储和使用密码学密钥以及平台状态测定数据的安全协处理器。这些能力可以被用于在其他事物之中保护存储于系统上的数据、提供强壮的设备身份，并且验证系统状态。尽管并非所有平台都包括或者使用 TPM，在任何包括并且使用 TPM 的系统上，它的固件必须被保护，鉴于它在帮助确保平台的可信度方面的至关重要性。TPM 还包含非易失性存储器，它可以包含关键数据，并且如果是这样，它必须被保护。TPM 可以是独立的硬件设备，也可以被实现在平台的主机控制器或者其他微控制器所执行的固件中（后者有时被称为固件 TPM 或者 fTPM）。
基板管理控制器（BMC）/ 管理引擎（ME）

BMC 与服务器平台相关联，而 ME 通常与客户端平台相关联。在这两种情况下，其功能的核心方面是作为一种带外管理设备，以允许管理员管理一个平台而无需要求宿主操作系统运行。尽管对于服务器或者客户端平台的基本计算功能而言并非总是严格必需，大多数现代服务器和客户端平台包含 BMC / ME，使得它们的固件不会对宿主处理器的安全域的完整性状态造成负面影响这一点至关重要。
宿主处理器【又称为中央处理器（CPU）、应用处理器（APU）】

宿主处理器是通常平台中的处理单元，在传统上称为 CPU，现在有时也称为 APU 或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所运行的处理单元。这是负责加载并执行宿主处理器固件的处理器。
网卡（NIC）

不论是独立的还是作为 SoC 的一部分而集成的，大多数现代客户端和服务器平台拥有至少一块 NIC（有线或者无线），并且可能拥有多块，包括多种类型（有线、Wi-Fi、蜂窝）。尽管拥有一块 NIC 对于启动一个平台并非严格必需，在当今的互联世界中，在系统启动之后的某个时间点拥有某种形式的连接性是至关重要的。更为重要的是，受到攻击的 NIC 固件镜像可以作为对系统中的其他漏洞的利用的发射台，被用于窃取数据、作为中间人等。除了由微控制器运行的固件以外，NIC 可能还包含在启动过程中加载并且由宿主处理器执行的扩展只读存储器（ROM）固件。NIC 的扩展 ROM 固件同样受到保护是至关重要的。此扩展 ROM 固件可以同宿主处理器启动固件一同存储（对于集成 NIC 的情况），或者对于作为扩展卡的情况，可以独立存储于 NIC 本身。NIC 通常还包含关键数据，例如，介质访问控制（MAC）地址可能存储于可变存储器中。针对此关键数据的攻击可能导致针对此平台以及具有匹配的 MAC 地址的另一台系统的拒绝服务（DoS）。
图形处理器（GPU）

GPU 是作为客户端平台中的主要“输出型”人体学接口设备（HID）的设备。在某些情况下，GPU 也可以被用作协处理器以支持高性能计算。GPU 可以作为对系统中的其他漏洞的利用的发射台。除了由微控制器运行的固件以外，GPU 可能包含在启动过程中加载并且由宿主处理器执行的扩展 ROM 固件。此扩展 ROM 固件可以同宿主处理器的启动固件一同存储（对于集成 GPU 的情况），或者对于作为扩展卡的情况，可以独立存储于 GPU 本身。
串行外设接口（SPI）闪存

大多数现代平台包括一定数量的 SPI 闪存以存储固件，通常是用于宿主处理器的启动固件，尽管它也可被用于其他目的。
A）用于大容量存储设备的主机控制器（HC）

对于大多数现代平台，需要有某种采用硬盘（HDD）或者固态硬盘（SSD）形式的本地大容量存储设备以启动操作系统并且存放用户的应用程序和数据。为了使得数据能够被存储到该大容量存储设备上，主机控制器（HC）被用于通过某种存储总线（例如 SATA、SCSI、PCIe）将数据从平台的主内存中移至物理存储介质中。HC 可以被集成到 SoC 中，也可以是独立的设备或者位于扩展卡上。

B）硬盘（HDD）/ 固态硬盘（SSD）

HDD 或者 SSD 代表了当前用于存储大量数据的传统平台中的最先进技术。这些设备与主机控制器（HC）相耦合。在 HDD 或者 SSD 内部，微控制器及其相关联的固件被用于执行将数据从平台的主内存发送至大容量存储设备的实际存储操作。对 HDD 或者 SSD 的固件的攻击同样可以用作对系统中的其他漏洞的利用的发射台，也可以被用于攻击用户和/或平台数据。
嵌入式多媒体存储卡（eMMC）/ 通用闪存存储（UFS）

eMMC 和 UFS 作为移动系统的标准大容量存储设备而出现。它们中的每一种都可以包含它们自己的扩展 ROM 固件和/或带有与之相关联的固件的微控制器。
宿主处理器启动固件

在大多数现代平台中，宿主处理器启动固件包含在 SPI 闪存设备中。BIOS 和统一可扩展固件接口（UEFI）是此类固件的范例。
平台运行时固件

除了启动固件以外，还有平台运行时代码。此代码在平台启动以后仍然驻留在内存中并且可执行。这对于在系统完全运行时需要执行固件以执行某些功能的微控制器而言最为常见。被看作运行时代码的宿主处理器固件的一个范例是系统管理模式（SMM）代码。
电源

某些电源拥有它们自己的微控制器和与之相关联的固件。通常的电池架构还包括内部逻辑和固件以管理该电池的充放电行为。
粘合逻辑（CPLD、FPGA）——未在图中显示

现代嵌入式系统使用可编程的逻辑组件以提供粘合逻辑功能。有两种类型的可编程逻辑组件，称为 FPGA 的现场可编程逻辑门阵列和称为 CPLD 的复杂可编程逻辑器件。FPGA 通常在加电时通过比特流程序从所连接的闪存设备中加载。而 CPLD 由比特流进行一次编程并且保持其功能，直到在现场被再次编程。通常，此功能是系统的基本操作所需要的，如果损坏，可能导致平台的永久拒绝服务。
风扇——未在图中显示

某些风扇拥有其自身的微控制器及其相关联的固件。

2.2 平台设备中的代码和数据

上述设备通常在其非易失性存储器中拥有某些固件和数据的组合，它们可以驻留在设备本身，或者位于共享存储设备（例如 SPI 闪存）。本节描述固件代码和数据，并且简要讨论此文档与这些组件相关的范围。

2.2.1 代码

固件代码是由任何设备的处理单元所使用以执行由设备所要求的操作的指令的集合。在历史上，平台设备中的固件极少在现场被修改，尽管系统或者组件厂商可以开发固件更新以便为漏洞打补丁、修复 bug 或者添加新功能。随着固件的复杂度增加，固件更新变得更加普遍，而硬件和操作系统厂商提供工具以帮助管理员更新他们的固件。

由于固件在很大程度上驱动着设备的行为，使其在平台上保持处于可信状态至关重要。针对固件代码的攻击可能使得设备不能运行，或者向设备中注入恶意功能。固件应该仅从授权的来源加载，通常是系统或者平台设备的制造商。

此文档中的指导意见描述了通过利用数字签名验证更新来保护固件的机制。它们还描述了检测针对固件的非授权修改的机制以及安全恢复的方法。

2.2.2 数据

数据是平台固件代码用以执行其操作的信息片断，如同其代码所指示。数据可以进一步分为关键和非关键。关键数据包括配置设置和策略，它们需要处于有效状态以使得设备维持其安全状态。非关键数据包括所有其他数据。

2.2.2.1 关键数据

关键数据可以被用于不同目的，包括：

配置设置：这些数据告知代码如何配置设备的操作方面
- 范例：启用某个被企业安全策略禁止的外设
- 范例：硬盘中的不可用扇区表
策略：这些数据告知代码选择何种路径或者如何响应
- 范例：系统的启动顺序描述了尝试用于启动的有效设备及其顺序
- 范例：UEFI 安全启动，一系列安全性配置以控制 BIOS 将控制权移交给哪些第三方代码

关键数据难于精确定义，由于对于某一设备可能属于关键的数据对于其他设备可能并非关键。然而，关键数据的共同特征包括：

它必须处于有效状态以允许设备的正常启动和运行时操作
它在加电周期之间持续存在（例如存储于非易失性存储器中）
它会改变设备的行为或者功能
它必须处于有效状态以支持平台固件及其相关联的数据的保护、检测和/或恢复

某些关键数据被硬编码到代码中，并且仅可通过固件镜像更新而更新。出于此文档的目的，硬编码的数据被看作代码的一部分，并且根据固件代码的保护、检测和恢复指导意见来保护。

平台设备通常拥有在其正常操作时可由平台管理员、硬件、固件或者软件配置的其他数据。由于关键数据的损坏可能影响系统的正常或者安全运作，保护关键数据防止损坏，并且能够在检测到问题时进行恢复是至关重要的。然而，对于某些形式的关键数据的强保护可能在架构上难于实现，由于这样一些期望，即诸如操作系统以及设备驱动程序等某些实体拥有更改这些设置的访问权限。

某些配置数据只能通过由平台层级的代码控制的限定的接口来更改，例如，UEFI 运行时变量属于此类。这一基本层级的保护可以防止攻击者直接修改配置数据，并且允许平台固件在将更改提交至存储设备之前验证其输入。然而，某些实体可能能够利用这些限定的接口来作出格式良好但却是恶意的配置更改。

为了防止这样的破坏，针对某些特别敏感的配置数据的更改可以要求在使用上述限定的接口应用更改之前通过授权。在某些情况下，诸如宿主处理器启动固件或者服务处理器固件等平台设备可能能够先于允许平台管理员作出更改对其进行认证。其他认证技术可以允许平台固件对更改的来源和完整性进行密码学验证。

某些关键数据由不会通过外部接口暴露为可编程的固件管理（例如耗损平均技术数据），并且如果丢失或者损坏，可能导致设备功能永久丧失。此类状态数据需要在最高层级进行保护，并且不可从平台的其他位置写入。

2.2.2.2 非关键数据

非关键数据可以被用于不同目的，包括：

信息性 / UI：这些数据仅是信息性的，或者用作最终用户的用户界面（UI）的一部分
- 范例：在启动过程中显示名为“Property of NIST”的财产标签
状态：不会影响平台完整性的状态设置
- 范例：系统启动时的数字锁定键的状态；BIOS 执行快速启动还是标准启动

非关键数据对于平台的安全启动或者操作不应该具有决定性。在实践中，所有由平台固件消费的数据都可能是安全敏感的，包括某些并不直接影响平台的正确和安全操作的数据。由平台固件消费的任何数据的错误或者对其的恶意攻击都可能暴露并且利用该代码中的漏洞。就其本身而言，对于由平台消费的任何非可信输入或者数据需要给予特别的关照。

第 3 章原理和关键概念

本章为平台弹性的指导原则提供了简要的描述，它们为此文档中的指导意见提供了基础。本章还讨论了用于整篇文档的主要架构方面的概念和考虑。

3.1 支持平台弹性的原则

此文档中的安全性指导意见基于下列三个原则：

保护：

保证平台固件代码和关键数据处于某种具有完整性的状态，并且受到保护以防止损坏的机制，诸如保证固件更新的合法性和完整性的过程
检测：

检测平台固件代码和关键数据于何时发生损坏或者从某种授权的状态发生更改的机制
恢复：

用于将平台固件代码和关键数据恢复至某种具有完整性的状态的机制，如果任何上述代码或者关键数据被检测为发生损坏，或者如果被迫通过某种授权机制来进行恢复。恢复被限制为恢复固件代码和关键数据的能力

第 4 章的技术指导意见围绕这些原则进行组织。第一个原则，保护，其范围和目的类似于 NIST SP 800-147，BIOS 保护指南 [1] 中的指导意见。关于保护的基本原则在此文档中得到扩展以适用于平台中的更为宽泛的一组固件和配置数据。

尽管保护机制的本意是防止针对平台固件和关键数据的破坏性和恶意攻击，这些机制在所有类别的设备上的实现可能不完美或者不现实。在这些情况下，检测和恢复机制的本意是发现并且化解攻击，从而重新得到设备的正常和安全的运行。

3.2 弹性属性

此文档中的技术指导意见根据针对单个平台设备的指导意见而写作，以使得它们广泛适用于一系列设备、平台和系统。抛开对于设备的狭窄专注，此文档的本意是通过保证底层平台具有弹性从而建立起支持系统整体弹性以对抗破坏性攻击的指导意见。

平台可能不能为其所有平台设备完整地提供保护、检测和恢复能力。哪怕只是一个设备的功能丧失也可能足以使得整个系统永久性地不能运作，如果该特别设备在启动或者运行平台中具有关键作用。作为一个整体的平台若要称其为具有对抗破坏性攻击的弹性，其中对于最小限度地恢复系统运作所必需的，以及足以恢复系统的合理的功能的那一组平台设备，其本身应该是具有弹性的。我们称这组设备为 关键平台设备。特定的弹性属性可能因平台而异。

受保护的

平台若要被看作 受保护的，所有关键平台设备必须满足 4.1 和 4.2 节的保护指导意见，但可以不完全地提供恢复设备地固件和/或关键数据的能力
可恢复的

平台若要被看作 可恢复的，所有关键平台设备必须提供 4.1 和 4.3 节所描述的检测损坏的方法，并且提供满足 4.1 和 4.4 节的指导意见的从损坏中恢复的方法
具有弹性的

平台若要被看作 具有弹性的，所有关键平台设备必须满足第 4 章的所有指导意见。非关键设备也应该满足这些要求，或者至少是如此设计的，即针对这些设备之一的攻击不会影响作为整体的平台的安全性。具有弹性的平台将会尝试防止那些能够干扰平台正确运行的攻击，同时还能提供机制以检测所发生的恶意或者意外的问题并且从中恢复

3.3 可信根和信任链

此文档中所描述的安全机制建立在可信根（RoT）之中。可信根是构成了提供一项或者多项诸如测定、存储、报告、恢复、验证和更新等具体针对安全性的功能的基础的元素。RoT 必须被设计为总是以预期的方式运作，由于它的恰当运作对于提供它的具体针对安全性的功能至关重要，并且由于它的不当行为不能被检测到。RoT 通常是信任链（CoT）中的首个元素，并且可以作为这样一条信任链中的锚点，以提供更加复杂的功能。RoT 的责任和能力可以完全在 RoT 内部实现，也可以利用通过一条植根于 RoT 的信任链由其 RoT 衍生的代理来执行。例如，当某个恢复代理（RTRec）被触发时，它将会通过启动另一个元素来引发恢复过程，该元素确定一种适当的恢复序列并且启动一连串的后续元素以执行恢复操作。图 2 提供了关于信任链如何从某个初始 RoT 建立的高层级描述。

通常，后续元素在维持由 RoT 开始的信任链中具有协助性。信任链中的组件具有提升的权限以执行安全性关键任务，诸如执行那些对于不那么受信任的软件不可用的设备更新。RoT 和 CoT 可以拥有机制以放下这些权限，一旦其安全功能执行完毕，或者如果该安全功能被确定为非必要。CoT 也可以在将控制权移交给某个非协助性的元素之前放下这些权限。

图 2：可信根

由于 RoT 对于提供关键安全功能至关重要，它们需要在设计上是安全的。确定 RoT 的可信度方面的主要考虑包括对于 RoT 的攻击面的分析，以及对于用于保护该攻击面的化解方法的评估。确保 RoT 的可信度是提供可信根的厂商的责任。厂商通常通过使得 RoT 不可变，或者通过保证在针对 RoT 的任何更新的完整性和合法性得到验证之后才执行这样的更新来保护它们。通常，RoT 运行在隔离环境中，并且运行在高于任何可能修改它的事物的权限等级之上，并且/或者能够在任何事物可能修改它们之前完成其功能，以保证其他设备不能在操作过程中攻击其行为。

此文档的 4.1 节提供了关于支持平台弹性的 RoT 的能力和属性的具体指导意见。

平台通常由大量设备组成，通常在设备以及不同制造商之间存在隔离边界。一个平台可能需要多个独立的 RoT 和 CoT 以提供对于弹性的完整覆盖。例如，硬盘控制器可能拥有不同于宿主平台的独立微控制器和固件。硬盘控制器和宿主平台可能都需要其各自独立的恢复信任链，如果它们各自的关键数据损坏。

3.4 设备关系

由于缺少能力或者功能，某些平台设备可能并不拥有它们自己的可信根以执行更新、检测或者恢复。我们将需要协助的设备称为共生设备，而将提供协助的设备称为宿主设备。依赖关系可以被如此确立，如果宿主设备和共生设备可以共同满足保护、检测和/或恢复的指导意见，而共生设备不能独立满足这些要求。这样的依赖关系可以撬动安全通讯信道或者其他技术。为了能够高效地提供协助，宿主设备需要自身满足那些关于它们所协助传递给共生设备的机制的指导意见。合在一起，宿主和共生设备提供了一条用于实现保护、检测和/或恢复的安全性指导意见的 CoT。

图 3：信任链

设备之间可能存在这样的关系，这里的信任是隐式的——即这种信任由系统架构来提供。一个设备可以从另一个设备接收关于无歧义的物理存在的指示，在此，一种隐式的信任关系已经存在。另一个设备通过可信路径发送消息这一事实意味着此设备可以信任该请求。

图 3 中的示意图显示了共生设备和宿主之间的关系的不同方面；这种关系可以位于隔离边界内部，或者跨越隔离边界、跨越设备。它还显示了在具有多个可信根、多条信任链以及多条通讯路径的情况下，不同的设备可以如何共存。

可能还存在其他关系，它们既不暗示也不要求任何信任级别。考虑一个负责接收更新的设备。该设备可以随后将这些更新传递至其他设备。由于每个设备（或者连同其宿主设备的共生设备）负责验证其自身的更新，在发布更新的设备和被提供这些更新的设备之间没有信任要求。

3.5 固件更新机制

固件保护指导意见的核心原则是保证只有合法并且经过授权的固件更新镜像可以被应用到平台设备。如果来源（例如设备、系统制造商或者其他经过授权的实体）和完整性可以被成功验证，则称此更新镜像为合法的。在应用更新之前验证镜像的技术过程称为 认证更新机制。

而授权则是许可执行某个更新的过程。尽管认证过程通常植根于设备或者系统制造商，执行更新的授权过程通常植根于设备或者系统所有者。

3.5.1 认证更新机制

认证更新机制利用数字签名以保证固件更新镜像的合法性。利用认证更新机制更新固件镜像依赖更新可信根（RTU），它包含一种签名验证算法和一个密钥存储器，该密钥存储器包含验证固件更新镜像的签名所需的公钥。此密钥存储器和签名验证算法以某种受保护的方式存储于计算机系统上，并且仅可通过使用认证更新机制或者安全本地更新机制来修改。

RTU 中的密钥存储器包含用于验证固件更新镜像的签名的公钥 [7] 或者包含该公钥的散列值 [6]，如果该公钥由固件更新镜像提供。在后一种情况下，更新机制计算由固件更新镜像提供的公钥的散列值，并且保证它和出现在密钥存储器中的某个散列值相匹配，然后才会使用提供的公钥来验证固件更新镜像的签名。

密钥存储器中的与该公钥对应的私钥有可能受到“攻击”，例如，该私钥被盗并且被曝光，获得此密钥的访问权限的攻击者可以签名无效固件，它可以损坏平台设备或者向平台中注入恶意软件。对于签名的恰当使用因此使得供货成为必需，以便从密钥攻击中恢复。一系列技术可用于从这些情况中恢复。范例可以复杂到包括密钥层级，也可以简单到包括在恢复（或者更新）镜像的其余部分时更新密钥存储器。

3.5.2 授权更新机制

系统及其支持管理软件和固件可以提供若干种授权机制以便合法地更新固件镜像。这些包括：

由用户引发的更新：厂商通常为最终用户提供能够更新固件镜像的工具。这可以是通过外部介质以执行这些更新，也可以是通过能够从用户的正常操作系统中更新固件镜像的工具。取决于系统上所实现的安全机制，这些工具可以直接更新固件镜像，或者它们可以安排在下次系统重启时更新。更新后的代码将会遇到由不同修订版本的代码写入的关键数据。更新后的代码应该保证平台继续正常工作，可以通过保持同关键数据兼容、通过更新关键数据以使其同更新后的代码兼容，或者至少是通过将关键数据的值重置为其默认值来实现。
受管理的更新：一台给定的计算机系统可能拥有基于硬件和软件的代理，它们允许系统管理员远程更新固件镜像而无需来自用户的直接介入。
回滚：在应用更新之前对其进行认证的实现可能也会在更新过程中检查版本号。在这些情况下，固件镜像可能拥有一种特殊的更新过程，用于将已安装的固件回滚至某个早期版本。例如，回滚过程可能要求用户的物理存在。此机制可以防止攻击者安装具有已知漏洞的老旧固件。
手动恢复：为了从损坏或者不能正常工作的固件中恢复，计算机系统可以提供机制以允许具有物理存在的用户在启动过程中将固件镜像替换为已知良好的版本和配置。
自动恢复：某些计算机系统能够检测固件镜像于何时损坏并且从存储在不同于损坏的镜像的位置（例如第二块闪存存储器芯片、存储设备的保护区域等）的备份固件镜像恢复。

3.5.3 安全本地更新

尽管此文档建议固件更新通过 3.5.1 节所描述的某种认证更新机制来实施，某些设备也可以支持一种安全本地更新机制。这些机制通过某种能够说明无歧义的物理存在的过程来替代授权固件更新。例如，安全本地更新机制可以被用于从某个不能利用认证更新或者自动恢复机制更新的损坏的固件镜像中恢复。安全本地更新机制也可被一位物理存在的管理员用于在一个不允许回滚的设备上将其更新至某个早期固件镜像。

为了防止远程攻击利用安全本地更新机制，这些机制验证用户是否已经物理授权该更新是至关重要的。诸如通过远程控制台同设备或者系统进行交互等远程机制不满足关于物理存在的要求。类似地，可以被运行在系统或者设备上的恶意软件伪造的机制不满足此要求。参见 3.6.2 节以获得更多细节。

然而请注意，实现了安全本地更新机制的设备潜在地易受来自恶意管理员的攻击，以及对该设备或者系统具有物理访问权限的其他攻击。额外的物理、环境和技术方面的安全性措施对于保护这些设备至关重要，但是这些超出了此文档的范围。

3.6 关于平台弹性的其他考虑

此文档并未解决购买者、用户或者 IT 管理员可能考虑到的属于平台网络弹性的某些其他考虑。关于这些其他考虑的不完全列表和讨论见下文。

3.6.1 管理

厂商在设计具有弹性的平台时应该仔细考虑它们的目标客户，以保证恰当的管理和控制策略以及配置设置能够以最好地服务于客户要求的方式来管理。策略和配置设置的管理可以在本地或者远程进行。取决于平台类型，客户可能期望安全地从远程位置完整地管理平台的能力。某些客户可能期望要求物理存在的用户批准策略更改。其他客户可能期望能够远程提取任何日志数据，或者它们可能希望阻止提取日志数据，除非通过授权的本地机制。

3.6.2 授权机制

某些恢复和管理操作可能对平台固件或者软件作出重大修改。例如，固件设置可以控制启动顺序，而软件恢复代理可能还原一份备份而删除最近创建的数据。修改这些设置可能要求平台层级的授权以表明请求此更改的实体被授权如此做。对于某些环境，诸如大型组织机构或者数据中心，专业平台管理员可以利用提供给管理平台用的凭证来远程授权操作。在其他环境中，例如消费者或者小型企业，可能没有远程平台管理员。然而某些系统可能拥有可以本地使用的平台管理员凭证。或者，某些系统可以允许用户主张平台层级的授权，通过确保物理存在的用户发出命令或者请求更改。在这些系统上，平台必须无歧义地验证物理存在的用户授权了此操作。如果正确处理，恶意软件不能伪造涉及来自物理存在的用户的确认的授权检查。我们使用“无歧义的物理存在”这一词语来指示不能被恶意软件伪造的本地用户。

无歧义的物理存在允许主张平台层级的授权（或者平台层级授权的一部分），通过表明此人正在同设备或者平台进行物理交互。通过保证恢复操作或者关键数据更改得到了物理存在的人员的授权，无歧义的物理存在提供了一种本意是要防止恶意软件的影响的管理路径。

创建能够恰当和可靠地验证来自物理存在的人员的确认的平台和设备是复杂的。专用的物理按钮或者硬件跳线可以提供一种相对直接和显式的方法，以此表明物理存在。平台设计或者部署方面的考虑可以防止某人拥有直接物理机制以便同每一个支持某种依赖无歧义的物理存在的功能的设备进行交互。在这些情况下，需要在用于验证无歧义的物理存在的机制和将要以管理员的名义执行操作的设备之间存在一条可信路径。为了满足此文档后面提到的不可绕过性的指导意见，这条可信路径，它可能包括输入/输出设备（例如人体学接口设备、显卡等）和内部总线，需要被保护以防止其被恶意软件操控。

有一系列技术可以在验证无歧义的物理存在的物理机制和平台或者设备之间提供可信路径。一个范例可能是仅当平台可以被信任为处于某种具有完整性的状态，先于恶意软件可能干扰这些过程，诸如在启动过程的早期，才可以接受或者确认来自物理存在的人员的命令。在其他情况下，系统架构可能会在服务处理器（例如 EC、BMC）和其他平台设备之间提供可信路径。

依赖无歧义的物理存在而非平台管理员凭证以授权管理操作的设备可能易受具有该设备的物理访问权限的个人的攻击。因此它的应用可能不适合于缺少强物理安全性的应用或者环境。

3.6.3 网络辅助恢复 vs. 本地恢复

在大多数情况下，通过本地从损坏中恢复的能力将会是最为简便的，能够提供最高等级的客户满意度，并且可能是必需的，如果没有网络连接性。然而公认的是，这并非总是可能的，特别是鉴于众多设备所具有的存储限制。在本地恢复不可能的情况下，网络辅助恢复可以被实现，如果以某种安全并且可信的方式实施，这可能包括使用加密、数字签名、安全传输方法等。尽管本地或者网络辅助的恢复都是可接受的实现机制，一台设备同时支持二者的能力提供了更高级别的弹性，因而是推荐的。

3.6.4 自动恢复 vs. 手动恢复

恢复可以通过三种方式之一进行：

完全自动——引发恢复或者在恢复过程中无需用户交互
部分自动——自动引发恢复，但是在恢复过程中的某些时间点要求用户交互
手动——要求用户交互以引发恢复

完全自动恢复机制可能被某些用户所偏好，由于它可以在发生大范围攻击时允许更快速的大规模恢复。

完全自动恢复可能并不被所有系统支持，或是所有用户都想要的。例如，系统可能要求管理员凭证或者授权以继续恢复过程。

手动恢复可能被某些用户所偏好，以使得平台管理员被告知发生了某些错误，然后等待管理员决定接下来将要采取何种步骤。这可能也会有用，如果平台管理员希望捕获信息以帮助取证分析。

由管理员定义的策略通常定义了手动恢复的行为和权限要求。这样的策略可能也会影响自动恢复。例如，一条由管理员定义的策略可能会限制在恢复过程中可以被安装的固件版本。设置恢复策略者必须谨慎行事。策略中所设置的固件版本可能刚好就是被成功攻击从而使得恢复成为必需的版本。简单地重写易受攻击的版本可能导致攻击/恢复的循环。

策略本身也可能成为攻击目标，因此，恢复实现的设计必须说明该策略不可用的可能性。同时，由于恢复可能是多步骤的过程，一条将会在恢复过程结束时被满足的策略要求可能在中间步骤过程中未被满足。

重写固件镜像的恢复方案可能会在恢复过程中破坏那些将会有助于分析攻击的证据。恢复方案应该在可行的情况下提供方法以保留或者记录被攻击的镜像以及其他信息，在那些恢复固件时可能会丢失该信息的情况下。

3.6.5 事件日志

记录固件和恢复相关事件的日志通常可能有助于多种目的，包括但不限于：

允许系统的平台管理员捕获关于可能导致针对平台的攻击或者实际平台攻击的信息的取证分析。这可能有助于确定平台是否可能包含未知安全漏洞，或者理解是否可能存在具有类似性质的大规模攻击。
提供一条审计路径以获知某一事件于何时发生，以及某次更新或者恢复是否得到授权、由谁授权以及何时授权。

平台和设备制造商需要决定它们的系统可能要求何种级别的事件日志记录，为这些系统考虑预想中的用户环境。记入日志的事件应该以一种能够提供对其完整性的担保，并且允许日志事件的安全恢复和传输的方式来记录。必须谨慎行事以保证对事件日志的访问权限受到控制。非授权的人员可以利用事件日志数据分析以拓宽攻击面。

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

本章针对弹性三要素：保护、检测和恢复中的每一个详细叙述平台设备的技术安全指导意见。设备可以实现本章中的一节或者多节中的要求，基于它们所意在支持的固件弹性属性，如 3.2 节所定义。4.1 节提供了关于支持这些属性的可信根的基础安全性指导意见。4.2 节提供了关于保护固件代码和关键数据的安全性指导意见。关于检测针对固件和数据的非授权修改的机制的指导意见描述于 4.3 节。最后，4.4 节具体说明了针对固件和数据恢复机制的安全性指导意见。

尽管这些指导意见是以适用于独立设备的形式编写的，一个设备可以在另一个设备的协助下实现这些指导意见。安全功能可以由设备自身实现（自包含的），或者它可以依赖于一种安全架构，在此，另一个平台设备可以为此设备提供某些或者全部安全功能。依赖另一个设备以提供必要的安全功能要求在这些设备之间具有关键信任关系，如 3.4 节所描述。这些指导意见将依赖于来自另一个设备的安全功能的设备称为 共生设备，而将为共生设备提供这些功能的设备称为 宿主设备。在这些情况下，共生设备和宿主设备共同形成了负责实现安全功能的可信根和信任链。宿主设备必须额外满足对于自包含的设备的所有要求。

将要（shall）、应该（should） 和 可以（may） 的使用如同 RFC 2119 [5] 中定义。

4.1 可信根

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

更新可信根（RTU）负责认证固件更新和关键数据更改以支持平台保护能力
检测可信根（RTD）负责实现对于固件和关键数据的损坏的检测能力
恢复可信根（RTRec）负责在检测到损坏时以及在得到管理员指示时恢复固件和关键数据

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

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

安全机制将要被构建于可信根（RoT）中
如果使用了信任链（CoT），某个 RoT 将要作为 CoT 的锚点
所有 RoT 和 CoT 将要要么是不可变的，要么由能够保证所有 RoT 和 CoT 保持为某种具有完整性的状态的机制对其进行保护
位于非易失性存储器中的更新、检测和恢复信任链中的所有元素将要在平台固件中实现

注释：此指导意见，即 RoT 和 CoT 被作为平台固件的一部分而实现，仅适用于那些用于实现此论文中描述的平台弹性功能的元素。我们鼓励平台厂商维持一条始于启动固件、贯穿操作系统的信任链以提供对抗不同形式的攻击的弹性。
RoT 和 CoT 的功能将要具有弹性以防止由运行在宿主处理器所运行的操作系统之下，或者作为此操作系统的一部分的软件所试图进行的任何破坏
从宿主处理器上所运行的软件传输到平台固件的信息将要被视为不可信的
CoT 可以被延伸到包括不是来自非易失性存储器的元素。在使用之前，这些元素将要由 CoT 中的早期元素进行密码学验证
跨越设备边界，或者为共生设备提供服务的 RoT 和 CoT 将要在设备之间使用某种安全通讯信道

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

每一个具有可变固件的平台设备将要依赖更新可信根（RTU）或者植根于 RTU 中的更新信任链（CTU）以认证固件更新
如果 RTU 或者 CTU 是可变的，则 RTU 或者 CTU 元素将要利用一种认证更新机制来更新，如果没有贯穿于安全本地更新的物理介入。在这样一次更新过程中，RTU 或者 CTU 将要在后续重启时，甚至是如果发生了意外的灾难性事件（例如在闪存写入过程中发生断电）时总是保持可运作或者可恢复
RTU 或者 CTU 将要包含一个密钥存储器，以及一种来自 FIPS 186-4 [7] 的受批准的数字签名算法实现以验证固件更新镜像的数字签名
如果此密钥存储器是可更新的，则此密钥存储器将要利用某种认证更新机制来更新，如果没有贯穿于安全本地更新的无歧义的物理存在

注释：可更新的密钥存储器提供了一种方式以便从签名密钥的攻击中恢复，但是这可能使得此设备的密钥存储器更易受到破坏。我们鼓励使用不可更新的密钥存储器的实现者设计化解和恢复机制以应对固件签名密钥的潜在泄露的威胁。
植根于 RTU 中的认证更新机制将要成为用于更新设备固件的唯一方式，如果没有贯穿于安全本地更新中的无歧义的物理存在

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

每一个实现了检测能力的平台设备将要依赖于检测可信根（RTD）或者植根于 RTD 中的检测信任链（CTD）以用于它的检测
RTD 或者 CTD 将要包括或者拥有对于检测固件代码和关键数据损坏的必需信息的访问权限
植根于 RTD 的检测机制将要提供 4.3 节所具体说明的检测能力

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

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

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

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

4.2 保护

尽管之前的努力（例如 NIST SP 800-147 [1]、NIST SP 800-147B [2]）解决了 BIOS 的保护问题，平台中仍有其他安全关键固件并未被解决。这些包括驻留在管理控制器、服务处理器、存储设备、网络控制器和图形处理器中的固件。同时，保护必须被延伸到与受保护的固件相关联的关键数据上来，由于某些此类数据可能成为能够攻击平台完整性的攻击向量。

所有提供固件代码和关键数据保护的平台设备必须满足下列要求。

4.2.1 可变代码的保护和更新

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

4.2.1.1 认证更新机制

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

固件更新镜像将要使用如同 FIPS 186-4，数字签名标准 [7] 所具体说明的一种受批准的数字签名算法签名，它具有至少 112 位的安全强度，以符合 SP 800-57，关于密钥管理的建议——第 1 部分：总则 [8] 的要求
每一个固件更新镜像将要由某个授权实体——通常是设备制造商、平台厂商或者可信的第三方——签名以满足 SP 800-89，关于获取用于数字签名应用程序的担保的建议 [9] 的要求
新的或者恢复的固件更新镜像的数字签名将要在非易失性存储器更新过程完成之前由 RTU 或者 CTU 验证。例如，这可以通过验证内存中的更新内容然后执行活动闪存的更新来实现。在另一个范例中，这还可以通过将更新加载至闪存的某个区域，验证它，然后将该闪存区域选定为活动区域来实现

4.2.1.2 完整性保护

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

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

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

4.2.1.3 不可绕过性

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

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

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

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

4.2.2 不可变代码的保护

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

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

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

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

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

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

如果非易失性存储器中的关键平台固件代码被复制到内存中执行（为了提升性能或者出于其他原因），那么内存中的固件程序将要被保护以防止其被软件修改，或者将要在软件启动之前完成其功能
如果关键平台固件将内存用于临时数据存储，那么此内存将要被保护以防止运行于平台上的软件的影响，直到该数据的使用完成
软件将不会能够干涉关键平台固件的预期功能，例如通过拒绝执行、修改处理器模式或者污染缓存

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

4.2.4 关键数据的保护

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

关键数据将要仅可通过设备本身或者由设备固件提供的限定接口进行修改。限定接口的范例包括由设备固件使用的私有或者公有应用程序接口（API）或者基于标准的接口。共生设备可以依赖它们的宿主设备来满足此要求
关键数据更新将要在提交关键数据更改之前由设备或者共生设备的宿主设备进行验证，以保证新的数据结构良好。验证的范例可能包括范围或者边界检查、格式检查等
关键数据更新将要由平台管理员或者授权固件更新机制的一部分来授权
关键数据更新可以使用机制以先于其使用认证关键数据
设备将要至少以保护其代码的同等程度保护其出厂默认值。此出厂默认值将要能够以和代码相同的方式进行更新

4.3 检测

本节中的指导意见描述了可以检测设备固件和关键数据在其被执行或者由设备消费之前发生非授权更改的机制。如果非授权更改被检测到，设备可以引发恢复过程，如 4.4 节所描述。检测机制对于对其固件或者关键数据缺乏强保护的设备特别重要。然而，这些机制也可以提供一种方式以检测尝试实现 4.2 节中的指导意见的设备中的固件或者关键数据保护中的错误。

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

4.3.1 损坏的代码的检测

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

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

导致活动关键数据或者固件镜像的损坏，或者破坏其保护机制的成功攻击，就其自身而言将不会自发导致针对 RTD 或者检测固件镜像损坏所必需的信息的成功攻击
下列技术中的一项或者多项将要被用于 RTD 或者 CTD 以验证固件代码：
- a) 先于执行 RTD 以外的代码，利用某种受批准的数字签名算法或者密码学散列值对设备固件代码进行完整性验证
  
  注释：完整性验证也可以于运行时进行。这些机制可以植根于 RTD，也可以不植根于 RTD。
- b) 共生设备可以依赖宿主设备以执行检测。如果共生设备独立于宿主设备启动，共生设备的固件完整性验证将要在执行宿主 CTD 以外的代码之前进行。在这些情况下，下列额外的要求适用：
  1. 共生设备的固件将要根据 4.2.1 节的要求进行保护
  2. 宿主设备应该能够立即引发共生设备固件的恢复过程，然后重启该设备，如果检测到损坏
- c) 某些硬件设备（例如 FPGA、CPLD）可能拥有现场可升级的逻辑而非固件代码，通常称为配置比特流。如果这些设备没有支持密码学验证的能力，或者符合 a) 或者 b) 的测定和报告能力，它们将要使用基于硬件的机制以检测设备加载错误
- d) 其他技术（例如看门狗计时器）可以和密码学完整性检查共同使用以检测平台设备初始化过程中的其他问题
如果检测到损坏，RTD 或者 CTD 应该能够启动恢复过程以便将设备固件代码恢复为某个合法版本
检测机制应该能够创建关于损坏的通知
检测机制应该能够在检测到损坏时记录事件日志
检测机制可以能够使用由平台管理员设置的、定义了 RTD/CTD 在上述指导意见中所采取的行动的策略

4.3.2 关键数据的损坏的检测

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

RTD 或者 CTD 将要先于其使用执行关键数据的完整性检查。完整性检查可以采用诸如针对已知有效值验证数据或者验证数据存储器的散列值等形式
无论作为完整性检查的替代方案（对于不能支持这样的能力的设备）还是作为这些检查之外的额外方案，RTD 或者 CTD 可以使用看门狗计时器以检测关键数据的潜在损坏
如果检测到关键数据的损坏，RTD 或者 CTD 将要能够启动恢复过程以恢复设备的关键数据
检测机制应该能够在检测到损坏时记录事件日志
RTD 或者 CTD 应该能够创建关于损坏的通知
RTD 或者 CTD 可以能够转发关于损坏的通知

4.4 恢复

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

4.4.1 可变代码的恢复

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

固件恢复机制将要抵御那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击
- a) RTRec、CTRec 以及合法的恢复固件镜像应该独立于运行的固件被保护
RTRec 或者 CTRec 将要能够获取合法的设备固件镜像
- a) 如果合法的固件镜像本地存储于非易失性存储器中，该镜像将要被保护以防止非授权修改
更新到本地存储的合法固件镜像的过程将要通过认证更新机制（4.2.1.1 节）或者安全本地更新（3.5.3 节）的方式实现
非本地恢复机制将要先于恢复使用认证更新机制（4.2.1.1 节）以验证恢复镜像的完整性和合法性
如果合法固件镜像采用远程存储，恢复策略将要可配置镜像的位置
如果某个设备（共生设备）依赖于另一个平台设备（宿主设备）以提供其 RTRec 或者 CTRec，则宿主设备的 RTRec 或者 CTRec 将要在恢复操作过程中调用宿主/共生认证更新机制
设备将要实现其自身的恢复能力，或者该设备（共生设备）和另一个平台设备（宿主设备）将要共同实现共生设备的恢复能力
恢复机制应该能够在执行恢复时记录并报告事件日志
恢复机制应该能够提供关于恢复事件和行为的通知
恢复机制可以能够执行恢复行为而无需通知或者由用户或者系统管理员介入
恢复机制可以请求来自用户或者系统管理员的批准以执行恢复行为
平台管理员应该能够引发可变代码的恢复。设备应该为平台管理员提供方法以强制恢复。设备可以按照平台层级的授权以通过一个或者多个可信设备的链条强制恢复，这些设备中的首个将要在指示下游设备进行恢复之前验证平台层级的授权
恢复过程应该防止非授权地恢复到某个包含安全漏洞的早期固件版本。整体恢复过程应该辅助恢复到某个最近的固件版本。这些可以被实现为多阶段的恢复过程

4.4.2 关键数据的恢复

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

恢复关键数据的机制将要抵抗那些能够损坏活动关键数据或者主固件镜像，或者破坏它们的保护机制的攻击
设备应该提供某种方式以便将活动关键数据的一份或者多份已知良好的副本备份到一个或者多个其他位置。这些位置的保护将要至少和对于活动关键数据的保护一样好。这些保护应该好于对于活动关键数据的保护
- a) 不能备份其自身的关键数据的共生设备应该使其关键数据对其宿主设备可用。在此情况下，宿主设备将要备份共生设备的数据
- b) 如果共生设备将其关键数据提供给宿主设备以使得宿主设备可以备份该数据，则该共生设备应该能够消费恢复的关键数据
设备可以通过将其关键数据用作成功重启的一部分来确认该数据为“已知良好”的
设备将要如此备份关键数据：自动、当用户指示时，或者由另一个可信设备指示如此做时
RTRec 或者 CTRec 将要能够将关键数据恢复至出厂默认值
RTRec 或者 CTRec 应该能够恢复至上一次已知良好的关键数据
设备将不会利用由该设备作为关键数据储存的策略来恢复其自身的关键数据。然而，共生设备可以依赖由宿主设备提供的策略
如果有多个备份可用，RTRec 或者 CTRec 可以允许选择使用哪个备份
如果自动检测关键数据的损坏，RTRec 或者 CTRec 可以在替换当前关键数据之前获得来自宿主设备或者用户的批准
在没有 RTD 或者 CTD 以触发恢复行为的情况下，平台管理员应该能够引发关键数据的恢复。设备应该为平台管理员提供方式以强制恢复。接收到授权请求以强制恢复的设备可以随后指示与其已经建立信任关系的其他设备进行强制恢复，可以是直接进行或者通过可信设备的链条进行

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

恢复到上一次已知良好的状态
重置为出厂默认值
更新至最新固件镜像
执行部分“修复”操作
恢复到某个由企业定义的“起始点”
上述情况的任何组合

注意，在正常操作被恢复之前，恢复过程可能要求多个阶段。例如，在恢复到上一次已知良好的配置数据之前，设备可能会最初恢复出厂默认的配置数据。

在考虑如何确定将设备恢复到上述哪种完整性状态时，使用基于策略的方式将会使得利用关键数据以存储/维持这些策略成为必需。然而，如果该关键数据损坏，则恢复过程可能要么不能发生，要么不能正确地发生。因此，厂商应该仔细考虑用于恢复的算法。例如，某种直接机制可能使用简单的最近使用（MRU）算法。例如，此算法可能首先尝试恢复到上一次已知良好的状态；如果该数据无效，则它可能接下来尝试恢复到某个先前保存的状态；如果该状态不可用，则它可能会尝试从某个远程企业存储位置恢复；如果该位置不可用，则它可能会尝试重置为出厂默认值。如此使用算法方式消除了恢复操作过程中依赖关键数据处于某种具有完整性的状态的需求。

附录 A——首字母缩略词

此论文中使用的选定的首字母缩略词和缩略语定义如下。

BIOS：基本输入/输出系统
CoT：信任链
CPLD：复杂可编程逻辑器件
CTD：检测信任链
CTRec：恢复信任链
CTU：更新信任链
FPGA：现场可编程逻辑门阵列
ROM：只读存储器
RoT：可信根
RTD：检测可信根
RTRec：恢复可信根
RTU：更新可信根
UEFI：统一可扩展固件接口

附录 B——词汇表

活动关键数据：用于初始化或者配置设备的那一份关键数据副本。注释：活动关键数据并不包括关键数据的备份。
扩展卡：用于指代可以通过诸如 PCI 等连接总线插入到平台中或者从平台中移除的任何设备的通用术语。扩展卡通常被插入到平台的物理机箱内部，而非物理存在于平台外部。扩展卡拥有其自身的设备及其相关联的固件，并且可能拥有其自身的扩展 ROM 固件。
认证更新：使用认证更新机制的更新。
认证更新机制：一种更新机制，它保证更新固件镜像经过数字签名，并且该数字签名可以在更新该镜像之前利用更新可信根（RTU）的密钥存储器中的某个密钥进行验证。
授权更新：使用授权更新机制的更新。
授权更新机制：一种更新机制，它在安装更新之前检查是否得到了批准。批准可能包括检查是否拥有凭证、由物理存在的人员进行确认，或者类似的方式。
启动固件：用于描述在平台上执行以启动（启动、初始化）设备的任何固件的通用术语。这可能包括但不限于初始化设备内存、初始化设备寄存器、初始化连接性接口、设备的健康度检查等。启动固件的一般目的是使得设备或者平台对于正常操作使用准备就绪。
信任链（CoT）：信任链（CoT）是植根于可信根（RoT）中的一系列协作性的元素，该元素通过当它移交其控制权时将相同的信任属性传递给下一个元素来延伸当前元素的信任边界。其结果是两个元素都能同等程度地完成信任功能，如同它们是一个可信元素那样。这一过程可以被延续，以进一步延伸信任链。一旦控制权被移交给未经验证或者不能被验证的代码，则信任链终结。这也被称为将控制权移交至某个非协作性的元素。
代码：由处理器或者类似设备（FPGA、CPLD 等）直接执行的指令。也包括由程序进行解读的指令。源代码 是被翻译成代码并且随后执行的人类可读指令。
损坏：损坏是指固件代码的完整性的丧失，或者关键数据中的错误或者意外的值，这可能是一系列不同原因中的任意一种的结果，包括但不限于：恶意活动（例如攻击者）、编写不良的代码（例如缓冲区溢出、算法错误）、意外事件（例如用户疏忽的行为）、未能安装某个安全补丁、非授权更改，或者由硬件引发的（例如信号完整性、阿尔法粒子、供电故障等）。
关键数据：关键数据是在加电循环之间持续存在的可变数据，并且必须处于由平台管理员授权的某种有效状态，以使得平台的恢复和/或启动过程可以安全和正确地进行。
关键平台固件：所有具有这些特征的平台固件的集合：(a) 执行任何平台固件的保护、检测、恢复和更新功能；(b) 维护关键数据的安全性；或者 (c) 实现了不可绕过的关键数据接口。
设备：用于指代平台上的任何计算或者存储元素，或者计算或者存储元素的组合的通用术语。设备的范例包括中央处理器（CPU）、应用处理器（APU）、嵌入式控制器（EC）、基板管理控制器（BMC）、可信平台模块（TPM）、图形处理器（GPU）、网卡（NIC）、硬盘驱动器（HDD）、固态硬盘（SSD）、只读存储器（ROM）、闪存 ROM 等。
设备固件：仅用于某个特定设备的非宿主处理器固件和扩展 ROM 固件的组合。此固件通常由设备制造商提供。
扩展 ROM 固件：用于指代在宿主处理器上执行的、被扩展设备在启动过程中所使用的固件的外设元件互连标准（PCI）术语。这包括 Option ROM 固件、UEFI 应用程序和 UEFI 驱动程序。扩展 ROM 固件可以作为宿主处理器启动固件的一部分而捆绑，也可以是独立的（例如来自扩展卡）。在此文档中，我们在一般性地指代 Option ROM 固件或者 UEFI 驱动程序和应用程序时使用扩展 ROM 固件这一术语。
固件：用于描述存储于芯片中的任何代码的通用术语，这些代码要么驻留于对应处理器的重置向量（或者等价物），要么作为其他固件的扩展而提供（诸如扩展 ROM 固件）。存储于芯片中的通用目的操作系统在此文档的范围中一般不被看作固件。
宿主设备：辅助共生设备建立满足此文档中的保护、检测和/或恢复指导意见所必需的可信根和信任链的设备。宿主和共生设备之间的功能分配取决于实现。宿主设备自身必须独立满足对其固件的指导意见。注意，这不应该同宿主处理器相混淆。宿主处理器可以作为宿主设备，但是宿主设备不一定是宿主处理器。
宿主处理器：宿主处理器是平台中的主要处理单元，在传统上称为中央处理器（CPU），现在有时也被称为应用处理器（APU）或者系统芯片（SoC）。这是主操作系统（和/或虚拟机监视器）以及用户应用程序所在其上运行的处理单元。这是负责加载并执行宿主处理器启动固件的处理器。
宿主处理器启动固件：用于描述由宿主处理器加载并且执行、为平台提供基本启动能力的固件的通用术语。此类固件包括传统 BIOS、系统 BIOS 和 UEFI，以及其他实现。在传统 BIOS 和 UEFI 之间的区别并不重要的情况下，将会使用宿主处理器启动固件这一术语。在这种区别至关重要的情况下，将会根据实际情况进行指代。扩展 ROM 启动固件也可以被看作宿主处理器启动固件的一部分。扩展 ROM 固件可以被作为宿主处理器启动固件的一部分而嵌入，也可以是独立于宿主处理器启动固件的（例如从扩展卡加载）。宿主处理器启动固件包括可能在运行时可用的固件。
不可变的：不可发生更改的。在此文档的上下文环境中，这仅仅指代不能在现场通过制造商本意中的机制和/或限定的接口进行更改。注意，平台或者设备制造商可能仍然能够通过直接连接到本地（物理）存在的平台或者设备的生产或者服务工具来作出更改。
传统 BIOS（基本输入/输出系统）：用于使用传统 x86 BIOS 架构的 x86 平台的一种宿主处理器启动固件形式。这种形式的宿主处理器启动固件已经或者正在被 UEFI 取代。
可变的：可发生更改的。在此文档的上下文环境中，这仅仅指代能够在现场通过制造商本意中的机制和/或限定的接口进行更改。这样的机制可能要求密码学机制或者无歧义的物理存在。
非关键数据：非关键数据是在加电循环之间持续存在，但是对于设备的启动、运作或者恢复并不具有决定性的可变数据。
非宿主处理器：非宿主处理器是用于描述平台上的任何不是宿主处理器的处理单元（例如微控制器、协处理器等）的通用术语。
非宿主处理器固件：非宿主处理器固件是用于描述被平台上的任何不是宿主处理器的处理单元所使用的固件的通用术语。
Option ROM 固件：用于通常在宿主处理器上执行、在启动过程中被设备使用的启动固件的传统术语。Option ROM 固件可以被包括在宿主处理器启动固件中，也可以由设备（例如扩展卡）独立提供。
外设（又称为外部设备）：外设（又称为外部设备）是物理存在于平台外部并且通过有线或者无线的方式连接到平台的设备。外设由其自身设备构成，它们可能拥有其自身的固件。尽管此文档中的原则和知道意见在概念上也可以同等程度地适用于外设，它们不属于此文档的范围之中。
平台：平台由被组装起来共同工作以带来某种特定计算功能的一个或者多个设备所组成，但是并不包含作为平台中的设备的一部分的固件以外的任何其他软件。平台的范例包括笔记本、台式机、服务器、网络交换机、刀片等。
平台管理员权限：管理平台设备中的固件和关键数据所必需的权限。特别地，这种权限可能是授权固件更新、更改固件配置设置，以及固件恢复操作所需要的。
平台管理员：拥有平台管理员权限的实体。
平台固件：平台上的所有设备固件的组合。在此文档中，平台固件这一术语可以被用于指代平台上所有被设备所使用的固件的组合。
主固件镜像：存储于设备上的可执行代码。主固件镜像的不同部分可以通过不同方式保护。
只读存储器（ROM）：一旦经过初始设置，就不能通过任何机制重写的存储器设备，使得该存储器成为不可变（不可更改）的。
具有弹性的：具有特定性质的系统在干扰发生之前、之中和之后吸收该干扰、恢复到某种可接受的性能级别，并且维持该级别达到一段可接受的时间的能力。
可信根（RoT）：构成了提供一项或者多项安全特定功能，诸如测定、存储、报告、恢复、验证、更新等的基础的元素。RoT 被信任为总是以预期的方式运作，由于它的不当行为不能被检测到，以及它的恰当运作对于提供其安全特定功能至关重要。
运行时固件：用于描述平台上的任何在运行时（在启动完成之后）活动/起作用或者可用的固件的通用术语。
软件：软件由加载操作系统、操作系统和随后由操作系统处理的所有用户应用程序和用户数据所必需的元素构成。参见图 1 以获得图形描述。
共生设备：共生设备是完全或者部分依赖另一个设备（宿主设备）以建立为符合此文档中的保护、检测和恢复指导意见所必需的可信根和信任链的设备。宿主设备和共生设备之间的功能分配取决于实现。例如，宿主设备验证更新并且备份关键数据，而共生设备负责满足所有其他指导意见。共生属性可以具有传递性：一个设备可以是一个宿主设备的共生设备，而这两个设备可以随后作为另一个共生设备的宿主设备，等等。
系统：系统是计算实体的整体，包括平台（硬件、固件）和软件（操作系统、用户应用程序、用户数据）中的所有元素。系统可以被看作逻辑构造（例如软件栈）或者物理构造（例如笔记本、台式机、服务器、网络交换机等）。参见图 1 以获得图形描述。
UEFI（统一可扩展固件接口）：使用统一可扩展固件接口（UEFI）架构（如同 UEFI 论坛所定义）的一种宿主处理器启动固件形式。
UEFI 驱动程序：在启动过程中加载以处理特定硬件部分的独立二进制可执行文件。
无歧义的物理存在：由不能被恶意软件伪造的本地人员指示授权。

附录 C——参考文献

[1] D. Cooper, W. Polk, A. Regenscheid, and M. Souppaya, BIOS Protection Guidelines, NIST Special Publication (SP) 800-147, National Institute of Standards and Technology, Gaithersburg, Maryland, April 2011, 26pp. https://doi.org/10.6028/NIST.SP.800-147
[2] A. Regenscheid., BIOS Protection Guidelines for Servers, NIST Special Publication (SP) 800-147B, National Institute of Standards and Technology, Gaithersburg, Maryland, August 2014, 32pp. https://doi.org/10.6028/NIST.SP.800-147B
[3] Specifications, Unified Extensible Firmware Interface Forum [Web site], http://www.uefi.org/specifications [accessed 5/2/18]
[4] TPM Library Specification, Trusted Computing Group [Web site], https://trustedcomputinggroup.org/tpm-library-specification/ [accessed 5/2/18]
[5] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, Internet Engineering Task Force, March 1997, 2pp, https://doi.org/10.17487/RFC2119
[6] U.S. Department of Commerce. Secure Hash Standard, Federal Information Processing Standards (FIPS) Publication 180-4, August 2015, 36pp. https://doi.org/10.6028/NIST.FIPS.180-4
[7] U.S. Department of Commerce. Digital Signature Standard, Federal Information Processing Standards (FIPS) Publication 186-4, July 2013, 130pp. https://doi.org/10.6028/NIST.FIPS.186-4
[8] E. Barker, Recommendation for Key Management, Part 1: General, NIST Special Publication (SP) 800-57 Part 1 Revision 4, National Institute of Standards and Technology, Gaithersburg, Maryland, January 2016, 160pp. https://doi.org/10.6028/NIST.SP.800-57pt1r4
[9] E. Barker, Recommendation for Obtaining Assurances for Digital Signature Applications, NIST Special Publication (SP) 800-89, National Institute of Standards and Technology, Gaithersburg, Maryland, November 2006, 38pp. https://doi.org/10.6028/NIST.SP.800-89
[10] International Council for Systems Engineering, “Resilient Systems Working Group Charter,” November 2011.
[11] R. Ross, R. Graubart, D. Bodeau, and R. McQuaid, Systems Security Engineering: Cyber Resiliency Considerations for the Engineering of Trustworthy Secure Systems, NIST Special Publication 800-160 Volume 2 (DRAFT), National Institute of Standards and Technology, Gaithersburg, Maryland, March 2018, 158pp. https://csrc.nist.gov/CSRC/media/Publications/sp/800-160/vol-2/draft/documents/sp800-160-vol2-draft.pdf