Secreto hacia adelante

En criptografía , el secreto hacia adelante ( FS ), también conocido como secreto perfecto hacia adelante ( PFS ), es una característica de protocolos específicos de acuerdo de claves que garantiza que las claves de sesión no se verán comprometidas incluso si se ven comprometidos los secretos a largo plazo utilizados en el intercambio de claves de sesión, lo que limita el daño. ^{[ 1 ] [ 2 ] [ 3 ]} Para TLS , el secreto a largo plazo suele ser la clave privada del servidor. El secreto hacia adelante protege las sesiones pasadas contra futuras vulneraciones de claves o contraseñas. Al generar una clave de sesión única para cada sesión que inicia un usuario, la vulneración de una sola clave de sesión no afectará ningún 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 hacia adelante, que además requiere que una vulneración del secreto a largo plazo no afecte la seguridad de las claves de sesión pasadas.

El secreto hacia adelante protege los datos en la capa de transporte de una red que utiliza protocolos de seguridad de capa de transporte comunes, incluido OpenSSL , ^{[ 4 ]} cuando sus claves secretas a largo plazo se ven comprometidas, como con el fallo de seguridad Heartbleed . Si se utiliza el secreto hacia adelante, las comunicaciones y sesiones cifradas registradas en el pasado no se pueden recuperar ni descifrar si las claves secretas o contraseñas a largo plazo se ven comprometidas en el futuro, incluso si el adversario interfirió activamente, por ejemplo, mediante un ataque de intermediario (MITM) .

La ventaja del secreto hacia adelante radica en 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 de larga duración, pero se detecta la vulneración y se revoca y actualiza la clave, en un sistema con seguridad hacia adelante se filtra relativamente poca información.

El valor del secreto hacia adelante depende de las capacidades que se le atribuyan al adversario. El secreto hacia adelante es valioso si se supone que un adversario puede obtener claves secretas de un dispositivo (acceso de lectura), pero es detectado 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 doble curva elíptica con puerta trasera . Si un adversario puede hacer que el generador de números aleatorios sea predecible, el tráfico pasado estará protegido, pero todo el tráfico futuro estará comprometido.

El valor del secreto hacia adelante está limitado no solo por la suposición de que un adversario atacará un servidor robando únicamente las claves y no modificando el generador de números aleatorios que utiliza, sino también por la suposición de que el adversario solo recopilará pasivamente el tráfico en el enlace de comunicaciones y no realizará un ataque de intermediario (man-in-the-middle). El secreto hacia adelante generalmente utiliza un intercambio de claves Diffie-Hellman efímero para evitar la lectura del tráfico anterior. Este intercambio de claves Diffie-Hellman efímero suele estar firmado por el servidor mediante una clave de firma estática. Si un adversario logra 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 viceversa, e implementar un ataque clásico de intermediario. ^{[ 5 ]}

El término "secreto perfecto hacia adelante" fue acuñado por CG Günther en 1990 ^{[ 6 ]} y discutido posteriormente por Whitfield Diffie , Paul van Oorschot y Michael James Wiener en 1992, ^{[ 7 ]} donde se utilizó para describir una propiedad del protocolo Estación a Estación. ^{[ 8 ]}

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) . ^{[ 9 ]}

En 2000, el IEEE ratificó por primera vez el IEEE 1363 , que establece las propiedades relacionadas de secreto directo de una y dos partes de varios esquemas de acuerdo de clave estándar. ^{[ 10 ]}

Un sistema de cifrado posee la propiedad de confidencialidad directa si la inspección en texto plano (descifrado) del intercambio de datos que se produce durante la fase de acuerdo de claves al 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 confidencialidad directa:

1. Alice y Bob generan cada uno un par de claves públicas y privadas asimétricas de larga duración , y luego verifican las huellas digitales de las claves públicas en persona o a través de un canal previamente autenticado. La verificación confirma con certeza que el propietario declarado de una clave pública es realmente su dueño.
2. Alice y Bob utilizan un algoritmo de intercambio de claves, como Diffie-Hellman , para acordar de forma segura una clave de sesión efímera . Utilizan las claves del paso 1 únicamente para autenticarse mutuamente durante este proceso.
3. Alice le envía un mensaje a Bob, encriptando el mensaje con un cifrado simétrico utilizando la clave de sesión negociada en el paso 2.
4. Bob descifra el mensaje de Alice utilizando la clave negociada en el paso 2.
5. El proceso se repite con cada nuevo mensaje enviado, comenzando desde el paso 2 (y alternando los roles de Alice y Bob como remitente/receptor según corresponda). El paso 1 nunca se repite.

El secreto hacia adelante (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 hacia adelante también garantiza que las comunicaciones pasadas no se puedan descifrar si las claves privadas a largo plazo del paso 1 se ven comprometidas. Sin embargo, suplantar la identidad de Alice o Bob sería posible en el futuro si esto ocurriera, lo que podría comprometer todos los mensajes posteriores.

El secreto hacia adelante está diseñado para evitar que la vulneración de una clave secreta a largo plazo afecte la confidencialidad de conversaciones pasadas. Sin embargo, el secreto hacia adelante no puede proteger contra un criptoanálisis exitoso de los cifrados subyacentes utilizados, 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í. ^{[ 11 ]} 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 ), es decir, ataques de recolección ahora, descifrado después . Esto permitiría la recuperación de textos planos antiguos incluso en un sistema que emplea secreto hacia adelante.

Los protocolos de intercambio de claves no interactivos con seguridad hacia adelante se enfrentan a 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 los mensajes impidiendo que lleguen al destinatario; como los mensajes nunca se reciben, las claves privadas correspondientes pueden no destruirse ni vulnerarse, por lo que una vulneración de la clave privada puede conducir 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 la clave privada, lo que obliga a un protocolo a elegir entre fallar cerrado (y permitir ataques de denegación de servicio ) o fallar abierto (y renunciar a cierta cantidad de confidencialidad hacia adelante). ^{[ 12 ]}

La mayoría de los protocolos de intercambio de claves son interactivos , lo que requiere comunicación bidireccional entre las partes. Un protocolo que permite al remitente transmitir datos sin necesidad de recibir primero ninguna respuesta del receptor puede denominarse no interactivo , asíncrono o de tiempo de ida y vuelta cero (0-RTT). ^{[ 13 ] [ 14 ]}

La interactividad es onerosa para algunas aplicaciones ; por ejemplo, en un sistema de mensajería segura, 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 reanudación de la conexión. Estos casos de uso han estimulado el interés en el intercambio de claves no interactivo y, dado que la seguridad hacia adelante es una propiedad deseable en un protocolo de intercambio de claves, en el secreto hacia adelante no interactivo. ^{[ 15 ] [ 16 ]} Esta combinación se ha identificado como deseable desde al menos 1996. ^{[ 17 ]} Sin embargo, combinar el secreto hacia adelante y la no interactividad ha resultado desafiante; ^{[ 18 ]} se sospechaba que el secreto hacia adelante con protección contra ataques de repetición era imposible de forma no interactiva, pero se ha demostrado que es posible lograr los tres requisitos. ^{[ 14 ]}

En términos generales, se han explorado dos enfoques para el secreto directo no interactivo: claves precalculadas y cifrado perforable . ^{[ 16 ]}

Con claves precalculadas, se crean muchos pares de claves y se comparten las claves públicas, destruyéndose las claves privadas una vez recibido un mensaje con la clave pública correspondiente. Este enfoque se ha implementado como parte del protocolo Signal . ^{[ 19 ]}

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 permanece sin cambios. Ross J. Anderson describió informalmente un esquema de cifrado perforable para el intercambio seguro de claves hacia adelante en 1997, ^{[ 20 ]} y Green y Miers (2015) describieron formalmente dicho sistema, ^{[ 21 ]} basándose en el esquema relacionado de Canetti, Halevi y Katz (2003) , que modifica la clave privada según un cronograma de modo que los mensajes enviados en períodos anteriores no se pueden leer con la clave privada de un período posterior. ^{[ 18 ]} Green y Miers (2015) utilizan cifrado jerárquico basado en identidad y 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. ^{[ 22 ]} Dallmeier et al. (2020) encontraron experimentalmente que modificar QUIC para usar un intercambio de claves seguro hacia adelante y resistente a la repetición con 0-RTT implementado con cifrado perforable generó un aumento significativo en el uso de recursos, pero no tanto como para hacer inviable su uso práctico. ^{[ 23 ]}

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. ^{[ 24 ] [ 25 ]} Esta definición más débil requiere implícitamente que el secreto perfecto hacia adelante 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 directo está presente en varias implementaciones de protocolos, como SSH e IPsec (RFC 2412), aunque es opcional en este último. Off-the-Record Messaging , un protocolo y biblioteca de criptografía para muchos clientes de mensajería instantánea, así como OMEMO, que proporciona funciones adicionales como la funcionalidad multiusuario en dichos clientes, ofrecen tanto secreto directo como cifrado negable .

En Transport Layer Security (TLS), están disponibles conjuntos de cifrado 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 puede usar el secreto hacia adelante desde SSLv3, pero muchas implementaciones no ofrecen el secreto hacia adelante o lo proporcionan con un cifrado de menor nivel. ^{[ 26 ]} TLS 1.3 eliminó la compatibilidad con RSA para el intercambio de claves, dejando a Diffie-Hellman (con secreto hacia adelante) como el único algoritmo para el intercambio de claves. ^{[ 27 ]}

OpenSSL admite el secreto hacia adelante mediante Diffie-Hellman de curva elíptica desde la versión 1.0, ^{[ 28 ]} con una sobrecarga computacional de aproximadamente el 15 % para el handshake inicial. ^{[ 29 ]}

El Protocolo Signal utiliza el algoritmo Double Ratchet para proporcionar confidencialidad directa. ^{[ 30 ]}

Por otro lado, entre los protocolos populares que se utilizan actualmente, WPA Personal no admitía el secreto hacia adelante antes de WPA3. ^{[ 31 ]}

Desde finales de 2011, Google proporcionó confidencialidad directa con TLS de forma predeterminada a los usuarios de su servicio Gmail , Google Docs y servicios de búsqueda encriptados. ^{[ 28 ]} Desde noviembre de 2013, Twitter proporcionó confidencialidad directa con TLS a sus usuarios. ^{[ 32 ]} Las wikis alojadas por la Fundación Wikimedia han proporcionado confidencialidad directa a los usuarios desde julio de 2014, ^{[ 33 ]} y han requerido el uso de confidencialidad directa 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 hosts que admiten STARTTLS también proporcionan confidencialidad directa. ^{[ 34 ]} TLS 1.3, publicado en agosto de 2018, dejó de admitir cifrados sin confidencialidad directa. A febrero de 2019 El 96,6% de los servidores web encuestados admiten alguna forma de confidencialidad directa, y el 52,1% utilizará la confidencialidad directa con la mayoría de los navegadores. ^{[ 35 ]}

En la WWDC 2016, Apple anunció que todas las aplicaciones de iOS tendrían que usar App Transport Security (ATS), una función que impone el uso de la transmisión HTTPS. Específicamente, ATS requiere el uso de un algoritmo de cifrado que proporciona confidencialidad directa. ^{[ 36 ]} ATS se volvió obligatorio para las aplicaciones el 1 de enero de 2017. ^{[ 37 ]}

La aplicación de mensajería Signal emplea confidencialidad directa en su protocolo, diferenciándola notablemente de los protocolos de mensajería basados ​​en PGP . ^{[ 38 ]}

En una encuesta realizada en junio de 2025, el secreto hacia adelante era compatible con aproximadamente el 95% de los sitios web populares cuando se accedía a ellos con navegadores modernos, mientras que el 0,2% no lo era en absoluto. ^{[ 39 ]}

• Anonimato hacia adelante
• Intercambio de claves Diffie-Hellman
• Curva elíptica Diffie-Hellman
• Cosecha ahora, descifra después.

• Anderson, Ross (2002). "Dos observaciones sobre criptología de clave pública" (PDF) .
• Canetti, Ran ; Halevi, Shai ; Katz, Jonathan (2003). «Un esquema de cifrado de clave pública con seguridad prospectiva». Avances en criptología — EUROCRYPT 2003. Notas de clase en ciencias de la computación. Vol.  2656. págs. 255–271 . doi : 10.1007/3-540-39200-9_16 . ISBN  978-3-540-14039-9.
• Green, Matthew D .; Miers, Ian (2015). «Mensajería asíncrona segura hacia adelante a partir de cifrado vulnerable». Simposio IEEE de 2015 sobre seguridad y privacidad . págs. 305–320 . doi : 10.1109/SP.2015.26 . ISBN  978-1-4673-6949-7. S2CID 9171925 . 
• Günther, Felix; Hale, Britta; Jager, Tibor; Lauer, Sebastian (2017). "Intercambio de claves 0-RTT con total confidencialidad directa" (PDF) .
• Back, Adam (6 de septiembre de 1996). "Secreto no interactivo hacia adelante" . Cypherpunks (Lista de correo).
• Boyd, Colin; Gellert, Kai (24 de agosto de 2020). "Una visión moderna sobre la seguridad prospectiva" . The Computer Journal . 64 (4) (publicado en abril de 2021): 639–652 . doi : 10.1093/comjnl/bxaa104 . hdl : 11250/2730309 . Recuperado el 8 de junio de 2021 .{{cite journal}}: CS1 maint: servicio de archivado obsoleto ( enlace )
• Dallmeier, Finlandia; Drees, enero P.; Gellert, Kai; Handrik, Tobías; Jáger, Tibor; Klauke, Jonás; Nachtigall, Simón; Renzelmann, Timo; Lobo, Rudi (2020). "Forward-Secure 0-RTT se activa: implementación y análisis de rendimiento en QUIC" (PDF) .

• RFC 2412 IETF, H. Orman. El protocolo de determinación de claves de Oakley. 
• El secreto perfecto hacia adelante puede impedir que la NSA acceda a páginas web seguras, pero nadie lo utiliza. Computerworld, 21 de junio de 2013.
• SSL: Interceptado hoy, descifrado mañana. Netcraft, 25 de junio de 2013.
• Implementación de Forward Secrecy SSL Labs, 25 de junio de 2013
• Pruebas de SSL Labs para navegadores web
• Pruebas de SSL Labs para servidores web