JPH10276185A

JPH10276185A - Ｉｄベース認証・鍵配送方法

Info

Publication number: JPH10276185A
Application number: JP9079745A
Authority: JP
Inventors: Takeshi Mito; 健史三戸; Yoshiki Samejima; 吉喜鮫島
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 1997-03-31
Filing date: 1997-03-31
Publication date: 1998-10-13

Abstract

(57)【要約】【課題】ネットワークを介して通信を行う前にユーザ
が相互に認証し合い、以後行おうとする通信に用いるセ
ッション鍵を配送する方法およびシステムにおいて、公
開鍵としてユーザが憶え易いものを用い、公開鍵の管理
を簡単にし、システム全体の運営・保守を容易にするこ
と。【解決手段】通信相手となる１対のクライアントが互
いに相手を認証し合った後に、当該１対のクライアント
で共有する暗号鍵を生成し、この暗号鍵を用いてメッセ
ージを暗号化して通信するためのＩＤベース認証・鍵配
送方において、それぞれのクライアントに、Ｕのｄ乗＝
Ｓ，Ｓのｅ乗＝（Ｕのｄ乗）のｅ乗＝Ｕ(但し、e・d＝1
(mod L)）の関係の公開鍵Ｕおよび秘密鍵を割り当てて
互いの認証と暗号鍵の生成する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワークを介
してユーザがお互いに情報を交換する場合に、その通信
を安全確実に行うために、実際の通信を行う前の前処理
を行う方法に関するものであり、特に、相手が本当に自
分が通信を行おうとする相手なのかを名前等のＩＤを用
いて相互に認証するＩＤベース認証と、互いに相手を確
認し合った後に、以後行おうとする通信を第三者に盗聴
されても大丈夫なように、通信文の暗号化および復号化
やメッセージ認証子の生成・検証のためのセッション鍵
を配送する鍵配送の方法に関するものである。

【０００２】

【従来の技術】図１１に示すようなコンピュータ等の通
信ネットワークを結合したネットワークでは、ネットワ
ーク１１で接続された複数のユーザ１２，１３，１４
は、ネットワーク１１を介して電子メール等の電子メッ
セージをお互いに配送することができる。

【０００３】この時に問題となるものに、ユーザ同士の
お互いの認証がある。ユーザ（Ａ）１２がユーザ（Ｂ）
１４とメッセージのやり取りを行おうとする時、メッセ
ージの受信者が確かにユーザ（Ｂ）１４であると、ユー
ザ（Ａ）１２は確認できなければならない。つまり、他
のユーザ（Ｃ）１３が、ユーザ（Ｂ）１４等の他人を偽
る行為（なりすまし）を防ぐ手段が必要である。同様
に、メッセージ受信者（この場合、ユーザ（Ｂ）１４）
も、メッセージ発信者がユーザ（Ａ）１２であることを
確認できなければならない。

【０００４】このような認証を行う手段の一つとして、
ゼロ知識証明がある。

【０００５】ゼロ知識証明とは、以下のようなものであ
る。証明者とは、自分が確かにその本人であることを証
明しようとするものであり、検証者とは、証明者の証明
が正しいかどうかを検証する者である。ゼロ知識証明と
は、証明者が秘密の情報を、検証者を含め他人に明かす
ことなく、検証者とメッセージのやり取りを行いなが
ら、その秘密を知っていることを検証者に対して証明す
る方法である。検証者は、秘密の情報を証明者が知って
いると認めれば、証明者を本人と認めるようにする。

【０００６】ゼロ知識証明を行う基本的なアルゴリズム
であるFiat-Shamir法について図２を参照して説明す
る。

【０００７】ｎを大きな合成数とする。合成数とは、素
数でない整数のことである。したがって、素数の積で表
わすことができる。ユーザ（Ａ）１２を証明者、ユーザ
（Ｂ）１４を検証者とする。そして、ユーザ（Ｂ）１４
はユーザ（Ａ）１２が次の「数１」となるＳ（秘密情報、
秘密鍵）を知っていることによりユーザ（Ａ）１２の認
証を行う。

【０００８】

【数１】

【０００９】ｎが非常に大きな素数の積である場合、ｎ
を素因数分解するのは困難であることが知られている。
更に、ｎが素因数分解できなければ、Ｚ_nでの平方根を
求めるのは困難であることも知られている。ここでＺ_n
とは、０以上ｎ未満の整数の集合{0,1,2,……n-1}のこ
とである。したがって、ＴからＳを求めることは非常に
難しく、Ｔを公開してもＳは秘密情報と見做すことがで
きる。

【００１０】ユーザ（Ｂ）１４は、Ｔ（ユーザＡの公開
情報、公開鍵）を知っているものとする。まず、ユーザ
（Ａ）１２は乱数Ｒ∈Ｚ_nを生成する（ステップ１２
１）。次に、「数２」を生成しＸをユーザ（Ｂ）１４に
送る（ステップ１２２）。

【００１１】

【数２】

【００１２】Ｘを受け取ったユーザ（Ｂ）１４（ステッ
プ１２６）は、ｂ∈{0,1}を二者択一的にランダムに選
び（ステップ１２７）、ｂをユーザ（Ａ）１２に送る
（ステップ１２８）。ｂを受け取ったユーザ（Ａ）１２
（ステップ１２３）は、「数３」を計算し（ステップ１
２４）、Ｙをユーザ（Ｂ）１４に送る（ステップ１２
５）。

【００１３】

【数３】

【００１４】ｂ＝０の場合、Ｙ＝ＲＳとなり、Ｓの情報
は漏れない。ｂ＝１の場合、Ｙ＝ＲＳとなるが、Ｒを求
めることは困難なため、Ｓを求めることも困難となる。

【００１５】そして、Ｙを受け取ったユーザ（Ｂ）１４
（ステップ１２９）は、「数４」が成り立つかどうか検
証する（ステップ１３０）。

【００１６】

【数４】

【００１７】ここまでを１ラウンドとし、これをｋ回
（ｋラウンド）繰り返すと、ユーザ（Ａ）１２がＳを知
らない場合、ユーザ（Ａ）１２が検証をクリアできる確
率は「数５」となる。すなわち、ユーザ（Ａ）１２がｋ
回後に正しく認証される確率は「数６」である。したが
って、充分大きなｋにおいて認証が行われた場合、ユー
ザ（Ｂ）１４は、ユーザ（Ａ）１２をユーザ（Ａ）１２
本人であると認めて構わない。

【００１８】

【数５】

【００１９】

【数６】

【００２０】以上では、ユーザ（Ｂ）１４がユーザ
（Ａ）１２を認証することしかしていないが、ユーザ
（Ａ）１２がユーザ（Ｂ）１４を認証する場合は、以上
と対称的な操作を行えばよい。このようにして、通信を
行なうもの同士が互いに認証を行うことができる。

【００２１】次に、問題となるのは、送信する情報の安
全性である。ネットワーク上では、通信当事者以外の者
がメッセージの内容を盗むこと（盗聴）ができる。そこ
で、メッセージを暗号化することが必要となるが、それ
には暗号鍵が必要となる。メッセージ認証子の生成・検
証にも暗号鍵は必要である。

【００２２】公開鍵配送法は、公開鍵を用いて暗号鍵を
共有する方法であり、これを用いて安全でない通信路を
介して暗号鍵を生成できる。

【００２３】暗号鍵を共有するための具体的なアルゴリ
ズムにＤiffie -Hellman型公開鍵配送法がある。このＤ
iffie -Hellman型公開鍵配送法を用いた暗号鍵（以降
は、セッション鍵と呼ぶことにする）の配送方法を図１
３を参照して説明する。

【００２４】まず、ｐを素数とし、有限体ＧＦ（ｐ）の
ある固定された原始根をｇとする。有限体ＧＦとは、代
数系ＧＦが有限集合であり、ＧＦの要素が加法可換群を
成し、ＧＦから０を除いた要素が乗法可換群を成し、Ｇ
Ｆの要素が分配法則（すなわち、ｘ，ｙ，ｚ∈ＧＦなら
ばｘ・（ｙ＋ｚ）＝ｘ・ｙ＋ｘ・ｚかつ（ｙ＋ｚ）・ｘ
＝ｙ・ｘ＋ｚ・ｘが成り立つ）を満たすものである。原
始根ｇとは、ＧＦの単位元を１とすると、「数７」とな
る最小の正整数ｋがｐ−１であるｇ（∈ＧＦ）のことで
ある。ｐとｇは、前もってユーザ全員に公開しておき、
これが公開鍵となる。

【００２５】

【数７】

【００２６】ユーザ（Ａ）１２とユーザ（Ｂ）１４がセ
ッション鍵を共有する方法を説明する。ユーザ（Ａ）１
２はＸ₁∈Ｚ_p-1をランダムに選び、秘密に保持しておく
（ステップ１３１）。ユーザ（Ｂ）１４も同様に、整数
Ｘ₂∈Ｚ_p-1をランダムに選び、秘密に保持しておく（ス
テップ１３６）。そしてユーザ（Ａ）１２は、「数８」
を計算し（ステップ１３２)、Ｙ₁をユーザ（Ｂ）１４に
送る（ステップ１３３）。ユーザ（Ｂ）１４も同様に、
「数９」を計算し（ステップ１３７）、Ｙ₂をユーザ
（Ａ）１２に送る（ステップ１３８）。

【００２７】

【数８】

【００２８】

【数９】

【００２９】このようにＹ₁とＹ₂を交換しあった後で
（ステップ１３４およびステップ１３９）、各々セッシ
ョン鍵Ｋを次のように生成する。ユーザ（Ａ）１２は、
「数１０」を計算し、セッション鍵とする（ステップ１
３５）。ユーザ（Ｂ）１４も同様に、「数１１」を計算
し、セッション鍵とする（ステップ１４０）。

【００３０】このセッション鍵Ｋを用いて、ユーザ
（Ａ）１２とユーザ（Ｂ）１４はお互いに暗号化したメ
ッセージを用いて通信を行うことができる。

【００３１】

【数１０】

【００３２】

【数１１】

【００３３】本発明も、Ｄiffie -Hellman型公開鍵配送
法を部分的に応用している。

【００３４】

【発明が解決しようとする課題】Fiat-Shamir法で認証
を行う場合、検証者は証明者毎に「数１２」を知ってい
なければならない。

【００３５】

【数１２】

【００３６】Ｔは、ユーザにとっては普通意味の無い，
大きな桁数（例えば５１２ビットや何百、何千桁）の数
字であり、そのためＴの管理情報、つまりそれぞれの証
明者（ユーザ）とその公開情報Ｔのテーブル（以降、テ
ーブルと呼ぶ）をシステムに組み込まなくてはならな
い。しかし、テーブルには偽造、改竄に対する処置を施
さねばならず、維持、管理が大変である。

【００３７】そこで、Ｔを、ユーザＩＤ、ユーザ名、住
所、通り名やマシン名などの人間に憶えやすいものにす
れば、ユーザが記憶できる範囲内ではテーブルを使用し
ないでも済む。このようにすれば、テーブルを用いる場
合でも、その構成や要素（Ｔ）が意味のあるものとなる
ので作成し易いし、Ｔがユーザに憶えやすいために、テ
ーブルが偽造・改竄を受けたとしても、ユーザがそれに
気づき易い。またテーブルを消失したとしても、そのデ
ータを復旧し易い。このように、Ｔがユーザに解り易い
ものであると、システムの運用に対して様々な利点が生
じ、ユーザも利用し易い。

【００３８】しかし、Fiat-Shamir法では、Ｔを解り易
いものにしようとすると、Ｔから秘密鍵Ｓを作ることは
非常に困難（それができれば、この方法の有用性も無く
なる）であるので、Ｔを解り易い情報とすることはでき
ない。したがって、Ｔはユーザにとっては無意味なワー
ド（ユーザの秘密鍵の２乗）とならざるを得ず、どうし
てもテーブルが必要となる。このため、テーブル管理
（配送、偽造、改竄防止等）のコストが大きいという問
題がある。

【００３９】本発明は、Fiat-Shamir法で言うところの
公開鍵Ｔがユーザに解り易いものであり、センタ（認証
を司る所）が公開鍵Ｔから秘密鍵Ｓを作ることは簡単で
あるが、部外者（システムに対する攻撃者）が公開鍵Ｔ
から秘密鍵Ｓを求めることが困難であり、公開鍵Ｔのテ
ーブルの管理が不要、若しくは簡単となり、システムの
運営が容易となるＩＤベース認証・鍵配送方法を提供す
ることを目的とするものである。

【００４０】

【課題を解決するための手段】上記目的を達成するため
に、本発明のＩＤベース認証・鍵配送方法は、通信相手
となる１対のクライアントが互いに相手を認証し合った
後に、当該１対のクライアントで共有する暗号鍵を生成
し、この暗号鍵を用いてメッセージを暗号化して通信す
るためのＩＤベース認証・鍵配送方において、それぞれ
のクライアントに、Ｕのｄ乗＝Ｓ，Ｓのｅ乗＝（Ｕのｄ
乗）のｅ乗＝Ｕ(但し、e・d＝1(mod L)，(p-1)・(q-1)＝
mod L でp,qは素数）の関係の公開鍵Ｕおよび秘密鍵Ｓ
を割り当てて互いの認証と暗号鍵の生成を行うことを特
徴とする。

【００４１】Ｕのｄ乗＝Ｓの関係にすることにより、公
開鍵Ｕとしてユーザが憶え易いユーザＩＤ、住所、機器
名称などを使用しても、その公開鍵をｄ乗するだけで、
秘密鍵Ｓを鍵配送センタ等で容易に作成することができ
る。

【００４２】認証は、Fiat-Shamir法を適用し、図１２
で説明した「Ｓのｂ乗」を「Ｓのｅ乗」に置き換えて行
う。また、暗号鍵の生成は、Ｄiffie -Hellman型公開鍵
配送法を部分的に応用して行う。

【００４３】

【発明の実施の形態】以下、本発明の実施形態を図面に
より詳細に説明する。

【００４４】まず、本発明を適用するシステムのエンテ
ィティには、認証や鍵配送を司るセンタ（あるいはプロ
グラム）や、システムを利用するユーザが最低限でも含
まれる。ユーザ同士で認証や鍵配送を行う。例として
は、クライアント・サーバシステム（ＣＳＳシステム）
のクライアントとサーバ、携帯端末とホスト、情報サー
ビスセンタとその利用者などが挙げられる。勿論、ユー
ザとセンタ間で行う場合もある。

【００４５】まず、センタは以下の操作を行う。まず、
大きな素数、ｐとｑ（共に２５６ビット以上）を生成す
る。ｎ＝ｐ×ｑ，Ｌ＝ｌｃｍ（ｐ−１，ｑ−１）とす
る。。ここで、ｌｃｍ（ｐ−１，ｑ−１）はｐ−１とｑ
−１の最小公倍数である。ｅ×ｄ＝１（ｍｏｄＬ）と
なるｅとｄを求める。ｍをｎ以下の素数とし、ｇは有限
体ＧＦ（ｍ）の原始根とする。

【００４６】さらに、センタは各ユーザＵに「数１３」
を配布する。ここで、添え字のＵはユーザのインデック
スであり、「数１４」となる。

【００４７】

【数１３】

【００４８】

【数１４】

【００４９】Ｓ_UはユーザＵの秘密鍵である。Ｕ_Uは、ユ
ーザに覚え易い、ユーザＵに関連するユーザＩＤやマシ
ン名等の一意的な名称であり、ユーザＵの公開鍵であ
る。認証はユーザＵがＳ_Uを知っているかどうかで行
う。

【００５０】センタの生成した以上の情報は、通信をあ
るグループ内で行うとすると、図１のように分類でき
る。

【００５１】グループは符号１００で示すような情報を
共有する。そのうち、グループ内の公開情報は符号１０
１で示すようにｍ，ｎ，ｇ，ｅ，Ｕ_U，Ｕ_V・・・等であ
る。ここで、Ｕ_*はユーザ＊の公開鍵である。センタの
秘密情報は符号１０２で示すようにｐ，ｑ，ｄ，Ｓ_*・
・・等である。Ｓ_*はユーザ＊の秘密鍵であり、ユーザ
＊以外に知られないようにユーザ＊にのみ配布（符号１
０５および１０６で示す）するものとする。ユーザＵが
個人で所有して秘密にする情報（秘密鍵）は符号１０３
で示すようにＳ_Uである。この個人情報が漏れると、他
人がユーザＵに成り済ますことができるので、注意しな
ければならない。

【００５２】次に、ｉを認証の試行回数とする。最初は
ｋ_U0＝１，Ｒ_U0＝０（以後、インデックスの右側は試行
回数とする）とする。ｋ_Ui，Ｒ_Uiはセッション鍵を生成
するための変数である。

【００５３】以下の説明では、セッション鍵の生成方法
を３種類（それぞれｔｙｐｅａ，ｔｙｐｅｂ，ｔｙｐ
ｅｃと呼ぶ）述べる。その生成方法は、最初に適当な
タイプを選び、証明者と検証者はそのタイプを認証の始
まりから終わりまで用いる。システムは、全てのタイプ
を実装している必要はなく、最低でもそのうちの１種類
を実装していれば良い。ｋ_Uiは全てのタイプで使用する
が、Ｒ_Uiはタイプｃでしか用いない。

【００５４】本発明のアルゴリズムの全体の流れを図２
に示し、以下説明する。ここでは、ユーザＡとユーザＢ
が互いに認証し合い、セッション鍵生成に必要な情報を
配送し合うことを考える。

【００５５】まず、セッション鍵生成方法を選択する
（ステップ２０１）。前述したように、生成方法には３
種類用意しているので、どれか１つを選び、手続が終る
まではその選択したものを使用する。

【００５６】次に、ユーザＢがユーザＡの認証を行う
（ステップ２０２）。さらにユーザＡがユーザＢの認証
を行う（ステップ２０３）。ステップ２０２とステップ
２０３では、並行してセッション鍵生成のための作業も
行う。さらにステップ２０４では、認証作業を続行する
かどうかを判断する。適当な回数を繰り返したら認証を
終了する。

【００５７】最後に、お互いにセッション鍵を生成して
（ステップ２０５）、この認証及び鍵配送の手続を終了
する（ステップ２０６）。

【００５８】図２のステップ２０２について、図３を用
いて詳しく説明する。

【００５９】まず、ユーザＡは、ｒ_1i∈Ｚ_m-1を生成す
る（ステップ３０１）。さらに、「数１５」を計算し
（ステップ３０２）、また「数１６」を計算する（ステ
ップ３０３）。そして、Ｘ_1iをユーザＢに送信する（ス
テップ３０４）。

【００６０】

【数１５】

【００６１】

【数１６】

【００６２】ユーザＢは、ユーザＡからＸ_1iを受け取る
（ステップ３１１。さらにユーザＢは、乱数ｒ_2i∈Ｚ
_m-1と検査ビットｂ_1i∈{0,1}をランダムに生成する（ス
テップ３１２）。そして、「数１７」を計算し（ステッ
プ３１３）、さらに「数１８」を計算する（ステップ３
１４）。次に、ユーザＡにＸ_2iとｂ_1iを送る（ステップ
３１５）。

【００６３】

【数１７】

【００６４】

【数１８】

【００６５】ユーザＡは、ユーザＢからＸ_2iとｂ_1iを受
け取る（ステップ３０５）。さらに、ユーザＡは検査ビ
ットｂ_2i∈{0,1}をランダムに生成し（ステップ３０
６）、「数１９」を計算する（ステップ３０７）。そし
て、ユーザＢにＹ_1iと検査ビットｂ_2iを送る（ステップ
３０８）。

【００６６】

【数１９】

【００６７】ユーザＢは、ユーザＡからＹ_1iと検査ビッ
トｂ_2iを受け取る（ステップ３１６）。次に、「数２
０」であることを確認する（ステップ３１７）。ここ
で、「数２０」のＵ１はユーザＡの公開鍵、Ｓ１はユー
ザＡの秘密鍵に相当する。

【００６８】

【数２０】

【００６９】ところで、ｂ_1i＝０の場合、「数２１」で
ある。Ｘ_1iはステップ３０２でＺ_m上で計算されたもの
である。これは後にセッション鍵の生成に用いるので、
ｂ_1i＝０の時のＹ_1iを便宜上、「数２２」と記述するこ
とにする。

【００７０】

【数２１】

【００７１】

【数２２】

【００７２】もし、「数２３」と「数２４」がｍｏｄ
ｎ上で一致すれば認証を続行し（ステップ３１８）、一
致しなければ中止し、否認通知をユーザＡに送る（ステ
ップ３１９）。続行する場合（ステップ３１８）は図２
のステップ２０３に移る。

【００７３】

【数２３】

【００７４】

【数２４】

【００７５】図２のステップ２０３の詳細について、図
４を用いて説明する。ユーザＢは、「数２５」を計算し
（ステップ４１１）、ユーザＡにＹ_2iを送信する（ステ
ップ４１２）。そして、ユーザＢはセッション鍵生成の
ための演算をする（ステップ４１３）。

【００７６】

【数２５】

【００７７】具体的には図８に示すような手順で計算す
る。すなわち、ｂ_1i＝１、あるいはｂ_2i＝１の時は何も
しない（図８ステップ５０１，５０２）。ｂ_1i＝ｂ_2i＝
０の時は以下のようにする。セッション鍵の生成方法に
は３種類(ｔｙｐｅａ，ｔｙｐｅｂ，ｔｙｐｅｃ）が
あるが、最初にこの手続きに用いると決めたタイプを選
択する（ステップ５０３）。ｔｙｐｅａの場合、「数
２６」を計算する（ステップ５０４）。ｔｙｐｅｂの
場合、「数２７」を計算する（ステップ５０５）。ｔｙ
ｐｅｃの場合、「数２８」を計算する（ステップ５０
６）。

【００７８】

【数２６】

【００７９】

【数２７】

【００８０】

【数２８】

【００８１】そして、Ｒ_2i＝Ｒ_2,(i-1)＋ｒ_2i（mod (m-
1))を計算する（ステップ５０７）。

【００８２】図４に戻り、ユーザＡはユーザＢからＹ_2i
を受け取る（図４ステップ４０１）。次に、「数２９」
であることを確認するが（ステップ４０２）、もし「数
３０」が「数３１」とｍｏｄｎ上で一致すれば認証を
続行し（ステップ４０３）、一致しなければ中止し、否
認通知をユーザＢに送る（ステップ４０４）。

【００８３】

【数２９】

【００８４】

【数３０】

【００８５】

【数３１】

【００８６】ところで、ｂ_2i＝０の場合、「数３２」と
なる。ｘ_2iは図３のステップ３１３でＺ_m上で計算され
たものである。これは後にセッション鍵の生成に用いる
ので、ｂ_2i＝０の時のＹ_2iを便宜上、「数３３」と記述
することにする。

【００８７】

【数３２】

【００８８】

【数３３】

【００８９】続行する場合（ステップ４０３）は、図２
のステップ２０４に移る。

【００９０】次の図２のステップ２０４の詳細につい
て、図６を用いて詳細に説明する。

【００９１】ユーザＡは、セッション鍵生成のための演
算を行う（ステップ６０１）。

【００９２】具体的には、図８に示すように、ｂ_1i＝１
あるいはｂ_2i＝１の時は何もしない（図８のステップ８
０２）。

【００９３】しかし、ｂ_1i＝ｂ_2i＝０の時は以下のよう
にする。セッション鍵の生成方法には前述のように３種
類(ｔｙｐｅａ，ｔｙｐｅｂ，ｔｙｐｅｃ）がある
が、最初にこの手続きに用いると決めたタイプを選択す
る（ステップ８０３）。ｔｙｐｅａの場合、「数３
４」を計算する（ステップ８０４）。ｔｙｐｅｂの場
合、「数３５」を計算する（ステップ８０５）。ｔｙｐ
ｅｃの場合、「数３６」を計算する（ステップ８０
６）。

【００９４】

【数３４】

【００９５】

【数３５】

【００９６】

【数３６】

【００９７】そして、Ｒ_1i＝Ｒ_1,(i-1)＋ｒ_1i（mod (m-
1))を計算する（ステップ８０７）。

【００９８】認証の正確性を高めるには、以上の処理を
適当な回数繰り返す。そして、試行をこれ以上続けるか
どうか判断する（図６のステップ６０２）。この場合の
判断の基準は２つあり、１つは認証の正確性が充分であ
るかということである。もう１つは、ｂ_1i＝ｂ_2i＝０の
場合がなければ、有用なセッション鍵を生成できないの
で、このような場合が今までの試行であったかどうかで
ある。なければ認証を続行しなければならない。

【００９９】更に認証を続ける場合は、図２のステップ
２０２に戻り（ステップ６０４）、認証を終了する場合
は、図２のステップ２０５へ進む（ステップ６０３）。

【０１００】ここでは、試行をｋ回繰り返した後に、認
証を正常に終了し、図２のステップ２０５に移ったとし
て説明を進める。

【０１０１】図２のステップ２０５の詳細について図１
１を用いて詳細に説明する。

【０１０２】まず、ユーザＡは認証が無事に終了したこ
とをユーザＢに知らせる（ステップ７０１）。ユーザＢ
はユーザＡから認証終了の通知を受け取り（ステップ７
１１）、さらにユーザＡへ終了承認の通知を送る（ステ
ップ７１２）。ユーザＡはユーザＢからの認証終了通知
を受け取る（ステップ７０２）。

【０１０３】ここでは、ユーザＡから認証終了通知を送
り、ユーザＢがそれを認める形をとっているが、ユーザ
Ｂが未だ認証手続に不満が残るのであれば、ユーザＡに
対して認証続行の通知を送り、認証を続行させることも
できる。その場合は、図３のステップ３０１に移る。

【０１０４】ユーザＢから認証終了通知を送る場合は、
図４のステップ４１２の時に、Ｙ_2iと一緒にその通知を
ユーザＡに伝える。ユーザＡが終了に賛成であれば、ユ
ーザＢに終了承認の通知を送るが、その時期にはＹ_2iの
検証（図４のステップ４０２）の前や後が考えられる。
まだ終了しないのであれば、認証続行の通知を送り返さ
なければならない。いずれにせよ、お互いに認証終了の
承認が得られたならば、ユーザＡとユーザＢは、各々セ
ッション鍵Ｋ_Sを生成する（図７のステップ７０３，７
１３）。

【０１０５】ユーザＡは具体的には、図９のような手順
でセッション鍵Ｋ_Sを生成する。セッション鍵の生成方
法には前述したように３種類用意されているが、最初に
この手続きに用いると決めたタイプを選択する（図９ス
テップ９０１）。

【０１０６】ｔｙｐｅａの場合、「数３７」を計算す
る（ステップ９０２）。ｔｙｐｅｂの場合、「数３
８」を計算する（ステップ９０３）。ｔｙｐｅｃの場
合、「数３９」を計算する（ステップ９０４）。

【０１０７】

【数３７】

【０１０８】

【数３８】

【０１０９】

【数３９】

【０１１０】ここで、ΠとΣは、ｂ_1i＝ｂ_2i＝０である
場合の全てについての積および和である。

【０１１１】ユーザＢは具体的には図１０に示すような
手順でセッション鍵Ｋ_Sを生成する。セッション鍵の生
成方法には前述したように３種類用意されているが、最
初にこの手続きに用いると決めたタイプを選択する（図
１０のステップ１００１）。

【０１１２】ｔｙｐｅａの場合、「数４０」を計算す
る（ステップ１００２）。ｔｙｐｅｂの場合、「数４
１」を計算する（ステップ１００３）。ｔｙｐｅｃの
場合、「数４２」を計算する（ステップ１００４）。

【０１１３】

【数４０】

【０１１４】

【数４１】

【０１１５】

【数４２】

【０１１６】ここで、ΠとΣは、ｂ_1i＝ｂ_2i＝０である
場合の全てについての積および和である。

【０１１７】ここまでで、ユーザの認証とセッション鍵
の配送が終了する（図７のステップ７０４，７１４）。

【０１１８】なお、上記の説明ではｂ_1i＝ｂ_2i＝０とな
る場合のｒ_1i，ｒ_2iの組みを全て利用して計算を行なっ
ているが、最初や最後にｂ_1i＝ｂ_2i＝０となった場合の
ｒ_1i，ｒ_2iの組みのみでも構わない。ｒ_1i，ｒ_2iの組み
が１組の場合は、ｔｙｐｅａ，ｔｙｐｅｂ，ｔｙｐｅ
ｃの結果は同じである。また、ｂ_1i＝ｂ_2i＝０であるｒ
_1i，ｒ_2iの組みをある回数分だけ選択的に利用するので
も構わない。つまり、ユーザＡとユーザＢが利用するｒ
_1i，ｒ_2iの組みが同一のものであるならば、セッション
鍵はｒ_1i，ｒ_2iのどんな組み合わせで生成してもよい。

【０１１９】また説明では、１回の試行につきユーザが
発生させる乱数ｒ_1i，ｒ_2iは１つであるが、これは複数
発生させても構わない。その場合は、検査ビットｂ_1i，
ｂ_2iやその応答Ｙ_1i，Ｙ_2i等も乱数の数に応じて計算
し、認証と鍵配送作業に用いる。

【０１２０】例えば、ユーザが乱数をｓ回発生させた場
合、検査ビットを同時にｓビット送る。これで全ての検
査ビットに対して正しい応答が返ってきた場合は、１回
の認証手続きにつき、不当なユーザが正しいレスポンス
を返す確率は「数４３」となる。

【０１２１】

【数４３】

【０１２２】また、検査ビットを同時にｓビット送る場
合でも、ビット全体を１つの数として見る方法もある。
この場合も、不当なユーザが正しいレスポンスを返す確
率は、前記「数４３」となるが、用いる乱数が１つで済
むという利点がある。但し、この方法では、検査ビット
が０になる確率が、検査ビットの桁数が大きくなればな
る程小さくなる。そのため、認証は行えるが、鍵の配送
は現実的には行うことができない場合もある。但し、後
述するが、ｍ＝ｎの場合は鍵の配送も行うことができ
る。

【０１２３】また、上記説明では、ｍ＜ｎであったが、
ｍ＝ｎでも基本的には構わない。この時ｇは、「数４
４」を０以上ｍ未満のうちでｍと互いに素な整数の集合
とすると、ｇを「数４４」の生成元となるように選ぶ。
また、アルゴリズム全体の整合性を保つため、細部の計
算方法を適宜変更しなければならない。効率を考える
と、変更した方が望ましい箇所もある。

【０１２４】

【数４４】

【０１２５】例えば、ｔｙｐｅｃを使う場合、以下の
ようにアルゴリズムを変更する。今、「数４５」となる
最小の整数をｋ（これをｇの位数という）とする。ｋは
十分大きくなくてはならない。この時、ｒ_1i，ｒ_2i∈Ｚ
_nでもｒ_1i，ｒ_2i∈Ｚ_kでもよい。

【０１２６】

【数４５】

【０１２７】図５のステップ５０７はＲ_2i＝Ｒ_2,(i-1)
＋ｒ_2i（mod (k-1))に変更する。同様に、図８のステッ
プ８０７をＲ_1i＝Ｒ_1,(i-1)＋ｒ_1i（mod (k-1))に変更
する。特にｋを使わずに、図５のステップ５０７をＲ_2i
＝Ｒ_2,(i-1)＋ｒ_2iに、図８のステップ８０７をＲ_1i＝
Ｒ_1,(i-1)＋ｒ_1iに変更する方法もある。この方法は、
Ｒ_1i，Ｒ_2iが大きくなる欠点があるが、実際の運用で生
成に用いるｒ_1i，ｒ_2iの組みがそれ程多くなければ、差
し支えない。これは、ｍ＜ｎの場合にも言えることであ
る。

【０１２８】ｍ＝ｎの場合、検査ビットｂ_1i，ｂ_2iによ
るセッション鍵生成方法の制限をはずすことができる。
図５、図８においてｙ_1i，ｙ_2iの替わりにＸ_1i，Ｘ_2iを
用いることにより、ｂ_1i＝ｂ_2i＝０の場合だけでなく、
全ての場合のｒ_1i，ｒ_2iの組みを利用できるようにな
る。したがって、図５のステップ５０１、図８のステッ
プ８０１は必要なくなる。この変更により、最終的に生
成されるセッション鍵も変化するが、それは図９，図１
０においてｇを「数４６」にしたものである。

【０１２９】

【数４６】

【０１３０】また、検査ビットを同時に複数ビット送
り、それを１つの整数として認証を行う方法でも、鍵配
送が行えるようになる。

【０１３１】

【発明の効果】以上の説明から明らかなように、本発明
のＩＤベース認証・鍵配送方法においては、通信相手と
なる１対のクライアントが互いに相手を認証し合った後
に、当該１対のクライアントで共有する暗号鍵を生成
し、この暗号鍵を用いてメッセージを暗号化して通信す
るためのＩＤベース認証・鍵配送方において、それぞれ
のクライアントに、Ｕのｄ乗＝Ｓ，Ｓのｅ乗＝（Ｕのｄ
乗）のｅ乗＝Ｕ(但し、e・d＝1(mod L)）の関係の公開
鍵Ｕおよび秘密鍵Ｓを割り当てて互いの認証と暗号鍵の
生成を行うようにしたため、Ｕのｄ乗＝Ｓの関係にする
ことにより、公開鍵Ｕとしてユーザが憶え易いユーザＩ
Ｄ、住所、機器名称などを使用しても、その公開鍵をｄ
乗するだけで、秘密鍵Ｓを鍵配送センタ等で容易に作成
することができる。

【０１３２】従って、同じ通信グループ内の公開情報
（公開鍵）として、ユーザやマシンに固有の情報（ユー
ザＩＤ、名前、住所、通り名やマシン名など）や辞書に
載っているユーザに馴染みやすい単語（河川等の地理上
の単語、国や都市名、人物名や星座名等）を用いること
ができる。これらの単語はユーザに記憶し易いために、
公開情報のテーブルが不要、もしくは、その作成、保
守、復旧が容易となり、システム全体の運営・保守を容
易にすることができる。

【図面の簡単な説明】

【図１】本発明の実施形態で用いるパラメータの分類図
である。

【図２】本発明を適用した認証・鍵配送方法の実施形態
における全体の流れを示すフローチャートである。

【図３】図２のステップ２０２の詳細フローチャートで
ある。

【図４】図２ステップ２０３の詳細フローチャートであ
る。

【図５】ユーザＢがセッション鍵を生成するための中間
処理を示すフローチャートである。

【図６】図２のステップ２０４の詳細フローチャートで
ある。

【図７】図２のステップ２０５の詳細フローチャートで
ある。

【図８】ユーザＡがセッション鍵を生成するための中間
処理を示すフローチャートである。

【図９】ユーザＡがセッション鍵を生成するための最終
的な処理をあらわすフローチャートである。

【図１０】ユーザＢがセッション鍵を生成するための最
終的な処理をあらわすフローチャートである。

【図１１】本発明を適用するネットワークとその利用者
の概念図である。

【図１２】Fiat-Shamir法のフローチャートである。

【図１３】Diffie-Shamir型公開鍵配送法のフローチャ
ートである。

【符号の説明】

１１…ネットワーク、１２…ユーザＡ、１３…ユーザ
Ｂ、１４…ユーザＣ、１０１…グループ共通の情報、１
０２…センタの秘密情報、１０３…ユーザＵの秘密情
報、１０４…ユーザＶの秘密情報。

Claims

【特許請求の範囲】

【請求項１】通信相手となる１対のクライアントが互
いに相手を認証し合った後に、当該１対のクライアント
で共有する暗号鍵を生成し、この暗号鍵を用いてメッセ
ージを暗号化して通信するためのＩＤベース認証・鍵配
送方法であって、それぞれのクライアントに、Ｕのｄ乗＝Ｓ，Ｓのｅ乗＝（Ｕのｄ乗）のｅ乗＝Ｕ(但
し、e・d＝1(mod L)，(p-1)・(q-1)＝mod L でp,qは素
数）の関係の公開鍵Ｕおよび秘密鍵Ｓを割り当てて互い
の認証と暗号鍵の生成を行うことを特徴とするＩＤベー
ス認証・鍵配送方法。