How to check if encrypted S/MIME message is also signed, without decrypting it

Question

What is the easiest way (in terms of computing resources) to tell if an s/mime email message is signed with attached signature when this message is encrypted?

If a message is just signed, it's easy. It has somewhat like:

for attached signature

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

Or:

for detached signature

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

in its headers.

But when a message is encrypted, you can't tell if it's also signed because the Content-Type header is the same for both cases (just encrypted and encrypted/signed):

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

Does it mean that I have to decrypt the message just to tell if it's also signed? For now, it seems I cannot even tell if my message is signed before I decrypt it (because the signature is within the encrypted data). Or, maybe, S/MIME encrypted and signed data still has some pattern which could let me distinguish between encrypted/signed and encrypted/unsigned data without decryption (which may even be possible if I don't have the certificate for decryption)?

Solution 1

S/MIME is flexible; you can sign and/or encrypt in any combination you want. Email clients, however, typically all behave the same way: Outlook 2010, Apple's Mail, and Thunderbird 17 all sign and then encrypt. The results for these 3 are nearly identical. They include these 3 headers in the message headers:

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

They encrypt and base64-encode the entire body of the message.

To answer your questions:

What is the easiest way (in terms of computing resources) to tell if an s/mime email message is signed with attached signature when this message is encrypted?

The only way is to decrypt it.

Does it mean that I have to decrypt the message just to tell if it's also signed?

Yes.

Solution 2

If the goal is to ensure that:

1. Only the recipient can decrypt the message, and
2. The recipient knows who wrote the message,

then the proper sequence is to sign, encrypt, and then sign again. Otherwise you can't trust it anyway. Here's why.

Signed and Encrypted Message: the sender first signs the message, then encrypts it.
Here the recipient can decrypt the message, then re-encrypt it with the signature intact and send it to a third party (with spoofed headers). That third party will believe the original author sent the message directly to him, when it was actually forwarded by the original recipient.

Encrypted and Signed Message: the sender first encrypts the message, then signs it.
Any attacker can remove the signature, replace it with his own, and claim authorship of the message without knowing its contents.

Encrypted, Signed, and Encrypted Message: the sender encrypts and signs the message, then encrypts it again.
Here, the inner encryption ensures only the intended recipient can read the message. The signature means the author is aware of the content and intends it for the recipient. The outer encryption prevents an attacker from knowing or tampering with the message.

• In this case, the recipient won't know the message is signed until after it's decrypted.

• Encrypting a message twice is more

• Worse, encrypt-then-sign is known to be vulnerable to attack.

Signed, Encrypted, and Signed Message: the sender signs and encrypts the message, then signs it again.
Here, the inner signature means the author is aware of the content. The encryption ensures only the recipient can decrypt it. And the outer signature means the author intended the message for the recipient.

• If an attacker tries to claim ownership by removing the outer signature and replacing it with his own, then the (replaced) outer signature won't match the inner signature.

• If the recipient decrypts and forwards the message to a third party, he must either leave the innermost signature intact or replace it with his own. In either case, the original author is absolved of responsibility for the message.

Conclusion

Despite current (broken) standards, you can verify the sender of a message only if it's been signed in the final step. So you needn't worry about a message that's been signed first and then encrypted, because you can't trust that the alleged signer sent the message to you.

For example, imagine receiving a signed-then-encrypted message from the President, inviting you to dinner at the White House. The President did, in fact, write that message, but he actually sent it to someone who decided to play a joke on you.

Comments

[Maarten Bodewes]

-1 as you make a brilliant effort at explaining the security of signed/encrypted messages, but forgot to actually try and answer the question.

[Adam Liss]

@Owlstead: First, thank you for taking the time (and having the courtesy) to explain your downvote. One of the lessons you learn from experience, as I used to tell my Tech Support lead, is not to focus on giving the customer what he wants; instead, give him what he needs. By explaining why it's misleading to trust the signature on a message that's been encrypted after it's been signed, I answered the underlying question. The OP asked "how can I...?" The proper answer is, "Don't do that, and here's why."

[Maarten Bodewes]

There is a lot wrong with the scheme, but it does protect against many attacks as well. It depends on the use case. E.g. if you just accept messages from certain entities, you don't care if somebody claims it is his message.

[system PAUSE]

-1 This patronizing non-answer is too highly rated. It has good info; it should be a blog post. Elsewhere. As per OP comment, it is not useful for their immediate task. I fully sympathize with the desire to explain The Right Way To Do Things to all the stupid programmers. (And sometimes, I'm that stupid programmer.) But when a mechanic asks you to hand them a spanner and you instead tell them at length why they are working on the wrong motor, it just wastes their time and tries their patience.

[not2savvy]

Good comparison of the different options. For more detailed information on why sign/encrypt/sign should be used, I recommend Defective Sign & Encrypt in S/MIME by Don Davis, chapter 5. However, this option does not seem to be supported by any of the widely used mail clients. In fact, we've found that only sign/encrypt works with them.

[not2savvy]

It should be said that, while the S/MIME standard itself is flexible, most mail clients not only implement just sign/encrypt, but they also don't seem to understand encrypt/sign or sign/encrypt/sign in received mail.