以下、添付図面を参照して本発明にかかる失効情報生成装置、サービス提供元装置、属性情報検証システム、及び属性情報検証方法の好適な実施形態を詳細に説明する。なお、図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。
[第1実施形態]
本発明の第1実施形態における課金情報検証システム(属性情報検証システム)1は、サービスの提供元装置からサービスの提供先装置へ所定のサービスが提供されるために、属性証明書に記載された課金情報(例えばクレジットカード番号など)の有効性を検証するシステムである。課金情報検証システム1の基本的な構成について、図1を参照しながら説明する。図1は課金情報検証システム1の構成概要図である。図1に示すように、課金情報検証システム1は、属性証明書管理装置10、ユーザ端末(サービス提供先装置)20、及びサーバ(サービス提供元装置)30を備えて構成される。なお、図1ではユーザ端末20とサーバ30とが単数として図示されているが、実際の課金情報検証システム1の構成ではユーザ端末20とサーバ30とが複数存在する。以下、課金情報検証システム1の各構成要素について詳細に説明する。
属性証明書管理装置10は、属性証明書等を管理するものである。図2は、属性証明書管理装置10のハードウェア構成図である。属性証明書管理装置10は、物理的には、図2に示すように、CPU11、主記憶装置であるRAM12及びROM13、入力デバイスであるキーボード及びマウス等の入力装置14、ディスプレイ等の出力装置15、ネットワークカード等のデータ送受信デバイスである通信モジュール16、及びハードディスク等の補助記憶装置17を含むコンピュータシステムとして構成されている。後述する属性証明書管理装置10の各機能は、図2に示すCPU11、RAM12等のハードウェア上に所定のソフトウェアを読み込ませることにより、CPU11の制御のもとで通信モジュール16、入力装置14、出力装置15を動作させると共に、RAM12や補助記憶装置17におけるデータの読み出し及び書き込みを行うことで実現される。
図1に戻り、属性証明書管理装置10は、属性証明書発行装置110及びACRL管理装置(失効情報生成装置)120を備えて構成される。属性証明書発行装置110は、属性証明書を生成してユーザ端末20に発行するものであり、例えば属性証明書発行機関(AA)に設置される。属性証明書発行装置110は、通信網40を介して、ユーザ端末20と通信可能なように構成されている。通信網40は、例えばインターネット網、PDC(Personal Digital Cellular)網、IMT(International MobileTelecommunication)2000網等の無線通信網である。
図3は、属性証明書発行装置110が生成した属性証明書の一例を示す。図3に示すように、属性証明書には特定情報としてシリアル番号(図3においては「○○番」)が付されている。また、属性証明書には、例えば「名前」、「住所」、「前回購入品目」、「クレジットカード番号」等、ユーザ端末20のユーザのプライバシーに関する属性情報が複数含まれている。以下の第1実施形態における説明においては、図1に示したユーザ端末20とサーバ30の間で課金を行うために、「名前」、「住所」、「クレジットカード番号」の3つの属性情報が有効なものとして必要であることを仮定する。これに対して、「前回購入品目」は、ユーザ端末20とサーバ30以外の装置間でサービスの授受を行うときに、その有効性が問われることを仮定する。すなわち、1つの属性証明書には複数の装置用の属性情報が含まれる。図1に戻り、属性証明書発行装置110は、このように生成した属性証明書を、通信網40を介して、ユーザ端末20に発行する。この発行処理は、属性証明書発行装置110からユーザ端末20へ属性証明書の電子データを送信することで行われる。
ACRL管理装置120は、失効された属性証明書及び属性情報のリストであるACRL(Attribute Certificate Revocation List)を生成して管理するものである。ACRL管理装置120は、通信網50を介して、サーバ30と通信可能なように構成されている。通信網50は、例えばインターネット網等の通信網である。ACRL管理装置120は、機能的には、ACRL生成部(生成手段)121、ACRL格納部(格納手段)122、ACRL要求受信部(失効情報要求受信手段)123、及びACRL要求応答部(失効情報送信手段)124を備える。以下、ACRL管理装置120の各構成要素について詳細に説明する。
ACRL生成部121は、属性証明書毎にACRLを生成するものである。ACRL生成部121は、例えばある属性証明書に含まれた属性情報が失効となったときに、該属性証明書のシリアル番号を記載した該属性証明書用のACRLを生成する。ACRLに記載された属性証明書のシリアル番号は、該属性証明書の本体の失効状態を表す。また、ACRL生成部121は、失効された属性情報の属性名(属性情報の特定情報)をACRLに記載する。ACRLに記載された属性情報の属性名は、該属性情報の失効状態を表す。更に、ACRL生成部121は、一度失効された属性情報が更新されることによって有効状態になったときに、該有効状態になった属性情報を該失効状態の属性情報の属性名に対応付けてACRLに格納する。なお、ACRLに記載された属性名は本発明における部分失効情報に相当し、部分失効情報を生成して格納することは、失効された属性情報の属性名を特定してACRLに記載することに相当する。
図4は、ACRL生成部121が生成したACRLの一例を示す。図4に示すACRLにはシリアル番号として「○○番」と記載されており、このことは、このACRLが図3に示したシリアル番号「○○番」の属性証明書用のACRLであることを表す。更に、ACRLに「○○番」と記載されたことは、シリアル番号が「○○番」である属性証明書は、失効された属性情報を少なくとも1つ以上含んでおり、少なくとも部分的には失効されたものであることを表す。また、ACRLには、属性名として「住所」と記載されている。このことは、「○○番」の属性証明書に含まれた「住所」という属性名の属性情報は、失効されたものであることを表す。同様に、ACRLには、属性名として「クレジットカード番号」と記載されている。このことは、「○○番」の属性証明書に含まれた「クレジットカード番号」という属性名の属性情報は、失効されたものであることを表す。
一方、図4には、属性名「住所」に対応付けて「東京都○○区××村1−2−3」と記載されている。このことは、「住所」という属性名の属性情報は一度失効されたが、更新されることによって現時点では有効状態になったこと、及び該更新された内容は「東京都○○区××村1−2−3」であることを表す。すなわち、「住所」という属性名の属性情報はもはや失効状態ではないことを表す。このことは、例えば、ユーザ端末20のユーザの住所が変更され、その旨を表す信号がユーザ端末20からACRL管理装置120に送信されたときなどに起こる。
これに対して、属性名「クレジットカード番号」に対応付けては何も記載されていない。このことは、「クレジットカード番号」という属性名の属性情報は失効されたままであることを表す。このことは、例えば、ユーザ端末20のユーザがクレジットカードを紛失してしまい、新しいクレジットカードを再発給されるまでにはクレジットカードで課金を行う全てのサービスに対して停止を要望する旨を表す信号が、ユーザ端末20からACRL管理装置120に送信されたときなどに起こる。
更に、図4には属性名として「住所」と「クレジットカード番号」が記載されており、図3に示した属性証明書に記載された全ての属性名が記載されているわけではない。このことは、図3に示した属性証明書が失効されてはいるが、全ての属性情報に対して失効されたわけではなく、「クレジットカード番号」に対してのみ失効されていること、つまり属性証明書は部分的に失効されていることを表す。これに対して、例えば、ACRLに、「名前」、「住所」、「前回購入品目」、「クレジットカード番号」等の全ての属性名が記載された場合には、該属性証明書に含まれた属性情報の全てが失効されており、該属性証明書は完全に失効されたものであることを表す。
図1に戻り、ACRL生成部121は、このように生成したACRLをACRL格納部122に出力する。そして、ACRL格納部122は、ACRL生成部121から入力されたACRLを格納する。
ACRL要求受信部123は、特定のACRLを要求する旨を表すACRL要求信号をサーバ30から受信するものである。ACRL要求信号は、例えば、任意の属性証明書のシリアル番号である。ACRL要求受信部123は、サーバ30から受信した該シリアル番号をACRL要求応答部124に出力する。
ACRL要求応答部124は、ACRL要求受信部123から入力されたシリアル番号に対応したACRLをサーバ30に送信するものである。ACRL要求応答部124は、まずACRL要求受信部123から入力されたシリアル番号でACRL格納部122内を検索し、該シリアル番号が記載されたACRLが見つかった場合には、該ACRLをサーバ30に送信する。一方、検索の結果、該シリアル番号が記載されたACRLがACRL格納部122内で見つからなかった場合には、その旨を表す信号をサーバ30に送信する。
ユーザ端末20は、サービス提供先の携帯端末等の装置であって、本実施形態においては例えば携帯電話機である。図5は、ユーザ端末20のハードウェア構成図である。ユーザ端末20は、物理的には、図5に示すように、CPU21、主記憶装置であるRAM22及びROM23、操作ボタンなどの操作部24、LCD(Liquid Crystal Display)やEL(Electro Luminescence)などの出力装置25、属性証明書管理装置10とサーバ30との間でデータの送受信を無線で行う無線通信部26、メモリディバイス等の補助記憶装置27を備えて構成される。後述するユーザ端末20の各機能は、図5に示すCPU21、RAM22等のハードウェア上に所定のソフトウェアを読み込ませることにより、CPU21の制御のもとで操作部24、出力装置25、無線通信部26を動作させると共に、RAM22や補助記憶装置27におけるデータの読み出し及び書き込みを行うことで実現される。
このようなユーザ端末20において、RAM22及び補助記憶装置27は、記憶可能な容量に制限があり、例えば複数の属性証明書を格納するほどの大量のメモリ容量を確保することは困難である。このため、ユーザ端末20は、例えば課金を伴うサービスを複数のサーバから提供される場合に、該複数のサーバのそれぞれがユーザ端末20のユーザに対する課金情報を確認するときに必要とする属性情報の全てをまとめて記載した1つの属性証明書(図3参照)を保持する。
図1に戻り、ユーザ端末20は、通信網40を介して、属性証明書発行装置110及びサーバ30と通信可能なように構成されている。このユーザ端末20は、機能的には、属性証明書受信部21、サービス要求部22及びサービス授受部23を備える。
属性証明書受信部21は、通信網40を介して、属性証明書発行装置110により発行された属性証明書を受けるものである。属性証明書受信部21は、属性証明書発行装置110から取得した属性証明書をサービス要求部22に出力する。
サービス要求部22は、通信網40を介して、サーバ30に、例えば所定のデータの配信等のサービスを要求するものである。ユーザ端末20が任意のサーバから該サービスを受けるためには、ユーザ端末20は自端末のユーザの課金情報をサーバ30に認証させる必要がある。このため、サービス要求部22は、該サービスの要求信号をサーバ30に送信すると共に、属性証明書受信部21から入力された属性証明書をサーバ30に送信する。
サービス授受部23は、サービス要求部22がサーバ30に送信したサービス要求信号等に対する応答信号として、サーバ30からの該サービスの提供を受け入れるものである。
サーバ30は、サービスの提供元の装置である。サーバ30は、属性証明書管理装置10と同様に、物理的な構成要素として、CPU、RAM、ROM、入力装置、出力装置、通信モジュール、補助記憶装置などを含むコンピュータシステムとして構成されている(図2参照)。サーバ30は、通信網40を介して、ユーザ端末20と通信可能なように構成されている。また、サーバ30は、通信網50を介して、ACRL管理装置120と通信可能なように構成されている。
サーバ30は、機能的には、サービス要求受信部(属性証明書受信手段)31、ACRL要求部(失効情報要求手段)32、ACRL受信部(失効情報受信手段)33、第1有効性検証部(第1検証手段)34、属性情報取得部35、及びサービス提供部36を備える。
サービス要求受信部31は、通信網40を介して、ユーザ端末20からのサービス要求信号を受信する。更に、ユーザ端末20のユーザの課金情報を確認するために、サービス要求受信部31は、ユーザ端末20から属性証明書を受信する。サービス要求受信部31は、ユーザ端末20から受信した属性証明書をACRL要求部32及び第1有効性検証部34に出力する。また、サービス要求受信部31は、ユーザ端末20から受信したサービス要求信号をサービス提供部36に出力する。
ACRL要求部32は、通信網50を介して、ACRL要求信号をACRL管理装置120に送信するものである。ACRL要求信号は、例えば、ACRL要求部32がサービス要求受信部31から入力された属性証明書のシリアル番号である。ACRL要求信号は、当該シリアル番号に対応付けてACRL管理装置120に格納されたACRLを要求する旨を表す。
ACRL受信部33は、ACRL要求部32がACRL管理装置120に送信したACRL要求信号に応じて、ACRL管理装置120から送信されたACRL等を受信するものである。ACRL要求部32が送信したシリアル番号が記載されたACRLがACRL管理装置120に有る場合に、ACRL受信部33は該ACRLを受信する。一方、該シリアル番号が記載されたACRLがACRL管理装置120に無い場合に、ACRL受信部33はその旨を表す信号を受信する。ACRL受信部33は、ACRL管理装置120から受信したACRL等を第1有効性検証部34に出力する。
第1有効性検証部34は、ACRL受信部33から入力されたACRL等に基づいて、サービス要求受信部31から入力された属性証明書の有効性を検証するものである。第1有効性検証部34は、例えば、図4に示したようなACRLをACRL受信部33から入力され、且つ図3に示したような属性証明書をサービス要求受信部31から入力された場合に、シリアル番号「○○番」の属性証明書は、失効された属性情報を少なくとも1つ以上含んでおり、少なくとも部分的には失効されたものであると判断する。また、この場合に、第1有効性検証部34は、「○○番」の属性証明書に含まれた属性名「住所」の属性情報は、一度失効されたが、後ほど更新されることによって現時点では有効状態のものであると判断する。そして、該更新された内容は「東京都○○区××村1−2−3」であると判断する。また、同様な場合において、第1有効性検証部34は、「○○番」の属性証明書に含まれた属性名「クレジットカード番号」の属性情報が失効されたままであると判断する。また、同様な場合において、第1有効性検証部34は、図3の属性証明書の全ての属性情報が図4のACRLに記載されてはいないこと、及び属性名「住所」は現時点では有効状態であることから、図3の属性証明書は完全に失効されたものではなく、部分的に失効されたものであると判断する。
上記のことに対して、例えば、ACRL要求部32がACRL管理装置120に送信したシリアル番号が記載されたACRLはACRL管理装置120に無かったことを表す信号をACRL受信部33から入力され、且つ図3に示したような属性証明書をサービス要求受信部31から入力された場合に、第1有効性検証部34は、シリアル番号が「○○番」である属性証明書は失効された属性情報を1つも含んでおらず、完全に有効状態のものであると判断する。
第1有効性検証部34は、有効性検証の対象とした属性証明書、及び該検証の結果を表す信号を属性情報取得部35に出力する。そして、属性情報取得部35は、該結果に基づいて、該属性証明書に含まれた属性情報を取得する。
具体的に、例えば、上述した仮定のようにユーザ端末20とサーバ30の間で課金が行われる際に、属性情報取得部35が取得対象とする属性情報は、図3に示す複数の属性情報の中で、「名前」、「住所」、「クレジットカード番号」の3つである。そして、属性情報取得部35が、有効性検証の結果を表す信号として、「○○番」の属性証明書は部分失効されており、「クレジットカード番号」だけが失効状態であること(上記図3及び図4における例と同じ)を表す信号を受信したとする。この場合に、属性情報取得部35は、取得対象である「クレジットカード番号」が失効されていることを理由に、「クレジットカード番号」を取得しない。そして、属性情報取得部35は、「クレジットカード番号」を取得しなかったことを表す信号をサービス提供部36に出力する。
これに対して、例えば、属性情報取得部35が、シリアル番号が「○○番」である属性証明書は失効された属性情報を1つも含んでおらず完全に有効状態であることを表す信号を受信したとする。この場合に、属性情報取得部35は、取得対象である「名前」、「住所」、「クレジットカード番号」の全ての属性情報が有効状態であるので、該3つの属性情報を該属性証明書から取得する。なお、「前回購入品目」は元々取得対象ではないので取得しない。そして、属性情報取得部35は、取得した3つの属性情報をサービス提供部36に出力する。
サービス提供部36は、属性情報取得部35から入力された属性情報等を参照して、ユーザ端末20のユーザに対する課金情報を確認し、その確認の結果に応じて、サービス要求受信部31から入力されたサービス要求信号に応じたサービスをユーザ端末20に提供するものである。サービス提供部36は、例えば、属性情報取得部35から「クレジットカード番号」を取得しなかったことを表す信号を入力された場合には、ユーザ端末20のユーザに対する課金情報を確認するための全ての属性情報が揃っていないので、課金情報は確認できず、ユーザ端末20に該サービスを提供しない。
これに対して、サービス提供部36は、例えば、「名前」、「住所」、「クレジットカード番号」の3つの属性情報を属性情報取得部35から入力され、且つ該3つの属性情報が当該課金を行うために適したものである場合(例えば、「クレジットカード番号」が正しいクレジットカード番号である場合など)には、ユーザ端末20に該サービスを提供する。一方、例えば、「名前」、「住所」、「クレジットカード番号」の3つの属性情報を属性情報取得部35から入力されたものの、該3つの属性情報が当該課金を行うために適したものではない場合(例えば、「クレジットカード番号」が間違ったクレジットカード番号である場合など)には、サービス提供部36は、ユーザ端末20に該サービスを提供しない。
続いて、課金情報検証システム1により行われる動作(属性情報検証方法)について、図6を参照しながら説明する。図6は、課金情報検証システム1の動作を示すシーケンス図である。
まず、属性証明書発行装置10が、図3に示したような属性証明書をユーザ端末20用の属性証明書として生成し、通信網40を介してユーザ端末20に発行する(S101)。ステップS101は、サービス提供先のユーザ端末20がサービス提供元のサーバ30にサービスの要求をする前に行われる動作である。以下では、ユーザ端末20がサーバ30にサービスの要求をする際に行われる動作を説明する。
ユーザ端末20が、通信網40を介して、サーバ30にサービスを要求する。ユーザ端末20は、該サービスの要求信号と共に、ステップS101にて発行された属性証明書をサーバ30に送信する(ステップS102)。
次に、サーバ30が、通信網50を介して、ACRL要求信号をACRL管理装置120に送信する。ACRL要求信号は、ステップS102にてユーザ端末20から受信した属性証明書のシリアル番号「○○番」である(ステップS103)。
次に、ACRL管理装置120が、ステップS103にて受信したシリアル番号「○○番」が記載されたACRLを自装置が保持しているか否かを確認する。この動作は、該シリアル番号でACRL格納部122内を検索することで行われる。ACRL管理装置120はACRL生成処理(後述するステップS110を参照)をまだ行ってないので、シリアル番号「○○番」が記載されたACRLは見つからない。このため、ACRL管理装置120は、ステップS103にて受信したシリアル番号「○○番」が記載されたACRLは無いことを表す信号をサーバ30に送信する(ステップS104)。
次に、サーバ30が、ステップS102にてユーザ端末20から受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。この動作は、ステップS104にてACRL管理装置120から受信した信号に基づいて行われる。すなわち、ステップS104にて、シリアル番号「○○番」が記載されたACRLは無いことを表す信号を受信したため、サーバ30は、ステップS102にてユーザ端末20から受信した属性証明書は有効状態であると判断する(ステップS105)。
次に、サーバ30が、ステップS102にてユーザ端末20から受信した属性証明書に含まれた属性情報を取得する。サーバ30は、ユーザ端末20のユーザの課金情報を確認するために、「名前」、「住所」、「クレジットカード番号」の3つの属性情報を読み取る(ステップS106)。
次に、サーバ30が、ステップS106にて読み取った「名前」、「住所」、「クレジットカード番号」の3つの属性情報を用いて、ユーザ端末20のユーザに対する課金情報を確認する(ステップS107)。
次に、サーバ30が、ステップS107における課金情報が該サービスを許可するために適したものである場合(例えば、「クレジットカード番号」が正しいクレジットカード番号である場合など)に、ステップS102にて受信したサービスの要求信号に応じたサービスをユーザ端末20に提供する(ステップS108)。
以上、ユーザ端末20が送信した属性証明書の本体が有効な場合について説明した。一方、以下においては、ユーザ端末20が送信した属性証明書が部分的に失効されている場合について説明する。ただし、以下においては、ユーザ端末20のユーザは、「東京都○○区××村1−2−3」の所に引越したこと、及びクレジットカードを紛失したことを仮定する。
ユーザ端末20が、ACRL管理装置120に、「住所」においては「東京都○○区××村1−2−3」の内容に変更すること、及び「クレジットカード番号」は失効させることを依頼する。この動作は、例えば、「住所」及び「クレジットカード番号」を表す信号をユーザ端末20からACRL管理装置120へ送信し、且つ「東京都○○区××村1−2−3」を表す信号を「住所」を表す信号に対応付けてACRL管理装置120へ送信することなどで行われる(ステップS109)。
次に、ACRL管理装置120が、ステップS109にてユーザ端末20から受信した信号に基づいてACRLを生成する。図4は、ステップS109の依頼に応じてACRL管理装置120が生成したACRLを示す(ステップS110)。
次に、ユーザ端末20が、通信網40を介して、サーバ30にサービスを要求する。ユーザ端末20は、該サービスの要求信号と共に、ステップS101にて発行された属性証明書をサーバ30に送信する(ステップS11)。
次に、サーバ30が、通信網50を介して、ACRL要求信号をACRL管理装置120に送信する。ACRL要求信号は、ステップS111にてユーザ端末20から受信した属性証明書のシリアル番号「○○番」である(ステップS112)。
次に、ACRL管理装置120が、ステップS112にて受信したシリアル番号「○○番」が記載されたACRLを自装置が保持しているか否かを確認する。この動作は、該シリアル番号「○○番」でACRL格納部122内を検索することで行われる。ステップS110にて、ACRL管理装置120はシリアル番号「○○番」を記載したACRLを生成したので、該ACRLが見つかりサーバ30に送信される(ステップS113)。
次に、サーバ30が、ステップS111にてユーザ端末20から受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。この動作は、ステップS113にて受信されたACRLに基づいて行われる。すなわち、サーバ30は、該ACRLが送信されてきたことを理由に、シリアル番号が「○○番」である属性証明書は、失効された属性情報を少なくとも1つ以上含んでおり、少なくとも部分的には失効されたものであると判断する。
また、サーバ30は、「住所」に対応付けられて「東京都○○区××村1−2−3」が記載されていることを理由に、「○○番」の属性証明書に含まれた属性名「住所」の属性情報は、一度失効されたが、更新されることによって有効状態になったものであると判断する。そして、該更新された内容は「東京都○○区××村1−2−3」であると判断する。また、ACRLには「クレジットカード番号」と記載されており、「クレジットカード番号」には何も対応付けられていないことを理由に、「○○番」の属性証明書に含まれた属性名「クレジットカード番号」の属性情報は、失効されたままであると判断する。
以上より、サーバ30は、自サーバがユーザ端末20のユーザの課金情報を確認するために必要な3つの属性情報の全てが有効状態であるとは限らないので、該3つの属性情報の全てを取得することはできず、ユーザ端末20のユーザに対する課金情報が確認できない(ステップS114)。このため、サーバ30は、テップS102にて受信したサービスの要求信号に応じたサービスをユーザ端末20に提供できないことを表す信号をユーザ端末20に送信する(ステップS115)。
続いて、第1実施形態の作用及び効果について説明する。本実施形態によれば、属性証明書に含まれたある属性情報が失効された場合、有効な属性証明書に含まれた有効な属性情報を取得するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、ACRLに属性証明書のシリアル番号が記載されたか否かによって、該属性証明書に対する有効性を検証することが可能であり、且つ部分失効情報を用いて(ACRLに該属性情報の属性名が記載されたか否かによって)、何れの属性情報が失効状態にあるかが検証可能である。このため、有効な属性証明書に含まれた有効な属性情報が取得可能であり、属性証明書を失効させてからまた再発行するなどの処理を行うために大きな手間がかかることを防止できる。したがって、第1実施形態によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
[第2実施形態]
以下、本発明の第2実施形態にかかるアクセス情報検証システム2を説明する。アクセス情報検証システム2は、例えばある会社の社内において、ある社員の端末から該社員の属する部署の共有フォルダへアクセスすることを許可するために、該社員用の属性証明書に記載されたアクセス情報(例えば所属部署名など)の有効性を検証するシステムである。このとき、例えば該部署用の共有フォルダには該部署に所属する社員のみがアクセス可能であることを仮定する。以下では、前述した第1実施形態における説明と異なる部分を中心に、アクセス情報検証システム2を説明する。
アクセス情報検証システム2の基本的な構成について、図7を参照しながら説明する。図7はアクセス情報検証システム2の構成概要図である。図7に示すように、アクセス情報検証システム2は、属性証明書管理装置10、社員端末(サービス提供先装置であり、第1実施形態におけるユーザ端末20に相当)200、及び共有フォルダ管理装置(サービス提供元装置であり、第1実施形態におけるサーバ30に相当)300を備えて構成される。なお、図7では社員端末200と共有フォルダ管理装置300とが単数として図示されているが、実際のアクセス情報検証システム2の構成では社員端末200と共有フォルダ管理装置300とが複数存在する。以下、アクセス情報検証システム2の各構成要素について詳細に説明する。
属性証明書発行装置110は、属性証明書を生成して社員端末200に発行する。図8は、属性証明書発行装置110が生成した属性証明書の一例を示す。図8に示すように、属性証明書には特定情報としてシリアル番号(図8においては「○△番」)が付されている。また、属性証明書には、例えば「名前」、「社員番号」、「入社日」、「所属部署名」等、社員端末200のユーザである社員に関する情報が複数含まれている。以下では、社員端末200が共有フォルダ管理装置300の管理する共有フォルダへアクセスすることを許可されるために、「名前」、「社員番号」、「所属部署名」の3つの属性情報が有効なアクセス情報として必要であることを仮定する。これに対して、「入社日」は、社員端末200と共有フォルダ管理装置300以外の装置間でアクセスを制御されるときに、その有効性が問われることを仮定する。
図7に戻り、ACRL管理装置120は、ACRLを生成して管理するものであり、通信網50を介して、共有フォルダ管理装置300と通信可能なように構成されている。ACRL管理装置120は、機能的には、ACRL生成部(生成手段)121、ACRL格納部(格納手段)122、有効性検証要求受信部(検証要求受信手段)125、第2有効性検証部(第2検証手段)126、及び検証結果送信部(検証結果送信手段)127を備える。
図9は、ACRL生成部121が生成したACRLの一例を示す。図9に示すACRLにはシリアル番号として「○△番」と記載されており、このことは、このACRLが図8に示したシリアル番号「○△番」の属性証明書用のACRLであることを表す。更に、ACRLに「○△番」と記載されたことは、シリアル番号が「○△番」である属性証明書は、失効された属性情報を少なくとも1つ以上含んでおり、少なくとも部分的には失効されたものであることを表す。また、ACRLには、属性名として「所属部署名」と記載されている。このことは、「○△番」の属性証明書に含まれた「所属部署名」は、失効されたものであることを表す。一方、図9には、属性名「所属部署名」に対応付けて「総務部」と記載されている。このことは、「所属部署名」という属性名の属性情報は一度失効されたが、更新されることによって有効状態になったこと、及び該更新された内容は「総務部」であることを表す。すなわち、「所属部署名」という属性名の属性情報はもはや失効状態ではないことを表す。したがって、シリアル番号「○△番」の属性証明書ももはや失効状態ではないこととなる。これらのことは、例えば、社員端末200の社員の部署が例えば営業部から総務部へと変更されたときなどに起こる。
図7に戻り、有効性検証要求受信部125は、特定の属性証明書及び該属性証明書に含まれた属性情報に対する有効性の検証を求める旨を表す有効性検証要求信号を共有フォルダ管理装置300から受信するものである。有効性検証要求信号は、例えば有効性検証の対象となる属性証明書である。有効性検証要求受信部125は、共有フォルダ管理装置300から受信した属性証明書を第2有効性検証部126に出力する。
第2有効性検証部126は、有効性検証要求受信部125から入力された属性証明書、及び該属性証明書に含まれた属性情報に対する有効性を検証するものである。第2有効性検証部126は、該属性証明書及び該属性情報とACRL格納部122に格納されたACRLとを照合することにより、該属性証明書及び該属性情報に対する有効性を検証する。
具体的に、第2有効性検証部126が、例えば図8に示したような属性証明書を有効性検証要求受信部125から入力されたと仮定する。この場合に、第2有効性検証部126は、まず該属性証明書のシリアル番号「○△番」でACRL格納部122内を検索する。検索の結果、該シリアル番号「○△番」が記載された例えば図9に示したようなACRLを見つけた場合に、第2有効性検証部126は、該属性証明書が失効されたものであると判断する。一方、該ACRLには、「名前」、「社員番号」、「入社日」、「所属部署名」等の全ての属性名が記載されてはいないので、該属性証明書は属性情報の全てが失効されたものではなく部分的に失効されたものであると判断される。また、第2有効性検証部126は、「○△番」の属性証明書に含まれた属性名「所属部署名」の属性情報は、一度失効されたが、後ほど更新されることによって有効状態になったものであると判断する。更に、該更新された内容は「総務部」であると判断する。以上より、第2有効性検証部126は、有効性検証要求受信部125から入力された属性証明書は現時点では有効状態であると判断する。これらのことに対して、上記検索の結果、例えば該シリアル番号が記載されたACRLがACRL格納部122内で見つからなかった場合には、シリアル番号「○△番」の属性証明書は、失効された属性情報を1つも含んでおらず、有効状態のものであると判断される。
第2有効性検証部126は、上記判断の結果を表す検証結果信号を検証結果送信部127に出力する。検証結果信号としては、上述したように属性証明書に含まれた属性情報が全て有効であることを表す信号や、属性証明書に含まれた属性情報が部分的に失効であることを表す信号の他に、例えば、属性証明書に含まれた属性情報が全て失効であることを表す信号、属性証明書或いは属性情報の失効可否が不明であることを表す信号などがある。また、更新されて有効になった属性情報がある場合には、該更新された属性情報が検証結果信号に含まれる。検証結果送信部127は、第2有効性検証部126から入力された検証結果信号を、通信網50を介して、OCSP(Online Certificate Status Protocol)レスポンスとして共有フォルダ管理装置300に送信する。
社員端末200は、共有フォルダ管理装置300の管理する共有フォルダ(当該社員の属する部署の共有フォルダ)にアクセスするために用いられる端末である。第2実施形態において、社員端末200は記憶可能な容量に制限があり、例えば複数の属性証明書を格納するほどの大量のメモリ容量を確保することは困難であることを仮定する。
共有フォルダ管理装置300は、社員端末200のアクセスの対象となる共有フォルダを管理する装置である。この共有フォルダ管理装置300は、例えば各部署の共有フォルダ毎に設けられる。共有フォルダ管理装置300は、機能的には、サービス要求受信部(属性証明書受信手段)31、有効性検証要求部(検証要求手段)37、検証結果受信部(検証結果受信手段)38、属性情報取得部35、及びサービス提供部36を備える。
サービス要求受信部31は、通信網40を介して、社員端末200からのサービス要求信号を受信する。第2実施形態において、サービス要求信号は、社員端末200の社員が属する部署の共有フォルダへのアクセス要求信号である。また、サービス要求受信部31は、社員端末200の社員のアクセス情報を確認するために、社員端末200から属性証明書を更に受信する。サービス要求受信部31は、社員端末200から受信した属性証明書を有効性検証要求部37及び属性情報取得部35に出力する。また、サービス要求受信部31は、社員端末200から受信したサービス要求信号をサービス提供部36に出力する。
有効性検証要求部37は、通信網50を介して、有効性検証要求信号をACRL管理装置120に送信するものである。有効性検証要求信号は、例えばサービス要求受信部31から入力された属性証明書である。
検証結果受信部38は、有効性検証要求部37がACRL管理装置120に送信した有効性検証要求信号に対するOCSPレスポンスとして、有効性の検証結果信号をACRL管理装置120から受信するものである。該検証結果信号は、サービス要求受信部31が社員端末200から受信した属性証明書及び該属性証明書に含まれた属性情報に対する失効可否を表す。検証結果受信部38は、受信した検証結果信号を属性情報取得部35に出力する。
属性情報取得部35は、検証結果信号を検証結果受信部38から入力され、該検証結果信号に基づいて、サービス要求受信部31から入力された属性証明書に含まれた属性情報を取得する。
具体的に、例えば、前述した仮定のように社員端末200が共有フォルダ管理装置300の管理する共有フォルダへアクセスする際に、属性情報取得部35が取得対象とする属性情報は、図8に示す複数の属性情報の中で「名前」、「社員番号」、「所属部署名」の3つである。この場合に、例えば、「○△番」の属性証明書に含まれた「名前」及び「社員番号」の属性情報は有効であり、且つ「所属部署名」は一度失効されたが、「総務部」という内容で更新されていることを表す信号を、属性情報取得部35が検証結果信号として受信したことを仮定する。なお、この仮定は、前述したように、図8の属性証明書に対して図9のACRLが見つかった場合のことである。この場合に、属性情報取得部35は、有効状態である「名前」及び「社員番号」の属性情報を取得すると共に、「所属部署名」が現時点では有効であるため、当該更新した内容(「総務部」)で「所属部署名」を取得する。そして、属性情報取得部35は、取得した3つの属性情報をサービス提供部36に出力する。
これに対して、例えば、シリアル番号が「○△番」である属性証明書は、取得対象である「名前」、「社員番号」、「所属部署名」の中で、現時点で失効された属性情報を1つ以上も含んでいることを表す信号を、属性情報取得部35が受信したとする。この場合に、属性情報取得部35は、現時点で失効された該属性情報を取得せず、その旨を表す信号をサービス提供部36に出力する。
サービス提供部36は、属性情報取得部35から入力された属性情報等を参照して、社員端末200のユーザに対するアクセス情報を確認し、その確認の結果に応じて、サービス要求受信部31から入力されたアクセス要求信号に応じたアクセス許可を社員端末200に与えるものである。サービス提供部36は、「名前」、「社員番号」、「所属部署名」の中で取得できなかった属性情報が1つ以上あることを表す信号を属性情報取得部35から入力された場合には、社員端末200の社員に対するアクセス情報の全てを確認できないので、社員端末200が当該共有フォルダにアクセスすることを許可しない。
これに対して、サービス提供部36は、属性情報取得部35から「名前」、「社員番号」、「所属部署名」の3つの属性情報を入力され、且つ該3つの属性情報が当該共有フォルダにアクセスするために適したものである場合には、社員端末200が該共有フォルダにアクセスすることを許可する。一方、例えば、属性情報取得部35から「名前」、「社員番号」、「所属部署名」の3つの属性情報を入力されてはいるが、該3つの属性情報が当該共有フォルダにアクセスするために適したものではない場合には、サービス提供部36は、社員端末200が該共有フォルダにアクセスすることを許可しない。
続いて、アクセス情報検証システム2により行われる動作(属性情報検証方法)について、図10を参照しながら説明する。図10は、アクセス情報検証システム2の動作を示すシーケンス図である。
まず、属性証明書発行装置10が、図8に示したような属性証明書を社員端末200用の属性証明書として生成し、通信網40を介して社員端末200に発行する(S201)。なお、ステップS201の動作が行われる前に、社員は「営業部」に配属されたことを仮定する。このため、ステップS201にて発行された属性証明書の「所属部署名」には「営業部」と記載されている。ステップS201は、社員端末200が例えば営業部の共有フォルダにアクセスを要求する前に行われる動作である。以下では、社員端末200が営業部の共有フォルダにアクセスする際に行われる動作を説明する。
社員端末200が、通信網40を介して、営業部の共有フォルダへのアクセス要求信号を営業部の共有フォルダ管理装置に送信する。社員端末200は、当該アクセス要求信号と共に、ステップS201にて発行された属性証明書を営業部の共有フォルダ管理装置に送信する(ステップS202)。
次に、営業部の共有フォルダ管理装置が、通信網50を介して、有効性検証要求信号をACRL管理装置120に送信する。有効性検証要求信号は、ステップS202にて社員端末200から受信した属性証明書である(ステップS203)。
次に、ACRL管理装置120が、ステップS203にて受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。ACRL管理装置120は、まずステップS203にて受信した属性証明書のシリアル番号の「○△番」が記載されたACRLを自装置が保持しているか否かを確認する。この動作は、該シリアル番号でACRL格納部122内を検索することで行われる。ACRL管理装置120はACRL生成処理(後述するステップS210を参照)をまだ行ってないので、シリアル番号「○△番」が記載されたACRLは見つからない。このため、ACRL管理装置120は、ステップS203にて受信したシリアル番号「○△番」の属性証明書は有効であると判断し(ステップS204)、その旨を表す検証結果信号をOCSPレスポンスとして営業部の共有フォルダ管理装置に送信する(ステップS205)。
次に、ステップS203にてACRL管理装置120に送信した属性証明書が有効であることを表す検証結果信号を受信した営業部の共有フォルダ管理装置は、該属性証明書に含まれた属性情報を取得する。営業部の共有フォルダ管理装置は、社員端末200の社員のアクセス情報として、「名前」、「社員番号」、「所属部署名」の3つの属性情報を読み取る(ステップS206)。
次に、営業部の共有フォルダ管理装置が、ステップS206にて読み取った「名前」、「社員番号」、「所属部署名」の3つの属性情報を用いて、社員端末200の社員に対するアクセス情報を確認する(ステップS207)。
次に、ステップS207におけるアクセス情報が該アクセスを許可するために適したものである場合(例えば、「所属部署名」の内容が「営業部」である場合など)に、営業部の共有フォルダ管理装置は、ステップS202にて受信したアクセス要求信号に応じて、社員端末200が営業部の共有フォルダへアクセスすることを許可する(ステップS208)。
以上、社員端末200の社員が「営業部」に配属され、社員端末200が提示した属性証明書のアクセス情報が営業部の共有フォルダにアクセスするために適した場合について説明した。一方、以下では、社員端末200の社員の所属部署が、「営業部」から「総務部」へと変更された場合について説明する。
社員端末200が、ACRL管理装置120に、「所属部署名」の内容を「営業部」から「総務部」へと更新することを依頼する。この動作は、例えば、「総務部」を表す信号を「所属部署名」を表す信号に対応付けてACRL管理装置120へ送信することで行われる(ステップS209)。
次に、ACRL管理装置120が、ステップS209にて社員端末200から受信した信号に基づいてACRLを生成する。図9は、ステップS209の依頼に応じてACRL管理装置120が生成したACRLを示す(ステップS210)。
次に、社員端末200が、通信網40を介して、総務部の共有フォルダへのアクセス要求信号を総務部の共有フォルダ管理装置に送信する。社員端末200は、当該アクセス要求信号と共に、ステップS201にて発行された属性証明書を総務部の共有フォルダ管理装置に送信する(ステップS211)。
次に、総務部の共有フォルダ管理装置が、通信網50を介して、有効性検証要求信号をACRL管理装置120に送信する。有効性検証要求信号は、ステップS211にて社員端末200から受信した属性証明書である(ステップS212)。
次に、ACRL管理装置120が、ステップS212にて受信した属性証明書及び該属性証明書に含まれた属性情報に対する有効性を検証する。ACRL管理装置120は、まずステップS212にて受信した属性証明書のシリアル番号の「○△番」が記載されたACRLを自装置が保持しているか否かを確認する。ステップS210にて、ACRL管理装置120はシリアル番号「○△番」を記載したACRLを生成したので、該ACRLが見つかる。
ACRL管理装置120は、該ACRLが見つかったことを理由に、シリアル番号が「○△番」である属性証明書は失効されたものと判断する。一方、ACRL管理装置120は、「所属部署名」に対応付けられて「総務部」と記載されていることを理由に、「○△番」の属性証明書に含まれた属性名「所属部署名」の属性情報は、一度失効されたが、後ほど更新されたことによって現時点では有効状態になったと判断する。そして、該更新された内容は「総務部」であると判断する。このことによって、該属性証明書も現時点では有効状態になったと判断される。ACRL管理装置120は、該属性証明書が現時点においては有効であるということ、及び「所属部署名」の更新内容は「総務部」であることを表す検証結果信号をOCSPレスポンスとして総務部の共有フォルダ管理装置に送信する(ステップS214)。
次に、ステップS212にてACRL管理装置120に送信した属性証明書が有効であることを表す検証結果信号を受信した総務部の共有フォルダ管理装置は、該属性証明書に含まれた属性情報を取得する。総務部の共有フォルダ管理装置は、社員端末200の社員のアクセス情報として、「名前」、「社員番号」、「所属部署名」の3つの属性情報を読み取る。「所属部署名」の属性情報を取得する際に、総務部の共有フォルダ管理装置は、属性証明書に記載された内容ではなく、ACRLに記載された内容、つまりステップS214の検証結果信号が表す内容を読み取る(ステップS215)。
次に、総務部の共有フォルダ管理装置が、ステップS215にて読み取った「名前」、「社員番号」、「所属部署名」の3つの属性情報を用いて、社員端末200の社員に対するアクセス情報を確認する(ステップS216)。
次に、ステップS216におけるアクセス情報が該アクセスを許可するために適したものである場合(例えば、「所属部署名」の内容が「総務部」である場合など)に、総務部の共有フォルダ管理装置は、ステップS211にて受信したアクセス要求信号に応じて、社員端末200が総務部の共有フォルダへアクセスすることを許可する(ステップS217)。
続いて、第2実施形態の作用及び効果について説明する。第2実施形態によれば、属性証明書に含まれたある属性情報が一度失効されて後で有効に更新された場合、有効な属性証明書に含まれた有効な属性情報を取得するために、例えば属性証明書の本体を失効させる処理、失効された属性情報を該属性証明書から削除する処理、有効となった属性情報を該属性証明書に書き込む処理、及び有効な属性情報のみが記載された新しい属性証明書を再発行する処理等を行わない。これに対して、共有フォルダ管理装置300は、該失効状態の属性情報の属性名と対応付けられてACRLに記載された該有効状態の属性情報を取得する。このため、更新されて有効状態となった属性情報が取得可能であり、該有効状態となった属性情報を該属性証明書に書き込んでからまた新しい属性証明書を再発行するなどの処理を行うために大きな手間がかかることを防止できる。したがって、第2実施形態によれば、上記処理等にかかる負荷を低減して、ユーザの利便性を高めることができる。
また、第2実施形態によれば、共有フォルダ管理装置300は、有効性の検証の結果をACRL管理装置120から受信することによって、何れの属性証明書が失効状態にあるか、及び何れの属性情報が失効状態にあるかを知ることができる。このため、ACRLがその生成元であるACRL管理装置120から外部に送出されることなく、共有フォルダ管理装置300は属性証明書及び属性情報に対する有効性の検証ができる。このため、例えばACRLが外部に送出され改竄されること等を防止することができる。
以上、本発明の好適な実施形態について説明したが、本発明は上記実施形態に限定されないことは言うまでもない。
例えば、上記実施形態においては、説明を簡略にするために、各装置間でのデータの送受信に際して暗号化することを省略しているが、実際のシステムの構成においては、各装置間で暗号化されたデータが送受信される。この場合には、例えば公開鍵を発行する認証局(CA)に設置される公開鍵管理装置等を更に設けても良い。
また、例えば、上記実施形態においては、属性証明書のシリアル番号と、属性情報の属性名と、属性情報が更新された場合にはその内容とを1つのACRLにまとめて格納しているが、それぞれを別々のリストとして格納しても良い。このとき、ACRL管理装置120は、例えば、失効した属性証明書のリストである本体ACRL、失効した属性情報のリストである部分失効ACRL、更新された属性情報のリストである部分再発行ACRL等をそれぞれ別々に格納することができる。
また、例えば、上記第2実施形態においては、共有フォルダ管理装置300は、有効性検証要求信号として属性証明書をACRL管理装置120に送信しているが、属性証明書そのものを送信せずに、属性証明書を特定する情報(例えばシリアル番号)及び該属性証明書に含まれた属性情報を特定する情報(例えば属性名)だけを送信するようにしても良い。この場合には、属性証明書が通信網上で送出される回数が少なくなるため、例えば属性証明書が外部装置によって改竄されること等を防止することができる。
1…課金情報検証システム、2…アクセス情報検証システム、10…属性証明書管理装置、110…属性証明書発行装置、120…ACRL管理装置、121…ACRL生成部、122…ACRL格納部、123…ACRL要求受信部、124…ACRL要求応答部、125…有効性検証要求受信部、126…第2有効性検証部、127…検証結果送信部、20…ユーザ端末、200…社員端末、30…サーバ、300…共有フォルダ管理装置、31…サービス要求受信部、32…ACRL要求部、33…ACRL受信部、34…第1有効性検証部、35…属性情報取得部、36…サービス提供部、37…有効性検証要求部、38…検証結果受信部、40,50…通信網。