# Tane — Seguridad y privacidad (modelo de amenaza)

*Nota de diseño (discusión). Nace del "peor caso legal": una persona en un país donde una variedad (p.ej. cannabis) está prohibida debe poder usar la app **sin dejar datos en claro**. Extiende y matiza [backup-and-recovery.md](backup-and-recovery.md) y la postura legal del [PLAN.md](../../PLAN.md) §6.*

## El peor caso, como brújula

Si diseñamos para la persona más expuesta —alguien cuyo inventario podría ser *prueba* en su contra si le requisan o le hacen desbloquear el móvil—, protegemos a todo el mundo de paso. Esto **corrige** la conclusión provisional anterior ("los datos son de baja sensibilidad, no cifrar"): eso valía para tomates en España, no para este caso. La regla pasa a ser más fuerte:

> **Nunca hay datos en claro en reposo. Ni el inventario, ni el backup, ni ficheros temporales o logs.**

## Tres superficies distintas (cada una su respuesta)

### A) Datos en reposo en el dispositivo (el inventario) — **cifrado siempre**
La base de datos local va **cifrada** (SQLCipher, que Drift/Flutter soportan). No se escribe nada en claro en disco: ni la BD, ni caché de fotos, ni logs. Así, un móvil apagado o bloqueado que se requisa **no revela nada**.

### B) Bloqueo de la app — **opcional, recomendado**
Para el caso "móvil desbloqueado en la mano" (o te obligan a desbloquear en una frontera), un **bloqueo propio de la app** (biométrico/PIN, aparte del desbloqueo del teléfono) evita que abrir el móvil muestre el inventario. Rápido con huella, y protege cuando el teléfono está desbloqueado pero la app cerrada (como hacen las apps de banca o Signal).

### C) La copia de seguridad — **cifrada también**
Coherente con A: el backup **también va cifrado** (el usuario lo pedía). Un archivo de copia filtrado o requisado tampoco debe estar en claro.

### D) La red / las ofertas — **acto deliberado, privado por defecto**
Publicar es lo más arriesgado. Por eso cada cosa es **privada por defecto**; ofrecer es un acto consciente por ítem. Quien tiene una variedad sensible simplemente **no la ofrece**: la tiene, cifrada, en su inventario, y punto. Cuando sí se ofrece: identidad seudónima (clave), **ubicación aproximada**, sin catálogo central. Gestionar el inventario nunca toca la red.

## La clave del asunto: cifrar **sin** contraseña que olvidar

El problema del cifrado en algo que debe durar (§ de backup) era: contraseña olvidada = pérdida total. Se resuelve **no usando una contraseña memorizada como llave.** En su lugar:

- **Llave = una clave aleatoria fuerte**, no algo que la persona recuerde.
- **Uso diario:** esa llave vive en el **almacén de claves del sistema** (Android Keystore / iOS Keychain / Secure Enclave), y se libera con el desbloqueo que la persona *ya hace* (huella/PIN del móvil). Cifrado invisible: no hay contraseña nueva que aprender.
- **Recuperación / cambio de móvil:** la misma llave se guarda en un **QR imprimible** — *"tu llave; guárdala como tu mejor semilla"*. Un objeto físico, no un secreto que memorizar. Se anima a tener **dos copias** en sitios distintos (como se hace con papeles importantes).
- **Restaurar en un móvil nuevo:** escaneas el QR → la llave → descifra la copia → todo vuelve.

Con esto conseguimos las dos cosas a la vez, que parecían enfrentadas:
- **Confidencialidad total:** nada en claro, ni en el móvil ni en la copia. Sirve para el peor caso legal.
- **Durabilidad:** no hay contraseña que olvidar. Solo pierdes datos si pierdes **a la vez** el móvil y **todas** las copias del QR. La pérdida es un objeto físico extraviable (intuitivo), no un olvido.

Y encaja con el público de 10 a 80: **no se le pide ninguna contraseña nueva**; usa su huella de siempre, y guarda un papel. El cifrado es invisible por defecto.

## Lo que la protege además, "gratis"

- **Es una app de semillas, genérica e inocua.** No es "una app de cannabis": es un inventario de semillas. Lo que importa —el contenido— va cifrado. La app en sí no delata.
- **Nada en la red por gestionar.** Tener no es publicar. El inventario vive local y cifrado.

## Avanzado / futuro (nombrarlo, no hacerlo ya)

- **Negación plausible / bóveda señuelo:** un inventario "de fachada" y otro oculto, para el caso de desbloqueo forzado. Potente pero delicado (puede volverse en contra) → función posterior, con cuidado.
- **Modo discreto:** icono/nombre camuflado. A valorar; suele ser más humo que protección real.
- No prometer lo que no se puede cumplir: si a alguien le **obligan** a desbloquear y abrir la app, el cifrado en reposo no basta; ahí ayudan el bloqueo de app y, en su caso, la negación plausible. Ser honestos sobre los límites.

## Decidido

- **Inventario cifrado en reposo, siempre** (SQLCipher). Sin datos en claro en disco.
- **Copia cifrada, siempre.**
- **Llave = clave aleatoria en el almacén del sistema + QR imprimible.** **Nunca** una contraseña memorizada como único secreto (default). El QR es el mecanismo de recuperación y de portabilidad.
- **Bloqueo de app (biométrico/PIN): opcional, recomendado** para variedades sensibles.
- **Privado por defecto** en la red; ofrecer es opt-in por ítem.

## A decidir

- ¿Bloqueo de app **activado por defecto**, o sugerido la primera vez que marcas algo como sensible?
- ¿Se permite una contraseña *además* del QR para quien la quiera (defensa en profundidad), asumiendo su riesgo?
- ¿La negación plausible entra en el radar de la v1 o se aparca claramente para después?
- Identidad: **una sola clave para todo** (perfil, ofertas, mensajes, certificaciones, Ğ1), tipo Duniter — decidido (ver [g1-integration.md](g1-integration.md)). Matiz: la **clave simétrica que cifra la BD en reposo** es un **detalle interno distinto** (no es una "identidad"), así que no contradice el "una sola identidad"; el cifrado de mensajes E2E sí deriva de la clave de identidad (ECDH), como en Cesium/Duniter.