V4: 通信要件
Last updated
Last updated
デバイスはネットワーク通信を使用してエコシステム内でデータを交換し、コマンドを受信します。さまざまな関係者が通信の内容を信頼できるように、関係者を保護し、関係者の真正性、悪意のある変更に対する完全性、情報漏洩に対する機密性を確保する必要があります。実際には、これは最新の通信プロトコルを展開し、暗号化を含むそれらのセキュリティ機能を構成することを意味します。セキュアな TLS, Bluetooth, および Wi-Fi に関する業界ガイドラインは頻繁に変更されるため、通信セキュリティが常に効果的であることを確保するために、構成を定期的にレビューする必要があります。
送信されるデータの機密性に関係なく、常に TLS または同等の強力な暗号化と認証を使用します。
その他のセキュリティプラクティスにはピンニングと相互認証を備える証明書ベースの認証が含まれます。
最新の構成を使用して、通信に使用されるアルゴリズムと暗号の優先順序を有効にして設定します。
非推奨または既知のセキュアではないアルゴリズムと暗号を無効にします。
有線および無線通信プロトコルで利用可能な最も強力なセキュリティ設定を使用します。
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
詳細については、以下も参照してください。
OWASP Transport Layer Protection Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
NIST SP800-52r2 - Guidelines for the Selection, Configuration, and Use of TLS Implementations: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
IETF RFC 7525 - Recommendations for Secure Use of TLS and DTLS: https://tools.ietf.org/html/rfc7525
NIST SP800-121r2 - Guide to Bluetooth Security: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf
NIST SP800-97 - Establishing Wireless Robust Security Networks: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-97.pdf
HKCERT - ZigBee Security Study: https://www.hkcert.org/f/blog/264453/3a1c8eed-012c-4b59-9d9e-971001d66c77-DLFE-14602.pdf
A systematic review of security in LoRaWAN: https://arxiv.org/pdf/2105.00384.pdf
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
| # | 説明 | L1 | L2 | L3 |
|---|---|---|---|---|
4.1.1
IoT エコシステムの他のコンポーネント (センサー、ゲートウェイ、サポートクラウドなど) との通信が、データの機密性と完全性が保証され、通信プロトコルにリプレイ攻撃に対する保護が組み込まれている安全なチャネルを介して行われることを検証します。
✓
✓
✓
4.1.2
最新の TLS テストツールを使用して、強い暗号スイートのみが有効であり、最も強い暗号スイートが優先として設定されていることを検証します。
✓
✓
✓
4.1.3
TLS を使用する場合は、デバイスが X.509 証明書を暗号学的に検証することを検証します。
✓
✓
✓
4.1.4
可用性が重要なアプリケーションについて、妨害からの保護または検出が提供されていることを検証します。
✓
✓
4.1.6
デバイスの TLS 実装が独自の証明書ストアを使用し、エンドポイントの証明書または公開鍵にピン留めし、信頼できる CA により署名されている場合でも異なる証明書または鍵を持つエンドポイントへの接続を許可しないことを検証します。
✓
✓
4.1.7
チップ間通信が暗号化されていることを検証します。 (メインボードからドーターボードへの通信など)
✓
4.2.1
暗号化されていない通信が機密性の低いデータと命令に限定されていることを検証します。
✓
✓
✓
4.2.2
MQTT ブローカーが認可された IoT デバイスのみにトピックのサブスクライブとメッセージのパブリッシュを許可していることを検証します。
✓
✓
✓
4.2.3
MQTT トランザクションを認証するために、証明書がネイティブのユーザー名とパスワードよりも優先されることを検証します。
✓
✓
✓
4.3.1
必要な場合を除いて Bluetooth デバイスでペアリングと検出がブロックされていることを検証します。
✓
✓
✓
4.3.2
PIN または PassKey コードが簡単に推測できないことを検証します。 (たとえば 0000 や 1234 を使用してはいけません)
✓
✓
✓
4.3.3
シンプルモードの認証を用いる古いバージョンの Bluetooth を使用しているデバイスでは、ペアリングに PIN が必要であることを検証します。
✓
✓
✓
4.3.4
最新バージョンの Bluetooth の場合、"Just Works" を除くすべてのバージョンで Secure Simple Pairing (SSP) 認証に少なくとも 6 桁が必要であることを検証します。
✓
✓
✓
4.3.5
暗号化鍵がデバイスがサポートする最大サイズであり、このサイズが Bluetooth 接続を介して送信される情報を適切に保護するのに十分であるを検証します。
✓
✓
✓
4.3.6
利用可能な最も安全な Bluetooth ペアリング手法が使用されていることを検証します。通信デバイスの機能に応じて Out Of Band (OOB), Numeric Comparison, Passkey Entry ペアリング手法が使用されていることを検証します。
✓
✓
✓
4.3.7
デバイスでサポートされている最強の Bluetooth セキュリティモードとレベルが使用されていることを検証します。たとえば、Bluetooth 4.1 デバイスの場合、セキュリティモード 4、レベル 4 を使用して、認証されたペアリングと暗号化を提供する必要があります。
✓
✓
✓
4.4.1
デバイス機能の一部として必要な場合を除き、Wi-Fi 接続が無効であることを検証します。ネットワーク接続を必要としないデバイスや、Ethernet など他のタイプのネットワーク接続をサポートするデバイスでは、Wi-Fi インタフェースを無効にする必要があります。
✓
✓
✓
4.4.2
Wi-Fi 通信を保護するために WPA2 以降が使用されていることを検証します。
✓
✓
✓
4.4.3
WPA が使用されている場合は、AES 暗号化 (CCMP モード) で使用されていることを検証します。
✓
✓
✓
4.4.4
Wi-Fi Protected Setup (WPS) がデバイス間の Wi-Fi 接続を確立するために使用されていないことを検証します。
✓
✓
✓
4.5.1
新しいアプリケーションには Zigbee バージョン 3.0 が使用されていることを検証します。
✓
✓
✓
4.5.2
アプリケーションのセキュリティレベル要件と脅威モデルに応じて、適切な Zigbee セキュリティアーキテクチャ (集中型または分散型) が選択されていることを検証します。集中型アーキテクチャは一般的に高いセキュリティを提供しますが柔軟性を犠牲にします。
✓
✓
✓
4.5.3
選択したセキュリティアーキテクチャに応じて、最もセキュアな方法で Zigbee ネットワークに参加していることを検証します。たとえば、集中型アーキテクチャでは帯域外インストールコードを使用します。分散型では事前設定されたリンクキーを使用します。
✓
✓
✓
4.5.4
互換性の理由で明示的に必要とされており、関連するリスクが考慮されている場合を除き、事前設定されたデフォルトのグローバルリンクキー (つまり ZigbeeAlliance09) がネットワークへの参加に使用されていないことを検証します。
✓
✓
✓
4.5.5
ペアリングモードをアクティブ化するために、参加ノードと Zigbee Trust Center やルーターの両方でユーザー操作が必要であることを検証します。ペアリングが失敗した場合でも、デバイスは事前定義された短い時間の後に自動的にペアリングモードを終了する必要があります。
✓
✓
✓
4.5.6
ネットワークキーがランダムに生成されていることを検証します (たとえばネットワークの初期設定時など) 。
✓
✓
✓
4.5.7
ネットワークキーが定期的にローテーションされていることを検証します。
✓
4.5.8
ユーザーがペアリングされたデバイスの概要を取得して、それらが正当なものであることを妥当性確認できることを検証します (たとえば、接続されたデバイスの MAC アドレスを想定されるものと比較するなど) 。
✓
4.6.1
新しいアプリケーションには LoRaWAN バージョン 1.1 が使用されていることを検証します。
✓
✓
✓
4.6.2
LoRaWAN エコシステムのネットワークサーバー、ジョインサーバー、アプリケーションサーバーが業界のベストプラクティスやベンチマークに基づいて適切に堅牢化されていることを検証します。
✓
✓
✓
4.6.3
LoRaWAN ゲートウェイとネットワークサーバー、ジョインサーバー、アプリケーションサーバー間のすべての通信が、少なくともメッセージの完全性と真正性を保証するセキュアチャネル (たとえば TLS や IPsec) を介して行われることを検証します。
✓
✓
✓
4.6.4
ルートキーはエンドデバイスごとに一意であることを検証します。
✓
✓
✓
4.6.5
オフシーケンスフレームカウンタを使用して、リプレイ攻撃ができないことを検証します。たとえば、再起動後にエンドデバイスカウンタがリセットされた場合、古いメッセージがゲートウェイにリプレイできないことを検証します。
✓
✓