Sicherheits-Architektur

Diese Seite richtet sich an technisch interessierte Leser*innen, Auditor*innen und Kanzleien. Für eine kompaktere, nicht-technische Erklärung siehe Sicherheit.

Stand: 2026-05. Diese Dokumentation beschreibt die produktive Architektur. Änderungen werden auf der Seite News angekündigt.

Grundprinzip: Zero Knowledge

Die LWYRUP-API hält keinen privaten Schlüssel der Nutzer*innen vor. Sie kann Nutzerinhalte technisch nicht entschlüsseln. Nur das Endgerät hat Zugriff auf den privaten Schlüssel.

Der Anwalts-Client besitzt ein eigenes Schlüsselpaar. Nachrichten und Dokumente werden vor dem Versand auf dem Gerät verschlüsselt – für die Empfänger und parallel für die Absender:in selbst, damit beide Seiten lesen können.

Die Kommunikation ist auf beiden Strecken Ende-zu-Ende verschlüsselt: zwischen Nutzer:in und Plattform und ebenso zwischen Plattform und Kanzlei. An quasi allen Übergängen liegt ein Intermediär-System dazwischen; keiner dieser Server hat Klartext-Wissen. Sie sehen Chiffretext, Routing-Metadaten und sonst nichts.

Schlüsselmaterial

Einziges Geheimnis der Nutzerin ist ein X25519 Private Key (32 Byte). Daraus wird alles Weitere deterministisch abgeleitet:

Private Key (32 B) – lebt nur im Geräte-Keystore
       │
       ├── X25519 → Public Key (Server kennt diesen)
       │
       ├── HKDF-SHA256(info="login") → Login-Credential
       │     (Server speichert nur bcrypt-Hash)
       │
       └── HKDF-SHA256(info="encryption") → Symmetrischer Key
             (AES-256-GCM, ausschließlich lokal)

Das Schlüsselpaar ersetzt das Passwort vollständig. Die Nutzerin muss sich nichts merken; das Backup erfolgt als QR-Code (siehe unten).

Speicherort des privaten Schlüssels

Plattform	Speicher
iOS	Keychain, Access-Group der App, `kSecAccessibleAfterFirstUnlockThisDeviceOnly`
Android	Android Keystore, hardware-gestützt (TEE/Strongbox, wenn verfügbar)
GrapheneOS	Android Keystore, ohne Google-Komponenten

Verschlüsselungsverfahren

Verfahren	Verwendung
X25519 + AES-256-GCM (Sealed Box)	App → App über Server (z. B. Nachrichten an die Kanzlei)
AES-256-GCM mit symmetrischem Key	App → Server (eigene Nutzer-Daten, „Notizen für mich selbst")
HKDF-SHA256	Schlüsselableitung aus Shared Secret oder Private Key
Ed25519	Signaturen im Challenge-Response-Login

Implementierungen verwenden ausschließlich auditierte Standardbibliotheken: Apple CryptoKit (iOS), Tink (Android), libsodium-kompatible Primitiven (PHP-Backend und Python-Worker).

Authentifizierung: Challenge-Response

Wir verwenden kein klassisches Passwort-Verfahren. Stattdessen:

1. App → POST /auth/challenge { email }
   Server → { nonce: 32 zufällige Bytes (Base64) }

2. App signiert nonce mit Private Key (Ed25519)
   App → POST /auth/verify { email, nonce, signature }
   Server prüft Signatur gegen gespeicherten Public Key
   Server → { token: JWT }

Es wird kein Geheimnis übertragen. Es gibt keinen Passwort-Hash auf dem Server und keinen, der durch einen Datenleak preisgegeben werden könnte. Der private Schlüssel verlässt das Gerät nie.

Nonces haben eine TTL von 5 Minuten und werden serverseitig nach erstmaliger Verifikation invalidiert.

Sealed Box / Mandanten ↔ Kanzlei

Inhalte, die nur die Kanzlei lesen soll (Dokumente, Schilderungen, Chat-Nachrichten):

Mandantin holt den Public Key der Anwältin (über LWYRUP).
App erzeugt einen ephemeren X25519-Schlüssel.
Shared Secret = X25519(ephemeralPriv, recipientPub).
K = HKDF-SHA256(SharedSecret, info=“lwyrup-msg-v1”).
Ciphertext = AES-256-GCM(K, nonce=24 B random, plaintext, aad=recipientPub‖ephemeralPub).
Versendete Payload = ephemeralPub ‖ nonce ‖ ciphertext.

Der ephemere Private Key wird sofort verworfen. Parallel verschlüsselt die App eine zweite Kopie für den eigenen Public Key, damit die Mandantin den eigenen Versand später noch lesen kann. Die Plattform speichert nur die verschlüsselten Payloads.

Datenverarbeitung in der EU

Server in Deutschland (Solar-Setup, siehe Serverraum).
Keine Google-Dienste, keine Drittland-Übermittlung.
KI-Analysen laufen auf eigenen Workern in derselben Region. Modelle werden lokal geladen, externe APIs werden nicht angesprochen.
Logs enthalten keine personenbezogenen Klartext-Inhalte; siehe Datenschutz.

Selbst verifizieren: Daten-Snapshot

Die Behauptung „Wir können deine Daten technisch nicht lesen" lässt sich nicht nur lesen, sondern prüfen. In der App gibt es die Funktion Daten-Snapshot anfordern. Damit erhältst du die zu deinem Konto gespeicherten Datensätze exakt so, wie sie auf dem Server liegen – also als Chiffretexte, Nonces und öffentliche Metadaten. Klartexte sind keine enthalten, weil keine vorhanden sind.

Was du mit dem Snapshot tun kannst:

Form prüfen: Du siehst, dass alle Inhaltsfelder Base64-codierter AES-256-GCM-Ciphertext sind – nicht zufällig, sondern strukturell. Es gibt keine versteckten Klartext-Spalten.
Lokal entschlüsseln: Mit deinem privaten Schlüssel (aus dem Keystore oder dem QR-Code-Backup) lässt sich der Snapshot vollständig entschlüsseln – auf deinem Gerät, ohne Server, ohne LWYRUP. Ergebnis: der Klartext, den du erwartet hast.
Bei Verdacht: gegenchecken. Wer einer eigenen Implementierung mehr traut, kann den Snapshot mit einem offenen libsodium-/CryptoKit-/Tink-Tool öffnen. Die verwendeten Primitive sind in dieser Doku spezifiziert.

Wenn LWYRUP heimlich Klartexte speichern würde, würde sich das spätestens hier zeigen. Genau das ist der Sinn der Funktion: nicht uns vertrauen – sondern es nachprüfen.

Backup: QR-Code

Der private Schlüssel kann als QR-Code exportiert werden. Format:

{ "v": 1, "k": "<base64-private-key>" }

Das ist kein passwortgeschütztes Backup. Wer den QR-Code besitzt, kann sich als die Nutzerin ausgeben. Die App weist auf diese Eigenschaft hin („Behandle den QR-Code wie Bargeld"). Wir empfehlen einen ausgedruckten, analog verwahrten Code – nicht den Foto-Roll auf dem Handy.

Der Gerätewechsel besteht aus genau zwei Schritten: QR scannen, Challenge abschließen.

Was wir bewusst NICHT tun

Kein Escrow. Wir halten keinen verschlüsselten Passwort-Backup-Kanal vor. Eine frühere Implementierung („DB2") ist abgeschaltet; entsprechende Routen antworten mit HTTP 410 Gone.
Kein Passwort-basiertes Login. Damit gibt es keine PBKDF2/Argon2- Ableitung serverseitig und keinen klassischen Passwort-Reset-Flow.
Kein Sign in with Apple / Google / Facebook. Kein Third-Party-Login, keine externen Konten.
Keine GPS-Permission. Region wird manuell ausgewählt (Bundesland), es gibt keinen CLLocationManager und keine ACCESS_FINE_LOCATION-Permission.

Offene Punkte und Roadmap

Diese Architektur ist die produktive Basis. Folgendes ist geplant oder in Arbeit:

Kanzlei-Invite-Architektur: QR-Codes mit dem Public Key der Anwältin für die Erstkontaktaufnahme. Erst teilweise umgesetzt.
Hardware Key Attestation auf Android: Im Release ohne Play-Integrity-Fallback. Backend-Verifier ist vorhanden; clientseitige Pflicht-Verifikation wird wellenweise eingeschaltet.

Quellen und Bibliotheken

Apple CryptoKit – X25519, AES-GCM, Ed25519, HKDF (Doku)
Google Tink – plattformneutrale Krypto-Primitive (Repo)
IETF RFC 7748 – Curve25519 (Link)
IETF RFC 5869 – HKDF (Link)
NIST SP 800-38D – GCM (Link)

Kontakt

Verantwortlichkeiten und postalische Adresse stehen im Impressum. Externer Datenschutzbeauftragter und Datenschutz-Anfragen sind in der Datenschutzerklärung erreichbar.