鍵導出関数（KDF）の原理：HKDF の extract-and-expand

KDF が解く問題：鍵素材は鍵ではない

鍵交換の結果として手に入る生の値は、そのまま暗号鍵には使えません。たとえば Diffie–Hellman の共有値 g^(ab) は、攻撃者から秘匿されてはいても、ビットの分布が一様ではない（特定ビットに偏りや構造が残る）。一方 AES や AEAD が前提とするのは「全ビットが一様ランダムに見える固定長の鍵」です。この溝を埋めるのが **KDF（Key Derivation Function／鍵導出関数）**で、役割は2つあります。

• 平滑化：偏った・構造を持つ入力鍵素材（IKM: Input Keying Material）から、統計的に一様な擬似ランダム鍵を取り出す。
• 伸長と分割：1つの素材から、暗号鍵・IV・MAC 鍵といった複数の独立な鍵を必要な長さだけ作り分ける。

extract-and-expand：なぜ2段に分けるのか

HKDF（RFC 5869）の設計思想は、KDF の仕事を性質の異なる2フェーズに明確に分離したことです。土台はすべて HMAC（ハッシュ関数を鍵付きで二重に回す MAC）で、HMAC の擬似ランダム関数（PRF）としての性質に安全性を帰着させます。

分離の利点は、入力が既に一様な場合は extract を省ける点にあります。乱数生成器の出力のように IKM が初めから擬似ランダムなら、平滑化は不要で expand だけ回せばよい。逆に DH 共有値のように偏りがある場合だけ extract を挟む。1つの関数に押し込めず2段にしたことで、状況に応じた最適化と、各段の安全性証明の切り分けが可能になりました。

Extract：エントロピーを HMAC で凝縮する

extract フェーズは驚くほど単純で、HMAC をそのまま使います。salt を HMAC の鍵に、IKM をメッセージに据えるだけです。

HKDF-Extract(salt, IKM):
    PRK = HMAC-Hash(key = salt, message = IKM)
    return PRK            # 出力は Hash の出力長（SHA-256 なら 32 バイト）

ここでの HMAC は「メッセージ認証」のためではなく、ランダム性抽出器（randomness extractor）として働きます。IKM のどこにエントロピーが偏って分布していても、HMAC の撹拌で全 PRK ビットへ均され、結果は一様ランダムと区別できない固定長 PRK になります。salt が秘密である必要はありません。salt は抽出器を「ランダムに選ぶ」ための公開ソルトで、特定の IKM 分布に対する最悪ケースを避け、抽出の安定性を高める役割です。

Expand：PRK を info ラベルで伸長・分割する

expand フェーズは、固定長の PRK から任意長 L バイトの出力鍵 OKM を作ります。ここでも中身は HMAC で、前ブロックを次の入力にフィードバックする反復（カウンタ付き）です。

HKDF-Expand(PRK, info, L):
    N = ceil(L / HashLen)          # 必要ブロック数
    T(0) = 空文字列
    T(i) = HMAC-Hash(PRK, T(i-1) || info || byte(i))   # i = 1..N
    OKM  = (T(1) || T(2) || ... || T(N)) の先頭 L バイト
    return OKM

各ブロック T(i) は前ブロック T(i-1) と info、そして 1 バイトのカウンタ i を連結して HMAC にかけます。前ブロックを混ぜるフィードバックにより、出力ブロック間に独立性が生まれます。L が大きくてもブロックを継ぎ足すだけで伸ばせますが、カウンタが 1 バイトのため最大 255 ブロック（SHA-256 なら 255×32 = 8160 バイト）という上限がある点は実装上の注意です。

info の本質：コンテキスト分離

HKDF を「ただの鍵伸長」ではなく実用的なものにしているのが info パラメータです。info は用途を識別するラベルで、同じ PRK からでも info が違えば暗号的に独立した別の鍵が出ます。

同じ PRK から3つの鍵を作り分ける:
    enc_key = HKDF-Expand(PRK, info = "app data key",  32)
    iv      = HKDF-Expand(PRK, info = "app data iv",   12)
    mac_key = HKDF-Expand(PRK, info = "app data mac",  32)
# info が違えば HMAC 入力が変わり、出力同士に相関は生じない

このコンテキスト分離（domain separation）が無いと、ある用途の鍵を別用途に流用したときに鍵が衝突・干渉し、片方の漏洩が他方を脅かす「クロスプロトコル攻撃」の温床になります。info にプロトコル名・バージョン・用途・場合によってはセッション識別子を埋め込むことで、「この鍵はこの文脈でしか出てこない」ことを暗号的に保証できます。salt がエントロピーの抽出器を選ぶのに対し、info は出力の名前空間を分けるものだと整理すると役割が明確になります。

TLS 1.3 の鍵スケジュール：extract と expand の連鎖

HKDF が最も体系的に使われているのが TLS 1.3 の鍵スケジュールです。ハンドシェイクの各段で HKDF-Extract と、info を構造化した HKDF-Expand-Label を交互に連鎖させ、すべてのトラフィック鍵を導出します。

TLS 1.3 鍵スケジュール（概念）:

    Early Secret     = HKDF-Extract(salt = 0,            IKM = PSK or 0)
                          │ Derive-Secret(..., "derived")
    Handshake Secret = HKDF-Extract(salt = ↑derived,     IKM = (EC)DHE 共有値)
                          │ Derive-Secret(..., "derived")
    Master Secret    = HKDF-Extract(salt = ↑derived,     IKM = 0)

各 Secret から HKDF-Expand-Label で用途別鍵を導出:
    c hs traffic / s hs traffic / c ap traffic / s ap traffic ...

ポイントは3つです。第一に、各段の extract の IKM が異なること——PSK、DH 共有値、ゼロを段階的に注入し、利用可能な秘密を漏れなく鍵に織り込みます。第二に、前段の出力を Derive-Secret(..., "derived") で変換して次段の salt に渡すことで、鍵スケジュール全体が一本の鎖になり、履歴を改ざんすると以降の鍵が総崩れになります。第三に、HKDF-Expand-Label の info にはラベル文字列とハンドシェイクのトランスクリプトハッシュが入り、そのハンドシェイクでしか同じ鍵が出ないよう束縛されます。

まとめ

KDF は「秘匿されてはいるが鍵としては使えない素材」を、用途別の一様ランダム鍵へ変換する道具です。HKDF はその仕事を **extract（salt を鍵に HMAC でエントロピーを凝縮し PRK を作る）**と **expand（PRK と info ラベルから任意長の鍵を反復生成する）**の2段に分け、入力が既に一様なら extract を省ける柔軟性を得ました。salt はエントロピー抽出器を選ぶ公開値、info は出力鍵の名前空間を分けるラベル——この役割分担を押さえると、TLS 1.3 が HKDF-Extract と HKDF-Expand-Label を連鎖させて全鍵を1本の鎖から導く設計が一貫して見えてきます。

鍵導出の土台となる HMAC とハッシュ構造は ハッシュ関数の内部構造、導出された鍵を消費する側は AEAD の設計原理、鍵交換で IKM を生む仕組みは Diffie–Hellman 鍵交換 を合わせて参照してください。