11. セキュリティに関する考慮事項

セキュリティに関する考慮事項

この仕様の実装者が考慮する必要があるセキュリティ上の考慮事項が多数あります。個々のアルゴリズムに固有のセキュリティ上の考慮事項は、アルゴリズムの説明の隣に配置されています。ここではいくつかの考慮事項が強調されていますが、参考文献に記載されているドキュメントに追加の考慮事項が記載されている場合があります。

実装は、すべての個人の秘密鍵データを保護する必要があります。このドキュメントのいくつかのケースは、この問題に関して強調する必要があります。

2つの異なるアルゴリズムに同じ鍵を使用すると、鍵に関する情報が漏洩する可能性があります。したがって、鍵を単一のアルゴリズムに制限することをお勧めします。
受信者アルゴリズムとして "direct" を使用し、2番目の受信者アルゴリズムと組み合わせると、直接鍵が2番目の受信者に公開されます。[RFC9052] のセクション 8.5 は、"direct" 受信者アルゴリズムを他のモードと組み合わせることを禁止しています。
このドキュメントのいくつかのアルゴリズムには、鍵に関する情報を漏洩することなく鍵を使用できる回数に制限があります。

ECDHおよび直接プラスKDF（キーラップなし）の使用は、秘密鍵の漏洩に直接つながることはありません。KDFの一方向関数がそれを防ぎます。ただし、対処する必要がある別の問題があります。2人の受信者がいる場合、CEKを2人の受信者間で共有する必要があります。したがって、2番目の受信者は、弱い送信元証明に使用できるデータから派生したCEKを持っています。2番目の受信者は、同じCEKを使用してメッセージを作成し、それを最初の受信者に送信できます。最初の受信者は、Static-Static ECDHまたは直接プラスKDFのいずれかについて、CEKが送信元証明に使用できると想定しますが、それは間違ったエンティティからのものです。キーラップステップが追加された場合、送信元証明は暗示されず、これは問題になりません。

以前にも言及しましたが、単一の鍵を複数のアルゴリズムに使用すると、場合によっては鍵に関する情報が漏洩し、攻撃者が整合性タグを偽造したり、暗号化されたコンテンツに関する情報を取得したりする機会を提供することが実証されていることを繰り返す価値があります。鍵を単一のアルゴリズムにバインドすることで、これらの問題を防ぐことができます。鍵の作成者と鍵の消費者は、異なるアルゴリズムごとに新しい鍵を作成するだけでなく、鍵データの配布にそのアルゴリズムの選択を含め、鍵構造内のアルゴリズムとメッセージ構造内のアルゴリズムの一致を厳密に強制することを強くお勧めします。アルゴリズムが正しいことを確認することに加えて、鍵の形式も確認する必要があります。"OKP" 鍵が期待される場所で "EC2" 鍵を使用しないでください。

送信に鍵を使用する前、または受信した情報に基づいて行動する前に、鍵に関する信頼決定を行う必要があります。データまたはアクションは、鍵に関連付けられたエンティティが表示する権利または要求する権利を持っているものですか？この信頼決定には多くの要因が関連しています。ここで強調されているのは次のとおりです。

鍵の所有者に関連付けられている権限は何ですか？
現在のコンテキストで暗号化アルゴリズムは許容されますか？
アルゴリズムや鮮度など、鍵に関連付けられた制限がチェックされており、それらは正しいですか？
アプリケーションの現在の状態を考慮して、要求は妥当なものですか？
メッセージの一部であるセキュリティに関する考慮事項（アプリケーションまたは "crit" ヘッダーパラメータで指定）は適用されていますか？

このドキュメントでは、ナンス値を使用する多数のアルゴリズムが提示されています。このドキュメントで定義されているすべてのナンスには、ナンスが鍵に対して一意の値であること、またはその他の条件に関する何らかのタイプの制限があります。これらすべてのケースにおいて、ナンスが一意であり、かつ予測不可能であるという既知の要件はありません。これらの状況下では、ナンスの作成にカウンターを使用するのが妥当です。ナンスのパターンが予測不可能であると同時に一意であることを望む場合は、その目的のために作成された鍵を使用し、カウンターを暗号化してナンス値を生成できます。

注目を集めている分野の1つは、メッセージの長さに基づく暗号化されたメッセージのトラフィック分析です。この仕様は、メッセージ構造の一部としてパディングを提供するための統一された方法を提供していません。観察者は、このドキュメントで定義されているすべてのコンテンツ暗号化アルゴリズムの長さに基づいて、2つの異なるメッセージ（たとえば、"YES" と "NO"）を区別できます。これは、そのような分析を防ぐか阻止するために、コンテンツのパディングをどのように行うかを文書化するのはアプリケーション次第であることを意味します。（たとえば、テキスト文字列は "YES" と "NO " として定義できます。）

[RFC9147] で行われた分析は、送信されたレコードの数に基づいています。これは、COSEを使用するときに送信されるメッセージの数によく対応するはずであるため、COSEメッセージがDTLSレコードとほぼ同じサイズであるという仮定の下で、その分析はここでも当てはまるはずです。制限はメッセージの数に基づいていることに注意する必要がありますが、QUICとDTLSは常にペアワイズベースのエンドポイントです。対照的に、[OSCORE-GROUPCOMM] はグループ通信シナリオでCOSEを使用します。このような状況では、暗号化されたすべてのメッセージを見る単一のエンティティは存在しない可能性があり、したがって、単一のエンティティが再キー操作をトリガーすることはできません。