Soluções Completas em Automação Industrial
Conteúdos e materiais
Cada dispositivo final (end device) deve ser registrado em uma rede antes de enviar e receber mensagens. Este procedimento é conhecido como ativação. Existem dois métodos de ativação disponíveis:
Ativação Over-The-Air (OTAA) – é o método de ativação mais seguro e recomendado para dispositivos finais. Os dispositivos realizam um procedimento de adesão à rede, durante o qual um endereço de dispositivo dinâmico é atribuído e chaves de segurança são negociadas com o dispositivo.
Ativação por personalização (ABP) – requer codificação do endereço do dispositivo, bem como das chaves de segurança no dispositivo. O ABP é menos seguro que o OTAA e também tem a desvantagem de que os dispositivos não podem trocar de provedor de rede sem alterar manualmente as chaves no dispositivo.
O procedimento de adesão para LoRaWAN 1.0.x e 1.1 é um pouco diferente. As duas seções a seguir descrevem o procedimento de adesão para LoRaWAN 1.0.x e 1.1 separadamente.
No LoRaWAN 1.0.x, o procedimento de adesão requer a troca de duas mensagens MAC entre o dispositivo final e o servidor de rede:
- Solicitação de adesão (Join-request) – do dispositivo final para o servidor de rede;
- Aceite de adesão (Join-accept) – do servidor de rede ao dispositivo final.
Antes da ativação, o AppEUI, DevEUI e AppKey devem ser armazenados no dispositivo final. A AppKey é uma chave secreta AES de 128 bits conhecida como chave raiz. A mesma AppKey deve ser provisionada na rede onde o dispositivo final será registrado. O AppEUI e o DevEUI não são secretos e são visíveis para todos.
Observação: O AppKey nunca é enviado pela rede. As etapas a seguir descrevem o procedimento de ativação Over-The-Air (OTAA).
O procedimento de adesão é sempre iniciado pelo dispositivo final. O dispositivo final envia a mensagem de solicitação de adesão para a rede à qual será ingressado. A mensagem de solicitação de adesão consiste nos seguintes campos.
(AppEUI 8 bytes) (DevEUI 8 bytes) (DevNonce 2 bytes)
AppEUI – identificador de aplicativo globalmente exclusivo de 64 bits no espaço de endereço IEEE EUI64 que identifica exclusivamente a entidade capaz de processar a solicitação Join-req.
DevEUI – identificador de dispositivo globalmente exclusivo de 64 bits no espaço de endereço IEEE EUI64 que identifica exclusivamente o dispositivo final.
DevNonce – valor único e aleatório de 2 bytes gerado pelo dispositivo final. O Network Server usa o DevNonce de cada dispositivo final para controlar suas solicitações de adesão. Se um dispositivo final enviar uma solicitação de ingresso com um DevNonce usado anteriormente (essa situação é conhecida como ataque de repetição), o servidor de rede rejeitará a solicitação de ingresso e não permitirá que esse dispositivo final se registre na rede.
O Código de Integridade da Mensagem (MIC) é calculado em todos os campos da mensagem de solicitação de adesão usando o AppKey. O MIC calculado é então adicionado à mensagem de solicitação de adesão.
Observação: O AppKey não é enviado com a mensagem de solicitação de adesão e a mensagem de solicitação de adesão não é criptografada.
A mensagem de solicitação de adesão pode ser transmitida usando qualquer taxa de dados e usando um dos canais de adesão específicos da região. Por exemplo, na Europa, um dispositivo final pode transmitir a mensagem de solicitação de adesão escolhendo aleatoriamente entre 868,10 MHz, 868,30 MHz ou 868,50 MHz. A mensagem de solicitação de adesão passa por um ou mais gateways até o Network Server.
O Network Server processa a mensagem de solicitação de adesão. O Network Server gerará duas chaves de sessão (NwkSKey e AppSKey) e a mensagem Join-accept se o dispositivo final tiver permissão para ingressar em uma rede.
A mensagem Join-accept consiste nos seguintes campos:
(AppNonce 3 bytes) (NetID 3 bytes) (DevAddr 4 bytes) (DLSettings 1 byte) (RXDelay 1 byte) (CFList 16 bytes (opcional))
AppNonce – um valor aleatório ou ID exclusivo fornecido pelo Network Server. O AppNonce é usado pelo dispositivo final para derivar as duas chaves de sessão, AppSKey e NwkSKey.
NetID – consiste no identificador de rede (NwkID), os 7 bits mais significativos.
DevAddr – um endereço de dispositivo de 32 bits atribuído pelo Network Server para identificar o dispositivo final na rede atual.
DLSettings – um campo de 1 byte que consiste em configurações de downlink que o dispositivo final deve usar.
RxDelay – contém o atraso entre TX e RX.
CFList – uma lista opcional de frequências de canal para a rede à qual o dispositivo final está ingressando. Essas frequências são específicas da região.
O Código de Integridade da Mensagem (MIC) é calculado em todos os campos da mensagem Join-accept usando o AppKey.
O MIC calculado é então adicionado à mensagem Join-accept. A própria mensagem Join-accept é então criptografada com o AppKey. O Network Server usa uma operação de descriptografia AES no modo ECB para criptografar a mensagem Join-accept.
O Network Server envia a mensagem criptografada de aceitação de adesão de volta ao dispositivo final como um downlink normal.
Observação: Nenhuma resposta será dada ao dispositivo final se a mensagem de solicitação de adesão não for aceita pelo Network Server.
O Network Server mantém o NwkSKey e distribui o AppSKey para o Application Server.
O dispositivo final decodifica a mensagem Join-accept usando a operação de criptografia AES. O dispositivo final usa AppKey e AppNonce para derivar as duas chaves de sessão, a chave de sessão de rede (NwkSKey) e a chave de sessão de aplicativo (AppSKey).
O dispositivo final agora está ativado na rede.
Após a ativação, as seguintes informações adicionais são armazenadas no dispositivo final.
DevAddr – um endereço de dispositivo de 32 bits atribuído pelo Network Server para identificar o dispositivo final na rede atual.
NwkSKey – a chave de sessão de rede é usada pelo dispositivo final e pelo servidor de rede para calcular e verificar o código de integridade da mensagem (MIC) de todas as mensagens de dados para garantir a integridade da mensagem. O NwkSKey também é usado para criptografar e descriptografar cargas úteis com comandos MAC.
AppSKey – a chave de sessão do aplicativo é usada para criptografar e descriptografar cargas úteis do aplicativo em mensagens de dados para garantir a confidencialidade da mensagem.
No LoRaWAN 1.0.x, o procedimento de adesão requer que duas mensagens MAC sejam trocadas entre o dispositivo final e o servidor de junção:
Solicitação de adesão (Join-request) – do dispositivo final para o servidor de rede;
Aceite de adesão (Join-accept) – do servidor de rede ao dispositivo final.
Antes da ativação, JoinEUI, DevEUI, AppKey e NwkKey devem ser armazenados no dispositivo final. O AppKey e o NwkKey são chaves secretas AES de 128 bits conhecidas como chaves raiz. O AppKey, NwkKey e DevEUI correspondentes devem ser provisionados no Join Server que ajudará no processamento do procedimento de junção e na derivação da chave de sessão. O JoinEUI e o DevEUI não são secretos e são visíveis para todos.
Observação: O AppKey e o NwkKey nunca são enviados pela rede. As etapas a seguir descrevem o procedimento de ativação Over-The-Air (OTAA).
Passo 1
O procedimento de adesão é sempre iniciado pelo dispositivo final. O dispositivo final envia a mensagem de solicitação de adesão para a rede à qual será ingressado. A mensagem de solicitação de adesão consiste nos seguintes campos.
(EUI 8 bytes) (DevEUI 8 bytes) (DevNonce 2 bytes)
JoinEUI – identificador global de aplicação de 64 bits no espaço de endereço IEEE EUI64 que identifica exclusivamente o servidor de adesão que pode auxiliar no processamento da solicitação de adesão e na derivação das chaves de sessão.
DevEUI – identificador global de aplicação de 64 bits no espaço de endereço IEEE EUI64 que identifica exclusivamente o dispositivo final.
DevNonce – contador de 2 bytes, começando em 0 quando o dispositivo é inicialmente ligado e incrementado a cada solicitação de ingresso. O valor DevNonce é usado para evitar ataques de repetição (retentativas).
Observação: No LoRaWAN 1.1 AppEUI é substituído pelo JoinEUI.
O MIC é calculado em todos os campos da mensagem de solicitação de adesão usando NwkKey. O MIC calculado é então adicionado à mensagem de solicitação de adesão.
Observação: O NwkKey não é enviado com a mensagem de solicitação de adesão, e a mensagem de solicitação de adesão não é criptografada, mas enviada como texto simples.
A mensagem de solicitação de adesão pode ser transmitida usando qualquer taxa de dados e usando um dos canais de adesão específicos da região. Por exemplo, na Europa, um dispositivo final pode transmitir a mensagem de solicitação de adesão escolhendo aleatoriamente entre 868,10 MHz, 868,30 MHz ou 868,50 MHz. A mensagem de solicitação de adesão passa por um ou mais gateways até o servidor de rede.
Observação: Nenhuma resposta será dada ao dispositivo final se a solicitação de adesão não for aceita.
O Network Server encaminha a mensagem de solicitação de ingresso para o servidor de ingresso correspondente.
O servidor de adesão processa a mensagem de solicitação de ingresso. O servidor de adesão gerará todas as chaves de sessão (AppSKey, FNwkSIntKey, SNwkSIntKey e NwkSEncKey) se o dispositivo final tiver permissão para ingressar na rede.
Se a etapa acima for bem-sucedida, o servidor de adesão gera a mensagem Join-accept. A mensagem Join-accept consiste nos seguintes campos.
(JoinNonce 1 byte) (NetID 3 bytes) (DevAddr 4 bytes) (DLSettings 1 byte) (RXDelay 1 byte) (CFList 16 bytes)
JoinNonce – valor de contador específico do dispositivo fornecido pelo servidor de adesão e usado pelo dispositivo final para derivar as chaves de sessão, FNwkSIntKey, SNwkSIntKey, NwkSEncKey e AppSKey.
NetID – identificador de rede exclusivo de 24 bits.
DevAddr – endereço de dispositivo de 32 bits atribuído pelo servidor de rede para identificar o dispositivo final na rede atual.
DLSettings – campo de 1 byte que consiste em configurações de downlink que o dispositivo final deve usar.
RxDelay – contém atraso entre TX e RX
CFList – lista opcional de frequências de canal para a rede na qual o dispositivo final está ingressando. Essas frequências são específicas da região.
O código de integridade da mensagem (MIC) é calculado em todos os campos da mensagem Join-accept usando NwkKey (para dispositivos LoRaWAN 1.0) ou JSIntKey (para dispositivos LoRaWAN 1.1). O MIC calculado é então adicionado à mensagem Join-accept.
A mensagem Join-accept é então criptografada com o NwkKey. O servidor de rede usa uma operação de descriptografia AES no modo ECB para criptografar a mensagem join-accept.
A mensagem Join-accept é criptografada com NwkKey (se acionada pela solicitação Join) ou JSEncKey (se acionada pela solicitação Rejoin).
Em seguida, o servidor de rede envia a mensagem criptografada de aceitação de adesão de volta ao dispositivo final como um downlink normal.
Observação: Nenhuma resposta será dada ao dispositivo final se a mensagem de solicitação de adesão não for aceita pelo Network Server.
O servidor de adesão envia o AppSKey para o servidor de aplicação e as três chaves de sessão de rede (FNwkSIntKey, SNwkSIntKey e NwkSEncKey) para o servidor de rede.
O dispositivo final descriptografa a mensagem Join-accept usando a operação de criptografia AES. O dispositivo final usa AppKey, NwkKey e JoinNonce para gerar chaves de sessão.
Para dispositivos LoRaWAN 1.0.x:
AppSKey é derivado do NwkKey.
FNwkSIntKey, SNwkSIntKey e NwkSEncKey são derivados de NwkKey.
Para dispositivos LoRaWAN 1.1:
AppSKey é derivado de AppKey.
FNwkSIntKey, SNwkSIntKey e NwkSEncKey são derivados de NwkKey.
O dispositivo final agora está ativado na rede. Após a ativação, as seguintes informações adicionais são armazenadas no dispositivo final.
DevAddr – endereço de dispositivo de 32 bits atribuído pelo servidor de rede para identificar o dispositivo final na rede atual.
FNwkSIntKey – chave de sessão de rede usada pelo dispositivo final para calcular o MIC (parcialmente) de todas as mensagens de dados de uplink para garantir a integridade da mensagem.
SNwkSIntKey – chave de sessão de rede que é usada pelo dispositivo final para calcular o MIC (parcialmente) de todas as mensagens de dados de uplink e calcular o MIC de todas as mensagens de dados de downlink para garantir a integridade da mensagem.
NwkSEncKey – chave de sessão de rede usada para criptografar e descriptografar as cargas úteis com comandos MAC das mensagens de dados de uplink e downlink para garantir a confidencialidade da mensagem.
AppSKey – chave de sessão usada pelo servidor de aplicativos e pelo dispositivo final para criptografar e descriptografar os dados do aplicativo nas mensagens de dados para garantir a confidencialidade da mensagem.
A ativação por personalização (ABP) vincula diretamente um dispositivo final a uma rede pré-selecionada, ignorando o procedimento de ativação over-the-air. A ativação por personalização é o método de ativação menos seguro e também tem a desvantagem de que os dispositivos não podem trocar de provedor de rede sem alterar manualmente as chaves no dispositivo. Um servidor de adesão não está envolvido no processo ABP.
Um dispositivo final ativado usando o método ABP só pode funcionar com uma única rede e mantém a mesma sessão de segurança durante toda a sua vida útil.
O DevAddr e as duas chaves de sessão NwkSKey e AppSKey são armazenadas diretamente no dispositivo final em vez de DevEUI, AppEUI e AppKey. Cada dispositivo final deve ter um conjunto exclusivo de NwkSKey e AppSkey. O mesmo DevAddr e NwkSKey devem ser armazenados no servidor de rede e o AppSKey deve ser armazenado no servidor de aplicação.
O DevAddr e as chaves de quatro sessões FNwkSIntKey, SNwkSIntKey, NwkSEncKey e AppSKey são armazenados diretamente no dispositivo final em vez de DevEUI, JoinEUI, AppKey e NwkKey. Os mesmos DevAddr, FNwkSIntKey, SNwkSIntKey e NwkSEncKey devem ser armazenados no servidor de rede e AppSKey devem ser armazenados no Application Server.
Artigo original: https://www.thethingsnetwork.org/docs/lorawan/end-device-activation/