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

业界很多终端厂商各有一套玩法，不过也或多或少相似，但是因为这个是竞争力也安全性，所以开源的资料比较少，之前更新的关于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：显卡及其固件；

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

同时，鉴于入侵某些固件的难度很高，攻击的概率很小，这样的防护方式也会显得多此一举——在考虑攻击者的利用难度、风险水平等多个维度后，底层安全防护最主要的固件对象，一般聚焦在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芯片，可以实现对于BIOS早期运行代码的合法性验证，通过校验后再执行相关的代码。

实现上述首指令完整性校验的关键是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固件的安全。

除了上述主要特征以外，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所示。

如果后续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）。

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

2.实时监控，运筹帷幄。

在Google和Intel的解决方案中，都涉及到OS启动之后，在硬件层面对与BIOS固件闪存（Boot FW Flash）进行交互的指令流的持续性监控，这一点是Titan和PFR作为下一代平台解决方案的关键优势之一。

而Boot Guard、UEFI Secure Boot这些方案，都是系统启动过程中进行防护，存在延迟性检测的弊端，也就是说，方案检测的实际效果很大程度上要取决于机器重启的频率。

那么，在机器长期不重启的情况下，BIOS是否已经被篡改便不得而知，对于攻击者入侵行为的取证能力较弱，会让防御的一方在攻防对抗中变得被动。

实际上，可以将对于Boot FW Flash的硬件层实时监控，调整为Runtime下的对于BIOS固件内容的（接近实时）周期性检测，一方面避免了硬件改板，以及总线监控不当引起的通信延迟；另一方面，由于OS层的计算资源更为丰富，数据分析方式更为多样，也可以获得更准确的分析效果。

**当然Runtime态的BIOS监控可能会存在一定的被绕过风险，**但对于应对中低烈度的安全攻击，提升对于底层威胁的取证能力，有着重要的意义。

目前我们团队也在服务器安全系统（洋葱）实践准实时的BIOS安全监控，也取得一定进展。

3.关注运营，见微者著。

企业服务器的规模数以万计，在部署硬件防护方案的时候，方案设计必须与部署运营紧密结合。见微者著，只有妥善处理好方案实施过程中的各项细节问题，硬件方案才能发挥真正的防护效果。

运营相关的具体实例太多，这里简述一二：

UEFI Secure Boot、Intel PFR、Google Titan方案都是基于签名机制进行合法性校验的，在实际运营中，

• 应该如何设计并导入证书？
• 如何解决证书的过期与更新问题？
• 如何保障相关运维工具的兼容性？
• 如何确保上游厂商提供固件签名的正确性？
• 如何评估启用方案之后对于正常业务的影响？

这往往需要联动厂商、运维团队、业务团队各方进行适配改造与兼容性验证。

此外，TPM 2.0等方案借助哈希算法进行度量，如何保证运营过程出现异常的可解释性？使用哈希度量进行校验，也意味着需要Golden Key作为基线进行对比参照，那么如何建立这样的基线，并在BIOS合法更新时进行基线的同步更新，也是安全运营过程中需要关注的重点。

又比如，在进行实时BIOS监控的过程中，如何利用离群分析和威胁情报进行数据关联，来识别高级入侵？如何消除由于厂商BIOS研发差异性而引起的监控误报？

监控策略的普适性需要结合运营收敛，并得以不断优化。

6.写在最后

硬件安全防护的核心任务是实现安全启动，从而建设可信的服务器系统。腾讯安全平台部在服务器硬件安全体系建设方面，也在积极地开展方案研究、设计与部署应用。

现阶段，在不进行硬件结构改造的前提下，有效整合现有防护技术，对于企业硬件安全水平的提升，不失为一种可行的解决思路。

Google Titan是下一代硬件安全厂商方案的标杆之一，虽然存在物理制造透明性、厂商驱动等局限，但在防护架构、实时监控、侧信道攻击防御等设计层面都有着重要的参考价值。

此外，硬件安全防护与传统的OS层防护一样，依赖运营质量的加持。只有充分落实对上游厂商的管控、自动化安全基线的建设、数据分析下的误报优化等关键环节，才能在这场关乎信任的攻防对抗中，立于不败之地。

参考文献

• [1] Titan Silicon Root of Trust for Google Cloud.

• [2] Intel® Platform Firmware Resilience (Intel® PFR).

• [3] Project Cerberus Architecture Overview.

• [4] 沈昌祥, 公备. 基于国产密码体系的可信计算体系框架. 密码学报. 2015 Jan 19;2(5):381-9.

• [5] OpenTitan: Open Source Silicon Root of Trust.

• [6] OpenTitan Hardware Development Stages.

• [7] Hardware Designs Dashboard.

• [8] Google Is Helping Design an Open Source, Ultra-Secure Chip.