4. Wallets
Dieses Kapitel behandelt
-
Automatisieren von Zahlungen
-
Erzeugen und Verwalten von Schlüsseln
-
Einfache, sichere Backups anfertigen
Bisher haben wir nichts getan, um die User Experience für die Kollegen in der Firma, die das Cookie Token Spreadsheet benutzt, zu verbessern. Die Situation hat sich für die Benutzer verschlimmert, weil Mails an Lisa jetzt mehr Informationen benötigen als zu Anfang. Darüber hinaus sollen die Benutzer jetzt auch noch weitere Schritte unternehmen, um zur Verbesserung ihrer Privacy mehrere Adressen zu benutzen.
In diesem Kapitel werden wir eine mobile App bauen, die wir als Wallet (Abbildung 1) bezeichnen, welche viele der üblichen Aufgaben übernimmt, die Benutzer durchführen möchten. Dieses Wallet wird neue Adressen erzeugen, private Keys speichern, den Transfer von Adressen zwischen Benutzern vereinfachen und den Zahlungsprozess automatisieren.
Wir werden diverse Ansätze besprechen, wie man die Daten der Wallet sichern kann. Wir schauen uns auch ein neues Verfahren zur Schlüsselerzeugung an, namens hierachical deterministic wallets (HD Wallets), womit Backups total einfach werden; man braucht nur noch eine einzige Zufallszahl zu sichern, die als Seed oder Samenkorn bezeichnet wird, und das war es. Wir beenden das Kapitel mit einem optionalen Tauchgang tief in die Mathematik hinter public Key Ableitung.
Dieses Kapitel ändert nichts an Lisas Arbeit oder dem Spreadsheet. Wir konzentrieren uns hier auf die Benutzer.
4.1. Erste Wallet Version
Unter dir und deinen Kollegen bildet sich eine Gruppe Softwareentwickler, die eine mobile App namens Wallet bauen, um häufig vorkommende Aufgaben für sich und andere zu vereinfachen. Die Gruppe identifiziert die folgenden Aufgaben als die häufigsten:
- Neue Adressen generieren
-
Benutzer müssen ab und zu neue Cookie Token Adressen erzeugen. Sie möchten vielleicht für unterschiedliche Zwecke verschiedene Adressen benutzen, oder sogar für jede einzelne Zahlung eine neue Adresse benutzen, aus Gründen der Sicherheit und Privacy.
- Private Keys verwalten
-
Für jede erzeugte Adresse muss das Wallet den dazugehörigen private Key speichern und verwalten. Die private Keys vor Eindringlingen zu schützen ist eine heikle Angelegenheit.
- Zahlungsdaten vom Empfänger zum Sender übertragen
-
Wenn John einen Keks kaufen will, muss er die Adresse des Cafés und den Betrag in seine App eingeben. Das von Hand einzugeben ist umständlich und fehleranfällig, also wäre es schön, wenn John die Daten stattdessen mit der Kamera einlesen könnte.
- Eine Zahlung durchführen
-
Die App sollte in der Lage sein, eine Mail an Lisa zu schicken, die die digital signierten Zahlungsdaten enthält.
- Kontostand verfolgen
-
Benutzer wollen wissen, wie viele Kekse sie sich leisten können. Die App sollte die Summe der Cookie Token anzeigen, die der User zur Verfügung hat.
- Datensicherung der private Keys
-
Wenn private Keys in der App erzeugt werden, existieren sie nur in der App. Geht das Telefon verloren oder kaputt, sind die private Keys weg. Du weisst schon, was es bedeutet, wenn man seine Keys verliert, oder? Du brauchst eine Backup Möglichkeit für die private Keys.
Das Entwicklerteam baut eine erste Version der App und nennt sie das Wallet. Der Begriff Wallet ist nicht perfekt, weil die App eigentlich kein Geld enthält. Sie enthält die Keys, die man zum Ausgeben von Geld braucht. Das eigentliche Geld ist im Spreadsheet gespeichert. Die App ist einem physischen Schlüsselbund ähnlicher; aber der Begriff Wallet wird in der Bitcoin Welt für alles benutzt, was private Keys speichert, also sollten wir darüber wegkommen und weitermachen. Gehen wir mal die Features dieses Wallets durch.
Nehmen wir wieder mal an, dass John im Café einen Keks kaufen möchte (Abbildung 2). Sowohl John als auch das Café benutzen diese neue App.
Der Prozess geht durch verschiedene Schritte:
Quick Response (QR) Codes sind eine Möglichkeit, Text scanbar zu machen. Dieser QR Code lautet “Hello”:
-
Das Café bittet sein Wallet, eine neue Adresse zu erzeugen und 10 CT an diese Adresse zu verlangen. Diese neue Adresse und der Betrag werden auf dem Bildschirm als QR Code dargestellt. Der QR Code enthält Informationen darüber, wie viel zu zahlen ist, damit John es nicht manuell eintippen muss.
-
John zeigt mit der Kamera seines Telefons auf den QR Code, um die Zahlungsdetails zu scannen. Das Telefon scannt den payment URI (uniform resource identifier, eine allgemeine Spezifikation darüber, wie man Zeug identifiziert; eine Web URL ist ein Beispiel für einen URI):
ct:19UzNFW4Fq8wm8mtWmoPZAzE3tcB9tZVtN?amount=10
Dies sagt Johns Telefon, dass es das Cookie Token Wallet (ct:) öffnen soll
und 10 (amount=10) Cookie Tokens an die Adresse
19UzNFW4Fq8wm8mtWmoPZAzE3tcB9tZVtN schicken soll.
-
Johns Wallet zeigt John die Zahlungsdetails, der sie auf Plausibilität prüft und auf OK tippt.
-
Johns Wallet erzeugt eine Mail an Lisa, die genauso aussieht wie vorher. Das Wallet sucht automatisch eine Adresse, von der aus gesendet werden soll, und signiert die Nachricht mit dem richtigen private Key. Auf Lisas Seite hat sich nichts verändert. Sie verifiziert die Zahlungen wie vorher und führt sie auch genauso aus.
Schauen wir uns genauer an, was Johns Wallet in Schritt 4 tut (Abbildung 3). Das Wallet tut dasselbe, was ein Benutzer in den früheren Beispielen manuell getan hätte.
Denk daran, dass das Wallet drei Schlüsselpaare verwaltet: zwei mit Guthaben und eines ohne. Mit diesem neuen Wallet können Benutzer so viele Adressen haben, wie sie wollen, was gut für die Privacy ist. Das Wallet behält alle Adressen im Blick.
Das Wallet des Cafés sowie Johns Wallet überprüfen gelegentlich das Spreadsheet, um festzustellen, ob neue Zahlungen für einen der Walletschlüssel, als Absender, Empfänger oder beides vorliegen (Abbildung 4).
Obwohl John von der Zahlung weiss, bevor Lisa sie im Spreadsheet bestätigt hat, aktualisiert sein Wallet den Guthabenstand nicht, bis sie bestätigt ist. Warum? Lisa könnte die Zahlung zurückweisen. Vielleicht ist die Zahlung auf dem Weg verfälscht worden, oder die Mail ist in Lisas Spam Ordner gelandet, oder sie hat sie einfach nicht gesehen.
Wenn das Wallet den Kontostand aktualisiert, ohne erst die Zahlung im Spreadsheet zu sehen, könnte das John falsche Informationen geben. Das Wallet könnte allerdings so nett sein, John zu informieren, dass eine ausstehende Zahlung auf Bestätigung wartet.
4.2. Private Key Backups
Das Entwicklerteam generiert ein Feature, um die private Keys des Wallets zu sichern. Die Idee ist, dass das Wallet eine Textdatei erzeugt, die Backup-Datei, die alle private Keys enthält, und diese Datei an eine vom Benutzer angegebene Mailadresse sendet.
Stell dir vor, John möchte seine private Keys sichern. Das Wallet sammelt alle Keys, die es je erzeugt hat, und schreibt diese in eine Textdatei (Abbildung 5).
Die Textdatei wird an Johns Mailadresse gemailt. Findest du das problematisch? Ja, das grösste Problem ist, dass die Keys die Privacy der Wallet Applikation verlassen haben und in die Wildnis geschickt werden. Jeder mit Zugriff auf den Mailserver oder irgendwelche anderen involvierten Systeme könnte an die private Keys drankommen, ohne dass John es merkt.
Aber es gibt noch ein weiteres Problem. Sobald John eine neue Adresse erzeugt, nachdem er das Backup gemacht hat, ist diese Adresse ohne Backup. John muss ein neues Backup machen, in dem der neue Key enthalten ist. Für jeden neuen Key muss John ein neues Backup machen. Backups für jede neue Adresse zu machen, wird manchen Benutzern lästig.
Schauen wir uns ein paar einfache Lösungen für diese zwei Probleme an:
-
Schicke automatisch ein Backup, wenn eine Adresse erzeugt wurde. Das erhöht das Diebstahlrisiko, weil du mehr Backups verschickst.
-
Erzeuge vorab 100 Adressen und mache ein grosses Backup von allen. Wiederhole, wenn die ersten 100 Adressen benutzt worden sind. Das erhöht ebenfalls das Diebstahlrisiko, aber nicht so sehr wie Lösung 1.
-
Verschlüssele das Backup mit einem Passwort. Das sichert die Keys im Backup gegen Diebstahl.
Eine Kombination aus den Lösungen 2 und 3 scheint eine gute Strategie zu sein; man muss seltener ein Backup machen, und die Backup sind durch ein starkes Passwort geschützt.
Der Vorgang ist ähnlich wie die vorigen Prozesse, aber diesmal gibt John ein Passwort ein, das benutzt wird, um die private Keys zu verschlüsseln (Abbildung 6). Wenn John sein Telefon verliert, braucht er das Passwort und die Backup Datei, um seine private Keys wiederherzustellen.
Wenn John sein Telefon verliert, kann er einfach die Wallet App auf einem neuen Telefon installieren. John schickt die Backupdatei an die App und gibt sein Passwort ein; die Keys aus der Backupdatei werden entschlüsselt und seiner Wallet App hinzugefügt.
4.2.1. Ein paar Worte über Passwortstärke
Die Stärke eines Passworts wird in Entropie gemessen. Je höher die Entropie, desto schwieriger ist es, das Passwort zu erraten. Das Wort Entropie, wie es in der Informationssicherheit verwendet wird, kommt aus der Thermodynamik und bedeutet Unordnung oder Unsicherheit. Angenommen du konstruierst ein Passwort aus 8 Zeichen aus dem Satz der folgenden 64 Zeichen:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Jedes Zeichen im Passwort würde dann 6 Bits Entropie darstellen, denn es
gibt 64 = 26 mögliche Zeichen. Wenn du 8 Zeichen daraus zufällig wählst
(nichts herauspicken, bitte!), sagen wir E3NrkbA7, dann wird das 8 Zeichen
lange Passwort 6 × 8 = 48 Bits an Entropie haben. Das entspricht von der
Stärke her 48 Münzwürfen.
Nimm stattdessen an, dass du zufällige Wörter aus einem Vorrat von 211= 2,048 Wörtern heraussuchst. Wie viele Wörter brauchst du, um die 48 Bit Entropie von deinem 8 Zeichen langen Passwort zu schlagen? Vier Wörter wären nicht genug, denn das wären 4 × 11 = 44 Bit Entropie. Aber fünf Wörter stünden schon für 55 Bit Entropie, was besser ist als die Entropie des Passworts.
Die echte Entropie eines Passworts hängt aber auch davon ab, was der
Angreifer über das Passwort weiss. Zum Beispiel, mal angenommen ein
Angreifer, Mallory, stiehlt Johns verschlüsselte Backupdatei und versucht,
es mit der Holzhammermethode, oder brute force attack zu knacken. Eine
brute force attack heisst, der Angreifer geht durch alle möglichen
Passwörter und rät immer und immer wieder, bis er das richtige Passwort
findet. Wenn Mallory weiss, dass das Passwort genau 8 Zeichen lang ist, und
dass die Zeichen zu den vorhin genannten 64 Zeichen gehören müssen, dann
ist die Entropie 48 Bit. Wenn sie weiss, dass das dritte Zeichen 3 ist,
sinkt die Entropie auf 6 × 7 = 42 Bit. Wenn Mallory auf der anderen Seite
nicht weiss, wie viele Zeichen das Passwort hat, wird es schwieriger für
sie, das heisst die Entropie wird höher sein.
Das gilt nur, wenn die Passwort Auswahl wirklich völlig zufällig ist. Wenn
John sich Zeichen auswählt, um sich das Passwort j0Hn4321 auszusuchen,
fällt die Entropie dramatisch. Typische brute-force Angriffsprogramme
probieren zuerst eine Menge bekannte Wörter und Namen in verschiedenen
Variationen, bevor sie “zufälliger” aussehende Passwörter probieren. John
ist ein geläufiger Name, also wird ein Angreifer eine Menge verschiedener
Variationen dieses Namens probieren, sowie andere Namen und Worte. Zum
Beispiel:
butter122 … waLk129 … go0die muh4mm@d john John JOhn JOHn JOHN j0hn j0Hn jOhn jOHn jOHN … john1 … … john12 J0hn12 … j0Hn321 … j0Hn4321
Bingo! Angenommen es gibt 1.000.000 geläufige Wörter und Namen, und jedes Wort kommt durchschnittlich in 100.000 Variationen. Das sind 100 Milliarden verschiedene Passwörter zum Ausprobieren, was etwa 37 Bit Entropie entspricht; für 100 Milliarden Versuche braucht ein High-End Desktop Computer ein paar Tage. Sagen wir, der Einfachheit halber, dass es einen Tag dauert. Benutzt John ein echtes Zufallspasswort, dann ist die Entropie für den Angreifer 48 Bit. Das wären rund 2.000 Tage, oder etwa 5,5 Jahre, um das Passwort zu knacken.
4.2.2. Probleme mit passwortgeschützten Backups
Der Prozess für passwortgeschützte Backups klappt ziemlich gut, führt aber auch neue Probleme ein:
- Mehr Zeug, das abgesichert werden muss.
-
John muss sich jetzt um zwei Dinge kümmern: die Backupdatei und ein Passwort. In der ersten Version wurde nur eine Backupdatei benötigt.
- Vergessenes Passwort
-
Passwörter, die selten benutzt werden, wie das bei Backup-Passwörtern der Fall ist, werden irgendwann vergessen. Du kannst sie auf Papier schreiben und an einem sicheren Ort aufbewahren, um das Problem zu lindern. Du kannst sie auch mittels eines Passwort-Managers wie LastPass oder KeePass speichern.
- Technologische Fortschritte
-
Im Laufe der Zeit entsteht neue Hardware und Software, die das Knacken von Passwörtern beschleunigt. Wenn dein acht-Zeichen-Passwort vor fünf Jahren noch sicher war, ist es heute nicht mehr gut genug. Passwörter brauchen mehr Entropie, weil sich die Technologie verbessert. Du kannst deine Backupdateien alle zwei Jahre mit einem stärkeren Passwort neu verschlüsseln, aber das ist ein komplizierter Prozess, den wenige Benutzer schaffen werden.
- Zufall ist schwierig
-
Sich zufällige Passwörter zu überlegen ist wirklich schwer. Wenn die App John nach einem Passwort fragt, muss er adhoc eines produzieren. Er hat keine Zeit dazu, 48 mal eine Münze zu werfen, um ein gutes Passwort zu generieren. er wird höchstwahrscheinlich irgendetwas mit viel weniger Entropie erfinden. Ein Weg, damit zurechtzukommen ist, dass das Wallet John ein generiertes Passwort gibt. Aber sich dieses Passwort zu merken ist wahrscheinlich viel schwieriger als bei einem selbstgenerierten Passwort, was die Wahrscheinlichkeit für ein vergessenes Passwort erhöht.
Anscheinend musst du dir immer noch ein gutes Schema einfallen lassen, um mit Backups zurechtzukommen. Geben wir uns aber nicht mit dieser halbgaren Lösung zufrieden–es gibt bessere Ansätze.
4.3. Hierarchische Deterministische Wallets
Einer der schlaueren Entwicklerinnen in der Firma, einer Kryptografin, fiel eine neue Art ein, Keys zu erzeugen, um die Backup-Situation zu entschärfen und völlig neue Features zu Wallets zu bringen.
Ihr wird klar, dass wenn alle private Keys in einer Wallet aus einer einzigen Zufallszahl namens Random Seed–Zufalls-Samenkorn–erzeugt würden, das gesamte Wallet dadurch gesichert werden könnte, dass man den Seed auf ein Stück Papier schreibt und sicher verwahrt (Abbildung 7).
Sie spricht mit einigen anderen Kryptografen, und sie entscheiden sich für eine Strategie. Sie werden ein HD Wallet programmieren. Im Grunde werden die Keys dabei als Baumstruktur organisiert, bei dem ein Key die Wurzel des Baumes ist, und diese Wurzel eine beliebige Anzahl an Kind-Bäumen–Child Keys–haben kann. Jedes Child kann wiederum eine riesige Menge an eigenen Kindern haben, und so weiter.
Angenommen Rita will ihre Keys deren Zweck entsprechend organisieren und fünf Keys zur Benutzung beim Shoppen im Café und drei Keys zum Sparen erzeugen. Abbildung 8 zeigt, wie ihre Child-Keys organisiert werden könnten.
Die Keys sind als Baum strukturiert, aber es ist ein umgedrehter Baum, weil Computer Geeks so normalerweise ihre Bäume zeichnen. Jedenfalls wird die Wurzel des Baumes (an der Spitze) als Master private Key bezeichnet. Es ist der Key, von dem der ganze Rest an Keys abgeleitet wird. Der Master private Key hat zwei Child Keys: einen, der das Shoppingkonto repräsentiert (links, in Abbildung 8) und einen, der das Sparkonto repräsentiert (rechts). Jeder dieser Child Keys hat jeweils eigene Kinder. Das Shoppingkonto hat fünf, und das Sparkonto hat drei Kinder. Diese acht Kinder haben keine weiteren eigenen Kinder, weshalb sie als Blätter des Baumes bezeichnet werden. Die Blätter sind die private Keys, die Rita benutzt, um Cookie Token abzulegen, also wird für jeden dieser acht private Keys eine Adresse generiert.
Schau wie die Keys in den Bäumen numeriert sind. Jede Kindmenge wird von 0
an aufsteigend numeriert. Damit bekommt jeder Key einen eindeutigen
Identifikator. Zum Beispiel wird der erste, index 0, Sparkonto-Key mit
m/1/0 bezeichnet. m ist eine Besonderheit und bezeichnet den Master
private Key.
Wie wird eine solche Baumstruktur erreicht? Schauen wir uns die Erstellung von einigen Teilen des Baumes einmal an.
Drei wichtige Prozesse laufen ab, um den Baum zu erzeugen, wie Abbildung 9 zeigt:
-
Ein Zufalls-Seed von 128 Bit Länge wird generiert. Aus diesem Seed wächst später der gesamte Baum hoch (äh, runter).
-
Der Master extended private Key wird aus dem Seed abgeleitet.
-
The descendant extended private keys of the master extended private key are derived.
Ein extended private Key (xprv) enthält zwei Bestandteile: einen private Key und einen Chain Code (Abbildung 10).
Der private Key ist nicht von einem private Key der alten Generation zu unterscheiden, wie er direkt von einem Zufallszahlengenerator erzeugt worden war. Man kann ihn benutzen, um einen public Key und eine Cookie Token Adresse zu erzeugen. Normalerweise macht man Adressen nur aus den Blättern, aber man könnte auch interne Keys dazu benutzen. Der andere Teil des xprv ist der Chain Code. Ein Chain Code besteht aus den rechten 256 Bit eines 512 Bit Hashes, daher das rechte-Hälfte Hash Icon im Bild. Zu der Erzeugung dieses Hashes kommen wir gleich. Der Sinn des Chain Codes ist, Entropie zur Erzeugung eines Child xprv zur liefern. Der Master xprv unterscheidet sich nicht von anderen xprvs, aber wir geben ihm einen besonderen Namen, weil er der Urahn aller Keys im Baum ist. Er wird aber auch auf andere Art erzeugt.
In Schritt 1 wird der Zufalls-Seed auf die gleiche Weise erzeugt, wie in [ch02], als wir private Keys erzeugt haben. In diesem Beispiel generieren wir 128 Bit Zufallsdaten, aber es könnten genausogut auch 256 Bit sein, je nachdem, welche Sicherheitsstufe du willst–128 Bit reichen für die meisten Benutzer. Du siehst später, wie die Wahl der Seedgrösse Einfluss auf den Backup-Prozess haben wird: ein längerer Seed bedeutet, man muss während des Backups mehr auf Papier schreiben. Wir kommen in Abschnitt 4.5 darauf zurück.
Schritte 2 und 3 verdienen ihre eigenen Abschnitte.
4.3.1. Ableitung eines Master extended private Key
Schauen wir uns die Erzeugung eines Master xprv näher an (Abbildung 11).
Um einen neuen Master private Key zu erzeugen, wird der Seed mit HMAC-SHA512 gehasht (HMAC ist die Abkürzung für Hash Based Message Authentication Code), was einen 512 Bit Hashwert ergibt. HMAC-SHA512 ist eine spezielle kryptografische Hashfunktion, die neben dem normalen einfachen Input noch einen Key erwartet. Aus Benutzersicht kann man HMAC-SHA512 als normale kryptografische Hashfunktion betrachten, aber als eine mit mehreren Inputs. Der Hashwert wird in die linken 256 Bit und die rechten 256 Bit aufgespalten. Die linken 256 Bit werden zum Master private Key, was ein normaler private Key ist.; er heisst nur Master private Key, weil alle anderen private Keys von diesem einzelnen private Key abgeleitet werden (sowie vom Chain Code). Die rechten 256 Bit werden der Chain Code, der im nächsten Schritt benutzt wird, um die Kinder vom Master xprv abzuleiten.
4.3.2. Ableiten eines Child extended private Key
Du hast Ritas Master xprv erzeugt. Es ist Zeit, den Child xprv abzuleiten,
der die drei Sparkonto-Keys bündelt. Die direkten Kinder eines xprvs können
in beliebiger Reihenfolge abgeleitet werden. Leiten wir den Sparkonto-Key
m/1 zuerst ab. Der Vorgang, um ein Child xprv von einem Parent xprv
abzuleiten, ist wie folgt (Abbildung 12):
-
Der gewünschte Index wird an den Parent public Key angehängt.
-
Der public Key und der Index werden zum Input für HMAC-SHA512. Der Parent Chain Code agiert als vorübergehende Entropiequelle für die Hashfunktion. Zur Vereinfachung stell dir einfach vor, dass drei verschiedene Stücke von Daten zusammen gehasht werden.
-
Der 512 Bit Wert wird in zwei Hälften aufgespalten:
-
Die linken 256 Bits werden addiert, mittels normaler Addition (modulo 2256) zum Parent private Key. Die Summe wird der Child private Key.
-
Die rechten 256 Bits werden der Child Chain Code.
-
-
Der Child private Key und der Child Chain Code zusammen ergeben den Child xprv.
Derselbe Prozess wird für alle Children und Grandchildren des Master xprv benutzt, bis man alle Keys hat, die Rita in ihrem Wallet haben wollte.
Du fragst dich vielleicht, wozu man die Addition braucht–warum nimmt man nicht einfach die linken 256 Bits als Child private Key? Der 512 Bit Hash wird vom public Key und dem Chain Code–zusammen als extended public Key (xpub) bezeichnet–und dem Index berechnet. Du siehst später, wie der xpub in weniger sicheren Umgebungen, zum Beispiel auf einem Web Server, zur Erzeugung eines ganzen Baumes von public Keys benutzt werden kann. Man muss den Parent private Key zu den linken 256 Bit addieren, damit jemand, der den xpub besitzt, keine Child private Keys generieren kann.
4.4. Wo waren wir?
Erinnern wir uns nochmal, warum wir hier sind: um ein Wallet zu erzeugen, das den Benutzern das Leben einfacher macht (Abbildung 13).
Die Hauptaufgaben eines Wallets sind
-
Private Keys verwalten
-
Neue Adressen generieren
-
Zahlungsdaten vom Empfänger zum Sender übertragen
-
Eine Zahlung durchführen
-
Kontostand verfolgen
-
Datensicherung der private Keys
Wir haben die ersten fünf Punkte abgehandelt, sind aber mit den Backups noch nicht ganz fertig. Wir haben uns gerade Ableitung oder Derivation angeschaut, was die Basis für bessere Backups ist.
4.5. Zurück zu Backups
Du willst einen sicheren, einfachen Weg, um private Keys zu sichern. Du hast ein HD Wallet erzeugt, um eine beliebige Menge an private Keys aus einem einzelnen Seed herzuleiten. Was muss Rita mindestens sichern, um alle Keys in ihrem Wallet zurückzugewinnen, wenn sie das Wallet verliert? Richtig: den Seed (und die Baumstruktur, siehe Rand). Solange sie den Seed sicher verwahrt, kann sie immer alle ihre Keys regenerieren.
Angenommen, Ritas 128 Bit (16 Byte) Seed ist
16432a207785ec5c4e5a226e3bde819d
Es ist viel einfacher, diese 32 Hexziffern auf Papier aufzuschreiben als ihre acht private Keys. Aber der grösste Gewinn ist, dass Rita das einmal aufschreiben und dann in den Safe tun kann. Solange das Papier sicher aufbewahrt ist, ist ihr Wallet sicher gegenüber versehentlichem Verlust. Sie kann sogar neue Key aus demselben Seed erzeugen, ohne ein weiteres Backup anfertigen zu müssen.
Aber es ist immer noch schwierig, das ohne Tippfehler abzuschreiben. Was ist, wenn Rita einen Tippfehler macht und dann ihr Wallet verliert? Sie würde ihre Keys nicht wiederherstellen können! Man braucht etwas noch Einfacheres, das noch kompatibler mit der Arbeitsweise von Menschen ist.
4.5.1. Mnemonische Sätze
Erinnere dich daran, dass ein Seed eine Abfolge von Bits ist. Zum Beispiel ist Ritas Seed 128 Bit lang. Was, wenn man das auf menschenfreundlichere Art codieren könnte? Man kann!
Ritas Wallet kann den Seed als Abfolge von 12 englischen Wörtern darstellen, die als mnemonic sentence oder mnemonischer Satz (Merksatz) bezeichnet werden:
Seed: 16432a207785ec5c4e5a226e3bde819d
Mnemonic: bind bone marine upper gain comfort
defense dust hotel ten parrot depend
Dieser mnemonische Satz codiert den Seed auf eine menschenlesbare Art. Es ist viel zugänglicher, 12 Wörter hinzuschreiben, als kryptischen Hexcode. Wenn Rita ihr Wallet verliert, kann sie die Wallet App auf einem anderen Telefon installieren und den Seed aus diesen 12 Wörtern regenerieren.
4.5.2. Codieren des Seeds in einen mnemonischen Satz
| Wir untersuchen, wie diese Codierung funktioniert. Es ist wirklich spassig, aber wenn dir dieser Abschnitt zu tief geht, dann kannst du einfach den letzten Abschnitt glauben und vorwärts springen zu Abschnitt 4.6. |
Das Codieren beginnt mit dem Zufalls-Seed, wie in Abbildung 14 gezeigt. Der
Seed wird mit SHA256 gehasht, und die ersten 4 Bits des Hashes–in diesem
Fall 0111–werden an den Seed angehängt. Diese 4 Bits dienen as
Checksum. Dann arrangieren wir die Bits in 12 Gruppen zu 11 Bit, wobei jede
Gruppe eine Zahl im Bereich 0 bis 2047 codiert. Elf Bits können 211 =
2,048 verschiedene Werte darstellen, erinnerst du dich?
Die 12 Zahlen werden in einer standardisierten Wortliste aus 2048 Wörtern nachgeschaut, die von 0 bis 2047 durchnumeriert ist. Du findest diese Liste in BIP39 auf [web-bips]; sie enthält gängige englische Wörter. Nachdem du alle 12 Zahlen dort nachgeschaut hast, besitzt du den mnemonic sentence.
Der Satz bedeutet nichts besonderes. Es sind einfach 12 zufällige Wörter, so wie der hex-codierte Seed auch aus 32 zufälligen Hexziffern besteht.
Ritas Wallet zeigt ihr den mnemonic sentence, und sie schreibt die 12 Wörter auf ein Stück Papier. Sie legt das Papier in einen Safe und kümmert sich wieder um ihren Alltag.
4.5.3. Decodieren eines mnemonic sentence zu einem Seed
Am nächsten Tag fällt Rita das Telefon ins Meer und verschwindet in der Tiefe. Sie hat ihr Wallet verloren! Aber Rita macht sich keine grossen Sorgen. Sie kauft ein neues Telefon und installiert die Wallet App. Sie wählt die Funktion zum Restaurieren des Seeds aus einem Backup. Das Wallet bittet um den mnemonic sentence. Sie schreibt
bind bone marine upper gain comfort defense dust hotel ten parrot depend
in die Wallet App. Die App decodiert den Satz, indem sie den Codierprozess umkehrt. Rita kann ihre Keys aus dem decodierten Seed regenerieren, wie Abbildung 15 zeigt.
Das Decodieren benutzt die 4 Bit Checksum, um sicherzustellen, dass alles
stimmt. Wenn Rita versehentlich als letztes Wort deposit anstelle von
depend schreibt, wird die Checksum wahrscheinlich nicht passen, weil sie
das falsche Wort am Ende geschrieben hatte. Wenn sie depends statt
depend schreibt, wird das Decodieren definitiv scheitern, weil es das Wort
depends in der Wortliste gar nicht gibt.
Die Checksum ist ziemlich schwach–4 Bit ergeben nur 16 mögliche Checksums. Ein falsch geschriebener mnemonic sentence, in dem alle Wörter in der Wortliste vorkommen, hat daher eine 1/16 Wahrscheinlichkeit, nicht entdeckt zu werden. Das scheint ziemlich schlecht zu sein. Aber die Wahrscheinlichkeit, dass man solch einen Satz schreibt, ist ziemlich klein, denn die falsch geschriebenen Wörter müssten in der Wortliste vorkommen. Das verringert das Risiko eines ungültigen mnemonic sentence beim Wiederherstellen.
4.6. Extended public Keys
Rita hat ihr Wallet aus einem 128 Bit Seed erzeugt, den sie mit einem mnemonic sentence von 12 Worten gesichert hat. Ihr Wallet kann eine beliebige Anzahl an private Keys aus diesem Seed erzeugen. Sie kann diese nach Belieben in verschiedene “Konten” organisieren. Sehr schön. Aber HD Wallets haben noch ein weiteres Feature: Man kann einen Baum von public Key und Chain Codes erzeugen, ohne irgendeinen private Key zu kennen.
Angenommen, der Cafébesitzer verwendet ein HD Wallet. Er möchte die Kekse auf seiner Webseite verkaufen und diese an die Cubicles der Kollegen liefern.
Aus Gründen der Privacy muss der Web Server für jeden erkauf eine neue Cookie Token Adresse anzeigen können, aber woher bekommt er die Adressen? Das Café könnte einen xprv für einen Onlineverkauf Konto in seinem HD Wallet einrichten und den xprv auf den Web Server legen, wie in Abbildung 16 gezeigt.
Der Web Server kann jetzt neue Adressen erzeugen, wenn Bestellungen eingehen. Toll! Aber was ist, wenn Mallory, die Gaunerin, sich Zugang zum Massenspeicher des Web Servers verschafft? Sie kann dann alles Geld in allen Adressen im Onlineverkauf Konto stehlen. Sie kann aber nicht von irgendeiner anderen Adresse im Baum stehlen. Zum Beispiel kann sie nicht irgendeinen Key im Thekenverkauf Konto berechnen, weil sie keinen Zugang zum Master xprv hat, der benötigt wird, um Keys für das Thekenverkauf Konto und all dessen Children zu berechnen.
Typische Web Server sind anfällig für Hackversuche, weil sie normalerweise von überall in der Welt aus zugänglich sind. Geld auf einem Web Server zu speichern, würde vermutlich eine Menge Hacker einladen. Früher oder später würde es jemandem gelingen, Zugang zum Massenspeicher des Web Servers zu erlangen und den xprv zu stehlen.
Aus diesem Grund möchte das Café vermeiden, private Keys auf dem Web Server liegen zu haben. Dank des HD Wallets ist dies durch Benutzung von xpubs möglich (Abbildung 17).
Ein xpub ist ähnlich wie ein xprv, aber der xpub enthält einen public Key und einen Chain Code, wohingegen der xprv einen private Key und einen Chain Code enthält. Beide haben denselben Chain Code. Man kann einen xpub aus einem xprv erzeugen, aber nicht umgekehrt einen xprv aus einem xpub. Das liegt daran, dass die public Key Ableitungsfunktion eine Einbahnfunktion ist; ein public Key kann von einem private Key abgeleitet werden, aber ein private Key nicht umgekehrt von einem public Key.
Das Café legt den xpub M/1 auf den Web Server. Per Konvention benutzen wir
M, um einen xpub Pfad zu bezeichnen und m für einen xprv Pfad. M/1 und
m/1 haben denselben Chain Code, aber M/1 hat nicht denselben private
Key, nur den public Key. Man kann den gesamten xpub Baum aus dem Master xpub
erzeugen (Abbildung 18), was bedeutet, man kann alle und jede Adresse ohne
irgendeinen private Key erzeugen. Man kann Adressen erzeugen, aber von
diesen Adressen kein Geld ausgeben.
Das sieht genauso aus wie vorher, als du den Baum aus xprvs erzeugt hast. Der Unterschied ist, dass du keine private Keys hast. Wie Abbildung 19 zeigt, werden die xpubs anders erzeugt als die xprvs. Bitte vergleiche dies mit der Ableitung von xprvs.
Dies ähnelt der xprv Herleitung. Der Unterschied liegt in dem, was mit den linken 256 Bit des 512 Bit Hashes geschieht. Um den Child public Key zu berechnen, behandelt man die linken 256 Bit so, als wären sie ein private Key, und leitet einen public Key aus ihnen ab. Dieser public Key wird dann mittels der public Key Addition zum Parent public Key addiert. Das Ergebnis ist der Child public Key. Vergleichen wir einmal die Child public Key Ableitung mit der Child private Key Ableitung (Abbildung 20) ab dem Punkt nach der Erzeugung der linken 256 Bit des HMAC-SHA512 Hashes.
Für den private Key wird die normale Addition benutzt. Man addiert eine 256 Bit Zahl zum Parent private Key, um den Child private Key zu erhalten. Aber um das Ergebnis im Bereich der 256 Bit Zahlen zu halten, benutzt man Addition modulo 2256.
Die Addition, die zum Ableiten des Child public Key benutzt wird, ist nicht gerade das, was die meisten Leute (mich eingeschlossen) gewöhnt sind. Wir gehen in Abschnitt 4.8 näher darauf ein.
4.7. Ableiten von gehärteten private Keys
| Dieser Abschnitt ist anspruchsvoll. Wenn du es schwierig fandest, xprv Ableitung und xpub Ableitung zu verstehen, schlage ich vor, dass du diesen Abschnitt überspringst und direkt zu Abschnitt 4.8 springst. Du brauchst diesen Abschnitt nicht, um den Rest des Buches zu verstehen. |
Dieser Abschnitt erklärt, wie man ein Sicherheitsproblem mit der normalen xprv Ableitung verhindern kann.
Das Online Geschäft des Cafés läuft prima. Die Leute bestellen Kekse wie verrückt! Das online Verkaufskonto wächst, mit einem neuen public Key für jede Bestellung. Der xpub für die online Verkäufe liegt auf dem Web Server, und der xprv liegt nur im Wallet des Cafés (und in einem weggeschlossenen mnemonic sentence).
Angenommen Mallory stiehlt irgendwie den private Key m/1/1, der nur 10 CT
enthält. Dann mag das zwar harmlos aussehen, weil dieser private Key so
wenig Geld kontrolliert. Aber es könnte schlimmer sein als das. Falls es
Mallory ausserdem schafft, den xpub vom online Verkaufskonto des Web Servers
zu stehlen, dann kann sie den xprv des online Verkaufskontos ausrechnen,
wie man in Abbildung 21 sieht.
m/1/1 vom Café gestohlen und den Parent xpub vom Web Server. Jetzt kann sie das gesamte Geld im online Verkaufskonto stehlen.Weisst du noch, wie die xprv Ableitungsfunktion normale Addition benutzt, um einen Child private Key aus einem Parent private Key zu berechnen?
Das kann man auch schreiben als
Mallory hat alles, was sie braucht, um die linke Hashhälfte für jeden
beliebigen Child Index von M/1 zu berechnen, den sie will, aber sie weiss
nicht, welchen Index ihr gestohlener private Key hat, also beginnt sie bei
Index 0:
Sie leitet den public Key von diesem private Key ab und stellt fest, dass es
nicht zu M/1 passt, also war 0 nicht der korrekte Index. Sie probiert
dann Index 1:
Dieser private Key leitet sich zu M/1 ab. Bingo! Sie hat den private Key
m/1 für das online Verkaufskonto. Der xprv teilt sich den Chain Code mit
dem xpub, also hat sie auch den xprv für m/1, und sie kann den Baum von
private Keys für das Konto berechnen. Mallory stiehlt das gesamte Geld vom
online Verkaufskonto. Nicht gut.
Jetzt überleg mal, was passieren würde, wenn Mallory den Master xpub
hätte. Sie könnte mit derselben Technik den Master xprv aus dem Master xpub
und m/1/1 ableiten. Mallory könnte dann alle private Keys von allen Konten
im gesamten Wallet rekreieren. Können wir etwas tun, um ein solches
Katastrophenszenario zu verhindern? Ja, mit noch einer Key
Ableitungsfunktion! Diese neue Ableitungsfunktion heisst gehärtete xprv
Ableitung.
Angenommen, das Café möchte verhindern, dass Mallory auf den master xprv zugreift, selbst wenn sie den master xpub und einen privaten Schlüssel im Online Verkaufskonto hat. Das Café kann den xprv für das Online Verkaufskonto mithilfe der gehärteten xprv Ableitung generieren, wie Abbildung 22 zeigt.
Das Apostroph in m/1' ist kein Tippfehler: Es wird benutzt, um eine
gehärtete Key Ableitung auszeichnen. Der Unterschied ist, dass man bei
gehärteter Key Ableitung den private Key anstelle des public Key
hasht. Ein Angreifer kann den “minus” Trick nicht mehr anwenden, weil der
Hash vom Parent private Key abgeleitet ist. Mallory kann die linke
Hashhälfte zum Subtrahieren nicht mehr ausrechnen, weil sie den Parent
private Key nicht kennt. Abbildung 23 illustriert das Ergebnis.
m/0' und m/1' gehärtete Keys sind.Das bedeutet auch, man kann keinen gehärteten Child xpub von einem Parent
xpub erzeugen. Man muss den Parent xprv haben, um irgendwelche Child Keys zu
generieren, public oder private. Die Abkömmlinge von m/1' können nicht als
gehärtete Keys abgeleitet werden, denn das setzt voraus, dass das Café den
private Key m/1' auf den online Web Server legt, was unsicher
wäre. Nichtgehärtete Blatt Keys im online Verkaufskonto machen das Café
empfindlich dagegen, dass ein Angreifer m/1'/1 und M/1' stiehlt. Wenn
das passiert, können alle Coins in dem Konto gestohlen werden. Mit einem
gehärteten xprv löst man das Problem von gestohlenen M und m/1'/1, aber
nicht den Fall von gestohlenen M/1' und m/1'/1.
4.8. Public Key Mathematik
Dieser Anschnitt steigt tiefer in die Mathematik hinter public Keys ein. Wir beginnen damit, wie ein public Key aus einem private Key durch public Key Multiplikation hergeleitet wird. Spätere Abschnitte werden dann ausführen, wie Child xprv Ableitung mittels public Key Addition funktioniert und wie public Keys in Bitcoin codiert werden.
4.8.1. Public Key Multiplikation
| Ich werde versuchen, dieses Thema in einfachen Begriffen zu erklären, aber wenn du glaubst es ist zu schwer, dann überspring diesen Abschnitt und springe zu Abschnitt 4.9. |
Denk zurück an vorhin, als du in [ch02] einen public Key aus einem private Key hergeleitet hast. Ich habe dir da eigentlich gar nicht gesagt, wie der public Key abgeleitet wurde. Das werde ich stattdessen hier probieren.
Ein public Key in Bitcoin ist eine ganzzahlige Lösung zu folgender Gleichung:
Viele solcher Lösungen existieren, ungefähr \(2^{256}\) davon, also vereinfachen wir, indem wir stattdessen die Lösungen zu \(y^2 = x^3 + 7 \mod{11}\) (Abbildung 24) benutzen.
Sie wird als Kurve bezeichnet, weil in der durchgehenden, realen Welt der reellen Zahlen die Lösungen eine Kurve wie diese hier bilden würden:
Die vorangegangenen Gleichungen sind Beispiele einer Klasse von Gleichungen, die als elliptische Kurven bezeichnet werden, und eine Lösung wird oft ein Punkt auf der Kurve genannt. Du kannst jetzt einen public Key, der ein Punkt auf der Kurve ist, aus einem private Key berechnen. Um dies zu tun, beginnst du an einem bestimmten Punkt, \(G=(6,5)\), auf der Kurve. \(G\) wurde mehr oder weniger willkürlich ausgesucht, ist aber allen als Ausgangspunkt für die public Key Herleitung wohlbekannt. Der public Key ist der private Key multipliziert mit \(G\).
Angenommen dein private Key ist \(5\). Dann ist dein public Key \(5G\).
Um diese Multiplikation auszurechnen, brauchst du zwei grundlegende public Key Operationen: Addition und Verdopplung, wobei Verdopplung als Addition des Punktes zu sich selbst betrachtet werden kann.
Um zwei Punkte zu addieren (Abbildung 25) ziehst du eine Gerade, die an den Rändern des Diagramms “umgebrochen” wird und die sowohl deine beiden Punkte schneidet als auch einen dritten Punkt. Dieser dritte Punkt ist das negative Resultat der Addition. Um das Endresultat der Addition zu erhalten, nimmst du den symmetrischen Punkt am selben \(x\) Wert.
Das Ergebnis von \((6, 5) + (2, 2)\) ist \((7, 8)\). Die Gerade zwischen den beiden Punkten schneidet den Punkt \((7, 3)\). Der komplementäre Punkt zu \((7, 3)\) ist \((7, 8)\), was das Ergebnis der Addition ist.
Einen Punkt zu verdoppeln (Abbildung 26) heisst, ihn zu sich selbst zu addieren, aber eine Steigung kann nicht aus einem einzigen Punkt berechnet werden. In diesem Spezialfall berechnet man die Steigung aus dem Einzelpunkt \(P=(6,5)\) durch \(3*x^2*(2y)^{-1} \mod{11} = 2\). Der Vorgang ist fast derselbe wir bei der Addition zweier unterschiedlicher Punkte, aber die Steigung wird anders berechnet.
Mit diesen zwei Grundoperationen, Addition und Verdopplung, kann man die Multiplikation von \(5\) und \(G\) herleiten. In binärer Form ist \(5\)
Der public Key ist dann
Fange bei \(G\) an und berechne den resultierenden public Key Punkt, indem du die Terme von links nach rechts durchgehst:
-
Berechne \(2^0*G = 1*G = G\). Einfach. Jetzt merke dir diesen Punkt.
-
Berechne \(2^1*G = 2*G\). Dies ist eine Punktverdopplung des zuvor gemerkten Punktes G aus Schritt 1. Merke dir den Punkt. Weil vor \(2^1*G\) eine 0 steht, tust du momentan nichts damit. Aber merke dir den Punkt.
-
Berechne \(2^2*G = 2*2*G\), was eine Verdopplung des zuvor gemerkten Punktes \(2*G\) ist. Weil vor \(2^2*G\) eine 1 steht, addierst du dieses Resultat zum Ergebnis von Schritt 1.
Kurz gesagt basiert Multiplikation auf einer Abfolge von Additions- und Verdopplungsoperationen.
4.8.2. Warum ist das sicher?
Der Multiplikationsvorgang ist relativ einfach durchzuführen; es braucht ungefähr 256 Schritte für 256 Bit lange private Keys. Aber das umzukehren ist eine völlig andere Geschichte. Es gibt keinen bekannten Weg, den private Key durch Punkt-“Division” (zum Beispiel, Punkt \((6,6)\) “geteilt durch” \(G\)). Der einzige bekannte Weg besteht darin, verschiedene private Keys auszuprobieren und zu sehen, ob dessen public Key derjenige ist, den du suchst. Das macht die public Key Ableitung zu einer Einbahnfunktion.
4.8.3. Xpub Herleitung
Du hast gesehen, wie ein normaler public Key aus einem private Key durch public Key Multiplikation hergeleitet werden kann. Aber wie kann die Addition eines Parent public Keys zu einem public Key, der aus den linken 256 Bits abgeleitet wurde, den Child public Key ergeben? Siehe Abbildung 27.
Du kannst dich überzeugen, dass das funktioniert, indem du sowohl die normale public Key Herleitung als auch die Child public Key Herleitung im selben Bild betrachtest: siehe Abbildung 28.
Das Schöne an elliptischen Kurven ist, dass die spezielle public Key “Addition” Operation ein bisschen funktioniert wie eine normale Addition. Dasselbe gilt für die spezielle public Key “Multiplikation”. Man kann daher einige Gleichungen lösen:
Das Ergebnis, \(C=Gc\), ist genau wie man den public Key \(C\) vom private Key \(c\) ableiten kann.
4.8.4. Public Key Codierung
Erinnerst du dich daran, dass Johns public Key wie eine riesige Zahl aussah?
035541a13851a3742489fdddeef21be13c1abb85e053222c0dbf3703ba218dc1f3
Das sieht nicht wie ein Koordinatenpaar aus, oder? Der public Key wird auf eine bestimmte Art codiert, Aufgrund der Symmetrie existieren exakt zwei Punkte für jeden Wert von stem\:[x], einer mit einem geraden stem\:[y] Wert und einer mit einem ungeraden stem\:[y] Wert (Abbildung 29).
Man braucht die \(y\) Werte nicht zu speichern, sondern nur, ob der
\(y\) Wert gerade oder ungerade it. Das geschieht, indem man dem \(x\)
Wert eine 02 (gerade) oder 03 (ungerade) voranstellt. In Johns Fall ist
der \(y\) Wert ungerade, also lautet das Prefix 03.
Deshalb sind public Keys 33 Bytes und nicht 32 Bytes lang. Es ist eine 256 Bit Zahl–die \(x\) Koordinate–mit einem Byte als Prefix, das die Geradzahligkeit oder Parität angibt.
Die Kurve in der Abbildung hat einen einzelnen Punkt \(x=5, y=0\). Das
sieht nicht symmetrisch aus, aber es ist eine sogenannte Doppel-Wurzel der
Kurve—zwei Punkte mit dem selben \(y\) von 0. Sie sind symmetrisch, weil
sie dieselbe Strecke von 5.5 von der Symmetrielinie entfernt sind. In diesem
Fall benutzen beide Punkte 02, weil 0 eine gerade Zahl ist.
4.9. Zusammenfassung
Schauen wir zurück, was wir in diesem Kapitel gelernt haben. Ein HD Wallet generiert einen Baum von Keys aus einem zufälligen, sogenannten Random Seed. Es kann Härtung benutzen, um die verschiedenen Zweige des Baumes voneinander zu isolieren.
Benutzer sichern ihre Keys, indem sie den Random Seed in Form von 12 bis 24 englischen Wörtern auf Papier schreiben und es sicher verwahren.
Das Café akzeptiert Cookie Token in seinem Online Shop. Es legt nur den xpub
für das online Verkaufskonto, M/1', auf den Web Server, der nun so viele
Adressen generieren kann wie nötig, ohne dafür einen private Key zu
benötigen. Die private Keys liegen im Wallet des Cafés und berühren niemals
den Webserver.
4.9.1. Systemänderungen
Unsere Konzepttabelle (Tabelle 1) wird in diesem Kapitel nicht aktualisiert. Die Wallets, die hier beschrieben sind, funktionieren im Grunde genauso wie sie es in Bitcoin tun, nur schicken sie Mails an Lisa anstatt Transaktionen ans das globale Bitcoin Netzwerk zu senden. Dazu kommen wir im nächsten Kapitel.
| Cookie Tokens | Bitcoin | Behandelt in |
|---|---|---|
1 Cookie Token |
1 bitcoin |
|
Das Spreadsheet |
Die Blockchain |
|
Email an Lisa |
Eine Transaktion |
|
Eine Zeile im Spreadsheet |
Eine Transaktion |
|
Lisa |
Ein Miner |
Feiern wir eine Release Party! Cookie Tokens 4.0, frisch aus dem Labor!
| Version | Feature | Wie |
|---|---|---|
|
Einfacher, zu bezahlen und neue Adressen zu generieren |
Mobile App “Wallet” |
Vereinfachte Backups |
HD Wallets werden aus einem Seed erzeugt. Nur der Seed, 12 bis 24 englische Wörter, muss gesichert werden. |
|
Erzeugen von Adressen in unsicheren Umgebungen |
HD Wallets können public Key Bäume erzeugen, ohne je einen der private Keys zu sehen. |
|
3.0 |
Sicher gegen teure Tippfehler |
Cookie Token Adressen. |
Privacy Verbesserungen |
Ein PKH statt eines Namens steht im Spreadsheet. |
|
2.0 |
Sichere Zahlungen |
Digitale Signaturen lösen das Problem mit Betrügern. |
4.10. Übungen
4.10.1. Wärm dich auf
-
Angenommen, du benutzt eine Bitcoin Wallet App und willst 50 BTC von deinem Freund auf deiner Bitcoin Adresse
155gWNamPrwKwu5D6JZdaLVKvxbpoKsp5Sempfangen. Konstruiere eine Zahlungs-URI für deinen Freund. Hinweis: in Bitcoin beginnt die URI mitbitcoin:`anstatt mit `ct:. Abgesehen davon sind sie gleich. -
Wie vielen Münzwürfen entspricht ein zufälliges Passwort von 10 Zeichen Länge? Das Passwort benutzt ein Alphabet von 64 Zeichen.
-
Nenne ein paar Probleme mit passwortgeschützten Backups. Es gibt mindestens vier.
-
Wie wird in HD Wallets der Seed generiert?
-
Woraus besteht ein xprv?
-
Woraus besteht ein xpub?
Übungen 4.7 und 4.8 setzen voraus, dass du Abschnitt 4.7 gelesen hast. Wenn du das übersprungen hast, kannst du auch diese Übungen überspringen.
-
Angenommen, du möchtest einen gehärteten xprv mit Index
7`aus `m/2/1erzeugen. Welche Information brauchst du, umm/2/1/7'zu generieren? -
Kann man den xpub
M/2/1/7'ausM/2/1erzeugen? Falls nicht, wie würde man dannM/2/1/7'erzeugen?
4.10.2. Grabe tiefer
-
Stell dir vor, du bist ein Bösewicht und besitzt den Master xpub eines ahnungslosen Opfers. Du hast ausserdem den private Key
m/4/1gestohlen, der 1 BTC enthält. Angenommen, du weisst ausserdem, dass der private Key diesen speziellen Pfad besitzt. Beschreibe, was du anstellen würdest, um den Master xprv auszurechnen. Verwende dabei diese Hinweise:
-
Nimm stattdessen an, dein ahnungsloses Opfer hat 0 bitcoins auf dem private Key
m/4/1, aber massenhaft Geld auf anderen Adressen unter demselben xprv. Kämst du in diesem Fall an das Geld heran?
Wenn du Abschnitt 4.7 nicht gelesen hast, kannst du Übung 4.11 überspringen.
-
Schlage ein besseres Verfahren vor, das dein Opfer hätte benutzen können, um dich am Diebstahl des ganzen Geldes zu hindern.
-
Sagen wir, der Cafébesitzer möchte seinen Angestellten Zugriff auf das Thekenverkaufskonto einräumen, weil sie für jeden Verkauf eine neue Adresse erzeugen müssen. Sie dürfen aber keinen Zugriff auf die private Key haben, weil der Besitzer den Angestellten nicht zutraut, diese sicher zu handhaben. Schlage vor, wie er dies erreichen kann. Hinweis: ein Wallet kann einen xpub exportieren.
-
Angenommen du arbeitest in dem Café und hast einen xpub in dein Wallet geladen. Deine Kollegin Anita hat denselben xpub in ihrem Wallet. Ihr könnt beide Zahlungen von Kunden anfordern, die in dasselbe Konto gehen. Wie würdest du feststellen, dass Anita Geld auf einen zuvor leeren Key erhalten hat? Hinweis: man kann Keys im voraus erzeugen.
4.11. Zusammenfassung
-
Du benutzt normalerweise eine mobile App, genannt Wallet, um Geld zu senden oder zu empfangen–Cookie Tokens oder bitcoins.
-
Das Wallet erzeugt und speichert Keys, scannt Zahlungsdetails und zeigt sie an, sendet Zahlungen, zeigt deinen Kontostand und sichert Keys. Du brauchst nichts davon mehr selber zu machen.
-
Backups richtig zu machen ist schwer. Passwortgeschützte Backups leiden unter Problemen mit vergessenen Passwörtern, technologischen Verbesserungen und Menschen, die lausige Zufallszahlengeneratoren sind.
-
Mit HD Wallets sichert man seinen Random Seed und legt diesen Seed geschützt ab. Das tut man nur einmal.
-
Der Seed kann als mnemonic sentence codiert sein, was das Aufschreiben vereinfacht.
-
HD Wallets erzeugen mehrere private Keys aus einem Seed und organisieren sie in eine Baumstruktur, um die Privacy zu erhöhen.
-
Der Baum von public Keys–oder einer seiner Zweige–kann aus einem xpub erzeugt werden. Das ist für unsichere Umgebungen wie Web Server geeignet.
-
Die gehärtete private Key Ableitung hält “Konten” kompartmentalisiert. Es beschränkt einen Angriff auf ein einzelnes Konto.