Governance und Custody-Risiken: Wenn die Key-Generierung scheitert

Eine Schwachstelle in der Firmware bestimmter Coldcard-Hardware-Wallets wurde am 30. Juli 2026 für einen groß angelegten Angriff ausgenutzt. Dabei wurden Vermögenswerte aus mehr als 1.000 Single-Signature-Wallets abgezogen. Aktuellen Analysen zufolge beläuft sich der Schaden inzwischen auf über 1.100 BTC – etwa 70 Millionen US-Dollar. Da die Ermittlungen noch laufen, ist die endgültige Summe noch nicht bestätigt.

Coinkite, der Entwickler von Coldcard, hat eine ausführliche technische Analyse mit der Ursache, den betroffenen Modellen und den empfohlenen Gegenmaßnahmen veröffentlicht – die vollständige Offenlegung finden Sie unter „Quellen“.
Kurz gesagt: Bestimmte Firmware-Versionen nutzten statt des Hardware-Zufallszahlengenerators unbemerkt eine deutlich schwächere Quelle für Zufallszahlen. Die Folge: Betroffene Seeds verfügten nur über rund ein Drittel der vorgesehenen Entropie einer Bitcoin-Wallet. Theoretisch könnte ein Angreifer dadurch einen privaten Schlüssel rekonstruieren, ohne jemals Zugriff auf das Gerät zu haben. Coinkite hat bislang nicht bestätigt, dass dies die Ursache des konkreten Angriffs war. Zeitpunkt und Ablauf sprechen jedoch deutlich dafür.

Ein Punkt sticht besonders hervor: Coinkite vermutet, dass der Angreifer KI-Tools nutzte, um die Schwachstelle im Open-Source-Code aufzuspüren. Eine interne, KI-gestützte Überprüfung hatte den Fehler nur wenige Wochen zuvor übersehen. Das verdeutlicht eine neue Realität: Angreifer und Verteidiger arbeiten inzwischen mit denselben KI-Werkzeugen – manchmal verschaffen sie den Angreifern den entscheidenden Vorsprung. Das zeigt, dass öffentlich zugänglicher und überprüfbarer Code allein noch keine Sicherheitsgarantie ist.

Für Nutzer betroffener Firmware reicht ein Update allein nicht aus: Wurde ein Seed bereits mit der fehlerhaften Version generiert, lässt sich das Problem durch eine neue Firmware nicht rückwirkend beheben. Die Schwachstelle steckt im Seed selbst, nicht in dem Gerät, auf dem er gespeichert ist. Die praktische Lösung besteht darin, unter einer sicheren Firmware eine komplett neue Wallet zu erstellen und die Assets dorthin zu übertragen.

Das gilt auch für Multisig-Setups (Wallets, die mehrere Signaturen für eine Transaktion erfordern). Ein einzelner sicherer Key schützt die Wallet nicht, wenn genügend weitere Signatur-Keys von betroffenen Geräten stammen und damit der erforderliche Schwellenwert für Transaktionen auch ohne ihn erreicht werden kann. Die genauen Schritte und Sonderfälle beschreibt Coinkite in seinem Sicherheitshinweis.

Was das für die Custody-Architektur bedeutet

Diesen Vorfall lediglich als Schwachstelle eines einzelnen Produkts zu betrachten, greift zu kurz. Das eigentliche Problem ist struktureller Natur: Der Fehler entstand bereits am Anfang des Custody-Lebenszyklus, bei der Key-Generierung – keine der nachfolgenden Sicherheitsmaßnahmen konnte ihn ausgleichen. Ein Seed mit unzureichender Entropie wird nicht sicherer, nur weil Backups sorgfältig verwaltet, Firmware-Updates gewissenhaft durchgeführt oder die Daten offline gespeichert werden. Ist die Zufälligkeit, auf der ein Key basiert, vorhersehbar, war er selbst nie wirklich privat – unabhängig davon, wo er verwahrt wurde.

Wie vertrauenswürdig die Key-Generierung ist, hängt letztlich von ihrer schwächsten und am wenigsten geprüften Komponente ab – das hat auch die KI-gestützte Entdeckung der Coldcard-Schwachstelle gezeigt. Der Vorfall macht deutlich, was eine andere Architektur besser machen muss: Eine softwarebasierte Rückfalllösung ersetzte unbemerkt den Hardware-Zufallszahlengenerator, ohne dass verifiziert wurde, welcher Mechanismus tatsächlich ausgeführt wurde.

Zertifizierte Hardware-Sicherheitsmodule (HSMs) setzen genau bei diesem Risiko an: Sie erzeugen Zufallswerte mittels einer physikalischen Rauschquelle – einem Hardware-Zufallszahlengenerator für echte Zufallszahlen, der sich kontinuierlich selbst überprüft. Damit sind sie nicht auf eine softwarebasierte Alternative angewiesen, die infolge einer Fehlkonfiguration unbemerkt zum Einsatz kommen könnte.

Bitpanda Enterprise Custody generiert und schützt kryptografisches Key-Material innerhalb einer zertifizierten HSM-Infrastruktur. Sie ist Teil einer professionell verwalteten Umgebung, die unabhängig zertifiziert und geprüft wird. Damit unterscheidet sie sich grundlegend von einem einzelnen Gerät für Endnutzer, das mit einem festen Firmware-Stack arbeitet und dessen Überprüfung davon abhängt, wer den Code wann unter die Lupe nimmt.

Das bedeutet jedoch nicht, dass jede Ebene vor vergleichbaren Bugs geschützt ist. Auch eine in Software implementierte Policy- oder Freigabeebene unterliegt grundsätzlich denselben Risiken wie anderer Code und könnte einen ähnlichen Fehler enthalten. Der entscheidende strukturelle Unterschied liegt in der Entropiequelle: Sie basiert auf einem physikalischen Prozess statt auf einer Software-Alternative – und genau hier lag die Coldcard-Schwachstelle.

Ein einzelner Key bleibt ein Single Point of Failure – unabhängig davon, wie sicher er generiert wurde. Das gilt für die Autorisierung ebenso wie für die Key-Generierung. Die Blockchain erkennt nicht, ob eine Transaktion von einem legitimen Nutzer signiert wurde oder von einem Angreifer, der den Key rekonstruieren konnte.

An diesem Punkt werden interne Prozesse selbst zu einem wichtigen Bestandteil der Sicherheitsarchitektur – zusätzlich zur Kryptografie.

Bitpanda Enterprise Custody setzt auf rollenbasierte Zugriffsrechte und ein Quorum für Freigaben. Sensible Vorgänge – darunter Transaktionen, Änderungen an Richtlinien oder Nutzerrollen – können erst ausgeführt werden, wenn eine zuvor festgelegte Anzahl autorisierter Nutzer zugestimmt hat. Kommt die erforderliche Zahl an Freigaben nicht zustande, wird der Vorgang nicht ausgeführt. Je nach Kontokonfiguration lassen sich so Aufgaben und Verantwortlichkeiten trennen und Maker-Checker-Kontrollen umsetzen: Wer eine Transaktion initiiert, kann sie nicht selbst freigeben.

Transaktionsbezogene Richtlinien ermöglichen zusätzliche Kontrollen über das Quorum hinaus. Dazu zählen beispielsweise die Beschränkung von Transfers auf ein vorab freigegebenes Adressbuch sowie zusätzliche manuelle Freigaben für Transaktionen oberhalb eines von der Organisation definierten Betrags.

Prävention allein reicht nicht – ebenso entscheidend ist die frühzeitige Erkennung. Der gemeldete Transfer erfolgte innerhalb eines kurzen Zeitfensters über mehr als tausend Wallets hinweg – genau die Art von Muster, die eine kontinuierliche Transaktionsüberwachung erkennen soll. Bei einer selbst verwalteten Hardware-Wallet gibt es eine solche Überwachung nur, wenn der Besitzer sie selbst einrichtet. Bei Bitpanda Enterprise Custody gehören 24/7-Monitoring und kontinuierliche Warnmeldungen zum operativen Setup.

Das heißt nicht, dass Managed Custody sämtliche Risiken beseitigt oder zertifizierte Infrastruktur vor vergleichbaren Fehlern geschützt ist. Auch HSMs und andere verwaltete Komponenten für das Key-Management sind komplexe Systeme – mit eigener Firmware, eigenen Lieferketten und Schwachstellen, die im Laufe der Jahre offengelegt wurden. Zertifizierungen und Audits können die Wahrscheinlichkeit eines Fehlers und das Ausmaß möglicher Schäden zwar reduzieren, können Fehler aber nicht ausschließen. Entscheidend ist, wie die Architektur mit einer entdeckten Schwachstelle umgeht: Kann sie koordiniert erkannt, eingegrenzt und behoben werden? Oder muss jede betroffene Partei das Problem selbst feststellen, die eigene Gefährdung bewerten und ihre Assets eigenständig migrieren?

Ein Blick in die Zukunft

Dieser Vorfall verdeutlicht auch eine umfassendere Anforderung an die institutionelle Verwahrung: die Fähigkeit, sich an veränderte kryptografische Standards und Implementierungen anzupassen – und nicht nur auf bereits bekannte Risiken zu reagieren.

In einer professionell verwalteten Umgebung lässt sich die Reaktion auf Sicherheitsprobleme grundsätzlich über die gesamten Bestände eines Instituts hinweg koordinieren – beispielsweise bei einem neuen Firmware-Fix, einem kompromittierten Algorithmus oder einer notwendigen Key-Migration. Bei selbst verwalteten Hardware-Wallets müssen entsprechende Maßnahmen dagegen für jedes Gerät einzeln umgesetzt werden.

Der Vorfall führt unmittelbar vor Augen, wie wichtig kontinuierliches Monitoring, Audit-Protokolle und ein dokumentierter Prozess für den Umgang mit Sicherheitsvorfällen sind. Sie sind keine reine Formalität, sondern entscheiden darüber, ob ein Institut von seinem Anbieter frühzeitig über ein Problem informiert wird – oder erst aus den Schlagzeilen davon erfährt.

Selbst verwaltete Hardware-Wallets und institutionelle Verwahrung im Vergleich

Fazit

Coldcard ist eine renommierte und weit verbreitete Hardware-Lösung. Der Vorfall stellt hardwarebasierte Sicherheitskonzepte deshalb nicht grundsätzlich infrage. Vielmehr macht er auf eine grundlegende strukturelle Erkenntnis aufmerksam: Offline-Verwahrung ist nur ein einzelner Baustein innerhalb einer mehrschichtigen Sicherheitsstrategie.

Fehler ganz am Anfang des Custody-Lebenszyklus – insbesondere bei der Erzeugung von Entropie – haben dauerhafte Folgen, die sich durch spätere Sicherheitsmaßnahmen nicht mehr ausgleichen lassen. Genau deshalb sollten Institutionen bei der Bewertung einer Verwahrlösung nicht nach einer Architektur suchen, die Fehler grundsätzlich ausschließt. Entscheidend ist, ob ein Custody-Modell so aufgebaut ist, dass es bei einer auftretenden Schwachstelle widerstandsfähig bleibt und deren Auswirkungen wirksam begrenzen kann.

Für Institutionen, die ihre Custody-Architektur angesichts dieses Vorfalls überprüfen, bietet das Bitpanda Enterprise Team einen detaillierten Einblick in den Aufbau und die Funktionsweise dieser Kontrollmechanismen.

Quellen

• Coinkite, Mk3 Security Advisory
• Coinkite, Technical Deep Dive into the Entropy Issue
• Dokumentation von COLDCARD, Upgrade Firmware
• Block Engineering Blog, Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware