Cada nueva filtración sobre la NSA nos hace cuestionarnos más todavía la seguridad de nuestras comunicaciones a través de Internet. Certificados filtrados, ataques criptográficos… ¿Hasta qué punto puede ser cierto todo esto? ¿Cómo pondría todo en marcha la NSA?
Hemos querido dar respuesta a esas y más preguntas, y por eso desde Genbeta hemos querido contar con tres expertos en seguridad que nos expliquen todo con precisión y claridad: Chema Alonso, Alfonso Muñoz y Yago Jesús.
HTTPS: cómo escucha la NSA las comunicaciones seguras y cómo protegerlas
Alfonso Muñoz nos explicaba cómo el problema empieza desde el uso de la clave pública (énfasis mío).
Cuando te comunicas con un tercero no tienes la garantía de que la clave pública del destinatario es precisamente de él. Puede que un tercero intercepte la comunicación, se ponga en medio (man in the middle), y nos dé su clave pública haciéndose pasar por el receptor. Para evitar esta situación se necesita una tercera parte de confianza que nos diga si una clave pública es precisamente de quién dice ser.[…]La seguridad de todo el sistema recae en la confianza en terceras partes, autoridades de certificaciones. Aquí de nuevo surge un problema, necesitamos saber cuál es la clave pública de una o más autoridades de certificaciones, pero no los la pueden enviar porque de nuevo sería factible un ataque de hombre en el medio. Para evitar esto los navegadores web vienen configurados de “fábrica” con certificados públicos de las autoridades de certificación más famosos a nivel mundial. Lógicamente la seguridad de todo el sistema recae en la confianza que tengamos en esas CAs.
¿Cómo podemos detectar esos ataques? Los tres expertos coinciden en que la mejor idea es
verificar que el certificado no cambia. Yago Jesús y Alfonso Muñoz sugieren
Certificate Patrol, una extensión para Firefox que avisa cuando cambian los certificados. También está EMET, una herramienta de Microsoft que explican en
Eleven Paths. El problema de ambas es el mismo: el encargado de interpretar la alerta por un cambio de certificado es el usuario. Puede que sea un ataque real o haya habido un cambio legítimo en el certificado. No son herramientas al alcance de todos los usuarios.
Por eso, hemos querido preguntar
qué habría que cambiar en HTTPS y el modelo de infraestructura de clave pública para no depender tanto de las CAs. La primera idea, recomendada por los tres, es minimizar riesgos no confiando en CAs de ciertos países poco fiables usando
SSLCop (desarrollada por Yago Jesús).
Existe también el proyecto
Convergence, que pretende crear
CAs distribuidas donde los usuarios votan las más fiables. Sin embargo, no parece una idea que pueda extenderse mucho. Yago nos comenta problemas que puede tener esta implementación, principalmente el hecho de que una CA de Convergence no tendría tantas garantías
ni estaría tan auditada como las CA actuales.
Por último, Chema Alonso nos apunta también al
Certificate Pinning, un concepto que consiste en recordar las cadenas de confianza de los certificados SSL, de tal forma que el navegador alerte y rechace conexiones con certificados modificados. La idea es la misma que la de Certificate Patrol o EMET, aunque si se busca modificar toda la infraestructura de CAs hay que encontrar algo más integrado que un añadido al navegador.
¿Existiría la posibilidad de deshacernos de ese paso que tanto parece molestarnos, el de la confianza? Parece que no. Los tres coinciden en que no hay forma de hacerlo, no podemos confiar únicamente en el algoritmo.
Criptografía y algoritmos de cifrado
Cada vez se extiende más una duda razonable sobre los algoritmos de cifrado que usamos, muchos creados bajo la influencia de Estados Unidos. Los estándares de criptografía GOST, de origen ruso/soviético, podrían sustituir o complementar los algoritmos principales: son robustos y ofrecen garantías, según Yago.
Chema Alonso nos comenta que los algoritmos están sometidos al escrutinio mundial, y es más probable que sean las implementaciones las que tengan problemas. En el mismo sentido habla Alfonso Muñoz: además de que no todos los algoritmos son norteamericanos (AES, para cifrado simétrico, está basado en un algoritmo belga, Rijndael), todos son examinados por muchos expertos alrededor del mundo.
Hemos querido saber cómo se ejecutan esos algoritmos de fuerza bruta. Chema Alonso:
La ruptura de claves por fuerza bruta requiere de una reducción previa del espacio de posibilidades para que se pueda hacer en tiempo útil. La posibilidad de inferir el valor de un bit divide por dos el tiempo que tarda en efectuarse el cracking. Lo más probable es que utilicen fuerza bruta, pero con algoritmos de reducción del espacio previos.
Sin embargo, la viabilidad o no de un ataque por fuerza bruta depende del algoritmo. Alfonso nos explica que hacer fuerza bruta sobre AES con claves de 128 bits llevaría un tiempo equivalente a la edad del universo. Eso sí, hay otras formas de obtener la clave, como ataques basados en diccionario o rainbow tables.
El problema reside más en los algoritmos de clave pública, comenta. RSA depende de un problema matemático, el de la factorización de productos de primos, y “es difícil aventurar qué tienen y qué no”, así posiblemente claves de 1024 bits ya no sean recomendables.
Sobre las
capacidades de la NSA para romper las claves, Yago Jesús aplica la lógica a la historia de la criptografía:
Aquí aplica la lógica. En la era de los 90 el criptoanálisis era la escuela más difundida. El objetivo era revertir el algoritmo al estilo ‘máquina Enigma’. En esa época había muchas restricciones en el uso de la criptografía y su exportación. Tal vez la gente recuerde esos navegadores ‘capados’ en cuanto a criptografía con los que nos obsequiaban desde EEUU.Luego, mágicamente, esas restricciones fueron levantadas y el uso de criptografía ‘fuerte’ se pudo usar ampliamente. ¿Casualidad? En mi opinión coincide con el auge de los procesadores ultra-optimizados para operaciones matemáticas. La fuerza bruta.Lo que tengo muy claro es que cualquier algoritmo que se pueda usar en el mundo civil, está ahí porque existen contra medidas para romperlo.
Ahora bien, ¿puede haber algo detrás,
algo más que la fuerza bruta, para romper algoritmos? Desde luego, existir existe. Yago nos explicaba el ejemplo del troyano Flame: sus creadores habían descubierto un ataque de colisión a MD5 que
les permitió falsificar certificados. También existen ataques contra las implementaciones, como el caso de
MS-CHAPv2; o contra algoritmos hechos a medida como los generadores de números aleatorios: véase el caso de
Dual EC DRBG.
Algunos algoritmos han tenido puertas traseras, pero tampoco hay que mitificar las capacidades de la NSA.
Sin embargo, también hay que desmitificar las capacidades de agencias como la NSA. Según Alfonso Muñoz:
Creo, y decir esto en estos tiempos puede sonar raro, deberíamos desmitificar las capacidades de ciertas agencias en relación con la criptografía. Este tipo de organismos se caracterizan por tener suficiente tiempo y dinero para “resolver problemas” lo cual es muy interesante en aquellos escenarios donde los “aspectos cuantitativos” [ataques por fuerza bruta] sean importantes.Sin embargo, no tengo claro que dinero y tiempo sean suficiente para resolver aspectos cualitativos. Para anular ciertos algoritmos criptográficos modernos se necesitaría un nuevo conocimiento en matemáticas para lo cual, además de lo anterior, sería necesario las mentes más brillantes del planeta, y por muchos motivos estas agencias no son poseedores de “todas ellas”.
Protegernos de la NSA, y el papel del software libre en todo esto
¿Qué podríamos hacer si nosotros somos fuésemos un objetivo de la NSA? ¿Cómo podemos protegernos? Lo cierto es que es difícil. Chema nos comenta que quizá usando criptografía simétrica de punto a punto sería posible, usando sistemas como PGP pero, eso sí, vigilando las implementaciones. Sin embargo, parece difícil. “Podemos protegernos frente a ataques masivos pero frente a ataques dirigidos, es cuestión de tiempo y dinero”, según Alfonso, y Yago nos lo resume con una buena analogía:
Tomando como ejemplo el ya famoso juego GTA, depende del número de ‘estrellas’ que tengas activadas. Si eres un objetivo menor/medio que no llama la atención excesivamente, tal vez la criptografía pueda ponerte a salvo. Si tienes las 5 estrellas activadas, no hay salida.
Y otra cuestión muy interesante:
¿puede protegernos el software libre de todo esto? Es conveniente, pero no suficiente, apunta Alfonso Muñoz: importa mucho más la calidad de los ojos que miran el código que cuántos ojos lo miran. “No es trivial analizar un código ni todo el mundo tiene la capacidad para hacerlo con ciertas garantías.”
De hecho, ya hubo problemas en otros proyectos de código abierto. Yago Jesús nos explica los problemas en
OpenSSL y
OpenBSD, y Chema Alonso comenta que
el tema está muy turbio.
Aunque el software libre puede ayudar, tampoco es la panacea ni la salvación absoluta.
Mención aparte merece el caso de
TrueCrypt. Chema y Yago coinciden en que
las dudas son razonables, aunque Alfonso se muestra más precavido a la hora de lanzar especulaciones al aire – “Es conveniente que la gente pruebe sus afirmaciones. Se puede producir el efecto contrario: que la gente no use software de protección de este tipo o desarrolle mecanismos propios inseguros” -. Eso sí, reconoce que no parece existir ningún análisis en profundidad del código fuente de la herramienta.
Esperamos que este artículo os haya aclarado las dudas que pudiéseis tener sobre seguridad a raíz de las filtraciones de la NSA. Y, antes de acabar,
agradecemos de nuevo a Chema Alonso, Yago Jesús y Alfonso Muñoz sus respuestas para este artículo. También os dejamos con las
respuestas completas que nos enviaron, que creo que pueden resultar muy interesantes.
Fuente: www.genbeta.com
