近日,谷歌宣称定制Titan芯片,为谷歌的重计算负载主机,提供硬件验证的启动和端到端认证的信任根。并声称在Google Cloud Platform中加固了服务器的各个层面,包括Google设计的硬件,受控的固件栈,OS镜像,加固过的hypervisor等。主要包括两个方面:secure boot的增强和基于硬件的身份加密。
当我第一眼看到这个消息时,我不由地问自己:这不就是TPM和以及TPM实现的一套可信启动系吗? 谷歌为何自己实现一套
类似TPM的系统? Intel不是已经有基于TPM的tboot/TXT以及OpenCIT的解决方案了吗?
的确,类似TPM,Titan综合了很多组件:一个安全应用处理器,一个加密协处理器,一个硬件随机数生成器,一个密钥体系,嵌入式静态RAM,嵌入式闪存和只读内存块。Titan芯片通过SPI总线(Serial Peripheral Interface)与主CPU进行通信.
基于Titan,谷歌宣称对Secure Boot进行了增强并且实现了基于硬件的身份加密系统。
Secure Boot的增强
首先,我们看一下服务器的典型的启动过程:
1)BMC配置机器硬件让CPU启动时,服务器开始启动;
2)CPU从引导固件闪存中加载引导固件(BIOS或者UEFI),这些引导固件会进行更进一步的软硬件配置;
3)一旦服务器配置成功后,引导固件会从服务器硬盘上的启动扇区读取boot loader程序,并加载到系统内存中;
4)启动固件将执行控制转交给boot loader程序,boot loader程序会从硬盘中读取操作系统镜像到系统内存;
5)boot loader程序把执行控制转移给操作系统。
Titan除了传统的secure boot的典型特性以外,还提供另外两个重要特性:修复(Remediation)和首指令完整性(first-instruction integrity)。
修复,提供了在Titan固件中找到并补上漏洞时,重新建立信任的机制。
首指令完整性,可以识别出每台机器启动周期中最早运行的代码。
根据谷歌的资料(https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html),使用了Titan之后的Secure Boot,服务器的启动过程如下:
1)当服务器Reset时,Titan的安全应用处理器立即从嵌入的只读内存中执行代码,即引导ROM。制造工艺预置了这些不可变代码,默认为是可信的并且在每次芯片重置时被验证。Titan在每次芯片启动时进行内存自带的自检测试,以确保所有的内存,包括ROM,没有被篡改。
2)载入Titan的固件。尽管该固件是嵌入在芯片自带的闪存中的,但是Titian启动ROM并不是盲目地信任它。事实上,启动ROM会使用公钥密码验证Titian的固件,并把经过验证的代码的身份加入到Titan的密钥体系中;
3)引导ROM加载经过验证的固件。
4)Titan在安全地启动完它本身的固件之后,它使用公钥密码来检查主机引导固件闪存里的内容。在Titan检查完引导固件闪存以前,它会阻止BMC/PCH访问引导固件闪存。当检查完毕,它会发出Ready信号使服务器从reset状态中出来。在Titan检查引导固件时把服务器保持在reset状态,提供给我们首指令完整性这一特性:我们可以从首指令中得到什么引导固件和OS在服务器上启动。
5)经过检验的引导固件会配置服务器并且加载Boot loader;
6)经过检验的Boot loader会检查和加载操作系统。
使用Titan进行身份加密
谷歌开发了基于Titan芯片的端到端的身份加密系统,该系统在数据中心里被用作各种加密操作的信任根。
Titan芯片制造工艺会为每个芯片生成独一无二的密钥材料(keying material)。该密钥材料和密钥的出处信息安全地存放在注册数据库里。该数据库的内容使用离线的Titan CA维护的密钥进行加密保护。各Titan芯片生成认证签名请求(Cerfiticate Signing Request)发给CA,CA会使用预先存放的注册数据库的信息验证CSR,并发给身份证书(identity certificate)。
基于Titan的身份系统不近使用CSR验证芯片的来源,而且,由于固件的代码身份的哈希值存放到芯片的密钥系统里,该系统也可以检查芯片里运行的固件。这一特点使得修复(Remediatioin)成为可能。它允许我们修改Titian固件里的bug,并且发送CA证书给修复后的Titan芯片使用。
同时,基于Titan的身份系统使能了后端系统来给各携带Titan芯片的服务器以及运行在上面的业务生成密钥。
Titan也可以为重要的审计日志进行签名,确保Log的修改会留有证据。Titan维护一个连续的计数器,把每条log和计数关联;同时使用私有密钥,对这种关联进行签名。这种把日志消息和计数器的连续数值进行绑定的做法,确保了审计日志不会毫无痕迹或觉察的情况下被具有root权限的入侵者进行修改或删除。
总结陈词:
确保服务器的启动过程的完整性这方面,现在比较流行的2种技术:基于UEFI的secure boot 和基于TPM的系统启动的度量。前者需要一个前提是Firmware本身是可信和完整的。而基于TPM的度量,则由于TCG在设计TPM规范时,考虑到兼容性和厂商中立性,把更多的空间留给了服务厂商来实现。Intel有一个trusted boot和txt的实现,以及CIT的解决方案,但是感觉实际使用的客户并不太多。相比TPM,除了提供所谓的首指令完整性之外,Google的Titan更主动地去测量服务器启动过程中的每一个状态,并主动进行修改。这一点对可信计算的厂商来说应该是一个很好的参考。其实,国内沈昌祥院士倡导的TPCM是一种主动的方式,但是由于需要硬件的支持,个人觉得有点太heavy,使用客户也不多。
参考资料:
https://youtu.be/kwnWfHq2EfQ?t=31m27s
https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html