Wo CardanoWall deine Schlüssel im Browser aufbewahrt

Wenn du CardanoWall im Browser entsperrst, leben der entsperrte Seed und die daraus abgeleiteten privaten Schlüssel im Sitzungsspeicher – ganz normaler Anwendungsspeicher, der verschwindet, sobald du sperrst, dich abmeldest oder den Tab schließt. Der dauerhafte Browser-Speicher (IndexedDB, sessionStorage) enthält nur verschlüsselten Vault-Chiffretext und nicht geheime Metadaten. Identity Seeds im Klartext und abgeleitete private Schlüssel landen dort niemals.

Genau diese Unterscheidung ist der springende Punkt. Der Browser muss Schlüsselmaterial besitzen, um lokal zu signieren und zu entschlüsseln – nur so funktioniert die Kryptografie überhaupt. Die Sicherheitsfrage lautet nie „Kann der Browser Schlüssel berühren?“. Er muss es. Die Frage ist, wo diese Schlüssel leben und was auf die Festplatte geschrieben wird. CardanoWalls Web-Modell ist so gebaut, dass das, was einen Reload überlebt, Chiffretext ist – keine Geheimnisse.

Was braucht der Browser, während eine Identität entsperrt ist?

Er braucht das private Schlüsselmaterial für genau die Arbeit, die du gerade erledigst – und nichts, das länger bestehen bleibt als die Sitzung selbst.

Nachdem du eine Identität entsperrt hast, kann die App Folgendes brauchen:

• einen Label 309-Eintrag signieren;
• einen versiegelten Eintrag entschlüsseln, der an dich adressiert ist;
• eingehende versiegelte Einträge probeweise entschlüsseln, um die für deine Inbox bestimmten zu finden;
• den Vault neu verschlüsseln, nachdem du einen Passkey hinzugefügt oder entfernt hast;
• deinen Seed anzeigen, wenn du ihn ausdrücklich sehen willst;
• lokale verschlüsselte Caches neu aufbauen.

Nichts davon ist mit öffentlichen Schlüsseln allein möglich. Jede Operation braucht privates Material, das aus deinem Identity Seed abgeleitet ist. Das Design hält dieses Material im Sitzungsspeicher und löscht es beim Sperren oder Abmelden – nach bestem Bemühen, aus Gründen, auf die wir gleich kommen.

Was ist hier der Sitzungsspeicher?

Der Sitzungsspeicher ist temporärer, prozessinterner Anwendungsspeicher, den die App verwirft, sobald die Entsperr-Sitzung endet.

In CardanoWalls Browser-App werden der aktive Seed und die daraus abgeleiteten Schlüssel außerhalb des gewöhnlichen UI-State gehalten, in internen Speicher-Maps. Der reaktive UI-State enthält nur nicht geheime Fakten: welche Identität entsperrt ist, wann sie entsperrt wurde, welche Passkey-Enrollment-Metadaten während der Einrichtung auf dem Bildschirm stehen. Die geheimen Bytes gelangen niemals in diesen reaktiven State.

Diese Trennung ist wichtig, weil gewöhnlicher UI-State der Teil einer App ist, der am ehesten inspiziert, serialisiert, persistiert oder versehentlich an eine Komponente weitergereicht wird, die ihn protokolliert. Geheimes Material verdient eine kleinere, bewusst aufgezählte Angriffsfläche. Jede Stelle in der App, die geheime Bytes herausgeben kann – die Signier-Closure, die Entschlüsselungsschlüssel, die Notluke zur Seed-Anzeige, der Pfad zum Neuaufbau des Vault – ist in einer einzigen Datei aufgeführt, und jede gibt eine defensive Kopie zurück statt des aktiven Puffers.

Der Browser hält die Geheimnisse weiterhin, solange du entsperrt bist. Sie werden nur nicht wie normale App-Daten behandelt.

Was wird in IndexedDB geschrieben?

Verschlüsselter Vault-Chiffretext – dieselben Bytes, die der Server speichert, nicht die Seeds darin.

IndexedDB dient als lokaler Cache deines verschlüsselten Identitäts-Tresors: eine Zeile pro Konto, die exakt den age-verschlüsselten Chiffretext enthält, den der Server aufbewahrt. Durch das Cachen kann die App nach einem Reload mit einem einzigen Passkey-Tipp rehydrieren, ohne den Vault erneut über einen Roundtrip abrufen zu müssen.

Ein Angreifer, der nur diese lokale Datenbank ausliest, sieht verschlüsselte Vault-Bytes, die an deine Passkeys adressiert sind – keine Seeds im Klartext. Der Cache bleibt sensible Dienstdaten, und die App löscht ihn beim Abmelden, bei Kontolöschung und bei Passkey-Änderungen. Aber er ist nicht die Identität selbst; er ist eine verschlossene Box, deren einzige Schlüssel in deinen Authenticatoren liegen. (Wie diese Box versiegelt wird, erfährst du unter wie CardanoWall deine Identität speichert und wie Passkeys deinen Identitäts-Tresor schützen.)

Diese Schreibvorgänge werden im Modus für öffentliche Computer und dann, wenn du dich entscheidest, das Gerät nicht zu merken, vollständig unterdrückt.

Was kommt in sessionStorage?

Nur nicht geheime Enrollment-Metadaten – niemals Schlüsselmaterial.

Während der Erstellung einer Identität spiegelt die App Passkey-Enrollment-Metadaten in sessionStorage, damit ein versehentlicher Reload mitten in der Einrichtung den sichtbaren Zustand nicht löscht. Diese Metadaten sind von Natur aus nicht geheim: Credential-IDs, öffentliche Schlüssel, Transports, Gerätetyp- und Backup-Flags und ähnliche Fakten, aus denen ein Angreifer nichts gewinnt.

Was ausdrücklich aus sessionStorage herausgehalten wird:

• Identity Seeds;
• abgeleitete private Schlüssel;
• WebAuthn-PRF-Ausgaben (Pseudozufallsfunktion) – die Geheimnisse, die ein Passkey zurückgibt, um den Vault zu entsperren;
• Vault-Klartext;
• entschlüsselter versiegelter Inhalt.

Die Grenze ist einfach. Die Kontinuität der Oberfläche darf einen Reload überdauern; Identitätsgeheimnisse sollten es nicht.

Was gehört überhaupt niemals in den Browser-Speicher?

Identitätsmaterial im Klartext – in keinem Speicher.

Diese Dinge werden aus localStorage, sessionStorage, IndexedDB, Cookies, Logs und gewöhnlichem App-State herausgehalten:

• der Identity Seed;
• private Ed25519-Signaturschlüssel;
• private X25519-Empfangsschlüssel;
• hybride Post-Quanten-Empfangsgeheimnisse (der Seed hinter der optionalen age1pqc...-Adresse);
• WebAuthn-PRF-Ausgaben;
• Vault-Klartext;
• entschlüsselter versiegelter Inhalt, es sei denn, du speicherst ihn ausdrücklich in einem verschlüsselten lokalen Cache, über den du klare Kontrolle hast.

Die Begründung ist dieselbe, die sich durch das gesamte Design zieht: Je mehr Orte ein Geheimnis geschrieben wird, desto schwerer wird es, über das Löschen nachzudenken, und desto größer ist die Angriffsfläche, die eine Kompromittierung auslesen kann.

Was ist der Modus für öffentliche Computer?

Es ist der ausdrückliche Modus für geteilte Geräte: Solange er aktiv ist, wird überhaupt nichts Identitätsbezogenes in den Browser-Speicher geschrieben.

Schalte ihn ein, und die App überspringt jeden identitätsbezogenen Persistenzpfad – kein PIN-Vault, kein IndexedDB-Vault-Cache, kein Version-Pin, kein sessionStorage-Enrollment-Spiegel. Entsperrte Schlüssel leben ausschließlich im Sitzungsspeicher; sie überstehen die In-App-Navigation des Tabs, sterben aber beim Schließen des Tabs oder beim Reload. Der Schalter selbst ist absichtlich nur im Speicher: „Ich bin an einem öffentlichen Computer“ zu persistieren wäre selbst ein Schreibvorgang in den Browser-Speicher, und eine geteilte Maschine sollte immer wieder im sicheren Standard öffnen und erneut fragen. Nutze ihn an einem Bibliothekscomputer, einem geliehenen Laptop, einer Konferenzmaschine, einem Redaktions-Kiosk – an allem, worüber du keine Kontrolle hast.

Was er nicht tut, ist, ein nicht vertrauenswürdiges Gerät sicher zu machen. Wenn die Maschine bereits kompromittiert ist, während du einen Seed eintippst oder eine Identität entsperrst, kann sie weiterhin Geheimnisse im Speicher beobachten. Der Modus reduziert, was nach deinem Weggang zurückbleibt; er besiegt keine aktive lokale Schadsoftware. Der Modus für öffentliche Computer beschreibt den vollständigen Ablauf.

Was bedeutet Zeroisierung in JavaScript?

Es bedeutet, die geheimen Byte-Arrays zu überschreiben – sie mit Nullen zu füllen –, sobald die App damit fertig ist.

CardanoWall zeroisiert seine Uint8Array-Schlüsselpuffer, wenn eine Identität gesperrt wird oder du dich abmeldest, statt zu warten und zu hoffen, dass der Garbage Collector sie zurückfordert. Das ist gute Hygiene und es lohnt sich.

Aber JavaScript ist keine gehärtete Umgebung für den Umgang mit Geheimnissen, und das gehört offen gesagt. Strings sind unveränderlich, also kann ein Geheimnis, das jemals zu einem String wurde, nicht an Ort und Stelle gelöscht werden. Das Timing der Garbage Collection liegt nicht in der Hand der App. Engines können Speicher intern kopieren. Entwicklertools, Erweiterungen und ein kompromittierter Origin verändern das Risikomodell vollständig.

Zeroisierung ist hier also eine Best-Effort-Maßnahme, kein garantiertes Löschen. Sie verkleinert merklich das Fenster, in dem eine verirrte Kopie verweilt; sie verspricht nicht, dass die Bytes überall verschwunden sind.

Was passiert, wenn die Seite kompromittiert wird, während sie entsperrt ist?

Dann ist die Identität tatsächlich in Gefahr – das ist die härteste Grenze in jeder browserbasierten Kryptografie.

Eine bösartige Browser-Erweiterung mit Zugriff auf den Seiteninhalt, ein kompromittiertes Gerät oder ein ernster Cross-Site-Scripting-Fehler (XSS), der während einer entsperrten Sitzung läuft, kann womöglich Geheimnisse aus dem Speicher auslesen oder die App dazu bringen, Dinge zu signieren oder zu entschlüsseln, die du nicht beabsichtigt hast. Keine Web-App kann das vollständig ausschließen: Code, der über das Netzwerk eintrifft und dann Schlüssel verarbeitet, ist allem ausgesetzt, was sonst im selben Origin läuft.

CardanoWall setzt auf Defense in Depth, um das Fenster zu verkleinern: eine strikte Content Security Policy, die Skripte auf den eigenen Origin der App beschränkt – ohne Inline-Skripte, ohne eval und ohne dass überhaupt Skripte von Drittanbietern geladen werden – plus Security-Header, die am Edge auf jede Antwort gestempelt werden, eine bewusst kleine Geheimnis-Angriffsfläche, keine Klartext-Persistenz sowie Entsperren und Entschlüsseln nur auf ausdrückliche Benutzeraktion – niemals automatisch beim Tab-Fokus. Das senkt die Wahrscheinlichkeit und den Schadensradius. Es macht ein bösartiges Skript innerhalb eines entsperrten Origin nicht harmlos; das bleibt die folgenschwerste Bedrohung, die das Browser-Modell in Kauf nimmt.

Für deine sensibelsten Identitäten ist die richtige Antwort, das Schlüsselmaterial von der geteilten Web-Oberfläche wegzubewegen. Halte sie auf einem dedizierten, vertrauenswürdigen Gerät und bevorzuge einen Ablauf, bei dem das Geheimnis überhaupt keinen Browser berührt – die CLI in der Automatisierung oder CardanoWall Desktop, das deine Schlüssel in einem lokalen Rust-Kern statt in einem Web-Origin hält. (Zum allgemeineren Prinzip siehe warum Schlüssel das Gerät nie verlassen.)

Was solltest du tatsächlich tun?

Nutze das Browser-Modell bewusst und passe die Vorkehrungen an die Sensibilität der Arbeit an.

Für den Alltag:

• speichere deinen Identity Seed an einem sicheren Ort – er ist das eigentliche Backup;
• füge einen Passkey für das tägliche Entsperren hinzu;
• sperre oder melde dich ab, wenn du fertig bist;
• nutze „Dieses Gerät merken“ nur auf Maschinen, denen du vertraust;
• halte deinen Browser und dein Betriebssystem aktuell;
• vermeide riskante Browser-Erweiterungen;
• schalte den Modus für öffentliche Computer auf jedem geteilten Gerät ein.

Für sensible Arbeit kommt hinzu:

• ein dediziertes Browser-Profil oder, besser, ein dediziertes Gerät;
• kein Entsperren auf geliehenen Maschinen;
• ein Hardware-Sicherheitsschlüssel als Entsperrfaktor;
• Trennung zwischen risikoreichen und gewöhnlichen Identitäten;
• Vorsicht bei versiegelten Einträgen – ein Empfänger, der entschlüsseln kann, kann den Klartext danach auch weitergeben.

Die Kurzfassung

CardanoWalls Browser-App braucht private Schlüssel, solange eine Identität entsperrt ist, also hält sie sie im Sitzungsspeicher statt im dauerhaften Speicher. IndexedDB cacht nur den verschlüsselten Vault-Chiffretext; sessionStorage hält nur nicht geheime Einrichtungs-Metadaten. Der Identity Seed und die privaten Schlüssel werden niemals als gewöhnliche Browser-Daten geschrieben.

Das Hosted-Vault-Modell und das Browser-Speicher-Modell verstärken sich gegenseitig: Der Server hält Chiffretext, den er nicht entschlüsseln kann, und der Browser bemüht sich nach Kräften, den Seed nicht zurückzulassen. Keine der beiden Aussagen ist eine Garantie gegen ein Gerät, das bereits kompromittiert ist – und über diese Grenze klar zu sein, ist Teil davon, sie ernst zu nehmen. Für das vollständige Bild dessen, was der Dienst beobachten kann und was nicht, siehe was CardanoWall sehen kann.