 Alright everybody, let's kick this off. Thank you for being here at Crypto and Privacy Village. We have a fantastic talk right now. It is Security Analysis of the Telegram Instant Messenger app by Tomasz Sushanka all the way from the Czech Republic. So, let's give it up for Tomasz. Okay. Uh, hi everyone. Um, so yeah, my name is Tom and I will tell you something about Telegram in the few other minutes. Uh, first of all, let me introduce myself. Uh, I'm not really sure if the audience care who's presenting, but I always wanted to have a slide about me, so here you go. Um, so I've recently graduated from the Czech Technical University in Prague. Um, I've studied computer security and cryptography. And uh, I'm based in Prague, Czech Republic. However, I'm doing now internship at Cloudflare in London, UK. Um, I would like to stress out that the results I'm presenting today are, uh, as part of my university studies. They are not connected to Cloudflare in any way. However, Cloudflare supported me in, uh, in coming here, so I just would like to thank them for that. However yet again, this is as part of my university studies. That's why the slides are ugly. Um, so after a short introduction, uh, I will tell you something about Telegram. Uh, I will tell you something about the Android app because that's what I've mostly focused on. And, um, then we'll dive into the empty product, which is the Telegram's own cryptographic protocol. And then we will have a look into the actual analysis results. Uh, yeah, I have actually two findings to share with you today. So, as mentioned, first of all, let's introduce Telegram. So Telegram, uh, was launched in August 2013. Uh, so that's almost four years now. Um, they have around 100 million active users, which are a lot, with a large user base in Iran, about 20 millions, even though those numbers are from 2016, so might, might be higher as of today. And Telegram claims to be faster, better alternative to, safer alternative to other solutions, such, such as WhatsApp signal and other. Um, Telegram has support for various clients. Um, they're supporting pretty much everything. So that goes Android, uh, IOs, uh, even Windows phone, desktop, web, pretty much everything. As I've mentioned, uh, Telegram decided not to use any known cryptographic solutions, but they decided to craft their own new homebrew protocol, which is called MT Proto. I will introduce the MT Proto just in a second, but let me first introduce the Android app. So the Android app is fully open sourced, as all the other clients are. Uh, only the clients are open sourced. So that means Android IOs and all the others. However, the server side is not open sourced. Um, we focused on the version 3.13, which was as of today, uh, in October 2016. And let me make a small note in here. On the picture, you can see that even though Telegram is open source, it's not really the open source. Maybe we are used to, um, they pretty much just dumped the whole code like once or twice or three times a year on, on GitHub. So it's not really, you know, structured commit that goes for the Android app. It may, it may be better for the other clients. So as you can see on the picture, um, this is actually really continuous commit. So they had a commit in, you know, October and then another one in March, 2017, which was really convenient for us because we've started the analysis in October and we finished in February. So we could say for the whole time that we are up to date. Okay. So now we're getting into have a look into the empty proto protocol. So we have Alice and Bob and first of all, what they do, they, they negotiated, uh, a common master key. We will label it as Aufkey. They, this negotiation is done, uh, using Diffie Helman. So there's nothing really, um, that's spectacular or extraordinary. It's regular Diffie Helman as, as you know, and after this key is negotiated, each, both of the sides make a fingerprint of the, of this key, which is, I will describe how is that used in just a second. But so both of those sides make Aufkey ID, which is a fingerprint of the master key. So now this is the whole picture of the empty proto protocol. So on the top, we have a payload. This payload is the actual message, contains the actual message. So it can be high and it contains some other, uh, some other service, uh, messages such as message ID and so on and so on. So Alice has a payload. She as well has Aufkey and, uh, let's have a look how it's, uh, how it's done in empty proto. So the payload is first hashed via sha one. Yeah, sha one. And it, that yields message key. Um, this message key is later used for the integrity check. The message key and the Aufkey, the master secret, is then serves as an input into the key derivation function. This key derivation function makes a number of truncations, uh, hashes and so on. And it outputs two values, the AS key and the AS initialization vector. This key and IV is then used as a, uh, uh, is then used for the actual IS encryption. So the payload is padded and then it's encrypted. Uh, interestingly, telegram use IgE, block cipher mode. Uh, I will, we will have a look into that just in a second. And then the actual data that are sent are, you can see them at the bottom. That is the actually encrypted data, data before that is the message key, which is used for the integrity and before that the, the fingerprint of the master key. So as I've mentioned the, um, the block cipher mode. So the block cipher mode is IgE. Actually I would like to know who of you have heard about that? About IgE. Okay. So few, four, five, six. Okay. Who of you have heard about that? Not with a context about telegram? One. Okay. Yeah. So it was around eight and now then it was one. So that like gives the picture. Uh, anyway, it's similar to CBC. It just has two initialization vectors. Um, I, I wasn't unable to find any other applications that would actually use this. Uh, it is implemented in open SSL. But as far as I know, it's only, only telegram uses that. Okay. So this was the first part. Uh, now we will have a look at the actually analysis findings, the, the findings from our analysis. So yet again, we, we started in October 2016 and we finished about, uh, January 2017 and we have two findings that we, I would like to share with you. The first one is the undocumented obfuscation method. So when we started the analysis, I've basically, I, I, I had an Android app on my testing phone. I've installed telegram. I started to send some messages. And what I was expecting is, was to see the output that I just described like one minute ago. So that means I've extracted my master key. I've extracted the fingerprint of the master key from my testing phone. And I, I just were sniffing the, the network and I was expecting to see this fingerprint. However, that was not the case. Um, I was expecting to see this kind of structure. That means the, the fingerprint, then, then some kind of message key, then the encrypted data. But I was unable to find my own fingerprint of the key. We basically, at the first, we just, uh, we observed random data. So we were thinking that, okay, maybe it's encrypted. So after another month or so of pain, uh, we actually found out that, uh, the whole empty product output is encrypted again. Um, so they take the whole, whole empty product output. So that's this thing, the whole thing. And they encrypted again using AS in counter mode. Um, they create the temporary key. They create a temporary key and initialization vector and they put those values in front of the actually encrypted data. So this doesn't have to do really anything in security. It's just my look security free obscurity kind of thing. But this is what they're actually, what the Android app is actually sending. Okay. So temporary key, temporary IV, and then the actually encrypted data of the encrypted data because you know, it's the empty product. So that was the first finding. And after that, we as well wanted to have a look slightly into the code, um, which is written in Java, but has a significant part of logic in the C. And, um, one of the things that we look into today was how it deals with reply attack. So let me briefly say what reply attack is. So, uh, that's basically a very simple attack when you take some old, when you take some valid data and you send them again at a later time. So the attacker does not actually know the content, but it just takes older, it just takes a valid message, sends it again and let's see how the message deals with that. Um, so now on, on the slide, you can see, um, how telegrams deals with that. So they, they basically check if a message ID is processed. And if it is not processed, it processes the message. Um, what is more important is the function that is, uh, below, which is at processed message ID. And what this function does that the app has a internal array of message IDs that it already processed. However, this, this array had the size of 300 items and that, that was it. So what the Android app was doing that when it exceeded the 300 messages, which happens quite fast, they actually erased the first 100 and that's it. So we came up with a scenario where we would capture a message, then we would wait for another 300 messages, and then we would replace the next message, let's say the 300 and first or later one, uh, with the previously saved. And, uh, so yet again, we just took, took a, we just took a later message and, uh, uh, I'm sorry. Uh, we've captured the message, then we waited for a while till the other 300 messages are, uh, are sent and then, uh, we replaced it. Uh, we actually checked how telegram, because telegram has like a security guidelines, which, which pretty much specify how you should, uh, if you, if you decide to develop your own telegram client. So this security guidelines tell you, uh, the security guidelines tell you what you have to take care of, where you should be careful and so on. And one of the things that the guideline actually states is that if a message comes in with a message ID, which is lower, which is lower than, than all or equal to any of the stored values, that message is to be discarded. So this is actually what the Android app was not doing. The Android app was only looking if the message ID is in the array and if the message ID, it was not in the array. Uh, uh, if the message ID was not in the array, it simply, uh, uh, let it go through. However, it should not be doing that. It should check as well with the lower value. So let me now say a few words about the, the, the, the telegrams, how telegram responded because we contacted them about, uh, in around December, 2016. And they, they didn't really say much about the obfuscation method. They, they just basically said that it has to do something with, with, uh, attempts of banning their services in certain countries and that it's not related to the security and they didn't really, they, they pretty much send out one sentence and that was it. However, about the reply attack, uh, they took that pretty seriously. Um, the, the, they claimed and we verified that, uh, you could not actually use the, this reply attack for the actual messages because there is some, there are some, some later checks. So it was not possible to do that. However, it affects some like service messages. So for example, when somebody is like, you know, texting you and you see that the person is typing. So for this kind of messages, it could be used. Um, also telegram promised that they're gonna fix it in the next release. So telegram promised that they're gonna, uh, they gonna fix it in version 3.16, uh, which was out in January, in January, 2017. Um, however, as I mentioned earlier, they, we were not able to actually verify that because at that time, because the, the code was published on, sorry, uh, in, at the end of March, 2017. So we were not able to verify it for another two or three months. However, uh, now, uh, finally at the end of March, they, they released the code so we can have a look. Um, so yeah, the fix was really simple. They've just added another value. Uh, they pretty much put, uh, another variable which is min process message ID, which is the minimum value of, uh, of the, you know, of the lowest, uh, processed, uh, message ID. And then they, then they check, uh, if, if the, if that value that is now incoming, if the message ID that is now incoming is lower than that stored value. And if it is, that message is already processed, processed and it's discarded. Yeah. So we're coming to the end. Um, I would like to say a few more words about the disclosure and the communication with telegram. So I, I was somewhat, um, criticizing a little bit telegram time to time. Uh, I would like to say one positive thing that was the, the communication with the telegram team was quite, was pretty professional. Um, they took our remarks that well, they took the reply attack quite seriously. They didn't really talk about the obfuscation method, but about the, about the attack, they really took it seriously. Um, they were answering in a reasonable, reasonable timeframe and so on, then they fixed it. So just to end on a little bit more positive note. And yeah, um, during the analysis, we, we have written like two small, small tools. Uh, one of them is a, uh, is a C program, which the obfuscated traffic. So you can actually, you can see the actual, you can see the actual empty product, but not just the whole obfuscation thing. And another thing is just a simple extractor that will extract the keys, uh, from your phone. Um, the, which is like helpful for another analysis and stuff. Um, yeah, uh, you can as well find some more things on my, on my blog, if you would be interested in, in, to seeing more details. Yeah. And with that bombshell, that's all. Thank you. So I guess if there are some questions, so I repeat the question, what was wrong with the obfuscation part? Yeah, yeah, like fair enough. Yeah. Uh, yeah, one more. So there's, there's been a lot of commentary about how they have this custom protocol that is just basically weird, right? It's, it's non-standard and they just, they haven't offered a lot of rationale for why they do things this way. Um, after you've kind of spent some time with it, what's your, what's your feeling about that? Um, you know, is the, is the weirdness of it hiding, uh, you know, some other problems we haven't noticed yet, maybe? Yeah. Um, so I guess there are like two things. So one of them, like if I recommend using telegram, like over signal and other, so that the answer is no, like just use signal. And the other thing about the protocol, I think that's, that's the whole problem with telegram that we cannot really point to some, like, like, you know, really specifics and say, this is how we will crack it, you know, or this is how you will hack it. But like the overall, like, as you mentioned, like the whole, like, idea is that the protocol is just weird. But unfortunately, you know, I think you could, would actually have to spend like a year of your life to maybe be possible, like, you know, able to say, this is like, particularly where we can, like, hack it, actually hack it. I hope I answered that question at least a little bit. We've checked that. That should be okay, even if it overflows. And I think it was two bytes. Yeah. I'm not completely sure I can check later, but I think it was two bytes. There was one more question. Yeah, so it's my surname.eu. Yeah, the telegram app has a, has a, has internally stored RSA, RSA public keys. And the server then sends them, sorry, no, like the Diffie-Hellman parameters, they are like encrypted from the server. So the server then later sends them. I'm not exactly sure now how it, how it is, but we were looking into that and it was authenticated. Like, okay, so I guess that's it. Thank you for your attention. Yeah.