Ich bin jetzt knapp ein Jahr mit BTC in Kontakt und hab auch recht früh einen Ledger gekauft. Den hab ich mit zusätzlich mit passphrase versehen und den Seed gesichert. Das 25. Wort ist anderweitig gesichert.
Als ich jetzt ein paar Tage im Urlaub war ist mir etwas mulmig geworden weil ich drüber nachgedacht hab was passiert wenn bei mir zuhause eingebrochen wird und mein Seed-Backup gestohlen wird. Die BTC werden dank Passphrase nicht gestohlen, ich selber hab aber auch keinen Zugriff mehr drauf.
Nun hab ich mir eine Bitbox gekauft (BTC only) und überarbeite in dem Zusammenhang jetzt meine Backup-Strategie.
Ich werde den 2/3er Seed Split nutzen und weiterhin das 25. Wort (208bit) welches anderweitig gesichert ist (aber zusätzlich im Kopf)
Mir stellt sich nur eine Frage… ich habe die Bitbox erstellt und Gerätepasswort/Passphrase erstellt. Seed gesichert.
Kann ich nun ohne bedenken den Seed in die Bitbox eingeben ohne dass er kompromittiert wird?
Dieser Teil ist mir leider nicht 100%ig sicher. Ich meine klar funktioniert die Wiederherstellung aber ob die Wallet dann noch sicher ist wird nirgends erläutert. Einfach um zu testen ob die Wiederherstellung funktioniert bevor man seine Satoshis komplett umzieht.
Okay, kannst du konkret Gründe nennen warum du die beiden Maßnahmen kombinierst?
Du verkomplizierst damit etwas die Aufteilung deiner Backups. Für eine Wiederherstellung bräuchtest du 2 von 3 Splits und die Passphrase, welche du wegen Verlustgefahr doppelt sichern solltest.
Das wäre eine 3/5 Aufteilung, ohne wirklich relevanten Sicherheitsvorteil gegenüber einem reinen 2/3 Split.
Was meinst du damit? Entropie der Passphrase?
Ja, das kannst du machen. Eine Wiederherstellung mal selbst auszuprobieren ist sogar sehr empfehlenswert.
Effektiv gehts mir nur darum den Seed nicht komplett irgendwo hinzulegen. Wie gesagt, Einbruch z.b.
Dabei sei gesagt dass der jetzt nicht auf dem Schreibtisch rumliegt aber dennoch potentiell gestohlen werden kann.
Bankschliessfach traue ich leider auch nicht für ein 24er Backup
Wenn ich jetzt 1-8 16-24 etc. in 2/3er Aufteilung an 3 unterschiedlichen Orten sichere habe ein Halt wie gesagt immer noch das Backup selbst wenn es hier zuhause gestohlen wird. Es ist aber dennoch noch mit 80bit gesichert.
Die Passphrase ist die zusätzliche Sicherheit. Die ist zwar anderweitig gesichert, ist aber nicht nur mir bekannt (Familie im Haushalt weiß wie sie drauf kommen können). Dass beides gesichert sein muss ist mir klar. Wie gesagt, es ist mehr oder weniger im Kopf gespeichert. Als Eselsbrücke aber zusätzlich anderweitig.
Ja, das kannst du machen. Eine Wiederherstellung mal selbst auszuprobieren ist sogar sehr empfehlenswert.
Das war aber auch nicht der Punkt, mir ging es explizit darum ob es sicher ist die Wörter in die Hardware-Wallet einzugeben um sie wiederherzustellen. Ich weiß nicht inwiefern diese Auswahl der Wörter im Gerät gespeichert wird.
In den ganzen Anleitungen steht nur dass die Wörter angezeigt werden und man sie quasi bestätigen muss.
Ob es wirklich >200 Bit sind weiß ich nicht, hab’s mal in so einen Online-Calculator eingegeben (natürlich nur beispielhaft, nicht das richtige)
Ein anderer Calculator sagt 120bit
Eine Passphrase schützt dich doch bereits gegen dieses Risiko, also nochmal: Wieso die Kombination?
Ich würde dir empfehlen entweder eine Passphrase zu nutzen oder auf den Split zu setzen. Der Split ist dabei weniger Fehleranfällig und hat den zusätzlichen Vorteil dass du eines der drei Backups verlieren kannst ohne Totalverlust.
Verstehe die Frage nicht. Natürlich merkt sich deine Hardware Wallet deine Mnemonic, anders könnte sie auch nicht funktionieren. Völlig egal wie du wiederherstellst, also ob manuell oder mit der microSD Karte.
In deinem Fall kennt die Hardware dein Backup doch sowieso schon.
KeePassXC zeigt dir verlässlich die Entropie eines Passwortes an, kannst du ja mal ausprobieren.
Alles ab 100 bit ist für eine Passphrase vollkommen ausreichend, ansonsten leidet nur die Usability durch das lange Eintippen.
Nenn mich paranoid aber ich hab hier zuviele Horrorgeschichten gelesen
Ich danke dir zwar für die Ausführung und die Kritik, aber ich denke das ist dennoch der Weg den ich gehen werde. Die Passphrase ist ja auch weiterhin die selbe, nur der Seed ändert sich. Wie gesagt, es ist jetzt kein Passwort welches aus dem Keepass oder iCloud-Manager kommt. Es ist für die Familie recht leicht zu merken, man muss nur wissen wie es sich zusammensetzt… und das hab ich halt mit einer Eselsbrücke sichergestellt.
Insgesamt soll es halt langfristig sicher sein und da ist man sich ja nicht wirklich einig wie lange die 80bit sicher sind.
Wie gesagt, ich verstehe den Einwand. Fühle mich aber mit der Seed alleine einfach nicht sicher. Bank öffnet wegen „Geldwäscheverdacht“ das Bankfach und die Seed ist bekannt. Bringt aber nichts wegen der Passphrase. Die Seed ist aber dennoch kompromittiert.
Effektiv merk ich dann nichts davon und Passphrase könnte evtl. Schon als Ziel fungieren.
Wie gesagt, alles hypothetisch. Aber könnte dann nicht schlafen
Aber du scheinst das ja gut verstanden zu haben, pass einfach auf dass du dir nicht selbst irgendwo ein Bein stellst.
Ja ich denke den technischen Hintergrund hab ich doch schon recht gut verstanden. Ich meine die Fullnode läuft auf „nicht-Standard“ Hardware und ich nutze Specter für BTC. Das ganze mit VLAN im Netzwerk isoliert.
Deine Frage ob es sicher ist seine Mnemonic testweise einzutippen hat sich geklärt?
Ja das ist soweit klar. Wie gesagt es war mir nur nicht klar wie das ganze technisch im Gerät abläuft, ob die Wörter irgendwie an die BitBox-App übermittelt werden um den Seed zu berechnen oder sonstwas. Bin lieber vorher etwas gewissenhaft als nachher. Zur not hätte ich nen neuen Seed erstellt und beim Abschreiben halt noch mehr aufgepasst, wenn er auch nicht in die HW-Wallet eingegeben werden sollte.
Ich würde noch empfehlen, eine ausführliche Bedrohungsanalyse zu machen, denn offensichtlich hast du dich zumindest zum Teil damit beschäftigt.
Was meine ich damit: sind alle Daten für die erfolgreiche Wiederherstellung deiner Wallet(s) hinreichend gegen für dich relevante potentielle Bedrohungen ausreichend gesichert?
So ganz grob als (für mich) relevante Bedrohungen:
Einbruch/Diebstahl (Gegenmaßnahme z.B. komplexe Mnemonic Passphrase)
Brand Wohnung/Haus (Gegenmaßnahme z.B. sichere Lagerung an mehreren Orten (Redundanz!) ggf. zusätzlich feuerfeste Speicherung der Mnemonic Seed Daten, inkl. Mnemonic Passphrase (oder Multisig oder Shamir Secret Sharing))
Mnemonic Wörter und Mnemonic Passphrase natürlich immer getrennt voneinander, nie gemeinsam, sonst verliert die Mnemonic Passphrase ihren Zweck!
Unfall/Tod → kommen meine Erben narrensicher an alle relevanten Details heran, die dann auch redundant und auch sicher verwahrt werden müssen (der Teil ist komplex)
Sich selbst ein Bein stellen (Lernen, Verstehen, kein eigenes Security-Geschwurbel, Repeat)
Kurzum: welche Lösungen kann oder habe ich implementiert, damit keine der Bedrohungen jemals zum vollständigen Verlust meiner Wallet(s) führt.
Jede Maßnahme sollte auch (sicher!!) überprüft werden, soweit das sinnvoll und machbar ist. Jegliche Recovery sollte man mal tatsächlich durchgeführt haben, damit man auch weiß und verifiziert hat, daß es im Ernstfall funktioniert.
Also klar, mein Backup ist noch nicht für die Ewigkeit fix. Der 2/3 Split an sich ist ja schon in gewissen Maße Redundant.
Bzgl. Brand ist meine Seed in Seedor-Ausführung eben in 2/3 Manier an unterschiedlichen Orten. z.B. das bekannte Zuhause/Erdloch/Bank
Die Passphrase ist „sicher“ und durch Bekanntheit innerhalb der engsten Familie bekannt. Allerdings wird dieser Teil sicherlich noch durchs Testament abgesichert, nur aktuell steht der Teil Testament noch nicht auf meiner ToDo-Liste. Ich weiß, das kann schneller gehen als gedacht, aber aktuell sehe ich mich da noch nicht
Deinen letzten Teil mit dem Geschwurble und Repeat verstehe ich leider nicht.
Also ich plane das alles später auch ins Testament zu packen, aber aktuell ist die Sicherung erstmal durch direkte Bedrohung von außen… Einbruch, Brand, Staat etc.
Gesundheitliche und Zeitliche Aspekte sind bisher nur in grober Planung, das Konzept kann sich ja auch nochmal ändern. Dieses Konzept betrifft wie gesagt auch nur die Bitbox, die ich als HODL über längere Zeit nutzen möchte. Transaktionen VON der Bitbox sind erstmal nicht geplant. Dafür muss der Ledger noch herhalten.
Mit Security-Geschwurbel meinte ich die meisten selbsterfundenen Sicherheitsmechanismen oder Kryptoschemata, die allzu häufig mehr oder weniger fatale Fehler aufweisen, die der Erfinder häufig nicht wahrhaben oder einsehen möchte. Die wenigsten Personen sind in der Lage oder haben das nötige Wissen, um in diesem Bereicht etwas Gutes und Neues zu finden, daher sollte man mit eigenen Ideen hier sehr vorsichtig und demütig sein.
Den Prozess des Lernens und Verstehens kann man nicht oft genug wiederholen bzw. neu auflegen. Hinzu kommt, wenn man glaubt, etwas verstanden zu haben, kommt garantiert Jemand, der einem aufzeigt, daß es mit dem Verständnis dann doch noch nicht soo weit ist. Ich akzeptiere das (meistens), es ist OK.
Ok dann weiß ich was du meinst.
Bei den Überlegungen hatte ich auch erst an ein vertauschen der 8er Blocks gedacht. Also 1-8 an Stelle von 17-24 oder sowas in der Art.
Habe das aber wegen dir genannten Gründen verworfen. Zumal ich über diesen Weg dann erstmal gelernt hab dass das 24. Wort die Checksum darstellt, was dann natürlich nicht mehr hinhaut. (Plausible deniability)
Ein XOR Verfahren habe ich wegen der 2/3-Redundanz auch verworfen.
Ich will mir ja die Möglichkeit offen halten dass ein Part abhanden kommen kann.
Bei Berechnung einer neuen seed über XOR Brauch ich dann aber wieder ALLE teile.
Das ist auch der Grund wieso ich keine Multisig nutze. 2 von 3 keys ist schön, aber der xpub darf dann halt auch nicht fehlen.
Einen xpub kann ich mir nicht merken, die besagte Passphrase aber schon.
Also ich hab mir schon ein paar Gedanken gemacht und ausgesiebt bzw. abgewogen. Wie bereits gesagt, der 2/3 Split mit zusätzlicher Passphrase ist vielleicht außergewöhnlich, aber meiner Meinung nach jetzt kein absoluter Exot.
Bezüglich der Eingabe der 24 Wiederherstellungswörter in die BitBox02: ja, die BitBox02 nutzt diese Wörter um den Seed (das Hauptgeheimnis der Wallet) neu zu berechnen. Vereinfacht kann gesagt werden: die 24 Wörter sind der Seed (einfach anders encodiert, plus Checksumme).
Hardware-Wallets sind genau dafür gemacht, den Seed sicher aufzubewahren, gegen unberechtigten Zugriff zu schützen, und trotzdem nutzbar zu halten.
Den 2/3-Split und andere Themen der Seed-Sicherung, v.a. in Bezug auf Vererbung, habe ich hier mal in einem Artikel beschrieben:
Was mir am konventionellen 2/3-Split nicht gefällt, ist die Tatsache, daß jeder Einzelsplit bereits 2/3 des zugrunde liegenden Geheimnisses preisgibt. Das Restgeheimnis kommt dann schon in eine durchaus für Brute-force-Angriffe näherungsweise machbare Region und das wird mit dem Computerfortschritt ja eher machbarer als umgekehrt.
Verwendet man keine Techniken, die dem legitimen Besitzer anzeigen, daß Jemand Kenntnis eines Splits erlangt hat, dann kann der Angreifer in Ruhe Zeit für einen Brute-force-Angriff nutzen, ohne daß dies offenbar wird. Zugegeben ist das ein Szenario, das vielleicht unwahrscheinlich erscheint, aber auf Pseudo-Sicherheit sollte man auch nicht setzen.
An der Stelle finde ich Shamir Secret Sharing (SSS) eine interessante Option, da jede unvollständige Teilmenge an Splits rein garnichts über das kodierte Geheimnis verrät. Nachteil ist ein zusätzlicher Komplexitätslayer, der mitgeführt und dokumentiert werden muss. (Offensichtliche Sicherheitsprobleme sind mir bei Recherchen zum SSS nicht wirklich aufgefallen, das Verfahren erscheint mir „solid“.)
Im Szenario „Ein Einbrecher hat mein Backup gefunden, ich habe hoffentlich genug Zeit meine Bitcoin in Sicherheit zu bringen“ reichen 80 bit Sicherheit doch vollkommen aus.
Für alle anderen Threat Models, bei denen alles unter 100 bit ein Sicherheitsrisiko darstellt, gibt es multi-sig.
Aber nicht für Anfänger die einfach etwas mehr Redundanz haben wollen.
Du musst außerdem dein Backup digitalisieren und hast keinen Schutz vor Fehlern, die durch das Fehlen einfacher BIP-39 Wörter und Checksumme auch wahrscheinlicher werden – es sei denn du druckst aus, was aber einen weiteren Angriffsvektor öffnet. Es ist, wie immer bei SSS, eine Frage der perfekten Implementierung.
Für Anfänger ist SSS zu kompliziert und damit zu gefährlich, während man als fortgeschrittener gleich multi-sig nutzen kann – mit den effektiv gleichen Vorteilen, ohne zusätzliches Risiko.
In Bitcoin, Shamir Secret Sharing by itself has almost no valid use: Most threat models that could be defended using SSS are much better defended by multisig particularly because recombining shares of a private key on a device leave the key exposed to malware or a malicious user of the device which are usually the most important threats to protect against. If you have a device which is guaranteed to be free of malware operated by a user guaranteed to be incorrupt, you could just leave the private key there and dispense with the SSS ritual-security-theatre.
SSS finde ich bezüglich des 2/3 Splits interessant und habe es auch in die Überlegungen einfließen lassen. Mir gefällt die Tatsache aber nicht dass man Tails oder sonstiges nutzen muss um eine „sichere“ Umgebung zu bekommen. Gerade wenn es ums vererben geht kann da schnell mal ein Fehler passieren.
Verwendet man keine Techniken, die dem legitimen Besitzer anzeigen, daß Jemand Kenntnis eines Splits erlangt hat, dann kann der Angreifer in Ruhe Zeit für einen Brute-force-Angriff nutzen, ohne daß dies offenbar wird. Zugegeben ist das ein Szenario, das vielleicht unwahrscheinlich erscheint, aber auf Pseudo-Sicherheit sollte man auch nicht setzen.
Deswegen der 2/3 Split und zusätzlich die Passphrase. Sollte jemand meinen er müsste den letzten Teil Brute-Forcen ist er auf der „falschen“ Wallet. Dort kann man zur not auch einen Honeypot legen um festzustellen ob der Seed kompromittiert ist (z.b. Bluewallet Watchonly) Wie gesagt möchte ich für den 2/3 Split gerne Seedor nutzen und habe durch das Siegel die Möglichkeit auch festzustellen ob irgendwas „geleakt“ ist.
