図1は、本発明の一実施形態である通信システム100の概略図である。図示するように、通信システム100は、第一利用者装置1と、第二利用者装置2と、第一認証局装置3Aと、第二認証局装置3Bと、サービス提供装置4と、ユーザ情報管理装置5と、提供側証明書検証装置6と、第一証明書検証装置7Aと、第二証明書検証装置7Bと、を備え、これらは、ネットワーク8を介して、相互に情報を送受信することができるようにされている。
図2は、第一利用者装置1の概略図である。図示するように、第一利用者装置1は、記憶部101と、制御部102と、入力部108と、出力部109と、通信部110と、利用者認証用デバイス入出力部111と、を備える。
記憶部101には、第一利用者装置1での処理に必要な情報が記憶される。
制御部102は、全体制御部103と、サービス利用部104と、利用者認証用デバイス制御部105と、第一利用者装置用認証部106と、を備える。
全体制御部103は、第一利用者装置1での処理の全体を制御する。例えば、本実施形態においては、ファイル管理、プロセス管理、デバイス管理といった処理を行う。
サービス利用部104は、ネットワーク8を介して、サービス提供装置4より、サービスの提供を受ける処理を制御する。例えば、本実施形態においては、サービスはWebで提供されるものとして説明を行うが、本発明はWebの形態に限定されるものではない。この場合、サービス利用部104は、Webブラウザを用いて処理を行い、ネットワーク上のWebサーバに公開されたHTMLファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生等を行い、また、フォームを使用してユーザがデータをWebサーバに送信することや、Java等で記述されたプログラムを動作させることも可能である。また、SSLもしくはTLS通信を行うために必要な暗号処理を行う機能と鍵及び利用者証明書を管理する処理も行う。
利用者認証用デバイス制御部105は、後述する利用者認証用デバイス入出力部111を介して、図4(利用者認証用デバイス120の概略図)に示すような利用者認証用デバイス120との間で情報を入出力する処理を制御する。
第一利用者装置用認証部106は、第一利用者装置1における認証処理を制御する。例えば、第一利用者装置用認証部106は、利用者用認証デバイス120との間で情報の送受信を行い、サービス利用時の認証に必要な電子署名データや利用者証明書を取得し、サービス利用部104に出力する。
入力部108は、情報の入力を受け付ける。
出力部109は、情報を出力する。
通信部110は、ネットワーク8を介した情報の送受信を行う。
利用者認証用デバイス入出力部111は、図4に示すような利用者認証用デバイス120との間で情報を入出力する。
以上に記載した第一利用者装置1は、例えば、図3(コンピュータ180の概略図)に示すような、CPU(Central Processing Unit)181と、メモリ182と、HDD(Hard Disk Drive)等の外部記憶装置183と、CD(Compact Disk)やDVD(Digital Versatile Disk)等の可搬性を有する記憶媒体184に対して情報を読み書きする読書装置185と、キーボードやマウスなどの入力装置186と、ディスプレイなどの出力装置187と、通信ネットワークに接続するためのNIC(Network Interface Card)等の通信装置188と、を備えた一般的なコンピュータ180に、ICカード等の記憶媒体に対して情報を読み書きするリーダライタ184を接続することにより実現できる。
例えば、記憶部101は、CPU181がメモリ182又は外部記憶装置183を利用することにより実現可能であり、制御部102は、外部記憶装置183に記憶されている所定のプログラムをメモリ182にロードしてCPU181で実行することで実現可能であり、入力部108は、CPU181が入力装置186を利用することで実現可能であり、出力部109は、CPU181が出力装置187を利用することで実現可能であり、通信部110は、CPU181が通信装置188を利用することで実現可能であり、利用者認証用デバイス111は、CPU181がリーダライタ189を利用することにより実現可能である。
この所定のプログラムは、読書装置185を介して記憶媒体184から、あるいは、通信装置188を介してネットワークから、外部記憶装置183にダウンロードされ、それから、メモリ182上にロードされてCPU181により実行されるようにしてもよい。また、読書装置185を介して記憶媒体184から、あるいは、通信装置188を介してネットワークから、メモリ182上に直接ロードされ、CPU181により実行されるようにしてもよい。
図4は、利用者認証用デバイス120の概略図である。図示するように利用者認証用デバイス120は、記憶部121と、制御部125と、I/F部129と、を備える。
記憶部121は、第一利用者秘密鍵記憶領域122と、第一利用者証明書記憶領域123と、を備える。
第一利用者秘密鍵記憶領域122には、後述する第一利用者証明書記憶領域123に記憶されている利用者証明書に含まれる公開鍵とペアとなる秘密鍵を特定する情報が記憶される。ここで、本実施形態においては、第一利用者秘密鍵記憶領域122には、後述する第一認証局装置3Aにおいて生成された秘密鍵が記憶される。
第一利用者証明書記憶領域123には、第一利用者秘密鍵記憶領域122に記憶されている秘密鍵とペアとなる公開鍵を含む利用者証明書を特定する情報が記憶される。ここで、本実施形態においては、第一利用者証明書記憶領域123には、後述する第一認証局装置3Aにおいて発行された利用者証明書が記憶される。例えば、利用者証明書は、利用者の公開鍵と利用者を識別するための情報が記載されており、これらの情報を署名対象範囲として、認証局の秘密鍵を用いて電子署名が付与されたデータである。
制御部125は、全体制御部126と、デバイス用認証部127と、備える。
全体制御部126は、利用者認証用デバイス120での処理の全体を制御する。
デバイス用認証部127は、I/F部129を介して、第一利用者装置1より電子署名データの生成要求を受けると、第一利用者秘密鍵記憶領域122に記憶されている秘密鍵を用いて電子署名を生成し、I/F部129を介して、第一利用者装置1より利用者証明書の出力要求を受けると、第一利用者証明書記憶領域123に記憶されている利用者証明書を出力する処理を行う。
I/F部129は、第一利用者装置1の利用者認証用デバイス入出力部111との間で情報を入出力する。
以上に記載した利用者認証用デバイス120は、図5(ICカード190の概略図)に示すような、CPU192及び外部記憶装置193を有するICユニット191と、データを送受信するためのインタフェースであるI/F195と、を備えるICカード190で実現可能である。
例えば、制御部125は、ICユニット191のCPU192により実現可能であり、記憶部121は、ICユニット191のCPU192が外部記憶装置193を利用することにより実現可能であり、I/F部129は、ICユニット191のCPU192がI/F195を利用することにより実現可能である。
図6は、第二利用者装置2の概略図である。図示するように、第二利用者装置2は、記憶部201と、制御部205と、入力部210と、出力部211と、無線通信部212と、を備える。
記憶部201は、第二利用者秘密鍵記憶領域202と、第二利用者証明書記憶領域203と、を備える。
第二利用者秘密鍵記憶領域202には、後述する第二利用者証明書記憶領域203に記憶されている利用者証明書に含まれる公開鍵とペアとなる秘密鍵を特定する情報が記憶される。ここで、本実施形態においては、第二利用者秘密鍵記憶領域202には、後述する第二認証局装置3Bにおいて生成された秘密鍵が記憶される。
第二利用者証明書記憶領域203には、第二利用者秘密鍵記憶領域202に記憶されている秘密鍵とペアとなる公開鍵を含む利用者証明書を特定する情報が記憶される。ここで、本実施形態においては、第二利用者証明書記憶領域203には、後述する第二認証局装置3Bにおいて発行された利用者証明書が記憶される。
制御部205は、全体制御部206と、サービス利用部207と、第二利用者装置用認証部208と、を備える。
全体制御部206は、第二利用者装置2での処理の全体を制御する。例えば、本実施形態においては、ファイル管理、プロセス管理、デバイス管理といった処理を行う。
サービス利用部207は、ネットワーク8を介して、サービス提供装置4より、サービスの提供を受ける処理を制御する。例えば、本実施形態においては、サービスはWebで提供されるものとして説明を行うが、本発明はWebの形態に限定されるものではない。この場合、サービス利用部207は、Webブラウザを用いて処理を行い、ネットワーク上のWebサーバに公開されたHTMLファイル、画像ファイル、音楽ファイル等をダウンロードし、レイアウトを解析して表示あるいは再生等を行い、また、フォームを使用してユーザがデータをWebサーバに送信することや、Java等で記述されたプログラムを動作させることも可能である。また、SSLもしくはTLS通信を行うために必要な暗号処理を行う機能と鍵及び利用者証明書を管理する処理も行う。
第二利用者装置用認証部108は、第二利用者装置2における認証処理を制御する。例えば、本実施形態においては、第二利用者秘密鍵記憶領域202に記憶されている秘密鍵を用いて電子署名を生成し、また、第二利用者証明書記憶領域203に記憶されている利用者証明書をサービス利用部207に出力する処理を行う。
入力部210は、情報の入力を受け付ける。
出力部211は、情報を出力する。
無線通信部212は、無線を介してネットワーク8に接続し、情報の送受信を行う。
以上に記載した第二利用者装置2は、例えば、図7(携帯電話端末290の概略図)に示すような、CPU291と、メモリ292と、外部記憶装置293と、キーデバイス等の入力装置294と、ディスプレイ等の出力装置295と、RF(Radio Frequency)部、BB(Base Band)部及びMAC(Media Access Controller)部を備える無線通信装置296と、アンテナ297と、を備えた一般的な携帯電話端末290により実現できる。
例えば、記憶部201は、CPU291がメモリ292又は外部記憶装置293を利用することにより実現可能であり、制御部205は、外部記憶装置293に記憶されている所定のプログラムをメモリ292にロードしてCPU291で実行することで実現可能であり、入力部218は、CPU291が入力装置294を利用することで実現可能であり、出力部211は、CPU291が出力装置295を利用することで実現可能であり、無線通信部212は、CPU291が無線通信装置296及びアンテナ297を利用することで実現可能である。
この所定のプログラムは、無線通信装置296を介してネットワークから、外部記憶装置293にダウンロードされ、それから、メモリ292上にロードされてCPU291により実行されるようにしてもよい。また、無線通信装置296を介してネットワークから、メモリ292上に直接ロードされ、CPU291により実行されるようにしてもよい。
図1に戻り、第一認証局装置3A及び第二認証局装置3Bは、利用者の電子証明書を発行する。ここで、第一認証局装置3Aが発行する電子証明書のドメインをドメインA、第二認証局装置3Bが発行する電子証明書のドメインをドメインBとして説明する。
なお、ドメインAとドメインBは相互認証を行っておらず、電子証明書の検証時に構成される認証パスは互いに独立であるものとする。ここで、サービス提供装置4を介してサービスを提供するサービス提供者にとって信頼度の高い電子証明書をドメインAとし、信頼度の高くない電子証明書をドメインBとする。そして、本実施形態では、ドメインAの電子証明書は、ICカード等のセキュアなデバイスに格納され、PC等のコンピュータを用いて利用されるものとして説明する。また、ドメインBの電子証明書は、携帯電話端末に接続されたICチップに格納され、携帯電話端末を用いて利用されるものとする。
ここで、第一認証局装置3A及び第二認証局装置3Bは、同様の機能構成を有するため、これらの機能構成を、図8(認証局装置3の概略図)を用いて説明する。
図8は、認証局装置3の概略図である。図示するように、認証局装置3は、記憶部301と、制御部307と、入力部312と、出力部313と、通信部314と、を備える。
記憶部301は、認証局秘密鍵記憶領域302と、認証局証明書記憶領域303と、利用者証明書記憶領域304と、証明書失効情報記憶領域305と、を備える。
認証局秘密鍵記憶領域302には、認証局3の所有する秘密鍵である認証局秘密鍵を特定する情報が記憶される。
なお、認証局秘密鍵は、利用者証明書(公開鍵証明書)を発行する際に認証局装置3の電子署名の付与に用いる暗号鍵である。認証局秘密鍵は、それぞれのドメインの認証局が所有する秘密鍵情報であり、各ドメインの認証局内で安全に管理される。なお、本実施形態においては、認証局装置3の記憶部301の内部で管理するものとしているが、ハードウェアセキュリティモジュール等の耐タンパ性を有する専用の装置を用いて管理してもよい。
認証局証明書記憶領域303には、認証局秘密鍵記憶領域302に記憶された認証局秘密鍵に対応した認証局3の公開鍵証明書である認証局証明書を特定する情報が記憶される。
なお、認証局証明書は、認証局3が自身に対して発行した自己署名の公開鍵証明書である。当該公開鍵証明書に記載された公開鍵と、認証局秘密鍵と、は一対の鍵ペアをなすものである。
利用者証明書記憶領域304には、利用者に発行した電子証明書である利用者証明書を特定する情報が記憶される。
証明書失効情報記憶領域305には、認証局3が発行した利用者証明書に関する失効情報を特定する情報が記憶される。
なお、証明書失効情報は、利用者証明書(公開鍵証明書)が失効しているかどうかを確認するために用いられる情報である。証明書失効情報は、証明書失効リスト(CRL)等が該当する。
また、本実施形態においては、認証局秘密鍵、認証局証明書、証明書失効情報は、ドメイン毎に別々の認証局装置3で取り扱われるものとする。
制御部307は、全体制御部308と、認証処理部309と、失効情報提供部310と、を備える。
全体制御部308は、認証局装置3での処理の全体を制御する。例えば、本実施形態においては、ファイル管理、プロセス管理、デバイス管理といった処理を制御する。
認証処理部309は、認証局装置3での認証処理を制御する。例えば、本実施形態においては、ある利用者に関して、当該利用者の識別名と利用者の所有する公開鍵とを結びつけ、この結びつけた情報に対し認証局秘密鍵を用いて電子署名を施した利用者証明書(公開鍵証明書)を発行する処理を行う。
また、認証処理部309は、認証局装置3が発行した利用者証明書の管理を行い、さらに、認証局装置3が発行した利用者証明書(公開鍵証明書)に関して、失効した利用者証明書(公開鍵証明書)の情報の一覧に、認証局装置3の認証局秘密鍵を用いて電子署名を施した証明書失効情報の生成等も行う。
また、本実施形態においては、認証処理部309は、ルート証明書となる認証局証明書と、利用者証明書と、を発行するものとする。
なお、本実施形態においては、認証局の証明書と利用者の証明書という2階層で説明を行うが、認証局の階層構造は3階層以上であってもよく、本実施形態での説明に限定されるものではない。
失効情報提供部310は、認証処理部309で生成された証明書失効情報を、通信部314を介して提供する処理を制御する。例えば、失効情報提供部310は、公開鍵証明書を検証するものからの要求に応じて、通信部314を介して、証明書失効情報を送信する。
例えば、失効情報提供部310は、LDAPサーバ等の機能を有する。なお、本実施形態においては、証明書失効情報は、証明書失効リスト(CRL)であるとして説明を行うが、このような態様に限定されず、失効情報提供部310は、オンライン証明書ステータスプロトコル(OCSP)のように、証明書の有効性確認に関する要求を受け付け、要求に応じて応答を返信するような処理を行ってもよい。
入力部312は、情報の入力を受け付ける。
出力部313は、情報を出力する。
通信部314は、ネットワーク8を介した情報の送受信を行う。
以上に記載した認証局装置3は、例えば、図9(コンピュータ390の概略図)に示すような、CPU391と、メモリ392と、HDD等の外部記憶装置393と、CDやDVD等の可搬性を有する記憶媒体394に対して情報を読み書きする読書装置395と、キーボードやマウスなどの入力装置396と、ディスプレイなどの出力装置397と、通信ネットワークに接続するためのNIC等の通信装置398と、を備えた一般的なコンピュータ390で実現できる。
例えば、記憶部301は、CPU391がメモリ392又は外部記憶装置393を利用することにより実現可能であり、制御部307は、外部記憶装置393に記憶されている所定のプログラムをメモリ392にロードしてCPU391で実行することで実現可能であり、入力部312は、CPU391が入力装置396を利用することで実現可能であり、出力部313は、CPU391が出力装置397を利用することで実現可能であり、通信部314は、CPU391が通信装置398を利用することで実現可能である。
この所定のプログラムは、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、外部記憶装置393にダウンロードされ、それから、メモリ392上にロードされてCPU391により実行されるようにしてもよい。また、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、メモリ392上に直接ロードされ、CPU391により実行されるようにしてもよい。
図10は、サービス提供装置4の概略図である。図示するように、サービス提供装置4は、記憶部401と、制御部405と、通信部410と、を有する。
記憶部401は、認証局証明書記憶領域402と、アクセス制御ポリシー情報記憶領域403と、を備える。
認証局証明書記憶領域402には、利用者証明書の署名検証に必要な全ての認証局証明書が記憶される。
アクセス制御ポリシー情報記憶領域403には、サービス提供装置4において提供する各々のサービスに対するアクセス権を特定する情報が記憶される。例えば、サービスの各URIと利用者もしくは当該利用者の属性に応じて、アクセス可否を決めたアクセスコントロールリスト等が記憶される。
制御部405は、全体制御部406と、サービス提供部407と、認証連携処理部408と、を備える。
全体制御部406は、サービス提供装置4での処理の全体を制御する。例えば、本実施形態においては、ファイル管理、プロセス管理、デバイス管理といった処理を制御する。
サービス提供部407は、ネットワーク8を介して、利用者にサービスを提供する処理を制御する。例えば、WebサーバプログラムとWebアプリケーションプログラム等で構成される。
認証連携処理部408は、利用者がサービス提供プログラムにアクセスしてきた際に、利用者に認証に必要な情報の要求を行い、利用者側から送信された電子署名データや利用者証明書を提供側証明書検証装置6等に検証依頼する処理や、複数の電子証明書を関連付けする処理を制御する。
通信部410は、ネットワーク8を介した情報の送受信を行う。
以上に記載したサービス提供装置4は、例えば、図9に示すような一般的なコンピュータ390で実現できる。
例えば、記憶部401は、CPU391がメモリ392又は外部記憶装置393を利用することにより実現可能であり、制御部405は、外部記憶装置393に記憶されている所定のプログラムをメモリ392にロードしてCPU391で実行することで実現可能であり、通信部410は、CPU391が通信装置398を利用することで実現可能である。
この所定のプログラムは、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、外部記憶装置393にダウンロードされ、それから、メモリ392上にロードされてCPU391により実行されるようにしてもよい。また、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、メモリ392上に直接ロードされ、CPU391により実行されるようにしてもよい。
図11は、ユーザ情報管理装置5の概略図である。図示するように、ユーザ情報管理装置5は、記憶部501と、制御部504と、通信部508と、を備える。
記憶部501は、ユーザ情報記憶領域502を備える。
ユーザ情報記憶領域502には、サービス提供装置4が提供するサービスの利用者毎に、当該利用者の利用者証明書と、当該利用者証明書を連携先とする他の利用者証明書と、を特定するユーザ情報が記憶される。例えば、本実施形態においては、図12(ユーザ情報テーブル502aの概略図)に示すようなユーザ情報テーブル502aが記憶される。
図示するように、ユーザ情報テーブル502aは、登録IDフィールド502bと、個人情報フィールド502cと、被連携証明書格納領域502dと、連携証明書格納領域502eと、通知先フィールド502nと、認証コードフィールド502oと、登録日時フィールド502pと、状態フラグフィールド502qと、を有する。
登録IDフィールド502bには、サービス提供装置4が提供するサービスの利用者を特定する情報が格納される。ここで、本実施形態においては、サービスの利用者を特定する情報として、利用者に一意となるように割り振られた登録IDが格納される。
個人情報フィールド502cには、登録IDフィールド502bで特定される利用者の属性情報が格納される。ここで、本実施形態においては、利用者の属性情報として、氏名、住所、生年月日、性別等が格納される。
被連携証明書格納領域502dには、他の利用者証明書が連携付けられる利用者証明書を特定する情報が格納される。ここで、本実施形態においては、サービス提供装置4を用いてサービスを提供するサービス提供者が高い信頼を置くドメインAの利用者証明書(第一認証局装置3Aが提供する利用者証明書)を特定する情報が格納される。
ここで、被連携証明書格納領域502dは、利用者証明書フィールド502fと、発行者名フィールド502gと、シリアル番号フィールド502hと、所有者名フィールド502iと、を有する。
利用者証明書フィールド502fには、ドメインAの利用者証明書(第一認証局装置3Aが提供する利用者証明書)を特定する情報が格納される。
発行者名フィールド502gには、利用者証明書フィールド502fに格納された利用者証明書から抽出された利用者証明書の発行者名を特定する情報が格納される。
シリアル番号フィールド502hには、利用者証明書フィールド502fに格納された利用者証明書から抽出された利用者証明書のシリアル番号を特定する情報が格納される。
所有者名フィールド502iには、利用者証明書フィールド502fに格納された利用者証明書から抽出された利用者証明書の所有者を特定する情報が格納される。
連携証明書格納領域502eには、被連携証明書格納領域502dで特定される利用者証明書を連携先とする利用者証明書を特定する情報が格納される。ここで、連携証明書格納領域502eには、被連携証明書格納領域502dで特定される利用者証明書を連携先とする少なくとも一つ以上の利用者証明書を特定する情報が格納されるが、本実施形態においては、サービス提供装置4を用いてサービスを提供するサービス提供者があまり高い信頼をおいていないドメインBの利用者証明書(第二認証局装置3Bが提供する利用者証明書)を特定する情報が格納される。
ここで、連携証明書格納領域502eには、利用者証明書フィールド502jと、発行者名フィールド502kと、シリアル番号フィールド502lと、所有者名フィールド502mと、が被連携証明書格納領域502dで特定される利用者証明書を連携先とする利用者証明書の数に応じて設けられる。
利用者証明書フィールド502jには、被連携証明書格納領域502dで特定される利用者証明書を連携先とする利用者証明書(ここでは、ドメインBの利用者証明書)を特定する情報が格納される。
発行者名フィールド502kには、利用者証明書フィールド502jに格納された利用者証明書から抽出された利用者証明書の発行者名を特定する情報が格納される。
シリアル番号フィールド502lには、利用者証明書フィールド502jに格納された利用者証明書から抽出された利用者証明書のシリアル番号を特定する情報が格納される。
所有者名フィールド502mには、利用者証明書フィールド502jに格納された利用者証明書から抽出された利用者証明書の所有者を特定する情報が格納される。
通知先フィールド502nには、登録IDフィールド502bで特定される利用者に対して、本登録の依頼を行うためのURL等を通知する際の通信アドレスを特定する情報が格納される。ここで、本実施形態においては、登録IDフィールド502bで特定される利用者が利用する第二利用者装置2のメールアドレスが格納される。
認証コードフィールド502oには、登録IDフィールド502bで特定される利用者が、ドメインAの利用者証明書の関連付けの変更を行う際に使用する認証コードを特定する情報が格納される。ここで、認証コードは、どの利用者証明書に関連付いていたかを一意に特定するための情報であり、他の行の認証コードの値とはほぼ衝突することのない値を使用する。例えば、認証コードとしては、乱数やハッシュ値などを用いる。
登録日時フィールド502pには、被連携証明書格納領域502dに情報の登録が行われた年月日時刻特定する情報が格納される。
状態フラグフィールド502qには、登録IDフィールド502bで特定される利用者の登録の状態を示す情報が格納される。ここで、本実施形態においては、登録の状態を示す情報として、被連携証明書格納領域502dに利用者証明書を登録し、未だ、連携証明書格納領域502eに利用者証明書の登録を行っていないことを示す「仮登録」、「仮登録」後に、登録IDフィールド502bで特定される利用者に本登録の依頼通知を行い、未だ、連携証明書格納領域502eに利用者証明書の登録を行っていないことを示す「未検証」、登録IDフィールド502bで特定される利用者が連携証明書格納領域502eに利用者証明書の登録を行ったことを示す「本登録」、「本登録」の状態において被連携証明書格納領域502dに格納された利用者証明書が無効であることを示す「A無効」、「本登録」の状態において連携証明書格納領域502eに格納された利用者証明書が無効であることを示す「B無効」、といった5つのステータスを持つものとするが、ステータスの内容については本実施形態に限定されるものではない。また、「本登録」の状態は、利用者証明書の関連付けが有効な状態であることを示している。
以上のようなデータ構造を持たせることにより、同一の利用者が使用する複数の利用者証明書の関連付けを行う。
通信部508は、ネットワーク8を介して情報の送受信を行う。
以上に記載したユーザ情報管理装置5は、例えば、図9に示すような一般的なコンピュータ390で実現できる。
例えば、記憶部501は、CPU391がメモリ392又は外部記憶装置393を利用することにより実現可能であり、制御部504は、外部記憶装置393に記憶されている所定のプログラムをメモリ392にロードしてCPU391で実行することで実現可能であり、通信部508は、CPU391が通信装置398を利用することで実現可能である。
この所定のプログラムは、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、外部記憶装置393にダウンロードされ、それから、メモリ392上にロードされてCPU391により実行されるようにしてもよい。また、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、メモリ392上に直接ロードされ、CPU391により実行されるようにしてもよい。
図13は、提供側証明書検証装置6の概略図である。図示するように、提供側証明書検証装置6は、記憶部601と、制御部605と、通信部610と、を備える。
記憶部601は、検証アクセス先情報記憶領域602と、認証局証明書情報記憶領域603と、を備える。
検証アクセス先情報記憶領域602には、利用者証明書の正当性の検証を要求するための証明書検証装置(本実施形態では、第一証明書検証装置7A又は第二証明書検証装置7B)のURI、または、利用者証明書の有効性を確認するための問い合わせ先のURI等を特定する情報が、利用者証明書の発行者別に記憶されている。
認証局証明書情報記憶領域603には、利用者証明書の検証を行うために必要な認証局の認証局証明書を特定する情報が記憶される。
制御部605は、全体制御部606と、証明書検証部607と、追加検証部608と、を備える。
全体制御部606は、提供側証明書検証装置6における処理の全体を制御する。例えば、本実施形態においては、ファイル管理、プロセス管理、デバイス管理といった処理を制御する。
証明書検証部607は、他の装置及び追加検証部608からの要求に応じて、利用者証明書の正当性を検証し、その結果を応答する処理を制御する。ここで、利用者証明書の正当性の検証とは、検証を要求された証明書の認証パスを構築、検証し、当該利用者証明書の有効性確認を行うことである。
さらに、証明書検証部607は、特定のドメインの証明書検証装置(本実施形態では、第一証明書検証装置7A及び第二証明書検証装置7B)が存在し、当該証明書検証装置に検証を依頼する設定になっている場合には、特定のドメインの利用者証明書の正当性の検証を当該証明書検証装置に依頼し、検証結果を応答として受け付ける処理を制御する。
追加検証部608は、証明書検証部607で検証の要求を受け付けた利用者証明書が連携付けられている別の利用者証明書の正当性の検証を行う処理を制御する。
通信部610は、ネットワーク8を介した情報の送受信を行う。
以上に記載した提供側証明書検証装置6は、例えば、図9に示すような一般的なコンピュータ390で実現できる。
例えば、記憶部601は、CPU391がメモリ392又は外部記憶装置393を利用することにより実現可能であり、制御部605は、外部記憶装置393に記憶されている所定のプログラムをメモリ392にロードしてCPU391で実行することで実現可能であり、通信部610は、CPU391が通信装置398を利用することで実現可能である。
この所定のプログラムは、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、外部記憶装置393にダウンロードされ、それから、メモリ392上にロードされてCPU391により実行されるようにしてもよい。また、読書装置395を介して記憶媒体394から、あるいは、通信装置398を介してネットワークから、メモリ392上に直接ロードされ、CPU391により実行されるようにしてもよい。
第一証明書検証装置7Aは、他の装置からの要求に応じて、第一認証局装置3Aが発行した利用者証明書(ドメインAの利用者証明書)の検証を行い、第二証明書検証装置7Bは、他の装置からの要求に応じて、第二認証局装置3Bが発行した利用者証明書(ドメインBの利用者証明書)の検証を行う。
なお、第一証明書検証装置7A及び第二証明書検証装置7Bは、公開鍵証明書の検証を行う公知の検証サーバで実現可能であるため、詳細な説明は省略する。
図14及び図15は、利用者証明書の登録処理を示すシーケンス図である。
利用者証明書の登録を行う際の前提として、利用者は、ドメインAの第一認証局装置3A、および、ドメインBの第二認証局装置3Bより利用者証明書392の発行を受けているものとする。また、本実施形態では、第一利用者装置1及び第二利用者装置2は、利用者が所有しているものとして説明を行うが、第一利用者装置1及び第二利用者装置2自体は、サービス提供者側の窓口端末でもよく、利用者認証用デバイス120を利用者が所有する形態でもよい。
まず、第一利用者装置1のサービス利用部104は、入力部108を介して、サービス提供装置4が提供するサービスの利用登録を行うためのURLの入力を受け付け、通信部110を介して、サービス提供装置4にユーザ登録要求を送信する(S10)。
次に、サービス提供装置4は、第一利用者装置1が送信したユーザ登録要求を、通信部410を介して、サービス提供部407が受信する(S11)。
続いて、サービス提供装置4のサービス提供部407は、利用者の登録を行うために必要なユーザ登録画面データを第一利用者装置1に送信する(S12)。
第一利用者装置1では、ステップS12にて送信されたユーザ登録画面データを、通信部110を介して、サービス利用部104が受信し、出力部109に表示する(S13)。
次に、第一利用者装置1は、入力部108を介して、利用者から登録に必要な情報の入力を受け付ける(S14)。入力を受け付ける情報は、図12に示すユーザ情報テーブル502aの個人情報フィールド502cに格納する利用者の属性情報や本登録要求の通知先(本実施形態では、第二利用者装置2のメールアドレス)等である。
次に、サービス利用部104は、入力された情報を署名対象として、ドメインAの秘密鍵を用いて電子署名データを生成する。そして、サービス利用部104は、通信部110を介して、ステップS14において入力を受け付けたユーザ情報と、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応するドメインAの利用者証明書と、をサービス提供装置4に送信する(S15)。
ここで、電子署名データの生成にあたっては、サービス利用部104が、第一利用者装置用認証部106及び利用者認証用デバイス制御部105を介して、利用者認証用デバイス120のデバイス用認証部127に電子署名データの生成を要求することで、デバイス用認証部127が、電子署名データを生成した後、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応するドメインAの利用者証明書と、を第一利用者装置1のサービス利用部104に返信する。
次に、サービス提供装置4では、サービス提供部407が、通信部410を介して、第一利用者装置1より送信されたユーザ情報、電子署名データ及びドメインAの利用者証明書を受信する(S16)。
次に、サービス提供装置4は、認証連携処理部408によって、第一利用者装置1から受信した電子署名データの署名検証を、ドメインAの利用者証明書を用いて行う(S17)。ここで、署名の検証に成功した場合は、ステップS19に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信して、ステップS18に進む。
ステップS18では、第一利用者装置1のサービス利用部104は、通信部110を介して受信したエラー画面データを出力部109に表示する。なお、本実施形態においては、ステップS18で処理が終了するが、必要に応じてステップS10に戻り処理を繰り返してもよい。
一方、ステップS19では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、S17で署名の検証に用いた利用者証明書の検証を要求する検証要求メッセージを送信する。ここで、検証要求メッセージには、ユーザ登録要求における検証要求であることを示す要求種別データと、検証の対象である利用者証明書と、が含まれているものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S20)。
次に、提供側証明書検証装置6の証明書検証部607が、ステップS20で受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S21)。なお、ステップS21での検証処理の詳細については、図22を用いて説明する。
さらに、提供側証明書検証装置6の証明書検証部607は、ステップS21の検証結果に応じて、利用者証明書の検証応答メッセージを生成し、通信部610を介して、サービス提供装置4に送信する(S22)。利用者証明書の検証応答メッセージには、利用者証明書の正当性検証の成否が含まれるものとする。
そして、サービス提供装置4の認証連携処理部408は、ステップS22において送信された利用者証明書の検証応答メッセージを受信し、利用者証明書の正当性の検証結果を確認する(S23)。そして、利用者証明書の正当性検証の結果、利用者証明書に問題がないことを確認できた場合にはステップS25に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信する。
ステップS24では、第一利用者装置1のサービス利用部104は、通信部110を介して受信したエラー画面データを、出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS10に戻り処理を繰り返してもよい。
ステップS25では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報の仮登録を要求するユーザ情報仮登録メッセージを送信する。ユーザ情報仮登録要求メッセージには、ユーザ情報仮登録要求メッセージであることを示す識別情報の他、ステップS16において受信したユーザ情報(個人情報や通知先等)、ドメインAの利用者証明書、および、当該利用者証明書から抽出した発行者名、シリアル番号、所有者名等が含まれるものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信したユーザ情報仮登録要求メッセージを受信する(S26)。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS26において受信したユーザ情報仮登録要求メッセージに含まれる情報を、ユーザ情報テーブル502aに格納する(S27)。
ここで、ステップS27では、図12に示すようなユーザ情報テーブル502aに新たなレコードを追加して、追加したレコードに、登録ID、個人情報、利用者証明書、発行者名、シリアル番号、所有者名、通知先、登録日時、登録状態フラグを、各々、登録IDフィールド502b、個人情報フィールド502c、利用者証明書フィールド502f、発行者名フィールド502g、シリアル番号フィールド502h、所有者名フィールド502i、通知先フィールド502n、認証コードフィールド502o、登録日時フィールド502p、および、状態フラグフィールド502q、に格納する。
なお、登録IDフィールド502bには、ユーザ情報テーブル502a内には登録されていない番号が自動的に付与されて格納され、また、登録日時フィールド502pには、ステップS26でユーザ情報仮登録要求メッセージを受信してから現時点までの間の任意の年月日時間が格納され、状態フラグフィールド502qには、「仮登録」のステータスが格納される。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、ユーザ情報の仮登録結果を含めた仮登録結果メッセージを生成し、サービス提供装置4に送信する(S28)。
サービス提供装置4の認証連携処理部408は、通信部410を介して、ステップS28において送信された仮登録結果メッセージを受信し、仮登録の成否を確認する(S29)。その結果、仮登録に成功している場合にはステップS31に進み、仮登録に失敗している場合には、仮登録に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信して、ステップS30に進む。
ステップS30では、第一利用者装置1のサービス利用部104は、通信部410を介して、エラー画面データを受信し、出力部109にエラー画面データを表示する。本実施形態においては本ステップで処理を終了するが、必要に応じてステップS10に戻り処理を繰り返してもよい。
一方、ステップS31では、サービス提供装置4のサービス提供部407は、仮登録に成功した旨を示す仮登録結果画面データを生成し、当該仮登録結果画面データを第一利用者装置1に送信する。
次に、第一利用者装置1のサービス利用部104は、通信部110を介して、仮登録結果画面データを受信し、出力部109に表示する(S32)。そして、図15のシーケンスに進む。
次に、サービス提供装置4のサービス提供部407は、利用者が本登録の手続きを行うためのアクセス先を、第二利用者装置2に送信する(S33)。送信先は、図14のステップS16で受信したユーザ情報に含まれている通知先を使用する。本実施形態においては、通知先を第二利用者装置2に付随するメールアドレスとしているため、サービス提供部407は、第二利用者装置2へのメールの本文に本登録の手続を行うためのアクセス先であるURLを記載して、送信するものとする。
また、そのURLには、登録IDもしくは通知先等、第二利用者装置2の利用者を特定することのできる情報を含むものとする。
さらに、図示してはいないが、ステップS40を行った後、サービス提供装置4のサービス提供部407は、ユーザ情報管理装置5に対して、アクセス先の通知済登録要求メッセージを送信する。アクセス先の通知済登録要求メッセージには、通知済登録要求メッセージであることを示すデータの他、登録ID等が含まれているものとする。
このような通知済み登録要求メッセージを受信したユーザ情報管理装置5では、ユーザ情報管理部506が、通知済登録要求メッセージに含まれる登録IDに対応するユーザ情報テーブル502aのレコードを特定し、特定したレコードの状態フラグフィールド502qを「通知済」のステータスに更新する。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、アクセス先の通知済登録結果を含めた通知済登録結果メッセージを生成し、サービス提供装置4に送信する。
次に、第二利用者装置2は、ステップS33で送信された本登録のアクセス先を、サービス利用部207で受信する(S34)。
そして、第二利用者装置2のサービス利用部207は、出力部211にアクセス先を表示して、入力部210を介して、表示されたアクセス先を選択した実行指示の入力を受け付けることにより、サービス提供装置4にユーザの本登録を行うための本登録要求メッセージを送信する(S35)。なお、ステップS35での処理は、利用者の都合のよいタイミングで実施されるものとし、必ずしも即時に実施される必要はない。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信した本登録要求メッセージを受信する(S36)。
そして、サービス提供装置4のサービス提供部407は、利用者の本登録を行うための認証に必要なドメインBの利用者証明書等を要求する認証要求データを第二利用者装置2に送信する(S37)。例えば、SSL(Secure Socket Layer)あるいはTLS(Transport Layer Security)によるクライアント認証の要求が、ステップS37に相当する。
第二利用者装置2のサービス利用部207は、無線通信部212を介して、ステップS37にて送信された認証要求データを受信する(S38)。
次に、第二利用者装置2は、認証要求に基づき、ドメインBの秘密鍵を用いて電子署名を生成する(S39)。
電子署名の生成にあたっては、サービス利用部207の指示に応じて、第二利用者装置用認証部208が、第二利用者秘密鍵記憶領域202に記憶されている第二利用者秘密鍵を用いて電子署名データを生成する。
そして、第二利用者装置2のサービス利用部207は、ステップS39で使用した第二利用者秘密鍵に対応するドメインBの利用者証明書を第二利用者証明書記憶領域203より抽出し、ステップS39で生成した電子署名データと、抽出した利用者証明書と、サービス提供装置4に送信する(S40)。例えば、SSLあるいはTLSによるクライアント証明書を送信する処理等が本ステップに相当する。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信した電子署名データ、ドメインBの利用者証明書等を受信する(S41)。
そして、サービス提供装置4の認証連携処理部408は、受信した電子署名データの署名検証を、ドメインBの利用者証明書を用いて行う(S42)。ここで、署名の検証に成功した場合はステップS44に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS43に進む。
ステップS43では、第二利用者装置2のサービス利用部207は、送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS35に戻り処理を繰り返してもよい。
一方、ステップS44では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS42で署名の検証に用いた利用者証明書の検証要求メッセージを送信する。この検証要求メッセージには、本登録要求であることを示す要求種別データと、検証の対象となる利用者証明書と、が含まれているものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S45)。
そして、提供側証明書検証装置6の証明書検証部607は、ステップS45において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S46)。本ステップの詳細は、図22を用いて説明する。
さらに、ステップS46の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S47)。利用者証明書の検証応答メッセージには、利用者証明書の正当性検証の成否が含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、ステップS47において送信された利用者証明書の検証応答メッセージを受信し、利用者証明書の正当性の検証結果を確認する(S48)。利用者証明書の正当性検証の結果、利用者証明書に問題がないことを確認できた場合にはステップS50に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、利用者証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS49に進む。
ステップS49では、第二利用者装置2のサービス利用部207は、ステップS48において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS35に戻り処理を繰り返してもよい。
一方、ステップS50では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報の本登録要求メッセージを送信する。ユーザ情報の本登録要求メッセージには、本登録要求メッセージであることを示すデータの他、ステップS41において受信したドメインBの利用者証明書、および、当該利用者証明書から抽出した発行者名、シリアル番号、所有者名等が含まれているものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信してきたユーザ情報の本登録要求メッセージを受信する(S51)。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS51において受信した登録要求メッセージに含まれる情報に基づいて、ユーザ情報テーブル502を更新する(S52)。例えば、ユーザ情報管理部506は、ユーザ情報テーブル502の登録IDフィールド502bに対して、送信された登録IDを検索キーとして検索を実行し、当該登録IDが格納されているレコードを特定し、特定したレコードの利用者証明書フィールド502j、発行者名フィールド502k、シリアル番号フィールド502l、および、所有者名フィールド502m、にステップS51で受信した情報を格納し、状態フラグフィールド502qは「本登録」のステータスに更新する。
なお、本登録しようとしているドメインBの利用者証明書が、既に別のドメインAの利用者証明書に関連付けされている場合には、登録に失敗するようにする。
さらに、ステップS52を実行した後、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の本登録結果を含めた本登録結果メッセージを生成し、サービス提供装置4に送信する(S53)。
サービス提供装置4の認証連携処理部408は、通信部410を介して、ステップS53において送信された本登録結果メッセージを受信し、本登録の成否を確認する(S54)。その結果、本登録に成功した場合にはステップS56に進み、本登録に失敗した場合は、本登録に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS55に進む。
ステップS55では、第二利用者装置2のサービス利用部207は、ステップS54において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS35に戻り処理を繰り返してもよい。
一方、ステップS56では、サービス提供装置4のサービス提供部407は、本登録に成功した旨を示す本登録結果画面データを生成し、当該本登録結果画面データを第二利用者装置2に送信する(S56)。
次に、第二利用者装置2のサービス利用部207は、無線通信部212を介して、ステップS56において送信された本登録結果画面データを受信し、出力部211に表示する(S57)。
次に、以上のように、図14及び図15に示す手順を実施することにより、サービス提供者にとって信頼度の高い利用者証明書と信頼度の低い利用者証明書との関連付けが完了する。なお、本実施形態においては、関連付けのことを連携と表現する場合もある。
図16は、サービス利用時の認証処理を示すシーケンス図である。
ここでは、第二利用者装置2を用いる例を示しているが、第一利用者装置1を用いる場合も同様である。また、サービスを利用する前提として、利用者は図14及び図15に示す利用者証明書の登録処理を行っているものとする。
まず、第二利用者装置2のサービス利用部207は、入力部210を介して、サービス提供装置4が提供するサービスを利用するためのURLの入力を受け付け、サービス提供装置4にサービス要求メッセージを送信する(S60)。
サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信したサービス要求メッセージを受信する(S61)。
次に、サービス提供装置4のサービス提供部407は、サービス利用時の認証に必要な利用者証明書等を要求する認証要求データを第二利用者装置2に送信する(S62)。
次に、第二利用者装置2のサービス利用部207は、無線通信部212を介して、ステップS62にて送信された認証要求データを受信する(S63)。
次に、第二利用者装置2のサービス利用部207は、第二利用者装置用認証部208に指示を出して、第二利用者装置用認証部208が、認証要求に基づき、第二利用者秘密鍵記憶領域202に記憶されているドメインBの秘密鍵を用いて電子署名データを生成する(S64)。例えば、SSLあるいはTLSによるクライアント認証のために必要なクライアント側の処理が本ステップに相当する。
次に、第二利用者装置2のサービス利用部207は、ステップS64において生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、サービス提供装置4に送信する(S65)。例えば、SSLあるいはTLSによるクライアント証明書を送信する処理等が本ステップに相当する。
そして、サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信した電子署名データ及び利用者証明書等を受信する(S66)。
次に、サービス提供装置4の認証連携処理部408は、第二利用者装置2から受信した電子署名データの署名検証を、一緒に受信した利用者証明書を用いて行う(S67)。ここで、署名の検証に成功した場合はステップS69に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装2に送信し、ステップS68に進む。
ステップS68では、第二利用者装置2のサービス利用部207は、ステップS67において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS60に戻り処理を繰り返してもよい。
一方、ステップS69では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS67で署名の検証に用いた利用者証明書の検証要求メッセージを送信する。この検証要求メッセージには、サービス要求であることを示す要求種別データと利用者証明書とが含まれているものとする。
提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S70)。
次に、提供側証明書検証装置6の証明書検証部607は、ステップS70において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S71)。本ステップの詳細については、図22を用いて説明する。
そして、ステップS71の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S72)。証明書の検証応答メッセージには、第二利用者証明書2の正当性検証の成否が含まれるものとし、また、ステップS71において信頼度の低い利用者証明書を検証している場合には、図22に従って、当該利用者証明書に関連付けされている信頼度の高い利用者証明書の正当性検証結果も検証応答に含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、ステップS72において送信された証明書の検証応答メッセージを受信し、利用者証明書の正当性の検証結果を確認する(S73)。そして、利用者証明書の正当性検証の結果、証明書に問題がないことを確認できた場合にはステップS75に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、利用者証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS74に進む。
ステップS74では、第二利用者装置2のサービス利用部207は、ステップS73において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS60に戻り処理を繰り返してもよい。
一方、ステップS75では、サービス提供装置4のサービス提供部407は、アクセス制御ポリシー情報記憶領域403に記憶されているアクセス制御ポリシーを参照して、当該利用者証明書の利用者に対するサービスへのアクセス可否を判定する。アクセス判定の結果、当該利用者にアクセス権限があることを確認できた場合にはステップS77に進み、アクセス判定に失敗した場合にはサービスへのアクセス権限がない旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS76に進む。
ステップS76では、第二利用者装置2のサービス利用部207は、ステップS75において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS60に戻り処理を繰り返してもよい。
一方、ステップS77では、サービス提供装置4のサービス提供部407は、サービスの提供を行うためのサービス提供画面データを生成し、当該サービス提供画面データを第二利用者装置2に送信する(S77)。
そして、第二利用者装置2のサービス利用部207は、ステップS77において送信されたサービス提供画面データを出力部211に表示する(S78)。
以上の手順を実施することにより、サービス提供者にとって信頼度の高い認証を行った上で、サービスの提供が可能となる。
図17は、利用者証明書の関連付けの更新処理を示すシーケンス図である。
本シーケンスの前提として、利用者は図14及び図15に示す利用者証明書の登録処理が済んでいるものとする。また、本シーケンスでは、第一利用者装置1を用いて説明しているが、第二利用者装置2でも同様の処理が可能である。
なお、利用者証明書の関連付けの更新が必要な場合としては、利用者証明書の有効期限切れに伴い、当該利用者証明書を発行した認証局と同一の認証局から新たに利用者証明書を発行された場合等が該当する。ここで、利用者証明書の関連付けの更新の対象となる利用者証明書は、ドメインAのものでもドメインBのものでもよいが、古い利用者証明書と新しい利用者証明書において、利用者証明書の発行者名及び所有者名が同一であるものとする。
但し、新旧利用者証明書間において発行者名又は所有者名の少なくとも一部が一致しない場合であっても、証明書の発行者名もしくは所有者名の命名規則により、その他の一致する部分から同一の発行者もしくは所有者であることが判断できる場合には、更新の対象とすることが可能である。
まず、第一利用者装置1のサービス利用部104は、入力部108を介して、サービス提供装置4が提供するサービスにおいて利用者証明書の関連付けを更新するためのURLの入力を受け付け、サービス提供装置4に利用者証明書の関連付けを更新するための証明書更新要求メッセージを送信する(S80)。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信した証明書更新要求メッセージを受信する(S81)。
次に、サービス提供装置4のサービス提供部407は、証明書更新時の認証に必要な利用者証明書等を要求する認証要求データを第一利用者装置1に送信する(S82)。
次に、第一利用者装置1のサービス利用部104は、通信部110を介して、ステップS82で送信された認証要求データを受信する(S83)。
次に、第一利用者装置1は、受信した認証要求データに基づき、利用者の秘密鍵を用いて電子署名を生成する(S84)。例えば、サービス利用部104は、第一利用者装置用認証部106及び利用者認証用デバイス制御部105を介して、利用者認証用デバイス120のデバイス用認証部127に電子署名データの生成を要求する。そして、デバイス用認証部127が、第一利用者秘密鍵記憶領域122に記憶されている利用者の秘密鍵を用いて電子署名データを生成した後、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、を第一利用者装置1のサービス利用部104に返信する。これは、SSLあるいはTLSによるクライアント認証のために必要なクライアント側の処理が本ステップに相当する。
なお、ここで使用する利用者証明書や秘密鍵は、新たに発行された利用者証明書や当該利用者証明書に対応する秘密鍵である。すなわち、関連付けの更新後に使用することを想定している利用者証明書や秘密鍵である。
次に、第一利用者装置1のサービス利用部104は、ステップS84において生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、をサービス提供装置4に送信する(S85)。例えば、SSLあるいはTLSによるクライアント証明書を送信する処理等が本ステップに相当する。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信した電子署名データ、利用者証明書等を受信する(S86)。
次に、サービス提供装置4の認証連携処理部408は、第一利用者装置1から受信した電子署名データの署名検証を、一緒に受信した利用者証明書を用いて行う(S87)。ここで、署名の検証に成功した場合はステップS89に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS88に進む。
ステップS88では、第一利用者装置1のサービス利用部104は、ステップS87において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS80に戻り処理を繰り返してもよい(S88)。
一方、ステップS89では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS87で署名の検証に用いた利用者証明書の検証要求メッセージを送信する(S89)。この検証要求メッセージには、証明書更新要求であることを示す要求種別データと、検証の対象となる利用者証明書と、が含まれるものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S90)。
そして、提供側証明書検証装置6の証明書検証部607は、ステップS90において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S91)。本ステップの詳細については、図22を用いて説明する。
さらに、ステップS91の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S92)。利用者証明書の検証応答メッセージには、利用者証明書の正当性検証の成否を特定する情報が含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、通信部410を介して、ステップS92において送信された利用者証明書の検証応答メッセージを受信し、利用者証明書の正当性の検証結果を確認する(S93)。利用者証明書の正当性検証の結果、利用者証明書に問題がないことを確認できた場合にはステップS95に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、利用者証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS95に進む。
ステップS94では、第一利用者装置1のサービス利用部104は、通信部110を介して、ステップS93において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS80に戻り処理を繰り返してもよい。
一方、ステップS95では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報を検索するための検索要求メッセージを送信する。ユーザ情報の検索要求メッセージには、検索要求メッセージであることを示すデータの他、ステップS86において受信した利用者証明書から抽出した発行者名もしくはその一部(発行者を識別することができる部分)、及び、所有者名もしくはその一部(所有者を識別することができる部分)が含まれているものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信したユーザ情報の検索要求メッセージを受信する(S96)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS96において受信した情報をもとに、ユーザ情報テーブル502aを検索する(S97)。例えば、ユーザ情報管理部506は、ステップS96において受信した利用者証明書の発行者名もしくはその一部がどのドメインに属するものであるかを判断し、ユーザ情報テーブル502aにおいて、該当するドメインの所有者名フィールド502i、502mの列から、受信した所有者名を検索キーに一致するレコードを検索する(S97)。なお、本フローの前提条件に記載したとおり、証明書の命名規則によって所有者名の一部で利用者を一意に特定可能であるものについては、所有者名の一部を検索キーに使用する。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の検索結果を含めた検索結果メッセージを生成し、サービス提供装置4に送信する(S98)。ここで、検索結果メッセージには、該当するレコードが存在した場合には、そのレコードの登録IDフィールド502bに格納されている登録IDを含め、該当するレコードが存在しない場合は、存在しないことを示す旨を示す情報を含めるものとする。
なお、本シーケンスの前提である証明書の関連付けの更新対象の条件からすると、該当するレコードは複数存在しない想定であるため、ステップS97において該当するレコードが複数検索された場合には、本ステップにおいて生成する検索結果としてエラーである旨のメッセージを生成するものとする。
次に、サービス提供装置4の認証連携処理部408は、通信部410を介して、ステップS98において送信された検索結果メッセージを受信し、受信した検索結果メッセージにユーザ情報が含まれているか否かを確認する(S99)。検索結果メッセージにユーザ情報である登録IDが含まれている場合にはステップS101に進み、検索結果からユーザ情報(登録ID)を取得できなかった場合は、更新の対象となる利用者証明書登録が行われていない旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS100に進む。
ステップS100では、第一利用者装置1のサービス利用部104は、ステップS99において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS80に戻り処理を繰り返してもよい。
一方、ステップS101では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報の変更要求メッセージを送信する。ユーザ情報の変更要求メッセージには、変更要求メッセージであることを示すデータの他、ステップS99において取得した登録ID、ステップS86において受信した利用者証明書、さらには当該利用者証明書から抽出した発行者名、シリアル番号、所有者名等が含まれるものとする。また、変更を要求する利用者証明書、発行者名、シリアル番号、所有者名の列については、発行者名から該当するドメインを特定し、変更する列を指定するものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信したユーザ情報の変更要求メッセージを受信する(S102)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS102において受信した情報により、ユーザ情報テーブル502に格納されている情報を更新する(S103)。本ステップでは、受信した情報に含まれる登録IDを検索キーとしてユーザ情報テーブル502のレコードを特定し、特定したレコードに、利用者証明書、発行者名、シリアル番号、所有者名、の情報を更新する。なお、更新する利用者証明書、発行者名、シリアル番号、所有者名のフィールドについては、発行者名から該当するドメインを特定し、特定したドメインに対応するフィールドを特定するものとする。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の変更結果を含めたメッセージを生成し、サービス提供装置4に送信する(S104)。
次に、サービス提供装置4の認証連携処理部408は、ステップS104において送信された変更結果メッセージを受信し、変更の成否を確認する(S105)。変更に成功した場合にはステップS107に進み、変更に失敗した場合は、変更に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS106に進む。
ステップS106では、第一利用者装置1のサービス利用部104は、ステップS105において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS80に戻り処理を繰り返してもよい。
一方、ステップS107では、サービス提供装置4のサービス提供部407は、変更に成功した旨を示す変更結果画面データを生成し、当該画面データを第一利用者装置1に送信する(S107)。
そして、第一利用者装置1のサービス利用部104は、ステップS107において送信された変更結果画面データを出力部109に表示する(S108)。
以上の手順を実施することにより、利用者証明書の関連付けの更新が完了する。なお、本シーケンスでは、ユーザ情報の検索を行ってから(ステップS95〜ステップS100)、ユーザ情報の変更要求メッセージを送信するようにしているが(ステップS101)、ユーザ情報の検索ステップ(ステップS95〜ステップS100)については、スキップすることも可能である。
図18及び図19は、利用者証明書の関連付けの変更処理を示すシーケンス図である。
ここで、本シーケンスの前提として、利用者は図14及び図15に示す利用者証明書の登録処理を済ましているものとする。
また、利用者証明書の関連付けの変更が必要となるのは、利用者証明書の関連付けの更新の条件に該当しない場合であり、例えば、既に登録済みの利用者証明書を発行した認証局とは別の認証局から発行された利用者証明書を関連付ける場合や、利用者証明書の情報に変更があり、利用者証明書の再発行を受け、当該利用者証明書を関連付ける場合等が該当する。
なお、本シーケンスの対象となるのは、信頼度の低い利用者証明書はそのままで、信頼度の高い利用者証明書を変更する場合である。そこで、本実施形態では、ドメインBの利用者証明書に新たなドメインAの利用者証明書を関連付ける場合について説明する。一方、サービス提供者にとって信頼度の高い利用者証明書(ドメインAの利用者証明書)はそのままで、信頼度の低い利用者証明書(ドメインBの利用者証明書)の関連付けを変更する場合は、図20及び図21に示す連携解除のシーケンス及び図14及び図15に示す登録のシーケンスを行うものとする。
まず、第二利用者装置2のサービス利用部104は、入力部210を介して、サービス提供装置4が提供するサービスにおいて利用者証明書の関連付けを変更するためのURLの入力を受け付け、サービス提供装置4に利用者証明書を変更するための証明書連携変更要求メッセージを送信する(S110)。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信した証明書連携変更要求メッセージを受信する(S111)。
次に、サービス提供装置4のサービス提供部407は、証明書連携変更時の認証に必要な利用者証明書等を要求する認証要求データを第二利用者装置2に送信する(S112)。
そして、第二利用者装置2のサービス利用部104は、無線通信部212を介して、ステップS112にて送信された認証要求データを受信する(S113)。
次に、第二利用者装置2は、認証要求データに応じて、第二利用者秘密鍵記憶領域202に記憶されているドメインBの秘密鍵を用いて電子署名データを生成する(S14)。電子署名に付与にあたっては、サービス利用部104が、第二利用者装置用認証部208に指示することで、第二利用者装置用認証部208が、電子署名データを生成した後、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、サービス利用部207に返信する。例えば、SSLあるいはTLSによるクライアント認証のために必要なクライアント側の処理が本ステップに相当する。
次に、第二利用者装置2のサービス利用部207は、ステップS114において生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、をサービス提供装置4に送信する(S115)。例えば、SSLあるいはTLSによるクライアント証明書を送信する処理等が本ステップに相当する。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第二利用者装置2が送信した電子署名データ、利用者証明書等を受信する(S116)。
次に、サービス提供装置4の認証連携処理部408は、第二利用者装置2から受信した電子署名データの署名検証を、一緒に受信した利用者証明書を用いて行う(S117)。ここで、署名の検証に成功した場合はステップS119に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS118に進む。
ステップS118では、第二利用者装置2のサービス利用部207は、ステップS117において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS110に戻り処理を繰り返してもよい。
一方、ステップS119では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS117で署名の検証に用いた利用者証明書の検証要求メッセージを送信する。この検証要求メッセージには、連携変更要求であることを示す要求種別データと、利用者証明書と、が含まれるものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S120)。
そして、提供側証明書検証装置6の証明書検証部607は、ステップS120において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S121)。本ステップの詳細については、図22を用いて説明する。
次に、ステップS91の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S122)。利用者証明書の検証応答メッセージには、利用者証明書の正当性検証の成否が含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、ステップS122において送信された利用者証明書の検証応答メッセージを受信し、利用者証明書の正当性の検証結果を確認する(S123)。利用者証明書の正当性検証の結果、利用者証明書に問題がないことを確認できた場合にはステップS125に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、利用者証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS124に進む。
ステップS124では、第二利用者装置2のサービス利用部207は、ステップS123において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS110に戻り処理を繰り返してもよい。
一方、ステップS125では、サービス提供装置4の認証連携処理部408は、当該利用者証明書の利用者に対して一意となる認証コードの生成を行う。
そして、サービス提供装置4の認証連携処理部408は、通信部410を介して、ユーザ情報管理装置5に対して、認証コードの登録要求メッセージを送信する(S126)。認証コードの登録要求メッセージには、認証コードの登録要求メッセージであることを示すデータの他、ステップS116において受信した利用者証明書から抽出した発行者名及びシリアル番号と、認証コードと、が含まれているものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信した認証コードの登録要求メッセージを受信する(S127)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS127において受信した情報に基づき、ユーザ情報記憶領域502に記憶されているユーザ情報テーブル502aを更新する(S128)。ここでは、発行者名及びシリアル番号を検索キーとしてユーザ情報テーブル502aを検索し、当該発行者名及びシリアル番号が登録されているレコードに受信した情報に含まれる認証コードを登録する。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、認証コードの登録結果を含めたメッセージを生成し、サービス提供装置4に送信する(S129)。
サービス提供装置4の認証連携処理部408は、通信部410を介して、ステップS129において送信された登録結果メッセージを受信し、登録の成否を確認する(S130)。登録に成功した場合にはステップS132に進み、登録に失敗した場合は、登録に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第二利用者装置2に送信し、ステップS131に進む。
ステップS131では、第二利用者装置2のサービス利用部207は、ステップS130において送信されたエラー画面データを出力部211に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS110に戻り処理を繰り返してもよい。
一方、ステップS132では、サービス提供装置4のサービス提供部407は、認証コードを記載した認証コード通知画面データを生成し、当該認証コード通知画面データを第二利用者装置2に送信する(S132)。
第二利用者装置2のサービス利用部207は、ステップS132において送信された認証コード通知画面データを出力部211に表示する(S133)。なお、本ステップを実施した後、図19の次のステップS134に移行するタイミングは、利用者の都合のよいタイミングで実施されるものとし、必ずしも即時に実施される必要はない。また、本ステップ以降、利用者は第一利用者装置1を使用する。
図19に進み、次に、第一利用者装置1のサービス利用部104は、入力部108を介して、サービス提供装置4が提供するサービスにおける証明書変更要求を行うためのURLの入力を受け付け、サービス提供装置4に証明書変更要求メッセージを送信する(S134)。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信した証明書変更要求を受信する(S135)。
次に、サービス提供装置4のサービス提供部407は、利用者証明書の変更を行うために必要な認証コード入力画面データを第一利用者装置1に送信する(S136)。
そして、第一利用者装置1のサービス利用部104は、ステップS136にて送信された認証コード入力画面データを受信し、出力部109に表示する(S137)。
次に、第一利用者装置1のサービス利用部104は、入力部108を介して、変更に必要な情報の入力を受け付け、入力された情報を署名対象として、ドメインAの新しい秘密鍵を用いて電子署名データを生成する(S138)。例えば、サービス利用部104は、第一利用者装置用認証部106及び利用者認証用デバイス制御部105を介して、利用者認証用デバイス120のデバイス用認証部127に電子署名データの生成を要求する。そして、デバイス用認証部127が、第一利用者秘密鍵記憶領域122に記憶されている新しい秘密鍵を用いて電子署名データを生成した後、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する新しい利用者証明書と、を第一利用者装置1のサービス利用部104に返信する。
そして、第一利用者装置1のサービス利用部104は、ステップS138においてユーザに入力させた情報と、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する新しい利用者証明書と、をサービス提供装置4に送信する(S139)。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信したユーザの情報、電子署名データ、新しい利用者証明書等を受信する(S140)。
次に、サービス提供装置4の認証連携処理部408は、第一利用者装置1から受信した電子署名データの署名検証を、新しいドメインAの利用者証明書を用いて行う(S141)。ここで、署名の検証に成功した場合はステップS143に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS142に進む。
ステップS142では、第一利用者装置1のサービス利用部104は、ステップS141において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS110に戻り処理を繰り返してもよい。
一方、ステップS143では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS141で署名の検証に用いた利用者証明書の検証要求メッセージを送信する。検証要求メッセージには、証明書変更要求であることを示す要求種別データと、検証対象となる新しいドメインAの利用者証明書と、が含まれるものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S144)。
次に、提供側証明書検証装置6の証明書検証部607は、ステップS144において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S145)。本ステップの詳細については、図22を用いて説明する。
さらに、ステップS145の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S146)。利用者証明書の検証応答メッセージには、新しいドメインAの利用者証明書の正当性検証の成否が含まれるものとする。
そして、サービス提供装置4の認証連携処理部408は、ステップS146において送信された利用者証明書の検証応答メッセージを受信し、新しいドメインAの利用者証明書の正当性の検証結果を確認する(S147)。利用者証明書382の正当性検証の結果、証明書に問題がないことを確認できた場合にはステップS149に進み、利用者証明書の正当性検証の結果が失敗を示すものである場合には、証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS148に進む。
ステップS148では、第一利用者装置1のサービス利用部104は、ステップS147において送信されたエラー画面データを出力部109に表示する(S148)。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS134に戻り処理を繰り返してもよい。
一方、ステップS149では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、認証コードを検索するための検索要求メッセージを送信する。認証コードの検索要求メッセージには、検索要求メッセージであることを示すデータの他、ステップS140において受信した利用者証明書から抽出した発行者名もしくはその一部(発行者を識別できる部分)、および、所有者名もしくはその一部(所有者を識別できる部分)が含まれるものとする。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、サービス提供装置4が送信した認証コードの検索要求メッセージを受信する(S150)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS150において受信した情報をもとに、ユーザ情報記憶領域502に記憶されているユーザ情報テーブル502aを検索する(S151)。本ステップでは、ユーザ情報テーブル502aにおいて、利用者証明書の発行者名もしくはその一部がどのドメインに属するものであるかを判断し、該当するドメインの所有者名の列から、受信した所有者名を検索キーに一致するレコードを検索する。なお、本フローの前提条件に記載したとおり、証明書の命名規則によって所有者名の一部で利用者を一意に特定可能であるものについては、所有者名の一部を検索キーに使用する。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、認証コードの検索結果を含めた検索結果メッセージを生成し、サービス提供装置4に送信する(S152)。ここで、ステップS151において該当するレコードが存在した場合には、当該レコードに登録されている認証コードを検索結果メッセージに含め、該当するレコードが存在しない場合、あるいは、該当するレコードに認証コードが存在しない場合は、認証コードが存在しないことを示す情報を検索結果メッセージに含める。
なお、本シーケンスの前提である利用者証明書の関連付けの更新対象の条件からすると、該当するレコードは複数存在しない想定であるため、ステップS151において該当するレコードが複数検索された場合には、本ステップにおいて生成する検索結果としてエラーである旨のメッセージを生成するものとする。
そして、サービス提供装置4の認証連携処理部408は、ステップS152において送信された検索結果メッセージを受信し、受信した認証コードと、ステップS140で受信した認証コードと、が一致するかどうかを検証する(S153)。検証に成功した場合は、ステップS155に進み、検証に失敗した場合(ステップS146で送信された検証結果メッセージに認証コードが含まれていない場合も含む)は、証明書の変更に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS154に進む。
ステップS154では、第一利用者装置1のサービス利用部104は、ステップS153において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS134に戻り処理を繰り返してもよい。
一方、ステップS155では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報の変更要求メッセージを送信する。ユーザ情報の変更要求メッセージには、変更要求メッセージであることを示すデータの他、ステップS140において取得した認証コード、利用者証明書、さらには当該利用者証明書から抽出した発行者名、シリアル番号、所有者名等が含まれているものとする。また、変更を要求する利用者証明書、発行者名、シリアル番号、所有者名の列については、発行者名をから該当するドメインを特定し、変更する列を指定するものとする。
ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信したユーザ情報の変更要求を受信する(S156)。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS156において受信した情報を、ユーザ情報記憶領域502に記憶されているユーザ情報テーブル502aに格納する(S157)。本ステップでは、認証コードを検索キーにユーザ情報テーブル502aを検索し、当該認証コードが登録されているレコードに、利用者証明書、発行者名、シリアル番号、所有者名の情報を格納して更新する。また、当該レコードの認証コードの削除も行う。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の変更結果を含めた変更結果メッセージを生成し、サービス提供装置4に送信する(S158)。
サービス提供装置4の認証連携処理部408は、ステップS158において送信された変更結果メッセージを受信し、変更の成否を確認する(S159)。変更に成功した場合にはステップS161に進み、変更に失敗した場合は、変更に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS160に進む。
ステップS160では、第一利用者装置1のサービス利用部104は、ステップS159において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS134に戻り処理を繰り返してもよい。
一方、ステップS161では、サービス提供装置4のサービス提供部407は、変更に成功した旨を示す変更結果画面データを生成し、当該画面データを第一利用者装置1に送信する。
そして、第一利用者装置1のサービス利用部104は、ステップS161において送信された変更結果画面データを出力部109に表示する(S162)。
以上の手順を実施することにより、サービス提供者にとって信頼度の高い利用者証明書の関連付けの変更が完了する。なお、本シーケンスでは、ユーザ情報の検索を行ってから(ステップS149〜ステップS154)、ユーザ情報の変更要求メッセージを送信するようにしているが(ステップS155)、ユーザ情報の検索ステップ(ステップS149〜ステップS154)については、スキップすることも可能である。
図20及び図21は、利用者証明書の関連付けの解除処理を示すシーケンス図である。サービス利用の前提として、利用者は図14及び図15に示す利用者証明書の登録処理を既に行っているものとする。また、ここでは、利用者が第一利用者装置1を利用する際のシーケンスを説明するが、第二利用者装置2を利用してもよい。
まず、第一利用者装置1のサービス利用部104は、入力部108を介して、サービス提供装置4が提供するサービスにおいて利用者証明書の関連付けを解除するためのURLの入力を受け付け、サービス提供装置4に利用者証明書の関連付けを解除するための連携解除要求メッセージを送信する(S170)。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信した連係解除要求メッセージを受信する(S171)。
次に、サービス提供装置4のサービス提供部407は、連係解除時の認証に必要な利用者証明書等を要求する認証要求データを第一利用者装置1に送信する(S172)。
そして、第一利用者装置1のサービス利用部104は、通信部110を介して、ステップS172にて送信された認証要求データを受信する(S173)。
次に、第一利用者装置1は、受信した認証要求データに基づき、秘密鍵を用いて電子署名を生成する(S174)。例えば、サービス利用部104は、第一利用者装置用認証部106及び利用者認証用デバイス制御部105を介して、利用者認証用デバイス120のデバイス用認証部127に電子署名データの生成を要求する。そして、デバイス用認証部127が、第一利用者秘密鍵記憶領域122に記憶されている秘密鍵を用いて電子署名データを生成した後、生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、を第一利用者装置1のサービス利用部104に返信する。例えば、SSLあるいはTLSによるクライアント認証のために必要なクライアント側の処理が本ステップに相当する。なお、ここで使用する利用者証明書や秘密鍵は、有効な利用者証明書や当該証明書に対応する秘密鍵である。
次に、第一利用者装置1のサービス利用部104は、ステップS174において生成した電子署名データと、当該電子署名データの生成に使用した秘密鍵に対応する利用者証明書と、をサービス提供装置4に送信する(S175)。例えば、SSLあるいはTLSによるクライアント証明書を送信する処理等が本ステップに相当する。
次に、サービス提供装置4のサービス提供部407は、通信部410を介して、第一利用者装置1が送信した電子署名データ、利用者証明書等を受信する(S176)。
そして、サービス提供装置4の認証連携処理部408は、第一利用者装置1から受信した電子署名データの署名検証を、一緒に受信した利用者証明書を用いて行う(S177)。ここで、署名の検証に成功した場合はステップS179に進み、署名の検証に失敗した場合は、署名検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS178に進む。
ステップS178では、第一利用者装置1のサービス利用部104は、ステップS177において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS170に戻り処理を繰り返してもよい。
一方、ステップS179では、サービス提供装置4の認証連携処理部408は、提供側証明書検証装置6に対して、ステップS177で署名の検証に用いた利用者証明書の検証要求メッセージを送信する。検証要求メッセージには、連携解除要求メッセージであることを示す要求種別データと、検証対象となる利用者証明書と、が含まれるものとする。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、サービス提供装置4が送信した利用者証明書の検証要求メッセージを受信する(S180)。
そして、提供側証明書検証装置6の証明書検証部607は、ステップS180において受信した検証要求メッセージ中の利用者証明書の正当性の検証を行う(S181)。本ステップの詳細については、図22を用いて説明する。
次に、ステップS181の検証結果に応じて、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証応答メッセージを生成し、サービス提供装置4に送信する(S182)。利用者証明書の検証応答メッセージには、利用者証明書の正当性検証の成否が含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、ステップS182において送信された利用者証明書の検証応答を受信し、利用者証明書の正当性の検証結果を確認する(S183)。利用者証明書の正当性検証の結果、利用者証明書に問題がないことを確認できた場合にはステップS185(図21)に進み、利用者証明書の正当性検証の結果が失敗していた場合には、証明書の検証に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS184に進む。
ステップS184では、第一利用者装置1のサービス利用部104は、ステップS183において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS170に戻り処理を繰り返してもよい。
図21に進み、ステップS185では、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報を検索するための検索要求メッセージを送信する。ユーザ情報の検索要求メッセージには、検索要求メッセージであることを示すデータの他、ステップS176において受信した利用者証明書から抽出した発行者名もしくはその一部(発行者を識別することのできる部分)、および、所有者名もしくはその一部(所有者を識別することのできる部分)、が含まれているものとする。
ユーザ情報管理装置5のユーザ情報管理部506は、サービス提供装置4が送信したユーザ情報の検索要求メッセージを受信する(S186)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS186において受信した情報をもとに、ユーザ情報記憶領域502に記憶されているユーザ情報テーブル502aを検索する(S187)。本ステップでは、利用者証明書の発行者名もしくはその一部がどのドメインに属するものであるかを判断し、該当するドメインの所有者名の列から、受信した所有者名を検索キーに一致するレコードを検索する。なお、証明書の命名規則によって所有者名の一部で利用者を一意に特定可能であるものについては、所有者名の一部を検索キーに使用する。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の検索結果を含めた検索結果メッセージを生成し、サービス提供装置4に送信する(S188)。ここで、検索結果メッセージには、該当するレコードが存在した場合には、そのレコードに格納されている登録ID、個人情報、各ドメインの利用者証明書の発行者名、シリアル番号、所有者名を少なくとも含め、該当するレコードが存在しない場合は、存在しない旨を示す情報を含めるものとする。
なお、本フローの前提である証明書の関連付けの更新対象の条件からすると、該当するレコードは複数存在しない想定であるため、ステップS187において該当するレコードが複数検索された場合には、本ステップにおいて生成する検索結果としてエラーである旨のメッセージを生成するものとする。
次に、サービス提供装置4の認証連携処理部408は、ステップS188において送信された検索結果メッセージを受信し、受信した検索結果メッセージにユーザ情報(登録ID、個人情報、各ドメインの利用者証明書の発行者名、シリアル番号、所有者名)が含まれているか否かを確認する(S189)。検索結果メッセージにユーザ情報が含まれている場合には、ステップS191に進み、検索結果メッセージにユーザ情報が含まれていない場合は、解除の対象となる証明書登録が行われていない旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS190に進む。
ステップS190では、第一利用者装置1のサービス利用部104は、ステップS189において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS170に戻り処理を繰り返してもよい。
一方、ステップS191では、サービス提供装置4の認証連携処理部408は、連携解除を行うための連携解除選択画面データを生成し、当該連携解除選択画面データを第一利用者装置1に送信する。なお、連携解除選択画面データには、ステップS189において受信したユーザ情報をもとに、関連付けされている利用者証明書に関する情報の一覧を記載し、連携を解除するものをチェックした結果と登録IDを送信できる形態のものとする。
そして、第一利用者装置1のサービス利用部104は、ステップS191において送信された連携解除選択画面データを出力部109に表示する(S192)。
次に、第一利用者装置1のサービス利用部104は、入力部108を介して、利用者から連携を解除したい利用者証明書を特定する部分にチェックをつけさせるなどして選択を受け付ける(S193)。
そして、第一利用者装置1のサービス利用部104は、ステップS193において選択を受け付けた内容で特定される情報を連携解除証明書情報メッセージとして、サービス提供装置4に送信する(S194)。連携解除証明書情報メッセージには、登録ID、解除対象として選択された利用者証明書の発行者名、シリアル番号、所有者名等が含まれるものとする。
次に、サービス提供装置4の認証連携処理部408は、通信部410を介して、第一利用者装置1が送信した連携解除証明書情報メッセージを受信する(S195)。
そして、サービス提供装置4の認証連携処理部408は、ユーザ情報管理装置5に対して、ユーザ情報の変更要求メッセージを送信する(S196)。ユーザ情報の変更要求メッセージには、変更要求メッセージであることを示すデータの他、ステップS195において取得した登録ID、解除対象となった利用者証明書の発行者名、シリアル番号、所有者名等が含まれているものとする。
ユーザ情報管理装置5のユーザ情報管理部506は、通信部508を介して、サービス提供装置4が送信したユーザ情報の変更要求メッセージを受信する(S197)。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ステップS197において受信した変更要求メッセージに含まれる情報に基づいて、ユーザ情報テーブル502aを更新する(S198)。本ステップでは、ユーザ情報テーブル502aにおいて、登録IDを検索キーに、当該登録IDが登録されているレコードの、解除対象となる利用者証明書、発行者名、シリアル番号、所有者名の情報を削除する。なお、削除する利用者証明書、発行者名、シリアル番号、所有者名の列については、発行者名から該当するドメインを特定し、削除する列を特定するものとする。
次に、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報の変更結果を含めた変更結果メッセージを生成し、サービス提供装置4に送信する(S199)。
そして、サービス提供装置4の認証連携処理部408は、ステップS199において送信された変更結果メッセージを受信し、変更の成否を確認する(S200)。変更に成功した場合にはステップS202に進み、変更に失敗した場合は、連携解除に失敗した旨を伝えるエラー画面データを生成し、当該エラー画面データを第一利用者装置1に送信し、ステップS201に進む。
ステップS201では、第一利用者装置1のサービス利用部104は、ステップS200において送信されたエラー画面データを出力部109に表示する。本実施形態においては本ステップで処理が終了するが、必要に応じてステップS170に戻り処理を繰り返してもよい。
一方、ステップS202では、サービス提供装置4のサービス提供部407は、連携解除に成功した旨を示す連携解除結果画面データを生成し、当該連携解除結果画面データを第一利用者装置1に送信する(S202)。
そして、第一利用者装置1のサービス利用部104は、ステップS202において送信された連携解除結果画面データを出力部109に表示する(S203)。
以上の手順を実施することにより、利用者証明書の関連付けの解除が完了する。なお、本シーケンスでは、ユーザ情報の検索を行ってから(ステップS189〜ステップS190)、連係解除選択画面データを送信するようにしているが(ステップS191)、ユーザ情報の検索ステップ(ステップS189〜ステップS190)については、スキップすることも可能である。
図22は、利用者証明書の検証処理を示すフローチャートである。
まず、提供側証明書検証装置6の追加検証部608は、検証対象となる利用者証明書から発行者名を抽出し、検証対象となる利用者証明書がサービス提供にあたり利用を認めているサポート内の利用者証明書であるか否かを確認する(S210)。そして、サポート内の利用者証明書である場合にはステップS211に進み、サポート内の利用者証明書ではない場合にはステップS223に進む。
次に、追加検証部608は、検証対象となる利用者証明書から抽出した発行者名より、ドメインを特定し、検証対象となる利用者証明書が信頼度の高い証明書として位置づけられている利用者証明書であるか否か(ここでは、ドメインAの利用者証明書であるか否か)を確認する(S211)。そして、信頼度の高い利用者証明書である場合にはステップS219に進み、信頼度の高い利用者証明書ではない場合にはステップS212に進む。
ステップS212では、追加検証部608は、サービス提供装置4が第一利用者装置1又は第二利用者装置2から受信した要求種別データが、連携変更要求メッセージを示すものであるか否かを判定する。そして、要求種別データが連携変更要求メッセージを示すものであった場合には、ステップS219に進み、要求種別データが連携変更要求メッセージを示すものではない場合には、ステップS213に進む。
ステップS213では、追加検証部608は、検証対象である利用者証明書の解析を行う。本実施形態においては、ドメインBの利用者証明書の解析を行うことになる。ここで解析を行う要素としては、利用者証明書の発行者名及びシリアル番号であり、これらの情報を取得する。
次に、追加検証部608は、ユーザ情報管理装置5に対して、ユーザ情報を検索するための検索要求メッセージを送信する(S214)。ユーザ情報の検索要求のメッセージには、検索要求メッセージであることを示すデータの他、ステップS213において取得した利用者証明書の発行者名及びシリアル番号を含める。
このような検索要求メッセージを受信したユーザ情報管理装置5では、ユーザ情報管理部506が、受信した検索要求メッセージに含まれる情報をもとに、ユーザ情報テーブル502aより、検証対象となる利用者証明書が連携付けられている利用者証明書を被連携証明書格納領域502dより取得する。
例えば、本ステップでは、利用者証明書の発行者名がどのドメインに属するものであるかを判断し、該当するドメインのシリアル番号の列から、解析したシリアル番号を検索キーに一致するレコードを検索する。該当するレコードが存在した場合には、そのレコードの被連携証明書格納領域502dに格納されている利用者証明書、発行者名、シリアル番号、所有者名等を抽出し、さらに、そのレコードの状態フラグを抽出する。
さらに、ユーザ情報管理部506は、該当するレコードが存在した場合には、抽出した利用者証明書、発行者名、シリアル番号、所有者名、状態フラグ等を含むユーザ情報の検索結果メッセージを生成して、提供側証明書検証装置6に返信する。
そして、提供側証明書検証装置6の追加検証部608は、ユーザ情報管理装置5より、検索結果メッセージを受信すると(S215でYes)、受信した検索結果メッセージに含まれる状態フラグが「本登録」を示すものであるか否かを確認する(S216)。そして、「本登録」を示すものである場合にはステップS217に進み、「本登録」を示すものではない場合にはステップS223に進む。
ステップS217では、提供側証明書検証装置6の追加検証部608は、検証対象証明書に関連付けされた利用者証明書の正当性の検証を、証明書検証部607に要求し、証明書検証部607が検証を行う。ここで、本実施形態においては、本ステップでは、ドメインBの利用者証明書に関連付けされたドメインAの利用者証明書が検証の対象となる。なお、証明書検証部607での利用者証明書の正当性の検証処理の詳細は、図23及び図24を用いて説明する。
次に、提供側証明書検証装置6の追加検証部608は、ステップS217で行われた検証の検証結果を判定する(S218)。そして、検証結果が成功であった場合には、ステップS219に進み、検証結果が失敗であった場合には、ステップS221に進む。
ステップS219では、提供側証明書検証装置6の追加検証部608が、検証対象となっている利用者証明書の正当性の検証を、証明書検証部607に要求することにより、証明書検証部607は検証を行う。証明書検証部607における証明書の正当性の検証処理の詳細は、図23及び図24を用いて説明する。
次に、提供側証明書検証装置6の追加検証部608は、ステップS219において検証された利用者証明書の検証結果を判定する(S220)。利用者証明書の検証結果が成功であった場合にはステップS223に進み、利用者証明書の検証結果が失敗であった場合にはステップS221に進む。
ステップS221では、追加検証部608は、ユーザ情報管理装置5に対して、登録状態フラグの変更要求メッセージを送信する。登録状態フラグの変更要求メッセージには、登録フラグの変更要求メッセージであることを示すデータの他、検証に失敗した利用者証明書、当該利用者証明書の発行者名、シリアル番号等を含めるものとする。
このような登録状態フラグの変更要求メッセージを受信したユーザ情報管理装置5では、ユーザ情報管理部506が、受信した変更要求メッセージに含まれている情報を、ユーザ情報テーブル502aに格納する。
例えば、ユーザ情報管理装置5のユーザ情報管理部506は、ユーザ情報テーブル502aにおいて、利用者証明書の発行者名及びシリアル番号を検索キーに検索されたレコードの状態フラグフィールド502qに格納されている情報を、受信した変更要求メッセージで特定されるステータスに変更する。例えば、ドメインAの利用者証明書の検証に失敗した場合には、ドメインAの証明書が無効であることを特定する「A無効」のステータスに、ドメインBの利用者証明書の検証に失敗した場合には、ドメインBの証明書が無効であることを特定する「B無効」のステータスに、変更する。
なお、ユーザ情報管理装置5のユーザ情報管理部506は、変更を要求する利用者証明書、発行者名、シリアル番号の列については、発行者名から該当するドメインを特定し、更新する列を特定するものとする。
そして、ユーザ情報管理装置5のユーザ情報管理部506は、登録状態フラグの変更結果を含めた変更結果メッセージを生成し、提供側証明書検証装置6に送信する。
次に、提供側証明書検証装置6の追加検証部608は、ユーザ情報管理装置5より変更結果メッセージを受信すると(ステップS222でYes)、ステップS223に進む。
ステップS223では、提供側証明書検証装置6の追加検証部608は、証明書検証結果の生成を行う。例えば、ステップS210において検証対象証明書がサポート外のドメインであった場合、ステップS216において登録状態フラグが本登録以外の状態を示すものであった場合、あるいは、ステップS222で変更結果メッセージを受信した場合には、検証に失敗した旨の証明書検証結果メッセージを生成する。一方、ステップS222において検証対象証明書の検証に成功した場合には、検証に成功した旨の証明書検証結果メッセージを生成する。
以上の処理を実施することによって、サービス利用時に信頼度の低い利用者証明書が使われた場合であっても、当該利用者証明書に関連する信頼度の高い利用者証明書も併せて検証することができ、認証の信頼度を低下させないようにすることができる。
一方、サービス利用時に信頼度の高い利用者証明書が使われた場合や利用者証明書が無効であることが既に把握できている場合には、複数の利用者証明書を検証することはなく、検証における冗長性を排除することもできる。
図23及び図24は、利用者証明書の検証処理を示すシーケンス図である。
ここでは、ドメインAの利用者証明書を検証する際の処理を記載しているが、ドメインBの利用者証明書を検証する際には、第一証明書検証装置3Aに代えて第二証明書検証装置3Bを、第一認証局装置3Aに代えて第二認証局装置7Bを、用いればよい。
なお、本シーケンスの前提として、提供側証明書検証装置6以外の証明書検証装置として利用可能なもの(本実施形態においては、第一証明書検証装置3A及び第二証明書検証装置3B)が存在し、これらの証明書検証装置を利用する場合には、予め、提供側証明書検証装置6の設定情報として、これらの証明書検証装置を利用者証明書の検証に利用する設定にしておくものとする。
まず、提供側証明書検証装置6の証明書検証部607は、利用者証明書の検証において、利用者証明書のドメインに対応した他の証明書検証装置を利用するかどうかについて、提供側証明書検証装置6の設定情報を確認する(S230)。他の証明書検証装置を利用する設定になっている場合にはステップS231に進み、他の証明書検証装置を利用しない設定になっている場合にはステップS244(図24)に進む。
ステップS231では、提供側証明書検証装置6の証明書検証部607は、他の証明書検証装置(ここでは、第一証明書検証装置3A)に対して、証明書検証要求メッセージを送信する。証明書検証要求メッセージは、検証する利用者証明書と、信頼する認証局証明書と、を含むメッセージであり、例えば、政府認証基盤(GPKI)政府認証基盤相互運用性仕様書に規定されている証明書検証サーバアクセスプロトコルや、RFC5055として規定されているSCVP(Server-Based Certificate Validation Protocol)の要求メッセージが該当する。
第一証明書検証装置3Aの証明書検証部は、提供側証明書検証装置6が送信した証明書検証要求メッセージを受信する(S232)。
次に、第一証明書検証装置3Aの証明書検証部は、ステップS232において受信した証明書検証要求メッセージに含まれる利用者証明書の認証パスを構築する(S233)。認証パスの構築とは、信頼する認証局の認証局証明書から利用者証明書に至るまで、上位の証明書の所有者名と下位の証明書の発行者名が一致するようにパスを構成し、当該パス上の証明書全てを収集することである。信頼する認証局の認証局証明書から利用者証明書までのパスがつながっていない場合や、認証パス上の証明書が取得できなかった場合は、認証パスの構築に失敗したことになる。
そして、認証パスの構築に成功した場合はステップS234に進み、認証パスの構築に失敗した場合はステップS240に進む。
ステップS234では、第一証明書検証装置3Aの証明書検証部は、構築された認証パスの検証を行う。認証パスの検証とは、信頼する認証局証明書から利用者証明書までの各証明書について、下位の証明書に付与されている電子署名を上位の証明書の公開鍵で検証すること等である。
そして、認証パスの検証に成功した場合はステップS235に進み、認証パスの検証に失敗した場合はステップS240に進む。
ステップS235では、第一証明書検証装置3Aの証明書検証部は、利用者証明書の有効性の確認を行うため、有効性確認の対象としている利用者証明書を発行した認証局装置(ここでは、第一認証局装置3A)に対して、有効性確認要求メッセージを送信する。
ここで、本実施形態においては、有効性確認要求として証明書失効リストの取得要求を行うものとして説明を行うが、オンライン証明書ステータスプロトコルによる要求メッセージを送信する形態であってもよい。なお、有効性確認要求の問い合わせ先は、各証明書内に記載されているものとする。
次に、第一認証局装置3Aの失効情報提供部310は、通信部314を介して、第一証明書検証装置3Aが送信した有効性確認要求メッセージを受信する(S236)。
次に、第一認証局装置3Aの失効情報提供部310は、失効した利用者証明書を特定する有効性確認情報を含めた有効性確認情報メッセージを生成し、第一証明書検証装置3Aに送信する(S237)。本実施形態においては、証明書失効リストを送信するものとするが、オンライン証明書ステータスプロトコル等の方法によって失効情報を提供する場合は、この限りではない。
次に、第一証明書検証装置3Aの証明書検証部は、通信部を介して、ステップS237において送信された有効性確認情報メッセージを受信する(S238)。
次に、第一証明書検証装置3Aの証明書検証部は、ステップS238において受信した有効性確認情報メッセージに基づき、有効性を確認しようとしている利用者証明書が失効していないこと、および、証明書が有効期間内であることを確認する(S239)。
次に、第一証明書検証装置3Aの証明書検証部は、ステップS233、ステップS234及びステップS239の検証結果に応じて、利用者証明書の検証応答メッセージを生成する(S240)。
例えば、ステップS239において証明書が有効であると判断された場合には、証明書検証応答として証明書の検証に成功した旨のメッセージを生成する。一方、ステップS233において認証パスの構築に失敗した場合、ステップS234において認証パスの検証に失敗した場合、および、ステップS239において証明書が無効であると判断された場合、には証明書検証応答として証明書の検証に失敗した旨のメッセージを生成する。
次に、第一証明書検証装置3Aの証明書検証部は、ステップS240において生成した証明書検証応答メッセージを、提供側証明書検証装置6に送信する(S241)。
次に、提供側証明書検証装置6の証明書検証部607は、通信部610を介して、ステップS241において送信された証明書検証応答メッセージを受信する(S242)。
次に、提供側証明書検証装置6の証明書検証部607は、ステップS242において受信した証明書検証応答メッセージの内容を確認することで、検証結果を判断する(S243)。
一方、ステップS230において、他の証明書検証装置を利用しない設定になっていた場合、図24のステップS244に進み、提供側証明書検証装置6の証明書検証部607は、利用者証明書の認証パスを構築する(S244)。認証パスの構築に成功した場合はステップS245に進み、認証パスの構築に失敗した場合はステップS251に進む。
ステップS245では、提供側証明書検証装置6の証明書検証部607は、構築された認証パスの検証を行う。認証パスの検証に成功した場合はステップS246に進み、認証パスの検証に失敗した場合はステップS251に進む。
ステップS246では、提供側証明書検証装置6の証明書検証部607は、利用者証明書の有効性確認を行うため、有効性確認の対象としている利用者証明書を発行した第一認証局装置3Aに対して有効性確認要求メッセージを送信する(S246)。
次に、第一認証局装置3Aの失効情報提供部310は、通信部314を介して、提供側証明書検証装置6が送信した有効性確認要求を、にて受信する(ステップ7540)。
そして、第一認証局装置3Aの失効情報提供部310は、失効した利用者証明書を特定する有効性確認情報を含めた有効性確認情報メッセージを生成し、提供側証明書検証装置6に送信する(S248)。
次に、提供側証明書検証装置6の証明書検証部607は、ステップS248において送信された有効性確認情報メッセージを受信する(S249)。
次に、提供側証明書検証装置6の証明書検証部607は、ステップS249において受信した有効性確認情報メッセージに基づき、有効性を確認しようとしている証明書が失効していないこと、及び、証明書が有効期間内であることを確認する(S250)。
そして、提供側証明書検証装置6の証明書検証部607は、ステップS250において証明書が有効であると判断された場合には、証明書の検証に成功したと判断する。一方、ステップS244において認証パスの構築に失敗した場合、ステップS245において認証パスの検証に失敗した場合、ステップS250において証明書が無効であると判断された場合には、利用者証明書の検証に失敗したと判断する(S251)。
以上で、証明書の検証処理を完了する。
なお、以上に記載した実施形態においては、サービス提供者が高い信頼をおいていない認証局が発行した利用者証明書を提示して、サービスの提供を受けようとする際には、サービス提供者が高い信頼をおく認証局が発行した利用者証明書と、サービスの提供を受けようとする際に提示した利用者証明書と、の両方の検証が成功することにより、サービスの提供を可能としているが、これらの利用者証明書の何れか一方の検証が成功した場合には、検証に成功した利用者証明書の信頼度に応じたサービスを提供することは可能である。
このような場合には、図16のステップS72において、検証の成功した利用者証明書、検証の成功した利用者証明書の信頼度、または、検証の成功した利用者証明書のドメイン等を特定する情報を検証応答メッセージに含めて送信することで、サービス提供装置4において、検証に成功した利用者証明書の信頼度に応じたサービスの提供を判断することができる。この際、サービス提供装置4には、利用者証明書の信頼度又はドメインと、提供可能なサービスと、を関連付けた情報を記憶部401に記憶しておく。
また、以上に記載した実施形態においては、サービスを提供する際に、サービス提供装置4、ユーザ情報管理装置5及び提供側証明書検証装置6で、利用者の検証を行うようにしているが、このような態様に限定されず、これらの装置で行っている処理を一又は複数の装置にまとめ、または、分散させることも可能である。例えば、ユーザ情報管理装置5及び提供側証明書検証装置6で行っている処理を一つの装置で行うことも可能である。
さらに、以上に記載した実施形態においては、サービスの提供を受ける利用者が、第一利用者装置1と第二利用者装置2とを使用する例を記載したが、このような例に限られず、一つの装置(例えば、第一利用者装置1)を使用して本実施形態の処理を行うようにすることも可能である。このような場合には、本登録の通知先として当該一つの装置(例えば、第一利用者装置1)の通信アドレスを登録しておけばよい。