第三章 核心密码学原语：远程证明的基石
说实话，远程证明这东西，看着高大上，拆开来看，底层的密码学原语就那么几个。我经常跟团队里的小朋友说，你把这几个原语吃透了，远程证明的骨架你就搭起来了。哈希、签名、证书链、密钥协商——嗯，就是这些。
这一章，我们就来把这些“砖块”一块块掰开揉碎。别怕，咱们不讲那种让人昏昏欲睡的数学证明，只讲你在实战中必须知道的东西。
3.1 哈希函数：数据的“指纹”
哈希函数，说白了就是给任意长度的数据算出一个固定长度的“摘要”。这个摘要就像人的指纹，数据变一点点，指纹就面目全非。
在远程证明里，哈希函数干的事特别纯粹：保证完整性。你想想看，证明者要告诉验证者“我的代码是干净的”，那它就得先把代码的哈希值算出来，签上名，发给对方。对方一验，哈希对得上，说明代码没被篡改过。
3.1.1 SHA-256 与 SHA-384：选哪个？
目前最常用的就是 SHA-256 和 SHA-384。SHA-256 输出 256 位（32 字节），SHA-384 输出 384 位（48 字节）。
我个人习惯，在 TPM（可信平台模块）相关的远程证明场景里，SHA-256 是绝对的主流。但如果你在做一些高安全等级的系统，比如金融核心或者政府项目，我建议你直接上 SHA-384。为什么？因为 SHA-256 的碰撞攻击虽然在理论上可行，但 SHA-384 给了你更大的安全余量。
来看一个简单的哈希计算示例（Python）：
import hashlib
# 计算一段代码的 SHA-256 哈希值
code_blob = b"int main() { return 0; }"
hash_value = hashlib.sha256(code_blob).hexdigest()
print(f"SHA-256: {hash_value}")
# 哪怕只改一个字节
code_blob_modified = b"int main() { return 1; }"
hash_modified = hashlib.sha256(code_blob_modified).hexdigest()
print(f"Modified: {hash_modified}")
# 输出结果完全不同
# SHA-256: a1b2c3d4...
# Modified: e5f6g7h8...3.2 数字签名：身份的“印章”
哈希只能保证数据没被改，但没法证明这个数据是谁发的。这时候就需要数字签名出场了。
数字签名的逻辑很简单：私钥签名，公钥验签。私钥只有你自己有，所以你用私钥签了名，别人用你的公钥能验过，那这个数据就一定是你发的——这就是不可否认性。
3.2.1 RSA vs ECDSA：老牌劲旅与新锐力量
RSA 和 ECDSA 是目前最主流的两种签名算法。我列个表，你一看就明白：
| 特性 | RSA | ECDSA |
|---|---|---|
| 密钥长度 | 2048 / 4096 位 | 256 / 384 位 |
| 签名速度 | 较慢（尤其私钥操作） | 快 |
| 验签速度 | 快 | 较快 |
| 安全性基础 | 大整数分解 | 椭圆曲线离散对数 |
| 典型应用 | 传统 PKI、代码签名 | 区块链、IoT、现代 TPM |
我在实际项目中，如果是做传统的服务器端远程证明，RSA 2048 位依然很常见。但如果是做嵌入式设备或者 TPM 2.0 的远程证明，我强烈推荐 ECDSA。为什么？因为 ECDSA 的密钥短，签名也短，在带宽受限的环境下优势太明显了。
3.3 公钥基础设施（PKI）与证书链：信任的传递
好，现在你有签名了。但问题来了：验证者怎么知道你的公钥是真的？
这就是 PKI 要解决的问题。PKI 的核心思想是信任链。你不需要信任每一个终端设备，你只需要信任一个根 CA（证书颁发机构）。根 CA 给中间 CA 发证书，中间 CA 给设备发证书。一层层下来，就形成了一条证书链。
在远程证明里，这个过程是这样的：
- 设备（证明者）持有自己的私钥和由 CA 签发的设备证书。
- 设备向验证者发送：
设备证书 + 中间 CA 证书 + 签名数据。 - 验证者用自己信任的根 CA 证书，逐级验证证书链，直到确认设备证书是合法的。
- 然后用设备证书里的公钥，验证签名数据。
你看，信任就这样从根 CA 传递到了设备。
下面这张图，展示了典型的证书链结构：
3.4 非对称加密与密钥协商：建立安全通道
签名搞定了身份和完整性，但远程证明过程中，证明者和验证者之间往往需要交换一些敏感数据——比如会话密钥、度量日志。这些数据如果明文传输，那就等于裸奔。
这时候就需要非对称加密和密钥协商了。
3.4.1 非对称加密：公钥加密，私钥解密
非对称加密和签名正好反过来。签名是私钥签名、公钥验签；加密是公钥加密、私钥解密。
在远程证明里，一个典型场景是：验证者用证明者的公钥加密一个临时会话密钥，发给证明者。证明者用自己的私钥解密，拿到会话密钥。之后双方就用这个对称密钥进行加密通信，效率高得多。
3.4.2 密钥协商：双方一起算出一个秘密
另一种常见做法是密钥协商，最经典的就是 ECDH（椭圆曲线 Diffie-Hellman）。双方各自生成一对临时密钥对，交换公钥，然后各自用自己的私钥和对方的公钥算出同一个共享密钥。
我比较喜欢用 ECDH 做密钥协商，因为它提供了前向安全性——即使长期私钥泄露了，之前协商出来的会话密钥也不会被破解。这个特性在远程证明里特别重要。
3.5 密码学在远程证明中的角色：一张图说清楚
说了这么多，我们来总结一下。这些密码学原语在远程证明里到底扮演什么角色？
我画了张图，把整个流程串起来：
你看，整个远程证明的流程，其实就是这些密码学原语的一次“联合演出”：
- 哈希函数：负责度量，生成不可篡改的“指纹”。
- 数字签名：负责证明“指纹”是谁生成的，提供不可否认性。
- PKI 与证书链：负责把公钥和身份绑定起来，建立信任的传递路径。
- 非对称加密与密钥协商：负责保护通信过程，确保数据在传输中不被窃听或篡改。