特許 6933182 通信システムおよび通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6933182

(24)【登録日】2021年8月23日

(45)【発行日】2021年9月8日

(54)【発明の名称】通信システムおよび通信方法

(51)【国際特許分類】

   H04L 9/08 20060101AFI20210826BHJP

【ＦＩ】

   H04L9/00 601C

   H04L9/00 601E

【請求項の数】7

【全頁数】26

(21)【出願番号】特願2018-66248(P2018-66248)

(22)【出願日】2018年3月29日

(65)【公開番号】特開2019-176449(P2019-176449A)

(43)【公開日】2019年10月10日

【審査請求日】2020年11月11日

(73)【特許権者】

【識別番号】000000295

【氏名又は名称】沖電気工業株式会社

(74)【代理人】

【識別番号】100115417

【弁理士】

【氏名又は名称】鈴木 弘一

(72)【発明者】

【氏名】中野 義久

(72)【発明者】

【氏名】堤 直崇

【審査官】 児玉 崇晶

(56)【参考文献】

【文献】 特開２０１８−０４２１１０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１７／０３３９５５９（ＵＳ，Ａ１）

【文献】 特開２００５−０３９６４３（ＪＰ，Ａ）

【文献】 特開２０１３−１４５９９８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１６／０１１９３０２（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／０８

(57)【特許請求の範囲】

【請求項1】

通信端末とサーバとが共通鍵を用いて暗号通信を行う通信システムであって、
前記通信端末は、
前記サーバと通信を行う第一の通信手段、
第一の情報を記憶する第一の記憶手段、
前記サーバへ送信される第一の要求情報と、前記サーバへ送信される第二の要求情報とを生成する要求情報生成手段、
前記第一の通信手段を介して前記サーバへ前記第一の要求情報を送信し、前記第一の要求情報に対する第一の応答情報を、前記第一の通信手段を介して前記サーバから受信する第一の接続処理手段、
前記第一の要求情報と、前記第一の応答情報と、前記第一の情報とを用いて第二の情報を生成する第一の生成手段、
前記第一の通信手段を介して前記サーバへ前記第二の要求情報を送信し、前記第二の要求情報に対する第二の応答情報を、前記第一の通信手段を介して前記サーバから受信する第二の接続処理手段、
前記第二の要求情報と、前記第二の応答情報と、前記第二の情報とを用いて第一の共通鍵を生成する第二の生成手段、
前記第一の通信手段に接続され、前記第一の共通鍵を用いて前記サーバへの送信データを暗号化する第一の暗号化手段、
前記第一の通信手段に接続され、前記第一の共通鍵を用いて前記サーバからの受信データを復号する第一の復号手段、
を備え、
前記サーバは、
前記通信端末と通信を行う第二の通信手段、
前記第一の情報と同一の値である第三の情報を記憶する第二の記憶手段、
前記通信端末へ送信される前記第一の応答情報と、前記通信端末へ送信される前記第二の応答情報とを生成する応答情報生成手段、
前記第二の通信手段を介して前記通信端末から前記第一の要求情報を受信し、前記第二の通信手段を介して前記通信端末へ前記第一の応答情報を送信する第三の接続処理手段、
前記第一の要求情報と、前記第一の応答情報と、前記第三の情報とを用いて前記第二の情報と同一の値である第四の情報を生成する第三の生成手段、
前記第二の通信手段を介して前記通信端末から前記第二の要求情報を受信し、前記第二の通信手段を介して前記通信端末へ前記第二の応答情報を送信する第四の接続処理手段、
前記第二の要求情報と、前記第二の応答情報と、前記第四の情報とを用いて、前記第一の共通鍵と同一の値である第二の共通鍵を生成する第四の生成手段、
前記第二の通信手段に接続され、前記第二の共通鍵を用いて前記通信端末への送信データを暗号化する第二の暗号化手段、
前記第二の通信手段に接続され、前記第二の共通鍵を用いて前記通信端末からの受信データを復号する第二の復号手段、
を備えることを特徴とする通信システム。

【請求項2】

前記第一の記憶手段は、前記通信端末の動作プログラムを保持し、
前記通信端末は、前記動作プログラムから前記第一の情報を導出する導出手段を備える、ことを特徴とする請求項１に記載の通信システム。

【請求項3】

前記通信端末は、前記第一の生成手段による前記第二の情報を生成受けて、前記第一の記憶手段に前記第二の情報が保持された状態を維持して前記通信端末を再起動して前記通信端末と前記サーバとの接続を解消する再起動手段を備え、
前記第二の接続処理手段は、前記通信端末の再起動を受けて、前記第一の通信手段を介して前記サーバへ前記第二の要求情報を送信する、
ことを特徴とする請求項１または２に記載の通信システム。

【請求項4】

前記第一の記憶手段と前記第二の記憶手段とはそれぞれ演算式を記憶し、
前記第一の生成手段は、前記第一の要求情報と、前記第一の応答情報と、前記第一の情報とを前記演算式に設定して前記第二の情報を生成し、
前記第三の生成手段は、前記第一の要求情報と、前記第一の応答情報と、前記第三の情報とを前記演算式に設定して前記第四の情報を生成し、
前記第二の生成手段は、前記第二の要求情報と、前記第二の応答情報と、前記第二の情報とを前記演算式に設定して前記第一の共通鍵を生成し
前記第四の生成手段は、前記第二の要求情報と、前記第二の応答情報と、前記第四の情報とを前記演算式に設定して前記第二の共通鍵を生成する、
ことを特徴とする請求項１から３のいずれか一項に記載の通信システム。

【請求項5】

前記通信端末は乱数を発生する第一の乱数発生手段を備え、
前記第一の記憶手段は前記通信端末に固有の端末識別情報を記憶し、
前記第一の要求情報は、前記端末識別情報と、前記第一の乱数発生手段による第一の乱数値とを含み、
前記第二の要求情報は、前記端末識別情報と前記第一の乱数発生手段による第二の乱数値とを含み、
前記サーバは乱数を発生する第二の乱数発生手段を備え、
前記第二の記憶手段は前記端末識別情報毎に通信識別子を記憶し、
前記第一の応答情報は、前記通信識別子と、前記第二の乱数発生手段による第三の乱数値とを含み、
前記第二の応答情報は、前記通信識別子と、前記第二の乱数発生手段による第四の乱数値とを含む、
ことを特徴とする請求項１から４のいずれか一項に記載の通信システム。

【請求項6】

前記通信端末は複数であり、
複数の前記通信端末の前記第一の生成手段は、前記第一の情報と、複数の前記通信端末毎に異なる乱数値を含む前記第一の要求情報と、複数の前記通信端末毎に異なる乱数値を含む前記第一の応答情報とを用いて、複数の前記通信端末毎に異なる前記第二の情報を生成し、
前記サーバの前記第三の生成手段のそれぞれは、前記第三の情報と、複数の前記通信端末毎に異なる乱数値を含む前記第一の要求情報と、複数の前記通信端末毎に異なる乱数値を含む前記第一の応答情報とを用いて、複数の前記通信端末毎に異なる前記第四の情報を生成し、
複数の前記通信端末の前記第二の生成手段は、複数の前記通信端末毎に異なる前記第二の情報と、複数の前記通信端末毎に異なる乱数値を含む前記第二の要求情報と、複数の前記通信端末毎に異なる乱数値を含む前記第二の応答情報とを用いて、複数の前記通信端末毎に異なる前記第一の共通鍵を生成し、
前記サーバの前記第四の生成手段のそれぞれは、複数の前記通信端末毎に異なる前記第四の情報と、複数の前記通信端末毎に異なる乱数値を含む前記第二の要求情報と、複数の前記通信端末毎に異なる乱数値を含む前記第二の応答情報とを用いて、複数の前記通信端末毎に異なる前記第二の共通鍵を生成し、
複数の前記通信端末における前記第一の暗号化手段と前記第一の復号手段はそれぞれ、複数の前記通信端末毎に生成された前記第一の共通鍵を用いて前記サーバへの送信データの暗号化と前記サーバからの受信データの復号を行い、
前記サーバの前記第二の暗号化手段と前記第二の復号手段はそれぞれ、通信先である前記通信端末毎に生成された前記第二の共通鍵を用いて、前記通信端末への送信データの暗号化と前記通信端末からの受信データの復号とを行う、
ことを特徴とする請求項５に記載の通信システム。

【請求項7】

第一の情報を保持する第一の記憶手段を備える通信端末と、前記第一の情報と同一の値である第三の情報を保持する第二の記憶手段を備えるサーバとが共通鍵を用いて暗号通信を行う通信方法であって、
前記通信端末が前記サーバへ第一の要求情報を送信する第一のステップ、
前記サーバが前記第一の要求情報を受信すると、前記通信端末へ第一の応答情報を送信する第二のステップ、
前記通信端末が前記第一の要求情報と、前記第一の応答情報と、前記第一の情報とを用いて第二の情報を生成する第三のステップ、
前記サーバが前記第一の要求情報と、前記第一の応答情報と、前記第三の情報とを用いて前記第二の情報と同一の値である第四の情報を生成する第四のステップ、
前記第三のステップの実行を受けて、前記通信端末が前記サーバへ第二の要求情報を送信する第五のステップ、
前記サーバが前記第二の要求情報の受信を受けて、前記通信端末へ第二の応答情報を送信する第六のステップ、
前記通信端末が前記第二の要求情報と、前記第二の応答情報と、前記第二の情報とを用いて第一の共通鍵を生成する第七のステップ、
前記サーバが前記第二の要求情報と、前記第二の応答情報と、前記第四の情報とを用いて前記第一の共通鍵と同一の値である第二の共通鍵を生成する第八のステップ、
前記通信端末が前記第一の共通鍵を用いて前記サーバへの送信データの暗号化と前記サーバからの受信データの復号とを行い、前記サーバが前記第二の共通鍵を用いて前記通信端末への送信データの暗号化と前記通信端末からの受信データの復号とを行う第九のステップ、
を含む通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は通信システムおよび通信方法に関する。

【背景技術】

【0002】

複数の無線端末がサーバと接続され、無線端末がサーバへ情報を送信する無線通信システムがある。そのような無線通信システムを実現する手段として、低消費電力で長距離通信を可能とする無線通信技術がある。これは一般にＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）と呼ばれる。ＬＰＷＡにおける無線端末は９２０ＭＨｚなどの１ＧＨｚ以下のサブギガ帯や数ＧＨｚの無線帯域を用い、数十ｍＡの消費電力で、数Ｋｍから数十Ｋｍの伝播距離の通信を行う。ＬＰＷＡに対応する無線端末は通信に要する電力が小さいため電池駆動であっても長期間に亘って運用することができる。また多数の無線端末を広範囲に配置する場合でも、長距離の通信が可能であるため中継局が不要、あるいは小数で済む。これにより、例えば広域かつ多数に亘るセンサー情報を収集する用途などで無線通信システムを構築する場合、ＬＰＷＡの採用により無線通信システムの経済コストを抑制することができる。

【0003】

無線通信システムでは、無線端末からサーバへの通信が盗聴や改ざんされないよう、通信にセキュリティを設けることが求められる。セキュリティの技術として、例えば特許文献１がある。特許文献１は、クライアント端末がサーバに接続する情報処理システムを説明しており、当該情報処理システムはクライアント端末が公開鍵を保持し、サーバが公開鍵と秘密鍵を保持して通信の暗号化を行う公開鍵暗号方式を用いている。また特許文献１は、サーバが公開鍵と秘密鍵を更新し、またクライアント端末がサーバで秘密鍵と公開鍵を更新するために必要となる情報を生成および送信し、サーバで更新された公開鍵をサーバから受信する態様を説明する。

【先行技術文献】

【特許文献】

【0004】

特許文献１ 特開２０１５−１０６８４２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１に挙げたような公開鍵暗号方式は、暗号化と復号の処理が複雑であり、そのためサーバと無線端末の双方で、大きな消費電力や高度なハードウェアを必要とする。そのため、無線通信システムに公開鍵暗号方式を採用すると、無線端末の消費電力は増大し、また無線端末のハードウェアは高度化して経済コストが増加する。ここでＬＰＷＡを採用した無線通信システムでは、上述のとおり無線端末は低消費電力での動作が求められ、また無線端末の経済コストは低いことが求められる。故にＬＰＷＡの無線通信システムでは公開鍵暗号方式を採用し難い。例えば、ＬＰＷＡの技術仕様の１つとしてＬｏＲａＷＡＮ（ＬｏＲａは登録商標）があるが、ＬｏＲａＷＡＮにおいても、無線端末とサーバとの間における通信の暗号化は、公開鍵暗号方式に比べて低消費電力かつ簡素なハードウェアで実現可能な、共通鍵暗号方式が採用されている。

【0006】

ここで、無線通信システムに共通鍵暗号方式を採用する場合、暗号化に用いられる暗号鍵を、無線端末の設置時に、無線端末に保持させる必要がある。しかし、上述のように多数の無線端末が広範囲に設置されることが想定されるため、無線端末に暗号鍵を保持させると、暗号鍵が第三者に漏洩するおそれがある。無線端末とサーバとの間の通信を暗号化する暗号鍵が第三者に漏洩すると、無線端末からサーバへの通信が第三者に解読されてしまう。

【0007】

従って、ＬＰＷＡの無線通信システムの利点である無線端末の低消費電力性、低経済コストを損なわないために、暗号鍵の漏洩を考慮した共通鍵暗号方式による通信の暗号化が行える通信システムおよび通信方法が求められている。

【0008】

本発明はこのような事情を考慮してなされたものであり、暗号鍵の漏洩を考慮した共通鍵暗号方式による通信の暗号化が行える通信システムおよび通信方法を提案するものである。

【課題を解決するための手段】

【0009】

第一の本発明は、通信端末とサーバとが共通鍵を用いて暗号通信を行う通信システムであって、前記通信端末は、前記サーバと通信を行う第一の通信手段、第一の情報を記憶する第一の記憶手段、前記サーバへ送信される第一の要求情報と、前記サーバへ送信される第二の要求情報とを生成する要求情報生成手段、前記第一の通信手段を介して前記サーバへ前記第一の要求情報を送信し、前記第一の要求情報に対する第一の応答情報を、前記第一の通信手段を介して前記サーバから受信する第一の接続処理手段、前記第一の要求情報と、前記第一の応答情報と、前記第一の情報とを用いて第二の情報を生成する第一の生成手段、前記第一の通信手段を介して前記サーバへ前記第二の要求情報を送信し、前記第二の要求情報に対する第二の応答情報を、前記第一の通信手段を介して前記サーバから受信する第二の接続処理手段、前記第二の要求情報と、前記第二の応答情報と、前記第二の情報とを用いて第一の共通鍵を生成する第二の生成手段、前記第一の通信手段に接続され、前記第一の共通鍵を用いて前記サーバへの送信データを暗号化する第一の暗号化手段、前記第一の通信手段に接続され、前記第一の共通鍵を用いて前記サーバからの受信データを復号する第一の復号手段、を備え、前記サーバは、前記通信端末と通信を行う第二の通信手段、前記第一の情報と同一の値である第三の情報を記憶する第二の記憶手段、前記通信端末へ送信される前記第一の応答情報と、前記通信端末へ送信される前記第二の応答情報とを生成する応答情報生成手段、前記第二の通信手段を介して前記通信端末から前記第一の要求情報を受信し、前記第二の通信手段を介して前記通信端末へ前記第一の応答情報を送信する第三の接続処理手段、前記第一の要求情報と、前記第一の応答情報と、前記第三の情報とを用いて前記第二の情報と同一の値である第四の情報を生成する第三の生成手段、前記第二の通信手段を介して前記通信端末から前記第二の要求情報を受信し、前記第二の通信手段を介して前記通信端末へ前記第二の応答情報を送信する第四の接続処理手段、前記第二の要求情報と、前記第二の応答情報と、前記第四の情報とを用いて、前記第一の共通鍵と同一の値である第二の共通鍵を生成する第四の生成手段、前記第二の通信手段に接続され、前記第二の共通鍵を用いて前記通信端末への送信データを暗号化する第二の暗号化手段、前記第二の通信手段に接続され、前記第二の共通鍵を用いて前記通信端末からの受信データを復号する第二の復号手段を備えることを特徴とする。

【0010】

第二の本発明は、第一の情報を保持する第一の記憶手段を備える通信端末と、前記第一の情報と同一の値である第三の情報を保持する第二の記憶手段を備えるサーバとが共通鍵を用いて暗号通信を行う通信方法であって、前記通信端末が前記サーバへ第一の要求情報を送信する第一のステップ、前記サーバが前記第一の要求情報を受信すると、前記通信端末へ第一の応答情報を送信する第二のステップ、前記通信端末が前記第一の要求情報と、前記第一の応答情報と、前記第一の情報とを用いて第二の情報を生成する第三のステップ、前記サーバが前記第一の要求情報と、前記第一の応答情報と、前記第三の情報とを用いて前記第二の情報と同一の値である第四の情報を生成する第四のステップ、前記第三のステップの実行を受けて、前記通信端末が前記サーバへ第二の要求情報を送信する第五のステップ、前記サーバが前記第二の要求情報の受信を受けて、前記通信端末へ第二の応答情報を送信する第六のステップ、前記通信端末が前記第二の要求情報と、前記第二の応答情報と、前記第二の情報とを用いて第一の共通鍵を生成する第七のステップ、前記サーバが前記第二の要求情報と、前記第二の応答情報と、前記第四の情報とを用いて前記第一の共通鍵と同一の値である第二の共通鍵を生成する第八のステップ、前記通信端末が前記第一の共通鍵を用いて前記サーバへの送信データの暗号化と前記サーバからの受信データの復号とを行い、前記サーバが前記第二の共通鍵を用いて前記通信端末への送信データの暗号化と前記通信端末からの受信データの復号とを行う第九のステップを含むことを特徴とする。

【発明の効果】

【0011】

本発明によれば、暗号鍵の漏洩を考慮した共通鍵暗号方式による通信の暗号化が行える通信システムおよび通信方法が提供される。

【図面の簡単な説明】

【0012】

【図1】第１の実施形態における無線通信システム１Ａの全体構成を示す構成図である。

【図2】無線端末２の内部構成を示すブロック図である。

【図3】ネットワークサーバ４の内部構成を示すブロック図である。

【図4】ＬｏＲａＷＡＮにおける暗号鍵生成の基本的な仕組みを示す図である。

【図5】無線端末２とネットワークサーバ４とにおけるデータ送受信の流れを示すシーケンス図である。

【図6】無線端末２とネットワークサーバ４における各情報および暗号鍵の遷移を示す図である。

【図7】無線端末２の動作を示すフローチャートである。

【図8】ネットワークサーバ４の動作を示すフローチャートである。

【図9】第２の実施形態における無線通信システム１Ｂの全体構成を示す構成図である。

【図10】無線端末２−１、無線端末２−２およびネットワークサーバ４におけるデータ送受信の流れを示すシーケンス図である。

【図11】無線端末２−１、無線端末２−２とネットワークサーバ４における各情報の遷移を示す図である。

【発明を実施するための形態】

【0013】

（１）第１の実施形態
本発明の第１の実施形態を、図１から図８を参照して説明する。なお第１の実施形態では、ＬＰＷＡの技術仕様であるＬｏＲａＷＡＮ（ＬｏＲａ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ：ＬｏＲａは登録商標）に規定される方式を一部利用する例を説明する。

【0014】

（Ａ）ハードウェア
（Ａ−１）無線通信システムの全体構成
図１は、第１の実施形態における無線通信システム１Ａの全体構成を示す構成図である。図１において無線通信システム１Ａは、無線端末２、基地局３、ネットワークサーバ４、上位装置５を含む。無線端末２の数は任意のｎ個（ｎは１以上の整数）であってよいが、第１の実施形態では無線端末２が１つ（ｎ＝１）である形態を説明する。なお無線端末２が２以上である形態は、第２の実施形態にて説明する。

【0015】

無線端末２は、屋内や屋外に設置され、無線端末２に搭載または接続される各種センサーの検出情報や、無線端末２に接続される電気機器などから収集した情報を、無線通信システム１Ａの上流（上位装置５側）に送信するものである。無線端末４は基地局３と無線により接続される。第１の実施形態では、無線端末２はＬｏＲａＷＡＮに規定される変調方式にて基地局３と接続されるものとする。なお無線端末２は、後述する本発明の動作を実行して無線通信システム１Ａに参加する。

【0016】

基地局３は、無線端末２から無線にて受信した各種情報をネットワークサーバ４へ中継する。基地局３はＬｏＲａＷＡＮに規定される変調方式にて無線端末２と接続される。また基地局３はネットワークサーバ４と接続される。基地局３とネットワークサーバ４との接続は、例えば既存のＥｔｈｅｒｎｅｔ規格（Ｅｔｈｅｒｎｅｔは登録商標）に従ったケーブルで接続される。有線で接続するにあたり、接続に用いる規格、方式は限定されない。また基地局３とネットワークサーバ４とを無線で接続してもよく、無線で接続するにあたり、接続に用いる規格、方式は限定されない。基地局３は、無線端末２とネットワークサーバ４との間で無線と有線の変換、情報中継の能力を備えていれば特定の装置に限定されないが、例えば無線端末２を基地局３の用途で使用して実現してもよい。以後の説明においては、基地局３の内部構成は図示せず、説明を省略する。

【0017】

ネットワークサーバ４は、基地局３から有線にて受信した無線端末２からの各種情報を、上位装置５へ中継する。またネットワークサーバ４は、後述する本発明の動作を実行して無線通信システム１Ａにおける無線端末２の参加を制御する。ネットワークサーバ４と上位装置５との接続は、例えば既存のＥｔｈｅｒｎｅｔ規格に従ったケーブルで接続され、接続に用いる規格、方式は限定されない。ネットワークサーバ４と上位装置５とを無線で接続してもよく、無線で接続するにあたり、接続に用いる規格、方式は限定されない。

【0018】

上位装置５は、ネットワークサーバ４から有線にて受信した無線端末２からの各種情報に基づいて各種の処理を実行するものである。上位装置５は例えばアプリケーションサーバである。例えば、アプリケーションサーバは無線端末２から送信された各種センサーの検出情報を蓄積し処理して、無線通信システム１Ａの利用者へ監視サービスを提供する。また他の例として、アプリケーションサーバは無線端末２から送信された電気機器などから収集した情報を蓄積し処理して、無線通信システム１Ａの利用者へエネルギー管理や遠隔検針サービスを提供する。

【0019】

図１において、各装置を結ぶ実線は有線による接続を示し、各装置を結ぶ点線は無線による接続を示す。上述のとおり無線端末２と基地局３は無線で接続され、またネットワークサーバ４と基地局３、および上位装置５とネットワークサーバ４は有線で接続される。ここで、ネットワークサーバ４と基地局３、および上位装置５とネットワークサーバ４は、上述のとおり、有線に限らず無線で接続するものであってもよい。

【0020】

（Ａ−２）無線端末２、ネットワークサーバ４の構成
（Ａ−２−１）無線端末２
図２は無線端末２の内部構成を示すブロック図である。図２において無線端末２は、制御部２１、記憶部２２、送信部２３、受信部２４、暗号化部２５、復号部２６、外部インタフェース２７、アンテナ２８を有する。

【0021】

制御部２１は無線端末２の動作を制御するものでありＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などにより実現される。制御部２１はさらに接続処理部２１１、一時保持部２１２、乱数発生部２１３、暗号鍵生成部２１４を有する。なお図２において以後の説明のため暗号化部２５と復号部２６を制御部２１の外部に設けているが、制御部２１が暗号化部２５と復号部２６を有していてもよい。図２において制御部２１は記憶部２２、暗号化部２５、復号部２６、外部インタフェース２７と接続される。

【0022】

接続処理部２１１は、無線端末２とネットワークサーバ４との間における接続処理を実行する。一時保持部２１２は、接続処理部２１１による接続処理に用いる情報を一時的に保持するものであり、例えばＣＰＵにおける小容量のキャッシュメモリ等で実現される。乱数発生部２１３は、接続処理部２１１による接続処理に用いる乱数を発生する。暗号鍵生成部２１４は、接続処理部２１１による接続処理を受けて、ネットワークサーバ４と共通である暗号鍵を生成する。これら接続処理部２１１、一時保持部２１２、乱数発生部２１３、暗号鍵生成部２１４の動作により、ネットワークサーバ４との間における接続処理が実行され、無線端末２においてネットワークサーバ４と共通である暗号鍵が生成される。制御部２１の動作の詳細は後述する。

【0023】

記憶部２２は、無線端末２を動作させるための動作プログラムを格納する主記憶装置、および無線端末２の動作における一次記憶装置である。記憶部２２は、主記憶装置としてＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフラッシュメモリなどの不揮発メモリーで実現され、一次記憶装置としてＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのメモリーで実現される。なお記憶部２２に格納される動作プログラムにおいて、後述する仮ＡｐｐＫｅｙが予め定義されている。これについては無線端末２の動作の詳細と合わせて後述する。

【0024】

送信部２３は、無線端末２から基地局３へ送信する各種情報を、無線通信のために送信処理する。送信部２３の送信処理は、ＬｏＲａＷＡＮに規定されるＬｏＲａ変調方式に従った各種情報の変調処理を含む。図２において送信部２３は暗号化部２５およびアンテナ２３と接続される。

【0025】

受信部２４は、基地局３からの各種情報を、無線端末２にて処理可能とするために受信処理する。受信部２４の受信処理は、ＬｏＲａＷＡＮに規定されるＬｏＲａ変調方式に従った各種情報の復調処理を含む。図２において受信部２４は復号部２６およびアンテナ２３と接続される。

【0026】

暗号化部２５は、無線端末２から基地局３へ送信する各種情報を、送信部２３の送信処理に先んじて暗号化する。暗号化部２５は、暗号鍵生成部２１４によって生成された、ネットワークサーバ４と共通の暗号鍵を用いて各種情報を暗号化する。なお暗号化部２５にて用いられる暗号化方式は限定されない。

【0027】

復号部２６は、受信部２４が受信処理した基地局３からの各種情報の暗号化を解除して復号する。復号部２６は、暗号鍵生成部２１４によって生成されたネットワークサーバ４と共通の暗号鍵、換言すると暗号化部２５が用いるものと同一の暗号鍵を用いて、各種情報を復号する。なお復号部２６にて用いられる暗号化方式は、暗号化部２５と同一である。

【0028】

外部インタフェース２７は、無線端末２と外部装置とを接続するインタフェースである。ここで外部装置は例えば各種センサー、電気機器などである。外部インタフェースは既存の規格に従ったものでよく、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）規格や、Ｅｔｈｅｒｎｅｔ規格に従ったアダプタである。

【0029】

アンテナ２８は、送信部２３および受信部２４と接続され、基地局３との間で電波の送受信を行う。

【0030】

請求項との対応関係において、無線端末２が通信端末に対応する。また無線端末２における各機能部と請求項とにおける対応関係は次のとおりである。接続処理部２１１は第一の接続処理手段および第二の接続処理手段に対応する。暗号鍵生成部２１４は第一の生成手段および第二の生成手段に対応する。乱数発生部２１３は第一の乱数発生手段に対応する。記憶部２２は第一の記憶手段に対応する。送信部２３および受信部２４は第一の通信手段に対応する。暗号化部２５は第一の暗号化手段に対応する。復号部２６は第一の復号手段に対応する。

【0031】

（Ａ−２−２）ネットワークサーバ４の構成
図３はネットワークサーバ４の内部構成を示すブロック図である。図３においてネットワークサーバ４は、制御部４１、記憶部４２、送信部４３、受信部４４、暗号化部４５、復号部４６、外部インタフェース４７、インタフェース４８を有する。

【0032】

制御部４１はネットワークサーバ４の動作を制御するものでありＣＰＵなどにより実現される。制御部４１はさらに接続処理部４１１、一時保持部４１２、乱数発生部４１３、暗号鍵生成部４１４を有する。なお図３において以後の説明のため暗号化部４５と復号部４６を制御部４１の外部に設けているが、制御部４１が暗号化部４５と復号部４６を有していてもよい。図３において制御部４１は記憶部４２、暗号化部４５、復号部４６、外部インタフェース４７と接続される。

【0033】

接続処理部４１１は、無線端末２を無線通信システム１Ａに参加させるために無線端末２との間で行う接続処理を実行する。一時保持部４１２は、接続処理部４１１による接続処理に用いる情報を一時的に保持するものであり、例えばＣＰＵにおける小容量のキャッシュメモリ等で実現される。乱数発生部４１３は、接続処理部４１１による接続処理に用いる乱数を発生する。暗号鍵生成部４１４は、接続処理部４１１による接続処理を受けて、無線端末２と共通である暗号鍵を生成する。これら接続処理部４１１、一時保持部４１２、乱数発生部４１３、暗号鍵生成部４１４の動作により、無線端末２との間における接続処理が実行され、ネットワークサーバ４において無線端末２と共通である暗号鍵が生成される。制御部４１の動作の詳細は後述する。

【0034】

記憶部４２は、ネットワークサーバ４を動作させるための動作プログラムを格納する主記憶装置、およびネットワークサーバ４の動作における一次記憶装置である。記憶部４２は、主記憶装置としてＨＤＤ（Ｈａｒｄ Ｄｉｓｃ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などで実現され、一次記憶装置としてＲＡＭなどのメモリーで実現される。なお記憶部４２に格納される動作プログラムにおいて、後述する仮ＡｐｐＫｅｙが予め定義されている。これについては制御部４１の動作の詳細と合わせて後述する。

【0035】

送信部４３は、ネットワークサーバ４から基地局３への各種情報を送信処理する。送信部２３の送信処理は、例えば情報のパケット化などである。図３において送信部４３は暗号化部４５およびインタフェース４８と接続される。

【0036】

受信部４４は、基地局３からの各種情報を、ネットワークサーバ４にて処理可能とするために受信処理する。受信部４４の受信処理は、例えばパケットからの情報抽出である。図３において受信部４４は復号部４６およびインタフェース４８と接続される。

【0037】

暗号化部４５は、ネットワークサーバ４から基地局３へ送信する各種情報を、送信部４３の送信処理に先んじて暗号化する。暗号化部４５は、暗号鍵生成部４１４によって生成された、無線端末２と共通の暗号鍵を用いて、各種情報を暗号化する。なお暗号化部４５にて用いられる暗号化方式は限定されない。

【0038】

復号部４６は、受信部４４が受信処理した基地局３からの各種情報の暗号化を解除して復号する。復号部４６は、暗号鍵生成部４１４によって生成された無線端末２と共通の暗号鍵、換言すると暗号化部４５が用いるものと同一の暗号鍵を用いて、各種情報を復号する。なお復号部４６にて用いられる暗号化方式は、暗号化部４５と同一である。

【0039】

外部インタフェース４７は、ネットワークサーバ４と上位装置５とを接続するインタフェースである。ここで上位装置５は、上述のとおり例えばアプリケーションサーバである。上位装置５の態様に合わせて外部インタフェース４７を適宜選択すればよく、上述のように上位装置５がアプリケーションサーバであれば、外部インタフェース４７を例えばＥｔｈｅｒｎｅｔ規格に従ったアダプタとすればよい。

【0040】

インタフェース４８は、送信部４３および受信部４４と接続され、ネットワークサーバ４と基地局３とを接続する例えばＥｔｈｅｒｎｅｔ規格に従ったアダプタである。

【0041】

請求項との対応関係において、ネットワークサーバ４がサーバに対応する。またネットワークサーバ４における各機能部と請求項とにおける対応関係は次のとおりである。接続処理部４１１は第三の接続処理手段および第四の接続処理手段に対応する。暗号鍵生成部４１４は第三の生成手段および第四の生成手段に対応する。乱数発生部４１３は第二の乱数発生手段に対応する。記憶部４２は第二の記憶手段に対応する。送信部４３および受信部４４は第二の通信手段に対応する。暗号化部４５は第二の暗号化手段に対応する。復号部４６は第二の復号手段に対応する。

ネットワークサーバ４における各機能部と第二の本発明とにおける対応関係は次の通りである。接続処理部４１１および暗号鍵生成部４１４は第一の処理部および第二の処理部に対応する。一時保持部４１２は記憶部に対応する。送信部４３は送信部に対応する。受信部４４は受信部に対応する。暗号化部４５は暗号化部に対応する。復号部４６は復号部に対応する。

【0042】

（Ｂ）動作
図４を参照して、第１の実施形態の動作において利用するＬｏＲａＷＡＮに規定される方式を説明する。図５および図６を参照して無線端末２とネットワークサーバ４との間における情報の授受、および暗号鍵生成の流れを説明する。図７および図８を参照して無線端末２およびネットワークサーバ４の動作の詳細を説明する。

【0043】

（Ｂ−１）ＬｏＲａＷＡＮにおける鍵生成の仕組み
図４はＬｏＲａＷＡＮにおける暗号鍵生成の基本的な仕組みを示す図である。第１の実施形態においては、図４に示す仕組みのうち、エンドデバイスとネットワークサーバとの間で共通の暗号鍵であるＡｐｐＳＫｅｙ（Ａｐｐｌｉｃａｔｉｏｎ ｓｅｓｓｉｏｎ ｋｅｙ）が生成される仕組みを利用する。なお第１の実施形態において無線端末２がエンドデバイスに相当し、ネットワークサーバ４がネットワークサーバに相当する。なお図４において、エンドデバイスとネットワークサーバのそれぞれにおける情報のうち点線で囲んだものは、本実施形態に関与しない情報であり、これらについては説明を省略する。またエンドデバイスとネットワークサーバのそれぞれにおいて二点鎖線で囲んだＮｗｋＳＫｅｙ（Ｎｅｔｗｏｒｋ ｓｅｓｓｉｏｎ ｋｅｙ）は、本実施形態に関与しないため説明を省略する。

【0044】

エンドデバイスとネットワークサーバは共通の情報であるＡｐｐＫｅｙ（Ａｐｐｌｉｃａｔｉｏｎ ｋｅｙ）９０が予め設定されている。ＡｐｐＫｅｙは、エンドデバイスとネットワークサーバを運用する作業者により設定されるものであり、ＡｐｐＫｅｙはＡｐｐＳｋｅｙを生成するための基（シード、ルート）になる情報である。一方でＡｐｐＳＫｅｙは、エンドデバイスとネットワークサーバのそれぞれでＡｐｐＫｅｙを基に生成され、エンドデバイスとネットワークサーバとの間で通信するユーザデータの暗号化および復号に用いられる。ＡｐｐＳＫｅｙはエンドデバイスとネットワークサーバとの接続が解消されるまで有効であり、エンドデバイスとネットワークサーバとの接続が解消された場合は、エンドデバイスとネットワークサーバとの接続が再度確立されると新たなＡｐｐＳＫｅｙが生成される。

【0045】

エンドデバイスはネットワークに参加するにあたり、ネットワークサーバへＪｏｉｎＲｅｑｕｅｓｔを送信する。このＪｏｉｎＲｅｑｕｅｓｔは少なくとも、エンドデバイス固有の識別子（アドレス）であるＤｅｖＥＵＩ（Ｅｎｄ−ｄｅｖｉｃｅ ｉｄｅｎｔｉｆｉｅｒ）９４と、エンドデバイスが発生させた乱数であるＤｅｖＮｏｎｃｅ９２を含む。

【0046】

ネットワークサーバはエンドデバイスからＪｏｉｎＲｅｑｕｅｓｔを受信すると、ＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＥＵＩ９４とＤｅｖＮｏｎｃｅ９２を抽出する。そしてＤｅｖＥＵＩ９４に基づいてエンドデバイスを識別し、当該ＪｏｉｎＲｅｑｕｅｓｔの送信元であるエンドデバイスに対応したＮｅｔＩＤ（Ｎｅｔｗｏｒｋ ｉｄｅｎｔｉｆｉｅｒ）９６を特定する。ＮｅｔＩＤはエンドデバイスがネットワークに参加するに当たり割り振られる識別子（アドレス）である。さらにネットワークサーバは、乱数を発生させこれをＡｐｐＮｏｎｃｅ９８とする。ネットワークサーバはエンドデバイスへ、少なくともＮｅｔＩＤ９６とＡｐｐＮｏｎｃｅ９８を含むＪｏｉｎＡｃｃｅｐｔを送信する。

【0047】

エンドデバイスはネットワークサーバからＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ９６とＡｐｐＮｏｎｃｅ９８を抽出する。そしてエンドデバイスは、ネットワークサーバと共通であるＡｐｐＫｅｙ９０、ネットワークサーバへ送信したＤｅｖＮｏｎｃｅ９２、ネットワークサーバから受信したＮｅｔＩＤ９６およびＡｐｐＮｏｎｃｅ９８を計算機に与え、ＡｐｐＳＫｅｙ９１０を生成する。なお計算機はネットワークサーバと共通の演算式を用いてＡｐｐＳＫｅｙを生成する。

【0048】

一方でネットワークサーバは、ＪｏｉｎＡｃｃｅｐｔを送信すると、エンドデバイスと同様にＡｐｐＳｋｅｙを生成する。つまりネットワークサーバは、エンドデバイスと共通であるＡｐｐＫｅｙ９０、エンドデバイスから受信したＤｅｖＮｏｎｃｅ９２、エンドデバイスへ送信したＮｅｔＩＤ９６およびＡｐｐＮｏｎｃｅ９８を計算機に与え、ＡｐｐＳＫｅｙ９１０を生成する。

【0049】

エンドデバイスとネットワークサーバがそれぞれＡｐｐＳＫｅｙを生成すると、エンドデバイスがネットワークに参加する状態となる。以後、エンドデバイスとネットワークサーバは、送受信するユーザデータを、ＡｐｐＳｋｅｙを用いて暗号化、復号して通信を行う。

【0050】

上記のように、ＬｏＲａＷＡＮにおいては、エンドデバイスとネットワークサーバがＪｏｉｎＲｅｑｕｅｓｔとＪｏｉｎＡｃｃｅｐｔの送受信により、ＤｅｖＮｏｎｃｅ、ＮｅｔＩＤ、ＡｐｐＮｏｎｃｅを取得して、ＡｐｐＳｋｅｙを生成する。第１の実施形態ではこの仕組みを利用する。ただし第１の実施形態ではＡｐｐＫｅｙの取り扱いが異なっている。

【0051】

（Ｂ−２）無線端末とネットワークサーバの間の情報授受と暗号鍵生成
次いで、図５および図６を参照して無線端末２とネットワークサーバ４との間における情報の授受、および暗号鍵生成の流れを説明する。図５は無線端末２とネットワークサーバ４とにおけるデータ送受信の流れを示すシーケンス図である。図６は無線端末２とネットワークサーバ４における各情報および暗号鍵の遷移を示す図である。なお図５では基地局３を省略している。また図５中の右側に付したアルファベットＡ〜Ｆは、図６中の（Ａ）〜（Ｆ）にそれぞれ対応する。

【0052】

上述したＬｏＲａＷＡＮの基本的な仕組みの前提と異なり、第１の実施形態における無線端末２は、無線通信システム１Ａを運用する作業者により予めＡｐｐＫｅｙが設定されていない。無線端末２は予めＡｐｐＫｅｙが設定されていない状態で起動する（Ｓ５１）。この時、無線端末２は自身のプログラムに定義される仮ＡｐｐＫｅｙを当該プログラムから読み出して自身に設定する。この仮ＡｐｐＫｅｙは作業者により設定されるものではなく、無線端末２のプログラムは作業者の干渉を受けないものである。またネットワークサーバ４では、無線通信システム１Ａに参加登録していない無線端末２に対して、無線端末２と同様に仮ＡｐｐＫｅｙを対応づけて予め記憶している。

【0053】

次いで無線端末２は、乱数を発生させてＤｅｖＮｏｎｃｅとし、ＤｖｅＮｏｎｃｅとＤｖｅＥＵＩを含むＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４へ送信する（Ｓ５２）。図５のＳ５２までの状態を図６（Ａ）に示す。図６（Ａ）では、無線端末２とネットワークサーバ４の双方に仮ＡｐｐＫｅｙ：α１が保持されており、無線端末２にＤｅｖＮｏｎｃｅ：ε１が保持されている。

【0054】

ネットワークサーバ４は無線端末２からＪｏｉｎＲｅｑｕｅｓｔを受信すると、ＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｖｅＥＵＩとＤｅｖＮｏｎｃｅを抽出する。ネットワークサーバ４はＤｅｖＥＵＩに基づき無線端末２に対応するＮｅｔＩＤを特定し、また乱数を発生させてＡｐｐＮｏｎｃｅとする。ネットワークサーバ４はＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２へ送信する（Ｓ５３）。図５のＳ５３までの状態を図６（Ｂ）に示す。図６（Ｂ）では、ネットワークサーバ４にＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＮｏｎｃｅ：ε１が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ１と、ＡｐｐＮｏｎｃｅ：ζ１が保持されている。

【0055】

無線端末２はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２は仮ＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ５５）。一方でネットワークサーバ４は、仮ＡｐｐＫｅｙ、無線端末２から受信したＤｖｅＮｏｎｃｅ、無線端末２へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ５６）。図５のＳ５４およびＳ５５までの状態を図６（Ｃ）に示す。図６（Ｃ）では、無線端末２にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ１とＡｐｐＮｏｎｃｅ：ζ１が保持されている。また無線端末２とネットワークサーバ４の双方に、仮ＡｐｐＫｅｙ：α１、ＮｅｔＩＤ：σ１、ＤｅｖＮｏｎｃｅ：ε１およびＡｐｐＮｏｎｃｅ：ζ１を用いて生成されたＡｐｐＫｅｙ：β１が保持されている。

【0056】

次いで無線端末２は、Ｓ５５で生成した正式ＡｐｐＫｅｙ（図６（Ｃ）のβ１）を保持した状態で再起動する（Ｓ５６）。無線端末２はこのＳ５６の再起動において、上述したＳ５１の起動時とは異なり、自身のプログラムから仮ＡｐｐＫｅｙを読み出さず、正式ＡｐｐＫｅｙを保持して起動する。無線端末２の再起動により、無線端末２とネットワークサーバ４の接続は解消される。この時、ネットワークサーバ４では、無線端末２に対応してＳ５４で生成した正式ＡｐｐＫｅｙ（図６（Ｃ）のβ１）を保持し、その他情報は接続の解消に伴い消去する。

【0057】

次いで無線端末２は、乱数を発生させてＤｅｖＮｏｎｃｅとし、ＤｖｅＮｏｎｃｅとＤｖｅＥＵＩを含むＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４へ送信する（Ｓ５７）。図５のＳ５７までの状態を図６（Ｄ）に示す。図６（Ｄ）では、無線端末２とネットワークサーバ４の双方にＡｐｐＫｅｙ：β１が保持されており、無線端末２にＤｅｖＮｏｎｃｅ：ε２が保持されている。なお図６（Ａ）で保持されていた仮ＡｐｐＫｅｙ：α１は無線端末２の再起動および接続の解消により図６（Ｄ）では消去されており、またＤｅｖＮｏｎｃｅは乱数であるから、図６（Ｄ）のＤｅｖＮｏｎｃｅ：ε２は図６（Ａ）のＤｅｖＮｏｎｃｅ：ε１と異なる値である。

【0058】

ネットワークサーバ４は無線端末２からＪｏｉｎＲｅｑｕｅｓｔを受信すると、ＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｖｅＥＵＩとＤｅｖＮｏｎｃｅを抽出する。ネットワークサーバ４はＤｅｖＥＵＩに基づき無線端末２に対応するＮｅｔＩＤを特定し、乱数を発生させてＡｐｐＮｏｎｃｅとする。ネットワークサーバ４はＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２へ送信する（Ｓ５８）。図５のＳ５８までの状態を図６（Ｅ）に示す。図６（Ｅ）では、ネットワークサーバ４にＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＮｏｎｃｅ：ε２が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ１と、ＡｐｐＮｏｎｃｅ：ζ２が保持されている。なおＮｅｔＩＤは無線端末２に固有の識別子であるから、図６（Ｂ）と同じくＮｅｔＩＤ：σ１であり、またＡｐｐＮｏｎｃｅは乱数であるから、図６（Ｅ）のＡｐｐＮｏｎｃｅ：ζ２は図６（Ｂ）のＡｐｐＮｏｎｃｅ：ζ１と異なる値である。

【0059】

無線端末２はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２はＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ５１０）。一方でネットワークサーバ４は、ＡｐｐＫｅｙ、無線端末２から受信したＤｖｅＮｏｎｃｅ、無線端末２へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ５９）。図５のＳ５９およびＳ５１０までの状態を図６（Ｆ）に示す。図６（Ｆ）では、無線端末２にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ１とＡｐｐＮｏｎｃｅ：ζ２が保持されている。また無線端末２とネットワークサーバ４の双方に、ＡｐｐＫｅｙ：β１、ＮｅｔＩＤ：σ１、ＤｅｖＮｏｎｃｅ：ε２およびＡｐｐＮｏｎｃｅ：ζ２を用いて生成されたＡｐｐＳＫｅｙ：γ１が保持されている。なおＤｅｖＮｏｎｃｅ：ε２およびＡｐｐＮｏｎｃｅ：ζ２は乱数であるから、それぞれは、図６（Ｃ）のＤｅｖＮｏｎｃｅ：ε１およびＡｐｐＮｏｎｃｅ：ζ１と異なる値である。従って、ＤｅｖＮｏｎｃｅ：ε２およびＡｐｐＮｏｎｃｅ：ζ２を用いて生成されるＡｐｐＳＫｅｙ：γ１は、ＡｐｐＫｅｙ：β１と異なる値である。

【0060】

無線端末２とネットワークサーバ４は、各々でＡｐｐＳｋｅｙ（図６（Ｆ）のγ１）が生成されると、当該ＡｐｐＳＫｅｙを用いてユーザデータを暗号化、復号する通常運用へ以降する（Ｓ５１１）。ＡｐｐＳＫｅｙは無線端末２とネットワークサーバ４との接続が解消されるまで有効であるから、無線端末２とネットワークサーバ４との接続が解消された場合は、Ｓ５１からＳ５１０までの動作が実行され、Ｓ５２からＳ５５（図６（Ａ）〜（Ｃ））のフェーズ１で新たなＡｐｐＫｅｙが生成され、Ｓ５６からＳ５１０（図６（Ｄ）〜（Ｆ））のフェーズ２で新たなＡｐｐＳｋｅｙが生成される。

【0061】

なお第一の本発明および第二の本発明との対応関係において、上述した仮ＡｐｐＫｅｙは第一の情報に対応し、正式ＡｐｐＫｅｙは第二の情報に対応し、ＡｐｐＳＫｅｙは暗号鍵に対応する。

【0062】

（Ｂ−３）無線端末の動作フロー
図５および図６を参照して説明した無線端末とネットワークサーバの間の情報授受と暗号鍵生成について、無線端末２に着目しその動作の詳細を説明する。図７は無線端末２の動作を示すフローチャートである。

【0063】

無線端末２が起動すると、制御部２１は記憶部２２からＡｐｐＫｅｙの読出しを試みる（Ｓ７００）。そして記憶部２２にＡｐｐＫｅｙが保持されているかを判定する（Ｓ７０２）。上述のとおり、無線端末２は予めＡｐｐＫｅｙが設定されていない状態で起動するため、記憶部２２にＡｐｐＫｅｙは保持されていない。従って判定は否定される（Ｓ７０２：Ｎｏ）。

【0064】

Ｓ７０２の判定が否定されると、制御部２１は記憶部２２に格納される動作プログラムに定義される仮ＡｐｐＫｅｙ（図６（Ａ）のα１）を動作プログラムから読み出し、一時保持部２１２に保持する（Ｓ７０４）。この仮ＡｐｐＫｅｙは動作プログラムにて定義されるため、無線通信システム１Ａを運用する作業者は干渉できず、従って作業者は仮ＡｐｐＫｅｙを知ることはできない。

【0065】

制御部２１は記憶部２２からＤｅｖＥＵＩを読み出して（図示せず）一時保持部２１２に保持する（Ｓ７０８）。また制御部２１は乱数発生部２１３に乱数を発生させこれをＤｅｖＮｏｎｃｅ（図６（Ａ）のε１）とし一時保持部２１２に保持する（Ｓ７１０）。

【0066】

制御部２１は接続処理部２１１に、ＤｅｖＥＵＩおよびＤｅｖＮｏｎｃｅを含むＪｏｉｎＲｅｑｕｅｓｔコマンドを作成させる（Ｓ７１２）。ＪｏｉｎＲｅｑｕｅｓｔコマンドの作成は、例えばＬｏＲａＷＡＮにて規定される方式を用いてもよい。接続処理部２１１によりＪｏｉｎＲｅｑｕｅｓｔコマンドが作成されると、制御部２１は送信部２３を介してＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４へ送信する（Ｓ７１４）。なおＪｏｉｎＲｅｑｕｅｓｔを暗号化部２５で暗号化してもよい。暗号化部２５でＪｏｉｎＲｅｑｕｅｓｔを暗号化する場合は、例えば仮ＡｐｐＫｅｙを用いて暗号化してもよい。

【0067】

送信部２３を介してＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４に送信すると、無線端末２はネットワークサーバからのＪｏｉｎＡｃｃｅｐｔの受信を待機する（Ｓ７１６）。

【0068】

無線端末２がネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると（Ｓ７１６：Ｙｅｓ）、制御部２１は受信したＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ（図６（Ｃ）のδ１）とＡｐｐＮｏｎｃｅ（図６（Ｃ）のζ１）を抽出し、一時保持部２１２に保持する（Ｓ７１８）。

【0069】

次いで制御部２１は、暗号鍵生成部２１４に、一時保持部２１２に保持された仮ＡｐｐＫｅｙ（図６（Ｃ）のα１）、ＤｅｖＮｏｎｃｅ（図６（Ｃ）のε１）、ＮｅｔＩＤ（図６（Ｃ）のδ１）およびＡｐｐＮｏｎｃｅ（図６（Ｃ）のζ１）を用いて暗号鍵を生成させる（Ｓ７２０）。

【0070】

制御部２１は暗号鍵が生成されると、記憶部２２にＡｐｐＫｅｙが保持されているかを再度判定する（Ｓ７２２）。Ｓ７２２の判定は上述したＳ７０２の判定と同様である。ここで、記憶部２２にＡｐｐＫｅｙは保持されていなので、判定は否定される（Ｓ７２２：Ｎｏ）。

【0071】

Ｓ７２２の判定が否定されると、制御部２１は、Ｓ７２０にて生成された暗号鍵を正式なＡｐｐＫｅｙ（図６（Ｃ）のβ１）として記憶部２２に保持する（Ｓ７２４）。

【0072】

次いで制御部２１は、ＡｐｐＫｅｙを記憶部２２に保持した状態で、無線端末２を再起動する（Ｓ７２６）。この再起動は、無線端末２の電源を一旦遮断して再度投入するハードリセットでもよいし、無線端末２の電源を維持したままソフトウェアを再起動するソフトリセットでもよい。無線端末２が再起動すると、処理は図７に示すフローチャートの先頭（図７に丸囲みのＡで図示）に戻る。

【0073】

無線端末２が再起動すると、制御部２１は記憶部２２からＡｐｐＫｅｙの読出しを試みる（Ｓ７００）。そして記憶部２２にＡｐｐＫｅｙが保持されているかを判定する（Ｓ７０２）。ここでは、記憶部２２にＡｐｐＫｅｙ（図６（Ｄ）のβ１）が保持されているので、判定は肯定される（Ｓ７０２：Ｙｅｓ）。

【0074】

Ｓ７０２の判定が肯定されると、制御部２１は記憶部２２に保持されるＡｐｐＫｅｙ（図６（Ｄ）のβ１）を一時保持部２１２に保持する（Ｓ７０６）。

【0075】

以降、制御部２１、乱数発生部２１３、暗号鍵生成部２１４の動作は、上述したＳ７０８からＳ７２０までにおける動作と同様である。ただし、図７のフローの２週目において、乱数発生部２１３が発生する乱数は図６（Ｄ）のＤｅｖＮｏｎｃｃｅ：ε２であり、ネットワークサーバ４から受信するＪｏｉｎＡｃｃｅｐｔには図６（Ｅ）のＮｅｔＩＤ：δ１とＡｐｐＮｏｎｃｅ：ζ２が含まれ、暗号鍵生成部２１４は図６（Ｆ）のＡｐｐＫｅｙ；β１、ＤｅｖＮｏｎｃｅ：ε２、ＮｅｔＩＤ：δ１およびＡｐｐＮｏｎｃｅ：ζ２を用いて暗号鍵を生成する。

【0076】

制御部２１は暗号鍵が生成されると、記憶部２２にＡｐｐＫｅｙが保持されているかを再度判定する（Ｓ７２２）。Ｓ７２２の判定は上述したＳ７０２の判定と同様である。ここで、記憶部２２にＡｐｐＫｅｙ：β１が保持されているので、判定は肯定される（Ｓ７２２：Ｙｅｓ）。

【0077】

Ｓ７２２の判定が肯定されると、制御部２１は、Ｓ７２０にて生成された暗号鍵をＡｐｐＳＫｅｙ（図６（Ｆ）のγ１）として記憶部２２に保持する（Ｓ７２８）。

【0078】

以降、無線端末２は、記憶部２２に保持したＡｐｐＳＫｅｙ（図６（Ｆ）のγ１）を暗号鍵に用いて、ネットワークサーバ４との通信を行う通用運用へ移行する（Ｓ７３０）。通常運用において、無線端末２からネットワークサーバ４へ送信されるデータは暗号化部２５によりＡｐｐＳＫｅｙを用いて暗号化される。また通常運用において、ネットワークサーバ４から受信されるデータは復号部２６によりＡｐｐＳＫｅｙを用いて復号される。

【0079】

（Ｂ−４）ネットワークサーバの動作フロー
図５および図６を参照して説明した無線端末とネットワークサーバの間の情報授受と暗号鍵生成について、ネットワークサーバ４に着目しその動作の詳細を説明する。図８はネットワークサーバ４の動作を示すフローチャートである。

【0080】

ネットワークサーバ４は無線端末２からのＪｏｉｎＲｅｑｕｅｓｔの受信を待機する（Ｓ８００）。

【0081】

ネットワークサーバ４の制御部４１（図３）は、無線端末２からＪｏｉｎＲｅｑｕｅｓｔを受信すると（Ｓ８００：Ｙｅｓ）、当該ＪｏｉｎＲｅｑｕｅｓｔの送信元である無線端末２に対応するＡｐｐＫｅｙが記憶部４２に保持されているか判定する（Ｓ８０２）。ここで、記憶部４２には無線端末２に対応するＡｐｐＫｅｙは保持されていないので（図６（Ａ））、判定は否定される（Ｓ８０２：Ｎｏ）。なお無線端末２の特定はＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＥＵＩを用いる。

【0082】

Ｓ８０２の判定が否定されると、制御部４１は記憶部４２に格納される動作プログラムに定義される仮ＡｐｐＫｅｙ（図６（Ａ）のα１）を動作プログラムから読み出し、一時保持部４１２に保持する（Ｓ８０４）。この仮ＡｐｐＫｅｙは、無線端末２と同様に動作プログラムにて定義される。

【0083】

次いで制御部４１は、受信したＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＥＵＩ（図示せず）に基づいて無線端末２を特定し、無線端末２に対応するＮｅｔＩＤ（図６（Ｂ）のδ１）を記憶部４２から読み出し、一時保持部４１２に保持する（Ｓ８０８）。また制御部４１は、乱数発生部４１３に乱数を発生させこれをＡｐｐＮｏｎｃｅ（図６（Ｂ）のζ１）とし一時保持部２１２に保持する（Ｓ８１０）。

【0084】

制御部４１は接続処理部４１１に、ＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔコマンドを作成させる（Ｓ８１２）。ＪｏｉｎＡｃｃｅｐｔコマンドの作成は、例えばＬｏＲａＷＡＮにて規定される方式を用いてもよい。接続処理部４１１によりＪｏｉｎＡｃｃｅｐｔコマンドが作成されると、制御部４１は送信部４３を介してＪｏｉｎＡｃｃｅｐｔを無線端末２へ送信する（Ｓ８１４）。なおＪｏｉｎＡｃｃｅｐｔを暗号化部４５で暗号化してもよい。暗号化部４５でＪｏｉｎＡｃｃｅｐｔを暗号化する場合は、例えば仮ＡｐｐＫｅｙを用いて暗号化してもよい。

【0085】

次いで制御部４１は、無線端末２から受信したＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＮｏｎｃｅ（図６（Ｂ）のε１）を抽出し、一時期億部４１２に保持する（Ｓ８１６）。なおＳ８１６の処理は、無線端末２からＪｏｉｎＲｅｑｕｅｓｔを受信した時点（Ｓ８００：Ｙｅｓ）から、無線端末２へＪｏｉｎＡｃｃｅｐｔを送信する時点（Ｓ８１４）までの任意のタイミングで行われてもよい。図８においては、説明のため便宜的にＳ８１６の処理をＳ８１４の処理の後としている。

【0086】

次いで制御部４１は、暗号鍵生成部４１４に、一時保持部４１２に保持された仮ＡｐｐＫｅｙ（図６（Ｃ）のα１）、ＤｅｖＮｏｎｃｅ（図６（Ｃ）のε１）、ＮｅｔＩＤ（図６（Ｃ）のδ１）およびＡｐｐＮｏｎｃｅ（図６（Ｃ）のζ１）を用いて暗号鍵を生成させる（Ｓ８１８）。

【0087】

制御部４１は暗号鍵が生成されると、記憶部４２に当該無線端末２に対応するＡｐｐＫｅｙが保持されているかを再度判定する（Ｓ８２０）。Ｓ８２０の判定は上述したＳ８０２の判定と同様である。ここで、記憶部４２に、当該無線端末２に対応するＡｐｐＫｅｙは保持されていなので、判定は否定される（Ｓ８２０：Ｎｏ）。

【0088】

Ｓ８２０の判定が否定されると、制御部４１は、Ｓ８１８にて生成された暗号鍵を正式なＡｐｐＫｅｙ（図６（Ｃ）のβ１）として記憶部４２に保持する（Ｓ８２２）。

【0089】

次いでネットワークサーバ４の処理は、図８に示すフローチャートの先頭（図８に丸囲みのＡで図示）に戻り、ネットワークサーバ４は当該無線端末２からのＪｏｉｎＲｅｑｕｅｓｔの受信を待機する（Ｓ８００）。

【0090】

制御部４１は、当該無線端末２からＪｏｉｎＲｅｑｕｅｓｔを受信すると（Ｓ８００：Ｙｅｓ）、当該ＪｏｉｎＲｅｑｕｅｓｔの送信元である無線端末２に対応するＡｐｐＫｅｙが記憶部４２に保持されているか判定する（Ｓ８０２）。ここで、記憶部４２には無線端末２に対応するＡｐｐＫｅｙ：β１が保持されるので（図６（Ｄ））、判定は肯定される（Ｓ８０２：Ｙｅｓ）。なお無線端末２の特定はＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｅｖＥＵＩを用いる。

【0091】

Ｓ８０２の判定が肯定されると、制御部４１は記憶部４２に保持されるＡｐｐＫｅｙ（図６（Ｄ）のβ１）を一時保持部４１２に保持する（Ｓ８０６）。

【0092】

以降、制御部４１、乱数発生部４１３、暗号鍵生成部４１４の動作は、上述したＳ８０８からＳ８１８までにおける動作と同様である。ただし、図８のフローの２週目において、ネットワークサーバ４から無線端末２へ送信されるＪｏｉｎＡｃｃｅｐｔには、乱数発生部４１３が発生する乱数として図６（Ｅ）のＡｐｐＮｏｎｃｃｅ：ζ２が含まれ、当該無線端末２に対応するＮｅｔＩＤ：δ１（図６（Ｅ））が含まれる。また無線端末２から受信するＪｏｉｎＲｅｑｕｅｓｔには図６（Ｅ）のＤｅｖＮｏｎｃｅ：ε２が含まれる。そして暗号鍵生成部４１４は図６（Ｆ）のＡｐｐＫｅｙ；β１、ＤｅｖＮｏｎｃｅ：ε２、ＮｅｔＩＤ：δ１およびＡｐｐＮｏｎｃｅ：ζ２を用いて暗号鍵を生成する。

【0093】

制御部４１は暗号鍵が生成されると、記憶部４２にＡｐｐＫｅｙが保持されているかを再度判定する（Ｓ８２０）。Ｓ８２０の判定は上述したＳ８０２の判定と同様である。ここで、記憶部４２にＡｐｐＫｅｙ：β１が保持されているので、判定は肯定される（Ｓ８２０：Ｙｅｓ）。

【0094】

Ｓ８２０の判定が肯定されると、制御部４１は、Ｓ８１８にて生成された暗号鍵をＡｐｐＳＫｅｙ（図６（Ｆ）のγ１）として記憶部４２に保持する（Ｓ８２４）。

【0095】

以降、ネットワークサーバ４は、記憶部４２に保持したＡｐｐＳＫｅｙ（図６（Ｆ）のγ１）を暗号鍵に用いて、当該無線端末２との通信を行う通用運用へ移行する（Ｓ８２６）。通常運用において、ネットワークサーバ４から送信されるデータは暗号化部４５によりＡｐｐＳＫｅｙを用いて暗号化される。無線端末２から受信されるデータは復号部４６によりＡｐｐＳＫｅｙを用いて復号される。

【0096】

（Ｃ）第１の実施形態における効果
上述した第１の実施形態によれば、無線端末２に予めＡｐｐＫｅｙを保持させる必要が無い。従前では作業者が無線端末２の設置時に、無線端末２にＡｐｐＫｅｙを保持させる必要があったため、作業者からＡｐｐＫｅｙが漏洩するおそれがあった。一方で第１の実施形態では、上述のとおり、無線端末２はＡｐｐＫｅｙが設定されていない状態で起動し、無線端末２は自身のプログラムに定義される仮ＡｐｐＫｅｙ（図６のα１）を当該プログラムから読み出して自身に設定する。無線端末２のプログラムは無線端末２を設置する作業者の干渉を受けないものであるから、第１の実施形態において仮ＡｐｐＫｅｙが作業者を含めた第三者に漏洩する可能性は低く、第１の実施形態は従前に比べてＡｐｐＫｅｙ管理の点でセキュリティが向上している。

【0097】

また第１の実施形態では、無線端末２とネットワークサーバ４の双方は、仮ＡｐｐＫｅｙ（図６のα１）を用いて正式なＡｐｐＫｅｙ（図６のβ１）を装置内部で生成し、更に正式なＡｐｐＫｅｙ（図６のβ１）を用いてＡｐｐＳＫｅｙ（図６のγ１）を装置内部で生成し、当該ＡｐｐＳＫｅｙ（図６のγ１）を用いて通信の暗号化を行う。上述のとおり仮ＡｐｐＫｅｙは第三者に漏洩しにくいものであるから、正式なＡｐｐＫｅｙおよびＡｐｐＳＫｅｙは更に漏洩、解析されにくいものであり、第１の実施形態は従前に比べＡｐｐＳＫｅｙ管理の点でもセキュリティが向上している。

【0098】

さらに第１の実施形態では、上述のとおりＡｐｐＫｅｙ管理の点および、ＡｐｐＳＫｅｙ管理の点でセキュリティ向上を実現しているが、無線通信システム１Ａで用いられる暗号化方式は共通鍵暗号方式である。第１の実施形態は、無線端末２の消費電力増大、ハードウェア高度化を招く公開鍵暗号方式を用いていない。従って第１の実施形態は、共通鍵暗号方式を用い、ＬＰＷＡの無線通信システムの利点である無線端末２の低消費電力性、低経済コストを損なわずに、従前に比べセキュリティが向上した無線通信システム１Ａを実現している。

【0099】

（２）第２の実施形態
本発明の第２の実施形態を、図９から図１１を参照して説明する。第１の実施形態ではネットワークサーバ４に１つの無線端末２が接続される場合の構成と動作を説明したが、第２の実施形態ではネットワークサーバ４に複数の無線端末２が接続される場合の構成と動作を説明する。また第２の実施形態でも、図４に示すＬｏＲａＷＡＮに規定されるＡｐｐＳｋｅｙ生成の仕組みを利用する。なお以下の説明では、第１の実施形態と同一である構成、動作については図１から図８のそれぞれを適宜参照して説明したり、説明の一部を省略したりすることがある。

【0100】

（Ｄ）ハードウェア
（Ｄ−１）無線通信システムの全体構成
図９は、第２の実施形態における無線通信システム１Ｂの全体構成を示す構成図である。図９において、無線通信システム１Ｂは、複数の無線端末２−１〜２−ｎ（ｎは２以上の整数）、基地局３、ネットワークサーバ４、上位装置５を含む。

【0101】

各無線端末２−１〜２−ｎ、基地局３、ネットワークサーバ４および上位装置５それぞれの機能、役割は、第１の実施形態にて説明したものと同様である。図９における接続関係については、無線端末２−１〜２−ｎのそれぞれが、基地局３とＬｏＲａＷＡＮに規定される変調方式にて無線接続される。即ち第２の実施形態では、基地局３と無線端末２−１〜２−ｎが１対ｎで接続される。

【0102】

（Ｄ−２）無線端末２−１〜２−ｎ、ネットワークサーバ４の構成
（Ｄ−２−１）無線端末２−１〜２−ｎ
第２の実施形態における無線端末２−１〜２−ｎの内部構成は、第１の実施形態における無線端末２の内部構成（図２）と同様である。

【0103】

（Ｄ−２−２）ネットワークサーバ４の構成

【0104】

第２の実施形態におけるネットワークサーバ４の内部構成は、第１の実施形態におけるネットワークサーバ４の内部構成（図３）と同様である。ただしネットワークサーバ４の記憶部４２は、複数の無線端末２−１〜２−ｎのそれぞれに対して各種情報を記憶可能なように論理構造が設けられている（図示せず）。

【0105】

（Ｅ）動作
図１０および図１１を参照して、複数の無線端末２−１〜２−ｎとネットワークサーバ４との間における情報の授受、および暗号鍵生成の流れを説明する。なお第２の実施形態においても、ネットワークサーバ４と１台の無線端末２との間では、図４を用いて説明したＬｏＲａＷＡＮに規定される暗号鍵生成方式を利用する。また以後の説明では、複数の無線端末２−１〜２−ｎのうち、無線端末２−１と無線端末２−２の２台を代表として説明する。

【0106】

（Ｅ−１）複数の無線端末とネットワークサーバ間の情報授受と暗号鍵生成
図１０は無線端末２−１ 、無線端末２−２およびネットワークサーバ４におけるデータ送受信の流れを示すシーケンス図である。図１１は無線端末２−１、無線端末２−２とネットワークサーバ４における各情報の遷移を示す図である。なお図１０では基地局３を省略している。また図１０中の右側に付したアルファベットＡ〜Ｆは、図１１中の（Ａ）〜（Ｆ）にそれぞれ対応する。

【0107】

第２の実施形態において、無線端末２−１と無線端末２−２は同期して動作するものではない。従って各無線端末２とネットワークサーバ４との間における通信は適宜のタイミングで行われ、無線端末２−１、無線端末２−２およびネットワークサーバ４の内部における処理も、適宜のタイミングで行われる。図１０にでは説明のため便宜的に、無線端末２−１と無線端末２−２の通信タイミングと処理タイミングに前後関係を設けているが、各処理のタイミングの前後関係は図１０に限定されるものではない。

【0108】

図１０において、無線端末２−１、無線端末２−２のそれぞれについての、ネットワークサーバ４との間における情報の授受および暗号鍵生成の流れは、第１の実施形態にて図５、図６を用いて説明したものと同じである。但し、ネットワークサーバ４では、無線端末２−１と無線端末２−２のそれぞれに対してＡｐｐＫｅｙ、ＡｐｐＳＫｅｙ、ＮｅｔＩＤ、ＤｅｖＮｏｎｃｅ、ＡｐｐＮｏｎｃｅの生成と管理を行う。

【0109】

無線端末２−１および無線端末２−２は、無線通信システム１Ｂを運用する作業者により予めＡｐｐＫｅｙが設定されていない。無線端末２−１および無線端末２−２は予めＡｐｐＫｅｙが設定されていない状態で起動する（Ｓ１００、Ｓ１０２）。この時、無線端末２−１および無線端末２−２は自身のプログラムに定義される仮ＡｐｐＫｅｙを当該プログラムから読み出して自身に設定する。なお無線端末２−１および無線端末２−２に搭載されるプログラムには、同一の仮ＡｐｐＫｅｙを定義する。無線端末２の数が２以上のｎ台であっても同様に、無線端末２−１〜２−ｎのプログラムに同一の仮ＡｐｐＫｅｙを定義する。一方でネットワークサーバ４では、無線通信システム１Ｂに参加登録していない無線端末２−１と無線端末２−２のそれぞれに対し一律に、同一の仮ＡｐｐＫｅｙを記憶している。

【0110】

次いで無線端末２−１および無線端末２−２はそれぞれ、乱数を発生させてＤｅｖＮｏｎｃｅとし、ＤｅｖＮｏｎｃｅＥＵＩを含むＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４へ送信する（Ｓ１０４、Ｓ１０６）。図１０のＳ１０６までの状態を図１１（Ａ）に示す。図１１（Ａ）では、無線端末２−１とネットワークサーバ４の双方に仮ＡｐｐＫｅｙ：α１が保持されており、無線端末２−２とネットワークサーバ４の双方に仮ＡｐｐＫｅｙ：α１が保持されている。また無線端末２−１にＤｅｖＮｏｎｃｅ：ε１が保持されており、無線端末２−２にＤｅｖＮｏｎｃｅ：ε２が保持されている。ＤｅｖＮｏｎｃｅは乱数であるから、ε１とε２は関連の無い異なった値である。

【0111】

ネットワークサーバ４は無線端末２−１からＪｏｉｎＲｅｑｕｅｓｔを受信すると、ＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｖｅＥＵＩとＤｅｖＮｏｎｃｅを抽出する。ネットワークサーバ４はＤｅｖＥＵＩに基づき無線端末２−１に対応するＮｅｔＩＤを特定し、乱数を発生させてＡｐｐＮｏｎｃｅとする。ネットワークサーバ４はＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２−１へ送信する（Ｓ１０８）。またネットワークサーバ４は無線端末２−２に対しても同様に、ＤｅｖＥＵＩに基づき無線端末２−２に対応するＮｅｔＩＤを特定し、乱数を発生させてＡｐｐＮｏｎｃｅとし、ＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２−２へ送信する（Ｓ１０１０）。図１０のＳ１０１０までの状態を図１１（Ｂ）に示す。図１１（Ｂ）では、ネットワークサーバ４に無線端末２−１に対応付けてＤｅｖＮｏｎｃｅ：ε１が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ１と、ＡｐｐＮｏｎｃｅ：ζ１が保持されている。またネットワークサーバ４に無線端末２−２に対応付けてＤｅｖＮｏｎｃｅ：ε２が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ２と、ＡｐｐＮｏｎｃｅ：ζ２が保持されている。ここでＡｐｐＮｏｎｃｅは乱数であるから、ζ１とζ２は関連の無い異なった値である。

【0112】

無線端末２−１はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２−１は仮ＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ１０１４）。一方でネットワークサーバ４は、仮ＡｐｐＫｅｙ、無線端末２−１から受信したＤｖｅＮｏｎｃｅ、無線端末２−１へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ１０１２）。

【0113】

無線端末２−２はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２−２は仮ＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ１０１８）。一方でネットワークサーバ４は、仮ＡｐｐＫｅｙ、無線端末２−２から受信したＤｖｅＮｏｎｃｅ、無線端末２−２へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これを正式ＡｐｐＫｅｙとする（Ｓ１０１６）。

【0114】

図１０のＳ１０１２からＳ１０１８までの状態を図１１（Ｃ）に示す。図１１（Ｃ）では、無線端末２−１にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ１とＡｐｐＮｏｎｃｅ：ζ１が保持されており、無線端末２−１とネットワークサーバ４の双方に、仮ＡｐｐＫｅｙ：α１、ＮｅｔＩＤ：σ１、ＤｅｖＮｏｎｃｅ：ε１およびＡｐｐＮｏｎｃｅ：ζ１を用いて生成されたＡｐｐＫｅｙ：β１が保持されている。また図１１（Ｃ）では、無線端末２−２にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ２とＡｐｐＮｏｎｃｅ：ζ２が保持されており、無線端末２−２とネットワークサーバ４の双方に、仮ＡｐｐＫｅｙ：α１、ＮｅｔＩＤ：σ２、ＤｅｖＮｏｎｃｅ：ε２およびＡｐｐＮｏｎｃｅ：ζ２を用いて生成されたＡｐｐＫｅｙ：β２が保持されている。ここで、無線端末２−１に対するＡｐｐＫｅｙ：β１と無線端末２−２に対するＡｐｐＫｅｙ：β２は、それぞれ異なるＮｅｔＩＤおよび乱数値（ＤｅｖＮｏｎｃｅ、ＡｐｐＮｏｎｃｅ）に基づき生成されるので、β１とβ２は関連の無い異なる値である。

【0115】

次いで無線端末２−１は、Ｓ１０１４で生成した正式ＡｐｐＫｅｙ（図１１（Ｃ）のβ１）を保持した状態で再起動する（Ｓ１０２０）。無線端末２はこの再起動において、上述したＳ１００の起動時とは異なり、自身のプログラムから仮ＡｐｐＫｅｙを読み出さず、正式ＡｐｐＫｅｙを保持して起動する。無線端末２−１の再起動により、無線端末２−１とネットワークサーバ４の接続は解消される。この時、ネットワークサーバ４では、無線端末２−１に対応してＳ１０１２で生成した正式ＡｐｐＫｅｙ（図１１（Ｃ）のβ１）を保持し、その他情報は接続の解消に伴い消去する。

【0116】

無線端末２−２も同様に、Ｓ１０１８で生成した正式ＡｐｐＫｅｙ（図１１（Ｃ）のβ２）を保持した状態で再起動する（Ｓ１０２２）。無線端末２−２はこの再起動において、上述したＳ１０２の起動時とは異なり、自身のプログラムから仮ＡｐｐＫｅｙを読み出さず、正式ＡｐｐＫｅｙを保持して起動する。無線端末２−２の再起動により、無線端末２−２とネットワークサーバ４の接続は解消される。この時、ネットワークサーバ４では、無線端末２−２に対応してＳ１０１６で生成した正式ＡｐｐＫｅｙ（図１１（Ｃ）のβ２）を保持し、その他情報は接続の解消に伴い消去する。

【0117】

次いで無線端末２−１および無線端末２−２はそれぞれ、乱数を発生させてＤｅｖＮｏｎｃｅとし、ＤｅｖＮｏｎｃｅＥＵＩを含むＪｏｉｎＲｅｑｕｅｓｔをネットワークサーバ４へ送信する（Ｓ１０２４、Ｓ１０２６）。図１０のＳ１０２６までの状態を図１１（Ｄ）に示す。図１１（Ｄ）では、無線端末２−１とネットワークサーバ４の双方にＡｐｐＫｅｙ：β１が保持されており、無線端末２−１にＤｅｖＮｏｎｃｅ：ε３が保持されている。なお図１１（Ａ）で保持されていた仮ＡｐｐＫｅｙ：α１は無線端末２−１の再起動および接続の解消により、図１１（Ｄ）では消去されている。また図１１（Ｄ）では、無線端末２−２とネットワークサーバ４の双方にＡｐｐＫｅｙ：β２が保持されており、無線端末２−２にＤｅｖＮｏｎｃｅ：ε４が保持されている。なお図１１（Ａ）で保持されていた仮ＡｐｐＫｅｙ：α１は無線端末２−２の再起動および接続の解消により、図１１（Ｄ）では消去されている。ＤｅｖＮｏｎｃｅは乱数であるから、ε３とε４は関連の無い異なった値である。

【0118】

ネットワークサーバ４は無線端末２−１からＪｏｉｎＲｅｑｕｅｓｔを受信すると、ＪｏｉｎＲｅｑｕｅｓｔに含まれるＤｖｅＥＵＩとＤｅｖＮｏｎｃｅを抽出する。ネットワークサーバ４はＤｅｖＥＵＩに基づき無線端末２−１に対応するＮｅｔＩＤを特定し、乱数を発生させてＡｐｐＮｏｎｃｅとする。ネットワークサーバ４はＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２−１へ送信する（Ｓ１０２８）。またネットワークサーバ４は無線端末２−２に対しても同様に、ＤｅｖＥＵＩに基づき無線端末２−２に対応するＮｅｔＩＤを特定し、乱数を発生させてＡｐｐＮｏｎｃｅとし、ＮｅｔＩＤとＡｐｐＮｏｎｃｅを含むＪｏｉｎＡｃｃｅｐｔを無線端末２−２へ送信する（Ｓ１０３０）。図１０のＳ１０３０までの状態を図１１（Ｅ）に示す。図１１（Ｅ）では、ネットワークサーバ４に無線端末２−１に対応付けてＤｅｖＮｏｎｃｅ：ε３が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ１と、ＡｐｐＮｏｎｃｅ：ζ３が保持されている。なおＮｅｔＩＤは無線端末２−１に固有の識別子であるから、図１１（Ｂ）と同じくＮｅｔＩＤ：σ１である。またネットワークサーバ４に無線端末２−２に対応付けてＤｅｖＮｏｎｃｅ：ε４が保持されており、さらにＤｅｖＥＵＩから特定したＮｅｔＩＤ：σ２と、ＡｐｐＮｏｎｃｅ：ζ４が保持されている。なおＮｅｔＩＤは無線端末２−２に固有の識別子であるから、図１１（Ｂ）と同じくＮｅｔＩＤ：σ２である。ここでＡｐｐＮｏｎｃｅは乱数であるから、ζ３とζ４は関連の無い異なった値である。

【0119】

無線端末２−１はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２−１はＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ１０３４）。一方でネットワークサーバ４は、ＡｐｐＫｅｙ、無線端末２−１から受信したＤｖｅＮｏｎｃｅ、無線端末２−１へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ１０３２）。

【0120】

無線端末２−２はネットワークサーバ４からＪｏｉｎＡｃｃｅｐｔを受信すると、ＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤとＡｐｐＮｏｎｃｅを抽出する。無線端末２−２はＡｐｐＫｅｙ、ネットワークサーバ４へ送信したＤｖｅＮｏｎｃｅ、ネットワークサーバ４から受信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ１０３８）。一方でネットワークサーバ４は、ＡｐｐＫｅｙ、無線端末２−２から受信したＤｖｅＮｏｎｃｅ、無線端末２−２へ送信したＮｅｔＩＤおよびＡｐｐＮｏｎｃｅを用いて暗号鍵を生成し、これをＡｐｐＳＫｅｙとする（Ｓ１０３６）。

【0121】

図１０のＳ１０３２からＳ１０３８までの状態を図１１（Ｆ）に示す。図１１（Ｆ）では、無線端末２−１にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ１とＡｐｐＮｏｎｃｅ：ζ３が保持されており、無線端末２−１とネットワークサーバ４の双方に、ＡｐｐＫｅｙ：β１、ＮｅｔＩＤ：σ１、ＤｅｖＮｏｎｃｅ：ε３およびＡｐｐＮｏｎｃｅ：ζ３を用いて生成されたＡｐｐＳＫｅｙ：γ１が保持されている。また図１１（Ｃ）では、無線端末２−２にＪｏｉｎＡｃｃｅｐｔに含まれるＮｅｔＩＤ：σ２とＡｐｐＮｏｎｃｅ：ζ４が保持されており、無線端末２−２とネットワークサーバ４の双方に、ＡｐｐＫｅｙ：β２、ＮｅｔＩＤ：σ２、ＤｅｖＮｏｎｃｅ：ε４およびＡｐｐＮｏｎｃｅ：ζ４を用いて生成されたＡｐｐＳＫｅｙ：γ２が保持されている。ここで、無線端末２−１に対するＡｐｐＳＫｅｙ：γ１と無線端末２−２に対するＡｐｐＳＫｅｙ：γ２は、それぞれ異なるＡｐｐＫｅｙ、ＮｅｔＩＤおよび乱数値（ＤｅｖＮｏｎｃｅ、ＡｐｐＮｏｎｃｅ）に基づき生成されるので、γ１とγ２は関連の無い異なる値である。

【0122】

無線端末２−１とネットワークサーバ４は、各々でＡｐｐＳＫｅｙ（図１１（Ｆ）のγ１）が生成されると、当該ＡｐｐＳＫｅｙを用いてユーザデータを暗号化、復号する通常運用へ移行する（Ｓ１０４０）。また無線端末２−２とネットワークサーバ４は、各々でＡｐｐＳＫｅｙ（図１１（Ｆ）のγ２）が生成されると、当該ＡｐｐＳＫｅｙを用いてユーザデータを暗号化、復号する通常運用へ移行する（Ｓ１０４２）。ここで、ＡｐｐＳＫｅｙ：γ１およびγ２は、無線端末２−１と無線端末２−２のそれぞれとネットワークサーバ４との接続が解消されるまで有効であるから、無線端末２−１あるいは無線端末２−２とネットワークサーバ４との接続が解消された場合は、接続が解消された無線端末２とネットワークサーバ４との接続動作が実行され、図６（Ａ）〜（Ｃ）のフェーズ１で新たなＡｐｐＫｅｙが生成され、図６（Ｄ）〜（Ｆ）のフェーズ２で新たなＡｐｐＳｋｅｙが生成される。

【0123】

（Ｅ−２）無線端末の動作フロー
第２の実施形態における無線端末２−１および無線端末２−２それぞれの動作は、第１の実施形態にて説明した無線端末２の動作と同一である。即ち、第２の実施形態における無線端末２−１および無線端末２−２それぞれの動作は図７のフローチャートにて説明される。

【0124】

（Ｅ−３）ネットワークサーバの動作フロー
第２の実施形態におけるネットワークサーバ４の、無線端末２−１および無線端末２−２のそれぞれに対する動作は、第１の実施形態にて説明したネットワークサーバ４の動作と同一である。即ち、第２の実施形態におけるネットワークサーバ４の動作は図８のフローチャートにて説明される。上述のとおり、無線端末２−１と無線端末２−２は同期して動作するものではないので、ネットワークサーバ４は無線端末２−１に対して適宜に図８のフローチャートに示される動作を行い、無線端末２−２に対しても適宜に図８のフローチャートに示される動作を行う。

【0125】

（Ｆ）第２の実施形態における効果
上述した第２の実施形態によれば、第１の実施形態と同様の効果を得ることができる。即ち、無線端末２−１および無線端末２−２のそれぞれに予めＡｐｐＫｅｙを保持させる必要が無く、無線端末２−１および無線端末２−２のそれぞれは自身のプログラムに定義される仮ＡｐｐＫｅｙを当該プログラムから読み出して自身に設定するので、第１の実施形態と同様に、第２の実施形態は従前に比べてＡｐｐＫｅｙ管理の点でセキュリティが向上している。また第２の実施形態は、第１の実施形態と同様に、従前に比べＡｐｐＳＫｅｙ管理の点でもセキュリティが向上している。また第２の実施形態は、共通鍵暗号方式を用い、ＬＰＷＡの無線通信システムの利点である無線端末２の低消費電力性、低経済コストを損なわずに、従前に比べセキュリティが向上した無線通信システム１Ｂを実現している。

【0126】

第２の実施形態に特有な点は、無線端末２−１および無線端末２−２のそれぞれに予めＡｐｐＫｅｙを保持させずとも、無線端末２−１および無線端末２−２のそれぞれがネットワークサーバ４に接続し、人手に依らずＡｐｐＫｅｙが生成される点である。上述のように、無線通信システムに共通鍵暗号方式を採用する場合、暗号鍵（ＡｐｐＫｅｙ）を、無線端末２の設置時に、無線端末２に保持させる必要がある。つまり従前では、無線通信システムを構築する者は、多数の無線端末２のそれぞれに異なる暗号鍵（ＡｐｐＫｅｙ）を保持させ、かつネットワークサーバ４にも無線端末２に対応したそれぞれ異なる暗号鍵（ＡｐｐＫｅｙ）を登録する必要があり、多大な手間を要するものであった。

【0127】

対して第２の実施形態では、無線端末２−１および無線端末２−２のそれぞれに予めＡｐｐＫｅｙを保持させる必要がなく、また無線端末２−１および無線端末２−２のそれぞれのプログラムに定義する仮ＡｐｐＫｅｙは、無線端末２の数に依らず同一の値でよい（図１１のα１）。そして第２の実施形態では、無線端末２−１および無線端末２−２がネットワークサーバ４と通信を行う過程で、無線端末２ごとに異なる正式ＡｐｐＫｅｙが無線端末２とネットワークサーバ４にて生成される（図１１のβ１およびβ２）。つまり第２の実施形態は、従前に比べ、複数の無線端末２のそれぞれへ異なるＡｐｐＫｅｙを保持させ、かつネットワークサーバ４にもＡｐｐＫｅｙを保持させる手間を削減することができる。この効果は、無線通信システム１Ｂに参加する無線端末２の数が増大するほど顕著である。

【0128】

（３）他の変形例
第１の実施形態および第２の実施形態について、次の変形例を適用してもよい。

【0129】

（Ｇ−１）上述のとおり、無線端末２およびネットワークサーバ４のそれぞれでＡｐｐＳＫｅｙが生成された後に、無線端末２とネットワークサーバ４との接続が解消されると、無線端末２およびネットワークサーバ４のそれぞれで、仮ＡｐｐＫｅｙを基にした正式ＡｐｐＫｅｙの生成、および正式ＡｐｐＫｅｙを基にしたＡｐｐＳｋｅｙの生成が再度行われる。ここで、無線端末２とネットワークサーバ４のそれぞれは、接続が解消される直前までに用いていたＡｐｐＳＫｅｙの値（旧ＡｐｐＳｋｅｙ値と呼称する）を保持するようにし、接続解消後の再接続において、旧ＡｐｐＳｋｅｙ値を基にしてＡｐｐＫｅｙを生成し、当該ＡｐｐＫｅｙを基にして新たなＡｐｐＳｋｅｙを生成するようにしてもよい。

【0130】

第１の実施形態および第２の実施形態で説明したように、接続が解消される直前までに用いていた旧ＡｐｐＳＫｅｙ値は、無線端末２またはネットワークサーバ４のプログラムに定義される仮ＡｐｐＫｅｙおよび乱数値を用いて、無線端末２およびネットワークサーバ４の内部にて生成される。従って第三者に旧ＡｐｐＳＫｅｙ値を把握される、または第三者に旧ＡｐｐＳＫｅｙ値を演算で導出される可能性は低い。そのため、無線端末２とネットワークサーバ４の再接続において旧ＡｐｐＳＫｅｙ値を利用すれば、これに基づいて生成されるＡｐｐＫｅｙおよびＡｐｐＳｋｅｙは、第三者に対して更に秘匿性の高いものとなる。

【0131】

（Ｇ−２）第１の実施形態および第２の実施形態では、図４において二点鎖線で囲んだＮｗｋＳＫｅｙは関与しなかった。ここで、ＮｗｋＳＫｅｙとは、図４においてエンドデバイスとネットワークサーバとの間で通信する定型のコマンドデータの暗号化および復号に用いられるものであり、ＮｗｋＳＫｅｙはＡｐｐＳｋｅｙと同様にＡｐｐＫｅｙを基に生成される。変形例として、上述した手順によってＡｐｐＳＫｅｙを生成するとともに、同様の手順によってＮｗｋＳＫｅｙを生成してもよい。この場合、ＡｐｐＳＫｅｙの生成においては、上述の正式ＡｐｐＫｅｙ、ＮｅｔＩＤ、ＤｅｖＮｏｎｃｅおよびＡｐｐＮｏｎｃｅの４つに、さらに第１の固定値Ｘ１を加えた５つの値に基づいてＡｐｐＳＫｅｙを生成する。またＮｗｋＳＫｅｙの生成においては、上述の正式ＡｐｐＫｅｙ、ＮｅｔＩＤ、ＤｅｖＮｏｎｃｅおよびＡｐｐＮｏｎｃｅの４つに、さらに第２の固定値Ｘ２を加えた５つの値に基づいてＮｗｋＳＫｅｙを生成する。本変形例によれば、第１の実施形態および第２の実施形態に加え、ＮｗｋＳＫｅｙ管理の点でもセキュリティを向上することができる。

【0132】

（Ｇ−３）第１の実施形態および第２の実施形態では、ＬｏＲａＷＡＮにて規定される暗号鍵生成の仕組みを利用する形態を説明した。しかしながら本発明はＬｏＲａＷＡＮプロトコル以外の他の無線プロトコルでも適用可能である。即ち、通信システムの上流側サーバと下流側端末との通信において共通鍵暗号方式が採用されており、上流側サーバと下流側端末との通信によって下流側端末が上流側サーバに登録され、通信に用いられる暗号鍵が生成される通信システムであれば、本発明の構成、動作を適用することができる。

【符号の説明】

【0133】

１Ａ、１Ｂ…無線通信システム、２（２−１〜２−ｎ）…無線端末、３…基地局、
４…ネットワーク（ＮＷ）サーバ、５…上位装置、
２１…制御部、２１２…接続処理部、２１２…一時保持部、２１３…乱数発生部、
２１４…暗号鍵生成部、２２…記憶部、２３…送信部、２４…受信部、
２５…暗号化部、２６…復号部、
２７…外部インタフェース、２８…アンテナ、
４１…制御部、４１２…接続処理部、４１２…一時保持部、４１３…乱数発生部、
４１４…暗号鍵生成部、４２…記憶部、４３…送信部、４４…受信部、
４５…暗号化部、４６…復号部、４７…外部インタフェース、４８…インタフェース、
９０…ＡｐｐＫｅｙ、９２…ＤｅｖＮｏｎｃｅ、９４…ＤｅｖＥＵＩ、
９６…ＡｐｐＮｏｎｃｅ、９８…ＮｅｔＩＤ、９１０…ＡｐｐＳＫｅｙ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】