2. 密码学基础回顾：对称与非对称加密、哈希函数、数字签名、公钥基础设施(PKI)
聊远程证明和密钥轮换之前，咱们得先把密码学底子夯实了。说实话，我见过不少工程师一上来就撸代码，结果密钥存储、签名验证这些基础环节出了纰漏，整个安全体系直接崩塌。所以这一节，咱们把对称加密、非对称加密、哈希、数字签名、PKI 这几个核心概念过一遍。我会结合自己踩过的坑来讲，希望能帮你少走弯路。
2.1 对称加密：快，但密钥怎么分？
对称加密，说白了就是加密和解密用同一把钥匙。你想想看，就像你用一把锁锁住箱子，再用同一把钥匙打开它。优点是快，特别快。AES-256 在硬件加速下，每秒能处理几个 G 的数据。
但问题来了——密钥怎么安全地分给通信双方？我在早期做物联网项目时，就遇到过这个难题。设备出厂时预置了一个对称密钥，结果生产环节管理不善，密钥被泄露了，整批设备都得召回。嗯，那叫一个惨。
常用对称加密算法：
- AES（高级加密标准）：目前最主流，密钥长度 128/192/256 位
- SM4：国密标准，国内商用场景常用
- ChaCha20：流密码，移动端性能优异
我的建议：对称加密只适合在已经建立安全信道的场景下使用。比如 TLS 握手完成后，用对称加密传输实际数据。千万别把对称密钥硬编码在客户端代码里——我曾经在某个 App 里发现过，那感觉就像看到自家大门钥匙挂在门外。
2.2 非对称加密：慢，但能解决密钥分发
非对称加密引入了“公钥”和“私钥”这对概念。公钥可以公开，私钥必须保密。用公钥加密的数据，只有对应的私钥能解开；反过来，用私钥签名的数据，公钥可以验证。
这解决了对称加密最头疼的密钥分发问题。你不需要提前和对方共享密钥，直接把公钥扔出去就行。但代价是慢——RSA 2048 位加密，比 AES-256 慢上千倍。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个（共享密钥） | 2 个（公钥 + 私钥） |
| 速度 | 快（硬件加速可达 Gbps） | 慢（通常用于小数据量） |
| 密钥分发 | 困难，需要安全信道 | 容易，公钥可公开 |
| 典型算法 | AES, SM4, ChaCha20 | RSA, ECC, SM2 |
| 典型用途 | 批量数据加密 | 密钥交换、数字签名 |
避坑指南：我曾经见过有人用 RSA 直接加密大文件，结果性能惨不忍睹。正确的做法是“混合加密”：用非对称加密交换对称密钥，再用对称加密处理实际数据。TLS 就是这么干的。
2.3 哈希函数：不可逆的“指纹”
哈希函数能把任意长度的数据，映射成一个固定长度的摘要。而且这个过程是单向的——你没法从摘要反推出原始数据。哪怕原始数据只改了一个比特，摘要也会面目全非。
哈希在安全领域无处不在：密码存储、数据完整性校验、数字签名、区块链……我记得有一次做固件升级系统，就是用 SHA-256 校验固件包的完整性。如果哈希对不上，直接拒绝升级，防止被植入恶意代码。
常用哈希算法：
- SHA-256：目前最安全的选择，输出 256 位
- SM3：国密哈希标准，输出 256 位
- BLAKE2：比 SHA-256 更快，适合高性能场景
注意：MD5 和 SHA-1 已经被证明不安全，别再用了。我去年审计一个老系统，发现还在用 MD5 做签名，当场就建议客户升级。碰撞攻击不是闹着玩的。
2.4 数字签名：证明“你是谁”和“你没改过”
数字签名结合了哈希和非对称加密。流程是这样的：
- 发送方对消息做哈希，得到摘要
- 用私钥对摘要加密，生成签名
- 接收方用公钥解密签名，得到摘要 A
- 接收方自己对消息做哈希，得到摘要 B
- 如果 A == B，说明消息没被篡改，且确实来自私钥持有者
这就同时提供了身份认证和完整性保护。远程证明的核心机制之一，就是靠数字签名来证明“我是我，我没被篡改”。
我曾经踩过的坑：签名时一定要带上时间戳或随机数（nonce），否则攻击者可以重放签名。有一次做 API 签名验证，忘了加 nonce，结果被安全团队发现后直接打回重做。嗯，从那以后我再也不敢忘了。
2.5 公钥基础设施(PKI)：谁来证明公钥是真的？
非对称加密解决了密钥分发问题，但引入了一个新问题：你怎么知道你拿到的公钥真的是对方的？中间人完全可以伪造一个公钥给你。
PKI 就是解决这个问题的。它引入了一个可信第三方——证书颁发机构（CA）。CA 用自己的私钥给你的公钥签名，生成一张数字证书。别人拿到你的证书，只要信任 CA，就能验证证书上的签名，从而确认公钥的真实性。
证书链的结构是这样的：
- 根 CA：自签名证书，是信任的锚点
- 中间 CA：由根 CA 签发，用于分担风险
- 终端实体证书：由中间 CA 签发，给具体的设备或服务使用
PKI 的核心组件：
- CA（证书颁发机构）：签发和吊销证书
- RA（注册机构）：验证申请者身份
- 证书库：存储和分发证书
- CRL/OCSP：证书吊销列表/在线证书状态协议，用于检查证书是否被吊销
下面这张图展示了 PKI 证书链的信任关系：
实际项目中的 PKI：在远程证明场景里，设备通常预置了根 CA 证书。当设备启动时，它用这个根证书验证远程服务端下发的证书链。如果验证通过，说明服务端是可信的。反过来，服务端也可以用同样的方式验证设备。这就是双向认证。
2.6 这些基础怎么用在远程证明里？
咱们简单串一下。远程证明的核心，就是让一个实体（比如设备）向另一个实体（比如服务器）证明自己的身份和状态是可信的。这个过程依赖：
- 非对称加密：设备持有私钥，服务器持有公钥。设备用私钥签名一个“证明报告”，服务器用公钥验证签名。
- 哈希函数：对设备的固件、配置、度量值做哈希，确保报告内容的完整性。
- 数字签名：设备对哈希后的度量值签名，证明这些度量值确实来自该设备。
- PKI：通过证书链验证设备的公钥是否真实可信，防止中间人攻击。
一句话总结：远程证明 = 度量（哈希）+ 签名（非对称）+ 信任链（PKI）。这三者缺一不可。
好了，密码学基础就回顾到这里。这些概念在后面讲远程证明协议、密钥轮换策略时会反复用到。如果你对某个点还不熟，我建议你动手写个小 demo 试试——比如用 OpenSSL 生成自签名证书、做一次签名验证。实践出真知，光看文档是不够的。