34C3 Vorspannmusik
Herald-Engel: So. In unserem nächsten Vortrag lernt ihr etwas darüber, was
passiert, wenn das tolle TPM und das tolle Intel ME dann doch irgendwie nicht so toll
sind und was denn schief gehen kann, wenn man seine Keys auf so nem TPM
initialisieren will. Dazu helfen euch jetzt gleich die Herrn Professoren
Doktoren Weis und Forler weiter, bitte einen schönen Applaus!
Applaus
Ruediger Weis: So, also herzlichen Dank für die nette Einführung, auch herzlichen
Dank für die zahlreichen Zuhörenden. Es wird heute ein Vortrag, wo ich ein
bisschen auch mit dem Kollegen Forler von der Realität irgendwie auch ein bisschen
massiv gerempelt worden bin. Eigentlich war unsere Intention, wirklich zu
diskutieren, wie macht man Kryptographie robuster, und auch in einem feindlichen
Umfeld. Und ich hab gelernt ein neues Buzzwort: riesa...lienzte?
lacht Kryptographie war eigentlich wirklich als
Titel geplant, jedoch müssen wir, glaube ich, wegen der realen Entwicklung noch ein
paar Einordnungen gleich am Anfang machen. Also zunächst mal die übliche gute
Nachricht, die ich auch immer gern bring: wissenschaftlich starke Kryptographie ist
selbst gegen übermächtige Geheimdienstgegner wahrscheinlich das
Einzige, was überhaupt hält, aber es hält. Also wir haben einigermaßen die Sachen
verstanden, die Sachen, die freundlicherweise im Zusammenhang mit der
Snowden-Geschichte veröffentlicht wurden, zeigten auch, dass die Kryptographen in
der NSA mit Wasser kochen und da gab es eigentlich für die großen Mengen Geld, die
da rein geworfen wird, relativ wenig Überraschungen da. Also man kann sagen,
Krypto hält, oder um's mal ein bisschen lyrischer von Bruce Schneier zu machen:
"Vertraue auf die Mathematik, Verschlüsselung ist dein Freund". Also
insofern eigentlich eine ganz gute Situation, bis diese gute Situation auf
die reale Welt kommt. Wir Kryptographen können wirklich eine Art Magie entwickeln.
Wir können mit ein paar Bits, die man sicher speichert, wirklich sicher gegen
alle möglichen Angriffe bestehen. Das Problem ist, wenn diese paar wenigen Bits
aber nimmer sicher sind, dann können wir halt gar nichts mehr machen. Und man kann
es auch, wenn man es ein bisl modell- theoretisch macht, kann man auch sagen, na
ja, irgendwas muss die berechtigten Kommunikations-Partner von den Angreifern
unterscheiden. Und das Kleinste, was wir anbieten können, sind ein paar wenige
Bits, die sicher gespeichert werden müssen. Weniger können wir nicht machen.
Also wir sind mit unserem Latein nicht am Ende, aber eigentlich schon in der
Situation, wo wir gesagt haben, OK passt auf ein paar Bits auf, mehr können wir
nicht für euch tun. Und genau das ist das, was ja im Moment episch uns um die Ohren
fliegt. Also es gab hier auch schon einen sehr interessanten Vortrag, deswegen will
ich auch gar nicht so arg ins Detail zu gehen, aber der Titel ist einfach zu
schön: "How to hack a turned off computer", oder dass man beliebigen Code
ausführt auf dieser Management Engine. Und diese Management Engine ist relativ
spannende Geschichte, insbesondere für meine Forschungsarbeiten ganz interessant,
weil Dank der Intel Management Engine kann ich auf die lästerliche Frage, wo mich
eigentlich Leute schon seit Jahrzehnten immer.. naja, seit anderthalb Jahrzehnten,
damit aufziehen: "Wann ist endlich das Jahr von Minix auf dem Desktop?" kann ich
inzwischen freundlich grinsen und sag: "Seit 2012 ist es IN deinem Desktop und
niemand hat's gemerkt". Also diese Management Engine läuft in der Tat auf
diesem Minix 3, was ein akademisches Projekt, das irgendwie über Jahre halt
niemand benutzt hat, und jetzt bin ich auch im Minix Steering Committee und wir
waren ziemlich traurig, dass wenig Beteiligung letztes Jahr von der Konferenz
war, bis wir dann mitgekriegt haben, dass das Minix, was wir da entwickelt haben,
wirklich auf allen Intel-Plattformen läuft und damit ist wirklich diese lästerliche
Bemerkung, dass Minix auf mehr Rechnern läuft - auf Windows als auch Mac, weil
auch Mac haben die Intel-Hardware und diese selbe ME-Geschichte drin - ein ganz
witziges Detail, aber wie gesagt, bei den witzigen Detail ist natürlich das
Hauptproblem da, wenn das nicht ordentlich gemacht worden ist, dann können da
Sicherheitslücken kommen. Und offensichtlich ist es so, dass die zwar
dieses Minix genommen haben, das steht aber halt unter einer freien Lizenz und
nicht GPL, und dann natürlich die ihre Arbeiten und Modifikationen nicht
veröffentlicht haben und sich offensichtlich nicht gut genug damit
auskennen, das einigermaßen sicher zu machen. Minix ist ein militant auf
Sicherheit getrimmtes System, das hat so Inflexibilitäten, z.B. dass alle
Nachrichten für eine gewisse Prozessorarchitektur genau 24 Byte lang
sind. Also es gibt sehr wenig Angriffsvektoren, die wir da haben. Und es
ist ein Microkernel-System, ich weiß nicht genau, wie die genaue Code-Entwicklung
ist, aber in der Anfangszeit waren wir da bei unter 10.000 lines of code. Und das
ist auch wieder ein schöner Moment, wo man als Betriebssystem-Professor relativ
einfach die Welt erklären kann. Linux hat inzwischen 10 oder 20 Millionen Zeilen of
code. Windows irgendwie 100 Millionen - frag mich nicht. Und es ist auch so ein
Lemma, dass man sagt, alle 1000 Programm- Zeilen gibt es einen Fehler. Und jetzt
können wir ausrechnen: das ist bei Minix halt 20.000 Fehler, äh bei Linux 20.000
Fehler und bei Minix vielleicht eine Handvoll Fehler, und da könnte man
eigentlich vorbeigehen und das anschauen. Kleines weiteres Lemma: wie problematisch
sind Fehler? Da ist die Antwort, wenn man mit C programmiert, kann man davon
ausgehen, dass ein Fehler mit hoher Wahrscheinlichkeit echte Schmerzen
verursacht. Also die Gruppe der Sachen, der Fehler, die wirklich zu ignorieren
sind - oder ignoriert werden können - sind bei C deutlich geringer als bei anderen
Systemen. Insofern sage ich also, die reine Information, dass Minix ein sehr
kleines System ist, das so klein ist, dass man es so wunderbar in einer Vorlesung
erklären kann, ist wirklich direkt verbunden mit der Sicherheit. OK. Neben
diesem Problem, das wir halt Ärger auf der untersten Ebene haben, war ein anderes
Ding, das wir über Jahre lang auch verfolgt haben, diese TPM-Diskussion, und
hier gibt es wieder was sehr Bizarres. Hier, wer ein RSA verwendet, wer
vielleicht meine alten Diskussionen mit RSA und ECC kennt, weiß, dass ich RSA
eigentlich ganz, ganz, ganz gern hab und das hat auch eine Reihe von Gründen, nämlich es
gibt Sicherheitsbeweise, wirklich harte Sicherheitsbeweise, es ist verstandene
Mathematik. Und es ist eine relativ kurze Implementierung, wo man doch nicht allzu
viel falsch machen kann. Und da das, sage ich, immer noch ein bisschen ne Hacker-
Konferenz ist, seien mir auch ein paar Sachen hier erlaubt. Zunächst mal, was ist
RSA? Wir brauchen Primzahlen. Wenn wir 2048-bit-Schlüssel haben, brauchen wir
1024 Bit lange Primzahlen, die multipliziert man. Erste Frage an den
Mathematiker: gibt's die? Ja, es gibt Primzahlen in jeder Menge. Zweitens: wie
viel gibt es da? Und da hat man eine Formel, die sagt, also die Anzahl der
Primzahlen ist etwa x/ln(x), also ganz grob gesagt, alle 1024 Zahlen sind.. ist
eine Primzahl. Also man hat irgendwie 2^10^15 mögliche Primzahlen und wer ein
bisschen aufpasst, sollte bei Mathematikern immer zusammenzucken, wenn
die 'in ungefähr gleich' schreiben, dann bedeutet das, es ist gleich bis auf einen
linearen Faktor, lacht
der möglicherweise beliebig groß sein kann.
Lachen Und das ist für die Leute, die
implementieren, immer so mäßig befriedigend, deswegen haben wir noch mal
nachgeguckt und für x > 17 gilt, dass diese Abschätzung schon sehr genau ist.
Und im Vertrauen: für echte Systeme sollten wir Primzahlen, die deutlich
größer sind als 17 verwenden. Lachen
Ja, das war ein mathematischer Witz, vielen Dank für die Leute,
lacht Lachen
die es gefunden haben. Ok. Zurück zu der Hacker-Welt. Wie sieht es in der
praktischen Implementierung aus? Schauen wir uns mal gpg an, das bedeutet, wir
nehmen halt Zahlen, Zufallszahlen, und testen die dann. Zuerst mit einem Sieve-
Algorithmus, also ein einfaches Durchteilen der Primzahlen kleiner/gleich
2000.. 400.. äh, 4999. Das muss ich, glaube ich, hier nicht machen. Der zweite
Teil ist ein Fermat-Test, der ist auch so niedlich, dass ich den Wikipedia-Artikel
nehm: das ist alles. Und der dritte Test ist bisl ausführlicher, weil da mit Bit
hin und her geschubst wird, ein bisschen, aber das ist der komplette Code. Also wir
machen Zufallszahlen und machen diese Tests, diese wenigen Zeilen Tests durch.
Und haben dann eine hohe Wahrscheinlichkeit, dass es eine Primzahl
ist, multiplizieren das dann, sind fertig. Was kann da passieren? Nochmal zur
Erinnerung: wir sind in einem Zahlenraum, wo wir 2^1015 Primzahlen zur Verfügung
haben, also da kann doch nichts schiefgehen. Außer man kommt auf die tolle
Idee, wir machen mal ganz schnelle Primzahl- Erzeugung. Mein erster Eindruck
war: Nein, echt lieber nicht. Dann habe ich gesagt: "Guck Dir mal die Literatur
an", hab die zwei, drei Tage angeguckt und dann kam ich zur Entscheidung: Echt lieber
nicht. Und die Praxis haut dann hier auch nochmal voll auf die Computersicherheit
ein. Nämlich diese TPM-Systeme, die kriegen das hin, die haben einen
Schlüssel, also einer der zentralen Schlüssel ist der Storage Root Key. Der
wird genau ein Mal erzeugt. In der Lebenszeit des Gerätes. Also ein Mal. Also
hier ist kein.. keine Notwendigkeit, das mit einer unsicheren schnellen Erzeugung
zu machen, wird allerdings trotzdem gemacht. Weiterhin haben die ganzen TPM-
Chips eine Schlüssellänge kleiner/gleich 2048 Bit. So, und dann passierte der
preiswerte Totalschaden, das haben die Kollegen in einem Vortrag hier auch
gemacht, als Professor muss ich da noch mal darauf hinweisen, dass die Hauptidee -
haben die jungen Leute auch ordentlich hingeschrieben - von 1996 ist,
unmodifiziert. Dieser Coppersmith.. unmodifiziert, gar nix. Und was ich ihnen
sehr dankbar bin ist, dass sie da bei den ganzen Sachen mal die Preisliste
drangeschrieben haben. Also, ich weiß nicht, was das in Bitcoin ist, aber das
sind Cent-Bruchteile in Dollar. Und für das 2048, was die höchste Schlüssellänge
für TPM-Chips ist, ist es Kosten von 944 $. Wer sieht noch was Ultra-bizarres?
unverständliche Antwort Ja. Also, irgendjemand erklärt mir nach
dem dritten Bier, warum.. wie man das hinkriegt, dass 3072 eine 10^17 mal
größere Sicherheit gegen Angriffe haben als 4096. Also ihr merkt, das ist an
Bizzarität relativ wenig zu überbieten. Gut, wie gesagt, wenn wir gerade bei
Sachen sind, die in die Hose gehen können, habe ich auch noch überlegt: Was gibt es
noch aus dem letzten Jahrtausend? Nämlich den Bleichenbacher-Angriff. Und da hat
eine Gruppe um Hanno Böck und andere Autoren auch mit Robot das sehr schön
gezeigt, lacht
dass das heute auch noch genau geht, aber nur bei so kleinen Firmen wie F5, Citrix
und Cisco. Lachen
Und so bei 27 der 100 häufigsten Webservices, unter anderem Facebook und
lacht PayPal. Das ist, glaube ich, die Firma die
irgendwas mit Geld macht also das ist irgendwie
Lachen auch ein Punkt, wo ich irgendwie sag, das
ist eine Sache, wo man sich fragt, und da werd ich nicht näher auf.. gehen, aber
noch mal der Hinweis: Coppersmith [ist von] 96, Bleichenbacher [von] 98. Ihr
merkt, ich steh auf alte Angriffe, insofern seid versichert, im Laufe
lacht
des Vortrags kommen dann noch ältere Geschichten raus.
Lachen
Aber das ist natürlich relativ schmerzhaft. Also wir sollten hier auch
nochmal sagen, was wir empfehlen: es hilft alles nichts, wir brauchen Open Source im
Booting. Wir müssen weg von UEFI. Wir brauchen so was wie Core Boot, Libre Boot
oder U-Boot, und das muss jetzt relativ schnell passieren, weil ansonsten haben
wir.. sind wir Kryptographen auch wehrlos. Also wenn die uns die unterste Ebene
wegschießen und dann alle Bits, die wir irgendwie sichern wollen, einsammeln, dann
können wir auch keine Magie machen. Interessant ist, dass auch Google das im
Bereich des NERF - schöner Akronym für Non-Extensible Reduced Firmware - sehr
stark weiter betreibt. Kommen wir zu dem Thema, das ich eigentlich hauptsächlich
bespielen wollte, das ist Robuste Kryptographie. Und jetzt geb ich mal
wirklich ein paar Sachen, die sehr vom Ingenieurs-mäßigen Standpunkt interessant
sind, aber natürlich mathematisch fundiert sind. Erste Regel: XOR ist dein Freund.
Das bedeutet, wenn man z.B. aus mehreren Quellen den Zufall nimmt und das dann
XORt, dann tut man eigentlich das System stärken. Also es bedeutet auch, ich hab 15
schlechte random Quellen und eine gute, und wenn ich alles zusammen XOR, tue ich
weitgehend die Eigenschaft der guten Geschichte erben. Auch hier muss man ein
paar Sachen beachten, aber 'XOR ist dein Freund' ist, denk ich, sagen wir mal, als
erste Annäherung schon mal ein guter Punkt. Zweitens: man kann Sachen doppelt
hashen, das habe ich auch vor vielen Jahren gemacht, ist heute auch - [das]
erste Mal Blockchain - bei Bitcoin der Fall, dass die zweimal hashen, bevor sie
in den Mining-Prozess.. aber die machen das halt nicht richtig, denen fehlt ein
XOR und dadurch haben sie nicht die Sicherheit, die sie natürlich durch höhere
Sachen.. äh, durch doppelt hashen erreichen würden. Längere Schlüssellängen,
na, das ist generell eine gute Empfehlung, außer wenn ihr euch an die vorletzte Folie
erinnert, also es ist kein Allheilmittel. Aber für sehr viele Sachen ist eine lange
Schlüssellänge doch eine deutlich bessere Idee. Gut. Historische Sachen..
Cryptophone. Ein Telefon, das auch Snowden ganz gern benutzt, haben wir da für 2003
ein Design gemacht, und da können wir sehen: Schon damals, wo die Rechner etwas
langsamer waren - wir haben das für Handy gemacht - ging das irgendwie, dass wir
4096-bit.. äh, Diffie-Hellmann machen, wir haben es einmal gehasht und dann haben wir
vor der Schlüsselableitung es ein zweites Mal gehasht, aber mit einer modifizierten
Hash-Funktion. Also hier ist es ein bisl verkürzt dargestellt: Wir nehmen die SHA-2-
Funktion von damals, aber tun die mit dem anderen Wert parametrisieren, das hat z.B.
die Eigenschaft, ihr könnt überlegen, wenn man Kollisionsprobleme hat und zweimal
hintereinander hasht und schon nach einem Hash eine Kollision da ist, dann hilft das
nicht allzu sehr weiter. Aber durch das Umparametrisieren, wie gesagt, es ist
manchmal nur ein Bit, also im Prinzip wär Bitcoin sehr viel sicherer, wenn sie nach
dem.. - also, sicherer gegen einige Angriffs-Sachen - wenn sie nach dem ersten
Hashing ein Bit umrempeln würden. Also das ist irgendwie manchmal ein bisschen
gruselig, wenn man sich überlegt, das manchmal ein Bit an der richtigen Stelle
gesetzt oder nicht gesetzt wirklich drastische Auswirkungen hat. Später dazu
noch ein paar weitere Bemerkungen. Und hier aus der beliebten Serie 'XOR ist dein
Freund': wir haben damals AES-256 und Twofish einfach mit XOR verknüpft, das ist
eine Verknüpfung, die die schöne Eigenschaft hat, das dann Angreifer beide
Funktionen brechen müssen, etwas verkürzt dargestellt, aber durchaus zutreffend.
Also wie gesagt, es sind relativ einfache Sachen, bei Hash-Funktionen ein bisl
darauf achten: XOR ist ganz spannend. Kommen wir noch mal zur Hash-Funktion, da
möchte ich hier heute mal ein bisschen Werbung für SHA-512 machen. Ich bin der
Meinung, man sollte lieber SHA-512 nutzen als SHA-256. Warum? Naja, Abschneiden ist
OK, man kann die, wenn man nur 256 Bit ist, kann man die anderen Bits schlicht
und einfach verwerfen. Wer es nochmal im Standard da hinten.. kann es sich
angucken, SHA-356 ist im Prinzip, mit einer leichten Modifikation, SHA-512 mit
abgeschnittenen Bits. Zweiter Punkt: Kryptographisch hochwertige Bits, genauer
gesagt schön randomisierte Bits, kann man immer brauchen. Also wenn man 512-bit
Ausgabe hat, dann hat man noch zusätzlich ein paar random Bits rumliegen, wie schon
gesagt, man kann dann noch überlegen 'XOR ist dein Freund' und das in andere Sachen
nochmal anzubringen. Weiterhin ist SHA-512 sehr schnell, auf 64-bit Plattformen, ist
eigentlich fast genauso schnell auf älteren Plattformen wie SHA-256 und wie
gesagt, rein aus dem kryptographischen Bauchgefühl: Man hat in SHA-512 mehr
Runden und man hat 64-bit-Operation, also von allem kryptographischen Bauchgefühl
wird da deutlich mehr durcheinander gewirbelt und die Sicherheit auch in einer
gewissen Weise erhöht. Gut, das machen wir kurz. Längere Kurven, nochmal der Hinweis:
Ich bin der Meinung, unter anderem die Gruppe um D.J. Bernstein hat da schöne
Arbeit gemacht bei der kleinen Kurve, er hat auch irgendwie bei der 256-bit Kurve
interessante Ergebnisse gehabt. Er hat auch längere Kurven bereitet, aber das
nicht mit der.. mit dem In.. mit dem Nachdruck bearbeitet, die man vielleicht
dafür braucht. Und außerdem bin ich halt wirklich der Meinung, wenn man schon auf
die elliptischen Kurven kommt, ist ja SHA-256, also ist 256 Bit wirklich sehr
nahe an der Grenze, wo man irgendwie sagt, das könnte schnell problematisch werden.
Insbesondere, weil auch djb verwiesen hat auf die Probleme, die RSA bei
Quantencomputern hat, muss ich sagen, elliptische Kurven, wegen der kleineren
Schlüssellänge würd ich vom Bauchgefühl sagen, da knallt's deutlich früher als bei
den RSA-Operationen. Gut, alles klar, jetzt in einem zweitem Teil tut mein
geschätzter Kollege Christian Forler mal ein paar konstruktive Tips geben, wie man
wirklich bestehende Systeme besser nutzen können, und es ist eigentlich auch
überraschend: Wir haben uns in dem Vorfeld halt da noch mal reingeguckt und sind an
einigen Stellen gekommen, dass z.B. einige neue Ideen, TLS, z.B. 1.3, eigentlich auf
den ersten Blick gut aussehen, außer wenn man mal ein paar andere Angriffsmodelle
zugrunde legt. Insofern sind die Arbeiten, die Christian jetzt vorstellt, glaube ich
auch, vom hohen Maße praxisrelevant. Christian Forler: Hallo. Jetzt wird es
gleich ein bisschen technisch werden, da müsst ihr jetzt halt durch.
lacht OK. Und zwar geht es jetzt um den
richtigen Einsatz von AES. Ne? Also das Problem ist, dass jetzt die ganzen
Hersteller von Softwareprodukte irgendwie Sicherheit bewerben, indem sie erzählen:
"Wir nutzen AES". Ja. Das ist zwar jetzt erst mal nicht so die schlechteste Idee,
AES zu nutzen, aber in der Regel findet man halt nicht raus, wie sie das
einsetzen, ja, und da kann man auch viel falsch machen. Und das schauen wir uns
dann gleich mal an, das heißt, wenn jemand irgendwie behauptet, er macht irgendwie
AES, online erstmal nachfragen, wie das eingesetzt wird und wenn man das nicht
rausfindet, ist das meistens ein Indiz dafür, dass da ein Fehler gemacht wird.
Und dann schauen wir uns mal an hier: Also AES ist keine Wunderwaffe, das ist einfach
nur ein Blockchiffre, das heißt, ich kann mit AES einen Klartextblock verschlüsseln,
bzw. einen Chiffretextblock entschlüsseln, und die Blockgröße ist 128 Bit, das heißt
16 Byte. Das hilft jetzt in der Regel nicht so wirklich viel, weil in der Regel
habe ich halt Nachrichten, die ein wenig größer sind als 16 Byte, ja, wenn man es
so irgendwie Dateien uns anschaut, auch Netzwerkpakete. Und da ist jetzt die
Frage: Wie kann ich jetzt einen größeren Klartext verschlüsseln? Und dann ist die
Antwort irgendwie klar: Ich zerhacke den in Blöcke und bearbeite die Blöcke
nacheinander irgendwie mit AES ab. Ja, das ist so die elementare Strategie. Und dann
schauen wir uns mal an: da in der i-Folge jetzt, da geht das auf jeden Fall schief,
und ihr könnt euch vorstellen, man tut jeden Block einmal durch AES jagen,
Nachteil: gleiche Klartextblöcke, ja, wenn die Klartextblöcke gleich sind und AES
eine Funktion, dann kommt auch das Gleiche raus. Das heißt, gleiche Klartextblöcke
ergibt gleiche Chiffretextblöcke, ja, alles schon mal gehört, das heißt, da
bleibt Struktur erhalten und wenn da Struktur erhalten bleibt bei einer
Verschlüsselung, dann ist das irgendwie extrem schlecht. Also das, was wir grad
nicht haben. Ja, das ist halt die Idee, warum wir Kryptographie nutzen, damit ja
von der Struktur nichts mehr übrig bleibt. Ja, und falls doch, gibt es da dieses
Wikipedia-Beispiel, das wir irgendwie alle kennen. Das heißt, das ist irgendwie AES-
verschlüsselt, das ist 'military-grade security', da, so Werbung.. so, ja.
räuspert sich Also da gibts ja Leute, die bewerben halt
ihre Software mit 'military-grade security' und machen dann sowas. Das ist
irgendwie schlecht. Nächster Schritt, was man jetzt machen kann: Wir wissen alle, ja
man macht Schlüsselstrom. Man nehme ein AES, generiere einen Schlüsselstrom. Die
Idee ist schon mal gar nicht mal so schlecht, weil wir haben ja irgendwie
gelernt so, One-Time-Pad funktioniert. Und das wollen wir irgendwie da ein bisschen
emulieren. Dann gibt's jetzt die einfache Variante, dann.. genau, verschlüssel ich
jetzt was, indem ich einen Counter, irgendwie, also ich nehm einen Counter,
verschlüssel den und tu das Ergebnis, der Schlüsselstrom, der raus kommt, XORen mit
meinem Klartext. Und das Problem ist hier bei dieser Variante, hier gibt's keinen
Zustand, das ist zustandslos, das heißt, das ist deterministisch. Das heißt, jedes
Mal, wenn ich hier das anwerfe, die Verschlüsselungsverfahren, kommt der
gleiche Schlüsselstrom raus. Und wie wir auch wissen, One-Time-Pads mehrmals
anwenden ist auch eine schlechte Idee, dann kommt .. das heißt, ich muss jedes
Mal bei AES den Schlüssel wechseln, ja wenn ich da jetzt eine neue Nachricht
verschlüsseln möchte. Und das ist irgendwie auch.. irgendwie nicht so
richtig praktikabel, wenn ich jetzt vergesse, den Schlüssel zu wechseln, bei
dem einfachen Verfahren, dann fällt es erstmal gar nicht so auf, weil ich habe
hier jetzt einmal Tux verschlüsselt und einmal Beastie, und hier sieht man
erstmal: die Struktur ist weg, weißes Rauschen, das ist schon mal irgendwie ganz
angenehm. Problem ist jetzt nur, ich habe zweimal den gleichen Schüsselstrom, das
heißt, wenn ich den Chiffretext XORe, dann kürzt sich der weg. Und dann, genau, kommt
irgendwie das raus. Und da kann man sich vorstellen, das das jetzt nicht so der
Riesenaufwand ist, aus diesem XOR dann die zwei Klartexte zu extrahieren, das kriegt
man auch hier noch als Geheimdienst hin, selbst als schlecht ausgestatteter
Geheimdienst, das kriegt man auch noch als Student noch hin. Das ist eventuell mal
eine Übungsaufgabe, so im.. für Bachelor- studenten, das ist jetzt net so schwer.
lacht
Deswegen also, wie funktioniert's richtig? Das heißt, ich brauch einen Zustand, ja?
Das heißt, wenn ich einen Schlüssel nur habe und möchte damit mehrere Nachrichten
verschlüsseln, brauche ich einen Zustand, das nennen wir hier Nonce. Und das heißt,
und beim Counter-Mode setzt sich halt mein Counter im Anfangswert nicht auf 1,
sondern ich setze ihn auf seinen Zustand. Und jetzt ist die Idee: Jedes Mal, wenn ich
eine neue Nachricht verschlüssele, würfel ich mir einen neuen Zustand aus, neue
Nonce. Und das heißt, wenn ich da jetzt eine neue Nonce anfange, bekomme ich immer
wieder einen neuen Schlüsselstrom und das ist halt vorteilhaft, das heißt, genau.
Das heißt, wenn ich halt.. neuer Schlüsselstrom heißt halt, das können wir
wieder nutzen und so falls sich jetzt.. das Ganze ist sicher so, falls sich kein
Nonce-Schlüssel-Paar wiederholt. So weit, so gut. Das heißt, die Anforderung halt
hier ist jetzt.. ist, der Nonce darf sich nicht wiederholen. Ja und das ist halt so
ein bisl kritisch, es gibt uns, genau, es gibt da noch so mehrere
Verschlüsselungsverfahren, die sind alle Nonce-basiert, und das erste Problem, wie
ich gesagt habe, man darf den Nonce irgendwie.. muss aufpassen, dass der sich
nicht wiederholt. Und das zweite Problem ist, man schützt nicht die Integrität der
Nachricht damit. Ja das heißt, wenn ich da was mit verschlüssele, z.B. so eine Bank-
Transaktion, ist es sozusagen geschickt, dass die hier im Internet niemand lesen
kann, aber wenn ich das Format irgendwie kenne, der Bank-Transaktion, kann ich es
so manipulieren, dass der Betrag sich ändert, oder die Empfängeradresse und das
auch kontrolliert. Und eventuell möchte man das nicht. Ja. Genau. Und deswegen
gibt es die Authentisierte Verschlüsselung. Das heißt, als Kryptograh
ist man auch auf die Idee gekommen, seit längerem schon, das man nicht nur die
Vertraulichkeit irgendwie schützen möchte einer Nachricht, sondern auch die
Integrität. Und das in einem Rutsch und das auch irgendwie mit AES. Genau. Das ist
jetzt das große Ziel. Und wie funktioniert das, so ein Verfahren? Ich hab jetzt, wie
gesagt, wieder mein Nonce und mein N und meinen Klartext P, den kipp ich da rein,
und dann fällt es nicht nur unter Chiffretext raus, sondern es fällt auch
noch so eine kryptographische Prüfsumme raus. Ja? Und das heißt, wenn ich jetzt
die Inputs ändere, ändern sich auch alle Outputs bei der Verschlüsselung. Das
heißt, ich komm jedesmal, wenn ich dann irgendwie mindestens ein Bit ändere oder
mehr im Input, ändert sich halt auch die Prüfsumme und der Chiffretext. Das ist
schon mal ganz nett. Und wenn ich entschlüssle, ganz einfach, dann kipp ich
wieder so ein valides Nonce-Chiffretext- Tag-Paar rein und es kommt mein Klartext
raus, Juhu! Und das ist, der Clou ist jetzt, der Hammer: Wenn ich jetzt
irgendwie am.. wenn jetzt jemand manipuliert, das heißt wenn ich jetzt
Nonce, Chiffretext oder Tag ändere, dann gibts ne Fehlermeldung. Ja? Dann heißt es,
der Klartext ist nicht valide, das heißt die Eingabe war invalide und es gibt eine
Fehlermeldung. Das ist irgendwie ganz nett, sowas will ich eigentlich haben. Ja
da gibt es irgendwie so zwei ganz berühmte Verfahren, das eine ist der Galois/Counter
Mode, der wird eigentlich überall.. der ist in der Industrie weit verbreitet, den
gibt es z.B. so bei Sachen wie IPSec oder auch bei TLS und so weiter und das ist,
das Problem.. also, das Gute ist, das Ding ist superschnell, der Galois/Counter Mode,
Nachteil ist, er ist ein bissel fragil. Das schauen wir uns gleich mal an und das
andere Verfahren, das ich dann noch empfehlen kann, ist OCB, Offset Codebook
von.. genau, Rogaway, hat er mit gebaut und das.. genau. Also wenn man die Wahl
hat, sollte man OCB einsetzen. Problem ist halt auch wieder hier: Bei all den
Verfahren, wenn sich eine Nonce wiederholt dann ist es.. dann bricht so alles
zusammen. Ja und ich hab mir das nochmal angeschaut, wie schlimm die Situation ist,
wenn sich eine Nonce wiederholt, 2011. Und d.h. das Schlimme ist, das ist wirklich
total kaputt. D.h ich kann da immer von O(1) Angriff finden, d.h. ich kann das
Ding in Echtzeit alles kaputt machen. 'Vertraulichkeit und Integrität'. Und das
möchte man nicht so wirklich haben. Also das ist irgendwie.. d.h. wenn sich eine
Nonce wiederholt, ist das so eine mittlere Katastrophe. Ja und das ist irgendwie vom
Design her nicht so gut, d.h. da muss man irgendwann mal irgendwie die.. also die
Anforderungen für einen Kryptograph, der ist Mathematiker, man hat so einen
Zustand, der sich wiederholt, das klingt jetzt erstmal irgendwie so nicht so
schlimm, aber in der Praxis ist das echt ein Problem. Schauen wir uns auch gleich
an, erstmal noch mal hier bisl GCM- Bashing. GCM, na das liegt.. das ist
extrem fragil. Also, [auf] das muss mans aufpassen, wenn man es einsetzt. Wenn ihr
GCM einsetzt, Galois/Counter Mode, dann bitte nur mit 96-bit Nonces. Ansonsten
gibt's Probleme, da können Konstanz- Kollisionen auftreten, weil dann das
gehasht wird. Das möchte man eigentlich nicht tun. Ja und die Hashfunktion hat da
so ein bisschen Schwächen. Dann, kurz nachdem GCM raus kam, hat sich mal Niels
Ferguson - also sprich: Microsoft - das Ding angeschaut und hat gemeint so, oh,
das Problem ist, wenn ich jetzt den.. die Nachricht, also die Prüfsumme, kürze, dann
wird das Ganze extrem unsicher. Das heißt, es nimmt überproportional stark ab, die
Sicherheit. D.h. Kürzen ist eine schlechte Idee. Und das ist auch so manche komische
Eigenschaft, die man eigentlich nicht haben möchte. Ja. Das andere, was man
jetzt rausgefunden hat: ja, bei Nonce Wiederholung, da fliegt da so ein
Schlüssel raus. Ja, d.h. da irgendwie kriegt man noch einen Schüssel frei Haus
und das Gute ist, GCM hat zwei Schlüssel. Einen Schlüssel zum Verschlüsseln, einen
Schlüssel für die Integrität, für die Prüfsumme. Und es fällt da nur der
Schlüssel raus für die Prüfsumme. Das ist aber irgendwie trotzdem irgendwie schlimm.
Das möchte man eigentlich nicht. Dass man mal einen Fehler macht, der Schlüssel raus
fällt. Das ist halt auch bisl.. so bisl fragil. Und es gibt noch auch ein paar
Handvoll schwache Schlüssel, weil dieses Galois/Counter Mode, ja, das 'Galois'
steht halt für Galois field multiplication, d.h. da findet eine
Multiplikation statt, und da kann man sich denken, ja, Multiplikation mit 0 ist
vielleicht nicht die beste Idee. Ja, wenn man so einen 0-Schlüssel hat, weil
irgendeine Nachricht mal 0, ne, ist halt immer 0, unabhängig von der Nachricht und
eine Prüfsumme, die unabhängig von der Nachricht ist, ist irgendwie nutzlos. Und
da gibts noch weitere Schlüssel, die auch irgendwie noch Schwächen haben. Genau.
Also, als das rauskam, wie gesagt, hat sich das mal Niels Ferguson angeschaut,
der ist bei Microsoft tätig, und hat dann so ein Papier geschrieben, da stand drin,
ja, ich kann das nicht zufällig empfehlen, besser nicht. Wenn ihr keine andere Wahl
habt , dann nutzt GCM, aber bitte, bitte nicht.. niemals die Prüfsumme kürzen. Da..
genau, dann.. das Zweite, was ich hier habe, als Code-Schnipsel ist RFC 4103..
06, da steht beschrieben, wie man denn jetzt GCM bei IPSec benutzt und da steht
drin, ja wenn ihr das implementiert, natürlich müsst ihr dann die volle
Prüfsumme unterstützen - ich glaub, das kann man auch gar nicht anders
implementieren, dafür ist es nicht möglich, dass man es eben anders
implementiert - und aber, was optional noch erlaubt ist, ihr dürft die Prüfsumme
kürzen, auf.. genau. Von 16 Byte auf 12 oder 8 Byte, und das ist natürlich eine
schlechte Idee. Ja, weil dann die Sicherheits.. also mehr, die Sicherheit,
wenn man nur 8 Byte hat, ist halt wesentlich geringer, als man da vermutet.
D.h. erstmal: tuwat! Ne? Wer Admin ist, erst mal nachschauen: IPSec - nutzt ihr
GCM mit kurzen Prüfsummen? Und dann erstmal das Feature deaktivieren. Das
hilft. Dann, genau. Jetzt gehts wieder zurück zum Nonce-Reuse, nachdem ich ein
paar Nachteile von GCM aufgezählt habe. Weil der Vorteil ist halt, es ist halt
verdammt schnell, aber der Preis ist Fragilität. Und bei Nonce, genau,
Wiederholung: Es ist halt praxisrelevant, da gab es ja irgendwie Diskussionen am
Anfang, als der da herauskam und irgendwie, da nenn ich mal drei Beispiele.
Ja, ich glaube schon, weil erster Grund ist halt: Programmierer machen Fehler und
auch Leute, die sowas designen, machen auch mal ab und zu Fehler. Und genau, da
gibt es so drei lustige Beispiele. Eins, so irgendwie so eine kleine Klitsche aus
Redmond, mit so Nischen-Software - Word, Excel - hat es irgendwie nicht so richtig
hinbekommen beim ersten Anlauf, dann das andere, was ich hier noch hab ist so
WinZip, auch so irgendwie Nischen- Software, die keiner nutzt. Und das dritte
haben wir jetzt dieses Jahr ganz brandneu, ist KRACK hier, WPA2 Wi-Fi, ja, auch so
ein Nischen-Produkt. Und das ist so, sieht man, das geht halt immer wieder.. also
selbst die großen Firmen eben.. und Standard und Komitees kriegen das nicht so
richtig hin. D.h. da gibts halt irgendwie ein Problem. Und ich denke, auch in
Zukunft wirds immer wieder Probleme geben, ja? Und das andere ist, wenn man sich mal
schaut so, die ganzen App Stores, was es da an Software gibt, den nutzen halt viele
Leute, also, was heißt.. es gibt halt irgendwie.. ich denke, jede zehnte App,
die irgendwie so AES einsetzt, wird so irgendwie diesen.. als Nonce hier den
Zufallszahlengenerator von xkcd verwenden, d.h. das ist alles schlimm, wenn man sich
mal das anschaut. räuspert sich
Ja also, das ist halt strukturelles Problem. Das andere sind da so
Bedienfehler, ja, Admins sind auch teilweise mal schuld, nicht nur die
Programmierer, d.h. was man da oft macht, ist jetzt hier restore ein Backup, und der
Nonce ist halt dann persistent geschrieben worden irgendwo auf Platte, den letzten
Wert so, dann wird das wieder geladen, oder wenn man klont, bei virtuellen Maschinen,
da kann auch mal was schief gehen bei Nonces, dass mal eine Nonce öfters
aufkommt. Oder das andere ist, wenn ihr jetzt zu wenig Entropie habt, dann zieht
man öfter mal die gleiche Nonce. Ja, das ist irgendwie alles unlustig. Das
Problem.. also, das Gute der Nachricht ist, das Problem wurde eigentlich 2006
schon gelöst, ja, von den Kryptographen. Da gab es jetzt ein Paper, das rauskam,
das hat vorgestellt ein Verfahren, das ist Misuse Resistant AE Schemes, heißen die,
und die bieten auch Sicherheit, wenn man das mit einem Nonce vergeigt. Ja, genau.
Und das Coole ist, die haben beliebig.. unterstützen beliebig lange Nonces,
i.d.R., die Verfahren. D.h. wenn man da Netzwerk-Pakete verschlüsselt, dann kann
man den Header als Nonce nehmen und den Payload als Klartext. Wunderprima. Sollt
man mal machen. Und zwar überall. Das Verfahren, wie gesagt, wurde jetzt
vorgestellt, da gibt's auch ein RFC für, d.h. es gibt jetzt keinen Grund, das
irgendwie nicht zu implementieren als Entwickler oder Netzwerk-Mensch. Und
genau, da gab es noch eine Schwäche, also SIV ist eigentlich idiotensicher, d.h. man
kann auch ein Nonce wiederholen, aber es ist halt nicht irgendwie
vollidiotensicher, deswegen habe ich da noch 2016 an einem Verfahren gearbeitet,
das das Ganze noch verstärkt. Warum ist SIV nicht idiotensicher? Ja, man muß ja
noch die kryptographische Prüfsumme verifizieren. Und ja, und wenn man das
nicht hinkriegt, ja, wir erinnern uns, hier Apple z.B. kriegt das auch nicht
immer hin, mit goto fail Bug, d.h. wenn das Apple passiert, kann es eventuell auch
anderen Firmen passieren, haben wir uns da gedacht. Und deswegen haben wir das
irgendwie so gebaut, dass selbst wenn man jetzt irgendwie die Verifikation
versemmelt, dass dann irgendwie bei der.. genau, dass dann immer noch.. irgendwie
das irgendwie bemerkbar wird, indem man als.. das so baut, das der Klartext, wenn
man den Chiffretext manipuliert, immer weißes Rauschen ergibt. D.h. man hat immer
weißes Rauschen. Und dann war die Idee so, eventuell fällt es bei.. wenn man den
Input validiert, dann auf, bei der Input- Validierung, dass da irgendwie nur weißes
Rauschen ist, und dass es keine valide Eingabe ist, oder die Software wirft
eine Exception oder stürzt ab oder so. Ja genau. Wie das genau machen, überspringe
ich mal, aus Gründen der Zeit. Genau und das Ding ist, hier tutwat! Benutzt diese
MRAE-Schemes. Die haben einen gravierenden Nachteil: man muss zweimal komplett über
den Klartext gehen. D.h. das dauert halt ein bisschen länger als andere Verfahren.
D.h. die sind nicht so super effizient. Und jetzt kann es natürlich sein, dass man
jetzt irgendwie Echtzeitanforderungen hat, die das nicht erlauben. Ja dann, was soll
ich tun, wenn das irgendwie technisch nicht möglich, realisierbar ist? Ja, nicht
in Panik verfallen, auch da hab ich irgendwie.. gibt es eine Lösung, da war
ich dabei, die mit zu entwickeln. Und die Antwort hier ist Robuste AE-Schemes, die
hießen vorher mal 'Nonce Misuse Resistant AE-Schemes', und wir haben das jetzt
umbenannt, nur noch Robust, weil es da irgendwie ein bisl Konflikt gab,
Potenzial, in der Crypto-Szene. Und was wir da gebaut haben, ja, 2012, war ein
Verfahren, McOE, da kann man jetzt irgendwie, wenn man da jetzt irgendwie
Probleme hat mit den Nonces, eine Nonce wiederholt, dann ist hier immer noch, die
Integrität immer noch gewährleist, Integritätsschutz, und die Vertraulichkeit
bleibt auch noch irgendwie.. je nachdem, wie schlimm man da Fehler macht, noch
teilweise erhalten, oder eventuell auch ganz. Also was man auf jeden Fall erkennen
kann, wenn man Nonce wiederholt, dass zwei Klartexte den gleichen Prefix haben. Das
konnten wir eben nicht wegkriegen, wenn wir nur einmal über den Klartext gehen.
Genau. Das.. die Idee hat sich dann irgendwie fortgepflanzt, d.h. da gab es
dann auch diesen CAESAR Competition, und das R steht auch für Robust. Das.. genau.
Und die CAESAR Competition sucht halt einen Nachfolger für GCM. Ja, das ist eine
Crypto Competition, auch von Dan Bernstein, der hat die da angetriggert,
ist der Schirmherr. Und da haben jetzt einen Nachfolger von McOE, auch, da hab
ich auch mit.. POET - da war ich auch wieder mit dabei gewesen - ins Rennen
geschickt. Wir haben es in die zweite Runde gepackt, leider nicht in die dritte,
weil wir waren wahrscheinlich ein bisl zu super-schwergewichtig und auch nicht so
performant auf Hardware. Was noch im Rennen ist, was ich empfehlen kann: COLM,
das ist ein Zusammenschluss aus AES-COPA und ELmD. Das waren praktisch zwei
Zweirunden-Verfahren, die sind jetzt.. haben sich zusammengeschlossen, ist jetzt
noch Drittrunden-Kandidat, was es jetzt noch gibt, was ich noch empfehlen kann,
beim CAESAR Competition, was man näher anschauen kann, ist AEZ, AEZ ist ein MRAE-
Scheme, mit von Phil. Und genau, zumindest hat der Phil mitgemacht, das sind die zwei
Kandidaten, die ich da noch empfehlen kann. Genau und jetzt schauen wir uns mal
an, also alle die Verfahren, ja, sind irgendwie beweisbar sicher. Und genau. Und
das heißt, da gibt es immer so einen Sicherheitsbeweis. Und da gibt's immer..
irgendwie da unten.. das schauen wir uns mal man hier: also das ist jetzt so eine
Sicherheitsschranke, und wenn man einfach sieht, hier hat man da.. ist das eine
Birthday Security-Bound. Also die haben alle so komische Bounds. Ja und da gibt es
jetzt so drei Parameter: q, l und t. q ist die Anzahl Nachrichten, die man damit
verschlüsselt, l sind die Anzahl Blöcke, die man insgesamt verschlüsselt und t ist
die Zeit. Und was hier steht ist, ihr könnt ungefähr so 100 Terabyte unter einem
Schlüssel verschlüsseln, ein paar hundert Terabyte, und dann sollt ihr den Schlüssel
wechseln. Genau. Und natürlich ist es nur sicher, wenn auch AES sicher ist, wer
hätte es gedacht, weil das Ding nutzt ja irgendwie AES. Und ja genau. Also und die
Idee ist auch irgendwie bei POET, das ist immer so'n.. also das ist halt super
strong, ja so das Superheavyweight, weil wir machen hier die erste lane, obere
lane, ist einfach nur eine Prüfsumme über den Klartext, die untere lane ist eine
Prüfsumme über den Chiffretext und in der Mitte drin ist die Verschlüsselung. Genau,
d.h. die kryptographische Prüfsumme ist ja ziemlich, irgendwie.. wenn Klartext und
Chiffretext.. und das zweite coole Ding, ja, wenn ich hier jetzt z.B. was
manipuliere bei C 2, dann kommt ab M 2 weißes Rauschen raus. D.h. da kann ich
auch wieder.. da ist auch wieder die Idee, wenn man jetzt die Verifikation jetzt
nicht richtig macht, dass man da viel weißes Rauschen hat und dass damit
irgendwie vielleicht auffallen könnte bei der Eingabe-Validierung. D.h. da ist jetzt
auch noch irgendwie so ein bisschen Schutz drin, das, wenn man die Verifikation nicht
richtig hinbekommt. Also if-Abfrage ist nicht immer ganz einfach zu
implementieren. Genau, jetzt bin ich auch schon so gut wie durch. Das ist gleich
geschafft, dann darf wieder Ruedi. lacht
Und genau, also was ich mit.. das, was ihr tun sollt: niemals nicht eine Nonce
wiederholen! Das ist eine mittlere Katastrophe, das ist also, das ist
praktisch so ein Unfall. Das ist irgendwie.. genau. Also, und jetzt die
Frage, so, sei wie soll ich meine Daten verschlüsseln? Da gibt es jetzt wie
gesagt, mal schauen, also da gibt es jetzt 4 Kategorien: die erste ist die stärkste,
die vierte ist die schwächste, und man sollte schauen, dass man jetzt irgendwie
schaut, kann ich ein Verfahren aus der Kategorie 1 nehmen? Lässt das mein ..
irgendwie, mein Umfeld zu, meine Anforderungen? Wenn nicht, dann 2, wenn
nicht 3 und ansonsten 4. D.h. eine klassische Verschlüsselung, die wir so
kennen, ist so halt ziemlich das schwächste - schlechteste - was man tun
kann. D.h. wir müssen jetzt irgendwie schauen, dass wir mal da besser werden und
mal so auf 1 und 2 kommen und nicht nur bei 3 und 4 rumdümpeln hier. Damit die
Verahren auch robuster und stärker werden in Zukunft.
ruedi: OK, vielen Dank, ah, dein Zitat noch! lacht
cforler: Ah, ich hab noch eins, ja, genau - also, allerwichtigste Botschaft für
heute ist: Redet verdammt noch mal mit Kryptographen, ja! Also, ihr macht ja
einen Haufen cooler Software und die fällt dann auseinander, weil man nie mit uns
geredet hat. lacht
Also wir sind irgendwie beide.. unsere E-Mail-Adresse, unsere Telefonnummer sind
irgendwie im Internet, stehen die, und da kann man uns mal sprechen und, ja.
lacht Applaus
und genau, also man kann irgendwann mal nach Berlin kommen und mit uns reden. Bei
einem Käffchen. ruedi: Ja, noch mal also vielen Dank. Ich
möchte das auch noch einmal ein bisl aufgreifen, also damit es noch mal ganz
klar ist, dass das jetzt wirklich ein praxisrelevantes Problem ist. Also wenn
ich mich nicht täusche, also das ändert sich, aber als ich das letzte Mal
reingeguckt hab, war wirklich in TLS die Überlegung: Wir sind clever, wir benutzen
keine Verfahren, wo nicht Authentifizierung mit eingebaut ist und
wir verwenden zwangsweise das GCM, also Galois/Counter Mode. Das ist auch supi,
bis auf die Tatsache, wenn ein Nonce wiederholt wird, ist das katastrophal
schwächer als alle katastrophal.. alle Fehler, die man auf der unteren Ebene
machen kann. Also Kryptographie ist relativ schwer. Aber noch einmal der Apell
von Christian wirklich deutlich wiederholt: die Crypto-Gemeinde hat einen
starken wissenschaftlichen Teil, die auch offen publizieren und so weiter. Also
insofern noch einmal da der Hinweis: da mal rein zu gucken, was da ist, ist
wirklich eine gute Idee. Und nochmal wirklich an dieses: redet mit
Kryptographen, mal anbuzzen.. kommt jetzt der Grund, warum hier so voll ist: weil
wir noch was mit Blockchain machen wollen in diesen nächsten Folien. Auch da möchte
ich an ein paar Stellen sagen: Ein bisschen reden mit Kryptographen wäre ganz
angenehm gewesen. Also wir arbeiten da auch an verschiedenen virtuellen
Kooperationspartnern, also wir möchten da auch besser werden in Richtung verteilter
Echtzeit, aber da arbeiten wir schon lacht intensiv daran. Also wer da noch
weitere Tips hat, was es da noch für Forschungseinrichtungen gibt, der kann
sich auch bei uns freundlich melden. So, mal ein paar Worte zu Bitcoin. Ich hab's
mal schon vor Jahren hier gemacht, ich hätte damals vielleicht Bitcoin kaufen
sollen, anstatt das zu.. sicherheits zu evaluieren. - Nein, hätte ich nicht - soll
man nicht machen, ich bin da altmodischer Professor. Ich bin der Meinung - wenn da
von.. also, von führenden kapitalistischen Zeitungen gefragt wird, wie sicher das ist
- dann solltest du nicht irgendwelche Aktien drin haben, um da zu antworten. Ich
will es mal so sagen: die Kryptographie in Bitcoin wäre eine befriedigende
Bachelorarbeit. Das sind schon.. und das reicht eigentlich. Die Crypto ist so
stark, dass eine befriedigende Bachelorarbeit völlig dazu führt, dass die
Probleme woanders zu sagen sind. Es ist vorsichtige Amateur-Kryptographie. Doppelt
hält besser, die hashen zweimal hintereinander, aber wie gesagt, meine
Erweiterung, nach dem ersten Hash ein Bit umzurempeln und dann weiter zu hashen
würde bedeuten, dass z.B. die Kollisionseigenschaften sich nicht einfach
weiter vererben. Also diese zweimal Hash hintereinander bringen z.B. gegen
Kollision nicht allzu viel, wenn sie nach dem ersten Hash ein Bit gerempelt hätten,
weiter gehasht, hätten sie eine deutlich bessere.. bessere Eigenschaften gehabt.
Also so ist jetzt das Doppelhash ziemlich.. nicht besonders relevant. Also
jedenfalls, wenn man starke Sachen macht. Was relativ cool ist, ist dass die die
Public Keys nicht veröffentlichen, sondern halt hier auch eine zweimal gehashte
Kontonummer. Und da sieht man, dass die möglicherweise doch ein paar Hacker-
Konferenzen gehört haben und gewusst haben, sie sind nicht so fit in Crypto:
"Machen wir es lieber mal ein bisschen robuster", und so weiter. Insofern ist das
eigentlich relativ erfreulich, aber wenn die jungen Leute mit.. oder alten Leute,
oder was immer für Leute, mal mit Kryptographen geredet hätten, hätten wir
ganz interessante Implikationen gehabt. Es ist ganz lustig, der Bitcoin-Hauptautor
hat gesagt: "Oh ja, jetzt hashen die, alle Leute, mit Spezialhardware, und unser
demokratischer Ansatz 'jeder PC hat eine Stimme und alles verteilt' geht den Bach
runter. Wir sollten ein Gentlemen's Agreement machen, dass nur auf CPUs
gemined wird." Lachen
ruedi seufzt Ach, ist das schön, junge Leute! Dann..
ich mache einen.. lacht
ein Konzept von kryptogra.. äh, von kapitalistischen Anarchisten, die
irgendwie alles so designen, dass keine zentrale Stelle ist, und will mit diesen
verteilten Anarcho-Kapitalisten weltweit Gentlemen's Agreements zu machen. Ohne der
Geschichte vorzugreifen: es ist nur beschränkt gelungen.
Lachen Wobei das wirkt alles lustig, da, wenn
schlecht bezahlte Berliner Professoren hier rum[unverständlich] und gute Witze darüber
machen, das Problem ist, wenn man hier Fehler macht, dann hat das auf einmal
Auswirkungen, dass irgendwie eine große Menge an Energie völlig sinnlos verheizt
wird. Und da muss ich auch sagen, am Anfang habe ich gesagt, oh, Leute kommt
runter, es ist EIN Kraftwerk - was mir dann erst irgendwann mal siedend heiß
eingefallen.. ne, mit Erhöhung der Hashing-Komplexität tut praktisch linear
auch der Stromverbrauch irgendwie steigen. Also es ist jetzt schon auf dem Weg, eine
deutliche Umwelt-Sauerei zu werden und wir Krypto-Hippies könnten natürlich sagen:
"Können wir wenigstens nur mit Wasserkraft minen?" usw, aber unser Einfluss auf
verteilte krypto- und kapitalistischen Anarchisten ist relativ überschaubar. Also
insofern ist es wirklich kein Witz, dass einige Sachen, die wir haben.. wirklich es
hilfreich gewesen wäre, wenn die mit Kryptographen geredet hätten. Und hier
haben wir auch ein Bild, was ich mal einfach mal vorstellen wollte: Dieses
Proof of Work demokratisch zu halten, das ist sehr verwandt mit der Frage Passwort-
Hashing. Also Passwort-Hashing ist die Idee, aus dem gehashten Passwort soll es
sehr schmerzhaft, sehr arbeitsspeicher- intensiv sein, das Passwort wieder zurück
rechnen. Also klassischer Proof of Work. Dass ihr seht, dass das nicht ganz aus der
Welt ist: scrypt wird z.B. in Lite.. Moment, Litecoin? Litecoin verwendet, das
ist auch eine der größeren Sachen, und die haben scrypt verwendet. Die haben aber
auch nicht mit Kryptographen geredet, wie man die Parameter da vernünftig fährt mit
dem Ergebnis, dass jetzt mit ein bisschen Verspätung da auch ASICs kommen und
dieselbe Problematik, die wir bei Bitcoin haben, haben wir dort genauso. Auch hier
kriege ich manchmal bisschen die Krise, und ich sage, wir hätten das alles
demokratisch regeln können, wenn ihr mit uns geredet hättet. Wir hätten euch
umfangreiche Änderungen gesagt, nämlich genau eine Zahl geändert, einen Parameter
geändert. Dann wäre die ganze Sache auf einmal eine demokratische Veranstaltung
gewesen und nicht so, dass jetzt irgendwie sinnlos Sachen verbrannt werden und
irgendwelche.. nur noch Fabriken mitspielen dürfen. Das ist manchmal selbst
für Hacker und Mathematiker, die wissen, dass Zahlen eine gewisse Magie hat,
relativ gruselig. Also hier einen scrypt- Parameter richtig einzustellen, wär eine
gute Idee. Dann gibt es noch Passwort- Hashingverfahren.. äh, -Wettbewerbe, da
ist Argon2i, ne, war nicht - 2d! unverständlicher Kommentar aus dem Off
Du hast den Tippfehler wieder reingemacht, lacht
den du vorhin korrigiert hast! cforler: Ja, ja, wieder hinten integriert.
ruedi: Ä-ä-ä, das ist immer... cforler: Problem mit der Versionierung, ja.
ruedi: Das ist "d"! cforler: Das muß "d" sein.
ruedi: Naja, aber Catena-Stonefly, da hat er ja sich auch als Hauptautor
rausgemogelt, also Christian ist der Autor des ganzen Frameworks.
cforler: Mitautor, Co-Autor. ruedi: Co-Autor, ach so.
cforler: Das hab ich zusammen mit Stefan Lucks und Jakob Wenzel gemacht.
ruedi: Und das Catena-Stonefly ist eine Implementierung, die ganz besonders diese
Sachen adressiert, und - ne, haben wir die nicht - also, so sieht das aus, also ihr
seht, das ist ein bisschen was. Aber wenn man irgendwie große Geschichten jetzt
erwartet, ist es relativ überschaubar. Also das sind relativ naheliegende
Funktionen und das schöne ist halt an den Arbeiten von Forler et al.,
lacht dass da also sehr brutale Sicherheits..
also sehr ordentliche mathematische Sicherheitsschranken da ist. Also nochmal,
man könnte scrypt nehmen mit ein bisschen cleveren Parametern, oder man könnte das
andere Passwort-Hashing machen und dann hätte man mathematisch beweisbar, dass die
Leute nicht das auf Spezialhardware relativ einfach machen können. Also
nochmal diese Sache, die wir mehrfach gesagt.. redet mit Kryptographen. Noch
einmal, eine Zahl in diesen bitcoinartigen Sachen richtig gesetzt, hätten wir es
weiterhin demokratisch. Nicht mit Kryptographen geredet, gesagt: "OK, wir
machen Gentlemen's Agreement" bedeutet halt, dass irgendwie im Moment eine
obszöne Menge an Energie einfach fürs Mining verbrannt wird, und zwar völlig
nutzlos. Entschuldigung, ich stehe eigentlich auf Hashfunktionen, aber
irgendwie sinnlos irgendwie da vor sich hin zu hashen und alles wegzuschmeißen,
das kann nicht so die pfiffige Idee sein. Wenn man Proof of Work ist, noch einmal,
hier wäre es hilfreich gewesen, entweder also mit Kryptographen zu reden oder
zumindestens mal die Damen und Herren von Litecoin: Da mal überlegen, dass man die
Parameter vielleicht ein bisschen ordentlich setzen könnte. Gut, ich bin der
Meinung, dass wir wegkommen müssen von dem sinnlosen Heizen und deswegen werd ich in
den nächsten Monaten auch mit einem Doktoranden zusammen mal ein bisschen
arbeiten, Proof of Work nützlich zu machen. Da sind schon Ideen da, die im
Bereich Storage sind, da ist Filecoin z.B. ein Kandidat, der ähnliche Sachen macht.
Oder Network Services: ich habe durchaus die Überlegung dass es vielleicht sinnvoll
ist, bei der Anonymisierung des Webtraffics nicht auf das Tor-Projekt zu
vertrauen, dass seine Hauptfinanzierung vom amerikanischen
Verteidigungsministerium hat. Also ich hätte ganz gerne eine Konstruktion, wo
Router Netzwerk-Service, Tor-artige Services anbieten und damit praktisch auch
nebenher minen. Also dass praktisch Geräte sich selbst finanzieren und wenn man
irgendwie halt mal ein bisschen träumt, dann kann man halt sagen, man entwickelt
einen Router, den stellt man in der dritten Welt in die Sonne, solange Sonne
ist, tut der Energie machen und Services machen und wenn die Sonne weg ist, holt er
den Strom, aber bezahlt das mit der Arbeit, die er gemacht hat. Also dieser
Traum eines wirklich ganz autonomen Systems, das möchte ich noch auferhalten,
vielleicht einen Schritt zurück, ich hab einfach keine Lust, dass irgendwie Mining
- also wirklich 2^17 oder 2^73 Operationen - immer in sinnlose Umsetzung von Strom,
in Wärme, gemacht werden. Also vielleicht gibts..
Applaus Ja, Dankeschön.
Applaus
Und um es noch einmal zu wiederholen, den
ganzen Mist hätte man.. also diese Sachen sind anspruchsvoll und da sind sehr viele
Fragen zu klären, deswegen ist es eine schöne Promotion und ich bin da ein
altmodischer Professor, wenn es irgendwie die Welt nicht revolutioniert, 'ne gute
Promotionsthema ist es auf jeden Fall. Lachen
Insofern passiert die Revolution im Rahmen meiner dienstlichen Aufgaben, was
irgendwie von Professoren in meinem Alter immer eine ganz angenehme Perspektive auch
ist. Aber um es noch einmal zu betonen, wenn die Damen und Herren, die das gemacht
hätten, wirklich das Passwort-Hashing angeguckt hätten, wenn diese Litecoin-
Leute die Parameter richtig gemacht hätten, also nochmal: Macht euch die Kraft
von euch Programmierern und Mathematikern, und ne, sogar von euch Programmierern,
lest die Mathematik, die wir euch präsentieren, setzt die Zahl richtig und
ihr habt eine bessere Welt dadurch. Zumindestens, sagen wir mal, in dieser
virtuellen Welt, warte mal ab mit den Auswirkungen. Aber noch einmal, ich sage,
also erstens möchte ich einen wirklichen Proof of nützlicher, gesellschaftlich
nützlicher Arbeit. Zweitens, wenn ich dieses alte Proof of Work mach, das hätten
wir weiterhin demokratisch gehalten, wenn die Leute dieses Passwort-Hashing gemacht
hätten. Entweder das scrypt oder halt, sagen wir mal, die Sachen mit richtig hart
brutalen Sicherheitsbeweisen, die Christian da unter anderem entwickelt hat.
Kommen wir noch mal zum Ende. 'Wir sollten was tun' ist irgendwie das Ding, und ich
habe ja damals gesagt, Krypto-Magie ist, dass man auf einer kleinen,
fingernagelgroßen Fläche, oder mit ein paar Programmierzeilen, Code erzeugen
kann, den die Geheimdienste nicht brechen können. Das hat schon ein bisschen was
magisches, die.. problematisch ist, wenn man halt nicht reingucken kann und die
Leute das halt schlecht implementieren, wie das jetzt bei Infineon in Zusammenhang
mit den TPM-Chips passiert hat. - Oh, da haben wir eine Folie, die muss ich, glaube
ich, nachhalten. - Also bei den TPM-Chips, Infenion war einer der Hauptkandidaten,
und da ist es einfach so, das ist zwar vom BSI zertifiziert worden, aber
offensichtlich reicht das nicht aus. Wenn das Open Source gewesen wäre, wenn man da
reingucken könnte, dann hätte ein talentierter Doktorand wirklich nur wenige
Stunden gebraucht, um aufzuschreien und den Fehler zu finden. Also wir brauchen
wirklich auf der untersten Ebene Open Source ganz dringend. Wir brauchen freie
Software, die verhindert Hintertüren und ermöglicht das Finden der Fehler. Noch mal
zusammenzufassen: das BSI ist gutmütig, sie haben auch sehr gute Kryptographen,
aber sie haben es nicht gefunden. Und BSI ist noch eine der staatlichen
Organisationen, die ich noch am ehesten vertraue, sie haben es da episch gefailed.
Nochmal zur Erinnerung, diese Infineon- Chips stecken in den ganzen Google
Chromebooks an, wo in Amerika wirklich eine ganze Generation von Schülern mit
rumspringt: die haben's vermasselt. Also offensichtlich klappt es nur, wenn es
öffentlich ist und da darf ich noch mal auf meine geschätzten Kolleginnen und
Kollegen Bernstein, Lange und Nadja ... äh, Namen vergessen?
cforler: Tanja? ruedi: Heninger. Heninger, Entschuldigung.
Nadja Heninger. In dem Vortrag war einer der Highlights, wo sie gezeigt haben: Ha! Da
sind die Ergeb.. da sind die Submissions, Veröffentlichungen für diese Post-Quantum
Sache und innerhalb des ersten Abends, die haben sich wirklich einen Spaß gemacht,
und haben irgendwie 10 % von den Sachen innerhalb von drei Stunden zertrümmert.
Nehmen wir einfach mal zur Kenntnis, die öffentliche Kryptographie ist so viel
besser als Kryptographie hinter verschlossenen Türen. Dass das wirklich
hier ein Punkt ist: es ist nix ideologisches, aber der Code muss lesbar
sein. Das ist vernünftigerweise unter Open-Source-Lizenz, aber er muss lesbar
sein, die Community muss da reingucken. Keine Behörde ist offensichtlich dazu in
der Lage, das in irgendeiner Weise ordentlich zu machen. Der letzte Teil wird
nicht bei 'tuwat!' - Dankeschön. Applaus
Der letzte Teil von 'tuwat!' ist auch ein bisschen launisch, das habe
ich mir erlaubt, aber da irgendwie die Mathematik scheinbar so abschreckend ist,
dass es kaum jemand programmiert, gehen jetzt immer mehr Mathematiker dazu über,
brandneue Protokolle direkt zu implementieren. Als Erstes muss ich
sehr.. als sehr positives Beispiel den Herrn Kollegen Heiko Stamer erwähnen, der
hat auch am Datengarten einen sehr schönen Vortrag gemacht, da ging es um verteilte
Schlüsselerzeugung und Schwellenwertkryptographie. Da sind so
Sachen, wie wenn man sagt, in einer Welt, wo man wenig Leuten vertrauen kann, ist es
gut kryptographische Verfahren haben, wo man mathematische Beschreibung hat, des
Vertrauens. Also muss man einem aus einer Gruppe vertrauen, zwei aus einer Gruppe..
das können wir alles mit Schwellenwertkryptographie ganz gut
machen. Wie gesagt, das sind ganz aktuelle Implementierungen von 2017, die Arbeiten
vorher sind auch relativ neu, die sind von 1987.
Kichern Ja, ihr könnt ruhig lachen, das ist ein
Weilchen her, aber ihr könnt auch auf diese Folie warten, weil diese Sachen -
oh, das ist jetzt auch rausgeflogen - Blind Signature, wo ich also mit einem
Masterstudenten von mir ein bisl was entwickelt hab, 2016, auch auf der Open
TechSummit vorgestanden hab, basiert auf Blind Signature von David Chaum und die
sind von 1983. Und wir haben uns auch nur soviel Zeit gemacht, weil jetzt die
Patente endlich abgelaufen sind. Lachen
Spaß beiseite. Nicht alles, was wir hier machen.. also, elliptische Kurven ist
schon relativ harte Mathematik. Auch die Schwellwertkryptographie ist durchaus
harte Mathematik. Ich will das gar nicht so sagen: "Also guckt es einfach an, dann
ist es lösbar". Aber es gibt einen ganzen Kanon voll Sachen, wo es wirklich eine
kurze Frage an Kryptographen benötigt, um dann den richtigen Tipp in die richtige
Richtung zu machen. Auch diese Sache, dass wir halt programmieren, das war jetzt ein
bisschen arg schnippisch gesagt also: "Wir tun idiotensichere Krypto entwickeln".
Idiotensicher ist ein relativer Begriff. Ein armes, eingebettetes Gerät ohne
externe.. ohne interne Zufallsquelle hat halt keine gute Zufallsquelle. Also
insofern noch einmal, also wir arbeiten wirklich an einem System, möglichst robust
zu sein, in anderen Worten. Eine Nachricht, die hier noch einmal vielleicht
an die Standardisierung geht, ist wirklich der Punkt, zu sagen, GCM ist
offensichtlich für einige Probleme, also wenn diese Leute richtige Nonces machen -
wunderbar, supi. Aber willkommen in der realen Welt: Angreifer können dann
irgendwie anfangen, eben Nonces zu rempeln und dann auf einmal die Sicherheit und die
Integrität des ganzen Systems nachhaltig gefährden. Insofern ist das, glaube ich,
keine gute Idee, das als einzige Sache zu machen. Enden wir mit den guten Worten von
Edward Snowden: "Krypto ist keine dunkle, alte Kunst, sondern es ist wirklich eine
basic Protection, eine grundlegende.. Schutz da, wir müssen implementieren und
aktiv daran forschen". Und noch einmal, um zusammenzufassen, zu sagen, auch nach
vielen Jahren Snowden muss ich sagen, Kryptographie ist das, was uns vor der
Barbarei der Geheimdienste schützt. Die Politik hat da auch in den letzten Jahren
nicht unbedingt sehr gute Ergebnisse gezeigt. Insofern, vielen Dank für eure
Aufmerksamkeit. Applaus
cforler: Just in time! ruedi (zu cforler): Oh, da fehlten 1,2
Folien noch... Herald: So es hat ja geheißen, man soll
die Kryptographen fragen, nur leider ist die Zeit jetzt alle.
Unmuts-Laute Das heißt, ihr dürft, wie angekündigt, die
Fragen über ein Käffchen stellen, allerdings leider nicht mehr hier drin.
Aber trotzdem eine Runde schönen Applaus für unsere beiden Vortragenden! Vielen
Dank. Applaus
Abspannmusik