En criptografía , RC4 (Rivest Cipher 4, también conocido como ARC4 o ARCFOUR , que significa Presunto RC4, véase más abajo) es un cifrado de flujo . Si bien es notable por su simplicidad y velocidad en el software, se han descubierto múltiples vulnerabilidades en RC4, lo que lo vuelve inseguro. [3] [4] Es especialmente vulnerable cuando no se descarta el comienzo del flujo de claves de salida, o cuando se utilizan claves no aleatorias o relacionadas. Los usos particularmente problemáticos de RC4 han llevado a protocolos muy inseguros como WEP . [5]
A partir de 2015 [actualizar], se especula que algunas agencias criptológicas estatales pueden tener la capacidad de romper RC4 cuando se usa en el protocolo TLS . [6] IETF ha publicado RFC 7465 para prohibir el uso de RC4 en TLS; [3] Mozilla y Microsoft han emitido recomendaciones similares. [7] [8]
Se han realizado varios intentos para fortalecer el RC4, en particular Spritz, RC4A, VMPC y RC4 + .
RC4 fue diseñado por Ron Rivest de RSA Security en 1987. Si bien oficialmente se denomina "Rivest Cipher 4", el acrónimo RC también se entiende como "Código de Ron" [9] (consulte también RC2 , RC5 y RC6 ).
RC4 fue inicialmente un secreto comercial , pero en septiembre de 1994, se publicó anónimamente una descripción del mismo en la lista de correo Cypherpunks . [10] Pronto se publicó en el grupo de noticias sci.crypt , donde Bob Jenkins lo descifró en cuestión de días . [11] A partir de ahí, se extendió a muchos sitios en Internet. Se confirmó que el código filtrado era genuino, ya que se encontró que su salida coincidía con la del software propietario que usaba RC4 con licencia. Debido a que el algoritmo es conocido, ya no es un secreto comercial. El nombre RC4 es una marca registrada, por lo que a menudo se hace referencia a RC4 como ARCFOUR o ARC4 (que significa supuesto RC4 ) [12] para evitar problemas de marca registrada. RSA Security nunca ha publicado oficialmente el algoritmo; sin embargo, Rivest ha vinculado el artículo de Wikipedia en inglés sobre RC4 en sus propias notas del curso en 2008 [13] y confirmó la historia de RC4 y su código en un artículo de 2014 escrito por él. [14]
RC4 se convirtió en parte de algunos protocolos y estándares de cifrado de uso común, como WEP en 1997 y WPA en 2003/2004 para tarjetas inalámbricas; y SSL en 1995 y su sucesor TLS en 1999, hasta que fue prohibido para todas las versiones de TLS por RFC 7465 en 2015, debido a que los ataques RC4 debilitaban o rompían el RC4 utilizado en SSL/TLS. Los principales factores del éxito de RC4 en una gama tan amplia de aplicaciones han sido su velocidad y simplicidad: las implementaciones eficientes tanto en software como en hardware fueron muy fáciles de desarrollar.
RC4 genera un flujo pseudoaleatorio de bits (un flujo de claves ). Al igual que con cualquier cifrado de flujo, estos pueden usarse para el cifrado al combinarlo con el texto simple usando bit a bit exclusivo o ; el descifrado se realiza de la misma manera (ya que exclusivo o con datos dados es una involución ). Esto es similar al block de un solo uso , excepto que se usan bits pseudoaleatorios generados , en lugar de un flujo preparado.
Para generar el flujo de claves, el cifrado utiliza un estado interno secreto que consta de dos partes:
La permutación se inicializa con una clave de longitud variable , normalmente entre 40 y 2048 bits, mediante el algoritmo de programación de claves (KSA). Una vez completado esto, se genera el flujo de bits mediante el algoritmo de generación pseudoaleatoria (PRGA).
El algoritmo de programación de claves se utiliza para inicializar la permutación en la matriz "S". "Keylength" se define como el número de bytes en la clave y puede estar en el rango 1 ≤ keylength ≤ 256, típicamente entre 5 y 16, correspondiente a una longitud de clave de 40–128 bits. Primero, la matriz "S" se inicializa con la permutación de identidad . Luego, S se procesa durante 256 iteraciones de manera similar al PRGA principal, pero también mezcla bytes de la clave al mismo tiempo.
para i de 0 a 255 S[i] := yofin paraj := 0para i de 0 a 255 j := (j + S[i] + clave[i mod longitud de clave]) mod 256 Intercambiar valores de S[i] y S[j]fin para
Para tantas iteraciones como sean necesarias, el PRGA modifica el estado y genera un byte del flujo de claves. En cada iteración, el PRGA:
Cada elemento de S se intercambia con otro elemento al menos una vez cada 256 iteraciones.
yo := 0j := 0mientras se genera la salida: yo := (yo + 1) mod 256 j := (j + S[i]) módulo 256 Intercambiar valores de S[i] y S[j] t := (S[i] + S[j]) módulo 256 K := S[t] Salida Kmientras tanto
Por lo tanto, esto produce un flujo de K[0], K[1], ... que se combinan con el texto simple para obtener el texto cifrado . Por lo tanto, texto cifrado[ l ] = texto simple[ l ] ⊕ K[ l ] .
Varios sistemas operativos incluyen arc4random
, una API originada en OpenBSD que proporciona acceso a un generador de números aleatorios originalmente basado en RC4. La API no permite la inicialización, ya que la función se inicializa a sí misma utilizando /dev/random . El uso de RC4 ha sido eliminado en la mayoría de los sistemas que implementan esta API. Las páginas del manual para el nuevo arc4random incluyen el acrónimo "A Replacement Call for Random" para ARC4 como mnemónico, ya que proporciona mejores datos aleatorios que rand() . [15]
arc4random
se modificó para utilizar ChaCha20 . [16] [17] Las implementaciones de arc4random en FreeBSD , NetBSD [18] [19] también utilizan ChaCha20.Los nuevos generadores de números aleatorios propuestos a menudo se comparan con el generador de números aleatorios RC4. [22] [23]
Varios ataques a RC4 son capaces de distinguir su salida de una secuencia aleatoria . [24]
Muchos cifrados de flujo se basan en registros de desplazamiento con retroalimentación lineal (LFSR), que, si bien son eficientes en hardware, lo son menos en software. El diseño de RC4 evita el uso de LFSR y es ideal para la implementación de software, ya que solo requiere manipulaciones de bytes. Utiliza 256 bytes de memoria para la matriz de estados, S[0] a S[255], k bytes de memoria para la clave, clave[0] a clave[k−1], y las variables enteras, i, j y K. La realización de una reducción modular de algún valor módulo 256 se puede realizar con un AND bit a bit con 255 (que es equivalente a tomar el byte de orden inferior del valor en cuestión).
Estos vectores de prueba no son oficiales, pero son útiles para cualquiera que esté probando su propio programa RC4. Las claves y el texto sin formato están en ASCII , el flujo de claves y el texto cifrado están en hexadecimal .
A diferencia de un cifrado de flujo moderno (como los de eSTREAM ), RC4 no toma un nonce separado junto con la clave. Esto significa que si se va a utilizar una única clave a largo plazo para cifrar de forma segura varios flujos, el protocolo debe especificar cómo combinar el nonce y la clave a largo plazo para generar la clave de flujo para RC4. Un enfoque para abordar esto es generar una clave RC4 "nueva" mediante el hash de una clave a largo plazo con un nonce . Sin embargo, muchas aplicaciones que utilizan RC4 simplemente concatenan clave y nonce; el programa de claves débil de RC4 da lugar a ataques de clave relacionada , como el ataque Fluhrer, Mantin y Shamir (que es famoso por romper el estándar WEP ). [25]
Debido a que RC4 es un cifrado de flujo , es más maleable que los cifrados de bloque comunes . Si no se utiliza junto con un código de autenticación de mensajes (MAC) fuerte, el cifrado es vulnerable a un ataque de inversión de bits . El cifrado también es vulnerable a un ataque de cifrado de flujo si no se implementa correctamente. [26]
Sin embargo, cabe destacar que RC4, al ser un cifrado de flujo, fue durante un tiempo el único cifrado común que era inmune [27] al ataque BEAST de 2011 a TLS 1.0 . El ataque explota una debilidad conocida en la forma en que se utiliza el modo de encadenamiento de bloques de cifrado con todos los demás cifrados compatibles con TLS 1.0, que son todos cifrados de bloque.
En marzo de 2013, Isobe, Ohigashi, Watanabe y Morii [28], así como AlFardan, Bernstein, Paterson, Poettering y Schuldt propusieron nuevos escenarios de ataque que utilizan nuevos sesgos estadísticos en la tabla de claves RC4 [29] para recuperar texto simple con una gran cantidad de cifrados TLS. [30] [31]
El uso de RC4 en TLS está prohibido por el RFC 7465 publicado en febrero de 2015.
En 1995, Andrew Roos observó experimentalmente que el primer byte del flujo de claves está correlacionado con los primeros tres bytes de la clave, y los primeros bytes de la permutación después del KSA están correlacionados con alguna combinación lineal de los bytes de la clave. [32] Estos sesgos permanecieron sin explicación hasta 2007, cuando Goutam Paul, Siddheshwar Rathi y Subhamoy Maitra [33] demostraron la correlación flujo de claves-clave y, en otro trabajo, Goutam Paul y Subhamoy Maitra [34] demostraron las correlaciones permutación-clave. El último trabajo también utilizó las correlaciones permutación-clave para diseñar el primer algoritmo para la reconstrucción completa de la clave a partir de la permutación final después del KSA, sin ninguna suposición sobre la clave o el vector de inicialización . Este algoritmo tiene una probabilidad constante de éxito en un tiempo, que es la raíz cuadrada de la complejidad de búsqueda exhaustiva de la clave. Posteriormente, se han realizado muchos otros trabajos sobre la reconstrucción de claves a partir de estados internos de RC4. [35] [36] [37] Subhamoy Maitra y Goutam Paul [38] también demostraron que los sesgos de tipo Roos aún persisten incluso cuando se consideran índices de permutación anidados, como S[S[i]] o S[S[S[i]]] . Estos tipos de sesgos se utilizan en algunos de los métodos de reconstrucción clave posteriores para aumentar la probabilidad de éxito.
El flujo de claves generado por el RC4 está sesgado en distintos grados hacia ciertas secuencias, lo que lo hace vulnerable a ataques de distinción . El mejor ataque de este tipo se debe a Itsik Mantin y Adi Shamir , quienes demostraron que el segundo byte de salida del cifrado estaba sesgado hacia cero con una probabilidad de 1/128 (en lugar de 1/256). Esto se debe al hecho de que si el tercer byte del estado original es cero y el segundo byte no es igual a 2, entonces el segundo byte de salida siempre es cero. Tal sesgo se puede detectar observando solo 256 bytes. [24]
Souradyuti Paul y Bart Preneel de COSIC demostraron que el primer y el segundo byte del RC4 también estaban sesgados. La cantidad de muestras necesarias para detectar este sesgo es de 2 a 25 bytes. [39]
Scott Fluhrer y David McGrew también mostraron ataques que distinguían el flujo de claves del RC4 de un flujo aleatorio dado un gigabyte de salida. [40]
Riddhipratim Basu, Shirshendu Ganguly, Subhamoy Maitra y Goutam Paul realizaron la caracterización completa de un solo paso de RC4 PRGA. [41] Considerando todas las permutaciones, demostraron que la distribución de la salida no es uniforme dados i y j, y como consecuencia, la información sobre j siempre se filtra en la salida.
En 2001, Fluhrer, Mantin y Shamir hicieron un descubrimiento nuevo y sorprendente : en todas las claves RC4 posibles, las estadísticas de los primeros bytes del flujo de claves de salida son fuertemente no aleatorias, lo que permite filtrar información sobre la clave. Si el nonce y la clave a largo plazo se concatenan simplemente para generar la clave RC4, esta clave a largo plazo se puede descubrir analizando una gran cantidad de mensajes cifrados con esta clave. [42] Este y otros efectos relacionados se utilizaron para romper el cifrado WEP ("privacidad equivalente a cable") utilizado con las redes inalámbricas 802.11 . Esto provocó una lucha por un reemplazo basado en estándares para WEP en el mercado 802.11 y condujo al esfuerzo IEEE 802.11i y WPA . [43]
Los protocolos pueden defenderse de este ataque descartando la parte inicial del flujo de claves. Este algoritmo modificado se denomina tradicionalmente "RC4-drop[ n ]", donde n es el número de bytes iniciales del flujo de claves que se descartan. El valor predeterminado de SCAN es n = 768 bytes, pero un valor conservador sería n = 3072 bytes. [44]
El ataque de Fluhrer, Mantin y Shamir no se aplica a SSL basado en RC4, ya que SSL genera las claves de cifrado que utiliza para RC4 mediante hash, lo que significa que las diferentes sesiones SSL tienen claves no relacionadas. [45]
En 2005, Andreas Klein presentó un análisis del cifrado de flujo RC4, mostrando más correlaciones entre el flujo de claves RC4 y la clave. [46] Erik Tews, Ralf-Philipp Weinmann y Andrei Pychkine utilizaron este análisis para crear aircrack-ptw, una herramienta que descifra RC4 de 104 bits utilizado en WEP de 128 bits en menos de un minuto. [47] Mientras que el ataque de Fluhrer, Mantin y Shamir utilizó alrededor de 10 millones de mensajes, aircrack-ptw puede descifrar claves de 104 bits en 40.000 cuadros con una probabilidad del 50%, o en 85.000 cuadros con una probabilidad del 95%.
Itsik Mantin y Adi Shamir plantearon por primera vez en 2001 un problema combinatorio relacionado con el número de entradas y salidas del cifrado RC4, según el cual, de los 256 elementos totales del estado típico de RC4, si solo se conocen x elementos ( x ≤ 256) (se puede suponer que todos los demás elementos están vacíos), entonces el número máximo de elementos que se pueden producir de forma determinista también es x en las siguientes 256 rondas. Esta conjetura fue descartada en 2004 con una prueba formal dada por Souradyuti Paul y Bart Preneel . [48]
En 2013, un grupo de investigadores de seguridad del Grupo de Seguridad de la Información de Royal Holloway, Universidad de Londres, informó sobre un ataque que puede resultar efectivo utilizando solo 2 34 mensajes cifrados. [49] [50] [51] Aunque todavía no es un ataque práctico para la mayoría de los propósitos, este resultado es lo suficientemente cercano a uno como para haber llevado a la especulación de que es plausible que algunas agencias criptológicas estatales ya puedan tener mejores ataques que hagan que RC4 sea inseguro. [6] Dado que, a partir de 2013 [actualizar], una gran cantidad de tráfico TLS utiliza RC4 para evitar ataques a cifrados de bloque que utilizan encadenamiento de bloques de cifrado , si existen estos hipotéticos ataques mejores, esto haría que la combinación TLS con RC4 sea insegura contra tales atacantes en una gran cantidad de escenarios prácticos. [6]
En marzo de 2015, un investigador de Royal Holloway anunció mejoras en su ataque, proporcionando un ataque 2x26 contra contraseñas cifradas con RC4, como las que se utilizan en TLS. [52]
En la Conferencia Black Hat Asia 2015, Itsik Mantin presentó otro ataque contra SSL utilizando el cifrado RC4. [53] [54]
En 2015, investigadores de seguridad de KU Leuven presentaron nuevos ataques contra RC4 tanto en TLS como en WPA-TKIP . [55] Apodado el ataque Numerous Occurrence MOnitoring & Recovery Exploit (NOMORE), es el primer ataque de este tipo que se demostró en la práctica. Su ataque contra TLS puede descifrar una cookie HTTP segura en 75 horas. El ataque contra WPA-TKIP puede completarse en una hora y permite a un atacante descifrar e inyectar paquetes arbitrarios.
Como se mencionó anteriormente, la debilidad más importante de RC4 proviene de la programación de claves insuficiente; los primeros bytes de salida revelan información sobre la clave. Esto se puede corregir simplemente descartando una parte inicial del flujo de salida. [56] Esto se conoce como RC4-drop N , donde N es típicamente un múltiplo de 256, como 768 o 1024.
Se han realizado varios intentos para fortalecer el RC4, en particular Spritz, RC4A, VMPC y RC4 + .
Souradyuti Paul y Bart Preneel han propuesto una variante RC4, a la que denominan RC4A. [57]
RC4A utiliza dos matrices de estados S1 y S2 y dos índices j1 y j2 . Cada vez que se incrementa i , se generan dos bytes:
Así pues, el algoritmo es:
Toda la aritmética se realiza módulo 256yo := 0j1 := 0j2 := 0mientras se genera la salida: yo := yo + 1 j1 := j1 + S1[i] Intercambiar valores de S1[i] y S1[j1] salida S2[S1[i] + S1[j1]] j2 := j2 + S2[i] Intercambiar valores de S2[i] y S2[j2] salida S1[S2[i] + S2[j2]] fin mientras
Aunque el algoritmo requiere el mismo número de operaciones por byte de salida, existe mayor paralelismo que RC4, lo que proporciona una posible mejora de velocidad.
Aunque es más fuerte que RC4, este algoritmo también ha sido atacado: Alexander Maximov [58] y un equipo de NEC [59] desarrollaron formas de distinguir su salida de una secuencia verdaderamente aleatoria.
La composición de permutación modificada de forma variable (VMPC) es otra variante de RC4. [60] Utiliza un esquema de claves similar al de RC4, con j := S[(j + S[i] + clave[i mod longitud de clave]) mod 256] iterando 3 × 256 = 768 veces en lugar de 256, y con 768 iteraciones adicionales opcionales para incorporar un vector inicial. La función de generación de salida funciona de la siguiente manera:
Toda la aritmética se realiza módulo 256.yo := 0mientras se genera la salida: a := S[i] j := S[j + a] salida S[S[S[j] + 1]] Intercambiar S[i] y S[j] ( b := S[j]; S[i] := b; S[j] := a) ) yo := yo + 1mientras tanto
Esto fue atacado en los mismos artículos que RC4A, y se puede distinguir dentro de 2 38 bytes de salida. [61] [59]
RC4 + es una versión modificada de RC4 con un programa de clave de tres fases más complejo (que tarda aproximadamente tres veces más que RC4, o lo mismo que RC4-drop512), y una función de salida más compleja que realiza cuatro búsquedas adicionales en la matriz S para cada byte de salida, lo que tarda aproximadamente 1,7 veces más que el RC4 básico. [62]
Toda la aritmética módulo 256. << y >> son desplazamientos a la izquierda y a la derecha, ⊕ es OR exclusivo mientras GeneratingOutput: yo := yo + 1 a := S[i] j := j + a Intercambiar S[i] y S[j] ( b := S[j]; S[j] := S[i]; S[i] := b; ) c := S[i<<5 ⊕ j>>3] + S[j<<5 ⊕ i>>3] salida (S[a+b] + S[c⊕0xAA]) ⊕ S[j+b] fin
Este algoritmo no ha sido analizado significativamente.
En 2014, Ronald Rivest dio una charla y coescribió un artículo [14] sobre un rediseño actualizado llamado Spritz. Se publicó un acelerador de hardware de Spritz en Secrypt, 2016 [63] y muestra que debido a las múltiples llamadas anidadas necesarias para producir bytes de salida, Spritz funciona de manera bastante lenta en comparación con otras funciones hash como SHA-3 y la implementación de hardware más conocida de RC4.
Al igual que otras funciones de esponja , Spritz se puede utilizar para construir una función hash criptográfica, un generador de bits aleatorios determinista ( DRBG ), un algoritmo de cifrado que admita el cifrado autenticado con datos asociados (AEAD), etc. [14]
En 2016, Banik e Isobe propusieron un ataque que puede distinguir a Spritz del ruido aleatorio. [64] En 2017, Banik, Isobe y Morii propusieron una solución simple que elimina el diferenciador en los primeros dos bytes del flujo de claves, lo que requiere solo un acceso adicional a la memoria sin disminuir sustancialmente el rendimiento del software. [65]
Cuando un protocolo está marcado con "(opcionalmente)", RC4 es uno de los múltiples cifrados que el sistema puede configurarse para usar.
Generador de números aleatorios basado en ChaCha para OpenBSD.
API arc4random(3) heredada de OpenBSD reimplementada utilizando la PRF ChaCha20, con estado por subproceso.