781.txt

[12] 
[[内容符号化]] [DFN[[CODE[aes128gcm]]]]
[SRC[>>6 2.]]
は、
[[HTTPメッセージ]]で転送するデータを[[暗号化]]するものです。


* 仕様書

[REFS[
- [6] [CITE@en[RFC 8188 - Encrypted Content-Encoding for HTTP]], [TIME[2020-03-09 11:21:54 +09:00]] <https://tools.ietf.org/html/rfc8188>
- [7] [CITE[RFC Errata Report » RFC Editor]], [TIME[2020-03-12 17:34:59 +09:00]] <https://www.rfc-editor.org/errata_search.php?rfc=8188>
- [137] [CITE@en[RFC 8291 - Message Encryption for Web Push]], [TIME[2020-03-09 11:30:01 +09:00]] <https://tools.ietf.org/html/rfc8291>
- [138] [CITE[RFC Errata Report » RFC Editor]], [TIME[2020-03-13 15:40:46 +09:00]] <https://www.rfc-editor.org/errata_search.php?rfc=8291>
]REFS]

* 文脈

[9] 
[[HTTPメッセージ]] ([[HTTP要求]]、
[[HTTP応答]])
の内容を暗号化し、適切な鍵を持つ者のみが閲覧可能とし、
ときに[[サーバー]]すらその内容を閲覧できなくしたいようなとき、
使えるものです。
[SRC[>>6 1.]]

;; [10] [[HTTP]] の[[暗号化]]といえば [[TLS]]
があります。 [[TLS]] は[[サーバー]]と[[クライアント]]の間の[[通信路]]を[[暗号化]]するもので、
性質が異なります。
本手法では、[[サーバー]]すらデータを読むことができないべきかもしれませんし、
読めないデータを他の[[サーバー]]に複製して配置したりすることもあって、
1対の [[HTTPサーバー]]と [[HTTPクライアント]]の間の通信で完結しないかもしれません。
[SRC[>>6 1.]]

[135] 
[[Web Push]] で使われます。
[[アプリケーションサーバー]]から[[プッシュサービス]]へ、そして[[利用者エージェント]]へとデータが転送されるので、
本手法により[[末端対末端]]の[[暗号化]]が実現できます。

[136] 理論上他にもいろいろ用途はあり得ますが、実用例があるのか不明です。

* 構文

[65] 
ある
[[HTTPメッセージ]]における
[CODE[aes128gcm]]
で符号化されたデータは、
[[ヘッダーブロック]]と、
それに続く1個以上の[[レコード]]で構成されます。
[SRC[>>6 2., >>2.1.]]

[FIG(railroad)[
= [[ヘッダーブロック]]
=*
== 途中の[[レコード]]
= 最終[[レコード]]
]FIG]

** ヘッダーブロック

[45] 
[DFN[[RUBYB[ヘッダーブロック][header block]]]]
([DFN[[RUBYB[内容符号化ヘッダー][content-coding header]]]]、
[DFN[encrypted content coding header]] [SRC[>>137 2.]])
は、
次の4つの[DFN[[RUBYB[[[引数]]][parameter]]]]を順に並べたものです。
[SRC[>>6 2.1.]]

[FIG(list members)[

: [DFN[[F[[CODE[salt]]]]]] :
[[内容暗号化鍵]]を決定するために使う[[バイト列]]。
16バイト [SRC[>>6 2.1.]]。
: [DFN[[F[[CODE[rs]]]]]] :
[[レコードサイズ]]を[[バイト]]単位の[[ネットワークバイト順]]の[[32ビット符号無し整数]]としたもの。
[SRC[>>6 2.1.]]
: [DFN[[F[[CODE[idlen]]]]]] :
[F[[CODE[keyid]]]]
[[引数]]の[[長さ][バイト長]]を[[8ビット符号無し整数]]で表したもの。
[SRC[>>6 2.1.]]
: [DFN[[F[[CODE[keyid]]]]]] :
使用する [[IKM]] を識別するために使える、
[F[[CODE[idlen]]]]
[[引数]]で指定された[[長さ][バイト長]]の[[バイト列]]。
[[テキスト]]として[[レンダリング]]する必要がある場合、
[[RFC 3629]] [[UTF-8]] 符号化する[SHOULD[べきです]]。
[SRC[>>6 2.1.]]
[F[[CODE[keyid]]]]
が[[8ビット符号無し整数]]なので、
[[長さ][バイト長]]は [0, 255] [[バイト]]です。

]FIG]

[86] 
[[ヘッダーブロック]]は、最短で21バイト、
最長で276バイトです。

[HISTORY[
[64] 
古い [[I-D]] では、この情報は [CODE[Encryption:]]
[[HTTPヘッダー]]に入れることになっていました。
[[HTTPヘッダー]]ではなく[[本体]]の先頭に入れることに変更したせいで、
[[ランダムアクセス]]できるという特徴が半分嘘になってしまっています。
]HISTORY]




** レコード

[66]
[[レコード]]は、
[[暗号文]]、
[[詰め区切子オクテット]]、
[[詰め]]の順に構成されます。
[DFN[[RUBYB[詰め区切子オクテット][padding delimiter octet]]]]は、
最終[[レコード]]では [N[0x02]]、
途中の[[レコード]]では [N[0x01]]
です。
[DFN[[RUBYB[[[詰め]]][padding]]]]は、
0個[[以上]]の
[N[0x00]]
の[[バイト列]]です。
[SRC[>>6 2.]]

[FIG(railroad)[
= [[暗号文]]
= |
== [N[0x01]]
== [N[0x02]]
= *
== [N[0x00]]
]FIG]


[17] 
[[HTTPメッセージ]]ごとに、
[DFN[[RUBYB[レコードサイズ][record size]]]]は固定です。
途中の[[レコード]]の[[バイト長]]は、
必ず[[レコードサイズ]]です。
最終[[レコード]]の[[バイト長]]は、
[[レコードサイズ]][[以下]]です。
[SRC[>>6 2.]]
[[詰め]]は、
[[レコードサイズ]]に満たないデータを送るときに適宜挿入するものです。

[11] 
本手法は、
[[JWE]]
その他各種既存の[[メッセージ]]ベースの[[暗号化形式]]を採用せず、
[[RFC 5116]] のより低レベルな構造に依っています。
既存の形式では[[ストリーミング処理]]に適しません。
[SRC[>>6 1.]]
本手法は[[レコード]]構造により、
[[範囲要求]]や[[ランダムアクセス]]が、
[[レコードサイズ]]粒度で可能となります。
[SRC[>>6 2.]]

[44] 
適切な[[レコードサイズ]]は、状況により異なります。
小さくすると解読済み[[バイト]]を早めに解放できるので、
[[応答性]]が重要な[[応用]]に適しています。
小さいほど[[ランダムアクセス]]時に解読が必要な余分なデータが少なくて済みます。
逆に大きいほど処理やデータの[[オーバーヘッド]]は小さくなるので、
[[ストリーミング処理]]や[[ランダムアクセス]]や任意の[[詰め]]が不要な[[応用]]は、
[[レコードサイズ]]を大きくできます。
極端な場合は全体を1レコードにできます。
[SRC[>>6 2.]]

[63] 
[[レコードサイズ]]を記述する
[F[[CODE[rs]]]]
[[引数]]は32ビット[[符号無し整数]]なので、
[CODE[AEAD_AES_128_GCM]] の[VAR[平文]]の上限 2[SUP[36]] - 31 は超え得ません。
[SRC[>>6 2.1.]]
さらに、
[[IND-CPA]] の 2[SUP[-40]] の確率を防ぐため、
同じ [[IKM]] と [F[[CODE[salt]]]]
で暗号化される[VAR[平文]]の総量は
16バイトの
2[SUP[44.5]]
[[ブロック]][[未満]]でなければ[MUST[なりません]]。
[[レコードサイズ]]が
16バイトの[[倍数]]のとき、
これはすなわち[[詰め]]とオーバーヘッドを含めて
398テラバイトまで安全に暗号化できることを表します。
16バイトの倍数でないときは更に少なくなり、
最悪ケースは[[高々]]74テラバイトになります。
[SRC[>>6 4.4.]]

[59] 
[DFN[[RUBYB[レコードシーケンス番号][record sequence number]]]]
([DFN[SEQ]])
は、
[N[0]]
から始まる、
[[ネットワークバイト順]]の
96ビット[[符号無し整数]]です。
[SRC[>>6 2.3.]]
最初の[[レコード]]が [N[0]] で、以後
[N[1]]、[N[2]]
と順に増やしていきます
[SRC[仕様書になし]]。
96ビット[[符号無し整数]]なので、
[[レコード]]数は
2[SUP[96]]
を超えられないことになります。

* 暗号化と鍵

[13] 
[CODE[aes128gcm]]
は、
[[RFC 5116]] 5.1 節
[CODE[AEAD_AES_128_GCM]]
([[AES]] [[GCM]]、128ビット[[内容暗号化鍵]]利用)
で[[暗号化]]するものです。
[SRC[>>6 2.]]

[NOTE[
[15] 
[[暗号化]]の [[primitive]] はこの通り固定化されています。
他の手法への対応 ([[cipher agility]])
は、別の[[内容符号化]]を定義することによって実現し、
[[折衝]]は [CODE[Accept-Encoding]] を使うことになっています。
[SRC[>>6 2.]]

[16] 
こういうとき、これまでの [[IETF]] 
の[[プロトコル]]だともう1段階抽象化と折衝の仕組みを導入していたところでしょうが、
既存の[[内容符号化]]の[[折衝]]を流用して統合することで、
仕組みが簡単になって、既存の [[HTTP]] の実装と統合しやすくなっているのは優れた設計です。
]NOTE]


[14] 
本手法では、
[[暗号化]]時と[[解読]]時に[[鍵]]が必要となります。
両者で共有する
[[input-keying material]]
([[keying material]]、[[IKM]])
と、
[[HTTPメッセージ]]ごとの[[内容暗号化キー]] ([[CEK]])
の2段階となっています。
これは1つの [[IKM]] を複数の [[HTTPメッセージ]]で再利用するためです
[SRC[>>6 2.2.]]。

-*-*-

[72] 
[[IKM]] を取得するには、
[VAR[鍵識別子]]について、
次のようにします。
[SRC[>>6 2.1.]]

[FIG(steps)[
= [74] [VAR[IKM]] を、
[VAR[鍵識別子]]を使って[[鍵]]を取得した結果に設定します。
= [75] [VAR[IKM]] を返します。
]FIG]

[76] [[鍵]]の取得の方法は、
[[仕様書]]では定義されていません [SRC[>>6 2.]]。 
受信者はその方法を知っていることが期待されます [SRC[>>6 2.1.]]。
取得のために [VAR[keyid]] を使うことができます [SRC[>>6 2.1.]]
(が使わなければならないわけでもありません)。
[[鍵]]の共通方法は、[[応用]]ごとに別途定めておく必要があります。

[77] 
[CODE[keyid]]
を[[テキスト]]として[[レンダリング]]する場合の規定がある (>>45)
ので、
[[利用者]]に提示して[[鍵]]を入力させる方式も採り得るようです。
しかしそれも1つの方法に過ぎず、 [CODE[keyid]]
が[[テキスト]]であるとも保証されていません。一般には[[バイト列]]として扱わなければなりません。


-*-*-

[46] 
[DFN[[RUBYB[内容暗号化キー][content-encryption key]]]] ([DFN[[[CEK]]]])
は、
[[IKM]] と [CODE[salt]] から、
[[HTTPメッセージ]]ごとに求めます。
その方法として、
[[RFC 5869]] [[HKDF]]
で
[[SHA-256]] 
を使ったものを用います。
[SRC[>>6 2.2.]]


[89] 
[[CEK]] の取得は、
[VAR[PRK]]
について次のようにします。
[SRC[>>6 2.2.]]

[FIG(steps)[
= [50] 
[VAR[cek_info]]
を、
[CODE[Content-Encoding: aes128gcm]]
に
[N[0x00]]
を[[末尾に連結]]した結果に設定します。
= [51] 
[VAR[CEK]]
を、
[CODE[HMAC-SHA-256]] ([VAR[PRK]], [VAR[cek_info]] に [N[0x01]] を[[末尾に連結]]した結果)
の結果に設定します。
[NOTE[
[53] [VAR[L]] = [N[16]]
なので、このように簡略化できます。
]NOTE]
= [52] 
[VAR[CEK]]
を返します。
]FIG]




[87] 
[DFN[[RUBYB[疑似乱数鍵][pseudorandom key]]]] ([DFN[PRK]])
の取得は、
[VAR[salt]]、[VAR[鍵識別子]]について、
次のようにします。
[SRC[>>6 2.2.]]

[FIG(steps)[
= [47] [VAR[IKM]] を、
[VAR[鍵識別子]]について
[[IKM]]
を取得した結果に設定します。
= [49] 
[VAR[PRK]] 
を、
[CODE[HMAC-SHA-256]] ([VAR[salt]], [VAR[IKM]])
の結果に設定します。
= [88] 
[VAR[PRK]] を返します。
]FIG]

[90] [[PRK]] は、[[CEK]] や [[nonce]] の取得に使います。


[82] 
[CODE[salt]]
は、
[[暗号化]]時に[[HTTPメッセージ]]ごとに準備し、
[[ヘッダーブロック]]に入れて[[解読]]者へと引き渡します。
[[解読]]者は[[ヘッダーブロック]]から取り出して使います。

[83] [[salt]] の生成は、次のようにします。

[FIG(steps)[
= [84] [VAR[salt]] を、16バイトの[[バイト列]]に設定します。
=- [68] 
同じ [[IKM]] を使う別の [[HTTPメッセージ]]で同じ 
[VAR[salt]] を使っては[MUST[なりません]]。
[SRC[>>6 2.1., 4.3.]]
=- [69] [[HTTPメッセージ]]ごとに毎回
[VAR[salt]]
を生成する[SHOULD[べきです]]。
[SRC[>>6 4.3.]]
= [85] [VAR[salt]] を返します。
]FIG]


-*-*-


[54] 
[[nonce]]
の取得は、
[VAR[PRK]]、
[VAR[SEQ]]
について次のようにします。
[SRC[>>6 2.3.]]

[FIG(steps)[
= [55] [VAR[nonce_info]] を、
[CODE[Content-Encoding: nonce]]
に
[N[0x00]]
を[[末尾に連結]]した結果に設定します。
= [56] [VAR[NONCE]]
を、
[CODE[HMAC-SHA-256]]
([VAR[PRK]], [VAR[nonce_info]] に [N[0x01]] を[[末尾に連結]]した結果)
の結果と
[VAR[SEQ]]
を
[[XOR]]
した結果に設定します。
= [58] 
[[Assert]]:
[VAR[NONCE]]
は96ビットです。
= [57] [VAR[NONCE]] を返します。
]FIG]


[60] 
[[nonce]]
は、
[[レコード]]の削除や順序入れ替えを防ぐものです。
[SRC[>>6 2.3.]]

** Web Push

[146] [[利用者エージェント]]は、
[[push subscription]]
[VAR[sub]]
の生成時に、次のようにします。

[FIG(steps)[
= [147] [VAR[鍵ペア]]を、 [[P-256 curve]] の [[ECDH]] 
[[鍵ペア]]を生成した結果に設定します。
[SRC[>>137 2., 3.1.]]
= [159] [VAR[authentication secret]]
を、
16バイトの[[バイト列]]に設定します。
[SRC[>>137 3.2.]]
=- [140] 推測し難いものでなければ[MUST[なりません]]。
=- [160] [[RFC 4086]] [[暗号学的に強い乱数生成器]]を使う[SHOULD[べきです]]。
= [148]  
[VAR[sub]] の[F[鍵ペア]]を、[VAR[鍵ペア]]に設定します。
= [161] [VAR[sub]] の [F[authentication secret]]
を、 [VAR[authentication secret]] に設定します。
]FIG]

[158] 
[[symmetric authentication secret]]
である
[VAR[sub]] の [F[authentication secret]]
は、
[[プッシュメッセージ]]が正しく[[認証]]されるようにするものです。
[SRC[>>137 3.2.]]

[141] 
[VAR[sub]] の[F[鍵ペア]]の[F[公開鍵]]と
[VAR[sub]] の [F[authentication secret]]
は、
他の必要な情報と共に、
[[アプリケーション]]に引き渡します。
[SRC[>>137 2.]]


[144] 
[[push subscription]]
を使う[[アプリケーション]]は、
[[subscription]] [[公開鍵]]と
[[authentication secret]]
を、
[RUBYB[認可された][authorized]][[アプリケーションサーバー]]に配布します。
[[アプリケーション]]は、
[[認証]]された、
秘密が保持される通信媒体を使ってこれを行わなければ[MUST[なりません]]。
これは [[RFC 8030]] に述べられた理由に加え、
[[authentication secret]]
が漏れると[[プッシュメッセージ]]を送られてしまうからです。
ほとんどの[[アプリケーション]]は予め決められた[[アプリケーションサーバー]]との関係を持っていて、
[[HTTPS]] のような方法でこの条件を満たせます。
[SRC[>>137 2.1.]]

;; [145] 一昔前ならこれは[[保安通信路]]という言葉で表されていました。
ここでの規定がややもってまわった形になっているのは、
登場するのが1対の[[クライアント]]と[[サーバー]]の間だけで完結するものでないためでしょう。



[142] 
[[アプリケーションサーバー]]は、
[[プッシュメッセージ]]送付時、
[[random salt]]
を生成します。
[[salt]] は、
[[ヘッダーブロック]]の [F[[CODE[salt]]]]
[[引数]]に符号化します。
[SRC[>>137 2.]]

[149] 
[[アプリケーションサーバー]]は、
[[プッシュメッセージ]]送付時、
[VAR[sub]] について、
次のようにします。

[FIG(steps)[
= [150] [VAR[鍵ペア]]を、 [[P-256 curve]] の [[ECDH]] 
[[鍵ペア]]を生成した結果に設定します。
[SRC[>>137 2., 3.1.]]
[NOTE[
[152] 
[VAR[鍵ペア]]は、
[[プッシュメッセージ]]の[[暗号化]]後、
捨てて構いません。
[SRC[>>137 2.]]
]NOTE]
= [151] [VAR[鍵識別子]]を、[VAR[鍵ペア]]の[F[公開鍵]]に設定します。
[SRC[>>137 2., 3.1.]]
= [153] 
[VAR[ECDH shared secret]] を、
[VAR[鍵ペア]]の[F[秘密鍵]]と
[VAR[sub]] の[F[公開鍵]]について、
[[ECDH]] の処理を実行した結果に設定します。
[SRC[>>137 3.1.]]
]FIG]

[154] 
[[利用者エージェント]]は、
[[プッシュメッセージ]]受信時、
[VAR[sub]] と[VAR[鍵識別子]]について、
次のようにします。

[FIG(steps)[
= [156] [VAR[公開鍵]]を、[VAR[鍵識別子]]に設定します。
= [155] 
[VAR[ECDH shared secret]] を、
[VAR[sub]] の[F[鍵ペア]]の[F[秘密鍵]]と[VAR[公開鍵]]について、
[[ECDH]] の処理を実行した結果に設定します。
[SRC[>>137 3.1.]]

]FIG]



[143] 
[[プッシュメッセージ]]の内容は、
[[内容暗号化鍵]]と [[nonce]]
を使って[[暗号化]]したり[[解読]]したりします。
[CODE[salt]]
を入力として使います。
[SRC[>>137 2.]]



* 符号化


[97] 
[[符号化]]は、[[平文]]の[[バイト列]]を入力とし、
[[暗号化]]された[[バイト列]]を出力とする操作です。
[[符号化]]の処理たる[VAR[符号化器]]は、
次の状態を保持します。

[FIG(list members)[
: [F[salt]] : [[バイト列]]。
: [F[レコードサイズ]] : [[非負整数]]。
: [F[鍵識別子]] : [[バイト列]]。
: [F[PRK]] : [[バイト列]]。
: [F[CEK]] : [[バイト列]]。
: [F[SEQ]] : [[非負整数]]。
]FIG]

[95] 
[VAR[符号化器]]による[[符号化]]の開始時には、
[[非負整数]][VAR[レコードサイズ]]、
[[バイト列]][VAR[鍵識別子]]について、
次のようにします。
[SRC[>>6 2.1.]]

[FIG(steps)[
= [67] [[Assert]]: [VAR[レコードサイズ]]は [18, 2[SUP[32]] - 1]
= [81] [[Assert]]: [VAR[鍵識別子]]の[[長さ][バイト長]]は [0, 255]
[SRC[仕様書に明記は無し]]
= [70] [VAR[符号化器]]の [F[salt]] を、
[[salt]] を生成した結果に設定します。
= [71] [VAR[符号化器]]の[F[レコードサイズ]]を、
[VAR[レコードサイズ]]に設定します。
= [100] [VAR[符号化器]]の[F[鍵識別子]]を、
[VAR[鍵識別子]]に設定します。
= [43] 
[VAR[符号化器]]の [F[PRK]]
を、
[VAR[salt]]、[VAR[鍵識別子]]について
[[PRK]]
を取得した結果に設定します。
= [92] [VAR[符号化器]]の [F[CEK]]
を、
[VAR[符号化器]]の [F[PRK]]
について
[[CEK]] を取得した結果に設定します。
= [48] [VAR[符号化器]]の [F[SEQ]] を、 [N[0]] に設定します。
= [73] [VAR[ヘッダーブロック]]を、
[[空バイト列]]に設定します。
= [98] [VAR[ヘッダーブロック]]に、
[VAR[符号化器]]の [F[salt]] を[[末尾に追加]]します。
= [99] [VAR[ヘッダーブロック]]に、
[VAR[符号化器]]の[F[レコードサイズ]]を[[ネットワークバイト順]]の[[32ビット符号無し整数]]としたものを[[末尾に追加]]します。
= [79] [VAR[ヘッダーブロック]]に、
[VAR[符号化器]]の[F[鍵識別子]]の[[長さ][バイト長]]を[[8ビット符号無し整数]]としたものを[[末尾に追加]]します。
= [80] [VAR[ヘッダーブロック]]に、
[VAR[符号化器]]の[F[鍵識別子]]を[[末尾に追加]]します。
= [101] [VAR[ヘッダーブロック]]を送信します。
]FIG]

[102] 
[VAR[符号化器]]による[[符号化]]の過程、
[[バイト列]][VAR[データ]]を、
これが[[バイト列]]全体の末尾に当たるかどうかを表す[[真偽値]][VAR[最後]]について送信するには、
次のようにします。
[SRC[>>6 2.1.]]

[FIG(steps)[
= [103] [[Assert]]: [VAR[データ]]の[[長さ][バイト長]]は
[0, [VAR[符号化器]]の[F[レコードサイズ]] - 17]
= [78] 
[VAR[nonce]]
を、
[VAR[符号化器]]の [F[PRK]] 
と[VAR[符号化器]]の [F[SEQ]]
について
[[nonce]] を取得した結果に設定します。
= [27] 
[VAR[[RUBYB[暗号文][ciphertext]]]]を、
[CODE[AEAD_AES_128_GCM]]
の[[暗号化]]を実行した結果に設定します。
[FIG(list members)[
: [VAR[鍵]] : [VAR[符号化器]]の [F[CEK]]
: [VAR[nonce]] : [VAR[nonce]]
: [VAR[平文]] : [VAR[データ]]
: [VAR[関連付けされたデータ]] : [[空バイト列]]
[NOTE[
[25] [[RFC 8188]] では「additional data」と呼ばれています。
]NOTE]
]FIG]
= [29] [[Assert]]:
[VAR[暗号文]]の[[長さ][byte length]] = [VAR[平文]]の[[長さ][byte length]] + [N[16]]
= [21] [VAR[詰め区切子オクテット]]を、
[VAR[最後]]なら 
[N[0x02]]、
それ以外なら
[N[0x01]]
に設定します。
= [20] [VAR[符号化器]]の [F[SEQ]] を、[N[1]] [[インクリメント]]します。
= [19] [VAR[レコード]]を、
[VAR[暗号文]]に[VAR[詰め区切子オクテット]]を[[末尾に連結]]した結果に設定します。
= [105] [VAR[レコード]]の[[長さ][バイト長]]が[VAR[レコードサイズ]][[未満]]の間、繰り返し、
== [22] [VAR[最後]]の場合、
=== [23] ここで繰り返しを脱出して構いません。
== [106] [VAR[レコード]]に、 [N[0x00]] を[[末尾に追加]]します。
= [24] [VAR[レコード]]を送信します。
]FIG]

* 復号

[28] 
[[復号]]は、[[暗号化]]された[[バイト列]]を入力とし、
[[解読]]された[[バイト列]]を出力とする操作です。
[[復号]]の処理たる[VAR[復号器]]は、
次の状態を保持します。

[FIG(list members)[
: [F[salt]] : [[バイト列]]。
: [F[レコードサイズ]] : [[非負整数]]。
: [F[鍵識別子]] : [[バイト列]]。
: [F[PRK]] : [[バイト列]]。
: [F[CEK]] : [[バイト列]]。
: [F[SEQ]] : [[非負整数]]。
]FIG]


[26] 
[VAR[復号器]]による[[復号]]は、
次のようにします。

[FIG(steps)[
= [130] [VAR[結果バイト列]]を、[[空バイト列]]に設定します。
= [110] 21バイト受信するのを待ちます。
完了前に入力が終了した場合、
[[失敗]]を返してここで停止します。
[SRC[仕様書になし]]
= [30] [VAR[ヘッダーブロック]]を、受信した21バイトの[[バイト列]]に設定します。
= [31] [VAR[復号器]]の
[F[salt]]
を、[VAR[ヘッダーブロック]]の先頭16バイトに設定します。
[SRC[>>6 2.1.]]
= [104] [VAR[復号器]]の[F[レコードサイズ]]を、
[VAR[ヘッダーブロック]]の第17バイトから第20バイトを[[ネットワークバイト順]]の[[32ビット符号無し整数]]として解釈した結果に設定します。
[SRC[>>6 2.1.]]
= [112] [VAR[復号器]]の[F[レコードサイズ]]が [N[18]] [[未満]]の場合 [SRC[>>6 2.1.]]、
== [113] [[失敗]]を返し、ここで停止します。 [SRC[仕様書になし]]
= [107] [VAR[識別子長]]を、
[VAR[ヘッダーブロック]]の最終バイトを[[8ビット符号無し整数]]として解釈した結果に設定します。
[SRC[>>6 2.1.]]
= [108] [VAR[識別子長]]バイト受信するのを待ちます。
完了前に入力が終了した場合、
[[失敗]]を返してここで停止します。
[SRC[仕様書になし]]
= [109] [VAR[復号器]]の[F[鍵識別子]]を、
受信した[VAR[識別子長]]バイトの[[バイト列]]に設定します。
= [91] [VAR[復号器]]の [F[PRK]] を、
[F[復号器]]の [F[salt]]、
[F[復号器]]の[F[鍵識別子]]について
[[PRK]] を取得した結果に設定します。
= [93] [VAR[復号器]]の [F[CEK]] を、
[VAR[復号器]] の [F[PRK]]
について
[[CEK]] を取得した結果に設定します。
= [111] [VAR[復号器]]の [F[SEQ]] を、
[N[0]]
に設定します。
= [114] 繰り返し、
== [115] 
[VAR[レコード]]を、受信した[[バイト列]]に設定します。
[VAR[レコード]]の[[長さ][バイト長]]が[VAR[復号器]]の[F[レコードサイズ]]に等しくなるか、
受信[[バイト列]]の末尾に到達するまでとします。
== [120] 
[VAR[詰め区切子オクテット]]を、
[VAR[レコード]]の末尾から順に [N[0x00]] でない[[バイト]]を探した結果に設定します。
== [121] 
[VAR[詰め区切子オクテット]]が [CODE[null]] の場合、
=== [122] [MUST[失敗]]を返し、ここで停止します。
[SRC[>>6 2.]]
== [33] 
[VAR[詰め区切子オクテット]]が [N[0x01]] でも [N[0x02]] でもない場合、
=== [34] [MUST[失敗]]を返し、ここで停止します。
[SRC[>>6 2.]]
== [123] 
[VAR[詰め区切子オクテット]]が [N[0x01]] で[VAR[レコード]]の[[長さ][バイト長]]が[VAR[復号器]]の[F[レコードサイズ]]で''ない''場合、
=== 
;; [35] この条件は[[仕様書]]に明記されていませんが、
最終レコードが [N[0x02]] でなければ[MUST[失敗]]という要件が適用されます。
=== [124] [MUST[失敗]]を返し、ここで停止します。
== [125] 
[VAR[暗号文]]を、
[VAR[レコード]]から末尾の [N[0x00]] [[バイト]]とその直前の[VAR[詰め区切子オクテット]]を除去した結果に設定します。
[SRC[>>6 2.]]
== [116] 
[VAR[nonce]]
を、
[VAR[復号器]]の [F[PRK]] 
と[VAR[復号器]]の [F[SEQ]]
について
[[nonce]] を取得した結果に設定します。
== [94] 
[VAR[平文]]を、
[CODE[AEAD_AES_128_GCM]]
の[[解読]]を実行した結果に設定します。
[FIG(list members)[
: [VAR[鍵]] : [VAR[復号器]]の [F[CEK]]
: [VAR[nonce]] : [VAR[nonce]]
: [VAR[暗号文]] : [VAR[暗号文]]
: [VAR[関連付けされたデータ]] : [[空バイト列]]
[NOTE[
[40] [[RFC 8188]] では「additional data」と呼ばれています。
]NOTE]
]FIG]
== [29] [[Assert]]:
[VAR[暗号文]]の[[長さ][byte length]] = [VAR[平文]]の[[長さ][byte length]] + [N[16]]
== [42] [VAR[結果バイト列]]に、[VAR[平文]]を[[末尾に追加]]します。
== [39] [VAR[復号器]]の [F[SEQ]] を、 [N[1]] [[インクリメント]]します。
== [37] [VAR[詰め区切子オクテット]]が [N[0x02]] の場合、
=== [126] 次のバイトを受信するか、受信[[バイト列]]の終端に到達するのを待ちます。
=== [127] バイトを受信した場合、
==== 
;; [41] 最終レコードを受信しましたが、まだ次のレコードがあります。
==== [128] [MUST[失敗]]を返し、ここで停止します。
[SRC[>>6 2.]]
=== [38] ここで停止します。
= [117]
;; [129] 最終レコードを受信していませんが、もう次のレコードがありません。
= [119] [MUST[失敗]]を返し、ここで停止します。
[SRC[>>6 2.]]


]FIG]

[131] 
[VAR[結果バイト列]]が[[復号]]した結果になります。

[118] 
[[仕様書]]はエラー処理をほとんど曖昧に濁しています。
[[レコード]]を[[失敗]]とみなすべき条件がいくつか定められていますが、
そのときまでに得られた[VAR[結果バイト列]]をそのまま使って良いのかどうか、
[[失敗]]した[[レコード]]から得られた情報を[VAR[結果バイト列]]に含めて良いのか、
[[仕様書]]からは読み取れません。

[132] 特に問題なのは、[VAR[詰め区切子オクテット]]が最終レコードなら [N[0x02]]、
それ以外なら [N[0x01]] でなければ[RUBYB[[[失敗]]][fail]]としなければ[MUST[ならない]]
[SRC[>>6 2.]] との条件です。[[ストリーミング処理]]でこの要件を満たすためには、
次のレコード (または入力の末端) まで処理を進める必要があります。
[[仕様書]]がどうとでも解釈できるので、
実装によって、あるいは[[ネットワーク]]からの[[バイト]]の到着タイミング次第で、
挙動が変わってくるおそれがあります。

[62] 
途中で途切れたメッセージでも本手法は処理できますが、
完全なメッセージであるものとして処理しては[MUST[なりません]]。
途中までのメッセージでも処理する受信者は、
攻撃者によりメッセージが途中で切られた可能性も考慮する必要があります。
[SRC[>>6 4.2.]]
この規定の存在が、[[失敗]]の扱いの解釈を難しくします。
途切れた[[メッセージ]]や[[ランダムアクセス]]の処理では、
入力中最後の[[レコード]]の[VAR[詰め区切子オクテット]]が [N[0x02]]
でなくても認めなければなりません。
このような実装方針次第でいかようにもなりそうな曖昧な規定方法は、
[[セキュリティー]]問題の温床でしかありません。

[157] 途中の[[レコード]]で解読に失敗した場合、
無視して次の[[レコード]]に進むべきなのか、停止するべきなのか不明です。

-*-*-

[61] 
本手法を使って内容の起源を認証する[[受信者]]は、
[CODE[aes128gcm]]
[[内容符号化]]を含まない[[HTTPメッセージ]]を拒絶しなければ[MUST[なりません]]。
[[内容符号化]]が自動的に除去されて、最終的な受信者がそれに気づかないおそれがあります。
[SRC[>>6 4.1.]]



* 歴史

[1] [CITE@en[Encrypted Content-Encoding for HTTP]]
([TIME[2016-04-06 02:26:28 +09:00]] 版)
<http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.html>

[2] [CITE@en[draft-ietf-webpush-encryption-08 - Message Encryption for Web Push]]
([TIME[2017-04-16 18:28:05 +09:00]])
<https://tools.ietf.org/html/draft-ietf-webpush-encryption-08>

[3] [[IANA登録簿]]に [CODE[aes128gcm]] が登録されました。 [TIME[2017-04-21T03:50:50.600Z]]

[4] [CITE@en[Add PushManager.supportedContentEncodings (#252)]]
([[beverloo]]著, [TIME[2017-04-26 01:13:27 +09:00]])
<https://github.com/w3c/push-api/commit/813f9af75d59e3fa1522db9aeeaa2bd158ff10bf>

[5] [CITE@en[encrypted-content-encoding/ece.js at master · web-push-libs/encrypted-content-encoding]]
([TIME[2019-01-04 13:12:20 +09:00]])
<https://github.com/web-push-libs/encrypted-content-encoding/blob/master/nodejs/ece.js>

[134] 古い案では[[内容符号化]]
[DFN[[CODE[aesgcm]]]],
[[内容符号化]] [DFN[[CODE[aesgcm128]]]],
[[HTTPヘッダー]] [DFN[[CODE(HTTP)@en[Encryption:]]]],
[[HTTPヘッダー]] [DFN[[CODE(HTTP)@en[Encryption-Key:]]]],
[[HTTPヘッダー]] [DFN[[CODE(HTTP)@en[Crypto-Key:]]]]
が提案されていました。

[8] 
[TIME[平成29(2017)年6月][2017-06]]、
[CODE[aes128gcm]]
の[[仕様書]]が
[[IETF]]
の[[提案標準]]
[DFN[RFC 8188]]
が出版されました
[SRC[>>6]]。

[133] それにしてもこの時代に出版されたとは思えない、古き悪しき時代を思わせる曖昧な[[仕様書]]です。
構文、生成側処理、解釈側処理のどれなのかはっきりしない曖昧な規定、
[[事実の文]]ベースで実装の要件がはっきりしない上に、
用語の表記がその場その場で少しずつ揺れていて意図的かどうかわかりにくい、
挙動が用語のイメージの暗黙の了解によって規定され明文化されていない、
といった [[IETF]]
にありがちな空気を読まないといけない[[仕様書]]。
こんなもので[[相互運用性]]は維持できるのでしょうか。

[139] 
[TIME[平成20(2017)年11月][2017-11]]、
[[Web Push]] での[[暗号化]]方式の[[仕様書]]が
[[IETF]] 
の[[提案標準]]
[DFN[RFC 8291]]
として出版されました
[SRC[>>137]]。