数字签名（Digital Signature）

用私钥对数据生成、可由对应公钥验证的密码学结果，用于检查内容完整性并证明签名时有人控制相应私钥。

核心特性

1. 只有私钥持有者能生成：签名无法伪造（前提是私钥未泄露）
2. 任何人可用公钥验证：验证方不需要知道私钥
3. 公开可验证性：不掌握私钥的第三方也能验证签名
4. 完整性保证：数据被篡改后签名验证会失败

数字签名可以支撑不可否认性，但不能单独保证它。要把“某个私钥产生了签名”提升为“某个自然人或组织实施且不能否认该业务行为”，还需要可信身份绑定、私钥控制、授权、时间证据、签署意图和审计记录。

与 MAC 的区别

MAC（消息认证码）和数字签名都能验证消息来源和完整性，但有根本区别：

结论：需要让不持有共享密钥的第三方验证来源时，应使用数字签名；最终归责仍取决于证书、密钥控制和业务证据链。

两层签名，各有分工

PKI 中存在两种签名，用途完全不同，初学时极易混淆：

第一层：用户签名数据（证明“这份数据是我发出的”）

Alice 用 SK_alice（自己的私钥）对文件签名
Bob   用 PK_alice（Alice 证书里的公钥）验签
→ 确认：文件由持有 SK_alice 的人签署，内容未被篡改

第二层：CA 签名证书（证明“这张证书本身是真的”）

CA    用 SK_CA（CA 自己的私钥）对证书内容签名
Bob   用 PK_CA（根证书里 CA 的公钥）验签
→ 确认：这张证书是受信任的 CA 颁发的，PK_alice 确实属于 Alice

为什么两层缺一不可？ 若没有 CA 签名，攻击者可以自制一张假证书写上“PK_mallory 属于 Alice”，受害者用 PK_mallory 验签后以为在和 Alice 通信，实际上是 Mallory。CA 的签名堵住了这个漏洞：只有受信任的 CA 才能权威地声明“这个公钥属于这个人”。

CA 签名回答的是“这把公钥可以信任吗？“，用户签名回答的是”这份数据是这把公钥的持有者发出的吗？“——两个问题，两层验证，缺一不可。

在 PKI 中的作用

• CA 签发证书：CA 用自己的私钥对证书内容签名，任何人可用 CA 公钥验证证书真实性
• 证书链验证：每一级证书都由上级 CA 签名，形成可验证的信任链
• TLS 握手：服务器用私钥签名握手数据，客户端用证书中的公钥验证

内容签名与时间证据

CMS SignedData 可以把签名与正文一起封装，也可以使用 detached 形式让正文独立保存。signedAttrs 将内容摘要等属性纳入签名，但普通 signingTime 通常只是签名者提供的时间声明，不能独立证明真实时间。需要第三方时间证据时，应结合 数字信封与可信时间 中的 RFC 3161 时间戳。

有效的密码学签名证明内容完整且某个私钥参与了签名；“签名者是否有业务权限”“签署是否表达真实意思”仍需身份映射、授权记录和业务流程共同回答。

相关概念

• 公钥密码学 — 数字签名的密码学基础
• — CA 用数字签名保证证书真实性
• — 签名行为的主体
• — 依赖逐级签名建立的信任路径
• TLS — 大量使用签名的协议

中国商用密码标准中的数字签名

中国 PKI 体系中使用SM2 算法（替代 RSA/ECDSA）进行数字签名，配套 SM3 算法（替代 SHA-256）进行摘要。

• 签名算法 OID：1.2.156.10197.1.501（SM2+SM3，GB/T 33560）
• 应用场景：电子印章（SESeal.signedValue）、电子签章（SES_Signature.signature）
• 相关国标：GBT38540-2020 — 规定了电子签章完整的生成与验证流程

注：RSA、ECDSA 与 SM2 是不同算法套件，不能直接拿一种算法的密钥或签名给另一种算法验证；但 X.509/CMS 等体系可通过算法标识承载不同套件。实际互操作取决于双方是否支持相同算法、参数、编码和应用协议，而不是简单按“国际/中国”二分。

来源

• 数字证书与PKI — 详细对比了签名与 MAC，说明不可否认性的来源
• GBT38540-2020 — 中国国家标准；SM2+SM3 数字签名在电子签章中的权威规范
• 理解PKI：从密码学历史到公钥基础设施 — 两层签名模型的清晰拆解，含攻击者视角的反例
• 理解PKI（七）：TLS数字信封与可信时间 — CMS 内容签名、可信时间与业务授权边界