S/MIME v4.0 协议详解：从 CMS 消息格式到端到端邮件加密的完整架构

协议详解 · 2026-08-12

概述

S/MIME（Secure/Multipurpose Internet Mail Extensions）是互联网工程任务组（IETF）标准化的电子邮件安全协议族，提供端到端的邮件加密与数字签名服务。当前最新版本为 S/MIME v4.0，由 RFC 8551（消息规格）、RFC 8550（证书使用规范）、RFC 8552（内容处理策略）和 RFC 8553（能力协商）组成，于 2019 年发布，取代了 RFC 5751 定义的 S/MIME v3.1。

截至 2026 年，S/MIME 仍是企业级加密邮件的标准方案之一，与 PGP/GnuPG 形成两大端到端邮件安全生态。在国密合规场景下，S/MIME 的消息格式（CMS/PKCS#7）与 SM2 证书的映射关系是许多安全工程师面临的实际挑战。

本文从协议架构、消息格式、安全模型三个维度深入解析 S/MIME v4.0，并分析其在国密环境下的适配路径。

一、协议架构

1.1 历史演进

S/MIME 的设计思想源自 Netscape 公司 1995 年提出的 MIME 加密扩展。1999 年发布的 S/MIME v2.0 引入了基于 PKCS#7 的签名和加密协议，成为事实标准。2007 年的 S/MIME v3.1（RFC 5751）将其正式标准化。2019 年发布的 S/MIME v4.0（RFC 8551）完成了以下关键升级：

版本	发布年份	关键变更
S/MIME v2.0	1997	引入 PKCS#7 签名/加密
S/MIME v3.1	2007	标准化 RFC 5751，支持 AES、SHA-256
S/MIME v4.0	2019	完整 RFC 8551-8553 套件，CMS 重构
S/MIME v5.0（草案）	2024+	正在讨论（含国密扩展）

1.2 核心组件关系

S/MIME v4.0 采用分层架构，每一层对应一个 RFC：

CODE

┌─────────────────────────────────────────────────┐
│              S/MIME 应用层                       │
│  (邮件客户端集成、MIME 封装、用户界面)            │
├─────────────────────────────────────────────────┤
│        RFC 8551: S/MIME 消息规格                 │
│  (SignedData、EnvelopedData、CompressedData)      │
├─────────────────────────────────────────────────┤
│        RFC 8550: 证书使用规范                     │
│  (SMIMECapability 扩展、证书验证策略)              │
├─────────────────────────────────────────────────┤
│        RFC 5652: CMS (Cryptographic Message Syntax)│
│  (底层密码语法定义)                              │
├─────────────────────────────────────────────────┤
│        RFC 5280: X.509 证书                      │
│  (证书格式与验证链)                              │
└─────────────────────────────────────────────────┘

二、CMS 消息格式

2.1 ContentInfo 结构

所有 S/MIME 消息都基于 CMS（Cryptographic Message Syntax，RFC 5652）编码。CMS 的核心类型是 ContentInfo，由内容类型和内容值两部分组成：

CODE

ContentInfo ::= SEQUENCE {
    contentType ContentType,
    content       [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
}

ContentType ::= OBJECT IDENTIFIER

S/MIME v4.0 定义了四种 Content-Type：

Content-Type	OID	说明
`signedData`	1.2.840.113549.1.7.2	数字签名（含或不含加密）
`envelopedData`	1.2.840.113549.1.7.3	加密消息（仅加密）
`signedAndEnvelopedData`	1.2.840.113549.1.7.4	先签名后加密
`data`	1.2.840.113549.1.7.1	原始数据（无保护）

2.2 SignedData 结构

SignedData 是最常用的 S/MIME 内容类型，对应 MIME 类型 application/pkcs7-signature。其 ASN.1 结构如下：

CODE

SignedData ::= SEQUENCE {
    version         INTEGER,          -- 通常为 v1 或 v3
    digestAlgorithms [0] SET OF DigestAlgorithmIdentifier,
    contentInfo     ContentInfo,
    certificates   [1] IMPLICIT CertificateSet OPTIONAL,
    crls           [2] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos     SET OF SignerInfo
}

2.3 SignerInfo 详解

SignerInfo 是 SignedData 的核心，包含签名者的身份信息、签名算法和签名值：

CODE

SignerInfo ::= SEQUENCE {
    version               INTEGER (v1 or v3),
    sid                   SignerIdentifier,      -- issuerAndSerialNumber 或 subjectKeyIdentifier
    digestAlgorithm       DigestAlgorithmIdentifier,
    signedAttrs             [0] IMPLICIT SetOfAttribute OPTIONAL,
    signatureAlgorithm      SignatureAlgorithmIdentifier,
    signature               SignatureValue,
    unsignedAttrs           [2] IMPLICIT SetOfAttribute OPTIONAL
}

版本差异：

version = 1：不使用签名属性（即 signedAttrs 为空），仅包含基本签名信息
version = 3：使用签名属性，支持时间戳、散列等附加信息

2.4 认证属性（Authenticated Attributes）

认证属性是 v3 SignerInfo 的核心扩展，存储在 signedAttrs 字段中。RFC 8551 定义了以下必须支持的属性：

属性 OID	名称	说明
1.2.840.113549.1.9.3	contentType	标识内容类型（防止重放攻击）
1.2.840.113549.1.9.4	messageDigest	消息摘要，用于完整性校验
1.2.840.113549.1.9.5	signingTime	签名时间（ASN.1 UTCTime 或 GeneralizedTime）
1.2.840.113549.1.9.6	unstructuredName	签名者显示名称
1.2.840.113549.1.9.7	unstructuredAddress	签名者地址（通常为邮箱）
1.2.840.113549.1.9.8	counterSignature	对签名者的二次签名（审计用途）

这些属性确保签名包含消息内容的哈希值，而非仅对原始数据进行签名，从而防止"签名重放"攻击。

2.5 EnvelopedData 结构

EnvelopedData 对应 MIME 类型 application/pkcs7-mime; smype=envelopedData，用于加密消息：

CODE

EnvelopedData ::= SEQUENCE {
    version         INTEGER (0-5),
    recipientInfos  SET OF RecipientInfo,
    encryptedContentInfo EncryptedContentInfo
}

RecipientInfo 定义每个接收者的密钥包装方式：

CODE

RecipientInfo ::= SEQUENCE {
    version         INTEGER,
    rid             KeyTransRecipientInfo | KEKRecipientInfo
                    | OtherRecipientInfo,
    ...
}

类型	说明
`KeyTransRecipientInfo`	传统密钥传输，使用接收者公钥加密会话密钥
`KEKRecipientInfo`	基于密钥加密密钥（KEK），无需证书
`OtherRecipientInfo`	自定义扩展（如 SM2 密钥封装）

2.6 内容处理策略（Content Processing）

RFC 8552 定义了 S/MIME v4.0 的内容处理策略，将四种基本操作模式组合成三种实用的处理方式：

CODE

┌─────────────────────────────────────────────────────┐
│  纯签名（Signing only）                            │
│  Content-Type: application/pkcs7-signature         │
│  用途：发送方对邮件内容签名，收件人验证身份与完整性   │
├─────────────────────────────────────────────────────┤
│  签名+加密（Signing then Enveloping）              │
│  SignedAndEnvelopedData                             │
│  用途：先签名后加密，收件人解密后验证签名             │
├─────────────────────────────────────────────────────┤
│  加密（Encryption only）                           │
│  Content-Type: application/pkcs7-mime; smime-type=envelopedData │
│  用途：仅加密邮件内容，收件人用私钥解密               │
└─────────────────────────────────────────────────────┘

重要安全原则：必须采用"先签名后加密"（sign-then-encrypt）模式，而非"先加密后签名"（encrypt-then-sign）。前者可防止攻击者替换加密内容；后者存在"签名剥离"攻击风险（攻击者可移除外层签名后重新签名）。

三、证书与扩展机制

3.1 SMIMECapability 扩展

RFC 4262 定义了 SMIMECapabilities 证书扩展，用于声明发送方支持的 S/MIME 能力：

CODE

id-smime-oids OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15 }

id-smime-ct-smimeCapabilities OBJECT IDENTIFIER ::= {
    id-smime-oids 15 }

SMIMECapabilities ::= SEQUENCE OF SMIMECapability

SMIMECapability ::= SEQUENCE {
    capabilityID  CapabilityIdentifier,
    cdmParameter  ANY DEFINED BY capabilityID OPTIONAL
}

常用 Capability Identifier：

OID	算法	说明
1.2.840.113549.3.2	DES-CBC	DES 对称加密（不推荐）
1.2.840.113549.3.7	3DES-CBC	三重 DES 对称加密
1.2.840.113549.3.4	AES-128-CBC	AES 128 位
1.2.840.113549.3.7	AES-192-CBC	AES 192 位
1.2.840.113549.3.8	AES-256-CBC	AES 256 位
1.2.840.113549.3.6	AES-128-GCM	AES-GCM（推荐）
1.2.840.113549.3.9	AES-256-GCM	AES-GCM（推荐）
1.2.840.113549.2.9	HMAC-SHA256	SHA-256 MAC
1.2.840.113549.2.11	HMAC-SHA384	SHA-384 MAC
1.2.840.113549.2.12	HMAC-SHA512	SHA-512 MAC
1.2.840.113549.1.9.16.3.11	SM2WithSM3	国密 SM2+SM3

3.2 证书使用规范（RFC 8550）

RFC 8550 规定了 S/MIME v4.0 对 X.509 证书的要求：

要求项	说明
密钥用法（Key Usage）	必须包含 `digitalSignature` 或 `nonRepudiation`
扩展密钥用法（EKU）	建议包含 `emailProtection` (1.3.6.1.5.5.7.3.4)
主题备用名称（SAN）	必须包含 `rfc822Name`（邮箱地址）
证书有效期	最长 825 天（约 27 个月），建议 1 年
密钥长度	RSA ≥ 2048 位；ECDSA ≥ 256 位（P-256）
签名算法	SHA-256 或更强（禁止 MD5/SHA-1）

3.3 国密证书适配

国密环境下的 S/MIME 需要遵循 GM/T 0010-2023《SM2 密码算法加密签名消息语法规范》。该标准定义了 SM2 证书在 CMS/S/MIME 中的使用方式：

国际标准	国密对应
RSA-OAEP 密钥封装	SM2 加密（GM/T 0003.4）
SHA-1/SHA-256 散列	SM3（GM/T 0004）
RSASSA-PKCS1-v1.5 签名	SM2 签名（GM/T 0003.2）
ECDSA 签名	SM2 签名
HMAC-SHA256 MAC	HMAC-SM3（基于 GM/T 0004）

国密 S/MIME 消息特征：

Content-Type 需携带 smime-type=signedData 或 envelopedData 参数
SignerInfo 中的 digestAlgorithm 应使用 sm3WithSM2Encryption（OID: 1.2.156.10197.1.501）
证书扩展需包含国密标识（如 sm2EncryptionCertificate 备用名称）

四、消息处理流程

4.1 签名邮件处理流程

CODE

发件人：
  ┌─────────────────────────────────────────────────┐
  │ 1. 准备邮件内容（plaintext）                    │
  │ 2. 计算 messageDigest（SM3/SHA-256）            │
  │ 3. 构建 signedAttrs（contentType + messageDigest + signingTime）│
  │ 4. 对 signedAttrs 进行哈希                       │
  │ 5. 用私钥对哈希值签名（SM2/RSA）                  │
  │ 6. 构建 SignedData CMS 结构                     │
  │ 7. 设置 Content-Type: application/pkcs7-signature│
  └─────────────────────────────────────────────────┘
                    │
                    ▼ 发送邮件
收件人：
  ┌─────────────────────────────────────────────────┐
  │ 1. 解析 SignedData，提取证书和签名               │
  │ 2. 验证证书链（X.509 路径验证）                  │
  │ 3. 从 signedAttrs 中取出 messageDigest           │
  │ 4. 重新计算内容哈希，与 messageDigest 比对       │
  │ 5. 用发件人公钥验证签名                         │
  │ 6. 解密并显示原始邮件内容                        │
  └─────────────────────────────────────────────────┘

4.2 加密邮件处理流程

CODE

发件人：
  ┌─────────────────────────────────────────────────┐
  │ 1. 生成随机会话密钥 K（AES-256-GCM）            │
  │ 2. 用收件人公钥加密 K → E_K                     │
  │ 3. 用 K 加密邮件内容 → C                        │
  │ 4. 构建 EnvelopedData CMS 结构                  │
  │ 5. 设置 Content-Type: application/pkcs7-mime    │
  │    smime-type=envelopedData                     │
  └─────────────────────────────────────────────────┘
                    │
                    ▼ 发送邮件
收件人：
  ┌─────────────────────────────────────────────────┐
  │ 1. 解析 EnvelopedData，提取 recipientInfos     │
  │ 2. 用自身私钥解密 E_K → K                       │
  │ 3. 用 K 解密 C → plaintext                      │
  │ 4. 验证解密结果（GCM 认证标签）                  │
  └─────────────────────────────────────────────────┘

五、安全模型与攻击防护

5.1 安全目标

S/MIME 提供以下安全保证：

安全属性	实现机制	说明
身份认证	数字签名 + X.509 证书链	确认邮件来自声称的发件人
消息完整性	messageDigest 认证属性	检测邮件内容是否被篡改
不可否认性	非对称签名（私钥唯一）	发件人无法否认已发送的邮件
机密性	会话密钥加密（对称加密）	防止第三方读取邮件内容

5.2 已知攻击与缓解

攻击类型	影响	缓解措施
BEAST 攻击	CBC 模式下的明文恢复	使用 GCM 模式替代 CBC
Lucky13 攻击	通过时序差恢复明文	使用 GCM 或 AEAD
签名剥离	移除签名重新签名	采用 sign-then-encrypt 模式
重放攻击	旧签名被重复使用	contentType 认证属性
SMIMECapability 降级	强迫使用弱算法	严格接受策略配置
证书吊销未检查	使用已吊销证书	必须检查 CRL/OCSP

5.3 国密场景特殊考量

在国密环境中部署 S/MIME 时需注意：

SM2 证书兼容：国际邮件服务器不支持 SM2 证书，需部署双证书（SM2 + RSA/ECDSA）
SM3 散列验证：部分国际客户端无法验证 SM3 签名，需降级到 SHA-256
HMAC-SM3 支持：RFC 5652 未原生定义 HMAC-SM3，需在 ciphertextAlgorithm 中自定义
时间戳服务：国密时间戳使用 SM3 签名，需确保证书链可追溯至 CFCA 等国内 CA

六、与 PGP/GnuPG 的对比

维度	S/MIME v4.0	PGP/GnuPG
标准组织	IETF	IETF（OpenPGP RFC 4880）
信任模型	X.509 证书链（PKI）	Web of Trust
消息格式	CMS（PKCS#7）	OpenPGP 数据包
内容类型	`application/pkcs7-signature`	`application/pgp-signature`
客户端集成	原生支持（Outlook、Apple Mail）	需插件（Gpg4win、Mailpile）
国密支持	GM/T 0010-2023（正在完善）	无原生支持
企业部署	成熟（基于现有 PKI 体系）	较复杂（需独立信任管理）

关键差异：S/MIME 依赖企业已有的 PKI 基础设施，适合内网部署；PGP 采用去中心化信任模型，适合个人场景。

七、相关实践链接

S/MIME 国密适配指南 — 国密 S/MIME 在实际部署中的常见问题与解决方案
GM/T 0010-2023 SM2 加密签名消息语法 — 国密 S/MIME 的标准规范
TLS 1.3 协议架构深度解析 — 传输层加密与邮件层加密的对比
GB/T 38636-2020 TLCP 国密协议 — 国密协议标准对照

参考资料

← 返回知识库