Coldcard und der stille RNG-Fallback: Wie aus 128 Bit rund 40 Bit wurden

Am 30. Juli 2026 veröffentlichte der Hersteller Coinkite eine Warnung für seine Hardware-Wallet Coldcard. Am selben Tag veröffentlichte das Bitcoin-Engineering-Team von Block seine eigene Analyse, mit einer ungewöhnlichen Begründung: Man publiziere früh, weil die aktive Ausnutzung bereits laufe. Der technische Kern des Vorfalls betrifft jede Organisation, die Software baut oder einkauft. Mit Bitcoin hat er wenig zu tun.

Wie konnten Angreifer die Seed Phrase erraten?

Erraten im Wortsinn war es nicht, eher nachgerechnet. Die Firmware sollte Schlüssel aus dem Hardware-Zufallsgenerator des STM32-Mikrocontrollers erzeugen. Stattdessen kam ein deterministischer Software-Generator zum Zug, der aus der Geräte-Kennung und Timer-Registern initialisiert wird. Wer diese Werte einschränken kann, kann den Zahlenstrom offline nachbilden und die zugehörigen Adressen mit der öffentlichen Blockchain vergleichen. Ein Treffer bestätigt den Schlüssel.

Der Fehler ist eine Zeile Prüflogik

Block beschreibt die Ursache präzise. Die Platinenkonfiguration setzt das Makro MICROPY_HW_ENABLE_RNG auf null, weil Coldcard einen eigenen Wrapper für den Hardware-Generator mitbringt. Die eingebundene Bibliothek libngu prüfte jedoch, ob das Makro definiert ist, statt ob es aktiviert ist. Beides ist wahr, sobald der Wert null lautet. Der Build lief durch, und die Funktion ngu.random band an den Fallback von MicroPython.

Dieser Fallback ist ein Yasmarang-Generator, initialisiert aus der Geräte-Kennung des Mikrocontrollers und aus Timer-Registern. Für Mk2 und Mk3 der Firmware-Version 4 kommt keine kryptografische Entropie hinzu. Bei bekannter Kennung, bekanntem Timer-Zustand und bekannter Aufrufhistorie ist die Erzeugung deterministisch.

Bei Mk4, Q und Mk5 ergänzt der Startvorgang Entropie aus den Sicherheitselementen. Sie wird jedoch gehasht, und davon bleiben vier Bytes übrig. Der anschließende Aufruf von reseed() ersetzt nur ein einziges 32-Bit-Wort im Zustand des Generators. Es existieren damit höchstens 2^32 sicher unterscheidbare Ausgabeströme.

Entscheidend ist die Firmware, die beim Erzeugen des Schlüssels lief, nicht die heute installierte und nicht das Herstellungsdatum.

Wie viel Entropie blieb übrig?

Coinkite schätzt den effektiven Suchraum unter den aktuellen Angriffsannahmen auf rund 40 Bit. Angestrebt waren 128 Bit. Galaxy Research beziffert die verbliebene Entropie auf rund 40 Bit bei Mk2 und Mk3 sowie rund 72 Bit bei Mk4, Q und Mk5.

Zwischen 128 und 40 Bit liegt kein gradueller Unterschied, sondern die Grenze der Durchsuchbarkeit. Der eine Suchraum überdauert das Universum, der andere ein Wochenende. Eingetreten ist der zweite Fall. Galaxy Research verfolgte bis zum 4. August 2026 Verluste von nahe 130 Millionen US-Dollar und schätzt mindestens 15 unabhängig voneinander agierende Angreifer. Der Verlauf lief in Wellen, rund 1.082 Bitcoin bis zum 1. August, danach rund 284 Bitcoin in zwei weiteren Wellen. Diese Zahlen sind ein Zwischenstand und bewegen sich weiter.

Was lässt sich aus dem Fall für eigene Builds lernen?

Ein Fallback, der still greift, ist gefährlicher als ein fehlender Wert. Der Build hätte scheitern müssen. Stattdessen lief er durch und lieferte funktionierende Geräte, die fünf Jahre lang schwache Schlüssel erzeugten.

Der Hotfix dreht das um. Er schließt das Fallback-Objekt von MicroPython ausdrücklich aus und prüft zur Build-Zeit, ob das erwartete Symbol vorhanden ist. Fehlt es, bricht der Build ab.

Dieselbe Frage lässt sich auf jede eigene Lieferkette anwenden. Welche kryptografischen Bausteine haben einen Rückfallpfad? Wird dieser Pfad im Build oder erst zur Laufzeit ausgewählt? Und wird er still gewählt oder mit einer Fehlermeldung?

Für eingekaufte Firmware kommt die Frage dazu, ob sich die Qualität einer Entropiequelle von außen überhaupt nachweisen lässt. Sie lässt sich, und der Weg ist beschrieben. NIST SP 800-90B legt die Prüfung fest: ein Prüflabor mit NVLAP-Akkreditierung, mindestens eine Million aufeinanderfolgende Rohwerte aus der Rauschquelle, dazu Restart-Tests über 1.000 Neustarts. Wer eine Zahl aus dem Datenblatt übernimmt, ohne nach einer solchen Prüfung zu fragen, übernimmt eine Behauptung.

Am Standard für die Wiederherstellungsphrase liegt es dabei nicht. BIP-39 legt die zulässige Entropielänge fest, 128 bis 256 Bit in Schritten von 32, und leitet daraus die Wortzahl ab. Woher diese Bits kommen, regelt der Standard nicht. In dieser Lücke ist der Fehler entstanden. Prüfungen dieser Art sind Gegenstand eines Penetrationstests und der Offensive Security, die Grundlagen der Verfahren stehen im Eintrag zur Kryptographie.

Einordnung

Zwei Details verdienen Beachtung. Erstens repariert ein Firmware-Update einen bereits erzeugten Schlüssel nicht. Wer betroffen ist, muss einen neuen Schlüssel erzeugen und die Mittel umziehen. Zweitens gelten Schlüssel, bei deren Erzeugung mindestens 50 unabhängige, private Würfelwürfe ergänzt wurden, für dieses Problem als nicht betroffen. Die zusätzliche manuelle Entropiequelle, die vielen als übertriebene Vorsicht galt, war der einzige Schutz gegen einen Fehler tief im Build.

Coinkite gibt außerdem an, dass TAPSIGNER, OPENDIME und SATSCARD nicht betroffen sind, weil sie eine andere Codebasis nutzen. Dass der Fehler überhaupt gefunden wurde, ist der Arbeit externer Forschender und der Reaktion von Nutzern zu verdanken. Wie Organisationen solche Hinweise erreichbar machen, beschreibt der Beitrag zum Aufbau eines Bug-Bounty-Programms.