RFC翻訳: HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

Abstract

この文書は、様々なプロトコルやアプリケーションの構成要素として使用できる、シンプルなハッシュメッセージ認証コード (HMAC;Hashed Message Authentication) ベースの鍵導出関数 (HKDF) を規定する。鍵導出関数 (KDF) は広範なアプリケーション要件をサポートすることを意図しており、暗号論的ハッシュ関数を使用する点では保守的である。

Status of This Memo

この文書は Internet Standards Track 仕様ではなく、情報提供を目的として公開されている。

この文書は Internet Engineering Task Force (IETF) の成果物である。これは IETF の総意を表している。この文書は公開レビューを受け Internet Engineering Steering Group (IESG) によって公開が承認されている。IESG によって承認されたすべての文書がインターネット標準の候補となるわけではない。RFC 5741 のセクション 2 を参照。

この文書の現在の状態、正誤表、およびそれに対するフィードバックの提供方法に関する情報は http://www.rfc-editor.org/info/rfc5869 で入手できる。

Table of Contents

1. Abstract
2. Status of This Memo
3. Copyright Notice
4. 1. 導入
5. 2. HMAC ベースの鍵導出関数 (HKDF)
   1. 2.1 表記
   2. 2.2 Step 1: 抽出
   3. 2.3 Step 2: 展開
6. 3. HKDF ユーザへの注意
   1. 3.1 Salt を使うべきか否か
   2. 3.2 HKDF への info 入力
   3. 3.3 スキップするか否か
   4. 3.4 独立性の役割
7. 4. HKDF の応用
8. 5. セキュリティ考察
9. 6. Acknowledgements
10. 7. References
    1. 7.1 Normative References
    2. 7.2 Informative References
11. 翻訳抄

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 導入

鍵導出関数 (KDF) は暗号システムの基本的かつ不可欠な構成要素である。KDF の目的は、初期鍵素体のあるソースを取得し、そこから 1 つ以上の暗号論的に強力な秘密鍵を導出することである。

この文書では HKDF という名前の HMAC ベース [HMAC] のシンプルな KDF を規定する。この KDF は様々なプロトコルやアプリケーションの構成要素として使用でき、既に [IKEv2], [PANA], [EAP-AKA] などの IEFT プロトコルで使用されている。この KDF を一般的な方法で文書化する目的は将来のプロトコルやアプリケーションでの採用を容易にし、複数の KDF メカニズムの拡散を抑制することである。この KDF は既存のプロトコルの変更呼びかけを意図したものではなく、KDF を使用する既存の仕様を変更または更新するものではない。

HKDF は "extract-then-expand" (抽出し展開する) というパラダイムにしたがっており、KDF は論理的に 2 つのモジュールで構成される。第 1 段階は入力された鍵素体を受け取り、そこから固定長疑似乱数鍵 \(K\) を "抽出" する。第 2 段階は鍵 \(K\) をいくつかの追加疑似乱数鍵 (KDF の出力) に "展開" する。

多くのアプリケーションにおいて、入力された鍵素体は必ずしも均一に分散しているとは限らず、攻撃者はそれに関する部分的な知識 (例えば鍵交換プロトコルで算出された Diffie-Hellman 値など) を持っていたり、(エントロピー収集アプリケーションのように) それを部分的に制御している可能性がある。したがって "抽出" 段階の目的は入力された鍵素体の分散している可能性のあるエントロピーを、短い暗号学的に強力な擬似ランダム鍵に "集中" することである。一部のあろうケーションでは入力が既に適切な疑似乱数鍵になっている場合がある。このような場合は "抽出" 段階は必要なく "展開" 部分のみを使用することができる。

第 2 段階では疑似乱数鍵を必要な長さに "展開" する。出力される鍵の数と長さは鍵が必要とする特定の暗号アルゴリズムに依存する。

NIST Special Publication 800-56A [800-56A], NIST Special Publication 800-108 [800-108], IEEE Standard 1363a-2004 [1363a] など、既存の KDF 仕様の中には第 2 段階 (疑似乱数鍵の展開) のみを考慮している点に注意。あるいは "抽出" 段階と "展開" 段階を明確に区別しないため多くの場合で設計上の欠陥が生じる。この使用の目的は、基礎となるハッシュ関数に関する過程を最小に抑えながら幅広い KDF 要件に対応することである。"extract-then-expand" パラダイムはこの目標を十分にサポートしている (設計理論的根拠の詳細については [HKDF-paper] を参照)。

2. HMAC ベースの鍵導出関数 (HKDF)

2.1 表記

HMAC-Hash はハッシュ関数 'Hash' でインスタンス化された HMAC 関数 [HMAC] を示す。HMAC は常に 2 つの引数を取る。1 つ目は鍵、2 つ目は入力 (またはメッセージ) である。(抽出段階では 'IKM' が HMAC 鍵ではなく HMAC 入力として使用されることに注意。)

メッセージが複数の要素で構成されている場合、第二引数に (| で示す) 連結を使用する。例えば HMAC(\(K\), elem1 | elem2 | elem3) である。

この文書における "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は [KEYWORDS] に記述されているように解釈される。

2.2 Step 1: 抽出

\(\mbox{HKDF-Extract}({\rm salt}, {\rm IKM}) = {\rm PRK}\)

出力の \({\rm PRK}\) は次のように算出される: \[ {\rm PRK} = \mbox{HMAC-Hash}({\rm salt}, {\rm IKM}) \]

2.3 Step 2: 展開

\(\mbox{HKDF-Expand}({\rm PRK}, {\rm info}, L) = {\rm OKM}\)

出力の \({\rm OKM}\) は次のように算出される: \[ \begin{eqnarray*} N & = & {\rm ceil}(L/{\rm HashLen}) \\ T & = & T(1) | T(2) | T(3) | \ldots | T(N) \\ {\rm OKM} & = & \mbox{first $L$ octets of $T$} \\ \end{eqnarray*} \] ここで: \[ \begin{eqnarray*} T(0) & = & \mbox{empty string (zero length)} \\ T(1) & = & \mbox{HMAC-Hash}({\rm PRK}, T(0)\,|\,{\rm info}\,|\,{\tt 0x01}) \\ T(2) & = & \mbox{HMAC-Hash}({\rm PRK}, T(1)\,|\,{\rm info}\,|\,{\tt 0x02}) \\ T(3) & = & \mbox{HMAC-Hash}({\rm PRK}, T(2)\,|\,{\rm info}\,|\,{\tt 0x03}) \\ \vdots & & \\ \end{eqnarray*} \] (ここで各 \(T(n)\) の末尾に連結される定数は単一オクテットである。)

3. HKDF ユーザへの注意

このセクションでは HKDF の使用に関する一連の指針が含まれている。このような原理と設計理論的根拠についてのさらに広範な説明は [HKDF-paper] を参照。

3.1 Salt を使うべきか否か

HKDF はランダム Salt の有無にかかわらず動作するように定義されている。これは Salt 値が利用できないアプリケーションに対応するためである。ただし、Salt を使用することでハッシュ関数の様々な用途間の独立性が確立され、"source-independent" 抽出が可能となり、HKDF の設計を裏付ける分析結果が強化されるため HKDF の強度が大幅に向上することを強調する。

ランダム Salt は 2 つの点、つまり秘密ではないことと再利用できる点で最初の鍵素体と根本的に異なる。そのため Salt 値は多くのアプリケーションで利用できる。たとえば再生可能なエントロピープール (サンプリングされたシステムイベントなど) に HKDF を適用して継続的に出力を生成する疑似乱数生成器 (PRNG) は、Salt 値を固定しその秘密を保護することなく HKDF の複数のアプリケーションに使用できる。別の応用分野では、Diffie-Hellman 交換から暗号鍵を導出する鍵号合意プロトコルは鍵合意の一部として通信当事者間で交換および認証されたパブリック nonce から Salt 値を導出できる (これは [IKEv2] で採用されているアプローチである)。

理想的には Salt 値は長さ \({\rm HashLen}\) のランダム (または擬似ランダム) 列である。ただし Salt 値の品質が低い (サイズが短い、またはエントロピーが制限されている) 場合であっても出力される鍵素体のセキュリティに大きく貢献する可能性がある。したがってアプリケーションの設計者は HKDF に Salt 値を提供することが推奨される。

典型的なケースではないがアプリケーションによっては使用可能な秘密の Salt があるケースもある。このような場合、HKDF はさらに強力なセキュリティ保証を提供する。このようなアプリケーションの例は "public-key encryption mode" の IKEv1 であり、このモードでは抽出器に対する "Salt" は秘密の nonce から計算される。同様に IKEv1 の pre-shared mode では事前共有鍵に由来する秘密の Salt を使用する。

3.2 HKDF への info 入力

HKDF の定義では 'info' 値はオプションだがアプリケーションでは非常に重要であることが多い。この値の主な目的は、派生した鍵素体をアプリケーション固有およびコンテキスト固有の情報と結びつけることである。例えば 'info' にはプロトコル番号、アルゴリズム識別子、ユーザ ID などを含めることができる。特に (同じ入力鍵素体 (IKM) が異なるコンテキストで使用される場合に) 異なるコンテキストで同じ鍵素体が導出されることを防ぐことができる。また、必要に応じて鍵展開部への追加入力に対応することもできる (例えばアプリケーションが鍵素体をその長さ \(L\) に束縛したければ \(L\) を 'info' フィールドの一部にする)。'info' には一つの技術的要求がある。それは入力の鍵素体 IKM から独立していることである。

3.3 スキップするか否か

アプリケーションによっては入力鍵素体 IKM が既に暗号論的に強力な鍵として存在していることがある (例えば TLS RSA 暗号スイートにおけるプレマスターシークレットは最初の 2 オクテットを除いて擬似ランダム列となる)。このような場合は抽出部分をスキップし IKM を直接 HMAC の鍵に使用することができる。一方でアプリケーションは一般的なケースとの互換性を維持するために抽出部分を使用することができる。特に、KIM がランダム (または擬似ランダム) であっても HMAC 鍵より長い場合には抽出ステップは適切な HMAC 鍵を出力する役割を果たす (HMAC の場合、HMAC は長い鍵でも動作するように定義されているため抽出器を介したこの短縮は厳密には必要ない)。ただし Diffie-Hellman を使用する TLS の場合のように、IKM が Diffie-Hellman 値である場合は抽出部分をスキップすべきではないことに注意。これを行うと (一様乱数または疑似乱数列ではない) Diffie-Hellman 値 \(g^{xy}\) 自体を HMAC の鍵 PRK として使用することになる。代わりに HKDF は \(g^{xy}\) に抽出ステップを適用し (Salt 値を使用することが望ましい)、その結果の PRK を展開部分で HMAC の鍵として使用すべきである。

必要な鍵ビットの量 \(L\) が \({\rm HashLen}\) 以下の場合、PRK を OKM として直接使用することもできる。しかしこれは推奨されない。特に、導出プロセスの一部として 'info' の仕様が省略されるためである (抽出ステップへの入力として 'info' を追加することは推奨されない -- [HKDF-paper] 参照)。

3.4 独立性の役割

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

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

4. HKDF の応用

HKDF はさまざまな HKDF アプリケーションでの使用を目的としている。例えば不完全な乱数源 (物理乱数生成器 (RNG) など) からの疑似乱数生成器の構築、システムイベントのユーザーのキー入力などから収集したエントロピーなどの弱い乱数発生源からの疑似乱数の生成、鍵合意プロトコルの共有 Diffie-Hellman 値からの暗号鍵の導出、ハイブリッド公開暗号方式からの共通鍵の導出、キーラッピング機構の鍵導出などが含まれる。これらのアプリケーションはすべて HKDF の単純さと多目的性、そして分析基盤からの恩恵を受けることができる。

一方、特定の運用要件により HKDF を "そのまま" 使用できないアプリケーションや、使用できてもスキームの利点を十分に活用できないアプリケーションもあると予想される。重要な例の 1 つは、ユーザパスワードなどエントロピーの低いソースから暗号鍵を導出する場合である。HKDF の抽出ステップではエントロピーを集中できるがエントロピーを増幅することはできない。パスワードベースの HKDF の場合の主な目的は、Salt 値と鍵の導出関数を意図的に遅くするという 2 つの要素を使用して、辞書攻撃を遅くすると言うことである。HKDF は Salt の仕様に当然対応している。しかし速度低下メカニズムはこの仕様には含まれていない。パスワードベースの KDF に関心のあるアプリケーションは、例えば [PKCS5] が HKDF よりもニーズを満たしているかを検討すべきである。

5. セキュリティ考察

HKDF はその単純さにもかかわらず、この構造の設計と解析では多くのセキュリティ上の効力事項が多くある。これらすべての側面の説明はこの文書の範囲を超えている。設計の根拠やセクション 3 に示すガイドラインなどの詳細情報については [HKDF-paper] を参照。

上記の論文 [HKDF-paper] では、暗号ハッシュ関数を使用する方法に細心の注意を払った多目的 KDF として HKDF の暗号化分析を提供するために大きな努力を払ってきた。これは、現在のハッシュ関数の強度に対する信頼性が限られているため特に重要である。ただし、この分析はスキームの絶対的に安全であると言うことを意味するものではなく、基礎となるハッシュ関数の強度とモデリングの選択に大きく依存する。それでも、これは HKDF 設計の正しい構造と、他の一般的な KDF スキームに対する HKDF の利点を強く示すものとして機能する。

6. Acknowledgements

The authors would like to thank members of the CFRG (Crypto Forum Research Group) list for their useful comments, and to Dan Harkins for providing test vectors.

7. References

7.1 Normative References

1. [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
2. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
3. [SHS] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.

7.2 Informative References

4. [1363a] Institute of Electrical and Electronics Engineers, "IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", IEEE Std 1363a-2004, 2004.
5. [800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, November 2008.
6. [800-56A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007.
7. [EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009.
8. [HKDF-paper] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 (to appear), 2010, <http://eprint.iacr.org/2010/264>.
9. [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
10. [PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
11. [PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.

翻訳抄

ある秘密鍵に基づいて複数の鍵を生成するスキームを規定している RFC 5869 についての仕様文書。

1. KRAWCZYK, Hugo; ERONEN, Pasi. HMAC-based extract-and-expand key derivation function (HKDF). 2010.