4. コンテンツ暗号化アルゴリズム

コンテンツ暗号化アルゴリズム

[RFC9052] のセクション 8.3 には、コンテンツ暗号化アルゴリズムの一般的な説明が含まれています。このドキュメントでは、3つのコンテンツ暗号化アルゴリズムの識別子と使用法を定義します。

4.1. AES-GCM

Galois/Counter Mode (GCM) モードは、[AES-GCM] で定義されている一般的な AEAD ブロック暗号モードです。GCM モードは、AES ブロック暗号化アルゴリズムと組み合わされて AEAD 暗号を定義します。

GCM モードは、認証タグのサイズとナンスのサイズによってパラメータ化されます。このドキュメントでは、ナンスのサイズを 96 ビットに固定します。認証タグのサイズは、少数の値のセットに制限されています。ただし、このドキュメントでは、認証タグのサイズは 128 ビットに固定されています。

このドキュメントで定義されているアルゴリズムのセットは表 5 にあります。

  +=========+=======+==========================================+
  | 名前    | 値    | 説明                                     |
  +=========+=======+==========================================+
  | A128GCM |   1   | AES-GCM モード w/ 128ビット鍵,           |
  |         |       | 128ビットタグ                            |
  +---------+-------+------------------------------------------+
  | A192GCM |   2   | AES-GCM モード w/ 192ビット鍵,           |
  |         |       | 128ビットタグ                            |
  +---------+-------+------------------------------------------+
  | A256GCM |   3   | AES-GCM モード w/ 256ビット鍵,           |
  |         |       | 128ビットタグ                            |
  +---------+-------+------------------------------------------+

              表 5: AES-GCM のアルゴリズム値

鍵は、鍵構造または受信者構造のいずれかから取得できます。暗号化または復号化している実装は、鍵の種類、鍵の長さ、およびアルゴリズムが、関与するエンティティにとって正しく適切であることを検証しなければなりません (MUST)。

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

"kty" フィールドが存在しなければならず (MUST)、"Symmetric" でなければなりません (MUST)。
"alg" フィールドが存在する場合、使用されている AES-GCM アルゴリズムと一致しなければなりません (MUST)。
"key_ops" フィールドが存在する場合、暗号化するときに "encrypt" または "wrap key" を含める必要があります (MUST)。
"key_ops" フィールドが存在する場合、復号化するときに "decrypt" または "unwrap key" を含める必要があります (MUST)。

4.1.1. AES-GCM のセキュリティに関する考慮事項

AES-GCM を使用する場合、以下の制限を強制しなければなりません (MUST)。

暗号化されるすべてのメッセージについて、鍵とナンスのペアは一意でなければなりません (MUST)。
単一の鍵で暗号化されるメッセージの総数は 2^32 を超えてはなりません (MUST NOT) [SP800-38D]。明示的なチェックは、この制限を超える可能性があると予想される環境でのみ必要です。
[RFC8446] には、その環境での AES-CGM の使用に関する分析が含まれています。その推奨事項に基づき、暗号化されるメッセージの数を 2^24.5 に制限すべきです。
[ROBUST] のより最近の分析は、鍵のロールオーバーをいつ行うかを決定する一環として、復号化の失敗回数を考慮する必要があることを示しています。DTLS ([RFC9147] のセクション 4.5.3) の推奨事項に従い、失敗したメッセージ復号化の回数は 2^36 に制限されるべきです。

より小さなタグ値のサポートが検討されました。制約のあるコミュニティは 64 ビット範囲のタグサイズを望むでしょう。そのような使用は、最大メッセージサイズ（通常は問題になりません）と鍵を使用できる回数の両方を劇的に変更します。Counter with CBC-MAC (CCM) が制約のある環境の通常のモードであることを考えると、制限されたモードはサポートされません。

4.2. AES-CCM

CCM は、[RFC3610] で定義されている一般的な認証暗号化ブロック暗号モードです。CCM モードは、AES ブロック暗号化アルゴリズムと組み合わされて、制約のあるデバイスで一般的に使用される AEAD 暗号を定義します。

CCM モードには2つのパラメータの選択肢があります。最初の選択肢は M、認証フィールドのサイズです。M の値の選択には、メッセージの増加（タグによる）と、攻撃者が検出されずにメッセージを変更できる確率との間のトレードオフが伴います。2番目の選択肢は L、長さフィールドのサイズです。この値は、最大メッセージサイズとナンスのサイズの間のトレードオフを必要とします。

残念ながら、CCM の仕様では L と M をビット数ではなくバイト数として指定しています。これにより、AES-CCM-8 が認証サイズが 8 ビットではなく 64 ビットである CCM モードのバージョンを指すために頻繁に使用されるという誤解が生じる可能性があります。ほとんどの暗号化アルゴリズムの仕様では、これらの値は従来、バイト数ではなくビット数として指定されてきました。このドキュメントでは、提示されているさまざまなアルゴリズムを比較しやすくするために、ビット数を使用する慣習に従います。

このドキュメントでは、L と M の値にわたるアルゴリズムの行列を定義します。制約のあるデバイスは通常、短いメッセージを使用し、受信者固有の暗号化操作を行うことを避けたい状況で動作しています。これは、より小さな L と M の値を支持します。制約の少ないデバイスは、より大きなメッセージを使用できるようにしたいと考え、操作ごとに新しい鍵を生成することをいとわないでしょう。これは、より大きな L と M の値を支持します。

以下の値が L に使用されます。

16 ビット (2): これにより、メッセージの長さは 2^16 バイト (64 KiB) に制限されます。これは、制約のある世界のメッセージには十分な長さです。ナンスの長さは 13 バイトで、繰り返すことなく 2^104 個の可能なナンス値を許容します。

64 ビット (8): これにより、メッセージの長さは 2^64 バイトに制限されます。ナンスの長さは 7 バイトで、繰り返すことなく 2^56 個の可能なナンス値を許容します。

以下の値が M に使用されます。

64 ビット (8): これにより、64 ビットの認証タグが生成されます。これは、変更されたメッセージが認証される確率が 2^64 分の1であることを意味します。

128 ビット (16): これにより、128 ビットの認証タグが生成されます。これは、変更されたメッセージが認証される確率が 2^128 分の1であることを意味します。

+====================+=======+====+=====+========+===============+
| 名前               | 値    | L  | M   | 鍵の   | 説明          |
|                    |       |    |     | 長さ   |               |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128  |   10  | 16 | 64  |  128   | AES-CCM モード|
|                    |       |    |     |        | 128ビット鍵,  |
|                    |       |    |     |        | 64ビットタグ, |
|                    |       |    |     |        | 13バイトナンス|
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256  |   11  | 16 | 64  |  256   | AES-CCM モード|
|                    |       |    |     |        | 256ビット鍵,  |
|                    |       |    |     |        | 64ビットタグ, |
|                    |       |    |     |        | 13バイトナンス|
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128  |   12  | 64 | 64  |  128   | AES-CCM モード|
|                    |       |    |     |        | 128ビット鍵,  |
|                    |       |    |     |        | 64ビットタグ, |
|                    |       |    |     |        | 7バイトナンス |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256  |   13  | 64 | 64  |  256   | AES-CCM モード|
|                    |       |    |     |        | 256ビット鍵,  |
|                    |       |    |     |        | 64ビットタグ, |
|                    |       |    |     |        | 7バイトナンス |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 |   30  | 16 | 128 |  128   | AES-CCM モード|
|                    |       |    |     |        | 128ビット鍵,  |
|                    |       |    |     |        | 128ビットタグ,|
|                    |       |    |     |        | 13バイトナンス|
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 |   31  | 16 | 128 |  256   | AES-CCM モード|
|                    |       |    |     |        | 256ビット鍵,  |
|                    |       |    |     |        | 128ビットタグ,|
|                    |       |    |     |        | 13バイトナンス|
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 |   32  | 64 | 128 |  128   | AES-CCM モード|
|                    |       |    |     |        | 128ビット鍵,  |
|                    |       |    |     |        | 128ビットタグ,|
|                    |       |    |     |        | 7バイトナンス |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 |   33  | 64 | 128 |  256   | AES-CCM モード|
|                    |       |    |     |        | 256ビット鍵,  |
|                    |       |    |     |        | 128ビットタグ,|
|                    |       |    |     |        | 7バイトナンス |
+--------------------+-------+----+-----+--------+---------------+

              表 6: AES-CCM のアルゴリズム値

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

"kty" フィールドが存在しなければならず (MUST)、"Symmetric" でなければなりません (MUST)。
"alg" フィールドが存在する場合、使用されている AES-CCM アルゴリズムと一致しなければなりません (MUST)。
"key_ops" フィールドが存在する場合、暗号化するときに "encrypt" または "wrap key" を含める必要があります (MUST)。
"key_ops" フィールドが存在する場合、復号化するときに "decrypt" または "unwrap key" を含める必要があります (MUST)。

4.2.1. AES-CCM のセキュリティに関する考慮事項

AES-CCM を使用する場合、以下の制限を強制しなければなりません (MUST)。

暗号化されるすべてのメッセージについて、鍵とナンスのペアは一意でなければなりません (MUST)。L の値が一意のナンスの数に影響することに注意してください。
AES ブロック暗号が使用される総回数は、2^61 回の操作を超えてはなりません (MUST NOT)。この制限は、MAC 値の計算とストリーム暗号化操作の実行で使用されるブロック暗号の回数の合計です。明示的なチェックは、この制限を超える可能性があると予想される環境でのみ必要です。
[RFC9147] には、その環境での AES-CCM の使用に関する分析が含まれています。その推奨事項に基づき、暗号化されるメッセージの数を 2^23 に制限すべきです。
正常に復号化されたメッセージの数に加えて、失敗した復号化の回数も追跡する必要があります。DTLS ([RFC9147] のセクション 4.5.3) の推奨事項に従い、失敗したメッセージ復号化の回数は 2^23.5 に制限されるべきです。64ビットタグを使用している場合、同じ整合性制限を維持したいのであれば、制限は大幅に小さくなります。これを推奨するプロトコルは、より小さなタグサイズに対してどのレベルの整合性が許容されるかを分析する必要があります。望ましいレベルの整合性を維持するために、2^7 メッセージごとに鍵を再生成する必要があるかもしれません。

[RFC3610] ではさらに、注目すべき考慮事項を1つ挙げています。平文の一部が非常に予測可能である場合、アルゴリズムに対して事前計算攻撃を行うことが可能です。これにより、鍵サイズのセキュリティが半分に低下します。この攻撃に対処する方法には、ナンス値にランダムな部分を追加することや、使用する鍵サイズを増やすことが含まれます。ナンスの一部をランダム値に使用すると、単一の鍵を使用できるメッセージの数が減少します。鍵サイズを増やすと、制約のあるデバイスでより多くのリソースが必要になる場合があります。詳細については、[RFC3610] のセクション 5 および 10 を参照してください。

4.3. ChaCha20 と Poly1305

ChaCha20 と Poly1305 を組み合わせたものは、[RFC8439] で定義されている AEAD モードです。これは AES ではない暗号を使用して定義されたアルゴリズムであるため、AES で見つかる将来の弱点の影響を受けません。これらの暗号化機能は、ソフトウェアのみの実装で高速になるように設計されています。

[RFC8439] で定義されている ChaCha20/Poly1305 AEAD 構造にはパラメータ化がありません。入力として 256 ビットの鍵と 96 ビットのナンス、および平文と追加データを取り、出力として暗号文を生成します。表 7 でこのアルゴリズムの1つのアルゴリズム識別子を定義します。

     +===================+=======+==========================+
     | 名前              | 値    | 説明                     |
     +===================+=======+==========================+
     | ChaCha20/Poly1305 |   24  | ChaCha20/Poly1305 w/     |
     |                   |       | 256ビット鍵, 128ビットタグ |
     +-------------------+-------+--------------------------+

          表 7: ChaCha20/Poly1305 のアルゴリズム値

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

"kty" フィールドが存在しなければならず (MUST)、"Symmetric" でなければなりません (MUST)。
"alg" フィールドが存在する場合、使用されている ChaCha20/Poly1305 アルゴリズムと一致しなければなりません (MUST)。
"key_ops" フィールドが存在する場合、暗号化するときに "encrypt" または "wrap key" を含める必要があります (MUST)。
"key_ops" フィールドが存在する場合、復号化するときに "decrypt" または "unwrap key" を含める必要があります (MUST)。

4.3.1. ChaCha20/Poly1305 のセキュリティに関する考慮事項

鍵とナンスの値は、アルゴリズムの呼び出しごとに一意のペアでなければなりません (MUST)。ナンスカウンタは、それらが一意であることを保証するための許容可能な方法であると考えられています。

[ROBUST] のより最近の分析は、鍵のロールオーバーをいつ行うかを決定する一環として、復号化の失敗回数を考慮する必要があることを示しています。DTLS ([RFC9147] のセクション 4.5.3) の推奨事項に従い、失敗したメッセージ復号化の回数は 2^36 に制限されるべきです。

[RFC8446] は、ChaCha20/Poly1305 の場合、(64ビットの) レコードシーケンス番号が安全制限に達する前にラップすることに注意しています。COSE 実装は、単一の ChaCha20/Poly1305 鍵を使用して暗号化された 2^64 を超えるメッセージを送信すべきではありません (SHOULD NOT)。