JP4980785B2 - 暗号通信装置、暗号通信方法 - Google Patents

Description

本発明は、暗号通信装置、暗号通信方法に係り、特に少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置、暗号通信方法に関する。

ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）レベルの通信では、暗号化，内容の認証等の処理を行うＩＰセキュリティに必要な暗号鍵の設定が従来から行われている。このような暗号鍵は、セキュリティ上の問題から同じ暗号鍵を長時間使用せず、ＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）等の自動鍵交換プロトコルを利用して頻繁に交換することが一般的である（例えば特許文献１参照）。

近年では、ＩＰｓｅｃ（Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ＩＰ）やＩＰｖ６（ＩＰ ｖｅｒｓｉｏｎ ６）を利用した暗号通信において、暗号通信をはじめる前に暗号化方式，相手認証方式，暗号鍵などの情報を交換・共有し、安全な通信路を確立するセキュリティアソシエーション（以下、ＳＡと呼ぶ）が知られるようになった。

ＩＰｓｅｃとはインターネットで暗号通信を行うための規格である。ＩＰｓｅｃはＩＰレベルでパケットを暗号化して送受信する。従って、ＴＣＰ／ＵＤＰなどの上位のプロトコルを利用するアプリケーションでは、ＩＰｓｅｃが使われていることを意識しなくてもよい。ＩＰｓｅｃにおけるＳＡは、ＩＫＥの標準手順に従って、暗号化方式の決定，暗号鍵の交換，相手認証が行われる。
特開２００１−７８０３号公報

例えばＩＰｓｅｃにおけるＳＡでは、相手認証方式としてＰＳＫ（Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ：事前共有鍵）が利用される。相手認証方式がＰＳＫの場合、相手認証は事前に暗号通信を行う両ノードで共有している文字列（以下、ＰＳＫ文字列と呼ぶ）から生成した暗号鍵を利用して行われる。即ち、相手認証の成功は、両ノード間でＰＳＫ文字列が一致していることが必要条件となる。

しかしながら、ＰＳＫ文字列に対して両ノードで使用している文字コードが異なる場合は表示上、同じＰＳＫ文字列からでも異なる暗号鍵が生成されてしまい、相手認証に失敗してしまうという問題があった。なお、使用する文字コードについては規約上の取り決めが無く、プラットフォームやアプリケーションに依存する。また、一般にＰＳＫ文字列の文字コードはＵＩレベルで意識されない。

したがって、従来のＩＰｓｅｃにおけるＳＡでは、正しいＰＳＫ文字列を設定してもＵＩレベルであまり意識されていない文字コードの違いによって相手認証に失敗してしまうケースがあるという問題があった。

本発明は、上記の点に鑑みなされたもので、使用者に文字コードの違いを意識させることなく、適切に相手認証を行うことができる暗号通信装置、暗号通信方法を提供することを目的とする。

上記課題を解決するため、本発明は、少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、自装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成する暗号鍵生成手段と、生成した暗号鍵毎に、その暗号鍵を用いて、相手認証に利用する第１認証情報を生成する認証情報生成手段と、前記第１認証情報を相手装置に送信する送信手段と、前記相手認証が成功した前記相手装置から、前記相手認証が成功した前記第１認証情報に対応する暗号鍵を用いて生成された、相手認証に利用する第２認証情報を受信する受信手段と、前記第２認証情報を用いて相手認証を行う相手認証手段と、前記相手認証が成功した前記第２認証情報に対応する暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段とを有することを特徴とする。

また、本発明は、少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、自装置において使用可能なただ１つの文字コードで表現された前記文字列から暗号鍵を生成する暗号鍵生成手段と、相手装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成した前記相手装置から、前記暗号鍵毎に、その暗号鍵を用いて生成された相手認証に利用する第１認証情報を受信する受信手段と、前記第１認証情報を用いて相手認証を行う相手認証手段と、前記相手認証が成功すると、前記暗号鍵生成手段により生成された前記暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段と、前記相手装置との暗号通信で用いる暗号鍵により、相手認証に利用する第２認証情報を生成する認証情報生成手段と、前記第２認証情報を相手装置に送信する送信手段とを有することを特徴とする。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明によれば、使用者に文字コードの違いを意識させることなく、適切に相手認証を行うことができる暗号通信装置、暗号通信方法を提供可能である。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。なお、本実施例ではＩＰｓｅｃを利用した暗号通信装置を一例として説明するが、他の暗号化方式を利用する暗号通信装置であってもよい。

図１は、本発明による暗号通信装置を含むシステムの一例の構成図である。図１のシステムは、複数の暗号通信装置１，２が、ＬＡＮやインターネット等のネットワーク３に通信可能に接続されている。なお、暗号通信装置１，２は通信機能を有するＰＣ，複合機又は通信端末等である。

暗号通信装置１，２は、ＩＰｓｅｃ機能部１２を有するＩＰ機能部１１，ＴＣＰ／ＵＤＰ機能部１３，ＩＫＥデーモン１４，ＨＴＴＰ機能部１５，ＰＳＫ文字列１６を含むように構成されている。ＩＰｓｅｃ機能部１２を有するＩＰ機能部１１は、ネットワーク層に含まれる。ＴＣＰ／ＵＤＰ機能部１３は、トランスポート層に含まれる。ＩＫＥデーモン１４及びＨＴＴＰ機能部１５は、アプリケーション層に含まれる。また、ＰＳＫ文字列１６はユーザデータに含まれる。なお、ＨＴＴＰ機能部１５はアプリケーション層に属するプロトコルの一例であって、他のプロトコルであってもよい。

暗号通信装置１，２は、ＩＫＥの標準手順に従ってメッセージ交換を行う。メッセージ交換を開始する側の暗号通信装置１はイニシエータと呼ばれる。もう一方の暗号通信装置２はレスポンダと呼ばれる。暗号通信装置１，２はイニシエータにもレスポンダにもなり得る。暗号通信装置１，２は、同じ構成となる。

ここでは、暗号通信装置１，２がＰＣであるときのハードウェア構成について簡単に説明する。図２は暗号通信装置の一例のハードウェア構成図である。

暗号通信装置１，２は、それぞれバスＢで相互に接続されている入力装置２１，出力装置２２，ドライブ装置２３，補助記憶装置２４，メモリ装置２５，演算処理装置２６及びインターフェース装置２７を含むように構成される。

入力装置２１はキーボードやマウスなどで構成され、各種信号を入力するために用いられる。出力装置２２はディスプレイ装置などで構成され、各種ウインドウやデータ等を表示するために用いられる。インターフェース装置２７は、モデム，ＬＡＮカードなどで構成されており、ネットワーク３に接続する為に用いられる。

暗号通信装置１，２を制御する各種プログラムは、例えば記録媒体２８の配布やネットワーク３からのダウンロードなどによって提供される。各種プログラムを記録した記録媒体２８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスクなどの様に情報を光学的，電気的或いは磁気的に記録する記録媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記録媒体を用いることができる。

各種プログラムを記録した記録媒体２８がドライブ装置２３にセットされると、各種プログラムは記録媒体２８からドライブ装置２３を介して補助記憶装置２４にインストールされる。ネットワーク３からダウンロードされた各種プログラムは、インターフェース装置２７を介して補助記憶装置２４にインストールされる。

暗号通信装置１，２は、インストールされた各種プログラムを格納すると共に、必要なファイル，データ等を格納する。メモリ装置２５は、コンピュータの起動時に補助記憶装置２４から各種プログラムを読み出して格納する。そして、演算処理装置２６はメモリ装置２５に格納された各種プログラムに従って、後述するような各種処理を実現している。

次に、発明の理解を容易とするため、従来の問題点について簡単に説明する。図３はＩＫＥのＰｈａｓｅ（フェーズ）１の通信を表したシーケンス図である。Ｍａｉｎモードの場合、ＩＫＥのＰｈａｓｅ１ではステップＳ１〜Ｓ６の手順により６つのメッセージが交換される。

ステップＳ５，Ｓ６は相手認証の為のメッセージ交換である。ステップＳ５，Ｓ６ではＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードで自身を一意に識別する識別情報である自身のＩＰアドレスを交換し、相手認証が行われる。Ｉｄｅｎｔｉｆｉｃａｔｉｏｎペイロードは暗号化されている。相手認証方式がＰＳＫの場合、暗号化される元データと暗号鍵とは図４に示すようになる。

図４はＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードの元データと暗号鍵とを表した説明図である。暗号化される元データは、自身のＩＰアドレスである。暗号鍵は、ＰＳＫ文字列１６と、Ｎｏｎｃｅ（Ｎｉ，Ｎｒ）と、Ｉｎｉｔｉａｔｏｒ ｃｏｏｋｉｅと、Ｒｅｓｐｏｎｄｅｒ ｃｏｏｋｉｅとを含む要素からハッシュ計算されたハッシュ値である。

なお、Ｎｏｎｃｅ（Ｎｉ，Ｎｒ）と、Ｉｎｉｔｉａｔｏｒ ｃｏｏｋｉｅと、Ｒｅｓｐｏｎｄｅｒ ｃｏｏｋｉｅと、ハッシュアルゴリズムとは、ステップＳ１〜Ｓ４までの処理により折衝済みである。したがって、両ノード（イニシエータ，レスポンダ）間でＰＳＫ文字列１６が一致していることは、ステップＳ５，Ｓ６において相手認証が成功するための必要条件となる。

しかしながら、ＰＳＫ文字列１６に対して両ノードで使用している文字コードが異なる場合は表示上、同じＰＳＫ文字列１６からでも異なる暗号鍵が生成されてしまい、相手認証に失敗してしまうという問題があった。なお、使用する文字コードについては規約上の取り決めが無く、プラットフォームやアプリケーションに依存する。また、一般にＰＳＫ文字列１６の文字コードはＵＩレベルで意識されない。

図５は両ノードで使用している文字コードが同じ場合におけるＩＫＥのＰｈａｓｅ１の通信を表したシーケンス図である。図６は両ノードで使用している文字コードが異なる場合におけるＩＫＥのＰｈａｓｅ１の通信を表したシーケンス図である。

図５では、イニシエータ及びレスポンダが同じ文字コードＸを使用している。図５の例ではイニシエータ及びレスポンダにおいて、文字コードＸで表現されたＰＳＫ文字列「ＡＢＣ」から同じ暗号鍵Ｘｉ，Ｘｒが生成される。したがって、図５の例では相手認証に成功する。

図６では、イニシエータ及びレスポンダが異なる文字コードＸ，Ｙを使用している。図６の例ではイニシエータ及びレスポンダにおいて、文字コードＸ，Ｙで表現されたＰＳＫ文字列「ＡＢＣ」から異なる暗号鍵Ｘｉ，Ｙｒが生成される。したがって、図６の例では相手認証に失敗する。使用者から見ると、従来の暗号通信装置１，２は正しいＰＳＫ文字列を設定しても認証に失敗したと判断されてしまい、信頼を失う恐れがあった。

そこて、本発明による暗号通信装置１，２では以下に示す実施例１〜４のように、使用者に文字コードの違いを意識させることなく、上記の問題点を解決している。

図７は本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第一実施例のシーケンス図である。なお、図７のステップＳ１１，Ｓ１２は、図３のステップＳ１〜Ｓ４と同様であるため、説明を省略する。

図７のシーケンス図では、イニシエータにおいて内部的に複数の文字コードＸ，Ｙ及びＺを扱い、複数の文字コードＸ，Ｙ及びＺで表現されたＰＳＫ文字列１６から生成された暗号鍵で個々に相手認証を試みる方式である。このような方式では、イニシエータ及びレスポンダが以下のように動作する。

イニシエータは、予め使用する複数の文字コードＸ，Ｙ及びＺが設定されている。イニシエータは設定されている文字コードＸ，Ｙ及びＺ毎に暗号鍵Ｘｉ，Ｙｉ及びＺｉを生成する。ステップＳ１３では、設定されている文字コードＸ，Ｙ及びＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードがイニシエータからレスポンダに送信される。即ち、イニシエータは設定されている文字コードの数分のＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードをレスポンダに送信する。

レスポンダは、予め使用する文字コードＺが設定されている。レスポンダは設定されている文字コードＺの暗号鍵Ｚｒを生成する。レスポンダは、イニシエータから受信したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証を試みる。

イニシエータから受信したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードの何れかで相手認証が成功すると、レスポンダはステップＳ１４に進み、設定されている文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードをイニシエータに送信する。

なお、図７のシーケンス図の場合は、イニシエータから受信した文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証を試みたときに相手認証が成功し、その他の相手認証が失敗する。ステップＳ１４の後、イニシエータとレスポンダとは文字コードＺの暗号鍵Ｚｉ，Ｚｒを用いて暗号通信を行う。

ＩＫＥのＰｈａｓｅ１の通信は図１のＩＫＥデーモン１４によって制御される。ＩＫＥデーモン１４は上記の処理を実現するため、図８に示すように構成される。図８はＩＫＥデーモンの一例のブロック構成図である。

図８のＩＫＥデーモン１４は、暗号鍵生成部８１，認証情報生成部８２，相手認証部８３，暗号鍵決定部８４，送信部８５，受信部８６を含む構成である。各ブロックの処理は後述のフローチャートを用いて説明する。

図９はイニシエータがレスポンダへＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを送信する処理を表したフローチャートである。

イニシエータのＩＫＥデーモン１４は、自装置がサポートする各文字コード（自装置において使用可能な各文字コード）に対し、ステップＳ２１〜Ｓ２４の処理を繰り返す。

ステップＳ２１に進み、ＩＫＥデーモン１４の暗号鍵生成部８１は文字コードＸで表現されたＰＳＫ文字列１６から暗号鍵Ｘｉを生成する。ステップＳ２２に進み、暗号鍵生成部８１は暗号鍵Ｘｉを鍵リストに登録する。

ステップＳ２３に進み、認証情報生成部８２は生成した暗号鍵Ｘｉを用いてＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを生成する。認証情報生成部８２はステップＳ２４に進み、生成したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを生成済みの共通ペイロードに連結する。

文字コードＸと同様、文字コードＹ及びＺについてもステップＳ２１〜Ｓ２４の処理を行うことにより、認証情報生成部８２は、図７に示すような共通ペイロード７１を生成できる。自装置がサポートする各文字コードに対し、ステップＳ２１〜Ｓ２４の処理が全て終了すると、送信部８５は認証情報生成部８２によって生成された図７の共通ペイロード７１をレスポンダへ送信する。

図１０はイニシエータからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信する前の処理を表したフローチャートである。

レスポンダのＩＫＥデーモン１４は、自装置がサポートする各文字コード（自装置において使用可能な各文字コード）に対し、ステップＳ３１〜Ｓ３２の処理を繰り返す。図７の例では文字コードＺに対し、ステップＳ３１〜Ｓ３２の処理が行われる。ステップＳ３１に進み、ＩＫＥデーモン１４の暗号鍵生成部８１は文字コードＺで表現されたＰＳＫ文字列１６から暗号鍵Ｚｒを生成する。ステップＳ３２に進み、暗号鍵生成部８１は暗号鍵Ｚｒを鍵リストに登録する。

図１１はレスポンダがイニシエータからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信したときの処理を表したフローチャートである。ＩＫＥデーモン１４の受信部８６が共通ペイロード７１を受信すると、図１１のフローチャートに表した処理が開始される。

ステップＳ４１に進み、ＩＫＥデーモン１４の相手認証部８３はイニシエータから受信した共通ペイロード７１に含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証処理を試みる。なお、相手認証処理の詳細は後述する。

まず、相手認証部８３はステップＳ４１に進み、文字コードＸのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証処理を試みる。イニシエータの暗号鍵Ｘｉとレスポンダの暗号鍵Ｚｒとが異なるため、相手認証部８３は相手認証に失敗し、ステップＳ４１に戻る。

次に、相手認証部８３は文字コードＹのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証処理を試みる。イニシエータの暗号鍵Ｙｉとレスポンダの暗号鍵Ｚｒとが異なるため、相手認証部８３は相手認証に失敗し、ステップＳ４１に戻る。

次に、相手認証部８３は文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証処理を試みる。イニシエータの暗号鍵Ｚｉとレスポンダの暗号鍵Ｚｒとが同じであるため、相手認証部８３は相手認証に成功し、ステップＳ４３に進む。

ステップＳ４３では、認証情報生成部８２が、相手認証が成功した暗号鍵Ｚｒを用いて文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを生成する。ステップＳ４４に進み、送信部８５は文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを含む図７の共通ペイロード７２を生成し、その共通ペイロード７２をイニシエータへ送信する。なお、暗号鍵決定部８４は相手認証が成功した暗号鍵Ｚｒをイニシエータとの暗号通信に用いる暗号鍵として決定する。

一方、相手認証部８３はイニシエータから受信した共通ペイロード７１に含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証処理を試みた結果、全ての相手認証に失敗するとステップＳ４５に進み、送信部８５経由で相手認証の失敗をイニシエータへ応答する。

図１２は相手認証処理を表したフローチャートである。ステップＳ５１に進み、相手認証部８３は共通ペイロード７１に含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードのうちの一つのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードを、鍵リストに登録されている一つの暗号鍵Ｚｒで復号する。ステップＳ５２に進み、相手認証部８３は復号したデータからＨａｓｈペイロードを計算する。

ステップＳ５３に進み、相手認証部８３は暗号鍵Ｚｒで復号したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードに対応するＨａｓｈペイロードと、復号したデータから計算したＨａｓｈペイロードとを比較し、一致すれば相手認証が成功したと判定する。鍵リストに登録されている全ての暗号鍵について、復号したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロードに対応するＨａｓｈペイロードと、復号したデータから計算したＨａｓｈペイロードとが一致しなければ相手認証が失敗したと判定する。

図１３はイニシエータがレスポンダからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信したときの処理を表したフローチャートである。ＩＫＥデーモン１４の受信部８６が共通ペイロード７２を受信すると、図１３のフローチャートに表した処理が開始される。

ステップＳ６１に進み、ＩＫＥデーモン１４の相手認証部８３はレスポンダから受信した共通ペイロード７２に含まれるＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、鍵リストに登録されている暗号鍵Ｘｉ，Ｙｉ及びＺｉを用いて相手認証処理を試みる。なお、相手認証処理は、前述した図１１のフローチャートのように行われる。ここでは、鍵リストに登録されている暗号鍵Ｚｉを用いて相手認証処理を試みたときに相手認証に成功する。

相手認証が成功すると、暗号鍵決定部８４はステップＳ６３に進み、相手認証が成功した暗号鍵Ｚｉをイニシエータとの暗号通信に用いる暗号鍵として決定し、その暗号鍵Ｚｉを用いてＰｈａｓｅ２の処理を行う。なお、鍵リストに登録されている暗号鍵Ｘｉ，Ｙｉ及びＺｉを用いて相手認証処理を試みた結果、相手認証に失敗すると、ステップＳ６４に進み、送信部８５経由で相手認証の失敗をレスポンダへ応答する。

図１４は本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第二実施例のシーケンス図である。なお、図１４のステップＳ７１，Ｓ７２は、図３のステップＳ１〜Ｓ４と同様であるため、説明を省略する。

図１４のシーケンス図では、レスポンダにおいて内部的に複数の文字コードＸ，Ｙ及びＺを扱い、複数の文字コードＸ，Ｙ及びＺで表現されたＰＳＫ文字列１６から生成された暗号鍵で個々に相手認証を試みる方式である。このような方式では、イニシエータ及びレスポンダが以下のように動作する。

イニシエータは、予め使用する文字コードＺが設定されている。イニシエータは設定されている文字コードＺから暗号鍵Ｚｉを生成する。ステップＳ７３では、設定されている文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードがイニシエータからレスポンダに送信される。

レスポンダは、予め使用する文字コードＸ，Ｙ，Ｚが設定されている。レスポンダは設定されている文字コードＸ，Ｙ及びＺの暗号鍵Ｘｒ，Ｙｒ及びＺｒを生成する。レスポンダは、イニシエータから受信したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｘｒ，Ｙｒ及びＺｒを用いて相手認証を試みる。

なお、図１４のシーケンス図の場合は、イニシエータから受信した文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証を試みたときに相手認証が成功し、その他の相手認証が失敗する。

イニシエータから受信したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードの相手認証が成功すると、レスポンダはステップＳ７４に進み、相手認証が成功した文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードをイニシエータに送信する。ステップＳ７４の後、イニシエータとレスポンダとは文字コードＺの暗号鍵Ｚｉ，Ｚｒを用いて暗号通信を行う。

なお、ＩＫＥデーモン１４の構成及び処理は図８〜図１３を利用して説明した第一実施例におけるＩＫＥデーモン１４の構成及び処理と同様であるため、説明を省略する。

図１５は本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第三実施例のシーケンス図である。なお、図１５のステップＳ８１，Ｓ８２は、図３のステップＳ１〜Ｓ４と同様であるため、説明を省略する。

図１５のシーケンス図ではイニシエータにおいて内部的に複数の文字コードＸ及びＺを扱い、レスポンダにおいて内部的に複数の文字コードＹ及びＺを扱い、複数の文字コードＸ，Ｙ及びＺで表現されたＰＳＫ文字列１６から生成された暗号鍵で個々に相手認証を試みる方式である。このような方式では、イニシエータ及びレスポンダが以下のように動作する。

イニシエータは、予め使用する文字コードＸ及びＺが設定されている。イニシエータは設定されている文字コードＸ及びＺから暗号鍵Ｘｉ及びＺｉを生成する。ステップＳ８３では、設定されている文字コードＸ及びＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードがイニシエータからレスポンダに送信される。

レスポンダは、予め使用する文字コードＹ及びＺが設定されている。レスポンダは設定されている文字コードＹ及びＺの暗号鍵Ｙｒ及びＺｒを生成する。レスポンダは、イニシエータから受信した文字コードＸ及びＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｙｒ及びＺｒを用いて相手認証を試みる。

なお、図１５のシーケンス図の場合は、イニシエータから受信した文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードに対し、暗号鍵Ｚｒを用いて相手認証を試みたときに相手認証が成功し、その他の相手認証が失敗する。

イニシエータから受信したＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードの相手認証が成功すると、レスポンダはステップＳ８４に進み、相手認証が成功した文字コードＺのＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードをイニシエータに送信する。ステップＳ８４の後、イニシエータとレスポンダとは文字コードＺの暗号鍵Ｚｉ，Ｚｒを用いて暗号通信を行う。

なお、ＩＫＥデーモン１４の構成及び処理は図８〜図１３を利用して説明した第一実施例におけるＩＫＥデーモン１４の構成及び処理と同様であるため、説明を省略する。

前述したＩＫＥのＰｈａｓｅ１の通信を表した第一実施例〜第三実施例の代替手段としてはＰｈａｓｅ１のパラメータの折衝時に、ＰＳＫ文字列１６の文字コードも折衝することが考えられる。Ｐｈａｓｅ１のパラメータは、図１６（Ａ）に示すように、Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎペイロードに含まれるＰｒｏｐｏｓａｌペイロード内のＴｒａｎｓｆｏｒｍペイロードに格納されている。

そこで、第四実施例では図１６（Ｂ）に示すように、Ｔｒａｎｓｆｏｒｍペイロードに格納されているＳＡ属性フィールド（ＳＡ Ａｔｔｒｉｂｕｔｅｓ）で文字コードをやり取りできるように拡張する。

図１７は固定長のＳＡ属性フィールドの一例を示す説明図である。図１７（Ａ）に示すように、固定長のＳＡ属性フィールドは、Ａｔｔｒｉｂｕｔｅ Ｔｙｐｅと、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅとで構成されている。

図１７（Ｂ）に示すように、固定長のＳＡ属性フィールドは、Ａｔｔｒｉｂｕｔｅ Ｔｙｐｅとして「ＰＳＫ文字列文字コード」を表すＶａｌｕｅ「１７」と、Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅとして「Ｂｉｎａｒｙ，ＡＳＣＩＩ，Ｕｎｉｃｏｄｅ」を表すＶａｌｕｅ「０，１，２」とが拡張されている。このように、第四実施例ではＴｒａｎｓｆｏｒｍペイロードに格納されているＳＡ属性フィールドで文字コードをやり取りするように拡張できる。

図１８は本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第四実施例のシーケンス図である。Ｍａｉｎモードの場合、ＩＫＥのＰｈａｓｅ１ではステップＳ９１〜Ｓ９６の手順により６つのメッセージが交換される。

ステップＳ９１に進み、イニシエータはサポートする文字コード１〜ｎを図１６及び図１７に示したようにＴｒａｎｓｆｏｒｍペイロードに乗せ、共通ペイロード１８１によりレスポンダへ送信する。

共通ペイロード１８１を受信したレスポンダは共通ペイロード１８１内のＴｒａｎｓｆｏｒｍペイロードからイニシエータのサポートする文字コード１〜ｎを読み出し、イニシエータのサポートする文字コード１〜ｎのうち、自装置がサポートする文字コードを一つ選択する。ここでは、レスポンダが文字コードａを選択したものとする。

ステップＳ９２に進み、レスポンダは選択した文字コードａを図１６及び図１７に示したようにＴｒａｎｓｆｏｒｍペイロードに乗せ、共通ペイロード１８２でイニシエータへ送信する。なお、図１８のステップＳ９３〜Ｓ９６は折衝で決定した文字コードａで図３のステップＳ３〜Ｓ６と同様な処理を行う。

なお、第四実施例の処理を実現するため、ＩＫＥデーモン１４は図１９に示すように構成される。図１９はＩＫＥデーモンの他の例のブロック構成図である。

図１９のＩＫＥデーモン１４は、暗号鍵生成部８１，認証情報生成部８２，相手認証部８３，暗号鍵決定部８４，送信部８５，受信部８６，文字コード選択部８７を含む構成である。図１９のＩＫＥデーモン１４は図８のＩＫＥデーモンの構成に文字コード選択部８７を追加したものである。

イニシエータの文字コード選択部８７は、サポートする文字コード１〜ｎを図１６及び図１７に示したようにＴｒａｎｓｆｏｒｍペイロードに乗せる処理を行う。レスポンダの文字コード選択部８７は、共通ペイロード１８１内のＴｒａｎｓｆｏｒｍペイロードからイニシエータのサポートする文字コード１〜ｎを読み出し、イニシエータのサポートする文字コード１〜ｎのうち、自装置がサポートする文字コードを一つ選択する処理と、選択した文字コードａを図１６及び図１７に示したようにＴｒａｎｓｆｏｒｍペイロードに乗せる処理を行う。

以上のように、実施例１〜４に示した本発明による暗号通信装置１，２では、使用者に文字コードの違いを意識させることなく、適切に相手認証を行うことができる。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明による暗号通信装置を含むシステムの一例の構成図である。 暗号通信装置の一例のハードウェア構成図である。 ＩＫＥのＰｈａｓｅ（フェーズ）１の通信を表したシーケンス図である。 Ｉｄｅｎｔｉｆｉｃａｔｉｏｎペイロードの元データと暗号鍵とを表した説明図である。 両ノードで使用している文字コードが同じ場合におけるＩＫＥのＰｈａｓｅ１の通信を表したシーケンス図である。 両ノードで使用している文字コードが異なる場合におけるＩＫＥのＰｈａｓｅ１の通信を表したシーケンス図である。 本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第一実施例のシーケンス図である。 ＩＫＥデーモンの一例のブロック構成図である。 イニシエータがレスポンダへＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを送信する処理を表したフローチャートである。 イニシエータからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信する前の処理を表したフローチャートである。 レスポンダがイニシエータからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信したときの処理を表したフローチャートである。 相手認証処理を表したフローチャートである。 イニシエータがレスポンダからＩｄｅｎｔｉｆｉｃａｔｉｏｎペイロード及びＨａｓｈペイロードを受信したときの処理を表したフローチャートである。 本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第二実施例のシーケンス図である。 本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第三実施例のシーケンス図である。 Ｔｒａｎｓｆｏｒｍペイロード内のＳＡ属性フィールドで文字コードをやり取りできるように拡張する例を表した説明図である。 固定長のＳＡ属性フィールドの一例を示す説明図である。 本発明によるＩＫＥのＰｈａｓｅ１の通信を表した第四実施例のシーケンス図である。 ＩＫＥデーモンの他の例のブロック構成図である。

符号の説明

１，２ 暗号通信装置
３ ネットワーク
１１ ＩＰ機能部
１２ ＩＰｓｅｃ機能部
１３ ＴＣＰ／ＵＤＰ機能部
１４ ＩＫＥデーモン
１５ ＨＴＴＰ機能部
１６ ＰＳＫ文字列
２１ 入力装置
２２ 出力装置
２３ ドライブ装置
２４ 補助記憶装置
２５ メモリ装置
２６ 演算処理装置
２７ インターフェース装置
２８ 記録媒体
８１ 暗号鍵生成部
８２ 認証情報生成部
８３ 相手認証部
８４ 暗号鍵決定部
８５ 送信部
８６ 受信部
８７ 文字コード選択部
Ｂ バス

Claims (8)

1. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、
   自装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成する暗号鍵生成手段と、
   生成した暗号鍵毎に、その暗号鍵を用いて、相手認証に利用する第１認証情報を生成する認証情報生成手段と、
   前記第１認証情報を相手装置に送信する送信手段と、
   前記相手認証が成功した前記相手装置から、前記相手認証が成功した前記第１認証情報に対応する暗号鍵を用いて生成された、相手認証に利用する第２認証情報を受信する受信手段と、
   前記第２認証情報を用いて相手認証を行う相手認証手段と、
   前記相手認証が成功した前記第２認証情報に対応する暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段と
   を有する暗号通信装置。
2. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、
   自装置において使用可能なただ１つの文字コードで表現された前記文字列から暗号鍵を生成する暗号鍵生成手段と、
   相手装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成した前記相手装置から、前記暗号鍵毎に、その暗号鍵を用いて生成された相手認証に利用する第１認証情報を受信する受信手段と、
   前記第１認証情報を用いて相手認証を行う相手認証手段と、
   前記相手認証が成功すると、前記暗号鍵生成手段により生成された前記暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段と、
   前記相手装置との暗号通信で用いる暗号鍵により、相手認証に利用する第２認証情報を生成する認証情報生成手段と、
   前記第２認証情報を相手装置に送信する送信手段と
   を有する暗号通信装置。
3. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、
   自装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成する暗号鍵生成手段と、
   相手装置において使用可能なただ１つの文字コードで表現された前記文字列から暗号鍵を生成した前記相手装置から、前記暗号鍵を用いて生成された相手認証に利用する第１認証情報を受信する受信手段と、
   前記第１認証情報を用いて相手認証を行う相手認証手段と、
   前記相手認証が成功した前記第１認証情報に対応する暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段と、
   前記相手認証が成功した前記第１認証情報に対応する暗号鍵を用いて、相手認証に利用する第２認証情報を生成する認証情報生成手段と、
   前記第２認証情報を相手装置に送信する送信手段と
   を有する暗号通信装置。
4. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置であって、
   自装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成する暗号鍵生成手段と、
   相手装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成した前記相手装置から、前記暗号鍵毎に、その暗号鍵を用いて生成された相手認証に利用する第１認証情報を受信する受信手段と、
   前記第１認証情報を用いて相手認証を行う相手認証手段と、
   前記相手認証が成功した前記第１認証情報に対応する暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定手段と、
   前記相手認証が成功した前記第１認証情報に対応する暗号鍵を用いて、相手認証に利用する第２認証情報を生成する認証情報生成手段と、
   前記第２認証情報を相手装置に送信する送信手段と
   を有する暗号通信装置。
5. 前記相手認証に利用する第１及び第２認証情報は、
   前記暗号通信装置を一意に識別する識別情報を前記暗号鍵で暗号化した情報と、
   前記識別情報からハッシュ関数により変換されたハッシュ値と
   を含むことを特徴とする請求項１乃至４何れか一項記載の暗号通信装置。
6. 前記相手認証手段は、前記暗号鍵で暗号化されている情報を復号して前記暗号通信装置を一意に識別する識別情報を取得すると共に、取得した前記識別情報をハッシュ関数により変換してハッシュ値を取得し、前記第１又は第２認証情報に含まれていたハッシュ値と一致するときに認証成功と判定することを特徴とする請求項５記載の暗号通信装置。
7. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置の暗号通信方法であって、
   前記暗号通信装置の暗号鍵生成手段が、自装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成する暗号鍵生成ステップと、
   前記暗号通信装置の認証情報生成手段が、生成した暗号鍵毎に、その暗号鍵を用いて、相手認証に利用する第１認証情報を生成する認証情報生成ステップと、
   前記暗号通信装置の送信手段が、前記第１認証情報を相手装置に送信する送信ステップと、
   前記暗号通信装置の受信手段が、前記相手認証が成功した前記相手装置から、前記相手認証が成功した前記第１認証情報に対応する暗号鍵を用いて生成された、相手認証に利用する第２認証情報を受信する受信ステップと、
   前記暗号通信装置の相手認証手段が、前記第２認証情報を用いて相手認証を行う相手認証ステップと、
   前記暗号通信装置の暗号鍵決定手段が、前記相手認証が成功した前記第２認証情報に対応する暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定ステップと
   を有する暗号通信方法。
8. 少なくとも文字列を含む要素から生成された暗号鍵により相手認証を行う暗号通信装置の暗号通信方法であって、
   前記暗号通信装置の暗号鍵生成手段が、自装置において使用可能なただ１つの文字コードで表現された前記文字列から暗号鍵を生成する暗号鍵生成ステップと、
   前記暗号通信装置の受信手段が、相手装置において使用可能な複数の文字コード毎に、前記文字列から暗号鍵を生成した前記相手装置から、前記暗号鍵毎に、その暗号鍵を用いて生成された相手認証に利用する第１認証情報を受信する受信ステップと、
   前記暗号通信装置の相手認証手段が、前記第１認証情報を用いて相手認証を行う相手認証ステップと、
   前記暗号通信装置の暗号鍵決定手段が、前記相手認証が成功すると、前記暗号鍵生成手段により生成された前記暗号鍵を、前記相手装置との暗号通信で用いる暗号鍵とする暗号鍵決定ステップと、
   前記暗号通信装置の認証情報生成手段が、前記相手装置との暗号通信で用いる暗号鍵により、相手認証に利用する第２認証情報を生成する認証情報生成ステップと、
   前記暗号通信装置の送信手段が、前記第２認証情報を相手装置に送信する送信ステップと
   を有する暗号通信方法。

Images