Attacking end-to-end email encryption
Schinzel, Sebastian
In this talk, I’ll present several attacks that leak the plaintext of OpenPGP or S/MIME encrypted emails to an attacker. Some of the attacks are technically interesting, i.e. the two different efail attacks, some are somewhat silly, yet effective. Some abuse HTML emails, some also work with plain ASCII emails. Furthermore, I’ll discuss our lessons learned and describe the efail-related changes to mail clients and the OpenPGP and S/MIME standards.
 The following talk is about email encryption. Who worries that their email encryption might be capable of being hacked or cracked? Worry not, as far as I'm told, it still is rather secure but. And the but will be answered by Sebastian Schinsel, who is one of the age security researchers who uncovered the drama and the details behind eFail, a recently occurred issue with OpenPGP and S-Mime in a lot of email clients. All the technical details he will dig into. So please give a warm hand of applause for Sebastian Schinsel. Okay, so it's good to be back. Thank you everyone for coming. My name is Sebastian. It's my fourth talk here at the CCC. And the other talks that I did were also on encryption. So I somehow like encryption and I like analyzing encryption and I like to break encryption. So I did a talk on TLS where we found an attack against TLS and against XML encryption, for example. And I usually start my talk by asking who's using this specific technology, right? Because when you're usually when you're analyzing or doing a talk about a communication protocol, you ask the people who's using that. And you know, for email, you know, for email it would be silly, right? Because who's using email, everyone of you is using email. Okay? Because I don't know. I mean, when you started using the internet, like in the last 20 years or so, usually the first thing that you do, you dial in onto the internet and you make yourself an email address, right? So everyone has, everyone uses email. But let's take a look at how things work when you send an email. So when you click in your email client, when you compose an email and you click in your email client, send. So the first thing is on one of your devices, you're using the local network and there's a green arrow because it's under your control. So you can define by yourself how secure this link is going to be. Then you use the next connection and the next connection will be to your SMTP server. And this is also a green arrow because it's under your control. Okay? You can control this and usually it's TLS. The same is valid for your IMAP folder because always when you send an email via SMTP, you will upload a copy to your send folder on IMAP and it uses TLS in most of the cases. So therefore the arrow is green. The arrow is not that green anymore when it comes to the backup strategy, for example, an archiving strategy of your email provider, which may be Gmail or GMX, for example, or your company. Okay? But you may have a chance to know the administrators and ask them whether they're doing a good job and stuff like that. You're also, it's not under your control where else your email is uploaded to. So for example, in order to check it for antivirus or anti-spam and stuff like that, right? So it gets uploaded to some cloud, right? Because you want to do a spam filtering. And then it goes out to the internet and, you know, we learned what's happening on the internet. People are listening in on the internet. And we heard from Edward Snowden, for example, that many nation-state actors and agencies are doing this as well. They are listening into your emails or they at least try to. And then the arrows get read as soon as it hits the SMTP server of the receiver, right? Because you don't really know whether they are using TLS encryption in any case. You don't know whether they upload it to another antivirus vendor or so. And then it gets uploaded to the IMAP folder, to the inbox of the receiver, where it gets archived again, right? There's a backup is being done and stuff like that. It's archived. And then finally, the receiver of the email has the ability to check his own email and retrieve the email from his inbox. Okay. So even if you know that the other person that you just sent the email to does a good job in securing it and uses encryption everywhere and so on and so on, you never know whether there's some attacker or so who has compromised the infrastructure and so on and so on. Okay. And this problem multiplies when you send an email to multiple people. Because then all of a sudden the email that you just sent, your email, hits infrastructures of many other people. Okay. So many people have access to this email. And this is the first thing that I want to, this is the first point that I want to make in this talk. People usually talk about their email. It's my email. You know? And when I run my own mail server, it's going to be secure. But this is not the case. I mean, the point of using email is distributing it to your friends, to your colleagues and so on and so on, because you want to exchange it. It's a communication method. But the communication is archived. So people archive this and so on and so on. So it's a mess, basically. Okay. So for the rest of this talk, we need to have some assumption that someone has access to the emails. Okay. Because, right, we just learned that it's distributed. You're archiving your own emails and your email folder and so on and so on. I have the emails of the last 15 years or so in my email folder. And if someone gets access to it, right, boom, I have a problem. Okay. And in order to cope with this, people came up with end-to-end encryption. And there's two competing standards. Out there, the first one is OpenPGP. It was first defined in 1991 from Phil Zimmerman, invited it. And this was like, this happened in the first crypto wars. So this very interesting story. And it's the most widely used email clients. They support OpenPGP, but only when you download the plug-in. Okay. For Asmime, it's usually, you usually have native support in most of the applications. So you just get an Asmime certificate and off you go. You can just use it. And it just works out of the box. But it's mostly used by corporate organizations and military, for example. Right. Not so much by privacy advocates like OpenPGP. Now, we can't measure very well how many people use Asmime. We try it, but there doesn't seem to be a public source where we can measure this. But we can do it on PGP. Because PGP has key servers and you can upload your key there so that people can communicate with you in a secure manner. And this statistic here is the amount of new published key, public keys per month. And it started off very low in 1997. Then in 2003, we saw a constant rise until 2013, where we see a spike here, where it more than doubled. Does anyone know why we saw this spike in 2013? Snowden, right? We had the Snowden revelations and Edward Snowden used PGP to communicate with a journalist who did the actual, like, disclosure of the documents. And so we see this in the uploaded keys. So people use PGP much more. We also see this in the daily, in the amount of daily users of any mail, which is the plug-in for Thunderbird. And you can expect this information. And there we also see around 2013, we see a jump and it increased by 50% or so, something like this. So people use PGP, right? It's not that many. When you compare it to how many people you see mail, a few hundred thousand is not that much, but still, it's a substantial number. The problem here is we know for a fact that in the last 20 years or so, especially non-technical users are not able to use PGP in a secure manner. So we have the first paper from 1999, why Johnny can't encrypt. And then we have a follow-up paper from 2006, why Johnny still can't encrypt. Must have been better, I hope. And then in 2015, we have why Johnny still, still can't encrypt. So we have a long story where people try to use PGP but failed. And this is not something that is inherent in OpenPGP. We have the same papers for SMIME where they said novice users, and they confronted novice users with SMIME and they failed, basically. They weren't able to use it in a secure manner. So therefore, in order to enable people to use PGP, especially PGP and SMIME in a secure manner, you have many tutorials out there. And this is a very interesting tutorial because it's the original video that Edward Snowden recorded in order to teach Glenn Greenwald how to use OpenPGP. It's still on Vimeo, the original video is still there. And what is interesting there is he doesn't recommend a plugin for an email client. He basically says just use webmail and use this PGP standalone application, type your message there, click encrypt, and copy and paste the ciphertext into your webmail. Okay, so there's no integration. And others recommend, for example, Enigmail or GPG tools. Enigmail is the plugin for Thunderbird and GPG tools is the plugin for Apple Mail. Which means that most of them HTML switched on, which is an interesting fact, okay, for something that we're going to talk about later. So I thought about how can I do this talk? And this is how I came up with the agenda. So we start off with some attacks that are very, I find pretty interesting, at least for an academic, they are pretty interesting. And we slowly degrade to pretty silly attacks. And you decide for yourself whether you would fall for it or not. I came to the conclusion that I would probably fall for them. Okay, a light. So we start off with something that is even worse than silly. So what's the worst thing that can happen when you're sending an encrypted mail? You're sent the private key that would be bad. What's even worse? You sent the plain text. Okay. Okay, so in 2014 there was a bug in Enigmail which is documented in their bug tracker. So basically you compose an email, you tell Enigmail to sign and encrypt it, and then you send it and it will be sent in plain text. Okay. Oh, okay, this is not good. In 2017 Outlook did it much better because they did encrypt it, but they packed the plain text along with the cipher text. Okay, bad. And then in 2018 you may remember this. This is just a few months back or so. Enigmail or pretty easy privacy. It's a plugin to Enigmail, so a plugin to the plugin that's actually used for novice users. It gave the feedback that the email that you're composing will be encrypted, but it wasn't. Okay. And the good news here is, okay, the e-file attacks don't apply here because, okay. I mean, it's about, I don't want to make fun of any developers. The point that I'm trying to make here is that email is a plain text protocol. And it's always very difficult to make a protocol that was made for plain text delivery to make this encrypted. When you have a plain text fallback, you're into trouble. Okay. And we saw the same basically with HTTP and HTTPS. Okay. So HTTPS is like now secure, but they had the same issues, right? And browsers and so they were falling back to HTTP and so on and so on. So it's really, really difficult. Now that we have this out of the way, okay, we try to look at the interesting, interesting bugs. And before we start, I want to make a short introduction into how the cryptography in S-MIME and PGP work. And I just make one introduction because both are the same from the viewpoint of the attacks that I'm going to present. Okay. Both are very similar, actually. So we start off by writing a message M. This is here. We generate a session key S. That's basically a random session key. And we use the session key to encrypt the message and make a cipher text C. And we use AES or triple S, for example. Any symmetric cipher will do here. Then we use this session key that we just generated and encrypt this with a public key of the recipient and we get a K. And we pack this K into the message so everything will be packed into a message and sent off to the receiver. The receiver then obtains the encrypted email. He starts extracting the cipher text K and the cipher text C. From K, he decrypts S, which is the session key, right? And with S, he can decrypt the cipher text C and retrieves M. And so both have the same message. Okay. So it's basically hybrid encryption. You use symmetric encryption for the actual encryption of the message and then asymmetric encryption to just encrypt this session key. Now, if you attended my previous talks, I talk a lot about cipher text malleability. So you make tiny changes to a cipher text and it will lead to predictable changes in the plain text, which is strange, right? So we would assume when we just flip a bit here somewhere, okay? Here's a bit that just flipped. And when we decrypt it, we get something like this. Usually, you would think, okay, it's total garbage. Nothing sensible should come out of this. But we see something like this. Most of the message is still intact. We just have a few randomly looking junk binary stuff in there. And we see one changed character here. That used to be email and now it's e-fail. Okay? So there was just a bit flipping happening here. In order to understand this, we need to introduce something that we call a mode of operation. AES or any other block cipher has the property that it uses blocks. In most cases, it's 16 bytes. And when you want to encrypt more than 16 bytes, you need to call AES multiple times and you split it into blocks. And CBC is one way of connecting these cipher text blocks. So the decryption works like this. You have the first cipher text block, the second cipher text block, and the third cipher text block. Only the second one is decrypted. So C1 is decrypted using AES and your key, for example. And the result here is not directly the plain text, but it will be x-oared with C0, which we would also call an initialization vector. Okay? So whatever is written in here will be x-oared on whatever comes out of this description. And we get this plain text here. Now, when we flip a bit or when we change a certain byte in C0, we change whatever comes out here of the decryption and we will flip the same bit at the same position in the plain text, which is interesting. Because now, when we say we use the original C0 and x-oared with P0, so when we x-oared it, when we x-oared two tries the same value, we get basically a block of all zeros, which is like a blank sheet of paper that we can write on. And we call this thing these two blocks here in combination. We call this a CBC gadget because we can reuse it as much as we want. And now, when we now take a chosen cipher text, the nice thing is here, we just x-oared the chosen cipher text on this initialization vector and it means that it will here result in a chosen cipher text. So this requires that we know the value of P0. We need to guess this value of P0. And this is always true, at least for SMIME because all SMIME emails start with a content type. So we always know the first bytes, so this is valid. We can do this. Now, this was like the perfect scenario. It does have some drawbacks because when we try to do the same for C1, we flip a bit here, then we flip a bit also here, but the decryption of C1 results in this random junk. And we can't do anything about it. We don't know whatever will come out here and we can't control it. We just have to deal with it. It's going to be there when we use the CBC gadgets and we have to deal with it. We have to find a way to deal with it. And now we can explain this behavior. You remember this email where we just flipped a single bit and we saw one block was destroyed basically and then the other block we had, like, we can flip arbitrary bits. That's the explanation for it. Now, how do you deal with it? How should a proper crypto protocol deal with it? Usually you do something that is called a message authentication code. It's not a digital signature. A message authentication code is something like a cryptographic checksum that is put right next to the encrypted message and that can be checked after decryption or for decryption. The message authentication code is solely there to detect changes of recypher text. Digital signatures are different, especially in the mail context, because they're pretty much totally separate from the decryption part. So digital signatures are merely only used to display an icon, for example, for valid signature or invalid signature. And the problem here is a smart attacker can use a signed email and strip off the signature. We just strip off this part that we know there's a signature. We can remove the signature and then this doesn't mean there will be an invalid signature, but we will get something like this. This is the icon in Thunderbird for encrypted and not signed. So we can simply strip off a signature and there's valid reasons to send an encrypted email without doing a digital signature on it, right? So we want to do both. So digital signatures won't do, won't prevent this attack. So how does S-MIME look like? Basically, I mean, most of you will have heard of MIME. MIME is like a standard that we use in emails anyway. Here we have an email header. It looks very similar to HTTP. We have content type, colon, empty space, and then it's whatever is coming now for data. And then we have an email body with envelope data, and there we have the list of the encrypted session keys that this ciphertext was encrypted with. And after that, we have the encrypted content info here. This part is the encrypted part where the actual message lies. And now when you look closely and you squint, you see there's no message authentication code. And it's not because I left them out, but because S-MIME doesn't define one. So S-MIME doesn't have a message authentication code, which means it cannot detect by the standard whether a message was changed or not. So how can we attack this? How can we use it? I think you all have a feeling that this shouldn't work. Okay? This is nothing that is supposed to work. This is the plain text that we want to exfiltrate, and we only know the first block. We can pretty much always guess the first block because it's always content type, colon, text HTML or text plain, something like this. Now, we can use this as a gadget here and write our arbitrary plain text. We have a random block and then chosen plain text. Then we copy it again. We again have a random block and some chosen plain text. Then we have a random block and a chosen plain text. Then we have a random block and a chosen plain text. Then we copy here the original cipher text. And we close this thing. And when you look closely again, you see that we're building HTML here. That's a base tag. That's an image tag. It uses a URL that is not closed here. It will be closed down here, and this is effectively the URL, okay? A URL path. And will thus be exfiltrated. So when this HTML is interpreted, the actual plain text is sent to the server. And here we have an old Thunderbird. So that is a version of before May and before we did the disclosure. We first compose a message just to have some PGP cipher text. This is a very secret message. And here we have the attack email that is already prepared. And now it asks us, okay, here's remote content in here. What do you want to do? And we just, just for the last, just like this, we just click it. And we see always now when we select the message, an HTTP request is done to this URL. And when we decode this, it looks pretty, it's encoded. But basically what we have here now, you see here's the secret message. And here's random junk. And here again is random junk, right? So it was successfully exfiltrated. This was the first proof of concept that we had, right? And okay, right? So this works. It's, this is like this dialogue here that you get in Thunderbird that asks you, should I load remote images? Yes or no? This is basically everything that is keeping you from losing your PGP or S-MIME cipher text. S-MIME. We're talking about S-MIME here. Now, what we did next was we were asking ourselves, okay, it works with remote images. We understand this. But what other back channels do we have? Back channel is something where your email client is communicating over the network. That's, so it's not necessarily exfiltrating, but it's just like, how can we convince a client to make a connection to somewhere else? Now, I colored in red all the email clients that require user interaction, that always require user interaction before it does, it opens up a network connection somewhere. In orange, we say that there's no user interaction. So these are the clients that allow, for example, loading remote images by default. Okay, there's mail app, for example, there's Gmail, for example. They will not ask you, they will just load it. Okay. And, but what we think is worse, and therefore we colored in red, are the clients that say we won't load remote images or any other way of communicating over the network, but then they will because we found bypasses. Okay, so because preventing loading remote images is basically a firewall, and we bypassed this local firewall and found several ways of extracting it. And there's even four or five of them that even allow JavaScript execution, right, in a mail client. I mean, come on. This is really weird. So basically, 40 or 47 clients have back channels that require no user interaction at all. And now we went out and tried to think about how can we exfiltrate plaintext over it. And this is the final, the final table, the final result table of for Esmime. And it looks pretty grim, right? So the red ones means it's vulnerable. That means we could exfiltrate plaintext successfully. The ones with a dash, they don't support Esmime. And Clause and Mudd, they don't, we just didn't find any remote connection there. Okay. Which is good. Which is good. Yeah. That's a round of applause, right? So I didn't say what S in Esmime means. It actually means super. So it's supermime. I don't know. Is it supermime? I don't know. And basically, his kryptonite, you know, the supervillain of supermime is HTML here, right? You could say this. Okay. So Esmime is broken by HTML. And it's very annoying, a very annoying kryptonite because it jumps into, you know, like his ugly colors. Now, this is my Thunderbird that I have on my Mac at home. So this is like something that I recorded two days ago or so. And here I want to try to show you a way of exfiltrating the data without using HTML. So HTML here is disabled. This is the message that we want to break. And here we see the same message where we just changed, using gatcheting, we just changed the URL. So in Thunderbird, when you disable HTML, it will still highlight the links. And when you click on it, you're going to exfiltrate plain text, right? So we require a little bit of user interaction, but we can basically change a Esmime cipher text in a way that it will contain links. And when you click a single link, you will lose your plain text. It's just a single click on it. And the thing here is, I mean, this is not a zero day in a mail client, right? You just can't do anything about it. That's the problem. Okay. So people said, okay, EFIL, that's just disabled HTML, and then you'll be fine. But the problem here is basically EFIL should work with any format that supports external connections. So as soon as you have a file format, for example, that supports external connections like PDF here, right, this is a PDF. When you click on it, it will warn you and will say, do you really want to make a connection to this domain? And if you click yes, you will do a connection there, right? And when you look at how the URL is encoded in the PDF, when you open the PDF in a hex editor, you see it's just a string, just like HTML, basically, right? So you could, if you reuse this as well, so you could change an Esmime email that it contains a PDF attachment, and when you click the PDF attachment, it will extortate. With no user interaction, it works with Microsoft Word, for example. So that's a doc file, and doc files allow external images that will load. It has no user interaction at all, so you just open it and the request will happen. And the only problem that we're having here is it's not an ASCII URL, it's a Unicode URL. So I'm not sure whether this works with extortation, but hey, no user interaction, right? And now you could say, okay, PDF, Microsoft Word, that's really bad. The same works in Libre Office, and it's not a bug in the viewers, right? That's a basic feature that has been in these standards forever, right? So it's a thing that will be supported. It's not a zero-day vulnerability in these viewers, it's just the file format supported, so you can abuse it. So if you have some time, here's your challenge for you. If someone is able to make a successful demo for exfiltrating an Esmime email using a PDF or a doc file, for example, you will get a crate of Plupmata and some e-fields back if you want to. Okay. So what happened after we disclosed it? Obviously we disclosed it to all the manufacturers and so on. And there's an Esmime draft of a new RFC, so there's a working group, and they already massaged the countermeasures into the current RFC draft. So for example, to counter the CBC gadget attack, they say use AESGCM, which is not right now in the current RFC, but in a draft, it's already in. And so they're referencing the paper and they're saying, okay, you need to do this and do this as quickly as possible. And the second e-fill attack, which I'll talk about very soon, is also mitigated in this RFC draft. So, okay, so Esmime is pretty much broken, and you can just try to convince your email client not to do any external connections. Okay, that's all you have, which at least, I mean, for a cryptographer, this means broken. Okay, when you have to rely on the viewer not making any connections, the cryptography is broken. So what are the changes to openPGP? Because there are substantial differences to openPGP. So first of all, PGP uses a variation of the CFB mode. It's not CBC mode, but CFB mode, and they have pretty similar, they're very similar. So I won't show it here if you're looking for the details. Please look at the paper, but it's very similar. We can also flip bits, and we also have these chunk bits in the middle, and so on. What really costs a lot of headaches is the plaintext compression. So that means in openPGP, you don't encrypt directly the plaintext, but you deflate it before you encrypt it, and that makes it very hard to guess plaintext bytes. Because for our attack to work, we need to guess plaintext bytes, and when we know plaintext, certain parts of the plaintext, but it's deflated, we have a problem. And what is also the most important thing is that openPGP defines an modification detection code, which is basically, this is the message here, and the modification detection code is a hash of the message appended at the plaintext and then encrypted, which should detect plaintext modifications. Now, how does the openPGP standards say how to deal with broken MDCs when an MDC is not valid? Well, they say an implementation must treat an MDC failure as a security problem, but they don't say what's a security problem. What do you need to do then? And the implementation may allow the user access to the Iranians data, so the modified data may be passed on to the email clients. And basically, we tried to do this. But before we go there, we looked at how many keys on the public key service support MDCs at all. So MDC is a feature that came to openPGP in the early 2000s, and before that, it wasn't possible to use it. And so therefore, to make the change from software that doesn't use MDC versus software that does use MDC, they encoded in the key whether you support MDCs or not. And here you see those keys that were generated in 2000. They don't support MDCs and the green ones, they support it. But the problem is when you accumulate all the valid keys in PGP that don't support MDCs, we still see that at the key service right now in 2017, we have something like 1.7 million of the keys that don't support MDCs. So when I send an email to one of these people, my implementation will not use an MDC. Or, yeah, right. They, yeah, I'll come to this later. So we thought about, okay, how can we make a structured analysis how the MDC is treated with? The openPGP standard is not clear what to do with it. And so we have three test cases. First of all, we try to strip the MDC. So we just use this and crypt the packet here and strip off at the end. We just say, okay, it's incorrect, right? So we make our modification in the plain text and see whether it's, whether they will detect this error. Or we could also do this downgrade from the packet type that supports MDC to the old packet type that does not support MDC, right? And when we check this, especially with the most widely used clients, we saw that Thunderbird and Enigmael and Apple Mail and GBG tools, they basically ignored the MDC. And that was the reason why we didn't see the MDC as very important because in our test systems, it wasn't just, it wasn't just treated, okay? Now, what are the E-FIL related changes to openPGP? And we're talking about the changes that were done after we disclosed this to them. First of all, they make something that was, that is very important. They say that the packet type in PGP that does not support MDC is now obsolete. So you must not use this packet type anymore. You must ignore it. Which also means that when you have used non-MDC messages in your mailbox, you will not be able to open them anymore, okay? Yeah, that's a problem. Then they also said, okay, what is supposed to happen when the MDC was wrong? And this is the text that we have already seen where we said the implementation may allow the user access to the Erranius data. And they changed this in the current draft to the implementation should not allow the user to process the Erranius data, right? They must still warn the user and so on and so on, but it should not allow the user, which is good. That's a good change. So this was, this MDC check is a bit troublesome because it's right at the end of the plain text. So you can only check the MDC when you have fully decrypted the message, which means when you have a large email or a large backup or so, you have to fully decrypt it and afterwards only you can tell whether it was valid or not. And the solution of GNU-PG is that it will just stream, while it decrypts, it will stream the data to the email client and afterwards tell it whether it's supposed to use it or not. Okay, so here's your email, here's your email, here's your email. Oh, no, you must not use it. Please forget it, right? Which is not fine. This is not a safe way of doing it. So the current openPGP draft before we did the disclosure already supported something that they called chunking. So they not only have an MDC, some kind of a Mac at the end of the plain text, but they chunk it into more chunks and each of these has a Mac, a real Mac, which is much better because you can authenticate chunks and cache it before you give it to the app. The problem is that the standard says that 120 megabyte is a good chunk size, which is far too big, right? Far too big. And when we look at the e-fail-related changes to GNU-PG, so for example, MDCs, there used to be warnings. So when GNU-PG was detecting that an MDC is not there or it's wrong, they would just warn it, but it would still print it out. GNU-PG now fails. It makes a hard failure now. And GNU-PG now always uses the MDC independently of the key denotes that the receiver can use it or not, which is also very good, but it's a breaking change, right? So when you have people that send you PGP emails and you can't decrypt them anymore, you have to tell them that they need to update GNU-PG. They also say that they say the default chunk size is 120 megabyte, which means they still stream unauthenticated plain text, so they missed this opportunity to make this go away, which is a pity. Okay. What is not answered, neither by SMIME nor by PGP, how to deal with past emails. So basically, all the emails that you're sending in SMIME encrypted right now are insecure, and the old ones that don't use MDCs in PGP, they are also not secure, and nobody talks about what's supposed to happen with them. Okay. That was the interesting attack. That was the one that is really cryptographically involving that require changes to the standards and so on. Now let's look at something that's a bit more silly. Okay. So we have Alice writes an email to Bob. We encrypt it and send it off to Bob. Now here we have the original email, and now Eve composes an attack email, and it somehow gained access to the PGP ciphertext. It also works for SMIME, right? It's independent. It's a vulnerability in the mail clients, and now we don't change the ciphertext, we just surround it with other mine parts that are of type HTML and that exfiltrate it. The same as we did before, only that we don't need to change the ciphertext at all, right? So basically, when this is decrypted, it will be replaced with a plain text in place, and then it will be merged into one document. And now I have to tell you something that many people don't seem to know. All mail clients except Matt, they use HTML to view emails. So even when you disable HTML, it basically means that they will use incoming HTML emails, parse them, transform them into something that looks like ASCII, and display this in HTML. Okay. So, right? There's no such thing as ASCII emails with most of the clients. So but here now you have one HTML document which basically means the same, it will exfiltrate. And very easy. Okay. So let's look here on this video. Here we have, we create one ciphertext, we encrypt it, we use Apple mail because this was one of the two vulnerable clients, and we just open this email in order to view the PGP ciphertext, right? We look at the raw code of the ciphertext, the raw source, and we scroll down, and there we see there's the PGP message. Okay. Now in the next, in the next minute, Eve somehow gained access to this ciphertext, and it will compose a attacker email which is hidden in a Python program that we just used to generate an email. So this happened now in the background, you will see an email is incoming. Here we just open the access lock for this, and when we click on it, right at this time, it will be exfiltrated. Okay. So very easy attack. Anyone can do this. You don't need to know anything about cryptography. You only need to understand a little bit of HTML and a little bit of mine, and you can execute this. You know what's worse than this? How about we just exfiltrate many emails with a single attack email? Because we could basically use, here we open an image, here's the ciphertext, here we close it, then we open another image, here's the second ciphertext, then we close it, then we open the third one, and so on, and so on. And what you see here on the left hand side, you see there's 100 ciphertext packed into one email that is sent to this client. I blurred this because I used 100 GPG emails that I sent, right? I didn't want to show them to you. And now this takes some time. Now it's like decrypting, decrypting, decrypting, decrypting, and when you look at the terminal on the left side, you see 100 emails getting exfiltrated, right? Automatically, simply by opening a single email. Okay, this is horrifying. And when I say horrifying, I'm literally mean. This is horrifying. So we were like afraid, okay, when we disclose this, then people will start attacking this within the hour or so, okay? And so we disclosed this in early 2018, end of 2017, early 2018, and in May 2018, we had already shifted the disclosure date twice, and in May we said, okay, we won't shift this anymore. And so therefore we said, okay, we go online, but we want to make a pre-announcement. We want people to warn, we want to warn the people that if you use PGP or S-MIME for very sensitive communication, you should disable it in your email client for now. These are the original tweets that we sent. And we said, okay, in a day, okay, when you have done this, then we will disclose everything, okay? We will go online with a paper and everything. And now, I mean, people started talking about it, and then the new PGP people started tweeting, and they basically broke the embargo. So they told, okay, the attack is working like this. First, you do this, and then you do that, and then you do that, and they were blabbing and so on. And then they sent it, which is annoying, but then they sent this. So they said, note that the new PGP team was not contacted by them in advance. And this, this really, okay, then it got really hot, okay? This is not true. I will show you later, but I mean, this tipped off almost anyone in the InfoSec community, and we got hate emails, and yeah, people were really mad with them. I posted, we did contact them, and this is like the, these are the original dates when I talked with Verna Koch, which is the main developer of KnoopyG, but it was too late. I mean, they recognized it, they said, oh yeah, oh, I forgot, right, that they sent this paper here that writes e-fail with our names and a date and an embargo and so on and so on, and they said, they forgot it, okay? But I mean, we lost at this point, okay? People were hating us, I was called a murderer and so on and so on, so it was really, really weird. If you're interested of how things worked, right, this is an independent summary of the disclosure timeline from Thomas Taschek, which is not involved with us at all, we have never met him, but who was so kind to just compile this just from public information that are really reliable. So, and then something happened that we, what we could foresee, people were finding, like, there were some patches and we told, I told you already that we saw that these patches are not sufficient, and two days later, okay, people came up with new style of attacks, new e-fail attacks, and this was Hano who found something, so he said, I found a trivial bypass, e-fail is still exploitable with latest enigma and Thunderbird, that is three days after we did the disclosure, and he responsibly disclosed this and so on and so on, so everything is fine. Mikhael Lee from the Intercept also developed a proof of concept exploit that works against Apple Mail and GBG tools, also two or three days later, so we were right, right? So people were finding ways to circumvent the fixes that were in there. But still, I mean, okay, media was blowing up, okay? And we didn't actually understand what was really going on there, but you have to know, I mean, PGP is like one of the main users of PHP, of PGP is journalists, right? So, and they basically, I mean, we showed it to them, look, that's the attack, and they were like, what? That's how easy it is? And that's what you see in the press, I guess. So what are the lessons learned from the disclosure? So first of all, people kept complaining, I mean, people kept complaining to us that we didn't stick to the 90-day disclosure deadline, so we had more than 200 days disclosure, and we postponed it and so on and so on, and then the aftermath, it didn't make sense, because we were postponing it and postponing it, and there were still no reliable fixes. So we should have stuck to the 90-day disclosure headline, because after we disclosed it, they were in a rush, they released patches and stuff like, you know, so it was, yeah. Be careful with disclosure pre-announcements. The problem here is people will speculate about the details, you know, because when you say, okay, we'll disclose something tomorrow, but we're not going to speak today, then journalists will speak to some random people, right, that they just get their hands on, and they will just try to guess what it could be, and this means they will underrate the risk or they will overrate the risk. Underrate the risk is just disable external images, loading external images, then you're fine, that is underrating, and overrating is like, okay, PGP is broken forever, right, which is not the case, and they will spread this false information, and you still see this out there, right, it's documented, people have issued like papers and so on and so on with wrong information, provably wrong information, which is bad, and so these disclosure pre-announcements are bad because you're not in control of the communication anymore, that's very bad, and controlling information flow really is key after you do the disclosure, because otherwise you get the wrong story out, and this doesn't help at all. Okay, let's look at the last attack, and we call this reply to attacker, and I have to give credit to the people of Q of 53, which also found this bug or a similar, very similar version of this bug as well and disclosed it, but they were first to disclose it, so credit goes to them, okay, here the attacker scenario is I get an email from some person which makes sense, it's a benign email, okay, it doesn't look bad at all, and the person wants to trick me to answer this email, so this is the email that I get, there's some footer here and stuff like that, and now we look at in the video, it's an old version of mail that we use here, right, this is the email, and I answer it, right, because people were asking me for an appointment, they want to meet me, and I was like, yeah, sure, after my talk, let's just meet, and this is the attacker email that the attacker has opened, and when you look closely down here, you see secret stuff here that shouldn't be in there and that I didn't send, actually. Let's look at the plain text of this email, and the source code of this email, and when you scroll down, you see, it's a mix of just a normal email, benign email, and down here, you find a cipher text, it can be asmime, it can be pgp, it doesn't really matter, and what's happening now is I get this email, this will be decrypted from my mail client, and I don't see it, because I won't scroll down, I'm a lazy person, I'm a top poster, right, now you can go boo, and so on, okay, but still, I mean, top posting is considered evil here, because I basically, the attacker was sending me an email where cipher text was hidden in there, that my email client was decrypting, and I was replying to this email, sending the attacker the actual plain text that I just decrypted, without knowing it, okay, that's silly, okay, come on, that's really silly, okay, what are you supposed to do now, what are the things that you should do, and the important question here is, you should ask yourself, are you targeted by motivated attackers, and a motivated attacker is not necessarily the NSA or so, right, it can be just, I don't know, cybercrime people or so, I mean, we basically came up with these attacks with eight people, and the better part of a year, which is not, which is a lot of research actually, but it's not comparable to a nation state, right, so if you're targeted by a motivated attacker, and if you say, yeah, you are probably targeted by motivated attackers, then avoid email in total, email is not made for secure communication, okay, if you can't avoid it, and there's people who can't avoid using email, they can't just use signal or any other chat client, then definitely use openPGP and encrypt and decrypt outside of the mail client, if you are probably not targeted by motivated attackers, which is most of you, and I presume I would count to the same people here, definitely prefer openPGP over Asmime, because Asmime remains broken, right, there's a standard coming up which fixes most of the stuff, disable HTML for encrypted emails, and this is like, not that easy, note that most email clients use HTML by default, and it might be okay if you fix it, the people that are here in the audience, but think of all the people who are not here in this audience, who are not technically reversed and so on and so on, and they will not disable HTML, right, so be careful with attachments, which is also very how can you be careful with attachments, right, this is not very good, and don't top post, don't cite text in a reply, okay, that was my talk, if you want to meet us afterwards, we're gonna go to the Chaos West, there's a huge enlightened palm and we'll be there if you have questions, you can ask us there, thank you very much. Thanks a lot, Sebastian, for this interesting talk, we still have some time for questions, so if you would like to ask some questions to Sebastian, then please queue up behind the microphones, and please try to be concise with your question, and please get close to the microphone, because the mixing angel in the back is able to make it quieter, but hardly much louder if your distance is not right, so let's start with microphone number two. Hello, I've actually tested the HTMLX2 query for you, but I found out in Thunderbird the HTML parsing of Thunderbird was actually helping against the tag, because the word tag is just disabling any possibility to expetrate the message, because there was some div tag, which is closing your image tag at every point in time. Yeah, so this is one of the fixes that they did, I mean it doesn't help with the cryptography, but it makes exhortation a little more difficult. If you want to do the testing, try the versions from before May this year. I did, I did with all the versions. Okay, we can talk afterwards if you want, let me show it to you. We are streaming all the talks on the internet, and we have people on the internet that would like to ask a question, so please a question from the internet. There were actually many questions in the direction of problems with the mind standards, so what they were asking was basically, wouldn't the expetration be prevented if the email clients would handle the standard correctly? Okay, so I'm not sure whether they meant the mind standards or the S-MIME standards, so basically the mind standards are the one to blame for the direct exhortation attacks, where you have multiple mind parts that are mixed together, and the mind standards don't state explicitly how to do this, so they don't have any rules of how to handle it, and basically I think as a rule of thumb, when you try to be concise and complete with implementing the mind standard, you were vulnerable, and if you were just lazy and just, for example, decrypted the first mind part or so, you were not vulnerable, so leaving out much of the stuff made you more secure, which is weird. Thank you for the answer. We have another question in this hall on microphone number six, and please remember to be concise and get close to the microphone. What do you see as a future replacement to PGP for email encryption? So actually we brainstorm a little, because PGP lacks many of the modern properties like forward secrecy and stuff like this, but it turns out that it's not very easy to do this, especially not with when you don't want to do changes to SMTP and IMAP, so it's going to be difficult, it's going to be difficult to make it more secure than PGP besides the criticism that I already brought in, so email is not a very good protocol, or the protocols that are built in email are not very good to build proper crypto on top of it. Thank you for this answer, so maybe we need to build something and turn you from scratch. There is another question on microphone number two, if I see this correctly. So do I understand it correctly? Looks like there won't be a fix for that multi-part attacks, like there's the normal plain text, the attacker writes, and then there is a server text which my mail client decrypts, there won't be a fix for that. There is a fix, so the mail clients are fixed, because that's a non-breaking fix, that's a good thing here, so you can fix SMIME for example, because it would be a breaking fix, but you could fix the email clients, which was a lot of work because MIME parsers are very complex, but they fixed it, so it's not supposed to work in current mail clients anymore, the direct acceptration part. So we still have quite some time left, and so I would like to have another question from the internet. Yes, so one user asks, would you recommend developers to get PGP into the email clients instead of using extensions? Yeah, I mean, I already talked about this, that not many people use PGP, and also not many people use SMIME. I'm not sure whether this will be increased when OpenPGP is built into most of the mail clients, because you could use SMIME, you know, as soon as SMIME is fixed, it will be fine to use SMIME, and it's already in all the clients in there, but not many people use it. So it would be nice if we could have it, but I'm not sure whether it would have much of an effect on the amount of people who use it. Thank you, and we have another question from microphone number seven. Yes, hello. So I work with journalists here, here, here, there, in the very back. There, there, hello, hello. So I work with journalists, and May was very annoying, and I cannot stress enough how important it is to what the point you've made about communicating around disclosure. We were scrambling. I work with about 200 journalists who use PGP daily, and we were scrambling for any bit of information. What should we do? It was madness. Yes. But I actually have a question. The question is, have you played with mail pile? I've read the, I've read the paper in, in the paper, mail pile, I think I remember was mentioned, and I vaguely remember it was mentioned in a positive light, but I just want to make sure if that's the right thing that I should get from this paper. I don't know it on the, on the top of my head, but if you come afterwards to, to Kau's West, we'll, we'll get out the paper and look at the tests, and then we can answer this question. Cool. Thank you. Okay, we have another question on the microphone number six. So I'd like to know if there's any difference in the attack surface regarding open, open PGP. If plain, like plain PGP is used or PGP mine? For example, if you, if you set your email client to disallow encryption of inline PGP. ID. Yeah, that's a very good question. I mean, the reply to attacker attack that I just showed at the last, the Q 53 people came up with a version that worked with inline PGP, and we showed that it's also possible with, with PGP mine. So I wouldn't say, I mean, most of the people use PGP mine, inline PGP is not used anymore. The problem is when you don't decrypt PGP, inline PGP, then you have a problem when people use PGP and an external application, they can't copy and paste the ciphertext in there anymore, which is also very annoying. And I also told you that it's, I think it's a very good idea to do this outside of the mail client if you're in a, in a, if you, if you face motivated attackers. So it's not that easy. It would be a breaking change that wouldn't maybe not be too good. Okay. Thanks. Okay. Thanks a lot for this answer. I think we are done with all the questions from the hall. If you'd like to continue the discussion with Sebastian Schinsel, you may move yourself to the assembly of Chaos West in the next hall in this direction. And now please give a big round of applause for Sebastian Schinsel and the awesome team behind.
 The following talk is about email encryption. Who worries that their email encryption might  be capable of being hacked or cracked? Worry not, as far as I'm told, it still is rather  secure but. And the but will be answered by Sebastian Schinsel, who is one of the age  security researchers who uncovered the drama and the details behind eFail, a recently occurred  issue with OpenPGP and S-Mime in a lot of email clients. All the technical details he  will dig into. So please give a warm hand of applause for Sebastian Schinsel.  Okay, so it's good to be back. Thank you everyone for coming. My name is Sebastian. It's my fourth  talk here at the CCC. And the other talks that I did were also on encryption. So I somehow like  encryption and I like analyzing encryption and I like to break encryption. So I did a talk on  TLS where we found an attack against TLS and against XML encryption, for example. And I usually  start my talk by asking who's using this specific technology, right? Because when you're  usually when you're analyzing or doing a talk about a communication protocol, you ask the people  who's using that. And you know, for email, you know, for email it would be silly, right? Because  who's using email, everyone of you is using email. Okay? Because I don't know. I mean, when you  started using the internet, like in the last 20 years or so, usually the first thing that you do,  you dial in onto the internet and you make yourself an email address, right? So everyone has,  everyone uses email. But let's take a look at how things work when you send an email. So when  you click in your email client, when you compose an email and you click in your email client,  send. So the first thing is on one of your devices, you're using the local network and there's a  green arrow because it's under your control. So you can define by yourself how secure this link  is going to be. Then you use the next connection and the next connection will be to your SMTP server.  And this is also a green arrow because it's under your control. Okay? You can control this and  usually it's TLS. The same is valid for your IMAP folder because always when you send an email via  SMTP, you will upload a copy to your send folder on IMAP and it uses TLS in most of the cases. So  therefore the arrow is green. The arrow is not that green anymore when it comes to the backup  strategy, for example, an archiving strategy of your email provider, which may be Gmail or GMX,  for example, or your company. Okay? But you may have a chance to know the administrators and ask  them whether they're doing a good job and stuff like that. You're also, it's not under your control  where else your email is uploaded to. So for example, in order to check it for antivirus or  anti-spam and stuff like that, right? So it gets uploaded to some cloud, right? Because you want to  do a spam filtering. And then it goes out to the internet and, you know, we learned what's  happening on the internet. People are listening in on the internet. And we heard from Edward Snowden,  for example, that many nation-state actors and agencies are doing this as well. They are listening  into your emails or they at least try to. And then the arrows get read as soon as it hits the  SMTP server of the receiver, right? Because you don't really know whether they are using TLS  encryption in any case. You don't know whether they upload it to another antivirus vendor or so.  And then it gets uploaded to the IMAP folder, to the inbox of the receiver, where it gets archived  again, right? There's a backup is being done and stuff like that. It's archived. And then finally,  the receiver of the email has the ability to check his own email and retrieve the email from  his inbox. Okay. So even if you know that the other person that you just sent the email to does a  good job in securing it and uses encryption everywhere and so on and so on, you never know  whether there's some attacker or so who has compromised the infrastructure and so on and so  on. Okay. And this problem multiplies when you send an email to multiple people. Because then all  of a sudden the email that you just sent, your email, hits infrastructures of many other people.  Okay. So many people have access to this email. And this is the first thing that I want to,  this is the first point that I want to make in this talk. People usually talk about their email.  It's my email. You know? And when I run my own mail server, it's going to be secure. But this is  not the case. I mean, the point of using email is distributing it to your friends, to your  colleagues and so on and so on, because you want to exchange it. It's a communication method. But  the communication is archived. So people archive this and so on and so on. So it's a mess, basically.  Okay. So for the rest of this talk, we need to have some assumption that someone has access to the  emails. Okay. Because, right, we just learned that it's distributed. You're archiving your own  emails and your email folder and so on and so on. I have the emails of the last 15 years or so in  my email folder. And if someone gets access to it, right, boom, I have a problem. Okay. And in order  to cope with this, people came up with end-to-end encryption. And there's two competing standards.  Out there, the first one is OpenPGP. It was first defined in 1991 from Phil Zimmerman, invited it.  And this was like, this happened in the first crypto wars. So this very interesting story. And  it's the most widely used email clients. They support OpenPGP, but only when you download the  plug-in. Okay. For Asmime, it's usually, you usually have native support in most of the  applications. So you just get an Asmime certificate and off you go. You can just use it. And it  just works out of the box. But it's mostly used by corporate organizations and military, for  example. Right. Not so much by privacy advocates like OpenPGP. Now, we can't measure very well how  many people use Asmime. We try it, but there doesn't seem to be a public source where we can measure  this. But we can do it on PGP. Because PGP has key servers and you can upload your key there so  that people can communicate with you in a secure manner. And this statistic here is the amount of  new published key, public keys per month. And it started off very low in 1997. Then in 2003, we saw  a constant rise until 2013, where we see a spike here, where it more than doubled. Does anyone know  why we saw this spike in 2013? Snowden, right? We had the Snowden revelations and Edward Snowden  used PGP to communicate with a journalist who did the actual, like, disclosure of the documents.  And so we see this in the uploaded keys. So people use PGP much more. We also see this in the daily,  in the amount of daily users of any mail, which is the plug-in for Thunderbird. And you can expect  this information. And there we also see around 2013, we see a jump and it increased by 50% or so,  something like this. So people use PGP, right? It's not that many. When you compare it to how  many people you see mail, a few hundred thousand is not that much, but still, it's a substantial  number. The problem here is we know for a fact that in the last 20 years or so, especially  non-technical users are not able to use PGP in a secure manner. So we have the first paper from  1999, why Johnny can't encrypt. And then we have a follow-up paper from 2006, why Johnny still can't  encrypt. Must have been better, I hope. And then in 2015, we have why Johnny still, still can't  encrypt. So we have a long story where people try to use PGP but failed. And this is not something  that is inherent in OpenPGP. We have the same papers for SMIME where they said novice users,  and they confronted novice users with SMIME and they failed, basically. They weren't able to use it  in a secure manner. So therefore, in order to enable people to use PGP, especially PGP and  SMIME in a secure manner, you have many tutorials out there. And this is a very interesting tutorial  because it's the original video that Edward Snowden recorded in order to teach Glenn Greenwald  how to use OpenPGP. It's still on Vimeo, the original video is still there. And what is interesting  there is he doesn't recommend a plugin for an email client. He basically says just use webmail  and use this PGP standalone application, type your message there, click encrypt, and copy and paste  the ciphertext into your webmail. Okay, so there's no integration. And others recommend, for example,  Enigmail or GPG tools. Enigmail is the plugin for Thunderbird and GPG tools is the plugin for  Apple Mail. Which means that most of them HTML switched on, which is an interesting fact, okay,  for something that we're going to talk about later. So I thought about how can I do this talk?  And this is how I came up with the agenda. So we start off with some attacks that are very,  I find pretty interesting, at least for an academic, they are pretty interesting.  And we slowly degrade to pretty silly attacks. And you decide for yourself whether you would fall  for it or not. I came to the conclusion that I would probably fall for them. Okay, a light.  So we start off with something that is even worse than silly. So what's the worst thing  that can happen when you're sending an encrypted mail? You're sent the private key that would be  bad. What's even worse? You sent the plain text. Okay. Okay, so in 2014 there was a bug in Enigmail  which is documented in their bug tracker. So basically you compose an email, you tell Enigmail  to sign and encrypt it, and then you send it and it will be sent in plain text. Okay. Oh, okay,  this is not good. In 2017 Outlook did it much better because they did encrypt it,  but they packed the plain text along with the cipher text.  Okay, bad. And then in 2018 you may remember this. This is just a few months back or so. Enigmail  or pretty easy privacy. It's a plugin to Enigmail, so a plugin to the plugin that's actually used  for novice users. It gave the feedback that the email that you're composing will be encrypted,  but it wasn't. Okay. And the good news here is, okay, the e-file attacks don't apply here because,  okay. I mean, it's about, I don't want to make fun of any developers. The point that I'm trying to  make here is that email is a plain text protocol. And it's always very difficult to make a protocol  that was made for plain text delivery to make this encrypted. When you have a plain text fallback,  you're into trouble. Okay. And we saw the same basically with HTTP and HTTPS. Okay. So HTTPS is  like now secure, but they had the same issues, right? And browsers and so they were falling  back to HTTP and so on and so on. So it's really, really difficult. Now that we have this out of  the way, okay, we try to look at the interesting, interesting bugs. And before we start, I want  to make a short introduction into how the cryptography in S-MIME and PGP work. And I just make one  introduction because both are the same from the viewpoint of the attacks that I'm going to present.  Okay. Both are very similar, actually. So we start off by writing a message M. This is here.  We generate a session key S. That's basically a random session key. And we use the session key  to encrypt the message and make a cipher text C. And we use AES or triple S, for example. Any  symmetric cipher will do here. Then we use this session key that we just generated and encrypt  this with a public key of the recipient and we get a K. And we pack this K into the message so  everything will be packed into a message and sent off to the receiver. The receiver then obtains  the encrypted email. He starts extracting the cipher text K and the cipher text C. From K,  he decrypts S, which is the session key, right? And with S, he can decrypt the cipher text C  and retrieves M. And so both have the same message. Okay. So it's basically hybrid encryption.  You use symmetric encryption for the actual encryption of the message and then asymmetric  encryption to just encrypt this session key. Now, if you attended my previous talks, I talk a lot  about cipher text malleability. So you make tiny changes to a cipher text and it will lead to  predictable changes in the plain text, which is strange, right? So we would assume when we just  flip a bit here somewhere, okay? Here's a bit that just flipped. And when we decrypt it, we get  something like this. Usually, you would think, okay, it's total garbage. Nothing sensible  should come out of this. But we see something like this. Most of the message is still intact.  We just have a few randomly looking junk binary stuff in there. And we see one changed character  here. That used to be email and now it's e-fail. Okay? So there was just a bit flipping happening  here. In order to understand this, we need to introduce something that we call a mode of operation.  AES or any other block cipher has the property that it uses blocks. In most cases, it's 16 bytes.  And when you want to encrypt more than 16 bytes, you need to call AES multiple times and you split  it into blocks. And CBC is one way of connecting these cipher text blocks. So the decryption works  like this. You have the first cipher text block, the second cipher text block, and the third cipher  text block. Only the second one is decrypted. So C1 is decrypted using AES and your key, for example.  And the result here is not directly the plain text, but it will be x-oared with C0, which we  would also call an initialization vector. Okay? So whatever is written in here will be x-oared  on whatever comes out of this description. And we get this plain text here. Now, when we flip a bit  or when we change a certain byte in C0, we change whatever comes out here of the decryption and we  will flip the same bit at the same position in the plain text, which is interesting. Because now,  when we say we use the original C0 and x-oared with P0, so when we x-oared it,  when we x-oared two tries the same value, we get basically a block of all zeros, which is like a  blank sheet of paper that we can write on. And we call this thing these two blocks here in combination.  We call this a CBC gadget because we can reuse it as much as we want. And now, when we now take a  chosen cipher text, the nice thing is here, we just x-oared the chosen cipher text on this  initialization vector and it means that it will here result in a chosen cipher text. So this requires  that we know the value of P0. We need to guess this value of P0. And this is always true, at least  for SMIME because all SMIME emails start with a content type. So we always know the first bytes,  so this is valid. We can do this. Now, this was like the perfect scenario. It does have some drawbacks  because when we try to do the same for C1, we flip a bit here, then we flip a bit also here,  but the decryption of C1 results in this random junk. And we can't do anything about it. We don't  know whatever will come out here and we can't control it. We just have to deal with it. It's  going to be there when we use the CBC gadgets and we have to deal with it. We have to find a way to  deal with it. And now we can explain this behavior. You remember this email where we just flipped a  single bit and we saw one block was destroyed basically and then the other block we had,  like, we can flip arbitrary bits. That's the explanation for it. Now, how do you deal with it?  How should a proper crypto protocol deal with it? Usually you do something that is called a  message authentication code. It's not a digital signature. A message authentication code is  something like a cryptographic checksum that is put right next to the encrypted message  and that can be checked after decryption or for decryption. The message authentication code is  solely there to detect changes of recypher text. Digital signatures are different, especially  in the mail context, because they're pretty much totally separate from the decryption part.  So digital signatures are merely only used to display an icon, for example, for valid signature  or invalid signature. And the problem here is a smart attacker can use a signed email and strip  off the signature. We just strip off this part that we know there's a signature. We can remove  the signature and then this doesn't mean there will be an invalid signature, but we will get  something like this. This is the icon in Thunderbird for encrypted and not signed. So we can simply  strip off a signature and there's valid reasons to send an encrypted email without doing a digital  signature on it, right? So we want to do both. So digital signatures won't do, won't prevent this  attack. So how does S-MIME look like? Basically, I mean, most of you will have heard of MIME.  MIME is like a standard that we use in emails anyway. Here we have an email header. It looks  very similar to HTTP. We have content type, colon, empty space, and then it's whatever is coming  now for data. And then we have an email body with envelope data, and there we have the list of the  encrypted session keys that this ciphertext was encrypted with. And after that, we have the encrypted  content info here. This part is the encrypted part where the actual message lies. And now when you  look closely and you squint, you see there's no message authentication code. And it's not because  I left them out, but because S-MIME doesn't define one. So S-MIME doesn't have a message  authentication code, which means it cannot detect by the standard whether a message was changed  or not. So how can we attack this? How can we use it? I think you all have a feeling that this  shouldn't work. Okay? This is nothing that is supposed to work. This is the plain text that  we want to exfiltrate, and we only know the first block. We can pretty much always guess the first  block because it's always content type, colon, text HTML or text plain, something like this.  Now, we can use this as a gadget here and write our arbitrary plain text. We have a random block  and then chosen plain text. Then we copy it again. We again have a random block and some  chosen plain text. Then we have a random block and a chosen plain text. Then we have a random block  and a chosen plain text. Then we copy here the original cipher text. And we close this thing.  And when you look closely again, you see that we're building HTML here. That's a base tag.  That's an image tag. It uses a URL that is not closed here. It will be closed down here,  and this is effectively the URL, okay? A URL path. And will thus be exfiltrated. So when this HTML  is interpreted, the actual plain text is sent to the server. And here we have an old Thunderbird.  So that is a version of before May and before we did the disclosure. We first compose a message  just to have some PGP cipher text. This is a very secret message. And here we have the attack  email that is already prepared. And now it asks us, okay, here's remote content in here. What  do you want to do? And we just, just for the last, just like this, we just click it. And we see  always now when we select the message, an HTTP request is done to this URL. And when we decode  this, it looks pretty, it's encoded. But basically what we have here now, you see here's the secret  message. And here's random junk. And here again is random junk, right? So it was successfully  exfiltrated. This was the first proof of concept that we had, right? And okay, right? So this works.  It's, this is like this dialogue here that you get in Thunderbird that asks you, should I load  remote images? Yes or no? This is basically everything that is keeping you from losing your  PGP or S-MIME cipher text. S-MIME. We're talking about S-MIME here. Now, what we did next was  we were asking ourselves, okay, it works with remote images. We understand this. But what other  back channels do we have? Back channel is something where your email client is communicating over  the network. That's, so it's not necessarily exfiltrating, but it's just like, how can we convince  a client to make a connection to somewhere else? Now, I colored in red all the email clients that  require user interaction, that always require user interaction before it does, it opens up a  network connection somewhere. In orange, we say that there's no user interaction. So these are  the clients that allow, for example, loading remote images by default. Okay, there's mail app,  for example, there's Gmail, for example. They will not ask you, they will just load it. Okay.  And, but what we think is worse, and therefore we colored in red, are the clients that say we won't  load remote images or any other way of communicating over the network, but then they will because we  found bypasses. Okay, so because preventing loading remote images is basically a firewall,  and we bypassed this local firewall and found several ways of extracting it. And there's even four  or five of them that even allow JavaScript execution, right, in a mail client. I mean, come on.  This is really weird. So basically, 40 or 47 clients have back channels that require no user  interaction at all. And now we went out and tried to think about how can we exfiltrate  plaintext over it. And this is the final, the final table, the final result table of for  Esmime. And it looks pretty grim, right? So the red ones means it's vulnerable. That means we could  exfiltrate plaintext successfully. The ones with a dash, they don't support Esmime. And Clause and  Mudd, they don't, we just didn't find any remote connection there. Okay. Which is good. Which is  good. Yeah. That's a round of applause, right? So I didn't say what S in Esmime means. It actually  means super. So it's supermime. I don't know. Is it supermime? I don't know. And basically, his  kryptonite, you know, the supervillain of supermime is HTML here, right? You could say this. Okay.  So Esmime is broken by HTML. And it's very annoying, a very annoying kryptonite because it jumps  into, you know, like his ugly colors. Now, this is my Thunderbird that I have on my Mac at home.  So this is like something that I recorded two days ago or so. And here I want to try to show you a  way of exfiltrating the data without using HTML. So HTML here is disabled. This is the message that  we want to break. And here we see the same message where we just changed, using gatcheting, we just  changed the URL. So in Thunderbird, when you disable HTML, it will still highlight the links. And when  you click on it, you're going to exfiltrate plain text, right? So we require a little bit of user  interaction, but we can basically change a Esmime cipher text in a way that it will contain links.  And when you click a single link, you will lose your plain text. It's just a single click on it.  And the thing here is, I mean, this is not a zero day in a mail client, right? You just can't do  anything about it. That's the problem. Okay. So people said, okay, EFIL, that's just disabled HTML,  and then you'll be fine. But the problem here is basically EFIL should work with any format that  supports external connections. So as soon as you have a file format, for example, that supports  external connections like PDF here, right, this is a PDF. When you click on it, it will warn you and  will say, do you really want to make a connection to this domain? And if you click yes, you will do  a connection there, right? And when you look at how the URL is encoded in the PDF, when you open  the PDF in a hex editor, you see it's just a string, just like HTML, basically, right? So you could,  if you reuse this as well, so you could change an Esmime email that it contains a PDF attachment,  and when you click the PDF attachment, it will extortate. With no user interaction, it works  with Microsoft Word, for example. So that's a doc file, and doc files allow external images that  will load. It has no user interaction at all, so you just open it and the request will happen.  And the only problem that we're having here is it's not an ASCII URL, it's a Unicode URL. So I'm  not sure whether this works with extortation, but hey, no user interaction, right? And now you could  say, okay, PDF, Microsoft Word, that's really bad. The same works in Libre Office, and it's not a bug  in the viewers, right? That's a basic feature that has been in these standards forever, right? So  it's a thing that will be supported. It's not a zero-day vulnerability in these viewers, it's just  the file format supported, so you can abuse it. So if you have some time, here's your challenge for  you. If someone is able to make a successful demo for exfiltrating an Esmime email using a PDF or  a doc file, for example, you will get a crate of Plupmata and some e-fields back if you want to.  Okay. So what happened after we disclosed it? Obviously we disclosed it to all the manufacturers  and so on. And there's an Esmime draft of a new RFC, so there's a working group, and they already  massaged the countermeasures into the current RFC draft. So for example, to counter the CBC  gadget attack, they say use AESGCM, which is not right now in the current RFC, but in a draft,  it's already in. And so they're referencing the paper and they're saying, okay, you need to do this  and do this as quickly as possible. And the second e-fill attack, which I'll talk about very soon,  is also mitigated in this RFC draft. So, okay, so Esmime is pretty much broken, and you can just try  to convince your email client not to do any external connections. Okay, that's all you have,  which at least, I mean, for a cryptographer, this means broken. Okay, when you have to rely on  the viewer not making any connections, the cryptography is broken. So what are the changes  to openPGP? Because there are substantial differences to openPGP. So first of all,  PGP uses a variation of the CFB mode. It's not CBC mode, but CFB mode, and they have pretty similar,  they're very similar. So I won't show it here if you're looking for the details. Please look at the  paper, but it's very similar. We can also flip bits, and we also have these chunk bits in the middle,  and so on. What really costs a lot of headaches is the plaintext compression. So that means in  openPGP, you don't encrypt directly the plaintext, but you deflate it before you encrypt it,  and that makes it very hard to guess plaintext bytes. Because for our attack to work,  we need to guess plaintext bytes, and when we know plaintext, certain parts of the plaintext,  but it's deflated, we have a problem. And what is also the most important thing is that openPGP  defines an modification detection code, which is basically, this is the message here, and the  modification detection code is a hash of the message appended at the plaintext and then encrypted,  which should detect plaintext modifications. Now, how does the openPGP standards say  how to deal with broken MDCs when an MDC is not valid? Well, they say an implementation must treat  an MDC failure as a security problem, but they don't say what's a security problem. What do  you need to do then? And the implementation may allow the user access to the Iranians data,  so the modified data may be passed on to the email clients. And basically, we tried to do this.  But before we go there, we looked at how many keys on the public key service support MDCs at all.  So MDC is a feature that came to openPGP in the early 2000s, and before that, it wasn't possible  to use it. And so therefore, to make the change from software that doesn't use MDC versus software  that does use MDC, they encoded in the key whether you support MDCs or not. And here you see those  keys that were generated in 2000. They don't support MDCs and the green ones, they support it.  But the problem is when you accumulate all the valid keys in PGP that don't support MDCs,  we still see that at the key service right now in 2017, we have something like 1.7 million  of the keys that don't support MDCs. So when I send an email to one of these people, my  implementation will not use an MDC. Or, yeah, right. They, yeah, I'll come to this later.  So we thought about, okay, how can we make a structured analysis how the MDC is treated with?  The openPGP standard is not clear what to do with it. And so we have three test cases. First of all,  we try to strip the MDC. So we just use this and crypt the packet here and strip off at the end.  We just say, okay, it's incorrect, right? So we make our modification in the plain text and see  whether it's, whether they will detect this error. Or we could also do this downgrade from the  packet type that supports MDC to the old packet type that does not support MDC, right? And when we  check this, especially with the most widely used clients, we saw that Thunderbird and Enigmael  and Apple Mail and GBG tools, they basically ignored the MDC. And that was the reason why we  didn't see the MDC as very important because in our test systems, it wasn't just, it wasn't just  treated, okay? Now, what are the E-FIL related changes to openPGP? And we're talking about the  changes that were done after we disclosed this to them. First of all, they make something that  was, that is very important. They say that the packet type in PGP that does not support MDC is  now obsolete. So you must not use this packet type anymore. You must ignore it. Which also means  that when you have used non-MDC messages in your mailbox, you will not be able to open them anymore,  okay? Yeah, that's a problem. Then they also said, okay, what is supposed to happen when the MDC  was wrong? And this is the text that we have already seen where we said the implementation may  allow the user access to the Erranius data. And they changed this in the current draft to the  implementation should not allow the user to process the Erranius data, right? They must still  warn the user and so on and so on, but it should not allow the user, which is good. That's a good  change. So this was, this MDC check is a bit troublesome because it's right at the end of the  plain text. So you can only check the MDC when you have fully decrypted the message, which means  when you have a large email or a large backup or so, you have to fully decrypt it and afterwards  only you can tell whether it was valid or not. And the solution of GNU-PG is that it will just  stream, while it decrypts, it will stream the data to the email client and afterwards tell it  whether it's supposed to use it or not. Okay, so here's your email, here's your email, here's your  email. Oh, no, you must not use it. Please forget it, right? Which is not fine. This is not a safe  way of doing it. So the current openPGP draft before we did the disclosure already supported  something that they called chunking. So they not only have an MDC, some kind of a Mac at the end  of the plain text, but they chunk it into more chunks and each of these has a Mac, a real Mac,  which is much better because you can authenticate chunks and cache it before you give it to the app.  The problem is that the standard says that 120 megabyte is a good chunk size, which is far too  big, right? Far too big. And when we look at the e-fail-related changes to GNU-PG, so for example,  MDCs, there used to be warnings. So when GNU-PG was detecting that an MDC is not there or it's  wrong, they would just warn it, but it would still print it out. GNU-PG now fails. It makes a hard  failure now. And GNU-PG now always uses the MDC independently of the key denotes that the  receiver can use it or not, which is also very good, but it's a breaking change, right? So when  you have people that send you PGP emails and you can't decrypt them anymore, you have to tell them  that they need to update GNU-PG. They also say that they say the default chunk size is 120 megabyte,  which means they still stream unauthenticated plain text, so they missed this opportunity to  make this go away, which is a pity. Okay. What is not answered, neither by SMIME nor by PGP,  how to deal with past emails. So basically, all the emails that you're sending in SMIME encrypted  right now are insecure, and the old ones that don't use MDCs in PGP, they are also not secure,  and nobody talks about what's supposed to happen with them. Okay. That was the interesting attack.  That was the one that is really cryptographically involving that require changes to the standards  and so on. Now let's look at something that's a bit more silly. Okay. So we have Alice writes an  email to Bob. We encrypt it and send it off to Bob. Now here we have the original email,  and now Eve composes an attack email, and it somehow gained access to the PGP ciphertext.  It also works for SMIME, right? It's independent. It's a vulnerability in the mail clients,  and now we don't change the ciphertext, we just surround it with other mine parts that are of  type HTML and that exfiltrate it. The same as we did before, only that we don't need to change  the ciphertext at all, right? So basically, when this is decrypted, it will be replaced with a  plain text in place, and then it will be merged into one document. And now I have to tell you  something that many people don't seem to know. All mail clients except Matt, they use HTML to  view emails. So even when you disable HTML, it basically means that they will use incoming  HTML emails, parse them, transform them into something that looks like ASCII, and display this  in HTML. Okay. So, right? There's no such thing as ASCII emails with most of the clients. So but  here now you have one HTML document which basically means the same, it will exfiltrate.  And very easy. Okay. So let's look here on this video. Here we have, we create one ciphertext,  we encrypt it, we use Apple mail because this was one of the two vulnerable clients,  and we just open this email in order to view the PGP ciphertext, right? We look at the raw code  of the ciphertext, the raw source, and we scroll down, and there we see there's the PGP message.  Okay. Now in the next, in the next minute, Eve somehow gained access to this ciphertext,  and it will compose a attacker email which is hidden in a Python program that we just used to  generate an email. So this happened now in the background, you will see an email is incoming.  Here we just open the access lock for this, and when we click on it, right at this time,  it will be exfiltrated. Okay. So very easy attack. Anyone can do this. You don't need to know anything  about cryptography. You only need to understand a little bit of HTML and a little bit of mine,  and you can execute this. You know what's worse than this? How about we just exfiltrate many emails  with a single attack email? Because we could basically use, here we open an image, here's the  ciphertext, here we close it, then we open another image, here's the second ciphertext,  then we close it, then we open the third one, and so on, and so on. And what you see here on the left  hand side, you see there's 100 ciphertext packed into one email that is sent to this client. I  blurred this because I used 100 GPG emails that I sent, right? I didn't want to show them to you.  And now this takes some time. Now it's like decrypting, decrypting, decrypting, decrypting,  and when you look at the terminal on the left side, you see 100 emails getting exfiltrated,  right? Automatically, simply by opening a single email. Okay, this is horrifying.  And when I say horrifying, I'm literally mean. This is horrifying. So we were like afraid,  okay, when we disclose this, then people will start attacking this within the hour or so, okay?  And so we disclosed this in early 2018, end of 2017, early 2018, and in May 2018,  we had already shifted the disclosure date twice, and in May we said, okay, we won't shift this  anymore. And so therefore we said, okay, we go online, but we want to make a pre-announcement.  We want people to warn, we want to warn the people that if you use PGP or S-MIME for very  sensitive communication, you should disable it in your email client for now. These are the  original tweets that we sent. And we said, okay, in a day, okay, when you have done this, then  we will disclose everything, okay? We will go online with a paper and everything.  And now, I mean, people started talking about it, and then the new PGP people started tweeting,  and they basically broke the embargo. So they told, okay, the attack is working like this. First,  you do this, and then you do that, and then you do that, and they were blabbing and so on.  And then they sent it, which is annoying, but then they sent this. So they said,  note that the new PGP team was not contacted by them in advance. And this, this really,  okay, then it got really hot, okay? This is not true. I will show you later, but I mean, this  tipped off almost anyone in the InfoSec community, and we got hate emails, and yeah, people were  really mad with them. I posted, we did contact them, and this is like the, these are the original  dates when I talked with Verna Koch, which is the main developer of KnoopyG, but it was too late.  I mean, they recognized it, they said, oh yeah, oh, I forgot, right, that they sent this paper here  that writes e-fail with our names and a date and an embargo and so on and so on, and they said,  they forgot it, okay? But I mean, we lost at this point, okay? People were hating us, I was called  a murderer and so on and so on, so it was really, really weird. If you're interested of how things  worked, right, this is an independent summary of the disclosure timeline from Thomas Taschek,  which is not involved with us at all, we have never met him, but who was so kind to just compile  this just from public information that are really reliable. So, and then something happened that  we, what we could foresee, people were finding, like, there were some patches and we told, I told  you already that we saw that these patches are not sufficient, and two days later, okay, people came  up with new style of attacks, new e-fail attacks, and this was Hano who found something, so he said,  I found a trivial bypass, e-fail is still exploitable with latest enigma and Thunderbird,  that is three days after we did the disclosure, and he responsibly disclosed this and so on and  so on, so everything is fine. Mikhael Lee from the Intercept also developed a proof of concept  exploit that works against Apple Mail and GBG tools, also two or three days later, so we were right,  right? So people were finding ways to circumvent the fixes that were in there. But still, I mean,  okay, media was blowing up, okay? And we didn't actually understand what was really going on there,  but you have to know, I mean, PGP is like one of the main users of PHP, of PGP is journalists,  right? So, and they basically, I mean, we showed it to them, look, that's the attack, and they were  like, what? That's how easy it is? And that's what you see in the press, I guess. So what are the  lessons learned from the disclosure? So first of all, people kept complaining, I mean, people kept  complaining to us that we didn't stick to the 90-day disclosure deadline, so we had more than 200  days disclosure, and we postponed it and so on and so on, and then the aftermath, it didn't make sense,  because we were postponing it and postponing it, and there were still no reliable fixes. So we  should have stuck to the 90-day disclosure headline, because after we disclosed it, they were in a rush,  they released patches and stuff like, you know, so it was, yeah. Be careful with disclosure  pre-announcements. The problem here is people will speculate about the details, you know,  because when you say, okay, we'll disclose something tomorrow, but we're not going to speak today,  then journalists will speak to some random people, right, that they just get their hands on, and they  will just try to guess what it could be, and this means they will underrate the risk or they will  overrate the risk. Underrate the risk is just disable external images, loading external images,  then you're fine, that is underrating, and overrating is like, okay, PGP is broken forever,  right, which is not the case, and they will spread this false information, and you still see this  out there, right, it's documented, people have issued like papers and so on and so on with wrong  information, provably wrong information, which is bad, and so these disclosure pre-announcements  are bad because you're not in control of the communication anymore, that's very bad, and  controlling information flow really is key after you do the disclosure, because otherwise you get  the wrong story out, and this doesn't help at all. Okay, let's look at the last attack, and we call  this reply to attacker, and I have to give credit to the people of Q of 53, which also found this  bug or a similar, very similar version of this bug as well and disclosed it, but they were first to  disclose it, so credit goes to them, okay, here the attacker scenario is I get an email from  some person which makes sense, it's a benign email, okay, it doesn't look bad at all, and the person  wants to trick me to answer this email, so this is the email that I get, there's some footer here  and stuff like that, and now we look at in the video, it's an old version of mail that we use here,  right, this is the email, and I answer it, right, because people were asking me for an appointment,  they want to meet me, and I was like, yeah, sure, after my talk, let's just meet, and this is the  attacker email that the attacker has opened, and when you look closely down here, you see  secret stuff here that shouldn't be in there and that I didn't send, actually. Let's look at the  plain text of this email, and the source code of this email, and when you scroll down, you see,  it's a mix of just a normal email, benign email, and down here, you find a cipher text, it can be  asmime, it can be pgp, it doesn't really matter, and what's happening now is I get this email,  this will be decrypted from my mail client, and I don't see it, because I won't scroll down,  I'm a lazy person, I'm a top poster, right, now you can go boo, and so on, okay, but still,  I mean, top posting is considered evil here, because I basically, the attacker was sending me an email  where cipher text was hidden in there, that my email client was decrypting, and I was replying  to this email, sending the attacker the actual plain text that I just decrypted, without knowing it,  okay, that's silly, okay, come on, that's really silly, okay, what are you supposed to do now,  what are the things that you should do, and the important question here is, you should ask yourself,  are you targeted by motivated attackers, and a motivated attacker is not necessarily the NSA or  so, right, it can be just, I don't know, cybercrime people or so, I mean, we basically came up with  these attacks with eight people, and the better part of a year, which is not, which is a lot of  research actually, but it's not comparable to a nation state, right, so if you're targeted by a  motivated attacker, and if you say, yeah, you are probably targeted by motivated attackers,  then avoid email in total, email is not made for secure communication, okay, if you can't avoid it,  and there's people who can't avoid using email, they can't just use signal or any other chat client,  then definitely use openPGP and encrypt and decrypt outside of the mail client,  if you are probably not targeted by motivated attackers, which is most of you, and I presume I  would count to the same people here, definitely prefer openPGP over Asmime, because Asmime remains  broken, right, there's a standard coming up which fixes most of the stuff, disable HTML for encrypted  emails, and this is like, not that easy, note that most email clients use HTML by default,  and it might be okay if you fix it, the people that are here in the audience, but think of all  the people who are not here in this audience, who are not technically reversed and so on and so on,  and they will not disable HTML, right, so be careful with attachments, which is also very  how can you be careful with attachments, right, this is not very good, and don't top post, don't  cite text in a reply, okay, that was my talk, if you want to meet us afterwards, we're gonna go to  the Chaos West, there's a huge enlightened palm and we'll be there if you have questions, you can  ask us there, thank you very much.  Thanks a lot, Sebastian, for this interesting talk, we still have some time for questions, so  if you would like to ask some questions to Sebastian, then please queue up behind the  microphones, and please try to be concise with your question, and please get close to the microphone,  because the mixing angel in the back is able to make it quieter, but hardly much louder if your  distance is not right, so let's start with microphone number two.  Hello, I've actually tested the HTMLX2 query for you,  but I found out in Thunderbird the HTML parsing of Thunderbird was actually helping against the  tag, because the word tag is just disabling any possibility to expetrate the message,  because there was some div tag, which is closing your image tag at every point in time.  Yeah, so this is one of the fixes that they did, I mean it doesn't help with the  cryptography, but it makes exhortation a little more difficult. If you want to do the testing,  try the versions from before May this year.  I did, I did with all the versions.  Okay, we can talk afterwards if you want, let me show it to you.  We are streaming all the talks on the internet, and we have people on the internet that would  like to ask a question, so please a question from the internet.  There were actually many questions in the direction of problems with the mind standards,  so what they were asking was basically, wouldn't the expetration be prevented if the email clients  would handle the standard correctly?  Okay, so I'm not sure whether they meant the mind standards or the S-MIME standards,  so basically the mind standards are the one to blame for the direct exhortation attacks,  where you have multiple mind parts that are mixed together, and the mind standards don't  state explicitly how to do this, so they don't have any rules of how to handle it,  and basically I think as a rule of thumb, when you try to be concise and complete with implementing  the mind standard, you were vulnerable, and if you were just lazy and just, for example,  decrypted the first mind part or so, you were not vulnerable, so leaving out much of the stuff  made you more secure, which is weird.  Thank you for the answer. We have another question in this hall on microphone number six,  and please remember to be concise and get close to the microphone.  What do you see as a future replacement to PGP for email encryption?  So actually we brainstorm a little, because PGP lacks many of the modern properties like  forward secrecy and stuff like this, but it turns out that it's not very easy to do this,  especially not with when you don't want to do changes to SMTP and IMAP, so it's going to be  difficult, it's going to be difficult to make it more secure than PGP besides the criticism  that I already brought in, so email is not a very good protocol, or the protocols that are built  in email are not very good to build proper crypto on top of it.  Thank you for this answer, so maybe we need to build something and turn you from scratch.  There is another question on microphone number two, if I see this correctly.  So do I understand it correctly? Looks like there won't be a fix for that multi-part attacks,  like there's the normal plain text, the attacker writes, and then there is a  server text which my mail client decrypts, there won't be a fix for that.  There is a fix, so the mail clients are fixed, because that's a non-breaking fix,  that's a good thing here, so you can fix SMIME for example, because it would be a breaking fix,  but you could fix the email clients, which was a lot of work because MIME parsers are very complex,  but they fixed it, so it's not supposed to work in current mail clients anymore,  the direct acceptration part.  So we still have quite some time left, and so I would like to have another question from the internet.  Yes, so one user asks, would you recommend developers to get PGP into the email clients  instead of using extensions?  Yeah, I mean, I already talked about this, that not many people use PGP,  and also not many people use SMIME.  I'm not sure whether this will be increased when OpenPGP is built into most of the mail clients,  because you could use SMIME, you know, as soon as SMIME is fixed, it will be fine to use SMIME,  and it's already in all the clients in there, but not many people use it.  So it would be nice if we could have it, but I'm not sure whether it would have much of an effect on the amount of people who use it.  Thank you, and we have another question from microphone number seven.  Yes, hello. So I work with journalists here, here, here, there, in the very back.  There, there, hello, hello. So I work with journalists, and May was very annoying,  and I cannot stress enough how important it is to what the point you've made about  communicating around disclosure. We were scrambling. I work with about 200 journalists who use PGP daily,  and we were scrambling for any bit of information. What should we do? It was madness.  Yes. But I actually have a question. The question is, have you played with mail pile?  I've read the, I've read the paper in, in the paper, mail pile, I think I remember was mentioned,  and I vaguely remember it was mentioned in a positive light, but I just want to make sure  if that's the right thing that I should get from this paper.  I don't know it on the, on the top of my head, but if you come afterwards to, to Kau's West,  we'll, we'll get out the paper and look at the tests, and then we can answer this question.  Cool. Thank you. Okay, we have another question on the microphone number six.  So I'd like to know if there's any difference in the attack surface regarding open, open PGP.  If plain, like plain PGP is used or PGP mine? For example, if you, if you set your email client  to disallow encryption of inline PGP.  ID. Yeah, that's a very good question. I mean, the reply to attacker attack that I just showed  at the last, the Q 53 people came up with a version that worked with inline PGP, and we showed  that it's also possible with, with PGP mine. So I wouldn't say, I mean, most of the people use  PGP mine, inline PGP is not used anymore. The problem is when you don't decrypt PGP, inline  PGP, then you have a problem when people use PGP and an external application, they can't copy  and paste the ciphertext in there anymore, which is also very annoying. And I also told you that  it's, I think it's a very good idea to do this outside of the mail client if you're in a, in a,  if you, if you face motivated attackers. So it's not that easy. It would be a breaking change that  wouldn't maybe not be too good. Okay. Thanks. Okay. Thanks a lot for this answer. I think we are  done with all the questions from the hall. If you'd like to continue the discussion with  Sebastian Schinsel, you may move yourself to the assembly of Chaos West in the next hall in this  direction. And now please give a big round of applause for Sebastian Schinsel and the awesome team behind.
35c3-9463-attacking_end-to-end_email_encryption_0_59.png 35c3-9463-attacking_end-to-end_email_encryption_60_659.png 35c3-9463-attacking_end-to-end_email_encryption_660_779.png 35c3-9463-attacking_end-to-end_email_encryption_780_1571.png 35c3-9463-attacking_end-to-end_email_encryption_1572_1631.png 35c3-9463-attacking_end-to-end_email_encryption_1632_1823.png 35c3-9463-attacking_end-to-end_email_encryption_1824_1907.png 35c3-9463-attacking_end-to-end_email_encryption_1908_2039.png 35c3-9463-attacking_end-to-end_email_encryption_2040_2267.png 35c3-9463-attacking_end-to-end_email_encryption_2268_2471.png 35c3-9463-attacking_end-to-end_email_encryption_2472_2771.png 35c3-9463-attacking_end-to-end_email_encryption_2772_31091.png 35c3-9463-attacking_end-to-end_email_encryption_31092_77195.png 35c3-9463-attacking_end-to-end_email_encryption_77196_77255.png 35c3-9463-attacking_end-to-end_email_encryption_77256_77987.png 35c3-9463-attacking_end-to-end_email_encryption_77988_78191.png 35c3-9463-attacking_end-to-end_email_encryption_78192_78899.png 35c3-9463-attacking_end-to-end_email_encryption_78900_80099.png 35c3-9463-attacking_end-to-end_email_encryption_80100_80519.png 35c3-9463-attacking_end-to-end_email_encryption_80520_80663.png 35c3-9463-attacking_end-to-end_email_encryption_80664_80831.png 35c3-9463-attacking_end-to-end_email_encryption_80832_80915.png 35c3-9463-attacking_end-to-end_email_encryption_80916_80999.png 35c3-9463-attacking_end-to-end_email_encryption_81000_81275.png 35c3-9463-attacking_end-to-end_email_encryption_81276_81455.png 35c3-9463-attacking_end-to-end_email_encryption_81456_81659.png 35c3-9463-attacking_end-to-end_email_encryption_81660_81803.png 35c3-9463-attacking_end-to-end_email_encryption_81804_81899.png 35c3-9463-attacking_end-to-end_email_encryption_81900_82415.png 35c3-9463-attacking_end-to-end_email_encryption_82416_83147.png 35c3-9463-attacking_end-to-end_email_encryption_83148_83243.png 35c3-9463-attacking_end-to-end_email_encryption_83244_83375.png 35c3-9463-attacking_end-to-end_email_encryption_83376_83843.png 35c3-9463-attacking_end-to-end_email_encryption_83844_84191.png 35c3-9463-attacking_end-to-end_email_encryption_84192_84323.png 35c3-9463-attacking_end-to-end_email_encryption_84324_84419.png 35c3-9463-attacking_end-to-end_email_encryption_84420_84683.png 35c3-9463-attacking_end-to-end_email_encryption_84684_84875.png 35c3-9463-attacking_end-to-end_email_encryption_84876_84947.png 35c3-9463-attacking_end-to-end_email_encryption_84948_85175.png 35c3-9463-attacking_end-to-end_email_encryption_85176_85679.png 35c3-9463-attacking_end-to-end_email_encryption_85680_85799.png 35c3-9463-attacking_end-to-end_email_encryption_85800_85895.png 35c3-9463-attacking_end-to-end_email_encryption_85896_86615.png 35c3-9463-attacking_end-to-end_email_encryption_86616_87383.png 35c3-9463-attacking_end-to-end_email_encryption_87384_87491.png 35c3-9463-attacking_end-to-end_email_encryption_87492_87563.png 35c3-9463-attacking_end-to-end_email_encryption_87564_87803.png 35c3-9463-attacking_end-to-end_email_encryption_87804_88127.png 35c3-9463-attacking_end-to-end_email_encryption_88128_88247.png 35c3-9463-attacking_end-to-end_email_encryption_88248_88499.png 35c3-9463-attacking_end-to-end_email_encryption_88500_88643.png 35c3-9463-attacking_end-to-end_email_encryption_88644_88691.png 35c3-9463-attacking_end-to-end_email_encryption_88692_88919.png 35c3-9463-attacking_end-to-end_email_encryption_88920_89075.png 35c3-9463-attacking_end-to-end_email_encryption_89076_89171.png 35c3-9463-attacking_end-to-end_email_encryption_89172_89399.png 35c3-9463-attacking_end-to-end_email_encryption_89400_89531.png 35c3-9463-attacking_end-to-end_email_encryption_89532_89747.png 35c3-9463-attacking_end-to-end_email_encryption_89748_89891.png 35c3-9463-attacking_end-to-end_email_encryption_89892_90047.png 35c3-9463-attacking_end-to-end_email_encryption_90048_90275.png 35c3-9463-attacking_end-to-end_email_encryption_90276_90359.png 35c3-9463-attacking_end-to-end_email_encryption_90360_90623.png 35c3-9463-attacking_end-to-end_email_encryption_90624_90791.png 35c3-9463-attacking_end-to-end_email_encryption_90792_90944.png
The following talk is about email encryption. Who worries that their email encryption might be capable of being hacked or cracked? Worry not, as far as I'm told, it still is rather secure but. And the but will be answered by Sebastian Schinsel, who is one of the age security researchers who uncovered the drama and the details behind eFail, a recently occurred issue with OpenPGP and S-Mime in a lot of email clients. All the technical details he will dig into. So please give a warm hand of applause for Sebastian Schinsel. Okay, so it's good to be back. Thank you everyone for coming. My name is Sebastian. It's my fourth talk here at the CCC. And the other talks that I did were also on encryption. So I somehow like encryption and I like analyzing encryption and I like to break encryption. So I did a talk on TLS where we found an attack against TLS and against XML encryption, for example. And I usually start my talk by asking who's using this specific technology, right? Because when you're usually when you're analyzing or doing a talk about a communication protocol, you ask the people who's using that. And you know, for email, you know, for email it would be silly, right? Because who's using email, everyone of you is using email. Okay? Because I don't know. I mean, when you started using the internet, like in the last 20 years or so, usually the first thing that you do, you dial in onto the internet and you make yourself an email address, right? So everyone has, everyone uses email. But let's take a look at how things work when you send an email. So when you click in your email client, when you compose an email and you click in your email client, send. So the first thing is on one of your devices, you're using the local network and there's a green arrow because it's under your control. So you can define by yourself how secure this link is going to be. Then you use the next connection and the next connection will be to your SMTP server. And this is also a green arrow because it's under your control. Okay? You can control this and usually it's TLS. The same is valid for your IMAP folder because always when you send an email via SMTP, you will upload a copy to your send folder on IMAP and it uses TLS in most of the cases. So therefore the arrow is green. The arrow is not that green anymore when it comes to the backup strategy, for example, an archiving strategy of your email provider, which may be Gmail or GMX, for example, or your company. Okay? But you may have a chance to know the administrators and ask them whether they're doing a good job and stuff like that. You're also, it's not under your control where else your email is uploaded to. So for example, in order to check it for antivirus or anti-spam and stuff like that, right? So it gets uploaded to some cloud, right? Because you want to do a spam filtering. And then it goes out to the internet and, you know, we learned what's happening on the internet. People are listening in on the internet. And we heard from Edward Snowden, for example, that many nation-state actors and agencies are doing this as well. They are listening into your emails or they at least try to. And then the arrows get read as soon as it hits the SMTP server of the receiver, right? Because you don't really know whether they are using TLS encryption in any case. You don't know whether they upload it to another antivirus vendor or so. And then it gets uploaded to the IMAP folder, to the inbox of the receiver, where it gets archived again, right? There's a backup is being done and stuff like that. It's archived. And then finally, the receiver of the email has the ability to check his own email and retrieve the email from his inbox. Okay. So even if you know that the other person that you just sent the email to does a good job in securing it and uses encryption everywhere and so on and so on, you never know whether there's some attacker or so who has compromised the infrastructure and so on and so on. Okay. And this problem multiplies when you send an email to multiple people. Because then all of a sudden the email that you just sent, your email, hits infrastructures of many other people. Okay. So many people have access to this email. And this is the first thing that I want to, this is the first point that I want to make in this talk. People usually talk about their email. It's my email. You know? And when I run my own mail server, it's going to be secure. But this is not the case. I mean, the point of using email is distributing it to your friends, to your colleagues and so on and so on, because you want to exchange it. It's a communication method. But the communication is archived. So people archive this and so on and so on. So it's a mess, basically. Okay. So for the rest of this talk, we need to have some assumption that someone has access to the emails. Okay. Because, right, we just learned that it's distributed. You're archiving your own emails and your email folder and so on and so on. I have the emails of the last 15 years or so in my email folder. And if someone gets access to it, right, boom, I have a problem. Okay. And in order to cope with this, people came up with end-to-end encryption. And there's two competing standards. Out there, the first one is OpenPGP. It was first defined in 1991 from Phil Zimmerman, invited it. And this was like, this happened in the first crypto wars. So this very interesting story. And it's the most widely used email clients. They support OpenPGP, but only when you download the plug-in. Okay. For Asmime, it's usually, you usually have native support in most of the applications. So you just get an Asmime certificate and off you go. You can just use it. And it just works out of the box. But it's mostly used by corporate organizations and military, for example. Right. Not so much by privacy advocates like OpenPGP. Now, we can't measure very well how many people use Asmime. We try it, but there doesn't seem to be a public source where we can measure this. But we can do it on PGP. Because PGP has key servers and you can upload your key there so that people can communicate with you in a secure manner. And this statistic here is the amount of new published key, public keys per month. And it started off very low in 1997. Then in 2003, we saw a constant rise until 2013, where we see a spike here, where it more than doubled. Does anyone know why we saw this spike in 2013? Snowden, right? We had the Snowden revelations and Edward Snowden used PGP to communicate with a journalist who did the actual, like, disclosure of the documents. And so we see this in the uploaded keys. So people use PGP much more. We also see this in the daily, in the amount of daily users of any mail, which is the plug-in for Thunderbird. And you can expect this information. And there we also see around 2013, we see a jump and it increased by 50% or so, something like this. So people use PGP, right? It's not that many. When you compare it to how many people you see mail, a few hundred thousand is not that much, but still, it's a substantial number. The problem here is we know for a fact that in the last 20 years or so, especially non-technical users are not able to use PGP in a secure manner. So we have the first paper from 1999, why Johnny can't encrypt. And then we have a follow-up paper from 2006, why Johnny still can't encrypt. Must have been better, I hope. And then in 2015, we have why Johnny still, still can't encrypt. So we have a long story where people try to use PGP but failed. And this is not something that is inherent in OpenPGP. We have the same papers for SMIME where they said novice users, and they confronted novice users with SMIME and they failed, basically. They weren't able to use it in a secure manner. So therefore, in order to enable people to use PGP, especially PGP and SMIME in a secure manner, you have many tutorials out there. And this is a very interesting tutorial because it's the original video that Edward Snowden recorded in order to teach Glenn Greenwald how to use OpenPGP. It's still on Vimeo, the original video is still there. And what is interesting there is he doesn't recommend a plugin for an email client. He basically says just use webmail and use this PGP standalone application, type your message there, click encrypt, and copy and paste the ciphertext into your webmail. Okay, so there's no integration. And others recommend, for example, Enigmail or GPG tools. Enigmail is the plugin for Thunderbird and GPG tools is the plugin for Apple Mail. Which means that most of them HTML switched on, which is an interesting fact, okay, for something that we're going to talk about later. So I thought about how can I do this talk? And this is how I came up with the agenda. So we start off with some attacks that are very, I find pretty interesting, at least for an academic, they are pretty interesting. And we slowly degrade to pretty silly attacks. And you decide for yourself whether you would fall for it or not. I came to the conclusion that I would probably fall for them. Okay, a light. So we start off with something that is even worse than silly. So what's the worst thing that can happen when you're sending an encrypted mail? You're sent the private key that would be bad. What's even worse? You sent the plain text. Okay. Okay, so in 2014 there was a bug in Enigmail which is documented in their bug tracker. So basically you compose an email, you tell Enigmail to sign and encrypt it, and then you send it and it will be sent in plain text. Okay. Oh, okay, this is not good. In 2017 Outlook did it much better because they did encrypt it, but they packed the plain text along with the cipher text. Okay, bad. And then in 2018 you may remember this. This is just a few months back or so. Enigmail or pretty easy privacy. It's a plugin to Enigmail, so a plugin to the plugin that's actually used for novice users. It gave the feedback that the email that you're composing will be encrypted, but it wasn't. Okay. And the good news here is, okay, the e-file attacks don't apply here because, okay. I mean, it's about, I don't want to make fun of any developers. The point that I'm trying to make here is that email is a plain text protocol. And it's always very difficult to make a protocol that was made for plain text delivery to make this encrypted. When you have a plain text fallback, you're into trouble. Okay. And we saw the same basically with HTTP and HTTPS. Okay. So HTTPS is like now secure, but they had the same issues, right? And browsers and so they were falling back to HTTP and so on and so on. So it's really, really difficult. Now that we have this out of the way, okay, we try to look at the interesting, interesting bugs. And before we start, I want to make a short introduction into how the cryptography in S-MIME and PGP work. And I just make one introduction because both are the same from the viewpoint of the attacks that I'm going to present. Okay. Both are very similar, actually. So we start off by writing a message M. This is here. We generate a session key S. That's basically a random session key. And we use the session key to encrypt the message and make a cipher text C. And we use AES or triple S, for example. Any symmetric cipher will do here. Then we use this session key that we just generated and encrypt this with a public key of the recipient and we get a K. And we pack this K into the message so everything will be packed into a message and sent off to the receiver. The receiver then obtains the encrypted email. He starts extracting the cipher text K and the cipher text C. From K, he decrypts S, which is the session key, right? And with S, he can decrypt the cipher text C and retrieves M. And so both have the same message. Okay. So it's basically hybrid encryption. You use symmetric encryption for the actual encryption of the message and then asymmetric encryption to just encrypt this session key. Now, if you attended my previous talks, I talk a lot about cipher text malleability. So you make tiny changes to a cipher text and it will lead to predictable changes in the plain text, which is strange, right? So we would assume when we just flip a bit here somewhere, okay? Here's a bit that just flipped. And when we decrypt it, we get something like this. Usually, you would think, okay, it's total garbage. Nothing sensible should come out of this. But we see something like this. Most of the message is still intact. We just have a few randomly looking junk binary stuff in there. And we see one changed character here. That used to be email and now it's e-fail. Okay? So there was just a bit flipping happening here. In order to understand this, we need to introduce something that we call a mode of operation. AES or any other block cipher has the property that it uses blocks. In most cases, it's 16 bytes. And when you want to encrypt more than 16 bytes, you need to call AES multiple times and you split it into blocks. And CBC is one way of connecting these cipher text blocks. So the decryption works like this. You have the first cipher text block, the second cipher text block, and the third cipher text block. Only the second one is decrypted. So C1 is decrypted using AES and your key, for example. And the result here is not directly the plain text, but it will be x-oared with C0, which we would also call an initialization vector. Okay? So whatever is written in here will be x-oared on whatever comes out of this description. And we get this plain text here. Now, when we flip a bit or when we change a certain byte in C0, we change whatever comes out here of the decryption and we will flip the same bit at the same position in the plain text, which is interesting. Because now, when we say we use the original C0 and x-oared with P0, so when we x-oared it, when we x-oared two tries the same value, we get basically a block of all zeros, which is like a blank sheet of paper that we can write on. And we call this thing these two blocks here in combination. We call this a CBC gadget because we can reuse it as much as we want. And now, when we now take a chosen cipher text, the nice thing is here, we just x-oared the chosen cipher text on this initialization vector and it means that it will here result in a chosen cipher text. So this requires that we know the value of P0. We need to guess this value of P0. And this is always true, at least for SMIME because all SMIME emails start with a content type. So we always know the first bytes, so this is valid. We can do this. Now, this was like the perfect scenario. It does have some drawbacks because when we try to do the same for C1, we flip a bit here, then we flip a bit also here, but the decryption of C1 results in this random junk. And we can't do anything about it. We don't know whatever will come out here and we can't control it. We just have to deal with it. It's going to be there when we use the CBC gadgets and we have to deal with it. We have to find a way to deal with it. And now we can explain this behavior. You remember this email where we just flipped a single bit and we saw one block was destroyed basically and then the other block we had, like, we can flip arbitrary bits. That's the explanation for it. Now, how do you deal with it? How should a proper crypto protocol deal with it? Usually you do something that is called a message authentication code. It's not a digital signature. A message authentication code is something like a cryptographic checksum that is put right next to the encrypted message and that can be checked after decryption or for decryption. The message authentication code is solely there to detect changes of recypher text. Digital signatures are different, especially in the mail context, because they're pretty much totally separate from the decryption part. So digital signatures are merely only used to display an icon, for example, for valid signature or invalid signature. And the problem here is a smart attacker can use a signed email and strip off the signature. We just strip off this part that we know there's a signature. We can remove the signature and then this doesn't mean there will be an invalid signature, but we will get something like this. This is the icon in Thunderbird for encrypted and not signed. So we can simply strip off a signature and there's valid reasons to send an encrypted email without doing a digital signature on it, right? So we want to do both. So digital signatures won't do, won't prevent this attack. So how does S-MIME look like? Basically, I mean, most of you will have heard of MIME. MIME is like a standard that we use in emails anyway. Here we have an email header. It looks very similar to HTTP. We have content type, colon, empty space, and then it's whatever is coming now for data. And then we have an email body with envelope data, and there we have the list of the encrypted session keys that this ciphertext was encrypted with. And after that, we have the encrypted content info here. This part is the encrypted part where the actual message lies. And now when you look closely and you squint, you see there's no message authentication code. And it's not because I left them out, but because S-MIME doesn't define one. So S-MIME doesn't have a message authentication code, which means it cannot detect by the standard whether a message was changed or not. So how can we attack this? How can we use it? I think you all have a feeling that this shouldn't work. Okay? This is nothing that is supposed to work. This is the plain text that we want to exfiltrate, and we only know the first block. We can pretty much always guess the first block because it's always content type, colon, text HTML or text plain, something like this. Now, we can use this as a gadget here and write our arbitrary plain text. We have a random block and then chosen plain text. Then we copy it again. We again have a random block and some chosen plain text. Then we have a random block and a chosen plain text. Then we have a random block and a chosen plain text. Then we copy here the original cipher text. And we close this thing. And when you look closely again, you see that we're building HTML here. That's a base tag. That's an image tag. It uses a URL that is not closed here. It will be closed down here, and this is effectively the URL, okay? A URL path. And will thus be exfiltrated. So when this HTML is interpreted, the actual plain text is sent to the server. And here we have an old Thunderbird. So that is a version of before May and before we did the disclosure. We first compose a message just to have some PGP cipher text. This is a very secret message. And here we have the attack email that is already prepared. And now it asks us, okay, here's remote content in here. What do you want to do? And we just, just for the last, just like this, we just click it. And we see always now when we select the message, an HTTP request is done to this URL. And when we decode this, it looks pretty, it's encoded. But basically what we have here now, you see here's the secret message. And here's random junk. And here again is random junk, right? So it was successfully exfiltrated. This was the first proof of concept that we had, right? And okay, right? So this works. It's, this is like this dialogue here that you get in Thunderbird that asks you, should I load remote images? Yes or no? This is basically everything that is keeping you from losing your PGP or S-MIME cipher text. S-MIME. We're talking about S-MIME here. Now, what we did next was we were asking ourselves, okay, it works with remote images. We understand this. But what other back channels do we have? Back channel is something where your email client is communicating over the network. That's, so it's not necessarily exfiltrating, but it's just like, how can we convince a client to make a connection to somewhere else? Now, I colored in red all the email clients that require user interaction, that always require user interaction before it does, it opens up a network connection somewhere. In orange, we say that there's no user interaction. So these are the clients that allow, for example, loading remote images by default. Okay, there's mail app, for example, there's Gmail, for example. They will not ask you, they will just load it. Okay. And, but what we think is worse, and therefore we colored in red, are the clients that say we won't load remote images or any other way of communicating over the network, but then they will because we found bypasses. Okay, so because preventing loading remote images is basically a firewall, and we bypassed this local firewall and found several ways of extracting it. And there's even four or five of them that even allow JavaScript execution, right, in a mail client. I mean, come on. This is really weird. So basically, 40 or 47 clients have back channels that require no user interaction at all. And now we went out and tried to think about how can we exfiltrate plaintext over it. And this is the final, the final table, the final result table of for Esmime. And it looks pretty grim, right? So the red ones means it's vulnerable. That means we could exfiltrate plaintext successfully. The ones with a dash, they don't support Esmime. And Clause and Mudd, they don't, we just didn't find any remote connection there. Okay. Which is good. Which is good. Yeah. That's a round of applause, right? So I didn't say what S in Esmime means. It actually means super. So it's supermime. I don't know. Is it supermime? I don't know. And basically, his kryptonite, you know, the supervillain of supermime is HTML here, right? You could say this. Okay. So Esmime is broken by HTML. And it's very annoying, a very annoying kryptonite because it jumps into, you know, like his ugly colors. Now, this is my Thunderbird that I have on my Mac at home. So this is like something that I recorded two days ago or so. And here I want to try to show you a way of exfiltrating the data without using HTML. So HTML here is disabled. This is the message that we want to break. And here we see the same message where we just changed, using gatcheting, we just changed the URL. So in Thunderbird, when you disable HTML, it will still highlight the links. And when you click on it, you're going to exfiltrate plain text, right? So we require a little bit of user interaction, but we can basically change a Esmime cipher text in a way that it will contain links. And when you click a single link, you will lose your plain text. It's just a single click on it. And the thing here is, I mean, this is not a zero day in a mail client, right? You just can't do anything about it. That's the problem. Okay. So people said, okay, EFIL, that's just disabled HTML, and then you'll be fine. But the problem here is basically EFIL should work with any format that supports external connections. So as soon as you have a file format, for example, that supports external connections like PDF here, right, this is a PDF. When you click on it, it will warn you and will say, do you really want to make a connection to this domain? And if you click yes, you will do a connection there, right? And when you look at how the URL is encoded in the PDF, when you open the PDF in a hex editor, you see it's just a string, just like HTML, basically, right? So you could, if you reuse this as well, so you could change an Esmime email that it contains a PDF attachment, and when you click the PDF attachment, it will extortate. With no user interaction, it works with Microsoft Word, for example. So that's a doc file, and doc files allow external images that will load. It has no user interaction at all, so you just open it and the request will happen. And the only problem that we're having here is it's not an ASCII URL, it's a Unicode URL. So I'm not sure whether this works with extortation, but hey, no user interaction, right? And now you could say, okay, PDF, Microsoft Word, that's really bad. The same works in Libre Office, and it's not a bug in the viewers, right? That's a basic feature that has been in these standards forever, right? So it's a thing that will be supported. It's not a zero-day vulnerability in these viewers, it's just the file format supported, so you can abuse it. So if you have some time, here's your challenge for you. If someone is able to make a successful demo for exfiltrating an Esmime email using a PDF or a doc file, for example, you will get a crate of Plupmata and some e-fields back if you want to. Okay. So what happened after we disclosed it? Obviously we disclosed it to all the manufacturers and so on. And there's an Esmime draft of a new RFC, so there's a working group, and they already massaged the countermeasures into the current RFC draft. So for example, to counter the CBC gadget attack, they say use AESGCM, which is not right now in the current RFC, but in a draft, it's already in. And so they're referencing the paper and they're saying, okay, you need to do this and do this as quickly as possible. And the second e-fill attack, which I'll talk about very soon, is also mitigated in this RFC draft. So, okay, so Esmime is pretty much broken, and you can just try to convince your email client not to do any external connections. Okay, that's all you have, which at least, I mean, for a cryptographer, this means broken. Okay, when you have to rely on the viewer not making any connections, the cryptography is broken. So what are the changes to openPGP? Because there are substantial differences to openPGP. So first of all, PGP uses a variation of the CFB mode. It's not CBC mode, but CFB mode, and they have pretty similar, they're very similar. So I won't show it here if you're looking for the details. Please look at the paper, but it's very similar. We can also flip bits, and we also have these chunk bits in the middle, and so on. What really costs a lot of headaches is the plaintext compression. So that means in openPGP, you don't encrypt directly the plaintext, but you deflate it before you encrypt it, and that makes it very hard to guess plaintext bytes. Because for our attack to work, we need to guess plaintext bytes, and when we know plaintext, certain parts of the plaintext, but it's deflated, we have a problem. And what is also the most important thing is that openPGP defines an modification detection code, which is basically, this is the message here, and the modification detection code is a hash of the message appended at the plaintext and then encrypted, which should detect plaintext modifications. Now, how does the openPGP standards say how to deal with broken MDCs when an MDC is not valid? Well, they say an implementation must treat an MDC failure as a security problem, but they don't say what's a security problem. What do you need to do then? And the implementation may allow the user access to the Iranians data, so the modified data may be passed on to the email clients. And basically, we tried to do this. But before we go there, we looked at how many keys on the public key service support MDCs at all. So MDC is a feature that came to openPGP in the early 2000s, and before that, it wasn't possible to use it. And so therefore, to make the change from software that doesn't use MDC versus software that does use MDC, they encoded in the key whether you support MDCs or not. And here you see those keys that were generated in 2000. They don't support MDCs and the green ones, they support it. But the problem is when you accumulate all the valid keys in PGP that don't support MDCs, we still see that at the key service right now in 2017, we have something like 1.7 million of the keys that don't support MDCs. So when I send an email to one of these people, my implementation will not use an MDC. Or, yeah, right. They, yeah, I'll come to this later. So we thought about, okay, how can we make a structured analysis how the MDC is treated with? The openPGP standard is not clear what to do with it. And so we have three test cases. First of all, we try to strip the MDC. So we just use this and crypt the packet here and strip off at the end. We just say, okay, it's incorrect, right? So we make our modification in the plain text and see whether it's, whether they will detect this error. Or we could also do this downgrade from the packet type that supports MDC to the old packet type that does not support MDC, right? And when we check this, especially with the most widely used clients, we saw that Thunderbird and Enigmael and Apple Mail and GBG tools, they basically ignored the MDC. And that was the reason why we didn't see the MDC as very important because in our test systems, it wasn't just, it wasn't just treated, okay? Now, what are the E-FIL related changes to openPGP? And we're talking about the changes that were done after we disclosed this to them. First of all, they make something that was, that is very important. They say that the packet type in PGP that does not support MDC is now obsolete. So you must not use this packet type anymore. You must ignore it. Which also means that when you have used non-MDC messages in your mailbox, you will not be able to open them anymore, okay? Yeah, that's a problem. Then they also said, okay, what is supposed to happen when the MDC was wrong? And this is the text that we have already seen where we said the implementation may allow the user access to the Erranius data. And they changed this in the current draft to the implementation should not allow the user to process the Erranius data, right? They must still warn the user and so on and so on, but it should not allow the user, which is good. That's a good change. So this was, this MDC check is a bit troublesome because it's right at the end of the plain text. So you can only check the MDC when you have fully decrypted the message, which means when you have a large email or a large backup or so, you have to fully decrypt it and afterwards only you can tell whether it was valid or not. And the solution of GNU-PG is that it will just stream, while it decrypts, it will stream the data to the email client and afterwards tell it whether it's supposed to use it or not. Okay, so here's your email, here's your email, here's your email. Oh, no, you must not use it. Please forget it, right? Which is not fine. This is not a safe way of doing it. So the current openPGP draft before we did the disclosure already supported something that they called chunking. So they not only have an MDC, some kind of a Mac at the end of the plain text, but they chunk it into more chunks and each of these has a Mac, a real Mac, which is much better because you can authenticate chunks and cache it before you give it to the app. The problem is that the standard says that 120 megabyte is a good chunk size, which is far too big, right? Far too big. And when we look at the e-fail-related changes to GNU-PG, so for example, MDCs, there used to be warnings. So when GNU-PG was detecting that an MDC is not there or it's wrong, they would just warn it, but it would still print it out. GNU-PG now fails. It makes a hard failure now. And GNU-PG now always uses the MDC independently of the key denotes that the receiver can use it or not, which is also very good, but it's a breaking change, right? So when you have people that send you PGP emails and you can't decrypt them anymore, you have to tell them that they need to update GNU-PG. They also say that they say the default chunk size is 120 megabyte, which means they still stream unauthenticated plain text, so they missed this opportunity to make this go away, which is a pity. Okay. What is not answered, neither by SMIME nor by PGP, how to deal with past emails. So basically, all the emails that you're sending in SMIME encrypted right now are insecure, and the old ones that don't use MDCs in PGP, they are also not secure, and nobody talks about what's supposed to happen with them. Okay. That was the interesting attack. That was the one that is really cryptographically involving that require changes to the standards and so on. Now let's look at something that's a bit more silly. Okay. So we have Alice writes an email to Bob. We encrypt it and send it off to Bob. Now here we have the original email, and now Eve composes an attack email, and it somehow gained access to the PGP ciphertext. It also works for SMIME, right? It's independent. It's a vulnerability in the mail clients, and now we don't change the ciphertext, we just surround it with other mine parts that are of type HTML and that exfiltrate it. The same as we did before, only that we don't need to change the ciphertext at all, right? So basically, when this is decrypted, it will be replaced with a plain text in place, and then it will be merged into one document. And now I have to tell you something that many people don't seem to know. All mail clients except Matt, they use HTML to view emails. So even when you disable HTML, it basically means that they will use incoming HTML emails, parse them, transform them into something that looks like ASCII, and display this in HTML. Okay. So, right? There's no such thing as ASCII emails with most of the clients. So but here now you have one HTML document which basically means the same, it will exfiltrate. And very easy. Okay. So let's look here on this video. Here we have, we create one ciphertext, we encrypt it, we use Apple mail because this was one of the two vulnerable clients, and we just open this email in order to view the PGP ciphertext, right? We look at the raw code of the ciphertext, the raw source, and we scroll down, and there we see there's the PGP message. Okay. Now in the next, in the next minute, Eve somehow gained access to this ciphertext, and it will compose a attacker email which is hidden in a Python program that we just used to generate an email. So this happened now in the background, you will see an email is incoming. Here we just open the access lock for this, and when we click on it, right at this time, it will be exfiltrated. Okay. So very easy attack. Anyone can do this. You don't need to know anything about cryptography. You only need to understand a little bit of HTML and a little bit of mine, and you can execute this. You know what's worse than this? How about we just exfiltrate many emails with a single attack email? Because we could basically use, here we open an image, here's the ciphertext, here we close it, then we open another image, here's the second ciphertext, then we close it, then we open the third one, and so on, and so on. And what you see here on the left hand side, you see there's 100 ciphertext packed into one email that is sent to this client. I blurred this because I used 100 GPG emails that I sent, right? I didn't want to show them to you. And now this takes some time. Now it's like decrypting, decrypting, decrypting, decrypting, and when you look at the terminal on the left side, you see 100 emails getting exfiltrated, right? Automatically, simply by opening a single email. Okay, this is horrifying. And when I say horrifying, I'm literally mean. This is horrifying. So we were like afraid, okay, when we disclose this, then people will start attacking this within the hour or so, okay? And so we disclosed this in early 2018, end of 2017, early 2018, and in May 2018, we had already shifted the disclosure date twice, and in May we said, okay, we won't shift this anymore. And so therefore we said, okay, we go online, but we want to make a pre-announcement. We want people to warn, we want to warn the people that if you use PGP or S-MIME for very sensitive communication, you should disable it in your email client for now. These are the original tweets that we sent. And we said, okay, in a day, okay, when you have done this, then we will disclose everything, okay? We will go online with a paper and everything. And now, I mean, people started talking about it, and then the new PGP people started tweeting, and they basically broke the embargo. So they told, okay, the attack is working like this. First, you do this, and then you do that, and then you do that, and they were blabbing and so on. And then they sent it, which is annoying, but then they sent this. So they said, note that the new PGP team was not contacted by them in advance. And this, this really, okay, then it got really hot, okay? This is not true. I will show you later, but I mean, this tipped off almost anyone in the InfoSec community, and we got hate emails, and yeah, people were really mad with them. I posted, we did contact them, and this is like the, these are the original dates when I talked with Verna Koch, which is the main developer of KnoopyG, but it was too late. I mean, they recognized it, they said, oh yeah, oh, I forgot, right, that they sent this paper here that writes e-fail with our names and a date and an embargo and so on and so on, and they said, they forgot it, okay? But I mean, we lost at this point, okay? People were hating us, I was called a murderer and so on and so on, so it was really, really weird. If you're interested of how things worked, right, this is an independent summary of the disclosure timeline from Thomas Taschek, which is not involved with us at all, we have never met him, but who was so kind to just compile this just from public information that are really reliable. So, and then something happened that we, what we could foresee, people were finding, like, there were some patches and we told, I told you already that we saw that these patches are not sufficient, and two days later, okay, people came up with new style of attacks, new e-fail attacks, and this was Hano who found something, so he said, I found a trivial bypass, e-fail is still exploitable with latest enigma and Thunderbird, that is three days after we did the disclosure, and he responsibly disclosed this and so on and so on, so everything is fine. Mikhael Lee from the Intercept also developed a proof of concept exploit that works against Apple Mail and GBG tools, also two or three days later, so we were right, right? So people were finding ways to circumvent the fixes that were in there. But still, I mean, okay, media was blowing up, okay? And we didn't actually understand what was really going on there, but you have to know, I mean, PGP is like one of the main users of PHP, of PGP is journalists, right? So, and they basically, I mean, we showed it to them, look, that's the attack, and they were like, what? That's how easy it is? And that's what you see in the press, I guess. So what are the lessons learned from the disclosure? So first of all, people kept complaining, I mean, people kept complaining to us that we didn't stick to the 90-day disclosure deadline, so we had more than 200 days disclosure, and we postponed it and so on and so on, and then the aftermath, it didn't make sense, because we were postponing it and postponing it, and there were still no reliable fixes. So we should have stuck to the 90-day disclosure headline, because after we disclosed it, they were in a rush, they released patches and stuff like, you know, so it was, yeah. Be careful with disclosure pre-announcements. The problem here is people will speculate about the details, you know, because when you say, okay, we'll disclose something tomorrow, but we're not going to speak today, then journalists will speak to some random people, right, that they just get their hands on, and they will just try to guess what it could be, and this means they will underrate the risk or they will overrate the risk. Underrate the risk is just disable external images, loading external images, then you're fine, that is underrating, and overrating is like, okay, PGP is broken forever, right, which is not the case, and they will spread this false information, and you still see this out there, right, it's documented, people have issued like papers and so on and so on with wrong information, provably wrong information, which is bad, and so these disclosure pre-announcements are bad because you're not in control of the communication anymore, that's very bad, and controlling information flow really is key after you do the disclosure, because otherwise you get the wrong story out, and this doesn't help at all. Okay, let's look at the last attack, and we call this reply to attacker, and I have to give credit to the people of Q of 53, which also found this bug or a similar, very similar version of this bug as well and disclosed it, but they were first to disclose it, so credit goes to them, okay, here the attacker scenario is I get an email from some person which makes sense, it's a benign email, okay, it doesn't look bad at all, and the person wants to trick me to answer this email, so this is the email that I get, there's some footer here and stuff like that, and now we look at in the video, it's an old version of mail that we use here, right, this is the email, and I answer it, right, because people were asking me for an appointment, they want to meet me, and I was like, yeah, sure, after my talk, let's just meet, and this is the attacker email that the attacker has opened, and when you look closely down here, you see secret stuff here that shouldn't be in there and that I didn't send, actually. Let's look at the plain text of this email, and the source code of this email, and when you scroll down, you see, it's a mix of just a normal email, benign email, and down here, you find a cipher text, it can be asmime, it can be pgp, it doesn't really matter, and what's happening now is I get this email, this will be decrypted from my mail client, and I don't see it, because I won't scroll down, I'm a lazy person, I'm a top poster, right, now you can go boo, and so on, okay, but still, I mean, top posting is considered evil here, because I basically, the attacker was sending me an email where cipher text was hidden in there, that my email client was decrypting, and I was replying to this email, sending the attacker the actual plain text that I just decrypted, without knowing it, okay, that's silly, okay, come on, that's really silly, okay, what are you supposed to do now, what are the things that you should do, and the important question here is, you should ask yourself, are you targeted by motivated attackers, and a motivated attacker is not necessarily the NSA or so, right, it can be just, I don't know, cybercrime people or so, I mean, we basically came up with these attacks with eight people, and the better part of a year, which is not, which is a lot of research actually, but it's not comparable to a nation state, right, so if you're targeted by a motivated attacker, and if you say, yeah, you are probably targeted by motivated attackers, then avoid email in total, email is not made for secure communication, okay, if you can't avoid it, and there's people who can't avoid using email, they can't just use signal or any other chat client, then definitely use openPGP and encrypt and decrypt outside of the mail client, if you are probably not targeted by motivated attackers, which is most of you, and I presume I would count to the same people here, definitely prefer openPGP over Asmime, because Asmime remains broken, right, there's a standard coming up which fixes most of the stuff, disable HTML for encrypted emails, and this is like, not that easy, note that most email clients use HTML by default, and it might be okay if you fix it, the people that are here in the audience, but think of all the people who are not here in this audience, who are not technically reversed and so on and so on, and they will not disable HTML, right, so be careful with attachments, which is also very how can you be careful with attachments, right, this is not very good, and don't top post, don't cite text in a reply, okay, that was my talk, if you want to meet us afterwards, we're gonna go to the Chaos West, there's a huge enlightened palm and we'll be there if you have questions, you can ask us there, thank you very much. Thanks a lot, Sebastian, for this interesting talk, we still have some time for questions, so if you would like to ask some questions to Sebastian, then please queue up behind the microphones, and please try to be concise with your question, and please get close to the microphone, because the mixing angel in the back is able to make it quieter, but hardly much louder if your distance is not right, so let's start with microphone number two. Hello, I've actually tested the HTMLX2 query for you, but I found out in Thunderbird the HTML parsing of Thunderbird was actually helping against the tag, because the word tag is just disabling any possibility to expetrate the message, because there was some div tag, which is closing your image tag at every point in time. Yeah, so this is one of the fixes that they did, I mean it doesn't help with the cryptography, but it makes exhortation a little more difficult. If you want to do the testing, try the versions from before May this year. I did, I did with all the versions. Okay, we can talk afterwards if you want, let me show it to you. We are streaming all the talks on the internet, and we have people on the internet that would like to ask a question, so please a question from the internet. There were actually many questions in the direction of problems with the mind standards, so what they were asking was basically, wouldn't the expetration be prevented if the email clients would handle the standard correctly? Okay, so I'm not sure whether they meant the mind standards or the S-MIME standards, so basically the mind standards are the one to blame for the direct exhortation attacks, where you have multiple mind parts that are mixed together, and the mind standards don't state explicitly how to do this, so they don't have any rules of how to handle it, and basically I think as a rule of thumb, when you try to be concise and complete with implementing the mind standard, you were vulnerable, and if you were just lazy and just, for example, decrypted the first mind part or so, you were not vulnerable, so leaving out much of the stuff made you more secure, which is weird. Thank you for the answer. We have another question in this hall on microphone number six, and please remember to be concise and get close to the microphone. What do you see as a future replacement to PGP for email encryption? So actually we brainstorm a little, because PGP lacks many of the modern properties like forward secrecy and stuff like this, but it turns out that it's not very easy to do this, especially not with when you don't want to do changes to SMTP and IMAP, so it's going to be difficult, it's going to be difficult to make it more secure than PGP besides the criticism that I already brought in, so email is not a very good protocol, or the protocols that are built in email are not very good to build proper crypto on top of it. Thank you for this answer, so maybe we need to build something and turn you from scratch. There is another question on microphone number two, if I see this correctly. So do I understand it correctly? Looks like there won't be a fix for that multi-part attacks, like there's the normal plain text, the attacker writes, and then there is a server text which my mail client decrypts, there won't be a fix for that. There is a fix, so the mail clients are fixed, because that's a non-breaking fix, that's a good thing here, so you can fix SMIME for example, because it would be a breaking fix, but you could fix the email clients, which was a lot of work because MIME parsers are very complex, but they fixed it, so it's not supposed to work in current mail clients anymore, the direct acceptration part. So we still have quite some time left, and so I would like to have another question from the internet. Yes, so one user asks, would you recommend developers to get PGP into the email clients instead of using extensions? Yeah, I mean, I already talked about this, that not many people use PGP, and also not many people use SMIME. I'm not sure whether this will be increased when OpenPGP is built into most of the mail clients, because you could use SMIME, you know, as soon as SMIME is fixed, it will be fine to use SMIME, and it's already in all the clients in there, but not many people use it. So it would be nice if we could have it, but I'm not sure whether it would have much of an effect on the amount of people who use it. Thank you, and we have another question from microphone number seven. Yes, hello. So I work with journalists here, here, here, there, in the very back. There, there, hello, hello. So I work with journalists, and May was very annoying, and I cannot stress enough how important it is to what the point you've made about communicating around disclosure. We were scrambling. I work with about 200 journalists who use PGP daily, and we were scrambling for any bit of information. What should we do? It was madness. Yes. But I actually have a question. The question is, have you played with mail pile? I've read the, I've read the paper in, in the paper, mail pile, I think I remember was mentioned, and I vaguely remember it was mentioned in a positive light, but I just want to make sure if that's the right thing that I should get from this paper. I don't know it on the, on the top of my head, but if you come afterwards to, to Kau's West, we'll, we'll get out the paper and look at the tests, and then we can answer this question. Cool. Thank you. Okay, we have another question on the microphone number six. So I'd like to know if there's any difference in the attack surface regarding open, open PGP. If plain, like plain PGP is used or PGP mine? For example, if you, if you set your email client to disallow encryption of inline PGP. ID. Yeah, that's a very good question. I mean, the reply to attacker attack that I just showed at the last, the Q 53 people came up with a version that worked with inline PGP, and we showed that it's also possible with, with PGP mine. So I wouldn't say, I mean, most of the people use PGP mine, inline PGP is not used anymore. The problem is when you don't decrypt PGP, inline PGP, then you have a problem when people use PGP and an external application, they can't copy and paste the ciphertext in there anymore, which is also very annoying. And I also told you that it's, I think it's a very good idea to do this outside of the mail client if you're in a, in a, if you, if you face motivated attackers. So it's not that easy. It would be a breaking change that wouldn't maybe not be too good. Okay. Thanks. Okay. Thanks a lot for this answer. I think we are done with all the questions from the hall. If you'd like to continue the discussion with Sebastian Schinsel, you may move yourself to the assembly of Chaos West in the next hall in this direction. And now please give a big round of applause for Sebastian Schinsel and the awesome team behind.
same from the viewpoint of the attacks that I'm plaintext bytes. Because for our attack to work, e-fail-related changes to GNU-PG, so for example, thing as ASCII emails with most of the clients. one of the two vulnerable clients, and we just style of attacks, new e-fail attacks, and this guess. So what are the lessons learned from the HTML for encrypted emails, and this is like, not meant the mind standards or the S-MIME standards, OpenPGP is built into most of the mail clients,