HKDF
RFC 5869 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) HKDF(HMAC(MessageDigest()))
RFC 8619 the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) のアルゴリズム識別子
RFC 5869
HMAC ベースの抽出および展開鍵導出関数 (HKDF)
概要
この文書は、様々なプロトコルやアプリケーションの構成要素として利用可能な、シンプルなハッシュメッセージ認証コード（HMAC）ベースの鍵導出関数（HKDF）を規定するものです。鍵導出関数（KDF）は、幅広いアプリケーションと要件をサポートすることを目的としており、暗号学的ハッシュ関数の使用に関しては保守的です。
1. はじめに
鍵導出関数（KDF）は、暗号システムの基本的かつ不可欠な構成要素です。その目的は、初期鍵素材を取得し、そこから1つ以上の暗号的に強力な秘密鍵を導出することです。 本文書では、HKDFと呼ばれる、HMACベースのシンプルな KDFを規定します。HKDFは、様々なプロトコルやアプリケーションの構成要素として使用可能であり、IKEv2、PANA、EAP-AKAなど、いくつかのIETFプロトコルで既に使用されています。本文書の目的は、このKDFを一般的な方法で文書化し、将来のプロトコルやアプリケーションへの採用を容易にし、複数のKDFメカニズムの普及を抑制することです。これは、既存のプロトコルの変更を意図したものではなく、このKDFを使用して既存の仕様を変更または更新するものでもありません。 HKDFは「抽出してから展開する(extract-then-expand)」パラダイムに従っており、KDFは論理的に2つのモジュールで構成されます。第一段階では、入力鍵素材を受け取り、そこから固定長の擬似ランダム鍵 K を「抽出(extracts)」します。第二段階では、鍵 K を複数の追加の擬似ランダム鍵（KDF の出力）に「拡張(expands)」します。
多くのアプリケーションでは、入力鍵素材は必ずしも均一に分散されているわけではなく、攻撃者は鍵素材について部分的に知識を持っている場合（例えば、鍵交換プロトコルによって計算された Diffie-Hellman 値など）、あるいは部分的に制御している場合（一部のエントロピー収集アプリケーションなど）があります。したがって、「抽出」段階の目的は、入力鍵素材の分散している可能性のあるエントロピーを、短いながらも暗号的に強力な擬似ランダム鍵に「集中」することです。アプリケーションによっては、入力鍵が既に良好な擬似ランダム鍵である場合があり、そのような場合は「抽出」段階は不要であり、「拡張」段階のみを使用できます。
第二段階では、擬似ランダム鍵を必要な長さに「拡張」します。出力鍵の数と長さは、鍵が必要となる暗号アルゴリズムによって異なります。
NIST Special Publication 800-56A 800-56A、NIST Special Publication 800-108 800-108、IEEE Standard 1363a-2004 1363a などの既存のKDF仕様では、第2段階（擬似乱数鍵の展開）のみを考慮しているか、「抽出」段階と「展開」段階を明確に区別していないため、設計上の欠陥が生じることがよくあります。本仕様の目標は、基盤となるハッシュ関数に関する仮定を最小限に抑えながら、幅広いKDF要件に対応することです。「抽出してから展開する」パラダイムは、この目標を十分にサポートしています（設計根拠の詳細については、HKDF論文 を参照してください）。 2. HMACベースの鍵導出関数 (HKDF)
2.1. 表記法
HMAC-Hashは、ハッシュ関数「Hash」でインスタンス化されたHMAC関数HMACを表します。HMACは常に2つの引数を持ちます。1つ目は鍵、2つ目は入力（またはメッセージ）です。（抽出ステップでは、「IKM」はHMAC鍵ではなくHMAC入力として使用されることに注意してください。） メッセージが複数の要素で構成されている場合、2つ目の引数では連結（|で表記）を使用します。例：HMAC(K, elem1 | elem2 | elem3)
この文書におけるキーワード「しなければならない（MUST）」、「してはならない（MUST NOT）」、「必須（REQUIRED）」、「するものとする（SHALL）」、「するべきではない（SHALL NOT）」、「すべきである（SHOULD）」、「すべきでない（SHOULD NOT）」、「推奨される（RECOMMENDED）」、「してもよい（MAY）」、「任意（OPTIONAL）」は、キーワード で説明されているとおりに解釈されます。 2.2. ステップ 1: 抽出: Extract
HKDF-Extract(salt, IKM) -> PRK
オプション:
Hash ハッシュ関数; アルゴリズム識別子(OBJECTIDENTIFIER)で指定したものなど
HashLen はハッシュ関数の出力の長さ（オクテット単位）を表します。
入力:
salt オプションの salt 値（秘密ではないランダム値）。
指定されていない場合は、HashLen がゼロの文字列に設定されます。
IKM 入力鍵素材
出力:
PRK 疑似ランダム鍵（HashLen オクテット単位）
出力 PRK は次のように計算されます。
PRK = HMAC-Hash(salt, IKM)
2.3 ステップ2: 展開 Expand
HKDF-Expand(PRK, info, L) -> OKM
オプション
Hash: ハッシュ
HashLen: ハッシュの出力長
入力
PRK HashLenの長さの擬似ランダム鍵(pseudorandom key) 通常 抽出ステップの出力
info オプションのcontextとアプリケーション定義情報 サイズ0可
L 鍵の出力長
出力:
OKM 出力鍵素材 (長さL)
出力 OKM は次のように計算されます:
N = ceil(L/HashLen) = (L + HashLen - 1) / HashLen
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = Tの先頭L オクテット
where:
T(0) = 空文字(長さ0)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)
...
HMACの出力T(x)を必要な長さまで繋げたもの
3. HKDF利用者への注意
このセクションでは、HKDFの使用に関する一連のガイドラインを示します。これらのガイドラインと設計根拠に関するより詳細な説明は、HKDF論文に記載されています。 3.1. ソルトの有無
HKDFは、ランダムソルトの有無にかかわらず動作するように定義されています。これは、ソルト値が利用できないアプリケーションに対応するためです。
しかしながら、ソルトの使用はHKDFの強度を大幅に高め、ハッシュ関数の異なる用途間の独立性を確保し、「ソース非依存」な抽出をサポートし、HKDFの設計を裏付ける解析結果を強化することを強調しておきます。
ランダムソルトは、初期の鍵素材とは2つの点で根本的に異なります。それは、秘密ではなく、再利用可能であることです。そのため、ソルト値は多くのアプリケーションで利用可能です。例えば、再生可能なエントロピープール（例えば、サンプリングされたシステムイベント）にHKDFを適用することで継続的に出力を生成する疑似乱数生成器（PRNG）は、ソルト値を固定し、ソルトの秘密性を保護することなく、HKDFの複数の用途で使用することができます。別のアプリケーションドメインでは、Diffie-Hellman交換から暗号鍵を導出する鍵合意プロトコルは、鍵合意の一環として通信当事者間で交換・認証された公開ノンスからソルト値を導出することができます（これはIKEv2で採用されているアプローチです）。 理想的には、ソルト値は長さHashLenのランダム（または擬似ランダム）文字列です。しかし、ソルト値の品質が低い（サイズが短い、またはエントロピーが限られている）場合でも、出力鍵素材のセキュリティに大きく貢献する可能性があります。したがって、アプリケーション設計者は、ソルト値をアプリケーションが取得できる場合は、HKDFにソルト値を提供することが推奨されます。
典型的なケースではありませんが、一部のアプリケーションでは秘密のソルト値を使用できる場合もあります。このような場合、HKDFはさらに強力なセキュリティ保証を提供します。このようなアプリケーションの例としては、IKEv1の「公開鍵暗号化モード」が挙げられます。このモードでは、抽出器への「ソルト」は秘密のノンスから計算されます。同様に、IKEv1 の事前共有モードでは、事前共有キーから派生した秘密ソルトが使用されます。
3.2. HKDFへの「info」入力
「info」値はHKDFの定義ではオプションですが、アプリケーションでは多くの場合非常に重要になります。その主な目的は、導出された鍵素材をアプリケーションおよびコンテキスト固有の情報に結び付けることです。例えば、「info」にはプロトコル番号、アルゴリズム識別子、ユーザーIDなどが含まれます。特に、異なるコンテキストで同じ鍵素材が導出されるのを防ぐことができます（異なるコンテキストで同じ入力鍵素材（IKM）が使用される場合）。また、必要に応じて、鍵拡張部への追加入力にも対応できます（例えば、アプリケーションが鍵素材をその長さLに結び付け、Lを「info」フィールドの一部にしたい場合など）。「info」には1つの技術的な要件があります。それは、入力鍵素材値IKMとは独立している必要があるということです。
3.3. スキップするか否か
一部のアプリケーションでは、入力鍵素材IKMが暗号学的に強力な鍵として既に存在している場合があります（例えば、TLS RSA暗号スイートのプレマスターシークレットは、最初の2オクテットを除いて擬似ランダム文字列です）。この場合、抽出部分をスキップし、展開ステップでIKMを直接使用してHMAC鍵を生成できます。一方、アプリケーションは、一般的なケースとの互換性を確保するために、抽出部分を使用することもできます。特に、IKMがランダム（または擬似ランダム）であるものの、HMAC鍵よりも長い場合、抽出ステップは適切なHMAC鍵を出力するのに役立ちます（HMACの場合、HMACは長い鍵でも動作するように定義されているため、抽出器によるこの短縮は厳密には不要です）。ただし、Diffie-Hellmanを使用するTLSの場合のように、IKMがDiffie-Hellman値である場合は、抽出部分をスキップしないでください。そうすると、Diffie-Hellman値 g^{xy} 自体（一様ランダムまたは疑似ランダム文字列ではない）がHMACの鍵PRKとして使用されることになります。
代わりに、HKDFは g^{xy} に抽出ステップを適用し（できればソルト値を使用）、その結果得られたPRKを拡張部におけるHMACの鍵として使用する必要があります。
必要な鍵ビット数LがHashLen以下の場合、PRKを直接OKMとして使用できます。ただし、これは推奨されません。特に、導出プロセスの一部として「info」の使用が省略されるためです（また、「info」を抽出ステップの入力として追加することは推奨されません。HKDF論文を参照）。 3.4. 独立性の役割
鍵導出関数の解析では、入力鍵素材（IKM）が、ある長さのビットストリーム（例えば、エントロピープールによって生成されたストリーム、ランダムに選択されたDiffie-Hellman指数から導出された値など）上の確率分布としてモデル化された何らかの情報源から得られるものと仮定します。各IKMインスタンスは、その分布からのサンプルです。鍵導出関数の主な目標は、（同一の）情報源分布からサンプリングされた任意の2つの値IKMとIKM'にKDFを適用した際に、結果として得られる鍵OKMとOKM'が（統計的または計算的な意味で）本質的に互いに独立していることを保証することです。この目標を達成するには、KDFへの入力が適切な入力分布から選択され、かつ入力が互いに独立して選択されることが重要です（技術的には、KDFへの他の入力を条件とする場合であっても、各サンプルが十分なエントロピーを持つ必要があります）。
独立性も、KDF に提供されるソルト値の重要な側面です。ソルトを秘密にする必要はなく、同じソルト値を複数の IKM 値で使用できますが、ソルト値は入力鍵素材から独立していると想定されています。特に、アプリケーションは、ソルト値が攻撃者によって選択または操作されないようにする必要があります。例として、ソルトが鍵交換プロトコルの当事者によって提供された nonce から導出されるケース (IKE など) を考えてみましょう。プロトコルがこのようなソルトを使用して鍵を導出する前に、これらの nonce が攻撃者によって選択されたものではなく、正当な当事者からのものであることが認証されていることを確認する必要があります (IKE では、たとえばこの認証は、認証された Diffie-Hellman 交換の不可欠な部分です)。
4. HKDFの応用
HKDFは、様々なKDFアプリケーションでの使用を想定しています。これには、不完全な乱数源（物理乱数生成器（RNG）など）からの疑似乱数生成器の構築、システムイベントやユーザーのキー入力などから収集されたエントロピーなどの弱い乱数源からの疑似乱数生成、鍵合意プロトコルにおける共有Diffie-Hellman値からの暗号鍵の導出、ハイブリッド公開鍵暗号化方式からの対称鍵の導出、鍵ラッピング機構のための鍵導出などが含まれます。これらのアプリケーションはすべて、HKDFのシンプルさと多目的性、そしてその分析的基盤の恩恵を受けることができます。
一方で、特定の運用要件により、一部のアプリケーションではHKDFを「そのまま」使用できない、あるいは使用できてもその利点を十分に活用できないことが予想されます。重要な例としては、ユーザーのパスワードなど、エントロピーの低い情報源から暗号鍵を導出することが挙げられます。HKDFの抽出ステップでは、既存のエントロピーを集中させることはできますが、エントロピーを増幅させることはできません。パスワードベースのKDFの場合、主な目標は、ソルト値と鍵導出計算の意図的な遅延という2つの要素を用いて辞書攻撃を減速させることです。HKDFはソルトの使用を自然にサポートしますが、減速メカニズムはこの仕様には含まれていません。パスワードベースのKDFに関心のあるアプリケーションは、例えばPKCS5がHKDFよりもニーズを満たすかどうかを検討する必要があります。 5. セキュリティに関する考慮事項
HKDFはシンプルですが、その設計と解析においては、多くのセキュリティ上の考慮事項が考慮されています。これらの側面すべてを説明することは、本文書の範囲を超えています。設計の根拠やセクション3で示したガイドラインを含む詳細については、HKDF論文を参照してください。 上記の論文HKDF論文では、暗号ハッシュ関数の利用方法に細心の注意を払った多目的KDFとしてのHKDFの暗号学的解析を提供することに多大な努力が払われました。これは、現在のハッシュ関数の強度に対する信頼度が限られているため、特に重要です。ただし、この解析は、いかなる方式の絶対的な安全性を意味するものではなく、基礎となるハッシュ関数の強度とモデルの選択に大きく依存します。それでもなお、HKDF設計の正しい構造と、他の一般的なKDF方式に対するその利点を強く示唆しています。 6. 謝辞
著者は、有益なコメントをいただいたCFRG（Crypto Forum Research Group）メーリングリストのメンバー、およびテストベクトルを提供してくださったDan Harkins氏に感謝の意を表します。
以下略
----
RFC 8619
id-alg-hkdf-with-sha256
1.2.840.113549.1.9.16.3.28
id-alg-hkdf-with-sha384
1.2.840.113549.1.9.16.3.29
id-alg-hkdf-with-sha512
1.2.840.113549.1.9.16.3.30