密码学基础（上）：对称加密与非对称加密、哈希函数与数字签名、公钥基础设施（PKI）概念

说实话，很多做UEFI开发的兄弟，一听到「密码学」三个字就头大。我当年也一样，觉得这是数学系的事，跟我一个搞固件的有什么关系？直到我第一次接触Secure Boot的签名验证流程，才发现——不懂密码学，你连BIOS里那几行配置都看不懂。

这一章，咱们就把UEFI安全启动依赖的密码学基础捋一遍。不推公式，不讲玄学，只讲你在实际开发中必须搞明白的那些概念。

2.1 对称加密：简单粗暴，但有个大麻烦

对称加密，说白了就是「一把钥匙开一把锁」。加密和解密用同一个密钥。

你想想看，A要给B发一条消息，先用密钥K加密，B收到后用同样的密钥K解密。这个过程很快，硬件实现也简单。UEFI里的某些变量存储、TPM通信，底层用的就是对称加密。

但对称加密有个致命问题：密钥怎么安全地传给对方？如果你和对方之间还没有建立安全通道，那第一次传输密钥的过程本身就是个死循环。这就是所谓的「密钥分发问题」。

2.2 非对称加密：公钥公开，私钥藏好

非对称加密的思路就巧妙多了。它用一对密钥：公钥（Public Key）和私钥（Private Key）。公钥可以公开给任何人，私钥只有你自己知道。

公钥加密的数据，只能用私钥解密。反过来，私钥签名的数据，可以用公钥验证。这两个方向，构成了UEFI Secure Boot的底层逻辑。

常用的非对称算法有RSA（最常见，UEFI Secure Boot默认支持）、ECC（椭圆曲线，密钥更短，效率更高）、SM2（国密）。

2.3 哈希函数：数据指纹，不可逆

哈希函数，你可以把它理解成给数据打一个「指纹」。不管输入多大，输出都是固定长度。而且，从哈希值几乎不可能反推出原始数据。

UEFI Secure Boot里，哈希函数用来做两件事：

• 完整性校验：验证固件镜像有没有被篡改
• 数字签名的前置步骤：先对镜像算哈希，再对哈希值签名（而不是直接签名整个镜像）

这里有个关键点：哈希碰撞。两个不同的数据算出同一个哈希值，就叫碰撞。理论上存在，但好的哈希算法（比如SHA-256）让碰撞在计算上不可行。我曾经在测试中故意修改一个UEFI驱动的二进制文件，只要改一个字节，哈希值就完全变了——这就是哈希的「雪崩效应」。

2.4 数字签名：用私钥给哈希值盖章

数字签名，本质上就是「用私钥加密数据的哈希值」。验证方用公钥解密签名，得到原始哈希值，再跟自己算出来的哈希值对比。一致，说明数据没被改过，而且确实是私钥持有者签的。

UEFI Secure Boot的签名验证流程，说白了就是三步：

1. 计算待加载镜像的哈希值（比如SHA-256）
2. 用公钥解密镜像附带的签名，得到原始哈希值
3. 对比两个哈希值，一致则通过，不一致则拒绝加载

2.5 公钥基础设施（PKI）：信任链的骨架

有了公钥、私钥、签名，还缺一个东西：你怎么知道某个公钥确实是某个厂商的？这就是PKI要解决的问题。

PKI的核心是「证书」和「证书链」。一个证书，就是把公钥和身份信息绑定在一起，并由一个可信的第三方（CA，证书颁发机构）签名。

UEFI Secure Boot的PKI结构是这样的：

• 根证书（Platform Key, PK）：由平台厂商（比如微软、OEM）内置在固件中，是整个信任链的起点
• 中间证书（Key Exchange Key, KEK）：由根证书签名，用于授权签名数据库的更新
• 签名数据库（db / dbx）：存放允许或禁止加载的签名/证书

你想想看，如果没有PKI，任何人都可以声称自己是Intel，然后签一个恶意驱动。有了PKI，系统只信任由根证书链验证过的签名。

2.6 知识体系总览

下面这张图，把这一章的核心概念串起来了。你可以看到，从哈希到签名，从对称到非对称，最后汇聚到PKI这个信任骨架。UEFI Secure Boot的每一环，都离不开这些基础。

2.7 小结：这些概念怎么串起来？

咱们用UEFI Secure Boot的实际场景，把这一章的知识点串一遍：

1. OEM厂商用私钥对固件镜像的哈希值做数字签名
2. 签名和镜像一起打包，发布给用户
3. UEFI固件启动时，用公钥（来自PKI证书链）验证签名
4. 验证通过，镜像被信任，加载执行
5. 验证失败，拒绝加载，系统可能进入恢复模式

整个过程，对称加密没怎么出现——因为Secure Boot是「验证」而非「加密」场景。但如果你要做固件更新包的加密传输，对称加密就派上用场了。