核心密码学基础：哈希函数、非对称加密、数字签名、证书链（X.509）
聊远程证明，绕不开密码学。很多人觉得密码学是数学家的玩具，离工程很远。其实不然。我做了这么多年安全，最深的体会是：远程证明的每一层信任，最终都落在几个基础密码学原语上。你如果不理解哈希、非对称加密、数字签名和证书链，那远程证明对你来说就是个黑盒子。
这一节，咱们把这四个东西拆开揉碎。我不讲复杂的数学公式，只讲它们在远程证明里到底怎么用，以及我踩过的坑。
1. 哈希函数：数据的「指纹」
哈希函数，说白了就是给一段数据算一个固定长度的摘要。你输入任意长度的数据，它输出一个固定长度的字符串（比如 SHA-256 输出 256 位）。而且这个函数是单向的——从摘要反推原始数据，几乎不可能。
在远程证明里，哈希函数干三件事：
- 度量完整性：设备启动时，把 BIOS、引导加载程序、操作系统内核依次哈希，得到一组度量值。这些值就是设备的「指纹」。如果有人篡改了固件，哈希值就会变。
- 压缩签名数据：数字签名一般不直接签整个文件，而是先对文件做哈希，再签名这个哈希值。这样效率高得多。
- 构建信任链：在 TPM（可信平台模块）里，度量值被扩展到平台配置寄存器（PCR）中，用的就是哈希链。
关键点：远程证明里，验证方拿到的是设备的哈希度量值。如果这些值和预期值一致，说明设备没有被篡改。但前提是——哈希算法本身要安全。
我的经验：我曾经在一个项目里用了 SHA-1 做度量，结果被安全审计直接打回。SHA-1 已经被证明存在碰撞攻击。现在业界最低标准是 SHA-256。别图省事用旧算法，否则你的远程证明就是纸糊的。
2. 非对称加密：公钥和私钥的「双钥匙」机制
对称加密用一把钥匙加密解密，非对称加密用两把：公钥和私钥。公钥可以公开，私钥必须保密。用公钥加密的数据，只有对应的私钥能解密；反过来，用私钥签名的数据，只有对应的公钥能验证。
在远程证明里，非对称加密解决了一个核心问题：如何在不安全的信道上建立信任。
具体场景：
- 身份认证：设备持有私钥，验证方用公钥验证设备的身份。私钥如果泄露，设备就不再可信。
- 密钥协商：远程证明过程中，设备和验证方需要建立安全通道。通常用非对称加密交换对称密钥。
- 签名验证：设备用私钥对度量值签名，验证方用公钥验签。
| 算法 | 密钥长度 | 安全性 | 远程证明中的典型用途 |
|---|---|---|---|
| RSA | 2048 / 4096 位 | 成熟，但密钥较长 | 签名验证、密钥传输 |
| ECC（椭圆曲线） | 256 / 384 位 | 同等安全强度下密钥更短 | IoT 设备、TPM 签名 |
| Ed25519 | 256 位 | 高性能，抗侧信道攻击 | 现代远程证明协议（如 TPM 2.0） |
注意：RSA 1024 位已经被认为不安全。我见过一些老旧设备还在用 1024 位的 RSA 密钥，这在远程证明里是致命漏洞。建议至少用 RSA 2048 或 ECC P-256。
3. 数字签名：证明「谁说了什么」
数字签名，本质上是用私钥对数据的哈希值做加密操作。验证方用公钥解密，比对哈希值是否一致。如果一致，说明：
- 数据没有被篡改（完整性）。
- 数据确实来自持有私钥的一方（真实性）。
- 私钥持有者不能否认自己签过（不可否认性）。
在远程证明里，数字签名是信任的载体。设备把度量值、设备 ID、时间戳等信息打包，用私钥签名，然后发给验证方。验证方验签通过，才相信这些数据是真实的。
核心流程：
- 设备计算度量值的哈希。
- 设备用私钥对哈希值签名。
- 设备把原始度量值 + 签名一起发给验证方。
- 验证方用设备的公钥验签，比对哈希值。
这里有个坑：签名本身不保证数据的新鲜性。攻击者可以截获一次合法的签名数据，然后重放。所以远程证明协议里一定要加随机数（nonce）或时间戳。我见过一个项目，就是因为没加 nonce，被重放攻击打穿了。
避坑指南：我曾经在一个远程证明方案里，只签了度量值，没签时间戳。结果攻击者把旧度量值重放，验证方以为设备还是「干净」的。后来我强制要求签名数据里必须包含一个由验证方生成的随机数。这个教训，花了我两周时间修 bug。
4. 证书链（X.509）：从「谁」到「可信谁」
数字签名解决了「谁说了什么」，但没解决「这个谁是否可信」。你拿到一个公钥，怎么知道这个公钥真的属于那台设备？
答案就是证书链。X.509 证书把公钥和身份绑定在一起，并由一个可信的第三方（CA，证书颁发机构）签名。证书链就是一层层往上追溯，直到一个你信任的根 CA。
在远程证明里，证书链的典型结构：
- 根 CA 证书：自签名，是信任的锚点。通常预置在验证方或设备中。
- 中间 CA 证书：由根 CA 签发，用于签发设备证书。这样做的好处是，即使中间 CA 被攻破，根 CA 可以吊销它，不影响其他中间 CA。
- 设备证书：由中间 CA 签发，包含设备的公钥和身份信息。设备在远程证明时，把自己的证书和中间 CA 证书一起发给验证方。
验证方收到证书链后，做以下检查：
- 验证设备证书的签名是否来自中间 CA。
- 验证中间 CA 证书的签名是否来自根 CA。
- 检查证书是否在有效期内。
- 检查证书是否被吊销（通过 CRL 或 OCSP）。
- 确认根 CA 在验证方的信任列表中。
一句话总结：证书链把「信任」从根 CA 传递到设备。只要根 CA 可信，整个链条上的设备就都可信。
这里我画了一张图，帮你理解证书链的层级关系：
在实际的远程证明系统里，证书链的管理是个大工程。我见过不少团队，证书链搭好了，但证书吊销没做。设备被攻破后，私钥泄露，攻击者拿着旧证书还能通过验证。这就是为什么 CRL（证书吊销列表）和 OCSP（在线证书状态协议）必须部署。
重要提醒：证书链不是越长越好。每多一级，验证时间就多一次网络请求（如果是 OCSP）或本地校验。在 IoT 场景里，证书链最好控制在 3 级以内（根 CA → 中间 CA → 设备）。否则设备启动时，光验证证书链就要好几秒，用户体验极差。
5. 四个原语如何协同工作
这四个密码学原语不是孤立的。在远程证明里，它们配合起来形成一个完整的信任闭环：
- 哈希函数：度量设备状态，生成不可篡改的「指纹」。
- 非对称加密：提供公钥/私钥对，让设备能证明自己的身份。
- 数字签名：用私钥对度量值签名，保证数据的真实性和完整性。
- 证书链：把设备的公钥和身份绑定到可信的根 CA 上，解决「这个公钥是谁的」问题。
举个例子，TPM 远程证明的典型流程：
- TPM 芯片内部存储了设备的私钥（永远不导出）。
- 设备启动时，TPM 度量固件和操作系统，把度量值扩展到 PCR。
- 验证方发起挑战，发送一个随机数。
- TPM 用私钥对 PCR 值 + 随机数签名，生成一个「引用」（quote）。
- 设备把引用、度量值日志、设备证书一起发给验证方。
- 验证方验签、验证证书链、比对度量值是否和预期一致。
你看，四个原语一个都没少。而且每一步都有坑——签名不加随机数会被重放，证书不检查吊销会被冒用，哈希算法太弱会被碰撞。这些坑，我基本都踩过一遍。
我的建议：如果你刚开始做远程证明，别急着写代码。先把这四个原语的关系理清楚。画一张图，标出每个环节用哪个原语，数据流向是什么，信任从哪里来。这张图画清楚了，代码实现就是体力活。