电子签名基础：数字签名原理与PKI
说实话，很多人一上来就问我：“电子签名到底是怎么保证签了就不能赖账的？”
嗯，我们先不急着谈HSM，先把最底层的东西理清楚。你想想看，如果连数字签名是怎么工作的都不清楚，后面封装接口肯定要踩坑。
数字签名原理：一句话讲清楚
数字签名本质上就是两件事：哈希 + 非对称加密。
哈希保证内容没被改过，非对称加密保证是你本人签的。
我当年刚入门时，总把“签名”和“加密”搞混。后来带我的老工程师说了句特形象的话——加密是把信锁进保险柜，签名是在信封上盖个章。从此再没忘过。
签名过程（你发消息时做的事）
- 把原文算一个哈希值（比如SHA-256）
- 用你自己的私钥把这个哈希值加密，得到“数字签名”
- 把原文和签名一起发给对方
验签过程（对方收到后做的事）
- 用你的公钥解密签名，得到你当初算的那个哈希值
- 自己对原文再算一次哈希值
- 两个哈希值比一比——一样就是真签，不一样就是被篡改或冒签
核心公式：
验证通过 ⇔ Hash(原文) == 公钥解密(签名)
为什么会这样？因为私钥只有你一个人有。别人即使拿到了原文和签名，没有私钥也伪造不了同样的签名。反过来，如果你把私钥弄丢了……嗯，我在项目里就见过有人把U盾里存私钥的配置文件当垃圾清掉了，结果所有已签文件统统变成“不可验证”。私钥就是命根子，一定得放HSM里锁好。
公钥基础设施（PKI）简介
好了，现在你知道了签名原理。但有一个现实问题——你怎么知道那个公钥真的是张三的？
网络世界里，万一中间人把自己的公钥假装成张三的给你，你拿那个公钥去验签，那不就被骗了吗？
PKI就是专门来解决这个信任问题的。
说白了，它是一套发证书、管证书、查证书的体系。我参与过一个企业级证书管理系统，每天签发上万张证书，PKI的每个环节都踩过坑，下面给你拆开讲。
PKI的四大角色
| 角色 | 做什么 | 我遇到的坑 |
|---|---|---|
| CA（证书颁发机构） | 签发、吊销证书，是整个信任链的根 | 有一次根CA证书过期了，下面所有子CA签的证书全被客户端报不安全，紧急换根花了三天 |
| RA（注册机构） | 审核用户身份，帮用户向CA申请证书 | RA和CA之间的通信如果没做双向认证，容易被中间人冒充，这个坑在等保测评里被重点提过 |
| 证书持有者 | 自己保管私钥，用证书证明身份 | 很多开发者把私钥和证书放在同一个目录下，这是大忌——应该在HSM里生成私钥，证书和公钥可以公开 |
| 依赖方（验证者） | 拿到证书后，验证签名链是否有效 | 依赖方如果没配置CRL或OCSP，等出事了才发现证书早就被吊销了 |
证书链：信任是怎么传递的
想象一个树状结构：
根CA（自签名） → 二级CA → 三级CA → 最终用户证书。
验签时，依赖方会从用户证书开始，一级一级往上追溯，直到找到本地信任的根证书。这条路径就叫证书链。
我在项目中的教训：
曾经有个客户说“我明明装了根证书，为什么还报信任错误？”
排查了半天，发现他装的根证书是旧版本，而用户证书是用新根签发的——新旧根的公钥不同，链断了。
所以建议你们在项目里统一维护一份可信任的根证书列表，并且定期更新。
证书吊销：两个机制
- CRL（证书吊销列表）：CA定期发布一个黑名单列表。缺点是有时间延迟，刚被吊销的证书可能还在列表里没更新。
- OCSP（在线证书状态协议）：实时查询某个证书现在是否有效。更及时，但需要OCSP响应器在线。
注意：现实中很多系统只配了CRL，但CRL下载频率设成一个月一次。这期间证书被吊销了，完全防不住。
我曾经帮一个金融客户整改过——把CRL更新间隔缩到6小时，同时叠加OCSP stapling（让服务器主动把OCSP响应结果附在握手里），才算把风险降下来。
数字签名 & PKI 核心流程
下面这张图把签名、验签、证书链串起来了。你盯着看两分钟，后面HSM封装接口的逻辑就能一眼看明白。
总结一下本章你必须要记住的三句话：
- 数字签名 = 哈希 + 私钥加密，验签 = 哈希 + 公钥解密比对
- PKI的核心是CA签发的证书链，解决了公钥归属的信任问题
- 私钥必须用HSM保护，证书吊销不能只靠CRL，得叠加OCSP