Was CardanoWall sehen kann (und was nicht)

CardanoWall kann gewöhnliche Servicedaten und die öffentlichen Nachweiseinträge sehen, die du veröffentlichst. Per Design sieht es weder deinen Identity Seed im Klartext noch deine privaten Schlüssel noch den Klartext einer Datei, die du versiegelst. Das sensibelste Material wird auf deinem Gerät gehalten und genutzt, nicht auf unseren Servern.

Das ist die ehrliche Fassung des Datenschutzmodells. CardanoWall ist ein gehostetes Produkt auf Basis eines Gateways und braucht deshalb tatsächlich Account-, Abrechnungs-, Veröffentlichungs- und Indexdaten, um zu funktionieren. Die spannende Frage ist nicht „Sieht CardanoWall überhaupt etwas?“ – das tut es. Die spannende Frage ist, welche Art von Daten es sieht und was für uns verschlüsselt bleibt.

Dieser Artikel geht diese Grenze Kategorie für Kategorie durch.

Welche Account-Daten speichert CardanoWall?

Ganz normale Daten eines gehosteten Dienstes. Je nachdem, wie du das Produkt nutzt, gehören dazu unter Umständen:

• deine Account-Kennung;
• Login-Kennungen wie eine E-Mail-Adresse oder die Referenz auf einen verknüpften OAuth-Account;
• Abrechnungsdaten und dein vorausbezahltes Guthaben;
• API-Key-Metadaten und die gehashte Form von API-Keys (niemals der Klartext-Key);
• Zahlungsdienstleister-Referenzen für Aufladungen;
• Einstellungen auf Account-Ebene;
• Zeitstempel von Account-Aktionen;
• Support- und Betriebsmetadaten;
• Rate-Limit- und Sicherheitslogs.

Das ist genau die Art von Daten, die jeder account-basierte Dienst vorhält. Nichts davon ist dein Identity Seed.

Welche Identitätsdaten kann es sehen?

Öffentliche Identitätsschlüssel – und nichts Privates.

In CardanoWall wird eine Identität deterministisch aus einem einzelnen, 32 Byte großen Identity Seed abgeleitet, und die öffentlichen Schlüssel dieser Identität sind das, was der Dienst für seine Arbeit braucht: deine Identität auflisten, ihre signierten Nachweise zählen, eine Identität nach einer Besitzprüfung mit deinem Account verknüpfen und ein öffentliches Profil anzeigen, wenn du dich für eines entscheidest.

Der Dienst kann also öffentliche Identitätsdaten sehen, etwa:

• den öffentlichen Ed25519-Signaturschlüssel;
• den öffentlichen X25519-Empfangsschlüssel;
• den optionalen hybriden Post-Quanten-Empfangsschlüssel (öffentlich);
• den Erstellungszeitpunkt der Identität in der Service-Datenbank;
• den Verknüpfungsstatus zwischen einem Account und einer Identität;
• alle öffentlichen Profilfelder, die du aktivierst.

Das sind öffentliche oder service-interne Fakten. Es sind weder der private Signaturschlüssel noch der private Empfangsschlüssel, und sie lassen sich nicht in deinen Seed zurückrechnen.

Was muss der Server nie sehen?

Alles, womit er an deiner Stelle handeln könnte. Der Server braucht Folgendes nicht und ist so gebaut, dass er es nicht in nutzbarer Form vorhält:

• Identity Seeds im Klartext;
• private Ed25519-Signaturschlüssel;
• private X25519-Empfangsschlüssel;
• hybride (Post-Quanten-)Empfangsgeheimnisse;
• das Entsperrmaterial, das dein Passkey erzeugt;
• den entschlüsselten Inhalt deines Identitäts-Tresors;
• den entschlüsselten Klartext einer versiegelten Datei.

All das lebt nach dem Entsperren auf deinem Gerät oder in Backups, die du kontrollierst. Die portable, kanonische Kopie einer Identität ist ihr Seed – dieses eine Artefakt, nicht die gehostete Komfortschicht, ist das eigentliche Backup.

Was verrät der verschlüsselte Tresor dem Server?

Dass er existiert – und kaum mehr.

Damit du auf einem neuen Gerät mit einem Passkey entsperren kannst, speichert CardanoWall pro Account eine aktuelle Zeile mit verschlüsseltem Tresor. Der Server kann die Metadaten dieser Zeile lesen – wann sie zuletzt aktualisiert wurde, ihre Versionsnummer und welche registrierten Passkey-Credentials ihr zugeordnet sind –, weil er diese Angaben für die Entsperr-UX und die Lebenszyklus-Verwaltung braucht.

Was der Server nicht kann, ist den Tresor entschlüsseln. Der Tresor ist ein einzelner Chiffretext im age-Stil, der ausschließlich an deine WebAuthn-Passkey-Entsperrfaktoren (PRF-Stanzas) adressiert ist. Es gibt bewusst weder einen passwortabgeleiteten Entsperrpfad noch einen hinzugefügten Public-Key-Empfänger, sodass der gespeicherte Chiffretext nichts offenlegt, was der Server offline durchprobieren könnte. Das ist eine Komfortfunktion der Service-Schicht, keine Verwahrung: Wir halten die verschlossene Box, deine Passkeys halten die einzigen Schlüssel.

Der Klartext des Tresors enthält deine Identity Seeds und deine privaten Anzeige-Labels – genau das Material, das niemals serverlesbar sein darf. Dasselbe Design regelt auch den Entzug: Entfernst du einen Passkey, wird der Tresor an deine verbleibenden Faktoren neu verschlüsselt und der vorherige Chiffretext hart gelöscht, sodass der entfernte Authenticator den aktuellen Tresor nicht mehr öffnen kann. Das ist echter Entzug für den aktuellen Zustand, wenn auch nicht rückwirkend – eine Kopie, die ein Angreifer bereits abgezogen hat und weiterhin öffnen könnte, ist ein eigenes Problem. Wie Passkeys deinen Identitäts-Tresor schützen geht hier tiefer.

Welche Nachweisdaten sind öffentlich?

Der Nachweis selbst. Label-309-Einträge werden auf Cardano genau deshalb veröffentlicht, damit jeder mit der Transaktionsreferenz sie verifizieren kann. Je nach Eintrag können die öffentlichen Daten Folgendes umfassen:

• Content-Hashes;
• die Transaktionsreferenz;
• die Blockzeit, die die Chain zuweist;
• die Struktur des Eintrags;
• Signaturen und öffentliche Signaturschlüssel, wenn der Autor signiert hat;
• Merkle-Wurzeln, bei gebündelten Einträgen;
• Metadaten des verschlüsselten Umschlags;
• inhaltsadressierte Speicher-URIs (ar://, ipfs://);
• die Anzahl der verschlüsselten Empfänger-Slots;
• die Schlüsselaustausch-Familie, die für einen versiegelten Eintrag verwendet wird.

Diese Daten sind bewusst öffentlich: Genau sie machen einen Nachweis verifizierbar, ohne CardanoWall vertrauen zu müssen. Beachte bei einem versiegelten Eintrag, was nicht dabei ist – der Klartext der Datei kommt niemals auf die Chain. Ein Beobachter kann sehen, dass ein Eintrag versiegelt ist, wie viele Empfänger-Slots er hat und welche Schlüsselaustausch-Familie er nutzt, aber nicht, wer die Empfänger sind, und nicht den Inhalt.

Was können Storage-Gateways sehen?

Gespeicherte Bytes und Anfrage-Metadaten.

Wenn ein Eintrag auf Inhalte bei Arweave oder IPFS verweist, können die öffentlichen Gateways, die diese Bytes ausliefern, die Anfragen danach sehen. Bei einer öffentlichen Datei sind diese Bytes Klartext. Bei einer versiegelten Datei sind diese Bytes Chiffretext, und sie sollten ohne den privaten Schlüssel des Empfängers unlesbar bleiben.

Gateways können außerdem Timing, Objektgröße und Anfragemuster beobachten. Sie sind kein Ort, an dem man Vertrauen für Vertraulichkeit ablegt. Das ist der ganze Grund, eine sensible Datei zu versiegeln, bevor sie in den Speicher geht, statt sich darauf zu verlassen, dass die Speicherschicht sie privat hält.

Was kann der Browser sehen, solange du entsperrt bist?

Alles, was er braucht, um als deine Identität zu handeln – solange die Sitzung entsperrt ist.

Nach dem Entsperren liegen deine Identity Seeds und die daraus abgeleiteten privaten Schlüssel im Session-Speicher deines Browsers, damit die App signieren und entschlüsseln kann. Wenn du eine versiegelte Datei entschlüsselst, ist der Klartext ebenfalls im Browser. Beim Sperren oder Abmelden wird dieses In-Memory-Material nach bestem Bemühen mit Nullen überschrieben.

Das ist clientseitiger Datenschutz, und er ist ehrlich über seine Grenzen. Geheimnisse auf deinem Gerät zu halten schützt dich vor der Verwahrung durch den Server, bedeutet aber, dass dein Gerät und deine Browser-Umgebung eine Rolle spielen. Eine bösartige Browser-Erweiterung, feindselige lokale Software oder eine aktive Cross-Site-Scripting-Lücke während einer entsperrten Sitzung können lesen, was im Speicher liegt. Strikte Content-Security-Header, ein Entsperrablauf mit minimalem Skript und das Entsperren nur bei expliziter Aktion verringern diese Angriffsfläche alle – beseitigen können sie sie aber nicht. Nutze für sensible Identitäten ein Gerät, dem du vertraust; Browser-Speicher und Session-Schlüssel erklärt genau, was zwischengespeichert wird und was nicht.

Was kann das Adressbuch verraten?

Deine Kontaktliste ist Servicedaten, und sie kann auf ihre eigene Weise sensibel sein.

Vertrauenswürdige Kontakte sind account-lokale Einträge, die dir ersparen, jedes Mal lange öffentliche Schlüssel einzufügen, wenn du eine Datei für jemanden versiegelst. Ein Eintrag kann einen Anzeigenamen, einen öffentlichen Signaturschlüssel, optionale Empfangsadressen (klassisch und post-quantum), das Wie und Wann deiner Verifizierung des Kontakts sowie freie Notizen enthalten.

Das sind keine Identity Seeds, aber eine Liste, mit wem du korrespondierst, kann Beziehungen und Arbeitsabläufe verraten. CardanoWall protokolliert so, dass das ruhig bleibt: Die serverseitigen Aktionen, die Kontakte anlegen und bearbeiten, halten nur eine Anfrage-Kennung und deine Account-Kennung fest – niemals den Namen, die Schlüssel, die Notizen oder die Verifizierungsmethode des Kontakts.

Was verspricht CardanoWall nicht?

Es verspricht keine Unsichtbarkeit.

CardanoWall ist kein Anonymitätsnetzwerk. Die Blockchain, die Storage-Gateways, das Zahlungssystem, dein Account-Login, dein Browser und dein Netzwerkpfad können alle Metadaten preisgeben. Einen unsignierten versiegelten Eintrag zu veröffentlichen hält Absender, Empfänger und Klartext aus dem Label-309-Eintrag selbst heraus – aber das ist Datenschutz auf Eintragsebene, keine vollständige Anonymität. Die gebührenzahlende Cardano-Adresse, deine IP, wie sie Gateways sehen, und ähnliche Signale leben außerhalb des Eintrags und außerhalb dieser Garantie.

Es macht ein kompromittiertes Gerät auch nicht sicher. Läuft auf deiner entsperrten Sitzung bösartiger Code, kann dieser Code sehen, was du sehen kannst.

Und ein veröffentlichter Nachweis ist per Design öffentlich. Er zeigt, dass bestimmte Bytes zu einem bestimmten öffentlichen Zeitpunkt existierten. Er beweist für sich genommen weder, wer sie verfasst hat, noch, wem sie gehören, noch, dass ihr Inhalt wahr ist – siehe was ein Nachweis nicht beweist für diese Grenze.

Die Kurzfassung

CardanoWall kann Servicedaten und öffentliche Nachweisdaten sehen. Per Design sieht es weder deinen Identity Seed im Klartext noch deine privaten Schlüssel noch den Klartext deines Tresors noch den Klartext einer versiegelten Datei.

In der Praxis heißt das: Versiegle sensible Dateien, bevor sie dein Gerät verlassen, bewahre eine sichere Kopie deines Seeds auf, entsperre auf Geräten, denen du vertraust, und behandle alles, was du on chain veröffentlichst, als dauerhaft öffentlich.

Guter Datenschutz beginnt damit, genau zu wissen, wo jede Art von Daten lebt – und CardanoWall ist so gebaut, dass die Daten, die am meisten zählen, bei dir leben.

Weiterführende Lektüre

CardanoWall ist die Referenzimplementierung von Label 309, einem offenen, anbieterneutralen Existenznachweis-Standard. Der Standard wurde in den Cardano-CIP-Prozess eingereicht und wird derzeit von den CIP-Editoren als Vorschlag der Kategorie Metadata geprüft (offener Pull Request). Der kryptografische Kern, die SDKs und die Kommandozeilenwerkzeuge sind quelloffen unter github.com/cardanowall, sodass du genau prüfen kannst, was auf deinem Gerät berechnet wird, statt uns beim Wort zu nehmen.