一方向SSLはIoTデバイスを保護できますか？

インターネットアクセスの有無にかかわらず、ローカルネットワークに接続されたIoTデバイス（デフォルト設定、VPNなし、NATなし、DMZなし）を検討しています。私のデバイスは、認証と承認を備えたRPCメカニズムを提供するHTTPサーバーとして実行されます。それはmDNSでそれ自身を宣伝し、私は私のモバイルアプリまたは私のRaspberryPiを使用してそれに話します。

IoT開発の標準は相互（双方向）SSLを持つことです。 これは、一方向SSLではトラフィックを保護できないことを意味しますか？どうして？

ノート：

• 一方向SSLと双方向SSLの技術的な違いを理解していますが、IoTの生産で一方向（ほとんど）が考慮されない理由がわかりません。
• ローカルデバイスに相互SSLを設定するのは難しいことを理解しています。サーバーの公開鍵と証明書をクライアントと共有する必要があり、その逆も同様です。一方、一方向の方が簡単に見えます（ユーザーの操作は必要ありません）。
• Philips Hueのような一部の大量生産されたデバイスは、一方向SSL暗号化よりもローカルのhttpエンドポイントを開き、安全ではありません。なぜこの選択​​をするのでしょうか？
• この質問は意見に基づくものではないと思います。この場合はお詫び申し上げます。

SSL / TLSは、「サーバー」が既知の場所（固定ホスト名）にあり、それが提示する証明書のCNと一致できる場合に適切に機能します。

これは、RFC1918ブロックから発行されたIPアドレスを取得する傾向があり、DNSエントリがないため、ホームネットワーク上のデバイス（ほとんどのIoTデバイスなど）ではうまく機能しません。これは、証明書を発行できないことを意味します（そうすることはできますが、ほとんどのブラウザーは証明書を拒否します）。これが、Philips Hueなどのデバイスがデバイスの保護されていないHTTPエンドポイントを使用する理由です。基本的に、デバイスを保護するために保護されているネットワークへのアクセスに依存しています。

相互TLSが使用される場合、デバイスがいくつかの中央サービスに接続するためのものであり、クライアントは、中央サーバーを持つ所有者に代わって動作できることを認証するための独自の証明書/秘密鍵を持っています。

質問を明確にするために、サーバーの証明書/キーをすべてのクライアントに配布する必要はありません。証明書が発行されたCAの証明書だけが、証明書が信頼できることを証明するために必要です。

編集：

安全なローカルデバイス接続の良い例は、クライアントごとのキーの生成に使用されるデバイス上の事前共有キー（QRコード内）でCOAP over DTLSを使用するIKEAのTradfri照明です。これにより、新しいクライアントをセットアップするための物理的なアクセスが保証され、ローカルネットワーク上で処理中のデータが保護されます。

一般に、TLSはx.509よりはるかに優れていますが、多くの実装ではx.509のみに制限されています。

x.509は、安全な間接信頼のための手法です。「B」が「C」によって署名され、「C」が「A」によって信頼される証明書を持っている場合、「A」は「B」を信頼します。これは実際の生活でも機能します。信頼できる人が署名した手紙が提示された場合、あなたは知らない人を信頼します。多分あなたは落とし穴を見るでしょう：手紙が言うならば、あなたがあなたの車を与えないであろうコーヒーを一杯与えてください。したがって、証明書の追加情報は、信頼の範囲にも関連しています。そのため、サーバーは通常、証明書にDNS名またはIPアドレスを持っています。通常、さまざまな情報（「リビングルームランプ」など）を含めることができますが、多くの実装では、少なくともDNS / IPを使用/チェックするように事前設定されています。そして、それはすべて、誰かが信頼されていることを気にかけている場合にのみ機能します

それに時間を費やすことができる場合は、PSK暗号スイートも提供するかどうか、実装を確認してください。そうでない場合は、サーバー証明書の「検証チェック」を調整できます。しかし、それは良い解決策を見つけるために多くの読書を必要とします。そして、時々使用されるTLS実装はそれを提供しないだけです。