vTPM: Virtualizing the Trusted Platform Module
摘要
在一台拥有无限VM的物理机上允许可信计算技术,通过虚拟可信平台模块,使得TPM的安全存储与加密功能能够在VM中使用,支持在虚拟化环境中建立可信,特别是对软件完整性的远程证实。
使用软件实现了整个TPM规范,增加了创建与销毁TPM实例的功能,支持vTPM的挂起与恢复以及迁移操作,在vTPM与硬件TPM的连接上给出了四种设计。
概述
虚拟化带来的成本优势同时引入了安全问题:
- 共享相同平台的工作量可能需要分离,如政府要求银行在市场分析与安全保险部门之间维护一个严格的分离;商业利益要求竞争对手不能访问对手的数据
- 恶意软件威胁更加严重
要求:软件完整性(TPM完成)与工作量隔离(VMM完成)。
将TPM虚拟化所面临的挑战:
- 在高层支持诸如可信建立的安全概念
- 通过管理签名密钥与证书将信任链从物理TPM扩展到vTPM
- 如何支持vTPM实例的迁移
贡献:
- 定义vTPM的要求,包括迁移
- 针对这些要求给出vTPM架构
- Xen上实现
- vTPM安全证书的四种可选机制
- 方案有效
vTPM要求
- 与物理TPM有相同的使用模型与命令集
- 在VM的生命周期内强绑定VM与vTPM,包括迁移
- 维护vTPM与其下的TCB的强绑定
- vTPM与TPM能够明确区分(不同的安全属性)
挑战:
- 支持vTPM的挂起与恢复,包括迁移
- 维护vTPM与其下的TCB之间的绑定关系
架构
为解决vTPM server-side不知道是由哪个vTPM实例发送的命令请求问题,引入四字节的标识符,用于说明哪个vTPM实例能够接收哪个虚拟机的信息,是由server-side定义的,所以不能被VM所伪造。
维护一个list:virtual- machine-to-virtual-TPM-instance associations,在VM的整个生命周期内维护绑定关系。
Capability应当紧紧被root实例的拥有者访问。
每个vTPM实例拥有独立的key继承树,优势:不需要借助硬件TPM做加解密,速度更快;简化迁移操作。
有没有简单的办法能够确保vTPM的EK是有效的?
扩展命令集
- vTPM manager cmd:setup,对OS内核与相关boot文件度量,度量值写入PCR
- vTPM migration cmd:强制保护要迁移的vTPM实例(如何保护?)
- vTPM utility cmd:将vTPM实例的某些命令路由给孩子vTPM
vTPM迁移流程:
TCB:
要证实虚拟机必须要首先保证vTPM的运行环境是可信的,因而,需要先证实hypervisor以及boot过程。通过提供两种不同类型的PCR来解决这个问题,low PCR复制了物理TPM的BIOS、bootloader以及VMM的度量值,使用PCR9度量guest os的度量值,这样挑战者能够看到所有相关的度量值。
问题:虽然说度量信息映射到了vTPM上,但是由于不能确保vTPM自身是可信的,所以也不能确保vTPM提供的信息都是可信的,还是说有其他方案?所以还是得两步证实吧?
为了确保迁移时非对称存储密钥仅仅会迁移给可信的vTPM,要求目的vTPM的使用AIK签名的存储密钥。那么,
- 谁能够为vTPM提供EK证书?
- 这个证书能够代表什么?
解决方案:
- 将vTPM的EK证书绑定在物理TPM的AIK证书上。
优势:保留普通的证实流程
- 不签发vTPM的EK,而是使用物理TPM的AIK产生vTPM的AIK
优势:快速
劣势:变更标准的证实过程
- 使用本地认证机构为vTPM颁发EK证书
优势:没有将证书链接到物理TPM,直接当成物理TPM,不需要修改标准证实流程 - 使用安全协处理器来代替物理TPM
对vTPM的迁移的影响:
前两种解决方案要求在迁移前要撤销与物理TPM的链接
四种解决方案对比: