4. Usando MQTT com segurança (TLS)¶

Nota

Público: administradores
Nível: intermediário
Tempo de leitura: 15 ms

Este documento descreve como configurar o dojot para usar o MQTT sobre TLS quando usando o microsserviço IotAgent-Mosca

Índice

Componentes
- EJBCA-REST
  - O que é um certificado?
  - Então, como o EJBCA funciona no dojot?
- Mosca
Certificate retriever
Simulando um dispositivo com mosquitto
Anotações importantes
- Debugging
  - Como ler um certificado

Para que um dispositivo se conecte usando o TLS com o Mosca, ele deve possuir:

Um par de chaves (arquivo .key)
Um certificado assinado por uma Autoridade de Certificação (CA) confiável por Mosca(arquivo .crt);
O certificado desta CA (arquivo .crt);

Quando um dispositivo é criado, o DeviceManager notifica automaticamente os seguintes componentes:

IoTAgent-Mosca: registrará o novo dispositivo em seu cache interno e criará uma entrada, permitindo que o dispositivo publique em um tópico especifico.
EJBCA: criará uma entidade final para que um certificado possa ser criado no futuro.

O EJBCA`_ é uma infraestrutura de chave privada (PKI) completa capaz de gerenciar CAs, chaves de criptografia e certificados. O EJBCA fornece SOAP, web e uma interface de linha de comandos. O EJBCA-REST é um wrapper no topo do EJBCA que fornece interface moderna como REST .

O EJBCA fornece interfaces SOAP, web e de linha de comando. EJBCA-Rest é um wrapper do EJBCA que o complementa, permitindo que a CA seja configurado usando REST. Quando usado na dojot, ele também escuta eventos Kafka, permitindo sua configuração automática.

4.1.1.1. O que é um certificado?¶

Um certificado contém a chave pública de uma entidade (um usuário, dispositivo, website), juntamente com informações sobre essa entidade, sobre a CA que assina o certificado, o uso permitido do certificado e uma soma de verificação. Quando uma entidade deseja que um certificado seja assinado, a entidade deve criar um arquivo CSR e enviá-lo para a CA desejada. O arquivo CSR é uma ‘intenção de certificação’. O arquivo contém as informações necessárias da entidade e algumas informações sobre o uso do certificado, nomes de host e IPs onde o certificado residirá, nomes alternativos para a entidade etc. A EJBCA pode decidir, usando suas políticas configuradas, quais informações manter, descartar e substituir do CSR recebido. EJBCA pode recusar assinar um CSR se concluir que não é seguro o suficiente de acordo com sua políticas.

Essas políticas configuráveis são chamadas de ‘Perfis de certificado’. Um perfil do certificado chamado CFREE, especializado para MQTT TLS, é fornecido.

Em resumo, o CFREE tem as seguintes configurações (e muitas mais):

As chaves de criptografia devem ter entre 2048 e 8192 bits;
As entidades podem definir nomes de host e IPs;
O uso da chave está marcado como não crítico (por enquanto);
O algoritmo de hash é SHA256. O algoritmo de assinatura é RSA.

4.1.1.2. Então, como o EJBCA funciona no dojot?¶

Ao criar um novo dispositivo, uma entidade associada é criada na EJBCA. Seu nome será o ID do dispositivo (como ‘f60c28’) e sua senha será sempre ‘dojot’.

Um certificado pode ser assinado enviando uma solicitação HTTP POST para host:8000/sign/<cname>/pkcs10. CName é o nome da entidade final (ou device). O payload enviada com esta solicitação deve ser um JSON contendo a senha da entidade final e um arquivo CSR (intenção de certificado) em base64.

Observe que a URL é ‘roteado’ pelo gateway da API. Como em outras APIs na dojot, é necessário um JWT. Você pode descobrir como gerar e como usar tal JWT em Utilizando a API da dojot.

Para criar o arquivo CSR e solicitar uma assinatura de certificado, um usuário pode usar um script auxiliar chamado ‘Certificate Retriever’, que é detalhado na seção Certificate retriever.

4.1.2. Mosca ¶

Mosca é um broker mqtt em node.js. Para usar o Mosca, você precisa fazer algumas configurações por variável de ambiente:

MOSCA_TLS_DNS_LIST: lista de DNSs TLS, o host para conectar externamente (separado por vírgula). Exemplo: localhost, meudominio.com

Todos os certificados serão criados automaticamente no broker, sem a necessidade de configurar manualmente os certificados no broker.

Nota: Para usar Mosca sem TLS também, você precisa definir a variável de ambiente ALLOW_UNSECURED_MODE para ‘true’ e usar a porta 1883. Não é recomendado!

4.2. Certificate retriever ¶

Este componente é um script auxiliar para a criação de certificados de dispositivo. É disponível em Certificate Retriever GitHub repository e codificado usando Python 3.

Um usuário pode usá-lo executando:

sudo apt install python3-pip #run on Debian-based Linux distributions, if necessary

pip3 install crypto #or pip install crypto, run if necessary
pip3 install pyOpenSSL #or pip install pyOpenSSL, run if necessary
pip3 install requests #or pip install requests, run if necessary

mkdir -p certs

E finalmente obter o certificado para o dispositivo:

python3 generateLoginPwd.py  ${DOJOT_HOST} ${DEVICE_ID} IOTmidCA #run every time

Os parâmetros obrigatórios são:

${DOJOT_HOST}: onde está o dojot (Sem / no final). Exemplo: http://localhost:8000
${DEVICE_ID}: ID do dispositivo que receberá um novo certificado. Exemplo: f60c28

Observe que a autenticação é realizada na dojot. O script solicitará credenciais do usuário e invocará a autenticação do usuário automaticamente. O usuário precisa de permissão para assinar o certificado para poder usar essa rota.

Uma entidade final deve existir na EJBCA no estado ‘Novo’ antes de solicitar uma nova assinatura de certificado. Quando um novo dispositivo é criado, uma entidade final é criado automaticamente no EJBCA pelo DeviceManager. Esta nova entidade finalname é o próprio ID do dispositivo. Sua senha é ‘dojot’.

O script autentica os usuários com nome de usuário e senha, recupera o certificado da CA, gera um par de chaves e um arquivo CSR e solicita a assinatura do certificado, nesta ordem. Qualquer erro em qualquer etapa será interrompa sua execução.

Após executado com sucesso, todos os certificados podem ser encontrados na pasta ‘./certs’.

4.3. Simulando um dispositivo com mosquitto¶

Para publicar e assinar usando os certificados apropriados, você deve estar com o Mosca Broker e o EJBCA em execução. Depois de criar o ambiente dojot, os modelos (templates) e os dispositivos. Então usando o mosquitto emule um dispositivo, publique e subscreva-se nos tópicos desejados:

Antes de instalar mosquitto_pub e mosquitto_sub (do pacote mosquitto-clients em Debian-based Linux distribuições) e acessar a pasta certs, se necessário:

Atenção

Algumas distribuições Linux, distribuições Linux baseadas em Debian em particular, tem dois pacotes para mosquitto - um contendo ferramentas para cliente (ou seja, mosquitto_pub e mosquitto_sub para publicar mensagens eassinando tópicos) e outro contendo o broker MQTT também. E neste tutorial, apenas as ferramentas do pacote mosquitto-clients em Distribuições Linux baseadas no Debian serão usadas. Verifique se o broker MQTT não está em execução antes de iniciar o dojot (executando comandos como ps aux | grep mosquitto) para evitar conflitos de porta.

sudo apt-get install mosquitto-clients   #if necessary on Debian-based Linux distributions
cd certs  #if necessary

Como publicar:

mosquitto_pub  -h localhost -p 8883 -t /<tenant>/<deviceId>/attrs -i <tenant>:<deviceId> -m '{"attr_example": 10}' --cert <your .crt file> --key <your .key file> --cafile IOTmidCA.crt

Como se subscrever:

mosquitto_sub  -h localhost -p 8883 -t /<tenant>/<deviceId>/config -i <tenant>:<deviceId> --cert <your .crt file> --key <your .key file> --cafile IOTmidCA.crt

O <seu arquivo .crt>, <seu arquivo .key> e o cafile podem ser criados com o script do Certificate Retriever GitHub repository. Onde <tenant> é um identificador de contexto na dojot e <deviceId> é um identificador para o dispositivo no contexto correspondente.

Nota: neste caso, a mensagem é uma publicação com um atributo, este atributo tem o rótulo attr_example e um novo valor 10, você precisará mudar isso para o seu caso de uso.

4.4. Anotações importantes ¶

Estas são algumas notas importantes, relacionadas à segurança do dispositivo e assuntos associados.

4.4.1. Debugging ¶

Os erros do TLS podem não ser tão detalhados quanto outros problemas. Se houver um erro, o usuário pode não saber o que deu errado porque nenhum componente indica algum problema. Nesta seção, existem algumas dicas, frequentemente as ferramentas de depuração ajudam a descobrir o que está acontecendo.

4.4.1.1. Como ler um certificado ¶

Um arquivo de certificado pode estar em dois formatos: PEM (texto base64) ou DER(binário). O OpenSSL oferece ferramentas para ler esses formatos:

openssl x509 -noout -text -in certFile.crt