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>
]REFS]

* 意味

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

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


* 構文

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

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

** ヘッダーブロック

[45] 
[DFN[[RUBYB[ヘッダーブロック][header block]]]]
([DFN[[RUBYB[内容符号化ヘッダー][content-coding header]]]])
は、
次の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.]]


* 符号化


[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]

* 復号

= [32] [VAR[レコード]]の末尾から、
[N[0x00]]
[[バイト]]をすべて削除します。
= [33] [VAR[レコード]]が[[空バイト列]]の場合、
== [34] [RUBYB[[[失敗]]][fail]]を返し、ここで停止します。
= [35] [VAR[詰め区切子オクテット]]を、
[VAR[レコード]]の最後の[[バイト]]に設定し、
これを[VAR[レコード]]から削除します。
= [36] [VAR[詰め区切子オクテット]]が [N[0x02]] の場合、
== [37] [VAR[最終レコード]]を、[[偽]]に設定します。
= [38] [VAR[詰め区切子オクテット]]が [N[0x01]] の場合、
== [39] [VAR[最終レコード]]を、[[真]]に設定します。
= [40] それ以外の場合、
== [41] [[失敗]]を返し、ここで停止します。



]FIG]


= [91] [VAR[PRK]] を、
[VAR[salt]]、[VAR[鍵識別子]]について
[[PRK]] を取得した結果に設定します。
= [93] [VAR[CEK]] を、
[VAR[PRK]]
について
[[CEK]] を取得した結果に設定します。
= [94] 
[VAR[平文]]を、
[CODE[AEAD_AES_128_GCM]]
の[[解読]]を実行した結果に設定します。
[FIG(list members)[
: [VAR[鍵]] : [VAR[CEK]]
: [VAR[nonce]] : [VAR[nonce]]
: [VAR[暗号文]] : [VAR[暗号文]]
: [VAR[関連付けされたデータ]] : [[空バイト列]]
([[RFC 8188]] では「additional data」)
]FIG]
= [29] [[Assert]]:
[VAR[暗号文]]の[[長さ][byte length]] = [VAR[平文]]の[[長さ][byte length]] + [N[16]]


= [18] [[Assert]]:
[VAR[暗号文]]の[[長さ][byte length]] = [VAR[平文]]の[[長さ][byte length]] + [N[16]]

= [42] [VAR[最終レコード]]が[[真]]で最後でない場合、
[VAR[最終レコード]]が[[偽]]で最後の場合、
[[失敗]]を返し、ここで停止します。




-*-*-

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

[62] 
途中で途切れたメッセージでも本手法は処理できますが、
完全なメッセージであるものとして処理しては[MUST[なりません]]。
途中までのメッセージでも処理する受信者は、
攻撃者によりメッセージが途中で切られた可能性も考慮する必要があります。
[SRC[>>6 4.2.]]


* 歴史

[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>


[8] 
[TIME[平成29(2017)年6月][2017-06]]、
[DFN[RFC 8188]]
として出版されました
[SRC[>>6]]。