*33C3 preroll music*
Herald: Good morning everyone, thanks for showing up in such great numbers, that's
always a good thing for such an early session.
First of all I would like to ask you a question, I mean... or
let's start like that: Last night I had
a weird encounter with a locked door
out of the fate that we endured during this week we were out of our apartment
and the hotel owner let us stay in their office, but the guy who stayed there
put the dead lock on so we tried to reach him. Hmmm, how do you reach them?
We thought about maybe he has some messaging, maybe he has some mobile number,
no landline, landline, they have landline. It turned out that the guy
was not at the landline, out, exit, and
so we looked around in the bar. So this wouldn't have happened
if he had mobile messaging, so, to dive into that, if we could
just text him: "Hey, we are at the hotel, please open the door" we would have had
one hour more sleep tonight. So let's dive in
with, yeah, the talk of today.
So this morning session starts with our speakers Roland Schilling
and Frieder Steinmetz.
*applause*
And they will be talking about... they will at first give you a gentle
introduction into Mobile Messaging. I have nine messaging apps on my phone, no, ten!
The organizers forced me to install another messaging app.
And after that [they] give you a quick analysis, or not so quick, I don't know,
a deep analysis of the Threema protocol.
So let's give another round of applause for our speakers!
*applause*
Thank you, Thilo. I am Roland, this is Frieder, and
as, well, as Thilo already introduced us we are going to talk about
secure messaging. More specifically we are trying to give a very broad introduction
into the topic because we want to make the field that is somewhat complex available
to a more broad audience, so as to leave our expert bubble
and get the knowledge of technology that people use every day
to these people who are using it. To do that we have to start
at a very low level which might mean for the security and crypto nerds in the room
that you will see a lot of things that you already know. But bear with us, please,
since we are specifically trying, at least with the first part of the talk, to convey
a few of these mechanisms that drive encrypted messaging
to people who are new to the field. So what we are going
to try today is basically three things: We are... we will try to
outline privacy expectations when we communicate. We are going to do that
by sketching a communication scenario to you guys and identifying
what we can derive from that in expectations. We are going to find
an analogy, or look at an analogy that helps us map these expectations to mobile
messaging. And then we are going to look at specific solutions, technical solutions
that make it possible to make mobile messaging as secure, and give us the same
privacy guarantees that a one-to-one talk would, before, in the second part of the
talk we move on to look at a specific implementation, and it's no secret anymore
that we are going to look at the specific implementation of Threema. So let's just
dive right in. You are at a party, a party in a house
full of people and a friend approaches you wanting to have a private
conversation. Now what do you do? You ideally would find a place at this party
that is, well, private, and in our scenario you find a room, maybe the
bedroom of the host where nobody's in there, you enter the room, you close the
door behind you. Meaning you are now private, you have a one-on-one,
one-to-one session in this room in private. And we are going to look at
what that means.
First of all the most, the most intuitive one is what we call confidentiality and
that means that since nobody is there in the room with you you are absolutely sure
that anything you say and anything your communication partner says, if you imagine
Frieder and me having this conversation, can only be heard by the other person.
If that is guaranteed we say… we call this confidentiality because nobody who's
not intended to overhear any of the conversation will be able to.
The second part… no, the second
claim that we make is: if you guys know each other, and again,
if I had a talk with Frieder I know I've been knowing him for a long time,
more than five years now, I know what his face looks like, I know his voice,
I know that if I talk to him I actually talk to ‘him’, meaning I know exactly
who my communication partner is and the same thing goes vice versa,
so if this is achieved, if we can say I definitely know who I'm talking to,
there's no chance that somebody else switches in and poses off as Frieder
we call this ‘authenticity’. Moving on. Integrity.
Integrity is a bit… this is where the analogy falls short,
well, somewhat. But, basically, if I can make sure that everything I say
reaches Frieder exactly the way I wanted to say it and there is no messenger
in between, I'm not telling a third friend "Please tell Frieder something" and
he will then alter the message because he remembered it wrong or
has malicious intentions. If I can make sure that everything I say
is received by Frieder exactly the way I said it then we have ‘integrity’
on our communication channel. Okay. The next ones are two ones
that are bit hard to grasp at first. Therefore we are going to take a few
minutes to look at these, and they are ‘forward and future secrecy’. Suppose
somebody entered the room while we had our talk and that person would stay a while
overhear some portion of our talk and then they would leave the room again. Now
if they, if at the point where they entered the room they
wouldn't learn anything about the conversation that we had before, which is
intuitive in this scenario which, that's why we chose it, they enter the room, and
everything that can overhear is only the portion of the talk that takes place while
they are in the room, they don't learn anything about what we said before,
meaning we have what we call forward security, we'll get back to that, and
after they left they wouldn't be able to overhear anything, anything more that we
say. This is what we call future security. Because those are a bit hard to understand
we have made a graphic here. And we are going to get back to this graphic when we
translate this so I'm going to take a minute to introduce it. We have a time
line that is blue, goes from left to right, and on this time line we have green
bar that denotes our secret on our secret conversation. The first pink bar there is
when the third person enters the room, then our secret conversation turns orange
because it's no longer secret, it's now overheard by the third person and after
they left they wouldn't know anything that was said after that. So the left part of
it meaning the fact that they can't hear anything into the past is what we call
forward security and if they can't learn anything after they left we call it future
secure, future secrecy, sorry. Okay, the last one that we're going to talk about
since we're trying to keep things simple is deniability. Since we are only two
people in the room and there are no witnesses we achieve deniability because
after we had this talk we returned to the party and people asked us what happened,
um, I can always point to Frieder as you could to your friend and say he said
something. Frieder could always say, no I didn't, and it would be my word against
his and if this is, you know, if our scenario allows for this we have
deniability because every one of us can always deny having said or not having said
something. And now we are going to look at messaging.
Now in messaging a third player comes into the room and this could be your provider
if we talk about text messaging like short messages that we used to send in the 90s,
it could be your messaging provider if you use something more sophisticated, it could
be WhatsApp for example could be Apple depending on what your favorite messenger
is but there is always, unless you use, like, federated systems, if some some of
you guys might think but I'm using Jabber I know but we are looking at centralized
systems right now and in these there will always be one third party that all
messages go through, whether you want it or not. And whether you're aware of it or
not. And this brings us to our second analogy which is Postal Services now while
messaging feels like you have a private conversation with the other person and I
think everyone can relate to that you have your phone you see you are
displayed with the conversation and it looks like only you and this other person,
in my case Frida, are having this conversation we feel like we have a
private conversation, while actually our messages go through a service provider all
the time. Meaning we are now looking something at something more akin to postal
services. We prepare a message send it off, our message provider takes the
message, takes a to our intended recipient, and they can then read the
message. And this is this this applies to all the messages we exchange. And to
underline that we're going to look at what I initially called traditional messaging
meaning text messaging, unencrypted SMS messaging, and as you may or may not be
aware of these messages also go through our providers: more than one provider
even. Say I'm at Vodafone and Frieder is with Verizon, I don't know, I would send
my messages to Vodaphone, they would forward them to Verizon who would then
deliver it to Frieders phone. So since both of our providers would know all the
messages; they are unencrypted; we would have no confidentiality.
They could change the messages and these things have happened actually. So we
don't have any integrity we don't know if the messages received are actually the
ones that were sent. We also have no authentication because phone numbers are
very weak for authenticating people, they are managed by our providers they don't
they are not fixed that there's no fixed mapping to our phones or our SIM cards.
They can be changed they can be rerouted so we don't we never know if the messages
we send are actually received by the people we intended to: no authenticity and
no authentication. Now forward secrecy and future secrecy don't even apply because we
have no secrecy. We do have some sort of deniability but this goes into like
philosophically.. Let's do that again: philosophical claims of whether when I say
I haven't sent anything this must have been the provider they can technically,
you know, guarantee they did or did not do something. So let's not dive too deeply
into that discussion, but we can summarize that messaging translates, at least
traditional messaging, translates very badly to our privacy expectations when we
think of a communication. Okay, moving on. Looking at our postal analogy, actually
our messages are more like postcards. Because they are plain, our providers can
look at them, can change them, you know all the things we've just described: just
as they would a postcard. They can see the intended recipient, they can look at the
sender, they can look at the tags, change it: postcards. And what we want to achieve
now is find a way to wrap these postcards and make them more like letters, assuming
that postal services don't open letters. That's the one the one point with this
analogy that we have to like, define. And to be able to do that we're going to we're
trying to give you the shortest encryption to – the shortest introduction to
encryption, see I'm confusing myself here, that you will ever get. Starting with
symmetric encryption. Now, encryption, for those of you who
don't know, is what we call the translation of plain, readable text into
text that looks like it's random, but it can be reversed and turned back into plain
text provided we have the right key for that. So to stick with a very simple
example please imagine this box that we've just labeled crypto, and we are not
concerned with what's in the box we just imagine it as a machine. Please imagine it
as a machine that takes two inputs the plaintext and the key, and it produces
something that we call ciphertext. The ciphertext is undistinguishable from
random text, but it can be reversed at the recipient side using the same key and
basically the same machine just doing the operation, you know, in reverse: turning
the ciphertext back into plain text. This is what we call, sorry, this is what we
call symmetric encryption because if you imagine a line where the cipher text is
you could basically mirror the thing on to the other side so it's symmetric at that
at that line. And when when there's something that is called symmetric there
is also something that is called asymmetric and asymmetric encryption works
relatively the same way, only there are now two keys. We have made them a yellow
one and a blue one. These keys are called a key pair. They are mathematically
linked. And the way this works now is that anything encrypted with one of these keys
can only be decrypted with the other one. You can do it both ways, but the important
thing to memorize here is just anything I encrypt with the yellow key can only be
decrypted with the blue key. Okay, since we have that now, let's capitalize on this
on this scenario. Imagine each of our communication partners now has one of
these two keys and we are still talking about the same key pair that we've
outlined on the previous slide. Now we call one of them a secret key and one of
them a public key. This is probably known to most of you: traditional public key
cryptography. We've added something that is called an
identity in this in this picture: we will get back
to that in a minute. But the scenario we want we want you to envision right now is
that both parties would publish their public key to the public. And we are going
to get back to what that means as well. And keep their secret key, as the name
says, secret. Some of you might know this as a private key: it's the same the same
concept applies. We just chose to call it secret key. Because it more clearly
denotes that it's actually secret and not never published. So this would mean any
message that would that would be encrypted with one of the parties public key could
then only be decrypted with that parties secret key, putting us in a position where
I could take Frieta's public key, encrypt my message, send it to him, and I would
know that he would be the only one able to decrypt the message - as long as his
secret key remains his, well, secret. And he doesn't doesn't publish it. Well
the problem is: it's a very expensive scenario. We get something akin to a
postal to a postal service where we can now encrypt the message and envision it
like putting a plain sheet of paper into an envelope, seal it, we would put it on
the way. Nobody on the line would be able to look into the letter. They would of
course, well, since there are addresses on there, they would see who it is from and
who it to - but they couldn't look inside the letter: this is achieved. But as I've
already said it's a very expensive mechanism and by that we mean it is hard
to do for devices - especially since you are doing mobile messaging on your phones,
ideally, especially hard to do on on small devices like phones. So while if we had a
mechanism that would allow us to combine symmetric and asymmetric encryption. And
it turns out we do. And we are going to keep this very simple by just looking at
what is called key establishment, and then again also just one particular way of key
establishment. We have two new boxes here: they are called key generators. And the
scheme that we are
looking at right now works works the following way: You can take one of the
secret keys, and another part and another public key, like the one of the other
party, put them into the key generator. And remember, these keys are
mathematically linked each secret key belongs to exactly one public key. And the
way this key generator works is that through this mathematical this
mathematical linking it doesn't matter if you take, in this case, let's call them
Alice and Bob: if you take Alice's secret key and Bob public key, or Bob secret key
and Alice's public key, you will always come up with the same key. And we call
this a shared key. Because this key can now be it can be generated independently
on both sides and it can then be used for symmetric encryption, and as we've already
told you symmetric encryption is a lot cheaper than asymmetric encryption. So
this has one advantage and one disadvantage: the advantages I've already
said is that it's way cheaper, and the fact, well, the advantage is also that we
come up with the key on both sides, and the disadvantage is that we come up with
one key on both sides - because whether or not you've realized this by now since this
is a very static scheme we always come up with the same key. That is going to be a
problem in a minute. So let's recap we have looked at asymmetric encryption which
as I've said gives us IDs, and we're going to look at what means. But it is very
expensive. We know that symmetric encryption is cheap, but we have to find a
way to get this key delivered to both parties before they can even start
encrypting their communication. And we have looked at key establishment, which
allows us which gives us symmetric keys based on asymmetric key pairs. Meaning we
have now basically achieved confidentiality - we can use these keys
put them in the machines with our plaintext, get ciphertext, can, you know,
we are able to transport it to the other side. Nobody can look inside.
Confidentiality is achieved. Now deniability. Deniability in this
scenario would basically mean, if you think back at our initial sketch, where we
could say I haven't said that, and the other guy couldn't prove that we did,
would in this case be a letter that was sent to both of the participants, and it
would be from either of the participants. So that when looking at this
cryptographically, we couldn't say this was sent by me or this was sent by Frieda.
You could just see it was sent by, well, either of us. And if you think of the
scheme that we've just sketched, since both parties come up with the same key by
using different by using a different set of keys to to generate them, basically the
same key can be generated on both sides. And you can never really say, by just
looking at a message, if it was encrypted with a shared key generated on one or on
the other side since they are the same. So, very simply and on a very high level
we have now achieved deniability. What about forward and future secrecy? You
remember this picture? Our overheard conversation on the party that we were at
at the beginning of the talk? Well, this picture now changes to this. And what we
are looking at now is something we call key compromise and key renegotiation. Key
compromise would be the scenario where one of our keys were lost. And we are talking
about the shared key that we generated now. Which, if it would fall into the
hands of an attacker, this attacker would be able to decrypt our messages because
it's the same key that we used for that. Now, if if if at the point where the key
was compromised they wouldn't be able to decrypt anything prior to that point - we
would have forward secrecy. And if we had a way to renegotiate keys, and they would
be different ,completely different, not linked to the ones we had before, and then
use that in the future, we would have future secrecy. But we don't, since as
we've already said the keys that we generate are always the same. And we want
you to keep this in mind because we will get
back to this when we look at Threema in more detail.
yeah, if we had a way to dump keys after having used them, we could achieve forward
and future secrecy. Since we don't, we can't right now. Okay, next recap our key
establishment protocol gives us confidentiality, deniability, and
authenticity. We don't have forward and future secrecy. And if you've stuck with
us you would realize we are omitting integrity here - that is because we don't
want to introduce a new concept right now but we will get back to that, and you will
see that when we look at Threema it actually does have integrity. Now,
basically you could think we fixed all the-- well, we fixed everything, but you
heard us talk about things like IDs, and we said we haven't really lost a few words
about them lost many words about them and we're going to look at that now. And we
are going to start with a quote by my very own professor - don't worry you don't have
to read that, I'm going to do it for you. My professor says, "cryptography is
rarely, if ever, the solution to a security problem. Cryptography is a
translation mechanism, usually converting a communications security problem into a
key management problem." And if you think of it, this is exactly what we have now,
because I know that Frieder has a private key, a secret key I'm sorry, and a public
key. He knows that I have a secret key and a public key. How does I know which one of
those public keys that are in the open is actually his? How would I communicate to
him what my public key is? Those of you who've used PGP for example and then the
couple in the last couple of decades know what I'm talking about. And we have the
same problem everywhere where public key cryptography is used, so we also have the
same problem in mobile messaging. To the rescue comes our messaging server -
because, since we have a central instance inbetween us, we can now query this
instance: I can now tell my public key; I can now take my public key and my identity,
tell the messaging server, " Hey messaging server - this is my
identity. Please store it for me." So that Frieda, who has
some well some kind of information to identify me can then query, you, get my
public key back. This of course assumes that we trust the message messaging
server. We may or may not do that. But for now we have a way to at least communicate
our our public keys to other parties. Now what can we use as identities here? In
our, like, now a figure here it's very simple: Alice just goes to the messaging
server and says, "Hey, what's the public key for Bob?" And the messaging server
magically knows who Bob is, and what his public key is. And the same thing where I
work works the other way. What would; the question now is what is a good ID in this
scenario. Remember we are on phones, so we could think of using phone numbers, we
could think of using email addresses, we could think of something else. And
something else will be the interesting part, but let's look at the other parts
one by one. Phone numbers can identify users - you
remember that you rely on your providers for the mapping between phone numbers and
SIM cards, so you have to trust another instance in this situation. We're going to
ignore that completely because we find that phone numbers are personal
information, and I for one my phone number. And I mean the same phone number
I've had it for like 18 years now. I wouldn't want that to get into the wrong
hands. And by using it to identify me as a person, or, you know, my cryptographic
identity that is bound to my to my keys: I wouldn't necessarily want to use that,
because I wouldn't be able to change it or I would want to change it if it ever got
compromised. Now something else comes to mind: e-mail addresses. E-mail addresses
basically are also personal information. They are a bit shorter lived, as we would
argue, than phone numbers. But, and you can use temporary e-mails, you can do a
lot more you are way more flexible with e-mails. But ideally we want to have
something that is that we call dedicated IDs, meanings something that identifies me
only within the bounds of the service that we use.
So that's what we want to have we are going to show you how this might work but
we still have to find a way to verify ownership, because this is a scenario that
is more or less likely to happen. I am presented with a number of public keys to
an identity that I know - and I have to verify a way to, well, I have to find a
way to verify which one is maybe the right one, maybe the one that is actually used,
maybe Frieda has used quite a number of public keys - he's a lazy guy. He forgets
to, you know, take his keys from one machine to the other: he just, you know,
buys a new laptop sets up a new public key: bam, he has two - which one am I
supposed to read to use right now. Now remember that we are looking at the
messenger server for, you know, key brokerage, and we are now going to add a
third line here and that is this one. Basically we introduce a way to meet in
person, and again PGP veterans will know what I'm talking about, and verify our
keys independently. We've chosen QR codes here - free mail uses QR codes, many other
messengers and do as well, and we want to like tell you why this is an important
feature to be able to to verify our public keys independently of the messaging
server. Because once we did that we no longer have to trust the messaging server
to tell us or - we don't have longer we no longer have to trust his promise that this
is actually the key we are looking for. We have verified that independently. Okay, we
have basically solved our authenticity problem. We know that we can identify
users by phone numbers and emails, and you remember our queries to the server for
Bob: we can still use phone numbers for that if we want to. We can use emails for
that if we want to. We don't have to. We can use our ids anonymously. But we have a way
to verify them independently. The remaining problem is users changing their
IDs - that is where we have to verify again. And we also get back to that later,
but I want to look at something else first, and that is the handling of
metadata. Now, we know that an attacker can no
longer look inside our messages. They can, however, still see the addressee, who the
message is from, and they can see how large the message is, they can see they
can look at timestamps and stuff like that. And since we are getting a bit tight
on the clock I'm going to try to accelerate this a bit. Metadata handling:
we want to conceal now who a message is from, who a message is to. And we are
doing this by taking the envelope that we've just generated, wrapping it into a
third envelope, and then sending that to the messenger server first. And the
messenger server gets a lot of envelopes. They are all just addressed to the
messenger server, so anyone on the network would basically see there's there's one
party sending a lot of messages to the messenger server; maybe there are a lot of
parties. But they couldn't look at they couldn't look at the end-to-end, we call a
channel, that's seeing what the address is on each internal envelope are. The
messaging server, however, can. They would open the other-- the outer envelope, look
at the inside, see , "Okay this is a message directed at Alice," wrap it into
another envelope - that would just say, "This is the message from the messaging
server and it is directed to Alice." Who would then be able to, you know, open the
outer envelope, open the inner envelope, see this is actually a message from Bob.
And what we have thereby achieved is a to where two layer end to end communication
tunnel as we call it, where the purple and the blue bar are encrypted channels
between both communication partners and the messaging server, and they carry an
encrypted tunnel between both partners, you know, both communication partners,
directly. But, and we've had this caveat before, the messaging server still knows
both communication partners, they still know the times that the messages were
sent. And they also know the size of the message. But we can do something against
that. And we what we do is introduce padding - meaning,
in the inner envelope we just stick a bunch of extra
pages so the envelope looks a bit thicker. And we do that by just appending random
information to the actual message before we encrypt it. So anything looking at the
encrypted message would just see a large message. And, of course, that should be
random information every time - it should have should never have the same length
twice. But if we can achieve that, we can at least conceal the size of the message.
Now so much for our gentle introduction to mobile messaging. And for those those of
you stuck around, we are now moving on to analyze Threema. Now I want to say a few
things before we do that - we are not affiliated with Threema, we don't, we are
not here to recommend that the the app to you or the service. We didn't do any kind
of formal analysis. There will be no guarantees. We will not be quoted with
saying, "use it or don't use it." What we want to do is make more people aware of
the mechanisms that are in use and we have chosen basically a random message provider
- we could have chosen anyone. We chose Threema for the fact that they do offer
dedicated IDs. That they don't bind keys to phone numbers, which many messengers
do. Those of you who use WhatsApp know what I'm talking about. And well, since it
is closed source we found it interesting to look at what is actually happening inside
the app and make that publicly aware. Now we are not the only ones we've done this,
we are also not the first ones who've done this, and we don't claim we are. But we
are here now and we want to try to make you aware of the inner workings of the app
as far as we have understood it. And with that I hand the presenter over to Frieda.
*Applause*
Frieda: So I'll be presenting to you our
understanding of the Threema protocol and how the application works as we deduced
from mostly reverse engineering the Android app. And so this won't be a
complete picture, but it will it will be a picture presenting to you the most
essential features and how the protocol works. And I'll start by giving you a
bird's eye look at the overall architecture and why Roland was giving you
this abstract introduction to mobile messaging, there was also always this
third party - this messaging provider. And this now became actually three
entities because Threema has three different servers, mostly, doing well,
very different stuff for for the apps working. And I'll start with the directory
server in orange at the bottom, because that is the server you most likely will be
contacted contacting first if you want to engage in any conversation with someone
you never talked to before. Because this is the server that handles all the
identity public key related stuff that Roland was talking about so much. This is
the server you'll be querying for whose public key - I have this Threema ID,
what's the corresponding public key, for example stuff like that. Above that there
is the messaging server, which is kind of the core central entity in this this whole
scenario because it's task is relaying messages from one communication partner to
another. And above that we have the media server, and I'll be talking about that
later. In short, its its task, its purpose, is storing large media files like
images and videos you send to your communication partners. But as I said I
want to start with the directory server, and in the case of Threema, this directory
server is offers a REST API so communication with this server happens
via HTTP. It is HTTPS actually so it's TLS encrypted. And this encryption is also
fulfills all the requirements you would have to to to a proper TLS connection and,
so, if you if you want to communicate with the new person and you have
their phone number or
the email address or Threema ID. You'll be asking your app will be asking the
directory server, "Hey, I have this phone number, do you have a corresponding
Threema account and public key." And the response will hopefully be, "Yes, I do -
that's a public key that's the Threema ID: go ahead."
And as Ron said we kind of chose Threema for the arbitrary use of IDs and
especially for the system of verifying fingerprints in person by scanning QR
codes and because this is something Threema has and other messengers do not
have I want to talk a little bit about that, because if you just ask the
directory server "hey I have a threema ID what is the corresponding public key?" the
threema location will say "ok I got an answer from from the directory server I
have a public key but I have very little trust, that you actually know who the real
person behind this threema account is, we're not quite sure about that", so it'll
mark this contact with one red dot and if you had a phone number or an email address
and asked the directory server, "hey what's the corresponding threema account
and public key?" the app will say, "ok we still have to trust the directory server,
but we're a little bit more confident that the person on the other hand is actually
who you think they are because you have a phone number probably linked to a real
person and you have a better idea who you're talking to but still we rely on the
threema server", so it'll knock a contact like that with two orange dots and then
there is the final stage if you met someone in person and scan their, their
public key and threema ID in form of a QR code such a contact will be marked with
three green dots and in that case the app says "We're 100% confident we're talking
to the person we want to talk to and we have the proper keys." So right now we're
at if we think of engaging a conversation, we were at the point where we do have all
necessary details to start encrypting our communication, but question remains, how
do we encrypt our communication, in case of threema.
Threema uses a library called salt has been developed by Daniel Bernstein and he
called it salt but it's spelled NaCl so I'm sorry for for the play on words, but
if you see NaCl its salt so this is a library specifically designed for the
encryption of messages and it's supposed to be very
simple in use and give us all the the necessary features we wanted and this is
Salt's authenticated encryption giving us all the features Roland was talking about
in abstract before. It gives us integrity, it gives us authenticity, it gives us
confidentiality and just a quick look and on how this this library would be used is,
as you can see up there like everything in the grey box is, what the library does and
we only need our secret key, if we want to encrypt something to someone, the
recipients public key, our message. So far very obvious and the library also requires
a nonce, which is something that should be only used once, that's actually yeah part
of the definition, so we generate something random and include that in the
process of encrypting the message this is just so that if we encrypt the same
content same message twice, we do not get the same ciphertext. This is not nothing
secret because as you can see at the output the library actually gives us
ciphertext, Roland talked a bit about that what it is and it'll also give you it was
a MAC and I'll just stick with a very simple definition of what that is, it is
something that ensures that there's kind of a checksum so someone getting looking
at the cipher text and the MAC can ensure no one tampered with the cipher text so
the cipher text is still in the state when it was, when we sent it and if we want to
transmit our message now in encrypted form to someone, we have to include the nonce,
the nonce is not secret, we can just send it along with the cipher text, but to
decrypt we need the nonce and well so this is what we might use for encryption, but
as you might remember from Roland's introduction, this scheme
does not offer us any forward or future secrecy and we can still try to to add
some form of forward to future secrecy to this scheme and this is usually done,
sorry for skipping with a, with something something called a handshake and
handshakes are a system of discarding old keys and agreeing agreeing a new keys,
this is usually what we do with the handshake and scenarios like this and
doing a handshake with someone that is not online at the moment is pretty difficult
there are protocols to do that; the signal messaging for app, app for example does
something like that but it's kind of complicated and threema's protocol spares
the effort and only does this kind of handshake with the Threema servers because
they are always online, we can always do a handshake with them, so Threema has some
form of forward secrecy on this connection to the messaging server and how this is
achieved, I'll try to present to you right now and we walk through this handshake
step by step and I try to put some focus on what every step tries to achieve, so if
we initiate a connection, if we start sending a message the threema app will
connect to the to the messaging server and start the connection by sending a client
hello, this is a very simple packet. It is only there to communicate the public key
we from now on intend to use and a nonce prefix in this case
notice it is I'd say half a nonce and the other part is some some kind of a counter
that will during the ongoing communication always be increased by one. So but it'll
do no harm if you just see it as a nonce right now, so we start the conversation by
saying "hey, we want to use a new key pair from now on and this is our public key,
please take note" and the server will react by saying "okay, I need a fresh key
pair as well then", generate a fresh key pair and let us know what it's public key
from now on is. The only thing to note is, I mean as you can see there is, there's
not much more than then the things the client sent
corresponding things from the server side, but there's also the client nonce
included, so so as we can we can see this is actually a response to our client hello
we just sent, not something that got, I don't know redirected to us on accident,
whatever. And as you can see the latter part of the message including the server's
public key is encrypted that's what what this bracket saying ciphertext says and it
is encrypted with the server's long-term secret key and our ephemeral temporary key
and by doing so, the server does something only the person in possession of the
service long-term secret key can do and proves to us, this public key we just
received from the server, in this server "hello", has actually been been sent by
the proper threema server, no one can impersonate the threema server at that
point, so, after that we are at a point where the client application knows, this
is the public key threema server wants to use and it's actually the threema server,
not someone impersonating it, the server know was there is someone who wants to
talk to me using this public key, but knows nothing else it doesn't know who's
actually talking to him and this is going to change with the next packet, because
the threema app is going to, to now send a client authentication packet, we call it
that way, which includes information about the client, the first thing is the threema
ID , the threema IDs are eight character strings, it's just uppercase letters and
numbers and what follows is a user agent string which is not technically necessary
for the protocol, it's something the threema app sends, it includes the threema
version, your system; Android iOS and your, in case of Android, the Android
version and stuff like that so it's very similar to user agent in web browsers,
yeah. I don't know why they sent it, but they do and the rest of it is nonces.
Let's get skip over them, but also the client's ephemeral public key we already
sent in the client hello but this time encrypted
with our long-term secret key, so we just repeat what the server just did, proving
by encrypting with our long-term key, proving that we are, who we claim to be
and that we vouch that we really want to use this, this temporal key and after that
happens each party knows, what public key what new keypair the other party wants to
use from now on and that the other party is actually who they claim to be and so
the handshake is just concluded by the server
sending a bunch of zeros and grouped encrypted with the newly exchanged key
pairs. This is just so the client can decrypt it, see it as a bunch of zeros,
everything worked out, we have a working connection now so if we've done that we
have this, we have, if you remember this picture, we have established forward
secrecy in the paths between the app and the server we do not have established
anything for the inner crypto layer, which is in case of threema, just taking
messages encrypting them with the salt library and sending them over the wire.
There's nothing more to it, it's just as I showed you the scheme before, used in a
very simple way so we now have channels established and we can communicate via
those and the next step I want to look at, what we are actually sending via this
channels and so I'm introducing the threema packet format and this is the
format packets do have, that your application sends to the threema service,
this is what if what the threema server sees, in this case it is the form a packet
has if it's something I want to send to a communication partner, for example, the
content could be a text message I want to send to someone.
There are different looking messages for, for management purposes, for exchanges
with the server, that will never be relayed to someone else, but this is the
the most basic format we use when sending images, text to, to communication parts
and as you can see there's a packet type, its purpose is kind of obvious and what
follows is the fields on the envelope as Roland introduced, it's saying "this is a
message from me" from Alice to Bob and so you recall the
server can see that, what follows is a message ID this is just a random ID
generated when sending a message, follows a timestamp so the server knows this is a
recent message that has been stuck in transit for a long time, whatever.
What follows is some things to threema specific, threema does have public
nicknames, it's just an alias for, for your account you can set that in the app
and if you do it actually gets transmitted with every message you send, so if you
change it, your name will change at your communication partners phone with the
first message you sent to them and what follows is a nonce and that is the nonce
used to encrypt the cypher text as follows, the cypher text you see down
below is the inner envelope, as in Roland's earlier pictures and we're now
going to look at what is in this envelope, how do the messages look we transmitted to
our end-to-end communication partners and the most simple thing we could look at is
a text message and you can see grayed out above, still all the stuff from the outer
envelope and down below it's very simple, we have a message type it's just one byte
indicating in this case that it is a text message and what follows is text.
It's nothing more, it's just plain plain text and after that, noteworthy maybe is
padding and this padding is as you can see in the most inner encryption layer so the
threema server does not know how big your your actual messages are, this is kind of
useful because there's stuff like typing notifications you send to your
communication partners, which are always the same size and to make this, to hide
this from the threema servers, we have this padding in the inner crypto layer.
Next I want to look at a other message type, like I'd say the most, yeah, I think
one of the basic message types most people use with instant messaging app is image
messages, I want to send someone an image, this is something we do regularly and this
looks a little bit weird in the first on the first look; because it has a message
type, we know that, we know what what it's burst with the purposes follows a blob
ID, what a blob ID is, I'm going to explain in a minute. Follows the size is
very basic, it's just the size of the image just should be transmitted and what
follows is a key and the mandatory padding, so, the questions are, what is
this blob ID what is the key ID and what is this key and this is where the media
server comes into the picture. The media server is, well I'll show you what happens
if you send an image message. Your app will take the image you want to send,
generate a random key, encrypt this image with this key and send it to the media
server and the media server will say "okay I'll store this under the following blob
ID" and your app takes note of this blob ID and then, we'll send this kind of image
message I just showed to you to the messaging server via the messaging server
to your communication partner, your communication partner opens up the message
looks at it sees a blob ID sees the key and goes to the media server and says "hey
do you have a blob ID, something stored under this blob ID?" and the media server
will respond "yes I do, here's the encrypted stuff" and your communication partner
can take this encrypted stuff, decrypt it with the key you sent and look at your image.
This is how image sending works. So right now we do have the basic the basics of
modern instant messaging, we can send text, we can send images, this is the
simple stuff and what I want to look at next is something that most people would
want a modern messenger to have as well and that is group conversations.
Group conversations essentially in threema do work not very different from other from
other method messages because if you send something to a group your app will just
encrypt the message several times for every communication partner involved and
send it to them, but your communication partners need to know, well this is a
group message and it belongs to this and that group and to do so threema has group
packets and they include exactly that information, they include a creator ID
which is the threema ID of the person who created the group and a group ID which is
something randomly generated when creating a group and after that folIows a regular
packet format; in this case a text message, if it were an image message you would see
exactly the same stuff as shown in the Image message before so this is how group
messages look, but we need a way to introduce new groups to change names and
for that there are special packets and this for example is a group "set members
message", which tells everybody there is this new group and it has the following
members as you can see here there is only a group ID, there is no longer a
group creator ID included and that is because a threema group management
is very static, there can only be one person managing a group and that is the person
who created the group. So only the person who created the group can send this kind
of messages, saying there is a new member in the group for example and therefore the
group creator is implicit in this case, it is the sender of the message, so this is
kind of annoying because you cannot have a group where everybody can have members for
example and stuff like that. Just if you set a name for a group, the message looks
very similar it just doesn't include a member list, but a name field. So, what I
want to talk about next is something that happens above all the stuff I talked
about right now, because now I show you there are different kinds of packets doing
all that stuff, there there are lots of more packages for all your messages for
example they look very similar to the image messages, because they just I mean
we have a blob ID for the audio file and stuff like that but what is kind of
interesting I thought, we thought, is that above this layer of packet formats,
there's, there's also some additional stuff happening and a good example for that is
how Threema handles subtitles for images, you can I think a lot of modern messengers
support that at some some kind of text to an image and Threema doesn't have a packet
format of a field in some kind of image message for that, but they just embed the
subtitle of the image, in the actual image and the acts of data of the image and send
it along. This has the advantage of being compatible with Threema versions not aware
of this feature, because they can just happily ignore this exif data, you won't
see the subtitle but it won't break anything. It is though kind of wonky because
it's not actually a feature which is not reflected in the actual packet format and
this is also very similar happening with quotes, you can quote other people in
Threema you can like, mark your message and say I want to quote that and in the
app it looks like like some kind of fixed feature, yeah, you have this message you
quoted, included in your new message and it looks like like it's somehow linked to
the old message, but in reality it's just a text message, including some markdown,
which if you're Threema version supports this this kind of stuff, is rendered
nicely as is shown below, but if your version doesn't support it, you'll just
see the plain text. So again, being compatible with versions
that don't have it introduces some, yeah, weird layer. And with that, I'll stop
showing you all the features Threema has. There's certainly more to talk about, but
I think you should have an idea how how it works in basic terms. What it does; all
the other stuff is kind of similar to what I showed you and differs in
particularities which aren't so important I think and I'll just hand over to Roland
who'll be wrapping up our talk and say something about the results of our reverse
engineering.
*Applause*
Roland: Okay, we told you we reversed the app and we told you we weren't the first
ones and this is all true. But we came here to tell you guys or to make you guys
aware of things you can expect from messaging apps, and we hope that by using
Threema as an example we have we have shown you how you can relate your own
privacy expectations to different apps and we also hope we gave you enough
terminology and explanation to that so you can make a more more competent decision
next time you look at a messenger and look at what its promises are. Since we
reversed it anyway and we did a lot of coding to do that what we did is put it in
a library. Now, I don't know how many of you guys know the term academic code
*Laughter* We are of course we are of course I'm
working at a university, so we've been doing this on and off for for quite some
time. We started roughly two years ago, did it for a couple of days then left it
lying around. Eventually we had the whole thing lying in a drawer for about a year
before we decided to finish it so we we didn't we never actually put a lot of
effort into the code. We are not proficient programmers. But we still
wanted to we still wanted to publish what we did with the hopes that a small
community might form around this, maybe extend it, help us you know fix the few
things that we didn't do so well, help us document it - you don't have to take
photographs by the way will will upload the slides. So these repositories they
exist we push to them we made a GitHub organization that we push to them
yesterday. If you wanted to look if you wanted to start coding right away, say if
you wanted to write a bot, we'd recommend you wait a few weeks say two to three
because we still want it like, fix a few of the kinks in there. Everyone else we
hope will just look at it, maybe this will help your understanding of what actually
does. And also the activists in us hope that this might get the people at Threema
to open-source their code because no matter what we tell you here, and no
matter what they tell you how their their app actually works - and this is always
true for non open-source software, there will never be true transparency: you will
never be able to prove that what runs on your phone is actually implemented the
same way we've shown you. With our library you would have these guarantees, you can
actually you can definitely use it to write bots if you ever wanted to do that.
Or if you just want to understand how it works please go ahead and dive right into
there. Well, with that said, we thank you for your attention.
*Applause* Herald: Okay, thank you very much, Roland,
Frieder, we only have time for one question, so who has a super eager
question - the signal angel is signalling. Signal Angel: There's a couple of
questions, but I will pick the best one. The best one was from alien: could you use
captions to inject malicious Exif data into the images?
Frieder: What is malicious Exif data? Signal Angel: Well some data that probably
the image passing library. Frieder: What we did not do was have
looked very particular at security problems in the implementation of Threema.
I could, like, and I would say this falls into this department: there's also a
library handling the gif display meant and stuff like that. We could have looked at
is this broken, maybe. We did not. We looked at the protocol from a higher level
and, so I cannot say anything about it. Signal Angel: Okay and another question
was when an non-group originating user sends the group update message, what
happens? Frieder: The thing is, Threema group IDs
aren't globally unique. A Threema group ID only refers to a particular group together
with the group creator's ID. So if you send an update group message from your
account, the app would look for a different group than you intended. Because
your group ID would say I'm I'm trying to update a group created by me with this and
that ID. So it won't be the group you want to hijack.
Herald: Okay, very well. Another round of applause for our speakers!
*applause*
*postroll music*
*Subtitles created by c3subtitles.de in the year 2018*