Como es bien sabido, /dev/random, un generador de números aleatorios criptográficamente seguro (CSPRNG), tiene un problema incómodo: los bloqueos. Este artículo explica cómo se puede solucionar.
En los últimos meses, se han realizado algunas modificaciones en los métodos de generación de números aleatorios en el núcleo, pero se han abordado problemas en este subsistema durante un período más amplio. Los últimos se hicieron con el objetivo de prevenir el bloqueo prolongado de la llamada al sistema getrandom() al arrancar el sistema, pero la causa subyacente de esto fue el comportamiento del grupo aleatorio bloqueante. Un parche reciente eliminó este grupo, y se esperaba que se dirigiera al núcleo principal.
Andy Lutomirski publicó la tercera versión del parche a finales de diciembre. Este introduce “dos cambios semánticos principales en las API aleatorias de Linux”.El parche agrega una nueva bandera GRND_INSECURE a la llamada al sistema getrandom() (aunque Lutomirski se refiere a ella como getentropy(), que se implementa en glibc usando getrandom() con banderas fijas); esta bandera hace que la llamada siempre devuelva la cantidad de datos solicitados, pero sin la garantía de que estos datos sean aleatorios. El núcleo simplemente se esforzará por proporcionar los mejores datos aleatorios que tenga en ese momento. “Probablemente lo mejor que se puede hacer es llamarlo 'INSECURE' (inseguro), para desincentivar el uso de esta API para cosas que necesitan seguridad.”
Los parches también eliminan el grupo bloqueante. Actualmente, el núcleo mantiene dos grupos de datos aleatorios, uno correspondiente a /dev/random y el otro a /dev/urandom, como se describe en esta publicación de 2015. El grupo bloqueante es un grupo para /dev/random; la lectura de este dispositivo se bloqueará (como su nombre indica) hasta que se haya recopilado suficiente entropía del sistema para satisfacer la solicitud. Lecturas adicionales de este archivo también se bloquean 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 el valor de flags igual a cero (y convierte el flag GRND_RANDOM en noop). Después de inicializar el generador de números aleatorios criptográficos (CRNG), la lectura de /dev/random y las llamadas a getrandom(…,0) no bloquearán y devolverán la cantidad solicitada de datos aleatorios.
Lutomirsky dice: «Creo que el grupo de bloqueo de Linux ha quedado obsoleto. El CRNG de Linux genera salidas que son lo suficientemente buenas como para ser utilizadas incluso para la generación de claves. El grupo de bloqueo ya no es más fuerte en ningún sentido material, y su mantenimiento requiere mucha infraestructura de dudoso valor».
Se hicieron cambios con la intención de que los programas existentes no se vean realmente afectados, y de hecho, los problemas con largas esperas para cosas como la generación de claves GnuPG serán menores.
«Estas series no deberían interrumpir ningún programa existente. /dev/urandom permanece sin cambios. /dev/random todavía se bloquea justo después de la carga, pero ahora se bloquea menos que antes. getentropy() con los flags existentes devolverá un resultado que será tan apropiado para propósitos prácticos como antes».
Lutomirsky señaló que todavía queda abierta la cuestión de si el núcleo debería proporcionar lo que se llaman "números verdaderamente aleatorios", que en cierta medida era lo que se suponía que hacía el núcleo de bloqueo. Solo ve una razón para ello: «cumplimiento de estándares gubernamentales». Lutomirsky sugirió que si el núcleo debe asegurarlo, debería hacerse a través de una interfaz completamente diferente o debería trasladarse al espacio de usuario, permitiéndole extraer muestras crudas de eventos que puedan ser utilizadas para crear tal grupo de bloqueo.
Stephan Müller sugirió que su conjunto Para el generador de números aleatorios de Linux (LRNG) (actualmente en su versión 26), puede ser una forma de proporcionar números verdaderamente aleatorios para aplicaciones que lo necesitan. LRNG "cumple completamente con los requisitos de las 'Recomendaciones sobre fuentes de entropía utilizadas para la generación de bits aleatorios' SP800-90B", lo que lo convierte en una solución para el problema de las normas estatales.
Matthew Garrett se opuso al término 'datos verdaderamente aleatorios', señalando que los dispositivos elegidos pueden ser modelados lo suficientemente bien como para hacerlos predecibles: 'no estamos seleccionando eventos cuánticos aquí'.
Müller respondió que este término proviene del estándar alemán AIS 31 para describir un generador de números aleatorios que solo produce resultados 'a la misma velocidad a la que la fuente básica de ruido genera entropía'.
Además de las interpretaciones erróneas de la terminología, la existencia de un pool de bloqueo, tal como se propone en los parches de LRNG, simplemente causará diversos problemas, al menos si está disponible sin privilegios.
Como dijo Lutomirski: "Esto no resuelve el problema. Si dos usuarios diferentes ejecutan programas tontos, como gnupg, simplemente se agotarían entre sí. Veo que actualmente hay dos principales problemas con /dev/random: tiende al DoS (es decir, agotar recursos, impactar maliciosamente o algo por el estilo), y dado que no se requieren privilegios para su uso, también es propenso a abusos. Gnupg está mal, es un colapso total. Si añadimos una nueva interfaz no privilegiada que utilizarán gnupg y programas similares, perderemos nuevamente."
Müller señaló que añadir getrandom() ahora permitirá a GnuPG utilizar esta interfaz, ya que proporcionará la garantía necesaria de que el pool ha sido inicializado. Basándose en discusiones con el desarrollador de GnuPG Werner Koch, Müller considera que la garantía es la única razón por la que GnuPG actualmente lee directamente de /dev/random. Pero si hay una interfaz no privilegiada que es susceptible a denegaciones de servicio (como lo es hoy /dev/random), según Lutomirski, será mal utilizada por algunas aplicaciones.
Teodoro Tsao (Theodore Yue Tak Ts’o), desarrollador del subsistema de números aleatorios de Linux, aparentemente ha cambiado de opinión sobre la necesidad de un pool bloqueante. Dijo que eliminar este pool permitiría deshacerse eficazmente de la idea de que Linux tiene un verdadero generador de números aleatorios (TRNG): "no es un sinsentido, ya que es exactamente lo que siempre han hecho los *BSD".
También está preocupado de que proporcionar un mecanismo TRNG simplemente sirva como un señuelo para los desarrolladores de aplicaciones y considera que, de hecho, dado los diferentes tipos de hardware soportados por Linux, es imposible garantizar TRNG en el núcleo. El problema no se resolverá ni siquiera con la posibilidad de trabajar con hardware solo con privilegios de root: "Los desarrolladores de aplicaciones dicen que, para la seguridad de su aplicación, debe instalarse como root, solo así puedes acceder a números aleatorios 'realmente buenos'".
Müller preguntó si Tsao había renunciado a la implementación del pool bloqueante que él mismo había propuesto hace tiempo. Tsao respondió que planea tomar los parches de Lutomirski y se opone activamente a agregar la interfaz bloqueante de nuevo al núcleo.
"El núcleo no puede dar ninguna garantía sobre si la fuente de ruido ha sido caracterizada adecuadamente. Lo único que puede obtener un desarrollador de GPG o OpenSSL es una vaga sensación de que TRUERANDOM es 'mejor', y como quieren más seguridad, sin duda intentarán utilizarlo. En algún momento se bloqueará, y cuando algún otro usuario inteligente (quizás un especialista en lanzamiento de distribuciones) lo inserte en el script init y los sistemas dejen de funcionar, a los usuarios solo les quedará quejarse ante Linus Torvalds".
Tsao también aboga por permitir a los criptógrafos y a quienes realmente necesitan TRNG la forma de recolectar su propia entropía en el espacio del usuario, para usarla a su conveniencia. Él dice que la recolección de entropía no es un proceso que pueda realizar el núcleo en todos los diversos hardware que admite; además, el propio núcleo no puede evaluar la cantidad de entropía proporcionada por las diferentes fuentes.
«El núcleo no debe mezclar diferentes fuentes de ruido, y no debe pretender saber cuántos bits de entropía recibe al intentar jugar una 'juego de entropía' en una arquitectura de CPU increíblemente simple para casos de uso de IOT/Embebido, cuando todo está desincronizado con un único generador maestro, sin ninguna instrucción de CPU para reordenar o renombrar registros, etcétera».
«Se puede hablar sobre proporcionar herramientas que intenten realizar estos cálculos, pero tales cosas deben llevarse a cabo en el hardware de cada usuario, lo cual es, para la mayoría de los usuarios de la distribución, simplemente poco práctico. Si esto está destinado solo a criptógrafos, que se haga en su espacio de usuario. Y no simplifiquemos GPG, OpenSSL, etc., para que todos digan: 'queremos 'verdadera aleatoriedad' y no aceptamos menos'. Se puede hablar sobre cómo proporcionamos interfaces a los criptógrafos para que puedan obtener la información necesaria a través de acceso a fuentes de ruido primarias, separadas y nombradas, y, tal vez, de alguna manera, la fuente de ruido pueda autenticarse en la biblioteca o aplicación del espacio de usuario».
Tuvo lugar una pequeña discusión sobre cómo podría ser dicha interfaz, ya que, por ejemplo, ciertos eventos podrían tener implicaciones en términos de seguridad. Cao señaló que los códigos de escaneo del teclado (es decir, las pulsaciones de teclas) se mezclan en un pool como parte de la recolección de entropía: 'Mover esto al espacio de usuario, incluso a través de una llamada al sistema privilegiada, sería, al menos, imprudente'. Es bastante posible que otros tiempos de eventos puedan crear alguna fuga de información a través de canales secundarios.
Así, se tiene la sensación de que un viejo problema del subsistema de números aleatorios de Linux está en camino de solución. Los cambios que el subsistema de números aleatorios ha sufrido últimamente han llevado principalmente a problemas de DoS en su uso. Ahora, sin embargo, hay métodos efectivos para obtener los mejores números aleatorios que el núcleo puede proporcionar. Si TRNG sigue siendo deseable para Linux, este defecto tendrá que ser corregido en el futuro, aunque es poco probable que se haga dentro del propio núcleo.
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
