Sicherheitskonzept

Wie Krywerk Daten schützt, wem es dabei vertraut, welche Verfahren es verwendet und warum – und wo die Grenzen liegen. Zielgruppe: IT-Administration, Datenschutzbeauftragte, Prüferinnen und Prüfer. Schwachstellen bitte wie in SECURITY.md melden.

Stand: Version 0.9 (2026-10). Ein externes Sicherheitsaudit steht noch aus.

1. Schutzziele

Ziel	Bedeutung für Krywerk
Vertraulichkeit	Dateiinhalte und Dateinamen sind nur für Berechtigte lesbar – nicht für den Cloud-Anbieter, nicht für den Betreiber des Schlüsselservers, nicht für Dritte mit Zugriff auf den Speicherort.
Integrität	Veränderte oder vertauschte verschlüsselte Blöcke werden beim Lesen erkannt (modernes Format).
Verfügbarkeit	Ohne Passwort bzw. Zugang bleiben Daten unlesbar; deshalb Wiederherstellungsschlüssel und Notfallzugriff für Team-Ordner.
Kompatibilität	Offene, dokumentierte Formate (Cryptomator-Format 8, Hub-Protokoll); keine Abhängigkeit von Krywerk.

2. Bedrohungsmodell

Geschützt gegen:

• Cloud-Anbieter, NAS-Betreiber, verlorene USB-Sticks: sehen nur Chiffrat und verschlüsselte Namen.
• Betreiber des Schlüsselservers und Angreifer, die die Server-Datenbank kopieren: Tresorschlüssel liegen dort nur verschlüsselt für einzelne Personen; private Schlüssel nur verschlüsselt mit dem Freischaltcode der Person bzw. dem Geräteschlüssel.
• Manipulation der verschlüsselten Dateien (modernes Format): AES-GCM erkennt jede Änderung je Block.
• Ehemalige Mitglieder eines Team-Ordners: „Schlüssel erneuern“ erzeugt einen neuen Tresorschlüssel; neue Dateien sind für sie nicht mehr lesbar.

Nicht geschützt gegen (bewusste Grenzen):

• Schadsoftware oder Angreifer auf einem Rechner, auf dem ein Laufwerk entsperrt ist – sie sehen, was der angemeldete Mensch sieht.
• Metadaten am Speicherort: Anzahl, ungefähre Größe, Zeitstempel und Ordnerstruktur (Tiefe) der Dateien bleiben erkennbar.
• Wer einen Tresorschlüssel einmal hatte, kann bereits heruntergeladene Daten weiter entschlüsseln. „Schlüssel erneuern“ schützt nur künftige Änderungen.
• Ein bösartiger Schlüsselserver kann Zugriff verweigern (Verfügbarkeit) und Metadaten sehen (wer ist Mitglied welcher Gruppe/welches Ordners). Siehe Abschnitt 5 zum Austausch von Schlüsseln.
• Das alte Boxcryptor-Format hat keinen Integritätsschutz der Inhalte (siehe 4.3).

3. Vertrauensgrenzen

flowchart LR
  subgraph T1["Vertraut: Rechner der Person (entsperrt)"]
    APP["Krywerk-App / krywerk-mount"]
    KEYS["Geräteschlüssel<br/>DPAPI · Schlüsselbund · Secret Service"]
  end
  subgraph T2["Teilweise vertraut: Organisation"]
    KS["Krywerk Server<br/>verschlüsselte Schlüssel, Metadaten"]
    IDP["Anmeldedienst<br/>bestätigt Identität"]
  end
  subgraph T3["Nicht vertraut"]
    CLOUD["Speicherort (Cloud, NAS)<br/>nur Chiffrat"]
    NET["Netzwerk"]
  end
  APP -- "TLS (HTTPS erzwungen)" --> KS
  APP -- "nur Chiffrat" --> CLOUD
  APP -. "Browser, PKCE" .-> IDP
  KS -- "JWKS" --> IDP

4. Verfahren und Begründung

Krywerk implementiert keine eigenen kryptografischen Grundbausteine. Alle Primitive stammen aus geprüften, weit verbreiteten Rust-Bibliotheken (RustCrypto: aes, aes-gcm, aes-siv, aes-kw, scrypt, pbkdf2, hmac, sha2, p384, rsa; ring/rustls für TLS; jsonwebtoken). Zufallszahlen kommen ausschließlich aus dem Betriebssystem (OsRng). Schlüsselmaterial wird nach Gebrauch überschrieben (zeroize). Vergleiche von MACs, Tokens und Prüfsummen laufen in konstanter Zeit.

Eigene Logik gibt es nur dort, wo ein Format sie vorschreibt; sie ist gegen Referenzvektoren getestet: Concat-KDF für JWE (RFC 7518 § 4.6.2) und Shamir-Secret-Sharing über GF(2⁸) für den Notfallzugriff (Multiplikation ohne datenabhängige Verzweigungen, Testvektoren aus FIPS 197).

4.1 Persönliche Tresore und Team-Ordner (Cryptomator-Format 8)

Zweck	Verfahren	Warum
Dateiinhalt	AES-256-GCM, 32-KiB-Blöcke, 96-Bit-Zufalls-Nonce je Block, Blocknummer und Datei-Nonce als zusätzliche Daten	Authentisierte Verschlüsselung: erkennt Veränderung, Vertauschen und Abschneiden von Blöcken; Standard des Formats
Datei- und Ordnernamen	AES-SIV (RFC 5297), Ordner-ID als zusätzliche Daten	Deterministisch (nötig zum Finden einer Datei über ihren Namen), missbrauchsresistent; verschiebt man ein Chiffrat in einen anderen Ordner, wird es ungültig
Masterkey aus Passwort	scrypt (N = 32768, r = 8, p = 1) → AES-Key-Wrap (RFC 3394)	Speicherhart gegen GPU-/ASIC-Angriffe; Parameter wie in den Cryptomator-Apps (Kompatibilität)
Tresor-Konfiguration	JWT, HS256/HS512 mit dem Masterkey signiert	Erkennt Manipulation der Formatangaben

4.2 Team-Ordner (Hub-Protokoll)

Zweck	Verfahren	Warum
Tresorschlüssel je Person	JWE ECDH-ES mit P-384, Inhalt A256GCM	Server speichert nur Chiffrat für den öffentlichen Schlüssel der Person; P-384 ist im Hub-Protokoll vorgegeben (CNSA-konform)
Private Schlüssel der Person	JWE PBES2-HS512+A256KW mit dem Freischaltcode, ≥ 1 000 000 Runden	Server kennt den Freischaltcode nie; viele Runden bremsen das Raten
Gerät	eigener P-384-Schlüssel je Gerät, privater Teil im Betriebssystem-Schlüsselspeicher	Gerät entsperrt ohne Freischaltcode; Verlust eines Geräts betrifft nur dieses
Signaturen	ES384	Vom Protokoll vorgegeben
Anmeldung	OpenID Connect, Authorization Code mit PKCE (S256), Loopback-Umleitung auf 127.0.0.1 mit Zufallspfad	Stand der Technik für Desktop-Apps (RFC 8252); kein Client-Secret in der App
Transport	HTTPS mit rustls; HTTP nur für localhost	Klartext-HTTP zu entfernten Servern ist ausgeschlossen
Wiederherstellungsschlüssel	44 Wörter (Masterkey + CRC-32)	Vom Hub-Format vorgegeben; Ausdruck/Aufbewahrung offline
Notfallzugriff	Shamir-Secret-Sharing (k von n), Anteile je Gremiumsmitglied per JWE verschlüsselt	Keine Einzelperson kann den Tresor allein öffnen

4.3 Boxcryptor-Format (nur Übergang)

Krywerk liest und schreibt das alte Format nur, damit vorhandene Daten weiter nutzbar sind und umgestellt werden können. Das Format ist vorgegeben und hat bekannte Schwächen:

Zweck	Verfahren	Bewertung
Dateiinhalt	AES-256-CBC je 4-KiB-Block, Block-IV aus HMAC	Kein Integritätsschutz der Inhalte – Veränderung wird nicht erkannt
Dateischlüssel	RSA-4096 OAEP (SHA-1)	Sicher als Verfahren; siehe Hinweis zu RUSTSEC-2023-0071
Kontopasswort	PBKDF2-HMAC-SHA512	Nicht speicherhart
Dateinamen	AES-CFB-128, eigene Kodierung	Deterministisch, ohne Integritätsschutz

Deshalb empfiehlt Krywerk die Umstellung aufs moderne Format und kennzeichnet Boxcryptor-Laufwerke als „Boxcryptor (alt)“.

RUSTSEC-2023-0071 (Marvin-Angriff auf rsa): Ein Angreifer, der viele RSA-Entschlüsselungen eines Dienstes zeitlich messen kann, könnte den privaten Schlüssel rekonstruieren. Krywerk entschlüsselt RSA nur lokal beim Öffnen eigener Boxcryptor-Daten; es gibt keinen Dienst, der für Dritte entschlüsselt, und damit kein Messorakel. Die Meldung ist in deny.toml begründet ausgenommen und wird bei einer korrigierten rsa-Version entfernt.

5. Schlüsselserver: Rechte und Grenzen

• Authentisierung: Jede API-Anfrage braucht ein Access Token des Anmeldedienstes. Geprüft werden Signatur (nur asymmetrische Verfahren, kein none/HS*), Aussteller (iss), Ablauf (exp, 30 s Toleranz), und dass das Token für einen zugelassenen Client ausgestellt ist (aud bzw. azp); ID-Tokens werden abgelehnt.
• Autorisierung: Jede Route prüft Eigentum bzw. Rolle (Person, Gruppe, Tresorrolle); fremde Objekte liefern 403/404.
• Web-Verwaltung: eigene Anmeldung (Code-Flow mit PKCE, state, nonce), Sitzungscookie __Host-…, HttpOnly, Secure, SameSite=Lax; CSRF-Token und Origin-Prüfung bei jedem Formular; strikte Content-Security-Policy ohne Skripte. Gespeichert wird nur ein Hash der Sitzungs-ID.
• Überlastung: Anfragebegrenzung je Client-IP für die API (Standard 6000/min, wegen NAT in Schulen großzügig) und die Anmeldung der Web-Verwaltung (10/min), danach HTTP 429. Hinter einem Reverse Proxy zählt nur der letzte, vom eigenen Proxy angehängte Eintrag von X-Forwarded-For.
• Sitzungen der Web-Verwaltung: Sperren einer Person wirkt sofort (jede Anfrage prüft das Konto). Rollen kommen aus dem Token der Anmeldung; wird eine Rolle beim Anmeldedienst entzogen, gilt das ab der nächsten Anmeldung, spätestens nach web.session_hours (Standard 8 h).
• Header: CSP mit frame-ancestors 'none', X-Content-Type-Options, Referrer-Policy auf allen Antworten, Cache-Control: no-store für die API, HSTS bei HTTPS.
• Datenbank: ausschließlich parametrisierte SQL-Anweisungen; versionierte Migrationen.
• Protokoll: Wer hat wann was geändert (Mitglieder, Freigaben, Notfall); IP-Adressen nur mit audit.record_ip; Aufbewahrung standardmäßig 365 Tage.
• Was der Server sieht: Namen, E-Mail-Adressen, Gruppen, Geräte, Freigaben und verschlüsselte Schlüssel – nie Dateien, Dateinamen, Passwörter, Freischaltcodes oder entschlüsselte Schlüssel.

Austausch öffentlicher Schlüssel (Web of Trust, Spec §16a): Beim Freigeben verschlüsselt die App den Tresorschlüssel an den öffentlichen Schlüssel, den der Server für die empfangende Person liefert. Damit ein manipulierter Server keinen eigenen Schlüssel unterschieben kann:

• Personen vergleichen Fingerabdrücke (SHA-256 über die RFC-7638-Thumbprints beider öffentlicher Schlüssel) außerhalb des Servers (Telefon, persönlich) und bestätigen damit die Schlüssel der anderen Person: Die App signiert sie mit dem eigenen ECDSA-Schlüssel (JWS ES384) und legt die Signatur auf dem Server ab. Einzutippen sind mindestens max(wotIdVerifyLen, 8) Zeichen – eine Server-Einstellung von 0 oder 2 wird nicht übernommen, weil sich so wenige Zeichen mit wenigen hundert erzeugten Schlüsseln treffen ließen.
• Der Server speichert Signaturen nur, wenn sie mit dem gespeicherten Schlüssel des Aufrufers gültig sind und genau die aktuellen Schlüssel des Ziels betreffen, und liefert die kürzeste Vertrauenskette (höchstens wot.max_depth + 1 Glieder). Geprüft wird jede Kette in der App gegen den lokal gespeicherten eigenen Schlüssel; der Server ist für diese Prüfung nicht vertrauenswürdig.
• „Zugriff gewähren“ in der App und krywerk-hub freigeben geben nur bestätigten Personen frei; nicht bestätigte nur nach ausdrücklicher Auswahl mit Warnung bzw. --auch-unbestaetigt. Die Bestätigung wird für genau die Schlüssel berechnet, an die verschlüsselt wird.

Verbleibende Grenzen:

• Eigener Schlüssel – Vertrauen beim ersten Mal: Die App lernt den eigenen Schlüssel, wenn sie die privaten Schlüssel mit dem Freischaltcode entschlüsselt (Freischalten eines Geräts, erstes Bestätigen bzw. Anzeigen des Fingerabdrucks) oder selbst erzeugt (Konto einrichten), und speichert ihn lokal (hub-wot-keys.json, nur öffentliche Schlüssel). Nicht aus dem Geräte-JWE, das der Server an den öffentlichen Geräteschlüssel selbst bauen könnte. Meldet der Server später andere eigene Schlüssel, gilt niemand mehr als bestätigt, bis der neue Freischaltcode eingegeben wird.
• Notfallzugriff: Die Bestätigung von Gremiumsmitgliedern und Antragstellenden wird nur angezeigt (wie beim Cryptomator Hub), nicht erzwungen. Der Antragsschlüssel eines Notfallantrags ist nicht signiert.
• Bestätigen ist freiwillig. Wer nicht bestätigte Personen trotz Warnung auswählt, vertraut dem Server.
• Krywerk Server zeigt bisher nicht an, welche Signaturen durch Schlüsselwechsel ungültig geworden sind; die App meldet solche Personen als „nicht bestätigt“.

6. Desktop-App

• Passwörter werden nur auf Wunsch gemerkt und dann im Schlüsselspeicher des Betriebssystems abgelegt (Windows DPAPI, macOS-Schlüsselbund, Linux Secret Service).
• Das Protokoll (log.txt) enthält keine Passwörter, Schlüssel oder Dateiinhalte.
• Die Oberfläche (Tauri) darf nur die Befehle der App aufrufen; Content-Security-Policy default-src 'self', kein Nachladen von Inhalten aus dem Internet.
• Keine Telemetrie, keine Absturzberichte, keine automatische Update-Abfrage.

7. Abgleich mit OWASP Top 10 (2021)

Kategorie	Maßnahmen	Offen
A01 Zugriffskontrolle	Prüfung je Route, Rollen aus dem Token, IDs als UUIDs	Web of Trust (A-14)
A02 Kryptografische Fehler	nur geprüfte Bibliotheken, HTTPS erzwungen, siehe Abschnitt 4	–
A03 Injection	parametrisierte SQL, automatische HTML-Maskierung, CSV-Formeln entschärft	–
A04 Unsicheres Design	Bedrohungsmodell (Abschnitt 2), Clean-Room-Spezifikation	Web of Trust (A-14)
A05 Fehlkonfiguration	Pflichtangaben werden beim Start geprüft, unbekannte Optionen abgelehnt, keine Standardpasswörter	–
A06 Veraltete Komponenten	cargo deny und cargo audit in CI, SBOM je Release	–
A07 Authentisierung	OIDC mit PKCE, Prüfung von aud/azp, kurze Web-Sitzungen	–
A08 Integrität von Software und Daten	AES-GCM/SIV im Tresor, signierte Tresorkonfiguration, Cargo.lock	Signierte Installationspakete (HUMAN)
A09 Protokollierung	Protokoll der Verwaltungsaktionen, keine Geheimnisse in Logs	–
A10 SSRF	Server ruft nur den konfigurierten Anmeldedienst ab	–

8. Prüfung

• Unit- und Integrationstests für alle Krypto-Bausteine mit Testvektoren (RFC, FIPS, Vektoren des Referenz-Hubs, Gegentests mit den Java-Bibliotheken von Cryptomator).
• Ende-zu-Ende-Tests gegen Krywerk Server und den offiziellen Cryptomator Hub.
• In jeder CI-Ausführung: cargo deny (Sicherheitsmeldungen, Lizenzen, Herkunft), gitleaks über die gesamte Git-Geschichte, Clippy ohne Warnungen.