如何检查加密的S/MIME消息是否也已签名,而不对其进行解密

Ale*_*lex 8 email encryption smime digital-signature

在加密此消息时,判断s/mime电子邮件是否使用附加签名进行签名的最简单方法(就计算资源而言)是什么?

如果邮件刚签名,则很容易.它有点像:

附加签名

   Content-Type: application/x-pkcs7-mime; smime-type=signed-data;
    name="smime.p7m"
Run Code Online (Sandbox Code Playgroud)

要么:

用于分离签名

   Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
    micalg=SHA1; boundary="----=_NextPart_000_00D2_01CD5850.61030BF0"
Run Code Online (Sandbox Code Playgroud)

在它的标题中.

但是当邮件被加密时,您无法判断它是否也已签名,因为两种情况的Content-Type标头相同(只是加密和加密/签名):

  Content-Type: application/x-pkcs7-mime;
    smime-type=enveloped-data;
    boundary="----=_NextPart_000_000D_01CDC82B.98454D80";
    name="smime.p7m"
Run Code Online (Sandbox Code Playgroud)

这是否意味着我必须解密消息只是为了告诉它是否也签名?现在,在我解密之前,似乎我甚至无法判断我的消息是否已签名(因为签名在加密数据中).或者,S/MIME加密和签名数据可能还有一些模式可以让我在没有解密的情况下区分加密/签名和加密/未签名数据(如果我没有解密证书,甚至可能这样做)?

jam*_*iss 10

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
Run Code Online (Sandbox Code Playgroud)

它们对消息的整个主体进行加密和base64编码.

回答你的问题:

在加密此消息时,判断s/mime电子邮件是否使用附加签名进行签名的最简单方法(就计算资源而言)是什么?

唯一的方法是解密它.

这是否意味着我必须解密消息只是为了告诉它是否也签名?

是.


Ada*_*iss 7

如果目标是确保:

  1. 只有收件人才能解密邮件,并且
  2. 收件人知道谁写了邮件,

然后正确的顺序是签名,加密,然后再次签名.否则你无论如何都不能相信它.这就是原因.

签名和加密邮件: 发件人首先签署邮件,然后加密.
在这里,收件人可以解密邮件,然后在签名完整的情况下重新加密邮件并将其发送给第三方(带有欺骗性标题).当第三方实际上由原始收件人转发时,该第三方会相信原始作者直接将该邮件发送给他.

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

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

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

  • 加密消息两次更多

  • 更糟的是,加密,那么符号被称为是容易受到攻击.

签名,加密和签名消息: 发件人签名并加密消息,然后再次签名.
这里,内部签名意味着作者知道内容.加密确保只有收件人才能解密它.外部签名意味着作者为收件人打算发送消息.

  • 如果攻击者试图通过删除外部签名并将其替换为自己的签名来声明所有权,则(替换的)外部签名将与内部签名不匹配.

  • 如果收件人解密并将邮件转发给第三方,他必须保留最内层的签名,或者用自己的签名替换.在任何一种情况下,原作者都免除了对该消息的责任.

结论

尽管当前(破坏)标准,您只有在最后一步中签署了消息的发件人才能验证它.因此,您无需担心首先签名然后加密的邮件,因为您不能相信所谓的签名者会将邮件发送给您.

例如,想象一下从总统那里接收签名然后加密的消息,邀请你去白宫吃饭.事实上,总统确实写了这个消息,但实际上他把它发给了一个决定对你开玩笑的人.

  • -1,因为您在解释签名/加密邮件的安全性方面付出了巨大努力,但忘记了实际尝试回答问题. (3认同)
  • @Owlstead:首先,感谢您花时间(并且礼貌地)解释您的downvote.您从经验中学到的经验之一,就像我过去告诉我的技术支持主管一样,不是专注于为客户提供他想要的东西; 相反,给他什么_needs_.通过解释为什么它会误导信任签名对已加密的邮件签名后,我回答了基本问题.OP问"我怎么......?" 正确的答案是,"不要这样做,这就是原因." (3认同)
  • -1这个光顾的非回答评分很高。它有很好的信息;它应该是博客文章。别处。根据OP的评论,它对他们的直接任务没有用。我完全同情向所有愚蠢的程序员解释“正确的做事方式”的愿望。(有时,我是那个愚蠢的程序员。)但是,当机械师要求您交给他们一把扳手,而您却详细地告诉他们为什么他们在错误的电动机上工作时,这只会浪费他们的时间并尝试耐心。 (2认同)