¿Dónde empiezo una petición para incrementar el CI y conocimiento del kernel de la gente? Tíos, leed drivers/char/random.c. Después, aprended criptografía. Finalmente volved y admitid ante el mundo que os habíais equivocado. Respuesta corta: Sabemos lo que hacemos. Vosotros no. Respuesta larga: usamos rdrand como una de las muchas entradas de entropía y lo usamos para mejorarla. Incluso si hubiera una puerta trasera de la NSA nuestro uso mejora la calidad de los números aleatorios de /dev/random. Respuesta muy corta: Sois unos ignorantes.
|
etiquetas: linux , ciberseguridad , ciberespionaje , nsa , ignorancia 
Primero que nada: los números al azar son fundamentales para la transmisión de datos cifrados. Por ejemplo el https que usamos para comunicarnos con el banco depende completamente de ellos.
Verán, las máquinas tienen un problema respecto de los números al azar: no pueden producirlos. El azar no existe para una máquina porque el azar implica algo demasiado complicado para analizarlo en profundidad, y los programas son perfectamente entendibles.
Para producir números al azar, las máquinas necesitan de algo externo que sea lo más impredecible posible. Por ejemplo, la temperatura, los tiempos de acceso al disco, los tiempos entre teclas que presiona el usuario, los movimientos del ratón, etc. Un programa se encarga de hacer una mescolanza de cosas diversas para obtener un número lo más impredecible posible. A eso es a lo que le…...
Por cierto, el contenido entero del enlace está traducido en la entradilla.
Ahora en serio, me parece un déspota egocéntrico, pero es un gran informático.
A Torvalds vamos a tener que lavarle la boca con lejia
#2 Ni falta que le hacen. No está ahí para ser diplomático. Y en general toda persona que trabaja en puestos supertécnicos (tanto a nivel de programación como de sistemas) adolece (y me incluyo, por la parte de sistemas) de diplomacia y tacto a partir de cierto punto.. ese en el que te tocan los huevecillos
La arrogancia es la mejor compañera de los errores
" La preocupación vendría por dos lados. Por un lado no hay forma de saber si la secuencia de números obtenida es realmente aleatoria o se trata de una secuencia prefabricada (muy larga). Por el otro, esta el hecho de que ese algoritmo, al estar incrustado en el hardware, no puede ser modificado ni auditado de ninguna forma."
"... 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: "
" Basta con agregar la opción nordrand a la linea de booteo del kernel, y listo, problema solucionado."
Primero que nada: los números al azar son fundamentales para la transmisión de datos cifrados. Por ejemplo el https que usamos para comunicarnos con el banco depende completamente de ellos.
Verán, las máquinas tienen un problema respecto de los números al azar: no pueden producirlos. El azar no existe para una máquina porque el azar implica algo demasiado complicado para analizarlo en profundidad, y los programas son perfectamente entendibles.
Para producir números al azar, las máquinas necesitan de algo externo que sea lo más impredecible posible. Por ejemplo, la temperatura, los tiempos de acceso al disco, los tiempos entre teclas que presiona el usuario, los movimientos del ratón, etc. Un programa se encarga de hacer una mescolanza de cosas diversas para obtener un número lo más impredecible posible. A eso es a lo que le llamamos "generador de entropía". En base a ese número, con cálculos matemáticos, se puede obtener una secuencia de otros más que también serán impredecibles.
Bien, pues resulta que algunos procesadores de Intel (en particular los de la serie ivy bridge) traen un generador interno de números al azar, y resulta que esos números al azar no eran tan al azar, sino que parece que Intel y la NSA tienen información que les permite predecirlos. Aunque no sea con total exactitud, el simple hecho de que no sean absolutamente desconocidos ya reduce muchísimo el tiempo necesario para romper un cifrado.
Ahora bien, ¿qué pasa con el kernel de Linux? Que hace uso de ese generador que está comprometido. Cuando se incluyó eso en el kernel hubo gente que se quejó de que no era seguro confiar en un generador que no sabemos cómo funciona, pero Linus no hizo caso a la advertencia.
¿Qué dice Linus de esto? Básicamente dice que los que han dicho esto son unos ignorantes. ¿Por qué? Porque la cosa no es que el kernel utilice solamente el generador de números al azar del microprocesador cuando está disponible, sino que lo usa a demás del resto de factores variables.
O sea, que el kernel siempre utiliza un montón de factores variables para su generador de entropía, y si el procesador tiene RdRand, lo agrega como un factor extra.
Así que podemos verlo de esta forma: en los procesadores que no tienen RdRand, ese factor extra es siempre el mismo: cero. Si el procesador sí lo tiene, el factor es variable aunque no sea 100% al azar porque la NSA sepa algo de él. En todo caso, la seguridad no se resiente en lo más mínimo. Los números al azar generados por Linux usando RdRand serian en el peor de los casos tan seguros como los que se generan sin usarlo.
- Al ser "agresivo", deja claro que no está equivocado. Hay que tener en cuenta de que lo que dice al ser un motivo técnico, es demostrable.
- Consigue que los hábiles se interesen por echarle un ojo a drivers/char/random.c, aunque sea por curiosidad. Está consiguiendo posibles colaboradores.
- Da una patada en el culo a los que hablan antes de saber de que hablan, haciendo que la próxima vez se enteren un poco mejor antes de decidirse a lanzar FUD.
Comete muchos errores en otros aspectos, pero no es mal estratega.
Cada día admiro más a este señor, y mira que yo soy más de Stallman, pero...
PD: Menéame es la prensa rosa de los geeks.
Yo creo que simplemente quieren votar negativo y no se molestan en pensar algo minimamente normal.
Mira esto:
www.meneame.net/story/backdoor-linux-nsa-no-invente-senora/voters
sensacionalista: 17
irrelevante: 10
errónea: 6
cansina: 2
La mas normal que veo es irrelevante ya que es subjetivo.
Pero que House que es este hombre...
lists.openwrt.org/pipermail/openwrt-devel/2013-September/021318.html
Tienes un Router con Wifi en casa? probablemente tengas un MIPS
Bueno, pues lo importante es que NO se puede saber de ninguna forma realmente lo que hace por dentro el firmware del disco, debido al secretismo de los fabricantes. Por lo que yo sé, ahora mismo el disco duro con el que investigo podría estar guardando datos en otra zona del disco a la que no se tiene acceso (de hecho las hay), y ni me enteraría. A partir de ahí las posibilidades son infinitas si sabes acceder a esos supuestos datos escondidos.
Cabe destacar que no se puede desarrollar un firmware libre, ya que tampoco dan las especificaciones completas. Así que estás atado de pies y manos y sólo puedes ver a través de la rendija que ellos te dejan.
Quiero decir con todo esto que es cierto que tener hardware abierto mejora la libertad, la privacidad y la innovación, no es una paja mental de Stallman y gente del mundillo open source.
Para variar, Linus tiene evidentemente razón y su posible arrogancia es la reacción adversa de tener que aguantar a tanta sin razón. Debe ser frustrante.
Recordemos que no es político. Con que sea buen programador a mi me basta.
Sobre que este asunto sea llevado a través de change.org, sin comentarios.
Al contrario que el artículo que enlaza #7, que no hace más que decir que los demás "comen mierda" sin enterarse él mismo de un pimiento.
Lastima que debido a la devaluación de los votos positivos y negativos no recibas el karma que mereces.
Enhorabuena.
Por cierto, el informe que enlazas en tu comentario de aquí: www.meneame.net/story/ubuntu-aparece-promo-mercedes-benz-coches-inteli esta realizado por la propia Intel. Muy objetivo no se si será.
Las alusiones personales no se han hecho esperar
plus.google.com/117091380454742934025/posts/SDcoemc9V3J
Y viene a desmentir a Linus Torvalds en el sentido de que, según él, hubo un tiempo (no se cuán largo) en el que un parche de Intel hizo que RDRAND fuese la única fuente de números aleatorios:
"RDRAND is not the only source of randomness used for /dev/random. It was at one point, but that's because the Intel engineers pushed a patch into the kernel."
Posteriormente se revirtieron esos parches, y ahora RDRand es solamente una más de las fuentes de entropía que usa linux.
#76 Ya lo dice bien Theo. Y no hace falta ser un hacker para darse cuenta.
"Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea."
¿Auditar un chip con millones de transistores? Sí, ingeniería inversa y tal, pero mira donde anda Nouveau...
¿Tengo que enseñarte el TPM con Intel y su Sandy Bridge, con acceso remoto de serie?
Tomas una secuencia aleatoria "A":
011100110110000...
Tomas otra secuencia "B" (imagina que no es aleatoria):
110111111110001...
Ahora creas una nueva secuencia "C": Tomas el primer bit de "A" y el primer bit de "B". ¿Son iguales? ¿Sí? Entonces pones un 0. ¿Son distintos? Entonces pones un 1.
La secuencia C sería:
101011001000001...
Imagina el caso malvado en que "B" son todo 0. Entonces la secuencia C será igual a A. No pierdes nada.
En el caso malvado que "B" sea todo 1, la secuencia C será la opuesta a A. Y por tanto será igual de aleatoria que A.
Si se construyese una secuencia B que sea igual que A, entonces C sería todo ceros. Pero el chip de RDRAND no sabe ni de la existencia de "A", así que no puede* generar una secuencia B que se le asemeje.
* Estadísticamente no es imposible... dada una secuencia de longitud N bits la probabilidad de que salga una cadena igual a "A" es igual a la probabilidad de que tu saques N caras seguidas tirando una moneda N veces.
git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/c
(con copia a #71 por si tiene curiosidad por el código)
Y puse dos códigos inventados uno realmente aleatorio sin saber la secuencia y otro sabiendo al menos parte la secuencia. Y como puse entre paréntesis la cosa sería más complicada y esos números que puse al principio realmente estarían desperdigados por el código.
Lo pongo más simple:
Si yo te pongo 137482828479569 ¿Sabes la secuencia? ¡ Ni de coña ! porque es 100% aleatorio, incluso aunque se repitan los números.
Si yo te pongo 135791357913579 ¿Sabes la secuencia? Por supuesto, es demasiado predecible (aunque fueran 100 millones de números) esos supuestos números aleatorios no lo son tanto. Es decir, que si el uso de RdRand súmale lo que quieras (flujo de datos, pulsaciones,...) realmente está comprometido por la NSA y la secuencia no es tan aleatoria, aunque sea una pequeña parte del código que se genere no deja de ser un peligro. Pués para la NSA es más fácil adivinar una clave con RdRand que sin ella. Y es que dentro de los múltiples factores o variables aleatorias una de ellas no lo es tanto. Y podéis hacer un XOR o lo que queráis que una de las variables no es aleatoria realmente.
Salu2
PD: Los saludos son para todos los compañeros, no sólo para ti.
En cuanto a las empresas de recuperación de datos, no sé muy bien cómo lo hacen, pero te puedo decir lo que se hace primero. Los sistemas de ficheros normalmente no borran nada en el disco, sino que eliminan la información que tienen de los mismos (inodo en el caso de ext por ejemplo). Así que en teoría los datos siguen en el disco, y si accedes al sector donde comenzaba un fichero borrado (vete a saber) podrías leerlo. Solución obvia: lees el disco completo, y vuelcas los ficheros que encuentres.
Si te refieres a la recuperación de discos dañados, o formateados de forma dura, o que han sido sobreescritos, no lo sé. No creo que necesiten información del fabricante, pero a lo mejor sí que tienen que usar algún aparato especial para leer la superficie del disco de forma más profunda que los cabezales con que viene de fábrica. De ahí podría venir el pastizal que cobran.
Ten en cuenta que estas cosas las sé por la carrera y por lo que he investigado para el proyecto, no soy un profesional del tema, nunca he trabajado recuperando información ni nada parecido.
No digo que existan, pero hay que ser cautos, si lees previamente la explicación de #84, imagina que hay una instrucción secreta que al enviarla al procesador, todos los números aleatorios generados a partir de entonces son cadenas "00000000000000", todas secuencias encriptadas que se obtienen de "xorear" (hacer XOR) contra esa cadena ("0000000000"...) van a ser la propia secuencia no encriptada, dicho de otro modo, la NSA/Gobierno de turno/etc puede hacer un virus/gusano/troyano/rootkit que al infectar tu ordenador, envíe esta instrucción desconocida al procesador y mágicamente toda tu encriptación de datos se vaya al garete. Así podrían saber de ti todo.
Por eso es tan importante no confiar únicamente en una instrucción del procesador para generar "entropía" (la semilla de los números aleatorios). Linus Torvalds ya dejó claro que no era el caso, por lo que esa petición a la que él ha contestado era bastante inútil y partía del desconocimiento de como funciona el kernel en estas tareas. Y ya sabemos que desde la desinformación no es de recibo reclamar cosas.
Esto... ¿En qué punto afecta eso a un Linux vajo KVM o XEN+Passthrough? A parte de /dev/random tenemos /dev/urandom el cual funciona igual bajo KVM.
Por no hablar de virtio-rng.
Realmente todo esto va de cómo de mala manera acabó RdRand incorporado en el núcleo de LINUX y de como el carácter insultante, ofensivo y despótico del padre del núcleo de LINUX ha llevado a esta polémica.
En el origen de todo esto está Matt Mackall, un antiguo responsable del kernel de LINUX, entre otros del /dev/random , digamos que la parte encargada de la generación de aleatoriedad del sistema (fundamental para el correcto funcionamento de los sistemas criptográficos) y que hace dos años se opuso a la inclusión de la función RdRand de Intel que permite utilizar un generador de números aleatorios por hardware incorporado en los procesadores de este fabricante (los Ivy Bridge y posteriores). Sus objeciones tenían que ver con el caracter cerrado tanto de la función RdRand (no está disponible su código fuente, sólo el binario ya compilado) como del mecanismo de los procesadores Intel para generar números aleatorios (es imposible de auditar). Matt Mackall alegaba que era imposible saber si realmente RdRand y el procesador sólamente se dedicaban a generar números aleatorios o en realidad podía hacer algo más, como por ejemplo, generar dichos números con un patrón predecible lo cual facilitaría enormemente la ruptura de los cifrados de las comunicaciones, entre otros. Además, Intel presionaba a los responsables del Kernel de Linux para que incluyeran la función RdRand como único generador de números aleatorios prescindiendo de todos los demás. Sospechoso, ¿verdad?.
Y en esto estaban los de Intel y los de Linux cuando de repente, intervino en esta polémica el señor Torvalds en persona zanjando la discusión a su manera (por cojones, vamos) incluyendo sin más en el núcleo dicha función RdRand, sin explicar ni razonar sus motivos y cerrando toda discusión en plan "el escatérgoris es mio y me lo llevo". Matt y otros alegaban que el caracter cerrado e inauditable de dicha función podía suponer un riesgo de seguridad importante para el núcleo, en un punto tan delicado como el generador de números aleatorio, fundamental para la criptografía y las comunicaciones seguras. Pero ya habéis visto como razona este chaval (digo chaval porque su comportamiento a veces es de niñato de instituto),… » ver todo el comentario
Ahí está el hilo completo.
Aún así, RDRand no es la única fuente de conseguir ruido aleatorio en GNU/Linux.
Lo cual no es culpa de Linux, por supuesto, pero tampoco significa que Linux + este chip no sea inseguro.
Por cierto, la página no me carga.