(57)【要約】【課題】安全性が高く、より簡易に使用できる認証システムを提供する。【解決手段】複数のユーザ端末と、認証サーバを含む認証システムであって、ユーザ端末は、個人情報を含まない公開鍵と、公開鍵に対応する秘密鍵とを生成して、公開鍵を含む登録情報を認証サーバに送信する第１登録部と、秘密鍵を用いて自端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する第１認証部を含み、認証サーバは、受信した登録情報をユーザ端末ごとに記憶する第２登録部と、登録情報に含まれる公開鍵を用いてユーザ端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する第２認証部を含む。【選択図】図２
2015138978.tif 000002
【特許請求の範囲】
【請求項１】
複数のユーザ端末と、認証サーバを含む認証システムであって、
前記ユーザ端末は、
個人情報を含まない公開鍵と、前記公開鍵に対応する秘密鍵とを生成して、前記公開鍵を含む登録情報を前記認証サーバに送信する第１登録部と、
前記秘密鍵を用いて自端末が前記公開鍵に対応する前記秘密鍵を所持していることを認証、又は前記認証に必要なデータを生成して送信する第１認証部を含み、
前記認証サーバは、
受信した前記登録情報を前記ユーザ端末ごとに記憶する第２登録部と、
前記登録情報に含まれる前記公開鍵を用いて前記ユーザ端末が前記公開鍵に対応する前記秘密鍵を所持していることを認証、又は前記認証に必要なデータを生成して送信する第２認証部を含む
認証システム。
【請求項２】
請求項１に記載の認証システムであって、
前記第１登録部は、
自端末を識別する情報である識別子を取得する識別子取得部と、
個人情報を含まない公開鍵と、前記公開鍵に対応する秘密鍵とを生成する鍵生成部と、
前記秘密鍵を記憶する秘密鍵記憶部と、
前記識別子と前記公開鍵の組を前記登録情報として前記認証サーバに送信する登録情報送信部を含み、
前記第１認証部は、
認証開始時に前記識別子を前記認証サーバに送信する識別子送信部と、
前記認証サーバから暗号文を受信する暗号文受信部と、
前記秘密鍵を用いて前記暗号文を復号してセッション鍵を取得する暗号文復号部を含み、
前記第２登録部は、
前記登録情報を受信する登録情報受信部と、
受信した前記登録情報を記憶する登録情報記憶部を含み、
前記第２認証部は、
前記識別子を受信する識別子受信部と、
前記受信した識別子に対応する前記公開鍵を前記登録情報記憶部から取得する公開鍵取得部と、
前記セッション鍵を生成するセッション鍵生成部と、
受信した前記識別子に対応する公開鍵を用いて、前記セッション鍵を暗号化して前記暗号文を生成する暗号文生成部と、
前記暗号文を前記ユーザ端末に送信する暗号文送信部を含む
認証システム。
【請求項３】
請求項１に記載の認証システムであって、
前記第１登録部は、
自端末を識別する情報である識別子を取得する識別子取得部と、
個人情報を含まない公開鍵と、前記公開鍵に対応する秘密鍵とを生成する鍵生成部と、
前記秘密鍵を記憶する秘密鍵記憶部と、
前記識別子と前記公開鍵の組を前記登録情報として前記認証サーバに送信する登録情報送信部を含み、
前記第１認証部は、
認証開始時に前記識別子を前記認証サーバに送信する識別子送信部と、
前記認証サーバから乱数を受信する乱数受信部と、
前記秘密鍵を用いて前記乱数の署名を生成する署名生成部と、
前記署名を前記認証サーバに送信する署名送信部を含み、
前記第２登録部は、
前記登録情報を受信する登録情報受信部と、
受信した前記登録情報を記憶する登録情報記憶部を含み、
前記第２認証部は、
前記識別子を受信する識別子受信部と、
受信した前記識別子に対応する前記公開鍵を前記登録情報記憶部から取得する公開鍵取得部と、
前記乱数を生成する乱数生成部と、
前記乱数を前記ユーザ端末に送信する乱数送信部と、
前記署名を前記ユーザ端末から受信する署名受信部と、
受信した前記識別子に対応する前記公開鍵を用いて、前記署名を検証する署名検証部を含む
認証システム。
【請求項４】
請求項１に記載の認証システムであって、
証明書署名要求に対して証明書を発行する認証局をさらに含み、
前記第１登録部は、
個人情報を含まない公開鍵と、前記公開鍵に対応する秘密鍵とを生成する鍵生成部と、
前記秘密鍵を記憶する秘密鍵記憶部と、
前記公開鍵を前記登録情報として前記認証サーバに送信する登録情報送信部と、
前記認証局から前記公開鍵に対応する前記証明書を受信する証明書受信部と、
前記証明書を記憶する証明書記憶部を含み、
前記第１認証部は、
認証開始時に前記証明書を前記認証サーバに送信する証明書送信部と、
前記認証サーバから暗号文を受信する暗号文受信部と、
前記秘密鍵を用いて前記暗号文を復号してセッション鍵を取得する暗号文復号部を含み、
前記第２登録部は、
前記登録情報として前記公開鍵を受信する登録情報受信部と、
受信した前記公開鍵を前記証明書署名要求に含むべき個人情報の代用として、前記証明書署名要求を生成する証明書署名要求生成部と、
前記証明書署名要求を前記認証局に送信する証明書署名要求送信部と、
前記認証局から前記公開鍵に対応する前記証明書を受信する証明書受信部と、
受信した前記公開鍵と前記公開鍵に対応する前記証明書の組を記憶する公開鍵−証明書記憶部を含み、
前記第２認証部は、
前記ユーザ端末から送信された前記証明書を受信する証明書受信部と、
前記ユーザ端末から送信された前記証明書に対応する前記公開鍵を前記証明書−公開鍵記憶部から取得する公開鍵取得部と、
前記セッション鍵を生成するセッション鍵生成部と、
前記ユーザ端末から送信された前記証明書に対応する前記公開鍵を用いて、前記セッション鍵を暗号化して前記暗号文を生成する暗号文生成部と、
前記暗号文を送信する暗号文送信部を含む
認証システム。
【請求項５】
請求項１から４のいずれかに記載の認証システムであって、
前記ユーザ端末からのアクセスに応じて前記認証サーバに認証クエリを送信するサービス提供サーバをさらに含み、
前記認証サーバは、
前記認証クエリを受信した場合にアクセスを実行した前記ユーザ端末との認証の結果である認証結果通知を前記サービス提供サーバに送信する認証結果通知部をさらに含む
認証システム。
【請求項６】
請求項１から４のいずれかに記載の認証システムであって、
前記認証サーバは、
前記第２認証部における認証が成功する度に許可トークンを生成し、前記許可トークンを認証相手である前記ユーザ端末に送信する許可トークン送信部をさらに含む
認証システム。
【請求項７】
コンピュータを、請求項１から６のいずれかに記載の認証システムに含まれるユーザ端末として機能させるためのプログラム。
【請求項８】
コンピュータを、請求項１から６のいずれかに記載の認証システムに含まれる認証サーバとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンライン上でユーザ認証を実行する認証システム、プログラムに関する。
【背景技術】
【０００２】
従来、インターネットやイントラネットにおけるネットワーク上のリソースに対するアクセス制御方法がいくつか提案されている。よく知られているのは、ＩＤとパスワードを用いるＢａｓｉｃ認証である（非特許文献１参照）。これ以外にも、アクセス元のＩＰアドレスによりアクセス制御を行う方法がある。他には、個人用証明書を使用した認証方法がある。個人用証明書を使用した認証方法としてよく知られているものにベリサイン（登録商標）社が提供している個人用電子証明書サービスがある（非特許文献２参照）。また、個人用証明書を使用した認証方法として、ＡｐａｃｈｅのＦａｋｅＢａｓｉｃ認証が知られている（非特許文献３参照）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】“HTTP Authentication: Basic and Digest Access Authentication”、［online］、［平成 25年 1月 10日検索］、インターネット〈URL：http://tools.ietf.org/html/rfc2617〉
【非特許文献２】“ベリサイン 個人用電子証明書 Class2 スタンダード - 組織内個人を認証 -”、［online］、［平成 25年 1月 10日検索］、インターネット〈URL：https://www.verisign.co.jp/personal/class2/index.html〉
【非特許文献３】“Fake Basic Authentication”、［online］、［平成 25年 1月 10日検索］、インターネット〈URL：http://httpd.apache.org/docs/2.2/mod/mod_ssl.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ＩＤとパスワードを用いる認証方法では、通常サーバ側はパスワードをハッシュ関数で変換した値を管理することになるが、この値が漏えいすれば、この値に対して総当たり攻撃をしかけることによりパスワードが不正に入手できてしまうため、セキュリティの観点から問題がある。アクセス元のＩＰアドレスによりアクセス制御を行う方法では、アクセス元のＩＰアドレスに対して不正な改竄が行われる場合があり、ＩＤとパスワードを用いる認証方法と同様にセキュリティの観点から問題がある。
【０００５】
また個人用証明書を使う認証方法では、本人確認手続きなどが煩雑で導入コストが高いという問題がある。
【０００６】
そこで、本発明では安全性が高く、より簡易に使用できる認証システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の認証システムは、複数のユーザ端末と、認証サーバを含む。ユーザ端末は、第１登録部と、第１認証部を含み、認証サーバは、第２登録部と、第２認証部を含む。
【０００８】
第１登録部は、個人情報を含まない公開鍵と、公開鍵に対応する秘密鍵とを生成して、公開鍵を含む登録情報を認証サーバに送信する。第１認証部は、秘密鍵を用いて自端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する。第２登録部は、受信した登録情報をユーザ端末ごとに記憶する。第２認証部は、登録情報に含まれる公開鍵を用いてユーザ端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する。
【発明の効果】
【０００９】
本発明の認証システムは、安全性が高く、より簡易に使用できる。
【図面の簡単な説明】
【００１０】
【図１】実施例１の認証システムの概要を示すブロック図。
【図２】実施例１のユーザ端末、認証サーバの構成を示すブロック図。
【図３】実施例１のユーザ端末、認証サーバの動作を示すフローチャート。
【図４】実施例１のユーザ端末、認証サーバの詳細構成を示すブロック図。
【図５】実施例１のユーザ端末、認証サーバの動作の詳細を示すフローチャート。
【図６】実施例２の認証システムの概要を示すブロック図。
【図７】実施例２のユーザ端末、認証サーバの構成を示すブロック図。
【図８】実施例２のユーザ端末、認証サーバの詳細構成を示すブロック図。
【図９】実施例２のユーザ端末、認証サーバの動作の詳細を示すフローチャート。
【図１０】実施例３の認証システムの概要を示すブロック図。
【図１１】実施例３のユーザ端末、認証サーバの構成を示すブロック図。
【図１２】実施例３のユーザ端末、認証サーバの詳細構成を示すブロック図。
【図１３】実施例３のユーザ端末、認証サーバの動作の詳細を示すフローチャート。
【図１４】実施例４の認証システムの概要を示すブロック図。
【図１５】実施例４のユーザ端末、認証サーバの構成を示すブロック図。
【図１６】実施例４のユーザ端末、認証サーバの動作を示すフローチャート。
【図１７】実施例５の認証システムの概要を示すブロック図。
【図１８】実施例５のユーザ端末、認証サーバの構成を示すブロック図。
【図１９】実施例５のユーザ端末、認証サーバの動作を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、本発明の実施の形態について、詳細に説明する。なお、同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。
【実施例１】
【００１２】
以下、図１、図２、図３を参照して実施例１の認証システムの概要について説明する。図１は、本実施例の認証システム１の概要を示すブロック図である。図２は、本実施例のユーザ端末１１−ｋ、認証サーバ１２の構成を示すブロック図である。図３は、本実施例のユーザ端末１１−ｋ、認証サーバ１２の動作を示すフローチャートである。
【００１３】
図１に示すように、本実施例の認証システム１は、複数のユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎと、認証サーバ１２を含む。ただしｎは２以上の整数である。ｋは１以上ｎ以下の整数である。なお、ｎ台のユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎ、および認証サーバ１２は、ＮＷ９を介して互いに通信可能に接続されている。ｎ台のユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎは全て同じ機能を備えるため、これらの代表として、以下ユーザ端末１１−ｋについて述べる。図２に示すように、ユーザ端末１１−ｋは、第１登録部１１１と、第１認証部１１２を含み、認証サーバ１２は、第２登録部１２１と、第２認証部１２２を含む。図３に示すように、まずユーザ端末１１−ｋの第１登録部１１１は、個人情報を含まない公開鍵と、公開鍵に対応する秘密鍵とを生成して、公開鍵を含む登録情報を認証サーバに送信する（Ｓ１１１）。次に、認証サーバ１２の第２登録部１２１は、受信した登録情報をユーザ端末ごとに記憶する（Ｓ１２１）。以上がユーザ登録動作である。次に、ユーザ端末１１−ｋの第１認証部１１２は、秘密鍵を用いて自端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する（Ｓ１１２）。次に、認証サーバ１２の第２認証部１２２は、登録情報に含まれる公開鍵を用いてユーザ端末が公開鍵に対応する秘密鍵を所持していることを認証、又は認証に必要なデータを生成して送信する（Ｓ１２２）。以上がユーザ認証動作である。
【００１４】
以下、図４、図５を参照して本実施例の認証システム１の詳細について説明する。図４は、本実施例のユーザ端末１１−ｋ、認証サーバ１２の詳細構成を示すブロック図である。図５は、本実施例のユーザ端末１１−ｋ、認証サーバ１２の動作の詳細を示すフローチャートである。
【００１５】
図４に示すように第１登録部１１１は、識別子取得部１１１１と、鍵生成部１１１２と、秘密鍵記憶部１１１３と、登録情報送信部１１１４を含む。第１認証部１１２は、識別子送信部１１２１と、暗号文受信部１１２２と、暗号文復号部１１２３を含む。第２登録部１２１は、登録情報受信部１２１１と、登録情報記憶部１２１２を含む。第２認証部１２２は、識別子受信部１２２１と、公開鍵取得部１２２２と、セッション鍵生成部１２２３と、暗号文生成部１２２４と、暗号文送信部１２２５を含む。
【００１６】
図５に示すように、まず第１登録部１１１の識別子取得部１１１１は、自端末を識別する情報である識別子ＩＤｋを取得する（Ｓ１１１１）。識別子としては、例えばユーザが独自に設定した文字列を用いることができる。また、ユーザのメールアドレスを識別子とすることができる。また、システムから識別子が割り振られるようにしてもよい。これ以外には、例えば後述する実施例３のように公開鍵そのものを識別子として用いることもできる。次に、鍵生成部１１１２は、個人情報を含まない公開鍵ＰＫｋと、公開鍵ＰＫｋに対応する秘密鍵ＳＫｋとを生成する（Ｓ１１１２）。次に、秘密鍵記憶部１１１３は、秘密鍵ＳＫｋを記憶する（Ｓ１１１３）。次に、登録情報送信部１１１４は、識別子ＩＤｋと公開鍵ＰＫｋの組を登録情報として認証サーバ１２に送信する（Ｓ１１１４）。
【００１７】
次に、第２登録部１２１の登録情報受信部１２１１は、登録情報を受信する（Ｓ１２１１）。登録情報記憶部１２１２は、受信した登録情報を記憶する（Ｓ１２１２）。以上がユーザ登録動作の詳細である。
【００１８】
次に、第１認証部１１２の識別子送信部１１２１は、認証開始時に識別子ＩＤｋを認証サーバ１２に送信する（Ｓ１１２１）。
【００１９】
次に、第２認証部１２２の識別子受信部１２２１は、識別子ＩＤｋを受信する（Ｓ１２２１）。次に、公開鍵取得部１２２２は、受信した識別子ＩＤｋに対応する公開鍵ＰＫｋを登録情報記憶部１２１２から取得する（Ｓ１２２２）。次に、セッション鍵生成部１２２３は、セッション鍵Ｋを生成する（Ｓ１２２３）。次に、暗号文生成部１２２４は、受信した識別子ＩＤｋに対応する公開鍵ＰＫｋを用いて、セッション鍵Ｋを暗号化して暗号文Ｃ＝ＥｎｃＰＫ（Ｋ）を生成する（Ｓ１２２４）。次に、暗号文送信部１２２５は、暗号文Ｃ＝ＥｎｃＰＫ（Ｋ）をユーザ端末１１−ｋに送信する（Ｓ１２２５）。
【００２０】
次に、第１認証部１１２の暗号文受信部１１２２は、認証サーバ１２から暗号文を受信する（Ｓ１１２２）。次に、暗号文復号部１１２３は、秘密鍵ＳＫｋを用いて暗号文Ｃを復号してセッション鍵Ｋを取得する（Ｓ１１２３）。セッション鍵Ｋで通信が可能であれば、認証成功とみなされる。以後、ユーザ端末１１−ｋと認証サーバ１２とは、セッション鍵Ｋを用いて安全に通信を行うことができる。以上がユーザ認証動作の詳細である。
【００２１】
本実施例の認証システム１は、ユーザ登録時には、第１登録部１１１が公開鍵を含む登録情報を送信し、ユーザ認証時は識別子送信部１１２２が識別子を送信する。従って、認証サーバ１２には、例え漏えいしても安全性に問題がない公開鍵や識別子などが送信されるだけである。一方、秘匿されるべき秘密鍵はユーザ端末１１−ｋの秘密鍵記憶部１１１３内で安全に秘匿されている。従って、例え通信を傍受されたり、認証サーバ１２が管理する登録情報が漏えいしたとしてもセキュリティ上の問題が発生しない。また、セッション鍵Ｋは、暗号化されてユーザ端末１１−ｋに送信されるため、通信中の第三者の盗聴を防ぐことができる。これらの点において本認証システムは、ＩＤとパスワードを使用するＢａｓｉｃ認証よりも優れている。また、本実施例の認証システム１で用いられる公開鍵や識別子は個人情報を含まないため、事前の本人確認手続きなど煩雑な手続きが不要である。このため、ユーザは簡単に本認証システムを利用できる。また、個人用証明書を使う従来のアクセス制御方法では、端末のアクセスを不許可とする場合に証明書失効リストを正しく管理する必要があり、またその即時性も低いが、本認証システムでは認証サーバ１２がリソースと公開鍵の紐付け情報を変更するだけでよいため、管理に手間がかからず、即時性がある。これらの点において本認証システムは、個人用証明書を使う認証方法よりも優れている。
【００２２】
昨今の認証を必要とするオンライン上のサービスは、本名や所属を証明しなくても十分なものが多い。このようなサービスでは、認証に必要な機能は「利用者が初回に登録したときにつけたＩＤと対応する秘密情報を持っていることを確認すること」のみで足りる。本実施例の認証システム１は、この条件を上手く利用して、本名や所属の証明に必要となる余分なコスト、煩雑さを上手く取り除いたことがポイントである。
【実施例２】
【００２３】
以下、図６、図７を参照して実施例１と異なる認証方法とした実施例２の認証システムの概要について説明する。図６は本実施例の認証システム２の概要を示すブロック図である。図７は本実施例のユーザ端末２１−ｋ、認証サーバ２２の構成を示すブロック図である。
【００２４】
図６に示すように、本実施例の認証システム２は、複数のユーザ端末２１−１，２１−２，…，２１−ｋ，…，２１−ｎと、認証サーバ２２を含む。なお、ｎ台のユーザ端末２１−１，２１−２，…，２１−ｋ，…，２１−ｎ、および認証サーバ２２は、ＮＷ９を介して互いに通信可能に接続されている。ｎ台のユーザ端末２１−１，２１−２，…，２１−ｋ，…，２１−ｎは全て同じ機能を備えるため、これらの代表として、以下、ユーザ端末２１−ｋについて述べる。図７に示すように、ユーザ端末２１−ｋは、第１登録部１１１と、第１認証部２１２を含み、認証サーバ２２は、第２登録部１２１と、第２認証部２２２を含む。第１登録部１１１、第２登録部１２１については、実施例１と同様であるため、ユーザ登録動作の詳細については説明を割愛する。
【００２５】
以下、図８、図９を参照して本実施例の認証システム２の詳細について説明する。図８は、本実施例のユーザ端末２１−ｋ、認証サーバ２２の詳細構成を示すブロック図である。図９は、本実施例のユーザ端末２１−ｋ、認証サーバ２２の動作の詳細を示すフローチャートである。
【００２６】
図８に示すように第１認証部２１２は、識別子送信部１１２１と、乱数受信部２１２２と、署名生成部２１２３と、署名送信部２１２４を含む。第２認証部２２２は、識別子受信部１２２１と、公開鍵取得部１２２２と、乱数生成部２２２３と、乱数送信部２２２４と、署名受信部２２２５と、署名検証部２２２６を含む。
【００２７】
図９に示すように、ユーザ認証動作において、まず第１認証部２１２の識別子送信部１１２１は、認証開始時に識別子ＩＤｋを認証サーバに送信する（Ｓ１１２１）。
【００２８】
次に、第２認証部２２２の識別子受信部１２２１は、識別子ＩＤｋを受信する（Ｓ１２２１）。次に、公開鍵取得部１２２２は、受信した識別子ＩＤｋに対応する公開鍵ＰＫｋを登録情報記憶部１２１２から取得する（Ｓ１２２２）。次に、乱数生成部２２２３は、乱数ｒを生成する（Ｓ２２２３）。次に、乱数送信部２２２４は、乱数ｒをユーザ端末２１−ｋに送信する（Ｓ２２２４）。
【００２９】
次に、第１認証部２１２の乱数受信部２１２２は、認証サーバ２２から乱数ｒを受信する（Ｓ２１２２）。次に、署名生成部２１２３は、秘密鍵ＳＫｋを用いて乱数ｒの署名σ＝ｓｉｇ（ＳＫｋ，ｒ）を生成する（Ｓ２１２３）。次に、署名送信部２１２４は、署名σ＝ｓｉｇ（ＳＫｋ，ｒ）を認証サーバ２２に送信する（Ｓ２１２４）。
【００３０】
次に、第２認証部２２２の署名受信部２２２５は、署名σをユーザ端末２１−ｋから受信する（Ｓ２２２５）。次に、署名検証部２２２６は、受信した識別子ＩＤｋに対応する公開鍵ＰＫｋを用いて、署名σを検証する（Ｓ２２２６）。
【００３１】
このように、本実施例の認証システム２によれば、秘密鍵による署名を用いて実施例１と同様に安全性が高く、より簡易な認証を実現することができる。
【実施例３】
【００３２】
以下、図１０、図１１を参照して、前述の識別情報の代わりに認証局が発行する証明書を用いる認証方法とした実施例３の認証システムの概要について説明する。図１０は本実施例の認証システム３の概要を示すブロック図である。図１１は本実施例のユーザ端末３１−ｋ、認証サーバ３２の構成を示すブロック図である。
【００３３】
図１０に示すように、本実施例の認証システム３は、複数のユーザ端末３１−１，３１−２，…，３１−ｋ，…，３１−ｎと、認証サーバ３２と、認証局３３を含む。なお、ｎ台のユーザ端末３１−１，３１−２，…，３１−ｋ，…，３１−ｎ、認証サーバ３２、および認証局３３は、ＮＷ９を介して互いに通信可能に接続されている。ｎ台のユーザ端末３１−１，３１−２，…，３１−ｋ，…，３１−ｎは全て同じ機能を備えるため、これらの代表として、以下、ユーザ端末３１−ｋについて述べる。図１１に示すように、ユーザ端末３１−ｋは、第１登録部３１１と、第１認証部３１２を含み、認証サーバ３２は、第２登録部３２１と、第２認証部３２２を含む。
【００３４】
以下、図１２、図１３を参照して本実施例の認証システム３の詳細について説明する。図１２は、本実施例のユーザ端末３１−ｋ、認証サーバ３２の詳細構成を示すブロック図である。図１３は、本実施例のユーザ端末３１−ｋ、認証サーバ３２の動作の詳細を示すフローチャートである。
【００３５】
図１２に示すように第１登録部３１１は、鍵生成部１１１２と、秘密鍵記憶部１１１３と、登録情報送信部３１１４と、証明書受信部３１１５と、証明書記憶部３１１６を含む。第１認証部３１２は、証明書送信部３１２１と、暗号文受信部１１２２と、暗号文復号部１１２３を含む。第２登録部３２１は、登録情報受信部３２１１と、証明書署名要求生成部３２１２と、証明書署名要求送信部３２１３と、証明書受信部３２１４と、公開鍵−証明書記憶部３２１５を含む。第２認証部３２２は、証明書受信部３２２１と、公開鍵取得部３２２２と、セッション鍵生成部１２２３と、暗号文生成部１２２４と、暗号文送信部１２２５を含む。なお、第１認証部３１２、第２認証部３２２については、実施例１における識別子の代わりに証明書を用いている点のみが異なるため、ユーザ認証動作の説明は適宜割愛する。
【００３６】
ステップＳ１１１２、Ｓ１１１３は実施例１と同じであるため、説明を割愛する。次に、第１登録部３１１の登録情報送信部３１１４は、公開鍵ＰＫｋのみを登録情報として認証サーバ３２に送信する（Ｓ３１１４）。次に、第２登録部３２１の登録情報受信部３２１１は、登録情報として公開鍵ＰＫｋを受信する（Ｓ３２１１）。次に、証明書署名要求生成部３２１２は、受信した公開鍵ＰＫｋを証明書署名要求ＣＳＲに含むべき個人情報の代用として、証明書署名要求ＣＳＲを生成する（Ｓ３２１２）。次に、証明書署名要求送信部３２１３は、証明書署名要求ＣＳＲを認証局３３に送信する（Ｓ３２１３）。
【００３７】
次に、認証局３３は、証明書署名要求ＣＳＲを受信する（Ｓ３３１）。次に、認証局３３は、公開鍵ＰＫｋに対応する証明書ｃｅｒｔｋを生成して、認証サーバ３２に送信する（Ｓ３３２）。
【００３８】
次に、第２登録部３２１の証明書受信部３２１４は、認証局３３から公開鍵ＰＫｋに対応する証明書ｃｅｒｔｋを受信する（Ｓ３２１４）。公開鍵−証明書記憶部３２１５は、受信した公開鍵ＰＫｋと公開鍵ＰＫｋに対応する証明書ｃｅｒｔｋの組を記憶する（Ｓ３２１５）。以上が、ユーザ登録動作の詳細である。
【００３９】
第１登録部３１１の証明書受信部３１１５は、認証局３３から公開鍵ＰＫｋに対応する証明書ｃｅｒｔｋを受信する（Ｓ３１１５）。次に、証明書記憶部３１１６は、証明書ｃｅｒｔｋを記憶する（Ｓ３１１６）。
【００４０】
ユーザ認証動作においては、図１３に示すように、第１認証部３１２の証明書送信部３１２１は、認証開始時に証明書ｃｅｒｔｋを認証サーバ３２に送信する（Ｓ３１２１）。
【００４１】
次に、第２認証部３２２の証明書受信部３２２１は、ユーザ端末３１−ｋから送信された証明書ｃｅｒｔｋを受信する（Ｓ３２２１）。次に、公開鍵取得部３２２２は、ユーザ端末３１−ｋから送信された証明書ｃｅｒｔｋに対応する公開鍵ＰＫｋを証明書−公開鍵記憶部３２１５から取得する（Ｓ３２２２）。前述したように、本実施例では実施例１における識別子の代わりに証明書を用いている点のみが異なる。従って、ステップＳ１２２３以降の動作は実施例１と同じであるため説明を割愛する。
【００４２】
なお、本実施例の認証システム３は、ＷｅｂブラウザとＷｅｂサーバの認証で実装することができる。従来のＩＤパスワードによる認証の場合、ユーザがブラウザの入力欄にＩＤとパスワードを手入力し、Ｂａｓｉｃ認証などのプロトコルを用いて認証を行うことができる。一方、本認証システムの場合、ブラウザの入力欄に公開鍵暗号の秘密鍵を手入力することは現実的ではない。そこで、個人用証明書を認証するプロトコルであるＦａｋｅＢａｓｉｃ認証（非特許文献３）を利用することで本認証システムを実現することができる。この場合、認証サーバ側３２では、ＡｐａｃｈｅのＦａｋｅＢａｓｉｃ認証を有効にすることで、個人用証明書を用いた認証を行なうことができる。認証には、ＬＤＡＰを利用する設定とする。ＬＤＡＰは、インターネットやイントラネットなどのＴＣＰ／ＩＰネットワークで、ディレクトリデータベースにアクセスするためのプロトコルである。本認証システムでは、認証サーバ３２において、登録されたユーザ公開鍵のリストをデータベースに登録するためにＬＤＡＰを使用することができる。
【００４３】
本実施例の認証システム３では、証明書署名要求生成部３２１２が、証明書署名要求ＣＳＲに含むべき個人情報の代用として公開鍵を用いて、証明書署名要求ＣＳＲを生成するように構成したため、ＦａｋｅＢａｓｉｃ認証などの個人用証明書を認証するプロトコルを用いて実装した場合でも、個人用証明書を使う認証方法特有の煩雑さが発生しない。
【実施例４】
【００４４】
以下、図１４、図１５、図１６を参照して、実施例１の構成に加えて認証サーバが、他のサーバ（各種サービスを提供するサービス提供サーバ）に認証結果通知を送信する機能を付加した実施例４の認証システム４について説明する。図１４は、本実施例の認証システム４の概要を示すブロック図である。図１５は、本実施例のユーザ端末１１−ｋ、認証サーバ４２の構成を示すブロック図である。図１６は、本実施例のユーザ端末１１−ｋ、認証サーバ４２の動作を示すフローチャートである。
【００４５】
図１４に示すように、本実施例の認証システム４は、複数のユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎと、認証サーバ４２、サービス提供サーバ４３を含む。ユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎは、実施例１と同じである。なお、ｎ台のユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎ、認証サーバ４２、およびサービス提供サーバ４３は、ＮＷ９を介して互いに通信可能に接続されている。サービス提供サーバ４３は、ユーザ端末１１−１，１１−２，…，１１−ｋ，…，１１−ｎからのアクセスに応じて認証サーバ４２に認証クエリ（認証要求）を送信する。これは、認証サーバ４２にユーザの認証動作を肩代わりさせることを目的とした動作である。例えばサービス提供サーバ４３が、ＰａｙＴＶサイト、電子書籍販売サイト、ゲームサーバなどであって、認証サーバ４２に該当するｆａｃｅｂｏｏｋ（登録商標）、ｉＴｕｎｅｓ  Ｓｔｏｒｅ（登録商標）などの規模の大きいサーバに認証動作を代行してもらう例がある。
【００４６】
図１５に示すように、認証サーバ４２は、実施例１と同じ第２登録部１２１、第２認証部１２２に加え、認証結果通知部４２３をさらに含む。図１６に示すように、認証結果通知部４２３は、認証クエリＱを受信した場合に、アクセスを実行したユーザ端末１１−ｋとの認証の結果である認証結果通知（Ｔ ｏｒ Ｆ，Ｔならば認証成功、Ｆならば認証失敗）をサービス提供サーバ４３に送信する（Ｓ４２３）。サービス提供サーバ４３は、受信した認証結果通知に基づいて、ユーザのリソースへのアクセスの可否を判断する。
【００４７】
このように、本実施例の認証システム４によれば、サービス提供サーバ４３に代わって、認証サーバ４２がアクセス元のユーザ端末１１−ｋを認証することができるため、実施例１の効果に加え、より柔軟に、様々なシステムに応用することができる。
【実施例５】
【００４８】
以下、図１７、図１８、図１９を参照して、実施例１の構成に加えて認証サーバが、認証成功時にユーザ端末に許可トークンを送信する機能を付加した実施例５の認証システム５について説明する。図１７は、本実施例の認証システム５の概要を示すブロック図である。図１８は、本実施例のユーザ端末５１−ｋ、認証サーバ５２の構成を示すブロック図である。図１９は、本実施例のユーザ端末５１−ｋ、認証サーバ５２の動作を示すフローチャートである。
【００４９】
図１７に示すように、本実施例の認証システム５は、複数のユーザ端末５１−１，５１−２，…，５１−ｋ，…，５１−ｎと、認証サーバ５２、サービス提供サーバ５３を含む。ｎ台のユーザ端末５１−１，５１−２，…，５１−ｋ，…，５１−ｎ、認証サーバ５２、およびサービス提供サーバ５３は、ＮＷ９を介して互いに通信可能に接続されている。ｎ台のユーザ端末５１−１，５１−２，…，５１−ｋ，…，５１−ｎは全て同じ機能を備えるため、これらの代表として、以下ユーザ端末５１−ｋについて述べる。本実施例では、例えば認証サーバ５２は、会社などの入退室管理システムにおけるシステム・サーバ、サービス提供サーバ５３は、社内ＬＡＮや大学の学内ＬＡＮにおけるサーバ装置などとすることができる。この場合、学生や社員が研究室や会社に入室する際に認証が実行され、認証成功時に許可トークンが発行され、社内ＬＡＮや学内ＬＡＮにおいて、この許可トークンを使用する例が想定できる。この場合、許可トークンは例えばプリンタの使用許可、ネットワークドライブへのアクセスの許否などに使用することができる。
【００５０】
図１８に示すように、ユーザ端末５１−ｋは、実施例１と同じ第１登録部１１１、第１認証部１１２に加え、許可トークン受信部５１３をさらに含む。認証サーバ５２は、実施例１と同じ第２登録部１２１、第２認証部１２２に加え、許可トークン送信部５２３をさらに含む。図１９に示すように、認証サーバ５２の許可トークン送信部５２３は、第２認証部１２２における認証が成功する度に許可トークンを生成し、許可トークンを認証相手であるユーザ端末５１−ｋに送信する（Ｓ５２３）。ユーザ端末５１−ｋの許可トークン受信部５１３は、許可トークンを受信する（Ｓ５１３）。
【００５１】
このように、本実施例の認証システム５によれば、サービス提供サーバ５３などで利用される許可トークンを、認証サーバ５２が発行することとしたため、実施例１の効果に加え、より柔軟に、様々なシステムに応用することができる。
【００５２】
上述の各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。その他、本発明の趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。
【００５３】
また、上述の構成をコンピュータによって実現する場合、各装置が有すべき機能の処理内容はプログラムによって記述される。そして、このプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。
【００５４】
この処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等どのようなものでもよい。
【００５５】
また、このプログラムの流通は、例えば、そのプログラムを記録したＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体を販売、譲渡、貸与等することによって行う。さらに、このプログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することにより、このプログラムを流通させる構成としてもよい。
【００５６】
このようなプログラムを実行するコンピュータは、例えば、まず、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、一旦、自己の記憶装置に格納する。そして、処理の実行時、このコンピュータは、自己の記録媒体に格納されたプログラムを読み取り、読み取ったプログラムに従った処理を実行する。また、このプログラムの別の実行形態として、コンピュータが可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することとしてもよく、さらに、このコンピュータにサーバコンピュータからプログラムが転送されるたびに、逐次、受け取ったプログラムに従った処理を実行することとしてもよい。また、サーバコンピュータから、このコンピュータへのプログラムの転送は行わず、その実行指示と結果取得のみによって処理機能を実現する、いわゆるＡＳＰ（Application Service Provider）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。
【００５７】
また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。
【図１】
2015138978.tif 000003
【図２】
2015138978.tif 000004
【図３】
2015138978.tif 000005
【図４】
2015138978.tif 000006
【図５】
2015138978.tif 000007
【図６】
2015138978.tif 000008
【図７】
2015138978.tif 000009
【図８】
2015138978.tif 000010
【図９】
2015138978.tif 000011
【図１０】
2015138978.tif 000012
【図１１】
2015138978.tif 000013
【図１２】
2015138978.tif 000014
【図１３】
2015138978.tif 000015
【図１４】
2015138978.tif 000016
【図１５】
2015138978.tif 000017
【図１６】
2015138978.tif 000018
【図１７】
2015138978.tif 000019
【図１８】
2015138978.tif 000020
【図１９】
2015138978.tif 000021