0:00:00.000,0:00:13.139
33C3 preroll music
0:00:13.139,0:00:17.510
Herald: Good morning everyone, thanks for[br]showing up in such great numbers, that's
0:00:17.510,0:00:23.630
always a good thing[br]for such an early session.
0:00:23.630,0:00:28.690
First of all I would like to ask you[br]a question, I mean... or
0:00:28.690,0:00:33.590
let's start like that: Last night I had
0:00:33.590,0:00:38.680
a weird encounter with a locked door
0:00:38.680,0:00:45.629
out of the fate that we endured during[br]this week we were out of our apartment
0:00:45.629,0:00:51.330
and the hotel owner let us stay in their[br]office, but the guy who stayed there
0:00:51.330,0:00:57.290
put the dead lock on so we tried to reach[br]him. Hmmm, how do you reach them?
0:00:57.290,0:01:03.350
We thought about maybe he has some[br]messaging, maybe he has some mobile number,
0:01:03.350,0:01:08.880
no landline, landline, they have landline.[br]It turned out that the guy
0:01:08.880,0:01:13.870
was not at the landline, out, exit, and
0:01:13.870,0:01:17.860
so we looked around in the bar.[br]So this wouldn't have happened
0:01:17.860,0:01:23.870
if he had mobile messaging, so,[br]to dive into that, if we could
0:01:23.870,0:01:29.369
just text him: "Hey, we are at the hotel,[br]please open the door" we would have had
0:01:29.369,0:01:34.659
one hour more sleep tonight.[br]So let's dive in
0:01:34.659,0:01:41.339
with, yeah, the talk of today.
0:01:41.339,0:01:45.580
So this morning session starts with[br]our speakers Roland Schilling
0:01:45.580,0:01:48.880
and Frieder Steinmetz.
0:01:48.880,0:01:55.580
applause
0:01:55.580,0:02:00.170
And they will be talking about...[br]they will at first give you a gentle
0:02:00.170,0:02:06.240
introduction into Mobile Messaging. I have[br]nine messaging apps on my phone, no, ten!
0:02:06.240,0:02:10.990
The organizers forced me to[br]install another messaging app.
0:02:10.990,0:02:15.080
And after that [they] give you a quick[br]analysis, or not so quick, I don't know,
0:02:15.080,0:02:18.390
a deep analysis of the Threema protocol.
0:02:18.390,0:02:22.000
So let's give another round of[br]applause for our speakers!
0:02:22.000,0:02:28.730
applause
0:02:28.730,0:02:33.780
Thank you, Thilo. I am Roland,[br]this is Frieder, and
0:02:33.780,0:02:37.840
as, well, as Thilo already introduced[br]us we are going to talk about
0:02:37.840,0:02:43.260
secure messaging. More specifically we are[br]trying to give a very broad introduction
0:02:43.260,0:02:48.170
into the topic because we want to make the[br]field that is somewhat complex available
0:02:48.170,0:02:53.580
to a more broad audience, so as[br]to leave our expert bubble
0:02:53.580,0:02:58.390
and get the knowledge of technology[br]that people use every day
0:02:58.390,0:03:03.500
to these people who are using it.[br]To do that we have to start
0:03:03.500,0:03:08.720
at a very low level which might mean for[br]the security and crypto nerds in the room
0:03:08.720,0:03:14.550
that you will see a lot of things that you[br]already know. But bear with us, please,
0:03:14.550,0:03:20.090
since we are specifically trying, at least[br]with the first part of the talk, to convey
0:03:20.090,0:03:24.790
a few of these mechanisms[br]that drive encrypted messaging
0:03:24.790,0:03:29.910
to people who are new to the field.[br]So what we are going
0:03:29.910,0:03:35.250
to try today is basically three[br]things: We are... we will try to
0:03:35.250,0:03:40.410
outline privacy expectations when we[br]communicate. We are going to do that
0:03:40.410,0:03:46.110
by sketching a communication scenario[br]to you guys and identifying
0:03:46.110,0:03:49.960
what we can derive from that in[br]expectations. We are going to find
0:03:49.960,0:03:54.470
an analogy, or look at an analogy that[br]helps us map these expectations to mobile
0:03:54.470,0:03:59.470
messaging. And then we are going to look[br]at specific solutions, technical solutions
0:03:59.470,0:04:06.760
that make it possible to make mobile[br]messaging as secure, and give us the same
0:04:06.760,0:04:12.470
privacy guarantees that a one-to-one talk[br]would, before, in the second part of the
0:04:12.470,0:04:17.060
talk we move on to look at a specific[br]implementation, and it's no secret anymore
0:04:17.060,0:04:23.880
that we are going to look at the specific[br]implementation of Threema. So let's just
0:04:23.880,0:04:29.590
dive right in.[br]You are at a party, a party in a house
0:04:29.590,0:04:33.150
full of people and a friend approaches[br]you wanting to have a private
0:04:33.150,0:04:38.430
conversation. Now what do you do? You[br]ideally would find a place at this party
0:04:38.430,0:04:43.090
that is, well, private, and in our[br]scenario you find a room, maybe the
0:04:43.090,0:04:47.600
bedroom of the host where nobody's in[br]there, you enter the room, you close the
0:04:47.600,0:04:52.340
door behind you. Meaning you are now[br]private, you have a one-on-one,
0:04:52.340,0:04:56.280
one-to-one session in this room in[br]private. And we are going to look at
0:04:56.280,0:05:00.420
what that means.
0:05:00.420,0:05:06.919
First of all the most, the most intuitive[br]one is what we call confidentiality and
0:05:06.919,0:05:11.319
that means that since nobody is there in[br]the room with you you are absolutely sure
0:05:11.319,0:05:15.509
that anything you say and anything your[br]communication partner says, if you imagine
0:05:15.509,0:05:21.029
Frieder and me having this conversation,[br]can only be heard by the other person.
0:05:21.029,0:05:26.300
If that is guaranteed we say… we call this[br]confidentiality because nobody who's
0:05:26.300,0:05:32.270
not intended to overhear any of[br]the conversation will be able to.
0:05:32.270,0:05:37.770
The second part… no, the second
0:05:37.770,0:05:42.580
claim that we make is: if you guys[br]know each other, and again,
0:05:42.580,0:05:45.909
if I had a talk with Frieder I know I've[br]been knowing him for a long time,
0:05:45.909,0:05:50.619
more than five years now, I know what[br]his face looks like, I know his voice,
0:05:50.619,0:05:56.199
I know that if I talk to him I actually[br]talk to ‘him’, meaning I know exactly
0:05:56.199,0:06:01.009
who my communication partner is[br]and the same thing goes vice versa,
0:06:01.009,0:06:06.660
so if this is achieved, if we can say[br]I definitely know who I'm talking to,
0:06:06.660,0:06:11.409
there's no chance that somebody else[br]switches in and poses off as Frieder
0:06:11.409,0:06:17.109
we call this ‘authenticity’.[br]Moving on. Integrity.
0:06:17.109,0:06:21.840
Integrity is a bit… this is where[br]the analogy falls short,
0:06:21.840,0:06:27.579
well, somewhat. But, basically, if I can[br]make sure that everything I say
0:06:27.579,0:06:31.619
reaches Frieder exactly the way I wanted[br]to say it and there is no messenger
0:06:31.619,0:06:36.860
in between, I'm not telling a third friend[br]"Please tell Frieder something" and
0:06:36.860,0:06:43.400
he will then alter the message because[br]he remembered it wrong or
0:06:43.400,0:06:49.070
has malicious intentions. If I can[br]make sure that everything I say
0:06:49.070,0:06:54.190
is received by Frieder exactly the way[br]I said it then we have ‘integrity’
0:06:54.190,0:06:59.479
on our communication channel.[br]Okay. The next ones are two ones
0:06:59.479,0:07:04.849
that are bit hard to grasp at first.[br]Therefore we are going to take a few
0:07:04.849,0:07:09.050
minutes to look at these, and they are[br]‘forward and future secrecy’. Suppose
0:07:09.050,0:07:14.900
somebody entered the room while we had our[br]talk and that person would stay a while
0:07:14.900,0:07:21.449
overhear some portion of our talk and[br]then they would leave the room again. Now
0:07:21.449,0:07:25.059
if they, if at the[br]point where they entered the room they
0:07:25.059,0:07:28.630
wouldn't learn anything about the[br]conversation that we had before, which is
0:07:28.630,0:07:32.349
intuitive in this scenario which, that's[br]why we chose it, they enter the room, and
0:07:32.349,0:07:36.660
everything that can overhear is only the[br]portion of the talk that takes place while
0:07:36.660,0:07:41.389
they are in the room, they don't learn[br]anything about what we said before,
0:07:41.389,0:07:46.610
meaning we have what we call forward[br]security, we'll get back to that, and
0:07:46.610,0:07:51.190
after they left they wouldn't be able to[br]overhear anything, anything more that we
0:07:51.190,0:07:56.319
say. This is what we call future security.[br]Because those are a bit hard to understand
0:07:56.319,0:08:00.090
we have made a graphic here. And we are[br]going to get back to this graphic when we
0:08:00.090,0:08:05.180
translate this so I'm going to take a[br]minute to introduce it. We have a time
0:08:05.180,0:08:08.509
line that is blue, goes from left to[br]right, and on this time line we have green
0:08:08.509,0:08:14.160
bar that denotes our secret on our secret[br]conversation. The first pink bar there is
0:08:14.160,0:08:19.159
when the third person enters the room,[br]then our secret conversation turns orange
0:08:19.159,0:08:23.279
because it's no longer secret, it's now[br]overheard by the third person and after
0:08:23.279,0:08:29.979
they left they wouldn't know anything that[br]was said after that. So the left part of
0:08:29.979,0:08:36.510
it meaning the fact that they can't hear[br]anything into the past is what we call
0:08:36.510,0:08:40.299
forward security and if they can't learn[br]anything after they left we call it future
0:08:40.299,0:08:48.440
secure, future secrecy, sorry. Okay, the[br]last one that we're going to talk about
0:08:48.440,0:08:53.310
since we're trying to keep things simple[br]is deniability. Since we are only two
0:08:53.310,0:08:57.720
people in the room and there are no[br]witnesses we achieve deniability because
0:08:57.720,0:09:01.540
after we had this talk we returned to the[br]party and people asked us what happened,
0:09:01.540,0:09:06.110
um, I can always point to Frieder as you[br]could to your friend and say he said
0:09:06.110,0:09:10.070
something. Frieder could always say, no I[br]didn't, and it would be my word against
0:09:10.070,0:09:17.130
his and if this is, you know, if our[br]scenario allows for this we have
0:09:17.130,0:09:22.190
deniability because every one of us can[br]always deny having said or not having said
0:09:22.190,0:09:28.209
something.[br]And now we are going to look at messaging.
0:09:28.209,0:09:33.870
Now in messaging a third player comes into[br]the room and this could be your provider
0:09:33.870,0:09:40.040
if we talk about text messaging like short[br]messages that we used to send in the 90s,
0:09:40.040,0:09:44.000
it could be your messaging provider if you[br]use something more sophisticated, it could
0:09:44.000,0:09:47.600
be WhatsApp for example could be Apple[br]depending on what your favorite messenger
0:09:47.600,0:09:54.100
is but there is always, unless you use,[br]like, federated systems, if some some of
0:09:54.100,0:09:59.310
you guys might think but I'm using Jabber[br]I know but we are looking at centralized
0:09:59.310,0:10:03.740
systems right now and in these there will[br]always be one third party that all
0:10:03.740,0:10:07.820
messages go through, whether you want it[br]or not. And whether you're aware of it or
0:10:07.820,0:10:16.620
not. And this brings us to our second[br]analogy which is Postal Services now while
0:10:16.620,0:10:20.431
messaging feels like you have a private[br]conversation with the other person and I
0:10:20.431,0:10:23.822
think everyone can relate to that you have[br]your phone you see you are
0:10:23.822,0:10:28.410
displayed with the conversation and it[br]looks like only you and this other person,
0:10:28.410,0:10:32.300
in my case Frida, are having this[br]conversation we feel like we have a
0:10:32.300,0:10:36.820
private conversation, while actually our[br]messages go through a service provider all
0:10:36.820,0:10:42.810
the time. Meaning we are now looking[br]something at something more akin to postal
0:10:42.810,0:10:49.230
services. We prepare a message send it[br]off, our message provider takes the
0:10:49.230,0:10:53.170
message, takes a to our intended[br]recipient, and they can then read the
0:10:53.170,0:11:00.740
message. And this is this this applies to[br]all the messages we exchange. And to
0:11:00.740,0:11:04.700
underline that we're going to look at what[br]I initially called traditional messaging
0:11:04.700,0:11:12.399
meaning text messaging, unencrypted SMS[br]messaging, and as you may or may not be
0:11:12.399,0:11:17.029
aware of these messages also go through[br]our providers: more than one provider
0:11:17.029,0:11:21.760
even. Say I'm at Vodafone and Frieder is[br]with Verizon, I don't know, I would send
0:11:21.760,0:11:26.100
my messages to Vodaphone, they would[br]forward them to Verizon who would then
0:11:26.100,0:11:32.089
deliver it to Frieders phone. So since[br]both of our providers would know all the
0:11:32.089,0:11:36.420
messages; they are unencrypted; we would[br]have no confidentiality.
0:11:36.420,0:11:41.000
They could change the messages and these[br]things have happened actually. So we
0:11:41.000,0:11:44.000
don't have any integrity we don't know if[br]the messages received are actually the
0:11:44.000,0:11:51.410
ones that were sent. We also have no[br]authentication because phone numbers are
0:11:51.410,0:11:56.690
very weak for authenticating people, they[br]are managed by our providers they don't
0:11:56.690,0:12:01.720
they are not fixed that there's no fixed[br]mapping to our phones or our SIM cards.
0:12:01.720,0:12:06.459
They can be changed they can be rerouted[br]so we don't we never know if the messages
0:12:06.459,0:12:10.730
we send are actually received by the[br]people we intended to: no authenticity and
0:12:10.730,0:12:17.279
no authentication. Now forward secrecy and[br]future secrecy don't even apply because we
0:12:17.279,0:12:24.269
have no secrecy. We do have some sort of[br]deniability but this goes into like
0:12:24.269,0:12:33.370
philosophically.. Let's do that again:[br]philosophical claims of whether when I say
0:12:33.370,0:12:36.850
I haven't sent anything this must have[br]been the provider they can technically,
0:12:36.850,0:12:41.629
you know, guarantee they did or did not do[br]something. So let's not dive too deeply
0:12:41.629,0:12:46.920
into that discussion, but we can summarize[br]that messaging translates, at least
0:12:46.920,0:12:51.089
traditional messaging, translates very[br]badly to our privacy expectations when we
0:12:51.089,0:13:00.430
think of a communication. Okay, moving on.[br]Looking at our postal analogy, actually
0:13:00.430,0:13:05.390
our messages are more like postcards.[br]Because they are plain, our providers can
0:13:05.390,0:13:09.600
look at them, can change them, you know[br]all the things we've just described: just
0:13:09.600,0:13:14.440
as they would a postcard. They can see the[br]intended recipient, they can look at the
0:13:14.440,0:13:18.690
sender, they can look at the tags, change[br]it: postcards. And what we want to achieve
0:13:18.690,0:13:25.230
now is find a way to wrap these postcards[br]and make them more like letters, assuming
0:13:25.230,0:13:29.819
that postal services don't open letters.[br]That's the one the one point with this
0:13:29.819,0:13:35.960
analogy that we have to like, define. And[br]to be able to do that we're going to we're
0:13:35.960,0:13:41.220
trying to give you the shortest encryption[br]to – the shortest introduction to
0:13:41.220,0:13:46.790
encryption, see I'm confusing myself here,[br]that you will ever get. Starting with
0:13:46.790,0:13:50.209
symmetric encryption.[br]Now, encryption, for those of you who
0:13:50.209,0:13:55.500
don't know, is what we call the[br]translation of plain, readable text into
0:13:55.500,0:14:00.459
text that looks like it's random, but it[br]can be reversed and turned back into plain
0:14:00.459,0:14:05.690
text provided we have the right key for[br]that. So to stick with a very simple
0:14:05.690,0:14:09.400
example please imagine this box that we've[br]just labeled crypto, and we are not
0:14:09.400,0:14:13.839
concerned with what's in the box we just[br]imagine it as a machine. Please imagine it
0:14:13.839,0:14:18.069
as a machine that takes two inputs the[br]plaintext and the key, and it produces
0:14:18.069,0:14:21.959
something that we call ciphertext.[br]The ciphertext is undistinguishable from
0:14:21.959,0:14:29.949
random text, but it can be reversed at the[br]recipient side using the same key and
0:14:29.949,0:14:35.019
basically the same machine just doing the[br]operation, you know, in reverse: turning
0:14:35.019,0:14:42.290
the ciphertext back into plain text. This[br]is what we call, sorry, this is what we
0:14:42.290,0:14:48.079
call symmetric encryption because if you[br]imagine a line where the cipher text is
0:14:48.079,0:14:52.959
you could basically mirror the thing on to[br]the other side so it's symmetric at that
0:14:52.959,0:14:59.560
at that line. And when when there's[br]something that is called symmetric there
0:14:59.560,0:15:03.350
is also something that is called[br]asymmetric and asymmetric encryption works
0:15:03.350,0:15:08.630
relatively the same way, only there are[br]now two keys. We have made them a yellow
0:15:08.630,0:15:13.709
one and a blue one. These keys are called[br]a key pair. They are mathematically
0:15:13.709,0:15:19.300
linked. And the way this works now is that[br]anything encrypted with one of these keys
0:15:19.300,0:15:26.649
can only be decrypted with the other one.[br]You can do it both ways, but the important
0:15:26.649,0:15:31.950
thing to memorize here is just anything I[br]encrypt with the yellow key can only be
0:15:31.950,0:15:42.370
decrypted with the blue key. Okay, since[br]we have that now, let's capitalize on this
0:15:42.370,0:15:48.230
on this scenario. Imagine each of our[br]communication partners now has one of
0:15:48.230,0:15:51.350
these two keys and we are still talking[br]about the same key pair that we've
0:15:51.350,0:15:56.160
outlined on the previous slide. Now we[br]call one of them a secret key and one of
0:15:56.160,0:16:03.950
them a public key. This is probably known[br]to most of you: traditional public key
0:16:03.950,0:16:06.860
cryptography.[br]We've added something that is called an
0:16:06.860,0:16:09.180
identity in this in this picture: we will[br]get back
0:16:09.180,0:16:13.870
to that in a minute. But the scenario we[br]want we want you to envision right now is
0:16:13.870,0:16:19.959
that both parties would publish their[br]public key to the public. And we are going
0:16:19.959,0:16:24.829
to get back to what that means as well.[br]And keep their secret key, as the name
0:16:24.829,0:16:29.790
says, secret. Some of you might know this[br]as a private key: it's the same the same
0:16:29.790,0:16:38.670
concept applies. We just chose to call it[br]secret key. Because it more clearly
0:16:38.670,0:16:44.110
denotes that it's actually secret and not[br]never published. So this would mean any
0:16:44.110,0:16:48.550
message that would that would be encrypted[br]with one of the parties public key could
0:16:48.550,0:16:54.100
then only be decrypted with that parties[br]secret key, putting us in a position where
0:16:54.100,0:16:59.060
I could take Frieta's public key, encrypt[br]my message, send it to him, and I would
0:16:59.060,0:17:04.689
know that he would be the only one able to[br]decrypt the message - as long as his
0:17:04.689,0:17:13.080
secret key remains his, well, secret.[br]And he doesn't doesn't publish it. Well
0:17:13.080,0:17:22.050
the problem is: it's a very expensive[br]scenario. We get something akin to a
0:17:22.050,0:17:27.970
postal to a postal service where we can[br]now encrypt the message and envision it
0:17:27.970,0:17:32.890
like putting a plain sheet of paper into[br]an envelope, seal it, we would put it on
0:17:32.890,0:17:38.260
the way. Nobody on the line would be able[br]to look into the letter. They would of
0:17:38.260,0:17:41.350
course, well, since there are addresses on[br]there, they would see who it is from and
0:17:41.350,0:17:48.220
who it to - but they couldn't look inside[br]the letter: this is achieved. But as I've
0:17:48.220,0:17:52.470
already said it's a very expensive[br]mechanism and by that we mean it is hard
0:17:52.470,0:17:59.370
to do for devices - especially since you[br]are doing mobile messaging on your phones,
0:17:59.370,0:18:07.610
ideally, especially hard to do on on small[br]devices like phones. So while if we had a
0:18:07.610,0:18:15.320
mechanism that would allow us to combine[br]symmetric and asymmetric encryption. And
0:18:15.320,0:18:20.990
it turns out we do. And we are going to[br]keep this very simple by just looking at
0:18:20.990,0:18:26.650
what is called key establishment, and then[br]again also just one particular way of key
0:18:26.650,0:18:33.160
establishment. We have two new boxes here:[br]they are called key generators. And the
0:18:33.160,0:18:34.160
scheme[br]that we are
0:18:34.160,0:18:36.860
looking at right now works works the[br]following way: You can take one of the
0:18:36.860,0:18:41.890
secret keys, and another part and another[br]public key, like the one of the other
0:18:41.890,0:18:45.580
party, put them into the key generator.[br]And remember, these keys are
0:18:45.580,0:18:50.710
mathematically linked each secret key[br]belongs to exactly one public key. And the
0:18:50.710,0:18:54.150
way this key generator works is that[br]through this mathematical this
0:18:54.150,0:18:59.380
mathematical linking it doesn't matter if[br]you take, in this case, let's call them
0:18:59.380,0:19:04.390
Alice and Bob: if you take Alice's secret[br]key and Bob public key, or Bob secret key
0:19:04.390,0:19:09.780
and Alice's public key, you will always[br]come up with the same key. And we call
0:19:09.780,0:19:13.830
this a shared key. Because this key can[br]now be it can be generated independently
0:19:13.830,0:19:18.130
on both sides and it can then be used for[br]symmetric encryption, and as we've already
0:19:18.130,0:19:26.300
told you symmetric encryption is a lot[br]cheaper than asymmetric encryption. So
0:19:26.300,0:19:29.900
this has one advantage and one[br]disadvantage: the advantages I've already
0:19:29.900,0:19:36.370
said is that it's way cheaper, and the[br]fact, well, the advantage is also that we
0:19:36.370,0:19:39.900
come up with the key on both sides, and[br]the disadvantage is that we come up with
0:19:39.900,0:19:47.090
one key on both sides - because whether or[br]not you've realized this by now since this
0:19:47.090,0:19:51.580
is a very static scheme we always come up[br]with the same key. That is going to be a
0:19:51.580,0:19:57.880
problem in a minute. So let's recap we[br]have looked at asymmetric encryption which
0:19:57.880,0:20:02.429
as I've said gives us IDs, and we're going[br]to look at what means. But it is very
0:20:02.429,0:20:06.400
expensive. We know that symmetric[br]encryption is cheap, but we have to find a
0:20:06.400,0:20:12.309
way to get this key delivered to both[br]parties before they can even start
0:20:12.309,0:20:16.839
encrypting their communication. And we[br]have looked at key establishment, which
0:20:16.839,0:20:23.920
allows us which gives us symmetric keys[br]based on asymmetric key pairs. Meaning we
0:20:23.920,0:20:28.350
have now basically achieved[br]confidentiality - we can use these keys
0:20:28.350,0:20:32.029
put them in the machines with our[br]plaintext, get ciphertext, can, you know,
0:20:32.029,0:20:37.030
we are able to transport it to the other[br]side. Nobody can look inside.
0:20:37.030,0:20:42.670
Confidentiality is achieved.[br]Now deniability. Deniability in this
0:20:42.670,0:20:47.510
scenario would basically mean, if you[br]think back at our initial sketch, where we
0:20:47.510,0:20:51.250
could say I haven't said that, and the[br]other guy couldn't prove that we did,
0:20:51.250,0:20:56.649
would in this case be a letter that was[br]sent to both of the participants, and it
0:20:56.649,0:21:01.250
would be from either of the participants.[br]So that when looking at this
0:21:01.250,0:21:05.200
cryptographically, we couldn't say this[br]was sent by me or this was sent by Frieda.
0:21:05.200,0:21:10.429
You could just see it was sent by, well,[br]either of us. And if you think of the
0:21:10.429,0:21:13.980
scheme that we've just sketched, since[br]both parties come up with the same key by
0:21:13.980,0:21:20.010
using different by using a different set[br]of keys to to generate them, basically the
0:21:20.010,0:21:25.320
same key can be generated on both sides.[br]And you can never really say, by just
0:21:25.320,0:21:29.649
looking at a message, if it was encrypted[br]with a shared key generated on one or on
0:21:29.649,0:21:35.940
the other side since they are the same.[br]So, very simply and on a very high level
0:21:35.940,0:21:41.500
we have now achieved deniability. What[br]about forward and future secrecy? You
0:21:41.500,0:21:45.330
remember this picture? Our overheard[br]conversation on the party that we were at
0:21:45.330,0:21:52.740
at the beginning of the talk? Well, this[br]picture now changes to this. And what we
0:21:52.740,0:21:58.200
are looking at now is something we call[br]key compromise and key renegotiation. Key
0:21:58.200,0:22:03.669
compromise would be the scenario where one[br]of our keys were lost. And we are talking
0:22:03.669,0:22:08.470
about the shared key that we generated[br]now. Which, if it would fall into the
0:22:08.470,0:22:13.059
hands of an attacker, this attacker would[br]be able to decrypt our messages because
0:22:13.059,0:22:23.140
it's the same key that we used for that.[br]Now, if if if at the point where the key
0:22:23.140,0:22:28.000
was compromised they wouldn't be able to[br]decrypt anything prior to that point - we
0:22:28.000,0:22:33.020
would have forward secrecy. And if we had[br]a way to renegotiate keys, and they would
0:22:33.020,0:22:38.240
be different ,completely different, not[br]linked to the ones we had before, and then
0:22:38.240,0:22:42.820
use that in the future, we would have[br]future secrecy. But we don't, since as
0:22:42.820,0:22:48.279
we've already said the keys that we[br]generate are always the same. And we want
0:22:48.279,0:22:51.210
you to keep this in mind because[br]we will get
0:22:51.210,0:22:54.120
back to this[br]when we look at Threema in more detail.
0:22:58.573,0:23:07.320
yeah, if we had a way to dump keys after[br]having used them, we could achieve forward
0:23:07.320,0:23:13.669
and future secrecy. Since we don't, we[br]can't right now. Okay, next recap our key
0:23:13.669,0:23:17.180
establishment protocol gives us[br]confidentiality, deniability, and
0:23:17.180,0:23:23.159
authenticity. We don't have forward and[br]future secrecy. And if you've stuck with
0:23:23.159,0:23:27.750
us you would realize we are omitting[br]integrity here - that is because we don't
0:23:27.750,0:23:32.419
want to introduce a new concept right now[br]but we will get back to that, and you will
0:23:32.419,0:23:39.279
see that when we look at Threema it[br]actually does have integrity. Now,
0:23:39.279,0:23:43.419
basically you could think we fixed all[br]the-- well, we fixed everything, but you
0:23:43.419,0:23:47.779
heard us talk about things like IDs, and[br]we said we haven't really lost a few words
0:23:47.779,0:23:53.310
about them lost many words about them and[br]we're going to look at that now. And we
0:23:53.310,0:23:56.590
are going to start with a quote by my very[br]own professor - don't worry you don't have
0:23:56.590,0:24:01.159
to read that, I'm going to do it for you.[br]My professor says, "cryptography is
0:24:01.159,0:24:04.950
rarely, if ever, the solution to a[br]security problem. Cryptography is a
0:24:04.950,0:24:09.360
translation mechanism, usually converting[br]a communications security problem into a
0:24:09.360,0:24:15.770
key management problem." And if you think[br]of it, this is exactly what we have now,
0:24:15.770,0:24:19.970
because I know that Frieder has a private[br]key, a secret key I'm sorry, and a public
0:24:19.970,0:24:24.890
key. He knows that I have a secret key and[br]a public key. How does I know which one of
0:24:24.890,0:24:29.940
those public keys that are in the open is[br]actually his? How would I communicate to
0:24:29.940,0:24:36.820
him what my public key is? Those of you[br]who've used PGP for example and then the
0:24:36.820,0:24:42.040
couple in the last couple of decades know[br]what I'm talking about. And we have the
0:24:42.040,0:24:46.240
same problem everywhere where public key[br]cryptography is used, so we also have the
0:24:46.240,0:24:52.700
same problem in mobile messaging. To the[br]rescue comes our messaging server -
0:24:52.700,0:24:57.030
because, since we have a central instance[br]inbetween us, we can now query this
0:24:57.030,0:25:02.490
instance: I can now tell my public key; I[br]can now take my public key and my identity,
0:25:02.490,0:25:04.440
tell the messaging server, "[br]Hey messaging server - this is my
0:25:04.440,0:25:07.490
identity. Please store it for me." So that[br]Frieda, who has
0:25:07.490,0:25:13.860
some well some kind of information to[br]identify me can then query, you, get my
0:25:13.860,0:25:19.409
public key back. This of course assumes[br]that we trust the message messaging
0:25:19.409,0:25:25.730
server. We may or may not do that. But for[br]now we have a way to at least communicate
0:25:25.730,0:25:31.870
our our public keys to other parties. Now[br]what can we use as identities here? In
0:25:31.870,0:25:37.029
our, like, now a figure here it's very[br]simple: Alice just goes to the messaging
0:25:37.029,0:25:40.809
server and says, "Hey, what's the public[br]key for Bob?" And the messaging server
0:25:40.809,0:25:45.840
magically knows who Bob is, and what his[br]public key is. And the same thing where I
0:25:45.840,0:25:52.289
work works the other way. What would; the[br]question now is what is a good ID in this
0:25:52.289,0:25:57.380
scenario. Remember we are on phones, so we[br]could think of using phone numbers, we
0:25:57.380,0:26:02.000
could think of using email addresses, we[br]could think of something else. And
0:26:02.000,0:26:06.830
something else will be the interesting[br]part, but let's look at the other parts
0:26:06.830,0:26:10.559
one by one.[br]Phone numbers can identify users - you
0:26:10.559,0:26:14.130
remember that you rely on your providers[br]for the mapping between phone numbers and
0:26:14.130,0:26:19.210
SIM cards, so you have to trust another[br]instance in this situation. We're going to
0:26:19.210,0:26:23.049
ignore that completely because we find[br]that phone numbers are personal
0:26:23.049,0:26:27.711
information, and I for one my phone[br]number. And I mean the same phone number
0:26:27.711,0:26:32.269
I've had it for like 18 years now. I[br]wouldn't want that to get into the wrong
0:26:32.269,0:26:39.960
hands. And by using it to identify me as a[br]person, or, you know, my cryptographic
0:26:39.960,0:26:45.429
identity that is bound to my to my keys: I[br]wouldn't necessarily want to use that,
0:26:45.429,0:26:49.499
because I wouldn't be able to change it or[br]I would want to change it if it ever got
0:26:49.499,0:26:54.640
compromised. Now something else comes to[br]mind: e-mail addresses. E-mail addresses
0:26:54.640,0:27:00.740
basically are also personal information.[br]They are a bit shorter lived, as we would
0:27:00.740,0:27:05.120
argue, than phone numbers. But, and you[br]can use temporary e-mails, you can do a
0:27:05.120,0:27:09.730
lot more you are way more flexible with[br]e-mails. But ideally we want to have
0:27:09.730,0:27:14.830
something that is that we call dedicated[br]IDs, meanings something that identifies me
0:27:14.830,0:27:18.229
only within the bounds of the service that[br]we use.
0:27:18.229,0:27:24.450
So that's what we want to have we are[br]going to show you how this might work but
0:27:24.450,0:27:30.480
we still have to find a way to verify[br]ownership, because this is a scenario that
0:27:30.480,0:27:36.030
is more or less likely to happen. I am[br]presented with a number of public keys to
0:27:36.030,0:27:41.760
an identity that I know - and I have to[br]verify a way to, well, I have to find a
0:27:41.760,0:27:46.049
way to verify which one is maybe the right[br]one, maybe the one that is actually used,
0:27:46.049,0:27:51.429
maybe Frieda has used quite a number of[br]public keys - he's a lazy guy. He forgets
0:27:51.429,0:27:55.100
to, you know, take his keys from one[br]machine to the other: he just, you know,
0:27:55.100,0:27:59.210
buys a new laptop sets up a new public[br]key: bam, he has two - which one am I
0:27:59.210,0:28:04.299
supposed to read to use right now. Now[br]remember that we are looking at the
0:28:04.299,0:28:10.159
messenger server for, you know, key[br]brokerage, and we are now going to add a
0:28:10.159,0:28:18.929
third line here and that is this one.[br]Basically we introduce a way to meet in
0:28:18.929,0:28:23.860
person, and again PGP veterans will know[br]what I'm talking about, and verify our
0:28:23.860,0:28:28.580
keys independently. We've chosen QR codes[br]here - free mail uses QR codes, many other
0:28:28.580,0:28:33.440
messengers and do as well, and we want to[br]like tell you why this is an important
0:28:33.440,0:28:39.520
feature to be able to to verify our public[br]keys independently of the messaging
0:28:39.520,0:28:43.620
server. Because once we did that we no[br]longer have to trust the messaging server
0:28:43.620,0:28:47.790
to tell us or - we don't have longer we no[br]longer have to trust his promise that this
0:28:47.790,0:28:54.150
is actually the key we are looking for. We[br]have verified that independently. Okay, we
0:28:54.150,0:29:00.050
have basically solved our authenticity[br]problem. We know that we can identify
0:29:00.050,0:29:04.269
users by phone numbers and emails, and you[br]remember our queries to the server for
0:29:04.269,0:29:08.100
Bob: we can still use phone numbers for[br]that if we want to. We can use emails for
0:29:08.100,0:29:12.789
that if we want to. We don't have to. We can[br]use our ids anonymously. But we have a way
0:29:12.789,0:29:18.190
to verify them independently. The[br]remaining problem is users changing their
0:29:18.190,0:29:24.179
IDs - that is where we have to verify[br]again. And we also get back to that later,
0:29:24.179,0:29:27.800
but I want to look at something else[br]first, and that is the handling of
0:29:27.800,0:29:31.320
metadata.[br]Now, we know that an attacker can no
0:29:31.320,0:29:36.210
longer look inside our messages. They can,[br]however, still see the addressee, who the
0:29:36.210,0:29:39.540
message is from, and they can see how[br]large the message is, they can see they
0:29:39.540,0:29:44.649
can look at timestamps and stuff like[br]that. And since we are getting a bit tight
0:29:44.649,0:29:50.899
on the clock I'm going to try to[br]accelerate this a bit. Metadata handling:
0:29:50.899,0:29:56.440
we want to conceal now who a message is[br]from, who a message is to. And we are
0:29:56.440,0:30:01.050
doing this by taking the envelope that[br]we've just generated, wrapping it into a
0:30:01.050,0:30:05.480
third envelope, and then sending that to[br]the messenger server first. And the
0:30:05.480,0:30:12.169
messenger server gets a lot of envelopes.[br]They are all just addressed to the
0:30:12.169,0:30:15.950
messenger server, so anyone on the network[br]would basically see there's there's one
0:30:15.950,0:30:19.699
party sending a lot of messages to the[br]messenger server; maybe there are a lot of
0:30:19.699,0:30:24.590
parties. But they couldn't look at they[br]couldn't look at the end-to-end, we call a
0:30:24.590,0:30:29.819
channel, that's seeing what the address is[br]on each internal envelope are. The
0:30:29.819,0:30:35.690
messaging server, however, can. They would[br]open the other-- the outer envelope, look
0:30:35.690,0:30:40.559
at the inside, see , "Okay this is a[br]message directed at Alice," wrap it into
0:30:40.559,0:30:43.880
another envelope - that would just say,[br]"This is the message from the messaging
0:30:43.880,0:30:50.320
server and it is directed to Alice." Who[br]would then be able to, you know, open the
0:30:50.320,0:30:54.230
outer envelope, open the inner envelope,[br]see this is actually a message from Bob.
0:30:54.230,0:30:59.559
And what we have thereby achieved is a to[br]where two layer end to end communication
0:30:59.559,0:31:06.230
tunnel as we call it, where the purple and[br]the blue bar are encrypted channels
0:31:06.230,0:31:13.150
between both communication partners and[br]the messaging server, and they carry an
0:31:13.150,0:31:18.560
encrypted tunnel between both partners,[br]you know, both communication partners,
0:31:18.560,0:31:24.860
directly. But, and we've had this caveat[br]before, the messaging server still knows
0:31:24.860,0:31:29.080
both communication partners, they still[br]know the times that the messages were
0:31:29.080,0:31:33.940
sent. And they also know the size of the[br]message. But we can do something against
0:31:33.940,0:31:39.269
that. And we what we do is introduce[br]padding - meaning,
0:31:39.269,0:31:42.169
in the inner envelope we[br]just stick a bunch of extra
0:31:42.169,0:31:47.270
pages so the envelope looks a bit thicker.[br]And we do that by just appending random
0:31:47.270,0:31:51.790
information to the actual message before[br]we encrypt it. So anything looking at the
0:31:51.790,0:31:56.479
encrypted message would just see a large[br]message. And, of course, that should be
0:31:56.479,0:31:59.940
random information every time - it should[br]have should never have the same length
0:31:59.940,0:32:05.730
twice. But if we can achieve that, we can[br]at least conceal the size of the message.
0:32:05.730,0:32:12.639
Now so much for our gentle introduction to[br]mobile messaging. And for those those of
0:32:12.639,0:32:19.210
you stuck around, we are now moving on to[br]analyze Threema. Now I want to say a few
0:32:19.210,0:32:24.289
things before we do that - we are not[br]affiliated with Threema, we don't, we are
0:32:24.289,0:32:30.529
not here to recommend that the the app to[br]you or the service. We didn't do any kind
0:32:30.529,0:32:35.380
of formal analysis. There will be no[br]guarantees. We will not be quoted with
0:32:35.380,0:32:41.509
saying, "use it or don't use it." What we[br]want to do is make more people aware of
0:32:41.509,0:32:48.070
the mechanisms that are in use and we have[br]chosen basically a random message provider
0:32:48.070,0:32:52.370
- we could have chosen anyone. We chose[br]Threema for the fact that they do offer
0:32:52.370,0:32:57.190
dedicated IDs. That they don't bind keys[br]to phone numbers, which many messengers
0:32:57.190,0:33:04.240
do. Those of you who use WhatsApp know[br]what I'm talking about. And well, since it
0:33:04.240,0:33:08.710
is closed source we found it interesting[br]to look at what is actually happening inside
0:33:08.710,0:33:13.700
the app and make that publicly aware. Now[br]we are not the only ones we've done this,
0:33:13.700,0:33:18.770
we are also not the first ones who've done[br]this, and we don't claim we are. But we
0:33:18.770,0:33:24.049
are here now and we want to try to make[br]you aware of the inner workings of the app
0:33:24.049,0:33:33.490
as far as we have understood it. And with[br]that I hand the presenter over to Frieda.
0:33:33.490,0:33:42.670
Applause
0:33:42.670,0:33:45.530
Frieda: So I'll be presenting to you our
0:33:45.530,0:33:52.460
understanding of the Threema protocol and[br]how the application works as we deduced
0:33:52.460,0:33:59.260
from mostly reverse engineering the[br]Android app. And so this won't be a
0:33:59.260,0:34:03.539
complete picture, but it will it will be a[br]picture presenting to you the most
0:34:03.539,0:34:09.380
essential features and how the protocol[br]works. And I'll start by giving you a
0:34:09.380,0:34:16.909
bird's eye look at the overall[br]architecture and why Roland was giving you
0:34:16.909,0:34:21.419
this abstract introduction to mobile[br]messaging, there was also always this
0:34:21.419,0:34:26.719
third party - this messaging provider.[br]And this now became actually three
0:34:26.719,0:34:34.220
entities because Threema has three[br]different servers, mostly, doing well,
0:34:34.220,0:34:41.230
very different stuff for for the apps[br]working. And I'll start with the directory
0:34:41.230,0:34:48.840
server in orange at the bottom, because[br]that is the server you most likely will be
0:34:48.840,0:34:55.149
contacted contacting first if you want to[br]engage in any conversation with someone
0:34:55.149,0:34:59.770
you never talked to before. Because this[br]is the server that handles all the
0:34:59.770,0:35:05.850
identity public key related stuff that[br]Roland was talking about so much. This is
0:35:05.850,0:35:12.089
the server you'll be querying for whose[br]public key - I have this Threema ID,
0:35:12.089,0:35:17.050
what's the corresponding public key, for[br]example stuff like that. Above that there
0:35:17.050,0:35:23.410
is the messaging server, which is kind of[br]the core central entity in this this whole
0:35:23.410,0:35:30.140
scenario because it's task is relaying[br]messages from one communication partner to
0:35:30.140,0:35:34.989
another. And above that we have the media[br]server, and I'll be talking about that
0:35:34.989,0:35:42.670
later. In short, its its task, its[br]purpose, is storing large media files like
0:35:42.670,0:35:49.190
images and videos you send to your[br]communication partners. But as I said I
0:35:49.190,0:35:54.319
want to start with the directory server,[br]and in the case of Threema, this directory
0:35:54.319,0:36:01.650
server is offers a REST API so[br]communication with this server happens
0:36:01.650,0:36:12.260
via HTTP. It is HTTPS actually so it's[br]TLS encrypted. And this encryption is also
0:36:12.260,0:36:18.550
fulfills all the requirements you would[br]have to to to a proper TLS connection and,
0:36:18.550,0:36:21.990
so, if you if you want to communicate with[br]the new person and you have
0:36:21.990,0:36:22.990
their phone[br]number or
0:36:22.990,0:36:27.460
the email address or Threema ID. You'll be[br]asking your app will be asking the
0:36:27.460,0:36:30.609
directory server, "Hey, I have this phone[br]number, do you have a corresponding
0:36:30.609,0:36:37.380
Threema account and public key." And the[br]response will hopefully be, "Yes, I do -
0:36:37.380,0:36:41.090
that's a public key that's the Threema ID:[br]go ahead."
0:36:41.090,0:36:51.420
And as Ron said we kind of chose Threema[br]for the arbitrary use of IDs and
0:36:51.420,0:36:57.210
especially for the system of verifying[br]fingerprints in person by scanning QR
0:36:57.210,0:37:06.339
codes and because this is something[br]Threema has and other messengers do not
0:37:06.339,0:37:12.400
have I want to talk a little bit about[br]that, because if you just ask the
0:37:12.400,0:37:17.050
directory server "hey I have a threema ID[br]what is the corresponding public key?" the
0:37:17.050,0:37:20.980
threema location will say "ok I got an[br]answer from from the directory server I
0:37:20.980,0:37:25.660
have a public key but I have very little[br]trust, that you actually know who the real
0:37:25.660,0:37:29.480
person behind this threema account is,[br]we're not quite sure about that", so it'll
0:37:29.480,0:37:37.230
mark this contact with one red dot and if[br]you had a phone number or an email address
0:37:37.230,0:37:40.840
and asked the directory server, "hey[br]what's the corresponding threema account
0:37:40.840,0:37:46.240
and public key?" the app will say, "ok we[br]still have to trust the directory server,
0:37:46.240,0:37:51.640
but we're a little bit more confident that[br]the person on the other hand is actually
0:37:51.640,0:37:55.109
who you think they are because you have a[br]phone number probably linked to a real
0:37:55.109,0:37:59.810
person and you have a better idea who[br]you're talking to but still we rely on the
0:37:59.810,0:38:06.640
threema server", so it'll knock a contact[br]like that with two orange dots and then
0:38:06.640,0:38:11.230
there is the final stage if you met[br]someone in person and scan their, their
0:38:11.230,0:38:17.390
public key and threema ID in form of a QR[br]code such a contact will be marked with
0:38:17.390,0:38:23.470
three green dots and in that case the app[br]says "We're 100% confident we're talking
0:38:23.470,0:38:29.589
to the person we want to talk to and we[br]have the proper keys." So right now we're
0:38:29.589,0:38:35.600
at if we think of engaging a conversation,[br]we were at the point where we do have all
0:38:35.600,0:38:41.410
necessary details to start encrypting our[br]communication, but question remains, how
0:38:41.410,0:38:46.260
do we encrypt our communication,[br]in case of threema.
0:38:46.260,0:38:52.260
Threema uses a library called salt has[br]been developed by Daniel Bernstein and he
0:38:52.260,0:38:59.730
called it salt but it's spelled NaCl so[br]I'm sorry for for the play on words, but
0:38:59.730,0:39:07.240
if you see NaCl its salt so this is a[br]library specifically designed for the
0:39:07.240,0:39:12.440
encryption of[br]messages and it's supposed to be very
0:39:12.440,0:39:20.560
simple in use and give us all the the[br]necessary features we wanted and this is
0:39:20.560,0:39:25.020
Salt's authenticated encryption giving us[br]all the features Roland was talking about
0:39:25.020,0:39:29.930
in abstract before. It gives us integrity,[br]it gives us authenticity, it gives us
0:39:29.930,0:39:39.800
confidentiality and just a quick look and[br]on how this this library would be used is,
0:39:39.800,0:39:44.619
as you can see up there like everything in[br]the grey box is, what the library does and
0:39:44.619,0:39:49.800
we only need our secret key, if we want to[br]encrypt something to someone, the
0:39:49.800,0:39:58.520
recipients public key, our message. So far[br]very obvious and the library also requires
0:39:58.520,0:40:04.960
a nonce, which is something that should be[br]only used once, that's actually yeah part
0:40:04.960,0:40:08.670
of the definition, so we generate[br]something random and include that in the
0:40:08.670,0:40:13.099
process of encrypting the message this is[br]just so that if we encrypt the same
0:40:13.099,0:40:19.030
content same message twice, we do not get[br]the same ciphertext. This is not nothing
0:40:19.030,0:40:23.090
secret because as you can see at the[br]output the library actually gives us
0:40:23.090,0:40:27.770
ciphertext, Roland talked a bit about that[br]what it is and it'll also give you it was
0:40:27.770,0:40:32.690
a MAC and I'll just stick with a very[br]simple definition of what that is, it is
0:40:32.690,0:40:38.069
something that ensures that there's kind[br]of a checksum so someone getting looking
0:40:38.069,0:40:43.359
at the cipher text and the MAC can ensure[br]no one tampered with the cipher text so
0:40:43.359,0:40:50.280
the cipher text is still in the state when[br]it was, when we sent it and if we want to
0:40:50.280,0:40:54.859
transmit our message now in encrypted form[br]to someone, we have to include the nonce,
0:40:54.859,0:40:58.060
the nonce is not secret, we can just send[br]it along with the cipher text, but to
0:40:58.060,0:41:04.690
decrypt we need the nonce and well so this[br]is what we might use for encryption, but
0:41:04.690,0:41:07.420
as you might remember from Roland's[br]introduction, this scheme
0:41:07.420,0:41:17.460
does not offer us any forward or future[br]secrecy and we can still try to to add
0:41:17.460,0:41:24.410
some form of forward to future secrecy to[br]this scheme and this is usually done,
0:41:24.410,0:41:29.790
sorry for skipping with a, with something[br]something called a handshake and
0:41:29.790,0:41:36.250
handshakes are a system of discarding old[br]keys and agreeing agreeing a new keys,
0:41:36.250,0:41:42.960
this is usually what we do with the[br]handshake and scenarios like this and
0:41:42.960,0:41:48.309
doing a handshake with someone that is not[br]online at the moment is pretty difficult
0:41:48.309,0:41:52.559
there are protocols to do that; the signal[br]messaging for app, app for example does
0:41:52.559,0:41:57.340
something like that but it's kind of[br]complicated and threema's protocol spares
0:41:57.340,0:42:02.140
the effort and only does this kind of[br]handshake with the Threema servers because
0:42:02.140,0:42:07.150
they are always online, we can always do a[br]handshake with them, so Threema has some
0:42:07.150,0:42:13.160
form of forward secrecy on this connection[br]to the messaging server and how this is
0:42:13.160,0:42:19.589
achieved, I'll try to present to you right[br]now and we walk through this handshake
0:42:19.589,0:42:27.559
step by step and I try to put some focus[br]on what every step tries to achieve, so if
0:42:27.559,0:42:31.319
we initiate a connection, if we start[br]sending a message the threema app will
0:42:31.319,0:42:35.270
connect to the to the messaging server and[br]start the connection by sending a client
0:42:35.270,0:42:43.109
hello, this is a very simple packet. It is[br]only there to communicate the public key
0:42:43.109,0:42:48.190
we from now on intend to use[br]and a nonce prefix in this case
0:42:48.190,0:42:54.140
notice it is I'd say half a nonce and the[br]other part is some some kind of a counter
0:42:54.140,0:43:01.819
that will during the ongoing communication[br]always be increased by one. So but it'll
0:43:01.819,0:43:08.140
do no harm if you just see it as a nonce[br]right now, so we start the conversation by
0:43:08.140,0:43:12.740
saying "hey, we want to use a new key pair[br]from now on and this is our public key,
0:43:12.740,0:43:17.410
please take note" and the server will[br]react by saying "okay, I need a fresh key
0:43:17.410,0:43:23.859
pair as well then", generate a fresh key[br]pair and let us know what it's public key
0:43:23.859,0:43:33.260
from now on is. The only thing to note is,[br]I mean as you can see there is, there's
0:43:33.260,0:43:38.589
not much more than then the things[br]the client sent
0:43:38.589,0:43:42.689
corresponding things from the server side,[br]but there's also the client nonce
0:43:42.689,0:43:47.920
included, so so as we can we can see this[br]is actually a response to our client hello
0:43:47.920,0:43:54.020
we just sent, not something that got, I[br]don't know redirected to us on accident,
0:43:54.020,0:44:00.180
whatever. And as you can see the latter[br]part of the message including the server's
0:44:00.180,0:44:06.339
public key is encrypted that's what what[br]this bracket saying ciphertext says and it
0:44:06.339,0:44:13.089
is encrypted with the server's long-term[br]secret key and our ephemeral temporary key
0:44:13.089,0:44:18.490
and by doing so, the server does something[br]only the person in possession of the
0:44:18.490,0:44:23.280
service long-term secret key can do and[br]proves to us, this public key we just
0:44:23.280,0:44:27.869
received from the server, in this server[br]"hello", has actually been been sent by
0:44:27.869,0:44:31.940
the proper threema server, no one can[br]impersonate the threema server at that
0:44:31.940,0:44:42.430
point, so, after that we are at a point[br]where the client application knows, this
0:44:42.430,0:44:45.830
is the public key threema server wants to[br]use and it's actually the threema server,
0:44:45.830,0:44:49.880
not someone impersonating it, the server[br]know was there is someone who wants to
0:44:49.880,0:44:54.599
talk to me using this public key, but[br]knows nothing else it doesn't know who's
0:44:54.599,0:44:59.220
actually talking to him and this is going[br]to change with the next packet, because
0:44:59.220,0:45:05.700
the threema app is going to, to now send a[br]client authentication packet, we call it
0:45:05.700,0:45:10.940
that way, which includes information about[br]the client, the first thing is the threema
0:45:10.940,0:45:17.730
ID , the threema IDs are eight character[br]strings, it's just uppercase letters and
0:45:17.730,0:45:24.520
numbers and what follows is a user agent[br]string which is not technically necessary
0:45:24.520,0:45:28.820
for the protocol, it's something the[br]threema app sends, it includes the threema
0:45:28.820,0:45:34.640
version, your system; Android iOS and[br]your, in case of Android, the Android
0:45:34.640,0:45:41.960
version and stuff like that so it's very[br]similar to user agent in web browsers,
0:45:41.960,0:45:49.560
yeah. I don't know why they sent it, but[br]they do and the rest of it is nonces.
0:45:49.560,0:45:54.040
Let's get skip over them, but also the[br]client's ephemeral public key we already
0:45:54.040,0:45:58.160
sent in the client hello but this time[br]encrypted
0:45:58.160,0:46:01.859
with our long-term secret key, so we just[br]repeat what the server just did, proving
0:46:01.859,0:46:06.400
by encrypting with our long-term key,[br]proving that we are, who we claim to be
0:46:06.400,0:46:12.170
and that we vouch that we really want to[br]use this, this temporal key and after that
0:46:12.170,0:46:17.050
happens each party knows, what public key[br]what new keypair the other party wants to
0:46:17.050,0:46:23.420
use from now on and that the other party[br]is actually who they claim to be and so
0:46:23.420,0:46:25.910
the handshake is just concluded[br]by the server
0:46:25.910,0:46:29.880
sending a bunch of zeros and grouped[br]encrypted with the newly exchanged key
0:46:29.880,0:46:34.800
pairs. This is just so the client can[br]decrypt it, see it as a bunch of zeros,
0:46:34.800,0:46:40.990
everything worked out, we have a working[br]connection now so if we've done that we
0:46:40.990,0:46:46.930
have this, we have, if you remember this[br]picture, we have established forward
0:46:46.930,0:46:51.700
secrecy in the paths between the app and[br]the server we do not have established
0:46:51.700,0:46:55.839
anything for the inner crypto layer, which[br]is in case of threema, just taking
0:46:55.839,0:46:59.619
messages encrypting them with the salt[br]library and sending them over the wire.
0:46:59.619,0:47:04.550
There's nothing more to it, it's just as I[br]showed you the scheme before, used in a
0:47:04.550,0:47:11.650
very simple way so we now have channels[br]established and we can communicate via
0:47:11.650,0:47:17.579
those and the next step I want to look at,[br]what we are actually sending via this
0:47:17.579,0:47:24.069
channels and so I'm introducing the[br]threema packet format and this is the
0:47:24.069,0:47:28.950
format packets do have, that your[br]application sends to the threema service,
0:47:28.950,0:47:36.190
this is what if what the threema server[br]sees, in this case it is the form a packet
0:47:36.190,0:47:42.540
has if it's something I want to send to a[br]communication partner, for example, the
0:47:42.540,0:47:45.710
content could be a text message[br]I want to send to someone.
0:47:45.710,0:47:50.250
There are different looking messages for,[br]for management purposes, for exchanges
0:47:50.250,0:47:55.240
with the server, that will never be[br]relayed to someone else, but this is the
0:47:55.240,0:48:01.250
the most basic format we use when sending[br]images, text to, to communication parts
0:48:01.250,0:48:06.780
and as you can see there's a packet type,[br]its purpose is kind of obvious and what
0:48:06.780,0:48:12.180
follows is the fields on the envelope as[br]Roland introduced, it's saying "this is a
0:48:12.180,0:48:17.140
message from me"[br]from Alice to Bob and so you recall the
0:48:17.140,0:48:21.390
server can see that, what follows is a[br]message ID this is just a random ID
0:48:21.390,0:48:27.630
generated when sending a message, follows[br]a timestamp so the server knows this is a
0:48:27.630,0:48:33.340
recent message that has been stuck in[br]transit for a long time, whatever.
0:48:33.340,0:48:38.750
What follows is some things to threema[br]specific, threema does have public
0:48:38.750,0:48:45.440
nicknames, it's just an alias for, for[br]your account you can set that in the app
0:48:45.440,0:48:50.491
and if you do it actually gets transmitted[br]with every message you send, so if you
0:48:50.491,0:48:56.230
change it, your name will change at your[br]communication partners phone with the
0:48:56.230,0:49:04.569
first message you sent to them and what[br]follows is a nonce and that is the nonce
0:49:04.569,0:49:08.960
used to encrypt the cypher text as[br]follows, the cypher text you see down
0:49:08.960,0:49:14.990
below is the inner envelope, as in[br]Roland's earlier pictures and we're now
0:49:14.990,0:49:22.340
going to look at what is in this envelope,[br]how do the messages look we transmitted to
0:49:22.340,0:49:28.610
our end-to-end communication partners and[br]the most simple thing we could look at is
0:49:28.610,0:49:35.670
a text message and you can see grayed out[br]above, still all the stuff from the outer
0:49:35.670,0:49:41.140
envelope and down below it's very simple,[br]we have a message type it's just one byte
0:49:41.140,0:49:46.619
indicating in this case that it is a text[br]message and what follows is text.
0:49:46.619,0:49:55.400
It's nothing more, it's just plain plain[br]text and after that, noteworthy maybe is
0:49:55.400,0:50:01.200
padding and this padding is as you can see[br]in the most inner encryption layer so the
0:50:01.200,0:50:06.300
threema server does not know how big your[br]your actual messages are, this is kind of
0:50:06.300,0:50:10.630
useful because there's stuff like typing[br]notifications you send to your
0:50:10.630,0:50:18.619
communication partners, which are always[br]the same size and to make this, to hide
0:50:18.619,0:50:24.030
this from the threema servers, we have[br]this padding in the inner crypto layer.
0:50:24.030,0:50:32.819
Next I want to look at a other message[br]type, like I'd say the most, yeah, I think
0:50:32.819,0:50:37.550
one of the basic message types most people[br]use with instant messaging app is image
0:50:37.550,0:50:42.200
messages, I want to send someone an image,[br]this is something we do regularly and this
0:50:42.200,0:50:48.712
looks a little bit weird in the first on[br]the first look; because it has a message
0:50:48.712,0:50:53.389
type, we know that, we know what what it's[br]burst with the purposes follows a blob
0:50:53.389,0:50:59.740
ID, what a blob ID is, I'm going to[br]explain in a minute. Follows the size is
0:50:59.740,0:51:04.380
very basic, it's just the size of the image[br]just should be transmitted and what
0:51:04.380,0:51:10.200
follows is a key and the mandatory[br]padding, so, the questions are, what is
0:51:10.200,0:51:16.370
this blob ID what is the key ID and what[br]is this key and this is where the media
0:51:16.370,0:51:22.610
server comes into the picture. The media[br]server is, well I'll show you what happens
0:51:22.610,0:51:28.350
if you send an image message. Your app[br]will take the image you want to send,
0:51:28.350,0:51:34.950
generate a random key, encrypt this image[br]with this key and send it to the media
0:51:34.950,0:51:38.760
server and the media server will say "okay[br]I'll store this under the following blob
0:51:38.760,0:51:44.339
ID" and your app takes note of this blob[br]ID and then, we'll send this kind of image
0:51:44.339,0:51:48.830
message I just showed to you to the[br]messaging server via the messaging server
0:51:48.830,0:51:53.919
to your communication partner, your[br]communication partner opens up the message
0:51:53.919,0:51:59.010
looks at it sees a blob ID sees the key[br]and goes to the media server and says "hey
0:51:59.010,0:52:04.010
do you have a blob ID, something stored[br]under this blob ID?" and the media server
0:52:04.010,0:52:09.540
will respond "yes I do, here's the encrypted[br]stuff" and your communication partner
0:52:09.540,0:52:16.210
can take this encrypted stuff, decrypt it[br]with the key you sent and look at your image.
0:52:16.210,0:52:22.190
This is how image sending works. So right[br]now we do have the basic the basics of
0:52:22.190,0:52:26.250
modern instant messaging, we can send[br]text, we can send images, this is the
0:52:26.250,0:52:35.059
simple stuff and what I want to look at[br]next is something that most people would
0:52:35.059,0:52:41.150
want a modern messenger to have as well[br]and that is group conversations.
0:52:41.150,0:52:46.440
Group conversations essentially in threema[br]do work not very different from other from
0:52:46.440,0:52:54.079
other method messages because if you send[br]something to a group your app will just
0:52:54.079,0:52:57.790
encrypt the message several times for[br]every communication partner involved and
0:52:57.790,0:53:02.849
send it to them, but your communication[br]partners need to know, well this is a
0:53:02.849,0:53:08.809
group message and it belongs to this and[br]that group and to do so threema has group
0:53:08.809,0:53:15.780
packets and they include exactly that[br]information, they include a creator ID
0:53:15.780,0:53:21.670
which is the threema ID of the person who[br]created the group and a group ID which is
0:53:21.670,0:53:28.059
something randomly generated when creating[br]a group and after that folIows a regular
0:53:28.059,0:53:32.790
packet format; in this case a text message,[br]if it were an image message you would see
0:53:32.790,0:53:37.840
exactly the same stuff as shown in the[br]Image message before so this is how group
0:53:37.840,0:53:43.070
messages look, but we need a way to[br]introduce new groups to change names and
0:53:43.070,0:53:51.330
for that there are special packets and[br]this for example is a group "set members
0:53:51.330,0:53:55.069
message", which tells everybody there is[br]this new group and it has the following
0:53:55.069,0:54:00.590
members as you can see here there is[br]only a group ID, there is no longer a
0:54:00.590,0:54:03.880
group creator ID included and that is[br]because a threema group management
0:54:03.880,0:54:10.500
is very static, there can only be one person[br]managing a group and that is the person
0:54:10.500,0:54:14.830
who created the group. So only the person[br]who created the group can send this kind
0:54:14.830,0:54:20.670
of messages, saying there is a new member[br]in the group for example and therefore the
0:54:20.670,0:54:27.810
group creator is implicit in this case, it[br]is the sender of the message, so this is
0:54:27.810,0:54:33.260
kind of annoying because you cannot have[br]a group where everybody can have members for
0:54:33.260,0:54:39.710
example and stuff like that. Just if you[br]set a name for a group, the message looks
0:54:39.710,0:54:47.710
very similar it just doesn't include a[br]member list, but a name field. So, what I[br]
0:54:47.710,0:54:52.180
want to talk about next is something that[br]happens above all the stuff I talked
0:54:52.180,0:54:57.070
about right now, because now I show you[br]there are different kinds of packets doing
0:54:57.070,0:55:01.069
all that stuff, there there are lots of[br]more packages for all your messages for
0:55:01.069,0:55:07.030
example they look very similar to the[br]image messages, because they just I mean
0:55:07.030,0:55:11.340
we have a blob ID for the audio file and[br]stuff like that but what is kind of
0:55:11.340,0:55:17.760
interesting I thought, we thought, is that[br]above this layer of packet formats,
0:55:17.760,0:55:24.091
there's, there's also some additional stuff[br]happening and a good example for that is
0:55:24.091,0:55:30.420
how Threema handles subtitles for images,[br]you can I think a lot of modern messengers
0:55:30.420,0:55:35.810
support that at some some kind of text to[br]an image and Threema doesn't have a packet
0:55:35.810,0:55:42.429
format of a field in some kind of image[br]message for that, but they just embed the
0:55:42.429,0:55:47.630
subtitle of the image, in the actual image[br]and the acts of data of the image and send
0:55:47.630,0:55:54.920
it along. This has the advantage of being[br]compatible with Threema versions not aware
0:55:54.920,0:55:58.690
of this feature, because they can just[br]happily ignore this exif data, you won't
0:55:58.690,0:56:03.680
see the subtitle but it won't break[br]anything. It is though kind of wonky because
0:56:03.680,0:56:07.839
it's not actually a feature which is not[br]reflected in the actual packet format and
0:56:07.839,0:56:13.070
this is also very similar happening with[br]quotes, you can quote other people in
0:56:13.070,0:56:17.540
Threema you can like, mark your message[br]and say I want to quote that and in the
0:56:17.540,0:56:23.339
app it looks like like some kind of fixed[br]feature, yeah, you have this message you
0:56:23.339,0:56:28.559
quoted, included in your new message and[br]it looks like like it's somehow linked to
0:56:28.559,0:56:36.050
the old message, but in reality it's just[br]a text message, including some markdown,
0:56:36.050,0:56:42.349
which if you're Threema version supports[br]this this kind of stuff, is rendered
0:56:42.349,0:56:46.809
nicely as is shown below, but if your[br]version doesn't support it, you'll just
0:56:46.809,0:56:50.990
see the plain text.[br]So again, being compatible with versions
0:56:50.990,0:57:01.039
that don't have it introduces some, yeah,[br]weird layer. And with that, I'll stop
0:57:01.039,0:57:07.680
showing you all the features Threema has.[br]There's certainly more to talk about, but
0:57:07.680,0:57:16.550
I think you should have an idea how how it[br]works in basic terms. What it does; all
0:57:16.550,0:57:21.880
the other stuff is kind of similar to what[br]I showed you and differs in
0:57:21.880,0:57:27.619
particularities which aren't so important[br]I think and I'll just hand over to Roland
0:57:27.619,0:57:34.089
who'll be wrapping up our talk and say[br]something about the results of our reverse
0:57:34.089,0:57:36.294
engineering.
0:57:36.294,0:57:45.440
Applause
0:57:45.440,0:57:50.300
Roland: Okay, we told you we reversed the[br]app and we told you we weren't the first
0:57:50.300,0:57:58.980
ones and this is all true. But we came[br]here to tell you guys or to make you guys
0:57:58.980,0:58:04.839
aware of things you can expect from[br]messaging apps, and we hope that by using
0:58:04.839,0:58:10.369
Threema as an example we have we have[br]shown you how you can relate your own
0:58:10.369,0:58:14.109
privacy expectations to different apps and[br]we also hope we gave you enough
0:58:14.109,0:58:20.559
terminology and explanation to that so you[br]can make a more more competent decision
0:58:20.559,0:58:28.480
next time you look at a messenger and look[br]at what its promises are. Since we
0:58:28.480,0:58:33.880
reversed it anyway and we did a lot of[br]coding to do that what we did is put it in
0:58:33.880,0:58:39.960
a library. Now, I don't know how many of[br]you guys know the term academic code
0:58:39.960,0:58:45.970
Laughter[br]We are of course we are of course I'm
0:58:45.970,0:58:50.709
working at a university, so we've been[br]doing this on and off for for quite some
0:58:50.709,0:58:55.320
time. We started roughly two years ago,[br]did it for a couple of days then left it
0:58:55.320,0:59:00.569
lying around. Eventually we had the whole[br]thing lying in a drawer for about a year
0:59:00.569,0:59:05.859
before we decided to finish it so we we[br]didn't we never actually put a lot of
0:59:05.859,0:59:09.790
effort into the code. We are not[br]proficient programmers. But we still
0:59:09.790,0:59:15.130
wanted to we still wanted to publish what[br]we did with the hopes that a small
0:59:15.130,0:59:21.980
community might form around this, maybe[br]extend it, help us you know fix the few
0:59:21.980,0:59:25.849
things that we didn't do so well, help us[br]document it - you don't have to take
0:59:25.849,0:59:32.910
photographs by the way will will upload[br]the slides. So these repositories they
0:59:32.910,0:59:38.230
exist we push to them we made a GitHub[br]organization that we push to them
0:59:38.230,0:59:43.289
yesterday. If you wanted to look if you[br]wanted to start coding right away, say if
0:59:43.289,0:59:47.209
you wanted to write a bot, we'd recommend[br]you wait a few weeks say two to three
0:59:47.209,0:59:51.830
because we still want it like, fix a few[br]of the kinks in there. Everyone else we
0:59:51.830,0:59:56.579
hope will just look at it, maybe this will[br]help your understanding of what actually
0:59:56.579,1:00:04.260
does. And also the activists in us hope[br]that this might get the people at Threema
1:00:04.260,1:00:08.329
to open-source their code because no[br]matter what we tell you here, and no
1:00:08.329,1:00:11.690
matter what they tell you how their their[br]app actually works - and this is always
1:00:11.690,1:00:15.950
true for non open-source software, there[br]will never be true transparency: you will
1:00:15.950,1:00:20.010
never be able to prove that what runs on[br]your phone is actually implemented the
1:00:20.010,1:00:25.531
same way we've shown you. With our library[br]you would have these guarantees, you can
1:00:25.531,1:00:30.430
actually you can definitely use it to[br]write bots if you ever wanted to do that.
1:00:30.430,1:00:34.549
Or if you just want to understand how it[br]works please go ahead and dive right into
1:00:34.549,1:00:43.780
there. Well, with that said, we thank you[br]for your attention.
1:00:43.780,1:00:58.990
Applause[br]Herald: Okay, thank you very much, Roland,
1:00:58.990,1:01:06.220
Frieder, we only have time for one[br]question, so who has a super eager
1:01:06.220,1:01:11.540
question - the signal angel is signalling.[br]Signal Angel: There's a couple of
1:01:11.540,1:01:16.930
questions, but I will pick the best one.[br]The best one was from alien: could you use
1:01:16.930,1:01:22.690
captions to inject malicious Exif data[br]into the images?
1:01:22.690,1:01:29.880
Frieder: What is malicious Exif data?[br]Signal Angel: Well some data that probably
1:01:29.880,1:01:37.420
the image passing library.[br]Frieder: What we did not do was have
1:01:37.420,1:01:42.750
looked very particular at security[br]problems in the implementation of Threema.
1:01:42.750,1:01:48.099
I could, like, and I would say this falls[br]into this department: there's also a
1:01:48.099,1:01:52.280
library handling the gif display meant and[br]stuff like that. We could have looked at
1:01:52.280,1:01:57.140
is this broken, maybe. We did not. We[br]looked at the protocol from a higher level
1:01:57.140,1:02:01.029
and, so I cannot say anything about it.[br]Signal Angel: Okay and another question
1:02:01.029,1:02:07.570
was when an non-group originating user[br]sends the group update message, what
1:02:07.570,1:02:13.529
happens?[br]Frieder: The thing is, Threema group IDs
1:02:13.529,1:02:19.839
aren't globally unique. A Threema group ID[br]only refers to a particular group together
1:02:19.839,1:02:26.569
with the group creator's ID. So if you[br]send an update group message from your
1:02:26.569,1:02:31.029
account, the app would look for a[br]different group than you intended. Because
1:02:31.029,1:02:36.930
your group ID would say I'm I'm trying to[br]update a group created by me with this and
1:02:36.930,1:02:43.930
that ID. So it won't be the group[br]you want to hijack.
1:02:43.930,1:02:47.163
Herald: Okay, very well. Another round[br]of applause for our speakers!
1:02:47.163,1:02:56.571
applause
1:02:56.571,1:03:12.741
postroll music
1:03:12.741,1:03:19.741
Subtitles created by c3subtitles.de[br]in the year 2018