(57)【要約】【課題】  リポジトリが新規追加されたときにも、認証サーバが属性証明書を用いたノードの認証を行いやすくする。【解決手段】  属性証明書検証サーバ５が、ノード３の属性を証明する属性証明書および属性証明書の失効情報を蓄積する１以上のリポジトリ４から属性証明書を取得して、この属性証明書の取得および検証を行い、この検証結果を属性情報検証サーバ５へ送信する構成とした。【選択図】  図１
2005252500.tif 000002
【特許請求の範囲】
【請求項１】
ノードの属性を証明する属性証明書およびこの属性証明書の失効情報を蓄積する１以上のリポジトリから、ネットワーク経由で前記ノードの属性証明書を取得して、この属性証明書の検証を行う属性証明書検証サーバであって、
前記ネットワーク経由で各種データの送受信を行うインターフェース部と、
前記属性証明書の検証結果を用いて前記ノードの認証を行う認証サーバから、前記ノードの公開鍵証明書を含む前記属性証明書の検証要求を受信する検証要求受付部と、
前記受信した検証要求に含まれる前記ノードの公開鍵証明書に基づいて、前記ネットワーク経由で、前記１以上のリポジトリから前記ノードの属性証明書を取得する属性証明書取得部と、
前記ネットワーク経由で、前記リポジトリに蓄積された前記属性証明書の失効情報を参照して、前記リポジトリから取得した前記ノードの属性証明書が有効か否かを検証する属性証明書検証部と、
前記属性証明書の検証結果を前記認証サーバへ送信する検証結果送信部と、
を備えることを特徴とする属性証明書検証サーバ。
【請求項２】
前記属性証明書検証サーバは、
１以上の通信プロトコルを格納する通信プロトコル記憶部をさらに備え、
前記属性証明書取得部は、
前記ネットワーク経由で、前記リポジトリから前記属性証明書を取得するときおよび前記リポジトリの前記属性証明書の失効情報を参照するとき、前記通信プロトコル記憶部から前記リポジトリとの通信に必要な通信プロトコルを選択して用いるよう構成されていることを特徴とする請求項１に記載の属性証明書検証サーバ。
【請求項３】
請求項１または請求項２に記載の属性証明書検証サーバを含む認証システムであって、
前記１以上のリポジトリと、
前記認証サーバと、
前記ノードと、
を含み、
前記認証サーバは、前記属性証明書検証サーバから送信された前記属性証明書の検証結果を用いて前記ノードの認証を行い、この認証結果を前記ノードへ送信するよう構成されていることを特徴とする認証システム。
【請求項４】
ノードの属性を証明する属性証明書およびこの属性証明書の失効情報を公開鍵証明書の識別情報ごとに記憶する１以上のリポジトリから、ネットワークを経由で前記ノードの前記属性証明書を取得して、前記属性証明書が有効か否かの検証を行う属性証明書検証方法であって、
コンピュータが、
各ノードの認証を行う認証サーバから、前記ノードの公開鍵証明書を含む前記属性証明書の検証要求を受信するステップと、
前記リポジトリから前記属性証明書を取得する属性証明書取得部で、前記受信した検証要求に含まれる前記ノードの公開鍵証明書の識別情報に基づいて、前記ネットワークを経由して、前記１以上のリポジトリから前記ノードの属性証明書を取得するステップと、
前記属性証明書の検証を行う属性証明書検証部で、前記ネットワーク経由で、前記リポジトリに記憶された前記属性証明書の失効情報を参照して、前記リポジトリから取得した属性証明書が有効か否かを検証するステップと、
前記属性証明書の検証結果を送信する検証結果送信部で、前記属性証明書の検証結果を前記認証サーバへ送信するステップと、
を実行することを特徴とする属性証明書検証方法。
【請求項５】
前記属性証明書取得部で、前記ネットワークを経由して、前記１以上のリポジトリから前記ノードの属性証明書を取得するとき、および前記リポジトリの前記属性証明書の失効情報を参照するとき、前記属性証明書取得部は、１以上の通信プロトコルを格納する通信プロトコル記憶部から前記リポジトリとの通信に必要な通信プロトコルを選択して用いることを特徴とする請求項４に記載の属性証明書検証方法。
【請求項６】
ノードの属性を証明する属性証明書の検証結果を用いて前記ノードの認証を行う認証方法であって、
前記ノードの認証を行う認証サーバが、
前記ノードから、このノードの公開鍵証明書を含む認証要求を受信するステップと、
前記受信した認証要求に基づいて、前記ノードの公開鍵証明書を含む前記ノードの属性証明書の検証要求を送信するステップと、
を実行し、
前記ノードの属性証明書の取得および検証を行う属性証明書検証サーバが、
前記認証サーバから、前記ノードの属性証明書の検証要求を受信するステップと、
前記受信した属性証明書の検証要求に含まれる前記ノードの公開鍵証明書の識別情報に基づいて、前記ノードの属性証明書を、前記属性証明書およびこの属性証明書の失効情報を前記公開鍵証明書の識別情報ごとに記憶する１以上のリポジトリから、前記ネットワーク経由で取得するステップと、
前記ネットワーク経由で、前記リポジトリに記憶された前記属性証明書の失効情報を参照して、前記リポジトリから取得した前記ノードの属性証明書が有効か否かを検証するステップと、
前記ノードの検証結果を前記認証サーバへ送信するステップと、
を実行し、
前記認証サーバが、
前記属性証明書検証サーバから、前記ノードの検証結果を受信するステップと、
このノードの検証結果に基づいて、前記ノードの認証を行うステップと、
を実行することを特徴とする認証方法。
【請求項７】
コンピュータに、請求項４または請求項５に記載の属性証明書検証方法を実行させることを特徴とする属性証明書検証用プログラム。
【請求項８】
コンピュータに、請求項７に記載の認証方法を実行させることを特徴とする認証用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、属性証明書の検証を行う属性証明書検証サーバに関する。
【背景技術】
【０００２】
従来、インターネットにおける認証技術として公開鍵基盤（PKI、Public Key Infrastructure）を利用した認証技術が注目されている。
PKIには、本人性を証明する公開鍵証明書（PKC、Public Key Certificate）と、権限を証明する属性証明書（AC、Attribute Certificate）とが用いられる。認証サーバ（認証をする装置）は、被認証ノード（認証対象の装置）のPKCやACを取得し、検証することで、証明書の正当性を確認する。そして、その正当性が確認された証明書を利用して被認証ノードの認証を行う。
【０００３】
認証サーバは、PKCを検証する際、PKCに関する各種情報を蓄積するリポジトリからPKCの失効情報等を取得する。ここで、リポジトリが新規追加されると、認証サーバは、このリポジトリに対応する情報取得機能（例えば、HTTP（HyperText Transfer Protocol）、LDAP（Lightweight Directory access Protocol）といった通信プロトコル等）を新たに追加（拡張）しなければならない場合がある（以下、この問題を認証サーバの通信機能の問題という）。
【０００４】
非特許文献１の方法は、従来認証サーバで行っていたPKCの検証処理を、検証サーバで代行させることで、認証サーバの通信機能の問題を解決している。この非特許文献１の方法を、図３を用いて説明する。
【０００５】
図３は、従来技術（非特許文献１の方法）を説明するために引用した図である。
図３に示すように、非特許文献１の方法において、（１）認証サーバ２は、ノード３（被認証ノード３）からPKCを含む認証要求を受信する。（２）認証サーバ２は、（１）で受信したPKCを含む検証要求を検証サーバ１へ送信する。（３）この検証要求を受けた検証サーバ１は、PKCやPKCの失効情報をリポジトリ４から取得し、ノード３から受信したPKCが有効か否か（正当なものか否か）を検証する。（４）認証サーバ２は、検証サーバ１からPKCの検証結果を受信する。（５）認証サーバ２は、（４）での検証結果に基づき被認証ノード３の認証を行い、その認証結果を被認証ノード３へ送信する。
このように検証サーバ１で、PKCの検証処理を代行させることで、認証サーバ２がリポジトリ４から情報を取得する機能（通信機能）を備えなくとも、被認証ノード３のPKCの検証結果を得て、認証を行うことができる。
【０００６】
一方、認証サーバが、被認証ノードのAC（属性証明書）を取得する方法には、１）被認証ノードから認証サーバに対してACを送信するPush方式と、２）認証サーバがACを管理するリポジトリから被認証ノードに関するACを取得するPull方式が存在する。
ここで、Push方式で取得したACの検証については、前記した非特許文献１の方法をPush方式で取得したACの検証に用いることで、認証サーバの通信機能の問題を解決できる。
【０００７】
【非特許文献１】IETF PKIX WG，Delegated PathVa1idation and Delegated Path Discovery Protocol Requirements，September2002、[online]、[2004年2月24日検索]、インターネット、<URL: http://www.ietf.org/rfc/rfc3379.txt>
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、Pull方式で取得したACの検証に、前記した非特許文献１の方法を適用する場合、認証サーバは、リポジトリからACを取得する機能が必要になるので、前記した認証サーバの通信機能の問題は依然解決されない。これを、図４を用いて説明する。
図４は、従来技術（非特許文献１の方法）をPull方式で取得したACの検証に適用した場合の処理手順を説明した図である。
【０００９】
図４に示すように、（１）認証サーバ２は、被認証ノード３からPKCを含む認証要求を受信する。（２）認証サーバ２は、（１）で受信したPKCに基づいてリポジトリ４からAC（被認証ノード３のAC）を取得する。（３）認証サーバ２は、（２）で取得したACを含むACの検証要求を検証サーバ１へ送信する。（４）〜（６）の手順は、図４の（３）〜（５）のPKCをACに置き換えた手順と同様であるので説明を省略する。
【００１０】
このように、非特許文献１の方法を、Pull方式で取得したACの検証に適用した場合、認証サーバの検証処理の負担を軽減することができる。しかし、非特許文献１の方法は、リポジトリからのAC取得を、認証サーバで行うことを前提にしているので、前記した認証サーバの通信機能の問題を解決していない。すなわち、リポジトリが新規追加されたときに、認証サーバがこれに対応する通信機能を持っていないと、認証サーバはACを用いた被認証ノードの認証を行うことができないことになる。
そこで本発明は、このような認証サーバの通信機能の問題を解決する属性証明書検証サーバ等を提供することを課題とする。
【課題を解決するための手段】
【００１１】
前記した課題を解決するため、本発明は、ネットワーク経由で、ノードの属性を証明する属性証明書およびこの属性証明書の失効情報を蓄積する１以上のリポジトリから前記ノードの属性証明書を取得して、この属性証明書の検証を行う属性証明書検証サーバを、前記ネットワーク経由で各種データの送受信を行うインターフェース部と、前記属性証明書の検証結果を用いて前記ノードの認証を行う認証サーバから、前記ノードの公開鍵証明書を含む前記属性証明書の検証要求を受信する検証要求受付部と、前記受信した検証要求に含まれる前記ノードの公開鍵証明書に基づいて、前記ネットワーク経由で、前記１以上のリポジトリから前記ノードの属性証明書を取得する属性証明書取得部と、前記ネットワーク経由で、前記リポジトリに蓄積された前記属性証明書の失効情報を参照して、前記リポジトリから受信した前記ノードの属性証明書が有効か否かを検証する属性証明書検証部と、前記属性証明書の検証結果を前記認証サーバへ送信する検証結果送信部とを備える構成とした。
その他の構成については、後記する実施の形態で述べる。
【発明の効果】
【００１２】
本発明によれば、属性証明書検証サーバが、AC（属性証明書）の取得を代行するので、リポジトリの新規追加等があった場合も、認証サーバ側で新規な通信機能（通信プロトコル）を追加する必要がなくなる。すなわち、認証サーバが属性証明書検証サーバとの通信機能を備えていれば、リポジトリの新規追加等があった場合も、通信機能の追加をすることなくACを用いた被認証ノードの認証を行うことができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の属性証明書検証サーバ等を実施するための最良の形態（以下「実施の形態」という）を、図面を参照して詳細に説明する。
【００１４】
図１は、本発明の実施の形態である属性証明書検証サーバを含む認証システムの構成を示すブロック図である。まず、図１を用いて、認証システムの概略を説明する。
【００１５】
図１に示すように、認証システムは、認証サーバ２と、被認証ノード（ノード）３と、リポジトリ４と、属性証明書検証サーバ（AC検証サーバ）５と、これらを接続するネットワーク６とを含んで構成される。
【００１６】
認証サーバ２は、被認証ノード３のACの検証結果を用いて認証を行うサーバである。例えば、所定のユーザ（被認証ノード３）にサービスを提供するため、ユーザのACの検証結果を用いて、ユーザ（被認証ノード３）の認証を行うサーバ等が考えられる。認証サーバ２は、CPU（Central Processing Unit）、メモリ等から構成され、メモリに格納された認証用プログラムを展開させることで各種の処理を行うものとする。なお、被認証ノード３は、例えば、PC（Personal Computer）等が考えられる。
【００１７】
リポジトリ４は、ACおよびACに関する情報（ACの失効情報等）をACの証明対象（被認証ノード３）の識別情報ごとに格納している。また、リポジトリ４は、PKCに関する情報（PKCの失効情報）をPKCの証明対象（被認証ノード３）の識別情報ごとに蓄積している。
このリポジトリ４は、ネットワーク６経由でAC検証サーバ５からACの取得要求を受けると、これに応じてACを送信する。また、AC検証サーバ５からACに関する情報やPKCに関する情報の参照要求を受け付けて、AC検証サーバ５にこれらの情報を参照させる。
なお、被認証ノード３の識別情報とは、例えば、被認証ノード３のPKCの識別情報等が考えられる。
ちなみに、リポジトリ４は、ACを蓄積するリポジトリ、ACの失効情報を蓄積するリポジトリ、PKCの失効情報を蓄積するリポジトリ等の複数の異なるリポジトリで構成されるようにしても良いし、これらの情報をまとめて１つのリポジトリで記憶・蓄積するよう構成しても良い。
【００１８】
なお、認証サーバ２および被認証ノード３も、それぞれ２台以上で構成されていても良く、ネットワーク６は、例えばインターネット網やLAN(Local Area Network)等である。
【００１９】
AC検証サーバ５は、ネットワーク６経由で各種データの送受信を行うインターフェース部１０１と、被認証ノード３から受信したPKCやリポジトリ４から取得したACを記憶する証明書記憶部１００と、リポジトリ４との通信に用いる通信機能（少なくとも１以上の通信プロコトル）を記憶する通信プロトコル記憶部１１０と、ACの検証処理等を行う処理手段１２０とを含んで構成される。
AC検証サーバ５は、認証サーバ２からのACの検証要求を受信すると、ネットワーク６経由で、リポジトリ４から被認証ノード３のACを取得する。そして、リポジトリ４に記憶されるACの失効情報を参照して、被認証ノード３のACが有効か否か（正当なものか否か）の検証を行う。
処理手段１２０は、検証要求受付部１２１と、属性証明書取得部（AC取得部）１２２と、属性証明書検証部（AC検証部）１２３と、検証結果送信部１２４とを含んで構成される。
【００２０】
検証要求受付部１２１は、認証サーバ２からネットワーク６経由で被認証ノード３のACの検証要求を受け付ける。この検証要求は、被認証ノード３のPKCを含み、検証要求受付部１２１は、検証要求を受け付けると、被認証ノード３のPKCをAC取得部１２２へ出力する。このようにACの検証要求がPKCを含むことにより、AC検証サーバ５が、どのノードのACを取得すればよいのかを特定できる。
【００２１】
なお、この検証要求受付部１２１は、検証要求に含まれる被認証ノード３のPKCの検証機能を備えていても良い。すなわち、検証要求受付部１２１は、検証要求を受け付けると、ネットワーク６経由でリポジトリ４が格納するPKCの失効情報を参照して、このPKCが有効なものか否か（正当なものか否か）を検証する。そして、PKCが有効なもの（正当なもの）であると検証できたときに、このPKCをAC取得部１２２へ出力するようにしても良い。
このようにすることで、検証対象（認証サーバ２の認証対象）が確かに被認証ノード３であることを確認した上で、ACの取得を行うようにすることができる。つまり、被認証ノード３の本人性を確認した上でACの取得を行うようにすることができる。
【００２２】
AC取得部１２２は、検証要求受付部１２１から出力された被認証ノード３のPKCを受信すると、そのPKCに基づくACの取得要求をリポジトリ４へ送信する。このPKCに基づくACの取得要求とは、例えば、被認証ノード３のPKC（PKCの識別情報）を含むACの取得要求である。そして、ネットワーク６経由でリポジトリ４からこのPKC（PKCの識別情報）に対応するAC（被認証ノード３のAC）を取得する。そして、このACを証明書記憶部１００に記憶させる。
なお、AC取得部１２２がリポジトリ４からACを取得するとき、通信プロトコル記憶部１１０に格納されている通信プロトコルから、リポジトリ４との通信に必要な通信プロトコルを選択し、これを読み出して、通信（AC取得）を行うものとする。
【００２３】
AC検証部１２３は、リポジトリ４から取得したACの検証を行う。具体的には、AC検証部１２３は、証明書記憶部１００からリポジトリ４から取得した被認証ノード３のACを読み出し、ネットワーク６経由で、リポジトリ４に格納されたACの失効情報（ACの有効期間、発行者（認証局）等の情報）を参照して、このACが有効なものか否か（正当なものか否か）を検証する。そして、検証結果送信部１２４経由で、この検証結果を認証サーバ２へ送信する。
なお、処理手段１２０は、例えば、CPU（Central Processing Unit）であり、図示しないメモリに格納された属性証明書検証用プログラムを展開させることで各種の処理を行うものとする。
前記した各構成要素の動作の詳細は、以下の処理手順の項で説明する。
【００２４】
次に、適宜図１を参照しつつ図２を用いて、図１のAC検証サーバ５を含む認証システムの処理手順（AC検証サーバ５によるAC検証方法および認証サーバ２による被認証ノード３の認証方法）を説明する。
図２は、図１のAC検証サーバを含む認証システムの処理手順を示したシーケンス図である。
【００２５】
まず、被認証ノード３は、認証サーバ２へ被認証ノード３のPKCを付加した認証要求を送信する（ステップＳ１０１）。認証サーバ２は、被認証ノード３から送信された認証要求を受信すると、被認証ノード３のPKCを含むACの検証要求をAC検証サーバ５へ送信する（ステップＳ１０２）。
【００２６】
AC検証サーバ５は、この検証要求を検証要求受付部１２１で受信すると、検証要求に含まれるPKCをAC取得部１２２へ出力する。
【００２７】
このとき、検証要求受付部１２１は、検証要求に含まれる被認証ノード３のPKCの検証を行ってからPKCをAC取得部１２２へ出力するようにしても良い。すなわち、ネットワーク６経由で、リポジトリ４が格納するPKCの失効情報を参照して、このPKCが有効なものか否か（正当なものか否か）を検証し、PKCが有効なもの（正当なもの）であると検証できたときに、このPKCをAC取得部１２２へ出力するようにしても良い。すなわち、被認証ノード３の本人性を確認した上でAC取得をするようにしても良い。
そして、AC取得部１２２は、このPKC（PKCの識別情報）を付加したACの取得要求をネットワーク６経由で、リポジトリ４へ送信する（ステップＳ１０３）。
【００２８】
AC検証サーバ５からのAC取得要求を受信したリポジトリ４は、AC取得要求に含まれるPKCの識別情報をキーとして、自身の記憶部（図示せず）から被認証ノード３のACを検索する（ステップＳ１０４）。そして、検索した被認証ノード３のACをAC検証サーバ５へ送信する（ステップＳ１０５）。
【００２９】
AC検証サーバ５のAC取得部１２２が、まず、リポジトリ４から被認証ノード３のACを受信し、このACをいったん証明書記憶部１００へ記憶させる。そして、AC検証部１２３にこのACの検証を指示する信号を出力する。この信号を受けたAC検証部１２３は、ネットワーク６経由で、リポジトリ４のACの失効情報を参照し、証明書記憶部１００に記憶された被認証ノード３のACが有効か否かを検証する（ステップＳ１０６）。
【００３０】
すなわち、AC検証部１２３は、例えば、リポジトリ４のACの失効情報（有効期間に関する情報）を参照して、被認証ノード３から送信されたACがまだ有効か否かをチェックする。そして、この検証結果を検証結果送信部１２４へ出力し、検証結果送信部１２４から認証サーバ２へ送信する（ステップＳ１０７）。
【００３１】
認証サーバ２は、AC検証サーバ５から送信された被認証ノード３のACの検証結果を受信すると、認証サーバ２はこの検証結果に基づき、被認証ノード３の認証を行い、この認証結果を被認証ノード３へ送信する（ステップＳ１０８）。ここで、ACの認証結果に基づく被認証ノード３の認証とは、例えば、ACが確かに有効なものであると検証（確認）できたとき、このACに記載されている属性やサービスの利用権限にしたがって被認証ノード３が利用できるサービスを判断すること等も考えられる。また、ステップＳ１０８で送信する認証結果には、認証の結果利用できるコンテンツやデータ等を含んでいても良い。
【００３２】
なお、AC検証サーバ５のAC取得部１２２およびAC検証部１２３は、リポジトリ４との通信（ステップＳ１０３、ステップＳ１０５およびステップＳ１０６）において、通信プロトコル記憶部１１０からリポジトリ４との通信に必要な通信プロトコルを選択して、これを読み出し、実行するものとする。また、AC検証サーバ５が、認証サーバ２と通信を行う際（ステップＳ１０２およびステップＳ１０７）も同様である。
【００３３】
AC検証サーバ５が以上のような構成および処理手順を実行することで、ACの情報を蓄積するリポジトリ４の新規追加等があった場合も、認証サーバ２で新規な通信機能（通信プロトコル）を追加する必要がなくなる。すなわち、認証サーバ２がAC検証サーバ５との通信機能を備えていれば、リポジトリ４の新規追加等があった場合も、通信機能の追加をすることなくACを利用した被認証ノード３の認証を行うことができる。
【００３４】
本発明は、前記した実施の形態に限定されず、発明の趣旨を逸脱しない範囲で応用可能である。
【００３５】
例えば、前記した実施の形態におけるAC検証サーバ５の通信プロトコル記憶部１１０は、書き込み可能な記憶媒体で構成され、インターフェース部１０１を介して外部から新規な通信プロトコルをインストール可能なようにしても良い。
このようにすることで、新規なリポジトリ４が追加され、通信プロトコル記憶部１１０に格納された通信プロトコルではリポジトリ４と通信できない場合でも、このリポジトリ４と通信が可能となる。また、AC検証サーバ５で新規な通信プロトコルを追加可能とすることで、認証サーバ２のそれぞれで新規な通信プロトコルを追加する必要もなくなるので、認証サーバ２の通信機能の問題をより確実に解決できる。
【００３６】
本実施の形態に係るAC検証サーバ５は、前記した属性証明書の検証方法（検証処理）を実行する属性証明書検証用プログラムによって実現することができ、認証サーバ２は、前記した認証方法（認証処理）を実行する認証用プログラムによって実現することができる。さらに、これらのプログラムを、コンピュータによる読み取り可能な記憶媒体（例えば、ＣＤ−ＲＯＭやハードディスク等）に記憶して提供することも可能であるし、ネットワークを通して提供することも可能である。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施の形態である属性証明書検証サーバを含む認証システムの構成を示すブロック図である。
【図２】図１のAC検証サーバを含む認証システムの処理手順を示したシーケンス図である。
【図３】従来技術（非特許文献１の方法）を説明するために引用した図である。
【図４】従来技術をPull方式で取得したACの検証に適用した場合の処理手順を説明した図である。
【符号の説明】
【００３８】
２      認証サーバ
３      被認証ノード（ノード）
４      リポジトリ
５      AC検証サーバ（属性証明書検証サーバ）
６      ネットワーク
１０１  インターフェース部
１１０  通信プロトコル記憶部
１２１  検証要求受付部
１２２  AC取得部（属性証明書取得部）
１２３  AC検証部（属性証明書検証部）
１２４  検証結果送信部
【図１】
2005252500.tif 000003
【図２】
2005252500.tif 000004
【図３】
2005252500.tif 000005
【図４】
2005252500.tif 000006