/dev/random, um gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG), é conhecido por ter um problema irritante: bloqueio. Este artigo explica como você pode resolver isso.
Nos últimos meses, os recursos de geração de números aleatórios no kernel foram ligeiramente reformulados, mas os problemas neste subsistema foram resolvidos ao longo do curso mais amplo. . Maioria foram feitas para evitar que a chamada do sistema getrandom() bloqueasse por um longo tempo quando o sistema inicializa, mas a razão subjacente para isso foi o comportamento de bloqueio do pool aleatório. Um patch recente teria removido esse pool e seria esperado que ele se dirigisse ao núcleo principal.
Andy Lutomirski publicou a terceira versão do patch no final de dezembro. Ele contribui "duas grandes mudanças semânticas em APIs aleatórias do Linux". O patch adiciona um novo sinalizador GRND_INSECURE à chamada de sistema getrandom() (embora Lutomirsky se refira a ele como getentropy(), que é implementado em glibc usando getrandom() com sinalizadores fixos); esta flag faz com que a chamada retorne sempre a quantidade de dados solicitada, mas sem garantir que os dados sejam aleatórios. O kernel simplesmente fará o melhor para produzir os melhores dados aleatórios que possui em um determinado momento. "Provavelmente a melhor coisa a fazer é chamá-lo de 'INSEGURO' (inseguro) para evitar que esta API seja usada para coisas que precisam de segurança."
Os patches também removem o pool de bloqueio. O kernel atualmente mantém dois conjuntos de dados aleatórios, um correspondente a /dev/random e outro a /dev/urandom, conforme descrito neste 2015. O pool de bloqueio é o pool para /dev/random; as leituras desse dispositivo serão bloqueadas (ou seja, seu nome) até que entropia "suficiente" seja coletada do sistema para satisfazer a solicitação. Outras leituras deste arquivo também serão bloqueadas se não houver entropia suficiente no pool.
Remover o pool de bloqueios significa que a leitura de /dev/random se comporta como getrandom() com sinalizadores definidos como zero (e transforma o sinalizador GRND_RANDOM em um noop). Depois que o gerador criptográfico de números aleatórios (CRNG) for inicializado, a leitura de /dev/random e as chamadas para getrandom(...,0) não serão bloqueadas e retornarão a quantidade solicitada de dados aleatórios.
Lutomirsky disse: “Acredito que o pool de bloqueio do Linux se tornou obsoleto. O CRNG Linux gera uma saída boa o suficiente para ser usada até mesmo na geração de chaves. O pool de bloqueio não é mais forte em nenhum sentido material e requer muita infraestrutura de valor duvidoso para apoiá-lo.”
As alterações foram feitas com o objetivo de garantir que os programas existentes não seriam realmente afetados e, de fato, haveria menos problemas com longas esperas por coisas como a geração de chaves do GnuPG.
“Esses episódios não devem atrapalhar nenhum programa existente. /dev/urandom permanece inalterado. /dev/random ainda bloqueia imediatamente após a inicialização, mas bloqueia menos do que antes. getentropy() com os sinalizadores existentes retornará um resultado que é tão adequado para fins práticos quanto antes."
Lutomirsky observou que ainda é uma questão em aberto se o kernel deve fornecer os chamados “números aleatórios verdadeiros”, que é o que o kernel bloqueador deveria fazer até certo ponto. Ele vê apenas uma razão para isso: “conformidade com os padrões governamentais”. Lutomirsky sugeriu que se o kernel fornecesse isso, isso deveria ser feito através de uma interface completamente diferente, ou deveria ser movido para o espaço do usuário, permitindo ao usuário recuperar amostras de eventos brutos que poderiam ser usadas para criar tal pool de bloqueios.
Stephan Müller sugeriu que seu set para Linux Random Number Generator (LRNG) (atualmente versão 26 lançada) pode ser uma maneira de fornecer números aleatórios verdadeiros para aplicativos que precisam deles. O LRNG é “totalmente compatível com as Diretrizes SP800-90B sobre fontes de entropia usadas para gerar bits aleatórios”, tornando-o uma solução para o problema de padrões governamentais.
Matthew Garrett opôs-se ao termo “dados aleatórios verdadeiros”, observando que os dispositivos amostrados poderiam, em princípio, ser modelados com precisão suficiente para torná-los previsíveis: “não estamos amostrando eventos quânticos aqui”.
Müller respondeu que o termo vem do padrão alemão AIS 31 para descrever um gerador de números aleatórios que só produz um resultado "na mesma taxa em que a fonte de ruído subjacente produz entropia".
Deixando de lado as diferenças de terminologia, ter um pool de bloqueios conforme sugerido pelos patches do LRNG simplesmente levará a vários problemas, pelo menos se for acessado sem privilégios.
Como disse Lutomirsky: “Isso não resolve o problema. Se dois usuários diferentes executarem programas estúpidos como o gnupg, eles simplesmente irão drenar um ao outro. Vejo que atualmente existem dois problemas principais com /dev/random: ele é propenso a DoS (ou seja, esgotamento de recursos, influência maliciosa ou algo semelhante) e, como não são necessários privilégios para usá-lo, também é propenso a abusos. O Gnupg está errado, é um colapso total. Se adicionarmos uma nova interface sem privilégios que o gnupg e programas similares usarão, perderemos novamente."
Mueller observou que a adição de getrandom() agora permitirá ao GnuPG usar esta interface, pois fornecerá a garantia necessária de que o pool foi inicializado. Com base em discussões com o desenvolvedor do GnuPG, Werner Koch, Mueller acredita que a garantia é a única razão pela qual o GnuPG atualmente lê diretamente de /dev/random. Mas se houver uma interface sem privilégios que seja suscetível à negação de serviço (como é o /dev/random hoje), Lutomirsky argumenta que ela será mal utilizada por alguns aplicativos.
Theodore Yue Tak Ts'o, desenvolvedor do subsistema de números aleatórios do Linux, parece ter mudado de ideia sobre a necessidade de um pool de bloqueio. Ele disse que a remoção desse pool eliminaria efetivamente a ideia de que o Linux possui um verdadeiro gerador de números aleatórios (TRNG): "isso não é bobagem, já que é exatamente isso que o *BSD sempre fez."
Ele também está preocupado com o fato de que fornecer um mecanismo TRNG servirá simplesmente como isca para desenvolvedores de aplicativos e acredita que, de fato, dados os diferentes tipos de hardware suportados pelo Linux, é impossível garantir o TRNG no kernel. Mesmo a capacidade de trabalhar com equipamentos apenas com privilégios de root não resolverá o problema: "Os desenvolvedores de aplicativos especificam que seus aplicativos sejam instalados como root por motivos de segurança, de modo que esta seja a única maneira de acessar os números aleatórios 'realmente bons'."
Mueller perguntou se Cao havia abandonado a implementação do pool de bloqueio que ele próprio havia proposto há muito tempo. Cao respondeu que planeja adotar os patches de Lutomirsky e se opõe ativamente à adição de uma interface de bloqueio ao kernel.
“O kernel não pode dar nenhuma garantia se a fonte de ruído foi devidamente caracterizada. A única coisa que um desenvolvedor GPG ou OpenSSL pode ter é uma vaga sensação de que TRUERANDOM é "melhor" e, como desejam mais segurança, sem dúvida tentarão usá-lo. Em algum momento ele será bloqueado, e quando algum outro usuário inteligente (talvez um especialista em distribuição) o inserir no script de inicialização e os sistemas pararem de funcionar, os usuários só terão que reclamar com o próprio Linus Torvalds."
Cao também defende dar aos criptógrafos e àqueles que realmente precisam do TRNG uma maneira de coletar sua própria entropia no espaço do usuário para usar como acharem adequado. Ele diz que a coleta de entropia não é um processo que pode ser executado pelo kernel em todos os diferentes hardwares que ele suporta, nem o próprio kernel pode estimar a quantidade de entropia fornecida por diferentes fontes.
"O kernel não deveria estar misturando diferentes fontes de ruído, e certamente não deveria estar tentando afirmar que sabe quantos bits de entropia está obtendo quando está tentando jogar algum tipo de" jogo de entropia inquieto "em uma CPU escandalosamente simples arquitetura para usuários consumidores. Casos IOT/Embedded onde tudo está fora de sincronia com um único oscilador mestre, onde não há instrução de CPU para reordenar ou renomear um registro, etc.
“Podemos falar em fornecer ferramentas que tentem fazer esses cálculos, mas essas coisas precisam ser feitas no hardware de cada usuário, o que simplesmente não é prático para a maioria dos usuários de distribuição. Se isso for destinado apenas a criptógrafos, deixe-o ser feito em seu espaço de usuário. E não vamos simplificar GPG, OpenSSL, etc. para que todos digam "queremos" verdadeira aleatoriedade "e não nos contentaremos com menos". Podemos falar sobre como fornecemos interfaces aos criptógrafos para que eles possam obter as informações de que precisam acessando as fontes primárias de ruído, separadas e nomeadas, e talvez de alguma forma a fonte de ruído possa se autenticar em uma biblioteca ou aplicativo de espaço do usuário."
Houve alguma discussão sobre como seria essa interface, já que, por exemplo, poderia haver implicações de segurança para alguns eventos. Cao observou que os códigos de varredura do teclado (ou seja, pressionamentos de teclas) são misturados em um pool como parte da coleta de entropia: “Trazer isso para o espaço do usuário, mesmo por meio de uma chamada de sistema privilegiada, seria no mínimo imprudente”. É bem possível que outros horários de eventos criem algum tipo de vazamento de informações através de canais secundários.
Portanto, parece que um problema antigo com o subsistema de números aleatórios do Linux está a caminho de uma solução. As mudanças pelas quais o subsistema de números aleatórios passou recentemente resultaram apenas em problemas de DoS durante seu uso. Agora existem maneiras eficientes de obter os melhores números aleatórios que o kernel pode fornecer. Se o TRNG ainda for desejável no Linux, então essa falha precisará ser corrigida no futuro, mas muito provavelmente isso não será feito no próprio kernel.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com