Informe técnico sobre seguridad y privacidad (descripción general)Appendix

Apéndice: Índice de identificación de reclamaciones (fuente única de verdad)

Este apéndice es la única fuente de información para todos los ID de reclamaciones del documento técnico. Cada reclamo tiene un identificador y un ancla únicos y estables, y se presenta en una sola línea con un Statement and Evidence. La evidencia se vincula solo a referencias autorizadas repetiblemente verificables (anclajes de capítulos o puntos de entrada de informes de estado/terceros) y no se vincula a capturas de pantalla ni a contenido rehospedado.

Reglas de mantenimiento

MUST: Los ID de reclamo son únicos y estables; una vez publicados, nunca se reutilizan.
MUST: La evidencia de cada reclamo debe ser verificable repetidamente (anclajes de capítulos o puntos de entrada autorizados de terceros).
MUST: Las declaraciones sólo deben afirmar lo que respalda la evidencia; Evite el lenguaje de “seguridad absoluta”.
SHOULD: Cuando los cambios de implementación o política afecten un reclamo, regístrelo en el registro de cambios y vincule los ID de reclamo afectados.

Capítulos 1 a 4 (alcance, modelo de amenaza, arquitectura, AuthZ)

SCOPE-01

Statement: El documento define claramente los riesgos dentro y fuera del alcance y los límites de seguridad del sistema. Evidence:1.3， 1.4

THREAT-01

Statement: El modelo de amenaza cubre ataques a la red, descargas no autorizadas, intentos de lectura del lado del servidor/almacenamiento y atacantes del lado del navegador. Evidence:2.2

BOUNDARY-01

Statement: Los límites de confianza separan claramente las responsabilidades entre el cliente, el servidor, el almacenamiento de objetos y el entorno externo; el servidor NO DEBE obtener CEK. Evidence:2.4

FAILCLOSE-01

Statement: En caso de falla de autenticación o contexto inconsistente, el sistema debe cerrarse y no generar texto sin formato parcial. Evidence:2.5

ARCH-01

Statement: Los objetos de datos centrales están claramente separados: los fragmentos cifrados, los datos de manifiesto y de auditoría están aislados entre sí. Evidence:3.2

FLOW-UP-01

Statement: El flujo de carga incluye la creación de un transferId y la emisión de tokens de acceso de corta duración (tokens de sesión basados en búsquedas) con estrictos controles de alcance y vencimiento. Evidence:3.3

FLOW-DL-01

Statement: Las descargas analizan el fragmento de URL para obtener CEK; las lecturas de manifiesto y fragmentos utilizan tokens de alcance diferente; Las fallas de autenticación fallan cerradas. Evidence:3.4， 2.5

AUTH-TOKEN-01

Statement: Los tokens de acceso de corta duración son tokens de sesión del lado del servidor (basados en búsquedas) que caducan y se utilizan para el control de acceso a texto cifrado y manifiestos. Evidence:4.2

AUTH-SCOPE-01

Statement: Los tokens están separados por ámbitos como read_manifest/read_chunk/upload_chunk y están estrictamente validados. Evidence:4.3， 4.4， 3.4

AUTH-PAID-01

Statement: Los usuarios pagos inician sesión a través de un enlace mágico único y obtienen un token de larga duración en poder del cliente para acciones de administración del lado del remitente. Evidence:4.1， 3.5

REVOKE-01

Statement: El remitente puede revocar el acceso: eliminar una transferencia o eliminar archivos invalida las descargas anticipadamente y deniega el acceso posterior. Evidence:4.5

AUDIT-01

Statement: Los datos de auditoría, como el recuento de descargas y el progreso, son visibles solo para el remitente y no para el receptor. Evidence:4.6， 3.5

LOG-01

Statement: Los registros/telemetría del cliente y del servidor no incluyen CEK, fragmentos de URL ni ningún material de clave derivable. Evidence:4.7， 10.2

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

CRYPTO-ZK-01

Statement: CEK se genera únicamente en el navegador y se distribuye a través del fragmento de URL; el servidor nunca genera un enlace de descarga completo que contenga CEK. Evidence:5.3.1， 5.3.2

CRYPTO-ZK-02

Statement: El servidor no recibe/almacena/registra CEK; El almacenamiento de objetos almacena solo fragmentos cifrados. Evidence:5.0， 5.5.1

CRYPTO-E2EE-01

Statement: Los fragmentos utilizan AES-128-GCM; La falla de autenticación debe fallar y no generar texto sin formato parcial. Evidence:5.4.2， 5.8.4

CRYPTO-CHUNK-01

Statement: El tamaño del fragmento está fijado en 16 MB (16777216). Evidence:5.4.1， 5.8.1

CRYPTO-NONCE-01

Statement: IV se deriva como noncePrefix(8B)||uint32_be(chunkIndex) y no debe repetirse bajo la misma CEK. Evidence:5.4.3， 5.8.1

CRYPTO-AAD-01

Statement: AAD está vinculado a transferId + fileId + chunkIndex y codificado mediante EncodeAAD_v1. Evidence:5.4.4

CRYPTO-CLIENT-01

Statement: Las páginas de descarga/descifrado no cargan scripts de terceros; Los registros/telemetría del cliente no incluyen fragmentos ni material de claves. Evidence:5.6， 10.2

CRYPTO-TLS-01

Statement: Se aplica HTTPS en todo el sitio; La configuración de TLS se puede verificar mediante informes públicos de terceros. Evidence:5.1.2， /status#tls-configuration

Capítulos 6 a 7 (Ciclo de vida de los datos/Defensa contra abusos)

LIFECYCLE-01

Statement: La caducidad y la eliminación iniciada por el usuario activan la limpieza; Se admite la revocación para invalidar las descargas anticipadamente. Evidence:6.2， 6.3， 4.5

ABUSE-01

Statement: La defensa contra el abuso utiliza controles escalonados y que limitan la tasa, y opera sin romper el límite del conocimiento cero. Evidence:7.2， 7.4

Capítulos 8 y 9 (Privacidad/Seguridad web y aislamiento)

PRIVACY-01

Statement: La definición y los compromisos de conocimiento cero son explícitos: CEK se genera y utiliza únicamente en el cliente; el servidor no puede recuperar la clave. Evidence:8.1

PRIVACY-02

Statement: Las implicaciones de privacidad de los fragmentos de URL (copiar y pegar, fuga de referencias, registro) están documentadas con mitigaciones. Evidence:8.2， 10.2

WEB-01

Statement: Las páginas clave imponen estrictos límites de recursos y CSP para reducir el riesgo de inyección y clickjacking. Evidence:9.1， 9.3

WEB-HEADERS-01

Statement: La línea de base de los encabezados de seguridad se puede verificar mediante informes públicos de terceros. Evidence:/status#security-headers

WEB-OBS-01

Statement: El sitio se puede comprobar mediante análisis públicos de mejores prácticas de terceros. Evidence:/status#http-observatory

Capítulos 10 a 12 (Registro e IR / Divulgación de vulnerabilidad / Evidencia)

OBS-01

Statement: La observabilidad sigue un principio mínimo, que cubre solo las necesidades de operaciones/seguridad y utiliza estrategias de agregación/muestreo. Evidence:10.1

IR-01

Statement: Se define un proceso de respuesta a incidentes de seguridad (gravedad, contención, post mortem, remediación y aviso público). Evidence:10.4

VDP-01

Statement: Existe un proceso de divulgación de vulnerabilidades que prioriza los problemas que podrían afectar el límite del conocimiento cero. Evidence:11.2

EV-01

Statement: La página de estado agrega puntos de entrada de evidencia de terceros; la evidencia se vincula con fuentes autorizadas y aclara los límites de aplicabilidad. Evidence:12.2， 12.6