JPWO2012014294A1 - 鍵設定方法、ノード、およびネットワークシステム - Google Patents

鍵設定方法、ノード、およびネットワークシステム Download PDF

Info

Publication number
JPWO2012014294A1
JPWO2012014294A1 JP2012526241A JP2012526241A JPWO2012014294A1 JP WO2012014294 A1 JPWO2012014294 A1 JP WO2012014294A1 JP 2012526241 A JP2012526241 A JP 2012526241A JP 2012526241 A JP2012526241 A JP 2012526241A JP WO2012014294 A1 JPWO2012014294 A1 JP WO2012014294A1
Authority
JP
Japan
Prior art keywords
key
node
gateway
encryption key
acquisition request
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.)
Granted
Application number
JP2012526241A
Other languages
English (en)
Other versions
JP5397547B2 (ja
Inventor
尚 兒島
尚 兒島
和快 古川
和快 古川
武仲　正彦
正彦 武仲
伊豆　哲也
哲也 伊豆
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.)
Fujitsu Ltd
Original Assignee
Fujitsu 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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2012014294A1 publication Critical patent/JPWO2012014294A1/ja
Application granted granted Critical
Publication of JP5397547B2 publication Critical patent/JP5397547B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H04W84/22—Self-organising networks, e.g. ad-hoc networks or sensor networks with access to wired networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

アドホックネットワーク（Ａ１）〜（Ａｎ）のいずれかのアドホックネットワーク（Ａｉ）内の新規ノード（Ｎ）は、管理サーバ（１０１）と通信可能な携帯端末（１０２）との接続を検知すると、鍵の取得要求をアドホックネットワーク（Ａｉ）にブロードキャストする。つぎに、新規ノード（Ｎ）は、ブロードキャストされた鍵の取得要求がアドホックネットワーク（Ａｉ）内のゲートウェイ（Ｇｉ）に転送された結果、ゲートウェイ（Ｇｉ）から管理サーバ（１０１）に送信されたゲートウェイ（Ｇｉ）固有の鍵を、携帯端末（１０２）を介して管理サーバ（１０１）から受信する。そして、新規ノード（Ｎ）は、受信されたゲートウェイ（Ｇｉ）固有の鍵を設定する。

Description

本発明は、データを暗号化するための鍵を設定する鍵設定方法、ノード、およびネットワークシステムに関する。
アドホックネットワークは、無線通信でリンクする自己構成型のネットワークの一種である。アドホックネットワークは複数のノードにより構成される。また、アドホックネットワーク内の各ノードは、マルチホップ通信によりパケットの送受信を行う。マルチホップ通信は、互いの通信圏内に存在しないノード同士が、各ノードの通信圏内に存在する別のノードを介して通信を行う技術である。
また、アドホックネットワークとインターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの他のネットワークとを接続する場合、ゲートウェイと呼ばれる中継機器を用いて、ネットワーク間の通信の転送が行われる。
アドホックネットワークを利用した技術として、各家庭の電力メータに無線通信可能なノードを組み込んで、作業員が現地に出向くことなく、アドホックネットワーク経由でメータ確認などの業務を行うシステムがある。各家庭の電力の使用量などの個人情報を扱うアドホックネットワークでは、秘匿性や改ざん防止の観点からセキュアな通信を行うことが要求される。
そこで、従来のシステムでは、アドホックネットワーク内のノード間で送受信されるパケットを暗号化することで、セキュアな通信を確保することが行われている。この際、システム内の全ノードで共通の暗号鍵を用いた場合、鍵漏洩時のリスクが大きいため、ゲートウェイごとに暗号鍵を変えるシステムがある。
また、システムへの新規ノードの初期導入時などにおいて、新規ノードは、暗号鍵が設定されるまでの間、アドホックネットワーク内の他のノードとセキュアな通信を行うことができない。このため、アドホックネットワーク経由で新規ノードに暗号鍵を自動設定することが難しく、作業員が現地に出向いて暗号鍵の設定作業を行っている。
また、セキュア通信に関する先行技術として、例えば、端末が通信制御を行うのに必要な各種の通信制御情報を端末とは異なる他の通信装置を利用して認証サーバから取得する技術がある（例えば、下記特許文献１参照。）。また、アドホックネットワークにおいて通信開始時の鍵交換を安定して行うための技術がある（例えば、下記特許文献２参照。）。また、各通信端末が最寄りの通信端末と公開鍵を用いて相互認証を行うアドホックネットワークに関する技術がある（例えば、下記特許文献３参照。）。
特開２００６−１３５８７４号公報 特開２００７−８８７９９号公報 特開２００７−１３３８６号公報
しかしながら、上述した従来技術では、アドホックネットワーク内の各ノードに設定する暗号鍵をゲートウェイごとに変える場合、新規ノードの初期導入時などにおいて、新規ノードが属するゲートウェイを特定することが難しいという問題があった。例えば、新規ノードの設置場所の住所から候補となるゲートウェイを絞り込むことはできても、天候や近傍の建物との位置関係などの要因により通信状況が変化する。このため、現地に出向いた作業員が実際にどのゲートウェイと通信可能であるかを確認する必要があり、作業員の暗号鍵の設定作業にかかる作業時間および作業負荷の増大を招くという問題がある。
本発明は、上述した従来技術による問題点を解消するため、アドホックネットワーク内のノードが用いる暗号鍵の設定作業の効率化を図ることができる鍵設定方法、ノード、およびネットワークシステムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、開示の鍵設定方法は、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードが実行する鍵設定方法であって、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する。
また、上述した課題を解決し、目的を達成するため、開示のノードは、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードであって、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する。
また、上述した課題を解決し、目的を達成するため、開示のネットワークシステムは、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりパケットを送受信するノードと、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと、を含むネットワークシステムであって、前記ノードは、前記サーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定し、前記サーバは、前記取得要求が転送された前記いずれかのアドホックネットワーク内のゲートウェイから、前記ゲートウェイ固有の鍵を受信し、受信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記ノードに送信する。
本鍵設定方法、ノード、およびネットワークシステムによれば、アドホックネットワーク内のノードが用いる暗号鍵の設定作業の効率化を図ることができるという効果を奏する。
実施の形態にかかるネットワークシステムの一実施例を示す説明図である。 ネットワークシステムへの新規ノードの導入例を示す説明図である。 新規ノードの導入時におけるネットワークシステムの動作例を示すシーケンス図である。 実施の形態にかかる管理サーバのハードウェア構成を示すブロック図である。 実施の形態にかかるノード等のハードウェア構成を示すブロック図である。 ノードの機能的構成を示すブロック図である。 ＧＷ探索フレームの送信指示の具体例を示す説明図である。 ＧＷ探索フレームのデータ構造の一例を示す説明図である。 ゲートウェイの機能的構成を示すブロック図である。 鍵通知フレームの具体例を示す説明図（その１）である。 鍵通知フレームの具体例を示す説明図（その２）である。 管理サーバの機能的構成を示すブロック図である。 送信済リストの具体例を示す説明図である。 暗号鍵ＤＢの記憶内容の一例を示す説明図である。 管理サーバの認証情報の一例を示す説明図である。 携帯端末の認証情報の一例を示す説明図である。 ノードの鍵設定処理手順の一例を示すフローチャートである。 ゲートウェイの鍵通知処理手順の一例を示すフローチャートである。 管理サーバの鍵提供処理手順の一例を示すフローチャート（その１）である。 管理サーバの鍵提供処理手順の一例を示すフローチャート（その２）である。
以下に添付図面を参照して、この発明にかかる鍵設定方法、ノード、およびネットワークシステムの好適な実施の形態を詳細に説明する。
（ネットワークシステムの一実施例）
図１は、実施の形態にかかるネットワークシステムの一実施例を示す説明図である。図１において、ネットワークシステム１００は、管理サーバ１０１と、ゲートウェイＧ１〜Ｇｎと、ノードＮ１−１〜Ｎ１−ｍ１，Ｎ２−１〜Ｎ２−ｍ２，…，Ｎｎ−１〜Ｎｎ−ｍｎと、を含む構成である。
管理サーバ１０１は、インターネット、ＬＡＮ、ＷＡＮなどのネットワークＮＷ１を介して、ゲートウェイＧ１〜Ｇｎと相互に通信可能に接続されている。管理サーバ１０１は、各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵を、各ゲートウェイＧ１〜Ｇｎから取得して保持するコンピュータである。
各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵（以下、「暗号鍵Ｋ１〜Ｋｎ」という）は、各ゲートウェイＧ１〜Ｇｎが属する各アドホックネットワークＡ１〜Ａｎ内のノード間で送受信されるデータを暗号化するための鍵情報である。以下の説明では、データの一例として、データ本体を含むペイロード部に宛先などを含むヘッダ部が付加されたパケットを用いて説明する。
また、管理サーバ１０１は、携帯電話網やインターネットなどのネットワークＮＷ２を介して、携帯端末１０２と相互に通信可能である。携帯端末１０２は、作業員ＯＰが使用する携帯型の通信装置であり、例えば、携帯電話機、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）電話機、スマートフォン、ノート型のパーソナル・コンピュータなどである。
ゲートウェイＧｉは、アドホックネットワークＡｉとネットワークＮＷ１とを接続する中継機器である（ｉ＝１，２，…，ｎ）。具体的には、ゲートウェイＧｉは、アドホックネットワークＡｉを介して、ノードＮｉ−１〜Ｎｉ−ｍｉと接続されている。また、ゲートウェイＧｉは、ネットワークＮＷ１を介して、管理サーバ１０１と接続されている。
ゲートウェイＧｉは、アドホックネットワークＡｉのプロトコルとネットワークＮＷ１のプロトコルの両方を理解し、アドホックネットワークＡｉとネットワークＮＷ１との間の通信の転送を行う。ゲートウェイＧｉは、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するためのゲートウェイＧｉ固有の暗号鍵Ｋｉを有している。
ノードＮｉ−１〜Ｎｉ−ｍｉは、所定の通信圏内の他ノードとマルチホップ通信を行う無線通信装置である。アドホックネットワークＡｉでは、すべてのノードＮｉ−１〜Ｎｉ−ｍｉがゲートウェイＧｉと直接通信できる必要はなく、一部のノードがゲートウェイＧｉと通信可能であればよい。
ネットワークシステム１００は、例えば、各家庭の電力やガスの使用量を収集するシステムに適用することができる。具体的には、例えば、各家庭の電力メータやガスメータに各ノードＮｉ−１〜Ｎｉ−ｍｉを組み込むことで、アドホックネットワークＡｉ内のノード間で各家庭の電力やガスの使用量を送受信する。なお、各家庭の電力やガスの使用量は、各ノードＮｉ−１〜Ｎｉ−ｍｉが計測してもよく、また、各ノードＮｉ−１〜Ｎｉ−ｍｉが電力メータやガスメータから取得してもよい。
ゲートウェイＧｉは、アドホックネットワークＡｉ内のノードＮｉ−１〜Ｎｉ−ｍｉから受信した各家庭の電力やガスの使用量を、ネットワークＮＷ１を介して電力会社やガス会社のサーバ（例えば、管理サーバ１０１）に送信する。これにより、作業員が現地に出向くことなく電力やガスの使用量を収集することができる。
また、ネットワークシステム１００では、アドホックネットワークＡｉごとにゲートウェイＧｉ固有の暗号鍵Ｋｉを用いてパケットを暗号化する。これにより、アドホックネットワークＡｉのセキュア通信（データ秘匿性、改ざん防止など）を確保する。また、アドホックネットワークＡｉごとに暗号鍵Ｋｉを変えることで、鍵漏洩時のリスクを低減させる。
なお、図１の例では、アドホックネットワークＡｉ内に１台のゲートウェイＧｉを設ける構成としたが、同一のアドホックネットワークＡｉ内に複数台のゲートウェイＧｉを設ける構成としてもよい。この場合、アドホックネットワークＡｉ内で送受信されるパケットを暗号化するための暗号鍵Ｋｉは、複数台のゲートウェイＧｉで共通である。
（新規ノードＮの導入時における暗号鍵Ｋｉの設定例）
つぎに、図１に示したネットワークシステム１００への新規ノードＮの導入時における暗号鍵Ｋｉの設定例について説明する。
図２は、ネットワークシステムへの新規ノードの導入例を示す説明図である。図２において、ネットワークシステム１００のアドホックネットワークＡｉ内に新規ノードＮが導入されている。なお、図２では、アドホックネットワークＡｉ内のノードＮｉ−１〜Ｎｉ−ｍｉのうち、代表としてノードＮｉ−１〜Ｎｉ−３を示している。
新規ノードＮの導入時は、作業員ＯＰは新規ノードＮがどのアドホックネットワークＡｉに属しているのかわからない。そこで、本実施の形態では、作業員ＯＰが使用する携帯端末１０２を利用して、新規ノードＮに設定すべき暗号鍵Ｋｉを管理サーバ１０１から取得して新規ノードＮに自動設定する。以下、図２に示した新規ノードＮの導入時におけるネットワークシステム１００の動作例について説明する。
図３は、新規ノードの導入時におけるネットワークシステムの動作例を示すシーケンス図である。図３のシーケンスにおいて、（１）携帯端末１０２は、ネットワークＮＷ２を介して管理サーバ１０１に接続する。この際、携帯端末１０２は、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）を用いて、管理サーバ１０１とセキュアな通信を行う。なお、管理サーバ１０１と携帯端末１０２との間でセキュア通信を実現するための通信方式については、図１５および図１６を用いて後述する。
（２）携帯端末１０２は、有線または無線のネットワークＮＷ３を介して新規ノードＮに接続する。具体的には、例えば、作業員ＯＰが、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブルを用いて、携帯端末１０２と新規ノードＮとを接続することで、携帯端末１０２と新規ノードＮとの間にネットワークＮＷ３が確立される。
（３）新規ノードＮは、携帯端末１０２との接続を検知すると、アドホックネットワークＡｉ内でマルチホップ通信により送受信されるパケットを暗号化するための鍵の取得要求をアドホックネットワークＡｉにブロードキャストする。ここでは、鍵の取得要求が、新規ノードＮの通信圏内に存在するノードＮｉ−３に送信される。
（４）ノードＮｉ−３は、新規ノードＮからの鍵の取得要求を通信圏内のノードＮｉ−１に送信する。（５）ノードＮｉ−１は、ノードＮｉ−３からの鍵の取得要求を通信圏内のゲートウェイＧｉに送信する。この結果、新規ノードＮからの鍵の取得要求がアドホックネットワークＡｉ内のゲートウェイＧｉに転送される。
（６）ゲートウェイＧｉは、新規ノードＮからの鍵の取得要求を受信すると、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。（７）管理サーバ１０１は、ネットワークＮＷ２を介して、ゲートウェイＧｉからのゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２に送信する。
（８）携帯端末１０２は、ネットワークＮＷ３を介して、管理サーバ１０１からのゲートウェイＧｉ固有の暗号鍵Ｋｉを新規ノードＮに送信する。（９）新規ノードＮは、携帯端末１０２からの暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定する。
なお、携帯端末１０２と新規ノードＮとの接続は、新規ノードＮに対する暗号鍵Ｋｉの設定が終了するまで維持する。また、暗号鍵Ｋｉの設定が終了して携帯端末１０２と新規ノードＮとの接続を切断すると、携帯端末１０２の中から暗号鍵Ｋｉが自動で削除されるようにしてもよい。これにより、携帯端末１０２の紛失時などにおけるリスクを低減させることができる。
このように、本実施の形態にかかるネットワークシステム１００によれば、新規ノードＮの導入時に、作業員ＯＰの携帯端末１０２を介して、新規ノードＮと管理サーバ１０１との一時的な通信路を確立することができる。また、新規ノードＮからブロードキャストされた鍵の取得要求がゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された暗号鍵Ｋｉを、携帯端末１０２を介して管理サーバ１０１から新規ノードＮに提供することができる。これにより、新規ノードＮに設定すべき暗号鍵Ｋｉを容易に取得することができ、新規ノードＮが用いる暗号鍵Ｋｉの設定作業の効率化を図ることができる。
なお、以下の説明において、「ノードＮ」とは、ネットワークシステム１００のアドホックネットワークＡ１〜ＡｎのいずれかのアドホックネットワークＡｉ内でマルチホップ通信によりパケットを送受信するノードを示す。また、「ノード等」とは、ネットワークシステム１００のゲートウェイＧ１〜ＧｎおよびノードＮを示す。
（管理サーバ１０１のハードウェア構成）
図４は、実施の形態にかかる管理サーバのハードウェア構成を示すブロック図である。図４において、管理サーバ１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）４０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０３と、磁気ディスクドライブ４０４と、磁気ディスク４０５と、光ディスクドライブ４０６と、光ディスク４０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０８と、ディスプレイ４０９と、キーボード４１０と、マウス４１１と、を備えている。また、ＣＰＵ４０１〜マウス４１１はバス４００によってそれぞれ接続されている。
ここで、ＣＰＵ４０１は、管理サーバ１０１の全体の制御を司る。ＲＯＭ４０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ４０３は、ＣＰＵ４０１のワークエリアとして使用される。磁気ディスクドライブ４０４は、ＣＰＵ４０１の制御に従って磁気ディスク４０５に対するデータのリード／ライトを制御する。磁気ディスク４０５は、磁気ディスクドライブ４０４の制御で書き込まれたデータを記憶する。
光ディスクドライブ４０６は、ＣＰＵ４０１の制御に従って光ディスク４０７に対するデータのリード／ライトを制御する。光ディスク４０７は、光ディスクドライブ４０６の制御で書き込まれたデータを記憶したり、光ディスク４０７に記憶されたデータをコンピュータに読み取らせたりする。
Ｉ／Ｆ４０８は、通信回線を通じてネットワークＮＷ１，ＮＷ２に接続され、このネットワークＮＷ１，ＮＷ２を介して他の装置（例えば、ゲートウェイＧｉ、携帯端末１０２）に接続される。Ｉ／Ｆ４０８は、ネットワークＮＷ１，ＮＷ２と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ４０８には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
ディスプレイ４０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ４０９は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
キーボード４１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス４１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。なお、図２に示した携帯端末１０２についても、図４に示した管理サーバ１０１と同様のハードウェア構成により実現できる。
（ノード等のハードウェア構成）
図５は、実施の形態にかかるノード等のハードウェア構成を示すブロック図である。図５において、ノード等は、ＣＰＵ５０１と、ＲＡＭ５０２と、フラッシュメモリ５０３と、Ｉ／Ｆ５０４と、暗号化回路５０５と、を備えている。ＣＰＵ５０１〜暗号化回路５０５は、バス５００によってそれぞれ接続されている。
ここで、ＣＰＵ５０１は、ノード等の全体の制御を司る。ＲＡＭ５０２は、ＣＰＵ５０１のワークエリアとして使用される。フラッシュメモリ５０３は、プログラムや暗号鍵などの鍵情報を記憶している。Ｉ／Ｆ５０４は、マルチホップ通信によりパケットを送受信する。また、ゲートウェイＧｉのＩ／Ｆ５０４は、通信回線を通じてネットワークＮＷ１に接続され、このネットワークＮＷ１を介して管理サーバ１０１に接続される。
暗号化回路５０５は、データを暗号化する場合に暗号鍵によりデータを暗号化する回路である。暗号化をソフトウェア的に実行する場合は、暗号化回路５０５に相当するプログラムをフラッシュメモリ５０３に記憶させておくことで、暗号化回路５０５は不要となる。
（ノードＮの機能的構成）
図６は、ノードの機能的構成を示すブロック図である。図６において、ノードＮは、検知部６０１と、受付部６０２と、フレーム送信部６０３と、鍵受信部６０４と、設定部６０５と、フレーム受信部６０６と、を含む構成である。各機能部（検知部６０１〜フレーム受信部６０６）は、具体的には、例えば、図５に示したＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０４により、その機能を実現する。また、各機能部（検知部６０１〜フレーム受信部６０６）の処理結果は、特に指定する場合を除いて、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶される。
検知部６０１は、管理サーバ１０１と通信可能な携帯端末１０２との接続を検知する。具体的には、例えば、作業員ＯＰがＵＳＢケーブルを用いて携帯端末１０２とノードＮとを接続した結果、検知部６０１が、ＵＳＢケーブルを介した携帯端末１０２との接続を検知する。
受付部６０２は、検知部６０１によって接続が検知された携帯端末１０２から、鍵の取得要求の送信指示を受け付ける。ここで、鍵の取得要求は、アドホックネットワークＡｉ内でマルチホップ通信によりノード間で送受信されるパケットを暗号化するための暗号鍵Ｋｉの取得要求である。
鍵の取得要求は、例えば、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉを探索して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを提供してもらうためのものである。そこで、以下の説明では、「鍵の取得要求」を、鍵の提供元となるゲートウェイＧｉを探索するための「ＧＷ探索フレーム」と称する。
具体的には、例えば、受付部６０２が、ＵＳＢケーブルなどのネットワークＮＷ３を介して、携帯端末１０２からＧＷ探索フレームの送信指示を受け付ける。ここで、ＧＷ探索フレームの送信指示の具体例について説明する。
図７は、ＧＷ探索フレームの送信指示の具体例を示す説明図である。図７において、送信指示７００は、コマンドおよびユーザＩＤを有している。コマンドは、ノードＮに対する指示内容を示している。ここでは、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉの探索指示を表す『ｓｅａｒｃｈ ｇｗ』が記述されている。ユーザＩＤは、携帯端末１０２の識別子である。ここでは、『Ｄ１』が記述されている。
図６の説明に戻り、フレーム送信部６０３は、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする。ＧＷ探索フレームは、例えば、フレームの種別、携帯端末１０２の識別子、ノードＮの識別子を含む情報であり、暗号化されていないノーマルフレームである。
ここで、携帯端末１０２の識別子は、例えば、上記受付部６０２によって受け付けたＧＷ探索フレームの送信指示から特定される。また、ノードＮの識別子は、例えば、予め設定されてＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されている。具体的には、例えば、フレーム送信部６０３が、携帯端末１０２との接続が検知された場合に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。
また、フレーム送信部６０３は、例えば、携帯端末１０２からＧＷ探索フレームの送信指示を受け付けた場合に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。すなわち、携帯端末１０２との接続が検知され、かつ、ＧＷ探索フレームの送信指示を受け付けた場合に、フレーム送信部６０３が、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする。
これにより、携帯端末１０２を利用して、ノードＮに対して鍵設定とは異なる設定作業などを行う際に、携帯端末１０２との接続が検知された時点で、ノードＮからＧＷ探索フレームがブロードキャストされることを防ぐことができる。ここで、ＧＷ探索フレームの具体例について説明する。
図８は、ＧＷ探索フレームのデータ構造の一例を示す説明図である。図８において、ＧＷ探索フレーム８００は、ヘッダ部８１０とペイロード部８２０とを含む構成である。ヘッダ部８１０には、宛先アドレス、差出アドレス、種別、サイズおよびホップ数が記述されている。ペイロード部８２０には、ユーザＩＤおよびノードＩＤが記述されている。
ここで、宛先アドレスは、送信先のアドレスである。ここでは、ブロードキャスト用のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス『ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ』が記述されている。差出アドレスは、送信元のアドレスである。ここでは、アドホックネットワークＡ１内のノードＮとは異なる他のノードＮのＭＡＣアドレスが記述されている。種別は、フレームの種別である。ここでは、ＧＷ探索フレームを示す『２』が記述されている。サイズは、フレームのデータサイズ（バイト）である。
ホップ数は、ノード間でＧＷ探索フレーム８００を残り何回転送するのかを示す残余の転送回数である。ノードＮからブロードキャストされるＧＷ探索フレーム８００のホップ数の最大値は予め設定されている。ホップ数はＧＷ探索フレーム８００の転送時にデクリメントされ、ホップ数が『０』となったＧＷ探索フレーム８００は棄却される。ここでは、ＧＷ探索フレーム８００のホップ数『１０』が記述されている。
ユーザＩＤは、ノードＮに接続されている携帯端末１０２の識別子である。ここでは、ユーザＩＤ『Ｄ１』が記述されている。ノードＩＤは、ノードＮの識別子である。ここでは、ノードＩＤ『Ｎ１−ｘ』が記述されている。なお、ここでは宛先アドレスおよび差出アドレスの一例として、ＭＡＣアドレスを用いて説明したが、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスなどのアドレスを用いることにしてもよい。
図６の説明に戻り、鍵受信部６０４は、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵Ｋｉを、携帯端末１０２を介して管理サーバ１０１から受信する。ここで、ゲートウェイＧｉ固有の暗号鍵Ｋｉは、ブロードキャストされたＧＷ探索フレームがゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された鍵である。
この暗号鍵Ｋｉは、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するための鍵であり、例えば、１２８〜２５６ビット程度のバイナリデータである。また、この暗号鍵Ｋｉは、例えば、パケットを暗号化するとともに、暗号鍵Ｋｉを用いて暗号化されたパケットを復号することができる共通鍵である。
具体的には、例えば、ノードＮからブロードキャストされたＧＷ探索フレームは、アドホックネットワークＡｉを介してゲートウェイＧｉに転送される。この結果、ゲートウェイＧｉは、ネットワークＮＷ１を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。つぎに、管理サーバ１０１は、ネットワークＮＷ２を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２に送信する。そして、鍵受信部６０４が、ネットワークＮＷ３を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２から受信する。
設定部６０５は、受信されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定する。これにより、以降においてノードＮが送信対象となるパケットを暗号化、および暗号化されたパケットを復号することが可能となり、アドホックネットワークＡｉ内のノード間でセキュア通信を行うことができる。
フレーム受信部６０６は、アドホックネットワークＡｉ内の自ノードとは異なる他ノードからＧＷ探索フレームを受信する。すなわち、アドホックネットワークＡｉ内の他ノードでの鍵設定のために、他ノードからブロードキャストされたＧＷ探索フレームをフレーム受信部６０６が受信する。
この場合、ノードＮは、受信された他ノードからのＧＷ探索フレームを別ノードに転送する。ただし、アドホックネットワークＡｉでは、安全性の観点から、各ノードＮは、暗号化されていないノーマルフレームを受信した場合、該ノーマルフレームを破棄するように設定されている場合がある。
そこで、フレーム送信部６０３は、受信されたノーマルフレームの種別がＧＷ探索フレームを示す『２』の場合、該ノーマルフレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。これにより、アドホックネットワークＡｉ内の自ノードとは異なる他ノードからのＧＷ探索フレームを別ノードに転送することができる。
（ゲートウェイＧｉの機能的構成）
図９は、ゲートウェイの機能的構成を示すブロック図である。図９において、ゲートウェイＧｉは、ＧＷ受信部９０１と、作成部９０２と、ＧＷ送信部９０３と、を含む構成である。各機能部（ＧＷ受信部９０１〜ＧＷ送信部９０３）は、具体的には、例えば、図５に示したＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０４により、その機能を実現する。また、各機能部（ＧＷ受信部９０１〜ＧＷ送信部９０３）の処理結果は、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶される。
ＧＷ受信部９０１は、アドホックネットワークＡｉを介して、ノードＮからブロードキャストされたＧＷ探索フレームを受信する。具体的には、例えば、ＧＷ受信部９０１が、アドホックネットワークＡｉ内のノードＮとは異なる他ノードからＧＷ探索フレームを直接受信する。
作成部９０２は、ＧＷ探索フレームが受信された場合、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを作成する。ここで、鍵通知フレームは、例えば、携帯端末１０２の識別子、ノードＮの識別子、ゲートウェイＧｉの識別子およびゲートウェイＧｉ固有の暗号鍵Ｋｉを含む情報である。
携帯端末１０２の識別子およびノードＮの識別子は、受信されたＧＷ探索フレームから特定される。また、ゲートウェイＧｉ固有の暗号鍵Ｋｉは、例えば、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されている。具体的には、例えば、作成部９０２が、受信されたＧＷ探索フレーム８００に基づいて、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを作成する。ここで、鍵通知フレームの具体例について説明する。
図１０は、鍵通知フレームの具体例を示す説明図（その１）である。図１０において、鍵通知フレーム１０００は、ユーザＩＤ、ノードＩＤ、ゲートウェイＩＤおよび暗号鍵に関する情報を有している。ここで、ユーザＩＤは、携帯端末１０２の識別子である。このユーザＩＤは、図８に示したＧＷ探索フレーム８００のペイロード部８２０から特定されたものである。ノードＩＤは、ノードＮの識別子である。このノードＩＤは、ＧＷ探索フレーム８００のペイロード部８２０から特定されたものである。ゲートウェイＩＤは、ゲートウェイＧｉの識別子である。暗号鍵は、ゲートウェイＧｉ固有の暗号鍵Ｋｉである。
図９の説明に戻り、ＧＷ送信部９０３は、ネットワークＮＷ１を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。具体的には、例えば、ＧＷ送信部９０３が、作成された鍵通知フレーム１０００を管理サーバ１０１に送信することにしてもよい。これにより、単にゲートウェイＧｉ固有の暗号鍵Ｋｉのみを送信する場合に比べて、管理サーバ１０１において、暗号鍵Ｋｉの提供先となる携帯端末１０２やノードＮを識別することができる。
また、詳細は後述するが、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する構成とした場合、鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉを含む必要がない。そこで、上記作成部９０２は、例えば、図１１に示すようなゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレーム１１００を作成することにしてもよい。
図１１は、鍵通知フレームの具体例を示す説明図（その２）である。図１１において、鍵通知フレーム１１００は、ユーザＩＤ、ノードＩＤおよびゲートウェイＩＤに関する情報を有している。すなわち、鍵通知フレーム１１００は、図１０に示した鍵通知フレーム１０００の中からゲートウェイＧ１固有の暗号鍵Ｋ１を削除したものである。
管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する構成とした場合、上記ＧＷ送信部９０３は、例えば、ゲートウェイＧ１固有の暗号鍵Ｋ１を含まない鍵通知フレーム１１００を管理サーバ１０１に送信する。
（管理サーバ１０１の機能的構成）
図１２は、管理サーバの機能的構成を示すブロック図である。図１２において、管理サーバ１０１は、ＳＶ受信部１２０１と、ＳＶ送信部１２０２と、判断部１２０３と、抽出部１２０４と、を含む構成である。各機能部（ＳＶ受信部１２０１〜抽出部１２０４）は、具体的には、例えば、図４に示したＲＯＭ４０２、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶されたプログラムをＣＰＵ４０１に実行させることにより、または、Ｉ／Ｆ４０８により、その機能を実現する。また、各機能部（ＳＶ受信部１２０１〜抽出部１２０４）の処理結果は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶される。
ＳＶ受信部１２０１は、ネットワークＮＷ１を介して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを受信する。具体的には、例えば、ＳＶ受信部１２０１が、ネットワークＮＷ１を介して、図１０に示した鍵通知フレーム１０００を受信する。鍵通知フレーム１０００は、携帯端末１０２に対するゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求である。
ＳＶ送信部１２０２は、受信されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、ネットワークＮＷ２を介して携帯端末１０２に送信する。具体的には、例えば、ＳＶ送信部１２０２が、受信された鍵通知フレーム１０００を、ネットワークＮＷ２を介して携帯端末１０２に送信する。この結果、携帯端末１０２が、鍵通知フレーム１０００に含まれる暗号鍵Ｋ１を、ネットワークＮＷ３を介してノードＮに送信することになる。
ここで、管理サーバ１０１は、ネットワークＮＷ２を介して、複数の携帯端末１０２と通信可能に接続されている場合がある。この場合、ＳＶ送信部１２０２は、例えば、鍵通知フレーム１０００に含まれるユーザＩＤから送信先の携帯端末１０２を識別することができる。鍵通知フレーム１０００の例では、ＳＶ送信部１２０２は、ユーザＩＤ『Ｄ１』の携帯端末１０２に鍵通知フレーム１０００を送信する。
また、アドホックネットワークＡｉ内のノードＮからゲートウェイＧｉに辿り着くまでの経路は複数存在する場合がある。この場合、ノードＮからブロードキャストされたＧＷ探索フレームは、複数の経路を辿ってゲートウェイＧｉに到達する。その結果、ゲートウェイＧｉは、ノードＮからブロードキャストされたＧＷ探索フレームを複数回受信することになる。
この場合、ゲートウェイＧｉは、ＧＷ探索フレームを受信する都度、鍵通知フレームを作成して管理サーバ１０１に送信することになる。そして、管理サーバ１０１は、鍵通知フレームを受信する都度、その鍵通知フレームを携帯端末１０２に送信することになる。この結果、携帯端末１０２は、管理サーバ１０１から同一の鍵通知フレームを複数回受信することになる。
これでは、作業員ＯＰが同一の携帯端末１０２を用いて、複数のノードＮの鍵設定を連続して行う場合に、誤った暗号鍵ＫｉをノードＮに設定してしまう可能性がある。例えば、アドホックネットワークＡ１内のノードＮ１−ｘとアドホックネットワークＡ２内のノードＮ２−ｘの鍵設定を連続して行う場合を想定する。このとき、ノードＮ１−ｘへの暗号鍵Ｋ１の設定が終了し、作業員ＯＰが携帯端末１０２をノードＮ２−ｘに接続したあと、管理サーバ１０１から暗号鍵Ｋ１を含む鍵通知フレームを受信した場合、ノードＮ２−ｘに暗号鍵Ｋ１を誤って設定してしまう。
そこで、管理サーバ１０１において、暗号鍵Ｋｉ（鍵通知フレーム）を送信済みのノードＮを管理することで、同一の鍵通知フレームを重複して携帯端末１０２に送信することを防ぐことができる。ここで、鍵通知フレームを送信済みのノードＮを管理するための送信済リストの具体例について説明する。
図１３は、送信済リストの具体例を示す説明図である。図１３において、送信済リスト１３００は、暗号鍵Ｋｉを送信済みのノードＮのノードＩＤと、送信済みの暗号鍵Ｋｉとを関連付けて記憶している。送信済リスト１３００は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置により実現される。
図１３の例では、アドホックネットワークＡ１内のノードＮ１−１のノードＩＤ『Ｎ１−１』と、ノードＮ１−１に送信された『暗号鍵Ｋ１』とが関連付けて記憶されている。また、アドホックネットワークＡ１内のノードＮ１−２のノードＩＤ『Ｎ１−２』と、ノードＮ１−２に送信された『暗号鍵Ｋ１』とが関連付けて記憶されている。
図１２の説明に戻り、判断部１２０３は、暗号鍵Ｋｉを送信済みのノードＮを管理する送信済リストを参照することにより、携帯端末１０２に鍵通知フレームを送信するか否かを判断する。具体的には、例えば、判断部１２０３が、送信済リスト１３００を参照して、鍵通知フレームに含まれるノードＩＤが登録済みか否かを判断する。
ここで、鍵通知フレームに含まれるノードＩＤが登録済みの場合、判断部１２０３が、携帯端末１０２に鍵通知フレームを送信しないと判断する。この場合、ＳＶ送信部１２０２による鍵通知フレームの送信処理は行われない。一方、鍵通知フレームに含まれるノードＩＤが未登録の場合、判断部１２０３が、携帯端末１０２に鍵通知フレームを送信すると判断する。
そして、ＳＶ送信部１２０２が、携帯端末１０２に鍵通知フレームを送信する。鍵通知フレームが携帯端末１０２に送信されると、例えば、鍵通知フレームに含まれているノードＩＤおよび暗号鍵Ｋｉが送信済リスト１３００に登録される。鍵通知フレーム１０００の例では、ノードＩＤ『Ｎ１−ｘ』と暗号鍵『Ｋ１』とが関連付けられて送信済リスト１３００に登録される。
これにより、同一の鍵通知フレームを重複して携帯端末１０２に送信することを防ぐことができる。さらに、暗号鍵Ｋｉを送信済みのノードＮを管理することで、複数の異なるアドホックネットワークの境界付近にノードＮが設置された場合などに、複数の異なる暗号鍵がノードＮに送信されることを防ぐことができる。
具体的には、例えば、ノードＮの設置場所がアドホックネットワークＡ１，Ａ２の境界付近の場合、ノードＮからブロードキャストされたＧＷ探索フレームがゲートウェイＧ１，Ｇ２に転送される可能性がある。この場合、管理サーバ１０１は、ゲートウェイＧ１，Ｇ２から鍵通知フレームを受信し、それら鍵通知フレームを携帯端末１０２に送信することになる。この結果、複数の異なる暗号鍵Ｋ１，Ｋ２がノードＮに送信されてしまう。そこで、暗号鍵Ｋｉを送信済みのノードＮを管理して鍵通知フレームの重複送信を防ぐことで、複数の異なる暗号鍵がノードＮに送信されることを防ぐ。
また、判断部１２０３は、送信済リスト１３００を参照して、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが登録済みか否かを判断することにしてもよい。そして、判断部１２０３は、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが登録済みの場合、携帯端末１０２に鍵通知フレームを送信しないと判断する。
一方、判断部１２０３は、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが未登録、または、ノードＩＤと暗号鍵のいずれかが登録済みの場合、携帯端末１０２に鍵通知フレームを送信すると判断する。すなわち、判断部１２０３は、鍵通知フレームに含まれるノードＩＤが登録済みでも暗号鍵が未登録の場合、携帯端末１０２に鍵通知フレームを送信すると判断する。これにより、例えば、アドホックネットワークＡ１内のノードＮに暗号鍵Ｋ１を設定したあと、該ノードＮを他のアドホックネットワークＡ２に属する別の場所に移動させて使用する場合に、ノードＮに設定すべき新たな暗号鍵Ｋ２を提供することができる。
なお、管理サーバ１０１は、ＳＶ送信部１２０２による鍵通知フレームの携帯端末１０２への送信後において、携帯端末１０２との接続が切断された場合、ゲートウェイＧｉから受信した鍵通知フレームを削除することにしてもよい。
また、上述した説明では、各ゲートウェイＧｉ固有の暗号鍵Ｋｉを含む鍵通知フレームをゲートウェイＧｉから管理サーバ１０１に送信する場合について説明したが、これに限らない。例えば、管理サーバ１０１において、ネットワークシステム１００内の各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを予め保持しておく構成としてもよい。ここで、各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する暗号鍵ＤＢ（データベース）の具体例について説明する。
図１４は、暗号鍵ＤＢの記憶内容の一例を示す説明図である。図１４において、暗号鍵ＤＢ１４００は、ゲートウェイＩＤおよび暗号鍵のフィールドを有し、各フィールドに情報を設定することで、ゲートウェイＧ１〜Ｇｎごとの鍵情報１４００−１〜１４００−ｎをレコードとして記憶している。
ここで、ゲートウェイＩＤは、ゲートウェイＧｉの識別子である。暗号鍵は、ゲートウェイＧｉ固有の暗号鍵Ｋｉである。鍵情報１４００−１を例に挙げると、ゲートウェイＧ１固有の暗号鍵Ｋ１が記憶されている。なお、暗号鍵ＤＢ１４００は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置により実現される。
このように、管理サーバ１０１がゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する場合、ＳＶ受信部１２０１は、ネットワークＮＷ１を介して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレームを受信する。具体的には、例えば、ＳＶ受信部１２０１が、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレーム１１００を受信する。
また、抽出部１２０４は、ゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレームが受信された場合、暗号鍵ＤＢ１４００の中からゲートウェイＧｉ固有の暗号鍵Ｋｉを抽出する。具体的には、例えば、抽出部１２０４が、暗号鍵ＤＢ１４００の中から、受信された鍵通知フレーム１１００に含まれるゲートウェイＩＤ『Ｇ１』と関連付けて記憶されている暗号鍵Ｋ１を抽出する。
そして、ＳＶ送信部１２０２は、抽出されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、ネットワークＮＷ２を介して携帯端末１０２に送信する。このように、ゲートウェイＧｉから暗号鍵Ｋｉを含まない鍵通知フレームを送信することで、暗号鍵Ｋｉを含む鍵通知フレームを送信する場合に比べて、ゲートウェイＧｉと管理サーバ１０１との間の通信時におけるデータ量を削減することができる。
また、管理サーバ１０１への鍵通知フレームの初回送信時のみ、ゲートウェイＧｉに暗号鍵Ｋｉを含む鍵通知フレームを送信させて、それ以降は、暗号鍵Ｋｉを含まない鍵通知フレームを送信させることにしてもよい。この場合、管理サーバ１０１は、鍵通知フレームの初回受信時に、鍵通知フレームに含まれる暗号鍵ＫｉをゲートウェイＩＤと関連付けて暗号鍵ＤＢ１４００に登録することにしてもよい。これにより、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを予め保持しておく必要がなくなる。
なお、ゲートウェイＧｉが暗号鍵Ｋｉを含む鍵通知フレームを管理サーバ１０１に送信する場合は、暗号鍵Ｋｉの抽出処理が不要となるため、管理サーバ１０１は上記抽出部１２０４および暗号鍵ＤＢ１４００を備えない構成としてもよい。
（管理サーバ１０１と携帯端末１０２との間の通信方式）
ここで、管理サーバ１０１と携帯端末１０２との間の通信方式の一実施例について説明する。まず、携帯端末１０２からみた管理サーバ１０１のサーバ認証について説明する。具体的には、例えば、まず、携帯端末１０２が、予め決められたＩＰアドレスを用いて管理サーバ１０１に接続する。
そして、携帯端末１０２が、管理サーバ１０１からＳＳＬサーバ証明書を受信する。受信されたＳＳＬサーバ証明書は、例えば、図１５に示すように管理サーバ１０１のＩＰアドレスと関連付けて携帯端末１０２の記憶装置に記憶される。
図１５は、管理サーバの認証情報の一例を示す説明図である。図１５において、管理サーバ１０１の認証情報１５００は、ＩＰアドレスおよびＳＳＬサーバ証明書を有する。ＩＰアドレスは、管理サーバ１０１のＩＰアドレスである。Ｘ．５０９証明書は、管理サーバ１０１のＳＳＬサーバ証明書（公開鍵証明書）である。
携帯端末１０２は、予め自端末に組み込まれている公開鍵を用いて、ＳＳＬサーバ証明書を復号することでサーバ認証を行う。公開鍵は、例えば、第三者認証機関によって発行されたものである。この公開鍵を用いてＳＳＬサーバ証明書を正しく復号できれば、ＳＳＬサーバ証明書が第三者認証機関によって証明された正しい証明書であることがわかり、ひいては管理サーバ１０１の身元が保証されたことになる。
つぎに、管理サーバ１０１からみた携帯端末１０２のユーザ認証について説明する。ここでは、図１６に示すような携帯端末１０２の認証情報１６００を用いて、携帯端末１０２のユーザ認証を行う場合を例に挙げて説明する。認証情報１６００は、例えば、管理サーバ１０１のＲＯＭ４０２、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶されている。
図１６は、携帯端末の認証情報の一例を示す説明図である。図１６において、携帯端末１０２の認証情報１６００は、ユーザＩＤおよびパスワードを有する。ユーザＩＤは、携帯端末１０２の識別子である。パスワードは、携帯端末１０２を使用するユーザを認証するためのものである。
具体的には、例えば、まず、携帯端末１０２が、ユーザＩＤおよびパスワードのペアを管理サーバ１０１に送信する。このユーザＩＤおよびパスワードは、携帯端末１０２の記憶装置に予め登録されていてもよく、また、携帯端末１０２の入力装置（不図示）を用いたユーザの操作入力により受け付けてもよい。
このあと、管理サーバ１０１は、携帯端末１０２からのユーザＩＤおよびパスワードのペアを、認証情報１６００のユーザＩＤおよびパスワードのペアと一致判定する。ここで、認証情報１６００のユーザＩＤおよびパスワードと一致すれば、携帯端末１０２のユーザの身元が保証されたことになる。
なお、認証後において、携帯端末１０２は、例えば、管理サーバ１０１のＳＳＬサーバ証明書に含まれる公開鍵を用いてパケットを暗号化して管理サーバ１０１との通信を行う。これにより、管理サーバ１０１と携帯端末１０２との間でセキュアな通信を行うことができる。
（ノードＮの鍵設定処理手順）
図１７は、ノードの鍵設定処理手順の一例を示すフローチャートである。図１７のフローチャートにおいて、まず、検知部６０１により、管理サーバ１０１と通信可能な携帯端末１０２との接続を検知したか否かを判断する（ステップＳ１７０１）。
ここで、携帯端末１０２との接続を検知するのを待って（ステップＳ１７０１：Ｎｏ）、検知した場合（ステップＳ１７０１：Ｙｅｓ）、受付部６０２により、携帯端末１０２からＧＷ探索フレームの送信指示を受け付けたか否かを判断する（ステップＳ１７０２）。
ここで、ＧＷ探索フレームの送信指示を受け付けるのを待って（ステップＳ１７０２：Ｎｏ）、受け付けた場合（ステップＳ１７０２：Ｙｅｓ）、フレーム送信部６０３により、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする（ステップＳ１７０３）。
このあと、鍵受信部６０４により、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２から受信したか否かを判断する（ステップＳ１７０４）。
ここで、ゲートウェイＧｉ固有の暗号鍵Ｋｉを受信するのを待って（ステップＳ１７０４：Ｎｏ）、受信した場合（ステップＳ１７０４：Ｙｅｓ）、設定部６０５により、受信された暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定して（ステップＳ１７０５）、本フローチャートによる一連の処理を終了する。
これにより、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するためのゲートウェイＧｉ固有の暗号鍵Ｋｉを、携帯端末１０２を利用して一時的に確立された通信路を介して管理サーバ１０１から取得して設定することができる。
（ゲートウェイＧｉの鍵通知処理手順）
図１８は、ゲートウェイの鍵通知処理手順の一例を示すフローチャートである。図１８のフローチャートにおいて、まず、ＧＷ受信部９０１により、アドホックネットワークＡｉを介して、ノードＮからブロードキャストされたＧＷ探索フレームを受信したか否かを判断する（ステップＳ１８０１）。
ここで、ＧＷ探索フレームを受信するのを待って（ステップＳ１８０１：Ｎｏ）、受信した場合（ステップＳ１８０１：Ｙｅｓ）、作成部９０２により、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレーム（鍵通知フレーム１０００または１１００）を作成する（ステップＳ１８０２）。
そして、ＧＷ送信部９０３により、ネットワークＮＷ１を介して、作成された鍵通知フレームを管理サーバ１０１に送信して（ステップＳ１８０３）、本フローチャートによる一連の処理を終了する。
これにより、アドホックネットワークＡｉ内のノードＮからのＧＷ探索フレームに応じて、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを管理サーバ１０１に送信することができる。
（管理サーバ１０１の鍵提供処理手順）
つぎに、管理サーバ１０１の鍵提供処理手順について説明する。まず、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持していない場合の鍵提供処理手順について説明する。すなわち、以下に説明する鍵提供処理手順は、ゲートウェイＧｉから管理サーバ１０１に送信される鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉが含まれている場合の処理手順である。
図１９は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その１）である。図１９のフローチャートにおいて、まず、ＳＶ受信部１２０１により、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレームを受信したか否かを判断する（ステップＳ１９０１）。
ここで、鍵通知フレームを受信するのを待って（ステップＳ１９０１：Ｎｏ）、受信した場合（ステップＳ１９０１：Ｙｅｓ）、判断部１２０３により、受信された鍵通知フレームに含まれるノードＩＤと暗号鍵Ｋｉを特定する（ステップＳ１９０２）。そして、判断部１２０３により、特定されたノードＩＤと暗号鍵のペアが送信済リスト１３００に登録されているか否かを判断する（ステップＳ１９０３）。
ここで、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に未登録の場合（ステップＳ１９０３：Ｎｏ）、ＳＶ送信部１２０２により、受信された鍵通知フレームに含まれるユーザＩＤを特定する（ステップＳ１９０４）。つぎに、ＳＶ送信部１２０２により、ネットワークＮＷ２を介して、特定されたユーザＩＤの携帯端末１０２に受信された鍵通知フレームを送信する（ステップＳ１９０５）。
そして、判断部１２０３により、ステップＳ１９０２において特定されたノードＩＤと暗号鍵Ｋｉを関連付けて送信済リスト１３００に登録して（ステップＳ１９０６）、本フローチャートによる一連の処理を終了する。一方、ステップＳ１９０３において、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に登録されている場合（ステップＳ１９０３：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。
これにより、携帯端末１０２を利用して一時的に確立された通信路を介して、ノードＮが属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵ＫｉをノードＮに提供することができる。
つぎに、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持している場合の鍵提供処理手順について説明する。すなわち、以下に説明する鍵提供処理手順は、ゲートウェイＧｉから管理サーバ１０１に送信される鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉが含まれていない場合の処理手順である。
図２０は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その２）である。図２０のフローチャートにおいて、まず、ＳＶ受信部１２０１により、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレームを受信したか否かを判断する（ステップＳ２００１）。
ここで、鍵通知フレームを受信するのを待って（ステップＳ２００１：Ｎｏ）、受信した場合（ステップＳ２００１：Ｙｅｓ）、抽出部１２０４により、受信された鍵通知フレームに含まれるゲートウェイＩＤを特定する（ステップＳ２００２）。つぎに、抽出部１２０４により、暗号鍵ＤＢ１４００の中から、特定されたゲートウェイＩＤと関連付けて記憶されている暗号鍵Ｋｉを抽出する（ステップＳ２００３）。
そして、判断部１２０３により、受信された鍵通知フレームに含まれるノードＩＤを特定する（ステップＳ２００４）。そして、判断部１２０３により、特定されたノードＩＤと抽出された暗号鍵のペアが送信済リスト１３００に登録されているか否かを判断する（ステップＳ２００５）。
ここで、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に未登録の場合（ステップＳ２００５：Ｎｏ）、ＳＶ送信部１２０２により、受信された鍵通知フレームに含まれるユーザＩＤを特定する（ステップＳ２００６）。つぎに、ＳＶ送信部１２０２により、ネットワークＮＷ２を介して、特定されたユーザＩＤの携帯端末１０２に抽出された暗号鍵Ｋｉを送信する（ステップＳ２００７）。
そして、判断部１２０３により、ステップＳ２００４において特定されたノードＩＤとステップＳ２００３において抽出された暗号鍵Ｋｉを関連付けて送信済リスト１３００に登録して（ステップＳ２００８）、本フローチャートによる一連の処理を終了する。
一方、ステップＳ２００５において、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に登録されている場合（ステップＳ２００５：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。これにより、ゲートウェイＧｉから暗号鍵Ｋｉを含む鍵通知フレームを受信する場合に比べて、ゲートウェイＧｉとの通信時におけるデータ量を削減することができる。
以上説明したように、本実施の形態にかかるノードＮによれば、作業員ＯＰの携帯端末１０２を介して、管理サーバ１０１との一時的な通信路を確立することができる。また、ノードＮによれば、携帯端末１０２との接続を契機に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。また、ノードＮによれば、ＧＷ探索フレームがゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された暗号鍵Ｋｉを、携帯端末１０２を介して受信することができる。
これにより、ノードＮの鍵設定時に、ノードＮに設定すべき暗号鍵Ｋｉを容易に取得することができ、ノードＮが用いる暗号鍵Ｋｉの設定作業の効率化を図ることができる。具体的には、例えば、ノードＮの初期導入時などにおいて、作業員ＯＰが地理的に絞り込まれた候補となるゲートウェイとノードＮとの通信状況をしらみつぶしに確認するなどの作業が不要となり、ノードＮに対する暗号鍵Ｋｉの設定作業の効率化を図ることができる。また、確認作業のために候補となる各ゲートウェイの暗号鍵を携帯端末１０２などに記録しておく必要がないため、持ち運びの際の情報漏洩のリスクを低減させることができる。
また、本実施の形態にかかるノードＮによれば、携帯端末１０２からのＧＷ探索フレームの送信指示を契機に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、携帯端末１０２を利用して、ノードＮに対して鍵設定とは異なる設定作業などを行う際に、携帯端末１０２との接続が検知された時点で、ノードＮからＧＷ探索フレームがブロードキャストされることを防ぐことができる。
また、本実施の形態にかかるノードＮによれば、携帯端末１０２の識別子を含むＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、管理サーバ１０１において、複数の携帯端末１０２が通信可能に接続されている場合であっても、鍵通知フレームの送信先となる携帯端末１０２を適切に識別することができる。
また、本実施の形態にかかるノードＮによれば、ノードＮの識別子を含むＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、管理サーバ１０１において、鍵通知フレームを送信済みのノードＮを管理することができ、鍵通知フレームの重複送信を防ぐことができる。
以上のことから、本実施の形態にかかる鍵設定方法、ノード、およびネットワークシステムによれば、アドホックネットワーク内のノードに対する暗号鍵の設定作業にかかる作業員の作業負担の軽減化および作業時間の短縮化を図ることができる。
なお、本実施の形態で説明した鍵設定方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本鍵設定プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本鍵設定プログラムは、インターネット等のネットワークを介して配布してもよい。
１００ ネットワークシステム
１０１ 管理サーバ
１０２ 携帯端末
６０１ 検知部
６０２ 受付部
６０３ フレーム送信部
６０４ 鍵受信部
６０５ 設定部
６０６ フレーム受信部
８００ ＧＷ探索フレーム
９０１ ＧＷ受信部
９０２ 作成部
９０３ ＧＷ送信部
１２０１ ＳＶ受信部
１２０２ ＳＶ送信部
１２０３ 判断部
１２０４ 抽出部
１０００，１１００ 鍵通知フレーム
Ａ１〜Ａｎ，Ａｉ アドホックネットワーク
Ｇ１〜Ｇｎ，Ｇｉ ゲートウェイ
Ｋ１〜Ｋｎ，Ｋｉ 暗号鍵
Ｎ ノード
ＮＷ１，ＮＷ２，ＮＷ３ ネットワーク
本発明は、データを暗号化するための鍵を設定する鍵設定方法、ノード、およびネットワークシステムに関する。
アドホックネットワークは、無線通信でリンクする自己構成型のネットワークの一種である。アドホックネットワークは複数のノードにより構成される。また、アドホックネットワーク内の各ノードは、マルチホップ通信によりパケットの送受信を行う。マルチホップ通信は、互いの通信圏内に存在しないノード同士が、各ノードの通信圏内に存在する別のノードを介して通信を行う技術である。
また、アドホックネットワークとインターネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの他のネットワークとを接続する場合、ゲートウェイと呼ばれる中継機器を用いて、ネットワーク間の通信の転送が行われる。
アドホックネットワークを利用した技術として、各家庭の電力メータに無線通信可能なノードを組み込んで、作業員が現地に出向くことなく、アドホックネットワーク経由でメータ確認などの業務を行うシステムがある。各家庭の電力の使用量などの個人情報を扱うアドホックネットワークでは、秘匿性や改ざん防止の観点からセキュアな通信を行うことが要求される。
そこで、従来のシステムでは、アドホックネットワーク内のノード間で送受信されるパケットを暗号化することで、セキュアな通信を確保することが行われている。この際、システム内の全ノードで共通の暗号鍵を用いた場合、鍵漏洩時のリスクが大きいため、ゲートウェイごとに暗号鍵を変えるシステムがある。
また、システムへの新規ノードの初期導入時などにおいて、新規ノードは、暗号鍵が設定されるまでの間、アドホックネットワーク内の他のノードとセキュアな通信を行うことができない。このため、アドホックネットワーク経由で新規ノードに暗号鍵を自動設定することが難しく、作業員が現地に出向いて暗号鍵の設定作業を行っている。
また、セキュア通信に関する先行技術として、例えば、端末が通信制御を行うのに必要な各種の通信制御情報を端末とは異なる他の通信装置を利用して認証サーバから取得する技術がある（例えば、下記特許文献１参照。）。また、アドホックネットワークにおいて通信開始時の鍵交換を安定して行うための技術がある（例えば、下記特許文献２参照。）。また、各通信端末が最寄りの通信端末と公開鍵を用いて相互認証を行うアドホックネットワークに関する技術がある（例えば、下記特許文献３参照。）。
特開２００６−１３５８７４号公報 特開２００７−８８７９９号公報 特開２００７−１３３８６号公報
しかしながら、上述した従来技術では、アドホックネットワーク内の各ノードに設定する暗号鍵をゲートウェイごとに変える場合、新規ノードの初期導入時などにおいて、新規ノードが属するゲートウェイを特定することが難しいという問題があった。例えば、新規ノードの設置場所の住所から候補となるゲートウェイを絞り込むことはできても、天候や近傍の建物との位置関係などの要因により通信状況が変化する。このため、現地に出向いた作業員が実際にどのゲートウェイと通信可能であるかを確認する必要があり、作業員の暗号鍵の設定作業にかかる作業時間および作業負荷の増大を招くという問題がある。
１つの側面では、本発明は、アドホックネットワーク内のノードが用いる暗号鍵の設定作業の効率化を図ることができる鍵設定方法、ノード、およびネットワークシステムを提供することを目的とする。
本発明の一側面によれば、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードが実行する鍵設定方法であって、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する鍵設定方法が提案される。
また、本発明の一側面によれば、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードであって、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定するノードが提案される。
また、本発明の一側面によれば、複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードと、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと、を含むネットワークシステムであって、前記ノードは、前記サーバと通信可能な携帯端末との接続を検知し、前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報し、同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、前記ゲートウェイから前記サーバに送信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信し、受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定し、前記サーバは、前記取得要求が転送された前記いずれかのアドホックネットワーク内のゲートウェイから、前記ゲートウェイ固有の鍵を受信し、受信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記ノードに送信するネットワークシステムが提案される。
本発明の一態様によれば、アドホックネットワーク内のノードが用いる暗号鍵の設定作業の効率化を図ることができるという効果を奏する。
図１は、実施の形態にかかるネットワークシステムの一実施例を示す説明図である。 図２は、ネットワークシステムへの新規ノードの導入例を示す説明図である。 図３は、新規ノードの導入時におけるネットワークシステムの動作例を示すシーケンス図である。 図４は、実施の形態にかかる管理サーバのハードウェア構成を示すブロック図である。 図５は、実施の形態にかかるノード等のハードウェア構成を示すブロック図である。 図６は、ノードの機能的構成を示すブロック図である。 図７は、ＧＷ探索フレームの送信指示の具体例を示す説明図である。 図８は、ＧＷ探索フレームのデータ構造の一例を示す説明図である。 図９は、ゲートウェイの機能的構成を示すブロック図である。 図１０は、鍵通知フレームの具体例を示す説明図（その１）である。 図１１は、鍵通知フレームの具体例を示す説明図（その２）である。 図１２は、管理サーバの機能的構成を示すブロック図である。 図１３は、送信済リストの具体例を示す説明図である。 図１４は、暗号鍵ＤＢの記憶内容の一例を示す説明図である。 図１５は、管理サーバの認証情報の一例を示す説明図である。 図１６は、携帯端末の認証情報の一例を示す説明図である。 図１７は、ノードの鍵設定処理手順の一例を示すフローチャートである。 図１８は、ゲートウェイの鍵通知処理手順の一例を示すフローチャートである。 図１９は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その１）である。 図２０は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その２）である。
以下に添付図面を参照して、この発明にかかる鍵設定方法、ノード、およびネットワークシステムの好適な実施の形態を詳細に説明する。
（ネットワークシステムの一実施例）
図１は、実施の形態にかかるネットワークシステムの一実施例を示す説明図である。図１において、ネットワークシステム１００は、管理サーバ１０１と、ゲートウェイＧ１〜Ｇｎと、ノードＮ１−１〜Ｎ１−ｍ１，Ｎ２−１〜Ｎ２−ｍ２，…，Ｎｎ−１〜Ｎｎ−ｍｎと、を含む構成である。
管理サーバ１０１は、インターネット、ＬＡＮ、ＷＡＮなどのネットワークＮＷ１を介して、ゲートウェイＧ１〜Ｇｎと相互に通信可能に接続されている。管理サーバ１０１は、各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵を、各ゲートウェイＧ１〜Ｇｎから取得して保持するコンピュータである。
各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵（以下、「暗号鍵Ｋ１〜Ｋｎ」という）は、各ゲートウェイＧ１〜Ｇｎが属する各アドホックネットワークＡ１〜Ａｎ内のノード間で送受信されるデータを暗号化するための鍵情報である。以下の説明では、データの一例として、データ本体を含むペイロード部に宛先などを含むヘッダ部が付加されたパケットを用いて説明する。
また、管理サーバ１０１は、携帯電話網やインターネットなどのネットワークＮＷ２を介して、携帯端末１０２と相互に通信可能である。携帯端末１０２は、作業員ＯＰが使用する携帯型の通信装置であり、例えば、携帯電話機、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）電話機、スマートフォン、ノート型のパーソナル・コンピュータなどである。
ゲートウェイＧｉは、アドホックネットワークＡｉとネットワークＮＷ１とを接続する中継機器である（ｉ＝１，２，…，ｎ）。具体的には、ゲートウェイＧｉは、アドホックネットワークＡｉを介して、ノードＮｉ−１〜Ｎｉ−ｍｉと接続されている。また、ゲートウェイＧｉは、ネットワークＮＷ１を介して、管理サーバ１０１と接続されている。
ゲートウェイＧｉは、アドホックネットワークＡｉのプロトコルとネットワークＮＷ１のプロトコルの両方を理解し、アドホックネットワークＡｉとネットワークＮＷ１との間の通信の転送を行う。ゲートウェイＧｉは、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するためのゲートウェイＧｉ固有の暗号鍵Ｋｉを有している。
ノードＮｉ−１〜Ｎｉ−ｍｉは、所定の通信圏内の他ノードとマルチホップ通信を行う無線通信装置である。アドホックネットワークＡｉでは、すべてのノードＮｉ−１〜Ｎｉ−ｍｉがゲートウェイＧｉと直接通信できる必要はなく、一部のノードがゲートウェイＧｉと通信可能であればよい。
ネットワークシステム１００は、例えば、各家庭の電力やガスの使用量を収集するシステムに適用することができる。具体的には、例えば、各家庭の電力メータやガスメータに各ノードＮｉ−１〜Ｎｉ−ｍｉを組み込むことで、アドホックネットワークＡｉ内のノード間で各家庭の電力やガスの使用量を送受信する。なお、各家庭の電力やガスの使用量は、各ノードＮｉ−１〜Ｎｉ−ｍｉが計測してもよく、また、各ノードＮｉ−１〜Ｎｉ−ｍｉが電力メータやガスメータから取得してもよい。
ゲートウェイＧｉは、アドホックネットワークＡｉ内のノードＮｉ−１〜Ｎｉ−ｍｉから受信した各家庭の電力やガスの使用量を、ネットワークＮＷ１を介して電力会社やガス会社のサーバ（例えば、管理サーバ１０１）に送信する。これにより、作業員が現地に出向くことなく電力やガスの使用量を収集することができる。
また、ネットワークシステム１００では、アドホックネットワークＡｉごとにゲートウェイＧｉ固有の暗号鍵Ｋｉを用いてパケットを暗号化する。これにより、アドホックネットワークＡｉのセキュア通信（データ秘匿性、改ざん防止など）を確保する。また、アドホックネットワークＡｉごとに暗号鍵Ｋｉを変えることで、鍵漏洩時のリスクを低減させる。
なお、図１の例では、アドホックネットワークＡｉ内に１台のゲートウェイＧｉを設ける構成としたが、同一のアドホックネットワークＡｉ内に複数台のゲートウェイＧｉを設ける構成としてもよい。この場合、アドホックネットワークＡｉ内で送受信されるパケットを暗号化するための暗号鍵Ｋｉは、複数台のゲートウェイＧｉで共通である。
（新規ノードＮの導入時における暗号鍵Ｋｉの設定例）
つぎに、図１に示したネットワークシステム１００への新規ノードＮの導入時における暗号鍵Ｋｉの設定例について説明する。
図２は、ネットワークシステムへの新規ノードの導入例を示す説明図である。図２において、ネットワークシステム１００のアドホックネットワークＡｉ内に新規ノードＮが導入されている。なお、図２では、アドホックネットワークＡｉ内のノードＮｉ−１〜Ｎｉ−ｍｉのうち、代表としてノードＮｉ−１〜Ｎｉ−３を示している。
新規ノードＮの導入時は、作業員ＯＰは新規ノードＮがどのアドホックネットワークＡｉに属しているのかわからない。そこで、本実施の形態では、作業員ＯＰが使用する携帯端末１０２を利用して、新規ノードＮに設定すべき暗号鍵Ｋｉを管理サーバ１０１から取得して新規ノードＮに自動設定する。以下、図２に示した新規ノードＮの導入時におけるネットワークシステム１００の動作例について説明する。
図３は、新規ノードの導入時におけるネットワークシステムの動作例を示すシーケンス図である。図３のシーケンスにおいて、（１）携帯端末１０２は、ネットワークＮＷ２を介して管理サーバ１０１に接続する。この際、携帯端末１０２は、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）を用いて、管理サーバ１０１とセキュアな通信を行う。なお、管理サーバ１０１と携帯端末１０２との間でセキュア通信を実現するための通信方式については、図１５および図１６を用いて後述する。
（２）携帯端末１０２は、有線または無線のネットワークＮＷ３を介して新規ノードＮに接続する。具体的には、例えば、作業員ＯＰが、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブルを用いて、携帯端末１０２と新規ノードＮとを接続することで、携帯端末１０２と新規ノードＮとの間にネットワークＮＷ３が確立される。
（３）新規ノードＮは、携帯端末１０２との接続を検知すると、アドホックネットワークＡｉ内でマルチホップ通信により送受信されるパケットを暗号化するための鍵の取得要求をアドホックネットワークＡｉにブロードキャストする。ここでは、鍵の取得要求が、新規ノードＮの通信圏内に存在するノードＮｉ−３に送信される。
（４）ノードＮｉ−３は、新規ノードＮからの鍵の取得要求を通信圏内のノードＮｉ−１に送信する。（５）ノードＮｉ−１は、ノードＮｉ−３からの鍵の取得要求を通信圏内のゲートウェイＧｉに送信する。この結果、新規ノードＮからの鍵の取得要求がアドホックネットワークＡｉ内のゲートウェイＧｉに転送される。
（６）ゲートウェイＧｉは、新規ノードＮからの鍵の取得要求を受信すると、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。（７）管理サーバ１０１は、ネットワークＮＷ２を介して、ゲートウェイＧｉからのゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２に送信する。
（８）携帯端末１０２は、ネットワークＮＷ３を介して、管理サーバ１０１からのゲートウェイＧｉ固有の暗号鍵Ｋｉを新規ノードＮに送信する。（９）新規ノードＮは、携帯端末１０２からの暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定する。
なお、携帯端末１０２と新規ノードＮとの接続は、新規ノードＮに対する暗号鍵Ｋｉの設定が終了するまで維持する。また、暗号鍵Ｋｉの設定が終了して携帯端末１０２と新規ノードＮとの接続を切断すると、携帯端末１０２の中から暗号鍵Ｋｉが自動で削除されるようにしてもよい。これにより、携帯端末１０２の紛失時などにおけるリスクを低減させることができる。
このように、本実施の形態にかかるネットワークシステム１００によれば、新規ノードＮの導入時に、作業員ＯＰの携帯端末１０２を介して、新規ノードＮと管理サーバ１０１との一時的な通信路を確立することができる。また、新規ノードＮからブロードキャストされた鍵の取得要求がゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された暗号鍵Ｋｉを、携帯端末１０２を介して管理サーバ１０１から新規ノードＮに提供することができる。これにより、新規ノードＮに設定すべき暗号鍵Ｋｉを容易に取得することができ、新規ノードＮが用いる暗号鍵Ｋｉの設定作業の効率化を図ることができる。
なお、以下の説明において、「ノードＮ」とは、ネットワークシステム１００のアドホックネットワークＡ１〜ＡｎのいずれかのアドホックネットワークＡｉ内でマルチホップ通信によりパケットを送受信するノードを示す。また、「ノード等」とは、ネットワークシステム１００のゲートウェイＧ１〜ＧｎおよびノードＮを示す。
（管理サーバ１０１のハードウェア構成）
図４は、実施の形態にかかる管理サーバのハードウェア構成を示すブロック図である。図４において、管理サーバ１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１と、ＲＯＭ（Ｒｅａｄ‐Ｏｎｌｙ Ｍｅｍｏｒｙ）４０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０３と、磁気ディスクドライブ４０４と、磁気ディスク４０５と、光ディスクドライブ４０６と、光ディスク４０７と、Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０８と、ディスプレイ４０９と、キーボード４１０と、マウス４１１と、を備えている。また、ＣＰＵ４０１〜マウス４１１はバス４００によってそれぞれ接続されている。
ここで、ＣＰＵ４０１は、管理サーバ１０１の全体の制御を司る。ＲＯＭ４０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ４０３は、ＣＰＵ４０１のワークエリアとして使用される。磁気ディスクドライブ４０４は、ＣＰＵ４０１の制御に従って磁気ディスク４０５に対するデータのリード／ライトを制御する。磁気ディスク４０５は、磁気ディスクドライブ４０４の制御で書き込まれたデータを記憶する。
光ディスクドライブ４０６は、ＣＰＵ４０１の制御に従って光ディスク４０７に対するデータのリード／ライトを制御する。光ディスク４０７は、光ディスクドライブ４０６の制御で書き込まれたデータを記憶したり、光ディスク４０７に記憶されたデータをコンピュータに読み取らせたりする。
Ｉ／Ｆ４０８は、通信回線を通じてネットワークＮＷ１，ＮＷ２に接続され、このネットワークＮＷ１，ＮＷ２を介して他の装置（例えば、ゲートウェイＧｉ、携帯端末１０２）に接続される。Ｉ／Ｆ４０８は、ネットワークＮＷ１，ＮＷ２と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ４０８には、例えば、モデムやＬＡＮアダプタなどを採用することができる。
ディスプレイ４０９は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ４０９は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。
キーボード４１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス４１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などを行う。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。なお、図２に示した携帯端末１０２についても、図４に示した管理サーバ１０１と同様のハードウェア構成により実現できる。
（ノード等のハードウェア構成）
図５は、実施の形態にかかるノード等のハードウェア構成を示すブロック図である。図５において、ノード等は、ＣＰＵ５０１と、ＲＡＭ５０２と、フラッシュメモリ５０３と、Ｉ／Ｆ５０４と、暗号化回路５０５と、を備えている。ＣＰＵ５０１〜暗号化回路５０５は、バス５００によってそれぞれ接続されている。
ここで、ＣＰＵ５０１は、ノード等の全体の制御を司る。ＲＡＭ５０２は、ＣＰＵ５０１のワークエリアとして使用される。フラッシュメモリ５０３は、プログラムや暗号鍵などの鍵情報を記憶している。Ｉ／Ｆ５０４は、マルチホップ通信によりパケットを送受信する。また、ゲートウェイＧｉのＩ／Ｆ５０４は、通信回線を通じてネットワークＮＷ１に接続され、このネットワークＮＷ１を介して管理サーバ１０１に接続される。
暗号化回路５０５は、データを暗号化する場合に暗号鍵によりデータを暗号化する回路である。暗号化をソフトウェア的に実行する場合は、暗号化回路５０５に相当するプログラムをフラッシュメモリ５０３に記憶させておくことで、暗号化回路５０５は不要となる。
（ノードＮの機能的構成）
図６は、ノードの機能的構成を示すブロック図である。図６において、ノードＮは、検知部６０１と、受付部６０２と、フレーム送信部６０３と、鍵受信部６０４と、設定部６０５と、フレーム受信部６０６と、を含む構成である。各機能部（検知部６０１〜フレーム受信部６０６）は、具体的には、例えば、図５に示したＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０４により、その機能を実現する。また、各機能部（検知部６０１〜フレーム受信部６０６）の処理結果は、特に指定する場合を除いて、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶される。
検知部６０１は、管理サーバ１０１と通信可能な携帯端末１０２との接続を検知する。具体的には、例えば、作業員ＯＰがＵＳＢケーブルを用いて携帯端末１０２とノードＮとを接続した結果、検知部６０１が、ＵＳＢケーブルを介した携帯端末１０２との接続を検知する。
受付部６０２は、検知部６０１によって接続が検知された携帯端末１０２から、鍵の取得要求の送信指示を受け付ける。ここで、鍵の取得要求は、アドホックネットワークＡｉ内でマルチホップ通信によりノード間で送受信されるパケットを暗号化するための暗号鍵Ｋｉの取得要求である。
鍵の取得要求は、例えば、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉを探索して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを提供してもらうためのものである。そこで、以下の説明では、「鍵の取得要求」を、鍵の提供元となるゲートウェイＧｉを探索するための「ＧＷ探索フレーム」と称する。
具体的には、例えば、受付部６０２が、ＵＳＢケーブルなどのネットワークＮＷ３を介して、携帯端末１０２からＧＷ探索フレームの送信指示を受け付ける。ここで、ＧＷ探索フレームの送信指示の具体例について説明する。
図７は、ＧＷ探索フレームの送信指示の具体例を示す説明図である。図７において、送信指示７００は、コマンドおよびユーザＩＤを有している。コマンドは、ノードＮに対する指示内容を示している。ここでは、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉの探索指示を表す『ｓｅａｒｃｈ ｇｗ』が記述されている。ユーザＩＤは、携帯端末１０２の識別子である。ここでは、『Ｄ１』が記述されている。
図６の説明に戻り、フレーム送信部６０３は、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする。ＧＷ探索フレームは、例えば、フレームの種別、携帯端末１０２の識別子、ノードＮの識別子を含む情報であり、暗号化されていないノーマルフレームである。
ここで、携帯端末１０２の識別子は、例えば、上記受付部６０２によって受け付けたＧＷ探索フレームの送信指示から特定される。また、ノードＮの識別子は、例えば、予め設定されてＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されている。具体的には、例えば、フレーム送信部６０３が、携帯端末１０２との接続が検知された場合に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。
また、フレーム送信部６０３は、例えば、携帯端末１０２からＧＷ探索フレームの送信指示を受け付けた場合に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。すなわち、携帯端末１０２との接続が検知され、かつ、ＧＷ探索フレームの送信指示を受け付けた場合に、フレーム送信部６０３が、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする。
これにより、携帯端末１０２を利用して、ノードＮに対して鍵設定とは異なる設定作業などを行う際に、携帯端末１０２との接続が検知された時点で、ノードＮからＧＷ探索フレームがブロードキャストされることを防ぐことができる。ここで、ＧＷ探索フレームの具体例について説明する。
図８は、ＧＷ探索フレームのデータ構造の一例を示す説明図である。図８において、ＧＷ探索フレーム８００は、ヘッダ部８１０とペイロード部８２０とを含む構成である。ヘッダ部８１０には、宛先アドレス、差出アドレス、種別、サイズおよびホップ数が記述されている。ペイロード部８２０には、ユーザＩＤおよびノードＩＤが記述されている。
ここで、宛先アドレスは、送信先のアドレスである。ここでは、ブロードキャスト用のＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレス『ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ：ＦＦ』が記述されている。差出アドレスは、送信元のアドレスである。ここでは、アドホックネットワークＡ１内のノードＮとは異なる他のノードＮのＭＡＣアドレスが記述されている。種別は、フレームの種別である。ここでは、ＧＷ探索フレームを示す『２』が記述されている。サイズは、フレームのデータサイズ（バイト）である。
ホップ数は、ノード間でＧＷ探索フレーム８００を残り何回転送するのかを示す残余の転送回数である。ノードＮからブロードキャストされるＧＷ探索フレーム８００のホップ数の最大値は予め設定されている。ホップ数はＧＷ探索フレーム８００の転送時にデクリメントされ、ホップ数が『０』となったＧＷ探索フレーム８００は棄却される。ここでは、ＧＷ探索フレーム８００のホップ数『１０』が記述されている。
ユーザＩＤは、ノードＮに接続されている携帯端末１０２の識別子である。ここでは、ユーザＩＤ『Ｄ１』が記述されている。ノードＩＤは、ノードＮの識別子である。ここでは、ノードＩＤ『Ｎ１−ｘ』が記述されている。なお、ここでは宛先アドレスおよび差出アドレスの一例として、ＭＡＣアドレスを用いて説明したが、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスなどのアドレスを用いることにしてもよい。
図６の説明に戻り、鍵受信部６０４は、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵Ｋｉを、携帯端末１０２を介して管理サーバ１０１から受信する。ここで、ゲートウェイＧｉ固有の暗号鍵Ｋｉは、ブロードキャストされたＧＷ探索フレームがゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された鍵である。
この暗号鍵Ｋｉは、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するための鍵であり、例えば、１２８〜２５６ビット程度のバイナリデータである。また、この暗号鍵Ｋｉは、例えば、パケットを暗号化するとともに、暗号鍵Ｋｉを用いて暗号化されたパケットを復号することができる共通鍵である。
具体的には、例えば、ノードＮからブロードキャストされたＧＷ探索フレームは、アドホックネットワークＡｉを介してゲートウェイＧｉに転送される。この結果、ゲートウェイＧｉは、ネットワークＮＷ１を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。つぎに、管理サーバ１０１は、ネットワークＮＷ２を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２に送信する。そして、鍵受信部６０４が、ネットワークＮＷ３を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２から受信する。
設定部６０５は、受信されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定する。これにより、以降においてノードＮが送信対象となるパケットを暗号化、および暗号化されたパケットを復号することが可能となり、アドホックネットワークＡｉ内のノード間でセキュア通信を行うことができる。
フレーム受信部６０６は、アドホックネットワークＡｉ内の自ノードとは異なる他ノードからＧＷ探索フレームを受信する。すなわち、アドホックネットワークＡｉ内の他ノードでの鍵設定のために、他ノードからブロードキャストされたＧＷ探索フレームをフレーム受信部６０６が受信する。
この場合、ノードＮは、受信された他ノードからのＧＷ探索フレームを別ノードに転送する。ただし、アドホックネットワークＡｉでは、安全性の観点から、各ノードＮは、暗号化されていないノーマルフレームを受信した場合、該ノーマルフレームを破棄するように設定されている場合がある。
そこで、フレーム送信部６０３は、受信されたノーマルフレームの種別がＧＷ探索フレームを示す『２』の場合、該ノーマルフレームをアドホックネットワークＡｉにブロードキャストすることにしてもよい。これにより、アドホックネットワークＡｉ内の自ノードとは異なる他ノードからのＧＷ探索フレームを別ノードに転送することができる。
（ゲートウェイＧｉの機能的構成）
図９は、ゲートウェイの機能的構成を示すブロック図である。図９において、ゲートウェイＧｉは、ＧＷ受信部９０１と、作成部９０２と、ＧＷ送信部９０３と、を含む構成である。各機能部（ＧＷ受信部９０１〜ＧＷ送信部９０３）は、具体的には、例えば、図５に示したＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されたプログラムをＣＰＵ５０１に実行させることにより、または、Ｉ／Ｆ５０４により、その機能を実現する。また、各機能部（ＧＷ受信部９０１〜ＧＷ送信部９０３）の処理結果は、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶される。
ＧＷ受信部９０１は、アドホックネットワークＡｉを介して、ノードＮからブロードキャストされたＧＷ探索フレームを受信する。具体的には、例えば、ＧＷ受信部９０１が、アドホックネットワークＡｉ内のノードＮとは異なる他ノードからＧＷ探索フレームを直接受信する。
作成部９０２は、ＧＷ探索フレームが受信された場合、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを作成する。ここで、鍵通知フレームは、例えば、携帯端末１０２の識別子、ノードＮの識別子、ゲートウェイＧｉの識別子およびゲートウェイＧｉ固有の暗号鍵Ｋｉを含む情報である。
携帯端末１０２の識別子およびノードＮの識別子は、受信されたＧＷ探索フレームから特定される。また、ゲートウェイＧｉ固有の暗号鍵Ｋｉは、例えば、ＲＡＭ５０２、フラッシュメモリ５０３などの記憶装置に記憶されている。具体的には、例えば、作成部９０２が、受信されたＧＷ探索フレーム８００に基づいて、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを作成する。ここで、鍵通知フレームの具体例について説明する。
図１０は、鍵通知フレームの具体例を示す説明図（その１）である。図１０において、鍵通知フレーム１０００は、ユーザＩＤ、ノードＩＤ、ゲートウェイＩＤおよび暗号鍵に関する情報を有している。ここで、ユーザＩＤは、携帯端末１０２の識別子である。このユーザＩＤは、図８に示したＧＷ探索フレーム８００のペイロード部８２０から特定されたものである。ノードＩＤは、ノードＮの識別子である。このノードＩＤは、ＧＷ探索フレーム８００のペイロード部８２０から特定されたものである。ゲートウェイＩＤは、ゲートウェイＧｉの識別子である。暗号鍵は、ゲートウェイＧｉ固有の暗号鍵Ｋｉである。
図９の説明に戻り、ＧＷ送信部９０３は、ネットワークＮＷ１を介して、ゲートウェイＧｉ固有の暗号鍵Ｋｉを管理サーバ１０１に送信する。具体的には、例えば、ＧＷ送信部９０３が、作成された鍵通知フレーム１０００を管理サーバ１０１に送信することにしてもよい。これにより、単にゲートウェイＧｉ固有の暗号鍵Ｋｉのみを送信する場合に比べて、管理サーバ１０１において、暗号鍵Ｋｉの提供先となる携帯端末１０２やノードＮを識別することができる。
また、詳細は後述するが、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する構成とした場合、鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉを含む必要がない。そこで、上記作成部９０２は、例えば、図１１に示すようなゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレーム１１００を作成することにしてもよい。
図１１は、鍵通知フレームの具体例を示す説明図（その２）である。図１１において、鍵通知フレーム１１００は、ユーザＩＤ、ノードＩＤおよびゲートウェイＩＤに関する情報を有している。すなわち、鍵通知フレーム１１００は、図１０に示した鍵通知フレーム１０００の中からゲートウェイＧ１固有の暗号鍵Ｋ１を削除したものである。
管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する構成とした場合、上記ＧＷ送信部９０３は、例えば、ゲートウェイＧ１固有の暗号鍵Ｋ１を含まない鍵通知フレーム１１００を管理サーバ１０１に送信する。
（管理サーバ１０１の機能的構成）
図１２は、管理サーバの機能的構成を示すブロック図である。図１２において、管理サーバ１０１は、ＳＶ受信部１２０１と、ＳＶ送信部１２０２と、判断部１２０３と、抽出部１２０４と、を含む構成である。各機能部（ＳＶ受信部１２０１〜抽出部１２０４）は、具体的には、例えば、図４に示したＲＯＭ４０２、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶されたプログラムをＣＰＵ４０１に実行させることにより、または、Ｉ／Ｆ４０８により、その機能を実現する。また、各機能部（ＳＶ受信部１２０１〜抽出部１２０４）の処理結果は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶される。
ＳＶ受信部１２０１は、ネットワークＮＷ１を介して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを受信する。具体的には、例えば、ＳＶ受信部１２０１が、ネットワークＮＷ１を介して、図１０に示した鍵通知フレーム１０００を受信する。鍵通知フレーム１０００は、携帯端末１０２に対するゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求である。
ＳＶ送信部１２０２は、受信されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、ネットワークＮＷ２を介して携帯端末１０２に送信する。具体的には、例えば、ＳＶ送信部１２０２が、受信された鍵通知フレーム１０００を、ネットワークＮＷ２を介して携帯端末１０２に送信する。この結果、携帯端末１０２が、鍵通知フレーム１０００に含まれる暗号鍵Ｋ１を、ネットワークＮＷ３を介してノードＮに送信することになる。
ここで、管理サーバ１０１は、ネットワークＮＷ２を介して、複数の携帯端末１０２と通信可能に接続されている場合がある。この場合、ＳＶ送信部１２０２は、例えば、鍵通知フレーム１０００に含まれるユーザＩＤから送信先の携帯端末１０２を識別することができる。鍵通知フレーム１０００の例では、ＳＶ送信部１２０２は、ユーザＩＤ『Ｄ１』の携帯端末１０２に鍵通知フレーム１０００を送信する。
また、アドホックネットワークＡｉ内のノードＮからゲートウェイＧｉに辿り着くまでの経路は複数存在する場合がある。この場合、ノードＮからブロードキャストされたＧＷ探索フレームは、複数の経路を辿ってゲートウェイＧｉに到達する。その結果、ゲートウェイＧｉは、ノードＮからブロードキャストされたＧＷ探索フレームを複数回受信することになる。
この場合、ゲートウェイＧｉは、ＧＷ探索フレームを受信する都度、鍵通知フレームを作成して管理サーバ１０１に送信することになる。そして、管理サーバ１０１は、鍵通知フレームを受信する都度、その鍵通知フレームを携帯端末１０２に送信することになる。この結果、携帯端末１０２は、管理サーバ１０１から同一の鍵通知フレームを複数回受信することになる。
これでは、作業員ＯＰが同一の携帯端末１０２を用いて、複数のノードＮの鍵設定を連続して行う場合に、誤った暗号鍵ＫｉをノードＮに設定してしまう可能性がある。例えば、アドホックネットワークＡ１内のノードＮ１−ｘとアドホックネットワークＡ２内のノードＮ２−ｘの鍵設定を連続して行う場合を想定する。このとき、ノードＮ１−ｘへの暗号鍵Ｋ１の設定が終了し、作業員ＯＰが携帯端末１０２をノードＮ２−ｘに接続したあと、管理サーバ１０１から暗号鍵Ｋ１を含む鍵通知フレームを受信した場合、ノードＮ２−ｘに暗号鍵Ｋ１を誤って設定してしまう。
そこで、管理サーバ１０１において、暗号鍵Ｋｉ（鍵通知フレーム）を送信済みのノードＮを管理することで、同一の鍵通知フレームを重複して携帯端末１０２に送信することを防ぐことができる。ここで、鍵通知フレームを送信済みのノードＮを管理するための送信済リストの具体例について説明する。
図１３は、送信済リストの具体例を示す説明図である。図１３において、送信済リスト１３００は、暗号鍵Ｋｉを送信済みのノードＮのノードＩＤと、送信済みの暗号鍵Ｋｉとを関連付けて記憶している。送信済リスト１３００は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置により実現される。
図１３の例では、アドホックネットワークＡ１内のノードＮ１−１のノードＩＤ『Ｎ１−１』と、ノードＮ１−１に送信された『暗号鍵Ｋ１』とが関連付けて記憶されている。また、アドホックネットワークＡ１内のノードＮ１−２のノードＩＤ『Ｎ１−２』と、ノードＮ１−２に送信された『暗号鍵Ｋ１』とが関連付けて記憶されている。
図１２の説明に戻り、判断部１２０３は、暗号鍵Ｋｉを送信済みのノードＮを管理する送信済リストを参照することにより、携帯端末１０２に鍵通知フレームを送信するか否かを判断する。具体的には、例えば、判断部１２０３が、送信済リスト１３００を参照して、鍵通知フレームに含まれるノードＩＤが登録済みか否かを判断する。
ここで、鍵通知フレームに含まれるノードＩＤが登録済みの場合、判断部１２０３が、携帯端末１０２に鍵通知フレームを送信しないと判断する。この場合、ＳＶ送信部１２０２による鍵通知フレームの送信処理は行われない。一方、鍵通知フレームに含まれるノードＩＤが未登録の場合、判断部１２０３が、携帯端末１０２に鍵通知フレームを送信すると判断する。
そして、ＳＶ送信部１２０２が、携帯端末１０２に鍵通知フレームを送信する。鍵通知フレームが携帯端末１０２に送信されると、例えば、鍵通知フレームに含まれているノードＩＤおよび暗号鍵Ｋｉが送信済リスト１３００に登録される。鍵通知フレーム１０００の例では、ノードＩＤ『Ｎ１−ｘ』と暗号鍵『Ｋ１』とが関連付けられて送信済リスト１３００に登録される。
これにより、同一の鍵通知フレームを重複して携帯端末１０２に送信することを防ぐことができる。さらに、暗号鍵Ｋｉを送信済みのノードＮを管理することで、複数の異なるアドホックネットワークの境界付近にノードＮが設置された場合などに、複数の異なる暗号鍵がノードＮに送信されることを防ぐことができる。
具体的には、例えば、ノードＮの設置場所がアドホックネットワークＡ１，Ａ２の境界付近の場合、ノードＮからブロードキャストされたＧＷ探索フレームがゲートウェイＧ１，Ｇ２に転送される可能性がある。この場合、管理サーバ１０１は、ゲートウェイＧ１，Ｇ２から鍵通知フレームを受信し、それら鍵通知フレームを携帯端末１０２に送信することになる。この結果、複数の異なる暗号鍵Ｋ１，Ｋ２がノードＮに送信されてしまう。そこで、暗号鍵Ｋｉを送信済みのノードＮを管理して鍵通知フレームの重複送信を防ぐことで、複数の異なる暗号鍵がノードＮに送信されることを防ぐ。
また、判断部１２０３は、送信済リスト１３００を参照して、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが登録済みか否かを判断することにしてもよい。そして、判断部１２０３は、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが登録済みの場合、携帯端末１０２に鍵通知フレームを送信しないと判断する。
一方、判断部１２０３は、鍵通知フレームに含まれるノードＩＤと暗号鍵のペアが未登録、または、ノードＩＤと暗号鍵のいずれかが登録済みの場合、携帯端末１０２に鍵通知フレームを送信すると判断する。すなわち、判断部１２０３は、鍵通知フレームに含まれるノードＩＤが登録済みでも暗号鍵が未登録の場合、携帯端末１０２に鍵通知フレームを送信すると判断する。これにより、例えば、アドホックネットワークＡ１内のノードＮに暗号鍵Ｋ１を設定したあと、該ノードＮを他のアドホックネットワークＡ２に属する別の場所に移動させて使用する場合に、ノードＮに設定すべき新たな暗号鍵Ｋ２を提供することができる。
なお、管理サーバ１０１は、ＳＶ送信部１２０２による鍵通知フレームの携帯端末１０２への送信後において、携帯端末１０２との接続が切断された場合、ゲートウェイＧｉから受信した鍵通知フレームを削除することにしてもよい。
また、上述した説明では、各ゲートウェイＧｉ固有の暗号鍵Ｋｉを含む鍵通知フレームをゲートウェイＧｉから管理サーバ１０１に送信する場合について説明したが、これに限らない。例えば、管理サーバ１０１において、ネットワークシステム１００内の各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを予め保持しておく構成としてもよい。ここで、各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する暗号鍵ＤＢ（データベース）の具体例について説明する。
図１４は、暗号鍵ＤＢの記憶内容の一例を示す説明図である。図１４において、暗号鍵ＤＢ１４００は、ゲートウェイＩＤおよび暗号鍵のフィールドを有し、各フィールドに情報を設定することで、ゲートウェイＧ１〜Ｇｎごとの鍵情報１４００−１〜１４００−ｎをレコードとして記憶している。
ここで、ゲートウェイＩＤは、ゲートウェイＧｉの識別子である。暗号鍵は、ゲートウェイＧｉ固有の暗号鍵Ｋｉである。鍵情報１４００−１を例に挙げると、ゲートウェイＧ１固有の暗号鍵Ｋ１が記憶されている。なお、暗号鍵ＤＢ１４００は、例えば、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置により実現される。
このように、管理サーバ１０１がゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持する場合、ＳＶ受信部１２０１は、ネットワークＮＷ１を介して、ゲートウェイＧｉからゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレームを受信する。具体的には、例えば、ＳＶ受信部１２０１が、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレーム１１００を受信する。
また、抽出部１２０４は、ゲートウェイＧｉ固有の暗号鍵Ｋｉを含まない鍵通知フレームが受信された場合、暗号鍵ＤＢ１４００の中からゲートウェイＧｉ固有の暗号鍵Ｋｉを抽出する。具体的には、例えば、抽出部１２０４が、暗号鍵ＤＢ１４００の中から、受信された鍵通知フレーム１１００に含まれるゲートウェイＩＤ『Ｇ１』と関連付けて記憶されている暗号鍵Ｋ１を抽出する。
そして、ＳＶ送信部１２０２は、抽出されたゲートウェイＧｉ固有の暗号鍵Ｋｉを、ネットワークＮＷ２を介して携帯端末１０２に送信する。このように、ゲートウェイＧｉから暗号鍵Ｋｉを含まない鍵通知フレームを送信することで、暗号鍵Ｋｉを含む鍵通知フレームを送信する場合に比べて、ゲートウェイＧｉと管理サーバ１０１との間の通信時におけるデータ量を削減することができる。
また、管理サーバ１０１への鍵通知フレームの初回送信時のみ、ゲートウェイＧｉに暗号鍵Ｋｉを含む鍵通知フレームを送信させて、それ以降は、暗号鍵Ｋｉを含まない鍵通知フレームを送信させることにしてもよい。この場合、管理サーバ１０１は、鍵通知フレームの初回受信時に、鍵通知フレームに含まれる暗号鍵ＫｉをゲートウェイＩＤと関連付けて暗号鍵ＤＢ１４００に登録することにしてもよい。これにより、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを予め保持しておく必要がなくなる。
なお、ゲートウェイＧｉが暗号鍵Ｋｉを含む鍵通知フレームを管理サーバ１０１に送信する場合は、暗号鍵Ｋｉの抽出処理が不要となるため、管理サーバ１０１は上記抽出部１２０４および暗号鍵ＤＢ１４００を備えない構成としてもよい。
（管理サーバ１０１と携帯端末１０２との間の通信方式）
ここで、管理サーバ１０１と携帯端末１０２との間の通信方式の一実施例について説明する。まず、携帯端末１０２からみた管理サーバ１０１のサーバ認証について説明する。具体的には、例えば、まず、携帯端末１０２が、予め決められたＩＰアドレスを用いて管理サーバ１０１に接続する。
そして、携帯端末１０２が、管理サーバ１０１からＳＳＬサーバ証明書を受信する。受信されたＳＳＬサーバ証明書は、例えば、図１５に示すように管理サーバ１０１のＩＰアドレスと関連付けて携帯端末１０２の記憶装置に記憶される。
図１５は、管理サーバの認証情報の一例を示す説明図である。図１５において、管理サーバ１０１の認証情報１５００は、ＩＰアドレスおよびＳＳＬサーバ証明書を有する。ＩＰアドレスは、管理サーバ１０１のＩＰアドレスである。Ｘ．５０９証明書は、管理サーバ１０１のＳＳＬサーバ証明書（公開鍵証明書）である。
携帯端末１０２は、予め自端末に組み込まれている公開鍵を用いて、ＳＳＬサーバ証明書を復号することでサーバ認証を行う。公開鍵は、例えば、第三者認証機関によって発行されたものである。この公開鍵を用いてＳＳＬサーバ証明書を正しく復号できれば、ＳＳＬサーバ証明書が第三者認証機関によって証明された正しい証明書であることがわかり、ひいては管理サーバ１０１の身元が保証されたことになる。
つぎに、管理サーバ１０１からみた携帯端末１０２のユーザ認証について説明する。ここでは、図１６に示すような携帯端末１０２の認証情報１６００を用いて、携帯端末１０２のユーザ認証を行う場合を例に挙げて説明する。認証情報１６００は、例えば、管理サーバ１０１のＲＯＭ４０２、ＲＡＭ４０３、磁気ディスク４０５、光ディスク４０７などの記憶装置に記憶されている。
図１６は、携帯端末の認証情報の一例を示す説明図である。図１６において、携帯端末１０２の認証情報１６００は、ユーザＩＤおよびパスワードを有する。ユーザＩＤは、携帯端末１０２の識別子である。パスワードは、携帯端末１０２を使用するユーザを認証するためのものである。
具体的には、例えば、まず、携帯端末１０２が、ユーザＩＤおよびパスワードのペアを管理サーバ１０１に送信する。このユーザＩＤおよびパスワードは、携帯端末１０２の記憶装置に予め登録されていてもよく、また、携帯端末１０２の入力装置（不図示）を用いたユーザの操作入力により受け付けてもよい。
このあと、管理サーバ１０１は、携帯端末１０２からのユーザＩＤおよびパスワードのペアを、認証情報１６００のユーザＩＤおよびパスワードのペアと一致判定する。ここで、認証情報１６００のユーザＩＤおよびパスワードと一致すれば、携帯端末１０２のユーザの身元が保証されたことになる。
なお、認証後において、携帯端末１０２は、例えば、管理サーバ１０１のＳＳＬサーバ証明書に含まれる公開鍵を用いてパケットを暗号化して管理サーバ１０１との通信を行う。これにより、管理サーバ１０１と携帯端末１０２との間でセキュアな通信を行うことができる。
（ノードＮの鍵設定処理手順）
図１７は、ノードの鍵設定処理手順の一例を示すフローチャートである。図１７のフローチャートにおいて、まず、検知部６０１により、管理サーバ１０１と通信可能な携帯端末１０２との接続を検知したか否かを判断する（ステップＳ１７０１）。
ここで、携帯端末１０２との接続を検知するのを待って（ステップＳ１７０１：Ｎｏ）、検知した場合（ステップＳ１７０１：Ｙｅｓ）、受付部６０２により、携帯端末１０２からＧＷ探索フレームの送信指示を受け付けたか否かを判断する（ステップＳ１７０２）。
ここで、ＧＷ探索フレームの送信指示を受け付けるのを待って（ステップＳ１７０２：Ｎｏ）、受け付けた場合（ステップＳ１７０２：Ｙｅｓ）、フレーム送信部６０３により、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストする（ステップＳ１７０３）。
このあと、鍵受信部６０４により、ノードＮが所属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵Ｋｉを携帯端末１０２から受信したか否かを判断する（ステップＳ１７０４）。
ここで、ゲートウェイＧｉ固有の暗号鍵Ｋｉを受信するのを待って（ステップＳ１７０４：Ｎｏ）、受信した場合（ステップＳ１７０４：Ｙｅｓ）、設定部６０５により、受信された暗号鍵Ｋｉを、パケットを暗号化するための鍵に設定して（ステップＳ１７０５）、本フローチャートによる一連の処理を終了する。
これにより、アドホックネットワークＡｉ内のノード間で送受信されるパケットを暗号化するためのゲートウェイＧｉ固有の暗号鍵Ｋｉを、携帯端末１０２を利用して一時的に確立された通信路を介して管理サーバ１０１から取得して設定することができる。
（ゲートウェイＧｉの鍵通知処理手順）
図１８は、ゲートウェイの鍵通知処理手順の一例を示すフローチャートである。図１８のフローチャートにおいて、まず、ＧＷ受信部９０１により、アドホックネットワークＡｉを介して、ノードＮからブロードキャストされたＧＷ探索フレームを受信したか否かを判断する（ステップＳ１８０１）。
ここで、ＧＷ探索フレームを受信するのを待って（ステップＳ１８０１：Ｎｏ）、受信した場合（ステップＳ１８０１：Ｙｅｓ）、作成部９０２により、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレーム（鍵通知フレーム１０００または１１００）を作成する（ステップＳ１８０２）。
そして、ＧＷ送信部９０３により、ネットワークＮＷ１を介して、作成された鍵通知フレームを管理サーバ１０１に送信して（ステップＳ１８０３）、本フローチャートによる一連の処理を終了する。
これにより、アドホックネットワークＡｉ内のノードＮからのＧＷ探索フレームに応じて、ゲートウェイＧｉ固有の暗号鍵Ｋｉの通知要求を表す鍵通知フレームを管理サーバ１０１に送信することができる。
（管理サーバ１０１の鍵提供処理手順）
つぎに、管理サーバ１０１の鍵提供処理手順について説明する。まず、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持していない場合の鍵提供処理手順について説明する。すなわち、以下に説明する鍵提供処理手順は、ゲートウェイＧｉから管理サーバ１０１に送信される鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉが含まれている場合の処理手順である。
図１９は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その１）である。図１９のフローチャートにおいて、まず、ＳＶ受信部１２０１により、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレームを受信したか否かを判断する（ステップＳ１９０１）。
ここで、鍵通知フレームを受信するのを待って（ステップＳ１９０１：Ｎｏ）、受信した場合（ステップＳ１９０１：Ｙｅｓ）、判断部１２０３により、受信された鍵通知フレームに含まれるノードＩＤと暗号鍵Ｋｉを特定する（ステップＳ１９０２）。そして、判断部１２０３により、特定されたノードＩＤと暗号鍵のペアが送信済リスト１３００に登録されているか否かを判断する（ステップＳ１９０３）。
ここで、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に未登録の場合（ステップＳ１９０３：Ｎｏ）、ＳＶ送信部１２０２により、受信された鍵通知フレームに含まれるユーザＩＤを特定する（ステップＳ１９０４）。つぎに、ＳＶ送信部１２０２により、ネットワークＮＷ２を介して、特定されたユーザＩＤの携帯端末１０２に受信された鍵通知フレームを送信する（ステップＳ１９０５）。
そして、判断部１２０３により、ステップＳ１９０２において特定されたノードＩＤと暗号鍵Ｋｉを関連付けて送信済リスト１３００に登録して（ステップＳ１９０６）、本フローチャートによる一連の処理を終了する。一方、ステップＳ１９０３において、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に登録されている場合（ステップＳ１９０３：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。
これにより、携帯端末１０２を利用して一時的に確立された通信路を介して、ノードＮが属するアドホックネットワークＡｉ内のゲートウェイＧｉ固有の暗号鍵ＫｉをノードＮに提供することができる。
つぎに、管理サーバ１０１が各ゲートウェイＧ１〜Ｇｎ固有の暗号鍵Ｋ１〜Ｋｎを保持している場合の鍵提供処理手順について説明する。すなわち、以下に説明する鍵提供処理手順は、ゲートウェイＧｉから管理サーバ１０１に送信される鍵通知フレームにゲートウェイＧｉ固有の暗号鍵Ｋｉが含まれていない場合の処理手順である。
図２０は、管理サーバの鍵提供処理手順の一例を示すフローチャート（その２）である。図２０のフローチャートにおいて、まず、ＳＶ受信部１２０１により、ネットワークＮＷ１を介して、ゲートウェイＧｉから鍵通知フレームを受信したか否かを判断する（ステップＳ２００１）。
ここで、鍵通知フレームを受信するのを待って（ステップＳ２００１：Ｎｏ）、受信した場合（ステップＳ２００１：Ｙｅｓ）、抽出部１２０４により、受信された鍵通知フレームに含まれるゲートウェイＩＤを特定する（ステップＳ２００２）。つぎに、抽出部１２０４により、暗号鍵ＤＢ１４００の中から、特定されたゲートウェイＩＤと関連付けて記憶されている暗号鍵Ｋｉを抽出する（ステップＳ２００３）。
そして、判断部１２０３により、受信された鍵通知フレームに含まれるノードＩＤを特定する（ステップＳ２００４）。そして、判断部１２０３により、特定されたノードＩＤと抽出された暗号鍵のペアが送信済リスト１３００に登録されているか否かを判断する（ステップＳ２００５）。
ここで、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に未登録の場合（ステップＳ２００５：Ｎｏ）、ＳＶ送信部１２０２により、受信された鍵通知フレームに含まれるユーザＩＤを特定する（ステップＳ２００６）。つぎに、ＳＶ送信部１２０２により、ネットワークＮＷ２を介して、特定されたユーザＩＤの携帯端末１０２に抽出された暗号鍵Ｋｉを送信する（ステップＳ２００７）。
そして、判断部１２０３により、ステップＳ２００４において特定されたノードＩＤとステップＳ２００３において抽出された暗号鍵Ｋｉを関連付けて送信済リスト１３００に登録して（ステップＳ２００８）、本フローチャートによる一連の処理を終了する。
一方、ステップＳ２００５において、ノードＩＤと暗号鍵Ｋｉのペアが送信済リスト１３００に登録されている場合（ステップＳ２００５：Ｙｅｓ）、本フローチャートによる一連の処理を終了する。これにより、ゲートウェイＧｉから暗号鍵Ｋｉを含む鍵通知フレームを受信する場合に比べて、ゲートウェイＧｉとの通信時におけるデータ量を削減することができる。
以上説明したように、本実施の形態にかかるノードＮによれば、作業員ＯＰの携帯端末１０２を介して、管理サーバ１０１との一時的な通信路を確立することができる。また、ノードＮによれば、携帯端末１０２との接続を契機に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。また、ノードＮによれば、ＧＷ探索フレームがゲートウェイＧｉに転送された結果、ゲートウェイＧｉから管理サーバ１０１に送信された暗号鍵Ｋｉを、携帯端末１０２を介して受信することができる。
これにより、ノードＮの鍵設定時に、ノードＮに設定すべき暗号鍵Ｋｉを容易に取得することができ、ノードＮが用いる暗号鍵Ｋｉの設定作業の効率化を図ることができる。具体的には、例えば、ノードＮの初期導入時などにおいて、作業員ＯＰが地理的に絞り込まれた候補となるゲートウェイとノードＮとの通信状況をしらみつぶしに確認するなどの作業が不要となり、ノードＮに対する暗号鍵Ｋｉの設定作業の効率化を図ることができる。また、確認作業のために候補となる各ゲートウェイの暗号鍵を携帯端末１０２などに記録しておく必要がないため、持ち運びの際の情報漏洩のリスクを低減させることができる。
また、本実施の形態にかかるノードＮによれば、携帯端末１０２からのＧＷ探索フレームの送信指示を契機に、ＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、携帯端末１０２を利用して、ノードＮに対して鍵設定とは異なる設定作業などを行う際に、携帯端末１０２との接続が検知された時点で、ノードＮからＧＷ探索フレームがブロードキャストされることを防ぐことができる。
また、本実施の形態にかかるノードＮによれば、携帯端末１０２の識別子を含むＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、管理サーバ１０１において、複数の携帯端末１０２が通信可能に接続されている場合であっても、鍵通知フレームの送信先となる携帯端末１０２を適切に識別することができる。
また、本実施の形態にかかるノードＮによれば、ノードＮの識別子を含むＧＷ探索フレームをアドホックネットワークＡｉにブロードキャストすることができる。これにより、管理サーバ１０１において、鍵通知フレームを送信済みのノードＮを管理することができ、鍵通知フレームの重複送信を防ぐことができる。
以上のことから、本実施の形態にかかる鍵設定方法、ノード、およびネットワークシステムによれば、アドホックネットワーク内のノードに対する暗号鍵の設定作業にかかる作業員の作業負担の軽減化および作業時間の短縮化を図ることができる。
なお、本実施の形態で説明した鍵設定方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本鍵設定プログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また本鍵設定プログラムは、インターネット等のネットワークを介して配布してもよい。
上述した実施の形態に関し、さらに以下の付記を開示する。
（付記１）複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードが実行する鍵設定方法であって、
前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知する検知工程と、
前記検知工程によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信工程と、
前記送信工程によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信工程と、
前記受信工程によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定工程と、
を含むことを特徴とする鍵設定方法。
（付記２）前記検知工程によって接続が検知された前記携帯端末から、前記データを暗号化するための鍵の取得要求の送信指示を受け付ける受付工程をさらに含み、
前記送信工程は、
前記受付工程によって前記送信指示を受け付けた場合、前記取得要求を前記いずれかのアドホックネットワークに同時通報することを特徴とする付記１に記載の鍵設定方法。
（付記３）前記送信工程は、
前記送信指示に含まれる前記サーバが通信先を識別するための前記携帯端末の識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする付記２に記載の鍵設定方法。
（付記４）前記送信工程は、
前記ゲートウェイ固有の鍵を送信済みのノードを前記サーバが識別するための前記ノードの識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする付記２または３に記載の鍵設定方法。
（付記５）前記いずれかのアドホックネットワーク内の自ノードとは異なる他ノードから前記取得要求を受信した場合、当該取得要求を前記いずれかのアドホックネットワークに同時通報する転送工程をさらに含むことを特徴とする付記１に記載の鍵設定方法。
（付記６）複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードであって、
前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知する検知手段と、
前記検知手段によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信手段と、
前記送信手段によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信手段と、
前記受信手段によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定手段と、
を備えることを特徴とするノード。
（付記７）前記検知手段によって接続が検知された前記携帯端末から、前記データを暗号化するための鍵の取得要求の送信指示を受け付ける受付手段をさらに備え、
前記送信手段は、
前記受付手段によって前記送信指示を受け付けた場合、前記取得要求を前記いずれかのアドホックネットワークに同時通報することを特徴とする付記６に記載のノード。
（付記８）前記送信手段は、
前記送信指示に含まれる前記サーバが通信先を識別するための前記携帯端末の識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする付記７に記載のノード。
（付記９）前記送信手段は、
前記ゲートウェイ固有の鍵を送信済みのノードを前記サーバが識別するための前記ノードの識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする付記７または８に記載のノード。
（付記１０）前記いずれかのアドホックネットワーク内の自ノードとは異なる他ノードから前記取得要求を受信した場合、当該取得要求を前記いずれかのアドホックネットワークに同時通報する転送手段をさらに備えることを特徴とする付記６に記載のノード。
（付記１１）複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードと、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと、を含むネットワークシステムであって、
前記ノードは、
前記サーバと通信可能な携帯端末との接続を検知する検知手段と、
前記検知手段によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信手段と、
前記送信手段によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信手段と、
前記受信手段によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定手段と、を備え、
前記サーバは、
前記取得要求が転送された前記いずれかのアドホックネットワーク内のゲートウェイから、前記ゲートウェイ固有の鍵を受信する鍵受信手段と、
前記鍵受信手段によって受信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記ノードに送信する鍵送信手段と、
を備えることを特徴とするネットワークシステム。
１００ ネットワークシステム
１０１ 管理サーバ
１０２ 携帯端末
６０１ 検知部
６０２ 受付部
６０３ フレーム送信部
６０４ 鍵受信部
６０５ 設定部
６０６ フレーム受信部
８００ ＧＷ探索フレーム
９０１ ＧＷ受信部
９０２ 作成部
９０３ ＧＷ送信部
１２０１ ＳＶ受信部
１２０２ ＳＶ送信部
１２０３ 判断部
１２０４ 抽出部
１０００，１１００ 鍵通知フレーム
Ａ１〜Ａｎ，Ａｉ アドホックネットワーク
Ｇ１〜Ｇｎ，Ｇｉ ゲートウェイ
Ｋ１〜Ｋｎ，Ｋｉ 暗号鍵
Ｎ ノード
ＮＷ１，ＮＷ２，ＮＷ３ ネットワーク

Claims (11)

  1. 複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードが実行する鍵設定方法であって、
    前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知する検知工程と、
    前記検知工程によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信工程と、
    前記送信工程によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信工程と、
    前記受信工程によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定工程と、
    を含むことを特徴とする鍵設定方法。
  2. 前記検知工程によって接続が検知された前記携帯端末から、前記データを暗号化するための鍵の取得要求の送信指示を受け付ける受付工程をさらに含み、
    前記送信工程は、
    前記受付工程によって前記送信指示を受け付けた場合、前記取得要求を前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項１に記載の鍵設定方法。
  3. 前記送信工程は、
    前記送信指示に含まれる前記サーバが通信先を識別するための前記携帯端末の識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項２に記載の鍵設定方法。
  4. 前記送信工程は、
    前記ゲートウェイ固有の鍵を送信済みのノードを前記サーバが識別するための前記ノードの識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項２または３に記載の鍵設定方法。
  5. 前記いずれかのアドホックネットワーク内の自ノードとは異なる他ノードから前記取得要求を受信した場合、当該取得要求を前記いずれかのアドホックネットワークに同時通報する転送工程をさらに含むことを特徴とする請求項１に記載の鍵設定方法。
  6. 複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりデータを送受信するノードであって、
    前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと通信可能な携帯端末との接続を検知する検知手段と、
    前記検知手段によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信手段と、
    前記送信手段によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信手段と、
    前記受信手段によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定手段と、
    を備えることを特徴とするノード。
  7. 前記検知手段によって接続が検知された前記携帯端末から、前記データを暗号化するための鍵の取得要求の送信指示を受け付ける受付手段をさらに備え、
    前記送信手段は、
    前記受付手段によって前記送信指示を受け付けた場合、前記取得要求を前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項６に記載のノード。
  8. 前記送信手段は、
    前記送信指示に含まれる前記サーバが通信先を識別するための前記携帯端末の識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項６に記載のノード。
  9. 前記送信手段は、
    前記ゲートウェイ固有の鍵を送信済みのノードを前記サーバが識別するための前記ノードの識別子を含む前記取得要求を、前記いずれかのアドホックネットワークに同時通報することを特徴とする請求項７または８に記載のノード。
  10. 前記いずれかのアドホックネットワーク内の自ノードとは異なる他ノードから前記取得要求を受信した場合、当該取得要求を前記いずれかのアドホックネットワークに同時通報する転送手段をさらに備えることを特徴とする請求項６に記載のノード。
  11. 複数のアドホックネットワークのいずれかのアドホックネットワーク内でマルチホップ通信によりパケットを送受信するノードと、前記複数のアドホックネットワークの各アドホックネットワーク内のゲートウェイと接続されたサーバと、を含むネットワークシステムであって、
    前記ノードは、
    前記サーバと通信可能な携帯端末との接続を検知する検知手段と、
    前記検知手段によって前記携帯端末との接続が検知された場合、前記データを暗号化するための鍵の取得要求を前記いずれかのアドホックネットワークに同時通報する送信手段と、
    前記送信手段によって同時通報された前記取得要求が前記いずれかのアドホックネットワーク内のゲートウェイに転送された結果、当該ゲートウェイから前記サーバに送信されたゲートウェイ固有の鍵を、前記携帯端末を介して前記サーバから受信する受信手段と、
    前記受信手段によって受信された前記ゲートウェイ固有の鍵を、前記データを暗号化するための鍵に設定する設定手段と、を備え、
    前記サーバは、
    前記取得要求が転送された前記いずれかのアドホックネットワーク内のゲートウェイから、前記ゲートウェイ固有の鍵を受信する鍵受信手段と、
    前記鍵受信手段によって受信された前記ゲートウェイ固有の鍵を、前記携帯端末を介して前記ノードに送信する鍵送信手段と、
    を備えることを特徴とするネットワークシステム。
JP2012526241A 2010-07-28 2010-07-28 鍵設定方法、ノード、およびネットワークシステム Expired - Fee Related JP5397547B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/062712 WO2012014294A1 (ja) 2010-07-28 2010-07-28 鍵設定方法、ノード、およびネットワークシステム

Publications (2)

Publication Number Publication Date
JPWO2012014294A1 true JPWO2012014294A1 (ja) 2013-09-09
JP5397547B2 JP5397547B2 (ja) 2014-01-22

Family

ID=45529539

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012526241A Expired - Fee Related JP5397547B2 (ja) 2010-07-28 2010-07-28 鍵設定方法、ノード、およびネットワークシステム

Country Status (3)

Country Link
US (1) US8719563B2 (ja)
JP (1) JP5397547B2 (ja)
WO (1) WO2012014294A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949949B1 (en) * 2014-02-11 2015-02-03 Level 3 Communications, Llc Network element authentication in communication networks
US10015720B2 (en) 2014-03-14 2018-07-03 GoTenna, Inc. System and method for digital communication between computing devices
US10944669B1 (en) 2018-02-09 2021-03-09 GoTenna, Inc. System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos
EP3831021A1 (en) 2018-07-27 2021-06-09 Gotenna Inc. VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS
US11082344B2 (en) 2019-03-08 2021-08-03 GoTenna, Inc. Method for utilization-based traffic throttling in a wireless mesh network
US11467848B2 (en) * 2020-05-07 2022-10-11 Capital One Services, Llc Portable operating system and portable user data

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7761910B2 (en) * 1994-12-30 2010-07-20 Power Measurement Ltd. System and method for assigning an identity to an intelligent electronic device
JP2003348072A (ja) * 2002-05-30 2003-12-05 Hitachi Ltd 自律分散網における暗号鍵の管理方法および装置
US9818136B1 (en) * 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
JP4357339B2 (ja) * 2004-04-07 2009-11-04 株式会社バッファロー 無線通信システム、アクセスポイントおよび無線通信方法
JP2006135874A (ja) 2004-11-09 2006-05-25 Matsushita Electric Ind Co Ltd 無線携帯端末の通信制御情報設定システム
JP4533258B2 (ja) 2005-06-29 2010-09-01 株式会社日立製作所 アドホックネットワーク用の通信端末および通信制御方法
JP4750515B2 (ja) * 2005-09-07 2011-08-17 株式会社エヌ・ティ・ティ・ドコモ 安全なアドホックネットワークを構築するシステム
US7714735B2 (en) * 2005-09-13 2010-05-11 Daniel Rockwell Monitoring electrical assets for fault and efficiency correction
JP4735157B2 (ja) 2005-09-22 2011-07-27 ソニー株式会社 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
CN101400105B (zh) * 2007-09-25 2013-04-10 株式会社Ntt都科摩 自适应网关发现方法及网关
US20090135762A1 (en) * 2007-11-25 2009-05-28 Michel Veillette Point-to-point communication within a mesh network
US8138934B2 (en) * 2007-11-25 2012-03-20 Trilliant Networks, Inc. System and method for false alert filtering of event messages within a network
JP5077186B2 (ja) * 2008-10-17 2012-11-21 富士通株式会社 通信装置、通信方法及び通信プログラム
US8397288B2 (en) * 2010-08-25 2013-03-12 Itron, Inc. System and method for operation of open connections for secure network communications

Also Published As

Publication number Publication date
US8719563B2 (en) 2014-05-06
WO2012014294A1 (ja) 2012-02-02
US20130138950A1 (en) 2013-05-30
JP5397547B2 (ja) 2014-01-22

Similar Documents

Publication Publication Date Title
US9032203B2 (en) Key setting method, node, server, and network system
JP5397547B2 (ja) 鍵設定方法、ノード、およびネットワークシステム
Yan et al. An efficient security protocol for advanced metering infrastructure in smart grid
WO2019128753A1 (zh) 一种低延迟的量子密钥移动服务方法
JP4612817B2 (ja) グループ管理装置及び情報処理方法、ならびにコンピュータプログラム及び記録媒体
CN101738516B (zh) 一种电子式电能表数据安全传输的方法及电能表装置
US8732454B2 (en) Key setting method, node, and network system
US20140006785A1 (en) Systems and methods for authenticating devices by adding secure features to wi-fi tags
JP4405309B2 (ja) アクセスポイント、無線ｌａｎ接続方法、無線ｌａｎ接続プログラムを記録した媒体および無線ｌａｎシステム
CN1798021B (zh) 通信支持服务器、通信支持方法、及通信支持系统
JP2002217896A (ja) 暗号通信方法およびゲートウエイ装置
JP5488716B2 (ja) 鍵更新方法、ノード、ゲートウェイ、サーバ、およびネットワークシステム
WO2014030186A1 (ja) 中継装置、中継方法、中継プログラムおよび中継システム
JP5488715B2 (ja) 鍵更新方法、ノード、サーバ、およびネットワークシステム
JP4933286B2 (ja) 暗号化パケット通信システム
JP5494828B2 (ja) 鍵設定方法、ノード、サーバ、およびネットワークシステム
JP5418699B2 (ja) 鍵設定方法、ノード、サーバおよびネットワークシステム
JP5418700B2 (ja) 鍵設定方法、ノード、サーバおよびネットワークシステム
JP4480478B2 (ja) アクセスポイントおよび外部記憶装置を含むシステム、アクセスポイント、無線ｌａｎ接続方法、無線ｌａｎ接続プログラムを記録した媒体および無線ｌａｎシステム
JP5621905B2 (ja) 鍵設定方法、ノード、サーバおよびネットワークシステム
WO2024069879A1 (ja) 端末装置によって中継される通信のセキュリティ
JP6953680B2 (ja) 鍵管理装置、通信システム、端末装置、鍵管理方法、通信方法、処理方法、プログラム
JPWO2014016863A1 (ja) ノードおよび通信方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130924

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131007

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees