 Also bitte noch mal alle die Hände heben, die noch einen freien Platz haben. Und jetzt einen Applaus für unseren Redner. Herzlich Willkommen. Das hier ist die grundlegende Griederung meines Vortrags. Erst mal möchte ich euch eine Übersicht geben über die Mechanismen, die es gibt für sichere Kommunikation. Es wird, ich werde darüber erzählen, was es für Auswahlmöglichkeiten gibt. Wir reden oft sehr verallgemeinend über Sicherheit und Privatsphäre. Und wenn wir das jetzt ein bisschen aufschlüsseln, dann können wir besser verstehen, was wir überhaupt hergeben. Und für die Systeme, die wir brauchen. Ich werde meinen Bogenspannen von erstmal eine Taxonomie, eine Klassifizierung der verschiedenen Systeme, die wir so zur Verfügung haben. Und dann möchte ich bedrohungen identifizieren, gegen die wir uns schützen möchten. Und die Mechanismen, die wir haben, um diese Risiken zu senken. Ich erzähle etwas über die aktuellen Entwicklungen in verschiedenen Systemen. Und da geht es mehr so um Forschung und was gerade im Moment passiert, um neue Ideen, die es gibt. Aber es ist immer noch ein ziemlicher Trade-off, der da stattfindet zwischen Privatsphäre und Sicherheit. Also wir haben unsere typischen Akteure Alice und Bob. Und normalerweise hat man eine 1 zu 1 Kommunikation. Also Systeme, die uns helfen zu kommunizieren. Und ich möchte natürlich idealerweise direkte Live-Konversation haben. Und normalerweise kenne ich meine Gesprächspartner und die kann sie identifizieren. Wenn wir uns jetzt die Systeme angucken, haben wir erstmal Systeme, die ziemlich ähnlich wie die echte Kommunikation im echten Leben ablaufen. Wir können zum Beispiel AirDrop verwenden. Oder Systeme, die direkt zwischen meinem Gerät und dem Gerät eines Freundes stattfinden. Auf dem Computer wäre das zum Beispiel NetCard. Und das Kommunikationsergebnis ist sehr ähnlich wie normale Alltagskommunikation. Aber es gibt dort auch schon Bedrohungen, gegen die wir uns sichern sollten. Da gibt es zum Beispiel das Netzwerk. Kann jemand die Kommunikation abfangen und wie können wir das verhindern? Es gibt dagegen Mechanismen wie zum Beispiel die Verschlüsselung. Jemand, der also nicht mein intendierter Empfänger ist, kann dann nicht sehen, was in der Kommunikation abläuft. Und dann gibt es natürlich die Endgeräte selbst. Und da müssen wir an mehrere Bedrohungsszenarien denken. Zum Beispiel könnte es schlechte Software auf dem Gerät geben, mit dem zum Beispiel die Kommunikation abgefangen werden kann. Da gibt es Mechanismen wie zum Beispiel das Auslaufen einer Nachricht, so dass die Nachricht irgendwann gelöscht wird. Und wir können die Systeme isolieren, so dass andere auf dem systembefindliche Software nicht sehen kann, was in der Software passiert. Oft haben wir aber keine direkte Kommunikation von Gerät zu Gerät, sondern wir haben einen zentralen Server. Eine Cloud zum Beispiel, wo ich meine Nachricht hinsetze und hinsende, und dann sende die Cloud meine Nachricht weiter. Das kann Facebook sein, WhatsApp, Slack, Signal, es gibt so viele Anbieter. Und dieses Modell gilt für alle diese Applikationen, die wir kennen. Wir können also gleich sehen, dass es hier noch zusätzliche Bedrohungen gibt. Einmal haben wir natürlich auch wieder das Netzwerk. Wir haben das noch lokale Netzwerk, über das wir schon vorher gesprochen haben. Da kann jemand drin sitzen. Das kann zum Beispiel jemand sein, der mit dir zusammen im Café sitzt oder in der Schule oder am Arbeitsplatz. Dann gibt es das Internet über das Nachrichten übertragen werden. Und da gibt es natürlich den Internet Service Provider. Der kann auch Nachrichten abfangen. Und der Server kann natürlich auch die Nachrichten, die ein und aus gehen, sehen. Also, da gibt es Datenzentren, wo Computer physisch drin sind. Und da haben wir also jetzt viele Akteure, an die wir denken müssen. Und wo wir bedenken müssen, dass die unseren Verkehr sehen. Dann müssen wir natürlich auch an den Server selbst denken. Und da gibt es mehrere Bedrohungen, an die wir denken müssen. Der Server kann gehackt oder kompromittiert werden. Es kann Softwarebacks geben, die ein Problem darstellen können. Es gibt natürlich auch Behörden, die Zugriff auf den Server haben. Und je nachdem, in welchem Rechtssystem sich das befindet, können auch Behörden auf die Kommunikationsserver zugreifen. Und die Kommunikation muss eventuell ausgeleitet werden. Und natürlich will die Firma, die den Messenger betreibt, natürlich auch Geld verdienen. Und deshalb müssen wir darüber nachdenken, wie wir uns versichern, dass unsere Nachrichten nicht missbraucht werden. Und da gibt es verschiedene Techniken. Es gibt also Umgehungstechniken oder Verschlangstechniken, um den Untraffekt weniger offensichtlich zu machen. Und ich nenne das Server Hardening. Aber es ist eigentlich nur das Server, der die Technik bereitet. Aber die Frage ist, wie können wir weniger vertrauen in den Server haben und können den Schaden verringern, der durch die durch das Bekannte Information entsteht und eine der Gründe, warum wir zentralisiertes Chatting haben. Es ist einfach sehr einfach, einen bestimmten Ansprechpunkt zu haben. Und man löst dadurch viele Probleme wie das Umgehen mit verschiedenen Geräten, Mobile Push zum Beispiel, sowohl Google und Apple erwarten oder haben einzelne autorisierte Provider herausgesucht, die das Recht haben, Push nachrichten zu senden. Das heißt, es ist dadurch absolut nötig, einen zentralisierten Ort zu haben, um diese zentralisierten Push Nachrichten an die Benutzer der Anwendungen zu geben. Und das Ergebnis ist, dass es also Kosten gibt. Es gibt eine Entität, die für die ganzen Kosten verantwortlich ist und das Geschäftsmodell konsoliert und das ist eine einzelne Entität, zu denen Leute gehen. Das ist nicht die einzige Art von Systemen, die es gibt, es gibt auch federierte Systeme. E-mail ist das bekannteste Beispiel und E-mail ist schön. Denn jetzt als Benutzerin-Benutzer kann ich einen Provider aussuchen, dem ich vertraue. Oder wenn ich niemanden kenne, dem ich vertraue, kann ich sogar meinen eigenen Service starten und habe also Dezentralisierung, was die ganze Sache zugänglicher macht. Und während ich versuche, mehr Vertrauen in meinen individuellen Provider aufzubauen, dann habe ich vielleicht immer noch nicht das Vertrauen in meinen Empfänger Bob hier. Ich weiß nicht, wie sicher seine Verbindung ist. Denn wir haben uns getrennt und haben das jetzt dezentralisiert. Die Verhältnisse sind auf allen Seiten verschieden und es gibt da so die ganzen Probleme, die sich damit ergeben, die Identität zu überprüfen oder sich gegenseitig zu finden. Und wir haben Systeme wie E-mail, das Fediverse, Riot-Chat und sogar SMS ist ein federites System. Es gibt sehr viele Provider und es ist also kein zentralisierter Ort, den es gibt für SMS. Und während wir nun diese Metapher fortsetzen, dann kommen wir zu einer Anzahl von dezentralisierten Systemen. Und das ist zu sagen der Rand, der Rand der Szene, es gibt so etwas wie Gossip, Secures Cuddlebot, wo die Leute, wo man Nachrichten bekommt, die zu den intendierten Partnern kommen, aber man leitet auch selbst Nachrichten weiter, die auf dem Weg zu Leuten in der Nähe sind. Das ist eine Gegend, in der wir immer noch dazulernen, der Ausgleich zwischen dem bekannt werden von Metadaten aber die Dezentralisierung ist ja ein schönes Feature. Und das Ding ist, dass viele Leute hier eine Zeithaber haben mit relativ geringem Trast, das werden hier Ding im Nutz für die Hashtables in Bittorrent. Man sieht das in Dingen wie Ricochet oder ToxChat. Das sind torainliche Weiterleitungssysteme, wo das Routing verteilt ist. Alle Beteiligten haben ein Teil des Wissens über das Routing. Nun, wenn wir uns einiges dieser Mechanismen zu, die wir gerade besprochen haben, wir fangen an mit Verschlüsselung. Wenn man einem Server in der Nachricht sendet, dann gibt es zunächst mal von Anfang an keine Verschlüsselung. Das ist die Art, wie EEC und E-Mail funktionierte in der Anfangszeit. Und das muss betrachtet werden wie eine Postkarte. Wir haben also eine Nachricht, die wir schicken wollen und die Karte enthält sowohl die Kommunikationsdaten von wem an wem als auch den Inhalt. Wenn wir nun stattdessen Transportverschlüsselung einsetzen, was heutzutage Standard für die meisten zentralisierten Dienste ist. Das heißt, man steckt die Postkarte nun in den Umschlag, dass das Netzwerk, den das Netzwerk nicht öffnen kann. Wir haben also TLS oder irgendwelche andere Transportverschlüsselung. Die Verbindung sieht nur Quelle und Ziel der Kommunikation. Also alles an Facebook oder welcher Provider auch immer. Aber das Netzwerk kann nicht in die Nachricht hineinschauen, in den Inhalt der Nachricht. Es sieht nur, dass hier Kommunikation zwischen Individuen und dem Provider stattfindet. SMTPS gibt also gesicherte E-Mail auf diese Art und Weise und andere Protokolle, die anderen beteiligten Protokolle, können alle gesichert werden auf diese Weise. Und was wir jetzt haben, was wir auch haben, ist sogenannte Ende-zu-Ende-Verschlüsselung. Und der Unterschied hier ist, dass die Nachricht, die alles schickt, die ist an Bob adressiert und sie ist so verschlüsselt, dass der Provider, zum Beispiel Facebook, das auch nicht öffnen kann und nicht in Inhalt anschauen kann. Okay? Das Netzwerk sieht nur eine Nachricht, die von Alice zu Facebook geht. Wie vorher, aber Facebook kann die Inhalte nicht einsehen. Also Ende-zu-Ende-Verschlüsselung ist inzwischen sehr beliebt. Es wird immer populärer. Wir haben es in Signal, in iMessage, großen Trösten-Teils. Wir haben PGP, GPG, die das in E-Mail implementieren. Und das Signalprotokoll, das ursprünglich Axolotl hieß, wurde inzwischen aufgenommen in WhatsApp, Facebook-Privatnachrichten. Und ich glaube, es ist jetzt verallgemeinert worden, in etwas, was sich das Noise-Framework nennt. Und das verbreitet sich weiter. OMEMO sieht sehr ähnlich aus, speziell für XMPP-Kommunikation. Das ist eine spezielle Implementierung. Und die andere Implementierung ist OTR of the Record. Das hat sich ein bisschen unabhängig von diesem Framework entwickelt. Dinge wie Abstreitbarkeit sind hier ein Thema. Ich gehe hier nicht zu tief in die Details der einzelnen Protokolle. Aber die Intuition ist, das Schwierige ist nicht die Verschlüsselung an sich, sondern das Schwierige ist, wie schickt man diese erste Nachricht und etabliert den verschlüsselten Kanal, insbesondere, wenn die andere Seite nicht gerade online ist. Ich fange also an zu schreiben und möchte jemanden erreichen. Dann muss ich irgendwie einen Schlüssel bekommen und eine Nachricht schicken, die nur für die andere Seite lesbar ist. Und ich muss irgendwie ein Geheimnis teilen. Und wenn das andere Gerät nicht online ist, ist das schwierig. Außerdem herauszufinden, wie User und Devices Geräte zusammenhängen. Und Geräte können wieder herausgenommen aus der Kommunikation und andere hereingenommen, ohne dass jetzt Schlüssel ungültig werden oder zu viele Fehlermeldungen erscheinen oder Warnungen. Und das ist tatsächlich die Hauptschwierigkeit in diesen Systemen. Es gibt zwei Probleme, die hier in Spiel kommen, wenn wir Ende zu Ende Verschlüsselung benutzen. Das erste ist, wenn es darum geht, die Verbindung zunächst einmal aufzunehmen. Das ist das Problem zu sagen, wer ist Bob? Ich habe einen Kontakt und ich habe dafür zum Beispiel eine E-Mail-Adresse, eine Telefonnummer, Signal benutzt Telefonnummern. Viele benutzen E-Mail-Adressen. Es gibt Dinge wie 3-mal, die eigene Identifier benutzen, die sie generieren für dich. Aber von diesem Identifier muss man nun eigentlich einen Schlüssel bekommen für die Kryptografie, die man betreiben will. Und ich muss herausfinden, wem ich vertraue, um diese Übersetzung in den Schlüssel zu machen. Und die Frage ist, wie gleichen wir uns ab? Einige Systeme tun das, indem das Adressbuch hochgeladen wird oder mit existierenden Kontakten abgeglichen wird, um das Problem im User-Interface zu lesen, das Problem, das sich gegenseitig findet. Wenn wir schon wissen, welche Identifier es gibt, dann müssen wir diese Zuordnung machen und wir müssen dann diese Schlüssel finden und wir müssen also den Server vertrauen, dass der Server das Adressbuch hat und diese Zuordnung machen kann zwischen Identifier und Schlüsseln. Signal ist hier schön. Es sagt, dass es nicht die Kontakte hochlädt. Das stimmt. Sie laden Herrschwerte der Telefonnummern hoch. Aber es ist etwas Ähnliches. Sie haben hier ein Verzeichnis der Identifier oder der geherrschter Identifier. Und wenn Leute suchen, dann suchen wir nach einem Herrschter Telefonnummer und erhalten dann den Schlüssel, den Signal hoffentlich dir korrekt mitteilt. Also es gibt einige Möglichkeiten, wie man mit geringerem Vertrauen arbeiten kann. Signal hat einen Weg eingeschlagen, indem sie SGX verwenden, um die Kosten eines Angriffs zu erhöhen und einige Mechanismen, mit denen man die Kosten eines Angriffs erhöhen kann, einen Angriff auf den Erkennungsmechanismus. Der andere Weg, den man gehen kann, ist, dass man es erlaubt, dass Leute pseudonyme oder anonyme Identifier benutzen. Und nun ist der Schaden für dich dann geringer, wenn das bekannt wird. Und morgen um vier gibt es ein Talk von mir über die Evolution des Umfelds von Signal. Und da werden wir dich mehr tiefe dann bringen zu diesem Punkt. Was ist, wenn wir nun dem selber nicht vertrauen für diese Zuordnung? Eine der frühen Dinge, die es gegeben hat, ist das Web of Just in GPG oder PGP. Und das ist der Idee, die ich auch im normalen Leben habe, wenn ich einen Identifier mit einem Schlüssel verbinden möchte, dann kann ich öffentlich auch bekannt geben, dass ich dieser Zuordnung vertraue und Leute, die jemanden nicht kennen, aber eine soziale Verbindung haben, dann diese Statements finden und ihreseits dann Vertrauen aufbauen in diese Statements. Ich vertraue jemanden, der gesagt hat, ja, dieser Identifier ist mit diesem Schlüssel verbunden und dann kann ich dieses Vertrauen in dieses Netzwerk verwenden, um den Identifier oder den Schlüssel zu finden, dem ich vertraue. Es gibt einen gewissen Balance im User-Interface hier. Es gibt z.B. die Nilo-Service-Angriffe auf die Infrastruktur. Dieser spezielle Angriff ist, dass alle Menschen diese Vertrauensstatements hochladen können. Und wenn man dann die gesammelten Statements herunterlädt, kann man also überwältigt werden von der anderen Seite der Daten. Es gibt hier keine Filterung, die ich einbauen kann, um nur die Statements herunterzuladen, die ich brauche für meine Situation, ohne das dem Server mitzuteilen. Keybase hat einen anderen Zugang. Die Beobachtung hier ist, dass wenn ich mit jemandem spreche, ist, dass dann es mich kümmert. Es geht darum, dass die Person einen bestimmten GitHub-Account oder Twitter-Account hat. Nun wird Keybase mitgeteilt, dass hier ein Schlüssel ist, um diesen Twitter-Account oder Reddit-Account oder Facebook-Account zu geordnet ist. Um dieses Vertrauen zu haben, diese Beweise, kann ich einfangen, eine kryptografischen Identität zu vertrauen mit der Person, die vielleicht die Passwörter für diese Accounts hat und so etwas. Keybase hat an diesem Jahr auch angefangen, einen finanziellen Anreiz zu bieten und für die Nutzung und so besser zu beweisen, ob er kann es zu echten Menschen gehören. Auf unseren Geräten haben wir meistens die Lösung, dass wir TOFU benutzen, also bei erster Benutzung Vertrauen. Das heißt, wenn ich als erstes das erste Benutzung vertraue, und wenn ich dann wieder mit dieser Person kommunizieren möchte, dann habe ich schon einen Schlüssel und ich kann diesen Schlüssel benutzen und ich kann davon ausgehen, dass dieser Schlüssel gleich bleiben wird. Und diese Kontinuität, dieses Weiterführen und dieses Ausgehen davon, dass ein Schlüssel gleich bleibt, dass es die gleiche Person ist, das darf sich dann nicht ändern. Das ist plötzlich eine andere Person, dass sie den gleichen Schlüssel benutzt. Und schließlich eine aufregende Sache, wenn sie 15 rauskam, das leider nicht mehr funktioniert, war ein System, das Pond heißt, und da geht es um eine gehertete, moderne Vision von E-Mail. Eine Sache, die Pond hatte, war eine Passwort-gestützte Schlüssel-Austausch und das ist eine kryptografische Bereich, bei dem man davon ausgeht, dass wenn zwei Menschen mit einem schwachen, geheimnisgestützten Austausch arbeiten oder anfangen, wenn man zum Beispiel sagt, jetzt, wo arbeitet jemand heute? Und man hat ein paar solche Feature und beide können die gleiche Antwort geben, die gleiche textbasierte Antwort, dann können wir davon Schlüssel ableiten und gemeinsam neue Geheimnisse erzeugen und damit stärkere Schlüssel ableiten. Also Pond hat ein System, das sie Panda nennt, um zwei Individuen zu verbinden über eine Challenge-Response und das wird auch vielen Java benutzt. Das andere Thema, mit dem wir uns wirklich aufpassen müssen, ist die Neuabilität oder Abstreitbarkeit. Wenn wir in einer 1 zu 1 Verbindung mit jemandem reden, dann ist dieses Gespräch noch ziemlich abstreitbar. Beide Personen können ihre Erinnerung haben, was passiert ist und es gibt keinen Nachweis, was wirklich gesprochen wurde und was wirklich passiert ist, solange keine weitere Technologie dabei ist. Aber bei einer verschlüsselten Kommunikation, da ist schon ein gewisser Nachweis dar, dass wirklich die Person gesagt hat, von der ich davon ausgehe, weil sie den passenden Schlüssel verwendet hat. Und wir sehen jetzt zunehmend auch Dinge, dass E-Mails, die einfach der Öffentlichkeit bekannt werden, genauso nachgewiesen wurden oder einer Person zugeordnet werden, weil sie verschlüsselt waren. Hier haben wir zum Beispiel Hillary Clinton's E-Mails und wir können sicher sein, dass der Text nicht verändert wurde und dass er wirklich von diesem Server kam, was behauptet wird, weil der Schlüssel passt. Und was jetzt einfach mit eingeführt werden soll, ist die Neuabilität oder Abstreitbarkeit. Und da geht es vor allem um Vorwärtsgeheimhaltung. Also wir wollen Dinge so wegwerfen, dass unsere Kommunikation wieder vergänglicher wird. Und es gibt hier zwei zusammenhängende Eigenschaften. Wir haben Schlüssel, die wir benutzen, um unsere gemeinsame Kommunikation aufzubauen und um unsere geheime Nachrichten zu haben. Und jedes Mal, wenn wir eine Nachricht schicken, dann gibt es immer ein neues Schlüsselmaterial dazu, also ein neues Geheimnis. Und dadurch ändern wir den Schlüssel. Und wenn Bob jetzt antwortet, dann benutzt er den nächsten Schlüssel und gibt mir gleichzeitig seinen neuen Schlüssel. Und was ich dann auch machen kann, ist, dass wenn ich eine Nachricht schicke, dass ich das Geheimnis meines letzten Schlüssel schicke. Ich kann also sagen, mein altes Geheimnis war dieses hier und jetzt sind dann, weil spätere Nachrichten alle Schlüssel bekannt, das heißt, jeder hätte das gesamte Gespräch fälschen können. Also zu jeder gegebenen Zeit ist nur die letzte gesendete Nachricht wirklich authentiziert, dass sie spezifisch von einer Person kommt. Und das gesamte Lok oder der gesamtes Gesprächsverlauf hätte gefälscht werden können. Und da gibt es jetzt eine Version 4, wo es heute um 9 Uhr tiefer eingestiegen wird. Da geht es dann wirklich mehr darum und ich kann nur empfehlen, dass ihr euch das genau anschaut. Das nächste Thema ist ablaufende Nachrichten oder auslaufende Nachrichten. Das ist sehr eng verwandt mit Forward Secrecy. Und hier gibt es ein paar Angriffe, die man betrachten muss. Und hier muss man denken, denke ich, Snapchat ein bisschen Credit geben und dass sie das bekannt gemacht haben. Und zwar, dass die Nachrichten nach einer Weile einfach verloren gehen oder verschwinden. Und da ist kritisch, dass sich einer Person einfach nicht vertrauen muss, dass sie das später nicht teilt. Und hier gibt es natürlich auch Angriffe drauf. Wenn jetzt zum Beispiel jemand ein Screenshot macht, dann kann man davon gewarnt werden. Und deswegen blenden einige Apps auch den Screen aus, wenn man auf den Task Manager geht. Also wenn ich zwischen zwei Apps hin und her wechsle, dann zeigen einige Applications einfach nur einen leeren Screen an. Und das ist, weil das Betriebssystem den Apps einfach nicht erzählt, was der andere Screen hat und das verhindert, dass man Screenshots macht. Aber das ist jetzt mehr ein soziales Kosten. Also es wird nur erschwert, ein Screenshot zu machen. Natürlich könnte ich immer noch eine andere Kamera benutzen, um ein Screenshot anzufertigen. Aber es wird schwieriger, es wird erschwert und das ist mehr ein sozialer Effekt. Das nächste Problem ist, dass ein Gerät komplementiert wird, nachdem die Kommunikation stattfindet. Also wenn ich jetzt mein Handy verliere und jemand findet das, dann kann er natürlich die alten Nachrichten lesen oder es wird eine bösartige App installiert, die das Telefon scant und die ganzen Nachrichten liest. Das passiert jetzt gerade in China. Und auch das ist jetzt wieder eine Frage des User-Interfaces und der Nutzererfahrung. Also wie lange müsste ich jetzt Nachrichten speichern? Wie sind die Normen? Und da gibt es natürlich auch wieder in Trade-Off. Manchmal ist es nützlich, alte Nachrichten lesen zu können. Insbesondere für Firmen, die glauben, dass sie, die damit ihr Geschäftsmodell aufbauen, dass sie Datenanalyse machen, die wollen natürlich ihre Daten nicht verlieren. Das nächste Thema ist Isolation oder Sandboxing. Sehr viel davon ist eine Stufe weiter abstrahiert. Also was können wir tun, um unsere Applikation von anderen Programmen, Viren oder Schadsoftware zu isolieren und zu schützen? Wir haben ein paar Projekte, die damit tun haben und die das weiterführen. Es gibt Schad-Systeme, die versuchen, das einzeln zu machen. Ein extremes Beispiel ist Tinfoil-Head oder Alufolien-Chad. Die besuchen drei verschiedene Geräte und eine Diode. Und es gibt einen Gerät, das nur sendet, einen Gerät, das nur empfängt. Und die Idee ist, dass wenn du eine Nachricht bekommst, dass dein Gerät kompromittiert, irgendwie ein Virus oder irgendwas, dann kann dieser Virus nie wieder nach außen telefonieren oder sich nach draußen melden. Hier sieht man ein kleines Beispiel, wie das dann ein Hardware aussehen könnte. Die andere Seite dessen ist Recovery-Backups, also Daten-Wiederherstellung und Backups. Man hat jetzt hier auch wieder ein User-Experience oder ein Nutzer-Experience-Trade-Off. Das heißt, wenn jetzt jemand sein Gerät verliert, dann möchte er natürlich seine Kontaktliste wiederbekommen. Aber ein Backup ist auch immer ein Problem, dass es ein weiterer Ort ist, wo man kompromittiert werden kann oder angegriffen werden kann. Apple hat hier vor ein paar Jahren ein Backup-Talk gegeben oder ein Vortrag, wie Sie das Problem gelöst haben. Und die haben ein extra Chip für die iCloud. Und in diesem extra Chip sind die Schlüssel dann gespeichert. Und hier gibt es jetzt eine große Anzahl an Angreifern und viel mehr, als man meistens denkt. Also wenn jetzt beispielsweise eine Regierung ankommt und einen Angriff verlangt, was kann man da machen? Und hier Apple kann jetzt nicht einfach einen Angriff dazu schreiben. Und das ist einfach auch ein Schritt oder ein wichtiger Punkt in Cloud Security in der Cloud, worüber nicht viel nachgedacht wird. Dieses slides werden natürlich auch online sein. Und es kann sich lohnen, sich ihre Lösung anzusehen, weil hier eine große Anzahl möglicher Angreifer betrachtet wird, an die man möglich nicht gedacht hat. Traffic Objuscation oder Nachrichtenversteckung oder Kommunikationsverstecken. Es geht hier darum, Nachrichten zu verstecken. Und wenn Menschen denken, dass sie das tun müssen, dann gibt es eine Möglichkeit Domain Fronting. Das hatte so seine Hochzeit in 2013, ist seitdem etwas zurückgegangen. Die Idee dahinter ist, dass es wieder mehrere Abstraktionsebenen gibt zwischen dem Umschlag und der Nachricht, die sich darin befindet. Und ich erstelle jetzt eine sichere Verbindung zu einem Content Provider wie Amazon oder Microsoft. Und dann stelle ich diese Verbindung her. Und der Security Layer ist, dass ich einen sehr generischen Service hier aufsetze. Und dann ist es wie ein Tunnel, dass dieser generische Web-Service das Weiterleid ist zu einem spezifischen Kunden. Das ist ein effektiver Werk, um dem Netzwerk zu verheimlichen welchen Service ich jetzt hier genau benutze. Und das wurde leider sehr viel für Mallware oder für Viren und Schadsoftware verwendet, was dazu gesorgt hat, dass viele Provider das nicht mehr erlauben. Zum Beispiel Telegram verwendet das auch. Und es geht um die gleiche grundlegende Technologie über verschlüsselte SNI. Und diese Techniken erlauben einen standardisierten Ansatz und eine standardisierte Verbindungsherstellung zu dem Dienst, den man verwenden möchte. Man sollte auch erwähnen, dass momentan der aktivste Chatservice, der diese Verschleierung verwendet, Telegram ist. Und da gibt es ja auch Benutzer, die in bestimmten Ländern sitzen. Und denen erlaubt es dann, dass sie verschiedene IPs verwenden können. Und die dann zum Beispiel auch Nachrichten durch DNS-Tunnel senden können. Und so Zensur umgehen können. Für die Provider geht es dann natürlich um die Nutzer. Die denken nicht so sehr ans lokale Netzwerk und die Anzahl der Benutzer. Also wir können vielleicht Eigenschaften unseres Traffics verstecken. Es gibt aber auch andere Eigenschaften von Traffic. Und da sind es zum Beispiel Metadaten, an die wir denken müssen. Das geht es zum Beispiel im Padding. Da geht es um die Größe der Nachrichten. Also mein Chat hat ja zum Beispiel eine ganz andere Dateigröße als Bilder zum Beispiel. Und das kann man dann an der jeweiligen verwendeten Bandbreite erkennen, was da gesendet wurde. Es gab Forschungen, die gezeigt haben, dass es bei Sprachdaten, selbst bei verschlüsselten Sprachdaten kann man anhand der Größe erkennen, was für Geräusche übertragen wurden. Wir können etwas sagen, und das kann dann komprimiert und verschlüsselt werden. Und da gab es ein Paper 2011, was gezeigt hat, dass das eine Möglichkeit für Angriffe ist. Daraus können wir lernen, dass es immer ein Trade-off gibt zwischen den Daten, die wir übertragen und den Daten, die wir freigeben und unserer Sicherheit. Und wir sehen da auch Mustards, wann Leute aktiv sind, wann sendet zum Beispiel jemand Tweets ab oder sendet Nachrichten, das ist eben auch relevant für diese Metadaten-Angriffe. Man schaut sich also die relative Aktivität verschiedener Leute an und zieht daraus Schlüsse. Also wenn alles zum Beispiel eine Nachricht sendet, kann man gucken, wer war zur gleichen Zeit online, mit wem kann sie also kommuniziert haben. Bei Pond gibt es einen Ansatz, dass man immer online gezeigt wird. Und es gibt dann halt ein reguläres Muster mit dem Anmeldung am Server. Und von der Netzwerkerspektive sieht dann also jeder Nutzergleich aus, das Problem daran ist, dass halt jeder Kleint jederzeit Nachrichten senden muss und es gibt einen großen Overhead. Und da werden jede Menge sinnlose Datenversand eigentlich. Als Letztes wollen wir uns die Server-Härtung anschauen. Es gibt einige Beispiele dafür, warum wir das unbedingt machen wollen. Oft sind Servers nicht so sicher, wie sie es behaupten. Zum Beispiel die Skype-Niederlassung in China hat Blacklist verwendet, um Nachrichten abzufangen. Und die haben das niemanden verraten. Und dann ist die Zukunft natürlich auch unsicher. Also wir wissen nicht, was der Server-Betreiber, den ich benutze, in der Zukunft vielleicht noch alles macht. Und wichtig ist dabei auch, dass Software-Entwicklung sehr zentralisiert ist. Auch wenn ich den Server nicht vertraue, kann ich auch den Updates auf dem Server vertrauen. Open Source ist da ein sehr guter Ansatz, um dieses Vertrauen zu stärken. Wir müssen uns angucken, was der Server alles weiß. Und der Verschlüsselung ist, der Server kennt die Größe und auch die Quelle. Wir haben zum Beispiel jetzt gerade bei der Größe über das Padding gesprochen. Damit können wir quasi diese Informationen ein bisschen verschleiern, die durch die Größe übermittelt werden. Und dann gibt es noch diese Linkability. Wie kann man Sender und Empfänger dieser Nachricht verbinden? Es gibt da einige Mechanismen, mit denen man das reduzieren kann, diese Verlinkbarkeit. Zum Beispiel kann auch die Quelle der Nachricht in einem separaten Umschlag verschlüsselt werden. Und diese Logs, die werden sehr bald verworfen, damit es da nicht so eine Datenansammlung gibt. In der Theorie steckt da eine Menge dahinter. Wir haben ein sogenanntes Mixnet-Netz. Und da haben wir also mehrere Provider, die die Server verbinden. Und die User senden also an den ersten Provider die Nachricht und der vermischt das. Und dann geht es zum nächsten Provider und der vermischt das wieder. Und dann geht es dann an die Zieladresse. Die Provider wissen also alle, weder den Sender noch den Empfänger der Nachricht. Da gibt es aber ein paar kleine technische Unterschiede. Normalerweise wird eine bestimmte Anzahl an Nachrichten abgewartet. Und so kann man theoretisch garantieren, dass es in der selben Stapel Nachrichten eine bestimmte Anzahl Nachrichten gewesen ist. Und so hat man eine stärkere theoretische Sicherheit. Es gibt ein momentan aktives Projekt, das heißt Katzenpost. Und da könnt ihr auch gerne mal auf die Webseite schauen. Das ist ganz interessant. Ich habe da noch ein interessantes Projekt, das heißt Private Information Retrieval. Wir haben einen anderen Ansatz an diese Fragestellung. Also wenn ein Server eine Datenbank mit Nachrichten hat und eine Nachricht soll abgerufen werden, ohne dass der Server das mitbekommt. Das klingt schwer. Aber es ist tatsächlich machbar. Man kann die gesamte Datenbank des Servers abfragen und dann die einzelnen Nachricht rausfiltern und danach weiß der Server nicht, welche Nachricht rausgefiltert wurde. Da gibt es mehrere Konstruktionen, die das erlauben. Und dadurch erhält man eben diese theoretische private Abfrage. Und das ist ähnlich wie das Bedrohungsmodell von Mixnetz. Wir können davon ausgehen, dass nicht alle Server miteinander kommunizieren. Wir werden hier eine Exclusive Oil-Operatur verwenden. Also wenn wir einen Zugriff auf die Ressource selbst haben, dann schließt es sich aus. Ich habe also Systeme, die Datenbanken haben. Und ich kann jedes System fragen, Anfragen, dass es mir ein Datenbankensatz gibt. Und ich sage dem Server zum Beispiel, gibt mir mal die folgenden drei Datensätze. Und die bekomme ich dann. Und wenn ich das dann strukturiere, dann kann ich jeden im Server individuell anfragen. Mit einem Subset. Und wenn ich das dann zurückbekomme, dann schließt es sich gegenseitig aus. Und man kann also nicht mehr genau sehen, welchen Datensatz es angefragt habe. Man könnte jetzt vielleicht denken, dass ich da sehr viel Anforderungen an den Server stelle. Und das klingt nach einer ganzen Menge Arbeit. Aber was ich daran so aufregend finde, ist, dass man eine große Datenbank abfragt. Und man dann nur einen kleinen Datensatz zurückbekommt. Das funktioniert ganz gut. Und wir haben ganz viele Kerne, die kleine Verarbeitungsanfragen durchführen. Und diese Datenbanken enthalten ja zirke Gigabyte an Daten. Und das wird innerhalb von Millisekunden übertragen. Telec ist das System, wo ich selbst mitgearbeitet habe. Und es geht darum, wie man ein Item auf einen Datenbank überträgt, ohne dass die Datenbank das mitbekommt. Es ist nicht so einfach zu erklären. Aber da gab es signifikante Fortschritte in den letzten Monaten. Zum Beispiel ein Forscher aus Stanford hat daran gearbeitet. Und man kann diese Operation jetzt also ziemlich praktikabel durchführen. Zum Abschluss würde ich gerne noch über Gruppenchats sprechen. Also Chats in kleinen Gruppen. Da gibt es verschiedene Möglichkeiten, wie das durchgeführt werden kann. Man kann dem Server quasi nicht erzählen, dass es diese Gruppe gibt. Ich sende die Nachricht also einfach an jeden in der Gruppe, ohne dass der Server mitbekommt, dass es eine Gruppe ist. Oder man macht es effizienter. Und man sagt dem Server quasi, dass man eine Mitgliedschaft in einer Gruppe hat. Und auch wenn man das dem Server nicht mitteilt, muss man sich trotzdem ein paar Sorgen über Angriffe machen. Denn wenn jemand die selbe Nachricht in Größe an fünf Leute sendet und dann wieder einer dieser fünf Leute eine bestimmte Nachricht in Größe an die fünf anderen Leute schickt, dann ist das auffällig. Und das kann man nicht so einfach verschleiern. Dann geht es natürlich auch wieder um die Abstreitbarkeit. Wenn diese Logs also bei mehreren Leuten vorliegen, könnte das zwar jeder geschrieben haben, aber wenn man die gleichen Schlüssel hat, dann ist das natürlich trotzdem klar, dass man Part dieser Gruppen Nachricht gewesen ist. Ein Signal arbeitet da an einem Modell für zentralisierten Zugriff. Und wahrscheinlich wird der Server da in manchen Fällen mitbekommen, dass es um eine Gruppenmitgliedschaft gibt. Aber es gibt dort ein ganz cooles System, das heißt Quitch. Und das ist eine Erweiterung zu Wikishay. Und da kann man fünf bis 20 Leute in der Gruppenkonversation teilhaben lassen. Und die Nachrichten werden quasi an jeden verbundenen Teilnehmer weitergeleitet. Der Server sendet die Nachricht an diese Erweiterung und weiß dann also nicht, mit welcher Gruppe er tatsächlich verbunden ist. Das ist nicht unbedingt skalierbar auf größere Gruppen, man kann trotzdem die Gruppenmitgliedschaft verstecken. Und das ist eine sehr nette Anwendung, um sowas in der Praxis stattfinden zu lassen. So, als letzten Gedanken würde ich gerne noch anbringen. Es gibt sehr viele Systeme, aber in der Community ist es sehr wichtig, dass es da eben im Privaten-Chats Innovationen gibt. Und das ist eine ganz unglaublich wichtige Sache, an der wir da arbeiten. Und wir suchen immer nach neuen Möglichkeiten, diese Trade-offs auszubalancieren. Denn wir möchten, dass möglichst viele Leute darüber Bescheid wissen, welche Mechanismen es dafür gibt. Gibt es denn Fragen? Beliebtheit und Unabhängigkeit sind ein Widerspruch. Wie kann ich sicher sein, dass ein immer beliebter werdener Messenger unabhängig bleibt? Ich würde, glaube ich, in Frage stellen, ob Unabhängigkeit an sich ein Ziel ist. Es stimmt, dass der Wert so nimmt. Etwas, worüber man nachdenken sollte, ist, dass es nicht so wichtig ist, dass die Systeme zu benutzen, die auf eine Protokolle verwenden oder federiert sind und nicht zentralisiert. Und das ist etwas, die Frage ist, wie man hier Vertrauen in das zukünftige Geschäftsmodell aufbauen kann. Ich weiß nicht, was mit Sachen Unabhängigkeit, ob die Unabhängigkeit eine Firma hier, das ist, was man mit der Popularität aber liebtheit ausbalancieren möchte. Vielen Dank für den Vortrag. Es ging viel um Inhalt und Verschlüsselung. Aber was ist jetzt mit dem ursprünglichen Problem? Die Geschichte zeigt, dass, wenn ich eine Einzelperson bin und überwacht werde, dann ist es vielleicht gar nicht zielführend, etwas zu verschlüsseln. Es ist ja vielleicht schon alles bekannt, dass der Inhalt, die Uhrzeit, also gibt es da vielleicht eine Möglichkeit, da was zu tun? Also, das Ding werden nachträglich noch zu verstecken. Das scheint sehr schwer zu sein. Ja, es gibt ein paar Gedanken vielleicht an diesem Punkt. Diese Schnittstelle mit der realen Welt und der Angriff da, wenn ich eine in der realen Welt beobachtbare Aktion gibt, dann ein Protest. Das ist eine ziemlich gute Art und Weise herauszufinden, wer z.B. vorher über diesen Protest sich unterhält. Und ich glaube, was wir gesehen haben in der politischen Organisation, in der wirklichen Welt, ist, wenn man das zentralisiert und verschiedene Plattformen verwendet. Und wir haben Dinge, die dann spontan kurz vor dem Ereignis passieren, sodass man nicht viel Zeit hat, auf der Gegenseite zu reagieren. Die Anwesenheit zu verstecken oder die Aktionen schwerer verbindbar zu machen, die eigenen mit dem Ereignis. Das ist nicht etwas, was Chatsysteme hier, das gerede ich nicht mehr bei Chatsysteme. Also, wenn die Übersetzungen von Netzwerkadressen das ursprüngliche Problem sind und wenn wir deswegen jetzt Server laufen lassen müssen, die jemand bezahlen muss, gibt es dafür eine gute Lösung für das wirtschaftliche Problem. Wir müssen einige bezahlen, auch ohne Netzwerkadress-Translation. Und wir verschieben nun mehr dieser Kosten an die End-User-Vennen. Also, wir haben also hier die Möglichkeit mit IP6, um die Kosten zu verteilen und mehr Zentralisierungen in den Protokollen zu haben, wo die Kosten dann fairer verteilt sind. Unsere Telefone haben einen unglaublichen Rechenleistungsmöglichkeit. Also... Und ich denke, was die Interesse mit den Protokollen passiert, ist eine Balance, die sich entwickelt. Und ich glaube, einige der Gründe, warum Netzwerkadress-Translation oder Zentralisierung so häufig vorkommt, ist, oder Zentralisierung, ist, weil diese anderen Systeme sehr schwer sind. Und sehr schwer ist, Vertrauen in sie aufzubauen. Je mehr Werkzeuge wir zum Testen einsetzen können, um zu verstehen, dass ein System wirklich funktionieren wird in der allergrößten Zeit, für verteilte Systeme ist das wichtig, um Leute weniger zögerlich zu machen, um das zu bewenden. Wir haben noch eine Frage aus dem Internet. Was ist deine Meinung dazu? Technische Neulinge im Umgang zu geheimen Schlüsseln zu instruieren? Ja, ich denke, das hat mit vielen Problemen dieses Trade-offs zu tun. Wir haben erste Version vom Signal gesehen, wo man versuchte, regulär bestimmte QR-Codes zu verheizieren untereinander, immer wieder. Und dann wurde dies zurückverschoben zu schwieriger, zugängliche Teilen, schwerer, zugängliche Teil des User-Interface. Es waren Leute, die es nicht gerne nutzen. In Matrix & Ride bekam man früher sehr viele Warnungen, hier ist ein neues Gerät mit zu verifizieren, nur zu den vorher schon bekannten Geräten Nachrichten schicken. Und das ist inzwischen automatischer, um diese Veränderung zu akzeptieren. Dadurch wird ein gewisser Teil der Verschlüsselung Sicherheit geschwächt, aber das User-Interface wird besser nutzbar. Weil viele Leute sowieso einfach ja klicken, weil sie die Nachricht einfach schicken wollen. Inzwischen der Protokoll-Sicherheit, die dann im Weg steht, zwischen dir und dem, was du tun möchtest, dann ist das eigentlich keine Art, um diese Reibung da mit einzubauen. Weil sie suchen also andere Wege, wie man das sozusagen auf der Seite haben kann. Und die Kommunikation eher unterstützt, anstatt sie zu verhindern. Und das ist wahrscheinlich die Art von User-Interface und Systemen, über die wir nachdenken sollten, die Erfolg haben werden. Noch mal Danke für den Vortrag. Es ging darum auch über Abstreibbarkeit, indem man den privaten Schlüssel einfach weiter schickt. Aber woher kriege ich jetzt die einzelne Schlüssel in der gesamten Konversation? In OTR XMPP Java-Systemen wird es eine explizite Aktion geben, um die Konversation zu beenden. Und dann kann man das abstreibbar machen, wenn diese finale Nachricht zum Schließen gesendet wird. Und wenn man Dinge hat wie Signal, dann ist es so, dass jede Nachricht Teil der Bestätigung ist. Also erst ein kurzer Kommentar. Der Riot hat das noch nicht ganz herausbekommen. Aber ich denke, da gibt es noch eine viel subtilere Gespräche, das passieren muss, wenn man mit unterschiedlichen Machtverhältnissen eine nicht-abstreibbare Konversation eigentlich besser für die schwache Person, also in den meisten Chat-Nachrichten möchte man eigentlich keine Abstreibbarkeit außer. Das ist immer noch etwas subtiler als das. Wenn man nämlich gleichmächtige Gesprächsteilnehmer hat, dann ist es etwas seltsam. Und ich denke, der andere Teil ist, das ist etwas, was die User sehen sollten. Es ist hier ein Konzept, wie man diesen Begriff, dieses Idee ausdrückt in allerverständlichen Weise, sodass gute Entscheidungen getroffen werden können. Anstatt dass das System Entscheidungen für alle User selbst trifft. Hi, danke für den Vortrag. Es ging um private Informationsabholung und wie das den Server davon abhält zu wissen, wer eine Nachricht abholt. Aber für mich ist jetzt die Frage, woher weiß ich überhaupt, welche Nachricht für mich ist. Weil wenn ich jetzt beispielsweise immer den Port 14 nehme, dann ist natürlich im Laufe eines Gesprächs immer eindeutiger oder einfacher zu deanonymisieren, wer jetzt der User ist, weil der immer genau diesen einen Slot für Nachrichten angreift. Ja, genau, das habe ich nicht erklärt. Der Trick ist, zwischen den beiden Beteiligten haben wir ein geteiltes Geheimnis. Das ist unser Konversationsgeheimnis. Und wenn wir dieses Geheimnis nutzen, dafür einen Pseudo-Zufallsgenerator zu starten, wir haben jetzt also denselben Strom von Zufallszahlen. Und jede nächste Nachricht wird nun zu dem Ort gehen, der durch das nächste Glied in dieser Zufallszahlenkette angegeben wird. Die Person, die schreibt, kann einen Zufall für den Stellen schreiben. Und wenn die nächste Nachricht in dieser Kompensation geschrieben werden soll, dann wird das eben an denselben, an dem nächsten Ort in dieser Zufallszahlenkette geschrieben. Und es gibt da ein Papier, das einige andere Systeme dieser Art beschreibt. Aber das ist ein anderes Thema. Noch eine Frage aus dem Internet. Es scheint so, als wäre Identität der Schwachpunkt in Nachrichts-Apps. Wie ändern wir, wie lösen wir dieses Problem, dass wir die Unik Identifier brauchen? Identität ist schwer. Ich denke, es war immer schwer und wird auch schwer bleiben. Eine Vielfalt von Wegen zu haben, um das zu identifizieren, bleibt meiner Meinung nach wichtig. Und das ist kein einzelnes System, das jetzt alles gewinnt. Es wird immer verschiedene Chat-Protokolle für verschiedene Kreise geben, in denen man sich befindet. Und Teil davon ist unser Wunsch, nicht eine einzelne Identität zu haben, die übergefunden wird, die Aspekte unserer Persönlichkeit zu haben. Es gibt Systeme, in denen man sich identifizieren kann mit einem eindeutigen Identifier, für jede einzelne Person, mit der man spricht. Und dass es einen einzelnen Identifier im gesamten System gibt. Und ich denke, dass der Identifier, den man verschiedenen Menschen gibt, verschieden ist. Und so erscheint man dann als für völlig andere Persönlichkeiten verschiedenen Kombinationen. Und es ist plötzlich sehr schwer, wenn ich einen Identifier veröffentliche, dann ist dieser Identifier für mich verbunden, für alle, die diesen Identifier benutzen. Ich muss also den Identifier privat verteilen und das beschränkt die Entdeckbarkeit. Also das, worum es hier geht, ist, dass Identität tatsächlich an sich ein schwieriges Problem ist, ein chaotisches Problem ist. Und das war die letzte Frage. Vielen Dank. Bitte einen großen Applaus für den Speaker.