A look into the Mobile Messaging Black Box
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 147 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/43848 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
00:00
Wechselseitige InformationAnalysisProtokoll <Datenverarbeitungssystem>ZahlenbereichGüte der AnpassungMessage-PassingVerklemmungMultiplikationsoperatorOffice-PaketComputeranimationVorlesung/Konferenz
01:48
Message-PassingSelbst organisierendes SystemUnrundheitApp <Programm>Protokoll <Datenverarbeitungssystem>AnalysisTelekommunikationGeradeDatenfeldMechanismus-Design-TheorieExpertensystemMereologieUmwandlungsenthalpieMAPInformationImplementierungChiffrierungComputersicherheitDatenmissbrauchErwartungswertAnalogieschlussFontVorlesung/Konferenz
04:13
Mobiles InternetComputersicherheitSystemidentifikationImplementierungArithmetisches MittelUmsetzung <Informatik>UmwandlungsenthalpieRechter WinkelMultiplikationsoperatorZweiMereologieTelekommunikationVorlesung/Konferenz
05:47
Inhalt <Mathematik>Befehl <Informatik>TelekommunikationArithmetisches MittelAuthentifikationService providerMessage-PassingUmsetzung <Informatik>IntegralBitPhysikalisches SystemPunktMereologieEinsWort <Informatik>Lesezeichen <Internet>AnalogieschlussComputersicherheitProzess <Informatik>Notepad-ComputerMultiplikationsoperatorVersionsverwaltungVorlesung/KonferenzDiagramm
10:10
AnalogieschlussErwartungswertTelekommunikationRechnernetzInhalt <Mathematik>Message-PassingUmsetzung <Informatik>AnalogieschlussCASE <Informatik>Dienst <Informatik>Message-PassingQuick-SortService providerArithmetisches MittelMapping <Computergraphik>SimulationPlastikkarteEinsZahlenbereichAuthentifikationEinfügungsdämpfungTranslation <Mathematik>MultiplikationsoperatorIntegralVorlesung/KonferenzJSON
12:27
Symmetrische MatrixChiffrierungSchlüsselverwaltungIdentitätsverwaltungMessage-PassingKryptologieTranslation <Mathematik>ErwartungswertDatenmissbrauchTelekommunikationMessage-PassingSchlüsselverwaltungIdentitätsverwaltungVirtuelle MaschineNichtlinearer OperatorGeradeRandomisierungEntscheidungsmodellOrtsoperatorAnalogieschlussDienst <Informatik>PunktChiffrierungInternetworkingComputerspielMathematikMereologiePublic-Key-KryptosystemInterrupt <Informatik>QuaderSymmetrische MatrixChiffreEin-AusgabeKryptologieService providerPrivate-key-KryptosystemRechenschieberVorlesung/Konferenz
16:47
IdentitätsverwaltungSchlüsselverwaltungMessage-PassingKryptologieSchlüsselverwaltungMessage-PassingOrtsoperatorChiffrierungPolstelleDienst <Informatik>Generator <Informatik>Public-Key-KryptosystemAdressraumSchlüsselverteilungQuaderGeradePrivate-key-KryptosystemMechanismus-Design-TheorieCASE <Informatik>WarteschlangeWeb SiteMereologieVerschlingungNummernsystemSkriptspracheAutomatische HandlungsplanungEinhüllendeSystemaufrufVorlesung/KonferenzFlussdiagramm
19:35
SchlüsselverwaltungSchlüsselverwaltungPublic-Key-KryptosystemPrivate-key-KryptosystemAsymmetrieSchlüsselverteilungBenutzerfreundlichkeitArithmetisches MittelVirtuelle MaschineSymmetrische MatrixTelekommunikationChiffrierungVorlesung/Konferenz
20:39
CASE <Informatik>SchnittmengeSchlüsselverwaltungNummernsystemDifferenteMessage-PassingMAPComputeranimationVorlesung/Konferenz
21:41
PunktSchlüsselverwaltungEinsUmsetzung <Informatik>Private-key-KryptosystemMathematikMessage-PassingSichtenkonzeptMehrrechnersystemDiagramm
22:41
Protokoll <Datenverarbeitungssystem>Konsistenz <Informatik>SchlüsselverwaltungRechter WinkelWort <Informatik>MehrrechnersystemIntegralSchlüsselverteilungAuthentifikationProtokoll <Datenverarbeitungssystem>DimensionsanalyseAdditionVorlesung/KonferenzComputeranimation
23:51
KryptologieComputersicherheitTranslation <Mathematik>Mechanismus-Design-TheorieDigital Rights ManagementComputersicherheitKryptologieTranslation <Mathematik>Digital Rights ManagementTelekommunikationMechanismus-Design-TheorieSchlüsselverwaltungPublic-Key-KryptosystemInstantiierungMessage-PassingZentralisatorSondierungInformationsspeicherungIdentitätsverwaltungVorlesung/KonferenzComputeranimation
24:53
Digital Rights ManagementE-MailAdressraumInformationProgrammverifikationMobiles InternetServerMessage-PassingChiffrierungInnerer PunktSenderServerMereologieIdentitätsverwaltungZahlenbereichService providerMapping <Computergraphik>InstantiierungE-MailInformationsspeicherungFigurierte ZahlInformationPublic-Key-KryptosystemQR-CodeMessage-PassingDickeSchlüsselverwaltungArithmetisches MittelGebundener ZustandDienst <Informatik>Virtuelle MaschineAdressraumEindringerkennungSoftwareMetadatenIdentifizierbarkeitAbfrageInnerer PunktTelekommunikationGeradeWeb-SeiteEinhüllendeMultiplikationsoperatorZeitstempelBitNotebook-ComputerFormation <Mathematik>GraphiktablettSpezielle unitäre GruppeCodierungFlächeninhaltFlussdiagramm
32:09
AnalysisDienst <Informatik>Formale GrammatikKontextbezogenes SystemMechanismus-Design-TheorieApp <Programm>BildschirmmaskeMessage-PassingRandomisierungSchnelltasteZahlenbereichSchlüsselverwaltungService providerCoxeter-GruppeReverse EngineeringEinsProtokoll <Datenverarbeitungssystem>Rechter WinkelKartesische KoordinatenMultiplikationsoperatorComputerarchitekturVorlesung/Konferenz
33:58
Architektur <Informatik>Protokoll <Datenverarbeitungssystem>TaskZahlenbereichElektronische PublikationVerzeichnisdienstBildgebendes VerfahrenApp <Programm>VideokonferenzMultifunktionCASE <Informatik>GruppenoperationKategorie <Mathematik>Einfach zusammenhängender RaumServerTelekommunikationHypermediaAdressraumMessage-PassingSondierungZählenUmsetzung <Informatik>Public-Key-KryptosystemDifferenteMinimumService providerIdentitätsverwaltungChiffrierungHyperbelverfahrenSpeicherabzugZentralisatorVorlesung/KonferenzComputeranimation
36:12
Architektur <Informatik>ServerSystemidentifikationVerzeichnisdienstE-MailProgrammverifikationPeer-to-Peer-NetzService providerCodierung <Programmierung>Elektronischer FingerabdruckAdressraumE-MailEigentliche AbbildungZahlenbereichEinfach zusammenhängender RaumVerzeichnisdienstMultifunktionExogene VariableApp <Programm>Kategorie <Mathematik>Elektronischer FingerabdruckKartesische KoordinatenSkalarproduktQR-CodePublic-Key-KryptosystemPhysikalisches SystemBitSchlüsselverwaltungServerBereichsschätzungPunktMAPBildschirmmaskeCASE <Informatik>ResultanteCodeDesign by ContractGreen-FunktionReelle ZahlUmsetzung <Informatik>Message-PassingVorlesung/KonferenzComputeranimation
38:34
CASE <Informatik>Quick-SortTelekommunikationProgrammbibliothekMessage-PassingQuaderChiffrierungChiffreMereologieSchlüsselverwaltungRandomisierungProzess <Informatik>BitAggregatzustandBildschirmmaskeIntegralInhalt <Mathematik>Funktion <Mathematik>AuthentifikationWeb SiteOntologie <Wissensverarbeitung>ComputersicherheitVorlesung/KonferenzFlussdiagramm
40:57
ClientIdentitätsverwaltungSchlüsselverwaltungTermServerProgrammverifikationNummernsystemBildschirmmaskePunktChiffrierungEinfach zusammenhängender RaumComputervirusProtokoll <Datenverarbeitungssystem>FokalpunktServerSchlüsselverwaltungClientApp <Programm>Physikalisches SystemMomentenproblemMessage-PassingMetropolitan area networkGruppenoperationFlächeninhaltStreaming <Kommunikationstechnik>Besprechung/Interview
42:34
ServerClientChiffreTelekommunikationMereologieCASE <Informatik>Public-Key-KryptosystemServerRechter WinkelClientUmsetzung <Informatik>SchlüsselverwaltungArithmetisches MittelDienst <Informatik>Exogene VariableVorlesung/KonferenzJSON
43:38
ServerSchlüsselverwaltungClientExogene VariableMereologiePoisson-KlammerPublic-Key-KryptosystemPunktFolge <Mathematik>Message-PassingTermDienst <Informatik>BeweistheorieVorlesung/KonferenzBesprechung/Interview
44:54
ChiffreServerClientAuthentifikationChiffrierungInnerer PunktVerschlingungTermClientInformationMAPTermHumanoider RoboterMultiplikationsoperatorDienst <Informatik>SchlüsselverwaltungPublic-Key-KryptosystemZeichenketteCASE <Informatik>ZahlenbereichPhysikalisches SystemComputersicherheitProtokoll <Datenverarbeitungssystem>App <Programm>AuthentifikationServerBrowserEindringerkennung
46:23
Einfach zusammenhängender RaumMessage-PassingApp <Programm>GruppenoperationServerClientPublic-Key-KryptosystemKryptologieDateiformatNummernsystemProgrammbibliothekMereologieInnerer PunktFlächeninhaltCASE <Informatik>Vorlesung/Konferenz
47:20
E-MailDateiformatZeichenketteServerBildschirmmaskeChiffreMessage-PassingInhalt <Mathematik>TelekommunikationDateiformatKartesische KoordinatenDigital Rights ManagementUmwandlungsenthalpieAliasingApp <Programm>ZeitstempelTypentheorieDatenfeldGruppenoperationBildgebendes VerfahrenCASE <Informatik>MereologieEinhüllendeEnergiedichteDechiffrierungMultiplikationsoperatorRauschenChiffrierungComputeranimation
49:11
ChiffreE-MailMessage-PassingSpezialrechnerTelekommunikationMessage-PassingEinhüllendeBildgebendes VerfahrenCASE <Informatik>App <Programm>ChiffrierungTypentheorieServerGraphiktablettHypermediaInnerer PunktBitSchlüsselverwaltungVorlesung/Konferenz
51:15
Message-PassingSpezialrechnerHypermediaInformationsspeicherungBildgebendes VerfahrenChiffrierungApp <Programm>ServerRandomisierungGruppenoperationMessage-PassingTelekommunikationInstant MessagingSchlüsselverwaltungUmsetzung <Informatik>Exogene VariableKryptologieDienst <Informatik>Computeranimation
52:39
GruppenkeimChiffreE-MailMessage-PassingDigital Rights ManagementInformationTelekommunikationApp <Programm>GruppenoperationUmsetzung <Informatik>GrenzschichtablösungMessage-PassingMultiplikationsoperatorRegulärer GraphBildschirmmaskeCASE <Informatik>Digital Rights ManagementBildgebendes VerfahrenVorlesung/KonferenzComputeranimation
54:30
GruppenkeimMessage-PassingChiffreE-MailDigital Rights ManagementSpezialrechnerImplementierungMessage-PassingZahlenbereichGruppenoperationMailing-ListeDatenfeldBildgebendes VerfahrenDifferenteAbstandBildschirmmaskeAudiodateiSystem FKontrollstrukturDateiformatAdditionVorlesung/Konferenz
55:56
Message-PassingImplementierungDateiformatKontrollstrukturVersionsverwaltungMessage-PassingWort <Informatik>App <Programm>TermVerschlingungVorlesung/Konferenz
57:12
ResultanteReverse EngineeringDifferenteErwartungswertDatenmissbrauchEinsApp <Programm>Kontextbezogenes SystemAutomatische DifferentiationTermProgrammbibliothekInhalt <Mathematik>EntscheidungstheorieMultiplikationsoperatorCodeVorlesung/Konferenz
58:36
DokumentenserverProgrammbibliothekCodeTermGrundraumMultiplikationsoperatorHilfesystemSelbst organisierendes SystemGüte der AnpassungDigitale PhotographieDokumentenserverProgrammierungComputeranimationVorlesung/Konferenz
59:43
Wurm <Informatik>Open SourceProgrammbibliothekApp <Programm>CodeQuellcodeMultiplikationsoperatorSoftwareRoboterVorlesung/Konferenz
01:01:01
ComputersicherheitBildgebendes VerfahrenInjektivitätGruppenoperationApp <Programm>DatensichtgerätMessage-PassingEindringerkennungProgrammbibliothekImplementierungProtokoll <Datenverarbeitungssystem>MAPUnrundheitKlasse <Mathematik>Vorlesung/Konferenz
01:02:44
MedianwertKartesische AbgeschlossenheitHypermediaUnrundheitVorlesung/KonferenzJSON
Transkript: Englisch(automatisch erzeugt)
00:13
Good morning, everyone. Thanks for showing up in such great numbers. That's always a good thing for such an early session.
00:23
And first of all, I would like to ask you a question. I mean, 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,
00:43
we were out of our apartment and the hotel owner let us stay in their office. But the guy who stayed there put the deadlock on, so we tried to reach him. Hm, how do we reach them? We thought about, hm, maybe he has some messaging, maybe he has some mobile number.
01:03
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.
01:21
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, oh, yeah. The talk of today.
01:42
So this morning's session starts with our speakers, Roland Schilling and Frieder Steinmetz. And they will be talking about, they will at first give you a gentle introduction
02:01
into mobile messaging. I have nine messaging apps on my phone, no, 10. The organizers forced me to install another messaging app. And after that, give you a quick analysis, or not so quick, I don't know, a deep analysis of the three mile protocol. So let's give another round of applause for our speakers.
02:29
Thank you, Tilo. I am Roland, this is Frieder. And as, well, as Tilo already introduced us, we are going to talk about secure messaging. More specifically, we are trying to give
02:42
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 those people who are using it.
03:01
So 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
03:22
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 will try to outline privacy expectations when we communicate. We are going to do that by sketching
03:42
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
04:01
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.
04:23
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,
04:42
you find a room, maybe the bedroom of the host, where nobody is in there. You enter the room, you close the door behind you, meaning you are now private. You have a one-to-one session in this room in private, and we are going to look at what that means.
05:00
First of all, the most intuitive one is what we call confidentiality, and that means that since nobody's there in the room with you, you are absolutely sure that anything you say and anything your communication partner says, if you imagine Frida and me having this conversation, can only be heard by the other person.
05:21
If that is guaranteed, 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,
05:42
and again, if I had a talk with Frida, 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.
06:01
So if this is achieved, if we can say, I definitely know who I'm talking to, there is no chance that somebody else switches in and poses off as Frida, we call this authenticity. Moving on, integrity. Integrity is a bit, this is where the analogy falls short,
06:22
well, somewhat, but basically, if I can make sure that everything I say reaches Frida exactly the way I wanted to say it, and there is no messenger in between, I'm not telling a third friend, please tell Frida something, and he will then alter the message because he remembered it wrong, or has malicious intentions.
06:47
If I can make sure that everything I say is received by Frida exactly the way I said it, then we have integrity on our communication channel. Okay, the next ones are two ones that are a bit hard to grasp at first.
07:03
Therefore, we are going to take a few minutes to look at these, and they are forward in 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.
07:20
Now, 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 they 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,
07:41
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 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,
08:01
so I'm going to take a minute to introduce it. We have a timeline that is blue. It goes from left to right. And on this timeline, we have a green bar that denotes 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.
08:21
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 secrecy.
08:43
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 achieved deniability because after we had this talk, we returned to the party and people asked us what happened.
09:02
I can always point to Frida, as you could, to your friend, and say, he said something. Frida 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.
09:24
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
09:42
if you use something more sophisticated. It could be WhatsApp, for example. It could be Apple, depending on what your favourite messenger is. But there is always, unless you use, like, federated systems, if some of you guys might think, but I'm using Jabber. I know, but we are looking at centralised systems right now,
10:00
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,
10:22
you have your phone, you see you are displayed with a 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 at something more akin to postal services.
10:44
We prepare a message, send it off, our message provider takes the message, takes it to our intended recipient, and they can then read the message. And this applies to all the messages we exchange. And to underline that, we are going to look at
11:02
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 Frida is with Verizon, I don't know,
11:21
I would send my messages to Vodafone, they would forward them to Verizon, who would then deliver it to Frida's 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,
11:42
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, there's no fixed mapping to our phones or our SIM cards.
12:02
They can be changed, they can be rerouted, so 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,
12:23
but this goes into like philosophical... 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 guarantee they did or did not do something.
12:40
So let's not dive too deeply into that discussion, but we can summarise 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,
13:00
actually our messages are more like postcards, because they are plain, our providers can look at them, can change them, 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 text, change it, postcards. And what we want to achieve now is find a way to wrap these postcards
13:22
and make them more like letters, assuming that postal services don't open letters. That's the one point with this analogy that we have to define. And to be able to do that, we're trying to give you the shortest encryption, the shortest introduction to encryption,
13:42
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,
14:01
provided we have the right key for that. So, to stick with a very simple example, please imagine this box that we've just labelled 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 plain text and the key, and it produces something that we call cipher text.
14:20
Cipher text is undistinguishable from random text, but it can be reversed at the recipient's side using the same key and basically the same machine just doing the operation in reverse, turning cipher text back into plain text. This is what we call symmetric encryption,
14:44
because if you imagine a line where the cipher text is, you could basically mirror the thing onto the other side, so it's symmetric at that line. And when there's something that is called symmetric, there is also something that is called asymmetric,
15:01
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.
15:22
You can do it both ways, but the important thing to memorise here is just anything I encrypt with the yellow key can only be decrypted with the blue key. OK. Since we have that now,
15:41
let's capitalise 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,
16:03
traditional public key cryptography. We've added something that is called an identity in this picture. We will get back to that in a minute. But the scenario 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,
16:22
and keep their secret key as the name says, secret. Some of you might know this as a private key. It's the same concept applies. We just chose to call it a secret key. Because it more clearly denotes that it's actually secret and never published.
16:43
So this would mean any message that would be encrypted with one of the parties' public key could then only be decrypted with that party's secret key, putting us in a position where I could take Frida'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
17:02
as long as his secret key remains his, well, secret, and he doesn't publish it. Well, the problem is, this is a very, well, the problem is it's a very expensive scenario. We get something akin to a postal service
17:23
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,
17:40
they would see who it is from and who it is 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,
18:00
especially hard to do on small devices like phones. So what 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
18:20
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're looking at right now works the following way. You can take one of the secret keys and another public key,
18:41
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 linking, it doesn't matter if you take, in this case, let's call them Alice and Bob,
19:00
if you take Alice's secret key and Bob's public key, or Bob's secret key and Alice's public key, you would 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
19:21
than asymmetric encryption. So this has one advantage and one disadvantage. The advantage, I've already said, is that it's way cheaper. And the fact, well, the advantage is also that we come up with a key on both sides, and the disadvantage is that we come up with one key on both sides,
19:43
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 that means, but it is very expensive.
20:03
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.
20:23
Meaning we have now basically achieved confidentiality. We can use these keys, put them in the machines without plaintext, get ciphertext, you know, we are able to transport it to the other side. Nobody can look inside. Confidentiality is achieved. Now, deniability.
20:42
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,
21:02
this was sent by me or this was sent by Frida, 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 a different set of keys to generate them, basically the same key can be generated on both sides,
21:23
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?
21:40
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
22:01
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 at the point where the key was compromised,
22:24
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,
22:42
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 Frima in more detail. Yeah, if we had a way to dump keys
23:04
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,
23:20
and if you've stuck with us, you would realise 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 Frima, it actually does have integrity. Now, basically, you could think we fixed everything,
23:43
but you heard us talk about things like IDs, and we haven't really lost a few words about them, or lost many words about them, and we are 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.
24:04
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 Frida has a private key, a secret key, I'm sorry, and a public key.
24:20
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 have used PGP, for example, in the last couple of decades, know what I'm talking about.
24:41
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 in between us, we can now query this instance. I can now take my public key and my identity,
25:02
tell the messaging server, hey, messaging server, this is my identity, please store it for me, so that Frida, who has some kind of information to identify me, can then query you, get my public key back. This, of course, assumes that we trust the messaging server.
25:20
We may or may not do that. But for now, we have a way to at least communicate our public keys to other parties. Now, what can we use as identities here? In our 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
25:43
and what his public key is. And the same thing works the other way. 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.
26:01
And something else will be the interesting part, but let's look at the 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,
26:24
and I, for one, have my phone number, and I mean the same phone number I've had for 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 my cryptographic identity that is bound to my keys,
26:43
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, email addresses. Email addresses basically are also personal information. They are a bit shorter-lived, as we would argue,
27:01
than phone numbers, and you can use temporary emails. You can do a lot more. You're way more flexible with emails. But ideally, we want to have something that we call dedicated IDs, meaning something that identifies me only within the bounds of the service that we use. So that's what we want to have.
27:21
We're 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...
27:41
Well, I have to find a way to verify which one is maybe the right one, maybe the one that is actually used. Maybe Frida has used quite a number of public keys. He's a lazy guy. He forgets to take his keys from one machine to the other. He just buys a new laptop, sets up a new public key. Bam, he has two. Which one am I supposed to use right now?
28:02
Now, remember that we are looking at the messenger server for 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,
28:22
and verify our keys independently. We've chosen QR codes here. Frida uses QR codes. Many other messengers do as well, and we want to tell you why this is an important feature, to be able to verify our public keys independently of the messaging server, because once we did that, we no longer have to trust the messaging server
28:43
to tell us, or 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,
29:02
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,
29:21
and we'll 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 look at timestamps and stuff like that,
29:43
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,
30:00
wrapping it into a third envelope, and then sending that to the messenger server first, and the messenger server gets a lot of envelopes, and they are all just addressed to the messenger server, so anyone on the network would basically see there's one party sending a lot of messages to the messenger server, maybe there are a lot of parties,
30:21
but they couldn't look at the end-to-end, as we call a channel, seeing what the addresses on each internal envelope are. The messaging server, however, can. They would open 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,
30:43
this is a message from the messaging server and it is directed to Alice. Who would then be able to open the outer envelope, open the inner envelope, see this is actually a message from Bob, and what we have thereby achieved is a two-layer, end-to-end communication tunnel,
31:00
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 communication partners directly. But, and we've had this caveat before,
31:23
the messaging server still knows both communication partners, they still know the times that the messages were sent at, and they also know the size of the message, but we can do something against that. And what we do is introduce padding, meaning in the inner envelope,
31:41
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 never have the same length twice,
32:01
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 of you who stuck around, we are now moving on to analyse Frima. Now, I want to say a few things before we do that.
32:20
We are not affiliated with Frima, we are not here to recommend 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
32:41
of the mechanisms that are in use, and we have chosen basically a random message provider, we could have chosen anyone. And we chose Frima 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.
33:03
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 who have done this, we are also not the first ones who have done this, and we don't claim we are. But we are here now and we want to try to make you aware
33:22
of the inner workings of the app as far as we have understood it. And with that, I hand the presenter over to Frida. We will dive right into that. Well, so I will be presenting to you
33:45
our understanding of the Frima 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,
34:00
but 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 while Roland was giving you this abstract introduction to mobile messaging, there was always this third party,
34:22
this messaging provider. And this now became actually three entities, because Frima has three different servers, mostly, doing, well, very different stuff for the apps working. And I'll start with the directory server in orange
34:43
at the bottom, because that is the server you most likely will be 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,
35:00
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 Frima ID, what's the corresponding public key, for example, and stuff like that. Above that, there is the messaging server, which is kind of the core central entity
35:22
in this whole scenario, because its 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 purpose is storing large media files,
35:43
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 Frima, this directory server offers a REST API, so communication with this server
36:01
happens via HTTP, it is HTTPS actually, so it's TLS encrypted, and this encryption also fulfils all the requirements you would have to a proper TLS connection. And so if you want to communicate with a new person
36:22
and you have their phone number or their email address or a Frima ID, your app will be asking the directory server, hey, I have this phone number, do you have a corresponding Frima account and public key? And the response will hopefully be, yes, I do, that's a public key, that's a Frima ID, go ahead.
36:41
And as Rohan said, we kind of chose Frima 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 Frima has
37:04
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 Frima ID, what is the corresponding public key? The Frima application will say, okay, I got an answer from the directory server,
37:21
I have a public key, but I have very little trust that you actually know who the real person at this Frima 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 Frima account and public key?
37:42
The app will say, okay, 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 Frima server.
38:01
So it'll mark a contact like that with two orange dots. And then there is the final stage. If you met someone in person and scanned their public key and Frima 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.
38:23
We're talking to the person we want to talk to and we have the proper keys. So right now, if we think of engaging a conversation, we're at the point where we do have all necessary details to start encrypting our communication. But the question remains, how do we encrypt our communication?
38:43
In the case of Frima, Frima uses a library called Salt. It has been developed by Daniel Bernstein and he called it Salt, but it's spelled N-A-C-L. So I'm sorry for the play on words, but if you see N-A-C-L, it's Salt.
39:03
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 necessary features we want. And this is Salt offers authenticated encryption,
39:23
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 on how this library would be used. As you can see up there,
39:41
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 recipient's public key, our message. So far, very obvious. And the library also requires a nonce, which is something that should be only used once.
40:03
That's actually 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, the same message twice, we do not get the same ciphertext. This is nothing secret, because as you can see at the output,
40:22
the library actually gives us ciphertext. Roland talked a bit about that, what it is. And it also gives us a MAC, and I'll just stick with a very simple definition of what that is. It is something that ensures that there is kind of a checksum, so someone looking at the ciphertext and the MAC can ensure no one tampered with the ciphertext.
40:43
So the ciphertext 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 ciphertext, but to decrypt, we need the nonce.
41:01
And, well, so this is what female uses 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 add some form of forward or future secrecy to this scheme,
41:22
and this is usually done, sorry for skipping, with something called a handshake. And handshakes are a system of discarding old keys and agreeing on new keys. This is usually what we do with a handshake in scenarios like this.
41:41
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 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
42:00
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'll walk through this handshake step by step, and I'll try to put some focus
42:22
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 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
42:43
which 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 kind of a counter that will, during the ongoing communication, always be increased by one.
43:01
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
43:22
what its public key from now on is. The only thing to note is, I mean, as you can see, there's not much more than the things the client sent, just the corresponding things from the server side, but there's also
43:42
the client nonce included, so as 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 or whatever. And as you can see, the latter part of the message, including the server's public key, is encrypted.
44:02
That's what this bracket saying self-attacks 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 server's long-term secret key can do, and proves to us,
44:22
this public key we just received from the server, in this server hello, has actually been sent by the proper three-month server. No one can impersonate the three-month server at that point. So, after that, we are at a point where the client
44:40
application knows this is the public key the three-month server wants to use, and it's actually the three-month server, not someone impersonating it. The server knows 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 three-month app is going to now send
45:03
a client authentication packet, we call it that way, which includes information about the client. The first thing is the three-month ID. Three-month IDs are eight-character strings, it's just uppercase letters and numbers. What follows is a user-agent string,
45:22
which is not technically necessary for the protocol. It's something the three-month app sends. It includes the three-month 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.
45:42
Yeah, I don't know why they sent it, but they do. And the rest of it is non-sys, let's 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,
46:02
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 temporal key. And after that happens, each party knows what public key, what new key pair the other party wants to use from now on, and that the other party is actually who they claim to be.
46:22
And so the handshake is just concluded by the server sending a bunch of zeros encrypted with the newly-exchanged key pairs. This is just as the client can decrypt it, see there's a bunch of zeros, everything worked out, we have a working connection now. So if we've done that, we have this,
46:43
if you remember this picture, we have established forward secrecy in the parts between the app and the server. We do not have established anything for the inner crypto layer, which is, in case of three, not just taking messages, encrypting them with the salt library and sending them over the wire. There's nothing more to it, it's just,
47:02
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 in the next step, I want to look at what we are actually sending via these channels. And so I'm introducing the three-month packet format.
47:22
And this is the format packets do have that your application sends to the three-month servers. This is what the three-month server sees. In this case, it is the form a packet has if it's something I want to send to a communication partner.
47:41
For example, the content could be a text message I want to send to someone. There are different looking messages for management purposes, for exchanges with the server that will never be relayed to someone else. But this is the most basic format we use when sending images, text to communication partners.
48:01
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 Ronald introduced, is saying, this is a message 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.
48:24
Follows a time stamp. So the server knows this is a recent message, has been stuck in transit for a long time, whatever. What follows is something three-month specific. Three-month does have public nicknames. It's just an alias for your account.
48:43
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 partner's phone with the first message you send to them. And what follows is a nonce.
49:03
And that is the nonce used to encrypt the ciphertext as follows. The ciphertext 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 inner envelope. What is, how do the messages look?
49:21
We transmit to our end-to-end communication partners. And the most simple thing we can look at is a text message. And you can see greyed 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,
49:41
indicating in this case that it is a text message. And what follows is text. There's nothing more, it's just plain text. And after that, noteworthy maybe is padding. And this padding is, as you can see, in the most inner encryption layer.
50:01
So the three-month server does not know how big 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 three-month servers,
50:20
we have this padding in the inner crypto layer. I want to look, next I want to look at 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.
50:42
And this looks a little bit weird on the first look, because it has a message type, we know that, we know what its purpose is. It follows a blob ID, what a blob ID is, I'm going to explain in a minute, follows the size. This is very, basically it's just the size of the image,
51:02
it 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
51:23
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,
51:42
and then will send this kind of image message I just showed to you via the messaging server to your communication partner. Your communication partner opens up the message, looks at it, sees the blob ID, sees the key, and goes to the media server and says, hey, do we have a blob ID,
52:01
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 basics
52:22
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.
52:41
Group conversations essentially in Threema do work not very different from other 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,
53:02
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
53:23
when creating a group. And after that follows 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,
53:43
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,
54:03
and that is because Threema's 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.
54:24
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.
54:41
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 showed you there are different kinds of packets doing all that stuff. There are lots of more packages for audio messages, for example.
55:02
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, we thought, is that above this layer of packet formats, there is also some additional stuff happening,
55:21
and a good example for that is how Frima handles subtitles for images. You can, I think a lot of modern messengers support that, add some kind of text to an image. And Frima doesn't have a packet format or a field in some kind of image message for that, but they just embed the subtitle of the image in the actual image,
55:45
and the acts of data of the image and send it along. This has the advantage of being compatible with Frima versions, not aware of this feature, because they can just happily ignore this acts of data. You won't see the subtitle, but it won't break anything.
56:01
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 Frima. You can mark a message and say, I want to quote that. And in the app, it looks like some kind of fixed feature.
56:22
You have this message you quoted included in your new message, and it looks like it's somehow linked to the old message. But in reality, it's just a text message including some markdown, which, if your Frima version supports this kind of stuff,
56:41
is rendered nicely, as shown below, but if your version doesn't support it, you will just see the plain text. So, again, being compatible with versions that don't have it introduces some weird layer. And with that, I will stop showing you all the features Frima has.
57:05
There's certainly more to talk about, but I think you should have an idea how it works in basic terms, what it does. All the other stuff is kind of similar to what I showed you
57:20
and differs in particularities, which aren't so important, I think. And I will just hand over to Roland, who will be wrapping up our talk and say something about the results of our reverse engineering.
57:45
OK. We told you we reversed the app, and we told you we want 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,
58:02
and we hope that by using Frima as an example, 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 competent decision next time you look at a messenger
58:22
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.
58:43
We are, of course, I'm working at a university, so we've been doing this on and off for quite some time. We started roughly two years ago, did it for a couple of days, then left it lying around, and eventually we had the whole thing lying in a drawer for about a year before we decided to finish it,
59:02
so we never actually put a lot of effort into the code. We are not proficient programmers, but we still wanted to publish what we did with the hopes that a small community might form around this, maybe extend it, help us fix a few things that we didn't do so well,
59:24
help us documenting it. You don't have to take photographs, by the way. We'll upload the slides. So, these repositories, they exist. We pushed to them, we made a GitHub organisation that we pushed to them yesterday. If you wanted to start coding right away,
59:43
say if you wanted to write a bot, we'd recommend you wait a few weeks, say two to three, because we still want to 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 it actually does.
01:00:00
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 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.
01:00:22
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, and I hope that I have some news.
01:00:54
Okay. Thank you very much, Roland and Frida. Well, we only have time for one question, so who has a super eager question?
01:01:09
The signal angel is signalling, so we'll be available anyway. I will pick the best one. The best one was from Alien. Could you use captions to inject malicious Exif data into the images?
01:01:23
What is malicious Exif data? Well, some data that probably the image passing library. What we did not do was have looked very particular at security problems in the implementation
01:01:42
of Threema. I could, like, and I would say this falls into this department. There's also a library handling the GIF displayment 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. Okay, and another question was when a non-group originating user sends the group update message,
01:02:07
what happens? Okay, shall I answer? 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.
01:02:22
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 trying to update a group created by me with this and that ID. So it won't be the group you want to hijack.
01:02:44
Okay, very well. Another round of applause for our speakers.