O objetivo deste artigo é detalhar os mecanismos de autenticação em redes LoRaWAN, com foco na versão 1.1 do protocolo. Pretendemos explicar como esses mecanismos contribuem para a segurança da comunicação entre dispositivos IoT, destacando os processos envolvidos no Join Procedure. Além disso, buscamos evidenciar as melhorias de segurança implementadas na versão 1.1 do LoRaWAN e como elas mitigam diversos tipos de ataques, proporcionando uma comunicação mais segura e confiável em aplicações IoT.
Segurança em LoRaWAN
A LoRa Alliance, responsável pelo desenvolvimento das especificações LoRaWAN, dedica muita atenção ao problema de segurança desde as primeiras versões do protocolo. Uma grande melhoria em termos de segurança foi feita com a versão LoRaWAN v1.1, onde vários mecanismos de prevenção contra ataques foram implementados, chaves de segurança foram adicionadas (Loukil et al., 2022), e a arquitetura foi reformulada com a adição do JS. No entanto, as redes LoRaWAN v1.1 ainda são suscetíveis a diversos tipos de ataque, como ataques de Jamming, Network Flooding, Replay, Man In The Middle (MITM), análise de tráfego e de sincronização (Butun, Pereira & Gidlund, 2018).
A autenticação dos dispositivos finais à rede é um procedimento crucial para o estabelecimento de uma comunicação segura em redes LoRaWAN v1.1. O mecanismo mais seguro envolve a troca de mensagens entre o dispositivo final, o NS e o JS, que verificam a autenticidade. Este procedimento é chamado de Join Procedure.
LoRaWAN V1.0 e LoRaWAN V1.1
A versão 1.1 do protocolo LoRaWAN lançada em 2017 pela Lora Alliance trouxe mudanças na arquitetura e em aspectos relacionados à segurança das redes LoRaWAN, vale citar o advento do JS, as novas chaves de sessão e a alteração de alguns termos.
O JS assume funções relacionadas ao Join Procedure que na versão 1.0 eram de responsabilidade do NS, sendo capaz de auxiliar no processamento do Join Procedure e na derivação de chaves de sessão (LORA ALLIANCE, 2017).
Em relação as chaves de sessão, na versão 1.1 são derivadas quatro delas (FNwkSIntkey, SNwkSIntKey, AppSKey e NwkSEncKey) no Join Server enquanto na versão 1.0 apenas duas (AppSKey e NwkSKey). Além disso, na versão 1.0 existe apenas uma chave raiz (AppKey) enquanto na versão 1.1 são duas (AppKey e NwkKey).
Também vale citar que o termo AppEUI foi substituído por JoinEUI na versão 1.1 do protocolo e que a chave de rede anteriormente denominada AppKey corresponde a NwkKey em LoRaWAN v1.1.
Métodos de autenticação
Os dispositivos finais LoRaWAN precisam se conectar à rede por meio da Ativação OTAA – Over-The-Air ou da ABP – Activation by Personalization antes de poderem enviar dados pela rede, métodos descritos na Tabela 1. Nesse processo, são geradas as chaves de sessão que serão usadas para criptografar e calcular o MIC – Message Integrity Code das mensagens trocadas entre os servidores e os dispositivos finais (Naoui, Elhdhili & Saidane, 2018).
Tab. 1 – Métodos de autenticação
| Descrição | Vantagens | Desvantagens | |
| ABP | Utiliza as mesmas chaves de sessão por toda a vida útil do dispositivo | Implementação simples e de baixo custo | Problemas com armazenamento de chaves e vulnerabilidade a ataques em caso de vazamento |
| OTAA | Gera novas chaves de sessão para cada comunicação, mediada pelo Join Procedure | Maior segurança nas comunicações | Procedimento mais complexo e possivelmente mais caro |
Join Procedure em LoRaWAN v1.1
A autenticação de um dispositivo final em uma rede LoRaWAN começa com o envio de uma solicitação de ingresso para o NS. Se a mensagem for autêntica, o NS encaminha a solicitação para o JS, que verifica a autenticidade, deriva as chaves de sessão e responde ao dispositivo final com as informações necessárias para a derivação dessas chaves. A figura 2 ilustra o fluxo de mensagens, chaves e campos relacionados ao Join Procedure.
