2、密码学基础回顾：公钥基础设施(PKI)、数字签名、哈希函数在远程证明中的角色

各位同学，咱们今天聊点基础但极其重要的东西。远程证明协议，说白了就是让一个设备向另一个设备证明“我是我，我没被篡改”。这个信任链条怎么建立？靠的就是 PKI、数字签名和哈希函数这三驾马车。

我刚开始做 TPM（可信平台模块）相关项目时，总觉得这些基础概念太简单，结果在证书链验证上栽了个大跟头。嗯，从那以后我再也不敢小看这些“基础”了。

2.1 哈希函数：远程证明的“指纹”

哈希函数在远程证明里扮演什么角色？我习惯把它比作“数字指纹”。你想想看，一个设备的启动过程，从 BIOS 到操作系统，每个阶段的代码和配置都算出一个哈希值。这些值串起来，就是设备的“身份快照”。

远程证明的核心逻辑其实就一句话：比对哈希值。验证方拿到被验证方上报的哈希值，跟自己信任的“黄金参考值”一比对，就知道对方有没有被篡改。

这里有个坑，我必须要提醒你。后量子时代，传统的 SHA-256、SHA-3 虽然目前还算安全，但哈希函数的输出长度和抗碰撞性需要重新审视。我在做某个 IoT 平台升级时，就发现旧设备只支持 SHA-1，这玩意儿现在基本等于纸糊的。

2.2 数字签名：远程证明的“印章”

哈希值本身是明文，谁都能伪造。那怎么证明这个哈希值确实来自某个可信设备？靠数字签名。

数字签名的逻辑很简单：发送方用私钥对哈希值签名，接收方用公钥验签。在远程证明里，这个流程通常是：

1. 设备 A 生成自己的度量值（哈希列表）
2. 设备 A 用私钥对度量值签名，生成 Quote 结构
3. 设备 A 把 Quote + 度量值 + 证书发给验证方 B
4. 验证方 B 用证书里的公钥验签，确认度量值未被篡改

我参与过一个基于 Intel SGX 的远程证明项目，里面用的就是 ECDSA 签名。当时觉得 ECDSA 够快了，但后量子时代一来，事情就变了。

2.3 公钥基础设施(PKI)：远程证明的“信任锚”

数字签名解决了“谁签的”问题，但没解决“这个公钥是谁的”问题。PKI 就是干这个的——它提供了一条可追溯的信任链。

远程证明里最常见的 PKI 结构是这样的：

• 根 CA：离线保存，签发中间 CA 证书
• 中间 CA：签发设备证书
• 设备证书：绑定设备的公钥和身份信息
• 证书撤销列表(CRL)：标记被吊销的设备证书

验证方拿到设备证书后，沿着证书链一路验证到根 CA。只要根 CA 可信，整条链就可信。这就是远程证明的“信任锚”。

我曾经在一个项目中，发现设备上报的证书链不完整——少了中间 CA 证书。验证方没法构建完整的信任路径，直接拒绝。后来我们在协议里加了一条规则：证书链必须完整，不能依赖验证方自己去下载。

2.4 三者在远程证明中的协同工作

光说概念太抽象，咱们画个图看看这三者怎么配合的。

你看这个流程，每一步都环环相扣。哈希函数保证“度量值没变”，数字签名保证“度量值来自可信设备”，PKI 保证“公钥确实属于这个设备”。缺一个，信任链就断了。

2.5 后量子时代的挑战

聊完基础，咱们得面对现实。量子计算机对这三样东西的威胁有多大？

密码学组件	量子威胁	后量子替代方案
哈希函数(SHA-256)	Grover 算法将安全强度减半	SHA-3、SHAKE256（输出长度加倍）
数字签名(ECDSA/RSA)	Shor 算法可破解离散对数和大整数分解	Dilithium、Falcon、SPHINCS+
PKI(X.509证书链)	证书签名算法被破解，整条链失效	混合证书、量子签名算法证书

我个人的建议是：不要等到量子计算机真来了再动手。现在就开始做“密码敏捷性”设计——让你的远程证明协议能平滑切换算法。我在做某个云平台的可信启动方案时，就提前预留了算法协商字段，后来切换到 Dilithium 时只改了配置，没动协议框架。