9 Min. Lesezeit
Wie CardanoWall deine Identität speichert
CardanoWall speichert deine Identität als verschlüsselten Tresor-Chiffretext, niemals als Klartext-Seeds. Hier steht genau, was der Server hält, was nur dein Passkey öffnen kann und warum dein Seed das eigentliche Backup ist.

CardanoWall speichert deinen Identity Seed niemals im Klartext. Der Server hält einen verschlüsselten Tresor, den nur deine eigenen Passkeys öffnen können, dazu die öffentlichen, nicht geheimen Daten, die dein Konto braucht. Der Seed selbst – das, was deine Identität ist – bleibt auf deiner Seite.
Hier ist das Denkmodell in einem Satz: dein Identity Seed ist die portable Identität und das eigentliche Backup; der gehostete Tresor ist eine per Passkey entsperrte Komfortschicht, keine Verwahrung.
Dieser Beitrag führt durch das, was CardanoWall speichert, was es bewusst nicht lesen kann und was das bedeutet, wenn etwas schiefgeht.
Was ist ein Identity Seed, und warum ist er wichtig?
Eine CardanoWall-Identität wird aus einem einzigen 32 Byte großen Identity Seed aufgebaut. Aus diesem Seed erzeugt eine deterministische Schlüsselableitung die Schlüssel, die du tatsächlich nutzt: einen Ed25519-Schlüssel, der Einträge signiert, und X25519-basierte Schlüssel, die versiegelte Dateien empfangen. Dieselben 32 Byte bauen überall immer dieselbe Identität wieder auf – die Website, das Kommandozeilen-Werkzeug, die SDKs oder jede andere Software, die den offenen Ableitungsregeln von Label 309 folgt.
Das ist die entscheidende Eigenschaft: der Seed ist portabel, und er bestimmt alles. Die Schlüssel hängen von ihm ab. Für die Speicherung zählt also nur eine einzige Frage – wo der Seed liegt.
Die Antwort lautet: bei dir. CardanoWall kann eine verschlüsselte Kopie zur Bequemlichkeit aufbewahren, aber es speichert Chiffretext, keine lesbaren Seeds.
Was speichert CardanoWall tatsächlich?
CardanoWall speichert die Servicedaten, die dein Konto braucht. Dazu gehören:
- dein Konto-Anmeldestatus;
- Abrechnungs- und Guthaben-Einträge;
- deine öffentlichen Identitätsschlüssel;
- öffentliche Nachweis-Einträge und Cardano-Transaktionsreferenzen;
- der verschlüsselte Chiffretext des Identitäts-Tresors;
- API-Schlüssel, nur als Hashes gespeichert;
- Produkteinstellungen wie der Lebenszyklus-Status jeder Identität;
- deine Adressbuch-Einträge und Inbox-Präferenzen.
Achte darauf, was nicht auf dieser Liste steht. Dein Identity Seed, dein abgeleiteter privater Signaturschlüssel, deine abgeleiteten privaten Empfangsschlüssel und alle entschlüsselten versiegelten Dateien sind allesamt clientseitige Geheimnisse. Sie werden niemals in einer lesbaren Server-Spalte gespeichert. Der verschlüsselte Tresor ist der einzige Ort, an dem der Server überhaupt etwas Seed-Bezogenes hält, und er hält es als Chiffretext, den er nicht öffnen kann.
Das vollständige Bild davon, was für den Service sichtbar ist und was auf deinem Gerät bleibt, findest du unter was CardanoWall sehen kann.
Was ist der Identitäts-Tresor?
Der Identitäts-Tresor ist ein einziges verschlüsseltes Bündel, das die Geheimnisse für die Identitäten deines Kontos enthält.
Im Klartext des Tresors enthält jeder Eintrag den 32 Byte großen Seed einer Identität und das private Anzeigelabel, das du dafür gewählt hast – „Privat“, „Presse-Team“ oder was auch immer du eingetippt hast. (Ein Konto kann mehrere Identitäten halten; jede bekommt ihren eigenen Eintrag.) Das Label liegt ebenfalls innerhalb der Verschlüsselung, es wird also serverseitig niemals offengelegt.
Bevor irgendetwas davon gespeichert wird, wird es verschlüsselt. CardanoWall hält das Ergebnis als eine aktuelle Tresor-Zeile pro Konto, im age-v1-Format. Der Server kann diesen Chiffretext halten und ihn dir zurückgeben, aber er hält nicht das Schlüsselmaterial, das nötig ist, um ihn zu öffnen.
Genau das ist der Punkt: der Tresor ist keine Verwahrung. Er ist ein verschlüsselter Komfort-Cache. Das kanonische, portable Artefakt ist nach wie vor der Seed.
Was entsperrt den Tresor?
Dein registrierter Passkey entsperrt ihn – und sonst nichts.
Der Tresor ist ausschließlich an WebAuthn-Passkey-Faktoren verschlüsselt, die die PRF-Erweiterung (Pseudo-Random Function) unterstützen, mit einer Empfänger-Stanza pro Passkey. Es gibt im gehosteten Tresor bewusst keine passwortabgeleitete Stanza und keine Public-Key-Stanza. Während einer Entsperrung führt dein Authenticator die Nutzerverifizierung durch und gibt PRF-abgeleitetes Schlüsselmaterial an den Browser frei; dieses Material öffnet den Tresor lokal.
Der Server von CardanoWall erhält niemals den Klartext-Seed, den entschlüsselten Tresor oder einen aus dem Seed abgeleiteten privaten Schlüssel. Aus Sicht des Servers weiß er nur, dass ein Konto authentifiziert ist und dass er einen Blob Chiffretext zurückliefern kann. Was ihn öffnet, ist dein Browser, gesteuert von deiner Passkey-Zeremonie.
Wie Passkeys diese Sperre bereitstellen und welche Wiederherstellungs-Kompromisse die verschiedenen Passkey-Typen mitbringen, liest du unter wie Passkeys deinen Identitäts-Tresor schützen.
Warum nicht einfach den Seed auf dem Server speichern?
Weil das CardanoWall zu einem Verwahrer deiner Identität machen würde – und Verwahrung ist genau der Fehlermodus, den das Design vermeidet.
Würde ein Service Klartext-Seeds speichern oder Seeds, die er selbst entschlüsseln könnte, dann könnte aus einem Server-Einbruch ein Einbruch in die Nutzerschlüssel werden. Ein Angreifer, der die Datenbank oder die Schlüssel des Servers gestohlen hat, könnte womöglich als Nutzer signieren oder deren versiegelte Einträge entschlüsseln. Das ist ein einzelner Punkt katastrophalen Versagens.
CardanoWall ist um ein anderes Versprechen herum gebaut: ein Datenbankleck soll keine Identity Seeds preisgeben, weil der Server niemals das Material hält, das sie öffnet. Das Design soll einen hypothetischen Einbruch zwar ernst, aber für deine Schlüssel nicht katastrophal machen.
Die Entscheidung, ausschließlich an Passkeys zu verschlüsseln, hat zwei konkrete Konsequenzen, die es zu nennen lohnt. Weil es keine passwortabgeleitete Stanza gibt, hat ein gestohlener Tresor nichts, das sich per Brute Force knacken ließe – es gibt keine menschengewählte Passphrase, die man durchprobieren könnte. Und weil es keine Public-Key-Stanza gibt, gibt es kein asymmetrisches Ziel, auf das ein künftiger Quantenangriff (vom Typ Shor) zielen könnte; die Schlüssel, die den Tresor schützen, sind 256-Bit-symmetrische Werte, die in deinen Authenticators liegen, wo die relevante Quantenbedrohung eine Grover-artige Suche ist – das lässt rund 128 Bit effektive Sicherheitsmarge.
Das lässt nicht jedes Risiko verschwinden. Es bedeutet, dass das wichtigste Geheimnis nicht in einer lesbaren Server-Spalte sitzt und darauf wartet, kopiert zu werden.
Ist der Tresor ein Backup?
Nicht das Backup der letzten Instanz. Das eigentliche portable Backup ist der Identity Seed.
Wenn du den Seed hast, kannst du dieselbe Identität in CardanoWall, im Kommandozeilen-Werkzeug, in den SDKs, in der Desktop-App oder in jeder künftigen Label-309-Software wieder aufbauen, die denselben Ableitungsregeln folgt. Der Seed ist die eine Sache, die überallhin mitreist.
Der gehostete Tresor hilft dir, den Seed nicht jeden Tag neu eintippen zu müssen. Er kann dir auch helfen, auf ein anderes angemeldetes Gerät zu wechseln, wenn dein Passkey-Anbieter den Passkey über deine Geräte synchronisiert. Aber der Tresor gehört zur Service-Schicht. Er kann gelöscht werden, nicht verfügbar sein oder verschwinden, wenn du deinen letzten Passkey entfernst. Der Seed ist das, was du sichern musst. Warum der Identity Seed weiterhin zählt geht tiefer darauf ein.
Was passiert im Browser, wenn du entsperrst?
Wenn du eine Identität entsperrst, braucht der Browser vorübergehend Zugriff auf privates Schlüsselmaterial. Das ist unvermeidlich: um einen Eintrag zu signieren, muss der Client den Signaturschlüssel halten; um eine versiegelte Datei zu entschlüsseln, muss er den Empfangsschlüssel halten. Diese Schlüssel werden im Browser aus dem Seed abgeleitet, nachdem du entsperrt hast.
Das Design hält Geheimnisse aus dem gewöhnlichen persistenten Browser-Speicher heraus. Der lokale Cache des Browsers (IndexedDB) darf den verschlüsselten Tresor-Chiffretext halten – dieselben Bytes, die der Server hat –, damit ein Seitenneuladen nur einen Passkey-Tipp statt einer Netzwerkanfrage braucht. Den Klartext-Seed cacht er niemals. Die aktiven privaten Schlüssel leben im Sitzungsspeicher, außerhalb des UI-Zustands der Anwendung gehalten, und werden beim Sperren oder Abmelden nach bestem Bemühen mit Nullen überschrieben.
Das ist ein Web-Crypto-Modell, keine Hardware-Isolierung, und es ist ehrlich gegenüber seinen Grenzen. Eine bösartige Browser-Erweiterung, ein kompromittiertes Gerät oder ein aktives bösartiges Skript, das während einer entsperrten Sitzung läuft, kann lesen, was im Speicher liegt, solange du entsperrt bist. Eine strikte Content-Security-Policy, minimale Skripte und Entsperrung nur bei expliziter Aktion verkleinern diese Angriffsfläche, können sie aber nicht beseitigen. CardanoWall beseitigt das Verwahrungsrisiko des Servers; es kann ein nicht vertrauenswürdiges Gerät nicht sicher machen. Die Mechanik dahinter findest du unter Browser-Speicher und Sitzungsschlüssel, das umfassendere Prinzip unter warum Schlüssel das Gerät nie verlassen.
Was passiert, wenn du einen Passkey entfernst?
Der Tresor wird ohne diesen Faktor neu aufgebaut.
Wenn du einen Passkey entfernst, wird der aktuelle Tresor an die verbleibenden Faktoren neu verschlüsselt und als neue einzelne Zeile geschrieben, die den alten Chiffretext an Ort und Stelle ersetzt. Der entfernte Passkey kann den existierenden Tresor nicht mehr öffnen. Der Service erzwingt das sogar an der Speichergrenze: ein Tresor kann niemals gewrappt an eine Anmeldeinformation geschrieben werden, die das Konto bereits entfernt hat.
Das ist ein echter Widerruf für den aktuellen gehosteten Tresor. Es ist Kontrolle auf Service-Ebene, keine Zeitreise. Wurde ein Passkey missbraucht, solange er noch gültig war – etwa benutzt, um den Tresor zu öffnen und den Seed innerhalb einer aktiven Sitzung zu lesen –, dann hält der Angreifer den Seed womöglich bereits, und den Tresor danach neu zu verschlüsseln holt das nicht zurück. In diesem Fall ist die richtige Reaktion kein Zurücksetzen, sondern ein Neuanfang: erstelle eine neue Identität, deaktiviere die alte und veröffentliche die neuen öffentlichen Schlüssel dort, wo Leute sie erwarten.
Was passiert, wenn du einen Passkey entfernst geht die genaue Abfolge durch.
Was, wenn CardanoWall verschwindet?
Deine veröffentlichten Nachweise lassen sich weiterhin verifizieren.
Ein Label-309-Nachweis ist so konzipiert, dass er eigenständig verifizierbar ist. Seine Verifizierung hängt von öffentlichen Cardano-Daten ab, von öffentlichem inhaltsadressiertem Speicher, wenn der Eintrag darauf zeigt, und von der Kopie, die der Verifizierer selbst vom Originalinhalt oder vom Entschlüsselungsmaterial hat. Ein gültiger Nachweis verlangt nicht, dass CardanoWall online bleibt – jeder mit der Transaktionsreferenz und einem öffentlichen Cardano-Explorer kann ihn prüfen.
Auch deine Identität überlebt, wenn du den Seed gesichert hast. Dieselben 32 Byte rekonstruieren dieselbe Identität in jedem konformen Werkzeug.
Was du ohne den Seed verlierst, ist die künftige Nutzung dieser Identität: neue Signaturen zu erzeugen und versiegelte Einträge zu entschlüsseln, die an sie adressiert sind. Die Nachweise, die du bereits veröffentlicht hast, bleiben für immer verifizierbar, aber du kannst nicht mehr als diese Identität handeln. Diese Asymmetrie – veröffentlichte Nachweise sind dauerhaft, künftige Nutzung hängt am Besitz des Seeds – ist der bewusste Preis dafür, keinen Verwahrer zu haben.
Was solltest du konkret tun?
Sichere zuerst den Identity Seed.
Lege ihn an einem Ort ab, dem du auch hochwertige Geheimnisse anvertraust: einen Passwortmanager, einen sicheren Offline-Ort oder welches Modell auch immer du für Dinge nutzt, die du dir nicht leisten kannst zu verlieren. Füge dann einen Passkey für die tägliche Bequemlichkeit hinzu.
Für den normalen Gebrauch ist diese Kombination eine starke Balance: der Seed bleibt portabel, und der Passkey hält den alltäglichen Zugriff reibungslos. Für risikoreiche Identitäten füge betriebliche Kontrollen hinzu – einen Hardware-Sicherheitsschlüssel, ein dediziertes Gerät und eine separate Identität, die für sensible Arbeit reserviert ist.
Noch eine Sache, die man auseinanderhalten sollte: ein verlorener Seed (ohne verbleibende Entsperrfaktoren) bedeutet, dass die künftige Nutzung der Identität weg ist, ihre Nachweise sich aber weiterhin verifizieren lassen. Ein gestohlener Seed ist die vollständige Kompromittierung der Identität, und die Reaktion ist eine neue Identität plus die Deaktivierung der alten – niemals ein Passwort-Reset, denn es gibt kein Passwort zum Zurücksetzen.
Die Kurzfassung
CardanoWall speichert verschlüsselten Tresor-Chiffretext, keine Klartext-Identity-Seeds.
Dein Seed ist die Identität. Dein Passkey entsperrt den verschlüsselten Tresor. Der Browser nutzt private Schlüssel erst, nachdem du entsperrt hast, und löscht sie beim Sperren. Der Server kann dir helfen zu veröffentlichen, zu synchronisieren und den Zugriff bequem wiederherzustellen – aber er kann deine Identität von Haus aus nicht lesen oder neu erstellen.
Sichere den Seed. Nutze den Passkey. Kenne den Unterschied.
Weiterführende Lektüre
- Deine Identität ist ein Seed – was der 32 Byte große Seed ist und warum er die gesamte Identität ausmacht.
- Wie Passkeys deinen Identitäts-Tresor schützen – die Passkey-Sperre und die Kompromisse zwischen synchronisierten und Hardware-Schlüsseln.
- Browser-Speicher und Sitzungsschlüssel – was im Browser lebt, für wie lange, und die Grenzen von Web-Crypto.
- Was CardanoWall sehen kann – die vollständige Grenze der Server-Sichtbarkeit.
- Label 309 – der offene Standard, den CardanoWall implementiert, mit Referenzcode unter github.com/cardanowall.