JP2005341095A - 端末装置、公開鍵の正当性を判断する方法、およびプログラム - Google Patents

端末装置、公開鍵の正当性を判断する方法、およびプログラム Download PDF

Info

Publication number
JP2005341095A
JP2005341095A JP2004155754A JP2004155754A JP2005341095A JP 2005341095 A JP2005341095 A JP 2005341095A JP 2004155754 A JP2004155754 A JP 2004155754A JP 2004155754 A JP2004155754 A JP 2004155754A JP 2005341095 A JP2005341095 A JP 2005341095A
Authority
JP
Japan
Prior art keywords
public key
partner
user
terminal device
trading
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2004155754A
Other languages
English (en)
Inventor
Masahiro Mimura
昌弘 三村
Kenta Takahashi
健太 高橋
Yoshiaki Isobe
義明 磯部
Yoichi Seto
洋一 瀬戸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2004155754A priority Critical patent/JP2005341095A/ja
Publication of JP2005341095A publication Critical patent/JP2005341095A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】公開鍵基盤を利用した電子商取引における相手先の信用を確認する。
【解決手段】利用者端末１００に、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持する手段と、通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得する手段と、前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得する手段と、前記取得した情報を用いて、前記通信相手の公開鍵が信用できるか否かを判断する手段と、を設ける。
【選択図】図１

Description

本発明は、電子商取引において、取引相手の信用度を確認するための技術に関し、特に、公開鍵基盤（PKI：Public Key Infrastructure）を利用した電子商取引において、取引相手の信用を確認する技術に関する。
公開鍵の正当性を確認する代表的な技術として、公開鍵基盤（PKI：Public Key Infrastructure）が知られている（例えば非特許文献１）。非特許文献１に記載のＰＫＩでは、公開鍵を利用する利用者の公開鍵に対する公開鍵証明書を認証局（ＣＡ局：Certification Authority）が発行する仕組みが開示されている。そして、上記の利用者と取引を行う取引相手は、ＣＡ局を信用することで、すなわち、ＣＡ局が発行する公開鍵証明書を信用することで利用者の公開鍵の正当性を確認する。このように、非特許文献１によれば、ＣＡ局を信用することで公開鍵を利用する利用者間の信用を構築することが可能となる。
また、公開鍵の正当性を確認する他の技術として、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｉｖａｃｙ（ＰＧＰ）がある（例えば非特許文献２）。上記のＰＧＰでは、「自分の信用する利用者が信用している他の利用者は信用できる」との考えに基づき、信用する利用者の公開鍵リストを公開することで、利用者間の信用を構築するようにしている。
さらに、ネットワーク上における信用構築システムには、ホームページなどのレイティング（格付け）システムがある（例えば、非特許文献３）。非特許文献３では、「多数の利用者から信用されるホームページは信用できる」との考えに基づき、ホームページへの信用を構築している。
C.Adams,S.Lloyd著（鈴木優一訳）「ＰＫＩ−公開鍵インフラストラクチャの概念、標準、展開」ピアソンエデュケーション出版、２０００年７月１５日、Ｐ２５〜３９ Simson Garfinkel著（山本和彦監訳）「ＰＧＰ 暗号メールと電子署名」オライリージャパン出版、１９９６年４月１５日、Ｐ２２３〜２６３ 山本早人、近藤秀和著「解説：サーチエンジンGoogle」情報処理学会出版、２００１年８月１５日、情報処理４２巻８号Ｐ７７５〜７８０
しかしながら、上述した非特許文献１〜３は、以下の問題を有している。
具体的には、非特許文献１に記載の公開鍵を利用する利用者間の信用の構築は、互いの利用者が認証を受けたＣＡ局が同一のグループに属していることを前提にしている。したがって、互いの利用者が認証を受けたＣＡ局が、それぞれ、異なるグループに属する場合に利用者同士が互いの公開鍵の正当性を確認することができないこととなる。ＣＡ局が異なるグループに属する場合には、例えば、互いの利用者が認証を受けたＣＡ局が、異なる上位ＣＡ局のグループに属する場合がある。また、上記非特許文献１では、ＣＡ局から取得した公開鍵証明書ではなく、自己証明書を提示する利用者への信用確認について特に考慮されていない。
上記非特許文献２では、共通の利用者がいない利用者間においては、相手の公開鍵の正当性を確認することができないという問題を有している。
また、非特許文献３の技術を、公開鍵の信用構築に利用することも考えられる。しかしながら、非特許文献３の技術を公開鍵の信用構築に利用した場合、一人の利用者が多数の利用者になりすますことで自身の信用度を不正に向上させることが可能となる。
そこで、本発明の目的は、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）を利用した電子商取引における相手先の信用を確認するシステムにおいて、公的な認証局（ＣＡ：Certification Authority）から公開鍵証明書の発行を受けていない取引相手や、自分の属する認証局と異なる認証局から公開鍵証明書の発行を受けている取引相手、或いは、認証局に属さない取引相手に対する信用確認を行うことにある。
上記課題を解決するため、本発明の一態様は、公開鍵基盤を利用したデータ通信に用いる端末装置に適用される。
そして、前記端末装置は、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持する手段と、通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得する手段と、前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得する手段と、
前記取得した情報を用いて、前記通信相手の公開鍵が信用できるか否かを判断する手段と、を有する。
このように本発明によれば、端末装置は、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持するようにしている。そして、端末装置は、信用の確認先である通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得している。また、端末装置は、前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得して、その情報により通信相手の公開鍵が信用できるか否かを判断している。
そのため、本発明によれば、公開鍵基盤を利用したデータ通信において、取引を行う相手が、自分が信用するＣＡ局からの認証を受けていない場合であっても、その取引相手の公開鍵が信用できる否かを判断することができる。
以下、本発明の実施形態について図面を用いて説明する。なお、以下の説明は、本実施形態が、インターネットを利用したネットオークション等の電子商取引における取引相手の信用確認に利用されている場合を例示したものである。
最初に本実施形態の概略構成を、図１を用いて説明する。
図１は、本実施形態の信用構築システムの概略構成を説明するための図である。
図示するように、本実施形態の信用構築システムは、複数の利用者端末Ａ〜Ｎ１００を有する。複数の利用者端末Ａ〜Ｎ１００は、ネットワーク（インターネット）を介して相互に接続されていている。そして、複数の利用者端末１００は、各々通信部を有し、インターネットを介して利用者端末１００間でデータ通信を行う。また、各利用者端末１００は、秘密鍵および公開鍵のペアを有していて、それらの鍵を利用して、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）による電子商取引を行う。
また、各利用者端末１００には、電子商取引を行う取引相手先の信用確認を行う機能が実装されている（取引相手の信用を確認する機能の具体的な構成については後段で詳細に説明する）。例えば、利用者端末Ａ１００の利用者が利用者端末Ｂ１００を利用する取引相手とＰＫIによる電子商取引を行う場合、利用者端末Ａ１００は、取引相手の「公開鍵の正当性」を確認する処理と、「取引相手の信用度」を検証する処理と、「個人情報の正当性」を検証する処理とを行う。そのため、本実施形態では、ネットオークション等に参加して、インターネット上で商取引を行う場合の取引の安全を確保することができる。
なお、本実施形態では、取引相手先の信用確認を行う機能は利用者端末１００に実装されているものとして説明するが、特にこれに限定するものではない。例えば利用者のホームページを開設しているＷＥＢサーバにＣＧＩ機能として、以下で説明する取引相手先の信用確認を行う機能が実装されてもよい。また、本実施形態では、利用者端末１００は、インターネットに接続されている場合を例にしているが、ネットワークはインターネットでなくてもよい。
続いて、本実施形態の利用者端末１００の機能構成について図２〜５を用いて説明する。
図２は、本実施形態の利用者端末の機能構成のブロック図を説明するための図である。
利用者端末１００は、公開鍵確認部１１１、信用度取得部１１２、個人情報検証部１１３、上記各部（公開鍵確認部１１１、信用度取得部１１２、および個人情報検証部１１３）が他の利用者端末１００と情報交換するための通信部１１４、取引相手情報テーブル１２０、利用者情報テーブル１２１、およびポリシーテーブル１２２を有する。
公開鍵確認部１１１は、取引相手の公開鍵の正当性を確認するための処理を行う。また、公開鍵確認部１１１は、自利用者端末１００が保持する公開鍵に対する正当性の確認を他の利用者端末１００から要求された場合、取引相手情報テーブル１２０から「取引相手先のアクセス先」および「取引相手の証明書」を読み出して（取引相手情報テーブル１２０のデータ構造は後述する）、その要求を行った利用者端末１００に返信する。さらに、公開鍵確認部１１１は、他の利用者端末１００から、他の利用者端末１００が確認処理を行っている「公開鍵」に対する問い合わせを受け付けた場合、取引相手情報テーブル１２０に格納されたデータを用いて、その「公開鍵」の問い合わせに対する確認情報を、その問い合わせを行った利用者端末１００に返信する。なお、公開鍵確認部１１１が実行する上記の処理は、後段で詳細に説明する。
信用度取得部１１２は、取引相手が信用できるか否かを判断するための処理を行う。また、信用度取得部１１２は、他の利用者端末１００の利用者に対する信用度の問い合わせを受け付けた場合、受け付けた利用者に対する信用度を示すデータをその問い合わせをした利用者端末１００に送信する。なお、信用度取得部１１２が実行する上記の処理は、後段で詳細に説明する。
個人情報検証部１１３は、取引相手の個人情報の正当性を確認するための処理を行う。また、個人情報検証部１１３は、他の利用者端末１００の利用者の個人情報に対する問い合わせを受け付けた場合、問い合わせを受け付けた利用者の個人情報を示すデータのハッシュ値を算出する。そして、個人情報検証部１１３は、算出したハッシュ値を、問い合わせをしてきた利用者端末１００に送信する。なお、個人情報検証部１１３が実行する上記の処理は、後段で詳細に説明する。
次に、取引相手情報テーブル１２０、利用者情報テーブル、およびポリシーテーブル１２２について説明する。
図３は、本実施形態の取引情報交換テーブル１２０のデータ構造を模擬的に示した図である。
取引相手情報テーブル１２０は、利用者端末１００を利用する利用者の取引相手先のデータを格納するためのテーブルである。図示するように、取引相手情報テーブル１２０は、「取引相手先のアクセス先１２０ａ」、「取引相手の証明書（公開鍵証明書）１２０ｂ」、「取引相手の信用度１２０ｃ」、および「取引相手の個人情報１２０ｄ」を１レコードとしたテーブルである。
「取引先のアクセス先１２０」とは、取引先の利用者端末１００に割り当てられている「ＩＰアドレス」のことを言うが、特に、これに限定するものではない。「取引先のアクセス先１２０」は、例えば、「ＵＲＬ（Uniform Resource Locator）」やネットワーク上で一意に定めた利用者端末の「端末名」等でもよい。他の利用者端末１００からその利用者端末１００（取引先の利用者端末）に対してアクセス可能なものであればよい。
「取引相手の証明書（公開鍵証明書）１２０ｂ」とは、取引相手が有する公開鍵に対する公開鍵証明書のことをいう。本実施形態の「証明書」は、ＩＴＵ-Ｔで規格化されている「Ｘ５０９」準拠していることとするが、特にこれに限定するものではない。公開鍵の証明書としては、少なくとも「公開鍵」を示すデータおよび、「公開鍵証明書の発行者」を示すデータを含んでいればどのようなフォーマットを用いてもかまわない。また、「証明書」は、ＣＡ局から取得したものに限定されない。本実施形態の「証明書」には、取引相手が自己で発行した証明書も含まれる。これは、公開鍵の利用者のよっては、公開鍵の証明書をＣＡ局から取得せず、自己証明書を発行している場合もあるためである。
「取引相手の信用度１２０ｃ」とは、本実施形態の信用構築システムに参加する利用者間において所定の規則により定めた信用度を示す数値のことをいう。以下では、説明を簡単にするため、取引相手の信用度を「１」から「５」までの５段階で表記し、値が大きいほど信用度が高いことを意味するものとする（信用度の詳細については後述する）。
「取引先の個人情報１２０ｄ」とは、取引相手の氏名、住所、連絡先などを示すデータをいう。本実施形態では、個人情報はShift-JISコードを用いてテキストデータとして記録するがこの限りではなく、どのようなフォーマットを用いて個人情報を記録してもかまわない。
続いて、利用者情報テーブル１２１のデータ構造を、図４を用いて説明する。図４は、本実施形態の利用者情報テーブル１２１のデータ構造を模擬的に示した図である。
利用者情報テーブル１２１は、利用者端末１００を利用する利用者自身のデータを格納するためのテーブルである。利用者情報テーブル１２１は、利用者の「秘密鍵１２１ａ」およびそのペアの「公開鍵１２１ｂ」と、「公開鍵１２１ｂ」の「証明書１２１ｃ」と、「利用者自身の個人情報１２１ｄ」とを１レコードとしたテーブルである。
なお、本実施形態では、公開鍵暗号として、６４ｂｉｔＲＳＡ暗号を用いることとするが、特にこの限りではない。どのような公開鍵暗号方式を用いても本実施形態は実現可能である。また、利用者自身の公開鍵の「証明書１２１ｃ」のデータ構造は、図３で説明した取引相手の「証明書１２０ｄ」で説明したデータ構造と同様である。また、利用者の「個人情報１２１ｄ」のデータ構造についても、図３で説明した取引相手の「個人情報１２０ｄ」のデータ構造と同様である。
続いて、ポリシーテーブル１２２のデータ構造を、図５を用いて説明する。
図５は、本実施形態のポリシーテーブル１２２のデータ構造を模擬的に示した図である。
ポリシーテーブル１２２は、取引相手を信用できるか否かを判断するために利用者端末１００が利用する「しきい値」を格納するためのテーブルである。ポリシーテーブル１２２は、「公開鍵信用しきい値」を格納するエントリ１２２ａ、「信用度しきい値」を格納するエントリ１２２ｂ、および「個人情報しきい値」を格納するエントリ１２２ｃを有する。
「公開鍵信用しきい値」とは、取引相手の公開鍵が信用できるものであるか否かについて、公開鍵確認部１１１が判断する際に用いるしきい値である。「信用度しきい値」とは、取引先が取引相手として信用できるか否かについて、信用度取得部１１２が判断する際に用いるしきい値である。また、「個人情報しきい値」とは、取引相手先が公表している取引相手先の個人情報が信用できるか否かについて、個人情報検証部１１３が判断する際に用いるしきい値である。なお、「公開鍵信用しきい値」、「信用度しきい値」、および「個人情報しきい値」については、後述する。また、ポリシーテーブル１２２の各エントリ１２２ａ〜ｃのデータは、利用者端末１００のデフォルトとして、或いは、利用者からの入力により各エントリ１２２ａ〜ｃに格納されるものとする。
続いて、本実施形態の利用者端末１００のハードウェア構成を、図６を用いて説明する。
図６は、本実施形態のおける利用者端末１００のハードウェア構成を説明するための図である。
図示するように、利用者端末１００には、ＣＰＵ（Central Processing Unit）２０１、データや各種プログラムを記憶するハードディスク等の補助記憶装置２０２、ＣＰＵが実行するプログラムやデータを一時的に記憶するＲＡＭ（Random Access Memory）等の主記憶装置２０３、およびネットワークインタフェース２０５を有するコンピュータを用いることができる。また、図示するように、利用者端末１００には、ＣＲＴや液晶ディスプレイ等のモニタ２０６、およびキーボードやマウス等の入力装置２０４が接続されていてもよい。なお、本実施形態では、データ、プログラム等を記憶する記憶装置として、ハードディスクを例示しているが、この限りではなく、ハードディスクの代わりに不揮発性のメモリ（ＥＥＰＲＯＭ）などで代替したり、ＲＯＭ（Read Only Memory）などで代替することも可能である。また、ＣＰＵ２０１、補助記憶装置２０２、主記憶装置２０３、ネットワークインタフェース２０５、モニタ２０６、および入力装置２０４は、バス２０９で接続されて、各々が、ＣＰＵ２０１を介してデータをやりとりすることが可能である。また、ＣＰＵ２０１は、必要に応じてネットワークインタフェース２０５を介してインターネットに接続した他の利用者端末１００と通信を行う。
ＣＰＵ２０１は、必要なデータを主記憶装置２０３に書き込み、読出しつつ、補助記憶装置２０２上に保存されたデータを利用する。また。ＣＰＵ２０１は、補助記憶装置２０２上に保存された各種プログラムを実行する。なお、上述した各部（公開鍵確認部１１１、信用度取得部１１２、個人情報検証部１１３、および通信部１１４）の機能を実現するための各プログラム（公開鍵確認プログラム、信用度取得プログラム、個人情報検証プログラム、および通信プログラム）は、補助記憶装置２０２に記憶されている。そして、上記各部の機能は、ＣＰＵ２０１が、補助記憶装置２０２に記憶されている各プログラムを主記憶装２０３にロードして実行することにより実現される。また、上記の各テーブル（取引相手情報テーブル１２０、利用者情報テーブル１２１、およびポリシーテーブル１２２）は、補助記憶装置２０２あるいは主記憶装置２０３の所定領域に保持されている。
続いて、本実施形態の信用構築システムの処理の概略フローを説明する。
図７は、本実施形態の信用構築システムの概略フローを説明するための図である。以下で説明する概略フローでは、利用者Ａ、Ｂ、Ｃx、Ｄxは、それぞれ、利用者端末Ａ１００、Ｂ１００、Ｃx１００、Ｄx１００を利用していることとする。なお、記号「Ｃx」および「Ｄx」に付した「ｘ」とは、利用者を示すインデックスを指すものとする。「ｘ」の数は利用者Ｂあるいは利用者Ｃｘの取引状況などによって異なる。また、以下の概略フローは、利用者Ａが利用者Ｂと取引を行うにあたって、利用者端末Ａ１００を用いて行う利用者Ｂに対する信用確認処理を例示している。
さて、本実施形態の信用構築システムが行う概略フローは、公開鍵取得・検証フェーズＡ４０１、信用情報取得フェーズＡ４０２、および個人情報取得・検証フェーズＡ４０３の３つのフェーズに分類されている。
公開鍵取得・検証フェーズＡ４０１では、利用者Ａの利用者端末Ａ１００は、利用者Ｂの利用者端末Ｂ１００から利用者Ｂの公開鍵Ｂを取得する処理を行う。また、利用者端末Ａ１００は、利用者端末Ｂ１００、利用者Ｂと過去に取引実績のある利用者Ｃxの利用者端末Ｃx１００、および利用者Ｃxと過去に取引実績のある利用者Ｄxの利用者端末Ｄx１００と必要な情報を交換することで、利用者Ｂの公開鍵Ｂの正当性を検証する処理を行う。なお、図示する、公開鍵取得・検証フェーズＡ４０１では、公開鍵Ｂを検証するために、利用者Ｂの取引相手である利用者Ｃxの利用者端末Ｃｘ１００、および利用者Ｃxの取引相手である利用者Ｄxの利用者端末Ｄx１００と情報交換を行っているが、これは、例示に過ぎない。場合によっては、さらに多数の利用者端末１００（例えば、利用者Ｄxの取引相手である利用者Ｅxの利用者端末Ｅx１００）と情報の交換を行う場合がある。
信用情報取得フェーズＡ４０２では、利用者端末Ａ１００は、利用者端末Ｃx１００と必要な情報を交換することで、利用者Ｂの取引相手としての信用度を取得して、利用者Ｂを信用できるか否かの検証を行う。
個人情報取得・検証フェーズＡ４０３では、利用者端末１００Ａは、利用者端末Ｂ１００および利用者端末Ｃx１００の各々と必要な情報を交換することで、利用者Ｂの個人情報を取得し、その正当性を検証する。
続いて、公開鍵取得・検証フェーズＡ４０１、信用情報取得フェーズＡ４０２、および個人情報取得・検証フェーズＡ４０３で行われる処理を詳細に説明する。
最初に公開鍵取得・検証フェーズＡ４０１で行われる処理について、図８〜１０を用いて説明する。
図８は、本実施形態の公開鍵取得・検証フェーズで行われる処理のフローを説明するための図である。なお、以下で説明する各処理ステップは、各利用者端末（Ａ、Ｂ、Ｃx、Ｄx）１００の公開鍵確認部１１１により実現されるものである。
さて、利用者Ａの利用者端末Ａ１００の公開鍵確認部１１１は、入力装置２０４を介して利用者が入力する利用者Ｂに対する信用確認の指示を受け付けて、公開鍵取得・検証フェーズＡ４０１の処理を開始する。そして、利用者端末Ａ１００の公開鍵確認部１１１は、主記憶装置２０３の所定のエリアに利用者Ｂの公開鍵の正当性を検出するために用いる評価値算出テーブル９００を生成する。ここで、評価値算出テーブル９００について図９を用いて説明する。
図９は、利用者Ｂの評価値算出テーブル９００を模擬的に示した図である。図示するように、評価値算出テーブル９００は、利用者Ｂの取引先を格納するエントリ９００ａと、エントリ９００ａに格納された取引先の評価を格納するエントリ９００ｂとを有する。なお、評価値算出テーブル９００の各エントリ９００ａ、ｂのデータは、以下で説明する処理ステップで格納される。そのため、現ステップでは、評価値算出テーブル９００の各エントリ９００ａ、ｂにはデータは格納されていない。
図８に戻り、説明を続ける。利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ｂ１００に対して、利用者Ｂの証明書を要求する（Ｓ５０１）。具体的には、利用者端末Ａ１００の公開鍵確認部１１１は、通信部１１４を介して利用者Ｂの「証明書を要求するデータ」を利用者端末Ｂ１００に送信する。
続いて、利用者端末Ｂ１００の公開鍵確認部１１１は、利用者端末Ａ１００が送信した「証明書を要求するデータ」を、通信部１１４を介して受け付ける。利用者端末Ｂ１００の公開鍵確認部１１１は、利用者端末Ｂ１００の利用者情報テーブルに格納されている利用者Ｂの証明書を利用者端末Ａ１００に送信する（Ｓ５２１）。
利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ｂ１００が送信した利用者Ｂの証明書を受信する。利用者端末Ａ１００の公開鍵確認部１１１は、受信した利用者Ｂの証明書に含まれる利用者Ｂの公開鍵を用いて、利用者端末Ｂ１００に対して暗号通信セッションの確立を要求する（Ｓ５０２）。そして、利用者端末Ａ１００から暗号通信セッションの確立を要求された利用者端末Ｂ１００は、利用者端末Ａ１００との間で暗号通信セッションを確立する（Ｓ５２２）。なお、暗号通信の具体的な手段については、特に限定しないが、例えば、暗号通信として、ＳＳＬ（Secure Socket Layer）などを用いて実現すればよい。
上記Ｓ５０２、Ｓ５２２により、暗号通信が確立されると、利用者端末Ａ１００の公開鍵確認部１１１は、利用者Ｂの過去の取引先情報を利用者端末Ｂ１００に対して要求する（Ｓ５０３）。具体的には、利用者端末Ａ１００の公開鍵確認部１１１は、「利用者Ｂの過去の取引先情報を要求するデータ」を利用者端末Ｂ１００に送信する。
利用者端末Ｂ１００の公開鍵確認部１１１は、利用者端末Ａ１００が送信した「利用者Ｂの過去の取引先情報を要求するデータ」を、通信部１１４を介して受け付ける。利用者端末Ｂ１００の公開鍵確認部１１１は、利用者端末Ｂ１００Ｂの取引先情報テーブル１２０に格納されている「取引相手のアクセス先１２０ａ」および「取引相手の照明書１２０ｂ」のリストを、利用者端末Ａ１００に送信する（Ｓ５２３）。なお、ここで送信されるデータは前ステップ（Ｓ５２２）により暗号化されている。
利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ｂ１００が送信した「取引相手のアクセス先１２０ａ」および「取引相手の照明書１２０ｂ」のリストを受信する。利用者端末Ａ１００の公開鍵確認部１１１は、上記の受信したリストの中から利用者Ｂの公開鍵の正当性を確認するための確認先として、第１の利用者Ｃxを選択する。以後取引先情報の第１の利用者をＣ１と称する（Ｓ５０４）。
利用者端末Ａ１００の公開鍵確認部１１１は、Ｓ５０４で選択した確認先の「アクセス先」およびアクセス先の証明書に含まれる「公開鍵」を用いて、利用者端末Ｃ１１００に暗号化通信のセッション確立を要求する（Ｓ５０５）。そして、利用者端末Ａ１００から暗号通信セッションの確立を要求された利用者端末Ｃ１１００は、利用者端末Ａ１００との間で暗号通信セッションを確立する（Ｓ５４１）。なお、暗号通信の具体的な手段については、特に限定しないが、例えば、暗号通信として、ＳＳＬ（Secure Socket Layer）などを用いて実現すればよい。
利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ｃ１１００に対して、Ｓ５０２で取得した利用者Ｂの公開鍵を送信し、利用者Ｂの公開鍵の確認を要求する（Ｓ５０６）。
利用者端末Ｃ１１００の公開鍵確認部１１１は、利用者端末Ａ１００が送信した、利用者Ｂの公開鍵の確認要求を受信する。利用者端末Ｃ１１００の公開鍵確認部１１１は、受信した利用者Ｂの公開鍵が利用者端末Ｃ１１００の取引相手情報テーブル１２０に含まれているか否かを確認する。利用者端末Ｃ１１００の公開鍵確認部１１１は、確認できた場合に「ＹＥＳ」を示す確認情報を生成し、確認できなかった場合に「ＮＯ」を示す確認情報を生成する（Ｓ５４２）。そして、利用者端末Ｃ１１００の公開鍵確認部１１１は、Ｓ５４２の結果（確認情報）を利用者端末Ａ１００に送信する（Ｓ５４３）。
利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ｃ１１００が送信した確認情報を受信する。利用者端末Ａ１００の公開鍵確認部１１１は、受信した確認情報が「ＹＥＳ」を示すデータである場合にＳ５０８に進み、受信した確認情報が「ＮＯ」を示すデータである場合にＳ５０９に進む（Ｓ５０７）。
Ｓ５０８では、利用者端末Ａ１００の公開鍵確認部１１１は、Ｓ５０４で選択した確認先を評価値算出テーブル９００のエントリ９００ａに格納して、Ｓ５０９に進む。
Ｓ５０９では、利用者端末Ａ１００の公開鍵確認部１１１は、ステップ５０４で受信したすべての取引先について、Ｓ５０５からＳ５０８で行う処理が終了したか否かを判定する。そして、利用者端末Ａ１００の公開鍵確認部１１１は、Ｓ５０４で受信したすべての取引先について、Ｓ５０５からＳ５０８の処理が終了したと判断した場合にＳ５１０に進み、上記終了していない場合にＳ５０４に戻る。
Ｓ５１０では、利用者端末Ａ１００の公開鍵確認部１１１は、Ｓ５０４で取得した「取引相手の照明書１２０ｂ」を利用して、評価値算出テーブル９００のエントリ９００ａに格納されているすべての確認先の証明書を検証する。具体的には、利用者端末Ａ１００の公開鍵確認部１１１は、利用者Ａが信用するＣＡ局を示すデータ（例えば、リスト形式のデータ）を保持している。そして、利用者端末Ａ１００の公開鍵確認部１１１は、上記のエントリ９００ａに格納されている確認先の証明書の発行者が、上記保持するＣＡ局を示すデータに含まれる場合に、エントリ９００ａに対応するエントリ９００ｂに「１」を格納する。一方、利用者端末Ａ１００ａの公開鍵確認部１１１は、上記のエントリ９００に格納されている確認先の証明書の発行者が、上記保持するＣＡ局を示すデータに含まれていない場合に、エントリ９００ａに対応するエントリ９００ｂに「０」を格納する。
続いて、利用者端末Ａ１００の公開鍵確認部１１１は、評価テーブル９００のエントリ９００ｂに格納された値の合計値を算出する。利用者端末Ａ１００の公開鍵確認部１１１は、利用者端末Ａ１００のポリシーテーブル１２２からエントリ１２２ａに格納されている「公開鍵信用しきい値」を読み出す。なお、ポリシーテーブル１２２のエントリ１２２ａには、人数を示すデータが予め格納されていることとする。そして、利用者端末Ａ１００の公開鍵確認部１１１は、算出した合計値および読み出した「公開鍵信用しきい値」を比較する。利用者端末Ａ１００の公開鍵確認部１１１は、比較した結果、算出した合計値が「公開鍵信用しきい値」以上の場合に利用者Ｂの公開鍵を信用できるものと判断して、信用情報取得フェーズＡ４０２へ移行する。一方、利用者端末Ａ１００の公開鍵確認部１１１は、比較した結果、算出した合計値が「公開鍵信用しきい値」を未満の場合、Ｓ５１２の処理に進む（Ｓ５１１）。
Ｓ５１２では、利用者端末Ａ１００の公開鍵確認部１１１は、評価値算出テーブル９００のエントリ９００ｂに格納された評価値が「０」の取引先に対して、ステップ５０２からステップ５１０の処理を行い、評価値算出テーブル９００のエントリ９００ｂの評価値を更新する処理を行う。すなわち、ここでは、利用者端末Ａ１００の公開鍵確認部１１１は、Ｓ５１０において信用できる利用者であると確認できなかった利用者Ｃxから、その利用者Ｃxの取引先Ｄxのデータ（「取引相手のアクセス先１２０ａ」および「取引相手の照明書１２０ｂ」のリスト）を取得する。この際、利用者端末Ａ１００の公開鍵確認部１１１は、主記憶装置２０３の所定のエリアに利用者Ｃxの公開鍵の正当性を検出するために用いる、図１０に示す評価値算出テーブル１０００を生成する。なお、図１０は、利用者Ｃｘの評価値算出テーブルを模擬的に示した図であり、データ構造は図９と同様である。
そして、利用者端末Ａ１００の公開鍵確認部１１１は、取得した取引先Ｄxから上記Ｓ５４３と同様の確認データを取得して、利用者Ｃxの評価値算出テーブル１０００にデータを格納する。利用者端末Ａ１００の公開鍵確認部１１１は、評価値算出テーブル１０００を利用して、再度、利用者Ｃxを信用できるか否かを判断して、評価値算出テーブル９００を更新する。そして、利用者端末Ａ１００の公開鍵確認部１１１は、更新した評価値算出テーブル９００を用いて、Ｓ５１１の処理を行う。以上の処理を繰り返し、利用者Ｂの公開鍵の正当性を確認できた場合に、信用情報取得フェーズＡ４０２へ移行する。
例えば、利用者Ｂの評価値算出テーブル９００が図９に示す場合、すなわち、評価値の合計値が「２」とする。また、ポリシーテーブル１２２に予め設定された「公開鍵信用しきい値」が「３」であるとする。この場合、利用者端末Ａ１００の公開鍵確認部１１１は、利用者Ｂの公開鍵の正当性を確認できないと判断する（評価値の合計値が「公開鍵信用しきい値」未満であるため）。
このような場合、本実施形態では、利用者Ｃ３に対して、ステップ５０２からステップ５１０の処理を行う。そして、利用者Ｃ３の評価値算出テーブル１０００が図１０に示す結果となったとする。その結果、利用者端末Ａ１００の公開鍵確認部１１１は、利用者Ｃ３を信用できると判断して、図９に示す評価値算出テーブルのＣ３の「評価値」を「１」に更新する（評価値の合計値が「３」となり「公開鍵信用しきい値」以上となるため）。
その後、利用者端末Ａ１００の公開鍵確認部１１１は、更新した利用者Ｂの評価値算出テーブル９００を再評価すると、評価値の合計値が「３」となり「公開鍵信用しきい値」以上となるため、利用者Ｂの公開鍵を信用できると判断する。
なお、本実施形態では、説明を簡単にするため、利用者Ｃ３の取引相手である利用者Ｄxの利用者端末Ｄxまでを利用する場合を例にしたが、これは、例示に過ぎない。
また、公開鍵確認部１１１は、Ｓ５１１で行う判定回数を予め設定しておくこととする。そして、あらかじめ設定した回数の確認を行ってもポリシーテーブル１２２に格納した「公開鍵信用しきい値」を満足する評価値の合計が得られなかった場合、利用者端末Ａ１００ａは、利用者Ｂの公開鍵を信用できないと判定して、その旨を利用者Ａに告知する。
このように、本実施形態の公開鍵取得・検証フェーズＡ４０１では、利用者端末Ａ１００は、利用者Ｂの公開鍵の正当性を確認する際に、利用者Ｂの利用者端末Ｂ１００から「利用者Ｂの取引先（利用者Ｃx）のデータ」を取得している。また、利用者端末Ａ１００は、利用者Ｃxの利用者端末Ｃx１００に利用者Ｂと取引を行っているかを確認し、確認がとれた利用者Ｃxを信用できるか否かを検証して、信用できると検証した利用者Ｃxの「数」により利用者Ｂの公開鍵の「正当性」を確認するようにしている。具体的には、利用者端末Ａ１００は、利用者Ａの信用するＣＡ局により認証されている公開鍵を有する利用者Ｃxの数により、利用者Ｂの公開鍵の正当性を確認するようにしている。
そのため、本実施形態の公開鍵取得・検証フェーズＡ４０１では、公的なＣＡ局から公開鍵証明書の発行を受けていない取引相手や、自分の属するＣＡ局と異なる認証局から公開鍵証明書の発行を受けている取引相手、或いは、認証局に属さない取引相手の公開鍵の正当性を確認することができる。
また、本実施形態では、利用者Ｂの公開鍵の正当性を判断するために用いられる利用者Ｃxの公開鍵の証明書は、利用者Ａの信用するＣＡ局により認証されている必要がある。そのため、本実施形態によれば、利用者Ｂが単独で多数の取引相手Ｃxになりすますことを防ぐことができる。すなわち、利用者Ｂが自分の公開鍵の正当性を証明するために、多数の取引相手Ｃxになりすますことを防ぐことができる。
続いて、本実施形態の信用情報取得フェーズＡ４０２で行われる処理について、図１１を用いて説明する。
図１１は、本実施形態の信用情報取得フェーズＡ４０２で行われる処理のフローを説明するための図である。なお、以下で説明する各処理ステップは、各利用者端末１００の信用度取得部１１２によって実現されるものである。
さて、最初に利用者端末Ａ１００の信用度取得部１１２は、上述した公開鍵確認部１１１からの「信用情報取得処理の開始を指示する通知」を受け付けて処理を開始する。なお、公開鍵確認部１１１は、利用者Ｂの公開鍵の正当性を確認できた場合に上記通知を行う。
最初に、利用者端末Ａ１００の信用度取得部１１２は、図８で示したＳ５０５と同様の手順により、利用者端末Ｃ１１００に暗号化通信のセッション確立を要求する（Ｓ８０１）。また、利用者端末Ａ１００ａから暗号通信セッションの確立を要求された利用者端末Ｃ１１００は、図８で示したＳ５４１と同様の手順により、利用者端末Ａ１００との間で暗号通信セッションを確立する（Ｓ８１１）。
続いて、利用者端末Ａ１００の信用度取得部１１２は、利用者端末Ｃ１１００に対して利用者Ｂの信用度の送信を要求する（Ｓ８０２）。具体的には、利用者端末Ａ１００の信用度取得部１１２は、「利用者Ｂの信用度の送信を要求するデータ」を利用者端末Ｃ１１００に送信する。
利用者端末Ｃ１１００の信用度取得部１１２は、利用者端末Ａ１００が送信した「利用者Ｂの信用度の送信を要求するデータ」を受信する。利用者端末Ｃ１１００の信用度取得部１１２は、利用者端末Ｃ１１００の取引相手情報テーブル１２０に格納された「取引相手の信用度１２０ｃ」の中から、「利用者Ｂの信用度」を選択して、利用者端末Ａ１００に送信する（Ｓ８２１）。
利用者端末Ａ１００の信用度取得部１１２は、利用者端末Ｃ１１００が送信した「利用者Ｂの信用度」を受信する。そして、利用者端末Ａ１００の信用度取得部１１２は、利用者Ｂと取引のある利用者すべてから信用度を取得した場合はＳ８０４へ進む。一方、利用者端末Ａ１００の信用度取得部１１２は、利用者Ｂと取引のある利用者すべてから信用度を取得していない場合、Ｓ８０１に戻りＳ８０１〜Ｓ８０３の処理を繰り返す（Ｓ８０３）。すなわち、利用者端末Ａ１００の信用度取得部１１２は、利用者Ｂと取引のある利用者すべてから信用度を取得する。なお、上記の利用者Ｂと取引のある利用者とは、公開鍵・取得検証フェーズＡ４０１において、利用者Ｂの評価テーブル９００のエントリ９００ａに格納された取引先のことをいう。
Ｓ８０４では、利用者端末Ａ１００の信用度取得部１１２は、利用者端末Ｃｘ１００から取得した利用者Ｂへの「信用度の平均値」を算出する。利用者端末Ａ１００の信用度取得部１１２は、利用者端末Ａ１００のポリシーテーブル１２２からエントリ１２２ｂに格納されている、予め定めた「信用度しきい値」を読み出す。利用者端末Ａ１００の信用度取得部１１２は、算出した「信用度の平均値」と、読み出した「信用度しきい値」とを比較する。そして、利用者端末Ａ１００の信用度取得部１１２は、比較した結果、算出した「信用度の平均値」が読み出した「信用度しきい値」以上の場合に、取引相手として利用者Ｂを信用できると判断して、個人情報取得・検証フェーズＡ４０３に移行する。一方、利用者端末Ａ１００の信用度取得部１１２は、算出した「信用度の平均値」が読み出した「信用度しきい値」未満である場合、利用者Ｂは、取引相手として信用できないもの判断して、その旨を利用者Ａに告知して処理を終了する。
このように、本実施形態の信用構築システムでは、自分が「過去に取引した取引相手の信用度」を各利用者端末１００に保持させるようにしている。そして、本実施形態の信用情報取得フェーズＡ４０２では、公開鍵の正当性を確認した利用者に対して、さらに、取引相手として信用できるか否かを判断するようにしている。具体的には、公開鍵の正当性を確認した利用者に対して、その利用者の取引先の利用者端末１００にアクセスして、その利用者端末１００が保持する「その利用者への信用度」を取得するようにしている。そのため、本実施形態によれば、公開鍵の正当性の確認に加えて、さらに、取引相手が信用できるか否かについても確認することができる。なお、本実施形態では、取引を行う相手が信用できるか否かを、その相手の「取引相手」が保持する信用度を取得し、取得した信用度の平均値により取引相手が信用できるか否かについて確認するようにしているが、これは、例示に過ぎない。例えば、取得した信用度の中から、所定の信用度を満足する数を算出して、その算出した数により取引相手が信用できるか否かについて確認するようにしてもよい。
続いて、本実施形態の個人情報取得・検証フェーズＡ４０３で行われる処理について、図１２を用いて説明する。
図１２は、本実施形態の個人情報取得・検証フェーズＡ４０３で行われる処理のフローを説明するための図である。なお、以下で説明する各処理ステップは、各利用者端末１００の個人情報検証部１１３によって実現されるものである。
さて、最初に利用者端末Ａ１００の個人情報検証部１１３は、上述した信用度取得部１１２からの「個人情報取得・検証処理の開始を指示する通知」を受けて処理を開始する。なお、信用度取得部１１２は、利用者Ｂが取引相手として信用できると判断した場合に上記通知を行う。
最初に、利用者端末Ａ１００の個人情報検証部１１３は、図８で示したＳ５０５と同様の手順により、利用者端末Ｂ１００に暗号通信のセッション確立を要求する（Ｓ９０１）。また、利用者端末Ａ１００から暗号通信セッションの確立を要求された利用者端末Ｂは、図８で示したＳ５４１と同様の手順により、利用者端末Ａ１００との間で暗号通信セッションを確立する（Ｓ９１１）。
続いて、利用者端末Ａ１００の個人情報検証部１１３は、利用者端末Ｂ１００に対して個人情報を要求する（Ｓ９０２）。具体的には、利用者端末Ａ１００の個人情報検証部１１３は、「利用者Ｂの個人情報」を要求するデータを利用者端末Ｂ１００に送信する。
利用者端末Ｂ１００の個人情報検証部１１３は、利用者端末Ａ１００が送信した「利用者Ｂの個人情報」を要求するデータを受信する。利用者端末Ｂ１００の個人情報検証部１１３は、利用者端末Ｂ１００の利用者情報テーブル１２１に格納された「個人情報１２１ｄ」を利用者端末Ａ１００に送信する（Ｓ９１２）。なお、ここで送信される「個人情報１２１ｄ」は暗号化されている。
利用者端末Ａ１００の個人情報検証部１１３は、利用者端末Ｂ１００が送信した利用者Ｂの「個人情報１２１ｄ」を受信する。利用者端末Ａ１００の個人情報検証部１１３は、受信した利用者Ｂの「個人情報１２１ｄ」のハッシュ値を算出する（Ｓ９０３）。なお、本実施形態では、ハッシュ値を算出するための具体的な手段を限定しない。例えば、ハッシュ値を算出には、「ＳＨＡ-１（Secure Hash Algorithm 1）」などを用いるようにすればよい。
続いて、利用者端末Ａ１００の個人情報検証部１１３は、上記Ｓ９０１と同様の手順により、利用者端末Ｃ１１００に暗号化通信のセッション確立を要求する（Ｓ９０４）。また、利用者端末Ａ１００ａから暗号通信セッションの確立を要求された利用者端末Ｃ１１００は、上記Ｓ９１１同様の手順により、利用者端末Ａ１００との間で暗号通信セッションを確立する（Ｓ９２１）。
利用者端末Ｃ１１００との間で暗号通信セッションが確立された後、利用者端末Ａ１００の個人情報検証部１１３は、利用者端末Ｃ１１００に対して、利用者Ｂの個人情報のハッシュ値を要求する（Ｓ９０５）。具体的には、利用者端末Ａ１００の個人情報検証部１１３は、「利用者Ｂの個人情報のハッシュ値」の検証を要求するデータを利用者端末Ｃ１１００に送信する。
利用者端末Ｃ１１００の個人情報検証部１１３は、利用者端末Ａ１００が送信した「利用者Ｂの個人情報のハッシュ値」を要求するデータを受信する。そして、利用者端末Ｃ１１００の個人情報検証部１１３は、利用者端末Ｃ１１００の取引相手情報テーブル１２０に格納された、取引相手の個人情報１２０ｄの中から、「利用者Ｂの個人情報」を読み出す。利用者端末Ｃ１１００の個人情報検証部１１３は、読み出した「利用者Ｂの個人情報」から、上記Ｓ９０３と同様の手順により、「利用者Ｂの個人情報のハッシュ値」を算出して、利用者端末Ａ１００に送信する（Ｓ９２２）。
利用者端末Ａ１００の個人情報検証部１１３は、利用者端末Ｃ１１００が送信した「利用者Ｂの個人情報のハッシュ値」を受信する。利用者端末Ａ１００の個人情報検証部１１３は、利用者Ｂの全ての取引先から「利用者Ｂの個人情報のハッシュ値」を取得できた場合にＳ９０７に進み、それ以外は、Ｓ９０４の処理に戻る（Ｓ９０６）。
Ｓ９０７では、利用者端末Ａ１００の個人情報検証部１１３は、ステップ９０３で算出した「利用者Ｂの個人情報のハッシュ値」と、ステップ９０４からステップ９０６で取得した「利用者Ｂの個人情報のハッシュ値」を比較する。そして、利用者端末Ａ１００の個人情報検証部１１３は、一致しているハッシュ値の数をカウントする。利用者端末Ａ１００の個人情報検証部１１３は、ポリシーテーブル１２２のエントリ１２２ｃに格納されている、予め定めた「信用度しきい値」を読み出す。利用者端末Ａ１００の個人情報検証部１１３は、カウントした「一致したハッシュ値の数」と読み出した「信用度しきい値」と比較して、「一致したハッシュ値の数」が「信用度しきい値」以上の場合に個人情報の正当性が確認できたものとして具体的な商取引に進む。一方、利用者端末Ａ１００の個人情報検証部１１３は、上記比較の結果、「一致したハッシュ値の数」が「信用度しきい値」未満の場合、利用者Ｂの個人情報の正当性が確認できないと判断して、その旨を利用者Ａに告知して処理を終了する。
このように、本実施形態の個人情報取得・検証フェーズＡ４０３では、利用者端末Ａ１００は、利用者端末Ｂ１００から取得した利用者Ｂの個人情報を確認するため、利用者Ｂの取引相手である利用者Ｃの利用者端末Ｃxに、利用者Ｂの個人情報のハッシュ値を送付させ、利用者Ｂの個人情報の正当性を確認するようにしている。そのため、本実施形態によれば、利用者Ｂの個人情報は、利用者端末Ｂから利用者端末Ａに開示されるだけで、その正当性を確認することができる。
このように、本実施形態によれば、ネットオークション等のようにネットワーク上で商取引を行う際に、取引相手が信用できるＣＡ局の証明書を有していない等の理由により取引相手が提示する情報だけで相手先を信用できない場合であっても、取引相手のプライバシーを保護したままで、「取引相手に公開鍵の正当性」、「取引相手の取引上の信用」、および「取引相手の個人情報の正当性」を確認することができる。これにより、本実施形態によれば、ネットオークション等のような、ネットワーク上で行う商取引の安全を確保することができる。
なお、本発明は、以上で説明した実施形態に限定されるものではなく、本発明の要旨の範囲内において種々の変形が可能である。
例えば、図８に示したフローのＳ５２３において、利用者端末Ｂ１００が自分の「取引相手の証明書（公開鍵証明書）」を利用者端末Ａ１００宛てに送信することとしたが、以下のようにしてもよい。具体的には、Ｓ５２３において、利用者端末Ｂ１００は、自分の「取引相手のアクセス１２０ａ」だけを利用者端末Ａ１００に送信するようにする。そして、利用者端末Ａ１００は、Ｓ５０６において、利用者端末Ｃx１００に対して、利用者Ｂの公開鍵確認要求とともに、利用者Ｃxの公開鍵の「証明書１２１ｃ」の送信も要求する。利用者端末Ｃx１００は、Ｓ５４３において、利用者端末Ａ１００に対して、確認情報と共に自身の公開鍵の「証明書１２１ｃ」を送信する。このように、利用者Ｂの「取引相手の証明書」を、取引相手自身から取得するようにしても、図８のフローと同様の効果、すなわち、取引相手Ｂの公開鍵の正当性の確認を行うことができる。
また、例えば、図１２のフローのＳ９２２において、利用者端末Ｃx１００が、利用者Ｂの個人情報の「ハッシュ値」を生成し、利用者端末Ａ１００に送信することとしたが、利用者端末Ｃx１００が「ハッシュ値」を利用者端末Ａ１００に送信しないで、以下のようにしてもよい。具体的には、Ｓ９０４において、利用者端末Ａ１００の個人情報検証部１１３は、Ｓ９０３で生成した利用者Ｂの個人情報の「ハッシュ値」を利用者端末Ｃｘ１００に送信する。利用者端末Ｃx１００は、上記利用者Ｂの個人情報の「ハッシュ値」を受信した場合、自身が保持する利用者Ｂの個人情報から利用者Ｂの個人情報の「ハッシュ値」を生成する。利用者端末Ｃx１００は、受信した「ハッシュ値」および自身が生成した「ハッシュ値」を比較して、ハッシュ値が一致しているか否かを示す比較結果を利用者端末Ａ１００に送信する。利用者端末Ａ１００は、比較結果を受信する。そして、利用者端末Ａ１００、ハッシュ値が一致している旨を示す比較結果を送信した利用者端末Ｃx１００の数が、「個人情報信用しきい値」以上の場合に利用者Ｂの個人情報を信用するようにしてもよい。
本発明の実施形態の信用構築システムの概略構成を説明するための図である。 本発明の実施形態の利用者端末の機能構成のブロック図を説明するための図である。 本発明の実施形態の取引情報交換テーブルのデータ構造を模擬的に示した図である。 本発明の実施形態の利用者情報テーブルのデータ構造を模擬的に示した図である。 本発明の実施形態のポリシーテーブルのデータ構造を模擬的に示した図である。 本発明の実施形態の利用者端末１００のハードウェア構成を説明するための図である。 本発明の実施形態の信用構築システムが行う概略フローを説明するための図である。 本発明の実施形態の公開鍵取得・検証フェーズで行われる処理のフローを説明するための図である。 本実施形態の評価値算出テーブルを模擬的に示した図である。 本実施形態の評価値算出テーブルを模擬的に示した図である。 本実施形態の信用情報取得フェーズで行われる処理のフローを説明するための図である。 本実施形態の個人情報取得・検証フェーズで行われる処理のフローを説明するための図である。
符号の説明
１００…利用者端末、１１１…公開鍵確認部、１１２…信用度取得部、１１３…個人情報検証部、１１４…通信部、１２０…取引相手情報テーブル、１２１…利用者情報テーブル、１２２…ポリシーテーブル、２０１…ＣＰＵ、２０２…補助記憶装置、２０３…主記憶装置、２０４…入力装置、２０５…ネットワークインタフェース、２０６…モニタ

Claims (12)

  1. 公開鍵基盤を利用したデータ通信に用いる端末装置であって、
    利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持する手段と、
    通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得する手段と、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得する手段と、
    前記取得した情報を用いて、前記通信相手の公開鍵が信用できるか否かを判断する手段と、を有すること
    を特徴とする端末装置。
  2. 公開鍵基盤を利用したデータ通信に用いる端末装置であって、
    利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持する手段と、
    通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得する手段と、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得する手段と、
    前記取得した情報を用いて、前記通信相手と取引を行っている取引相手を特定する手段と、
    前記取得した取引相手の公開鍵証明書を用いて、前記特定した取引相手が信用できるか否かを判断する手段と、
    前記信用できると判断した前記取引相手の数により、前記通信相手の公開鍵が信用できるか否かを判断する手段と、を有すること
    を特徴とする端末装置。
  3. 請求項２に記載の端末装置であって、
    前記通信相手の公開鍵が信用できると判断できなかった場合、前記信用できると判断されなかった取引相手の前記公開鍵証明書に含まれる公開鍵を信用できるか否かにより、該取引相手の信用を再判断する手段と、
    前記再判断した後で、前記信用できると判断した前記取引相手の数により、前記通信相手の公開鍵が信用できるか否かを判断する手段と、を有し、
    前記再判断する手段は、
    前記信用できると判断されなかった取引相手を確認相手と特定し、該確認相手が利用する端末装置から、該確認相手の取引相手の公開鍵証明書、および、該確認相手の取引相手が利用する端末装置のネットワークアドレスを取得する手段と、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記確認相手の公開鍵が含まれているか否かを示す情報を取得する手段と、
    前記取得した情報を用いて、前記確認相手と取引を行っている取引相手を特定する手段と、
    前記取得した確認相手の取引相手の公開鍵証明書を用いて、前記特定した取引相手が信用できるか否かを判断する手段と、
    前記信用できると判断した前記取引相手の数により、前記確認相手の公開鍵が信用できるか否かを判断する手段と、を有すること
    を特徴とする端末装置。
  4. 請求項２または３に記載の端末装置であって、
    前記特定した取引相手が信用できるか否かを判断する手段は、前記取得した公開鍵証明書に含まれる該公開鍵証明書を発行したＣＡ局（Certification Authority）が、所定のＣＡ局であることを条件にして該取引相手を信用すること
    を特徴とする端末装置。
  5. 請求項１から４のいずれか一項に記載の端末装置であって、
    利用者の取引相手の信用度を示すデータを保持していて、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置が保持する利用者の取引相手の信用度を示すデータを取得する手段と、
    前記取得した信用度を示すデータを用いて、前記通信相手が取引上信用できる相手か否かを判断する手段と、を有すること
    を特徴とする端末装置。
  6. 請求項２から５のいずれか一項に記載の端末装置であって、
    利用者の個人情報、および該利用者の取引相手の個人情報信用を保持していて、
    前記通信相手の端末装置から、当該端末装置の利用者の個人情報を取得する手段と、
    前記取得した前記個人情報のハッシュ値を生成する手段と、
    前記取得したネットワークアドレスにより特定される端末装置に前記生成したハッシュ値を送信すると共に、その送信したハッシュ値と該端末装置が保持する前記通信相手の個人情報から生成するハッシュ値とが一致するか否かの確認を要求する手段と、
    前記要求に応答して、前記端末装置が送信する前記一致するか否かのデータを受信して、前記一致する旨を示すデータの数により、前記取得した通信相手の個人情報が信用できるか否かを判断する手段と、を有すること
    を特徴とする端末装置。
  7. 公開鍵基盤を利用したデータ通信に用いる端末装置が行う公開鍵の正当性を判断する方法であって、
    前記端末装置は、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持していて、
    前記端末装置は、
    通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得するステップと、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得するステップと、
    前記取得した情報を用いて、前記通信相手の公開鍵の正当性を判断するステップと、を実行すること
    を特徴公開鍵の正当性を判断する方法。
  8. 公開鍵基盤を利用したデータ通信に用いる端末装置が行う公開鍵の正当性を判断する方法であって、
    前記端末装置は、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持していて、
    前記端末装置は、
    通信相手の端末装置から、当該端末装置の利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用する端末装置のネットワークアドレスを取得するステップと、
    前記取得したネットワークアドレスにより特定される端末装置から、当該端末装置の利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得するステップと、
    前記取得した情報を用いて、前記通信相手と取引を行っている取引相手を特定するステップと、
    前記取得した取引相手の公開鍵証明書を用いて、前記特定した取引相手が信用できるか否かを判断するステップと、
    前記信用できると判断した前記取引相手の数により、前記通信相手の公開鍵が信用できるか否かを判断するステップと、を実行すること
    を特徴とする公開鍵の正当性を判断する方法。
  9. 請求項８に記載の公開鍵の正当性を判断する方法であって、
    前記特定した取引相手が信用できるか否かの判断は、前記取得した公開鍵証明書に含まれる当該公開鍵証明書を発行したＣＡ局（Certification Authority）が、所定のＣＡ局であるか否かにより行うこと
    を特徴とする公開鍵の正当性を判断する方法。
  10. 公開鍵基盤を利用したデータ通信に用いるコンピュータに公開鍵の正当性を判断させる処理を実行させるプログラムであって、
    前記コンピュータは、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持していて、
    前記プログラムは、
    通信相手のコンピュータから、当該コンピュータの利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用するコンピュータのネットワークアドレスを取得するステップと、
    前記取得したネットワークアドレスにより特定されるコンピュータから、当該コンピュータの利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得するステップと、
    前記取得した情報を用いて、前記通信相手の公開鍵の正当性を判断するステップと、をコンピュータに実行させること
    を特徴とするプログラム。
  11. 公開鍵基盤を利用したデータ通信に用いるコンピュータに公開鍵の正当性を判断させる処理を実行させるプログラムであって、
    前記コンピュータは、利用者の公開鍵、該利用者の取引相手の公開鍵証明書および該取引相手が利用する端末装置のネットワークアドレスを保持していて、
    前記プログラムは、
    通信相手のコンピュータから、当該コンピュータの利用者の公開鍵、該利用者の取引相手の公開鍵証明書、および、該取引相手が利用するコンピュータのネットワークアドレスを取得するステップと、
    前記取得したネットワークアドレスにより特定されるコンピュータから、当該コンピュータの利用者の取引相手の公開鍵証明書に、前記通信相手の公開鍵が含まれているか否かを示す情報を取得するステップと、
    前記取得した情報を用いて、前記通信相手と取引を行っている取引相手を特定するステップと、
    前記取得した取引相手の公開鍵証明書を用いて、前記特定した取引相手が信用できるか否かを判断するステップと、
    前記信用できると判断した前記取引相手の数により、前記通信相手の公開鍵が信用できるか否かを判断するステップと、をコンピュータに実行させること
    を特徴とするプログラム。
  12. 請求項１１に記載のプログラムであって、
    前記特定した取引相手が信用できるか否かの判断は、前記取得した公開鍵証明書に含まれる当該公開鍵証明書を発行したＣＡ局（Certification Authority）が、所定のＣＡ局であるか否かにより判断すること
    を特徴とするプログラム。

JP2004155754A 2004-05-26 2004-05-26 端末装置、公開鍵の正当性を判断する方法、およびプログラム Pending JP2005341095A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004155754A JP2005341095A (ja) 2004-05-26 2004-05-26 端末装置、公開鍵の正当性を判断する方法、およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004155754A JP2005341095A (ja) 2004-05-26 2004-05-26 端末装置、公開鍵の正当性を判断する方法、およびプログラム

Publications (1)

Publication Number Publication Date
JP2005341095A true JP2005341095A (ja) 2005-12-08

Family

ID=35494167

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004155754A Pending JP2005341095A (ja) 2004-05-26 2004-05-26 端末装置、公開鍵の正当性を判断する方法、およびプログラム

Country Status (1)

Country Link
JP (1) JP2005341095A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006270504A (ja) * 2005-03-24 2006-10-05 Mitsubishi Electric Corp 検証装置及び通信システム
JP2008097434A (ja) * 2006-10-13 2008-04-24 Toppan Printing Co Ltd 認証システム及び認証方法
WO2008099739A1 (ja) * 2007-02-06 2008-08-21 Nec Corporation 個人情報の改ざん防止と個人情報流通否認防止のための個人情報管理装置、サービス提供装置、プログラム、個人情報管理方法、照合方法、および個人情報照合システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006270504A (ja) * 2005-03-24 2006-10-05 Mitsubishi Electric Corp 検証装置及び通信システム
JP4667921B2 (ja) * 2005-03-24 2011-04-13 三菱電機株式会社 検証装置及び通信システム及びトラストストア管理装置及びトラストストア監視装置
JP2008097434A (ja) * 2006-10-13 2008-04-24 Toppan Printing Co Ltd 認証システム及び認証方法
WO2008099739A1 (ja) * 2007-02-06 2008-08-21 Nec Corporation 個人情報の改ざん防止と個人情報流通否認防止のための個人情報管理装置、サービス提供装置、プログラム、個人情報管理方法、照合方法、および個人情報照合システム

Similar Documents

Publication Publication Date Title
US11223614B2 (en) Single sign on with multiple authentication factors
JP7181539B2 (ja) 利用者識別認証データを管理する方法および装置
US20200396089A1 (en) Digital certificate management method and apparatus, computer device, and storage medium
US11411949B2 (en) Trusted communication session and content delivery
CN108259438B (zh) 一种基于区块链技术的认证的方法和装置
US9264236B2 (en) Embedded extrinsic source for digital certificate validation
US20050097316A1 (en) Digital signature method based on identification information of group members, and method of acquiring identification information of signed-group member, and digital signature system for performing digital signature based on identification information of group members
US20200218830A1 (en) Method and server for certifying an electronic document
JP5475035B2 (ja) 認証権限移譲システム、情報端末、トークン発行局、サービス提供装置、認証権限移譲方法、及びプログラム
US9124571B1 (en) Network authentication method for secure user identity verification
JP2008022526A (ja) 属性証明書検証方法、属性認証局装置、サービス提供装置、および属性証明書検証システム
JP2011525028A (ja) エンドポイントの独立解決によるデジタルアイデンティティ又はトークンの取得
WO2006115522A1 (en) Peer-to-peer authentication and authorization
MX2012011105A (es) Autoridad de certificado.
JP2023503607A (ja) 自動デジタル証明書検証のための方法およびデバイス
US8312526B2 (en) Method and system for delegating authority with restricted access right in an online collaborative environment
EP3286894B1 (en) Security model for identification and authentication in encrypted communications using delegate certificate chain bound to third party key
US11924211B2 (en) Computerized device and method for authenticating a user
KR20120030092A (ko) 휴대가능한 이용자 평판을 인에이블하기 위한 방법 및 디바이스
KR100750214B1 (ko) 공인 인증서를 이용한 로그인 방법
EP2916509B1 (en) Network authentication method for secure user identity verification
US8656303B2 (en) Method and system for certifying webforms
JP2005341095A (ja) 端末装置、公開鍵の正当性を判断する方法、およびプログラム
CN105379176A (zh) 用于验证scep证书注册请求的系统和方法
JP5793593B2 (ja) ユーザ識別情報を安全に検証するためのネットワーク認証方法