JP6182080B2 - 認証システム、プログラム - Google Patents

Description

本発明は、オンライン上でユーザ認証を実行する認証システム、プログラムに関する。

従来、インターネットやイントラネットにおけるネットワーク上のリソースに対するアクセス制御方法がいくつか提案されている。よく知られているのは、ＩＤとパスワードを用いるＢａｓｉｃ認証である（非特許文献１参照）。これ以外にも、アクセス元のＩＰアドレスによりアクセス制御を行う方法がある。他には、個人用証明書を使用した認証方法がある。個人用証明書を使用した認証方法としてよく知られているものにベリサイン（登録商標）社が提供している個人用電子証明書サービスがある（非特許文献２参照）。また、個人用証明書を使用した認証方法として、ＡｐａｃｈｅのＦａｋｅＢａｓｉｃ認証が知られている（非特許文献３参照）。

"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）型のサービスによって、上述の処理を実行する構成としてもよい。なお、本形態におけるプログラムには、電子計算機による処理の用に供する情報であってプログラムに準ずるもの（コンピュータに対する直接の指令ではないがコンピュータの処理を規定する性質を有するデータ等）を含むものとする。

また、この形態では、コンピュータ上で所定のプログラムを実行させることにより、本装置を構成することとしたが、これらの処理内容の少なくとも一部をハードウェア的に実現することとしてもよい。

Claims (5)

1. 複数のユーザ端末と、認証サーバと、認証局を含む認証システムであって、
   前記ユーザ端末は、
   個人情報を含まない公開鍵と、前記公開鍵に対応する秘密鍵とを生成する鍵生成部と、
   前記秘密鍵を記憶する秘密鍵記憶部と、
   前記公開鍵を登録情報として前記認証サーバに送信する登録情報送信部と、
   前記認証局から前記公開鍵に対応する証明書を受信する証明書受信部と、
   前記証明書を記憶する証明書記憶部と、
   認証開始時に前記証明書を前記認証サーバに送信する証明書送信部と、
   前記認証サーバから暗号文を受信する暗号文受信部と、
   前記秘密鍵を用いて前記暗号文を復号してセッション鍵を取得する暗号文復号部を含み、
   前記認証サーバは、
   前記登録情報として前記公開鍵を受信する登録情報受信部と、
   受信した前記公開鍵を証明書署名要求に含むべき個人情報の代用として、前記証明書署名要求を生成する証明書署名要求生成部と、
   前記証明書署名要求を前記認証局に送信する証明書署名要求送信部と、
   前記認証局から前記公開鍵に対応する前記証明書を受信する証明書受信部と、
   受信した前記公開鍵と前記公開鍵に対応する前記証明書の組を記憶する公開鍵−証明書記憶部と、
   前記ユーザ端末から送信された前記証明書を受信する証明書受信部と、
   前記ユーザ端末から送信された前記証明書に対応する前記公開鍵を前記証明書−公開鍵記憶部から取得する公開鍵取得部と、
   前記セッション鍵を生成するセッション鍵生成部と、
   前記ユーザ端末から送信された前記証明書に対応する前記公開鍵を用いて、前記セッション鍵を暗号化して前記暗号文を生成する暗号文生成部と、
   前記暗号文を送信する暗号文送信部を含む
   認証システム。
2. 請求項１に記載の認証システムであって、
   前記ユーザ端末からのアクセスに応じて前記認証サーバに認証クエリを送信するサービス提供サーバをさらに含み、
   前記認証サーバは、
   前記認証クエリを受信した場合にアクセスを実行した前記ユーザ端末との認証の結果である認証結果通知を前記サービス提供サーバに送信する認証結果通知部をさらに含む
   認証システム。
3. 請求項１に記載の認証システムであって、
   前記認証サーバは、
   認証が成功する度に許可トークンを生成し、前記許可トークンを認証相手である前記ユーザ端末に送信する許可トークン送信部をさらに含む
   認証システム。
4. コンピュータを、請求項１に記載の認証システムに含まれるユーザ端末として機能させるためのプログラム。
5. コンピュータを、請求項１に記載の認証システムに含まれる認証サーバとして機能させるためのプログラム。

Images