Der Passkey, der das Unternehmen überlebt

Warum ein normaler Passkey nicht reicht

Ein Passkey ist eine wunderschöne Authentifizierungs-Primitive. Der private Signaturschlüssel verlässt den Authenticator nie. Webseiten sehen nur Signaturen. Phishing stirbt, Passwort-Datenbanken werden egal.

Aber als Wallet-Primitive ist ein normaler Passkey eine Sackgasse. Er kann beweisen, dass du du bist — immer wieder, für immer. Er kann dir kein Geheimnis übergeben. Und eine Wallet braucht ein Geheimnis — eine Zahl, aus der deine Bitcoin- und Ethereum-Schlüssel abgeleitet werden.

Deshalb landen die meisten Passkey-Wallets in einem von zwei Lagern. Der Server hält den Wallet-Schlüssel und der Passkey ist nur ein schickes Login: Custody mit besserem UX. Oder MPC- und Enclave-Modelle teilen den Schlüssel über Infrastruktur — wirklich besser, aber die Rekonstruktion erfordert typischerweise, dass diese Infrastruktur lebt. Der Notausgang ist der Export: wenn du ihn nutzt, bevor der Anbieter verschwindet.

Beide Lager teilen eine stillschweigende Annahme: Die Domain, in die du dich einloggst, überlebt dein Bedürfnis nach dem Schlüssel.

Es gibt noch eine zweite, seltener diskutierte Falle. Passkeys sind domain-gebunden. Dein Credential funktioniert für die RP-ID, für die es erstellt wurde — genau das verhindert, dass eine fremde Webseite dein Wallet-Login phisht. Aber Domain-Bindung ist Schutz für die Lebensdauer der Firma, ohne Geschichte für danach. Wenn dein Wallet-Schlüssel mit der Zeremonie eines Anbieters verknüpft ist und dessen Domain dunkel wird, existiert dein Passkey noch, funktioniert noch — er hat nur niemanden mehr, mit dem er reden kann.

Der Passkey, der sein eigenes Geheimnis trägt

Nuri nutzt die WebAuthn-PRF-Erweiterung. PRF erlaubt der Wallet, dem Authenticator eine feste Frage zu stellen und eine stabile, pseudorandome Antwort zu bekommen — gebunden an dieses Credential, für immer reproduzierbar und niemals einem Server ausgesetzt.

Die RP-ID ist nuri.com, der PRF-Input ist die feste Zeichenkette nuri-prf-salt-v1, und der Output sind 32 geheime Bytes, lokal erzeugt nach Nutzerverifizierung. Diese 32 Bytes sind der Seed. Von dort ist alles öffentliche, deterministische Mathematik: HKDF-SHA256 mit Domain-Trennung in BIP32-Pfade m/86'/0'/0'/0/0 für Bitcoin Taproot und m/44'/60'/0'/0/0 für Ethereum. Der Ableitungs-Code und die Konstanten sind öffentlich — das local-nuri-prf-passkey-recovery-tool auf GitHub ist genau dieser Code, verpackt für den schlimmsten Tag.

Ein Unterschied trägt das meiste des Sicherheitsmodells. Eine Passkey-Zeremonie produziert zwei Dinge: die WebAuthn-Assertion — ein öffentlicher Beweis für Nutzerpräsenz, Origin, RP-ID und Absicht — und den PRF-Output — das private, deterministische Geheimnis hinter deinen Wallet-Schlüsseln. Der Nuri-Co-Signer erhält Assertionen, um zu verifizieren, dass du eine Co-Signing-Aktion genehmigt hast. Er erhält niemals den PRF-Output.

Das Geheimnis, das deine Signatur erzeugt, reist nie; nur der Beweis, dass du die Signatur des Servers genehmigt hast. Co-Signing und Recovery sind absichtlich getrennte Zeremonien. Der Server kann dir an einem Dienstag beim Ausgeben helfen und ein Jahrzehnt später für deine Recovery irrelevant sein.

Aber der Passkey ist an nuri.com gebunden

Ja. Der Passkey ist kryptografisch an die RP-ID nuri.com gebunden. Wir halten das für ein Feature — es ist genau das, was eine fremde Webseite daran hindert, deinen Passkey nach Geld zu fragen. Aber hier ist der Teil, der echte Design-Arbeit gekostet hat: Die RP-ID ist eine Zeichenkette, kein Abo.

WebAuthn prüft, dass die anfragende Seite ein sicherer Kontext ist, dessen Hostname zur RP-ID passt. Es prüft nicht, ob die Firma noch existiert, ob DNS auflöst oder ob das Zertifikat von einer öffentlichen Autorität stammt. Das sind Browser-Sicherheitseigenschaften, keine Firmenregister.

Deshalb baut das Recovery-Tool den Relying-Party-Kontext auf deiner eigenen Maschine wieder auf. Ein Hosts-Eintrag zeigt nuri.com auf deine Loopback-Adresse. Ein lokal erzeugtes, lokal vertrautes Zertifikat macht die Seite zu einem sicheren Origin. Der lokale Server auf https://nuri.com:8443 liefert geprüfte, eingecheckte Dateien — kein Remote-JavaScript, keine Analytics, keine Fonts. Dein Passkey fragt nach Face ID, Touch ID oder deiner PIN — die echte Zeremonie, dein echtes Credential — und übergibt den PRF-Output einer Seite, die vollständig auf deinem Computer läuft, idealerweise mit gezogenem Netzwerkkabel.

Das ist kein WebAuthn-Bypass. Ein Angreifer braucht weiterhin deinen Passkey und deine Nutzerverifizierung. Es ist kein gefälschtes öffentliches Zertifikat — du vertraust deiner eigenen lokalen CA nur auf deiner eigenen Maschine, für eine Recovery-Session. Es ist die Erkenntnis, dass der Nutzer, dem der Passkey gehört, den RP-Kontext besitzt — auch wenn dem Domain-Registrar das egal ist.

Wenn die Zeremonie fertig ist, entfernst du den Hosts-Eintrag, löschst die lokale CA und trennst die Verbindung. Die Zeichenkette nuri.com im Gedächtnis deines Passkeys hat das Unternehmen überlebt. Das war der Punkt.

Die Bitcoin-Schicht: 2-of-2 mit eingebautem Ausgang

Normales Ausgeben in Nuri Bitcoin ist eine 2-of-2-MuSig2-Kooperation. Dein Schlüssel — aus dem PRF abgeleitet — und der Schlüssel des Nuri-Co-Signers aggregieren zu einem einzigen Taproot-Schlüssel. On-chain sieht das wie ein gewöhnlicher Taproot-Output aus: schnell, privat, eine Signatur.

Aber jeder Output trägt auch einen Miniscript-Notausgang, der in die Chain selbst eingebrannt ist: Der Key-Pfad ist das MuSig2-Aggregat; der Script-Pfad ist dein x-only-Schlüssel in einer CSV-Frist: and_v(v:pk(user), older(csv_blocks)).

Solange Nuri lebt, gebt ihr gemeinsam über den Key-Pfad aus. Der Co-Signer gibt dir sofortiges, validiertes Ausgeben — Limits, Anomalie-Checks, ein menschlich geformtes Sicherheitsnetz. Wenn Nuri weg ist, wartest du die CSV-Frist ab — CheckSequenceVerify, ein relativer Timelock, der zu zählen beginnt, wenn der Output bestätigt — und dann kehrt dein Schlüssel allein die Gelder über den Script-Pfad. Keine Erlaubnis nötig, weil die Erlaubnis in den Output gebrannt war, als er erstellt wurde.

Die Mathematik ist öffentlich: Die Unlock-Höhe ist Bestätigungshöhe plus CSV-Blöcke. Das Recovery-Tool kann die Sweep-Transaktion vor dem Unlock bauen und signieren, weigert sich aber zu senden, bis die Unlock-Bedingung erfüllt ist.

Deshalb bestehen wir auf der Unterscheidung: Der private Schlüssel ist sofort offline wiederherstellbar; das Onchain-Script kann trotzdem Wartezeit verlangen. Das ist keine Anbieter-Verwahrung — es ist eine öffentliche Bitcoin-Konsensregel, die im Output steht. Verwahrung ist, wenn dich jemand ablehnen kann. Niemand kann einen Timelock ablehnen.

Die Verfalls-Architektur: Co-Signer, die ablaufen

Jetzt der Teil, der am leichtesten zu übersehen und am schwersten zu bauen ist: Wer darf signieren, und wie schrumpft diese Menge mit der Zeit? Die meisten Multisig-Wallets behandeln den Signer-Set als permanent. Widerruf bedeutet Infrastruktur: ein Widerrufsserver, eine Key-Rotation-Zeremonie, eine Upgrade-Transaktion. Jede davon ist eine Abhängigkeit, die genau dann versagen kann, wenn du sie am meisten brauchst.

Nuri behandelt den Signer-Set als Zeitplan. Co-Signer werden nicht per Infrastruktur widerrufen — sie verfallen on-chain, auf einer Uhr, die Bitcoin selbst durchsetzt. Der Nutzerschlüssel rotiert nie. Die Policy um ihn herum wird mit der Zeit nur einfacher.

Auf Bitcoin L1 startet der Output als 2-of-2. Dein Schlüssel und der Schlüssel des Nuri-Co-Signers aggregieren zu einem MuSig2-Taproot-Schlüssel. Dann, zu einer festen relativen Frist nach Bestätigung des Outputs, verfällt der Co-Signer aus der Existenz. Zur Zeit null ist der Set Nutzer plus Co-Signer, sofortige Key-Pfad-Ausgaben. Nach der CSV-Frist ist der Set der Nutzer allein, Script-Pfad-Sweep. Keine Transaktion entfernt den Co-Signer. Kein Widerrufsserver, keine Key-Rotation, keine Migration. Derselbe Output hat einfach zwei Ausgabebedingungen, und die Zeit wählt, welche lebt.

Das muss ein ehrliches nicht-custodiales 2-of-2 heißen: nicht 2-of-2, bis wir anders entscheiden, sondern 2-of-2, verfallend zu 1-of-1, auf einem Zeitplan, den niemand pausieren kann.

Die Arkade-Wallet: drei Schlüssel, zwei Verfälle

Die Lightning-Schicht hat einen Signer mehr, also hat die Verfallsleiter eine Sprosse mehr. Jedes VTXO — der virtuelle Transaktions-Output, der dein Offchain-Guthaben repräsentiert — committet zu einem Taproot-Baum mit drei Blättern, jede eine vollständige Ausgabebedingung.

Blatt eins ist der Arkade-Pfad: das MuSig2-Aggregat aus Nutzer und Nuri-Co-Signer, zusammen mit dem Arkade-Server. Sofort, offchain, Lightning-schnell. Blatt zwei ist die Aggregat-Recovery: Nutzer und Nuri-Co-Signer allein, nach der Arkade-CSV-Frist. Blatt drei ist die Client-Recovery: der Nutzerschlüssel allein, nach der Summe beider Fristen.

In klaren Worten verfällt der Signer-Set so: Zur Zeit null ist er Nutzer, Nuri-Co-Signer und Arkade-Server — normales Lightning-Leben. Nach der ersten Frist ist der Arkade-Server verfallen: Nutzer und Co-Signer bleiben. Nach der vollen Summe beider Fristen ist auch der Nuri-Co-Signer verfallen, und nur der Nutzerschlüssel bleibt.

Drei Eigenschaften machen das zur Leiter und nicht zu einem Haufen Scripts. Erstens: Thresholds schrumpfen nur auf dich zu. Drei Schlüssel, zu zwei, zu einem. Nie Wachstum, nie weg vom Nutzer. Zweitens: Jede Frist ist die Summe aller Fristen darüber. Das Client-Recovery-Blatt schaltet exakt dann frei, wenn beide Co-Signer vollständig verfallen sind, und die App lehnt strukturell jeden Baum ab, in dem der Nur-Nutzer-Pfad vor dem vollständigen Verfall des letzten Co-Signers freischalten würde. Solange ein Co-Signer im Script ist, schützt er dich noch — vor Vertipper-Beträgen, vor einem kompromittierten Client, vor dir um 3 Uhr morgens. Drittens: Der Verfall ist Konsens, nicht Infrastruktur. Nach der ersten Frist wird der Arkade-Server nicht widerrufen — er hört einfach auf, von einer lebenden Ausgabebedingung erwähnt zu werden. Selbst wenn er noch läuft, gesund und online, hat er keine mathematische Rolle mehr in deinem Output.

Das meinen wir, wenn wir sagen, die Arkade-Wallet sei ein 2-of-2-of-3. Nicht drei Schlüssel, Threshold zwei, für immer — sondern ein Multisig, dessen Co-Signer sterblich sind und dessen einziger unsterblicher Schlüssel deiner ist.

Wie die Operatoren und Co-Signer zusammenspielen

Es hilft, die Besetzung zu sehen. Dein Schlüssel wird aus dem PRF-Output deines Passkeys abgeleitet — er lebt auf deinen Geräten, in deinem Passwort-Manager oder auf einem Hardware-Authenticator. Der Nuri-Co-Signer ist ein Operator, den wir betreiben: Er verifiziert WebAuthn-Assertionen, bevor er seine Signatur beisteuert. Der Arkade-Server ist der Lightning-Operator, der Offchain-Sends möglich macht.

Der kritische Punkt ist, wie der Co-Signer entscheidet zu signieren. Er vertraut keinem API-Key und keinem Session-Cookie. Er verlangt eine frische WebAuthn-Assertion — eine echte Passkey-Zeremonie mit Nutzerverifizierung — für jede Co-Signing-Aktion.

Das macht das ganze System in der Tiefe phishing-resistent: Selbst wenn ein Angreifer einen gültigen PRF-Output extrahiert, hält er einen deterministischen Key-Seed, aber Ausgeben erfordert weiterhin den Co-Signer, und der Co-Signer handelt nur auf eine frische Passkey-Assertion des Nutzers. Ein geleakter PRF allein kann kein Geld bewegen, solange der Co-Signer im Script ist. Und nach dem Verfall des Co-Signers ist das Fenster des Angreifers dieselbe CSV-Frist, die alle schützt — eine Frist, die der Nutzer auch nutzen kann, um zuerst bei seinen Geldern zu sein.

Das ist auch der Kern ohne Single Point of Failure: Der Operator, der Arkade-Server und sogar die Domain sind sterblich, ersetzbar und nach ihrem Verfall außerhalb des kritischen Pfads. Und das Design erweitert sich: Ein Hardware-Wallet kann als Backup-Co-Signer für eine 2-of-3-Recovery-Option hinzugefügt werden, und PRF-fähige Hardware-Authenticatoren — YubiKeys mit PRF-Support oder unsere biometrische NFC-Passkey-Smartcard — können den Nutzerschlüssel in Silizium halten. Mehr Schlüssel, mehr Verfallsprossen, dieselbe Regel: Thresholds schrumpfen nur auf den Nutzer zu.

Was das bedeutet, wenn das Licht ausgeht

Spiele das volle Szenario durch. Es ist 2040. Die Nuri GmbH wurde 2031 aufgelöst. Niemand hat die Domain verlängert. Du hast deinen Passkey noch in deinem Passwort-Manager, deinem Telefon oder einem Hardware-Authenticator.

Auf einem offline Computer führst du das Open-Source-Recovery-Tool aus. Es baut den nuri.com-RP-Kontext lokal wieder auf — Hosts-Eintrag, lokale CA, lokaler Server. Dein Passkey — dasselbe Credential, domain-gebunden an eine Zeichenkette, die nicht mehr auflöst — evaluiert den PRF. Deterministische Ableitung erzeugt deine Bitcoin- und Ethereum-Schlüssel. Du ziehst die verschlüsselten Nostr-Backups, rekonstruierst deine VTXOs, berechnest die Unlock-Höhe jeder Verfallssprosse und sweepst: L1-Outputs, deren CSV gereift ist, Arkade-Outputs, deren Leiter fertig verfallen ist, alles noch Timelocked, sobald es reift.

An keinem Punkt dieser Geschichte musste jemand in einer Firma einen Button drücken, ein Ticket genehmigen oder eine Datenbank am Leben halten. Die Rettung war von Tag eins an designed.

Warum wir immer Rettung sagen, nicht Export

Ein Export-Button ist ein Versprechen über dein künftiges Verhalten. Ein Rettungspfad ist eine Eigenschaft des Systems.

Der Privy-artige Export ist ein echter Notausgang — aber einer, an den du denken musst, solange die Tür noch offen ist. Nuris Antwort dreht die Reihenfolge um. Das Schlüsselmaterial lebt beim Passkey des Nutzers. Der Verfallszeitplan lebt in der Chain. Der Recovery-State lebt auf Nostr. Der Job der Firma ist es, nützlich zu sein, solange sie existiert — nicht tragend zu sein, nachdem sie es nicht mehr ist.

Das ist auch, warum die Arkade-Architektur über Nuri hinaus zählt. Agenten, die Geld halten, brauchen dieselbe Eigenschaft: einen Operator, der Geld schnell machen kann, solange er existiert, und mathematisch egal sein kann, wenn seine Zeit um ist. Eine Wallet, deren Co-Signer verfallen, ist eine Wallet, die ein Agent erben kann, ohne eine Abhängigkeit zu erben.

Selbstverwahrung, die das Weiterleben des Verwahrers erfordert, ist nur Custody mit extraschritten. Wir haben Nuri so gebaut, dass sogar unsere Abwesenheit überlebensfähig ist. Das ist keine Marketing-Zeile; es ist testbar, heute, mit Tools, die wir veröffentlicht haben, und einem Szenario, das du an einem Nachmittag durchspielen kannst.

Recovery braucht weiterhin den Original-Passkey, einen Authenticator mit PRF-Support und eine geprüfte Kopie des Tools. Und Ehrlichkeit beim Trade-off: Nach dem Verfall der Co-Signer verfallen auch deren Schutzfunktionen. Selbstverwahrung heißt, das zu besitzen. Der wichtigste Satz dieses Artikels ist dieser: Prüfe, ob der Passkey deiner Wallet ein Geheimnis trägt — oder nur eine Signatur.