0 引言

自2003年可信计算组织(trusted computing group,TCG)成立以来,可信计算^[1]取得了长足的发展,TCG陆续发布了PC机、服务器、移动平台、虚拟化系统的规范说明,国内外研究人员相继开发出了IMA、TGRUB、Tboot、BitLocker等实际可信计算应用产品.已有研究表明,针对可信计算系统中的重要核心部件:静态可信度量根(static root of trust for measurement,SRTM),国内外大部分可信计算产品中的SRTM部件存在着未严格遵从可信计算规范说明,对于规范说明中要求SRTM应该度量的组件也存在未实现的情况^[1].在云计算等新型计算环境中得到广泛应用的动态可信度量根(dynamic root of trust for measurement,DRTM)也并非绝对安全,Wojtczuk等发现可通过在系统管理模式(system management mode,SMM)中注入恶意代码对DRTM进行旁路攻击^[2].因此SRTM的安全性是保证静态信任链和动态信任链安全运行的重要前提.

SRTM的安全性直接和BIOS相关,BIOS的安全性一直受到国内外研究人员的关注,在国际信息安全顶级学术会议上相继出现了一些具有代表性的研究成果.基于BIOS未写保护的假设,Heasman(2006)^[3]提出了BIOS Rootkit,该攻击通过对ACPI表进行修改使得BIOS在解释执行ACPI表时会对特定内存区域进行操作.Brossard(2012)^[4]提出了对芯片组寄存器进行写操作达到对CoreBoot系统进行攻击的目的.通过BIOS对SRTM/DRTM进行安全机制破坏的研究,Butterworth等(2013)^[5]构造了tick和flea漏洞,使得恶意代码总是能够驻留在SRTM中.Kauer^[6]发现了可信笔记本HP-nx6325中对SRTM机制的几种破坏方法,并建议用AMD-V平台的DRTM替换SRTM,从信任链中去除BIOS、OptionROMs和BootLoaders,达到让DRTM不依赖SRTM的目的.但实际上DRTM的安全性是和SRTM密切相关的,对于依赖SMM达到安全目标的云计算安全基础设施系统,如HyperCheck^[7]、HperSentry^[8]和SICE^[9]等,SRTM的安全性也将直接对其造成安全威胁.为对SRTM的安全性进行证明,本文将采用基于TPM(trusted platform module)时间戳的证明方法.文献[10~14]先后提出了基于运行时间阈值的软件证明方法,包括著名的Pioneer和SWATT软件证明协议,但这些协议在证明过程中都未使用TPM时间戳,存在着中间人攻击的安全问题.

1 SRTM安全问题 1.1 SRTM重写安全

可信计算PC规范指出:可信度量根核CRTM必须是不可被改变的.但在实际过程中,BIOS的升级需求使得对其进行更新是不受控制的,对BIOS的重写破坏了SRTM作为静态可信度量根以及CRTM(core root of trust for measurement)作为可信度量根核的作用.虽然可以通过数字签名对BIOS升级过程进行验证,防止攻击者刷新携带有恶意代码的BIOS,但是研究人员给出了旁路签名过程的方法.由于对BIOS更新的随意性导致SRTM、CRTM的安全性难以得到保障,Intel公司提出了两种方法以阻止对BIOS的恶意重写,一种是设置芯片组中BIOS_CNTL寄存器的BIOSWE位和BLE位防止对BIOS的直接刷新;另外一种是通过触发系统管理中断(system management interrupts,SMI)进入SMM后重新配置BIOS_CNTL寄存器的值^[3].

1.2 SRTM度量不一致

可信计算PC规范对SRTM度量过程进行了详细描述,要求度量结果应存入平台配置寄存器(platform configuration register,PCR)中,并严格规定了PCR₀~PCR₇应包含的被度量组件,如表1所示,度量组件分为必须被度量组件、可选被度量组件和必须不能被度量组件,可信计算PC规范严格定义了PCR₀~PCR₇对应的被度量组件,本文以HP-nc6400可信计算笔记本为实验对象,对其SRTM度量结果和存储度量日志(stored measurement log,SML)进行了分析,实验表明HP-nc6400存在着PCR₂、PCR₃、PCR₆和PCR₇的存储值相同的情况,说明了这些PCRs都存储了同一个被度量组件的哈希值,这违背了可信计算PC规范,本文发现度量不一致的问题也出现在国内外的其他可信计算平台中,甚至存在着SRTM缺失CRTM证书和MA(memory absent)驱动的安全漏洞隐患.这表明BIOS厂商在实现SRTM上存在着严重的度量不一致问题,导致难以从根本上保证SRTM的正确性和安全性,因此需要从实际系统出发,考虑SRTM的度量一致性和安全证明问题.

1.3 不完整性的CRTM自度量

可信PC规范明确要求CRTM需要度量自身完整性,并度量BIOS的POST代码,但在实际系统中发现在产生PCR₀存储值的过程中,CRTM仅度量了很少的代码,如图1所示,通过分析HP-nc6400的存储度量日志SML发现,CRTM仅对BIOS版本号、POST BIOS信息值、键盘控制器版本等信息进行了度量,未度量SRTM、POST BIOS的完整性,对BIOS的度量内容仅占整个BIOS的0.1%.

2 可靠的SRTM度量与安全证明 2.1 完整SRTM度量

从上节得知HP-nc6400的CRTM并不能为SRTM提供有效的度量过程和度量结果,为达到既不修改原始SRTM度量流程,又能实现完整SRTM度量的目标,本文在HP-nc6400 BIOS中增加CRTM锚节点(CRTM anchor node,CAN)模块,在静态信任链运行流程上,CAN是SRTM的第一个运行模块,针对CRTM度量不完整和不准确的问题,CAN完成自度量、SMRAM度量和BIOS度量等.

Step 1:CAN初始化SMRAM内存，布置SMI Handlers和BIOS度量代码等.

Step 2:CAN触发SMI中断，进行SRTM度量.

Step 3:CAN的SMI Handlers代码被执行，CAN请求TPM时间戳；CAN分别度量CAN代码区域，SMRAM区域和BIOS区域.

在组成结构上,CAN模块包括CAN启动代码和CAN在SMRAM中的SMI处理代码(CAN’s SMI handlers).CAN通过图2所示步骤完成对CAN的自度量、SRTM度量和必要组件的度量,确保CAN和SRTM的安全性.

2.2 TTSAP协议

本文在SRTM中增加了CAN模块,鉴于CAN对SRTM的重要性,这里通过设计安全协议确保CAN度量过程和运行的安全性,以保证SRTM度量的安全.Kovah等^[10]给出了一种基于TPM时间戳的证明协议(TPM timing-based attestation protocol),根据该思想本文提出基于TPM时间戳的SRTM证明协议TTSAP(TPM timing-based SRTM attestation protocol).

首先对时间戳进行简单描述,时间戳(tickstamp)是TPM内部时钟滴答数的签名值,在TPM 1.2规范中提供了TPM_TickStampBlob命令,如图3所示,随机数nonce、签名参数data blob和AIK密钥句柄作为输入参数,经过调用TPM_TickStampBlob命令,输出为TPM的当前滴答值ticks、TPM的当前时间会话随机数TSN(tick session nonce)和时间戳签名值Signature,整个过程可表示为TickStamp_AIK(data,nonce)→(ticks,TSN,signature),其中signature=SIGN_AIK(data,nonce,ticks,TSN).

文献^[10]对基于软件证明(software-based attestation)进行了扩展,其基本思想是通过使用与时钟相关的硬件或软件指令,并通过周期性的校验系统对自身和其他需要被保护的代码进行校验,协议的证明时间被严格要求在阈值范围内,攻击者难以增加额外的恶意代码进行欺骗攻击.如果攻击者对度量代码进行了篡改,为达到不被发现的目的,攻击者必须给出正确的校验值,而前提条件是攻击者也必须有一个周期性校验系统用于生成正确的校验值,修改生成校验值的代码以发送正确的校验值.但对于周期性校验系统而言,附加在循环校验系统上的恶意代码会增加协议交互时间^[14],时间上的变化对于验证方是可检测的.

在文献^{[5, 10]}的基础上,本文提出系统启动后的CAN度量流程,包括如下步骤:

Step 1:通过TPM_GetTicks命令读取当前时间会话随机数TSN,GetTicks()→TSN_curr;

Step 2:将TSN_curr作为参数获得时间戳tickstamp₁(简称TS₁),TickStamp_AIK(TSN_curr,TSN_curr)→TS₁;

Step 3:将TS₁中的签名值作为自检函数checksum(简称CS)的参数,SelfCheck(TS₁.signature)→CS,度量内容包括:

Step 3.1：CS所在的内存区域;

Step 3.2：SMRAM、BIOS和中断向量表;

Step 4:将CS的值作为参数获得时间戳tickstamp₂(简称TS₂),TickStamp_AIK(CS,CS)→TS₂;

Step 5:将TS₁,TS₂和CS存储至SMRAM.

与Schellekens等^[15]提出的改进pioneer协议相比,TTSAP协议的nonce是通过TPM获得的,时间会话随机数TSN用于标识区别不同的时间会话,而不是来自于外部请求者.TTSAP协议验证过程步骤如下:

Step 1:挑战者给应答者发送一个作为nonce的TSN;

Step 2:应答者触发SMI中断,并将TSN作为输入参数传入CAN的SMI Handler;

Step 3:应答者获得当前的TPM时间戳(简写为CTS),TickStamp_AIK(TSN,TSN)→CTS;

Step 4:应答者将SMRAM内存中的CTS、TS₁、TS₂和CS发送给挑战者;

Step 5:挑战者验证TS₁，TS₂和CTS的签名,以确认它们是通过一个可信的TPM产生的;

Step 6:挑战者验证等式TS₁.TSN =TS₂.TSN是否成立,用于验证CAN运行前后都处在同一个TPM时间会话中;

Step 7:挑战者验证等式TS₁.TSN =TS₂.TSN=CTS.TSN是否成立,以确认协议运行过程中不会出现重放攻击;

Step 8:挑战者验证CS的参数就是TS₁.signature,即证明应答者在计算CS之前必须先获得TS₁;

Step 9:挑战者验证TS₁.signature中的随机数参数和Step 1发送的nonce是同一个值,从而证明攻击者不能预先计算出TSN;

Step 10:挑战者验证被TS₂.signature中的自检参数和应答者发送的CS是同一个值,证明TS₂是在应答者计算完成CS后才计算完成的;

Step 11:挑战者计算时间阈值Δ=TS₂.ticks-TS₁.ticks,验证Δ在可接受的范围内;

Step 12:挑战者确认应答者发送的CS和基于nonce计算出来的CS′是同一个值.

2.3 TTSAP协议分析

若挑战者成功运行了TTSAP协议,则认为挑战者完成了对SRTM的完整性度量过程,并可证明CAN可抵御重放攻击和篡改攻击,这里给出定性描述.

在本文提出的基于TPM时间戳的TTSAP协议中,一方面为防止中间人重放攻击,挑战者给应答者发送一个作为nonce的TSN(Step 1),使得攻击者通过命令接口对TSN进行重放攻击,攻击者获得TSN的计算复杂度为O(2¹⁶⁰),在计算上是不可行的;另一方面为防止对时间阈值Δ的篡改攻击,在对CAN的软件证明过程中,基于对TPM物理安全的假设条件,协议使用了TPM的ticks计数功能,使得攻击者难以获得当前TSN、TS₁.ticks或TS₂.ticks,这就保证协议中计算时间阈值的过程是可信的(Step 11).

综合这两点,本文提出的基于TPM时间戳的的TTSAP协议是可靠的.

3 结论

静态信任链的核心度量根CRTM,存在着产品实现上的安全漏洞,本文首先针对HP-nc6400的SRTM进行了安全问题分析,包括SRTM重写安全、SRTM度量不一致问题和不完整的CRTM自度量问题,针对CRTM产品实现上的缺陷以及带来的一系列安全隐患,提出了一种可靠的SRTM度量与安全证明方法,即完整SRTM度量过程和基于TPM时间戳的SRTM安全证明协议,并对协议进行了验证与分析,为现有SRTM产品存在的安全漏洞提供了一种有效的解决方法.下一步工作是对TTSAP协议进行形式化证明,并在云安全平台上进行应用和性能分析.