Die Entropie-Illusion: Der Fall Coldcard und die Physik des Vendor-Risikos Warum ein einzelner Integrationsfehler in der Zufallserzeugung ganze Produktlinien kompromittiert – und Air-Gap dagegen nichts ausrichtet.

Fangen wir bei der einzigen Stelle an, die in einer Hardware-Wallet wirklich zählt: dem Moment der Seed-Erzeugung. Alles, was danach kommt – Secure Element, Air-Gap, PIN, Anti-Phishing-Wörter, verschlüsselte Backups – schützt einen Schlüssel, der bereits existiert. Wenn dieser Schlüssel in dem Augenblick, in dem er entsteht, vorhersagbar ist, dann schützt die gesamte nachgelagerte Architektur nichts weiter als ein bereits bekanntes Geheimnis.

Genau hier lag der Fehler. Die Coldcard-Firmware ruft für die Erzeugung kryptografischen Zufalls die Funktion ngu.random auf, die den Hardware-Zufallsgenerator des STM32-Mikrocontrollers ansprechen soll – eine physikalische Rauschquelle. Durch einen Integrationsfehler griff dieser Pfad unter bestimmten Bedingungen jedoch nicht auf die Hardware zu, sondern fiel auf den in MicroPython eingebauten Yasmarang-Pseudozufallsgenerator zurück. Yasmarang ist ein solider Generator für Simulationen und Spiele. Er ist deterministisch. Für die Erzeugung von Schlüsselmaterial ist er ungeeignet, weil sein gesamter zukünftiger Ausgabestrom aus seinem inneren Zustand berechenbar ist.

Wichtig ist die Präzision an dieser Stelle, denn der Fehler wirkte über die Modellreihen hinweg nicht identisch. Bei der älteren Generation konnte der Fallback-Pfad Ausgaben erzeugen, die sich aus der eindeutigen Kennung des Mikrocontrollers und dem Zustand eines Timers ableiten ließen – ohne dass kryptografische Entropie eingespeist wurde. Bei den neueren Geräten wurde beim Start zwar Entropie aus dem Secure Element eingemischt, doch der Reseed war auf ein einziges 32-Bit-Wort begrenzt. Das klingt harmlos, ist es aber nicht: Ein 32-Bit-Suchraum umfasst rund 4,3 Milliarden Möglichkeiten. Für einen Menschen unvorstellbar viel. Für eine GPU eine Angelegenheit von Minuten.

Und genau so ist es passiert. Der beobachtete Angriff war kein gezielter Einbruch bei einzelnen Opfern, sondern ein vollautomatisierter Sweep: Der Angreifer generierte den erreichbaren Schlüsselraum durch, prüfte die resultierenden Adressen gegen den UTXO-Satz und räumte jede Adresse mit Guthaben in derselben Bewegung ab. Rund 594,48 BTC, etwa 38 Millionen USD, über circa 500 Wallets und rund 1.324 UTXOs – in einem Fenster von 25 bis 41 Minuten. Die Geschwindigkeit ist der eigentliche Beweis. Kein menschlicher Angreifer arbeitet so. Das war ein Skript, das eine Liste abarbeitete.

Zur Einordnung der Fehlerklasse, weil das in der Aufregung oft durcheinandergeht: Dies war kein Fehler beim Parsen von Transaktionen, kein Signatur-Bug und kein Versagen der kryptografischen Primitive im Secure Element. Es war ein Fehler in der Erzeugung des Schlüssels. Diese Unterscheidung ist deshalb entscheidend, weil sie bestimmt, was eine Reparatur überhaupt leisten kann.

Und hier kommt der Satz, der aus diesem Vorfall ein Lehrstück macht: Ein Firmware-Update repariert einen bereits erzeugten schwachen Seed nicht. Der Hersteller hat Notfall-Hotfixes veröffentlicht – 5.6.0 für Mk4 und Mk5, 1.5.0Q für Q – und diese Updates schließen die Lücke für alle künftig erzeugten Seeds. Was sie nicht können, ist rückwirkend Entropie in einen Schlüssel gießen, der bereits mit zu wenig davon entstanden ist. Wer betroffen ist, muss auf gepatchter Firmware einen neuen Seed erzeugen und sämtliche Bestände migrieren. Als Übergangsmaßnahme nennt der Hersteller eine BIP-39-Passphrase, ausdrücklich als Risikominderung und nicht als Reparatur, sowie die Erzeugung per Würfel – mindestens 50 unabhängige Würfe, im älteren Mk3-Ablauf sind 99 dokumentiert.

Dem Hersteller ist dabei zugutezuhalten, wie er reagiert hat: schnelle Offenlegung, technisch offener Hintergrundbericht, Hotfixes innerhalb von Tagen, und am 2. August die Vernichtung der verbliebenen verwundbaren Lagerbestände samt Auslieferungsstopp. Das ist mehr Transparenz, als die Branche üblicherweise liefert. Es ändert nur nichts an der strukturellen Lehre, um die es in diesem Dispatch geht.

Jetzt zu dem Teil, der unbequem ist, weil er an einer Überzeugung rüttelt, die in dieser Szene fast religiöse Züge trägt: der Vorstellung, dass ein bestimmtes Gerät oder eine bestimmte Firma sicher sei. Nicht sicherer, nicht besser geprüft – sondern sicher, als Eigenschaft, als Zustand. Diese Vorstellung ist der eigentliche Angriffsvektor, und der Entropie-Vorfall hat sie zerlegt.

Beginnen wir mit dem Air-Gap, dem meistzitierten Sicherheitsmerkmal überhaupt. Ein luftgetrenntes Gerät hat keine Netzwerkverbindung; Transaktionen werden per SD-Karte oder QR-Code übertragen. Das ist eine ausgezeichnete Eigenschaft und sie verhindert eine ganze Klasse von Angriffen. Aber schau genau hin, was sie verhindert: den Abfluss des Schlüssels über eine Verbindung. Sie schützt die Grenze, über die signiert wird.

Was ein Air-Gap konstruktionsbedingt nicht kann, ist die Qualität des Zufalls prüfen, aus dem der Schlüssel entstand. Wenn der Seed bereits bei seiner Erzeugung in einem berechenbaren Raum liegt, muss niemand mehr etwas exfiltrieren. Der Angreifer braucht keinen Zugang zu deinem Gerät. Er braucht nicht einmal zu wissen, dass du existierst. Er generiert den Suchraum, gleicht gegen die Blockchain ab und findet dich, weil deine Adresse öffentlich ist. Das Air-Gap hat perfekt funktioniert. Es war nur an der falschen Stelle.

Damit zur zweiten Illusion. Firmware ist kein Naturgesetz und kein geprüftes Artefakt höherer Ordnung. Firmware ist Code, von Menschen geschrieben, unter Zeitdruck, in gewachsenen Systemen, mit Abhängigkeiten zu Bibliotheken, die andere Menschen geschrieben haben. Der konkrete Fehler war nicht einmal ein kryptografischer Denkfehler – es war ein Integrationsfehler: Eine Funktion tat unter bestimmten Bedingungen etwas anderes als beabsichtigt. Das ist die häufigste Fehlerklasse der gesamten Softwaregeschichte, und keine Menge an Reputation immunisiert dagegen.

Beachte auch, dass es sich hier nicht um einen unbekannten Newcomer handelt. Es geht um einen der ältesten, technisch respektiertesten Hersteller im Bitcoin-Ökosystem, mit Open-Source-Firmware, öffentlicher Historie von Offenlegungen und einer Nutzerschaft, die überdurchschnittlich technisch versiert ist. Wenn ein Fehler dieser Tragweite dort über Jahre unentdeckt bleiben kann, dann ist die Schlussfolgerung nicht, dass man einen besseren Hersteller wählen muss. Die Schlussfolgerung ist, dass die Annahme selbst falsch war: Es gibt keinen Hersteller, dessen Fehlerfreiheit du voraussetzen darfst.

Und dann kommt die härteste Eigenschaft dieser Fehlerklasse: Die Qualität der Entropie eines bereits erzeugten Seeds lässt sich nachträglich nicht beweisen. Weder aus öffentlichen Daten noch aus dem Gerät selbst. Ein Seed, der aus gutem Zufall entstand, und einer, der aus schlechtem entstand, sehen identisch aus. Du kannst nicht nachsehen. Du kannst nur migrieren. Das ist der Grund, warum die Antwort auf diesen Vorfall nicht Wachsamkeit sein kann, sondern Struktur sein muss.

Kommen wir zur Konsequenz, und ich möchte sie nicht als Empfehlung formulieren, sondern als das, was sie ist: eine Aussage über Wahrscheinlichkeiten. Nimm eine klassische Zwei-von-Drei-Multi-Sig, bei der alle drei Signaturgeräte vom selben Hersteller stammen und dieselbe Firmware-Linie ausführen. Wie viele unabhängige Fehler braucht ein Angreifer, um an dein Geld zu kommen?

Die intuitive Antwort lautet zwei, weil zwei Signaturen nötig sind. Die richtige Antwort lautet einen. Ein Entropie-Fehler in der gemeinsamen Codebasis kompromittiert alle drei Schlüssel gleichzeitig, weil alle drei durch denselben defekten Pfad erzeugt wurden. Die Schwelle von zwei aus drei schützt gegen den Verlust einzelner Geräte. Gegen einen Fehler, der allen dreien gemeinsam ist, schützt sie überhaupt nicht. Die Ausfälle sind nicht unabhängig, und damit multiplizieren sich die Wahrscheinlichkeiten nicht – sie kollabieren auf eine einzige.

Genau das ist der Kern. Eine homogene Multi-Sig aus einer Hand fühlt sich robust an, weil sie mehrere Geräte umfasst. Mathematisch ist sie ein Single Point of Failure mit drei Gehäusen. Der Vorfall hat das nicht als These bewiesen, sondern als Ereignis: Ein Integrationsfehler in einer Funktion hat die Erzeugungshistorie einer ganzen Produktlinie über Jahre hinweg kompromittiert.

Die Gegenmaßnahme heißt Heterogenität. Verteile die Schlüssel deiner Multi-Sig über Geräte unterschiedlicher Hersteller mit unterschiedlichen Mikrocontroller-Architekturen, unterschiedlichen Secure-Element-Ansätzen, unterschiedlichen Codebasen und unabhängigen Build-Systemen. Etwa eine BitBox02 zusammen mit einer Coldcard und einem dritten Signierer aus einem weiteren Lager wie Jade oder Specter. Der Schutz entsteht dann nicht daraus, dass eines dieser Geräte fehlerfrei wäre – das setzt du bei keinem voraus – sondern daraus, dass ein Fehler in einer Codebasis nur einen deiner Schlüssel berührt. Und ein Schlüssel unter der Schwelle bewegt keine Coins.

Zur Ehrlichkeit gehört, die Kosten dieser Struktur zu benennen. Eine Multi-Vendor-Multi-Sig ist teurer, weil du mehrere Geräte kaufst. Sie ist komplexer, weil du mehrere Bedienlogiken beherrschen musst. Sie erfordert eine sauber dokumentierte und mindestens einmal geprobte Wiederherstellung, weil eine Konstruktion, die im Ernstfall niemand rekonstruieren kann, kein Sicherheitsgewinn ist, sondern eine garantierte Vernichtung. Und für kleine Beträge steht dieser Aufwand in keinem sinnvollen Verhältnis – eine gut verstandene Einzel-Wallet schlägt eine halb verstandene Multi-Sig jederzeit.

Der Übergang lohnt sich dort, wo der Verlust der Position eine echte Lebensveränderung bedeuten würde. Wo diese Schwelle liegt, weißt nur du. Aber wenn du sie überschritten hast, dann ist die Frage nicht mehr, ob dir die Komplexität gefällt. Dann ist die einzige verbleibende Frage, ob du bereit bist, dein gesamtes Vermögen gegen die Fehlerfreiheit einer einzigen Codebasis zu wetten – und der 30. Juli 2026 hat dir die Quote dieser Wette gezeigt.

Zum Schluss die operative Kurzfassung, falls du selbst betroffen sein könntest. Prüfe, auf welcher Firmware deine Seeds erzeugt wurden, nicht welche gerade installiert ist. Ein Update schließt die Lücke nur für zukünftige Schlüssel. Wenn dein Seed im betroffenen Bereich entstand, erzeuge auf gepatchter Firmware einen neuen – idealerweise per Würfel mit ausreichend unabhängigen Würfen – und migriere deine Bestände vollständig. Eine BIP-39-Passphrase kann das akute Risiko dämpfen, sie ersetzt die Migration aber nicht. Und wenn du danach ohnehin alles neu aufsetzt: Nutze die Gelegenheit und setze es heterogen auf.