Cifrado en reposo vs en tránsito: ambos son importantes

El cifrado en tránsito protege los datos que se mueven entre dos puntos —tu navegador y un servidor, por ejemplo— usando TLS 1.3 con AES-256-GCM o ChaCha20-Poly1305. El cifrado en reposo protege los datos almacenados en disco, típicamente con AES-256-XTS para cifrado de disco completo o AES-256-GCM por archivo. Ninguno por sí solo es suficiente. TLS protege contra la interceptación en red, pero descifra en el servidor; el cifrado en reposo protege los datos almacenados, pero es inútil si las claves viven junto al texto cifrado. La seguridad real viene de combinar ambos, idealmente junto con cifrado del lado del cliente (extremo a extremo) para que el servidor nunca vea el texto plano.

Dos amenazas distintas, dos controles distintos

Las amenazas tienen un aspecto diferente según dónde viven tus datos:

En tránsito (ruta de red): un atacante en una cafetería con un sniffer de paquetes, un router ISP comprometido, un estado interceptando cables submarinos. Los documentos Snowden de 2013 revelaron el programa MUSCULAR de la NSA que interceptaba los enlaces de fibra interna de Google. Defensa: TLS 1.3, preferiblemente con certificate pinning para apps.

En reposo (almacenamiento): un portátil robado, una cinta de copia de seguridad filtrada, un bucket de S3 mal configurado, un empleado del centro de datos con acceso al disco. La brecha de Equifax de 2017 expuso 147 millones de registros en parte porque los datos estaban sin cifrar. Defensa: LUKS, BitLocker, FileVault para discos; AES-256-GCM o AES-256-XTS por archivo o por bloque.

El error es tratar uno como sustituto del otro. TLS no protege un volcado de base de datos. El cifrado de disco no detiene un ataque man-in-the-middle.

Cómo TLS 1.3 protege los datos en tránsito

TLS 1.3, estandarizado en RFC 8446 (2018), es el estándar moderno. Usa:

• Secreto hacia adelante por defecto mediante intercambio de claves ECDHE efímero. Aunque la clave a largo plazo del servidor se filtre, las sesiones pasadas siguen protegidas.
• Solo cifrados AEAD — AES-128-GCM, AES-256-GCM o ChaCha20-Poly1305. Los modos CBC antiguos y RC4 han desaparecido.
• Handshake de un solo viaje de ida y vuelta (1-RTT), o cero viajes (0-RTT) para reanudación.
• Handshake cifrado para que los observadores pasivos no puedan ver la cadena de certificados.

Todos los servicios de transferencia de archivos de confianza —WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer— ejecutan TLS 1.3 con cabeceras HSTS que aplican HTTPS durante al menos 12 meses. Puedes verificarlo con la herramienta testssl de SSL Labs; cualquier puntuación por debajo de A- indica problemas de configuración.

Cómo funciona el cifrado en reposo en el servidor

Una vez que los archivos llegan y TLS termina, el cifrado en reposo toma el relevo. Hay varias capas:

• A nivel de bloque (disco completo): AES-256-XTS en LUKS (Linux), BitLocker (Windows), FileVault (macOS), o equivalentes del proveedor cloud como el cifrado AWS EBS. Protege contra discos robados.
• A nivel de sistema de archivos: eCryptfs, Fscrypt en ext4/F2FS. Los archivos de cada usuario cifrados con claves separadas.
• A nivel de almacenamiento de objetos: AWS S3 SSE-KMS, Azure Blob con Storage Service Encryption, Google Cloud Storage con claves gestionadas por el cliente. Cada objeto cifrado con AES-256-GCM.
• A nivel de aplicación: el servicio cifra cada archivo en su propio código antes de escribirlo en el almacenamiento, con claves almacenadas en un KMS o HSM.

El nivel de aplicación es el más robusto porque el cifrado ocurre antes de que cualquier sistema de almacenamiento vea los datos. AWS KMS cobra 1 €/clave/mes más 0,03 € por 10.000 solicitudes, suficientemente barato para que los servicios serios lo usen por archivo.

La trampa de «claves junto al texto cifrado»

Aquí es donde el cifrado en reposo falla habitualmente. Si las claves se almacenan en el mismo servidor que el texto cifrado, un atacante que viole el servidor obtiene ambos. El proveedor puede técnicamente marcar la casilla de «cifrado en reposo» para cumplimiento normativo sin ofrecer ninguna protección real contra el compromiso del servidor.

Las buenas arquitecturas separan las responsabilidades:

• Texto cifrado en S3 u almacenamiento de objetos similar.
• Claves de cifrado en AWS KMS, Google Cloud KMS, Azure Key Vault o un HSM dedicado.
• Acceso a las claves controlado por credenciales IAM de corta duración y logs de auditoría.

Las grandes arquitecturas van más lejos: las claves nunca existen en el servidor. El cifrado del lado del cliente (E2EE) significa que el navegador del usuario genera la clave, cifra el archivo y guarda la clave. El servidor almacena texto cifrado y no tiene nada que filtrar.

Dónde aparecen las brechas de cifrado

Incluso con ambos controles implementados, los datos están brevemente en texto plano en varios lugares:

• En la memoria del servidor durante el procesamiento de subidas, el análisis antivirus o la generación de miniaturas. Un volcado de memoria durante esta ventana revela texto plano.
• En los logs de acceso si se registran nombres de archivo o fragmentos de contenido para depuración.
• En cintas de copia de seguridad si las copias de seguridad no heredan el mismo cifrado.
• Durante la compresión o transcodificación donde el servicio procesa el contenido del archivo.
• En la caché del navegador después de la descarga si el usuario no la borra.

Estas brechas son por qué importa el cifrado de conocimiento cero (del lado del cliente). Cuando los archivos se cifran en el navegador antes de subirlos, las brechas del lado del servidor se vuelven irrelevantes: el servidor solo ve texto cifrado.

Lo que hacen realmente los grandes servicios

Una clasificación aproximada basada en documentación pública:

• Google Drive, Dropbox, OneDrive: TLS 1.3 en tránsito, AES-256 en reposo con claves en poder del proveedor. No son de conocimiento cero: el proveedor puede leer tus archivos.
• WeTransfer (nivel gratuito): TLS 1.3, AES-256 en reposo en AWS S3. El proveedor tiene las claves.
• Box Enterprise: TLS 1.3, AES-256-GCM en reposo, claves opcionales gestionadas por el cliente (Box KeySafe).
• Tresorit, Proton Drive, SwissTransfer nivel E2EE, HexaTransfer: TLS 1.3 en tránsito, AES-256-GCM en reposo, pero las claves por archivo son generadas por el cliente y nunca llegan al servidor. Efectivamente de conocimiento cero.

Para datos sensibles, solo la última categoría proporciona protección significativa contra amenazas internas y demandas legales válidas.

Cumplimiento normativo y el mandato de «defensa en profundidad»

Los reguladores exigen explícitamente ambos:

• RGPD Artículo 32 exige «seudonimización y cifrado de datos personales» sin restricción sobre el estado en el que se encuentran los datos.
• HIPAA Security Rule 45 CFR § 164.312(a)(2)(iv) y (e)(2)(ii) requiere cifrado para ePHI tanto en tránsito como en reposo.
• PCI DSS 4.0 Requisitos 3 y 4 separa «proteger los datos del titular de la tarjeta almacenados» (en reposo) de «proteger los datos con criptografía fuerte durante la transmisión» (en tránsito).
• FIPS 140-3 la validación se aplica a los módulos criptográficos usados en ambos contextos.
• LOPD-GDD complementa al RGPD en España y exige las mismas garantías técnicas de cifrado.

Proporcionar solo uno es un incumplimiento normativo antes de convertirse en un fallo de seguridad.

Cómo verificar que ambos están activos

Cinco comprobaciones rápidas para cualquier servicio de transferencia de archivos:

1. Ejecuta testssl.sh https://proveedor.com para confirmar TLS 1.3 con solo cifrados robustos.
2. Comprueba las cabeceras HSTS con max-age de al menos 31.536.000 (un año).
3. Lee el whitepaper de seguridad para menciones explícitas de AES-256-GCM o AES-256-XTS en reposo.
4. Confirma que las claves se almacenan en un KMS o HSM, no en la base de datos de la aplicación.
5. Busca la certificación SOC 2 Tipo II o ISO 27001: ambas requieren controles documentados en reposo y en tránsito.

Extra: comprueba si el cifrado del lado del cliente está disponible como opción. Si es así, actívalo para todo lo sensible.

Cómo combinarlos correctamente

El patrón que realmente funciona:

1. El navegador cifra el archivo con una clave AES-256-GCM aleatoria (lado del cliente).
2. El texto cifrado viaja sobre TLS 1.3 al servidor (en tránsito).
3. El servidor almacena el texto cifrado en almacenamiento cifrado AES-256 (en reposo).
4. La clave de descifrado solo existe en el fragmento de URL del enlace, nunca se envía al servidor.

Tres capas independientes. Si una falla, las otras aguantan. Este es el diseño que usa HexaTransfer, junto con Tresorit Send, los enlaces compartidos de Proton Drive y el modo E2EE de SwissTransfer.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.