Sábese que /dev/random, un xerador de números pseudoaleatorios criptograficamente seguro (CSPRNG), ten un problema molesto: o bloqueo. Este artigo explica como podes resolvelo.
Durante os últimos meses, as instalacións de xeración de números aleatorios no núcleo foron lixeiramente reelaboradas, pero os problemas deste subsistema foron resoltos ao longo do proceso máis amplo. . O máis fixéronse para evitar que a chamada ao sistema getrandom() se bloquee durante moito tempo cando se inicia o sistema, pero a razón subxacente foi o comportamento de bloqueo do grupo aleatorio. Un parche recente tería eliminado esta piscina e sería de esperar que se dirixise ao núcleo principal.
Andy Lutomirski publicou a terceira versión do parche a finais de decembro. El contribúe "dous cambios semánticos importantes para as API aleatorias de Linux". O parche engade unha nova marca GRND_INSECURE á chamada do sistema getrandom() (aínda que Lutomirsky refírese a ela como getentropy(), que se implementa en glibc usando getrandom() con bandeiras fixas); esta marca fai que a chamada devolva sempre a cantidade de datos solicitados, pero sen garantir que os datos sexan aleatorios. O núcleo simplemente fará todo o posible para producir os mellores datos aleatorios que teña no momento dado. "Probablemente o mellor que podes facer é chamalo 'INSEGURO' (inseguro) para evitar que esta API se use para cousas que necesitan seguridade".
Os parches tamén eliminan o grupo de bloqueo. O kernel mantén actualmente dous conxuntos de datos aleatorios, un correspondente a /dev/random e outro a /dev/urandom, como se describe neste 2015. O grupo de bloqueo é o grupo de /dev/random; as lecturas para ese dispositivo bloquearanse (que significa o seu nome) ata que se recollese "suficiente" entropía do sistema para satisfacer a solicitude. Tamén se bloquean as lecturas posteriores deste ficheiro se non hai suficiente entropía no grupo.
Eliminar o grupo de bloqueos significa que a lectura de /dev/random compórtase como getrandom() con bandeiras configuradas en cero (e converte a bandeira GRND_RANDOM nun noop). Unha vez que se inicialice o xerador de números aleatorios criptográficos (CRNG), a lectura de /dev/random e as chamadas a getrandom(...,0) non se bloquearán e devolverá a cantidade solicitada de datos aleatorios.
Lutomirsky di: "Creo que o grupo de bloqueo de Linux quedou obsoleto. CRNG Linux xera unha saída o suficientemente boa como para ser usada incluso para a xeración de claves. O grupo de bloqueo non é máis forte en ningún sentido material e require moita infraestrutura de dubidoso valor para apoialo".
Os cambios fixéronse co obxectivo de garantir que os programas existentes non se verían realmente afectados e, de feito, habería menos problemas con longas esperas para cousas como a xeración de claves GnuPG.
"Estes episodios non deben perturbar ningún programa existente. /dev/urandom permanece sen cambios. /dev/random aínda bloquea inmediatamente despois do arranque, pero bloquea menos que antes. getentropy() coas marcas existentes devolverá un resultado que é tan axeitado para fins prácticos como antes."
Lutomirsky observou que aínda é unha cuestión aberta se o núcleo debería proporcionar os chamados "números aleatorios verdadeiros", que é o que se supón que debía facer o núcleo de bloqueo ata certo punto. Só ve unha razón para iso: "o cumprimento dos estándares gobernamentais". Lutomirsky suxeriu que se o núcleo fornece isto, debería facerse a través dunha interface completamente diferente, ou debería moverse ao espazo do usuario, permitindo ao usuario recuperar mostras de eventos en bruto que poderían usarse para crear tal grupo de bloqueos.
Stephan Müller suxeriu que o seu conxunto para Linux Random Number Generator (LRNG) (actualmente lanzada a versión 26) podería ser unha forma de proporcionar verdadeiros números aleatorios para as aplicacións que o necesiten. LRNG cumpre "totalmente coas directrices SP800-90B sobre fontes de entropía utilizadas para xerar bits aleatorios", polo que é unha solución ao problema dos estándares gobernamentais.
Matthew Garrett opúxose ao termo "datos aleatorios verdadeiros", sinalando que os dispositivos mostrados poderían en principio modelarse con precisión suficiente para facelos previsibles: "non estamos mostrando eventos cuánticos aquí".
Müller respondeu que o termo provén do estándar alemán AIS 31 para describir un xerador de números aleatorios que só produce un resultado "ao mesmo ritmo que a fonte de ruído subxacente produce entropía".
Deixando a un lado as diferenzas de terminoloxía, ter un grupo de bloqueos como o suxiren os parches de LRNG simplemente levará a varios problemas, polo menos se se accede sen privilexios.
Como dixo Lutomirsky: "Isto non resolve o problema. Se dous usuarios diferentes executan programas estúpidos como gnupg, simplemente esgotaranse entre si. Vexo que actualmente hai dous problemas principais con /dev/random: é propenso a DoS (é dicir, esgotamento de recursos, influencia maliciosa ou algo similar) e como non se requiren privilexios para usalo, tamén é propenso a abusos. Gnupg está mal, é un colapso total. Se engadimos unha nova interface sen privilexios que usarán gnupg e programas similares, volveremos perder".
Mueller sinalou que a adición de getrandom() agora permitirá que GnuPG use esta interface, xa que proporcionará a garantía necesaria de que o grupo foi inicializado. Baseándose nas discusións co desenvolvedor de GnuPG Werner Koch, Mueller cre que a garantía é a única razón pola que GnuPG le actualmente directamente desde /dev/random. Pero se hai unha interface sen privilexios que é susceptible de denegación de servizo (como é hoxe /dev/random), Lutomirsky argumenta que será usada incorrectamente por algunhas aplicacións.
Theodore Yue Tak Ts'o, desenvolvedor do subsistema de números aleatorios de Linux, parece ter cambiado de opinión sobre a necesidade dun grupo de bloqueo. Dixo que eliminar este grupo eliminaría efectivamente a idea de que Linux ten un verdadeiro xerador de números aleatorios (TRNG): "isto non é unha tontería, xa que isto é exactamente o que *BSD fixo sempre".
Tamén lle preocupa que proporcionar un mecanismo TRNG simplemente sirva de cebo para os desenvolvedores de aplicacións e cre que, de feito, dados os diferentes tipos de hardware soportados por Linux, é imposible garantir TRNG no núcleo. Incluso a capacidade de traballar con equipos só con privilexios de root non resolverá o problema: "Os desenvolvedores de aplicacións especifican que a súa aplicación se instale como root por motivos de seguridade, para que este sexa o único xeito de acceder aos números aleatorios "moi bos".
Mueller preguntou se Cao abandonara a implementación do grupo de bloqueo que el mesmo propuxera hai tempo. Cao respondeu que planea tomar os parches de Lutomirsky e oponse activamente a engadir unha interface de bloqueo de volta ao núcleo.
"O núcleo non pode ofrecer ningunha garantía sobre se a fonte de ruído foi caracterizada correctamente. O único que pode ter un desenvolvedor de GPG ou OpenSSL é unha vaga sensación de que TRUERANDOM é "mellor", e como queren máis seguridade, sen dúbida tentarán usalo. Nalgún momento bloquearase e cando algún outro usuario intelixente (quizais un especialista en distribución) o insira no script de inicio e os sistemas deixen de funcionar, os usuarios só terán que queixarse ante o propio Linus Torvalds".
Cao tamén avoga por dar aos criptógrafos e aos que realmente necesitan TRNG unha forma de recoller a súa propia entropía no espazo do usuario para usala como consideren oportuno. El di que a recollida de entropía non é un proceso que poida realizar o núcleo en todos os diferentes hardware que admite, nin o propio núcleo pode estimar a cantidade de entropía proporcionada polas diferentes fontes.
"O núcleo non debería mesturar diferentes fontes de ruído xuntos, e certamente non debería intentar pretender saber cantos bits de entropía está a ter cando intenta xogar algún tipo de "xogo de entropía nerviosa" nunha CPU escandalosamente sinxela. arquitectura para usuarios consumidores. Casos IOT/Embedded nos que todo está fóra de sincronía cun único oscilador mestre, onde non hai instrucións da CPU para reordenar ou renomear un rexistro, etc.
“Pódese falar de proporcionar ferramentas que intenten facer estes cálculos, pero tales cousas hai que facerlas no hardware de cada usuario, o que simplemente non é práctico para a maioría dos usuarios da distribución. Se isto só está pensado para criptógrafos, déixao facer no seu espazo de usuario. E non simplifiquemos GPG, OpenSSL, etc para que todos digan "queremos "auténtica aleatoriedade" e non nos conformamos con menos". Podemos falar de como fornecemos interfaces aos criptógrafos para que poidan obter a información que necesitan accedendo ás fontes de ruído primarias, separadas e nomeadas, e quizais dalgún xeito a fonte de ruído poida autenticarse nunha biblioteca ou na aplicación do espazo do usuario".
Houbo algunha discusión sobre como podería ser tal interface, xa que, por exemplo, podería haber implicacións de seguridade para algúns eventos. Cao observou que os códigos de exploración do teclado (é dicir, as pulsacións de teclas) mestúranse nun grupo como parte da recollida de entropía: "Traer isto ao espazo do usuario, mesmo a través dunha chamada ao sistema privilexiada, sería pouco prudente dicir". É moi posible que outros tempos de eventos poidan crear algún tipo de fuga de información a través de canles laterais.
Polo tanto, parece que un problema de longa data co subsistema de números aleatorios de Linux está en camiño dunha solución. Os cambios que sufriu recentemente o subsistema de números aleatorios só deron lugar a problemas de DoS ao usalo. Agora hai formas eficientes de obter os mellores números aleatorios que o núcleo pode proporcionar. Se TRNG aínda é desexable en Linux, entón este fallo terá que ser abordado no futuro, pero o máis probable é que isto non se faga no propio núcleo.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com