# Threat Model — Android Security Beta

## Schutzwerte

Primär geschützt werden BIP39-Seed-Phrasen, Passwörter, Benutzernamen, URLs,
sichere Notizen, vertrauliche Bildanhänge, Vault-Metadaten, der DEK,
Masterpasswort und Recovery-Key. Der verschlüsselte Gesamtexport darf kopiert
und gesichert werden; seine Vertraulichkeit darf nicht davon abhängen, dass
Dateiname oder Speicherort geheim bleiben.

## Angreifermodell

Die Konstruktion soll gegen Diebstahl einer ausgeschalteten bzw. gesperrten
Geräteinstanz, Kopie der Vault-Datei, Offline-Passwortraten, Dateimanipulation
und versehentliche Cloud-/Netzwerkübertragung durch die App selbst schützen.

Sie kann nicht zuverlässig schützen gegen:

- ein bereits kompromittiertes, gerootetes oder entsperrtes Betriebssystem
- manipulierte Tastatur, Accessibility-Dienst, Screen-/Kamera-Aufnahme außerhalb
  der App-Kontrolle oder physische Beobachtung
- Zwang, Social Engineering und ein kompromittiertes Papier-Backup
- gleichzeitigen Verlust von Passwort und Recovery-Key
- Fehler in Plattform, Kryptobibliotheken oder dieser nicht auditierten Beta
- einen Angreifer mit Zugriff auf App-Speicher während einer entsperrten Sitzung
- Kopien eines importierten Bildes, die noch in Galerie, Cloud, Papierkorb,
  Messenger oder anderen Apps liegen
- Zwischenablage-Manager oder Tastaturen, die ausdrücklich kopierte bzw.
  eingegebene Geheimnisse ausserhalb der App erfassen

## Vertrauensgrenzen

| Grenze | Annahme | Gegenmaßnahme |
|---|---|---|
| Android-App → Rust | JNI ist lokal, aber fehleranfällig | kleine API, Längenlimits, generische Fehler |
| Rust → Dateisystem | Datei/Import ist feindlich | Formatgrenzen, AEAD, maximale Dateigröße |
| Kotlin-Zusatzspeicher → Dateisystem | Metadaten, Zugangsdaten und Bilder sind geheim | AES-256-GCM, domänengetrennte Schlüssel, AAD, Padding, atomare Dateien |
| App → System Photo Picker | Quelldatei liegt ausserhalb des Tresors | keine Speicherberechtigung, Typ-/Grössen-/Auflösungsgrenzen, sofortige Löschwarnung |
| App → Android Keystore | Plattform und TEE/SE sind vertrauenswürdig | starke Biometrie, Auth pro Nutzung, Enrollment-Invalidierung |
| App → Zwischenablage | andere Apps bzw. Systemdienste können lesen | nur explizites Kopieren, Sensitiv-Markierung, 30-Sekunden-Löschung nach bestem Bemühen |
| App → Browser | Browser ist außerhalb des Vaults | feste HTTPS-Allowlist, keine Secrets in URLs |
| Mensch → Papier | Recovery-Aufzeichnung kann verloren gehen | Bestätigung klar nummerierter Recovery-Key-Blöcke im Onboarding |

## Wichtige Entscheidungen

Masterpasswort und Recovery-Key bilden echte getrennte Faktoren für die
manuelle Entsperrung. Der Recovery-Key ist zufällig und besitzt eine Prüfsumme.
Im Schnellmodus gibt starke Biometrie den Keystore-geschützten DEK frei. Im
strikten Modus bestätigt sie nach den beiden Wissensfaktoren den Zugriff auf dem
eingerichteten Gerät. Diese dritte Zugangsprüfung ist bewusst nicht als dritter
portabler Kryptofaktor beschrieben; eine Wiederherstellung auf einem neuen
Gerät bleibt mit Passwort und Recovery-Key möglich. TOTP wäre ohne Backend auf
demselben Gerät kein belastbarer zusätzlicher Faktor und wird deshalb nicht als
Vault-Entsperrung angeboten.

Zugangsdaten und Notizen sind in Compose/JVM zur Laufzeit teilweise immutable
Strings und lassen sich daher nicht zuverlässig überschreiben. Die App hält sie
nur während aktiver Eingabe bzw. in der entsperrten Detailansicht, sperrt nach
60 Sekunden bzw. beim Verlassen, schreibt sie nicht in Saved State und speichert
sie nie unverschlüsselt auf Datenträger. Komprimierte Bildbytes werden nach dem Ausblenden überschrieben;
die dekodierte Vorschau wird geleert und freigegeben.

Die App hat absichtlich keine Panic-Wipe-Funktion. Automatisches Löschen kann
Nutzer dauerhaft aussperren und lässt sich als Denial-of-Service missbrauchen.
Nach Fehlversuchen wird nur verzögert; Daten bleiben erhalten.
