メインコンテンツまでスキップ

9. Securing CoAP (CoAPのセキュリティ保護)

このセクションでは、CoAPのDTLSバインディングを定義します。

プロビジョニングフェーズ中に、CoAPデバイスには、キーイングマテリアルやアクセス制御リストを含む、動作に必要なセキュリティ情報が提供されます。本仕様では、セクション9.1.3.2.1でRawPublicKeyモードの設定を定義します。プロビジョニングフェーズの終わりに、デバイスは4つのセキュリティモードのいずれかになり、以下に説明するそのモードの情報を持つことになります。NoSecおよびRawPublicKeyモードは、本仕様の実装必須モードです。

NoSec: プロトコルレベルのセキュリティはありません (DTLSは無効)。適切な場合は、下位層のセキュリティを提供する代替技術を使用すべきです (SHOULD)。IPsecの使用は [IPsec-CoAP] で議論されています。制約されたノードで使用される特定のリンク層は、リンク層セキュリティも提供し、適切な鍵管理の下で適切である場合があります。

PreSharedKey: DTLSが有効になっており、事前共有鍵 [RFC4279] のリストがあり、各鍵には、セクション9.1.3.1で説明されているように、通信に使用できるノードのリストが含まれています。極端な場合、このCoAPノードが通信する必要がある各ノードに対して1つの鍵がある場合があります (1:1ノード/鍵比率)。逆に、2つ以上のエンティティが特定の事前共有鍵を共有する場合、この鍵は、エンティティがそのグループのメンバーとして認証できるようにするだけであり、特定のピアとして認証できるようにするものではありません。

RawPublicKey: DTLSが有効になっており、デバイスには証明書なしの非対称鍵ペア (生の公開鍵) があり、セクション9.1.3.2で説明されているように、帯域外メカニズム [RFC7250] を使用して検証されます。デバイスには、公開鍵から計算されたIDと、通信できるノードのIDのリストもあります。

Certificate: DTLSが有効になっており、デバイスには、セクション9.1.3.3で説明されているように、サブジェクトにバインドし、共通のトラストルートによって署名されたX.509証明書 [RFC5280] を持つ非対称鍵ペアがあります。デバイスには、証明書の検証に使用できるルートトラストアンカーのリストもあります。

"NoSec" モードでは、システムはIP上の通常のUDPを介してパケットを送信するだけであり、"coap" スキームとCoAPデフォルトポートによって示されます。システムは、攻撃者がCoAPノードを使用してネットワークからパケットを送信または受信できないようにすることによってのみ保護されます。このアプローチの追加の複雑さについては、セクション11.5を参照してください。

他の3つのセキュリティモードはDTLSを使用して実現され、"coaps" スキームとDTLS保護されたCoAPデフォルトポートによって示されます。その結果、認証 (セキュリティモデルの制限内で) およびこの認証に基づいて通信パートナーを承認するために使用できるセキュリティアソシエーションが得られます。CoAP自体は、認証または承認のためのプロトコルプリミティブを提供しません。これが必要な場合は、通信セキュリティ (つまり、IPsecまたはDTLS) またはオブジェクトセキュリティ (ペイロード内) によって提供できます。特定の操作に承認を必要とするデバイスは、これら2つの形式のセキュリティのいずれかを必要とすることが期待されます。必然的に、仲介者が関与する場合、通信セキュリティは、その仲介者が信頼関係の一部である場合にのみ機能します。CoAPは、クライアントが仲介者に対して持っている可能性のあるさまざまなレベルの承認を、さらに先の仲介者またはオリジンサーバーに転送する方法を提供しません。したがって、最初の仲介者ですべての承認を実行する必要がある場合があります。

9.1. DTLS-Secured CoAP (DTLS保護されたCoAP)​

HTTPがTCP上のトランスポート層セキュリティ (TLS) を使用して保護されるのと同様に、CoAPはUDP上のデータグラムTLS (DTLS) [RFC6347] を使用して保護されます (図13を参照)。このセクションでは、CoAPのDTLSへのバインディングと、制約された環境に適した最小限の実装必須構成を定義します。バインディングは、ユニキャストCoAPへの一連のデルタによって定義されます。実際には、DTLSはUDPトランスポートの信頼性の低い性質に対処するための機能が追加されたTLSです。

                        +----------------------+
                        |    アプリケーション    |
                        +----------------------+
                        +----------------------+
                        | リクエスト/レスポンス |
                        |----------------------|  CoAP
                        |      メッセージ       |
                        +----------------------+
                        +----------------------+
                        |         DTLS         |
                        +----------------------+
                        +----------------------+
                        |          UDP         |
                        +----------------------+

            図 13: DTLS保護されたCoAPの抽象レイヤリング

一部の制約されたノード (フラッシュやRAMが限られている) やネットワーク (帯域幅が限られている、または高いスケーラビリティ要件がある)、および使用されている特定の暗号スイートによっては、DTLSのすべてのモードが適用できない場合があります。一部のDTLS暗号スイートは、セキュリティアソシエーションを設定するときに必要な初期ハンドシェイクのオーバーヘッドだけでなく、実装の大幅な複雑さを追加する可能性があります。初期ハンドシェイクが完了すると、DTLSは、初期化ベクトル/ナンス (たとえば、TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] の場合は8バイト)、整合性チェック値 (たとえば、TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] の場合は8バイト)、および暗号スイートに必要なパディングを含まない、データグラムごとに約13バイトの制限されたオーバーヘッドを追加します。特定のモードのDTLSの使用がCoAPベースのアプリケーションに適用可能かどうかは、適用可能な特定の暗号スイート、セッションの維持によってアプリケーションフローとの互換性があるかどうか、および制約されたノードと追加のネットワークオーバーヘッドに十分なリソースがあるかどうかを考慮して、慎重に検討する必要があります。(DTLSを使用する一部のモードについて、本仕様では実装必須の暗号スイートを識別しています。これは、これらの暗号スイートが実際に適切である場合に相互運用性を最大化するための実装要件です。アプリケーションの特定のセキュリティポリシーによって、使用できる暗号スイートの実際のセットが決まる場合があります。) DTLSはグループキーイング (マルチキャスト通信) には適用されません。ただし、将来のグループ鍵管理プロトコルのコンポーネントになる可能性があります。

9.1.1. Messaging Layer (メッセージング層)​

CoAPクライアントとして機能するエンドポイントは、DTLSクライアントとしても機能すべきです (SHOULD)。適切なポートでサーバーへのセッションを開始すべきです (SHOULD)。DTLSハンドシェイクが完了すると、クライアントは最初のCoAPリクエストを開始できます (MAY)。すべてのCoAPメッセージは、DTLS「アプリケーションデータ」として送信されなければなりません (MUST)。

AcknowledgementメッセージまたはResetメッセージをConfirmableメッセージに一致させるため、またはResetメッセージをNon-confirmableメッセージに一致させるために、次のルールが追加されます: DTLSセッションは同じでなければならず (MUST)、エポックは同じでなければなりません (MUST)。

同じDTLSセッションと同じエポック内で送信され、同じMessage IDを持つ場合、メッセージは同じです。

注: Confirmableメッセージが再送される場合、CoAP Message IDが同じままであっても、試行ごとに新しいDTLS sequence_numberが使用されます。したがって、受信者はセクション4.5で説明されているように重複排除を実行する必要があります。再送はエポックをまたいで実行してはなりません (MUST NOT)。

RawPublicKeyおよびCertificateモードのDTLS接続は、相互認証を使用して設定されるため、維持して、いずれかの方向の将来のメッセージ交換に再利用できます。デバイスは、リソースを回復する必要があるときにDTLS接続を閉じることができますが、通常は可能な限り長く接続を維持すべきです。CoAPメッセージ交換ごとにDTLS接続を閉じることは非常に非効率的です。

9.1.2. Request/Response Layer (リクエスト/レスポンス層)​

レスポンスをリクエストに一致させるために、次のルールが追加されます: DTLSセッションは同じでなければならず (MUST)、エポックは同じでなければなりません (MUST)。

これは、DTLSで保護されたリクエストへのレスポンスは、常に同じセキュリティセッションとエポックを使用してDTLSで保護されなければならないことを意味します (MUST)。DTLSリクエストにNoSecレスポンスを提供しようとする試みは、単にリクエストと一致しないため、拒否されなければなりません (MUST) (無関係なNoSecリクエストと一致する場合を除く)。

9.1.3. Endpoint Identity (エンドポイントID)​

デバイスは、[RFC6066] のセクション3で定義されているSNI HostNameフィールドで権限を示すために、Server Name Indication (SNI) をサポートすべきです (SHOULD)。これは、複数の権限の仮想サーバーとして機能するホストが新しいDTLS接続を受信したときに、DTLSセッションに使用するキーを知るために必要です。

9.1.3.1. Pre-Shared Keys (事前共有鍵)​

新しいノードへの接続を形成するとき、システムは到達しようとしているノードに基づいて適切なキーを選択し、DTLSのPSK (事前共有鍵) モードを使用してDTLSセッションを形成します。これらのモードの実装は、[RFC6655] で指定されている実装必須の暗号スイート TLS_PSK_WITH_AES_128_CCM_8 をサポートしなければなりません (MUST)。

試運転モデルによっては、アプリケーションは、PSK IDヒントの使用を有効にするために、IDヒントのアプリケーションプロファイルを定義する必要がある場合があります ([RFC4279] のセクション5.2で要求および詳細化されているように)。

[RFC4279] のセクション7のセキュリティに関する考慮事項が適用されます。特に、アプリケーションは、Perfect Forward Secrecy (PFS) が必要かどうかを慎重に検討し、適切な暗号スイートを選択すべきです ([RFC4279] のセクション7.1)。PSKのエントロピーは、ブルートフォース攻撃や (PSKがランダムに選択されず、人間によって選択される場合) 辞書攻撃を軽減するのに十分でなければなりません ([RFC4279] のセクション7.2)。クライアントIDの平文通信は、データを漏洩したり、プライバシーを侵害したりする可能性があります ([RFC4279] のセクション7.3)。

9.1.3.2. Raw Public Key Certificates (生の公開鍵証明書)​

このモードでは、デバイスには非対称鍵ペアがありますが、X.509証明書はありません (生の公開鍵と呼ばれます)。たとえば、非対称鍵ペアは製造元によって生成され、デバイスにインストールされます (セクション11.6も参照)。デバイスは、複数の生の公開鍵で構成される場合があります (MAY)。生の公開鍵のタイプと長さは、使用される暗号スイートによって異なります。RawPublicKeyモードの実装は、[RFC7251]、[RFC5246]、および [RFC4492] で指定されている実装必須の暗号スイート TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 をサポートしなければなりません (MUST)。使用されるキーはECDSA対応でなければなりません (MUST)。曲線 secp256r1 をサポートしなければなりません (MUST) [RFC4492]。この曲線はNIST P-256曲線と同等です。ハッシュアルゴリズムはSHA-256です。実装は、Supported Elliptic CurvesおよびSupported Point Formats Extensionsを使用しなければなりません (MUST) [RFC4492]。非圧縮ポイント形式をサポートしなければなりません (MUST)。[RFC6090] を実装方法として使用できます。この暗号スイートの実装に関連するいくつかのガイダンスは、[W3CXMLSEC] に記載されています。TLSで生の公開鍵を使用するメカニズムは [RFC7250] で指定されています。

実装上の注意: 具体的には、これは、図14にリストされている拡張機能が、少なくともリストされている値とともにDTLSハンドシェイクに存在することを意味します。

   Extension: elliptic_curves
    Type: elliptic_curves (0x000a)
    Length: 4
    Elliptic Curves Length: 2
    Elliptic curves (1 curve)
      Elliptic curve: secp256r1 (0x0017)

   Extension: ec_point_formats
    Type: ec_point_formats (0x000b)
    Length: 2
    EC point formats Length: 1
    Elliptic curves point formats (1)
      EC point format: uncompressed (0)

   Extension: signature_algorithms
    Type: signature_algorithms (0x000d)
    Length: 4
    Data (4 bytes): 00 02 04 03
      HashAlgorithm: sha256 (4)
      SignatureAlgorithm: ecdsa (3)

                  図 14: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8の
                         DTLS拡張機能
9.1.3.2.1. Provisioning (プロビジョニング)​

RawPublicKeyモードは、M2M展開で簡単にプロビジョニングできるように設計されています。各デバイスには、適切な非対称公開鍵ペアがインストールされていると想定されています。[RFC6920] のセクション2で説明されているように、識別子はエンドポイントによって公開鍵から計算されます。RawPublicKey IDのチェックをサポートするすべての実装は、少なくとも sha-256-120 モード (120ビットに切り捨てられたSHA-256) をサポートしなければなりません (MUST)。実装は、より長い長さの識別子もサポートすべきであり (SHOULD)、より短い長さをサポートしてもかまいません (MAY)。短い長さは攻撃に対するセキュリティが低くなるため、その使用は推奨されないことに注意してください。

識別子を検証するシステムに識別子を提供する方法に応じて、URI、バイナリ、および/または人間が発話可能な形式 [RFC6920] のサポートを実装する必要があります。すべての実装はバイナリモードをサポートすべきであり (SHOULD)、ユーザーインターフェイスを持つ実装は人間が発話可能な形式もサポートすべきです (SHOULD)。

プロビジョニング中に、各ノードの識別子は、たとえば、デバイスの外側にあるバーコードを読み取ったり、識別子のコンパイル済みリストを取得したりすることによって収集されます。これらの識別子は、対応するエンドポイント (たとえば、M2Mデータ収集サーバー) にインストールされます。識別子は、エンドポイントを詳細なデバイス情報に関連付けることと、アクセス制御を実行することの2つの目的で使用されます。(初期および進行中の) プロビジョニング中に、デバイスがDTLSセッションを開始できる識別子のアクセス制御リストもインストールおよび維持されるべきです (SHOULD)。

9.1.3.3. X.509 Certificates (X.509証明書)​

Certificateモードの実装は、[RFC7251]、[RFC5246]、および [RFC4492] で指定されている実装必須の暗号スイート TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 をサポートしなければなりません (MUST)。つまり、証明書には、名前付き曲線 secp256r1 [RFC5480] を持つ id-ecPublicKey のアルゴリズムを示す SubjectPublicKeyInfo が含まれます。公開鍵形式は非圧縮です [RFC5480]。ハッシュアルゴリズムはSHA-256です。含まれている場合、キー使用法拡張は digitalSignature を示します。証明書は、secp256r1を使用してECDSAで署名されなければならず (MUST)、署名はSHA-256を使用しなければなりません (MUST)。使用されるキーはECDSA対応でなければなりません (MUST)。曲線 secp256r1 をサポートしなければなりません (MUST) [RFC4492]。この曲線はNIST P-256曲線と同等です。ハッシュアルゴリズムはSHA-256です。実装は、Supported Elliptic CurvesおよびSupported Point Formats Extensionsを使用しなければなりません (MUST) [RFC4492]。非圧縮ポイント形式をサポートしなければなりません (MUST)。[RFC6090] を実装方法として使用できます。

証明書のサブジェクトは、EUI-64 [EUI64] など、デバイスの長期的な一意の識別子から構築されます。サブジェクトは、CoAP URIのHost部分として使用された完全修飾ドメイン名 (FQDN) に基づくこともできます。ただし、デバイスのIPアドレスは時間の経過とともに変化するため、通常はサブジェクトとして使用すべきではありません。システムで使用される検出プロセスは、特定のデバイスのIPアドレスと各デバイスのサブジェクトの間のマッピングを構築します。一部のデバイスは複数のサブジェクトを持つ可能性があり、複数の証明書が必要になります。

新しい接続が形成されると、リモートデバイスからの証明書を検証する必要があります。CoAPノードに絶対時間のソースがある場合、ノードは証明書の有効日が範囲内であることを確認すべきです (SHOULD)。証明書は、[RFC5280] のセクション6で指定されているアルゴリズムと同等の機能を使用して、セキュリティ要件に応じて適切に検証されなければなりません (MUST)。証明書にSubjectAltNameが含まれている場合、リクエストURIの権限は、SubjectAltNameセットのURIタイプのフィールドにあるCoAP URIの権限の少なくとも1つと一致しなければなりません (MUST)。証明書にSubjectAltNameがない場合、リクエストURIの権限は、[RFC3280] で定義されているマッチングルールを使用して、証明書にあるCommon Name (CN) と一致しなければなりません (MUST)。ただし、ワイルドカードを含む証明書は許可されません。

CoREによる証明書ステータスチェックのサポートには、さらなる研究が必要です。オンライン証明書ステータスプロトコル (OCSP) [RFC6960] のCoAPへのマッピングは現在定義されておらず、OCSPもすべての環境に簡単に適用できるとは限らないため、代替アプローチとして、TLS証明書ステータスリクエスト拡張 ([RFC6066] のセクション8。「OCSPステープリング」とも呼ばれます) または、利用可能な場合は複数の証明書ステータス拡張 ([RFC6961]) を使用することが考えられます。

システムに証明書に加えて共有鍵がある場合は、TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA [RFC5489] などの共有鍵を含む暗号スイートを使用すべきです (SHOULD)。

に最終更新