docs: M1-Bestandsaufnahme – 3 Punkte bereits vorhanden, SQLCipher-Lücke offen

Key-Backup-Flows und Geräteverwaltung waren schon implementiert (nur nicht
abgehakt). Neue Sicherheitslücke dokumentiert: sqlcipher_flutter_libs ist
eine ungenutzte Abhängigkeit, die Krypto-DB liegt unverschlüsselt vor.
Bewusst nicht blind gefixt (Migrationsrisiko für Bestandsinstallationen),
Frage an Bernd zur Priorität ergänzt.

PROGRESS.md

@@ -13,6 +13,56 @@ Schritt (und beim Abbruch mitten im Schritt den Zwischenstand). Format:
 
 ---
 
+## 2026-07-03 – M1: Restliche Punkte geprüft – 3 schon vorhanden, 1 echte Lücke gefunden
+
+**Erledigt:**
+- **Logout-Warnung bei fehlendem Key-Backup** (Commit b5762ea): neue Funktion
+  `isKeyBackupMissing(client)` in `bootstrap_dialog.dart` (prüft Cross-Signing +
+  `keyManager.isCached()`). Beide Logout-Dialoge in `settings_modal.dart` zeigen
+  jetzt eine rote Klartext-Warnung statt des neutralen Textes, wenn kein Backup
+  eingerichtet ist.
+- **Drei ROADMAP-Punkte waren bereits umgesetzt** (nur nicht abgehakt) – durch
+  Code-Lektüre verifiziert, nicht neu gebaut:
+  - Key-Backup einrichten/wiederherstellen: `bootstrap_dialog.dart` deckt beides
+    über den `Bootstrap`-Zustandsautomaten des matrix-SDK ab (`askNewSsss` für
+    Neueinrichtung, `askUnlockSsss` fragt auf einem neuen Gerät nach dem
+    Recovery-Key). Wird automatisch getriggert, wenn Cross-Signing fehlt
+    (`app_shell.dart:_triggerBootstrap`).
+  - Geräte-/Sessionverwaltung: `_SessionsSection` in `settings_modal.dart` –
+    Liste, Umbenennen, SAS/QR-Geräteverifizierung, Einzel- und
+    Massen-Abmeldung (mit Passwort-Reauth bei UIA-Anforderung).
+- **Echte Sicherheitslücke gefunden:** `sqlcipher_flutter_libs` ist eine
+  Abhängigkeit in `pubspec.yaml`, wird aber **nirgends im Code benutzt**.
+  `matrix_client.dart` (Haupt-App) und `background_push.dart` (Push-Hintergrund)
+  öffnen `pyramid.sqlite` beide über den normalen, unverschlüsselten
+  `sqflite`/`sqflite_common_ffi`-Factory. Die Krypto-DB (Access-Token,
+  gepickelter Olm-Account, Megolm-Sessions, komplette Nachrichtenhistorie)
+  liegt also **im Klartext** auf der Platte – nur durch Androids App-Sandbox
+  geschützt, nicht durch eine eigene Verschlüsselung.
+
+**Offen/Nächster Schritt:** SQLCipher-Anbindung NICHT blind auf dem Pi
+umgesetzt – siehe Stolperfalle unten. Braucht einen eigenen, vorsichtig
+geplanten PC-Termin: Backup der Test-DB, Migrationscode (bestehende
+Klartext-DB einmalig nach SQLCipher überführen), Test auf einem Gerät mit
+echten Daten, erst dann Rollout.
+
+**Fragen an Bernd:**
+- Priorität der SQLCipher-Lücke: Soll das vor M2 (Refactoring) angegangen
+  werden, oder reicht die App-Sandbox als Schutz erstmal aus (Angreifer bräuchte
+  Root oder physischen Zugriff + ADB, um die Datei überhaupt zu lesen)? Die
+  Migration bestehender Installationen (Uta!) ist der aufwändige/riskante Teil,
+  nicht die Verschlüsselung selbst.
+
+**Stolperfallen:**
+- Eine DB-Verschlüsselungs-Migration ist genau die Art Änderung, die laut
+  CLAUDE.md nicht "mal eben" auf dem Pi ohne Testgerät gemacht werden darf:
+  scheitert die Migration (falscher Schlüssel, falsche PRAGMA-Reihenfolge,
+  Timing zwischen Haupt-App und Push-Hintergrund-Client), sind Utas
+  Nachrichten und Krypto-Schlüssel unwiederbringlich weg. Deshalb hier nur
+  dokumentiert, nicht implementiert.
+
+---
+
 ## 2026-07-03 – M1: Push-Regression vermutlich dieselbe Ursache wie Random-Logout
 
 **Erledigt:** Vor dem Blick in den Push-Code die Vermutung geprüft, ob die

ROADMAP.md

@@ -33,12 +33,25 @@ Punkte abhaken (`[x]`), wenn erledigt UND in `PROGRESS.md` protokolliert.
       (z. B. fehlende Megolm-Schlüssel/Key-Sharing) – dann `docs/NOTIFICATIONS.md`
       + Memory „Pyramid Push" erneut konsultieren und die dort gelisteten 3
       Fallstricke der Hintergrund-Entschlüsselung gegenprüfen.
-- [ ] Sichere Speicherung von Access-Token & Krypto-DB prüfen (secure storage / sqlcipher korrekt?)
-- [ ] Key-Backup einrichten-Flow: Recovery-Key erzeugen, verständlich erklären, zum Sichern zwingen
-- [ ] Key-Backup wiederherstellen-Flow: nach Login auf neuem Gerät alte Nachrichten entschlüsseln
-- [ ] Logout-Schutz: Warnung mit Klartext-Folgen, wenn Key-Backup fehlt
-- [ ] Geräte-/Sessionverwaltung in den Einstellungen (Liste, Verifizieren, Abmelden)
+- [ ] **Sichere Speicherung von Access-Token & Krypto-DB: LÜCKE GEFUNDEN.**
+      `sqlcipher_flutter_libs` steht zwar in `pubspec.yaml`, wird aber nirgends
+      benutzt – `matrix_client.dart` und `background_push.dart` öffnen die
+      `pyramid.sqlite` (Access-Token, gepickelter Olm-Account, Nachrichten) über
+      den normalen `sqflite`/`sqflite_common_ffi`-Factory, also **unverschlüsselt**
+      auf der Platte. Bewusst NICHT blind auf dem Pi gefixt: eine Umstellung auf
+      SQLCipher braucht eine Migration für bereits bestehende Klartext-DBs
+      (Utas Gerät!) – ohne Testgerät hier zu riskant für „Kein Datenverlust".
+      Siehe PROGRESS.md 2026-07-03 + Frage an Bernd.
+- [x] Key-Backup einrichten-Flow: bereits vorhanden (`bootstrap_dialog.dart`,
+      wird automatisch getriggert wenn Cross-Signing fehlt, `app_shell.dart`)
+- [x] Key-Backup wiederherstellen-Flow: bereits vorhanden (`bootstrap_dialog.dart`,
+      `BootstrapState.askUnlockSsss` fragt nach Recovery-Key auf neuem Gerät)
+- [x] Logout-Schutz: Warnung mit Klartext-Folgen, wenn Key-Backup fehlt (b5762ea)
+- [x] Geräte-/Sessionverwaltung in den Einstellungen: bereits vorhanden
+      (`_SessionsSection` in `settings_modal.dart` – Liste, Umbenennen, Verifizieren
+      per SAS/QR, Abmelden, Massen-Abmeldung mit Passwort-Reauth)
 - [ ] Härtetest dokumentieren: Login → Nachrichten → Logout → Login neu → alles noch lesbar
+      (gehört zum ausstehenden PC-Praxistest der beiden Bugfixes oben)
 
 ## M2 – Das große Refactoring (erst nach M0/M1!)