docs: Verschluesselungs-Analyse (DB & Backups, vHost + Heim-Server)

Bedrohungsmodell, Whole-DB vs. pro User, Methoden (SQLCipher/Volume/LUKS),
Schluesselmanagement (Start-Injektion/TPM), Off-Site-Backups, Heim-Server-Delta.
Diskussionsgrundlage, kein Code.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

VERSCHLUESSELUNGS_ANALYSE.md

@@ -0,0 +1,162 @@
+# Verschlüsselungs-Analyse — Datenbank & Backups
+
+> Stand: Entwurf / Diskussionsgrundlage. Betrifft die SQLite-DB mit Userdaten,
+> Gesprächsverläufen, Erinnerungen und Notfall-Profilen (Name, Adresse,
+> Geburtsdatum, **medizinische Notizen**, Telefon). Ziel: Schutz der Daten **at
+> rest** gegen Diebstahl von DB-Datei, Backups oder Datenträger.
+>
+> Leitsatz: **Der Cipher ist der einfache Teil — entscheidend ist das
+> Schlüsselmanagement und das Bedrohungsmodell.**
+
+## 1. Bedrohungsmodell — wogegen schützt at-rest-Verschlüsselung überhaupt?
+
+| Szenario | Hilft Verschlüsselung? |
+|---|---|
+| **Gestohlenes Backup** (kopiert, geleakt, alter USB/Cloud-Ordner) | **Ja** — wahrscheinlichster & am leichtesten zu schließender Fall |
+| **Gestohlene/ausgemusterte Platte** (Box aus, Disk-Image) | **Ja — nur wenn der Schlüssel NICHT auf derselben Platte liegt** |
+| **Live-Kompromittierung** (root/App-Zugriff auf dem laufenden Server) | **Nein** — die App muss entschlüsseln können → Schlüssel im RAM |
+| **Hypervisor / Rechenzentrum** (RAM- & Disk-Snapshot durch Betreiber) | **Kaum** — RAM-Snapshot greift den Schlüssel ab |
+
+**Kernfalle:** Liegt der Schlüssel als Datei/`.env` auf **derselben** Platte wie
+die DB, bekommt ein Disk-/Backup-Dieb beides → die Verschlüsselung ist wertlos.
+
+## 2. Ganze DB einmal verschlüsseln vs. jeden User einzeln?
+
+**Empfehlung: ganze DB (eine Verschlüsselung), NICHT pro User.**
+
+- Pro-User-Verschlüsselung bringt nur dann Mehrwert, wenn die User-Schlüssel
+  **nicht** serverseitig verfügbar sind (aus User-Geheimnis abgeleitet, nur bei
+  aktiver Sitzung).
+- Der Assistent ist aber ein **autonomer, immer-laufender Server**: er verarbeitet
+  Userdaten **ohne** anwesenden Nutzer (Auto-Erinnerungs-Extraktion, LLM-Kontext,
+  Safety, Admin). Er muss also jederzeit entschlüsseln können → hält/leitet alle
+  Schlüssel ab → ein Dieb des Schlüsselmaterials bekommt **trotzdem alles**.
+- Authelia/SSO liefert **keinen** stabilen pro-User-Krypto-Schlüssel. Echte
+  Client-seitige Verschlüsselung würde den LLM-Assistenten unmöglich machen.
+- Pro-Feld-Verschlüsselung zerstört zudem Indizes/Suche/SQL, leakt Metadaten
+  (wer/wann/wie viel) und lässt WAL-/Temp-Dateien im Klartext.
+
+→ Pro-User = **sehr hoher Aufwand, kaum Sicherheitsgewinn** in dieser Architektur
+(Security-Theater). Whole-DB ist richtig und ausreichend.
+
+## 3. Methoden für Whole-DB
+
+- **(a) SQLCipher** (verschlüsseltes SQLite): App öffnet die DB mit `PRAGMA key`,
+  verschlüsselt DB + WAL transparent. Aufwand: Dependency (`pysqlcipher3`) +
+  `store._connect` + Einmal-Migration. App-contained.
+- **(b) Verschlüsseltes Volume** (LUKS-Loopback, **gocryptfs** userspace, fscrypt)
+  fürs `data/`: **app-transparent** (kein Code), deckt DB + WAL + Temp + dort
+  liegende Backups ab. Aufwand: OS-Setup + **Entsperren beim Boot**.
+- **(c) LUKS Full-Disk-Encryption** (ganze Platte): deckt zusätzlich **Logs,
+  Swap, OS** ab; ideal gegen physischen Diebstahl (s. Heim-Szenario).
+
+**Der eigentliche Hebel — Schlüssel-Ort:** nicht auf der Datenplatte. Optionen:
+Passphrase **beim Service-Start** injizieren (`systemd-ask-password`), Schlüssel
+beim Start **extern** holen (nur im RAM halten), oder **TPM** (s. u.). Trade-off:
+bricht den **unbeaufsichtigten Auto-Neustart** — bei einem Always-On-Care-System
+ein echter Betriebsnachteil.
+
+## 4. Aufwand vs. Sicherheit
+
+| Maßnahme | Aufwand | Sicherheitsgewinn |
+|---|---|---|
+| Backups off-host/-site + `age`/GPG | **niedrig** | **hoch** (häufigstes Leck) |
+| Whole-DB, Schlüssel auf gleicher Platte | mittel | **niedrig** (nur „nackte .db-Kopie") |
+| Whole-DB, Schlüssel off-disk / Start-Injektion | mittel–hoch (Ops) | mittel–hoch (echter Disk-Diebstahl) |
+| LUKS-FDE + TPM2 (Heim-PC) | mittel | **hoch** (deckt alles, löst Key-Problem) |
+| Pro-User-Feldverschlüsselung | **sehr hoch** | marginal hier, bricht Features |
+
+## 5. Empfohlenes Vorgehen (vHost), nach ROI sortiert
+
+1. **Backups verschlüsselt & off-host — sofort, größter Nutzen, kleinster Aufwand.**
+   Jedes Backup mit `age`/GPG (Public-Key); privater Schlüssel **nur offline/Heim-Host**.
+   Backups **weg vom Server**.
+2. **Live-DB verschlüsseln** (SQLCipher oder gocryptfs/LUKS).
+3. **Schlüssel vom Datenträger trennen** (Start-Injektion) — macht Stufe 2 erst wirksam.
+4. **Datensparsamkeit/Retention**: alte Verläufe automatisch löschen (Tools vorhanden) —
+   weniger Daten = weniger Schaden.
+
+## 6. Was leicht vergessen wird
+
+- **Backups liegen aktuell NEBEN der DB** auf demselben Datenträger (inkl. der
+  `…bak-*`-Dateien) → ein Disk-Dieb bekommt DB **und** Backups. Größte aktuelle
+  Schwachstelle → auslagern.
+- **WAL/-shm/-journal & SQLite-Temp** enthalten Klartext-Fragmente → spricht für
+  Whole-DB/Volume statt Feld-Ebene.
+- **Logs / journald**: Gesprächsinhalte können in App-Logs landen → Log-Level prüfen.
+- **Swap**: Schlüssel & Klartext können in den Swap geraten → **verschlüsselter Swap**.
+- **Schlüsselverlust = Datenverlust**: Für ein Care-System ist **Verfügbarkeit**
+  teils kritischer als Vertraulichkeit → **Key-Escrow/sicheres Backup des Schlüssels**.
+- **Sensibelste Daten = Notfall-Profil** (DSGVO-Gesundheitsdaten) — Hauptziel;
+  evtl. zusätzliche Feldverschlüsselung als Defense-in-Depth (nur Stufe 2).
+- **Realismus vHost**: Gegen bösartigen RZ-Betreiber (RAM-Snapshot) schützt
+  at-rest mit auto-verfügbarem Schlüssel **nicht** — ehrlich kommunizieren.
+
+---
+
+## 7. Wenn der Server LOKAL (zuhause) läuft — wie ändert sich das Bild?
+
+Der Standortwechsel verschiebt das Bedrohungsmodell **überwiegend zugunsten der
+Sicherheit**:
+
+### 7.1 Der schwierigste Gegner verschwindet
+Kein Rechenzentrums-Betreiber/Hypervisor mehr, der RAM **und** Disk snapshotten
+kann. Du kontrollierst die physische Hardware → **at-rest-Verschlüsselung liefert
+nahezu ihren vollen Wert.** Wichtigste Änderung.
+
+### 7.2 Neuer Hauptgegner: physischer Diebstahl / Einbruch
+Vorher abstrakt, jetzt konkret: Einbruch, Mitnahme von Rechner/Platten, Reparatur-/
+Besuchszugriff, Platten-Entsorgung. **LUKS-Full-Disk-Encryption** ist dagegen das
+natürliche, starke Mittel: gestohlener Heim-PC mit LUKS = Briefbeschwerer.
+
+### 7.3 Schlüsselmanagement wird einfacher UND besser: TPM
+Ein echter Heim-PC hat meist ein **TPM 2.0** (der vHost nicht). LUKS an das TPM
+binden →
+- entsperrt **automatisch, nur auf genau dieser Maschine** (kein Key auf Platte,
+  keine manuelle Eingabe) → **unbeaufsichtigter Neustart** funktioniert wieder;
+- **Platte ausbauen & woanders auslesen** scheitert;
+- **Trade-off:** ganze Maschine gestohlen **und eingeschaltet** → TPM entsperrt.
+  Wer das abdecken will: **TPM + PIN** (wieder Eingabe nötig — Verfügbarkeit vs.
+  Diebstahlschutz).
+
+→ Zuhause empfohlene Primärmaßnahme: **LUKS-FDE mit TPM2-Auto-Unlock (optional +PIN)**
+— deckt **alles** ab (DB, WAL, Logs, Swap, Temp), OS-nativ, löst zugleich das
+Schlüssel-/Neustart-Problem.
+
+### 7.4 Backups: aus „off-host" wird „off-SITE"
+Zweites Laufwerk im selben Raum nützt wenig — Einbruch/Brand nimmt alles mit.
+→ **verschlüsselte Off-Site-Backups** (`age`/GPG, Schlüssel getrennt) an einen
+zweiten Ort. Deckt Vertraulichkeit **und** Disaster-Recovery (Totalverlust) ab.
+
+### 7.5 Was zuhause schwieriger wird / auf dich übergeht
+- **Physische Sicherheit**: abschließbarer Raum, gesperrter Bildschirm,
+  Haushalts-/Gästevertrauen.
+- **Verfügbarkeit**: kein redundanter Strom/Kühlung/Remote-Hands → **USV** (auch
+  gegen DB-Korruption bei Stromausfall).
+- **Netzwerk-/Live-Kompromittierung kann GRÖSSER werden**: Heim-LAN heterogen
+  (IoT, schwache Segmentierung). Ist der Server **internet-exponiert**, kann ein
+  gekapertes Gerät seitlich angreifen. **Verschlüsselung hilft hier nicht** →
+  Netz-Härtung: möglichst **nur per VPN/Tunnel**, Reverse-Proxy, fail2ban,
+  minimale Ports, SSO behalten, **eigenes VLAN** weg von IoT.
+- **Platten-Entsorgung** wird durch FDE unkritisch.
+
+### 7.6 Unverändert
+- **Whole-DB schlägt weiter Pro-User.**
+- **Live-Kompromittierung** bleibt der Fall, den Verschlüsselung **nicht** abdeckt —
+  durch mögliche Heim-Internet-Exposition evtl. das **dominante** Restrisiko →
+  Netz-Härtung mindestens so ernst nehmen wie Verschlüsselung.
+
+## 8. Fazit
+
+- **Whole-DB-Verschlüsselung reicht**; pro User lohnt sich nicht.
+- **vHost:** Fokus auf (1) verschlüsselte Off-Host-Backups, (2) Live-DB
+  (SQLCipher/Volume), (3) Schlüssel vom Datenträger trennen.
+- **Heim-Server (besser & einfacher):** **LUKS-FDE + TPM2 (optional +PIN)** +
+  **verschlüsselte Off-Site-Backups** + **Netz-Härtung gegen Live-Angriffe** +
+  **physische Sicherheit & USV**. Der TPM löst zugleich Verschlüsselung und das
+  Schlüssel-/Neustart-Dilemma.
+
+### Offene Entscheidung
+Soll der Heim-Server **internet-exponiert** oder **nur per VPN/Tunnel** erreichbar
+sein? Davon hängt das Gewicht des Live-Kompromittierungs-Risikos ab — der einzige
+große Punkt, den Verschlüsselung nicht abdeckt.