Szenario:
Wenn ein privater Schlüssel einer deterministischen Brieftasche kompromittiert wird (einem Advisor bekannt), sind die anderen Schlüssel (und der Seed) immer noch sicher?
Das ist bei der electrum deterministic Wallet konstruktionsbedingt nicht der Fall und die Entwickler sind sich dessen bewusst. Wie wäre es mit anderen deterministischen Wallets, zB Armory?
Der vorgeschlagene Standard für hierarchische deterministische Wallets (siehe BIP 32 ) soll dies (und mehr) ermöglichen.
Es ist noch nicht implementiert, aber mehrere Autoren von Kunden haben zugestimmt, es zu übernehmen, sobald es endgültig ist.
Hatte das gleiche Bedürfnis und konnte keine benutzerfreundlichen Lösungen finden, also habe ich meine eigenen gedreht. Ich bin neu in Bitcoin und Krypto, also mit Vorsicht verwenden:
Ich gehe davon aus, dass Sie, wie Sie sagten, in der Lage sind, Ihre eigene Brieftasche zu erstellen. Unter solchen Umständen würde ich vorschlagen, dass Sie der folgenden Logik folgen.
Nehmen wir zunächst an, dass jemand (als die Blockchain-Website einige Tools in ihrem API-Bereich veröffentlicht hat) eine Software codiert hat, die in der Lage ist, Bitcoin-Adressen für externe Benutzer zu erstellen. Wenn in einem solchen Szenario die in einer solchen Software enthaltenen Algorithmen, die auf einem Server gehostet werden, eine Brieftasche mit mehreren Signaturen für die Benutzer erstellen können, bedeutet dies, dass bestimmte Benutzer beide privaten Schlüssel (2 Schlüssel pro Adresse) benötigen, die von erstellt wurden Software, um die Coins aus einem solchen Wallet mit einer einzigen Adresse auszugeben, und wenn der Server beispielsweise den privaten Schlüssel A aufbewahrt und dem Benutzer den privaten Schlüssel B liefert, dann hätten wir die Situation eines "hybriden Online-Wallets". Nur der Benutzer kann beide Schlüssel, A + B, verwenden, um Transaktionen im Zusammenhang mit seiner Bitcoin-Adresse zu erstellen, zu signieren und zu übertragen.
Ein solches System wäre für den Benutzer ziemlich sicher, wenn der Softwarebesitzer keine Kenntnis oder Interaktion mit dem privaten Schlüssel A (oder B) hätte und wenn die vor dem Speichern dieses privaten Schlüssels A verwendete Verschlüsselung für Dritte nutzlos wäre (selbst wenn er dort) jeglichen Zugriff auf diesen gespeicherten Schlüssel aus der Datenbank des Servers.
Auf der anderen Seite könnte der einzige Weg, eine Transaktion aufzubauen und mit beiden privaten Schlüsseln zu signieren, nur auf dem Server stattfinden (dies ist eine sehr wichtige Bedingung, wie ich später in diesem Szenario erläutern werde).
Wenn der Softwarebesitzer bereit ist, den Benutzern zu erlauben, den Server mit beiden Schlüsseln zu verlassen (zum Beispiel nur um ihre Konten zu löschen und solche Adressen als wirklich kalte Brieftaschen einzurichten), könnte er zwei Optionen anwenden.
Die eine wäre, den privaten Schlüssel A direkt an den Benutzer freizugeben und ihn so zu befähigen, die Schlüssel A und B an anderer Stelle (falls und wann erforderlich) zum Signieren von Transaktionen zu verwenden, oder die andere (irgendwie bessere), in der der Algorithmus es zulässt ein dritter Schlüssel, der C-Schlüssel, der in Verbindung mit Schlüssel B verwendet werden könnte, um Münzen von dieser Adresse auszugeben. Mit anderen Worten, der Benutzer geht wieder mit zwei privaten Schlüsseln in der Tasche, genug, um sie zum Erschöpfen der entsprechenden Adresse (öffentlicher Schlüssel) zu verwenden. Dies kann entweder durch Verwendung eines für den Server (oder für das Benutzerkonto) einzigartigen Seeds (bestimmter privater "D"-Schlüssel) oder sogar durch die Einrichtung des Schlüssels A als Seed realisiert werden. Wenn der Schlüssel A als Seed verwendet wird, dann könnte praktisch jeder mit Zugriff auf den Quellcode der Software den gesamten Adressbereich replizieren, der für den spezifischen Benutzer erstellt wurde (wenn der Schlüssel A "benutzerkontospezifisch" und nicht "adressspezifisch" ist). Ich sehe das letzte als unmöglich an, um von einem anständigen Systemadministrator verwendet zu werden (wenn er die geringste Vorstellung von den Risiken hat, die bei einer so niedrigen Sicherheitsauswahl auftreten). Nehmen wir also an, der Server erstellt Seeds mit höheren Privilegien (auch bekannt als benutzerspezifisch). Das wiederum könnte katastrophale Folgen für jeden unvorsichtigen Benutzer haben, der diesen Schlüssel A von einem mit Malware infizierten Gerät in eine beliebige Brieftasche importiert. (Vielleicht erinnert uns das irgendwie an die Electrum Wallet ? :/ ...) Ich sehe das letzte als unmöglich an, um von einem anständigen Systemadministrator verwendet zu werden (wenn er die geringste Vorstellung von den Risiken hat, die bei einer so niedrigen Sicherheitsauswahl auftreten). Nehmen wir also an, der Server erstellt Seeds mit höheren Privilegien (auch bekannt als benutzerspezifisch). Das wiederum könnte katastrophale Folgen für jeden unvorsichtigen Benutzer haben, der diesen Schlüssel A von einem mit Malware infizierten Gerät in eine beliebige Brieftasche importiert. (Vielleicht erinnert uns das irgendwie an die Electrum Wallet ? :/ ...) Ich sehe das letzte als unmöglich an, um von einem anständigen Systemadministrator verwendet zu werden (wenn er die geringste Vorstellung von den Risiken hat, die bei einer so niedrigen Sicherheitsauswahl auftreten). Nehmen wir also an, der Server erstellt Seeds mit höheren Privilegien (auch bekannt als benutzerspezifisch). Das wiederum könnte katastrophale Folgen für jeden unvorsichtigen Benutzer haben, der diesen Schlüssel A von einem mit Malware infizierten Gerät in eine beliebige Brieftasche importiert. (Vielleicht erinnert uns das irgendwie an die Electrum Wallet ? :/ ...)
Als letzte Möglichkeit steht noch die zur Verfügung, bei der der Server über einen eigenen Seed Key (mit höchsten Privilegien) verfügt, auf den kein Dritter zugreifen kann, und zwar in Kombination mit mindestens einem weiteren (Server ebenfalls mit Multi-Signatur geschützt).
Zurück zu Ihrer Situation, Sie sollten den Schlüssel B haben, der erhöhte Berechtigungen bietet (Sie können Schlüssel D und mehr erstellen, aber jeder, der D verwendet, kann keine anderen Schlüssel erstellen). Da dies jedoch eine Belastung für den Code darstellen würde, würde ich eine einfachere Option vorschlagen: die One-Way-One-Size-Shot-Transaktion. Das bedeutet, dass Sie die Schlüssel nach einer süßen Reinigung der Grundfunktionen in eine beliebige Brieftasche Ihrer Wahl importieren. Wie sagte einst Henry Ford über seine Autos „Sie können jede Farbe bestellen, solange es nur schwarz ist“.
Die importierte Adresse, wo immer sie gespeichert ist, kann so kodiert werden, dass eine einzige Operation möglich ist : Senden Sie eine Zahlung mit einem genauen Betrag nur an eine andere Adresse X von Ihnen (z. B. kann nur jedes Mal etwa 0,1 BTC an Ihre Hot Wallet gesendet werden -- Taschengeld). Brauchen Sie noch etwas? Eine weitere feste Tranche von 0,100 BTC an dieselbe Adresse. Nur das. Eine perfekte Anpassung. Natürlich kann die X-Adresse in einer Hardware-Wallet vollständig sicher gespeichert werden. Andere Arten von Ausgaben könnten nur über den Server selbst ermöglicht werden (um die volle Kontrolle über das Adressguthaben freizuschalten).
Es hängt alles davon ab, wie Ihre deterministische Brieftasche erstellt wurde. Wenn sie auf Hash basiert, wäre sie sicher. Was Sie brauchen, ist, dass es unmöglich ist, den Seed mit den tatsächlichen privaten Schlüsseln zu entdecken, also muss er eine Einwegfunktion (dh Hash-Funktion) verwenden.
Und im Allgemeinen umfasst die Kompromittierung eines privaten Schlüssels in einer Brieftasche nicht den Rest der Brieftasche.
KEY=HASH(SEED + offset)auch gehen? Auf diese Weise SEEDwären weder noch die anderen Adressen erratbar.Armory Wallet erlaubt dies und beeinträchtigt die Sicherheit der Wallet überhaupt nicht. Es gefährdet jedoch die Integrität Ihrer Backups. Deterministische Brieftaschen sind nützlich, da Sie gleich zu Beginn (bevor Sie sie verwenden) ein einzelnes Backup erstellen können, das für immer ein gutes Backup sein wird.
Das heißt, es sei denn, Sie importieren Adressen von woanders. Diese neuen Adressen befinden sich nicht in Ihrem alten Backup, daher müssen Sie an diesem Punkt ein neues Backup erstellen.
Alok