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

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

本仕様の実装者が考慮する必要があるセキュリティ上の考慮事項が多数ある。ここではいくつかの考慮事項が強調されているが、参考文献に記載されている文書に追加の考慮事項が記載されている場合がある。

実装は、すべての個人の秘密鍵情報を保護する必要がある。本文書のいくつかのケースでは、この問題に関して強調する必要がある。

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

楕円曲線 Diffie-Hellman (ECDH) と直接プラス KDF（キーラップなし）の使用は、秘密鍵の漏洩に直接つながることはない。KDF の一方向関数がそれを防ぐ。ただし、対処する必要がある別の問題がある。2 人の受信者がいる場合、CEK を 2 人の受信者間で共有する必要がある。したがって、2 番目の受信者は、弱い発信元証明に使用できる材料から導出された CEK を持っている。2 番目の受信者は、同じ CEK を使用してメッセージを作成し、それを最初の受信者に送信できる。最初の受信者は、Static-Static ECDH または直接プラス KDF のいずれについても、CEK が発信元証明に使用できるという仮定を行うが、それは誤ったエンティティからのものである。キーラップステップが追加された場合、発信元証明は暗示されず、これは問題にならない。

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

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

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

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