dschlueter/my_voice_assistant_v3_jamulix
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
my_voice_assistant_v3_jamulix/VERSCHLUESSELUNGS_ANALYSE.md
dschlueter f4fbac9673 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>
2026-06-30 20:37:48 +02:00

8.9 KiB
Raw Blame History

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.