JP4698678B2 - データ通信方法、コンピュータ及び情報記憶媒体 - Google Patents

Description

本発明はデータ通信方法、コンピュータ及び情報記憶媒体に関し、特に２以上のプロセッサを備えるコンピュータによるデータ通信に関する。

従来のデータ通信プロトコルは、１つのコンピュータが１つのプロセッサのみ含む場合にはそのプロセッサが、または１つのコンピュータが複数のプロセッサを含む場合にはそのうちの１つのプロセッサが代表となって、他のコンピュータと通信を行うことを前提としたものであった。

２つのコンピュータ間でセキュアな通信を行う場合には、通常は、コンピュータのユーザと、別のコンピュータのユーザとの間で公開鍵証明書（電子証明書）を交換する等して、セキュアな通信を行うか、またはＳＳＬ（Secure Socket Layer）（またはＴＬＳ（Transport Layer Security））を利用して、クライアントコンピュータがサーバコンピュータから公開鍵証明書付の公開鍵を取得し、その後、一方で生成された共通鍵を秘密裡に共有することによってクライアントとサーバ間のセキュアなデータ通信を実現するようなことがなされていた。

ＳＳＬ（またはＴＬＳ）においては、インターネットプロトコルのトランスポートレイヤとアプリケーションレイヤの中間にＳＳＬレイヤを設けることによってデータを交換する。この方式は、コンピュータを代表するプロセッサが１つに限られる場合には十分であるが、ワンチッププロセッサに内蔵される２つ以上のプロセッサの各々が、外部のコンピュータとの間で相互認証を必要とするような通信を行うためには不十分であった。

本発明は上記課題に鑑みてなされたものであって、その目的は、２以上のプロセッサを備えるコンピュータにより好適にセキュアなデータ通信を行うことができるデータ通信方法、コンピュータ及び情報記憶媒体を提供することにある。

上記課題を解決するために、本発明に係るデータ通信方法は、２以上のプロセッサをそれぞれ備える第１コンピュータと、第２コンピュータとの間のデータ通信方法であって、前記第１コンピュータから前記第２コンピュータに対して、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを送信する送信ステップと、前記第２コンピュータから前記第１コンピュータに対して、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書を含むデータを返信する返信ステップと、前記第１コンピュータが前記第２コンピュータから、前記返信ステップにより返信されるデータを受信する受信ステップと、前記第１コンピュータにおいて、前記受信ステップで受信されるデータから、該データに含まれるプロセッサＩＤを取得する取得ステップと、前記第１コンピュータにおいて、前記第１コンピュータに備えられる前記２以上のプロセッサのうち、前記取得ステップで取得されるプロセッサＩＤにより識別されるものにより、前記受信ステップで受信されるデータを処理する処理ステップと、前記第１コンピュータにおいて、前記受信ステップで受信されるデータに含まれる公開鍵証明書の内容に応じて、前記処理ステップによる処理を制限する認証ステップと、を含むことを特徴とする。

本発明では、プロセッサＩＤを含むデータを第１コンピュータから第２コンピュータに送信し、第２コンピュータは該プロセッサＩＤを含むデータを返信する。そして、第１コンピュータでは、受信したデータに含まれるプロセッサＩＤにより識別されるプロセッサにて、受信したデータの処理を行う。この際、受信したデータには、第２コンピュータに関連する公開鍵証明書が含まれており、第１コンピュータでは、この公開鍵証明書の内容に応じて、データ処理を制限する。本発明によれば、このようにプロセッサを特定した通信を行い、またデータ処理を公開鍵証明書の内容に応じて制限できるので、２以上のプロセッサを備えるコンピュータにより好適にセキュアなデータ通信を行うことができる。

また、本発明の一態様では、前記送信ステップは、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤに加えて、該プロセッサＩＤにより識別されるプロセッサに関連する公開鍵証明書をさらに含むデータを送信し、前記返信ステップは、前記送信ステップで送信されるデータに含まれる公開鍵証明書の内容に応じて、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書を含むデータを返信する。こうすれば、公開鍵証明書の内容により、第２コンピュータが第１コンピュータと信頼関係を構築できないと判断する場合に、第２コンピュータから第１コンピュータへのデータの返信を制限できる。

なお、前記送信ステップは、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤをヘッダの少なくとも一部として、通信内容をペイロードとして含むデータを前記第２コンピュータに送信するようにしてもよい。

また、前記返信ステップは、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書をヘッダの少なくとも一部として、通信内容をペイロードとして含むデータを前記第１コンピュータに返信するようにしてもよい。

また、本発明に係るコンピュータは、２以上のプロセッサと、前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを他のコンピュータに送信するデータ送信手段と、前記他のコンピュータから前記２以上のプロセッサのうち１つを識別するプロセッサＩＤ及び公開鍵証明書を含むデータを受信するデータ受信手段と、前記データ受信手段により受信されるデータから、該データに含まれるプロセッサＩＤを取得するプロセッサＩＤ取得手段と、前記２以上のプロセッサのうち、前記プロセッサＩＤ取得手段により取得されるプロセッサＩＤにより識別されるものにより、前記データ受信手段により受信されるデータを処理するデータ処理手段と、前記データ受信手段により受信されるデータに含まれる公開鍵証明書の内容に応じて、前記データ処理手段による処理を制限する認証手段と、を含むことを特徴とする。

また、本発明に係る情報記憶媒体は、２以上のプロセッサを備えるコンピュータにより実行されるプログラムであって、前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを他のコンピュータに送信するデータ送信手段、前記他のコンピュータから前記２以上のプロセッサのうち１つを識別するプロセッサＩＤ及び公開鍵証明書を含むデータを受信するデータ受信手段、前記データ受信手段により受信されるデータから、該データに含まれるプロセッサＩＤを取得するプロセッサＩＤ取得手段、前記２以上のプロセッサのうち、前記プロセッサＩＤ取得手段により取得されるプロセッサＩＤにより識別されるものにより、前記データ受信手段により受信されるデータを処理するデータ処理手段、及び前記データ受信手段により受信されるデータに含まれる公開鍵証明書の内容に応じて、前記データ処理手段による処理を制限する認証手段としてコンピュータを機能させるためのプログラムを記憶した情報記憶媒体である。このプログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等のコンピュータ読み取り可能な情報記憶媒体に格納されてもよい。また、コンピュータは、家庭用ゲーム機、業務用ゲーム機、携帯ゲーム機、携帯電話機、携帯情報端末、パーソナルコンピュータ、サーバコンピュータ等である。

データ通信に使用されるプロトコルスタックの一例を示す図である。 本発明の一実施形態に係るコンピュータのハードウェア構成図である。 図１に示すコンピュータに備えられたサブプロセッサの構成例を示す図である。 データ通信システムの一例を示す図である。 ピアノード選択・認証・登録処理のフローチャートである。 ピアノードの構成例を示す図である。 本実施形態に係るデータ通信システムに含まれるピアノード間の信頼関係の一例を示す図である。 １つのサブプロセッサが複数のピアノードと認証を行う場合における、ピアノード選択・認証・登録処理のフローチャートである。 １つのサブプロセッサが複数のピアノードと認証を行う場合における、ピアノードアクセステーブルの一構成例を示す図である。 本実施形態に係るデータ通信システムに含まれるピアノード間の信頼関係の他の例を示す図である。 １つのサブプロセッサが複数のピアノードと認証を行い、かつ信頼関係のないピアノードに対しても検索依頼を行う場合における、ピアノード選択・認証・登録処理のフローチャートである。 １つのサブプロセッサが複数のピアノードと認証を行い、かつ信頼関係のないピアノードに対しても検索依頼を行う場合における、ピアノードアクセステーブルの一構成例を示す図である。 本実施形態に係るセキュアプロトコルフレームの通信プロトコル全体における位置づけを示す図である。 本実施形態に係るセキュアプロトコルフレームの構成図である。 本実施形態に係るセキュアプロトコルヘッダの構成例である。 ピアノードが指定されている場合に、指定されたピアノードに処理要求を行う処理を示すフローチャートである。 ピアノードが指定されていない場合に、いずれかのピアノードに処理要求を行う処理を示すフローチャートである。 ピアノードに処理要求を行ったコンピュータが、該ピアノードから返信されるセキュアプロトコルフレームを受信した場合の処理を示すフローチャートである。 サブプロセッサ（ＳＰＥ）とピアノード間のタスク依頼・結果受信の処理の流れを示すシーケンス図である。 本実施形態に係るコンピュータの機器構成例を示す図である。

以下、本発明の一実施形態について図面に基づき詳細に説明する。

図１は、通信プロトコルのスタックを示す図であり、同図に示すように、データ通信は、物理層、データリンク層、ネットワーク層、トランスポート層及び応用層のそれぞれに属するプロトコルに従って実行されている。各層のプロトコルは階層的に配置されており、それらの例は同図に示されている通りである。本実施形態では、ワンチップマルチコアプロセッサを備えるコンピュータによるセキュアなデータ通信を実現するために、トランスポート層と応用層の間に位置する通信プロトコルを規定している。

図２は、本実施形態に係るデータ通信方法で使用されるコンピュータのシステム構成例である。このコンピュータ３１の特徴の一つは、ワンチップマルチコアプロセッサ３２を備えていることである。このワンチップマルチコアプロセッサ３２は、プロセッサコア４０を有するメインプロセッサ３９、プロセッサコア３４を有するサブプロセッサ３３ａ〜３３ｈ、Ｉ／Ｏインタフェース４８、並びにメモリコントローラ４６という、合計１１のプロセッシングエレメント（情報処理手段）がリングバス４５に結合され、それぞれ並列動作するように構成されている。さらに、各プロセッシングエレメントは、例えば「ＳＰＥ１」といったＩＤによってリングバス４５上でユニークに認識（特定）され、このＩＤによって、どのエレメントがどのエレメントにリングバス４５を経由してリクエストを出しているか特定できる。

メモリコントローラ４６は、メインメモリ４７と結合され、各プロセッシングエレメントがメインメモリ４７にアクセスする仲介を行う。なお、図２では、メインメモリ４７はワンチップマルチコアプロセッサ３２の外部に描かれているが、メインメモリ４７がワンチップマルチコアプロセッサ３２内部に含まれる構成でもよい。Ｉ／Ｏインタフェース４８に対して、様々なＩ／Ｏデバイス（ネットワークインタフェース５０、不揮発性メモリ５１、ＤＶＤドライバ５２、ＵＳＢポート５３に接続されるキーボード等の入力インタフェース５４等）と接続するためのサウスブリッジ４９、フレームメモリ５６を備えると共にモニタ５７に対する表示出力を制御するグラフィックスカード５５、あるいはアンテナ６１を用いたワイヤレス通信を可能にするＲＦ処理部５９等を接続させることによって、メインプロセッサ３９やサブプロセッサ３３が、外部装置を制御したり、外部装置とのコミュニケーションを通じてデータをやり取りすることが可能になる。このシステムはネットワークインタフェース５０を介してデータ通信ネットワークに接続されており、メインプロセッサ４２及びサブプロセッサ３３は、それぞれ独立してネットワーク上の各種機器と通信できるようになっている。また、ＲＦ処理部５９で取得される受信信号はダウンコンバータ６０により周波数変換され、ＡＤコンバータ５８によりデジタルデータに変換された後、ＩＯインタフェース４８に供給される。

サブプロセッサ３３は、それぞれコア３４、ローカルストレージ（ＬＳ）３５、ＤＭＡＣ（Direct Memory Access Controller）３７を内蔵するメモリフローコントローラ（ＭＦＣ）３６、並びに秘密鍵を内蔵するセキュアメモリ３８を構成要素として含んでいる。セキュアメモリ３８は、コア３４により排他的に（つまり当該セキュアメモリ３８と同じサブプロセッサ３３に設けられたコア３４からのみ）アクセスされるＲＡＭ等の記憶手段である。図３（ａ）に示すように、セキュアメモリは、ローカルストレージ（ＬＳ）３５の一部であってもよいし、図３（ｂ）に示すように、専用のハードウェア（コア３４から排他的にアクセスされるＲＡＭ等の記憶手段）として独立していてもよい。この場合、専用のハードウェアは、不揮発性メモリであってもよいし、揮発性メモリであっても構わない。さらに、図３（ａ）及び（ｂ）に示されるように、ローカルストレージ（ＬＳ）３５は、公開鍵６３、公開鍵６３を第三者機関によって証明したことを示す公開鍵証明書６４、並びに外部のピアノードに対するアクセスに関する情報（アドレス等）を保持したピアノードアクセステーブル６５を保持する。

各サブプロセッサ３３は、それぞれ固有のローカルストレージ３５を有するため、一度プログラムが、ローカルストレージ３５にロードされれば、それ以降は、必要のない限りメインメモリ４７にアクセスしなくとも処理を継続することができる。

メインプロセッサ３９は、コア４０、Ｌ１キャッシュ、Ｌ２キャッシュ、並びにＤＭＡＣ４４を内蔵するＭＦＣ４３を構成要素として含んでいる。一般に、オペレーティングシステムは、メインプロセッサ３９において動作し、オペレーティングシステムの基本処理に基づいて、各サブプロセッサ３３で動作するプログラムが決定される。言うまでもないが、サブプロセッサ３３で動作するプログラムが、通常の概念においてオペレーティングシステムの一部をなすようなプログラム（例えば、デバイスドライバやシステムプログラムの一部）であっても構わない。また、メインプロセッサ３９とサブプロセッサ３３は、それぞれ異なる命令セットを有する命令セットアーキテクチャ（ＩＳＡ）である。

本実施形態に係るデータ通信方法の特徴の一つは、各サブプロセッサ３３が、ネットワーク上のピアノードと相互認証を行うプロセスを実行する点である。なお、ピアノードはサーバ又はクライアントのどちらの機能を果たすものであってもよい。ここではまず、最も簡単な例として、各サブプロセッサ３３がユニークにネットワーク上の１つのピアノードと信頼関係を確立する場合について、図４と図５を参照して説明する。ここでは、複数のコンピュータによるデータ検索の分散処理を例に取り上げる。

図４にあるように、検索システムとして用いられるデータ通信システム７０では、サブプロセッサ３３とピアノード８４ａ〜８４ｈは、それぞれ秘密鍵を少なくとも１つ記憶している。図４では示されないが、ネットワーク８５上に公開鍵認証局が存在する。サブプロセッサ３３と各ピアノード８４は、それぞれの公開鍵６３に基づいて、公開鍵認証局から公開鍵証明書（電子証明書）を提供される。すなわち、サブプロセッサ３３の公開鍵６３に基づいて、公開鍵認証局は、公開鍵証明書（認証局の秘密鍵で暗号化された公開鍵６３等）を発行し、当該公開鍵証明書をサブプロセッサ３３に返信し、各サブプロセッサ３３は、当該公開鍵証明書を保持している。同様に、各ピアノード８４の公開鍵に基づいて、公開鍵認証局は、公開鍵証明書を発行し、当該公開鍵証明書を該ピアノード８４に返信し、各ピアノード８４は、当該公開鍵証明書を保持している。なお、公開鍵認証基盤としては、例えばＩＴＵ−Ｔによって勧告されたＸ.５０９を採用することができる。

図５に示すように、各サブプロセッサ３３がピアノード８４と信頼関係を確立する場合、サブプロセッサ３３は、まずＳ６１において外部ピアノード８４の選択処理を行う。図示されていないが、ここではピアノード選択サーバがネットワーク８５上に存在している。ピアノード選択サーバは、各サブプロセッサ３３の要求に基づいて、ユニークに１つのピアノード８４を選択し、当該サブプロセッサ３３は、選択されたピアノード８４との間で、Ｓ６２においてＳＳＬハンドシェークプロトコル等を利用して相互認証を行う。例えば、サブプロセッサ３３は、選択されたピアノード８４から公開鍵証明書を受信し、当該公開鍵証明書を公開鍵認証局の公開鍵を使用して復号化し、ピアノード８４の情報（ピアノード８４の公開鍵やその管理者の名称等）を取得する。そして、この情報からピアノード８４を認証する。同様に、ピアノード８４も、サブプロセッサ３３から公開鍵証明書を受信し、当該公開鍵証明書を公開鍵認証局の公開鍵を使用して復号化し、サブプロセッサ３３の情報（サブプロセッサ３３の公開鍵やそのユーザの名前等）を取得する。そして、この情報からサブプロセッサ３３を認証する。こうして、ステップＳ６３において相互に認証が成功していることが確認されれば、これ以降、当該サブプロセッサ３３は、アクセスできなくなる等の障害が生じない限り、当該ピアノード８４を信頼のおけるピアノードと判断する。そのために、ステップＳ６４において、サブプロセッサ３３は、図３に示すピアノードアクセステーブル６５に当該ピアノード８４に関する情報を登録する。一方、もしＳ６３において相互認証が失敗した場合には、再びＳ６１に戻り、サブプロセッサ３３は、ピアノード選択サーバに対して、再度、ピアノードの選択を依頼する。最後まで（例えば所定時間が経過するまで）相互認証が成功しなかった場合には、サブプロセッサ３３は、信頼のおけるピアノードが存在しないと判断する。この場合、本実施形態においては、当該サブプロセッサ３３は、検索処理の分散処理に関与（参加）しないこととなる。以上の処理は、クライアントから検索要求があった場合に実行されてもよいし、コンピュータ３１の起動時等、その他の適宜のタイミングで実行されてもよい。

図４に示されるピアノード８４は、図２のコンピュータ３１と同様の構成であってもよいし、図６（ａ）及び（ｂ）に示されるように、メインプロセッサ８６からアクセスされるメインメモリ８７中にセキュアメモリ８８を持つか、又はメインメモリ８７と独立にセキュアメモリ８８を持つような、汎用又は専用コンピュータであってもよい。ピアノード８４が、図６の構成を採用した場合には、セキュアメモリ８８には秘密鍵６２が記憶され、メインメモリ８６には公開鍵６３、第三者から発行された公開鍵証明書６４、並びにピアノードアクセステーブル６５を有している。なお、図４におけるコンピュータ３１がシングルプロセッサのピアノードとなる場合には、メインプロセッサ４２が、図６におけるメインプロセッサ８６であり、図４におけるメインメモリ４７が、図６におけるメインメモリ８７であるように構成することができる。すなわち、メインメモリ４７が、図６（ａ）にあるようにセキュアメモリ８８に相当する記憶領域を有し、そこに秘密鍵６２を格納し、さらに他の記憶領域に公開鍵６３及び公開鍵証明書６４を記憶する。ただし、コンピュータ３１がシングルプロセッサのピアノードとなる場合において、メインプロセッサ４２が検索処理に関わらないのであれば、コンピュータ３１は、ピアノードアクセステーブル６５を記憶しておく必要がない。

さて、上記実施形態では、１つのサブプロセッサが唯１つのピアノードと信頼関係を確立することを前提としている。しかしながら、１つのサブプロセッサが複数のピアノードと信頼関係を持ち、検索依頼を行うようにしてもよい。また、図７に示すように、検索依頼を受けるピアノード１２０を頂点とする、ピアノードの木構造ネットワークを構成するようにしてもよい。例えば、最初に検索依頼を受けるピアノード１２０は、２つのピアノード１２１ａと１２１ｂと信頼関係を確立しており、さらにピアノード１２１ａは、ピアノード１２２ａと１２２ｂと信頼関係を確立している。なお、繰り返しになるが、各ピアノードは、図２に示すようにしてワンチップマルチコアプロセッサを利用したコンピュータシステムであってもよいし、それ以外のコンピュータシステムであってもよい。

図７のような信頼関係ネットワークにおいて、ピアノード１２０がクライアントから検索依頼を受け取ると、検索依頼は、それぞれ下方（ツリーの末端方向）に向かって伝播し、信頼関係の最後に位置するピアノード１２４ａ、１２４ｂ、１２５、１２６ａ、１２６ｂ、並びに１２７が、折り返し上方（ツリーのルート方向）に検索結果を返していくことになる。最終的に、全てのピアノードの検索結果は、最初にクライアントから検索依頼を受けたピアノード１２０に集められることになる。ピアノード１２０に検索依頼を行ったクライアント（図示されていない）は、この検索結果を受け取り、ユーザに対して表示を行うことになる。もし、ピアノード１２０自身がユーザインタフェースを備えた検索サーバであれば、その場でユーザインタフェースを介して、ユーザに対して検索結果の表示を行う。

さて、図７のような実施形態とするためには、図５のフロー図により既に示した、各サブプロセッサが実施する信頼関係を確立したピアノードの登録処理を、より一般的に拡張する必要がある。これを図８に示す。同図では、まずステップＳ７１において、いくつのピアノードを選択するか（いくつのピアノードに対して相互認証を試みるか）を決定する。もちろん、選択するピアノード数Ｎが１であれば、図８の処理は、本質的に、図５の処理と同じになる。また、Ｎは無限大とすることもできる。しかしながら現実的には、図３又は図６のピアノードアクセステーブル６５は有限であることの方が一般的である。

まず、ステップＳ７２でＮが０かどうか、すなわち予定されたＮ個のピアノードについて認証を行ったかどうか検証している。Ｎが０でない間は、ステップＳ７３に進み、選択できるピアノードがあるかどうかチェックしている。この結果、選択的できるピアノードが存在するならば、ステップＳ７４でＮを１減じた後、ステップＳ７５に進み、ピアノードを選択する。選択対象となるピアノードがすでに存在しなければ、登録処理を終了する。ステップＳ７５で選択されたピアノードとの間で、ステップＳ７６において相互認証を行う。これには、例えばＳＳＬハンドシェークプロトコル等を利用することができる。最後にステップＳ７７において、ピアノード認証が成功したかどうか確認し、成功していればステップＳ７８に進み、公開鍵証明書を当該認証が成功したピアノードから取得して、そのピアノードを信頼できるピアノードとしてピアノートアクセステーブルに登録する。ピアノード認証が失敗すれば、ピアノードアクセステーブルに登録することなく、ステップＳ７２に戻る。

図９は、図３又は図６のピアノードアクセステーブル６５の一例を示したものである。このテーブルには、ピアノードＩＤ（ここではグローバルＩＤではなく、テーブルを保有するコンピュータからみたローカルＩＤが示されている）、ローカルメモリ上のアドレスである公開鍵証明書格納位置、登録されているピアノードのＩＰアドレス、及び登録されているピアノードが現在アクセス可能な状態にあるかどうかを示すレスポンスが項目として存在している。なお、本実施形態では、ＩＰアドレスを利用したが、ＭＡＣアドレスのように相手のネットワーク上での位置が何らかの形でわかるものであればよい。レスポンスの欄で"ＯＫ"と示されているのはアクセス可能なピアノードを示し、"ＮＯ"はなんらかの理由（例えばネットワークの切断やコンピュータ電源オフ等）によってアクセス不可となっているピアノードを示している。

以上の説明では、全て、検索を依頼するサブプロセッサと検索を依頼されるピアノードの間に信頼関係が成立している場合のみを想定していた。しかしながら、実際には、そこまで厳格に制限しなくとも、信頼できるピアノードからの検索結果なのか、信頼できないピアノードからの検索結果なのかが明確に区別できれば、あとは検索結果を利用するユーザの責任に基づいて検索結果を利用するという方法も考えられる。例えば、図１０では、検索依頼の各一部を処理するピアノードに、信頼できないピアノードが含まれている。同図は図７と、木構造ネットワークのノードに信頼できないピアノードが含まれている点で異なる。ピアノード１４２ｂ、１４４ｂ、１４５、並びに１４６ｂは信頼関係を確立できないピアノードである。これらは、例えば第三者の発行する公開鍵証明書を保持しないピアノードである。このため、例えばピアノード１４１ａにとって、ピアノード１４２ｂは信頼できないピアノードであり、よって、このピアノード１４２ｂからの検索結果は信頼できないものであるとして、ピアノード１４１ａにより認識される。同様のことは、ピアノード１４２ａとピアノード１４４ｂの間、及びピアノード１４３ａとピアノード１４６ｂの間にも成り立つ。特筆すべきなのは、あるノードが信頼できない場合、そこに接続する（そこよりも下方の）全てのノードからの検索結果は、信頼できない検索結果として認識されることである。例えば、もしピアノード１４５が第三者の発行する公開鍵証明書を保持していたとしても、このピアノード１４５の情報が、信頼できないピアノード１４２ａを経由して来た場合には、ピアノード１４１ａは、それを信頼できない検索結果と認識する。これは、信頼できないノードが間に入ることにより、信頼できないノード上で情報の改竄等が行われる可能性もあるためである。

図１１は、１つのサブプロセッサが複数のピアノードと認証を行い、その一部に信頼関係を確立していないものが含まれうる場合における、ピアノードの登録処理を示すフロー図である。同図の処理は、図１０の木構造ネットワークを前提としており、図８のフローチャートに一部変更を加えたものとなっている。具体的には、図８と異なるのは、ステップＳ７７以降の処理である。図８では、ピアノード認証が失敗した場合には、何の処理もしなかった。しかしながら、図１０にあるように信頼できないピアノードに対しても検索依頼を出せるようにするために、図１１は、ピアノード認証が失敗した後の処理として、ステップＳ７９を追加している。すなわち、あるピアノードとの相互認証が成功しなかった場合には、信頼関係がないピアノードとして、そのピアノードを、ピアノードアクセステーブルに登録している。

図１２は、図１１の処理により生成されるピアノードアクセステーブルの一例を示している。同図に示すピアノードアクセステーブルは、図９に示すピアノードアクセステーブルに比し、"信頼度"の項目が加えられている。ここで、ピアノードＩＤ０００４の信頼度は"無"となっている。これは、ステップＳ７７においてピアノード認証が失敗したと判断されたピアノード、すなわち信頼できないピアノードとして認識されたことを示すものである。さらに、このピアノードＩＤ０００４の公開鍵証明書格納位置には"ＮＯＮＥ"と示されている。信頼できないピアノードは公開鍵証明書がないので、ローカルメモリには格納できないためである。

ここで、図１３から図１９を参照しながら、本実施形態に係るデータ通信方法に関して、さらに詳細な説明を行う。図１でも示したように、本実施形態の通信プロトコルは、例えばインターネットプロトコルにおいては、トランスポート層（例えばＴＣＰ）の上に位置する。図１３では、ＴＣＰ／ＩＰを活用して本実施形態の通信レイヤを構築した例が示されている。すなわち、本実施形態の通信プロトコルで使われるデータ構造は、図１３において、セキュアプロトコルフレームとして示されている。ＴＣＰ／ＩＰにおいては、このセキュアプロトコルフレームに、ＴＣＰヘッダとＩＰヘッダが追加される。ネットワーク８５に送出されるイーサネット（登録商標）フレームは、このデータの前後に、さらにヘッダとトレイラが付加されたものである。

図１４は、本実施形態のセキュアプロトコルフレーム構造を示しており、同図に示すように、セキュアプロトコルフレームは、セキュアプロトコルヘッダ９１とペイロード（すなわち通信内容）９２から構成される。図１５は、セキュアプロトコルヘッダ９１の一例をより詳細に記述している。この例では、ペイロード９２を送出するサブプロセッサ３３のＩＤであるＳＰＥ ＩＤ１０１、サブプロセッサ３３がそれぞれ固有に保持する自分自身の公開鍵証明書１０２、各メッセージがユニークに特定されるためのメッセージＩＤ１０３，ペイロード９２の内容の種類を示すペイロードディスクリプタ１０４、ペイロードの長さ１０６、及びその他の情報（これは実施形態に応じて様々である）１０５を含む。ペイロードディスクリプタは、一例において、０ｘ０１がタスク依頼を、０ｘ０２がタスク依頼に対する結果を、ペイロード９２が含むことを示すようにできる。

図１６と図１７は、それぞれ、データ送信処理において、データを受信するピアノードが特に指定されている場合（図１６）と、特に指定されておらず応答可能なピアノードであればどれでもよいという場合（図１７）の２つを示している。

図１６においては、まず、ステップＳ４１において、サブプロセッサ３３に対するセキュアアプリケーションの実行リクエストを出す。このセキュアアプリケーションは例えば、検索アプリケーションの起動や、オブジェクト（アプリケーション、データ）のピアノード間再配置依頼アプリケーション等である。次にステップＳ４２において、他のコンピュータ（ピアノード）に対する処理リクエストコードが生成される。処理リクエストコードは、検索関連アプリケーションについてはキーワードを付けた検索依頼を示すデータであるし、オブジェクト再配置アプリケーションについては、特定のノードから別のノードへのオブジェクトの条件付き再配置の依頼を示すデータである。

続いてステップＳ４３では、送り先のピアノードの公開鍵証明書が、図３のピアノードアクセステーブル６５に登録されているかどうかがチェックされる。もし登録されていれば、信頼できるノードと判断し、ステップＳ４４において、サブプロセッサ３３が当該サブプロセッサ３３を識別するＳＰＥＩＤを、例えば当該サブプロセッサ３３のローカルストレージ３５から読み出す。さらに、ステップＳ４５において、図３における公開鍵証明書６４を同ローカルストレージ３５等から読み出すとともに、ステップＳ４６においてメッセージＩＤを生成する。メッセージＩＤは、例えばシリアルに生成されてもよいし、乱数に基づいて生成されてもよい。メッセージＩＤは、セキュアプロトコルフレームの送信に対して、通信相手であるピアノードからセキュアプロトコルフレームの返信があるまで、例えばローカルストレージ３５に保存される。

ステップＳ４７では、Ｓ４２で生成された処理リクエストコードを含むペイロード９２用のデータを生成し、ステップＳ４８でセキュアプロトコルフレームを作成するとともに、ステップＳ４９で、このセキュアプロトコルフレームを予め特定されている他のコンピュータに送信する。セキュアプロトコルフレームは、ステップＳ４４で読み出されたＳＰＥ ＩＤ、ステップＳ４５で読み出された公開鍵証明書、ステップＳ４６で生成されたメッセージＩＤをセキュアプロトコルヘッダ９１に含み、Ｓ４２で生成された処理リクエストコードをペイロード９２に含むデータである。

なお、ステップＳ４３で、送り先のピアノード（他のコンピュータ）の公開鍵証明書がピアノードアクセステーブル６５に登録されていないと判断される場合には、セキュアアプリケーションの実施条件が満たされないと判断して、処理を終了する。

一方、通信先である他のコンピュータが特定されていない場合の処理は、図１７に示される。図１７と図１６の違いの１つは、図１６におけるステップＳ４２とステップＳ４３の間に、ステップＳ５３とステップＳ５４が挿入され、ステップＳ５３で、通信相手として選択できるコンピュータが１つでも存在すると判断される場合には、ステップＳ５４でコンピュータ（ピアノード）を１つ選択することである。通信相手として選択できるコンピュータは、例えば予めリスト化して記憶しておけばよい。２つ目の違いは、図１６では、ステップＳ４３において、相手の公開鍵証明書が存在しなければすぐに処理を終了してしまったが、図１７では、ステップＳ５５において相手の公開鍵証明書が存在しなかった場合でも、ステップＳ５３で、通信相手として選択できるコンピュータが存在する限り処理を継続するようにした、という点である。それ以外の処理については、同じであるので、ここでは説明を省略する。

以上のようにして送信されるセキュアプロトコルフレーム（受信セキュアプロトコルフレーム）を受信したピアノード（コンピュータ）では、処理結果を示すデータを含むセキュアプロトコルフレーム（返信セキュアプロトコルフレーム）を生成して、これを元のコンピュータ３１に返信する。このとき、受信セキュアプロトコルフレームのセキュアプロトコルヘッダ９１に含まれる公開鍵証明書により、送信元のコンピュータ３１が正当なものであることが確認できない場合には、セキュアプロトコルフレームの返信を行わない。また、返信セキュアプロトコルフレームは、検索結果等の各種処理結果を示すデータをペイロード９２に含むものである。また、そのセキュアプロトコルヘッダ９１のＳＰＥ ＩＤの欄１０１には、受信セキュアプロトコルフレームのセキュアプロトコルヘッダ９１に含まれているＳＰＥ ＩＤの値が格納される。さらに、ＳＰＥの個別公開鍵証明書１０２の欄には、処理要求を受け付けた当該ピアノードの公開鍵証明書が格納される。また、メッセージＩＤの欄１０３には、受信セキュアプロトコルフレームのセキュアプロトコルヘッダ９１に含まれているメッセージＩＤの値が格納される。また、ペイロードディスクリプタの欄１０４には、例えば処理結果の返信の旨を示すデータが格納される。

図１８は、図１６又は図１７の処理によりセキュアプロトコルフレームを送信したコンピュータ３１が、送信先のコンピュータ（ピアノード）から上記返信セキュアプロトコルフレームを受信した場合の処理を示すフローチャートである。

まず、ステップＳ７１においてセキュアプロトコルフレームを受信すると、ステップＳ７２において例えばメインプロセッサ３９がセキュアプロトコルヘッダ９１を読み出す。続いて、ステップＳ７３において、例えばメインプロセッサ３９等のコミュニケーションプロセッサが上記ステップＳ７２において読み出されたセキュアプロトコルヘッダ９１に含まれているＳＰＥＩＤを読み出し、このＩＤを持つサブプロセッサ３３に、バス４５を介して、セキュアプロトコルフレームを転送する。

ステップＳ７４以下は、このセキュアプロトコルフレームを受信したサブプロセッサ３３による処理となる。まずステップＳ７４において、セキュアプロトコルヘッダ９１を読み出し、ステップＳ７５において、上記セキュアプロトコルヘッダからメッセージＩＤを読み出す。ステップＳ７６では、このメッセージＩＤが、図１６のステップＳ４６で生成され、ローカルストレージ３５等に記憶されているメッセージＩＤと一致するかどうかチェックする。

ステップＳ４６のチェックの結果、２つのメッセージＩＤが一致すれば、続いてステップＳ７７でセキュアプロトコルヘッダ９１から公開鍵証明書を取り出す。ステップＳ７８では、ステップＳ７７で取り出した返信したコンピュータの公開鍵証明書が、正しいかどうか検証を行う。これは単に、予めローカルストレージ３５等に記憶されている公開鍵証明書と一致するかどうか検証するだけの処理であってもよいし、新たに公開鍵証明書の署名を確認する処理を行ってもよい。ステップＳ７８の結果、相手の公開鍵証明書の正しさが確認された場合、ステップＳ７９で続きの処理（例えば検索結果や再配置結果等の処理結果の表示や、再処理の要求等）を行う。もしステップＳ７８において、相手の公開鍵証明書が不正なものであると判断した場合には、ステップＳ８０に進み、処理失敗として処理を中止する。この場合、ステップＳ７９の処理は行われない（制限される）。

また、ステップＳ７６において、２つのメッセージＩＤが一致しないと判断した場合には、そのまま処理を終了する。処理を終了した後は、例えば次のセキュアプロトコルフレームが来るのを時間制限なく待つようにしてもよいし、一定時間以内に、次のセキュアプロトコルフレームがこなければ処理を終了するようにしてもよい。

図１９は、サブプロセッサ３３の１つが、相手コンピュータ（ピアノード）を選択し、図１６または図１７にしたがって、当該ピアノードに対してタスク依頼を行ってから、結果報告を受けるまでの流れを示している。ステップＳ９１及びステップＳ９２で、サブプロセッサ３３が送信したセキュアプロトコルフレームが、プロトコルスタックを処理するコミュニケーションプロセッサを介して相手ノードに送られる。このセキュアプロトコルフレームを受信したピアノードは、相手の公開鍵証明書をセキュアプロトコルフレームから取り出し、認証を行う（ステップＳ９３）。

この結果、認証が失敗した場合には処理を終了する。認証が成功した場合には、ステップＳ９４に進み、ペイロード９２にしたがって、依頼されたタスクを実行する。例えば検索であれば検索処理を行う。タスクが正常に終了した場合には、当該ピアノードは、自分の公開鍵証明書を埋め込んだセキュアプロトコルフレームを作成し、ペイロード９２には要求されたタスクの処理結果を埋め込む。この際、ペイロードディスクリプタには、結果を示す、例えば０ｘ０２を書き込む。図１５のセキュアプロトコルフレームのうち、１０１のＳＰＥ ＩＤと１０３のメッセージＩＤは、ステップＳ９２で受信したセキュアプロトコルフレームのデータをそのまま書き込む。そして、この結果作成されたセキュアプロトコルフレームをステップＳ９６で送信元のＩＰアドレスを持つコンピュータに送信する。このセキュアプロトコルフレームは、当該依頼元コンピュータのコミュニケーションプロセッサを介して、図１８にしたがって、依頼元のサブプロセッサ３３に対して転送される（ステップＳ９７）。

以上の処理によれば、ワンチップマルチコアプロセッサ３２を備えるコンピュータ３１により、サブプロセッサ３３毎にセキュアなデータ通信を行うことができる。

なお、上記実施形態に係るデータ通信方法は汎用のコンピュータのみならず、例えばゲーム機等の特定用途のコンピュータでも使用可能である。図２０には、本実施形態に係るデータ通信方法を用いるコンピュータのシステム構成例が示されている。この構成例では、テレビ受像器等のモニタ１６０が利用されており、コンピュータ１５１本体は、このモニタ１６０により検索結果を表示したり、検索要求を受け付けたりするようになっている。コンピュータ１５１は、装置の起動・停止を行うためのスイッチ１５４、動作・非動作を示す確認ランプ（インディケータ）１５５、リモコンからの赤外線信号を受け付けるＩＲ受光部１５２、並びにキーボード１５９等の入力インタフェースを接続するＵＳＢ等の接続インタフェース１５３を備えている。ここで、キーボード１５９は有線で接続インタフェース１５３に接続されているように描かれているが、当然ながら接続インタフェース１５３が無線通信インタフェースであれば、キーボード１５９はワイヤレスキーボードであってよく、ＩＥＥＥ８０２．１１ａ／ｂ／ｇのような通信規格に則って、当該接続インタフェース１５３と通信するようにされていてもよい。

リモコン１５６は、赤外線発光部１５７と、複数の数字、文字、或いは方向指示キー等を備えたキーパッド部１５８と、を備えている。各キーは、数字入力、文字入力、或いは方向指示入力等の入力タイプを、１つのキー（入力タイプ選択キー）で選択できるようにされていてもよい。この場合、キーの１つが入力タイプ選択キーであり、さらに、キーパッド部に、入力した文字が表示されるような表示部を備えて、当該表示部には、現在選択されている入力タイプ（数字、文字、或いは方向指示）が表示される。そして、当該表示部にはさらに、入力した文字列が表示される。また別の例では、表示部の代わりに、入力タイプを示す複数のランプ或いは１つのランプで複数の色を表示できるものが備えられる。そして、これによって入力タイプを表示する。キーパッド部１５８には、文字変換や文字選択をするためのキーが備わっているとより好適である。

コンピュータ１５１の内部は、例えば図１のように構成されており、グラフィックカード５５を介してモニタ１６０（図１のモニタ５７に相当する。）と接続されており、検索仲介装置１５１のプロセッサによって生成された出力を表示するようにされている。具体的には、図１９に示されるように、例えば図１８で示したような検索インタフェース１４１が表示される。また、この検索インタフェースの操作はリモコン１５６やキーボード１５９等のユーザインタフェースを利用して行うことになる。例えば、リモコン１５６から入力タイプを「ひらがな」として、キーパッド部１５８のキーからひらがなを順に入力するとともに、適宜、それを漢字やカタカナに変換することによって、"並列"又は"コンピュータ"等の文字を打ち込むことができる。また、リモコン１５６により入力タイプを「方向指示」に設定し、キーバッド部１５８のキーから方向を指示することにより、検索インタフェース１４１上でボタンの間をカーソルが移動するようにしてもよい。例えば、キーパッド部１５８に設けられた右矢印のキーを押すことにより、検索開始ボタン、検索中止ボタン，検索条件入力部、検索式入力部、…といったように順にカーソル位置を変えることができる。

Claims (6)

1. ２以上のプロセッサをそれぞれ備える第１コンピュータと、第２コンピュータとの間のデータ通信方法であって、
   前記第１コンピュータから前記第２コンピュータに対して、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを送信する送信ステップと、
   前記第２コンピュータから前記第１コンピュータに対して、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書を含むデータを返信する返信ステップと、
   前記第１コンピュータが前記第２コンピュータから、前記返信ステップにより返信されるデータを受信する受信ステップと、
   前記第１コンピュータにおいて、前記受信ステップで受信されるデータから、該データに含まれるプロセッサＩＤを取得する取得ステップと、
   前記第１コンピュータにおいて、前記第１コンピュータに備えられる前記２以上のプロセッサのうち、前記取得ステップで取得されるプロセッサＩＤにより識別されるものにより、前記受信ステップで受信されるデータを処理する処理ステップと、
   前記第１コンピュータにおいて、前記受信ステップで受信されるデータに含まれる公開鍵証明書の内容に応じて、前記処理ステップによる処理を制限する認証ステップと、
   を含むことを特徴とするデータ通信方法。
2. 請求の範囲第１項に記載のデータ通信方法において、
   前記送信ステップは、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤに加えて、該プロセッサＩＤにより識別されるプロセッサに関連する公開鍵証明書をさらに含むデータを送信し、
   前記返信ステップは、前記送信ステップで送信されるデータに含まれる公開鍵証明書の内容に応じて、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書を含むデータを返信する、
   ことを特徴とするデータ通信方法。
3. 請求の範囲第１項又は第２項に記載のデータ通信方法において、
   前記送信ステップは、前記第１コンピュータに備えられる前記２以上のプロセッサのうち１つを識別するプロセッサＩＤをヘッダの少なくとも一部として、通信内容をペイロードとして含むデータを前記第２コンピュータに送信する、
   ことを特徴とするデータ通信方法。
4. 請求の範囲第１項に記載のデータ通信方法において、
   前記返信ステップは、前記送信ステップで送信されるデータに含まれるプロセッサＩＤ及び前記第２コンピュータに関連する公開鍵証明書をヘッダの少なくとも一部として、通信内容をペイロードとして含むデータを前記第１コンピュータに返信する、
   ことを特徴とするデータ通信方法。
5. ２以上のプロセッサと、
   前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを他のコンピュータに送信するデータ送信手段と、
   前記他のコンピュータから前記２以上のプロセッサのうち１つを識別するプロセッサＩＤ及び公開鍵証明書を含むデータを受信するデータ受信手段と、
   前記データ受信手段により受信されるデータから、該データに含まれるプロセッサＩＤを取得するプロセッサＩＤ取得手段と、
   前記２以上のプロセッサのうち、前記プロセッサＩＤ取得手段により取得されるプロセッサＩＤにより識別されるものにより、前記データ受信手段により受信されるデータを処理するデータ処理手段と、
   前記データ受信手段により受信されるデータに含まれる公開鍵証明書の内容に応じて、前記データ処理手段による処理を制限する認証手段と、
   を含むことを特徴とするコンピュータ。
6. ２以上のプロセッサを備えるコンピュータにより実行されるプログラムを記憶した情報記憶媒体であって、
   前記２以上のプロセッサのうち１つを識別するプロセッサＩＤを含むデータを他のコンピュータに送信するデータ送信手段、
   前記他のコンピュータから前記２以上のプロセッサのうち１つを識別するプロセッサＩＤ及び公開鍵証明書を含むデータを受信するデータ受信手段、
   前記データ受信手段により受信されるデータから、該データに含まれるプロセッサＩＤを取得するプロセッサＩＤ取得手段、
   前記２以上のプロセッサのうち、前記プロセッサＩＤ取得手段により取得されるプロセッサＩＤにより識別されるものにより、前記データ受信手段により受信されるデータを処理するデータ処理手段、及び
   前記データ受信手段により受信されるデータに含まれる公開鍵証明書の内容に応じて、前記データ処理手段による処理を制限する認証手段
   としてコンピュータを機能させるためのプログラムを記憶した情報記憶媒体。

Images