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 Tomáš Sušanka all the way from the Czech Republic. So let's give it up for
Tomáš. Okay. Hi everyone. So yeah, my name is Tom and I will tell you something about Telegram
in the few other minutes. First of all, let me introduce myself. 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.
So I've recently graduated from the Czech Technical University in Prague. I've studied computer
security and cryptography. And I'm based in Prague, Czech Republic. However, I'm doing now
internship at Klaus.
Cloudflare in London, UK. I would like to stress out that the results I'm presenting
today are as part of my university studies. They are not connected to Cloudflare in any
way. However, Cloudflare supported me 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.
So after a short introduction, I will tell you something about Telegram. I will tell
you something about the Android app because that's what I've mostly focused on. And 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. Yeah, I have actually two
findings to share with you today.
So, as mentioned, first of all, let's introduce Telegram. So Telegram was launched in August
2013. So that's almost four years now. They have around 100 million active users, which
a lot with a large user base in Iran, about 20 million, even though those numbers are
from 2016. So might be higher as of today. And Telegram claims to be five, six, seven,
ten times larger than the average user base in Iran. It's about 17,000 users. And it's
make the latest version of their apps that could be even faster, better alternative
to, safer alternative to other solutions, such as WhatsApp, Signal, and other. And Telegram
has support for various clients. They are supporting pretty much everything. So that goes
Android, IOs, even Windows Phone, desktop, web. Pretty much everything. As I've mentioned, Telegram decided not to use any known cryptographic solutions,
but they decided to craft their own new homebrewing 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.
Only the clients are open sourced
so that means Android iOS and all the others
however the server side is not open sourced.
We focused on the version 3.13
which was as up to date in October 2016
and let me make a small note in here
on the picture you can see that
even though Telegram is open sourced
it's not really the open source maybe we are used to.
They pretty much just dump the whole code
like once or twice or three times a year on GitHub
so it's not really a structured commit.
That goes for the Android.
It may be better for the other clients.
So as you can see on the picture
this is actually a really continuous commit
so they had a commit in October
and then another one in March 2017
which was really convenient for us
because we 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 to have a look
into the MT-Proto.
So we have Alice and Bob
and first of all what they do
they negotiate a common master key.
We will label it as AUF key.
This negotiation is done using Diffie-Hellman
so there is nothing really that spectacular
or extraordinary.
It's regular Diffie-Hellman as you know
and after this key is negotiated
each both of their sides make a fingerprint of this key
which is I will describe how is that used in just a second.
But, so both of those sides make AUF key ID
which is a fingerprint of the master key.
So now this is the whole picture of the MT-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 service messages
such as message ID and so on and so on.
So Alice has a payload, she as well has AUF key
and let's have a look how it's done in MT-Proto.
So the payload is first hashed via SHA-1
and that yields message key.
This message key is later used for the integrity check.
The message key and the AUF key, the master secret
then serves as an input into the key derivation
function, this key derivation function makes a number
of truncations, hashes and so on
and it outputs two values
the AS key and the AS initialization vector.
This key and IV is then used for the actual IS encryption.
So the payload is padded and then it's encrypted.
Interestingly, Telegram used
IGE block cipher mode.
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
before that is the message key
which is used for the integrity
and before that the fingerprint of the master key.
So as I've mentioned 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 the context about Telegram?
One, okay.
Yeah, so it was around eight
and now then it was one.
So that like gives the picture.
Anyway, it's similar to CBC.
It just has two initialization vectors.
I wasn't unable to find
any other applications
that would actually use this.
It is implemented in OpenSSL
but as far as I know
it's only Telegram uses that.
Okay, so this was the first part.
Now we will have a look at the actually
analysis findings.
The findings from our analysis.
So yet again we started in October 2016.
And this is the first part.
And we finished about January 2017.
And we have two findings
that 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 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 just were sniffing the network
and I was expecting to see this fingerprint.
However, that was not the case.
I was expecting to see this kind of structure.
That means the fingerprint
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
we observed random data.
So we were thinking that
okay, maybe it's encrypted.
So after another month or so of pain
we actually found out that
the whole empty product output
is encrypted again.
So they take the whole
whole empty product output
so that's this thing, the whole thing
and they encrypt it again
using AS encounter mode.
They create the temporary key
they create the 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 log security
through 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 output.
So that was the first finding.
And after that we as well wanted to have a look
slightly into the code
which is written in Java
but has a significant part of logic in C.
And one of the things that we look into today
was how it deals with replay attack.
So let me briefly say what replay attack is.
So 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 a valid message
sends it again
and let's see how the message deals with that.
So now on the slide you can see
how Telegram deals with that.
So they basically check if a message ID is processed
and if it is not processed
it processes the message.
What is more important is the function that is below
which is add processed message ID
and what this function does
that the app has an internal array
of message IDs that it already processed.
However, this array had the size of 300 items
and 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 the 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 301st or later one
with the previously saved.
And so yet again we just took
we just took a later message
and I'm sorry
we've captured the message
then we waited for a while
till the other 300 messages are sent
and then we replaced it.
We actually checked how Telegram
because Telegram has like a security guidelines
which pretty much specify
how you should
if you decide to develop your own Telegram
client.
So this security guidelines tell you
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
the guideline actually states is
that if a message comes in with a message ID
which is lower
which is lower 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 was not in the array
if the message ID was not in the array
it simply 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 Telegrams
how Telegram responded
because we contacted them about
in around December 2016.
And they didn't really say much
about the obfuscation method.
They just basically said
that it has to do something with
attempts of banning their services
in certain countries
and that it's not related to data security
and they didn't really
they pretty much sent out one sentence
and that was it.
However about the replay attack
they took that pretty seriously.
They claimed and we verified
that you could not actually use
this replay attack for your actual messages
because there are some later checks
so it was not possible to do that.
However it affects some service messages
for example when somebody is texting you
and you see that the person is typing
so for this kind of messages
it could be used.
Also Telegram promised
that they're going to fix it
in the next release.
So Telegram promised
that they're going to fix it
in version 3.16
which was out in January 2017.
However as I mentioned earlier
we were not able to actually verify that
because at that time
because the code was published
at the end of March 2017.
So we were not able to verify it
for another two or three months.
However
now
finally at the end of March
they released the code
so we can have a look.
So yeah,
the fix was really simple.
They just added another value.
They pretty much put another variable
which is min processed message ID
which is the minimum value
of the lowest processed message ID.
And then they check
if that value that is now incoming
if the message ID that is now incoming
is lower.
Then that stored value
and if it is
that message is already processed
and it's discarded.
Yeah, so we're coming to the end.
I would like to say
a few more words about the disclosure
and the communication with Telegram.
So I was somewhat criticizing
a little bit Telegram time to time.
I would like to say one positive thing
that was the communication
with the Telegram team
was pretty professional.
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 attack
they really took it seriously.
They were answering in a reasonable timeframe
and so on.
They fixed it.
So just to end on a little bit more positive note.
And yeah,
during the analysis
we have written like two small tools.
One of them is a C program
which do obfuscate the 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
from your phone.
Which is like helpful
for another analysis and stuff.
Yeah, you can as well find
some more things on my blog
if you would be interested
in 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?
I expected from Telegram
some answer or some comment about it.
Maybe they just use obfuscation.
Yeah, yeah, like fair enough.
Yeah.
Yeah, one more.
So you were talking about how
they have this custom protocol
that's
.
So there's been a lot of commentary
about how they have this custom protocol
that is just basically weird, right?
It's non-standard and they just
they haven't offered a lot of rationale
for why they do things this way.
After you've kind of spent some time with it
what's your feeling about that?
You know, is the weirdness of it
hiding, you know, some other problems
we haven't noticed yet, maybe?
Yeah, I mean, I think
Yeah.
So I guess there are like two things.
So one of them, like if I recommend using Telegram
like over Signal and others
so that answer is no.
Like just use Signal.
And the other thing about the protocol
I think that's the whole problem with Telegram
that we cannot really point to some
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 overall
like idea is that the protocol
is just weird.
But unfortunately, you know,
I think you would actually have to spend
like a year of your life to maybe
be 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.
How big is that messenger ID
here with like how many bits?
...
We've checked that.
That should be okay, even if it overflows
and I think it was 2 byte.
Yeah. I'm not completely sure
I can check later but I think it was 2 byte.
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, 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.
Thank you.