Schützt der BIP44-Schlüsselableitungspfad private Schlüssel, die innerhalb desselben Kontos abgeleitet werden?

Ich verstehe das mit

  • Ungehärteter erweiterter öffentlicher übergeordneter Schlüssel
  • privater Schlüssel des Kindes

Dies führt zur Kompromittierung des übergeordneten privaten Schlüssels und damit aller privaten Schlüssel von Geschwistern

BIP44 schlägt den Pfad vor m / purpose' / coin_type' / account' / change / address_index

Angenommen, ich verwende den Pfad m/44'/0'/0'/0, um öffentliche Schlüssel für das Konto abzuleiten0

Da The changeand address_indexnicht gehärtet ist. Und in meiner Anwendung werde ich die extended public keyat-Ebene m/44'/0'/0'/0offenlegen (um Adressen abzuleiten). Bedeutet dies, dass alle privaten Schlüssel innerhalb desselben address_indexKontos ebenfalls kompromittiert werden können, wenn einer der auf der Ebene abgeleiteten privaten Schlüssel kompromittiert wird?

Vermeiden Sie also mit diesem Weg nur weitere Kompromisse bis zu

  • Andere Konten u
  • Weiter bis zum Hauptschlüssel?

Hab ich recht?

Antworten (1)

Bip44 schützt nichts, wenn der Benutzer den Master-Root-Schlüssel hat, könnte er Zugriff auf alle privaten Schlüssel der anderen Konten erhalten.

Ihr Pfad ist falsch, es sollte so sein:

m/Zweck'/Münzentyp'/ Konto '/Änderung/Adressindex

Was Sie tun sollten, ist das Generieren des untergeordneten privaten Hauptschlüssels für den folgenden Pfad:

m/44'/0'/1'/

Jetzt hat der Benutzer nur Zugriff auf die Kontonummer "1" und sollte Adressen mit diesem untergeordneten privaten Hauptschlüssel und dem folgenden Pfad generieren:

m/changeAddress/addressIndex

Danke für den Hinweis auf den Fehler. Ich werde versuchen, mein Missverständnis zu klären und meine Frage klarzustellen. Ich verstehe, dass die Härtung hilft, den übergeordneten privaten Schlüssel zu schützen, der kompromittiert wird, wenn der erweiterte öffentliche Schlüssel + der untergeordnete private Schlüssel kompromittiert werden. Allerdings ist mir in BIP44 klar, dass changeund address_indexnicht gehärtet ist. Aus diesem Grund mache ich mir Sorgen, dass, wenn ein privater Schlüssel, den ich von diesem Pfad abgeleitet habe, kompromittiert wurde, dies bedeutet, dass alle anderen privaten Schlüssel mit demselben Konto, die von diesem Pfad abgeleitet wurden, ebenfalls kompromittiert sind.
Niemals, sie benötigen den privaten Hauptschlüssel, um Zugriff auf die privaten Schlüssel anderer Konten zu erhalten.
Wie wäre es mit demselben Konto? B. der private Schlüssel, um m/44'/0'/1'/0/0kompromittiert zu werden, mit dem erweiterten öffentlichen Schlüssel, bedeutet dies, dass m/44'/0'/1'/0/nalle privaten Schlüssel kompromittiert werden sollen?
Wenn sie den privaten WIF-Schlüssel nicht verwenden, benötigen sie den privaten Hauptschlüssel des Kontos.
Mit dem erweiterten öffentlichen Schlüssel sehen sie möglicherweise nur die Adressen, aber niemals die privaten Schlüssel.
Oh, ich bemerke gerade in Ihrer Antwort, die Sie erwähnen generate addresses using that child master private key. In meinem Fall möchte ich einen erweiterten öffentlichen Schlüssel verwenden, um eine Adresse zu generieren (weil ich eine Adresse im laufenden Betrieb generieren muss). Was ich also in meine Anwendung einfügen werde, wäre der erweiterte öffentliche Schlüssel unter path m/44'/0'/1'/0. Bedeutet dies, dass die von mir erwähnte Schwachstelle gültig ist?
Ich habe das Ganze nochmal überdacht und versucht es zusammenzufassen. Bedeutet dies Folgendes: 1) Wenn ich einen privaten Hauptschlüssel verwende, um einen öffentlichen Schlüssel abzuleiten, handelt es sich um einen gehärteten öffentlichen Schlüssel, und ich muss mir keine Gedanken über die Kompromittierung des privaten Schlüssels der Eltern oder Geschwister machen, wenn der private Schlüssel des Kindes offengelegt wird. 2) Wenn ich mich entscheide, einen erweiterten öffentlichen Schlüssel zum Ableiten von Adressen zu verwenden, dann bin ich der Schwachstelle ausgesetzt, unabhängig davon, ob ich den BIP44-Ableitungspfad m/44'/0'/1'/0oder einen anderen Pfad verwende, der ohne Prime endet.