JP2005203846A

JP2005203846A - マルチホップセルラネットワークに適したセキュリティ機構

Info

Publication number: JP2005203846A
Application number: JP2004005377A
Authority: JP
Inventors: Jun Anzai; 潤安齋; Tsutomu Matsumoto; 勉松本
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2004-01-13
Filing date: 2004-01-13
Publication date: 2005-07-28

Abstract

【課題】セルラネットワークにおけるマルチホップ通信において、汎用性の高いセキュリティ機構を実現する。
【解決手段】セルラネットシステムにより、無線端末を仲介ノードとして認定することで、マルチホップセルラネットワークに、仲介ノードを導入する。仲介ノードで、無線端末を登録する。報酬ポイントモジュール発行管理システムで、耐タンパーモジュールで構成された報酬ポイントモジュールを発行する。送信無線端末は、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信する。転送無線端末は、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送する。受信無線端末は、報酬ポイントを付加した暗号化メッセージを受信して復号する。インセンティブ機能とPKI補助機能を統合したので、汎用性が高いセキュリティ機構となる。
【選択図】図６

Description

本発明は、マルチホップセルラネットワークに適したセキュリティ機構に関し、特に、仲介ノードを導入しインセンティブ機能とPKI補助機能を統合して汎用性を高めたマルチホップセルラネットワークに適したセキュリティ機構に関する。

マルチホップ通信によるネットワークマルチホップ通信とは、送信端末から受信端末へ、経路上の１または複数の転送端末がバケツリレー式にデータを転送する方式である。図11のマルチホップ通信の概念図を参照しながら、マルチホップ通信方法の概略を説明する。通信ノードである無線端末Ａ〜Ｇの間でバケツリレー式に通信を中継して、ノードＡからノードＧへの通信を実現する。ノードＡは、ノードＢとノードＤとの間でしか直接通信ができない。ノードＢは、ノードＡ，Ｃ，Ｄ，Ｆとの間でしか直接通信ができない。以下同様に、各ノードは、限られた数のノードとしか直接通信ができない。そのため、ノードＡからノードＧへ通信する場合は、ノードＡ，Ｂ，Ｃ，ＧあるいはノードＡ，Ｄ，Ｅ，Ｆ，Ｇのような経路をたどって通信する。

マルチホップ通信を用いた通信網として、アドホックネットワーク（アドホックネットと呼ぶ）や、マルチホップセルラネットワーク（セルラネットと呼ぶ）が存在する。図12に、マルチホップ通信を前提としたマルチホップセルラネットワークとアドホックネットワークのシステムモデルを示す。図13に、アドホックネットワークにおけるノードＡからノードＢへのマルチホップ通信を示す。アドホックネットは、無線端末（ノードと呼ぶ）の集合から自律的に形成されたネットワークである。バックボーンインフラ（BBインフラと呼ぶ）を介さずに、ノードが相互に接続して、網目の様に通信する。そのため、BBインフラが不要である。短距離無線通信とトラフィック分散による周波数帯域の有効利用できる。無線エリアの拡大が容易である。

図14に、マルチホップセルラネットワークにおけるノードＡからノードＢとノードＣへのマルチホップ通信を示す。セルラネットは、図14に示すように、プロバイダが提供するアクセスポイント（APと呼ぶ）を介して、BBインフラに接続する無線LANスポットサービスや、基地局を介してBBインフラに接続する携帯電話の様なネットワークと、アドホックネットを結合したものである。BBインフラとノード間の通信は、マルチホップにより実現される。既存網を利用しつつ、アドホックネットの特徴を取り入れたものである。セルラネットは次の前提を持つ。無線LANスポットサービスと携帯電話を想定し、アクセスポイントAPと基地局を総称してステーションと呼ぶ。ノード間通信において、ステーション経由の有無は問わない。ステーションを経由する場合、ステーション以降の通信網がマルチホップ通信網である必要はない。

これらの通信網におけるセキュリティ課題として、ノード間認証、ノード間鍵共有、セキュアルーティング、ノード間の協調が挙げられる。ここでは、認証・鍵共有・協調に着目する。一般に、不特定多数のエンティティ間認証・鍵共有に、公開鍵システム（Public Key Infrastructure PKI）を用いるが、次の理由により、考察対象とする通信網では、必ずしも有効でない。

ノードはリソースが少なく、複数回の証明書検証・署名は負担が大きい。また、不特定多数のノードの認証に必要な種類の認証局証明書（Certificate Authorityが発行する証明書であり、略してCA証明書と呼ぶ）の保持も困難である。証明書の発行・管理に認証局を利用できない場合がある。セルラネットは、他ネットワークとの連携を考慮しなければ、認証局は必ずしも必要でない。以上を解決するために、リソースの多いノードがPKI処理の補助を行うことや、マルチホップ通信のために、ノードがデータ転送を行う必要がある。しかし、ノードはバッテリ駆動であり、一般に、電力を消費する処理への協力に積極的でない。バッテリ問題は燃料電池により解決される可能性もあるが、未解決問題として扱う。そのため、ノードの協調を促すために、協調に報酬を与え、非協調に罰を与えるインセンティブ機能が考えられる。一般に、報酬ポイント(Reward Point RP)で管理し、報酬ポイントとサービスを引き換える方式が多い。

アドホックネットにPKIを適用する従来技術をいくつかあげる。PGP (Pretty Good Privacy)と同様に、知り合いを信頼する方法の提案がある。PGPとの違いは、公開鍵ディレクトリを用いず、各ノードが自身の証明書を発行管理・配送することと、ノード間で証明書の交換が可能なことである。全ての処理を行うノードに負荷が集中する。一方、特権ノードのグループを信頼する方法の提案もある。認証局CAの秘密鍵を特権ノードが分散保持し、一定数以上の秘密鍵を用いると、証明書の発行管理・配布が可能となる。一般ノード（特権ノードと区別する場合に使用する）は、複数の特権ノードへの接続が必要である。一般ノードグループを信頼する方法の提案もある。自身で検証困難な証明書の信頼の有無を、同報でグループに問い合わせ、その結果を検証に代える。同報により通信量が増加する。問い合わせ結果の判断法が未解決である。

次に、インセンティブ機能に関する従来技術の例を紹介する。非特許文献１，２に、アドホックネットを想定し、信頼の仮定を耐タンパーモジュール（Tamper Resistant Module TRM）におく方法が提案されている。この方法では、耐タンパーモジュールで管理する報酬ポイントを、転送時には増加し、逆に、データ送信時には減少し、転送先の耐タンパーモジュールが転送を検査して、転送元に対して報酬ポイントを送ることにより、インセンティブ機能を実現する。しかし、この報酬ポイントの送り方の詳細は不明である。また、複雑な処理をする耐タンパーモジュールはコストが高い。一方、セルラネットを想定した共通鍵暗号ベースの方法が、非特許文献３，４で提案されている。この方法では、基地局で各ノードの報酬ポイント口座を管理する。各ノードは、基地局とセッション確立後、送信データにメッセージ認証子を付け、それを基地局経由時に検査することで、送信・転送ノードを特定し、送信ノードの報酬ポイントを転送ノードに移動する。基地局から受信ノードへの転送時は、受信ノードが基地局へ受信通知を行う。共通鍵暗号ベースのために、ノードの負荷が小さいが、ノード間通信において必ず基地局を経由するソースルーティング方式を前提とするという制約がある。

公開鍵暗号ベースでは、アドホックネットを想定した方法が、非特許文献５で提案されている。この方法では、データに添付した送信ノードの署名を、転送時に転送ノードが、受信時に受信ノードが検証する。受信ノードが署名を信頼できる第三者機関(Trusted Third Party TTP)に送り、TTPが送信ノードから転送ノードへと報酬ポイントを移すことで、インセンティブ機能を実現する。アドホックネットにTTPを仮定することや、ノードが転送毎に署名検証することが課題である。暗号を主体としない方法として、監視を用いたルーティング方法が、非特許文献２，６で提案されている。この方法では、ノードがデータ転送を監視し、転送しないノードを検出する。再送信時に、当該ノードをルートから外す仕組みのため、インセンティブ機能として利用できる。つまり、監視結果を元に、報酬ポイントを転送ノードに発行すればよい。しかし、監視を前提にできない場合も多い。
L. Buttyan and J. P. Hubaux, "Enforcing service availability in mobile ad-hoc WANs," in IEEE/ACM Workshop on Mobile Ad Hoc Networking and Computing, Boston, MA, August 2000. L. Buttyan and J. P. Hubaux, "Stimulating cooperation in self-organizing mobile ad hoc networks," ACM Journal for Mobile Networks, special issue on Mobile Ad Hoc Networks, summer2002. M. Jakobsson, J.P. Hubaux, and L. Buttyan, "A Micro-Payment Scheme Encouraging Collaboration in Multi-Hop Cellular Networks," In Proceedings of the Seventh International Financial Cryptography Conference, Guadeloupe, January 2003. N. B. Salem, L. Buttyan, J. P. Hubaux, and M. Jakobsson,"A Charging and Rewarding Scheme for Packet Forwarding in Multi-hop Cellular Net Works," in IEEE/ACM Works hop on Mobile Ad Hoc Networking and Computing (MobiHOC), June2003. S. Zhong, Y. R. Yang, and J. Chen, "Sprite: A Simple, Cheat-proof, Credit-based System for Mobile Ad Hoc Networks,"Technical Report Yale/DCS/TR1235, Department of Computer Science, Yale University, July 2002. S. Marti, T. Giuli, K. Lai, and M. Baker, "Mitigating routing misbehavior in mobile ad hoc networks," in Proceedings of the Sixth International Conference on Mobile Computing and Networking 2000, Boston, MA, Aug. 2000. J. Kong, P. Zerfos, H. Luo, S. Lu, and L. Zhang,"Providing Robust and Ubiquitous Security Support for Mobile Ad Hoc Networks," in Proceedings of the 9th International Conference on Network Protocols (ICNP), November 2001. A. Weimerskirch and G. Thonet, "A Distributed Light-Weight Authentication Model for Ad-hoc Networks," Information Security and Cryptology-ICISC2001, 2001. S. Yi and R. Kravets, "Key Management for Heterogeneous Ad Hoc Wireless Networks," Technical Report UIUCDCS -R -2002 -2290 / UILU -ENG -2002 -1734, University of Illinois at Urbana-Champaign, 2002. C. Perkins, E. Belding-Royer, and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing," Request for Comments: 3561, IETF Network Working Group, July 2003. David B. Johnson, David A. Maltz, and Yih-Chun Hu, "The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)," ITERNET-DRAFT, draft-ietf-manet-dsr-09.txt, IETF MANET Working Group, 15 April 2003. J.P. Hubaux, L. Buttyan, and S. Capkun, "The Quest for Security in Mobile Ad Hoc Networks, " in Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), 2001. Srdjan Capkun, L. Buttyan, and J. P. Hubaux, "Self-Organized Public-Key Management for Mobile Ad-Hoc Networks - Abstract," in Report on a Working Session on Security in Wireless Ad Hoc Networks, ACM Mobile Computing and Communications Review (MC2R), Vol. 6, No. 4, 2002. L. Zhou and Z. Haas, "Securing Ad Hoc Networks," IEEE Network, vol. 13, no. 6, pp. 24-30, November/December 1999. S. Buchegger and J. Y. L. Boudec, "Performance analysis of the CONFIDANT protocol: Cooperation of nodes - fairness in dynamic ad-hoc networks," in Proceedings of IEEE/ACM Workshop on Mobile Ad Hoc Networking and Computing (MobiHOC), IEEE, June 2002.

しかし、従来のセキュリティ機構では、ノードがルータを兼ねるマルチホップ通信を用いるアドホックネットワークやマルチホップセルラネットワークのセキュリティを維持するためには、公開鍵システム（PKI）が必ずしも有効でない場合があるという問題があった。また、各ノードが必ずしもデータ転送に協調しないという問題もある。従来方式では、PKI補助機能とインセンティブ機能は別々に議論され、同時に両機構を提供する提案は無い。しかし、インセンティブ機能を実現するためにPKIを前提とする方法もあり、逆に、PKI補助機能において、ノードの協調を前提とする方法もある。つまり、両機構は互いに補完関係の場合もあり、同時に議論することが重要である。本発明は、上記従来の問題を解決して、インセンティブ機能とPKI補助機能を統合した汎用性の高いセキュリティ機構を実現することを目的とする。

上記の課題を解決するために、本発明では、セルラネットシステムと報酬ポイントモジュール発行管理システムと複数の無線端末とを備えるセルラネットワークのセキュリティ機構のセルラネットシステムに、無線端末を仲介ノードとして認定する手段を備え、報酬ポイントモジュール発行管理システムに、耐タンパーモジュールで構成された報酬ポイントモジュールを発行する手段と報酬ポイントモジュールの報酬ポイントを増加する手段とを備え、仲介ノードに、仲介ノードとしての認定をセルラネットシステムに要求する手段と無線端末を登録する手段と報酬ポイントモジュールとマルチホップ通信手段とを備え、無線端末に、仲介ノードに登録を要求する手段と報酬ポイントモジュールとマルチホップ通信手段とを備え、仲介ノードと無線端末に、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信する手段と、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送する手段と、報酬ポイントを付加した暗号化メッセージを受信して復号する手段とを設けた。

このように構成したことにより、汎用性の高いセキュリティ機構を実現できる。すなわち、オーソリティに代わる仲介ノードにより、インセンティブ機能とPKI補助機能を提供するので、個別提供に比べ、機能の重複を削減できる。PKI補助機能のノードの協調に、インセンティブ機能を利用できる。インセンティブ機能のセキュリティに、PKI補助機能を利用できる。セルラネットに対する制約を最小限に抑えることができる。証明書の検証処理が高い確率で実行可能であるので、接続性がよい。システムに対するオーバヘッドが少ないので、効率がよい。不正を検出できるので、検証性がよい。結託によりシステムの秘密が漏洩しないので、結託耐性がよい。不正ノードを特定できるので、追跡性がよい。

以下、本発明を実施するための最良の形態について、図１〜図10を参照しながら詳細に説明する。

本発明の実施例は、報酬ポイントモジュールの報酬ポイントを増加する権限を有する報酬ポイントモジュール発行管理システムで、耐タンパーモジュールで構成された報酬ポイントモジュールを発行し、セルラネットシステムにより無線端末を仲介ノードとして認定し、仲介ノードに無線端末を登録し、送信無線端末で、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信し、転送無線端末で、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送し、受信無線端末で、報酬ポイントを付加した暗号化メッセージを受信して復号するセキュリティ機構である。

図１は、本発明の実施例におけるセキュリティ機構のシステム管理者による仲介ノードの認定（１）およびノードＡの仲介ノードへの登録（２）を説明する図である。図２は、PKI補助機能における仲介ノードＡとＢへの相互認証および鍵共有の補助を説明する図である。図３は、相互認証および鍵共有の補助手順を説明する図である。図４は、公開鍵ディレクトリサービス手順を説明する図である。図５は、相互通信モデルを説明する図である。図６は、インセンティブ機能の一方向モデルであり、ノードｓからノードｔを経由したノードｒへの送信を説明する図である。図７は、本発明と従来例の通信量・演算量比較表である。図８は、攻撃検出に必要な情報を示す表である。図９は、本発明と従来例のPKI補助機能の比較表である。図10は、本発明と従来例のインセンティブ機能の比較表である。

本発明の実施例におけるセキュリティ機構の原理と動作を説明する。最初に、エンティティに関する定義を説明する。
（１）ノードとは、マルチホップ通信機能を有する無線端末である。特に限定しない場合は、ノードｉまたは一般ノードｉと記す。ノードｉとは、IDコードがｉであるノードのことである。複数のノードを区別する必要のある例では、IDコードとしてＡ，Ｂなど適当なアルファベットを用いる。任意のノード証明書とその秘密鍵と、任意の認証局証明書（CA証明書）と、耐タンパーモジュール（TRM）で構成された報酬ポイントモジュールを有する。

（２）仲介ノードとは、次の条件を満たすノードである。システム管理者の発行する代理証明書とその秘密鍵と、任意のノード証明書とその秘密鍵と、複数のシステム管理者証明書のうち少なくとも一つを検証可能なCA証明書と、TRMで構成された報酬ポイントモジュールを有する。仲介ノードは、一般ノードより多くのリソースを要求されるため、主にノートPCを想定する。特に限定しない場合は、仲介ノードｊと記す。仲介ノードｊとは、IDコードがｊである仲介ノードのことである。一般ノードは、携帯電話やPDA等を想定する。共にマルチホップ通信可能な無線通信手段（Bluetooth、UWB、IEEE802.11等）を備える。

（３）システム管理者とは、セルラネットシステムの管理者である。単にセルラネットシステムとも呼ぶ。Ｍと表記する。無線LANスポットサービスや携帯電話サービスを提供するキャリアを想定する。ほぼ全CA証明書を有する。全ノードが信頼する。
（４）ステーションとは、無線LANスポットサービスのアクセスポイントや携帯電話の基地局の総称である。
（５）モジュール発行者とは、TRMで構成された報酬ポイントモジュールの発行者であり管理者である。報酬ポイントモジュール発行管理システムとも呼ぶ。Ｃと表記する。TRMで構成された報酬ポイントモジュール内の報酬ポイントを増加する権限を有する。システム管理者と同一でもよい。全エンティティが信頼する。

次に、図１を参照しながら、準備フェーズについて説明する。準備フェーズには、仲介ノードの認定段階と、仲介ノードへの登録段階がある。仲介ノードの認定段階では、図１の（１）に示すように、一般ノードが、仲介ノードとして、システム管理者に認定される。仲介ノードへの登録段階では、図１の（２）に示すように、仲介ノードへ、他の一般ノードが登録を行う。その後、仲介ノードが、登録済みのノードに対して、PKI補助・インセンティブ機能の提供を行う。以下に仲介ノードの認定手順を説明する。

Step1：ノードｊは、リソース情報RInfo_jを生成する。リソース情報には少なくとも、ノードｊが公開可能なスペック(例：CPU、メモリ、HD)と、保持するCA証明書のSubjectのリストと、自身の証明書Cert_jが含まれる。このリソース情報RInfo_jに対して、自身の証明書Cert_jに対応する秘密鍵SKey_jを用いて、ディジタル署名Sig_jを生成する。リソース情報RInfo_jとディジタル署名Sig_jを、システム管理者Ｍへ送信する。

Step2：システム管理者Ｍは、ディジタル署名Sig_jを検証する。検証に失敗すれば処理を終了し、検証に成功すれば処理を続行する。
Step3：システム管理者Ｍは、リソース情報RInfo_jに基づき、代理証明書PCert_jと、譲渡情報TInfo_jを発行し、共通鍵CKey_Mjを生成する。代理証明書は、ノードｊを仲介ノードとして保証する証明書であり、有効期間が一日程度のものである。システム管理者Ｍは、各認証局に対応したPCert_jを発行できるため、リソース情報RInfo_jに基づき、ノードｊが扱える枚数分だけ、各認証局に対応した代理証明書PCert_jを発行する。譲渡情報TInfo_jは、リソース情報RInfo_jに基づき、ノードｊが扱える量だけ発行する。システム管理者Ｍの証明書と、各種認証局証明書と、CRL（certificate revocation list）と、不正ノードのブラックリストを含む。仲介ノード間の連携が可能な場合、他の仲介ノードの位置情報と、保持する認証局証明書のSubjectのリストと、仲介ノード間の共通鍵CKey_Iを少なくとも含む。

Step4：システム管理者Ｍは、代理証明書PCert_jと、その秘密鍵PSKey_jと、譲渡情報TInfo_jと、共通鍵CKey_Mjと、これらに対する署名Sig_M（自身の証明書Cert_Mに対応する秘密鍵SKey_Mにより生成）を、証明書Cert_jの公開鍵により暗号化して、その暗号文Enc_Mをノードｊに送る。
Step5：ノードｊは、証明書Cert_jに対応する秘密鍵SKey_jを用いて暗号文Enc_Mを復号する。署名Sig_Mを検証し、成功すれば、復号した情報を受け入れ、ノードｊは、仲介ノードとしての資格を得る。失敗すれば拒否する。

仲介ノードへの登録手順を説明する。仲介ノードｊへの登録とは、一般ノードｉと仲介ノードｊが相互認証を行い、共通鍵を共有することを意味する。
Step１：一般ノードｉは、リソース情報RInfo_iを生成する。このリソース情報RInfo_iに対して、自身の証明書Cert_iに対応する秘密鍵SKey_iを用いて、ディジタル署名Sig_iを生成する。リソース情報RInfo_iとディジタル署名Sig_iを、仲介ノードｊへ送信する。一時ノード証明書TCert_iを取得済みの時は、証明書Cert_iに代わり、一時ノード証明書TCert_iを使用する。一方、仲介ノードｊは、証明書Cert_iの提示時には、一時ノード証明書TCert_iを発行する。

Step２：仲介ノードｊは、署名Sig_iを検証し、失敗時は処理を終了する。仲介ノードｊは、検証に必要な認証局証明書を保持しない場合、仲介ノード間の連携を想定できるモデルでは、他の仲介ノードに、共通鍵CKey_Iを用いて、認証局証明書の提供を依頼できる。
Step3：仲介ノードｊは、一時ノード証明書TCert_iと、その秘密鍵TSKey_iと、共通鍵CKey_jiを生成する。これらに対して、リソース情報RInfo_iに基づき選択した代理証明書PCert_iに対応する秘密鍵PSKey_iにより、署名Sig_iを計算する。共通鍵CKey_jiと、一時ノード証明書TCert_iと、秘密鍵TSKey_iを証明書Cert_iの公開鍵で暗号化した暗号文Enc_jを、代理証明書PCert_jと共に、一般ノードｉへ送信する。
Step4：一般ノードｉは、秘密鍵SKey_iで暗号文Enc_jを復号する。署名Sig_jを検証し、成功時は復号情報を受領し、失敗時には拒絶する。ノードｉが検証可能な認証局証明書を保持しない場合、相互認証済みの他ノードに認証局証明書の提供を依頼できる。

一時ノード証明書は、仲介ノードが上位認証局を検証できるため、任意認証局で発行される証明書と比べ、他の仲介ノードが検証できる可能性が高い。仲介ノードは、一般ノードに提供したサービスに応じて、報酬ポイントをシステム管理者から受け取る。仲介ノードは、サービス提供時に一般ノードから受信した認証情報が一定量になった際、その検証に必要な共通鍵と共に、それらをシステム管理者へ送る。システム管理者は、これらを検証する。検証成功時には、モジュール発行者からサービスに応じた報酬ポイントを発行してもらい、仲介ノードへ送る。仲介ノード間通信が可能な場合は、仲介ノード認定時に、システム管理者は、仲介ノード間共通鍵と他の仲介ノード情報を提供する。これにより、証明書共有によるノード登録時の成功確率を向上させることができる。また、他の仲介ノードに登録している一般ノード同士の相互認証と鍵共有を補助することも可能となる。

第３に、図２と図３を参照しながら、PKI補助機能について説明する。本発明では、PKI補助機能として、相互認証及び鍵共有の補助と公開鍵ディレクトリを提供する。相互認証及び鍵共有の補助を説明する。図２に示すように、仲介ノードｊを介し、登録済みノードＡとノードＢの相互認証及び鍵共有を、共通鍵暗号ベースで実現する。Ｈ(・)を一方向性ハッシュ関数とする。ノードＡとノードＢが、それぞれ別の仲介ノードＥと仲介ノードＦに登録されている場合、Step3、4を、それぞれ登録している仲介ノードＥと仲介ノードＦに対して行い、仲介ノードＥと仲介ノードＦは、それぞれが得た乱数を交換して、認証情報を検証し、成功時は、仲介ノードＥと仲介ノードＦが共通鍵CKey_ABの生成に必要な情報を交換する。なお、仲介ノードＥと仲介ノードＦの間の通信の認証と暗号化には、仲介ノード間共通鍵CKey_Iを用いる。

Step1：ノードＡは、乱数Rand_A生成し、（A‖Rand_A）をノードＢに送信する。ここで、（‖）は連結を示す。
Step2：ノードＢは、Step1の処理開始要求に応じる場合は、乱数Rand_Bを生成し、（B‖Rand_B）を、ノードＡに送信する。
Step3：ノードＡは、乱数Rand_Aと、認証情報AInfo_Aj(＝Ｈ(CKey_jA‖A‖B‖Rand_B))と、ノードＡのIDコードであるＡと、ノードＢのIDコードであるＢを、仲介ノードｊに送信する。
Step4：ノードＢは、乱数Rand_Bと、認証情報AInfo_Bj(＝H(CKey_jB‖B‖A‖Rand_A))と、ノードＢのIDコードであるＢと、ノードＡのIDコードであるＡを、仲介ノードｊに送信する。

Step5：仲介ノードｊは、認証情報AInfo_Ajと認証情報AInfo_Bjを、共通鍵CKey_jAと共通鍵CKey_jBを用いて検証し、失敗時は処理を終了する。
Step6：仲介ノードｊは、仲介ノードｊのIDコードであるｊと、ノードＡのIDコードであるＡと、認証情報AInfo_jA(＝Ｈ(CKey_jA‖j‖A‖Rand_A‖Rand_B))と、共通鍵CKey_jAを用いて共通鍵CKey_ABを暗号化した暗号文Enc_jAを、ノードＡへ送信する。
Step7：仲介ノードｊは、仲介ノードｊのIDコードであるｊと、ノードＢのIDコードであるＢと、認証情報AInfo_jB(＝Ｈ(CKey_jB‖j‖B‖Rand_A‖Rand_B))と、共通鍵CKey_jBを用いて共通鍵CKey_ABを暗号化した暗号文Enc_jBを、ノードＢへ送信する。
Step8：ノードＡとノードＢは、各々共通鍵CKey_jAと共通鍵CKey_jBにより、認証情報AInfo_jAと認証情報AInfo_jBを検証する。検証成功時は、各々共通鍵CKey_jAと共通鍵CKey_jBにより、暗号文Enc_jAと暗号文Enc_jBを復号し、共通鍵CKey_ABを得る。

第４に、図４を参照しながら、公開鍵ディレクトリサービスについて説明する。仲介ノードｊへ登録済みのノードｉに対し、仲介ノードｊが保有する情報（証明書や証明書失効リスト等）を提供する機能である。一般のノードは、自身が認証済みのノード証明書、CA証明書を他のノードに提供できる。ただし、提供を受けるノードが自己責任で利用し、本発明では不正ノードの検出と追跡を保証しない。

Step1：ノードｉは、要求するノード又はCA証明書のSubjectリストと、ノードｉのIDコードであるｉと、ノードｊのIDコードであるｊと、認証情報AInfo_ij（＝Ｈ(CKey_ji‖i‖j‖Subjectリスト)）を、仲介ノードｊに送信する。
Step2：仲介ノードｊは、認証情報AInfo_ijを検証し、失敗時は処理を終了する。
Step3：仲介ノードｊは、仲介ノードｊのIDコードであるｊと、ノードｉのIDコードであるｉと、Subjectリストに記載された証明書のうち、保有する証明書Certs_j、認証情報AInfo_ji(＝Ｈ(CKey_ji‖j‖i‖Certs_j))を、ノードｉへ送信する。
Step4：ノードｉは、認証情報AInfo_jiを検証し、成功時はCerts_jを受け入れ、失敗時は拒絶する。

第５に、インセンティブ機能の前提となる、耐タンパーモジュール（TRM）で構成された報酬ポイントモジュールの報酬ポイント管理方法を説明する。各ノードが登録する仲介ノードと、報酬ポイントを仲介する仲介ノードは、異なって構わない。ここでは簡単化のために、いずれも仲介ノードｊとする。ノードｉは、自身のTRMで構成された報酬ポイントモジュールCard_iの報酬ポイント情報RP_{i_Y}から、Ｘ(≦Ｙ)ポイントの報酬ポイント情報RP_{i_X_O}を引き出せる。報酬ポイント情報RP_{i_Y}の意味は、Ｙポイント分のノードｉの報酬ポイント情報であるということである。報酬ポイント情報RP_{i_X_O}の意味は、Ｘポイント分をノードｉの保有ポイントから引き出したということである。このとき、報酬ポイントモジュールCard_iは、報酬ポイント情報RP_{i_Y}のポイントデータをＸポイント減少する。その結果、報酬ポイント情報はRP_{i_Y-X}となる。報酬ポイント情報を送ることを、単に報酬ポイントを送るということもある。

一方、モジュール発行者Ｃのみが、報酬ポイントを増加できる。例えば、報酬ポイントモジュールCard_i中の報酬ポイント情報RP_{i_Y}のポイントデータを、Ｌポイント増加する場合は、モジュール発行者Ｃに依頼して報酬ポイント情報RP_{i_L_I}を生成してもらい、それを報酬ポイントモジュールCard_iに入力する。報酬ポイント情報RP_{i_L_I}の意味は、Ｌポイント分をノードｉの保有ポイントに加算するデータであるということである。ここで、報酬ポイントモジュールCard_iとモジュール発行者Ｃは、共通鍵CKey_iCを共有し、報酬ポイント情報RP_{i_X_O}とRP_{i_L_I}の生成と検証に共通鍵CKey_iCを用いる。報酬ポイントモジュールCard_iは、共通鍵CKey_iCにより生成されない報酬ポイント情報RP_{i_L_I}を拒絶する。

第６に、図５を参照しながら、相互通信モデルについて説明する。請求ノードＲに対して提供ノードＰがサービスを提供するモデルである。請求ノードＲが、ノード証明書又はCA証明書を、提供ノードＰに求める。提供ノードＰが、請求された証明書を請求ノードＲに与える。請求ノードＲは、対価として報酬ポイントを、提供ノードＰに与える。ここで、請求ノードＲと提供ノードＰは相互認証済みで、共通鍵CKey_PRを共有する。また、認証情報AInfo_ABは、共通鍵CKey_ABと、ノードＡからノードＢへ送るデータを、一方向性関数Ｈ(・)に入力して得た出力とする。なお、認証情報の検証に失敗した場合は処理を終了する。

Step1：請求ノードＲは、（R‖P‖請求List‖AInfo_RP）を、提供ノードＰへ送る。請求Listは、証明書を請求する場合であれば、Subjectを含み、他のブラックリスト等のデータを請求する場合は、それらの名称を含むものとする。
Step2：提供ノードＰは、認証情報AInfo_RPを検証し、（P‖R‖提供可能List‖AInfo_PR）を、請求ノードＲへ送信する。提供可能Listは、請求リストのうち提供可能な証明書のSubject等を含むリストである。
Step3：請求ノードＲは、認証情報AInfo_PRを検証し、提供可能Listを確認し、報酬ポイントモジュールCard_Rから、提供可能Listに応じたポイントＴの報酬ポイント情報RP_{R_T_O}を引き出し、（R‖P‖RP_{R_T_O}‖AInfo_RP）を、提供ノードＰに送信する。データに応じたポイント数は事前に決定しておく。請求ノードＲは、そのポイントを、仲介ノードを介してシステム管理者から受け取り済みとする。
Step4：提供ノードＰは、認証情報AInfo_RPを検証する。（P‖R‖提供可能Listに対応するデータ‖AInfo_PR）を、請求ノードＲへ送信する。（P‖j‖RP_{R_T_O}‖AInfo_Pj）を、仲介ノードｊへ送信する。受信後即送信せず、報酬ポイントが一定量貯まってから一括請求する。

Step5：請求ノードＲは、認証情報AInfo_PRを検証し、データを受領する。
Step6：仲介ノードｊは、認証情報AInfo_Pjを検証し、（j‖M‖RP_{R_T_O}‖AInfo_jM）を、システム管理者Ｍに送信する。
Step7：システム管理者Ｍは、認証情報AInfo_jMを検証し、モジュール発行者Ｃから報酬ポイント情報RP_{P_T_I}を発行してもらい、（M‖j‖RP_{P_T_I}‖AInfo_Mj）を、仲介ノードｊに送信する。
Step8：仲介ノードｊは、認証情報AInfo_Mjを検証し、（j‖P‖RP_{P_T_I}‖AInfo_jP）を、提供ノードＰに送信する。
Step9：提供ノードＰは、認証情報AInfo_jPを検証し、報酬ポイント情報RP_{P_T_I}を報酬ポイントモジュールCard_Pに入力し、報酬ポイント情報RP_{P_Y}のポイントデータを増加する。その結果、報酬ポイント情報はRP_{P_Y+T}となる。

第７に、図６を参照しながら、一方向通信モデルについて説明する。送信ノードｓが、対価として報酬ポイント情報を添付したメッセージMessageの転送を転送ノードｔに求め、転送ノードｔが受信ノードｒへ転送を行い、受信ノードｒが報酬ポイント情報を仲介ノードｊに送付することで、転送ノードｔが報酬ポイント情報を得るモデルである。これは、非特許文献１に記載されたPacket Purse Modelとほぼ同じである。「事前に受信ノードｒまでのホップ数が分からないために添付する報酬ポイントが確定できない」という問題がある。例えば、非特許文献11に記載されたDSRでは、メッセージ送信前にホップ数が決定しているが、非特許文献10に記載されたAODVの様に、事前に決定できないものもある。本発明では、それを解決するための手段を設ける。送信ノードｓは、平均的に予想されるホップ数に数ポイント上乗せしたポイント数Ｗの報酬ポイント情報を、メッセージMessageに添付する。余りの報酬ポイント情報を、仲介ノードｊ経由で送信ノードｓへ返却する。また、送信ノードｓと受信ノードｒ間でのメッセージ認証・メッセージ暗号化機能を備える。共通鍵暗号としてブロック暗号、ストリーム暗号のどちらを用いるかは、インセンティブ機能の本質でないため考慮外とする。

送信ノードｓと受信ノードｒ間は相互認証済みであり、共通鍵CKey_srを共有する。認証情報AInfo_ABは、共通鍵CKey_ABと、本文を除くヘッダ情報を連結したデータを、一方向性ハッシュ関数Ｈ(・)に入力して得た出力とする。なお、認証情報の検証に失敗した場合は、処理を終了する。転送ノードは複数台存在する場合もあるが、簡単化するために１台の場合を説明する。

Step1：送信ノードｓは、報酬ポイントモジュールCard_sから、ポイント数Ｗの報酬ポイント情報RP_{s_W_O}を引き出す。Messageを暗号化した暗号文Enc_sと、そのハッシュ値Hash_s(＝Ｈ(Enc_s))を生成する。（s‖t‖r‖Hash_s‖RP_{s_W_O}‖W）をHeader_sとして、（Header_s‖AInfo_sj‖AInfo_sr‖Enc_s）を、転送ノードｔへ送信する。受信ノードｒに送信するための最初の転送ノードｔは、送信ノードｓには既知でえあるとする。転送ノードｔから受信ノードｒまでの経路は、送信ノードｓには未知である。
Step2：転送ノードｔは、Ｈ(Enc_s)を計算し、Hash_sと等しいことを検証する。Ｗ←Ｗ−１とし、（s‖t‖r‖Hash_s‖RP_{s_W_O}‖W）をHeader_tとし、（Header_t‖AInfo_sj‖AInfo_tj‖AInfo_sr‖Enc_s）を、受信ノードｒへ送信する。ステーション以降のネットワークがマルチホップ通信に対応していない場合（固定電話網等）は、インセンティブ機能が不要となるため、システム管理者Ｍにて直接Step5と同様に、報酬ポイントRPの清算処理を実施する。転送ノードが複数の場合は、受信ノードｒに代えて、次の転送ノード宛てに送信し、次ノードが受信ノードｒになるまでStep2を繰り返す。

Step3：受信ノードｒは、Ｈ(Enc_s)を計算し、ハッシュ値Hash_sと等しいことを検証し、認証情報AInfo_srを検証する。Messageを復号し、（s‖t‖r‖Hash_s‖RP_{s_W_O}‖W）をHeader_rとして、（Header_r‖AInfo_sj‖AInfo_tj‖AInfo_rj）を、仲介ノードｊへ送信する。
Step4：仲介ノードｊは、（AInfo_sj‖AInfo_tj‖AInfo_rj）を検証し、（s‖t‖r‖j‖Hash_s‖RP_{s_W_O}）をHeade_rjとし、（Heade_rj‖AInfo_jM）を、システム管理者Ｍへ送信する。
Step5：システム管理者Ｍは、認証情報AInfo_jMを検証する。報酬ポイント情報RP_{s_W_O}を、モジュール発行者Ｃへ送信して、報酬ポイント情報RP_{t_Wt_I}とRP_{r_Wr_I}とRP_{s_Ws_I}を発行してもらう。システムにおいて事前に決定されたポイントＷ_{Nt_i}とＷ_NrをＷから引いた残りのポイントとなるため、存在しない場合もありえる。ただし、残りポイントが負の値になることは想定しない。モジュール発行者Ｃは、認証情報AInfo_jM及び報酬ポイント情報RP_{s_W_O}が不正の場合は発行しない。ここで、Ｗ＝Ｗ_t＋Ｗ_r＋Ｗ_sとする。（M‖j‖RP_{t_Wt_I}‖RP_{r_Wr_I}‖RP_{s_Ws_I}‖AInfo_Mj）を、仲介ノードｊへ送る。

Step6：仲介ノードｊは、認証情報AInfo_Mjを検証する。（j‖t‖RP_{t_Wti_I}‖AInfo_jt）、（j‖r‖RP_{r_Wr_I}‖AInfo_jr）、（j‖s‖RP_{s_Ws_I}‖AInfo_js）を、それぞれ転送ノードｔ、受信ノードｒ、送信ノードｓへ送信する。
Step7：転送ノードｔ、受信ノードｒ、送信ノードｓはそれぞれ、認証情報AInfo_jt、AInfo_jr、AInfo_jsを検証し、それぞれ報酬ポイント情報RP_{t_Wt_I}、RP_{r_Wr_I}、RP_{s_Ws_I}を、報酬ポイントモジュールCard_t、Card_r、Card_sへ入力して、報酬ポイントRPを増加する。転送ノードｔが次ノードへ転送ができない場合、添付の報酬ポイント情報と認証情報を、仲介ノードｊ経由でシステム管理者Ｍへ送信する。システム管理者Ｍはそれらを検証後、報酬ポイント情報の一部とその残りを、モジュール発行者にそれぞれ転送ノードｔと送信ノードｓが扱える形に変換してもらい、それぞれを仲介ノードｊ経由で、転送ノードｔと送信ノードｓへ送ることで、報酬ポイントの紛失を防ぐ。

第８に、その他の機能を説明する。本発明は、協調しないノードは報酬ポイントRPを得られない仕組みのため、ネットワークから切断する様な罰は与えない。不正を行うノードは、これを検出してノードを特定後、システム管理者が不正ノードのブラックリストを生成する。これを仲介ノード経由で一般ノードに配布し、各ノードがリストに掲載されたノードと接続しないことで、不正ノードを排除する。仲介ノードｊへの登録時に、ノードｊはオンラインでCRL（Certificate Revocation List）を検査できない。そのため、報酬ポイントRPを請求する時に、仲介ノードｊは、システム管理者Ｍに、検証済みノード証明書を提出する。システム管理者ＭがCRLを検査する。該当する場合は、仲介ノードｊと、証明書に対応するノードと、相互認証を行ったノードへ通知する。システム管理者Ｍは、常にCRL検査が可能である。システム管理者ＭはTTPであり、その証明書の失効する可能性が低い。仲介ノードｊは、システム管理者Ｍの証明書をCRLにより検査しない。

第９に、機能に関する性能評価について説明する。接続性について、PKI補助機能の有無ごとに、検証処理が実行可能な確率（実行確率Ｐ）を算出し、比較する。実行確率は、証明書の検証に必要なCA証明書を保持又は入手可能であり、検証処理が実行できる確率を示す。ノードＡとノードＢの相互認証（実行確率をP_ABとする）は、システム管理者Ｍと仲介ノードＥの相互認証（確率P_ME）、システム管理者Ｍと仲介ノードＦの相互認証（確率P_MF）、仲介ノードＥとノードＡの相互認証（確率P_EA）、仲介ノードＦとノードＢの相互認証（確率P_FB）に分けられる。検討を簡単にするため、仲介ノードＥと仲介ノードＦ、ノードＡとノードＢのリソースは等しいとし、P_jA＝P_jBと扱う。仲介ノードＥ＝仲介ノードＦと仮定し、仲介ノードは単に仲介ノードｊと表記する。

確率P_ABは、確率P_Mjと確率P_jA（＝P_jB）に分けられ、確率P_Mjは、システム管理者Ｍが仲介ノードｊの証明書を検証する確率（P_M__j）と仲介ノードｊがシステム管理者Ｍの証明書を検証する確率（P_j__M）に分けられる。確率P_jAは仲介ノードｊがＡの証明書を検証する確率（P_{j_A}）とノードＡが仲介ノードｊの証明書を検証する確率（P_{A_j}）に分けられる。以上より接続性を示す実行確率P_ABが以下に導ける。
P_AB＝P_Mj×(P_jA)²＝P_{M_j}×P_{j_M}×P_{j_A} ²×P_{A_j} ²
定義よりP_{M_j}＝P_{j_M}＝１。また、確率P_{j_A}は次の理由によりほぼ１と期待する。
（１）仲介ノードｊは多くリソースを有する。
（２）ノードＡは他仲介ノードから一時ノード証明書を発行されている可能性がある。
（３）仲介ノードｊは他仲介ノードからCA証明書の提供を受けられる可能性がある。

よって、P_AB≒P_{A_j} ²となり、確率P_ABは確率P_{A_j}に帰着する。同様にPKI補助機能が無い場合の実行確率P_AB'はノードＡがノードＢの証明書を検証する場合の実行確率P_{A_B}に帰着する。つまり、確率P_{A_B}はノードＢ以外に検証対象ノードを変更できないために実行確率が固定的に決定するのに対し、確率P_{A_j}は異なる仲介ノードを選択すること、及びノードＡが認証済みの他ノードからCA証明書の入手が期待でき、確率P_{A_B}より実行確率を高くできるため接続性を向上できる。

図７を参照しながら、効率性について説明する。本発明と同様に、セルラネットを想定し、従来方式のうちでは効率性の高い非特許文献４記載の方法を従来例Ａとして、図７に示す表で比較する。頻繁に実施されるメッセージ転送において、転送時に１メッセージに追加されるデータ量と、送信・転送・受信ノードの総演算量、受信ノードからシステム管理者への完了通知のデータ量と、その生成に必要な演算量を比較する。従来例Ａでは、１セッション毎にセッション確立処理を要するが、本発明は、システム使用開始時に仲介ノードへの登録処理を要する。これらは実施回数が異なると予想され、比較しない。従来例Ａに合わせて、一方向性ハッシュ関数の出力は16Byte、IDコードは4Byte、カウンタは２Byteとする。なお、Ｆを転送ノード数、１メッセージの総パケット数をＵとする。報酬ポイント情報RPについては、Ｈ(・)により生成されると想定して16Byteとして扱う。表１から明らかなように、大きなメッセージを送る場合は、本発明が有利となり、ホップ数の大きくなるノードと通信する場合は、従来例Ａが有利となることが分かる。

安全性について説明する。攻撃者を以下の目的を持つノードと定義する。
・RPを不正取得する又は報酬ポイントを不正に払わない
・他ノードに対する報酬ポイント情報の取得妨害
・任意のノード又はステーションへの成りすまし
・不正にメッセージを転送しない
攻撃者は通信を盗聴可能で、任意のデータを送信可能である。TRMを破ること、及びステーション以降のBBインフラへの攻撃はできないものとする。

図８を参照しながら、検証性について説明する。仲介ノードの認定及び仲介ノードへの登録は、PKIの相互認証を行い、その公開鍵を用いて共通鍵を共有するため、なりすましや共通鍵の不正取得は困難である。また、PKI補助機能は、共通鍵により相互認証を行い、共通鍵により新規共通鍵を共有するため、仲介ノードが信頼できる限り、なりすましや新規共通鍵の不正な取得は困難である。相互通信モデルでは、提供ノードＰが請求ノードＲからRPを受信後に請求されたデータを提供しない場合と、提供ノードＰが受信したRPが不正の場合がある。前者は提供ノードＰが仲介ノードｊ経由でシステム管理者Ｍへ不正を通報可能であり、後者はシステム管理者Ｍからモジュール発行者へPRを送るときに不正を検出可能である。一方向通信モデルでは、システム管理者Ｍが、送信ノードｓ、転送ノードｔ、受信ノードｒからの｛Header_i，AInfo_i｝（これらを併せてログと呼ぶ）を比較することで、不正の検出が可能である。図８に示す表に、想定する攻撃と、攻撃を検出するのに必要なログを示す。なお、攻撃が検出可能な場合は○を、困難な場合は×を記す。表２から明らかなように、本発明が検出性を満たす（つまり、想定する全攻撃を防ぐ）ためには、デフォルトの受信ノードのログと別に、送信ノードと転送ノードのログをシステム管理者Ｍが収集する必要がある。

ノードは、システムの秘密情報を持たず、かつノードの秘密鍵は、他ノードの秘密鍵と関連性がなく、結託によりシステム全体をブレイクするのに必要な情報量は増加しない。本発明は結託耐性を満たす。本発明では、仲介ノードへの登録が必要であるため、不正ノードを事後に追跡できる。仲介ノード自体は、システム管理者へ登録されるため、不正仲介ノードも追跡できる。本発明は追跡性を満たす。

図９を参照しながら、PKI補助機能の比較を説明する。他方式では、インセンティブ・PKI補助機能を同時に提供しないため、機能毎に本発明との比較を行う。非特許文献12に記載の方法を従来例Ｂとする。非特許文献13に記載の方法を従来例Ｃとする。非特許文献14に記載の方法を従来例Ｄとする。非特許文献７に記載の方法を従来例Ｅとする。非特許文献９に記載の方法を従来例Ｆとする。非特許文献８に記載の方法を従来例Ｇとする。なお、本発明は、仲介ノードに関する処理を、インセンティブ・PKI補助機能に関して一括処理できるため、個別に提供する場合より効率的である。PKI補助機能を比較すると、図９に示す表から明らかなように、本発明では、全ての機能を満足し、かつ一般ノードへの負荷も小さいため、セルラネットが想定可能な場合は最も優れている。

図10を参照しながら、インセンティブ機能を比較する。図10に示す表から明らかなように、本発明では、ノード自身がポイントを管理でき、かつルーティング方法に依存せず、かつPKIを提供できるため、他ネットワークへの接続が容易であり、他方式より汎用性に優れる。一方、処理負荷は、PKIのみや監視の場合と比較して、PKIと共通鍵暗号のハイブリッド使用により少ない。非特許文献１に記載の方法を従来例Ｈとする。非特許文献２に記載の方法を従来例Ｉとする。非特許文献３に記載の方法を従来例Ｊとする。非特許文献４に記載の方法を従来例Ｋとする。非特許文献５に記載の方法を従来例Ｌとする。非特許文献６に記載の方法を従来例Ｍとする。非特許文献15に記載の方法を従来例Ｎとする。

上記のように、本発明の実施例では、セキュリティ機構を、報酬ポイントモジュール発行管理システムで、耐タンパーモジュールで構成された報酬ポイントモジュールを発行し、報酬ポイントモジュールの報酬ポイントを増加する権限を持ち、セルラネットシステムで、無線端末を仲介ノードとして認定し、仲介ノードで、無線端末を登録し、送信無線端末で、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信し、転送無線端末で、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送し、受信無線端末で、報酬ポイントを付加した暗号化メッセージを受信して復号する構成としたので、汎用性の高いセキュリティ機構を実現できる。

本発明のセキュリティ機構は、セルラネットワークにおけるマルチホップ通信に最適である。

本発明の実施例におけるセキュリティ機構の仲介ノードの認定（１）と仲介ノードへの登録（２）を説明する図、本発明の実施例におけるセキュリティ機構のPKI補助機能を説明する図、本発明の実施例におけるセキュリティ機構の相互認証および鍵共有の補助手順を説明する図、本発明の実施例におけるセキュリティ機構の公開鍵ディレクトリサービス手順を説明する図、本発明の実施例におけるセキュリティ機構の相互通信モデルを説明する図、本発明の実施例におけるセキュリティ機構のインセンティブ機能を説明する図、本発明の実施例におけるセキュリティ機構と従来例の通信量・演算量比較表、本発明の実施例におけるセキュリティ機構の攻撃検出に必要な情報を示す表、本発明の実施例におけるセキュリティ機構と従来例のPKI補助機能の比較表、本発明の実施例におけるセキュリティ機構と従来例のインセンティブ機能の比較表、従来のマルチホップ通信の概念図、従来のマルチホップ通信のシステムモデル、従来のアドホックネットワークにおけるマルチホップ通信を説明する図、従来のマルチホップセルラネットワークにおけるマルチホップ通信を説明する図である。

Claims

セルラネットシステムと報酬ポイントモジュール発行管理システムと複数の無線端末とを備えるセルラネットワークのセキュリティ機構であって、前記セルラネットシステムは、無線端末を仲介ノードとして認定する手段を備え、前記報酬ポイントモジュール発行管理システムは、耐タンパーモジュールで構成された報酬ポイントモジュールを発行する手段と報酬ポイントモジュールの報酬ポイントを増加する手段とを備え、前記仲介ノードは、仲介ノードとしての認定をセルラネットシステムに要求する手段と無線端末を登録する手段と報酬ポイントモジュールとマルチホップ通信手段とを備え、前記無線端末は、仲介ノードに登録を要求する手段と報酬ポイントモジュールとマルチホップ通信手段とを備え、前記仲介ノードと前記無線端末は、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信する手段と、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送する手段と、報酬ポイントを付加した暗号化メッセージを受信して復号する手段とを有することを特徴とするセルラネットワークのセキュリティ機構。
前記無線端末は、報酬ポイントを付加して証明書または証明書失効リスト提供サービスを要求する手段と、要求に応じて証明書または証明書失効リストを提供して報酬ポイントを受け取る手段とを有することを特徴とする請求項１記載のセルラネットワークのセキュリティ機構。
セルラネットシステムと報酬ポイントモジュール発行管理システムと複数の無線端末とを備えるセルラネットワークにおけるマルチホップセキュリティ通信方法であって、前記報酬ポイントモジュール発行管理システムは、耐タンパーモジュールで構成された報酬ポイントモジュールを発行し、準備フェーズの仲介ノード認定手順において、無線端末が仲介ノードとしての認定をセルラネットシステムに要求し、前記セルラネットシステムは、無線端末を仲介ノードとして認定し、準備フェーズの一般ノード登録手順において、無線端末が仲介ノードに登録を要求し、仲介ノードは無線端末を登録し、通信フェーズにおいて、前記無線端末の送信端末は、報酬ポイントを付加した暗号化メッセージをマルチホップ通信で送信し、転送端末は、報酬ポイントを付加した暗号化メッセージを受信してマルチホップ通信で転送し、受信端末は、報酬ポイントを付加した暗号化メッセージを受信して復号し、報酬ポイントモジュール発行管理システムは、報酬ポイントモジュールの報酬ポイントを増加する情報を発行することを特徴とするマルチホップセキュリティ通信方法。
前記無線端末は、必要に応じて報酬ポイントを付加して証明書または証明書失効リスト提供サービスを要求し、サービスを要求されたとき証明書または証明書失効リストを提供して報酬ポイントを受け取ることを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
仲介ノードが自身に登録済みの無線端末に対して、自身の保持する証明書または証明書失効リストを提供することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
第１の仲介ノードが自身に登録済みの第１の無線端末に対して、自身に登録済みの第２の無線端末または、第２の仲介ノードに登録済みの第３の無線端末との相互認証および鍵共有を仲介することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
第１の仲介ノードが自身への登録が成功した無線端末に対して、一時的な無線端末証明書を発行し、前記無線端末が前記無線端末証明書を用いて第２の仲介ノードへ登録することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
送信端末が必要と予想される報酬ポイント以上の報酬ポイントを暗号化メッセージに付加して転送端末に送り、転送端末が前記暗号化メッセージを受信端末に送り、受信端末は前記暗号化メッセージに付加された報酬ポイントが必要数以上の場合に、仲介ノードに報酬ポイントを送り、仲介ノードはセルラネットシステムを経由して報酬ポイントモジュール発行管理システムに報酬ポイントを送り、報酬ポイントモジュール発行管理システムは、受信した報酬ポイントと合計が等しくなるように割り振った報酬ポイントを送信端末と受信端末に仲介ノード経由で発行することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
転送端末は、暗号化メッセージが一定時間以上転送できなかった場合に、暗号化メッセージの報酬ポイントを仲介ノードに送り、仲介ノードはセルラネットシステム経由で報酬ポイントモジュール発行管理システムに報酬ポイントを送り、報酬ポイント発行管理システムは受信した報酬ポイントと合計が等しくなるように割り振った報酬ポイントを送信端末と転送端末に仲介ノード経由で発行することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
仲介ノードは無線端末登録時に無線端末と第１の共通鍵を共有し、セルラネットシステムは仲介ノード認定時に仲介ノードと第２の共通鍵を共有し、送信端末と転送端末は送信時に暗号化メッセージに対して第１の共通鍵を用いて第１の認証情報を計算して暗号化メッセージに付加し、受信端末は受信した暗号化メッセージに対して第１の共通鍵を用いて第１の認証情報を計算して全ての第１の認証情報を仲介ノードの送信し、仲介ノードは第１の共通鍵と第１の認証情報に対して第２の共通鍵を用いて第２の認証情報を計算し、第１の共通鍵と第１の認証情報と第２の認証情報をセルラネットシステムに送信し、セルラネットシステムが第１の共通鍵と第１の認証情報と第２の認証情報を検証することにより不正を検出することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。
送信端末または転送端末は前記第１の認証情報を仲介ノードに送信し、仲介ノードが第１の認証情報に対して第２の共通鍵を用いて第２の認証情報を計算し、第１の共通鍵と第１の認証情報と第２の認証情報をセルラネットシステムに送信し、セルラネットシステムが第１の共通鍵と第１の認証情報と第２の認証情報を検証することにより不正を検出することを特徴とする請求項３記載のマルチホップセキュリティ通信方法。