IoT & OT Security

IoT Protocols

IoT通信プロトコルセキュリティ

Category: IoT & OT Security / Updated: 2026-05-26

📖

Overview

IoTプロトコルとは、IoT(Internet of Things)デバイス間やデバイスとクラウド間の通信に使用される専用の通信プロトコル群です。代表的なプロトコルとして、軽量なPublish/Subscribe型メッセージングのMQTT、RESTfulな制約付きデバイス向けのCoAP、近距離無線通信のZigbee・Z-Wave・BLE(Bluetooth Low Energy)、広域低電力通信のLoRaWANなどがあります。これらは従来のHTTPやTCPと異なり、低消費電力・低帯域幅・制約付きハードウェアに最適化されています。

IoTプロトコルのセキュリティは、従来のIT通信プロトコルとは異なる課題を抱えています。多くのIoTデバイスはCPU性能やメモリが限られており、TLSのような暗号化処理の負荷が大きいため、セキュリティ機能が省略されたり、弱い設定で運用されることがあります。また、プロトコル自体の設計段階でセキュリティが十分に考慮されていないケースもあり、認証の欠如やメッセージの改ざんリスクなどが指摘されています。

IoTの普及に伴い、産業制御システム、スマートホーム、医療機器、自動車など、あらゆる分野でIoTプロトコルが利用されるようになりました。これらのプロトコルの脆弱性が悪用されると、デバイスの不正操作、データの盗聴・改ざん、大規模なボットネット構築など、深刻なセキュリティインシデントにつながります。各プロトコルの特性を理解し、適切なセキュリティ対策を実施することが不可欠です。

🔬

Details

MQTTのセキュリティ

MQTT(Message Queuing Telemetry Transport)は、Publish/Subscribe型の軽量メッセージングプロトコルで、IoTシステムで最も広く利用されています。ブローカーを介してPublisherとSubscriberがトピックベースでメッセージを交換します。MQTTの主なセキュリティリスクとして、デフォルトでは認証なしで接続可能な設定、平文通信(ポート1883)の使用、トピックのワイルドカード購読(#)による情報漏洩があります。

対策として、MQTT over TLS(ポート8883)による暗号化通信、ユーザー名/パスワードまたはクライアント証明書による認証、トピックレベルのアクセス制御リスト(ACL)の設定が必要です。MQTT v5ではEnhanced Authenticationが追加され、SCRAM等のチャレンジレスポンス型認証も利用可能になっています。

CoAPとDTLS

CoAP(Constrained Application Protocol)は、制約付きデバイス向けに設計されたUDPベースのRESTfulプロトコルです。HTTPに似たGET/POST/PUT/DELETEメソッドを持ちますが、UDPを使用するため軽量で低遅延です。CoAPのセキュリティはDTLS(Datagram Transport Layer Security)によって提供され、Pre-Shared Key(PSK)、Raw Public Key(RPK)、証明書ベースの3つの認証モードがあります。

CoAPのセキュリティ課題として、DTLSのハンドシェイクオーバーヘッドが制約付きデバイスには負担となること、マルチキャスト通信ではDTLSが使用できないこと、UDPベースのためリフレクション/アンプリフィケーション攻撃に悪用される可能性があることが挙げられます。OSCORE(Object Security for Constrained RESTful Environments)は、エンドツーエンドのセキュリティを提供するCoAP向けの新しいセキュリティ標準です。

Zigbee・Z-Waveのセキュリティ

Zigbeeは、IEEE 802.15.4をベースとしたメッシュネットワーク対応の短距離無線プロトコルで、スマートホームや産業用IoTで広く使われています。Zigbeeはネットワーク層にAES-128暗号化を実装していますが、ネットワーク鍵の配布プロセスに脆弱性があり、鍵の平文送信時に傍受される「鍵スニッフィング」攻撃が知られています。

Z-Waveは、スマートホーム向けの低電力メッシュネットワークプロトコルです。Z-Wave S2(Security 2)フレームワークでは、ECDHによる鍵交換とAES-128-CCMによる暗号化が導入されましたが、旧バージョンのS0セキュリティでは鍵交換時に既知の固定鍵を使用するという脆弱性があり、通信の復号が可能でした。

BLE(Bluetooth Low Energy)のセキュリティ

BLE(Bluetooth Low Energy)は、低消費電力の近距離無線通信技術で、ウェアラブルデバイス、医療機器、ビーコンなどで広く利用されています。BLEのセキュリティ機能には、ペアリング時の認証、AES-CCM暗号化、プライバシー保護のためのランダムアドレスがあります。

しかし、BLEには複数のセキュリティリスクが存在します。Just WorksペアリングモードではMITM攻撃に脆弱であり、BLESA(BLE Spoofing Attack)では再接続時のなりすましが可能です。また、GATTプロファイルの不適切な設定により、認証なしでセンサーデータの読み取りやデバイスの操作が可能になる場合があります。BLE 5.2以降ではセキュリティが強化されていますが、レガシーデバイスとの互換性維持が課題となっています。

LoRaWANのセキュリティ

LoRaWANは、低消費電力で数キロメートル以上の長距離通信が可能なLPWAN(Low Power Wide Area Network)プロトコルです。スマートメーター、環境モニタリング、資産追跡など、広域IoTアプリケーションで利用されています。LoRaWANは2層の暗号化(ネットワークセッション鍵とアプリケーションセッション鍵)を採用し、AES-128で通信を保護します。

LoRaWANのセキュリティ課題として、ABP(Activation by Personalization)モードではセッション鍵が静的であるため、鍵の漏洩リスクが高まること、OTAA(Over-the-Air Activation)モードでもJoinリクエストのリプレイ攻撃が可能なケースがあることが指摘されています。LoRaWAN 1.1では、Joinサーバーの分離やセッション鍵の導出方法の改善によりセキュリティが強化されています。

プロトコル固有の脆弱性と攻撃手法

IoTプロトコル全般に共通する脆弱性として、デフォルト認証情報の使用暗号化の欠如または弱い暗号化ファームウェアアップデートの未署名不十分なアクセス制御があります。攻撃者はこれらの脆弱性を組み合わせ、デバイスの乗っ取り、中間者攻撃、リプレイ攻撃、サービス拒否攻撃などを実行します。

特に注意すべきは、IoTプロトコルの多くが軽量性を優先して設計されているため、セキュリティ機能がオプションとなっていることです。プロトコル選定時には、通信要件だけでなくセキュリティ要件も考慮し、適切な暗号化・認証・アクセス制御を必ず有効化する必要があります。

🛡️

Security Measures

  • 01
    通信の暗号化を必ず有効化:MQTT over TLS(ポート8883)、CoAP over DTLS、BLEのSecure Connections Onlyモードなど、各プロトコルが提供する暗号化機能を必ず有効にしてください。平文通信は傍受・改ざんのリスクがあるため、本番環境では絶対に使用しないでください。
  • 02
    デバイス認証の強化:デフォルトのユーザー名・パスワードを必ず変更し、クライアント証明書やPSK(Pre-Shared Key)による相互認証を導入してください。MQTTブローカーでは匿名アクセスを無効化し、すべての接続に認証を要求する設定にしましょう。
  • 03
    トピック・リソースレベルのアクセス制御:MQTTではトピックベースのACLを設定し、各デバイスが必要最小限のトピックにのみアクセスできるようにしてください。ワイルドカード購読(#)は管理用途に限定し、一般デバイスには許可しないでください。
  • 04
    プロトコルバージョンの最新化:Zigbee 3.0、Z-Wave S2、BLE 5.2以降、LoRaWAN 1.1など、セキュリティが強化された最新バージョンのプロトコルを使用してください。レガシープロトコルのデバイスは隔離されたネットワークセグメントに配置しましょう。
  • 05
    ネットワークセグメンテーション:IoTデバイスのネットワークを企業LANやインターネットから分離し、IoTゲートウェイを介した通信のみを許可してください。プロトコル変換が行われるゲートウェイには、ファイアウォール機能とトラフィック監視を実装しましょう。
  • 06
    通信の監視と異常検知:IoTプロトコルの通信パターンを監視し、異常なメッセージ頻度、不正なトピックへのアクセス、未知のデバイスからの接続試行を検知する仕組みを構築してください。MQTT用のIDS/IPSやプロトコルアナライザーを活用した定期的なセキュリティ監査も重要です。
⚠️

Incidents

📋 MQTTブローカーの認証なし公開による大規模データ漏洩(2017年〜)

セキュリティ研究者の調査により、インターネット上に認証なしで公開されたMQTTブローカーが数万台存在することが発見されました。これらのブローカーには、スマートホームのセンサーデータ、GPS位置情報、医療機器のテレメトリデータ、産業制御システムのステータス情報など、機密性の高いデータが平文で流れていました。

攻撃者はワイルドカードトピック(#)を購読するだけで、すべてのメッセージを傍受できる状態でした。さらに、一部のブローカーではメッセージの発行も可能であり、デバイスの不正操作やデータの改ざんが可能な状態でした。この問題はMQTTのデフォルト設定が認証なしであることに起因しており、設定の見直しが急務とされました。

📋 Zigbee鍵スニッフィングによるスマートロック解錠(2015年)

2015年のBlack Hatカンファレンスで、研究者がZigbeeプロトコルの鍵配布メカニズムの脆弱性を実演しました。Zigbeeネットワークに新しいデバイスが参加する際、ネットワーク鍵が一時的に平文で送信されるタイミングがあり、この瞬間を捕捉することでネットワーク全体の暗号化を突破できることが示されました。

この攻撃手法を用いると、スマートロック、照明システム、温度制御システムなど、Zigbeeを使用するスマートホームデバイスを不正に操作することが可能でした。特にスマートロックの解錠は物理的なセキュリティに直結する深刻な脅威であり、Zigbee Allianceはセキュリティガイドラインの強化とZigbee 3.0でのInstall Code必須化で対応しました。

📋 BLE脆弱性「KNOB Attack」による暗号化の弱体化(2019年)

2019年に発見されたKNOB(Key Negotiation of Bluetooth)Attackは、Bluetooth/BLEの暗号化鍵ネゴシエーション時に、攻撃者が暗号化鍵のエントロピーを最小の1バイトに強制的に縮小できるという脆弱性でした。この攻撃により、暗号化されたBluetooth通信をブルートフォースで容易に復号できることが実証されました。

この脆弱性はBluetooth仕様自体の問題であり、Apple、Google、Microsoft、Qualcommなど、主要なBluetooth実装すべてに影響しました。医療機器やウェアラブルデバイスなど、BLEを使用する機密性の高いデバイスへの影響が懸念され、Bluetooth SIGは仕様の修正(最小暗号化鍵長の引き上げ)で対応しました。

🔗

Related Terms