验证花刺代理验证

收稿日期:20071109基金项目:国家自然科学基金项目资助(60803150,60573036);国家自然科学基金重点项目资助(60633020);高等学校学科创新引智计划项目资助(B08038)作者简介:张志勇(1975),男,河南科技大学副教授,西安电子科技大学博士研究生,Email:xidianzzy@126.
com.
支持验证代理方的远程证明模型及其安全协议张志勇1,2,裴庆祺1,杨林3,马建峰1(1.
西安电子科技大学计算机网络与信息安全教育部重点实验室,陕西西安710071;2.
河南科技大学电子信息工程学院,河南洛阳471003;3.
中国电子设备系统工程公司研究所,北京100039)摘要:针对现有的远程证明模型中存在的终端平台基本配置细节与安全属性特征等隐私的保护问题,提出了一种具有委托模式的支持验证代理方的远程证明模型(AP2RA)及其安全协议.
引入可信第3方接受验证方的委托,实施终端软硬件的完整性和安全性证明,并可信地报告平台当前状态的布尔值,改进了基于验证双方的远程证明模式,有效地保护了被验证方的平台隐私.
与已有的方案相比,该方案能够抵抗被验证方消息重放攻击和共谋攻击,以及追踪对验证代理方(APP)发起攻击的终端平台,适用于可信网络中的资源分发与信息共享等环境.
关键词:可信计算;远程证明;隐私保护;安全协议中图分类号:TP309文献标识码:A文章编号:10012400(2009)01005806犃狋狋犲狊狋犪狋犻狅狀狆狉狅狓狔狆犪狉狋狔狊狌狆狆狅狉狋犲犱狉犲犿狅狋犲犪狋狋犲狊狋犪狋犻狅狀犿狅犱犲犾犪狀犱犻狋狊狊犲犮狌狉犲狆狉狅狋狅犮狅犾犣犎犃犖犌犣犺犻狔狅狀犵1,2,犘犈犐犙犻狀犵狇犻1,犢犃犖犌犔犻狀3,犕犃犑犻犪狀犳犲狀犵1(1.
MinistryofEducationKeyLab.
ofComputerNetworkandInformationSecurity,XidianUniv.
,Xian710071,China;2.
Electron.
Inf.
Eng.
Coll.
,HenanUniv.
ofSci.
&Technol.
,Luoyang471003,China;3.
TheResearchInst.
,ChinaElectron.
Equ.
&Sys.
Eng.
Corp,Beijing100039,China)犃犫狊狋狉犪犮狋:Sinceexistingremoteattestationmodelsleadtoanissueofprivacyprotectionofbasicconfigurationdetailsandsecurityattributefeaturesoftheterminalplatform,anAttestationProxyPartysupportedRemoteAttestation(abbr.
AP2RA)modelanditssecureprotocol,whichhaveadelegationmode,arepresented.
TheTrustedThirdPartyisintroducedtoacceptanattestiondelegationfromtheAttestorParty,implementsintegrityandsecurityattestationofhardwareandsoftwareontheterminal,andfurthertrustworthilyreportsthebooleanvalueofthecurrentplatformstatus,thusimprovingtheremoteattestationmodelbasedontwoparties,aswellaseffectivlyprotectingtheplatformprivacyoftheAttestedParty.
Moreover,comparedwithotherapproaches,theproposedapproachiscapableofresistingagainstthemessagereplayattackandcollusionattackfromtheAttestedPartytogetherwiththetracingterminalplatformsponsoringattackonAPP,sothatitissuitableforresourcedisseminationandinformationsharinginthetrustednetwork.
犓犲狔犠狅狉犱狊:trustedcomputing;remoteattestation;privacyprotection;secureprotocol远程证明(RA)[1]作为可信计算中的关键技术,旨在实现终端平台依赖可信芯片模块,通过本地度量忠实地向外界报告自身的完整性状态,使得远程实体能够确信平台的软硬件组件在按照预期的方式运行,没有被篡改和攻陷.
目前,RA国内外研究主要集中在度量方式和验证机制上,如基于二进制代码度量的TCG方案[1]、基于平台属性[23]、软件语义或行为[46]的远程证明等,以及设计高安全性的RA相关协议[3,7].
然而,这些仅支持验证双方参与的RA必然会导致平台隐私的暴露问题,其中包括平台身份隐私和基本配置隐私两2009年2月第36卷第1期西安电子科技大学学报(自然科学版)犑犗犝犚犖犃犔犗犉犡犐犇犐犃犖犝犖犐犞犈犚犛犐犜犢Feb.
2009Vol.
36No.
1个方面,前者TCG已通过可信第3方PrivacyCA和DAA协议[7]加以解决,而后者使得敌手能够结合平台软硬件配置细节、安全属性以及上层应用运行时的软件行为特征,发起更广泛、更具有针对性的攻击[23,8].
文献[8]综述性地提出了几种RA模型,如基于验证双方的RA,基于3方的"拉"模式,"推"模式和委托模式等,其中后两种模式能够有效地保护平台配置隐私,但文中并未深入探讨一个具有委托模式的RA模型及其安全协议,而是基于Web验证服务采用"推"模式和扩展平台配置寄存器机制保护平台隐私.
笔者提出了具有委托模式的支持可信第3方验证的AP2RA模型与安全协议,并给出了与其他方案在机制和功能性方面的分析对比.
图1支持验证代理方的远程证明模型1形式化的远程证明模型1.
1AP2RA模型基本框架针对现有的RA模型存在着平台配置信息和安全属性等隐私的暴露问题,AP2RA通过引入可信第3方———验证代理方(APP)改进现有的远程证明模式,由验证方(AtorP)发起验证请求,与被验证方(AtedP)协商认可一个APP,然后APP和AtedP之间对被验证对象(AO)进行RA质询应答,最后由APP验证组件来验证平台的完整性和安全性,并将平台(或AO)状态的布尔值结果,即是否完整性保持和安全属性满足基本策略等,作为RA报告传递给AtorP.
这里AtorP并没有得到被验证方的平台配置细节和安全属性特征,有效地解决了被验证方的平台隐私保护问题,同时也提高了验证系统的可生存性.
一旦验证方被攻陷,APP仍然可以有效地提供远程证明服务,并安全地保持验证的结果.
AP2RA模型如图1所示.
1.
2基本实体与组件AP2RA模型主要由AtedP,AtorP和APP等3个基本实体构成,它们的功能性定义如下:被验证方RA过程的受动者,在可信计算环境下,它通常为终端平台本身及其内部软硬件组件、固件等,利用可信芯片模块及上层软件栈完成可信度量,然后向外界实体可信地报告度量值.
验证方RA过程的发起者,通常为远端的验证平台.
AtorP根据应用需求发起验证请求,并借助于APP的RA报告及应用策略进行访问决策.
验证代理方RA过程的施动者,是验证双方认可的可信第3方.
APP接受AtedP发送的可信度量值,并依据完整性参考值和基本安全策略验证当前终端平台或AO的完整性和安全性,并向AtorP提供平台状态报告.
3个实体中涉及以下基本组件,它们属于逻辑上的功能性组件,具体可实现为一个或多个硬件组件、软件代码或服务程序等.
被验证对象RA中被验证的固件、硬件组件、软件代码或进程(组)等,它们构成终端平台的软硬件环境,例如BIOS,OSLoader,OSKernel及应用程序等.
可信度量组件(TMC)AtedP平台中提供可信度量机制的软件代码或硬件芯片.
这里的可信度量模式采用基于二进制代码的完整性度量和获取安全属性相结合机制,前者利用散列算法来实施,后者对于软件代码及应用程序可通过访问平台特征数据、基于安全漏洞扫描、基于软件语义的对象属性检测[4]等机制获取安全属性.
在OSKernel加载前,即BIOSOSLoaderOSKernel信任链建立的安全启动过程中,TMC主要功能为完整性度量,由BIOS中的CRTM和可信芯片模块完成;在OSKernel加载之后,TMC的功能为对OS服务程序和应用程序的完整性度量和安全评估.
验证功能组件(AFC)RA中提供可信验证机制的软硬件组件或程序等,通过访问完整性参考值和基本安全策略数据库,与AtedP提供的可信度量值进行校验,判定系统当前状态,并将验证结果作为RA报告发送给AtorP.
验证发起组件(ASC)RA中发起证明请求的组件,通常为位于AtorP端的一段应用代码,根据应用需95第1期张志勇等:支持验证代理方的远程证明模型及其安全协议求来激活RA会话.
应用决策组件(ADC)AtorP中提供应用决策机制的软硬件组件,结合APP的RA报告和其他应用级安全策略判定AtedP是否通过平台或AO的远程证明,进行访问控制.
1.
3证明模式形式化定义基于BNF形式化定义AP2RA证明模式中的主要操作如下:∷="""[[""]]"[""][],∷={},∷=⊥||→|Δ|∧|Δ∧|MR幑幐AC||∨|∨|platformStatus幑幐帯帯帯帯帯AR|,∷={||}.
定义1(APP协商)AtedP和AtorP通过消息交互共同认可第3方APP,信任它所实施的平台验证与报告,以及对平台隐私的保护.
记"⊥"为协商操作符.
NegotiationAPP[[AtedP,AtorP,APP]]⊥.
定义2(RA会话)一次完整的远程证明过程称为RA会话,包括从AtorP发起证明委托请求到AtorP基于RA报告作出应用决策的所有步骤与操作,即验证委托AtorPAttestDelegation、可信度量AtedPTrustedMeasure、度量报告AtedPMeasureReport、平台验证APPPlatformAttest、RA报告APPRAReport,应用决策AtorPApplicatonDecision等.
定义3(验证委托)AtorP向验证双方可信的APP发出委托验证请求,由APP执行平台或AO的验证并可信地报告当前状态.
具体委托过程参见2.
2节协议,记"|→"为委托操作符.
AtorPAttestDelegation[[AtorP,APP]]|→.
定义4(可信度量)AtedP利用可信度量组件所提供的完整性度量和安全属性获取功能,将AO的二进制代码度量值采用迭代哈希的方式存放于平台配置寄存器(PCR),同时保存获取的安全属性值,如软件补丁版本,病毒库数据版本、对象安全级、是否采用进程隔离机制等,并将度量过程写入平台的可信度量日志(TML).
记"Δ∧"为可信度量操作符,其中"Δ"和"∧"分别为完整性度量和获取安全属性操作符,PCR犼[n]={hashFunction(PCR[狀-1]||hashFunction(AO犻)}.
AtedPIntegrityMeasure[[AtedP.
TMC,AO犻]]Δ(犻=1,2,…,犿,犼=1,2,…,狀),AtedPAcquiringSecureAttributes[[AtedP.
TMC,AO犻]]∧,AtedPTrustedMeasure[[AtedP.
TMC,AO犻]]Δ∧.
定义5(度量报告)对于APP的验证质询,AtedP在完成可信度量后,将所得AO完整性度量值和安全属性特征值作为消息通过安全信道发送给APP.
记"MR幑幐AC"为度量报告操作符.
AtedPMeasureReport[[AtedP,APP]]MR幑幐AC||.
定义6(平台证明)APP中的验证功能组件通过访问可信度量参考值数据库,获取由软硬件生产厂商提供、权威机构发布的完整性参考值integrityReferences和基本安全策略securityPolicies,然后依据完整性参考值和TML对PCR犼进行一致性验证,判定AO的完整性,即是否被攻击或篡改过;此外依据基本安全策略和secureAttributes验证两者的一致性,判定AO是否存在安全漏洞;并综合给出AO是否完整性保持以及安全属性是否符合策略等平台状态AtedPplatformStatus的两个布尔值integrityFlag和securityFlag.
记"∨"为平台验证操作符,其中""和"∨"分别为完整性度量验证和安全属性验证操作符.
06西安电子科技大学学报(自然科学版)第36卷APPIntegrityAttest[[APP.
AFC,PCR犼,integrityReferences}]],APPSecurityAttest[[APP.
AFC,secureAttributes,securityPolicies]]∨,APPPlatformAttest[[APP.
AFC,measureMetrics,integrityReferences,securityPolicies]]∨.
定义7(RA报告)对于AtorP的验证委托,APP向AtorP报告AtedP当前平台或AO状态,而不提供平台的基本配置细节和安全属性.
记"platformStatus幑幐帯帯帯帯帯AR"为RA报告操作符.
APPRAReport[[APP,AtorP]]platformStatus幑幐帯帯帯帯帯AR.
定义8(应用决策)AtorP收到RA报告后,结合其他应用级的安全策略,进行面向应用的访问决策,接受或拒绝AtedP访问操作等.
记""为应用决策操作符.
AtorPApplicatonDecision[[AtorP.
ADC,AtedPPlatformStatus,AtorPApplicationPoliciy]].
2犃犘2犚犃安全协议设计2.
1攻击模型对笔者所提出的AP2RA方案的攻击模型主要有以下3种模式:(1)对APP证明服务的攻击:敌手通过攻陷APP,使其无法向验证方提供RA报告或提供虚假错误的平台当前状态,从而影响整个应用系统的消息交互,直至系统瘫痪.
所采用的攻击方式主要为DoS攻击、欺骗攻击等.
(2)AtedP共谋攻击:被验证方控制有至少两个终端系统,其中一个是可信平台,另一个为非可信平台.
通过将可信平台的度量值发送给APP接受验证,骗取APP和验证方的信任,从而获取共享信息或接入网络.
(3)AtedP消息重放攻击:利用截获的包含有可信度量信息的消息,重新发起验证过程,借助于已有的符合验证的平台配置和安全属性消息通过不可信平台的APP验证.
2.
2AP2RA安全协议基于1.
3节定义的一次完整RA会话过程,AP2RA安全协议主要涉及AtorP验证委托与APP远程证明等步骤,这里着重给出其中的消息交互过程.
协议中所涉及到的签名算法可采用基于公钥密码体制的RSA,ECC算法等,散列算法可采用SHA1,MD5算法等.
在AtorP和AtedP通过协商APP,确定了可信第3方的验证代理后,AtorP向APP发出平台或应用组件的验证委托请求,包括AIK签名的验证对象AO,待APP验证通过后,给出委托请求的许可结果,此后APP发出对AtedP平台上AO的RA质询;AtedP在本地进行相关度量和安全评估,其中包括已有平台安全启动过程中的度量值和当前应用组件的完整性度量值,一起存放在相应的PCR中;并将签名后的PCR和安全属性值、AIK证书和PCR值等消息发送给APP;APP先后验证签名和PCR值,是否来自被质询的平台并和标准度量值一致,以及安全属性值是否符合安全策略;APP将向AtorP发出已签名的平台验证报告.
该协议具体消息交互如图2所示,其中第(2)~(5)步基于"|→"定义属于AtorP委托过程,第(4)~(7)步是APP远程证明过程.
(1)协议预备过程:基于"⊥"定义,AtedP在接受AtorP的平台验证请求后,双方进行可信第3方代理APP的协商,最终确定一个进行平台验证的代理服务,并且由它保护AtedP平台的隐私;若协商失败,则该协议终止.
在开始RA会话前,这里假定AtedP,AtorP及APP等实体已从PrivacyCA获得了AIK证书,KAtorPAPP和KAtedPAPP分别为APP和AtorP,AtedP之间在RA会话开始前产生的共享秘密密钥;(2)AtorP向APP发出一个委托请求消息MessageD,其中包含AIK私钥签名的被验证对象名称16第1期张志勇等:支持验证代理方的远程证明模型及其安全协议图2支持验证代理方的远程证明协议Signature(AOName,SKAtorP.
AIK)和AIK证书Cert(AtorP.
AIK),以及一个本地生成的随机数Nonce;(3)APP收到MessageD,通过APP.
AIK证书验证AtorP的平台身份并获得AO,进而接受或拒绝AtorP的验证委托,并发送结果.
若APP接受委托,协议向下执行;否则,协议终止;(4)APP向AtedP发出被验证对象AO的RA质询消息,其中包括一个第(2)步由AtorP生成的Nonce;(5)基于"Δ∧"定义,AtedP进行本地完整性度量AtedPIntegrityMeasure(AtedP.
TMC,AO犻)和获取安全属性AtedPAcquiringSecureAttributes(AtedP.
TMC,AO犻),从而PCRs(AO)存放有多个AO犻的度量散列值和相应的度量顺序,此外还获得AO的安全属性特征值secureAttributes,同时将此过程写入TML;基于"MR幑幐AC"定义,AtedP使用平台验证身份证书AIK的私钥SKAtedP.
AIK对PCRs与包含有平台标识值(如可信芯片模块标识码)的TML等内容进行签名,并连同PCRs、secureAttributes、AtedP.
AIK证书和TML作为应答消息{Signature(PCRs||secureAttributes||TML||Nonce,SKAtedP.
AIK),PCRs,TML,secureAttributes}通过安全信道发给APP.
(6)APP收到RA质询应答后,首先结合PrivacyCA判定Cert(AtedP.
AIK)的有效性,并使用AtedP的AIK公钥PKAtedP.
AIK对PCRs签名进行验证,从而判定消息的来源以及AtedP平台的身份,然后基于"∨"定义,执行平台验证操作,并基于"platformStatus幑幐帯帯帯帯帯AR"定义,APP对AtedP平台证明后,通过安全信道发送描述平台完整性与对象安全性状态及其签名值Signature(platformStatus||Nonce,SKAPP.
AIK),并连同APP公钥证书Cert(APP.
AIK)一起作为RA报告,返回给AtorP作为最终访问(或接入)请求的判定依据.
(7)AtorP基于APP的RA报告与其他应用级安全策略进行面向应用的访问决策,并将决策结果返回AtedP.
该协议第(6)步中的RA报告不使用证书机制将验证结果返回APP,虽然证书在有效期内可多次使用,但鉴于平台软硬件的更新和基本安全策略的变化,APP验证结果仅对激活本次协议的应用会话有效,再次应用会话需重新执行协议.
26西安电子科技大学学报(自然科学版)第36卷3犃犘2犚犃方案分析与对比AP2RA与已有的RA方案在采用机制、安全性能、抗攻击模型和系统开销等多个功能性方面进行对比,如表1所示,这里使用符号"","*","+"分别表示具备、不具备、没有涉及或描述该性能.
(1)机制对比与隐私保护:在采用的度量机制方面,由于各方案所考虑的角度不同,TCG采用基本的基于二进制代码的完整性度量,文献[23]所提出的PBRA则基于平台属性的度量与验证,文献[4,6]分别进行软件语义与行为的度量.
由于上述方案没有支持可信第3方的验证,他们的度量机制结合各自的报告机制会造成不同程度的平台配置及安全属性等隐私的暴露.
而文中方案通过APP引入来实施验证过程,它仅向AtorP报告AtedP当前平台状态是否完整性保持以及是否存在安全漏洞,不暴露平台基本配置与其他信息,因此在隐私保护上文中的方案优于其他方案.
(2)抗攻击能力分析:AP2RA主要针对2.
1节提出的3种攻击模型进行了安全协议设计.
在协议中APP通过对验证委托请求者AtorP发来的SKAtorP.
AIK签名消息,对AtorP进行平台身份验证.
由于AIK是能够标识平台惟一身份的EK别名,通过AIK的私钥签名可跟踪到本次发起验证委托请求的终端平台,进而可采用相应动作以防止对APP发起DoS攻击和欺骗攻击等.
在协议第(5)步,AtedP使用平台AIK的私钥签名内容中存在包含平台唯一身份标识的TML,因此即使AtedP拥有两台终端(一台可信终端,一台非可信终端),也无法通过传递可信平台的度量报告来欺骗APP通过非可信平台的验证,从而有效地阻止了共谋攻击.
在协议第(4)~(5)步中实施平台证明质询应答方式,通过Nonce来判定AtedP平台可信度量消息的新鲜性,有效地阻止了重放攻击.
(3)引入APP的可行性:可信计算技术及远程证明将终端可信性扩展到网络的过程中引入可信第3方PrivacyCA是解决平台身份隐私的TCG方案;这里引入APP旨在解决终端平台配置细节和安全属性特征等隐私在RA中的保护,同时由APP提供平台证明功能和服务减轻了终端平台验证远程实体的负担,简化了终端的功能实现.
APP平台验证功能可实现为一个WebService[8],并由不同的第3方提供,但在实施平台验证前,需验证双方协商认可它所提供的服务和平台隐私保护能力.
(4)协议效率与系统开销:文中协议共有3次签名操作,2次加密操作,比TCG的RA方案增加了AtorP与第3方APP之间的1轮验证委托消息交互,但APP的引入有效地保护了被验证平台的隐私.
由于文中方案和PBRA中的TC+[2]都引入可信第3方,所以系统开销较高.
表1方案的机制与性能对比TCGRA[1]PBRA[23]SBRA[4]文献[6]方案文献[8]方案AP2RA可信度量与证明机制基于二进制代码的完整性基于平台配置推导安全属性基于上层软件对象的语义基于应用软件行为和完整性基于二进制代码的完整性基于代码完整性和安全属性可信报告机制基于软硬件配置的报告基于安全属性的报告基于软件语义检查的报告基于应用完整性和行为报告基于PCR扩展和证书的报告平台完整性与安全状态报告支持可信第3方***消息保密性消息完整性+消息抗否认性+跟踪对APP攻击++++抗AtedP共谋攻击抗AtedP重放攻击++平台隐私保护较低一般+较低一般较高系统开销较低较高一般一般较高较高(下转第105页)36第1期张志勇等:支持验证代理方的远程证明模型及其安全协议