Logo

Informe 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 cryptoVersion=v1 parámetros, reglas de codificación, modos de falla y restricciones del cliente. Las claves se generan y utilizan en el cliente; el servidor y el almacenamiento de objetos manejan solo fragmentos de texto cifrado y metadatos requeridos.

5.0 Resumen

  • El sistema NO DEBE recibir, almacenar ni registrar claves de descifrado (CEK). El material CEK se transporta únicamente en el fragmento de URL (# parte), que no se envía al servidor en solicitudes HTTP.
  • Usos del cifrado AES-128-GCM (AEAD). Cada archivo utiliza una CEK independiente (16 bytes). El tamaño del fragmento es fijo (por ejemplo, 16 MB).
  • construcción v1 IV: IV = noncePrefijo(8B) || uint32_be(índice de fragmentos)(4B). AAD binds transferId, fileId, y chunkIndex para evitar el intercambio de contexto y la repetición.
  • Los tokens de servidor sólo controlan el acceso al texto cifrado y caducan; no otorgan capacidad de descifrado.

5.1 Cifrado de transporte (TLS)

5.1.1 Objetivo de seguridad

  • Evite las escuchas ilegales y la manipulación de enlaces de carga/descarga/API.
  • Proteja tokens y texto cifrado en tránsito.

5.1.2 Política de seguridad

  • el sistema MUST Sirve todas las páginas y API solo a través de HTTPS.
  • el sistema SHOULD prefiera TLS 1.3 y admita TLS 1.2 según sea necesario; los protocolos/cifrados débiles DEBEN estar desactivados.
  • el sistema MUST habilitar HSTS con un tiempo razonable max-age.

5.2 Cifrado de fragmentos (AES-128-GCM)

5.2.1 Notas de diseño

  • Los archivos se dividen en partes de tamaño fijo; Cada fragmento se cifra de forma independiente para admitir la transferencia paralela y la reanudación.
  • La autenticación AEAD protege la integridad; cualquier falla de autenticación DEBE cerrarse.

5.2.2 Política de seguridad

  • Cada archivo DEBE utilizar una CEK distinta (16 bytes).
  • IV DEBE ser único por (archivo, índice de fragmentos). usos v1 noncePrefix + chunkIndex encoding.
  • 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

  • CEK (o material de derivación) DEBE transportarse únicamente en el fragmento de URL y NO DEBE incluirse en los parámetros o encabezados de consulta.
  • El servidor NO DEBE registrar fragmentos; los registros DEBEN desinfectarse para evitar la captura accidental.
  • La política de referencia DEBE evitar la fuga de fragmentos a través de la navegación de salida (consulte el Capítulo 9).

5.4 Generación y manejo de claves

  • Las claves DEBEN generarse utilizando un RNG criptográficamente seguro (WebCrypto).
  • Las claves DEBEN mantenerse en la memoria únicamente y borrarse cuando ya no sean necesarias.
  • Los clientes NO DEBEN conservar CEK en ubicaciones visibles del servidor (por ejemplo, cookies, parámetros de consulta).

5.5 Codificación y parámetros

  • cryptoVersion=v1 Identifica el conjunto de algoritmos y las reglas IV/AAD.
  • El manifiesto DEBE incluir los parámetros públicos requeridos (tamaño/recuento de fragmentos, noncePrefix, mapeo de ID de archivo), pero NO DEBE incluir CEK.

5.6 Modos de falla (falla cerrada)

  • En caso de error de descifrado o de autenticación AEAD, los clientes DEBEN cancelar y NO DEBEN generar texto sin formato parcial.
  • En caso de discrepancia de parámetros (transferId/fileId/chunkIndex), los clientes DEBEN cerrarse y DEBEN informar un error procesable.

5.7 ID de reclamaciones relacionadas