By Todd Ouska、wolfSSL
MQTT (Message Queuing Telemetry Transport protocol) は、IoT 開発者の間に広まりつつあります。当然でしょう。極めて軽量 (クライアント側インプリメンテーションはKb単位) で、簡単に利用できるAPIが提供され、またEPL (Eclipse Public License)のもとに無料で利用可能なのですから。もし、接続されるアプリケーションが、例えばリビングの温度を遠隔モニターするといったような簡単なもので比較的閉じているならば、これで十分かもしれません。
しかし、もしもう少し本格的なものだったら？例えば、複数のセンサーを組みわせる、建物の暖房、換気、空調 (HVAC) システムで、少しのインテリジェンス。そしてMQTTで在宅を自動検知、季節にあわせて自動補正。それに、アプリケーションに遠隔制御機能も加えて、愛犬が赤外線距離センサーを横切ったような場所についてはセンサーの出力を手動で修正できるように (スポットくん、ゴメン)。あるいは、さらに計測精度上げるために、開発作業後そうった商用システムを展開しセンサープラットフォームのファームウェアを更新する必要があるかも知れません。さて、今度はどのくらいだったら「十分」と言えるでしょう。答はアプリケーションによって違ってきます。
MQTTはパブリッシュ/サブスクライブ、つまり従来のネットワークモデルで「クライアント」になるようなノードは、特定のトピックに関係付けられたメッセージに対するパブリッシャ、サブスクライバのどちらとしても振舞うことができます。メッセージは、TCP (transmission control protocol) によって配送されますが、無差別にブロードキャストされるのではなくクライアントは、メッセージをパブリッシャからのメッセージを受け付け複数のサブスクライバに対して配信する中央のブローカを通じて送信します。このとき、ブローカは異なるQoS (サービス品質) で配信します。
しかしMQTTでは、 IoT エッジ・デバイスの資源的な制約に対して可能な限り軽量なプロトコルを維持するために、MQTT仕様ではさらなる認証レベルを要求するようなアプリケーションへの使用にはTLS（トランスポート層セキュリティ）の使用を推奨する以外、TCPに加えて特段の仕様はありません。結局、TCPのみに依存するMQTTコミュニケーションは暗号化されず、中間者攻撃にさらされることになります。
このことをもう少し説明するために、前述の二つの「複雑な」例にもどってみましょう。例えば、距離センサープラットフォームがMQTTブローカのトピック「home/occupancy.」にメッセージをパブリッシュします。MQTTプロトコルはクライアントの身元確認としてユーザ名とパスワードを使用しますが、なんらかの暗号化がされなければこれらはテキストで表示されてしまいます。したがって、盗聴者はクライアント・サブスクライバとして盗聴したり、通信内容を復号たり、さらにはクライアント・パブリッシャに成りすまして偽モノや修正メッセージを送信してしまうかも知れません。パーソナルホーム・アプリケーションとしてはこれは家には誰もいない窃盗候補のシグナルになってしまうかも知れませんし、商用版の配布シナリオでは遠隔ファームウェア更新のようなプロセスにおける深刻な課題を示唆しています。
TLSのトレードオフ
前述のように、MQTTプロトコルでは機密性のあるMQTTインプリメンテーションにはTLSの使用を推奨しており、この目的のためにネットワークポート(8883ポート)も確保されています。TLSはSSL (セキュアソケット層)の後継プロトコルで、 MQTTメッセージを送ることができる暗号化された通信チャネルを提供します。チャネルが確立される前にTLSは証明書（ないし鍵）をパブリッシャからブローカに対して渡すため、またブローカとサブスクライバの間でハンドシェークを使用します。成功すれば安全なチャネルが確立し、もし不成功ならば接続は中断されます。
簡単でしょ？いや、実はそれほど簡単ではないかも知れません。
TLS、SSL、あるいは他の暗号化を使う難点はオーバヘッドを大幅に増やしてしまう点です。本来、オーバーヘッドが少ないからMQTTを使用することにしたはずなのに。例えば、わたしたちwolfSSL社ではコンパイルサイズたったの3.6kバイトのMQTTクライアントライブラリ(wolfMQTT) をリリースしましたが、一回のTLSハンドシェークだけで個々のパケットの暗号化のオーバーヘッド全体に匹敵するほど消費してしまうのです。資源制約の厳しい組み込みデバイスにとって、特に小さなマイクロコントローラ・ベースのものにとって、この負担増加はCPU資源という点からも大きすぎます。
セッション再開のような技術はTLSの接続コストをある程度補償することができるし、ハードウェアによる高速化は暗号化のサイズ負担を軽減するための方法となります。そのほかにも、システム・コミュニケーションの安全確保の際には最適化された暗号化ライブラリの選択、またwolfMQTTの場合は、wolfSSL組み込み向けSSL/TLSライブラリを併用することでハードウェア暗号化とともに利用した場合には20-30kバイトのコンパイル・サイズとなります。
最終的にいつどのようにMQTTベースのIoTシステムでセキュリティを実現するかはアプリケーションに依存します。もし、トランスポート層暗号化への移行を決定するならば、オープンソースのMQTTライブラリをはじめいくつかの事例ではカバーをあけて中を覗きみることができるだけでなく、アプリケーションにおいてどのように暗号化が実現されるかドキュメントとサンプルも提供されています。もし商用でMQTTをご使用ということならば、セキュリティ認定を持ち、ロックインを避けるためにできるかぎり広範囲なオペレーティングシステムと組み込みチップセットのサポートを提供するベンダーとパートナシップを組むことも考慮する必要があります。
詳細は、TLSを使用したMQTTの安全な通信、Cで書かれた安全なファームウェア更新の例を参照してください。
wolfSSLとwolfMQTT、またはその他の製品（wolfSSL、wolfMQTT）の詳細については弊社問い合わせ窓口 (info@wolfssl.com, info@wolfssl.jp: 日本語)までお問い合わせください
Todd Ouska：wolfSSL. 共同創設者、CTO
原文: https://www.wolfssl.com/transport-level-security-tradeoffs-mqtt/
wolfSSLホーム：www.wolfssl.jp (English：www.wolfssl.com)