COLDCARD-Hack 2026: Wie ein #ifndef 1.367 BTC stehlbar machte

1. Der 25-Minuten-Überfall: Was am 30. Juli geschah

Ein Hardware-Wallet gilt als der letzte sichere Ort für Bitcoin-Schlüssel: ein Gerät, das private Keys niemals verlässt, keine Netzwerkverbindung hat und bei dem selbst ein kompromittierter Computer nur Transaktionen zum Unterschreiben vorlegen kann. Am frühen Morgen des 30. Juli 2026 wurde diese Annahme auf spektakuläre Weise widerlegt — nicht durch einen Einbruch in die Geräte, sondern durch Mathematik, die von außen angesetzt wurde.

Zwischen 01:31 und 01:56 UTC transferierte ein Angreifer 594,5 BTC aus etwa 500 Einzel-Signatur-Wallets (1.324 UTXOs) auf eigene Adressen — innerhalb von 25 Minuten, wie die Community-Analyse „ColdCard Entropy Incident" dokumentiert. Galaxy Research, die Research-Abteilung von Galaxy Digital, verfolgte die vollständige erste Welle: 1.196 Adressen in 41 Minuten, insgesamt 1.082,65 BTC im Wert von rund 70,2 Mio. USD. Die Beute wurde anschließend konsolidiert: 562 BTC flossen auf eine Sammeladresse (einsehbar auf mempool.space).

Die Angreifer arbeiteten mit auffälliger Gebührenpolitik: 30 sat/vB, keine Change-Ausgaben („no-change sweeps"), standardisierte P2WPKH-Ziele. Galaxy Research stellte fest, dass es in den vorangegangenen 30 Tagen keine einzige andere Bitcoin-Transaktion mit exakt dieser Signatur gab — das Muster identifiziert den Operator, nicht zwangsläufig den Diebstahl, warnte das Unternehmen. Wer einen eigenen Coin-Sweep durchführt, hinterlässt dieselbe Spur.

Drei Wellen, drei Muster

Der Vorfall war mit der ersten Welle nicht vorbei. Galaxy Research identifizierte bis zum 1. August zwei weitere Wellen und erhöhte die Schätzung auf 1.367,05 BTC (ca. 88,6 Mio. USD) aus 4.585 Adressen — berichtet von The Crypto Times. Bemerkenswert: Die Welle 3 unterscheidet sich strukturell von den ersten beiden.

Die Wellen 1 und 2 teilen sich Collector-Adressen, identische P2WPKH-Zieladressen und ähnliche Ableitungspfade. Welle 3 nutzt dagegen individuelle Zieladressen, P2WSH-Outputs und bündelt mehrere Opfer pro Transaktion — Galaxy zufolge ein Hinweis darauf, dass der ursprüngliche Angreifer seine Werkzeuge gewechselt hat oder ein zweiter Akteur dieselbe Schwachstelle ausbeutet. Die meisten betroffenen Wallets hielten weniger als 1 BTC; der Großteil des Werts stammte jedoch aus wenigen größeren Wallets. Konsistent mit einem Befund von Chainalysis, wonach der Angreifer zuerst die größten Wallets anging.

Ungewöhnlich: Alle kontrollierten Gelder blieben bis Redaktionsschluss unausgegeben. Galaxy Research meldete rund 600 mutmaßlich angreiferkontrollierte Adressen an Bundesermittler, Compliance-Unternehmen und Cybersecurity-Firmen — und betonte, dass die Zuordnung auf On-Chain-Heuristiken beruht, nicht auf einer per-Address-Rekonstruktion der Seeds.

2. Die Betroffenen waren die Sichersten von allen

Das Besondere an diesem Fall: Die Opfer sind exakt jene Nutzer, die am meisten für Sicherheit getan haben. COLDCARD gilt unter Bitcoinern als das Wallet für Paranoiker — Open Source, airgapped, mit Dice-Rolls, Passphrase und Multi-Sig-Optionen. Genau diese Zielgruppe wurde getroffen.

1,6 Millionen Dollar in Bitcoin wurden am 29. Juli aus meinem Konto geleert. Meine Bitcoins lagen in Cold Storage. Meine Keys lagen auf einer COLDCARD in einem Schließfach, das nie mit dem Internet verbunden war.

„I did everything right" — dieser Satz zirkulierte nach Goodmans Post auf X quer durch die Bitcoin-Community und traf den Nerv. Auch in r/Bitcoin (via Bitcoin Magazine zitiert) meldeten sich Betroffene, deren Bitcoins seit 2021 unberührt lagen und plötzlich weg waren. Kevin Loaec, CEO des Bitcoin-Sicherheitsunternehmens Wizardsardine, formulierte es drastisch: „Every single mnemonic generated via a Coldcard since 2021 will be public in the next few days." Der Bitcoin-Engineer James O'Beirne (jamesob) bezeichnete die Ursache öffentlich als „faulty entropy in wallet generation".

Die Ironie der Lage: Hardware-Wallets verschieben das Risiko von der Laufzeitumgebung (Malware, Phishing, physischer Diebstahl) auf die Qualität der Seed-Erzeugung. Wenn genau dieser Baustein bricht, ist jedes andere Sicherheitsmerkmal wertlos — die Verschlüsselung des Chips, der PIN-Schutz, die Airgap, das Schließfach.

3. Grundlagen: Warum Zufall über Geld entscheidet

Um den Vorfall zu verstehen, muss man verstehen, wofür „Zufall" in der Kryptografie steht. Ein Bitcoin-Wallet wird aus einem einzigen Geheimnis abgeleitet — dem Seed (typischerweise 12 oder 24 Wörter). Aus diesem Seed werden deterministisch alle privaten Schlüssel berechnet. Determinismus ist gewollt: Aus 12 Wörtern lassen sich 30 Jahre später dieselben Schlüssel reproduzieren. Die gesamte Sicherheit hängt also daran, dass der Seed selbst unvorhersagbar ist — und genau dafür sorgt der Zufallsgenerator.

Was Entropie bedeutet

In der Informationstheorie misst Entropie die Unvorhersagbarkeit einer Quelle, in Einheiten von Bits. Ein fairer Münzwurf liefert 1 Bit Entropie. Ein Seed mit 128 Bit Entropie ist so gewählt, dass es ~2^128 ≈ 3,4 × 10^38 gleichwahrscheinliche Möglichkeiten gibt. Selbst mit einer Billion Versuchen pro Sekunde bräuchte ein Angreifer länger als das Alter des Universums, um alle Möglichkeiten durchzuprobieren. Bei nur 40 Bit (≈ 1,1 × 10^12 Möglichkeiten) sinkt der Aufwand auf Stunden bis Tage auf einem brauchbaren GPU-Cluster — das ist der Kern des Desasters.

TRNG, PRNG, DRBG: drei Welten

• TRNG (True Random Number Generator): nutzt physikalisches Rauschen — thermisches Rauschen, Jitter von Ringoszillatoren, Quanteneffekte. Ausgänge sind nicht vorhersagbar, auch nicht bei perfekter Kenntnis des Systems. Hardware-Wallets verlassen sich hierauf.
• PRNG (Pseudo Random Number Generator): eine deterministische Funktion mit internem Zustand. Gleicher Zustand → gleiche Ausgabe. Ohne kryptographische Eigenschaften (wie bei Yasmarang oder dem Mersenne Twister) sind Ausgaben nach kurzer Beobachtung sogar vorhersagbar.
• DRBG / CSPRNG (kryptographischer Generator): ein PRNG mit kryptographischer Härtung — etwa AES-CTR- oder HMAC-basierte Konstruktionen (z. B. NIST SP 800-90A). Ausgaben sind ohne Kenntnis des geheimen Zustands nicht vom Zufall unterscheidbar.

4. Der STM32-Hardware-RNG: Die eigentlich saubere Lösung

Die COLDCARD-Familie basiert auf Cortex-M-basierten STM32-Mikrocontrollern von STMicroelectronics. Diese Chips enthalten eine integrierte RNG-Peripherie, die echte physikalische Zufallszahlen liefert:

• Zwei asynchrone Ringoszillatoren erzeugen Rauschsignale; deren Ausgänge werden XOR-verknüpft und durch einen LFSR (Linear Feedback Shift Register) nachbearbeitet, um statistische Verzerrungen zu glätten.
• Jede 32-Bit-Probe wird validiert: Die Peripherie verwirft Ergebnisse, wenn zwei aufeinanderfolgende Wörter identisch sind, und meldet Fehlerzustände über Statusregister — ein einfacher Health-Check gegen „festgeklemmte" Oszillatoren.
• Die Ausgabe ist physikalisch bedingt unvorhersagbar — solange der Chip und der Zugriff darauf korrekt konfiguriert sind.

COLDCARD kapselt diese Peripherie in einer eigenen Implementierung (random_buffer(), in Python erreichbar als ckcc.rng_bytes). Bis März 2021 nutzte die Seed-Erzeugung genau diesen Weg — sauber, direkt, hardwarebasiert. Dann kam eine Refaktorierung, die alles änderte.

5. Vom Zufall zur Adresse: BIP-39, BIP-32 und die Ableitungskette

Damit man einschätzen kann, was „nur 40 Bit Entropie" bedeutet, muss man die Kette vom Zufall zur Adresse kennen:

BIP-39: Aus Entropie werden Wörter

BIP-39 definiert die Mnemonik. 128 Bit Entropie (12 Wörter) bzw. 256 Bit (24 Wörter) werden gehasht (SHA-256); die ersten Entropie/32 Bits der Prüfsumme werden angehängt und die Bitfolge in 11-Bit-Gruppen auf eine feste Wortliste von 2048 Wörtern abgebildet. Aus dem Wortstreifen entsteht der 512-Bit-Seed via PBKDF2-HMAC-SHA512 (2048 Iterationen) mit dem Salt mnemonic + optionaler Passphrase.

Wichtig: Die Prüfsumme ist nur ein Fehlererkennungscode. Sie erhöht keine Entropie — die Mnemonik hat exakt so viele Freiheitsgrade wie die ursprüngliche Entropie.

BIP-32: Deterministische Schlüsselbäume

BIP-32 (HD-Wallets) leitet aus dem Seed einen Master-Schlüssel ab:

I = HMAC-SHA512(key="Bitcoin seed", data=seed)
master_priv = I[0:32]
chain_code  = I[32:64]

Alle Kind-Schlüssel entstehen aus diesem Master über CKD (Child Key Derivation): Für normal abgeleitete Kinder wird HMAC-SHA512(chain_code, serP(K_par) || index) berechnet, für gehärtete Kinder HMAC-SHA512(chain_code, 0x00 || ser256(k_par) || index). Der Baum ist einzigartig und unendlich verzweigbar — aber vollständig determiniert durch den Seed. Wer den Seed kennt, kennt alle Schlüssel; wer den Seed erraten kann, auch.

BIP-44/49/84: Standardisierte Pfade

Standard-Wallets leiten über feste Pfade ab: m/44'/0'/0' (BIP-44, Legacy), m/49'/0'/0' (BIP-49, wrapped SegWit), m/84'/0'/0' (BIP-84, native SegWit/P2WPKH). Diese Vorhersehbarkeit ist für den Angreifer ein Geschenk: Er muss nicht raten, welchen Pfad das Opfer nutzte, sondern nur den Seed — dann kann er die ersten, üblichen Adressen jedes Pfads ableiten und gegen die Blockchain abgleichen.

6. Die Wurzel des Übels: Ein #ifndef und das Yasmarang-Gespenst

Die technische Ursache ist ein Zusammenspiel aus einer Umstellung, einem fehlerhaft geprüften Präprozessor-Makro und einem uralten Software-PRNG. Blocks Engineering-Team und CoinKite selbst haben die Kette vollständig rekonstruiert.

Die libngu-Migration im März 2021

2021 verlegte COLDCARD die Elliptische-Kurven-Operationen auf libsecp256k1 (dieselbe Implementierung wie Bitcoin Core) und führte dafür libngu ein — eine eingebettete MicroPython-Bibliothek, die Bitcoin-Primitive exponiert. Im Zuge dieser Migration wechselte die Seed-Erzeugung von ckcc.rng_bytes() auf ngu.random.bytes() — ein Wechsel, der den Seed-Pfad unbemerkt auf den falschen RNG führte. Commit b18723dd (1. März 2021) brachte den Fehler; ausgeliefert wurde er erstmals in Firmware v4.0.0 am 17. März 2021.

Der Makro-Check, der seinen Job nicht tat

COLDCARDs Produktions-Config definiert:

/* Wir haben eine eigene Implementierung dieses Codes. */
#define MICROPY_HW_ENABLE_RNG (0)

Die Begründung ist nachvollziehbar: COLDCARD liefert einen eigenen Hardware-RNG-Wrapper. MicroPythons eigene RNG-Implementierung soll ausgeschaltet werden — daher der Wert 0. Aber libngu prüfte so:

extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

#ifndef testet nur, ob das Makro definiert ist — nicht, welchen Wert es hat. Die Definition existiert (mit Wert 0), also passierte der Build. Und MicroPython seinerseits wertet den Wert aus:

#if MICROPY_HW_ENABLE_RNG
    /* STM32-Hardware-RNG */
#else
    /* Yasmarang-Fallback */
#endif

Wert 0 → der Hardware-Pfad wird wegkompiliert, und rng_get() wird zum Software-Fallback. Ein einzelnes vertauschtes Präprozessor-Verb ersetzte jahrelang einen echten Zufallsgenerator durch ein deterministisches Spielzeug. Blocks Team: „The build therefore succeeds, and libngu binds to MicroPython's rng_get()."

Yasmarang: 32 Bit Zustand, null Zufall

Yasmarang ist ein winziger, uralter PRNG aus der „schnellste PRNG der Welt"-Ära — schnell, aber kryptographisch wertlos. Sein gesamter Zustand besteht aus vier 32-Bit-Wörtern. MicroPython initialisiert ihn beim ersten Aufruf genau einmal:

pad = UID_low32 ^ SysTick->VAL;
n   = RTC->TR;
d   = RTC->SSR;
dat = 0;

• UID_low32: das untere 32-Bit-Wort der fixen, 96-Bit-fertigungsprogrammierten Chip-Identifikation. Kein Geheimnis — es steckt teilweise sogar in der USB-Seriennummer der COLDCARD. Es ist Identität, keine Entropie.
• SysTick->VAL: ein abwärts zählender Timer, der jede Millisekunde neu geladen wird — bei Mk2/Mk3 nur ~80.000 mögliche Werte (≈ 2^16,3), bei neueren Modellen ~120.000.
• RTC->TR und RTC->SSR: Uhrzeit- und Subsekundenregister — untereinander korreliert, mit dem Bootzeitpunkt korreliert, beim Kaltstart teils statisch.

Nach dieser einmaligen Initialisierung wird keine frische Entropie mehr eingesammelt; jede Folgeausgabe ist eine deterministische Zustands-Transition. Wer UID, Timer-Zustand und Anzahl der RNG-Aufrufe kennt (oder einengt), reproduziert den Stream offline auf einem normalen Rechner.

Zusätzlich würzt libngu die Ausgabe mit einer eigenen Yasmarang-Instanz, die mit öffentlichen Konstanten initialisiert wird (pad=0x0a8ce26f, n=69, d=233) und per XOR gemischt wird:

chip = rng_get();        /* MicroPython-Fallback */
chip ^= my_yasmarang();  /* libngu-Yasmarang */

XOR erzeugt keine Entropie: Sind beide Operanden reproduzierbar, ist es auch ihr XOR. Sogar der Health-Check — gleiche aufeinanderfolgende Ausgaben verwerten — läuft ins Leere, denn ein deterministischer PRNG liefert typischerweise lauter verschiedene Wörter.

Und das Wallet-Hashing?

Die Seed-Erzeugung macht danach noch etwas: Sie hasht die 32 Zufallsbytes doppelt (SHA-256d) und prüft mit einer Assertion, dass mehr als 4 verschiedene Bytes vorkommen:

seed = ngu.random.bytes(32)
assert len(set(seed)) > 4
return ngu.hash.sha256d(seed)

Die Assertion fängt nur triviale Totalausfälle ab — Yasmarang besteht sie mühelos. Und SHA-256d macht die Ausgabe zwar statistisch „schöner", kann aber die Zahl der möglichen Seeds nicht erhöhen: Aus ≤ 2^40 Kandidaten-Streams werden per Hashing ≤ 2^40 Kandidaten-Seeds. Hashing ist eine deterministische Einbahnstraße, kein Entropieverstärker.

7. Die 32-Bit-Reseed der neuen Modelle: Halbherzige Entschärfung

Bei der Entwicklung der Mk4 (ab 2022) wurde das Problem halb erkannt und halb entschärft. Die Mk4, Mk5 und Q besitzen Secure Elements (SE1, SE2); SE1 liefert beim Boot echte Zufallswerte, SE2 acht Bytes aus einer ROM-options-Seite (kein Live-RNG-Kommando), der Boot-Code mischte diese ein:

a = callgate.read_rng(1)   # 32 Bytes von SE1
b = callgate.read_rng(2)   # 8 Bytes von SE2

n = ngu.hash.sha256d(a + b)
n, = ustruct.unpack('I', n[0:4])
ngu.random.reseed(n)

Das Problem steckt im Detail: Von den 40 Secure-Element-Bytes werden 32 Bytes SHA-256-doppel-gehasht — und dann landen nur die ersten 4 Bytes des Digests im Reseed. Und der Reseed selbst ersetzt exakt ein 32-Bit-Zustandswort des Yasmarang:

STATIC mp_obj_t random_reseed(mp_obj_t arg)
{
    yasmarang_pad = mp_obj_get_int_truncated(arg);
    return mp_const_none;
}

Kein kryptographischer DRBG, kein erneutes Seeden der MicroPython-Instanz, kein Zurücksetzen der anderen Zustandswörter, keine periodische Reseed- oder Prediction-Resistance-Logik. Blocks Analyse formuliert es präzise: Bei festem Fallback-Zustand und bekannter Aufruf-Historie gibt es höchstens 2^32 unterscheidbare Ausgabeströme — im Schnitt ~2^31 Kandidaten pro Wallet. Coinkite beziffert die effektive Entropie der neueren Modelle deshalb auf ~72 Bit, Block setzt die lockere Obergrenze bei <2^73,3 — ausdrücklich nicht gleichzusetzen mit 73 Bit kryptographischer Sicherheit, weil Timer-Felder korreliert, beobachtbar und nur einmal eingesammelt werden.

CoinKites eigener Rückblick ist erstaunlich offen: Der Großteil des Zufalls auf der COLDCARD kam jahrelang aus einem PRNG, von dessen Existenz im Source-Code der Hersteller nach eigener Aussage nichts wusste („it is from a submodule, Micropython"). Der sorgfältig gebaute eigene TRNG-Code lief weiter — aber nur „by chance" für weniger wichtige Aufgaben.

8. Angriffsmechanik: Wie man 2^40 Seeds offline durchprobiert

So brutal der Schaden, so elegant ist die Angriffskette. Sie braucht weder Zugriff auf das Gerät noch Kenntnis des Opfers:

Schritt 1: Kandidaten-Streams reproduzieren

Der Angreifer rekonstruiert den Yasmarang-Zustand, indem er UID (bekannt bzw. aus der USB-Seriennummer ableitbar), SysTick-Zählerstand, RTC-Register und die Aufruf-Historie des Seed-Prozesses über plausibel angenommene Bereiche durchläuft. Bei Mk2/Mk3 bleiben unter günstigen Annahmen wenige Milliarden bis ~10^12 Kandidaten; Blocks Obergrenze liegt bei <2^40,7. Bei bekannter UID und unbekanntem SysTick allein nur ~2^16,3.

Schritt 2: Das Address-Oracle

Bitcoin selbst liefert das Validierungs-Orakel: Jeder Kandidaten-Seed wird per BIP-39 in eine Mnemonik, per BIP-32 in einen Master-Schlüssel und über die üblichen Pfade (BIP-44/49/84) in Adressen übersetzt. Diese Adressen werden gegen die Blockchain abgeglichen — entweder global über alle existierenden Empfangsadressen oder gezielt gegen die Xpubs/Adressen, die der Angreifer vorher gesammelt hat. Bei Übereinstimmung: Seed gefunden, private Keys abgeleitet, Coins gesweept. Ein Xpub, eine bekannte Adresse oder ein öffentlicher Schlüssel genügt als Prüfkriterium.

Schritt 3: Massen-Sweep statt Einzel-Diebstahl

Die erste Welle konsolidierte 1.196 Adressen in 41 Minuten mit 30 sat/vB ohne Change-Ausgaben — ein programmatischer Ablauf, keine manuelle Jagd. Welle 3 ging sogar noch methodischer vor: Batch-Transaktionen bündeln mehrere Opfer, pro Opfer eine individuelle P2WSH-Zieladresse, nur der Default-Derivation-Path wurde angegriffen.

Eine öffentliche Kostenabschätzung von LLFOURN modelliert den Rechenaufwand je nach COLDCARD-Generation; die Schätzungen reichen von „Mk2/Mk3 lassen sich von einem guten Laptop aus brechen" bis „Mk4/Mk5/Q benötigen deutlich mehr Rechenleistung".

Auch betroffen: die Nebenfunktionen

Der schwache Stream speist nicht nur Wallets. Blocks Analyse listet weitere Konsumenten derselben Zufallsquelle: Paper-Wallet-Private-Keys (hier wird der RNG-Output direkt als privater Schlüssel verwendet — ohne BIP-39-Zwischenschritt, die öffentliche Adresse ist das Orakel), Seed-XOR-Masken beim Random Split, Ephemeral-ECDH-Keys für Cloning/USB-Verschlüsselung und Key Teleport, Web2FA-TOTP-Geheimnisse sowie Passwörter aus dem Secure-Notes-Generator.

9. Entropie-Zahlenwerk: 40, 72, 128 Bit im Vergleich

Zur Einordnung: 2^40 ≈ 1,1 Billionen — ein Kombinationsschloss, das Rechenzentrums-Hardware an einem Wochenende aufbricht. 2^72 ≈ 4,7 Trilliarden — für private Hobbyisten unerreichbar, für einen gut ausgestatteten Angreifer mit FPGAs/ASICs und Monaten Rechenzeit eine Investitionsrechnung. 2^128 dagegen ist die berühmte Zahl, bei der selbst 10^18 Versuche pro Sekunde das Universum alt werden ließen. Jedes Bit weniger Entropie halbiert den Angriffsaufwand — 88 Bit Differenz zwischen Soll und Ist sind kein gradueller Qualitätsverlust, sondern die Grenze zwischen mathematischer Sicherheit und Stehlbarkeit.

10. Die Aufdeckung: Community, Block, Galaxy — und die Rolle der KI

Die Ereigniskette nach dem 30. Juli lief bemerkenswert schnell:

• 30.07.: Betroffene Nutzer melden leere Wallets; Block Security & Bitcoin Engineering und unabhängige Researcher beginnen parallel zu untersuchen. CoinKite veröffentlicht am selben Tag eine erste Preliminary Advisory für Mk2/Mk3.
• 30.07.: Block identifiziert die Root Cause, stimmt sich mit CoinKite ab (inklusive abweichender Detailbefunde) und publiziert den vollständigen technischen Report.
• 31.07.: Galaxy Research mappt den Sweep on-chain; CoinKite liefert Notfall-Firmware für alle Modelle und Release-Tracks aus und veröffentlicht die technische Tiefenbohrung.
• 01.08.: Galaxy identifiziert Welle 3 und hebt die Gesamtschätzung auf 1.367,05 BTC an.

CoinKites Verantwortungskapitel ist in der Branche selten so deutlich formuliert: „We were unaware of the bug until today." Das Unternehmen räumt ein, dass der Quellcode immer offen lag und man deshalb annehmen müsse, jemand habe KI-gestützten Code-Review auf frühere Firmware-Versionen angesetzt und sei so auf den Fehler gestoßen — während der eigene KI-Review wenige Wochen zuvor nichts fand. „Both attackers and defenders have the same AI tools, but today it did not help us, and only helped the bad guys." Die bestehende Review-Praxis scheiterte an einem klassischen Blind-Spot: Beide RNG-Implementierungen hatten dieselbe Funktionssignatur, der richtige TRNG-Code war im Binary vorhanden — geprüft wurde die Existenz des Codes, nicht die tatsächliche Symbol-Auflösung und Erreichbarkeit im Seed-Pfad über zwei Submodule hinweg.

Die Lehre für das Verhältnis von Mensch, KI und Sicherheit: Der Code-Review-Prozess selbst wurde zur Angriffsfläche. Genau hier liegt der Bezug zur KI-Bildung — wer im Unternehmen Code-Review-Pipelines und Security-Audits aufbauen will, muss verstehen, dass KI-gestützte Analyse die Vollständigkeit des Verifikationsansatzes entscheidet, nicht die Rechenleistung.

11. CoinKites Reaktion: Advisory, Fixes und die harte Wahrheit

Die betroffenen Versionen

Entscheidend: Maßgeblich ist die Firmware, die bei der Erzeugung des Seeds lief — nicht das Installationsdatum des Geräts und nicht die aktuell installierte Version. Ein auf alter Firmware erzeugter Seed bleibt schwach, egal wohin man ihn exportiert. Der Hotfix selbst ist technisch sauber umgesetzt: Er schließt MicroPythons Fallback-PRNG-Objekt explizit aus dem Build aus und fügt einen Build-Zeit-Symbol-Check hinzu — der Build scheitert künftig, wenn nicht das Board-spezifische Objekt das globale rng_get() definiert und der Fallback gar keine Symbole liefert.

Was der Fix nicht repariert

Die 50-Dice-Rolls-Regel

Eine Ausnahme gibt es: Wer bei der Seed-Erzeugung mindestens 50 faire, unabhängige, private Würfelwürfe eingegeben hat, ist von diesem Bug allein nicht betroffen. Die Firmware hash den Geräte-Seed zusammen mit jedem eingegebenen Wurf; 50–98 Würfe liefern selbst ≥ 128 Bit unabhängige Entropie, 99+ Würfe rund 256 Bit. Das gilt aber nur, wenn die Würfe wirklich privat und nicht aufgezeichnet wurden und die finalen Wörter tatsächlich aus der gemischten Erzeugung stammen. Wer sich unsicher ist, wie viele Würfe es waren oder ob die Würfe exponiert wurden, soll migrieren. Die offizielle Anleitung zur Überprüfung der Würfel-Mathematik ist Teil der CoinKite-Dokumentation.

Passphrase und Multi-Sig: Barrieren, keine Reparaturen

Eine starke, einzigartige BIP-39-Passphrase erzeugt ein separates Wallet, das die Seed-Wörter allein nicht öffnen können — der Angreifer müsste zusätzlich die Passphrase erraten. Kurze, gebräuchliche, wiederverwendete oder exponierte Passphrasen zählen nicht. CoinKite empfiehlt trotzdem die Migration, weil die Passphrase das zugrunde liegende Problem nicht behebt (und Verluste der Passphrase unweigerlich den Wallet-Zugang kosten).

Multi-Sig hilft nur, wenn das Quorum nicht ausschließlich aus betroffenen Geräten besteht: Fünf COLDCARDs mit schwachen Seeds ergeben weiterhin ein schwaches Quorum. Blocks Report: „A quorum of secure devices is necessary to protect against this issue."

12. Einordnung: Die Ahnenreihe der schwachen RNGs — und der Bybit-Vergleich

Der COLDCARD-Fall ist kein Einzelfall, sondern der bisher teuerste Vertreter einer dokumentierten Fehlerfamilie:

• Android-SecureRandom (2013): Ein Seeding-Bug in Androids SecureRandom-Implementierung führte zu wiederholten ECDSA-Nonces und damit zu Key-Recovery bei Bitcoin-Wallets auf Android. Infrastruktur des mobilen Ökosystems — hier: die mobile Plattform.
• Profanity / Wintermute (2022): Der Vanity-Address-Generator Profanity seedete die Schlüsselerzeugung mit nur ~32 Bit Entropie; ein Angreifer nutzte das aus und leerte Wallets von Wintermute im Wert von rund 160 Mio. USD.
• Milk Sad (2023): bx seed aus Libbitcoin Explorer nutzte einen Mersenne Twister, gespeist aus der Systemzeit — 256 Bit Soll-Entropie kollabierten auf ~32 Bit; mehr als 120.000 Wallets waren exponiert.
• Ill Bloom (Coinspect, Juli 2026): Nur wenige Wochen vor dem COLDCARD-Fall wies Coinspect eine schwache-PRNG-Lücke in älteren Software-Wallets nach, der seit Mai über 5 Mio. USD über Bitcoin, Ethereum, Tron, Rootstock und Polygon zum Opfer fielen (The Hacker News).

Die wiederkehrende Struktur: eine Zufallsquelle, die als stark angenommen wurde, aber schwach war — bei identisch intakter Kryptographie. Zwei Lehren daraus: Erstens muss Entropie empirisch verifiziert werden, nicht per Code-Review-Glaube; zweitens sind selbst „professionelle" Generatoren (Mersenne Twister, Software-Fallbacks) keine kryptographischen Quellen.

Bybit, Februar 2025: Der andere Weg, Vertrauen zu brechen

Der Bybit-Hack vom Februar 2025 (ca. 1,5 Mrd. USD, der größte Diebstahl in der Geschichte von Krypto-Exchanges) verfolgte einen komplett anderen Vektor: Eine Supply-Chain-Kompromittierung von Safe{Wallet} — der von Bybit genutzten Signatur-Infrastruktur. Angreifer (vom FBI der Lazarus Group zugeschrieben) manipulierten die Wallet-Web-Infrastruktur so, dass die signierenden Personen eine modifizierte, bösartige Transaktion genehmigten. Entropie und Kryptographie waren dort einwandfrei; zerstört wurde die Integrität der Software-Kette zwischen Signierer und Wallet.

Der Vergleich ist lehrreich: Beim Bybit-Fall versagte die Umgebung des Schlüssels (Code, Infrastruktur, menschlicher Prüfprozess), beim COLDCARD-Fall versagte die Erzeugung des Schlüssels selbst — ohne Netzwerkzugriff, ohne Phishing, ohne jeden Bedienfehler. Beide Fälle zusammen decken die zwei kritischen Punkte jeder Self-Custody-Architektur ab: Woher kommt der Seed? und wohin fließt die Signaturanfrage? Beide müssen verifizierbar, unabhängig und auditierbar sein.

Die Marktbeobachtung unterstreicht die Dimension: TRM Labs beziffert für H1 2026 einen Rekord von 207 Hack-Events, wobei Infrastruktur- und Key-Kompromittierungen nur 15 % der Vorfälle, aber 76 % der Dollar-Verluste ausmachten. Ari Redbord (TRM Labs) formuliert den strategischen Punkt: Selbstverwahrung verlagert Risiko, sie eliminiert es nicht.

13. Was du jetzt tun solltest: Prüfen, migrieren, härten

Diese Anleitung folgt der offiziellen CoinKite-Advisory (Security Advisory). Wichtig: Ruhe bewahren und sauber arbeiten — eine überstürzte Migration ist ein größeres Risiko als das eigentliche Problem.

Schritt 1: Betroffenheit prüfen

1. Modell und Firmware auf der COLDCARD prüfen (Menü: Advanced → Firmware bzw. Settings). Release-Track beachten: Standard vs. Edge sind getrennte Gleise.
2. Versions-Tabelle oben abgleichen — maßgeblich ist die Version, die bei der Seed-Erzeugung aktiv war.
3. Frage beantworten: Wurden ≥ 50 faire, unabhängige, private Würfelwürfe eingegeben? Ist die Passphrase stark, einzigartig und nie digital gespeichert? Im Zweifel gilt: migrieren.

Schritt 2: Firmware aktualisieren (vor der Seed-Erzeugung!)

1. Firmware-Datei ausschließlich von den offiziellen Download-Seiten laden (Mk3, Mk4/Mk5, Q, Edge) — niemals von Drittanbietern.
2. Datei auf die MicroSD-Karte kopieren, im COLDCARD-Menü installieren und die angezeigte Versionsnummer verifizieren.
3. Erst nach bestätigtem Update einen neuen Seed erzeugen — auf alter Firmware generierte Ersatz-Seeds wären erneut schwach.

Schritt 3: Neuen Seed erzeugen und migrieren

Wer nur ein Mk2/Mk3-Gerät besitzt, kann nach dem Update auf 4.2.0 auch eine reine Dice-Only-Seed erzeugen (Import Existing → Dice Rolls, ≥ 99 Würfe) — dieser Pfad nutzt den Gerätegenerator gar nicht. Die Würfelsequenz ist geheimes Schlüsselmaterial: nie fotografieren, nie digital speichern, nie in einen vernetzten Rechner eingeben.

Schritt 4: Dauerhaft härten

• Entropie-Selbsttest: Nach der Migration den neuen Seed nicht blind vertrauen — XFP, Empfangsadresse und eine Wiederherstellung auf einem zweiten Gerät gegenprüfen. CoinKites Dice-Roll-Verifikation dokumentiert die Mathematik hinter Würfelwürfen.
• Passphrase: stark, einzigartig, getrennt vom Seed-Backup aufbewahren; jeden Passphrasen-Tippfehler erzeugt ein valides, aber leeres Wallet — Fingerprint vor Einzahlung prüfen.
• Multi-Sig: Quorum aus Geräten unterschiedlicher Hersteller/Codebasen aufbauen, damit ein einzelner Entropie- oder Firmware-Bug das Quorum nicht fällt.
• Diversifikation: Nie allein von der Entropie eines einzigen Herstellers abhängen; Seeds können auch unabhängig (Dice, Einmalkombinationen) ergänzt werden.
• Monitoring: Wallets beobachten (z. B. über Watch-only-Xpubs), damit ungewöhnliche Bewegungen sofort auffallen.

Für die Beurteilung, ob eigene Mittel in betroffenen Adressen liegen, sind öffentliche On-Chain-Daten der erste Anlaufpunkt — das Community-Review auf GitHub verlinkt entsprechende Werkzeuge und den Stand der Untersuchung. Ein öffentlich nachweisbarer Fall, in dem ein Opfer-Seed rekonstruiert und einer geleerten Adresse zugeordnet wurde, lag bei Redaktionsschluss allerdings nicht vor — Galaxy stützt die Zuordnung auf On-Chain-Heuristiken.

14. Fazit: Vertrauen ist messbar, oder es ist keines

Der COLDCARD-Fall ist der bisher teuerste Hardware-Wallet-Hack der Bitcoin-Geschichte — verursacht durch ein einziges falsches Präprozessor-Verb, das über fünf Jahre unbemerkt blieb. Er zeigt dreierlei:

1. Entropie ist nicht verhandelbar. Alle kryptographischen Sicherheitsversprechen eines Wallets hängen an der Qualität einer einzigen Zufallsquelle. 40 statt 128 Bit ist kein Faktor, sondern ein Klassenunterschied zwischen „unmöglich zu brechen" und „am Wochenende gehackt".
2. Code-Review muss Erreichbarkeit prüfen, nicht Existenz. Der richtige TRNG-Code war im Binary vorhanden; geprüft wurde nie, welches rng_get() der Seed-Pfad tatsächlich auflöst. Derselbe Blind-Spot-Fehler-Typ — prüfen statt verifizieren — wiederholt sich in dieser Branche seit Jahren.
3. Die Werkzeuge sind symmetrisch. KI-Assistenz fand den Bug für die Angreifer, nicht für den Hersteller. Sicherheitsteams müssen verstehen, wo automatisierte Analyse Grenzen hat — und sie müssen den Feind-Review zuerst machen.

A single misconfigured preprocessor macro can silently collapse the security guarantee of any self-custody arrangement for years without triggering any observable alarm.

Für alle, die ihr Wissen über sichere KI-Einsätze, Automation und Risikomanagement systematisieren wollen, ist dieser Fall ein ideales Lehrstück: Die Fehlerkette ist technisch präzise dokumentiert, wirtschaftlich bezifferbar und strategisch folgenreich.

15. Quellen & weiterführende Links

Alle Fakten und Zitate dieses Artikels stammen aus den folgenden öffentlichen Quellen; Stand jeweils 3. August 2026:

• CoinKite — Coldcard Security Advisory (Mk2/Mk3): https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
• CoinKite — Technical Deep Dive into the Entropy Issue: https://blog.coinkite.com/entropy-technical-backgrounder/
• Block Engineering — Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
• The Hacker News — Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes: https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
• Galaxy Research auf X — Welle 1: https://x.com/glxyresearch/status/2083181683067506899; Fingerprint-Warnung: …/2083255552633635183; Wellen-Update: …/2083560940469981591; Welle 3: …/2083623500183421043
• Community-Write-up — ColdCard Entropy Incident (GitHub): https://github.com/nwfella/coldcard-entropy-incident
• The Crypto Times — Coldcard Hack Tops $88.6M as Galaxy Finds Third Attack Wave: https://www.cryptotimes.io/2026/08/02/coldcard-hack-tops-88-6m-as-galaxy-finds-third-attack-wave/
• The Crypto Times — Erste Berichte ($38M drained): https://www.cryptotimes.io/2026/07/31/bitcoins-invisible-risk-coldcard-mk3-firmware-bug-leaves-btc-wallet-seeds-exposed-38m-drained/
• The Crypto Times — Zweite Welle ($75.1M): https://www.cryptotimes.io/2026/08/01/coldcard-hack-hits-75m-after-alleged-second-attack-wave-galaxy-research/
• The Crypto Times — Größte Wallets zuerst (Chainalysis): https://www.cryptotimes.io/2026/08/01/coldcard-hacker-went-after-largest-bitcoin-wallets-first-chainalysis/
• Bitcoin Magazine — Coldcard Wallet Flaw Exposes Years Of Bitcoin Seeds After $70M In BTC Stolen: https://bitcoinmagazine.com/news/coldcard-wallet-exposed-after-bitcoin-hack
• Bitcoin Magazine — Coinkite Releases Fixed Firmware; AI Likely Involved: https://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
• TechSpot — A Coldcard firmware flaw let hackers drain $70 million in Bitcoin in 41 minutes: https://www.techspot.com/news/113322-coldcard-firmware-flaw-hackers-drain-70-million-bitcoin.html
• CoinSpeaker — $86M in Bitcoin Lost to Coldcard's Silent PRNG Flaw Over Five Years: https://www.coinspeaker.com/coldcard-prng-vulnerability-bitcoin-hack-losses/
• The Hacker News — Ill Bloom (Coinspect, schwacher PRNG in Software-Wallets): https://thehackernews.com/2026/07/attackers-exploit-ill-bloom.html
• CoinKite-Dokumentation — Dice-Roll-Mathematik: https://coldcard.com/docs/verifying-dice-roll-math/; Passphrase: https://coldcard.com/docs/passphrase/
• Block-Referenzen — libngu random.c: https://github.com/switck/libngu/blob/537519a829259622ea6b0334fbafd6cae852852f/ngu/random.c; MicroPython-Fallback: https://github.com/Coldcard/micropython/blob/4107246f8a080807b62c3b4838e71e812ea68b6f/ports/stm32/rng.c; Migrations-Commit: https://github.com/Coldcard/firmware/commit/b18723dddb6d751c39978e4364b56b2414f68b47
• LLFOURN — Angriffskosten-Modell (X): https://x.com/LLFOURN/status/2082990000896147942

Hinweis: Dieser Artikel ist redaktionelle Einordnung, keine Anlage- oder Rechtsberatung. Prüfe alle Angaben gegen die offiziellen CoinKite-Veröffentlichungen, bevor du handelst.