JP2007074164A - 認証システム、認証方法および認証プログラム - Google Patents

Abstract

【課題】通信当事者以外の第三者による認証情報の正当性保証を要することなく認証を行うことができ、認証に用いられる証明書等の認証情報が失効した場合、その失効情報を通信相手に確実に伝えることでき、さらには、通信当事者間で秘密情報を共有しないようにすることを課題とする。
【解決手段】アクセス者装置はサービス提供者装置に対して、サービス提供要求に含める認証子を認証する、あるいは、認証子を認証するために必要な情報を所持する問い合わせ先のアドレスの登録を行う（図１の（１）参照）。そして、アクセス者装置はサービス提供者装置に対してサービス提供要求を行う（図１の（３）参照）と、サービス提供者装置は、サービス提供要求に含まれるユーザＩＤに基づいて、問い合わせ先リストから認証子の認証依頼を行う問い合わせ先のアドレスを取得する（図１の（４）参照）。
【選択図】 図１

Description

この発明は、アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する認証システム、認証方法および認証プログラムに関する。

近年、インターネットの普及により、個人間において行われる情報の共有化が活発となっており、例えば、知り合いにのみ情報を共有したいといった場合のように、情報の流通を制御したいというニーズが高まっている。そのような場合には、アクセス者が何者であるかを認証し、そのアクセス者が所定の情報にアクセス可能か否かを検証した上で情報を開示する必要がある。

上記のような場合に、個人間で情報を共有化する際の認証方式として、公開鍵基盤（PKI：Public Key infrastructure）を用いた認証方式が提案されている。例えば、非特許文献１では、サービス提供者は、ドメインネームシステム（ＤＮＳ：Domain Name System）の構造に対応した公開鍵基盤を構成しておき、各利用者のメールアドレスを識別子とした公開鍵、秘密鍵を利用者に発行している。利用者の鍵は、所属するドメインのＫＳＵ（Keys Services Unit）とよばれる鍵管理サーバの秘密鍵により署名が行われており、各ドメインのＫＳＵの公開鍵は上位のＫＳＵの秘密鍵により署名されている。そして、サービス提供者は、利用者を認証する際に利用者の公開鍵を信頼できるルートから入手する必要があるが、サービス提供者と利用者が同一のトップレベルドメインに属していて、トップレベルドメインの公開鍵をあらかじめ取得している場合には、署名のチェーンをたどっていくことでドメインの階層を下りつつ最終的に利用者の公開鍵を取得し、信頼できるかどうかを検証することができる。

また、非特許文献２では、信頼関係にある個人間でグループを構成して互いの公開鍵を保持しておき、その公開鍵を用いて認証を行う方式も提案されている。この方式の場合、新たにグループに参入しようとする者は、そのグループに既に属しているメンバの一人を紹介者として自らの公開鍵に署名してもらい、そのメンバから署名を受けた自らの公開鍵を配布してもらうことでそのグループに新たに参入する。これにより、グループに属している他のメンバは、紹介者となったメンバからの紹介を受けて新たに参入したメンバを認証することができる。

"An user authentication infrastructure for extranet application"（Lopez，J．；Mana，A．；Ortega，J．J．；Security Technology，1999．Proceedings．IEEE 33rd Annual 1999 International Carnahan Conference on 5-7 Oct．1999 Pages(s):354-362） 情報処理学会研究報告 Vol.2003 No.064 pp33-38「安全で閉じたP2Pネットワークの構成方式の提案」

ところで、上記した従来の技術は、以下に説明するように、通信当事者間で情報の認証を行う上で問題がある。

すなわち、非特許文献１のような公開鍵基盤を用いる従来技術では、利用者間で秘密情報を共有することなく認証を行うことができるが、認証できる相手は同一のＣＡ（Certificate Authority：認証局）に属しているか、あるいは別のCAに属している場合には、ＣＡ同士が互いの証明書に署名を行っている必要がある。これでは、認証の正当性は信頼された第三者機関であるＣＡの正当性保証に依存する形になり、個人間の関係に応じて任意の相手を認証することはできず、サービス提供者が認証できる相手は限定されてしまうという問題がある。

また、非特許文献２のような紹介に基づいて認証に用いられる証明書の正当性保証する従来技術では、正当性の保証がＣＡのような特定の第三者機関に依存することはないが、あるメンバの公開鍵証明書に対応した秘密鍵が第三者に漏洩してしまい、秘密鍵を入手した者による成りすましの危険性が発生した場合には、公開鍵証明書のメンバ全員に対して証明書の破棄依頼を確実に周知して、新しい公開鍵証明書を利用してもらう必要がある。しかし、証明書の失効情報を一元的に管理する機関が存在しないので、失効情報や新しい公開鍵証明書を確実に周知する手段がないという問題点がある。

つまり、上記した従来技術は、個人ごとに情報を格納している任意の装置間で互いに認証を行う際には、第三者による認証情報の正当性保証を要し、認証に用いられる証明書等の認証情報が失効した場合、その失効情報を通信相手に確実に伝えることができないという問題である。

そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、通信当事者以外の第三者による認証情報の正当性保証を要することなく認証を行うことができ、認証に用いられる証明書等の認証情報が失効した場合、その失効情報を通信相手に確実に伝えることでき、さらには、通信当事者間で秘密情報を共有しないようにすることが可能な認証システム、認証方法および認証プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に係る発明は、アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する認証システムにおいて、前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶手段と、前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付手段と、前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ手段と、前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証手段と、を備えたことを特徴とする。

また、請求項２に係る発明は、上記の発明において、前記認証子は、所定の鍵を用いて生成されたデータであって、前記認証情報問い合わせ手段は、前記認証子の検証結果を問い合わせ、前記認証手段は、前記問い合わせ先からの応答である検証結果に基づいて、前記認証子の正当性を確認することを特徴とする。

また、請求項３に係る発明は、上記の発明において、前記認証子は、前記認証子は、所定の鍵を用いて生成されたデータであって、前記認証情報問い合わせ手段は、前記認証子を問い合わせ、前記認証手段は、前記問い合わせ先からの応答である認証子と、前記認証要求に含まれる認証子とが対応していることを条件に前記アクセス者を確認することを特徴とする。

また、請求項４に係る発明は、上記の発明において、前記認証子は、当該認証子生成用の鍵を用いて生成されたデータであって、前記認証情報問い合わせ手段は、前記認証子を検証するために必要な認証子確認用の鍵を問い合わせ、前記認証手段は、前記問い合わせ先からの応答結果である前記認証子確認用の鍵を用いて、前記認証子を検証し、当該検証結果に基づいて前記認証子の正当性を確認することを特徴とする。

また、請求項５に係る発明は、上記の発明において、前記認証要求受付手段は、前記データを検証するために必要な鍵をさらに受け付け、前記認証子は、当該認証子生成用の鍵を用いて生成されたデータであって、前記認証情報問い合わせ手段は、前記認証子を検証するための認証子確認用の鍵を検証するために必要なデータを問い合わせ、前記認証手段は、前記問い合わせ先からの応答結果である前記認証子確認用の鍵を検証するために必要なデータに基づいて、前記認証子確認用の鍵を正規のアクセス者のものであると認証した場合には、当該認証子確認用の鍵を用いて前記認証子を検証し、当該検証結果に基づいて前記認証子の正当性を確認することを特徴とする。

また、請求項６に係る発明は、上記の発明において、前記アクセス者が前記認証子生成用の鍵と前記認証子確認用の鍵とを複数管理し、当該アクセス者が前記問い合わせ先に応じて当該認証子生成用の鍵と当該認証子確認用の鍵とを選択する鍵選択手段をさらに備えたことを特徴とする。

また、請求項７に係る発明は、上記の発明において、前記問い合わせ先からの応答結果を受け付けた場合に、前記認証手段によって前回使用された鍵を用いて、当該応答結果の検証を行う検証手段をさらに備え、前記認証手段は、前記検証手段によって前記応答結果が正規のアクセス者のものであると検証された場合に、当該応答結果に基づいて前記認証子の正当性を確認することを特徴とする。

また、請求項８に係る発明は、上記の発明において、前記認証情報問い合わせ手段は、以後取得すべき問い合わせ先からの応答結果の検証に必要な情報をあらかじめ前記問い合わせ先のアドレスに対して問い合わせ、前記認証手段は、前記認証要求を受け付けた場合に、前記認証情報問い合わせ手段によって得られた問い合わせ応答を、前記問い合わせ先からあらかじめ取得していた情報に基づいて検証した上で、前記認証子の正当性を確認することを特徴とする。

アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する認証方法において、前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶工程と、前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付工程と、前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ工程と、前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証工程と、を備えたことを特徴とする。

アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する方法をコンピュータに実行させる認証プログラムにおいて、前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶手順と、前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付手順と、前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ手順と、前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証手順と、をコンピュータに実行させることを特徴とする。

請求項１、９および１０の発明によれば、この認証システムは、認証要求に関する問い合わせに応答する問い合わせ先のアドレスとアクセス者を識別するアクセス者識別子に一意に対応づけて記憶し、認証要求に含まれるアクセス者に対応した問い合わせ先のアドレスに対してアクセス者を識別するための認証子の正当性を確認するための情報（例えば、認証子の検証結果、認証子を検証するための公開鍵、認証子を検証するための公開鍵を検証するためのデータや認証子そのもの）を問い合わせて、認証子の正当性を確認するので、通信当事者（例えば、アクセス者とサービス提供者）以外の第三者による認証子を認証するための認証情報の正当性保証を要することなく、アクセス者自身が認証情報を管理することで失効情報を確実に通信相手に伝えることができ、また、問い合わせ先のアドレスを公開情報とすることで公開情報のみによって認証子の正当性の確認ができ、通信当事者間で秘密情報を共有しないようにすることが可能となる。

また、請求項２の発明によれば、この認証システムは、認証子（例えば、鍵付きハッシュ値や暗号化データ）の検証結果を問い合わせて、その検証結果に基づいて認証子の正当性を確認するので、例えば、アクセス者に対してサービスを提供するサービス提供者側で認証子の検証方法を意識せずに認証を行なうことができ、認証子生成および検証に用いる暗号方式が統一されていない端末間においても認証子の正当性を確認することが可能となる。

また、請求項３の発明によれば、この認証システムは、認証子を問い合わせて、問い合わせ応答である認証子と認証要求に含まれる認証子とを比較して認証子の正当性を確認するので、認証問合せ先（例えば、アクセス者装置自身）において認証子を一度生成したら問い合わせを受けるまでそれを保持しておくので、認証問合せ先において認証子の生成ないし検証の処理を実行する回数を一回で済ませることが可能となる。

また、請求項４の発明によれば、この認証システムは、認証子を検証するために必要な認証子確認用の鍵（例えば、秘密鍵で暗号されたデータを検証するために必要な公開鍵）を問い合わせて、その鍵を用いて暗号化データを検証し、その検証結果に基づいて認証子の正当性を確認するので、秘密情報を保持する際の安全性を高めることが可能となる。例えば、認証要求は秘密鍵を保持した耐タンパ性のあるアクセス者の装置で行い、認証応答は公開鍵を格納したアクセス者装置以外の装置（例えば、公開サーバ）で行うといったように、認証要求を生成する機能と認証問い合わせに応答する機能を分離して配置することにより実現できる。

また、請求項５の発明によれば、この認証システムは、認証子を検証するために必要な認証子確認用の鍵を含んだ認証要求を受け付け、この認証子確認用の鍵を検証するために必要なデータ（例えば、公開鍵のハッシュ値や公開鍵証明書）を問い合わせ、このデータに基づいて、この認証子確認用の鍵が正規のアクセス者のものであると検証された場合には、この認証子確認用の鍵を用いて認証子を検証し、その検証結果に基づいて認証子の正当性を確認するので、例えば、アクセス者から受け取った公開鍵をサービス提供者側で保持しておき、認証の度に公開鍵を問い合わせることなく、公開鍵のハッシュ値のみを問い合わせることで通信量を減らすことが可能となる。

また、請求項６の発明によれば、この認証システムは、認証子生成用の鍵（例えば、チャレンジデータを暗号化するための秘密鍵）と認証子確認用の鍵（例えば、暗号化されたチャレンジデータを復号化するための公開鍵）とを複数管理し、認証子生成用の鍵および認証子確認用の鍵からなる複数の鍵の対を用意して使い分けるので、例えば、アクセス者が固有の公開鍵を複数のサービス提供者装置に対して使用することにより、公開鍵を元にサービス提供者装置間でアクセス者の名寄せが行われて、匿名性が損なわれるのを防止することが可能となる。

また、請求項７の発明によれば、この認証システムは、問い合わせ先からの応答結果（公開鍵、公開鍵のハッシュ値や公開鍵証明書）を受け付けた場合に、前回の認証に用いた鍵で応答結果を検証した上で認証子の正当性を確認するので、例えば、鍵が更新された場合に、前回認証子の検証に使用された鍵を用いて更新された鍵を検証することができ、鍵の問い合わせを受けた悪意ある第三者が認証問い合わせ先に成りすまして不当な応答メッセージを返信したとしても、正規のユーザ以外は以前の鍵による署名を施した新たな鍵を生成して返信することができないので、不正を検出することが可能となる。

また、請求項８の発明によれば、この認証システムは、認証子の認証に必要な情報をあらかじめ認証問い合わせ先に問い合わせて、その情報に基づいて認証子の正当性を確認するので、例えば、まだ、認証子の認証を行っていない段階において、自発的に公開鍵やハッシュ値を問い合わせて管理することで、悪意ある第三者が認証問い合わせ先に成りすまして不当な応答メッセージを返信する手段を用意する前に、正規の公開鍵やハッシュ値を取得することが可能となる。

以下に添付図面を参照して、この発明に係る認証システム、認証方法および認証プログラムの実施例を詳細に説明する。なお、以下では、図１を用いて、本発明に係る認証システムの概要を最初に説明し、続いて、実施例１〜４を説明する。図１は、本発明に係る認証システムの概要を説明するための図である。

同図に示すように、この認証システムは、アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の認証を行うことを概要とするが、アクセス者を認証するための問い合わせ先のアドレスをあらかじめ取得しておいて、その問い合わせ先に対して認証に必要な情報を問い合わせる点に主たる特徴がある。

この主たる特徴について簡単に説明すると、まず、サービス提供者装置は、認証要求に関する問い合わせに応答する問い合わせ先のアドレスの登録をアクセス者装置から受け付けると（図１の（１）参照）、アクセス者（もしくはアクセス者装置）を一意に識別するためのユーザＩＤと問い合わせ先のアドレスとを対応させて記憶する問合わせ先リストを作成する（図１の（２）参照）。なお、この問い合わせ先は、アクセス者装置であってもよいし、アクセス者以外の第三者装置であってもよい。

また、サービス提供者装置は、アクセス者装置から認証子とユーザＩＤとを含んだサービス提供要求を受け付ける（図１の（３）参照）。ここで、認証子とは、アクセス者が正規のユーザであるか否かを検証するためのデータであり、例えば、所定のデータ（チャレンジデータ）をアクセス者の固有鍵（もしくはアクセス者に固有の秘密情報）と結合した一方性関数の入力として得られる鍵付ハッシュ値や、所定のデータをアクセス者の秘密鍵で暗号化して得られる署名データ（暗号化データ）など、所定の鍵を用いて生成されたデータがこれに該当する。

そして、サービス提供者装置は、サービス提供要求とともに受け付けたユーザＩＤに基づいて、問合せ先リストから問い合わせ先のアドレスを取得し（図１の（４）参照）、この問い合わせ先のアドレスに対して、サービス提供要求に含まれる認証子を認証するために必要な情報を問い合わせる（図１の（５）参照）。かかる問い合わせとしては、認証子と所定のデータとを問い合わせ先に送信して、問い合わせ先において所定のデータから改めて認証子を生成させ、これらの認証子が一致するか否かの検証結果を問い合わせる、認証子の正当性を確認するために必要な公開鍵を問い合わせる、認証子の正当性を確認するために必要な公開鍵を検証するためのデータ（例えば、公開鍵のハッシュ値や公開鍵証明書）を問い合わせる、あるいは、認証子そのものを問い合わせる等がある。

その後、サービス提供者装置は、かかる問い合わせ先から問い合わせ応答（検証結果、公開鍵、公開鍵を検証するためのデータや認証子）を受信すると（図１の（６）参照）、この問い合わせ応答に基づいて、サービス提供要求に含まれる認証子を検証し、その正当性を確認する（図１の（７）参照）。具体的には、認証子の検証結果を受信した場合には、かかる検証結果が「ＯＫ」であれば、認証子は正規のアクセス者によって生成されたものとして、その正当性を確認する。

また、公開鍵を受信した場合には、かかる鍵を用いてサービス提供要求に含まれる認証子（例えば、所定のデータを秘密鍵で暗号化したもの）を検証して、かかる検証結果が「ＯＫ」であれば（例えば、秘密鍵で暗号化されたデータを公開鍵で復号化して、所定のデータと復号化したデータが一致）、認証子は正規のアクセス者によって生成されたものとして、その正当性を確認する。

また、公開鍵を検証するためのデータ（公開鍵のハッシュ値や公開鍵証明書）を受信した場合には、このデータに基づいて公開鍵を検証し、正規のアクセス者のものであると検証された公開鍵を用いてサービス提供要求に含まれる認証子を検証し、かかる検証結果が「ＯＫ」であれば（例えば、秘密鍵で暗号化されたデータを公開鍵で復号化して、所定のデータと復号化したデータが一致）、認証子は正規のアクセス者によって生成されたものとして、その正当性を確認する。

さらに、認証子そのものを受信した場合には、かかる認証子がサービス提供要求に含まれる認証子と同様であれば、認証子は正規のアクセス者によって生成されたものとして、その正当性を確認する。そして、サービス提供装置は、認証子が正規のものである旨（正当性）を確認した場合には、アクセス者装置に対してサービス（例えば、スケジュール情報等）を提供する（図１の（８）参照）。

このように、図１に示した認証システムによれば、認証要求に関する問い合わせに応答する問い合わせ先のアドレスとアクセス者を識別するアクセス者識別子に一意に対応づけて記憶し、認証要求に含まれるアクセス者に対応した問い合わせ先のアドレスに対してアクセス者を識別するための認証子の正当性を確認するための情報（例えば、認証子の検証結果、認証子を検証するための公開鍵、認証子を検証するための公開鍵を検証するためのデータや認証子そのもの）を問い合わせて、認証子の正当性を確認するので、通信当事者（例えば、アクセス者とサービス提供者）以外の第三者による認証子を認証するための認証情報の正当性保証を要することなく、アクセス者自身が認証情報を管理することで失効情報を確実に通信相手に伝えることができ、また、問い合わせ先のアドレスを公開情報とすることで公開情報のみによって認証子の正当性の確認ができ、通信当事者間で秘密情報を共有しないようにすることが可能となる。

以下の実施例１では、典型的な実施形態として、アクセス者端末Ａとサービス提供者端末Ｂとで構成され、認証要求と認証問い合わせ応答とをアクセス者端末Ａで行う場合の認証システムの構成および処理の流れを説明し、最後に実施例１による効果を説明する。なお、アクセス者端末Ａ１００とサービス提供者端末Ｂ２００とは、互いにネットワーク（公衆電話網やインターネット、ＬＡＮやＷＡＮなどによって形成される通信網）を経由して、ＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて互いに通信できるものとする。

［認証システムを構成する各装置の構成（実施例１）］
まず最初に、図２を用いて、実施例１に係る認証システムのアクセス者端末Ａ１００およびサービス提供者端末Ｂ２００の構成を説明する。図２は、実施例１に係る認証システムの全体構成を示すシステム構成図である。

同図に示すように、アクセス者端末Ａ１００は、認証要求部１１０と、認証応答部１２０と、固有鍵記憶部１３０と、ネットワーク通信機能１４０とからなる。このうち、ネットワーク通信機能１４０は、サービス提供者端末Ｂ２００との間の通信を制御する手段である。

固有鍵記憶部１３０は、認証要求部１１０および認証応答部１２０における各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、具体的には、アクセス者に固有の鍵情報を記憶する。

認証要求部１１０および認証応答部１２０は、アクセス者端末Ａ１００を制御して各種処理を実行する制御手段であり、具体的には、認証要求部１１０は、サービス提供者端末Ｂ２００に対してリソース（情報）要求を送信する認証要求の生成を行い、または、リソースを取得する。また、認証応答部１２０は、サービス提供者端末Ｂ２００からの認証問い合わせを受け付けて認証結果を応答する。

また、サービス提供者端末２００Ｂは、図２に示すように、認証要求受付部２１０と、認証問合せ部２２０と、問合せ先リスト２３０と、アクセス制御部２４０と、リソース記憶部２５０と、ネットワーク通信機能２６０とからなる。このうち、ネットワーク通信機能２６０は、アクセス者端末Ａ１００との間の通信を制御する手段である。

問合せリスト２３０は、認証問合せ部２２０における各種処理に必要なデータおよびプログラムを格納する手段であり、具体的には、図３に例示するように、認証問合せ部２２０によって認証問合せを行う問い合わせ先のアドレス情報（例えば、ＵＲＬ、メールアドレスやＩＰアドレス）をアクセス者に一意に付されたユーザＩＤに対応付けて記憶する。

リソース記憶部２５０は、アクセス制御部２４０における各種処理に必要なデータおよびプログラムを格納する手段であり、具体的には、図４に例示するように、正規のユーザである認証されたアクセス者に対して提供するリソース（例えば、スケジュール情報）を記憶する。

認証要求受付部２１０、認証問合せ部２２０およびアクセス制御部２４０は、サービス提供者端末Ｂ２００を制御して各種処理を実行する制御手段であり、具体的には、認証要求受付部２１０は、アクセス者端末Ａ１００からのリソース要求や認証要求を受け付ける。また、認証要求受付部２１０は、リソース要求を受け付けると、アクセス者端末Ａ１００に対して認証子を生成させるための所定のデータ（チャレンジデータ：乱数）を生成して送信するが、このデータを内部的なメモリーに記憶して保持する。

また、認証問合せ部２２０は、アクセス者端末Ａ１００から受け付けた認証要求に含まれる認証子を、問合せ先リスト（図３参照）に記憶されている問い合わせ先のアドレスに対して問い合わせる。また、アクセス制御部２４０は、認証結果に基づいて、アクセス者端末Ａ１００によるリソース記憶部２５０に記憶されたリソース（情報）へのアクセスを制御する。

なお、アクセス者端末Ａ１００およびサービス提供者端末Ｂ２００は、汎用的なパーソナルコンピュータ上で、実施例１に係る認証システムを実行するプログラムを走行することによって実現できるが、既知のパーソナルコンピュータ、ワークステーション、携帯電話、ＰＨＳ端末、移動体通信端末またはＰＤＡなどの情報処理装置に、上記した各機能を搭載することによって実現することもできる。

［認証システムによる処理（実施例１）］
次に、図５を用いて、実施例１に係る認証システムの処理の流れを説明する。図５は、実施例１に係る認証システムの処理の流れを示すシーケンス図である。

同図に示すように、アクセス者端末装置Ａ１００は、スケジュール取得要求をサービス提供者端末Ｂ２００に送信する（ステップＳ１１０）。ここで、スケジュール取得要求には、アクセス者端末Ａ１００に対して一意に付されたユーザＩＤ（Ｕ１）が含まれる。この要求を受信して、サービス提供者端末Ｂ２００は、チャレンジデータＣ（例えば、サービス提供者が生成した乱数）を応答メッセージとしてアクセス者端末Ａ１００に対して送信する（ステップＳ１２０）。

応答メッセージを受信して、アクセス者端末Ａ１００の認証要求部１１０は、チャレンジデータＣから認証子の生成を行う（ステップＳ１３０）。ここで、図６を用いて、認証子の生成処理の流れを説明する。認証要求部１１０は、固有鍵記憶部１３０から読み出した鍵Ｋを用いて、チャレンジデータＣの鍵付きハッシュ値を計算、計算の結果得られたデータ（チャレンジデータＣの鍵付きハッシュ値）を認証子Ｔとする（ステップＳ６０１）。

認証子Ｔの生成を終えると、アクセス者端末Ａ１００の認証要求部１１０は、認証子Ｔをサービス提供者端末Ｂ２００に対して送信する（ステップＳ１４０）。この送信を受信して、サービス提供者端末Ｂ２００の認証要求受付部２１０は、ユーザＩＤに対応する問い合わせ先アドレス（ＵＲＬ）を問合せ先リスト２３０から取得する（ステップＳ１５０）。そして、認証問合せ部２２０は、取得した問い合わせ先のアドレスに対してチャレンジデータＣと認証子Ｔとを含んだ認証問合せを送信する（ステップＳ１６０）。

この問合せを受信したアクセス者端末Ａ１００の認証応答部１２０は、認証子の検証処理を行う（ステップＳ１７０）。ここで、図７を用いて、認証子検証処理の流れを説明する。まず、認証応答部１２０は、固有鍵記憶部１３０から読み出した鍵Ｋを用いて、チャレンジデータＣの鍵付きハッシュ値を求めてＴ’とする（ステップＳ７０１）。続いて、認証応答部１２０は、認証子ＴとＴ’とを比較して一致した場合には、検証結果を「ＯＫ」とし、一致しなかった場合には検証結果を「ＮＧ」とする（ステップＳ７０２）。

認証子の検証を終えると、アクセス者端末Ａ１００の認証応答部１２０は、サービス提供者端末Ｂ２００に対して検証結果を送信する（ステップＳ１８０）。この検証結果を受信して、サービス提供者端末Ｂ２００のアクセス制御部２４０は、検証結果が「ＯＫ」である場合には、リソース記憶部２５０からスケジュールデータを取得する（ステップＳ１９０）。そして、アクセス制御部２４０は、アクセス者端末Ａ１００に対してスケジュールデータを送信する（ステップＳ２００）。一方、検証結果が「ＮＧ」である場合には、アクセス制御部２４０は、リソース記憶部２５０からスケジュールデータを取得して、アクセス者端末Ａ１００に対してスケジュールデータを送信することはない。

［実施例１による効果］
上述してきたように、実施例１によれば、この認証システムは、認証要求に関する問い合わせに応答する問い合わせ先のアドレスとアクセス者を識別するアクセス者識別子に一意に対応づけて記憶し、認証要求に含まれるアクセス者に対応した問い合わせ先のアドレスに対してアクセス者を識別するための認証子の正当性を確認するための情報（例えば、認証子の検証結果、認証子を検証するための公開鍵、認証子を検証するための公開鍵を検証するためのデータや認証子そのもの）を問い合わせて、認証子の正当性を確認するので、通信当事者（例えば、アクセス者とサービス提供者）以外の第三者による認証子を認証するための認証情報の正当性保証を要することなく、アクセス者自身が認証情報を管理することで失効情報を確実に通信相手に伝えることができ、また、問い合わせ先のアドレスを公開情報とすることで公開情報のみによって認証子の正当性の確認ができ、通信当事者間で秘密情報を共有しないようにすることが可能となる。

また、実施例１によれば、この認証システムは、認証子（例えば、鍵付きハッシュ値や暗号化データ）の検証結果を問い合わせて、その検証結果に基づいて認証子の正当性を確認するので、例えば、アクセス者に対してサービスを提供するサービス提供者側で認証子の検証方法を意識せずに認証を行なうことができ、認証子生成および検証に用いる暗号方式が統一されていない端末間においても認証子の正当性を確認することが可能となる。

ところで、上記の実施例では、認証子の検証をアクセス者端末Ａにおいて行い、その検証結果をサービス提供者端末Ｂに対して送信する場合について説明したが、本発明はこれに限定されるものではなく、認証子を検証するための情報（例えば、公開鍵）をアクセス者端末Ａからサービス提供者端末Ｂに送信して、サービス提供者端末Ｂにおいて認証子の検証を行うようにしてもよい。そこで、以下の実施例２では、この場合の認証システムの構成および処理の流れを順に説明し、最後に実施例２による効果を説明する。なお、以下に説明するアクセス者端末Ａ１００’とサービス提供者端末Ｂ２００’とは、互いにネットワーク（公衆電話網やインターネット、ＬＡＮやＷＡＮなどによって形成される通信網）を経由して、ＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて互いに通信できるものとする。

［認証システムを構成する各装置の構成（実施例２）］
まず最初に、図８を用いて、実施例２に係る認証システムのアクセス者端末Ａ１００’およびサービス提供者端末Ｂ２００’の構成を説明する。図８は、実施例２に係る認証システムの全体構成を示すシステム構成図である。

同図に示すように、アクセス者端末Ａ１００’は、認証要求部１１０’と、認証応答部１２０’と、固有鍵記憶部１３０’と、ネットワーク通信機能１４０’とからなる。なお、認証要求部１１０’およびネットワーク通信機能１４０’は実施例１と同様であるので、説明を割愛する。

固有鍵記憶部１３０’は、認証要求部１１０’および認証応答部１２０’における各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、具体的には、アクセス者端末Ａに固有の公開鍵および秘密鍵を記憶する。

認証応答部１２０’は、アクセス者端末Ａ１００’を制御して各種処理を実行する制御手段であり、具体的には、サービス提供者端末Ｂから公開鍵の問合せを受信して、固有鍵記憶部１３０’から取得した公開鍵を応答する。

また、サービス提供者装置Ｂ２００’は、図８に示すように、認証要求受付部２１０’と、認証問合せ部２２０’と、問合せ先リスト２３０’と、アクセス制御部２４０’と、リソース記憶部２５０’と、ネットワーク通信機能２６０’とからなる。なお、認証要求受付部２１０’、問合せ先リスト２３０’、アクセス制御部２４０’、リソース記憶部２５０’およびネットワーク通信機能２６０’は実施例１と同様であるので、説明を割愛する。

認証問合せ部２２０’は、サービス提供者端末Ｂ２００’を制御して各種処理を実行する制御手段であり、具体的には、アクセス者端末Ａ１００’から受信した公開鍵を用いて認証子の認証を行う。

なお、アクセス者端末Ａ１００’およびサービス提供者端末Ｂ２００’は、汎用的なパーソナルコンピュータ上で、実施例１に係る認証システムを実行するプログラムを走行することによって実現できる。

［認証システムによる処理（実施例２）］
次に、図９を用いて、実施例２にかかる認証システムによる処理を説明する。図９は、実施例２に係る認証システムの処理の流れを示すシーケンス図である。

同図に示すように、アクセス者端末装置Ａ１００’は、スケジュール取得要求をサービス提供者端末Ｂ２００’に送信する（ステップＳ３１０）。ここで、スケジュール取得要求には、アクセス者端末Ａ１００に対して一意に付されたユーザＩＤ（Ｕ１）が含まれる。この要求を受信して、サービス提供者端末Ｂ２００’は、チャレンジデータＣ（例えば、サービス提供者が生成した乱数）を応答メッセージとしてアクセス者端末Ａ１００’に対して送信する（ステップＳ３２０）。

応答メッセージを受信して、アクセス者端末Ａ１００’の認証要求部１１０’は、チャレンジデータＣから認証子の生成を行う（ステップＳ３３０）。ここで、図１０を用いて、認証子の生成処理の流れを説明する。認証要求部１１０’は、チャレンジデータＣのハッシュ値を求め、得られたデータをＸとする（ステップＳ１００１）。そして、固有鍵記憶部１３０’から取得した秘密鍵を用いて、Ｘを暗号化したものを認証子Ｔとする（ステップＳ１００２）。

認証子Ｔの生成を終えると、アクセス者端末Ａ１００’の認証要求部１１０’は、認証子Ｔをサービス提供者端末Ｂ２００’に対して送信する（ステップＳ３４０）。この送信を受信して、サービス提供者端末Ｂ２００’の認証要求受付部２１０’は、ユーザＩＤに対応する問い合わせ先アドレス（ＵＲＬ）を問合せ先リスト２３０から取得する（ステップＳ３５０）。そして、認証問合せ部２２０’は、取得した問い合わせ先のアドレスに対して公開鍵の問合せを送信する（ステップＳ３６０）。

この問合せを受信したアクセス者端末Ａ１００’の認証応答部１２０’は、固有鍵記憶部１３０から公開鍵を取得する（ステップＳ３７０）。そして、認証応答部１２０’は、公開鍵をサービス提供者端末Ｂ２００’に対して送信する（ステップＳ３８０）。

公開鍵を受信して、サービス提供者端末Ｂ２００’の認証問合せ部２２０’は、認証子の検証を行う（ステップＳ３９０）。ここで、図１１を用いて、認証子の検証処理の流れを説明する。認証問合せ部２２０’は、公開鍵Ｐを用いて認証子Ｔを復号化して得られたデータをＣ’とする（ステップＳ１１０１）。そして、チャレンジデータＣのハッシュ値とＣ’が一致した場合には、検証結果を「ＯＫ」とし、一致しなかった場合には、検証結果を「ＮＧ」とする（ステップＳ１１０２）。

認証子の検証を終えると、サービス提供者端末Ｂ２００’のアクセス制御部２４０’は、検証結果が「ＯＫ」である場合には、リソース記憶部２５０’からスケジュールデータを取得する（ステップＳ４００）。そして、アクセス制御部２４０’は、アクセス者端末Ａ１００’に対してスケジュールデータを送信する（ステップＳ４１０）。一方、検証結果が「ＮＧ」である場合には、アクセス制御部２４０’は、リソース記憶部２５０’からスケジュールデータを取得して、アクセス者端末Ａ１００’に対してスケジュールデータを送信することはない。

［実施例２の効果］
上述してきたように、実施例２によれば、この認証システムは、認証子を検証するために必要な所定の鍵（例えば、秘密鍵で暗号されたデータを検証するために必要な公開鍵）を問い合わせて、その所定の鍵を用いて暗号化データを検証し、その検証結果に基づいて認証子の正当性を確認するので、秘密情報を保持する際の安全性を高めることが可能となる。例えば、認証要求は秘密鍵を保持した耐タンパ性のあるアクセス者の装置で行い、認証応答は公開鍵を格納したアクセス者装置以外の装置（例えば、公開サーバ）で行うといったように、認証要求を生成する機能と認証問い合わせに応答する機能を分離して配置することにより実現できる。

また、上記の実施例では、問い合わせ先から取得した公開鍵を用いてそのまま認証子の検証を行う場合について説明したが、本発明はこれに限定されるものではなく、問い合わせ先から取得した公開鍵の検証を行った上で、その公開鍵を用いて認証子の検証を行うようにしてもよい。そこで、以下の実施例３では、この場合の認証システムの構成および処理の流れを説明し、最後に実施例３による効果を説明する。なお、以下に説明するユーザＡ端末３００、情報取得サーバＡ４００および情報共有サーバＢ５００は、互いにネットワーク（公衆電話網やインターネット、ＬＡＮやＷＡＮなどによって形成される通信網）を経由して、ＨＴＴＰ（Hyper Text Transfer Protocol）等のプロトコルを用いて互いに通信できるものとする。

まず最初に、図１２を用いて、実施例３に係る認証システムのユーザＡ端末３００、情報取得サーバＡ４００および情報共有サーバＢ５００の構成について説明する。図１２は、実施例３に係る認証システムの全体構成を示すシステム構成図である。同図に示すように、ユーザＡ端末３００は、Ｗｅｂブラウザを備えたＰＣや携帯電話端末等である。

まず、情報取得サーバＡ４００は、ユーザＡ端末３００を代理して情報共有サーバＢ５００からリソースを取得し、ユーザＡ端末３００に提供するサーバであり、ログイン要求受付部４１１と、ユーザ情報記憶部４１２と、認証要求部４２１と、認証応答部４２２と、固有鍵記憶部４２３と、固有鍵更新部４２４と、スケジュール問合せ先記憶部４２５と、ネットワーク通信機能４３０とからなる。なお、ネットワーク通信機能については、上記の実施例を同様であるので説明を割愛する。

ユーザ情報記憶部４１２は、ログイン要求受付部４１１における各種処理に必要なデータおよびプログラムを格納する格納手段（記憶手段）であり、具体的には、図１３に例示するように、ユーザＡ端末３００のログイン判定に用いられるユーザ名と、そのユーザに一意に規定したパスワードを対応させて記憶して構成される。

固有鍵記憶部４２３は、認証要求部４２１および鍵応答部４２２における各種処理に必要なデータを格納する格納手段（記憶手段）であり、具体的には、ユーザに固有の公開鍵および秘密鍵を記憶して構成される。

スケジュール問合せ先記憶部４２５は、認証要求部における各種処理に必要なデータを格納する格納手段（記憶手段）であり、具体的には、図１４に例示するように、ユーザＩＤごとにスケジュール問い合わせ先（例えば、ＵＲＬ）を記憶して構成される。

ログイン要求受付部４１１、認証要求部４２１、認証応答部４２２および固有鍵更新部４２４は、情報取得サーバＡ４００を制御して各種処理を実行する制御手段であり、具体的には、ログイン要求受付部４１１は、ユーザＡ端末３００からのログイン要求を受け付ける。また、認証要求部４２１は、リソースの要求および取得や、情報共有サーバＢ５００に対して送信する認証要求の生成を行う。また、認証応答部４２２は、情報共有サーバＢ５００からの公開鍵問合せを受信して公開鍵を応答する。また、固有鍵更新部４２４は、公開鍵および秘密鍵の対を作成して固有鍵記憶部４２３に登録する。

次に、情報共有サーバＢ５００は、認証判定部５１１と、相手鍵更新部５１２と、相手情報記憶部５１３と、アクセス制御部５２１と、リソース記憶部５２２と、ネットワーク通信機能５３０とからなる。なお、アクセス制御部５２１およびネットワーク通信機能５３０については、上記の実施例と同様であるので説明を割愛する。

相手情報記憶部５１３は、認証判定部５１１および相手鍵更新部５１２における各種処理に必要なデータを格納する格納手段（記憶手段）であり、具体的には、図１５に例示するように、公開鍵の問い合わせ先として、ユーザＩＤごとに鍵問合せ先（例えば、ＵＲＬ）および取得した公開鍵のファイルを記憶して構成される。

リソース記憶部５２２は、アクセス制御部５２１における各種処理に必要なデータを格納する格納手段（記憶手段）であり、具体的には、図１６に例示するように、情報共有サーバＢ５００の保有者の情報（例えば、スケジュール情報）を記憶して構成される。

認証判定部５１１および相手鍵更新部５１２は、情報共有サーバＢ５００を制御して各種処理を実行する制御手段であり、具体的には、認証判定部５１１は、ユーザＡ端末３００からリソース要求や認証要求を受け付けて認証判定を行う。また、相手鍵更新部５１２は、リソース要求等を行う通信相手の公開鍵を取得する。

なお、情報取得サーバＡ４００および情報共有サーバＢ５００は、汎用的なパーソナルコンピュータ上で、実施例１に係る認証システムを実行するプログラムを走行することによって実現できる。

［認証システムによる処理（実施例３）］
続いて、図１７を用いて、実施例３に係る認証システムの処理の流れを説明する。図１７は、実施例３に係る認証システムの処理の流れを説明するシーケンス図である。

同図に示すように、ユーザＡ端末３００は、情報取得サーバＡ４００に対してアクセス要求を送信する（ステップＳ５１０）。この要求を受信して、情報取得サーバＡ４００は、ユーザＡ端末３００に対してログインページを送信して、ユーザ名およびパスワードの入力を促す（ステップＳ５２０）。ログインページを受信して、ユーザＡ端末３００は、例えば、図１８に例示するような、ログインページにユーザ名（Ｕ１）およびパスワードを入力して送信ボタンをクリックし、情報取得サーバＡ４００にユーザ認証要求を送信する（ステップＳ５３０）。

この要求を受け付けた情報取得サーバＡ４００のログイン要求受付部４１１は、ユーザ認証を行う（ステップＳ５４０）。まず、ログイン要求受付部は、ユーザ情報記憶部４１２からユーザ名（Ｕ１）に対応するパスワードを取得し、認証要求に含まれるパスワードと比較する。その結果、両パスワードが一致する場合には認証成功とみなし、ユーザＡ端末３００に対して、例えば、図１９に例示するようなスケジュール表示ページを送信する（ステップＳ５５０）。

ところで、ユーザＡ端末３００のユーザは、必要に応じて新たに公開鍵および秘密鍵の対を作成することができる。その場合には、ユーザＡ端末３００のユーザは、情報取得サーバＡ４００に対して鍵更新要求を送信する（ステップＳ５６０）。この要求を受け付けた情報取得サーバＡ４００は、鍵更新処理を実行する（ステップＳ５７０）。

ここで、図２０を用いて、鍵更新処理の流れを説明する。固有鍵更新部４２４は、公開鍵および秘密鍵の対を生成し、それぞれＰｎ、Ｓｎとする（ステップＳ２００１）。次に、固有鍵記憶部４２３から秘密鍵Ｓを取得し、Ｐｎに対して署名処理を行う（ステップＳ２００２）。そして、固有鍵記憶部４２３に記憶されている公開鍵ＰをＰｎで、秘密鍵ＳをＳｎでそれぞれ置き換える（ステップＳ２００３）。鍵更新処理を終えると、情報取得サーバＡ４００は、更新が終了した旨をユーザＡ端末３００に対して通知する。なお、鍵更新の手順は必須の手順ではなく、更新の必要がない場合にはステップＳ５６０〜Ｓ５８０を省略するものとする。

スケジュール表示ページの応答あるいは鍵更新処理の通知を受けて、ユーザＡ端末３００は、スケジュールの取得を希望するユーザ名（Ｕ２）を指定して、情報取得サーバＡ４００に該当ユーザ（Ｕ２）のスケジュール取得を要求する（ステップＳ５９０）。この要求を受けて、情報取得サーバＡ４００認証要求部４２１は、ユーザ名（Ｕ２）に対応したスケジュール問い合わせ先をスケジュール問い合わせ先記憶部１２５から取得する（ステップＳ６００）。そして、認証要求部４２１は、情報共有サーバＢ５００に対して、ユーザ名（Ｕ２）に対応したスケジュール問い合わせ先にスケジュール取得要求を送信する（ステップＳ６１０）。なお、この要求には、要求者の識別子としてユーザ名（Ｕ１）が含まれる。

このスケジュール取得要求を受け付けた情報共有サーバＢ５００の認証判定部５１１は、情報取得サーバＡ４００に対してチャレンジデータＣ（例えば、乱数）を送信する（ステップＳ６２０）。チャレンジデータＣの送信を受けた情報取得サーバＡ４００の認証要求部４２１は、チャレンジデータＣに基づいて認証子生成処理を実行する（ステップＳ６３０）。

ここで、図２１を用いて、認証子生成処理の流れを説明する。まず。認証要求部４２１は、チャレンジデータＣのハッシュ値を求めて、得られたデータをＸとする（ステップＳ２１０１）。そして、固有鍵記憶部４２３に記憶された秘密鍵Ｓを取得して、秘密鍵Ｓを用いてデータＸを暗号化したものを認証子Ｔとする（ステップＳ２１０２）。認証子Ｔの生成を終えると、情報取得サーバＡ４００は、認証子Ｔを情報共有サーバＢ５００に対して送信する（ステップＳ６４０）。

この送信を受けて、情報共有サーバＢ５００の認証判定部５１１は、ステップＳ６１０で取得したユーザＩＤ（Ｕ１）に対応した鍵問合せ先アドレス（ＵＲＬ）を、相手情報記憶部５１３から取得し、このアドレスに対して鍵問い合わせ要求を送信する（ステップＳ６５０）。この要求を受けて、情報取得サーバＡ４００の鍵応答部４２２は、固有鍵記憶部４２３から公開鍵Ｐ’を取得し、情報共有サーバＢ５００に対して送信する（ステップＳ６６０）。

公開鍵Ｐ’を受信した情報共有サーバＢ５００の相手鍵更新部５１２は、公開鍵Ｐ’の検証と、相手情報記憶部５１３に記憶されている公開鍵ファイルの更新を行う（ステップＳ６７０）。ここで、図２２を用いて、公開鍵Ｐ’の検証処理の流れを説明する。まず、相手鍵更新部５１２は、相手情報記憶部５１３からユーザＩＤ（Ｕ１）に対応した公開鍵を取得してＰ’’とする（ステップＳ２２０１）。次に、公開鍵Ｐ’とＰ’’とを比較して検証を行う（ステップＳ２２０２）。公開鍵Ｐ’とＰ’’とが一致した場合には、公開鍵Ｐ’の検証結果を「ＯＫ」とし、鍵の更新は行わない。一方、公開鍵Ｐ’とＰ’’を比較して一致しなかった場合には、Ｐ’に付与された署名データをＰ’’で検証する（ステップＳ２２０３）。そして、検証が成功した場合には、公開鍵Ｐ’の検証結果を「ＯＫ」とし、相手情報記憶部５１３の中のユーザＩＤ（Ｕ１）に対応した公開鍵ファイルをＰ’に置き換える。一方、検証が失敗した場合には、検証結果を［ＮＧ］とし、鍵の更新は行わない。

公開鍵Ｐ’の検証結果が「ＯＫ」であった場合には、情報共有サーバＢ５００の認証判定部５１１は、認証子Ｔの検証を行う（ステップＳ６８０）。ここで、図２３を用いて、認証子Ｔの検証処理の流れを説明する。まず、認証判定部５１１は、相手情報記憶部５１３からユーザＩＤ（Ｕ１）に対応した公開鍵Ｐ’を取得し、その鍵Ｐ’を用いて認証子Ｔを複合化したデータをＣ’とする（ステップＳ２３０１）。そして、チャレンジデータＣとＣ’とを比較して、一致した場合には検証結果を「ＯＫ」とし、一致しなかった場合には検証結果を「ＮＧ」とする（ステップＳ２３０２）。なお、公開鍵Ｐ’の検証結果が「ＮＧ」であった場合には、情報共有サーバＢ５００の認証判定部５１１は、認証子Ｔの検証を行わない。

認証子Ｔの検証結果が「ＯＫ」であった場合には、情報共有サーバＢ５００のアクセス制御部５２１は、ユーザＡ端末３００によって取得希望されているユーザ名（Ｕ２）に対応したスケジュールデータをリソース記憶部５２２から取得する（ステップＳ６９０）。そして、アクセス制御部５２１は、情報取得サーバＡ４００に対してこのスケジュールデータを送信する（ステップＳ７００）。この送信を受けたユーザＡ端末３００の画面には、例えば、図２４に例示するようなスケジュール取得画面が表示される（ステップＳ７１０）。なお、認証子Ｔの証結果が「ＮＧ」であった場合には、情報共有サーバＢ５００のアクセス制御部５２１は、ユーザＡ端末３００によって取得希望されているユーザ名（Ｕ２）に対応したスケジュールデータをリソース記憶部５２２から取得しない。

ところで、上記の実施例では、公開鍵および秘密鍵の対を記憶しておいて使用する場合について説明したが、本発明はこれに限定されるものでなく、公開鍵および秘密鍵の対を複数記憶して使い分けるようにしてもよい。そこで、以下では、図２５を用いて、この場合の認証システムの処理の流れについて説明する。なお、ステップＳ８１０〜Ｓ８６０、ステップＳ９００〜Ｓ９２０およびステップＳ９８０〜Ｓ１０２０については、上記の実施例と同様であるので説明を割愛する。図２５は、実施例３に係る鍵の対を複数使用する場合の認証システムの処理の流れを示すシーケンス図である。

同図に示すように、ユーザＡ端末３００’から鍵更新要求を受け付けると、情報取得サーバＡ４００’は、鍵更新処理を実行する（ステップＳ８７０）。まず、生成した鍵の対に一意の識別子を付与する。また、固有鍵記憶部４２３’に新たな鍵を上書きする変わりに鍵の対を追加していく。そして、鍵の更新が終了した旨をユーザＡ端末３００’に対して送信する。

この送信を受けて、ユーザＡ端末３００’は、使用する公開鍵の識別子（例えば、ｉ）を指定した上で、スケジュールの取得を要求する（ステップＳ８９０）。また、ステップＳ９３０においては、ステップ８９０において指定された識別子（例えば、ｉ）に対応する鍵を用いて認証子の生成を行い、ステップＳ９４０においては、鍵の識別子（例えば、ｉ）も通知する。

また、ステップＳ９５０においては、要求する公開鍵を指定するために識別子（例えば、ｉ）を送信し、さらに情報共有サーバＡ４００’が相手情報記憶部５１３に記憶している公開鍵の識別子（例えば、ｊ）も送信する。ステップＳ９６０においては、ｉとｊが一致した場合には固有鍵記憶部４２３からｉに対応した公開鍵Ｐｉを取得し、ｉとｊが異なる場合にはｊに対応する公開鍵Ｐｊに対応する秘密鍵Ｓｊを固有鍵記憶部４２３’から取得し、ＰｉにＳｊで署名を行った上でＰｉを取得する。ステップＳ９７０においては、ステップＳ９６０で取得した公開鍵Ｐｉを応答する。

［実施例３の効果］
上述してきたように、実施例３によれば、この認証システムは、認証子を検証するために必要な認証子確認用の鍵（例えば、秘密鍵で暗号されたデータを検証するために必要な公開鍵）を問い合わせて、その鍵を用いて暗号化データを検証し、その検証結果に基づいて認証子の正当性を確認するので、秘密情報を保持する際の安全性を高めることが可能となる。例えば、認証要求は秘密鍵を保持した耐タンパ性のあるアクセス者の装置で行い、認証応答は公開鍵を格納したアクセス者装置以外の装置（例えば、公開サーバ）で行うといったように、認証要求を生成する機能と認証問い合わせに応答する機能を分離して配置することにより実現できる。

また、実施例３によれば、この認証システムは、問い合わせ先からの応答結果（公開鍵、公開鍵のハッシュ値や公開鍵証明書）を受け付けた場合に、前回の認証に用いた鍵で応答結果を検証した上で認証子の正当性を確認するので、例えば、鍵が更新された場合に、前回認証子の検証に使用された鍵を用いて更新された鍵を検証することができ、鍵の問い合わせを受けた悪意ある第三者が認証問い合わせ先に成りすまして不当な応答メッセージを返信したとしても、正規のユーザ以外は以前の鍵による署名を施した新たな鍵を生成して返信することができないので、不正を検出することが可能となる。

また、実施例３によれば、この認証システムは、この認証システムは、認証子生成用の鍵（例えば、チャレンジデータを暗号化するための秘密鍵）と認証子確認用の鍵（例えば、暗号化されたチャレンジデータを複合化するための公開鍵）とを複数管理し、認証子生成用の鍵および認証子確認用の鍵からなる複数の鍵の対を用意して使い分けるので、例えば、アクセス者が固有の公開鍵を複数のサービス提供者装置に対して使用することにより、公開鍵を元にサービス提供者装置間でアクセス者の名寄せが行われて、匿名性が損なわれるのを防止することが可能となる。

さて、これまで実施例１〜３に係る認証システムについて説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では実施例４として、種々の異なる実施例を（１）〜（５）に区分けして説明する。

（１）認証子自体の問い合わせ
上記の実施例では、認証問合せ先から認証子の検証結果や認証子の正当性を確認するために必要な情報を取得して認証子の正当性を確認する場合について説明したが、本発明はこれに限定されるものではなく、認証問合せ先から認証子そのものを取得して、認証子の正当性を確認するようにしてもよい。

これにより、認証子を問い合わせて、問い合わせ応答である認証子と認証要求に含まれる認証子とを比較して認証子の正当性を確認するので、認証問合せ先（例えば、アクセス者装置自身）において認証子を一度生成したら問い合わせを受けるまでそれを保持しておくので、認証問合せ先において認証子の生成ないし検証の処理を実行する回数を一回で済ませることが可能となる。

（２）認証子を検証するために必要な認証子確認用の鍵を検証するためのデータを問い合わせ
上記の実施例では、認証子を検証するために必要な認証子確認用の鍵を問い合わせて、この鍵を用いて認証子を検証する場合について説明したが、本発明はこれに限定されるものではなく、あらかじめ認証子を検証するために必要な認証子確認用の鍵を受け付けて、この認証子確認用の鍵を検証するために必要なデータ（例えば、公開鍵のハッシュ値や公開鍵証明書）を問い合わせて、このデータに基づいて認証子確認用の鍵を検証した上で、この鍵を用いて認証子を検証するようにしてもよい。

これにより、この認証システムは、認証子を検証するために必要な認証子確認用の鍵を含んだ認証要求を受け付け、この認証子確認用の鍵を検証するために必要なデータ（例えば、公開鍵のハッシュ値や公開鍵証明書）を問い合わせ、このデータに基づいて、この認証子確認用の鍵が正規のアクセス者のものであると検証された場合には、この認証子確認用の鍵を用いて認証子を検証し、その検証結果に基づいて認証子の正当性を確認するので、例えば、アクセス者から受け取った公開鍵をサービス提供者側で保持しておき、認証の度に公開鍵を問い合わせることなく、公開鍵のハッシュ値のみを問い合わせることで通信量を減らすことが可能となる。

（３）認証子の正当性を確認するために必要な情報を予め取得
上記の実施例では、前回認証子の検証に用いられた鍵を用いて、新たに認証問合せ先から受け付けた公開鍵を認証する場合について説明したが、本発明はこれに限定されるものではなく、まだ認証子の検証を行っていない段階においては、サービス提供者がユーザからあらかじめ認証子の検証に必要な情報（例えば、公開鍵や公開鍵のハッシュ値）を取得するようにしてもよい。

これにより、この認証システムは、認証子の認証に必要な情報をあらかじめ認証問い合わせ先に問い合わせて、その情報に基づいて認証子の正当性を確認するので、例えば、まだ、認証子の認証を行っていない段階において、自発的に公開鍵やハッシュ値を問い合わせて管理することで、悪意ある第三者が認証問い合わせ先に成りすまして不当な応答メッセージを返信する手段を用意する前に、正規の公開鍵やハッシュ値を取得することが可能となる。

（４）所定の鍵で暗号化したデータを解読させることでアクセス者（もしくはアクセス者装置）を検証
上記の実施例では、サービス提供要求（例えば、スケジュール取得要求）を受けたサービス提供者装置がアクセス者（もしくはアクセス者装置）に対して所定のデータ（例えば、チャレンジデータ）を送信して認証子を生成させ、その認証子の検証結果に基づいてアクセス者（もしくはアクセス者装置）を認証する場合について説明したが、本発明はこれに限定されるものではなく、サービス提供要求を受けたサービス提供者装置が所定の鍵（例えば、公開鍵）を用いて生成した所定の暗号化データをアクセス者（もしくはアクセス者装置）に送信して、アクセス者（もしくはアクセス者装置）がその認証子を解読（例えば、秘密鍵を用いて復号）できるか否かによってアクセス者を認証するようにしてもよい。そこで、以下では、図２６を用いて、この場合の認証システムの処理の流れについて説明する。図２６は、実施例４に係る認証システムの処理の流れを示すシーケンス図である。

同図に示すように、問合せアドレス登録（同図の（１）参照）から問合せ先取得（同図の（２）参照）までの流れは、上記の実施例と同様であるので説明を割愛する。また、サービス者提供装置は、アクセス者（もしくはアクセス者装置）からユーザＩＤを含んだサービス提供要求を受け付ける（同図の（３）参照）。そして、サービス提供者装置は、アクセス者（もしくはアクセス者装置）からサービス提供要求とともに受け付けたユーザＩＤに基づいて、問合せ先リストから問い合わせ先のアドレスを取得し（同図の（４）参照）、この問い合わせ先のアドレスに対して、所定の暗号化データを生成するために必要な情報を問い合わせる（同図の（５）参照）。かかる問い合わせとしては、所定の暗号化データを生成するための公開鍵などがこれに該当する。

その後、サービス提供者装置は、かかる問い合わせ先から問い合わせ応答（公開鍵）を受信すると（図２６の（６））参照）、この問い合わせ応答に基づいて生成した暗号化データをアクセス者（もしくはアクセス者装置）に対して送信する（同図の（７）参照）。この暗号化データの送信を受けて、アクセス者（もしくはアクセス者装置）は、暗号化データの復号を行う（同図の（８）参照）。具体的には、アクセス者（もしくはアクセス者装置）は、自己が保持する固有の秘密鍵を用いて、サービス提供者装置によって公開鍵で暗号化された暗号化データを復号する。そして、アクセス者（もしくはアクセス者装置）は、この復号化データをサービス提供者装置に対して送信する（同図の（９）参照）。

この復号化データの送信を受けて、サービス提供者装置は復号化データの検証を行う（同図の（１０）参照）。具体的には、サービス提供者が公開鍵を用いて暗号化する前の所定のデータとアクセス者装置から受け付けた復号化データが同様のものであるか否かの検証を行い、同様であれば、復号化データの正当性を確認し、アクセス者（もしくはアクセス者装置）を認証する。そして、アクセス者装置を認証した場合には、サービス者提供者装置は、アクセス者（もしくはアクセス者装置）に対して要求されたサービス（リソース）を開示する（同図の（１１）参照）。

このように、この認証システムによれば、公開鍵を用いて生成した認証子をアクセス者（もしくはアクセス者装置）に解読させることにより、アクセス者を正規のものであるか否かを検証（正当性を確認）することができ、アクセス者（もしくはアクセス者装置）検証のバリエーションに幅を持たせることが可能となる。

（５）装置構成
図２または８に示した認証システムにおける各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、図２のアクセス者端末Ａ１００における認証要求部１１０と認証応答部１２０とを分散して固有鍵記憶部１３０を端末間で共有させる、あるいは、図８のアクセス者端末Ａ１００’における認証要求部１１０’と認証応答部１２０’とを分散して固有鍵記憶部１３０を端末間で分散させるなど、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

以上のように、本発明に係る認証システム、認証方法および認証プログラムは、アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の認証を行うに有用であり、特に、通信当事者以外の第三者による認証情報の正当性保証を要することなく認証を行うことができ、認証に用いられる証明書等の認証情報が失効した場合、その失効情報を通信相手に確実に伝えることでき、さらには、通信当事者間で秘密情報を共有しないようにすることに適する。

本発明に係る認証システムの概要を説明するための図である。 実施例１に係る認証システムの全体構成を示すシステム構成図である。 実施例１に係る問合せ先リストの構成例を示す図である。 実施例１に係るリソース記憶部の構成例を示す図である。 実施例１に係る認証システムの処理の流れを示すシーケンス図である。 実施例１に係る認証子生成処理の流れを示すフローチャートである。 実施例１に係る認証子検証処理の流れを示すフローチャートである。 実施例２に係る認証システムの全体構成を示すシステム構成図である。 実施例２に係る認証システムの処理の流れを示すシーケンス図である。 実施例２に係る認証子生成処理の流れを示すフローチャートである。 実施例２に係る認証子検証処理の流れを示すフローチャートである。 実施例３に係る認証システムの全体構成を示すシステム構成図である。 実施例３に係るユーザ情報記憶部の構成例を示す図である。 実施例３に係るスケジュール問合せ先記憶部の構成例を示す図である。 実施例３に係る相手情報記憶部の構成例を示す図である。 実施例３に係るリソース記憶部の構成例を示す図である。 実施例３に係る認証システムの処理の流れを示すシーケンス図である。 実施例３に係るユーザ認証画面の構成例を示す図である。 実施例３に係るスケジュール表示画面およびスケジュール取得要求画面の構成例を示す図である。 実施例３に係る鍵更新処理の流れを示すフローチャートである。 実施例３に係る認証子生成処理の流れを示すフローチャートである。 実施例３に係る鍵検証および更新処理の流れを示すフローチャートである。 実施例３に係る認証子検証処理の流れを示すフローチャートである。 実施例３に係るスケジュール取得画面の構成例を示す図である。 実施例３に係る鍵の対を複数使用する場合の認証システムの処理の流れを示すシーケンス図である。 実施例４に係る認証システムの処理の流れを示すシーケンス図である。

符号の説明

１００ アクセス者端末Ａ
１１０ 認証要求部
１２０ 認証応答部
１３０ 固有鍵記憶部
１４０ ネットワーク通信機能
２００ サービス提供者端末Ｂ
２１０ 認証要求受付部
２２０ 認証問合せ部
２３０ 問合せ先リスト
２４０ アクセス制御部
２５０ リソース記憶部
２６０ ネットワーク通信機能
１００’ アクセス者端末Ａ
１１０’ 認証要求部
１２０’ 認証応答部
１３０’ 固有鍵記憶部
１４０’ ネットワーク通信機能
２００’ サービス提供者端末Ｂ
２１０’ 認証要求受付部
２２０’ 認証問合せ部
２３０’ 問合せ先リスト
２４０’ アクセス制御部
２５０’ リソース記憶部
２６０’ ネットワーク通信機能
３００ ユーザＡ端末
４００ 情報取得サーバＡ
４１０ ユーザログイン機能
４１１ ログイン要求受付部
４１２ ユーザ情報記憶部
４２０ サーバ間認証機能
４２１ 認証要求部
４２２ 鍵応答部
４２３ 固有鍵記憶部
４２４ 固有鍵更新部
４２５ スケジュール問合せ先記憶部
４３０ ネットワーク通信機能
５００ 情報共有サーバＢ
５１０ 認証機能
５１１ 認証判定部
５１２ 相手鍵更新部
５１３ 相手情報記憶部
５２０ リソース共有機能
５２１ アクセス制御部
５２２ リソース記憶部
５３０ ネットワーク通信機能

Claims (10)

1. アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する認証システムにおいて、
   前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶手段と、
   前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付手段と、
   前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ手段と、
   前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証手段と、
   を備えたことを特徴とする認証システム。
2. 前記認証子は、所定の鍵を用いて生成されたデータであって、
   前記認証情報問い合わせ手段は、前記認証子の検証結果を問い合わせ、
   前記認証手段は、前記問い合わせ先からの応答である検証結果に基づいて、前記認証子の正当性を確認することを特徴とする請求項１に記載の認証システム。
3. 前記認証子は、所定の鍵を用いて生成されたデータであって、
   前記認証情報問い合わせ手段は、前記認証子を問い合わせ、
   前記認証手段は、前記問い合わせ先からの応答である認証子と、前記認証要求に含まれる認証子とが対応していることを条件に前記アクセス者を確認することを特徴とする請求項１に記載の認証システム。
4. 前記認証子は、当該認証子生成用の鍵を用いて生成されたデータであって、
   前記認証情報問い合わせ手段は、前記認証子を検証するために必要な認証子確認用の鍵を問い合わせ、
   前記認証手段は、前記問い合わせ先からの応答結果である前記認証子確認用の鍵を用いて、前記認証子を検証し、当該検証結果に基づいて前記認証子の正当性を確認することを特徴とする請求項１に記載の認証システム。
5. 前記認証要求受付手段は、前記データを検証するために必要な鍵をさらに受け付け、
   前記認証子は、当該認証子生成用の鍵を用いて生成されたデータであって、
   前記認証情報問い合わせ手段は、前記認証子を検証するための認証子確認用の鍵を検証するために必要なデータを問い合わせ、
   前記認証手段は、前記問い合わせ先からの応答結果である前記認証子確認用の鍵を検証するために必要なデータに基づいて、前記認証子確認用の鍵を正規のアクセス者のものであると認証した場合には、当該認証子確認用の鍵を用いて前記認証子を検証し、当該検証結果に基づいて前記認証子の正当性を確認することを特徴とする請求項１に記載の認証システム。
6. 前記アクセス者が前記認証子生成用の鍵と前記認証子確認用の鍵とを複数管理し、当該アクセス者が前記問い合わせ先に応じて当該認証子生成用の鍵と当該認証子確認用の鍵とを選択する鍵選択手段をさらに備えたことを特徴とする請求項４または５に記載の認証システム。
7. 前記問い合わせ先からの応答結果を受け付けた場合に、前記認証手段によって前回使用された鍵を用いて、当該応答結果の検証を行う検証手段をさらに備え、
   前記認証手段は、前記検証手段によって前記応答結果が正規のアクセス者のものであると検証された場合に、当該応答結果に基づいて前記認証子の正当性を確認することを特徴とする請求項４、５または６に記載の認証システム。
8. 前記認証情報問い合わせ手段は、以後取得すべき問い合わせ先からの応答結果の検証に必要な情報をあらかじめ前記問い合わせ先のアドレスに対して問い合わせ、
   前記認証手段は、前記認証要求を受け付けた場合に、前記認証情報問い合わせ手段によって得られた問い合わせ応答を、前記問い合わせ先からあらかじめ取得していた情報に基づいて検証した上で、前記認証子の正当性を確認することを特徴とする請求項７に記載の認証システム。
9. アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する認証方法において、
   前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶工程と、
   前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付工程と、
   前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ工程と、
   前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証工程と、
   を備えたことを特徴とする認証方法。
10. アクセス者を認証するための認証子を含む認証要求を受け付けて当該認証子の正当性を確認する方法をコンピュータに実行させる認証プログラムにおいて、
    前記認証要求に関する問い合わせに応答する問い合わせ先のアドレスを、前記アクセス者を一意に識別するアクセス者識別子に対応付けて記憶するアドレス記憶手順と、
    前記アクセス者識別子ならびに前記認証要求を受け付ける認証要求受付手順と、
    前記認証要求に含まれるアクセス者識別子に対応する問い合わせ先のアドレスを前記アドレス記憶手段から取得し、前記認証子の正当性を確認するのに必要な情報を当該問い合わせ先のアドレスに対して問い合わせる認証情報問い合わせ手順と、
    前記問い合わせ先からの応答に基づいて、前記認証子の正当性を確認する認証手順と、
    をコンピュータに実行させることを特徴とする認証プログラム。

Images