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.