Warum deine Schlüssel das Gerät nie verlassen

In CardanoWall bleiben deine privaten Schlüssel auf deinem Gerät. Die Software, die signiert, versiegelt, probeweise entschlüsselt und verifiziert, läuft lokal; das gehostete Gateway ist darauf ausgelegt, weder deinen Identity Seed noch deinen Signaturschlüssel, deine Empfängerschlüssel oder das Material zu erhalten, das eine versiegelte Datei entschlüsselt.

Das Gateway hat auch ohne diese Geheimnisse genug zu tun. Es kann einen Preis kalkulieren, bereits verschlüsselten Chiffretext zur Speicherung annehmen, eine Cardano-Transaktion einreichen, Einträge indexieren und dein Guthaben verfolgen. Nichts davon braucht die Schlüssel, die Urheberschaft belegen oder eine versiegelte Nutzlast öffnen. Die Trennung ist gewollt: Der Dienst hilft, den Nachweis zu bewegen, und du behältst die Geheimnisse.

Von welchen Schlüsseln reden wir?

Eine Label 309-Identität beginnt mit einem einzigen Wert: einem 32 Byte großen Identity Seed. Aus diesem Seed leitet jede konforme Software die Schlüssel ab, die eine Identität tatsächlich verwendet, in drei Rollen:

• ein Ed25519-Schlüssel, der Einträge signiert;
• ein X25519-Schlüssel, der klassisch versiegelte Einträge empfängt;
• ein hybrider Post-Quanten-Schlüssel, der Post-Quanten-versiegelte Einträge empfängt.

Die Ableitung ist deterministisch. Dieselben 32 Byte erzeugen in jedem konformen Client immer dieselben drei Schlüsselpaare. Genau das macht den Seed portabel – und genau das macht ihn zur einzigen Sache, die es zu schützen gilt. Wer den Seed besitzt, kann die Identität wiederherstellen, in ihrem Namen signieren und an sie adressierte versiegelte Einträge entschlüsseln. Also bleibt der Seed privat, und alles Weitere ergibt sich daraus.

Was macht der Client lokal?

Der Client übernimmt jeden Vorgang, der einen privaten Schlüssel berührt:

• einen Identity Seed erzeugen oder importieren;
• die Signatur- und Empfangsschlüssel daraus ableiten;
• Einträge signieren;
• Dateien vor dem Upload verschlüsseln;
• die versiegelten Empfänger-Slots bauen, die einen Content-Schlüssel umhüllen;
• eingehende Einträge probeweise entschlüsseln, um die an dich adressierten zu finden;
• Chiffretext entschlüsseln und den Klartext-Hash neu berechnen;
• Signaturen und Eintragsstruktur verifizieren.

Die Web-App, die Desktop-App, das Kommandozeilen-Werkzeug und jede auf den SDKs aufbauende Software unterscheiden sich darin, wie sie Schlüssel speichern und wie sie sie entsperren. Das Prinzip ändert sich zwischen ihnen nicht: Privates Schlüsselmaterial wird nicht an das Gateway gesendet.

Was macht dann das Gateway?

Das Gateway betreibt die Veröffentlichungs-Pipeline. Es kann:

• einen Kostenvoranschlag berechnen;
• bereits verschlüsselten Chiffretext entgegennehmen und eine inhaltsadressierte URI zurückgeben;
• einen vorbereiteten Nachweis-Eintrag annehmen;
• eine Cardano-Transaktion einreichen und auf die Bestätigung warten;
• Chain-Reorganisationen behandeln und automatisch erstatten, wenn eine Veröffentlichung dauerhaft scheitert;
• Einträge in einen geteilten Feed indexieren;
• dein Kontoguthaben verfolgen;
• seine API bereitstellen und Lifecycle-Events aussenden.

Das sind echte Aufgaben, und sie machen den Großteil der operativen Arbeit aus. Doch keine einzige davon braucht einen Schlüssel, der deine versiegelten Inhalte entschlüsselt. Das Gateway ist eine Transport- und Betriebsschicht. Es ist nicht dein Identitäts-Tresor, und es ist auch nicht dafür ausgelegt, sich wie einer zu verhalten.

Warum ist diese Trennung wichtig?

Weil ein Nachweis verifizierbar bleiben sollte, ohne dem Dienst zu vertrauen, der ihn erstellen half.

Hielte ein gehosteter Dienst die einzige Kopie deiner Schlüssel, würde dieser Dienst zu deiner Vertrauenswurzel. Stellt er den Betrieb ein, ändert seine Bedingungen, erleidet einen Einbruch oder sperrt dein Konto, könnte deine Fähigkeit, zu signieren, zu entschlüsseln oder auch nur zu verifizieren, davon abhängen. Genau diese Lage soll Label 309 verhindern.

Ein Label-309-Eintrag ist aus öffentlichen Daten verifizierbar. Ein Verifizierer braucht nur die Transaktions-Metadaten, optional die Inhaltsbytes und einen öffentlichen Cardano-Explorer – an keinem Schritt einen Herausgeber-Server. Ein versiegelter Eintrag lässt sich vom Schlüsselinhaber öffnen. Ein signierter Eintrag lässt sich gegen seinen Signaturschlüssel prüfen. Das Gateway kann das Veröffentlichen enorm erleichtern, aber per Design kann es eine korrekt versiegelte Nutzlast nicht lesen, bloß weil es geholfen hat, sie on chain zu bringen.

Das ist der Unterschied zwischen einem Dienst, der dir sagt, dass er einen Nachweis hat, und einem Nachweis, der für sich allein steht.

Kann das Gateway meine versiegelten Dateien lesen?

Wenn der Client den Inhalt korrekt versiegelt hat, nein – das Gateway sieht immer nur Chiffretext.

So ist ein versiegelter Eintrag aufgebaut. Der öffentliche on-chain Eintrag legt sich auf den Klartext-Hash fest – dieser Hash plus die Blockzeit sind der Nachweis des Zeitpunkts. Die verschlüsselte Nutzlast selbst kommt nie auf die Chain; sie liegt an einer inhaltsadressierten URI (etwa ar://). Der Content-Schlüssel wird für einen oder mehrere öffentliche Empfängerschlüssel umhüllt, ein Slot pro Empfänger. Der Empfänger (oder der Absender) ruft den Chiffretext ab, entschlüsselt ihn lokal und berechnet den Klartext-Hash neu, um zu bestätigen, dass er zum on-chain Commitment passt.

Das Gateway kann sehen, dass ein versiegelter Eintrag existiert, und es kann Chiffretextgröße, Upload-Zeitpunkt, Kontoaktivität, Transaktionsstatus und die öffentlichen Metadaten beobachten. Es ist nicht dafür ausgelegt, den Klartext zu sehen, und ohne den richtigen privaten Schlüssel bleibt der Chiffretext unlesbar. Zwei ehrliche Vorbehalte gehören dazu: Versiegeln schützt Vertraulichkeit, nicht Anonymität – beobachtbare Metadaten sind weiterhin Metadaten –, und ein Empfänger, der eine Datei entschlüsselt, kann den Klartext danach jederzeit weitergeben. Verschlüsselung schützt die Bytes bei der Übertragung und im Ruhezustand, nicht das, was ein berechtigter Leser anschließend damit tut.

Kann das Gateway einen gültigen Nachweis fälschen?

Es ist so ausgelegt, dass es keinen ungültigen Nachweis durch eine unabhängige Verifizierung bringen kann.

Ein Verifizierer prüft den on-chain Eintrag, die Eintragsstruktur, die Hashes, die Signaturen und – bei einem versiegelten Eintrag, den er öffnen kann – den neu berechneten Klartext-Hash. Hätte ein Gateway über eine Transaktion gelogen, die Eintragsbytes verändert, eine Signatur weggelassen oder auf Bytes verwiesen, die nicht zum festgelegten Hash passen, sollte ein unabhängiger Verifizierer das auffangen.

Das ist ein präzises Versprechen, und man sollte es nicht überdehnen. Ein Gateway kann sich weiterhin auf gewöhnliche betriebliche Weise daneben benehmen: Es kann die Veröffentlichung verfehlen, eine Transaktion verzögern, einen Fehler zurückgeben, seinen eigenen Status falsch melden, einen Ausfall haben oder dir ein schlechtes Erlebnis bescheren. Was es nicht können sollte, ist, einen ungültigen Nachweis in einen zu verwandeln, der sauber gegen öffentliche Daten verifiziert. Komfort kann versagen; der kryptografische Anspruch hängt nicht davon ab, dass das Gateway ehrlich ist.

Was ist konkret mit der Web-App?

Die Web-App ist Software, die in einem Browser läuft, und das prägt ihr Vertrauensmodell.

Die relevante Grenze umfasst den Browser, den geladenen Anwendungscode, alle installierten Erweiterungen, das Gerät selbst und den Entsperr-Ablauf. Ein Browser ist komfortabel, aber er ist nicht dieselbe Umgebung wie ein Desktop-Tresor oder ein Kommandozeilen-Werkzeug, das aus einem Build läuft, den du kontrollierst. Ein bösartiges Skript in einer entsperrten Sitzung kann Geheimnisse im Speicher lesen; eine strikte Content-Security-Policy, minimale Skripte und ein expliziter Entsperr-Schritt verringern diese Angriffsfläche, doch keine Web-App kann behaupten, sie zu beseitigen.

Das ist ein Grund, warum es einen eigenen Desktop-Client gibt, für alle, die lokale Speicherung und mehr Kontrolle darüber wollen, wie Schlüssel gehalten werden. Die Invariante gilt über jeden Client hinweg – das Gateway braucht deine privaten Schlüssel nicht –, auch wenn jeder Client diese Schlüssel unterschiedlich schützt. Für eine ausführlichere Darstellung, wo die Linie verläuft, sieh dir an, was CardanoWall sehen kann und was nicht.

Was ist mit der Desktop-App?

CardanoWall Desktop ist eine quelloffene, plattformübergreifende Anwendung, die von Anfang an um einen lokalen, verschlüsselten Tresor herum gebaut ist.

Ein Rust-Kern verwaltet den Identitäts-Tresor, die Kryptografie, die Sync-Engine, die Probeentschlüsselung und die Verifizierung, mit einem Webview, das nur die Oberfläche darstellt. Seeds und abgeleitete private Schlüssel werden dem Webview nicht als gewöhnliche JavaScript-Strings übergeben; wenn Inhalt vorab angezeigt werden muss, werden entschlüsselte Bytes über einen dedizierten Kanal an die Ansicht gestreamt, statt als String durch die Seite zu laufen. Geheimnisse werden nicht an das Gateway gesendet, und sie gelangen nicht in den Renderer.

Diese Architektur verengt die Angriffsfläche; sie tilgt sie nicht. Ein kompromittiertes Betriebssystem, eine bösartige Abhängigkeit, ein Keylogger oder vom Nutzer freigegebene Schadsoftware können lokale Sicherheit immer noch aushebeln – dieselbe ehrliche Grenze, die jede Desktop-Wallet trägt. Schlüssel aus dem Gateway und aus dem Renderer herauszuhalten, ist eine spürbare Verbesserung, keine Garantie gegen einen vollständig kompromittierten Host. Wie es im Detail funktioniert, zeigt der Überblick zu CardanoWall Desktop und zu Offline-Nachweisen.

Was ist mit dem Kommandozeilen-Werkzeug und den SDKs?

Sie sind wichtig, weil sie dasselbe Modell ohne die Website verfügbar machen.

Ein Entwickler kann einen Seed lokal behalten, Einträge lokal signieren, Dateien lokal versiegeln und über jedes beliebige Gateway einreichen. Ein Continuous-Integration-System kann mit eng begrenzten API-Zugangsdaten veröffentlichen, während Identitätsmaterial unter der eigenen Kontrolle des Teams bleibt. Ein Unternehmen kann seinen eigenen Client bauen oder Label 309 in vorhandene Software einbinden. Die Aufteilung bleibt dieselbe, egal zu welcher Schnittstelle du greifst: Das Gateway veröffentlicht, der Client hält die Geheimnisse.

Das Kommandozeilen-Werkzeug und die SDKs sind quelloffen und gateway-unabhängig, sodass du die Grenze prüfen kannst, statt sie auf Vertrauen hinnehmen zu müssen.

Was sollte niemals an ein Gateway gesendet werden?

Sende diese Dinge niemals an ein Gateway – oder an irgendeine Website:

• deinen L309-SEED-1… Identity Seed;
• den rohen Seed in Hex;
• einen privaten Signaturschlüssel;
• einen privaten X25519-Empfangsschlüssel;
• ein hybrides Post-Quanten-Empfangsgeheimnis;
• eine Passphrase, die versiegelte Inhalte entschlüsselt;
• Klartext, den du privat halten wolltest.

Das Gateway braucht möglicherweise legitim öffentliche Schlüssel, öffentliche Signaturen, die öffentlichen Eintragsbytes, Chiffretext, Kostenvoranschlag-Kennungen, API-Tokens und Kontokennungen. Das ist kein privates Identitätsmaterial. Die Regel ist einfach: Wenn dich ein Ablauf auffordert, irgendwo ein Geheimnis einzufügen, halt inne und frag warum.

Worauf musst du trotzdem achten?

Lokale Schlüssel sind nur so sicher wie die Umgebung um sie herum. Kryptografie hält ein Gateway aus deinen Geheimnissen heraus; sie kann keinen Seed schützen, den ein Nutzer in ein vom Angreifer kontrolliertes Formular kopiert. Also musst du trotzdem:

• deinen Identity Seed schützen und ein echtes Backup davon aufbewahren;
• die Empfangsadresse eines Empfängers prüfen, bevor du etwas Sensibles versiegelst;
• Phishing-Seiten meiden;
• bewusst mit Browser-Erweiterungen umgehen;
• deine Geräte aktuell halten;
• Festplattenverschlüsselung nutzen, wo es passt;
• verstehen, wie entschlüsselte Dateien zwischengespeichert werden;
• vertrauenswürdige Builds der Desktop- und Kommandozeilen-Werkzeuge ausführen;
• Richtlinien zur Schlüsselverwaltung für geteilte oder Team-Abläufe festlegen.

Es lohnt sich, bei den Fehlerfällen deutlich zu werden, denn sie sind nicht symmetrisch. Verlierst du den Seed und deine Entsperr-Faktoren, ist die künftige Nutzung dieser Identität dahin – wobei alle bereits veröffentlichten Nachweise für immer aus öffentlichen Daten verifizieren. Ein gestohlener Seed ist eine vollständige Identitätskompromittierung: Die Reaktion ist, eine neue Identität zu erstellen und die alte zu deaktivieren, nicht ein Passwort zurückzusetzen. Es gibt kein Zurücksetzen; das ist der Preis dafür, dass es keinen Verwahrer gibt.

Warum das für einen offenen Standard wichtig ist

Ein offener Nachweis-Standard sollte nicht von einem einzigen vertrauenswürdigen Betreiber abhängen.

Würde CardanoWall morgen verschwinden, sollte ein Label-309-Eintrag weiterhin etwas bedeuten. Betreibt ein Unternehmen sein eigenes Gateway, sollten seine Einträge weiterhin standardkonform sein. Exportierst du deinen Seed in einen anderen konformen Client, sollte er exakt dieselben Schlüssel ableiten. Das funktioniert nur, wenn die Grenze sauber bleibt: Einträge sind standardkonform, Verifizierung ist unabhängig, Gateways sind austauschbar, Clients halten die Geheimnisse, und du kannst die Identitätswurzel jederzeit selbst sichern.

„Schlüssel verlassen das Gerät nie“ ist also kein Slogan. Es ist Teil dessen, was einen Existenznachweis portabel macht – ein Nachweis, den du über jeden einzelnen Dienst hinaustragen kannst, auch über diesen.

Die Kurzfassung

Das Gateway hilft, den Nachweis zu veröffentlichen. Der Client hält die Geheimnisse.

Private Schlüssel werden nicht an das Gateway gesendet. Inhalte werden vor dem Upload verschlüsselt. Das Entschlüsseln passiert lokal. Verifizierung hängt nicht davon ab, dem Wort eines Dienstes zu vertrauen. Das ist die Sicherheitsform, auf der CardanoWall aufbaut – und die Form, die Label 309 offen halten soll.

Weiterführende Lektüre

• Deine Identität ist ein Seed – was der Identity Seed ist und warum er das eigentliche Backup ist.
• Wie CardanoWall deine Identität speichert – der verschlüsselte Tresor und was der Server entschlüsseln kann und was nicht.
• Was ein Nachweis nicht beweist – die ehrlichen Grenzen von Zeitpunkt-und-Integritäts-Nachweisen.
• Der Label-309-Standard auf label309.org, eingereicht beim Cardano-CIP-Prozess und in Prüfung durch die CIP-Editoren.
• Die quelloffenen Clients, SDKs und das Gateway auf github.com/cardanowall.