Cómo de segura es la seguridad?
Buenas a todos,
llevo un tiempo consultando esta página y soy nuevo aquí. Últimamente se está notando un poco de paranoia en la red acerca de cómo de seguros son algoritmos como SHA-1 o AES. Con el primero, si no estoy mal informado, se están utilizando cosas como la "paradoja de cumpleaños", que reduce a casi la mitad el espacio de claves. Con el segundo ví anoche que también se está consiguiendo algo aunque no sé cómo exactamente.
Yo no sé si es que tengo una fe ciega o qué, pero quiero exponer mi razonamiento aquí para ver qué os parece. No sé si es una lucubración, pero la cosa es:
- Sea E el espacio de claves
- Sea L la longitud de la clave en bits
- Sea N el nº de operaciones que realiza la máquina la máquina atacante
- Sea T el tiempo
Premisas iniciales :)
- el espacio de claves crede exponencialmente según se aumenta la longitud de la clave (E = 2^L)
- el nº de operaciones que puede realizar la máquina crece linealmente con el tiempo (N = "un_número" * T + "otro_número")
Conclusión
el espacio de claves siempre va (o puede ir) con ventaja. Si aumenta la potencia de las máquinas y se ve factible un ataque, se aumenta la longitud de clave.
La mezcla de las dos premisas resulta un poco extraña, pero creo que no es tan descabellada. Digamos que alguien ataca con potencia lineal a alguien que se defiende con potencia exponencial :)
Un saludo
- Conecta o crea cuenta para participar
- 721 lecturas
Twitter
No van por ahi los tiros
La mayoría de los ataques exitosos no son ataques frontales de fuerza bruta contra todo el espacio de claves.
Normalmente se saca provecho de alguna debilidad del algoritmo o de su implementación, como ser el generador de números aleatorios, rastreo de interferencias electromagnéticas en el equipamiento de criptografía, variaciones en el consumo de energía, medición de los tiempos que toma encriptar distintos textos, análisis de fallas o reacciones ante datos inválidos, etc, etc, etc.
Aunque estas técnicas no revelen la clave directamente, a menudo pueden reducir el espacio de claves lo suficiente como para hacer factible un ataque de fuerza bruta en un tiempo razonable.
Tampoco hay que olvidar la ingeniería social, la extracción de claves apuntadas debajo del teclado, observar la pantalla con un telescopio desde el edificio de enfrente y otras técnicas más perversas como esta.
Pero
Tu mismo dices que lo que se consigue es reducir el espacio de claves. Espacio que crece exponencialmente....
Si obviamos técnicas ajenas a lo que es la criptografía (telescopios, keyloggers etc) y ataques por diccionario, aumentando la longitud de clave o de resumen hash se resuelve el problema (suponiendo un algoritmo bien diseñado). Es mucho suponer :) pero teóricamente, un ataque a un algoritmo bien diseñado debería ser inviable computacionalmente.
No siempre
No estás tomando en cuenta el factor humano.
Por ejemplo (y aunque no tiene mucho que ver con las claves criptográficas en si): Los passwords en Linux pueden ser de hasta 255 caracteres. Sin embargo, son personas las que seleccionan y utilizan los passwords. Personalmente he visto gente con passwords de más de 10 caracteres, aunque nunca supe de nadie que utilice más de 20. Podría decir con toda tranquilidad que es difícil encontrar a alguien que utilice apenas un 5% de la longitud máxima de un password (unos 12 caracteres), y en la práctica es bastante menos. Y eso sin ponernos a hablar de la calidad de la clave.
¿Aumentar el máximo de 255 a 1023 caracteres haría a Linux más seguro? Difícilmente.
Algunas organizaciones tienen paneles con teclados numéricos para acceder a ciertas áreas restringidas. He visto algunos de estos con 6 teclas como nuevas y 4 teclas muy gastadas.... Aunque el espacio de claves es de 10.000, una rápida inspección visual puede reducirlo a sólo 256.
Con respecto a los algoritmos de cifrado, puedes utilizar uno con claves de 4096 bits, pero si, por ejemplo, sabes que los primeros 4000 bits de la clave son "1010101010....", en realidad sólo tienes que romper los restantes 96 bits. Aunque el algoritmo funcione bién, una clave débil lo hará inseguro.
Una cosa es que un algoritmo esté bien diseñado, pero otra muy distinta es que esté bien implementado. La mayoría de los algoritmos acaban dependiendo de un generador de números aleatorios y más de uno ha demostrado ser más o menos predecible. Quizás no tanto como para adivinar los primeros 4000 bits de una clave de 4096, pero todo ayuda.
En SSL se utilizan algoritmos de encriptación razonablemente seguros, como DES y RC4, que junto con una longitud de clave razonable debería ser prácticamente irrompible. Sin embargo, los certificados utilizados en el handshake son validados mediante MD5, algoritmo que está totalmente roto, por lo que es factible un ataque tipo man-in-the-middle. Aquí, aunque el algoritmo de cifrado funciona perfectamente y puede hacerse más seguro aún con claves más largas, toda la seguridad falla por culpa de un componente secundario que ha quedado obsoleto.
En resumen: que si, que en condiciones ideales un algoritmo bien diseñado e implementado puede ser irrompible. Pero que sea irrompible no quiere decir que sea seguro. Cuando un componente que guarda lo que quieres obtener es imposible de romper, simplemente buscas otra manera y a menudo la encuentras.
Pero...
La criptografía no incluye únicamente el algoritmo a nivel lógico, sino que al final lo que cuenta son las implementaciones del mismo (obviando factor humano y demás).
Un ataque lateral de análisis diferencial de potencia lo que hace es basarse en el consumo de potencia de un dispositivo criptográfico (o radiaciones EM) para obtener partes de la clave. Los algoritmos criptográficos actuales suelen realizar operaciones con grupos de 6-8 bits de la clave, y esas operaciones proporcionan información vía consumo de potencia o radiación EM.
Aunque se pasara a usar un equivalente a AES con 1024 bits de clave, al final un ataque de este tipo sería 8 veces más complejo que un AES de 128 bits, pero seguiría siendo manejable.
Podemos argumentar que quizás en nuestro ordenador no se pueda aplicar este tipo de ataque... pero quizás pueda aplicarse desde otro usuario en la misma máquina un ataque basado en tiempos o cosas similares.
En fin, que aunque la seguridad del cifrado empieza teniendo un algoritmo resistente al criptoanálisis 'de toda la vida', no acaba ahí y hay muchos factores a tener en cuenta.
Saludos
PD: En unas semanas tendrá lugar el CHES 2009 ( Workshop on Cryptographic Hardware and Embedded Systems , http://www.chesworkshop.org/ ) para los interesados en el tema :)
Al menos en AES...
Si no me equivoco la debilidad que se ha señalado en AES hace poco afecta más a claves largas que a cortas (creo que a partir de 128bits).
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
"No hay nada repartido de modo más equitativo en el mundo que la razón: Todo el mundo está
convencido de tener suficiente"
René Descartes
"Recela de todos aquellos cuya tendencia al castigo es poderosa."
Friedrich Nietzsche
más
En cuanto a lo que dice Andy, creo que linux almacena el hash de la contraseña en lugar de la contraseña en sí, por lo que si se aumenta la longitud, se aumenta la seguridad no? en teoría...
En el caso de SSL y md5, no debería ser así, ya que durante el handshake se negocian los algoritmos según los que soporta cada extremo. Un certificado lo puedes firmar con lo que quieras, al igual que la firma del mensaje FIN del protocolo (esto último lo supongo por lógica).
Así que bueno, si no me equivoco, la cosa quedaría:
En teoría un algoritmo bien diseñado es imposible de romper por complejidad computacional, pero:
- Está la implementación del mismo. En este campo yo soy analfabeto. Técnicamente es posible implementarlo tal cual está diseñado? Debería haber implementadores de algoritmos criptográficos?:)
- Están los ataques laterales, como lo que dice KriptoCuenta del análisis de potencia en dispositivos, keyloggers etc
- Está el factor humano, que me atrevería a jurar que tiene solución
- Está la picardía, como teclas desgastadas, telescopios e interrogatorios :)
- Y en general, la seguridad en las máquinas origen y destino
Visto así ya no parece tan seguro :)
Por otro lado, el tema de AES, si es posible romper una clave de 256 pero no una de 128, eso indica que la implementación de uno y otro es distinta no? Es decir, que no es que hayan cogido AES-128 y lo hayan escalado a AES-256, sino que han cambiado la implementación. Eso no es un poco cutre?
Por otro lado, el tema de las colisiones en funciones hash, es realmente viable conseguirlo en la práctica y obviando el tiempo?
Es decir, supongamos que tengo un documento firmado y alguien se pone a buscar una colisión. Es factible encontrar un documento que no sea sospechoso? El tío tendrá que ir cambiando caracteres, añadir espacios etc etc hasta encontrarla, y parece lógico pensar que el documento encontrado como colisión no sea legible o sea sospechoso a la vista.
Eso sin pensar en el tiempo que requiere cambiar el documento, hacer el hash y comparar, y sin contar con que además esa firma debe ser comprobable con la clave pública del infeliz, clave que puede ser RSA (y aquí volveríamos al inicio del post :)
Parece que la seguridad es un poco como las mujeres, cuando crees que la tienes calada te sorprende con algo nuevo...
mmm
Respecto a lo que dice Andy, hay que tener en cuenta que por ejemplo en el caso de WPA-PSK y WPA2-PSK en redes inalámbricas, el protocolo genera un hash a partir de la PSK inicial de forma recursiva y concatenando números aleatorios, por lo que el factor humano digamos que se pierde si se quiere, con una buena frase de paso.
Creo que linux (o alguna versión) también almacena el hash de la contraseña en lugar de la contraseña en sí, así que, si se aumenta la longitud del hash, se hace más seguro (en teoría...).
Por otro lado, un certificado electrónico se firma con MD5 si quieres. Nada te impide firmarlo con SHA-1, SHA-2, DSA, ElGamal etc. Hay que tener en cuenta que durante el handshake se negocian los algoritmos y perfectamente se podría utilizar SHA-1 (que sííí, que este algoritmo empieza a chochear), AES y RSA.
A pesar de esto estoy deacuerdo con la parte de "En resumen:" :) sobretodo por cosas como la que dice KriptoCuenta, del análisis de potencia, y separar el algoritmo de la implementación. Está claro que no todo se reduce a la seguridad del algoritmo matemático, sino que vivimos en un mundo real.
Y lo que dice Flood, es increíble que con 256 bits de clave sea más inseguro que con 128. Eso demuestra que el algoritmo no es el mismo no? Quiero decir el mismo en todos los aspectos. Si ese artículo está en lo cierto es que algo cambia en él de 128 a 256.
En resumen :)
un algoritmo bien diseñado debe ser inmune al criptoanálisis por complejidad computacional. Sin embargo tenemos la seguridad en los extremos de la comunicación, que es lo que hace posible un ataque. Y la implementación del algoritmo...
Pues entonces estamos de acuerdo
Hola Sergius,
Si te fijas en mi primer comentario, es justo lo que yo he puesto:
Asi que va a ser que estamos de acuerdo.
Con respecto a la firma de certificados electrónicos, es verdad que se puede utilizar cualquier otro algoritmo, pero el 99% de los que andan ahí fuera (incluyendo bancos) están firmados y son verificados con MD5.
Otra vez en resumen: puedes tener el mejor algoritmo de encriptación del mundo, totalmente irrompible hasta que no salgan procesadores de 5000 GHz. Pero eso poco importa ya que casi siempre el algoritmo no es el eslabón más débil y puestos a romper un sistema, se comienza por lo más fácil.
Si instalas una puerta totalmente inviolable en tu piso, intentarán por las ventanas. Si las ventanas también son inviolables, entrarán en el piso de al lado y harán un hueco en la pared. Si esto tampoco es posible, siempre queda el recurso de robarte o hacer un duplicado de tus llaves, amenazarte para que abras la puerta, sobornar a algún familiar/amigo que tenga acceso a tu casa, etc. No verás a ningún profesional intentando inútilmente romper la puerta.
Saludos,
Andy
Only amateurs attack machines; professionals target people. Bruce Schneier
vale
pensando que no había llegado volví a escribir...
pido disculpas por ello a los oyentes...
si
es cierto que por ahí andan un montón de certificados con md5. Error humano :) Ademas, muchos están instalados en los navegadores sin proteger por contraseña ni nada, y sin entrar en detalles de cómo protege windows los certificados.
Digo sobretodo gente de a pié que siempre va a lo más cómodo, trabajadres de empresas que facturan miles de millones (en estos momentos trabajo en un help desk) .....
Y además de todo lo que se ha dicho aquí tu recuerdas, ya tengo los ojos un poco más abiertos, ya veo un poco de luz :)
un saludo