Segurança em redes LoRaWAN: Autenticação de dispositivos (Join Procedure)
Dispositivos IoT estão sendo cada vez mais utilizados no contexto corporativo, coletivo e doméstico, com aplicações em logística, agricultura, indústria de manufatura, smart cities, smart devices, entre outros. Neste contexto, diversos protocolos de comunicação foram desenvolvidos para suprir a necessidade de comunicação sem fio, levando em consideração as características físicas, limitações computacionais, de armazenamento e memória presentes em dispositivos IoT. Entre os protocolos que permitem o desenvolvimento de redes LPWAN, destaca-se o LoRaWAN, desenvolvido e mantido pela LoRa Alliance a partir de 2015. Sua versão 1.1, de 2017, corrigiu diversos problemas de segurança encontrados na primeira versão da especificação. O objetivo deste artigo é detalhar os mecanismos de autenticação em redes LoRaWAN, especialmente na versão 1.1, explicando como eles aumentam a segurança da comunicação entre dispositivos IoT e mitigam diversos tipos de ataques.
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
Existem diversas tecnologias de comunicação utilizadas em dispositivos de IoT – Internet das coisas, cada uma adequada a determinado contexto. Na comunicação de curto alcance, podemos destacar o Bluetooth Low Energy e o ZigBee. Já em redes onde é necessária a cobertura de uma grande área, as tecnologias conhecidas como LPWAN – Low Power Wide Area Network permitem comunicações de longo alcance com baixo consumo de energia, de modo que dispositivos com recursos limitados podem se comunicar a até 12 km em regiões abertas usando baterias por até 10 anos sem fonte de alimentação externa (Butun, Pereira & Gidlund, 2018).
Entre as tecnologias LPWAN utilizadas para a comunicação em redes que apresentam baixa taxa de transmissão de dados, destaca-se a LoRaWAN – Long Range Wide Area Network. Baseada no protocolo de camada física LoRa – Long Range, as redes LoRaWAN organizam os dispositivos participantes por meio de uma topologia estrela de estrelas, que permite que os dispositivos finais alcancem seu gateway correspondente por meio de um link direto (Sanchez-Iborra et al., 2018). Esse arranjo permite a distribuição de muitos dispositivos finais que se comunicam com um gateway e, deste, com os servidores de rede (NS – Network Servers), servidores de aplicação (AS – Application Servers) e servidores de junção (JS – Join Servers). A figura 1 descreve a arquitetura LoRaWAN v1.1.
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.
Montagem da Join-Request
Para iniciar o Join Procedure em uma rede LoRaWAN, o dispositivo final envia uma mensagem de Join-Request, que contém os valores JoinEUI, DevEUI e DevNonce, conforme descrito na tabela 2.
Tab. 2 – Valores da mensagem Join-Request
| DevEUI | JoinEUI | AppKey | NwkKey |
| ID único do dispositivo final | ID único do Join Server | Chave raiz privada usada para derivar a chave de sessão de aplicação | Chave raiz privada usada para derivar as chaves de sessão de rede |
As redes LoRaWAN v1.1 utilizam essas duas chaves raiz para garantir a segurança dos dados (LORA ALLIANCE, 2017). O DevNonce é um contador gerado pelo dispositivo final, incrementado a cada Join-Request, e armazenado na memória não volátil para prevenir Replay Attacks. O dispositivo final gera um MIC – Message Integrity Code usando a NwkKey para proteger a integridade do pacote Join-Request (LORA ALLIANCE, 2017). Esta mensagem é assinada, mas não criptografada, já que o dispositivo ainda não possui as chaves de sessão antes de enviá-la ao NS (FEICHTINGER; NAKANO; FUKUSHIMA; KIYOMOTO, 2018).
Montagem da Join-Req
O NS verifica se o DevNonce presente na Join-Request recebida não foi utilizado anteriormente, valida o MIC e adiciona ao pacote o endereço do dispositivo final na rede além de outros campos relacionados de configuração da rede.
Montagem da Join-Accept
O JS – Join Server verifica a versão do protocolo LoRaWAN, gera o JoinNonce, adiciona o NetID e deriva quatro chaves de sessão, conforme tabela 3.
Tab. 3 – Termos e descrições do Join-Accept
| Termo | Descrição |
| JoinNonce | Contador numérico único de 3 bytes, incrementado a cada mensagem de Join-Accept gerada, usado pelo dispositivo final para calcular as mesmas quatro chaves de sessão que o JS |
| NetID | Identificador da rede. |
| Chaves de Sessão | Descrição |
| SNwkSIntKey | Calcula o MIC em mensagens de downlink |
| FNwkSIntKey | Calcula o MIC em mensagens de uplink |
| NwkSEncKey | Encripta e desencripta comandos MAC |
| AppSKey | Encripta e desencripta payloads da camada de aplicação |
As chaves de sessão não são transmitidas pela rede; o dispositivo final as deriva novamente usando as chaves raiz (comuns ao JS e ao dispositivo), o JoinNonce, o JoinEUI e o DevNonce. O JS gera um MIC para garantir a integridade do pacote e encripta os dados usando a NwkKey antes de enviar a resposta (Join Ans) ao Network Server (NS), que então encaminha o pacote (Join Accept) ao dispositivo final (LORA ALLIANCE, 2017).
Conclusão do Join-Procedure
Ao receber o Join-Accept, o dispositivo final desencripta o pacote, verifica se os valores do MIC e do JoinNonce são adequados e deriva as quatro chaves de sessão. Então, o dispositivo final está registrado na rede, possuindo as quatro chaves de sessão necessárias para a comunicação segura.
Conclusão
A segurança em redes LoRaWAN é fundamental para garantir a integridade e confiabilidade das comunicações em aplicações IoT. A autenticação robusta dos dispositivos, especialmente através do método OTAA, protege contra diversos tipos de ataques e vulnerabilidades. O constante aprimoramento do protocolo LoRaWAN pela LoRa Alliance demonstra um compromisso contínuo com a segurança e a eficácia das redes LPWAN.
Diogo Henrique Dantas Moraes é graduado em Análise de Sistemas pela Fatec – Faculdade de Tecnologia de Sorocaba e pós-graduado (MTA) em Cibersegurança pelo IPT – Instituto de Pesquisas Tecnológicas onde realizou pesquisa relacionada à segurança em redes LoraWAN. Atualmente é assessor de tecnologia no Banco do Brasil. diogo.moraes.537@bb.com.br.
Matheus Jacon Pereira é mestre em Engenharia da Computação – Redes de Computadores pelo IPT e graduado em Engenharia Elétrica pela Universidade Estadual Paulista Júlio de Mesquita Filho, UNESP. Possui publicações acadêmicas nas áreas de RFID, Internet das Coisas, Sistemas Inteligentes de Transporte (ITS), Rede de Computadores e automação. Atuou como professor em cursos de Engenharia de Computação, Engenharia Elétrica e Sistemas de Informação e atualmente é professor no curso de pós-graduação (MTA) em Cibersegurança ministrando disciplinas de Engenharia Reversa e Análise de Malware. Atuou na área de PD em companhias do setor de telecomunicações e é Pesquisador do IPT, trabalhando com pesquisa e desenvolvimento nas áreas de RFID, ITS, Internet das coisas, Redes de Computadores, Governança e Segurança da Informação. Além de liderar projetos de desenvolvimento para Sistemas operacionais Linux e Android, incluindo requisitos de cibersegurança. mjacon@ipt.br.
Fabrício Gonçalves Torres é físico, mestre em Processos Industriais e gerente técnico do Laboratório de Metrologia Elétrica do IPT. Possui mais de 18 anos de experiência em metrologia e realiza auditorias, consultorias e treinamentos na área de qualidade, metrologia e instrumentação. fabrigt@ipt.br; www.linkedin.com/in/fabriciogt.
Referencias:
BUTUN, Ismail; PEREIRA, Nuno; GIDLUND, Mikael. Analysis of LoRaWAN v1.1 security. Proceedings Of The 4Th Acm Mobihoc Workshop On Experiences With The Design And Implementation Of Smart Objects – Smartobjects ’18, [S.L.], p. 1-5, 2018. ACM Press. http://dx.doi.org/10.1145/3213299.3213304.
BUTUN, Ismail; PEREIRA, Nuno; GIDLUND, Mikael. Security Risk Analysis of LoRaWAN and Future Directions. Future Internet, [S.L.], v. 11, n. 1, p. 3, 21 dez. 2018. MDPI AG. http://dx.doi.org/10.3390/fi11010003.
FEICHTINGER, Kevin; NAKANO, Yuto; FUKUSHIMA Kazuhide; KIOMOTO, Shinsaku. Enhancing the security of over-the-air-activation of LoRaWAN using a hybrid cryptosystem. Int. J. Comput. Sci.Netw. Secur. 18 (2) (2018) 1–9.
GAO, Shu-Yang; LI, Xiao-Hong; MA, Mao-De. A Malicious Behavior Awareness and Defense Countermeasure Based on LoRaWAN Protocol. Sensors, [S.L.], v. 19, n. 23, p. 5122, 22 nov. 2019. MDPI AG. http://dx.doi.org/10.3390/s19235122.
HAYATI, Nur; RAMLI, Kalamullah; WINDARTA, Susila; SURYANEGARA, Muhammad. A Novel Secure Root Key Updating Scheme for LoRaWANs Based on CTR_AES DRBG 128. Ieee Access, [S.L.], v. 10, p. 18807-18819, 2022. Institute of Electrical and Electronics Engineers (IEEE). http://dx.doi.org/10.1109/access.2022.3150281.
KITCHENHAM, B. Procedures for performing systematic reviews. Keele, UK, Keele Univ., v. 33, 08 2004.
LOCATELLI, Pierluigi; SPADACCINO, Pietro; CUOMO, Francesca. Hijacking Downlink Path Selection in LoRaWAN. 2021 Ieee Global Communications Conference (Globecom), [S.L.], p. 1-6, dez. 2021. IEEE. http://dx.doi.org/10.1109/globecom46510.2021.9685973.
LOCATELLI, Pierluigi; SPADACCINO, Pietro; CUOMO, Francesca. Ruling Out IoT Devices in LoRaWAN. Ieee Infocom 2022 – Ieee Conference On Computer Communications Workshops (Infocom Wkshps), [S.L.], p. 1-2, 2 maio 2022. IEEE. http://dx.doi.org/10.1109/infocomwkshps54753.2022.9798063.
“LoRaWAN v1.0 Specification”LoRa Alliance, Fremont, CA, USA, 2015.
“LoRaWAN v1.1 Specification”LoRa Alliance, Fremont, CA, USA, 2017.
