5. Segurança no LoRaWAN™
O protocolo LoRaWAN garante uma segurança robusta para dispositivos IoT de baixo consumo através de uma arquitetura de duas camadas com criptografia AES-128, autenticação mútua e proteção contra ataques de repetição.
5.1 Criptografia AES-128 de Duas Camadas
O LoRaWAN emprega o Advanced Encryption Standard (AES) com uma chave simétrica de 128 bits como seu principal primitivo criptográfico. Este padrão é aplicado em uma arquitetura de segurança de duas camadas, que é fundamental para o design de segurança do LoRaWAN.
Segurança da Camada de Rede (Integridade e Autenticação): Esta camada usa a Chave de Sessão de Rede (NwkSKey) e o AES-CMAC (Cipher-based Message Authentication Code) para fornecer integridade de dados e autenticação entre o dispositivo final e o Servidor de Rede. Garante que o dispositivo seja legítimo e que a mensagem não tenha sido adulterada ou repetida durante a transmissão.
Segurança da Camada de Aplicação (Confidencialidade Ponta a Ponta): Esta camada usa a Chave de Sessão de Aplicação (AppSKey) e o AES-CTR (Counter Mode Encryption) para fornecer criptografia ponta a ponta para a carga útil (payload) da aplicação. Esta chave é conhecida apenas pelo dispositivo final e pelo Servidor de Aplicação, garantindo que nem mesmo o operador da rede (Servidor de Rede) possa descriptografar os dados reais do usuário, proporcionando um alto nível de confidencialidade.
5.2 Autenticação Mútua e Derivação de Chave de Sessão
O LoRaWAN utiliza um processo robusto, tipicamente o procedimento de adesão Over-The-Air Activation (OTAA - Ativação pelo Ar), para estabelecer uma comunicação segura. Este processo envolve.
Autenticação Mútua: Tanto o dispositivo final quanto a rede (Join Server) verificam a autenticidade um do outro. O dispositivo prova que possui a Chave de Aplicação (AppKey) única de 128 bits, e a rede prova que pode gerar uma resposta válida. Isso evita que dispositivos não autorizados ou maliciosos se juntem à rede e protege dispositivos legítimos de se conectarem a redes falsas.
Derivação Dinâmica de Chave de Sessão: Após a autenticação mútua bem-sucedida, o dispositivo e o Join Server derivam dinamicamente as duas chaves de sessão exclusivas, a NwkSKey e a AppSKey, que são então usadas para toda a comunicação segura subsequente, aumentando a segurança em comparação com o uso de chaves estáticas.
5.3 Contadores de Quadros (Proteção Contra Repetição)
Para proteger contra ataques de repetição (replay attacks) (onde um invasor intercepta um pacote legítimo e o retransmite mais tarde), o LoRaWAN incorpora um Contador de Quadros (FCnt) em cada mensagem de dados.
Função: Existe um contador de quadros de uplink (subida) e downlink (descida) separado. O dispositivo final incrementa seu contador de uplink a cada transmissão, e o Servidor de Rede rastreia esse valor.
Proteção: Se o Servidor de Rede receber uma mensagem de uplink com um valor de contador de quadros igual ou inferior ao último contador válido que recebeu, a mensagem é descartada. Este mecanismo impede efetivamente que um invasor repita com sucesso mensagens antigas e válidas para manipular o sistema.
5.4 Vulnerabilidades do LoRaWAN™
Como uma tecnologia de rádio frequência (RF) que opera em bandas não licenciadas (ISM), o LoRaWAN é inerentemente vulnerável a ataques de jamming (interferência intencional no sinal).
Um atacante transmite um sinal de rádio forte e propositalmente desordenado na mesma frequência que a rede LoRaWAN, sobrecarregando o canal e bloqueando a comunicação legítima entre os dispositivos e os gateways, configurando um ataque DoS (Negação de Serviço)
Estudos mostram que o LoRaWAN é especialmente vulnerável ao jamming reativo, onde o atacante detecta a transmissão legítima e interfere rapidamente, exigindo um mínimo de energia para ser eficaz.
Além disso, existe uma vulnerabilidade no Método de Ativação ABP e Gerenciamento de Chaves, pois o LoRaWAN oferece dois métodos de ativação: OTAA (mais seguro, gera chaves de sessão novas e dinâmicas) e ABP (menos seguro, usa chaves de sessão estáticas). Quando um dispositivo utiliza o ABP, ele possui as mesmas chaves de sessão por toda sua vida útil.
Se um atacante conseguir extrair ou comprometer essas chaves estáticas de um único dispositivo (ABP), ele poderá descriptografar todas as mensagens futuras desse dispositivo e falsificar mensagens (spoofing), se passando pelo dispositivo legítimo.
O ABP também é mais suscetível a ataques de repetição (replay attacks) se os contadores de quadros (FCnt) não forem manipulados ou verificados corretamente, pois o atacante pode simplesmente re-enviar dados antigos com as chaves comprometidas.
5.5 Limitações e Desafios
Embora o LoRaWAN adote criptografia robusta, alguns aspectos de sua arquitetura e operação introduzem vulnerabilidades.
- Jamming: A operação em bandas não licenciadas facilita interferências intencionais, podendo causar DoS.
- ABP: A ativação por personalização usa chaves estáticas, tornando o dispositivo vulnerável caso sejam comprometidas.
- Exposição física: Dispositivos instalados em ambientes externos podem ter chaves extraídas por acesso físico.
- Gerenciamento de chaves: Implementações sem atualização periódica ou sem Join Server seguro ampliam riscos.
- Camada física sem proteção: A camada LoRa não possui autenticação, permitindo captura de pacotes e análise de tráfego.