Logo

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

Este capítulo establece un modelo de amenaza compartido y un vocabulario de límites de confianza: qué activos protegemos, qué pueden hacer los atacantes, qué suposiciones deben cumplirse y cómo DEBE fallar el sistema al cerrarse en caso de autenticación o 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 archivos de texto plano y las claves de descifrado (CEK) DEBEN estar protegidos.
  • Integridad del contenido: El texto cifrado y los metadatos DEBEN ser a prueba de manipulaciones (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.
  • Availability: capacidad de cargar, descargar y reanudar transferencias en condiciones de red comunes.

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 de interfaz de usuario/inyección rápida.
  • Actor de abuso: puede automatizar cargas y descargas para agotar cuotas, extraer contenido o amplificar el tráfico.
  • Se supone que el adversario del lado del servidor no tiene la CEK; Si se filtra CEK (por ejemplo, se comparte un enlace), la confidencialidad se pierde por diseño.

2.3 Supuestos de seguridad

  • Los clientes ejecutan código confiable (sin extensiones maliciosas ni malware); de lo contrario, el conocimiento cero no puede proteger el punto final.
  • Fragmentos de URL (#...) no se transmiten al servidor a través de solicitudes HTTP bajo el comportamiento estándar del navegador.
  • Las primitivas criptográficas (AES-GCM, SHA-256, TLS) se utilizan correctamente y no están rotas.

2.4 Límites de confianza

  • Límite del cliente: El cifrado/descifrado y la gestión CEK ocurren solo en el cliente.
  • Límite de borde/API: el servidor valida tokens y entrega texto cifrado/manifiesto; NO DEBE aprender CEK.
  • Límite de almacenamiento de objetos: almacena fragmentos de texto cifrado y manifiestos; tratados como no confiables por motivos de confidencialidad.

2.5 Principio cerrado ante fallos

  • En caso de falla del token, falta de coincidencia de parámetros o falla de autenticación AEAD, el sistema DEBE cerrarse por error.
  • NO DEBE generar texto plano parcial cuando fallan las comprobaciones de integridad.
  • Los mensajes de error y los registros DEBEN minimizar los datos confidenciales y NO DEBEN incluir fragmentos de URL, CEK ni materiales derivables.