Se sabe que /dev/random, un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG), tiene un problema molesto: el bloqueo. Este artículo explica cómo puedes solucionarlo.
En los últimos meses, las funciones de generación de números aleatorios en el kernel han sido ligeramente reelaboradas, pero los problemas en este subsistema se han resuelto en el transcurso de la versión más amplia. . La mayoría se hicieron para evitar que la llamada al sistema getrandom() se bloquee durante mucho tiempo cuando se inicia el sistema, pero la razón subyacente de esto fue el comportamiento de bloqueo del grupo aleatorio. Un parche reciente habría eliminado este grupo y se habría esperado que se dirigiera hacia el núcleo principal.
Andy Lutomirski publicó la tercera versión del parche a finales de diciembre. el contribuye "dos cambios semánticos importantes en las API aleatorias de Linux". El parche agrega un nuevo indicador GRND_INSECURE a la llamada al sistema getrandom() (aunque Lutomirsky se refiere a él como getentropy(), que se implementa en glibc usando getrandom() con indicadores fijos); este flag hace que la llamada devuelva siempre la cantidad de datos solicitados, pero sin garantizar que los datos sean aleatorios. El núcleo simplemente hará todo lo posible para producir los mejores datos aleatorios que tenga en un momento determinado. "Probablemente lo mejor que se puede hacer es llamarlo 'INSEGURO' (inseguro) para evitar que esta API se utilice para cosas que necesitan seguridad".
Los parches también eliminan el grupo de bloqueo. El kernel actualmente mantiene dos grupos de datos aleatorios, uno correspondiente a /dev/random y el otro a /dev/urandom, como se describe en este 2015. El grupo de bloqueo es el grupo de /dev/random; Las lecturas para ese dispositivo se bloquearán (es decir, su nombre) hasta que se haya recopilado "suficiente" entropía del sistema para satisfacer la solicitud. También se bloquean más lecturas de este archivo si no hay suficiente entropía en el grupo.
Eliminar el grupo de bloqueo significa que la lectura de /dev/random se comporta como getrandom() con indicadores establecidos en cero (y convierte el indicador GRND_RANDOM en un noop). Una vez que se inicializa el generador criptográfico de números aleatorios (CRNG), la lectura de /dev/random y las llamadas a getrandom(...,0) no se bloquearán y devolverán la cantidad solicitada de datos aleatorios.
Lutomirsky dice: “Creo que el grupo de bloqueo de Linux se ha vuelto obsoleto. CRNG Linux genera resultados que son lo suficientemente buenos como para usarse incluso para la generación de claves. El grupo de bloqueo no es más fuerte en ningún sentido material y requiere mucha infraestructura de dudoso valor para respaldarlo”.
Los cambios se realizaron con el objetivo de garantizar que los programas existentes no se vieran realmente afectados y, de hecho, habría menos problemas con largas esperas para cosas como la generación de claves GnuPG.
“Estos episodios no deben alterar ningún programa existente. /dev/urandom permanece sin cambios. /dev/random todavía se bloquea inmediatamente después del arranque, pero bloquea menos que antes. getentropy() con los indicadores existentes devolverá un resultado que es tan adecuado para propósitos prácticos como antes."
Lutomirsky señaló que todavía es una cuestión abierta si el núcleo debería proporcionar los llamados “números aleatorios verdaderos”, que es lo que se suponía que debía hacer el núcleo bloqueador hasta cierto punto. Sólo ve una razón para ello: "el cumplimiento de las normas gubernamentales". Lutomirsky sugirió que si el kernel proporcionara esto, debería hacerlo a través de una interfaz completamente diferente, o debería moverse al espacio del usuario, permitiendo al usuario recuperar muestras de eventos sin procesar que podrían usarse para crear dicho grupo de bloqueos.
Stephan Müller sugirió que su set para Linux Random Number Generator (LRNG) (actualmente lanzada la versión 26) podría ser una forma de proporcionar números aleatorios verdaderos para las aplicaciones que lo necesitan. LRNG es “totalmente compatible con las pautas SP800-90B sobre fuentes de entropía utilizadas para generar bits aleatorios”, lo que lo convierte en una solución al problema de los estándares gubernamentales.
Matthew Garrett se opuso al término "datos aleatorios verdaderos", señalando que los dispositivos muestreados podrían, en principio, modelarse con suficiente precisión para hacerlos predecibles: "aquí no estamos muestreando eventos cuánticos".
Müller respondió que el término proviene del estándar alemán AIS 31 para describir un generador de números aleatorios que sólo produce un resultado "al mismo ritmo que la fuente de ruido subyacente produce entropía".
Dejando a un lado las diferencias terminológicas, tener un grupo de bloqueo como lo sugieren los parches LRNG simplemente generará varios problemas, al menos si se accede a él sin privilegios.
Como dijo Lutomirsky: “Esto no resuelve el problema. Si dos usuarios diferentes ejecutan programas estúpidos como gnupg, se agotarán mutuamente. Veo que actualmente hay dos problemas principales con /dev/random: es propenso a DoS (es decir, agotamiento de recursos, influencia maliciosa o algo similar) y, dado que no se requieren privilegios para usarlo, también es propenso a sufrir abusos. Gnupg está equivocado, es un colapso total. Si añadimos una nueva interfaz sin privilegios que usarán gnupg y programas similares, volveremos a perder."
Mueller señaló que la adición de getrandom() ahora permitirá a GnuPG usar esta interfaz, ya que proporcionará la garantía necesaria de que el grupo ha sido inicializado. Basado en discusiones con el desarrollador de GnuPG Werner Koch, Mueller cree que la garantía es la única razón por la que GnuPG actualmente lee directamente desde /dev/random. Pero si hay una interfaz sin privilegios que es susceptible a la denegación de servicio (como lo es hoy /dev/random), Lutomirsky argumenta que algunas aplicaciones la utilizarán indebidamente.
Theodore Yue Tak Ts'o, desarrollador del subsistema de números aleatorios de Linux, parece haber cambiado de opinión sobre la necesidad de un grupo de bloqueo. Dijo que eliminar este grupo eliminaría efectivamente la idea de que Linux tiene un verdadero generador de números aleatorios (TRNG): "Esto no es una tontería, ya que esto es exactamente lo que *BSD siempre ha hecho."
También le preocupa que proporcionar un mecanismo TRNG simplemente sirva como cebo para los desarrolladores de aplicaciones y cree que, de hecho, dados los diferentes tipos de hardware soportados por Linux, es imposible garantizar TRNG en el kernel. Incluso la capacidad de trabajar con equipos solo con privilegios de root no resolverá el problema: "Los desarrolladores de aplicaciones especifican que su aplicación se instale como root por motivos de seguridad, de modo que ésta sea la única forma de acceder a los números aleatorios 'realmente buenos'".
Mueller preguntó si Cao había abandonado la implementación del grupo de bloqueo que él mismo había propuesto durante mucho tiempo. Cao respondió que planea tomar los parches de Lutomirsky y se opone activamente a agregar una interfaz de bloqueo al núcleo.
“El kernel no puede ofrecer ninguna garantía sobre si la fuente de ruido se ha caracterizado adecuadamente. Lo único que un desarrollador de GPG u OpenSSL puede tener es una vaga sensación de que TRURANDOM es "mejor" y, como quiere más seguridad, sin duda intentará utilizarlo. En algún momento será bloqueado, y cuando algún otro usuario inteligente (quizás un especialista en distribución) lo inserte en el script de inicio y los sistemas dejen de funcionar, los usuarios sólo tendrán que quejarse ante el propio Linus Torvalds”.
Cao también aboga por brindarles a los criptógrafos y a aquellos que realmente necesitan TRNG una forma de recolectar su propia entropía en el espacio del usuario para usarla como mejor les parezca. Dice que recolectar entropía no es un proceso que pueda realizar el kernel en todos los diferentes hardware que admite, ni el kernel mismo puede estimar la cantidad de entropía proporcionada por diferentes fuentes.
"El núcleo no debería mezclar diferentes fuentes de ruido, y ciertamente no debería intentar afirmar saber cuántos bits de entropía está obteniendo cuando intenta jugar algún tipo de "juego de entropía nerviosa" en una CPU escandalosamente simple. arquitectura para usuarios consumidores Casos IOT/Embedded donde todo no está sincronizado con un único oscilador maestro, donde no hay instrucciones de CPU para reordenar o cambiar el nombre de un registro, etc.
“Se puede hablar de proporcionar herramientas que intenten hacer estos cálculos, pero esas cosas deben hacerse en el hardware de cada usuario, lo que simplemente no es práctico para la mayoría de los usuarios de distribuciones. Si esto sólo está destinado a criptógrafos, entonces que se haga en su espacio de usuario. Y no simplifiquemos GPG, OpenSSL, etc. para que todos digan "queremos" verdadera aleatoriedad "y no nos conformaremos con menos". Podemos hablar sobre cómo proporcionamos interfaces a los criptógrafos para que puedan obtener la información que necesitan accediendo a las fuentes primarias de ruido, separadas y nombradas, y tal vez de alguna manera la fuente de ruido pueda autenticarse en una biblioteca o aplicación de espacio de usuario".
Hubo cierta discusión sobre cómo sería esa interfaz, ya que, por ejemplo, podría haber implicaciones de seguridad para algunos eventos. Cao señaló que los códigos de escaneo del teclado (es decir, las pulsaciones de teclas) se mezclan en un conjunto como parte de la recopilación de entropía: "Llevar esto al espacio del usuario, incluso a través de una llamada al sistema privilegiada, sería, por decir lo mínimo, imprudente". Es muy posible que otras fechas de eventos puedan crear algún tipo de fuga de información a través de canales secundarios.
Así que parece que un problema de larga data con el subsistema de números aleatorios de Linux está en camino a una solución. Los cambios que el subsistema de números aleatorios ha experimentado recientemente en realidad sólo han resultado en problemas de DoS durante su uso. Ahora existen formas eficientes de obtener los mejores números aleatorios que el núcleo puede proporcionar. Si TRNG todavía es deseable en Linux, entonces será necesario solucionar esta falla en el futuro, pero lo más probable es que esto no se haga dentro del propio kernel.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com