1835697 - Thunderbird: Add decryption support for S/MIME authEnveloped-data PKCS7 Cryptographic Layer and aes-GCM content-encryption algorithm

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, enhancement)

Description

[leszek.zablocki]

Attachment: make_AES-GCM_emails.tar.gz

Steps to reproduce:

1. make a self-signed cert (root+user bug#1523130#c8), import .p12 file
   1a. "Manage S/MIME Certificates" → "Your Certificates" tab → "Import..."
   1b. "Authorities" tab → "Edit Trust..."
2. create simple e-mail messages (headers, etc. low level stuff), see: bug#1011625#c20
   2a. create a "palette" of algorithms AEAD (3 available in Openssl v3) that we will test: aes-256-gcm, aes-192-gcm and aes-128-gcm
   2b. glue parts from openssl .p7m with email headers to .eml files
3. create folder "tests" in "Local Folders", see: bug#1806122, bug#1688163
4. open envelopedData/RSA_aes256_CBC.eml
   4a. "Copy To" → "Local Folders" → "tests"
5. open authEnvelopedData/RSA_aes256_GCM.eml
   5a. "Copy To" → "Local Folders" → "tests"
6. open first email (from "Local Folders") RSA_aes256_CBC.eml → [decryption OK]
7. open second email RSA_aes256_GCM.eml → [decryption failed, not OK]
   7a. "Message Cannot Be Decrypted"... "There are unknown problems..."
8. carefully modify base64 code of the file envelopedData/RSA_aes256_CBC.eml and import it to local folder, Th.:
   8a. decrypts ciphertext, broken with random characters; displays green padlock "Message Is Encrypted" → [OK, proper behavior]

Actual results:

Th. can't decipher AES-GCM emails encoded in authEnveloped-data

Expected results:

Th. can decrypt and encrypt AES-GCM emails encoded in authEnveloped-data.

1. carefully modify base64 code of the file authEnvelopedData/RSA_aes256_GCM.eml and import it to local folder, Th.:
   1a. tries to decrypt ciphertext, doesn't show the message (discards email); displays an error like "integrity check problem", "the requested encryption operation could not be performed" etc.
   Two possibilities (for encrypt):
2. Th. recognizes "sMIMECapabilities" extension and the AES-GCM fields contained therein and can encrypt emails using "AES-GCM" to a recipient sending such an extension with signed SMIME message.
   1a. Th. sends an "sMIMECapabilities" extension containing "AES-GCM" fields with each signed SMIME message.
3. Th. defaults the content-encryption to AES-GCM. The default setting can be changed in the "Config Editor". [rfc8551#section-2.7.1.2 compliant solution.]
   2a. Th. sends an "sMIMECapabilities" extension containing "AES-GCM" fields with each signed SMIME message. It does so because perhaps some programs support this extension or will in the near future.

"sMIMECapabilities" would look, more or less, like this:

SEQUENCE {
  OBJECT IDENTIFIER sMIMECapabilities (1 2 840 113549 1 9 15)
  SET {
    SEQUENCE {
      SEQUENCE {
        OBJECT IDENTIFIER aes256-GCM (2 16 840 1 101 3 4 1 46)
        }
      SEQUENCE {
        OBJECT IDENTIFIER aes192-GCM (2 16 840 1 101 3 4 1 26)
        }
      SEQUENCE {
        OBJECT IDENTIFIER aes128-GCM (2 16 840 1 101 3 4 1 6)
        }
      SEQUENCE {
        OBJECT IDENTIFIER aes256-CBC (2 16 840 1 101 3 4 1 42)
        }
      SEQUENCE {
        OBJECT IDENTIFIER aes192-CBC (2 16 840 1 101 3 4 1 22)
        }
      SEQUENCE {
        OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
        }
      SEQUENCE {
        OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)
        }
      SEQUENCE {
        OBJECT IDENTIFIER sha-384 (2 16 840 1 101 3 4 2 2)
        }
      SEQUENCE {
        OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
        }
      }
    }
  }

Comment 1

[leszek.zablocki]

Attachment: brian_gcm.jpg

Comment 2

[leszek.zablocki]

authEnvelopedData  OID 1.2.840.113549.1.9.16.1.23
aes256-GCM         OID 2.16.840.1.101.3.4.1.46
aes192-GCM         OID 2.16.840.1.101.3.4.1.26
aes128-GCM         OID 2.16.840.1.101.3.4.1.6

Crème de la crème e2ee. SMIME support in Th. is generally neglected (see bug#280588#c13), but we'll see, maybe the work will move forward...

I created a script that generates certificates, creates emails in authEnvelopedData using the latest version of Openssl. I'm attaching a test package.
The package contains a script, result files and a dump of the ASN.1 structure (envelopedData and authEnvelopedData). Openssl is not so bad once you get to know a few of its options. SMIME is even a good standard (you just need to figure out a few rfc).

Once the GCM is implemented, you can try ChaCha20-Poly1305 (rfc8103) ...

Standards

NIST 800-38D, FIPS PUB 197
cms: rfc3852/rfc5652
Authenticated-Enveloped-Data: rfc5083
AES-GCM in cms: rfc5084
other: rfc8551#section-3.4 , rfc5116

similar: bug#1167857#c11, bug#379753, bug#373108
and: bug#1078725, bug#1673177, ESS bug#380624, bug#1576167, bug#84213, bug#229724, bug#222179, bug#136289, bug#130633
(mature, 20-year-old bugs)

Links:
https://datatracker.ietf.org/wg/lamps/documents/
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-e2e-mail-guidance-07
[Add CMS AuthEnvelopedData with AES-GCM support] Openssl Pull Request
https://github.com/openssl/openssl/pull/8024
Malleability gadgets:
https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf
https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/12/06/schwenk2020.pdf

--

User-Agent:
Thunderbird 102.11.0 (64-bit), Windows 10
[Th. sends encrypted messages with aes128-CBC, and signed with sha-256; unselectable options]

Reproducible: Always

Comment 3

[Taavi]

I'm actually kind-of surprised that AuthEnvelopedData is actually not supported. This makes at-rest encryption without signing a bit less safe.

Comment 4

[Taavi]

Attachment: Bug 1835697 - Implement CMS AuthEnvelopedData decryption (RFC 5083/5084). r?kaie

Add support for decoding and decrypting AuthEnvelopedData CMS content
type with AES-GCM (AES-128/192/256-GCM). This enables Thunderbird to
read S/MIME messages encrypted with authenticated encryption.

AEAD ciphers do not support streaming, so AuthEnvelopedData bypasses
the CMS streaming filter. The ASN.1 decoder accumulates ciphertext in
rawContent, and one-shot PK11_Decrypt runs after the full structure
(including the mac field) is parsed.

Also adds GCMParameters decoding to PK11_ParamFromAlgid (RFC 5084).

Comment 5

[Phabricator Automation]

Comment on attachment 9555592 [details]
Bug 1835697 - Implement CMS AuthEnvelopedData decryption (RFC 5083/5084). r?kaie

Revision D288495 was moved to bug 2014073. Setting attachment 9555592 [details] to obsolete.

Comment 6

[Taavi]

Attachment: Bug 1835697 - Accept authEnveloped-data smime-type in S/MIME MIME dispatch. r?kaie

Without this, a CMS message with Content-Type:
application/pkcs7-mime; smime-type=authEnveloped-data is routed to
mimeSuppressedCryptoClass (mimei.cpp) or hits skip_decoding (mimecms.cpp),
so the AES-GCM AuthEnvelopedData decoder added in D288495 is never
reached.

Comment 7

[Kai Engert [:KaiE:]]

I'll postpone review of the Thunderbird patch until after the NSS part is done.

Comment 8

[Kai Engert [:KaiE:]]

If your intention is to implement only decoding in an initial step (which is reasonable), the titles of these bugs should mention "decryption only".

Comment 9

[Kai Engert [:KaiE:]]

Taavi, thanks for your contributions so far.

There is some remaining work left to be done, but overall your work seems to go in the right direction.

Comment 10

[Taavi]

(In reply to Kai Engert [:KaiE:] from comment #8)

If your intention is to implement only decoding in an initial step (which is reasonable), the titles of these bugs should mention "decryption only".

I'd work on encryption as the next step, in a different patchset.

Comment 11

[Kai Engert [:KaiE:]]

If the encryption lands later, it might end up in a different version of NSS/Thunderbird. That would be sufficient reason to have separate bugs so we can track the individual enhancements per version (milestone attribute in bugzilla).

Comment 12

[Taavi]

(In reply to Kai Engert [:KaiE:] from comment #11)

If the encryption lands later, it might end up in a different version of NSS/Thunderbird. That would be sufficient reason to have separate bugs so we can track the individual enhancements per version (milestone attribute in bugzilla).

Hmm, possibly. So this issue should be renamed to include "for decryption" and a separate issue be created for encryption?

Comment 13

[Kai Engert [:KaiE:]]

yes please

Comment 14

[Kai Engert [:KaiE:]]

Let's check a try build prior to landing.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=ecf479e551a4de8a92691b234c7289d6fc256e4f

Comment 15

[Kai Engert [:KaiE:]]

I think those failures in try are unrelated.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/45f8eaca4df7
Accept authEnveloped-data smime-type in S/MIME MIME dispatch. r=kaie