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

2. 署名アルゴリズム

  1. 署名アルゴリズム

[RFC9052] のセクション 8.1 には、署名アルゴリズムの一般的な説明が含まれています。 本書では、2つの署名アルゴリズムの署名アルゴリズム識別子を定義します。

2.1. ECDSA

楕円曲線デジタル署名アルゴリズム (ECDSA) [DSS] は、楕円曲線暗号 (ECC) を使用した署名アルゴリズムを定義します。 実装は、[RFC6979] で定義されているような ECDSA の決定論的バージョンを使用すべきです (SHOULD)。 決定論的署名アルゴリズムを使用すると、システムは "k" の値(メッセージごとのランダム値)が同じになるのを避けるために 乱数生成器に依存する必要がなくなります。 "k" の値の生成に偏りがあると攻撃される可能性があり、この値の衝突は鍵の漏洩につながります。 さらに、署名アルゴリズムの決定論的なテストを実行できるようになります。 決定論的 ECDSA を使用しても、秘密鍵を作成する際に優れた乱数生成を行う必要性が減るわけではありません。

ECDSA 署名アルゴリズムは、ハッシュ関数 (h) でパラメータ化されます。 ハッシュ関数の出力の長さが鍵のグループよりも長い場合、ハッシュ出力の左端のバイトが使用されます。

本書で定義されているアルゴリズムは、表1に記載されています。

          +=======+=======+=========+==================+
| Name | Value | Hash | Description |
+=======+=======+=========+==================+
| ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 |
+-------+-------+---------+------------------+
| ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 |
+-------+-------+---------+------------------+
| ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 |
+-------+-------+---------+------------------+

表 1: ECDSA アルゴリズム値

本書では、ECDSA は曲線 P-256、P-384、および P-521 でのみ機能するように定義されています。 本書では、曲線は "EC2"(2座標楕円曲線)鍵タイプを使用してエンコードする必要があります。 実装は、署名を作成および検証するときに、鍵タイプと曲線が正しいことを確認する必要があります。 将来の文書では、将来的に他の曲線や鍵タイプで機能するように定義される可能性があります。

相互運用性を促進するために、SHA-256 は曲線 P-256 でのみ使用し、SHA-384 は曲線 P-384 でのみ使用し、 SHA-512 は曲線 P-521 でのみ使用することが提案されています。これは、[RFC5480] のセクション 4 の推奨事項と一致しています。

署名アルゴリズムの結果は、整数のペア (R, S) になります。これらの整数は、署名プロセスに使用される鍵の長さと同じ長さになります。 署名は、整数を鍵サイズと同じ長さのバイト文字列に変換することによってエンコードされます。 長さは最も近いバイトに切り上げられ、正しい長さを得るためにゼロビットで左パディングされます。 次に、2つの整数が連結されて、結果の署名となるバイト文字列が形成されます。

[RFC8017] で定義されている関数を使用すると、署名は次のようになります:

Signature = I2OSP(R, n) | I2OSP(S, n)

ここで n = ceiling(key_length / 8)

このアルゴリズムに COSE 鍵を使用する場合、以下のチェックが行われます:

  • "kty" フィールドが存在しなければならず (MUST)、それは "EC2" でなければなりません (MUST)。

  • "alg" フィールドが存在する場合、それは使用されている ECDSA 署名アルゴリズムと一致しなければなりません (MUST)。

  • "key_ops" フィールドが存在する場合、ECDSA 署名を作成するときに "sign" を含めなければなりません (MUST)。

  • "key_ops" フィールドが存在する場合、ECDSA 署名を検証するときに "verify" を含めなければなりません (MUST)。

2.1.1. ECDSA のセキュリティに関する考慮事項

署名のセキュリティ強度は、鍵のビット長に関連するセキュリティ強度とハッシュ関数のセキュリティ強度の最小値以下です。

注:優れた乱数生成が存在する場合でも、決定論的署名手法を使用することは良い考えです。 そうすることで、2つの署名操作で同じ "k" の値を持つ可能性が減り、再現可能な署名値が可能になり、テストに役立ちます。 最近、鍵を抽出するためにデバイスに障害を発生させる攻撃がありました。 これは、ランダム性と決定論の両方を組み合わせることで対処できます [CFRG-DET-SIGS]。

ECDSA 署名アルゴリズムに対して理論的に実行可能な置換攻撃は2つあります。

  • 署名の検証に使用される曲線の変更:署名の検証に使用される曲線を変更すると、それぞれ異なる曲線の下で計算された、 同じ署名を持つ2つのメッセージが存在する可能性があります。新しい曲線の唯一の要件は、その次数が古いものと同じであり、 クライアントに受け入れられることです。例としては、曲線 secp256r1 (別名 P-256) の使用から secp256k1 の使用への変更があります。 (どちらも256ビット曲線です。)使用できる曲線のセット全体を制限することを除いて、 現在、このバージョンの攻撃に対処する方法はありません。

  • 署名の検証に使用されるハッシュ関数の変更:同じ長さの2つの異なるハッシュ関数があるか、ハッシュ関数を切り捨てることができる場合、 単一のハッシュ関数内ではなく、ハッシュ関数間の衝突を見つける可能性があります。 たとえば、SHA-512 を 256 ビットに切り捨てると、SHA-256 ビットのハッシュ値と衝突する可能性があります。 ハッシュアルゴリズムは署名アルゴリズム識別子の一部であるため、この攻撃は、保護されたヘッダーバケットに 署名アルゴリズム識別子を含めることで軽減されます。

2.2. エドワーズ曲線デジタル署名アルゴリズム (EdDSA)

[RFC8032] は、楕円曲線署名スキーム Edwards-curve Digital Signature Algorithm (EdDSA) について説明しています。 その文書では、署名アルゴリズムは edwards25519 および edwards448 曲線のパラメータを使用してインスタンス化されます。 また、この文書では EdDSA アルゴリズムの2つのバリアントについて説明しています:署名前にコンテンツにハッシュ関数が適用されない Pure EdDSA、 および署名前にコンテンツにハッシュ関数が適用され、そのハッシュ関数の結果が署名される HashEdDSA です。 EdDSA の場合、署名されるコンテンツ(メッセージまたはプリハッシュ値)は、署名アルゴリズム内で2回処理されます。 COSE で使用する場合は、Pure EdDSA バージョンのみが使用されます。これは、非常に大きなコンテンツが必要になることは予想されておらず、 メッセージ構造の配置に基づいて、署名を作成または検証するためにメッセージ全体をメモリに保持する必要があるためです。 したがって、ハッシュのブロック更新を行い、その後メッセージをメモリから削除できるようにする必要はないようです。 アプリケーションは、メッセージのコンテンツをハッシュ値として定義し、COSE オブジェクト(ハッシュ値付き)とコンテンツを 別々の項目として転送することで、同じ機能を提供できます。

本書で定義されているアルゴリズムは、表2に記載されています。単一の署名アルゴリズムが定義されており、複数の曲線に使用できます。

                  +=======+=======+=============+
| Name | Value | Description |
+=======+=======+=============+
| EdDSA | -8 | EdDSA |
+-------+-------+-------------+

表 2: EdDSA アルゴリズム値

[RFC8032] は、署名値をエンコードする方法について説明しています。

このアルゴリズムに COSE 鍵を使用する場合、以下のチェックが行われます:

  • "kty" フィールドが存在しなければならず (MUST)、それは "OKP" (Octet Key Pair) でなければなりません (MUST)。

  • "crv" フィールドが存在しなければならず (MUST)、それはこの署名アルゴリズムに定義された曲線でなければなりません (MUST)。

  • "alg" フィールドが存在する場合、それは "EdDSA" と一致しなければなりません (MUST)。

  • "key_ops" フィールドが存在する場合、EdDSA 署名を作成するときに "sign" を含めなければなりません (MUST)。

  • "key_ops" フィールドが存在する場合、EdDSA 署名を検証するときに "verify" を含めなければなりません (MUST)。

2.2.1. EdDSA のセキュリティに関する考慮事項

公開値は EdDSA と Elliptic Curve Diffie-Hellman (ECDH) で異なる方法で計算されます。 このため、一方の公開鍵を他方のアルゴリズムで使用すべきではありません。

バッチ署名検証が実行される場合、十分にシードされた暗号論的乱数生成器が必要です ([RFC8032] のセクション 8.2)。 署名および非バッチ署名検証は決定論的な操作であり、いかなる種類の乱数も必要ありません。