关于Arm安全启动链增强功能

在过去几年中，影响计算机启动方式的攻击越来越多。大多数现代计算机使用统一可扩展固件接口（UEFI）——该规范定义了操作系统（例如Windows）与平台固件（例如磁盘驱动器、显卡）之间的软件接口。UEFI内置安全机制，确保平台固件可以加密验证，并通过启动加载程序安全启动。此固件存储在主板上的非易失性SPI闪存中，因此，即使重装操作系统和更换驱动器，它也依然在系统中。

这创建了一个“信任锚”，用于验证启动过程的每个阶段，但糟糕的是，这个信任锚也是一个攻击目标。在此类UEFI攻击中，恶意操作会在启动过程的早期加载到目标设备上。这意味着，恶意软件可以改变配置数据，通过将自身“植入”而持久存在，并可以绕过只在操作系统阶段加载的安全措施。因此，虽然UEFI锚定的安全启动可保护启动加载程序，使其免受启动加载程序攻击，但它并不能保护UEFI固件本身。

由于此类攻击呈增长趋势，我们开始对我们的UEFI固件进行加密签名，作为缓解步骤。我们现有的解决方案仅针对我们的x86 AMD服务器设备平台，没有针对Arm的类似的UEFI固件签名解决方案。为了确定缺少哪些内容，我们不得不深入研究Arm的安全启动过程。

继续阅读，了解Arm可信固件安全启动。

Arm可信固件安全启动

Arm通过一个名为可信开发板启动要求（TBBR）（即Arm可信固件（ATF）安全启动）的架构定义了一个可信启动过程。TBBR的工作原理是，验证一系列加密签名的二进制镜像，每个镜像都包含系统启动过程中需加载和执行的不同阶段或元素。每个启动加载程序（BL）阶段都会完成初始化过程中的不同阶段：

BL1

BL1定义了启动路径（冷启动还是热启动），将架构初始化（异常向量、CPU初始化和控制寄存器设置），并将平台初始化（启用watchdog流程、MMU和DDR初始化）。

BL2

BL2为Arm可信固件（ATF）的初始化做准备，ATF是负责设置安全启动过程的栈。ATF设置之后，控制台初始化，内存映射为MMU，并为下一个启动加载程序设置消息缓冲区。

BL3

BL3阶段包括多个环节，首先是运行时服务初始化，用于检测系统拓扑。初始化之后，在ATF“安全世界”启动阶段和“正常世界”启动阶段之间切换，包括UEFI固件的设置。上下文的设置是为了确保安全状态的信息无法进入正常世界执行状态。

每个镜像都经公钥验证，公钥存储在已签名的证书中，并可追溯到存储在SoC上的一次性可编程（OTP）存储器中或ROM中的根密钥。

TBBR最初是为手机设计的。这建立了关于如何构建“信任链”的参考架构，从第一步ROM执行（BL1）到“正常世界”固件交接（BL3）。虽然这创建了一个经过验证的固件签名链，但需要注意的是：

SoC制造商大力参与安全启动链，而客户几乎没有参与。

每位客户都需要一个唯一的SoC SKU。如果只有一位客户，那就很简单，但大多数制造商有成千上万个SKU

SoC制造商主要负责PKI链的端到端签名和维护。这增加了流程的复杂性，需要USB密钥存储器签名。

除制造商外，不能扩展。

这告诉我们，为手机构建的架构不能为服务器扩展。

如果我们100%参与制造流程，这就不是什么大问题，但我们是客户和消费者。作为客户，我们对服务器和区块设计有很大的控制权，所以我们希望设计合作伙伴会采用我们能够在AMD平台安全启动中实现的一些概念，并对其进行改进，以适应Arm CPU。

扩容

我们与Ampere展开合作，测试了他们的Altra Max单插槽机架式服务器CPU（代号Mystique），它性能极好，每个核心都能效极高，这正是我们为降低功耗而苦苦寻找的东西。这只是其中一小部分规格，Ampere在Altra Max中引入了各种功能，特别是投机性攻击缓解措施，包括来自Armv8.5指令集架构的Meltdown和Spectre（变体1和变体2），因此，Altra的ISA获得了“+”称号。

Ampere确实实现了一个与上述ATF签名过程相似的签名启动过程，但略有不同。我们将简单解释一下，为我们所做的修改设定上下文。

Ampere安全启动

Ampere实现的Arm处理器启动顺序如上图所示。系统控制处理器（SCP）由系统管理处理器（SMpro）和电源管理处理器（PMpro）组成。SMpro负责安全启动和BMC通信等功能，而PMpro负责动态频率缩放和片上热监控等电源功能。

上电复位时，SCP从ROM中运行系统管理启动加载程序，并加载SMpro固件。初始化后，SMpro在PMpro和ATF线程上生成电源管理栈。ATF BL2和BL31调出处理器资源，例如DRAM和PCIe。此后，控制权移交BL33 BIOS。

身份验证流程

开机时，SMpro固件从SCP EEPROM中的SMpro密钥证书读取Ampere的公钥（ROTPK），计算哈希值，并将其与存储在eFuse中的Ampere公钥哈希值进行比较。通过验证后，使用Ampere的公钥依次将SMpro、PMpro和ATF固件的密钥和内容证书解密。

SMpro公钥将用于验证SMpro和PMpro镜像和ATF密钥，ATF密钥又将验证ATF镜像。这套级联验证始于Ampere根密钥，并存储在俗称电子保险丝（即eFuse）的芯片中。eFuse只能进行一次编程，内容设为只读，无法篡改或修改。

这是用于签名系统、安全世界固件的原始硬件信任根。参考了我们与AMD PSB的签名过程，且知道SoC内有一个足够大的一次性可编程（OTP）区域后，看到这里我们不禁会想：我们为什么不能在这里插入密钥哈希值？

单域安全启动

单域安全启动采用相同的身份验证流程，并将客户公钥（本例中为Cloudflare固件签名密钥）的哈希值添加到eFuse域。因此可以通过一个硬件信任根来验证UEFI固件。此过程由BL2在经过验证的ATF固件中执行。我们的公钥（dbb）从UEFI安全变量存储中读取，计算出哈希值并与存储在eFuse中的公钥哈希值进行比较。如果相符，则使用经过验证的公钥将BL33内容证书解密，验证并启动BIOS和剩下的启动项。这是SDSB增加的关键功能。它通过处理器上的一个eFuse信任根来验证整个软件启动链。

构建基块

在对单域安全启动的工作原理有了基本了解后，下一个合乎逻辑的问题是“如何实现？”。我们确保所有UEFI固件都在构建时签名，但如果把这个过程分成几步，则更有助于理解。

Ampere是我们的原始设备制造商（ODM），我们在执行SDSB方面发挥了重要作用。首先，我们使用我们内部的安全PKI为公-私密钥对生成证书。以UEFI安全变量格式的dbb.auth和dbb.auth向ODM提供公钥端。Ampere向ODM提供参考软件发布包（SRP），包括底板管理控制器、系统控制处理器、UEFI和复杂可编程逻辑器件（CPLD）固件，ODM为其平台自定义SRP。ODM生成一个描述硬件配置的开发板文件，并且还自定义UEFI，旨在第一次启动时注册dbb和dbu，确保变量存储安全。

完成这一步后，我们使用ODM的UEFI ROM镜像、Arm可信固件（ATF）和开发板文件生成一个UEFI.slim文件。（注意：这与AMD PSB不同，因为整个镜像和ATF文件均已签名；在AMD PSB中，只有启动代码的第一个代码块已签名。）整个.SLIM文件使用我们的私钥签名，在文件中产生一个签名哈希值。这只能通过正确的公钥进行验证。最后，ODM将UEFI打包成与其平台BMC兼容的.HPM格式。

同时，我们提供调试保险丝选择和我们DER格式的公钥的哈希值。Ampere使用这些信息创建一个特殊版本的SCP固件，即安全供应（SECPROV）.slim格式。该固件只运行一次，用于将调试设置和公钥哈希值编入SoC eFuse。Ampere将SECPROV.slim文件提交给ODM，ODM将其打包成一个与BMC固件更新工具兼容的.hpm文件。

融合密钥

在系统制造过程中，固件在置入主板之前，已预先编程到存储IC中。请注意，SCP EEPROM包含SECPROV镜像，不是标准SCP固件。在系统首次开机后，向BMC发送一条IPMI命令，将Ampere处理器解除复位。这将允许SECPROV固件运行，使用我们的公钥哈希值和调试设置来刻录SoC eFuse。

最终制造流程

配置我们的公钥后，就会通过使用常规固件重新编程SCP EEPROM继续制造流程。系统开机后，ATF检测到安全变量存储中没有密钥，并允许UEFI固件启动，无论有无签名。由于是第一次UEFI启动，所以会将我们的公钥编入安全变量存储并重新启动。和平常一样，通过Ampere的公钥哈希值验证ATF。由于我们的公钥存在于dbb中，因此对照eFuse中的公钥哈希值进行验证，并允许UEFI启动。

验证

第一部分验证要求观察到eFuse成功销毁。这将我们的公钥哈希值刻入一个不可改变的专用内存区域，不允许覆盖哈希值。自动或手动向BMC发出IPMI OEM命令后，BMC观察到来自SECPROV固件的信号，表示eFuse编程结束。这可以通过BMC命令探测到。

eFuse销毁之后，通过观察其他固件的启动链来继续验证。SCP、ATF或UEFI固件的损坏会阻碍启动流程和启动身份验证，导致机器无法进入操作系统。固件就位后，就会从启动机器开始继续完成路径验证。

第一次启动后，固件按以下顺序启动：BMC、SCP、ATF和UEFI。可以通过各自的串行控制台观察BMC、SCP和ATF固件。UEFI会自动将dbb和dbb文件注册到安全变量存储中，并触发系统复位。

观察复位后，如果正确执行了功能，机器应该会成功进入操作系统。为了进一步验证，我们可以使用UEFI Shell环境来提取dbb文件，并将哈希值与提交给Ampere的哈希值进行比较。成功验证密钥后，会闪存一个未签名的UEFI镜像。未签名的UEFI镜像导致启动加载程序BL3-2阶段身份验证失败。因此，ATF固件经历了一个启动循环。使用不正确的密钥签名的UEFI镜像也会出现类似结果。

更新身份验证流程

在随后的所有启动循环中，ATF将读取安全变量dbb（我们的公钥），计算密钥的哈希值，并将其与eFuse中的只读Cloudflare公钥哈希值进行比较。如果计算出的哈希值和eFuse的哈希值相符，就可以信任我们的公钥变量，并用来验证已签名的UEFI。此后，系统将进入操作系统。

启动

如果机器没有启用该功能，就无法演示该功能的设置，因为我们在构建时设置了eFuse，但我们可以演示从未签名BIOS到签名BIOS的过程。对于该功能的设置，我们将观察到一个自定义BMC命令，指示SCP将ROTPK刻录到SOC的OTP保险丝。我们将在那里观察到对BMC的反馈，详细说明保险丝刻录是否成功。第一次启动UEFI镜像时，UEFI将把dbb和dbb写入安全存储。

您会发现，未签名的BIOS闪存之后，机器将无法启动。

尽管还不了解启动失败的原因，但后台仍在进行一些工作。SCP（系统控制处理器）仍会启动。

1.SCP镜像持有一个包含Ampere生成的ROTPK和SCP密钥哈希值的密钥证书。SCP将计算ROTPK哈希值，并与刻录的OTP保险丝进行比较。如果失败，即哈希值不匹配，那么和前面一样，您将观察到失败。如果成功，SCP固件将继续启动PMpro和SMpro。PMpro和SMpro固件都将通过验证，并继续ATF身份验证流程。

2.SCP身份验证的结论是通过SCP HOB（交接块）将BL1密钥递交给第一阶段启动加载程序，继续前述标准的三阶段启动加载程序ATF身份验证。

3.在BL2阶段，从安全变量存储中读取dbb用于验证BL33证书，并通过启动BL33 UEFI镜像完成启动流程。

任重道远

近年来，服务器管理界面（例如BMC）已经成为各种网络攻击的目标，包括勒索软件、植入工具和破坏性活动。访问BMC时，本地或远程访问均可。随着远程访问模式的开放，有可能通过网络接口在BMC上安装恶意软件。在BMC上的软件受到感染的情况下，恶意软件或间谍软件能在服务器上持久存在。攻击者可能会直接使用闪存工具（例如flashrom或socflash）来更新BMC，而不需要在UEFI层面构建相同级别的固件恢复能力。

未来的状态涉及到使用与主机CPU无关的基础设施，在启动时间之前启用加密安全的主机。我们将寻求纳入开放计算项目数据中心安全控制模块规范（DC-SCM）2.0提出的模块化方法规范。然后，我们便能将我们的信任根标准化，签署我们的BMC，并将基于物理不可克隆函数（PUF）的身份密钥分配给组件和外围设备，以限制OTP保险丝的使用。OTP保险丝在试图“电子循环使用”或重复使用机器时出现故障，因为您无法真正删除一台机器的身份。

相关推荐: 交易量提升2倍！东南亚版“闲鱼”联手Stripe安全支付快速扩张

（图片来源：图虫创意） 新晋独角兽二手交易平台Carousell联手互联网支付专家Stripe，3年内交易量提升两倍，交易欺诈风险降低至0.03%。想了解这个成功秘诀？那就继续往下看！ 一、海外二手市场当道，新晋独角兽Carousell崭露头角 （数据来源：T…