第 5 章 DMA 恶意软件检测初步

您不能防御，您不能预防。您所能做的只有检测并且作出回应。——Bruce Schneier，美国密码学家，计算机安全和隐私专家

上一章呈现了计算机平台外设可以被利用以攻击宿主计算机平台。更准确地说，是那些诸如网卡、显卡以及管理控制器等专用硬件。专用硬件为攻击者提供了隔离的执行环境，该环境不会被代表了业界最先进技术的反病毒软件、入侵检测系统以及其他在市场上可获得的系统软件安全特性所考虑。因此，专用硬件非常适合于隐秘攻击 [35，36，46，123，134，135]。诸如此类的攻击也已经被整合进漏洞利用框架中 [19，18]。

例如，Duflot 等人 [47] 呈现了一种基于网卡（NIC）的攻击以便运行远程 shell 并且接管该宿主。他们使用利用了某个安全漏洞的攻击代码来渗透网卡。Triulzi [134，135] 展示了如何利用网卡和显卡（VC）的组合来访问主内存以允许攻击者偷取密码学密钥及其他敏感数据。Triulzi 远程利用了固件更新机制的漏洞以使得攻击代码进入该系统。

在第 4 章，我们描述了我们是如何利用某个集成在计算机平台上的内存控制器集线器（MCH）中的微控制器的漏洞来隐藏一个击键码记录器的，它被用于捕获诸如口令等机密数据。所有这些攻击的共同点是它们都拥有通过直接内存访问机制对主内存的访问。通过如此做，这些攻击绕过了由宿主系统软件设置的加固安全机制。更进一步地，这些攻击并不需要利用任何宿主系统软件漏洞。具有执行 DMA 传输的能力的设备称为总线主控，参见 2.5 节。在其他总线主控访问主内存时，通常运行着安全软件以揭示攻击的宿主 CPU 并不一定被涉及进来，参见第 4 章。由于诸如外设元件高速互连标准（PCIe）等现代总线架构的出现，一种必须由宿主 CPU 来配置的唯一中央 DMA 控制器已经过时。执行于专用硬件的隔离执行环境中的固件能够配置该外设的 DMA 引擎以读取或者写入主内存的任意位置，这对于宿主 CPU 来说 不可见。

在本章中，我们呈现了我们的 总线代理运行时监视器（BARM）——它是一种能够揭示并且终止针对平台主内存的基于外设的隐秘攻击的监视器。我们开发 BARM 是为了证实这一点，即宿主 CPU 能够检测到源自平台外设的针对平台主内存的额外（恶意）访问，即使宿主 CPU 不能访问可疑外设的隔离执行环境。关于额外访问，我们是指其本意并非代表宿主系统软件而进行的数据传送或者传输等访问。BARM 基于这样一种原型，它能够分析内存总线活动。它将由诸如操作系统或者虚拟机监视器等宿主系统软件所预期的总线活动同实际总线活动相比较。如果 BARM 检测到的总线活动多于宿主系统软件所预期的，则它将会报告基于 DMA 的攻击。BARM 还能识别恶意外设。

在前几章，我们还呈现了人们所提议的若干种考虑了 DMA 攻击的预防方法。例如，Intel 开发了一种输入/输出内存管理单元（I/OMMU），并且将此技术称为用于直接 I/O 的 Intel 虚拟化技术（VT-d [2]）。I/OMMU 可以被应用以限制对于主内存的访问。VT-d 的目的在于为流行的 x86 平台提供硬件虚拟化支持。然而，由于若干种原因，I/OMMU 不一定能够被信任为一种针对 DMA 攻击的反制措施。例如，I/OMMU (i) 必须被无瑕疵地配置 [83]，(ii) 可以被成功地攻击 [111，148，147，146]，以及 (iii) 当存在内存访问策略冲突时不能被应用，参见第 4 章。更进一步地，I/OMMU 并不能被每一种芯片组或者系统软件（例如 Windows Vista 和 Windows 7）所支持。另一种预防方法是在加载时检测外设固件的完整性。然而，这样的加载时检查并不能防止运行时攻击。无限重复进行此类检查以防止运行时攻击的代价是系统性能的损失。注意，这同样并不一定能够捕获瞬时攻击。更进一步地，宿主 CPU 是否能够访问用于存储平台固件的全部只读存储器这一点并不清楚。

在本章中，我们应对了这一挑战，即利用一种运行于宿主 CPU 之上的原型来检测恶意 DMA。通过监控总线活动，我们的方法并不要求能够访问该外设的 ROM 或者其执行环境。我们的原型被作为平台的系统软件的一部分而实现。其基本理念是：攻击者在访问平台的主内存时不能避免造成额外的总线活动。这些额外的总线活动是基于 DMA 的攻击的死穴，而我们正是利用这一弱点来揭示并且终止该攻击。我们的概念验证 BARM 实现了一种考虑了瞬时攻击的监控策略。我们的技术的主要目标是监视连接到内存总线的设备对内存的访问。特别地，宿主 CPU 核心为大量进程存取数据和指令。而诸如网卡和硬盘等外设带来的输入和输出（I/O）更加剧了这种情形。BARM 展示了如何应对这些挑战。

在本章中，我们呈现了一种方法以检测并且化解基于 DMA 的攻击。我们的主要贡献包括：

• 用于揭示攻击的预期总线活动模型以及真实总线活动的测量方法：本章呈现了一种新的机制以通过某个执行于宿主 CPU 之上的原型来监控完整的内存总线活动。我们的方法基于对预期的内存总线活动进行建模。更进一步地，我们呈现了一种技术以用于监视实际的总线活动。我们通过模型预期的活动与实际测量得到的活动之间的差值来揭示恶意内存访问。任何额外的 DMA 活动可以被预设为攻击行为。

• 解除恶意外设的能力：我们能够检测到发动攻击的外设。我们在一种我们称其为 BARM 的概念验证中实现并且评估了我们的检测模型。BARM 是足够高效和有效的，以使得它不仅仅能够检测到，并且还能够在攻击者能够造成任何伤害之前消除基于 DMA 的攻击的威胁。

• 运行时监视测量策略：我们实现了一种用于永久运行时监控的测量策略，它以可忽略的性能开销考虑了瞬时攻击，得益于 x86 平台上可用的 CPU 特性。

最后，我们的解决方案并不要求修改硬件或者固件。

5.1 通用检测模型

我们的检测模型的基础包括两个核心点。其一，内存总线是一种共享资源（参见图 5.1）。其二，系统软件，即操作系统，以 I/O 统计的形式记录了所有 I/O 活动。总线主控（CPU 和外设）通过内存总线连接到主内存。此总线为主内存提供且仅提供了一个必须被所有总线主控所共享的接口，参见图 5.1。我们将此共享资源看作某种 挂钩，或者称其为攻击者的死穴。此共享资源的事实可以被宿主 CPU 所利用以确定是否有其他总线主控正在使用该总线。例如，如果宿主 CPU 在一定时间内不能访问该总线，则操作系统可以得出结论，即其他总线主控正在使用该总线。

图 5.1 总线主控拓扑结构被利用以揭示恶意内存访问

如果测量得到的总线活动值 A_m 和预期的总线活动值 A_e 之差大于 0，则额外的总线活动 A_a 被检测出来，并且 DMA 攻击被揭示出来。

宿主 CPU / 操作系统能够多么精确地确定恶意总线活动取决于实现。我们调查了多种基于计时测量和总线传输监视地指导意见。例如，对总线传输的计时测量实验由 Li 等人 [83] 描述。内存传输的计时测量方法给出于 4.5.2 节。我们的实验揭示了总线传输事件计数是最为可靠的方法。我们于 5.2 节呈现了这种新方法的实现。

5.2 检测模型的一种实现

在本节中，我们描述了我们自己的基于总线传输事件计数的通用检测模型的实现。我们的概念验证的目标是确认宿主 CPU 能够检测到源自外设的基于 DMA 的攻击。我们为 Intel x86 平台实现了 BARM。我们将 BARM 作为一个 Linux 内核模块来开发。根据第 4 章所描述的实验，执行于具有独立 DMA 引擎的外设上的恶意软件可以隐秘地访问主内存。当基于 DMA 的内存传输被建立时，宿主 CPU 不一定被涉及进来。然而，内存总线不可避免地是一种共享资源，它由 MCH 来仲裁，参见图 2.5。这是我们为何期待总线主控在访问主内存时会产生副作用的原因。

我们分析了性能监视单元（PMU，参见 2.3 节）的能力以发现并且利用这样的 DMA 副作用。PMU 被实现为模型特定寄存器。这些寄存器可以被配置为对与性能相关的事件进行计数。PMU 的本意并非用于检测计算机系统上的恶意行为。它们的目的是检测性能瓶颈以允许开发者相应地改良受到影响的软件的性能 [104]。在本工作中，我们利用 PMU 以揭示针对平台主内存的基于外设的隐秘攻击。执行于外设的恶意软件不能访问处理器寄存器，因此也就不能通过修改 PMU 处理器寄存器来对宿主 CPU 隐藏其活动。我们的分析揭示了可以被 PMU 计数的内存传输事件。特别地，一种称为 BUS_TRANS_MEM 的计数事件总结了所有突发（完整缓存线）、部分读 / 写（非突发），以及无效内存传输 [71]。这正是 BARM 的基础。

取决于精确的处理器架构，Intel 处理器为每个处理器核心提供了 5 到 7 个性能计数器寄存器 [69，第 18 章]。在此种情况下，利用一个处理器核心最多可以并行计数 5 到 7 个事件。这些寄存器中的 3 个是固定功能寄存器，即它们所计数的事件不可更改。其他计数器是通用目的计数器，我们可以将其用于 BARM 以对特定的 BUS_TRANS_MEM 事件进行计数。如果我们正确地应用 BUS_TRANS_MEM 计数器，我们就能够成功地测量 A_m。此时，这一知识并不足以确定此传输是否排他性地与某一操作系统任务相关联，或者这其中是否有恶意传输。在下文中，我们为揭示源自某个受到攻击的具有 DMA 能力的外设的恶意传输奠定基础。

5.2.1 总线主控分析

在下文中，我们就其所造成的总线传输数量对宿主 CPU（与处理器总线系统相关）以及通用主机控制器接口（UHCI）控制器（与 PCIe 总线系统相关）的总线主控进行了分析。通过如此做，我们考虑了共享内存总线的总线系统中最重要的部分。其他总线主控，诸如硬盘和以太网控制器，可以按照某种类似的方式进行分析。

宿主 CPU 可能是最具挑战性的总线主控。CPU 造成巨大数量的内存传输。若干个处理器核心为众多进程存取指令和数据。针对由它们所造成的总线活动来高效地监控所有这些系统进程几乎不可能。因此，我们决定这样来分析宿主 CPU 的总线代理行为，即利用 BUS_TRANS_MEM 事件，并且与某些控制选项以及所谓的事件名称扩展相结合。我们实现了一种用于此类分析的 Linux 内核模块。我们的关键结果包括：(i) 由用户空间和内核空间的进程造成的总线事件可以由同一个计数器来计数。(ii) 事件名称扩展 THIS_AGENT 和 ALL_AGENTS 可以同 BUS_TRANS_MEM 事件 [参见 71] 配合使用以区分由宿主 CPU 以及所有其他处理器总线系统上的总线主控所造成的总线传输。THIS_AGENT 对与属于某个 CPU 总线代理的所有处理器核心相关的所有事件进行计数。而 ALL_AGENTS 则对连接到宿主 CPU 所连接到的总线的所有总线代理的事件进行计数。ALL_AGENTS 扩展对于我们的实现至关重要。它允许我们以总线传输数量的形式测量总线活动值 A_m（参见 5.1 节）：

A_m = BUS_TRANS_MEM.ALL_AGENTS （公式 5.1）

更进一步地，我们的分析揭示了一块宿主 CPU 并不一定准确地就是一个总线代理。一块多核心处理器可能包含若干个总线代理。例如，我们使用的是一块四核处理器（Intel Core 2 Quad CPU Q9650 @ 3.00 GHz），它包含两个总线代理。两个处理器核心共用一个总线代理，如图 5.2 所示。因此，对于判定合法或者非法传输，处理器核心的数量至关重要。注意，如果宿主 CPU 拥有若干个总线代理，有必要为每个总线代理启用一个计数器，并且带有 THIS_AGENT 事件名称扩展。有了这一知识，我们就可以确定所有总线主控的总线主控传输 A_m。我们能够区分宿主 CPU 的总线活动（参见公式 5.2）和由通过 MCH 访问主内存的所有其他总线主控所造成的总线活动（参见公式 5.3）。

A_m^CPU = ∑_n=0^H BUS_TRANS_MEM.THIS_AGENT_{cpu_bus_agent#n}, H ∈ N, H = 宿主 CPU 总线代理数量 - 1 （公式 5.2）

A_m^CPU= A_m - A_m^CPU ⇔ A_m = A_m^CPU +A_m^CPU（公式 5.3）

图 5.2 Intel 四核处理器

四核处理器包含两个总线代理，每个总线代理包含两个核心，参见 (a)。当同时利用两个总线代理，即 (b) 中的 BA#0 和 BA#1 对 BUS_TRANS_MEM 事件进行计数时，THIS_AGENT 名称扩展带来了显著的区别。(b) 中的内核日志同样描述了对应于名称扩展 ALL_AGENTS 的值在同一个计数器查询迭代内基本相同。

这意味着我们可以减去由所有处理器核心上运行着的用户空间和内核空间进程所造成的所有合法传输。注意，根据我们的信任和对手模型（参见 2.7 节），测量得到的宿主 CPU 的总线活动值和预期的宿主 CPU 总线活动值相同（A_e^CPU = A_m^CPU），由于运行于宿主 CPU 上的所有进程都可信。类似地，预期的总线活动值也可被分割，即 A_e = A_e^CPU +A_e^CPU。

通用主机控制器接口（UHCI）控制器是一种用于 通用串行总线（USB）设备，诸如 USB 键盘或者 USB 鼠标等的 I/O 控制器。USB 设备由 I/O 控制器轮询以检查是否有新数据。系统软件需要为 UHCI 控制器准备一组计划。此计划决定了某一被连接的 USB 设备如何被 I/O 控制器轮询。UHCI 控制器持久性地从主内存中检查其计划。显然，这一过程造成了大量总线活动。如果某次轮询报告有新数据可用，则更多的总线活动将会由 USB 设备产生。在下文中，我们将会分析这将会产生多少活动，即在为某个 USB 设备服务时，多少字节将会通过 UHCI 控制器传输。

在我们的案例中，I/O 控制器每毫秒分析其计划。这意味着控制器将会查找称为传输描述符的数据结构。为了获得描述符，控制器在每毫秒从某个列表中读取一个框架指针。一个框架指针（物理地址）引用到当前时间框架的传输描述符。传输描述符被组织进队列中。一个队列以队首开始，它可能包含一个指向首个传输描述符的指针，以及一个指向下一个队首的指针 [参见 62，p.6]。根据 Intel [62] 的说法，框架（指针）列表包含 1024 个项目，其大小为 4096 字节。UHCI 控制器需要 1024 ms（每毫秒 1 个项目）用于一个框架（指针）列表的迭代过程。借助于 Linux 的 UHCI 主机控制器设备驱动程序的最高调试模式，我们分析了一次迭代的总线传输数量。在该模式下，计划信息被映射到调试文件系统。我们确定了这些框架指针引用到中断传输队列（参见图 5.3 (d.i) 和 (d.ii)：int2，int4，……，int128），以及一个称为 async 的队列。int2 的涵义是，此队列被每隔 2 个框架指针引用，int4 指每隔 4 个，int8 指每隔 8 个，以此类推。async 队列被每隔 128 个框架指针引用。

图 5.3 UHCI 计划信息（简化）

此计划显示了 int 和 async 队列正在被使用。队列连接目标的物理地址被显示于方括号中。用于终止的队列连接或者队列元素所包含的值为 00000001 而非物理地址。此 int16 队列为我们的 USB 键盘负责。

未被指认的中断传输队列，即并未被用于轮询某一 USB 设备的队列，被重定向到 async 队列的队首，参见图 5.3 (b)。分析 async 队列要求 3 次内存读取访问，如图 5.3 (a) 所示。分析已被指认为轮询某一 USB 设备的中断传输队列需要多于 4 次内存读取。精确的内存读取次数取决于该队列中拥有多少元素。通常，如果该队列被指认给 USB 键盘，它只有 1 个元素。该队列可能还会拥有 2 个元素，例如该队列被指认给 USB 键盘和鼠标。如果该队列只有 1 个元素，分析整个被指认的中断传输队列需要 6 次内存读取，参见图 5.3 (c)。

我们的检查结果总结如下：

#总线读取传输 = 8 * #async 读取 + 8 * #int128 读取 + 16 * #int64 读取 + 32 * #int32 读取 + 64 * #int16 读取 + 128 * #int8 读取 + 256 * #int4 读取 + 512 * #int2 读取 （公式 5.4）

如果 int16 被指认给 USB 键盘，计算得到总共需要 4216 次总线读取，如图 5.3 (d) 所示。根据 Intel [62] 的说法，UHCI 控制器需要更新队列元素。我们期待这一点对应于 int16 队列的队列元素。此队列被 64 个框架指针所引用。因此，我们计算得到 64 次内存写入访问。这意味着总线传输的总数是 4280。我们成功地利用一块 Dell USB 键盘以及一块 Logitech USB 键盘，配合 UHCI 控制器的单步调试模式 [参见 62，p.11] 验证了这种行为，此信息通过位于 /sys/kernel/debug/usb/uhci/ 的 Linux 调试文件系统以及用于计数 BUS_TRANS_MEM 事件的性能监视单元所获取。

利用同样的设置，我们确定了当 USB 设备拥有新数据需要传输至主内存时所需的总线传输数量。对于 USB 键盘，我们精确地确定了需要且只需要 2 次总线传输以处理一次击键事件。这同样适用于按键释放事件。Linux 驱动程序通过中断例程来处理此类事件。因此，为了确定预期的总线活动 A_e^UHCI，我们需要来自操作系统的已处理中断的数量并且复制它。这意味着我们的范例中的总线传输总数是 A_e^UHCI = 4280 + 2 * #USB 中断。

为了处理整个计算机平台上的总线活动，诸如以太网控制器和硬盘控制器等所有其他总线主控的行为必须以类似于 UHCI 控制器的方式进行分析。当我们在一台 Lenovo ThinkPad 笔记本计算机测试我们的检测模型时，我们不得不分析一个额外的总线主控。我们不能在早期 ThinkPad 型号上通过 BIOS 关闭指纹读取器（FR）。因此，我们分析了指纹读取器并且在我们的实现中考虑了这个总线主控。我们确定了它会造成每毫秒 4 次总线传输。对于本工作，或者更准确地说，为了显示宿主 CPU 能够检测 DMA 攻击，对于 BARM 而言，考虑最多 5 个总线主控就足够了。除了基于 CPU 的两个总线主控以及 UHCI 控制器以外，我们还将 Intel 管理引擎（ME）看作一个总线主控。在正常操作中，我们假设 A_e^ME = 0。为了能够显示我们的检测模型适用于某一计算机平台，我们并未在我们的实验中使用该平台上的全部总线主控。例如，我们在我们的评估中的某些测试中从计算机的主内存中运行 Linux 操作系统（参见 5.3 节）。这允许我们按需使用硬盘控制器的 I/O 功能。

有了本节中所呈现的分析，我们已经能够确认哪个总线主控造成了多少内存传输。这些中间结果如图 5.4 所示。

图 5.4 对由 3 个活动的总线主控造成的内存传输进行分解

最上方的曲线描述了（在我们的设置中的）所有活动的总线主控所造成的所有内存传输数量，即 A_m。其下方的曲线描述了 A_m 减去第一个 CPU 总线主控的预期内存传输，即 A_m - A_e^{CPU BA#0}。再下方的曲线代表 A_m - A_e^{CPU BA#0} - A_e^{CPU BA#1}，最下方的曲线表示 A_m - A_e^{CPU BA#0} - A_e^{CPU BA#1} - A_e^UHCI。

5.2.2 总线代理运行时监视器

有了我们于 5.2.1 节引入的总线主控分析，我们就能够以 Linux 内核模块的形式实现 BARM。在本节中，我们描述了我们是如何实现一种能够永久地监控并且评估总线活动地监控策略的。性能监视单元已经被配置为测量 BUS_TRANS_MEM 事件。对于 A_m，即 A_m^CPU 和A_m^CPU的永久监控采用如下步骤实现：

1. 重置计数器并且存储所有非 CPU 总线主控（例如 UHCI、FR、ME、硬盘控制器（HD）、以太网控制器（ETH）、视频控制器（VC） 等）的初始 I/O 统计数据。

2. 开始对于一定时间 t 的计数（采用高精度计时器实现）。

3. 当到达时间 t 时停止计数。

4. 存储对应于 A_m 和 A_m^CPU 的计数器的值（参见 5.2.1 节），并且更新所有非 CPU 总线代理的 I/O 统计数据

5. 继续步骤 (1)，并且通过唤醒对应的评估内核线程来并行确定 A_e。

我们还需要比较测量得到的总线活动和预期总线活动。BARM 在按照如下步骤执行评估内核线程时比较A_m^CPU和A_e^CPU：

1. 利用所存储的对应于 A_m 和 A_m^CPU 的计数器的值来确定A_m^CPU（参见 5.2.1 节）。

2. 利用 A_e^UHCI、A_e^FR、A_e^ME、A_e^HD、A_e^ETH 和 A_e^VC 等来计算A_e^CPU，这些值来自于所存储的更新过的 I/O 统计数据与所存储的初始 I/O 统计数据之差值。注意，对于我们的实现，我们假设 A_e^HD = 0，A_e^ETH = 0 等。

3. 比较A_m^CPU和A_e^CPU，报告结果，并且如有必要则应用某种防御机制。

出于实践性，我们需要重新定义如何计算 A_a。我们利用 A_a 来解读我们的概念验证实现中的 PMU 测量结果。原因之一是 PMU 计数器不能被同时开始 / 停止。开始 / 停止某个计数器需要非常少的处理器周期，并且计数器是被逐个开始 / 停止的。同样的事情可能发生于非常短的时间之内，在此，计数器被停止以便被读取和重置（参见永久监控时的步骤 (3) 和步骤 (2) 之间的时间框架）。类似的不精确性可能发生于读取操作系统 I/O 统计数据时。因此，我们引入了容错值 T ∈ N，并且精炼 A_a：

A_Ta = 0, 如果 |A_m - A_e| ∈ {0, …, T}</br>A_Ta = |A_m - A_e|, 如果 |A_m - A_e| ∉ {0, …, T} （公式 5.5）

T 的值是可以自由选择的数字，用于表示 BARM 在检查额外的总线流量时可以容忍的总线传输次数。我们的评估显示了有用的 T 是一个非常小的值（参见 5.3 节）。此外，我们必须考虑 T > 0 的值在理论上赋予了攻击者隐藏攻击的机会，即发动瞬时攻击的机会。在最佳案例中（参见图 5.5），此隐秘攻击可以最多拥有 2 T 的总线传输。然而这 2 T 的总线传输不太可能足以用于一次成功的攻击。而在平台重启之后，数据很可能不在同一内存位置。因此，内存必须被重新扫描以查找有价值数据，而这需要大量的总线传输。由现代操作系统所应用的地址空间布局随机化（ASLR，同时参见 4.3.3 节）等机制同样使得搜索过程复杂化。这会导致更多的总线传输。更进一步地，攻击者需要知道 BARM 不得不容忍 - T 传输的非常精确的时间点。

图 5.5 容错值 T

如果攻击者能够预测非常精确的时刻，在此 BARM 认为 T 是太少的总线传输，则具有 2 T 的总线传输的攻击在理论上可以隐秘地执行。

如果 A_Ta > 0，则 BARM 检测到了来自某个平台外设的基于 DMA 的攻击。知道有这样的攻击正在被执行已经具有很大价值。可以被应用于阻止一次攻击的一种简单的防御策略是利用所有不可信的总线主控的 BME 位（参见 2.5 节）来移除其总线主控能力。这样一种策略可能并不充分，如果所有平台特性都被要求能够运作。而如果没有进一步措施，这也可能导致数据丢失。然而，一台受到这样一种有目标的攻击的系统应该被下线以接受仔细的检查。

在终止不可信的总线主控时，BARM 会在平台屏幕上为用户放置一则通知。A_Ta 并不包含任何关于何种平台外设正在执行攻击的信息。为了在通知消息中包含此信息，我们实现了一种能够识别可疑外设的简单外设测试。在当 DMA 攻击仍在查找有价值数据时，我们通过逐个解除不可信的总线主控的 BME 位来揭示恶意外设。在 BME 位解除之后，BARM 检查额外总线活动是否消失。如果消失，则恶意外设被识别出来，并且该外设的名称被添加到攻击通知消息中来。如果 BARM 仍然检测到额外的总线活动，则此错误外设的 BME 位被重新设置。在外设测试阶段，操作系统必须不能触发任何 I/O 任务。我们的评估结果揭示了我们的测试可以在几毫秒之内执行完毕，参见 5.3 节。攻击行为处于活动的时间需要略长于我们的外设测试，否则，我们的测试便不能保证识别出恶意外设。第 4 章所述的针对 Linux 系统的 DMA 攻击需要 1000 ms 到 30000 ms 以扫描内存。我们的评估显示了 BARM 能够快得多地检测并且终止这一 DMA 攻击。

5.3 关于检测模型实现的评估

我们评估了作为 Linux 内核而实现的 BARM。首先，我们引导了一些测试以确定有用的容错值 T。在本节的主要部分，我们呈现了关于我们的解决方案的性能开销评估。我们显示了由 BARM 造成的开销是可忽略的。最后，我们引导了一些实验以评估在攻击过程中 BARM 的行为。

5.3.1 容错值 T

我们执行了若干组不同的测试以确定一个有用的容错值。我们重复了本组测试 100 次。若干种不同的测试意味着我们对于 BARM 评估了不同的 PMU 值采样区间（32 ms，128 ms，512 ms，1024 ms 和 2048 ms）、不同的 CPU 核心数（1 至 4 个核心）、不同的内存大小（2 GiB，4 GiB，6 GiB 和 8 GiB）、不同的平台（Intel Q35 台式机 / Lenovo ThinkPad：T400，X200，X61s），以及最低（节能模式）和最高（性能模式）CPU 频率，以检查它们对 T 的影响。更进一步地，我们对 BARM 进行了 CPU 和内存压力测试评估。CPU 压力测试意味着并行运行针对一个 100 MB 的测试文件的 sha1sum 命令 100 次以保证 CPU 使用率 100%。对于内存压力测试，我们将此 100 MB 的测试文件从主内存中的一个位置复制到另一个位置 2000 次。我们的平台拥有如下配置：Q35——Intel Core 2 Quad CPU Q9650 @ 3.00 GHz，4 GiB 内存；T400——Intel Core 2 Duo CPU P9600 @ 2.66 GHz，4 GiB 内存；X200——Intel Core 2 Duo CPU P8700 @ 2.53 GHz，4 GiB 内存，以及 X61s——Intel Core 2 Duo L7500 @ 1.60 GHz，2 GiB 内存。我们将采样区间 32 ms，1 个 CPU 核心，4 GiB 内存，Q35 平台，以及最大 CPU 频率作为基本评估配置。在每次测试中，我们只更改这些属性中的一个。结果总结于图 5.6 中。

图 5.6 确定足够的容错值 T

图 (a)-(f) 呈现了利用不同测试对 BARM 进行评估时的 A_a 计算结果的差值。BARM 执行了每种测试 100 次以确定 A_a。关于差值，我们是指最大和最小 A_a 之差。图 (a)-(f) 以盒图的形式显示了差值。对于每一种测试，对应的 A_a 的最小值、较低的四分位数、中位数、较高的四分位数以及最大值被描述出来。最小值和最大值之间的小点表示 A_a 平均值。A_a 的值一般位于 -10 到 10 之间。最大的绝对值为 19，参见图 (e) 之 X61s。

注意，为了确定 T，我们考虑了最多 5 个总线主控（1 至 2 个 CPU，一个 UHCI，一个指纹读取器，以及一个 ME 的总线主控）。我们使用 SliTaz Linux 发行版 [脚注 16]，它允许我们从内存运行 Linux 操作系统。其结果是我们能够选择性地激活或者取消激活诸如硬盘控制器总线主控这样的不同组件。总体测试结果展示了一种最差案例，其测量得到的和预期的总线传输之差值为 19（绝对值）。这一结果确认了这种关于总线活动的测量和评估能够得到可靠的值，即这些数值几乎没有任何波动。然而，为了安全起见，我们在利用一种基于 DMA 的隐秘击键码记录器评估 BARM 时使用的容错值是 T = 50，参见 5.3.3 节。

脚注 16：参见 http://www.slitaz.org/ [访问于 2014 年二月 25 日]

5.3.2 永久监控时的性能开销

由于 BARM 仅仅直接影响宿主 CPU 和主内存，我们评估了关于这两种资源的性能开销。BARM 在监控时并不访问硬盘或者网卡。我们利用 64 位 Ubuntu 内核（版本 3.5.0-26）评估了 BARM。在测试过程中，我们以最高频率运行宿主 CPU 以使其造成尽可能多的总线活动。更进一步地，我们使用 1 个或者 2 个 CPU 总线主控来执行我们的测试，以确定 CPU 总线主控的数量是否对于性能开销具有任何影响。最终，我们需要为第二个 CPU 总线主控使用更多的处理器寄存器（PMU）。另一件重要的事情是对采样区间的评估。因此，我们利用不同区间对 BARM 进行了配置并且检查了开销。为了测量开销，我们为所有测试使用了时间戳计数器（参见 2.3 节）。这些评估的结果如图 5.7 所示。

图 5.7 宿主性能 CPU 和内存开销评估

我们利用内存（MEM）和 CPU 基准测试测量了开销。每次测试使用 1 个在线的 CPU 核心（1 个 CPU 总线主控）或者 4 个在线的 CPU 核心（2 个 CPU 总线主控），参见图 (a) 和 (b)。首先，我们进行了不带 BARM 的基准测试以建立一组基线。随后，我们在启用 BARM 的情况下重复了这一基准测试（采样区间 32 ms）。其结果以相对开销的形式呈现。CPU 基准测试并未揭示任何显著开销。内存基准测试揭示了大约 3.5% 的开销。在线 CPU 核心数 / CPU 总线主控数对于开销没有影响。更进一步地，我们在使用不同的采样区间运行 BARM 时检查了其开销，参见图 (c) 和 (d)。同样，CPU 基准测试并未揭示任何开销。内存基准测试结果揭示了开销可以通过选择较长的采样区间而减少。较长的区间并不会阻止 BARM 检测 DMA 攻击。然而，较长的区间 可能 意味着攻击者在其攻击被检测到并且被终止之前已经造成了某些伤害。

5.3.3 展示 BARM 的有效性的一个应用案例

即使我们并未在我们所呈现的概念验证实现中考虑平台上的全部总线主控，我们仍然可以展示 BARM 的有效性。这是可能的，由于并非所有的平台总线主控都是每一项敏感应用所必需的。例如，如果用户输入口令或者其他敏感数据，则只有 UHCI 控制器和 CPU 是必需的。我们利用 Linux 上的口令提示符评估了 BARM。我们设置了一组环境，当使用 sudo 或者 ssh 命令时，有 4 个总线主控是活动的（2 个 CPU，一个 UHCI 和一个 ME 总线主控）。BARM 与 sudo 或者 ssh 命令一同启动，并且在口令被输入时停止。BARM 终止了非必需的总线主控并且在口令提示符通过之后立即重启它们。我们利用我们自己的基于 DMA 的击键码记录器 DAGGER 攻击了此口令提示符，它执行于 Intel ME 之上，参见第 4 章。DAGGER 利用 DMA 扫描主内存以查找键盘缓冲区的物理地址，而这也是通过 DMA 被监控的。

图 5.8 利用口令提示符（ssh 命令）于运行时的任意时间点评估 BARM

BARM 每隔 32 ms（采样区间）检查一次额外总线活动 A_a。如果测量值高于容错值 T = 50，则 A_a 被发现。如果平台未被攻击，则这些值低于 T，参见图 (a) 和 (b) 之“无 DAGGER”。图 (a) 描述了这样一种攻击，在此，DAGGER 已经在等待用户输入口令。BARM 在首次测量时就检测到了 DAGGER 并且几乎立即将其终止。图 (b) 描述了 DAGGER 试图在运行时的任意时间点攻击平台，其结果类似。图 (c) 是在如图 (b) 所示的攻击企图过程中由 BARM 生成的内核日志。

图 5.8 (a) 可视化了当平台受到攻击时 BARM 所采取的措施。受到攻击意味着在用户被提示输入口令时，DAGGER 已经被加载。图 5.8 (b) 描述了平台在运行时的任意时间点受到攻击时 BARM 的处理结果。为了便于比较，图 5.8 (a) 和 (b) 还可视化了当平台未受攻击时 BARM 的测量结果。图 5.8 (c) 是内核日志的一部分，它确认了 BARM 是多么快地终止了 DAGGER。BARM 于时间戳 350.401045 s 检测到了 DMA 攻击。BARM 于时间戳 350.465042 s 识别了基于 DMA 的恶意外设。这项测试确认了 BARM 能够在攻击者造成伤害之前检测到攻击。当击键码记录器仍然处于搜索模式时，BARM 就终止了其攻击。这意味着击键码记录器并未找到键盘缓冲区。因此，攻击者不能捕获任何击键。我们将 BARM 配置为具有 32 ms 的 PMU 值采样区间。我们的评估揭示了在这段时间内，攻击者已经造成了超过 1000 次内存传输。这意味着我们甚至可以选择一个远大于 T = 50 次总线传输的容错值。

5.4 当前的 BARM 实现的局限性

尽管对于当前的检测模型的实现的评估显示了 DMA 恶意软件可以利用可忽略的性能开销而被检测到，当前的实验仍然具有若干局限性。直到目前，我们只考虑了一个特定的 UHCI 控制器、一个指纹读取器、2 个 CPU 总线代理，以及一个 ME 外设作为总线主控（参见 5.3 节）。即使我们知道每一个总线主控都只能通过唯一的接口访问主内存，我们仍然不能排除这样的可能性，即当前用于此检测模型的方式不足以将所有可能的总线主控都整合进来。当前所整合进来的总线主控足以显示 BARM 可以检测到 DAGGER。此外，我们只考虑了某一代的 Intel 芯片组。这意味着关于其他世代芯片组以及其他厂商制造的芯片组的额外调查对于确定 BARM 在多大程度上普遍适用是必要的。

另一种局限性来自于我们利用一种 DMA 恶意软件范例来测试 BARM 这一事实。尽管 DAGGER 代表了典型的 DMA 恶意软件，即它必须在宿主内存中搜索有价值数据、并不要求同宿主软件进行任何合作，以及通过系统内存接口访问主内存，我们仍然不能排除可能有其他 DMA 恶意软件实现机制以绕过 BARM。例如，理论上对手可以试图利用每个采样区间（参见图 5.5）中的 2 T 总线传输。这意味着对手可以隐藏多达 2 T 的总线传输，如果有可能预测到非常精确的时刻，在此，BARM 认为 T 是太少的总线传输。

然而，即使对手找到了某种方式以利用每个采样区间中的 2 T 总线传输，这也会导致查找有价值的宿主数据的搜索阶段更加迟缓。这 2 T 的总线传输明显少于在一个采样区间内通常可供对手使用的总线传输。与之相反，取决于在宿主内存中查找目标数据的搜索时间，宿主 CPU 可以利用延迟的搜索以进行例如重新安排内存地址空间等行动。这将会迫使对手重启搜索阶段。因此，BARM 应该利用额外的 DMA 恶意软件范例进行测试，以确认 BARM 也能检测除了 DAGGER 以外的 DMA 恶意软件。

诸如以太网控制器等总线主控可以试图绕过 BARM，通过 (i) 忽略将要通过 DMA 被复制的数据的源地址，以及 (ii) 利用由需要被复制以攻击宿主内存的数据长度决定的总线传输数量。源地址和长度是在例如宿主想要发送一个网络数据包时由宿主提供的。对手只需利用由此长度确定的总线传输数量。因此，BARM 不会检测到任何额外的总线活动，由于对手将非法总线传输伪装成了预期总线传输。此类攻击可以看作由网卡引导的中间人攻击。为了能够成功引导这种中间人攻击，攻击者还需要准确地确定预期的以太网控制器总线传输的数量。第 6 章呈现了如何考虑由网卡引导的中间人攻击。这一章还展示了正确的预期以太网控制器总线传输数量难于计算（相对于 UHCI 控制器）。因此，对手必须在计算预期的以太网控制器总线传输时考虑由此造成的潜在的性能开销。

5.5 本章小结

在本章中，我们展示了宿主 CPU 能够检测源自受到攻击的外设的额外的，即隐秘的和恶意的主内存访问，其基本理念是内存总线是一种共享资源，攻击者不能绕过它而攻击平台的主内存。这是攻击者的死穴，而我们则利用它来构建我们的检测模型。我们对通过宿主系统软件而获知的预期总线活动和实际总线活动进行比较。实际总线活动之所以可以被监测，是由于该总线是一种共享资源这一事实。我们开发了概念验证实现 BARM 并且利用最多 5 个总线主控评估了我们的方法，这其中包括现代计算机平台中最为重要的总线系统（PCIe、FSB、内存总线）。BARM 还可以在受到攻击的外设造成任何伤害之前将其识别出来并且禁用。

由于宿主 CPU 可以检测 DMA 攻击，我们得出结论，即宿主 CPU 可以防御自身而无需对固件或者硬件进行任何修改。平台用户不必须依靠诸如 I/OMMU 等预防性机制。我们选择实现一种能够永久监控总线活动的运行时监控策略。我们的监控策略考虑到了瞬时攻击。相关工作章节（参见 3.2 节）所呈现的反制措施，诸如签名固件和基于延时的证言等并未考虑瞬时攻击。与基于延时的证言方法，参见 3.2.3 节，相比，BARM 可以通过较少的努力而实现，并且无需关于外设的固件或者硬件的内部工作方式的知识细节。

我们同样鉴定了当前的 BARM 实现的局限性，诸如理论上可被利用的每个采样区间中的总线传输范围（2 T），或者某种由以太网控制器引导的可能的中间人攻击。BARM 不能检测由网卡实施的中间人攻击，而这可以被基于延时的证言方法揭示出来。这样的攻击也可以通过以某种可信信道 [52] 的形式应用端对端安全性来防止。我们在第 6 章采用可信信道的概念以使得 BARM 能够检测中间人攻击。此外，我们的 BARM 评估显示了性能开销是可忽略的。因此，我们得出结论，即我们的方法可以在实践中被部署。

第 6 章 向外部平台进行合法报告

在互联网上使用加密，就像安排一辆装甲车将信用卡信息从一位住在纸箱里的人那里送到一位住在公园长椅上的人那里。——Gene Spafford，计算机科学教授

我们实现一种用于状态报告的合法信道应用的动机是将 BARM 的测定结果发送至某个被保护起来以防止 DMA 攻击的外部平台。此外部通讯伙伴可以评估所传输的测定结果以检查其对端是否被 DMA 恶意软件所攻击。此测试结果基于处理器寄存器的值（参见 5.2 节）。为了排除网卡上的恶意软件修改并且伪造流出的网络数据包，我们需要一种安全的通讯信道。这样一种信道不仅仅保证所传送的数据的机密性、完整性和新鲜性，而且还能保证信道端点的合法性。为了实现这样一种信道，我们采用了我们于早期工作 [52，10] 中所呈现的一种可信信道的概念。

可信信道是这样一种通讯信道，它不仅实现了安全信道的属性，并且额外地将通讯端点的状态信息绑定到通讯会话。基于 IPSec 或者 TLS 部署一种安全信道对于我们的案例来说并不足够。基于 IPSec 或者 TLS 的安全信道能够保证所传送的数据的机密性、完整性和新鲜性。然而，这些信道并未绑定到实际的通讯端点。我们为 BARM 实现基于可信信道的报告应用是为了至少能够防止下列攻击。这些攻击可以由执行于网卡上的恶意软件所引导。此类恶意软件可以通过拦截或者损坏流出的网络数据包来阻止 BARM 同外部平台进行通讯。攻击者还可以利用这样的恶意软件来通过 DMA 偷取存在于宿主的主内存中的用于该安全信道的密钥素材。随后，攻击者就可以引导中间人攻击。此恶意软件还可以中继来自第三方平台的平台状态信息。这意味着可以通过引导 中继攻击 来欺骗管理员平台。

对于我们的合法报告信道，我们至少要求安全信道的属性（要求 R1）以保证所传输的数据的机密性、完整性和新鲜性 [参见 52，p.32]。机密性属性保证攻击者只能得到最小化的信息。完整性属性保证了损坏的网络数据包将会被立即揭示出来。新鲜性属性防止攻击者引导重放攻击，在此，一次有效的通讯会话被记录下来并且在随后被重放。为了揭示对包括平台状态信息在内的数据包的拦截攻击，我们引入了所谓的 心跳 消息作为负载，它必须在通讯会话过程中被发送。计算机科学中的心跳是这样一种信号，即对应的软件仍然在线并且正在运行 [132]。

心跳消息包含当前的 BARM 测定结果，而如果某次攻击被阻止，则还包括日志信息。如果由于攻击而导致网卡被终止，则心跳消息不再被外部平台接收到。此行为将会被外部平台解读为基于网卡的攻击。被传送的信息还包括状态改变。状态改变同样被可信信道概念所考虑 [52，10]，但是缺少如同在 BARM 中所实现的那样的具有可忽略的性能开销的高效并且有效的运行时监控 [参见 52，p.36]：“某一平台的状态改变将会被 CM（一种假想的高效监控代理）注意到……”在我们的 DMA 恶意软件场景中，BARM 代表了缺失的“监控代理”。

与前期工作 [52，10] 相比，用于我们的 DMA 恶意软件场景的信任和对手模型并不要求由 TCG 所提议的可信计算机制，参见 2.7 节。我们的信道并不基于 TPM，由与我们并不依赖加载时的代码完整性检查，参见 3.2.1 节。从信道到存储于 TPM 中的加载时测定结果的连接在我们的应用中并非必需。我们要求由 BARM 确定的结果被绑定到我们的信道（要求 R2）。这在通讯会话协商以及通讯会话本身的过程中都是必要的。

请注意，我们并不依赖诸如 Intel 的 VT-d 实现等 I/OMMU 机制。这是与我们的早期工作 [52] 中的信任模型之间的另一个差别。此技术在我们的结果被发表 [52] 之前不久被引入。这意味着先前的作者并未遇到如 4.5.1 节所呈现的 I/OMMU 问题。先前的工作假设存在能够正确配置 I/OMMU 的驱动程序。对于本工作，我们更加详细地分析了 I/OMMU，并且我们决定并不依赖 VT-d 用于我们的合法报告信道。我们的先前工作还引入了关于隐私的要求（要求 R3）。这意味着此信道只考虑了最少的信息范型以便将平台状态信息的公开最小化到仅仅包含基本必要信息。

本章的主要贡献如下：

• 将网卡排除在端点之外的合法报告信道：执行于网卡上的恶意软件能够从主内存中偷取私钥素材以引导中间人攻击。因此，我们开发了一种合法报告信道，它保证只有宿主 CPU 才是通讯的端点。我们的信道基于安全信道协议 TLS。我们采用 TLS 协议以交换 BARM 测定结果，并且将此信道绑定到其本意的端点上。我们的通讯信道的一个额外特性是平台状态改变的报告。这意味着我们的运行时监视器 BARM 通过合法报告信道持久性地将与 DMA 恶意软件有关的每一次状态改变传送至通讯伙伴。我们对于 TLS 的修改基于 TLS 扩展。这意味着我们的信道符合 TLS 规范。我们的 TLS 合规信道是首个考虑到了与 DMA 恶意软件相关的平台状态报告的信道。它还是首个基于一种已实现的、有效和高效的运行时监视器以报告状态改变的信道。先前的工作仅仅预设了这样一种运行时监视器的存在。

• 对于以太网控制器的分析：我们的通讯信道要求使用网卡。因此，以太网控制器将会引发总线传输。这些总线传输必须被 BARM 所考虑。本章展示了以太网控制器可以被如何整合进 BARM 的检测模型，即如何将以太网控制器用作一个额外的总线代理。

• 利用一个新的参数改良 BARM 的检测模型：以太网控制器传输数据包，其大小大于地址指针和击键码。我们展示了对于 BARM 的检测模型而言，缓存线的大小是一个重要参数。缓存线大小对于正确计算预期总线传输数量是必要的。

• 利用额外的性能监视单元事件：我们展示了某些性能监视单元配置可以被利用以区分内存读取总线传输和内存写入总线传输。这允许我们检查由以太网控制器所造成的预期读取总线传输和预期写入总线传输的数量是否被 BARM 的检测模型所正确地确定。

下一节以对合法报告信道的描述开始。随后，我们将会解释我们如何实现这一模型。

6.1 独立于实现的模型

我们的信道模型考虑了客户端 C（目标平台）和服务器 S（外部平台）之间的通讯。每个端点都可以请求该端的平台状态信息（即 BARM 测定结果）。本地安全策略决定了该端的平台状态信息被评估之后准确地将会发生什么。我们的合法报告信道由宿主 CPU 软件所控制。此信道可以通过一块潜在地被攻击的网卡来进行协商。我们在下一节描述了一种用于协商和维持一条合法报告信道的高级协议。请注意，在下文中，我们省略了上标 C 和 S，由于该协议的对称特征。

6.1.1 协商一条合法报告信道

我们的合法报告信道的重要理念之一是防止平台外设访问诸如私钥素材等与此信道相关的敏感信息。只有宿主 CPU 软件被允许使用信道的敏感信息。请注意，外设可以通过 DMA 偷取这些信息。然而，BARM 将会揭示并且终止此类 DMA 攻击，参见 5.3.3 节。图 6.1 描述了为 BARM 协商一条合法报告信道的握手协议。为了引导握手，双方需要一组签名密钥 K_sign，它是非对称密钥对，即 K_sign := (PK_sign, SK_sign)。更进一步地，双方都需要一份证书 Cert，它包含 PK_sign，以及宿主 CPU 软件组件标识符（BARM_ID）。此证书由可信实体签发，该实体可以是外部管理员平台。签名密钥和证书是在协商一条合法报告信道之前创建的。每个端点验证其对端的包含 BARM_ID 的证书。

图 6.1 协商一条合法报告信道

在客户端 C（目标平台）和服务器 S（例如外部管理员平台）之间协商一条合法报告信道

• NIC：网卡

• K_sign：绑定到宿主 CPU 软件组件的非对称签名密钥对 (PK_sign, SK_sign)

• PK：公钥

• SK：私钥

• Cert：绑定到宿主 CPU 软件组件的密钥对的经过验证的公钥部分

• BARM_ID：宿主 CPU 软件组件标识符

• sec_param：所要求的安全性参数

• state_data：由 BARM 测定得到的平台状态数据

• SigStD：平台状态数据的签名

• SeKey：会话密钥

此信道的创建始于安全性参数的协商。这意味着每个实体以安全性参数的形式将其证书证书和安全性要求发送至其对端。此安全性参数决定了哪些实体需要报告其平台状态信息。每个端点检查其对端的安全性要求是否可接受。在下一步中，每个实体将其平台状态数据（当前 BARM 测定结果）发送至对端。此状态数据经过数字签名，并且对应的签名连同状态数据一同传送。这保证了所接收到的状态数据是由预期的通讯伙伴所发送的。双方利用由该端作为其证书 Cert 的一部分而发送的 PK_sign 验证签名。如果签名有效，则双方验证状态数据。此握手可能会由于攻击该端的 DMA 恶意软件而取消。这是当所传送的 BARM 测定结果大于容错值 T（参见 5.2.2 节）时所发生的事情。当客户端和服务器都成功验证了所交换的数据以后，同一会话的密钥被双方平台所计算并且确认。此计算出来的会话密钥将会被绑定到此通讯会话。在合法通讯会话确认就绪以后，双方开始周期性地发送心跳消息。

心跳消息要么确认当前平台状态，要么报告某种状态改变。被报告的平台状态可以揭示该端正在受到 DMA 恶意软件的攻击，此时该可疑外设可以被终止，或者并未检测到攻击。如果该端停止发送心跳消息，则本地平台假设该端受到了执行于网卡上的 DMA 恶意软件的攻击。在此情况下，BARM 已经通过终止网卡而成功地终结了正在进行中的 DMA 攻击。取决于本地安全策略，此平台可以中断该信道，继续当前会话密钥，或者重新协商此信道。如果心跳消息报告此次攻击可以被立即终止并且本地安全策略宣称此类案例是可容忍的，则继续当前会话密钥是有利的。更准确地说，如果平台在没有受到影响的外设的情况下仍然能够正常工作，则这可能是有意义的。在涉及管理员平台的情况下，我们期待管理员将会尽快更加详细地分析此次攻击，以便从受到攻击的外设中移除 DMA 恶意软件，或者如果绝对必要，将受到攻击的外设或者芯片组替换为良好的。

6.2 用于 BARM 的合法报告信道的实现

第 5 章所述的 BARM 并不足以用于基于合法信道的报告应用。当 BARM 发送网络数据包时，它也会造成需要被 BARM 本身的检测模型所考虑的总线活动。为了为我们的 DMA 恶意软件场景实现一种合法信道应用，我们已经 (i) 改良了 BARM 的检测模型，参见 6.2.1 节，以及 (ii) 修改了 TLS 协议以便将 BARM 测定结果（状态信息）绑定到该信道，参见 6.2.2 节。

6.2.1 总线主控分析：以太网控制器

为了在 BARM 的检测模型中考虑以太网适配器，我们必须确定预期的总线活动值 A_e^ETH。因此，我们为我们的目标平台的以太网控制器引入了如 5.2.1 节所述的类似的总线主控分析。我们分析了与之前的实验相同的目标平台的以太网控制器（其名称为 Ethernet Controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) [65]），参见第 4 章和第 5 章。对应的以太网控制器的 Linux 设备驱动程序为 e1000e.ko。为了简化我们的分析，我们将此驱动程序配置为使用传统中断，没有中断延时或者中断限速。我们同样禁用了该网络设备的校验和和段卸载。

此以太网控制器利用所谓的描述符环进行工作，即传送描述符环和接收描述符环，参见图 6.2。每个环包括 256 个描述符。每个描述符的大小为 16 字节。这意味着该设备驱动程序为每个环分配 4096 字节。如果宿主想要发送网络数据包，它需要准备传输描述符并且通知以太网控制器新的描述符已经处理就绪。以太网控制器通过 DMA 从宿主内存中读取描述符。在评估描述符之后，此控制器将网络数据包的数据从存在于描述符中的宿主内存地址（参见图 6.2）复制到其内部的内存，以便能够发送数据包。如果以太网控制器已经处理了描述符，则该控制器通过 DMA 向描述符的 status 字段写入 descriptor done bit 位，以便将该描述符“返回”宿主。当接收网络数据包时，其过程与之类似，除了以太网控制器是将网络数据包的数据写入宿主内存以外。

图 6.2 传送 / 接收描述符环的结构

当设备驱动程序通知网卡新的网络数据包已经准备好可供传送时，以太网控制器从描述符环中读取传送描述符。此控制器还会从宿主内存地址读取存储于描述符的 length 字段中的对应数据包的大小，而此地址存储于该描述符的 address 字段。当描述符处理完毕时，以太网控制器向描述符的 status 字段写入 descriptor done bit 位。当新的网络数据包通过网络到达时，以太网控制器从描述符环读取接收描述符。随后，此控制器向宿主内存地址中写入存储于描述符的 length 字段中的对应数据包的大小。此地址存储于描述符的 address 字段。如果此描述符处理完毕，以太网控制器向描述符的 status 字段写入 descriptor done bit 位。

为了将以太网控制器作为一个总线主控整合进 BARM 的检测模型中来，我们必须考虑网络数据包的大小通常大于击键码这一事实，参见 5.2 节。击键码是通过一次总线传输完成的。这并不适用于网络数据包，例如后者可能拥有 1514 字节的大小。为了能够确定传输一定数量的数据需要多少次总线传输，我们引入一个新的参数，即 缓存线大小。系统缓存被组织为缓存线。内存访问被处理为具有 C ∈ N [参见 127，p.223] 的特定大小的缓存线。对于我们的平台，C 为 64 字节 [参见 63，p.17]。这意味着，如果从主内存中请求一个字，则一次内存传输中实际传输了 64 字节。假设在宿主内存中相邻存储的数据很可能在一次后续的操作中被访问，如果是这样，则这些字节已经位于缓存中，并且无需额外的传输。外设的内存访问同样是以缓存线的方式被处理的。有可能必须对这样一次传输进行嗅探以保证具有一致性的缓存线 [参见 63，p.27]。

对于 e1000e.ko 驱动程序的描述符转储描述了网络数据包的宿主内存地址，参见图 6.3。次转储也揭示了并非每个地址都是按照缓存线对齐的。这意味着通过 DMA 传输该网络数据包数据所需的总线传输次数并不一定就是存储于 length 字段中的值除以缓存线大小。另一个重要问题于接收描述符的处理相关。根据 Intel [65]，以太网控制器对返回接收描述符的过程进行了优化。这意味着，当接收数据包时，以太网控制器并非为每一个描述符都单独写入 descriptor done bit 位。与之相反，它会“集齐”属于同一缓存线的 4 个描述符以便能够在一次总线传输中写入 4 个 descriptor done bit 位，参见图 6.2。我们为计算由以太网控制器所造成的预期总线传输的公式同时考虑了这两种场景。

图 6.3 e1000e.ko 驱动程序的传送 / 接收描述符转储

此转储揭示了导出由以太网控制器所造成的总线传输数量所必需的最重要信息。某些宿主内存地址并未对齐到缓存线，这可能导致一次额外的总线传输。

根据我们的分析，我们将以太网控制器的预期总线活动定义如下：

A_e^ETH = A_e^TX_reads + A_e^TX_writes + A_e^RX_reads + A_e^RX_writes （公式 6.1）

A_e^TX_reads 是传送数据包时的内存读取所造成的预期总线活动。A_e^TX_writes 代表此过程中由内存写入所造成的活动。类似地，A_e^RX_reads 和 A_e^RX_writes 被引入以考虑接收网络数据包时的总线活动。为了计算 A_e^TX_reads，A_e^TX_writes，A_e^RX_reads，和 A_e^RX_writes，对于一个 BARM 采样区间，我们必须考虑被读取和写入的内存缓冲区的缓存线大小。这意味着对于在宿主内存中用于存储网络数据包数据的内存缓冲区，我们必须对齐内存缓冲区的起始地址，它存储于描述符的 address 字段（hma ∈ N），将其对齐到上一段与缓存线相对齐的地址。其结果为 ba_start ∈ N：

ba_start = hma - (hma mod C) （公式 6.2）

内存缓冲区的结束地址（ba_end ∈ N），它是描述符中的 address 字段的值（hma）和 length 字段的值（len ∈ N）之和，的对齐方式如下：

ba_end = hma + len + C - ((hma + len) mod C) （公式 6.3）

描述符的传输要求同样的对齐方式。传输起始地址由之前的采样区间（d_old ∈ N）的最后一个描述符的描述符编号所决定。传输结束地址由当前采样区间（d_cur ∈ N）的最后一个描述符的描述符编号所决定。在考虑到缓存线大小时，描述符编号 d_start ∈ N 和 d_end ∈ N 的对齐结果如下所示（D ∈ N 是描述符的字节数，即在我们的案例中是 16 字节）：

d_start = old_d - ((old_d * D) mod C) / D （公式 6.4）

d_end = (cur_d * D + C - ((cur_d * D) mod C)) / D （公式 6.5）

对于一个采样区间，A_e^TX_reads，A_e^TX_writes，A_e^RX_reads，和 A_e^RX_writes 的计算如下：

A_e^TX_reads = ∑_n=1^{cur_dTX - old_dTX} (1 + (ba_end_n^TX - ba_start_n^TX) / C) （公式 6.6）

有必要为每一个传送描述符增加一次内存读取的总线访问，由于对应的描述符存取（根据我们的实验）并非按照缓存线优化。这与写入 descriptor done bit 位的处理方式不同。在此种情况下，以太网控制器试图写入尽可能多的 descriptor done bit 位。对于一次总线传输的最大值是 4 位。

A_e^TX_writes = (d_end^TX - d_start^TX) * D / C （公式 6.7）

在接收网络数据包时，内存读取仅仅会由于存取接收描述符而产生。我们已经确定，以太网控制器在我们的实验过程中利用一次内存读取总线传输存取 4 个接收描述符（等于缓存线大小）。我们在下列公式中利用带有 N 的指示函数：N := {n ∈ [old_d^RX, cur_d^RX] | (n * D mod C) = 0 }：

A_e^RX_reads = ∑^cur_dRX_{n=old_d^RX} 1_N(n) （公式 6.8）

由于内存写入造成的预期总线传输数量如下：

A_e^RX_writes = (∑_n=1^{cur_dRX - old_dRX} (ba_end_n^RX - ba_start_n^RX) / C) + (d_end^RX - d_start^RX) * D / C （公式 6.9）

我们预期网络数据包数据必须被复制到宿主内存并且对应的 descriptor done bit 位将会被写入到宿主内存中的描述符。

我们利用更多的 BUS_TRANS 事件计数器验证了公式 6.1，它们基本上是事件 BUS_TRANS_MEM 的子集，参见图 6.4。我们确定了事件计数器 BUS_TRANS_P 对外设的内存读取进行计数，而事件计数器 BUS_TRANS_INVAL 对外设的内存写入进行计数。我们将这些计数器配合 THIS_AGENT 和 ALL_AGENTS 的名称扩展共同使用，如 5.2.1 节所述，以区分由宿主 CPU 造成的总线传输和由外设造成的总线传输。在我们的实验中并未发生 BUS_TRANS_BURST 事件。当 e1000e.ko 驱动程序函数 e1000_clean_tx_irq 和 e1000_clean_rx_irq 被调用时，由以太网控制器造成的总线传输根据公式 6.1 被计算出来。我们改良了由 5.2.2 节引入的 BARM 以考虑如本节所述的 A_e^ETH。

图 6.4 BUS_TRANS 事件计数器

BUS_TRANS_P，BUS_TRANS_INVAL，和 BUS_TRANS_BURST 计数之和为 BUS_TRANS_MEM 计数结果 [71]。

6.2.2 基于 OpenSSL 的实现

OpenSSL 是一种流行的软件工具套件，它实现了诸如 SSL/TLS 协议以及 X.509 证书的加 / 解密等密码学机制。此工具套件为开发者提供了共享库，即 libssl 和 libcrypto。openssl 命令行工具同样使用了这些库。需要使用由 OpenSSL 提供的密码学机制的应用程序可以直接使用这些库。注意，本节所呈现的实现基于我们 [10] 之前的可信信道实现。我们的修改基于 TLS 以及与 TLS 相关的 征求意见稿（RFC）文档，即 RFC4366 和 RFC4680。因此，这些修改符合 TLS 规范。

用于协商安全信道的会话密钥的 TLS 握手协议需要被适配以考虑 BARM 的测定结果。在握手阶段考虑这些测定结果使得该端能够确定目标平台是否已经受到 DMA 恶意软件的攻击。这有助于该端决定目标平台是否可信。如果另一个端点被认为不可信，则该端可以终止合法报告信道的握手。注意，基于我们的信任模型，我们将宿主 CPU 视为信道的一个端点。诸如网卡等其他计算环境不属于端点。我们利用非对称密码学机制和证书来认证端点。在下列段落中，我们将会描述所使用的密钥交换和证书。我们同样描述用于 TLS 的 Hello 消息的扩展。针对 TLS 协议的扩展由 Dierks 和 Rescorla [38] 所考虑。为了传送 BARM 测定结果（平台状态数据），需要使用额外的握手信息。我们出于此目的使用 补充数据 消息。

我们关于合法报告信道的实现基于 TLS Diffie-Hellman 短寿命 RSA（DHE-RSA）握手 [脚注 17] 的一种适配版本。这意味着，为了认证端点数据，一组 RSA 签名密钥对将会被使用。而对于会话密钥的协商，Diffie-Hellman 值将会被使用。被传送至该端的 Diffie-Hellman 公开部分是由 RSA 签名密钥对的私钥部分签名的。

脚注 17：如我们的前期工作 [10] 所述，诸如 RSA 和 DH-RSA 等密钥交换方法也可被用于实现一种基于可信信道的合法报告应用。

为了认证端点，证书（参见图 6.6 和图 6.7 中的 cert）在 TLS 握手阶段被交换。当使用 DHE-RSA 时，证书通过包含签名密钥对 K_sign := (SK_sign, PK_sign) 的公钥部分 PK_sign 的 证书 消息而被交换。我们必须保证私钥 SK_sign 仅对该端点可用。我们的认证包含一个与 BARM 相关的标识符以使得基于 TLS 的合法报告信道被 绑定 到该端点。包含 BARM 标识符的证书由可信的第三方签发，它能够担保目标平台上的 BARM 的正确安装，以及私钥部分 SK_sign 仅对该端点可用。因此，证书 cert 将签名密钥 K_sign 同执行 BARM 的端点关联起来。密钥对 K_sign 必须被用于认证在握手过程中由客户端 C 和服务器 S 所发送的数据。这最终将所传送的平台状态数据绑定到此合法报告信道。负责担保正确的 BARM 安装以及签名密钥的私钥部分 SK_sign 的可信第三方可以是同时运行评估平台的管理员。此评估平台从目标平台接收平台状态信息（BARM 测定结果）。所使用的证书实际上是包含 BARM 相关标识符的正常 TLS 证书。此证书连同签名密钥对 K_sign 由 BARM 一同部署，并且被看作长寿命的。

我们利用 ClientHello 和 ServerHello 消息来协商用于合法报告信道的安全性参数，参见图 6.6。运行 BARM 的客户端平台 C 启动适配的 TLS 客户端并且向服务器平台 S 发送 ClientHello 消息。服务器以 ServerHello 消息作为回应。这些 Hello 消息包含对应端的安全性参数 sec_param（参见 6.1 节），参见图 6.6。此安全性参数决定了哪些端点必须提供平台状态数据，即 BARM 测定结果。我们使用 Hello 消息扩展 [38] 来交换安全性参数。我们的基于 OpenSSL 的实现使用 TLS Hello 扩展，如 RFC4366 [14] 所述。OpenSSL 的某个补丁（0.9.8.x）实现了 Hello 扩展，参见图 6.5 [脚注 18]。此补丁修改了与 libssl 库相关联的代码。我们将此补丁用于我们的合法报告信道应用实现。

脚注 18：此 TLS Hello 扩展和补充数据补丁可以在此找到：http://openssl.6102.n7.nabble.com/PATCH-TLS-hello-extensions-and-supplemental-data-td38202.html [访问于 2014 年二月 25 日]

图 6.5 考虑了 Hello 扩展和补充数据扩展的 TLS 握手

此 ClientHello 消息包含 client data 而 ServerHello 消息包含 server data。额外的 SupplementalData 包含 client supplemental data 和 server supplemental data。补充数据也被看作 TLS 扩展（基于 [142]）。

图 6.6 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (a)

我们针对 TLS 握手所作的修改以粗体高亮显示。适配的握手在图 6.7 中继续。

图 6.7 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (b)

在握手完成之后，合法报告信道被用于 BARM 以便以某种常规的区间来传送心跳消息以通讯平台状态改变，即报告一次基于 DMA 恶意软件的攻击。

此补丁提供了一个接口以允许开发者注册新的 TLS 扩展 [参见 142]。由 TLSEXT_GENERAL 对象所表示的 TLS 扩展用于传送通用数据。使用 TLS 的应用程序指定此通用数据的数据格式。TLS 扩展包括一种类型、数据长度、通用数据（类型——长度——值格式），以及某些用于实现所需的扩展逻辑的标识 [脚注 19] 和回调函数。回调函数（参见图 6.5）只会在实例化了对应的 TLSEXT_GENERAL 对象的端上被触发。通过一条 Hello 消息所传送的通用数据是一个通用数据项。在我们的实现中，通过 Hello 消息（Hello 扩展）所交换的 TLS 扩展是：

• ARCH_NEGOTIATION_EXT：用于我们的合法报告信道（ARCH）的这一扩展（EXT）被用于协商安全性参数 sec_param。

脚注 19：这些扩展标识包括 client_required（当此标识被设置时，如果服务器忽略此扩展，则客户端将会终止协商），server_send（当此标识被设置时，服务器将会发送此扩展），以及 received（内部使用，例如用于检查重复）。

客户端和服务器都需要注册 Hello 扩展（TLSEXT_GENERAL 对象），如果它们想要处理这些扩展。如果某端收到一条包含已注册的扩展的 Hello 消息，则该端调用对应扩展的回调函数，如图 6.5 所示。

客户端 C 和服务器 S 都能够提供平台状态数据。我们使用由 互联网工程任务小组之网络小组 在 RFC4680 [113] 中所指定的所谓 SupplementalData 消息来传送平台状态数据。OpenSSL 补丁（0.9.8.x）[脚注 20] 同样实现了用于 OpenSSL 的 SupplementalData 消息。此补丁的实现细节由 Davide Vernizzi [142] 所解释。如 RFC4680 所述，补充数据也可被用于传送通用数据。由该端决定是否需要利用 Hello 扩展来传送通用数据。此 OpenSSL 补丁还允许我们定义那些我们需要用于我们的合法报告信道的补充数据扩展。补充数据扩展同样包含一种类型、通用数据、数据长度，以及回调函数。利用 SupplementalData 消息传送的补充数据可以是若干通用数据的栈。在我们的实现中，通过 SupplementalData 消息来交换通用数据的扩展包括：

• ARCH_SUPP_DATA_C_EXT：此扩展用于将平台状态数据 PSD^C（补充数据）从客户端 C 传送至服务器 S。

• ARCH_SUPP_DATA_S_EXT：此扩展用于将平台状态数据 PSD^S（补充数据）从服务器 S 传送至客户端 C。

脚注 20：参见脚注 18。

此打过补丁的 OpenSSL 软件如图 6.5 所示处理通用数据。同属 TLS 扩展的回调函数被调用以根据所要求的扩展逻辑来处理通用数据。与 Hello 扩展类似，客户端和服务器都必须注册那些它们想要通过对应的补充数据回调函数来处理的补充数据扩展。图 6.6 和 6.7 描述了我们的通用数据（Hello 扩展以及补充数据扩展）是在适配的 TLS 握手期间利用回调函数来处理的。

在我们的概念验证实现中，用于通过补充数据来交换平台状态数据 PSD 的通用数据格式非常简单：

• barm_measurement：此数据字段包含由 BARM Linux 内核模块进行的 BARM 测定的结果

• 设备标识对列表：我们使用设备标识对列表来通讯某个外设是否在攻击目标平台。第一个标识代表对应设备是否开始攻击宿主，并且如果是这样，第二个标识表明此恶意设备是否能够被终止。此设备标识对列表的形式如下：

• (uhci_attack, uhci_disabled)：此标识对代表 UHCI 控制器。

• (..._attack, ..._disabled)：[其他设备]。

• (me_attack, me_disabled)：此标识对代表管理引擎。

• nonceSD：nonceSD 包含两个元素：

• nonce^C (client_random)

• nonce^S (server_random)

平台状态数据 PSD 上的签名 Sig_PSD 也是通过 SupplementalData 消息发送至该端的，参见图 6.6 和 6.7。通过如此做，平台状态数据 PSD 也被绑定到对应的安全信道。包括于补充数据中的 nonceSD 被同 nonce^C 和 nonce^S（通过 Hello 消息所发送）进行比较以保证所接收到的平台状态数据 PSD 的新鲜性。为了认证平台状态数据 PSD 并且检查其完整性，我们使用签名密钥对的私钥部分 SK_sign 来签名 PSD。为了能够验证此签名，每个端点在传送 SupplementalData 消息完成之后立即利用 证书 消息提供包含公钥部分 PK_sign 的证书，参见图 6.6 和 6.7。同样作为补充数据的一部分的 BARM 测定结果被评估以导出该端的可信性。取决于所导出的可信性，本地平台根据本地安全策略采取措施。

会话密钥 SeK 照常由双方计算。由于我们使用 DHE-RSA，使用 SeK 的安全信道最终被连接到端点（宿主 CPU）。所交换的 DH 部分利用 K_sign 的私钥部分（SK_sign）签名，它将 DH 值连接到 K_sign。签名密钥对 K_sign 被准确地绑定到一个端点，由于此证书是由可信第三方签发的，它为 SK_sign 仅对该端点可用这一事实进行了担保。因此，此会话密钥也被绑定到该端点。

当握手完成后，BARM 利用此协商好的信道以某个常规的区间将心跳消息发送至外部管理员平台。这些消息以一种类似于握手过程中所使用过的 PSD 格式包含当前 BARM 测定结果和设备标识对列表。只有 nonceSD 缺失。常规的心跳消息被 BARM 用于报告平台状态改变，即一次基于 DMA 恶意软件的攻击。如果外部平台不再收到心跳消息，我们假设网卡试图攻击宿主平台并且 BARM 能够成功地终止该次攻击。也有可能是某个执行于网卡上的恶意软件拦截了心跳消息。如果是这样，则此次攻击同样被揭示出来。

6.3 评估

我们使用与 5.3 节所述的相同的平台和基本评估配置来评估改良的 BARM。请注意，只有客户端平台必须传送平台状态数据。

6.3.1 预期总线活动的验证

为了验证公式 6.1，我们引导了不同的测试。评估结果如图 6.8 所示。这些结果揭示了当 ping，scp 和 wget 命令造成网络流量时，BARM 测量结果会产生较大的波动。表 6.1 提供了关于造成这些较大波动的原因的信息。此表呈现了在使用 wget 命令下载一个 1 GB 的文件时进行的 BARM 测量的结果。所应用的采样区间为 32 ms。此表描述了一个较大的正偏差（参见 BARM 样本 125924：13 次总线传输）之后跟着一个较大的负偏差（参见 BARM 样本 125925：-12 次总线传输）。我们假设正偏差发生于网络数据包已经由以太网控制器复制到宿主内存，但是 BARM 未能在当前采样区间中评估对应的接收描述符。这些描述符在下一个采样区间中可用。因此，BARM 在下一个区间中评估这些描述符，而这又导致了负偏差。BARM 从测量的传输次数减去预期总线传输，而这部分传输实际上已经在上一个采样区间中测量过了。

如表 6.1 所示，这些正值和负值相互抵消。因此，可以通过简单地累加正负 BARM 测量值而使得波动最小化。如表 6.1 所示，一对正负测量值也可以以另一种方式发生（例如参见 BARM 样本 125926 和 125927）。这意味着负值先于正值被检测到。我们假设这发生于 BARM 已经分析了传送描述符，而对应的数据包尚未被以太网控制器所复制。因此，BARM 在其实际被测量之前，已经从测量到的总线传输次数中减去了这部分预期总线传输。这些传输于下一个采样区间中被测量，从而导致一个较大的正偏差。

表 6.1 显示出波动的 BARM 测量值

BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值	BARM 采样编号	BARM 测量值
125912	5	125928	5	125944	2	125960	-21
125913	2	125929	0	125945	25	125961	25
125914	3	125930	-2	125946	-48	125962	2
125915	2	125931	5	125947	28	125963	-2
125916	3	125932	2	125948	0	125964	3
125917	0	125933	5	125949	3	125965	2
125918	0	125934	0	125950	5	125966	5
125919	1	125935	-2	125951	1	125967	2
125920	2	125936	9	125952	13	125968	-1
125921	-17	125937	2	125953	-21	125969	2
125922	22	125938	3	125954	5	125970	2
125923	1	125939	-2	125955	2	125971	6
125924	13	125940	8	125956	2	125972	0
125925	-12	125941	-3	125957	-1	125973	1
125926	-15	125942	0	125958	4	125974	2
125927	22	125943	5	125959	3	125975	3

采样编号和对应的测量值取自测量日志，该日志取自从 http://download.thinkbroadband.com/1GB.zip [访问于 2014 年二月 25 日] 下载一个 1 GB 的文件时。BARM 采样区间为 32 ms。

图 6.8 具有网络流量时的预期总线活动评估

我们为 6 种不同的测试案例评估了预期总线活动。此差值以从图 5.6 中所知的盒图的形式可视化。在第一个案例（BARM）中，我们只运行了改良的 BARM，而在第二个案例中，我们连同改良的 BARM 一起运行了基于 OpenSSL 的合法报告信道。我们在这两种情况下各自运行了 100 次 BARM 测量。BARM 和合法报告信道同样在其余的测试案例（ping，scp，wget 和 wget'）中保持活动。我们以 1000 字节的负载执行了 ping 命令 100 次（ping）。在 scp 案例中，我们将一个 100 MB 的文件从外部平台复制到我们的目标平台 100 次。在 wget 案例中，我们使用 wget 命令从 http://download.thinkbroadband.com/1GB.zip [访问于 2014 年二月 25 日] 下载了一个 1 GB 的文件。我们对除了最后一项测试（wget'）以外的全部测试使用了 32 ms 的 BARM 采样间隔。wget' 案例的盒图代表了在利用 wget 下载一个 1 GB 的文件时使用 1024 ms 采样区间的结果。

我们在利用 wget 命令下载一个 1 GB 的文件时检测到了发生于两个采样区间之间的上述行为。如图 6.8 所示，当使用 wget 并且使用 32 ms 采样区间（参见 wget）时的波动大于使用 1024 ms 采样区间（参见 wget'）时的。

6.3.2 网络性能开销评估

我们引导了一组网络基准测试以揭示由改良的 BARM 所造成的网络性能开销。此改良版本的 BARM 持久地发送心跳消息。其结果如图 6.9 所示。图 6.9 所示的结果揭示了每隔 32 ms 发送一次心跳消息时的相对性能开销约为 4.5%。此区间长度对应于 BARM 的采样区间。并不必须将用于 BARM 测量采样的相同区间长度用于报告，由于我们用于传送平台状态数据的心跳消息的格式。该设备标识对列表代表了关于恶意外设的历史记录。因此，对于同为 32 ms 的采样和报告区间的网络性能开销可以避免。唯一的要求是采样区间小于或者等于报告区间。

图 6.9 对于不同报告区间和固定采样区间的相对性能开销

此图对比了 3 组系列测量的结果。第一组测量系列（不活动）代表基线。不活动意味着 BARM 并未运行，以及没有心跳消息被发送。图中的条形表示 100 次测量的平均值，同时参见 5.3.2 节。我们（利用时间戳计数器）测量了利用 scp 命令从外部平台复制一个 100 MB 文件所需的时钟周期。测量针对 32 ms 和 1024 ms 的报告区间进行。在两种情况下，我们都使用 32 ms 的 BARM 采样区间。每 32 ms 发送一次心跳消息时的相对性能开销约为 4.5%，而每 1024 ms 发送一次该消息时的开销仅约为 0.5%。

6.3.3 利用 DAGGER 进行测试

我们利用改良的总线代理运行时监视器 BARM 重复了 DMA 恶意软件 DAGGER 测试（参见 5.3.3 节）。其结果总结于图 6.10，6.11 和 6.12。我们在运行时的任意时间点攻击了目标平台。图 6.10 确认了改良的 BARM 能够揭示 DMA 攻击并且终止恶意外设。图 6.11 和图 6.12 中截取的日志来自于相同的实验，该实验也是图 6.10 的基础。

图 6.10 在运行时的任意时间点以及存在合法报告信道的情况下评估改良的 BARM

所引导的实验类似于 5.3.3 节所呈现的实验。BARM 的采样区间为 32 ms，并且容错值为 50 次总线传输。这一次，BARM 将以太网控制器视为一个额外的总线主控，这允许我们启动我们的合法报告信道。心跳消息每隔 32 ms 发送一次。此图对比了 3 条曲线，即容错值 T、在没有任何攻击时的 BARM 测量结果，以及发生了一次 DAGGER 攻击时的 BARM 测量结果。

图 6.11 BARM 合法报告信道——客户端侧

此图呈现了 BARM 日志输出的一部分。BARM 被部署于目标平台，即客户端上。此日志输出展示了 BARM 揭示了一次 DMA 攻击，并且 BARM 能够终止该恶意外设。

图 6.12 BARM 合法报告信道——服务器侧

此图描述了适配的 OpenSSL 服务器的日志输出。此日志包含 TLS 握手消息、回调函数调用消息，以及所接收到的 BARM 测定结果。测定结果值同图 6.11 所呈现的。部署于客户端侧的 BARM 实例能够终止此次攻击。在此范例中，本地安全策略容忍了此次被终止的攻击。或者，服务器也可以终止此信道，如果服务器收到了 441 次总线传输的 BARM 测试结果。服务器同样配置了 T = 50 次总线传输的容错值。

6.4 安全性考虑

在本节中，我们非形式化地评估了我们于本章开头所引入的安全性要求。形式化的证明超出了本工作的范围。众多与 TLS 协议的安全性证明相关的研究工作已经于过去被发表。一部综述由 Kohlweiss 等人 [78] 呈现。此研究同样考虑了多种 TLS 变体。我们假设我们的基于 TLS 的信道也能被形式化地证明。然而，本章的关注焦点在于考虑了网卡的改良的 BARM。因此，我们重新审视了我们的改良的 BARM 能够在多大程度上满足对于安全信道（R1）、将 BARM 的测定结果绑定到该安全信道（R2），以及隐私（R3）的要求。

R1——安全信道属性

由于所应用的 TLS 协议，此通讯信道已经保证了安全信道属性中的机密性、完整性、合法性，以及新鲜性。由于改良的 BARM，这些属性同样在端点，即宿主 CPU 上得到了保证。鉴于攻击者必须搜索有价值数据，BARM 保证了存在于主内存中的数据的完整性和机密性。攻击者只能随机写入或者读取主内存而不能搜索有价值数据。攻击者同样需要搜索一次性随机数、密钥素材或者会话密钥 SeK 以及签名密钥对的私钥部分 SK_sign 以攻击此通讯会话。因此，改良的 BARM 同样能够在端点上兼顾合法性和新鲜性的属性，由于在攻击者搜索主内存时检测到了额外的总线流量。

攻击者只能引导一次中间人攻击，如果攻击者能够通过 DMA 偷取私钥素材或者会话密钥。扫描内存以查找这些数据将会被 BARM 检测到。BARM 还能够识别恶意设备。因此，对主内存的访问可以被防止。注意，宿主 CPU 可以通过将一部分敏感数据存储于处理器寄存器中而迫使攻击者造成更多的总线传输。此项技术已经在相关工作中被提议，参见 3.2.6 节。这并不能够保护敏感数据，由于 DMA 攻击可以被用于将处理器寄存器内容转储到主内存。然而，这样的攻击将会造成更多的总线活动，而这也会被 BARM 检测到。

攻击者可以试图修改 BARM 测量结果。为了做到这一点，攻击者可以试图从主内存中查找某些变量，在此，BARM 存储那些我们将其用于揭示 DMA 攻击的性能监视单元的值。然而，基于 DMA 的搜索将会被 BARM 揭示出来。或者，攻击者可以试图修改那些 BARM 所使用的对应于性能监视单元的宿主 CPU 寄存器。攻击者不能直接访问宿主 CPU 寄存器。然而，攻击者需要查找一块用于存储宿主 CPU 指令以修改用于性能监视的处理器寄存器的内存区域。这要求宿主 CPU 迟早将会考虑该内存区域，它包含恶意指令。然而，攻击者还是必须通过 DMA 搜索这样一块区域，而这种基于 DMA 的搜索将会被 BARM 揭示出来。

R2——将 BARM 测定结果绑定到安全信道

端点的合法性通过提供证书 cert 而得到保证。该证书包含 BARM 标识符以及签名密钥对的公钥部分 PK_sign。此证书由可信实体签名。两个因素保证了 BARM 测定结果被绑定到该信道。其一，在握手阶段被传输的 BARM 测定结果经过该端点的签名密钥中的私钥部分 SK_sign 签名。其二，被用于会话密钥计算的交换的 DH 值也经过 SK_sign 签名。因此，不仅仅是首先被传送的 BARM 测定结果以及 DH 值被绑定到信道端点，而且也包括用于最终建立用于合法状态报告的安全通讯信道的会话密钥 SeK。这意味着每一条心跳消息也都被绑定到信道端点。这些消息只会通过由 SeK 所保护的信道以加密的形式而被传送。

端点的合法性同样防止了一种中继攻击，在此，攻击者能够向第三方平台发送请求以签名一条包含少于 50 次总线传输的 BARM 测量值的平台状态数据 PSD。第三方平台不能访问目标平台的 SK_sign。这意味着我们可以排除攻击者能够引导中继攻击的可能性。或者，攻击者可以试图伪造 PSD 签名。为了做到这一点，攻击者需要存在于主内存中的 SK_sign。然而，当攻击者通过 DMA 搜索 SK_sign 时，BARM 还是会揭示此次攻击并且内存访问将会被终止。因此，我们可以得出结论，即攻击者不能伪造数字签名。

R3——隐私

唯一以未加密形式传送的敏感数据是首次 BARM 测量值，它在握手阶段被发送至对端。尽管受到攻击的网卡可以被用于拦截这个值，此首次测量结果的值不太可能对于攻击者有用。它与其他测量值相互独立，后者被用于识别 BARM 于何时检测到 - T 次总线传输。因此，我们可以得出结论，即我们的合法报告信道满足最少信息范型。

6.5 本章小结

在本章中，我们为 BARM 开发、实现并且评估了一种合法报告信道应用。此信道基于安全信道协议 TLS。我们修改了 TLS 协议以便在握手阶段以及其余的通讯会话中考虑 BARM 测定结果。我们的修改基于 TLS 扩展，这意味着我们的信道符合 TLS 规范。更进一步地，我们的报告信道的实现满足我们为 DMA 恶意软件场景所定义的安全性要求（宿主 CPU 端点的合法性以及信道绑定）。如果未能满足这些要求，则执行于网卡上的恶意软件对于同外部平台进行合法通讯来说仍然是一种威胁。

我们的信道是用于我们的总线代理运行时监视器的一个应用，如果通讯伙伴要求关于平台状态更改的报告。合法报告信道将状态改变传送至该端。我们利用我们自己的 DMA 恶意软件 DAGGER 配合所实现的报告信道确认了 BARM 的有效性和高效性。与合法平台状态报告相关的前期工作假设存在这样一种高效的运行时监视器。然而，呈现于前期工作中的对应的概念验证实现并未包含这样一种监视器。更进一步地，前期工作也并未考虑 DMA 恶意软件场景。

我们同样可以得出结论，即 BARM 可以处理更加复杂的总线主控。我们展示了 BARM 不仅仅能够处理宿主 CPU、UHCI 控制器等，也能处理以太网控制器。为了将以太网控制器整合进 BARM 的检测模型，我们不得不针对内存读取和内存写入访问对该控制器进行分析。我们通过利用额外的性能监视单元配置能够区分读取和写入访问。然而，为了最终确定由以太网控制器造成的总线传输数量，我们不得不引入了一个新的参数。这个新参数是缓存线大小。根据我们的评估，BARM 测量结果的波动只是略微高于未考虑以太网控制器的版本。此外，波动仍然处于 T = ±50 次总线传输的范围内。我们的经验性测量揭示了合法报告信道应用的性能开销是可忽略的，如果心跳消息大约每秒发送一次。报告区间可以大于 BARM 的采样区间。DMA 恶意软件攻击信息的缺失可以通过在心跳消息中包含一段攻击历史记录而避免。

第 7 章 结论和未来工作

逻辑学是一种系统性的方法，用于满怀信心地得出错误的结论。——Manly’s Maxim，Murphy 法则集锦

通过攻击计算机平台外设来攻击宿主平台内存代表了当前 rootkit 进化的顶峰。本论文呈现了关于利用这些 rootkit 技术针对计算机平台发动攻击的研究。平台外设非常适合隐藏恶意代码以攻击宿主平台。这些外设包含具有专用处理器和专用内存，并且能够直接访问宿主内存的隔离执行环境。在本工作之前，源自利用直接内存访问（DMA）的恶意软件的攻击曾经被看作是对于宿主 CPU 不可见 的。然而，本论文展示了 宿主 CPU 仍然能够检测那些利用 DMA 的攻击。这允许宿主 CPU 化解此类攻击。

最近，诸如管理控制器和网卡（NIC）等外设几乎存在于每一部计算设备中。服务器系统、台式机系统、笔记本、平板，以及甚至是移动电话都使用专用控制器以便从宿主 CPU 上卸载工作量。尽管渗透这样一部外设是一项资源密集型任务，然而就其隐秘性而言，这些环境仍然具有吸引力。DMA 机制是攻击宿主内存的基础。因此，我们将那些利用直接内存访问的基于外设的攻击代码称为 DMA 恶意软件。通过利用 DMA 恶意软件，攻击者可以以某种隐秘的方式读取和写入宿主内存。对手能够访问存在于主内存中的全部数据。因此，攻击者可以偷取诸如密码学密钥、口令、互联网银行凭证、打开的文件，以及所有用户输入等敏感数据。对手也可以向主内存中插入数据以实现内核后门。然而，这会降低隐秘攻击的成功率，由于理论上宿主软件可以检测到针对宿主内存的恶意修改。与之相反，攻击者也可以通过 DMA 攻击宿主检测软件以避免被检测到。

在本工作中，我们开发并且分析了一种 DMA 恶意软件概念验证。此恶意软件执行于某个隔离执行环境，其内部工作方式不可被宿主访问。本论文的目标是展示即使宿主 CPU 不能访问可疑外设的内部工作方式，宿主 CPU 仍然能够保护自己不受 DMA 恶意软件的攻击。我们用于我们的恶意软件概念验证的外设是 Intel 管理引擎（Intel ME）。除了其他事情以外，Intel 还利用 ME 环境实现了一台网络服务器，它为系统管理员提供了远程设备管理能力。管理员能够恢复宿主操作系统，即使该平台已经不能启动，例如由于操作系统内核完整性的损坏。Intel 应用了保护机制以确保 ME 特性不能被用于攻击宿主。然而，这种保护也确保了诸如反病毒软件等无法评估 ME 环境。与之相反，例如能够通过零日漏洞等方式渗透 ME 的攻击者同样得益于这种保护。

我们的恶意软件概念验证是一种 基于直接内存访问的击键码记录器（Direct memory Access based keystroke code loGGER）。DAGGER 展示了就宿主 CPU 的检测能力而言，实现隐秘恶意软件是可能的。攻击代码执行于专用的 ME 处理器上。因此，此击键码记录器对于宿主并不会造成可测量的性能开销。我们的恶意软件同样能够捕获短寿命数据，例如击键码。我们利用 ME 环境的隔离的带外网络特性来将诸如捕获的击键码等私密数据潜出至外部平台。此网络特性同样对于宿主不可见。我们对 DAGGER 的分析揭示了 DMA 恶意软件必须从宿主内存中搜索有价值数据。对宿主内存的这种搜索过程造成了额外的总线活动，而如果使用了内存地址随机化机制，或者如果私密数据存在于 CPU 缓存或者 CPU 寄存器中，这种额外的总线活动还会增加。我们还确定了不同设备的并行内存访问请求由内存控制器集线器进行仲裁。这导致了这样一种假设，即仲裁器可以造成 DMA 副作用，而我们能够利用这种副作用来检测 DMA 恶意软件。我们通过引导一次内存压力测试而确认了这一假设。有了这次实验，我们展示出了一种可靠的，可测量的 DMA 副作用。我们的测量考虑了基于宿主 CPU 时钟周期以及性能计数器的精确计时。

我们带着开发一种 DMA 恶意软件检测器的目标继续了本研究。我们分析了宿主 CPU 的性能计数器。最终，我们的调查得出了一种能够区分合法和非法内存总线传输的性能计数器配置。我们对宿主操作系统的预期总线活动进行了建模，并且将其同测量得到的总线活动进行比较。为了对预期总线活动进行建模，我们使用了操作系统内核中可用于宿主 CPU 的信息。

我们以一种操作系统内核模块的形式实现了我们的模型和测量机制，我们称其为 总线代理运行时监视器，简称 BARM。BARM 是一种运行时监视器，它同时考虑了瞬时攻击。我们的监视器只造成了可忽略的性能开销。BARM 不要求对固件或者硬件进行任何修改。我们的运行时监视器同样不要求对于潜在受到攻击的外设的内部工作方式的任何访问。在对我们的概念验证实现 BARM 进行评估之后，我们得出结论，即宿主 CPU 能够检测并且终止 DMA 恶意软件。我们的评估同样揭示了最小化的 BARM 测量结果波动。这些波动可能发生于使用性能计数器时，由于我们将这些性能计数器用于我们的概念验证实现。我们通过引入容错值来克服这一问题。此容错值是一个经验值，它代表可被容忍的总线传输次数，即在我们的案例中，容错值是 50 次总线传输。我们展示了 DMA 恶意软件在宿主运行时内存中搜索有价值数据时会造成大得多的总线活动。

然而，此容错值也展示了当前 BARM 实现的一种局限性。理论上，对手可以在每个采样区间内隐藏多达 2 T 的总线传输。然而仅当对手能够精确地预测 BARM 检测到 - T 次总线传输的时间点时，这才是可行的。与之相反，这也会导致更加迟缓的搜索阶段，而宿主 CPU 可以利用这一点来保护宿主内存中的目标数据。另一种局限性是一种由以太网控制器引导的可能的中间人攻击。我们通过实现一种合法报告信道来化解这种中间人攻击。用于报告平台状态的合法报告信道是本工作的另一个目标。在我们的场景中，此平台状态包括 DMA 恶意软件。BARM 将合法测定结果传送至外部平台。

诸如 TLS 等安全信道协议不足以胜任我们的场景。我们调整了 TLS 协议以满足合法平台状态报告的要求。同时考虑网卡是至关重要的，由于它可以潜在地修改或者拦截 BARM 数据包。为了逃避检测，网卡还可以实施 中间人（MitM）攻击，通过将另一平台的良好 BARM 测定结果中继到想要评估目标平台状态的平台上。另一个范例是通过 DMA 偷取存在于宿主运行时内存中的密钥素材。为了消除这些问题，此通讯信道被绑定到实际端点，即宿主 CPU。BARM 对总线活动的测定结果进行数字签名，并且确保私钥以及通讯信道的会话密钥被保护起来以防止 DMA 恶意软件攻击。为了实现一种关于合法平台状态报告应用的概念验证，我们必须改良 BARM 以考虑网卡的合法内存总线活动。关于我们的信道应用的评估确认了网卡可以被 BARM 可靠地考虑。

未来工作

尽管我们能够得出结论，即宿主 CPU 能够利用 BARM 保护自己不受 DMA 恶意软件的攻击，仍有一些任务留作我们的未来工作。首先，在非 Intel 硬件上评估 BARM 背后的理念将会十分有趣。诸如 ARM 等其他架构也提供了硬件性能计数器。基于 ARM 的平台同样用到了可以作为 DMA 恶意软件的潜在宿主的外设。当考虑到这些平台在其设计中广泛使用 系统芯片（SoC）时，这变得特别有趣。因此，位于相同设备封装或者芯片之中的外设可以被用于实现系统后门。

调查基于计时的 DMA 副作用是否也可被用于实现一种可靠的检测工具也很有趣。这可能对于那些不支持性能计数器的架构非常有用。BARM 实现还应该考虑其他外设。在我们看来，在 BARM 的检测模型中整合更多的外设更为重要。这也可能消除 BARM 测量结果中的波动。值得注意的是，整合更多的基于 DMA 的设备是一项资源密集型任务。因此，后续研究项目应该检查此过程能够在多大程度上自动化。

致谢

首先，我特别想要感谢我的导师 Jean-Pierre Seifert。我不仅感谢众多有益的讨论以及卓越的研究环境，同时也感谢允许我自由地选择我自己的论文题目。他的感召、鼓舞、激励和启发使我感激终生。感谢我的导师，他使我总是对我的研究和论文充满信心。其次，我想要对来自柏林科大电信安全委员会（SecT）的同事和朋友们致以最诚挚的谢意。特别感谢 Nico Golde 和 Dmitry Nedospasov（博士团队），以及 Iurii Bystrov，Kévin Redon，Ravi Borgaonkar，和 Collin Mulliner。如果没有博士团队，我可能现在还在写作我的论文。特别地，我感谢 Collin 在所有领域提出的建议。如果没有 Iruii，与 Intel AMT/ME 相关的工作不可能取得如此巨大的成功。

我同样想要感谢柏林科大通讯和操作系统（KBS）研究小组以及计算机安全工作组（AGRS），由于众多有益的评论，以及他们对于对于准备学术会议演讲的有益建议。此外，我想要感谢来自云和安全实验室（惠普 Bristol 实验室）的 Dirk Kuhlmann 和 Chris Dalton，由于他们那些非常有益和激励性的讨论帮助我开发了 BARM 所基于的理念。

我同样感谢我所得到的来自软件校园计划的帮助。德国电信 AG（DTAG）和电信创新实验室（T-Labs）在此计划的上下文环境中对我的工作进行了支持。我的软件校园计划由德意志联邦教育和科研部资助（批准号 O1IS12056）。此项目的成果是我的论文的重要组成部分。因此，我想要感谢软件校园团队的组织支持、DTAG/T-Labs 的业界指导、柏林科大/SecT 的学术指导，以及德意志联邦教育和科研部的经济支持。

在我作为博士生期间，有许多其他人以不同方式帮助过我。我没法在此列出他们的全部，但是我想要特别感谢下列支持者的帮助（不完全统计，排名不分先后）：Yacine Gasmi，Martin Unger，Kei Ishii，和 Marcel Selhorst。此外，博士学位委员会，即 Hans-Ulrich Heiß，Jean-Pierre Seifert，以及外部审稿人 Konrad Rieck 和 Volker Roth 为我的论文最终版本给予了无价的反馈，我对此深表谢意。

此外，我特别想要感谢我的家庭，特别是我的家长和姐妹的鼓励和爱。最后，我深深地感谢我的未婚妻 Gesche，你总是尽你所能极大地帮助了我。感谢你的光辉灿烂的支持，鼓舞和爱！

附录 A 图注清单

• 图 2.1 “-3 环”环境，与 x86 平台上的其他 rootkit 环境相比

• 图 2.2 能够潜在地被 rootkit 利用的专用隔离硬件概述

• 图 2.3 x86 芯片组和外设组件

• 图 2.4 第三方和第一方 DMA

• 图 2.5 总线主控拓扑结构

• 图 4.1 DAGGER 一般设计

• 图 4.2 Intel 管理引擎环境

• 图 4.3 USB 请求块签名扫描（简化）

• 图 4.4 查找 DeviceExtension 结构（简化）

• 图 4.5 查找 KiInitialPCR（简化）

• 图 4.6 包含来自键盘缓冲区的字节的网络数据包

• 图 4.7 宿主性能 CPU、内存和网络开销测试

• 图 4.8 搜索时间测试结果 (a) 和 (b)

• 图 4.9 搜索时间测试结果 (c) 和 (d)

• 图 4.10 内存压力测试

• 图 5.1 总线主控拓扑结构被利用以揭示恶意内存访问

• 图 5.2 Intel 四核处理器

• 图 5.3 UHCI 计划信息（简化）

• 图 5.4 对由 3 个活动的总线主控造成的内存传输进行分解

• 图 5.5 容错值 T

• 图 5.6 确定足够的容错值 T

• 图 5.7 宿主性能 CPU 和内存开销评估

• 图 5.8 利用口令提示符（ssh 命令）于运行时的任意时间点评估 BARM

• 图 6.1 协商一条合法报告信道

• 图 6.2 传送 / 接收描述符环的结构

• 图 6.3 e1000e.ko 驱动程序的传送 / 接收描述符转储

• 图 6.4 BUS_TRANS 事件计数器

• 图 6.5 考虑了 Hello 扩展和补充数据扩展的 TLS 握手

• 图 6.6 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (a)

• 图 6.7 用于合法报告信道的适配的 TLS-DHE-RSA 握手 (b)

• 图 6.8 具有网络流量时的预期总线活动评估

• 图 6.9 对于不同报告区间和固定采样区间的相对性能开销

• 图 6.10 在运行时的任意时间点以及存在合法报告信道的情况下评估改良的 BARM

• 图 6.11 BARM 合法报告信道——客户端侧

• 图 6.12 BARM 合法报告信道——服务器侧

附录 B 表注清单

• 表 4.1 DMA 攻击范例对于判据 C1-C4 的满足情况

• 表 6.1 显示出波动的 BARM 测量值

附录 C 参考文献

• [1] Doug Abbott. PCI Bus Demystified. Demystifying Technology Series. Elsevier Science, 2004.

• [2] Darren Abramson, Jeff Jackson, Sridhar Muthrasanallur, Gil Neiger, Greg Regnier, Rajesh Sankaran, Ioannis Schoinas, Rich Uhlig, Balaji Vembu, and John Wiegert. Intel Virtualization Technology for Directed I/O. Intel Technology Journal, 10(3):179–192, August 2006.

• [3] Grace Agnew. Digital Rights Management: A Librarian’s Guide to Technology and Practise. Chandos Information Professional Series. Chandos Pub., 2008.

• [4] Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes. Application-binding Protocol in the User Centric Smart Card Ownership Model. In Proceedings of the 16th Australasian Conference on Information Security and Privacy, ACISP’11, pages 208–225, Berlin, Heidelberg, 2011. Springer-Verlag.

• [5] Raja Naeem Akram, Konstantinos Markantonakis, and Keith Mayes. A Privacy Preserving Application Acquisition Protocol. In Geyong Min, Yulei Wu, Lei (Chris) Liu, Xiaolong Jin, Stephen A. Jarvis, and Ahmed Yassin Al-Dubai, editors, TrustCom, pages 383–392. IEEE Computer Society, 2012.

• [6] Don Anderson. FireWire System Architecture: IEEE 1394a. PC System Architecture Series. Addison Wesley, 1999.

• [7] Don Anderson. SATA Storage Technology. MindShare Technology Series. MindShare Press, 2007.

• [8] Don Anderson and Dave Dzatko. Universal Serial Bus System Architecture. PC System Architecture Series. Addison Wesley, 2001.

• [9] Don Anderson and Tom Shanley. PCI System Architecture. PC System Architecture Series. Addison Wesley, 1999.

• [10] Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, and Davide Vernizzi. An Efficient Implementation of Trusted Channels based on OpenSSL. In Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, STC ’08, pages 41–50, New York, NY, USA, 2008. ACM.

• [11] Damien Aumaitre and Christophe Devine. Subverting Windows 7 x64 Kernel with DMA Attacks. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/10-hitbamsterdam-dmaattacks.pdf [accessed 25 February 2014], July 2010.

• [12] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. Norrman. The Secure Real-time Transport Protocol (SRTP). The Internet Engineering Task Force: http://tools.ietf.org/html/rfc3711 [accessed 25 February 2014], March 2004. RFC3711.

• [13] Muli Ben-Yehuda, Jimi Xenidis, Michal Ostrowski, Karl Rister, Alexis Bruemmer, and Leendert van Doorn. The Price of Safety: Evaluating IOMMU Performance. In OLS ’07: The 2007 Ottawa Linux Symposium, pages 9–20, July 2007.

• [14] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Transport Layer Security (TLS) Extensions. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4366.txt [accessed 25 February 2014], April 2006. RFC4366.

• [15] Erik-Oliver Blass and William Robertson. TRESOR-HUNT: Attacking CPU-bound Encryption. In Proceedings of the 28th Annual Computer Security Applications Conference, ACSAC ’12, pages 71–78, New York, NY, USA, 2012. ACM.

• [16] Bill Blunden. The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System. Jones & Bartlett Learning, 2012.

• [17] Adam Boileau. Hit by a Bus: Physical Access Attacks with Firewire. Security-Assessment.com: http://www.security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf [accessed 25 February 2014], October 2006. Ruxcon 2006.

• [18] Rory Breuk and Albert Spruyt. Integrating DMA Attacks in Exploitation Frameworks. Homepage of Cees de Laat: http://www.delaat.net/rp/2011-2012/p14/report.pdf [accessed 25 February 2014], February 2012.

• [19] Rory Breuk and Albert Spruyt. Integrating DMA Attacks in Metasploit. Sebug: http://sebug.net/paper/Meeting-Documents/hitbsecconf2012ams/D2%20SIGINT%20-%20Rory%20Breuk%20and%20Albert%20Spruyt%20-%20Integrating%20DMA%20Attacks%20in%20Metasploit.pdf [accessed 25 February 2014], May 2012.

• [20] Ernie Brickell, Jan Camenisch, and Liqun Chen. Direct Anonymous Attestation. In Proceedings of the 11th ACM Conference on Computer and Communications Security, CCS ’04, pages 132–145, New York, NY, USA, 2004. ACM.

• [21] Jonathan Brossard. Hardware Backdooring is Pratical. Toucan System: http://www.toucan-system.com/research/blackhat2012_brossard_hardware_backdooring.pdf [accessed 25 February 2014], 2012.

• [22] Jonathan Brossard. Hardware Backdooring is Pratical. Black Hat USA 2012: https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf [accessed 25 February 2014], 2012.

• [23] William Buchanan. Computer Busses. Electronics & Electrical. Taylor & Francis, 2010.

• [24] Ravi Budruk, Tom Shanley, and Don Anderson. PCI Express System Architecture. The PC System Architecture Series. Addison Wesley, Pearson Education, July 2010. MindShare, Inc.

• [25] Yuriy Bulygin. Chipset based Approach to Detect Virtualization Malware. hakim.ws: http://www.hakim.ws/BHUSA08/speakers/Bulygin_Detection_of_Rootkits/bh-us-08-bulygin_Chip_Based_Approach_to_Detect_Rootkits.pdf [accessed 25 February 2014], 2008.

• [26] John Butterworth, Corey Kallenberg, Xeno Kovah, and Amy Herzog. Problems with the Static Root of Trust for Measurement. Black Hat: https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-WP.pdf [accessed 25 February 2014], 2013. Presented at Black Hat, Slides: https://media.blackhat.com/us-13/US-13-Butterworth-BIOS-Security-Slides.pdf [accessed 25 February 2014].

• [27] Emanuele Cesena, Hans Löhr, Gianluca Ramunno, Ahmad-Reza Sadeghi, and Davide Vernizzi. Anonymous Authentication with TLS and DAA. In Alessandro Acquisti, Sean W. Smith, and Ahmad-Reza Sadeghi, editors, Trust and Trustworthy Computing, volume 6101 of Lecture Notes in Computer Science, pages 47–62. Springer Berlin Heidelberg, 2010.

• [28] Xiaolin Chang, Ying Qin, Zhi Chen, and Bin Xing. ZRTP-based Trusted Transmission of VoIP Traffic and Formal Verification. In Proceedings of the 2012 Fourth International Conference on Multimedia Information Networking and Security, MINES ’12, pages 560–563, Washington, DC, USA, 2012. IEEE Computer Society.

• [29] Song Cheng, Liu Bing, Xin Yang, Yang Yixian, Li Zhongxian, and Yin Han. A Security-enhanced Remote Platform Integrity Attestation Scheme. In Proceedings of the 5th International Conference on Wireless Communications, Networking and Mobile Computing, WiCOM’09, pages 4420–4423, Piscataway, NJ, USA, 2009. IEEE Press.

• [30] David Chess, Joan Dyer, Noamaru Itoi, Jeff Kravitz, Elaine Palmer, Ronald Perez, and Sean Smith. Using Trusted Co-servers to Enhance Security of Web Interaction. United States Patent 7,194,759: http://www.freepatentsonline.com/7194759.html [accessed 25 February 2014], March 2007.

• [31] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Drivers, 3rd Edition. O’Reilly Media, Inc., 2005.

• [32] Rob Crooke. Accelerating Innovation in the Desktop. Intel Corporation: http://download.intel.com/pressroom/kits/events/computex2009/Crooke_Computex_presentation.pdf [accessed 25 February 2014], April 2009.

• [33] Francis M. David, Ellick Chan, Jeffrey C. Carlyle, and Roy H. Campbell. Cloaker: Hardware Supported Rootkit Concealment. In IEEE Symposium on Security and Privacy, pages 296–310. IEEE Computer Society, 2008.

• [34] Jonathan Davidson. Voice Over IP Fundamentals. Cisco Press Fundamentals Series. Cisco Press, 2006.

• [35] Guillaume Delugré. Closer to Metal: Reverse Engineering the Broadcom NetExtreme’s Firmware. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/10-hack.lu-nicreverse_slides.pdf [accessed 25 February 2014], October 2010.

• [36] Guillaume Delugré. How to Develop a Rootkit for Broadcom NetExtreme Network Cards. Sogeti ESEC Lab: http://esec-lab.sogeti.com/dotclear/public/publications/11-recon-nicreverse_slides.pdf [accessed 25 February 2014], 2011.

• [37] Department of Defense. DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA. NIST CSRC: http://csrc.nist.gov/publications/history/dod85.pdf [accessed 25 February 2014], December 1985. DEPARTMENT OF DEFENSE STANDARD.

• [38] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5246.txt [accessed 25 February 2014], August 2008. Network Working Group RFC 5246.

• [39] Kurt Dietrich. A Secure and Reliable Platform Configuration Change Reporting Mechanism for Trusted Computing Enhanced Secure Channels. In Proceedings of the 9th International Conference for Young Computer Scientists, 2008. ICYCS 2008, pages 2137–2142, 2008.

• [40] Kurt Dietrich. On Reliable Platform Configuration Change Reporting Mechanisms for Trusted Computing Enabled Platforms. Journal of Universal Computer Science, 16(4):507–518, 2010.

• [41] Jeroen Domburg. Hard Disk Hacking. SpritesMods.com: http://spritesmods.com/?art=hddhack&page=1 [accessed 25 February 2014], 2013. Presented at OHM2013: http://bofh.nikhef.nl/events/OHM/video/d2-t1-13-20130801-2300-hard_disks_more_than_just_block_devices-sprite_tm.m4v [accessed 25 February 2014].

• [42] Maximilian Dornseif, Michael Becher, and Christian N. Klein. FireWire – All Your Memory Are Belong To Us. CanSecWest: http://cansecwest.com/core05/2005-firewire-cansecwest.pdf [accessed 25 February 2014], May 2005.

• [43] Maximillian Dornseif. 0wned by an iPod - Hacking by Firewire. Laboratory for Dependable Distributed Systems University of Mannheim: http://pi1.informatik.uni-mannheim.de/filepool/presentations/0wned-by-an-ipod-hacking-by-firewire.pdf [accessed 25 February 2014], November 2004. PacSec 2004.

• [44] Loı̈c Duflot, Olivier Levillain, and Benjamin Morin. ACPI: Design Principles and Concerns. In Proceedings of the 2nd International Conference on Trusted Computing, Trust ’09, pages 14–28, Berlin, Heidelberg, 2009. Springer-Verlag.

• [45] Loı̈c Duflot, Yves-Alexis Perez, and Benjamin Morin. Run-time Firmware Integrity Verification: What If You Can’t Trust Your Network Card? French Network and Information Security Agency (FNISA): http://www.ssi.gouv.fr/IMG/pdf/Duflot-Perez_runtime-firmware-integrity-verification.pdf [accessed 25 February 2014], March 2011.

• [46] Loı̈c Duflot, Yves-Alexis Perez, and Benjamin Morin. What If You Can’t Trust Your Network Card? In Proceedings of the 2011 International Symposium on Research in Attacks, Intrusions and Defenses (RAID), pages 378–397, 2011.

• [47] Loı̈c Duflot, Yves-Alexis Perez, Guillaume Valadon, and Olivier Levillain. Can You Still Trust Your Network Card? French Network and Information Security Agency (FNISA): http://www.ssi.gouv.fr/IMG/pdf/csw-trustnetworkcard.pdf [accessed 25 February 2014], March 2010.

• [48] Marcel Eckert, Igor Podebrad, and Bernd Klauer. Hardware Based Security Enhanced Direct Memory Access. In Bart Decker, Jana Dittmann, Christian Kraetzer, and Claus Vielhauer, editors, Communications and Multimedia Security, volume 8099 of Lecture Notes in Computer Science, pages 145–151. Springer Berlin Heidelberg, 2013.

• [49] Shawn Embleton, Sherri Sparks, and Cliff Zou. SMM Rootkits: A New Breed of OS Independent Malware. In Proceedings of the 4th International Conference on Security and Privacy in Communication Networks, pages 1–12, New York, NY, USA, 2008. ACM.

• [50] A. Freier, P. Karlton, and P. Kocher. The Secure Sockets Layer (SSL) Protocol Version 3.0. Internet Engineering Task Force: http://tools.ietf.org/html/rfc6101 [accessed 25 February 2014], August 2011. Category: Historic.

• [51] Tal Garfinkel and Mendel Rosenblum. A Virtual Machine Introspection Based Architecture for Intrusion Detection. In Proceedings of the 2003 Network and Distributed Systems Security Symposium, February 2003.

• [52] Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, and N. Asokan. Beyond Secure Channels. In Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, STC ’07, pages 30–40, New York, NY, USA, 2007. ACM.

• [53] Kenneth Goldman, Ronald Perez, and Reiner Sailer. Linking Remote Attestation to Secure Tunnel Endpoints. In STC ’06: Proceedings of the 1st ACM Workshop on Scalable Trusted Computing, pages 21–24, New York, NY, USA, November 2006. ACM Press.

• [54] David Grawrock. Dynamics of a Trusted Platform: A Building Block Approach. Intel Press, 2009.

• [55] John Heasman. Implementing and Detecting a PCI Rootkit. Black Hat: http://www.blackhat.com/presentations/bh-dc-07/Heasman/Paper/bh-dc-07-Heasman-WP.pdf [accessed 25 February 2014], 2006.

• [56] John Heasman. Implementing and Detecting an ACPI BIOS Rootkit. Black Hat Federal: http://www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Heasman.pdf [accessed 25 February 2014], 2006.

• [57] John Heasman. Hacking the Extensible Firmware Interface. Black Hat USA: https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf [accessed 25 February 2014], 2007.

• [58] John L. Hennessy and David A. Patterson. Computer Architecture: A Quantitative Approach. Morgan Kaufmann, May 2005. 3rd edition.

• [59] John L. Hennessy and David A. Patterson. Computer Architecture: A Quantitative Approach. Morgan Kaufmann, 2012. 5th edition.

• [60] Greg Hoglund and Jamie Butler. Rootkits: Subverting the Windows Kernel. Addison Wesley Professional, 2005.

• [61] David Hulton. Cardbus Bus-Mastering: 0Wning The Laptop, January 2006. Shmoocon 2006.

• [62] Intel Corporation. Universal Host Controller Interface (UHCI) Design Guide. The Slackware Linux Project: ftp://ftp.slackware.com/pub/netwinder/pub/misc/docs/29765002-usb-uhci%20design%20guide.pdf [accessed 25 February 2014], March 1996. Revision 1.1.

• [63] Intel Corporation. Intel 3 Series Express Chipset Family. Intel Corporation: http://www.intel.com/Assets/PDF/datasheet/316966.pdf [accessed 25 February 2014], August 2007.

• [64] Intel Corporation. Intel I/O Controller Hub (ICH9) Family. Intel Corporation: http://www.intel.com/content/dam/doc/datasheet/io-controller-hub-9-datasheet.pdf [accessed 25 February 2014], August 2008.

• [65] Intel Corporation. Intel I/O Controller Hub 8/9/10 and 82566/82567/82562V Software Developer’s Manual. Intel Corporation: http://www.intel.com/content/dam/doc/manual/i-o-controller-hub-8-9-10-82566-82567-82562v-software-dev-manual.pdf [accessed 25 February 2014], July 2009.

• [66] Intel Corporation. 2nd Generation Intel Core vPro Processor Family. Intel Corporation: http://www.intel.com/content/dam/doc/white-paper/performance-2nd-generation-core-vpro-family-paper.pdf [accessed 25 February 2014], June 2011.

• [67] Intel Corporation. Access Accounts More Securely with Intel Identity Protection Technology. Intel Corporation: http://ipt.intel.com/Libraries/Documents/Intel_IdentityProtect_techbrief_v7.sflb.ashx [accessed 25 February 2014], February 2011.

• [68] Intel Corporation. Intel 5 Series Chipset and Intel 3400 Series Chipset. Intel Corporation: http://www.intel.com/content/dam/doc/datasheet/5-chipset-3400-chipset-datasheet.pdf [accessed 25 February 2014], January 2012.

• [69] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer’s Manual — Volume 3 (3A, 3B & 3C): System Programming Guide. Intel Corporation: http://download.intel.com/products/processor/manual/325384.pdf [accessed 27 April 2012], March 2012.

• [70] Intel Corporation. Intel Architecture Instruction Set Extensions Programming Reference. Intel Corporation: http://download-software.intel.com/sites/default/files/319433-015.pdf [accessed 25 February 2014], July 2013.

• [71] Intel Corporation. Intel VTune Amplifier 2013 – Document Number: 326734-004. Intel Corporation: http://software.intel.com/sites/products/documentation/doclib/iss/2013/amplifier/lin/ug_docs/index.htm [accessed 25 February 2014], 2013. External Bus Events.

• [72] International Business Machines Corp. IBM 4764 PCI-X Cryptographic Coprocessor. International Business Machines Corp.: http://www-03.ibm.com/security/cryptocards/pcixcc/overview.shtml [accessed 5 March 2012], March 2012.

• [73] International Business Machines Corp. IBM PCIe Cryptographic Coprocessor. International Business Machines Corp.: http://www-03.ibm.com/security/cryptocards/pciecc/overview.shtml [accessed 5 March 2012], March 2012.

• [74] Shan Jiang, Sean Smith, and Kazuhiro Minami. Securing Web Servers against Insider Attack. In ACSAC ’01: Proceedings of the 17th Annual Computer Security Applications Conference, page 265, Washington, DC, USA, 2001. IEEE Computer Society.

• [75] C. Kaufman, P. Hoffman, Y. Nir, and P. Eronen. Internet Key Exchange Protocol Version 2 (IKEv2). The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc5996.txt [accessed 25 February 2014], September 2010. RFC5996.

• [76] S. Kent and K. Seo. Security Architecture for the Internet Protocol. Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4301.txt [accessed 25 February 2014], December 2005. Network Working Group RFC 4346. Obsoletes: RCF2401.

• [77] Samuel T. King, Peter M. Chen, Yi-Min Wang, Chad Verbowski, Helen J. Wang, and Jacob R. Lorch. SubVirt: Implementing Malware with Virtual Machines. In SP ’06: Proceedings of the 2006 IEEE Symposium on Security and Privacy, pages 314–327, Washington, DC, USA, 2006. IEEE Computer Society.

• [78] Markulf Kohlweiss, Ueli Maurer, Cristina Onete, Björn Tackmann, and Daniele Venturi. (De-)Constructing TLS. Cryptology ePrint Archive: http://eprint.iacr.org/2014/020.pdf [accessed 25 February 2014], January 2014.

• [79] Arvind Kumar, Purushottam Goel, and Ylian Saint-Hilaire. Active Platform Management Demystified. 2009. Intel Press.

• [80] Evangelos Ladakis, Lazaros Koromilas, Giorgos Vasiliadis, Michalis Polychronakis, and Sotiris Ioannidis. You Can Type, but You Can’t Hide: A Stealthy GPU-based Keylogger. In Proceedings of the 6th European Workshop on System Security. EuroSec, Prague, Czech Republic, April 2013.

• [81] Hojoon Lee, Hyungon Moon, Daehee Jang, Kihwan Kim, Jihoon Lee, Yunheung Paek, and Brent Byunghoon Kang. KI-Mon: A Hardware-assisted Event-triggered Monitoring Platform for Mutable Kernel Object. In Proceedings of the 22nd Conference on USENIX Security Symposium, SSYM’13. USENIX Association, 2013.

• [82] Yanlin Li, Jonathan M. McCune, and Adrian Perrig. SBAP: Software-based Attestation for Peripherals. In Proceedings of the 3rd International Conference on Trust and Trustworthy Computing, TRUST’10, pages 16–29, Berlin, Heidelberg, 2010. Springer-Verlag.

• [83] Yanlin Li, Jonathan M. McCune, and Adrian Perrig. VIPER: Verifying the Integrity of PERipherals’ Firmware. In Proceedings of the ACM Conference on Computer and Communications Security (CCS), October 2011.

• [84] Loukas K (snare). DE MYSTERIIS DOM JOBSIVS Mac EFI Rootkits. ho/ax.: http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Paper.pdf [accessed 25 February 2014], 2012. Paper.

• [85] Loukas K (snare). DE MYSTERIIS DOM JOBSIVS Mac EFI Rootkits. ho/ax.: http://ho.ax/downloads/De_Mysteriis_Dom_Jobsivs_Black_Hat_Slides.pdf [accessed 25 February 2014], 2012. Slides.

• [86] John Lyle and Andrew Martin. Engineering Attestable Services. In Alessandro Acquisti, SeanW. Smith, and Ahmad-Reza Sadeghi, editors, Trust and Trustworthy Computing, volume 6101 of Lecture Notes in Computer Science, pages 257–264. Springer Berlin Heidelberg, 2010.

• [87] Carsten Maartmann-Moe. Inception. Break & Enter: http://www.breaknenter.org/projects/inception/ [accessed 25 February 2014].

• [88] Vinod Mamtani. DMA Directions And Windows. Microsoft: http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e-84e1-b4085a80e34e/sys-t304_wh07.pptx [accessed 25 February 2014], 2007.

• [89] John Marchesini, Sean W. Smith, Omen Wild, Josh Stabiner, and Alex Barsamian. Open-Source Applications of TCPA Hardware. In ACSAC ’04: Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC’04), pages 294–303, Washington, DC, USA, 2004. IEEE Computer Society.

• [90] David Maynor. DMA: Skeleton Key of Computing && Selected Soap Box Rants. CanSecWest: http://cansecwest.com/core05/DMA.ppt [accessed 25 February 2014], May 2005.

• [91] Jonathan M. McCune, Bryan Parno, Adrian Perrig, Michael K. Reiter, and Arvind Seshadri. Minimal TCB Code Execution. In SP ’07: Proceedings of the 2007 IEEE Symposium on Security and Privacy, pages 267–272, Washington, DC, USA, 2007. IEEE Computer Society.

• [92] Hyungon Moon, Hojoon Lee, Jihoon Lee, Kihwan Kim, Yunheung Paek, and Brent Byunghoon Kang. Vigilare: Toward Snoop-based Kernel Integrity Monitor. In Proceedings of the 2012 ACM Conference on Computer and Communications Security, CCS ’12, pages 28–37, New York, NY, USA, 2012. ACM.

• [93] Tilo Müller, Andreas Dewald, and Felix C. Freiling. AESSE: A Cold-boot Resistant Implementation of AES. In Proceedings of the Third European Workshop on System Security, EUROSEC ’10, pages 42–47, New York, NY, USA, 2010. ACM.

• [94] Tilo Müller, Felix C. Freiling, and Andreas Dewald. TRESOR Runs Encryption Securely Outside RAM. In Proceedings of the 20th USENIX Conference on Security, SEC’11, pages 17–17, Berkeley, CA, USA, 2011. USENIX Association.

• [95] Tilo Müller, Benjamin Taubmann, and Felix C. Freiling. TreVisor: OS-independent Software-based Full Disk Encryption Secure against Main Memory Attacks. In Proceedings of the 10th International Conference on Applied Cryptography and Network Security, ACNS’12, pages 66–83, Berlin, Heidelberg, 2012. Springer-Verlag.

• [96] Quan Nguyen. Issues in Software-based Attestation. Kaspersky Lab: http://www.kaspersky.com/images/Quan%20Nguyen.pdf [accessed 25 February 2014], November 2012.

• [97] Alfredo Ortega and Anibal Sacco. Deactivate the Rootkit: Attacks on BIOS Anti-theft Technologies. Black Hat USA: http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-SLIDES.pdf [accessed 25 February 2014], July 2009. Slides.

• [98] Alfredo Ortega and Anibal Sacco. Deactivate the Rootkit: Attacks on BIOS Anti-theft Technologies. Black Hat USA: http://www.blackhat.com/presentations/bh-usa-09/ORTEGA/BHUSA09-Ortega-DeactivateRootkit-PAPER.pdf [accessed 25 February 2014], July 2009. Paper.

• [99] Siani Pearson, Boris Balacheff, Liqun Chen, David Plaquin, and Graeme Proudler. Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. Hewlett-Packard Professional Books.

• [100] Nick L. Petroni, Jr., Timothy Fraser, Jesus Molina, and William A. Arbaugh. Copilot – A Coprocessor-based Kernel Runtime Integrity Monitor. In Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13, SSYM’04, Berkeley, CA, USA, 2004. USENIX Association.

• [101] David R. Piegdon and Lexi Pimenidis. Targeting Physically Addressable Memory. In Bernhard Hämmerli and Robin Sommer, editors, Detection of Intrusions and Malware, and Vulnerability Assessment, volume 4579 of Lecture Notes in Computer Science, pages 193–212. Springer Berlin Heidelberg, 2007.

• [102] Marsh Ray and Steve Dispensa. Renegotiating TLS. Internet Archive Way Back Machine: http://web.archive.org/web/20130203213851/http://extendedsubset.com/Renegotiating_TLS.pdf [accessed 25 February 2014], November 2009.

• [103] Sasha Rehbock. Trustworthy Clients: Extending TNC for Integrity Checks in Web-based Environments. Master’s thesis, University of Canterbury. Computer Science and Software Engineering, 2008. http://ir.canterbury.ac.nz/handle/10092/2369 [accessed 25 February 2014].

• [104] James Reinders. VTune Performance Analyzer Essentials: Measurement and Tuning Techniques for Software Developers. Engineer to Engineer Series. Intel Press, 2005.

• [105] Mark E. Russinovich and David A. Solomon. Windows Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition. Microsoft Press, 5th edition, 2009.

• [106] Mark E. Russinovich, David A. Solomon, and Alex Ionescu. Windows Internals 6th Edition, Part 2. Microsoft Press, 2012.

• [107] Joanna Rutkowska. Red Pill… Or How to Detect VMM Using (almost) One CPU Instruction. Internet Archive: http://web.archive.org/web/20110726182809/http://invisiblethings.org/papers/redpill.html [accessed 25 February 2014], November 2004.

• [108] Joanna Rutkowska. Subverting Vista Kernel for Fun and Profit. Black Hat: http://blackhat.com/presentations/bh-usa-06/BH-US-06-Rutkowska.pdf [accessed 25 February 2014], August 2006.

• [109] Ahmad-Reza Sadeghi and Steffen Schulz. Extending IPsec for Efficient Remote Attestation. In Radu Sion, Reza Curtmola, Sven Dietrich, Aggelos Kiayias, Josep M. Miret, Kazue Sako, and Francesc Seb, editors, Financial Cryptography and Data Security, volume 6054 of Lecture Notes in Computer Science, pages 150–165. Springer Berlin Heidelberg, 2010.

• [110] Ahmad-Reza Sadeghi, Marko Wolf, Christian Stüble, N. Asokan, and Jan-Erik Ekberg. Enabling Fairer Digital Rights Management with Trusted Computing. In Proceedings of the 10th International Conference on Information Security, ISC’07, pages 53–70, Berlin, Heidelberg, 2007. Springer-Verlag.

• [111] Fernand Lone Sang, Éric Lacombe, Vincent Nicomette, and Yves Deswarte. Exploiting an I/OMMU Vulnerability. In Proceedings of the 5th International Conference on Malicious and Unwanted Software (MALWARE), pages 7–14, October 2010.

• [112] Fernand Lone Sang, Vincent Nicomette, and Yves Deswarte. I/O Attacks in Intel-PC Architectures and Countermeasures. SysSec: http://www.syssec-project.eu/media/page-media/23/syssec2011-s1.4-sang.pdf [accessed 25 February 2014], July 2011.

• [113] S. Santesson. TLS Handshake Message for Supplemental Data. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc4680.txt [accessed 25 February 2014], September 2006. RFC4680.

• [114] Russ Sevinsky. Funderbolt – Adventures in Thunderbolt DMA Attacks. Black Hat: https://media.blackhat.com/us-13/US-13-Sevinsky-Funderbolt-Adventures-in-Thunderbolt-DMA-Attacks-Slides.pdf [accessed 25 February 2014], 2013.

• [115] Gaurav Shah, Andres Molina, and Matt Blaze. Keyboards and Covert Channels. In Proceedings of the 15th Conference on USENIX Security Symposium - Volume 15, USENIX-SS’06, Berkeley, CA, USA, 2006. USENIX Association.

• [116] Tom Shanley and Don Anderson. ISA System Architecture. Mindshare PC System Architecture. Addison Wesley, 1995.

• [117] Tom Shanley and Bob Colwell. The Unabridged Pentium 4: IA32 Processor Genealogy. PC System Architecture Series. Addison Wesley Professional, 2005.

• [118] John P. Shen and Mikko H. Lipasti. Modern Processor Design: Fundamentals of Superscalar Processors. Electrical and Computer Engineering. McGraw-Hill Companies, Incorporated, 2005.

• [119] Patrick Simmons. Security Through Amnesia: A Software-based Solution to the Cold Boot Attack on Disk Encryption. In Proceedings of the 27th Annual Computer Security Applications Conference, ACSAC ’11, pages 73–82, New York, NY, USA, 2011. ACM.

• [120] Ned M. Smith. System and Method for Combining User and Platform Authentication in Negotiated Channel Security Protocols. United States Patent Application 20050216736: http://www.freepatentsonline.com/20050216736.html [accessed 25 February 2014], September 2005.

• [121] Stephen L. Smith. Intel Roadmap Overview August 20th 2008. Intel Corporation: http://download.intel.com/pressroom/kits/events/idffall_2008/SSmith_briefing_roadmap.pdf [accessed 25 February 2014], August 2008.

• [122] Patrick Stewin. A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory. In Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2013.

• [123] Patrick Stewin and Iurii Bystrov. Understanding DMA Malware. In Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, 2012.

• [124] Patrick Stewin and Iurii Bystrov. Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware. http://stewin.org/slides/44con_2013-dedicated_hw_malware-stewin_bystrov.pdf [accessed 25 February 2014], September 2013. 44CON.

• [125] Patrick Stewin and Iurii Bystrov. Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware. http://stewin.org/slides/30c3-dedicated_hw_malware-stewin_bystrov_final.pdf [accessed 25 February 2014], December 2013. 30C3: 30th Chaos Communication Congress.

• [126] Patrick Stewin, Jean-Pierre Seifert, and Collin Mulliner. Poster: Towards Detecting DMA Malware. In Proceedings of the 18th ACM Conference on Computer and Communications Security, CCS ’11, pages 857–860, New York, NY, USA, 2011. ACM.

• [127] Jon Stokes. Inside The Machine: An Illustrated Introduction to Microprocessors and Computer Architecture. No Starch Press Series. No Starch Press, 2007.

• [128] Frederic Stumpf, Omid Tafreschi, Patrick Röder, and Claudia Eckert. A Robust Integrity Reporting Protocol for Remote Attestation. In Proceedings of the Second Workshop on Advances in Trusted Computing (WATC ’06 Fall), Tokyo, December 2006.

• [129] Peter Szor. The Art Of Computer Virus Research And Defense. Symantec Press Series. Addison Wesley Publishing Company Incorporated, 2005.

• [130] TCG Infrastructure Working Group (IWG). TCG Infrastructure Working Group Reference Architecture for Interoperability (Part I). Trusted Computing Group: http://www.trustedcomputinggroup.org/files/resource_files/8770A217-1D09-3519-AD17543BF6163205/IWG_Architecture_v1_0_r1.pdf [accessed 25 February 2014], June 2005. Specification Version 1.0 Revision 1.

• [131] Alexander Tereshkin and Rafal Wojtczuk. Introducing Ring -3 Rootkits. Black Hat: http://www.blackhat.com/presentations/bh-usa-09/TERESHKIN/BHUSA09-Tereshkin-Ring3Rootkit-SLIDES.pdf [accessed 25 February 2014], July 2009.

• [132] The Computer Language Company Inc. Heartbeat. Computer Desktop Encyclopedia: http://lookup.computerlanguage.com/host_app/search?cid=C999999&term=heartbeat&lookup.x=27&lookup.y=21 [accessed 25 February 2014], 2013.

• [133] Robert Bruce Thompson and Barbara Fritchman Thompson. PC Hardware in a Nutshell, 3rd Edition. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2003.

• [134] Arrigo Triulzi. Project Maux Mk.II. The Alchemist Owl: http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-PACSEC08-Project-Maux-II.pdf [accessed 25 February 2014], 2008.

• [135] Arrigo Triulzi. The Jedi Packet Trick Takes Over the Deathstar. The Alchemist Owl: http://www.alchemistowl.org/arrigo/Papers/Arrigo-Triulzi-CANSEC10-Project-Maux-III.pdf [accessed 25 February 2014], March 2010.

• [136] Trusted Computing Group. TCG PC Client Specific Implementation Specification For Conventional BIOS. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/temp/64505409-1D09-3519-AD5C611FAD3F799B/PCClientImplementationforBIOS.pdf [accessed 25 February 2014], July 2005.

• [137] Trusted Computing Group. TCG Trusted Network Connect – TNC IF-T: Binding to TLS. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/static_page_files/1D8D3689-1A4B-B294-D0E7699128CB9817/TNC_IFT_TLS_v2_0_r7.pdf [accessed 25 February 2014], February 2013. Specification Version 2.0 Revision 7.

• [138] Trusted Network Connect Work Group. TCG Trusted Network Connect TNC Architecture for Interoperability. Trusted Computing Group: http://www.trustedcomputinggroup.org/files/resource_files/2884F884-1A4B-B294-D001FAE2E17EA3EB/TNC_Architecture_v1_5_r3-1.pdf [accessed 25 February 2014], May 2012. Specification Version 1.5, Revision 3.

• [139] USB Implementers Forum, Inc. USB.org - ExpressCard specs. USB Implementers Forum, Inc.: http://www.usb.org/developers/expresscard/EC_specifications [accessed 25 February 2014], 2009.

• [140] Giorgos Vasiliadis, Michalis Polychronakis, and Sotiris Ioannidis. GPU-Assisted Malware. In Proceedings of the 5th International Conference on Malicious and Unwanted Software (MALWARE), pages 1–6, October 2010.

• [141] Amit Vasudevan, Jonathan McCune, James Newsome, Adrian Perrig, and Leendert van Doorn. CARMA: A Hardware Tamper-resistant Isolated Execution Environment on Commodity x86 Platforms. In Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security, ASIACCS ’12, pages 48–49, New York, NY, USA, 2012. ACM.

• [142] Davide Vernizzi. TLS Hello Extensions and Supplemental Data. Blog: http://tlsext-general.blogspot.de/2008/12/tls-hello-extensions-and-supplemental.html [accessed 25 February 2014], December 2008.

• [143] Jian Wang, Zhiyong Zhang, Fei Xiang, Lili Zhang, and Qingli Chen. A Trusted Authentication Protocol based on SDIO Smart Card for DRM. International Journal of Digital Content Technology & Its Applications, 6(23):222–233, December 2012.

• [144] Filip Wecherowski. A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers. Phrack Magazine Issue 0x42, Phile #0x0B of 0x11: http://www.phrack.org/issues.html?issue=66&id=11#article [accessed 25 February 2014], June 2009.

• [145] Rafal Wojtczuk and Joanna Rutkowska. Attacking SMM Memory via Intel CPU Cache Poisoning. Invisible Things Lab: http://invisiblethingslab.com/itl/Resources.html [accessed 25 February 2014], March 2009.

• [146] Rafal Wojtczuk and Joanna Rutkowska. Attacking Intel TXT via SINIT Code Execution Hijacking. Invisible Things Lab: http://www.invisiblethingslab.com/resources/2011/Attacking_Intel_TXT_via_SINIT_hijacking.pdf [accessed 25 February 2014], November 2011.

• [147] Rafal Wojtczuk and Joanna Rutkowska. Following the White Rabbit: Software Attacks against Intel VT-d Technology. Invisible Things Lab: http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf [accessed 25 February 2014], April 2011.

• [148] Rafal Wojtczuk, Joanna Rutkowska, and Alexander Tereshkin. Another Way to Circumvent Intel Trusted Execution Technology. Invisible Things Lab: http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf [accessed 25 February 2014], December 2009.

• [149] Rafal Wojtczuk and Alexander Tereshkin. Attacking Intel BIOS. Invisible Things Lab: http://invisiblethingslab.com/resources/bh09usa/Attacking%20Intel%20BIOS.pdf [accessed 25 February 2014], July 2009.

• [150] Ben-Ami Yassour, Muli Ben-Yehuda, and Orit Wasserman. On the DMA Mapping Problem in Direct Device Assignment. In Proceedings of the 3rd Annual Haifa Experimental Systems Conference, SYSTOR ’10, pages 18:1–18:12, New York, NY, USA, 2010. ACM.

• [151] Yue Yu, Sun Hao, and Kong Yanan. Expand the SSL/TLS Protocol on Trusted Platform Module. In Proceedings of the International Conference on Computer Application and System Modeling (ICCASM), volume 11, pages V11–48–V11–51, 2010.

• [152] Jonas Zaddach, Anil Kurmus, Davide Balzarotti, Erik Olivier Blass, Aurelien Francillon, Travis Goodspeed, Moitrayee Gupta, and Ioannis Koltsidas. Implementation and Implications of a Stealth Hard-Drive Backdoor. In Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC), ACSAC 13. ACM, December 2013.

• [153] Fengwei Zhang. IOCheck: A Framework to Enhance the Security of I/O Devices at Runtime. In Proceedings of the 43rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN’13), June 2013.

• [154] P. Zimmermann, A. Johnston, and J. Callas. ZRTP: Media Path Key Agreement for Unicast Secure RTP. The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc6189.txt [accessed 25 February 2014], April 2011. RFC6189.

原文始发于微信公众号（赛博堡垒）：Intel ME之暗影匕首初章：检测针对宿主内存的基于外设的攻击 （下篇）