Bitcoin begreifen

Kryptografische Hashfunktionen können zur Integritätsprüfung verwendet werden, um Änderungen in Daten festzustellen. Angenommen du willst dein Lieblings-Katzenbild auf der Festplatte deines Laptops abspeichern, aber du machst dir Sorgen, dass die Datei beschädigt werden könnte. Das könnte zum Beispiel aufgrund von Festplatten Fehlern oder Hackern geschehen. Wie kannst du sichergehen, dass du eine Beschädigung der Datei feststellen kannst?

Zunächst berechnest du den kryptografischen Hash des Katzenbildes auf deiner Festplatte und schreibst ihn auf ein Blatt Papier (Abbildung 8).

Später, wenn du das Bild anschauen willst, kannst du überprüfen, ob es sich geändert hat, seitdem du den Hash aufgeschrieben hast. Berechne den kryptografischen Hash des Katzenbildes erneut und vergleiche ihn mit dem, den du auf Papier hast (Abbildung 9).

Wenn der neue Hash mit dem auf dem Papier übereinstimmt, kannst du sicher sein, dass das Bild unverändert ist. Auf der anderen Seite, sollten die Hashes sich unterscheiden, so hat sich das Bild definitiv geändert.

Bitcoin verwendet kryptografische Hashfunktionen sehr ausgiebig, um zu überprüfen, dass sich Daten nicht geändert haben. Zum Beispiel wird immer ab und zu–durchschnittlich alle 10 Minuten–ein neuer Hash der gesamten Zahlungsgeschichte erzeugt. Wenn jemand versucht, diese Daten zu ändern, wird dies sofort von jedem, der die Hashes überprüft, bemerkt.

Die korrekte Antwort ist komplex, also werde ich nicht tief in’s Detail gehen. Aber um die Arbeitsweise einer kryptografischen Hashfunktion zu verstehen, werden wir eine sehr einfache schreiben. Nun ja, ehrlich gesagt ist sie nicht wirklich kryptografisch, wie ich später noch erklären werde. Nennen wir sie erstmal einfach eine Hashfunktion.

Angenommen du willst den Hash einer Datei mit den sechs Bytes a1 02 12 6b c6 7d berechnen. Du möchtest, dass der Hash eine 1 Byte lange Zahl ist (8 Bits) Du benutzt eine Hashfunktion, die die Addition modulo 256 benutzt, was bedeutet, sie bricht beim Wert von 256 um und fängt wieder bei 0 an, sobald das Ergebnis einer Addition den Wert 256 überschreitet (Abbildung 10).

Das Ergebnis ist die Dezimalzahl 99. Was sagt 99 über die Eingabedaten a1 02 12 6b c6 7d aus? Nicht viel; 99 sieht genauso zufällig aus wie jede andere zufällige Zahl.

Wenn du die Eingabedaten änderst, ändert sich auch der Hashwert, obwohl es möglich ist, dass der Hash trotzdem zufällig 99 ergibt. Schliesslich hat diese Hashfunktion nur 256 verschiedene mögliche Ergebnisse. Mit echten kryptografischen Hashfunktionen wie der, die wir für das Katzenbild benutzt hatten, ist diese Wahrscheinlichkeit unvorstellbar klein. Du wirst bald eine Idee von dieser Wahrscheinlichkeit bekommen.

Eine kryptografische Hashfunktion nimmt beliebige Eingabedaten, das sogenannte Pre-Image, und erzeugt daraus eine Ausgabe von fester Länge, die als Hash bezeichnet wird. In dem Beispiel mit dem Katzenbild auf deiner Festplatte ist das Pre-Image das Katzenbild von 1,21 MB und der Hash ist eine 256 Bit lange Zahl. Die Funktion liefert jedesmal genau denselben Hash für dasselbe Pre-Image. Aber mit allerhöchster Wahrscheinlichkeit wird sie einen vollkommen anderen Wert ergeben, wenn auch nur die winzigste Änderung am Pre-Image stattgefunden hat. Der Hash wird gemeinhin auch als Digest, also Kurzfassung, bezeichnet.

Schauen wir uns an, welche Eigenschaften wir von einer kryptografischen Hashfunktion erwarten können. Ich illustriere das anhand der Funktion SHA256, weil diese in Bitcoin am meisten verwendet wird. Mehrere kryptografische Hashfunktionen sind verfügbar, aber sie besitzen alle dieselben grundlegenden Eigenschaften:

Abbildung 11 illustriert die ersten drei Eigenschaften. Die vierte Eigenschaft einer kryptografischen Hashfunktion ist das, was sie kryptografisch macht, und das bedarf einer gewissen Erläuterung. Es gibt einige Varianten der vierten Eigenschaft, von denen alle für kryptografische Hashfunktionen wünschenswert sind (Abbildung 12):

Der Term schwierig bedeutet in diesem Zusammenhang astronomisch schwierig. Es wäre albern, es überhaupt zu versuchen. Wir betrachten Zweit-Pre-Image-Resistenz als Beispiel dafür, was schwierig bedeutet, aber ein ähnliches Beispiel kann für jede der drei Varianten aufgestellt werden.

Angenommen du willst einen Input für SHA256 finden, der zu demselben Hash führt wie der Input “Hello!”:

Du kannst ja nicht den Input “Hello!” einfach so geringfügig verändern, dass die Hashfunktion das nicht bemerkt. Sie wird es bemerken und der Output wird ein vollständig anderer Hash sein. Der einzige Weg, einen anderen Input als “Hello!” zu finden, der den Hash 334d016f…​d42c87b7 erzeugt, ist, verschiedene Inputs durchzuprobieren und immer wieder zu prüfen, ob der richtige Hash dabei herauskommt.

Probieren wir es mal mit Tabelle 3.

Wie du siehst, sind wir nicht sonderlich erfolgreich. Denk mal, wie lange ein Desktop Computer brauchen würde, um einen solchen Input zu finden. Er kann ungefähr 60 Millionen Hashes pro Sekunde berechnen, und die erwartete Anzahl Versuche, um eine Lösung zu finden, beträgt 2²⁵⁵. Das Ergebnis ist 2²⁵⁵ / (60 × 10⁶) s ≈ 10⁶⁸ s ≈ 3 × 10⁶¹ Jahre, oder etwa 30,000,000,000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000,​000 Jahre.

Ich glaube wir können aufhören, es zu versuchen, oder? Ich glaube nicht, dass es helfen würde, einen schnelleren Computer zu kaufen. Selbst wenn wir 1 Billion Computer hätten und sie alle gleichzeitig laufen würden, würde es noch 3 × 10⁴⁹ Jahre dauern.

Pre-Image-Resistenz, Zweit-Pre-Image-Resistenz und Kollisionsresistenz sind in Bitcoin extrem wichtig. Der Grossteil von Bitcoins Sicherheit beruht auf diesen Eigenschaften.

Tabelle 4 zeigt verschiedene kryptografische Hashfunktionen. Einige gelten als nicht kryptografisch sicher.

Ganz allgemein, wenn eine einzige Kollision in einer kryptografischen Hashfunktion entdeckt wurde, werden die meisten Kryptografen diese Funktion als unsicher betrachten.

Eine kryptografische Hashfunktion ist ein Computerprogramm, das beliebige Daten als Input nimmt und eine grosse Zahl berechnet–einen kryptografischen Hash–, der aus dem Input hervorgeht.

Es ist astronomisch schwierig, einen Input zu finden, der zu einem bestimmten Output führt. Deswegen nennen wir sie Einbahnfunktionen. Man muss immer wieder mit unterschiedlichen Inputs probieren.

Wir diskutieren wichtige Themen im ganzen Buch. Wenn du ein bestimmtes Thema gelernt hast, wie kryptografische Hashfunktionen, dann kannst du dieses Werkzeug für später in deine Werkzeugkiste legen. Dein erstes Werkzeug sind kryptografische Hashfunktionen, die hier durch einen Papierschredder dargestellt werden; der kryptografische Hash wird als ein Haufen Papierstreifen dargestellt.

Von nun an werden wir diese Werkzeug-Icons benutzen, um kryptografische Hashfunktionen und kryptografische Hashes darzustellen, mit wenigen Ausnahmen.

Angenommen, du willst dein Lieblings-Katzenbild per Email deinem Freund Fred schicken, vermutest aber, dass das Bild, auf bösartige oder anderweitige Weise, auf dem Weg dorthin verändert werden könnte. Wie könnten Fred und du sicherstellen, dass das Bild, das Fred erhält, genau das ist, das du weggeschickt hast?

Du kannst in der Email eine digitale Signatur des Katzenbildes mitschicken. Fred kann dann diese digitale Signatur verifizieren, um sicherzustellen, dass das Bild authentisch ist. Dies geschieht in drei verschiedenen Phasen, wie in Abbildung 13 dargestellt.

Schritt 1 ist die Vorbereitung. Du erzeugst eine Zufallszahl: den privaten Schlüssel oder private Key. Diesen benutzt du, um digitale Signaturen zu erstellen. Dann erzeugst du einen öffentlichen Schlüssel oder public Key, der dazu verwendet wird, die digitale Signatur zu überprüfen, die der private Key erzeugt hat. Der public Key wird aus dem private Key berechnet. Du übergibst Fred den public Key persönlich, damit Fred sicher sein kann, dass es wirklich dein public Key ist.

Schritt 2 ist die Signatur. Du schreibst eine Email an Fred und hängst das Katzenbild an. Du benutzt ausserdem deinen private Key und das Katzenbild, um das Katzenbild digital zu signieren. Das Ergebnis ist eine digitale Signatur, die du der Email Nachricht beifügst. Danach sendest du die Email an Fred.

Schritt 3 ist die Verifikation. Fred bekommt deine Mail, aber er macht sich Sorgen um die Echtheit des Bildes, also möchte er die Signatur überprüfen, oder verifizieren. Er verwendet den public Key, den er in Schritt 1 von dir bekommen hatte, die digitale Signatur in der Mail, und das angehängte Katzenbild. Wenn die Signatur oder das Katzenbild seit Erstellung der Signatur verändert wurde, dann scheitert die Überprüfung.

Es ist Zeit, auf unser Cookie Token Spreadsheet zurückzukommen. Die Firma wächst, und Lisa fällt es schwer, sich jeden Mitarbeiter zu merken. Ausserdem merkt sie, dass nicht jeder ehrlich ist. Zum Beispiel behauptet Mallory, Anne zu sein und Lisa dazu zu bringen, Cookie Tokens von Anne an das Café zu schicken, anstatt von Mallory. Lisa kommt auf die Idee, von jedem zu verlangen, alle Cookie Token Transfers digital zu signieren, indem sie eine Nachricht schreiben und dessen Signatur mit der Email mitschicken, wie in Abbildung 14 dargestellt.

Angenommen, John ist der neue Mitarbeiter im Büro. Die Firma hat ihm als Willkommensgeschenk einige Cookie Tokens gegeben, als er anfing. Nun möchte John im Café einen Keks für 10 CT kaufen. Er muss den Cookie Token Transfer digital signieren. Abbildung 15 zeigt, was er dafür tun muss.

Genau wie mit der Mail von Fred im vorigen Abschnitt besteht auch dieser Vorgang aus drei Phasen (vergleiche mit den Schritten in Abbildung 13, um die Ähnlichkeiten zu erkennen):

Die Signier- und Prüfvorgänge basieren auf einem Schlüsselpaar. John benutzt einen private Key, um die Zahlung zu signieren, und Lisa braucht Johns public Key, um die Signatur zu verifizieren. John muss das vorbereiten, indem er ein Schlüsselpaar erstellt. Er tut dies, indem er zunächst einen private Key erzeugt und dann daraus dessen public Key berechnet, wie in Abbildung 16 zu sehen ist.

John will einen Zufallszahlengenerator benutzen, um eine riesige, 256 Bit lange Zahl zu erzeugen. Ein Zufallszahlengenerator ist Teil praktisch jedes Betriebssystems. Die Zufallszahl ist Johns private Key. Der private Key wird dann mittels einer Ableitungsfunktion zum public Key umgeformt.

Der public Key ist 33 Bytes (66 Hexziffern) lang. Das ist länger als der private Key, der 32 Bytes (64 Hexziffern) lang ist. Der Grund für dieses zusätzliche Byte und wie die public Key Ableitung funktioniert ist ein schwieriges Thema, das in [ch04] behandelt wird. Glücklicherweise muss man kein Kryptografie-Experte sein, um zu verstehen, wie digitale Signaturen aus Benutzersicht funktionieren.

Fassen wir zusammen, was wir über public und private Keys gelernt haben. Man erzeugt ein Schlüsselpaar, indem man zunächst einen private Key generiert. Der private Key ist eine riesige, geheime Zufallszahl. Der public Key wird dann aus dem private Key berechnet.

Man kann den private Key zum Verschlüsseln einer Nachricht benutzen, die nur mit dem public Key entschlüsselt werden kann.

Die Ver- und Entschlüsselung in diesem Bild sind die Grundlage für digitale Signaturen. Dieser Prozess ist ungeeignet zum Versenden geheimer Nachrichten, da der public Key normalerweise allgemein bekannt ist.

Der umgekehrte Prozess ist ebenfalls häufig, wobei der public Key zum Verschlüsseln und der private Key zum Entschlüsseln verwendet wird. Dieser Prozess wird zum Versenden geheimer Nachrichten verwendet. Bitcoin benutzt ihn nicht.

Schauen wir uns an, wie das Signieren tatsächlich vonstatten geht (Abbildung 19).

Die Nachricht, die John signieren will, lautet: "Lisa, please move 10CT to Café. /John". Die Signaturfunktion hasht diese Nachricht mittels SHA256, was als Output eine 256 Bit lange Zahl ergibt. Dieser Hash wird dann mit John’s private Key verschlüsselt. Das Ergebnis ist eine digitale Signatur, die so aussieht:

Zum Beispiel würde die Input Nachricht “Lisa, please move 10CT to Mallory. /John” folgende Signatur erzeugen:

Das ähnelt nicht entfernt der vorigen Signatur. Das ist gut für John, denn er weiss, dass seine Signatur nicht für andere Nachrichten benutzt werden kann als seine eigene.

John hat eine Mail an Lisa erstellt. Diese Mail enthält eine Nachricht und die Signatur dieser Nachricht. John beendet den Vorgang mit dem Senden der Mail an Lisa.

Lisa schaut in die Mail und sieht, dass sie angeblich von John ist, also sucht sie in der Liste ihrer public Keys nach John (Abbildung 20).

Lisa versucht in dieser Grafik festzustellen, dass der Cookie Token Transfer mit dem private Key signiert wurde, mit dem es vorgibt, signiert worden zu sein. Die Nachricht sagt sie komme von John. Sie hatte Johns public Key neulich erhalten und ihn in ihre Tabelle der public Keys eingetragen. Die Dinge, die sie zur Verfügung hat, sind

Lisa nimmt die Signatur (B) und entschlüsselt sie mit dem public Key (C), den sie in ihrer Tabelle mit public Key nachgeschaut hat. Die Entschlüsselung ergibt eine grosse Zahl. Wenn diese Zahl mit dem Hash der Nachricht (A) übereinstimmt, so beweist dies, dass Johns private Key zum Signieren der Nachricht benutzt worden war. Lisa nimmt die Nachricht (A), genauso wie sie da steht, und hasht sie ebenso wie John das getan hat, als er die Signatur erstellte. Dieser Nachrichten-Hash wird dann mit der entschlüsselten Signatur verglichen. Der Nachrichten-Hash und die entschlüsselte Signatur sind identisch, also ist die Signatur gültig.

Wohlgemerkt funktioniert dieser Prozess nur, wenn John und Lisa dasselbe Signaturverfahren benutzen. Darauf müssen sie sich vorher geeinigt haben, aber es ist normalerweise standardisiert. In Bitcoin weiss jeder, welches Signaturverfahren zu verwenden ist.

Lisa kann jetzt sicher sein, dass niemand sie betrügen will. Sie aktualisiert das Spreadsheet mit Johns Transfer wie in Abbildung 21 gezeigt.

John besitzt die Kontrolle über seine Cookie Token, weil er den private Key besitzt. Niemand ausser John kann Johns Cookie Token benutzen, weil er der einzige mit Zugang zu seinem private Key ist. Wenn sein private Key gestohlen wird, kann er alle seine Cookie Token verlieren.

Am Morgen nach Johns Transfer kommt er ins Büro, nimmt seinen Laptop vom Tisch und geht direkt zum Café, um sich zwei Frühstückskekse zu holen. Er öffnet seinen Laptop und schreibt eine Nachricht an Lisa:

Er sendet diese Mail mit der Nachricht und der Signatur an Lisa. Aber das Café gibt ihm keine Kekse. Der Mensch hinter der Theke sagt, er hätte noch keine einkommende Zahlung über 20 Cookie Token gesehen. Lisa verifiziert und führt Transfers normalerweise schnell aus.

John öffnet das Spreadsheet—vergiss nicht, dass er read-only Zugriff besitzt, und sucht “John.” Abbildung 22 zeigt, was er sieht.

John geht in Lisas Büro und bittet um eine Erklärung. Sie antwortet, dass sie eine Nachricht bekommen hatte, die mit Johns private Key signiert worden war, und in der sie gebeten wurde, Geld an eine neue Mitarbeiterin namens Melissa zu schicken. Natürlich gibt es gar keine Melissa im Büro, obwohl mehrere neue Mitarbeiter bei der Firma angefangen haben. Lisa interessieren Namen nicht mehr, nur noch public Key und Signaturen. Aber sie braucht den Namen noch, um in der Tabelle nach dem richtigen public Key zu schauen.

Die Erklärung für all das ist, dass Mallory

Lisa hat den Transfer in Schritt 3 verifiziert, festgestellt, dass er gültig ist, und ihn dann ausgeführt. John bittet Lisa, den–ihm zufolge– betrügerischen Transfer rückgängig zu machen, aber Lisa weigert sich. Sie hält den Transfer für einwandfrei. Wenn John jemanden an seinen private Key heranlässt, dann ist das sein Problem, nicht Lisas. Das ist einer der Gründe, warum Lisa in der Firma als so vertrauenswürdig gilt–sie hält ihre Versprechen.

John erzeugt ein neues Schlüsselpaar und bittet Lisa, den neuen public Key unter dem Namen John2 abzulegen. Wie kann John seinen neuen private Key sichern und ihn dennoch immer bereithalten, wenn er einen Keks möchte? John ist sich ziemlich sicher, dass er nicht mehr als 1.000 Cookie Token auf diesem Key haben wird.

Die Sicherheit des Spreadsheet hat sich gewandelt von einem System, in dem Lisa von jedem das Gesicht kennt, zu einem, in dem sie von jedem den public Key kennt. In gewisser Weise steht es um die Sicherheit jetzt schlechter, denn es ist einfacher für Mallory, Johns private Key zu stehlen als Lisa dazu zu bringen, sie für John zu halten. Es hängt davon ab, wie sicher John seinen private Key verwahrt. Wichtig ist, dass die Sicherheit für Johns private Key vollständig ihm selbst überlassen ist. Niemand wird seinen private Key wiederherstellen können, wenn er ihn verliert. Und Lisa macht bestimmt keine “betrügerischen” Transfers rückgängig, weil John nachlässig mit seiner Sicherheit umgegangen ist.

Wenn John seinen private Key im Klartext in einem gemeinsam benutzten Folder auf dem Firmen-Intranet ablegt, kann diesen jeder kopieren und zum Stehlen seiner Cookie Tokens benutzen. Aber wenn John den private Key von einem starken Passwort geschützt in einer verschlüsselten Datei auf seinem eigenen Laptop ablegt, dann ist es viel schwieriger, den Schlüssel zu ergaunern. Ein Angreifer müsste

Wenn John nie mehr als 50 CT auf seinem private Key hat, dann mag er sich nicht viele Gedanken um die Sicherheit machen. Aber das Café, das etwa 10.000 CT pro Tag verwaltet, sollte besorgt sein. John und das Café brauchen wahrscheinlich unterschiedliche Strategien, um ihre private Keys zu sichern.

Es gibt einen Tradeoff zwischen Sicherheit und Bequemlichkeit. Du kannst zum Beispiel deinen private Key verschlüsselt auf einem Laptop in einem Bankschliessfach lagern. Wenn du einen Keks kaufen willst, musst du zur Bank gehen, den Laptop aus dem Schliessfach nehmen, den private Key entschlüsseln und eine digitale Nachricht an Lisa verschlüsseln, die du auf einem USB-Stick speicherst. Dann musst du den Laptop wieder in das Schliessfach einschliessen, den USB-Stick ins Büro mitnehmen und die Mail an Lisa schicken. Der private Key verlässt dabei nie den Laptop im Schliessfach. Sehr sicher, und sehr unbequem.

Auf der anderen Seite kannst du den private Key auch im Klartext auf dem Telefon speichern. Dann hast du den Key immer bereit und kannst in Sekunden eine Message signieren, wenn dich die Lust auf einen Keks packt. Sehr bequem, und sehr unsicher.

Einige der Tradeoffs, wie in Abbildung 23 dargestellt, sind die Folgenden:

Du kannst irgendeine Kombination dieser Methoden benutzen, um deine Keys zu speichern. Aber als Daumenregel gilt, je grösser die Sicherheit gegenüber Angreifern, desto grösser das Risiko, die Keys versehentlich zu verlieren. Wenn du zum Beispiel den private Key verschlüsselt auf deiner Festplatte speicherst, riskiert du dessen Verlust, wenn die Festplatte kaputtgeht oder du das Passwort vergisst. In dieser Hinsicht ist es umso unsicherer, je sicherer es ist.