Geräteartefakte und Wallet-Wiederherstellung · Lektion 4 von 5
Wiederherstellung von Wallets unter rechtmäßiger Befugnis
9 Min. Lesezeit
Eine Seedphrase oder eine Wallet-Datei zu finden, ist nicht dasselbe, wie zu wissen, worüber sie Kontrolle ermöglicht. Die Wiederherstellung ist der Schritt, bei dem Schlüsselmaterial in eine dokumentierte Liste von Adressen, Guthaben und Transaktionshistorie überführt wird und – sofern die Befugnis dies erlaubt – in Gelder, die durch die Behörde gesichert sind. Bei diesem Schritt kann ein unvorsichtiger Prüfer außerdem Gelder verlieren, einen Verdächtigen alarmieren oder ein Ergebnis erzeugen, das sich nicht wiederholen lässt. Diese Lektion behandelt die Wiederherstellung als forensisches Verfahren, das im Rahmen einer rechtmäßigen Befugnis durchgeführt wird: die einschlägigen Standards, die Umgebung, die Grenzen und die Dokumentation, durch die das Ergebnis belastbar wird.
Wiederherstellung als forensisches Verfahren
Die Wiederherstellung sollte erst beginnen, wenn vier Dinge geklärt sind. Die Befugnis deckt die Untersuchung des Schlüsselmaterials und gegebenenfalls die Übertragung der Gelder ab. Der Plan legt fest, wer die Wiederherstellung durchführt, wer sie im Vier-Augen-Prinzip bezeugt und wohin gesicherte Gelder übertragen werden (siehe die Lektion Sicherung beschlagnahmter Krypto-Assets). Die Umgebung ist ein isoliertes, für diesen Zweck vorbereitetes Prüfgerät. Und die Dokumentation wird vor der ersten Handlung angelegt, damit jede Ableitung, jeder Scan und jede Entscheidung sofort protokolliert wird.
Ziel ist zweierlei: als Beweismittel festzustellen, worüber das Schlüsselmaterial Kontrolle ermöglicht, und das Risiko auszuschließen, dass jemand anderes mit einer Kopie derselben Schlüssel die Gelder zuerst bewegt.
Von der Mnemonik zu Adressen
Die meisten modernen Wallets folgen drei Bitcoin Improvement Proposals, die auch von vielen anderen Chains verwendet werden.
BIP-39 wandelt Entropie in Wörter um. Entropie von 128 bis 256 Bit in Schritten von 32 Bit erhält eine Prüfsumme von einem Bit je 32 Bit Entropie, die aus dem SHA-256-Hash entnommen wird. Die kombinierten Bits werden in 11-Bit-Gruppen aufgeteilt, von denen jede einen Eintrag in einer Liste mit 2.048 Wörtern indiziert. Daraus ergeben sich 12, 15, 18, 21 oder 24 Wörter. Die nach Unicode NFKD normalisierte Phrase wird anschließend mit PBKDF2 unter Verwendung von HMAC-SHA512 und 2.048 Iterationen zu einem 512-Bit-Seed erweitert; das Salt ist die Zeichenfolge „mnemonic“, gefolgt von der optionalen Passphrase.
BIP-32 leitet aus diesem Seed einen Schlüsselbaum ab. Der Master-Schlüssel wird aus HMAC-SHA512 abgeleitet, dessen Schlüssel „Bitcoin seed“ ist. Kindschlüssel sind entweder normal oder gehärtet (Index 2^31 und höher, mit einem Apostroph oder h geschrieben). Ein erweiterter öffentlicher Schlüssel ermöglicht es jeder Person, die normalen öffentlichen Kindschlüssel abzuleiten; dadurch sind Watch-only-Wallets möglich. BIP-32 warnt außerdem, dass sich aus einem erweiterten öffentlichen Schlüssel in Verbindung mit einem beliebigen nicht gehärteten privaten Kindschlüssel der private übergeordnete Schlüssel ableiten lässt. Deshalb behandeln Prüfer xpubs als vertraulich.
BIP-44 legt die Struktur des Baums fest: m / purpose' / coin_type' / account' / change / address_index. Die ersten drei Ebenen sind gehärtet. Der Wert für change ist 0 für die externe (Empfangs-)Chain und 1 für die interne (Wechselgeld-)Chain. Coin-Typen sind in SLIP-0044 registriert, zum Beispiel 0 für Bitcoin, 1 für alle Testnetze, 2 für Litecoin, 60 für Ether und 195 für Tron. Spätere Vorschläge verwenden dieselbe Struktur mit einer anderen purpose-Nummer für jeden Skripttyp:
| Standard | Erster Empfangspfad | Skripttyp | Adresspräfix | Erweiterter Schlüssel |
|---|---|---|---|---|
| BIP-44 | m/44'/0'/0'/0/0 | P2PKH | 1… | xpub |
| BIP-49 | m/49'/0'/0'/0/0 | P2WPKH in P2SH eingebettet | 3… | ypub nach Konvention |
| BIP-84 | m/84'/0'/0'/0/0 | P2WPKH (native SegWit) | bc1q… | zpub |
| BIP-86 | m/86'/0'/0'/0/0 | P2TR (Taproot mit einem Schlüssel) | bc1p… | xpub (keine neuen Versionsbytes) |
| BIP-44, Coin-Typ 60 | m/44'/60'/0'/0/0 | Ethereum-Konto | 0x… | — |
Die forensische Folge ist, dass eine einzige Phrase gleichzeitig Gelder unter mehreren purposes, mehreren Konten und mehreren Chains kontrollieren kann. Auch Ethereum-Wallets unterscheiden sich: Bei manchen wird der Adressindex erhöht (m/44'/60'/0'/0/n), bei anderen der Kontoindex (m/44'/60'/n'/0/0). Eine Wiederherstellung, bei der nur ein Pfad geprüft wird, kann eine „leere“ Wallet melden, die nicht leer ist.
Das Passphrasenproblem
Die BIP-39-Passphrase ist die wichtigste Einschränkung jeder Aussage. Jede Passphrase, auch eine leere, erzeugt einen gültigen Seed und eine gültige Wallet; BIP-39 stellt dies als plausible Abstreitbarkeit dar. Bei einer falschen Passphrase erscheint keine Fehlermeldung, sondern lediglich eine andere, üblicherweise leere Wallet. Eine Person kann daher einen kleinen Scheinbestand ohne Passphrase und die tatsächlichen Guthaben unter einer geheimen Passphrase aufbewahren.
Der Prüfer kann nicht beweisen, dass keine Passphrase existiert. Der Befund muss präzise formuliert werden: „Mit einer leeren Passphrase zeigten die abgeleiteten Wallets auf den aufgeführten Pfaden und Chains keine Aktivität“ und nicht „Die Wallet ist leer“. Zum Wiederherstellungsplan gehört, das Fallmaterial nach einer getrennt von den Wörtern gespeicherten Passphrase zu durchsuchen und danach gemäß den in der Lektion Durchsuchung und Beschlagnahme von Krypto-Assets am Einsatzort erläuterten Regeln zu fragen.
Wiederherstellung auf einem isolierten Prüfgerät
Das allgemeine Vorgehen ist unabhängig von der verwendeten Software gleich:
- Vorbereiten: ein eigens dafür vorgesehenes, frisch eingerichtetes Prüfgerät verwenden, auf dem zuvor noch keine Schlüssel aus anderen Fällen gespeichert waren und dessen Netzwerkverbindung deaktiviert ist. Open-Source-Wallet- oder Ableitungssoftware verwenden, deren Version anhand des veröffentlichten Hashes verifiziert wurde, und Name, Version und Hash dokumentieren.
- Phrase prüfen. Die BIP-39-Prüfsumme erkennt die meisten Übertragungsfehler; eine ungültige Phrase wird im Vier-Augen-Prinzip anhand des Originals erneut geprüft. Bei einer 12-Wort-Phrase besteht ungefähr eine Chance von eins zu 16, dass eine zufällige Wortfolge die Prüfsumme besteht. Eine gültige Prüfsumme stützt daher die Annahme einer korrekten Übertragung, beweist sie aber nicht.
- Offline ableiten: die erweiterten öffentlichen Schlüssel und Adressen für alle plausiblen purposes, Konten und Chains ableiten und ausschließlich öffentliche Daten exportieren.
- Aktivität im Watch-only-Modus prüfen, vorzugsweise anhand der eigenen Nodes der Dienststelle. Anfragen an Drittanbieter-Server legen die Adressen und die Netzwerkidentität der Dienststelle offen, was die Vertraulichkeit beeinträchtigen und über den Serverbetreiber andere alarmieren kann. Mindestens bis zum BIP-44-Gap-Limit von 20 ungenutzten Adressen scannen und weiter, wenn bekannt ist, dass die Wallet-Software größere Abstände verwendet.
- Gelder sichern und dabei dem Plan folgen: Gelder mit Vier-Augen-Prinzip und einer Testtransaktion auf die von der Behörde kontrollierte Wallet übertragen. Gelder niemals über das eigene Gerät oder die eigene Software des Verdächtigen zurücksenden.
Nicht jede Phrase entspricht BIP-39. Electrum-Seeds kodieren eine Versionsnummer in einem Hash der Phrase statt einer BIP-39-Prüfsumme; ältere Monero-Wallets verwenden 25 Wörter; SLIP-39-Shamir-Anteile erfordern eine bestimmte Mindestanzahl an Anteilen. Zuerst den Standard identifizieren und anschließend Software auswählen, die ihn implementiert.
Die Wiederherstellungsdokumentation hält jeden Durchlauf fest:
{
"Fall": "CASE-0417",
"Wiederherstellungs-ID": "REC-002",
"Quellobjekt": "CASE-0417-I-012 (Metallplatte, Siegel TE-88213 geöffnet am 2026-03-16T10:05Z)",
"Bearbeiter": "Prüfer 2", "Zeuge": "Prüfer 4",
"Umgebung": "Prüfgerät EX-07, offline, neu eingerichtet am 2026-03-15",
"Software": "Open-Source-Ableitungstool v4.2.1, Release-SHA-256 9d0c…41ee",
"Phrasenstandard": "BIP-39, 24 Wörter, Prüfsumme gültig",
"Passphrase": "leer (kein Hinweis auf eine Passphrase im Fallmaterial gefunden)",
"Gescannte_Pfade": ["m/44'/0'/0'", "m/49'/0'/0'", "m/84'/0'/0'..m/84'/0'/2'", "m/86'/0'/0'", "m/44'/60'/0'/0/0..19"],
"Verwendetes_Gap_Limit": 50,
"Gefundene_Aktivität": "m/84'/0'/0': 31 verwendete Adressen, Guthaben 4,21907 BTC bei Block 940112",
"Exportierte_öffentliche_Daten": "xpub-Liste, SHA-256 b77a…0c3e",
"Maßnahme_bezüglich_Geldern": "Gemäß Anordnung OR-2026-118 übertragen; siehe Übertragungsprotokoll TR-004"
}
Die Dokumentation verknüpft den Durchlauf mit dem versiegelten Quellobjekt und dem Zeitpunkt der Siegelöffnung, nennt Bearbeiter und Zeugen, beschreibt die Umgebung und die verifizierte Software, gibt den Standard, die Annahme zur Passphrase und jeden gescannten Pfad an und hält das Ergebnis mit einer Blockhöhe fest, sodass jede Person das Guthaben später erneut prüfen kann.
Verschlüsselte Wallet-Dateien und Passwortwiederherstellung
Wallet-Dateien auf Computern und Smartphones verschlüsseln ihr Schlüsselmaterial üblicherweise mit einem Schlüssel, der aus einem Benutzerpasswort abgeleitet wird. Ist das Passwort unbekannt, hängt die Wiederherstellung davon ab, es zu finden oder wiederherzustellen. Allgemein gesagt, arbeitet die Passwortwiederherstellung in forensischen Laboren mit möglichen Passwörtern, die anhand von Fallinformationen zusammengestellt werden: Passwörter, die auf anderen beschlagnahmten Geräten, in Passwortmanagern oder Notizen gefunden wurden, bei Befragungen mitgeteilt wurden oder den bekannten Mustern der betreffenden Person entsprechen. Validierte Tools testen die möglichen Passwörter anhand einer Kopie der Wallet-Datei, niemals anhand des Originals. Die Schlüsselableitungseinstellungen der Wallet bestimmen, wie aufwendig jeder Versuch ist; ein Erfolg ist daher nie garantiert. Aufwand, Eingaben und Ergebnisse werden wie jeder andere Untersuchungsschritt protokolliert. Die Befugnis für diese Arbeit sollte ausdrücklich erteilt sein.
Hardware-Wallets sind ein anderer Fall. Aufgrund ihrer PIN-Schutzmechanismen und der Funktion zum Löschen nach fehlgeschlagenen Eingaben erfolgt die Wiederherstellung normalerweise über das Seed-Backup, nicht über das Gerät. Physische Angriffe auf die Gerätehardware sind eine spezielle, modellabhängige Tätigkeit, die außerhalb des Umfangs dieses Kurses liegt.
Multisig, MPC und Fälle, in denen eine Wiederherstellung nicht möglich ist
Eine Multisig-Wallet benötigt M von N Schlüsseln, um Gelder auszugeben. Für ihre Wiederherstellung benötigt man außerdem den erweiterten öffentlichen Schlüssel jeder mitzeichnenden Person und die genaue Skriptkonfiguration, die üblicherweise als Output-Descriptor aufgezeichnet ist (die BIP-380-Familie). Ein Seed aus einer 2-von-3-Wallet zeigt allein keine ausgebbaren Gelder an; der Prüfer muss nach der Konfiguration oder einer Sicherungsdatei der Wallet und nach den übrigen mitzeichnenden Personen suchen. Bei einer MPC- oder Threshold-Wallet wird nie ein vollständiger Schlüssel gebildet: Anteile liegen auf dem Gerät der betreffenden Person sowie bei einem Anbieter oder einer anderen Partei. Ein einzelner Anteil genügt daher nicht, und die Wiederherstellung läuft normalerweise über das eigene Wiederherstellungsverfahren des Anbieters oder ein gegen ihn gerichtetes rechtliches Verfahren (siehe die IDFE-DA-Lektion Schlüsselverwaltungstechnologien).
| Situation | Typisches Ergebnis | Nächster Schritt |
|---|---|---|
| Seed verloren, Gerät gelöscht | Keine Kontrolle | Watch-only-Überwachung; Sperranträge stellen, sobald Gelder Dienste erreichen |
| Passphrase unbekannt | Nur die Wallet mit leerer Passphrase sichtbar | Nach der Passphrase suchen; die Einschränkung im Bericht angeben |
| Starkes Passwort für Wallet-Datei | Wiederherstellung kann zu lange dauern oder scheitern | Aufwand protokollieren; Adressen anhand etwaiger öffentlicher Daten überwachen |
| Multisig unterhalb des Schwellenwerts | Keine Kontrolle; vollständige Adresshistorie, falls alle xpubs gefunden werden | Weitere mitzeichnende Personen oder die Konfiguration ausfindig machen |
| Nur MPC-Anteil vorhanden | Keine Kontrolle | Über ein rechtliches Verfahren die Mitwirkung des Anbieters anfordern |
Wenn die Wiederherstellung scheitert, war die Arbeit nicht umsonst. Öffentliche Daten können weiterhin Adressen zuordnen, die Nachverfolgung unterstützen und einen Sperrantrag ermöglichen, sobald Gelder einen Dienst erreichen (siehe die Lektion Möglichkeiten des Einfrierens und der Beschlagnahme).
Prüfungsschwerpunkt: die vier Voraussetzungen für eine Wiederherstellung (Befugnis, Plan, isolierte Umgebung, Dokumentation); BIP-39-Parameter (128 bis 256 Bit, Prüfsumme von ENT/32 Bit, 2.048 Wörter, PBKDF2-HMAC-SHA512 mit 2.048 Iterationen und Salt „mnemonic“ plus Passphrase, 512-Bit-Seed); gehärtete Schlüssel nach BIP-32, Watch-only-xpubs und das Risiko durch die Kombination aus xpub und privatem Kindschlüssel; Ebenen des BIP-44-Pfads, Change-Werte, SLIP-0044-Coin-Typen, Gap-Limit von 20 und purposes 44, 49, 84 und 86 mit ihren Adresstypen; warum eine falsche Passphrase eine gültige leere Wallet ergibt und wie diese Einschränkung formuliert werden muss; Offline-Ableitung, Watch-only-Prüfungen anhand eigener Nodes und Formate, die nicht BIP-39 entsprechen; Passwortwiederherstellung allgemein und Wiederherstellung von Hardware-Wallets über den Seed; Anforderungen an Multisig und MPC sowie nächste Schritte, wenn die Wiederherstellung scheitert.