4

I received an email recently which displayed as an empty body with a smime.p7m attachment. After some Googling, I discovered it was an encrypted email -- neat! So I started looking for the key. But... I couldn't find it.

On a hunch, I tried downloading the email from my web client and opening it in Thunderbird, and it just worked. This is a fresh install of Thunderbird, with no connection to my email account. So it's encryption that requires no key to decrypt (or where the key is shipped in plaintext with the message) and, therefore, seems entirely pointless.

What's the point?

I can think of two things:

  • This isn't how SMIME is normally used, and it normally does have a key.
  • It's meant to discourage casual inspection, not actually secure communications.
Nic
  • 1,806
  • 14
  • 22
  • 1
    Have you considered using Wikipedia instead of Stack Exchange to answer this question? – Z.T. Jun 19 '19 at 20:39
  • 3
    @Z.T. Not only did I consider it, I actually did research S/MIME before asking. Wikipedia was unhelpful, because it said that keys were required, and made no mention of "decrypting" without a key. – Nic Jun 19 '19 at 20:41
  • 1
    "... is a standard for public key encryption and signing of MIME data". All public key cryptosystems provide encryption, signing or both. You got a message with signing only. – Z.T. Jun 19 '19 at 20:45
  • @Z.T. See, that's exactly what I was missing, which was why I was confused. I didn't realize it could be used for signing. Thanks! – Nic Jun 19 '19 at 20:46
  • This doesn't check out. If it was a sign-only email, it should have had a p7s extension, not p7m. – Lie Ryan Jun 20 '19 at 03:53
  • 2
    @LieRyan: _detached_ signature or the signature part of clearsigned should be p7s, but embedded signeddata (like envelopeddata) should be p7m. Plus C-Disp values are only SHOULDs. – dave_thompson_085 Jun 20 '19 at 09:34

3 Answers3

5

If it opened without a key, it wasn't encrypted. It was probably signed by the sender, and if you have the sender's public key (out of band) then you can verify the signature.

The point of S/MIME is the same as PGP, but geared for corporate use. It's not good, and people should use Signal instead, but when used for encryption it does provide encryption.

The people who downvote this answer because they don't like me saying PGP and S/MIME are not good and should not be used, should read the "Johnny-You-Are-Fired" paper about PGP and S/MIME signatures.

My reply to a comment got too long so I post it here:

@martijnbrinkers in practice you are wrong.

A standard for doing something between you and another person is only good and useful if there is a high chance the other person will (1) have an implementation and (2) that the implementation they have is good. If no one uses the standard (e.g. too hard to implement or expensive) then it's no good. If the major implementations are not good then it's no good.

Take for example TLS. If only an implementation you never heard about had the bug we would agree the bug doesn't mean anything about TLS. But if every major implementation had the bug, like poodle and lucky13 variants, we say TLS was a bad standard (fixed in TLS 1.3).

Back to secure mail, Thunderbird, Outlook, Apple mail all fell? Interoperability with a random implementation used by other side is likely insecure? The standard is bad.

If it's only secure to use if you are sure the counterparty verifies signatures and decrypts using gpg command line outside their mail client, it's not good.

And even when all these bugs are fixed, it's not using authenticated encryption, there is no forward secrecy, the non repudiation is too strong, the metadata is problematic, etc. etc.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • 3
    The "Johnny-You-Are-Fired" issues are related to implementation, not the standard. Bad implementations do not imply that a standard is bad. – martijnbrinkers Aug 05 '19 at 18:11
  • 2
    Signal is neither a practical replacement for email nor without its own security limitations (mostly around its trust model; SMS is simply not a secure way to establish identity and the lack of any practical way to chain trust means most users' keys go unverified; it's possible to use it securely but the same is true of OpenPGP or S/MIME). Also, while Signal's approach to forward secrecy with asynchronous communication is clever in practice, it also means you need an always-available central server. S/MIME (and OpenPGP) make different tradeoffs. – CBHacking Aug 06 '19 at 02:26
  • 1
    Agree with @CBHacking. Comparing Signal with OpenPGP and S/MIME is a bit silly (it's like comparing apples and oranges). Email is asynchronous whereas Signal is synchronous. You cannot use Signal with email unless you completely change the SMTP protocol. – martijnbrinkers Aug 08 '19 at 12:10
0

S/MIME is a format to do secure assymetric encryption (RSA) over email. The mail you have received could have been one of two: If the email was plain text it could have been signed with a certificate issued by a third party verifying the email sender owns this address. (this has limitations, everyone can issue an email certificate, this has meaning if you continuessly message the same person). There is an option you have received an encrypted attachment, while the email itself is plaintext the attachment requires a private key to open.

Jonathan Allon
  • 721
  • 3
  • 14
0

As mentioned by Z.T., the email would not have been encrypted, but only signed.

Since you were seeing an empty mail with a smime.p7m attachment, it seems your usual email client is unable to show S/MIME mail. Opening it with a more robust client (in this case Thunderbird) fixed the issue by properly showing the content.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • 1
    The "usual email client" in question is almost certainly Gmail, which is ***absolutely [REDACTED] terrible*** at handling encrypted or signed messages. – CBHacking Aug 06 '19 at 02:09