3. 签名证据交接基础：数字签名原理、证据链完整性、交接协议
在多团队协作的 API 延迟诊断场景中，不同团队（SRE、开发、安全、网络）产生的诊断日志、调用链快照、策略评估结果需要作为可验证的签名证据进行跨组织交接。本章从密码学基础出发，建立证据链完整性的理论模型，并对比主流交接协议（JWT、mTLS）的适用场景。
3.1 数字签名原理：证据的不可否认性
数字签名是签名证据交接的基石。它保证：
- 真实性：证据确实由声称的团队/节点签发。
- 完整性：证据在传输或存储中未被篡改。
- 不可否认性：签发者无法否认曾签发该证据。
标准流程包含签名生成与验证两个阶段：
签名生成（发送方）：
1. 对证据原文 M 进行哈希运算，得到摘要 H(M)。
2. 使用发送方私钥 SKA 对摘要加密，生成签名 Sig = Enc(SKA, H(M))。
3. 将 (M, Sig, 发送方证书 CertA) 打包为证据包。
1. 对证据原文 M 进行哈希运算，得到摘要 H(M)。
2. 使用发送方私钥 SKA 对摘要加密，生成签名 Sig = Enc(SKA, H(M))。
3. 将 (M, Sig, 发送方证书 CertA) 打包为证据包。
签名验证（接收方）：
1. 使用发送方公钥 PKA（从 CertA 提取）解密签名，得到摘要 H'(M)。
2. 对收到的原文 M 重新计算哈希 H(M)。
3. 比较 H'(M) 与 H(M)：一致则验证通过，否则证据无效。
1. 使用发送方公钥 PKA（从 CertA 提取）解密签名，得到摘要 H'(M)。
2. 对收到的原文 M 重新计算哈希 H(M)。
3. 比较 H'(M) 与 H(M)：一致则验证通过，否则证据无效。
3.2 证据链完整性模型
在跨团队协作中，单个签名证据不足以建立完整信任。需要构建证据链，将多个签名证据按时间/因果顺序链接，形成不可篡改的序列。
| 证据链属性 | 描述 | 实现方式 |
|---|---|---|
| 时序完整性 | 每个证据包含前一个证据的哈希或签名引用 | 链式哈希（Hash Chain） |
| 因果完整性 | 证据间的依赖关系可追溯 | 签名中嵌入前序证据 ID + 时间戳 |
| 身份完整性 | 每个签名可追溯到具体团队/节点 | X.509 证书链 + 签名验证 |
| 策略完整性 | 证据生成时使用的策略版本可查 | 策略哈希嵌入签名负载 |
实践要点： 在 API 延迟诊断中，建议每个诊断步骤（如：SRE 采集延迟数据 → 开发分析代码路径 → 安全审计策略执行）都生成一个签名证据，并将前一步的证据哈希包含在当前签名中，形成不可逆的证据链。
3.3 交接协议对比：JWT vs Mutual TLS
签名证据的跨团队交接需要标准协议封装。两种主流方案各有优劣：
| 维度 | JWT（JSON Web ） | mTLS（Mutual TLS） |
|---|---|---|
| 签名机制 | 负载内嵌签名（JWS），支持 RS256/ES256 | 传输层证书双向验证，TLS 握手完成签名 |
| 证据封装 | 证据直接放入 JWT payload，自包含 | 证据通过 TLS 通道传输，不强制封装 |
| 离线验证 | 支持：接收方可离线验证 JWT 签名 | 不支持：需要在线 TLS 握手 |
| 链式引用 | JWT header 或 payload 可嵌入前序证据哈希 | 需应用层自行实现链式引用 |
| 性能开销 | 低：仅一次签名/验签操作 | 中：每次连接 TLS 握手 + 证书验证 |
| 适用场景 | 异步消息、事件驱动、离线审计 | 实时流、高安全传输、服务间直接通信 |
3.4 JWT 签名证据示例
以下是一个包含延迟诊断证据的 JWT 结构，展示了如何将签名、证据链引用和策略版本封装在一起：
{
"header": {
"alg": "ES256",
"typ": "JWT",
"kid": "sre-team-key-2025-01"
},
"payload": {
"evidence_id": "evt-2025-03-21-001",
"team": "sre",
"timestamp": "2025-03-21T14:30:00Z",
"diagnosis_data": {
"api": "/v2/order/create",
"latency_ms": 2450,
"p99_latency_ms": 3200,
"strategy_version": "v2.3.1",
"strategy_hash": "sha256:a1b2c3d4e5f6..."
},
"chain": {
"prev_evidence_id": "evt-2025-03-21-000",
"prev_evidence_hash": "sha256:9f8e7d6c5b4a..."
},
"policy_context": {
"policy_id": "latency-slo-v3",
"evaluation_result": "violation"
}
},
"signature": "MEUCIQ... (ES256 签名值)"
}
安全警告： JWT 的签名仅保证 payload 完整性，不加密 payload 内容。如果证据包含敏感数据（如用户 IP、内部拓扑），必须使用 JWE（JSON Web Encryption）对 payload 加密，或通过 mTLS 通道传输。
3.5 mTLS 证据交接流程
mTLS 在传输层提供双向身份认证和加密通道，适合高安全要求的实时证据交接：
- 证书准备：每个团队/节点持有由信任 CA 签发的客户端证书和私钥。
- TLS 握手：客户端和服务端互相验证对方证书，建立加密通道。
- 证据传输：签名证据通过已建立的 TLS 通道传输，传输层保证完整性和机密性。
- 应用层签名：建议在证据负载内仍保留数字签名，实现端到端不可否认性（即使 TLS 终止）。
推荐组合策略：
- 使用 mTLS 作为传输层安全基座，保证通道加密和双向身份认证。
- 在应用层使用 JWT 封装签名证据，支持离线验证和链式引用。
- 证据链的完整性通过 JWT payload 中的
- 使用 mTLS 作为传输层安全基座，保证通道加密和双向身份认证。
- 在应用层使用 JWT 封装签名证据，支持离线验证和链式引用。
- 证据链的完整性通过 JWT payload 中的
chain.prev_evidence_hash 字段维护。
3.6 交接协议选择矩阵
| 诊断场景 | 推荐协议 | 理由 |
|---|---|---|
| 异步延迟告警（消息队列） | JWT | 支持离线验证，消息可持久化审计 |
| 实时调用链追踪（gRPC） | mTLS + JWT | 传输层加密 + 应用层签名证据 |
| 跨组织证据归档 | JWT | 自包含，无需实时连接验证 |
| 高敏感策略审计 | mTLS | 强制双向认证，防止中间人攻击 |
| 混合云/多集群诊断 | mTLS + JWT | 跨集群传输加密 + 证据链可追溯 |