Comment puis-je utiliser 2FA dans un réseau MQTT?

12

Comment puis-je utiliser 2FA (authentification à deux facteurs) lorsque je connecte un nouvel appareil au courtier, si cela est même possible?

Parce que cela semble plus facile, le deuxième facteur peut être une solution logicielle en premier, mais j'accueillerais volontiers des idées sur la façon d'introduire des jetons durs (RFID peut-être).

Il serait logique que les périphériques ne s'authentifient qu'à la première connexion et que le serveur se souvienne des "anciens" clients.

L'idée peut être inhabituelle ou inadaptée - si c'est une mauvaise idée, veuillez m'en donner les raisons.

security mqtt authentication

— Bence Kaulics
source

Pouvez-vous nous dire comment vous pensez qu'un appareil pourrait faire 2FA puisqu'il s'agit d' un seul appareil?

— Goufalite

@Goufalite Par exemple lorsque j'installe un nouvel appareil, je dois fournir une clé manuellement (par un tag RFID par exemple) qui sera utilisée lors de l'authentification. Quant au logiciel 2FA, je ne sais pas si une sorte de service pourrait être installé chez moi à partir duquel de nouveaux appareils pourraient demander des jetons logiciels, quelque chose comme un serveur de clé privée.

— Bence Kaulics

8

Vous avez besoin d'un proxy courtier ou d'un serveur web ...

Tout d'abord, vous avez absolument besoin d'un service d'authentification quelque part connecté à votre courtier pour effectuer le 2FA en utilisant des rubriques spécifiques ( /auth/RFID, ...). Cela permettrait alors au client de publier des informations (voir ci-dessous).

Le premier problème que je peux voir ici est que toute personne abonnée à ce sujet peut lire les informations de ce sujet, mais vous pouvez verrouiller les sujets !

Vous pouvez ensuite dire (forcer) à tous vos appareils de publier des informations /proxy/mytopic. Avec la fonction clientId de mqtt, le service d'authentification peut vérifier si les messages envoyés à partir de cette rubrique proviennent d'un appareil authentifié qui a utilisé 2FA auparavant, puis publier son propre message au nom de l'appareil /proxyout/mytopicavec l'ID de l'appareil dans la charge utile.

Le problème est maintenant de rechercher les périphériques qui peuvent recevoir des messages s'ils sont authentifiés, car, bien, MQTT est une question de publication de masse. Le service d'authentification doit disposer d'une liste de périphériques authentifiés et vérifier s'ils sont éligibles à la réception. Encore une fois, le chiffrement de la charge utile et le déchiffrement côté appareil ...

Je pense que ma solution est très exagérée par rapport aux capacités MQTT. Vous devez donc utiliser un socket ou un serveur web ...

— Goufalite
source

@ tim3in désolé pour la réponse tardive. Après tout, c'était une réponse donnée il y a 2,5 ans ... peut-être que les choses ont changé et ce n'était qu'une proposition d'architecture générale. Avez-vous fait un POC avec votre solution?

— Goufalite

Je l'ai planifié. Pourrez-vous l'examiner?

— tim3in

7

La prochaine spécification MQTT v5 ajoute la prise en charge du AUTHpaquet de contrôle, qui permet l'authentification par défi / réponse. Comme MQTT v5 n'est pas encore finalisé, le support peut encore changer, mais il semble raisonnable de supposer que AUTH restera sous une forme ou une autre et que 2FA pourrait être ajouté en l'utilisant.

Vous pouvez voir les versions actuelles de la spécification sur la page des documents du comité OASIS MQTT .

— ralight
source

5

Selon la spécification, le message de connexion peut éventuellement fournir un nom d'utilisateur et un mot de passe. Ceci est validé par rapport à une ACL enregistrée quelque part sur le courtier. C'est donc votre premier facteur d'authentification que vous pourriez exploiter. Le message CONNACK du courtier répondra si l'authentification a été effectuée.

Pour implémenter le deuxième facteur en cas d'authentification, la meilleure façon devrait être d'envoyer un message de connexion personnalisé avec l'autre facteur. Dans ce cas, le message CONNACK doit faire référence au succès ou à l'échec du deuxième facteur d'authentification. Par conséquent, le courtier et le client doivent implémenter des messages personnalisés au-delà de la spécification.

— cogito ergo sum
source

4

Pour atteindre 2FA dans le réseau MQTT, j'ai créé les services d'authentification suivants qui sont connectés à Broker.

Vérificateur d'ID
Générateur de jetons
Vérificateur de jetons

Lorsque le client MQTT se connecte au courtier via SSL / TLS, il publie d'abord son propre ID dans la rubrique device_id , le vérificateur d'ID vérifie qu'il s'agit du client authentique, puis le générateur de jeton est invoqué qui génère un jeton et publie le jeton sur la rubrique verrouillée device_token .

Le périphérique client obtient ce jeton et le publie ensuite dans une rubrique verify_token . Dès que la rubrique est publiée sur verify_token, le vérificateur de jetons compare les valeurs de la rubrique device_token et verify_token si elle correspond, ajoutez l'ID de l'appareil au pool d'appareils vérifié et autorisez l'appareil à publier des données. Cela améliore la sécurité car les seuls appareils vérifiés sont connectés aux rubriques pour publier des données.

J'ai également utilisé l'option de configuration MQTT_KEEPALIVE pour garder le client actif lorsqu'aucune donnée n'est envoyée ou reçue pour garder le périphérique client en vie dans le pool de périphériques et l'empêcher d'être vérifié à nouveau une fois qu'il est ajouté au pool de périphériques. Cependant, pour des raisons de sécurité, j'ai gelé l'appareil à 2FA toutes les 24 heures.

— tim3in
source

3

Comment est-il garanti que seul le bon client obtient le jeton?

— Helmar

@Helmar utilise l' identifiant client unique et une rubrique distincte pour stocker le jeton pour chaque client prédéfini lors de l'enregistrement de l'appareil. Le client souscrit réellement à ce sujet. Lorsqu'il republie le jeton pour vérification, il ajoute son identifiant avec les données de jeton afin que le vérificateur sache quel client a publié ce jeton. clientid peut être protégé en utilisant Secure Element côté périphérique après avoir enregistré le même identifiant sur le serveur dans la base de données.

— tim3in

@Helmar, aimeriez-vous ajouter votre commentaire? J'apprécierais les opinions de tout le monde sur ma solution.

— tim3 du

2

oui, mais qu'est-ce qui m'empêche de m'abonner à '#' pour voir toutes les réponses symboliques

— hardillb

Les sujets @hardillb qui ont des réponses symboliques sont verrouillés comme l'a mentionné Goufalite. Par conséquent, seul le périphérique pré-filtré peut voir. Lors de la phase d'enregistrement, les appareils sont liés à des sujets spécifiques et chaque appareil a attribué des sujets distincts pour les réponses de jeton.

— tim3 dans le