Capítulo 2 Modelo de amenazas y límites de confianza

Este capítulo establece un modelo de amenazas compartido y un vocabulario común de límites de confianza: qué activos protegemos, qué pueden hacer los atacantes, qué supuestos deben cumplirse y cómo DEBE aplicar el sistema el fallo cerrado ante un error de autenticación o una discrepancia de parámetros.

Metadatos del documento

Versión del documento técnico: v1.0
Última actualización: 2026-01-14

2.1 Inventario de activos

Confidencialidad del contenido: los bytes de los archivos en texto plano y las claves de descifrado (CEK) DEBEN estar protegidos.
Integridad del contenido: el texto cifrado y los metadatos DEBEN permitir detectar cualquier manipulación (autenticación AEAD).
Control de acceso: tokens de acceso de corta duración, tokens de inicio de sesión del remitente y estado de revocación.
Disponibilidad: capacidad de subir, descargar y reanudar transferencias en condiciones de red habituales.

2.2 Modelo de atacante

Atacante de red: puede observar, retrasar, descartar y reproducir el tráfico; no puede romper la criptografía TLS/AEAD moderna.
Atacante web: puede crear enlaces maliciosos, probar XSS/CSRF e intentar la inyección en la interfaz o la inyección de prompts.
Actor de abuso: puede automatizar subidas y descargas para agotar cuotas, extraer contenido (scraping) o amplificar el tráfico.
Se supone que el adversario del lado del servidor no tiene la CEK; si la CEK se filtra (por ejemplo, al compartir el enlace), la confidencialidad se pierde por diseño.

2.3 Supuestos de seguridad

Los clientes ejecutan código de confianza (sin extensiones maliciosas ni malware); de lo contrario, el conocimiento cero no puede proteger el dispositivo del usuario.
Los fragmentos de URL (#...) no se transmiten al servidor en las solicitudes HTTP con el comportamiento estándar de los navegadores.
Las primitivas criptográficas (AES-GCM, SHA-256, TLS) se usan correctamente y no están rotas.

2.4 Límites de confianza

Límite del cliente: el cifrado/descifrado y la gestión de la CEK ocurren solo en el cliente.
Límite de edge/API: el servidor valida tokens y sirve el texto cifrado y el manifiesto; NO DEBE llegar a conocer la CEK.
Límite del almacenamiento de objetos: almacena fragmentos de texto cifrado y manifiestos; se trata como no confiable en cuanto a confidencialidad.

2.5 Principio de fallo cerrado

Ante un fallo del token, una discrepancia de parámetros o un fallo de autenticación AEAD, el sistema DEBE fallar de forma cerrada.
NO DEBE producir texto plano parcial cuando fallan las comprobaciones de integridad.
Los mensajes de error y los registros DEBERÍAN minimizar los datos sensibles y NO DEBEN incluir fragmentos de URL, la CEK ni material del que esta pueda derivarse.