Moin!
An die Techniker: Ich lese grade Mastering Bitcoin und verstehe einen Punkt bei „Gehärtete Ableitungen von Child-Schlüsseln“ nicht.
Warum lässt sich mit einem Private Child Schlüssel + einem Parent Chain Code ein Private Parent Schlüssel ableiten??? Der Parent Chain Code wird doch immer SHA512 gehasht. Es geht doch nie Rückwärts?
Gruß!
gmblr247
Schon klar, ist im Buch ja auch ähnlich erklärt. Aber das beantwortet meine Frage irgendwie nicht. Oder ich verstehe die Zuordnung/Grafik nicht.
Ich habe Mastering Bitcoin schon vor einiger Zeit angefangen zu lesen, aber dann wieder liegen lassen.
Vielleicht schaue ich mir das morgen mal an und falls ich es verstehe, kann ich dir meine Meinung dazu sagen.
Das BIP32 kennst du vielleicht schon. Dort wurden die Derivation Paths meines Wissens zum ersten Mal spezifiziert.
Ich habe mir das jetzt auch endlich einmal durchgelesen und verstehe das folgendermaßen (wirklich nur mein Verständnis bzw. meine Interpretation; vielleicht falsch).
Alleine ein Child Private Key + Parent Chain Code reichen denke ich nicht aus, um den Parent Private Key zurückzurechnen. Dem Parent Chain Code wird man allerdings auch nicht alleinstehend begegnen, sondern nur als Teils des Parent Extended Public Keys (xpub).
Ich denke im Buch ist es so gemeint, dass ein Child Private Key + xpub ausreichen, um den Parent Private Key zu ermitteln. Der Parent Public Key alleine würde nicht reichen, aber der xpub beinhaltet eben zusätzlich den Parent Chain Code.
So ähnlich ist das zu Beginn des gleichen Absatzes im Buch geschrieben, und so steht es auch im BIP32:
Note however that the following properties does not exist:
- Given a parent extended public key (Kpar,cpar) and a child public key (Ki), it is hard to find i.
- Given a parent extended public key (Kpar,cpar) and a non-hardened child private key (ki), it is hard to find kpar.
Angenommen also man hat einen einzelnen Private Key, sowie den xpub einer fremden Wallet gefunden. Man hat demnach einen Child Private Key + Parent Public Key + Parent Chain Code.
Dann würde ich folgendermaßen vorgehen:
Normalerweise fangen die Wallets bei der Ableitung der Private Keys und Adressen beim Index 0 an.
Man probiert der Reihe nach alle Indices durch, angefangen bei Index = 0. Für jeden Index erzeugt man aus xpub und Index über die Child Key Derivation function (HMAC-SHA512) die „left 256 bits“.
Ein Child Private Key ist die Summe aus dem Parent Private Key und den „left 256 bits“ des jeweiligen Indexes. Das steht glaube ich nicht direkt im Buch, aber im BIP32.
Von dem geleakten Private Key subtrahiere ich also die „left 256 bits“ und erhalte einen Parent Private Key Kandidaten.
Aus diesem berechne ich über secp256k1 einen Parent Public Key. Falls dieser dem tatsächlichen Parent Public Key entspricht, habe ich den Parent Private Key und damit auch den Parent Extended Private Key (xpriv) gefunden. Falls nicht zähle ich den Index eins hoch und probiere weiter.
Gehärtete Keys:
Bei gehärteten Child Private Keys ist das nicht möglich, da diese nicht von Parent Private Key + Parent Extended Public Key (xpub) abgeleitet werden, sondern ausschließlich vom Parent Extended Private Key (xpriv).
Einschätzung:
Ist es ein Problem, dass bei Verlust von xpub und eines einzelnen Private Keys der Gesamtverlust eines Accounts droht? Man muss bedenken, dass man früher vor den Hierarchisch-Deterministischen Wallets entweder nur eine Adresse, oder einen Haufen unkorrelierter Adressen hatte.
Entweder hatte man also nur einen Private Key, was bei Verlust des Keys ebenfalls einen Komplettverlust der Wallet bedeutete. Dagegen ist es heute etwas sicherer, da man eben noch mindestens den xpub benötigt.
Oder man hatte viele unkorrelierte Adressen und Private Keys. Das war beim Portieren und Sichern von Wallets sehr unkomfortabel, scheint aber erst einmal sicherer als heute. Ich denke aber das ist ein Trugschluss, da man beim Sichern und Verwahren von so vielen Keys sicher leichter Fehler macht.
Ein Zwischenschritt, der im Vergleich am sichersten ist, sind die nicht-hierarchisch, aber deterministischen Wallets. Dort wird alles von einem Seed abgeleitet, aber es gibt keine xpubs. Diesen Spezialfall könnte man heute immer noch erreichen, wenn man ausschließlich gehärtete Keys verwenden würde.
Ich weiß nicht ob es Wallets gibt, wo man das bis zur untersten Ebene einstellen kann (Electrum?). Ich persönlich bräuchte z.B. keinen xpub.
Hi! Danke dir für deine ausführliche Herleitung. Ich bin dennoch ein wenig verwirrt, denn ich kann die Aussage im Deutschen „Mastering Bitcoin“ auf Seite 115 unter „Gehärtete Ableitung von Child-Schlüsseln“ echt nicht nachvollziehen:
„Ein einziger durchgesickerter privater Child-Schlüssel legt zusammen mit dem Parent Chaincode alle privaten Schlüssel aller Children offen. Schlimmer noch: Mit dem privaten Child-Schlüssel und einem Parent-Chaincode können Sie den privaten Parent-Schlüssel ableiten.“
Ich habe da echt einen Hänger. Der private Child-Schlüssel generiert sich doch aus 1) dem privaten Parent-Schlüssel sowie 2) den linken 256 Bit aus einem HMAC-SHA512 Hash bestehend aus dem öffentlichen Parent-Schlüssel, Parent-Chaincode und einem Index. Ich kann doch den Hash nicht rückwärts berechnen. Vielleicht bin ich aber auch einfach nur auf dem falschen Weg?!
Ich denke immer noch, dass das im Buch einfach nur unglücklich formuliert ist. In der englischen Originalfassung wird auch das gleiche gesagt, es ist also kein Übersetzungsfehler. In der Figure 5-11 waren mir übrigens auch zwei Ungenauigkeiten aufgefallen.
Nach nochmaligem Überlegen bin ich aber immer noch der Meinung, dass wir recht haben.
Gerade habe ich auch nochmal ein bisschen im Netz gesucht und ich finde nur Bestätigungen meiner Annahme. Außerdem bin ich über stackexchange noch auf folgende Passage im BIP32 gestoßen:
One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it).
This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.
Das ist eine eindeutige Bestätigung unserer Annahme.