国产操作系统之殇：Linux安全启动的签名问题

值此中美冲突日渐激烈之际，国产操作系统的安全启动根证书掌握在美国微软公司手中这一事实，让中国计算机产业的自主可控链条看起来赢弱无比。正如隔壁老王有你家门锁的一把超级钥匙，不但可用随意制作新的可自由出入的子钥匙，而且可以随时作废你这个正主的钥匙。虽然老王看起来很正直，但请问你会不会随时担心家里的财产？

前几天恰逢中国固件联盟成立大会召开，和几位业界大佬聚会聊天。一个经常被提及的问题是：如果和美国明天发生硬脱钩，中国固件产业乃至整个计算机产业链会发生什么？会不会立刻陷入混乱？如果GitHub不让访问了，BIOS界会发生什么？如果美国恶意攻击，我们的安全链条强壮吗？

回来的高铁上，我时不时陷入沉思。尽管中国计算机（包括服务器）启动过程安全证书两头在外业内人士早就知晓:

但我从未从最坏的可能性考虑过：如果证书所有者主动发动攻击怎么办？毕竟安全设计的原则就是“怀疑”，不是吗？是梳理整个链条，标记可能的薄弱环节，引起大家关注的时候了。我计划写几篇文章，分别关注某些薄弱环节，也欢迎大家一起讨论可能的解决方案：

1.Linux安全启动签名问题，和对策讨论。这是安全链条的后端，也就是'证书两头在外'的后端。

2.硬件可信根的问题，和对策讨论。这是安全链条的前端，是'证书两头在外'的前端。

3.Github中EDK2代码的国内镜像和分支讨论，顺便介绍一下已有的多个EDK2镜像和分支。

今天就从Linux的安全启动签名问题开始。

Linux的安全启动签名

现在国内计算机，包括个人电脑和服务器，BIOS大多打开了UEFI安全启动；而国产主流操作系统基本上可以说都是Linux国内的一个发行版（附加了一些自己的特色功能，如中文、特色桌面等等）。于是Linux安全启动链条中被人诟病最多的CA证书问题，成为了链条中最大的薄弱环节。

读懂后文需要一定的密码学和UEFI安全启动知识，读者可以在我前面的科普文章中恶补一下为了更好地服务各位读者，避免舟车劳顿，下面是一些囫囵吞枣的知识点，看不懂也没有关系，后面我会尝试用你家的门锁和隔壁老王来不恰当的比喻一下,方便大家理解：

1.安全启动基于现代密码学中的非对称秘钥：一对公钥和私钥。

2.更高的层次上，引入证书授权机构（Certificate Authority,简称CA），对秘钥进行签名，来保证对签名的认可。

3.签名是可以传递的，构成信任链条。所以CA作为信任的根基，尤其重要，我们叫它做信任锚。

4. UEFI安全启动有两种信任锚：PK（Platform Key）是最高等级的信任锚点，由OEM或者企业IT拥有；次一级的是密钥交换密钥（Key Exchange Key,简称KEK）数据库，里面可以是多个CA，但目前大多数机器里面只有美国微软公司的CA。

5.UEFI安全启动有三个名单库：白名单（db，用于特赦的Hash或秘钥）、黑名单（dbx，用于被召回revoke的秘钥）和dbt。

6.要更新KEK，必须要有PK；要想更新db或者dbx，必须有KEK。

7.安全启动的流程一般是：BIOS用KEK验签OS Bootloader；Bootloader验签（OS的公钥）OS Kernel；Kernel再去验证OS驱动和应用。从而保证每个被启动的环境都是安全的，构成一个完整的信任链条。

众多周知，UEFI安全启动是微软牵头Intel搞出来的。所以UEFI的第一批CA就是微软的CA，由OEM通过PK放在KEK数据库中。理论上来说，众多Linux发行版也可以把各自的CA放在KEK中，但因为Linux世界十分发散，小公司众多，不想也不能支持完善的CA管理和召回机制。同时KEK中CA众多，也无形中增大了风险。

在开始Linux社区对安全启动持排斥态度，毕竟Linux和Windows世界可以说是世仇（最近发生了变化）。让Linux把自己的入口放给微软，让微软CA签名Bootloader太难于接受。但随着固件安全形式越来越严峻，安全启动的必须性越来越明显。加上微软将BIOS CA贡献给了UEFI论坛，作为UEFI论坛的CA，并将db和dbx管理交给了UEFI论坛，打消了部分疑虑。Linux社区开始拥抱UEFI安全启动。但尽管大家BIOS中的这个KEK叫做UEFI CA，但实际上UEFI CA由微软管理，签名验证和批准都由微软和微软CA服务器进行 ，并收取一定费用 。这些Linux社区都可以勉强接受，但如果每次更新改动比较频繁的BootLoader都需要微软签名的话，会严重拖慢Linux发行速度，而且限制了个人魔改Linux的可能性。有没有可能将签名机制分层呢？

Shim解决方案

Linux社区UEFI安全启动签名的解决方案主要有两个：Shim和Preloader，Shim方案占据主流，主流发行版包括国产操作系统都采用Shim方案，我们今天就只介绍Shim方案。

Shim方案由Fedora团队的Fedora's Shim program发展而来，它的代码是开源的 。Shim是垫片的意思，它的主要思想是设计一个可扩展，但代码相对稳定的中间层。它相对稳定，不需要经常改动，所以只需要微软CA签名一次可以不太需要重新签名。它的内部放入Linux厂家的签名，对后面的部分进行签名。Shim作为一个中间层，隔离了微软的CA，将签名传递给Linux发行版的签名，来保证不需要太依赖微软CA服务。

Shim中有两种签名：

1. Shim keys, 这是build-in嵌入到Shim中的固定秘钥，一般是Linux发行版厂家的公钥。
2. MOKs（Machine Owner Key），一般用于自己编译Linux时使用，不在本文讨论范围内。

我们拿OpenSUSE举个例子：

1. SUSE将自己的公钥放在Shim Key中，重新编译后，提交给微软。微软审核后签名。
2. Suse将签名后的Shim64.efi（或者改名叫做bootx64.efi）放入发行版中。
3. SUSE用私钥签名自己的GRUB2，放入发行版中。

Ubuntu也类似采用Shim方案，需要微软签名自己的Shim64.efi .国产Linux操作系统也不例外，都要提交自己的Shim给微软签名。

那么问题来了，掌握大多数电脑KEK CA的微软如果要作恶，他能做些什么呢？

UEFI CA由微软掌握的弊端

我们假设微软放弃了他的承诺，用它的CA攻击（需要说明这样它的CA和公信力会变成垃圾）的话，它可以做什么呢？

它可以利用Windows Update的机会，更新黑名单dbx，把给所有国内的Shim颁发的证书都召回（revoke）。Poof，所有国产Linux都启动不了了！它还可以用CA签名一个恶意BootLoader，占据国产Shim的位置，这样以后所有操作都可以在微软的监控下！

这就好比隔壁老王为你装了个门锁，给你了一串钥匙。但为了防止你丢掉钥匙坏人进来，贴心的自己掌握了一个超级钥匙。这个超级钥匙不但可以重新制作新的可以进你家的钥匙，还可以让你的所有钥匙都无效。以前老王家富有，你家一贫如洗。几年过去了，老王家慢慢衰败，你家富了起来，你感觉老王看你的眼神越来越不对，你知道他有你家的超级钥匙，就问你怕不怕？

解决方案

那怎么办呢？是不是把UEFI安全启动干脆关掉呢？显然这样不但于事无补，反而放大了风险。就像你知道隔壁老王的超级钥匙后，为了怕某天被锁在门外，干脆把门锁卸了，这样所有人（包括老王）都可以自由出入你家，这不是好的办法。

那能不能干脆把所有国产操作系统的公钥全部放入KEK中，移除微软的CA呢？这样也不妥，国产厂商良莠不齐，管理公钥私钥对需要花费很多金钱和精力，更重要的是要有完整可靠的秘钥管理流程，这是很多国内厂商不具备的。这就好比你收回了隔壁老王的超级钥匙，但害怕钥匙丢了没有了，于是配了好多钥匙，放得到处都是，甚至家里的狗身上都别了一个！这能不招人惦记吗？

正确的方式似乎是在国内寻找一个有公信力的机构或者公司，来掌握一个中国的固件安全启动CA，由这家公司来行使目前微软的职能。并要求国内销售的BIOS都必须集成这个CA进KEK中。这样既避免了风险，又能统一管理。就像你把老王的超级钥匙拿回来了，寄存在派出所中，用的时候凭借身份证去领，这样感觉更安全一些。

结论

我并不是暗示微软真的会攻击中国的计算机，但防人之心不可无，尤其在现在的国际形势下，需做好万全的准备。