In diesen Tagen ist das größte Sicherheitsereignis in der Krypto-Welt ein Zufallszahlfehler beim Hardware-Wallet Coldcard: etwa 5000 Wallets und 1755 Bitcoins wurden gestohlen, im Wert von über 110 Millionen US-Dollar.
Die meisten Berichte sagen nur: „Ein Defekt bei der Zufallszahlengenerierung ermöglicht es, die Seed-Phrase (Mnemonic) zurückzurechnen“. Aber als jemand, der die Prinzipien wirklich verstehen will, habe ich sehr viele technische Unterlagen geprüft (Block-offizielle Analyse, Galaxy Research On-Chain-Tracking, Community-PoC-Projekte) und die gesamte Angriffskette Schritt für Schritt zerlegt. Hier teile ich das mit allen Freunden, die genauso neugierig sind.
[Zuerst die wichtigste Schlussfolgerung]
Der Hacker hat weder die Seed-Phrase durch brutales Raten erraten noch den privaten Schlüssel durch brutales Raten—beides sind Räume von 2^256, physikalisch unmöglich. Er hat stattdessen den internen Zustand eines PRNG (Pseudozufallszahlengenerators) enumeriert, der die Seed-Phrase erzeugt. Dieser Zustandsraum ist nur 2^32 (etwa 4,2 Milliarden).
Warum? Weil die Seed-Wörter nicht „zufällig generierte Aufzeichnungen“ sind, sondern das Ergebnis einer deterministischen Funktion:
Seed-Wörter (24 Wörter) → PBKDF2 → Seed → BIP32 → Private Key → Adresse
Gegeben den Seed-Wörtern ist die Adresse eindeutig bestimmt. Daher kann man, sobald man die Quelle der Seed-Wörter hat (PRNG-Status), die gesamte Kette vollständig reproduzieren.
【Ursache der Lücke: ein Bug aus dem Jahr 2021 „prüft, ob ein Macro existiert“】
Coinkite hat im März 2021 einmal seine Firmware geändert – die Absicht war gut: Wechsel zu einer sichereren Kryptobibliothek. Aber beim Kompilieren ist etwas schiefgelaufen:
• In der Produktionskonfiguration ist das Makro für die Hardware-Zufallszahl MICROPY_HW_ENABLE_RNG auf 0 gesetzt (Coinkite glaubte, es habe seinen eigenen TRNG)
• Die Low-Level-Bibliothek prüft, ob „dieses Makro existiert“, nicht ob es „aktiviert ist“
• Ergebnis: Der Hardware-TRNG wurde aus der Kompilierung ausgeschlossen, und die Zufallsfunktionen fielen stillschweigend auf den in MicroPython eingebauten Yasmarang-Software-PRNG zurück
Am schlimmsten ist der initiale Zustand dieses PRNG:
• pad = Chip-UID ^ Timer – eine 32-Bit-Zahl (global universell, man muss keinerlei Geräteinformationen kennen)
• RTC-Register – stets 0 (die RTC wurde nie initialisiert)
• Aufrufanzahl vor dem Generieren des Wallets – beim ersten Start lässt sich das präzise ableiten (ca. 3103 Aufrufe)
Damit schrumpft der gesamte Suchraum auf 2^32 Zustände. Miete ein paar Cloud-GPUs, scanne einen oder zwei Tage – die Kosten liegen unter 1000 US-Dollar.
【Angriffsablauf: Das Scannen ist vorher abgeschlossen; 41 Minuten sind nur das „Einsammeln“】
Vollständiger Ablauf:
1. Lade alle Adressen mit Guthaben aus der gesamten Blockchain herunter, baue einen Bloom Filter (Speicherindex; Abgleich im Mikrosekundenbereich)
2. Zähle 2^32 PRNG-Zustände auf, reproduziere jeden einzeln „Zufallsbytes“
3. Für jeden Zustand: SHA-256 → 24-Wort-Seed-Wörter → PBKDF2 → BIP32 → abgeleitete Adresse (BIP44/49/84 Multi-Pfad)
4. Abgeleitete Adressen sofort mit dem Bloom Filter abgleichen – Treffer heißt: man besitzt den Private Key
5. 30. Juli, kurz vor Mitternacht: Signieren + Broadcast von 500+ Transaktionen, 41 Minuten zum Leerscan von 1196 Adressen, Bündelung von ca. 1082 BTC
Achtung: 41 Minuten sind die Ausführungszeit des „Einsammel“-Skripts (einheitliche 30 sat/vB Gebühr, Single-Output ohne Change, automatische Konsolidierung). Das Scannen war schon zuvor vor Stunden bis zu ein bis zwei Tagen abgeschlossen.
【Warum nicht warten, bis „alles“ gescannt ist, und dann einmalig einsammeln?】
Mein erster Gedanke war auch: Wenn die Lücke fünf Jahre lang existiert hat – warum hat man dann nicht vorher alle betroffenen Wallets gescannt, eine Liste erstellt und sie dann auf einmal komplett geleert? So hatte doch niemand Zeit zu reagieren.
Nach der Untersuchung stellte sich heraus, dass „„allumfassendes Scannen““ praktisch nicht existiert:
• Das Angriffssmodell wurde selbst iterativ nachgebessert (Anzahl der PRNG-Aufrufe beim ersten Start, Ableitungen über mehrere Pfade, unterschiedliche Gerätegenerationen). Jede Korrektur erfordert ein erneutes komplettes Scannen.
• Der Angreifer hat keine „Gottesaugen“-Sicht und kann niemals sicher bestätigen, dass das aktuelle Modell alle echten Wallets vollständig abdeckt
• Ein privater Schlüssel zu haben bedeutet nicht, dass die Assets gesperrt sind: Wer zuerst broadcastet, dessen Geld ist es. Warten lässt nur Nutzer abwandern und Mitbewerber losrennen
Daher lautet die tatsächliche Strategie: ein Slice scannen → sofort liquidieren → Modell korrigieren → erneut scannen. Die erste Welle holt 80%+ des Werts ab (ca. 1082 BTC); nach der Bekanntmachung wird in der zweiten Welle nur noch 76 BTC gescannt; die dritte Welle ergänzt auf 4585 Adressen. Der „Pool“ schrumpft mit der Zeit monoton.
【Zeitleiste: kein Einsperren für Eigengewinn – der Angriff kam vor der Bekanntmachung】
Am Anfang bezweifelte ich auch, ob es ein Insider im Unternehmen ist. Ich habe die Zeitleiste geprüft und herausgefunden, dass es andersherum ist:
• 30. Juli, kurz vor Mitternacht: erster Angriff (41 Minuten)
• 30. Juli tagsüber: Galaxy Research bemerkt Anomalien on-chain, Block findet die Root Cause via Reverse des Firmware-Images, Forbes berichtet
• 31. Juli (ca. 30 Stunden nach dem Angriff): erst dann veröffentlicht Coinkite eine Mitteilung
Der Angriff passiert zuerst, die Bekanntmachung kommt danach. Die Bekanntmachung ist keine Wissensquelle, sondern eine nachträgliche Offenlegung. Wer zuerst es entdeckt hat, und wie – dazu gibt es derzeit keine offiziellen Schlussfolgerungen.
【Wenn nicht „alles“ gescannt wurde, könnten dann nicht alle scannen?】
Ja. Das Wissen über die Lücke ist nicht monopolisiert: Firmware ist Open Source, der Suchraum umfasst nur 2^32, Adressen über die gesamte Blockchain sind öffentlich, und die PoC-Toolchain wurde veröffentlicht. Nach der Bekanntmachung kann jeder mit technischen Fähigkeiten die Scans reproduzieren.
Aber „jeder kann scannen“ bedeutet nicht „jeder kann verdienen“: Wenn mehrere denselben Wallet treffen, dann gewinnt grundsätzlich derjenige, der zuerst die Coins broadcastet. Das ist im Kern Tragik der Allmende – der Angriff kann profitabel sein, gerade weil nicht alle zur gleichen Zeit Bescheid wissen.
【Zum Schluss: die Lehren dieses Vorfalls für alle】
Die Lücke liegt nicht im BIP-39-Standard, sondern darin, dass die „Zufälligkeit“ selbst gar nicht zufällig ist. Prüfsumme, Wortliste und Adressableitungs-Pfade sind allesamt konform, aber die Entropiequelle hat nur ca. 40 Bit echter Unsicherheit – gleichbedeutend damit, dass das Schloss eines Tresors gegen einen Rohling-Schlüssel getauscht wurde, den jeder nachbauen kann.
Wenn du Coldcard verwendest und deine Seed-Wörter auf der betroffenen Firmware generiert wurden (Mk3 Firmware 4.0.1–4.1.9, Mk4/Mk5 unter 5.6.0, Q unter 1.5.0Q), dann bitte sofort: Firmware upgraden → neue Seed-Wörter komplett neu generieren → Test mit kleinen Beträgen → migriere alle Assets. Hinweis: Ein Firmware-Upgrade kann vorhandene Seeds nicht reparieren; du musst sie neu generieren.
*Der obige Inhalt basiert auf öffentlich zugänglichen Berichten und Sicherheitsforschung. Teile der Zuordnungen beruhen auf Schlussfolgerungen aus der Analyse der Blockchain und dienen nur zu Lernzwecken; dies stellt keine Anlageberatung dar.*