QUICの暗号化と鍵の導出について

QUIC, HTTP/3 関連記事

HTTP/3というかQUICの通信がどのように暗号化されているのか勉強がてら軽くまとめる。(執筆時点でQUIC-TLS Draft 19)

QUICでは、通信の多くが暗号化されています。アプリケーションデータはもちろんのこと、ACKや切断といった制御情報も暗号化されます。さらにパケット番号やフラグが含まれるQUICパケットのヘッダ部分も暗号化されています。

これらの通信の保護がどのように行われているか見ていきます。

先にQUICの概要についてざっとここらへんを見ていただけると良いかと思います。
asnokaze.hatenablog.com

QUICのハンドシェイク
ショートパケットとロングパケット
鍵の導出
- Initial Keys
- そのほかの鍵の導出
パケット保護
- ペイロードの保護
- パケットヘッダの保護 (Header Protection)
Key Update
その他

QUICのハンドシェイク

まずは、QUICのハンドシェイクを見ていきます。

TLS1.3のメッセージを流用しており、QUICの上でTLS1.3のメッセージをやりとりしています。
f:id:ASnoKaze:20190421222513p:plain
(引用 QUIC Security)

コネクションを開始するクライアントは、InitialパケットにCRYPTOフレームを格納し、ClientHelloのメッセージを送信します。(これはInitial Keysで暗号化されます)
もし、0-RTTでEarly Dataを送る場合は送信します。(これは、Early Data (0-RTT) Keysで暗号化されます)
サーバはClientHelloに対してInitialパケットにCRYPTOフレームを格納し、ServerHelloのメッセージを送信します。(これはInitial Keysで暗号化されます9
ServerHelloが送信できれば、Handshake Keysが導出できるので、サーバはHandshakeパケットにCRYPTOフレームを格納し、TLSハンドシェイクの残りを送信します(EncryptedExtensions, Certificate, CertificateVerify, Finished)。（これは、Handshake Keysで暗号化されます）
クライアントがHandshakeパケットを受け取ると、同じくFinishを送るためにHandshakeパケットにCRYPTOフレームを格納し送信します。

こうしてアプリケーションデータを暗号化するための、Application Data (1-RTT) Keysが導出できアプリケーションデータが送受信できます。

QUICでは、下記の4つの鍵が登場します。その鍵によって各パケットのペイロードが保護されます。上記図では、枠線の色ごとに使用する鍵が対応しています。

Initial Keys
Early Data (0-RTT) Keys
Handshake Keys
Application Data (1-RTT) Keys

TLS_AES_128_CCM_8_SHA256を除いてTLS1.3で定義される暗号スイートが利用できます。この暗号スイートを用いて暗号化及び(ハッシュ関数を用いて)鍵の導出が行われます

ショートパケットとロングパケット

パケットのペイロードの暗号化に先立ち、QUICパケットに関して簡単に復習します。

ハンドシェイク中のQUICパケットはすべてロングパケットです。アプリケーションデータはショートパケットで送信されます。

ハンドシェイク中に登場したようにロングパケットとしては、Initialパケット、Handshakeパケット、0-RTTパケットなどがあります。また、紹介しませんがRetryパケットといったものもあります。それぞれロングパケットヘッダ領域を持ちますが、それ以外はパケットごと固有になります。

例えば、Handshakeパケットは下記のようになります。
f:id:ASnoKaze:20190422101405p:plain

ペイロード領域に、TLSメッセージを含むCRYPTOフレームや、Ack情報を格納するACKフレームなどが含まれます。

アプリケーションデータやコネクションの制御情報を含むショートパケットは以下のようになっています。
f:id:ASnoKaze:20190422101518p:plain

ロングパケットに比べ一部の領域が省略されていることが分かります。

鍵の導出

Initial Keys

ClientHello, SeverHelloを運ぶInitialパケットを保護するInitial Keysは特殊であり、仕様に定義されるinitial_saltと送信先コネクションIDから導出されます。

具体的には下記の通りに、client_initial_secret とserver_initial_secret が導出されます。

   initial_salt = 0xef4fb0abb47470c41befcf8031334fae485e09a0
   initial_secret = HKDF-Extract(initial_salt,
                                 client_dst_connection_id)

   client_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "client in", "",
                                             Hash.length)
   server_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "server in", "",
                                             Hash.length)

saltはdraftバージョンで固有。今後変わる可能性があります。つまり、対応しているdraftバージョンでないと正しく復号できません。実装は、対応してない仕様を処理しようとして不具合を起こすことがありません。

少々古いですが下記に書いたとおりです。
asnokaze.hatenablog.com