tane/docs/design/security-privacy.md

Tanemaki — 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 y la postura legal del 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). 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.