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)?

Was it helpful?

Solution

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.

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top