Estas aquiContenido / Nuevo ataque contra RSA: la vulnerabilidad está en el chip
Nuevo ataque contra RSA: la vulnerabilidad está en el chip
Yahoo! ha levantado hoy la liebre en la Red, pero tanto ese medio como el artículo original en Le Monde, hacen referencia a un misterioso trabajo "aún confidencial".
Sin embargo, Kriptópolis ha podido encontrar on-line una versión preliminar del que parece ser el artículo que ambos mencionan, pendiente tan sólo de revisión editorial.
El artículo en cuestión explica un nuevo ataque contra RSA, que profundiza en una vía recientemente abierta -denominada BPA (Branch Prediction Analysis)- y que aprovecha una peculiaridad del diseño de los microprocesadores actuales...
En muy pocas palabras, los autores del trabajo afirman que los procesadores actuales han tomado un atajo de diseño (el módulo de predicción) en aras de favorecer la velocidad de las operaciones, lo que perjudica seriamente la seguridad de ciertas operaciones.
De hecho, debido a esa debilidad, y mediante un simple software que espiara determinadas operaciones de la CPU, sería posible romper con suma facilidad las claves RSA en las que descansa hoy en día la seguridad del comercio electrónico mundial.
A modo de ejemplo, los autores afirman haber hallado al primer intento una clave de 512 bit utilizada en OpenSSL, en sólo varias milésimas de segundo.
Según Le Monde, fuentes de la máxima solvencia confirman la realidad de la amenaza. Afirman que la solución radical pasaría por rediseñar los microprocesadores, pero que un posible atajo sería que las implementaciones dejaran de utilizar el módulo de predicción del procesador, aunque tal medida podría convertir en cuatro veces más lentas las operaciones criptográficas en línea.
Al parecer, el trabajo será presentado públicamente en febrero de 2007, durante la Conferencia RSA 2007, a celebrar este año en San Francisco (EE.UU.).
Versión para imprimir
Aquí hay otro interesante documento sobre este mismo asunto, que recomiendo leer detenidamente.
Pero lo peor de todo esto, es que los sistemas "Branch Prediction" se usan preferentemente en sistemas de "tiempo real" y desde hace tiempo, eran un reto para incluir en los sistemas basados en Smart Card, en un intento de optimizar su limitada capacidad de proceso.
En el artículo que nos recomienda José Manuel, se comenta algo tan preocupante como:
"So far, typical targets of side-channel attacks have been mainly Smart Cards, cf. [CNK,Koc]. This is due to the ease of applying such attacks to smart cards. The measurements of side-channel information on smart cards are almost “noiseless”, which makes such attacks very practical. "
Pero si rebobinamos en el tiempo, allá en el año 2003 y en el seno del Votobit, yo comentaba en un artículo que en un futuro cercano podrían haber problemas por fallos inadvertidos en el hardware:
4.2 Fallos no detectados
El hecho de que no se reporten o conozcan fallos de seguridad del dispositivo, no significa que no existan, incluso que no se estén explotando con éxito por delincuentes. Este hecho puede ser muy peligroso para los usuarios, ya que es posible que ante un eventual problema y una reclamación judicial, los peritos de la Administración, por desconocimiento de las vulnerabilidades, declaren que el sistema es completamente seguro.
Posteriormente yo hablaba en Kriptópolis de los problemas relacionados con la sustitución de una tecnología, si fallaba el sistema criptográfico que la soportaba y por ello, aunque pareciera un escenario poco probable, recomendaba el establecimiento de planes de contingencia.
Es decir, que si se confirma que dicha vulnerabilidad existe y que explotándola se puede romper una clave de 512 bits en centésimas de segundo, algo tendría que cambiar en el panorama criptográfico de este país y si me apuran, ya están tardando los responsables del ramo en establecer los planes de contingencia, por si es cierto lo que se dice en este artículo y se puede explotar con facilidad.
Sin embargo, aquí otra predicción que se va a cumplir con casi toda la seguridad, "nadie va a mover un dedo al respecto", o como dicen en mi tierra y se ha demostrado con el fallo en el sistema PKI:
"Unos por otros y la casa por barrer".
Aunque está vulnerabilidad está por confirmar y demostrar, para mayor desgracia para los que decían y mantenían que este era un escenario imposible, me parece que tiene pinta de ser cierta.
Dicho de otro modo, creo que he logrado dos predicciones acertadas en dos días consecutivos, lo que me eleva al rango de mejor "vidente" nacional, muy por encima de Rappel ;-) y otros.
Pero ¿se cumplirá también la tercera que lanzo en este comentario de que nadie va a hacer nada aunque se demuestre que esto es cierto?.
Y otra cosa no menos importante, veremos lo que opinan y hacen ahora, todos aquellos que mantenían posturas contrarias a que esto fuera posible.
"Copyleft 2006 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".
Te felicito enormemente, por tu capacidad predictiva en el mundo de la criptografía... Sólo esta el problema de... ¿y ahora que hacemos los que nos tomamos nuestra seguridad en serio?... Que yo sepa, la inmensa mayoría de sistemas de clave pública, se basan en RSA si no me ekivoco... ¿lo único así alternativo son los sistemas de Curva Elíptica no? sin embargo, esa tecnica no esta muy difundida al publico... pese al trabajo logradisimo del amigo del foro, creando el SKS :P Creo que tu predicción tercera, se cumplirá sin dudas... ...aunque quede demostrado, las administraciones públicas y todos los sistemas mundiales, no haran nada, en caso de demostrarse la veracidad de la noticia... Un Fuerte Abrazo! ========================================= En Enero 2007 volvere a actualizar mi web http://www.dtodo1poco.com/~strapping/
=========================================
En Enero 2007 volvere a actualizar mi web
http://www.dtodo1poco.com/~strapping/
Es obvio que este descubrimiento impacta gravemente en la seguridad de RSA, pero en la práctica ¿qué tan grave es?
Me refiero a que si es necesario tener acceso al equipo que tiene la clave privada para descifrar los datos. Porque si es así, entonces la solución rápida se reduce a restringir lo más posible el acceso a los servidores.
Por otro lado, el ataque ¿qué clase de acceso requiere? Necesita permiso de administración sobre el equipo o con una cuenta de usuario se podría realizar?
Alejandro Nestor Vargas
"Afirman que la solución radical pasaría por rediseñar los microprocesadores"
A mi esto no me parece una solucion ni de lejos, y menos una vez se haga público
"Los bancos tienen muchos numeros en el ordenador, pero poca pasta"
Me parece un agujero serio y no sé hasta qué punto es responsabilidad de programadores poco profesionales.
Me explico. Cuando estuve programando la aplicación SKS (ver en la firma), tuve que pensar en optimizaciones, especialmente en el multiplicador de curva elíptica que es la operación más pesada (equivalente en importancia a la exponenciación modular del RSA, pero no tan exigente).
Una de las optimizaciones que descarté actúa de la siguiente manera: se mueve por todos los bits del multiplicador y hace algo que consume tiempo de CPU sólo cuando el bit está a 1. ¿Qué ocurre? Que un multiplicador poco "denso" en 1s efectúa la operación más rápido que otro más "denso", por lo que podría quedar bajo un ataque de inspección del tiempo de computación, de forma que un atacante podría tener una pista acerca de la cantidad de 1s que forman parte del multiplicador, muchas veces secreto (en ECC, la clave secreta es un multiplicador de curva).
(Y es que, como parece apuntar la práctica, seguridad y velocidad son como dos variables conjugadas de una especie de principio de incertidumbre de Heisenberg aplicado a la informática: o tienes una o tienes la otra pero ambas a la vez...)
Si eso lo pensé yo, programador aficionado cuya aplicación está orientada a entornos tales que difícilmente se pueden dar escenarios de ataques de tiempo, entonces... ¿por qué no piensan en eso los programadores profesionales?
También puede ocurrir que el uso de la optimización del procesador a la que se refiere la noticia dependa más bien del compilador y/o de una opción del compilador, en lugar de ser algo dependiente directamente de cómo se ha programado el código. En ese caso... ¿es el programador responsable?
SKS, criptografía de curva elíptica de bolsillo
http://sks.merseine.nu
SKS, criptografía de curva elíptica de bolsillo
http://sks.merseine.nu
He estado leyendo con más detenimiento los documentos de este artículo y el que envié yo y la cosa puede tener más miga de la que parece.
Los hechos parece que son los siguientes:
a) Están afectados todos los sistemas superescalares con predicción, con independencia de que se implementen mediante software o hardware. Las smartcards con sistemas operativos WCET (Worst Case Execution Analysis) también están afectadas ¿cuáles son?, habrá que verlo, pero con el esfuerzo dedicado a optimizarlas, casi podemos decir que todas.
b) No es necesario tener acceso físico al sistema, un troyano puede hacer el trabajo. No es necesario que el programa "espia" corra con privilegios especiales y basta con que se esté ejecutando antes que el algoritmo de cifrado. Lo único que puede cambiar algo del código del espía con cada modelo o velocidad de procesador, pero ese es un problema fácilmente salvable ya que los procesadores son habas contadas.
c) Todos los sistemas de seguridad ideados para proteger sistemas, tales como los que comenta Shevek en su post, son completamente inútiles ante este ataque. Por ejemplo, las smartcards con protección contra ataques side-chanel (usados con mucho éxito en los ataques a las plataformas de tv digital) también están afectadas, así como los sistemas que usan randomizadores, inversores, equilibradores de rama, o sistemas similares de protección también están afectados, con independencia de que su implementación sea por software o hardware.
d) Este sistema usa un proceso paralelo "espia" que interactua con el proceso "seguro" en los elementos comunes de la arquitectura.
A diferencia de los sistemas estadísticos o diferenciales, este sistema solamente necesita una pasada para lograr el 90% o más de la clave.
El ataque es relativamente simple, el programa "espia" ejecuta un determinado número de ramas y mide el tiempo de ejecución medio de cada rama en esa única ejecución.
Simplemente, ejecutando las ramas del programa "espía" y midiendo el tiempo total de ejecución de las mismas. Por lo tanto, el proceso "espía" puede conocer la traza completa de predicción del programa objetivo en las pilas y con ello, ser capaz de obtener la clave secreta, si no completa, en un porcentaje muy alto.
Para simplificar, podemos decir que el programa "espía" afecta al funcionamiento del programa "seguro" a través de las áreas comunes de la arquitectura del procesador y mediante la medición del tiempo de ejecución o metadatos de control, obtiene la información de la clave de forma bastante precisa.
Por lo tanto, como hemos dicho, los esquemas de protección usados hasta el momento, son completamente inútiles, como se comenta en el artículo, ante este novedoso ataque.
e) Las operaciones "sensibles" son las reducción modular y la inversión modular, aunque operaciones como la multiplicación o potenciación también pueden servir para detectar la clave.
Lo que implica que no solamente está afectado el algoritmo RSA, están afectados prácticamente todos los algoritmos de cifrado.
Sigo leyendo e intentando asimilar ya que el documento para mi gusto no es muy completo y deja algunas lagunas, pero revisando la bibliografía que le acompaña, se pueden sacar conclusiones más que interesantes, pero eso requiere algo más de tiempo.
De verdad, recomiendo la atenta lectura de los dos artículos ya que son muy interesantes y entre todos, podemos sacar algunas conclusiones interesantes.
Si se manifiesta que esta vulnerabilidad es explotable de forma práctica, las soluciones son pocas, complicadas y posiblemente caras.
"Copyleft 2006 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".
Buenas noches señores, aki son las 11 de la noche... tras leer el nuevo comentario de Fer, parece que al final el unico algoritmo de cifrado no estudiable por atakes sería la siguiente idea:
1º Comprimir archivo a cifrar
2º Inventarnos nuestra super clave (palabra o frase), y sacar su HASH de nbits (pongamos SHA 512)
3º Mediante algoritmo generador de secuencia de bits aleatorio, usar el HASH, como SEMILLA de la secuencia RAND... de N bits...
4º Usar esa secuencia como cifradora por sustitución XOR.
...¿que tal parece la idea? eso no se puede medir en ningun micro, el XOR a pelo de una secuencia de bits con otra...
PD: creo q es una buena propuesta, aunque igual es solo una tonta idea de un feliciano forofo...
================================ En Enero 2007 volvere a actualizar mi web http://www.dtodo1poco.com/~strapping/
=========================================
En Enero 2007 volvere a actualizar mi web
http://www.dtodo1poco.com/~strapping/
Uhm... si te han metido un troyano, poco importa realmente cómo te la juega.
Sin necesidad de estos artículos ya se podía predecir que un sistema con un troyano no es seguro. Realmente el agujero está antes: no permitas troyanos.
Como dice David Wagner en sci.crypt:
SKS, criptografía de curva elíptica de bolsillo
http://sks.merseine.nu
SKS, criptografía de curva elíptica de bolsillo
http://sks.merseine.nu
Es un matiz, pero esta técnica tiene más usos que un simple troyano. Lo verdaderamente peligroso de todo este asunto, es que el objetivo de esta técnica no es el mensaje o la contraseña, es la clave usada para encriptar y desencriptar o para firmar la información que se envía, un escenario que anteriormente se antojaba remoto o improbable.
Estamos ante la posibilidad de clonar una clave, sacándola de su contenedor seguro, para meterla en otro contenedor controlado por nosotros (de hardware o de software), con lo que podremos hacer lo mismo que hace el usuario original con su clave (firmar, decodificar mensajes, codificarlos, etc).
Hemos de darnos cuenta de una cosa, una vez que se la logrado firmar un documento con una clave válida, es complicado saber cuál era el origen de dicha clave o si estaba en cun contenedor de software o de hardware, si compartía espacio con claves de otras personas, etc. Sistemas de seguridad para detectar falsificaciones, como el número de serie único para smartcards, tiene poca aplicación ante un mensaje que ha sido firmado, en todo caso, serviría para detectar, si se tiene acceso físico a la tarjeta falsa, que es falsa.
De todos modos, habrá que ver en lo que queda todo este asúnto, pero desde luego, a la vista de lo que hay, abre puertas muy interesantes para nuevos ataques.
"Copyleft 2006 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".
Me imagino perfectamente el impacto de esto en una empresa que use cifrado de datos, digamos un banco:
El gerente le pregunta al director de informática respecto a algo preocupante que leyó en las noticias respecto del cifrado. El director de informática responde que lo están analizando (mentira) con los especialistas.
El director de informática (que no tenía noticia del asunto) se reúne urgente con su gente y les pregunta: muchachos, ¿qué hay con esto de una vulnerabilidad en el RSA?
Ellos, que sí están al tanto de las noticias le contestan: la verdad es que es un problema grave, no sólo afecta al RSA sino a casi cualquier sistema de cifrado y parece que no hay solución más que cambiar los algoritmos y eso no es muy viable, imaginate cambiar todo el software por todos lados, incluso de equipos a los que no tenemos ningún acceso.
Entonces el director preocupadísimo pregunta ¿a ver cuéntenme cómo sería el ataque?. Y le contestan: bueno, primero habría que poner en el servidor un programa, hecho especialmente para robar las claves.
¡Un momento! dice el director: ¿o sea que hay que tener acceso al servidor para poder hacer eso?
Bueno, no acceso físico, es necesario que el atacante corra un programa en el servidor, le contestan.
¡Ah!, ¡entonces no pasa nada! No nos hemos gastado una millonada en sistemas de seguridad, hemos comprado hasta switchs carísimos para evitar la suplantación de mac, tenemos controles de acceso hasta en la puerta del baño, e investigamos hasta al personal de limpieza para asegurarnos de que no tiene antecedentes penales, para así garantizar la seguridad del centro de cómputos!
Hemos puesto todos los malditos firewalls y claves que nos pidieron en el análisis de seguridad. De hecho, pagamos a una empresa externa para que hiciera el análisis y cumplimos todas sus recomendaciones. Estoy harto de que el sistema me pida que cambie la clave a cada rato y no me deje poner claves de menos de 8 caracteres, y me fuerza a que contengan por lo menos tres números, y aún así me rechaza algunas porque dice que parecen palabras del diccionario (malditos sitema, no en qué diccionario ha visto que salgan los jeroglíficos que me invento... El maldito sistema recuerda todas las claves que he estado usando y no me deja repetir ninguna! Ya se me ha bloqueado la cuenta 3 veces en el último mes por escribir mal la clave.
Está tan cerrado todo que el otro día quise enchufar mi portátil en el puerto de red de la PC de mi oficina y el switch me desactivó la boca porque la MAC era diferente de la autorizada. Ustedes se perdieron toda la mañana cambindo cables y conectores hasta que descubrieron que era por la seguridad que no funcionaba.
Ustedes mismos me dijeron que todo esto era necesario y que sólo así estábamos adecuadamente protegidos contra intrusiones de todo tipo, así que eso deberá protegernos también del probelma este de las claves, que requiere primero acceder al sistema. Quiero un informe por escrito que diga que con la seguridad que tenemos es suficiente porque si no nos cortan la cabeza.
A continuación el director de informática vuelve a su oficina privada y llama por teléfono al gerente, que ya ni se acordaba del problema porque tiene muchos otros más inmediatos y le dic: sobre el problema del cifrado que me comentaba esta mañana. Ya lo hemos analizado a fondo y con las medidas de seguridad que implementamos el año pasado, el problema queda cubierto. No hay ningún peligro. Para mañana le tenemos un informe por escrito al respecto por si la junta directiva pregunta algo. De paso con eso van a ver que el gasto que se hizo el año pasado en seguridad era necesario.
Alejandro Nestor Vargas