e.V.
Lösungen · Protokoll · Beta · geprüft 2026-05-21

BYOK-Vault — der Verein sieht den Klartext nicht

Für sensible Inhalte gibt es einen Zero-Knowledge-Modus: der Verschlüsselungs-Schlüssel liegt nur auf den Geräten der Nutzerin, der Server speichert ausschließlich Chiffretext. Auch wir können den Inhalt dann nicht entschlüsseln.

These
Der einzige Anbieter, dem man Daten ohne Vertrauen anvertrauen kann, ist der, der sie technisch nicht sehen kann — auch wenn er wollte.
Was wir tun

Es gibt einen einfachen Gradmesser für Daten-Souveränität: kann der Anbieter, wenn er wollte, den Inhalt sehen? Wenn ja, dann ist das, was zwischen ihm und dem Klartext steht, Vertrauen — eine Datenschutz- Erklärung, eine Compliance-Abteilung, ein Audit. Vertrauen ist gut. Es ist nur weniger gut als das technische Unvermögen.

Der Vault-Modus ist unsere Antwort darauf. Für sensible Inhalte — private Notizen, intime Listen, vertrauliche Sprachaufnahmen — gibt es einen Schaltmodus, in dem der Verschlüsselungs-Schlüssel ausschließlich auf den Geräten der Nutzerin existiert. Wir verschlüsseln im Client, schicken Chiffretext an sync2, und der Server speichert ihn, ohne ihn lesen zu können. Auf dem nächsten Gerät, das mit demselben Schlüssel gekoppelt ist, entschlüsseln wir wieder.

Das ist nicht das gleiche wie „server-side encryption at rest”. Es ist auch nicht das gleiche wie das, was die meisten kommerziellen Anbieter „Ende-zu-Ende-Verschlüsselung” nennen — weil wir nicht im Besitz des Schlüssels sind. Es heißt: wenn ein Gericht uns zwingen würde, alles herauszugeben, was wir über eine Person haben, wäre das Ergebnis ein Berg unbrauchbarer Chiffretext-Zellen. Nicht weil wir es kompliziert gemacht haben, sondern weil der Schlüssel woanders ist.

Das hat eine harte Kehrseite. Wenn alle gekoppelten Geräte verloren gehen, sind die Inhalte unwiderruflich verloren. Wir können nicht helfen. Das ist nicht ein Versäumnis, das ist die Bedingung dafür, dass wir vorher auch nicht helfen können. Wir kommunizieren das offen, weil das einzige Schlimmere als kein Vault ein Vault wäre, dem man den Schlüssel-Auffang heimlich hinten anbaut.

Umsetzung

Wie genau das funktioniert

  • AES-GCM-256 als Verschlüsselungs-Verfahren, Schlüssel-Erzeugung client-seitig (Web Crypto API / Apple CryptoKit).
  • Master-Key liegt in der Keychain / im IndexedDB-Vault des Endgeräts, geräte-übergreifend nur via QR-Code-Kopplung oder explizitem Export.
  • Events werden vor dem Schreiben in `sync2` verschlüsselt — der Server sieht Akteur, Zeitstempel und Schema-Hash, aber nicht den Inhalt.
  • Such-Indizes sind clientseitig (lokales SQLite/IndexedDB), keine serverseitige Volltextsuche über verschlüsselten Inhalt.
  • Beim Verlust aller gekoppelten Geräte ist der Inhalt *unwiderruflich* verloren. Das ist die ehrliche Kehrseite, kein Bug.
Trade-offs

Was uns das kostet

Jeder Lösung hat einen Preis. Diese hier zahlen wir bewusst — weil das, was wir damit erreichen, mit nachgelagerten Tricks nicht ehrlich zu bauen ist.

  • Schlüsselverlust ist Daten-Verlust. Wir können nicht „helfen, wieder reinzukommen" — der Preis dafür, dass wir nicht reinkönnen.
  • Cross-App-Suggestions, KI-Empfehlungen über alle Daten hinweg und Server-seitige Volltextsuche werden im Vault-Modus funktionell eingeschränkt oder rein lokal ausgeführt.
  • Geräte-Kopplung ist ein UX-Bottleneck. Wir arbeiten daran, aber sie wird nie so reibungslos sein wie „Login mit Passwort irgendwo".
Stand

Offene Punkte

  • Geräte-Kopplung per QR ist implementiert, aber nicht in allen Apps einheitlich. Ziel ist ein gemeinsamer Flow über `@mana/byok-vault`.
  • Recovery-Codes als optionaler dritter Pfad neben Geräte-Kopplung — bewusst opt-in, weil sie das Bedrohungs-Modell ändern.

Lösungen sind die strukturellen Antworten des Vereins. Werte sagen, wonach wir uns ausrichten; Probleme sagen, wogegen; Lösungen sagen, was wir daraus baulich machen.