Krypto-News

Zilliqa-Ledger-Lücke: Private Keys gefährdet

Teilen
Zilliqa-Ledger-Lücke als gebrochene digitale Signatur zwischen Hardware-Wallet und geschütztem Blockchain-Netzwerk

Die Zilliqa-Ledger-Lücke kann private Schlüssel aus bereits veröffentlichten Signaturen rekonstruierbar machen. Betroffen ist die App für native, nicht EVM-kompatible ZIL-Transaktionen auf Ledger-Geräten. Zilliqa hat native Transaktionen vorsorglich ausgesetzt und arbeitet an einer koordinierten Lösung. Wer mit dieser App ungefähr fünf oder mehr native Transaktionen signiert hat, soll den verwendeten Schlüssel nach Angaben des Projekts als kompromittiert betrachten und zunächst auf offizielle Anweisungen warten.

Die offizielle Sicherheitsmitteilung von Zilliqa beschreibt eine fehlerhafte Erzeugung temporärer Zufallswerte bei Schnorr-Signaturen. The Block berichtete unabhängig über die Sperre und die technische Ursache. EVM-Transaktionen sowie die von Zilliqa genannten Software Development Kits zilliqa-js, gozilliqa-sdk und pyzil sind laut Projekt nicht betroffen.

Zilliqa-Ledger-Lücke: Das Wichtigste

  • Betroffener Pfad: Native ZIL-Transaktionen, die mit der Zilliqa-App auf einem Ledger-Gerät signiert wurden.
  • Nicht betroffen: EVM-Transaktionen und die von Zilliqa ausdrücklich genannten Software Development Kits.
  • Risikoschwelle: Konten mit ungefähr fünf oder mehr veröffentlichten betroffenen Signaturen sollen als kompromittiert gelten.
  • Zeitraum: Der Fehler war laut Zilliqa seit 2019 in allen veröffentlichten Versionen der App auf unterstützten Geräten enthalten.
  • Reaktion: Native Transaktionen wurden ausgesetzt; eine korrigierte App und ein koordinierter Wiederherstellungsplan werden vorbereitet.
  • Wichtige Einschränkung: Ein App-Update verhindert neue schwache Signaturen, schützt aber keinen Schlüssel, der anhand alter Onchain-Daten bereits ableitbar ist.

Wie der Fehler private Schlüssel offenlegen kann

Native Zilliqa-Transaktionen verwenden EC-Schnorr-Signaturen auf der Kurve secp256k1. Für jede Signatur ist ein neuer, gleichmäßig zufälliger temporärer Wert nötig, der in der Kryptografie als Nonce bezeichnet wird. Dieser Nonce darf weder wiederverwendet noch vorhersagbar eingeschränkt sein. Sonst verraten mehrere Signaturen mathematische Informationen über den privaten Schlüssel.

Nach Zilliqas technischer Darstellung erzeugte die App zunächst 40 Byte Zufall und reduzierte sie korrekt auf einen 256-Bit-Wert. Beim Kopieren in den eigentlichen Nonce-Puffer wurden jedoch die falschen 32 Byte übernommen. Acht Byte Entropie gingen verloren, während acht Null-Byte erhalten blieben. Dadurch waren die höchsten 64 Bit jedes Nonce fest auf null gesetzt.

Diese Einschränkung ist keine bloße theoretische Qualitätsabweichung. Zilliqa zufolge kann ein Angreifer mit ungefähr fünf oder mehr betroffenen Signaturen den privaten Schlüssel auf handelsüblicher Hardware in Sekunden rekonstruieren. Dafür wird das sogenannte Hidden Number Problem über Gitterreduktion gelöst. Die erforderlichen Signaturen liegen dauerhaft öffentlich auf der Blockchain; ein späteres Software-Update kann diese historischen Daten nicht zurücknehmen.

Die Ursache unterscheidet sich von langfristigen Angriffen durch Quantencomputer. Unser Hintergrund zur Bitcoin-Quantenschutz-Initiative von Galaxy behandelt neue kryptografische Verfahren gegen ein künftiges Hardware-Risiko. Bei Zilliqa geht es dagegen um einen konkreten Implementierungsfehler in der heutigen Erzeugung klassischer Signaturen.

Wer von der Schwachstelle betroffen ist

Entscheidend ist nicht allein, ob jemand ein Ledger-Gerät besitzt. Betroffen ist nach der Mitteilung der native Signaturpfad der Zilliqa-Ledger-App. Ein Konto wird besonders kritisch, wenn damit ungefähr fünf oder mehr native ZIL-Transaktionen signiert und an die Blockchain gesendet wurden. Die veröffentlichten Signaturen reichen dann möglicherweise zur Schlüsselrekonstruktion aus.

ZIL-Nutzer, die ausschließlich EVM-kompatible Werkzeuge verwendet haben, fallen laut Zilliqa nicht unter diese Schwachstelle. Ebenso seien die genannten Entwicklerbibliotheken nicht betroffen, weil sie Nonces korrekt erzeugen. Diese Abgrenzung ist wichtig: Die Meldung belegt keinen allgemeinen Bruch des Zilliqa-Netzwerks, der secp256k1-Kurve oder aller Ledger-Geräte.

Warum Zilliqa native Transaktionen gestoppt hat

Zilliqa beobachtete nach eigenen Angaben am 19. Juli 2026 Onchain-Aktivität, die zu einer aktiven Ausnutzung passte. Am 21. Juli sei die Ursache im Nonce-Code isoliert und anhand von Onchain-Signaturen reproduziert worden. Das Projekt schreibt, KuCoin habe bei Ursachenanalyse, Schlüsselrekonstruktion und Bestätigung der aktiven Ausnutzung geholfen.

Der Stopp nativer Transaktionen soll weitere Abflüsse begrenzen, schafft aber ein schwieriges Wiederanlaufproblem. Sobald Transfers wieder möglich sind, könnte ein Angreifer mit einem bereits rekonstruierten Schlüssel eine legitime Transaktion überholen. Deshalb warnt das Projekt davor, betroffene Guthaben ohne abgestimmten Plan einfach selbst zu verschieben.

Dass Börsen Ein- und Auszahlungen in einem Sicherheitsfall vorübergehend aussetzen, schützt den betroffenen Übertragungsweg, kann aber zugleich den Zugriff einschränken. Unser unabhängiger Krypto-Börsenvergleich ordnet Verwahrung, Auszahlungsregeln und Sicherheitsreserven als getrennte Prüfpunkte ein. Er ersetzt keine fallbezogene Anweisung von Zilliqa oder einer genutzten Plattform.

Was Nutzer jetzt beachten sollten

  • Transaktionshistorie prüfen: Maßgeblich ist, ob native ZIL-Transaktionen mit der Zilliqa-App auf einem Ledger-Gerät signiert wurden.
  • Nicht vorschnell senden: Zilliqa rät betroffenen Nutzern, auf den koordinierten Plan zu warten. Ein unkoordinierter Transfer kann bei einem bereits bekannten Schlüssel abgefangen werden.
  • Keine Seed Phrase eingeben: Weder ein Update noch eine Wiederherstellung sollte die Eingabe der Seed Phrase auf einer Website, in einem Chat oder gegenüber angeblichem Support verlangen.
  • Offizielle Kanäle beobachten: Relevant sind die angekündigte korrigierte App, konkrete Migrationsschritte und die Freigabe nativer Transaktionen.
  • EVM und native ZIL trennen: Allgemeine Warnungen sollten nicht ohne Prüfung auf EVM-Transaktionen oder andere Ledger-Apps übertragen werden.

Diese Punkte dienen der Einordnung der veröffentlichten Sicherheitsinformation. Sie sind keine individuelle Empfehlung zur Übertragung, Verwahrung oder Veräußerung von ZIL. Wer eine Börse oder einen Verwahrer nutzt, sollte zusätzlich dessen offiziellen Status und Support-Hinweise prüfen, ohne sensible Schlüssel oder Wiederherstellungswörter offenzulegen.

Offene Fragen und Grenzen der Meldung

Zum Zeitpunkt der Recherche lag noch kein öffentlich bezifferter Gesamtschaden vor, der sich belastbar allein dieser Schwachstelle zuordnen ließ. Zilliqa nennt Aktivität, die mit einer Ausnutzung vereinbar sei, und bestätigt die technische Rekonstruktion betroffener Schlüssel. Daraus folgt nicht automatisch, dass jedes gefährdete Konto bereits geleert wurde.

  • Wie viele Adressen die Schwelle von ungefähr fünf betroffenen Signaturen erreichen, ist öffentlich noch nicht abschließend beziffert.
  • Details des koordinierten Plans zur Sicherung vorhandener Guthaben stehen noch aus.
  • Ein Termin für die Wiederaufnahme nativer Transaktionen war in den geprüften Quellen nicht genannt.
  • Die genaue Verantwortung zwischen App-Code, Prüfung und Auslieferungsprozess muss gegebenenfalls in einem späteren technischen Bericht aufgearbeitet werden.

Fazit zur Zilliqa-Ledger-Lücke

Die Zilliqa-Ledger-Lücke ist ein konkreter, sicherheitsrelevanter Implementierungsfehler: Zu wenig Zufälligkeit in den Nonces kann den privaten Schlüssel aus mehreren öffentlich gespeicherten Signaturen ableitbar machen. Der Transaktionsstopp begrenzt akute Bewegungen, löst aber nicht das Problem bereits gefährdeter Schlüssel.

Für Betroffene zählt deshalb die genaue Abgrenzung des verwendeten Signaturpfads und der angekündigte koordinierte Wiederherstellungsplan. Nicht betroffen sind nach aktuellem Stand EVM-Transaktionen und die ausdrücklich genannten SDKs. Stand der Recherche ist der 23. Juli 2026, 00:32 Uhr CEST. Neue technische Details oder konkrete Migrationsschritte können diese Einordnung verändern.

Quellen

Diskussion

0 Kommentare

Teile deine Einschätzung. Bitte bleibe sachlich und respektvoll.

Für diesen Beitrag sind keine Kommentare möglich.

Wöchentliches Briefing

Bleibe informiert

Erhalte wöchentliche Crypto-News direkt in dein Postfach.