Möglicher Angriffsvektor der BIP32 HD Wallet

Ich habe über BIP32 HD Wallet und seine Implementierung gelesen und bin auf einige Fragen bezüglich des möglichen bekannten „Angriffs“-Vektors von durchgesickerten privaten untergeordneten Schlüsseln und bekannten übergeordneten Schlüsseln gestoßen, die zur Entdeckung des xpubübergeordneten privaten Schlüssels führen. Gegeben ist der folgende Pfad einer HD-Wallet:

m/b/p/c

Wo mist der Master-Knoten, der von einem Seed abgeleitet ist, b, p, cwobei es sich um indizierte Knoten in verschiedenen Tiefen handelt.

Stellen Sie sich vor, ein Server beobachtet und erstellt Empfangsadressen cvon p's xpub. Wenn der cprivate Schlüssel eines Knotens von durchgesickert und der Server gehackt wird, wodurch xpubder Angreifer aufgedeckt wird, könnte der Angriff nun p's generieren xpriv, und damit ckönnten alle privaten und öffentlichen Adressen des Knotens von vom Angreifer abgeleitet werden (gehärtet cKnoten enthalten).

Erste Frage: Wenn es psich um einen gehärteten Knoten handelt, könnte der Angreifer seinen privaten Schlüssel trotzdem aus seinem xpubund dem privaten Schlüssel eines Kindes berechnen?

xprivZweite Frage: Könnte der Angreifer die Tiefe (Berechnung der übergeordneten ) von pganz nach oben "erklimmen", mnachdem er p's xprivaus dem geleakten cSchlüssel und p's berechnet hat xpub? Würde ein Härter boder phier einen Unterschied machen?

Dritte Frage: Wenn ein privater Schlüssel aus cder Tiefe von durchgesickert ist und der Angreifer mden von kennt xpub, kann der Angreifer dann mden privaten Schlüssel berechnen oder erlaubt der Exploit nur die Berechnung des direkten Elternteils eines durchgesickerten Kindes?

Bonusfrage: Könnte jemand tatsächliche Anwendungsfälle für die Verwendung eines oder mehrerer gehärteter Knoten in einem Pfad nennen?

Antworten (1)

Erste Frage: Wenn es psich um einen gehärteten Knoten handelt, könnte der Angreifer seinen privaten Schlüssel trotzdem aus seinem xpubund dem privaten Schlüssel eines Kindes berechnen?

Ja. Es spielt keine Rolle, wie pgeneriert wurde. Entscheidend ist, wie cgeneriert wird.

xprivZweite Frage: Könnte der Angreifer die Tiefe (Berechnung der übergeordneten ) von pganz nach oben "erklimmen", mnachdem er p's xprivaus dem geleakten cSchlüssel und p's berechnet hat xpub?

Nur wenn der Angreifer auch ein bund m's hat xpub. Ein wichtiger Teil der Ableitung ist der Chaincode des Elternteils. Der Chaincode ist Teil des xpubund wenn der Angreifer den Chaincode nicht hat, kann er den privaten Schlüssel des Elternteils nicht ableiten.

Würde ein Härter boder phier einen Unterschied machen?

Wenn der Angreifer die Chaincodes bvon und hätte m, würde Härtung einen Unterschied machen. Die Härtung verhindert diesen Angriff vollständig. Das Härten erlaubt es jedoch niemandem, einen xpubSchlüssel ohne den privaten Schlüssel zu haben und zu generieren.

Dritte Frage: Wenn ein privater Schlüssel aus cder Tiefe von durchgesickert ist und der Angreifer mden xpub von kennt, kann der Angreifer dann den privaten Schlüssel von m berechnen oder erlaubt der Exploit nur die Berechnung des direkten Elternteils eines durchgesickerten Kindes?

Der Angriff funktioniert nur auf einem untergeordneten Schlüssel und seinem direkten übergeordneten erweiterten öffentlichen Schlüssel.

Angesichts mdes xpub- und cdes privaten Schlüssels von kann es jedoch immer noch möglich sein, den privaten Schlüssel von wiederzugewinnen, mobwohl er nicht cder direkte Elternschlüssel von ist. Wenn bund punter Verwendung einer ungehärteten Ableitung abgeleitet werden, mkann then zum Ableiten von und bverwendet werden . Von dort aus kann der Angreifer mit all diesen s rückwärts arbeiten, um .pxpubxpubcm

Wenn bund pverhärtet sind, dann ist es nicht möglich.

Bonusfrage: Könnte jemand tatsächliche Anwendungsfälle für die Verwendung eines oder mehrerer gehärteter Knoten in einem Pfad nennen?

Nehmen Sie zum Beispiel BIP 44. Es definiert einen Standardableitungspfad von m/44'/0'/0'/i/k. Das xpub at m/44'/0'/0'wird ausgegeben. Aber da er selbst mit gehärteter Ableitung abgeleitet wird, ist der Hauptschlüssel des Benutzers immer noch sicher, wenn irgendwelche von m, m/44'oder m/44'/0''s durchgesickert sind, da gehärtete Ableitung verwendet wird.xpub

Darüber hinaus leitet Bitcoin Core alle Schlüssel mithilfe einer gehärteten Ableitung ab. Dies liegt daran, dass BIP 32 für die einfachere Backup-Funktion verwendet wird (Sie können ein älteres Backup verwenden und immer noch dieselben Schlüssel erhalten) und nicht für die Überprüfbarkeit.

Chaincodes sollen mit anderen geteilt werden – nicht auf der Blockchain veröffentlicht, aber keine geheimen Daten. Die Beschreibung, dass die öffentliche BIP32-Ableitung sicher gegen private Schlüsselbeziehungen ist, solange der Angreifer nicht weiß, dass der Kettencode technisch korrekt ist, aber möglicherweise ein wenig gefährlich irreführend ist.
Wenn also im obigen Pfad irgendwelche c's xprivund p's xpubbekannt wären, cwürden nur die Knoten von exponiert und der Angreifer könnte nichts anderes mit den restlichen cübergeordneten Knoten von machen. Im Wesentlichen ist das Härten von Knoten nur in einem Szenario nützlich, in dem auch oder mbekannt sind, wodurch der gesamte Baum mit einem beliebigen privaten Schlüssel exponiert wird, ist das richtig? bxpubc
Ja, das ist richtig. Aber wie G. Maxwell betont, soll der Chaincode geteilt werden, und das Teilen des Chaincodes führt dazu, dass der gesamte Baum offengelegt wird.
Okay, das war alles, was ich wissen musste, danke!
Möglicher Angriffsvektor der BIP32 HD Wallet
AntwortenHierDatenschutz-Bestimmungen1y, 0v