Logo

Documento técnico sobre seguridad y privacidad (descripción general)Capítulo 5

Capítulo 5 Criptografía y gestión de claves

Este capítulo describe el cifrado de extremo a extremo (E2EE) y el límite de conocimiento cero de FileBolt, y especifica los parámetros de cryptoVersion=v1, las reglas de codificación, los modos de fallo y las restricciones del cliente. Las claves se generan y se usan en el cliente; el servidor y el almacenamiento de objetos solo manejan fragmentos cifrados y los metadatos necesarios.

5.0 Resumen

  • El sistema NO DEBE recibir, almacenar ni registrar las claves de descifrado (CEK). El material de la CEK viaja únicamente en el fragmento de la URL (la parte tras #), que no se envía al servidor en las solicitudes HTTP.
  • El cifrado usa AES-128-GCM (AEAD). Cada archivo usa una CEK independiente (16 bytes). El tamaño de los fragmentos es fijo (por ejemplo, 16 MB).
  • Construcción del IV en v1: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). El AAD vincula transferId, fileId y chunkIndex para impedir el intercambio de contexto y los ataques de repetición.
  • Los tokens del servidor solo controlan el acceso al texto cifrado y caducan; no conceden capacidad de descifrado.

5.1 Cifrado en tránsito (TLS)

5.1.1 Objetivo de seguridad

  • Impedir las escuchas y la manipulación en los enlaces de subida, descarga y API.
  • Proteger los tokens y el texto cifrado en tránsito.

5.1.2 Política de seguridad

  • El sistema DEBE servir todas las páginas y API únicamente por HTTPS.
  • El sistema DEBERÍA preferir TLS 1.3 y admitir TLS 1.2 cuando sea necesario; los protocolos y cifrados débiles DEBEN estar desactivados.
  • El sistema DEBE habilitar HSTS con un valor razonable de max-age.

5.2 Cifrado por fragmentos (AES-128-GCM)

5.2.1 Notas de diseño

  • Los archivos se dividen en fragmentos de tamaño fijo; cada fragmento se cifra de forma independiente para permitir la transferencia en paralelo y la reanudación.
  • La autenticación AEAD protege la integridad; cualquier fallo de autenticación DEBE provocar un cierre ante el fallo.

5.2.2 Política de seguridad

  • Cada archivo DEBE usar una CEK distinta (16 bytes).
  • El IV DEBE ser único para cada (archivo, chunkIndex). La v1 usa la codificación noncePrefix + chunkIndex.
  • El AAD DEBE incluir (transferId, fileId, chunkIndex) para vincular el texto cifrado a su contexto.

5.3 Modelo de enlace de conocimiento cero

5.3.1 Restricciones clave

  • La CEK (o el material de derivación) DEBE viajar únicamente en el fragmento de la URL y NO DEBE incluirse en los parámetros de consulta ni en las cabeceras.
  • El servidor NO DEBE registrar los fragmentos; los registros DEBEN sanearse para evitar capturas accidentales.
  • La política de referrer DEBERÍA impedir la fuga del fragmento mediante la navegación saliente (véase el capítulo 9).

5.4 Generación y gestión de claves

  • Las claves DEBEN generarse con un generador de números aleatorios criptográficamente seguro (WebCrypto).
  • Las claves DEBERÍAN mantenerse solo en memoria y borrarse cuando ya no se necesiten.
  • Los clientes NO DEBEN guardar la CEK en ubicaciones visibles para el servidor (por ejemplo, cookies o parámetros de consulta).

5.5 Codificación y parámetros

  • cryptoVersion=v1 identifica el conjunto de algoritmos y las reglas de IV/AAD.
  • El manifiesto DEBE incluir los parámetros públicos necesarios (tamaño y número de fragmentos, noncePrefix, correspondencia de fileId), pero NO DEBE incluir la CEK.

5.6 Modos de fallo (cierre ante el fallo)

  • Ante un fallo de descifrado o de autenticación AEAD, los clientes DEBEN abortar y NO DEBEN mostrar texto sin cifrar parcial.
  • Ante una discrepancia de parámetros (transferId/fileId/chunkIndex), los clientes DEBEN cerrarse ante el fallo y DEBERÍAN notificar un error accionable.

5.7 ID de afirmaciones relacionados