Como você sabe, / dev / random, um gerador de números pseudo-aleatórios criptograficamente fortes (CSPRNG), tem um problema desagradável - o bloqueio. Este artigo descreve como resolvê-lo.
Nos últimos meses, os meios de gerar números aleatórios no kernel foram ligeiramente reformulados, mas os problemas nesse subsistema foram resolvidos em um
período mais amplo. As
alterações mais
recentes foram feitas para impedir que a chamada do sistema getrandom () seja bloqueada por um longo tempo durante a inicialização do sistema, mas a razão por trás disso foi o comportamento do pool aleatório de bloqueio. Um patch recente removeria esse pool e era de se esperar que fosse para o núcleo principal.
Andy Lutomirski lançou a terceira versão do patch no final de dezembro. Faz
"duas alterações semânticas básicas nas APIs aleatórias do Linux" . O patch adiciona o novo sinalizador GRND_INSECURE à chamada do sistema getrandom () (embora Lutomirsky se refira a ele como getentropy (), que é implementado no glibc usando getrandom () com sinalizadores fixos); esse sinalizador força a chamada a sempre retornar a quantidade de dados solicitados, mas sem garantir que os dados sejam aleatórios. O kernel simplesmente fará o possível para fornecer os melhores dados aleatórios que possui em um determinado momento.
“Provavelmente a melhor coisa que você pode fazer é chamá-lo de“ INSEGURO ” (inseguro) para impedir que seja usado para coisas que precisam de segurança.”
Os patches também removem o pool de bloqueio. Atualmente, o kernel suporta dois conjuntos de dados aleatórios, um dos quais corresponde a / dev / random e o outro a / dev / urandom, conforme descrito neste
artigo de 2015. Um pool de bloqueio é um pool para / dev / random; a leitura deste dispositivo será bloqueada (ou seja, seu nome) até que a entropia "suficiente" seja coletada do sistema para atender à solicitação. Leituras adicionais deste arquivo também serão bloqueadas se não houver entropia suficiente no pool.
A remoção do conjunto de bloqueios significa que a leitura de / dev / random se comporta como getrandom () com o valor de sinalizadores definido como zero (e transforma o sinalizador GRND_RANDOM em noop). Após inicializar o gerador de números aleatórios criptográficos (CRNG), a leitura de / dev / random e a chamada getrandom (..., 0) não serão bloqueadas e retornarão a quantidade solicitada de dados aleatórios.
Lutomirsky diz:
“Eu acredito que o pool de bloqueio do Linux se tornou obsoleto. O CRNG Linux gera uma saída que é boa o suficiente para usar, 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 mantê-lo. ”As mudanças foram feitas com o objetivo de garantir que os programas existentes não sofram realmente e, de fato, os problemas com a longa espera por coisas como gerar chaves do GnuPG se tornarão menores.
“Essas séries não devem violar nenhum programa existente. / dev / urandom permanece inalterado. / dev / random ainda bloqueia imediatamente após o carregamento, mas bloqueia menos que antes. getentropy () com sinalizadores existentes retornará um resultado que será tão prático para a finalidade quanto antes. ”Lutomirsky observou que permanece em aberto a questão de saber se o núcleo deve fornecer os chamados "números aleatórios verdadeiros", que até certo ponto deveriam ter sido feitos pelo núcleo de bloqueio. Ele vê apenas uma razão para isso: "conformidade com os padrões do estado". Lutomirsky sugeriu que, se o kernel fornecer isso, isso deve ser feito por meio de uma interface completamente diferente ou deve ser transferido para o espaço do usuário, permitindo recuperar padrões de eventos não processados que podem ser usados para criar um pool de bloqueios.
Stephan Müller sugeriu que seu conjunto de
patches para o gerador de números aleatórios do Linux (LRNG) (a versão 26 está atualmente liberada) pode ser uma maneira de fornecer números aleatórios verdadeiros para aplicativos que precisam dele. O LRNG "cumpre totalmente os requisitos das" Recomendações sobre as fontes de entropia usadas para gerar bits aleatórios "SP800-90B", o que o torna uma solução para o problema dos padrões estaduais.
Matthew Garrett opôs-se ao termo "dados aleatórios verdadeiros", observando que dispositivos selecionáveis podem, em princípio, ser modelados com precisão suficiente para torná-los previsíveis: "não estamos recebendo eventos quânticos aqui".
Muller respondeu que o termo vem do padrão alemão AIS 31 para descrever um gerador de números aleatórios que produz apenas o resultado "na mesma velocidade que a fonte de ruído subjacente produz entropia".
Além dos mal-entendidos da terminologia, a presença de um pool de bloqueios, conforme sugerido pelos patches do LRNG, simplesmente levará a vários problemas, pelo menos se estiver disponível sem privilégios.
Como Lutomirsky disse:
“Isso não resolve o problema. Se dois usuários diferentes executam programas estúpidos, como o gnupg, eles simplesmente se esgotam. Vejo que atualmente existem dois problemas principais com / dev / random: ele é suscetível a DoS (ou seja, esgotamento de recursos, influências prejudiciais ou algo semelhante) e, como não requer privilégios para usá-lo, também sujeito a abuso. Gnupg está errado, é um colapso completo. Se adicionarmos uma nova interface não privilegiada que o gnupg e programas similares usarão, perderemos novamente. ”Muller observou que a adição de getrandom () agora permitirá que o GnuPG use essa interface, pois fornecerá a garantia necessária de que o pool foi inicializado. Com base nas discussões com o desenvolvedor do GnuPG Werner Koch, Muller acredita que a garantia é a única razão pela qual o GnuPG atualmente lê diretamente em / dev / random. Mas se houver uma interface sem privilégios que esteja sujeita a uma negação de serviço (a partir de hoje / dev / random), então, de acordo com Lutomirsky, ela será mal utilizada por alguns aplicativos.
Theodore Yue Tak Ts'o, o desenvolvedor do subsistema de números aleatórios do Linux, parece ter mudado de idéia sobre a necessidade de um pool de bloqueio. Ele disse que a exclusão desse pool eliminaria efetivamente a idéia de que o Linux tem um verdadeiro gerador de números aleatórios (TRNG):
"isso não é bobagem, pois é exatamente isso que o * BSD sempre fez".Ele também está preocupado com o fato de que o fornecimento do mecanismo TRNG sirva simplesmente de chamariz para os desenvolvedores de aplicativos e acredita que, na realidade, considerando os vários tipos de hardware suportados pelo Linux, não é possível garantir o TRNG no kernel. Mesmo a capacidade de trabalhar com equipamentos baseados em privilégios de root não resolverá o problema:
“Os desenvolvedores de aplicativos especificam que seus aplicativos sejam instalados como raiz por razões de segurança, porque esta é a única maneira de acessar números aleatórios“ realmente bons ””.Muller perguntou se Cao se recusara a implementar o pool de bloqueio, que ele próprio havia proposto há muito tempo. Cao respondeu que planejava usar os patches de Lutomirsky e se opôs ativamente a adicionar uma interface de bloqueio ao kernel.
“O kernel não pode dar nenhuma garantia sobre se a fonte de ruído foi adequadamente caracterizada. A única coisa que um desenvolvedor de GPG ou OpenSSL pode obter é a vaga sensação de que o TRUERANDOM é "melhor" e, como eles querem mais segurança, sem dúvida tentarão usá-lo. Em algum momento, ele será bloqueado e, quando outro usuário inteligente (talvez um especialista em distribuição) o inserir no script init e os sistemas pararem de funcionar, os usuários terão apenas que reclamar com o próprio Linus Torvalds. ”Cao também defende fornecer aos criptografadores e àqueles que realmente precisam do TRNG uma maneira de coletar sua própria entropia no espaço do usuário, para que possam usá-lo como entenderem. Ele diz que a coleta de entropia não é um processo que pode ser executado pelo kernel em todos os tipos de hardware suportados por ele; além disso, o próprio kernel não pode estimar a quantidade de entropia fornecida por várias fontes.
“O kernel não deve misturar diferentes fontes de ruído e, é claro, não deve tentar afirmar que sabe quantos bits de entropia recebe quando tenta executar algum tipo de“ jogo brusco de entropia ”em uma arquitetura de CPU simples para o usuário feio. "Casos IOT / Embutidos, quando tudo está fora de sincronia com um único gerador mestre, quando não há instruções da CPU para reordenar ou renomear o registro, etc."
“Podemos falar sobre o fornecimento de ferramentas que tentam fazer esses cálculos, mas essas coisas devem ser realizadas no equipamento de cada usuário, o que para a maioria dos usuários do kit de distribuição é simplesmente impraticável. Se isso for destinado apenas a criptografadores, faça-o no espaço do usuário. E não vamos simplificar o GPG, o OpenSSL etc., para que todos digam: "queremos" verdadeira aleatoriedade "e não concordemos com nada menos". Podemos falar sobre como fornecemos interfaces para os criptografadores, para que eles possam obter as informações necessárias através do acesso a fontes de ruído primárias, separadas e nomeadas e, possivelmente, de alguma forma, a fonte de ruído pode se autenticar em uma biblioteca ou aplicativo de espaço do usuário. ”Houve uma pequena discussão sobre como essa interface pode parecer, porque, por exemplo, para alguns eventos, pode haver implicações de segurança. Cao observou que os códigos de verificação do teclado (ou seja, pressionamentos de tecla) são misturados no pool como parte da coleção de entropia: "Transferir isso para o espaço do usuário, mesmo através de uma chamada privilegiada do sistema, seria pelo menos irracional". É possível que outros tempos de eventos possam criar algum tipo de vazamento de informações através dos canais laterais.
Portanto, parece que o problema de longa data do 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, de fato, levaram apenas a problemas de DoS no processo de seu uso. Agora, existem maneiras eficazes de obter os melhores números aleatórios que o kernel pode fornecer. Se o TRNG ainda for desejável para o Linux, essa falha precisará ser resolvida no futuro, mas provavelmente não será feita dentro do próprio kernel.
Um pouco de publicidade :)
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos
VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um
analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps de 10GB de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente temos
2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?