Aunque no es una noticia nueva, estos últimos días ha salido a la luz de nuevo: Linux podría tener una puerta trasera puesta por la NSA, que permitiría a la agencia romper la criptografía que se ejecute en el sistema. El tema es complicado, y podría decirse que se ha transmitido de forma un poco alarmista. Pero, como siempre y antes de saltar a conclusiones, veamos qué es lo que ocurre de verdad y cómo funciona todo.
Por qué los números aleatorios son importantes para la criptografía
Generar números verdaderamente aleatorios es una tarea muy difícil en un ordenador, y sin embargo muy importante. La gran mayoría de funciones criptográficas necesitan un generador de números aleatorios para crear claves de cifrado. Si el generador no es realmente aleatorio, alguien podría predecir los números que devuelve y, con ello, saber qué claves genera un ordenador y por lo tanto romper sus cifrados.
Pasó con Netscape en su momento: la implementación de HTTPS usaba números pseudoaleatorios predecibles para las claves de cifrado, y esto permitía a los atacantes ver el tráfico que los usuarios creían seguro. Como veis, el tema de la aleatoriedad es importante. Diremos que una fuente de números aleatorios es criptográficamente segura cuando sea imposible de predecir por un atacante.
Bull Mountain, aleatoriedad por hardware
El diseño del circuito de incertidumbre de Bull Mountain. Los nodos A y B intercambian los dos caminos de forma aleatoria.
Intel quiso llegar más lejos que las soluciones existentes en su momento, y crear un generador de números verdaderamente aleatorios por hardware que fuese rápido. Lo hizo, y desde el punto de vista técnico no funciona nada mal.
La idea del generador hardware es un chip muy sencillo: dos inversores colocados en paralelo y en distintos sentidos. Cuando se deje pasar la corriente por esos inversores, primero habrá un estado de equilibrio y después los dos nodos alcanzarán un estado definido, que es aleatorio.
El chip de Intel abusa de los inversores poniéndolos en un estado de equilibrio inestable, que resuelve a un estado aleatorio
Para entender mejor cómo funciona ese chip, hagamos una analogía. Imaginemos que colocamos un raíl perfectamente equilibrado en la cima de un tejado, de tal forma que no se caiga ni para un lado ni para otro. En el centro de ese raíl ponemos una bola. Al cabo de algunos segundos, por el viento, las irregularidades en la bola y demás factores que no podemos medir, la bola se moverá del centro y hará que el carril caiga para un lado.
Lo que hace el chip es repetir esa operación continuamente: si el carril cae en el lado izquierdo, anota un 0, y si cae en el derecho anota un 1. Así, uno tras otro, va generando una secuencia de números aleatorios. Adicionalmente, el chip ajusta la salida para garantizar que es verdaderamente aleatoria y que ambos números salen con la misma probabilidad.
El generador de números aleatorios de Linux y la piscina de entropía
Por otra parte, tenemos el generador de números aleatorios del kernel de Linux. Para ser verdaderamente aleatorio, el núcleo va alimentado lo que se llama una _piscina de entropía_ con números de fuentes aleatorias: por ejemplo, cada cuanto tiempo pulsas una tecla, cada cuanto tiempo una parte del hardware hace una petición al sistema (interrupción)... Si bien todas estas fuentes por sí solas no son seguras (podrían predecirse), al combinarlas en la _piscina_ hacen muy difícil que un atacante pueda saber qué números aleatorios estás generando. El mismo archivo de código del kernel lo explica con mucha más precisión que yo.
Con la creación de Bull Mountain y la correspondiente instrucción _RdRand_ que obtenía un número aleatorio de la CPU, se añadió en el kernel como una fuente de entropía. Sin embargo, se hizo algo más.
Como podréis imaginar al ver el nombre, la _piscina de entropía_ hay que llenarla antes de poder sacar números aleatorios de ahí. Y aunque se puede llenar manualmente (si estáis en Linux/Unix, _echo loquesea >> /dev/random_ añade datos a la piscina), no es precisamente rápida. Por eso, Intel creó una función (get_random_bytes_arch) que permitía obtener números aleatorios saltándose la piscina de entropía llamando directamente al chip Bull Mountain, usando la famosa instrucción _RdRand_. Linus aceptó el parche, y la función sigue ahí en el kernel.
Y el problema es...
La función get_random_bytes_arch.
El problema es que la fuente de números aleatorios de Intel no se puede auditar y ver cómo funciona, porque es un chip físico. Y, aunque nosotros veamos números aleatorios saliendo de ahí, es posible que en realidad sigan algún tipo de patrón.
Ese patrón sería la puerta trasera que habría puesto la NSA a través de Intel. Sólo ellos conocen la relación de los números aleatorios, podrían saber cómo se generan y por lo tanto saber qué claves están generando los ordenadores con Linux.
Ahora bien, aventuro (aun sin ser ni un experto en seguridad ni en el kernel de Linux, lo que es bastante arriesgado) que es poco posible que esa puerta trasera exista realmente. ¿Por qué?
Lo primero, porque desde el kernel de Linux, la principal fuente de números aleatorios es _/dev/random/_, la piscina de entropía que comentábamos. Incluso asumiendo que una de las fuentes, el chip de Intel, está comprometida, la combinación de todas ellas es criptográficamente segura.
Por otro lado, la función get_random_bytes_arch, la que usa el chip de Intel directamente, no se usa en el kernel de Linux (al menos no que yo haya visto). En el caso de que la puerta trasera existiera, ya no afectaría a todos el sistema Linux sobre Intel, sino sólo a los programas que la llamen específicamente. Esto convierte a la puerta trasera en prácticamente inútil: el posible ataque de la NSA pasaría de estar dirigido a todo el sistema a sólo ciertos programas que usen la llamada correspondiente. Y en este caso, es mucho más sencillo explotar cualquiera de los otros fallos posibles que pueda tener el programa, más sencillos de detectar y atacar, que usar el patrón del chip (que, si existe, no será ni mucho menos sencillo o simple) para sacar la clave que usa. Además, la llamada está claramente marcada como "usar sólo si confías en el fabricante de hardware", lo que debería evitar que los desarrolladores la usen accidentalmente.
En resumen, que si bien existe la posibilidad de que la NSA haya introducido una puerta trasera en el generador de números aleatorios de Linux, es muy baja y no afectaría a todo el kernel, sino sólo a ciertos programas que usen la llamada en cuestión.
Ver 25 comentarios