Subject: [openpgp] Mitigation of Attacks on Email End-to-End Encryption

From: Marcus Brinkmann <[email-masked]>
Date: Tue, 3 Nov 2020 17:24:58 +0100

Hello,

we have just published a paper on our research how to mitigate attacks
on email end-to-end encryption. The full paper is available here with
open access:

Jörg Schwenk, Marcus Brinkmann, Damian Poddebniak, Jens Müller, Juraj
Somorovsky, and Sebastian Schinzel. 2020. Mitigation of Attacks on Email
End-to-End Encryption. In Proceedings of the 2020 ACM SIGSAC Conference
on Computer and Communications Security (CCS '20). Association for
Computing Machinery, New York, NY, USA, 1647–1664.
DOI:https://doi.org/10.1145/3372297.3417878

We have analyzed three attack vectors: EFAIL malleability gadgets (MG),
EFAIL direct exfiltration (DE), and REPLY attacks.

MG attacks exploit unauthenticated block cipher modes such as CBC and
CFB, and are mitigated by using an authenticated encryption mode such as
AEAD, or by a strict implementation of OpenPGP's modification detection
code.  S/MIME 4.0 and OpenPGP RFC4880bis have added AEAD encryption
modes, and assuming a strict implementation, can also protect against MG
attacks that way. (Currently, RFC4880bis does allow unsafe
implementations of AEAD, and even encourages them due to unrestricted
chunk sizes. This has been previously discussed, and I will re-raise
this issue when the WG has been reinstantiated).

EFAIL DE attacks rely on modifications of the MIME structure to embed
authentic ciphertexts in a context that allows exfiltration of the
plaintext after decryption, for example through image source URLs in a
HTML MIME element before the ciphertext. These attacks have also been
published in the EFAIL paper, and so far were only mitigated at the
recipient side by ad-hoc measures in email clients. Our experience was
that developers were struggling to mitigate these attacks. For example,
we found several bypasses after attempts at mitigation.

REPLY attacks are known for 20+ years: They rely on modifications of the
email header (SMTP) context, that allow the attacker to receive replies
to authentic ciphertexts, were the victim quotes the plaintext back to
the attacker. To our knowledge, these attacks have not been mitigated so
far. We have looked at reply attacks in our paper on covert content
attacks [COVERT].

We have looked systematically at these issues, and propose to protect
the MIME and SMTP context of an email by adding a summary of this
decryption contexts (DC) as associated data (AD) in the AEAD encryption.
This way, any significant modification to these contexts that indicate
an attack would lead to a decryption error, rather than emitting the
plaintext to the application, where it would be subject to a large
attack surface to launch DE or REPLY attacks.

To support this mechanism, OpenPGP RFC4880bis would need to be amended
to allow applications to add arbitrary data to the AD, either directly
(length+value) or by adding a hash representation (constant length). I
plan to introduce a proposal for these changes when the WG is
reinstantiated.

We have evaluated which SMTP headers are relevant for REPLY actions in
email clients, and which MIME contexts can be considered safe. Based on
this (and inspired by DKIM), we make a specific proposal for calculating
the decryption context which is sender-enforced and extensible.

We have implemented this solution with GnuPG and Thunderbird/Enigmail.
It was easy to implement, offered excellent compatibility (low false
positive rate when detecting attacks) and mitigated all REPLY and DE
attacks conclusively without introducing new cryptographic primitives.

I hope these findings are interesting to the OpenPGP community. For
example, some of the problems described in

https://www.ietf.org/archive/id/draft-dkg-lamps-e2e-mail-guidance-00.txt

can be mitigated using our techniques. Also, the REPLY action behavior
of email clients in our evaluation should be useful for the memory hole
project, for example.

Thanks,
Marcus

Bibliography:

[COVERT] Jens Müller, Marcus Brinkmann, Damian Poddebniak, Sebastian
Schinzel, and Jörg Schwenk. 2019. Re: What’s Up Johnny? – Covert Content
Attacks on Email End-to-End Encryption.
https://arxiv.org/ftp/arxiv/papers/1904/1904.07550.pdf.

[EFAIL] Damian Poddebniak, Christian Dresen, Jens Müller, Fabian Ising,
Sebastian Schinzel, Simon Friedberger, Juraj Somorovsky, and Jörg
Schwenk. 2018. Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels. In 27th USENIX Security Symposium, USENIX
Security 2018, Baltimore, MD, USA, August 15-17, 2018., William Enck and
Adrienne Porter Felt (Eds.). USENIX Association, 549–566.
https://www.usenix.org/conference/usenixsecurity18/presentation/poddebniak

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 Nov 2020 16:35:39 +0000

Hiya,

Interesting work and I look forward to seeing your
suggestions as we go.

One thing: the DOI URL below gets me a "not found"
error but indicates that may change in future. Is
that correct? If so, be great if you could send a
ping when the paper is available (or another URL
to a preprint or whatever).

Thanks,
S.

---

From: Marcus Brinkmann <[email-masked]>
Date: Tue, 3 Nov 2020 18:02:37 +0100

Hi,

sorry, I did not test the DOI. The URL is:

https://dl.acm.org/doi/10.1145/3372297.3417878

The PDF is at:

https://dl.acm.org/doi/pdf/10.1145/3372297.3417878

Thanks,
Marcus

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 7 Nov 2020 23:26:42 -0800

Hi Marcus,

Thanks for posting this (and the work itself, of course)!

On Tue, Nov 03, 2020 at 05:24:58PM +0100, Marcus Brinkmann wrote:
[...]
> the decryption context which is sender-enforced and extensible.

I'll also leave a link to
https://tools.ietf.org/html/draft-ietf-lamps-header-protection-02 that,
IIUC, is attempting to address similar issues for S/MIME.

-Ben

---

From: Marcus Brinkmann <[email-masked]>
Date: Mon, 9 Nov 2020 14:10:31 +0100

Hi,

Thanks for reminding me about previous efforts for header protection. We
mention Memory Hole in the paper, but a longer discussion had to be left
out because of the page limit.

The main point to keep in mind is that if protected headers are
encrypted, they can't be verified before decryption. This means that
there is a window for an attacker to potentially exploit. The semantics
of AEAD ensure that no unauthenticated plaintext is emitted, closing
this gap conclusively.

Having two (or more!) sets of headers, one unprotected and one
protected, can also be very error prone and lead to usability issues.

Previous efforts have focussed on privacy, rather than as a defense to
attacks. That said, our analysis of headers used in REPLY actions should
be very relevant to other efforts protecting headers as well.

Thanks,
Marcus

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Nov 2020 14:28:36 -0800

> be very relevant to other efforts protecting headers as well.

Indeed, and thanks again.

-Ben

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 14 Nov 2020 02:07:50 -0500

On Tue 2020-11-03 17:24:58 +0100, Marcus Brinkmann wrote:
> I hope these findings are interesting to the OpenPGP community.

They definitely are, thanks.

> For example, some of the problems described in
>
> can be mitigated using our techniques.

I'd welcome contributions (and co-editors) on that document if any of
the authors of this work.  I would hope it's a way that we can publish
specific guidance like this in the IETF.

Alexey Melnikov has asked the LAMPS WG to adopt that draft, and we'll be
discussing it in the upcoming LAMPS meeting at IETF 109 on Tuesday, if
you want to join the discussion remotely.

Thanks very much for doing this work!

       --dkg