3. Notes to HKDF Users (HKDF ユーザーへの注意事項)

このセクションには, HKDF の使用に関する一連の指針が含まれています。これらの原則と設計根拠のより広範な説明は, [HKDF-paper] にあります。

3.1. To Salt or not to Salt (ソルトを使うかどうか)

HKDF は, ランダムソルトを使用する場合と使用しない場合の両方で動作するように定義されています。これは, ソルト値が利用できないアプリケーションに対応するために行われています。しかし, ソルトの使用は HKDF の強度を大幅に高め, ハッシュ関数の異なる使用間の独立性を確保し, "ソースに依存しない"抽出をサポートし, HKDF 設計を裏付ける分析結果を強化することを強調します。

ランダムソルトは, 初期鍵材料と2つの点で根本的に異なります: それは非秘密であり, 再利用できます。したがって, ソルト値は多くのアプリケーションで利用可能です。たとえば, 再生可能なエントロピーのプール (サンプリングされたシステムイベントなど) に HKDF を適用することによって継続的に出力を生成する疑似乱数生成器 (pseudorandom number generator, PRNG) は, ソルト値を固定し, ソルトの秘密性を保護することなく HKDF の複数の適用に使用できます。別のアプリケーション領域では, Diffie-Hellman 交換から暗号鍵を導出する鍵合意プロトコルは, 鍵合意の一部として通信当事者間で交換され認証された公開ノンスからソルト値を導出できます (これは [IKEv2] で採用されているアプローチです)。

理想的には, ソルト値は長さ HashLen のランダム (または疑似ランダム) 文字列です。しかし, 質の低いソルト値 (サイズが短いか, エントロピーが限られている) であっても, 出力鍵材料のセキュリティに大きく貢献する可能性があります。したがって, アプリケーションの設計者は, アプリケーションがそのような値を取得できる場合は, HKDF にソルト値を提供することが奨励されます。

典型的なケースではありませんが, 一部のアプリケーションには使用可能な秘密ソルト値がある場合もあることに注意してください。そのような場合, HKDF はさらに強力なセキュリティ保証を提供します。そのようなアプリケーションの例は, "公開鍵暗号化モード"の IKEv1 で, 抽出器への"ソルト"は秘密のノンスから計算されます。同様に, IKEv1 の事前共有モードは, 事前共有鍵から導出された秘密ソルトを使用します。

3.2. The 'info' Input to HKDF (HKDF への 'info' 入力)

'info' 値は HKDF の定義ではオプションですが, アプリケーションでは非常に重要であることがよくあります。その主な目的は, 導出された鍵材料をアプリケーション固有およびコンテキスト固有の情報にバインドすることです。たとえば, 'info' にはプロトコル番号, アルゴリズム識別子, ユーザー ID などが含まれる場合があります。特に, 異なるコンテキストで同じ入力鍵材料 (IKM) が使用される場合, 異なるコンテキストで同じ鍵材料が導出されるのを防ぐことができます。また, 必要に応じて鍵拡張部分への追加入力に対応することもできます (たとえば, アプリケーションが鍵材料をその長さ L にバインドしたい場合があり, L を 'info' フィールドの一部にすることができます)。'info' には1つの技術的要件があります: それは入力鍵材料値 IKM から独立している必要があります。

3.3. To Skip or not to Skip (スキップするかどうか)

一部のアプリケーションでは, 入力鍵材料 IKM はすでに暗号学的に強力な鍵として存在している可能性があります (たとえば, TLS RSA 暗号スイートのプリマスターシークレットは, 最初の2オクテットを除いて疑似ランダム文字列になります)。この場合, 抽出部分をスキップして, 拡張ステップで IKM を直接 HMAC の鍵として使用できます。一方, アプリケーションは一般的なケースとの互換性のために抽出部分を使用することもできます。特に, IKM がランダム (または疑似ランダム) であるが HMAC 鍵よりも長い場合, 抽出ステップは適切な HMAC 鍵を出力するのに役立ちます (HMAC の場合, 抽出器によるこの短縮は厳密には必要ありません。HMAC は長い鍵でも動作するように定義されているためです)。ただし, TLS with Diffie-Hellman のように IKM が Diffie-Hellman 値である場合は, 抽出部分をスキップすべきではありません。そうすると, Diffie-Hellman 値 g^{xy} 自体 (これは均一にランダムまたは疑似ランダムな文字列ではありません) を HMAC の鍵 PRK として使用することになります。代わりに, HKDF は g^{xy} に抽出ステップを適用し (できればソルト値を使用して), 結果の PRK を拡張部分で HMAC の鍵として使用する必要があります。

必要な鍵ビット数 L が HashLen 以下の場合, PRK を直接 OKM として使用できます。ただし, これは推奨されません。特に, 導出プロセスの一部として 'info' の使用を省略することになるためです (抽出ステップへの入力として 'info' を追加することは推奨されません -- [HKDF-paper] を参照してください)。

3.4. The Role of Independence (独立性の役割)

鍵導出関数の分析は, 入力鍵材料 (IKM) が, 一定の長さのビットストリーム上の確率分布としてモデル化されたソースから来ることを前提としています (たとえば, エントロピープールによって生成されたストリーム, ランダムに選択された Diffie-Hellman 指数から導出された値など)。IKM の各インスタンスは, その分布からのサンプルです。鍵導出関数の主な目標は, (同じ) ソース分布からサンプリングされた任意の2つの値 IKM と IKM' に KDF を適用する場合, 結果の鍵 OKM と OKM' が本質的に互いに独立していることを確保することです (統計的または計算的な意味で)。この目標を達成するには, KDF への入力が適切な入力分布から選択され, 入力が互いに独立して選択されることが重要です (技術的には, 他の KDF 入力を条件としても, 各サンプルが十分なエントロピーを持つ必要があります)。

独立性は, KDF に提供されるソルト値の重要な側面でもあります。ソルトを秘密にしておく必要はなく, 同じソルト値を複数の IKM 値で使用できますが, ソルト値は入力鍵材料から独立していると想定されます。特に, アプリケーションは, ソルト値が攻撃者によって選択または操作されていないことを確認する必要があります。例として, (IKE のように) 鍵交換プロトコルで当事者によって提供されたノンスからソルトが導出される場合を考えてください。プロトコルがそのようなソルトを使用して鍵を導出する前に, これらのノンスが攻撃者によって選択されたものではなく, 正当な当事者から来たものとして認証されていることを確認する必要があります (たとえば IKE では, この認証は認証された Diffie-Hellman 交換の不可欠な部分です)。