【开源项目】Google OpenTitan，硬件安全的泰坦之箭？

Titan芯片在Google Cloud Next 2017大会上首次被提出，**它主要被用来保障谷歌云基础设施的启动安全。硬件安全防护的核心任务是实现安全启动，从而建设可信的服务器系统。腾讯安全平台部在服务器硬件安全体系建设方面，也在积极地开展方案研究、设计与部署应用。现阶段，在不进行硬件结构改造的前提下，有效整合现有防护技术，对于企业硬件安全水平的提升，不失为一种可行的解决思路。Google

摸肚子的小胖子

868人浏览 · 2024-01-12 00:15:27

摸肚子的小胖子 · 2024-01-12 00:15:27 发布

业界很多终端厂商各有一套玩法，不过也或多或少相似，但是因为这个是竞争力也安全性，所以开源的资料比较少，之前更新的关于AES、OTPC、TRNG等设计的文章也是来自于OpenTitan。感兴趣的从业者以及在校生，从事安全相关的可以了解一下。
‘

作者：[ Tencent Blade Team ] Yao

导语

从Windows 98的CIH病毒，到2011年的BMW木马，再到2018年的APT-28攻击，底层安全威胁此起彼伏。

企业信息基础设施是否值得信任，已成为服务提供商需要回应的关键问题。

今年11月Google OpenTitan项目正式发布，平台可信启动问题成为业内关注焦点。

本文将解读Titan安全芯片的基本原理，并针对现阶段服务器硬件安全防护体系的建设思路和大家做一下简单探讨。

1.不断升级的攻防博弈

对于服务器平台的底层攻击，大多集中在对固件（Firmware）内容的非法修改上。

早期的Legacy BIOS木马，以破坏机器的可用性为主要目标，如CIH病毒，可以直接清空BIOS导致无法正常开机。

其他的固件木马，通过感染个人电脑的主/卷引导目录（MBR/VBR），实现持久化驻留的目的，使终端用户叫苦不迭。

随着技术演变，Legacy BIOS逐步被UEFI（服务器启动的新规范）替代，硬件木马也被更多地应用到高级入侵与渗透之中（如APT-28 LoJax木马）。

与之前被黑产利用，存在明显异常行为的特征不同，固件入侵威胁变得更隐蔽、更顽固，例如针对特定企业的供应链攻击、针对特定机器的恶意女仆攻击（基于物理接触，如通过U盘植入木马）、利用启动管理命令实现启动路径修改攻击（如efibootmgr指令）等——这些恶意向量不再局限于OS层的渗透范畴，因此可以有效地绕过常规监控策略。

硬件安全风险带来了信任的危机，尤其是大型企业，影响更加广泛。在企业内部，数据中心基础设施是否安全可靠？在企业外部，是否可以让云平台得到所服务用户的信任？

很多企业APP都有自己的内部软件，保存公司信息。

妥善解决上述问题的一种策略是，充分利用现有的安全防护技术，如IDS、IPS、WAF，布下天罗地网——可是这些方式即便发现异常，也很难准确地定位风险来源，无法彻底排除隐患；

另一种方式是通过可信执行环境（TEE），如Intel SGX技术，以内存加密的方式构建应用程序独享的可信执行区域，将一部分机密的数据和代码隔离起来做机密计算。

但这种方式实际上并没有缓解机器被攻陷的风险，偏安一隅的思路能够暂时保障数据安全，但无法保护平台本身不被入侵。

2.防御方法与业内标杆

那保障平台安全的有效方案是什么样的呢？一种可行策略是，构建无法被篡改的信任根（RoT，Root of Trust），对于平台启动过程中所需执行的固件对象，在其执行前，依次进行合法性验证与信任链条的扩展。

在所有固件对象完成校验后，平台执行操作系统的启动，这样一来，系统最终进入可被信任的Runtime状态。

这个方法听上去简单直接，但操作起来又是另一番情景——图1给出了NIST标准下服务器架构所包含的组成对象，在操作系统层之下，存在十几种硬件固件对象，如：

UEFI BIOS：服务器系统启动固件，其固件镜像存储于SPI总线下的一块闪存片（Boot FW Flash）中；
BMC：带外管理系统，有单独固件，提供不依赖操作系统的服务器管理能力；
Boot Loader: 操作系统OS引导程序，其主要功能是用来载入OS内核；
NIC：外设网卡及其固件；
GPU：显卡及其固件；

图1 服务器系统组成元素

理想情况当然是对涉及到的全体固件对象进行合法性校验，但这不现实，臃肿的开机检测过程会极大地影响机器启动的效率，复杂的厂商供应链组成也让这一目标的达成变得困难；

同时，鉴于入侵某些固件的难度很高，攻击的概率很小，这样的防护方式也会显得多此一举——在考虑攻击者的利用难度、风险水平等多个维度后，底层安全防护最主要的固件对象，一般聚焦在BIOS，BMC和Boot Loader上。

不管是现有的硬件防护方案（如TPM 2.0技术, 后文会进一步说明），还是业内普遍认可的 “下一代硬件安全防护方案”，基本上是围绕上述三大固件对象进行安全方案的设计。

主流的下一代硬件安全防护方案包括Google Titan[1]、Intel PFR[2]、Microsoft Cerberus[3]和我国沈昌祥院士提出的TPCM[4]。

区别于现有TPM 2.0方案所提供的被动式校验固件的能力，这些新的设计都满足主动校验服务器关键固件的能力，但由于涉及到主板设计和硬件结构的定制修改，除了Google Titan方案在谷歌云内部被使用之外，其余方案还未能广泛应用到实际案例中。

作为下一代硬件防护方案的标杆，下面将为大家解读Google Titan安全芯片的基本原理。

3.Google Titan概述

Titan芯片在Google Cloud Next 2017大会上首次被提出，**它主要被用来保障谷歌云基础设施的启动安全。**在功能层面，Titan具有以下三大核心特征：

（1）自主可控的物理可信根：

与传统的TPM 2.0外设芯片不同的是，Titan芯片中包含了Google的物理可信根BOOT ROM，可以作为平台启动信任的锚点，这样一来，谷歌服务器启动的信任起点便掌握在了自己的手中。

由于引入了BOOT ROM，Titan也包含了一个自我修复功能，可以保证在出现Titan芯片漏洞时，对BOOT ROM进行升级，重新建立信任关系。

如图2所示，Titan在硬件结构上包括了一块32位的RISC-V处理器，具有密码和密钥管理功能的外设部分（与TPM 2.0的设计几乎一致），以及蓝色部分中，作为硬件可信根而存在的BOOT ROM。

图2 Titan组成元素一览

（2）首指令完整性校验：

通过Titan芯片，可以实现对于BIOS早期运行代码的合法性验证，通过校验后再执行相关的代码。

图3 Titan芯片主板连接方式示意图

实现上述首指令完整性校验的关键是Titan芯片在主板上的特殊连接方式，如图3所示，Titan芯片串接了SPI总线，如守门员一样介于主板南桥（PCH）或带外管理系统（BMC）与BIOS固件的闪存芯片之间。

这样一来，Titan芯片驱动下的服务器启动过程可描述为：

1.当CPU上电开机/重启时，开机/重启信号由PCH或BMC传递至Boot FW Flash途中，由Titan芯片接收并拦截。
2.Titan芯片执行其只读内存（BOOT ROM）下的代码，并启动一个自检程序，检测Titan芯片自身没有被篡改过。如自检通过，Titan芯片中的代码将正常运行。
3.Titan芯片通过签名校验的方式，验证BIOS固件的合法性。在校验通过后，释放原始的开机/重启信号。从而BIOS固件得以被正常加载并执行启动操作。
4.经过检验的BIOS固件会配置服务器并且加载Boot Loader，Boot Loader会检查和加载操作系统OS。

（3）持续监控SPI总线上的异常操作：

如图4所示，在完成上述服务器启动过程后，Titan芯片会实时监控SPI总线上的数据流，任何试图修改Flash固件的非法操作都会被过滤掉，以持续保障BIOS固件的安全。

图4 Titan在SPI总线上的监控逻辑

除了上述主要特征以外，Titan的支撑系统也引入了一系列防篡改机制，来抵御包括侧信道攻击在内的安全威胁，相应的防护措施包括攻击检测（故障、激光、热、电压）、保险丝、密钥存储、时钟和内存完整性检查等。

同时，Titan也使用OTP保险丝跟踪服务器从制造到生产整个生命周期的过程。

（4）挑战与局限：

需要指出的是，从目前公开的材料来看[1]，Titan方案还没有解决如何进行BMC和Boot Loader的安全防护。

对于BIOS的防护，实现首指令完整性这一点也依赖SPI总线的硬件结构调整和支持，对于一些企业用户来说，改造成本依旧比较高。

此外，在SPI总线上进行监控和流量管理，也不免会产生对正常业务的误伤，如何保障监控逻辑的安全性，也需要谨慎和严密的设计。

4.OpenTitan：群雄逐鹿下的厂商生态

国外厂商在下一代平台硬件安全方案上，呈现出百家争鸣的态势，除了Google的Titan[1]，还包括前文提及到的Intel PFR[2]，Microsoft Cerberus[3]，以及国内倡导的TPCM解决方案[4]等。

TPCM解决方案是一种基于可信计算技术的安全解决方案，可以为各类应用提供可信验证、度量认证、数据加密等服务，保障数据的安全性和完整性。

其中，PFR有Intel的下游厂商支持和配合，Cerberus借助OCP社区的影响力，也获得了很多厂商的响应与认可；在我国等级保护2.0的合规性要求下，TPCM也有一定的部署激励与实践场景。

而Google Titan，一直以谷歌云私有化部署的形态存在，缺乏对于社区和厂商的影响力，这对硬件安全方案的应用和迭代优化都会造成一定的阻力。

出于竞争压力与社区博弈等因素，Google在近期将大部分Titan芯片源码进行了开源，也就是现在浮出水面的OpenTitan项目[5]。

**OpenTitan公开了Titan芯片的大部分实现环节，在打造社区影响力和促进厂商合作的方面，**较Intel和Microsoft可谓扳回一城。需要说明的是，OpenTitan当前开源部分的代码还不成熟[6,7]，某些环节涉及芯片加工商的专有制造工艺（如可信根部分的逻辑），在短期内也很难完全公开[8]，如图5所示。

图5 Titan方案的开源情况（绿色为完全开源）

如果后续OpenTitan可以促使这一实践的更多细节公开，使得企业用户可以更好地缩小其信任范围，那么OpenTitan的竞争优势将会进一步凸显——就目前来看，大厂的下一代解决方案都默认设置由大厂控制的可信根，与企业用户需要更灵活、开放的可信根配置能力的需求相矛盾，这一点会很大程度上影响使用者对于硬件安全方案的选择。

总的来看，下一代硬件安全防护方案仍待打磨，银弹并未出现。对于企业来说，目前还无法直接应用Cerberus、PFR、TPCM这些技术方案。

Titan方案虽已开源，但仍处于相对初期的建设阶段，前文提及的挑战与局限，也不会因为Titan的开源而在短时间内得到解决。

5.防护体系的建设思路

那么问题来了，现阶段企业服务器硬件安全防护应该如何展开呢？

换句话讲，对于大部分企业来说，是否可以暂时不付出主板重构的昂贵代价，实现x86服务器硬件安全防护的目标呢？

答案是肯定的。在笔者来看，这一目标的达成，可以与下述三个方面的工作紧密结合起来：

1、组合出击，化整为零。

即便是Titan和PFR方案，也没有清楚的解释如何校验Boot Loader的合法性。由此我们不难发现，仅仅依靠单一方案，很难有效的兼顾所有硬件安全防护需求。

因此通过化整为零，合理地进行防护点的拆分，并在此基础上整合现有技术方案，其防护效果甚至优于单纯使用某一个“先进的”防护机制。

那么这里让我们盘点一些现阶段已成熟的硬件防护的技术：

BIOS WP：即基于寄存器实现的BIOS写保护，在Intel平台可以使能，AMD平台待确认。
Secure Flash：保证BIOS、BMC固件更新进行时，新的固件镜像满足签名的合法性。
Intel Boot Guard：通过签名校验的方式，保障BIOS启动最初阶段代码的完整性与合法性，类似技术还包括AMD平台下的PSB方案。
UEFI Secure Boot：新固件标准UEFI下，通过校验签名，验证Boot Loader和Option Rom合法性的检测方案，在Intel和AMD平台通用。
TPM 2.0/TCM：使用兼容国密密码算法的可信计算芯片进行开机启动过程的静态度量，实现对于启动阶段固件的完整性校验，在Intel和AMD平台通用。

我们发现，这些方案可以满足对BMC、BIOS、Boot Loader实现局部的防护效果：或进行主动校验（Boot Guard），或采取被动度量（TPM 2.0/TCM）；或实施事前防护（BIOS WP、Secure Flash），或借助事后检测（UEFI Secure Boot）。

那么面对潜在的底层安全威胁，我们可以部署多个单点方案，从而形成一记组合拳式的纵深防护效果，最终建立起服务器平台端到端可信链条。