En criptografía , el secreto directo ( FS ), también conocido como secreto directo perfecto ( PFS ), es una característica de los protocolos de acuerdo de claves específicos que garantiza que las claves de sesión no se verán comprometidas incluso si se comprometen los secretos a largo plazo utilizados en el intercambio de claves de sesión, lo que limita el daño. Para HTTPS , el secreto a largo plazo suele ser la clave privada del servidor. El secreto directo protege las sesiones pasadas contra futuros compromisos de claves o contraseñas. Al generar una clave de sesión única para cada sesión que inicia un usuario, el compromiso de una sola clave de sesión no afectará a ningún otro dato que no sea el intercambiado en la sesión específica protegida por esa clave en particular. Esto por sí solo no es suficiente para el secreto directo, que además requiere que un compromiso secreto a largo plazo no afecte la seguridad de las claves de sesión pasadas.
El secreto de reenvío protege los datos en la capa de transporte de una red que utiliza protocolos de seguridad de capa de transporte comunes, incluido OpenSSL , [1] cuando sus claves secretas de largo plazo se ven comprometidas, como en el caso del error de seguridad Heartbleed . Si se utiliza el secreto de reenvío, las comunicaciones cifradas y las sesiones registradas en el pasado no se pueden recuperar ni descifrar si las claves secretas de largo plazo o las contraseñas se ven comprometidas en el futuro, incluso si el adversario interfirió activamente, por ejemplo, a través de un ataque de intermediario (MITM) .
El valor del secreto de reenvío es que protege las comunicaciones pasadas. Esto reduce la motivación de los atacantes para comprometer las claves. Por ejemplo, si un atacante descubre una clave a largo plazo, pero se detecta el compromiso y se revoca y actualiza la clave a largo plazo, se filtra relativamente poca información en un sistema seguro de reenvío.
El valor del secreto hacia adelante depende de las capacidades asumidas de un adversario. El secreto hacia adelante tiene valor si se supone que un adversario puede obtener claves secretas de un dispositivo (acceso de lectura) pero se detecta o no puede modificar la forma en que se generan las claves de sesión en el dispositivo (compromiso total). En algunos casos, un adversario que puede leer claves a largo plazo de un dispositivo también puede modificar el funcionamiento del generador de claves de sesión, como en el generador de bits aleatorios determinista de curva elíptica dual con puerta trasera . Si un adversario puede hacer que el generador de números aleatorios sea predecible, entonces el tráfico pasado estará protegido, pero todo el tráfico futuro se verá comprometido.
El valor del secreto de reenvío está limitado no sólo por la suposición de que un adversario atacará un servidor robando claves y no modificando el generador de números aleatorios que utiliza el servidor, sino también por la suposición de que el adversario sólo recopilará tráfico de forma pasiva en el enlace de comunicaciones y no estará activo utilizando un ataque de intermediario. El secreto de reenvío normalmente utiliza un intercambio de claves Diffie-Hellman efímero para evitar la lectura del tráfico pasado. El servidor suele firmar el intercambio de claves Diffie-Hellman efímero utilizando una clave de firma estática. Si un adversario puede robar (u obtener mediante una orden judicial) esta clave de firma estática (a largo plazo), puede hacerse pasar por el servidor ante el cliente y por el cliente ante el servidor e implementar un ataque clásico de intermediario. [2]
El término "secreto directo perfecto" fue acuñado por CG Günther en 1990 [3] y analizado más a fondo por Whitfield Diffie , Paul van Oorschot y Michael James Wiener en 1992 [4] , donde se utilizó para describir una propiedad del protocolo de estación a estación. [5]
El secreto hacia adelante también se ha utilizado para describir la propiedad análoga de los protocolos de acuerdo de clave autenticados por contraseña donde el secreto a largo plazo es una contraseña (compartida) . [6]
En 2000, el IEEE ratificó por primera vez el IEEE 1363 , que establece las propiedades relacionadas de confidencialidad de avance de una y dos partes de varios esquemas de acuerdo de clave estándar. [7]
Un sistema de cifrado tiene la propiedad de secreto hacia adelante si la inspección de texto simple (descifrado) del intercambio de datos que ocurre durante la fase de acuerdo de clave del inicio de la sesión no revela la clave que se utilizó para cifrar el resto de la sesión.
El siguiente es un ejemplo hipotético de un protocolo de mensajería instantánea simple que emplea secreto de reenvío:
El secreto de reenvío (que se logra generando nuevas claves de sesión para cada mensaje) garantiza que las comunicaciones pasadas no se puedan descifrar si una de las claves generadas en una iteración del paso 2 se ve comprometida, ya que dicha clave solo se utiliza para cifrar un único mensaje. El secreto de reenvío también garantiza que las comunicaciones pasadas no se puedan descifrar si se ven comprometidas las claves privadas de largo plazo del paso 1. Sin embargo, en el futuro sería posible hacerse pasar por Alice o Bob si esto ocurriera, lo que posiblemente comprometería todos los mensajes futuros.
El secreto hacia adelante está diseñado para evitar que la vulneración de una clave secreta de largo plazo afecte la confidencialidad de conversaciones pasadas. Sin embargo, el secreto hacia adelante no puede defenderse contra un criptoanálisis exitoso de los cifrados subyacentes que se están utilizando, ya que un criptoanálisis consiste en encontrar una forma de descifrar un mensaje cifrado sin la clave, y el secreto hacia adelante solo protege las claves, no los cifrados en sí. [8] Un atacante paciente puede capturar una conversación cuya confidencialidad está protegida mediante el uso de criptografía de clave pública y esperar hasta que se rompa el cifrado subyacente (por ejemplo, se podrían crear grandes computadoras cuánticas que permitan calcular rápidamente el problema del logaritmo discreto ). Esto permitiría la recuperación de textos simples antiguos incluso en un sistema que emplee el secreto hacia adelante.
Los protocolos de intercambio de claves seguras y no interactivas enfrentan amenazas adicionales que no son relevantes para los protocolos interactivos. En un ataque de supresión de mensajes , un atacante que controla la red puede almacenar mensajes y evitar que lleguen al destinatario previsto; como los mensajes nunca se reciben, las claves privadas correspondientes pueden no destruirse ni perforarse, por lo que una vulneración de la clave privada puede llevar a un descifrado exitoso. La retirada proactiva de claves privadas según un cronograma mitiga, pero no elimina, este ataque. En un ataque malicioso de agotamiento de claves , el atacante envía muchos mensajes al destinatario y agota el material de claves privadas, lo que obliga a un protocolo a elegir entre fallar en el cierre (y permitir ataques de denegación de servicio ) o fallar en la apertura (y renunciar a cierta cantidad de confidencialidad hacia adelante). [9]
La mayoría de los protocolos de intercambio de claves son interactivos y requieren una comunicación bidireccional entre las partes. Un protocolo que permite al remitente transmitir datos sin necesidad de recibir primero ninguna respuesta del destinatario puede denominarse no interactivo , asincrónico o de viaje de ida y vuelta cero (0-RTT). [10] [11]
La interactividad es onerosa para algunas aplicaciones; por ejemplo, en un sistema de mensajería seguro, puede ser deseable tener una implementación de almacenamiento y reenvío , en lugar de requerir que el remitente y el destinatario estén en línea al mismo tiempo; flexibilizar el requisito de bidireccionalidad también puede mejorar el rendimiento incluso cuando no es un requisito estricto, por ejemplo, en el establecimiento o la reanudación de la conexión. Estos casos de uso han estimulado el interés en el intercambio de claves no interactivo y, como la seguridad de reenvío es una propiedad deseable en un protocolo de intercambio de claves, en el secreto de reenvío no interactivo. [12] [13] Esta combinación ha sido identificada como deseable desde al menos 1996. [14] Sin embargo, combinar el secreto de reenvío y la no interactividad ha demostrado ser un desafío; [15] se había sospechado que el secreto de reenvío con protección contra ataques de repetición era imposible de manera no interactiva, pero se ha demostrado que es posible lograr los tres objetivos. [11]
En términos generales, se han explorado dos enfoques para el secreto hacia adelante no interactivo: claves precalculadas y cifrado perforable . [13]
Con claves precalculadas, se crean muchos pares de claves y se comparten las claves públicas, mientras que las claves privadas se destruyen después de recibir un mensaje utilizando la clave pública correspondiente. Este enfoque se ha implementado como parte del protocolo Signal . [16]
En el cifrado perforable, el receptor modifica su clave privada después de recibir un mensaje de tal manera que la nueva clave privada no puede leer el mensaje pero la clave pública no cambia. Ross J. Anderson describió informalmente un esquema de cifrado perforable para el intercambio seguro de claves hacia adelante en 1997, [17] y Green y Miers (2015) describieron formalmente dicho sistema, [18] basándose en el esquema relacionado de Canetti, Halevi y Katz (2003), que modifica la clave privada de acuerdo con un cronograma para que los mensajes enviados en períodos anteriores no puedan leerse con la clave privada de un período posterior. [15] Green y Miers (2015) hacen uso del cifrado jerárquico basado en identidad y el cifrado basado en atributos , mientras que Günther et al. (2017) utilizan una construcción diferente que puede basarse en cualquier esquema jerárquico basado en identidad. [19] Dallmeier et al. (2020) encontraron experimentalmente que modificar QUIC para usar un intercambio de claves seguro y resistente a la reproducción de 0-RTT implementado con cifrado perforable implicaba un uso de recursos significativamente mayor, pero no tanto como para hacer que su uso práctico fuera inviable. [20]
El secreto perfecto hacia adelante débil (Wpfs) es la propiedad más débil por la cual, cuando las claves a largo plazo de los agentes se ven comprometidas, se garantiza el secreto de las claves de sesión previamente establecidas, pero solo para las sesiones en las que el adversario no interfirió activamente. Esta nueva noción, y la distinción entre esta y el secreto hacia adelante, fue introducida por Hugo Krawczyk en 2005. [21] [22] Esta definición más débil requiere implícitamente que el secreto hacia adelante completo (perfecto) mantenga el secreto de las claves de sesión previamente establecidas incluso en sesiones en las que el adversario interfirió activamente o intentó actuar como intermediario.
El secreto de reenvío está presente en varias implementaciones de protocolos importantes, como SSH y como una característica opcional en IPsec (RFC 2412). Off-the-Record Messaging , un protocolo de criptografía y biblioteca para muchos clientes de mensajería instantánea, así como OMEMO , que proporciona características adicionales como la funcionalidad multiusuario en dichos clientes, ambos proporcionan secreto de reenvío y cifrado denegable .
En Transport Layer Security (TLS), están disponibles conjuntos de cifrados basados en el intercambio de claves Diffie–Hellman (DHE- RSA , DHE- DSA ) y el intercambio de claves Diffie–Hellman de curva elíptica (ECDHE- RSA , ECDHE- ECDSA ). En teoría, TLS podía elegir cifrados apropiados desde SSLv3, pero en la práctica diaria muchas implementaciones se negaban a ofrecer secreto hacia adelante o solo lo proporcionaban con un grado de cifrado muy bajo. [23] Este ya no es el caso con TLS 1.3, que garantiza el secreto hacia adelante dejando el efímero Diffie–Hellman (variantes de campo finito y curva elíptica) como el único mecanismo de intercambio de claves restante. [24]
OpenSSL admite el secreto hacia adelante mediante el uso de la curva elíptica Diffie-Hellman desde la versión 1.0, [25] con una sobrecarga computacional de aproximadamente el 15 % para el protocolo de enlace inicial. [26]
El Protocolo de Señal utiliza el Algoritmo de Doble Ratchet para proporcionar secreto hacia adelante. [27]
Por otro lado, entre los protocolos populares actualmente en uso, WPA Personal no admitía secreto hacia adelante antes de WPA3. [28]
Varios proveedores de información de Internet de gran tamaño consideran que el secreto hacia adelante es una característica de seguridad importante. Desde finales de 2011, Google proporcionó secreto hacia adelante con TLS de forma predeterminada a los usuarios de su servicio Gmail , su servicio Google Docs y sus servicios de búsqueda encriptados. [25] Desde noviembre de 2013, Twitter proporcionó secreto hacia adelante con TLS a sus usuarios. [29] Todos los wikis alojados por la Fundación Wikimedia han proporcionado secreto hacia adelante a los usuarios desde julio de 2014 [30] y exigen el uso de secreto hacia adelante desde agosto de 2018.
Facebook informó, como parte de una investigación sobre el cifrado de correo electrónico, que, a mayo de 2014, el 74 % de los servidores que admiten STARTTLS también ofrecen confidencialidad hacia adelante. [31] TLS 1.3, publicado en agosto de 2018, eliminó la compatibilidad con cifrados sin confidencialidad hacia adelante. A febrero de 2019 [update], el 96,6 % de los servidores web encuestados admiten alguna forma de confidencialidad hacia adelante y el 52,1 % utilizará confidencialidad hacia adelante con la mayoría de los navegadores. [32]
En la WWDC 2016, Apple anunció que todas las aplicaciones iOS tendrían que usar App Transport Security (ATS), una función que obliga a utilizar la transmisión HTTPS. En concreto, ATS requiere el uso de un código de cifrado que proporciona confidencialidad hacia adelante. [33] ATS pasó a ser obligatorio para las aplicaciones el 1 de enero de 2017. [34]
La aplicación de mensajería Signal emplea secreto hacia adelante en su protocolo, lo que la diferencia notablemente de los protocolos de mensajería basados en PGP . [35]
El secreto hacia adelante es compatible con el 92,6 % de los sitios web en navegadores modernos, mientras que el 0,3 % de los sitios web no lo admiten en absoluto a mayo de 2024. [36]