如何在不解密的情况下检查加密的 S/MIME 消息是否也被签名

Question

在加密邮件时，判断 s/mime 电子邮件是否带有附加签名的最简单方法（就计算资源而言）是什么？

如果消息刚刚签名，这很容易。它有点像：

附加签名

   Content-Type: application/x-pkcs7-mime; smime-type=signed-data;
    name="smime.p7m"

或者：

用于分离签名

   Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
    micalg=SHA1; boundary="----=_NextPart_000_00D2_01CD5850.61030BF0"

在其标题中。

但是当消息被加密时，您无法判断它是否也被签名，因为 Content-Type 标头在两种情况下都是相同的（只是加密和加密/签名）：

  Content-Type: application/x-pkcs7-mime;
    smime-type=enveloped-data;
    boundary="----=_NextPart_000_000D_01CDC82B.98454D80";
    name="smime.p7m"

这是否意味着我必须解密消息才能知道它是否也已签名？目前，似乎我什至无法判断我的消息在解密之前是否已签名（因为签名在加密数据中）。或者，也许 S/MIME 加密和签名数据仍然有一些模式可以让我区分加密/签名和加密/未签名数据而无需解密（如果我没有解密证书，这甚至可能）？

Answer 1

S/MIME 很灵活；您可以以任何您想要的组合进行签名和/或加密。然而，电子邮件客户端通常都以相同的方式运行：Outlook 2010、Apple 的 Mail 和 Thunderbird 17 都签名然后加密。这 3 个的结果几乎相同。它们在消息标头中包含这 3 个标头：

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
    name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64

它们对整个消息正文进行加密和 base64 编码。

回答您的问题：

什么是最简单的方法（就计算资源而言）来判断是否 当这 消息被加密了吗？

唯一的办法就是解密。

这是否意味着我必须解密消息才能判断它是否是 也签了？

是的。

Answer 2

如果目标是确保：

1. 只有收件人可以解密邮件，并且
2. 收件人知道谁写了邮件，

那么正确的顺序是签名，加密，然后再次签名。否则无论如何你都不能相信它。原因如下。

签名和加密消息： 发件人首先对消息签名，然后对其进行加密。
在这里，接收者可以解密消息，然后用完整的签名重新加密它，然后将其发送给第三方（带有欺骗的标头）。该第三方会相信原始作者直接将消息发送给他，而实际上该消息是由原始收件人转发的。

加密和签名的消息： 发件人首先加密消息，然后对其进行签名。
任何攻击者都可以删除签名，将其替换为自己的签名，并在不知道其内容的情况下声明消息的作者身份。

加密、签名和加密的消息： 发件人对消息进行加密和签名，然后再次加密。
在这里，内部加密确保只有预期的收件人才能阅读邮件。签名意味着作者知道内容并打算将其提供给收件人。外部加密可防止攻击者知道或篡改消息。

• 在这种情况下，收件人在解密之前不会知道邮件已签名。

• 对消息加密两次更多

• 更糟糕的是，加密然后签名是 known 容易受到攻击。

签名、加密和签名的消息： 发件人对消息进行签名和加密，然后再次签名。
在这里，内部签名意味着作者知道内容。加密确保只有收件人可以解密它。并且外部签名意味着作者打算将消息发送给收件人。

• 如果攻击者试图通过移除外部签名并用自己的替换来声明所有权，那么（替换的）外部签名将与内部签名不匹配。

• 如果收件人将邮件解密并转发给第三方，他必须保持最里面的签名不变或用自己的签名替换。在任何一种情况下，原作者均不对信息承担责任。

结论

尽管有当前（失效的）标准，您只有在最后一步中签名后才能验证消息的发件人。因此，您不必担心首先签名并然后加密的消息，因为您无法相信所谓的签名者将消息发送给您。

例如，想象一下收到一封来自总统的签名然后加密的消息，邀请您到白宫共进晚餐。事实上，总统确实写了那条信息，但他实际上把它发送给了一个决定跟你开玩笑的人。