Kann LifeWyn meinen Tresor lesen?

Nein. Ihr Tresor wird auf Ihrem eigenen Gerät verschlüsselt, bevor irgendetwas hochgeladen wird, und die Passphrase, die ihn entsperrt, verlässt Ihr Gerät nie. Was unsere Server erreicht, ist Chiffretext – es gibt nichts Lesbares für uns, für eine an uns zugestellte gerichtliche Anordnung oder für jemanden, der in die Datenbank eindringt.

Welche Chiffre verwendet LifeWyn, und warum diese?

XChaCha20-Poly1305, eine authentifizierte Chiffre, die Ihre Daten sowohl verbirgt als auch Manipulationen erkennt. Ihr erweiterter 192-Bit-Nonce kann zufällig erzeugt werden, ohne realistische Chance einer Wiederverwendung, was eine ganze Klasse von Implementierungsfehlern beseitigt, die bei Konstruktionen mit schmalerem Nonce bereits echte Sicherheitsvorfälle verursacht hat.

Was passiert, wenn ich meine Tresor-Passphrase vergesse?

LifeWyn kann sie nicht zurücksetzen, weil es auf unserer Seite nichts zum Zurücksetzen gibt – wir besitzen Ihren Schlüssel nie. Deshalb muss die Wiederherstellung über Ihre vertrauten Kontakte oder Schlüsselanteile im Voraus eingerichtet werden; sie ist der einzige Weg zurück, und es lohnt sich, ihn frühzeitig einzurichten.

Wenn mein Tresor Zero-Knowledge ist, wie kann LifeWyn einen Todesfall verifizieren oder einen Begünstigten benachrichtigen?

Weil Verifizierung und Tresorinhalte getrennte Dinge sind. Verifizierung stellt nur fest, ob ein zulässiges Ereignis eingetreten ist – ein versäumtes Lebenssignal, eine validierte Urkunde – und arbeitet mit dem Mindestmaß an Informationen, das dieser Schritt benötigt. Sie entsperrt niemals Ihren verschlüsselten Tresor, Ihre Passwörter oder nicht damit zusammenhängende Vermögenswerte. Zero-Knowledge-Tresor bedeutet nicht Zero-Knowledge-Verifizierung.

Wovor schützt Verschlüsselung nicht?

Ein Gerät, das bereits durch Malware kompromittiert ist, während Sie angemeldet sind, eine schwache oder wiederverwendete Passphrase, das eigenständige Weitergeben der Passphrase, und was ein Empfänger nach einer abgeschlossenen Freigabe mit Informationen macht. Verschlüsselung schützt Daten im Ruhezustand und bei der Übertragung – sie kann diese Fälle nicht beheben.

Sicherheitszentrum → Verschlüsselung

Zero-Knowledge-Verschlüsselungsarchitektur

Sechs Schichten kryptografischen Schutzes. Ihre Daten werden auf Ihrem Gerät verschlüsselt, bevor sie es je verlassen. Wir speichern nur Chiffretext.

XChaCha20-Poly1305

scrypt (N=2^15)

HKDF-SHA-256

Shamir Secret Sharing

TLS 1.2 / 1.3

Das Prinzip der Mindestinformation

Zero-Knowledge-Tresor ≠ Zero-Knowledge-Verifizierung

Ihr Tresor bleibt versiegelt. Die Verifizierung sieht immer nur die eine Tatsache, die sie braucht — dass ein zulässiges Ereignis eingetreten ist.

LifeWyn hält den Inhalt Ihres Tresors verschlüsselt und für uns unerreichbar. Ihre Dokumente, privaten Nachrichten, Medien und sonstigen geschützten Inhalte werden verschlüsselt, bevor sie Ihr Gerät verlassen, und wir besitzen keine Schlüssel, um sie einzusehen.

Ein Vermächtnisdienst muss allerdings mehr leisten, als eine versiegelte Box zu verwahren. Lebenssignal, Verifizierung des Todesfalls, Benachrichtigung der Begünstigten, Anspruchsabläufe und Ihre Vermächtnisanweisungen hängen alle davon ab, festzustellen, ob tatsächlich etwas eingetreten ist — und ein System, das für jede Tatsache blind ist, kann nichts verifizieren. Deshalb arbeiten wir nach dem Prinzip der Mindestinformation: Bei jedem Schritt verarbeitet LifeWyn nur das, was dieser Schritt erfordert, und nicht mehr.

Verifizierung

stellt fest, ob ein zulässiges Ereignis eingetreten ist.

Ihre Regeln

entscheiden, was als Nächstes geschehen darf.

Ihre Verschlüsselung

schützt den eigentlichen Inhalt Ihres Tresors.

Tresorzugriff

Der verschlüsselte Inhalt Ihres Tresors — Dokumente, private Nachrichten, Medien und Zugangsdaten.

Benötigt Ihre Schlüssel, die Ihr Gerät nie verlassen. Kein Mitglied des LifeWyn-Teams und kein serverseitiger Prozess kann ihn öffnen.

Fallzugriff

Ein einzelner Verifizierungsfall — zum Beispiel ein Totenschein, den ein Begünstigter einreicht.

Eine für diesen Fall autorisierte prüfende Person sieht nur, was der Fall erfordert. Diese Berechtigung reicht nie in Ihren Tresor hinein.

Verifizierungszugriff

Ob ein zulässiges Ereignis tatsächlich eingetreten ist — ein verpasstes Lebenssignal, ein geprüfter Totenschein.

Beantwortet „Ist das eingetreten?“, niemals „Was befindet sich im Tresor?“.

Ein von einem Begünstigten eingereichter Totenschein etwa kann geprüft werden, um einen gemeldeten Todesfall zu bestätigen. Diese Prüfung entsperrt niemals den Tresor, die Passwörter oder andere Inhalte der Kundin oder des Kunden — sie bleiben durchgehend verschlüsselt. Jeder Schritt, von Verifizierung und Prüfung über Benachrichtigung bis zu Begünstigtenzugriff und Offenlegung, ist durch Ihre konfigurierten Regeln und die geringstmögliche dafür nötige Information begrenzt.

Sechsstufiger Schutz

Jede Schicht hat einen Zweck

Von Ihrem Master-Passwort bis zu unseren Servern — jede Schicht verstärkt den mehrstufigen Schutz.

Tresor-Passphrase & Biometrie

Sie geben Ihre Tresor-Passphrase ein (getrennt von Ihrem Konto-Anmeldepasswort), optional mit biometrischer Entsperrung

scrypt (N=2^15), speicherintensiv → 256-Bit-Hauptschlüssel

Schlüsselableitung

Der Hauptschlüssel leitet Kategorieschlüssel per HKDF-SHA-256 mit Domänentrennung ab

HKDF-SHA-256 mit Kontext-Labels: 'vault', 'credentials', 'documents' usw.

Verschlüsselung von Elementen und Dokumenten

Asset-Schlüssel werden aus dem Kategorieschlüssel abgeleitet; jedes Dokument erhält einen frischen zufälligen Schlüssel, der unter diesem Kategorieschlüssel verpackt wird

XChaCha20-Poly1305 (AEAD) — eine Chiffre für Tresor-Elemente und Dateibytes gleichermaßen

Umschlagverschlüsselung

DEKs werden mit Kategorieschlüsseln umhüllt; nur Chiffretext verlässt das Gerät

NIST SP 800-38F Key Wrapping; authentifizierte Verschlüsselung (AEAD)

Schwellenwert-Secret-Sharing

Der Tresor-Hauptschlüssel wird in N Anteile aufgeteilt; K sind für die Rekonstruktion erforderlich

Shamir's Secret Sharing over GF(2^8)

Serverspeicher

Nur Chiffretext + verschlüsselte Schlüssel-Umschläge gespeichert; null Klartext

PostgreSQL (Chiffretext-Blobs); Redis (Sitzung); Objektspeicher (Dateien)

Algorithmus-Spezifikationen

Kryptografische Grundbausteine — keine eigene Kryptografie

Wir verwenden ausschließlich standardisierte, bewährte Algorithmen. Keine proprietären Konstruktionen.

XChaCha20-Poly1305

Jedes Tresor-Element und jedes Dokumentbyte – es gibt keine zweite Verschlüsselung für Inhalte

Stärke

256-Bit-Schlüssel, 192-Bit-Nonce (zufällige Nonces, kein Wiederverwendungsrisiko), 128-Bit-Poly1305-Tag

Standard

RFC 8439 (XChaCha20-Konstruktion mit erweitertem Nonce)

scrypt

Streckt Ihre Tresor-Passphrase zu Ihrem 256-Bit-Master-Schlüssel, auf Ihrem Gerät

Stärke

Speicherintensiv; N=2^15, r=8, p=1; Salt pro Benutzer; NFKC-normalisierte Eingabe

Standard

RFC 7914

Argon2id

Hasht Ihr KONTO-ANMELDEPASSWORT, serverseitig. Ein anderes Passwort; es leitet keine Schlüssel ab

Stärke

Speicherintensives Passwort-Hashing; wird nie auf die Tresor-Passphrase angewendet

Standard

RFC 9106 / Gewinner der Password Hashing Competition

HKDF-SHA-256

Ableitung der Schlüsselhierarchie (Master- → Kategorie- → Asset-Schlüssel)

Stärke

SHA-256-PRF; Domänentrennung über den Info-Parameter

Standard

RFC 5869

TLS 1.2 / 1.3

Der gesamte Netzwerkverkehr (API, WebSocket, Datei-Upload/-Download)

Stärke

TLS 1.2 als Mindeststandard, 1.3 bevorzugt; Perfect Forward Secrecy

Standard

RFC 8446 / RFC 5246

Shamir Secret Sharing

Schwellenwert-basierte Aufteilung des Tresor-Schlüssels (z. B. 3 von 5)

Stärke

GF(2^8)-Feld; einfaches Shamir – Anteile tragen keine Verifizierbarkeits-Zusicherungen

Standard

Adi Shamir 1979; RFC 9570 (Entwurf)

Bedrohungsmodell

Wogegen wir schützen — und wie

Ehrliche Einschätzung der Angriffsvektoren und unserer Gegenmaßnahmen.

Serverkompromittierung

Kritisch

Der Server hält ausschließlich Chiffretext + umhüllte DEKs. Kein Hauptschlüssel, keine Kategorieschlüssel, kein Klartext berühren jemals den Server.

Datenbankleck

Kritisch

Gespeicherte Tresordaten sind XChaCha20-Poly1305-Chiffretext. Ohne Ihren Hauptschlüssel — der Ihr Gerät nie verlässt — ist eine Entschlüsselung praktisch unmöglich. Kontaktdaten von Ihnen und Ihren Begünstigten sind NICHT im Ruhezustand verschlüsselt: LifeWyn kann keine Begünstigte oder keinen Begünstigten benachrichtigen oder verifizieren, deren Adresse es nicht lesen kann.

Man-in-the-Middle

Hoch

TLS 1.2 als Mindeststandard, 1.3 bevorzugt, Certificate Pinning auf Mobilgeräten und HSTS mit includeSubDomains bei jeder Antwort.

Gerätediebstahl

Hoch

Der Hauptschlüssel wird stets nur mit scrypt neu aus Ihrer Passphrase abgeleitet. Die biometrische Entsperrung ist an die iOS-Keychain / den Android-Keystore gebunden, mit automatischer Sperre bei Inaktivität und Löschung des umhüllten Schlüssels bei verweigerter Biometrie.

Böswilliger Insider

Mittel

Es gibt keine serverseitige Entschlüsselungsfunktion, die missbraucht werden könnte: Alle Schlüsseloperationen laufen clientseitig, und jedes Freigabetor wird von einer separaten Komponente gegengeprüft und schlägt im Zweifel fehl. Jede Aktion wird protokolliert.

Lieferkette

Mittel

Fixierte Abhängigkeiten per Lockfile, eine SBOM sowie eine Lizenzprüfung bei jedem Pipeline-Lauf und ein Secret-Scanner, der den Build bei einem Fund hart abbricht. Kryptografie stammt aus auditierten, veröffentlichten Bibliotheken, nicht von uns.

Schlüsselhierarchie

Vom Master-Passwort zu den Asset-Schlüsseln

Visueller Ablauf, der zeigt, wie Ihr Master-Passwort jeden Verschlüsselungsschlüssel im System ableitet.

Master-Schlüssel (256-Bit)

scrypt(Passphrase, Salt, N=2^15) → 256-Bit-Schlüssel

Tresorschlüssel

HKDF(master, 'vault')

Schlüssel für Zugangsdaten

HKDF(master, 'credentials')

Schlüssel für Dokumente

HKDF(master, 'documents')