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

11. セキュリティ上の考慮事項

このセクションでは、プロトコルに対する起こり得る脅威を分析する。これは、本文書で説明されている CoAP のセキュリティ上の制限について、プロトコルおよびアプリケーションの開発者に知らせることを目的としている。CoAP は HTTP/1.1 の機能のサブセットを実現するものであるため、[RFC2616] の 15 節にあるセキュリティ上の考慮事項も CoAP に関連する。このセクションでは、CoAP に固有の制限の記述に焦点を当てる。

11.1. プロトコルの解析と URI の処理​

ネットワークに面するアプリケーションは、受信パケットの処理ロジックにおいて脆弱性を示すことがある。複雑なパーサーは、そのような脆弱性の有力な発生源としてよく知られており、例えばノードをリモートからクラッシュさせたり、さらにはその上で任意のコードをリモートから実行したりする能力につながる。CoAP は、パーサーの複雑さを軽減し、可能な限りエンコード可能な値の全範囲に意味を与え、同じ意味を持つ複数の表現の間の不必要な選択によってしばしば引き起こされる複雑さを積極的に削減することにより、そのような脆弱性を持ち込む機会を狭めようとしている。URI 処理の大部分はクライアントに移され、サーバーに脆弱性を持ち込む機会がさらに減少している。それでもなお、CoAP 実装における URI 処理コードは、残存する脆弱性の大きな発生源である可能性が高く、特別な注意を払って実装されるべきである。CoAP のアクセス制御実装は、URI からアクセス制御の決定を導出するコードと、URI によってアドレス指定されたリソースを最終的に提供するコードとの間の不一致を通じて脆弱性を持ち込まないように確保する必要がある。残る中で最も複雑なパーサーは CoRE Link Format のものになり得るが、これも実装の複雑さを軽減するという目標をもって設計されている [RFC6690]。(あわせて [RFC2616] の 15.2 節も参照のこと。)

11.2. プロキシングとキャッシング​

[RFC2616] の 15.7 節で述べられているように、プロキシはその本質上 man-in-the-middle であり、直接の CoAP メッセージ交換が持つかもしれない IPsec または DTLS による保護を破壊する。したがって、プロキシは CoAP メッセージ交換の機密性または完全性を破壊するための興味深い標的となる。[RFC2616] で指摘されているように、プロキシは可用性を破壊するための興味深い標的でもある。

プロキシがキャッシュも行う場合、request/response データの機密性と完全性に対する脅威は増幅される。CoAP は、機微なデータをよりよく保護するために HTTP/1.1 が提供するキャッシュ抑制用の Cache-Control オプションを一切定義していないことに注意されたい。

キャッシュ実装では、キャッシュエントリを生成したリクエストを行う際に適用されるはずのあらゆるアクセス制御上の考慮事項が、キャッシュ内の値にも適用される必要がある。これは、複数のセキュリティドメインを実装するクライアントや、複数のクライアントにサービスを提供する可能性のあるプロキシに関連する。また、caching proxy は、プロキシがそもそもリクエスト転送を実行するために要求するであろう transport-security 特性よりも低い特性しか持たないリクエストに対して、キャッシュ値を利用可能にしてはならない (MUST NOT)。

"coap" scheme とは異なり、"coaps" で識別されるリクエストへの応答は決して "public" ではなく、したがって、キャッシュがキャッシュエントリにつながったものと等価なアクセス制御の決定を行える場合を除き、共有キャッシュに再利用してはならない (MUST NOT)。ただし、そのメッセージが CoAP でデフォルトでキャッシュ可能である場合、private cache で再利用することはできる。

最後に、Separate Responses (piggybacked Responses ではなく) を複数の元のリクエスタにファンアウトするプロキシは、追加の増幅をもたらす可能性がある (11.3 節を参照)。

11.3. 増幅のリスク​

CoAP サーバーは一般に、リクエストパケットにレスポンスパケットで応答する。このレスポンスパケットは、リクエストパケットより著しく大きいことがある。攻撃者は CoAP ノードを利用して、小さな攻撃パケットをより大きな攻撃パケットに変える可能性があり、この手法は amplification として知られている。したがって、CoAP ノードがプロトコルの増幅特性を利用して denial-of-service (DoS) 攻撃に関与させられる危険性がある。すなわち、被害者を過負荷にしようとしているが生成できるトラフィック量が限られている攻撃者は、増幅を利用してより大量のトラフィックを生成できる。

これは特に、NoSec アクセスを有効にし、攻撃者からアクセス可能であり、潜在的な被害者 (例えば一般的なインターネット上) にアクセスできるノードにおいて問題となる。UDP プロトコルは、リクエストパケットに与えられた送信元アドレスを検証する方法を提供しないからである。攻撃者は、適切なリクエストパケットの送信元アドレスに被害者の IP アドレスを入れるだけで、被害者に向けたより大きなパケットを生成できる。

緩和要因として、多くの制約されたネットワークは少量のトラフィックしか生成できないため、CoAP ノードはこの攻撃にとって魅力が低くなる可能性がある。しかし、制約されたネットワークの限られた容量は、そのネットワーク自体を増幅攻撃の被害者となりやすいものにする。

したがって、リクエストが認証されていない場合、応答において大きな増幅率を提供すべきではない (SHOULD NOT)。CoAP サーバーは、CoAP の slicing/blocking modes [BLOCK] を使用し、大きなリソース表現を比較的小さな slices でのみ提供することにより、攻撃者に提供する増幅量を減らすことができる。例えば、1000-byte のリソースに対して、10-byte のリクエストは 1016-byte の応答ではなく、80-byte の応答 (64-byte の block を伴う) をもたらすことがあり、提供される増幅がかなり減少する。

CoAP はまた、リクエストにおけるマルチキャスト IP アドレスの使用をサポートしており、これは M2M にとって重要な要件である。Multicast CoAP リクエストは、特に制約されたネットワーク上で、偶発的または意図的な DoS 攻撃の発生源となり得る。本仕様は、応答が返されるタイミングを制限することにより、マルチキャストリクエストの増幅効果を低減しようとしている。悪意ある使用の可能性を制限するため、CoAP サーバーは、暗号学的に、または潜在的な送信元を制限する何らかのマルチキャスト境界によって、何らかの方法で認証できないマルチキャストリクエストを受け入れるべきではない (SHOULD NOT)。可能であれば、CoAP サーバーは、マルチキャストリクエストのサポートを、その機能が必要とされる特定のリソースに限定すべきである (SHOULD)。

POSIX-style API [IEEE1003.1] を提供する一部の汎用オペレーティングシステムでは、受信したパケットがマルチキャストアドレス宛てであったかどうかを調べることは容易ではない。多くの実装は自分がマルチキャストグループに参加しているかどうかを知っているが、これは FF0x::1 形式のマルチキャストアドレス宛てのパケットに対して問題を生じさせる。そのようなパケットはすべての IPv6 ノードに受信されるからである。実装は、この判断を行うために、利用可能であれば IPV6_RECVPKTINFO [RFC3542] のような現代的な API を利用すべきである (SHOULD)。

11.4. IP アドレススプーフィング攻撃​

UDP にはハンドシェイクが存在しないため、制約されたネットワークによって運ばれるメッセージを自由に読み書きできる不正なエンドポイント (すなわち、nodes/key ratio > 1:1 の NoSec または PreSharedKey の展開) は、例えば以下のことにより、単一のエンドポイント、エンドポイントのグループ、さらにはネットワーク全体を容易に攻撃できる:

  1. Confirmable message または Non-confirmable message への応答として Reset message をスプーフィングし、それによってエンドポイントを「聞こえない」状態にする。または

  2. CON message への応答として ACK をスプーフィングし、それによって CON message の送信者が再送するのを妨げ、実際の応答をかき消す可能性がある。または

  3. 偽造された payload/options を用いて応答全体をスプーフィングする (これには異なるレベルの影響がある。単一の応答の妨害から、サポート基盤に対するはるかに大胆な攻撃、例えばプロキシキャッシュの汚染や、resource directories における検証/検索インターフェイスの欺瞞まで及ぶ。より一般的には、グローバルなネットワーク状態を保存し、状態の設定または更新を扱うためのメッセージング機能として CoAP を使用するあらゆるコンポーネントが潜在的な標的である。)。または

  4. 標的ノードに対するマルチキャストリクエストをスプーフィングする。これは、ネットワークの輻輳/崩壊、被害者への DoS 攻撃、またはスリープ状態からの強制的な起床をもたらす可能性がある。または

  5. observe メッセージなどをスプーフィングする。

off-path 攻撃者による応答スプーフィングは、トランスポート層のセキュリティがなくても、リクエストにおいて非自明でランダム化された token を選択することにより検出および緩和できる (5.3.1 節)。[RFC4086] は、セキュリティのためのランダム性の要件について議論している。

原則として、他の種類のスプーフィングは、Confirmable message のセマンティクスが使用される場合にのみ CoAP によって検出できる。騙されたエンドポイントから予期しない Acknowledgement または Reset メッセージが届くからである。しかし、これは使用された Message ID の追跡を強いるものであり、それが常に可能とは限らず、さらに検出は通常、損害がすでに生じた後にしか得られない。この種の攻撃は、NoSec 以外の security modes を使用することによって防止できる。

送信元アドレスのスプーフィングの有無にかかわらず、クライアントは、サーバーに (できれば複雑な) リクエストを送信することによってサーバーを過負荷にしようと試みることができる。アドレスのスプーフィングは、この攻撃の追跡およびブロックをより困難にする。CON リクエストのコストは小さいため、この攻撃は容易に実行できる。この攻撃の下では、利用可能な総エネルギーが限られた制約されたノードが、計画よりもはるかに早くそのエネルギーを使い果たす可能性がある (battery depletion attack)。また、クライアントが Confirmable message を使用し、サーバーが (スプーフィングされた可能性のある) 応答しないアドレスに対して Confirmable separate response で応答する場合、サーバーは MAX_TRANSMIT_SPAN を使い果たすまで各応答のためにバッファと再送ロジックを割り当てなければならず、正当なトラフィックを処理するためのリソースを使い果たす可能性が高くなる。後者の問題は、4.7 節で議論されているように応答のレートを制限することによって多少緩和できる。攻撃者は、正当なクライアントのアドレスをスプーフィングすることもできる。これは、サーバーが separate responses を使用する場合、NSTART=1 のためにそのクライアントへの正当な応答をブロックさせる可能性がある。これらの攻撃はすべて、NoSec 以外の security mode を使用することによって防止でき、したがってセキュリティプロトコルに対する攻撃のみが残る。

11.5. クロスプロトコル攻撃​

CoAP エンドポイントを誘導して偽の送信元アドレスにパケットを送信させる能力は、増幅だけでなく、特定のアドレス (IP アドレスとポート) で UDP パケットを待ち受ける被害者に対する cross-protocol attacks にも利用できる。これは以下のようにして起こる:

  • 攻撃者は、指定されたアドレスを偽の送信元アドレスとして、CoAP エンドポイントにメッセージを送信する。

  • CoAP エンドポイントは、指定された送信元アドレスにメッセージで応答する。

  • 指定されたアドレスにいる被害者は、UDP パケットを受信し、それを別のプロトコルの規則に従って解釈する。

これは、攻撃者から被害者への直接の通信を防ぐ一方で、CoAP エンドポイント (他のプロトコルにおいて正当な役割も担っている可能性がある) から被害者への通信はたまたま許可しているファイアウォール規則を回避するために使用される可能性がある。

また、CoAP エンドポイントは、DNS のような別の UDP ベースのプロトコルのエンドポイントを通じて生成される cross-protocol attack の被害者となる可能性もある。どちらの場合も、エンドポイントのセキュリティ特性が IP アドレスの検査 (および偽の IP アドレスを使って外部から送信される直接攻撃をファイアウォールで遮断すること) に依存している場合、攻撃が可能である。一般に、UDP ベースのプロトコルは、コンテキストを欠いているため、cross-protocol attacks の比較的容易な標的となる。

最後に、他の手段によって伝送された CoAP URIs は、クライアントを誘導して他のプロトコルのエンドポイントにメッセージを送信させるために使用される可能性がある。

cross-protocol attacks に対する緩和策の 1 つは、受信したパケットの構文の厳格な検査と、構文における十分な差異の組み合わせである。例として、DNS サーバーを誘導して CoAP エンドポイントの検査を通過する DNS 応答を送信させることが困難であれば、役立つかもしれない。残念ながら、DNS 応答の最初の 2 バイトは攻撃者が選択できる ID であり、CoAP ヘッダーの重要な部分にマッピングされる。次の 2 バイトは CoAP の Message ID として解釈される (すなわち、どのような値でも受け入れられる)。DNS count words は、(存在しないが elective な) CoAP option 0 の複数のインスタンスとして、あるいは Token として解釈される可能性がある。最後に、エコーされたクエリは、CoAP エンドポイントに対して望ましい効果を達成するために攻撃者によって作り出される可能性があり、サーバーによって追加された応答 (もしあれば) は、単に追加された payload として解釈されるだけかもしれない。

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       | T, TKL, code
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   | Message ID
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    | (options 0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

図 15: DNS ヘッダー ([RFC1035]、4.1.1 節) 対 CoAP メッセージ

一般に、任意の 2 つのプロトコルの組について、一方のプロトコルが、攻撃者に他方のプロトコルのメッセージのように見える応答の生成を可能にするように設計されていることは十分あり得る。実行可能な攻撃が存在しないことを保証または証明することは、まだ完全には攻撃を可能にしないかもしれないが、より創造的な頭脳によってさらに発展させられる可能性のある例を生成することよりも、しばしばはるかに困難である。したがって、cross-protocol attacks は、エンドポイントが、パケットの送信元 IP アドレスを信頼するだけに基づいて攻撃者の望むアクションを認可しない場合にのみ、完全に緩和できる。逆に、CoAP のセキュリティを完全にファイアウォールに依存する NoSec 環境は、CoAP エンドポイントをファイアウォールで遮断する必要があるだけでなく、何らかの他の UDP ベースのプロトコルを使用して CoAP エンドポイントに UDP メッセージを送信するよう誘導される可能性のある他のすべてのエンドポイントも遮断する必要がある。

上記の考慮事項に加えて、cross-protocol attacks に関する DTLS のセキュリティ上の考慮事項が適用される。例えば、同じ DTLS security association ("connection") が複数のプロトコルのデータを運ぶために使用される場合、DTLS はもはやこれらのプロトコル間の cross-protocol attacks に対する保護を提供しない。

11.6. 制約されたノードに関する考慮事項​

制約されたノードの実装者は、しばしば良好なエントロピー源を持たないことに気づく [RFC4086]。そのような場合、そのノードは、鍵生成のような良好なエントロピーを必要とするプロセスに使用してはならない (MUST NOT)。代わりに、鍵は外部で生成し、製造時または commissioning 中にデバイスに追加すべきである。

制約されたノードは、処理能力が低いため、timing attacks に対して特に脆弱である。暗号プリミティブの実装には特別な注意を払わなければならない。

多数の制約されたノードが露出した環境に設置され、keying materials の復元を含む改ざんに対する耐性がほとんどないであろう。これらに割り当てられる credentials の範囲を定義する際には、これを考慮する必要がある。特に、ノードのグループに共有鍵を割り当てると、単一の制約されたノードがグループ全体を覆すための標的になり得る。