SM9 标识密码用于邮件加密，相比证书体系解决了什么问题？代价是什么？

邮件端到端加密的技术方案早已成熟。RFC 8551 定义的 S/MIME 提供了完整的报文签名与加密能力，OpenPGP 体系同样如此。但这些方案在组织内部大规模落地时，卡住的从来不是算法，而是公钥分发。

基于证书的体系要求：给我发加密邮件之前，你必须先拿到我的证书。这引出一连串工程问题：

• 首次通信的死锁。要给一个从未联系过的人发加密邮件，得先想办法拿到他的证书；而最自然的索取方式——发一封邮件问他要——本身是明文的。
• 证书目录的可用性。组织内可以靠目录服务解决，跨组织则缺乏通用的、可信的公开查询途径。
• 证书生命周期管理。签发、续期、吊销、吊销状态查询，每一环都需要基础设施支撑，且都可能成为故障点。
• 用户负担。普通用户要理解证书、私钥、信任链这些概念，实践中这是最难跨越的一道坎。

结果是：能用的方案存在，但在组织内的实际启用率长期偏低。标识密码正是针对这个分发问题提出的另一条路径。

SM9 是我国的标识密码算法，其国家标准为 GB/T 38635《信息安全技术 SM9标识密码算法》，对应的密码行业标准为 GM/T 0044《SM9标识密码算法》。该算法体系包含数字签名、密钥交换、密钥封装与公钥加密等机制。

标识密码（Identity-Based Cryptography）与证书体系的根本区别在于：用户的公钥直接由其标识经过公开算法导出，不需要证书来把「公钥」和「身份」绑定在一起。

对邮件而言，这个性质极其贴合：邮箱地址本身就是一个天然的、全局唯一的、人人都已经知道的标识。于是——

• 要给 zhangsan@example.com 发加密邮件，发送方直接用这个地址串算出公钥即可，不需要向任何人索取、不需要查询目录、不需要验证证书链；
• 首次通信的死锁自然消解；
• 用户侧的概念负担大幅降低——不需要理解证书，只需要知道「我的私钥」。

私钥则由一个密钥生成中心（KGC）根据系统主密钥与用户标识计算生成，并通过安全通道分发给用户。这是整个体系的枢纽，也是它全部优势与全部代价的来源。

标识密码的便利有一个无法回避的结构性后果：KGC 能够为任意标识生成私钥，因此它在原理上可以解密发给任何人的邮件。这称为密钥托管（key escrow）特性。

这不是实现缺陷，而是该体系的固有属性。它带来几个必须被显式决策的问题：

1. 抗抵赖性受影响。由于 KGC 也持有用户私钥的生成能力，「只有签名人能产生这个签名」这一前提被削弱。对照电子签名法关于可靠电子签名的条件——签署时电子签名制作数据仅由电子签名人控制——托管特性会对这一条的论证造成实质困难。因此在需要强抗抵赖的场景中，采用标识密码签名需要额外的制度与技术安排。
2. 主密钥是单点。系统主密钥一旦泄露，历史与未来的全部通信都会失去保护。它的保护等级必须显著高于普通密钥，通常需要密码硬件、分割存储与严格的多人操作流程。
3. 吊销机制不同于证书。证书体系可以吊销证书，而标识无法被「吊销」——邮箱地址还是那个字符串。常见的工程做法是在标识中拼接有效期信息（例如把地址与时间段组合作为实际标识），使私钥自然到期，需要定期重新申请。这实际上是用密钥轮换替代了吊销，代价是分发频率上升。
4. 跨组织互通尚不平凡。两个组织各有各的 KGC 与主密钥，跨域加密需要额外的信任建立机制。在组织内部，标识密码的优势最明显；跨组织场景下，它并不自动比证书体系更简单。

值得强调的是，托管特性在某些场景中反而是需求而非缺陷。合规归档要求组织能够对邮件内容进行审计与检索，而纯粹的端到端加密会使这一要求无法满足。标识密码的托管特性恰好为「加密传输与存储」和「合规可审计」的并存提供了技术空间——前提是访问必须受到严格的授权与留痕控制。

实际的邮件加密不会只用一种算法，而是一套组合。国密算法体系中与之配合的主要有：

• SM4（GB/T 32907《信息安全技术 SM4分组密码算法》）：分组密码，用于对邮件正文与附件做实际的对称加密。大体量数据始终由对称算法承担，非对称算法只用于保护对称密钥。
• SM3（GB/T 32905《信息安全技术 SM3密码杂凑算法》）：杂凑算法，用于完整性校验与签名过程中的摘要计算。
• SM2（GB/T 32918《信息安全技术 SM2椭圆曲线公钥密码算法》）：基于证书的椭圆曲线公钥算法，是与 SM9 并列的另一条路径。SM2 走证书体系，SM9 走标识体系，二者解决同一层问题的不同取舍。
• SM9：标识密码，用于密钥封装与公钥加密，把对称密钥安全地传给收件人。

合规定位方面，密码法把密码分为核心密码、普通密码和商用密码，商用密码用于保护不属于国家秘密的信息，企业邮件加密属于这一范畴。GB/T 39786-2021 对信息系统的密码应用提出基本要求，其技术部分覆盖物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个层面。邮件的端到端加密主要落在「应用和数据安全」层面，用于满足其中关于数据传输机密性与存储机密性的要求。

端到端加密不是越多越好，它有明确的适用边界。给出一个务实的判断框架：

适合采用的情形：

1. 组织内部通信为主，KGC 可由自己掌控，跨域互通需求有限；
2. 存在明确的、有限范围的高敏感通信场景（如特定部门、特定业务线），而非全员全量加密；
3. 有密码合规要求需要满足，且已有或计划建设密码基础设施；
4. 能够接受并管理主密钥的集中风险。

不适合或需谨慎的情形：

1. 以跨组织外部通信为主。对方大概率不支持，加密邮件发不出去，最终会退化为明文。
2. 需要强抗抵赖的签署场景。托管特性会削弱论证，应优先考虑由个人独占控制密钥的方案。
3. 缺乏密钥管理能力。密钥管理做不好，加密只是把风险从「内容泄露」转移到「数据永久丢失」——用户私钥丢失、主密钥损坏都会导致历史邮件无法解密。这一风险在实践中造成的损失往往大于它所防范的风险。

无论选择哪条路径，有三件事必须先做：

• 先把传输加密与存储加密做扎实。强制 TLS、证书校验、存储加密的成本远低于端到端加密，覆盖的风险面却更广。基础层没做好就上端到端加密，是典型的次序颠倒。
• 先想清楚归档与检测怎么办。端到端加密后，网关侧的反病毒、反垃圾、数据防泄漏与合规归档的可读性都会失效。这个取舍必须在设计阶段就有答案。
• 先设计密钥恢复流程。用户离职、设备丢失、私钥损坏时如何恢复历史邮件的可读性，必须有明确方案并经过演练。