my_voice_assistant_v3_jamulix/VERSCHLUESSELUNGS_ANALYSE.md

# 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.