Fecha: 25 Marzo 2001


La seguridad es un proceso, no un producto. Y pocos ejemplos pueden rivalizar con PGP. A lo largo de los años, el programa de "tío Phil" ha resistido el escrutinio de la comunidad criptográfica mundial. De hecho, una declaración del tipo "he descubierto el siguiente fallo en PGP: ..." se ha convertido en receta infalible para obtener fama y reconocimiento ... o el desdén más absoluto por propagador de bulos.

Por ello, cuando el 20 de Marzo de 2001 un grupo de criptógrafos checos afirmaron haber descubierto una grave vulnerabilidad relativa a las claves de firma de PGP, no pocos lo consideraron uno de tantos propagadores de FUD (iniciales en inglés de Temor, Incertidumbre y Duda). Sin embargo, los análisis iniciales parecen indicar que el fallo es real.

Debido a ello, y a pesar del escaso tiempo transcurrido, he decidido redactar el siguiente Informe de urgencia. Soy consciente de que el tema sigue abierto, pero considero necesario aclarar el tema hasta donde sea posible con el objeto de alejar rumores y exageraciones.


En pocas palabras

El ataque presente, propuesto por Vlastimil Krima y Tomás Rosa, de la empresa checa ICZ, aprovecha ciertas sutilezas asociados con el modo en que PGP (y, de hecho, cualquier programa compatible con el formato OpenPGP) almacena las claves privadas.

Dicho eso, será mejor comenzar por lo que NO significa este "ataque checo" (permítaseme bautizarlo así). No es un ataque criptoanalítico contra ninguno de los algoritmos empleados. Es decir, ni los algoritmos de cifrado simétrico (IDEA, CAST...), ni los de cifrado asimétrico (RSA, Diffie-Hellman), ni los de destilado o "hash" (MD5, SHA-1), ni los de firma han sido atacados. No es un ataque que permita descifrar mensajes.

Más bien es un fallo de implementación, al estilo del ya famoso "ADK bug" descubierto por Ralf Senderek en Agosto pasado (ver Informe 24: Agujero en PGP). En el caso que nos ocupa, un atacante con acceso al archivo de claves privadas secring.skr puede modificarlo de forma tal que puede deducir la clave de firma.

¿Preparados? Pues vamos allá.


Un poco de matemáticas

Si usted sigue aquí después de haber leído la palabra "matemáticas", una de dos: o no les tiene miedo, o ya me conoce de anteriores Informes y confía en que mantendré la presente explicación lo más sencilla posible. Efectivamente, voy a intentar hacérselo fácil. Aunque algo de mates sí que habrá que meter. De todos modos, no es necesario que se trague este rollo. Le servirá si lo hace, pero si está peleado con las mates, limítese a saltar al siguiente apartado.

Le supondré familiarizado con el concepto de criptografía de clave pública. Como su nombre indica, se basa en diversos parámetros matemáticos relacionados entre sí, algunos de estos parámetros son públicos, y otros secretos. El hecho de que en la práctica no sea viable obtener los parámetros secretos partiendo de los públicos -aún cuando en teoría es posible- hace que la criptografía de clave pública sea posible.

Lo que vamos a hacer es estudiar uno de los algoritmos de firma: el denominado DSA (Digital Signature Standard), que es el que se usa para "firmar" con una clave del tipo Diffle-Hellman/DSS. Aunque el ataque checo también se aplica a las claves de firma RSA, el método es distinto ... y bastante complejo.

Para crear un par público/privado de claves de firma DSA se seguirán los siguientes pasos:

La pareja de parámetros (r,s) constituye la firma digital.

Un atacante malicioso que pudiese conocer el valor de k podría calcular el de x despejando su valor en el paso 4 del proceso de firma. ¿Y cómo podemos conocer k? En teoría, despejando del paso 2 en el proceso de firma. En la práctica, "despejar" implicaría un cantidad de cálculos superior a la que podemos permitirnos.

Y aquí entra el ataque checo. ¿Recuerdan que los valores (p, q, g) son conocidos? Pues supongamos que reemplazamos p y q por dos valores distintos p´ y q´. Estos números se escogen de forma que el paso 2 del proceso de firma es fácilmente invertible. Esto significa que podemos obtener k con bastante facilidad. Y, puesto que conocemos los demás parámetros (el mensaje m, su hash h(m) y la firma r´,s´), podemos deducir x. Puesto que x era el parámetro secreto, ya podemos firmar mensajes impunemente. Fin de la historia.

En el caso de la firma mediante clave RSA, el procedimiento es distinto, pero tambíen se basa en sustituir unos parámetros de la parte pública de la clave por otra.


El ataque en la práctica

Por si se saltó el apartado anterior, recapitulemos. Una clave de firma tiene parámetros públicos (p, q, g) y secretos (x). Un atacante que consiguiese sustituir dichos parámetros públicos por otros (p´, q´, g) cuidadosamente escogidos podría averiguar el parámetro secreto x, lo que le daría la facultad de poder falsificar firmas impunemente.

Este ataque, interesante en teoría, debería tener pocas repercusiones en las implementaciones de PGP. A fin de cuentas, todos esos parámetros -públicos y privados- están contenidos en el archivo de claves privadas secring.skr. Y, como todos los usuarios sabemos, dicho archivo está cifrado, de manera que sería imposible extraer información o alterarla, ¿no?

Bien, prepárese para una sorpresa. En un archivo secring.skr, solamente el valor de la clave privada está encriptado. Todo lo demás, incluidos los parámetros públicos, está "al aire", sin cifrar. ¿Por qué, se preguntará usted? Bien, por una sencilla razón: porque los parámetros públicos son públicos. No es un retruécano. Recuerde que en un sistema de clave pública seguro, los parámetros públicos pueden ser conocidos por todos sin que disminuya la seguridad. De hecho, esos mismos parámetros públicos están en la clave pública, la que almacena usted en el archivo pubring.pkr. Esa clave pública es la que usan los demás para enviarle a usted mensajes cifrados, de manera que pueden incluso estar en un servidor de claves, sin problema.

Lo realmente importante es que dichos parámetros no se puedan cambiar sin que dicho cambio sea detectado. Esa es su protección. Si intentásemos cambiar los valores de los parámetros públicos que hay en la clave pública, inmediatamente saltaría la alarma (recordemos que las clave públicas van auto-firmadas precisamente para evitar alteraciones).

¿Y qué hay de la clave privada? Allí también hay una copia de los parámetros públicos. ¿Podemos alterarlos ahí? Sí. ¿Podemos hacerlo de manera que la alteración pase desapercibida? Sí. ¿Por qué? Pues porque no hay ninguna comprobación de integridad, es decir, no hay ningún mecanismo que permita detectar cuándo los parámetros públicos existentes en la clave privada son alterados.

Y ese es el meollo de la cuestión: el ataque resulta en la práctica posible en entornos PGP no porque los parámetros públicos pueden ser leídos, sino porque pueden ser alterados impunemente.


Sistemas afectados

Los autores probaron este ataque en la práctica usando PGP versión 7.0.3, con una combinación de claves AES y DH/DSS. Sin embargo, puede ser aplicable a cualquier sistema híbrido (que use combinaciones de criptografía simétrica y de clave pública) en el que no se compruebe la integridad de los parámetros públicos, como hemos dicho anteriormente. Es decir, a cualquiera en el que podamos sustituir unos parámetros públicos por otros sin ser detectados.

Esto incluye no solamente el programa PGP propiamente dicho, sino todos los programas compatibles con el formato OpenPGP (RFC 2440: OpenPGP Message Format), entre los que se incluyen la versión GnuPG. Los autores comentan, eso sí, que un ataque contra claves RSA en el programa PGP no es viable debido a que dicho programa tiene mecanismos incorporados para comprobación de integridad.

Pero por otro lado, recordemos que las claves RSA no tienen dos tipos diferentes de claves (una para firmar, otra para cifrar). La misma clave sirve para firmar y para cifrar. Esto significa que, si consiguiésemos obtener la clave privada, podríamos no solamente falsificar mensajes sino descifrarlos. Resulta cuando menos una cruel ironía para aquellos inconformistas que nunca se han fiado de las nuevas claves Diffie-Hellman/DSS y han permanecido fiel a sus viejas claves RSA. No quiero ni pensar lo que sucedería si esta vulnerabilidad pudiese aplicarse a las conexiones seguras por navegador (SSL), que hoy día forman la columna vertebral del comercio electrónico.

Y ahora, ánimo, que viene la parte buena.


Limitando el pánico

El ataque checo puede obtener la clave de firma si se dan ciertas condiciones, pero eso no significa que haya que tirar a la basura todo lo que lleve las siglas PGP. Es esencial poner las cosas en perspectiva, y en función de ello decidir lo que hay que hacer.

Para empezar, enumeremos lo que un atacante necesitaría. En primer lugar, debe tener acceso a nuestro archivo de clave secreta, secring.skr. Debe ser capaz de obtener dicho archivo, modificarlo, devolverlo a su lugar, esperar a que el usuario firme un mensaje, obtener dicho mensaje y su firma, ejecutar las operaciones precisas, restaurar el archivo a su estado originar y devolverlo a su lugar.

Esto significa que los mensajes cifrados, o cifrados y firmados, no son vulnerables. Únicamente en los casos en que solamente se firma habría riesgo. ¿Significa eso que ya no hay que firmar mensajes? Eso depende de usted y de su nivel de paranoia.

Sin embargo, un atacante con acceso al archivo secring.skr puede intentar ataques menos sofisticados y más efectivo. Puede, por ejemplo, usar un ataque de diccionario: probar multitud de frases de contraseña hasta dar la correcta; en muchos casos, los usuarios escogen frases o palabras sencillas, lo que hace que el ataque de diccionario sea deprimentemente eficaz. También se puede instalar en el ordenador de la víctima un capturador de teclado (keylogger), o introducir un troyano que capte dicha contraseña y la transmita al exterior...

Los expertos en seguridad siempre han aconsejado no confiar solamente en la fortaleza de la contraseña o en el hecho de que el archivo secring.skr vaya cifrado. Bruce Schneier compara la seguridad informática con una valla. PGP representaría una estaca de un kilómetro de altura. Discutir sobre si la clave ha de tener 1.024 o 2.048 bits es como decidir si la estaca tiene un kilómetro de altura o kilómetro y medio. Pero ¿y el resto de la valla?

Ningún ladrón atacará una puerta acorazada a prueba de misiles si le basta con tirar un ladrillo para romper un cristal y entrar por la ventana. Del mismo modo, al malo de la película nunca se le ocurriría darse de bruces contra el algoritmo simétrico, o incluso complicarse la vida con el ataque checo, si tuviese medios más sencillos a su alcance.

¿Y quién es responsable de este desaguisado? No faltará quienes vean oscuros intereses. ¿Estará la poderosa NSA tras todo este embrollo? ¿Habrá sucumbido NAI, propietaria de PGP, a las presiones gubernamentales, o simplemente a las comerciales? Personalmente, no creo tal cosa. Es cierto que las agencias en la sombra han intentado una y otra vez socavar los desarrollos criptográficos comerciales. Pero me cuesta creer que este sea el caso. En primer lugar, una agencia de espionaje electrónico podría estar interesada en descifrar mensajes ajenos, pero ¿qué ganaría suplantando firmas digitales? Dado el impacto del e-business en nuestros días, socavar el sistema de firma digital conllevaría enormes perjuicios económicos y ninguna ventaja.

En segundo lugar, recordemos que este ataque no se restringe a PGP. De hecho, es extensible a todos los sistemas que operan bajo OpenPGP, un formato abierto a escrutinio y donde las agencias gubernamentales han tenido poca participación, si es que la han tenido. !Pregúnteles a los desarrolladores de GnuPG si están bajo nómina, a ver qué les responden!


Contramedidas

Cualesquiera que sean sus consecuencias prácticas, el ataque checo desvela una vulnerabilidad que es preciso afrontar. No solamente PGP, sino cualquier sistema que implemente cifrado "híbrido" puede verse potencialmente afectado. En particular, espero ver las posibles repercusiones en sistemas tales como S/MIME o SSL.

Pero no podemos abarcarlo todo, así que vamos a ver cómo podemos blindar nuestro programa de cifrado favorito. Los autores del ataque checo, al final de su artículo, sugieren algunas comprobaciones adicionales que pueden hacerse para verificar que los parámetros públicos no han sido alterados. No son una solución satisfactoria, pero sí pueden servir como medidas temporales en tanto que se resuelva el problema sustancial (la no comprobación de integridad). En este sentido, no me sorprendería ver en los próximos días parches que implementen estas comprobaciones. No me cabe duda de que los técnicos de NAI estarán trabajando contra reloj en estos momentos. Sin embargo, a la fecha en que escribo estas líneas (domingo 25) aún no he tenido noticias al respecto.

En cuanto a los demás programas que se basen en el formato OpenPGP, deberán ser comprobados uno por uno, y el propio formato habría de ser modificado. Tarea pesada, pero ese es el precio a pagar por la seguridad. El código fuente y la política de transparencia son grandes aliados en la búsqueda de fallos, pero después hay que corregirlos. En este sentido, podemos considerar el ataque checho como una validación de esta política. En un sistema de código cerrado y cerrado, esta vulnerabilidad podría muy bien no haber sido nunca descubierta.

Mientras tanto, podemos dar desde este Taller de Criptografía algunas recomendaciones para los usuarios de PGP en particular y sistemas basados en OpenPGP en general. Mi consejo es sencillo: no guarden sus archivos de claves en lugares públicamente accesibles. Esto significa almacenarlas en disquetes, o mejor, en unidades de disco cifrado. Existen programas como PGPdisk o Scramdisk que permiten hacerlo. Otra medida de seguridad podría consistir en firmar digitalmente el archivo de claves secring.skr, o incluso cifrar todo el archivo mediante una opción de cifrado de archivos (como la que incorpora el propio PGP).

Precauciones como éstas resultan especialmente aconsejables en redes de ordenadores o sistemas de acceso compartido. Pero incluso si se encuentra usted tan tranquilo en su casa, puede ser vulnerable a intrusiones cada vez que se conecta a Internet. Por ello, sería aconsejable que se fuese planteando (y no solamente a causa de este fallo) otras medidas de seguridad: programas antivirus, cortafuegos, detectores de intrusión, etc. Está muy bien acorazar la puerta, pero preocúpese también de las ventanas, la chimenea, el sótano, los desconocidos disfrazados de operarios del gas, los paquetes sospechosos...

Si este "ataque checo" ha demostrado algo es la necesidad de dotarse de una protección amplia. Protegerse contra troyanos o intrusos juguetones resulta más útil y eficaz que preocuparse por ataques criptográficos esotéricos o por si los hombres de negro necesitarían diez mil o veinte mil años en reventar mis claves.

El propio Philip Zimmermann, en declaraciones a Wired News, quita hierro al ataque checo e intenta poner las cosas en su correcta perspectiva: