Documento técnico sobre seguridad y privacidad (descripción general)Apéndice
Apéndice: índice de ID de afirmaciones (fuente única de verdad)
Este apéndice es la fuente única de verdad de todos los ID de afirmaciones del documento técnico. Cada afirmación tiene un identificador y un ancla únicos y estables, y se presenta en una sola línea con una Declaración y una Evidencia. La evidencia enlaza únicamente con referencias autorizadas que se pueden verificar de forma repetible (anclas de capítulos o puntos de entrada a informes de estado o de terceros) y no enlaza con capturas de pantalla ni con contenido alojado de nuevo.
Reglas de mantenimiento
- MUST: Los ID de afirmaciones son únicos y estables; una vez publicados, nunca se reutilizan.
- MUST: La evidencia de cada afirmación debe poder verificarse de forma repetible (anclas de capítulos o puntos de entrada autorizados de terceros).
- MUST: Las declaraciones solo deben afirmar lo que respalda la evidencia; evita el lenguaje de «seguridad absoluta».
- SHOULD: Cuando un cambio de implementación o de política afecte a una afirmación, regístralo en el registro de cambios y enlaza los ID de afirmaciones afectados.
Capítulos 1–4 (alcance, modelo de amenazas, arquitectura, autorización)
SCOPE-01
Declaración: El documento define con claridad qué riesgos están dentro y fuera del alcance, y el límite de seguridad del sistema. Evidencia:1.3， 1.4
THREAT-01
Declaración: El modelo de amenazas abarca ataques de red, descargas no autorizadas, intentos de lectura en el almacenamiento o en el servidor, y atacantes en el lado del navegador. Evidencia:2.2
BOUNDARY-01
Declaración: Los límites de confianza separan con claridad las responsabilidades entre el cliente, el servidor, el almacenamiento de objetos y el entorno externo; el servidor NO DEBE obtener la CEK. Evidencia:2.4
FAILCLOSE-01
Declaración: Ante un fallo de autenticación o un contexto inconsistente, el sistema debe fallar en modo cerrado y no emitir texto plano parcial. Evidencia:2.5
ARCH-01
Declaración: Los objetos de datos principales están claramente separados: los fragmentos cifrados, el manifiesto y los datos de auditoría están aislados entre sí. Evidencia:3.2
FLOW-UP-01
Declaración: El flujo de subida incluye crear un transferId y emitir tokens de acceso de corta duración (tokens de sesión basados en consulta) con controles estrictos de ámbito y caducidad. Evidencia:3.3
FLOW-DL-01
Declaración: Las descargas leen el fragmento de la URL para obtener la CEK; la lectura del manifiesto y la de los fragmentos usan tokens con ámbitos distintos; los fallos de autenticación fallan en modo cerrado. Evidencia:3.4， 2.5
AUTH-TOKEN-01
Declaración: Los tokens de acceso de corta duración son tokens de sesión del lado del servidor (basados en consulta) que caducan y se usan para controlar el acceso al texto cifrado y a los manifiestos. Evidencia:4.2
AUTH-SCOPE-01
Declaración: Los tokens se separan por ámbitos como read_manifest / read_chunk / upload_chunk y se validan de forma estricta. Evidencia:4.3， 4.4， 3.4
AUTH-PAID-01
Declaración: Los usuarios de pago inician sesión mediante un enlace mágico de un solo uso y obtienen un token de larga duración, conservado en el cliente, para las acciones de gestión del remitente. Evidencia:4.1， 3.5
REVOKE-01
Declaración: El remitente puede revocar el acceso: eliminar una transferencia o quitar archivos invalida las descargas antes de tiempo y deniega cualquier acceso posterior. Evidencia:4.5
AUDIT-01
Declaración: Los datos de auditoría, como el número de descargas y el progreso, solo son visibles para el remitente y no para el destinatario. Evidencia:4.6， 3.5
LOG-01
Declaración: Los registros y la telemetría del cliente y del servidor no incluyen la CEK, los fragmentos de URL ni ningún material de clave derivable. Evidencia:4.7， 10.2
Capítulo 5 (criptografía y gestión de claves)
CRYPTO-ZK-01
Declaración: La CEK se genera únicamente en el navegador y se distribuye mediante el fragmento de la URL; el servidor nunca genera un enlace de descarga completo que contenga la CEK. Evidencia:5.3.1， 5.3.2
CRYPTO-ZK-02
Declaración: El servidor no recibe, almacena ni registra la CEK; el almacenamiento de objetos guarda únicamente fragmentos cifrados. Evidencia:5.0， 5.5.1
CRYPTO-E2EE-01
Declaración: Los fragmentos usan AES-128-GCM; un fallo de autenticación debe fallar en modo cerrado y no emitir texto plano parcial. Evidencia:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Declaración: chunkSize es fijo y vale 16 MB (16777216). Evidencia:5.4.1， 5.8.1
CRYPTO-NONCE-01
Declaración: El IV se deriva como noncePrefix(8B)||uint32_be(chunkIndex) y no debe repetirse con la misma CEK. Evidencia:5.4.3， 5.8.1
CRYPTO-AAD-01
Declaración: El AAD está vinculado a transferId + fileId + chunkIndex y se codifica mediante EncodeAAD_v1. Evidencia:5.4.4
CRYPTO-CLIENT-01
Declaración: Las páginas de descarga y descifrado no cargan scripts de terceros; los registros y la telemetría del cliente no incluyen fragmentos ni material de claves. Evidencia:5.6， 10.2
CRYPTO-TLS-01
Declaración: Se aplica HTTPS en todo el sitio; la configuración de TLS se puede verificar mediante informes públicos de terceros. Evidencia:5.1.2， /status#tls-configuration
Capítulos 6–7 (ciclo de vida de los datos / defensa contra abusos)
LIFECYCLE-01
Declaración: La caducidad y la eliminación iniciada por el usuario activan la limpieza; se admite la revocación para invalidar las descargas antes de tiempo. Evidencia:6.2， 6.3， 4.5
ABUSE-01
Declaración: La defensa contra abusos usa limitación de tasa y controles por niveles, y funciona sin romper el límite del conocimiento cero. Evidencia:7.2， 7.4
Capítulos 8–9 (privacidad / seguridad web y aislamiento)
PRIVACY-01
Declaración: La definición de conocimiento cero y sus compromisos son explícitos: la CEK se genera y se usa únicamente en el cliente; el servidor no puede recuperar la clave. Evidencia:8.1
PRIVACY-02
Declaración: Las implicaciones de privacidad de los fragmentos de URL (copiar y pegar, fuga por el referrer, registros) están documentadas junto con sus medidas de mitigación. Evidencia:8.2， 10.2
WEB-01
Declaración: Las páginas clave aplican una CSP estricta y límites de recursos para reducir el riesgo de inyección y de clickjacking. Evidencia:9.1， 9.3
WEB-HEADERS-01
Declaración: La línea base de cabeceras de seguridad se puede verificar mediante informes públicos de terceros. Evidencia:/status#security-headers
WEB-OBS-01
Declaración: El sitio se puede comprobar mediante análisis públicos de buenas prácticas de terceros. Evidencia:/status#http-observatory
Capítulos 10–12 (registros y respuesta a incidentes / divulgación de vulnerabilidades / evidencias)
OBS-01
Declaración: La observabilidad sigue un principio de mínimos: cubre solo las necesidades de operación y seguridad y usa estrategias de agregación y muestreo. Evidencia:10.1
IR-01
Declaración: Existe un proceso definido de respuesta a incidentes de seguridad (gravedad, contención, análisis posterior, corrección y aviso público). Evidencia:10.4
VDP-01
Declaración: Existe un proceso de divulgación de vulnerabilidades que da prioridad a los problemas que podrían afectar al límite del conocimiento cero. Evidencia:11.2
EV-01
Declaración: La página de estado reúne los puntos de entrada a evidencias de terceros; las evidencias enlazan con fuentes autorizadas y aclaran los límites de aplicabilidad. Evidencia:12.2， 12.6