Detecting Peripheral-based Attacks on the Host Memory

Patrick Stewin

摘要

对手可以通过在目标平台上部署 rootkit 技术以便以某种隐秘的方式持续攻击计算机系统。行业和政治间谍活动、对用户的监控，以及引导网络犯罪等行为要求对计算机系统进行隐秘攻击。利用某种 rootkit 技术意味着，所实现的攻击代码中的一部分负责隐藏此次攻击。被加载到诸如网卡或者特殊的微控制器等外设的攻击代码目前成为了 rootkit 进化的顶峰。本工作检视了宿主计算机上的此类基于外设的隐秘攻击。外设拥有一块专用处理器以及专用的运行时内存以处理其任务。这意味着这些外设实质上是一个独立的系统。攻击者得益于这种隔离。外设通常通过宿主的主内存同宿主进行通讯。攻击者利用了这一事实。宿主的所有运行时数据存在于主内存中，这包括密码学密钥、口令、已打开的文件以及其他敏感数据。攻击者只需定位这些数据。随后，攻击者可以利用外设的直接内存访问机制暗中读取和修改这些数据。这使得绕过诸如业界最先进的反病毒软件和加固的现代操作系统内核等安全软件成为可能。

检测这样的攻击是本工作的目标。基于独立微控制器的隐形恶意软件被实现为引导技术分析。此恶意软件的概念验证称为 DAGGER，它来自于 Direct memory Access based keystroke code loGGER（基于直接内存访问的击键码记录器）。对此恶意软件的开发和分析揭示了基于外设的恶意软件的重要属性。其检测程序称为 BARM——Bus Agent Runtime Monitor（总线代理运行时监视器）。此检测程序揭示了通过利用某些硬件属性对宿主的主内存进行的基于外设的隐秘攻击。一种永久的并且高效利用资源的测定策略保证了此检测程序同时还能检测瞬时攻击。如果所应用的测定策略只会在特定的时间点进行测定，则此类瞬时攻击将会成为可能。攻击者可以如此利用此种测定策略，通过在两次测定之间对系统进行攻击，并且在系统被测定之前销毁所有进攻痕迹。对于之前提出的预防性保护方式，即输入/输出内存管理单元，此检测程序代表了一种替代解决方案。由于实践方面的原因，之前提出的方法不一定是高效的。这一事实再加上由基于外设的恶意软件所带来的威胁共同要求本工作所呈现的替代检测方案。此检测程序不仅能够揭示攻击，同时能够终止该恶意设备。BARM 立即检测到并且阻止由 DAGGER 引导的攻击。其性能开销可以忽略。更进一步地，BARM 能够向外部平台报告宿主的主内存是否受到了外设的攻击。

与本论文相关的发表

本论文呈现的工作带来了下列通过同行评审的发表：

Understanding DMA Malware, Patrick Stewin and Iurii Bystrov, DIMVA2012 Proceedings of the 9th Conference on Detection of Intrusions and Malware & Vulnerability Assessment, Heraklion, Crete, Greece, July 26-27th, 2012 ([参见 123] / 第 4 章)
Extended Abstract – Poster: Towards Detecting DMA Malware, Patrick Stewin, Jean-Pierre Seifert, Collin Mulliner, CCS2011 Proceedings of the 18th ACM Conference on Computer and Communications Security, 2011 ([参见 126] / 第 4 章)
A Primitive for Revealing Stealthy Peripheral-based Attacks on the Computing Platform’s Main Memory, Patrick Stewin, RAID2013 Proceedings of the 16th International Symposium on Research in Attacks, Intrusions and Defenses (RAID), St. Lucia, October 23-25, 2013 ([参见 122] / 第 5 章)

下列通过同行评审的发表根据第 6 章进行了更新，以考虑到基于 DMA 的恶意软件的场景，这也是本论文关注的焦点：

Beyond Secure Channels, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, N. Asokan, STC2007 Proceedings of the 2007 ACM Workshop on Scalable Trusted Computing, 2007 ([参见 52])
An Efficient Implementation of Trusted Channels based on OpenSSL, Frederik Armknecht, Yacine Gasmi, Ahmad-Reza Sadeghi, Patrick Stewin, Martin Unger, Gianluca Ramunno, Davide Vernizzi, STC2008 Proceedings of the 3rd ACM Workshop on Scalable Trusted Computing, 2008 ([参见 10])

第 1 章简介

我认为，大多数人甚至都不知道 rootkit 是什么，那么他们为什么要去关心它呢？——Thomas Hesse，索尼全球数字业务前主席

大多数人可能会将 rootkit 这一术语同针对计算机平台的攻击相关联。实际上，对手部署 rootkit 是为了攻击计算机用户。基于 rootkit 的攻击被用于引导行业和政治间谍活动以及网络犯罪 [参见 16，p.22-25]。对手通过引导行业间谍活动来偷取知识产权以减少技术开发周期的成本。政治间谍活动不同于行业间谍活动。在政治间谍活动中，对手所感兴趣的是国家机密而非新技术。网络犯罪分子利用 rootkit 来偷取互联网银行凭证、口令以及其他敏感信息。rootkit 也可被用于引导对最终用户的持久监控。rootkit 还可被用于强制执法，以执行对嫌疑人的监控 [参见 16，p.21]。但是，准确地说，rootkit 到底是什么？它是后门吗？它是 特洛伊木马 吗？换言之，rootkit 所包含的恶意负载是什么类型，以及目标计算机是如何被此 rootkit 所渗透的？

术语 rootkit 的若干种定义可以在这样一些文献中找到，例如 Bill Blunden 所著的 The Rootkit Arsenal: Escape And Evasion In The Dark Corners Of The System [16]。他的著作同时评估了 Mark Russinovich（此人以 Windows Internals [106] 系列著作而闻名）和 Greg Hoglund（Rootkits: Subverting the Windows Kernel [60] 一书的作者）对于 rootkit 的定义。最后，Bill Blunden 得出了他自己的定义 [参见 16，p.12]：

rootkit 在一台设备上建立了一个远程接口，此接口使得系统可以被操纵……数据可以被收集（例如监控），以某种难以被观察到的方式（例如隐藏）。

所有这些定义提示了 rootkit 在总体上所展现出来的一个重要属性，即能够隐秘地运作的能力。攻击者通过部署 rootkit 来掩护用于攻击目标计算机的代码。这一点回答了关于 rootkit 的恶意负载的问题。此负载可以被用于执行在用户看来是恶意行为的任何东西。此恶意行为也可以是后门。后门被用于绕过诸如认证请求等安全机制以获得对某台计算机系统的访问权限。后门还可以为攻击者提供对于某台计算机的远程访问权限。在攻击者看来，将此后门隐藏起来是有意义的。此后门应该在计算机用户毫不知情的情况下被使用。因此，后门可以得益于 rootkit 机制。rootkit 负载的另一个例子是监控程序，此程序通过激活目标计算机的话筒和摄像头以暗中监视该计算机的用户。能够捕获由某位计算机用户所输入的所有击键的击键码记录器也是恶意负载的常见范例。

然而，对于攻击者的挑战在于渗透目标计算机平台。此攻击者必须实现某种类型的 rootkit 安装程序。rootkit 安装程序通常被称为 释放器 [参见 16，p.9] [33]。这样的释放器可以基于最常见的渗透机制之一，即特洛伊木马，或者简称木马。木马的目的在于在目标计算机将要安装某个预想的程序、特性或者功能时对其进行误导。与之相反，其结果是用户安装了诸如击键码记录器或者后门等恶意负载。诸如此类的负载通常被部署于高权限环境，并且利用 rootkit 技术加以掩护。另一种常见的渗透方式是利用某个安全漏洞。此 rootkit 安装程序可以实现某种 漏洞利用。漏洞利用是一段利用安全漏洞的攻击代码。所谓的 零日漏洞 相对于非零日漏洞更具威胁性。零日漏洞所利用的是某个此前未知的安全漏洞，这可能对于攻击者更加有利。它使得攻击者能够引导一次对于目标计算机的隐秘渗透。

rootkit 的另一个关键属性是其代码运行于可能的最高权限之上。其目标是获得至少是高于任何潜在的检测机制的权限。这使得 rootkit 能够控制并且修改检测机制。在某种程度下，检测机制将会无法检测 rootkit 或者由此 rootkit 掩护的恶意负载。这是攻击者寻求新的、更加强大的攻击向量的原因。攻击者获得的权限越多，其所获得的对于目标计算机的控制也就越多。

攻击者的目标是获得对目标计算机的绝对控制。rootkit 进化 记录了攻击者和反恶意软件社区之间的军备竞赛。相对于早期的 rootkit，现在的 rootkit 已经前进到了更高权限的执行环境。近年来 [35，36，47，134，135] rootkit 的进化达到了一个新的水平。攻击者开始利用平台外设的隔离执行环境。具有专用处理器、专用内存以及直接访问宿主的运行时内存的硬件特性的外设能够掩护用于攻击目标计算机的恶意负载。这样的攻击被认为是隐秘的。市场上可获得的现代反病毒软件之类尚未考虑基于外设的执行环境。这样的软件执行于宿主处理器上，并且通常只将硬盘和主内存考虑为能够存储恶意代码。

1.1 问题表述

恶意软件是对数据的机密性、完整性以及可用性的威胁。对于基于外设的恶意软件的情况，攻击者可以利用外设的隐形潜力。隐藏在平台外设中的恶意软件不会被反病毒软件所考虑。取决于外设，安全软件甚至不能访问该设备的内部工作。例如某些管理控制器拥有对全部宿主内存的访问，并且提供远程管理特性。为了防止滥用，制造商应用保护机制以阻止对此执行环境的内部工作的访问。

这种机制，如果被基于外设的恶意软件所利用以攻击宿主，则称之为直接内存访问或者 DMA。在本工作中，我们将会引入术语 DMA 恶意软件 以用于诸如此类的攻击。DMA 恶意软件拥有同 rootkit 相似的特性。当前的反制措施无法应对 DMA 恶意软件的挑战。例如，对本意将要在外设上运行的代码进行加载时完整性检测等机制并不能阻止运行时攻击。这同样适用于数字签名的固件镜像的情形。另一种方式是基于延时的证明。此类证明要求一段散列值在一定的时间框架内被计算出来。然而，这同样要求修改外设固件，并且不能阻止瞬时攻击。诸如特殊监控以及内存总线嗅探等其他方式基于特殊硬件或者硬件特性。阻止敏感数据出现在主内存中同样不能奏效。这些数据可以通过 DMA 攻击被转储到主内存中 [脚注 1]。

脚注 1：具体细节可以在 3.2 节“相关工作——反制措施”部分找到。

一种被提议的针对 DMA 攻击的反制措施是使用一种所谓的 输入/输出内存管理单元（I/OMMU）。这样的管理单元可以限制外设对宿主的部分主内存的访问。然而，此技术具有重大缺陷。已有证据表明 I/OMMU 可以被攻击并且绕过 [111，146，147，148]。因此，I/OMMU 不一定可信。某些操作系统，诸如 Windows，并不提供驱动程序以支持 I/OMMU。此外，并非每种芯片组都提供 I/OMMU。更进一步地，I/OMMU 不能处理内存访问策略冲突。例如，Bulygin [25] 展示了如何利用外设以揭示存在于宿主的运行时内存中的恶意软件。我们将相同的执行环境用于第 4 章的攻击研究。例如，如果 I/OMMU 被配置为允许外设扫描宿主的全部运行时内存以揭示 rootkit，那么我们的攻击代码同样可以访问全部运行时内存以偷取敏感数据。因此，本工作并不依赖 I/OMMU 作为一种反制措施。更进一步地，I/OMMU 可能会引入显著的性能开销 [13，150]，这使得 I/OMMU 对于某些场景并不理想。由于这些考虑，我们相信缺少这样一种能够检测恶意内存访问并且具有可忽略的性能开销的运行时监视器。这样一种运行时监视器的缺失正是推动本工作的动力之一。

1.2 研究问题和方法论

我们的研究兴趣基于现代 x86 平台的隐形能力。这些能力被对手以利用以隐藏恶意代码，如同 rootkit 进化所记载，同时参见 2.1 节。这提出了这样一个问题，即不可被检测到的软件是否能够存在。为了检验这个问题，我们考虑了 rootkit 中的下一个逻辑步骤，即利用平台外设以攻击宿主的运行时内存。

我们开发了一种恶意软件的 概念验证（PoC），它执行于某个隔离的外设上。此外设的硬件提供了对宿主的运行时内存的访问。我们以击键码记录器的形式实现了一次攻击。这意味着我们的恶意软件搜索宿主操作系统的键盘缓冲并且监视该缓冲以捕获击键码。对此击键码记录器的评估指导了我们后续的一个研究问题，即宿主系统能否保护自己以对抗基于外设的宿主主内存攻击？为了回答这个问题，我们实现了一个运行时监视器，它执行于宿主 CPU 上。有了这个监视器，我们想要展示这一点，即来自平台外设的对宿主主内存的额外（恶意）访问事实上是可以被检测到的。我们要求基于宿主 CPU 的检测程序能够检测恶意访问，即使它不能访问该恶意外设的隔离执行环境。

我们利用我们的恶意软件样本以得出此类恶意软件的一般属性。随后我们利用了这些属性以检测由恶意软件所引导的内存访问。我们定义了这样一种属性，它是每一种攻击宿主内存的基于外设的恶意软件都体现出来的。基于此，我们将我们的恶意软件概念验证视为对于此类恶意软件典型的。我们实现了基于宿主 CPU 的检测程序以揭示由平台外设通过直接内存访问所引导的非法内存访问。其目标是实现这样一种运行时监视器，它不仅对于宿主 CPU 只造成最小化的性能开销，同时能够阻止瞬时攻击。

我们还在我们的研究的最后一部分考虑了网卡。网卡同样可以托管恶意软件。特别是在企业环境中，某个计算机平台被要求向某个中央管理员平台报告其状态。这样的状态报告可以被执行于网卡上的恶意软件修改。因此，我们开发了一种合法报告信道。此信道有助于揭示针对此类状态报告的攻击。

实验研究环境

我们的实验环境基于 Intel x86 硬件。我们用于执行我们的基于外设的恶意软件的隔离环境是 Intel 管理引擎（Intel ME [79]）。Intel ME 是一种特殊的微控制器，它运行某种强大的平台管理固件。管理员可以利用此管理固件远程重装操作系统，即使操作系统已经不可引导，并且该平台不可通过操作系统的网络栈抵达。ME 同样能够在平台处于待机或者关机的情况下运作。由于这些特性，其制造商 Intel 建立了这样的保护机制，它们不能在不付出巨大努力的情况下被绕过。ME 是同宿主系统相隔离的。Intel ME 环境是同宿主完全隔离的，而其他外设可以通过调试寄存器以及其他机制来访问。

从检测程序的角度来看，ME 是用于托管基于外设的恶意软件的执行环境的最坏的案例。宿主 CPU 无法访问 ME 环境。我们将这一最坏案例环境用于我们的研究。我们通过应用某个只能工作在特定芯片组 [脚注 2] 上的漏洞来渗透 ME 环境。请注意，此工作并不致力于查找未被发现的安全漏洞。我们重复利用了某个已知的安全漏洞来设置我们自己的实验环境，是由于缺少一块适合的 Intel 开发板。

脚注 2：此漏洞利用仅适用于刚好具有特定版本 BIOS 的 Intel Q35 芯片组。Intel 通过提供 BIOS 更新堵住了对应的安全漏洞。

1.3 论文贡献的影响

例如为了引导行业间谍活动或者偷取在线银行凭证等，攻击者要求能够隐秘运作的恶意软件。基于外设的恶意软件保证了攻击仍然不可被检测到。能够满足隐秘恶意软件运作的需求的外设存在于几乎每一部现代计算机平台中。诸如显卡、网卡和管理控制器等是台式机、服务器系统以及其他计算机终端的组成部分。移动电话和平板计算机也具有那些带有独立处理器、内存以及对宿主运行时内存的直接访问的外设。这意味着所有现代平台都易受基于外设的恶意软件的攻击。这样的恶意软件执行于隔离环境中，并且处于由操作系统内核所设置的反病毒软件和安全机制的视野之外。由于缺少针对基于外设的恶意软件的检测程序以及在反病毒软件中缺少类似功能，本论文的贡献可能对上述计算机设备及其用户具有重大影响。我们将本论文的主要贡献总结如下：

DMA 恶意软件研究

我们定义了 DMA 恶意软件以便能够区分不同的 DMA 代码。这样的恶意软件执行于某个外设上，并且能够通过直接内存访问攻击宿主。我们开发了一种 DMA 恶意软件实现的概念验证，它能够利用某个隔离的外设来引导隐秘攻击。我们的概念验证称为 DAGGER，它来自于 DmA-based keystroke code loGGER（基于 DMA 的击键码记录器）。DAGGER 可以攻击不同的宿主操作系统。DAGGER 强调了 DMA 恶意软件在实践中是多么地高效。我们识别了 DMA 恶意软件的核心属性以研究诸如此类的恶意软件的属性。这些属性是 DMA 恶意软件检测程序的基础。在一次早期实验中，我们提供了关于 DMA 的副作用存在的证据。我们展示了这样一种效应可以如何利用通常的宿主 CPU 特性进行测定。这是 DMA 恶意软件检测程序开发的第一步（参见第 4 章）。

检测 DMA 恶意软件

我们开发了一种监视器，它能够通过比较实际的内存总线活动和预期的内存总线活动来检测 DMA 恶意软件。我们的方法能够确定并且比较实际的总线活动而不受任何固件或者硬件修改的影响。此检测器基于这样一种特性，它实现了永久的运行时监控并且运行在宿主 CPU 上。我们实现并且评估了这样一种概念验证，我们称之为 总线代理运行时监视器（BARM）。我们的监视器实现了这样一种监视策略，它会考虑瞬时攻击。它只会造成可忽略的性能开销。BARM 可以检测并且立即终止 DMA 恶意软件（参见第 5 章）。

排除了 DMA 恶意软件干扰的合法平台状态报告

我们展示了我们的检测方法同样适用于这样的场景，在此，一部计算机平台必须向某个中央管理员平台报告其状态。我们建立了这样一种合法报告信道，它能够揭示由执行于网卡上的恶意软件所引导的攻击。这意味着我们改良了 BARM 以揭示 中间人（MitM）攻击，并且阻止由网卡引导的中继攻击。我们实现了一种信道以便将平台状态信息安全地传输至一台外部计算机。此平台状态信息允许远程实体评估 BARM 的测定结果。这意味着远程实体可以确定其对端是否受到了 DMA 恶意软件的攻击。我们的信道将宿主 CPU 视为信道的端点，而非完整的目标平台。这排除了网卡作为端点的一部分。我们改良了 BARM 以说明由网卡所造成的内存总线活动。此改良的 BARM 利用 OpenSSL 来实现合法报告信道。我们还修改了 TLS 握手协议以便在通讯会话的最初阶段就说明平台状态信息。我们的修改仍然符合 TLS 规范（参见第 6 章）。

具体的工作细节可以在各对应章节找到。

1.4 论文结构

根据我们的方法论，我们按照如下方式组织论文结构。下一章，我们将会介绍必需的技术背景、预备知识以及假设。用于我们的评估的目标平台是一种基于 Intel x86 的现代系统，参见 2.2，2.3，2.4，2.5 和 2.6 节。这些章节介绍了关于该目标平台的大部分重要术语，特别是宿主 CPU、直接内存访问（DMA）、总线主控以及 输入/输出内存管理单元。我们还在 2.7 节介绍了我们的假设以及由此得出的对手模型。第 3 章覆盖了相关工作。由于我们同时考虑攻击以及攻击检测和防护两端，我们必须认真研究两端的相关工作。关于 DMA 攻击的相关工作描述于 3.1 节。3.2 节呈现了那些考虑了反制措施的前期工作。更进一步地，我们想要使得我们的目标平台能够向外部平台报告其关于基于 DMA 的恶意软件的状态。为了达成这一目的，我们要求一种能够揭示由网卡发动的中间人攻击的通讯信道。这是必需的，由于我们同时将网卡视为能够隐藏 DMA 攻击代码的专用硬件。

我们引导了针对 DMA 恶意软件的研究并且将其结果呈现于第 4 章。关于 DMA 恶意软件的定义给出于 4.1 节。在 4.2 节，我们呈现了 DMA 恶意软件的核心功能。我们自己的 DMA 恶意软件的设计和实现呈现于 4.3 节。4.4 节描述了对于 DAGGER 的评估。4.5 节考虑了反制措施并且特别讨论了 I/OMMU 的问题。在同一节中，我们描述了我们如何能够利用这些属性以显示首个 DMA 副作用。由于宿主 CPU 无法直接意识到由受到攻击的外设所引导的非法内存访问，我们试图触发一种发生于外设访问主内存时发生的副作用。

第 4 章所呈现的 DMA 副作用是推动我们实现我们于第 5 章所介绍的运行时监视器的动力。在第 5 章“DMA 恶意软件检测初步”中，我们展示了 DMA 副作用可以被如何利用以开发检测工具。我们定义了一种通用检测模型，它有助于我们构建检测工具，参见 5.1 节。随后，我们在 5.2 节中呈现了一种基于流行的 Intel x86 平台的概念验证实现。我们在 5.3 节评估了我们的实现。我们同时利用我们于第 4 章开发的 DMA 恶意软件测试了 BARM。最后，BARM 利用了这一事实，即我们的 DMA 恶意软件必须搜索有价值的数据，由此造成了一定量的总线传输。

在第 6 章，我们改良了我们的检测工具以实现一种合法状态报告应用程序。此应用程序将 BARM 测定结果发送至某个外部平台。其目标是实现这样一种安全通讯信道，此信道排除了由运行于网卡之上的恶意软件引导中间人攻击的可能性。在 6.1 节，我们呈现了一种模型以协商一种合法报告信道。我们需要一种诸如 TLS 的安全信道，它绑定于实际的通讯端点，即宿主 CPU。我们关于合法报告应用程序的概念验证基于 OpenSSL，参见 6.2 节。此实现章节同时描述了为了考虑网卡而必需的 BARM 改良。关于我们的实现的评估呈现于 6.3 节。我们还利用我们自己的 DMA 恶意软件 DAGGER 测试了关于网络的 BARM 改良。合法报告信道的安全性考虑于 6.4 节讨论。我们关于此论文的结论以及今后的工作呈现于最后一章，第 7 章。

第 2 章技术背景、预备知识和假设

在孩子面前放一台计算机并且指望由它来教育他，就好比在他的枕头底下放一本书，只不过更加昂贵而已。——Joseph Weizenbaum，德国/美国计算机科学家

为了理解我们的后续章节，尽管获知大量关于现代计算机架构的细节是有益的，然而在这里解释所有这些晦涩的细节并不现实。因此，我们将读者引向一系列文献 [参见 54，59，118，127] 以获得关于此话题的完整论述。我们将本章限定为理解本工作所必需的最重要的术语。我们从 rootkit 进化 开始。这段进化史突出展示了为何呈现于后续各节的技术背景有助于理解本工作。

2.1 rootkit 进化

在流行的 x86 平台上，rootkit 的能力与其执行环境强烈相关，例如用户模式（3 环）或者内核模式（0 环）。现代 x86 处理器提供所谓的保护环以区分不同权限的执行环境，参见图 2.1。对 rootkit 进化的分析揭示了这一事实，即攻击者在 x86 平台发现了新的、更加强大的执行环境。以下段落总结了不同类型的 rootkit，即用户模式、内核模式、基于虚拟机的、系统管理模式、基于固件的以及基于外设的。这段概述呈现了 rootkit 进化史，并且展示了近年来 rootkit 这一术语是如何变化的。

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

请注意，3 环和 0 环实现于硬件（宿主 CPU）中。术语“-1 环”、“-2 环”和“-3 环”被用于强调对应的执行环境的能力，它们并非实现于硬件中。

用户模式 rootkit 使用简单的技术，其基本理念是将 rootkit 伪装成正常的软件 [129]。例如，攻击者向某个运行于用户模式并且具有超级用户/root 权限的普通软件工具中添加所需的恶意功能。此修改过的工具替换了目标平台上的原始工具。用户模式 rootkit 被认为是 rootkit 进化的起点。其名称来源于赋予了超级用户 root 的权限级别。用户模式 rootkit 可以被运行于内核模式的特定检测工具发现。

内核模式 rootkit 基于某种高级技术以便利用操作系统内核组件来隐藏 rootkit [60]。内核模式 rootkit 修改了内核，或者更准确地说，修改了内核代码（例如系统调用）或者内核数据。对内核的修改改变了内核行为以强制实施某些隐形能力，进而隐藏恶意活动 [参见 129]，例如击键码记录器。执行于内核模式的 rootkit 不受那些用于揭示用户模式 rootkit 的技术的影响。

用于控制一台计算机系统的更加强大的 rootkit 称为 基于虚拟机的 rootkit（VMBR），诸如 SubVirt [77] 和 Blue Pill [108]。一种称为 hypervisor 或者 虚拟机监视器（VMM）的控制实例通常被用于在 虚拟机（VM）中托管客户操作系统。而 VMBR 通过利用 VMM 环境以便在虚拟机中托管目标计算机的操作系统。由于操作系统内核执行于 VMM 环境上，VMBR 可以被看作运行于“-1 环”上。因此，一个恶意控制实例被放置于硬件和操作系统之间。VMBR 难于安装，然而反过来说，VMBR 同样难于检测。Blue Pill 可以在计算机运行时托管目标操作系统，即无需关机或者重启。

用于 rootkit 的另一种强大的执行环境称为 系统管理模式（SMM）。SMM 是一种特殊的高权限处理器模式，它用于执行特殊的系统软件。它同样可以被利用以实现所谓的基于 SMM 的 rootkit。在 SMM 中执行的代码运行于宿主 CPU 的最高权限上。这意味着基于 SMM 的 rootkit 在运行时具有多于操作系统内核和虚拟机监视器的权限。因此，基于 SMM 的 rootkit 可以被看作执行于“-2 环” [145]。在 2008 年，Embleton 等人 [49] 和 Wecherowski [144] 展示了 SMM 可以如何被用于 rootkit。SMM 代码存储于固件中，即 SMM rootkit 可以被看作固件 rootkit 的特例。

基于固件的 rootkit 也是非常强大的。在固件中部署 rootkit 非常困难，但是并非不可能。固件是一种存储于闪存存储器上的特殊低级软件。基本输入/输出系统（BIOS）是存储于 x86 平台上的闪存存储器中的固件的一个范例。基于固件的 rootkit 并不是部署于硬盘上。因此，很难检测并且移除此恶意软件。攻击者可以利用此 rootkit 来攻击操作系统，即使用户重装操作系统。Heasman [56] 在 Black Hat Federal 2006 大会上展示了如何实现并且检测基于 BIOS 的 rootkit。Heasman [57] 延续了此项研究。由 Wojtczuk 和 Tereshkin [149]、Loukas K [84，85]，以及 Ortega 和 Sacco [97，98] 等人展示其他 BIOS 固件攻击可以作为 rootkit 的基础。Brossard [21，22] 还展示了 硬件后门是可行的。此作者利用了开源 BIOS coreboot [脚注 3] 及其相关工具以刷新 BIOS 以及外设的只读内存以攻击计算机平台。

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

隐藏于固件中的 rootkit 也可以被实现为使用平台外设的固件。这样的 rootkit 称为 基于外设的 rootkit。一种潜在地可被利用的外设是网卡 [134]。Heasman [55] 也讨论了如何实现并且检测一种部署于存在于 外设元件互连标准（PCI）设备上的扩展 只读内存（ROM）中的基于 PCI 的 rootkit。外设同实际的宿主系统之间被良好地隔离。因此，这种外设中的执行环境并未被反病毒软件所考虑。这使得外设对于攻击者而言极具吸引力，参见图 2.2。

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

隐藏于外设中的 rootkit 能够直接访问计算机平台的主内存。因此，它们可以偷取敏感数据，诸如硬盘加密密钥、视频电话通讯会话密钥、在线银行凭证、口令、打开的文件等。这样的 rootkit 也可能修改主内存中的数据。

一种能够在独立处理器上执行平台管理代码的特殊微控制器提供了良好的隐形能力，并且同样可以被用于 rootkit。在 Black Hat USA 2009 大会上，Tereshkin 和 Wojtczuk [131] 展示了将此类微控制器用于 rootkit 的理念。他们引入了术语“-3 环”以强调其隐形能力。这样的基于外设的 rootkit 被认为比基于 SMM 的 rootkit 更具隐秘性。Bulygin [25] 展示了如何利用这种特殊的基于微控制器的环境来检测基于 SMM 和基于 VMM 的 rootkit。由于诸如网卡等外设通过主内存同宿主操作系统进行通讯，基于外设的 rootkit 可以通过非法读取或者写入宿主内存来攻击宿主。这种允许外设进行内存访问的机制称为 直接内存访问（DMA，参见 2.4 节）。由于这种机制，基于外设的 rootkit 被认为是绝对隐秘并且不可能被检测到的。这样的 rootkit 技术是本工作关注的焦点。基于外设的 rootkit 可以通过 DMA 访问宿主内存以偷取存在于宿主运行时内存中的口令、在线银行凭证、打开的文件等。它们还可以通过诸如基于内核的后门等其他攻击代码来渗透宿主 [47]。

注意，我们在本工作中避免使用术语“-3 环”。并没有什么“-3 环”是实现于硬件中的。诸如“-1 环”、“-2 环”和“-3 环”等术语仅仅被用于描述 x86 平台上的对应环境的权限级别。所处的环越低，则 rootkit 的能力就越大。在本论文中，我们将会使用术语“恶意软件”，由于我们所分析的攻击并非执行于宿主 CPU 上。因此，root 权限与之无关。我们所关注的恶意软件同原始的用户空间 rootkit 相比只有这一点是共同的，即它们的目标都是隐秘运作。

2.2 典型的基于 x86 的系统架构

典型的 x86 系统架构的主要组件描述于图 2.3 中。中央处理器（CPU）、内存控制器集线器（MCH）和 输入/输出路径控制器（ICH）之间的连接称为芯片组 [54]。这种芯片组解决方案也称为 三芯片解决方案。系统内存（随机访问存储器，或者简称为 RAM）以及显示适配器被连接到 MCH。MCH 控制了对内存的访问。它可以阻止对内存地址的请求，或者将此请求重定向到 ICH，如果该目标地址属于 ICH。诸如闪存存储器、网卡（NIC）等通过 外设元件高速互连标准（PCIe [24]）整合到系统中。此标准为外设和芯片组之间实现了一种串行互连。网卡和其他扩展卡可以通过 PCIe 连接到 ICH。用于存储诸如 基本输入/输出系统（BIOS [参见 54，p.369]）等固件的闪存存储器也被连接到 ICH。

图 2.3 x86 芯片组和外设组件

芯片组组件包括 中央处理器（CPU 或者宿主处理器）、内存控制器集线器（MCH，又称为北桥）以及 输入/输出路径控制器（ICH，又称为南桥）。外设不属于主芯片组。

请注意，Intel 在 Intel 5 系列芯片组 [121，p.15] 中引入了一种所谓的 双芯片解决方案。这意味着 MCH 功能被整合进宿主 CPU，并且被称为 集成内存控制器（IMC [32，p.14]）。同之前的 MCH 一样，IMC 是控制内存访问的控制实例。ICH 被更名为 平台路径控制器（PCH [68]）。本论文中引导的实验基于三芯片解决方案。

其他控制器设备将其他格式通过 PCIe 连接到系统，诸如 通用串行总线（USB [8]）、火线（FW [6]）或者 串行高技术配置（SATA [7]）等。传统 PCI 设备通过一种所谓的 PCI 到 PCIe 桥接 连接到 PCIe 架构 [24]。在笔记本计算机中，个人计算机存储卡国际联盟（PCMCIA）/快速卡（ExpressCard）[139] 设备通过 PCIe 整合到系统中。宿主 CPU 不一定是系统中唯一的处理器。例如，显卡支持一种 图形处理器（GPU）以高效渲染计算机图形。待处理的数据存储于显存（VRAM）中，它独立于通常的系统内存。具有相似属性的其他设备包括网卡以及位于平台的 MCH 中的 Intel 管理引擎（ME [79]）。它们同样利用独立处理器和独立内存来执行固件。

2.3 基于 Intel x86 的宿主中央处理器

Intel x86 中央处理器（CPU）公布于 1978 年 [参见 59，附录 K.3]。此后，x86 CPU 持续被增强，直到最近，x86 处理器包含若干个单元以支持用于不同计算任务的适当特性。现代扩展包括浮点单元、单指令流多数据流（SIMD [117，p.524]）、流式 SIMD 扩展（SSE [117，p.748]）、x64 [58，p.351]、物理地址扩展（PAE [69，p.2-23]）、多级缓存（L1、L2、L3 缓存 [59，p.117]）、性能监视单元（PMU [参见 104，p.429]），以及虚拟化的硬件支持等，如 Grawrock 所描述 [54]。一块现代 x86 处理器通常也包括多个核心 [参见 59，p.117]，这些核心提供具有不同的位宽的寄存器，即从 16 位到 512 位 [参见 70，第 1.2.1 节]。

为了提供保护机制，CPU 通过所谓的保护模式支持一种权限模型。此模型提供的不同权限等级也称为环，以分隔运行于此硬件上的特定软件。如果处理器处于保护模式，则有 4 种环可用。0 环是权限最高的环，而 3 环的权限最少。操作系统执行于 0 环。因此它同运行于 3 环的应用程序相隔离。1 环被认为是用于设备驱动程序的，而 2 环被用于服务，尽管在实践上 1 环和 2 环并未被使用 [54，p.41]。

系统管理模式（SMM [69]）是另一种处理器模式，仅对于系统固件可用。此模式被引入 x86 架构以实现高级能效，例如通过关闭未使用的硬盘，以及控制系统硬件，例如当系统达到温度限制时打开系统风扇并且关闭系统。SMM 通过中断触发，即 系统管理中断（SMI）。SMI 处理程序代码在系统初始化的早期由 BIOS 从闪存存储器中加载至 系统管理内存（SMRAM）。为了防止由来自除了 SMM 以外的其他处理器模式的代码修改 SMI 处理程序代码，芯片组提供了一个特殊的位，它称为 D_LCK。此 D_LCK 位在 SMI 代码被加载至 SMRAM 之后被设置以对其进行保护。如果此 D_LCK 位被设置，则不可能更改 SMRAM 的内容。

如果某个 SMI 触发了 SMM，当前执行的程序被中断，并且处理器状态将会被保存。随后，处理器执行 SMI 处理程序代码。当此处理程序代码执行完毕时，被保存的处理器状态将被恢复。当处理器从 SMM 切换回之前的处理器模式时，被中断的程序可以继续运行。注意，之前的处理器模式损失了 CPU 周期/时间，由于两种处理器模式不能同时被执行。SMM 可以被看作一种独立的执行环境。SMRAM 是一块独立的地址空间，并且仅在处理器处于 SMM 时可访问。换言之，操作系统不能访问 SMRAM。更进一步地，SMM 中的权限不受限制，执行于 SMM 中的代码可以调用任何 I/O 以及系统指令。

在 Intel 平台上，x86 中的硬件虚拟化扩展称为 Intel 虚拟化技术（Intel VT）[54]。虚拟化机制被用于在单一的硬件平台上并行运行彼此隔离的多个操作系统或者应用程序。一种称为 虚拟机监视器（VMM）的控制实例用于托管 虚拟机（VM）中的客户操作系统。现代 x86 CPU 提供了一种特殊的指令集，称为 VT-x。VT-x 是 Intel VT 的一部分，并且其本意是用于支持硬件虚拟化。此种硬件支持提供了两种特殊的 CPU 操作：VMX root 操作和 VMX 非 root 操作。VMM 运行于 VMX root 操作模式。运行于 VMM 之上的 VM 处于由 VMM 控制的 VMX 非 root 模式。这两种操作模式都支持其各自的保护环，各 4 个。因此，客户系统的软件（内核、驱动程序、应用程序等）可以运行于其被指认的权限级别。VMX 非 root 操作模式中的保护环被认为是低权限的，由于这些环受到运行于 VMX root 操作模式的 VMM 的控制。而 VMX root 操作模式的 4 个环是高权限的。通常，VMM 只会使用最高权限的环。此环通常称为“-1 环”以强调它控制着较低权限的 0-3 环这一事实。

x86 微架构还实施了这样一种流水线概念，它具有诸如分支预测和乱序执行等特别执行优化特性 [118，p.329ff] [127，p93ff]。执行流水线利用微操作进行工作，即运算被作为程式化原子单元而实现。Intel 架构指令被翻译为微操作 [118，p.331]。对于乱序执行，需要一块所谓的 重排序缓冲区（ROB [118，p.333]）来跟踪重命名的寄存器。寄存器重命名发生于乱序执行过程中。微运算中所使用的寄存器通过 寄存器别名表（RAT [118，p.333]）而被重命名，它也被称为 寄存器分配表（RAT [参见 127，p.100]）。

PMU 以 型号特定寄存器（MSR [69，第 9.4 节]）的形式实现，它允许软件开发者对微架构相关的事件进行计数。这有助于程序员编写针对某一 CPU 微架构优化的代码 [104]。例如，MSR 可以被配置为计数在代码执行时发生的缓存未命中、RAT 停止，以及分支预测错误等 [69，第 18/19 章]。用于事件计数的 PMU 寄存器也称为 性能计数器 或者 硬件性能计数器（HPC）。它们仅在 0 环中可用。与性能测定相关的另一种特殊目的寄存器是所谓的 时间戳计数器（TSC [69，第 17.12 节]）寄存器。TSC 寄存器可以在平台重置之后被用于计数 CPU 周期。由不同的权限级别对时间戳计数器寄存器和性能监视单元寄存器的访问可以由 x86 控制寄存器 4（CR4）[参见 69，第 2 章] 来控制。

一种同外设交换数据的特殊输入/输出（I/O）特性是经过由 x86 CPU 提供端口（I/O 端口 [117，p.70，341]）的 I/O 映射 I/O 的概念。此概念与内存映射 I/O（同样由 x86 系统提供 [117，p.343]）互补，在后者的情况下，外设的内存和寄存器都被映射到宿主 CPU 的内存地址空间。外设同样会通过中断与宿主 CPU 通讯，以发出例如新数据可用的信号 [117，p.252]。为了同宿主系统进行通讯，外设也可利用直接内存访问的概念。在此情况下，外设并不直接同宿主 CPU 通讯，参见 2.4 节。

2.4 直接内存访问

PCIe 支持用于外设，或者更准确地说，诸如显卡、网卡以及管理控制器等专用硬件的 直接内存访问（DMA）。DMA 允许快速内存访问而无需宿主 CPU 的介入。DMA 的目的在于从宿主 CPU 移除负载。DMA 允许外设绕过 CPU 获得对全部宿主内存的访问。CPU 可以在 DMA 传输发生时执行其他任务。外设可以拥有它们自己的引擎以执行 DMA。此类 DMA 称为第一方 DMA [133，p.428]。另一种机制称为第三方 DMA [133，p.428]，在此，需要由一个中央 DMA 控制器（DMAC，参见图 2.3）来为不带 DMA 引擎的传统设备（例如基于 工业标准结构（ISA [116]）格式的设备）提供快速内存访问。它也被集成到现代平台中 [64，p.128]。

图 2.4 第三方和第一方 DMA

(a) 第三方 DMA：要求宿主 CPU (1) 通过 I/O 端口配置（源和目标地址）中央 DMA 控制器，以便 (2) 执行 DMA 传输。宿主 CPU 将会被 (3) 中断，如果 DMA 传输完成 [31，p.454]。因此，宿主 CPU 对于第三方 DMA 传输警觉。(b) 第一方 DMA：外设设备可以 (1) 配置其自身的 DMA 引擎。此设备作为总线主控（参见第 2.5 节）以获得对于系统总线的控制来执行 DMA 传输。此设备可以中断宿主 CPU，如果该设备 (2) 完成传输。传输同样能够进行，如果此设备并不在 DMA 传输完成时中断宿主 CPU。在此情况下，CPU 对于 DMA 传输并不警觉。

图 2.4 高亮显示了第三方和第一方 DMA 之间与隐秘操作有关的一个重要区别。如果使用第三方 DMA，宿主 CPU 对于 DMA 传输警觉，由于外设需要宿主 CPU 通过 I/O 端口 [脚注 4]（参见 2.3 节）来配置 [参见 31，p.454] DMAC。如果使用第一方 DMA，宿主 CPU 不一定 对此传输警觉。注意，DMAC 或者 DMA 引擎只能访问宿主内存地址，而非诸如宿主 CPU 缓存、宿主 CPU 寄存器或者硬盘等。后一条规则提示从运行时内存中移出至硬盘中的数据对于 DMA 引擎来说也不可访问。

脚注 4：参见诸如 arch/x86/include/asm/dma.h 和 arch/x86/include/asm/io.h 等 Linux 源代码。

2.5 总线主控

计算机平台拥有若干种总线系统，例如 PCIe 和 前端总线（FSB）。因此，平台拥有取决于总线系统的不同的总线主控类型，参见图 2.5。总线主控是一种能够经过某种总线引发数据传输（例如从 I/O 设备到主内存）的设备 [58，第 7.3 节]。某个连接到总线的设备（CPU、I/O 控制器等）本质上并不是总线主控。此设备只是一个 总线代理 [1，p.13]。如果该总线必须被仲裁，则总线主控可以向仲裁器发送一段总线所有权请求 [9，第 5 章]。如果仲裁器将总线所有权授予该总线主控，则该总线主控可以引发数据传输，只要总线所有权被持续授予。注意，此过程与 PCIe 设备不相关，由于其点对点的属性。PCIe 请求不需要被仲裁，因此，总线所有权并非必需。此总线并未如同其在 PCIe 的前身 PCI 中那样被共享。

图 2.5 总线主控拓扑结构

总线主控通过不同的总线系统（例如 PCIe，FSB）访问内存。MCH 为不同的总线控制器仲裁主内存访问请求（基于 [23，p.504] [24] [58，第 7.3 节] [63，第 1.3 节] [64]）。

然而，PCIe 设备的总线主控能力是通过某个特定的位来控制的，它称为 总线主控启用（BME）。BME 位是该外设的标准配置寄存器的一部分，并且通常由执行于宿主 CPU 上的对应设备驱动程序来设置。MCH（位于 PCIe 的视野之外）仍然对从不同的总线接口到主内存的请求进行仲裁 [63，p.27]，参见图 2.5。宿主 CPU 也是一个总线主控，它通过 前端总线（FSB）从主内存中获取数据和指令。I/O 控制器（例如以太网、硬盘控制器等）为 I/O 设备（例如 USB 键盘/鼠标、硬盘、网卡等）提供独立的 DMA 引擎。这意味着如果外设对主内存的访问请求由 MCH 处理，则 PCIe 与之完全不相关。

2.6 输入/输出内存管理单元

Intel 引入了一种称为 用于直接 I/O 的 Intel 虚拟化技术（VT-d [2]）的技术作为若干构建块之一，以便为 x86 系统提供硬件支持的虚拟化。VT-d 可以被看作一种 输入/输出内存管理单元（I/OMMU）以便有效地辅助虚拟化要求，诸如对运行于同一虚拟机监视器上的不同虚拟机进行可靠的隔离。VT-d 的应用主要与虚拟化相关联。有了 VT-d，虚拟机监视器或者操作系统等可以创建内存保护域。例如，互相隔离的物理内存子集可以被指认给虚拟机或者 I/O 设备驱动程序的内存。未被指认一块保护域的 I/O 设备没有对该域的物理内存的访问权限。这些访问限制通过地址翻译器而实现。系统软件对由 Intel VT-d 提供的所谓 DMA 重映射（DMAR）引擎进行配置。这样的引擎将例如由 I/O 设备触发的内存请求映射到物理内存。VT-d 可以阻止内存请求，如果该设备未被指认保护域。请注意，激活的 I/OMMU 可以为宿主 CPU 引入显著的性能开销 [13] [150] [88，p.129]，其结果是此技术的使用经常被避免。

为了允许系统软件配置 DMAR 引擎，BIOS 需要将对应信息以 高级配置与电源接口（ACPI [44]）表的形式加载至主内存。系统软件可以利用这些信息（例如 DMAR 引擎数量）来设置保护域。请注意，在主内存中存储 ACPI 表这一做法带来了严重的安全威胁。这些表可以通过直接内存访问来访问，并且可以如同 Wojtczuk 等人 [148] 和 Sang 等人 [111] 所描述的那样被修改。负责正确配置 DMAR 引擎的系统软件可能会失效，如果此漏洞被攻击者所利用。

2.7 信任和对手/攻击模型

此攻击者模型提供了关于一种隐秘 DMA 攻击场景的描述。攻击者能够 远程地 利用恶意负载来渗透存在于计算机平台中的专用硬件。这可以通过利用与操作系统或者固件相关联的零日漏洞 [例如参见 47] 来实施。我们假设攻击者能够在运行时对目标平台进行攻击。这不仅可以通过远程利用固件漏洞来实现，也可以通过分别由 Duflot [45] 和 Triulzi [135] 所描述的远程固件更新机制来实现。除了上述远程利用以外，攻击者还能够在本应作为拥有者的实体获取并且在目标平台上部署外设之前渗透该外设。

此专用硬件支持如 2.4 节所述的第一方 DMA 并且通过内存总线访问主内存，如图 2.5 所示。我们假设目标计算机平台拥有通常的最新防御机制，诸如反病毒软件和宿主防火墙。此平台的用户并未应用诸如硬件防火墙等额外的硬件以保护此计算机平台。我们假设只有隐秘攻击可以算作成功的攻击。因此，攻击者想要利用专用硬件的隐形潜力以隐藏攻击。对于主内存的攻击（例如对于机密性和完整性的侵犯）只来自于外设并且是通过 DMA。攻击者并未实施这样一种要求外设和宿主之间进行协作以提高隐秘攻击成功率的攻击。我们进一步假设攻击者能够保证对完整性的侵犯（内存写访问）不会导致攻击的暴露。额外的硬件将会显著降低隐秘攻击的成功率。例如，最有可能的情况是攻击者致力于偷取数据以引导行业间谍活动或者获取在线银行凭证等。为了实现这一点，攻击者必须通过 DMA 从主内存中读取数据（对机密性的侵犯）或者向主内存中写入数据（对完整性的侵犯）。

我们将某个计算机平台视为可信的，如果它满足所应用的安全策略。这意味着在我们的案例中，没有基于 DMA 的恶意软件通过 DMA 读取或者写入平台的主内存来攻击宿主平台。我们依赖于一种最小化的 可信计算基（TCB [37，p.66] [99，p.8]），它包括宿主 CPU 和内存芯片硬件，以及它们之间的通讯路径（前端总线、内存控制器集线器、内存总线）。执行于宿主 CPU 上的软件（系统软件和应用软件）在平台被攻击之前处于可信状态。这意味着软件被正确地加载和启动，并且行为符合预期。我们并不依赖诸如 I/OMMU 等预防性措施，由于 2.6 节所述的安全性问题。

第 3 章相关工作

黑客的思维模式并不能真正看到另一面，即对受害者发生了什么。——Kevin David Mitnick，安全专家

由于我们在方法论中决定同时思考两方面，即攻击以及对攻击的检测和化解，我们必须详细论述两个方面的相关工作。更进一步地，我们想要使得我们的目标平台能够将其关于基于 DMA 恶意软件的状态报告至外部平台。为了实现这一点，我们要求一种能够揭示由网卡发动的 中间人（MitM）攻击的通讯信道。这是必要的，由于我们同样将网卡视为能够隐藏攻击代码的专用硬件。

3.1 DMA 攻击

直接内存访问可以成为一种足够有效的方式以引导对于宿主系统的隐秘攻击。我们的工作分析了那些能够在运行时实现恶意软件功能并且应用 rootkit/隐形能力的攻击。在最坏的情况下，基于 DMA 的恶意软件还能够在平台重启以后，以及在待机和关机模式下存活。在下文中，我们将会区分这两类外设之间的区别，即可以从机箱外部连接到宿主平台的外设以及直接连接到芯片组的外设。

3.1.1 可以从外部连接的设备

自 2004 年始，利用诸如 USB 设备 [90]、特殊的 PCMCIA 卡 [61，11] 以及火线设备 [43，42，17] 等额外硬件进行的若干种 DMA 攻击就已经出现。由 Maynor [90，p.55ff] 所描述的此类攻击使用了一部摩托罗拉移动电话，以通过 USB 利用攻击代码渗透目标设备。此攻击通过在目标平台的屏幕上显示一个窗口来暴露自己。因此，此攻击与其说是完全可运作的恶意软件，不如说是一个概念验证。

Dornseit [43] 和 Dornseif 等人 [42] 展示了如何利用一部通过火线连接到目标的苹果 iPod 以引导一次 DMA 攻击。作者提到，他们可以利用 DMA 读取来复制屏幕内容、字符串和关键素材。更进一步地，通过 DMA 写入，作者可以更改屏幕内容、引导一次权限提升攻击，并且向宿主的运行时内存注入代码。Boileau [17] 同样覆盖了一种基于火线的 DMA 攻击。作者能够攻击一台基于 Windows XP 的笔记本计算机。在 2007 年，Piegdon 和 Pimenidis [101] 发表了另一篇关于与火线相关的 DMA 攻击的论文。他们描述了如何偷取 SSH 私钥以及注入任意代码。此注入的代码实现了同目标设备之间具有管理员权限的互动访问。作者必须搜索被宿主 CPU 用于实现虚拟地址空间的数据结构以查找运行于宿主 CPU 上的进程。Blass 和 Robertson [15] 描述了 Tresor-Hunt，这是另一种基于火线的攻击以欺骗硬盘加密机制。更准确地说，绑定到宿主 CPU 的加密机制受到了攻击。CPU 绑定意味着密钥数据从未被释放到主内存。该数据一直保存在宿主 CPU 的寄存器中。Tresor-Hunt 的基本理念是向内核空间注入代码（某个中断处理程序被挂钩）。该攻击代码将密钥数据从处理器寄存器转储到内存，在这里，它可以通过 DMA 捕获。Blass 和 Robertson [15] 利用火线来转储宿主的物理内存。然后，他们扫描整段转储的内存以查找中断描述符表，进而挂钩某个中断处理程序，它最终将会释放加密密钥。

David Hulton [61] 展示了如何利用通过 cardbus 连接到目标平台的 现场可编程逻辑门阵列（FPGA）外设来捕获存在于主内存中的口令和私钥。更进一步地，Hulton 的 FPGA 设备能够解锁屏幕保护程序并且执行任意代码。为了在宿主内存中查找目标内存地址，作者对所有物理内存页进行了签名扫描。

由 Breuk 和 Spruyt [18，19] 记载的项目致力于将 DMA 攻击整合到漏洞利用框架。作者讨论了 PCI、火线、USB、SATA、DisplayPort、雷电和 PC 卡（即 PCMCIA、cardbus、快速卡）。他们的概念验证基于火线。为了在宿主的运行时内存中查找目标地址，作者实施了针对全部内存页的签名扫描。Inception 工具能够通过“火线、雷电、快速卡、PC 卡，以及任何其他 PCI/PCIe 接口”攻击目标平台 [87]。此工具能够做的事情包括转储主内存、解锁系统，并且引导针对基于 Windows、Mac OS 以及 Linux 的目标的权限提升攻击。描述了利用雷电进行 DMA 攻击的策略的后续研究由 Sevinsky [114] 所贡献。作者并未描述通过雷电进行的具体的 DMA 攻击。

3.1.2 牢固建立在平台机箱内部的设备

在本工作中，我们明确地专注于隐秘性。攻击者必须不依赖对目标设备的物理访问以增加隐秘渗透的成功率。因此，3.1.1 节所呈现的攻击设备并不被考虑在我们的信任和对手模型中，参见第 2.7 节。我们专注于源自平台外设的攻击。本节考虑了源自诸如特殊的管理控制器、网卡和显卡等平台外设的 DMA 攻击。

Tereshkin 和 Wojtczuk [131] 说明了 Intel ME 的 DMA 引擎可以被用于写入宿主内存。作者描述了一种允许向 DMA 环境注入代码的漏洞。Tereshkin 和 Wojtczuk 的代码并未实现任何恶意软件行为。它通过向一段已知的硬编码的宿主内存地址进行写入从而暴露自身。因此，这种方法实现了一种概念验证而非真实的恶意软件功能。我们利用 Intel ME 用于我们自己的攻击研究，参见第 4 章。我们的基于 DMA 的攻击以击键码记录器的形式实现了完全可运作的恶意软件，它执行于管理引擎的环境中。

Duflot 等人 [47] 和 Delugré [35，36] 所描述的基于网卡的攻击专注于隐秘攻击、恶意软件功能和 rootkit 能力。由 Duflot 等人 [47] 所呈现的攻击在运行时利用了网卡固件的漏洞。被攻击的网卡被用于通过添加后门的方式来攻击宿主系统。作者描述了宿主可以如何访问网卡的内部内存。这提供了一种可能性以便利用执行于宿主 CPU 的代码来检测攻击代码。据我们所知，没有任何反病毒软件之类能够利用这一点。应该指出，宿主能够访问网卡的内部内存并不是一种常见特性。例如，我们所用于自己的攻击研究（参见第 4 章）的 Intel ME 的运行时内存是宿主不可访问的。由 Delugré [35，36] 发表的工作与 Duflot 等人 [47] 发表的工作非常相似，两起攻击都使用相同的网卡型号。由 Delugré [35，36] 实现的恶意软件致力于实现 rootkit 能力。

Arrigo Triulzi [134，135] 呈现了一种隐秘的安全 shell。它可以通过 DMA 提供内存检测功能。网卡和显卡的组合被用于隐藏此 shell。此 shell 通过远程重刷固件而被安装。网卡和显卡通过 PCI 到 PCI 传输进行通讯。作者提议 PCI 到 PCI 传输计数作为反制措施，但是并未描述如何实现。与显卡相关的其他工作由 Vasiliadis [140] 发表。作者描述了一种方法将性能开销从宿主 CPU 转移到显卡的 GPU 上。部分代码仍然需要运行在宿主 CPU 上。CPU 和 GPU 通过共享内存进行通讯。此性能开销将会在诸如解包或者运行时多态等技术被应用时出现。因此，Vasiliadis [140] 同时描述了 GPU 辅助解包和运行时多态，但是并未描述任何利用 DMA 攻击宿主系统的特定恶意软件。Ladakis 等人 [80] 实现了一种运行于 GPU 上的击键码记录器。此击键码记录器类似于我们所发布的击键码记录器 [123] [脚注 5]。他们重用了相同的签名扫描以查找键盘缓冲区。更进一步地，此方法要求在宿主 CPU 上以内核模式执行签名扫描。这一致命弱点可以被用于检测此攻击。作者事实上需要一个基于内核的零日漏洞来增加隐秘攻击的成功率。根据作者所述，特殊的调试工具可以被用于分析执行于 GPU 上的进程。这些工具可以被用于开发一种针对基于 GPU 的恶意软件的反制措施。在显卡环境中被捕获的击键码随后发生了什么并不清楚。Ladakis 等人 [80] 并未考虑潜出。

脚注 5：我们所发表的击键码记录器 [123] 是我们在第 4 章所研究的攻击的基础。

最近，Domburg [41] 展示了如何在硬盘控制器上安装攻击代码。攻击代码存储于硬盘控制器的内存存储器上，并且被加载到硬盘控制器的动态内存中，以便在硬盘控制器的处理器中执行。作者并未描述如何利用硬盘控制器的 DMA 引擎攻击宿主运行时内存。由 Zaddach 等人 [152] 呈现的类似工作同样基于硬盘控制器。作者展示了一种隐秘的硬盘后门。然而，他们所攻击的是硬盘上存储的数据，即他们并未展示如何利用该控制器的 DMA 引擎攻击宿主系统的主内存。因此，他们的攻击不属于本论文的范畴。我们专注于针对平台的主内存的隐秘攻击。

3.2 反制措施

不同的方法被提议出来，它们可以看作针对 DMA 攻击的反制措施。例如，测定固件 [脚注 6] 是一种用于检查固件二进制文件的完整性的方法。它假设固件并不会引导 DMA 攻击，如果其二进制文件未被修改。签名固件的方法同样致力于使用户相信该固件不会引导 DMA 攻击。其理念是经过厂商数字签名的固件是可信的。除了这两种方式以外，后续各节还描述了相关工作，诸如基于延时的证言、运行时监视、总线嗅探、敏感数据保护以及 I/OMMU 等。

脚注 6：在此案例中，测定是指导出散列值。

3.2.1 测定固件

可信计算小组（TCG）[136] 提议在加载时证明外设固件。更准确地说，此方法基于一块额外的芯片 [脚注 7]，它称为 可信平台模块（TPM [99]）。TPM 类似于一块牢固地固定在计算机平台的芯片组的智能卡芯片。然而，TPM 可以在二进制代码被执行之前以该代码的散列值的形式存储完整性测定信息。这意味着测定是在加载时进行的。此类测定可以被用于检查平台是否可信。当前版本的 Intel 管理引擎执行环境也采用一种所谓的验证启动机制以允许使用散列值对外设固件进行证明 [79，第 15 章]。然而，在加载阶段引导的测定并不能排除运行时攻击。在运行时重复进行测定将会造成显著的性能下降。它同样不能阻止 瞬时攻击，在此，攻击者利用两次测定之间的时间框架。更进一步地，并不能保证宿主 CPU 能够访问用于存储固件代码的所有外设 ROM 组件。

脚注 7：TCG 规范并不禁止以固件形式实现 TPM。Intel [参见 79，p.108] 拥有一种基于固件的 TPM 解决方案。

3.2.2 签名固件

经过签名的固件镜像同样不能阻止运行时攻击。固件更新只能被刷入对应的 ROM 芯片，如果该固件镜像拥有有效的数字签名。例如，只有经过主板厂商数字签名的 BIOS 固件镜像可以被刷入对应的 ROM 芯片 [79，第 14 章]。这并不能排除运行时攻击。此类攻击已经被 Wojtczuk 和 Tereshkin [149] 以及 Butterworth 等人 [26] 所展示。

3.2.3 软件/基于延时的证言

其他证言方式由诸如 Li 等人 [83，82] 所呈现。这些方式基于 基于延时的证言，即外设不仅需要计算出一段正确的校验和，它还必须在限定的时间内计算出该值。被攻击的外设将会被认为已经暴露，如果校验和错误或者计算该校验和耗时过长。基于延时的证言要求修改外设固件，并且宿主需要知道该外设的准确硬件配置以便能够对其进行验证。Li 等人 [83] 同时说明他们的方法不能正确地工作，如果外设会造成大量总线流量。他们在其评估中仅仅考虑了一部外设。更进一步地，Nguyen [96] 揭示了 Li 等人 [83] 的证言方法中存在的严重问题。同样不清楚的是，基于延时的证言能够在多大程度上阻止瞬时攻击。

3.2.4 监视方法

另一种有趣的方法由 Duflot 等人 [46] 所呈现。网卡特定的调试特性被用于监视固件执行。这些特性对于其他外设并不可用。另一个缺陷是对宿主造成的显著性能问题（某一个 CPU 核心 100% 使用）。我们的目标同样是开发一种运行时监视器。与 Duflot 等人 [46] 所描述的监视器相反，我们的监视器要求 (i) 独立于外设的内部工作方式，以及 (ii) 造成的性能开销显著减少，参见第 5 章。

另一种运行时监视方式由 Zhang 等人 [153] 所呈现。此方式类似于 SMM。作者提议周期性地检查外设固件和配置。然而，作者并未描述在 I/OMMU 被正确配置之前，存储着监视器的 SMRAM 是如何被保护起来使其不受 DMA 攻击的。作者同样并未解释检查间隔。因此，必须假设瞬时攻击并未被考虑。同样不清楚的是，检查全部外设到底需要多少时间。实现描述和评估都没有。因此，该提议的方法在实践中切实可行这一点并未被证明。

3.2.5 总线嗅探方法

Moon [92] 和 Lee [81] 遵循另一种基于硬件的方法。作者提议了这样一种系统，它能够嗅探内存总线以检查对于内核完整性的侵犯。此方法能够阻止瞬时攻击。然而，作者并不致力于检测 DMA 攻击。更进一步地，他们的嗅探监视器组件基于特定硬件（Leon3 处理器）。它和被监视的宿主系统（同样基于 Leon3 处理器）拥有相同的计算能力。探究这样一种内存嗅探方法是否能够被利用以检测基于 DMA 的恶意软件将会十分有趣。

由 Eckert 等人 [48] 呈现的一种相关方法考虑了一种 DMA 攻击。提议的系统可以被用于检测经过 DMA 传输至宿主内存的恶意软件。因此，作者只考虑了从外设到宿主内存的写入操作。此系统无法阻止基于 DMA 读取的攻击，在此，攻击者捕获了存在于主内存中的诸如密码学密钥或者在线银行凭证等信息。在其描述的攻击场景中，作者假设攻击代码执行于宿主处理器上。因此，他们同样通过总线嗅探来扫描通过 DMA 写入宿主内存的数据以查找恶意软件签名。作者承认其基于签名的检测方式存在缺陷。此提议的系统要求基于 FPGA 的硬件，并且同样不清楚的是，他们的实现专注于第一方还是第三方 DMA。

3.2.6 敏感数据保护

已有若干种方法被呈现，用以保护诸如密码学密钥等敏感数据等，以防止内存攻击。有人提议仅在处理器寄存器或者缓存中存储敏感数据，而非在主内存中 [93，94，119，141]。然而，Blass 和 Robertson [15] 展示了如何利用基于 DMA 的攻击以强制宿主将敏感数据泄漏到主内存中，参见 3.1.1 节。

3.2.7 输入/输出内存管理单元

如同 Duflot 等人 [47] 以及 Müller 等人 [95] 所提议的那样，存储于主内存中的敏感数据也可以通过 I/OMMU 进行保护。如同我们已经在我们的信任和对手模型中所考虑到的那样，我们并不会依赖 I/OMMU（参见 2.7 节）。这是由于 I/OMMU 必须被配置无误 [83，p.2]，以及 I/OMMU 可以被成功地攻击 [111，148，147，146]。更进一步地，I/OMMU 将会由于内存访问策略冲突而不适用 [123]，并且它们并不被每一种芯片组和操作系统所支持。Sang 等人 [112] 同样确认了 I/OMMU 具有缺陷。在将 I/OMMU 看作一种反制措施时另一个应当被考虑的问题在于，根据 Ben-Yehuda 等人 [13] 和 Yassour 等人 [150] 的研究结果，激活的 I/OMMU 可能造成显著的性能开销。

3.3 在考虑平台状态报告的前提下加固通讯信道

本章所呈现的相关工作均未考虑作为托管恶意软件的网卡可以引导 中间人（MitM）攻击的情况。我们将 可信信道 这一概念用于此目的 [52，10]。可信信道拥有安全信道的全部属性。此外，可信信道的概念允许将通讯端点的配置数据绑定到安全信道，以保证该端点的合法性（同一性和完整性）。然而，还存在与可信信道相关联的其他方法，它们将会在下文讨论。为了防止 中继攻击（攻击者中继了某个第三方平台的可信配置数据），要求在安全信道和将要被报告至该端的配置数据之间实现一种安全绑定。并非所有下文所呈现的相关工作都实现了这样一种安全绑定。

3.3.1 基于可信平台模块的方法

存在着众多由 可信计算小组（TCG）[脚注 8] 所提议的基于 可信计算（TC [99]）的方法。众多方法加强了现存的安全信道协议，诸如 传输层安全（TLS [38]）或者 互联网安全协议（IPSec [76]）将端点配置数据绑定到安全信道 [120]。我们同样倾向于从已有的安全信道协议中得到好处。

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

Smith [120] 描述了如何将平台认证和用户认证结合起来以认证一个端点。为了做到这一点，他们引入了两步握手的 TLS 扩展。然而，Smith 的描述不够详细。中继攻击和端点配置更改不在此工作的范围内。Sadeghi 等人 [110] 也引入了一种可信信道的概念。他们的概念基于密钥传输。我们倾向于使用分担式密钥协商协议。我们将密钥素材视为对相关端点的贡献。更进一步地，由 Sadeghi 等人 [110] 描述的参考实现使用 TLS 以隧穿他们的信道。配置数据并未同基于 TLS 的安全信道绑定。

TCG 开发了 可信网络连接（TNC）架构 [138]。TNC 主要应对网络访问。网络认证和策略强制实施是 TNC 关注的焦点。这并非我们关注的焦点。基于完整性的配置信息被用于判定某个平台是否被允许接入网络。TNC 致力于这样一种规范，它基于证言目的对 TLS 进行扩展（用于证明的 TLS 扩展，或者简称为 TLS 证明 [130，p.51]）。此文档并不使用 TCG 网站 [脚注 9] 公开。然而，TCG [137] 发布了一篇称为“绑定到 TLS”的文档，此文档考虑了当客户端请求网络访问时的中间人攻击。基于 TNC 的另一种方法由 Rehbock [103] 所讨论。作者将 TNC 架构扩展到基于网页的环境。

脚注 9：参见脚注 8。

Marchesini 等人 [89] 的目的是对网页应用程序的可信度进行证言。他们基于所提议的 Bear 平台 引入了一种架构。此平台实现了这样一种信任模型，它致力于将长寿命密码学密钥对（由认证权威机构所认证）映射到短寿命平台配置部分。作者承认他们的平台存在诸如 检查与使用之时差（TOCTOU，同时参见 3.2 节）等问题。

由 Goldman 等人 [53] 描述的方法同样致力于将配置数据连接到安全信道的端点。作者利用 TLS 的前身，即 安全套接字层（SSL [50]）协议进行工作。其基本理念是在由可执行代码得出的完整性测定列表之上附加 SSL 证书的测定结果。作者并未说明他们如何准确地防止中间人攻击。SSL 证书可能来自其他平台，或者在我们的攻击场景中，来自于通过 DMA 进行证书偷运的网卡。更进一步地，此网卡可以在运行时攻击端点以攻击数据和密码学密钥。McCune 等人 [91] 利用一种同 Goldman 等人 [53] 类似的协议。作者利用诸如 Intel 可信执行技术（TXT [参见 54]）等现代芯片组特性以显著减小 TCB。在他们的对手模型中，作者确实明确地允许 DMA 攻击。其原因是他们提议了一种能够得益于隔离执行环境的安全架构。当代码在该环境中执行时，中断和 DMA 被关闭。更进一步地，每当使用此隔离环境时，宿主处理器的状态就被要求保存和恢复。其结果是性能的损失。因此，此方法仅适用于快速安全操作。保护通过 USB 键盘输入的用户输入是完全不可能的，由于需要 DMA 将击键码从键盘复制到主内存。

Dietrich [39，40] 也提议了一种基于 TPM 以及 TLS 的可信信道概念。他致力于在同远程平台的会话过程中报告平台配置更改。他的方法要求对 TPM 的修改。这样的硬件修改在实践中是否能够强制实施尚不清楚。Cheng 等人 [29] 同样致力于通过将基于 TCG 的平台配置报告方法同 TLS 信道相结合以防止中间人攻击。然而，作者并未呈现一种实现。他们同样未能清楚地描述他们将哪种 TLS 握手信息用于所提议的信道的协商。由 Yu 等人 [151] 所描述的方法同样将基于 TPM 的平台配置数据同 TLS 协议相结合。作者强烈地专注于 TLS 重新协商攻击 [参见 102]。他们宣称此种攻击即使在使用安全信道的情况下也是可能的。我们怀疑这一点，由于 Yu 等人 [151，p.3] 所描述的攻击协议流展示了这一点，即中间人需要将合法的平台配置数据上传至服务器。因此，服务器能够检测到负责引导重新协商攻击的代码。作者并未解释中间人想要伪造可信的平台配置数据是否可能。

一种与隐私相关的十分有趣的可信信道方法由 Cesena 等人 [27] 呈现。所提议的信道结合了 TLS 和 直接匿名证言（DAA [20]）协议，后者被 TCG 所采用。在此上下文环境中，DAA 允许平台证明它包含一块 TPM，而无需暴露它是何种特定的 TPM。这有助于保护隐私，如果要求避免将不同的会话同某一特定平台的 TPM 连接起来。除了 DAA 以外，所提议的信道同我们的可信信道非常相似。作者以类似于我们的解决方案的方式利用 TLS 握手信息。

Sadeghi 和 Schulz [109] 改良了安全信道协议 IPSec 以实现这样一种可信信道。该方法利用 互联网密钥交换协议版本 2（IKEv2 [75]）作为基础以便将平台配置信息绑定到此信道。配置数据也可以在 IPSec 会话期间被传输。作者还考虑了他们的方法可以如何被整合到 TNC 架构中。尽管所呈现的方法是向后兼容的，只需对 IKEv2 进行最小化的修改即可使其完全得益于可信信道。

平台配置信息也可以被包含在 Diffie-Hellman（DH）密钥交换过程中，如 Stumpf [128] 所述。作者依赖于这样一条命令（TPM_Quote），它负责获取一份关于存储于 TPM 之中的完整性测定数据的签名报告。DH 方法并不能化解由加载时测定造成的缺陷。

Lyle 和 Martin [86] 引入了一种考虑了网页服务技术的信道。他们的特殊环境并不允许应用一种基于 TLS 的信道。他们将 TCG 平台配置报告方法同所谓的消息级加密 [参见 86，p.4] 相结合。Chang 等人 [28] 将 TCG 方法同 安全实时传输协议（SRTP [12]）/ Z 实时传输协议（ZRTP [154]）相结合。SRTP/ZRTP 为 网际协议通话技术（VoIP [34]）传输提供了安全信道。作者致力于提供一种结合了 TCG 方法和 SRTP/ZRTP 的可信信道。

然而，所有这些提议的基于 TPM 的方法均未充分考虑运行时攻击（特别是基于 DMA 的运行时攻击）。它们同样受制于 3.2 节开头描述的缺陷。请注意，我们关于可信信道的工作最初同样基于 TPM。在本工作中，我们采用了另一种攻击场景的可信信道概念，在此，攻击来自于外设。我们的信任模型（参见 2.7 节）考虑了另一套不同的 TCB。我们并不依赖于加载时完整性测定。TPM 并非必需。我们的测定基于一种运行时监视器，它能够根据内存总线传输推导出状态信息，参见第 5 章。我们在本工作中所使用的安全通讯信道考虑到了这些测定。此信道基于我们在前期工作 [52，10] 中所引入的可信信道概念。

3.3.2 基于协处理器和智能卡的方法

由 Jiang 等人 [74] 和 Chess 等人 [30] 描述的方法基于一块安全协处理器。协处理器被用于通过实现一种称为可信协服务器的概念来建立信任。协服务器执行经过评估和认证的程序以便将主服务器认证为能够监视它们的行为的。协服务器在对抗物理操作方面更加安全。然而，它们相对于现货供应的硬件更加昂贵。这样的协服务器通常被实现为具有专用的处理器、内存、DMA 引擎以及以太网连接器 [72，73] 的 PCI(e) 板卡的形式。因此，它们是基于 DMA 的恶意软件的理想宿主。

由 Akram 等人 [5] 提议的可信信道协议本意是用于一种特殊的智能卡场景。作者专注于一种针对智能卡用户的隐私保护协议。因此，他们的方法仅适用于涉及智能卡的场景，在此，用户的身份必须不被暴露。在 Akram 等人 [4] 的一篇早期发表中，作者呈现了另一种信道，其本意是用于运行时认证和智能卡应用程序的验证。此信道是作者所实现的框架的一部分。此信道协议经过了作者的验证。由 Akram 等人 [4] 所描述的信道同样专注于智能卡场景。另一种基于智能卡的方法由 Wang 等人 [143] 呈现。作者提议并且形式化验证了一种用于 数字版权管理（DRM [3]）场景的可信认证协议。此协议也考虑了平台配置值。作者并未评估他们所提议的协议的实现。

第 4 章关于一种基于直接内存访问的隐秘恶意软件的研究

我们信仰上帝，我们监控所有其他人。——美国空军情报、监控和侦察机构之美国空军技术应用中心的座右铭

恶意软件开发者和反恶意软件社区之间的军备竞赛达到了一个新的水平。针对内核级别的 [60]、基于虚拟机监视器的 [77]，以及基于系统管理模式的恶意软件 [49] 的反制措施已经被提议出来 [51，107，25]。其结果是，研究者探索了新的环境以用于隐藏恶意软件。恶意软件可以被放置在诸如显卡和网卡等专用硬件上以攻击宿主平台 [参见 134，135，47]。除了其他组件以外，这些设备带来了一块专用的处理器和专用的运行时内存。这些设备可以独立于宿主系统而运作。反病毒软件不能检测存储于独立内存中并且执行于另一块处理器上的恶意软件。攻击者可以利用这些设备，或者更准确地说，利用其直接内存访问机制，通过直接攻击宿主运行时内存而绕过构建于操作系统中的保护机制。我们将这种执行有目标的基于 DMA 的隐秘攻击以定位并且读取或者修改目标数据的代码称为 DMA 恶意软件。这样的数据可能是用于加密硬盘的密码学密钥、在线银行帐户的凭证、即时通讯聊天会话，以及存在于文件缓存中的已经打开的文档等。

在本章中，我们将 DMA 攻击特征化，并且推导出术语 DMA 恶意软件。我们这样探索该术语，即通过检测 DMA 恶意软件是否能够在显著提升针对计算机平台发动隐秘攻击的成功率的同时保持高效性和有效性。为了进行此项评估，我们构建了自己的 DMA 恶意软件 DAGGER——一种基于 DMA 的击键码记录器（DmA-based keystroke loGGER），它将其所捕获的数据潜出至某个外部实体。我们对此 DMA 恶意软件的高效性、有效性，以及特别是隐秘性感兴趣。我们之所以选择实现一种击键码记录器，是为了显示“短寿命”数据也能够被 DMA 恶意软件所捕获。

我们的实现基于 Intel 管理引擎，它是流行的 x86 平台的一部分。Intel ME 被实现于商用以及消费级平台（参见 Intel 博锐平台 [66]）以支持不同的应用，诸如 Intel 主动管理技术（iAMT [79]）或者 身份保护技术（IPT [67]）。我们的 DMA 恶意软件 DAGGER 并非执行于宿主处理器上。它执行于由 Intel ME 提供的处理器上，并不需要额外的硬件。DAGGER 实现了对于用户输入的隔离的运行时攻击。此外，我们的 DMA 恶意软件能够偷取密码学密钥，在攻击中针对操作系统内核结构，以及从文件缓存中复制文件等。尽管 DMA 恶意软件不能被反病毒软件检测到，攻击者仍然面临某些挑战。DMA 恶意软件必须是有效的，即它应该能够成功攻击不同系统。DMA 恶意软件还必须是高效的，即运行得足够快以查找并且处理数据，即使是在处理虚拟内存地址以及随机放置的数据时。这样的恶意软件已经超出了利用 DMA 硬件的能力。

本章的主要贡献包括：

DMA 恶意软件定义：有不同类型的代码用到 DMA。为了清楚地区分某段代码应该被看作无害、攻击，还是 DMA 恶意软件，我们引入了一种适当的定义。
DMA 恶意软件核心功能：我们列举了一系列要求，它们是 DMA 恶意软件为了实施成功的攻击所必须满足的。
DMA 恶意软件原型实现的评估：为了显示 DMA 恶意软件在增加隐秘攻击的成功率的同时保持了有效性和高效性，我们实现了 DAGGER。DAGGER 执行于隔离的 Intel ME 之上。DAGGER 能够隐秘地运作并且攻击多种操作系统。我们的实现是快速并且高效的，因此它可以在平台启动过程的早期捕获击键码。这使得 DAGGER 能够在 Linux 下捕获例如硬盘加密口令等。
DMA 副作用检测方法：我们呈现了一种检测方法，它可以揭示执行于隔离硬件环境中的 DMA 恶意软件。我们的工作展示了 DMA 恶意软件能够造成非预期的副作用，而我们可以利用那些被广泛使用并且跨平台可用的 CPU 特性来检测它们。

4.1 DMA 恶意软件定义

为了定义 DMA 恶意软件这一术语，我们首先对不同类型的基于 DMA 的代码进行了特征化，这有助于清楚地区分简单的 DMA 应用、DMA 攻击以及 DMA 恶意软件，在此，后者明确地专注于隐秘性。注意，DMA 恶意软件超出了控制 DMA 引擎的能力以外。实现了恶意功能的基于 DMA 的代码被看作严重的威胁。这样的代码可以在渗透和运行时隐秘运作。例如对于长期攻击而言，如果代码能够在平台重启以及关机和待机模式下存活，这也是一种优势。因此，我们可以在评估利用 DMA 的代码时优先考虑下列判据。即该基于 DMA 的代码：

(C1) 实施了恶意软件功能
(C2) 不需要物理访问以增加隐秘渗透的成功率
(C3) 在运行时应用了 rootkit/隐形能力
(C4) 能够在重启/待机/关机模式下存活

我们将一种二进制体系用于我们的优先级：

2³	2²	2¹	2⁰
C1	C2	C3	C4

此体系区分了 16 种基于 DMA 的代码。我们可以为每一种得出一个独特的数值。例如，某段基于 DMA 的代码并不实施恶意行为（C1=0），不会在宿主上留下痕迹（C3=1），不依赖物理访问（C2=1），并且不能在重启之后存活（C4=0），则它被映射到二进制结构 0110。此结构对应于十进制的第 6 类。所得出的数字越大，则该基于 DMA 的恶意代码越危险。

我们关于 DMA 恶意软件的定义如下：

定义：DMA 恶意软件是执行于专用硬件之上，通过一种称为直接内存访问的机制攻击计算机系统，并且至少满足判据 C1、C2 和 C3 的恶意软件。

当其被应用于第 2 章所介绍的目标平台时，此定义意味着：该 DMA 恶意软件基于第一方 DMA，并且其 DMA 引擎可以被攻击代码配置为不涉及宿主 CPU。攻击代码执行于具有其自身的处理器和运行时内存的专用硬件之上，例如网卡。控制了网卡可以增加攻击者在潜出时隐藏数据的成功率。表 4.1 将我们的二进制体系应用到第 3 章“相关工作”所呈现的 DMA 攻击上。此表还描述了哪些相关工作根据我们的定义属于 DMA 恶意软件。在本章，我们同样致力于开发一种 DMA 恶意软件的概念验证，它至少满足判据 C1、C2 和 C3。

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

攻击呈现于	`C1 C2 C3 C4`	DMA 恶意软件
[90]（USB）	`- - - √`	-
[43，42，17，101，19，18，15，87]（火线）	`√ - √ √`	-
[11，61，87]（PC 卡）	`√ - √ √`	-
[131]（Intel ME）	`- √ - √`	-
[35，36，47]（网卡）	`√ √ √ √`	√
[134，135]（显卡和网卡）	`√ √ √ √`	√
[80]（显卡）	`√ √ - -`	-

注意，此评估基于公开可获得的材料。如果我们仅仅依靠可获得的资源不能确定某个判据是否满足，我们假设该判据被满足。

4.2 DMA 恶意软件核心功能

在攻击宿主时，攻击者仅仅控制 DMA 引擎并不够。此引擎允许攻击者读取和写入宿主内存。然而，在大多数情况下，目标内存地址未知。本节描述了 DMA 恶意软件的核心功能，即克服地址随机化、内存映射，以及搜索空间限制。

攻击者必须确定内存地址。然而问题在于，例如分配给内核数据结构的内存空间在平台重启之后并不一定是位于原来的内存地址。数据结构被操作系统 随机放置于内存中。这可以以某种自然的方式发生，例如，当某个驱动程序分配内存并且获取下一段未分配的可用内存块时。该块的内存地址在平台重启之后不一定与原来相同。或者，操作系统可以应用某种随机化算法以保证数据结构不会被放置于相同的内存位置。当然，攻击者可以扫描全部系统内存以查找目标数据的签名。但是这对于扫描一台具有 4 GiB 或者更多的物理内存的系统来说非常低效。

操作系统利用 虚拟内存地址 [参见 31，第 15 章] 进行工作，而 DMA 则利用 物理内存地址 进行工作。操作系统创建了所谓的页表，它们被宿主 CPU 用于将虚拟内存地址映射到物理内存地址。这种映射在利用 DMA 解析内存地址指针时绝对必要。一种称为 CR3 的特殊宿主处理器控制寄存器包含页表的物理内存地址。攻击者不能访问 CR3 寄存器。DMA 引擎的可视性被限制在宿主内存以内。如果不进行深入分析，攻击者就必须扫描全部内存地址空间以查找相关数据。有两种潜在的方式使得攻击者可以克服这一困难。第一种方法是分析操作系统是否将上述数据结构放置在近似相同的内存区域。第二种可能性是实现操作系统的内存管理机制，即攻击者必须找到某种方式以访问由操作系统创建的内存页表。只要有了对页表的访问，攻击者就可以遍历页表并且由此解析由一个数据结构指向另一个数据结构的指针。这仍然需要已知的起始点用于搜索。

4.3 DAGGER 的设计和实现

我们将会在下一小节呈现我们的基于 DMA 的击键码记录器 DAGGER 的一般设计的概述，然后我们在 4.3.2 节解释 DAGGER 的实现细节。

4.3.1 一般设计

我们的 DAGGER 设计如图 4.1 所示。DAGGER 是一种 DMA 恶意软件。即 DAGGER 必须至少满足 DMA 恶意软件定义中的判据 C1、C2 和 C3。DAGGER 包含 3 个主要的组件：

搜索：通过 DMA 在宿主内存中查找有价值数据的地址。
处理数据：在搜索过程中识别的区域内读取有价值数据。
潜出：以某种宿主不可见的方式潜出信息。

图 4.1 DAGGER 一般设计

DAGGER 执行于具有 DMA 能力的设备上，于是它可以从宿主运行时内存中 (1) 搜索并且 (2) 处理数据。它控制了某一通讯路径以潜出数据 (3)。

4.3.2 基于 Intel ME 环境的实现

为了评估 DMA 恶意软件，我们选择在 Intel ME 上实现 DAGGER。Intel ME 为实现我们于下文所述的 DMA 恶意软件提供了某些有用的特性。

Intel ME 的核心是一块植入于平台 MCH 中的嵌入式微控制器。此隔离环境包含 只读存储器（ROM）、静态随机访问存储器（SRAM）、用于访问宿主内存的 DMA 硬件 [25，131]，以及一块处理器，如图 4.2 所示。ME 的嵌入式处理器是一块 ARCtangent-A4（ARC4）处理器。此隔离环境持续可用，与电源状态无关，甚至在待机或者开关机状态下仍然可用。它只要求芯片组被连接到某个电源。执行于此嵌入式微控制器上的应用程序被实现为固件（ME FW）的形式，并且与 BIOS 共同存储于闪存存储器中。最重要的 ME 固件范例是 Intel 主动管理技术。然而取决于计算机平台的种类（商用或者消费级），ME 还可以运行其他固件。例如由 Intel ME 执行的其他固件包括 Intel 身份保护技术、报警标准格式 [131，p.46]、用于温度和风扇控制的 Intel 安静系统技术（QST [131，p.46]），以及 集成可信平台模块（iTPM [79，p.109]）。

图 4.2 Intel 管理引擎环境

Intel 管理引擎（ME）环境包括 MCH 中的管理引擎。更进一步地，此环境包括一部分隔离的内存以及一部分隔离的持久性闪存处理器。ICH 同样包含 ME 环境组件，特别是用于实现带外通讯的组件。

ME 固件可以通过一个称为 ME 接口（MEI [79，p.71]）的 PCI 设备同宿主进行通讯。例如，MEI 可以提供所执行的 ME 固件的版本。ME 环境提供了额外的 PCI 设备 [脚注 10] 以支持诸如文本控制台和硬盘重定向等某些 AMT 特性。一个串口被模拟为实现文本控制台重定向 [参见 79，第 5 章]。发送至此端口的文本输出被通过网络转发至远程控制台。有了这项能力，管理员可以远程控制 BIOS。为了实现硬盘重定向，一块本地硬盘被 ME 环境模拟 [参见 79，第 5 章]。管理员可以通过本地模拟硬盘远程挂载存储介质（例如一张含有操作系统安装程序的 CDROM 以恢复此启用了 AMT 的平台上的操作系统）。

脚注 10：这些设备可以作为总线主控，参见 2.5 节。

在平台加电过程中，ME 固件镜像被加载至 ME 内存。ME 固件本身运行于微控制器内部的 ARC4 处理器上，它还会使用某些系统内存，如图 4.2 所示，以存储运行时数据。此运行时内存由某一内存区域提供，并且对于主 CPU 和操作系统不可见。这种隔离由芯片组强制实施 [79]。

ME 环境引入了带外（OOB）通讯，即由 iAMT 使用的特殊网络流量信道。启用了 iAMT 的计算机平台由远程管理控制台通过 OOB 管理。OOB 同样持续可用，而与电源状态无关。OOB 可以看作运行于相同硬件上的隔离网络连接。ICH 实现了必要组件以便为 ME 环境提供 OOB 特性。固件将专门用于例如 iAMT 的网络流量过滤出来并且将这些数据包重定向至 ME。宿主对于重定向的 ME 网络流量并不警觉。此类流量由 TCP 端口号来识别。

4.3.3 针对 Linux 和 Windows 目标的攻击实现细节

我们实现了两种击键码记录器原型以攻击两类目标，即基于 Linux 和 Windows 的操作系统。我们决定查找并且监控目标操作系统的 32 位版本的键盘缓冲区地址。与 64 位版本相比，32 位版本必须处理更加复杂的内存管理，例如，攻击者在映射内存地址时必须考虑 物理地址扩展（PAE [105，p.769]）或者某些内存偏移量。在下一小节中，我们描述了我们是如何实现如 4.2 节所述的 DMA 恶意软件核心功能的。这些原型在其 监控阶段 捕获短寿命的击键码。每种原型以不同方式处理用于不同目标缓冲区的 搜索阶段。这是由至少两大原因决定的。原因之一是为了评估 DMA 恶意软件的尽可能多的方面。另一个原因是不同的操作系统拥有不同的内存管理属性。我们使用一种由 Tereshkin 和 Wojtczuk [131] 所描述的漏洞以便在运行时渗透 ME 环境。为了调用我们的代码，我们挂钩到某个被我们识别为库函数 memset 的 ME 固件函数上。Tereshkin 和 Wojtczuk [131] 假设他们挂钩了某个计时器中断处理程序，但是他们实际上挂钩了 ME 固件函数 memcpy。我们之所以选择挂钩 memset 是由于我们确定此函数被更加频繁地调用。

我们的 Linux 变体基于如图 4.3 所示的签名扫描。我们分析了可获得的 Linux 源代码以得出我们的目标的签名，即键盘缓冲区的物理地址。此缓冲区地址是 USB 请求块（URB）结构的一部分，该结构定义于 Linux 源代码的 include/linux/usb.h 文件中。所需的结构字段称为 transfer_dma。此内存偏移量随内核版本不同而不同。我们通过利用 多重启动管理器（GRUB）来解决这个问题，使其在固定的物理内存地址放置一个标识符。我们实现了一个函数以便通过 DMA 读取该标识符并且对内核版本号进行分析以得出对应的偏移量。随后，我们的原型进入搜索阶段，即签名扫描。

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

(1) 开始查找指向 USB 设备结构的指针，这样的候选指针对齐到 0x400 边界。结构字段 transfer_dma 的值必须对齐到 0x20 边界。如果这两个条件同时为真，此 USB 设备结构中的产品字符串将被 (2) 检查是否包含子字符串”USB”和”Keyboard”。在签名扫描的最后一步 (3) 检查键盘缓冲区是否包含 垃圾信息，即无效的击键码。

由于我们的 Linux 原型针对的是内核数据结构，我们可以将搜索空间限制为系统内存的最前面 1 GiB。标准 Linux 系统拥有一种 1 GiB / 3 GiB 的内存分割方案，即 1 GiB 用于内核空间，3 GiB 用于用户空间。我们能够通过经验性地分析内核将我们的签名搜索所需的数据结构放置于哪块内存区域来进一步限制搜索空间。我们已经确定对于 Ubuntu Linux 内核版本 3.0.0 在一次新鲜的平台重启之后，该内存区域介于 0x33000000 至 0x36000000 之间。此键盘缓冲区的地址在待机或者休眠之后不会改变。通过这种方式，我们克服了低效扫描全部系统内存以查找随机放置的签名这一困难。在攻击 Linux 内核时，将虚拟地址映射到物理地址并不是一个大问题。通常，在 32 位版本中，一段内核虚拟地址（或者更准确地说，内核逻辑地址 [参见 31，第 15 章]）通过减去一个固定的偏移量而被映射到它的物理地址。在 64 位 Linux 版本中，无需使用这样的偏移量。因此无需获知 CR3 处理器寄存器的状态。

针对基于 Windows 的目标平台的搜索策略与此不同。为了能够利用搜索路径执行下文所述的搜索，虚拟地址必须被映射到物理地址。这种映射是通过由 Windows 内核创建的页表而实现的。这些页表的内存地址被加载至 CR3 寄存器，这是攻击者利用 DMA 所不能访问的。在利用某个简单的驱动程序进行了一些经验测试之后，此用于 系统进程 的页表的物理地址被证明为采用以下两个值之一：0x122000 或者 0x185000，对于 Windows Vista/7 系统。此系统进程是在 Windows 启动过程中所创建的首个进程。有了这一知识，DAGGER 便可以访问由内核创建的页表并且克服将虚拟地址映射到物理地址这一困难。DAGGER 实现了一种考虑到 PAE 的页表遍历算法。

我们的 Windows 恶意软件查找一个名为 DeviceExtension 的结构，它由 USB 键盘驱动程序 kbdhid.sys 所维护。此结构包含一块存储着近期按键的击键码的缓存。kbdhid.sys 的源代码不可公开获得。获得关于此驱动程序的内部信息的最便捷方式是使用 IDA Pro [脚注 11]、Windows Debugger（WinDbg）工具，以及由微软以 pdb 文件形式提供的调试符号 [脚注 12]。为了最终确定该缓冲区在 DeviceExtension 结构中的位置，我们的研究始于启动过程的早期 [参见 105，第 13 章]。我们了其他的 Windows 内部结构。为了查找用于搜索的起始指针，我们分析了 内核处理器控制区域（KPCR [105，p.62ff]），或者更加准确地说，KiInitialPCR，即用于处理器 0 的 KPCR。我们同样检查了 对象管理器名称空间目录（OMND，Windows 对象管理器的一部分）。我们确定了 KiInitialPCR 很适合于推导出一条指向 DeviceExtension 结构的路径，如图 4.4 所示。KiInitialPCR 并非定位于固定的内存地址。DAGGER 不得不在其能够开始如图 4.4 所示的搜索之前应用一个额外步骤。

脚注 11：参见 http://www.hex-rays.com/products/ida/index.shtml [访问于 2014 年二月 25 日]

脚注 12：参见 http://msdn.microsoft.com/en-us/windows/hardware/gg462988 [访问于 2014 年二月 25 日]

图 4.4 查找 DeviceExtension 结构（简化）

有了 KiInitialPCR 作为起始点，DAGGER 找到了 OMND，它通过散列值表提供了一条指向驱动程序对象 kbdhid 的路径。此对象包含指向设备对象的指针。此设备对象提供了 DeviceExtension 结构，它包含击键码缓冲区。

KiInitialPCR 的内存位置由 winload.exe 二进制文件中的一个名为 OslpLoadAllModules 的函数决定，如图 4.5 所示。此二进制文件由 Windows 启动管理器 bootmgr 所加载，而后者又由 主引导记录（MBR）代码所加载。此函数以某种或多或少地随机化的方式加载 硬件抽象层（HAL）库 hal.dll 以及 Windows 内核镜像。此内核镜像在一个固定的相对地址包含 KiInitialPCR。OslpLoadAllModules 的反汇编代码类似于某种 地址空间布局随机化（ASLR [105，p.757]）机制。

图 4.5 查找 KiInitialPCR（简化）

OslpLoadAllModules 决定了 Windows 内核镜像和 HAL 的准确位置。

用于内核镜像和 HAL 的内存缓冲区由 OslpLoadAllModules 通过一个名为 BlImgAllocateImageBuffer 的函数分配。该函数返回对于某一 Windows 系统固定的地址值。这些值可能会因系统不同而不同。对于函数 BlImgAllocateImageBuffer 的可能的返回值，共有 64 种不同的 4 kiB 对齐的虚拟地址的理论可能值。这些地址需要被检查以发现内核镜像基地址。对 BlImgAllocateImageBuffer 的反汇编揭示了用于地址随机化的种子拥有 5 位的值。这提示了对于（两种）可能的加载顺序情况中的每一种各有 32 种可能的地址，这两种可能的情况是指到底是先加载内核镜像，然后加载 hal.dll 还是反过来。只要 KiInitialPCR 在内核镜像内部具有固定的虚拟地址，同样多的待检查的虚拟地址数量同样适用于直接搜索 KiInitialPCR，而无需处理内核镜像。为了保证 DAGGER 找到的是正确的 KiInitialPCR，我们实施了一种 KiInitialPCR 签名检查。如果 DAGGER 识别到了正确的 KiInitialPCR，它就会继续利用图 4.4 所示的搜索路径查找键盘缓冲区。

我们利用以太网控制器来潜出所捕获的击键码。更准确地说，我们利用 Intel ME 环境的 OOB 特性。然而，没有文档解释如何使用这一特性。因此，我们不得不分析固件以判明如何利用 OOB 信道来潜出击键码。我们能够找到用于在 ME 运行时内存中发送网络数据包的传送环缓冲区。更进一步地，我们还能够从该传送环缓冲区中找到负责发送下一个网络数据包的固件代码。为了潜出所捕获的数据，我们准备了网络数据包，例如如图 4.6 所示的 DHCP 发现数据包。它包含记录下来的击键码。然后，我们将准备好的网络数据包复制到传送缓冲区。随后，我们通过网卡触发，将此数据包发送至某个外部平台。请注意，如果利用外部平台分析网络流量，则很容易发现被传送的数据包。为了增强此设计的隐秘性，我们 [124，125] 实现了一种隐秘计时信道，它基于所谓的 Jitterbug [参见 115]。

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

此 wireshark 实例执行于某个外部平台上。此网络数据包已经被 wireshark 分析为包含 4 个字节，它代表了所记录的击键码数据。

4.4 评估

我们使用一台具有 Q35 芯片组、2 GiB 内存、一块四核 3 GHz CPU，以及 iAMT 固件（版本 3.2.1）的 x86 平台来评估 DAGGER，利用 4 种不同的 32 位操作系统内核：Windows Vista 商用版（服务包 2）、Windows 7 专业版（服务包 1），以及 Ubuntu Linux 内核版本 2.6.32 和 3.0.0。

4.4.1 DMA 恶意软件功能的实现

我们根据 4.1 节所述的 DMA 恶意软件定义设计并且实现了我们的 DAGGER 原型。(C1) 显然满足，由于 DAGGER 实现了可运作的击键码记录器功能。DAGGER 在渗透过程中不需要物理访问 (C2)。我们在运行时利用基于软件的漏洞渗透 ME 环境。DAGGER 利用了专用硬件以实现 rootkit 属性 (C3)。我们运行了宿主性能开销测试（内存：MEM，网络：NET，以及 CPU），由于宿主和 ME 环境共享网卡以及内存芯片。并行的网卡和内存访问必须被仲裁，并且可能因此造成延迟。我们的测试结果如图 4.7 所示，并未显示出显著的开销。我们所能检测到的最高开销在搜索阶段扫描宿主内存时大约为 1.5%。这种最小化的性能开销不太可能使得 DAGGER 暴露。

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

我们使用时间戳计数器以测定开销时间。我们测试了通过网络（NET）以及在内存（MEM）中复制一个 100 MB 的测试文件所需的时间，以及并行计算此测试文件的 SHA1 散列值 10 次所需的时间，这是为了对全部 4 个 CPU 核心（CPU）造成压力。每组基准测试执行了 3 次：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式。对于监控模式，我们将击键码记录器配置为大约每分钟持续发送大约 1000 个网络数据包。这相当于 500 次击键和 500 次释放按键事件。我们重复了每项测试 1000 次。图中的横线表示 1000 次运行的平均值。

如图 4.8 所总结的搜索时间非常短，并且我们所进行的极具侵略性的内存压力测试并不代表通常的计算机系统的内存使用。DAGGER 拥有完全只读的操作以保证其隐秘性。流行的网络嗅探工具 Wireshark [脚注 13] 在 Linux 和 Windows 系统上不能检测到任何 DAGGER 流量。宿主防火墙也不能阻止这些流量。即使反病毒软件知道 DAGGER 的签名，它也不能访问 DAGGER 的内存以成功应用签名扫描。此外，我们还运行了一种名为 Mamutu [脚注 14] 的软件，除了其他功能以外，它专注于检测击键码记录器行为。即使是专门的软件也不能发现 DAGGER 的任何痕迹。关于判据 C4，我们成功地检查了 DAGGER 的攻击代码能否在平台重启、待机以及关机之后仍然完全可运作。我们确定这取决于一个 iAMT 的 BIOS 选项。我们的代码不能在冷启动之后存活，如果此选项未被设置。

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

脚注 14：参见 http://www.emsisoft.com/en/software/mamutu/ [访问于 2014 年二月 25 日]

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

在 Linux 下利用若干种键盘的测试结果显示了搜索时间约为 1000 ms 的最佳案例和将近 30000 ms 的最差案例，如 (a) 所示。对于所有键盘的平均值为 3281 ms。有利于比较的信息是：对于 Linux（参见 4.3.2 节），扫描全部内存区域用时被测定为 13000 ms。而 30000 ms 的最差案例是由于我们所未能直接处理的错误 DMA 传输。这导致 DAGGER 重复进行搜索阶段。在 Windows 7 上，最佳搜索时间约为 50 ms 而最差搜索时间约为 120 ms，参见 (b)。对于所有键盘的平均值为 93 ms。因此，我们为 Windows 平台所实现的搜索策略的性能远远好于 Linux 的基于签名扫描的策略。

4.4.2 有效性和高效性

DAGGER 是高效的，由于它可以永久性地从键盘缓冲区捕获短寿命数据。为了表明 DAGGER 同样是有效的，我们利用不同的 Windows 和 Linux 版本以及若干种键盘测试了 DAGGER。测试得出的搜索时间总结于图 4.8，这确认了 DAGGER 非常高效。我们为每种内核和每种键盘重复测试 100 次。我们的测试发生于平台启动或者重启之后以改变每次运行时的目标地址。Linux 测试结果提示我们能够进一步限制搜索空间。我们能够在我们的测试中最常遇到的最低地址附近开始搜索。大约 2500 ms 的搜索时间是由于目标地址靠近 0x33c00000。因此我们能够跳过大约 2500 ms，如果我们在 0x33c00000 处开始搜索。更进一步地，我们能够跳过介于 0x34000000 和 0x36000000 之间的地址范围，由于我们几乎没有在此区域发现目标。大量目标被发现于 0x36e00000 附近，即还可以节省大约 12500 ms 的搜索时间。这会增加错失键盘缓冲区地址的几率。这意味着我们可以以牺牲有效性为代价来获取更好的搜索时间。在最佳案例下，搜索时间快到足以捕获诸如硬盘加密口令等。我们利用某个 Linux 系统成功地测试了这一点。Windows 内核可以将内存页交换到硬盘上——而 Linux 则不会。交换的内存页不能被 DMA 恶意软件所发现。因此我们同样对 Windows 进行了一项测试以检查内存交换对 DAGGER 是否有任何影响，如图 4.9 (d) 所示。

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

(c) 中的图像比较了不同的目标内核。DAGGER 在 Windows 7 上的性能略好于 Windows Vista。Linux 2.6.32 相对于 Linux 3.0.0 将目标内存结构放置得更加靠近 0x33000000，因此 DAGGER 在攻击 Linux 2.6.32 时拥有更多的位于 1000 ms 左右的命中率。(d) 中的结果确认了内存交换对于 DAGGER 的高效性和有效性没有影响。平台重启仅被应用于改变交换行为。尖峰是由于搜索阶段的重启。

4.4.3 ME 固件条件

为了能够真正成为隐秘的，DAGGER 确保了 ME 固件一直运行并且正确运行。iAMT 提供了一种网络服务器以用于远程平台管理 [参见 79，p.215]，它仍然可用。此服务器在本地平台的 Linux 和 Windows 上正确响应。利用 MEI（参见 4.3.2 节）工作的固件工具在 DAGGER 活动时仍然能够正常工作。我们在 Windows 下成功地测试了 AMT 状态工具（作为 本地管理服务驱动程序 的一部分）和 管理连接工具（作为 管理开发者工具包 7.0 的一部分）。在 Linux 下，我们成功地测试了 Intel AMT 开源工具和驱动程序（版本 5.0.0.30），或者更加准确地说，ME Status 和 ZTCLocalAgent 工具。注意，我们确定 DAGGER 仍然能够运行，即使已经在 BIOS 中禁用了 iAMT 固件。看起来 ME 环境不可能通过任何 BIOS 选项完全禁用。

4.4.4 I/OMMU

为了测试 I/OMMU（参见 2.6 节）能否作为对抗 DAGGER 的反制措施，我们在 BIOS 中启用了 Intel VT-d。就我们所知，Windows 并不能直接支持 I/OMMU。我们仍然能够成功攻击 Windows Vista 和 Windows 7，即使 I/OMMU 被激活。Linux 通过额外的努力支持了 I/OMMU 配置。我们同样在 BIOS 中启用 VT-d 并且通过内核命令行激活了 I/OMMU 支持。有了这些额外的步骤，我们能够阻止 Linux 版本的 DAGGER 从操作系统内存中读取短寿命的击键码。这种保护在默认状态下并未开启。在下一节中，除了其他内容以外，我们将会讨论与 I/OMMU 有关的其他问题。

4.5 关于反制措施的考虑

利用执行于宿主 CPU 之上的软件来扫描 DMA 恶意软件非常困难。例如，当前的反病毒软件并不会扫描外设的运行时内存，或者宿主 CPU 不能访问此运行时内存，由于某些隔离机制。对于扫描方法的最坏案例是 DMA 恶意软件改变了扫描软件的行为，使其得出错误的结果。如 TCG [136] 所提议的加载时固件镜像检查并不能防止运行时攻击。更进一步地，所有 ROM 组件是否都可被宿主访问这一点并不清楚。

4.5.1 I/OMMU 相关问题

对于 DMA 攻击的情况，I/OMMU（参见 2.6 节）的恰当配置被诸如 Duflot 等人 [47] 所提议为一种预防性的反制措施。这要求由系统软件配置 I/OMMU。不正确的配置不能被排除 [83，p.2]。

假设 I/OMMU 是安全的。然而，情况并非总是如此。Sang 等人 [111] 展示了 I/OMMU 配置可以被传统 PCI 设备所欺骗。Wojtczuk 等人 [148] 揭示了 I/OMMU 可以通过修改由 BIOS 提供的 DMA 重映射引擎数量而被攻击（参见 2.6 节）。这是在 I/OMMU 被系统软件配置之前完成的。我们用于 DAGGER 的环境能够执行此类攻击。此威胁只能通过执行名为 SINIT 的依赖于硬件的特定代码来化解。然而，之前至少发生过一次这样的情形，即芯片组厂商未能在芯片组发布时释出 SINIT 代码 [147，p.22]。此代码对于初始化一个用于诸如虚拟机监视器等的众所周知的、可信的环境来说是必要的。它检查 DMA 重映射引擎，并且由此能够阻止由 Wojtczuk 等人 [148] 所呈现的攻击。

SINIT 属于可信计算基并且增加了它的大小。前期工作展示了 SINIT 代码可能包含可被利用的安全漏洞，这些漏洞可以被用于欺骗 I/OMMU 机制 [参见 148]。最近，Wojtczuk 和 Rutkowska [146] 呈现了另一种可以被用于绕过 I/OMMU 机制的攻击。为了防止由 Wojtczuk 和 Rutkowska [146] 所呈现的攻击，SINIT 以及 BIOS 更新必须被应用。Wojtczuk 等人 [147] 呈现了另一种 I/OMMU 攻击。注意，SINIT 一般在基于虚拟机监视器的平台上被触发。基于通常的操作系统的平台不一定能够依靠 I/OMMU。同样值得提到的是，SINIT 要求激活额外的平台特性，即 可信执行技术 和 TPM [54]。这意味着诸如那些不想激活 TPM 的用户将不能依靠 I/OMMU。注意，TPM 是一种可选设备 [参见 54，p.212]，并且默认被关闭。

为了得到针对 DMA 恶意软件的完全保护，正确配置 I/OMMU 是绝对必要的。然而，I/OMMU 仅在其上方的用于保护整个平台的机制是安全的的情况下才能被看作是安全的。这是一项困难的任务。因此，其他方法由 Li 等人 [83] 和 Duflot 等人 [46] 所考虑。Li 等人 [83] 宣称他们的方法要求对固件进行扩展、并不能在外设造成大量 PCIe 流量的情况下正确地工作，以及验证组件需要知道精确的硬件配置。由 Duflot 等人 [46] 所呈现的方法高度针对网卡，并且不适用于诸如 Intel ME 等隔离执行环境。值得注意的是，诸如我们所实现的恶意软件能够在不进行任何网卡固件修改的情况下控制网卡，即数据潜出不能被由 Duflot 等人 [46] 所描述的方法检测到。更进一步地，此方法对于宿主 CPU 具有显著的性能问题（某个 CPU 核心 100% 使用）。

由 I/OMMU 强制实施的内存访问策略可能是不充分的，或者甚至可能在某些应用场景中阻止某些其他特性的使用。考虑诸如 CoPilot [100] 和 DeepWatch [25] 等由硬件支持的恶意软件扫描工具。I/OMMU 可以被配置为阻止 CoPilot 或者 DeepWatch 正常工作，或者允许这些系统访问宿主内存以扫描恶意软件。在后一种情况下，DMA 恶意软件可以利用 CoPilot 或者 DeepWatch 的执行环境来攻击宿主。例如，DAGGER 利用了 DeepWatch 的环境，即 Intel ME。自从 iAMT 版本 5 开始，Intel 支持对于将要执行于 Intel ME 之上的固件进行验证启动 [参见 79，p.271]。固件将会在加载时被检查。此加载时检查的结果被提供给系统软件。据我们所知，此结果并未在实践中被使用。此机制不能阻止由我们的概念验证所应用的运行时攻击。这意味着 DAGGER 证实了我们的这一假设，即诸如通过零日漏洞（参见 2.7 节）已经渗透目标系统的攻击者仍然能够雷打不动，即使诸如此类的额外安全机制已经就位。I/OMMU 的恰当配置是对抗 DMA 恶意软件的第一步。但是，如果不能解决上述问题，成功的部署并不能被保证。

4.5.2 基于 DMA 副作用的检测方式

一种可能的检测方式基于 DMA 副作用，这种副作用是我们在对自己的 DMA 恶意软件原型 DAGGER 进行首次实验的时候就观察到了的。我们的检测机制基于多种被广泛使用并且跨平台可用的 CPU 特性。

就目前为止，我们开发、实现并且评估了我们的机制，它能够检测到那些并非由宿主系统引发的非预期的恶意 DMA 使用。如果某个外设必须以宿主 CPU 的名义处理数据，则其 DMA 使用由宿主 CPU 引发。利用网卡发送一个网络数据包就是这样的一个范例。预期的 DMA 使用源自外设，并且其本意是用于运行于宿主 CPU 上的软件。接收一个网络数据包就是关于预期 DMA 使用的一个范例。我们的方法能够检测一种普遍的副作用特征。因此我们相信它除了我们自己所实现的 DMA 恶意软件原型以外，还适合于检测其他类型的 DMA 恶意软件。我们对于检测恶意 DMA 使用的调查基于这一知识，即主 CPU 和平台外设都能够在同一时刻请求对主系统内存的访问。内存控制器集线器对并行内存访问请求进行仲裁，参见图 2.5。对于我们来说的有趣问题是，这种并行内存访问是否引入了任何可以测量的副作用。如果此副作用存在并且可测量，则我们可以利用这些副作用来检测恶意行为。

我们启动了一种 Linux 内核并且只启动了一个 root shell 以保持系统负载最小化。只有一个 CPU 核心在线。我们执行了 3 次内存压力测试：没有击键码记录器（基线）、击键码记录器处于搜索模式，以及击键码记录器处于监控模式，同时参见 4.3.3 节。我们使用了一个 100 MB 的文件用于测试，通过将其从某个基于内存的文件系统中的一个位置复制到另一个位置。我们重复了此测试 1000 次并且计算了平均值。结果如图 4.10 所示。此图表揭示了我们如何利用不同的更加专门化的测量工具来精炼我们的策略。

图 4.10 内存压力测试

搜索阶段和监控阶段被表示为相对于基线的值。

GNU Time 测量结果

首先，我们尝试通常的系统工具 GNU time 以测定延时。GNU time 测量的是某个进程的系统资源使用，在我们的案例中即为内存压力测试工具。如图 4.10 左侧显示，所运行的测试结果的平均值几乎相同。我们得出结论，即 GNU time 的测量分辨率不足以揭示我们的实验中的延迟。

时间戳计数器（TSC）测量结果

我们利用一种更加精确的，基于硬件的测量工具，即 TSC [参见 69，第 17.12 节] 重复了我们的测量。TSC 对时钟周期进行计数，参见 2.3 节。其结果呈现于图 4.10 中间。我们能够得到或者重现 2% 的开销，如果我们的原型恶意软件处于搜索模式。DMA 最初被引入是为了消除 CPU 负载。这意味着执行内存传输而无需涉及宿主 CPU。因此，这种开销是一种惊喜，也是关于可检测的 DMA 副作用确实存在的第一组证据。当我们的原型恶意软件处于监控模式，我们在使用 TSC 时并不能观测到显著的开销。两种模式之间的关键区别在于，在搜索模式中，恶意软件需要复制至少一个内存页以便在其中搜索有价值数据。而在监控模式中，此恶意软件只需从键盘缓冲区复制 4 字节。

硬件性能计数器（HPC）测量结果

我们利用第三种方式重复了测量，即利用 HPC，用于代码优化的一种基于硬件性能监视工具，参见 2.3 节。这些计数器是位于 Intel 处理器上的特殊目的处理器寄存器 [69，第 18/19 章]。它们对特定事件进行计数，诸如缓存未命中、分支预测错误，以及资源停止等。类似的 HPC 在诸如 ARM 和 SPARC 等平台上同样可用。我们用于我们的实验的 Intel 平台支持 340 种事件 [脚注 15]。我们评估了它们的全部，并且确定资源停止是一种特别有效的 DMA 副作用。对于某些特定事件，HPC 事件计数相对于 TSC 测量更加精确。我们假设资源停止的次数是我们所能利用 TSC 测量得到的延迟的直接结果。作为一个范例，我们在图 4.10 中呈现了一种名为 RAT_STALLS:ROB_READ_PORT（参见 2.3 节）的硬件性能计数器所得到的结果。相对于基线，其开销高达 2 倍以上。如果没有我们的原型恶意软件，我们的测量结果是 1359898 次计数事件。如果我们的原型恶意软件处于搜索模式，平均值为 3161868 次计数事件，而在监控模式中时则为 1535054 次计数事件。后者只是略高于基线。这组精炼的测量结果展示了我们的测量越精确，则 DMA 副作用的可见性就越好。

脚注 15：我们使用了性能 API 以便在上述实验中配合 HPC 工作，它可以从此处获得：http://icl.cs.utk.edu/papi/software/index.html [访问于 2014 年二月 25 日]

检测

基于我们的发现，DMA 副作用可以被测量。这意味着我们能够设计一种 DMA 恶意软件检测机制。此机制通过建立一组测量基线并且将 TSC/HPC 的测量值与之进行比对而达到目的。在运行时，我们的系统监控 TSC/HPC 测量值并且将其与参比值进行比对。如果这些值偏离参比值，则 DMA 恶意软件就被检测出来了。我们承认关于此种基于延迟的检测方法的某种实际实现仍需进一步调查。在第 5 章，我们呈现了一种改良的检测器，它同样基于 HPC。更进一步地，对于我们的改良的方法，对于检测 DMA 恶意软件而言，人为施加的内存压力不再是必需的。在本节，我们仅仅作为反制措施来讨论 I/OMMU 和一种基于 DMA 副作用的检测方法。

4.6 本章小结

在本章中，我们研究了 DMA 恶意软件，即隐藏于专用硬件中的恶意软件。诸如此类的恶意软件可以通过直接访问宿主内存来绕过运行于宿主 CPU 之上的保护机制。我们实现并且评估了 DAGGER，一种基于 DMA 的击键码记录器。专用硬件使得我们的原型能够得益于 rootkit 属性。DAGGER 能够隐秘地运作。它不可由诸如反病毒软件等检测到。我们能够得出结论，与其他已知的 DMA 恶意软件相比，DAGGER 是一种具有代表性的恶意软件概念验证。因此，我们将会在后续章节重复使用 DAGGER 以开发一种可靠的 DMA 恶意软件检测器。

DMA 恶意软件不仅仅是控制一个 DMA 引擎。我们的评估确认了 DMA 恶意软件是高效的，即使诸如内存地址随机化等障碍已经就位。我们同样展示了 DMA 恶意软件可以是有效的，即它可以攻击若干种操作系统。这确认了 DMA 恶意软件的隐秘性无需以牺牲高效性和有效性作为代价。宿主并没有可靠的方式以保护其自身。纵观本章，我们强调了 I/OMMU 具有若干问题，并且宿主不一定能够依赖这种预防性措施以对抗 DMA 恶意软件。除了可能的漏洞以及不同的预设条件必须被满足以成功部署 I/OMMU 以外，最为明显的问题是普通的操作系统并不支持 I/OMMU，或者支持不充分。因此 DMA 恶意软件可以攻击诸如 Windows 等操作系统。用于扫描专用设备以查找恶意软件的通用并且可靠的方法并不存在。需要一种可靠并且更加通用的 DMA 恶意软件检测机制。其他研究者也调查了 I/OMMU 的替代品。

在本章中，我们讨论了一种替代方法。我们的检测方法基于这样一种现象的观察，即来自隔离硬件（通过 DMA）和来自宿主 CPU 的并行内存访问造成了可测量的副作用。因此我们可以得出结论，即非法 DMA 操作不再是隐秘的。此外，我们不得不承认用于此检测方法的实验设置包含大量人为因素。我们得出结论，当前的设置不足以作为可以在实践中应用的检测工具。然而，我们展示了硬件性能计数器可以作为可靠的检测工具的基础。我们揭示了测量工具必须具有足够的测量分辨率。硬件性能计数器满足这一要求。我们将会在下一章更加详细地调查这一点。

没有替代品，只有那些其内部工作方式对于宿主可以访问，即完整的内存和只读存储器访问的专用硬件应该被部署。这使得宿主能够时时刻刻地检查该设备以查找恶意代码。关于这一点的一个前提条件是一种合理的测定策略，以及扫描程序得以首先加载。具有专用处理器、专用运行时内存以及 DMA 引擎的设备对于宿主平台来说是一种威胁。本章展示了需要额外的保护机制以确保平台的机密性和完整性，以及特别是它们的可信性。

第 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 造成巨大数量的内存传输。若干个处理器核心为众多进程存取指令和数据。针对由它们所造成的总线活动来高效地监控所有这些系统进程几乎不可能。因此，我们决定这样来分析宿主 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~~ 的永久监控采用如下步骤实现：

重置计数器并且存储所有非 CPU 总线主控（例如 UHCI、FR、ME、硬盘控制器（HD）、以太网控制器（ETH）、视频控制器（VC）等）的初始 I/O 统计数据。
开始对于一定时间 t 的计数（采用高精度计时器实现）。
当到达时间 t 时停止计数。
存储对应于 A_m 和 A_m^CPU 的计数器的值（参见 5.2.1 节），并且更新所有非 CPU 总线代理的 I/O 统计数据
继续步骤 (1)，并且通过唤醒对应的评估内核线程来并行确定 A_e。

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

利用所存储的对应于 A_m 和 A_m^CPU 的计数器的值来确定 ~~A_m^CPU~~（参见 5.2.1 节）。
利用 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 等。
比较 ~~A_m^CPU~~ 和 ~~A_e^CPU~~，报告结果，并且如有必要则应用某种防御机制。

容错值

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

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

在终止不可信的总线主控时，BARM 会在平台屏幕上为用户放置一则通知。A_{T_a} 并不包含任何关于何种平台外设正在执行攻击的信息。为了在通知消息中包含此信息，我们实现了一种能够识别可疑外设的简单外设测试。在当 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_d^TX - old_d^TX} (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_d^RX}_{n=old_d^RX} 1_N(n) （公式 6.8）

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

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

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

利用额外的 `BUS_TRANS` 事件

我们利用更多的 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 一同部署，并且被看作长寿命的。

对 Hello 消息的修改

我们利用 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.