 Willkommen an alle, welche jetzt in den Übersetzungskanal gewechselt haben. Ihr werdet hier den Talk zum Neues Protocol Framework hören am 34. KS Communication Congress. Übersetzt wird von Mir Myrion sowie Florian. Und wir danken wie immer für jegliches Feedback, von uns auf Twitter, bei C3lingo, oder unter dem Hashtag C3T Hubt. Und WireGuard, der VPN von Jason Dunfield, der ich hier nicht sehe. Die Talk wird mit den Neues Protocol Framework fokussiert. Was ist die Rationale behindert und wie zu benutzen? Bitte gebt ihm ein Handel der Applaus. Danke, dass ihr hier seid. Mein Name ist Trevor Perrin. Ich bin ein Consultant, wenn es um Kriptografie und sicheres Protokolldesign geht. Und ich werde euch heute von einem Projekt erzählen, an dem ich die letzten paar Jahre gearbeitet habe. Und da geht es eben um dieses Neues Protocol Framework. Sein Framework, das euch unterstützt, Secure Channel Protokolle zu entwerfen. Das sind Sachen wie TLS oder SSH oder IPsec, wo man zwei Teilnehmer hat, welche gleichzeitig online sind, wie ein kleinen Serververhältnis. Die wollen ein paar Nachrichten austauschen, um sich gegenseitig zu authentifizieren und einen geteilten Schlüssel zu finden, welche sie für weitere Kommunikation nutzen können. Die sichere Protokolle sind so die Kerne der Kriptografie. Und meistens, wenn Kriptografie verwendet wird, dann wird sie in diesem Kontext verwendet. Es gibt auch andere Anwendungsfälle, aber Neues fokussiert auf diese Secure Channels. Und darüber werde ich in diesem Talk sprechen. Da denken sicher viele Leute erst mal, warum? Da haben wir schon Sachen, da haben wir TLS, SSH, IPsec, und das gibt's schon lange. Da steckt ganz, ganz viel Arbeit drin und die Leute haben die Box rausgesucht und es gab Features. Warum wollen wir das von vorne nochmal machen und nochmal andere und neuere Protokolle entwerfen? Und das ist eine legitime Frage und ich denke, die will ich beantworten. Meine Gefühle dazu sind die Folgen. Was ein solches Protokoll macht, ist wirklich eine simple Sache. Ein paar Nachrichten hin und her schicken und den Channel aufsetzen. Und diese Protokolle sollten entsprechend auch simple sein. Sie sollten simple zum entwerfen sein, simple zu implementieren sein. Und die bestehenden sind sehr komplex und schwer zu erweitern und zu schwer zu erweitern für das, was sie eigentlich machen. Danke. Wir werden sie weiter erweitern müssen und neue Funktionen einbringen. Und darum ist es wichtig, und wir haben hier noch viel Platz, um uns zu verbessern hier. Und darum ist, hier halt wichtig, dass wir bessere Protokolle haben und bessere Wege haben, diese Protokolle zu erstellen. Und Noise ist da ein Effort, in diese Richtung das hinzukriegen. Es hat noch nicht alle seine Ziele erreicht, es hat einige erreicht, aber wir arbeiten noch daran, es zu erweitern. Und wenn ich euch in den nächsten 20 Minuten überzeugt habe, Neues in eurem Protokoll-Design-Herausforderung zu benutzen, dann ist es gut. Was ich im Wesentlichen herüberbringen möchte, ist, wie dieses Protokoll arbeitet, die Komplimenten, die darin eingehen, wie der Design-Space aussieht. Und es ist wichtig, dass man das verstehen kann und dass das nicht einfach als schwarze Magie wirkt. Es ist nur ein paar Zauberer verschenken. Um diese Protokolle zu verstehen, braucht man einen kleinen Hintergrund in Kryptografie, die Krypta, die verwendet wird. Und das Hauptkonstrukt, das hier verwendet wird, ist das, was als authentifizierter Schlüssel-Austausch bezeichnet wird. Das ist einfach eine Abfolge von Nachrichten, welche zwischen zweiten teilnehmenden Parteien hin und her geht, um sich gegenseitig zu authentifizieren und einen geteilten, geheimen Schlüssel zu etablieren. Und diese Schlüssel können unterschiedliche Eigenschaften haben. Sie können zukunftssicher sein. Sie können ein Weg authentifizieren. Gegenseitig authentifizieren. Es kann sich unterscheiden darin, wie sie Identitäten handhaben. Sie können sich zuerst gegenseitig kennen. Sie können das hin und her schicken. Sie vielleicht wollen Sie das Info zuerst schicken, wenn Sie eine gewisse Verschlüsselung bereit haben, damit die Identitätsinformation verschlüsselt ist. Und da gibt es verschiedene Eigenschaften. Es gibt verschiedene Arten von Kryptografie, die man einsetzen kann, die verschiedene Eigenschaften haben. Und da will ich ein bisschen expandieren. Die meisten Protokolle, die man kennt, die verwenden das auf etwa die gleiche Art. Entweder man verwendet Signaturen und dann Diffie-Helmen, das ist so typisch. In den letzten 10, 15 Jahren ist das Interesse daran gestiegen, Methoden zu verwenden, welche nur Diffie-Helmen basiert sind und keine Signaturen verwenden. Und das wurde schon praktisch umgesetzt im Endtor und in einigen verschiedenen anderen Designs wie Knuckle, Curve CP und so weiter. Es gibt also ein Interesse daran, das zu machen und Neues willm an dieser Idee arbeiten und damit weitermachen. Wir starten damit nur auf den Schlüffelaustausch Teil eines LKE anzugucken. Das wird ein nicht authentifizierter Diffie-Helmen-Austausch sein, die man denkt über Diffie-Heli nach. Wir haben hier Alice und Bob, die einen privaten Key und einen öffentlichen Schlüssel haben und sie tauschen ihre öffentlichen Schlüssel aus, kombinieren ihre öffentlichen und privaten Schlüssel und kriegen einen geheimen Schlüssel, der für beide dergleiche ist. Wenn man das in einen authentifizierten Schlüssel-Austausch verwandeln will, müssen wir Authentifizierung hinzufügen. In dem wir Signaturen in einem ganz konventionellen Weg hinzufügen. Einfach Bob schickt eine verschlüsselte Signatur an Alice und Alice schickt eine verschlüsselte Signatur zurück. Das ist im Wesentlichen wie TLS 1.3 funktioniert. Du kriegst erst ein Schlüssel und dann tauscht du verschlüsselte Signaturen aus. Da ist nichts falsch an diesem Schema. Man kann nur gucken, was daran guckt, wenn man nicht darauf guckt, wie die Nachrichtenreinfalle genau ist. Sobald Sie einen geteilten Schlüssel haben, wissen Sie, dass Sie den gleichen Schlüssel haben und die Signaturen mit einem Diffie-Helmen und das gleiche Konfidenz und das gleiche Guarantee haben, dass die andere Partie auf das ultimale und über den Teil sind wir jetzt nicht nachgekommen. Ich werde einsetzen, sobald wir wieder machen. Sie können zusätzliche Schlüssel-Keypairs mit Signaturen, auch Unsignaturen, entwickeln, welche nur für eine Verbindung verwendet werden und können sich gegenseitig verifizieren, weil sie einen Hash machen aus allen Diffie-Helmen Schlüsseln, die hier verwendet werden. Und die einzige andere Partei, die das kann, die alle diese Informationen haben, ist das bekannte Gegenüber. Darum haben Sie sich authentifizieren können, ohne Signaturen zu verwenden. Das ist ein gut verstandenes Protokoll, das gibt es ja so. So, und jetzt zur Geschichte von Neues. Vor ein paar Jahren war ich daran, verschiedene dieser Papers zu lesen, diese Diffie-Helmen-basierte Key-Schlüsselaustausch und ich habe mir angeschaut, wie geht das und die sind elegant, diese Protokollen sind elegant, aber sie fangen immer von ganz vorn an. Und die bauen eben alle immer das separat neu auf und überlegen sich, wie machen wir den Schlüsselableitung, wie machen wir die Bestätigung und so weiter und so fort. Sie schreiben ihren eigenen Diffie-Helmen-Beweis. Es ist viel Arbeit. Und da wird viel Arbeit jedes Mal repliziert, um diese Protokolle zu erstellen. Und meine Idee war da, dass man halt ein Framework entwickelt, mit dem man viele verschiedene Profis in dieser Art entwickeln könnte, in dem man einfach diese verschiedenen Bausteine auf unterschiedlich kombinieren könnte. Und da habe ich mit Mike Hamburg drüber gereden, der nennt das Strobe und das ist auf sogenannt schwammartige Kryptografie aufgesetzt. Und mit den Ideen von dort und meinen eigenen Ideen sind wir dazu gekommen, eine einfache Sprache zu entwickeln, welche Diffie-Helmen-Protokolle beschreiben kann und mit denen man diese verschiedenen Elemente beschreiben kann und diese auf unterschiedliche Arten kombinieren kann. Und das haben wir 2015 hingekriegt und das ist seither stabil. Und wir versuchen seither mehr und mehr um diesen Kern aufzubauen. Wir haben eine kleine Community mit einer Mailing-Liste, einer Website, mit Specs oder einer Test Suite. Es gibt Open Source Libraries mit verschiedenen bekannten Sprachen und es gibt jetzt einige auch Nutzer. WhatsApp benutzt Noise jetzt und WireGuard, ein Next Generation Vibian Tunnel Projekt von Jason Dunnenfeld, benutzt auch ein Noise-Based Secure Channel Protocol und wir hören auch aus dem IoT viel Interesse Leute, welche Anonymität gewähren wollen und Mixnet und auch aus dem Lightning-Netzwerk von Bitcoin und ich glaube, wir kriegen Interesse von Leuten, welche ein Custom Secure Channel Protocol für ihren Anwendungsfall haben wollen und sie wollen etwas Einfaches und Schnellen in ihrem Use Case. Das ist der Suite for Noise so weit. Das ist der Plan, was ich machen möchte. Ich möchte darüber reden, was die Komponenten eines so sicheren Channel-Protokolls sind, was das Protokoll ist und dann die Details ausführen. Secure Channel-Protokolle haben alle ungefähr die gleiche Struktur. Sie starten mit einer Handtrack-Phase, in der die beiden Parteien ein paar Pakete hin und her schicken, um einen gemeinsamen sicheren Schlüssel zu etablieren und dann die Transportphase in, das ist eine einfache Sache. Man benutzt dann einfach den geteilten Schlüssel um Daten hin und her zu schicken. Da braucht man nicht drüber zu sagen. Die Handtrack-Phase ist das, wo all die interessanten Sachen passieren. Die wichtigste Komponente ist die der authenticated Key is Change, LKI. Aber viele Protokolle haben auch eine Art Verhandlungsphase, bevor sie sich auf den Rest einigen. Da einigen sie sich über die Art und die Parameter des LKI und welche Parameter für die Krypto benutzt wird. Das passiert logisch vor allem anderen, weil es alles andere determiniert, aber aus Effizienzgründen sind die Phasen typischerweise verschränkt. Es gibt eine initiale Nachricht vom Klient, der spekulativ schon ein bestimmtes Protokoll benutzt, aber auch sagt, wenn der Server was anderes möchte, kann ich auch ein anderes Sachen, und der Server kann dann sagen, du benutzt bitte dieses LKI und dieses Verschlüsselungsmechanismus. Insofern passieren diese Phasen teilweise gleichzeitig. Das macht es etwas komplizierter. Aber wenn wir ein Secure Channel Protokoll bauen, würden wir versuchen, diese Elemente zu füllen. Welche LKIs wollen wir benutzen? Wie wollen wir die Kryptografie instanzieren und wie wollen wir die Verhandlungsstruktur aufbauen, um diese Dinge auszuwählen? Wir wollen kein einzelnes LKI-Protokoll bauen, sondern ein Framework um LKI-Protokolle zu bauen. Etwas Verwirrenderes. Und der Grund dafür ist eigentlich ganz einfach. Wir wollen ein einzelnes Protokoll bauen. Da muss man harte Trade-offs machen, ob man bestimmte Features einbauen will oder ob man es einfacher halten will. Je mehr Features es gibt, desto mehr Entscheidungen muss man treffen, desto mehr Features gibt es, desto komplexer wird die Implementation, desto mehr Angriffsfläche hast du bezahlt. Wenn in irgendein dieser Features ein Bug ist, hat der Angreifer Möglichkeit es angreifen. Wir haben ein möglichst Problem. Wir wollen Dinge haben, die viele Features haben, aber wir wollen es auch simpel halten. Deshalb brauchen wir kein einzelnes Protokoll, sondern ein Framework, bei dem wir alle diese Features und Möglichkeiten irgendwo an der Seite haben, wie eine Bibliothek. Und wenn wir ein konkretes Protokoll bauen, wählen wir ein Features aus und bauen eine einfache Kombination, dass genau das tut, was wir wollen und nicht irgendwas, was wir nicht brauchen. Das heißt, mit Neues zu arbeiten ist anders, als wenn man mit etwas wie TLS arbeitet. Bei den anderen Protokollen kann man nur machen, man nimmt bei einer TLS-Bibliothek, verweist die eine andere TLS-Bibliothek und sie reden miteinander und bestimmen dann die Parameter, die Schnittmenge der Verschlüsselungsalgeritmen. Das ist eine große Ingenieursleistung, aber es ist viel Komplexität. Bei Neues, auf der anderen Seite, muss man vorherdenken, was man benutzen will, welche Nutzungsfälle man hat, welche Kryptografie man benutzen muss, welche Sequenz von Berteilung man benutzen will. Man tut es zusammen und kriegt etwas, was in eigenen Newscales löst, aber nicht viel anderes hat. Das ist eine andere Art, mit Protokollen zu arbeiten und darüber zu denken. Aber ich denke, es ist die richtige Antwort für ein Haufenfälle. Das ist was wir wollen. Wir wollen ein Framework bauen, wo man verschiedene Sachen auswählen kann und die zusammensetzen kann und am Ende kommt man mit einem großen Breit an verschiedenen Protokollen raus. Da mussten wir die Struktur von einem Secure Channel Protocol nehmen und das sind die verschiedenen Elemente herunterbrechen, damit man die zusammensetzen kann. Wir machen das auf verschiedene Arten. Wir separieren alle die Stellen im Protokoll, wo zur Laufzeit Entscheidungen getroffen werden, damit wir daraus eine Geradlinie linearer Code machen können, weil wenn wir das so machen können und da gibt es nichts außer vielleicht Fehlern, wenn da die Authentifizierung Fälle schlägt, dann ist das sehr einfach zu testen, sehr einfach zum drüber nachdenken und Sachen rundherum designen. Daher wird Neues sehr stark sich auch Mühe geben, die Leute dazu zu zwingen diesen geradlinigen Code der Lineares zu bauen, weil damit ist man sicherer. Das soll viele Laufzeit Entscheidungen zur Designzeit verschieben, aber es werden immer Entscheidungen über, übrigens welche Cyphers werden eingesetzt, oder will man eine Zero Round Trip oder welche Fallback wird es geben und unser Ziel ist halt, dass es ein Punkt geben wird, wo man eine Entscheidung treffen wird zur Laufzeit und da wählt man ein Noise Protokoll aus und wenn man das mal ausgewählt hat, dann hat man diese Lineare abfolge von Code und das Noise Protokoll, das man da auswählt das wird eine A-Key und ein Transport fest sein und wir komprimieren damit all diese Entscheidungen an einen Punkt und um das machen können zoomen wir jetzt mal in ein Noise Protokoll rein und bauen das auch in einzelne Teile auf und da gibt es ein Handshacken-Muster und das ist die abstrakte Ansicht auf ein A-Key und da steht ja, mach eine Art von Diffy Helmen, verschlüsseln die Hashes irgendwie, es sagt einem nicht wie welche Krypto man verwenden soll, sondern es gibt eine Option und dann kann man das wieder zusammensetzen und das ganze Framework sieht dann etwa so aus wir haben diese zentrale Idee eines Noise Protokolls da stecken wir die Meisterarbeit rein da hat es eine Abstrakte von einem A-Key welches wir mit Krypto verbinden um ein Noise Protokoll zu machen und dann gibt es das Verhandlungs-Layer, wo es nur darum geht vom Initialen Protokoll auf ein Noise Protokoll zu wechseln und dann wird es noch das Kodierungs-Layer, wo es darum geht vielleicht wollen wir über TCP senden oder wir wollen über HTTP senden und das ist halt auch wiederum sehr abstrakt vielleicht müssen wir noch eine gewisse Kodierung hinzufügen damit wir es über ein gewisses Protokoll verschicken können und das wird der ganze Weg sein wie wir ein Secure Channel Protokoll bauen und jetzt der Hauptpunkt mit dem man interagieren wird das zentrale Stück ist das Noise Protokoll und die Hauptart wie man damit als Nutzer wird interagieren ist, dass man einfach den Namen kennen muss wir wollen sehr präzis sein im Namen definiert dann das ganze Protokoll und hier haben wir ein Noise Protokoll das ist eine konkrete implementierbare Möglichkeit das ist das NX-Pattern das verwendet die COVID-2519 mit AES-GCM Verschlüsselung und schaut 256 als Hash und klar wir können aussagen wir haben verschiedene Muster wir haben unterschiedliche Kurven die meisten der Noise Libraries können dieses Protokoll nehmen und daraus etwas bauen also diese Pattern-Idee, diese Namskonvention also wichtiger als die Namskonvention zu verstehen ist die einfache Sprache zu verstehen auf der es gebraucht wird wir haben eine einfache Sprache um eine Gruppe von abstrakten LKI-Nussern zu beschreiben wir haben Alice und Bob die haben vielleicht einen statischen Schlüssel und einen ephemeren Schlüssel und das einzige was wir ihnen erlauben als Teil eines Protokolls ist ihre Schlüssel hin und her zu schicken und Diffie-Helmen-Operationen durchzuführen wie das Pattern benutzt sie können z.B. die Static-Static-Operation oder die Static-Ephemeral von Alice und Bob und am Ende können sie EE benutzen für Vorwurzsequenzie wir erlauben ihnen diese verschiedene Schlüssel und verschiedene Arten zu benutzen lass uns ein paar Muster schnell zeigen dieses LKI ist einfache Publiki-Kryptografie das bezeichnet einfach Alice verschlüsselt eine Mitteilung an Bob wir haben 3 Punkte das zeigt wo Alice etwas weiß bevor das Protokoll startet sie weiß Bob Schlüssel bevor sie anfängt sie schickt einfach einen ephemeren Schlüssel und eine Entschuldigung ich bin gerade etwas raus wir können das komplik wir können davon ausgehen dass beide Gegenseite ihrer öffentlichen Schlüssel kann und dann können wir die Static-Static-Verschlüsselung verwenden und dann kann sich alles auch bei Bob identifizieren wir wollen Alice sie wollen dass Alice sich bei Bob identifiziert und ihren Publiki schickt und das kann auch in den Transport-Pilot gehen damit können wir wir können es auch so machen dass der Schlüssel eben von Alice in der Message verschickt wird damit muss Bob nicht mehr den Statischen Schlüssel von Alice kennen und wir können den Statischen Schlüssel mit dem Output der fm-erenschlüssel verschlüsseln und damit wird die Identität von Alice versteckt obwohl Bob sie auch kennt wir können auch interaktive Protokolle anschauen und einen unidentifiziertes Nehmen wo man einfach den fm-erenschlüssel austauscht man kann Server-Autoidentifizierung haben wo der Server seinen Statischen Publiki mitschickt und damit die Firmung gemacht wird man kann davon ausgehen dass der Client den Publiki des Servers zuerst kennt und den Server nicht nachts noch mitschicken und wir können wir können damit auch eine 0 Roundtrip Encryption machen weil wir können den fm-erenschlüssel aus der zweiten in die erste Nachricht verschieben und sie verschlüsselt direkt an Bob von der ersten Messagewerk und das kann man damit halt machen weil man den Schlüssel schon kennt und das ging ja nicht mit Signaturen weil das wäre ja nur der Signing-Key und nicht der Encryption-Key und wir können damit beliebig kompliziert Protokolle weggehen wir können nicht nur 0 Roundtrip Authentication wir können hier noch einen Zusatz in Diffie-Helmen machen wir können wenn wir das machen, dann sollten wir den Authentifizierung auch in der zweiten Nachricht dann nochmal mit ES authentifizieren damit die Authentifizierung von Alice gegenüber Bob mit einem frischen Schlüssel basiert und nicht mit einem potenziell schon kompriviatierten Schlüssel und das ist ziemlich nahe an dem was WireGuard macht und das hat dann noch einen pre-shared einen vorgeteilten symmetrischen Schlüssel als Zusatzfeature und das haben wir designed mit Jerry Donfeld der WireGuard entwickelt und das wird noch überall reingemischt mit der Idee, dass man im Kontext eines VPN einen ... dass wenn man entweder Diffie-Helmen oder den pre-shared Key geschützt und wenn jemand Diffie-Helmen breaken kann dann ist man immer noch durch den PSK geschützt das ist im Postquanten-Kontext potenziell relevant und wir werden da wahrscheinlich weitere Features einbauen beiseite um eben Postquanten sichere Algorithmen einzubauen wir können auch wieder hingehen und ... und wir können diese ganzen Ideen und sie auch auf konventionellere AKEs anwenden und das sieht also letztendlich etwas so an wir haben eine ganz simple Verhandlungs-Layer dann kommen wir zu diesem sehr linearen ... neues Protokoll, das man zusammensetzen kann in dem man ein ... ein abstraktes Pattern nimmt und das mit der Krypto-Euro-Wahl kombiniert und wir arbeiten an vielen Erweiterungen dafür und wir hören immer gerne von Leuten, die daran arbeiten wollen oder das für etwas verwenden wollen ihr könnt mehr Informationen auf unserer Website und der Mailing-Liste finden ich bin dafür da angesprochen zu werden es gibt ein WireGuard-Meetup ich werde wahrscheinlich auch dort sein vielleicht wollt ihr auch zu Jason und den WireGuard-Leuten sprechen und im konkreten Fall sehen, wie das Zeug eingesetzt wird danke fürs Zuhören und ... vielleicht haben wir jetzt noch kurz Zeit für Fragen microphone one test, test, okay in dem Kontext von mehrparteien-Systemen wenn ja eine Person, die mehrere ... Geräte hat oder mehrere Schlüssel gibt es da irgendwas, das man innerhalb von NEWS benutzen kann, um damit zu arbeiten also dass man Mitteilungen an beide Identitäten schicken kann oder etwas, wo eine zentrale Autorität gibt, die die Mitteilung verteilt da geht es darum, wie ein sicheres Nachrichtenprotokoll aussieht es gibt Gruppen, was macht man, wenn nicht alle in der Gruppe gleichzeitig online sind und so, das ist eine andere und komplexere Art von Protokollen und das ist nicht, was wir hier anschauen wir schauen hier einen gut verstanden und simplen Design Space an weil das glauben wir lösen zu können und haben darum diesen engen Ausblick gewählt und nicht diese deutlich komplexere Themen fällt enthält NEWS irgendwas wie Retroding oder Schlüssel-Fortschreibungsreigenschaften NEWS ist ziemlich einfach es wird ein Schlüssel verhandelt und in der Transportphase wie diese verwendet wir haben da Ideen gehabt um aus dem Output einen neuen Schlüssel zu generieren und das ist schon drin man kann auf diesen neuen Schlüssel dann wechseln sondern dann hat man innerhalb vom Protokoll forward secrecy aber wir wollen da nichts so ganz kompliziertes umsetzen was ist der einfache Salespitch um NEWS statt TLS zu benutzen also der einfachste ist wenn du wirklich willst, dass dein Protokoll etwas macht und du nicht so viel Code mitschleifen willst der ganz viel macht wenn du ein perfekter und dich angepasstes Protokoll willst dann nimm NEWS vielen Dank