Documento Técnico de Seguridad

Análisis técnico detallado de cómo RocketShare protege sus archivos con encriptación de conocimiento cero

Este documento proporciona una descripción técnica completa de cómo RocketShare protege sus datos. Está dirigido a profesionales de la seguridad, responsables de cumplimiento normativo y cualquier persona que desee comprender exactamente cómo funciona nuestra encriptación.

1. Resumen ejecutivo

RocketShare es una plataforma de intercambio de archivos con encriptación de conocimiento cero. Los archivos se encriptan del lado del cliente mediante AES-256-GCM antes de la carga, y la clave de encriptación se incluye exclusivamente en el fragmento de la URL—una parte de la URL que los navegadores nunca transmiten a los servidores. Esta arquitectura significa que los operadores de RocketShare no pueden acceder, leer ni desencriptar archivos de usuarios bajo ninguna circunstancia, incluyendo solicitudes de intercepción legal.

Propiedades clave:

  • Arquitectura de conocimiento cero — el servidor nunca posee las claves de desencriptación
  • Encriptación de extremo a extremo — los archivos se encriptan antes de salir del dispositivo del remitente y se desencriptan solo en el dispositivo del destinatario
  • Sin almacenamiento de claves del lado del servidor — las claves existen únicamente en el fragmento de la URL del enlace para compartir
  • Caducidad y eliminación automática — los archivos se eliminan permanentemente después de su caducidad

2. Modelo de amenazas

Contra qué protegemos

  • Compromiso del servidor — incluso si un atacante obtiene acceso completo a nuestros servidores, los archivos almacenados permanecen encriptados e ilegibles sin la clave específica de cada transferencia
  • Interceptación de red — TLS 1.3 protege los datos en tránsito; las claves de encriptación en los fragmentos de URL nunca se envían a través de la red
  • Amenazas internas — los operadores de RocketShare no tienen acceso al contenido de los archivos por diseño, no por política
  • Intercepción legal — no podemos cumplir con solicitudes de desencriptación porque no poseemos las claves; solo podemos proporcionar blobs encriptados y metadatos

Qué está fuera de nuestro modelo de amenazas

  • Dispositivo comprometido del remitente o destinatario — si hay malware con acceso al navegador del usuario, podría interceptar claves o archivos en texto plano
  • Interceptación del enlace para compartir — cualquiera que obtenga el enlace completo para compartir (incluyendo el fragmento de URL) puede desencriptar los archivos; los usuarios deben compartir enlaces de forma segura
  • Vulnerabilidades del navegador — dependemos de la API Web Crypto proporcionada por el navegador; las vulnerabilidades a nivel del navegador están fuera de nuestro control

3. Implementación de la encriptación

Algoritmo

Toda la encriptación de archivos utiliza AES-256-GCM (Modo Galois/Contador), un algoritmo de encriptación autenticada simétrica. GCM proporciona tanto confidencialidad como integridad, lo que significa que cualquier manipulación del texto cifrado se detecta durante la desencriptación.

Generación de claves

Las claves de encriptación se generan del lado del cliente utilizando la API Web Crypto del navegador (crypto.subtle.generateKey), que está respaldada por el generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) del sistema operativo.

  • Tamaño de la clave: 256 bits
  • Fuente: API Web Crypto (crypto.subtle.generateKey), respaldada por CSPRNG a nivel del sistema operativo
  • Alcance: una clave única por transferencia (archivo o paquete)

Proceso de encriptación

  1. El usuario selecciona archivos para cargar
  2. Se genera una clave AES de 256 bits usando crypto.subtle.generateKey()
  3. Se genera un vector de inicialización (IV) único de 96 bits por operación de encriptación
  4. Los archivos se encriptan en el navegador usando AES-256-GCM a través de la API Web Crypto
  5. El texto cifrado encriptado se carga en el servidor
  6. El material de clave sin procesar se codifica en Base64url y se coloca en el fragmento de URL (#<clave-base64url>)

Encriptación en streaming

Para archivos grandes, RocketShare utiliza un enfoque de encriptación en streaming. Los archivos se procesan en fragmentos para minimizar el uso de memoria, permitiendo la encriptación y carga de archivos que superan la RAM disponible.

Cada fragmento se encripta con su propio IV de 96 bits generado aleatoriamente (crypto.getRandomValues), asegurando texto cifrado único para cada fragmento incluso si el contenido del archivo se repite.

4. Gestión de claves

Enfoque de fragmento de URL

La clave de desencriptación se incluye en el fragmento de URL (la porción después de #). Esta es la propiedad de seguridad crítica del sistema:

  • Los navegadores nunca transmiten fragmentos de URL a los servidores en solicitudes HTTP (RFC 3986, Sección 3.5)
  • El fragmento permanece completamente del lado del cliente — en la barra de direcciones del navegador, historial, y cuando es compartido por el usuario
  • El servidor solo recibe la ruta y los parámetros de consulta, nunca la porción de clave #...

Ciclo de vida de la clave

  1. Generación — creada en el navegador del remitente usando CSPRNG
  2. Uso — usada inmediatamente para encriptación del lado del cliente
  3. Inclusión — colocada en el fragmento de URL del enlace para compartir
  4. Transmisión — el usuario comparte el enlace a través de su canal seguro preferido (correo electrónico, mensajería, etc.)
  5. Desencriptación — el navegador del destinatario lee el fragmento y desencripta el archivo
  6. Sin almacenamiento — las claves nunca se almacenan en el servidor; existen solo en el enlace para compartir

Qué almacena el servidor

El servidor almacena únicamente:

  • Blobs de archivos encriptados (texto cifrado)
  • Metadatos de transferencia: nombre del archivo, tamaño del archivo, tipo MIME, fecha de caducidad
  • Configuración de transferencia: límite de descargas, hash de protección por contraseña (si está habilitado)
  • Datos a nivel de cuenta: correo electrónico, tokens de autenticación (no relacionados con la encriptación de archivos)

El servidor nunca almacena: claves de encriptación, contenido de archivos en texto plano, o cualquier dato que pueda usarse para derivar la clave.

5. Ciclo de vida del archivo

Carga

  1. El usuario selecciona archivos → se genera la clave de encriptación del lado del cliente
  2. Los archivos se encriptan con AES-256-GCM en el navegador
  3. Los blobs encriptados se cargan al servidor a través de TLS 1.3
  4. El servidor almacena texto cifrado + metadatos, devuelve ID de transferencia
  5. Se construye el enlace para compartir: https://rocketshare.app/d/{id}#{clave-base64url}

Almacenamiento

  • Los archivos encriptados se almacenan en almacenamiento de objetos compatible con S3 alojado en la UE (Ámsterdam)
  • Los archivos se almacenan como blobs encriptados opacos — el proveedor de almacenamiento no puede leerlos
  • Los metadatos se almacenan en PostgreSQL con encriptación en reposo en el volumen de la base de datos

Descarga

  1. El destinatario abre el enlace para compartir
  2. El navegador extrae la clave del fragmento de URL (nunca enviado al servidor)
  3. El blob encriptado se descarga del servidor
  4. La desencriptación ocurre completamente en el navegador del destinatario
  5. El archivo en texto plano se presenta al usuario para su descarga

Caducidad y eliminación

  • Las transferencias tienen una caducidad configurable (3 días a 90 días dependiendo del plan)
  • Después de la caducidad, una tarea de limpieza programada elimina permanentemente los blobs encriptados del almacenamiento de objetos y los registros de archivos de la base de datos
  • El registro de metadatos de transferencia (nombres de archivos, tamaños, marcas de tiempo) se conserva en estado caducado para fines contables y de auditoría, pero todos los datos de archivos encriptados se eliminan de forma irreversible
  • No se mantienen copias de seguridad de datos de archivos caducados

6. Infraestructura

Alojamiento

  • Aplicación: desplegada en Cloudflare Workers (computación en el borde)
  • Base de datos: PostgreSQL, alojada en la UE
  • Almacenamiento de objetos: compatible con S3, región UE (Ámsterdam)
  • Caché: Cloudflare KV (almacén clave-valor), solo para datos de sesión y limitación de velocidad — nunca usado para contenido de archivos
  • CDN: red global de Cloudflare para activos estáticos y enrutamiento en el borde

Residencia de datos

Todos los servidores de almacenamiento de archivos y bases de datos están ubicados dentro de la Unión Europea. No replicamos datos de archivos fuera de la UE.

Seguridad de red

  • TLS 1.3 aplicado en todas las conexiones (HTTP y base de datos)
  • HSTS con precarga — se instruye a los navegadores para usar siempre HTTPS
  • Encabezados de seguridad HTTP — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Sin contenido mixto — todos los recursos cargados a través de HTTPS

7. Autenticación y control de acceso

Autenticación de usuario

  • Correo electrónico/contraseña — contraseñas hasheadas con scrypt (N=16384, r=16, p=1), longitud mínima de 8 caracteres aplicada
  • OAuth — SSO de Google y Microsoft a través de OAuth 2.0 / OpenID Connect estándar de la industria
  • Gestión de sesiones — cookies seguras HTTP-only con atributos SameSite apropiados

Controles de acceso a transferencias

  • Acceso basado en enlace — cualquiera con el enlace completo para compartir puede desencriptar (la clave está en la URL)
  • Protección opcional por contraseña — las transferencias pueden requerir una contraseña adicional; el hash de contraseña se verifica del lado del servidor antes de entregar el blob encriptado
  • Límites de descarga — número máximo configurable de descargas antes de que el enlace se deshabilite
  • Caducidad — caducidad automática basada en tiempo después de la cual los datos de archivos encriptados se eliminan permanentemente

8. Minimización de datos y retención

Principio de mínimos datos

Recopilamos solo lo necesario para operar el servicio:

  • Datos de cuenta: dirección de correo electrónico, nombre (si se proporciona a través de OAuth), contraseña hasheada
  • Metadatos de transferencia: nombres de archivos, tamaños, tipos MIME, marcas de tiempo, fechas de caducidad
  • Datos de uso: recuentos de transferencias y almacenamiento utilizado (para aplicación del plan)
  • Analítica: patrones de uso anonimizados a través de PostHog (alojado en la UE, configuración centrada en la privacidad)

Qué no recopilamos

  • Contenido de archivos (no podemos acceder a blobs encriptados)
  • Claves de encriptación
  • Direcciones IP en almacenamiento a largo plazo (los registros de acceso son efímeros)
  • Historial de navegación o datos de seguimiento entre sitios

Retención

  • Transferencias: datos de archivos encriptados eliminados automáticamente al caducar; metadatos de transferencia conservados en estado caducado
  • Datos de cuenta: conservados mientras la cuenta está activa; eliminados al solicitar eliminación de cuenta
  • Registros de acceso: efímeros, no persistidos más allá del ciclo de vida de la solicitud

9. Respuesta a incidentes

En caso de un incidente de seguridad:

  1. Contención — aislar sistemas afectados inmediatamente
  2. Evaluación — determinar alcance e impacto; gracias a la arquitectura de conocimiento cero, una brecha del servidor no expone el contenido de los archivos
  3. Notificación — los usuarios afectados son notificados dentro de 72 horas según lo requerido por GDPR
  4. Remediación — solucionar causa raíz, mejorar defensas
  5. Divulgación — divulgación pública del incidente y nuestra respuesta

Los problemas de seguridad pueden reportarse a través de nuestra política de Divulgación Responsable.

10. Limitaciones y transparencia

Creemos en ser transparentes sobre qué protege y qué no protege nuestra arquitectura de seguridad:

  • No podemos recuperar enlaces perdidos — si un usuario pierde el enlace para compartir (incluyendo el fragmento de URL), los archivos encriptados no pueden desencriptarse. No tenemos la clave.
  • La seguridad del enlace es responsabilidad del usuario — el enlace para compartir es la única credencial de acceso. Si es interceptado (por ejemplo, enviado a través de un canal inseguro), el interceptor puede desencriptar los archivos.
  • CSP con política de scripts basada en nonce — usamos Política de Seguridad de Contenido con strict-dynamic y fuentes de scripts basadas en nonce, que es el enfoque recomendado para aplicaciones SSR. Los estilos en línea todavía requieren unsafe-inline debido a Tailwind CSS.
  • Confianza en el navegador — nuestra encriptación depende de la API Web Crypto. Si el navegador está comprometido, todo está en riesgo.
  • Visibilidad de metadatos — aunque el contenido de los archivos está encriptado, los nombres de archivos, tamaños y marcas de tiempo son visibles para el servidor con fines operativos.

Este documento técnico está actualizado a febrero de 2026. Actualizamos este documento cuando nuestra arquitectura de seguridad cambia. Para preguntas, contáctenos.