¿Una ‘puerta trasera’ de la NSA en Linux? Podría ser
¿Una ‘puerta trasera’ de la NSA en Linux?
El asunto de PRISM, el espionaje masivo llevado a cabo por las autoridades de Estados Unidos y la tan en boca de todos estos días NSA, la Agencia de Seguridad Nacional, roza a estas alturas el delirio.
Ni de Linux te puedes fiar ya, a tenor de lo publicado por Linux Magazine en Google+.
A grandes rasgos, hay un elemento privativo -es decir, de código cerrado, sin la posibilidad de ser analizado- en Linux, creado por Intel e impuesto en el kernel por el mismo Linus Torvalds, en contra de la opinión de Matt Mackall, mantenedor de ese área. Ese elemento se encarga de generar números aleatorios para distinto tipo de operaciones, entre otras, el cifrado de datos y comunicaciones. Y se sospecha que ha pasado una de esas “cosas que pasan“: Linux podría estar ‘troyanizado’ por la NSA.
Así, hace dos años que el Mackall dimitió precisamente por la negativa de Torvalds, que estaba convencido de la superioridad técnica del aporte de Intel. Pero Mackall volvió en julio a protagonizar una conversación que no ha levantado mucha polvareda -la prueba es que nos hemos enterado a través de una red social más de un mes después- pero que sería todo un mazazo para el sistema del pingüino de llegar a confirmarse. Porque no está confirmado.
A la dura sentencia que hacen desde Linux Magazine:
“Ahora sabemos que Intel, a instancias de la NSA, coló una puerta trasera en su generador de números aleatorios…”.
Solo podemos repetir que no está confirmado. El gran, grandísimo problema en este caso, es que va a ser prácticamente imposible de demostrar, por la naturaleza privativa del componente, que además ya no se utiliza de la misma forma.
Asimismo, se trata de un tema muy complejo, solo apto para expertos en la materia, y es que no se ponen de acuerdo ni ellos en las posibles implicaciones de este asunto. De hecho, ni siquiera está claro si este agujero negro afecta solo a dispositivos Intel o no, ya que el proceso de cocinado de distribuciones crea sus lagunas a este respecto.
En lo que sí parecen coincidir la mayoría es que en estos términos confiar en Intel es como tirarse a un pozo ciego, por lo que tampoco se descarta nada, todo lo contrario. Sea como fuere, sea verdad o mentira este caso en particular, parece que ya no hay nada de lo que fiarse.
¿Qué hacemos ahora?
Os contábamos poco antes de verano, en plena explosión del escándalo PRISM, que una receta, tal vez la única receta para evitar el espionaje gubernamental en Internet, era software libre y cifrado. Sin embargo, el devenir de los acontecimiento lo ha puesto todo patas arriba. Porque muchos nos temíamos lo peor, pero verlo sobre el papel impacta… Y no hablamos solo de Linux o el software libre, que también.
Veamos: la NSA no solo controla todas las comunicaciones (teléfono, Internet) que pasan por Estados Unidos. Ahora sabemos que también puede espiar cualquier dispositivo móvil, y que obliga a las empresas a incluir puertas traseras en su software. ¿No te sorprende? Pues debería. Como muestra, el completo resumen publicado ayer por el reconocido experto en seguridad informática Chema Alonso.
Ya está. Olvídate de la privacidad de tus datos para con las autoridades estadounidenses -y seguramente para con muchos otros gobiernos a lo largo y ancho del globo-, porque no puedes estar seguro de nada. Repetimos: no puedes estar seguro de NADA… En Internet.
¿Utilizas solo software libre? Ya sabes, una de esas distribuciones 100% libres. No importa. Es imposible revisar todo el código que incluyen, y aunque así fuese, lo podrido te puede llegar vía hardware. O vía vulnerabilidad descubierta -o abierta, ojo- por la NSA hace vaya usted a saber cuánto y vaya usted a saber dónde, todavía sin resolver. Desgraciadamente, hemos alcanzado ese punto de no retorno en la confianza.
Llegados, pues, a este punto de no retorno, se hace harto difícil continuar escribiendo, porque la única conclusión viable es deprimente: si eres una persona normal, es decir, no eres un criminal de altos vuelos, un terrorista, el presidente de una gran multinacional o un alto cargo gubernamental, y en estos casos ya se ocupará alguien de tu seguridad, pasa de todo.
Y más si no eres ciudadano estadounidense, que ni pinchas, ni cortas. Ellos al menos pueden castigar con el voto, aunque ese cáncer llamado bipartidismo que impera en esa nación -y en otras muchas, como España- hace realmente difícil que algo tan enraizado en el sistema pueda cambiar. Como tantas otras veces ha pasado, se maquillará de cara al público, y todo seguirá igual.
Aún así, parece que hay cosas que sí funcionan. Ahí está Wikileaks para demostrarlo. O el cierre de Lavabit, el servicio de correo electrónico utilizado por Edward Snowden, el cual no solo parece que funcionaba como debía, sino que no se dejó ‘troyanizar” por las autoridades y se vio forzado a cerrar y a defenderse en los tribunales en una guerra que puede durar años.
En definitiva, quéjate públicamente, haz piña con las iniciativas populares que surjan demandando transparencia… Pero que algo vaya a cambiar no se lo imagina ni el guionista de Matrix. Así que mejor preocúpate de mantener tus datos seguros de los malos de siempre que pululan por Internet, que a la NSA no le interesan tus “trapos sucios”. ¿Es indignante que puedan hacer lo que les de la gana? Sí. ¿Consiguió John Connor salvar al mundo de Skynet?
Mismo título, nuevo capitulo. Porque nada ha cambiado desde ayer en lo que al fondo del asunto respecta. Y éste no es, como advertimos en varias ocasiones, si Intel pudo haber jugado sucio o no, al no ser posible demostrarlo. El fondo del asunto es lo enturbiado que está todo el mundo de Internet por los excesos de la NSA y demás agencias gubernamentales de Estados Unidos.
No obstante, volvemos a retomar la historia de ayer, ya que hay informaciones complementarias que nos pueden interesar. Sin ir más lejos, la respuesta airada de Linus Torvalds a este asunto, en concreto a una petición iniciada y concluida ayer mismo en Change.org para eliminar RdRand de /dev/random:
¿Dónde empiezo una petición para elevar el cociente intelectual y del kernel de las personas?
Chicos, id a leer drivers/char/random.c. Entonces, aprended sobre criptografía. Por último, volved aquí y admitid ante el mundo que estabais equivocados.
Respuesta corta: sabemos lo que estamos haciendo. Vosotros no.
Respuesta larga: utilizamos RdRand como una de muchas “entradas en la piscina de entropía” [Ndt: Se refiere a un método para conseguir números aleatorios], y lo usamos como una manera de mejorar ese grupo al azar.
Así que incluso si la NSA puso una puerta trasera en RdRand, nuestro uso de RdRand realmente mejora la calidad de los números aleatorios que obtiene de /dev/random.
Respuesta muy corta: sois ignorantes”.
Como siempre, Torvalds responde de manera contundente y afilada.
Sin embargo, no es su palabra la última a la que vamos a atender hoy. Theodore Ts’o, un veterano y reconocido desarrollador de Linux también ha mostrado su desconfianza en este asunto, vía Google+ :
Estoy muy contento de haber resistido la presión de los ingenieros de Intel para que /dev/random se basara únicamente en la instrucción RdRand.
Basarse únicamente en el generador de números aleatorios del hardware que está utilizando una aplicación sellada dentro de un chip que es imposible de analizar, es una mala idea.
Así comienza una conversación que ya va por los 180 y pico comentarios donde encontraréis un poco de todo, desde usuarios preguntando a otros veteranos de Linux, como Alan Cox, dando su opinión o exponiendo detalles técnicos. Y tela. Un hilo de discusión muy jugoso, si es que os interesa el tema.
Asimismo, acaban de publicar un artículo en Espacio Linux de muy recomendable lectura, donde explican en qué consiste el componente de la discordia, RdRand.
En conclusión, por muy vehemente que haya sido la respuesta de Linus Torvalds y sin quitarle razón a lo que dice porque la tiene (no es incompatible con nada de lo expuesto), hay otros expertos del mismo nivel que no están tan a gusto con este asunto. A las referencias nos remitimos.
De hecho, remendamos ipso facto el error de no haber publicado una cita realmente descriptiva de Matt Mackall, el protagonista de la historia de ayer, en el comentario de la polémica. Pero solo el final, en el que, a modo de despedida y entre paréntesis, decía: “Y mientras tanto, mi desconfianza en la criptografía de Intel se ha movido de “paranoia profesional estándar” a “legítima preocupación real“.
Para terminar, repetimos una vez más que no está confirmado que RdRand -o cualquier otro de los componentes privativos que se utilizan o distribuyen con el kernel, ya que estamos- contenga una “trampa” de la NSA (también hay código de la NSA en SELinux).
E incluso aunque así fuera, como indica el propio Torvalds y las fuentes enlazadas, se trata de un elemento complementario que solo funcionaría con chips Intel (a partir de Ivy Bridge) el cual, además, se puede desactivar.
Aquí mismo pueden ver y descargar el código fuente original de Linux:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree
Y aquí tienen el código fuente de Linux Libre:
http://linux-libre.fsfla.org/pub/linux-libre/releases/3.11-gnu/linux-libre-3.11-gnu.tar.xz
Las instrucciones relativas al uso de RdRand las encuentran en los archivos:
arch/x86/kernel/cpu/common.c
arch/x86/kernel/cpu/rdrand.c
La instrucción que inicializa RdRand se encuentra en common.c y su definición en rdrand.c. Y ambos kernels hacen uso de las mismas instrucciones sin modificación alguna.
En otras palabras, da igual que uses Linux Libre, si tienes un microprocesador Ivy Bridge, o superior, lo más probable es que estés usando RdRand.
La pregunta a todo esto es: ¿Pero se puede desactivar esta característica? Sí, y en la misma documentación dice perfectamente como desactivarla:
Documentation/kernel-parameters.txt
Basta con agregar la opción nordrand a la linea de booteo del kernel, y listo, problema solucionado.
En serio señores, no coman mierda, infórmense bien antes de emitir palabra sobre un tema que desconocen. Preocuparse por la privacidad está perfecto, pero tampoco se trata de entrar en pánico sin sentido.
http://www.espaciolinux.com/2013/09/linux-la-nsa-y-la-desinformacion/
Más allá de este caso particular, la gran desazón que se respira estos días, como sugiere la frase citada de Mackall, es la pérdida de confianza en todo lo que pasa por Estados Unidos. Y por Estados Unidos pasa todo. Eso tomándola en un sentido general, porque él apunta a un objetivo bastante más específico.
En cualquier caso, el titular de este artículo y su primera parte, ¿Una ‘puerta trasera’ en Linux? Podría ser, no iba en exclusiva por RdRand, como supongo que muchos de nuestros lectores ya habrán comprendido a estas alturas e incluso antes.
No hace falta rebuscar demasiado para encontrarte con “puertas traseras” en Linux, ahí tienes Skype. Y tampoco es cuestión de desmoralizar a todo el mundo. Simplemente, las cosas están como están. Conviene saberlo y, si es menester, ir depurando la información hasta que se comprenda.
RdRand, Intel y la (poco probable) puerta trasera de la NSA en Linux
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.
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…
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.
