引言
基 础 设 施 即 服 务 (IaaS,infrastructure as aservice)作为云服务的最底层,利用虚拟化技术将基础软硬件进行封装,为租户提供弹性和透明的计算存储服务.目前包括亚马逊在内的许多IT厂商已经向租户提供IaaS服务.
随着IaaS的发展,其安全问题也越发突出:共享的基础软硬件资源访问不受控制、服务提供商的权限不受控制、设计缺陷导致的安全漏洞等,这些问题导致租户资源的安全完整性无法得到保障;同时,IaaS对外隐藏内部操作,资源状态对外不可见,更加深了租户对自身资源数据的安全性忧虑.
针对上述问题,国内外学者进行了一系列研究.Santos针对租户对资源数据和执行环境的完整性要求,提出TCCP可信云计算框架,该框架对节点的行为进行约束,保证VM只在信任的节点上运行.Khan基于Eucalyptus平台设计了3个协议,实现VM安全注册和启动,并在迁移之前实现对目的节点的验证.文献[6,7]从服务提供商的角度出发,通过加密的手段保证租户资源在启动之初的静态完整性.但是这些方案在资源运行过程中缺乏对资源的动态度量和验证,云服务商无法向租户提供其资源的完整性证明.
Azad针对IaaS底层物理虚拟机平台的安全度量问题,提出HyperSentry动态度量框架,实现对VM的动态度量和验证,但是该方案缺乏有效的完整性度量验证协议.Bertholon沿用文献[5,7]中的思想,着重从用户的角度设计可信云保证IaaS资源的完整性.但是该方案中服务提供商的权限过大,导致云服务特权管理员存在操纵验证结果的可能;同时,文章也缺乏对协议的安全性证明.
安全协议设计本身就存在困难,同时由于运行环境的复杂性和并发性以及攻击者能力的不确定性,导致上述协议可能存在潜在的安全问题.形式化验证方法以其严密的逻辑分析能力能够发现协议存在的缺陷和安全问题.SVO逻辑(Syverson P F,Van Oorschot P C)作为模态逻辑中的佼佼者,目前已经广泛应用于安全通信协议、电子商务协议的形式化分析.
本文针对IaaS环境缺乏动态度量和验证的现状,借鉴HyperSentry和文献[14]底层动态度量方案,设计了交互协议使租户主动发起对自身资源的度量和验证,增强IaaS资源安全完整状态的可见性,利用SVO逻辑对所设计的协议进行分析和证明.
1 完整性度量协议设计
1.1 协议交互实体
本协议基于Eucalyptus框架进行设计,Eu-calyptus是一种流行的开源IaaS系统管理平台,如图1所示,其具备模块化的思想构建.主要组件包括:云控制器CLC、集群控制器CC、执行节点Node等.本文提出的度量协议包含3类Eucalyptus节点:CLC、CC、Node,加上租户和可信第三方TC,一共5个协议交互实体.下面将详细介绍CLC、CC、Node和TC这4个实体.
CLC是租户和管理员进入云的主要入口,CC负责管理整个虚拟局域网络,本文忽略CLC与CC的交互,将CLC和CC统称CLC,协议中,CLC负责接受租户的度量验证请求,并将请求分发到对应的Node节点.
Node作为VM运行的物理节点,通过虚拟机监控器和管理域控制租户VM的启动、迁移、中断、停止等全部生命活动;Node节点安全可信的前提是Node上运行一个可信软件模块TVMM,TVMM与底层可信平台模块TPM安全交互,完成对Node节点和租户VM的完整性度量和度量值提交,详见.Node采用“迟启动”的方式,在节点启动前保 证 可 信 软 件 模 块TVMM的 可 信 启 动.该TVMM在节点的全程生命周期内必须正常运行.如果TVMM不能完成可信启动或者是受到攻击篡改,则TC通过协议认证部分能够检测到TVMM的可信状态从而判定Node节点是否安全可信.
TC作为可信的第三方实体,不与协议中的任何实体“合谋”,被协议中其他实体(租户、云服务商等)所信任.TC在协议中作为第三方可信实体对度量值进行可信验证和结果反馈,1)TC与目的Node节点上的TVMM进行安全交互,通过分析TVMM是否安全运行从而判定Node节点是否可信,2)TC对Node节点提交的度量值进行分析和验证,并将验证结果生成可信报告反馈给协议发起方(即租户).通过引入TC,将协议的度量和验证分开,增加验证的可信性,使得云服务商和云管理员无法操纵验证结果,提高协议过程的安全性.
本文要求所有交互实体必需配置可信密码硬件TPM(除了对租户没有要求),TPM实现度量值的安全存储,提供绑定的加密密钥BK和身份证明密钥AIK,并在完整性度量协议里对平台证明信息进行签名.
完整性度量协议所使用的密钥均是TPM直接或间接产生的,节点Node、CLC以及可信第三方TC在协议中均使用两种非对称密钥:AIK和BK.本协议严格遵循TCG的密钥规范,使用AIK作为TPM身份证明密钥对TPM内部数据进行签名;BK作为实体绑定密钥,实现会话通道的加密和部分TPM外部数据的签名.租户虽然没有AIK和BK,但是具有CA签名的一对公私钥,我们也将该密钥称之为BK.AIK和BK的公钥以证书形式可以被其他节点或者实体访问,两类证书经过CA签名颁发,被认为是可信的.
1.2 协议过程
本文提出的协议允许租户主动发起对运行环境安全性和资源数据完整性的度量和验证(见图2).因此,协议必须完成以下目标:
目标1 能够验证资源数据执行环境的可信性(即证明Node节点是否运行安全的TVMM);
目标2 能够度量租户资源的完整性并将可信的验证结果反馈给租户.
该协议由租户发起,经过一系列的操作交互之后,由TC反馈给租户资源数据的完整性报告,其详细过程如下:
M1:User→ CLC:{{{N1,UserID,MLis-tRequest(m1,m2,…)}BK-1User}BKpubTC,Node}BKCLC
外部租户发起对VM执行环境和资源完整性的度量:外部租户产生一个随机数、租户ID、度量的组件列表MListRequest(m1,m2,…),将这些数据用BK私钥签名后,利用TC的公钥加密,保证只有TC能够看到这些请求.将加密的度量请求与Node节点名称通过CLC的公钥加密后传给CLC.
M2:CLC → Node:{{{N1,UserID,MLis-tRequest(m1,m2,…)}BK-1User}BKTC,TC}BKNode
CLC将接收到的度量请求数据并解密后,得知目的节点的名字为Node,需要将度量请求分发路由到节点Node,于是加上TC的名称一起用Node公钥加密后传送给Node节点.
M3:Node→ TC:{{{N1,UserID,MLis-tRequest(m1,m2,…)}BK-1User}BKTC,TC}BKNode,{{N2,PCR1~kNode}AIK-1Node}BKTC
Node节点接收到CLC转发而来的数据,得知需要向TC提交平台证明报告,开始和TC进行交互.Node节点将User的签名加密过的请求数据与自身平台证明信息一起发送给TC.
M4:TC → Node:{{{N3,UserID,MLis-tRequest(m1,m2,…)}BK-1TC}BKTC
TC接收到Node节点发送的数据,解密验证签名,首先得到User的度量验证请求,然后验证Node节点平台配置,如果平台配置正确(TVMM成功启动)则向Node节点发出度量命令,度量租户VM相关组件MListRequest(m1,m2,…);如果Node配置有误,则TC直接向租户反馈验证失败信息.
M5:Node→TC:{{MListResponse(m1,m2,…)}BK-1Node,N2,N3}BKTC
Node根据TC要求,将对应组件度量值经过签名后发送给TC进行完整性校验.
M6:TC→User:{{N1,Request}BK-1TC}BKUser
TC解密M5中提交的度量结果,首先通过随机数N2、N3验证报告的新鲜性,然后通过Node BK的私钥验证报告的真实性,将报告值取出后,与注册阶段注册过的组件完整性参考值进行比对.最后将随机数N1与验证结果以及附加验证信息签名并加密后反馈给User.至此,完整性度量协议完成.
上述的协议过程必须完成目标1和目标2.其中完成目标1需要确保Node节点平台证据的真实性和新鲜性;而目标2需要确保组件度量值的真实性和新鲜性;同时目标1和目标2的完成都需要确保反馈结果的真实性和新鲜性.接下来将对协议安全目标进行验证.
2 协议安全性证明
协议对安全性、完备性要求很高,SVO逻辑基于作为一种广泛使用的形式化方法能够通过严格的逻辑推理有效验证协议的安全性和完备性.本文采用SVO逻辑对完整性度量协议进行安全性、完备性证明.
2.1 SVO逻辑
在SVO逻辑的推理中需要首先给出协议的初始化假设集Ω,即用SVO逻辑语言表示出主体的初始信念、接收到的消息和对消息的理解和解释;然后给出协议可能或者应该达到的目标集Γ,最后通过利用推理规则和公理对假设和协议步骤进行推导,判定协议能否达到预期目标.
SVO逻辑总共有20条公理,下面列出本文过程中需要使用的一些推理规则和公理:
P0:Pbelieves PKσ(Q,K)∧Preceived{X}k-1? Pbelieves(Qsaid X),PKσ(Q,K)表示K是主体Q的数字签名验证密钥.如果主体P收到密钥K-1签名的消息,就可以确定发送者是Q.
P1:Preceived{ }Xk∧Phas K-1?PreceivedX如果主体P收到公钥K加密的消息{X}K,且P拥有私钥K-1,那么P就能收到消息X.
P2:Preceived(X1,…,Xn)?Preceived X
P3:Pbelieves(Psees X)?Pbelieves(PseesX)F(X)表示消息X的函数.
P4:Preceived F(X)∧Pbelieves(Psees X)?Pbelieve(Preceived F(X))
P5:P believe PKσ(Q,K)∧P received X∧SV(X,K,Y)?Pbelieve(Qsaid Y).表明P相信K是Q的签名密钥,且P收到了消息X,同时用密钥K可以验证X是Y的签名,那么P相信Q说过Y.
P6:fresh(Xi)?fresh(X1,…,Xn)
P7:fresh(X1,…,Xn)?fresh(F(X1,…,Xn))
P8:fresh(X)∧Psaid X?Psays X
P9:fresh(X)∧Psaid X?Psaid X.
2.2 协议证明
协议证明之前需要首先对协议的运行环境、实体和消息做出以下合理假设:所有交互实体在协议运行之前通过信任的CA能够得到其他实体的AIK和BK公钥证书,因此能够提前确信实体对应的AIK和BK的公钥;实体能够确信自己产生的随机数的新鲜性,假设具体如下:
A0:协议的运行环境是不安全的
A1:每个主体的公钥是公开的
A2:每个主体的私钥仅为其所知
A3:每个主体都相信自己产生的随机数的新鲜性,即User,Node和TC分别相信N1,N2和N3的新鲜性.
本文将完整性度量协议目标细化为以下5个子目标,并分别进行证明,过程如下:
G1:TC believes(User said(N1,UserID,MListReq-uest)),该目标表明TC确信度量请求的发起者是User.
证由M3,P2,A2和P1得到
TC received(N1,UserID,MlistRequest)BK-1user,该式 利 用 公 理P0得 到TC believes(User said(N1,UserID,MlistRequest),G1得证.
G2:TC believes(Node said(PCR1-knode)),该目标表明TC确信平台配置信息的发送者是节点Node.
证由M3,P2,A2和P1得 到TC received(N2,PCR1-knode)AIK-1node,该式利用公理P0得到TCbelieves(Node said(PCR1-knode)),G2得证.
G3:TC believes(Node said(MlistResponse))该目标表明TC相信租户VM组件的度量值是真实的,是由TVMM签名过的.
证由M5、A2、P2和P1得 到TC received(MlistResponse)AIK-1node,该式通过公理P0得到TCbelieves(Node said(MlistResponse)),G3得证.
G4:TC believes fresh(MListResponse)目标表明TC确信Node的可信报告是新鲜的.
证由M5和P6和P7得到G4,得证.
G5:User believes(TC Says N1,{ }Result),该目标表明租户相信VM的反馈信息的真实性和时效性.即租户相信反馈结果来自于信任的第三方TC,且返回的结果是新鲜的.
证由M6,P2和A2得到User believes{N1,Result}BK-1TC,该式利用通过P0和A1得到Userbelieves(TC Said{N1,Result}),该式与A3通过P6和P8得到User believes(TC Says{N1,result}),G5得证.
上述过程表明,在TVMM安全可靠地遵循协议且按照协议与底层TPM硬件与交互执行动态度量,而IaaS服务提供商和租户完全信任TC的条件下,该协议是安全有效的.G1成功证明TC能够判定度量请求来自于真实的租户;G2,G3成功证明TC能够判定Node节点提交平台配置属性是合法的(即成功运行有TVMM),并且TC相信租户VM的执行环境度量值来源是真实的,G5证明租户得到的反馈结果是来自于信任的第三方实体TC.最后G4,G5能够判定协议传送的关键数据是新鲜的,能够有效抵抗重放攻击.租户通过自身发起的动态度量请求,能够有效授权TC对VM执行环境和组件完整性进行度量和验证.租户通过TC反馈信息获知VM执行环境的可信状况(目标1)并得到其定制组件的完整性状况(目标2).
通过SVO逻辑分析,本文面向租户的完整性度量协议能够满足1.2节提出的两个目标:即对执行环境的可信认证和对定制组件的完整性验证.同时本协议能够保持会话的新鲜性、机密性、完整性等,有效抵御重放攻击、假冒攻击等多种形式的攻击.
3 实验
针对面向租户资源的完整性度量协议的安全性和有效性验证,本文开发原型系统对协议的抗攻击性和性能进行了实验验证.
3.1 实验环境
本研究以Eucalyptus云服务平台为基础搭建协议验证平台.本实验环境为:4台配有Intel E5-2620 6核CPU、16GB RAM的 国 产 服 务 器 作 为CLC、2个NC和TC(实验将CLC和CC作为一个节点),1台配有Intel Corei3-550CPU、2.0GB内存的HP台式机作为租户客户端.本实验使用的操作系统是WindowsXP和Ubuntu12.04Server,虚拟机监控器采用的是Xen4.3,IaaS管理平台选用的是Eucalyptus3.1.
本文借鉴HyperSentry的度量框架,如图3所示,利用TVMM对租户VM执行度量,TVMM受到SMI handler安全保护,而SMI handler自身存储在SRAM中,受到主板的硬件保护.SMI han-dler和物理TPM一起作为Node节 点的可 信基TCB,在Node启动之初,TCB通过“迟启动”的方式把信任传递到TVMM.TVMM安全启动并正常工作,为协议执行提供基础.当协议执行时,租户授权TC通过IPMI通道触发TVMM对租户VM的度量,并通过TVMM与TPM的安全交互,将度量值迭代存储到TPM的寄存器中.
协议验证平台搭建完成之后,通过模拟各种攻击方式对协议实施攻击,验证协议能否真实向租户展示其资源的完整性.同时针对协议的性能问题,实验得出了协议的平均时间消耗,并做出了相应分析。
3.2 协议实验结果
3.2.1 安全性分析
为了验证完整性度量协议能否抵御目前常见的攻击,我们模拟假冒攻击、重放攻击、信息伪造3种攻击手段.攻击的前提假设是TC、TPM是安全可信的,同时SMI handler由于受到SRAM的保护,不会受到篡改.
本实验通过以下攻击方式对协议进行攻击实验:
1)假冒攻击:攻击者冒充物理节点向TC提交完整性报告;攻击者冒充TC向租户反馈错误的信息(比如租户资源完整性已经受到破坏,但是攻击者冒充TC向租户反馈结果表明其资源完整性没有受到破坏);2)重放攻击:假设节点被攻击者控制,重复提交过去生成的正确的组件度量值,用以获取TC的信任;3)信息伪造:攻击者通过篡改Node提交的可信报告,该攻击可能导致TC验证错误.
攻击效果如表1所示,1)当攻击者冒充Node节点和可信第三方实体在协议中发送消息时,由于交互之前需要通过验证签名验证对方实体的身份,因此,能够区分真实协议实体和假冒实体;2)重放攻击主要针对Node节点重复发送度量值的情况,假设攻击者能够获取完整的协议交互的消息,攻击者通过重复提交度量值试图获取TC的信任,但是TC在每次度量验证时产生一个随机数N3,能够利用N3校验提交的度量值的新鲜性,防止重放攻击;3)攻击者获取度量值,试图篡改度量值并发送给TC,但是由于消息加密,TC收到的是一个不能解密的消息,因此,TC能够判定发送的消息受到了篡改.
针对上述3类攻击,租户发起度量、Node节点执行度量到和TC验证度量值等过程,协议最终能够向租户反馈其资源的真实完整性,如图4所示,针对上述三类攻击,TC的可信报告都正确显示出组件是否受到篡改或者是执行环境Node节点是否可信;同时,如图5所示,租户能够通过TC反馈结果中附加的相关日志文件,能够查看其资源的度量、验证信息,提高租户对自身资源完整状态的可见性.
通过上述实验可得,完整性度量协议能够抵御常见的假冒攻击、重放攻击和信息篡改等攻击方式.协议在受攻击的情况下,能够向租户如实报告租户资源的完整性状态,提高租户对自身资源完整状态的可见性.
3.2.2 性能分析
本文提出的协议允许租户对IaaS资源的完整性进行校验,从租户发起请求到接收反馈信息的时间消耗关系到租户的使用体验.因此,本文需要验证租户提出请求到接受反馈结果的时间消耗.由于租户可以对VM组件进行选择性的度量(度量组件包括中断表、超级调用表、VM系统敏感数据等),为了实验方便,我们在度量测试时,选择最大开销的情况.实验结果如图6所示.
根据图6,租户从发起度量验证请求到接收到反馈结果,其平均时间消耗为864.2ms.我们分析其时间主要消耗在对Node节点的平台度量、对VM组件的度量以及交互证明的执行,并且完整性度量协议时耗随度量组件的个数增加而增加.实验度量组件采取最大开销的情况,因此864.2ms可以作为完整性度量协议的时间上限,租户从发起请求到接收到反馈结果,其时间消耗不会超过864.2ms,可以认为不会影响租户体验.
4 结论
针对IaaS租户对自身资源缺乏度量和验证的现状,本文将可信度量引入到IaaS环境,并设计面向租户的IaaS完整性校验协议,使租户主动发起对自身资源的完整性验证,增强租户对资源完整状态的可见性.文章通过SVO逻辑对协议的安全性、完备性进行了证明,并搭建实验平台对协议的抗攻击性和性能进行了实验.分析和实验表明,协议能够抵御常见的假冒攻击、重放攻击和篡改攻击等攻击模式,能向租户反馈其资源完整性的真实状态;同时,协议时间消耗在可接受范围内,对租户的使用体验影响不大.【图略】
