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
25 comentarios
coldkde
Gran artículo, Guillermo Julián.
Esto será pasto de mis cuentas en las redes sociales.
Land-of-Mordor
Has llegado al difícil equilibrio entre ser exacto en la exposición de los conceptos y claro para que prácticamente cualquiera que se detenga a leerlo lo pueda comprender. Mi más sincera enhorabuena.
Si en Weblogs hay algún artículo alarmando sobre este tema o no siendo tan certero, preciso y comprensible como éste, deberíais actualizarlo con referencias al que nos has ofrecido hoy.
mcj
Es decir depende más de como lo desarrolladores implementen, si tiras más de la piscina de entropía o del generador de hardware de Intel, dependiendo de tu nivel de exigencia de tiempo o de tu nivel de paranoia.
De todas formas, la solución por hardware estuvo un determinado tiempo presente en Linux y ya hace un año que no esta. Más información aquí
GuilloooAR
el primer articulo que leo sobre este tema que es claro y preciso, en otros blog solo leía posibles conspiraciones internacionales.
fearu
Yo creo que la verdadera pregunta es si hay una puerta trasera de la NSA en los procesadores intel, no si un sistema operativo con una cuota de mercado del 1% está afectado por esa puerta trasera (no contemos android, porque en su mayoría son procesadores arm).
supercoca
Efectivamente, afecta "sólo a ciertos programas que usen la llamada en cuestión". Pero ¿qué programas? ¿Y si la función de marras la usa algún navegador, o Truecrypt o cualquier otro programa de uso masivo "patrocinado" por la NSA?
Que en el kernel no aparezca tranquiliza, pero si sigue estando ahí es porque para algo se usa.
pacman2013
Excelente post, muy interesante!
electron222
Este redactor siempre con sus Excelente y muy claros artículos, muchísimas gracias. No como el otro bobo que decía que las distros linux debía eliminar la terminal, todavía me sangras los ojos u.u
tala2000
Felicidades, muy buen articulo.
En mi opinion que no tengo ni idea, encriptar es "facil", desencriptar es muy dificil, siempre que los sistemas no esten automatizados, si se usan generadores de codigo aleatorio como los que se generan con el movimiento del raton por parte del usario y se combinan con una serie de caracteres puestos por el mismo usuario al azar, me parece que son practicamente impenetrables.
No creo que nadie tenga tecnologia para romper estas encriptaciones aunque si creo que los sistemas que son automatizados tienen que tener sus flaquezas y gente intentando vulnerarlas.
bauglir
Gran artículo. Enhorabuena.
vivaldibonao
Gran articulo, wao, si tan solo la mitad de los articulos de genbeta tuviesen la mitad de calidad que este. Seria excelente. Y no es porque sea un fan de linux. Todo lo contrario, no me gusta linux, uso windows y me gusta apple. Pero cuando hay calidad explicando algo con el perfecto balance en terminos tecnicos y Generales para las personas que como yo no somos muy entendidos del tema, merece una felicitacion doble. Enhora buena, sigue asi.
ecoslacker
Muy buen artículo, yo no soy programador y creo haber entendido el asunto. Felicidades por la redacción, no en muchos blogs hay esta calidad.
Ahora ¿Cómo puedo saber si mi distro está usando esta función? ¿Cómo saber si en el momento que se cifre algo estoy usando esta función o no? o bien ¿Qué programas la usan?
Otra sería si las distros completamente libres reconocidas por GNU ¿están libres de esto?