ネットワーク WG
Request for Comments: 2404
分類: スタンダードトラック
C. Madson
Cisco Systems Inc.
R. Glenn
NIST
1998年11月

 

ESP および AH における HMAC-SHA-1-96 の使用法
(The Use of HMAC-SHA-1-96 within ESP and AH)

このメモの位置付け 

この文書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。このメモの配布に制限はない。

著作権表記

Copyright (C) The Internet Society (1998). All Rights Reserved.

要旨

このメモでは、IPSEC 暗号ペイロードの改訂版 [ESP] および IPSEC 認証ヘッダの改訂版 [AH] での認証の仕組みとして、SHA-1 アルゴリズム [FIPS-180-1] と組み合わせた HMAC アルゴリズム [RFC-2104] の使用法について説明する。HMAC-SHA-1 は、データ生成元認証とインテグリティ保護を提供する。

ESP および AH の実装に必要なその他のコンポーネントに関する詳細情報は、[Thayer97a] にて提供されている。

1. はじめに 

このメモでは、暗号ペイロードおよび認証ヘッダでの鍵付き認証の仕組みとして、HMAC [RFC-2104] と組み合わせた SHA-1 [FIPS-180-1] の使用法について定義する。HMAC-SHA-1-96 の目的は、パケットが偽造されたものではなく、配送中に変更ができないことを保証することにある。

HMAC は秘密鍵認証アルゴリズムである。HMAC が提供するデータインテグリティとデータ生成元認証は、秘密鍵の配送範囲に限定される。送信元と宛先のみが HMAC 鍵を知っている場合に、2 つの組織の間で送信されるパケットに対して、データ生成元認証とデータインテグリティが提供される。HMAC が正しければ、それが送信元によって追加されたことが証明される。

このメモでは、HMAC-SHA-1-96 は ESP と AH で使用される。ESP の各部分(機密性の仕組みを含む)がセキュリティサービスの提供のためにどのように相互に結び付くかに関しての詳細については、[ESP] および [Thayer97a] を参照すること。AH の詳細については、[AH] および [Thayer97a] を参照のこと。

この文書において、しなければならない (MUST)、してはならない (MUST NOT)、することになる (SHALL)、することはない (SHALL NOT)、する必要がある (SHOULD)、しないほうがよい (SHOULD NOT)、推奨される (RECOMMENDED)、してもよい (MAY)、選択できる (OPTIONAL) のキーワードが使用された場合は、[RFC-2119] における定義に沿って解釈されるものとする。

2. アルゴリズムとモード 

基本となる SHA-1 アルゴリズムは [FIPS-180-1] に、また HMAC アルゴリズムは [RFC-2104] にて定義される。HMAC アルゴリズムでは、SHA-1 に代表される様々なハッシュアルゴリズムを挿入するためのフレームワークが提供される。

HMAC-SHA-1-96 は 64 バイトのデータブロックで動作する。パディングに関する要求条件は、[FIPS-180-1] において指定され、その条件は SHA-1 アルゴリズムの一部として提供される。SHA-1 が [FIPS-180-1] に従って作成される場合には、HMAC-SHA-1-96 ではこれに追加してパディングをする必要はない。[AH] で定義される「暗黙的パケットパディング」は、ここでは必要とされない。

HMAC-SHA-1-96 は 160 ビットの認証値を生成する。この 160 ビットの値は、RFC2104 に定義されているように、後ろの部分を切詰めて省略することが可能である。ESP または AH のどちらで使用する場合でも、最初の 96 ビットに省略された値をサポートしなければならない (MUST)。送信時には、この省略された値が認証子フィールドに保存される。受信時には、160 ビットの値全体が計算され、その最初の 96 ビットと認証子フィールドに保存された値が比較される。
HMAC-SHA-1-96 ではその他の認証値サイズをサポートしない。

96 ビットの長さが選択された理由は、これが [AH] で指定されているデフォルトの認証子の長さであり、[RFC-2104] で説明されているセキュリティの要求条件に合致するためである。

2.1 性能 

[Bellare96a] では、「(HMACの)性能は本質的に、その基本となるハッシュ関数による」と説明されている。この文書の執筆時点では、SHA-1、HMAC、および HMAC-SHA-1 に対しての性能の分析は行われていない。

[RFC-2104] では、相互接続性に影響することなくパケット単位での性能を改善できる、実装時における修正について説明されている。

3. 鍵素材 

HMAC-SHA-1-96 は秘密鍵アルゴリズムである。[RFC-2104] では固定鍵長について指定されていないが、ESP または AH のどちらで使用する場合でも、160 ビットの固定鍵長をサポートしなければならない (MUST)。160 ビット以外の鍵長をサポートしてはならない (MUST NOT) (つまり、160 ビットの鍵のみが HMAC-SHA-1-96 で使用されることになる)。160 ビットの鍵長は、[RFC-2104] の勧告(すなわち、認証子長より短い鍵長はセキュリティ強度を低下させ、認証子長より長い鍵はセキュリティ強度を大幅に向上させることはない)を基に選ばれている。

[RFC-2104] では鍵素材に関する要求条件について取り上げられており、それには強力な無作為性に関する要求条件についての議論が含まれている。要求される 160 ビットの鍵を生成するためには、強力な疑似乱数関数を使用しなければならない (MUST)

この文書の執筆時点では、HMAC で使用する際の脆弱鍵は特にない。しかし、これは、脆弱鍵が存在しないということを意味するものではない。ある点で、HMAC の脆弱鍵のセットが発見された場合、これらの鍵の置き換えの要求や新たに取り決められたセキュリティアソシエーションに従って、これらの鍵の使用を拒否しなければならない。

[ARCH] では、1 つの SA に対して複数の鍵が要求された場合の、鍵素材の取得に関する一般的な仕組みについて説明されている(例えば、ESP SA が機密性のための鍵と認証のための鍵を要求する場合)。

データ生成元認証を提供するために、一意に鍵が割り当てられ、それが通信を行っている当事者にのみ配送されることが、鍵配送の仕組みによって保証されなければならない。

[RFC-2104] では、鍵の再生成に関して次のように勧告されている。既存の攻撃は実際には実行不可能であるため、ある特定の鍵の推奨変更頻度は示せない。
しかし、定期的な鍵の取り替えは、その関数と鍵の潜在的弱点を補うものであり、暗号解析者が利用できる情報を減らし、開示された鍵の損害を制限する、基本的なセキュリティ対策である。

4. ESP 暗号メカニズムとの影響 

この文書の執筆時点では、特定の暗号アルゴリズムとともに HMAC-SHA-1-96 アルゴリズムを使用することを妨げる問題は知られていない。

5. セキュリティについての考慮事項 

HMAC-SHA-1-96 によって提供されるセキュリティは、HMAC の強度、およびほんのわずかであるが SHA-1 の強度がもととなっている。この文書の執筆時点では、HMAC-SHA-1-96 に対する実際の暗号攻撃は存在しない。

[RFC-2104] では、「実用最低限のハッシュ関数」に対して、HMAC に対して知られている最強の攻撃である「誕生日攻撃」は実行不可能であると説明されている。
HMAC-SHA-1-96 のような 64 バイトのブロックハッシュでは、基本となるハッシュに 2**30 ブロックを処理した後に衝突があったことが発見されない限り、2**80 ブロックの処理が必要とされる攻撃は実現不可能である。このような弱い衝突抵抗特性を持つハッシュは、利用不可能であると考えるのが一般的である。

さらに、SHA-1 が鍵付ハッシュアルゴリズムとして使用されるために開発されていないのに対し、HMAC は始めからこの考えに沿っていることを考慮することが重要である。

[RFC-2104] ではまた、生じたハッシュの省略によって追加される、潜在的なセキュリティについて取り上げられている。HMAC を含む仕様では、このハッシュの省略を実行することが強く推奨されている。

[RFC-2104] で HMAC に様々なハッシュアルゴリズムを取り込むためのフレームワークが提供されているように、SHA-1 を MD5 などの他のアルゴリズムに置き換えることが可能である。[RFC-2104] には、HMAC アルゴリズムの強度と弱点に関する詳細な議論が含まれている。

あらゆる暗号化アルゴリズムで真実であるように、HMAC の強度の一部は、アルゴリズムの実装の正確さ、鍵管理の仕組みのセキュリティとその実装、使用される秘密鍵の強度、および通信するすべてのシステムにおける実装の正確さにかかっている。[RFC-2202] には、HMAC-SHA-1-96 コードの正確さを確認するためのテストベクトルとサンプルコードが含まれている。

6. 謝辞 

この文書は、Jim Huges と DES/CBC と HMAC-MD5 の組み合わせ ESP 変換に関して Jim Hughes と作業した人々、ANX ベイクオフ参加者、そして、IPsec ワーキンググループのメンバーによるこれまでの作業の一部を参考としている。

この文書の暗号に関する文章についてコメントを提供してくれた Hugo Krawczyk に感謝する。

7. 参考文献 

[FIPS-180-1]  NIST, FIPS PUB 180-1: Secure Hash Standard, 1995年 4月. http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
 
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, 
「HMAC: メッセージ認証のための鍵付ハッシング(HMAC: Keyed-Hashing for Message Authentication)」, 
RFC 2104
, 1997年 2月.
 
[Bellare96a]  Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash Functions for Message Authentication", Advances in Cryptography, Crypto96 Proceeding, 1996年 6月.
 
[ARCH] Kent, S., and R. Atkinson, 
「インターネットプロトコルのためのセキュリティアーキテクチャ(Security Architecture for the Internet Protocol)」, 
RFC 2401
, 1998年 11月.
 
[ESP] Kent, S., and R. Atkinson, 
「IP 暗号ペイロード(ESP)(IP Encapsulating Security Payload)」, 
RFC 2406
, 1998年 11月.
 
[AH] Kent, S., and R. Atkinson, 
「IP 認証ヘッダ(IP Authentication Header)」, 
RFC 2402
, 1998年 11月.
 
[Thayer97a] Thayer, R., Doraswamy, N., and R. Glenn, 
「IPSEC 文書ロードマップ(IP Security Document Roadmap)」, 
RFC 2411
, 1998年 11月.
 
[RFC-2202] Cheng, P., and R. Glenn, 
「HMAC-MD5 と HMAC-SHA-1 のためのテストケース(Test Cases for HMAC-MD5 and HMAC-SHA-1)」, 
RFC 2202
, 1997年 3月.
 
[RFC-2119] Bradner, S., 
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」, 
BCP 14, RFC 2119, 1997年 3月.

8. 著者のアドレス

Cheryl Madson
Cisco Systems, Inc.

EMail: cmadson@cisco.com
 

Rob Glenn
NIST

EMail: rob.glenn@nist.gov

IPsec ワーキンググループへは、以下のチェアを介してコンタクトをとることが可能である。

Robert Moskowitz
ICSA

EMail: rgm@icsa.net
 

Ted T'so
Massachusetts Institute of Technology

EMail: tytso@mit.edu
 

翻訳者のアドレス

株式会社 NTTデータ
開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

9.著作権表記全文 

Copyright (C) The Internet Society (1998). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。