DR@FT: Efficient Remote Attestation Framework for Dynamic Systems 论文翻译

Abstract

远程认证是一个重要的机制，它通过验证计算系统的完整性来提供其诚信证明。在本文中，我们提出一个创新的远程认证框架DR@FT，来高效的测量一个目标系统，这个目标系统是基于信息流完整性模型的。有了这个模型，系统的高集成度处理就第一次可以通过测量来验证了，并且这些处理会拒绝低完整性处理的访问。而且，我们的框架验证的是动态系统的最新的状态改变而不考虑整体系统信息。此外，我们采用基于图的方法，用一个排了名的违反图来表示整体性的违反，这就使得对认证结果可以直观推断了。我们的实验和性能评估证明了DR@FT的可行性和实用性。

Introduction

典型的认证机制被设计为基于以下几个步骤. 第一步，一个认证请求器(attester) 向目标系统 (attestee)发送一个挑战，attestee用它的硬件和软件组件的完整性证据响应。第二步，attester从attestee获取运行时属性并且决定attestee的可信度。最后可选的一步，attester返回认证结果（例如完整性测量状态）给attestee。远程认证可以帮助减少由干扰系统造成的潜在风险。

各种证明方法和技术都已经被提出了。可信计算组（TCG）指定了可信平台模块（TPM），它可以向远端安全地存储和提供系统的完整性测量。完整性测量机制已经被提出来了，用来帮助提高TPM在应用级别的能力。

然而，这些已经存在的方法，当证明一个由于系统导向的事件（如安全策略更新、软件包安装）而导致系统状态不断改变的平台时，仍然需要解决高效性问题。最后同等重要的一点，已经存在的证明系统，当解决被识别了的安全入侵时，没有一个有效的和主观的方法来表示和反映这个证明结果。

我们提出了一个高效的远程证明框架，叫做动态远程证明框架和策略（DR@FT），来解决前述的问题。我们的框架基于带有基于域的隔离模型的系统整体性属性。有了这个属性，系统的高整体性处理第一次通过测量的方法得到证实，并且这些处理被保护起来，使得低整体性处理无法获取。换句话说，通过分析系统的安全性策略，高完整性处理保护被证实了，这用系统行为（包括应用程序行为）指定了系统配置。DR@FT使我们能够证实是否某个在attestee中的应用程序满足完整性要求。通过证明一个系统的动态特性，DR@FT证实系统状态最新的改变，而不是为每一个证明请求考虑完整的系统信息。通过这两个策略，我们的框架试图高效地证明目标系统。而且，DR@FT采用一个基于图形的分析方法来分析安全策略侵入，这个能帮助直观地检测出attestee中的恶意信息流。为了更进一步提高安全入侵解决的高效性，我们提出了一个排名策略，它提供了一个方法来用风险级别描述不同系统状态的可信度。

2 Background

2.1 Attestation（认证）

TCG认证过程包含两个步骤：1.一个attestee平台从BIOS块开始，测量硬件和软件组件，并且生成一个哈希值。这个哈希值接着被存储进一个TPM平台配置寄存器（PCR）。递归地，它用同样的方式测量BIOS启动器和操作系统并且将他们存储进TPM PCR中。2.一个attester从attestee获得attestee的带有证明标示秘钥（AIK）的数字证书，被AIK标识的PCR值，和测量日志文件。通过这些步骤我们注意到，TCG测量过程组成了一组连续的步骤直到引导装入程序。因此，TCG不提供有效的机制来测量一个系统在开机之后的整体性，特别是考虑到还有一些由运行中的操作系统加载的可执行的内容是随机的。

IBM IMA将TCG的测量领域扩展到了应用程序级别。然而，IMA需要验证attestee平台的整个组件，而ateestee也许只需要对某个应用程序进行验证。而且，一个系统的完整性状态需要通过分别测试每一个测量入口来验证，它关注高完整性过程。然而，忽视从不受信任的网络新安装的不受信任的应用程序是不切实际的。

PRIMA是一个基于IMA和CW-Lite整体性模块的认证工作。一方面，PRIMA需要扩展才能抓住系统状态的动态特性（比如软件和策略的更新），这会为维持它的高效性带来障碍。另一方面，PRIMA用二进制的形式提供一个认证结果，而且对于有多少attestee平台可以被信任它不提供语义上的信息。

2.2整体性模块

为了描述一个系统的整体性状态，存在很多种的基于信息流的整体性模块。如Biba，LOMAC,Clark-Wilson和CW-Lite。对于Biba，如果一个高整体性处理不能读/执行一个更低的整体性对象，也不能通过任何其他方式获取更低整体性的数据，它的整体性属性就被实现。LOMAC允许高整体性处理读取更低整体性的数据，同时将过程的整体性级别降低至最低整体性级别。Clark-Wilson提供一个不同的依赖视图，它表达了信息可以通过一个特定的称为事务处理（TP）的程序来从低整体性对象流向高整体性对象。

用现存的整体性模块，在具体实现对一个系统组件的测量和验证它的整体性状态之间会有一道鸿沟。我们相信一个以应用为导向的和以域为中心的方法，相比于抽象模块，更能满足认证评估的需求。例如，在Linux系统中，一个在某一个传统的整体性模块中的主体可以符合于一组进程，这组进程属于单个的应用程序域。

3基于域的隔离

根据TCG和IMA，一个系统的可信度被用对一个已装载的软件组件的测量值（哈希值）来描述。然而，测量的高效性和认证的有效性是这些方法的主要问题。原因有二：需要被测量和追踪的组件太多；不同的软件生产商需要太多的已知友好的哈希值。这就要求，为了信任系统中的一个单个的应用程序，系统中每一个组件都必须被信任；否则认证结果就会是不可信的。

在我们的工作中，我们相信，一个系统的可信度和整体性状态紧密联系在一起，而整体性状态又被描述为施加在系统当中的一组整体性规则。如果任何规则被违反了，都会被检测出来。因此，为了信任一个单个的应用程序域，我们只需要确保系统TCB（可信计算基） ——包括引用监视器和保护目标应用程序的整体性规则——没有被修改。

基于此，我们为整体性保护提出了基于域的隔离原则，这也是描述系统整体性状态，即可信度的标准。我们首先提出了一般的方法来识别高整体性过程，包括系统TCB（TCBs）和域TCB（TCBd），然后为了保护这些高整体性过程，我们制定了安全性规则。系统TCB类似于传统TCB的概念，它可以和作为系统引用监视器的主体一起被识别。把这个概念应用到SELinux，作为系统引用监视器的主体，比如checkpolicy和loading policy属于系统TCB。而且，被用来支持引用监视器的主体，如kernel和initial也应该被包含到系统TCB中。

实际上，除了系统TCB，一个应用程序或者用户空间服务也可以影响整体性，即系统行为。我们提出一个叫做信息域TCB的概念，或者简单一点叫做域TCB（TCBd）。我们假定d是一个信息域，它通过一组相关的主体和客体，来起到某个应用程序或者服务的作用。TCBd由一组在信息域d中的主体和客体组成，它们具有同样级别的安全敏感度。同样级别的安全敏感度的意思是，如果信息可以流向一些主体或者客体，它可以流向域中所有其他主体和客体。也就是说，它们需要同样级别的整体性保护。在识别TCBd之前，我们首先识别信息域d，这
4000
要基于它的主函数和主函数的相关信息流。例如，一个正在运行的web服务器域包括很多主体——比如httpd过程，插件，工具，和其他客体——比如数据文件，配置文件，和日志。

一个客体的整体性，由在这个客体上进行操作的主体的整体性决定。所有依赖于TCBd的主体的客体都被归类为TCB受保护的客体或资源。因此我们需要从一个信息域中识别出所有的TCBd的主体并且确定他们的整体性保证。为了简化这个任务，一个最小的TCBd首先被发现。最小TCBd中的主体如果和其他主体有依赖，这些主体就应该被加入到域TCB中，或者这些依赖应该被解除。基于这些原则，我们首先识别初始TCBd主体，这些主体是信息域d中的主要主体。进一步的，我们通过信息流的转变来找出主体依赖关系，从而发现其他TCBd主体，这就是说，只能够流向或流出初始TCBd主体的主体应该被包含进TCBd中。例如，对于一个web服务器域，httpd是初始化其他web服务器相关程序的主体。因此，httpd就是主要的主体，并且属于TCBd。然后，基于所有流向httpd的可能的信息流，我们识别出其他的主体，比如httpd-suexec，将其加入TCBd。

为了保护被识别出的TCBs和TCBd ，我们建立类似于Clark-Wilson中的原则。Clark-Wilson利用事务处理（TP）来允许信息流从低完整性到高完整性过程。因此，我们也建立过滤器（Filter）的概念。过滤器可以是过程或者是接口，一般是特殊的输入信息通道并且由特定的操作如open()、accept()创建。比如，su进程允许一个低完整性进程（例如，工作人员账户）通过执行psswd进程，被改变到一个高完整性进程（如root），因此passwd可以被视为一个在root特权下运行的进程过滤器。同样，高完整性进程（如httpd管理）通过安全通道（如sshd）可以接受低完整性信息（如网络数据）。因此，sshd可以被当做是高优先级进程过滤器的另一个例子。识别了TCBs，TCBd和过滤器之后，对于信息域d，系统中其他所有主题都被划分为NON-TCB。

定义一：基于域的隔离满足一个信息域d——如果信息流是来自TCBd的；或者信息流来自TCBs，去向TCBd或者TCBd受保护的资源；或者信息流来自NON-TCB，通过过滤器去向TCBd或者TCBd受保护的资源

4 DR@FT设计

DR@FT包含三个主要部分：一个attestee（目标平台），一个attester（认证挑战者），和一个可信机构，如下图所示：

Attestee需要向attester提供它的系统状态信息来让attester验证。这里我们假定一个attestee初始是处在可信系统状态中的。在某个系统行为之后，系统状态变成一个新的状态。

一个在attestee上的认证报告后台进程利用IMA获得新的经过测量的状态信息（第一步），并且生成策略更新（第二步）。这个后台进程然后获得AIK标记的PCR值并且发送给attester。在attester获得并且用来自可信机构的attestee的AIK公钥证书证实了这个信息之后，它通过代码和数据确认来验证attestee的整体性（步骤3），报告进程鉴定（第四步）和策略分析（第五步）。

4.1系统状态和可信需求

定义二：在时间段i一个系统状态是一个元组Ti={TSLi，CDi，Policyi，Filteri，RProcessi）

TSLi：可信主体列表，代表一组高完整性进程，和TCBs、TCBd中的一组主体 相一致

CDi：是一组代码和数据，用来加载主体，

Policyi是当前在attestee上配置的安全策略。

Filteri是一组进程被定义为允许信息流从低完整性进程流向高完整性进程。

RProcessi代表了一个进程的列表，这些进程用来测量，监控和报告当前 的信息。IMA代理和认证报告后台程序就是RProcessi的例子。

根据这个定义，一个系统状态不包括一个特定的应用程序的运行状态，比如它的内存页和cpu上下文（栈和寄存器）。它只代表这一个attestee系统的安全配置或者策略。一个系统状态的改变指示了一个或多个在 中的改变。如果TSLi属于TCBs和TCBd，系统状态Ti就是可信任的；CDi不包含不受信任的代码和数据。Policyi满足基于域的隔离；Filteri属于在基于域的隔离中被定义了的过滤器；RProcessi代码和数据不包含恶意代码和数据并且这些RProcessi进程通过Policyi受到完整性保护，避免不受信任进程的伤害。
正如上面所提到的，我们假定存在一个初始的可信任系统状态T0，通过改变T0中的变量，系统改变到状态T1，T2…Ti，认证目标就是确认是否任意的这些状态都是可信的。

4.2认证程序

Attestee端测量。在attestee端的测量有两种形式，取决于attestee系统改变了多少。

一种情况是，假如TCBs中任意主体被更新了，attestee就必须从系统重启开始被完整的测量，并且attester需要完整的认证它，因为这个主体也许会影响系统RProcess中的主体的整体性，比如测量代理和报告后台程序。重启并且所有的TCBs主体都被测量以后，一个可信的初始系统T0就被建立了。为了完成这个重新测量，attestee测量一个状态Ti并且生成测量列表Mi，这个Mi被加入到TSLi，CDi,Policyi,Filteri和RProcessi的测量中。而且， （哈希函数，如SHA1）被扩展到一个TPM的特定的PCR。

另一种情况，TCBs主体没有更新，而属于TCBd的TSLi或者Filteri主体被更新了，attestee只需要测量装载被改变了的TSL或者filter主体的更新代码和数据，并且生成一个测量列表Mi。这个测量列表的生成，通过被潜在的测量代理所支持的运行时测量来实现。

为了支持两种类型的测量，我们建立了一个测量报告后台程序，用来监控attestee的运行时测量。如果TCBs的运行时测量被改变了，attestee就被要求重启并且用IMA完全测量。测量值之后通过后台程序送到attester。另一方面，只有当TCBd的测量被改变了，被改变了的测量值才被IMA测量并且用报告后台程序获取。很明显，这个后台程序应该被信任，并且被包含在TCBs中。也就是说它的代码和数据需要用整体性策略来保护并且相应的哈希值需要被存储在attester端。

策略更新。为了分析attestee当前的状态是否满足基于域的整体性属性，attester要求获取加载在attestee端的当前安全策略信息。为了提高性能，在DR@FT中，attestee只从最新的被认证的可信状态中生成策略更新，并且将他们发送到attester来认证。为了支持这个机制，我们让认证报告后台程序监控attestee系统上的任何策略更新，并且生成一个更新策略规则列表。

代码和数据验证。

收到测量列表Mi和被AIK标记的PCR之后，attester首先通过重建哈希值并且和PCR值比较来验证测量的整体性。这之后，attester执行分析。特别地，它获取CDi的哈希值并且检查是否他们符合已知友好的指纹。而且，attester需要保证TSLi属于TCBs和TCBd。另外，attester也获取Filteri的哈希值并且确保他们属于定义在attester端的filter列表中。如果这个步骤成功了，attester可以保证attestee端的目标进程中被证明不带任何不可信的代码或数据，并且attester可以处理下一步。否则，attester发送一个合适的认证结果来表示这个情况。

验证报告进程。为了保证收到的测量和被更新的策略规则来自于attestee，attester通过验证attestee中的所有的测量，更新和整体性测量代理进程都是受到整体性保护的来认证它们。也就是说，RProcessi不包含任何不受信任的代码或者数据，并且它的测量是和attester中的PCRs相一致。而且，根据域隔离规则，没有违反整体性的信息从TSLi的主体流向这些进程。

Attester的策略分析。

DR@FT使用基于图的分析方法来分析策略。在这个方法中，一个策略文件第一次被可视化进一个图中，然后这个策略图被用之前定义好的安全模型（如我们的基于域的隔离）分析，并且一个策略违反图被生成。这个方法的主要目标是向attestee提供一个认证结果的语义信息，这样它的系统或者安全管理员可以快速并且直观地获取任何被违反的整体配置。

注意到对每一个认证请求验证所有的安全策略规则会减少高效性，因为一个一个地加载策略图和检查所有的策略规则会耗费大量时间。因此我们需要建立一个高效的方法来分析attestee策略。在我们的方法中，attester存储初始化可信系统状态T0或者最新的可信系统状态Ti的策略，并且它相应的策略图被加载，其中没有任何策略违反。从attestee收到更新的信息后，attester只需要分析这些更新来看是否有新的信息流违反整体性。

发送至attester的认证结果。

如果认证成功，一个新的可信系统状态就被建立了，并且相应的信息被存储在attester端为后续的认证做准备。另一方面，如果认证失败，就有几种可能的认证结果，包括CDi整体性失败，CDi整体性成功，RProcessi未验证，和Policyi失败/成功，和CDi整体性成功，RProcessi被认证，和Policyi失败/成功。为了协助认证配置，attester也发送一个策略违反图给attestee。更进一步，有了这个策略违反图，attester指定attestee的违反级别和可信度，这个在下一节解释。

5 整体性违反分析

正如我们在第一节讨论过的，现存的认证解决方案，如TCG和IMA缺少有表现力的认证结果。DR@FT的认证结果，除了有它们的基于布尔的响应以外，还采用了基于图的策略分析机制，在这个机制中，一个策略违反图可以被构造来识别所有的attestee端的策略违反。我们更进一步地介绍一个建立在排名方案上的风险模型，它给出了一个隐含式，告诉我们已发现的策略违反的严重程度，和如何高效的解决他们。

5.1策略违反图

根据基于域的隔离模型，我们可以发现两种违反路径，直接违反路径和间接违反路径。一个直接违反路径是一个一跳路径，通过这个路径一个信息流可以从低整体性主体去向一个高整体性主体。我们观察到信息流一般都是可传递的。因此，也许会存在一些信息流通过一些其他主体来从低整体性主体传递到高整体性主体。这个多跳路径被称为间接违反路径。所有的属于一个域的直接和间接违反路径，可以为这个域组成一个策略违反图。

定义三：一个域d的策略违反图是一个定向的图

5.2排名策略违反图

为了发现策略违反图更多的特性，并且提高策略违反检测和解决的效率，我们介绍给策略违反图排名的方案。有两个步骤来为策略违反图排名。第一步，在策略违反图中TCBd的主体是基于他们间的依赖关系来排名的。TCBd主体的排名显示了低整体性信息流，从NON-TCB主体到TCBd主体的可达性。第二步，在策略违反图中直接违反路径是基于TCBd主体的排名来评估以指示这些路径的严重程度，这允许低整体性信息到达TCBd主体。排名了的策略违反图对系统管理员来说是很有价值的，因为他们需要评估系统的风险等级，并且提供向导来为高效地解决策略违反选择合适的策略。

TCBd中的主体排名。

我们在策略违反图中的主体排名（SR）的记号是一个标准，这个标准指示了从NON-TCB主体，通过直接或间接违反路径，到达TCBd主体的可能性。我们在这一节介绍的排名方案，采取了一个类似于应用在超文本链接分析系统中的排名分析过程，如Google的PageRank，它利用由网页中的超链接提供的链接结构来测量他们的重要性。

直接违反路径的排名。我们进一步定义路径排名（PR）作为直接违反路径的排名，他是一个反映了违反路径（低完整性信息通过违反路径流到达TCBd主体）的严重性的标准。在策略违反图中，直接违反路径被看做是低完整性数据到TCBd的入口。因此，直接违反路径的排名给系统管理员提供了一个向导，帮助他们为解决被识别出的违反采取合适的防御对策。

5.3评估可信度

假定Pd为一个在策略违反图中所有直接违反路径的集合。完整的排名，可以被认为是一个系统的风险级别，可以被如下计算：

经过计算了的风险级别可以反映一个attestee的可信度。通常风险级别越低表示这个系统的可信度越高。当一个认证成功了，并且没有违反路径被识别，这个被认证的系统的风险级别为0，也就意味着一个attestee有着最高的可信度。另一方面，当一个认证失败了，目标系统的相应的风险级别也被计算了。一个基于这个细粒度的认证结果的可选的服务可以被实现。也就是说，服务提供者向目标系统提供的服务数量，可能会根据目标系统的可信级别来决定。另一方面，一个系统的管理员可以将这个认证结果当做他系统的评估和指导，因为这个定量的应答会给他一个合适的理由来为提高系统可信度采取防护措施。

6实现和评估

6.1认证实现

我们从一个合法的attestee开始，并且为之后的验证为attestee系统做了测量。为了从attester调用一个新的认证请求，认证报告后台程序在attestee中运行，并且监视attestee系统。这个后台程序由两个主线程组成：一个监视并且获取新系统状态的测量，其他的监视和获取attestee的策略更新。后台程序也被测量并且结果可以通过合法attestee获取。因此后台程序的整体性可以之后被attester验证。假如attestee系统状态因为新的软件安装或者策略改变之类的而被更新，一个合适的后台程序线程会自动获取新的测量值，正如4中所讨论的那样。之后，后台程序会基于可信机构所支持的安全机制来将认证信息安全的转移给attester。

在从attestee收到更新后的系统信息后，attester的测量模块通过存储的PCR来检查收到的测量以验证它的完整性。为了分析可能的被修订的attestee策略，策略分析模块被作为一个后台程序建立，它是从一个策略分析引擎移植而来。