~$4M verloren: Taiko, SecondFi Exploits

In der vergangenen Woche (2026/06/22 - 2026/06/28) wurden 2 nennenswerte Sicherheitsvorfälle identifiziert, die zu bestätigten Verlusten von insgesamt ca. 4,1 Mio. USD führten.

Datum	Vorfall	Typ	Geschätzter Verlust
2026/06/22	Taiko	Schlüsselkompromittierung & Unzureichende Validierung	~1,7 Mio. USD
2026/06/23	SecondFi	Kryptografischer Implementierungsfehler	~2,4 Mio. USD

Taiko: Der Angreifer kombinierte einen exponierten SGX-Enklave-Signierschlüssel mit einer unvollständigen Attestierungsrichtlinie, um einen bösartigen Prover als autorisierte Instanz zu registrieren. Dies zeigt, dass eine gültige Attestierung allein ohne umfassende Attributdurchsetzung unzureichend ist.
SecondFi: Ein kryptografischer Implementierungsfehler ermöglichte es Angreifern, adressbezogene Signierschlüssel ausschließlich anhand öffentlicher Transaktionsdaten wiederherzustellen. Dies verdeutlicht, wie eine scheinbar geringfügige Abweichung von der Ed25519-Spezifikation zu einer vollständigen Schlüsselkompromittierung führen kann.

Wöchentliches Highlight: Taiko-Vorfall

Der Taiko-Vorfall wird hervorgehoben, weil der Angriff zwei unabhängige Sicherheitsfehler kombinierte (einen exponierten Enklave-Signierschlüssel und eine unvollständige Attestierungsrichtlinie), um ein SGX-basiertes Beweisverifizierungssystem zu kompromittieren. Der Vorfall zeigt, dass jede Schicht einer TEE-Vertrauenskette ihre Sicherheitseigenschaften unabhängig durchsetzen muss; eine gültige Attestierungssignaturkette kompensiert nicht für ungeprüfte Laufzeitattribute.

Am 22. Juni 2026 wurde Taikos SGX-basierter Beweisverifizierungsablauf auf Ethereum ausgenutzt, was zu Verlusten von ca. 1,7 Mio. USD führte [1]. Der Angreifer verwendete einen exponierten privaten Enklave-Signierschlüssel, der in ein öffentliches GitHub-Repository eingecheckt worden war, um die SIGSTRUCT für eine im DEBUG-Modus gestartete Prover-Enklave zu signieren. Da der On-Chain-Attestierungsvertrag DEBUG-Enklaven nicht ablehnte, registrierte sich der Angreifer als autorisierte Instanz, übermittelte gefälschte Beweisdaten und veranlasste die L1-Verträge, einen nicht existierenden L2-Zustand zu akzeptieren und Bridge-Gelder freizugeben.

Hintergrund

Taiko ist ein Ethereum Layer-2-Rollup mit einer Bridge, die auf ein Beweissystem angewiesen ist, um zu entscheiden, ob ein gegebener L2-Zustand oder eine Cross-Chain-Nachricht akzeptiert werden soll. Als Teil dieses Beweissystems verwendet Taiko SGX-Prover: Off-Chain-Programme, die innerhalb von SGX-Enklaven auf physischen Maschinen laufen und Beweisergebnisse mit durch die Enklave geschützten Schlüsseln signieren.

Off-Chain (physische Maschine)              On-Chain (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Prover Enklave     │                │  SgxVerifier                       │
│  - generiert Beweise    │── DCAP Quote ─→│  ├─ registerInstance()             │
│  - hält Instanzschlüssel│                │  │  └─ AutomataDcapV3Attestation   │
│                         │── sign. Beweis→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX & DCAP – Überblick

Das zentrale SGX-Konzept ist die Enklave: eine durch die CPU isolierte Programmumgebung. MRENCLAVE ist die Messung des initialen Codes, der Daten, des Seitenlayouts und verwandter Metadaten der Enklave; es kann als Hash des Enklave-Builds angenähert werden. MRSIGNER ist der Hash des öffentlichen Enklave-Signierschlüssels und repräsentiert die Identität des Herausgebers.

Der private Enklave-Signierschlüssel signiert die SGX-SIGSTRUCT, die Enklave-Metadaten wie MRENCLAVE, ISVPRODID, ISVSVN und ATTRIBUTES enthält. Diese Signatur wird nicht vom On-Chain-Vertrag verifiziert; sie wird von der SGX-Hardware während der EINIT-Phase bei der Initialisierung der Enklave überprüft. Die CPU prüft, ob die SIGSTRUCT-Signatur gültig ist und ob die darin enthaltene MRENCLAVE mit der Messung der tatsächlich geladenen Enklave übereinstimmt. Erst nachdem diese Überprüfung erfolgreich ist, kann die Enklave initialisiert werden und nachfolgende Reports und Quotes erzeugen.

Ein Intel SGX DCAP v3 Quote ist ein Remote-Attestierungspaket, das drei Teile enthält:

header: Metadaten wie die Quote-Version, der Attestierungsschlüsseltyp, QE/PCE SVN und der Anbieter.
localEnclaveReport: die Identität der attestierten Anwendungsenklave, einschließlich MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN und reportData. reportData ist ein 64-Byte-Wert, der von der Enklave beim Generieren des Reports geschrieben wird. Taiko speichert die Prover-Instanzadresse in den ersten 20 Bytes von reportData.
v3AuthData: Authentizitätsnachweis für den Quote, einschließlich der Quote-Signatur, des Attestierungsschlüssels, des QE-Reports, der QE-Report-Signatur und der PCK-Zertifikatskette.

On-Chain-Attestierung

Der On-Chain-Attestierungsvertrag (AutomataDcapV3Attestation, zuständig für die Remote-Attestierung) validiert die Authentizität des Quotes über die Intel DCAP-Zertifikatskette. Obwohl die Aussteller-Public-Keys in der Zertifikatskette als Teil des extern eingereichten Quotes übermittelt werden, verifiziert der Vertrag die Kette Schritt für Schritt und verlangt, dass der Hash des endgültigen Aussteller-Public-Keys mit dem im Vertrag fest kodierten Hash des Intel SGX Root CA-Public-Keys übereinstimmt [2]. Durch diese Kette bestätigt der Vertrag, dass der vom Quote-Signatur abgedeckte localEnclaveReport nicht beliebig in den Calldata geändert wurde.

Taiko Prover-Registrierung

Eine SGX-Prover-Instanz muss zunächst über SgxVerifier.registerInstance() registriert werden. Während der Registrierung übermittelt der Aufrufer einen DCAP-Quote. SgxVerifier delegiert die Quote-Validierung an AutomataDcapV3Attestation.verifyParsedQuote(). Wenn der Quote die Prüfung besteht, liest SgxVerifier die ersten 20 Bytes von localEnclaveReport.reportData als Instanzadresse und fügt diese dem autorisierten Instanzsatz hinzu.

Der Signaturverifizierungsablauf lässt sich in drei Schichten vereinfachen:

Die SGX-CPU verifiziert die SIGSTRUCT-Signatur während EINIT und bestätigt die MRENCLAVE der Enklave sowie die Signeridentität.
Die DCAP-Zertifikatskette und der QE-Report authentifizieren den Quote-Signierschlüssel. AutomataDcapV3Attestation verwendet diesen Schlüssel dann zur Verifizierung der Quote-Signatur und stellt das Vertrauen in localEnclaveReport her.
Taikos Beweisverifizierer verwendet die registrierte Instanzadresse, um spätere Beweissignaturen zu verifizieren und zu entscheiden, ob der entsprechende L2-Zustand oder die Cross-Chain-Nachricht akzeptiert werden soll.

Schwachstellenanalyse

Die Grundursache dieses Vorfalls ist eine Kombination aus einem operativen Fehler und einer Schwachstelle auf Vertragsebene. Beide waren notwendig, damit der Angriff gelingen konnte.

Operativer Fehler: exponierter Enklave-Signierschlüssel. Der von Taiko/Raiko zum Signieren von SGX-SIGSTRUCT verwendete private Enklave-Signierschlüssel wurde in ein öffentliches GitHub-Repository eingecheckt. MRSIGNER ist der Hash des entsprechenden öffentlichen Signierschlüssels. Jeder, der diesen privaten Schlüssel erhält, kann eine SIGSTRUCT einer Prover-Enklave signieren und dafür sorgen, dass die MRSIGNER im resultierenden Quote mit Taikos Allowlist übereinstimmt.

Vertragsschwachstelle: fehlende ATTRIBUTES-Prüfung. Mit einer übereinstimmenden MRSIGNER (Bestehen der Allowlist durch den exponierten Schlüssel) konnte der Angreifer dieselbe genehmigte Enklave im DEBUG-Modus starten, ohne MRENCLAVE zu ändern (das DEBUG-Flag ist kein Bestandteil von MRENCLAVE). Die Attestierungsrichtlinie hätte dies erkennen müssen, aber AutomataDcapV3Attestation (0x5e46...dd72) überprüfte die localEnclaveReport.attributes der Anwendungsenklave nicht. Eine DEBUG-Enklave erlaubt es dem Host oder Debugger, den Enklavespeicher zu lesen oder zu modifizieren, was bedeutet, dass der Instanz-Signierschlüssel, der durch die SGX-Enklave hätte geschützt sein sollen, nicht mehr sicher ist.

Zusammen bedeuten diese beiden Bedingungen, dass jede Partei denselben Prover-Enklave-Code im DEBUG-Modus starten kann (was dieselbe MRENCLAVE wie der legitime Build erzeugt) und mit dem exponierten Signierschlüssel eine SIGSTRUCT signieren kann, die MRSIGNER mit Taikos Allowlist übereinstimmen lässt. Der resultierende Quote erfüllt sowohl die MRENCLAVE- als auch die MRSIGNER-Allowlists, trägt dabei aber das ungeprüfte DEBUG-Attribut. Da AutomataDcapV3Attestation das DEBUG-Attribut nicht ablehnt, besteht ein solcher Quote verifyParsedQuote(), woraufhin SgxVerifier die Instanzadresse im autorisierten Instanzsatz registriert.

Eine Enklave im DEBUG-Modus schützt ihren Speicher nicht vor dem Host oder Debugger. Der innerhalb der Enklave generierte private Instanzschlüssel kann daher extrahiert werden. Mit diesem Schlüssel kann der Inhaber beliebige Beweisdaten signieren, die die L1-Verträge akzeptieren würden, was gefälschte L2-Zustandsübergänge und die unbefugte Freigabe von Bridge-Geldern aus dem Vault ermöglicht (0x9962...15ab).

Angriffsanalyse

Der Angreifer übermittelte mehrere Transaktionen. Die folgende Analyse basiert auf zwei repräsentativen Transaktionen: Die erste registrierte den Angreifer als autorisierte Instanz (0x2f44dc...277260), und die zweite führte den gefälschten Beweis aus, um Vermögenswerte zu stehlen (0x017292...ae35ee).

Schritt 1: Den exponierten Enklave-Signierschlüssel verwenden, um SIGSTRUCT zu signieren und die MRSIGNER des Quotes mit der Allowlist übereinstimmen zu lassen.
Schritt 2: Die Enklave mit dem DEBUG-Attribut ausführen. DEBUG ändert MRENCLAVE nicht, wird aber in localEnclaveReport.attributes widergespiegelt.
Schritt 3: registerInstance() aufrufen und einen echten SGX-Quote übermitteln. Der Quote hatte attributes = 0x07..., was das DEBUG-Bit (0x02) enthält, aber AutomataDcapV3Attestation prüfte dieses Feld nicht, sodass verifyParsedQuote() true zurückgab.

Schritt 4: Den privaten Instanzschlüssel aus dem SGX-Enklavespeicher extrahieren (möglich, da der DEBUG-Modus den Speicherschutz deaktiviert) und damit bösartige Beweisdaten signieren.
Schritt 5: Den präparierten Beweis übermitteln, damit die L1-Verträge einen nicht existierenden L2-Zustand akzeptieren und Vermögenswerte aus dem Vault stehlen.

Fazit

Eine vollständige SGX-Attestierungsrichtlinie sollte mindestens:

SGX_FLAGS_DEBUG in Produktionsdeployments ablehnen.
MRENCLAVE, MRSIGNER, ISVPRODID und ISVSVN prüfen.

Wenn DEBUG-Quotes akzeptiert werden, kann die Hardware zwar noch korrekt funktionieren, sie bietet aber nicht mehr die erwarteten Speicherschutzeigenschaften. Enklave-Signierschlüssel dürfen außerdem niemals in öffentliche Repositories eingecheckt werden. Ein exponierter Signierschlüssel erlaubt es jeder Partei, Binärdateien mit einer übereinstimmenden MRSIGNER zu erstellen, was die verbleibenden Hürden der Attestierungsrichtlinie auf MRENCLAVE und die Attributdurchsetzung reduziert.

Allgemeiner gilt: Für jedes System, das auf TEEs angewiesen ist, kann die Attestierung nicht damit enden, zu bestätigen, dass die Signaturkette gültig und die Messung in der Allowlist ist. Jede Schicht der Vertrauenskette muss ihre Sicherheitseigenschaften unabhängig durchsetzen.

Referenzen

[1] Phalcon Alert: Erkennung des Taiko Bridge-Exploits
[2] Intel SGX Entwicklerhandbuch

Weitere Vorfälle dieser Woche

SecondFi-Vorfall

Am 23. Juni 2026 gab SecondFi (ehemals Yoroi), eine von EMURGO entwickelte Cardano-Wallet, eine kritische Schwachstelle in seiner Ed25519-Signierungsimplementierung bekannt [1]. Die Signierungsimplementierung der Wallet berechnete die Signierungsnonce ausschließlich aus der öffentlichen Transaktionsnachricht, wobei ein erforderlicher geheimer Eingabewert weggelassen wurde. Dies reduzierte die digitale Signatur auf ein Einzel-Gleichungsproblem und ermöglichte es Angreifern, private Schlüssel auf Adressebene aus öffentlichen On-Chain-Daten wiederherzustellen. Zwei separate Angreifer nutzten die Schwachstelle aus und entleerten ca. 2,4 Mio. USD (16 Mio. ADA) aus 374 Wallets [2].

Hintergrund

SecondFi ist eine Self-Custody-Wallet für die Cardano-Blockchain, die im April 2026 von Yoroi umbenannt wurde. Ursprünglich von EMURGO entwickelt, einer der drei Gründungseinheiten von Cardano, hatte Yoroi zuvor über eine Million Nutzer.

Ed25519 ist das von Cardano für die Transaktionsautorisierung verwendete digitale Signaturverfahren. Der Unterzeichner hält einen Signierschlüsselskalar $k_{L}$ (den privaten Schlüssel für eine bestimmte Adresse) und ein geheimes Nonce-Präfix $k_{R}$ , das mit demselben Schlüsselmaterial verknüpft ist. Für eine gegebene Nachricht $M$ (die Transaktionsnutzlast) wird die Signierungsnonce berechnet als $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ . Da $k_{R}$ geheim ist, bleibt $r$ für Beobachter unbekannt, auch wenn $M$ nach der Übertragung öffentlich ist.

Der Nonce-Punkt $R = r \cdot B$ (wobei $B$ der feste Ed25519-Basispunkt ist) und der Signaturskalar $s \equiv r + H \cdot k_L \pmod{L}$ (wobei $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ Nonce, öffentlichen Schlüssel und Nachricht bindet) bilden die endgültige Signatur $(R, s)$ . Die Sicherheit des Verfahrens hängt davon ab, dass $r$ unvorhersehbar ist: Wenn ein Beobachter $r$ berechnen kann, wird die Signaturgleichung zu einer linearen Gleichung mit einer Unbekannten, die nach $k_{L}$ lösbar ist.

Schwachstellenanalyse

Diese Schwachstelle befindet sich in der Wallet-Signiersoftware von SecondFi, nicht in einem Smart Contract.

Durch Kombination bestehender Analysen [2] mit unserer eigenen Untersuchung stellten wir fest, dass die Versionen v10.0.3 bis v10.0.6 (live seit 8. Juni 2026; behoben in v10.0.6.2) betroffen sind. Die fehlerhafte Implementierung berechnete die Signierungsnonce als:

r = \operatorname{SHA-512}(M) \bmod L

anstatt des korrekten:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

Dadurch wurde der einzige geheime Eingabewert ( $k_{R}$ ) aus der Nonce-Ableitung entfernt. Da $M$ öffentlich ist, kann jeder $r$ für jede von einer betroffenen Adresse signierte Transaktion neu berechnen.

Mit bekanntem $r$ wird die Signaturgleichung $s \equiv r + H \cdot k_L \pmod{L}$ lösbar:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

Alle Werte auf der rechten Seite sind entweder öffentlich oder aus der On-Chain-Signatur und den Transaktionsdaten berechenbar. Dies ist kein Umkehren eines Hashes oder Lösen des diskreten Logarithmus aus $A = k_L \cdot B$ ; die fehlerhafte Implementierung hat $r$ direkt exponiert und die Schlüsselwiederherstellung auf einfache modulare Arithmetik reduziert.

Die Auswirkung ist eine adressbezogene Schlüsselkompromittierung. Jede Adresse, die eine Signatur durch die fehlerhafte Implementierung erzeugt hat, sollte als kompromittiert betrachtet werden.

Das Importieren derselben Mnemonik in eine gepatchte Wallet schützt die bereits exponierte Adresse nicht; Gelder müssen auf einen neu generierten Schlüssel übertragen werden, der niemals durch die fehlerhafte Signierungsimplementierung signiert hat.

Angriffsanalyse

Dieser Angriff folgt keiner typischen On-Chain-Exploit-Sequenz mit nachverfolgbaren Smart-Contract-Interaktionen. Da die Schwachstelle eine deterministische Beziehung zwischen öffentlichen Daten und dem Signierschlüssel offenlegt, wird die Schlüsselwiederherstellung offline durchgeführt.

Schritt 1: Zieladressen identifizieren, die Transaktionen mit SecondFi v10.0.3 bis v10.0.6 signiert haben.
Schritt 2: Für jedes Ziel die öffentlichen Signaturkomponenten der Transaktion ( $R$ , $s$ ) abrufen und die Nachricht $M$ aus der On-Chain-Transaktionsnutzlast rekonstruieren.
Schritt 3: Die Signierungsnonce $r = \operatorname{SHA-512}(M) \bmod L$ berechnen, unter Ausnutzung der Tatsache, dass die fehlerhafte Signierungsimplementierung das geheime Nonce-Präfix $k_{R}$ weggelassen hat.
Schritt 4: Den Challenge-Skalar $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ berechnen.
Schritt 5: Den Signierskalar lösen: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Schritt 6: Das wiederhergestellte $k_{L}$ verwenden, um beliebige Transaktionen von der kompromittierten Adresse zu signieren und Gelder auf vom Angreifer kontrollierte Wallets zu übertragen.

Zwei separate Angreifer nutzten diese Schwachstelle unabhängig voneinander aus. Einer kompromittierte 171 Wallets in zwei Wellen, während ein zweiter 203 Wallets in einer separaten Aktion entleerte und zusammen ca. 16 Mio. ADA (~2,4 Mio. USD) extrahierte [2]. EMURGO rettete anschließend weitere 129 Mio. ADA, bevor die Angreifer diese Gelder erreichen konnten.

Fazit

Die Grundursache war ein kryptografischer Implementierungsfehler, der das geheime Nonce-Präfix aus der Ed25519-Nonce-Ableitung entfernte und die Signierungsnonce auf eine deterministische Funktion öffentlicher Daten reduzierte. Jede betroffene Signatur wurde zu einem Schlüsselwiederherstellungsproblem mit einer Gleichung.

Dieser Vorfall unterstreicht, dass Wallet-Entwickler gut geprüfte, standardisierte Ed25519-Bibliotheken anstelle von benutzerdefinierten Signierungsimplementierungen verwenden sollten. Jede Abweichung von der Spezifikation, selbst eine scheinbar geringfügige wie das Weglassen eines einzelnen Hash-Eingabewerts, kann den gesamten Schlüssel kompromittieren. Produktive Signiersoftware sollte vor dem Deployment einem unabhängigen kryptografischen Audit unterzogen werden, insbesondere bei der Handhabung von Schlüsselableitungs- und Signieroperationen.

Referenzen

[1] SecondFi Post-Incident-Offenlegung
[2] Tibane Labs: SecondFi Cardano Forensische Analyse

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchains und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert und dabei mehr als 20 Millionen Dollar gerettet sowie Kryptowährungen im Wert von Milliarden gesichert.