Protegendo protocolos sem fio usando o LoRaWAN como exemplo

Oi Habr.

Gostaria de falar mais uma vez sobre como é fornecido o nível básico (leia-se: mínimo necessário) de segurança de dados em redes sem fio usadas em dispositivos IoT, usando o LoRaWAN como exemplo.

Por que LoRaWAN? Primeiro, porque é um padrão bem descrito e bem desenvolvido que deve ser guiado como referência se você estiver desenvolvendo algum tipo de seu próprio protocolo sem fio. Em segundo lugar, porque é uma solução de IoT muito nativa e típica; Você pode, é claro, desmontar a segurança em Wi-Fi ou LTE, mas para a maioria dos desenvolvedores isso será uma análise fútil: é improvável que você precise escrever sua própria implementação de Wi-Fi. Em terceiro lugar, são os dispositivos IoT de baixo consumo de energia nos quais os desenvolvedores salvam todos os bytes que costumam ser os mais vazados - aqui o LoRaWAN fornece uma boa idéia de como salvar bytes e não ser atacado. Quarto, finalmente, porque, literalmente, nos últimos dias, vários de nossos clientes pediram para lhes falar mais sobre proteção de dados no LoRaWAN, e com este artigo eu mato dois coelhos com uma cajadada.


Mensagens LoRaWAN entre servidor e dispositivo

Embora o esquema de mensagens do LoRaWAN na foto pareça bastante simples - essa simplicidade é enganosa: ele tem muito trabalho a ser feito e nem um único pixel é supérfluo. Agora você vai entender o porquê.

Analisaremos o uso do LoRaWAN 1.0.2 como exemplo e combateremos possíveis ameaças - pois um bom desenvolvedor deve sempre pensar não sobre como seu sistema está protegido, mas sobre como ele pode ser quebrado. Caso contrário, alguém pensará sobre isso por ele.

Então, quais são as principais ameaças na rede sem fio - e como se proteger delas?

Interceptação de dados do usuário

A ameaça mais simples é uma interceptação de dados regular: Como as ondas de rádio se propagam incontrolavelmente, qualquer pessoa pode pegar um receptor sintonizado na faixa e no tipo de modulação desejados e ouvir tudo o que você transmite.

A maneira mais fácil de se proteger contra isso é a criptografia de dados.

No LoRaWAN, os dados do usuário são criptografados usando o algoritmo AES-128 com um comprimento de chave de 128 bits (16 bytes), respectivamente. O AES é um algoritmo confiável, no entanto, em microcontroladores minimamente modernos que nem sequer possuem um bloco de criptografia de hardware, seu uso não implica uma sobrecarga significativa: em um Cortex-M3 com frequência de 48 MHz, um bloco de 16 bytes é criptografado em cerca de 100 μs do zero.

Repetição de dados

Em alguns casos, um invasor não precisa saber exatamente o que você está transmitindo lá. Por exemplo, se você possui um sensor de uma janela fechada que transmite uma coisa e uma aberta - ou seja, outra, é possível gravar uma sem entrar nos detalhes de seu conteúdo, abafar o sensor e para que o sistema não suspeite que algo estava errado devido à falta de pacotes do sensor - transmita a mensagem gravada anteriormente.

No LoRaWAN, um contador é adicionado a cada pacote . Se um pacote chegar ao servidor de rede com um contador igual ou inferior ao anterior, esse pacote será simplesmente descartado. Com dois bytes por metro e uma velocidade típica de transmissão de mensagens do sistema IoT, ela dura muito tempo - por exemplo, mesmo uma estação meteorológica doméstica que transmite temperatura a cada minuto a transborda apenas após um mês e meio (LoRaWAN permite um contador de 4 bytes).

Há, no entanto, um problema óbvio - após um estouro, um pacote com o número 0 virá do dispositivo, que obviamente será menor que qualquer outro número, mas o servidor de rede deve percebê-lo corretamente e iniciar a contagem de pacotes novamente. Além disso, o dispositivo pode redefinir o contador simplesmente reiniciando.

Isso é alcançado de duas maneiras:

• Antes de enviar esse pacote, o dispositivo deve passar pelo procedimento de registro na rede (na rede LoRaWAN, esse procedimento é chamado de ingresso)
• o servidor permite a chegada do próximo pacote com o número 0, enquanto a contagem regressiva começa novamente

Ambos os esquemas são usados ​​no LoRaWAN, dependendo de como o dispositivo é ativado - OTAA ou ABP (falaremos sobre eles abaixo). A primeira opção é usada para o OTAA, e o dispositivo também recebe novas chaves de criptografia - assim, mesmo um invasor que passou um mês e meio sob sua estação meteorológica não poderá transmitir nenhum pacote gravado anteriormente para que o sistema o aceite.

Para o ABP, no qual não há procedimento de registro na rede, a segunda opção é usada - no entanto, se o período de sobrecarga do contador exceder significativamente a vida útil estimada do dispositivo, e ele pode ser desativado. No caso de uma reinicialização acidental após o envio de cada pacote, esse dispositivo final armazena o valor do contador na memória não volátil.

O segundo esquema, é claro, é menos seguro, mas na prática é permitido - um invasor não precisa registrar nenhum pacote nele, mas especificamente zero. Se desejar, você pode diferenciar seu conteúdo de todos os outros pacotes - por exemplo, transmitir não dados, mas informações sobre o tipo e as configurações do dispositivo; então sua interceptação e repetição não dará nada razoável.

Contador falsificado

No entanto, a pergunta surge imediatamente - e se o contador for falsificado? Você pode colocá-lo na parte criptografada do pacote, mas a quantidade real de dados do usuário diminuirá em dois bytes. Você pode criptografar não apenas os dados do usuário, mas, em primeiro lugar, é necessário adaptar-se ao tamanho do bloco de 16 bytes e, em segundo lugar, a carga no servidor de rede aumentará, o que deverá descriptografá-lo primeiro para qualquer ação no pacote (no esquema, quando somente os dados do usuário são criptografados; se o pacote for ignorado formalmente, nada precisará ser descriptografado).

É óbvio que não importa para nós se o invasor sabe ou não o número do pacote - no esquema com re-registro de rede (OTAA), esse conhecimento não o ajudará e, na ABP, ele esperará muito tempo à beira-mar pelo clima, ou seja. a próxima chegada do pacote com o número N-1.

Portanto, é suficiente não deixá-lo mudar esse número.

Para fazer isso, o pacote inteiro no LoRaWAN é assinado com uma assinatura criptográfica - AES-CMAC, essa assinatura no padrão é chamada MIC, Message Integrity Code. Ele verifica se o pacote inteiro , incluindo todos os cabeçalhos e dados, atingiu o servidor inalterado.

Ou seja, depois de aceitar o próximo pacote, podemos analisar rapidamente seu contador (endereço do remetente, etc.) e, se for nosso e correto, já verificar a assinatura (gastando recursos adicionais) e se a assinatura também estiver correta - descriptografar os dados e transmitir eles ainda mais.

Rastreando dados inalteráveis

Infelizmente para nós, não basta impedir que um invasor entenda os dados ou, pelo menos, repita-os - em alguns casos, será suficiente para ele entender que eles não estão mudando. Um exemplo de livro didático é o medidor de água doméstico: se você apenas deseja descobrir se os proprietários estão em casa, não importa exatamente quantos litros existem, é importante que você saiba se esse valor está aumentando .

Obviamente, a criptografia de dados é um procedimento reversível (eles podem ser descriptografados), o que significa que os mesmos dados criptografados com a mesma chave sempre parecem iguais. Ao receber pacotes de um hidrômetro, cujas leituras não são alteradas, você pode, sem descriptografar o pacote , entender que elas não são alteradas.

Lidar com isso é bastante simples - os dados ou a chave devem mudar. Para alterar os dados, você pode adicionar sal a eles - alguns bytes aleatórios que são simplesmente jogados fora após a descriptografia. Infelizmente, 16 bytes de um pacote já são escassos; portanto, no caso geral, não queremos gastar de 2 a 4 bytes deles em lixo real.

LoRaWAN usa um esquema mais complicado . Lembre-se de que temos um contador de pacotes? Portanto, esse contador específico, além de informações sobre o dispositivo e o pacote (endereço curto do dispositivo na rede LoRaWAN, direção da transferência de dados, contador de 16 bytes) são criptografados usando o algoritmo AES, e o resultado XOR está no pacote de dados do usuário.

Como resultado, os bytes da carga útil não são desperdiçados e cada mensagem parece diferente, independentemente de a carga ter sido alterada ou não.

PS Existe outra opção, um pouco mais simples: use o contador de mensagens como os últimos N bytes da chave. Nesse caso, a chave será nova a cada vez, mas porque Como o servidor conhece o valor do contador de mensagens (ele está na parte não criptografada da mensagem), ele poderá restaurá-lo. Menos - se o seu pacote consistir em vários blocos de 16 bytes e eles tiverem os mesmos dados, depois da criptografia eles permanecerão os mesmos.

O invasor aprendeu a chave de criptografia

É uma situação muito real - a IoT é caracterizada pelo uso de um grande número de dispositivos, sobre os quais você geralmente não pode ter um controle confiável sobre o acesso a pessoas de fora (e se você também é um operador de rede, seus clientes são por definição externos).

Portanto, se todos os seus dispositivos tiverem a mesma chave de criptografia, o proprietário de um deles poderá ouvir o tráfego de qualquer outro dispositivo (em geral, se ele tiver a capacidade de modificar o firmware, então, para tal operação, talvez você nem conheça a chave explicitamente - deixe o novo firmware o leva do mesmo local que o antigo e apenas fornece os dados de outras pessoas).

O LoRaWAN implementa dois esquemas para o uso de chaves, individuais para cada dispositivo:

• Ativação Over The Air, OTAA - chaves são geradas pelo servidor de rede toda vez que um dispositivo é registrado nele
• Ativação por personalização - as teclas são definidas pelo fabricante e armazenadas no dispositivo, nunca mudando

Existem pelo menos duas chaves no total - AppSKey, que criptografa os dados do usuário, e NwkSKey, que assina a mensagem.

Obviamente, o esquema OTAA é mais conveniente e confiável - as chaves podem mudar quantas vezes você quiser, elas são garantidas como únicas e desconhecidas por ninguém, exceto pelo servidor de rede. No ABP, as chaves nunca mudam, a exclusividade depende da consciência do fabricante do dispositivo (por exemplo, geramos essas chaves a partir do ID exclusivo do microcontrolador, portanto, a probabilidade de coincidência nos dois dispositivos é desprezível) e elas devem ser armazenadas explicitamente em algum lugar, portanto, ao conectar o dispositivo na rede registre-os no servidor.

No entanto, o procedimento para obter chaves no OTAA é uma história separada que, se implementada incorretamente, pode dar origem a vários outros tipos de ataques.

Interceptação de chaves geradas

Obviamente, se novas chaves forem geradas a cada vez durante o registro na rede, elas deverão ser sincronizadas entre o dispositivo e o servidor, o que significa que um invasor pode interceptá-las, quebrando toda a proteção.

Portanto , os dispositivos LoRaWAN têm uma terceira chave - AppKey, firmemente conectada ao dispositivo e usada em um único momento: ao se registrar na rede. Com ele, é assinada uma troca de chaves de sessão entre o dispositivo e o servidor.

Idealmente, o AppKey deve ser exclusivo para cada dispositivo, mas em muitos casos o uso do mesmo AppKey é permitido - já que é necessário apenas uma vez, isso pode ser reconhecido como válido.

O AppKey antes de conectar o dispositivo é inserido em suas configurações no servidor de rede.

Portanto, o dispositivo gera uma solicitação de registro (JoinRequest), não criptografando-a (não possui informações confidenciais), mas assinando-a com a tecla AppKey. O servidor de rede, após receber este pacote e verificar o endereço do remetente (se este é o nosso dispositivo) e depois a assinatura, responde com o pacote JoinAccept, no qual transfere as configurações de rede - bem, na verdade, confirma o registro.

De onde vêm as chaves AppSKey e NwkSKey?

Este é o resultado da criptografia AES-128 com a chave AppKey de uma combinação de um número AppNonce aleatório, número de chave (1 ou 2), ID da rede e outro número DevNonce aleatório enviado pelo servidor na resposta:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce) 

Como o dispositivo e o servidor após a troca de pacotes de registro conhecem todos esses parâmetros, eles geram as mesmas chaves. Portanto, em nenhum momento nenhuma chave será transmitida por rádio por conta própria, mas, ao mesmo tempo, o dispositivo e o servidor receberão chaves exclusivas de criptografia e assinatura de pacotes.

Interceptação de um fluxo de dados em si mesmo

Mas isso não é tudo!

Sim, o evento de registro na rede geralmente não é frequente, mas imagine que um invasor foi capaz de iniciá-lo e interceptá-lo.

Então, se ele simplesmente enviar o pacote JoinRequest que ele gravou, sem alterar nada, o servidor responderá a ele com o pacote JoinAccept, gerando novas chaves. Depois disso, o dispositivo atacado simplesmente parará de se comunicar com o servidor, porque não iniciou o JoinRequest e não vê nenhum motivo para atualizar as chaves. Ou seja, o mesmo ataque é repetido - mas já no procedimento de registro na rede.

Um invasor não poderá falsificar os dados, pois para isso você precisa conhecer as chaves e, para obtê-las, precisa conhecer o AppKey, que ele não conhece. Mas para tirar o dispositivo da rede - ele pode.

Para evitar isso, durante o registro, o dispositivo envia um número aleatório de DevNonce para o servidor (veja, está nos pacotes acima). Além do fato de as chaves serem geradas em sua base, ele serve a outro propósito - o servidor LoRaWAN armazena o arquivo DevNonce . Se o dispositivo receber uma solicitação de registro repetida com o DevNonce já usado, o servidor simplesmente o ignorará.

Por sua vez, o dispositivo é obrigado a gerar um novo DevNonce a cada registro (ou seja, o circuito com o relé de pacotes convencionais - "não recebeu uma resposta, cuspiu o mesmo pacote no rádio pela segunda vez" - não funciona aqui, o JoinRequest é recriado sempre).

Conclusão

Embora tenha mostrado muito texto e poucas fotos, mesmo este não é um esquema completo de possíveis ataques apenas no rádio (as perguntas sobre por que, por exemplo, as configurações devem ser criptografadas no dispositivo, deixamos a chave com uma chave individual para cada dispositivo fora dos colchetes, não se trata mais do rádio). Por exemplo, no LoRaWAN 1.1, os esquemas de proteção se tornaram ainda mais complicados.

Não obstante, este é um conjunto de cavalheiros de qualquer protocolo de rádio que alega ter proteção mínima digna das informações e, ao mesmo tempo, foi projetado para funcionar em dispositivos de baixa potência em redes de baixa velocidade. Além disso, este é um exemplo muito bom de implementação não apenas de um protocolo seguro, mas de um protocolo escrito para dispositivos de baixo consumo de energia e de minimizar o consumo de tempo de antena e de computação sempre que possível, sem danos significativos à segurança.

E se você estiver projetando seu próprio protocolo para a IoT, o LoRaWAN bem especificado, combinado com o entendimento dos métodos básicos de condução de ataques, oferece uma excelente oportunidade para aprender a organizar adequadamente essa proteção.