Olá queridos amantes da Internet das Coisas. Notas de continuação Provedor de IoT.
A primeira parte > || >
Segunda parte > || >
Terceira parte > || >
A quarta parteHoje é hora de falar sobre segurança na LoRaWAN. Existem muitos rumores e lendas. Vamos tentar descobrir como isso funciona e quais são os riscos.
Para passar ao tópico de segurança, você terá que fazer uma pequena introdução e falar sobre a inicialização do módulo de rádio na rede. Esse processo no LoRaWAN é chamado de ativação.
Por uma questão de brevidade, listarei abaixo os termos de que precisamos. Se você ficar um pouco confuso - pode voltar aqui e conferir. Você provavelmente tem que voltar, porque abreviações de muitos termos são muito semelhantes. Além disso, nesta descrição, darei analogias para que você entenda mais ou menos com o que esse ou aquele termo pode ser comparado. Nem sempre é possível selecionar analogias exatas; portanto, não julgue esta coluna com muito rigor.
Portanto, a ativação no LoRaWAN pode ser feita por via aérea (OTAA) ou predefinida (ABP).
OTAA (Ativação Over the Air)
No caso de ativação por via aérea, três parâmetros devem ser definidos em nosso módulo de rádio. Seu identificador exclusivo (DevEUI), identificador do servidor (AppEUI) e chave do servidor (AppKey).
No lado do servidor, o identificador do módulo de rádio, o identificador do servidor e a chave também devem ser registrados. I.e. o servidor deve conhecer inicialmente o dispositivo que tentará ingressar nele. Se conhecermos os identificadores e as chaves do servidor, mas nosso DevEUI não estiver registrado em seu banco de dados, a conexão falhará.
Após a inicialização, o rádio envia o pacote join_request ao ar em uma das três frequências de junção predefinidas. Com este pacote, ele pergunta se existe uma rede próxima que o "reconheça". A seguir, é apresentada a composição do pacote join_request. Como você pode ver, ele contém o próprio DevEUI e AppEUI, além do DevNonce.
DevNonce é uma variável aleatória. O servidor a armazena na memória por algum tempo e, se join_request chegar com o mesmo DevNonce que um dos anteriores, o servidor ignorará essa solicitação. Isso é para proteger contra um ataque repetido quando um invasor pode anotar uma solicitação de ativação e depois repeti-la em seu dispositivo. A propósito, nem todos os padrões da IoT podem se orgulhar de proteção contra esse ataque.
O AppKey não é usado diretamente nesta mensagem, mas através dele é considerada a soma de verificação MIC no final do quadro.
Vamos precisar dessa chave um pouco mais, na mensagem de resposta do servidor join_accept.
Join_request é transmitido sem criptografia.
O Join_accept será recebido se o servidor conhecer AppEUI e DevEUI, assim como não houver correspondência no campo DevNonce e não houver problemas com o MIC. Caso contrário, não haverá resposta.Se todas as verificações forem aprovadas, o servidor gerará uma mensagem de resposta join_accept. Sua composição é mostrada na figura abaixo.
De fato, duas chaves de sessão são geradas - o servidor de rede (NwkSKey) e o servidor de aplicativos (AppSKey). Essas chaves, juntamente com outras informações, são criptografadas pelo AppKey e enviadas ao módulo de rádio. Além disso, todas as mensagens ocorrem com criptografia dupla com chaves de sessão (com exceção dos pacotes com comandos MAC, eles não são criptografados com a chave do servidor de aplicativos). O NwkSKey não participa da criptografia de pacote apenas com dados (sem comandos), mas uma soma de verificação é considerada através dele.
NwkSkey e AppSKey são exclusivos para cada módulo de rádio individual.
Duas chaves são usadas para proteção adicional de informações. Cada vez que um pacote do módulo de rádio chega ao nosso sistema, ele é parcialmente criptografado para o servidor de rede e parcialmente para o servidor de aplicativos. I.e. o servidor de rede poderá descriptografar apenas as mensagens endereçadas a ele (várias mensagens de serviço). O servidor de aplicativos verá apenas o componente útil dos pacotes (na verdade os dados sendo encaminhados). Isso é necessário porque o servidor de rede com uma probabilidade de 99% estará no provedor. Mas o servidor de aplicativos pode muito bem ser hospedado pelo cliente. A criptografia dupla torna difícil para o provedor descobrir o conteúdo do pacote.
Além das duas teclas, há outra coisa importante a ser aceita no OTAA - a lista de frequência estendida (CFList). Deixe-me lembrá-lo que, inicialmente, um módulo de rádio conhece apenas três frequências nas quais pode operar. Após a ativação, freqüências adicionais são registradas para a comunicação.
Isso é muito conveniente se não se sabe exatamente em qual rede o dispositivo funcionará. Podemos concordar que em todas as redes 3 frequências (+ RX2) sempre coincidem, e as cinco restantes ficam a critério do provedor.
Além disso, para o futuro, trabalhar com um grande número de dispositivos CFList pode ser usado para armazenamento em cluster
É quando você divide a rede em clusters e dentro dos clusters existe um planejamento de frequência. Digamos que nosso módulo de rádio conheça as três frequências F1, F2 e F3. Ele é ativado em uma das frequências e, se estiver no cluster1, recebe uma tabela de frequências adicional na forma de F4-1, F5-1 e F6-1. Para o cluster 2, ele obterá F4-2, F5-2, F6-2 completamente diferentes. Ao mesmo tempo, podemos configurar todos os módulos de rádio da mesma maneira e realmente não pensamos qual deles cairá em qual cluster. E em aglomerados vizinhos, a probabilidade de colisões diminuirá drasticamente.
ABP (Ativação por Personalização)
Um procedimento simplificado quando as chaves da sessão são conectadas imediatamente no módulo de rádio e são inicialmente registradas no lado do servidor. Conveniente, pois você não precisa ativar, o módulo de rádio está imediatamente pronto para uso. Nada mais conveniente, porque segurança neste caso é mais ou menos. Além disso, você não pode obter frequências do servidor. Eu nunca vi nenhum caso de uso real. Não o consideraremos e todos os itens a seguir são sobre a OTAA.
E quanto à segurança?
Portanto, em essência, temos a principal carga de criptografia nas chaves de sessão do servidor de rede e do servidor de aplicativos.
Considere-os um pouco mais cuidadosamente.
A principal reclamação dos críticos do padrão LoRaWAN é que, quando o dispositivo é ativado na rede, temos duas chaves, que não podem ser alteradas por meses. Mais precisamente, eles podem não mudar por anos até que o dispositivo seja reativado. Em condições normais, ativamos e esquecemos o módulo de rádio; portanto, uma vida útil de três a quatro anos é uma perspectiva muito realista. Na verdade, desde a instalação até deixar a bateria em zero.
Quão confiáveis são nossas chaves?
A especificação diz que eles estão em conformidade com o misterioso RFC4493.
O que é isso Este é um algoritmo de criptografia, mais conhecido como AES-CMAC.
Não vamos nos arrastar para a natureza da criptografia e nos restringir a um entendimento comum da imagem. É apresentado na figura abaixo.
O princípio do AES-CMAC é aproximadamente o seguinte: a mensagem criptografada é dividida em blocos de 128 bits. Cada bloco é criptografado separadamente com uma chave AES. Além disso, ao criptografar o segundo bloco, além da chave, o resultado da criptografia do primeiro é usado. E ao criptografar o terceiro - o resultado do segundo e (indiretamente) o primeiro. Tal cadeia de complicações.
Quão confiável é esse princípio?
Muito confiável. O algoritmo saiu mais de dez anos atrás. Desde então, ele foi atacado por muitos ataques diferentes e, no final, em teoria, eles provaram que ele pode ser hackeado.O problema é que uma grande amostra de pacotes, vários milhares, será necessária para quebrá-lo. Depois, há uma chance de entender o que há dentro dos blocos criptografados.
Um invasor com o conhecimento necessário pode obter esse exemplo se estivermos falando sobre interceptar pacotes LoRaWAN? Vamos estimar. Deixe os pacotes irem uma vez por hora. Em um mês, 720 pacotes sairão do módulo de rádio. Não chega.
Para uma ameaça real, precisamos de um paciente muito paciente que estará escrevendo pacotes por meses. E não é fato que ele ainda possa decifrar o algoritmo e obter as chaves preciosas. Não esqueça que essa paciência precisará ser demonstrada em relação a cada módulo de rádio separadamente. E lembre-se de que o envio de pacotes uma vez por hora é MUITO frequente. Na prática, os intervalos são muito mais longos - seis horas ou até um dia.
Mas mesmo essa oportunidade fantasmagórica agora está fechada após o lançamento da especificação 1.1, onde os comandos de reativação e ingresso no servidor são implementados. Vamos falar sobre essa especificação de alguma forma. Por enquanto, recordo meu pensamento do artigo anterior: quando o padrão é aberto e tem uma comunidade, todos os seus buracos são visíveis. Durante a atualização, os desenvolvedores sabem exatamente o que procurar primeiro.
Como resultado, descobrimos que a ameaça à segurança é bastante ilusória. Em algum lugar da teoria profunda, o hacking pode ser feito, mas na prática ele praticamente não é realista. Agora multiplique pelo valor das informações recebidas. Nosso atacante começará a escrever pacotes por meses para descobrir o contador? Improvável.
O LoRaWAN atende a essa relação preço-desempenho razoável. Entendemos que a proteção pode ser aprimorada. Mas esse é o poder de computação do final, é uma carga adicional na bateria, é possível aumentar o tamanho dos pacotes ou reduzir a carga útil.
Para mim, é mais do que uma tarefa de telemetria.
Nos comentários, terei prazer em ouvir meus oponentes e torcedores. Lembre-se de que o tópico segurança sempre requer discussão e nunca deve se basear na opinião de uma pessoa.