3. 密码学基础回顾：哈希函数、数字签名、公钥基础设施（PKI）在证明中的作用

聊远程证明，绕不开密码学。说白了，远程证明就是一场密码学协议的合谋。我见过不少团队，架构图画得漂亮，但一深究底层密码原语怎么选、怎么配，就露怯了。今天咱们把三个核心工具——哈希、签名、PKI——在证明里的角色彻底捋一遍。

3.1 哈希函数：证明的「指纹」

哈希函数在远程证明里干的事，用一句话就能说清：给任意大的数据打一个固定长度的「摘要」。这个摘要就是数据的指纹，独一无二。

我在项目里遇到过有人用 MD5 做固件哈希校验，结果被轻松碰撞攻击。嗯，这里要注意：远程证明里哈希函数必须用 SHA-256 或更强的。SHA-1 已经退役了，别再用。

哈希在证明里的典型用法：

• 度量值：把代码、配置、数据逐段哈希，得到一组度量值（Measurement）。
• 引用值：把「已知良好」的版本同样哈希，作为比对基准。
• 证据压缩：把一大段日志或事件序列哈希成一个值，再签名，省带宽。

3.2 数字签名：证明的「印章」

哈希只能保证数据没被改，但没法证明「是谁给的」。数字签名就是干这个的——用私钥签名，用公钥验签。你想想看，如果验证方能拿到一个可信的公钥，那签名就能证明三件事：

1. 真实性：数据确实来自声称的签名者。
2. 完整性：数据在签名后没被篡改。
3. 不可否认性：签名者事后不能抵赖。

远程证明里，签名通常用在两个地方：

• 证明请求签名：证明方（Attester）用自己身份私钥签名度量值，生成证明断言（Attestation）。
• 证书签名：CA 用其私钥签发身份证书，绑定公钥和身份信息。

下面这张图展示了哈希和签名在远程证明中的协作流程：

3.3 公钥基础设施（PKI）：信任的「锚」

签名再强，如果公钥是假的，一切白搭。PKI 就是解决这个问题的——建立一个可信的第三方（CA）来签发和验证证书。

远程证明里的 PKI 通常长这样：

组件	角色	在证明中的用途
根 CA	信任锚	签发中间 CA 证书，离线保存
中间 CA	证书签发	签发设备身份证书，可在线
设备证书	身份凭证	绑定设备公钥与身份信息
证书吊销列表（CRL）	撤销机制	标记已泄露或退役的设备

3.4 三者如何协同工作

哈希、签名、PKI 在远程证明里不是各自为战，而是层层递进：

1. 哈希：把「我是什么状态」压缩成一个固定长度的度量值。
2. 签名：用私钥给度量值盖章，证明「这个状态是我声明的」。
3. PKI：通过证书链把公钥绑定到可信根，证明「这个我就是可信的那个我」。

你想想看，如果缺了任何一环：

• 没哈希：签名内容太大，效率低，而且没法做细粒度比对。
• 没签名：度量值可以被中间人篡改，证明毫无意义。
• 没 PKI：你拿到一个公钥，但不知道它属于谁，信任无从建立。

3.5 常见误区与避坑

最后分享几个我踩过的坑：

• 误区一：哈希越长越安全。SHA-512 不一定比 SHA-256 更适合远程证明。很多 TPM 硬件只加速 SHA-256，用 SHA-512 反而慢。选硬件支持的。
• 误区二：签名算法越新越好。Ed25519 确实快，但有些老旧验证方不支持。我建议在协议设计阶段就明确算法套件，别等集成时才发现不兼容。
• 误区三：PKI 就是证书链。证书链只是 PKI 的一部分。CRL、OCSP、证书透明度（CT）这些配套机制同样重要。我曾经见过一个项目，证书链配得完美，但吊销机制没做，结果被重放攻击打穿。