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] にて提供されている。

このメモでは、 暗号ペイロードおよび認証ヘッダでの鍵付き認証の仕組みとして、 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] における定義に沿って解釈されるものとする。

基本となる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] で説明されているセキュリティの要求条件に合致するためである。

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

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

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

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

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

[RFC-2104] では、 「実用最低限のハッシュ関数」に対して、 HMACに対して知られている最強の攻撃である「誕生日攻撃」は実行不可能であると説明されている。

HMAC-SHA-1-96のような64バイトのブロックハッシュでは、 基本となるハッシュに2³⁰ブロックを処理した後に衝突があったことが発見されない限り、 2⁸⁰ブロックの処理が必要とされる攻撃は実現不可能である。 このような弱い衝突抵抗特性を持つハッシュは、 利用不可能であると考えるのが一般的である。

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

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

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

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

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

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

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

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

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

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

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