用于公钥加密和电子邮件签名的 S/MIME 解释

Question

我正在尽最大努力了解它的工作原理。我读了很多文章，但总是感到困惑。

根据我的有限理解，发件人和收件人都必须使用证书颁发机构提供的密钥/证书安装他们的客户端。但是发送方和接收方的邮件客户端如何使用这些证书呢？

这是一个让我困惑的具体例子，来自维基百科 (https://en.wikipedia.org/wiki/S/MIME)：

While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, [...]

因此，发件人邮件客户端应该能够使用收件人证书加密邮件。在实践中，发件人邮件客户端如何仅从收件人的邮件地址推断出收件人证书是什么？发件人和收件人的邮件客户端是否相互“ping”并以某种方式交换此信息？它是从电子邮件地址的域推断出来的吗？还是希望电子邮件客户端的用户事先交换这些信息？

Answer 1

你问了几个问题。那可能是因为你很困惑。让我试着整理一下。

用于加密目的

• 发件人使用收件人的公钥密钥（来自收件人的公共证书）加密电子邮件
• 然后收件人使用他们自己的私人密钥解密电子邮件

用于签名目的

• 发件人使用自己的私人密钥签署电子邮件
• 然后收件人使用发件人的公钥密钥（来自发件人的公共证书）验证签名

交换公共证书

1. Alice 向 Bob 发送一封签名但未加密的电子邮件
2. 签名包括 Alice 的公共证书
3. Bob 可以从邮件中提取 Alice 的公共证书
4. Bob 信任 Alice 的证书，因为它是由受信任的权威机构签署的 *)
5. Bob 现在可以验证包括证书在内的签名
6. Bob 现在可以向 Alice 发送加密电子邮件

*) 每个操作系统都带有大量预信任的证书颁发机构

然后，Bob 在回复 Alice 时还通过签署电子邮件来共享他自己的证书。之后，就可以双向加密了。

其他

来自 Wikipedia 的引述涉及不同的方面：

如果 Alice 向 Bob 发送了一封加密的电子邮件，Alice 使用 Bob 的公钥来加密这封电子邮件，所以只有 Bob 可以解密它。但这也意味着 Alice 无法解密她自己的电子邮件（它存储在她的“已发送”文件夹中）！

将未加密的电子邮件存储在 Alice 的“已发送”文件夹中将是一个严重的安全漏洞，那么可以做些什么呢？电子邮件可以为双方、收件人 Bob 和发件人 Alice 加密。

现在如何使用多个加密密钥对一封电子邮件进行加密？

邮件实际上并没有用 Bob 的密钥加密，而是

1. 选择随机密钥来加密电子邮件内容
2. 随机密钥使用 Bob 的密钥加密并添加到消息中
3. 随机密钥也用 Alice 的密钥加密并添加到消息中

然后要解密，使用收件人的私钥解密随机密钥，然后使用解密后的密钥解密电子邮件内容。

在这种情况下，随机密钥称为“内容加密密钥”或 CEK，而个人密钥称为“密钥加密密钥”或 KEK。

还有另一个使用 CEK 的原因 - 这与对称加密比非对称加密更快且更具可扩展性有关 - 但这是另一个故事，应该在另一个问题的答案中讲述。