3、核心密码学基础：哈希函数、数字签名、公钥基础设施（PKI）、证书链
远程证明这件事，说白了就是让一个设备向验证方证明“我是我，我没被篡改”。这背后靠的是什么？就是密码学。我经常跟团队里的新人说，不懂哈希和签名，就别谈远程证明。这一章咱们就把这几个核心概念掰开揉碎讲清楚。
3.1 哈希函数：数据的“指纹”
哈希函数，你想想看，它就像一个单向的碎纸机。你塞进去一份文件，出来一串固定长度的数字。而且这个操作不可逆——你没法从这串数字把原文件拼回来。
我习惯把哈希函数比作人的指纹。每个人的指纹都是独一无二的，文件也一样。哪怕你只改了一个比特，哈希值就会变得面目全非。这就是所谓的雪崩效应。
哈希函数在远程证明中的角色：
- 完整性校验：验证固件、启动代码有没有被改过
- 数据摘要：对大量数据做摘要，减少签名负担
- 身份绑定：将设备身份与度量值绑定在一起
目前业界常用的哈希算法有 SHA-256、SHA-384。SHA-1 已经退役了，别再用。我在一个物联网项目里见过有人还在用 MD5，当时我就说，这跟没锁门有什么区别？
| 算法 | 输出长度 | 安全状态 | 推荐场景 |
|---|---|---|---|
| MD5 | 128 位 | 已破解，不推荐 | 仅用于非安全校验 |
| SHA-1 | 160 位 | 已破解，不推荐 | 遗留系统兼容 |
| SHA-256 | 256 位 | 安全 | 远程证明首选 |
| SHA-384 | 384 位 | 安全 | 高安全场景 |
我的经验：做设备证明时，别只哈希一次。我习惯把多个度量值（如 Boot ROM、Boot Loader、OS 内核）串起来做一次复合哈希，这样签名只需要做一次，效率高很多。
3.2 数字签名：谁签的，谁负责
哈希能保证数据没被改，但保证不了数据是谁发的。这时候就需要数字签名了。
数字签名的原理其实不复杂：发送方用私钥对数据的哈希值加密，接收方用公钥解密验证。能解密成功，就说明数据确实是用对应的私钥签的。
我举个例子。你在网上买了个智能门锁，厂家在固件上签了名。门锁启动时，它用内置的公钥验证签名。签名对得上，固件才运行。这就是远程证明最朴素的形式。
注意：签名算法也有强弱之分。RSA-2048 目前还算安全，但我建议新项目直接上 ECDSA（椭圆曲线数字签名算法）。同样的安全强度，密钥更短，计算更快。我在一个资源受限的 MCU 项目里用过 ECDSA，效果比 RSA 好太多。
3.3 公钥基础设施（PKI）：信任的起点
好，现在问题来了。设备里那个公钥，怎么来的？谁保证它是真的？
这就是 PKI 要解决的问题。PKI 是一套管理密钥和证书的体系。它的核心是证书颁发机构（CA）。CA 是一个大家都信任的第三方，它负责签发证书，证明“这个公钥属于这个设备”。
我习惯把 PKI 比作身份证系统。公安局（CA）给你发身份证（证书），身份证上有你的照片和身份证号（公钥）。别人看到你的身份证，就知道你是谁。
PKI 的核心组件：
- CA（证书颁发机构）：签发和吊销证书
- RA（注册机构）：验证申请者身份
- 证书库：存储已签发的证书
- CRL/OCSP：证书吊销列表/在线状态查询
在设备远程证明里，PKI 的作用就是建立信任链。设备出厂时，CA 给设备签发一个证书。验证方只要信任这个 CA，就信任设备。
3.4 证书链：层层递进的信任
你想想看，如果全世界只有一个 CA，那它要是被攻破了，整个体系就完了。所以实际部署中，我们用的是证书链。
证书链的结构是这样的：
- 根 CA：自签名证书，是整个信任链的锚点
- 中间 CA：由根 CA 签发，用于分担风险
- 终端实体证书：由中间 CA 签发，发给具体设备
验证的时候，从设备证书开始，逐级向上验证，直到信任的根证书。这个过程叫证书路径验证。
我曾经在一个车联网项目里踩过坑。当时我们只用了两级证书链，结果中间 CA 的私钥泄露了，不得不吊销所有下级证书。后来我学乖了，至少用三级：根 CA 离线存储，中间 CA 在线服务，设备证书按批次签发。这样即使中间 CA 出问题，根 CA 还在，重建成本低很多。
3.5 证书格式与 X.509
说到证书，就绕不开 X.509 标准。这是目前最通用的证书格式。一个 X.509 证书包含以下关键字段：
| 字段 | 说明 | 在远程证明中的用途 |
|---|---|---|
| 版本号 | V1/V2/V3 | V3 支持扩展，推荐使用 |
| 序列号 | CA 分配的唯一编号 | 用于吊销查询 |
| 签名算法 | 如 sha256WithRSAEncryption | 指定签名算法 |
| 颁发者 | 签发该证书的 CA 名称 | 构建证书链 |
| 有效期 | 起止时间 | 检查证书是否过期 |
| 主体 | 证书持有者名称 | 标识设备身份 |
| 公钥 | 持有者的公钥 | 验证签名 |
| 扩展 | 密钥用途、基本约束等 | 限制证书用途 |
避坑指南：我曾经见过一个设备，证书里没设置密钥用途扩展（Key Usage），结果有人拿设备证书去签固件，造成安全漏洞。记住，设备证书一定要加上 digitalSignature 用途，CA 证书要加上 keyCertSign 和 cRLSign。
3.6 证书生命周期管理
证书不是永久的。它有生命周期。我习惯把证书管理分成四个阶段：
- 签发：设备生产时，CA 为每个设备生成密钥对并签发证书
- 部署：将证书和私钥安全写入设备（私钥绝不能明文传输）
- 使用：设备在远程证明时出示证书，验证方验证证书链
- 吊销/更新：证书过期或私钥泄露时，吊销旧证书，签发新证书
嗯，这里要注意。很多团队只关注签发和部署，忽略了吊销。结果设备被攻破了，证书还在有效期内，攻击者照样能冒充设备。我建议每个项目都要部署 OCSP（在线证书状态协议）或 CRL（证书吊销列表）。
3.7 小结
这一章的内容，说白了就是远程证明的密码学地基。哈希函数保证数据没被改，数字签名保证数据是谁发的，PKI 和证书链保证公钥是真的。这三样东西缺一不可。