可信云计算的实现

可信云计算的实现摘要云计算基础架构使公司能通过按需外包计算来缩减经费。

然而，云计算服务的用户目前无法验证他们数据和运算的保密性及完整性。

为了解决这个问题，我们提出了一个可信云计算平台（TCCP）的设计方案。

TCCP 使基础架构即服务（IaaS）供应商，比如亚马逊云计算平台EC2，能够提供一个封闭箱式操作环境来保证客户虚拟机的保密性操作。

此外，TCCP允许用户去证明IaaS供应商并且在启动虚拟机之前判定服务是否安全。

1.介绍公司可以通过卸载云计算服务的数据和运算来大量减少IT方面的花费。

然而，主要基于突出的安全问题考虑，许多公司并不情愿这么做。

一个最近的研究［2］调查了17个国家的超过500个首席执行官和IT经理，发现尽管有潜在的收益，执行官们“由于害怕安全威胁和丧失对数据及系统的控制，而仍选择相信已存在的内部系统而不是云基础的系统”。

一个最严重的担忧是关于侵犯保密性的可能性。

不论蓄意或者无意，云供应商的雇员都可以篡改或者泄漏一个公司的数据。

此类行为会严重损害此公司的声誉或财务状况。

为避免侵犯保密性，云服务的客户可以诉诸于加密措施。

然而尽管当加密手段在数据存储于供应商之前能有效保护数据，它不能被应用于需要计算数据的服务，因为未加密数据必须留存在要运行计算的主机内存中。

在IaaS云服务中（比如亚马逊云计算平台EC2），供应商替客户管理虚拟机并可以执行任意的计算。

在这些系统中，任何获得主机的授权访问权限者都可以阅读或操控客户的数据。

结果就造成客户不能自主保护他们的虚拟机。

云服务供应商正为保护他们的系统做出实质性的努力，以最小化内部人员的攻击，并加固客户的机密。

比如，他们保护并限制对硬件设施的访问，采取严格的问责和审计程序，并最小化可以访问基础设施的关键部分的工作人员数目[8]。

然而，在供应商后端管理软件系统的内部人员最终仍然拥有访问客户虚拟机的的技术手段。

因此，目前迫切需要一个能够保证计算保密性和完整性的技术方案，此方案要用一种能被服务的客户验证的方式。

传统的可信云计算平台比如Terra[4]采用一种令人信服的方法。

比如，Terra能够防止物理主机的机主计算时受到监测和干扰，Terra也提供一个远程的认证能力以保证远程方能够预先判定主机是否能安全地运行计算。

这种机制可靠地检测了主机是否正在运行一个远程方可以信任的平台。

这些平台可以有效地保障运行在单独主机上的虚拟机。

然而，许多供应商运行的数据中心包含了几百个虚拟机，并且一个客户的虚拟机可以被动态地预定运行于其中任意一台上。

供应商后端的这种复杂性和不透明性造成了传统可信平台无法解决的漏洞。

本文提出了一个可信云计算平台(TCCP)来保证外包给IaaS服务的运算的保密性和完整性。

TCCP为客户虚拟机提供了封闭箱式操作环境的抽象描述，保证没有云供应商的授权管理者可以监控或篡改它的内容。

除此之外，在要求服务启动虚拟机之前，TCCP允许客户可靠并远程地判定服务后台是否正在运行一个可信的TCCP。

这种能力把认证的概念扩展到了整个系统，因此也允许客户去验证运算是否将安全运行。

本文中我们将展示如何利用可信计算技术的进步来设计TCCP。

第二章介绍了这些技术并且描述了IaaS服务的结构。

第三章陈述了我们的TCCP设计。

尽管我们至今还没有一个可工作的TCCP雏形，此设计已经细致到足够我们相信，基于此讨论的方案是可实现的。

2.背景2.1基础架构即服务今天，无数云供应商在软件堆栈的不同层面提供服务。

在低层，IaaS供应商比如亚马逊，Flexiscale和GoGrid允许他们的客户访问被供应商管理的整个虚拟机。

客户，和系统的使用者，负责提供在虚拟机内部运行的整个软件堆栈。

在高层，软件即服务（SaaS）系统比如谷歌Apps提供完整的线上应用而不是可以直接被用户执行。

在软件堆栈高层的服务上，保证运算保密性的困难有所增加。

因为服务自身提供并且运行能够直接操控客户数据的软件（例如Google Docs）。

本文中我们聚焦保障客户虚拟机更易控制的低层IaaS云供应商。

当只了解商务IaaS服务内部组织很小一部分的时候，我们描述（并将我们的方案基于）Eucalyptus[6]，一种能提供类似于EC2的界面的开源IaaS平台。

图1展现了一个非常简单的Eucalyptus结构。

此系统管理了一个或多个簇，每个簇的节点运行了一个针对主机客户虚拟机的虚拟机检测仪（典型的有Xen）。

Eucalyptus设计了一套组件来管理簇。

为了简化，在我们的描述中将所有组件聚集进一个单独的云管理器（CM）来处理一个单独的簇。

建议读者参考[6]以获得更多细节。

从用户的观点，Eucalyptus提供了一个网络服务界面来启动、管理和终止虚拟机。

虚拟机由从CM载入的虚拟机映像（VMI）来启动。

一旦虚拟机启动，用户可以用普通工具比如ssh来登录进来。

除了面向每个用户的界面，CM也输出可以被用来执行管理任务的服务，比如增加和移除VMI或用户。

Xen支持动态迁移，允许虚拟机在仍运行时转移物理主机，用一种对用户透明的方式。

迁移有利于簇内的资源整合或负载均衡。

2.2攻击模型被授权控制后台的云供应商系统管理员为了访问客户虚拟机的内存可以发动很多攻击。

有了每台机器的根用户权限，系统管理员可以安装或执行各种软件以进行攻击。

例如，如果Xen在后台使用，Xenaccess[7]允许系统管理员去运行一个可以在运行时直接访问虚拟机内存内容的Dom0中的用户水平的程序。

而且，因为有对机器的物理访问，系统管理员可以发动更多的复杂攻击，比如冷启动攻击甚至篡改硬件。

在目前的IaaS供应商中，我们可以合理地考虑到没有任何单人能累计获得所有这些权限。

此外，供应商已经部署了严格的安全设备、有限的访问控制政策和监督机制来保护硬件的物理完整性。

因此，我们假设，通过强制的安全边界，供应商自身可以防止那些要求对机器进行物理访问的攻击。

不过，系统管理员在簇的机器上管理他们运行的软件需要获得授权许可。

因为目前并不精确地知道现在IaaS供应商的实际情况，我们在攻击模型里假设系统管理员可以利用根用户权限在任何时间远程登录进任何机器。

针对某一运行客户虚拟机的节点，系统管理员唯一可以进行物理访问的方式是把这个虚拟机移到她控制之下的、位于IaaS安全边界范围外的机器上。

因此，TCCP必须能：1）把虚拟机执行限制在边界内；2）保证在任意点有根用户权限的、远程登录到一个能操控虚拟机的机器上的系统管理员都不能访问虚拟机的内存。

2.3可信计算可信计算组织（TCG）[10]提出了一系列硬件和软件技术来确保可信平台的建设。

特别地，TCG提出了一个针对与商品硬件捆绑在一起的可信平台模块（TPM）芯片的设计标准。

TPM包含了一个可以唯一地标识出TPM（因此标识出物理主机）的担保私人密钥（EK），和一些不能修改的密码函数。

各个制造商签署相应的公共钥匙以保证芯片的正确性和钥匙的有效性。

可信平台[1,4,5,9]利用了TPM芯片的特点来确保远程认证。

机制工作如下：启动时主机计算出一个测量表ML，表由包含在启动序列里的软件的一个序列的散列值组成，叫BIOS，即引导启动程序，用软件来实现此平台。

ML安全地存储在主机的TPM里。

远程方用一个随机数n U来测试在主机上运行的平台，以验证此平台的工作。

平台要求本地TPM创建一个同时包含ML和n U的信息，由TPM的私人EK加密。

主机将信息发送回可以用EK的相应公共钥匙解密信息的远程方，从而验证主机。

通过检验随机数相符合并且ML对应于一个可信的配置，远程方可以可靠地验证不可信主机上的平台。

类似Terra[4]这样的可信平台安装了一个只能执行封闭箱式操作环境的轻薄VMM，意味着在顶端运行的客户虚拟机不能被拥有主机上所有权限的用户监测或修改。

VMM在机器重启前保证它自身的完整性。

因此，远程方可以通过验证主机上运行的平台来验证一个可信的VMM安装正在运行，并因此确定客户虚拟机上她运行的运算是安全的。

鉴于传统可信平台可以保护单独主机上的运算，保护IaaS服务的一个很自然的方法是把平台部署在服务后台的每一个节点上（见图1）。

然而这种方法并不充分：系统管理员可以把客户虚拟机移到一个不运行平台的节点上，当虚拟机启动时（通过操控CM），或者在虚拟机执行时（通过迁移）。

结果就是，平台的认证机制不能保证远程方获得的测量表ML对应于实际的、虚拟机正在或将要在其上运行的主机的配置。

因此，TCCP需要提供远程认证来保证平台在后台处的安全属性的不变性。

3.可信云计算平台我们通过把可信平台的概念扩展到整个IaaS后台来描述提供封闭箱式操作环境的可信云计算平台（TCCP）。

TCCP保证用户虚拟机的保密性和完整性，并且允许用户预先决定IaaS是否强制要求这些属性。

下一节概述了TCCP，之后3.2节给出了详细的设计。

3.1概述TCCP扩增了现今的IaaS后台，在不改变本质结构的情况下运行封闭箱式语义（图2）。

TCCP可信计算基础包括两个方面：可信虚拟机检测仪(TVMM)和可信协调程序（TC）。

后台的每一个节点都运行了一台监测客户虚拟机的TVMM，并阻止有访问权限的用户检测或修改数据。

随时间变化TVMM保护了自身的完整性并与TCCP协议相符合。

节点嵌入了一个认证的TPM芯片并且必须经由安全的启动过程来安装TVMM。

由于篇幅限制我们不展开讨论TVMM设计的细节，建议读者参考[5]以了解一个能被用来建立TVMM的结构，此TVMM强制执行本地封闭箱式保护来对抗恶意的系统管理员。

TC管理一系列能安全运行客户虚拟机的节点。

我们把此类节点叫做可信节点。

一个节点必须位于安全边界内并且运行TVMM才能叫做可信。

为满足这些条件，TC保留了一份位于安全边界内的节点的记录，并且通过验证节点的平台来验证节点正在运行可信的TVMM。

TC能够应对一些事件的发生，比如增减簇中节点或者关停节点以供维修或更新。

用户可以通过验证TC来验证是否IaaS服务保障了运算。

为保障虚拟机，每台在节点上运行的TVMM都和TC合作以：1)限制虚拟机在可信节点上运行，2）保护虚拟机在网络传输过程中抵制监控或修改。

要求此类保护的关键时刻有：启动、迁移虚拟机的操作。

为保障这些操作，TCCP明确了一些协议（见3.2节）。

由于空间限制我们就不详述其他的关键操作了（比如Xen 允许的暂停／继续）。

假设外部可信实体（ETE）运行TC，并安全地更新提供给TC的、关于一系列部署在IaaS边界内的节点，及可信配置的信息。

最重要的是，管理IaaS的系统管理员没有ETE的内部访问权限，因此也不能篡改TC。

我们设想ETE应该由没动机与IaaS供应商串通的第三方留存，比如，类似于今天像VeriSign这样的证书颁发机构的独立公司。