ネットワークシステム
【課題】通信デバイス毎の認証鍵の設定が簡便に行えるネットワークシステムを提供することにある。
【解決手段】通信デバイス２は、認証鍵を順列に集合させた決まった長さの乱数からなるビットバーＢＢを記憶する記憶部２１と、ビットバーＢＢに基づいて自己の認証鍵を設定する認証鍵設定部３３と、設定された認証鍵を用いた他の通信デバイス２に対して通信認証を行う通信認証部３５とを備えている。ビットバーＢＢは、通信認証を行う複数の通信デバイス２間で事前に付与され、認証鍵設定部３３はビットバーＢＢから所定の基準に従って各通信デバイス２用の認識鍵を生成する。
【解決手段】通信デバイス２は、認証鍵を順列に集合させた決まった長さの乱数からなるビットバーＢＢを記憶する記憶部２１と、ビットバーＢＢに基づいて自己の認証鍵を設定する認証鍵設定部３３と、設定された認証鍵を用いた他の通信デバイス２に対して通信認証を行う通信認証部３５とを備えている。ビットバーＢＢは、通信認証を行う複数の通信デバイス２間で事前に付与され、認証鍵設定部３３はビットバーＢＢから所定の基準に従って各通信デバイス２用の認識鍵を生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムに関するものである。
【背景技術】
【０００２】
従来、図８（ａ）に示すようにネットワーク１に接続された照明器具、空調機器、パーソナルコンピュータ、デジタルＴＶ等通信機能を備えた通信デバイス２…相互で通信を行う際に、通信デバイス２が相手側通信デバイス２を認証する場合、第３者の認証用サーバ３を用いて認証鍵の発行と認証を行うようなっていた。
【０００３】
また一方図８（ｂ）に示すようにネットワークに接続されている通信デバイス１同士が直接通信を行うＰ２Ｐの場合には事前共有鍵（プリシェアード鍵）を入力していた。
【０００４】
二つの通信デバイス間で共通暗号化手順を実施するために共通鍵を発生させる装置としては例えば特許文献１に開示されている装置がある。
【特許文献１】特表平９−５０１５５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上述の図８（ａ）に示すネットワークシステムでは、通信デバイス数が増加すると、認証用サーバ３が持つ鍵を配布或いは交換するためのキーデータベースＫＤＢの存在の効果が現れてくる。一方図８（ｂ）のネットワークシステムの場合には通信デバイス数が少ない場合にはキーデバイスベースＫＤＢのコストが不要であるため都合が良いという利点がある。
【０００６】
しかしながら、何れのシステムの場合も、通信デバイス２の増減が発生すると通信デバイス２及びキーデータベースＫＤＢにおいて鍵管理の設定の手間がかかっていた。
【０００７】
本発明は、上述の点に鑑みて為されたもので、その目的とするところは通信デバイス毎の認証鍵の設定が簡便に行えるネットワークシステムを提供することにある。
【課題を解決するための手段】
【０００８】
上述の目的を達成するために、請求項１の発明では、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とする。
【０００９】
請求項１の発明によれば、通信デバイスで共用する認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
【００１０】
請求項２の発明では、請求項１の発明において、前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする。
【００１１】
請求項２の発明によれば、設定した認証鍵基礎数の乱雑度を最大限に活用でき、認証鍵の強度を高く保てることができる。
【００１２】
請求項３の発明では、請求項２の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
【００１３】
請求項３の発明によれば、長さが固定である認証鍵の生成において、均等分割によって乱雑度を最大限に高めたブロックを基にするので、認証鍵の強度を高く保てる。
【００１４】
請求項４の発明では、請求項２の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
【００１５】
請求項４の発明によれば、通信デバイスがアドホック的に存在する場合で、通信デバイス数が設定した認証鍵基礎数の期待数よりも多く通信デバイスが存在しても、乱数の乱雑度を保ったまま固定長の認証鍵を生成することができる。
【００１６】
請求項５の発明では、請求項１の発明において、前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする。
【００１７】
請求項５の発明において、ポインタ手段が指し示す最後のビット位置によって認証鍵の割当てができるので、通信デバイスでの認証鍵の割当て処理が簡便になる。
【００１８】
請求項６の発明では、請求項１乃至５の何れかの発明において、前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする。
【００１９】
請求項６の発明によれば、認証鍵基礎数による認証鍵群の更新を、割当て移行認証手順を経て各通信デバイス間で自立的且つ安全に行え、そのため認証鍵基礎数の再設定が簡便に行える。
【００２０】
請求項７の発明では、請求項６の発明において、前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする。
【００２１】
請求項７の発明によれば、認証鍵の更新時に参加していなかった通信デバイスも、それ以降において認証鍵を更新することができる。
【００２２】
請求項８の発明では、請求項２乃至４、６、７の何れかの発明において、各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする。
【００２３】
請求項８の発明によれば、通信デバイスの順番が決められることで、認証鍵が第３者に漏れても、通信デバイスの順番を監視することで介入を防ぐことができる。
【発明の効果】
【００２４】
本発明は、共用認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、各通信デバイスは認証鍵を持つことができるもので、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
【発明を実施するための最良の形態】
【００２５】
以下本発明を実施形態により説明する。
（実施形態１）
本実施形態は、例えば図２（ａ）に示すようにネットワーク１上に照明器具、空調機器、パーソナルコンピュータ、デジタルＴＶ等通信機能を備えた通信デバイス２（２１〜２ｎ）を複数接続し、通信デバイス２の相互間で通信を行うネットワークシステムであるが、例えば図２（ｂ）に示すように認証鍵Ｋ（１）…を順列に集合させた決まった長さの乱数からなる認証鍵基礎数（以下ビットバーと称する）ＢＢを、相互に通信する通信デバイス２に生成設定する点に特徴がある。
【００２６】
ビットバーＢＢは、通信デバイス２群に対して、共通に保持する事前鍵であって、その配布は工場出荷時に通信デバイス２の記憶部に書き込む、或いはネットワークで配布する、更にはＩＣカードやＵＳＢメモリ等外部メモリデバイスに保持し、各通信デバイス２のメモリスロットに挿入することで保持させる等種々の方法で行う。
【００２７】
そして全通信デバイス２（２１〜２ｎ）で同じ値のビットバーＢＢを保持して後述する認証鍵生成方法により認証鍵を各通信デバイス２（２１〜２ｎ）で設定することになる。
【００２８】
ビットバーＢＢ自体の生成は、ビットバーＢＢを生成する専用装置を用い、この装置で生成したビットバーＢＢを上述の外部メモリデバイスに記憶させる方法や工場出荷時に通信デバイス２の記憶部に書き込むか、ネットワーク１を通じて通信により配布する。またネットワーク１上にビットバーＢＢの生成・配布のみを専ら行う通信デバイス２を設けても良く、更には通信デバイス２の一つに生成機能を持たせ、ネットワーク１を通じて配布するようにしても良い。
【００２９】
さて本実施形態に用いる通信デバイス２は、図１（ａ）に示すようにＣＰＵ２０と、記憶部２１と、通信部２２とをバス２３により接続した構成を基本的なハードウェア構成として備えている。
【００３０】
ＣＰＵ２０は、通信デバイス２固有の機能部（図示せず）の制御、通信部２２による通信制御、更に記憶部２１の書き込みや読み出しの制御、更に認証、乱数などの処理を行う。
【００３１】
記憶部２１は、プログラムを格納しているＥＥＰＲＯＭ２１ａと、実行中のプログラムの保持、更に諸データの保持を担うＲＡＭ２１ｂとから構成される。
【００３２】
通信部２２はネットワーク１に接続するためのイーサネット（登録商標）に対応したＬＡＮ用通信部２２ａや、ＲＳ２３２Ｃ対応の汎用通信部２２ｂとを備えている。
【００３３】
ここで、本実施形態に用いる通信デバイス２のＣＰＵ２０には、図１（ｂ）に示すように配布されたビットバーＢＢを記憶部２１のＥＥＰＲＯＭ２１ａ或いはＲＡＭ２１ｂに記憶させるビットバー記憶処理部３２、記憶されたビットバーＢＢを基に、後述する認証鍵Ｋ（ｉ）を生成して設定する認証鍵設定部３３、設定された認証鍵ＫをＲＡＭ２１ｂに記憶させる認証鍵記憶処理部３４、更に記憶した認証鍵Ｋを用いて通信を認証する通信認証部３５を基本的に備え、また後述するように認証鍵Ｋ（ｉ）を生成時においてハッシュ処理する場合にはハッシュ処理部３６を、またビットバー更新を行う場合にはビットバー更新部３７を、ポインタ処理を行う場合にはポインタ処理部３８を機能して備える。
【００３４】
また通信デバイス２に、ビットバーＢＢを生成する機能を持たせる場合には、乱数生成部３０を図１（ｃ）に示すように持たせ、その乱数生成部３０を働かせるか働かせないかで、ビットバーＢＢの配布兼用の通信デバイスとして用いることができるようなっており、その乱数生成部３０を働かせるか否かは、設定部３１で設定する。
【００３５】
次に本発明におけるビットバーＢＢを用いた認証鍵Ｋの生成方法を実施例により説明する。
（実施例１）
本実施例では、各通信デバイス２（２１〜２ｎ）が稼動すると、工場出荷時、記憶媒体による配布、ネットワーク１を通じた配布等によって、例えばＥＥＰＲＯＭ２１ａに既に記憶してあるビットバーＢＢから認証鍵設定部３３により所定のビット長さの認証鍵Ｋを生成する。
【００３６】
この場合、予め工場出荷時に設定されている通信デバイス２の接続最大数等の所定数ｎで均等分割し、均等分割したブロックＫｂ１〜Ｋｂｎにインデックスを付して夫々で認証鍵Ｋ（１）〜Ｋ（ｎ）を生成する。
【００３７】
図３（ａ）はビット長さＬのビットバーＢＢをｎ等分して状態を示す。ここで、認証鍵Ｋ（１）〜Ｋ（ｎ）のビット長さＬｅは所定数ｎでビットバーＢＢを均等分割して得られるブロックＫｂ（Ｋｂ１〜Ｋｂｎ）のビット長に固定したものとする。
【００３８】
そして通信デバイス２（２１〜２ｎ）のＣＰＵ２０の認証鍵設定部３３は、工場出荷時に付されたシリアル番号、通信アドレス、ＭＡＣアドレス、オブジェクトＩＤなどの番号順、或いはランダム、予め指定された設定順、種別等に基づいて自己の認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当て、生成設定した認証鍵Ｋ（１）〜Ｋ（ｎ）を例えばＥＥＰＲＯＭ２１ａに記憶保持する。
【００３９】
ここで、シリアル番号、通信アドレス、ＭＡＣアドレス、オブジェクトＩＤなどの番号順を用いる場合には、通信デバイス２（２１〜２ｎ）群は、事前に各通信デバイス２が自己の番号を送信して互いのシリアル番号を取得し合い、そのリストを作成するとともに、シリアル番号のソート処理を行い、シリアル番号の若い順にビットバーＢＢの上位或いは下位から認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当てる。ＭＡＣアドレスを用いる場合にはＡＲＰテーブルを参照することで実現することもできる。
【００４０】
また、各通信デバイス２（２１〜２ｎ）が通信を行った順番を監視し、どの通信デバイス２（２１〜２ｎ）が通信を開始したかという順番のリストを保持し、その順番で認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当てるようにしても良い。
【００４１】
ところで、上述の場合ｎ個の通信デバイス数によって均等分割したブロックにより認証鍵Ｋ（ｉ）を設定しているが、実際にネットワーク１に接続される通信デバイス数がｎ個より少ない場合には、例えば上位から順次割り当てた場合、余剰のブロックは捨てるものとする。
【００４２】
尚通信デバイス数を動的に検出する方法としては、例えばブロードキャストピングを用いる方法を用いて行う。ここで全ての通信デバイス２（２１〜２ｎ）がＴＣＰ／ＩＰの実装を持ち、ブロードキャストピングに応答するものとする。そしてブロードキャストピングのエコーリクエストを送信した通信デバイス２において、タイムアウト期間を設け、その期間内のエコーリプライの応答数をカウントする。これにより動的に現在稼動中の通信デバイス数を検出することができるのである。ブロードキャストは、通信デバイス２が同一セグメント内に存在することが条件となるが、例えばマルチキャストを持ち入ればセグメントを跨るネットワークにも対応することができる。
【００４３】
また認証鍵Ｋ（ｉ）のビット長さが固定長Ｌｅでない暗号通信、例えばワンタイムパッド（ＯＴＰ）の暗号方式などでは、メッセージ長分の認証鍵Ｋ（ｉ）のビット長さ必要であるが、本実施例の場合のように均等分割したブロックＫｂｉのビット長さＬｅが、メッセージ長より長いければ不要部分は切り捨てする。
【００４４】
上述の場合、ビットバーＢＢを所定の通信デバイス数ｎで均等分割したブロックＫｂｉで認証鍵Ｋ（ｉ）を設定しているが、実際の稼動中の通信デバイス数でビットバーＢＢを均等分割してブロックを設定する場合、通信デバイス数が上述のｎより少ない（ｎ−α）と一つのブロックＫｂｉのビット長さＬｂは認証鍵Ｋ（ｉ）のビット長さＬｅよりも長くなる。この場合は、一つのブロックＫｂｉから認証鍵Ｋ（ｉ）のビット長Ｌｅを切り取り余った分を捨てる。
【００４５】
図３（ｂ）はこの場合のビットバーＢＢにおけるブロックＫｂｉのビット長と認証鍵Ｋ（ｉ）のビット長さＬｅの関係を示す。
【００４６】
ところで、稼動中の通信デバイス数でビットバーＢＢを均等分割する場合、通信デバイス数が上述のｎよりも大きい（ｎ＋α）の場合には、一つのブロックＫｂｉのビット長さＬｂは認証鍵Ｋ（ｉ）のビット長さＬｅよりも短くなる、
この場合は、ブロックＫｂｉの先頭からＬｅのビット長さだけ切り取り、この切り取った部分で認証鍵Ｋ（ｉ）を設定する。
【００４７】
図３（ｃ）はこの場合のビットバーＢＢにおけるブロックＫｂｉのビット長と認証鍵Ｋ（ｉ）のビット長さＬｅの関係を示す。
【００４８】
また認証鍵Ｋ（ｉ）に対応するブロックＫｂ（ｉ）がビットバーＢＢの最後尾のブロックで、ビット長さＬｅの範囲がビットバーＢＢの範囲を超えるときには、図３（ｄ）に示すように越える部分Ｌｔを先頭のブロックＬ１から補う。
（実施例２）
本実施例も、実施例１と同様に認証鍵Ｋ（ｉ）が固定のビット長さＬｅで、ビットバーＢＢの長さがＬｒとした場合において、稼動中の通信デバイス数が所定数ｎよりも小さい（ｎ−α）場合、つまりＬｅ≦Ｌｅ／（ｎ−α）である場合は、通信デバイス２のＣＰＵ２０のハッシュ処理部３６の処理によって図４（ａ）に示すようにブロックＫｂｉをハッシュし、認証鍵設定部３３はこのハッシュした値により認証鍵Ｋ（ｉ）を設定する。
【００４９】
また、通信デバイス数が所定数ｎが大きい（ｎ＋α）場合、つまりＬｅr／（ｎ＋α））である場合は、図４（ｂ）に示すように認証鍵（Ｋｉ）はブロックＫｂｉの先頭のビットからＬｅの長さまでのブロックのハッシュをハッシュ処理部３６の処理で行い、認証設定部３３はこのハッシュした値により認証鍵Ｋ（ｉ）を設定する。
【００５０】
また、ブロックＫｂｉがビットバーＢＢの最後尾であり、且つＬｅの長さの範囲がビットバーＢＢの範囲を越えるときは実施例１の図３（ｄ）の場合と同様に、越えた部分Ｌｔを先頭のブロックＫｂ１から補うこととする。
【００５１】
上述の場合は、Ｌｅの長さがハッシュの長さと同じであるが、Ｌｅの長さがハッシュの長さより長い場合、図４（ｃ）のようにハッシュの長さを組み合わせ、Ｌｅの長さと一致させる補正としてｑとすると、複数ｍのブロックをハッシュした長さ（Ｈａｓｈ ｓｉｚｅ）の和からｑをはぎ取るようにする。つまり認証鍵Ｋ（ｉ）は、Ｌｅ＝（Hash size)×ｍ−ｑによって設定される。
【００５２】
以上のように何れかの実施例によって事前鍵であるビットバーＢＢから各通信デバイス２（２１〜２ｎ））は夫々において認証鍵Ｋ（ｉ）を生成設定する。
【００５３】
尚、通信デバイス２がネットワーク１上から取り外されたり、稼動を停止する場合は、通信デバイス数が経るため、当該通信デバイス２ｉが認証鍵Ｋ（ｉ）に用いていたブロックＫｂｉを空きブロックする。逆に新たに通信デバイス２ｉがネットワーク１に接続されて稼動している場合、空きブロックがあれば当該ブロックを認証鍵設定のブロックとしてあてがい、もしなければ全体の認証鍵生成を実施例１或いは実施例２により構成し直す。
【００５４】
次に上述のように生成された認証鍵Ｋ（ｉ）を用いた認証方法を例により説明する。
【００５５】
（例１）
本例は図５（ａ）に示すように例えば、２つの通信デバイス２ａと２ｂとの間で暗号技術を用いてチェレンジレスポンス認証方法である。尚通信デバイス２ａの認証鍵をＫ（ａ），通信デバイス２ｂの認証鍵をＫ（ｂ）とする。
【００５６】
まず通信デバイス２ａ，２ｂの間で一方を認証する場合には、１）、２）の方法がある。
【００５７】
１）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きにより通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ａ宛に送る。
【００５８】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）で暗号を復号化し、自己が送信したナンス値Ｎａの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。
【００５９】
２）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）で復号化してナンス値Ｎａを通信デバイス２ａに送る。
【００６０】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。
【００６１】
通信デバイス２ｂと通信デバイス２ａとの間で相互認証を行う場合、３）、４）の方法がある
３）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを復号化し、この復号によって得たナンス値Ｎａと、ナンス値Ｎｂを共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎｂ｝Ｋ（ａ）（ｂ）、Ｎａを通信デバイス２ａに送る。
【００６２】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られれば、通信相手が通信デバイス２ｂであると認証し、更に共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを復号化し通信デバイス２ｂ宛にＮｂを送る。
【００６３】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ａであると認証する。
【００６４】
４）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを暗号化し、この暗号化した値と所定のナンス値Ｎｂ、｛Ｎａ｝Ｋ（ａ）（ｂ）、Ｎｂを通信デバイス２ａに送る。
【００６５】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られれば、通信相手が通信デバイス２ｂであると認証し、更に共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを復号化し通信デバイス２ｂ宛にＮｂを送る。
【００６６】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを復号化し、自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。そして共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを暗号化し、｛Ｎｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。
【００６７】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを複合化し、自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ａであると認証する。
【００６８】
（例２）
本例は、ＩＳＯ／ＩＥＣの９７８−２標準として２者間の通信の認証する方法であって、片方向認証としてはタイムスタンプを用いて方法と、ナンス値を用いた方法とがある。
【００６９】
１）タイムスタンプを用いた片方向認証方式では、図５（ａ）において、一方の通信デバイス２ａが他方の通信デバイス２ｂにタイムスタンプＴａと、メッセージＢとを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｔａ，Ｂ｝Ｋ（ａ）（ｂ）を送る。これを受け取った通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ａ）（ｂ）で復号化し、送られてきたメッセージＢが自己宛のメッセージであれば、相手を識別して認証するのである。
【００７０】
２）ナンス値を用いて相互認証を行う場合、まず一方の通信デバイス２ｂのＣＰＵ２０の通信認証部３５はナンス値Nｂを他方の通信デバイス２ａ宛に送る。通信デバイス２ａのＣＰＵ２０の通信認証部３５は受け取ったナンス値Nｂと、自己のナンス値Ｎａと、通信デバイス２ｂへのメッセージを識別するための値Ｂとを、共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎａ，Ｎｂ、Ｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。
【００７１】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ａ）（ｂ）で復号化し、自己のナンス値Ｎｂと復号化したナンス値Ｎａとを共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎａ，Ｎｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ａ宛に送る。
【００７２】
このようにして通信デバイス２ａ、２ｂは自己のナンス値Ｎａ，Ｎｂが送り消されることで、相互を認証するのである。
【００７３】
（例３）
本例はNeedham-Schroederのような第三者認証に対応するものである。
【００７４】
まず本例では、通信デバイス２ａと２ｂの間で直接認証を行わず、信頼できる第三者の通信デバイス（ここでは２Ｐとする）
まず、通信デバイス２ａのＣＰＵ２０の通信認証部３５は、通信デバイス２Ｐに対して、送信したい通信相手の識別のために通信デバイス２ａ，２ｂの値Ａ、Ｂ及びナンス値Ｎａを送信する。
【００７５】
通信デバイス２ＰＣＰＵ２０の通信認証部３５は、通信デバイス２ａと通信デバイス２Ｐの間の共通認証鍵Ｋ（ａ）（ｐ）でナンス値Ｎａと、値Ｂ，Ａと、通信デバイス２ａ、２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）、及び２ｂのみが復号できるように共通認証鍵Ｋ（ａ）（ｂ）と、値Ａとを通信デバイス２ｂ、２Ｐの間の共通認証鍵Ｋ（ｂ）（ｐ）で暗号化し、更に共通認証鍵Ｋ（ａ）（ｐ）で暗号化し、｛Ｎａ，Ｂ，Ｋ（ａ）（ｂ），｛Ｋ（ａ）（ｂ）、Ａ｝Ｋ（ｂ）（ｐ）｝Ｋ（ａ）（ｐ）として通信デバイス２ａに送る。
【００７６】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ｂ）（ｐ）で復号し、｛Ｋ（ａ）（ｂ）、Ａ｝Ｋ（ｂ）（ｐ）を通信デバイス２ｂ宛に送る。
【００７７】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ｂ）（ｐ）でそのメッセージを復号し、Ｋ（ａ）（ｂ）を得る。そして得られた共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを暗号化し、通信デバイス２ａ宛に送る。
【００７８】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は、そのメッセージを共通認証鍵Ｋ（ａ）（ｂ）で復号し、受け取った証しとして通信デバイス２ｂにナンス値Ｎｂから１引いた値を共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、通信デバイス２ｂに送る。通信デバイス２ａのＣＰＵ２０の通信認証部３５は、そのメッセージを共通認証鍵Ｋ（ａ）（ｂ）で復号し、ナンス値Ｎｂから１引かれていることで、認証されたことを確認する。
【００７９】
（例４）
本例は、ＩＳＯ／ｌＥＣの９７９８−３標準として公開鍵暗号を用いた認証方式に対応する。
【００８０】
１）タイムスタンプを用いた片方向認証方式の場合、通信デバイス２ａから通信デバイス２ｂにＣＡ（ＰＫａ），Ｔａ，Ｂ，ＳｌＧＮ（Ｔａ，Ｂ）ＰＫａ−１を送る。
【００８１】
この場合、認証としてタイムスタンプを用いるためナンス値は必要としない。またＣＡ（ＰＫａ）は通信デバイス２ａの公開鍵Ｐｋａの証明書に含まれる例を示す。Ｔａはタイムスタンプを示す。更にＢは通信デバイス２ｂへのメッセージであるという識別の値を示し、ＳＩＧＮ（Ｔａ，Ｂ）ＰＫａ−１は通信デバイス２ａの公開鍵に対する秘密鍵ＰＫａ−１でデジタル署名を行っていることを示す。
【００８２】
２）ナンス値を用いた相互認証方式の場合には、通信デバイス２ｂから通信デバイス２ａにナンス値Ｎｂをまず送る。通信デバイス２ａからは通信デバイス２ａの公開鍵ＰＫａを含む証明書ＣＡ（ＰＫａ），通信デバイス２ａのナンス値Ｎａ，通信デバイス２ｂへのメッセージの識別の値Ｂ，Ｎａ，Ｎｂ，Ｂを秘密鍵ＰＫａ−１でデジタル署名して、
ＣＡ（ＰＫａ），Ｎａ，Ｂ，ＳＩＧＮ（Ｎａ，Ｎｂ，Ｂ）ＰＫａ−１を通信デバイス２ｂに送る。
【００８３】
通信デバイス２ｂは、通信デバイス２ａに、通信デバイス２ｂの公開鍵ＰＫｂを含む証明書ＣＡ（ＰＫｂ）、通信デバイス２ａへのメッセージの識別の値ａ，ナンス値Ｎｂ，Ｎａを秘密鍵ＰＫｂ−１でデジタル署名して、ＣＡ（ＰＫｂ），Ａ，ＳＩＧＮ（Ｎｂ，Ｎａ，Ａ）ＰＫｂ−１を通信デバイス２ａに送る。尚（）内は共通認証鍵Ｋ（ａ）（ｂ）で暗号化されていることを示す。
【００８４】
（例５）
本例は、暗号よりも処理が高速なハッシュ系の技術でKryptoKnightのＭＡＣを用いた２者間の認証プロトコルを用いるものである。
【００８５】
まず、通信デバイス２ａから通信デバイス２ｂに非暗号のナンス値Ｎａを送る。そして通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、非暗号のナンス値Ｎｂと共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａ，Ｎｂと通信デバイス２ｂからのメッセージを識別する値ＢをＭＡＣ処理し、Ｎｂ，ＭＡＣ（Ｎａ，Ｎｂ，Ｂ）Ｋ（ｂ）（ａ）として通信デバイス２ａに送る。
【００８６】
通信デバイス２ａは同様にナンス値Ｎａ、ＮｂをＭＡＣ処理し、通信デバイス２ｂにＭＡＣ（Ｎａ，Ｎｂ）Ｋ（ａ）（ｂ）として送る。
【００８７】
このようにＩＳＯ／ＩＥＣの標準の例では、タイムスタンプ方式を除けば、ナンス値を用いた認証方式は多岐に渡る。
【００８８】
以上の認証方法の例は二つの通信デバイス２ａ，２ｂ間の片方若しくは双方向の認証方法であったが、通信デバイス２ａ…間でグループを形成する場合の認証方法を例６，例７により説明する。
【００８９】
（例６）
本例は、多数決の方法をとったグループ認証方法である。
【００９０】
例えば図５（ｂ）に示すように複数の通信デバイス２ａ，２ｂ，２ｃ、２ｄが、或る認証子（ＩＤ）又はポリシーを持ち、通信デバイス間で連係動作するためのグループを形成したいとする。例えば図１（ａ）に示すシステムで通信デバイス２ａのＣＰＵ２０の通信認証部３５が、自己のは認証鍵Ｋ（ａ）を用いて暗号化して認証子（ＩＤ）或いはポリシーをブロードキャストで送信したする。ここで認証鍵Ｋ（ａ）は既に認証されているので、受信側の通信デバイス２ｂ〜２ｄは送信元が通信デバイス２aであることがわかる。
【００９１】
次に認証子（ＩＤ）又はポリシーの条件によって、通信デバイス２ａ以外の通信デバイス２ｂ〜２ｄの内、或る通信デバイス２ｊはＡＣＫ（許可）を返し、或る通信デバイス２mはＮＡＫ（不許可）を返すとする。ここで通信デバイス２aのＣＰＵ２０の通信認証部３５は、各通信デバイス２ｂ〜２ｎからの応答のＡＣＫ，ＮＡＫを受信してそれぞれの応答数をカウントする。ここで、閾値ＢＬを事前に設定しておき、閾値ＢＬをＡＣＫの総数が超えれば通信デバイス２ａ〜２ｄのグループ内で通信デバイス２aは認証されたこととなる。
【００９２】
ここで、閾値ＢＬは、通信デバイス２の全数（n数）を上述のように動的に検出し、閾値ＢＬの値を調停する。又は工場出荷時に設定するなどしても良い。
【００９３】
このようにして、グループ内での通信デバイス２の認証が可能となる。ここで、認証子（ＩＤ）の代わりにポリシー等アクセス権に関わる情報をやり取りしても良い。
【００９４】
そして予め定めている下限値ＬＭを、参加通信デバイス数が下回る場合にはグループ内の認証が成立しないものする。
【００９５】
（例７）
本例は、ビットバーＢＢによって既に配布されている認証鍵によって、ブロードキャスト、マルチキャスト、ユニキャスト等の方法で配布する個別鍵からグループの認証方法である。
【００９６】
つまり、個別鍵生成を利用してストックされた鍵を各通信デバイス２が蓄積し、ストックＳＫａ…を生成し、このストックＳＫａ…の生成後、ストックＫａ…を結合しグループ鎚を生成する。
【００９７】
この場合、単純にストックした値をビットバーＢＢの通信デバイス２の順番でグループ化とするか、ＧＫ（ａ）（ｂ）（ｃ）＝ＨＡＳＨ（ＳＫａ｜ＳＫｂ｜ＳＫｃ｜…）とハッシュを計算する。ここで通信デバイス２ｄが例６のグループ認証の結果ＮＡＫで不許可であったとしても、通信デバイス２ｄを含めて、グループ鍵を生成しても良く、また、その逆で、ＮＡＫで不許可であった通信デバイス２ｄを含めず、グループ鍵を生成しても良い。これはシステムのポリシーに依存する。
【００９８】
ところで、ビットバーＢＢは、工場出荷時などで秘密裏に各通信デバイス２に共有されることを前提とするため、一旦その値が悪意の第三者に漏れると、安全上の脅威となってしまう。
【００９９】
そこで、本実施形態では、第三者に漏れても通信デバイス２群の通信を終始監視し、ｓの間に介入していなければ、安全に更新する方法を採用している。
【０１００】
まず、ビットバーＢＢを図１（ａ）のシステムにおいて、更新したい通信デバイス２１〜２ｎまでの全てが稼動している場合、古い認証鍵で各通信デバイス２１〜２ｎが新しいビットバーＢＢのブロックＫｂを渡し合い、各通信デバイス２１〜２ｎの順番に或るブロックと置き換える。つまり、通信デバイス２Ｋは当該通信デバイス２Ｋに割り当てられたビットバーＢＢのブロックＫｂｋの認証鍵Ｋ（Ｋ）に対応して、ＣＰＵ２０のビットバー更新部３７によってブロックＫｂｋのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（Ｋ）’とする。この部分鍵Ｋ（Ｋ）’を現在の認証鍵Ｋ（Ｋ）で暗号化し、自己を除いた全通信デバイス２１〜２ｎに更新メッセージとして送信する。全通信デバイス２１〜２ｎは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２Ｋから送信された更新メッセージの認証鍵Ｋ（Ｋ）でメッセージを復号し部分鍵Ｋ（Ｋ）’を得る。同様にして、全ての通信デバイス２１〜２ｎが更新メッセージを送信し、全通信デバイス２１〜２ｎが全ての部分鍵Ｋ（１）’〜Ｋ（ｎ）’を得たならば、これを結合し新たなビットバーＢＢとする。
【０１０１】
図６は通信デバイス２ａで当該通信デバイス２ａに割り当てられたビットバーＢＢ０のブロックＫｂａの認証鍵Ｋ（ａ）に対応して、ブロックＫｂaのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（ａ）’とし、これを結合し新たなビットバーＢＢ１とする。またこの部分鍵Ｋ（ａ）’を現在の認証鍵Ｋ（ａ）で暗号化（図では＋を入れた○印で示す）し、例えば通信デバイス２ｂに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス２ｂは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２ａから送信された更新メッセージの認証鍵Ｋ（ａ）でメッセージを復号し部分鍵Ｋ（ａ）’を得る。通信デバイス２ｂが部分鍵Ｋ（ａ）’を得たならば、これを結合し新たなビットバーＢＢ１としている。その後同様に新しい部分鍵Ｋ（ａ）”を生成し、この部分鍵Ｋ（ａ）”を用いてビットバーＢＢ１をＢＢ２に更新している。
【０１０２】
また、通信デバイス２１〜２nまでの全ての通信デバイスが起動していない場合、必ずしもビットバーＢＢを更新したい全ての通信デバイス２１〜２ｎが更新時に起動しているとは限らない。そこで、更新期限があったとすれば、更新期限内に参加していない通信デバイス２の場合はそのまま古いブロックを部分鍵とする。この場合、新しいブロックＫでの認証鍵を使ったメッセージを更新期限内に起動していなかった通信デバイスが受信した場合、メッセージを復号できない問題がある。この場合は、再更新の方法として、通信デバイス２が復号できない旨を伝え、通信デバイス２が古い認証鍵で認証されると、その通信デバイス２を除く全応答可能通信デバイス２は保持しておいた古い認証鍵で暗号化してその通信デバイス２に送るようにすることで更新する。
【０１０３】
その他の更新方法としては、ビットバーＢＢの更新方法として複数のビットバーＢＢの履歴を持ち、古いビットバーＢＢから新しいビットバーＢＢを構築する方法もある。例えば、或る期間には起動していなかった通信デバイス２があり、古い認証鍵しかなかった場合、この通信デバイス２のビットバーＢＢを更新する方法として新しいビットバーＢＢを持つ通信デバイス２と古いビットバーＢＢを持つ通信デバイス２は常に時間又は回数（カウンタ）による履歴の管理を行い、ビットバーＢＢの時間又は回数を確認し、更新した時期のビットバーＢＢで通信させ、後に上述のビットバーＢＢの更新方法で更新する方法もある。
【０１０４】
つまり、例えば、通信デバイス２Ｋにおいて、ビットバーＢＢから認証鍵Ｋ（Ｋ）を生成設定する際にＣＰＵ２０のビットバー更新部３７がビットバー履歴を作成して例えばＥＥＰＲＯＭ２１ａに保持する。そして更新に当たっては部分鍵Ｋ（Ｋ）’を乱数で生成する。この部分鍵Ｋ（Ｋ）’のサイズは認証鍵Ｋ（Ｋ）と同じブロックのビット長さとする。部分鍵Ｋ（Ｋ）’を古い認証鍵Ｋ（Ｋ）で暗号化して履歴付で自己を除く全通信デバイス２１〜２ｎに送信する。全通信デバイス２１〜２ｎは受け取ったメッセージを履歴に対応する古い認証鍵Ｋ（Ｋ）で復号し、送った相手（２Ｋ）に割り当てられたビットバーＢＢのブロックＫｂｋを部分鍵Ｋ（Ｋ）’で更新するのである。
【０１０５】
図７は通信デバイス２ａで当該通信デバイス２ａに割り当てられたビットバーＢＢ０のブロックＫｂａの認証鍵Ｋ（ａ）に対応して、ブロックＫｂaのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（ａ）’とし、この部分鍵Ｋ（ａ）’で自己の現在のビットバーＢＢ０を更新するとともに、このビットバーＢＢ０の履歴を作成し、この履歴作成後、現在の認証鍵Ｋ（ａ）で暗号化（図では＋を入れた○印で示す）し、古いビットバーＢＢ０を用いていることを示す、つまり履歴（更新時間、更新回数、識別子等）を示すメッセージＢＢ０＿ＩＤとともに、例えば通信デバイス２ｂに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス２ｂは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２ａから送信された更新メッセージの認証鍵Ｋ（ａ）でメッセージを復号し部分鍵Ｋ（ａ）’を得る。通信デバイス２ｂが部分鍵Ｋ（ａ）’を得たならば、これを結合し新たなビットバーＢＢ１とし、また現在のビットバーＢＢ０の履歴を作成する。
【０１０６】
図７では、新たに通信デバイス２ｃが参加した場合を示しており、この通信デバイス２ｃは古いビットバーＢＢ０を持つものであるので、例えば通信デバイス２ａに認証を受ける場合、ナンス値を通信デバイス２ａと共通の認証鍵Ｋ（ａ）（ｃ）で暗号化し、メッセージＢＢ０＿ＩＤとともに通信デバイス２ａ宛に送る。一方通信デバイス２ａでは受け取った履歴を示すメッセージＢＢ０＿ＩＤに基づいて対応する古いビットバーＢＢ０による共通の認証鍵Ｋ（ａ）（ｃ）を選択してナンス値を復号し、通信デバイス２ｃに返えす。これにより通信デバイス２ｃは認証が成功したことを知ることになる。これにより認証鍵更新時に参加していなかった通信デバイス２ｃも認証後、更新できることになる。
【０１０７】
以上のように本実施形態では、上述したビットバーＢＢを事前鍵として各通信デバイス２に配布し、上述の実施例１、２のような方法により各通信デバイス２の認証鍵Ｋ（ｉ）を設定することで、通信デバイス２の増減が発生しても通信デバイス２毎の認証鍵Ｋ（ｉ）の設定が簡便にできることになる。
【０１０８】
また、各通信デバイス２は、ネットワーク１上で通信した順番を記録する通信順リストを記憶部２１のＥＥＰＲＯＭ２１ａにに保持することで、ビットバーＢＢの各ブロックＫｂは、その先頭ブロックから、記録した通信順リストに認識された通信デバイスの順番に対応して割り当てることで、順番が明確に分かることになり、後でノードに問題が分かった場合これを使わないようにする。
（実施形態２）
上述の実施形態１ではビットバーＢＢから認証鍵生成を行う場合、通信デバイス数でビットバーＢＢを分割し、その分割したブロックの値で認証鍵としていたが、本実施形態では、直ちに認証鍵として使わず、ポインタとして通知する方法を採用した点に特徴がある。
【０１０９】
つまり、通信デバイス２は、ＣＰＵ２０に備えたポインタ処理部３８によって、ブロックのN番目を利用すると宣言し、それをポインタとして全通信デバイス２に送信する。ポインタを受信した電子デバイス２のＣＰＵ２０の認証鍵設定部３３では、ビットバーＢＢにおいて、ポインタの先頭又は末尾から所定の鍵長分までを認証鍵として割り当てる。また受信しなければポインタ値＝０とする。ポインタは割り当てた先まで進め、他の通信デバイス２に送信する。ポインタ送信及び受信では通信デバイス２間の認証を前提に送受信しても良い。
【０１１０】
また、乱数を送信し、受信側は乱数を通信デバイス数で割ることでその値をポインタとすることもできる。
【０１１１】
本実施形態のように認証鍵を順番に利用するのではなく、任意又はランダムに扱えるため、通信を解析する第三者によるビットバーＢＢの推測がより困難となる。
【０１１２】
尚その他の構成、認証方法、更新方法は実施形態１と同じであるので、図示、説明は省略する。
【図面の簡単な説明】
【０１１３】
【図１】（ａ）は実施形態１の通信デバイスの構成図、（ｂ）はビットバー生成のための通信デバイスのＣＰＵの機能ブロック図、（ｃ）は通信デバイスのＣＰＵの機能ブロック図である。
【図２】（ａ）は実施形態１のシステム構成図、（ｂ）はビットバーの説明図である。
【図３】実施形態１のビットバーと認証鍵の生成に対応する実施例１の説明図である。
【図４】実施形態１のビットバーと認証鍵の生成に対応する実施例２の説明図である。
【図５】（ａ）、（ｂ）は実施形態１における認証方法説明用のシステム図である。
【図６】実施形態１のビットバー更新の一例のシーケンス図である。
【図７】実施形態１のビットバー更新の別の例のシーケンス図である。
【図８】（ａ）、（ｂ）は従来例のシステム構成図である。
【符号の説明】
【０１１４】
２ 通信デバイス
２０ ＣＰＵ
２１ 記憶部
２２ 通信部
２３ バス
３０ 乱数発生部
３１ 設定部
３２ ビットバー記憶処理部
３３ 認証鍵設定部
３４ 認証鍵記憶処理部
３５ 通信認証部
３６ ハッシュ処理部
３７ ビットバー更新部
３８ ポインタ処理部
【技術分野】
【０００１】
本発明は、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムに関するものである。
【背景技術】
【０００２】
従来、図８（ａ）に示すようにネットワーク１に接続された照明器具、空調機器、パーソナルコンピュータ、デジタルＴＶ等通信機能を備えた通信デバイス２…相互で通信を行う際に、通信デバイス２が相手側通信デバイス２を認証する場合、第３者の認証用サーバ３を用いて認証鍵の発行と認証を行うようなっていた。
【０００３】
また一方図８（ｂ）に示すようにネットワークに接続されている通信デバイス１同士が直接通信を行うＰ２Ｐの場合には事前共有鍵（プリシェアード鍵）を入力していた。
【０００４】
二つの通信デバイス間で共通暗号化手順を実施するために共通鍵を発生させる装置としては例えば特許文献１に開示されている装置がある。
【特許文献１】特表平９−５０１５５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上述の図８（ａ）に示すネットワークシステムでは、通信デバイス数が増加すると、認証用サーバ３が持つ鍵を配布或いは交換するためのキーデータベースＫＤＢの存在の効果が現れてくる。一方図８（ｂ）のネットワークシステムの場合には通信デバイス数が少ない場合にはキーデバイスベースＫＤＢのコストが不要であるため都合が良いという利点がある。
【０００６】
しかしながら、何れのシステムの場合も、通信デバイス２の増減が発生すると通信デバイス２及びキーデータベースＫＤＢにおいて鍵管理の設定の手間がかかっていた。
【０００７】
本発明は、上述の点に鑑みて為されたもので、その目的とするところは通信デバイス毎の認証鍵の設定が簡便に行えるネットワークシステムを提供することにある。
【課題を解決するための手段】
【０００８】
上述の目的を達成するために、請求項１の発明では、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とする。
【０００９】
請求項１の発明によれば、通信デバイスで共用する認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
【００１０】
請求項２の発明では、請求項１の発明において、前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする。
【００１１】
請求項２の発明によれば、設定した認証鍵基礎数の乱雑度を最大限に活用でき、認証鍵の強度を高く保てることができる。
【００１２】
請求項３の発明では、請求項２の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
【００１３】
請求項３の発明によれば、長さが固定である認証鍵の生成において、均等分割によって乱雑度を最大限に高めたブロックを基にするので、認証鍵の強度を高く保てる。
【００１４】
請求項４の発明では、請求項２の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
【００１５】
請求項４の発明によれば、通信デバイスがアドホック的に存在する場合で、通信デバイス数が設定した認証鍵基礎数の期待数よりも多く通信デバイスが存在しても、乱数の乱雑度を保ったまま固定長の認証鍵を生成することができる。
【００１６】
請求項５の発明では、請求項１の発明において、前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする。
【００１７】
請求項５の発明において、ポインタ手段が指し示す最後のビット位置によって認証鍵の割当てができるので、通信デバイスでの認証鍵の割当て処理が簡便になる。
【００１８】
請求項６の発明では、請求項１乃至５の何れかの発明において、前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする。
【００１９】
請求項６の発明によれば、認証鍵基礎数による認証鍵群の更新を、割当て移行認証手順を経て各通信デバイス間で自立的且つ安全に行え、そのため認証鍵基礎数の再設定が簡便に行える。
【００２０】
請求項７の発明では、請求項６の発明において、前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする。
【００２１】
請求項７の発明によれば、認証鍵の更新時に参加していなかった通信デバイスも、それ以降において認証鍵を更新することができる。
【００２２】
請求項８の発明では、請求項２乃至４、６、７の何れかの発明において、各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする。
【００２３】
請求項８の発明によれば、通信デバイスの順番が決められることで、認証鍵が第３者に漏れても、通信デバイスの順番を監視することで介入を防ぐことができる。
【発明の効果】
【００２４】
本発明は、共用認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、各通信デバイスは認証鍵を持つことができるもので、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
【発明を実施するための最良の形態】
【００２５】
以下本発明を実施形態により説明する。
（実施形態１）
本実施形態は、例えば図２（ａ）に示すようにネットワーク１上に照明器具、空調機器、パーソナルコンピュータ、デジタルＴＶ等通信機能を備えた通信デバイス２（２１〜２ｎ）を複数接続し、通信デバイス２の相互間で通信を行うネットワークシステムであるが、例えば図２（ｂ）に示すように認証鍵Ｋ（１）…を順列に集合させた決まった長さの乱数からなる認証鍵基礎数（以下ビットバーと称する）ＢＢを、相互に通信する通信デバイス２に生成設定する点に特徴がある。
【００２６】
ビットバーＢＢは、通信デバイス２群に対して、共通に保持する事前鍵であって、その配布は工場出荷時に通信デバイス２の記憶部に書き込む、或いはネットワークで配布する、更にはＩＣカードやＵＳＢメモリ等外部メモリデバイスに保持し、各通信デバイス２のメモリスロットに挿入することで保持させる等種々の方法で行う。
【００２７】
そして全通信デバイス２（２１〜２ｎ）で同じ値のビットバーＢＢを保持して後述する認証鍵生成方法により認証鍵を各通信デバイス２（２１〜２ｎ）で設定することになる。
【００２８】
ビットバーＢＢ自体の生成は、ビットバーＢＢを生成する専用装置を用い、この装置で生成したビットバーＢＢを上述の外部メモリデバイスに記憶させる方法や工場出荷時に通信デバイス２の記憶部に書き込むか、ネットワーク１を通じて通信により配布する。またネットワーク１上にビットバーＢＢの生成・配布のみを専ら行う通信デバイス２を設けても良く、更には通信デバイス２の一つに生成機能を持たせ、ネットワーク１を通じて配布するようにしても良い。
【００２９】
さて本実施形態に用いる通信デバイス２は、図１（ａ）に示すようにＣＰＵ２０と、記憶部２１と、通信部２２とをバス２３により接続した構成を基本的なハードウェア構成として備えている。
【００３０】
ＣＰＵ２０は、通信デバイス２固有の機能部（図示せず）の制御、通信部２２による通信制御、更に記憶部２１の書き込みや読み出しの制御、更に認証、乱数などの処理を行う。
【００３１】
記憶部２１は、プログラムを格納しているＥＥＰＲＯＭ２１ａと、実行中のプログラムの保持、更に諸データの保持を担うＲＡＭ２１ｂとから構成される。
【００３２】
通信部２２はネットワーク１に接続するためのイーサネット（登録商標）に対応したＬＡＮ用通信部２２ａや、ＲＳ２３２Ｃ対応の汎用通信部２２ｂとを備えている。
【００３３】
ここで、本実施形態に用いる通信デバイス２のＣＰＵ２０には、図１（ｂ）に示すように配布されたビットバーＢＢを記憶部２１のＥＥＰＲＯＭ２１ａ或いはＲＡＭ２１ｂに記憶させるビットバー記憶処理部３２、記憶されたビットバーＢＢを基に、後述する認証鍵Ｋ（ｉ）を生成して設定する認証鍵設定部３３、設定された認証鍵ＫをＲＡＭ２１ｂに記憶させる認証鍵記憶処理部３４、更に記憶した認証鍵Ｋを用いて通信を認証する通信認証部３５を基本的に備え、また後述するように認証鍵Ｋ（ｉ）を生成時においてハッシュ処理する場合にはハッシュ処理部３６を、またビットバー更新を行う場合にはビットバー更新部３７を、ポインタ処理を行う場合にはポインタ処理部３８を機能して備える。
【００３４】
また通信デバイス２に、ビットバーＢＢを生成する機能を持たせる場合には、乱数生成部３０を図１（ｃ）に示すように持たせ、その乱数生成部３０を働かせるか働かせないかで、ビットバーＢＢの配布兼用の通信デバイスとして用いることができるようなっており、その乱数生成部３０を働かせるか否かは、設定部３１で設定する。
【００３５】
次に本発明におけるビットバーＢＢを用いた認証鍵Ｋの生成方法を実施例により説明する。
（実施例１）
本実施例では、各通信デバイス２（２１〜２ｎ）が稼動すると、工場出荷時、記憶媒体による配布、ネットワーク１を通じた配布等によって、例えばＥＥＰＲＯＭ２１ａに既に記憶してあるビットバーＢＢから認証鍵設定部３３により所定のビット長さの認証鍵Ｋを生成する。
【００３６】
この場合、予め工場出荷時に設定されている通信デバイス２の接続最大数等の所定数ｎで均等分割し、均等分割したブロックＫｂ１〜Ｋｂｎにインデックスを付して夫々で認証鍵Ｋ（１）〜Ｋ（ｎ）を生成する。
【００３７】
図３（ａ）はビット長さＬのビットバーＢＢをｎ等分して状態を示す。ここで、認証鍵Ｋ（１）〜Ｋ（ｎ）のビット長さＬｅは所定数ｎでビットバーＢＢを均等分割して得られるブロックＫｂ（Ｋｂ１〜Ｋｂｎ）のビット長に固定したものとする。
【００３８】
そして通信デバイス２（２１〜２ｎ）のＣＰＵ２０の認証鍵設定部３３は、工場出荷時に付されたシリアル番号、通信アドレス、ＭＡＣアドレス、オブジェクトＩＤなどの番号順、或いはランダム、予め指定された設定順、種別等に基づいて自己の認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当て、生成設定した認証鍵Ｋ（１）〜Ｋ（ｎ）を例えばＥＥＰＲＯＭ２１ａに記憶保持する。
【００３９】
ここで、シリアル番号、通信アドレス、ＭＡＣアドレス、オブジェクトＩＤなどの番号順を用いる場合には、通信デバイス２（２１〜２ｎ）群は、事前に各通信デバイス２が自己の番号を送信して互いのシリアル番号を取得し合い、そのリストを作成するとともに、シリアル番号のソート処理を行い、シリアル番号の若い順にビットバーＢＢの上位或いは下位から認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当てる。ＭＡＣアドレスを用いる場合にはＡＲＰテーブルを参照することで実現することもできる。
【００４０】
また、各通信デバイス２（２１〜２ｎ）が通信を行った順番を監視し、どの通信デバイス２（２１〜２ｎ）が通信を開始したかという順番のリストを保持し、その順番で認証鍵Ｋ（ｉ）のブロックＫｂｉを割り当てるようにしても良い。
【００４１】
ところで、上述の場合ｎ個の通信デバイス数によって均等分割したブロックにより認証鍵Ｋ（ｉ）を設定しているが、実際にネットワーク１に接続される通信デバイス数がｎ個より少ない場合には、例えば上位から順次割り当てた場合、余剰のブロックは捨てるものとする。
【００４２】
尚通信デバイス数を動的に検出する方法としては、例えばブロードキャストピングを用いる方法を用いて行う。ここで全ての通信デバイス２（２１〜２ｎ）がＴＣＰ／ＩＰの実装を持ち、ブロードキャストピングに応答するものとする。そしてブロードキャストピングのエコーリクエストを送信した通信デバイス２において、タイムアウト期間を設け、その期間内のエコーリプライの応答数をカウントする。これにより動的に現在稼動中の通信デバイス数を検出することができるのである。ブロードキャストは、通信デバイス２が同一セグメント内に存在することが条件となるが、例えばマルチキャストを持ち入ればセグメントを跨るネットワークにも対応することができる。
【００４３】
また認証鍵Ｋ（ｉ）のビット長さが固定長Ｌｅでない暗号通信、例えばワンタイムパッド（ＯＴＰ）の暗号方式などでは、メッセージ長分の認証鍵Ｋ（ｉ）のビット長さ必要であるが、本実施例の場合のように均等分割したブロックＫｂｉのビット長さＬｅが、メッセージ長より長いければ不要部分は切り捨てする。
【００４４】
上述の場合、ビットバーＢＢを所定の通信デバイス数ｎで均等分割したブロックＫｂｉで認証鍵Ｋ（ｉ）を設定しているが、実際の稼動中の通信デバイス数でビットバーＢＢを均等分割してブロックを設定する場合、通信デバイス数が上述のｎより少ない（ｎ−α）と一つのブロックＫｂｉのビット長さＬｂは認証鍵Ｋ（ｉ）のビット長さＬｅよりも長くなる。この場合は、一つのブロックＫｂｉから認証鍵Ｋ（ｉ）のビット長Ｌｅを切り取り余った分を捨てる。
【００４５】
図３（ｂ）はこの場合のビットバーＢＢにおけるブロックＫｂｉのビット長と認証鍵Ｋ（ｉ）のビット長さＬｅの関係を示す。
【００４６】
ところで、稼動中の通信デバイス数でビットバーＢＢを均等分割する場合、通信デバイス数が上述のｎよりも大きい（ｎ＋α）の場合には、一つのブロックＫｂｉのビット長さＬｂは認証鍵Ｋ（ｉ）のビット長さＬｅよりも短くなる、
この場合は、ブロックＫｂｉの先頭からＬｅのビット長さだけ切り取り、この切り取った部分で認証鍵Ｋ（ｉ）を設定する。
【００４７】
図３（ｃ）はこの場合のビットバーＢＢにおけるブロックＫｂｉのビット長と認証鍵Ｋ（ｉ）のビット長さＬｅの関係を示す。
【００４８】
また認証鍵Ｋ（ｉ）に対応するブロックＫｂ（ｉ）がビットバーＢＢの最後尾のブロックで、ビット長さＬｅの範囲がビットバーＢＢの範囲を超えるときには、図３（ｄ）に示すように越える部分Ｌｔを先頭のブロックＬ１から補う。
（実施例２）
本実施例も、実施例１と同様に認証鍵Ｋ（ｉ）が固定のビット長さＬｅで、ビットバーＢＢの長さがＬｒとした場合において、稼動中の通信デバイス数が所定数ｎよりも小さい（ｎ−α）場合、つまりＬｅ≦Ｌｅ／（ｎ−α）である場合は、通信デバイス２のＣＰＵ２０のハッシュ処理部３６の処理によって図４（ａ）に示すようにブロックＫｂｉをハッシュし、認証鍵設定部３３はこのハッシュした値により認証鍵Ｋ（ｉ）を設定する。
【００４９】
また、通信デバイス数が所定数ｎが大きい（ｎ＋α）場合、つまりＬｅr／（ｎ＋α））である場合は、図４（ｂ）に示すように認証鍵（Ｋｉ）はブロックＫｂｉの先頭のビットからＬｅの長さまでのブロックのハッシュをハッシュ処理部３６の処理で行い、認証設定部３３はこのハッシュした値により認証鍵Ｋ（ｉ）を設定する。
【００５０】
また、ブロックＫｂｉがビットバーＢＢの最後尾であり、且つＬｅの長さの範囲がビットバーＢＢの範囲を越えるときは実施例１の図３（ｄ）の場合と同様に、越えた部分Ｌｔを先頭のブロックＫｂ１から補うこととする。
【００５１】
上述の場合は、Ｌｅの長さがハッシュの長さと同じであるが、Ｌｅの長さがハッシュの長さより長い場合、図４（ｃ）のようにハッシュの長さを組み合わせ、Ｌｅの長さと一致させる補正としてｑとすると、複数ｍのブロックをハッシュした長さ（Ｈａｓｈ ｓｉｚｅ）の和からｑをはぎ取るようにする。つまり認証鍵Ｋ（ｉ）は、Ｌｅ＝（Hash size)×ｍ−ｑによって設定される。
【００５２】
以上のように何れかの実施例によって事前鍵であるビットバーＢＢから各通信デバイス２（２１〜２ｎ））は夫々において認証鍵Ｋ（ｉ）を生成設定する。
【００５３】
尚、通信デバイス２がネットワーク１上から取り外されたり、稼動を停止する場合は、通信デバイス数が経るため、当該通信デバイス２ｉが認証鍵Ｋ（ｉ）に用いていたブロックＫｂｉを空きブロックする。逆に新たに通信デバイス２ｉがネットワーク１に接続されて稼動している場合、空きブロックがあれば当該ブロックを認証鍵設定のブロックとしてあてがい、もしなければ全体の認証鍵生成を実施例１或いは実施例２により構成し直す。
【００５４】
次に上述のように生成された認証鍵Ｋ（ｉ）を用いた認証方法を例により説明する。
【００５５】
（例１）
本例は図５（ａ）に示すように例えば、２つの通信デバイス２ａと２ｂとの間で暗号技術を用いてチェレンジレスポンス認証方法である。尚通信デバイス２ａの認証鍵をＫ（ａ），通信デバイス２ｂの認証鍵をＫ（ｂ）とする。
【００５６】
まず通信デバイス２ａ，２ｂの間で一方を認証する場合には、１）、２）の方法がある。
【００５７】
１）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きにより通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ａ宛に送る。
【００５８】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）で暗号を復号化し、自己が送信したナンス値Ｎａの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。
【００５９】
２）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）で復号化してナンス値Ｎａを通信デバイス２ａに送る。
【００６０】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。
【００６１】
通信デバイス２ｂと通信デバイス２ａとの間で相互認証を行う場合、３）、４）の方法がある
３）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｎａ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを復号化し、この復号によって得たナンス値Ｎａと、ナンス値Ｎｂを共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎｂ｝Ｋ（ａ）（ｂ）、Ｎａを通信デバイス２ａに送る。
【００６２】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られれば、通信相手が通信デバイス２ｂであると認証し、更に共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを復号化し通信デバイス２ｂ宛にＮｂを送る。
【００６３】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ａであると認証する。
【００６４】
４）通信デバイス２ａのＣＰＵ２０の通信認証部３５の働きによりナンス値Ｎａを通信デバイス２ｂ宛にナンス値Ｎａを送る。これに対して通信デバイス２ｂのＣＰＵ２０の通信認証部３５は記憶している通信デバイス２ａ，２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを暗号化し、この暗号化した値と所定のナンス値Ｎｂ、｛Ｎａ｝Ｋ（ａ）（ｂ）、Ｎｂを通信デバイス２ａに送る。
【００６５】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は自己が送信したナンス値Ｎａの応答が得られれば、通信相手が通信デバイス２ｂであると認証し、更に共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを復号化し通信デバイス２ｂ宛にＮｂを送る。
【００６６】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａを復号化し、自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ｂであると認証する。そして共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを暗号化し、｛Ｎｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。
【００６７】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを複合化し、自己が送信したナンス値Ｎｂの応答が得られたことで、通信相手が通信デバイス２ａであると認証する。
【００６８】
（例２）
本例は、ＩＳＯ／ＩＥＣの９７８−２標準として２者間の通信の認証する方法であって、片方向認証としてはタイムスタンプを用いて方法と、ナンス値を用いた方法とがある。
【００６９】
１）タイムスタンプを用いた片方向認証方式では、図５（ａ）において、一方の通信デバイス２ａが他方の通信デバイス２ｂにタイムスタンプＴａと、メッセージＢとを共通認証鍵Ｋ（ａ）（ｂ）で暗号化して｛Ｔａ，Ｂ｝Ｋ（ａ）（ｂ）を送る。これを受け取った通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ａ）（ｂ）で復号化し、送られてきたメッセージＢが自己宛のメッセージであれば、相手を識別して認証するのである。
【００７０】
２）ナンス値を用いて相互認証を行う場合、まず一方の通信デバイス２ｂのＣＰＵ２０の通信認証部３５はナンス値Nｂを他方の通信デバイス２ａ宛に送る。通信デバイス２ａのＣＰＵ２０の通信認証部３５は受け取ったナンス値Nｂと、自己のナンス値Ｎａと、通信デバイス２ｂへのメッセージを識別するための値Ｂとを、共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎａ，Ｎｂ、Ｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ｂ宛に送る。
【００７１】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ａ）（ｂ）で復号化し、自己のナンス値Ｎｂと復号化したナンス値Ｎａとを共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、｛Ｎａ，Ｎｂ｝Ｋ（ａ）（ｂ）を通信デバイス２ａ宛に送る。
【００７２】
このようにして通信デバイス２ａ、２ｂは自己のナンス値Ｎａ，Ｎｂが送り消されることで、相互を認証するのである。
【００７３】
（例３）
本例はNeedham-Schroederのような第三者認証に対応するものである。
【００７４】
まず本例では、通信デバイス２ａと２ｂの間で直接認証を行わず、信頼できる第三者の通信デバイス（ここでは２Ｐとする）
まず、通信デバイス２ａのＣＰＵ２０の通信認証部３５は、通信デバイス２Ｐに対して、送信したい通信相手の識別のために通信デバイス２ａ，２ｂの値Ａ、Ｂ及びナンス値Ｎａを送信する。
【００７５】
通信デバイス２ＰＣＰＵ２０の通信認証部３５は、通信デバイス２ａと通信デバイス２Ｐの間の共通認証鍵Ｋ（ａ）（ｐ）でナンス値Ｎａと、値Ｂ，Ａと、通信デバイス２ａ、２ｂ間の共通認証鍵Ｋ（ａ）（ｂ）、及び２ｂのみが復号できるように共通認証鍵Ｋ（ａ）（ｂ）と、値Ａとを通信デバイス２ｂ、２Ｐの間の共通認証鍵Ｋ（ｂ）（ｐ）で暗号化し、更に共通認証鍵Ｋ（ａ）（ｐ）で暗号化し、｛Ｎａ，Ｂ，Ｋ（ａ）（ｂ），｛Ｋ（ａ）（ｂ）、Ａ｝Ｋ（ｂ）（ｐ）｝Ｋ（ａ）（ｐ）として通信デバイス２ａに送る。
【００７６】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ｂ）（ｐ）で復号し、｛Ｋ（ａ）（ｂ）、Ａ｝Ｋ（ｂ）（ｐ）を通信デバイス２ｂ宛に送る。
【００７７】
通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、共通認証鍵Ｋ（ｂ）（ｐ）でそのメッセージを復号し、Ｋ（ａ）（ｂ）を得る。そして得られた共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎｂを暗号化し、通信デバイス２ａ宛に送る。
【００７８】
通信デバイス２ａのＣＰＵ２０の通信認証部３５は、そのメッセージを共通認証鍵Ｋ（ａ）（ｂ）で復号し、受け取った証しとして通信デバイス２ｂにナンス値Ｎｂから１引いた値を共通認証鍵Ｋ（ａ）（ｂ）で暗号化し、通信デバイス２ｂに送る。通信デバイス２ａのＣＰＵ２０の通信認証部３５は、そのメッセージを共通認証鍵Ｋ（ａ）（ｂ）で復号し、ナンス値Ｎｂから１引かれていることで、認証されたことを確認する。
【００７９】
（例４）
本例は、ＩＳＯ／ｌＥＣの９７９８−３標準として公開鍵暗号を用いた認証方式に対応する。
【００８０】
１）タイムスタンプを用いた片方向認証方式の場合、通信デバイス２ａから通信デバイス２ｂにＣＡ（ＰＫａ），Ｔａ，Ｂ，ＳｌＧＮ（Ｔａ，Ｂ）ＰＫａ−１を送る。
【００８１】
この場合、認証としてタイムスタンプを用いるためナンス値は必要としない。またＣＡ（ＰＫａ）は通信デバイス２ａの公開鍵Ｐｋａの証明書に含まれる例を示す。Ｔａはタイムスタンプを示す。更にＢは通信デバイス２ｂへのメッセージであるという識別の値を示し、ＳＩＧＮ（Ｔａ，Ｂ）ＰＫａ−１は通信デバイス２ａの公開鍵に対する秘密鍵ＰＫａ−１でデジタル署名を行っていることを示す。
【００８２】
２）ナンス値を用いた相互認証方式の場合には、通信デバイス２ｂから通信デバイス２ａにナンス値Ｎｂをまず送る。通信デバイス２ａからは通信デバイス２ａの公開鍵ＰＫａを含む証明書ＣＡ（ＰＫａ），通信デバイス２ａのナンス値Ｎａ，通信デバイス２ｂへのメッセージの識別の値Ｂ，Ｎａ，Ｎｂ，Ｂを秘密鍵ＰＫａ−１でデジタル署名して、
ＣＡ（ＰＫａ），Ｎａ，Ｂ，ＳＩＧＮ（Ｎａ，Ｎｂ，Ｂ）ＰＫａ−１を通信デバイス２ｂに送る。
【００８３】
通信デバイス２ｂは、通信デバイス２ａに、通信デバイス２ｂの公開鍵ＰＫｂを含む証明書ＣＡ（ＰＫｂ）、通信デバイス２ａへのメッセージの識別の値ａ，ナンス値Ｎｂ，Ｎａを秘密鍵ＰＫｂ−１でデジタル署名して、ＣＡ（ＰＫｂ），Ａ，ＳＩＧＮ（Ｎｂ，Ｎａ，Ａ）ＰＫｂ−１を通信デバイス２ａに送る。尚（）内は共通認証鍵Ｋ（ａ）（ｂ）で暗号化されていることを示す。
【００８４】
（例５）
本例は、暗号よりも処理が高速なハッシュ系の技術でKryptoKnightのＭＡＣを用いた２者間の認証プロトコルを用いるものである。
【００８５】
まず、通信デバイス２ａから通信デバイス２ｂに非暗号のナンス値Ｎａを送る。そして通信デバイス２ｂのＣＰＵ２０の通信認証部３５は、非暗号のナンス値Ｎｂと共通認証鍵Ｋ（ａ）（ｂ）でナンス値Ｎａ，Ｎｂと通信デバイス２ｂからのメッセージを識別する値ＢをＭＡＣ処理し、Ｎｂ，ＭＡＣ（Ｎａ，Ｎｂ，Ｂ）Ｋ（ｂ）（ａ）として通信デバイス２ａに送る。
【００８６】
通信デバイス２ａは同様にナンス値Ｎａ、ＮｂをＭＡＣ処理し、通信デバイス２ｂにＭＡＣ（Ｎａ，Ｎｂ）Ｋ（ａ）（ｂ）として送る。
【００８７】
このようにＩＳＯ／ＩＥＣの標準の例では、タイムスタンプ方式を除けば、ナンス値を用いた認証方式は多岐に渡る。
【００８８】
以上の認証方法の例は二つの通信デバイス２ａ，２ｂ間の片方若しくは双方向の認証方法であったが、通信デバイス２ａ…間でグループを形成する場合の認証方法を例６，例７により説明する。
【００８９】
（例６）
本例は、多数決の方法をとったグループ認証方法である。
【００９０】
例えば図５（ｂ）に示すように複数の通信デバイス２ａ，２ｂ，２ｃ、２ｄが、或る認証子（ＩＤ）又はポリシーを持ち、通信デバイス間で連係動作するためのグループを形成したいとする。例えば図１（ａ）に示すシステムで通信デバイス２ａのＣＰＵ２０の通信認証部３５が、自己のは認証鍵Ｋ（ａ）を用いて暗号化して認証子（ＩＤ）或いはポリシーをブロードキャストで送信したする。ここで認証鍵Ｋ（ａ）は既に認証されているので、受信側の通信デバイス２ｂ〜２ｄは送信元が通信デバイス２aであることがわかる。
【００９１】
次に認証子（ＩＤ）又はポリシーの条件によって、通信デバイス２ａ以外の通信デバイス２ｂ〜２ｄの内、或る通信デバイス２ｊはＡＣＫ（許可）を返し、或る通信デバイス２mはＮＡＫ（不許可）を返すとする。ここで通信デバイス２aのＣＰＵ２０の通信認証部３５は、各通信デバイス２ｂ〜２ｎからの応答のＡＣＫ，ＮＡＫを受信してそれぞれの応答数をカウントする。ここで、閾値ＢＬを事前に設定しておき、閾値ＢＬをＡＣＫの総数が超えれば通信デバイス２ａ〜２ｄのグループ内で通信デバイス２aは認証されたこととなる。
【００９２】
ここで、閾値ＢＬは、通信デバイス２の全数（n数）を上述のように動的に検出し、閾値ＢＬの値を調停する。又は工場出荷時に設定するなどしても良い。
【００９３】
このようにして、グループ内での通信デバイス２の認証が可能となる。ここで、認証子（ＩＤ）の代わりにポリシー等アクセス権に関わる情報をやり取りしても良い。
【００９４】
そして予め定めている下限値ＬＭを、参加通信デバイス数が下回る場合にはグループ内の認証が成立しないものする。
【００９５】
（例７）
本例は、ビットバーＢＢによって既に配布されている認証鍵によって、ブロードキャスト、マルチキャスト、ユニキャスト等の方法で配布する個別鍵からグループの認証方法である。
【００９６】
つまり、個別鍵生成を利用してストックされた鍵を各通信デバイス２が蓄積し、ストックＳＫａ…を生成し、このストックＳＫａ…の生成後、ストックＫａ…を結合しグループ鎚を生成する。
【００９７】
この場合、単純にストックした値をビットバーＢＢの通信デバイス２の順番でグループ化とするか、ＧＫ（ａ）（ｂ）（ｃ）＝ＨＡＳＨ（ＳＫａ｜ＳＫｂ｜ＳＫｃ｜…）とハッシュを計算する。ここで通信デバイス２ｄが例６のグループ認証の結果ＮＡＫで不許可であったとしても、通信デバイス２ｄを含めて、グループ鍵を生成しても良く、また、その逆で、ＮＡＫで不許可であった通信デバイス２ｄを含めず、グループ鍵を生成しても良い。これはシステムのポリシーに依存する。
【００９８】
ところで、ビットバーＢＢは、工場出荷時などで秘密裏に各通信デバイス２に共有されることを前提とするため、一旦その値が悪意の第三者に漏れると、安全上の脅威となってしまう。
【００９９】
そこで、本実施形態では、第三者に漏れても通信デバイス２群の通信を終始監視し、ｓの間に介入していなければ、安全に更新する方法を採用している。
【０１００】
まず、ビットバーＢＢを図１（ａ）のシステムにおいて、更新したい通信デバイス２１〜２ｎまでの全てが稼動している場合、古い認証鍵で各通信デバイス２１〜２ｎが新しいビットバーＢＢのブロックＫｂを渡し合い、各通信デバイス２１〜２ｎの順番に或るブロックと置き換える。つまり、通信デバイス２Ｋは当該通信デバイス２Ｋに割り当てられたビットバーＢＢのブロックＫｂｋの認証鍵Ｋ（Ｋ）に対応して、ＣＰＵ２０のビットバー更新部３７によってブロックＫｂｋのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（Ｋ）’とする。この部分鍵Ｋ（Ｋ）’を現在の認証鍵Ｋ（Ｋ）で暗号化し、自己を除いた全通信デバイス２１〜２ｎに更新メッセージとして送信する。全通信デバイス２１〜２ｎは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２Ｋから送信された更新メッセージの認証鍵Ｋ（Ｋ）でメッセージを復号し部分鍵Ｋ（Ｋ）’を得る。同様にして、全ての通信デバイス２１〜２ｎが更新メッセージを送信し、全通信デバイス２１〜２ｎが全ての部分鍵Ｋ（１）’〜Ｋ（ｎ）’を得たならば、これを結合し新たなビットバーＢＢとする。
【０１０１】
図６は通信デバイス２ａで当該通信デバイス２ａに割り当てられたビットバーＢＢ０のブロックＫｂａの認証鍵Ｋ（ａ）に対応して、ブロックＫｂaのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（ａ）’とし、これを結合し新たなビットバーＢＢ１とする。またこの部分鍵Ｋ（ａ）’を現在の認証鍵Ｋ（ａ）で暗号化（図では＋を入れた○印で示す）し、例えば通信デバイス２ｂに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス２ｂは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２ａから送信された更新メッセージの認証鍵Ｋ（ａ）でメッセージを復号し部分鍵Ｋ（ａ）’を得る。通信デバイス２ｂが部分鍵Ｋ（ａ）’を得たならば、これを結合し新たなビットバーＢＢ１としている。その後同様に新しい部分鍵Ｋ（ａ）”を生成し、この部分鍵Ｋ（ａ）”を用いてビットバーＢＢ１をＢＢ２に更新している。
【０１０２】
また、通信デバイス２１〜２nまでの全ての通信デバイスが起動していない場合、必ずしもビットバーＢＢを更新したい全ての通信デバイス２１〜２ｎが更新時に起動しているとは限らない。そこで、更新期限があったとすれば、更新期限内に参加していない通信デバイス２の場合はそのまま古いブロックを部分鍵とする。この場合、新しいブロックＫでの認証鍵を使ったメッセージを更新期限内に起動していなかった通信デバイスが受信した場合、メッセージを復号できない問題がある。この場合は、再更新の方法として、通信デバイス２が復号できない旨を伝え、通信デバイス２が古い認証鍵で認証されると、その通信デバイス２を除く全応答可能通信デバイス２は保持しておいた古い認証鍵で暗号化してその通信デバイス２に送るようにすることで更新する。
【０１０３】
その他の更新方法としては、ビットバーＢＢの更新方法として複数のビットバーＢＢの履歴を持ち、古いビットバーＢＢから新しいビットバーＢＢを構築する方法もある。例えば、或る期間には起動していなかった通信デバイス２があり、古い認証鍵しかなかった場合、この通信デバイス２のビットバーＢＢを更新する方法として新しいビットバーＢＢを持つ通信デバイス２と古いビットバーＢＢを持つ通信デバイス２は常に時間又は回数（カウンタ）による履歴の管理を行い、ビットバーＢＢの時間又は回数を確認し、更新した時期のビットバーＢＢで通信させ、後に上述のビットバーＢＢの更新方法で更新する方法もある。
【０１０４】
つまり、例えば、通信デバイス２Ｋにおいて、ビットバーＢＢから認証鍵Ｋ（Ｋ）を生成設定する際にＣＰＵ２０のビットバー更新部３７がビットバー履歴を作成して例えばＥＥＰＲＯＭ２１ａに保持する。そして更新に当たっては部分鍵Ｋ（Ｋ）’を乱数で生成する。この部分鍵Ｋ（Ｋ）’のサイズは認証鍵Ｋ（Ｋ）と同じブロックのビット長さとする。部分鍵Ｋ（Ｋ）’を古い認証鍵Ｋ（Ｋ）で暗号化して履歴付で自己を除く全通信デバイス２１〜２ｎに送信する。全通信デバイス２１〜２ｎは受け取ったメッセージを履歴に対応する古い認証鍵Ｋ（Ｋ）で復号し、送った相手（２Ｋ）に割り当てられたビットバーＢＢのブロックＫｂｋを部分鍵Ｋ（Ｋ）’で更新するのである。
【０１０５】
図７は通信デバイス２ａで当該通信デバイス２ａに割り当てられたビットバーＢＢ０のブロックＫｂａの認証鍵Ｋ（ａ）に対応して、ブロックＫｂaのビット長さに相当する乱数を生成し、新しい部分鍵Ｋ（ａ）’とし、この部分鍵Ｋ（ａ）’で自己の現在のビットバーＢＢ０を更新するとともに、このビットバーＢＢ０の履歴を作成し、この履歴作成後、現在の認証鍵Ｋ（ａ）で暗号化（図では＋を入れた○印で示す）し、古いビットバーＢＢ０を用いていることを示す、つまり履歴（更新時間、更新回数、識別子等）を示すメッセージＢＢ０＿ＩＤとともに、例えば通信デバイス２ｂに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス２ｂは、既に上述の認証鍵生成設定と割当てにより、通信デバイス２ａから送信された更新メッセージの認証鍵Ｋ（ａ）でメッセージを復号し部分鍵Ｋ（ａ）’を得る。通信デバイス２ｂが部分鍵Ｋ（ａ）’を得たならば、これを結合し新たなビットバーＢＢ１とし、また現在のビットバーＢＢ０の履歴を作成する。
【０１０６】
図７では、新たに通信デバイス２ｃが参加した場合を示しており、この通信デバイス２ｃは古いビットバーＢＢ０を持つものであるので、例えば通信デバイス２ａに認証を受ける場合、ナンス値を通信デバイス２ａと共通の認証鍵Ｋ（ａ）（ｃ）で暗号化し、メッセージＢＢ０＿ＩＤとともに通信デバイス２ａ宛に送る。一方通信デバイス２ａでは受け取った履歴を示すメッセージＢＢ０＿ＩＤに基づいて対応する古いビットバーＢＢ０による共通の認証鍵Ｋ（ａ）（ｃ）を選択してナンス値を復号し、通信デバイス２ｃに返えす。これにより通信デバイス２ｃは認証が成功したことを知ることになる。これにより認証鍵更新時に参加していなかった通信デバイス２ｃも認証後、更新できることになる。
【０１０７】
以上のように本実施形態では、上述したビットバーＢＢを事前鍵として各通信デバイス２に配布し、上述の実施例１、２のような方法により各通信デバイス２の認証鍵Ｋ（ｉ）を設定することで、通信デバイス２の増減が発生しても通信デバイス２毎の認証鍵Ｋ（ｉ）の設定が簡便にできることになる。
【０１０８】
また、各通信デバイス２は、ネットワーク１上で通信した順番を記録する通信順リストを記憶部２１のＥＥＰＲＯＭ２１ａにに保持することで、ビットバーＢＢの各ブロックＫｂは、その先頭ブロックから、記録した通信順リストに認識された通信デバイスの順番に対応して割り当てることで、順番が明確に分かることになり、後でノードに問題が分かった場合これを使わないようにする。
（実施形態２）
上述の実施形態１ではビットバーＢＢから認証鍵生成を行う場合、通信デバイス数でビットバーＢＢを分割し、その分割したブロックの値で認証鍵としていたが、本実施形態では、直ちに認証鍵として使わず、ポインタとして通知する方法を採用した点に特徴がある。
【０１０９】
つまり、通信デバイス２は、ＣＰＵ２０に備えたポインタ処理部３８によって、ブロックのN番目を利用すると宣言し、それをポインタとして全通信デバイス２に送信する。ポインタを受信した電子デバイス２のＣＰＵ２０の認証鍵設定部３３では、ビットバーＢＢにおいて、ポインタの先頭又は末尾から所定の鍵長分までを認証鍵として割り当てる。また受信しなければポインタ値＝０とする。ポインタは割り当てた先まで進め、他の通信デバイス２に送信する。ポインタ送信及び受信では通信デバイス２間の認証を前提に送受信しても良い。
【０１１０】
また、乱数を送信し、受信側は乱数を通信デバイス数で割ることでその値をポインタとすることもできる。
【０１１１】
本実施形態のように認証鍵を順番に利用するのではなく、任意又はランダムに扱えるため、通信を解析する第三者によるビットバーＢＢの推測がより困難となる。
【０１１２】
尚その他の構成、認証方法、更新方法は実施形態１と同じであるので、図示、説明は省略する。
【図面の簡単な説明】
【０１１３】
【図１】（ａ）は実施形態１の通信デバイスの構成図、（ｂ）はビットバー生成のための通信デバイスのＣＰＵの機能ブロック図、（ｃ）は通信デバイスのＣＰＵの機能ブロック図である。
【図２】（ａ）は実施形態１のシステム構成図、（ｂ）はビットバーの説明図である。
【図３】実施形態１のビットバーと認証鍵の生成に対応する実施例１の説明図である。
【図４】実施形態１のビットバーと認証鍵の生成に対応する実施例２の説明図である。
【図５】（ａ）、（ｂ）は実施形態１における認証方法説明用のシステム図である。
【図６】実施形態１のビットバー更新の一例のシーケンス図である。
【図７】実施形態１のビットバー更新の別の例のシーケンス図である。
【図８】（ａ）、（ｂ）は従来例のシステム構成図である。
【符号の説明】
【０１１４】
２ 通信デバイス
２０ ＣＰＵ
２１ 記憶部
２２ 通信部
２３ バス
３０ 乱数発生部
３１ 設定部
３２ ビットバー記憶処理部
３３ 認証鍵設定部
３４ 認証鍵記憶処理部
３５ 通信認証部
３６ ハッシュ処理部
３７ ビットバー更新部
３８ ポインタ処理部
【特許請求の範囲】
【請求項１】
ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とするネットワークシステム。
【請求項２】
前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする請求項１記載のネットワークシステム。
【請求項３】
前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項２記載のネットワークシステム。
【請求項４】
前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項２記載のネットワークシステム。
【請求項５】
前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする請求項１記載のネットワークシステム。
【請求項６】
前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする請求項１乃至５の何れかの１項に記載のネットワークシステム。
【請求項７】
前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする請求項６項に記載のネットワークシステム。
【請求項８】
各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする請求項２乃至４、６、７の何れかの１項に記載のネットワークシステム。
【請求項１】
ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とするネットワークシステム。
【請求項２】
前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする請求項１記載のネットワークシステム。
【請求項３】
前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項２記載のネットワークシステム。
【請求項４】
前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項２記載のネットワークシステム。
【請求項５】
前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする請求項１記載のネットワークシステム。
【請求項６】
前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする請求項１乃至５の何れかの１項に記載のネットワークシステム。
【請求項７】
前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする請求項６項に記載のネットワークシステム。
【請求項８】
各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする請求項２乃至４、６、７の何れかの１項に記載のネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００８−２４４８８５（Ｐ２００８−２４４８８５Ａ）
【公開日】平成２０年１０月９日（２００８．１０．９）
【国際特許分類】
【出願番号】特願２００７−８３００７（Ｐ２００７−８３００７）
【出願日】平成１９年３月２７日（２００７．３．２７）
【出願人】（０００００５８３２）松下電工株式会社 (17,916)
【Ｆターム（参考）】
【公開日】平成２０年１０月９日（２００８．１０．９）
【国際特許分類】
【出願日】平成１９年３月２７日（２００７．３．２７）
【出願人】（０００００５８３２）松下電工株式会社 (17,916)
【Ｆターム（参考）】
[ Back to top ]