MQTTネットワークで2FAを使用するにはどうすればよいですか？

可能であれば、新しいデバイスをブローカーに接続するときに2FA（2要素認証）を使用するにはどうすればよいですか？

簡単だと思われるため、2番目の要素は最初にソフトウェアソリューションにすることができますが、ハードトークン（RFIDの場合もある）を導入する方法についてのアイデアを歓迎します。

デバイスが最初の接続でのみ認証する必要があり、サーバーが「古い」クライアントを記憶している場合、それは理にかなっています。

アイデアは多分珍しいまたは不適切です-それが悪いアイデアである場合、私にその理由を教えてください。

ブローカープロキシまたはウェブサーバーが必要です...

まず、特定のトピックを使用して2FAを実行するには、ブローカーに接続された認証サービスが絶対に必要です（/auth/RFID、...）。その後、クライアントは情報を公開できます（以下を参照）。

私がここで見ることができる最初の問題は、このトピックにサブスクライブしている誰でもそのトピックの情報を読むことができるが、トピックをロックできることです！

その後、すべてのデバイスに情報を公開するように指示（強制）できます/proxy/mytopic。mqttのclientId機能を使用すると、認証サービスは、このトピックから送信されたメッセージが以前に2FAを使用した認証済みデバイスからのものかどうかを確認/proxyout/mytopicし、デバイスの代わりに独自のメッセージをペイロードのデバイスのIDで公開できます。

問題は、認証された場合にメッセージを受信できるデバイスを確認することです。これは、MQTTが大量公開に関するものだからです。認証サービスには、認証されたデバイスのリストがあり、それらが受信に適格であるかどうかを確認する必要があります。繰り返しますが、ペイロードの暗号化と復号化のデバイス側...

私のソリューションはMQTT機能よりも非常に過剰だと思います。したがって、ソケットまたはWebサーバーを使用する必要があります...

今後のMQTT v5仕様では、AUTH制御パケットのサポートが追加され、チャレンジ/レスポンス認証が可能になります。MQTT v5はまだ最終化されていないため、サポートは変更される可能性がありますが、AUTHが何らかの形で残り、それを使用して2FAを追加できると想定するのは合理的なようです。

OASIS MQTT委員会のドキュメントページで、仕様の現在のワーキングドラフトを確認できます。

仕様に従って、接続メッセージはオプションでユーザー名とパスワードを提供する場合があります。これは、ブローカーのどこかに保存されているACLに対して検証されます。したがって、それがあなたが利用できる認証の最初の要素です。認証が成功した場合、ブローカーからのCONNACKメッセージが応答します。

認証の場合、2番目の要素を実装するには、他の要素と共にカスタム接続メッセージを送信するのが最善の方法です。この場合のCONNACKメッセージは、認証の2番目の要素の成功または失敗を示す必要があります。したがって、ブローカーとクライアントは、仕様に加えてカスタムメッセージを実装する必要があります。

MQTTネットワークで2FAを実現するために、ブローカーに接続される認証用の次のサービスを作成しました。

1. ID検証
2. トークンジェネレーター
3. トークン検証

MQTTクライアントがSSL / TLSを介してブローカーに接続するとき、最初に自身のIDをdevice_idトピックに発行し、ID検証者がそれが本物のクライアントであることを確認してから、トークンジェネレーターが呼び出されてトークンを生成し、ロックされたトピックdevice_tokenにトークンを発行します。

クライアントデバイスはこのトークンを取得し、トピックverify_tokenにさらに公開します。トピックがverify_tokenで公開されるとすぐに、トークン検証はトピックdevice_tokenとverify_tokenの値を比較し、一致する場合、検証済みのデバイスプールにデバイスのIDを追加し、デバイスがデータを公開できるようにします。これにより、検証済みのデバイスのみがトピックに接続してデータを公開するため、セキュリティが向上します。

また、MQTT_KEEPALIVE構成オプションを使用して、データが送信または受信されていないときにクライアントをアクティブに保ち、デバイスプールでクライアントデバイスを有効に保ち、デバイスプールに追加された後に再度検証されないようにしました。ただし、セキュリティ上の理由から、24時間ごとにデバイスを2FAに凍結しています。