JP4803145B2

JP4803145B2 - 鍵共有方法、鍵配信システム

Info

Publication number: JP4803145B2
Application number: JP2007239842A
Authority: JP
Inventors: 純中嶋
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2007-09-14
Filing date: 2007-09-14
Publication date: 2011-10-26
Anticipated expiration: 2027-09-14
Also published as: JP2009071707A

Description

本発明は、通信端末間で暗号鍵を共有する方法、および鍵配信システムに関するものである。

従来、無線ＬＡＮシステムにおいて、アクセスポイント（以下、ＡＰと略す）の鍵を無線ＬＡＮ端末（以下、総称として端末と略す）に配送する技術に関し、端末とＡＰが設置者とともに屋内にあることを想定し、端末側とＡＰ側で所定のボタンをほぼ同じタイミングで押下し、ボタンが押下された状態にある端末とＡＰが鍵を共有する、というものが提案されている（非特許文献１）。
外部の悪意ある者は、ボタンがいつ押下されるか予測できないため、上記の鍵共有手続に割って入ることは一般に困難であると考えられており、これが上記技術の安全性の根拠とされている。

また、『利用者固有の情報を安全かつ容易に利用者端末に設定することができる利用者固有情報の配布方法、装置およびシステムを提供する。』ことを目的とした技術として、『無線タグ読取機２０によって端末１０に貼り付けた無線タグ１０１から公開鍵Ｋを読み取ると、無線ＬＡＮアクセスポイント２１は公開鍵Ｋを用いて設定情報を暗号化する。暗号化された設定情報はビーコンに格納され無線送信される。端末１０がビーコンを受信すると、ビーコンに格納された暗号化された設定情報を秘密鍵を用いて復号化し設定する。』というものが提案されている（特許文献１）。

特開２００６−２８５８２６号公報（要約）ワンタッチで設定できるバッファローの「ＡＯＳＳ」で変わる無線ＬＡＮのセキュリティ対策、http://bb.watch.impress.co.jp/cda/shimizu/4007.html

上記非特許文献１に記載の技術では、常時ボタン押下状態の端末やＡＰが通信可能エリア内に存在することにより、設置者の意図しない端末とＡＰが通信チャネルを確立してしまう可能性を、完全に回避できるものではない。
また、通信インターフェース以外の外部インターフェースを持たない（上記のようなボタンを持たない）通信端末、例えばセンサネットワークにおける無線通信端末に、上記非特許文献１に記載の技術を適用することはできない。

上記特許文献１に記載の技術では、端末１０に貼り付けた無線タグ１０１のタグ情報を悪意ある者に読み取られた場合は、例えばネットワークを再構築する際に端末が悪意あるＡＰからの鍵情報を受信してしまう可能性がある。
その他にも、タグ情報が読み取り不可能になった場合に備えて、最初にタグ情報を読み込んだときに別の記録メディアにその情報を保存する場合があり、これらを紛失したときにタグ情報が外部へ漏洩する可能性もある。

そのため、安全な通信チャネルを確立するための暗号鍵を、盗聴を困難にしつつ、設置者の想定するエンティティ間でのみ共有することのできる鍵共有方法、および鍵配信システムが望まれていた。

本発明に係る鍵共有方法は、通信端末間で暗号鍵を共有する方法であって、いずれの前記通信端末同士が前記暗号鍵を共有するのかを示す関連付け情報を保持するサーバと、前記サーバに前記関連付け情報を送信する関連付け端末と、を設け、前記サーバに各通信端末の固有鍵をあらかじめ格納しておき、前記各通信端末は、固有のＩＤを有し、前記関連付け端末は、前記ＩＤを撮像する撮像手段を備え、前記暗号鍵は、該暗号鍵の共有対象である前記通信端末のうちの第１の通信端末の前記固有鍵であり、前記サーバが、前記撮像手段によって撮像された前記各通信端末の前記ＩＤに基づいて、前記関連付け情報を生成するステップと、前記サーバが前記関連付け端末を認証するステップと、前記関連付け端末が前記サーバに前記関連付け情報を送信する関連付けステップと、前記サーバが前記関連付け情報に基づき、前記暗号鍵を該暗号鍵の共有対象である前記通信端末のうちの第２の通信端末の固有鍵によって暗号化し、その暗号化されたものである暗号化暗号鍵を前記第１の通信端末及び前記関連付け端末のうち少なくとも１つに配信する鍵配信ステップと、前記第２の通信端末が前記第１の通信端末に接続要求を発行する接続ステップと、を有するものである。

本発明に係る鍵共有方法によれば、サーバ上で関連付けられている通信端末間でのみ暗号鍵が共有されるため、外部の端末が鍵共有プロセスに割って入るということがなく、あらかじめ想定しておいた通信端末間でのみ暗号鍵を共有することができる。
また、共有する暗号鍵が通信経路上に平文で流れることがないため、暗号鍵の盗聴が困難である。

実施の形態１．
図１は、通信端末間で鍵共有を行う際の漏洩可能性について説明するものである。
図１において、家屋Ａには端末１００ａとＡＰ２００ａが設置者Ａにより設置されている。端末１００ａとＡＰ２００ａは、無線通信により接続されている。
ＡＰ２００ａはインターネット５００に接続され、端末１００ａに無線通信を介したインターネット接続を提供する。
なお、家屋Ｂには、設置者Ｂにより家屋Ａと同様の環境が敷設されている。以下では、家屋Ａ内の環境について説明するが、家屋Ｂについても同様である。

図１に示す環境の前提条件として、以下の事項を仮定する。
（１）端末１００ａとＡＰ２００ａで事前に共有できる情報はない。
（２）端末１００ａは無線通信以外のインターフェースを備えていない。
（３）公開鍵暗号は使用できない。

一般に、無線通信を用いたＡＰでは、端末１００ａとＡＰ２００ａの間の無線通信チャネルの安全性を確保するため、通信を暗号化する。暗号化に際し、暗号鍵を端末１００ａとＡＰ２００ａで共有するが、この暗号鍵が例えば外部の端末１００ｃによる盗聴などで漏洩すると、通信内容が外部に漏洩する危険性がある。
また、端末１００ａが設置者Ａの意図しないＡＰ（例えば家屋Ｂ内のＡＰ２００ｂ）に接続したり、設置者Ａの意図しない端末（例えば家屋Ｂ内の端末１００ｂ）がＡＰ２００ａに接続したりすると、家屋Ａ内の情報が外部に漏洩する危険性がある。
そこで、家屋Ａの通信環境の安全性を確保するための条件として、以下のような事項が要求される。

（１）端末１００ａは設置者Ａの所望するＡＰ２００ａに接続する。
（２）設置者Ａ以外の者が、故意に端末１００ａをＡＰ２００ａ以外のＡＰに接続させることはできない。
（３）ＡＰ２００ａに端末１００ａ以外の端末を接続させない。
（４）設置者Ａの所望する通りに暗号鍵の共有手続を実行する。

次に、端末１００ａとＡＰ２００ａの間で暗号鍵を安全に共有する手法について説明する。以下の説明では、端末１００ａ、１００ｂなどと特に区別せず、端末１００などと称する場合は、各機器に共通の事項であるものとする。

図２は、本実施の形態１に係る鍵配信システムの概略構成図である。以下、図２の各ステップに従って、図２の鍵配信システムが端末１００とＡＰ２００の間で鍵を共有する手順について説明する。
なお、詳細な処理シーケンスや各機器の詳細構成は、後述の各図で説明することとし、ここでは本実施の形態１に係る鍵配信システムの概略のみ示す。

まず、前提として各機器の役割等を説明しておく。
端末１００、ＡＰ２００は、図１で説明した端末１００ａ、ＡＰ２００ａに相当する。これらの機器は、固有のＩＤと鍵を内部に保持している。
センターサーバ３００は、後述の図３〜図５で説明する各テーブルを格納したデータベースを備えており、主に端末１００とＡＰ２００の関連付け、および共有する暗号鍵の配信を行う。
関連付け端末４００は、端末１００とＡＰ２００の関連付け操作を行うための端末である。関連付け端末４００は、インターネット接続機能を備えた通信端末、例えば携帯電話端末などで構成することができる。
センターサーバ３００は、インターネット５００を介してＡＰ２００および関連付け端末４００と接続されている。

以下、図２の各ステップについて説明する。

（１）ログイン
ユーザ（図１の設置者Ａに相当）は、関連付け端末４００を用いてセンターサーバ３００に接続し、センターサーバ３００へのログイン手続きを実行する。センターサーバ３００は、後述の図５で説明するユーザテーブルを参照し、ユーザ認証を行う。

（２）ＩＤ取得
ユーザは、端末１００とＡＰ２００にあらかじめ割り当てられている固有のＩＤを取得する。このＩＤは、各機器の製造時などに一意に割り当てられており、各機器の筐体に印字する、ＱＲコード化して筐体に貼り付けておく、適当なインターフェースを介して出力する、などの方法で、関連付け端末４００が取得できるようにしておく。
また、各機器のＩＤと固有鍵は、それぞれ後述の図３〜図４で説明する端末テーブルとＡＰテーブルに、各機器の製造等の時点であらかじめ格納されているものとする。

（３）ＩＤ送信
ユーザは、端末１００とＡＰ２００の固有ＩＤを、関連付け端末４００を使用してセンターサーバ３００に送信する。

（４）各機器とユーザの関連付け
センターセーバ３００は、ステップ（３）で受信した固有ＩＤを元に各機器を特定し、ユーザがこれらの機器を所有していることを認識する。次に、この所有機器のリストを、後述の図５で説明するユーザテーブルに反映する。

（５）ＡＰと端末の関連付け
センターサーバ３００は、ステップ（３）で受信した固有ＩＤを元に、各機器の関連付けを行い、その関連付け情報を後述の図４で説明するＡＰテーブルに反映する。
ここでいう関連付けとは、関連付けされた各機器の間で暗号鍵を共有することをセンターサーバ３００に提示することをいう。即ち、センターサーバ３００は、本ステップの関連付け処理により、関連付けられた各機器が暗号鍵を共有することを認識する。

（６）暗号化したＡＰ鍵をＡＰに送信
センターサーバ３００は、後述の図３で説明する端末テーブルより、ステップ（５）で関連付けした端末１００とＡＰ２００の固有鍵を読み取る。次に、端末１００の固有鍵でＡＰ２００の固有鍵を暗号化し、ＡＰ２００に送信する。
端末１００に直接送信しないのは、端末１００が直接インターネットに接続することができないためであり、暗号化して送信するのは、暗号鍵を平文で通信経路に流さないようにするためである。

（７）鍵共有
ＡＰ２００と端末１００の間で、ＡＰ２００の固有鍵を共有する。以後、端末１００とＡＰ２００の間の通信は、共有されたＡＰ２００の固有鍵を用いて暗号化される。
本ステップの処理の詳細は、後述の図６で説明する処理シーケンスで改めて説明する。

図３は、センターサーバ３００が保持する端末テーブルの構成説明図である。
端末テーブルは、「端末ＩＤ」列、「端末固有鍵」列を有する。
「端末ＩＤ」列には、端末１００の固有ＩＤが格納される。
「端末固有鍵」列には、端末１００の固有鍵が格納される。
いずれの列の値も、端末１００の製造、出荷等の時点でセンターサーバ３００に送信され、ユーザの手元に端末１００が届く前に、各値がセットされた状態となっている。

図４は、センターサーバ３００が保持するＡＰテーブルの構成説明図である。
ＡＰテーブルは、「ＡＰＩＤ」列、「ＡＰ固有鍵」列、「関連付けられた端末ＩＤ」列、「関連付けられた端末のＭＡＣアドレス」列を有する。
「ＡＰＩＤ」列には、ＡＰ２００の固有ＩＤが格納される。
「ＡＰ固有鍵」列には、ＡＰ２００の固有鍵が格納される。
「関連付けられた端末ＩＤ」列には、図２のステップ（５）で関連付けられる端末１００の固有ＩＤが格納される。本列の値は、関連付けられた端末１００の個数分存在する。
「関連付けられた端末のＭＡＣアドレス」列には、図２のステップ（５）で関連付けられる端末１００のＭＡＣアドレスが格納される。本列の値は、関連付けられた端末１００の個数分存在する。
「ＡＰＩＤ」列と「ＡＰ固有鍵」列の値は、ＡＰ２００の製造、出荷等の時点でセンターサーバ３００に送信され、ユーザの手元にＡＰ２００が届く前に、各値がセットされた状態となっている。

なお、「関連付けられた端末のＭＡＣアドレス」列の値に関しては、図２のステップ（３）で関連付け端末４００が端末１００の固有ＩＤの送信とともにＭＡＣアドレスを送信するようにしてもよいし、端末テーブル中に「端末ＭＡＣアドレス」列を設け、同列から端末ＩＤをキーにして取得するようにしてもよい。
後者の場合は、端末１００の製造、出荷などの時点で、「端末ＭＡＣアドレス」列の値をあらかじめセンターサーバ３００に送信しておく。

図５は、センターサーバ３００が保持するユーザテーブルの構成説明図である。
ユーザテーブルは、「ユーザＩＤ」列、「パスワード」列、「所持ＡＰリスト」列、「所持端末リスト」列を有する。
「ユーザＩＤ」列には、ユーザがセンターサーバ３００にログインする際のログインＩＤが格納される。
「パスワード」列には、ユーザがセンターサーバ３００にログインする際のログインパスワードが格納される。
「所持ＡＰリスト」列には、図２のステップ（４）で関連付けられる、当該ユーザが所持するＡＰ２００の固有ＩＤが格納される。本列の値は、関連付けられたＡＰ２００の個数分存在する。
「所持端末リスト」列には、図２のステップ（４）で関連付けられる、当該ユーザが所持する端末１００の固有ＩＤが格納される。本列の値は、関連付けられた端末１００の個数分存在する。

図６は、端末１００ａとＡＰ２００ａがＡＰ２００ａの固有鍵を暗号鍵として共有する処理シーケンスを説明するものである。ここでは、図１と同様の環境を前提に説明する。なお、端末１００ａはＺｉｇＢｅｅノード、ＡＰ２００ａはＺｉｇＢｅｅＣｏｏｒｄｉｎａｔｏｒとして動作するものとする。

図６（ａ）は、鍵共有手順を実行する前の事前処理シーケンスである。
図６（ｂ）は、端末１００ａが設置者Ａの意図しないＡＰ（ここではＡＰ２００ｂ）に接続を試みた場合の処理シーケンスである。
図６（ｃ）は、端末１００ａが設置者Ａの意図するＡＰ（ここではＡＰ２００ａ）に接続を試みた場合の処理シーケンスである。
図６（ａ）〜（ｃ）は、時系列に沿って記載している。以下、図６の各ステップについて説明する。

（Ｓ６０１）
センターサーバ３００は、ＡＰテーブルに格納されている関連付け情報に基づき、端末１００ａのＭＡＣアドレスをＡＰ２００ａに送信する。また、端末１００ａの固有鍵（Ｋ_a）でＡＰ２００ａの固有鍵（Ｋ_auth1）を暗号化し（以後、Ｃ１とする）、同時にＡＰ２００ａに送信する。
本ステップは、図２のステップ（６）に相当する。

（Ｓ６０２）
ユーザは、端末１００ａの電源をＯＮする。端末１００ａは、どのＡＰに接続すべきか最初は分からないため、ＡＰから送信されるビーコン信号を待機する。
（Ｓ６０３）
端末１００ａが、ＡＰ２００ｂ（設置者Ａが意図しないＡＰ）が送信したビーコン信号を、ＡＰ２００ａのビーコン信号より先に受信したものと仮定する。

（Ｓ６０４）
端末１００ａは、ＡＰ２００ｂへ接続要求を発行するとともに、乱数Ｒ１を送信する。
（Ｓ６０５）
ＡＰ２００ｂは、端末１００ａのＭＡＣアドレスを取得する。端末１００ａのＭＡＣアドレスがセンターサーバ３００から事前に送信されていないため、端末１００ａの接続要求はＡＰ２００ｂの意図しないものであることが分かる。
（Ｓ６０６）
ＡＰ２００ｂは、接続拒否通知を端末１００ａに返信する。

（Ｓ６０７）
端末１００ａは、ＡＰ２００ａ（設置者Ａが意図するＡＰ）が送信したビーコン信号を受信する。
（Ｓ６０８）
端末１００ａは、ＡＰ２００ａへ接続要求を発行するとともに、乱数Ｒ２を送信する。
（Ｓ６０９）
ＡＰ２００ａは、端末１００ａのＭＡＣアドレスを取得する。端末１００ａのＭＡＣアドレスがセンターサーバ３００から事前に送信されているため、端末１００ａの接続要求はＡＰ２００ａの意図するものであることが分かる。

（Ｓ６１０）
ＡＰ２００ａは、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として乱数Ｒ２のハッシュ値Ｃ２を計算する。
（Ｓ６１１）
ＡＰ２００ａは、ステップＳ６０１で受信したＣ１と、ステップＳ６１０で計算したＣ２を、端末１００ａに送信する。

（Ｓ６１２）
端末１００ａは、自己の固有鍵（Ｋ_a）でＣ１を復号し、ＡＰ２００ａの固有鍵（Ｋ_auth1）を取得する。
（Ｓ６１３）
端末１００ａは、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として乱数Ｒ２のハッシュ値を計算する。

（Ｓ６１４）
端末１００ａは、ステップＳ６１３で計算したハッシュ値と、ステップＳ６１１で受信したＣ２とが、一致するか否かを判定する。一致した場合はステップＳ６１５へ進み、一致しなかった場合はそのまま待機する。
（Ｓ６１５）
端末１００ａは、ステップＳ６１３の計算結果がＣ２と一致したことにより、接続先ＡＰがＡＰ２００ａであることが分かるので、ＺｉｇＢｅｅ−ｊｏｉｎ手続きを実行し、ＡＰ２００ａへの接続を完了する。

以上の手続きにより、設置者Ａが意図した通りに、端末１００ａとＡＰ２００ａの接続が完了し、両者の間でＡＰ２００ａの固有鍵（Ｋ_auth1）が安全に共有される。

なお、仮にＡＰ２００ｂが悪意ある者の設置した偽ＡＰ等の不正ＡＰであり、ステップＳ６０６で接続許可の旨を返信して端末１００ａを接続させるように誘導したとしても、端末１００ａは図６（ｃ）で説明したハッシュ値照合を行うため、意図しないＡＰに誤って接続してしまうことはない。

即ち、ＡＰ２００ｂはＡＰ２００ａの固有鍵（Ｋ_auth1）を知らないため、端末１００ａで計算するハッシュ値と一致する正しいハッシュ値を求めることができないので、ステップＳ６１４で計算結果は必ず不一致となり、端末１００ａが誤ってＡＰ２００ｂにＺｉｇＢｅｅ−ｊｏｉｎ手続きを実行することはない。

以上で、本実施の形態１に係る鍵配信システムの鍵共有手順について説明した。
以下では、各機器の詳細構成について説明する。

図７は、端末１００の機能ブロック図である。
端末１００は、無線通信部１０１、接続先候補保持部１０２、接続先決定部１０３、乱数生成部１０４、乱数保持部１０５、鍵付ハッシュ計算部１０６、照合部１０７、固有鍵保持部１０８、復号部１０９、ＡＰ鍵保持部１１０を備える。

無線通信部１０１は、ＺｉｇＢｅｅ等の無線通信方式で通信を行う。
接続先候補保持部１０２は、ＡＰからビーコン信号を受け取った際に、そのＡＰのアドレス等を接続先の候補として一時的に保持する。
接続先決定部１０３は、照合部１０７の照合結果に基づき、接続先候補保持部１０２が保持しているＡＰのアドレス等のリストから、接続先を決定する。
乱数生成部１０４は、適当な方法で乱数Ｒを生成する。
乱数保持部１０５は、乱数生成部１０４が生成した乱数Ｒを一時的に保持する。
鍵付ハッシュ計算部１０６は、ＡＰ固有鍵を用いて乱数Ｒのハッシュ値を計算する。
照合部１０７は、鍵付ハッシュ計算部１０６が計算したハッシュ値と、ＡＰより受信したハッシュ値とを照合し、照合結果を接続先決定部１０３に出力する。
固有鍵保持部１０８は、端末１００の固有鍵を保持する。
復号部１０９は、端末１００の固有鍵を用いて、ＡＰより受信した、暗号化されたＡＰ固有鍵を復号する。
ＡＰ鍵保持部１１０は、復号部１０９が復号したＡＰ固有鍵を一時的に保持する。

接続先決定部１０３、乱数生成部１０４、鍵付ハッシュ計算部１０６、照合部１０７、復号部１０９は、これらの機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。
接続先候補保持部１０２、乱数保持部１０５、固有鍵保持部１０８、ＡＰ鍵保持部１１０は、メモリ等の記憶装置で構成することができる。これらを一体的に構成してもよい。

図８は、ＡＰ２００の機能ブロック図である。
ＡＰ２００は、無線通信部２０１、鍵付ハッシュ計算部２０２、ＡＰ鍵保持部２０３、情報保持部２０４、インターネット通信部２０５を備える。

無線通信部２０１は、ＺｉｇＢｅｅ等の無線通信方式で通信を行う。
鍵付ハッシュ計算部２０２は、ＡＰ固有鍵を用いて乱数Ｒのハッシュ値を計算する。
ＡＰ鍵保持部２０３は、ＡＰ２００の固有鍵を保持する。
情報保持部２０４は、インターネット通信部２０５が受信したデータを一時的に保持する。
インターネット通信部２０５は、インターネット５００を介してセンターサーバ３００等の外部機器とデータの送受信を行う。

鍵付ハッシュ計算部２０２は、その機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。
ＡＰ鍵保持部２０３、情報保持部２０４は、メモリ等の記憶装置で構成することができる。これらを一体的に構成してもよい。

図９は、センターサーバ３００の機能ブロック図である。
センターサーバ３００は、インターネット通信部３０１、鍵暗号化部３０２、関連付け決定部３０３、関連付け参照子保持部３０４、テーブル操作部３０５、および図３〜図５で説明した各テーブルを格納したデータベースを備える。

インターネット通信部３０１は、インターネット５００を介してＡＰ２００等の外部機器とデータの送受信を行う。
鍵暗号化部３０２は、ＡＰテーブルに格納されているＡＰ２００の固有鍵（Ｋ_auth）を、端末テーブルに格納されている端末１００の固有鍵で暗号化する。
関連付け決定部３０３は、関連付け端末４００が送信した関連付け情報をインターネット通信部３０１より受け取り、端末１００とＡＰ２００等の関連付けを決定する。
関連付け参照子保持部３０４は、関連付け決定部３０３が決定した関連付け情報を一時的に保持する。
テーブル操作部３０５は、データベースが格納している各テーブルのエントリの生成、更新などの処理を行う。

鍵暗号化部３０２、関連付け決定部３０３、テーブル操作部３０５は、これらの機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。
関連付け参照子保持部３０４は、メモリ等の記憶装置で構成することができる。
データベースは、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）等の書き込み可能な記憶装置に、各テーブルのデータを格納することにより構成できる。説明の簡易の観点からテーブルとしたが、データ形式はテーブル形式に限られるものではなく、任意の形式を用いることができる。

図１０は、関連付け端末４００の機能ブロック図である。
関連付け端末４００は、インターネット通信部４０１、センターサーバアドレス保持部４０２、機器ＩＤ取得部４０３、テーブル操作要求生成部４０４、認証情報入力部４０５、関連付け指定部４０６を備える。

インターネット通信部４０１は、インターネット５００を介してセンターサーバ３００等の外部機器とデータの送受信を行う。
センターサーバアドレス保持部４０２は、センターサーバ３００のアドレスを保持している。
機器ＩＤ取得部４０３は、端末１００やＡＰ２００の固有ＩＤを取得する。取得方法は、ユーザがＩＤを直接入力する、各機器に貼り付けられた固有ＩＤを表すＱＲコードを撮像して解析する、適当なインターフェースを介して取得する、などの方法を用いることができる。
テーブル操作要求生成部４０４は、センターサーバ３００が保持している各テーブルのデータ作成、更新等の操作要求を生成する。
認証情報入力部４０５は、ユーザがセンターサーバ３００のログインＩＤとログインパスワードを入力するものである。
関連付け指定部４０６は、端末１００とＡＰ２００等の関連付けを指定し、関連付け情報としてインターネット通信部４０１に出力する。

センターサーバアドレス保持部４０２は、メモリ等の記憶装置で構成することができる。
テーブル操作要求生成部４０４、関連付け指定部４０６は、これらの機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。

以上、各機器の詳細構成について説明した。これらの構成は一例であり、図２や図６で説明した処理シーケンスを実現できるものであれば、その趣旨を逸脱しない範囲での設計変更は許容される。

本実施の形態１の説明では、端末１００およびＡＰ２００はＺｉｇＢｅｅ通信方式を用いるものとして説明したが、通信方式はこれに限られるものではない。以下の実施の形態においても同様である。

以上のように、本実施の形態１では、関連付け端末４００で端末１００とＡＰ２００の関連付けを行い、その関連付け情報をセンターサーバ３００のデータベースに格納し、センターサーバ３００はその関連付け情報に基づき暗号鍵を配信する。
そのため、ユーザの認証情報が漏洩しない限り、第３者がネットワークの構成を変更したり、ユーザの意図しない機器に暗号鍵が配信されたりすることがない。

また、本実施の形態１では、センターサーバ３００は、ＡＰ２００の固有鍵（Ｋ_auth1）を端末１００の固有鍵で暗号化してＡＰ２００に送信し、さらには端末１００がＡＰ２００の固有鍵（Ｋ_auth1）を取得する際も、暗号化されたままで送受信が行われる。
そのため、ＡＰ２００の固有鍵（Ｋ_auth1）が平文のままで通信経路を流れることがなく、同鍵の漏洩の危険性が低減される。

また、本実施の形態１では、センターサーバ３００は、関連付けがなされた端末１００のＭＡＣアドレスをＡＰ２００にあらかじめ送信しておき、端末１００がＡＰ２００に接続要求を発行した際に、ＡＰ２００は先にセンターサーバ３００より受信したＭＡＣアドレスとの照合を行う。
そのため、設置者の意図しない不正な端末１００がＡＰ２００に接続要求を発行した場合でも、ＡＰ２００は接続を拒否することができ、ＡＰ２００の安全性が確保される。

また、本実施の形態１では、端末１００がＡＰ２００に接続要求を発行する際に乱数を併せて送信し、ＡＰ２００の固有鍵（Ｋ_auth1）を鍵としたハッシュ値が一致するか否かにより、ＡＰ２００があらかじめ関連付けられたＡＰであるか否かを検証する。
そのため、設置者の意図しない不正なＡＰに誤って接続してしまうことがなく、端末１００の安全性が確保される。

また、以上の鍵共有手順により、ＡＰ２００の固有鍵（Ｋ_auth1）が端末１００とＡＰ２００の間で安全に共有される。

実施の形態２．
本発明の実施の形態２では、ＡＰ２００がインターネットに接続できない環境下において、端末１００とＡＰ２００で暗号鍵を安全に共有する手法について説明する。

図１１は、本実施の形態２に係る鍵配信システムの概略構成図である。以下、図１１の各ステップに従って、図１１の鍵配信システムが端末１００とＡＰ２００の間で鍵を共有する手順について説明する。
なお、詳細な処理シーケンスや各機器の詳細構成は、後述の図１２で説明することとし、ここでは本実施の形態２に係る鍵配信システムの概略のみ示す。

なお、関連付け端末４００は、端末１００との通信機能を備える。また、端末１００が接続先を知るためのビーコン信号を発信する。

以下、図１１の各ステップについて説明する。

（１）ログイン〜（５）ＡＰと端末の関連付け
これらのステップは、図２で説明したものと同様であるため、説明を省略する。
（６）暗号化したＡＰ鍵を関連付け端末に送信
センターサーバ３００は、端末テーブルより、ステップ（５）で関連付けした端末１００とＡＰ２００の固有鍵を読み取る。次に、端末１００の固有鍵でＡＰ２００の固有鍵を暗号化し、関連付け端末４００に送信する。

（７）鍵配信
関連付け端末４００は、ＡＰ２００の固有鍵を端末１００に配信する。以後、端末１００とＡＰ２００の間の通信は、共有されたＡＰ２００の固有鍵を用いて暗号化される。
（８）接続
端末１００は、ＡＰ２００に接続する。このとき、実施の形態１と異なり、ＡＰ２００はセンターサーバ３００より、端末１００のＭＡＣアドレス等の通知を受けていないため、端末１００の認証処理を行う必要がある。

なお、ステップ（７）〜（８）の処理の詳細は、後述の図１２で説明する処理シーケンスで改めて説明する。

図１２は、端末１００ａとＡＰ２００ａがＡＰ２００ａの固有鍵を暗号鍵として共有する処理シーケンスを説明するものである。ここでは、図１および図１１の環境を前提に説明する。なお、実施の形態１と同様に、端末１００ａはＺｉｇＢｅｅノード、ＡＰ２００ａはＺｉｇＢｅｅＣｏｏｒｄｉｎａｔｏｒとして動作するものとする。

図１２（ａ）は、鍵共有手順を実行する前の事前処理シーケンスである。
図１２（ｂ）は、関連付け端末４００と端末１００ａの間でＡＰ２００ａの固有鍵を共有する際の処理シーケンスである。
図１２（ｃ）は、端末１００ａが設置者Ａの意図するＡＰ（ここではＡＰ２００ａ）に接続を試みた場合の処理シーケンスである。
図１２（ａ）〜（ｃ）は、時系列に沿って記載している。以下、図１２の各ステップについて説明する。

（Ｓ１２０１）
センターサーバ３００は、ＡＰテーブルに格納されている関連付け情報に基づき、端末１００ａの固有鍵（Ｋ_a）でＡＰ２００ａの固有鍵（Ｋ_auth1）を暗号化し（以後、Ｃ１とする）、関連付け端末４００に送信する。
本ステップは、図１１のステップ（６）に相当する。
（Ｓ１２０２）
ユーザは、端末１００ａの電源をＯＮする。端末１００ａは、どのＡＰに接続すべきか最初は分からないため、ＡＰから送信されるビーコン信号を待機する。

（Ｓ１２０３）
端末１００ａは、関連付け端末４００が送信したビーコン信号を受信する。
（Ｓ１２０４）
端末１００ａは、関連付け端末４００へ接続要求を発行するとともに、乱数Ｒを送信する。

（Ｓ１２０５）
関連付け端末４００は、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として計算した乱数Ｒのハッシュ値Ｃ２を、センターサーバ３００に要求する。センターサーバ３００は、関連付け端末４００にハッシュ値Ｃ２を送信する。
（Ｓ１２０６）
関連付け端末４００は、ステップＳ１２０１で受信したＣ１と、ステップＳ１２０５で受信したＣ２を、端末１００ａに送信する。

（Ｓ１２０７）
端末１００ａは、自己の固有鍵でＣ１を復号し、ＡＰ２００ａの固有鍵（Ｋ_auth1）を取得する。
（Ｓ１２０８）
端末１００ａは、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として乱数Ｒのハッシュ値を計算する。
（Ｓ１２０９）
端末１００ａは、ステップＳ１２０８で計算したハッシュ値と、ステップＳ１２０６で受信したＣ２とが、一致するか否かを判定する。
一致した場合は、ＡＰ２００ａの固有鍵（Ｋ_auth1）の共有が成功したことになり、ステップＳ１２１０以降の接続処理に移行する。一致しなかった場合はそのまま待機する。

（Ｓ１２１０）
端末１００ａは、ＡＰ２００ａが送信したビーコン信号を受信する。
（Ｓ１２１１）
端末１００ａは、ＡＰ２００ａへ接続要求を発行する。
（Ｓ１２１２）
ＡＰ２００ａは、端末１００ａに乱数ρを送信する。
（Ｓ１２１３）
端末１００ａは、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として乱数ρのハッシュ値Ｃ３を計算する。

（Ｓ１２１４）
端末１００ａは、ハッシュ値Ｃ３をＡＰ２００ａに送信する。
（Ｓ１２１５）
端末１００ａは、ＺｉｇＢｅｅ−ｊｏｉｎ手続きを実行し、ＡＰ２００ａへの接続を試みる。

（Ｓ１２１６）
ＡＰ２００ａは、ＡＰ２００ａの固有鍵（Ｋ_auth1）を鍵として乱数ρのハッシュ値を計算する。
（Ｓ１２１７）
ＡＰ２００ａは、ステップＳ１２１６で計算したハッシュ値と、ステップＳ１２１４で受信したＣ３とが、一致するか否かを判定する。一致した場合は端末１００ａの接続を許可し、一致しなかった場合は接続を拒否する。

なお、図１２の処理シーケンスにおいて、端末１００ａがＡＰ２００ｂからのビーコン信号を受信する場合があるが、この場合は図１２（ｂ）と同様のハッシュ値照合を行い、計算結果が一致しなければ不正なＡＰであることが分かるので、誤ってＡＰ２００ｂに接続してしまうことはない。

また、本実施の形態２では、ＡＰ２００がインターネット接続機能を備えておらず、センターサーバ３００のＡＰテーブルに格納されているＡＰ固有鍵と、ＡＰ２００に格納されているＡＰ固有鍵との同期を簡単に取る手段がないため、ＡＰ２００の固有鍵を任意に更新することができない。そのため、ＡＰ２００の固有鍵が更新されず、古いままの状態で長期間使用されることになり、通信安全の観点から好ましくない。
そこで、ＡＰ２００の固有鍵（Ｋ_auth1）を通信の暗号化に用いるのではなく、ランダムに生成した暗号鍵をＡＰ２００の固有鍵で暗号化し、例えば図１２のステップＳ１２１２などで端末１００ａに配信するようにしてもよい。
端末１００ａは、ＡＰ２００の固有鍵（Ｋ_auth1）を用いてそのランダムに生成した鍵を復号し、以後の通信の暗号化に用いることができる。

以上で、本実施の形態２に係る鍵配信システムの鍵共有手順について説明した。
以下では、各機器の詳細構成について説明する。

図１３は、本実施の形態２に係るＡＰ２００の機能ブロック図である。
本実施の形態２に係るＡＰ２００は、インターネット接続機能を備えていないため、実施の形態１の図８で説明した情報保持部２０４とインターネット接続部２０５は備えていない。また、鍵付ハッシュ計算部２０２に代えて、認証部２０６を備える。

認証部２０６は、図１２（ｃ）で説明したような、端末１００の認証処理を行う。
認証部２０６は、その機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。

図１４は、本実施の形態２に係るセンターサーバ３００の機能ブロック図である。
本実施の形態２に係るセンターサーバ３００は、実施の形態１で説明した図９の構成に加え、鍵付ハッシュ計算部３０６を備える。

鍵付ハッシュ計算部３０６は、図１２のステップＳ１２０５で関連付け端末４００よりハッシュ値Ｃ２の要求を受けた際に、同値を計算し、インターネット通信部３０１を介して関連付け端末４００に送信する。
鍵付ハッシュ計算部３０６は、その機能を実現する回路デバイス等のハードウェアで構成することもできるし、ＣＰＵやマイコン等の演算装置上で実行されるソフトウェアとして構成することもできる。

図１５は、本実施の形態２に係る関連付け端末４００の機能ブロック図である。
本実施の形態２に係る関連付け端末４００は、実施の形態１で説明した図１０の構成に加え、無線通信部４０７を備える。
無線通信部４０７は、端末１００と無線通信を行うものであり、端末１００が備える無線通信部１０１と同種の通信機能を備える。

以上、各機器の詳細構成について説明した。これらの構成は一例であり、図１１や図１２で説明した処理シーケンスを実現できるものであれば、その趣旨を逸脱しない範囲での設計変更は許容される。

以上のように、本実施の形態２では、センターサーバ３００は関連付け端末４００にＡＰ２００ａの固有鍵（Ｋ_auth1）を送信し、関連付け端末４００はその固有鍵を端末１００ａに送信する。
そのため、ＡＰ２００ａがインターネット接続機能を備えていなくても、実施の形態１と同様に、ＡＰ２００ａの固有鍵（Ｋ_auth1）を端末１００ａとＡＰ２００ａで共有することができる。

また、本実施の形態２では、センターサーバ３００は、ＡＰ２００の固有鍵（Ｋ_auth1）を端末１００の固有鍵で暗号化して関連付け端末４００に送信し、さらには端末１００がＡＰ２００の固有鍵（Ｋ_auth1）を取得する際も、暗号化されたままで送受信が行われる。
そのため、ＡＰ２００の固有鍵（Ｋ_auth1）が平文のままで通信経路を流れることがなく、同鍵の漏洩の危険性が低減される。

また、本実施の形態２では、端末１００ａ、ＡＰ２００ａともに、それぞれ図１２（ｂ）（ｃ）で説明したようなハッシュ値照合による認証を行うので、設置者の意図しない不正な端末等に誤って接続してしまうことがなく、通信の安全性が確保される。

また、本実施の形態２では、関連付け端末４００は、ＡＰ２００の固有鍵（Ｋ_auth1）を端末１００の固有鍵で暗号化したＣ１を復号することなく、そのまま端末１００ａに配信するので、関連付け端末４００からＡＰ２００の固有鍵（Ｋ_auth1）が漏洩する危険性が低減される。

また、本実施の形態２において、ＡＰ２００の固有鍵（Ｋ_auth1）を通信の暗号化に用いるのではなく、ランダムに生成した暗号鍵をＡＰ２００の固有鍵で暗号化し、端末１００ａに配信するようにすることにより、ＡＰ２００の固有鍵（Ｋ_auth1）を更新しなくとも、常に暗号鍵を変更することができるので、通信の安全性が向上する。

実施の形態３．
本発明の実施の形態３では、実施の形態２と同様にＡＰ２００がインターネットに接続できない環境下において、端末１００とＡＰ２００で暗号鍵を安全に共有する別の手法について説明する。

図１６は、本実施の形態３に係る鍵配信システムの概略構成図である。以下、図１６の各ステップに従って、図１６の鍵配信システムが端末１００とＡＰ２００の間で鍵を共有する手順について説明する。
なお、関連付け端末４００は、データ通信、記録メディアを介したデータ交換等により、ＡＰ２００との間でデータの授受が可能であるものとする。

（１）ログイン〜（６）暗号化したＡＰ鍵を関連付け端末に送信
これらのステップは、図１１で説明したものと同様であるため、説明を省略する。
（７）鍵配信
関連付け端末４００は、暗号化したＡＰ２００の固有鍵を、ＡＰ２００に配信する。配信手段は、データ通信によるものでもよいし、記録メディアを介したデータ交換によるものでもよい。
（８）鍵共有
ＡＰ２００と端末１００の間で、ＡＰ２００の固有鍵を共有する。以後、端末１００とＡＰ２００の間の通信は、共有されたＡＰ２００の固有鍵を用いて暗号化される。
本ステップの処理は、実施の形態１の図２で説明したステップ（７）と同様である。

図１７は、本実施の形態３に係るＡＰ２００の機能ブロック図である。
本実施の形態３に係るＡＰ２００は、実施の形態１の図８で説明したインターネット通信部２０５に代えて、関連付け端末通信部２０７を備える。その他の構成は図８と同様である。
関連付け端末通信部２０７は、関連付け端末４００より、端末１００の固有鍵でＡＰ２００の固有鍵（Ｋ_auth1）を暗号化したＣ１を受信する。通信による受信に代えて、上述のように記録メディアを介したデータ交換によるものでもよい。

図１８は、本実施の形態３に係る関連付け端末４００の機能ブロック図である。
本実施の形態３に係る関連付け端末４００は、実施の形態２の図１５で説明した無線通信部４０７に代えて、ＡＰ通信部４０８を備える。その他の構成は図１５と同様である。
ＡＰ通信部４０８は、ＡＰ２００に、端末１００の固有鍵でＡＰ２００の固有鍵（Ｋ_auth1）を暗号化したＣ１を送信する。通信による受信に代えて、上述のように記録メディアを介したデータ交換によるものでもよい。

以上、各機器の詳細構成について説明した。これらの構成は一例であり、図１６で説明した処理シーケンスを実現できるものであれば、その趣旨を逸脱しない範囲での設計変更は許容される。

以上のように、本実施の形態３によれば、実施の形態２と同様の効果が得られる。

実施の形態４．
以上の実施の形態１〜３において、センターサーバ３００は、各機器の固有ＩＤを保持する端末テーブルおよびＡＰテーブルを格納したデータベースを備えることを説明した。また、関連付け端末４００は、各機器の固有ＩＤを関連付け情報としてセンターサーバ３００に送信し、その関連付け情報をＡＰテーブルに格納することを説明した。
本発明の実施の形態４では、この固有ＩＤを悪意ある第３者などに偽装されにくくする構成について説明する。

もし、悪意ある第３者にユーザの認証情報が漏洩すると、その第３者は、関連付け端末４００またはこれと同等の機能を有する端末を使用して、任意に生成したＩＤをセンターサーバ３００に送信することにより、購入していない機器を相互に関連付けることが可能となる。
そこで、機器の固有ＩＤをもって、そのＩＤが正規品のものであることを保証する仕組みを考える。

まず、端末１００やＡＰ２００の製造、出荷等の段階において、各機器の固有ＩＤを割り当てる際に、固有ＩＤを以下のように構成する。

（１）固有ＩＤの中に、ランダム文字列部分を構成する。
（２）そのランダム文字列部分と、センターサーバ３００の秘密鍵とで一意に生成した認証子を、固有ＩＤの中に含める。認証子の生成に際しては、十分な衝突耐性を備えた一方向関数を用いる。

機器の固有ＩＤを上記のように構成しておけば、その固有ＩＤを割り当てられた機器がセンターサーバ３００と関連付けられた正規品であることが分かるため、固有ＩＤを偽装される可能性を低減し、センターサーバ３００にて機器の関連付けを拒否するなどの適切な処置を行うことができる。
これにより、仮にユーザの認証情報が漏洩したとしても、第３者が各機器を不正に関連付けることが困難になるため、各機器同士で鍵を共有する際の安全性に加え、センターサーバ３００側での安全性も確保され、より安全に鍵の共有を行うことが可能となり、信頼性の高い鍵配信システムおよび鍵共有手順を提供することができる。

実施の形態５．
以上の実施の形態１〜４では、ユーザが関連付け端末４００を使用して、端末１００とＡＰ２００等の関連付けを行うことを説明したが、関連付け操作以外にも、機器ＩＤ等の登録、登録内容の変更、登録解除、機器所有権の譲渡、といった処理を実行できるように構成してもよい。

例えば、各機器の固有ＩＤは、製造、出荷等の段階で業者が各テーブルに設定するのみならず、ユーザが関連付け端末４００を使用して手動で設定するように構成してもよい。

また、センターサーバ３００は、ユーザが所持するＡＰが１つのみである場合、新規購入端末を自動的にそのＡＰに関連付けたり、別途ユーザのメールアドレスなどを登録した上で、関連付けを行う際に、ユーザに確認する処理を行うように構成してもよい。

また、各機器の固有ＩＤをＱＲコード化して各機器の筐体に貼り付けている場合は、関連付け端末４００が備えるカメラでＱＲコードを撮像した際に、センターサーバ３００のＵＲＬに自動的にジャンプするように構成しておくと、ユーザにとって便宜である。

実施の形態６．
以上の実施の形態１〜５において、ハッシュ値を用いて各認証処理を行う例を説明したが、ハッシュ値に代えて、暗号化した値を認証に用いるように構成してもよい。この場合は、ハッシュ関数Ｈ（）を共有するのではなく、暗号化・復号化関数を共有しておき、ハッシュ値の比較に代えて暗号化した値の比較により一致判定を行う。
これらの認証に用いるハッシュ値または暗号化した値を総称して、本発明における「暗号値」とする。

本発明において、ハッシュ値や暗号化した値は、一意の値が得られる一方向関数などを用いて安全に認証を行うことが目的であるため、必ずしもハッシュ関数や暗号関数を用いる必要はなく、これと同等の効果が得られる関数等を用いてもよい。

ハッシュ値に代えて暗号化した値を用いる場合は、各機器における「鍵付ハッシュ計算部」は、適宜「暗号化部」「復号部」などとして構成し、必要な処理を行うように構成すればよい。
なお、暗号化・復号化に用いる鍵は、上述の各実施の形態において、ハッシュ値を計算する際に用いている鍵を用いるように構成すればよい。

通信端末間で鍵共有を行う際の漏洩可能性について説明するものである。実施の形態１に係る鍵配信システムの概略構成図である。センターサーバ３００が保持する端末テーブルの構成説明図である。センターサーバ３００が保持するＡＰテーブルの構成説明図である。センターサーバ３００が保持するユーザテーブルの構成説明図である。端末１００ａとＡＰ２００ａがＡＰ２００ａの固有鍵を暗号鍵として共有する処理シーケンスを説明するものである。端末１００の機能ブロック図である。ＡＰ２００の機能ブロック図である。センターサーバ３００の機能ブロック図である。関連付け端末４００の機能ブロック図である。実施の形態２に係る鍵配信システムの概略構成図である。端末１００ａとＡＰ２００ａがＡＰ２００ａの固有鍵を暗号鍵として共有する処理シーケンスを説明するものである。実施の形態２に係るＡＰ２００の機能ブロック図である。実施の形態２に係るセンターサーバ３００の機能ブロック図である。実施の形態２に係る関連付け端末４００の機能ブロック図である。実施の形態３に係る鍵配信システムの概略構成図である。実施の形態３に係るＡＰ２００の機能ブロック図である。実施の形態３に係る関連付け端末４００の機能ブロック図である。

符号の説明

１００端末、１０１無線通信部、１０２接続先候補保持部、１０３接続先決定部、１０４乱数生成部、１０５乱数保持部、１０６鍵付ハッシュ計算部、１０７照合部、１０８固有鍵保持部、１０９復号部、１１０ＡＰ鍵保持部、２００ＡＰ、２０１無線通信部、２０２鍵付ハッシュ計算部、２０３ＡＰ鍵保持部、２０４情報保持部、２０５インターネット通信部、２０６認証部、２０７関連付け端末通信部、３００センターサーバ、３０１インターネット通信部、３０２鍵暗号化部、３０３関連付け決定部、３０４関連付け参照子保持部、３０５テーブル操作部、３０６鍵付ハッシュ計算部、４００関連付け端末、４０１インターネット通信部、４０２センターサーバアドレス保持部、４０３機器ＩＤ取得部、４０４テーブル操作要求生成部、４０５認証情報入力部、４０６関連付け指定部、４０７無線通信部、４０８ＡＰ通信部、５００インターネット。

Claims

通信端末間で暗号鍵を共有する方法であって、
いずれの前記通信端末同士が前記暗号鍵を共有するのかを示す関連付け情報を保持するサーバと、
前記サーバに前記関連付け情報を送信する関連付け端末と、
を設け、
前記サーバに各通信端末の固有鍵をあらかじめ格納しておき、
前記各通信端末は、固有のＩＤを有し、
前記関連付け端末は、前記ＩＤを撮像する撮像手段を備え、
前記暗号鍵は、該暗号鍵の共有対象である前記通信端末のうちの第１の通信端末の前記固有鍵であり、
前記サーバが、前記撮像手段によって撮像された前記各通信端末の前記ＩＤに基づいて、前記関連付け情報を生成するステップと、
前記サーバが前記関連付け端末を認証するステップと、
前記関連付け端末が前記サーバに前記関連付け情報を送信する関連付けステップと、
前記サーバが前記関連付け情報に基づき、前記暗号鍵を該暗号鍵の共有対象である前記通信端末のうちの第２の通信端末の固有鍵によって暗号化し、その暗号化されたものである暗号化暗号鍵を前記第１の通信端末及び前記関連付け端末のうち少なくとも１つに配信する鍵配信ステップと、
前記第２の通信端末が前記第１の通信端末に接続要求を発行する接続ステップと、
を有することを特徴とする鍵共有方法。
前記鍵配信ステップにおいて、
前記サーバは、前記暗号化暗号鍵を、前記第１の通信端末に配信する
ことを特徴とする請求項１に記載の鍵共有方法。
前記鍵配信ステップにおいて、
前記サーバは、前記暗号化暗号鍵を、前記関連付け端末に配信する
ことを特徴とする請求項１に記載の鍵共有方法。
前記鍵配信ステップにおいて、
前記サーバは、前記暗号化暗号鍵を、該第２の通信端末のＭＡＣアドレスとともに前記第１の通信端末に配信し、
前記接続ステップの後に、
前記第１の通信端末が、前記接続要求を発行した前記第２の通信端末のＭＡＣアドレスと前記鍵配信ステップで受信した前記ＭＡＣアドレスとを照合する照合ステップ
を有し、
前記照合ステップにおいて、
前記第１の通信端末は、前記接続要求を発行した前記第２の通信端末のＭＡＣアドレスと前記鍵配信ステップで受信した前記ＭＡＣアドレスとが一致した場合に限り前記接続要求を許可し、
前記第１の通信端末と前記第２の通信端末で前記暗号鍵を共有する
ことを特徴とする請求項２に記載の鍵共有方法。
前記接続ステップにおいて、
前記第２の通信端末は、前記第１の通信端末に前記接続要求を発行するとともに乱数を送信し、
前記接続ステップの後に、
前記第１の通信端末が前記暗号鍵を用いて前記乱数の暗号値を算出するステップと、
前記第１の通信端末が前記第２の通信端末に前記暗号値および前記暗号化暗号鍵を送信するステップと、
前記第２の通信端末が当該第２の通信端末の固有鍵で前記暗号化暗号鍵を前記暗号鍵に復号するステップと、
復号した前記暗号鍵を用いて前記乱数の暗号値を算出する検証ステップと、
を有し、
前記第１の通信端末が送信した暗号値と、前記検証ステップで算出した暗号値とが一致した場合に限り、
前記第１の通信端末と前記第２の通信端末で前記暗号鍵を共有する
ことを特徴とする請求項２または請求項４に記載の鍵共有方法。
前記接続ステップの後に、
前記第２の通信端末が前記関連付け端末に第１乱数を送信するステップと、
前記関連付け端末が前記サーバに前記第１乱数の暗号値の算出を要求し、前記サーバから該暗号値を受信するステップと、
前記関連付け端末が前記第２の通信端末に前記第１乱数の暗号値および前記暗号化暗号鍵を送信するステップと、
前記第２の通信端末が当該第２の通信端末の固有鍵で前記暗号化暗号鍵を前記暗号鍵に復号するステップと、
復号した前記暗号鍵を用いて前記乱数の暗号値を算出する第１検証ステップと、
を有し、
前記関連付け端末が送信した暗号値と、前記第１検証ステップで算出した暗号値とが一致した場合に限り、
前記関連付け端末と前記第２の通信端末で前記暗号鍵を共有する
ことを特徴とする請求項３に記載の鍵共有方法。
前記接続ステップの後に、
前記第１の通信端末が前記第２の通信端末に第２乱数を送信するステップと、
前記第２の通信端末が前記暗号鍵を用いて前記第２乱数の暗号値を算出するステップと、
前記第２の通信端末が前記第１の通信端末に前記暗号値を送信するステップと、
前記第１の通信端末が前記暗号鍵を用いて前記第２乱数の暗号値を算出する第２検証ステップと、
を有し、
前記第２の通信端末が送信した暗号値と、前記第２検証ステップで算出した暗号値とが一致した場合に限り、前記接続要求を許可する
ことを特徴とする請求項６に記載の鍵共有方法。
前記接続ステップの後に、
前記第１の通信端末が前記第２の通信端末に、前記暗号鍵で暗号化した第２暗号鍵を送信するステップを有し、
前記第２の通信端末は、
前記暗号鍵で前記第２暗号鍵を復号し、以後の通信の暗号化または復号化に用いる
ことを特徴とする請求項７に記載の鍵共有方法。
前記鍵配信ステップの後に、
前記関連付け端末は、前記暗号化暗号鍵を前記第１の通信端末に転送する転送ステップを有する
ことを特徴とする請求項３に記載の鍵共有方法。
前記鍵配信ステップにおいて、
前記サーバは、前記第２の通信端末のＭＡＣアドレスを前記関連付け端末に送信し、
前記転送ステップにおいて、
前記関連付け端末は、前記第２の通信端末のＭＡＣアドレスを前記第１の通信端末に転送し、
前記接続ステップの後に、
前記第１の通信端末が、前記接続要求を発行した前記第２の通信端末のＭＡＣアドレスと前記転送ステップで受信した前記ＭＡＣアドレスとを照合する照合ステップ
を有し、
前記照合ステップにおいて、
前記接続要求を発行した前記第２の通信端末のアドレスと前記転送ステップで受信した前記ＭＡＣアドレスとが一致した場合に限り前記接続要求を許可し、
前記第１の通信端末と前記第２の通信端末で前記暗号鍵を共有する
ことを特徴とする請求項９に記載の鍵共有方法。
前記接続ステップにおいて、
前記第２の通信端末は、前記第１の通信端末に前記接続要求を発行するとともに乱数を送信し、
前記接続ステップの後に、
前記第１の通信端末が前記暗号鍵を用いて前記乱数の暗号値を算出するステップと、
前記第１の通信端末が前記第２の通信端末に前記暗号値および前記暗号化暗号鍵を送信するステップと、
前記第２の通信端末が当該第２の通信端末の固有鍵で前記暗号化暗号鍵を前記暗号鍵に復号するステップと、
復号した前記暗号鍵を用いて前記乱数の暗号値を算出する検証ステップと、
を有し、
前記第１の通信端末が送信した暗号値と、前記検証ステップで算出した暗号値とが一致した場合に限り、
前記第１の通信端末と前記第２の通信端末で前記暗号鍵を共有する
ことを特徴とする請求項９または請求項１０に記載の鍵共有方法。
前記第１の通信端末及び前記第２の通信端末に、
前記サーバが固有に有する秘密鍵と乱数で生成した一意のＩＤをあらかじめ割り当てておき、
前記関連付けステップにおいて、
前記関連付け端末は、前記暗号鍵を共有する前記第１の通信端末及び前記第２の通信端末の前記ＩＤを前記関連付け情報として前記サーバに送信する
ことを特徴とする請求項１ないし請求項１１のいずれかに記載の鍵共有方法。
前記サーバは、
前記関連付け端末が送信した前記ＩＤを、前記秘密鍵を用いて検証し、
不正なＩＤである場合には、前記暗号鍵を共有する前記第１の通信端末と前記第２の通信端末との関連付けを拒否する
ことを特徴とする請求項１２に記載の鍵共有方法。
請求項１ないし請求項１３のいずれかに記載の第１の通信端末、第２の通信端末、サーバ、および関連付け端末を有することを特徴とする鍵配信システム。