El problema encontrado en OpenSSL de Debian puede ser considerado,
lamentablemente, un verdadero acontecimiento criptográfico. La
criptografía es una ciencia compleja, y con el ánimo de aclarar las
graves y extensas consecuencias del fallo, hemos redactado una serie
de preguntas frecuentas para intentar, aun tratándose de un tema tan
complejo, arrojar algo de luz.
¿Qué ha pasado exactamente?
Alguien (por error) del equipo de Debian eliminó una línea de código
en el paquete OpenSSL de Debian que ayudaba a generar la entropía al
calcular el par de claves pública y privada. Las claves sólo se
calculaban tomando como semilla el PID del proceso. Al estar limitado
a 32.768 semillas (tantos como PIDs de proceso son posibles) para la
generación de números seudoaleatorios, el número de claves posibles es
pequeño. Se han estado generando las mismas claves dentro de este número
limitado de posibilidades desde septiembre de 2006. Como son pocas y de
entropía pobre, se puede deducir la clave privada a partir de la pública
porque el espacio de primos es muy pequeño y está precalculado. Ya se
han generado listas disponibles para todos con la clave pública (del
espacio a que han quedado limitado después del fallo) y su
correspondiente privada. Para los usuarios de este OpenSSL de Debian
sin entropía suficiente, se han roto las reglas de la criptografía
asimétrica en la que por ahora confiamos todos y que sustentan las bases
de la (poca) seguridad y confianza que pueda existir en Internet.
¿Es tan grave como parece?
Es más grave. Mucho más grave. Podríamos considerar que la criptografía
de Debian en los últimos dos años ha sido una pantomima. Y es grave
además porque no se resuelve por completo parcheando. Esa no es la
solución definitiva. Hay que regenerar claves, revocar las antiguas,
certificarlas en el caso de SSL, comprobar dónde fueron a parar claves
generadas con Debian... No es un bug en un programa que eventualmente
quedará obsoleto porque todo el mundo estará parcheado. Habrá
administradores que no comprueben la debilidad sus claves, servidores
SSL que jamás certifiquen de nuevo sus claves, claves perdidas de
usuarios que dejen la puerta abierta a servidores SSH... También es
grave porque arrastra a decenas de programas y sistemas que se valen de
claves generadas con OpenSSL. SSL, SSH, OpenVPN, DNSSEC... Alguien lo
ha calificado de "apocalipsis criptográfico". Además los principales
perjudicados son los servidores que precisamente hayan buscado más
seguridad con la criptografía de clave pública, porque contenían
información crítica.
El SANS Internet Storm Center ha elevado el nivel de alerta general a
'amarillo'. No ocurre a menudo.
¿Cómo ha podido ocurrir?
Ha sido todo un desafortunado error. Aunque surgirán las teorías
conspiratorias porque el código abierto ha estado ahí durante dos años,
no ha sido hasta que Luciano Bello se ha dado cuenta que se ha corregido
el fallo y se ha dado la voz de alarma. Pero el daño ya está hecho. Dos
años de claves débiles generándose en cientos de miles de sistemas. Ha
pasado desapercibido porque en general cualquier programa es complejo,
pero la criptografía lo es aún más. Además, Bruce Schneier dijo algo así
como 'Good security looks the same as bad security' ('La buena seguridad
se ve igual que la mala', frase aplicable aún más a la criptografía).
Kurt Roeckx fue quien planteó en un principio borrar líneas que
consideraba problemáticas. Existe un correo de 2006 en una lista
pública, en el que Roeckx plantea en una lista de OpenSSL qué pasaría
si las eliminara. Pregunta si resultaría en una posible pérdida de
aleatoriedad. La respuesta no oficial desde OpenSSL es que "no mucho" y
que es partidario de borrarlas si ayuda en la depuración. Y era cierto,
esas líneas no suponían problema: el problema es que en Debian se
borraron más líneas de la cuenta, de las habladas en la conversación
y para colmo los cambios no se enviaron a OpenSSL para que fueran
revisados.
¿Se soluciona parcheando?
No. No se trata de un fallo de seguridad al uso. Ha existido una fuente
de claves inseguras que se han esparcido durante dos años. Hay que
comprobar y regenerar claves. El fallo fue anunciado a la vez que el
parche, pero hay que tener en cuenta, que las primeras versiones de los
parches para Debian y Ubuntu contenían regresiones. Han publicado nuevas
actualizaciones para los propios parches que es necesario aplicar
también.
¿Qué pasa si tengo un servidor web con acceso por HTTPS?
Si las claves han sido generadas con la versión de OpenSSL con el
problema, las consecuencias son que alguien se puede hacer pasar por el
servidor porque tendrá la privada de forma instantánea a partir de la
pública. Además, cualquiera que haya tenido acceso a una conversación
cifrada con el servidor, podría también descifrarla. Esto es así porque
la clave simétrica que se utiliza para el cifrado ha sido intercambiada
con la ayuda de claves asimétricas débiles. Un administrador debe además
revocar la clave, generar una nueva, enviarla a la Autoridad
Certificadora (que cobra por certificar) e instalarla. La catástrofe
hubiese sito total, si una Autoridad Certficadora, hubiese generado
claves y firmado certificados con estas claves débiles, pues el problema
se extendería hacia abajo a todos sus clientes, en cuyos certificados ya
no se podría confiar. Al parecer han comprobado que las principales
Autoridades no se ven afectadas.
¿Qué pasa con SSH?
Los administradores que controlan sus sistemas a través de SSH se suelen
autenticar a través de su clave privada y el servidor de SSH almacena la
pública correspondiente. Esto es más seguro que usar una sola contraseña
simétrica para autenticarse. El servidor cifra una cadena con la clave
pública del que pretende autenticarse y se la envía, si puede
descifrarla le deja pasar. En este caso puede que la clave pública sea
realmente pública o no. En el primer caso, deducir la privada es
instantáneo, y en el segundo caso, si no se conoce la pública, se debe
hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño,
algo que tarda unos 20 minutos con un ordenador de hoy día. Se ha creado
un exploit para esto.
Todos los administradores que permitan a sus usuarios utilizar la clave
privada para acceder a sus sistemas a través de SSH, deben auditar las
claves para saber si son de las "débiles". Los administradores de SSH
también se encuentran ante una tarea concienzuda, peligrosa, (y que
deben emprender ya) incluso si no utilizan Debian, porque puede que sus
claves hayan sido generadas en una distribución Debian y exportadas.
Los administradores de SSH comprobarán, con total seguridad, como los
intentos de acceso ilegítimo se multiplican en estos días.
¿A Windows le pasó lo mismo?
No. Se demostró que el generador de números aleatorios de Windows era
débil, pero la diferencia es que según el estudio, había que conocer el
estado previo del generador para saber el siguiente cálculo. Esto podría
permitir descifrar conversaciones SSL entre dos sistemas. Pero para
poder llegar a tener acceso a esa información inicial de la que se
deducirían el resto de "estados del algoritmo", un atacante necesitaría
poder tener acceso como administrador en el sistema. Digamos que para
poder aprovechar el problema del algoritmo y poder descifrar la
información, necesitaría tener el total control de la máquina para
llegar a conocer un estado, con lo que el sistema ya estaría
comprometido en sí.
Conclusiones
Lo peor no está ocurriendo ahora. Lo verdaderamente grave ha podido
ocurrir antes (en los últimos dos años si alguien ha conocido este error
y lo hubiese mantenido en secreto) y después (lo que nos espera a medida
que se vaya descubriendo que sistemas importantes ha generado claves
débiles).
Más información:
The Debian OpenSSL disaster
http://blog.drinsama.de/erich/en/linux/2008051401-debian-openssl-desaster.html
Random number generator, uninitialised data and valgrind
http://marc.info/?l=openssl-dev&m=114651085826293&w=2
The Bug
Debe ser ejecutado con