Dein Geld sollte nicht an einem einzigen Schlüssel hängen

Ein Schlüssel kann alles ausgeben

Die meisten fangen mit Self-Custody bei einer Singlesig-Wallet an. Eine Seed Phrase, ein privater Schlüssel, ein Gerät. Das ist einfach, und einfach ist gut. Es heißt aber auch, dass ein passender Schlüssel reicht, um alles auszugeben, was die Wallet schützt.

Das ist ein bisschen wie Bargeld. Wer die Scheine in der Hand hat, kann sie ausgeben. Keiner fragt, ob du das wirklich bist. Bei einer Seed Phrase ist es genauso, nur kann man die Scheine kopieren, ohne dass du es merkst, und die Kopie ist genau so viel wert wie das Original.

Deshalb habe ich auf X geschrieben, dass Multisig, am besten mit verschiedenen Herstellern, zum Standard für Self-Custody werden muss. Nicht weil ein Gerät schlecht ist. Sondern weil eine gestohlene Seed nicht den Totalverlust bedeuten darf.

Gerät weg ist nicht gleich Schlüssel weg

Geht nur das Gerät kaputt, kann ein brauchbares Backup den Zugang zurückholen. Geht nur das Papier mit der Seed Phrase verloren, sind die Bitcoin nicht automatisch weg, solange es noch irgendwo einen nutzbaren Schlüssel gibt.

Gerät verloren, Backup verloren und Schlüssel gestohlen sind drei verschiedene Probleme. Die werden ständig verwechselt, und dann schützt man sich gegen das falsche. Ein zweites Gerät in der Schublade hilft beim ersten Problem. Beim dritten hilft es gar nicht.

Eine gestohlene Seed braucht dein Gerät nicht

Anders sieht es aus, wenn jemand die ganze Seed Phrase bekommt und keine zusätzliche unbekannte Passphrase nötig ist. Dann kann der Angreifer die Schlüssel einfach auf einem anderen Gerät wiederherstellen. Er muss weder deine Hardware-Wallet entsperren noch an ihrem Sicherheitschip vorbei.

Die ganze Mühe, die in das Gerät geflossen ist, Secure Element, PIN, Siegel auf der Packung, zählt in dem Moment nicht mehr. Die Seed ist die Wallet. Das Gerät ist nur ein Ort, an dem sie benutzt wurde.

An dieser Stelle höre ich auf, über bessere Geräte nachzudenken, und fange an, über mehr als einen Schlüssel nachzudenken.

Kopien sind keine unabhängigen Schlüssel

Bei einem einfachen 2-von-3-Multisig gibt es drei verschiedene Schlüssel, und zwei davon müssen dieselbe Transaktion freigeben. Ein gestohlener Schlüssel reicht nicht. Fällt einer aus, können die anderen beiden weiter unterschreiben. Die Sicherheit kommt nicht daher, dass ein Schlüssel schwerer zu stehlen ist. Sie kommt daher, dass der erste erfolgreiche Angriff noch nicht reicht.

Das ist was anderes als mehrere Kopien derselben Seed. Drei Geräte mit demselben Schlüssel helfen vielleicht bei der Verfügbarkeit, sind aber keine drei unabhängigen Signierer. Wer eine Kopie hat, hat die ganze Macht dieser Singlesig-Wallet.

Ich glaube, das ist das häufigste Missverständnis. Man macht drei Kopien und fühlt sich dreimal so sicher. Gegen Verlust vielleicht. Gegen Diebstahl ist jede Kopie ein Ort mehr, an dem die ganze Wallet geklaut werden kann.

Unabhängige Signierer dürfen nicht am selben Fehler hängen

Unter meinem Post kam der Einwand, warum man bei möglichen Hintertüren in Hardware-Wallets einfach noch mehr Hardware kaufen sollte. Die Frage ist fair. Mehr Geräte allein lösen das Problem nicht.

Wenn mehrere Signierer dieselbe fehlerhafte Firmware oder dieselbe kompromittierte Abhängigkeit nutzen, kann ein Angriff mehrere Schlüssel auf einmal treffen. Verschiedene Hersteller können das verringern, aber auch verschiedene Marken teilen manchmal Bauteile oder Software. Zwei Logos sind kein Beweis. Es zählt, ob der Fehler, der den ersten Signierer trifft, auch den zweiten erwischt.

Dass das keine reine Theorie ist, zeigt ein Fall, den Ledger selbst bestätigt hat. Ein nicht autorisiertes Hardware-Implantat in einem betroffenen Gerät, in der Mitteilung wird ein Reseller genannt. Ein Implantat heißt nicht automatisch, dass ein Schlüssel ausgelesen wurde, aber dass ein gekauftes Gerät unverändert bei dir ankommt, ist eine Annahme und kein Fakt.

Darum vertraue ich verschiedenen Arten von Signierern mehr als mehr vom Gleichen. Eine Hardware-Wallet, ein Telefon, ein Server, der nach eigenen Regeln signiert, ein Schlüssel an einem anderen Ort.

Auch mehrere Unterschriften können denselben Fehler bestätigen

Multisig schützt nicht automatisch vor einer falschen Zahlung, die alle nötigen Signierer freigeben. Eine manipulierte Wallet-Oberfläche könnte zum Beispiel eine andere Zieladresse in die Transaktion schreiben. Wenn jeder Signierer nur dieselbe irreführende Anzeige übernimmt, können mehrere gültige Unterschriften am Ende die falsche Zahlung autorisieren.

Die Antwort sind nicht mehr Unterschriften. Die Antwort sind Signierer, die selbst hinschauen. Eine Hardware-Wallet, die die Adresse auf ihrem eigenen Display zeigt. Ein Co-Signer, der Limits oder ungewöhnliche Muster prüft, statt alles zu unterschreiben, was der Client schickt. Ein Mensch, der Betrag und Empfänger liest, bevor er bestätigt.

Dieser letzte Blick bleibt beim Nutzer, den nimmt ihm kein Design ab. Wer einen falschen Empfänger bestätigt, hat trotzdem echt bestätigt. Kein Single Point of Failure ist eine Anforderung an das ganze System, auch an diesen letzten Blick.

Diebstahlschutz und Verfügbarkeit sind zwei verschiedene Aufgaben

Ein 2-von-2-Modell kann einen einzelnen gestohlenen Schlüssel nutzlos machen. Beide Schlüssel werden gebraucht. Genau diese Regel heißt aber auch, wenn einer fehlt, gibt es erstmal keine Zahlung.

Ein Anbieter, der allein nicht stehlen kann, könnte den normalen Zahlungsweg trotzdem blockieren, indem er einfach nicht mehr mitsigniert. Das kann Absicht sein, aber auch ein Serverausfall oder das Ende der Firma.

Eine selbstverwahrte Wallet muss deshalb zwei Fragen beantworten. Warum kann der Anbieter mein Geld nicht allein bewegen? Und wie bewege ich es, wenn der Anbieter weg ist? Für die zweite Frage braucht es einen Ausgabepfad, der vorher festgelegt wurde und den Anbieter nie um Erlaubnis fragt. Wie eine Zeitsperre das machen kann, kommt weiter unten.

Muun zeigt, wie Alltag und Notfall getrennt werden können

Ich habe in meinen Posts auf Muun und Blockstream Green als Ideenquellen verwiesen. Muun beschreibt sein Modell ganz konkret. Im Alltag unterschreiben das Telefon und der Muun-Server zusammen. Das Telefon hält nicht beide unverschlüsselten Schlüssel.

Für den Notfall gibt es ein Emergency Kit mit verschlüsselten Schlüsseln und den Informationen zur Wiederherstellung. Der passende Recovery Code wird getrennt aufbewahrt. Der normale Zahlungsweg ist bequem, und der Notfallweg soll ohne die tägliche Mitarbeit des Anbieters auskommen.

Das zeigt, dass Multisig nicht mehrere Gerätebestätigungen pro Zahlung heißen muss. Es kann sich wie eine App anfühlen. Die eigentliche Arbeit steckt im Notfallweg. Nuri teilt dieselbe Alltagsidee von Nutzer plus Server, nur liegt der Nutzerschlüssel hinter einem Passkey statt in einem Kit mit Code. Eine gemeinsame Idee macht aus zwei Produkten noch nicht dasselbe.

Ein Passkey ist nicht einfach eine versteckte Seed Phrase

Ein normaler Passkey ist erstmal zum Anmelden da. Er weist einer Website kryptografisch nach, dass du das passende Zugangsmittel hast. Weil er an diese Website gebunden ist, kann eine nachgebaute Login-Seite ihn nicht einfach abgreifen wie ein abgetipptes Passwort.

Eine Seed Phrase ist ein Geheimnis, das du aufschreiben, aufbewahren und nie an der falschen Stelle eintippen darfst. Einen Passkey hält ein Authenticator, also ein Telefon, ein Passwortmanager oder ein Hardware-Schlüssel, und er kann über den Anbieter, den du gewählt hast, auf ein neues Gerät kommen. Mit der WebAuthn-PRF-Erweiterung kann derselbe Passkey außerdem ein festes Geheimnis liefern. Dieselbe Eingabe gibt immer dieselben 32 Bytes zurück, und daraus kann eine Wallet lokal einen Schlüssel ableiten.

Das hat Grenzen. Schutz vor gefälschten Login-Seiten macht nicht jede danach angezeigte Transaktion richtig. Eine kompromittierte echte Website oder ein kompromittiertes Gerät sind eigene Probleme. PRF muss vom jeweiligen Browser und Authenticator unterstützt werden. Und ein kompromittiertes Passkey-Konto bleibt ein echtes Risiko. Ein Passkey macht einen Schlüssel leichter aufzubewahren. Einen zweiten Schlüssel macht er daraus nicht.

MuSig2 macht gemeinsame Kontrolle weniger sichtbar

Mehrere Signierer müssen auf der Blockchain nicht wie mehrere Signaturen aussehen. Mit MuSig2 können sie zusammen eine gültige Schnorr-Signatur erzeugen. Ihre Schlüssel werden zu einem Taproot-Schlüssel zusammengefasst, und eine normale Ausgabe über den Key Path sieht aus wie die Signatur eines einzelnen Signierers.

Das hilft bei Größe und Privatsphäre. Die Sicherheit kommt trotzdem daher, dass die Beteiligten zusammenarbeiten, nicht von der Zahl der Signaturen, die man onchain sieht.

Eine technische Unterscheidung ist dabei wichtig. MuSig2 braucht nach BIP 327 alle Signierer einer Schlüsselaggregation. Allein ist es weder ein 2-von-3-System noch ein Weg zur Wiederherstellung. Andere Pfade muss die Wallet selbst festlegen, zum Beispiel über zusätzliche Taproot-Skriptpfade. Genau da setzt der nächste Teil an.

Co-Signer, die nach Plan verfallen

In meinen Posts habe ich Co-Signer beschrieben, die mit der Zeit überflüssig werden. Technisch verschwinden ihre Schlüssel nicht. Ein vorher festgelegter zweiter Ausgabepfad wird nutzbar. Bitcoin kann das mit einer relativen Zeitsperre, CHECKSEQUENCEVERIFY aus BIP 112. Die Zeit läuft ab dem Moment, in dem der Output bestätigt ist.

Die Form ist einfach. Im Alltag unterschreiben alle zusammen. Daneben gibt es einen Pfad, auf dem nach einer festen Zahl von Blöcken der Nutzerschlüssel allein reicht. Man kann auch mehrere Stufen bauen, bei denen ein Signierer nach dem anderen wegfällt. Wichtig ist die Richtung. Die Schwellen werden nur zum Nutzer hin kleiner, nie von ihm weg.

Das verändert die Sicherheitsannahme, und das will ich klar sagen. Sobald der Nutzerschlüssel allein reicht, kann auch ein Angreifer mit diesem Schlüssel den Pfad nutzen. Solange der Co-Signer im Skript steht, schützt er. Nach der Verzögerung ist dieser Schutz weg. Fristen, Schlüsselverlust und reifende Outputs muss man zusammen anschauen.

Wiederherstellung braucht mehr als ein Geheimnis

Bei komplexeren Bitcoin-Wallets muss die Recovery-Software auch wissen, welche Schlüssel und Ausgaberegeln zusammengehören. Output Descriptors beschreiben solche Konstruktionen, mit öffentlichen Schlüsseln, Ableitungspfaden und der Struktur der Ausgabebedingungen.

Wer nur seinen privaten Schlüssel wiederherstellt, hat noch nicht alles, um den richtigen Multisig- oder Taproot-Output auszugeben. Das Recovery-Projekt von Nuri nennt genau diese Grenze und trennt Schlüsselableitung, öffentliche Recovery-Daten, die Suche nach Outputs und das Senden einer Transaktion.

Ein Descriptor kann private Finanzinformationen verraten. Darum gehört er in ein verschlüsseltes Backup und nicht als Klartext irgendwohin. Aber gesichert werden muss er, und zwar so, dass du ihn ohne den Anbieter wieder lesen kannst. Ein Backup, das nur der Anbieter öffnen kann, ist kein Backup für den Tag, an dem der Anbieter weg ist.

Der Test mit dem verschwundenen Anbieter

Ich mag einen einfachen Test. Stell dir vor, die Firma hinter deiner Wallet ist morgen weg. Server aus, Domain weg, App aus dem Store. Was machst du jetzt?

Wenn die Antwort ist, du hättest vorher deinen Schlüssel exportieren sollen, ist das keine richtige Antwort. Du bekommst nicht immer eine Warnung. Wenn die Antwort einen Server braucht, den die Firma betreibt, ist es dasselbe Problem an einer anderen Stelle. Der Ausweg muss vorher feststehen, in den Coins selbst, und das Werkzeug dafür muss offen sein und auf deinem eigenen Computer laufen.

Das ist kein Test gegen Anbieter. Ein Anbieter kann viel Gutes tun, mitsignieren, Limits prüfen, auf seltsame Zahlungen achten. Er darf nur nicht das eine Ding sein, an dem alles hängt.

Warum das für Nuri wichtig ist

Bei Nuri sieht der Nutzer genau eine Sache, einen Passkey, bestätigt mit Face ID, Touch ID oder PIN. Keine Seed Phrase, keine Liste von Signierern, kein Jonglieren mit Geräten bei jeder Zahlung.

Hinter dieser einen Abfrage passieren zwei Dinge. Die PRF-Erweiterung liefert auf dem Gerät ein festes Geheimnis. Wie im öffentlichen Repository local-nuri-prf-passkey-recovery-tool dokumentiert, wird daraus lokal der Bitcoin-Schlüssel des Nutzers abgeleitet, mit domänengetrenntem HKDF-SHA256 und dem Taproot-Pfad m/86'/0'/0'/0/0. Gleichzeitig geht die WebAuthn-Assertion an einen getrennten Co-Signer, als Nachweis, dass der Nutzer genau diese Aktion freigegeben hat. Der Co-Signer will dafür jedes Mal eine frische Passkey-Zeremonie mit Nutzerverifikation, kein Session-Cookie und keinen API-Schlüssel. Er bekommt die Freigabe, nie die PRF-Ausgabe.

Auf Bitcoin L1 hat ein Output einen Key Path, das 2-von-2-MuSig2-Aggregat aus Nutzer und Co-Signer, und einen Skriptpfad mit dem Nutzerschlüssel hinter einer CSV-Verzögerung, and_v(v:pk(user), older(csv_blocks)). Auf der Arkade-Ebene für schnelle Off-Chain-Zahlungen kommt der Arkade-Server als dritter Signierer dazu, mit drei Blättern pro VTXO. Erst alle drei zusammen, nach der ersten Verzögerung Nutzer und Co-Signer, nach beiden Verzögerungen der Nutzer allein. Welche Outputs und Verträge zur Wallet gehören, liegt in einem verschlüsselten Backup auf Nostr und nicht in einer Datenbank von Nuri.

Wenn Nuri weg ist, baut das offene Recovery-Werkzeug den Web-Kontext von nuri.com auf dem eigenen Computer nach. Ein hosts-Eintrag zeigt nuri.com auf den lokalen Rechner, ein lokal vertrautes Zertifikat macht daraus einen sicheren Origin, und ein lokaler Server führt den geprüften Code aus. Der Passkey wertet PRF wie gewohnt aus, und die Schlüssel werden offline abgeleitet. Das ist kein WebAuthn-Bypass. Es braucht weiter den Passkey und seine Nutzerverifikation.

Die Grenzen gehören zum Design. Das Werkzeug ersetzt keinen verlorenen Passkey, es braucht einen Authenticator mit PRF, es stellt den privaten Schlüssel des Co-Signers nicht wieder her, und es überspringt keine Zeitsperre, die noch läuft. Für L1-Coins ist der CSV-Pfad der bedingungslose Ausweg. Wer Arkade ohne den Betreiber verlassen will, braucht zusätzlich die vorab signierten Exit-Transaktionen, dieser Ausstieg hängt also davon ab, dass die Exit-Daten im Backup des Nutzers liegen. Nach dem Verfall schützt der Co-Signer nicht mehr. Und Betrag und Empfänger muss der Nutzer trotzdem selbst prüfen. Ein dokumentiertes Werkzeug ist außerdem kein Nachweis, dass jede Wallet-Konfiguration vollständig damit getestet wurde.

Der Maßstab ist, was nach einem Fehler noch funktioniert

Ich will Multisig als Standard, weil der Verlust eines einzelnen Geräts oder Schlüssels nicht über das ganze Geld entscheiden sollte. Dafür müssen die zusätzlichen Signierer eine echte Hürde sein, und die Wiederherstellung darf sie nicht heimlich wieder abschaffen.

Für Nutzer muss das einfach bleiben. Eine Sache zum Bestätigen und eine klare Antwort auf jeden Ausfall. Telefon verloren. Schlüssel gestohlen. Falscher Bildschirm. Anbieter weg. Für keinen dieser Fälle sollte die Antwort dasselbe einzelne Ding sein.

Ein kaputtes oder manipuliertes Gerät ist ein Anlass, diese Fragen zu stellen, und die Antwort sollte mehr sein als der nächste Herstellername. Ich beurteile eine Wallet danach, welcher einzelne Fehler beherrschbar bleibt, wer für eine Zahlung zusammenarbeiten muss und wie Nutzer im Notfall wieder selbst handeln können. Daran muss sich auch Nuri messen lassen.