📚 课程目录第3章密码学基础回顾

密码学基础回顾：远程证明的基石

各位同学，欢迎来到第三章。在开始搭建远程证明系统之前，我们必须先把工具箱里的几样核心工具摸透。说白了，远程证明的本质就是一场密码学协议——你向对方证明“我是我，我没被篡改”。没有这些基础，后面的一切都是空中楼阁。

我个人习惯把密码学基础比作乐高积木。哈希、非对称加密、数字签名、证书、随机数，这几块积木搭在一起，才能拼出远程证明这个复杂的模型。咱们一个一个来看。

  核心观点： 远程证明的信任链，完全建立在这五个密码学原语之上。任何一个环节出问题，整个系统就不可信了。

3.1 哈希函数：数据的“指纹”

哈希函数，你肯定不陌生。它能把任意长度的数据，压缩成一个固定长度的摘要。这个摘要就像数据的指纹——内容变了，指纹一定变。

我遇到过不少刚入行的同学，觉得哈希就是“加密”。其实不是。哈希是单向的，你没法从摘要反推出原文。远程证明里，我们用它来度量系统状态——比如计算某个固件镜像的哈希值，然后跟预期值比对，就知道它有没有被篡改。

常用的哈希算法有 SHA-256、SHA-3。SHA-1 已经退役了，别再用。

避坑指南： 我曾经在一个项目里看到有人用 MD5 做固件校验，结果被哈希碰撞攻击轻松绕过。记住：远程证明场景下，至少用 SHA-256。

哈希函数有几个关键性质：

抗原像性： 给定 y，找不到 x 使得 H(x)=y
抗第二原像性： 给定 x，找不到 x'≠x 使得 H(x')=H(x)
抗碰撞性： 找不到任意两个不同的 x 和 x' 使得 H(x)=H(x')

在远程证明的度量环节，我们通常这样用：

# 伪代码：度量一个二进制文件的完整性
file_hash = SHA256(binary_file)
expected_hash = 0xABCD...  # 从安全启动链中获取
if file_hash == expected_hash:
    print("文件未被篡改")
else:
    print("文件已被篡改，拒绝加载")

3.2 非对称加密：公钥与私钥的默契

非对称加密，说白了就是一对钥匙——公钥公开，私钥保密。用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥签名的数据，公钥可以验证。

你想想看，远程证明里为什么需要这个？因为我们要在不可信的网络通道上建立信任。设备把它的公钥发给你，你用这个公钥加密一个挑战值发回去，设备能用私钥解密并返回结果——这就证明了它持有私钥，也就是证明了它的身份。

常用的算法有 RSA 和 ECC。我个人更倾向 ECC，同样的安全强度下，密钥更短，计算更快。在资源受限的 TEE 环境里，ECC 优势明显。

算法	密钥长度（安全强度 128 位）	签名速度	验证速度
RSA	3072 位	慢	快
ECC (P-256)	256 位	快	较快

注意： 非对称加密的计算开销远大于对称加密。远程证明中，我们通常只用它来协商会话密钥或验证签名，真正的数据传输用对称加密。

3.3 数字签名：防抵赖的“电子印章”

数字签名，本质上是哈希函数和非对称加密的组合。流程很简单：

发送方对消息计算哈希值
用私钥加密这个哈希值，得到签名
接收方用公钥解密签名，得到哈希值
接收方自己计算消息的哈希值，比对两者是否一致

如果一致，说明消息确实来自私钥持有者，且未被篡改。这就是远程证明的核心逻辑——设备用它的私钥签名一份度量报告，验证方用设备的公钥验证签名，就能确认报告的真实性。

我记得有一次调试一个远程证明协议，发现签名验证总是失败。查了半天，原来是签名时用的哈希算法和验证时用的不一致——一个用了 SHA-256，一个用了 SHA-384。嗯，这种细节问题最容易坑人。

# 伪代码：签名与验证
# 签名
message = "度量报告: 哈希值=0x1234, 时间戳=1700000000"
signature = RSA_sign(private_key, SHA256(message))

# 验证
expected_hash = RSA_verify(public_key, signature)
actual_hash = SHA256(message)
if expected_hash == actual_hash:
    print("签名验证通过，报告可信")
else:
    print("签名验证失败，报告可能被篡改")

3.4 证书（X.509）：把公钥和身份绑定

光有公钥还不够。你怎么知道这个公钥就是属于声称的那个设备？万一中间人给你一个假公钥呢？

证书就是来解决这个问题的。X.509 证书把公钥和身份信息绑定在一起，并由一个可信的第三方（CA）签名。证书链的信任传递，是远程证明信任模型的基石。

一个典型的 X.509 证书包含：

版本号、序列号
签名算法标识
颁发者（CA）名称
有效期（开始和结束时间）
主体（设备）名称
主体公钥信息
CA 的数字签名

在远程证明中，设备通常持有由设备制造商签发的证书。验证方通过验证证书链——从设备证书到根 CA 证书——来确认设备公钥的真实性。

经验之谈： 我曾经见过一个系统，证书有效期检查没做，结果用了一张过期三年的证书还能通过验证。记住：验证证书时，一定要检查有效期、吊销状态和证书链完整性。

3.5 随机数：安全协议的“盐”

随机数看似不起眼，但它是安全协议里不可或缺的调味料。没有好的随机数，你的加密、签名、密钥生成全都会出问题。

远程证明里，随机数主要用在两个地方：

挑战-响应协议： 验证方生成一个随机挑战值发给设备，设备用私钥签名后返回。这个随机数防止了重放攻击——如果挑战值每次都一样，攻击者可以录下签名结果反复使用。
密钥生成： 生成非对称密钥对时，需要高质量的随机数作为种子。如果随机数可预测，攻击者就能复现你的私钥。

我遇到过最离谱的一次，是某款 IoT 设备的随机数生成器因为硬件 bug，每次上电都生成相同的“随机数”。结果所有设备的私钥都一样——你想想看，这等于一把钥匙能开所有锁。

警告： 永远不要用 rand() 或 Math.random() 这类伪随机数生成器做安全用途。必须使用密码学安全的随机数生成器（CSPRNG），比如 Linux 的 /dev/urandom 或硬件 TRNG。

3.6 知识体系总览

下面这张图，把五个基础概念和它们在远程证明中的角色串起来了。你可以把它当作本章的思维导图。

3.7 小结

这一章我们回顾了五个密码学基础概念。哈希函数负责度量，非对称加密负责身份验证，数字签名负责完整性，证书负责信任链，随机数负责防重放。它们不是孤立存在的——在远程证明协议里，这五者会紧密配合，形成一个完整的信任闭环。

我个人建议你花点时间把这几块积木的原理彻底搞懂。后面讲到具体的远程证明协议（比如 TPM 远程证明、Intel SGX 远程证明）时，你会发现它们本质上就是这些基础概念的组合应用。基础不牢，地动山摇——这句话在安全领域尤其适用。