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

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 鍵のエントロピーと乱数値

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

実装は、公開鍵/秘密鍵ペア、MAC 鍵、およびパディング値を乱数で生成しなければならない。暗号鍵の生成に不十分な疑似乱数生成器（PRNG）を使用すると、セキュリティがほとんど、またはまったく得られない可能性がある。攻撃者にとっては、鍵を生成した PRNG 環境を再現し、結果として生じる少数の候補を探索するほうが、鍵空間全体を総当たり検索するよりはるかに容易な場合がある。高品質な乱数の生成は難しい。RFC 4086 [RFC4086] はこの分野で重要な指針を提供する。

10.2 鍵の保護

実装は署名者の秘密鍵を保護しなければならない。署名者の秘密鍵が侵害されると、攻撃者は署名者になりすますことができる。

実装は MAC 鍵を保護しなければならない。MAC 鍵が侵害されると、認証済みコンテンツが検出不能な形で変更される可能性がある。

10.3 鍵の発信元認証

公開鍵を取得するために使用する鍵管理方式は、鍵の発信元を認証しなければならない。そうでない場合、どの当事者がメッセージに署名したか不明である。

同様に、MAC 鍵を配布するために使用する鍵管理方式は、データ発信元認証を提供しなければならない。そうでない場合、コンテンツは完全性を保ったまま未知の発信元から届けられる。

10.4 暗号アジリティ

暗号アジリティに関するセキュリティ上の考慮事項については、[JWA] の 8.1 節を参照。

10.5 デジタル署名と MAC の違い

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

署名と MAC はともに完全性検査、すなわち完全性値の計算後にメッセージが変更されていないことの検証を提供する。しかし、MAC が発信元の識別を提供するのは特定の状況に限られる。通常、署名に使用する秘密鍵は単一のエンティティだけが保有すると仮定できるが、複製サーバの場合は分散エンティティである可能性もある。一方、MAC 鍵は、完全性の計算および検査に使用するすべてのエンティティが保有する必要がある。MAC の検証は、対称 MAC 鍵を知る当事者のいずれかがメッセージを生成したことを裏付けるにすぎない。したがって、MAC 鍵を知るエンティティが 2 つだけで、かつ受信者が自分ではメッセージを生成していないと認識している場合にのみ、発信元を判断できる。MAC の検証を第三者に対する発信元の証明として使用することはできない。

10.6 アルゴリズムの検証

一部のアルゴリズムのデジタル署名表現には、署名値の内部に使用したアルゴリズムの情報が含まれる。例えば、RSASSA-PKCS1-v1_5 [RFC3447] で作成された署名は使用したハッシュ関数を符号化し、多くのライブラリは署名の検証時に、署名内で指定されたハッシュアルゴリズムを実際に使用する。このようなライブラリを使用する場合、実装は実行するアルゴリズム検証の一部として、署名内に符号化されたアルゴリズム情報が「alg」ヘッダパラメータで指定されたものに対応することを保証しなければならない（MUST）。これを行わなければ、攻撃者は強いハッシュアルゴリズムを使用したと主張しつつ、実際には署名値に表現された弱いものを使用できる。

10.7 アルゴリズムの保護

JWS の一部の使用法では、アルゴリズム置換攻撃のリスクがある。攻撃者は、既存のデジタル署名値を別の署名アルゴリズムと組み合わせ、署名者が実際には署名していないものに署名したように見せかけることができる。この攻撃は、Cryptographic Message Syntax（CMS）[RFC6211] の文脈で詳しく議論されている。リスクは、以下がすべて真の場合に生じる。

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

アプリケーションがアルゴリズム置換攻撃を緩和する方法はいくつかある。

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

10.8 選択平文攻撃

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

10.9 タイミング攻撃

暗号アルゴリズムが、成功した操作と失敗した操作で異なる時間を要するように実装されている場合、攻撃者は時間差を利用して使用中の鍵に関する情報を得られる可能性がある。したがって、このような時間差は回避しなければならない。

10.10 リプレイ保護

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

10.11 SHA-1 証明書サムプリント

「x5t」（X.509 証明書 SHA-1 サムプリント）値の計算には、互換性上の理由から SHA-1 ハッシュが使用される。SHA-1 ハッシュ衝突を生成する有効な手段が開発され、攻撃者が特定システムにおける既知の証明書の使用を妨害しようとする場合、同じ SHA-1 ハッシュ値を持つ別の証明書を作成し、意図した被害者が使用する証明書ストアに追加することで実現できる。この攻撃が成功する前提条件は、攻撃者が被害者の証明書ストアへの書込みアクセスを持つことである。

代わりに、「x5t」の代わりに「x5t#S256」（X.509 証明書 SHA-256 サムプリント）ヘッダパラメータを使用できる。しかし、本書の執筆時点では SHA-256 証明書サムプリントをサポートする開発プラットフォームは知られていない。

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

厳格な JSON [RFC7159] 検証はセキュリティ要件である。不正な形式の JSON を受信した場合、生成者の意図を確実に識別することは不可能である。使用する JSON パーサが不正な JSON 構文を拒否しない場合、曖昧で、悪用される可能性のある状況が生じ得る。特に、RFC 7159 で定義される JSON テキスト構文に適合しない JSON 入力は、JSON パーサが完全に拒否しなければならない（MUST）。

「The JavaScript Object Notation (JSON) Data Interchange Format」[RFC7159] の 4 節は「The names within an object SHOULD be unique」と述べるが、本仕様は次のように規定する。

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 テキストオブジェクトの後に追加文字「ABCD」が続く。このような入力を含む JWS は、実装が無効とみなさなければならない（MUST）。

10.13 Unicode 比較に関するセキュリティ上の考慮事項

Header Parameter 名およびアルゴリズム名は Unicode 文字列である。セキュリティ上の理由から、これらの名前の表現は、RFC 7159 [RFC7159] の 8.3 節に従うエスケープ処理後に逐語的に比較しなければならない。例えば、JSON 文字列（「sig」、「\u0073ig」）は等しいと比較されなければならず、これらの文字列（「SIG」、「Sig」、「si\u0047」）はいずれも最初の組とも相互にも等しくないと比較されなければならない。

JSON 文字列には Unicode Basic Multilingual Plane の外にある文字を含めることができる。例えば、ト音記号（U+1D11E）は JSON 文字列では「\uD834\uDD1E」と表現できる。理想的には、JWS 実装は Basic Multilingual Plane 外の文字が正しく保存・比較されることを保証するべきである（SHOULD）。基礎となる JSON 実装の制約によりそれが不可能な場合は、そのような文字を含む入力を拒否しなければならない（MUST）。