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

10. Security Considerations (セキュリティに関する考慮事項)

JWS/JWE/JWKエージェントは、あらゆる暗号化アプリケーションに関連するすべてのセキュリティ問題に対処しなければなりません。これらの問題には、ユーザーの非対称秘密鍵と対称鍵の保護、およびさまざまな攻撃に対する対策の採用が含まれます。

"XML Signature Syntax and Processing Version 2.0" [W3C.NOTE-xmldsig-core2-20130411] のすべてのセキュリティに関する考慮事項は、XML固有のものを除き、本仕様にも適用されます。同様に、"XML Signature Best Practices" [W3C.NOTE-xmldsig-bestpractices-20130411] で文書化されている多くのベストプラクティスも、XML固有のものを除き、本仕様に適用されます。

10.1 Key Entropy and Random Values (鍵のエントロピーとランダム値)​

鍵の強度は、それらを生成するために使用されるエントロピーの量にのみ依存します。すべての鍵は、少なくとも128ビットのエントロピーを使用して生成すべきであり (SHOULD)、アプリケーションのコンテキストに応じて、さらに多くのエントロピーが必要になる場合があります。

実装は、公開鍵/秘密鍵ペア、MAC鍵、およびパディング値をランダムに生成しなければなりません。不十分な擬似乱数生成器（PRNG）を使用して暗号鍵を生成すると、セキュリティがほとんどまたはまったくなくなる可能性があります。攻撃者は、鍵空間全体をブルートフォース検索するよりも、鍵を生成するPRNG環境を再現し、結果の小さな可能性セットを検索する方がはるかに簡単であることがわかるかもしれません。高品質の乱数を生成することは困難です。RFC 4086 [RFC4086] は、この点に関する重要なガイダンスを提供しています。

10.2 Key Protection (鍵の保護)​

実装は、署名者の秘密鍵を保護しなければなりません。署名者の秘密鍵が漏洩すると、攻撃者が署名者になりすますことができます。

実装は、MAC鍵を保護しなければなりません。MAC鍵の漏洩は、認証されたコンテンツの検出不可能な変更につながる可能性があります。

10.3 Key Origin Authentication (鍵の起源認証)​

公開鍵を取得するために使用される鍵管理技術は、鍵の起源を検証しなければなりません。そうでない場合、どの当事者がメッセージに署名したかを知ることができません。

同様に、MAC鍵を配布するために使用される鍵管理技術は、データ起源認証を提供しなければなりません。そうでない場合、コンテンツは未知のソースから完全に配信されます。

10.4 Cryptographic Agility (暗号アジリティ)​

暗号アジリティに関するセキュリティの考慮事項については、[JWA] のセクション8.1を参照してください。

10.5 Differences between Digital Signatures and MACs (デジタル署名とMACの違い)​

MACとデジタル署名はどちらも完全性チェックに使用できますが、それぞれが提供するセキュリティ属性にはいくつかの重要な違いがあります。プロトコルを設計し、プロトコルで使用するアルゴリズムを選択する際には、これらの違いを考慮する必要があります。

署名とMACはどちらも完全性チェックを提供します -- 完全性値が計算されてからメッセージが変更されていないことを検証します。ただし、MACは特定の状況下でのみ起源識別を提供します。署名に使用される秘密鍵は、通常、単一のエンティティ（分散サーバーの場合は分散エンティティの可能性がありますが）のみが保持していると想定できます。しかし、MAC鍵は、完全性計算とチェックにそれを使用するすべてのエンティティによって保持される必要があります。MACの検証は、対称MAC鍵を知っている当事者によってメッセージが生成されたという確認のみを提供します。これは、MAC鍵が2つのエンティティのみに知られており、受信者がそれを作成していないことを知っている場合にのみ、起源を確定できることを意味します。MAC検証は、第三者に起源を証明するために使用することはできません。

10.6 Algorithm Validation (アルゴリズムの検証)​

一部のアルゴリズムのデジタル署名表現には、署名値内に使用されたアルゴリズムに関する情報が含まれています。たとえば、RSASSA-PKCS1-v1_5 [RFC3447] を使用して生成された署名は、使用されたハッシュ関数をエンコードし、多くのライブラリは実際に署名を検証する際に署名内で指定されたハッシュアルゴリズムを使用します。このようなライブラリを使用する場合、実装は、実行されるアルゴリズム検証の一部として、署名にエンコードされたアルゴリズム情報が"alg" Header Parameterで指定されたアルゴリズム情報に対応することを確認しなければなりません (MUST)。これを行わないと、攻撃者は強力なハッシュアルゴリズムが使用されたと主張できますが、実際には署名値で表現された弱いハッシュアルゴリズムが使用されていた可能性があります。

10.7 Algorithm Protection (アルゴリズムの保護)​

JWSの特定の使用法では、攻撃者が異なる署名アルゴリズムを持つ既存のデジタル署名値を使用して、署名者が署名していないものに署名したように見せかけることができるアルゴリズム置換攻撃のリスクがあります。これらの攻撃は、Cryptographic Message Syntax (CMS) [RFC6211] のコンテキストで詳細に議論されています。以下のすべての条件が真である場合、このリスクが発生します:

  • 署名の検証者が複数のアルゴリズムをサポートしている。
  • 既存の署名が与えられた場合、攻撃者は、異なるアルゴリズムを使用して同じ署名値を生成する別のペイロードを見つけることができる。
  • 攻撃者が作成したペイロードは、アプリケーションコンテキストで有効である。

アプリケーションには、アルゴリズム置換攻撃を軽減するいくつかの方法があります:

  • 置換攻撃に対して脆弱でないデジタル署名アルゴリズムのみを使用する。攻撃者が受信者が受け入れるハッシュ関数の原像を計算できる場合にのみ、置換攻撃は実行可能です。すべてのJWA定義の署名アルゴリズムはSHA-2ハッシュを使用しており、本文書の執筆時点では、これらのハッシュに対する既知の原像攻撃はありません。
  • "alg" Header ParameterがJWS Protected Headerに含まれることを要求する。（これはJWS Compact Serializationを使用する場合は常にそうであり、これはCMS [RFC6211] で採用されているアプローチです。）
  • アプリケーションペイロードにアルゴリズムを含むフィールドを含め、検証中に"alg" Header Parameterと一致することを要求する。（これはPKIX [RFC5280] で採用されているアプローチです。）

10.8 Chosen Plaintext Attacks (選択平文攻撃)​

JWSの作成者は、第三者が制御しないエントロピーを追加せずに、第三者が任意のコンテンツをメッセージに挿入することを許可すべきではありません。

10.9 Timing Attacks (タイミング攻撃)​

暗号アルゴリズムが、成功した操作に必要な時間と失敗した操作に必要な時間が異なる方法で実装されている場合、攻撃者は時間差を使用して使用された鍵に関する情報を取得できる可能性があります。したがって、このようなタイミング差異は避けなければなりません。

10.10 Replay Protection (リプレイ攻撃の防止)​

本仕様の範囲内に直接はありませんが、JWS（またはJWE）オブジェクトを使用するアプリケーションは、JWS（またはJWE）メッセージに一意のメッセージ識別子を完全性保護されたコンテンツとして含め、受信者がメッセージが以前に受信または処理されていないことを検証することにより、リプレイ攻撃を阻止できることに注意してください。

10.11 SHA-1 Certificate Thumbprints (SHA-1証明書サムプリント)​

互換性の理由から、"x5t" (X.509 certificate SHA-1 thumbprint、X.509証明書SHA-1サムプリント) 値の計算にはSHA-1ハッシュが使用されます。SHA-1ハッシュ衝突を生成する実行可能な方法が開発され、攻撃者が特定のシステムで既知の証明書の使用を妨害したい場合、同じSHA-1ハッシュ値を持つ別の証明書を作成し、意図された被害者が使用する証明書ストアに追加することで実現できます。この攻撃が成功するための前提条件は、攻撃者が意図された被害者の証明書ストアへの書き込みアクセス権を持っていることです。

あるいは、"x5t"の代わりに"x5t#S256" (X.509 certificate SHA-256 thumbprint、X.509証明書SHA-256サムプリント) Header Parameterを使用できます。ただし、本文書の執筆時点では、SHA-256証明書サムプリントをサポートする既知の開発プラットフォームはありません。

10.12 JSON Security Considerations (JSONセキュリティに関する考慮事項)​

厳格なJSON [RFC7159] 検証はセキュリティ要件です。不正な形式のJSONを受信した場合、生産者の意図を確実に識別することはできません。使用されるJSONパーサーが不正な形式のJSON構文を拒否しない場合、曖昧で悪用される可能性のある状況が発生する可能性があります。特に、JSONパーサーは、RFC 7159で定義されているJSON-text構文に準拠していないJSON入力を完全に拒否しなければなりません (MUST)。

"The JavaScript Object Notation (JSON) Data Interchange Format" [RFC7159] のセクション4は、「オブジェクト内の名前は一意であるべきです (SHOULD)」と述べていますが、本仕様では次のように述べています:

JOSE HeaderのHeader Parameter名は一意でなければなりません (MUST)。JWSパーサーは、重複したHeader Parameter名を持つJWSを拒否するか、ECMAScript 5.1 [ECMAScript] のセクション15.12（"The JSON Object"）で規定されているように、字句的に最後の重複メンバー名のみを返すJSONパーサーを使用しなければなりません (MUST)。

したがって、本仕様では、生産者が [RFC7159] セクション4の"SHOULD"を"MUST"として扱い、消費者がそれを"MUST"として扱うか、ECMAScript 5.1で指定された方法で処理することを要求しています。使用されるJSONパーサーがメンバー名の一意性を強制しないか、重複するメンバー名に対して予測不可能な値を返す場合、曖昧で悪用される可能性のある状況が発生する可能性があります。

一部のJSONパーサーは、有効な入力の後に追加の重要な文字を含む入力を拒否しない場合があります。たとえば、入力 {"tag":"value"}ABCD には、有効なJSON-textオブジェクトと、その後の追加文字"ABCD"が含まれています。実装は、このような入力を含むJWSを無効として扱わなければなりません (MUST)。

10.13 Unicode Comparison Security Considerations (Unicode比較セキュリティに関する考慮事項)​

Header Parameter名とアルゴリズム名はUnicode文字列です。セキュリティ上の理由から、エスケープ処理（RFC 7159 [RFC7159] セクション8.3に従って）を実行した後、これらの名前の表現を文字通り比較しなければなりません。これは、たとえば、これらのJSON文字列を等しいものとして比較しなければならないことを意味します（"sig"、"\u0073ig"）が、これらはすべて最初のセットまたは互いに等しくないものとして比較しなければなりません（"SIG"、"Sig"、"si\u0047"）。

に最終更新