Estratégias inovadoras para fortalecer a segurança em redes IoT
Com o avanço para a versão 1.1 do protocolo LoRaWAN, novas medidas de segurança foram introduzidas, especialmente no processo crítico de autenticação dos dispositivos finais, conhecido como Join Procedure. Apesar dessas melhorias, as redes LoRaWAN ainda enfrentam diversas ameaças, como ataques de repetição e interferência. Este estudo realiza uma revisão sistemática da literatura para mapear as vulnerabilidades e ataques documentados, além de propor estratégias para mitigar esses riscos e fortalecer a segurança das redes LoRaWAN, garantindo a integridade e confiabilidade das comunicações IoT.
Diogo Henrique Dantas Moraes; Matheus Jacon Pereira e Fabrício Gonçalves Torres, pesquisadores do IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
A crescente demanda por soluções de IoT – Internet das coisas tem impulsionado o uso da LoRaWAN, que se destaca por oferecer uma comunicação eficiente em longas distâncias com baixo consumo de energia, sendo ideal para diversas aplicações. Por outro lado, a segurança dessas redes, ainda latente, tem ganhado importância decorrente do aumento de ataques cibernéticos.
Lançada em 2017 pela LoRa Alliance, a versão 1.1 do protocolo LoRaWAN trouxe atualizações importantes, especialmente no que diz respeito à segurança e à estrutura da rede, resultando em conexões mais confiáveis e robustas. Entre as mudanças mais significativas está a introdução do JS – Join Server, que assumiu parte das funções de autenticação anteriormente gerenciadas pelo NS – Network Server. Agora, o JS é responsável pelo processamento do Join Procedure e pela geração de chaves de sessão, um passo crucial para garantir a segurança das comunicações na Internet das coisas (LoRa Alliance, 2017).
Enquanto na versão 1.0 do LoRaWAN apenas duas chaves de sessão eram derivadas (AppSKey e NwkSKey), na versão 1.1 esse número aumentou para quatro: FNwkSIntKey, SNwkSIntKey, AppSKey e NwkSEncKey. Essa divisão proporciona uma camada extra de segurança, segregando as funções da rede e da aplicação. Além disso, a nova versão introduziu uma segunda chave raiz, a NwkKey, que trabalha em conjunto com a AppKey, aumentando ainda mais a proteção dos dados transmitidos. Na v1.0, existia apenas uma chave raiz, a AppKey. Outro detalhe interessante foi a substituição do termo AppEUI pelo mais moderno JoinEUI, reforçando a evolução do protocolo.
Os dispositivos LoRaWAN podem se conectar à rede de duas formas: OTAA – Over-The-Air Activation ou ABP – Activation by Personalization. O ABP, apesar de ser uma solução mais simples e econômica, mantém as chaves de sessão durante toda a vida útil do dispositivo, o que representa um risco maior em caso de comprometimento (Butun, Pereira & Gidlund, 2018). Já o método OTAA é mais seguro, pois gera novas chaves a cada conexão, utilizando o processo de Join Procedure para autenticação. Isso reduz drasticamente o risco de vazamentos e vulnerabilidades, tornando o OTAA a escolha mais adequada para aplicações que exigem maior segurança (Naoui, Elhdhili & Saidane, 2018).
Estado da arte: segurança lorawan v1.1
Para mapear o estado da arte em relação às vulnerabilidades e ataques documentados durante o Join Procedure em redes LoRaWAN v1.1, realizamos uma revisão sistemática da literatura. Este levantamento foi conduzido nas principais bases de dados acadêmicas, incluindo a ACM Digital Library, IEEE Xplore, Scopus Digital Library e Web of Science. A tabela I apresenta o protocolo de revisão e figura 1 as etapas de seleção dos artigos.
Ao final, chegou-se à seleção final de 12 artigos. A tabela II mostra as informações dos artigos selecionados.
Análise dos resultados
Esta seção aborda os principais aspectos de segurança do Join Procedure em redes LoRaWAN v1.1, destacando vulnerabilidades, formas de ataque e estratégias de mitigação propostas nos artigos analisados. Apesar das melhorias da versão 1.1, algumas vulnerabilidades ainda persistem, como o uso de chaves raízes estáticas, a limitação dos dispositivos finais em termos de bateria e processamento, e problemas relacionados à implementação do protocolo.
Butun, Pereira e Gidlund (2018) discutem detalhadamente as chaves e o Join Procedure, afirmando, com base na ferramenta Scyther, que o LoRaWAN v1.1 é criptograficamente seguro. No entanto, alertam para vulnerabilidades comuns em redes sem fio, como ataques de repetição e análise de tráfego. Locatelli, Spadaccino e Cuomo (2021) propõem o uso de blockchain como solução para adicionar autenticação de dois fatores, mas reconhecem que essa abordagem aumenta a latência e só seria viável em redes com baixa demanda de transferência de dados.
Considerações sobre o protocolo e propostas de melhoria
O gerenciamento das chaves raiz é outra vulnerabilidade importante no protocolo, já que ele não prevê mecanismos de atualização das mesmas. Assim, na ocorrência de um ataque físico ou de interceptação com vazamento destas chaves, a segurança de toda a rede ficará prejudicada. Meios de aprimorar a segurança em relação às chaves são propostos em Gao, Li e Ma (2019), Hayati, Ramli, Windarta e Suryanegara (2022), Marlind e Butun (2020) e Donmez e Nigussie (2019).
Gao, Li e Ma (2019) propõem o Secure-Packet-Transmission (SPT), que reformula o pacote de Join Request e adiciona criptografia a essa etapa da autenticação, de modo a evitar a manipulação dos dados que nesta etapa do Join Procedure são transmitidos em texto aberto. Apesar de os autores defenderem a viabilidade técnica desta solução, ela exigiria mudanças na organização dos pacotes trocados entre os dispositivos finais e servidores, além do custo em termos de processamento e bateria relacionado ao uso de criptografia no dispositivo final.
Visando proteger a integridade dos dados e evitar ataques de repetição, Hayati, Ramli, Windarta e Suryanegara (2022) argumentam que as chaves raiz precisam ser atualizadas dinamicamente, de modo a minimizar o efeito negativo de seu vazamento. Assim, propõem um mecanismo em que o servidor de junção, após um período determinado, deriva novas chaves raízes e as envia criptografadas para o dispositivo final. Além disso, propõem a adição de timestamps aos pacotes de Join Request para evitar ataques de repetição.
Na mesma direção, em Marlind e Butun (2020), é proposto um novo mecanismo de atribuição dinâmica das chaves raiz utilizando criptografia de chave pública, chamado Over the Air Activation (PK-OTAA). Em comparação com o OTAA, o consumo de bateria dos dispositivos finais é sensivelmente afetado; porém, os autores argumentam que a atualização das chaves raiz pode ser realizada eventualmente, não acarretando uma sobrecarga expressiva para os dispositivos finais se considerarmos todas as operações realizadas por eles.
Já o artigo de Donmez e Nigussie (2019) propõe, para sistemas de monitoramento de saúde, um mecanismo em que as chaves dos dispositivos finais são atualizadas periodicamente com a aproximação de um dispositivo mestre, sem incorrer em mudanças significativas no protocolo LoRaWAN ou sobrecarga no processamento e transmissão. Em contextos em que o dispositivo final pode ser acessado regularmente, esta pode ser uma solução viável para a atualização de chaves.
Ainda relacionado ao gerenciamento das chaves, mas com foco nas limitações presentes nos dispositivos finais, McPherson e Irvine (2021) sugerem que um smartphone seja utilizado para a geração das chaves de segurança e as transfiram para os servidores pela internet, sendo as chaves transmitidas para o dispositivo final por meio do flash das câmeras com o uso de código Morse, sendo necessária a inclusão de um sensor luminoso nos dispositivos finais além de ajustes de software.
Em relação a problemas referentes ao protocolo LoRaWAN v1.1 em si, Butun, Pereira e Gidlund (2018) fazem a descrição de diversas vulnerabilidades, entre elas as relacionadas a cada entidade participante da rede, à distribuição de chaves, ao método de ativação, à implementação, à retirada de um dispositivo da rede, ao DevEUI, ao JoinEUI e às questões relacionadas à interoperabilidade entre as versões do protocolo, acarretando vulnerabilidades que são discutidas com detalhes e em diferentes cenários por Loukil, Fourati, Nayyar e Chee (2022).
Santamaria e Marchiori (2019) apresentam diversas preocupações em relação à implementação adequada do protocolo, com destaque para sua vulnerabilidade a ataques de sincronização em dispositivos da Classe B. Este ataque é simulado através de CPN Tools em Van Es, Vranken e Hommersom (2018), onde também são testados ataques de replay, levando em conta que as mensagens de Join-Accept não têm uma referência à mensagem de Join-Request correspondente, e de sequestro de sessão durante o downlink, situação experimentada em Locatelli, Spadaccino e Cuomo (2021), onde a configuração inadequada no processo de deduplicação de pacotes downlink é explorada na prática.
Conclusões e apontamentos futuros
Apesar dos avanços significativos introduzidos na versão 1.1 do protocolo LoRaWAN, especialmente no que diz respeito à segurança durante o Join Procedure, ainda existem vulnerabilidades críticas que podem ser exploradas por atacantes, como ataques de repetição e interferência. A análise realizada destacou a necessidade urgente de aprimorar os mecanismos de autenticação e gerenciamento de chaves, bem como a integração de tecnologias complementares para fortalecer a segurança das redes LoRaWAN. Portanto, é imperativo que futuras pesquisas e implementações práticas se concentrem em mitigar essas vulnerabilidades para garantir a integridade e confiabilidade das comunicações em ambientes de IoT.
