UEFI secure boot（3）- 安全引导的实现

最新推荐文章于 2024-05-09 10:01:00 发布

程序猿不会起名字

最新推荐文章于 2024-05-09 10:01:00 发布

阅读量3.6k

点赞数 1

分类专栏：固件分析

本文链接：https://blog.csdn.net/qq_21186033/article/details/116946684

版权

10 篇文章 10 订阅

订阅专栏

1）固件必须支持UEFI和SecureBoot。

2）固件必须支持Setup Mode，或至少清除密钥。

3）一个PKI，以及一种管理(生成和签名)您的X.509证书的方法。

参考上述签名过程，简言之，配置包括：

1). 生成初始的已允许数据库（Allowed Database）

2). 生成初始的被禁止数据库（Forbidden Database）

3). 生成初始的秘钥交换秘钥数据库（KEK Database）

4). 设置平台秘钥（PK）

当上述的最后一步完成时，平台将退出setup模式，并且任何涉及到以上数据库的更新都要授权（即要求包含数字签名）。

如果已允许数据库中还包含了grub的签名信息或者加载的grub已被db公钥签名，安全引导配置至此已全部完成。如果平台的默认启动模式是安全引导，那么平台还需要将安全引导变量（Secure Boot variable）设置为True；以便告知OS Loader安全引导已启用。

我们前文提到过，安全启动设备部署好以后，有时会需要修改一些与安全启动相关的数据库中的内容。比如发现了一个固件映像是容易受到安全威胁的，那么他就不应该再被添加到安全引导的过程中。同样，平台所有者有时候想要添加一个新的KEK签名来允许对Allowed或Forbidden数据库进行更灵活的更新。

我们可以通过在UEFI运行时的一些特殊的变量来进行管理。一如前文所讲，任何涉及到已认证变量的更新都要求签名，签名必须采取PKCS#7的形式，并且必须包含时间戳，以便UEFI运行时Variable服务验证此次更新不是旧版更新的重放（避免重放攻击）。

更新上述数据库中的内容时，通过UEFI运行时的一些特殊的变量来进行管理,涉及到的要认证更新的变量必须具有签名以及时间戳。否则更新不予理会。

当一个新驱动被发现与平台不兼容或者包含了使其不适合在设备上使用的bug。而由于安全引导不允许固件的程序回滚，如果不在设计时对这种情况加以预防，当设备真正遇到这种情况时驱动就会彻底不可用。

有两种方式来避免这种情况的发生：

1). 可以为当前存在用户提供旧有的的比较稳定的固件来替代有问题的固件。

2). 对老的固件映像重新签名，添加新的时间戳使它通过验证。

这样一种“恢复”机制的存在，在不损害系统安全的情况下增强了系统的健壮性（可以理解为系统的抗干扰和自修复的能力）。

UEFI安全引导的用途还包括调用OS加载器（OS Loader）。加载内核可能有以下几种情况出现：

1. 本地存储（系统在硬盘）

大多数情况下，操作系统都是存放在本地存储器上的，例如本地的硬盘。UEFI引导管理器首先验证grub的签名，如果通过，就将权限移交。在获得控制权后，frub将加载os，并在此过程中的某一时刻调用 ExitBootServices() 。该调用结束后，只有UEFI运行时服务仍然可用。

由于UEFI变量服务属于运行时服务，因此操作系统仍可能执行与安全引导有关的变量的更新，然而，验证这种更新的有效性的仍然通过固件。

2. 可移动介质与网络启动

UEFI也允许从移动介质加载操作系统。UEFI引导管理器读取引导顺序变量以确定是否优先从可移动介质或者从固定本地存储开始引导。第三种是基于网络的操作系统加载。例如使用PXE下载一个OS Loader。在这过程中，安全引导仍然会验证OS Loader的有效性。

关注