4. 数字签名与防抵赖：RSA/ECDSA签名算法选择、签名验签流程设计、时间戳服务集成
好，咱们直接进入正题。数字签名这块，说白了就是给交易报文盖个「电子公章」。你想想看，金融交易里最怕什么？最怕对方不认账——「我没发过这笔单子」、「这数据被人改过了」。数字签名就是用来解决这个问题的。
我在项目中遇到过好几次，因为签名算法选型不当，导致交易延迟飙升，甚至出现验签失败的情况。所以今天咱们把RSA和ECDSA掰开揉碎了讲清楚。
4.1 RSA vs ECDSA：怎么选？
先给结论：我个人习惯，新系统优先选ECDSA。为什么？
| 对比维度 | RSA (2048位) | ECDSA (P-256) |
|---|---|---|
| 签名长度 | 256字节 | 64字节 |
| 验签速度 | 较慢（约5000次/秒） | 较快（约15000次/秒） |
| 密钥生成 | 慢 | 快 |
| 安全性 | 依赖大整数分解 | 依赖椭圆曲线离散对数 |
| 兼容性 | 极好（几乎所有系统支持） | 较好（主流系统均支持） |
看到没？ECDSA的签名长度只有RSA的四分之一。在直连交易这种高频场景下，报文越短，网络延迟越低。我做过压测，同样1000笔交易，ECDSA比RSA节省了约30%的带宽。
重要提醒：如果你的系统需要跟老旧的金融机构对接，对方可能只支持RSA。这时候别硬上ECDSA，兼容性优先。我见过有团队强行上ECDSA，结果对方验签库版本太老，解析不了，回滚了三天。
4.2 签名验签流程设计
流程设计其实不复杂，但细节决定成败。我直接给出一套经过生产验证的流程：
// 签名端（发送方）
1. 计算交易报文的Hash值（SHA-256）
2. 使用私钥对Hash值进行签名
3. 将原始报文 + 签名值 + 证书序列号 打包发送
// 验签端（接收方）
1. 解析报文，分离出原始报文和签名值
2. 根据证书序列号查找对应的公钥证书
3. 计算原始报文的Hash值
4. 使用公钥验证签名
5. 验证通过则处理交易，否则拒绝嗯，这里要注意一个坑：签名时一定要包含时间戳。我曾经遇到过一个案例，对方把签名和报文分开传输，结果中间人把报文改了，签名没改，验签居然通过了——因为签名里没有绑定报文内容。后来我们强制要求签名时把整个报文的Hash值作为输入，才彻底解决。
实战技巧：建议在签名前对报文做规范化处理。比如JSON字段排序、去除多余空格。否则同样的业务数据，因为字段顺序不同，签名结果就不同，验签会失败。我吃过这个亏，排查了整整一个下午。
4.3 时间戳服务集成
时间戳是防抵赖的最后一道防线。你想想看，就算有签名，对方可以说「我的私钥被盗了，那笔交易不是我发的」。但如果有可信时间戳，就能证明在某个时间点之前，这笔交易确实存在且未被篡改。
集成时间戳服务，我建议采用以下架构：
// 时间戳请求流程
1. 交易系统生成签名后的报文
2. 将报文的Hash值发送给TSA（时间戳权威机构）
3. TSA返回时间戳令牌（包含Hash值、时间、TSA签名）
4. 将时间戳令牌附加到交易报文中存储
// 验证时
1. 验证交易报文签名
2. 验证时间戳令牌的TSA签名
3. 比对时间戳令牌中的Hash值与当前报文Hash值
4. 全部通过则证明交易在时间戳所示时间之前已存在警告：时间戳服务必须使用UTC时间，不要用本地时间。我见过一个系统用了服务器本地时间，结果跨时区交易时，时间戳比实际时间早了8小时，审计时被判定为「未来交易」，差点被监管处罚。
4.4 核心逻辑流程图
下面这张图，是我自己画的，把整个签名、验签、时间戳的流程串起来了。你仔细看一遍，基本就能理解全貌：
4.5 避坑指南
最后，我把自己踩过的坑总结一下，你直接拿去用：
- 密钥轮换：私钥不能一成不变。我建议每3个月轮换一次，旧密钥保留1年用于验签旧数据。
- 证书链验证：验签时不仅要验证签名本身，还要验证证书链是否完整、是否被吊销。我见过一个系统只验签名不验证书，结果被伪造证书攻击了。
- 性能优化：如果交易量很大，可以考虑把验签结果缓存起来。同一个客户端的连续交易，公钥是一样的，没必要每次都重新加载证书。
- 日志记录：签名和验签的每一步都要打日志。出了问题，日志就是你的救命稻草。我曾经靠日志里的签名值，反推出对方用的算法版本不对。
我的个人习惯：在开发环境用RSA（方便调试），生产环境切到ECDSA。因为RSA的签名结果可读性更好，出问题容易定位。但上线前一定要做完整的性能压测，确保ECDSA能满足你的TPS要求。
好了，数字签名这块就讲这么多。记住一句话：签名是手段，防抵赖是目的，时间戳是保障。三者缺一不可。