Hardened GNU/Linux

We are a group of free software enthusiasts, anarchists, cyber security researchers. Long live anarchy! Long live 0ld sch00l!!! A small step in security hardening --> A giant leap in Free & Open source software!!!

NIST SP 800-155: BIOS 完整性测定指南

Post on

美国商务部国家标准技术研究所 特别出版 800-155（草案）

BIOS 完整性测定指南（草案）——美国国家标准技术研究所的建议

Andrew Regenscheid 和 Karen Scarfone 著

计算机安全分部，信息科技实验室，美国国家标准技术研究所，盖瑟斯堡，马里兰州 20899-8930，2011 年十二月

美国商务部 秘书 John Bryson

美国国家标准技术研究所 标准技术次长和主任 Patrick D. Gallagher 博士

计算机系统技术报告

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

美国国家标准技术研究所 特别出版 800-155（草案），47 页（2011 年十二月）

此文档中可能会提到某些商业实体、设备或器材，以便完整地描述一种实验过程或概念。这样的提名的本意并非暗示美国国家标准技术研究所对其的推荐或认可，也不是为了暗示该实体、器材或设备一定是可用于其目的之最佳选择。

致谢

作者想要感谢那些审阅了此文档草案并且为其技术内容作出贡献的同事。特别地，作者想要感谢来自 Wave Systems 的 Greg Kazmierczak 和 Robert Thibadeau 以及来自 Citrix 的 Kurt Roemer，他们为此文档的早期草案提供了有益的评论和反馈。我们还想要感谢 NIST 的那些审阅了此文档早期草案的同事，包括 Bill Burr、Donna Dodson、Tim Polk、Matthew Scholl、Murugiah Souppaya 和 David Waltermine。

摘要

此文档概述了建立安全的基本输入/输出系统（BIOS）完整性测定和报告链所需的安全组件和安全指导意见。对 BIOS 固件的非授权修改构成了一种重大威胁，由于 BIOS 在 PC 架构中的独特和特权的地位。此文档专注于两种场景：检测存储于系统闪存中的系统 BIOS 代码的更改；以及检测系统 BIOS 配置的更改。此文档本意用于开发能够支持安全 BIOS 完整性测定机制的产品的硬件和软件厂商，并且对于开发关于这些技术的企业采购或者部署策略的组织机构可能也会适用。

商标信息

所有商标或者注册商标属于其各自的组织机构。

执行摘要

诸如台式机和笔记本等客户端计算机依赖基本输入/输出系统（BIOS）以便在启动过程中初始化其硬件。BIOS 是固件，并且它可以被配置。如果 BIOS 代码或者配置从其本意中的状态被更改，不论是恶意或者无意，此台式机或者笔记本可能会失去可靠性、完整性和可用性，并且会带来系统不稳定性、系统故障和信息泄露。同时，此台式机或者笔记本可能易受更加精心设计的攻击，诸如隐秘监视，并且这可以用作攻击其他系统的基石。这些后果强调了检测针对 BIOS 代码和配置的更改为何如此重要——并且这可以通过测定并且监视 BIOS 的完整性而实现。

此出版物解释了 BIOS 完整性测定的基础，诸如为了测定 BIOS 完整性而必须满足的基本要求，以及用于 BIOS 完整性测定和报告的典型数据流。这些素材为此文档的核心内容提供了基础，此文档为那些开发能够支持安全 BIOS 完整性测定机制的产品的硬件和软件厂商提供了指导意见。这些指导意见详细地定义了厂商为了支持 BIOS 完整性测定所需遵循的要求和建议。

以下内容是关于厂商支持 BIOS 完整性测定的关键要求和建议。注意，对于这些要求和建议的正式声明出现于第 3 章；以下这些是它们的总结，并且不能取代第 3 章的更加详细的声明。

为实施用于 BIOS 完整性测定的可靠的可信根提供必要的硬件支持

可信根是构成一系列被无条件信任的功能的组件（软件、硬件，或者混合）和计算引擎。可靠和可信的 BIOS 完整性测定和报告依赖于软件代理；每种软件代理依赖可信根，并且每种代理的可信度级别取决于它的可信根。BIOS 完整性测定要求以下代理之间的协作：一个测定代理用于收集测定数据、一个存储代理用于保护测定数据以防止修改，直到它们可以被报告，以及一个报告代理用于可靠地报告此测定数据。这些代理中的每一个都拥有一个对应的可信根（测定可信根，等等）。这些可信根必须一致行动并且相互基于对方构建以实现可靠和可信的测定、报告以及对于 BIOS 完整性测定的验证。

使得终端机能够在启动时测定所有 BIOS 可执行组件和配置数据组件的完整性

有意义的完整性测定比较方案中的一个关键因素是可靠地建立并且维护一组属性和测定数据的已知基线。终端机厂商有多种方式以将属性传达给用户；不论这是如何实现的，这些属性存在的原因是为了向用户提供一种方式以评估由终端机报告的 BIOS 完整性测定数据的有效性，以及在它所接收到的关于终端机的总体健康状况的报告中开发一种可靠度级别。此出版物定义了终端机厂商必须提供的属性以及所有终端机都必须能够报告的最小基本 BIOS 完整性测定数据。

将 BIOS 完整性测定数据安全地从终端机传输到测定评估权威机构（MAA）

当测定数据被可靠地和稳固地报告时，MAA 可以准确地确定每台终端机上的与安全相关的 BIOS 配置项目的状态。这允许 MAA 对组织机构所关注的项目进行汇报或者采取行动。BIOS 完整性测定数据的安全传输保证了测定数据在传输过程中并未被恶意相关方修改、泄露或者非法复制。更进一步地，适当选择传输协议应该能够保证最大的可互操作性、新鲜度和效率。

第 1 章 简介

1.1 权力范围

美国国家标准技术研究所（NIST）开发此文档以履行其在 2002 年美国联邦信息安全管理法案，公法 107-347 下的法定责任。

NIST 负有开发标准和指导意见，包括最低要求的责任，以便为所有政府机构的运作和财产提供足够的信息安全；但是，这些标准和指导意见不会适用于国家安全系统。此指导意见与美国行政管理和预算局（OMB）的公告 A-130 第 8b(3) 节“防护政府机构信息系统”相一致，如同在 A-130 的附录 IV“关键章节分析”中所分析的那样。补充信息在 A-130 附录 III 中提供。

此指导意见为联邦政府机构而准备。它可以在自愿基础上被非政府组织使用，并且不受限于版权，尽管我们要求署名权。

此文档中的任何部分都不应该被带到由美国商务部秘书在法定权力之下规定为对于联邦政府机构具有强制性和法定约束力的与之相矛盾的标准中来，这些指导意见也不应该被解读为更改或是取代商务部秘书、OMB 主任或是任何联邦官员的现有职权。

1.2 目的和范围

此文档概述了建立一条安全的基本输入/输出系统（BIOS）完整性测定和报告链所需的安全组件和安全指导意见。BIOS 是系统中的关键安全组件，由于它在个人计算机（PC）架构中的独特和特权的地位。恶意或者老旧的 BIOS 可能会允许或者成为针对组织机构的高级攻击的一部分——可以是永久的拒绝服务（如果 BIOS 损坏）或者是持久的恶意软件存在（如果 BIOS 被植入恶意软件）。

此文档在 2.1 节标识出了关于此文档中的指导意见的两种激励场景。其一，BIOS 完整性测定机制的本意是为了检测存储于系统闪存中的系统 BIOS 代码发生的更改。针对系统 BIOS 代码的非授权更改可能会允许恶意软件在启动过程中被执行。其二，这些机制的本意是检测系统 BIOS 配置发生的更改。非授权的 BIOS 配置更改可能将系统置于不安全的配置之中，使其易受攻击。

此文档中的指导意见的本意是辅助开发那些能够检测 BIOS 问题的产品，以使得组织机构能够实施适当的补救措施以防止或者限制伤害。此文档中具体说明的安全控制和过程面向部署于企业环境中的台式机和笔记本。

尽管此出版物专注于用于 BIOS 完整性测定产品的安全属性和能力，它也会为组织机构中的管理员和安全官员提供关于这些类型的产品所能提供的担保以及那些当此技术被部署时需要被整合进系统采购和管理过程的程序的更好的理解。此文档中的指导意见仅可通过贯穿于组织机构的信息科技基础设施的硬件和软件支持的组合来实现。这包括终端机设备上的用于获取和报告测定数据的支持性的可信根和安全软件、对于企业级管理系统的测定数据的请求和解读的支持，以及对于网络设备的潜在支持以化解问题。这些组件将会成为 BIOS 完整性测定系统中的关键元素。

1.3 受众

此文档本意中的受众包括开发那些能够支持 BIOS 完整性测定机制的产品的硬件和软件厂商。这包括终端机厂商，通常是原始设备制造商（OEM）、操作系统（OS）厂商，以及安全应用软件厂商。系统管理员和信息系统安全专业人士也可以查询此文档以理解这些产品以及那些在部署这些技术时需要被整合进他们的系统管理过程中的程序的能力。

此文档中的素材是面向技术的，并且它假设读者至少拥有对于系统和网络安全的基本理解。此文档提供了背景信息，以帮助这些读者理解所讨论的话题。我们鼓励读者利用其他资源（包括列出于此文档中的）以获取更多细节信息。

1.4 文档结构

此文档的剩余部分被组织进以下的主要章节和附录中：

  • 第 2 章呈现了关于 BIOS 完整性测定及其在企业中的操作环境中检测针对 BIOS 的攻击的作用的概述
  • 第 3 章描述了测定 BIOS 完整性所必需的组件以及针对每个组件所建议的安全指导意见
  • 附录 A 包含关于系统 BIOS 完整性测定实现的安全指导意见的总结
  • 附录 B 定义了此文档中所使用的首字母缩略词、缩略语和用语
  • 附录 C 标识了参考文献
  • 附录 D 包含关于一家公司可以如何选择以实施可信根的一系列范例
  • 附录 E 包含关于一家公司可以如何选择以利用现存能力来实施这些指导意见的一系列范例

1.5 文档惯例

此文档中的关键字 MUST（必须）、MUST NOT（必须不）、REQUIRED（要求）、SHALL（将要）、SHALL NOT（将不要）、SHOULD（应该）、SHOULD NOT（不应该）、RECOMMENDED（建议）、MAY（可以）和 OPTIONAL（可选）等应当按照征求意见稿（RFC）2119 [IETF-RFC-2119] 中所描述的方式来解读。如果这些词语以常规大小写形式出现，例如 should（应该）或者 may（可以），它们本意上不需要作为 RFC2119 关键字来解读。

在此出版物中，将要求指认为 MUST/SHALL（必须/将要）、SHOULD（应该）和 MAY（可以）等的判据如下：

  • MUST/SHALL（必须/将要）：需要这些要求以支持于第 2 章所概述的场景，AND（并且）它们对于当前可用的技术而言在短期内是可行的
  • SHOULD（应该）：这些能力是非常值得拥有的，并且可能在某些情况下需要，以支持某种特定操作需求或者强壮度级别
  • MAY（可以）：可选的要求，它们在某些情况下可能是理想的。

第 2 章 背景

诸如台式机和笔记本等客户端计算机包含用于辅助硬件初始化过程的程序代码。这些代码存储于非易失性存储器中，并且通常称为 启动固件。用于初始化系统的首要固件称为 基本输入/输出系统（BIOS）或者 系统 BIOS。如果 BIOS 从它的预想状态发生更改，不论是恶意还是无意，它所发生更改的设备可能会对组织机构产生负面影响，由于该设备不一定是以其预想状态运行的。可能的结果包括系统不稳定、系统故障、信息泄露，或是其他可靠性、完整性和可用性的丧失。此外，此系统可能易受更加精妙的攻击，诸如隐秘监控，并且攻击者可以将此系统用作攻击其他系统的基石。这些范例解释了为何通过测定和监测其完整性以检测针对 BIOS 及其配置的更改如此重要。

本章提供了关于 BIOS 完整性测定（BIM）的概述及其在组织机构检测、报告和化解操作环境中的针对 BIOS 的攻击中的作用。本章标识出了完成此任务所要求的主要组件并且对这种方法论所能解决的威胁进行了描述。

2.1 BIOS 完整性测定场景

本节呈现了那些定义了候选应用案例的场景，这些场景将会引导要求和建议在此文档的剩余部分中的呈现。这些应用案例用作识别用户操作、相关通讯、内在风险以及潜在的安全防护的基础。

这些场景基于 IT 组织机构在 BIM 领域的客观状态和过程成熟度。在很大程度上，这种客观状态近似地反映出了众多组织机构当今在终端机的补丁管理领域所使用的最佳实践。具体地，组织机构可以期望对于新的终端机实施这样一种供货过程，在这里，BIM 被完全整合进此模型中。例如，供货一台终端机将会包含这些额外的与 BIOS 完整性具体相关的活动，这些活动可以与现存的镜像、财产跟踪以及注册活动等互补。

  • 为一台给定的客户端安装并且/或者验证正确的 BIOS 修订版本
  • 利用适当的 BIOS 设置对该 BIOS 进行镜像
  • 设置 BIOS 口令
  • 主张任何要求物理存在的安全控制（可能包含可信平台模块（TPM））
  • 将此终端机的身份和完整性度量注册到相关的 IT 数据库

这些安全变量中的任何更改可能提示一种异常状态，以及潜在地更具危险性的效应。当今存在的客户端操作系统代理在网络管理层上报告关于这些设置的基本信息，并且它们是用于评估 BIOS 安全状态的良好的初始工具。然而，每当可能时，这些报告代理需要立即被迁移到依赖于植根于防破坏的可信根的完整性基础设施上来。

2.1.1 场景 1：系统 BIOS 发生某些更改

针对客户端计算机的 BIOS 更新频繁发布。这些更新通常修复电源管理子系统、硬盘或网络管理，或者其他重要组件中的 bug。然而，BIOS 也可能出于恶意目的被修改。系统管理员能够分辨哪种版本的 BIOS 在一台设备上被加载以便能够正确地管理它是至关重要的。这必须在面对如下基本挑战的同时完成：

  • IT 管理部门必须能够信任所采集到的 BIOS 固件测定数据是正确的
    • 需要有一个可信根以信任 BIOS 固件完整性测定数据的采集
    • 关于 BIOS 固件的完整性测定数据的有效初始基线必须被采集，可以潜在地使用该设备的可信根以采集并报告基线测定数据
    • BIOS 固件完整性测定数据必须是可证明地新鲜的（其响应不能仅仅是某次较早的正确响应的重放）
    • BIOS 固件完整性测定数据必须拥有可证明的完整性（它在响应者和接收者之间未被更改）
    • BIOS 固件完整性测定数据的来源必须被确定（它来自 IT 部门所认为它来自的地方）
  • IT 管理部门必须能够解读被报告的 BIOS 固件完整性测定数据
    • 标准格式至关重要
    • 需要考虑系统的多样性
  • 用户和管理员必须能够知道 BIOS 在何时发生更改，而无需徒手进行庞杂的计算。

2.1.2 场景 2：BIOS 配置设置发生某些更改

BIOS 设置对于系统安全性具有重大影响，需要回答的关于设置的部分问题列表包括：

  • 口令
    • 管理员口令是否被设置？
    • 开机口令是否被设置？
    • 硬盘口令是否被设置？
  • 基于 BIOS 的管理（BBM）软件
    • 是否被启用？
    • 基于 BIOS 的管理软件的配置是什么？
  • 启动
    • 启动顺序是否发生更改？
    • 计算机是否会从除硬盘外的任何位置启动？
  • 端口和其他硬件接口
    • USB 端口是否被启用？
    • 1394 端口是否被启用？
    • PCMCIA 或者智能卡读卡器是否被启用？
    • 近场通讯（NFC）端口是否被启用？

这些设置发生的任何更改可能指示系统已经变得不那么安全，或者已被攻击。与第一种场景类似，用户和管理员都能确定 BIOS 设置是什么以及它们是否符合策略是至关重要的。此文档要求那些允许管理员辨别 BIOS 配置设置是否被更改的能力，并且鼓励使用那些允许管理员区分哪些设置被更改的能力。

识别 BIOS 配置更改要求以下能力，与识别 BIOS 代码更改所需的能力类似，但是对其进行了扩展：

  • IT 管理部门必须能够信任 BIOS 配置的完整性测定数据是正确的
    • 需要有一个可信根以信任 BIOS 配置的完整性测定数据
    • 测定数据必须是可证明地新鲜的
    • 测定数据必须拥有可证明的完整性
    • 测定数据的来源必须被确定
  • IT 管理部门必须能够解读响应
    • 标准格式至关重要
    • 需要考虑系统的多样性

2.2 BIOS 完整性测定流

为了测定 BIOS 的完整性，某些基本要求必须被满足，它们包括：

  • 生成并采集测定数据的方法
  • 存储测定数据的方法，它要么是能够抵抗破坏的，要么是能够使破坏显而易见的
  • 将测定数据传输到分析代理的方法
  • 分析测定结果的方法，以及基于此测定结果管理一台设备的方法

终端机设备必须拥有能够测定 BIOS 固件并且将这些测定数据转发至管理权威机构的方法。此终端机必须在执行此任务的同时保护这些测定数据的完整性、合法性、不可抵赖性，以及在某些情况下还有机密性。

图 1 显示了支持 BIM 的生成、转发、分析，以及基于此分析的补救行为的架构。这些解决方案可以由单一厂商提供，或者由多家厂商联合提供。在终端机上，用于测定、存储和报告的可信根构成了提供必要的安全服务的基础。3.1 节将会在更深的层次上涵盖可信根。

图 1：BIOS 完整性架构

BIOS 代码和配置数据代表测定目标。测定数据生成和报告代理作用于测定目标并且直接撬动可信根以便为每一次测定以及测定和报告过程提供安全防护。3.2 和 3.3 节为测定和与之关联的过程提供了更多见解。采集和传输代理提供了一种方法以可靠地采集测定数据并且将其传输至测定数据评估权威机构（MAA）以进行进一步分析。3.4 和 3.5 节讨论这些代理的功能。3.6 节讨论的恢复代理为管理权威机构提供了一种方法以采取行动来修复通过 BIOS 测定数据分析在终端机上发现的任何问题。

在评估测定数据时，MAA 参考一组特征。这些特征集合分为两类：要么是终端机属性和 BIOS 代码的测定数据，它们由原始设备制造商（OEM）、增值分销商（VAR）或者独立软件厂商（ISV）提供并且担保（利用证书），要么是配置设置的测定数据，它们由终端机的用户/管理员在该终端机的最初供货阶段采集，或者由 MAA 采集。理想的测定数据特征的集合称为 黄金测定数据。

MAA 可以托管若干种服务，诸如管理控制台或者一种提供简易用户界面以分析 BIOS 属性和测定数据的控制面板，以允许管理员或者分析者快速确定以下方面：

  • 终端机设备的报告的可信度
  • 设备是否符合要求（与当前的一套黄金测定数据相匹配）
  • 设备是否需要恢复（BIOS 设置不符合要求，或者正在使用老旧的黄金测定数据）
  • 设备是否潜在地具有危险性（某些测定数据已知能够指示恶意活动）

基于这些报告，设备可以被允许或者拒绝访问资源（例如，允许访问网络资源、允许受限访问网络资源，诸如恢复网络，或者拒绝访问），这些报告也可触发其他管理行为。

图 1 描述了 BIOS 完整性测定和报告的典型数据流：

  1. 获取一套初始的可信测定数据（黄金测定数据）。这些测定数据要么由第三方（例如 OEM）向 MAA 提供，要么由系统管理员在初始供货时生成
  2. 在终端机的启动过程中，在植根于测定可信根（RTM）的信任链中由固件对 BIOS 固件及其配置设置进行一系列测定。RTM 存储这些测定数据的散列值表征，这些测定数据由存储可信根（RTS）存储或保护。一段可以根据它重建这些测定数据的日志存储于内存中的某处，以使得传输代理可以重建这些测定数据
  3. 作为对终端机请求服务或者 MAA 请求行为的响应，MAA 生成一次测定请求，包含一个临时随机数。传输代理接收此请求，确定它属于 BIOS 完整性测定，并且因此将其传输至采集代理
  4. 采集代理对请求进行语法检查，并且将临时随机数传输至报告代理，后者利用报告可信根（RTR）以获取此临时随机数的签名以及所存储的测定数据的散列值表征
  5. 报告代理将此数据（连同从内存中获取的日志）传输回采集代理
  6. 采集代理将此数据格式化为标准格式，并且将其传输回传输代理
  7. 传输代理将此数据传输至 MAA 的验证代理
  8. 验证代理验证散列值的签名，通过验证用于签名这些散列值以及签名本身的公钥，以及验证报告中包含的临时随机数与测定请求中发送的临时随机数匹配。它随后将这些签名的测定数据与它早先获取的黄金测定数据进行比较
  9. 在这种比较的结果与来自其他设备的类似比较结果相核对之后，可以将其通过某个用户界面（诸如管理控制台或者控制面板）显示给管理员并且/或者提供给某个自动化的强制执行/访问点
  10. 如果此结果被提供给某个自动化的强制执行/访问点，管理员或者其代理随后根据比较的结果作出决定，这可能是允许或者拒绝网络访问、发送信号至恢复代理，或者也可能是派遣一位服务技术人员到该设备以确定得到错误结果的原因。

2.3 过渡到理想状态

对于 BIM 的理想或者客观状态，BIOS 测定是程式化和自动化的客户端扫描的一部分。随着组织机构从它们当今所处的状态逐步进步到理想状态，必须迈出若干步骤。最初，这些测定数据只会随着其他客户端健康数据一同采集和存储。这些数据随后将会在常规的基础上被审阅和分析，以开发出一种关于组织机构内部的客户端 BIOS 的基线行为的理解。随着控制面板套件和其他操作工具被更新以便将 BIOS 完整性信息整合为第一级数据，用于 BIM 的附属活动和责任可以被移交给标准 IT 操作团队。随着时间进展，这又会简单地成为 IT 服务的另一个标准职位。

第 3 章 BIOS 完整性测定中的功能组件

下列章节为 BIM 的功能组件提供了描述以及与之相关的要求的指导意见：

  • 3.1 节探讨可信根（RoT）
  • 3.2 节定义了 BIOS 完整性属性和测定数据基线的建立
  • 3.3 节探讨 BIOS 完整性报告
  • 3.4 节定义了 BIM 数据的采集及其传输至 MAA 的过程
  • 3.5 节描述并定义了对 MAA 本身的要求
  • 3.6 节探讨了基于所采集和传输的测定数据和属性的潜在恢复行动

3.1 可信根（RoT）

可信根（RoT）位于任何 BIOS 完整性担保的基础地位。RoT 是构成一组被无条件信任的功能的组件（软件、硬件，或者混合）和计算引擎，并且必须总是以一种期望中的行为方式运作，由于它们的非正常行为不能被检测到。它们对于 BIOS 完整性测定尤其重要，由于 BIOS 在大体上负责软件执行环境的配置，包括物理内存和设备的映射。

撬动一个或更多的 RoT 的软件代理的可信度取决于 RoT 本身的可信度及其攻击面。全套的 RoT 至少拥有最小的一组能力以允许测定、存储并报告终端机的那些影响其可信度的特征。硬件 RoT 优于软件 RoT，由于它被发现能够在高得多的比例的攻击场景中以某种期望中的方式运作。

可靠和可信的 BIOS 完整性测定和报告取决于软件代理以执行那些验证者所必须依赖的功能。每个软件代理都依赖 RoT，并且代理的可信度级别取决于它的 RoT。任何软件代理的 RoT 是这样的一些计算引擎，它们要么能够可靠和准确地执行该代理的功能，要么负责产生可靠的软件代理以执行此任务。因此，某个代理可以被完全实现于 RoT 内部，或者可以通过一条植根于 RoT 中的信任链由它的 RoT 生成。因此，代理的可信度取决于它所对应的 RoT 以及信任链。

BIOS 完整性测定的最高担保机制提供可变状态容错，在此，此机制能够提供关于 BIOS 及其配置的可靠和可信的报告，而不论设备的总体配置或者 BIOS 存储设备的内容如何。此外，BIOS 完整性测定的最高担保机制提供内存泄露容错，在此，由此机制报告的测定数据必须是可证明地新鲜的（即最近采集的，一般是由于某次具体的请求），并且没有被任何相关方伪造，即使他们完全知道在所有过去的软件执行过程中曾经存在于软件可读内存中的全部内容。因此，这样的机制对于针对软件漏洞的利用更加强壮，并且不会受到存在于软件可读内存中的密码学密钥的泄露的影响。

3.1.1 软件代理概述

BIM 需要以下组件的协作：一个测定代理用于收集测定数据、一个存储代理用于保护测定数据不被修改，直到它们可以被报告，以及一个报告代理用于可靠地报告这些测定数据。如果测定数据是在收集之后立即报告的，可能并不需要使用存储代理。保证 BIOS 完整性的完备的系统还会包含对于所采集到的测定数据的某种形式的验证功能，这相应地需要使用验证代理以评估被报告的测定数据。这样的验证代理可以驻留于被测定的终端机上，或者位于管理服务或者基础设施外部。此外，如果任何软件代理可以被修改或者更新，那么这些代理的可信度取决于用于实现这些更新的机制。因此，如果这样的更新是可能的，此终端机应该包括更新代理以便以某种可靠的方式来实施软件更新，以提供相当于 [NIST-SP800-147] 中的保护。

3.1.2 可信根概述

测定可信根（RTM）是一种能够进行内在地可靠的完整性测定的计算引擎。它是后续的测定代理的传递性的信任链的根基。在终端机重新初始化之后很快被应用的小型 RTM 可能比之后被实例化的 RTM 拥有更大价值，这主要在于使得测定过程暴露给破坏行为的攻击面最小化。终端机调用 RTM 越晚，对手所拥有的破坏测定信任链的机会就越大。而 RTM 越大，其实现中存在能够为对手提供机会以破坏 RTM 的瑕疵的机会就越大。

存储可信根（RTS）是一种计算引擎，它能够维持一种使得破坏显而易见的，关于完整性测定值以及这些测定的序列的总结。它并不包括完整性测定序列的细节，而是存储这些序列的完整性散列值。这些完整性散列值可以被用于验证一段包含完整性测定值和这些测定序列的日志的完整性，或者被用于该日志的指标。RTS 在使得破坏显而易见的位置存储这些完整性散列值，例如，其接口可能允许寄存器扩展（定义于 3.2.2.2 节），但不允许直接寄存器写入。这些授权的接口通常称为 受保护的能力。使破坏显而易见的位置和受保护的能力共同构成了 RTS。

报告可信根（RTR）是一种计算引擎，它能够可靠地报告由 RTM 及其测定代理提供或者由 RTS 存储的信息。RTR 作为测定数据报告的完整性和不可抵赖性的能力的基础，它必然会撬动 RTM 和 RTS。对于 RTR 的关键要求之一是终端机以及正在被测定和报告的组件的无歧义的身份，这种身份可以是持久或者临时的。对测定报告数据利用密钥签名是一种常见的机制以提供无歧义的身份。密钥的证书可以认证组织的成员身份或者识别某个特定成员。

3.1.3 代理的协作

所有相关代理共同协作的可信度为验证代理对被测定的终端机的 BIOS 完整性进行可靠的评估提供了保证。对由组合系统提供的信任属性进行评估是至关重要的，而对单个代理的信任属性的评估仅在整个系统的上下文环境中才是相关的。

图 2 展示了各个 RoT 必须协同作用并且彼此基于对方构建以允许对 BIM 数据进行可靠和可信的测定、报告和验证。此外，这些 RoT 必须适当地整合完整性保护和安全 BIOS 更新认证的机制。这些 RoT 以及其他终端机安全性机制的实现可以通过集成式的方式，在此，它们都由单一的软件组件，诸如 BIOS 构成。不论此实现是整体式的还是分散式的，这些 RoT 的组合以及它们所基于其构建的 RoT 的组合构成了完整的 BIM 解决方案的可信度的基础。

图 2：RoT 和代理的协作

3.1.4 可信根的安全指导意见

  1. 终端机厂商将要提供实施可信的 RTM、RTS 和 RTR 所必需的硬件支持，并且利用该支持为 BIM 实现对应的 RoT
  2. 终端机厂商将要整合 RTM、RTS 和 RTR 的机制以形成集成式的、可靠的 BIM 基础
  3. 终端机厂商应该为受到完整性保护的，不可绕过的认证或者安全 BIOS 更新实现提供机制，如同符合 [NIST-SP800-147] 所必需的
  4. 终端机厂商可以为实现用于启动时之后的测定的可信的动态 RTM 提供硬件支持。终端机厂商和操作系统厂商可以利用此支持为 BIM 实现这样的 RoT。

3.2 完整性属性和测定数据的基线

有意义的完整性测定数据比较方案中的一个关键因素是可靠地建立并维持一组关于属性和测定数据的已知基线，以使得人们可以利用它进行决策。基线的建立必须考虑两种场景：具有未知或者可疑来源的 BIOS 的终端机设备，以及具有已知和可信（受保护和签名）的 BIOS 的终端机设备。本节列举了用于基线的属性和测定数据。

3.2.1 BIOS 完整性属性概述

属性被用于评估 BIOS 完整性测定数据的可信度。终端机厂商拥有多种方式将属性传达给用户。终端机厂商可以将这些属性连同黄金 BIOS 测定数据放在证书中，通过带外通讯信道（即并非利用终端机本身传达，而是通过其他方式）呈现给用户。终端机厂商可以允许用户直接查询此终端机并且提取属性。或者，终端机厂商可以允许用户将序列号提交至受管理的在线客服，后者以该终端机在送达时的属性的列表作为响应。无论用户如何获取某一特定终端机的属性，这些属性存在的理由是为用户提供一种方式以评估由终端机报告的 BIM 数据的有效性，以及在其接收到的报告中开发一种可信度级别，关于该终端机的仅存于 BIM 数据以外的总体健康状况。

3.2.1.1 BIOS 完整性属性列表

本节列举了 BIOS 完整性属性并且提示它们的可能的值。

  1. RTM——RTM 的属性提供了关于在 BIOS 测定发生之前可供对手利用的时间/代码量的信息，通常被称为攻击面的大小。终端机能够越早地撬动 RTM 并且进行 BIOS 测定，攻击面就越小，并且评估者能够在其测定数据中拥有更高的可信度。反之，在进行 BIOS 测定之前，终端机在初始化或者重新初始化之后的越晚的时间撬动 RTM，攻击面就越大，并且评估者在其测定数据中拥有的可信度就越少。关于 RTM 的属性的值的范例包括：
    • 第 1 类（即终端机将 RTM 的实例化作为早期 BIOS 加电自检初始化的一部分）
    • 第 2 类（即终端机在早期 BIOS 加电自检初始化之后才进行 RTM 实例化）
  2. RTS——RTS 的属性提供了关于由能够使得破坏显而易见的存储区域提供的保护的信息。RTS 越有可能抵御来自对手的攻击，则评估者就能在其包含的测定数据中拥有更高的可信度。RTS 的值可以取如下几种：
    • 第 1 类：基于硬件的（例如 TPM 1.2，基于处理器的受保护存储）
    • 第 2 类：基于软件的（例如：操作系统的密钥存储器，系统管理内存（SMRAM））
  3. RTR——RTR 的属性提供了关于可提供给以下内容的保护的信息：将要报告的数据、用于提供认证的密钥素材、利用密钥进行签名的代码，以及不可抵赖性的服务。RTR 越有可能抵御来自对手的攻击，则评估者就能在报告中拥有更高的可信度。RTR 属性的值可能包括：
    • 第 1 类：基于硬件的（例如 TPM 1.2，基于处理器的）
    • 第 2 类：基于软件的（例如：操作系统，BIOS 启动块和存储于 BIOS 中的密钥）
  4. BIOS 签名存在——这是关于 BIOS 是否被签名以及签名是否存在于 BIOS 中的指示器。其值包括：
    • 无（BIOS 未被签名）
    • 部分（某些 BIOS 组件被签名，并且签名存在）
    • 完全（所有 BIOS 组件被签名，并且签名存在）
  5. BIOS 更新机制——此属性提供了关于厂商所使用的 BIOS 更新机制类型的指示器。此属性的重要性在于 BIOS 提供商在提供最新的 BIOS 代码和数据更新时的勤奋度。在安全性的上下文环境中，可靠的 BIOS 更新机制的存在性为最终用户提供了这样的担保，即一旦需求出现，BIOS 提供商可以安全地将其产品从威胁中恢复。拥有不可靠的更新机制或者更新机制不存在的 BIOS 可能处于悬疑之中。其值包括：
    • 无（不可能更新 BIOS）
    • 胶囊式（从操作系统中将新的 BIOS 写入内存，然后执行系统重启）
    • 系统管理模式（SMM）（从操作系统中利用 SMM 以修改 BIOS，然后继续运行而无需重启系统；重启对于实现新的 BIOS 必要）
    • 其他
  6. 虚拟化——此属性提供了关于 BIOS 是来自终端机硬件还是作为虚拟机（VM）的一部分而被提供的指示器。其值包括：
    • 无（物理 BIOS 存在）
    • 完全（虚拟 BIOS 正在运行）
  7. 闪存锁定——此属性提供了关于终端机保护 BIOS 所驻留于其中的闪存以防止非授权修改的能力的指示器。此属于通常指代某种硬件能力。此属性的重要性在于 BIOS 提供商对 BIOS 代码和数据提供保护以防止非授权修改的勤奋度。在安全性的上下文环境中，可靠的 BIOS 闪存保护的存在性为最终用户提供了关于 BIOS 测定的可信度。具有不可靠的闪存保护或者不存在闪存保护的 BIOS 可能处于悬疑之中。其值包括：
    • 无
    • 芯片组
    • 闪存芯片原生

3.2.1.2 可信根属性的安全指导意见

  1. 终端机厂商将要提供定义于 3.2.1.1 节的属性
  2. 终端机厂商将要在其用于提供更新和维护的最低粒度级别上提供关于可执行 BIOS 启动代码的参考测定数据，并且它们可以用于验证从 RTR 返回的测定数据
  3. 终端机厂商将要提供用于测定和报告 BIOS 配置数据的测定数据基线的机制
  4. 终端机厂商应该部署那些并不排除扩展至系统 BIOS 外部的 Option ROM 的 BIOS 测定和报告机制
  5. 终端机厂商应该以标准化的格式提供属性
  6. 终端机厂商可以提供关于是否符合 [NIST-SP800-147] 的指示器。

3.2.2 BIOS 完整性测定数据概述

本节定义了所有终端机都应该能够报告的一组最小的基本 BIM 数据。本节探讨这些测定数据的格式以及它们如何生成。

BIOS 启动代码完整性测定数据——BIOS 启动代码完整性测定数据要么是 BIOS 启动代码的一段密码学散列值，要么是 BIOS 启动代码模块的一段扩展的密码学散列值。无论何种情况，它可以被简单地称为“散列值”。此散列值包含以下组件，如果它们被实现：

  • BIOS 启动块
  • SMM 代码
  • 高级配置与电源接口（ACPI）代码
  • 加电自检（POST）代码
  • BIOS 恢复机制代码
  • BIOS 更新机制代码
  • BBM 软件
  • RTM
  • 嵌入式 Option ROM（这些 Option ROM 嵌入在 BIOS 启动代码中并且由 BIOS 厂商控制）

BIOS 配置数据完整性测定数据——BIOS 配置数据完整性测定数据要么是 BIOS 中的用户可配置的数据组件的一段密码学散列值，要么是独立的配置数据组件的一段扩展的密码学散列值。所有这样的 BIOS 配置数据都必须被测定，除了自动更新的终端机配置信息，诸如时钟寄存器，以及系统独特的信息，诸如财产编号或者序列号以外。以上这些必须不被测定到相同的寄存器中。如果要测定，系统独特的信息，诸如财产编号、序列号、口令散列值等应该被测定到不同的私有寄存器中。这允许在相同配置的系统之间，以及在同一台系统的多次启动测定之间建立起具有一致性的测定数据，也允许系统管理员确定口令是否被更改。

在实践中，对来自同一品牌的同一型号的不同终端机的 BIOS 组件进行现场完整性测定，将会得到不同的和独特的值。这看起来是反直观的，特别是对于静态 BIOS 组件的完整性测定。黄金 BIOS 测定数据的缺失使得进一步调查变得困难，特别是在区分受到攻击的和合法的 BIOS 时。

在实践中，RoT 维护 BIM 数据的组合。尽管规范建议了独立的完整性测定数据应该如何存储和保存，标准的缺失使得解读这些测定数据用于取证变得困难。

3.2.2.1 BIOS 完整性测定数据的生成和存储

为了监测并改进 BIOS 完整性，BIOS 完整性测定数据必须开始被安全地生成和存储。这些测定数据可以随后被传输、分析、报告，以及用于提供恢复。本节描述终端机如何生成并存储 BIM 数据。

终端机的 RTM 必须作为测定信任链的根基。通过使得终端机的 RTM 测定一个或者更多的二进制组件并且在执行这些二进制组件之前将这些测定数据记录在安全的位置，终端机形成了测定信任链。接下来，终端机通过仅仅将测定委托给某些组件来维持测定信任链，这些组件要么是由终端机的 RTM 测定的，要么是由其测定过程可以回溯至终端机的 RTM 的其他组件测定的。测定信任链应该先于终端机使用它们测定所有 BIOS 配置数据（非可执行的二进制数据）。

3.2.2.2 BIOS 完整性测定数据寄存器

为了清楚起见，此文档创造并且使用了若干种寄存器“类型”。“寄存器”一词本意是为了解释所需的不同类型的存储能力以及它们如何使用，而非定义任何特别的实现架构或者命名惯例。

由于测定信任链测定 BIOS 代码和数据，终端机必须将测定数据存储于可信的位置，它将会再随后提供监测和查看，只要终端机管理员想要监测和查看。终端机的 RTM 和测定信任链将测定数据存储于包含在 RTS 中的完整性测定数据寄存器（IMR）中。它们将会计算 BIOS 组件（代码和数据）的散列值，使用某种批准的密码学散列算法，诸如发布于 [NIST-FIPS180-3] 中的算法之一。IMR 应该拥有足够的长度以容纳选自批准的列表中的散列算法的全部结果。

BIOS 完整性测定的实现者将要把各个 IMR 初始化为某个已知的固定值。它们可以一次性地为一个寄存器计算欲测定的所有 BIOS 组件的散列值，并且将此结果扩展到 BIOS IMR 中。或者，实现者可以创建组合的散列值，通过连续地逐个计算 BIOS 组件的散列值，并且为每个组件按照如下方式来扩展 BIOS 代码的 IMR：

IMRnew = H(IMRold || H(BIOScomponent))

IMRnew 是新的 IMR

IMRold 是 IMR 的旧值

BIOScomponent 是待测定的 BIOS 组件

H 是选自批准的列表中的一种散列算法

|| 是拼接运算符

当测定 BIOS 数据时，可选地使用某种某种带密钥的散列算法，诸如 HMAC。随机化的散列算法可以被应用以获取额外的防碰撞性，诸如 [NIST-SP800-106] 中发布的某种算法。在此情况下，IMR 的大小必须能够容纳随机化散列算法的输出，连同验证这些散列值所必需的额外参数。

在任何 BIOS 组件的测定发生之前，终端机将要把各个 IMR 初始化为某个已知的固定值。在理想情况下，终端机的加电即可初始化这些寄存器。只有那些导致 BIOS 被完整执行的终端机重置应该导致这些寄存器的重置。终端机从挂起调用（通常称为待机和休眠模式）中的恢复不会初始化 IMR，而是恢复其在挂起过程中所保持的有效值。

终端机将所有 BIOS 可执行组件的测定数据累积至一个 IMR 中。类似地，终端机为所有 BIOS 配置数据组件执行相同的过程，除了诸如口令、序列号、财产编号、密钥素材等隐私敏感数据，以及诸如时间等元素以外，这些元素使得制作黄金测定数据成为不可能。这些被排除的项目往往是对于平台独特的，并且可能导致管理员已经以相同方式配置的平台投射出不同的配置数据 IMR。并且，由于这些项目是隐私敏感的，管理员可能想要选项以配置这些值的测定和报告。终端机将要把 BIOS 可执行代码的测定数据累积至 BIOS 代码完整性测定数据寄存器（CIMR），将要把 BIOS 数据的测定数据累积至 BIOS 数据完整性测定数据寄存器（DIMR），并且应该将 BIOS 隐私敏感数据累积至 BIOS 隐私完整性测定数据寄存器（PIMR）。

3.2.2.3 BIOS 测定数据日志

除了将 BIOS 代码和数据的测定数据分别扩展至 CIMR 和 DIMR 以外，BIOS 功能还可以将可选的测定数据和事件扩展到它们当中来。为了帮助梳理位于寄存器中的测定数据，管理员将会在一段描述了扩展到它们当中的测定数据和事件的日志中发现巨大的价值。一些例子包括：

  • 终端机厂商以模块的形式维护并更新 BIOS，并且在模块基础上编写 BIOS 代码以测定并且扩展一个模块上的 CIMR。日志将会帮助 MAA 检测这样的情况，其中一次或者多次的错误或者意料之外的测定数据被扩展至 CIMR 中
  • 如果终端机包含多于一份 BIOS 镜像，例如，一份运行的镜像和一份备份，管理员可能想要获得关于哪份副本被测定并且扩展到 CIMR 的额外细节。BIOS 功能的某个早期阶段可能会将一个发出了所作选择的信号的“事件”连同其在日志中的对应项目扩展至 CIMR 中
  • BIOS 可能想要刚好在将执行权移交给某个后启动环境之前对测定数据扩展进行“封端”。通过将某个“封端”事件扩展至 CIMR 或者 DIMR 并且在日志中记录对应事件，管理员可以检测在终端机初始化过程中的哪些阶段发生了哪些事件
  • BIOS 配置数据拥有众多排列方式。一段记录了那些涉及 BIOS 配置数据的测定数据和事件的事件日志如果被适当地格式化，可以有助于对意料之外的更改进行编程式的审查。

一段存储的测定数据日志（SML）允许终端机的更高级别的代理，诸如报告和采集代理在将其转发至 MAA 之前采集它们以用于预处理和相互关联。由于这些代理通常运行于后启动环境中，BIOS应该在将执行权移交至新的环境时注意保留 SML 中的内容。

SML 测定数据通常拥有比 CIMR 或者 DIMR 测定值更好的粒度，但是并不拥有用于包含原始 BIOS 固件或者配置数据的最精细的粒度。尽管系统将要使得 SML 数据可用于报告，它应该提供某种方式以编程式地报告并解读 BIOS 配置数据。TCG 在 [TCG-ConvBiosSpec] 中提供了一种用于 SML 日志项目的标准格式。

3.2.2.4 关于 BIOS 完整性测定数据的生成和存储的安全性指导意见

  1. 被测定的组件
    1. 终端机将要测定所有 BIOS 可执行组件
    2. 终端机将要测定所有 BIOS 配置数据组件，除了隐私敏感数据以外
    3. 终端机应该独立于其他 BIOS 配置数据组件来测定隐私敏感数据
  2. BIOS 测定数据的生成和存储
    1. 终端机将要支持启动时测定
    2. 终端机将要使用某个 RTM 或者植根于某个 RTM 中的测定信任链中的某个组件来生成 BIOS 完整性测定数据
    3. 终端机将要使用批准的标准密码学技术以生成 BIOS 完整性测定数据
    4. 终端机将要使用标准的 BIOS 完整性测定数据格式
    5. BIM 数据的格式和报告——黄金测定数据和终端机测定数据——将要使用开放格式或者规范，诸如 [TCG-Manifest] 和 [TCG-Integrity] 中的
    6. 终端机厂商应该使用可扩展的系统以允许添加对于 Option ROM 等的测定支持
    7. 终端机将要在 RTS 中存储 BIM 数据
    8. 终端机厂商应该使得原始 BIOS 配置数据可用于报告，并且应该拥有某种方式以解读该可用的数据
  3. 测定数据日志
    1. BIOS 功能将要把 SML 测定数据和事件扩展记录至 CIMR 和 DIMR 中
    2. BIOS 功能应该把 SML 测定数据和事件扩展记录至 PIMR 中
    3. 在将 BIM 数据和其他 BIOS 相关事件记录于 SML 中时，BIOS 功能将要使用一种标准格式，诸如 [TCG-ConvBiosSpec]
    4. BIOS 将要保证恰当地将 SML 移交至后启动环境
  4. 测定数据支持
    1. 操作系统厂商将要支持一种标准应用程序接口（API）以用于采集测定数据
    2. 终端机、操作系统和应用程序厂商将要支持一种 RTR 以用于采集和报告 BIM 数据

3.2.2.5 相关标准和规范

有若干种与这些要求相关的记录标准。[NIST-SP800-147] 规范详细说明了获得并维持一种 RTM 所依赖的不可变的 BIOS 启动块所必需的条件。[TCG-ConvBiosSpec] 规范定义了 RTM（即 BIOS）应该对哪些 BIOS 组件进行测定并且将其存储于 RTS（例如 TPM）中。TCG EFI 平台规范版本 1.20 修订版本 1.0 [TCG-EFI] 定义了应该由 RTM 或者在 EFI 内部通过扩展信任链进行测定并且存储于 RTS（例如 TPM）中的可扩展固件接口（EFI）组件。最后，TCG 基础设施工作小组参考清单纲要规范版本 1.0 [TCG-Manifest] 具体说明了厂商可以用于报告 BIOS 完整性黄金测定数据、终端机测定数据以及 BIOS 完整性测定数据属性的格式。

3.3 BIOS 完整性报告

对存储于 RTS 中的 BIOS 完整性测定值的报告由终端机的报告代理执行。

3.3.1 终端机报告代理

终端机的 RTR 和植根于 RTR 中的报告代理负责提取存储于 RTS 中的 IMR 中的测定数据。RTR 和报告代理对此数据应用完整性和不可抵赖性的保护，以使得后续代理不能在不被 MAA 检测到的情况下更改或者替换这些数据是至关重要的。此外，无歧义的身份信息是应用于该数据的一项重要属性，以使得 MAA 知道该数据的来源。通常，利用 MAA 所认识的密钥对此数据进行签名即足以满足完整性、不可抵赖性和无歧义的身份的目标。

此外，报告代理还负责为 IMR 数据提供对应的 SML。基于唯一地标识出制造商、型号和版本的组件 ID 来识别所测定的组件，以便允许 MAA 将其测定数据同它的黄金测定数据进行对比是理想的。

终端机报告代理将会得到一个临时随机数，此临时随机数来自 MAA，并且通过传输代理和采集代理而被传递给它。它随后将此临时随机数传递给 RTR，并且收到对于此临时随机数连同存储于 RTS 中的测定数据的散列值表征的签名。它还会得到 SML 并且将此二者整合为一种标准格式。此报告最终必须可以被 MAA 读取。因此：

  1. 定义的报告格式将要使用 [TCG-Integrity]
  2. 此报告应该包含一份以某种业界标准格式呈现的 BIOS 配置副本，如果想要得到分析并确定此配置的可接受性的能力。

除了以上指导意见以及列出于整个 3.3 节的标准以外，下述 3.3.2 节中的要求适用于将要提供给 MAA 中的验证代理的 BIOS 测定数据报告。

3.3.2 报告协议的安全性指导意见

  1. BIOS 报告机制可以准备并签发一份 BIOS 完整性报告至某个合法的 MAA，当符合下列任何条件时：
    1. 如果 BIOS 配置发生更改
    2. 如果 BIOS 软件发生更改
    3. 如果本地端口被用于访问 BIOS 或其配置
    4. 如果 BIOS 错误条件被生成
    5. 当连接至由某个合法 MAA 控制的网络时
  2. BIOS 报告机制可以支持配置特定事件以引发 BIOS 完整性测定数据报告的能力
  3. 报告请求可以由此报告的报告方或者接收方引发。下列要求适用于由任意一方引发的请求：
    1. 机制将要能够提供可证明地新鲜的 BIOS 报告以发送给 MAA
    2. 报告应该包含一段关于此报告所使用的格式化标准/纲要的引用
    3. 报告格式应该包含一个版本字段，每当此报告格式发生扩展或者其他更改时，此字段可以随着时间更新
    4. 所有来自非法实体的签发或者提供报告的请求应该被忽略
    5. 提供或者签发报告的请求可以包含优先级信息，以指示此请求的紧急程度
    6. 与请求相关的响应时间框架可以由授权用户基于优先级进行配置

3.3.3 相关标准和规范

BIOS 测定数据需要以一种标准纲要来提供，以使其可以被接收它的实体基于策略使用并且采取行动。因此，下列标准和指南应该被用于建立一种关于报告和提供标准报告格式以及 BIOS 测定数据传输的信任模型。

TCG 基础设施工作小组的完整性报告纲要规范 [TCG-Integrity] 定义了在不同的实体之间进行完整性信息通讯所用的结构。TCG 可信网络连接（TNC）工作小组的 IF-M 规范 [TCG-IF-M] 定义了一种用于 MAA 从终端机请求测定数据以及用于终端机向 MAA 提供这些测定数据的协议。

TCG 用于可互操作性的可信网络连接架构规范 [TCG-ARCH-INTER] 描述了一种开放的解决方案架构，它允许网络操作员根据终端机的安全状态来强制执行策略，以决定是否赋予其访问所请求的网络基础设施的权限。终端机完整性策略可能涉及横跨一系列系统组件（硬件、固件、软件和应用程序设置）的完整性参数，并且可以包括或者不包括 TPM 的证据。对于每一台终端机的此类安全评估通过使用一套涵盖了终端机的操作环境的各个方面的声明的完整性测定来实现。IF-M、IF-TNCCS 和 IF-T 是用于将测定数据从终端机传输至 MAA 的关键 TNC 协议。

NIST IR 7802 [NIST-IR-7802] 提供了关于在安全自动化领域中的 XML 文档的上下文环境下如何使用现存规范以代表签名、散列值、密钥信息和身份信息的建议。NIST IR 7694 [NIST-IR-7694] 描述了财产报告格式（ARF），这是一种用于表达财产以及财产和报告之间的关系的信息传输格式的数据模型。此标准化的数据模型有助于在组织机构内部各处以及组织机构之间报告、关联和融合财产信息。NIST SP 800-126 [NIST-SP800-126] 定义了安全内容自动化协议（SCAP），这是一套规范，它们标准化了安全软件产品用于通讯安全内容，特别是软件瑕疵和安全配置信息所使用的格式和命名法。SCAP 是一种多目的协议，它支持自动配置、漏洞和补丁检查、技术控制合规行为以及安全测定。

DMTF 的系统管理 BIOS（SMBIOS）参考规范 [DMTF-SMBIOS] 应对的是主板和系统厂商如何通过扩展 x86 架构系统上的 BIOS 以便以一种标准格式呈现关于它们的产品的管理信息。此规范的本意是提供足够的信息，以使得 BIOS 开发者可以实现必要的扩展以允许他们的产品上的硬件以及其他系统相关信息可以被这些已定义接口的用户准确地确定。此外，在那些实施者对系统上的非易失性存储器提供了写入访问权限的情况下，当一台系统部署于场地中以后，某些信息可以由管理应用程序更新以记录持续存在于系统的多次启动之间的数据。此规范的目的还在于为管理仪器的开发者提供足够的信息以开发用于将 SMBIOS 格式翻译为他们所选择的管理技术所使用的格式的通用程式，不论该管理技术是诸如 DMI 或者 CIM 的 DMTF 技术或是其他技术。为了支持这种用于 DMTF 技术的翻译，此规范中的章节描述了 DMI 组和 CIM 类，它们的本意是通过此文档中描述的接口传达获取自 SMBIOS 兼容系统的信息。

最后，TCG 证明 PTS 协议：捆绑于 TNC IF-M 规范 [TCG-Att-PTS] 和 TCG 基础设施工作小组的完整性报告纲要规范 [TCG-Integrity] 定义了如何使用 IF 以请求和发送完整性报告。它们还添加了发送临时随机数的方法和对基于 TLV 的完整性报告数据的支持。

3.4 BIOS 完整性测定数据的采集和传输

3.4.1 完整性数据的采集和传输概述

BIM 测定数据由采集代理采集并置于某种标准格式，然后由传输代理将其从终端机传输至 MAA。本节描述了采集代理和传输代理所必须满足的条件。

BIM 数据的安全传输保证了测定数据并未被修改、泄露或者在传输过程中被恶意相关方非法复制。更进一步地，传输协议的适当选择应该保证最大化的可互操作性、新鲜度和效率。此外，始于 RTR 的完整性密码学保护和测定数据来源认证保证了即使采集代理、传输代理或者其他软件被攻击，测定结果也不能被证伪。

3.4.2 测定数据的采集和传输的安全性指导意见

传输代理将要安全地将 BIOS 完整性测定数据从终端机传输至 MAA，如下所述：

  1. 所有报告会话将要：
    1. 拥有提供机密性保护的能力
    2. 提供完整性保护和新鲜度
    3. 认证 MAA
    4. 提供终端机身份认证
  2. 传输代理：
    1. 将要允许测定数据在从 RTR 到验证组件的全程被保护完整性
    2. 应该支持一系列服务，诸如不间断监测、网络访问控制和应用程序层级的完整性监测
    3. 应该保证所得到的系统是廉价、非强迫性、高性能和安全的（尽管更高级的安全性可能要求更高级的开销）
  3. 终端机上的采集代理和传输代理应该支持开放标准，这些标准允许在众多不同类型的终端机和 MAA 之间，以及在众多不同形式的通讯媒体之间实现可互操作性，直到能够存在这样的可用标准的程度

3.4.3 相关标准和规范

存在若干与上述要求相关的标准。PA-TNC 规范 [IETF-RFC-5792] 相当于 TCG 的 IF-M 1.0 [TCG-IF-M]；它描述了一种用于请求和传输完整性测定数据的标准结构。PB-TNC 规范 [IETF-RFC-5793] 相当于 TCG 的 IF-TNCCS 2.0。它描述了一种用于指导完整性测定数据交换的标准协议。TCG 可信网络连接 TNC IF-T：绑定到 TLS 规范 [TCG-IF-T-TLS] 描述了在网络连接性被建立以后，完整性测定数据交换可以如何通过 TLS 协议传输。TCG 可信网络连接 INC IF-T：用于隧道 EAP 方法的协议绑定规范 [TCG-IF-T-EAP] 描述了在网络连接性被建立之前，完整性测定数据交换可以如何通过 EAP 传输。最后，TCG 证明 PTS 协议：绑定到 TNC IF-M 规范 [TCG-Att-PTS] 定义了如何使用 IF 以请求并发送完整性报告。它还添加了发送临时随机数的方法以及对基于 TLV 的完整性报告数据的支持。

3.5 测定数据评估权威机构

3.5.1 概述

MAA 负责若干事情。它将一个临时随机数传输至客户端的传输代理以保证它将会从客户端收到返回的新鲜测定数据。它从客户端的传输代理收到作为响应的数据传输，这将会包含一段详细记录 BIM 数据的报告，连同对于此临时随机数和一组散列值的签名，这些将会共同保证该报告的完整性。

如果这些项目被可靠和强壮地报告，这将会允许企业管理系统准确地确定系统上的与 BIOS 配置项目相关的安全性状态。有了此信息，MAA 就可以针对组织机构所关注的具体配置项目进行报告以及采取行动。它并没有被强制为只能依据这样的事实来采取行动，即某些未具体指定的配置项目发生的更改已经导致整体测定数据偏离其上次记录的值，如果此发生更改的配置可能甚至与安全性不相关。BIOS 报告机制中的管理组件能够选择哪些属性将被报告应该成为可能。对于独立的 BIOS 配置项目，安全管理员可以被期望为组织机构所关注的项目提供理想值。

被采集和报告的 BIOS 测定数据可以被用于制定访问决策，这可以是隔离、拒绝访问网络资源，或者恢复。它还提供了关于基于网络上的设备的完整性的网络安全状态的一方面的场景警觉性。终端机厂商对于符合 TCG 规范的 BIOS 的采纳将会提供某些必要的基础设施以可靠地建立、测定并且报告终端机的 BIOS 状态。MAA 至少必须能够提供系统状态以显示给 IT 管理员或者自动化的访问/强制执行点。所采集到的信息可以被报告给策略强制执行/决策点，以获取某种形式的恢复或者响应，或者也可以被提供给这样的可视化能力，它可以为网络操作者或者分析者提供关于网络上的财产的完整性的聚合的、归一化的视图。当今存在对于采集其他设备的测定数据的可视化/场景警觉性的能力；对 BIOS 完整性测定的附加是一种自然和直白的扩展。

BIOS 可能会发生 比特衰减 或者修改，在此，BIOS 内容的位可能发生虚假的变化，作为由 BIOS 存储设备硬件的物理属性所决定的随机故障的结果。取决于 BIOS 存储设备硬件，这些虚假的修改可能会在非常大规模的安装中以一定的频率发生；其结果是，意外的 BIOS 测定数据可能会被潜在地每周或者每天报告。为了避免这样的假设，即所有意外的测定数据都是由于比特衰减而造成，并且帮助操作者作出正确决策以及采取行动，MAA 可以提供机制以允许评估此测定结果是否可能是由于比特衰减而造成。

3.5.2 MAA 安全性指导意见

  1. MAA 将要能够存储期望值（黄金测定数据）
  2. MAA 将要能够将新报告的值同期望值和/或之前报告（最后已知）的测定数据进行比较
  3. MAA 将要能够存储被报告的值
  4. MAA 将要支持开放标准，它们允许在众多不同种类的终端机和 MAA 之间以及在众多不同形式的通讯媒体之间保持可互操作性，直到能够存在这样的可用标准的程度
  5. MAA 可以能够提供某种相似性评估，以确定某个意外、异常的测定数据是由比特衰减所造成的结果的可能性，如果同时提供给它产生异常测定数据的 BIOS 内容以及存在黄金测定数据的 BIOS 内容

3.6 恢复活动

恢复 是指修正计算机系统的问题的过程。在 BIOS 安全性的上下文环境中，恢复指的是诸如将老旧的 BIOS 升级到某种已知良好的版本以及重新配置 BIOS 以使其符合某组织机构的安全性要求等行为。用于修复 BIOS 安全性问题的过程通常有若干种选项。适合于每种情况的一种或者多种过程选项可能会由于若干因素而异，包括问题的类型（BIOS 更新、配置更改等）、问题的本质（有意的攻击还是无意的更改）、系统的相对重要性，以及组织机构的事故处理策略和实践等。每个组织机构都需要决定哪些因素是和它们的环境相关的，并且决定如何将它们整合到恢复活动当中。关于此问题的更深入讨论超出了此出版物的范围。

本节所探讨的恢复并未考虑事故处理和取证活动，这些方面超出了此出版物的范围。参阅 NIST SP 800-61 以获得关于事故处理的额外信息，参阅 NIST SP 800-86 以获得通用取证指南。

3.6.1 隔离策略

隔离 是在事实上将受到攻击的系统从具有宽带网络和资源访问权限（或者潜在的访问权限，在该系统将要加入某个网络的情况下）的位置移至访问受限的联网系统池中的过程，以使得目标系统在恢复完成之前“不会造成伤害”。完全隔离限制所有网络访问，而部分隔离允许该系统访问网络上的某些部分，而非更加敏感的区域。

隔离在本意上是一种短期状态。如果威胁化解成功，通常隔离将会结束，并且此系统被允许其常规的网络访问。如果威胁化解不成功，将此系统完全移出服务可能是恰当的，以使得管理员可以手动处理威胁化解过程。

支持 BIM 的产品可以撬动现存的标准以支持隔离。TCG 可信网络连接 IF-PEP [TCG-IF-PEP] 可以被用于在 MAA 和强制执行点之间发送命令以支持完整或者部分隔离。RFC 3576，远端用户拨入验证服务的动态授权扩展 [IETF-RFC-3576] 可以被用于支持动态授权，以允许 MAA 和强制执行点在一段时间以后重新测试一台终端机，并且潜在地采取恢复行动，包括隔离该系统。

3.6.2 恢复过程自动化

组织机构可以拥有若干种选项以使其 BIOS 恢复行为部分或者完全自动化。不同的选项适合于不同的情况和环境。例如，某个组织机构可能想要使其 BIOS 恢复完全由外部系统（例如企业网络和系统管理）驱动，而其他组织机构可能想让恢复行为完全自包含于产品中，并且利用完全自动化的方式以使得恢复行动被尽快执行。在这些极端情况之间还有众多其他方式，其中大多数制造商在发售其产品时附带某种默认的自动化策略。可能的策略包含以下这些：

  1. 完全自动化，自包含的。对于某些系统的情况，正常系统的带外可能会有被特别信任的硬件，这些硬件可以在发生攻击事件时为系统提供完整的恢复
  2. 完全自动化，外部驱动的。大多数企业和大型组织机构将会对那些将要允许远程恢复以修复问题的系统应用基于服务器的恢复。在此情况下，完全重启可能将会成为必需，由于软件就其自身而言通常不可信任
  3. 要求物理操作员介入的部分自动化。例如，如果恢复软件受到攻击，从某个次要来源，诸如一张 CD 重启系统以实施客户端软件的可信恢复可能是必需的。无论如何，此系统的操作员可以被信任以涉及恢复，而非要求一位可信的 IT 代表以执行此任务
  4. 要求远程所有者介入的部分自动化。IT 代表可能必须被派遣以处理该系统，而非其操作员

产品可以实施不同的恢复阶段，其中包含应变策略，以防最初的恢复不成功。每个阶段都可以是完全自动化、客户可配置，或者允许手动介入的。类似地，恢复阶段的顺序也可以是自动化或者客户可配置的。在分阶段的线性恢复过程中，有单一的预定义恢复路径；在分阶段的分支恢复过程中，基于一个或者更多的变量输入，可以有一系列灵活的恢复路径选择点。此情形的一个范例是一次基于服务器的恢复在重启时被发现是不成功的，由于基于客户端的恢复软件受到攻击。此时，该客户端可以被重启至一台预启动执行环境（PXE）服务器，该服务器可以随后被用于运行已知良好的基于客户端的恢复软件，或者，一位技术人员可以被派遣至该系统以对其进行本地恢复。

PA-TNC 规范 [IETF-RFC-5792] 相当于 TCG 的 IF-M 1.0 [TCG-IF-M]，它可以支持要求用户物理介入客户端的部分自动化的恢复过程。这些标准支持将诸如网址或者人类可读的字符串等统一资源标志符（URI）从 MAA 发送至终端机以辅助用户驱动的恢复活动。

NIST SCAP 规范也可以支持完全或者部分自动化的恢复活动。NIST IR 7670 草案，用于企业安全恢复的开放规范提案 [NIST-IR-7670] 检视了企业恢复的应用案例，标识出了这些应用案例的高级要求，并且提议了一系列可用于应对这些要求的新兴规范。

3.6.3 恢复选项

有若干种可能的选项用于将 BIOS 软件或者配置恢复至某种“已知良好的状态”，包括下列选项：

  1. 恢复至制造商的默认设置
  2. 恢复至用于一般应用的客户默认设置
  3. 恢复至用于某种特定应用的客户默认操作配置
  4. 恢复至上一次已知良好的配置
  5. 强制此系统进入某种非操作状态（例如隔离、移出服务等）

关于恢复的另一个考虑是对于系统的非易失性数据的处理策略。可能的选项包括：

  1. 无备份
  2. 部分备份
  3. 完全备份
  4. 应用程序门控策略——如果此攻击被定位于某个可以被选择性地禁用的特定 BIOS 服务，则可以应用此策略
  5. 如果某个特定服务（诸如某个低级可管理性的接口）被攻击，可能可以安全地关闭此服务，而非重新刷入整个 BIOS

3.6.4 验证选项

在 BIOS 被恢复之后，组织机构可以选择验证其完整性。这通常涉及重启该系统并且将其置入其正常的测试序列中，以保证在赋予此系统网络资源访问权限之前，其完整性已经得到恢复。或者，该组织机构可以选择允许系统返回操作而无需经历标准的重新测试。在此情况下，此恢复策略至少和通常在启动时发生的可信测定被同等程度地信任。

附录 A——安全性指导意见总结

此附录包含用于系统 BIOS 完整性测定实现的安全性指导意见的总结。

3.1.4 RoT 安全性指导意见

  1. 终端机厂商将要为实现可信的 RTM、RTS 和 RTR 提供必需的硬件支持，并且利用该支持来实现 BIM 中的对应 RoT
  2. 终端机厂商将要合并 RTM、RTS 和 RTR 的机制以形成用于 BIM 的集成式的，可靠的基础
  3. 终端机厂商应该为受到完整性保护的，不可绕过的认证或者安全 BIOS 更新提供机制，作为满足 [NIST-SP800-147] 之必需
  4. 终端机厂商可以为实现某种用于后启动时测定的可信的动态 RTM 提供硬件支持。终端机厂商和操作系统厂商可以使用该支持以实现用于 BIM 的这样的 RoT

3.2.1.2 RoT 属性的安全性指导意见

  1. 终端机厂商将要提供定义于 3.2.1.1 节的属性
  2. 终端机厂商将要在其提供更新和维护所用的最低级别的粒度上为可执行 BIOS 代码提供参考测定数据，并且该参考测定数据可以被用于验证返回自 RTR 的测定数据
  3. 终端机厂商将要提供机制以测定和报告用于 BIOS 配置数据的测定数据基线
  4. 终端机厂商应该部署那些并不排除扩展至系统 BIOS 外部的 Option ROM 的 BIOS 测定和报告机制
  5. 终端机厂商应该以标准化的格式提供属性
  6. 终端机厂商可以提供关于符合 [NIST-SP800-147] 的指示器

3.2.2.4 BIOS 完整性测定数据的生成和存储的安全性指导意见

  1. 被测定的组件
    1. 终端机将要测定所有 BIOS 可执行组件
    2. 终端机将要测定所有 BIOS 配置数据组件，除了隐私敏感数据以外
    3. 终端机应该独立于其他 BIOS 数据组件来测定隐私敏感数据
  2. BIOS 测定数据的生成和存储
    1. 终端机将要支持启动时测定
    2. 终端机将要使用 RTM 或者植根于 RTM 中的信任链中的某个组件来生成 BIOS 完整性测定数据
    3. 终端机将要使用批准的标准密码学技术以生成 BIOS 完整性测定数据
    4. 终端机将要使用标准的 BIOS 完整性测定数据格式
    5. BIM 数据——黄金测定数据和终端机测定数据——的格式和报告将要使用开放的标准或者规范，诸如 [TCG-Manifest] 或者 [TCG-Integrity]
    6. 终端机厂商应该使用可扩展的系统以允许添加对于测定 Option ROM 等的支持
    7. 终端机将要将 BIM 数据存储于 RTS 中
    8. 终端机厂商应该使得原始 BIOS 配置数据可用于报告，并且应该拥有方法以解读该可用的数据
  3. 测定数据日志
    1. BIOS 功能将要把 SML 测定数据和事件扩展记录进 CIMR 和 DIMR 中
    2. BIOS 功能应该把 SML 测定数据和事件扩展记录进 PIMR 中
    3. 在将 BIM 数据和其他 BIOS 相关事件记录进 SML 中时，BIOS 功能将要使用一种标准化的格式，诸如 [TCG-ConvBiosSpec]
    4. BIOS 将要保证恰当地将 SML 移交给后启动环境
  4. 测定支持
    1. 操作系统厂商将要支持某种标准 API 以用于采集测定数据
    2. 终端机、操作系统和应用程序厂商将要支持用于采集和报告 BIM 数据的 RTR

3.3.2 报告协议的安全性指导意见

  1. 在下列任何情况下，BIOS 报告机制可以准备并且向某个合法 MAA 签发 BIOS 完整性报告：
    1. 如果 BIOS 配置发生更改
    2. 如果 BIOS 软件发生更改
    3. 如果某个本地端口被用于访问 BIOS 或其配置
    4. 如果某个 BIOS 错误条件被生成
    5. 当连接至由某个合法 MAA 控制的网络时
  2. BIOS 报告机制可以支持配置特定事件以引发 BIOS 完整性测定数据报告的能力
  3. 报告请求可以由报告的报告方或者接收方引发。下列要求适用于由任何一方引发的请求：
    1. 机制将要能够提供可证明地新鲜的 BIOS 报告以发送至 MAA
    2. 此报告应该包含一段关于此报告所用的格式化标准/纲要的引用
    3. 此报告格式应该包含一个版本字段，它可以在报告格式发生扩展或者其他变化时随着时间被更新
    4. 来自非法实体的所有签发或者提供报告的请求应该被忽略
    5. 提供或者签发报告的请求可以包含优先级以指示该请求的紧急性
    6. 与请求相关的响应时间框架可以由授权用户根据优先级进行配置

3.4.2 测定数据采集和传输的安全性指导意见

传输代理将要安全地将 BIOS 完整性测定数据从终端机传输至 MAA，如下所述：

  1. 所有报告会话将要：
    1. 拥有提供机密性保护的能力
    2. 提供完整性保护和新鲜度
    3. 认证 MAA
    4. 提供终端机身份认证
  2. 传输代理：
    1. 将要允许测定数据在从 RTR 到验证组件的全程受到完整性保护
    2. 应该支持一系列不同的服务，诸如不间断监测、网络访问控制和应用程序层级的完整性监测等
    3. 应该保证所得到的系统是廉价、非强迫性、高性能和安全的（尽管更高级的安全性可能要求更高级的开销）
  3. 终端机上的采集代理传输代理应该支持开放格式以允许在众多不同类型的终端机和 MAA 之间以及在众多不同形式的通讯媒体之间实现可互操作性，直到能够存在这样的可用标准的程度

3.5.2 MAA 安全性指导意见

  1. MAA 将要能够存储期望值（黄金测定数据）
  2. MAA 将要能够将所报告的值同期望值和/或之前报告的（最后已知的）测定数据进行比较
  3. MAA 将要能够存储被报告的值
  4. MAA 将要支持开放格式以允许在众多不同类型的终端机和 MAA 之间以及在众多不同形式的通讯媒体之间实现可互操作性，直到能够存在这样的可用标准的程度
  5. MAA 可以能够提供关于某个意外、异常的测定数据是由比特衰减造成的可能性的评估机制，如果它被提供给产生此异常测定数据的 BIOS 内容以及存在黄金测定数据的 BIOS 内容

附录 B——用语和缩略语

此部分附录定义了此文档中所使用的术语。

  • 属性：评估者用于决定其可信度的 RoT 性质
  • BIOS 代码完整性测定数据寄存器（CIMR）：包含终端机上的所有静态 BIOS 代码的密码学散列值或者构成了 BIOS 代码空间的所有 BIOS 组件的组合散列值的寄存器
  • BIOS 数据完整性测定数据寄存器（DIMR）：包含终端机上的所有动态 BIOS 配置数据的密码学散列值或者构成了 BIOS 配置数据空间的所有 BIOS 组件的组合散列值的寄存器
  • BIOS 隐私完整性测定数据寄存器（PIMR）：包含所有 BIOS 隐私敏感数据的组合散列值的寄存器
  • BIOS 完整性测定数据的生成：创建 BIOS 组件的散列值并且用这些散列值填充静态和动态 BIOS 配置寄存器的行为
  • 比特衰减：由于随机物理过程造成的 BIOS 存储变化
  • 采集：测定终端机 BIOS 完整性的行为，以及收集所得到的测定数据以使得它们可以从终端机被传输的过程
  • 动态 BIOS 组件：BIOS 中可由用户更改而无需 BIOS 厂商或者系统厂商辅助的部分，这通常指代 BIOS 配置数据
  • 终端机：其 BIOS 完整性正在被测定的系统。终端机可以是台式机、服务器、虚拟化环境以及服务等
  • 黄金测定数据：关于 BIOS 及其配置数据的一组可信的完整性测定数据。这些测定数据通常由可信的相关方提供，诸如终端机的 OEM，它们也可以由系统管理员在一台设备的初始供货过程中采集。由 OEM 签名的 BIOS 的 SHA-2 散列值是黄金 BIOS 测定数据的一个范例。黄金 BIOS 测定数据并不提供关于恶意属性存在与否的信息。但是它确实能够帮助对某个对象进行快速、可靠以及不可抵赖的识别
  • 完整性测定数据：对于二进制代码和/或数据的紧凑表示形式。在 BIOS 完整性测定的上下文环境中，它通常表示为二进制代码和数据的密码学散列值，通常以密码学的方式签名以保持合法性和不可抵赖性
  • 已知良好状态：如果 BIOS 已经被验证为处于某种可接受的状态。此状态的一个范例是如果已加载的 BIOS 的数字签名被验证为与制造商的当前版本匹配
  • 测定数据评估权威机构（MAA）：一个代表 IT 管理部门运行的代理。它从客户端接收测定数据、检查这些测定数据的签名、通过将其同黄金测定数据进行比较来评估测定数据的质量，它可以进一步分析测定数据（以确定 BIOS 完整性测定数据发生了哪些更改，如果此测定数据与黄金测定数据不匹配），然后要么将此结果显示给 IT 管理部门，要么作为 IT 管理部门的代理以采取预设的行动，如果测定数据并非期望值
  • 管理控制器：在服务器环境中，通常有监督性的处理器或者控制器以“管理”运行应用程序的主处理器。此管理控制器独立于主处理器，并且能够为其或者以其身份执行若干操作
  • 主处理器：系统上可用于运行应用程序的可能的若干处理器（核心）之一
  • 恢复：修正计算系统的问题的过程
  • 可信根（RoT）：构成了一组被无条件信任的功能的组件（软件、硬件或者混合）和计算引擎。RoT 必须总是以某种预期的方式运作，由于它的不当行为不能被检测到
  • 测定可信根（RTM）：能够进行内在地可靠的完整性测定的计算引擎。RTM 是后续测定代理的传递性信任链的根基
  • 报告可信根（RTR）：能够可靠地报告由 RTM 及其测定代理提供的或者由 RTS 保存的信息的计算引擎
  • 存储可信根（RTS）：能够维持一段使得破坏显而易见的，关于完整性测定值及其测定序列的总结的计算引擎
  • 静态 BIOS 组件：BIOS 中可由用户修改的部分，通常需要来自 BIOS 厂商或者系统厂商的辅助。这通常被称为 BIOS 代码。在历史上，此代码几乎不包含任何对更改的保护机制。[NIST-SP800-147] 概述了厂商能够部署的 BIOS 保护机制

以下列表包含了此文档中所使用的首字母缩略词和其他缩略语。

  • ACPI：高级配置与电源接口
  • API：应用程序接口
  • ARF：财产报告格式
  • BBM：基于 BIOS 的管理
  • BIM：BIOS 完整性测定
  • BIOS：基本输入/输出系统
  • CIM：通用信息模型
  • CIMR：代码完整性测定数据寄存器
  • CPU：中央处理器
  • DIMR：数据完整性测定数据寄存器
  • DMI：桌面管理接口
  • DMTF：分布式管理任务小组
  • EFI：可扩展固件接口
  • FIPS：美国联邦信息处理标准
  • HMAC：基于散列的消息认证码
  • IMR：完整性测定数据寄存器
  • ISV：独立软件厂商
  • IT：信息科技
  • ITL：信息科技实验室
  • MAA：测定数据评估权威机构
  • NFC：近场通讯
  • NIST：美国国家标准技术研究所
  • NISTIR：美国国家标准技术研究所跨部门报告
  • OEM：原始设备制造商
  • OS：操作系统
  • PCR：终端机配置寄存器
  • PIMR：隐私完整性测定数据寄存器
  • POST：加电自检
  • PXE：预启动执行环境
  • RAM：随机存取存储器
  • RFC：请求意见稿
  • ROM：只读存储器
  • RoT：可信根
  • RTM：测定可信根
  • RTR：报告可信根
  • RTS：存储可信根
  • SCAP：安全内容自动化协议
  • SMBIOS：系统管理 BIOS
  • SML：存储的测定数据日志
  • SMRAM：系统管理内存
  • SP：特别出版
  • TCG：可信计算小组
  • TLS：传输层安全性协议
  • TLV：类型长度值
  • TNC：可信网络连接
  • TPM：可信平台模块
  • UEFI：统一可扩展固件接口
  • URI：统一资源标志符
  • USB：通用串行总线
  • VAR：增值分销商
  • VM：虚拟机
  • XML：可扩展标记语言

附录 C——参考文献

附录 C 标识出了相关参考文献。

附录 D——实现可信根的选项

BIOS 完整性保障的基础是 RoT，它们基于一种或者多种硬件机制属性构建。某些 RoT 本身假设 [NIST-SP800-147] 中的要求和建议已被满足。某些和 RoT 最为相关的硬件机制列于下方。（此列表并不完整。）

D.1 CPU 和芯片组的启动逻辑

BIOS 完整性取决于 CPU 在启动时的良好定义的行为，特别是取决于芯片组正确地映射 BIOS 存储设备，以及 CPU 在重置之后如同期望中地执行正确的初始 BIOS 指令。此硬件机制是启动时 RTM 的基础，但是对于基于“延迟启动”机制的 RTM 或者 CPU 在运行时的重新初始化可能不那么相关。

D.2 UEFI 加电 SEC 安全阶段

统一可扩展固件接口（UEFI）对于早先完全由 BIOS 处理的功能提供了补充和部分替换。UEFI 加电 SEC 安全阶段可以提供一种 RoT，它可能能够以这样一种方式可靠地调用 UEFI 中的软件管理代理，以使得它可以被用于实现用于 BIOS 完整性的 RTM。这可能要求符合 [NIST-SP800-147]。

D.3 BIOS 存储设备的访问控制区域

BIOS 和 BIOS 测定数据的完整性基于对于 BIOS 存储设备本身的硬件访问控制机制。这样的访问控制可以通过能够阻止读取或者写入 BIOS 存储设备的“设置直到重启”的触发器来强制执行。这样的触发器被持续设置，直到下一次硬件重置，并且可以在启动的早期阶段被诸如 BIOS 本身等锁定。这些触发器可以通过诸如在 BIOS 存储设备本身或者 CPU 芯片组内部的硬件机制来实现。这些机制可以被用于形成符合 [NIST-SP800-147] 的基础。

被符合 [NIST-SP800-147] 的架构所支持的 BIOS 存储设备访问控制区域也可作为 RTS 和 RTR 的基础。例如，BIOS 可以在初始化过程中测定其自身，并且将测定结果置于一块可读但是“写保护直到硬件重置”的 BIOS 存储区域。BIOS 也可以在将控制权移交给操作系统或者引导程序之前利用密码学密钥创建报告，此密钥存储于一块将会在随后被设置为“不可访问直到下次硬件重置”的 BIOS 存储区域中。为了保证新鲜度，报告可以使用于上次操作系统执行过程中存储于 BIOS 的易失性区域中的临时随机数。

D.3.1 静态的不可变 BIOS 启动块

一块静态的不可变 BIOS 启动块（或者初始 BIOS 代码区域）可以作为 BIOS 完整性 RTM 的基础，例如通过测定相关 BIOS 存储设备的内容以及设置其访问控制触发器。由于其构建于一块不可变的 BIOS 启动块的基础之上，这样的 RTM 可能提供定义于 3.1 节的可变状态容错性，甚至无需满足 [NIST-SP800-147]。

D.4 隔离的 CPU 执行模式和访问控制内存

若干种 CPU 执行模式和内存访问控制特性可以构成 BIOS 完整性和 BIOS 测定数据的可信根。就其本质而言，这些实现不能提供如 3.1 节所定义的内存泄露容错性。

对于某种符合 [NIST-SP800-147] 的架构，CPU 的 SMM 执行模式能够成为某种隔离的、状态性的机制的基础的潜在 RoT，该机制在启动时由 BIOS 控制和初始化，但是在该设备的整个执行过程中可用，直到下一次重置。在某些情况下，SMM 代码可能对于 BIOS 存储设备拥有比操作系统内核更大的访问权限。SMM 模式就其自身而言不是一种 RTM 的基础。然而，SMM 模式可以构建于某种基于 BIOS 的 RTM 的基础之上，并且用于 (a) 执行对于 BIOS 存储设备的内容及其相关的访问控制触发器设置的运行时测定，(b) 通过将测定结果置于 SMRAM 中来实现一种 RTS，或者 (c) 实现一种 RTR，例如通过使得 BIOS 利用某个密码学私钥来初始化 SMRAM，此密钥被用于签名测定报告，并且在 BIOS 初始化之后除了通过 SMM 模式以外无处可以访问。

如同在 TCG 规范中概述的那样，某些 CPU 提供了所谓的动态 RoT 支持，在此，CPU 被重新初始化为某种已知良好状态。同 TPM 相配合，这样的“延迟启动” CPU 执行模式可以成为所有必需的 RoT 的基础。然而值的注意的是，这样的动态测定可能不能建立过去或者将来的硬件重置时的 BIOS 或者 BIOS 设置的完整性；为了建立这样的启动时保障，BIOS 完整性必须利用诸如 [NIST-SP800-147] 中概述的机制来保护。

D.5 监督 CPU 执行模式和仅可由监督程序访问的内存

虚拟机监视器或者操作系统中的高权限、内核模式代码的一项传统任务是保护系统设备，诸如 BIOS。虚拟机监视器或者操作系统内核几乎总是通过由硬件支持的内存机制保护的，并且内核运行于一种监督执行模式，具有其自身的私有内存。在原理上，这些硬件机制可以成为用于实施 BIOS 完整性的 RTM、RTS 和 RTR 的 RoT，其中，虚拟机监视器或者操作系统保护其自身、BIOS，以及被报告的测定数据的完整性，特别是在假设架构符合 [NIST-SP800-147] 的情况下。由于它们的大小和复杂性，这样的由虚拟机监视器或者操作系统支持的 RoT 可能只能提供极少的保障和最小化的担保，至少是对于标准的虚拟机监视器或者操作系统而言。

D.6 可信平台模块

TPM 可以作为 RTS 和 RTR 的基础。当它与静态的不可变 BIOS 启动块（由 TCG 规范控制，如 D.3 节所述）相结合时，TPM 可以提供可变状态容错性和内存泄露容错性，如 3.1 节所定义。

D.7 私有 RoT

BIOS 完整性保护和测定机制可以由 CPU、CPU 芯片组和/或 BIOS 存储设备中的自定义逻辑来实现。这样的自定义逻辑可以被用于实现任意 RoT，尽管极少（如果有的话）这样的实现现在可用于客户端硬件平台商品。

这样的 RoT 的范例可能包括这样的 BIOS 存储设备，它们要么同某个嵌入式的独立微控制器打包在一起，要么与其紧密通讯，该微控制器被提供给了私钥和私有存储。如果被适当地实现，这样的 RoT 可以被用于实现那些能够提供如 3.1 节定义的可变状态容错性和内存泄露容错性的机制。

附录 E——范例实现的可能性

附录 E 列举了利用普遍可用的机制来实现 BIOS 完整性测定的一些可能性。在此处没有被考虑的一些机制的范例包括管理控制器（例如嵌入于 Intel Sandy Bridge 及其后续芯片组中的管理引擎）以及嵌入于 BIOS 存储设备中的微控制器。

E.1 范例 1——利用高担保性的内核或者虚拟机监视器的可能实现

在此范例实现中，一段可信的监督程序（诸如一款可信的虚拟机监视器或者高担保性的隔离内核）被用于创建 BIOS 完整性测定所必需的 RoT，基于 CPU 启动逻辑（E.1 节）和监督执行模式（E.4 节条目 3）的硬件 RoT。此监督程序负责引导性地保护 RoT 以及在操作过程中和更新之间保证 BIOS 及其设置的完整性。

  1. 在设备重置时，CPU 开始执行 BIOS 存储设备（例如闪存芯片）外的首段 BIOS 指令
  2. BIOS 完成初始化并且将控制权直接移交给一段可信的监督程序，或者移交给一段可信的引导程序，后者查找并加载可信的监督程序
  3. 此可信的监督程序负责实施 [NIST-SP800-147] 指导意见，以及完整调度和控制对于设备配置的访问权限，包括 CPU 启动逻辑和 BIOS 内容和设置的配置，以及包含引导程序的启动存储设备和监督程序本身的代码和配置的配置
  4. 此可信监督程序还构成了 BIOS 完整性测定的 RTM、RTS 和 RTR，并且必须保护存储的测定结果（例如，作为启动存储设备上的受保护状态的一部分）并且允许这些结果被可证明地新鲜地报告（例如，以使得它们不能被伪造或者重放）。基于此目的，此监督程序可以使用私密的私钥，例如存储于 BIOS 或者启动存储设备中的私钥
  5. 不论是按需、启动时还是每当 BIOS 升级时，此监督程序都可以准备 BIM 报告，通过测定诸如 (a) 所有 BIOS 代码，(b) 诸如不可写的配置设置等关键 BIOS 数据，以及 (c) NVRAM 配置数据等
  6. 保证此监督程序（并且只有此监督程序）将会在下次硬件重置时被再次启动是 BIOS 和监督程序的责任。BIOS 必须保护其自身以及任何存储的 RTR 密码学密钥（例如，通过销毁这些密钥），除非 BIOS 能够保证当其完成初始化之后，控制权将被移交给一份通过验证的可信监督程序的副本

上述实现既不能提供 3.1 节所述的可变状态容错性，也不能提供 3.1 节所述的内存泄露容错性。

E.2 范例 2——利用基于触发器的机制的可能实现

此范例实现假设一种符合 [NIST-SP800-147] 的架构，其中，由 BIOS 在启动时安装的 BIOS 启动代码和 SMM 代码的组合被用于创建 BIOS 完整性测定所必需的 RoT，基于 CPU 启动逻辑（D.1 节）、SMM 执行模式（D.4 节）和 BIOS 存储设备访问控制（D.3 节）的硬件 RoT。BIOS 本身及其 SMM 代码负责引导性地保护 RoT 以及在操作过程中和更新之间保证 BIOS 及其设置的完整性。

  1. 在设备重置时，CPU 开始执行 BIOS 存储设备（例如闪存芯片）外的首段 BIOS 指令
  2. 为了实施 [NIST-SP800-147] 的指导意见，BIOS 首先检查可访问的存储设备（例如磁盘、BIOS 闪存芯片中的剩余空间，或者插入的 USB 设备）中是否有可用的有效的、经过签名的 BIOS 升级。如果发现无需升级，BIOS 可以检查其自身的完整性；此步骤应该只需防止比特衰减，由于 BIOS 的完整性通过运行时写保护而被引导性地保持
  3. BIOS 随后设置 SMM 模式并且将一份 BIOS 特定地私钥复制到 SMRAM。此 BIOS 也会复制一份完整的 BIOS/NVRAM 配置数据到 SMRAM 中。SMM 代码负责运行时 BIOS 测定以及 BIM 结果的密钥签名
  4. BIOS 随后对“锁定直到设备重置”的触发器进行编程以 (a) 使得所有 BIOS 代码和所有关键数据，例如不可写的配置设置成为不可写，以及 (b) 使得包含 BIOS 特定的私钥的 BIOS 闪存区域成为不可访问，即既不可读也不可写
  5. BIOS 将控制权移交给引导程序，后者查找并加载操作系统
  6. 在运行时提供一个临时随机数以创建关于一项 BIM 属性的报告，例如 (a) BIOS 闪存芯片中的 BIOS 代码字节，(b) 当前或者启动时的 NVRAM 配置，(c) “锁定直到设备重置”的触发器的状态以及相关设备控制区域等
  7. SMM 代码通过一个或者更多 SMI 调用，并且 SMM 代码测定所请求的属性，诸如……(c)……通过查询 BIOS 闪存芯片本身以及芯片组（例如南桥）中的控制寄存器
  8. SMM 代码将其测定数据和临时随机数合并为一条消息摘要，并且利用 BIOS 特定的私钥对此消息摘要进行签名

上述实现既不能提供 3.1 节所述的可变状态容错性，也不能提供 3.1 节所述的内存泄露容错性。

E.3 范例 3——利用基于 TPM 的机制的可能实现

此范例普遍存在于当今的企业客户端中，其中，BIOS 启动代码和由 TCG 详细说明的 TPM 的组合被用于创建 BIOS 完整性测定所必需的 RoT，基于 CPU 启动逻辑（D.1 节）、TPM（D.5 节）以及 BIOS 存储设备访问控制（D.3 节）的硬件 RoT。由 BIOS 本身负责引导性地保护软件测定代理，并且在操作过程中以及更新之间保证 BIOS 及其设置的完整性。

  1. 在设备重置时，CPU 开始执行 BIOS 存储设备外的不可变的 BIOS 启动块的首段指令，并且 TPM 寄存器被设置为已知值
  2. 不可变的 BIOS 启动块测定 (a) 所有 BIOS 代码，(b) 所有关键 BIOS 数据，诸如不可写的配置设置，以及 (c) NVRAM 配置数据，并且将这些测定数据扩展至 TPM 中的独立 PCR 中。TPM 负责存储测定数据以及报告 BIM 结果，并且 TPM 密钥被用于签名 BIM 结果
  3. BIOS 启动块将控制权移交给驻留于 BIOS 存储设备中的已测定、可变的部分中的代码该代码随之将控制权移交给引导程序以查找并加载操作系统。注意，此实现不符合 [NIST-SP800-147]，由于它并未尝试建立 BIOS 代码完整性，例如，通过写保护 BIOS 存储设备中的代码区域
  4. 在运行时提供一个临时随机数以创建关于一项 BIM 属性的报告，例如 (a) BIOS 代码散列值，(b) 启动时 NVRAM 配置，(c) “锁定直到设备重启”的触发器的状态及其相关设备控制区域等
  5. TPM 中的 PCR 寄存器与临时随机数合并，并且由驻留 TPM 的密钥签名，以创建关于诸如 BIOS 代码以及存在于启动时的配置的报告

E.4 范例 4——利用基于 CPU 延迟启动的机制的可能实现

在此范例实现中，BIOS 启动代码和符合 TCG 规范的 CPU 延迟启动的组合被用于创建 BIOS 完整性测定所必需的 RoT，基于 CPU 启动逻辑（D.1 节）、TPM（D.5 节）以及运行时重新初始化的 CPU 执行模式（D.4 节）的硬件 RoT。硬件本身负责引导性地保护 RoT，而 BIOS 及其设置在操作过程中以及更新之间的完整性可以通过不同的软件方式保护——或者甚至完全不受保护。

  1. 在设备重置时，CPU 开始执行 BIOS 存储设备外的首段 BIOS 指令
  2. [NIST-SP800-147] 的指导意见中的实现中的某个瑕疵可能使得 BIOS 损坏，然而，延迟启动的功能允许 BIOS 完整性被以这样一种方式测定，它将发现此种损坏，并且潜在地揭示一次攻击
  3. BIOS 将控制权移交给引导程序，后者查找并加载操作系统
  4. 在运行时提供一个临时随机数以创建关于一项 BIM 属性的报告，诸如 (a) BIOS 代码散列值，(b) NVRAM 配置，(c) “锁定直到设备重置”的触发器的状态及其相关设备控制区域等
  5. CPU 通过延迟启动功能进入一种洁净、良好定义的环境，其在某些 TPM 寄存器中具有已知、良好定义的值
  6. 此延迟启动环境测定下列内容，诸如 (a) 所有 BIOS 代码，(b) 所有关键 BIOS 数据，诸如不可写的配置设置，以及 (c) NVRAM 配置数据，并且将其写入 TPM 上的良好定义的独立 PCR 中。TPM 负责存储测定数据以及报告 BIM 结果，并且 TPM 密钥被用于签名 BIM 结果
  7. TPM 中的 PCR 寄存器同临时随机数合并，并且由驻留 TPM 的密钥签名，以创建关于例如存在于启动时的 BIOS 代码的报告
Tagged with: system-security