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

10. セキュリティメカニズム

このセクションでは、セキュアなRPLメッセージの生成と処理について説明します。RPLメッセージコードの上位ビットは、RPLメッセージがセキュアかどうかを識別します。基本的な制御メッセージ（DIS、DIO、DAO、DAO-ACK）のセキュアバージョンに加えて、RPLにはセキュリティが有効なネットワークでのみ関連するいくつかのメッセージがあります。

実装の複雑さとサイズはLLNにとって中心的な懸念事項であり、RPL実装に高度なセキュリティ規定を含めることは経済的または物理的に不可能かもしれません。さらに、多くの展開では、RPLでのセキュリティの使用を必要とせずに、リンク層または他のセキュリティメカニズムを利用してセキュリティ要件を満たすことができます。

したがって、このドキュメントで説明されているセキュリティ機能の実装はオプションです。特定の実装は、説明されているセキュリティ機能のサブセット（空集合を含む）をサポートしてもよく（MAY）、たとえば、完全性と機密性はサポートするが署名はサポートしないことができます。実装は、どのセキュリティメカニズムがサポートされているかを明確に指定すべきであり（SHOULD）、実装者がセキュリティ要件とネットワークでのセキュリティメカニズムの可用性を慎重に検討することが推奨されます（RECOMMENDED）。

10.1. セキュリティの概要​

RPLは3つのセキュリティモードをサポートします：

  • Unsecured（非セキュア）: このセキュリティモードでは、RPLは基本的なDIS、DIO、DAO、およびDAO-ACKメッセージを使用し、これらはセキュリティセクションを持ちません。ネットワークはリンク層セキュリティなどの他のセキュリティメカニズムを使用している可能性があるため、非セキュアモードはすべてのメッセージがいかなる保護もなく送信されることを意味するわけではありません。

  • Preinstalled（プリインストール）: このセキュリティモードでは、RPLはセキュアメッセージを使用します。RPLインスタンスに参加するには、ノードはプリインストールされた鍵を持っている必要があります。ノードはこれを使用して、メッセージの機密性、完全性、および真正性を提供します。ノードは、このプリインストールされた鍵を使用して、ホストまたはルーターとしてRPLネットワークに参加できます。

  • Authenticated（認証済み）: このセキュリティモードでは、RPLはセキュアメッセージを使用します。RPLインスタンスに参加するには、ノードはプリインストールされた鍵を持っている必要があります。ノードはこの鍵を使用して、メッセージの機密性、完全性、および真正性を提供します。このプリインストールされた鍵を使用して、ノードはホストとしてのみネットワークに参加できます。ルーターとしてネットワークに参加するには、ノードは鍵機関から2つ目の鍵を取得する必要があります。この鍵機関は、2つ目の鍵を提供する前に、要求者がルーターになることを許可されていることを認証できます。認証済みモードは対称アルゴリズムではサポートできません。この仕様の執筆時点では、RPLは対称アルゴリズムのみをサポートしています。認証済みモードは、将来の潜在的な暗号プリミティブのために含まれています。セクション10.3を参照してください。

RPLインスタンスが非セキュアモードを使用するかどうかは、セキュアなRPLメッセージを使用するかどうかによって通知されます。セキュアなネットワークがプリインストールモードを使用するか認証済みモードを使用するかは、DAG構成オプションの'A'ビットによって通知されます。

この仕様は、RPLセキュリティの暗号化基盤としてCCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- を指定します[RFC3610]。この仕様では、CCMはその基礎となる暗号アルゴリズムとしてAES-128を使用します。セキュリティセクションには、将来他のアルゴリズムを指定するために予約されたビットがあります。

すべてのセキュアなRPLメッセージには、MACまたは署名のいずれかがあります。オプションで、セキュアなRPLメッセージには機密性のための暗号化保護もあります。セキュアなRPLメッセージフォーマットは、統合された暗号化/認証スキーム（例：CCM）と、パケットを個別に暗号化および認証するスキームの両方をサポートします。

10.2. セキュアネットワークへの参加​

RPLセキュリティは、セキュアなネットワークに参加したいノードが、近隣ノードおよびRPLルートと通信するための共有鍵で事前に構成されていることを前提としています。セキュアなRPLネットワークに参加するには、ノードはセキュアなDIOをリッスンするか、セキュアなDISを送信してセキュアなDIOをトリガーします。セクション8のDIO/DISルールに加えて、セキュアなDIOおよびDISメッセージには次のルールがあります：

  1. 送信される場合、この最初のセキュアDISは、Key Identifier Modeフィールドを0 (00)に設定しなければならず（MUST）、Security Levelフィールドを1 (001)に設定しなければなりません（MUST）。使用される鍵は、事前に構成されたグループ鍵（Key Index 0x00）でなければなりません（MUST）。

  2. ノードがセキュアDISに応答してTrickleタイマーをリセットする場合（セクション8.3）、送信する次のDIOは、セキュアDISと同じセキュリティ構成を持つセキュアDIOでなければなりません（MUST）。ノードがDIOを送信する前に複数のセキュアDISメッセージを受信した場合、セキュアDIOは、応答している最後のDISと同じセキュリティ構成を持たなければなりません（MUST）。

  3. ノードがユニキャストセキュアDISに応答してDIOを送信する場合（セクション8.3）、DIOはセキュアDIOでなければなりません（MUST）。

上記のルールにより、ノードは事前に構成された共有鍵を使用してセキュアなRPLインスタンスに参加できます。ノードが事前に構成された共有鍵を使用してDODAGに参加すると、構成オプションの'A'ビットがその能力を決定します。構成オプションの'A'ビットがクリアされている場合、ノードはこのプリインストールされた共有鍵を使用して通常通りメッセージを交換できます：DIO、DAOなどを発行できます。

構成オプションの'A'ビットがセットされており、RPLインスタンスが認証済みモードで動作している場合：

  1. ノードは、Key Index 0x00で保護されたセキュアDIOでINFINITE_RANK以外のランクをアドバタイズしてはなりません（MUST NOT）。Key Index 0x00で保護されたDIOメッセージを処理する場合、処理ノードはアドバタイズされたランクをINFINITE_RANKと見なさなければなりません（MUST）。その他の値は、メッセージが破棄される結果となります。

  2. Key Index 0x00を使用するセキュアDAOは、ノードのアドレス以外のプレフィックスを持つRPLターゲットオプションを持ってはなりません（MUST NOT）。ノードが、RPLターゲットオプションがIPv6送信元アドレスと一致しないプリインストールされた共有鍵を使用するセキュアDAOメッセージを受信した場合、それ以上の処理なしにセキュアDAOメッセージを破棄しなければなりません（MUST）。

上記のルールは、'A'ビットがセットされているRPLインスタンスでは、Key Index 0x00を使用して、ノードはホストとしてRPLインスタンスに参加できるが、ルーターとしては参加できないことを意味します。ノードは、ルーターとして機能できるようにする鍵を取得するために、鍵機関と通信する必要があります。

10.3. 鍵のインストール​

認証済みモードでは、ルーターになろうとするノードが、ホストとしてネットワークに参加した後に新しい鍵を動的にインストールする必要があります。ホストとして参加した後、ノードは標準のIPメッセージングを使用して認証サーバーと通信し、認証サーバーは新しい鍵を提供できます。

このような鍵を取得するためのプロトコルは、この仕様の範囲外であり、将来の仕様で詳しく説明されます。その詳細は、RPLが認証済みモードで安全に動作するために必要です。

10.4. 一貫性チェック​

RPLノードは、リプレイ攻撃から保護し、カウンターを同期するために、一貫性チェック（Consistency Check: CC）メッセージを送信します。

  1. ノードが'R'ビットがクリアされたユニキャストCCメッセージを受信し、関連するDODAGのメンバーであるか、または参加プロセス中である場合、送信者にユニキャストCCメッセージで応答すべきです（SHOULD）。この応答は'R'ビットがセットされていなければならず（MUST）、受信したメッセージと同じCC nonce、RPLInstanceID、およびDODAGIDフィールドを持っていなければなりません（MUST）。

  2. ノードがマルチキャストCCメッセージを受信した場合、それ以上の処理なしにメッセージを破棄しなければなりません（MUST）。

一貫性チェックメッセージにより、ノードはチャレンジレスポンスを発行して、ノードの現在のカウンター値を検証できます。CC nonceはチャレンジャーによって生成されるため、メッセージをリプレイする攻撃者が正しい応答を生成できる可能性は低いです。一貫性チェック応答のカウンターにより、チャレンジャーは聞いたカウンター値を検証できます。

10.5. カウンター​

最も単純なケースでは、カウンター値は、ノードが各セキュアRPL送信で1以上インクリメントする符号なし整数です。カウンターは、次のプロパティを持つタイムスタンプを表してもよいです（MAY）：

  1. タイムスタンプは少なくとも6オクテット長でなければなりません（MUST）。

  2. タイムスタンプは1024 Hz（バイナリミリ秒）の粒度でなければなりません（MUST）。

  3. タイムスタンプの開始時間は、1970年1月1日午前12:00:00 UTCでなければなりません（MUST）。

  4. カウンターがタイムスタンプを表す場合、カウンター値は次のように計算された値でなければなりません（MUST）。Tをタイムスタンプ、Sを使用中の鍵の開始時間、Eを使用中の鍵の終了時間とします。SとEはどちらも上記のタイムスタンプと同じ3つのルールを使用して表されます。E > T < Sの場合、カウンターは無効であり、ノードはパケットを生成してはなりません（MUST NOT）。それ以外の場合、カウンター値はT-Sに等しくなります。

  5. カウンターがそのようなタイムスタンプを表す場合、ノードはセキュアRPLパケットのセキュリティセクションの'T'フラグをセットしてもよいです（MAY）。

  6. カウンターフィールドがそのようなタイムスタンプを提示しない場合、ノードは'T'フラグをセットしてはなりません（MUST NOT）。

  7. ノードが上記の要件を満たすローカルタイムスタンプを持っていない場合、'T'フラグを無視しなければなりません（MUST）。

ノードがそのようなタイムスタンプをサポートしており、'T'フラグがセットされたメッセージを受信した場合、セクション10.7.1で説明されている受信メッセージに対する時間的チェックを適用してもよいです（MAY）。ノードが'T'フラグがセットされていないメッセージを受信した場合、この時間的チェックを適用してはなりません（MUST NOT）。ノードのセキュリティポリシーには、アプリケーション上の理由から、'T'フラグがセットされていないすべてのメッセージを拒否することを含めてもよいです（MAY）。

'T'フラグが存在するのは、今日の多くのLLNが、セキュリティ、アプリケーション、およびその他の理由ですでにサブミリ秒の粒度でグローバルな時間同期を維持しているためです。RPLがこの既存の機能を活用できるようにすることで、遅延保護などのいくつかのセキュリティ問題に対する解決策が大幅に簡素化されます。

10.6. 送信パケットの送信​

送信RPL制御パケットと必要なセキュリティ保護が与えられた場合、このセクションでは、RPLが送信するセキュアパケットを生成する方法について説明します。また、必要な保護を提供するための暗号化操作の順序についても説明します。

セキュリティ保護の要件と送信RPLパケットに適用されるセキュリティレベルは、ノードのセキュリティポリシーデータベースによって決定されるものとします。送信パケット処理のためのこのセキュリティポリシーデータベースの構成は、実装固有です。

セキュアなRPLメッセージが送信される場合、RPLノードは送信RPLパケットのセキュリティセクション（T、Sec、KIM、およびLVL）を設定して、適用される保護レベルとセキュリティ設定を記述しなければなりません（MUST）（セクション6.1を参照）。RPLメッセージコードフィールドのセキュリティサブフィールドビットは、セキュアRPLメッセージを示すためにセットされなければなりません（MUST）。

送信パケットを保護するためにAES-128 CCM nonce（図31）を構築する際に使用されるカウンター値は、特定の宛先アドレスに最後に送信されたカウンターのインクリメントでなければなりません（MUST）。

セキュリティポリシーが遅延保護の適用を指定する場合、送信パケットを保護するためにCCM nonceを構築する際に使用されるタイムスタンプカウンターは、セクション10.5のルールに従ってインクリメントされなければなりません（MUST）。タイムスタンプカウンターが適用される場合（'T'フラグがセットされていることで示される）、ローカルに維持されているタイムスタンプカウンターは、送信されるセキュアRPLメッセージの一部として含まれなければなりません（MUST）。

送信パケットを保護するために使用される暗号アルゴリズムは、ノードのセキュリティポリシーデータベースによって指定されるものとし、送信メッセージ内のSecフィールドの値で示されなければなりません（MUST）。

送信パケットのセキュリティポリシーは、適用可能なKIMと、暗号パケット処理に使用されるセキュリティ鍵を指定する鍵識別子を決定するものとします。これには、署名鍵のオプションの使用が含まれます（セクション6.1を参照）。セキュリティポリシーはまた、送信パケットに適用される認証または認証と暗号化の形式での保護レベル（Level）、および署名の潜在的な使用を指定するアルゴリズム（Algorithm）も指定します。

暗号化が適用される場合、ノードは元のパケットペイロードを、パケットのセキュリティセクションで指定されたセキュリティ保護、鍵、およびCCM nonceを使用して暗号化されたペイロードに置き換えなければなりません（MUST）。

すべてのセキュアなRPLメッセージには完全性保護が含まれます。セキュリティアルゴリズム処理と併せて、ノードはMACまたは署名を導出し、これは送信されるセキュアRPLパケットの一部として含まれなければなりません（MUST）。

10.7. 受信パケットの受信​

このセクションでは、セキュアなRPLパケットの受信と処理について説明します。RPLメッセージコードフィールドのセキュリティサブフィールドビットがセットされている受信セキュアRPLパケットが与えられた場合、このセクションでは、RPLがパケットの非暗号化バリアントを生成し、その完全性を検証する方法について説明します。

受信者は、RPLセキュリティ制御フィールドを使用して、必要なパケットセキュリティ処理を決定します。メッセージタイプと発信者に対して記述されたセキュリティレベルが不明であるか、ローカルに維持されているセキュリティポリシーを満たさない場合、ノードはそれ以上の処理なしにパケットを破棄しなければならず（MUST）、管理アラートを上げてもよく（MAY）、応答としてメッセージを送信してはなりません（MUST NOT）。これらのポリシーには、セキュリティレベル、使用される鍵、送信元識別子、またはタイムスタンプベースのカウンターの欠如（'T'フラグで示される）を含めることができます。受信パケット処理のためのセキュリティポリシーデータベースの構成は、この仕様の範囲外です（たとえば、DIO構成を通じて、または帯域外の管理ルーター構成を通じて定義される場合があります）。

メッセージセキュリティレベル（LVL）が暗号化されたRPLメッセージを示す場合、ノードはKIMフィールドを通じて識別された鍵情報とCCM nonceをメッセージペイロード復号化処理への入力として使用します。CCM nonceは、メッセージカウンターフィールドおよびその他の受信およびローカルに維持されている情報から導出されるものとします（セクション10.9.1を参照）。平文メッセージの内容は、受信パケットのSecフィールドで指定された逆暗号化操作モードを呼び出すことによって取得されるものとします。

受信者は、CCM nonceと識別された鍵情報を使用して、受信パケットの完全性をチェックするものとします。受信したMACに対して完全性チェックが失敗した場合、ノードはパケットを破棄しなければなりません（MUST）。

受信メッセージが初期化された（ゼロ値）カウンター値を持ち、受信者がメッセージの発信者に対して現在維持されている受信カウンターを持っている場合、受信者はメッセージ送信元に一貫性チェック（Consistency Check）応答メッセージ（セクション6.6を参照）を送信してカウンターの再同期を開始しなければなりません（MUST）。一貫性チェック応答メッセージは、特定のノードアドレスに対して維持されている現在の完全な送信カウンターで保護されるものとします。その送信カウンターはメッセージのセキュリティセクションに含まれ、受信カウンターは一貫性チェックメッセージペイロードに含まれます。

指定されたセキュリティポリシーに基づいて、ノードは受信したRPLメッセージに対してリプレイ保護を適用してもよいです（MAY）。リプレイチェックは、受信パケットの認証の前に実行されるべきです（SHOULD）。受信パケットから取得されたカウンターは、指定された発信元ノードアドレスに対して維持されている受信カウンターのウォーターマークと比較されるものとします。受信メッセージカウンター値がゼロ以外であり、維持されている受信カウンターウォーターマーク未満である場合、潜在的なパケットリプレイが示され、ノードは受信パケットを破棄しなければなりません（MUST）。

受信パケットセキュリティポリシーチェックの一部として遅延保護が指定されている場合、タイムスタンプカウンターを使用して受信RPLメッセージの適時性を検証します。受信メッセージのタイムスタンプカウンター値が、発信者アドレスに対してローカルに維持されている送信時間カウンターよりも前のメッセージ送信時間を示す場合、リプレイ違反が示され、ノードは受信パケットを破棄しなければなりません（MUST）。受信タイムスタンプカウンター値が、現在時刻から許容パケット遅延を引いた時間よりも早いメッセージ送信時間を示す場合、遅延違反が示され、ノードは受信パケットを破棄しなければなりません（MUST）。

メッセージが復号化され（該当する場合）、完全性チェック、リプレイチェック、およびオプションで遅延保護チェックに合格すると、ノードはリプレイ比較のためのソースの予想カウンター値などのローカルセキュリティ情報を更新できます。

ノードは、セキュリティポリシーチェックまたはその他の適用された完全性、リプレイ、または遅延チェックに失敗したメッセージを受信したときに、セキュリティ情報を更新してはなりません（MUST NOT）。

10.7.1. タイムスタンプ鍵チェック​

メッセージの'T'フラグがセットされており、ノードがセクション10.5の要件に従うローカルタイムスタンプを持っている場合、ノードはメッセージの時間的一貫性をチェックしてもよいです（MAY）。ノードは、カウンター値を関連する鍵の開始時間に加算することによって、メッセージの送信時間を計算します。この送信時間が鍵の終了時間を過ぎている場合、ノードはそれ以上の処理なしにメッセージを破棄してもよいです（MAY）。送信時間が受信者のローカル時間と比較して過去または未来に離れすぎている場合、それ以上の処理なしにメッセージを破棄してもよいです（MAY）。

10.8. 完全性と機密性の範囲​

RPL ICMPv6メッセージの場合、パケット全体がRPLセキュリティの範囲内です。

MACと署名は、非セキュアなIPv6パケット全体に対して計算されます。MACと署名を計算する際、変更可能なIPv6フィールドは、[RFC4302]（IPsec認証ヘッダー）のセクション3.3.3.1のルールに従ってゼロで埋められていると見なされます。MACと署名の計算は、下位層が適用する可能性のある圧縮の前に実行されます。

RPL ICMPv6メッセージが暗号化される場合、暗号化はセキュリティセクションの後の最初のバイトから始まり、パケットの最後のバイトまで続きます。IPv6ヘッダー、ICMPv6ヘッダー、およびセキュリティセクションの終わりまでのRPLメッセージは、パケットを正しく復号化するために必要なため、暗号化されません。

たとえば、LVL=1、KIM=0、およびAlgorithm=0でメッセージを送信するノードは、CCMアルゴリズム[RFC3610]を使用して、属性ENC-MAC-32を持つパケットを作成します：パケットを暗号化し、32ビットのMACを追加します。ブロック暗号鍵はキーインデックスによって決定されます。CCM nonceはセクション10.9.1で説明されているように計算されます。認証および暗号化するメッセージは、セキュリティセクションの後の最初のバイトから始まり、パケットの最後のバイトで終わるRPLメッセージです。追加の認証データは、IPv6ヘッダーの先頭から始まり、RPLセキュリティセクションの最後のバイトで終わります。

10.9. 暗号化操作モード​

この仕様で説明されている暗号化操作モード（Algorithm = 0）は、CCMとブロック暗号AES-128に基づいています[RFC3610]。この操作モードは、既存の実装で広くサポートされています。CCMモードにはnonce（CCM nonce）が必要です。

10.9.1. CCM Nonce​

RPLノードは次のようにCCM nonceを構築します：

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Source Identifier                       +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+

                        図 31: CCM Nonce

  • Source Identifier（送信元識別子）: 8バイト。Source Identifierは、保護されたパケットの発信者の論理識別子に設定されます。

  • Counter（カウンター）: 4バイト。Counterは、RPL制御メッセージのセキュリティオプションの対応するフィールドの（非圧縮）値に設定されます。

  • Key Identifier Mode (KIM): 2ビット。KIMは、RPL制御メッセージのセキュリティオプションの対応するフィールドの値に設定されます。

  • Security Level (LVL): 3ビット。Security Levelは、RPL制御メッセージのセキュリティオプションの対応するフィールドの値に設定されます。

CCM nonceの未割り当てビットは予約されています。CCM nonceを構築するときは、それらをゼロに設定しなければなりません（MUST）。

CCM nonceのすべてのフィールドは、最上位オクテットおよび最上位ビットの順序で表されます。

10.9.2. 署名​

KIMが署名の使用（値3）を示す場合、ノードはパケットのデータペイロードに署名を追加します。セキュリティレベル（LVL）フィールドは、この署名の長さを記述します。セキュリティモード3のRPLの署名スキームは、[RFC3447]のセクション8.1で定義されているRSAアルゴリズム（RSASSA-PSS）のインスタンス化です。公開鍵として、ペア(n,e)を使用します。ここで、nは2048ビットまたは3072ビットのRSAモジュラスであり、e=2^{16}+1です。暗号化スキームとしてM=0のCCMモード[RFC3610]を使用します（ストリーム暗号として）。[RFC3610]はM=0のCCMモードを許可していませんが、RPLは署名と併用する場合、署名が十分なデータ認証を提供するため、M=0のCCMモードを明示的に許可することに注意してください。ここで、M=0のCCMモードは[RFC3610]のように指定されますが、セクション2.2のM'フィールドは0に設定されなければなりません（MUST）。[FIPS180]のセクション6.2で指定されているSHA-256ハッシュ関数を使用します。[RFC3447]のセクション8.1のメッセージエンコーディングルールを使用します。

'a'をカウンターの6バイト表現とメッセージヘッダーの連結とします。パケットペイロードは、パケットデータ'm'と署名's'の右連結です。この署名スキームは、メッセージ部分aとmの右連結で呼び出されますが、署名検証は、メッセージ部分aとmおよび署名sの右連結で呼び出されます。

この形式のRSA署名は、RPLネットワークに十分な保護を提供します。必要に応じて、より簡潔な署名を生成する代替の署名スキームは、この仕様の範囲外であり、将来の仕様の主題となる可能性があります。

2048ビットまたは3072ビットのいずれかの署名でRSA署名をサポートする実装は、2048ビットと3072ビットの両方のRSA署名の検証をサポートすべきです（SHOULD）。これは、RPL展開のアップグレードパスを提供することを考慮してのことです。

に最終更新