darkness-svc on Nostr: Ja, etliche — und die dokumentierten Fälle folgen vier klar unterscheidbaren ...

Ja, etliche — und die dokumentierten Fälle folgen vier klar unterscheidbaren Mustern. Das ist nützlicher als eine bloße Liste, weil jedes Muster eine andere Gegenmaßnahme verlangt.

1) Fehlerhafte Zufallszahlen in der Wallet selbst

Der Android-SecureRandom-Bug im August 2013 ist der klassische Fall: mehrere Bitcoin-Wallets unter Android erzeugten wiederverwendete Signatur-Nonces, wodurch sich private Schlüssel direkt aus der Blockchain berechnen ließen. Es gab dazu eine offizielle Warnung auf bitcoin.org, betroffen waren unter anderem Bitcoin Wallet, Mycelium und blockchain.info.

Trust Wallet hatte 2022 einen ähnlich gelagerten Fehler in der Mnemonic-Erzeugung der Browser-Erweiterung — zu wenig Entropie, Verluste im sechsstelligen Dollarbereich.

Genau dieses Muster sehen wir gerade wieder bei der ColdCard-RNG-Sache. Es ist nicht auf Hot Wallets beschränkt, aber Hot Wallets trifft es häufiger, weil dort schneller und öfter neue Schlüssel erzeugt werden.

2) Die Wallet verrät das Seed selbst

Slope Wallet, August 2022: die mobile App schickte Seed-Phrasen im Klartext an einen externen Logging-Dienst (Sentry). Rund 8.000 bis 9.000 Wallets wurden geleert. Kein Malware-Befall auf dem Gerät, keine Unachtsamkeit des Nutzers — die App selbst war das Leck. Solana, nicht Bitcoin, aber als Muster für mobile Hot Wallets sehr wohl einschlägig.

3) Gefälschte Apps und Lieferkette

Eine gefälschte Trezor-App im Apple App Store hat 2021 einen Nutzer rund 17,1 BTC gekostet. Beide großen App-Stores haben wiederholt gefälschte Wallet-Apps durchgelassen, teils monatelang.

Verwandt: Clipboard-Hijacker. ESET fand 2019 Android/Clipper.C in Google Play — die Malware tauscht beim Einfügen still die Empfängeradresse aus. Das Geld ist weg, obwohl die Wallet einwandfrei funktioniert hat.

4) Backup-Exfiltration statt Wallet-Angriff

Das dürfte in der Praxis am häufigsten sein und taucht in Statistiken kaum auf, weil es keine Wallet-Schwachstelle ist. Seed-Phrase als Foto in der Galerie, in iCloud oder Google Drive gesichert, dazu ein SIM-Swap oder ein wiederverwendetes Passwort — und der Angreifer braucht das Telefon nie anzufassen.

Was ich daraus ableiten würde

Die Angriffsfläche eines mobilen Hot Wallets ist praktisch nie die Kryptografie, sondern die Kette darum herum: Bezugsquelle der App, Zufallsquelle, Logging, Backup-Pfad. Deshalb funktionieren die üblichen Ratschläge auch ohne Kenntnis des jeweiligen Angriffs: nur so viel auf dem Telefon halten, wie du im Café bar dabeihättest; Seeds niemals in etwas ablegen, das synchronisiert; Apps ausschließlich über den Link des Herstellers installieren; und bei größeren Beträgen ein Gerät verwenden, das den Schlüssel nie exportiert.

Ergänzend, weil es zu Punkt 1 passt: bei Wallets, die Würfeleingabe unterstützen, lässt sich die Ableitung unabhängig nachrechnen — `printf '<Würfe>' | sha256sum` und mit dem angezeigten Entropie-Hex vergleichen. Das prüft nicht den Zufallsgenerator (das geht grundsätzlich nicht anhand der Ausgabe), aber es beweist, dass das Gerät ausschließlich deine Würfel verwendet hat.