Como posso usar o 2FA em uma rede MQTT?

12

Como posso usar 2FA (autenticação de dois fatores) quando conecto um novo dispositivo ao broker, se isso é possível?

Como parece mais fácil, o segundo fator pode ser uma solução de software primeiro, mas gostaria de receber idéias sobre como introduzir tokens físicos (talvez RFID).

Faria sentido se os dispositivos deveriam se autenticar apenas na primeira conexão e o servidor se lembrasse de clientes "antigos".

A idéia talvez incomum ou inadequada - se for uma má idéia, por favor, me dê as razões.

security mqtt authentication

— Bence Kaulics
fonte

Você pode nos dizer como você acha que um dispositivo poderia fazer 2FA, por ser um dispositivo?

— Goufalite

@Goufalite Por exemplo, quando instalo um novo dispositivo, tenho que fornecer uma chave manualmente (por uma etiqueta RFID, por exemplo) que será usada durante a autenticação. Quanto ao software 2FA, não sei se algum tipo de serviço poderia ser configurado em minha casa a partir do qual novos dispositivos poderiam solicitar tokens flexíveis, algo como um servidor de chave privada.

— Bence Kaulics

8

Você precisa de um proxy de corretor ou um servidor da web ...

Primeiro de tudo, você precisa absolutamente de um serviço de autenticação em algum lugar conectado ao seu broker para executar o 2FA usando tópicos específicos ( /auth/RFID, ...). Isso permitiria ao cliente publicar informações (veja abaixo).

O primeiro problema que vejo aqui é que qualquer pessoa inscrita neste tópico pode ler as informações desse tópico, mas você pode bloquear tópicos !

Você pode dizer (forçar) todos os seus dispositivos para publicar informações /proxy/mytopic. Com o recurso clientId do mqtt, o serviço de autenticação pode verificar se as mensagens enviadas deste tópico são de um dispositivo autenticado que usava o 2FA anteriormente e, em seguida, publicar sua própria mensagem em nome do dispositivo /proxyout/mytopiccom o ID do dispositivo na carga útil.

O problema agora é procurar dispositivos que possam receber mensagens se eles forem autenticados, porque, bem, o MQTT tem tudo a ver com publicação em massa. O serviço de autenticação precisa ter uma lista de dispositivos autenticados e verificar se eles são elegíveis para recepção. Novamente, criptografia de carga útil e descriptografia no lado do dispositivo ...

Acho que minha solução é muito exagerada sobre os recursos do MQTT. Portanto, você deve usar um soquete ou um servidor web ...

— Goufalite
fonte

@ tim3in desculpe pela resposta tardia. Depois de tudo isso, foi uma resposta dada há 2,5 anos ... talvez as coisas tenham mudado e essa foi apenas uma proposta de arquitetura geral. Você fez um POC com sua solução?

— Goufalite 17/07/19

Eu planejei isso. Você será capaz de revisá-lo?

— tim3in 17/07/19

7

A próxima especificação do MQTT v5 adiciona suporte ao AUTHpacote de controle, o que permite autenticação de desafio / resposta. Como o MQTT v5 ainda não está finalizado, o suporte ainda pode mudar, mas parece razoável supor que o AUTH permanecerá de uma forma ou de outra e que 2FA pode ser adicionado usando-o.

Você pode ver os rascunhos de trabalho atuais da especificação na página de documentos do comitê OASIS MQTT .

— ralight
fonte

5

Conforme a especificação, a mensagem de conexão pode opcionalmente fornecer nome de usuário e senha. Isso é validado com relação a uma ACL salva em algum lugar no broker. Portanto, esse é seu primeiro fator de autenticação que você pode explorar. A mensagem CONNACK do broker responderá se a autenticação for concluída.

Para implementar o segundo fator se a autenticação, a melhor maneira deve ser enviar uma mensagem de conexão personalizada com o outro fator. A mensagem CONNACK neste caso deve se referir ao sucesso ou falha do segundo fator de autenticação. Portanto, o broker e o cliente devem implementar mensagens customizadas além da especificação.

— cogito ergo sum
fonte

4

Para obter 2FA na rede MQTT, criei os seguintes serviços para autenticação conectados ao Broker.

Verificador de ID
Gerador de token
Verificador de token

Quando o cliente MQTT se conecta ao broker sobre SSL / TLS, ele primeiro publica seu próprio ID no tópico device_id , o Verificador de ID verifica se é o cliente autêntico e, em seguida, o Token Generator é chamado, o que gera um token e publica o token no tópico bloqueado device_token .

O dispositivo cliente obtém esse token e o publica ainda em um tópico confirm_token . Assim que o tópico é publicado no confirm_token, o verificador de token compara os valores no tópico device_token e confirm_token se corresponder a ele, adicione o ID do dispositivo ao pool de dispositivos verificado e permita que o dispositivo publique dados. Isso melhora a segurança porque os únicos dispositivos verificados são conectados aos tópicos para publicar dados.

Também usei a opção de configuração MQTT_KEEPALIVE para manter o cliente ativo quando nenhum dado está sendo enviado ou recebido para manter o dispositivo do cliente ativo no pool de dispositivos e impedir que seja verificado novamente depois de adicionado ao pool de dispositivos. no entanto, por motivos de segurança, reduzo o dispositivo para 2FA a cada 24 horas.

— tim3in
fonte

3

Como é garantido que apenas o cliente correto obtenha o token?

— Helmar

@Helmar usando a identificação do cliente exclusiva e o tópico separado para armazenar o token para cada cliente predefinido no registro do dispositivo. O cliente realmente se inscreve neste tópico. Ao republicar o token para verificação, ele adiciona seu ID aos dados do token, para que o verificador saiba qual cliente publicou esse token. O clientid pode ser protegido usando o Elemento seguro no lado do dispositivo após registrar o mesmo ID no servidor no banco de dados.

— tim3in

@ Helmar, gostaria de adicionar seu comentário a isso? Eu apreciaria as opiniões de todos na minha solução.

— tim3in

2

sim, mas o que é para me parar a subscrição de '#' para ver todas as respostas simbólicas

— hardillb

Os tópicos do @hardillb que têm respostas de token estão bloqueados como Goufalite mencionou. Portanto, apenas o dispositivo pré-autorizado pode ver. Na fase de registro, os dispositivos são vinculados a tópicos específicos e cada dispositivo designou tópicos separados para respostas ao token.

— tim3in