Cifrado de extremo a extremo (E2EE)

¿Qué es el cifrado de extremo a extremo (E2EE)?

El cifrado de extremo a extremo (E2EE) significa que los datos se cifran en el dispositivo del emisor y solo se descifran en el del receptor. El servicio intermedio, por ejemplo un servidor de mensajería, solo maneja texto cifrado porque nunca tiene las claves. La Electronic Frontier Foundation lo describe como un mensaje que su remitente original convierte en secreto y que solo su destinatario final descifra.

Cómo funciona E2EE

• El dispositivo de cada usuario genera un par de claves. La clave pública se comparte a través del servicio y la privada nunca sale del dispositivo.
• El emisor cifra con claves derivadas del material de clave pública del receptor y envía el texto cifrado por el servidor.
• El servidor guarda y reenvía el texto cifrado sin poder leerlo.
• El dispositivo del receptor lo descifra con su clave privada.

Los mensajeros modernos añaden un esquema de renovación de claves. El algoritmo Double Ratchet de Signal da a cada mensaje su propia clave, de modo que una filtración posterior no expone los mensajes anteriores (forward secrecy), y los nuevos intercambios Diffie-Hellman permiten que la conversación se recupere tras un compromiso breve. El Double Ratchet necesita un protocolo aparte, como PQXDH, para acordar el primer secreto compartido. Para grupos, el IETF estandarizó Messaging Layer Security en el RFC 9420, que admite grupos de dos a miles de miembros y ofrece forward secrecy y seguridad tras compromiso.

E2EE frente al cifrado en tránsito y en reposo

TLS, el protocolo de HTTPS, protege los datos entre cliente y servidor de modo que solo esos dos extremos puedan leerlos (RFC 8446). Es cifrado en tránsito, pero el servidor ve el texto en claro. El cifrado en reposo protege los datos almacenados, aunque normalmente las claves las tiene el servicio. En E2EE el servicio nunca tiene las claves, así que ni su propio personal ni un atacante que entre en sus servidores puede leer el contenido de los mensajes. Si un servidor puede descifrar una parte importante de los mensajes, el sistema no es de extremo a extremo. La mayoría de los productos E2EE usan además TLS, porque cubren amenazas distintas.

Ejemplo

Envías una foto en una app de mensajería. Tu móvil la cifra, la app sube el archivo cifrado y el servidor se lo entrega a tu amigo. Su móvil la descifra y la muestra. El servidor vio un bloque de bytes, su tamaño y la hora de llegada.

Contra qué no protege E2EE

• Un dispositivo comprometido. El malware en el móvil del emisor o del receptor ve el mensaje después de descifrarlo.
• Los metadatos. Quién habla con quién y cuándo suele seguir siendo visible para el servicio, igual que un sobre muestra remitente, destinatario y destino aunque la carta esté sellada (una analogía de la guía de la EFF sobre metadatos).
• Las copias de seguridad. Si un chat se respalda sin cifrar o con una clave que tiene el proveedor, la protección termina ahí.
• Las personas. Un destinatario puede copiar o capturar lo que envías, y se puede engañar a un usuario para que confíe en una clave falsa.

Tampoco sustituye al resto del trabajo de seguridad. Las cuentas, las sesiones y la confianza en los dispositivos siguen necesitando gestión de identidades y accesos (IAM), las APIs que transportan el texto cifrado necesitan seguridad de APIs y los metadatos almacenados necesitan seguridad de bases de datos. Consulta también las amenazas de ciberseguridad habituales que E2EE no detiene.

Errores comunes

• Llamar cifrado de extremo a extremo a HTTPS. HTTPS termina en el servidor.
• Dejar que el servidor vea las claves. Un depósito de claves o una copia de "recuperación" en el servidor puede convertir E2EE en cifrado corriente sin que se note.
• Omitir la verificación de claves. Sin forma de comprobar números de seguridad o huellas, un servidor podría sustituir una clave y situarse en medio.
• Escribir tu propia criptografía. Usa un protocolo y una biblioteca revisados.

E2EE, pruebas de carga y monitorización

LoadFocus no ofrece productos de cifrado, y una prueba de carga no puede leer contenido E2EE, que es justo la idea. Lo que sí puede probar es el backend que lo transporta. El servidor sigue teniendo que aceptar subidas de texto cifrado, entregar claves públicas, guardar mensajes y entregarlos rápido a muchos dispositivos a la vez. Usa pruebas de carga con cuentas de prueba sintéticas y cargas opacas de tamaño realista para ver cómo se comportan esos endpoints al crecer los usuarios virtuales, y la monitorización de APIs para comprobarlos de forma programada. No uses nunca datos reales de usuarios. Para más contexto, lee el artículo (en inglés) Cloud testing security best practices.

Preguntas frecuentes sobre el cifrado de extremo a extremo

¿El cifrado de extremo a extremo es lo mismo que HTTPS?

No. HTTPS (TLS) protege la conexión entre tu dispositivo y un servidor, pero el servidor puede leer los datos. El cifrado de extremo a extremo mantiene los datos ilegibles también para el servidor.

¿Puede la empresa que ofrece el servicio leer mis mensajes E2EE?

El contenido no, si el sistema es realmente de extremo a extremo, porque la empresa no tiene las claves de descifrado. Sí puede ver metadatos, como quién contactó con quién y cuándo.

¿Qué es el forward secrecy?

Que una clave filtrada más tarde no puede descifrar mensajes pasados. El Double Ratchet de Signal da a cada mensaje su propia clave para lograrlo.

¿Funciona E2EE en chats de grupo?

Sí. Messaging Layer Security (RFC 9420) es un estándar del IETF para el acuerdo de claves en grupos y admite grupos de dos a miles de miembros.

¿El cifrado de extremo a extremo hace inmune a una app frente a ataques?

No. Protege el contenido de los mensajes en tránsito y en el servidor, pero no frente a un dispositivo comprometido, copias de seguridad sin cifrar o cuentas poco seguras.