Como é sabido, o /dev/random, um gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG), tem um problema desagradável - bloqueios. Este artigo explica como é possível resolvê-lo.
Nos últimos meses, os meios de geração de números aleatórios no núcleo foram um pouco revisados, mas problemas nesse subsistema foram resolvidos ao longo de um período mais amplo. As mais foram feitas com o objetivo de evitar o bloqueio prolongado da chamada de sistema getrandom() durante a inicialização do sistema, sendo que a causa subjacente era o comportamento do pool aleatório bloqueante. Um patch recente removeria esse pool, e esperava-se que ele fosse integrado ao núcleo principal.
Andy Lutomirski publicou a terceira versão do patch no final de dezembro. Ele introduz «duas mudanças semânticas principais nas API aleatórias do Linux».O patch adiciona uma nova flag GRND_INSECURE à chamada de sistema getrandom() (embora Lutomirski se refira a ele como getentropy(), que é implementado na glibc usando getrandom() com flags fixas); essa flag faz com que a chamada sempre retorne a quantidade de dados solicitada, mas sem garantia de que esses dados sejam aleatórios. O núcleo apenas fará o seu melhor para fornecer os melhores dados aleatórios que possui naquele momento. «Provavelmente, o melhor que pode ser feito é nomeá-lo de „INSECURE“ para impedir o uso dessa API para coisas que necessitam de segurança».
Os patches também removem o pool bloqueante. Atualmente, o núcleo mantém dois pools de dados aleatórios, um correspondente ao /dev/random e o outro ao /dev/urandom, conforme descrito neste documento de 2015. O pool bloqueante é o pool para /dev/random; a leitura para esse dispositivo será bloqueada (referindo-se ao seu nome) até que uma quantidade «suficiente» de entropia seja coletada do sistema para atender à solicitação. Leituras subsequentes desse arquivo também são bloqueadas se o pool não tiver entropia suficiente.
A remoção do pool de bloqueio significa que a leitura de /dev/random se comporta como getrandom() com o valor de flags igual a zero (transformando a flag GRND_RANDOM em noop). Após a inicialização do gerador criptográfico de números aleatórios (CRNG), a leitura de /dev/random e as chamadas getrandom(…,0) não causarão bloqueio e retornarão a quantidade solicitada de dados aleatórios.
Lutomirski diz: “Eu considero que o pool de bloqueio do Linux se tornou obsoleto. O CRNG do Linux gera saídas que são boas o suficiente para serem usadas até mesmo para a geração de chaves. O pool de bloqueio não é mais forte de qualquer maneira material, e sua manutenção requer mucha infraestrutura de valor duvidoso.”
Mudanças foram feitas com o objetivo de que os programas existentes realmente não fossem afetados, e na verdade, os problemas com longas esperas para coisas como a geração de chaves GnuPG serão reduzidos.
“Essas séries não devem interferir em nenhum programa existente. /dev/urandom permanece inalterado. /dev/random ainda é bloqueado imediatamente após a inicialização, mas está bloqueado menos do que antes. getentropy() com as flags existentes retornará um resultado que será igualmente adequado para fins práticos, como antes.”
Lutomirski apontou que ainda há uma questão em aberto sobre se o núcleo deve fornecer os chamados 'números verdadeiramente aleatórios', o que em certa medida deveria ser feito pelo núcleo de bloqueio. Ele vê apenas uma razão para isso: 'cumprir normas governamentais'. Lutomirski sugeriu que, se o núcleo deve garantir isso, deve ser feito por meio de uma interface completamente diferente ou deve ser transferido para o espaço do usuário, permitindo que ele extraia amostras brutas de eventos que podem ser usadas para criar tal pool de bloqueio.
Stephan Müller sugeriu que seu conjunto O gerador de números aleatórios do Linux (LRNG) (atualmente na versão 26) pode ser uma forma de fornecer números verdadeiramente aleatórios para aplicações que necessitam. O LRNG "atende completamente aos requisitos das 'Diretrizes sobre fontes de entropia utilizadas para gerar bits aleatórios' SP800-90B", o que o torna uma solução para o problema dos padrões governamentais.
Matthew Garrett contestou o termo "dados verdadeiramente aleatórios", observando que os dispositivos selecionados podem, em princípio, ser modelados com precisão suficiente para torná-los previsíveis: "não estamos coletando eventos quânticos aqui".
Müller respondeu que esse termo provém do padrão alemão AIS 31 para descrever um gerador de números aleatórios que apenas fornece resultados "na mesma velocidade com que a fonte básica de ruído gera entropia."
Além das ambiguidades terminológicas, a existência de um pool de bloqueio, como proposto por patches do LRNG, simplesmente levará a vários problemas, pelo menos se estiver acessível sem privilégios.
Como disse Lutomirski: "Isso não resolve o problema. Se dois usuários diferentes executarem programas bobos, como o gnupg, eles simplesmente esgotarão um ao outro. Vejo que atualmente existem dois problemas principais com /dev/random: ele é suscetível a DoS (ou seja, esgotamento de recursos, influência maliciosa ou algo semelhante), e, uma vez que nenhum privilégio para seu uso é necessário, ele também é propenso a abusos. O Gnupg é um erro, é um colapso total. Se adicionarmos uma nova interface não privilegiada que será utilizada pelo gnupg e programas semelhantes, voltaremos a perder."
Müller observou que a adição do getrandom() agora permitirá que o GnuPG utilize essa interface, pois garantirá que o pool foi inicializado. Com base nas discussões com o desenvolvedor do GnuPG, Werner Koch, Müller acredita que a garantia é a única razão pela qual o GnuPG atualmente lê diretamente de /dev/random. Mas se houver uma interface não privilegiada suscetível a negação de serviço (como é hoje /dev/random), então, segundo Lutomirski, ela será mal utilizada por alguns aplicativos.
Theodore Yue Tak Ts’o, desenvolvedor do subsistema de números aleatórios do Linux, aparentemente mudou de ideia sobre a necessidade de um pool bloqueador. Ele afirmou que a remoção desse pool permitiria se livrar efetivamente da ideia de que o Linux tem um verdadeiro gerador de números aleatórios (TRNG): "isso não é um non-sense, pois é exatamente o que sempre fizeram os *BSD."
Ele também expressou preocupação de que fornecer um mecanismo TRNG serviria apenas como um atrativo para desenvolvedores de aplicativos e acredita que, na verdade, considerando os diferentes tipos de hardware suportados pelo Linux, não é possível garantir um TRNG no núcleo. O problema não será resolvido nem mesmo pela possibilidade de trabalhar com o hardware apenas com privilégios de root: "Desenvolvedores de aplicativos indicam que seu aplicativo por questões de segurança deve ser instalado como root, pois só assim você pode acessar números aleatórios 'realmente bons'."
Müller perguntou se Ts’o havia desistido da implementação do pool bloqueador, que ele mesmo havia proposto há muito tempo. Ts’o respondeu que planeja adotar os patches de Lutomi e se opõe ativamente à reintegração da interface bloqueadora ao núcleo.
"O núcleo não pode garantir se a fonte de ruído foi caracterizada adequadamente. A única coisa que um desenvolvedor de GPG ou OpenSSL pode obter é uma vaga sensação de que o TRUERANDOM é 'melhor', e como eles desejam maior segurança, certamente tentarão utilizá-lo. Em determinado momento, ele será bloqueado, e quando algum outro usuário inteligente (talvez um especialista em release de distribuição) o inserir no script init e os sistemas pararem de funcionar, os usuários só poderão reclamar diretamente a Linus Torvalds."
Ts’o também defende que se deve fornecer aos criptógrafos e àqueles que realmente precisam de TRNG uma forma de coletar sua própria entropia no espaço do usuário, para utilizá-la como desejarem. Ele afirma que a coleta de entropia não é um processo que pode ser realizado pelo núcleo em todo o hardware suporte, além disso, o próprio núcleo não pode avaliar a quantidade de entropia fornecida por diferentes fontes.
«O núcleo não deve misturar diferentes fontes de ruído e, certamente, não deve tentar afirmar que sabe quantos bits de entropia está recebendo ao tentar jogar algum "jogo de entropia" rabugento em uma arquitetura de CPU absurdamente simples para casos de uso de IOT/Embutidos, quando tudo está dessincronizado em relação a um único gerador mestre, quando não há nenhuma instrução da CPU para reordenar ou renomear registradores, etc.»
«Pode-se falar sobre fornecer ferramentas que tentem fazer esses cálculos, mas essas coisas devem ocorrer no equipamento de cada usuário, o que é impraticável para a maioria dos usuários do distribuidor. Se isso for destinado apenas a criptógrafos, então que seja feito no espaço de usuário deles. E não vamos simplificar o GPG, OpenSSL, etc., para que todos digam: "nós queremos 'verdadeira aleatoriedade' e não aceitamos menos do que isso". Pode-se falar sobre como fornecemos interfaces a criptógrafos para que possam obter as informações necessárias por meio do acesso a fontes de ruído primárias, separadas e nomeadas, e, talvez, de alguma forma, a fonte de ruído consiga se autenticar na biblioteca ou aplicativo do espaço do usuário.»
Houve uma pequena discussão sobre como poderia ser essa interface, pois, por exemplo, para alguns eventos podem haver consequências em termos de segurança. Cao observou que os códigos de escaneamento de teclado (ou seja, de pressionamento de teclas) são misturados em um pool como parte da coleta de entropia: «Transferir isso para o espaço do usuário, mesmo através de uma chamada de sistema privilegiada, seria, no mínimo, imprudente». É bem possível que outros momentos de eventos possam criar algum vazamento de informações por canais laterais.
Assim, parece que um problema de longa data do subsistema de números aleatórios do Linux está a caminho da solução. As mudanças que o subsistema de números aleatórios passou recentemente, na verdade, resultaram apenas em problemas de DoS durante seu uso. Agora, surgiram maneiras eficazes de obter os melhores números aleatórios que o núcleo pode fornecer. Se o TRNG ainda for desejável para o Linux, essa deficiência precisará ser resolvida no futuro, mas provavelmente não será feita dentro do próprio núcleo.
Um pouco de publicidade 🙂
Obrigado por permanecer conosco. Você gosta dos nossos artigos? Quer ver mais materiais interessantes? Apoie-nos fazendo um pedido ou recomendando para conhecidos. , uma alternativa única aos servidores entry-level, que criamos para você: (disponíveis opções com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
Dell R730xd por 2 vezes mais barato no datacenter Equinix Tier IV em Amsterdã? Somente conosco na Holanda! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partir de $99! Leia sobre
Fonte: habr.com
