Logo

Capítulo 3 Arquitectura del sistema y flujo de datos

Este capítulo describe los componentes del sistema a alto nivel y el flujo de datos de extremo a extremo para la subida, la descarga y la gestión por parte del remitente. Se centra en qué se cifra, qué metadatos hacen falta 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

  • Cliente: divide los archivos en fragmentos, los cifra y descifra, y gestiona la CEK en el fragmento de la URL.
  • API/Edge: emite y valida tokens de ámbito limitado; sirve el manifiesto y los fragmentos de texto cifrado.
  • Almacenamiento de objetos: guarda los fragmentos cifrados y los manifiestos; se considera no fiable en cuanto a la confidencialidad del texto sin cifrar.
  • Almacén de estado: registra el estado de la transferencia (progreso de la subida, caducidad, revocación) con metadatos mínimos.

3.2 Objetos de datos

  • Manifiesto: parámetros públicos necesarios para obtener y ensamblar los fragmentos (cryptoVersion, tamaño y número de fragmentos, correspondencia); NO DEBE contener la CEK.
  • Fragmento: parte cifrada del archivo (texto cifrado) más metadatos mínimos (longitud/etag), direccionada por (transferId, fileId, chunkIndex).
  • Estado: registro del lado del servidor para la autorización, el TTL, la revocación y la reanudación.

3.3 Flujo de subida

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

3.4 Flujo de descarga

  1. El destinatario abre el enlace para compartir. El fragmento de la URL (material de la CEK) permanece en el navegador y no se envía al servidor.
  2. El cliente obtiene el manifiesto con un token de descarga de ámbito limitado y determina el plan de fragmentos.
  3. El cliente descarga los fragmentos de texto cifrado (opcionalmente en paralelo), verifica la autenticación AEAD y después ensambla el archivo en texto sin cifrar.
  4. Ante fallos, el cliente reanuda solicitando solo los fragmentos que faltan; los fallos de integridad DEBEN provocar un cierre ante el fallo.

3.5 Gestión del remitente y flujo de auditoría

  • Los remitentes se autentican con un token de inicio de sesión de larga duración (guardado en el cliente) para las operaciones de gestión.
  • Las API de gestión permiten listar las transferencias, consultar las pruebas de entrega y revocar o eliminar transferencias.
  • Los datos de auditoría están pensados para que solo los vea el remitente; por defecto no se exponen a los destinatarios.

3.6 Visibilidad y minimización

  • El servidor y el almacenamiento solo manejan texto cifrado y los parámetros públicos necesarios; no pueden descifrar el contenido sin la CEK.
  • Los registros y las analíticas DEBERÍAN reducirse al mínimo y NO DEBEN incluir fragmentos de URL ni material de la CEK.
  • La recopilación de metadatos DEBERÍA limitarse a su finalidad (pruebas de entrega, prevención de abusos y fiabilidad operativa).