Dispositivos IoT possuem sérias deficiências de segurança

Não é culpa dos fornecedores de IoT. A falta de um subsistema gerador de números pseudo-aleatórios criptograficamente seguro para os dispositivos da Internet das Coisas ficará vulnerável. As garantias de confidencialidade e integridade dos protocolos de comunicação modernos dependem de algoritmos que geram tokens secretos que os invasores não conseguem adivinhar. Eles são usados ​​para autenticação, criptografia, controle de acesso e muitos outros aspectos da segurança moderna e todos exigem números aleatórios criptograficamente seguros - sequências de números ou símbolos escolhidos de uma forma imprevisível por um invasor.

Não é culpa dos fornecedores e fabricantes de equipamentos IoT. A falta de um subsistema gerador de números pseudo-aleatórios criptograficamente seguro para os dispositivos da Internet das Coisas é um fator que os torna vulneráveis. As garantias de confidencialidade e integridade dos protocolos de comunicação modernos dependem de algoritmos que geram tokens secretos que não deveriam ser fáceis de se adivinhar, principalmente por atacantes. Eles são usados ​​para autenticação, criptografia, controle de acesso e muitos outros aspectos da segurança moderna e todos exigem números aleatórios criptograficamente seguros – sequências de números ou símbolos escolhidos de uma forma imprevisível para um invasor.

Todos os algoritmos criptográficos que envolvem algum tipo de chave segura ou geração de token precisam ser propagados com números aleatórios, de modo que o processo pelo qual esses números são escolhidos, conhecido como geradores de números aleatórios (random number generators – RNGs), é a base de muitos sistemas e recursos de segurança. Embora os sistemas operacionais e computadores modernos tenham funcionado há muito tempo com o RNG seguro, os dispositivos IoT, especialmente aqueles com recursos limitados e sem muitas interfaces que executam sistemas operacionais mais simples, há muito tempo têm problemas para encontrar elevadas fontes de aleatoriedade, também conhecida como entropia.

Nos últimos anos, os fornecedores de Sistemas em um Chip (systems-on-a-chip, SoC) tentaram resolver esse problema incorporando controladores periféricos em seus produtos que são projetados para gerar números aleatórios para que o sistema operacional possa usar com segurança. No entanto, uma equipe de pesquisadores da empresa de segurança Bishop Fox, que analisou a maneira como os desenvolvedores de IoT usam esses RNGs de hardware, encontrou grandes problemas de implementação que comprometem a segurança de seus sistemas. Eles recentemente apresentaram suas descobertas na conferência de segurança DEF CON.

“A forma como você usa o periférico é extremamente importante, e o estado da arte atual em IoT só pode ser apropriadamente descrito como ‘fazendo errado’”, concluíram os pesquisadores.

Hardware RNG vs software RNG

Não é culpa dos fornecedores de IoT. A falta de um subsistema gerador de números pseudo-aleatórios criptograficamente seguro para os dispositivos da Internet das Coisas ficará vulnerável. As garantias de confidencialidade e integridade dos protocolos de comunicação modernos dependem de algoritmos que geram tokens secretos que os invasores não conseguem adivinhar. Eles são usados ​​para autenticação, criptografia, controle de acesso e muitos outros aspectos da segurança moderna e todos exigem números aleatórios criptograficamente seguros - sequências de números ou símbolos escolhidos de uma forma imprevisível por um invasor.

RNGs baseados em software também são conhecidos como geradores de números pseudo-aleatórios (PRNGs) porque usam algoritmos de software determinísticos e precisam ser semeados com valores aleatórios, geralmente de um pool de entropia que combina valores aleatórios de diferentes fontes: informações de rede, interfaces de rádio , vários valores de tempo, etc. Isso não é tudo. Os PRNGs de uso geral são usados ​​para fins não relacionados à segurança e os PRNGs criptograficamente seguros (CSPRNGs) são projetados para oferecer garantias de segurança contra ataques que tentam adivinhar os valores iniciais ou prever sua saída em um período de tempo razoável e computacionalmente viável.

Os CSPRNGs empregam cifras criptográficas e funções de hashing para produzir saída que é então usada para operações críticas como geração de chave. Eles também realizam testes para prevenir ataques conhecidos. Todas essas operações consomem recursos de computação e memória, ambos altamente limitados em dispositivos IoT, motivo pelo qual os fornecedores de SoC adicionaram recursos de RNG de hardware.

RNGs de hardware também são conhecidos como RNGs verdadeiros (TRNGs) porque eles geram números aleatórios de processos físicos de uma forma que não pode ser prevista como no caso dos algoritmos de software. A saída dos TRNGs deve ser segura para uso direto, mas como os pesquisadores do Bishop Fox descobriram, as interfaces com eles podem ser complicadas e os erros têm consequências devastadoras para os sistemas de segurança construídos sobre eles.

Sem verificação de erros de hardware RNG

Não é culpa dos fornecedores de IoT. A falta de um subsistema gerador de números pseudo-aleatórios criptograficamente seguro para os dispositivos da Internet das Coisas ficará vulnerável. As garantias de confidencialidade e integridade dos protocolos de comunicação modernos dependem de algoritmos que geram tokens secretos que os invasores não conseguem adivinhar. Eles são usados ​​para autenticação, criptografia, controle de acesso e muitos outros aspectos da segurança moderna e todos exigem números aleatórios criptograficamente seguros - sequências de números ou símbolos escolhidos de uma forma imprevisível por um invasor.

Os fornecedores de SoC permitem que os desenvolvedores interajam com seu RNG de hardware por meio da API da camada de abstração de hardware (HAL) chamando diferentes funções em seu código C. Os nomes dessas funções RNG podem diferir entre os fornecedores, mas sua saída é um ponteiro para o número aleatório (inteiro de 32 bits) e, mais importante, um valor de retorno que indica possíveis erros.

“A função HAL para o periférico RNG pode falhar por uma variedade de razões, mas de longe a mais comum (e explorável) é que o dispositivo ficou sem entropia”, explicaram os pesquisadores em um relatório. “Os periféricos de hardware RNG puxam a entropia para fora do universo através de uma variedade de meios (como sensores analógicos ou leituras EMF), mas não têm um suprimento infinito. Eles são capazes de produzir apenas alguns bits aleatórios por segundo. Se você tente chamar a função RNG HAL quando ela não tiver nenhum número aleatório para fornecer, ela falhará e retornará um código de erro. Portanto, se o dispositivo tentar obter muitos números aleatórios muito rapidamente, as chamadas começarão a falhar.”

Isso pode acontecer com bastante frequência durante a geração de chaves grandes. Por exemplo, durante a geração de uma chave privada de 2048 bits, o dispositivo chamará a função hall RNG repetidamente em um loop e o hardware frequentemente falhará em acompanhar devido às suas limitações e começará a gerar erros.

O problema é que, com base no código encontrado no GitHub para interagir com SoCs e até mesmo no código de manipulação de RNG em sistemas operacionais integrados populares como o FreeRTOS, os desenvolvedores não parecem estar verificando erros de RNG de hardware. “É assim que a indústria da IoT faz”, disseram os pesquisadores do Bishop Fox. “Você encontrará esse comportamento em basicamente todos os SDKs e sistemas operacionais IoT.”

Este é um grande problema, porque dependendo do hardware, quando a função HAL RNG falha, a saída pode ser entropia parcial, o número 0 ou memória não inicializada. Nenhuma dessas saídas é segura para fins criptográficos.

Em 2019, pesquisadores da Keyfactor analisaram 75 milhões de certificados digitais com base em chaves RSA e descobriram que um em cada 172 era vulnerável a ataques que poderiam recuperar suas chaves secretas. O culpado foi a geração deficiente de números aleatórios, e a maioria dos certificados vulneráveis ​​foram encontrados na IoT e em dispositivos de rede incorporados, como roteadores, switches e firewalls. Se os números primos usados ​​para gerar chaves públicas RSA não forem aleatórios o suficiente, duas chaves separadas provavelmente compartilharão um fator. Então, é extremamente fácil recuperar seus outros fatores e comprometê-los.

“Embora não possamos dizer com certeza se nossa pesquisa é responsável por esses resultados … instâncias generalizadas de chaves RSA fracas em dispositivos IoT são exatamente o que você esperaria encontrar”, disseram os pesquisadores do Bishop Fox sobre suas descobertas sobre como IoTs lidam com RNGs de hardware. “Com certeza parece que este é um problema explorável em grande escala na prática, não apenas na teoria.”

Implementações ruins forçadas

Os pesquisadores alertam para não se apressar em culpar os desenvolvedores de software de IoT por implementações ruins, porque lidar com esses erros de maneira adequada tem outras desvantagens que podem afetar o funcionamento do dispositivo. “Se você é a pilha de rede no meio da geração de uma chave de criptografia para comunicações seguras, como você deve ‘lidar’ com o erro? Na verdade, existem apenas duas opções: Abortar, encerrar o processo inteiro ou girar o loop no Função HAL por um período indefinido de tempo até que a chamada seja concluída, bloqueando todos os outros processos e usando 100% da CPU no processo. Nenhuma das soluções são aceitáveis. É por isso que os desenvolvedores ignoram a condição de erro. As alternativas são terríveis e o ecossistema em torno do hardware RNG não lhes fez nenhum favor.”

Além disso, poucos dispositivos vêm com a documentação adequada sobre como o RNG deve funcionar e como lidar com erros ou evitá-los, informações ausentes sobre a velocidade operacional esperada, faixas de temperatura operacional seguras ou evidência estatística de aleatoriedade. Mesmo quando existe documentação, acertar não é uma tarefa fácil.

A saída de hardware RNG sozinha não é confiável

Não é culpa dos fornecedores de IoT. A falta de um subsistema gerador de números pseudo-aleatórios criptograficamente seguro para os dispositivos da Internet das Coisas ficará vulnerável. As garantias de confidencialidade e integridade dos protocolos de comunicação modernos dependem de algoritmos que geram tokens secretos que os invasores não conseguem adivinhar. Eles são usados ​​para autenticação, criptografia, controle de acesso e muitos outros aspectos da segurança moderna e todos exigem números aleatórios criptograficamente seguros - sequências de números ou símbolos escolhidos de uma forma imprevisível por um invasor.

Os pesquisadores do Bishop Fox encontraram muitos outros problemas ao tentar confiar apenas no hardware RNG como fonte de entropia na IoT. Por exemplo, na ausência de um CSPRNG verdadeiro, muitos SDKs e sistemas operacionais IoT que suportam RNGs de hardware o usam para propagar um PRNG inseguro como libc rand () e então sua saída é usada para fins de segurança quando não deveria.

“PRNGs como libc rand () são extremamente inseguros, pois os números que eles produzem revelam informações sobre o estado interno do RNG”, disseram os pesquisadores. “Eles são bons para contextos não relevantes para a segurança porque são rápidos e fáceis de implementar. Mas usá-los para coisas como chaves de criptografia leva ao colapso catastrófico da segurança do dispositivo, já que todos os números são previsíveis.”

Em um teste em um microcontrolador LPC54628, os pesquisadores notaram que os números aleatórios produzidos pelo hardware RNG eram de baixa qualidade e suspeitaram que algo estava errado com seu código. Indo mais fundo na documentação do fabricante, eles encontraram uma recomendação contra a concatenação de números de 32 bits produzidos pelo RNG para construir números maiores. Por exemplo, para obter um número aleatório de 128 bits, os desenvolvedores não devem concatenar quatro saídas RNG consecutivas de 32 bits, disse o fabricante. Em vez disso, eles devem usar um número de 32 bits, descartar os próximos 32 números, usar o próximo, descartar outros 32 números e assim por diante.

Esse comportamento da API é tão estranho e contra-intuitivo que é quase garantido que produza implementações vulneráveis. Mesmo que os desenvolvedores encontrem o código correto que descarta 32 números, eles podem removê-lo porque acham que é desnecessário, disseram os pesquisadores.

Além disso, algumas implementações de RNG de hardware testadas pelos pesquisadores falharam nos testes de análise estatística ou tiveram padrões claros na distribuição relativa dos bytes que produziram. Portanto, mesmo que os desenvolvedores consigam superar todos os obstáculos do tratamento adequado de erros, peculiaridades da API, documentação deficiente, eles ainda não devem depender apenas da saída de RNGs de hardware.

A resposta é ter CSPRNGs adequados para IoTs em que a saída de RNGs de hardware é apenas uma das fontes no pool de entropia. Todos os principais sistemas operacionais como Linux, Windows, macOS, Android, iOS, BSD têm subsistemas CSPRNG que são à prova de erros e os desenvolvedores de aplicativos podem usar facilmente sem interface direta com o hardware e se preocupando se seu código não está correto ou se os números aleatórios são inseguros.

“A vulnerabilidade central aqui não está no SDK de um único dispositivo ou em qualquer implementação de SoC em particular”, disseram os pesquisadores. “A IoT precisa de um subsistema CSPRNG. Esse problema não pode ser corrigido apenas alterando a documentação e culpando os usuários. O lugar mais elegante para tal subsistema CSPRNG é em um dos sistemas operacionais IoT cada vez mais populares. Se você estiver projetando um novo dispositivo do zero, recomendamos a implementação de um CSPRNG em um sistema operacional. “

Fonte: www.csoonline.com

Posts relacionados: Trabalho remoto aumenta as ameaças de dispositivos IoT do consumidor / ENISA Publica Diretrizes sobre Segurança na Cadeia de Suprimentos de IoT e Nova violação de IoT, mesma história de (in)segurança, amplas consequências