(57)【要約】【課題】ネットワーク上でサービスを利用するユーザの認証を行う安全性，利便性に優れたユーザ認証システムを提供する。【解決手段】第１のネットワーク上のユーザ端末１００と、第２のネットワーク（インターネット５００）上のサービス提供サーバ３００と、それらネットワークを接続するゲートウェイ２００とによって構成され、ゲートウェイ２００は鍵ペアを生成する手段と、その鍵ペアを記憶する手段と、鍵ペアの公開鍵に対応する証明書を生成する手段と、その証明書を記憶する手段と、鍵ペアの秘密鍵と証明書とを用いてユーザの認証情報を生成する手段とを備える。サービス提供サーバ３００はユーザ端末１００からサービスの提供を要求されると、ゲートウェイ２００における認証情報の生成を要求し、その認証情報を検証して正当であればユーザ端末１００に対してサービスを提供する。【選択図】図１
2008129673.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上でサービスを利用するユーザの認証を行うシステムであって、
第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとによって構成され、
前記ゲートウェイは鍵ペアを生成する手段と、その生成した鍵ペアを記憶する手段と、前記鍵ペアの公開鍵に対応する証明書を生成する手段と、その生成した証明書を記憶する手段と、前記鍵ペアの秘密鍵と前記証明書とを用いてユーザの認証情報を生成する手段とを備え、
前記サービス提供サーバは前記ユーザ端末からサービスの提供を要求されると、前記ゲートウェイにおける前記認証情報の生成を要求し、その生成された認証情報を検証して正当であれば前記ユーザ端末に対してサービスを提供する構成とされていることを特徴とするユーザ認証システム。
【請求項２】
ネットワーク上でサービスを利用するユーザの認証を行うシステムであって、
第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバ及び証明書発行サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとによって構成され、
前記ゲートウェイはユーザの第１の認証情報を生成する手段と、その第１の認証情報の前記証明書発行サーバにおける認証に基づき、鍵ペアを生成する手段と、その生成した鍵ペアを記憶する手段と、前記証明書発行サーバより受信した前記鍵ペアの公開鍵に対応する証明書を記憶する手段と、前記鍵ペアの秘密鍵と前記証明書とを用いてユーザの第２の認証情報を生成する手段とを備え、
前記証明書発行サーバは前記ゲートウェイより受信した前記第１の認証情報を検証する手段と、前記ゲートウェイより受信した前記公開鍵に対応する前記証明書を生成する手段とを備えており、
前記サービス提供サーバは前記ユーザ端末からサービスの提供を要求されると、前記ゲートウェイにおける前記第２の認証情報の生成を要求し、その生成された第２の認証情報を検証して正当であれば前記ユーザ端末に対してサービスを提供する構成とされていることを特徴とするユーザ認証システム。
【請求項３】
請求項１記載のユーザ認証システムにおいて、
前記証明書を記憶する手段は複数の鍵ペアの各公開鍵に対応する複数の証明書を記憶しており、
前記認証情報を生成する手段は前記ユーザ端末より指定された秘密鍵と、その秘密鍵と対応する前記証明書とを用いて前記認証情報を生成することを特徴とするユーザ認証システム。
【請求項４】
請求項２記載のユーザ認証システムにおいて、
前記証明書を記憶する手段は複数の鍵ペアの各公開鍵に対応する複数の証明書を記憶しており、
前記第２の認証情報を生成する手段は前記ユーザ端末より指定された秘密鍵と、その秘密鍵と対応する前記証明書とを用いて前記第２の認証情報を生成することを特徴とするユーザ認証システム。
【請求項５】
第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとを備え、ユーザ端末からサービス提供サーバの認証を必要とするサービスを利用する際のユーザ認証方法であって、
前記サービス提供サーバは前記ユーザ端末からサービスの提供を要求されると、前記ゲートウェイに対してユーザの認証情報を要求し、
前記ゲートウェイは認証情報を要求されると、鍵ペアを生成して、その鍵ペアの公開鍵に対応する証明書を生成し、さらに前記鍵ペアの秘密鍵と前記証明書とを用いてユーザの認証情報を生成して、その認証情報を前記サービス提供サーバに送信し、
前記サービス提供サーバは認証情報を受信すると、その認証情報を検証し、正当であれば前記ユーザ端末に対してサービスを提供することを特徴とするユーザ認証方法。
【請求項６】
第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバ及び証明書発行サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとを備え、ユーザ端末からサービス提供サーバの認証を必要とするサービスを利用する際のユーザ認証方法であって、
前記サービス提供サーバは前記ユーザ端末からサービスの提供を要求されると、前記ゲートウェイに対してユーザの第２の認証情報を要求し、
前記ゲートウェイは第２の認証情報を要求されると、ユーザの第１の認証情報を生成して前記証明書発行サーバに送信し、
前記証明書発行サーバは第１の認証情報を受信すると、その第１の認証情報を検証して、その結果を前記ゲートウェイに送信し、
前記ゲートウェイは受信した前記結果が認証成功を示すものであれば、鍵ペアを生成してその鍵ペアの公開鍵を前記証明書発行サーバに送信し、
前記証明書発行サーバは受信した公開鍵に対応する証明書を生成して、その証明書を前記ゲートウェイに送信し、
前記ゲートウェイは前記鍵ペアの秘密鍵と前記証明書とを用いてユーザの第２の認証情報を生成して、その第２の認証情報を前記サービス提供サーバに送信し、
前記サービス提供サーバは第２の認証情報を受信すると、その第２の認証情報を検証し、正当であれば前記ユーザ端末に対してサービスを提供することを特徴とするユーザ認証方法。
【請求項７】
請求項５記載のユーザ認証方法において、
前記ゲートウェイは前記ユーザ端末に確認情報を要求し、その確認情報を確認した後に、前記認証情報の生成を行うことを特徴とするユーザ認証方法。
【請求項８】
請求項６記載のユーザ認証方法において、
前記ゲートウェイは前記ユーザ端末に確認情報を要求し、その確認情報を確認した後に、前記第１の認証情報の生成を行うことを特徴とするユーザ認証方法。
【請求項９】
請求項５記載のユーザ認証方法において、
前記ゲートウェイはゲートウェイが管理している秘密鍵の識別子とその特徴を表す情報を前記ユーザ端末に送信し、前記ユーザ端末から指定された前記識別子に対応する秘密鍵と、その秘密鍵に対応する前記証明書とを用いて前記認証情報を生成することを特徴とするユーザ認証方法。
【請求項１０】
請求項６記載のユーザ認証方法において、
前記ゲートウェイはゲートウェイが管理している秘密鍵の識別子とその特徴を表す情報を前記ユーザ端末に送信し、前記ユーザ端末から指定された前記識別子に対応する秘密鍵と、その秘密鍵に対応する前記証明書とを用いて前記第２の認証情報を生成することを特徴とするユーザ認証方法。
【請求項１１】
第１のネットワークと第２のネットワークとを接続するゲートウェイであって、
鍵ペアを生成する手段と、
その生成した鍵ペアを記憶する手段と、
前記鍵ペアの公開鍵に対応する証明書を生成する手段と、
その生成した証明書を記憶する手段と、
前記鍵ペアの秘密鍵と前記証明書とを用いて、前記第１のネットワーク上のユーザ端末が前記第２のネットワーク上のサービス提供サーバのサービスを利用する際に必要なユーザの認証情報を生成する手段とを具備することを特徴とするゲートウェイ。
【請求項１２】
請求項１１に記載したゲートウェイとしてコンピュータを機能させるためのプログラム。
【請求項１３】
請求項１２に記載したプログラムを記録したコンピュータで読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はネットワーク上で認証を必要とするサービスを利用する際のユーザ（利用者）の認証を行うシステム及びその方法に関する。
【背景技術】
【０００２】
従来、ネットワークを介したサービスを受けるユーザの認証や電子署名を行う方式として、公開鍵及び秘密鍵からなる一対の利用者の鍵ペアと、公開鍵を証明する公開鍵証明書とを用いた公開鍵インフラストラクチャ（Public Key Infrastructure、以下ＰＫＩと称する）や、ケルベロス（Kerberos）等のようにチケット発行サーバ（Ticket Granting Server、以下ＴＧＳと称する）によって発行されるチケットを用いたチケット方式が知られている。
しかし、ＰＫＩにおいては通常、公開鍵及び公開鍵証明書は長寿命で運用されるため、証明書失効管理のオーバーヘッドが運用コスト増大の要因となっていた。また、ユーザが同一の公開鍵を多目的に使いまわすことになるため、ユーザが利用したサービスの履歴を蓄積することが可能になり、ユーザのプライバシーが損なわれるといった問題があった。
【０００３】
また、チケット方式においてはサービスを提供する側及びサービスを受ける側がそれぞれ共有するマスター鍵をＴＧＳが管理する必要があるため、マスター鍵の管理が煩雑になり、秘匿性が低下することにより、安全性が低下するといった問題があった。
ＰＫＩやチケット方式の問題を改善しようとするものとして、例えば特許文献１に有効期間が短い公開鍵証明書と鍵ペアを生成する方法が開示されている。
図１４に特許文献１に示された公開鍵認証方法を示す。クライアント１０はリクエストメッセージを鍵配布センター２０に送る。鍵配布センター２０はリクエストメッセージに応答して有効期間の短い公開−秘密鍵ペアと公開鍵証明書を生成し、鍵ペアを格納すると共に、鍵ペアと公開鍵証明書をクライアント１０に配送する。クライアント１０は入手した公開鍵とその証明書を用いてＰＫ制御資源３０にサービス要求を行う。
鍵の有効期間を短くすることで、同一鍵の多目的の利用を制限し、かつ鍵の管理を簡素化することができる。
【特許文献１】特表２００２−５０１２１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記したような従来の技術では、鍵ペアをクライアントに配送するために、鍵ペアをネットワーク上に送出するのでクライアント側と鍵配布センターとの間で両者が交換する情報をすりかえる中間者攻撃（man-in-the-middle attack）等の攻撃の可能性があり、安全性が低下するといった問題があった。
この発明の目的はこのような問題に鑑み、従来のものと比較して攻撃に対する安全性を向上させることができ、かつユーザの利便性を向上させることができるユーザ認証システムを提供することにある。
【課題を解決するための手段】
【０００５】
この発明によれば、ネットワーク上でサービスを利用するユーザの認証を行うシステムは、第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとによって構成され、ゲートウェイは鍵ペアを生成する手段と、その生成した鍵ペアを記憶する手段と、鍵ペアの公開鍵に対応する証明書を生成する手段と、その生成した証明書を記憶する手段と、鍵ペアの秘密鍵と前記証明書とを用いてユーザの認証情報を生成する手段とを備え、サービス提供サーバはユーザ端末からサービスの提供を要求されると、ゲートウェイにおける前記認証情報の生成を要求し、その生成された認証情報を検証して正当であればユーザ端末に対してサービスを提供する構成とされる。
【０００６】
さらに、この発明によれば、ネットワーク上でサービスを利用するユーザの認証を行うシステムは、第１のネットワーク上のユーザ端末と、第２のネットワーク上のサービス提供サーバ及び証明書発行サーバと、それら第１のネットワークと第２のネットワークとを接続するゲートウェイとによって構成され、ゲートウェイはユーザの第１の認証情報を生成する手段と、その第１の認証情報の証明書発行サーバにおける認証に基づき、鍵ペアを生成する手段と、その生成した鍵ペアを記憶する手段と、証明書発行サーバより受信した前記鍵ペアの公開鍵に対応する証明書を記憶する手段と、前記鍵ペアの秘密鍵と前記証明書とを用いてユーザの第２の認証情報を生成する手段とを備え、証明書発行サーバはゲートウェイより受信した第１の認証情報を検証する手段と、ゲートウェイより受信した公開鍵に対応する証明書を生成する手段とを備えており、サービス提供サーバはユーザ端末からサービスの提供を要求されると、ゲートウェイにおける第２の認証情報の生成を要求し、その生成された第２の認証情報を検証して正当であればユーザ端末に対してサービスを提供する構成とされる。
【発明の効果】
【０００７】
この発明によるユーザ認証システムによれば、ユーザの認証情報を生成するための秘密鍵はゲートウェイからネットワーク上に送出されることはなく、ゲートウェイに格納されており、よって従来に比し、安全性の向上を図ることができる。
また、目的別かつ短期間有効な鍵を用いた認証を行うために必要な鍵ペアの生成、証明書の取得及び証明書と秘密鍵とを用いたユーザの認証情報の生成はゲートウェイもしくはゲートウェイと証明書発行サーバとによって行われるものとなっており、認証情報の生成等に例えばＵＳＢトークンなどの外部デバイスを用いる場合にはユーザ端末側にドライバのインストール等の煩雑な作業が必要となるのに対し、この発明ではそのような作業を必要としない点でユーザの利便性を向上させることができる。
【発明を実施するための最良の形態】
【０００８】
以下、この発明の実施形態を図面を参照して説明する。
〈実施形態１〉
図１はこの発明によるユーザ認証システムの実施形態１の構成を示したものであり、この形態ではゲートウェイ２００はＬＡＮ（第１のネットワーク、図示せず）とインターネット（第２のネットワーク）５００とを接続し、インターネット５００上にサービス提供サーバ３００が存在している。ＬＡＮは例えば家庭内ＬＡＮであって、複数のユーザ端末１００−１，１００−２，１００−３が接続されている。これらユーザ端末１００は例えば情報家電やパーソナルコンピュータ等とされる。
【０００９】
図２はゲートウェイ２００の構成を示したものであり、ゲートウェイ２００はプログラムが記憶されたＲＯＭと、プログラムを実行するＣＰＵと、ＣＰＵが用いるデータ等を記憶するＲＡＭとで構成される制御手段２１０によって機能ブロック２２０の各手段の動作が制御されてその機能を実現するものである。
ゲートウェイ２００はＬＡＮとインターネット５００とを接続するネットワークインターフェース２３０に加えて、例えばＲＳＡやＤＣＳＡ等のアルゴリズムを用いて非対称鍵ペアを生成する鍵生成手段２２１と、生成した鍵ペアを記憶する鍵記憶手段２２２と、生成した鍵ペアの公開鍵に対応する公開鍵証明書（以下、単に証明書と言う。）を生成する証明書生成手段２２３と、生成した証明書を記憶する証明書記憶手段２２４と、証明書とそれに対応する秘密鍵とを用いてユーザの正当性を示す認証情報を生成する認証情報生成手段２２５と、判定手段２２６とを備えている。なお、鍵記憶手段２２２にはＲＳＡやＤＣＳＡ等のアルゴリズムを用いて非対称鍵ペアを生成する鍵生成手段提供者により、ゲートウェイ２００の正当性を証明するための情報として初期鍵（秘密鍵）が記憶されている。
【００１０】
ゲートウェイ２００はコンピュータ装置によって構成できるものであり、ＲＯＭもしくはハードディスク装置等の記憶手段（図示せず）に記憶されているプログラムには、これから説明するユーザ認証システムにおける動作を実行するためのプログラムが含まれている。このプログラムはＣＤ−ＲＯＭ等の記録媒体に記録可能なものである。
サービス提供サーバ３００はインターネット５００を介してコンテンツ配信、オンライン商取引等のユーザ認証を必要とするサービスを提供する事業者が運営するサーバであり、ゲートウェイ２００の提供者との例えば事前契約のもとに上記初期鍵（秘密鍵）に対応する初期鍵（公開鍵）を取得しており、それを使って送られてきた情報に付加された署名を検証して、その情報が正当なゲートウェイ２００から送信されたものであることを判別できることを特徴とする。
図３は図１に示したユーザ認証システムによって実行される認証手続きの手順を示すシーケンス図であり、以下、図３を参照して手順を説明する。
【００１１】
（１）ユーザはサービスの利用に際して、ユーザ端末１００を用いてサービス提供サーバ３００にサービスの提供を要求する（ステップＳ１）。
（２）サービス要求を受信したサービス提供サーバ３００は対象のサービスがユーザの認証を必要とする場合、ユーザ端末１００に対してゲートウェイ２００からユーザの認証情報を取得するよう応答する（ステップＳ２）。より具体的にはゲートウェイ２００のＩＰアドレスにサービス提供サーバ３００のＩＰアドレスとこの要求の識別子等の認証情報の生成に必要な情報を付加したＵＲＬを生成し、ユーザ端末１００上のブラウザなどのクライアントアプリケーションに対して、上記ＵＲＬにリダイレクトするよう指示を送る。なお、ゲートウェイ２００のＩＰアドレスはサービス要求の送信元ＩＰアドレス等の詐称が困難な情報をもとに判断する。
【００１２】
（３）上記の応答を受信したユーザ端末１００はゲートウェイ２００に対して認証情報を要求する（ステップＳ３）。より具体的にはユーザ端末１００上のブラウザなどのクライアントアプリケーションがサービス提供サーバ３００から指定されたＵＲＬに対してアクセスする。
（４）認証情報要求を受信したゲートウェイ２００は有効な証明書の有無を判断する（ステップＳ４）。この判断は証明書記憶手段２２４に例えば有効期限が切れていない有効な証明書が記憶されているか否かを判定手段２２６が判断することにより行われる。
有効な証明書がない場合、ゲートウェイ２００は鍵ペアの生成を鍵生成手段２２１において行い、生成した鍵ペアを鍵記憶手段２２２に記憶する（ステップＳ５）。さらに、その鍵ペアの公開鍵に対応する証明書を証明書生成手段２２３において生成し、生成した証明書を証明書記憶手段２２４に記憶する（ステップＳ６）。
有効な証明書がある場合はステップＳ５，Ｓ６は実行されない。なお、上記証明書には正当なゲートウェイ２００が生成した情報であることを示すために、初期鍵（秘密鍵）による署名を付加する。証明書には発行日時と有効期間が必須情報として含まれる。生成した鍵ペアの秘密鍵は耐タンパ性の高い記憶媒体への保存や暗号化等の手段を用いることによって漏洩の危険性を軽減することができる。
さらに、ゲートウェイ２００は生成した証明書とそれに対応する秘密鍵とを用いてユーザの正当性を示す認証情報を認証情報生成手段２２５において生成し（ステップＳ７）、ユーザ端末１００に対してその認証情報をサービス提供サーバ３００に送信するよう応答する（ステップＳ８）。より具体的にはサービス提供サーバ３００のＩＰアドレスに認証情報と対応する要求の識別子等の認証情報の送信に必要な情報を付加したＵＲＬを生成し、ユーザ端末１００上のブラウザなどのクライアントアプリケーションに対して上記ＵＲＬにリダイレクトするよう指示を送る。なお、サービス提供サーバ３００のＩＰアドレスと対応する要求の識別子は認証情報要求より取得する。
【００１３】
（５）上記の応答を受信したユーザ端末１００はサービス提供サーバ３００に対して認証情報を送信する（ステップＳ９）。より具体的にはユーザ端末１００上のブラウザなどのクライアントアプリケーションがゲートウェイ２００から指定されたＵＲＬに対してアクセスする。
（６）認証情報を受信したサービス提供サーバ３００は事前に設定された初期鍵（公開鍵）を用いて証明書の署名検証を用い、さらに証明書で証明された公開鍵を用いた検証を行い、認証情報の正当性を確認し（ステップＳ１０）、その内容がサービス提供サーバ３００に設定されたポリシーに合致する場合、ユーザ端末１００に対してサービスを提供する（ステップＳ１１）。
【００１４】
〈実施形態２〉
図４はこの発明によるユーザ認証システムの実施形態２の構成を示したものであり、実施形態２では実施形態１の構成に加え、証明書発行サーバ４００がインターネット５００上に存在する構成となっている。
図５は図４におけるゲートウェイ２００′の構成を示したものであり、ゲートウェイ２００′は図２に示した実施形態１の構成に対して、証明書生成手段２２３が削除された（証明書生成手段２２３を具備しない）構成となっている。
図６は証明書発行サーバ４００の構成を示したものであり、証明書発行サーバ４００はプログラムが記憶されたＲＯＭと、プログラムを実行するＣＰＵと、ＣＰＵが用いるデータ等を記憶するＲＡＭとで構成される制御手段４１０によって機能ブロック４２０の各手段の動作が制御されてその機能を実現するものである。
【００１５】
証明書発行サーバ４００はネットワークインターフェース４３０に加えて、サーバに対してアカウントをもつユーザの識別子、属性情報、そのユーザに関連する証明書等の情報を記憶するユーザ情報記憶手段４２１と、上記のユーザ情報を使って他の装置から受信した認証情報を検証し、その正当性と対象となるユーザを特定する認証情報検証手段４２２と、他の装置から受信した公開鍵に対して、その公開鍵に対応する秘密鍵によって生成された認証情報が証明する内容を制限する情報を含んだ証明書を生成する証明書生成手段４２３とを備えている。
【００１６】
サービス提供サーバ３００はこの形態では証明書発行サーバ４００を運営する事業者との事前の取り決めに基づき、証明書発行サーバ４００が発行する証明書によって保証されたユーザを信頼し、サービスを提供することを特徴とする。なお、証明書発行サーバ４００の運営者がサービス提供サーバ３００の運営者を兼ねることも想定される。
図７は図４に示したユーザ認証システムによって実行される認証手続きの手順を示すシーケンス図であり、以下、図７を参照して手順を説明する。
【００１７】
（１）ユーザはサービスの利用に際して、ユーザ端末１００を用いてサービス提供サーバ３００にサービスの提供を要求する（ステップＳ１）。
（２）サービス要求を受信したサービス提供サーバ３００は対象のサービスがユーザの認証を必要とする場合、ユーザ端末１００に対してゲートウェイ２００’からユーザの認証情報（第２の認証情報、以下、認証情報２と言う）を取得するよう応答する（ステップＳ２）。より具体的にはゲートウェイ２００’のＩＰアドレスにサービス提供サーバ３００のＩＰアドレスとこの要求の識別子等の認証情報２の生成に必要な情報を付加したＵＲＬを生成し、ユーザ端末１００上のブラウザなどのクライアントアプリケーションに対して、上記ＵＲＬにリダイレクトするよう指示を送る。なお、ゲートウェイ２００’のＩＰアドレスはサービス要求の送信元ＩＰアドレス等の詐称が困難な情報をもとに判断する。
【００１８】
（３）上記の応答を受信したユーザ端末１００はゲートウェイ２００’に対して認証情報２を要求する（ステップＳ３）。より具体的にはユーザ端末１００上のブラウザなどのクライアントアプリケーションがサービス提供サーバ３００から指定されたＵＲＬに対してアクセスする。
（４）認証情報２要求を受信したゲートウェイ２００’は有効な証明書の有無を判断する（ステップＳ４）。この判断は証明書記憶手段２２４に有効な証明書が記憶されているか否かを判定手段２２６が判断することにより行われる。
有効な証明書がない場合、ゲートウェイ２００’は事前に設定されたパスワード、鍵等の情報を用いて、証明書発行サーバ４００に対してユーザの正当性を証明する認証情報（第１の認証情報、以下、認証情報１と言う）を生成し（ステップＳ２１）、その生成した認証情報１を証明書発行サーバ４００に対して送信する（ステップＳ２２）。認証情報１の生成は認証情報生成手段２２５によって行われる。
（５）認証情報１を受信した証明書発行サーバ４００は事前に設定されたパスワード、鍵等の情報をもとに受信した認証情報１を認証情報検証手段４２２において検証することで（ステップＳ２３）、ユーザを特定し、その結果（認証結果）をゲートウェイ２００’に送信する（ステップＳ２４）。
【００１９】
（６）認証結果を受信したゲートウェイ２００’は認証の完了を示す認証結果を得られた場合、鍵ペアの生成を鍵生成手段２２１において行い、生成した鍵ペアを鍵記憶手段２２２に記憶する（ステップＳ２５）。そして、生成した鍵ペアの公開鍵を証明書発行サーバ４００に送信し、証明書の発行を要求する（ステップＳ２６）。
なお、ステップＳ２２の認証情報１の送信とステップＳ２６の証明書発行要求はメッセージにCookie等のセッション情報を含めることで、受信側で送信者の同一性を判別可能な状態であることを想定している。
また、証明書発行要求の中には、例えば証明書の有効期限、証明書に含まれるユーザの属性の種別、証明書に含まれるユーザの識別子の種別、証明書に記載されるユーザに対して認可される権限の種別、対応する秘密鍵で生成される認証情報が適用されるべきサービス提供サーバ３００の識別子等の証明書に対する条件を含めることができる。なお、生成した鍵ペアの秘密鍵は耐タンパ性の高い記録媒体への保存や暗号化等の手段を用いることによって漏洩の危険性を軽減することができる。
【００２０】
（７）証明書発行要求を受信した証明書発行サーバ４００は受信した公開鍵の正当性を示す証明書を証明書生成手段４２３において生成し（ステップＳ２７）、生成した証明書をゲートウェイ２００’に対して送信する（ステップＳ２８）。
なお、証明書を生成する際、上記証明書発行要求に含まれる証明書に対する条件を参照して、例えば証明書に対象となる公開鍵に関する情報や有効期限、証明書の識別子などの一般的な情報のほかに、証明書発行サーバ４００が管理するユーザの識別子、証明書発行サーバ４００とサービス提供サーバ３００の間で事前に共有されているユーザの識別子、証明書発行サーバ４００が生成した一時的な識別子、証明書発行サーバ４００がその正当性を保証するユーザの属性情報、ユーザに対して認可される権限の種類、対応する秘密鍵で生成される認証情報が適用されるべきサービス提供サーバ３００の識別子等の情報を含めることで、サービス提供サーバ３００に付加的な情報を取得させることもできる。
その際に証明書が対象とするユーザの同一性を示す情報やユーザのプライバシーにかかわる情報は例えばサービス提供サーバ３００が保持する非対称鍵ペアの公開鍵等を用いて暗号化されることが想定される。さらに、改ざんを防止する目的で例えば証明書発行サーバ４００が保持する非対称鍵ペアの秘密鍵を用いた署名を付加することで改ざんを防止することも想定される。また、証明書発行サーバ４００が証明書もしくは証明書の識別子等の証明書を識別する情報を対象となるユーザの情報と関連付けて記憶することで、のちにサービス提供サーバ３００からユーザに関して問い合わせがあった場合、証明書発行サーバ４００はそれらの情報を鍵としてユーザを特定することができる。
【００２１】
（８）証明書を受信したゲートウェイ２００’は取得した証明書をそれに対応する鍵ペアと関連づけて証明書記憶手段２２４に記憶する（ステップＳ２９）。そして、証明書とそれに対応する秘密鍵を用いてユーザの正当性を示す認証情報２を認証情報生成手段２２５において生成し（ステップＳ７）、ユーザ端末１００に対してサービス提供サーバ３００に認証情報２を送信するよう応答する（ステップＳ８）。より具体的にはサービス提供サーバ３００のＩＰアドレスに認証情報２と対応する要求の識別子等の認証情報２の送信に必要な情報を付加したＵＲＬを生成し、ユーザ端末１００上のブラウザなどのクライアントアプリケーションに対して上記ＵＲＬにリダイレクトするよう指示を送る。なお、サービス提供サーバ３００のＩＰアドレスと対応する要求の識別子は認証情報２要求より取得する。なお、ステップＳ４で有効な証明書があると判断した場合はステップＳ２１〜Ｓ２９は実行されない。
（９）上記の応答を受信したユーザ端末１００はサービス提供サーバ３００に対して認証情報２を送信する（ステップＳ９）。より具体的にはユーザ端末１００上のブラウザなどのクライアントアプリケーションがゲートウェイ２００’から指定されたＵＲＬに対してアクセスする。
（１０）認証情報２を受信したサービス提供サーバ３００は事前に設定された証明書発行サーバ３００の公開鍵を用いた署名検証、証明書で証明された公開鍵を用いた検証等により認証情報２の正当性を確認し（ステップＳ１０）、その内容がサービス提供サーバ３００に設定されたポリシーに合致する場合、ユーザ端末１００に対してサービスを提供する（ステップＳ１１）。
【００２２】
<実施形態３>
実施形態３は実施形態２において、ゲートウェイ２００’による認証情報１の生成に先立って、ユーザ端末１００を通してユーザに対し、確認情報を要求するようにしたものである。
図８は実施形態３の認証手続きの手順を示したものであり、この形態ではゲートウェイ２００’は認証情報２要求をユーザ端末１００から受信すると、ユーザ端末１００に対し、これから行う証明書取得やサービス利用等の動作の内容を通知して、ユーザの確認情報を要求する（ステップＳ３１）。確認情報の要求は、例えばユーザの許諾確認とＰＩＮコード等のユーザを認証するための情報の提示を求めるものとする。
確認情報要求を受信したユーザ端末１００は例えばディスプレイやスピーカ等の出力デバイスを用いてユーザにこれから行われる動作の内容を通知して、キーボード、マウス、指紋認証装置、ＩＣカード等の入力デバイスを用いたユーザからの許諾の意思とＰＩＮコード等のユーザを認証するための情報を取得し、ゲートウェイ２００’に対して送信する（ステップＳ３２）。
確認情報を受信したゲートウェイ２００’は受信した情報をもとにユーザを識別し、その正当性と許諾の意思を確認する（ステップＳ３３）。そして、正当性と許諾の意思を確認後、認証情報１を生成する。この形態では以上説明したステップＳ３１〜Ｓ３３が実施形態２におけるステップＳ３とＳ４の間に実行される。なお、ユーザに要求する確認情報は例えば許諾の意思だけでもよく、またＰＩＮコード等の認証情報だけでもよい。
【００２３】
<実施形態４>
実施形態４は実施形態２において、ゲートウェイ２００’による認証情報２の生成に先立って、ゲートウェイ２００’がユーザ端末１００経由でユーザに対してゲートウェイ２００’が記憶している複数の秘密鍵に関連する情報を提示して、その中から認証情報２の生成に際して使用を希望する秘密鍵の選択を要求するようにしたものである。
図９は実施形態４の認証手続きの手順を示したものであり、この形態ではゲートウェイ２００’は認証情報２要求をユーザ端末１００から受信すると、ユーザ端末１００に対し、ゲートウェイ２００’が記憶している複数の秘密鍵に関する情報、例えば対応する証明書に記載されたユーザの識別子や属性情報、利用が許諾されているサービスの名前、そのサービス上で認可されるユーザの権限などそれらに関連付けられた文字列や画像情報等をユーザ端末１００に送信して（ステップＳ４１）、ユーザにそれらの中から一つを選択させるもしくは証明書発行要求を行い、新たな秘密鍵を生成させることを要求するように指示する。
【００２４】
秘密鍵情報一覧を受信したユーザ端末１００は例えばディスプレイやスピーカ等の出力デバイスを用いてユーザにその一覧とユーザが新しい証明書の発行を要請するための情報を通知して、キーボード、マウス等の入力デバイスを用いたユーザからの選択した秘密鍵に関わる情報もしくは証明書発行の要請を取得し、ゲートウェイ２００’に対してその秘密鍵の識別子もしくは証明書発行要求を送信する（ステップＳ４２）。
ゲートウェイ２００’は証明書発行要求を受信した場合には（ステップＳ４３）、認証情報１の生成を行い（ステップＳ２１）、以下、実施形態２と同様の手順が実行される。一方、秘密鍵識別子を受信した場合には、受信した情報をもとにユーザが選択した秘密鍵を識別し、その秘密鍵と、秘密鍵と対応する証明書とを用いて認証情報２を生成する（ステップＳ７）。この形態では上述したステップＳ４１〜Ｓ４３が実施形態２におけるステップＳ３とＳ４の間に実行される。
【００２５】
<実施形態５>
実施形態５は実施形態３において、ゲートウェイ２００’が認証情報１の生成に先立ってユーザの正当性と許諾の意思を確認（ステップＳ３３）した後に、ゲートウェイ２００’が証明書発行サーバ４００にユーザ仮名識別子を要求し（ステップＳ５１）、ユーザ仮名識別子の送信（ステップＳ５２）を受けてゲートウェイ２００’が認証情報１の生成を行い（ステップＳ２１）、以下、実施形態３と同様の手順が実行されるようにしたものであり、図１０にこの実施形態５の認証手続きの手順を示す。
この実施形態５は証明書発行サーバ４００によってゲートウェイ２００’が発行する認証情報２の内容をコントロールしたいという要求があることが想定されることに基づく。そのための仕組みとして証明書のなかにゲートウェイ２００’が発行することが許されるユーザ仮名識別子のリスト、証明書の対象となるサービス提供サーバ３００の識別子のリストを記述しておき、サービス提供サーバ３００は自分の識別子が証明書に記載されていることを確認し、また認証情報２で指定されたユーザ仮名識別子が証明書に記載されていることを確認することで、認証が証明書発行サーバ４００のポリシーを満足する形で完了したことを確認することができる。
【００２６】
なお、ユーザ仮名識別子は証明書発行サーバユーザ識別子とサービス提供サーバユーザ識別子を連携させるためのユーザ識別子であり、証明書発行サーバ４００を運営する事業者とサービス提供サーバ３００を運営する事業者の事前の取り決めにより共有される。仮名を用いた連携により各サービス提供事業者によるユーザの行動把握が難しくなり、それによってユーザのオンラインサービスにおけるプライバシー保護の観点から有効である。
上記において証明書発行サーバユーザ識別子は証明書発行サーバ４００がユーザを識別するための識別子であり、ユーザが例えば証明書発行サーバ４００を運営する事業者との事前契約等により証明書発行サーバ４００にアカウントを持っていることを想定している。また、サービス提供サーバユーザ識別子はサービス提供サーバ３００がユーザを識別するための識別子であり、ユーザが例えばサービス提供サーバ３００を運営する事業者との事前契約等によりサービス提供サーバ３００にアカウントを持っていることを想定している。
【００２７】
〈実施形態６〉
実施形態６はサービス提供サーバ３００が認証情報にユーザ属性を付加するように要求した場合、ゲートウェイ２００がユーザ端末１００に対して要求されたユーザ属性を認証情報に含めてよいか許諾を得るためのシーケンスを追加したものである。
図１１は実施形態６の認証手続きの手順を示したものであり、この形態では実施形態１におけるステップＳ３とＳ４の間に、ゲートウェイ２００がユーザ端末１００に対して認証情報にユーザの属性情報を含めてよいかの確認要求を行い（ステップＳ６１）、ユーザ端末１００は属性情報確認要求に対し、応答する（ステップＳ６２）。
【００２８】
〈実施形態７〉
実施形態７はサービス提供サーバ３００が認証情報を検証し、ユーザの正当性を確認した際に、要求があったサービスにおいてユーザのアカウントを作成するようにしたものであり、図１２はその手順を示したものである。なお、図１２は図３に示した実施形態１の手順に適用した場合を示している。
この形態では認証情報の検証（ステップＳ１０）を終了したサービス提供サーバ３００はユーザの正当性が確認された場合、証明書から得られた情報をもとにユーザのアカウントを作成し（ステップＳ７１）、ユーザ端末１００に対してアカウントの作成が完了したことを通知する（ステップＳ７２）。
【００２９】
〈変形実施形態〉
この実施形態はサービス提供サーバ３００からの認証情報要求を受けてゲートウェイ２００が鍵ペア生成、証明書生成及び認証情報生成といった一連の手順を行うのではなく、サービス利用のための事前準備として、証明書を予め取得しておくようにしたものであり、図１３はその手順を示したものである。なお、図１３は図３に示した実施形態１の手順の変形形態となっている。
この形態ではユーザはサービス利用のための事前準備としてユーザ端末１００を用いてゲートウェイ２００に対して証明書の取得を要求する。証明書生成要求はユーザ端末１００からゲートウェイ２００に送信される（ステップＳ８１）。なお、この手順はユーザ端末１００のインターネットブラウザ等のソフトウェアにより定期的に実行されるように実装してもよい。
証明書生成要求を受信したゲートウェイ２００は鍵ペアの生成を行い、生成した鍵ペアを記憶し（ステップＳ８２）、さらにその公開鍵に対応する証明書を生成し、生成した証明書を記憶する（ステップＳ８３）。そして、ユーザ端末１００に対して証明書の生成が完了したことを通知する（ステップＳ８４）。
【００３０】
この形態では証明書が予め生成、記憶されているため、ユーザがユーザ端末１００を用いてサービス提供サーバ３００にサービスの提供を要求（ステップＳ１）した際には、ゲートウェイ２００はサービス提供サーバ３００からの認証情報要求（ステップＳ２，Ｓ３）を受けてユーザの認証情報を、生成されている証明書とそれに対応する秘密鍵とを用いて生成する（ステップＳ７）。
以上、各種実施形態について説明したが、この発明によるユーザ認証システムでは、目的別かつ短期間有効な鍵を用いた認証を行うために必要な鍵ペアの生成、証明書の取得、秘密鍵を用いた認証情報の生成等の機能をＬＡＮ内に存在するゲートウェイが行うものとなっている。
【００３１】
従来においては複数のユーザ端末で認証情報の生成等を利用するという目的で、例えばＵＳＢトークンなどの外部デバイスに認証情報の生成等の機能を実装するということは行われていたが、この方法ではユーザ端末と外部デバイス間で安全な通信路を確立しやすいというメリットがある一方で、ユーザ端末側にドライバのインストールやデバイスの差し替え等のユーザによる設定が必要であるというデメリットがあった。
これに対し、この発明ではユーザ端末とゲートウェイ間のやりとりはすべて標準的なプロトコルに基づいて行われるのでユーザ端末にインストール等の煩雑な設定を必要としないというメリットがある。
【図面の簡単な説明】
【００３２】
【図１】この発明によるユーザ認証システムの実施形態１の構成を示す図。
【図２】図１におけるゲートウェイの要部構成を説明するための図。
【図３】この発明によるユーザ認証システムの実施形態１の動作を説明するためのシーケンス図。
【図４】この発明によるユーザ認証システムの実施形態２の構成を示す図。
【図５】図４におけるゲートウェイの要部構成を説明するための図。
【図６】図４における証明書発行サーバの要部構成を説明するための図。
【図７】この発明によるユーザ認証システムの実施形態２の動作を説明するためのシーケンス図。
【図８】この発明によるユーザ認証システムの実施形態３の動作を説明するためのシーケンス図。
【図９】この発明によるユーザ認証システムの実施形態４の動作を説明するためのシーケンス図。
【図１０】この発明によるユーザ認証システムの実施形態５の動作を説明するためのシーケンス図。
【図１１】この発明によるユーザ認証システムの実施形態６の動作を説明するためのシーケンス図。
【図１２】この発明によるユーザ認証システムの実施形態７の動作を説明するためのシーケンス図。
【図１３】この発明によるユーザ認証システムの変形実施形態の動作を説明するためのシーケンス図。
【図１４】従来の公開鍵認証方法を説明するための図。
【図１】
2008129673.tif 000003
【図２】
2008129673.tif 000004
【図３】
2008129673.tif 000005
【図４】
2008129673.tif 000006
【図５】
2008129673.tif 000007
【図６】
2008129673.tif 000008
【図７】
2008129673.tif 000009
【図８】
2008129673.tif 000010
【図９】
2008129673.tif 000011
【図１０】
2008129673.tif 000012
【図１１】
2008129673.tif 000013
【図１２】
2008129673.tif 000014
【図１３】
2008129673.tif 000015
【図１４】
2008129673.tif 000016