stringtranslate.com

Secreto de reenvío

Una función de derivación de claves (KDF) puede ayudar a lograr la confidencialidad directa. Una KDF es una función unidireccional que genera una nueva clave a partir de la clave actual. La filtración de una clave no permite el descubrimiento de claves anteriores.

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]

Historia

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]

Definición

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.

Ejemplo

El siguiente es un ejemplo hipotético de un protocolo de mensajería instantánea simple que emplea secreto de reenvío:

  1. Alice y Bob generan cada uno un par de claves públicas y privadas asimétricas de largo plazo y luego verifican las huellas digitales de las claves públicas en persona o a través de un canal ya autenticado. La verificación establece con confianza que el supuesto propietario de una clave pública es el propietario real.
  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 entre sí durante este proceso.
  3. Alice envía un mensaje a Bob, cifrándolo 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 para cada nuevo mensaje enviado, comenzando desde el paso 2 (y cambiando los roles de Alice y Bob como remitente/receptor según corresponda). El paso 1 nunca se repite.

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.

Ataques

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]

Secreto de reenvío no interactivo

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]

Secreto directo perfecto débil

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.

Protocolos

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]

Usar

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 , el servicio Google Docs y los 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 , 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]

Véase también

Referencias

  1. ^ "/docs/man1.1.1/man3/SSL_set_tmp_dh.html". www.openssl.org . Consultado el 25 de mayo de 2024 .
  2. ^ "tls - ¿El secreto perfecto hacia adelante (PFS) dificulta los ataques Man-in-the-Middle (MitM)?". Stack Exchange sobre seguridad de la información . Consultado el 11 de octubre de 2020 .
  3. ^ Günther, CG (1990). Un protocolo de intercambio de claves basado en identidad . Avances en criptología EUROCRYPT '89 (LNCS 434). pp. 29–37.
  4. ^ Menzies, Alfred; van Oorscot, Paul C; Vanstone, SCOTT (1997). Manual de criptografía aplicada . CRC Pres. ISBN 978-0-8493-8523-0.
  5. ^ Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. (junio de 1992). "Autenticación e intercambios de claves autenticadas" (PDF) . Diseños, códigos y criptografía . 2 (2): 107–125. CiteSeerX 10.1.1.59.6682 . doi :10.1007/BF00124891. S2CID  7356608 . Consultado el 7 de septiembre de 2013 . 
  6. ^ Jablon, David P. (octubre de 1996). "Intercambio de claves autenticado mediante contraseñas seguras". ACM Computer Communication Review . 26 (5): 5–26. CiteSeerX 10.1.1.81.2594 . doi :10.1145/242896.242897. S2CID  2870433. 
  7. ^ "IEEE 1363-2000 - Especificaciones estándar IEEE para criptografía de clave pública". IEEE . Consultado el 14 de junio de 2018 .
  8. ^ Nilsson, Dennis K.; Roosta, Tanya; Lindqvist, Ulf; Valdes, Alfonso (31 de marzo de 2008). "Gestión de claves y actualizaciones seguras de software en entornos de control de procesos inalámbricos". Actas de la primera conferencia de la ACM sobre seguridad de redes inalámbricas . WiSec '08. Alexandria, VA, EE. UU.: Association for Computing Machinery. págs. 100–108. doi :10.1145/1352533.1352550. ISBN 978-1-59593-814-5. Número de identificación del sujeto  15382932.
  9. ^ Boyd y Gellert 2020, pag. 645.
  10. ^ Boyd y Gellert 2020, pag. 639-640.
  11. ^ ab Günther et al. 2017, pág. 1.
  12. ^ Boyd y Gellert 2020, pag. 640.
  13. ^ ab Boyd y Gellert 2020, pág. 643.
  14. ^ Volver 1996.
  15. ^ ab Green y Miers 2015, pág. 1.
  16. ^ Boyd y Gellert 2020, pag. 644-645.
  17. ^ Anderson 2002.
  18. ^ Boyd y Gellert 2020, pag. 643-644.
  19. ^ Günther y otros, 2017, pág. 5.
  20. ^ Dallmeier y col. 2020, pág. 18-19.
  21. ^ Krawczyk, Hugo (2005). HMQV: Un protocolo Diffie-Hellman seguro de alto rendimiento. Avances en criptología – CRYPTO 2005. Apuntes de clase en informática. Vol. 3621. págs. 546–566. doi : 10.1007/11535218_33 . ISBN 978-3-540-28114-6.
  22. ^ Cremers, Cas; Feltz, Michèle (2015). "Más allá de eCK: secreto perfecto hacia adelante bajo compromiso de actor y revelación de clave efímera" (PDF) . Diseños, códigos y criptografía . 74 (1): 183–218. CiteSeerX 10.1.1.692.1406 . doi :10.1007/s10623-013-9852-1. hdl :20.500.11850/73097. S2CID  53306672 . Consultado el 8 de diciembre de 2015 . 
  23. ^ Discusión en la lista de correo de TLS en octubre de 2007
  24. ^ "Una mirada detallada a RFC 8446 (también conocido como TLS 1.3)". El blog de Cloudflare . 2018-08-10 . Consultado el 2019-02-26 .
  25. ^ ab "Protección de datos a largo plazo con secreto hacia delante" . Consultado el 5 de noviembre de 2012 .
  26. ^ Vincent Bernat (28 de noviembre de 2011). «SSL/TLS y Perfect Forward Secrecy» . Consultado el 5 de noviembre de 2012 .
  27. ^ Unger, Nik; Dechand, Sergej; Bonneau, Joseph; Fahl, Sascha; Perl, Henning; Goldberg, Ian; Smith, Matthew (17–21 de mayo de 2015). "SoK: mensajería segura". Simposio IEEE sobre seguridad y privacidad de 2015 (PDF) . San José, CA: Instituto de Ingenieros Eléctricos y Electrónicos. p. 241. doi :10.1109/SP.2015.22. ISBN 978-1-4673-6949-7. S2CID  2471650 . Consultado el 4 de diciembre de 2015 .
  28. ^ "Wi-Fi se vuelve más seguro: todo lo que necesita saber sobre WPA3 - IEEE Spectrum". IEEE . Consultado el 4 de mayo de 2024 .
  29. ^ Hoffman-Andrews, Jacob. "Secreto de reenvío en Twitter". Twitter . Consultado el 25 de noviembre de 2013 .
  30. ^ "Tech/News/2014/27 - Meta". Fundación Wikimedia . 2014-06-30 . Consultado el 30 de junio de 2014 .
  31. ^ "El estado actual de la implementación de SMTP STARTTLS". Facebook . Consultado el 7 de junio de 2014 .
  32. ^ Qualys SSL Labs . «SSL Pulse». Archivado desde el original (3 de febrero de 2019) el 15 de febrero de 2019. Consultado el 25 de febrero de 2019 .
  33. ^ "iOS 9.0".
  34. ^ "Seguridad de transporte de aplicaciones REQUERIDA en enero de 2017 | Foros de desarrolladores de Apple". forums.developer.apple.com . Consultado el 20 de octubre de 2016 .
  35. ^ Evans, Jon (22 de enero de 2017). «WhatsApp, Signal y un periodismo peligrosamente ignorante». TechCrunch . Consultado el 18 de abril de 2018 .
  36. ^ "Qualys SSL Labs - SSL Pulse". www.ssllabs.com . Consultado el 25 de mayo de 2024 .

Bibliografía

Enlaces externos