Como saben, / dev / random, un generador de números pseudoaleatorios criptográficamente fuerte (CSPRNG), tiene un problema desagradable: el bloqueo. Este artículo describe cómo resolverlo.
En los últimos meses, los medios para generar números aleatorios en el núcleo se han modificado ligeramente, pero los problemas en este subsistema se han resuelto en un
período de tiempo más amplio. Los
cambios más
recientes se realizaron para evitar que la llamada al sistema getrandom () se bloquee durante mucho tiempo durante el arranque del sistema, pero la razón detrás de esto fue el comportamiento del grupo aleatorio de bloqueo. Un parche reciente eliminaría este grupo, y era de esperar que iría al núcleo principal.
Andy Lutomirski lanzó la tercera versión del parche a fines de diciembre. Realiza
"dos cambios semánticos básicos en las API de Linux aleatorias" . El parche agrega el 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 indicador obliga a la llamada a devolver siempre la cantidad de datos solicitados, pero sin garantizar que los datos sean aleatorios. El núcleo simplemente hará todo lo posible para proporcionar los mejores datos aleatorios que tenga en un momento dado.
"Probablemente lo mejor que puede hacer es llamarlo" INSEGURIDAD " (inseguro) para evitar que se use para cosas que necesitan seguridad".
Los parches también eliminan el grupo de bloqueo. Actualmente, el núcleo admite dos grupos de datos aleatorios, uno de los cuales corresponde a / dev / random y el otro a / dev / urandom, como se describe en este
artículo de 2015. Un grupo de bloqueo es un grupo para / dev / random; la lectura de este dispositivo se bloqueará (es decir, su nombre) hasta que se recopile entropía "suficiente" del sistema para satisfacer la solicitud. Las 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 las banderas establecido en cero (y convierte la bandera GRND_RANDOM en noop). Después de inicializar el generador de números aleatorios criptográficos (CRNG), la lectura de / dev / random y la llamada 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 usar incluso para la generación de claves. El grupo de bloqueo no es más fuerte en ningún sentido material, y requiere una gran cantidad de infraestructura de dudoso valor para mantenerlo ”.Los cambios se realizaron con el objetivo de garantizar que los programas existentes no sufran realmente, y de hecho, los problemas con la larga espera para cosas como generar claves GnuPG se harán más pequeños.
“Estas series no deben violar ningún programa existente. / dev / urandom permanece sin cambios. / dev / random aún se bloquea inmediatamente después de la carga, pero bloquea menos que antes. getentropy () con banderas existentes devolverá un resultado que será tan práctico para el propósito como antes ".Lutomirsky señaló que la pregunta sigue abierta si el núcleo debería proporcionar los llamados "números aleatorios verdaderos", que en cierta medida deberían haber sido realizados por el núcleo de bloqueo. Él ve solo una razón para esto: "cumplimiento de las normas estatales". Lutomirsky sugirió que si el kernel debe proporcionar esto, entonces esto debe hacerse a través de una interfaz completamente diferente o debe transferirse al espacio del usuario, lo que le permite recuperar patrones de eventos no procesados que se pueden usar para crear dicho grupo de bloqueo.
Stephan Müller sugirió que su conjunto de
parches para el generador de números aleatorios de Linux (LRNG) (actualmente se lanza la versión 26) podría ser una forma de proporcionar números aleatorios verdaderos para las aplicaciones que lo necesitan. LRNG "cumple totalmente con los requisitos de las" Recomendaciones sobre las fuentes de entropía utilizadas para generar bits aleatorios "SP800-90B", lo que lo convierte en una solución al problema de los estándares estatales.
Matthew Garrett se opuso al término "datos aleatorios verdaderos", y señaló que los dispositivos seleccionables pueden, en principio, modelarse con la precisión suficiente para hacerlos predecibles: "no estamos tomando eventos cuánticos aquí".
Muller respondió que el término proviene del estándar alemán AIS 31 para describir un generador de números aleatorios que solo produce el resultado "a la misma velocidad que la fuente de ruido subyacente produce entropía".
Además de los malentendidos de la terminología, la presencia de un grupo de bloqueo, como lo sugieren los parches LRNG, simplemente conducirá a varios problemas, al menos si está disponible sin privilegios.
Como dijo Lutomirsky:
“Esto no resuelve el problema. Si dos usuarios diferentes ejecutan programas estúpidos como gnupg, simplemente se agotan mutuamente. Veo que actualmente hay dos problemas principales con / dev / random: es susceptible a DoS (es decir, agotamiento de recursos, influencia dañina o algo así), y dado que no requiere ningún privilegio para usarlo, sujeto a abuso. Gnupg está equivocado, es un colapso completo. Si agregamos una nueva interfaz sin privilegios que usarán gnupg y programas similares, perderemos nuevamente ”.Muller señaló que agregar getrandom () ahora permitirá que GnuPG use esta interfaz, ya que proporcionará la garantía necesaria de que el grupo se ha inicializado. Basado en discusiones con el desarrollador de GnuPG Werner Koch, Muller 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 no privilegiada que está sujeta a una denegación de servicio (a partir de hoy / dev / random), entonces, según Lutomirsky, algunas aplicaciones la utilizarán mal.
Theodore Yue Tak Ts'o, el desarrollador del subsistema de números aleatorios de Linux, parece haber cambiado de opinión acerca de la necesidad de un grupo de bloqueo. Dijo que eliminar este grupo efectivamente eliminaría la idea de que Linux tiene un verdadero generador de números aleatorios (TRNG):
"esto no tiene sentido, ya que esto es exactamente lo que * BSD siempre ha hecho".También le preocupa que proporcionar el mecanismo TRNG simplemente sirva como señuelo para los desarrolladores de aplicaciones y cree que, en realidad, dados los diversos tipos de hardware soportados por Linux, no es posible garantizar TRNG en el núcleo. Incluso la capacidad de trabajar con equipos basados en privilegios de root no resolverá el problema:
"Los desarrolladores de aplicaciones especifican que su aplicación se instale como root por razones de seguridad, porque esta es la única forma de acceder a números aleatorios" realmente buenos ".Muller preguntó si Cao se había negado a implementar el grupo de bloqueo, que él mismo había propuesto durante mucho tiempo. Cao respondió que planeaba tomar los parches de Lutomirsky y se opuso activamente a agregar una interfaz de bloqueo al núcleo.
“El núcleo no puede dar ninguna garantía sobre si la fuente de ruido se ha caracterizado adecuadamente. Lo único que puede obtener un desarrollador de GPG u OpenSSL es la vaga sensación de que TRUERANDOM es "mejor", y dado que quieren más seguridad, sin duda intentarán usarlo. En algún momento, se bloqueará, 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 solo tendrán que quejarse ante el propio Linus Torvalds ".Cao también aboga por proporcionar a los criptógrafos y aquellos que realmente necesitan TRNG una forma de recopilar su propia entropía en el espacio del usuario para que puedan usarla como mejor les parezca. Él dice que la recopilación de entropía no es un proceso que puede realizar el núcleo en todo tipo de hardware soportado por él, además, el núcleo en sí mismo no puede estimar la cantidad de entropía proporcionada por varias fuentes.
"El núcleo no debe mezclar diferentes fuentes de ruido y, por supuesto, no debe intentar afirmar que sabe cuántos bits de entropía recibe cuando intenta jugar algún tipo de" juego desigual de entropía "en una arquitectura de CPU simple para el usuario feo "Casos IOT / Embedded, cuando todo está fuera de sincronización con un solo generador maestro, cuando no hay instrucciones de CPU para reordenar o renombrar el registro, etc."
“Podemos hablar acerca de proporcionar herramientas que intenten hacer estos cálculos, pero tales cosas deberían llevarse a cabo en el equipo de cada usuario, lo que para la mayoría de los usuarios del kit de distribución no es práctico. Si esto está destinado solo a criptógrafos, deje que se haga en su espacio de usuario. Y no simplifiquemos GPG, OpenSSL, etc., para que todos digan: "queremos" aleatoriedad verdadera "y no estamos de acuerdo en nada menos". Podemos hablar sobre cómo proporcionamos interfaces a los criptógrafos para que puedan obtener la información necesaria a través del acceso a fuentes de ruido primarias, separadas y nombradas, y, posiblemente, de alguna manera, la fuente de ruido puede autenticarse en una biblioteca o aplicación de espacio de usuario ".Hubo una pequeña discusión sobre cómo podría verse esa interfaz, porque, por ejemplo, para algunos eventos puede haber implicaciones de seguridad. Cao señaló que los códigos de exploración del teclado (es decir, las pulsaciones de teclas) se mezclan en el grupo como parte de la recopilación de entropía: "Transferir esto al espacio del usuario, incluso a través de una llamada privilegiada del sistema, sería al menos irrazonable". Es posible que otros tiempos de eventos puedan crear algún tipo de fuga de información a través de canales laterales.
Por lo tanto, existe la sensación de que el problema de larga data del subsistema de números aleatorios de Linux está en camino a una solución. Los cambios que ha sufrido recientemente el subsistema de números aleatorios, de hecho, solo condujeron a problemas DoS en el proceso de su uso. Ahora hay formas efectivas de obtener los mejores números aleatorios que el núcleo puede proporcionar. Si TRNG sigue siendo deseable para Linux, entonces esta deficiencia deberá abordarse en el futuro, pero lo más probable es que no se haga dentro del núcleo mismo.
Un poco de publicidad :)
Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos
VPS basado en la nube para desarrolladores desde $ 4.99 , un
análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles 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 tenemos
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre
Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?