Wie schwache Entropie weiterhin Millionen im Krypto-Bereich kostet

Am 31. Juli 2026 leerte ein Angreifer innerhalb von 25 Minuten etwa 500 Bitcoin-Wallets. Der Angriff bewegte rund 594 BTC im Wert von etwa 38 Millionen US-Dollar – und jede betroffene Wallet gehörte jemandem, der sich extra eine Hardware-Wallet gekauft hatte, um genau so einen Fall zu vermeiden.
 

Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
 

Dies ist der jüngste Fall in einer langen Reihe. In den vergangenen zehn Jahren waren die größten Verluste im Krypto-Bereich seltener auf ausgeklügelte Hacks zurückzuführen als auf ein grundlegendes Problem: Zufallszahlen, die nicht zufällig genug waren.

Was steckt hinter dem privaten Schlüssel?

Egal ob App, Browser-Erweiterung oder Hardware-Gerät – Krypto-Wallets hängen von einer entscheidenden Aufgabe ab: Zahlen zu erzeugen, die niemand erraten oder rekonstruieren kann. Genau das ist Entropie in diesem Zusammenhang: das Maß an Unvorhersehbarkeit einer erzeugten Zahl.

Entropie ist der Rohwert an Zufälligkeit, den eine Wallet zur Erstellung eines privaten Schlüssels nutzt, gemessen in Bits. Mehr Bits bedeuten eine größere Auswahl an möglichen Schlüsseln, die ein Angreifer durchsuchen müsste. Die Entropie gelangt bei der Einrichtung in die Wallet. Jeder Schlüssel, jede Adresse und jede Signatur danach folgt festen mathematischen Regeln – neue Zufälligkeit kommt später nicht mehr hinzu.

Entropiequelle

Grundsätzlich kann eine Wallet Zufallszahlen von einem pseudorandom number generator (PRNG) beziehen: ein Algorithmus, der eine kleine Menge „echter“ Entropie auf so viele Zufallszahlen streckt, wie benötigt werden – aber nur, wenn der Startwert selbst unvorhersehbar ist. 

Software, die in einem Browser-Tab oder auf einem frisch gestarteten Smartphone läuft, beginnt oft in einer Art sensorischer Isolationskammer. Um wirklich zufällige Zahlen zu erzeugen, braucht ein Programm „Rauschen“ – unvorhersehbare Eingaben aus der realen Welt, etwa aus Zeitabweichungen im Prozessor, Mausbewegungen oder spezieller Hardware.

In den ersten Millisekunden nach dem Einschalten eines Geräts sind diese Rauschquellen oft leer oder nur teilweise initialisiert. Ruft eine Kryptobibliothek den Zufallszahlengenerator zu früh auf, schöpft sie aus einem zu kleinen Pool – die erzeugten Zahlen sind zwar technisch zufällig, stammen aber aus einem so kleinen Bereich, dass sie sich erschöpfend durchsuchen lassen.

Browser bringen zusätzliche Einschränkungen mit sich. JavaScript’s Math.random() wurde nie für Sicherheitszwecke entwickelt, und auch das sicherere crypto.getRandomValues() hängt vom zugrundeliegenden Entropie-Pool des Betriebssystems ab. Ist dieser Pool schwach – etwa in mobilen Sandboxes, virtuellen Maschinen oder abgespeckten IoT-Geräten – ist die Zufälligkeit schon kompromittiert, bevor sie überhaupt zur Schlüsselerzeugung gelangt.

Zufall bei Transaktionssignaturen

Wenn du eine Bitcoin- oder Ethereum-Transaktion signierst, verwendest du deinen privaten Schlüssel nicht direkt. Stattdessen erzeugst du einen Nonce: eine einmalige, zufällige Zahl, die mit deinem privaten Schlüssel in der Elliptic Curve Digital Signature Algorithm (ECDSA) kombiniert wird, um die Signatur zu erzeugen.

Der Haken: Wird derselbe Nonce zweimal mit demselben privaten Schlüssel verwendet, liefert die Mathematik einem Angreifer alles, was er braucht, um den privaten Schlüssel zu berechnen.
ECDSA-Signaturen bestehen aus einem Zahlenpaar (r, s), das eine bestimmte Gleichung erfüllt, die Folgendes beinhaltet:

• den privaten Schlüssel (d),
• den Nonce (k), und
• die gehashte Transaktionsnachricht (z).

Ist k für zwei verschiedene Nachrichten gleich, lassen sich die Gleichungen so aufstellen, dass jeder, der beide Signaturen sieht, k berechnen kann. Ist k bekannt, ergibt sich d – der private Schlüssel – mit ein paar Multiplikationen und einer modularen Inversion.

Im Jahr 2013 führte a flaw in Android’s SecureRandom function caused early Bitcoin wallets on the platform to produce vorhersehbare Nonces. Guthaben verschwanden aus Wallets, bevor die meisten Nutzer überhaupt ahnten, dass es ein Problem gab.

Im Gegensatz zu typischen Programmierfehlern lässt sich schwache Zufälligkeit nicht einfach durch das Lesen des Quellcodes erkennen. Die Funktionsaufrufe können korrekt aussehen, aber nur wer die tatsächlich erzeugten Bits misst und statistisch auf Unvorhersehbarkeit prüft, erkennt tödliche Schwächen – die oft monatelang oder jahrelang unentdeckt bleiben, bis jemand sie gezielt ausnutzt.

Warum Entropie nach wie vor eine Schwachstelle bleibt, lässt sich so zusammenfassen:

• Startup-Entropie-Mangel: Geräte, die gerade erst eingeschaltet wurden, haben oft noch nicht genug Umgebungsrauschen gesammelt, um PRNGs zu initialisieren.

• Browser-Einschränkungen: JavaScript’s Math.random() ist nicht sicher; selbst crypto.getRandomValues() hängt vom Entropie-Pool des Hostsystems ab.

• Unsichere Tools: Vanity-Generatoren, Offline-Skripte oder schlecht gepflegte Bibliotheken sparen oft an Zufälligkeit zugunsten von Geschwindigkeit oder Nachvollziehbarkeit.

• Menschliche Eingaben: „Brainwallets“ und selbstgewählte Phrasen wurden bereits durch Wörterbuchangriffe geknackt.

Kryptografen bevorzugen seit Langem Hardware-Zufallszahlengeneratoren (HRNGs), auch True RNGs genannt. Sie wandeln physikalische Phänomene wie elektronisches Rauschen, thermische Schwankungen oder radioaktiven Zerfall in Zufallsbits um und können sich selbst laufend auf Fehler oder Bias testen.

Wie Hardware das Problem löst

In hochsicheren Systemen ist die Lösung klar: Die Schlüssel werden im Inneren eines Chips erzeugt, der einen zertifizierten HRNG enthält – und diese Schlüssel verlassen den Chip nie als Kopie.

A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.

A secure element can house a hardware random number generator that draws its unpredictability from physical noise, such as thermal fluctuations or oscillator jitter, rather than from mathematical algorithms alone. 

Diese HRNGs sind keine „Einmal-und-fertig“-Bauteile. Nach Standards wie NIST SP 800-90B müssen sie kontinuierliche Selbsttests durchführen und jeden Ausgabestrom auf statistische Auffälligkeiten, festhängende Bits oder andere Fehler prüfen, die die Zufälligkeit im Laufe der Zeit beeinträchtigen könnten. Bei Auffälligkeiten kann der Chip die Schlüsselerzeugung sofort stoppen. In einer guten Hardware-Wallet speist der HRNG des Secure Elements die Zufallsdaten direkt in den Schlüsselerzeugungsprozess im Chip ein. 

Nicht jede „Hardware“ ist gleich sicher

Der Begriff Hardware-Wallet umfasst eine breite Palette an Designs – und nicht alle bieten denselben Schutz für Zufälligkeit und Schlüsselisolierung.

Am unteren Ende stehen Geräte, die auf General-Purpose-Mikrocontrollern basieren – Chips, die auf Flexibilität statt auf Widerstandsfähigkeit gegen physische oder Seitenkanalangriffe ausgelegt sind. Viele davon enthalten nur einen einfachen Zufallszahlengenerator. 

Oft handelt es sich dabei lediglich um einen Pseudorandom-Generator, der aus dem internen Zustand des Geräts gespeist wird – und nicht um einen vollwertigen, nach Standards geprüften HRNG. In solchen Designs kann die Schlüsselerzeugung in der Firmware erfolgen, wobei der private Schlüssel vorübergehend im RAM oder Flash-Speicher landet. Das bedeutet: Ein Fehler in der Firmware, ein erfolgreicher Seitenkanalangriff oder physische Manipulation könnten den Schlüssel offenlegen.
 

Im Gegensatz dazu platzieren Wallets mit Secure Element sowohl die Entropiequelle als auch die Schlüsselerzeugung in einer manipulationssicheren Umgebung. Dieses Modell erzwingt zudem strikte Zugriffskontrolle: Kryptografische Operationen (Signatur, Ableitung) finden im Chip statt – nur die finale Signatur oder der Public Key verlassen ihn, nie das Geheimnis selbst.

Standards gibt es längst

Das Zufallsproblem ist keine ungelöste Wissenschaft. Kryptografen haben längst festgelegt, wie gute Entropie aussieht. Das US-amerikanische National Institute of Standards and Technology (NIST) hat die SP 800-90-Standardreihe veröffentlicht, die das Thema in klare Teilbereiche gliedert.

SP 800-90B beschreibt, wie eine Entropiequelle bewertet wird – also der physikalische oder softwarebasierte Prozess, der unvorhersehbare Bits erzeugt. Gefordert werden strenge statistische Analysen, um die echte Entropie jeder Bitfolge zu schätzen, sowie eingebaute Gesundheitstests, die die Quelle laufend auf Bias oder Fehler überwachen.

SP 800-90C erklärt, wie diese Entropie mit deterministischen Zufallsbitgeneratoren (DRBGs) kombiniert werden kann, damit die Ausgabe auch dann stark bleibt, wenn eine Quelle schwächer wird.

Ein konformes Gerät erzeugt nicht einfach einmal Zufallszahlen und hofft auf das Beste. Es prüft laufend seine eigene „Pulsfrequenz“: Wenn das Rauschmuster des HRNG sich verändert, ein Bit „hängen bleibt“ oder die Ausgabe statistische Schwellenwerte verfehlt, wird die Schlüsselerzeugung gestoppt, um schwache Schlüssel zu vermeiden.

Wie erkennst du das Risiko?

Die meisten Nutzer können Entropie nicht direkt messen – aber du kannst hinterfragen, wo und wie deine Schlüssel erzeugt wurden. Wurden sie „in einer Webseite“ oder „in einer alten Android-App“ generiert, insbesondere vor Mitte der 2010er Jahre, sind diese Schlüssel vermutlich schwach. Am sichersten ist es, eine neue Wallet auf einem Hardware-Gerät mit zertifizierter, dokumentierter Zufälligkeit zu erzeugen und die Coins dorthin zu transferieren.

Eine Chronik der Entropie-Angriffe 

Schwache Entropie macht aufwendige Rückwärtsarbeit überflüssig. Der Angreifer prüft die kleine Menge an Schlüsseln, die der fehlerhafte Generator erzeugt haben könnte, leitet die Adressen ab und gleicht sie mit der Blockchain ab. Hier einige Beispiele:

• 2018—The IOTA seed generator scam: Users were told to create their wallet seeds using a website. The site’s operator kept a copy of those seeds and drained funds later, stealing roughly $4 million. The randomness here was zero: the attacker already knew the numbers.
   

• 2019—The Blockchain Bandit: Security researchers identified 732 weak Ethereum private keys in the wild. An unknown attacker had been watching those addresses for years, siphoning roughly 45,000 ETH as soon as funds appeared.
   

• 2022—Profanity’s vanity address catastrophe: The open-source Profanity tool generated custom Ethereum addresses from seeds with only 32 bits of entropy, about four billion possibilities. A modern GPU can search that space in hours. Wintermute, a London market maker, lost about $160 million this way.
   

• 2023—Trust Wallet browser extension flaw: In a disclosure from Ledger’s security team, the browser extension was found to produce wallet seeds with about 32 bits of entropy. It was fixed quickly, and Trust Wallet reimbursed some users, but for months, anyone generating a wallet there was at risk.
   

• 2025—The LuBian allegation: Arkham’s claim is still unverified, but if the loss of 127,426 BTC really traces to predictable key generation, it would be the crowning example of how a single misstep at creation can doom billions in assets. 
   

• 2026: COLDCARD: Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.

  Coinkite estimates about 40 bits of effective search space on Mk3 hardware, and about 72 bits on later models that mixed in secure element data. Both figures sit below the 128-bit target.

  A guard existed to prevent exactly this. It tested whether a configuration macro was defined, rather than whether its value was non-zero; the macro was set to zero, so the check passed and the error never fired.

Du überlegst, von COLDCARD zu wechseln?

Tangem generiert deinen Schlüssel direkt im zertifizierten Secure-Element-Chip mithilfe eines Hardware-Zufallszahlengenerators. 

Wenn du genug davon hast, dir ständig Sorgen um Seed-Phrases zu machen: Unser Seedless-Setup bedeutet: keine 12- oder 24-Wort-Phrasen mehr, die du notieren, fotografieren oder verlieren könntest – genau das, worauf die meisten Wallet-Hacks der Vergangenheit zurückzuführen sind.

Unabhängig geprüft von Cure53, Kudelski und Riscure. Entwickelt genau für diesen Anwendungsfall.

Ziehe deine Coins dorthin, wo Zufälligkeit wirklich zufällig ist. Hol dir die Tangem Wallet.