From f4fbac9673c66b00c7c20c6142c84510d911a729 Mon Sep 17 00:00:00 2001 From: dschlueter Date: Tue, 30 Jun 2026 20:37:48 +0200 Subject: [PATCH] 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 --- VERSCHLUESSELUNGS_ANALYSE.md | 162 +++++++++++++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 VERSCHLUESSELUNGS_ANALYSE.md diff --git a/VERSCHLUESSELUNGS_ANALYSE.md b/VERSCHLUESSELUNGS_ANALYSE.md new file mode 100644 index 0000000..6e934e3 --- /dev/null +++ b/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.