Coldcards Entropiefehler und fast 90 Millionen US-Dollar Verlust: Eine ernste Warnung vor vermeintlich „absolut sicherer“ Hardware

Am 30. Juli erschien auf der Bitcoin-Blockchain eine Reihe ungewöhnlicher Transfers.

Die erste auffällige Sweep-Welle dauerte nur 41 Minuten. In diesem Zeitraum wurden 1.082,65 BTC von 1.196 Adressen bewegt. Später identifizierte Galaxy Research zwei weitere Wellen mutmaßlich zusammenhängender Aktivitäten. Bis zum 2. August belief sich die Gesamtsumme der drei Wellen auf rund 1.367,05 BTC, zum damaligen Kurs knapp 88,6 Millionen US-Dollar, verteilt auf 4.585 Adressen.

Diese Zahlen lassen sich mit öffentlichen Updates von Galaxy Research, dem On-Chain-Tracking von CoinDesk und der technischen Aufarbeitung von The Hacker News abgleichen.

Die Wallets hatten ein gemeinsames Merkmal: Ihre Seeds sollen mit Coldcard-Hardware-Wallets von Coinkite erzeugt worden sein.

Viele der betroffenen Geräte waren jahrelang offline, und die Recovery-Phrasen waren nie in eine Cloud hochgeladen worden. Das Problem entstand wesentlich früher. Bei der Erstellung der Wallets nutzten die Geräte nicht wie vorgesehen den echten Hardware-Zufallszahlengenerator. Ein Angreifer musste die Recovery-Phrase nicht stehlen. Es genügte, die möglichen generierten Phrasen zu berechnen und anschließend auf der Blockchain nach den dazugehörigen Adressen zu suchen.

Genau diese Art von Fehler gehört zu den schwersten Problemen bei Hardware-Wallets. Ein Gerät kann jahrelang in einer Schublade liegen, und der private Schlüssel kann das Gerät tatsächlich nie verlassen haben. Wenn der Schlüssel aber bereits bei seiner Erzeugung nicht ausreichend zufällig war, helfen spätere Schutzmechanismen wie Air-Gap, Secure Element oder Manipulationsschutz nicht mehr.

Quellenlage und Grenzen der Schlussfolgerungen

Primärquellen zur Überprüfung: COLDCARD Mk3 Seed Generation Warning; Version History; BIP-0039: Mnemonic code for generating deterministic keys.

Die überprüfbaren Aussagen dieses Artikels zum Low-Entropy-Fehler von COLDCARD, zu betroffener Firmware und zur sicheren Migration beruhen auf den genannten offiziellen oder regulatorischen Quellen. Tatsächlicher Service-Status, Gebühren, Teilnahmevoraussetzungen und regionale Verfügbarkeit sollten zum Zeitpunkt der Nutzung auf den aktuellen Seiten des Herausgebers oder der Plattform geprüft werden.

Eine Migration von Vermögenswerten muss auf einem vertrauenswürdigen Gerät erfolgen, wobei die Zieladresse direkt überprüft werden sollte. Bei Verlustangaben ist zwischen offizieller Bestätigung und Analysen Dritter zu unterscheiden. Aussagen über Nutzererfahrungen, Erfolgsquoten, Gebührenvergleiche oder Trends, die nicht direkt in den oben genannten Primärquellen veröffentlicht wurden, sind Analysen oder Schlussfolgerungen und wurden für Einzelfälle nicht offiziell von den beteiligten Stellen bestätigt.

Was bislang bestätigt ist

Coinkite, der Entwickler von Coldcard, hat eingeräumt, dass ein Teil der zwischen 2021 und Juli 2026 veröffentlichten Firmware von einem Low-Entropy-Problem betroffen war. Das Unternehmen fordert betroffene Nutzer auf, neue Seeds zu erzeugen und ihre Gelder auf neue Adressen zu übertragen. Zu den im Sicherheitshinweis von Coinkite genannten korrigierten Versionen gehören Mk2/Mk3 4.2.0, Mk4/Mk5 Standard 5.6.0, Q Standard 1.5.0Q sowie die Edge-Versionen 6.6.0X und 6.6.0QX.

Auch das Bitcoin-Engineering- und Sicherheitsteam von Block führte eine unabhängige Analyse durch. Der technische Bericht lokalisierte das Problem in der Aufrufkette der Zufallszahlenerzeugung. Beim Erzeugen eines Wallet-Seeds sollte eigentlich der Hardware-Zufallszahlengenerator des STM32-Chips genutzt werden. Tatsächlich landete der Aufruf bei Yasmarang, einem in MicroPython integrierten Software-Pseudozufallszahlengenerator.

Sowohl der Firmware-Fehler als auch die On-Chain-Sweeps sind real. Die direkte Zuordnung zwischen beiden ist jedoch noch nicht vollständig geschlossen. Galaxy identifizierte mutmaßlich zusammengehörige Transaktionen anhand von Gebührenmustern, Wechselgeldverhalten, Batch-Strukturen und Ableitungspfaden. Bislang gibt es keinen öffentlichen Bericht, der den vollständigen Prozess zeigt, bei dem der schwache Seed eines konkreten Opfers rekonstruiert und anschließend eindeutig einer geleerten Adresse zugeordnet wird.

Präziser formuliert lautet der aktuelle Stand daher: Forscher fanden einen Coldcard-Firmwarefehler, der die Erzeugung privater Schlüssel auf einen ausreichend kleinen Raum reduziert, um ihn offline zu durchsuchen. Gleichzeitig wurden mehrere hochgradig verdächtige Sweep-Wellen beobachtet, die zeitlich und im Verhalten stark dazu passen. Zu behaupten, sämtliche 1.367,05 BTC seien „nachweislich über diese Schwachstelle gestohlen“ worden, geht über die derzeitige Beweislage hinaus.

Der Bug steckte in der Aufrufkette für Zufallszahlen

Coldcard verfügte ursprünglich über Code, der direkt den Hardware-RNG des STM32 auslas. Die entsprechende Python-Schnittstelle lautete ckcc.rng_bytes().

Im Jahr 2021 änderte Coldcard bei der Migration von Elliptic-Curve-Code und der Einführung von libNgU die Zufallsschnittstelle für neue Wallets auf ngu.random.bytes(). Damit gelangte das Problem in die Firmware.

In der Produktionskonfiguration war MICROPY_HW_ENABLE_RNG auf 0 definiert. Die Entwickler taten dies, weil Coldcard bereits einen eigenen Wrapper für den Hardware-RNG hatte und daher keine zusätzliche MicroPython-Implementierung benötigte. Die Prüfung in libNgU verwendete jedoch #ifndef. Dabei wurde nur geprüft, ob das Makro definiert war, nicht ob sein Wert ungleich null war.

Der Code ließ sich kompilieren und das Gerät startete normal. Beim finalen Linken zeigte rng_get() jedoch nicht auf die von Coldcard vorgesehene Hardware-Implementierung, sondern auf MicroPythons Yasmarang-Fallback. Der relevante Code und die zugehörige Commit-Historie sind im Coldcard-Firmware-Repository nachvollziehbar; Blocks Bericht rekonstruiert den vollständigen Aufrufpfad im Detail.

Yasmarang erzeugt Zahlen, die zufällig aussehen können, ist aber kein kryptografisch sicherer Zufallszahlengenerator für Wallet-Masterkeys. Sein Anfangszustand basiert hauptsächlich auf den unteren 32 Bit der Chip-UID, dem SysTick-Timer und den RTC-Zeitregistern.

Die Chip-UID ist lediglich eine Gerätekennung und kein Geheimnis. Auch der Timerzustand ist kein physikalisches Rauschen, und die Eingaben können miteinander korreliert sein. Nach der Initialisierung nimmt der Generator keine zusätzliche Entropie mehr auf. Wenn sich Gerätezustand, Startzeit und Anzahl vorheriger Aufrufe auf einen ausreichend engen Bereich begrenzen lassen, können die späteren Ausgaben auf einem anderen Rechner reproduziert werden.

Die Firmware hasht das Ergebnis später zwar noch, doch das löst das Grundproblem nicht. Zehntausend mögliche Eingaben bleiben nach SHA-256 weiterhin nur zehntausend mögliche Ausgaben. Das Ergebnis sieht gleichmäßiger verteilt aus, aber der Suchraum wird dadurch nicht größer. Die BIP-39-Prüfsumme kontrolliert lediglich das Format; sie erhöht nicht die tatsächliche Entropie der Recovery-Phrase.

40 Bit versus 72 Bit: Wie groß ist der Unterschied?

Die BIP-39-Spezifikation verlangt eine anfängliche Entropie zwischen 128 und 256 Bit. Eine übliche Recovery-Phrase mit 12 Wörtern entspricht 128 Bit, eine mit 24 Wörtern 256 Bit.

Coinkites vorläufige Einschätzung für die alte Firmware liegt bei einem effektiven Suchraum von etwa 40 Bit für Mk2/Mk3 und rund 72 Bit für Mk4/Mk5/Q.

Ein 40-Bit-Raum umfasst ungefähr 1,1 Billionen Kandidaten. Das klingt zunächst viel, liegt aber in einer völlig anderen Größenordnung als 128 Bit. Die beiden Kandidatenräume unterscheiden sich um etwa 2^88. Kann ein Angreifer den Bereich zusätzlich anhand des Gerätemodells, der Chip-UID, des Boot-Zeitpunkts oder üblicher Ableitungspfade einschränken, ist Offline-Enumeration kein rein theoretisches Problem mehr.

Spätere Modelle enthielten eine zusätzliche Verarbeitungsschicht. Beim Start mischt das Mk4 einen vom Secure Element bereitgestellten Zufallswert ein. Nach dem Hashing behält der Code jedoch nur 4 Byte und ersetzt mit diesen 32 Bit ein Zustandswort von Yasmarang. Block kommt deshalb zu dem Schluss, dass das Secure Element bei bekanntem restlichem Zustand und bekanntem Aufrufverlauf höchstens 2^32 unterschiedliche Ausgabeströme unterscheiden kann. Selbst wenn für unbekannte Timerzustände eine großzügige Obergrenze angesetzt wird, bleibt der Kandidatenraum unter 2^73.3.

Es wäre irreführend, daraus schlicht zu machen: „Mk4 bietet 72 Bit Sicherheit.“ Block weist selbst darauf hin, dass 2^73.3 lediglich eine großzügige Obergrenze für den Kandidatenraum ist und nicht 73 Bit kryptografischer Sicherheit im üblichen Sinn. Die tatsächlichen Angriffskosten hängen von UID-Informationen, Startzeit, Anzahl vorheriger Aufrufe, Adressableitung und Verifikationsgeschwindigkeit ab. Ein vollständiger öffentlicher Cracking-Benchmark liegt derzeit nicht vor.

Sicher sagen lässt sich nur: Die späteren Modelle stehen besser da als Mk2/Mk3, erreichen aber weiterhin nicht Coldcards ursprünglich vorgesehenes Ziel von 128 Bit. Deshalb fordert Coinkite auch diese Nutzer auf, ihre Seeds zu ersetzen.

Betroffen ist der Seed, nicht nur das Gerät

Der häufigste Fehler bei der Prüfung besteht darin, nur auf die aktuell installierte Firmware zu schauen.

Entscheidend ist, welche Firmware-Version die Recovery-Phrase ursprünglich erzeugt hat. Ein Mk3 heute auf 4.2.0 zu aktualisieren, macht eine vor fünf Jahren erzeugte Phrase nicht nachträglich zufälliger. Auch ein Import derselben Phrase in Ledger, Trezor oder eine Software-Wallet hilft nicht. Die Schwäche steckt bereits im Seed selbst.

Dabei ist noch ein Versionsdetail wichtig. Standard und Edge sind separate Release-Zweige. Eine ältere Edge-Version ist nicht automatisch sicher, nur weil ihre Versionsnummer größer als 5.6.0 ist. Der genaue Umfang sollte anhand der neuesten Coinkite-Mitteilung und der offiziellen Versionshistorie geprüft werden.

Coinkite erklärt, dass TAPSIGNER, OPENDIME und SATSCARD andere Codebasen nutzen und von diesem Fehler nicht betroffen sind.

Wenn die Wallet nie online war: Wie konnte der Angreifer die Coins bewegen?

Eine Hardware-Wallet speichert private Schlüssel und signiert Transaktionen. Bei korrekter Zufallserzeugung ist es tatsächlich äußerst schwierig, einen privaten Schlüssel aus der Ferne zu erlangen.

Dieser Angriffsweg umging das Gerät selbst. Ein Angreifer konnte auf seinem eigenen Computer mögliche Zufallszustände durchprobieren, daraus Kandidaten für Recovery-Phrasen erzeugen, die entsprechenden Extended Public Keys und üblichen Adressen ableiten und anschließend auf der öffentlichen Bitcoin-Blockchain prüfen, ob diese Adressen Guthaben hielten.

Wurde eine Übereinstimmung gefunden, war der vom Angreifer berechnete private Schlüssel identisch mit dem Schlüssel in der Wallet. Er konnte die Transaktion selbst signieren und senden, ohne das Originalgerät anzuschließen und ohne dessen PIN zu kennen. Die Aussage, ein Gerät sei „nie online gewesen“, schließt diese Angriffsart daher nicht aus, denn die Suche nach Kandidatenschlüsseln kann vollständig offline stattfinden.

Auch Coins, die jahrelang nicht bewegt wurden, sind dadurch nicht automatisch sicher. Das Risiko eines schwachen Seeds läuft nicht von selbst ab. Wenn Forschung öffentlich wird und Rechenkosten sinken, kann eine früher unrentable Suche wirtschaftlich attraktiv werden. Gerade lange ruhende Adressen mit hohen Guthaben können zu bevorzugten Zielen werden.

Wie sind die 4.585 On-Chain-Adressen zu verstehen?

Galaxy Research veröffentlichte bis zum 2. August folgende zentrale Zahlen:

Die ersten beiden Wellen nutzten ähnliche feste Gebührenmuster und Batch-Verfahren. Sie könnten vom selben Betreiber stammen oder lediglich dasselbe Tooling genutzt haben. In der dritten Welle änderten sich Konsolidierungsadressen und Output-Struktur. Galaxy schrieb nicht alle drei Wellen demselben Angreifer zu, weil die On-Chain-Daten dafür nicht ausreichen.

Auch die Anzahl der Adressen lässt sich nicht direkt in eine Zahl von Opfern umrechnen. Eine Person kann viele Adressen kontrollieren, und aus einer einzigen Recovery-Phrase lassen sich zahlreiche Empfangsadressen ableiten. Umgekehrt könnten Forscher weitere Gelder derselben Wallet übersehen haben, wenn nur Standard-Ableitungspfade untersucht wurden.

On-Chain-Attribution hat zudem eine grundsätzliche Einschränkung: Wenn der Eigentümer einer Wallet seine Gelder freiwillig migriert, kann das Transaktionsmuster einem Angreifer-Sweep ähneln. Galaxy verwendet ein Modell aus Transaktionsfingerprints, Ableitungspfaden und Berichten von Opfern. Auf der Blockchain selbst steht kein direkt lesbares Etikett „Diebstahl“. Deshalb ist es präziser, die 1.367,05 BTC als „beobachtetes, mutmaßlich zusammenhängendes Volumen“ zu bezeichnen.

Der Code war fünf Jahre lang öffentlich. Warum bemerkte es niemand?

Die Coldcard-Firmware war die ganze Zeit öffentlich, und die Hardware-Zufallszahlenerzeugung war tatsächlich implementiert. Frühere Reviews konnten den TRNG-Code sehen, prüften aber nicht, ob der Wallet-Erstellungsweg am Ende wirklich diese Implementierung nutzte.

Der Bug erstreckte sich über mehrere Schichten. Die Wallet-Erzeugungsfunktion wechselte die Schnittstelle, libNgUs Prüfung der Compile-Makros war unvollständig und MicroPython stellte eine Software-Fallback-Implementierung mit derselben funktionalen Rolle bereit. Jede einzelne Komponente wirkte für sich genommen unauffällig. Die Software kompilierte, das Gerät funktionierte und die Ausgaben wiederholten sich nicht offensichtlich. Sichtbar wird das Problem erst, wenn Symbolauflösung und finaler Aufrufpfad im tatsächlichen Build nachverfolgt werden.

Auch klassische Zufallstests hätten die Schwachstelle möglicherweise nicht aufgedeckt. Ein nicht kryptografischer PRNG kann gleichmäßig verteilte Werte erzeugen, ohne dass benachbarte Ausgaben offensichtlich wiederholt werden. Das Problem ist nicht, dass die Zahlen „nicht zufällig aussehen“, sondern dass der interne Zustand berechenbar ist.

Coinkites Hotfix ergänzte eine Build-Time-Prüfung für RNG-Symbole. Gelangt künftig erneut die falsche Implementierung in die Firmware, bricht der Build ab. Auch die offizielle technische Nachanalyse räumt ein, dass frühere Prüfungen zwar das Vorhandensein des erwarteten TRNG bestätigten, aber nicht verifizierten, auf welche Implementierung der Wallet-Erzeugungspfad tatsächlich aufgelöst wurde.

Open Source bleibt trotzdem wertvoll. Dass das Problem so schnell lokalisiert und historische Commits geprüft werden konnten, lag gerade daran, dass der Code öffentlich war. Aber „jeder kann es auditieren“ bedeutet nicht, dass „jemand bereits jeden sicherheitskritischen Pfad vollständig auditiert hat“. Bei Hardware-Wallets sind reproduzierbare Builds nur ein Ausgangspunkt. Auch die Aufrufketten rund um Seed-Erzeugung, Signaturen und Backups müssen Ende-zu-Ende geprüft werden.

Multisig kann das Risiko senken – aber nur bei unabhängig erzeugten Schlüsseln

In einer 2-von-3-Multisig-Konfiguration reicht ein rekonstruierter schwacher privater Schlüssel nicht aus, um Gelder zu bewegen. Der Angreifer benötigt weiterhin einen zweiten Signaturschlüssel. Werden die übrigen Schlüssel von unterschiedlichen Herstellern, mit unterschiedlichen Codebasen und unabhängigen Zufallsquellen erzeugt, kann Multisig vor einem systemischen Fehler eines einzelnen Wallet-Anbieters schützen.

Drei betroffene Coldcards zu einem Multisig-Setup zusammenzuschalten, löst das Problem aber nicht automatisch. Kann der Angreifer genügend schwache Schlüssel rekonstruieren, um die Signaturschwelle zu erreichen, bleiben die Gelder verwundbar. Blocks Bericht formuliert das klar: Innerhalb der Signaturschwelle müssen ausreichend viele sichere Geräte vorhanden sein.

Für normale Nutzer gilt außerdem: Mehr Komplexität ist nicht automatisch besser. Fehlende Deskriptoren, Ableitungspfade, Geräte-Fingerprints oder Backups können eine Wiederherstellung unmöglich machen. Wer nie einen vollständigen Restore-Test durchgeführt hat und lediglich mehrere Geräte nach einer Anleitung kombiniert, kann ein ebenso großes oder sogar größeres Betriebsrisiko haben als mit einer Single-Signature-Wallet.

So sollte die Migration jetzt erfolgen

Wenn dein Seed mit einer der oben aufgeführten Firmware-Versionen erzeugt wurde und du damals weder ausreichend unabhängige Würfelentropie hinzugefügt noch eine starke, einzigartige BIP-39-Passphrase verwendet hast, solltest du den Seed als gefährdet betrachten.

Lade zunächst von der offiziellen Coldcard-Downloadseite die korrigierte Firmware für dein exaktes Modell und den richtigen Release-Zweig herunter und überprüfe die Versionsnummer auf dem Display des Geräts. Erzeuge anschließend eine vollständig neue Recovery-Phrase und notiere und überprüfe Backup, Wallet-Fingerprint und Empfangsadresse sorgfältig.

Übertrage nicht sofort das gesamte Guthaben. Sende zunächst einen kleinen Testbetrag, bestätige den Eingang in der neuen Wallet, überprüfe Fingerprint und Adresse erneut und transferiere erst dann den Rest. Bewahre das alte Backup auf, bis der vollständige Betrag eingegangen ist. Nach Abschluss der Migration sollten die alten Adressen nicht mehr für neue Einzahlungen verwendet werden.

Coinkite nennt eine Ausnahme für Würfelentropie. Wenn du bei der Seed-Erstellung über Coldcards Funktion „Add Dice Rolls“ mindestens 50 faire, unabhängige und vollständig private Würfe mit einem sechsseitigen Würfel eingegeben hast, haben die Würfel selbst mindestens 128 Bit Entropie beigetragen; ab 99 Würfen sind es ungefähr 256 Bit. Wenn du dich nicht mehr an die Anzahl erinnerst oder die Ergebnisse fotografiert beziehungsweise auf einem vernetzten Gerät gespeichert wurden, solltest du dich nicht auf diese Ausnahme verlassen.

Eine BIP-39-Passphrase kann ebenfalls ein zusätzliches unabhängiges Geheimnis darstellen. Kurze Wörter, Zitate, häufige Abwandlungen und wiederverwendete Passwörter können jedoch weiterhin erraten werden. Die Geräte-PIN ist keine BIP-39-Passphrase. Selbst bei einer starken Passphrase empfiehlt Coinkite weiterhin einen Seed-Wechsel, weil die ursprüngliche Recovery-Phrase selbst nicht repariert wurde.

Während der Migration ist besondere Vorsicht vor gefälschten Warnmeldungen, falschem Support und angeblichen „Seed-Sicherheitsprüfungen“ geboten. Wer dich auffordert, deine Recovery-Phrase auf einer Website, in einem Chatfenster oder über Fernwartungssoftware einzugeben, ist nicht vertrauenswürdig.

Welche Lehren aus dem Vorfall folgen

Coldcard Air-Gap, reproduzierbare Builds und physische Schutzmechanismen bleiben sinnvoll. Sie können nur keinen privaten Schlüssel schützen, der bereits bei seiner Erzeugung schwach war. Eine Hardware-Wallet ist kein einzelner Tresor, sondern ein vollständiger Prozess: Zufallszahlenerzeugung, Firmware-Build, Speicherung privater Schlüssel, Signatur, Backup und Wiederherstellung. Ein Fehler in nur einer dieser Stufen kann das gesamte System gefährden.

Nutzer können nicht jede Codezeile einer Hardware-Wallet selbst prüfen, aber sie können Single Points of Failure reduzieren. Große Vermögenswerte sollten nicht dauerhaft von nur einem Hersteller und nur einer Seed-Erzeugungsmethode abhängen. Es ist sinnvoll zu dokumentieren, welches Gerät einen Seed erzeugt hat, zusammen mit Firmware-Version und Datum, regelmäßig Herstellerwarnungen zu prüfen und bei seedbezogenen Schwachstellen nicht davon auszugehen, dass ein Firmware-Update allein das Problem löst.

Dieses Mal müssen tatsächlich die Schlüssel ersetzt werden. Solange der alte Seed noch Gelder kontrolliert, bleibt das Risiko bestehen.

Referenzen

Offizielle Unternehmens- und Firmware-Quellen

• Offizielle Coldcard-Website

• Offizielle Coinkite-Website

• Offizielle Sicherheitswarnung von Coldcard / Coinkite

• Offizielle technische Nachanalyse von Coinkite

• Offizieller Coldcard-Firmware-Quellcode und Sicherheitshinweise

• Offizielle Versionshistorie der Coldcard-Firmware

• Offizielle Coldcard-Firmware-Downloadseite

Unabhängige technische Quellen und Standards

• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

• Bitcoin BIPs: BIP-39-Spezifikation

• Coldcard-Commit von 2021 zur Einführung von libNgU

On-Chain-Tracking und journalistische Verifikation

• Galaxy Research: Tracking der dritten Welle und Gesamtdaten aller drei Wellen

• CoinDesk: drei Sweep-Wellen mit insgesamt 4.585 Adressen und rund 1.367 BTC

• The Hacker News: Schwachstellenpfad, betroffene Versionen und aktualisierte Galaxy-Daten