En criptografía , el secreto directo ( FS ), también conocido como secreto directo perfecto ( PFS ), es una característica de protocolos de acuerdo de claves específicos que garantiza que las claves de sesión no se verán comprometidas incluso si se utilizan secretos a largo plazo en el intercambio de claves de sesión. están comprometidos, 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 clave de sesión única 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 directo, que además requiere que un compromiso secreto a largo plazo no afecte la seguridad de las claves de sesiones anteriores.
El secreto directo protege los datos en la capa de transporte de una red que utiliza protocolos de seguridad de capa de transporte comunes, incluido OpenSSL , cuando sus claves secretas a largo plazo se ven comprometidas, como ocurre con el error de seguridad Heartbleed . Si se utiliza el secreto directo, las comunicaciones cifradas y las sesiones registradas en el pasado no se pueden recuperar ni descifrar en caso de que las claves o contraseñas secretas a largo plazo se vean comprometidas en el futuro, incluso si el adversario interfiriera activamente, por ejemplo a través de un hombre en el- ataque medio (MITM) .
El valor del secreto directo es que protege las comunicaciones pasadas. Esto reduce la motivación de los atacantes para comprometer las claves. Por ejemplo, si un atacante aprende una clave a largo plazo, pero se detecta el compromiso y la clave a largo plazo se revoca y actualiza, se filtra relativamente poca información en un sistema seguro hacia adelante.
El valor del secreto directo depende de las capacidades supuestas de un adversario. El secreto directo 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 desde 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 directo está limitado no sólo por la suposición de que un adversario atacará un servidor robando únicamente claves y sin modificar el generador de números aleatorios utilizado por el servidor, sino que también está limitado 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 suele utilizar un intercambio efímero de claves Diffie-Hellman para evitar leer el tráfico pasado. El intercambio de claves efímero Diffie-Hellman suele ser firmado por el servidor mediante 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), el adversario puede hacerse pasar por el servidor del cliente y como el cliente del servidor e implementar un intermediario clásico. ataque. [1]
El término "secreto directo perfecto" fue acuñado por CG Günther en 1990 [2] y discutido más a fondo por Whitfield Diffie , Paul van Oorschot y Michael James Wiener en 1992 [3] , donde se utilizó para describir una propiedad de la estación a -Protocolo de estación. [4]
El secreto directo también se ha utilizado para describir la propiedad análoga de los protocolos de acuerdo de claves autenticados por contraseña donde el secreto a largo plazo es una contraseña (compartida) . [5]
En 2000, el IEEE ratificó por primera vez el estándar IEEE 1363 , que establece las propiedades relacionadas de secreto directo unipartidista y bipartidista de varios esquemas de acuerdos clave estándar. [6]
Un sistema de cifrado tiene la propiedad de secreto directo si la inspección de texto plano (descifrado) del intercambio de datos que se produce 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 directo:
El secreto directo (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 directo también garantiza que las comunicaciones pasadas no puedan descifrarse si las claves privadas a largo plazo del paso 1 se ven comprometidas. Sin embargo, hacerse pasar por Alice o Bob sería posible en el futuro si esto ocurriera, posiblemente comprometiendo todos los mensajes futuros.
El secreto directo está diseñado para evitar que el compromiso de una clave secreta a largo plazo afecte la confidencialidad de conversaciones pasadas. Sin embargo, el secreto directo no puede defenderse de un criptoanálisis exitoso de los cifrados subyacentes que se utilizan, ya que un criptoanálisis consiste en encontrar una manera de descifrar un mensaje cifrado sin la clave, y el secreto directo sólo protege las claves, no los cifrados en sí. [7] 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 planos antiguos incluso en un sistema que emplea secreto directo.
Los protocolos de intercambio de claves seguros hacia adelante no interactivos 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 e impedir que lleguen al destinatario previsto; Como los mensajes nunca se reciben, las claves privadas correspondientes no pueden destruirse ni perforarse, por lo que comprometer 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 clave , el atacante envía muchos mensajes al destinatario y agota el material de la clave privada, lo que obliga al protocolo a elegir entre cerrar (y permitir ataques de denegación de servicio ) o abrir (y renunciar a cierta cantidad de secreto directo). ). [8]
La mayoría de los protocolos de intercambio de claves son interactivos y requieren 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 , asíncrono o de ida y vuelta cero (0-RTT). [9] [10]
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 exigir que el remitente y el destinatario estén en línea al mismo tiempo; Relajar 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, como la seguridad directa es una propiedad deseable en un protocolo de intercambio de claves, en el secreto directo no interactivo. [11] [12] Esta combinación ha sido identificada como deseable desde al menos 1996. [13] Sin embargo, combinar el secreto directo y la no interactividad ha demostrado ser un desafío; [14] Se sospechaba que el secreto directo con protección contra ataques de repetición era imposible de forma no interactiva, pero se ha demostrado que es posible lograr los tres deseos. [10]
En términos generales, se han explorado dos enfoques para el secreto directo no interactivo: claves precalculadas y cifrado perforable . [12]
Con claves precalculadas, se crean muchos pares de claves y se comparten las claves públicas, y 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 . [15]
En el cifrado perforable, el destinatario 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 de claves seguro hacia adelante en 1997, [16] y Green y Miers (2015) describieron formalmente dicho sistema, [17] basándose en el esquema relacionado de Canetti, Halevi y Katz (2003). ), que modifica la clave privada según un cronograma para que los mensajes enviados en períodos anteriores no puedan leerse con la clave privada de un período posterior. [14] 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 la identidad. [18] Dallmeier et al. (2020) descubrieron experimentalmente que la modificación de QUIC para utilizar un intercambio de claves 0-RTT seguro hacia adelante y resistente a la reproducción implementado con cifrado perforable generaba un uso de recursos significativamente mayor, pero no tanto como para hacer que el uso práctico fuera inviable. [19]
El secreto directo perfecto débil (Wpfs) es la propiedad más débil mediante 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 sólo para las sesiones en las que el adversario no interfirió activamente. Esta nueva noción, y la distinción entre esto y el secreto directo, fue introducida por Hugo Krawczyk en 2005. [20] [21] Esta definición más débil requiere implícitamente que el secreto directo 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 un hombre en el medio.
El secreto de reenvío está presente en varias implementaciones de protocolos importantes, como SSH y como característica opcional en IPsec (RFC 2412). La mensajería off-the-record , un protocolo y biblioteca de criptografía para muchos clientes de mensajería instantánea, así como OMEMO , que proporciona funciones adicionales como funcionalidad multiusuario en dichos clientes, ambos proporcionan secreto directo y cifrado denegable .
En Transport Layer Security (TLS), están disponibles conjuntos de cifrado basados en el intercambio de claves Diffie-Hellman (DHERSA , DHEDSA ) y el intercambio de claves Diffie-Hellman de curva elíptica (ECDHE- RSA , ECDHE- ECDSA ). En teoría, TLS podría elegir cifrados apropiados desde SSLv3, pero en la práctica diaria muchas implementaciones se negaron a ofrecer secreto directo o solo lo proporcionaron con un grado de cifrado muy bajo. [22] Este ya no es el caso con TLS 1.3, que garantiza el secreto directo al dejar la efímera Diffie-Hellman (variantes de campo finito y curva elíptica) como el único mecanismo de intercambio de claves restante. [23]
OpenSSL admite el secreto directo utilizando la curva elíptica Diffie-Hellman desde la versión 1.0, [24] con una sobrecarga computacional de aproximadamente el 15% para el protocolo de enlace inicial. [25]
El protocolo de señal utiliza el algoritmo de doble trinquete para proporcionar secreto directo. [26]
Por otro lado, entre los protocolos populares actualmente en uso, WPA no admite el secreto directo.
Varios grandes proveedores de información de Internet consideran que el secreto hacia adelante es una característica de seguridad importante. Desde finales de 2011, Google proporcionó confidencialidad directa con TLS de forma predeterminada a los usuarios de su servicio Gmail , su servicio Google Docs y sus servicios de búsqueda cifrados. [24] Desde noviembre de 2013, Twitter proporcionó confidencialidad directa con TLS a sus usuarios. [27] Todos los wikis alojados por la Fundación Wikimedia han proporcionado secreto de reenvío a los usuarios desde julio de 2014 [28] y exigen el uso de secreto de reenvío desde agosto de 2018.
Facebook informó, como parte de una investigación sobre el cifrado de correo electrónico, que, en mayo de 2014, el 74% de los hosts que admiten STARTTLS también proporcionan confidencialidad directa. [29] TLS 1.3, publicado en agosto de 2018, dejó de admitir cifrados sin secreto directo. En febrero de 2019 [actualizar], el 96,6 % de los servidores web encuestados admiten alguna forma de secreto directo y el 52,1 % utilizará el secreto directo con la mayoría de los navegadores. [30]
En la WWDC 2016, Apple anunció que todas las aplicaciones de iOS necesitarían utilizar App Transport Security (ATS), una característica que impone el uso de la transmisión HTTPS. Específicamente, ATS requiere el uso de un cifrado que proporcione secreto directo. [31] ATS pasó a ser obligatorio para las aplicaciones el 1 de enero de 2017. [32]
La aplicación de mensajería Signal emplea secreto directo en su protocolo, diferenciándolo notablemente de los protocolos de mensajería basados en PGP . [33]