JP4239573B2 - User authentication system - Google Patents
User authentication system Download PDFInfo
- Publication number
- JP4239573B2 JP4239573B2 JP2002345186A JP2002345186A JP4239573B2 JP 4239573 B2 JP4239573 B2 JP 4239573B2 JP 2002345186 A JP2002345186 A JP 2002345186A JP 2002345186 A JP2002345186 A JP 2002345186A JP 4239573 B2 JP4239573 B2 JP 4239573B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- ticket
- key
- session key
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上で利用されるユーザー認証方式及びこれを用いたユーザー認証システムに関し、特に相手側のＩＰアドレスを知らなくても相互認証が可能なユーザー認証方式及びこれを用いたユーザー認証システムに関する。
【０００２】
【従来の技術】
従来のインターネット等の汎用のネットワーク上でユーザーの認証を行う認証方式としてはKerberos認証（マサチューセッツ工科大学のAthenaプロジェクトで開発されたネットワーク上で利用されるユーザー認証方式）が存在し、Kerberos認証に関する先行技術文献としては次のようなものがある。
【０００３】
【特許文献１】
特表２００２−５０１２１８号公報
【０００４】
図９はこのような従来のユーザー認証方式を用いたユーザー認証システムの一例を示す構成ブロック図である。図９において１は他の端末との間で相互認証を行おうとする端末、２はサーバ等で構成され相互に情報を共有した端末に対してセッション鍵やチケットを提供する鍵配布センター（Key Distribution Center：以下、ＫＤＣ２と呼ぶ。）、３は端末１の相互認証の対象である端末である。
【０００５】
端末１はネットワーク等を介してＫＤＣ２と相互に接続され、端末３はネットワーク等を介して端末１に相互に接続される。
【０００６】
ここで、図９に示す従来例の動作を図１０、図１１、図１２、図１３、図１４及び図１５を用いて説明する。図１０は端末１の動作を説明するフロー図、図１１、図１２及び図１３は各端末やＫＤＣ間のデータのやり取りを説明する説明図、図１４はＫＤＣ２の動作を説明するフロー図、図１５は端末２の動作を説明するフロー図である。
【０００７】
初期状態として端末１及び端末２はＫＤＣ２との間で端末に対して設定された名称（以下、端末名称と呼ぶ。）を共有し、併せて、端末１とＫＤＣ２との間、及び、端末３とＫＤＣ２との間で共有する秘密鍵をそれぞれ保持しているものとする。
【０００８】
先ず、第１に、端末１側では”端末１の認証”の処理を行う。すなわち、図１０中”Ｓ００１”において端末１はＫＤＣ２との間で共有している秘密鍵（以下、”秘密鍵Ａ”と呼ぶ。）を用いて現在の時刻を暗号化して、自らの端末名称、ＩＰアドレス等の各種情報と共にＫＤＣ２に送信して端末１の認証を要求する。
【０００９】
図１０中”Ｓ００２”において端末１はＫＤＣ２から”秘密鍵Ａ”で暗号化されたセッション鍵（端末１とＫＤＣ２との間での通信に使用されるセッション鍵：以下、”セッション鍵Ａ”と呼ぶ。）及びＴＧＴ（Ticket-Granting-Ticket：チケット保証チケット）を受信したか否かを判断する。
【００１０】
例えば、図１１中”ＡＲ０１”に示すように端末１はＫＤＣ２に対して認証を要求し、図１１中”ＲＡ０１”に示すように”秘密鍵Ａ”で暗号化されたセッション鍵等を受信したか否かを判断する。
【００１１】
もし、図１０中”Ｓ００２”において暗号化されたセッション鍵等を受信した場合には、図１０中”Ｓ００３”において端末１は”秘密鍵Ａ”を用いて復号化し、”セッション鍵Ａ”及び”ＴＧＴ”を取得する。
【００１２】
そして、端末１が”セッション鍵Ａ”及び”ＴＧＴ”を取得した時点で、ＫＤＣ２による”端末１の認証”の処理が完了する。
【００１３】
第２に、端末１側では端末３との通信を行うための”チケットの要求”の処理を行う。すなわち、図１０中”Ｓ００４”において端末１は取得した”セッション鍵Ａ”を用いて時刻を暗号化して、通信を行いたい相手側の端末名称、取得した”ＴＧＴ”と共にＫＤＣ２に送信して端末３と通信を行うためのチケットを要求する。
【００１４】
図１０中”Ｓ００５”において端末１はＫＤＣ２から”セッション鍵Ａ”で暗号化されたセッション鍵（端末１と端末３との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｂ”と呼ぶ。）及びチケットを受信したか否かを判断する。
【００１５】
例えば、図１２中”ＴＲ１１”に示すように端末１はＫＤＣ２に対して端末３と通信を行うためのチケットを要求し、図１２中”ＲＴ１１”に示すように”セッション鍵Ａ”で暗号化されたセッション鍵及びチケット等を受信したか否かを判断する。
【００１６】
ここで、チケットとは端末３とＫＤＣ２との間で共有されている秘密鍵（以下、”秘密鍵Ｂ”と呼ぶ。）を用いてＫＤＣ２が”セッション鍵Ｂ”等を暗号化したものであって、端末３でのみ復号化が可能な情報である。
【００１７】
もし、図１０中”Ｓ００５”において暗号化されたチケット等を受信した場合には、図１０中”Ｓ００６”において端末１は”セッション鍵Ａ”を用いて復号化し、”セッション鍵Ｂ”及び”チケット”等を取得する。
【００１８】
そして、端末１が”チケット”を取得した時点で、端末３との通信を行うための”チケットの要求”の処理が完了する。
【００１９】
第３に、端末１側では端末３との間の”相互認証”の処理を行う。すなわち、図１０中”Ｓ００７”において端末１は取得した”セッション鍵Ｂ”を用いて時刻を暗号化して、取得した”チケット”と共に端末３に送信して認証を要求する。
【００２０】
図１０中”Ｓ００８”において端末１は端末３から”セッションＢ”で暗号化された時刻を受信したか否かを判断する。
【００２１】
例えば、図１３中”ＡＲ２１”に示すように端末１は端末３に対して認証を要求し、図１３中”ＲＡ２１”に示すように”セッション鍵Ｂ”で暗号化された時刻を受信したか否かを判断する。
【００２２】
もし、図１０中”Ｓ００８”において暗号化された時刻を受信した場合には、図１０中”Ｓ００９”において端末１は”セッション鍵Ｂ”を用いて復号化し、時刻を取得する。
【００２３】
図１０中”Ｓ０１０”において端末１は取得した時刻の良否を判断し、取得した時刻に問題がなければ、図１０中”Ｓ０１１”において端末１は端末３を認証する。
【００２４】
そして、端末１が”セッション鍵Ｂ”を用いて復号化した時刻に問題がなかった時点時点で、端末３との間の”相互認証”の処理が完了する。
【００２５】
すなわち、端末３が、端末３でのみ復号化が可能な情報である”チケット”から復号化により”セッション鍵Ｂ”を取得し、当該”セッション鍵Ｂ”を用いて暗号化した時刻を送信してくることにより、端末１は端末３を認証することが可能になる。
【００２６】
一方、ＫＤＣ２側では、図１４中”Ｓ１０１”においてＫＤＣ２は端末１から端末１の端末名称、ＩＰアドレス等の各種情報と共に”秘密鍵Ａ”で暗号化された現在の時刻を受信したか否かを判断する。
【００２７】
もし、図１４中”Ｓ１０１”において暗号化された時刻等を受信した場合には、図１４中”Ｓ１０２”においてＫＤＣ２は”秘密鍵Ａ”を用いて復号化し、時刻を取得する。
【００２８】
そして、図１４中”Ｓ１０３”においてＫＤＣ２は取得した時刻の良否を判断し、取得した時刻に問題がなく端末１を認証した場合には、図１４中”Ｓ１０４”においてＫＤＣ２は”秘密鍵Ａ”を用いて”セッション鍵Ａ”及び”ＴＧＴ”を暗号化して端末１に返送する。
【００２９】
図１４中”Ｓ１０５”においてＫＤＣ２は端末１から通信を行いたい端末３の端末名称、”ＴＧＴ”等の各種情報と共に”セッション鍵Ａ”で暗号化された現在の時刻を受信したか否かを判断する。
【００３０】
もし、図１４中”Ｓ１０５”において暗号化された時刻等を受信した場合には、図１４中”Ｓ１０６”においてＫＤＣ２は”セッション鍵Ａ”を用いて復号化し、時刻を取得する。
【００３１】
そして、図１４中”Ｓ１０７”においてＫＤＣ２は取得した時刻の良否を判断し、取得した時刻に問題がなく端末１を認証した場合には、図１４中”Ｓ１０８”においてＫＤＣ２は”セッション鍵Ａ”を用いて”セッション鍵Ｂ”及び”チケット”を暗号化して端末１に返送する。
【００３２】
また、端末３側では、図１５中”Ｓ２０１”において端末３は端末１から”チケット”等の各種情報と共に”セッション鍵Ｂ”で暗号化された現在の時刻を受信したか否かを判断する。
【００３３】
もし、図１５中”Ｓ２０１”において暗号化された時刻等を受信した場合には、図１５中”Ｓ２０２”において端末３は”秘密鍵Ｂ”を用いてチケットを復号化し、図１５中”Ｓ２０３”において復号化が可能であるか否かを判断する。
【００３４】
ここで、”秘密鍵Ｂ”は端末３とＫＤＣ２との間で共有されているものであるから復号化に成功すれば、当該”チケット”はＫＤＣ２が生成したものであることが証明され、端末１がＫＤＣ２から認証されていることが分かる。
【００３５】
すなわち、端末３は復号化が成功した時点で端末１を認証することが可能になる。
【００３６】
同時に、”秘密鍵Ｂ”を用いて”セッション鍵Ｂ”もまた”チケット”中に暗号化されているので、”チケット”を復号化することにより、図１５中”Ｓ２０４”において端末３は端末間のセッション鍵である”セッション鍵Ｂ”を取得することができる。
【００３７】
最後に、図１５中”Ｓ２０５”において端末３は”セッション鍵Ｂ”を用いて現在の時刻を暗号化して端末１に返送する。
【００３８】
この結果、端末１及び端末３がＫＤＣ２との間で秘密鍵等を共有しておくことにより、端末１はＫＤＣ２を介して端末３との間で相互認証が可能になり、相互認証した端末１及び端末３はＫＤＣ２から供給されたセッション鍵を用いて暗号化通信を行うことができる。
【００３９】
【発明が解決しようとする課題】
しかし、図９に示す従来のユーザー認証方式（Kerberos認証）を用いたユーザー認証システムでは、端末１が端末３との間で相互認証を行い安全な通信を確保するためには、端末１は端末３の名称及びＩＰアドレスを予め知っている必要性がある。
【００４０】
一方、近年、ホットスポット、ＳＯＨＯ（Small Office／Home Office）オフィス等端末の移動性が求められるようになり、このため、端末のＩＰアドレスは動的に変化することになり、常に固定のＩＰアドレスを有する端末はごく少数である。
【００４１】
すなわち、端末１がＩＰアドレスが動的に変化する端末３との間で相互認証を行い安全な通信を確保するためには、動的に変動する端末３のＩＰアドレスを常に把握している必要性があり、動的に変動する端末３のＩＰアドレスを常に把握することは非常に困難であると言った問題点があった。
従って本発明が解決しようとする課題は、相手側のＩＰアドレスを知らなくても相互認証が可能なユーザー認証方式及びこれを用いたユーザー認証システムを実現することにある。
【００４２】
【課題を解決するための手段】
このような課題を達成するために、本発明のうち請求項１記載の発明は、
ネットワーク上で利用されるユーザー認証システムにおいて、
ＩＰアドレスが変更された場合に端末の認証を要求する第１の端末と、ＩＰアドレスが変更された場合に端末の認証を要求すると共に前記第１の端末の間で相互認証を行う第２の端末と、前記第１の端末との間で第１の秘密鍵を、前記第２の端末との間で第２の秘密鍵をそれぞれ共有すると共に、前記第１若しくは前記第２の端末の認証の要求時に前記各端末から送信されてくる情報に基づき前記各端末のＩＰアドレスをキャッシュし、前記第２の端末が前記第１の端末の間で相互認証を行う場合、前記第２の端末の認証を行い、チケットと共にキャッシュされている前記第１の端末のＩＰアドレスを併せて前記第２の端末に送信する鍵配布センターとを備え、
前記第２の端末が、前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うための前記チケットを要求し、前記チケット共に前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して相互認証を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４７】
請求項２記載の発明は、
請求項１記載の発明であるユーザー認証システムにおいて、
前記鍵配布センターが、
前記第２の端末から端末名称、前記ＩＰアドレスと共に前記第２の秘密鍵で暗号化された時刻を受信した場合、前記第２の秘密鍵で第１のセッション鍵及びチケット保証チケットを暗号化して前記第２の端末に返送し、前記第２の端末から第１の端末名称、前記チケット保証チケットと共に前記第１のセッション鍵で暗号化された時刻を受信した場合、前記第１のセッション鍵で第２のセッション鍵、前記チケット及び前記第１の端末のＩＰアドレスを暗号化して前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４８】
請求項３記載の発明は、
請求項１記載の発明であるユーザー認証システムにおいて、
前記第１の端末が、
前記第２の端末から前記チケットを受信した場合に前記第２の端末を認証し、前記応答を前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４９】
請求項４記載の発明は、
請求項３記載の発明であるユーザー認証システムにおいて、
前記第１の端末が、
前記第２の端末から前記チケットと共に端末間のセッション鍵で暗号化された現在の時刻を受信し、前記第１の秘密鍵を用いて前記チケットの復号化が成功した場合に前記第２の端末を認証し、復号化で取得した前記端末間セッション鍵で時刻を暗号化して前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５０】
請求項５記載の発明は、
請求項１記載の発明であるユーザー認証システムにおいて、
前記第２の端末が、
前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して前記第１の端末からの応答を得ることにより前記第１の端末の認証を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５１】
請求項６記載の発明は、
請求項５記載の発明であるユーザー認証システムにおいて、
前記第２の端末が、
前記第２の秘密鍵を用いて時刻を暗号化して、自らの端末名称、ＩＰアドレスと共に前記鍵配布センターに送信して端末の認証を要求し、前記鍵配布センターから前記第２の秘密鍵で暗号化された第１のセッション鍵及びチケット保証チケットを受信した場合、前記第２の秘密鍵を用いて復号化して前記第１のセッション鍵及び前記チケット保証チケットを取得し、前記第１のセッション鍵を用いて時刻を暗号化して、第１の端末名称、前記チケット保証チケットと共に前記鍵配布センターに送信して前記チケットを要求し、前記鍵配布センターから前記第１のセッション鍵で暗号化された第２のセッション鍵、前記チケット及び前記ＩＰアドレスを受信した場合、前記第１のセッション鍵を用いて復号化して前記第２のセッション鍵、前記チケット及び前記ＩＰアドレスを取得し、前記第２のセッション鍵を用いて時刻を暗号化して前記チケットと共に前記第１の端末に送信して認証を要求し、前記第１の端末から前記第２のセッション鍵で暗号化された時刻を受信した場合、前記第２のセッション鍵を用いて復号化し取得した時刻に問題がなければ前記第１の端末を認証することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５３】
【発明の実施の形態】
以下本発明を図面を用いて詳細に説明する。図１は本発明に係るユーザー認証方式及びこれを用いたユーザー認証システムの一実施例を示す構成ブロック図である。
【００５４】
図１において４は他の端末との間で相互認証を行おうとする端末、５はサーバ等で構成され相互に情報を共有した端末に対してセッション鍵やチケットを提供する鍵配布センター（Key Distribution Center：以下、ＫＤＣ５と呼ぶ。）、６は端末４の相互認証の対象である端末である。
【００５５】
端末４はネットワーク等を介してＫＤＣ５と相互に接続され、端末６はネットワーク等を介して端末４に相互に接続される。
【００５６】
ここで、図１に示す実施例の動作を図２、図３、図４、図５、図６、図７及び図８を用いて説明する。図２は端末４及び端末６の共通の動作を説明するフロー図、図３は端末４の動作を説明するフロー図、図４、図５及び図６は各端末やＫＤＣ間のデータのやり取りを説明する説明図、図７はＫＤＣ５の動作を説明するフロー図、図８は端末６の動作を説明するフロー図である。
【００５７】
初期状態として端末４及び端末６はＫＤＣ５との間で端末に対して設定された名称（以下、端末名称と呼ぶ。）を共有し、併せて、端末４とＫＤＣ５との間、及び、端末６とＫＤＣ５との間で共有する秘密鍵をそれぞれ保持しているものとする。
【００５８】
図２中”Ｓ３０１”において端末４及び端末６は端末のＩＰアドレスが動的に変更されたか否かを判断し、もし、ＩＰアドレスが変更された場合には、図２中”Ｓ３０２”においてＫＤＣ５に対して自らの”端末の認証”の処理を行う。
【００５９】
この”端末の認証”の処理により、後述のようにＫＤＣ５に変更されたＩＰアドレスがキャッシュされることになり、ＫＤＣ５には常に最新のＩＰアドレスがキャッシュされることになる。
【００６０】
そして、第１に、端末４側では”端末４の認証”の処理を行う。すなわち、図３中”Ｓ４０１”において端末４はＫＤＣ５との間で共有している秘密鍵（以下、”秘密鍵Ｃ”と呼ぶ。）を用いて現在の時刻を暗号化して、自らの端末名称、現在のＩＰアドレス等の各種情報と共にＫＤＣ５に送信して端末４の認証を要求する。
【００６１】
図３中”Ｓ４０２”において端末４はＫＤＣ５から”秘密鍵Ｃ”で暗号化されたセッション鍵（端末４とＫＤＣ５との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｃ”と呼ぶ。）及びＴＧＴ（Ticket-Granting-Ticket：チケット保証チケット）を受信したか否かを判断する。
【００６２】
例えば、図４中”ＡＲ３１”に示すように端末４はＫＤＣ５に対して認証を要求し、図４中”ＲＡ３１”に示すように”秘密鍵Ｃ”で暗号化されたセッション鍵等を受信したか否かを判断する。
【００６３】
もし、図３中”Ｓ４０２”において暗号化されたセッション鍵等を受信した場合には、図３中”Ｓ４０３”において端末４は”秘密鍵Ｃ”を用いて復号化し、”セッション鍵Ｃ”及び”ＴＧＴ”を取得する。
【００６４】
そして、端末４が”セッション鍵Ｃ”及び”ＴＧＴ”を取得した時点で、ＫＤＣ５による”端末４の認証”の処理が完了する。
【００６５】
第２に、端末４側では端末６との通信を行うための”チケットの要求”の処理を行う。すなわち、図３中”Ｓ４０４”において端末４は取得した”セッション鍵Ｃ”を用いて時刻を暗号化して、通信を行いたい相手側の端末名称、取得した”ＴＧＴ”と共にＫＤＣ５に送信して端末６と通信を行うためのチケットを要求する。
【００６６】
図３中”Ｓ４０５”において端末４はＫＤＣ５から”セッションＣ”で暗号化されたセッション鍵（端末４と端末６との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｄ”と呼ぶ。）及びチケットを受信したか否かを判断する。
【００６７】
例えば、図５中”ＴＲ４１”に示すように端末４はＫＤＣ５に対して端末６と通信を行うためのチケットを要求し、図５中”ＲＴ４１”に示すように”セッション鍵Ｃ”で暗号化されたセッション鍵及びチケット等を受信したか否かを判断する。
【００６８】
ここで、チケットとは端末６とＫＤＣ５との間で共有されている秘密鍵（以下、”秘密鍵Ｄ”と呼ぶ。）を用いてＫＤＣ５が”セッション鍵Ｄ”等を暗号化したものであって、端末６でのみ復号化が可能な情報である。
【００６９】
もし、図３中”Ｓ４０５”において暗号化されたチケット等を受信した場合には、図３中”Ｓ４０６”において端末４は”セッション鍵Ｃ”を用いて復号化し、”セッション鍵Ｄ”、”チケット”及び”端末６のＩＰアドレス”等を取得する。
【００７０】
そして、端末４が”チケット”及び”端末６のＩＰアドレス”を取得した時点で、端末６との通信を行うための”チケットの要求”の処理が完了する。
【００７１】
第３に、端末４側では端末６との間の”相互認証”の処理を行う。すなわち、図３中”Ｓ４０７”において端末４は取得した”セッション鍵Ｄ”を用いて時刻を暗号化して、取得した”チケット”と共に端末６に送信して認証を要求する。
【００７２】
図３中”Ｓ４０８”において端末４は端末６から”セッションＤ”で暗号化された時刻を受信したか否かを判断する。
【００７３】
例えば、図６中”ＡＲ５１”に示すように端末４は端末６に対して認証を要求し、図６中”ＲＡ５１”に示すように”セッション鍵Ｄ”で暗号化された時刻を受信したか否かを判断する。
【００７４】
もし、図３中”Ｓ４０８”において暗号化された時刻を受信した場合には、図３中”Ｓ４０９”において端末４は”セッション鍵Ｄ”を用いて復号化し、時刻を取得する。
【００７５】
図３中”Ｓ４１０”において端末４は取得した時刻の良否を判断し、取得した時刻に問題がなければ、図２中”Ｓ４１１”において端末４は端末６を認証する。
【００７６】
そして、端末４が”セッション鍵Ｄ”を用いて復号化した時刻に問題がなかった時点時点で、端末６との間の”相互認証”の処理が完了する。
【００７７】
すなわち、端末６が、端末６でのみ復号化が可能な情報である”チケット”から復号化により”セッション鍵Ｄ”を取得し、当該”セッション鍵Ｄ”を用いて暗号化した時刻を送信してくることにより、端末４は端末６を認証することが可能になる。
【００７８】
一方、ＫＤＣ５側では、図７中”Ｓ５０１”においてＫＤＣ５は端末４から端末４の端末名称、現在のＩＰアドレス等の各種情報と共に”秘密鍵Ｃ”で暗号化された現在の時刻を受信したか否かを判断する。
【００７９】
もし、図７中”Ｓ５０１”において暗号化された時刻等を受信した場合には、図７中”Ｓ５０２”においてＫＤＣ２は”秘密鍵Ｃ”を用いて復号化し、時刻を取得する。
【００８０】
そして、図７中”Ｓ５０３”においてＫＤＣ５は取得した時刻の良否を判断し、取得した時刻に問題がなく端末４を認証した場合には、図７中”Ｓ５０４”においてＫＤＣ５は取得した端末４の現在のＩＰアドレスをキャッシュすると共に図７中”Ｓ５０５”において”秘密鍵Ｃ”を用いて”セッション鍵Ｃ”及び”ＴＧＴ”を暗号化して端末４に返送する。
【００８１】
図７中”Ｓ５０６”においてＫＤＣ５は端末４から通信を行いたい端末６の端末名称、”ＴＧＴ”等の各種情報と共に”セッション鍵Ｃ”で暗号化された現在の時刻を受信したか否かを判断する。
【００８２】
もし、図７中”Ｓ５０６”において暗号化された時刻等を受信した場合には、図７中”Ｓ５０７”においてＫＤＣ５は”セッション鍵Ｃ”を用いて復号化し、時刻を取得する。
【００８３】
そして、図７中”Ｓ５０８”においてＫＤＣ５は取得した時刻の良否を判断し、取得した時刻に問題がなく端末４を認証した場合には、図７中”Ｓ５０９”においてＫＤＣ５は”セッション鍵Ｃ”を用いて”セッション鍵Ｄ”、”チケット”及びキャッシュされている”端末６のＩＰアドレス”を暗号化して端末１に返送する。
【００８４】
また、端末６側では、図８中”Ｓ６０１”において端末６は端末４から”チケット”等の各種情報と共に”セッション鍵Ｄ”で暗号化された現在の時刻を受信したか否かを判断する。
【００８５】
もし、図８中”Ｓ６０１”において暗号化された時刻等を受信した場合には、図８中”Ｓ６０２”において端末６は”秘密鍵Ｄ”を用いてチケットを復号化し、図８中”Ｓ６０３”において復号化が可能であるか否かを判断する。
【００８６】
ここで、”秘密鍵Ｄ”は端末６とＫＤＣ５との間で共有されているものであるから復号化に成功すれば、当該”チケット”はＫＤＣ５が生成したものであることが証明され、端末４がＫＤＣ５から認証されていることが分かる。
【００８７】
すなわち、端末６は復号化が成功した時点で端末４を認証することが可能になる。
【００８８】
同時に、”秘密鍵Ｄ”を用いて”セッション鍵Ｄ”もまた”チケット”の中に暗号化されているので、”チケット”を復号化することにより、図８中”Ｓ６０４”において端末６は端末間のセッション鍵である”セッション鍵Ｄ”を取得することができる。
【００８９】
最後に、図８中”Ｓ６０５”において端末６は”セッション鍵Ｄ”を用いて現在の時刻を暗号化して端末４に返送する。
【００９０】
この結果、各端末がＫＤＣとの間で秘密鍵等を共有しておくと共に各端末のＩＰアドレスが変更された場合にＫＤＣに端末の認証を要求して変更されたＩＰアドレスをＫＤＣにキャッシュしておき、ＫＤＣが相手側端末との間で通信を行うためのチケットを送信する際にキャッシュされている相手側端末のＩＰアドレスを併せて送信することにより、相手側端末のＩＰアドレスを知らなくても相互認証が可能になる。
【００９１】
なお、図１に示す実施例は端末間で相互認証を行いセッション鍵を共有することにより、安全な通信を確保しているが、勿論、これに限定されるわけではない。
【００９２】
例えば、ＩＰパケットの暗号化と認証を行うセキュリティ技術であるＩＰｓｅｃ（IP Security）に適用しても構わない。
【００９３】
ＩＰｓｅｃでは、端末間でお互いの暗号鍵（IPsec Security Association）を交換して共有する必要性がある。
【００９４】
この場合には、端末間の”相互認証”の処理の過程において、暗号鍵を互いに交換すれば良い。
【００９５】
例えば、図６中”ＡＲ５１”に示すように端末４は端末６に対してチケット等を送信して認証を要求する際に、端末４が有する暗号鍵を端末６に送信し、図６中”ＲＡ５１”に示すように端末６は”セッション鍵Ｄ”で暗号化した時刻を送信する際に、端末６が有する暗号鍵を端末４に送信することにより、暗号鍵の交換を行えば良い。
【００９６】
この結果、移動性を有するために相手側端末のＩＰアドレスを知らなくてもＩＰｓｅｃを利用して暗号化通信を行うことが可能になる。
【００９７】
また、暗号鍵を相互に交換する際には、端末間の”セッション鍵Ｄ”を用いて当該暗号鍵を暗号化した上で相互に交換しても勿論構わない。この場合には、暗号鍵の交換がより安全に行うことができる。
【００９８】
また、図１に示す実施例は相互認証を行う機器の一例として端末と例示しているが、勿論、ネットワーク機能を有するコンピュータ、ＰＤＡ（Personal Digital(Data) Assistants）、ＰＨＳ（Personal Handyphone System）、携帯電話、プリンタ、スキャナ、ファクシミリ、ハブ、ルータ等の任意の機器であっても構わない。
【００９９】
【発明の効果】
以上説明したことから明らかなように、本発明によれば次のような効果がある。
請求項１，２，３，４，５及び請求項６の発明によれば、各端末がＫＤＣとの間で秘密鍵等を共有しておくと共に各端末のＩＰアドレスが変更された場合にＫＤＣに端末の認証を要求して変更されたＩＰアドレスをＫＤＣにキャッシュしておき、ＫＤＣが相手側端末との間で通信を行うためのチケットを送信する際にキャッシュされている相手側端末のＩＰアドレスを併せて送信することにより、相手側端末のＩＰアドレスを知らなくても相互認証が可能になる。
【図面の簡単な説明】
【図１】本発明に係るユーザー認証方式及びこれを用いたユーザー認証システムの一実施例を示す構成ブロック図である。
【図２】端末４及び端末６の共通の動作を説明するフロー図である。
【図３】端末４の動作を説明するフロー図である。
【図４】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図５】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図６】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図７】ＫＤＣ５の動作を説明するフロー図である。
【図８】端末６の動作を説明するフロー図である。
【図９】従来のユーザー認証方式を用いたユーザー認証システムの一例を示す構成ブロック図である。
【図１０】端末１の動作を説明するフロー図である。
【図１１】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１２】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１３】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１４】ＫＤＣ２の動作を説明するフロー図である。
【図１５】端末２の動作を説明するフロー図である。
【符号の説明】
１，３，４，６ 端末
２，５ 鍵配布センター（Key Distribution Center：ＫＤＣ）[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a user authentication method used on a network and a user authentication system using the same, and more particularly to a user authentication method capable of mutual authentication without knowing the other party's IP address and a user authentication system using the same. About.
[0002]
[Prior art]
Kerberos authentication (a user authentication method used on the network developed by the Massachusetts Institute of Technology Athena project) exists as an authentication method for authenticating users on a general-purpose network such as the Internet. The technical literature includes the following.
[0003]
[Patent Document 1]
JP-T-2002-501218
[0004]
FIG. 9 is a configuration block diagram showing an example of a user authentication system using such a conventional user authentication method. In FIG. 9, reference numeral 1 denotes a terminal that is to perform mutual authentication with another terminal, and 2 denotes a key distribution center (Key Distribution Center) that provides a session key and a ticket to terminals that are configured by a server and share information with each other. Center: hereinafter referred to as KDC 2) 3 is a terminal that is a target of mutual authentication of the terminal 1.
[0005]
The terminal 1 is connected to the KDC 2 via a network or the like, and the terminal 3 is connected to the terminal 1 via a network or the like.
[0006]
Here, the operation of the conventional example shown in FIG. 9 will be described with reference to FIGS. 10, 11, 12, 13, 14, and 15. FIG. 10 is a flowchart for explaining the operation of the terminal 1, FIGS. 11, 12 and 13 are explanatory diagrams for explaining the exchange of data between the terminals and the KDC, and FIG. 14 is a flowchart for explaining the operation of the KDC 2. 15 is a flowchart for explaining the operation of the terminal 2.
[0007]
As an initial state, the terminal 1 and the terminal 2 share a name (hereinafter referred to as a terminal name) set for the terminal with the KDC 2, and at the same time, between the terminal 1 and the KDC 2 and the terminal 3 And the secret key shared between KDC2 and KDC2.
[0008]
First, the process of “authentication of terminal 1” is performed on the terminal 1 side. That is, in “S001” in FIG. 10, the terminal 1 encrypts the current time using a secret key shared with the KDC 2 (hereinafter referred to as “secret key A”), and the terminal name of itself. The terminal 1 is sent together with various information such as an IP address to the KDC 2 to request authentication of the terminal 1.
[0009]
In “S002” in FIG. 10, the terminal 1 uses the session key encrypted with the “secret key A” from the KDC 2 (the session key used for communication between the terminal 1 and the KDC 2; hereinafter referred to as “session key A”. And TGT (Ticket-Granting-Ticket) is determined.
[0010]
For example, as shown in “AR01” in FIG. 11, the terminal 1 requests authentication from the KDC 2 and receives a session key or the like encrypted with the “secret key A” as shown in “RA01” in FIG. Determine whether or not.
[0011]
If the session key encrypted in “S002” in FIG. 10 is received, the terminal 1 decrypts using “secret key A” in “S003” in FIG. Get “TGT”.
[0012]
Then, when the terminal 1 acquires “session key A” and “TGT”, the process of “authentication of the terminal 1” by the KDC 2 is completed.
[0013]
Second, the terminal 1 side performs a “ticket request” process for communication with the terminal 3. That is, in “S004” in FIG. 10, the terminal 1 encrypts the time using the acquired “session key A”, and transmits it to the KDC 2 together with the terminal name of the other party to communicate with and the acquired “TGT”. Request a ticket to communicate with 3.
[0014]
In FIG. 10, in “S005”, the terminal 1 uses the session key encrypted with the “session key A” from the KDC 2 (the session key used for communication between the terminal 1 and the terminal 3; hereinafter, “session key B”). It is determined whether or not a ticket has been received.
[0015]
For example, as shown by “TR11” in FIG. 12, the terminal 1 requests a ticket for communicating with the terminal 3 from the KDC 2 and encrypts with the “session key A” as shown by “RT11” in FIG. It is determined whether or not the received session key and ticket are received.
[0016]
Here, the ticket is a ticket obtained by encrypting the “session key B” or the like by the KDC 2 using a secret key shared between the terminal 3 and the KDC 2 (hereinafter referred to as “secret key B”). Thus, the information can be decoded only by the terminal 3.
[0017]
If an encrypted ticket or the like is received in “S005” in FIG. 10, the terminal 1 decrypts using “session key A” in “S006” in FIG. "Ticket" etc. are acquired.
[0018]
When the terminal 1 acquires the “ticket”, the “ticket request” process for communicating with the terminal 3 is completed.
[0019]
Third, the terminal 1 performs “mutual authentication” with the terminal 3. That is, in “S007” in FIG. 10, the terminal 1 encrypts the time using the acquired “session key B” and transmits it to the terminal 3 together with the acquired “ticket” to request authentication.
[0020]
In “S008” in FIG. 10, the terminal 1 determines whether or not the time encrypted by “session B” is received from the terminal 3.
[0021]
For example, as shown in “AR21” in FIG. 13, terminal 1 requests authentication from terminal 3, and has received the time encrypted with “session key B” as shown in “RA21” in FIG. Judge whether or not.
[0022]
If the encrypted time is received in “S008” in FIG. 10, the terminal 1 decrypts using “session key B” in “S009” in FIG. 10 to obtain the time.
[0023]
In “S010” in FIG. 10, the terminal 1 determines whether the acquired time is acceptable or not, and if there is no problem with the acquired time, the terminal 1 authenticates the terminal 3 in “S011” in FIG.
[0024]
Then, when there is no problem in the time when the terminal 1 decrypts using the “session key B”, the process of “mutual authentication” with the terminal 3 is completed.
[0025]
That is, the terminal 3 obtains the “session key B” from the “ticket”, which is information that can be decrypted only by the terminal 3, and transmits the time encrypted using the “session key B”. As a result, the terminal 1 can authenticate the terminal 3.
[0026]
On the other hand, on the KDC 2 side, in “S 101” in FIG. 14, whether or not the KDC 2 has received from the terminal 1 the current time encrypted with the “secret key A” together with various information such as the terminal name and IP address of the terminal 1. Judging.
[0027]
If the encrypted time or the like in “S101” in FIG. 14 is received, the KDC 2 decrypts using “secret key A” in “S102” in FIG. 14 to obtain the time.
[0028]
Then, in “S103” in FIG. 14, the KDC 2 determines the quality of the acquired time. If there is no problem at the acquired time and the terminal 1 is authenticated, the KDC 2 in “S104” in FIG. Is used to encrypt the “session key A” and “TGT” and return them to the terminal 1.
[0029]
In FIG. 14, in “S105”, the KDC 2 determines whether or not it has received the current time encrypted with the “session key A” together with various information such as the terminal name of the terminal 3 to communicate with from the terminal 1 and “TGT”. to decide.
[0030]
If the encrypted time or the like is received in “S105” in FIG. 14, the KDC 2 decrypts using “session key A” and acquires the time in “S106” in FIG.
[0031]
Then, in “S107” in FIG. 14, the KDC 2 determines the quality of the acquired time. If there is no problem in the acquired time and the terminal 1 is authenticated, the KDC 2 in “S108” in FIG. Is used to encrypt the “session key B” and “ticket” and send them back to the terminal 1.
[0032]
On the terminal 3 side, in “S201” in FIG. 15, the terminal 3 determines whether or not the current time encrypted with the “session key B” is received from the terminal 1 together with various information such as “ticket”. .
[0033]
If the encrypted time or the like is received in “S201” in FIG. 15, the terminal 3 decrypts the ticket using “secret key B” in “S202” in FIG. 15, and “S203” in FIG. It is determined whether or not decoding is possible.
[0034]
Here, since the “secret key B” is shared between the terminal 3 and the KDC 2, if the decryption is successful, it is proved that the “ticket” is generated by the KDC 2, and the terminal It can be seen that 1 is authenticated from KDC2.
[0035]
That is, the terminal 3 can authenticate the terminal 1 when the decryption is successful.
[0036]
At the same time, the “session key B” is also encrypted in the “ticket” using the “secret key B”. Therefore, by decrypting the “ticket”, the terminal 3 in FIG. The “session key B”, which is the session key between, can be acquired.
[0037]
Finally, in “S205” in FIG. 15, the terminal 3 encrypts the current time using the “session key B” and returns it to the terminal 1.
[0038]
As a result, when the terminal 1 and the terminal 3 share a secret key or the like with the KDC 2, the terminal 1 can perform mutual authentication with the terminal 3 via the KDC 2, and the mutually authenticated terminal 1 And the terminal 3 can perform encrypted communication using the session key supplied from the KDC 2.
[0039]
[Problems to be solved by the invention]
However, in the user authentication system using the conventional user authentication method (Kerberos authentication) shown in FIG. 9, in order for the terminal 1 to perform mutual authentication with the terminal 3 and ensure secure communication, the terminal 1 3 names and IP addresses need to be known in advance.
[0040]
On the other hand, in recent years, the mobility of terminals such as hotspots and SOHO (Small Office / Home Office) offices has been demanded. For this reason, the IP address of the terminal changes dynamically, and the fixed IP address is always fixed. Very few terminals have
[0041]
That is, in order for the terminal 1 to perform mutual authentication with the terminal 3 whose IP address dynamically changes and to ensure secure communication, it is necessary to always know the IP address of the terminal 3 that dynamically changes. Therefore, there is a problem that it is very difficult to always grasp the IP address of the terminal 3 that dynamically changes.
Therefore, the problem to be solved by the present invention is to realize a user authentication method capable of mutual authentication without knowing the IP address of the other party and a user authentication system using the same.
[0042]
[Means for Solving the Problems]
In order to achieve such a problem, the invention according to claim 1 of the present invention is:
In the user authentication system used on the network,
A first terminal that requests terminal authentication when the IP address is changed, and a second terminal that requests terminal authentication when the IP address is changed and performs mutual authentication between the first terminals. A first secret key is shared between the terminal and the first terminal, and a second secret key is shared between the terminal and the second terminal, and authentication of the first or second terminal is performed. When the second terminal caches the IP address of each terminal based on information transmitted from each terminal at the time of the request, and the second terminal performs mutual authentication between the first terminals, A key distribution center that authenticates and transmits the IP address of the first terminal cached with the ticket together to the second terminal;
The second terminal requests authentication of the terminal from the key distribution center, requests the ticket for communication with the first terminal after authentication of the terminal, and the key distribution center together with the ticket The ticket is transmitted to the first terminal based on the IP address acquired from the terminal and mutual authentication is performed.As a result, mutual authentication is possible without knowing the IP address of the other party.
[0047]
Claim 2The invention of
Claim 1In the user authentication system which is the invention of
The key distribution center
When the time encrypted with the second secret key is received together with the terminal name and the IP address from the second terminal, the second secret key is used.First session keyas well asTicket guarantee ticketIs encrypted and returned to the second terminal, and the second terminalFirst terminal nameWhen the time encrypted with the first session key is received together with the ticket guarantee ticket, the first session key is used.Second session keyBy encrypting the ticket and the IP address of the first terminal and returning them to the second terminal, mutual authentication is possible without knowing the IP address of the other party.
[0048]
Claim 3The invention of
Claim 1In the user authentication system which is the invention of
The first terminal is
By authenticating the second terminal when the ticket is received from the second terminal and returning the response to the second terminal, mutual authentication is possible without knowing the other party's IP address become.
[0049]
Claim 4The invention of
Claim 3In the user authentication system which is the invention of
The first terminal is
When the current time encrypted with the session key between the terminals is received together with the ticket from the second terminal, and the ticket is successfully decrypted using the first secret key, the second terminal And encrypting the time with the inter-terminal session key obtained by decryption and returning it to the second terminal enables mutual authentication without knowing the other party's IP address.
[0050]
Claim 5The invention of
Claim 1In the user authentication system which is the invention of
The second terminal is
Requesting the key distribution center for terminal authentication, requesting a ticket for communication with the first terminal after terminal authentication, and based on the first IP address obtained from the key distribution center By authenticating the first terminal by transmitting the ticket to the terminal and obtaining a response from the first terminal, mutual authentication is possible without knowing the IP address of the other party.
[0051]
Claim 6The invention of
Claim 5In the user authentication system which is the invention of
The second terminal is
The time is encrypted using the second secret key, transmitted to the key distribution center together with its own terminal name and IP address to request authentication of the terminal, and the key distribution center uses the second secret key. When the encrypted first session key and ticket guarantee ticket are received, the first session key and the ticket guarantee ticket are obtained by decrypting using the second secret key, and the first session Encrypt time using a key,First terminal nameRequesting the ticket by sending it to the key distribution center together with the ticket guarantee ticket, and receiving the second session key encrypted with the first session key, the ticket and the IP address from the key distribution center In this case, the second session key, the ticket, and the IP address are obtained by decrypting using the first session key, and the time is encrypted using the second session key, together with the ticket. When the authentication request is sent to the first terminal and the time encrypted with the second session key is received from the first terminal, the time obtained by decrypting with the second session key If there is no problem, authentication of the first terminal enables mutual authentication without knowing the other party's IP address.
[0053]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in detail with reference to the drawings. FIG. 1 is a configuration block diagram showing an embodiment of a user authentication method and a user authentication system using the same according to the present invention.
[0054]
In FIG. 1, reference numeral 4 denotes a terminal that is to perform mutual authentication with another terminal, and 5 denotes a key distribution center (Key Distribution Center that provides a session key and a ticket to terminals that are configured by a server and share information with each other. Center: hereinafter referred to as KDC5), 6 is a terminal that is a target of mutual authentication of the terminal 4.
[0055]
The terminal 4 is mutually connected to the KDC 5 via a network or the like, and the terminal 6 is mutually connected to the terminal 4 via the network or the like.
[0056]
Here, the operation of the embodiment shown in FIG. 1 will be described with reference to FIGS. 2, 3, 4, 5, 6, 7 and 8. FIG. 2 is a flowchart for explaining operations common to the terminal 4 and the terminal 6. FIG. 3 is a flowchart for explaining operations of the terminal 4. FIGS. 4, 5, and 6 show data exchange between the terminals and the KDC. FIG. 7 is a flowchart for explaining the operation of the KDC 5, and FIG. 8 is a flowchart for explaining the operation of the terminal 6.
[0057]
As an initial state, the terminal 4 and the terminal 6 share a name (hereinafter referred to as a terminal name) set for the terminal with the KDC 5, and at the same time, between the terminal 4 and the KDC 5 and the terminal 6. And the secret key shared between KDC5 and KDC5.
[0058]
In “S301” in FIG. 2, the terminal 4 and the terminal 6 determine whether or not the IP address of the terminal has been dynamically changed. If the IP address has been changed, the KDC 5 in “S302” in FIG. The process of own “terminal authentication” is performed.
[0059]
By this “terminal authentication” process, the IP address changed to the KDC 5 is cached as will be described later, and the latest IP address is always cached in the KDC 5.
[0060]
First, the “terminal 4 authentication” process is performed on the terminal 4 side. That is, in “S401” in FIG. 3, the terminal 4 encrypts the current time using a secret key shared with the KDC 5 (hereinafter referred to as “secret key C”), and the terminal name of itself. The terminal 4 is requested to be authenticated by transmitting it to the KDC 5 together with various information such as the current IP address.
[0061]
In “S402” in FIG. 3, the terminal 4 uses the session key encrypted with the “secret key C” from the KDC 5 (the session key used for communication between the terminal 4 and the KDC 5; hereinafter referred to as “session key C”). And TGT (Ticket-Granting-Ticket) is determined.
[0062]
For example, the terminal 4 requests authentication from the KDC 5 as indicated by “AR31” in FIG. 4 and receives a session key or the like encrypted with the “secret key C” as indicated by “RA31” in FIG. Determine whether or not.
[0063]
If the session key encrypted in “S402” in FIG. 3 is received, the terminal 4 decrypts using the “secret key C” in “S403” in FIG. Get “TGT”.
[0064]
Then, when the terminal 4 acquires “session key C” and “TGT”, the process of “authentication of the terminal 4” by the KDC 5 is completed.
[0065]
Second, the terminal 4 side performs a “ticket request” process for communication with the terminal 6. That is, in “S404” in FIG. 3, the terminal 4 encrypts the time using the acquired “session key C” and transmits it to the KDC 5 together with the name of the other party to communicate with and the acquired “TGT”. Request a ticket to communicate with 6.
[0066]
In FIG. 3, in “S405”, the terminal 4 uses the session key encrypted in the “session C” from the KDC 5 (the session key used for communication between the terminal 4 and the terminal 6; hereinafter, “session key D”). And whether or not a ticket has been received.
[0067]
For example, the terminal 4 requests a ticket for communication with the terminal 6 from the KDC 5 as indicated by “TR41” in FIG. 5, and is encrypted with the “session key C” as indicated by “RT41” in FIG. It is determined whether or not the received session key and ticket are received.
[0068]
Here, the ticket is a ticket that is encrypted by the KDC 5 using the secret key shared between the terminal 6 and the KDC 5 (hereinafter referred to as “secret key D”). Thus, the information can be decoded only by the terminal 6.
[0069]
If an encrypted ticket or the like encrypted in “S405” in FIG. 3 is received, the terminal 4 decrypts using “session key C” in “S406” in FIG. “Ticket” and “IP address of terminal 6” are acquired.
[0070]
When the terminal 4 acquires “ticket” and “IP address of the terminal 6”, the processing of “ticket request” for communication with the terminal 6 is completed.
[0071]
Third, on the terminal 4 side, processing of “mutual authentication” with the terminal 6 is performed. That is, in “S407” in FIG. 3, the terminal 4 encrypts the time using the acquired “session key D” and transmits it to the terminal 6 together with the acquired “ticket” to request authentication.
[0072]
In “S408” in FIG. 3, the terminal 4 determines whether or not the time encrypted by “session D” is received from the terminal 6.
[0073]
For example, as shown in “AR51” in FIG. 6, the terminal 4 requests authentication from the terminal 6, and has received the time encrypted with the “session key D” as shown in “RA51” in FIG. 6? Judge whether or not.
[0074]
If the encrypted time is received in “S408” in FIG. 3, the terminal 4 decrypts using “session key D” in “S409” in FIG. 3 to obtain the time.
[0075]
In “S410” in FIG. 3, the terminal 4 determines whether the acquired time is acceptable or not, and if there is no problem with the acquired time, the terminal 4 authenticates the terminal 6 in “S411” in FIG.
[0076]
Then, when there is no problem with the time when the terminal 4 decrypts using the “session key D”, the “mutual authentication” process with the terminal 6 is completed.
[0077]
That is, the terminal 6 obtains the “session key D” from the “ticket”, which is information that can be decrypted only by the terminal 6, and transmits the time encrypted using the “session key D”. As a result, the terminal 4 can authenticate the terminal 6.
[0078]
On the other hand, on the KDC 5 side, in “S501” in FIG. 7, has the KDC 5 received from the terminal 4 the current time encrypted with the “secret key C” along with various information such as the terminal name of the terminal 4 and the current IP address? Judge whether or not.
[0079]
If the encrypted time or the like in “S501” in FIG. 7 is received, the KDC 2 decrypts using “secret key C” in “S502” in FIG. 7 to obtain the time.
[0080]
Then, in “S503” in FIG. 7, the KDC 5 determines the quality of the acquired time, and when there is no problem in the acquired time and authenticates the terminal 4, the KDC 5 in “S504” in FIG. The current IP address is cached, and “session key C” and “TGT” are encrypted using “secret key C” in “S505” in FIG.
[0081]
In FIG. 7, in “S506”, the KDC 5 determines whether or not it has received the current time encrypted with the “session key C” along with various information such as the terminal name of the terminal 6 to be communicated from the terminal 4 and “TGT”. to decide.
[0082]
If the encrypted time or the like in “S506” in FIG. 7 is received, the KDC 5 decrypts using “session key C” and acquires the time in “S507” in FIG.
[0083]
Then, in “S508” in FIG. 7, the KDC 5 determines the quality of the acquired time, and when there is no problem at the acquired time and authenticates the terminal 4, the KDC 5 in “S509” in FIG. Is used to encrypt the “session key D”, “ticket” and the cached “IP address of the terminal 6” and return them to the terminal 1.
[0084]
On the terminal 6 side, in “S601” in FIG. 8, the terminal 6 determines whether or not the terminal 6 has received the current time encrypted with the “session key D” together with various information such as “ticket” from the terminal 4. .
[0085]
If the encrypted time or the like is received in “S601” in FIG. 8, the terminal 6 decrypts the ticket using “secret key D” in “S602” in FIG. 8, and “S603 in FIG. 8”. It is determined whether or not decoding is possible.
[0086]
Here, since the “secret key D” is shared between the terminal 6 and the KDC 5, if the decryption is successful, it is proved that the “ticket” is generated by the KDC 5, and the terminal It can be seen that 4 is authenticated from the KDC 5.
[0087]
That is, the terminal 6 can authenticate the terminal 4 when the decryption is successful.
[0088]
At the same time, since the “session key D” is also encrypted in the “ticket” using the “secret key D”, the terminal 6 decrypts the “ticket” in “S604” in FIG. A “session key D” that is a session key between terminals can be acquired.
[0089]
Finally, in “S605” in FIG. 8, the terminal 6 encrypts the current time using the “session key D” and returns it to the terminal 4.
[0090]
As a result, each terminal shares a secret key or the like with the KDC, and when the IP address of each terminal is changed, the terminal requests the KDC to authenticate the terminal and caches the changed IP address in the KDC. In addition, when the KDC transmits a ticket for communication with the partner terminal, the IP address of the partner terminal cached is also transmitted, so that the IP address of the partner terminal is not known. But mutual authentication is possible.
[0091]
In the embodiment shown in FIG. 1, secure authentication is ensured by performing mutual authentication between terminals and sharing a session key. However, the present invention is not limited to this.
[0092]
For example, the present invention may be applied to IPsec (IP Security), which is a security technology that performs encryption and authentication of IP packets.
[0093]
In IPsec, it is necessary to exchange and share mutual encryption keys (IPsec Security Association) between terminals.
[0094]
In this case, encryption keys may be exchanged in the process of “mutual authentication” between terminals.
[0095]
For example, as shown by “AR51” in FIG. 6, when the terminal 4 transmits a ticket or the like to the terminal 6 to request authentication, the terminal 4 transmits the encryption key of the terminal 4 to the terminal 6. As shown in RA51 ", when the terminal 6 transmits the time encrypted with the" session key D ", the encryption key may be exchanged by transmitting the encryption key of the terminal 6 to the terminal 4.
[0096]
As a result, since it has mobility, it becomes possible to perform encrypted communication using IPsec without knowing the IP address of the counterpart terminal.
[0097]
Further, when exchanging encryption keys with each other, it is of course possible to exchange the encryption keys after encrypting the encryption keys using the “session key D” between the terminals. In this case, the encryption key can be exchanged more safely.
[0098]
1 illustrates a terminal as an example of a device that performs mutual authentication. Of course, a computer having a network function, a PDA (Personal Digital (Data) Assistants), a PHS (Personal Handyphone System), Any device such as a mobile phone, a printer, a scanner, a facsimile, a hub, and a router may be used.
[0099]
【The invention's effect】
As is apparent from the above description, the present invention has the following effects.
According to the inventions of claims 1, 2, 3, 4, 5 and claim 6,Each terminal shares a secret key or the like with the KDC, and when the IP address of each terminal is changed, the terminal requests the KDC to authenticate the terminal and caches the changed IP address in the KDC. When the KDC transmits a ticket for communicating with the partner terminal, the IP address of the partner terminal cached is also transmitted, so that the mutual IP address of the partner terminal can be obtained without knowing the IP address of the partner terminal. Authentication becomes possible.
[Brief description of the drawings]
FIG. 1 is a configuration block diagram showing an embodiment of a user authentication method and a user authentication system using the same according to the present invention.
FIG. 2 is a flowchart for explaining operations common to terminals 4 and 6;
FIG. 3 is a flowchart for explaining the operation of the terminal 4;
FIG. 4 is an explanatory diagram for explaining data exchange between terminals and KDC.
FIG. 5 is an explanatory diagram illustrating data exchange between terminals and KDC.
FIG. 6 is an explanatory diagram illustrating data exchange between terminals and KDC.
FIG. 7 is a flowchart for explaining the operation of the KDC 5;
FIG. 8 is a flowchart for explaining the operation of the terminal 6;
FIG. 9 is a configuration block diagram showing an example of a user authentication system using a conventional user authentication method.
FIG. 10 is a flowchart for explaining the operation of the terminal 1;
FIG. 11 is an explanatory diagram illustrating data exchange between terminals and KDC.
FIG. 12 is an explanatory diagram illustrating data exchange between terminals and KDC.
FIG. 13 is an explanatory diagram illustrating data exchange between terminals and KDC.
FIG. 14 is a flowchart for explaining the operation of the KDC 2;
FIG. 15 is a flowchart for explaining the operation of the terminal 2;
[Explanation of symbols]
1,3,4,6 terminal
2,5 Key Distribution Center (KDC)
Claims (6)
ＩＰアドレスが変更された場合に端末の認証を要求する第１の端末と、
ＩＰアドレスが変更された場合に端末の認証を要求すると共に前記第１の端末の間で相互認証を行う第２の端末と、
前記第１の端末との間で第１の秘密鍵を、前記第２の端末との間で第２の秘密鍵をそれぞれ共有すると共に、前記第１若しくは前記第２の端末の認証の要求時に前記各端末から送信されてくる情報に基づき前記各端末のＩＰアドレスをキャッシュし、前記第２の端末が前記第１の端末の間で相互認証を行う場合、前記第２の端末の認証を行い、チケットと共にキャッシュされている前記第１の端末のＩＰアドレスを併せて前記第２の端末に送信する鍵配布センターとを備え、
前記第２の端末が、前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うための前記チケットを要求し、前記チケット共に前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して相互認証を行うことを特徴とするユーザー認証システム。 In the user authentication system used on the network,
A first terminal that requests terminal authentication when the IP address is changed;
A second terminal that requests terminal authentication when the IP address is changed and performs mutual authentication between the first terminals;
The first secret key is shared with the first terminal, the second secret key is shared with the second terminal, and when the authentication of the first or the second terminal is requested. Based on the information transmitted from each terminal, the IP address of each terminal is cached, and when the second terminal performs mutual authentication between the first terminals, the second terminal is authenticated. A key distribution center that transmits the IP address of the first terminal cached with the ticket together to the second terminal,
The second terminal requests authentication of the terminal from the key distribution center, requests the ticket for communication with the first terminal after authentication of the terminal, and the key distribution center together with the ticket A user authentication system for performing mutual authentication by transmitting the ticket to the first terminal based on the IP address acquired from the server .
前記第２の端末から端末名称、前記ＩＰアドレスと共に前記第２の秘密鍵で暗号化された時刻を受信した場合、前記第２の秘密鍵で第１のセッション鍵及びチケット保証チケットを暗号化して前記第２の端末に返送し、When the time encrypted with the second secret key is received together with the terminal name and the IP address from the second terminal, the first session key and the ticket guarantee ticket are encrypted with the second secret key. Return to the second terminal,
前記第２の端末から第１の端末名称、前記チケット保証チケットと共に前記第１のセッション鍵で暗号化された時刻を受信した場合、前記第１のセッション鍵で第２のセッション鍵、前記チケット及び前記第１の端末のＩＰアドレスを暗号化して前記第２の端末に返送することを特徴とするWhen receiving the first terminal name and the time encrypted with the first session key together with the ticket guarantee ticket from the second terminal, the second session key with the first session key, the ticket, and The IP address of the first terminal is encrypted and returned to the second terminal
請求項１記載のユーザー認証システム。The user authentication system according to claim 1.
前記第２の端末から前記チケットを受信した場合に前記第２の端末を認証し、応答を前記第２の端末に返送することを特徴とするWhen the ticket is received from the second terminal, the second terminal is authenticated, and a response is returned to the second terminal.
請求項１記載のユーザー認証システム。The user authentication system according to claim 1.
前記第２の端末から前記チケットと共に端末間のセッション鍵で暗号化された現在の時刻を受信し、前記第１の秘密鍵を用いて前記チケットの復号化が成功した場合に前記第２の端末を認証し、When the current time encrypted with the session key between the terminals is received together with the ticket from the second terminal, and the ticket is successfully decrypted using the first secret key, the second terminal Authenticate
復号化で取得した前記端末間セッション鍵で時刻を暗号化して前記第２の端末に返送することを特徴とするThe time is encrypted with the inter-terminal session key obtained by decryption and returned to the second terminal.
請求項３載のユーザー認証システム。The user authentication system according to claim 3.
前記鍵配布センターに端末の認証を要求し、Request authentication of the terminal from the key distribution center,
端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、Requesting a ticket to communicate with the first terminal after authentication of the terminal;
前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して前記第１の端末からの応答を得ることにより前記第１の端末の認証を行うことを特徴とするThe first terminal is authenticated by transmitting the ticket to the first terminal based on the IP address acquired from the key distribution center and obtaining a response from the first terminal.
請求項１載のユーザー認証システム。The user authentication system according to claim 1.
前記第２の秘密鍵を用いて時刻を暗号化して、自らの端末名称、ＩＰアドレスと共に前The time is encrypted using the second secret key, and the terminal name and IP address of its own 記鍵配布センターに送信して端末の認証を要求し、Send to the key distribution center to request device authentication,
前記鍵配布センターから前記第２の秘密鍵で暗号化された第１のセッション鍵及びチケット保証チケットを受信した場合、前記第２の秘密鍵を用いて復号化して前記第１のセッション鍵及び前記チケット保証チケットを取得し、When the first session key and the ticket guarantee ticket encrypted with the second secret key are received from the key distribution center, the first session key and the ticket guarantee ticket are decrypted using the second secret key. Get a ticket guarantee ticket,
前記第１のセッション鍵を用いて時刻を暗号化して、第１の端末名称、前記チケット保証チケットと共に前記鍵配布センターに送信して前記チケットを要求し、Encrypt the time using the first session key, send the first terminal name and the ticket guarantee ticket to the key distribution center to request the ticket;
前記鍵配布センターから前記第１のセッション鍵で暗号化された第２のセッション鍵、前記チケット及び前記ＩＰアドレスを受信した場合、前記第１のセッション鍵を用いて復号化して前記第２のセッション鍵、前記チケット及び前記ＩＰアドレスを取得し、When the second session key encrypted with the first session key, the ticket, and the IP address are received from the key distribution center, the second session key is decrypted using the first session key. Obtain the key, the ticket and the IP address;
前記第２のセッション鍵を用いて時刻を暗号化して前記チケットと共に前記第１の端末に送信して認証を要求し、Encrypting the time using the second session key and sending it along with the ticket to the first terminal to request authentication;
前記第１の端末から前記第２のセッション鍵で暗号化された時刻を受信した場合、前記第２のセッション鍵を用いて復号化し取得した時刻に問題がなければ前記第１の端末を認証することを特徴とするWhen the time encrypted with the second session key is received from the first terminal, the first terminal is authenticated if there is no problem in the time obtained by decryption using the second session key. It is characterized by
請求項５記載のユーザー認証システム。The user authentication system according to claim 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002345186A JP4239573B2 (en) | 2002-11-28 | 2002-11-28 | User authentication system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002345186A JP4239573B2 (en) | 2002-11-28 | 2002-11-28 | User authentication system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004178361A JP2004178361A (en) | 2004-06-24 |
| JP4239573B2 true JP4239573B2 (en) | 2009-03-18 |
Family
ID=32706425
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002345186A Expired - Fee Related JP4239573B2 (en) | 2002-11-28 | 2002-11-28 | User authentication system |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4239573B2 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5585188B2 (en) * | 2010-04-30 | 2014-09-10 | ソニー株式会社 | Battery module, electric vehicle, and battery module discharge control method |
| JP6813030B2 (en) * | 2016-12-07 | 2021-01-13 | 大日本印刷株式会社 | Communications system |
-
2002
- 2002-11-28 JP JP2002345186A patent/JP4239573B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004178361A (en) | 2004-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100520116B1 (en) | A method for discributing the key to mutual nodes to code a key on mobile ad-hoc network and network device using thereof | |
| KR100759489B1 (en) | Method and appratus for security of ip security tunnel using public key infrastructure in a mobile communication network | |
| JP4575679B2 (en) | Wireless network handoff encryption key | |
| JP4634612B2 (en) | Improved subscriber authentication protocol | |
| JP4081724B1 (en) | Client terminal, relay server, communication system, and communication method | |
| US8046577B2 (en) | Secure IP access protocol framework and supporting network architecture | |
| US20060248337A1 (en) | Establishment of a secure communication | |
| US20070198837A1 (en) | Establishment of a secure communication | |
| EP1374533B1 (en) | Facilitating legal interception of ip connections | |
| EP1560396A2 (en) | Method and apparatus for handling authentication on IPv6 network | |
| EP1933498A1 (en) | Method, system and device for negotiating about cipher key shared by ue and external equipment | |
| WO2010078755A1 (en) | Method and system for transmitting electronic mail, wlan authentication and privacy infrastructure (wapi) terminal thereof | |
| CA2407482A1 (en) | Security link management in dynamic networks | |
| JP2002247047A (en) | Session shared key sharing method, radio terminal authenticating method, radio terminal and base station device | |
| US20080137859A1 (en) | Public key passing | |
| JP2003289301A (en) | Method of controlling network access in wireless environment, and recording medium recorded with the method | |
| JP4006403B2 (en) | Digital signature issuing device | |
| WO2010091563A1 (en) | Management method, device and system for wapi terminal certificates | |
| WO2011041962A1 (en) | Method and system for end-to-end session key negotiation which support lawful interception | |
| WO2008098453A1 (en) | A method, system and apparatus for the dhcp message transmission | |
| JP2010539839A (en) | Security method in server-based mobile Internet protocol system | |
| US7895648B1 (en) | Reliably continuing a secure connection when the address of a machine at one end of the connection changes | |
| JP4681990B2 (en) | Communication system and communication system | |
| JP3910611B2 (en) | Communication support server, communication support method, and communication support system | |
| JP4239573B2 (en) | User authentication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050208 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080128 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080414 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080606 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081202 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081215 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120109 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |