(57)【要約】【課題】センタ型であり且つ認証する機器同士の認証関係に基づき信頼可否を判定することができる認証システムを提供する。【解決手段】認証サーバ１０は、機器Ａ２０から受けた機器Ｂ３０との認証要求に応じて、機器Ａ２０および機器Ｂ３０との相互認証をする。認証サーバ１０の信頼性情報テーブル１７は、各機器から各機器への信頼可否を記憶する。認証サーバ１０の信頼性確認処理部１５は、機器Ａ２０から機器Ｂ３０への信頼可否と機器Ｂ３０から機器Ａ２０への信頼可否とを信頼性情報テーブル１７を参照して取得し、取得した結果が二つとも信頼可であったときは、機器Ａ２０と機器Ｂ３０は相互に信頼可とする。【選択図】図１
2007274380.tif 000002
【特許請求の範囲】
【請求項１】
複数の機器と、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をする認証サーバとからなる認証システムにおいて、
前記認証サーバは、
前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段と、
前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段と
を備えることを特徴とする認証システム。
【請求項２】
前記信頼性情報記憶手段は、前記複数の機器間の信頼可否とともに、該信頼可否の有効期限を記憶し、
前記信頼性確認手段は、前記一の機器から前記他の機器への信頼可否および有効期限と前記他の機器から前記一の機器への信頼可否および有効期限とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可且つ有効期限内であったときは、前記一の機器と前記他の機器は相互に信頼可とすること
を特徴とする請求項１に記載の認証システム。
【請求項３】
前記機器は、各々の公開鍵証明書を備え、
前記認証サーバは、
前記信頼性確認手段において前記信頼性情報記憶手段を参照した際に、必要な機器間の信頼可否が信頼性情報記憶手段に記憶されていないときは、前記必要な機器間の信頼可否を、前記必要な機器各々の公開鍵証明書間の認証パスを検証することで決定し、前記信頼性情報記憶手段に格納する信頼性情報生成手段
を備えることを特徴とする請求項２に記載の認証システム。
【請求項４】
前記機器は、各々の属性証明書を備え、
前記認証サーバの信頼性情報記憶手段は、前記複数の機器間の公開鍵証明書から属性証明書への信頼可否を記憶し、
前記認証サーバの信頼性確認手段は、前記一の機器から前記他の機器の属性証明書への信頼可否と前記他の機器から前記一の機器の属性証明書への信頼可否とを前記信頼性情報記憶手段より取得し、取得した結果が二つとも信頼可であったときは、前記一の機器の属性証明書および前記他の機器の属性証明書は信頼可とし、
前記認証サーバの信頼性情報生成手段は、前記信頼性確認手段において前記信頼性情報記憶手段を参照した際に、必要な機器間の属性照明書への信頼可否が信頼性情報記憶手段に記憶されていないときは、前記必要な機器間の属性照明書への信頼可否を、前記必要な機器間の属性証明書への認証パスを検証することで決定し、前記信頼性情報記憶手段に格納すること
を特徴とする請求項３に記載の認証システム。
【請求項５】
複数の機器と接続され、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をする認証サーバにおいて、
前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段と
前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段と
を備えることを特徴とする認証サーバ。
【請求項６】
複数の機器と接続され、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をするコンピュータを、
前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段、
前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証システム、認証サーバおよびプログラムにかかわり、特に多数の機器間での相互認証を認証サーバを介して行なうセンタ型の認証システム、認証サーバおよびプログラムに関する。
【背景技術】
【０００２】
従来の公開鍵証明書を利用した相互認証処理は、１対１の相互認証となっており、認証処理の結果が信頼可能となった場合は、その機器を全信頼している（例えば、特許文献１参照）。
例えば、多数の機器間で情報交換を実施する場合、情報交換を実施する機器間での相互認証を確立する方法には、Ｐ２Ｐ型とセンタ型の２種類がある。Ｐ２Ｐ型は、図６（ａ）に例を示すように、情報交換を実施する機器が、例えば、機器Ａ１００と機器Ｂ１０１とが、直接、相手の公開鍵証明書を検証して相互認証を実施する。センタ型は、図６（ｂ）に例を示すように、機器Ａ２００と機器Ｂ２０２との間で相互認証を確立するのであれば、まず、機器Ａ２００と機器Ｃ２０１とが、相手の公開鍵証明書を検証して相互認証し、次に、機器Ｃ２０１と機器Ｂ２０２とが、相手の公開鍵証明書を検証して相互認証する。その結果、機器Ｃ２０１を信頼している機器Ａ２００は、機器Ｃ２０１が信頼している機器Ｂ２０２も信頼する。
【特許文献１】特開２００５−２６８４２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来のセンタ型とＰ２Ｐ型の認証システムにあっては、Ｐ２Ｐ型では相互に信頼可とする相互認証が成立しないのに、センタ型では相互認証が成立してしまう場合があるという問題がある。
【０００４】
例えば、図７に示すように、認証局ＣＡは、ＤｏｍａｉｎＡのルートＣＡであるＣＡ−１Ａ３０１、ＣＡ−１Ａ３０１のサブＣＡであるＣＡ−２Ａ３０２、さらにＣＡ−２Ａ３０２のサブＣＡであるＣＡ−３Ａ３０３と、ＤｏｍａｉｎＢのルートＣＡであるＣＡ−１Ｂ３１１、ＣＡ−１Ｂ３１１のサブＣＡであるＣＡ−２Ｂ３１２とからなり、各ドメインのルートＣＡであるＣＡ−１Ａ３０１とＣＡ−１Ｂ３１１とは、ホップ数が２までの範囲（inhibitPolicyMapping：２）で相互認証証明書にて互いに認証しあっている場合を考える。このとき、機器Ａ２００の公開鍵証明書をＣＡ−３Ａ３０３が発行し、機器Ｂ２０２の公開鍵証明書をＣＡ−２Ｂ３１２が発行し、機器Ｃ２０１の公開鍵証明書をＣＡ−１Ａ３０１が発行したとする。
【０００５】
この場合、機器Ａ２００と機器Ｃ２０１との認証は、機器Ａ２００から機器Ｃ２０１の認証パスが、機器Ａ２００⇒ＣＡ−２Ｂ３１２⇒ＣＡ−１Ｂ３１１⇒ＣＡ−１Ａ３０１⇒機器Ｃ２０１なので、ホップ数は、ＣＡ−１Ａ３０１⇒機器Ｃ２０１の「１」であり信頼可、機器Ｃ２０１から機器Ａ２００への認証パスは、機器Ｃ２０１⇒ＣＡ−１Ａ３０１⇒ＣＡ−１Ｂ３１１⇒ＣＡ−２Ｂ３１２⇒機器Ａ２００なので、ホップ数はＣＡ−１Ｂ３１１⇒ＣＡ−２Ｂ３１２⇒機器Ａ２００の「２」であり信頼可なので、相互認証が成立する。また、機器B２０２と機器C２０１とは、同じＤｏｍａｉｎＡなので相互認証が成立する。このように機器Ａ２００と機器Ｃ２０１との相互認証と、機器Ｂ２０２と機器Ｃ２０１との相互認証とが成立するので、センタ型では機器Ａ２００と機器Ｂ２０２は信頼可能である。
【０００６】
ところが、Ｐ２Ｐ型に相当する機器Ａ２００と機器Ｂ２０２との直接認証は、機器Ａ２００から機器Ｂ２０２への認証パスは、機器Ａ２００⇒ＣＡ−２Ｂ３１２⇒ＣＡ−１Ｂ３１１⇒ＣＡ−１Ａ３０１⇒ＣＡ−２Ａ３０２⇒ＣＡ−３Ａ３０３⇒機器Ｂ２０２なので、ホップ数は、ＣＡ−１Ａ３０１⇒ＣＡ−２Ａ３０２⇒ＣＡ−３Ａ３０３⇒機器Ｂ２０２の「３」なので相互認証は成立しない。
【０００７】
つまり、従来のセンタ型の認証システムでは認証する機器と認証を媒介する機器との認証関係に基づき、信頼可否を判定しているため、認証する機器同士の認証関係では信頼不可にもかかわらず、信頼可としてしまうことがあるという問題がある。
【０００８】
本発明は、このような事情に鑑みてなされたもので、その目的は、センタ型でありながら、Ｐ２Ｐ型と同様に認証する機器同士の認証関係に基づき信頼可否を判定することができる認証システムを提供することにある。
【課題を解決するための手段】
【０００９】
この発明は上述した課題を解決するためになされたもので、請求項１に記載の発明は、複数の機器と、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をする認証サーバとからなる認証システムにおいて、前記認証サーバは、前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段と、前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段とを備えることを特徴とする認証システムである。
【００１０】
また、請求項２に記載の発明は、請求項１に記載の認証システムであって、前記信頼性情報記憶手段は、前記複数の機器間の信頼可否とともに、該信頼可否の有効期限を記憶し、前記信頼性確認手段は、前記一の機器から前記他の機器への信頼可否および有効期限と前記他の機器から前記一の機器への信頼可否および有効期限とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可且つ有効期限内であったときは、前記一の機器と前記他の機器は相互に信頼可とすることを特徴とする。
【００１１】
また、請求項３に記載の発明は、請求項２に記載の認証システムであって、前記機器は、各々の公開鍵証明書を備え、前記認証サーバは、前記信頼性確認手段において前記信頼性情報記憶手段を参照した際に、必要な機器間の信頼可否が信頼性情報記憶手段に記憶されていないときは、前記必要な機器間の信頼可否を、前記必要な機器各々の公開鍵証明書間の認証パスを検証することで決定し、前記信頼性情報記憶手段に格納する信頼性情報生成手段を備えることを特徴とする。
【００１２】
また、請求項４に記載の発明は、請求項３に記載の認証システムであって、前記機器は、各々の属性証明書を備え、前記認証サーバの信頼性情報記憶手段は、前記複数の機器間の公開鍵証明書から属性証明書への信頼可否を記憶し、前記認証サーバの信頼性確認手段は、前記一の機器から前記他の機器の属性証明書への信頼可否と前記他の機器から前記一の機器の属性証明書への信頼可否とを前記信頼性情報記憶手段より取得し、取得した結果が二つとも信頼可であったときは、前記一の機器の属性証明書および前記他の機器の属性証明書は信頼可とし、前記認証サーバの信頼性情報生成手段は、前記信頼性確認手段において前記信頼性情報記憶手段を参照した際に、必要な機器間の属性照明書への信頼可否が信頼性情報記憶手段に記憶されていないときは、前記必要な機器間の属性照明書への信頼可否を、前記必要な機器間の属性証明書への認証パスを検証することで決定し、前記信頼性情報記憶手段に格納することを特徴とする。
【００１３】
また、請求項５に記載の発明は、複数の機器と接続され、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をする認証サーバにおいて、前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段と前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段とを備えることを特徴とする認証サーバである。
【００１４】
また、請求項６に記載の発明は、前記複数の機器のうちの一の機器から受けた他の機器との認証要求に応じて前記一の機器および前記他の機器との相互認証をするコンピュータを、前記複数の機器間の信頼可否を記憶する信頼性情報記憶手段、前記一の機器から前記他の機器への信頼可否と前記他の機器から前記一の機器への信頼可否とを前記信頼性情報記憶手段を参照して取得し、取得した結果が二つとも信頼可であったときは、前記一の機器と前記他の機器は相互に信頼可とする信頼性確認手段として機能させるプログラムである。
【発明の効果】
【００１５】
この発明によれば、信頼性確認手段が、一の機器から他の機器への信頼可否と他の機器から一の機器への信頼可否を信頼性情報記憶手段から取得し、取得した結果が二つとも信頼可であるときは、相互に信頼可とするので、センタ型であり、且つ、認証する機器同士の認証関係に基づき信頼可否を判定することができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して、本発明の実施の形態について説明する。図１は、この発明の一実施形態による認証システムの構成を示す概略ブロック図である。１０は、機器２０、３０を認証する認証サーバであり、依頼元認証処理部１１、依頼先認証処理部１２、公開鍵証明書記憶部１３、サービス中継処理部１４、信頼性確認処理部１５、信頼性情報生成処理部１６、信頼性情報テーブル１７を備える。依頼元認証処理部１１は、認証要求とともに受けた依頼元の公開鍵証明書ＰＫＣから、公開鍵証明書記憶部１３より取得した自装置の公開鍵証明書ＰＫＣまで認証パスが到達することを検証し、検証に成功したときは、自装置の公開鍵証明書ＰＫＣを依頼元の機器へ送信する。依頼先認証処理部１２は、認証要求とともに受けた依頼先機器へ、公開鍵証明書記憶部１３より取得した自装置の公開鍵証明書ＰＫＣを送信し、該送信の返信として受けた依頼先機器の公開鍵証明書ＰＫＣから、公開鍵証明書記憶部１３より取得した自装置の公開鍵証明書ＰＫＣまで認証パスが到達することを検証し、検証結果を依頼先機器へ通知する。
【００１７】
公開鍵証明書記憶部１３は、自装置の公開鍵証明書ＰＫＣを記憶している。サービス中継処理部１４は、依頼元機器から受けたセッション開始要求を、依頼先認証処理部１２において検証が成功し且つ信頼性確認処理部１５または信頼性情報生成処理部１６にて信頼性が確認できたときは、依頼先機器へ送信し、また、依頼先機器から受けたサービス実施結果を依頼元機器へ送信する。
【００１８】
信頼性確認処理部１５は、信頼性情報テーブル１７を参照して、依頼元機器の公開鍵証明書ＰＫＣが依頼先機器の公開鍵証明書ＰＫＣおよび属性証明書ＡＣを信頼可能であることと、依頼先機器の公開鍵証明書ＰＫＣが依頼元機器の公開鍵証明書ＰＫＣおよび属性証明書ＡＣを信頼可能であることと、それぞれの有効期限とを確認し、全てが成立していれば信頼可とする。このとき、必要な情報が信頼性情報テーブル１７に格納されていない場合は、該当する情報の生成を信頼性情報生成処理部１６に依頼する。
信頼性情報生成処理部１６は、信頼性確認処理部１５から生成を依頼された確認先の証明書から確認元の証明書までの認証パスが到達することを検証することで信頼可否を決めるとともに、この認証パスの検証に要した全ての証明書の有効期限の中で最も近い有効期限あるいは現在時刻に所定の時間を足した時刻のうち近い方の時刻を選び出し、この検証結果と選び出した時刻を信頼性情報テーブル１７に格納する。
【００１９】
信頼性情報テーブル１７は、公開鍵証明書ＰＫＣの信頼性情報と属性証明書ＡＣの信頼性情報とを格納する。公開鍵証明書ＰＫＣの信頼性情報には、図２の（ａ）に例を示すように、確認元ＰＫＣのＣＡ名とシリアルＮｏ．で識別される、ある機器の公開鍵証明書ＰＫＣが、確認先ＰＫＣのＣＡ名とシリアルＮｏ．で識別される、もう一つの機器の公開鍵証明書ＰＫＣを信頼可能であるか否かの信頼性情報と、該情報の有効期限である信頼性期限とを格納する。属性証明書ＡＣの信頼性情報には、図２の（ｂ）に例を示すように、確認元ＰＫＣのＣＡ名とシリアルＮｏ．で識別される、ある機器の公開鍵証明書ＰＫＣが、確認先ＡＣのＡＡ名とシリアルＮｏ．で識別される、もう一つの機器の属性証明書ＡＣを信頼可能であるか否かの信頼性情報と、該情報の有効期限である信頼性期限とを格納する。
【００２０】
２０は、認証の依頼元となる機器Ａであり、相互認証処理部２１とサービス依頼処理部２２とサービス結果処理部２３と公開鍵証明書記憶部２４と属性証明書記憶部２５とを備える。相互認証処理部２１は、公開鍵証明書記憶部２４から取得した自装置の公開鍵証明書ＰＫＣと、属性証明書記憶部２５から取得した自装置の属性証明書ＡＣと、サービス依頼先の機器のＵＲＬとを、認証要求とともに、認証サーバ１０に送信する。さらに、相互認証処理部２１は、認証要求の返信として認証サーバ１０から受けた認証サーバ１０の公開鍵証明書ＰＫＣから自装置の公開鍵証明書ＰＫＣまでの認証パスを検証する。サービス依頼処理部２２は、セッション開始要求を認証サーバ１０へ送信する。サービス結果処理部２３は、セッション開始要求の返信として認証サーバ１０から受けたサービス実施結果を受けて、これを機器Ａ２０の画面に表示する。
【００２１】
機器Ｂ３０は、サービスの依頼先となる機器であり、相互認証処理部３１とサービス実行処理部３２と公開鍵証明書記憶部３３と属性証明書記憶部３４とを備える。相互認証処理部３１は、認証サーバ１０から受けた認証サーバ１０の公開鍵証明書ＰＫＣから公開鍵証明書記憶部３３より取得した自装置の公開鍵証明書ＰＫＣまでの認証パスを検証し、検証に成功したときは、公開鍵証明書記憶部３３より取得した自装置の公開鍵証明書ＰＫＣと公開鍵証明書記憶部３３より取得した自装置の属性証明書ＡＣとを認証サーバ１０に送信する。サービス実行処理部３２は、認証サーバ１０からセッション開始要求を受けると、サービスを実施し、その実施結果をサービス実施結果として認証サーバ１０へ送信する。
ここで、図１にて図示はしていないが、認証サーバ１０と機器Ａ２０と機器Ｂ３０とは、ＬＡＮ（Local Area Network）などのネットワークで接続され、互いに通信可能である。
【００２２】
次に、図３を参照して、本実施形態における各証明書および各証明書の発行元認証局ＣＡの関係を説明する。本実施形態では、認証局ＣＡとしてＤｏｍａｉｎＡ４０のルートＣＡであるＣＡ−１Ａ４１、ＣＡ−１Ａ４１のサブＣＡであるＣＡ−２Ａ４２、さらにＣＡ−２Ａ４２のサブＣＡであるＣＡ−３Ａ４３と、ＤｏｍａｉｎＢ５０のルートＣＡであるＣＡ−１Ｂ５１、ＣＡ−１Ｂ５１のサブＣＡであるＣＡ−２Ｂ５２とからなり、各ドメインのルートＣＡであるＣＡ−１Ａ４１とＣＡ−１Ｂ５１とは、ホップ数が２までの範囲（inhibitPolicyMapping：２）で相互認証証明書にて互いに認証しあっている。認証サーバ２０の公開鍵証明書ＰＫＣは、ＣＡ−１Ａ４１が発行し、機器Ａ２０の公開鍵証明書ＰＫＣおよび属性証明書ＡＣをＣＡ−２Ｂ５２が発行し、機器Ｂ３０の公開鍵証明書ＰＫＣおよび属性証明書ＡＣをＣＡ−３Ａ４３が発行している。
【００２３】
次に、この認証システムの動作を図４の動作を説明する。まず、機器Ａ２０の相互認証処理部２１は、公開鍵証明書記憶部２４から取得した自装置の公開鍵証明書ＰＫＣと、属性証明書記憶部２５から取得した自装置の属性証明書ＡＣと、依頼先の機器である機器Ｂ３０のＵＲＬとを、認証要求とともに、認証サーバ１０に送信する（Ｓａ１）。機器Ａ２０から認証要求を受けた依頼元認証処理部１１は、認証要求とともに受けた機器Ａ２０の公開鍵証明書ＰＫＣから、認証サーバ１０の公開鍵証明書記憶部１３より取得した自装置の公開鍵証明書ＰＫＣまで認証パスが到達することを検証する（Ｓａ２）。
【００２４】
具体的な検証手順を説明する。ここでは、機器Ａ２０の公開鍵証明書ＰＫＣの発行元は認証局ＣＡ−２Ｂ５２であり、認証局ＣＡ−２Ｂ５２の公開鍵証明書ＰＫＣの発行元はその親認証局である認証局ＣＡ−１Ｂ５１であり、認証局ＣＡ−１Ｂ５１は相互認証証明書により認証局ＣＡ−１Ａ４１とホップ数２までの範囲で相互に認証しあっている。認証局ＣＡ−１Ａ４１は、認証サーバ１０の公開鍵証明書ＰＫＣの発行元なので、これが機器Ａ２０の公開鍵証明書ＰＫＣから認証サーバ１０の公開鍵証明書ＰＫＣまでの認証パスである。依頼元認証処理部１１は、この認証パスに沿って、各証明書の署名をその証明書の発行元の公開鍵証明書ＰＫＣに含まれる公開鍵にて検証するとともに、各証明書の有効期限が期限切れでないことを検証する。
【００２５】
これらの検証の結果、問題がなければ、依頼元認証処理部１１は、認証サーバ１０の公開鍵証明書ＰＫＣを公開鍵証明書記憶部１３から取得して、認証要求の送信元である機器Ａ２０に送信する（Ｓａ３）。機器Ａ２０は、認証サーバ１０の公開鍵証明書ＰＫＣを受けると、その相互認証処理部２１が、これを受けて、受けた認証サーバ１０の公開鍵証明書ＰＫＣから機器Ａ２０の公開鍵証明書ＰＫＣまで認証パスが到達することを、ステップＳａ２と同様の手順で検証する（Ｓａ４）。
【００２６】
検証の結果、問題がなければ、機器Ａ２０と認証サーバ１０の相互認証は完了し、サービス依頼処理部２２が、機器Ｂ３０に対するセッション開始要求を認証サーバ１０に送信する（Ｓａ５）。認証サーバ１０は、セッション開始要求を受けると、その依頼先認証処理部１２が、公開鍵証明書記憶部１３から自装置の公開鍵証明書ＰＫＣを取得して、取得した公開鍵証明書ＰＫＣをサービス依頼先である機器Ｂ３０へ送信する（Ｓａ６）。機器Ｂ３０は、認証サーバ１０の公開鍵証明書ＰＫＣを受けると、その相互認証処理部３１が、これを受けて、受けた認証サーバ１０の公開鍵証明書ＰＫＣから機器Ｂ３０の公開鍵証明書ＰＫＣまで認証パスが到達することを、ステップＳａ２と同様の手順で検証する（Ｓａ７）。
【００２７】
検証の結果、問題がなければ、相互認証処理部３１は、公開鍵証明書記憶部３３から自装置の公開鍵証明書ＰＫＣを取得して、取得した公開鍵証明書ＰＫＣを認証サーバ１０へ送信する（Ｓａ８）。認証サーバ１０の依頼先認証処理部１２は、相互認証処理部３１が送信した機器Ｂ３０の公開鍵証明書ＰＫＣを受けて、受けた機器Ｂ３０の公開鍵証明書ＰＫＣから認証サーバ１０の公開鍵証明書ＰＫＣまで認証パスが到達することを、ステップＳａ２と同様の手順で検証する（Ｓａ９）。
検証の結果、問題がなければ、機器Ｂ３０と認証サーバ１０の相互認証は完了しているので、依頼先認証処理部１２は、相互認証完了の通知を機器Ｂ３０に送信する（Ｓａ１０）。機器Ｂ３０は、相互認証完了の通知を受けると、相互認証処理部３１が、これを受けて、相互認証されたことを認識する。
【００２８】
一方、依頼先認証処理部１２が相互認証完了の通知を送信した後、認証サーバ１０では、ステップＳａ１１に遷移して図５に示すフローチャートで信頼性確認処理部１５が動作して、機器Ａ２０の公開鍵証明書ＰＫＣと機器Ｂ３０の公開鍵証明書ＰＫＣの信頼性確認、および、機器Ａ２０の属性証明書ＡＣと機器Ｂ３０の属性証明書ＡＣの信頼性確認を行う。このステップＳａ１１の信頼性確認処理が、従来のセンタ型にはなく、本発明における特徴的な処理である。
まず、信頼性確認処理部１５は、信頼性確認テーブル１７を参照して、確認元ＰＫＣのＣＡ名、シリアルＮｏ．がサービス依頼元である機器Ａ２０の公開鍵証明書ＰＫＣのＣＡ名、シリアルＮｏ．であり、確認先ＰＫＣのＣＡ名、シリアルＮｏ．がサービス依頼先である機器Ｂ３０の公開鍵証明書ＰＫＣのＣＡ名、シリアルＮｏ．であるレコードを検索し、該当レコードが存在するか否かを確認する（Ｓｂ１）。存在する場合は、信頼性確認処理部１５は、該当レコードに登録されている有効期限が切れているか否か（Ｓｂ２）、信頼性情報は「ＯＫ」であるか否かを確認する（Ｓｂ３）。
【００２９】
これらの確認で問題なければ、さらに、信頼性確認処理部１５は、信頼性確認テーブル１７を参照して、ステップＳｂ１とは逆向きに、確認元ＰＫＣのＣＡ名、シリアルＮｏ．がサービス依頼先である機器Ｂ３０の公開鍵証明書ＰＫＣのＣＡ名、シリアルＮｏ．であり、確認先ＰＫＣのＣＡ名、シリアルＮｏ．がサービス依頼元である機器Ａ２０の公開鍵証明書ＰＫＣのＣＡ名、シリアルＮｏ．であるレコードを検索し、該当レコードが存在するか否かを確認する（Ｓｂ４）。存在する場合は、信頼性確認処理部１５は、該当レコードに登録されている有効期限が切れているか否か（Ｓｂ５）、信頼性情報は「ＯＫ」であるか否かを確認する（Ｓｂ６）。これらの確認で問題なければ、機器Ａ２０と機器Ｂ３０の信頼性確認結果を「ＯＫ」とする（Ｓｂ７）。
【００３０】
しかし、どちらかのレコードの信頼性情報が「ＯＫ」でなく、「ＮＧ」であった場合は（Ｓｂ３、Ｓｂ６）、信頼性確認処理部１５は、信頼性確認結果を「ＮＧ］とする（Ｓｂ１１）。また、どちらかのレコードが存在しなかった場合（Ｓｂ１、Ｓｂ４）、あるいは、有効期限が切れていた場合は（Ｓｂ２、Ｓｂ５）は、信頼性情報生成処理部１６が、確認元の公開鍵証明書ＰＫＣから確認先の公開鍵証明書ＰＫＣまで認証パスが到達することを検証する（Ｓｂ８、Ｓｂ１２）。検証の結果、認証パスが到達したときは、信頼性情報生成処理部１６は、信頼性情報テーブル１７に該当するテーブルを作成し、信頼性情報に「ＯＫ」を、有効期限に現在時刻に所定の時間を足した値もしくは検証に用いた証明書の有効期限で最も近い値のうち、近い値を登録し（Ｓｂ９、Ｓｂ１３）、ステップＳｂ９の場合はステップＳｂ４に遷移し、ステップＳｂ１３の場合はステップＳｂ７に遷移する。
【００３１】
一方、ステップＳｂ８またはＳｂ１２における検証の結果、認証パスが到達できなかったときは、信頼性情報生成処理部１６は、信頼性情報テーブル１７に該当するテーブルを作成し、信頼性情報に「ＯＫ」を、有効期限に現在時刻に所定の時間を足した値を登録する（Ｓｂ１０、Ｓｂ１４）。これを受けて、信頼性確認処理部１５は、信頼性確認結果を「ＮＧ］とする（Ｓｂ１１）。
【００３２】
これにより、信頼性確認処理部１５は、依頼元機器の公開鍵証明書ＰＫＣと依頼先機器の公開鍵証明書ＰＫＣが互いに信頼可能であることを検証している。さらに、信頼性確認処理部１５は、依頼元機器の公開鍵証明書ＰＫＣが依頼先機器の属性証明書ＡＣを信頼可能であることと、依頼先機器の公開鍵証明書ＰＫＣが依頼元機器の属性証明書ＡＣを信頼可能であることの確認を、図５のフローチャートにおける確認先を公開鍵証明書ＰＫＣから属性証明書ＡＣに変更したフローにて実施する。
【００３３】
図５によるフローチャートの動作例を具体的に説明する。ここでは、まずステップＳｂ１にて該当レコードが存在しないとすると、ステップＳｂ８に遷移し、信頼性確認処理部１５は、サービス依頼先の公開鍵証明書ＰＫＣからサービス依頼元の公開鍵証明書ＰＫＣの発行元認証局に認証パスが到達可能か確認する。このときサービス依頼元の公開鍵証明書ＰＫＣは、機器Ａ２０の公開鍵証明書ＰＫＣであり、サービス依頼元の公開鍵証明書ＰＫＣの発行元認証局は、機器Ｂ３０の公開鍵証明書ＰＫＣの発行元認証局ＣＡ−２Ｂ５２である。
【００３４】
図３を参照して認証パスを確認すると、まず、機器Ｂ３０の公開鍵証明書ＰＫＣの発行元認証局は、認証局ＣＡ−３Ａ４３であり、認証局ＣＡ−３Ａ４３の発行元認証局は、認証局ＣＡ−２Ａ４２であり、認証局ＣＡ−２Ａ４２の発行元認証局は、認証局ＣＡ−１Ａ４１である。認証局ＣＡ−１Ａ４１は認証局ＣＡ−１Ｂ５１と相互認証証明書６０にて相互認証しあっており、認証局ＣＡ−１Ｂ５１のサブＣＡには、認証局ＣＡ−２Ｂ５２がある。この認証局ＣＡ−２Ｂ５２は前述のようにサービス依頼元である機器Ａ２０の公開鍵証明書ＰＫＣの発行元認証局である。これが認証パスになるが、相互認証証明書６０で制限しているホップ数を確認すると、機器Ｂ３０の公開鍵証明書ＰＫＣから認証局ＣＡ−１Ａ４１までのホップ数は、機器Ｂ３０の公開鍵証明書ＰＫＣから認証局ＣＡ−３Ａ４３、認証局ＣＡ−３Ａ４３から認証局ＣＡ−２Ａ４２、認証局ＣＡ−２Ａ４２から認証局ＣＡ−１Ａ４１の計３つである。このため、サービス依頼先である機器Ａ２０の公開鍵証明書ＰＫＣからサービス依頼元である機器Ｂ３０の公開鍵証明書ＰＫＣの発行元認証局に認証パスが到達できない。
【００３５】
このため、ステップＳｂ１０に遷移し、確認元ＰＫＣを機器Ａ２０の公開鍵証明書ＰＫＣ、確認先ＰＫＣを機器Ｂ３０の公開鍵証明書ＰＫＣとするレコードを信頼性情報テーブル１７に生成し、信頼性情報を「ＮＧ」、信頼性期限に現在時刻に所定の時間を足した値を登録し、信頼性確認結果を「ＮＧ」とする（Ｓｂ１１）。
信頼性確認処理部１５における、信頼性確認結果が「ＮＧ」のときは、機器Ａ２０からのセッション開始要求は破棄され、シーケンスは終了する。
【００３６】
信頼性確認結果が「ＯＫ」であったときは、サービス中継処理部１４は、ステップＳａ５で受けたセッション開始要求を、機器Ｂ３０へ送信する（Ｓａ１２）。機器Ｂ３０は、セッション開始要求を受けると、そのサービス実行処理部３２が、サービスを実施し（Ｓａ１３）、その結果をサービス実施結果として、認証サーバ１０に送信する（Ｓａ１４）。認証サーバ１０は、サービス実施結果を受けると、そのサービス中継処理部１４が、受けたサービス実施結果を機器Ａ２０へ送信する（Ｓａ１５）。機器Ａ２０は、サービス実施結果を受けると、そのサービス結果処理部２３が、サービス実施結果を画面に表示する。
【００３７】
なお、本実施形態において、機器Ａ２０の相互認証処理部２１と認証サーバ１０の依頼元認証処理部１１、依頼先認証処理部１２と機器Ｂ３０の相互認証処理部３１は、公開鍵証明書を用いた相互認証を行なうとして説明したが、これらの処理部の間で実施する認証は、共通鍵を用いた認証であってもよいし、ＩＤとパスワードやバイオメトリクスを用いた認証であってもよい。また、このとき、機器Ａ２０の相互認証処理部２１と認証サーバ１０の依頼元認証処理部１１の認証方法と、依頼先認証処理部１２と機器Ｂ３０の相互認証処理部３１の認証方法とは別々の認証方法であってもよい。
これにより、異なる認証方法を持つ機器の間でも、機器同士の認証関係に基づき信頼可否を判定することができる。
【００３８】
また、本実施形態における各認証を実施する際に使用する証明書は、各装置が備えていてもよいし、認証サーバ１０と機器Ａ２０と機器Ｂ３０とが接続されたネットワークにリポジトリを設置し、該リポジトリが記憶していてもよい。また、リポジトリに記憶するときは、認証局ＣＡのＤｏｍａｉｎ毎などにリポジトリを設置してもよい。
【００３９】
また、本実施形態における機器Ｂ３０が実施して機器Ａ２０に提供するサービスは、認証された相手だけに情報を開示するサービスであってもよい、認証された相手にだけ業務サービスを提供するＡＳＰ（Application Service Provider）であってもよい。
【００４０】
また、図１における依頼元認証処理部１１、依頼先認証処理部１２、サービス中継処理部１４、信頼性確認処理部１５、信頼性情報生成処理部１６、相互認証処理部２１、サービス依頼処理部２２、サービス結果処理部２３、相互認証処理部３１、サービス実行処理部３２の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりこれらの処理部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【００４１】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【００４２】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【図面の簡単な説明】
【００４３】
【図１】この発明の一実施形態による認証システムの概略構成を示すブロック図である。
【図２】同実施形態における信頼性情報テーブル１７の内容例を示す図である。
【図３】同実施形態における各証明書の発行元認証局の関係を説明する図である。
【図４】同実施形態における認証システムの動作を説明するためのシーケンス図である。
【図５】同実施形態における信頼性確認処理部１５および信頼性情報生成処理部１６の動作を説明するためのフローチャートである。
【図６】従来の認証システムの概略構成を示すブロック図である。
【図７】従来の認証システムにおける各証明書の発行元認証局の関係例を説明する図である。
【符号の説明】
【００４４】
１０…認証サーバ
１１…依頼元認証処理部
１２…依頼先認証処理部
１３…公開鍵証明書記憶部
１４…サービス中継処理部
１５…信頼性確認処理部
１６…信頼性情報生成処理部
１７…信頼性情報テーブル
２０…機器Ａ
２１…相互認証処理部
２２…サービス依頼処理部
２３…サービス結果処理部
２４…公開鍵証明書記憶部
２５…属性証明書記憶部
３０…機器Ｂ
３１…相互認証処理部
３２…サービス実行処理部
３３…公開鍵証明書記憶部
３４…属性証明書記憶部
４０…ＤｏｍａｉｎＡ
４１…認証局ＣＡ−１Ａ
４２…認証局ＣＡ−２Ａ
４３…認証局ＣＡ−３Ａ
５０…ＤｏｍａｉｎＢ
５１…認証局ＣＡ−１Ｂ
５２…認証局ＣＡ−２Ｂ
６０…相互認証証明書
１００…機器Ａ
１０１…機器Ｂ
１０２…機器Ｘ
２００…機器Ａ
２０１…機器Ｃ
２０２…機器Ｂ
２０３…機器Ｘ
３００…ＤｏｍａｉｎＡ
３０１…認証局ＣＡ−１Ａ
３０２…認証局ＣＡ−２Ａ
３０３…認証局ＣＡ−３Ａ
３１０…ＤｏｍａｉｎＢ
３１１…認証局ＣＡ−１Ｂ
３１２…認証局ＣＡ−２Ｂ
【図１】
2007274380.tif 000003
【図２】
2007274380.tif 000004
【図３】
2007274380.tif 000005
【図４】
2007274380.tif 000006
【図５】
2007274380.tif 000007
【図６】
2007274380.tif 000008
【図７】
2007274380.tif 000009