JP2004178361A - User authentication method and user authentication system using it - Google Patents
User authentication method and user authentication system using it Download PDFInfo
- Publication number
- JP2004178361A JP2004178361A JP2002345186A JP2002345186A JP2004178361A JP 2004178361 A JP2004178361 A JP 2004178361A JP 2002345186 A JP2002345186 A JP 2002345186A JP 2002345186 A JP2002345186 A JP 2002345186A JP 2004178361 A JP2004178361 A JP 2004178361A
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- ticket
- key
- distribution center
- 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.)
- Granted
Links
Images
Abstract
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上で利用されるユーザー認証方式及びこれを用いたユーザー認証システムに関し、特に相手側のＩＰアドレスを知らなくても相互認証が可能なユーザー認証方式及びこれを用いたユーザー認証システムに関する。
【０００２】
【従来の技術】
従来のインターネット等の汎用のネットワーク上でユーザーの認証を行う認証方式としてはＫｅｒｂｅｒｏｓ認証（マサチューセッツ工科大学のＡｔｈｅｎａプロジェクトで開発されたネットワーク上で利用されるユーザー認証方式）が存在し、Ｋｅｒｂｅｒｏｓ認証に関する先行技術文献としては次のようなものがある。
【０００３】
【特許文献１】
特表２００２−５０１２１８号公報
【０００４】
図９はこのような従来のユーザー認証方式を用いたユーザー認証システムの一例を示す構成ブロック図である。図９において１は他の端末との間で相互認証を行おうとする端末、２はサーバ等で構成され相互に情報を共有した端末に対してセッション鍵やチケットを提供する鍵配布センター（Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ：以下、ＫＤＣ２と呼ぶ。）、３は端末１の相互認証の対象である端末である。
【０００５】
端末１はネットワーク等を介してＫＤＣ２と相互に接続され、端末３はネットワーク等を介して端末１に相互に接続される。
【０００６】
ここで、図９に示す従来例の動作を図１０、図１１、図１２、図１３、図１４及び図１５を用いて説明する。図１０は端末１の動作を説明するフロー図、図１１、図１２及び図１３は各端末やＫＤＣ間のデータのやり取りを説明する説明図、図１４はＫＤＣ２の動作を説明するフロー図、図１５は端末２の動作を説明するフロー図である。
【０００７】
初期状態として端末１及び端末２はＫＤＣ２との間で端末に対して設定された名称（以下、端末名称と呼ぶ。）を共有し、併せて、端末１とＫＤＣ２との間、及び、端末３とＫＤＣ２との間で共有する秘密鍵をそれぞれ保持しているものとする。
【０００８】
先ず、第１に、端末１側では”端末１の認証”の処理を行う。すなわち、図１０中”Ｓ００１”において端末１はＫＤＣ２との間で共有している秘密鍵（以下、”秘密鍵Ａ”と呼ぶ。）を用いて現在の時刻を暗号化して、自らの端末名称、ＩＰアドレス等の各種情報と共にＫＤＣ２に送信して端末１の認証を要求する。
【０００９】
図１０中”Ｓ００２”において端末１はＫＤＣ２から”秘密鍵Ａ”で暗号化されたセッション鍵（端末１とＫＤＣ２との間での通信に使用されるセッション鍵：以下、”セッション鍵Ａ”と呼ぶ。）及びＴＧＴ（Ｔｉｃｋｅｔ−Ｇｒａｎｔｉｎｇ−Ｔｉｃｋｅｔ：チケット保証チケット）を受信したか否かを判断する。
【００１０】
例えば、図１１中”ＡＲ０１”に示すように端末１はＫＤＣ２に対して認証を要求し、図１１中”ＲＡ０１”に示すように”秘密鍵Ａ”で暗号化されたセッション鍵等を受信したか否かを判断する。
【００１１】
もし、図１０中”Ｓ００２”において暗号化されたセッション鍵等を受信した場合には、図１０中”Ｓ００３”において端末１は”秘密鍵Ａ”を用いて復号化し、”セッション鍵Ａ”及び”ＴＧＴ”を取得する。
【００１２】
そして、端末１が”セッション鍵Ａ”及び”ＴＧＴ”を取得した時点で、ＫＤＣ２による”端末１の認証”の処理が完了する。
【００１３】
第２に、端末１側では端末３との通信を行うための”チケットの要求”の処理を行う。すなわち、図１０中”Ｓ００４”において端末１は取得した”セッション鍵Ａ”を用いて時刻を暗号化して、通信を行いたい相手側の端末名称、取得した”ＴＧＴ”と共にＫＤＣ２に送信して端末３と通信を行うためのチケットを要求する。
【００１４】
図１０中”Ｓ００５”において端末１はＫＤＣ２から”セッション鍵Ａ”で暗号化されたセッション鍵（端末１と端末３との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｂ”と呼ぶ。）及びチケットを受信したか否かを判断する。
【００１５】
例えば、図１２中”ＴＲ１１”に示すように端末１はＫＤＣ２に対して端末３と通信を行うためのチケットを要求し、図１２中”ＲＴ１１”に示すように”セッション鍵Ａ”で暗号化されたセッション鍵及びチケット等を受信したか否かを判断する。
【００１６】
ここで、チケットとは端末３とＫＤＣ２との間で共有されている秘密鍵（以下、”秘密鍵Ｂ”と呼ぶ。）を用いてＫＤＣ２が”セッション鍵Ｂ”等を暗号化したものであって、端末３でのみ復号化が可能な情報である。
【００１７】
もし、図１０中”Ｓ００５”において暗号化されたチケット等を受信した場合には、図１０中”Ｓ００６”において端末１は”セッション鍵Ａ”を用いて復号化し、”セッション鍵Ｂ”及び”チケット”等を取得する。
【００１８】
そして、端末１が”チケット”を取得した時点で、端末３との通信を行うための”チケットの要求”の処理が完了する。
【００１９】
第３に、端末１側では端末３との間の”相互認証”の処理を行う。すなわち、図１０中”Ｓ００７”において端末１は取得した”セッション鍵Ｂ”を用いて時刻を暗号化して、取得した”チケット”と共に端末３に送信して認証を要求する。
【００２０】
図１０中”Ｓ００８”において端末１は端末３から”セッションＢ”で暗号化された時刻を受信したか否かを判断する。
【００２１】
例えば、図１３中”ＡＲ２１”に示すように端末１は端末３に対して認証を要求し、図１３中”ＲＡ２１”に示すように”セッション鍵Ｂ”で暗号化された時刻を受信したか否かを判断する。
【００２２】
もし、図１０中”Ｓ００８”において暗号化された時刻を受信した場合には、図１０中”Ｓ００９”において端末１は”セッション鍵Ｂ”を用いて復号化し、時刻を取得する。
【００２３】
図１０中”Ｓ０１０”において端末１は取得した時刻の良否を判断し、取得した時刻に問題がなければ、図１０中”Ｓ０１１”において端末１は端末３を認証する。
【００２４】
そして、端末１が”セッション鍵Ｂ”を用いて復号化した時刻に問題がなかった時点時点で、端末３との間の”相互認証”の処理が完了する。
【００２５】
すなわち、端末３が、端末３でのみ復号化が可能な情報である”チケット”から復号化により”セッション鍵Ｂ”を取得し、当該”セッション鍵Ｂ”を用いて暗号化した時刻を送信してくることにより、端末１は端末３を認証することが可能になる。
【００２６】
一方、ＫＤＣ２側では、図１４中”Ｓ１０１”においてＫＤＣ２は端末１から端末１の端末名称、ＩＰアドレス等の各種情報と共に”秘密鍵Ａ”で暗号化された現在の時刻を受信したか否かを判断する。
【００２７】
もし、図１４中”Ｓ１０１”において暗号化された時刻等を受信した場合には、図１４中”Ｓ１０２”においてＫＤＣ２は”秘密鍵Ａ”を用いて復号化し、時刻を取得する。
【００２８】
そして、図１４中”Ｓ１０３”においてＫＤＣ２は取得した時刻の良否を判断し、取得した時刻に問題がなく端末１を認証した場合には、図１４中”Ｓ１０４”においてＫＤＣ２は”秘密鍵Ａ”を用いて”セッション鍵Ａ”及び”ＴＧＴ”を暗号化して端末１に返送する。
【００２９】
図１４中”Ｓ１０５”においてＫＤＣ２は端末１から通信を行いたい端末３の端末名称、”ＴＧＴ”等の各種情報と共に”セッション鍵Ａ”で暗号化された現在の時刻を受信したか否かを判断する。
【００３０】
もし、図１４中”Ｓ１０５”において暗号化された時刻等を受信した場合には、図１４中”Ｓ１０６”においてＫＤＣ２は”セッション鍵Ａ”を用いて復号化し、時刻を取得する。
【００３１】
そして、図１４中”Ｓ１０７”においてＫＤＣ２は取得した時刻の良否を判断し、取得した時刻に問題がなく端末１を認証した場合には、図１４中”Ｓ１０８”においてＫＤＣ２は”セッション鍵Ａ”を用いて”セッション鍵Ｂ”及び”チケット”を暗号化して端末１に返送する。
【００３２】
また、端末３側では、図１５中”Ｓ２０１”において端末３は端末１から”チケット”等の各種情報と共に”セッション鍵Ｂ”で暗号化された現在の時刻を受信したか否かを判断する。
【００３３】
もし、図１５中”Ｓ２０１”において暗号化された時刻等を受信した場合には、図１５中”Ｓ２０２”において端末３は”秘密鍵Ｂ”を用いてチケットを復号化し、図１５中”Ｓ２０３”において復号化が可能であるか否かを判断する。
【００３４】
ここで、”秘密鍵Ｂ”は端末３とＫＤＣ２との間で共有されているものであるから復号化に成功すれば、当該”チケット”はＫＤＣ２が生成したものであることが証明され、端末１がＫＤＣ２から認証されていることが分かる。
【００３５】
すなわち、端末３は復号化が成功した時点で端末１を認証することが可能になる。
【００３６】
同時に、”秘密鍵Ｂ”を用いて”セッション鍵Ｂ”もまた”チケット”中に暗号化されているので、”チケット”を復号化することにより、図１５中”Ｓ２０４”において端末３は端末間のセッション鍵である”セッション鍵Ｂ”を取得することができる。
【００３７】
最後に、図１５中”Ｓ２０５”において端末３は”セッション鍵Ｂ”を用いて現在の時刻を暗号化して端末１に返送する。
【００３８】
この結果、端末１及び端末３がＫＤＣ２との間で秘密鍵等を共有しておくことにより、端末１はＫＤＣ２を介して端末３との間で相互認証が可能になり、相互認証した端末１及び端末３はＫＤＣ２から供給されたセッション鍵を用いて暗号化通信を行うことができる。
【００３９】
【発明が解決しようとする課題】
しかし、図９に示す従来のユーザー認証方式（Ｋｅｒｂｅｒｏｓ認証）を用いたユーザー認証システムでは、端末１が端末３との間で相互認証を行い安全な通信を確保するためには、端末１は端末３の名称及びＩＰアドレスを予め知っている必要性がある。
【００４０】
一方、近年、ホットスポット、ＳＯＨＯ（Ｓｍａｌｌ Ｏｆｆｉｃｅ／Ｈｏｍｅ Ｏｆｆｉｃｅ）オフィス等端末の移動性が求められるようになり、このため、端末のＩＰアドレスは動的に変化することになり、常に固定のＩＰアドレスを有する端末はごく少数である。
【００４１】
すなわち、端末１がＩＰアドレスが動的に変化する端末３との間で相互認証を行い安全な通信を確保するためには、動的に変動する端末３のＩＰアドレスを常に把握している必要性があり、動的に変動する端末３のＩＰアドレスを常に把握することは非常に困難であると言った問題点があった。
従って本発明が解決しようとする課題は、相手側のＩＰアドレスを知らなくても相互認証が可能なユーザー認証方式及びこれを用いたユーザー認証システムを実現することにある。
【００４２】
【課題を解決するための手段】
このような課題を達成するために、本発明のうち請求項１記載の発明は、
ネットワーク上で利用されるユーザー認証方式であって、
第１及び第２の端末が鍵配布センターとの間でそれぞれの秘密鍵を共有すると共に前記第１及び第２の端末のＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求して変更されたＩＰアドレスを前記鍵配布センターにキャッシュしておき、
前記第１の端末が前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末が前記第２の端末との間で通信を行うためのチケットを前記鍵配布センターに要求し、前記鍵配布センターが前記チケットと共にキャッシュされている前記第２の端末のＩＰアドレスを併せて前記第１の端末に送信し、前記第１の端末が前記ＩＰアドレスに基づき前記第２の端末に前記チケットを送信して前記第２の端末からの応答を得ることにより相互認証を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４３】
請求項２記載の発明は、
請求項１記載の発明であるユーザー認証方式において、
前記相互認証の過程においてＩＰパケットの暗号化と認証を行うセキュリティ技術であるＩＰｓｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙ）で用いられる暗号鍵の交換を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４４】
請求項３記載の発明は、
ネットワーク上で利用されるユーザー認証方式を用いたユーザー認証システムにおいて、
鍵配布センターと、この鍵配布センターとの間で第１の秘密鍵を共有すると共にＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求する第１の端末と、前記鍵配布センターとの間で第２の秘密鍵を共有すると共にＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求するものであって、前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、前記チケット共に前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して相互認証を行う第２の端末とを備えたことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４５】
請求項４記載の発明は、
請求項３記載の発明であるユーザー認証システムにおいて、
前記鍵配布センターが、
端末の認証の要求時に前記各端末から送信されてくる情報に基づき前記各端末のＩＰアドレスをキャッシュすることにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４６】
請求項５記載の発明は、
請求項４記載の発明であるユーザー認証システムにおいて、
前記鍵配布センターが、
前記第２の端末の認証を行い、前記チケットと共にキャッシュされている前記第１の端末のＩＰアドレスを併せて前記第２の端末に送信することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４７】
請求項６記載の発明は、
請求項５記載の発明であるユーザー認証システムにおいて、
前記鍵配布センターが、
前記第２の端末から端末名称、前記ＩＰアドレスと共に前記第２の秘密鍵で暗号化された時刻を受信した場合、前記第２の秘密鍵で前記第１のセッション鍵及び前記チケット保証チケットを暗号化して前記第２の端末に返送し、前記第２の端末から前記第１の端末名称、前記チケット保証チケットと共に前記第１のセッション鍵で暗号化された時刻を受信した場合、前記第１のセッション鍵で前記第２のセッション鍵、前記チケット及び前記第１の端末のＩＰアドレスを暗号化して前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４８】
請求項７記載の発明は、
請求項３記載の発明であるユーザー認証システムにおいて、
前記第１の端末が、
前記第２の端末から前記チケットを受信した場合に前記第２の端末を認証し、前記応答を前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００４９】
請求項８記載の発明は、
請求項７記載の発明であるユーザー認証システムにおいて、
前記第１の端末が、
前記第２の端末から前記チケットと共に端末間のセッション鍵で暗号化された現在の時刻を受信し、前記第１の秘密鍵を用いて前記チケットの復号化が成功した場合に前記第２の端末を認証し、復号化で取得した前記端末間セッション鍵で時刻を暗号化して前記第２の端末に返送することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５０】
請求項９記載の発明は、
請求項３記載の発明であるユーザー認証システムにおいて、
前記第２の端末が、
前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して前記第１の端末からの応答を得ることにより前記第１の端末の認証を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５１】
請求項１０記載の発明は、
請求項９記載の発明であるユーザー認証システムにおいて、
前記第２の端末が、
前記第２の秘密鍵を用いて時刻を暗号化して、自らの端末名称、ＩＰアドレスと共に前記鍵配布センターに送信して端末の認証を要求し、前記鍵配布センターから前記第２の秘密鍵で暗号化された第１のセッション鍵及びチケット保証チケットを受信した場合、前記第２の秘密鍵を用いて復号化して前記第１のセッション鍵及び前記チケット保証チケットを取得し、前記第１のセッション鍵を用いて時刻を暗号化して、前記第１の端末名称、前記チケット保証チケットと共に前記鍵配布センターに送信して前記チケットを要求し、前記鍵配布センターから前記第１のセッション鍵で暗号化された第２のセッション鍵、前記チケット及び前記ＩＰアドレスを受信した場合、前記第１のセッション鍵を用いて復号化して前記第２のセッション鍵、前記チケット及び前記ＩＰアドレスを取得し、前記第２のセッション鍵を用いて時刻を暗号化して前記チケットと共に前記第１の端末に送信して認証を要求し、前記第１の端末から前記第２のセッション鍵で暗号化された時刻を受信した場合、前記第２のセッション鍵を用いて復号化し取得した時刻に問題がなければ前記第１の端末を認証することにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５２】
請求項１１記載の発明は、
請求項３記載の発明であるユーザー認証システムにおいて、
前記第１の端末と前記第２の端末間の相互認証の過程においてＩＰパケットの暗号化と認証を行うセキュリティ技術であるＩＰｓｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙ）で用いられる暗号鍵の交換を行うことにより、相手側のＩＰアドレスを知らなくても相互認証が可能になる。
【００５３】
【発明の実施の形態】
以下本発明を図面を用いて詳細に説明する。図１は本発明に係るユーザー認証方式及びこれを用いたユーザー認証システムの一実施例を示す構成ブロック図である。
【００５４】
図１において４は他の端末との間で相互認証を行おうとする端末、５はサーバ等で構成され相互に情報を共有した端末に対してセッション鍵やチケットを提供する鍵配布センター（Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ：以下、ＫＤＣ５と呼ぶ。）、６は端末４の相互認証の対象である端末である。
【００５５】
端末４はネットワーク等を介してＫＤＣ５と相互に接続され、端末６はネットワーク等を介して端末４に相互に接続される。
【００５６】
ここで、図１に示す実施例の動作を図２、図３、図４、図５、図６、図７及び図８を用いて説明する。図２は端末４及び端末６の共通の動作を説明するフロー図、図３は端末４の動作を説明するフロー図、図４、図５及び図６は各端末やＫＤＣ間のデータのやり取りを説明する説明図、図７はＫＤＣ５の動作を説明するフロー図、図８は端末６の動作を説明するフロー図である。
【００５７】
初期状態として端末４及び端末６はＫＤＣ５との間で端末に対して設定された名称（以下、端末名称と呼ぶ。）を共有し、併せて、端末４とＫＤＣ５との間、及び、端末６とＫＤＣ５との間で共有する秘密鍵をそれぞれ保持しているものとする。
【００５８】
図２中”Ｓ３０１”において端末４及び端末６は端末のＩＰアドレスが動的に変更されたか否かを判断し、もし、ＩＰアドレスが変更された場合には、図２中”Ｓ３０２”においてＫＤＣ５に対して自らの”端末の認証”の処理を行う。
【００５９】
この”端末の認証”の処理により、後述のようにＫＤＣ５に変更されたＩＰアドレスがキャッシュされることになり、ＫＤＣ５には常に最新のＩＰアドレスがキャッシュされることになる。
【００６０】
そして、第１に、端末４側では”端末４の認証”の処理を行う。すなわち、図３中”Ｓ４０１”において端末４はＫＤＣ５との間で共有している秘密鍵（以下、”秘密鍵Ｃ”と呼ぶ。）を用いて現在の時刻を暗号化して、自らの端末名称、現在のＩＰアドレス等の各種情報と共にＫＤＣ５に送信して端末４の認証を要求する。
【００６１】
図３中”Ｓ４０２”において端末４はＫＤＣ５から”秘密鍵Ｃ”で暗号化されたセッション鍵（端末４とＫＤＣ５との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｃ”と呼ぶ。）及びＴＧＴ（Ｔｉｃｋｅｔ−Ｇｒａｎｔｉｎｇ−Ｔｉｃｋｅｔ：チケット保証チケット）を受信したか否かを判断する。
【００６２】
例えば、図４中”ＡＲ３１”に示すように端末４はＫＤＣ５に対して認証を要求し、図４中”ＲＡ３１”に示すように”秘密鍵Ｃ”で暗号化されたセッション鍵等を受信したか否かを判断する。
【００６３】
もし、図３中”Ｓ４０２”において暗号化されたセッション鍵等を受信した場合には、図３中”Ｓ４０３”において端末４は”秘密鍵Ｃ”を用いて復号化し、”セッション鍵Ｃ”及び”ＴＧＴ”を取得する。
【００６４】
そして、端末４が”セッション鍵Ｃ”及び”ＴＧＴ”を取得した時点で、ＫＤＣ５による”端末４の認証”の処理が完了する。
【００６５】
第２に、端末４側では端末６との通信を行うための”チケットの要求”の処理を行う。すなわち、図３中”Ｓ４０４”において端末４は取得した”セッション鍵Ｃ”を用いて時刻を暗号化して、通信を行いたい相手側の端末名称、取得した”ＴＧＴ”と共にＫＤＣ５に送信して端末６と通信を行うためのチケットを要求する。
【００６６】
図３中”Ｓ４０５”において端末４はＫＤＣ５から”セッションＣ”で暗号化されたセッション鍵（端末４と端末６との間での通信に使用されるセッション鍵：以下、”セッション鍵Ｄ”と呼ぶ。）及びチケットを受信したか否かを判断する。
【００６７】
例えば、図５中”ＴＲ４１”に示すように端末４はＫＤＣ５に対して端末６と通信を行うためのチケットを要求し、図５中”ＲＴ４１”に示すように”セッション鍵Ｃ”で暗号化されたセッション鍵及びチケット等を受信したか否かを判断する。
【００６８】
ここで、チケットとは端末６とＫＤＣ５との間で共有されている秘密鍵（以下、”秘密鍵Ｄ”と呼ぶ。）を用いてＫＤＣ５が”セッション鍵Ｄ”等を暗号化したものであって、端末６でのみ復号化が可能な情報である。
【００６９】
もし、図３中”Ｓ４０５”において暗号化されたチケット等を受信した場合には、図３中”Ｓ４０６”において端末４は”セッション鍵Ｃ”を用いて復号化し、”セッション鍵Ｄ”、”チケット”及び”端末６のＩＰアドレス”等を取得する。
【００７０】
そして、端末４が”チケット”及び”端末６のＩＰアドレス”を取得した時点で、端末６との通信を行うための”チケットの要求”の処理が完了する。
【００７１】
第３に、端末４側では端末６との間の”相互認証”の処理を行う。すなわち、図３中”Ｓ４０７”において端末４は取得した”セッション鍵Ｄ”を用いて時刻を暗号化して、取得した”チケット”と共に端末６に送信して認証を要求する。
【００７２】
図３中”Ｓ４０８”において端末４は端末６から”セッションＤ”で暗号化された時刻を受信したか否かを判断する。
【００７３】
例えば、図６中”ＡＲ５１”に示すように端末４は端末６に対して認証を要求し、図６中”ＲＡ５１”に示すように”セッション鍵Ｄ”で暗号化された時刻を受信したか否かを判断する。
【００７４】
もし、図３中”Ｓ４０８”において暗号化された時刻を受信した場合には、図３中”Ｓ４０９”において端末４は”セッション鍵Ｄ”を用いて復号化し、時刻を取得する。
【００７５】
図３中”Ｓ４１０”において端末４は取得した時刻の良否を判断し、取得した時刻に問題がなければ、図２中”Ｓ４１１”において端末４は端末６を認証する。
【００７６】
そして、端末４が”セッション鍵Ｄ”を用いて復号化した時刻に問題がなかった時点時点で、端末６との間の”相互認証”の処理が完了する。
【００７７】
すなわち、端末６が、端末６でのみ復号化が可能な情報である”チケット”から復号化により”セッション鍵Ｄ”を取得し、当該”セッション鍵Ｄ”を用いて暗号化した時刻を送信してくることにより、端末４は端末６を認証することが可能になる。
【００７８】
一方、ＫＤＣ５側では、図７中”Ｓ５０１”においてＫＤＣ５は端末４から端末４の端末名称、現在のＩＰアドレス等の各種情報と共に”秘密鍵Ｃ”で暗号化された現在の時刻を受信したか否かを判断する。
【００７９】
もし、図７中”Ｓ５０１”において暗号化された時刻等を受信した場合には、図７中”Ｓ５０２”においてＫＤＣ２は”秘密鍵Ｃ”を用いて復号化し、時刻を取得する。
【００８０】
そして、図７中”Ｓ５０３”においてＫＤＣ５は取得した時刻の良否を判断し、取得した時刻に問題がなく端末４を認証した場合には、図７中”Ｓ５０４”においてＫＤＣ５は取得した端末４の現在のＩＰアドレスをキャッシュすると共に図７中”Ｓ５０５”において”秘密鍵Ｃ”を用いて”セッション鍵Ｃ”及び”ＴＧＴ”を暗号化して端末４に返送する。
【００８１】
図７中”Ｓ５０６”においてＫＤＣ５は端末４から通信を行いたい端末６の端末名称、”ＴＧＴ”等の各種情報と共に”セッション鍵Ｃ”で暗号化された現在の時刻を受信したか否かを判断する。
【００８２】
もし、図７中”Ｓ５０６”において暗号化された時刻等を受信した場合には、図７中”Ｓ５０７”においてＫＤＣ５は”セッション鍵Ｃ”を用いて復号化し、時刻を取得する。
【００８３】
そして、図７中”Ｓ５０８”においてＫＤＣ５は取得した時刻の良否を判断し、取得した時刻に問題がなく端末４を認証した場合には、図７中”Ｓ５０９”においてＫＤＣ５は”セッション鍵Ｃ”を用いて”セッション鍵Ｄ”、”チケット”及びキャッシュされている”端末６のＩＰアドレス”を暗号化して端末１に返送する。
【００８４】
また、端末６側では、図８中”Ｓ６０１”において端末６は端末４から”チケット”等の各種情報と共に”セッション鍵Ｄ”で暗号化された現在の時刻を受信したか否かを判断する。
【００８５】
もし、図８中”Ｓ６０１”において暗号化された時刻等を受信した場合には、図８中”Ｓ６０２”において端末６は”秘密鍵Ｄ”を用いてチケットを復号化し、図８中”Ｓ６０３”において復号化が可能であるか否かを判断する。
【００８６】
ここで、”秘密鍵Ｄ”は端末６とＫＤＣ５との間で共有されているものであるから復号化に成功すれば、当該”チケット”はＫＤＣ５が生成したものであることが証明され、端末４がＫＤＣ５から認証されていることが分かる。
【００８７】
すなわち、端末６は復号化が成功した時点で端末４を認証することが可能になる。
【００８８】
同時に、”秘密鍵Ｄ”を用いて”セッション鍵Ｄ”もまた”チケット”の中に暗号化されているので、”チケット”を復号化することにより、図８中”Ｓ６０４”において端末６は端末間のセッション鍵である”セッション鍵Ｄ”を取得することができる。
【００８９】
最後に、図８中”Ｓ６０５”において端末６は”セッション鍵Ｄ”を用いて現在の時刻を暗号化して端末４に返送する。
【００９０】
この結果、各端末がＫＤＣとの間で秘密鍵等を共有しておくと共に各端末のＩＰアドレスが変更された場合にＫＤＣに端末の認証を要求して変更されたＩＰアドレスをＫＤＣにキャッシュしておき、ＫＤＣが相手側端末との間で通信を行うためのチケットを送信する際にキャッシュされている相手側端末のＩＰアドレスを併せて送信することにより、相手側端末のＩＰアドレスを知らなくても相互認証が可能になる。
【００９１】
なお、図１に示す実施例は端末間で相互認証を行いセッション鍵を共有することにより、安全な通信を確保しているが、勿論、これに限定されるわけではない。
【００９２】
例えば、ＩＰパケットの暗号化と認証を行うセキュリティ技術であるＩＰｓｅｃ（ＩＰ Ｓｅｃｕｒｉｔｙ）に適用しても構わない。
【００９３】
ＩＰｓｅｃでは、端末間でお互いの暗号鍵（ＩＰｓｅｃ Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）を交換して共有する必要性がある。
【００９４】
この場合には、端末間の”相互認証”の処理の過程において、暗号鍵を互いに交換すれば良い。
【００９５】
例えば、図６中”ＡＲ５１”に示すように端末４は端末６に対してチケット等を送信して認証を要求する際に、端末４が有する暗号鍵を端末６に送信し、図６中”ＲＡ５１”に示すように端末６は”セッション鍵Ｄ”で暗号化した時刻を送信する際に、端末６が有する暗号鍵を端末４に送信することにより、暗号鍵の交換を行えば良い。
【００９６】
この結果、移動性を有するために相手側端末のＩＰアドレスを知らなくてもＩＰｓｅｃを利用して暗号化通信を行うことが可能になる。
【００９７】
また、暗号鍵を相互に交換する際には、端末間の”セッション鍵Ｄ”を用いて当該暗号鍵を暗号化した上で相互に交換しても勿論構わない。この場合には、暗号鍵の交換がより安全に行うことができる。
【００９８】
また、図１に示す実施例は相互認証を行う機器の一例として端末と例示しているが、勿論、ネットワーク機能を有するコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ（Ｄａｔａ） Ａｓｓｉｓｔａｎｔｓ）、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）、携帯電話、プリンタ、スキャナ、ファクシミリ、ハブ、ルータ等の任意の機器であっても構わない。
【００９９】
【発明の効果】
以上説明したことから明らかなように、本発明によれば次のような効果がある。
請求項１，２，３，４，５，６，７，８，９，１０及び請求項１１の発明によれば、各端末がＫＤＣとの間で秘密鍵等を共有しておくと共に各端末のＩＰアドレスが変更された場合にＫＤＣに端末の認証を要求して変更されたＩＰアドレスをＫＤＣにキャッシュしておき、ＫＤＣが相手側端末との間で通信を行うためのチケットを送信する際にキャッシュされている相手側端末のＩＰアドレスを併せて送信することにより、相手側端末のＩＰアドレスを知らなくても相互認証が可能になる。
【図面の簡単な説明】
【図１】本発明に係るユーザー認証方式及びこれを用いたユーザー認証システムの一実施例を示す構成ブロック図である。
【図２】端末４及び端末６の共通の動作を説明するフロー図である。
【図３】端末４の動作を説明するフロー図である。
【図４】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図５】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図６】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図７】ＫＤＣ５の動作を説明するフロー図である。
【図８】端末６の動作を説明するフロー図である。
【図９】従来のユーザー認証方式を用いたユーザー認証システムの一例を示す構成ブロック図である。
【図１０】端末１の動作を説明するフロー図である。
【図１１】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１２】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１３】各端末やＫＤＣ間のデータのやり取りを説明する説明図である。
【図１４】ＫＤＣ２の動作を説明するフロー図である。
【図１５】端末２の動作を説明するフロー図である。
【符号の説明】
１，３，４，６ 端末
２，５ 鍵配布センター（Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｃｅｎｔｅｒ：ＫＤＣ）[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a user authentication system used on a network and a user authentication system using the same, and more particularly to a user authentication system capable of performing mutual authentication without knowing the IP address of the other party and a user authentication system using the same. About.
[0002]
[Prior art]
As an authentication method for authenticating a user on a general-purpose network such as the Internet in the past, there is Kerberos authentication (a user authentication method used on a network developed by the Atena project of the Massachusetts Institute of Technology). The following are technical documents.
[0003]
[Patent Document 1]
JP 2002-501218 A
[0004]
FIG. 9 is a configuration block diagram showing an example of such a conventional user authentication system using a user authentication method. In FIG. 9, reference numeral 1 denotes a terminal that intends to perform mutual authentication with another terminal, and 2 denotes a key distribution center (Key Distribution) that provides a session key and a ticket to a terminal configured by a server or the like and sharing information with each other. Center: hereinafter referred to as KDC2.) Reference numeral 3 denotes a terminal that is a target of mutual authentication of the terminal 1.
[0005]
The terminal 1 is mutually connected to the KDC 2 via a network or the like, and the terminal 3 is mutually 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. 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 each terminal and the KDC, and FIG. 14 is a flowchart for explaining the operation of the KDC 2. 15 is a flowchart illustrating the operation of the terminal 2.
[0007]
In an initial state, the terminal 1 and the terminal 2 share a name set for the terminal with the KDC 2 (hereinafter, referred to as a terminal name), and also share a name between the terminal 1 and the KDC 2 and a terminal 3 It is assumed that a secret key shared between KDC2 and KDC2 is held.
[0008]
First, the terminal 1 performs "authentication of the terminal 1". That is, in “S001” in FIG. 10, the terminal 1 encrypts the current time using a secret key (hereinafter, referred to as “secret key A”) shared with the KDC 2 and names its own terminal. , Together with various information such as an IP address to the KDC 2 to request authentication of the terminal 1.
[0009]
In FIG. 10, in “S002”, the terminal 1 transmits a session key (a session key used for communication between the terminal 1 and the KDC 2) encrypted by the “secret key A” from the KDC 2 to the “session key A”. Call) and TGT (Ticket-Granting-Ticket: ticket guarantee ticket).
[0010]
For example, the terminal 1 requests authentication to the KDC 2 as indicated by “AR01” in FIG. 11, and receives a session key or the like encrypted with the “secret key A” as indicated by “RA01” in FIG. It is determined whether or not.
[0011]
If the session key or the like encrypted in “S002” in FIG. 10 is received, the terminal 1 decrypts using “secret key A” in “S003” in FIG. “TGT” is acquired.
[0012]
When the terminal 1 acquires the “session key A” and the “TGT”, the process of “authentication of the terminal 1” by the KDC 2 is completed.
[0013]
Second, the terminal 1 performs a "ticket request" process for communicating with the terminal 3. That is, in “S004” in FIG. 10, the terminal 1 encrypts the time using the obtained “session key A”, transmits the time to the KDC 2 together with the terminal name of the communication partner to communicate with, and the obtained “TGT”. Request a ticket to communicate with 3.
[0014]
In “S005” in FIG. 10, the terminal 1 sends a session key (a session key used for communication between the terminal 1 and the terminal 3; hereinafter, a “session key B”) encrypted with the “session key A” from the KDC 2. It is determined whether a ticket has been received.
[0015]
For example, as shown by "TR11" in FIG. 12, the terminal 1 requests a ticket for performing communication with the terminal 3 from the KDC 2, and encrypts it with the "session key A" as shown by "RT11" in FIG. It is determined whether the received session key, ticket, and the like are received.
[0016]
Here, the ticket is obtained by encrypting the “session key B” or the like by the KDC 2 using a secret key (hereinafter, referred to as “secret key B”) shared between the terminal 3 and the KDC 2. Thus, the information can be decoded only by the terminal 3.
[0017]
If the ticket or the like encrypted in “S005” in FIG. 10 is received, in “S006” in FIG. 10, the terminal 1 decrypts using the “session key A” and “session key B” and “session key B”. Get "Ticket" etc.
[0018]
Then, when the terminal 1 acquires the “ticket”, the processing of “ticket request” for communication 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 in “session B” has been received from the terminal 3.
[0021]
For example, as shown by “AR21” in FIG. 13, terminal 1 requests authentication to terminal 3 and received the time encrypted with “session key B” as shown by “RA21” in FIG. Determine whether or not.
[0022]
If the time encrypted in “S008” in FIG. 10 is received, in “S009” in FIG. 10, the terminal 1 decrypts using the “session key B” and acquires the time.
[0023]
In “S010” in FIG. 10, the terminal 1 determines the quality of the acquired time. If there is no problem in 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 has decrypted using the “session key B”, the “mutual authentication” process with the terminal 3 is completed.
[0025]
That is, the terminal 3 acquires the “session key B” from the “ticket” which is information that can be decrypted only by the terminal 3 by decryption, 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 KDC2 side, in "S101" in FIG. 14, whether or not the KDC2 has received the current time encrypted with the "secret key A" from the terminal 1 together with various information such as the terminal name and the IP address of the terminal 1 Judge.
[0027]
If the time or the like encrypted in “S101” in FIG. 14 is received, the KDC 2 decrypts the data using the “secret key A” in “S102” in FIG. 14 and acquires the time.
[0028]
Then, in "S103" in FIG. 14, the KDC 2 determines whether the acquired time is good or not, and when the terminal 1 is authenticated without any problem in the acquired time, the KDC 2 determines the "secret key A" in "S104" in FIG. And encrypts the "session key A" and "TGT" and returns them to the terminal 1.
[0029]
In "S105" in FIG. 14, the KDC 2 determines whether or not the terminal 1 has received the current time encrypted with the "session key A" together with the terminal name of the terminal 3 with which communication is desired and various information such as "TGT". to decide.
[0030]
If the time or the like encrypted in “S105” in FIG. 14 is received, the KDC 2 decrypts it using “session key A” in “S106” in FIG. 14 to obtain the time.
[0031]
Then, in "S107" in FIG. 14, the KDC 2 determines whether the acquired time is good or not, and if the terminal 1 is authenticated without any problem in the acquired time, the KDC 2 sets the "session key A" in "S108" in FIG. And encrypts the "session key B" and the "ticket" and returns them to the terminal 1.
[0032]
On the terminal 3 side, in “S201” in FIG. 15, the terminal 3 determines whether or not the terminal 3 has received the current time encrypted with the “session key B” together with various information such as “ticket”. .
[0033]
If the time or the like encrypted in “S201” in FIG. 15 is received, the terminal 3 decrypts the ticket using “secret key B” in “S202” in FIG. "" To determine whether decoding is possible.
[0034]
Here, since the “secret key B” is shared between the terminal 3 and the KDC2, if the decryption is successful, it is proved that the “ticket” is generated by the KDC2, It can be seen that 1 has been authenticated from KDC2.
[0035]
That is, the terminal 3 can authenticate the terminal 1 when the decryption is successful.
[0036]
At the same time, since the “session key B” is also encrypted in the “ticket” using the “secret key B”, by decrypting the “ticket”, the terminal 3 becomes the terminal in “S204” in FIG. A “session key B” that is a session key between them can be obtained.
[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, since the terminal 1 and the terminal 3 share a secret key and the like with the KDC 2, the terminal 1 can perform mutual authentication with the terminal 3 via the KDC 2, and the terminal 1 that has mutually authenticated the terminal 1 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 conventional user authentication system using the user authentication method (Kerberos authentication) shown in FIG. 9, in order for the terminal 1 to perform mutual authentication with the terminal 3 and secure secure communication, the terminal 1 must It is necessary to know in advance the name and IP address of No.3.
[0040]
On the other hand, in recent years, the mobility of terminals such as hot spots and SOHO (Small Office / Home Office) offices has been required, and therefore, the IP address of the terminal changes dynamically, and the IP address of the terminal always changes. Are very few terminals.
[0041]
That is, in order for the terminal 1 to perform mutual authentication with the terminal 3 whose IP address changes dynamically and secure secure communication, it is necessary to always know the IP address of the terminal 3 which dynamically changes. There is a problem that it is very difficult to always keep track of the dynamically changing IP address of the terminal 3.
Therefore, an object of the present invention is to realize a user authentication method capable of performing mutual authentication without knowing the other party's IP address and a user authentication system using the same.
[0042]
[Means for Solving the Problems]
In order to achieve such an object, the invention according to claim 1 of the present invention is:
A user authentication method used on a network,
The first and second terminals share their respective secret keys with the key distribution center, and request the key distribution center to authenticate the terminals when the IP addresses of the first and second terminals are changed. The changed IP address is cached in the key distribution center,
The first terminal requests the key distribution center for terminal authentication, and after the terminal authentication, the first terminal requests the key distribution center for a ticket for communication with the second terminal. The key distribution center transmits the IP address of the second terminal cached together with the ticket to the first terminal, and the first terminal transmits the second terminal based on the IP address. By performing the mutual authentication by transmitting the ticket to the second terminal and obtaining a response from the second terminal, the mutual authentication becomes possible without knowing the IP address of the other party.
[0043]
The invention according to claim 2 is
In the user authentication method according to the first aspect,
In the mutual authentication process, mutual authentication is possible without knowing the IP address of the other party by exchanging an encryption key used in IPsec (IP Security), which is a security technique for encrypting and authenticating an IP packet. become.
[0044]
The invention according to claim 3 is
In a user authentication system using a user authentication method used on a network,
A key distribution center, a first terminal that shares a first secret key with the key distribution center, and requests authentication of the terminal to the key distribution center when an IP address is changed; Requesting the key distribution center to authenticate the terminal when the IP address is changed while sharing the second secret key with the center, requesting the key distribution center to authenticate the terminal, Requesting a ticket for communication with the first terminal after authentication of the terminal, transmitting the ticket to the first terminal based on the IP address obtained from the key distribution center together with the ticket; The provision of the second terminal for performing mutual authentication enables mutual authentication without knowing the IP address of the other party.
[0045]
The invention according to claim 4 is
In the user authentication system according to claim 3,
The key distribution center,
By caching the IP address of each terminal based on information transmitted from each terminal at the time of a request for authentication of the terminal, mutual authentication becomes possible without knowing the IP address of the other party.
[0046]
The invention according to claim 5 is
In the user authentication system according to claim 4,
The key distribution center,
By authenticating the second terminal and transmitting the IP address of the first terminal cached together with the ticket to the second terminal, mutual authentication can be performed without knowing the other party's IP address. Authentication becomes possible.
[0047]
The invention according to claim 6 is
In the user authentication system according to claim 5,
The key distribution center,
When receiving the time encrypted with the second secret key together with the terminal name and the IP address from the second terminal, encrypt the first session key and the ticket assurance ticket with the second secret key. When the time encrypted with the first session key is received from the second terminal together with the first terminal name and the ticket assurance ticket, the first terminal By encrypting the second session key, the ticket, and the IP address of the first terminal with a session key and returning them to the second terminal, mutual authentication is possible without knowing the IP address of the other party become.
[0048]
The invention according to claim 7 is
In the user authentication system according to claim 3,
The first terminal comprises:
By authenticating the second terminal when receiving the ticket from the second terminal and returning the response to the second terminal, mutual authentication is possible without knowing the IP address of the other party become.
[0049]
The invention according to claim 8 is
In the user authentication system according to claim 7,
The first terminal comprises:
The second terminal receives the current time encrypted with the session key between the terminals together with the ticket from the second terminal, and if the decryption of the ticket is successful using the first secret key, the second terminal Is authenticated, the time is encrypted with the inter-terminal session key obtained by decryption, and the time is returned to the second terminal, thereby enabling mutual authentication without knowing the IP address of the other party.
[0050]
The invention according to claim 9 is
In the user authentication system according to claim 3,
The second terminal comprises:
Requesting the key distribution center to authenticate the terminal, requesting a ticket for performing communication with the first terminal after the terminal is authenticated, and requesting the first key based on the 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 becomes possible without knowing the IP address of the other party.
[0051]
The invention according to claim 10 is
In the user authentication system according to the ninth aspect,
The second terminal comprises:
The time is encrypted using the second secret key, and transmitted to the key distribution center together with the terminal name and the IP address of the terminal to request authentication of the terminal. When receiving the encrypted first session key and ticket assurance ticket, the first session key and the ticket assurance ticket are decrypted using the second secret key to obtain the first session key and the ticket assurance ticket. The time is encrypted using a key, transmitted to the key distribution center together with the first terminal name and the ticket assurance ticket to request the ticket, and encrypted with the first session key from the key distribution center. When the received second session key, the ticket and the IP address are received, the second session key is decrypted using the first session key, The second terminal obtains the ticket and the IP address, encrypts the time using the second session key, transmits the encrypted time together with the ticket to the first terminal, requests authentication, and sends the second terminal from the first terminal to the second terminal. When the time encrypted with the session key is received, the first terminal is authenticated if there is no problem with the time obtained by decrypting and using the second session key. Mutual authentication is possible without knowing.
[0052]
The invention according to claim 11 is
In the user authentication system according to claim 3,
By exchanging an encryption key used in IPsec (IP Security), which is a security technique for encrypting and authenticating an IP packet, in the process of mutual authentication between the first terminal and the second terminal, Mutual authentication is possible without knowing the IP address.
[0053]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, the present invention will be described in detail with reference to the drawings. FIG. 1 is a block diagram showing an embodiment of a user authentication system and a user authentication system using the same according to the present invention.
[0054]
In FIG. 1, reference numeral 4 denotes a terminal for performing mutual authentication with another terminal, and reference numeral 5 denotes a key distribution center (Key Distribution) for providing a session key and a ticket to a terminal constituted by a server or the like and sharing information with each other. Center: hereinafter, referred to as KDC 5) and 6 are terminals to be mutually authenticated by 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 a network or the like.
[0056]
Here, the operation of the embodiment shown in FIG. 1 will be described with reference to FIG. 2, FIG. 3, FIG. 4, FIG. 5, FIG. 6, FIG. 2 is a flowchart illustrating the common operation of the terminal 4 and the terminal 6, FIG. 3 is a flowchart illustrating the operation of the terminal 4, and FIGS. 4, 5 and 6 illustrate the exchange of data between each terminal and the KDC. FIG. 7 is a flowchart illustrating the operation of the KDC 5, and FIG. 8 is a flowchart illustrating the operation of the terminal 6.
[0057]
As an initial state, the terminal 4 and the terminal 6 share a name set for the terminal with the KDC 5 (hereinafter, referred to as a terminal name), and also, between the terminal 4 and the KDC 5, and the terminal 6 It is assumed that a secret key shared between KDC5 and KDC5 is held.
[0058]
In "S301" in FIG. 2, the terminals 4 and 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. Performs its own “terminal authentication” process.
[0059]
As a result of the “terminal authentication” process, the IP address changed to the KDC 5 is cached as described later, and the latest IP address is always cached in the KDC 5.
[0060]
Then, first, the terminal 4 performs "authentication of the terminal 4". That is, in “S401” in FIG. 3, the terminal 4 encrypts the current time using a secret key (hereinafter, referred to as “secret key C”) shared with the KDC 5, and the terminal name of its own. , Together with various information such as the current IP address to the KDC 5 to request authentication of the terminal 4.
[0061]
In "S402" in FIG. 3, the terminal 4 sends a session key (a session key used for communication between the terminal 4 and the KDC 5) encrypted by the "secret key C" from the KDC 5 to a "session key C". Call) and TGT (Ticket-Granting-Ticket: ticket guarantee ticket).
[0062]
For example, the terminal 4 requests authentication to 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. It is determined whether or not.
[0063]
If the session key or the like encrypted in “S402” in FIG. 3 is received, in “S403” in FIG. 3, the terminal 4 decrypts using the “secret key C”, and “TGT” is acquired.
[0064]
Then, when the terminal 4 acquires the “session key C” and the “TGT”, the process of “authentication of the terminal 4” by the KDC 5 is completed.
[0065]
Second, the terminal 4 performs a "ticket request" process for communicating with the terminal 6. That is, in “S404” in FIG. 3, the terminal 4 encrypts the time using the obtained “session key C”, transmits the encrypted time to the KDC 5 together with the terminal name of the communication partner to be communicated, and the obtained “TGT”. Request a ticket to communicate with 6.
[0066]
In “S405” in FIG. 3, the terminal 4 sends a session key (a session key used for communication between the terminal 4 and the terminal 6; hereinafter, “session key D”) encrypted from the KDC 5 in “session C”. Call) and whether or not a ticket has been received.
[0067]
For example, the terminal 4 requests a ticket for communicating with the terminal 6 from the KDC 5 as shown by “TR41” in FIG. 5, and encrypts it with the “session key C” as shown by “RT41” in FIG. It is determined whether the received session key, ticket, and the like are received.
[0068]
Here, the ticket is obtained by encrypting the “session key D” or the like by the KDC 5 using a secret key (hereinafter, referred to as “secret key D”) shared between the terminal 6 and the KDC 5. Thus, the information can be decoded only by the terminal 6.
[0069]
If a ticket or the like encrypted in “S405” in FIG. 3 is received, in “S406” in FIG. 3, the terminal 4 decrypts using the “session key C” and “session key D”, “ “Ticket” and “IP address of terminal 6” are acquired.
[0070]
Then, when the terminal 4 acquires the “ticket” and the “IP address of the terminal 6”, the process of “ticket request” for performing communication with the terminal 6 is completed.
[0071]
Third, the terminal 4 performs "mutual authentication" with the terminal 6. 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 in “session D” has been received from the terminal 6.
[0073]
For example, as shown by “AR51” in FIG. 6, the terminal 4 requests authentication to the terminal 6, and has received the time encrypted with the “session key D” as shown by “RA51” in FIG. Determine whether or not.
[0074]
If the terminal 4 receives the time encrypted in “S408” in FIG. 3, the terminal 4 decrypts it using “session key D” in “S409” in FIG. 3 to obtain the time.
[0075]
In “S410” in FIG. 3, the terminal 4 determines the quality of the acquired time, and if there is no problem in the acquired time, the terminal 4 authenticates the terminal 6 in “S411” in FIG.
[0076]
Then, when there is no problem in the time when the terminal 4 has decrypted 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” by decryption 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, the KDC 5 has received from the terminal 4 the current time encrypted with the "secret key C" together with various information such as the terminal name of the terminal 4 and the current IP address. Determine whether or not.
[0079]
If the time or the like encrypted in “S501” in FIG. 7 is received, the KDC 2 decrypts using the “secret key C” in “S502” in FIG. 7 and acquires the time.
[0080]
Then, in “S503” in FIG. 7, the KDC 5 determines the quality of the acquired time, and if the terminal 4 is authenticated without any problem in the acquired time, in step “S504” in FIG. The current IP address is cached and the “session key C” and “TGT” are encrypted using the “secret key C” in “S505” in FIG.
[0081]
In "S506" in FIG. 7, the KDC 5 determines whether or not the terminal 4 has received the current time encrypted with the "session key C" together with the terminal name of the terminal 6 with which communication is desired and various information such as "TGT". to decide.
[0082]
If the time or the like encrypted in “S506” in FIG. 7 is received, the KDC 5 decrypts using the “session key C” in “S507” in FIG. 7 and acquires the time.
[0083]
In step S508 in FIG. 7, the KDC 5 determines whether the acquired time is good or not. If the terminal 4 is authenticated without any problem in the acquired time, the KDC 5 determines the "session key C" in step S509 in FIG. And encrypts the “session key D”, the “ticket” and the cached “IP address of terminal 6” and returns them to 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". .
[0085]
If the time or the like encrypted in “S601” in FIG. 8 is received, the terminal 6 decrypts the ticket using the “secret key D” in “S602” in FIG. 8, and “S603” in FIG. "" To determine whether decoding is possible.
[0086]
Here, since the “secret key D” is shared between the terminal 6 and the KDC 5, if the decryption succeeds, it is proved that the “ticket” was generated by the KDC 5, and the terminal 4 is authenticated by 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”, by decrypting the “ticket”, the terminal 6 in “S604” in FIG. "Session key D" which is a session key between terminals can be obtained.
[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, 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 communicating with the partner terminal, it also transmits the cached IP address of the partner terminal so that the IP address of the partner terminal is not known. Even so, mutual authentication becomes possible.
[0091]
In the embodiment shown in FIG. 1, secure communication is ensured by performing mutual authentication between terminals and sharing a session key, but of course, 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 technique for encrypting and authenticating IP packets.
[0093]
In IPsec, terminals need to exchange and share encryption keys (IPsec Security Association) with each other.
[0094]
In this case, the encryption keys may be exchanged with each other in the process of “mutual authentication” between the 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 and requests authentication, the terminal 4 transmits the encryption key of the terminal 4 to the terminal 6, and “ When transmitting the time encrypted with the “session key D” as shown in RA51 ”, the terminal 6 may exchange the encryption key by transmitting the encryption key of the terminal 6 to the terminal 4.
[0096]
As a result, it is possible to perform encrypted communication using IPsec without having to know the IP address of the partner terminal because of the mobility.
[0097]
When the encryption keys are exchanged with each other, the encryption keys may be encrypted and exchanged using the “session key D” between the terminals. In this case, encryption key exchange can be performed more safely.
[0098]
Although the embodiment illustrated in FIG. 1 illustrates a terminal as an example of a device that performs mutual authentication, a computer having a network function, a PDA (Personal Digital (Data) Assistants), a PHS (Personal Handyphone System), and a PHS (Personal Handyphone System) may be used. 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 first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, and tenth aspects, each terminal shares a secret key and the like with the KDC and each terminal When the IP address is changed, the KDC requests terminal authentication from the KDC, caches the changed IP address in the KDC, and transmits a ticket for the KDC to communicate with the other terminal. By transmitting the IP address of the terminal on the other end cached at the same time, mutual authentication becomes possible without knowing the IP address of the terminal on the other end.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an embodiment of a user authentication system and a user authentication system using the same according to the present invention.
FIG. 2 is a flowchart illustrating common operations of a terminal 4 and a terminal 6.
FIG. 3 is a flowchart illustrating an operation of a terminal 4.
FIG. 4 is an explanatory diagram illustrating data exchange between terminals and KDCs.
FIG. 5 is an explanatory diagram illustrating data exchange between each terminal and a KDC.
FIG. 6 is an explanatory diagram for explaining data exchange between each terminal and the KDC.
FIG. 7 is a flowchart illustrating the operation of KDC5.
FIG. 8 is a flowchart illustrating the operation of terminal 6.
FIG. 9 is a configuration block diagram illustrating an example of a conventional user authentication system using a user authentication method.
FIG. 10 is a flowchart illustrating the operation of terminal 1.
FIG. 11 is an explanatory diagram illustrating data exchange between each terminal and the KDC.
FIG. 12 is an explanatory diagram illustrating data exchange between terminals and KDCs.
FIG. 13 is an explanatory diagram illustrating data exchange between each terminal and the KDC.
FIG. 14 is a flowchart illustrating the operation of KDC2.
FIG. 15 is a flowchart illustrating the operation of terminal 2.
[Explanation of symbols]
1,3,4,6 terminal
2,5 Key Distribution Center (KDC)
Claims (11)
第１及び第２の端末が鍵配布センターとの間でそれぞれの秘密鍵を共有すると共に前記第１及び第２の端末のＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求して変更されたＩＰアドレスを前記鍵配布センターにキャッシュしておき、
前記第１の端末が前記鍵配布センターに端末の認証を要求し、
端末の認証後に前記第１の端末が前記第２の端末との間で通信を行うためのチケットを前記鍵配布センターに要求し、
前記鍵配布センターが前記チケットと共にキャッシュされている前記第２の端末のＩＰアドレスを併せて前記第１の端末に送信し、
前記第１の端末が前記ＩＰアドレスに基づき前記第２の端末に前記チケットを送信して前記第２の端末からの応答を得ることにより相互認証を行うことを特徴とするユーザー認証方式。A user authentication method used on a network,
The first and second terminals share their respective secret keys with the key distribution center, and request the key distribution center to authenticate the terminals when the IP addresses of the first and second terminals are changed. The changed IP address is cached in the key distribution center,
The first terminal requests the key distribution center to authenticate the terminal,
After authentication of the terminal, the first terminal requests a ticket for communicating with the second terminal from the key distribution center,
The key distribution center transmits the IP address of the second terminal cached together with the ticket to the first terminal,
A user authentication method, wherein the first terminal transmits the ticket to the second terminal based on the IP address and obtains a response from the second terminal to perform mutual authentication.
請求項１記載のユーザー認証方式。2. The user authentication method according to claim 1, wherein in the mutual authentication process, an encryption key used in IPsec (IP Security), which is a security technology for encrypting and authenticating an IP packet, is exchanged.
鍵配布センターと、
この鍵配布センターとの間で第１の秘密鍵を共有すると共にＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求する第１の端末と、
前記鍵配布センターとの間で第２の秘密鍵を共有すると共にＩＰアドレスが変更された場合に前記鍵配布センターに端末の認証を要求するものであって、前記鍵配布センターに端末の認証を要求し、端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、前記チケット共に前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して相互認証を行う第２の端末と
を備えたことを特徴とするユーザー認証システム。In a user authentication system using a user authentication method used on a network,
A key distribution center,
A first terminal that shares a first secret key with the key distribution center and requests the key distribution center to authenticate the terminal when the IP address is changed;
A second secret key is shared with the key distribution center, and when the IP address is changed, the key distribution center is requested to authenticate the terminal. Requesting a ticket for communicating with the first terminal after authentication of the terminal, and sending the ticket to the first terminal based on the IP address obtained from the key distribution center together with the ticket. A user authentication system, comprising: a second terminal that transmits and performs mutual authentication.
端末の認証の要求時に前記各端末から送信されてくる情報に基づき前記各端末のＩＰアドレスをキャッシュすることを特徴とする
請求項３記載のユーザー認証システム。The key distribution center,
4. The user authentication system according to claim 3, wherein an IP address of each terminal is cached based on information transmitted from each terminal at the time of a request for terminal authentication.
前記第２の端末の認証を行い、
前記チケットと共にキャッシュされている前記第１の端末のＩＰアドレスを併せて前記第２の端末に送信することを特徴とする
請求項４記載のユーザー認証システム。The key distribution center,
Authenticate the second terminal,
5. The user authentication system according to claim 4, wherein an IP address of the first terminal cached together with the ticket is transmitted to the second terminal.
前記第２の端末から端末名称、前記ＩＰアドレスと共に前記第２の秘密鍵で暗号化された時刻を受信した場合、前記第２の秘密鍵で前記第１のセッション鍵及び前記チケット保証チケットを暗号化して前記第２の端末に返送し、
前記第２の端末から前記第１の端末名称、前記チケット保証チケットと共に前記第１のセッション鍵で暗号化された時刻を受信した場合、前記第１のセッション鍵で前記第２のセッション鍵、前記チケット及び前記第１の端末のＩＰアドレスを暗号化して前記第２の端末に返送することを特徴とする
請求項５記載のユーザー認証システム。The key distribution center,
When receiving the time encrypted with the second secret key together with the terminal name and the IP address from the second terminal, encrypt the first session key and the ticket assurance ticket with the second secret key. And returns it to the second terminal,
When receiving the time encrypted with the first session key together with the first terminal name and the ticket guarantee ticket from the second terminal, the second session key with the first session key, 6. The user authentication system according to claim 5, wherein the ticket and the IP address of the first terminal are encrypted and returned to the second terminal.
前記第２の端末から前記チケットを受信した場合に前記第２の端末を認証し、
前記応答を前記第２の端末に返送することを特徴とする
請求項３記載のユーザー認証システム。The first terminal comprises:
Authenticates the second terminal when receiving the ticket from the second terminal,
The user authentication system according to claim 3, wherein the response is returned to the second terminal.
前記第２の端末から前記チケットと共に端末間のセッション鍵で暗号化された現在の時刻を受信し、前記第１の秘密鍵を用いて前記チケットの復号化が成功した場合に前記第２の端末を認証し、
復号化で取得した前記端末間セッション鍵で時刻を暗号化して前記第２の端末に返送することを特徴とする
請求項７載のユーザー認証システム。The first terminal comprises:
The second terminal receives the current time encrypted with the session key between the terminals together with the ticket from the second terminal, and when the ticket is successfully decrypted using the first secret key, Authenticate
8. The user authentication system according to claim 7, wherein a time is encrypted with the session key between terminals obtained by decryption, and the encrypted time is returned to the second terminal.
前記鍵配布センターに端末の認証を要求し、
端末の認証後に前記第１の端末との間で通信を行うためのチケットを要求し、前記鍵配布センターから取得した前記ＩＰアドレスに基づき前記第１の端末に前記チケットを送信して前記第１の端末からの応答を得ることにより前記第１の端末の認証を行うことを特徴とする
請求項３載のユーザー認証システム。The second terminal comprises:
Requesting the key distribution center to authenticate the terminal,
Requesting a ticket for communication with the first terminal after authenticating the terminal, transmitting the ticket to the first terminal based on the IP address obtained from the key distribution center, The user authentication system according to claim 3, wherein the authentication of the first terminal is performed by obtaining a response from the terminal.
前記第２の秘密鍵を用いて時刻を暗号化して、自らの端末名称、ＩＰアドレスと共に前記鍵配布センターに送信して端末の認証を要求し、
前記鍵配布センターから前記第２の秘密鍵で暗号化された第１のセッション鍵及びチケット保証チケットを受信した場合、前記第２の秘密鍵を用いて復号化して前記第１のセッション鍵及び前記チケット保証チケットを取得し、
前記第１のセッション鍵を用いて時刻を暗号化して、前記第１の端末名称、前記チケット保証チケットと共に前記鍵配布センターに送信して前記チケットを要求し、
前記鍵配布センターから前記第１のセッション鍵で暗号化された第２のセッション鍵、前記チケット及び前記ＩＰアドレスを受信した場合、前記第１のセッション鍵を用いて復号化して前記第２のセッション鍵、前記チケット及び前記ＩＰアドレスを取得し、
前記第２のセッション鍵を用いて時刻を暗号化して前記チケットと共に前記第１の端末に送信して認証を要求し、
前記第１の端末から前記第２のセッション鍵で暗号化された時刻を受信した場合、前記第２のセッション鍵を用いて復号化し取得した時刻に問題がなければ前記第１の端末を認証することを特徴とする
請求項９記載のユーザー認証システム。The second terminal comprises:
Encrypting the time using the second secret key, transmitting the encrypted time together with its own terminal name and IP address to the key distribution center, and requesting authentication of the terminal;
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 assurance ticket are decrypted using the second secret key and the first session key and the ticket Get a ticket guarantee ticket,
Encrypting the time using the first session key, transmitting the first terminal name and the ticket assurance ticket to the key distribution center to request the ticket,
When a second session key, the ticket and the IP address encrypted with the first session key are received from the key distribution center, the second session key is decrypted using the first session key and the second session key is decrypted. Obtain a key, the ticket and the IP address,
Requesting authentication by encrypting the time using the second session key and transmitting the encrypted time together with the ticket to the first terminal;
If the time encrypted with the second session key is received from the first terminal, the first terminal is authenticated if there is no problem with the time obtained by decrypting and using the second session key. 10. The user authentication system according to claim 9, wherein:
請求項３記載のユーザー認証システム。In the process of mutual authentication between the first terminal and the second terminal, an encryption key used in IPsec (IP Security), which is a security technique for encrypting and authenticating an IP packet, is exchanged. The user authentication system according to claim 3.
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 true JP2004178361A (en) | 2004-06-24 |
| JP4239573B2 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) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011233470A (en) * | 2010-04-30 | 2011-11-17 | Sony Corp | Battery module, electric mobile body, authentication device, and method for controlling battery module discharge |
| WO2018105043A1 (en) * | 2016-12-07 | 2018-06-14 | 大日本印刷株式会社 | Terminal device, program and communication system |
-
2002
- 2002-11-28 JP JP2002345186A patent/JP4239573B2/en not_active Expired - Fee Related
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011233470A (en) * | 2010-04-30 | 2011-11-17 | Sony Corp | Battery module, electric mobile body, authentication device, and method for controlling battery module discharge |
| WO2018105043A1 (en) * | 2016-12-07 | 2018-06-14 | 大日本印刷株式会社 | Terminal device, program and communication system |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4239573B2 (en) | 2009-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Seitz et al. | RFC 9200: Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) | |
| 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 | |
| JP6301244B2 (en) | Computer-implemented system and method for lightweight authentication in datagram transfer for the Internet of Things | |
| JP4575679B2 (en) | Wireless network handoff encryption key | |
| JP4286224B2 (en) | Method for secure and confidential communication used in a wireless local area network (WLAN) | |
| US7181012B2 (en) | Secured map messages for telecommunications networks | |
| Harney et al. | GSAKMP: Group secure association key management protocol | |
| EP1933498B1 (en) | Method, system and device for negotiating about cipher key shared by ue and external equipment | |
| EP1560396A2 (en) | Method and apparatus for handling authentication on IPv6 network | |
| US20060105741A1 (en) | Method and apparatus for security of IP security tunnel using public key infrastructure in mobile communication network | |
| EP1374533B1 (en) | Facilitating legal interception of ip connections | |
| JP2005510184A (en) | Key management protocol and authentication system for secure Internet protocol rights management architecture | |
| US20080137859A1 (en) | Public key passing | |
| JP4006403B2 (en) | Digital signature issuing device | |
| WO2010091563A1 (en) | Management method, device and system for wapi terminal certificates | |
| JP2006050267A (en) | IPsec COMMUNICATION METHOD, COMMUNICATION CONTROLLER AND NETWORK CAMERA | |
| Gerdes et al. | Datagram transport layer security (DTLS) profile for authentication and authorization for constrained environments (ACE) | |
| JP2010539839A (en) | Security method in server-based mobile Internet protocol system | |
| JP4681990B2 (en) | Communication system and communication system | |
| Pereniguez et al. | Privacy-enhanced fast re-authentication for EAP-based next generation network | |
| JP4239573B2 (en) | User authentication system | |
| Pittoli et al. | Security architectures in constrained environments: A survey | |
| Gerdes et al. | RFC 9202: Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) | |
| KR101050835B1 (en) | Authentication method of a mobile terminal based on minimum public key providing non-repudiation service on mobile network | |
| Krohmer et al. | Decentralized Identifier Distribution for Moving Target Defense and Beyond |
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 |