Logo

Capítulo 3 Arquitectura del sistema y flujo de datos

Este capítulo describe los componentes del sistema de alto nivel y el flujo de datos de un extremo a otro para la carga, descarga y administración del remitente. La atención se centra en qué está cifrado, qué metadatos se requieren y cómo se aplican el control de acceso y la revocación.

Metadatos del documento

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

3.1 Componentes

  • Client: fragmenta archivos, cifra/descifra y administra CEK en el fragmento de URL.
  • API/Edge: emite y valida tokens con alcance; sirve fragmentos de manifiesto y texto cifrado.
  • Almacenamiento de objetos: almacena fragmentos y manifiestos cifrados; tratado como no confiable para la confidencialidad del texto sin formato.
  • Tienda estatal: rastrea el estado de la transferencia (progreso de la carga, vencimiento, revocación) con metadatos mínimos.

3.2 Objetos de datos

  • Manifest: parámetros públicos necesarios para recuperar y ensamblar fragmentos (cryptoVersion, tamaño/recuento de fragmentos, mapeo); NO DEBE contener CEK.
  • Chunk: pieza de archivo cifrada (texto cifrado) más metadatos mínimos (longitud/etiqueta), direccionado por (transferId, fileId, chunkIndex).
  • State: registro del lado del servidor para autorización, TTL, revocación y reanudación.

3.3 Flujo de carga

  1. El cliente crea una transferencia y recibe un token de carga con alcance de corta duración vinculado a transferId.
  2. El cliente genera CEK por archivo localmente, divide los archivos en fragmentos de tamaño fijo y cifra cada fragmento con AEAD.
  3. El cliente carga fragmentos de texto cifrado en paralelo; los reintentos son idempotentes por fragmento.
  4. El cliente carga el manifiesto (solo parámetros públicos). El servidor marca la transferencia como LISTA cuando las piezas necesarias están presentes.

3.4 Flujo de descarga

  1. El destinatario abre el enlace para compartir. El fragmento de URL (material CEK) permanece en el navegador y no se envía al servidor.
  2. El cliente recupera el manifiesto utilizando un token de descarga con alcance y determina el plan de fragmentos.
  3. El cliente descarga fragmentos de texto cifrado (opcionalmente en paralelo), verifica la autenticación AEAD y luego ensambla el archivo de texto sin formato.
  4. En caso de falla, el cliente continúa solicitando solo los fragmentos que faltan; las fallas de integridad DEBEN fallar cerradas.

3.5 Gestión de remitentes y flujo de auditoría

  • Los remitentes se autentican utilizando un token de inicio de sesión de larga duración (almacenado en el cliente) para las operaciones de administración.
  • Las API de administración permiten enumerar transferencias, verificar evidencia de entrega y revocar/eliminar transferencias.
  • Los datos de auditoría están diseñados para ser visibles únicamente para el remitente; no está expuesto a los destinatarios de forma predeterminada.

3.6 Visibilidad y minimización

  • El servidor y el almacenamiento sólo manejan texto cifrado y parámetros públicos necesarios; no pueden descifrar contenido sin CEK.
  • Los registros y análisis DEBEN minimizarse y NO DEBEN incluir fragmentos de URL ni material CEK.
  • La recopilación de metadatos DEBE tener un propósito limitado (entrega de pruebas, prevención de abusos y confiabilidad operativa).