 Guten Morgen und vielen Dank, dass ihr um diese Zeit schon so fielstählich erschienen seid. Als erstes möchte ich eine Frage stellen. Gestern Abend hatte ich eine komische Erfahrung mit einer verschlossenen Tür. Wir sind aus unserer Wohnung rausgeblieben und der Hotelbesitzer hat uns in seinem Büro übernachten lassen. Und dann haben wir gestern Abend seine Messaging und seine Mobile-Nummer gesucht, weil wir uns rausgesperrt hatten. Und er war auf dem Festnetz nicht zu erreichen. Und dann haben wir in der Bar gesucht. Und dann sind wir in der Bar rumgelaufen und haben ihn dort gesucht. Und mit Mobile-Messaging wäre das nicht passiert. Und ansonsten hätten wir vielleicht eine Stunde mehr geschlafen, aber hätten das mit der Bar verpasst. So, jetzt lasst uns mal anfangen. Die Vortragenden sind Roland Schilling und Frieda Steinmetz. Und sie werden eine einfache Einführung in Mobile-Chatten geben. Und wenn sie das gemacht haben, werden sie eine tiefe Analyse des Trima-Protokolls geben. Bitte einmal Applaus. Danke, Tilo. Ich bin Roland, das ist Frieda. Und wie Tilo uns schon angekündigt hat, reden wir über Mobile-Messaging. Das ist für eine ganz breite Einführung. Das Feld ist sehr komplex, und wir werden das versuchen, hier massentauglich zu machen. Und jetzt werden wir versuchen, das, was die Leute jeden Tag zu benutzen, auch ein bisschen transparenter zu machen. Um das zu machen, fangen wir ganz niedriger an. Die Sicherheits- und Krypto-Nerds in diesem Raum werden feststellen, dass sie eine Menge schon wissen. Die müssen aber ein bisschen sich gedulden. Der erste Teil, der ist speziell dafür da, die Mechanismen auch in den Grundlagen unserer Neuankommegie zu vermitteln. Was wir heute versuchen, sind drei Sachen. Wir werden Erwartungen an Privatsphäre erklären. Dann werden wir Kommunikations-Szenarien beschreiben, die man davon ableiten kann. Wir suchen nach einer Analogie, wie man das auf mobiles Messaging abbilden kann. Und dann suchen wir nach technischen Lösungen, die das wirklich machen. Und dann suchen wir nach etwas, was uns die gleiche Privatsphäre geben würde, wie eine 1 zu 1-Zimmderhaltung. Und insbesondere werden wir Trema anschauen. Jetzt fahren wir direkt mal an. Du bist bei einer Party. Du bist ein Hausvolle-Leute. Und dann kommt jemand auf dich zu und sagt, er möchte sich mit dir persönlich unterhalten. Was ist die Erwartung? Wir suchen einen separatesten Zimmer, vielleicht das Schlafzimmer vom Gastgeber. Und dann schließen wir die Tür. Und dann haben wir das Gefühl, dass wir uns privat unterhalten können. Und wir schauen mal, was das heißen wird. Als Erstes sind wir, das Erste ist Konfinenzialität, also Privatheit. Und wir sind alleine in dem Raum. Und wir sind uns sicher, dass das, was ich und der Kommunikationspartner sage, nur von der anderen Person, die weiß gehört werden kann. Und in der IT-Sicherheit nennen wir das Konfinenzialität. Der zweite Teil ist, die zweite Erwartung oder die zweite Versprechung, was wir machen, ist, dass wir wissen, mit wem wir reden. Ich weiß, wir auch. Und ich weiß genau, wer mein Kommunikationspartner ist. Und das Gleiche gilt natürlich auch umgekehrt. Und wenn wir uns beide sicher sind, mit wem wir uns unterhalten, dann nennt man das Authentizität. Weiter geht es mit Integrity. Das ist jetzt ein bisschen schwierig, weil die Analogie hier ein bisschen zusammenbricht. Wenn ich sicherstellen kann, dass alles das, was ich sage, so anbricht, dann ist das das Gleiche. Das ist das Gleiche. Das Gleiche. Wenn ich das sicherstellen kann, dass alles das, was ich sage, so ankommt, wie ich sage, und niemand dazwischen ist, der das vielleicht verändern würde, dann, wenn ich das sicherstellen kann, wenn ich das so sicherstellen kann, dass alles, was ich sage, unverändert auf der anderen Seite ankommt, dann ist das Gleiche. Das Gleiche. Die nächsten zwei Minuten sind in der meiner Meinung ein bisschen kompliziert. Dafür nehmen wir uns jetzt ein paar Minuten. Das ist eineseits Forward Secrecy, eine zukünftige Secrecy, Future Secrecy. Nehmen wir an, jemand geht in den Raum, während wir uns unterhalten und bleibt während einer gewissen Zeit da und das ist ein Punkt, als die Personen in den Raum getreten sind. Sie nichts darüber lernen müssen, was wir vorher besprochen haben. Sie kommen in den Raum rein. Und alles, was Sie hören, ist der Teil des Gesprächs, den Sie mithören, während Sie drin sind. Sie wissen also nichts von dem, was wir vorher besprochen haben. Dann haben wir Forward Secrecy. Wir haben wieder verlassen, Sie auch nichts mehr mitbekommen. Dann haben wir Future Secrecy. Weil es ein bisschen komplizierter zu verstehen ist, haben wir hier das Ganze grafisch aufgezeigt. Wir werden die wieder zurückholen, wenn wir mehr darüber sprechen. Wir haben die Timeline, die blau ist, von links nach rechts und darin den grünen Balken der geheimen Konversation. Der erste magenta Balken ist der Beginn des Gesprächs, als die Personen in den Raum eintritt. Unsere Gespräche ist an Orange. Und der zweite Balken ist wieder magenta, wo die Personen in den Raum verlässt. Und nach diesem Balken wissen Sie wieder nicht über unser Gespräch. Dass dieser Zuhörer nichts in der Vergangenheit erfahren kann, wenn wir Forward Secrecy, dass er nichts in die Zukunft hören kann, wenn wir Future Secrecy. Das letzte Prinzip, was Sie sprechen werden, ist Deniability. Weil wir nur zwei Personen in diesem Raum sind, gibt es keine Zeugen. Wir haben Deniability, weil nach diesem Talk, wenn uns Leute fragen, was wir besprochen haben, kann ich immer auf Frieda zeigen. Ich sagte X. Und Frieda kann immer sagen, nein, sagte er nicht. Und es wäre Wort gegen Wort. Und wenn das eine andere Sache erlaubt, dann haben wir Deniability. Weil jeder von uns kann immer verneinen, irgendwas gesagt zu haben oder behaupten, es gesagt zu haben. Und nun schauen wir uns Messaging an. In Messaging kommt ein dritter Teil, neben dem wir in Raum. Es könnte dein Provider sein, was Text Messaging ist, das SMS, wie wir 90er versichert haben. Es könnte der Messaging Provider sein, wie zum Beispiel WhatsApp oder Apple. Aber es gibt immer, außer wenn man ein federiertes System verwendet, das einige von euch hören möchten, wie zum Beispiel Jabba. Das weiß ich, aber wir gucken hier zentralisierte Systeme an und hier wird es immer einen dritten Teilnehmer geben, der die Nachrichten weiterfühlt. Ob ihr das mögt oder nicht und ob ihr das wisst oder nicht. Das bringt uns zur zweiten Analogie, dem Post-Netz-Post-Dienst. In Messaging fühlt sich so an, also ob man ein privates Gespräch hat. Wenn eine Person, ihr könnt das sicher verstehen. Man guckt aufs Display, sieht die Nachrichten, sieht den Gesprächspartner, in meinem Fall zum Beispiel Frieda. Wir fühlen uns, als ob wir eine private Konversation hätten. Aber die Nachrichten gehen durch einen Dienstleister. Wir schauen also etwas an, dass näher am Post-Dienst ist. Wir bereiten eine Nachricht vor, versenden sie, der Provider nimmt die Nachricht, bringt sie zum Empfänger, der sie dann lesen kann. Das betrifft jede Nachricht, die wir hin und her senden. Und das zu unterstreichen, werden wir traditional Messaging anschauen. SMS-Nachrichtenversand ohne Verschlüsselung. Wie ihr vielleicht wisst, diese Nachrichten werden auch über den Provider versandt. Sogar über mehrere Provider, wenn ich zum Beispiel bei Vodafone bin, an Frieda bei Verizon, sende ich meine Nachrichten zu Vodafone, die sie zu Verizon weiterleiten, die sie dann an Frieda weiterleiten. Weil beide unsere Provider alle Nachrichten kennen und die nicht verschlüsselt sind, hätten wir keine Vertraulichkeit. Sie könnten die Nachrichten auch austauschen. Sie könnten auch keine Integrität. Ich weiß nicht, ob die Nachricht die Frieda erhält. Die ist ich gesendet habe. Wir haben noch keine authentizierte Nachricht, weil die Telefonnummern, die verwendet werden, sehr schwach sind für Authentisierung. Sie sind von den Providern verwaltet. Es gibt dabei keine fixe Zuordnung zu unseren Telefon- oder SIM-Karten. Die Nachrichten können weiter gesendet werden. Wir wissen also nie, ob die Nachrichten an den vorgesehenen Empfänger sind. Die Nachrichten werden gesendet. Keine Authentizität. Ein Forward and Future Secrecy treffen hier nicht mal zu, weil wir nicht mal aktuelle Vertraulichkeit haben. Wir haben vielleicht eine gewisse Denialbility, aber das ist dann eine philosophische Diskussion, die sich darauf bezieht, ob der Provider behaupten kann, dass er eine Nachricht von mir erhalten hat. Oder er sie selber erschrieben haben könnte. Wir können das zusammenfassen, dass SMS-Nachrichtenversand diese Privatsphäre der Erwartungen, die wir jetzt aufgezeigt haben, sehr schlecht erfüllt. Machen wir weiter. Wenn wir unsere Postversandsanologie angucken, sind unsere Nachrichten ungefähr Postkarten. Sie sind offen. Die Provider können sie ansehen. Sie können sich verändern. Wie jetzt beschrieben. Wie Sie das mit der Postkarte können. Sie sehen den Empfänger. Sie sehen den Zender. Sie sehen den Text. Sie können alles davon verändern. Wie bei einer Postkarte. Und was wir jetzt machen wollen, ist, diese Postkarten einpacken und sie mehr wie Briefe zu machen. Wenn wir uns vorstellen, dass die Postbriefe nicht öffnet. Das müssen wir in dieser Anlage vorstellen. Die Postkarte. Die Postkarte. Die Postkarte. Um das zu tun zu können, geben wir euch die kürzeste Beschreibung zur Verschlüsselung, dass ihr je halten werdet. Wir beginnen mit symmetrischer Verschlüsselung. Verschlüsselung, wenn ihr das noch nicht kennt, ist die Besetzung von lesbarem Text zu Text, der aussieht, als ob er zufällig wäre. Aber wieder umgekehrt werden kann man den richtigen Schlüssel halt. Um beim einfachen Beispiel zu bleiben, schaut dieses Kästchen an, auf das Krypto geschrieben ist. Wir stellen uns das einfach vor. Das nimmt zwei Inputs, plaintext, den offenen Text und ein Key, den Schlüssel und produziert den ciphertext. Der ciphertext kann nicht von zufälligem Text unterschieden werden, aber der Empfänger kann mit demselben Schlüssel aus diesem ciphertext wie den plaintext herstellen. Das nennen wir symmetrische Verschlüsselung. Ihr könnt euch eine Linie vorstellen, wo der ciphertext ist und eigentlich sind die beiden Seiten gespiegelt. Wenn es etwas Symmetrisches gibt, muss es auch etwas Asymmetrisches geben und die Asymmetrische Verschlüsselung funktioniert ähnlich, aber es gibt jetzt zwei Schlüssel. Wir haben einen gelben und einen blauen Schlüssel. Das ist ein Keypair, ein Schlüsselpaar. Die sind mathematisch verknüpft und das funktioniert nun so, dass alles, was mit einem dieser Schlüssel verschlüsselt wurde, kann nur mit einem anderen Entschlüsselt werden. Man kann das in beide Richtungen machen, aber das Wichtige, das man sich hier merken sollte, ist, dass alles, was sich mit dem gelben Schlüssel verschlüsselt, kann nur mit dem blauen Entschlüsselt werden. Da wir jetzt das haben, bauen wir darauf auf und verrennen weiter das Szenario. Stellt euch vor, dass jeder unserer Kommunikationspartner ein dieser Schlüssel hat. Nun nennen wir ein dieser Schlüssel einen Geheimschlüssel und einen einen öffentlichen Schlüssel. Die meisten von euch kennen das wahrscheinlich schon. Das ist traditionelle Public Key, es gibt in diesem Bild etwas, was Identität nennt. Da kommen wir später dazu. Das Szenario, das ihr euch vorstellen sollt, ist, dass jede dieser Parteien ihren öffentlichen Schlüssel veröffentlicht und den privaten Schlüssel geheil hält. Ihr kennt das als Geheimschlüssel. Wir haben es hier als Geheimschlüssel in Folien aufgeschrieben, weil das Wort etwas klarer ist. Das heißt nun, dass jede Nachricht, die mit dem öffentlichen Schlüssel einer Partei verschlüsselt ist, kann nur mit deren Geheimschlüssel entschlüsselt werden. Das heißt, ich kann Friedes öffentliche Schlüssel nehmen, seine Nachricht damit verschlüsselt und er ist nun der Einzige, der diese Nachricht entschlüsseln kann, solange sein Geheimschlüssel geheim bleibt und er ihn nicht veröffentlicht. Das Problem ist, das ist ein ziemlich teures Zettel, das ist ein ziemlich teures Zettel. Wir bekommen etwas, das ähnlich ist wie ein Postversandnetz. Wir können eine Nachricht verschlüsseln. Wir packen also unseren Brief in einen Umschlagversenden, den niemand kann in den Umschlag reingucken. Die Poststelle sieht, an wen der Brief geht, weiß aber nicht, was drin ist. Das ist ein ziemlich teures Zettel. Das heißt, es ist schwer, umzusetzen für Mobilgeräte, besonders weil mobiles Messaging normalerweise auf dem Smartphone passiert, es kompliziert zu machen. Was, wenn wir ein Mechanismus hätten, der es uns umsetzten kann, dann ist es schwer, wenn wir ein Mechanismus haben, der uns ermöglichen würde, symmetrische und asymmetrische Verschlüsselung zu kombinieren. Es stellt sich heraus, dass haben wir. Wir machen das ganz einfach und sprechen hier kurz über Key Establishment. Auch hier nur einen möglichen Weg, dies zu tun. Wir haben zwei neue Kästchen, Key Generator. Das Schema, das wir anschauen, funktioniert folgendermaßen. Man nimmt einen der geheimen Schlüssel und einen anderen öffentlichen Schlüssel, packt diese in den Key Generator und merkt euch, erinnert euch, diese Keys sind Mathematisch verlinkt. Dieser Key Generator funktioniert nun so, dass es keine Rolle spielt. Nennen wir die Personen Alice und Bob. Es spielt keine Rolle, ob man Alice ist Secret Key und Bob ist Public Key und Bob Secret Key nimmt. Man kommt immer zum selben Schlüssel, denn wir den geteilten Schlüssel nennen Schert Key. Dieser Schert Key kann dann verwendet werden, um Nachrichten zu versenden. Wie wir besprochen haben, die symmetrische Verschlüsselung ist günstiger, geht schneller als asymmetrische Verschlüsselung. Das hat also den Vorteil, wir können beide Verfahren kombinieren. Wir können den Schlüssel auf beiden Seiten finden. Der Nachteil ist, wir kommen auf beiden Seiten zum selben Schlüssel. Ihr habt das sicher schon realisiert, das ist ein sehr statisches Schema. Wir kommen immer auf den selben Schlüssel zwischen Alice und Bob. Wir fassen zusammen, asymmetrische Verschlüsselung gibt uns IDs, aber ist sehr teuer. Wir müssen den Schlüssel erst zwischen beiden Parteien verteilen. Wir haben Key Establishment angeschaut, mit dem wir symmetrische Schlüssel generieren können, basierend auf asymmetrischen Schlüsselpaaren. Das heißt, wir haben jetzt Vertraulichkeit hergestellt. Wir können Nachrichten reinstecken, wir bekommen verschlüsselnden Text, dann schicken wir es rüber und auf der anderen Seite wird es ausgepackt. Und keiner kann es mitlesen auf dem Weg. Jetzt kommt es zu Ablehnbarkeit, Deniabilität. Es geht darum zu sagen, dass ich sage, du hast das gesagt und der andere sagt, das habe ich nie gesagt. Das nachweisen zu können. Wenn man auf das Kryptografe schaut, dann kann man bisher nicht sagen, dass es von mir oder jemand anders geschickt wurde. Wenn wir darüber nachdenken, was wir gerade beschrieben haben, beide Parteien generieren den gleichen Schlüssel, der gleiche Schlüssel wird auf beiden Seiten generiert und wenn ich auf eine Nachricht schaue und wenn ich auf eine Nachricht schaue, die auf der einen Seite generiert wurde, dann kann ich nicht abstreiten, dass die auf der anderen Seite generiert worden sei oder nicht. Und wie geht es um Vorwärts- und Rückwärtssicherheit? Geheimhaltung. Dieses Bild ändert sich jetzt so. Wir sehen jetzt unten Key Compromise. Das heißt also, dass der, dass der auf der anderen Seite generiert wurde, wir sehen jetzt unten Key Compromise. Das heißt also, dass der Schlüssel gebrochen wurde von jemandem draußen, dass der an jemand anderes gegeben wurde und dass wir nach einer gewissen Zeit einen neuen Schlüssel generieren. Der Schlüssel ist in die Hände eines Angreifers gefallen. Und wir nutzen ja den gleichen Schlüssel die ganze Zeit. Wenn die jetzt an dem Zeitpunkt, wo der Schlüssel in dritter Hände gefallen ist, nichts auspacken könnten, was vorher gewesen sei, und wenn die an dem Punkt, wo wir einen neuen Schlüssel aushandeln, dann auch nicht mehr weiter könnten, dann hätten wir Rückwärtssicherheit oder Rückwärtsvertraulichkeiten und Vorwärtsvertraulichkeiten. Und das sollte euch auch noch ein bisschen weitergehen. Und das sollte euch jetzt mal im Hinterkopf behalten, wenn wir uns Trema am Detail anschauen. Wenn wir jetzt eine Möglichkeit hätten, Schlüssel wegzuschmeißen, nachdem wir sie benutzt haben, dann könnten wir Vorwärts- und Rückwärtsgeheimhaltung sicherstellen. Unser Protokoll gibt uns Vertraulichkeit, Abstreibbarkeit und Authentizität. Wir haben keine Vorwärts- und Rückwärtsgeheimhaltung und wir ignorieren Interkretät. Aber wir werden dazu zurückkommen. Und wenn wir Trema anschauen, dann werden wir feststellen, dass das auch da ist. Aber wir wollen jetzt dieses Konzept erst mal rauslassen. Wir haben jetzt zwar alles in Ordnung gebracht, aber ihr habt uns über IDs reden gehört, wo wir uns nicht so im Detail darüber unterhalten haben. Hier ist mein eigener Professor. Mein Professor sagt, Kryptografie ist selten, wenn überhaupt jemals, die Lösung zu einem Sicherheitsproblem. Kryptografie ist ein Übersetzungsmechanismus, in dem es in aller Weise ein Kommunikations- und Sicherheitsproblem in einem Schlüsselmanagement-System übersetzt. Er weiß, dass ich einen privaten und öffentlichen Schlüssel habe. Ich weiß, dass er einen hat. Und wie können wir diesen öffentlichen Schlüssel zueinander kommunizieren? Ich weiß nicht. PGP gibt es seit 20 Jahren. Und jeder, der das schon mal angeschaut hat, weiß wovon ich rede. Das gleiche Problem gibt es im Mobile-Messaging-Server. Diese zentrale Instanz dieser Messaging-Server, die können wir anfragen. Und ich kann im zentralen Server meine Identität sagen. Und der Server hat ein bisschen Information, mich zu benennen und meinen Schlüssel. Und jetzt ist die Frage, ob wir den Messaging-Server trauen. Aber wir haben eine Möglichkeit, unsere Publikis zu anderen Leuten zu kommunizieren. Was werden wir als Identitäten verwenden? Die Frage ist, was eine gute Idee darstellt. Wir könnten Telefonnummern verwenden, E-Mail-Adressen verwenden. Oder wir könnten uns etwas anderes ausdenken. Und etwas anderes, das wird der Interessante sein. Was ist das? Was ist das? Was ist das? Die Telefonnummer kann benutze identifizieren. Und ich verlasse mich sowieso schon auf den Provider, dass das funktioniert mit den Telefonnummern. Dass die richtige Person auf der anderen Seite ist. Die Telefonnummer ist persönliche Information. Und das würde in der Hand sein. Ich persönlich würde das nicht unbedingt nutzen wollen, weil ich es nicht unbedingt ändern kann, wenn es kompromittiert wird. Eine E-Mail-Adresse ist auch wieder wie eine Telefonnummer. Die sind nicht ganz so, dass die Telefonnummer auf der anderen Seite ist. Ich würde das nicht nutzen, aber man kann temporäre E-Mail-Adressen verwenden. Idealerweise wollen wir etwas anderes. Etwas, das mich nur innerhalb dieses Services identifiziert. Und wir zeigen mal, wie das funktionieren könnte. Das ist das. Das ist das. Das ist das. Das ist das. Das ist das. Wir zeigen mal, wie das funktionieren könnte. Und dass man es auch ändern kann. So, hier ist das Szenario. Ich sehe eine bestimmte Anzahl von öffentlichen Keys. Und ich muss einen Weg finden, um herauszufinden, welcher denn jetzt der richtige ist. Vielleicht hat er eine ganze Anzahl von öffentlichen Schlüsseln und vielleicht ein paar neue gemacht. Vielleicht hat er vergessen, ein paar mitzunehmen. Ich weiß nicht genau, welcher der aktuelle ist. Jetzt gehen wir zurück zu dem Messenger-Server. Und der verteilt die Schlüssel. Und jetzt haben wir hier eine dritte Zeile. Wir haben jetzt hier ein Weg eingebaut, dass man sich persönlich treffen kann. Und die Schlüssel, wenn ihr persönlich überprüfen kann. Trema benutzt auch QR-Codes, wie wir es hier zeigen. Das ist ein ganz wichtiger Aspekt. Und das Wichtige ist halt, dass man den Schlüssel verifizieren kann, ohne abhängig von dem Messenger-Server, nicht mehr unbedingt vertrauen muss. Wir haben das jetzt unabhängig von dem Server verifiziert. Wir haben jetzt das Authentizitätsproblem gelöst. Wir können sie mit Telefonnummern und E-Mail identifizieren. Wir müssen das nicht tun. Wir können die IDs anonym verwenden. Aber wir haben eine Möglichkeit, das unabhängig zu bestätigen. Mein Problem ist, dass Benutzer ihre IDs ändern. Dann müssen wir halt nochmal neu verifizieren. Und jetzt schauen wir uns mal die Metadaten an. Der Angreifer kann jetzt nicht mehr in die Nachrichten reinschauen. Aber der kann sehen, wer mit wem ist. Und wie groß die Nachricht ist. Und was da für eine Zeitstempel drauf ist. Oh, jetzt wird es hier ein bisschen spät. Ich muss mal ein bisschen schneller werden. Also wir wollen jetzt verstecken, von wem das ist, an wem das ist. Und das tun wir, indem wir den Umschlag in noch einen Umschlag tun. Und wir geben dem Messenger-Server eine ganze Menge Umschläge. Also im Netzwerk kann man nur sehen, dass ganz viele Leute der Messenger-Server Pakete schicken. Aber sie können halt nicht sehen, wo das jetzt hingehen soll. Der Messenger-Server, der Messenger-Server, der Messenger-Server, der Messenger-Server, der Messenger-Server, der Messenger-Server, der kann den äußeren Umschlag aufmachen. Und kann dort hineinschauen. Und kann sehen, dass das für Alice ist. Kann es in noch einen Umschlag reinstecken. Und Alice kann dann den äußeren und den inneren Umschlag aufmachen. Und kann dann die Nachricht lesen. Und was wir damit erreicht haben, ist ein zweiebenen Kommunikations-Kanal vom einen Ende zum anderen Ende. Und das blaue ist von dem ersten zum Messenger-Server. Und in drin der braune Kanal ist zwischen den beiden Partnern, der auch dem Zentralserver verborgen ist. Der Messenger-Server weiß immer noch, wer mit wem redet und die Uhrzeit und die Größe der Nachricht. Also die Größe, die können wir erstmal adressieren, indem wir Padding machen. Padding ist extra Material in die Nachricht, an die Nachricht hin dranfügen, bevor wir das verschlüsseln, sodass alle verschlüsselten Nachrichten groß sind. Es sollte zufällige Informationen sein. Es sollte niemals die gleiche Länge haben. Aber damit können wir die eigentliche Größe von dem Ding verstecken. Das war jetzt eine einfache Einführung in mobiles Messaging. Und jetzt gehen wir zum nächsten. Dazu will ich nun ein paar Sachen sagen. Wir haben keine Beziehung zu Drima. Wir sind auch nicht hier, um euch Drima zu empfehlen. Wir haben keine formale Analyse gemacht. Wir machen keine Garantien. Und wir möchten nicht zitiert werden, dass wir sagen, nutzt es oder nutzt es nicht. Was wir machen möchten, ist mehr Leute auf die Mechanismen und Hinweisen, die verwendet werden. Wir haben einen beliebigen Nachrichtenproven ausgewählt. Wir haben uns für Drima entschieden, weil dieser Messenger die Möglichkeit anbietet, dedizierte Schlüssel zu verwenden. Und weil es closed-source ist, fanden wir es interessant, Ebis App reinzuschauen. Und das öffentlich zu machen, was dort passiert. Wir sind nicht die Ersten, die das gemacht haben. Wir sind nicht die Einzigen, die das gemacht haben. Aber uns ist es wichtig, euch darauf hinzuweisen, wie das diese App funktioniert. Und damit gebe ich an Frieda weiter. Ich werde euch unser Video zeigen. Ich werde euch unser Verständnis des Protokolls und der Architektur von Drima aufzeigen. Wir haben das größtenteils durch Reverse Engineering der Android App erhalten. Es wäre kein komplettes Bild, aber die wichtigsten Features, Funktionen, müssen enthalten sein des Protokolls. Wir haben hier mit der Vogelperspektive der Architektur an. Roland hat euch die abstrakte Einführung zu mobile Messaging aufgezeigt. Das ging immer um eine third-party Messaging Provider. Hier gibt es nun drei Entitäten. Drima hat drei verschiedene Server für den meisten Teil, die komplett unterschiedliche Aufgaben für die App wahrnehmen. Ich fange an mit dem Directory Server. Der Orange unten ist, weil das der Server ist, mit dem ihr wahrscheinlich als erstes Kontakt haben werdet, wenn ihr in einem Gespräch vertreten sein möchtet, mit dem ihr noch keine Gespräche hattet. Dieser Server vermittelt alles rund um Publikes. Das ist auch der Server, den ihr anfragen werdet für Publikes. Mit der Frage, wie ich habe, diese 3-mal ID, was ist der Publiki dazu? Darüber ist der Messaging Server, das zentrale Herzstück des ganzen Szenarios. Seine Aufgabe ist es, Nachrichten vom einen Kommunikationspartner zum nächsten weiterzuleiten. Aber ich werde darüber später noch sprechen. Seine Aufgabe ist es, große Medien-Dateien-Videos zu lagern. Wie gesagt, ich werde mit dem Directory Server anfangen. Im Fall von Drima ist dieser Directory Server basierend auf einer REST-API. Die Kommunikation passiert über harte TPS. Das heißt, die Verbindung ist CLS verschlüsselt. Die Verschlüsselung erfüllt alle der Merkmale, die wir vorher besprochen haben. Wenn man also mit einer neuen Person kommunizieren möchte und deren 3-mal ID oder Telefonnummer hat, dann fragt die App den Directory Server und fragt nach dem Publiki zu dieser Nummer oder der ID. Hoffentlich ist die Antwort, ja, ich kenne diese Person. Hier ist der Publiki dieser Person. Wie Ronan schon beschrieben hat, wir haben uns dafür entschieden, 3-mal zu analysieren für die Möglichkeit beliebige IDs zu verwenden und für das System, weil Fingerprints in Personen über QR-Codes verifiziert werden können. Das ist etwas, das viele andere Messenger nicht haben. Da will ich kurz drüber sprechen. Wenn man einfach den Directory Server fragt, was ist die 3-mal ID, ich möchte den Publiki. Die Applikation wird dann sagen, ich habe eine Antwort vom Directory Server, aber ich habe sehr geringes Vertrauen, dass du wirklich weißt, wer diese Person ist hinter diesem Publiki. Deshalb wird dieser Kontakt mit einem roten Punkt markiert werden. Wenn man eine Telefonnummer oder eine Mailadresse hat und fragt, was ist der passende 3-mal Publiki, dann wird der Server antworten, ja, wir müssen immer noch dem Directory Server vertrauen, aber ich habe ein gewisses Vertrauen, dass die Person mit diesem Publiki möglicherweise die Person sein könnte, mit der du sprechen möchtest. Wir vertrauen immer noch dem Directory Server und der Kontakt wird nun mit zwei Orangenpunkten markiert. Und die dritte Stufe, wenn man jemanden Person getroffen hat und den QR-Code, den Publiki oder den 3-mal-Ki dieser Person, den QR-Code gescannt hat, dann wird dieser Kontakt mit drei grünen Punkten markiert. In diesem Fall sagt die App, ich bin zu 100% sicher, dass die richtige Person ist und ich den richtigen Ki für diese Person habe. Wenn wir nun ein Gespräch starten möchten, haben wir zu diesem Zeitpunkt also allen nötigen Daten, um einen Nachricht zu verschlüsseln und ein Gespräch zu starten. Die Frage bleibt da, wie tun wir das, diese Verschlüsselung? Im Fall von 3 Month, 3 Month benutzt eine Library namens Salt von Daniel Bernstein. Er nennt die Library Salt, aber sie ist NACL, Natriumchlorid, abgekürzt. Wenn man irgendwo NACL sieht, dann ist das ausgesprochen Salt. Diese Bibliothek ist spezifisch dazu entwickelt worden, um Nachrichten zu verschlüsseln. Und soll sehr einfach in der Anwendung sein. Und uns dabei alle nötigen Features geben, die wir für die Verschlüsselung von Nachrichten brauchen. Was hier verwendet wird, ist die authentizierte Verschlüsselung von Salt. Sie gibt uns Intelligentität, Authentizität und Vertraulichheit. Hier ist ein kurzer Überblick, wie wir diese Bibliothek in 3 Month verwendet wird. Im Grauenkästchen sind die Bibliotheksfunktionen. Wir brauchen also nur den Public Key des Empfängers und die Nachricht, um eine Nachricht zu verschlüsseln. Die Library benötigt auch ein N-Once, eine Nonce. Das heißt, wir müssen etwas Zufälliges generieren, um das Nachricht mitzugeben, um diese verschlüsseln zu können. Das ist eine Maßnahme, dass, wenn wir dieselbe Nachricht 2-mal verschlüsseln würden, wir nicht denselben Cyphertext erhalten. Am Ende bekommen wir aus dieser Library den Cyphertext die verschlüsselte Nachricht, und da bleibe ich kurz bei einer ganz einfachen Definition. Es ist etwas, das zeigt, eine Checksumme, die bestätigt, dass die Nachricht nicht verändert wurde. Also jemand kann mit dem Cyphertext und der Mac nachvollziehen, dass diese Nachricht integer ist. Wenn wir diese Nachricht nun in verschlüsselter Form übermitteln wollen, dann müssen wir die Nonce mitsenden. Die ist nicht geheim, wird aber zur Entschlüsselung weiter benötigt. So funktioniert die Verschlüsselung in 3MOM. Wie ihr euch aber von Roland's Einführung erinnern könnt, dieses Schema bietet keine vorausschauende und rückblickende Sicherheit. Wir können hier vorausschauende und rückblickende Sicherheit hinzufügen. Und das macht man normalerweise mit einem Handshake. Ein Handshake ist ein System, bei dem man alte Schlüssel wegwirft und sich auf neue Schlüssel leidigt. Einen solchen Handshake mit jemanden zu machen, der nicht online ist, ist ziemlich kompliziert. Die Signal-Messaging-App hat einen solchen Mechanismus, der aber ziemlich kompliziert ist. Das Protokoll von 3MOM spart sich diesen Aufwand und tut diesen Handshake nur mit dem 3MOM-Messaging-Server durch. Weil diese Server werden online sein. 3MOM hat also einen gewissen Trust in diese Verbindung. Und ich werde euch aufzeigen, wie dieser Handshake gemacht wird. Das machen wir jetzt Schritt für Schritt. Und ich werde euch versuchen aufzuzeigen, was jeder Schritt zu tun versucht. Wenn wir eine Verbindung aufbauen, um eine Nachricht zu senden, dann verbindet sich die 3MOM-App erst zum Server und sendet ein Kleinteller. Ein sehr einfaches Paket. Es ist nur dafür da, um den Public Key zu kommunizieren, den wir verwenden möchten. Und das Nonce Prefix. Das ist ungefähr die Hälfte der Nonce. Die zweite Hälfte ist dann ein Counter, der während dieser Kommunikation immer erhört werden wird. Es macht nichts, wenn ihr das jetzt als die ganze Nonce anschaut. Gut, wir starten also diese Konversation und senden den neuen Public Key. Der Server wird dann antworten, ich brauche dann auch einen neuen Public Key. Sendet mit dieser Nachricht ebenfalls seinen neuen Public Key. Das Einzige, was man hier berücksichtigen muss, ist nicht viel mehr, das mitgesendet wird als der Kleint, das bereits getan hat. Zusätzlich kommt aber noch die Server Nonce dazu. Und eben die Kleint Nonce, um aufzuzeigen, dass der Server auf unsere Anfrage von gerade eben reagiert hat. Und das ist nicht einfach ein Fehlgeleiter, das Paket von vorher ist. Der zweite Teil der Nachricht, diese Klamascyphertext weist daraufhin, ist, dass der zweite Teil dieser Nachricht verschlüsselt ist. Verschlüsselt mit dem langfristigen Public Key, Private Key des Servers. Und damit tut der Server etwas, das nur jemand tun kann, der den langfristigen Private Key des Servers besitzt. Er verschlüsselt also die Nachricht mit diesem Secret Key und leitet und versendet die Nachricht erst dann. So kann niemand den Server imitieren und diese Nachricht selber verschenken. Zu diesem Zeitpunkt sind wir, weiß der Kleint, dass der Server tatsächlich der 3er Server ist und nicht jemand, der diesen Server fälscht. Der Server weiß auch, dass ein neuer Public Key verwendet werden soll, weiß aber noch nicht, wer das ist. Das ändert sich in diesem Schritt. In diesem Schritt sendet der Kleint das Kleint Authentication Packet mit, dass Information über den Kleint enthält. Der erste Teil ist die 3er ID. Das ist ein String von acht Zeichen, Zahlen, Ziffern und Buchstaben. Dann kommt ein User-Action String, der nicht technisch nötig ist für das Protokoll, der enthält die Version des 3er Clients, das System, IOS, Android, ist aber nicht technisch für das Protokoll notwendig. Es ist ungefähr dasselbe wie ein User-Action bei einem Web Browser. Ich weiß nicht, wieso sie das tun, aber sie tun es. Der Rest der Nachricht sind nonces, die jetzt überspringen werden. Und der vorübergehende Public Key des Clients, diesmal verschlüsselt mit unserem langfristigen Private Key. Wir tun das dasselbe wie das Server. Mit unserem geheimen Schlüssel verschlüsseln wir die Nachricht, die wir schon vorher gesendet haben und bestätigen damit, dass tatsächlich wir den geheimen langfristigen Schlüssel kontrollieren. Nach diesem Austausch wissen beide Parteien, was die jeweils andere Partei will und dass diese Person tatsächlich ist, wer sie sich ausgibt zu sein. Zum Abschluss sendet der Server eine Reihe von Nullen verschlüsselt mit dem ausgehandelten Key. Nun, wenn wir das getan haben, wenn ihr euch an dieses Bild hier erinnert, dann haben wir vorwärts Sicherheit, vorwärts Geheimhaltung sichergestellt. Wir haben nichts für das innere Verschlüsselungsleih gemacht. Bei 3MAR ist es einfach die Verschlüsselung mit der Soll Library, das auf ganz einfache Weise verwendet wird. Nun haben wir Kanäle aufgebaut, über die wir kommunizieren können. Im nächsten Schritt will ich nun anschauen, was wir über diese Kanäle auch tatsächlich versenden. Dazu zeige ich hier das 3MAR Packet Format auf. Das ist das Format, das Pakete haben, die von 3MAR, von der Applikation an die Server gesendet werden, das was der Server sieht. In diesem Fall ist, ist das die Form eines Pakets, wenn ich etwas an einem Kommunikationspartner übermitteln möchte, zum Beispiel eine Textnachricht. Es gibt Nachrichten für Managementzwecke mit dem Server, die niemals an andere Kleins übermittelt werden. Aber das hier ist das grundsätzliche Format, wenn wir Bilder oder Text an Kommunikationspartner übermitteln. Es gibt ein Paket-Typen um links und dann folgen die Felder auf dem Umschlag. Das ist eine Nachricht von Alice an Bob. Ihr könnt euch erinnern. Dann kommt eine Message-ID, eine zufällige ID, die erstellt wird, wenn die Nachricht versendet wird. Es fragt einen Side-Stampel, damit der Server weiß, ob eine Nachricht erst kürzlich ausgestellt wurde und stecken geblieben ist. Dann folgt etwas 3-mal Spezifisches. 3-mal hat öffentliche Nicknames, die man als alias für seinen Accountnamen festlegen kann. Wenn man dies tut, dann wird dieser Nickname mit jeder Nachricht übermittelt. Wenn man diesen Nickname ändert, dann wird das auf dem Gerät eines Kommunikationspartner auch erst dann wiedergespiegelt, wenn er eine Nachricht von euch erhalten hat. Dann folgt ein Nonz, die mit dem Cypher-Text verwendet wurde und schließlich kommt der Cypher-Text, der innere Umschlag mit der Nachricht. Nun schauen wir uns an, was in diesem Umschlag ist, wie diese Nachrichten ausschauen, die wir unseren Kommunikationspartner übermitteln. Das Einfachste, was wir tun können, ist die Nachricht, wir sehen oben in Grau immer noch die Felder des äußeren Umschlags und unten etwas ganz Einfaches. Wir haben einen Nachrichtentyp, ein Byte, das angibt, dass das Cypher-Text ein Nachricht ist und dann folgt Text. Nichts weiter, einfach Text. Danach folgt Padding, wie ihr sehen könnt, und ist das im Innersten Verschlüsselungs-Layer. Der Threema-Server weiß also nicht, wie groß die versandten Nachrichten sind. Das ist ja praktisch, also für Typing-Notifications, die an Gesprächspanner sendet werden. So versteckt Threema diese Notifications vor dem eigenen Server, weil die Länge sich immer ändert. Ein anderer MessageType, ich würde sagen, eine der einfachen Nachrichtentypen, die oft verwendet werden, ist eine Bildnachricht, wenn ich jemanden ein Bild senden möchte. Die sehen ungefähr komisch aus auf den ersten Blick. Sie haben auch einen Nachrichtentyp, gefolgt von einer Blob-ID. Was das ist, werde ich gleich noch erklären. Gefolgt von einer Größe. Die Größe des Bildes wird übertragen. Und dann folgt ein Key. Und dann das Padding. Die Frage ist nun, was ist die Blob-ID und was ist der Schlüssel, der übermittelt wird? Und hier kommt der Medien-Server ins Spiel. Der Medien-Server ist ... Ich zeige euch, was passiert, wenn ihr eine Bildnachricht versendet. Die App nimmt das Bild, das versendet werden soll. Er stellt einen zufälligen Schlüssel, verschlüsselt das Bild mit diesem Schlüssel und sendet es zum Medien-Server. Der Medien-Server speichert das Bild unter einer Blob-ID und antwortet mit dieser Blob-ID. Er sendet der Kleint die Image-Nachricht, die ich gerade gezeigt habe, an den Kommunikationsserver. Dieser gibt seinen Empfänger weiter. Der Empfänger sieht die Blob-ID und den Schlüssel, fragt dann beim Medien-Server an. Hey, Medien-Server, hast du unter dieser Blob-ID etwas gespeichert? Der Medien-Server antwortet, ja, habe ich. Hier ist der verschlüsselte Inhalt. Der Kommunikationspartner erhält zu diesem Zeitpunkt alles mit dem Schlüssel, den er in der Nachricht an den Alten hat und sieht das Bild. Damit haben wir grundsätzliches modernes Instant-Messaging sichergestellt. Was ich jetzt als Nächstes anschauen möchte, ist etwas, das die meisten Leute von einem modernen Schatzsystem auch wollen. Die Unterhaltungen in DREMA funktionieren nicht so viel anders als bei anderen Messagern. Wenn ich an eine Gruppesende verschlüsse, verschlüsse ich das mehrfach. Und meine Kommunikationspartner müssen wissen, dass es eine Gruppennachricht ist. Also Gruppennachrichten ist das, worüber ich reden möchte. Diese Nachrichten sehen dann hier so aus. Die enthalten genau das. Die Creator-ID ist hier die DREMA-ID von einem Sender, von einem Absender. Und die Gruppen-ID ist für die Empfängergruppe. Und dann kommt das normale Paketformat. Ja, eine Textnachricht, aber analog würde es auch filmen, wie es funktioniert. Wir brauchen jetzt auch noch eine Möglichkeit, neue Gruppen anzulegen. Und dafür gibt es Spezialpakete. Das hier ist eine Nachricht, die eine Gruppe anlegt. Und diese Gruppe hat die folgenden Nachrichten. Es gibt eine Gruppen-ID, es gibt keinen Creator mehr. Das Gruppenmanagement in DREMA ist sehr statisch. Also nur derjenige, der die Gruppe hergestellt hat, der kann dann auch solche Nachrichten verschicken, zum Beispiel, dass es einen neuen Teilnehmer gibt. Der Creator ist hier implizit. Das ist nämlich der Sender. Das ist ein bisschen nervig, weil man keine Gruppe anlegen kann, wo jeder Teilnehmer ist. Wenn man zusätzlich noch einen Namen hat, dann sieht das sehr ähnlich aus. Was Nächstes möchte ich mich über das, was darüber passiert, unterhalten. Wir haben jetzt hier Pakete unterhalten. Es gibt noch ein paar mehr Pakettypen, wir haben jetzt noch ein paar Pakete, wie zum Beispiel für Audio. Aber die sehen ähnlich aus, wie das mit den Bildern. Aber über den Paketformat ist auch noch eine ganze Menge, was passiert. Ein gutes Beispiel ist, wie die Subtitels oder Untertitel für Bilder behandeln, wenn man Texte in einem Bild hinzufügt. Sie haben keinen Paketformat oder sowas. Das heißt also, die tun den Untertitel in das Bild hinein. Das hat den Vorteil, dass das mit DREMA-Versionen, die sowas nicht kompatibel sind, also rückwärts kompatibel, ein Feature, das nicht im Paketformat auftaucht. Und Quotes sehen relativ ähnlich aus. In der App, wo man die Texte in einem Paketformat sieht, und Quotes sehen relativ ähnlich aus. Und in der Anwendung sieht es besonders aus. Und es sieht so aus, ob es zu der alten Nachricht dazu gehört, aber eigentlich ist das nur eine ganz normale Text-Message. Und die Formatierung des Payloads, der Nachricht des Markdowns, das wird dann beim Kleinen interpretiert. Damit ist es kompatibel mit Versionen, die sowas nicht haben. Und damit höre ich jetzt auf, euch die Features von DREMA vorzuführen. Es gibt zwar noch mehr, worum man die Situation unterhalten könnte, aber ihr habt jetzt ein gutes Gefühl dafür, wie das Ding funktioniert. Alles, was es tut, solltet ihr jetzt wissen. Und ich habe euch gesagt, wie es funktioniert. Und jetzt gebe ich wieder eine Roland ab. Und Roland wird die Ergebnisse unseres Reverse-Engineers vorführen. Wir haben euch erzählt, dass wir die Anwendung auseinandergenommen und reverse-engineered haben. Das stimmt alles. Aber wir sind hierhergekommen, um euch auch ein bisschen darüber aufzuklären, was ihr von Messaging-Anwendungen erwarten könnt. Wir haben euch ein bisschen Hintergrund und Terminologie gegeben, um eure eigene Entscheidung zu treffen oder eine eigene Einschätzung zu treffen von Messengers. Und was die Versprechen sind im Verhältnis zu euren Erwartungen. Da wir das Ding auseinandergenommen haben, weil wir das Ding auseinandergenommen haben, haben wir es in eine Bibliothek gepackt. Und wir wissen nicht, ob wir mit dem Begriff akademischer Code vertrauen seid. Wir haben das immer wieder mal ein bisschen dran gearbeitet. Wir haben es vor zwei Jahren gearbeitet und haben es wieder ein bisschen rumliegen lassen. Und jetzt hat es noch ein Jahr in der Schublade gelegen, bevor wir beschlossen haben, das abzuschließen. Aber wir wollten es publizieren in der Hoffnung, dass vielleicht darum sich eine Community gründet, die das erweitert, die vielleicht die Dinge in Ordnung bringt, die wir nicht so toll machen. Wir erladen die Slides hoch. Also ihr braucht hier keine Fotos von dem Slide-Namen. Hier ist unser Repository. Wir haben gestern das Ding Code hochgeladen. Und wenn ihr sofort etwas hochladen wollt, dann würden wir empfehlen, dass ihr noch mal ein paar Wochen wartet, weil wir noch ein paar Sachen in Ordnung bringen wollen. Und wir hoffen, dass alle anderen sich das anschauen und ein Gefühl dafür bekommen oder ein Verständnis dafür bekommen, was es tut. Und wir hoffen, dass das die Trämerleute dazu bringt, ihren Code veröffentlichen. Solange das hier nun Reverse-Engineering ist, wird es niemals echte Transparenz geben. Mit unserer Bibliothek habt ihr die Garantie von Transparenz. Wenn ihr mal ein Board schreiben wollt, dann würde das damit funktionieren. Dann würde das auch damit gehen. Und damit danken wir euch für eure Zeit und Aufmerksamkeit. Gut. Vielen Dank, Roland Frieder. Wir haben nur Zeit für eine Frage. Wer hat eine sehr, sehr wichtige Frage? Der Signal Angel winkt. Ich wähle die beste Frage von Alien. Wäre es möglich, Captions zu verwenden, um bösartige Exif-Daten in Bilder einzufügen? Antwort, was sind bösartige Exif-Daten? Was wir nicht beantworten, was wir nicht getan haben, ist im Detail Sicherheitsprobleme, der abanzuschauen. Ich würde sagen, das gehört in dieses Gebiet. Es gibt auch eine Library, die das Anzeigen von GIFs steuern. Wir hätten anschauen können, ob das exploitable ist, aber haben das nicht getan. Wir haben das Protokoll angeschaut. Aber keine weiteren Details. Eine weitere Frage. Wenn ein User, der nicht in einer Gruppe ist, eine Group-Update-Nachricht versendet, was passiert dann? Antwort. Trima-Gruppen-IDs sind nicht global einzigartig. Die Gruppen-ID hängt immer auch von der ID des Gruppenerstellers ab. Wenn eine andere Person eine Update-Nachricht für eine Gruppe versenden würde, dann würde Trima sich auf deren ID beziehen und die Gruppe gar nicht erst finden. Man kann also keine Gruppe übernehmen.