JP2008244885A - ネットワークシステム - Google Patents

ネットワークシステム Download PDF

Info

Publication number
JP2008244885A
JP2008244885A JP2007083007A JP2007083007A JP2008244885A JP 2008244885 A JP2008244885 A JP 2008244885A JP 2007083007 A JP2007083007 A JP 2007083007A JP 2007083007 A JP2007083007 A JP 2007083007A JP 2008244885 A JP2008244885 A JP 2008244885A
Authority
JP
Japan
Prior art keywords
authentication key
authentication
communication device
communication
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007083007A
Other languages
English (en)
Other versions
JP5080837B2 (ja
Inventor
Hisahiro Fukuda
尚弘 福田
Chikao Matsuo
至生 松尾
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Electric Works Co Ltd
Original Assignee
Matsushita Electric Works Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Works Ltd filed Critical Matsushita Electric Works Ltd
Priority to JP2007083007A priority Critical patent/JP5080837B2/ja
Publication of JP2008244885A publication Critical patent/JP2008244885A/ja
Application granted granted Critical
Publication of JP5080837B2 publication Critical patent/JP5080837B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】通信デバイス毎の認証鍵の設定が簡便に行えるネットワークシステムを提供することにある。
【解決手段】通信デバイス2は、認証鍵を順列に集合させた決まった長さの乱数からなるビットバーBBを記憶する記憶部21と、ビットバーBBに基づいて自己の認証鍵を設定する認証鍵設定部33と、設定された認証鍵を用いた他の通信デバイス2に対して通信認証を行う通信認証部35とを備えている。ビットバーBBは、通信認証を行う複数の通信デバイス2間で事前に付与され、認証鍵設定部33はビットバーBBから所定の基準に従って各通信デバイス2用の認識鍵を生成する。
【選択図】図1

Description

本発明は、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムに関するものである。
従来、図8(a)に示すようにネットワーク1に接続された照明器具、空調機器、パーソナルコンピュータ、デジタルTV等通信機能を備えた通信デバイス2…相互で通信を行う際に、通信デバイス2が相手側通信デバイス2を認証する場合、第3者の認証用サーバ3を用いて認証鍵の発行と認証を行うようなっていた。
また一方図8(b)に示すようにネットワークに接続されている通信デバイス1同士が直接通信を行うP2Pの場合には事前共有鍵(プリシェアード鍵)を入力していた。
二つの通信デバイス間で共通暗号化手順を実施するために共通鍵を発生させる装置としては例えば特許文献1に開示されている装置がある。
特表平9−501556号公報
ところで、上述の図8(a)に示すネットワークシステムでは、通信デバイス数が増加すると、認証用サーバ3が持つ鍵を配布或いは交換するためのキーデータベースKDBの存在の効果が現れてくる。一方図8(b)のネットワークシステムの場合には通信デバイス数が少ない場合にはキーデバイスベースKDBのコストが不要であるため都合が良いという利点がある。
しかしながら、何れのシステムの場合も、通信デバイス2の増減が発生すると通信デバイス2及びキーデータベースKDBにおいて鍵管理の設定の手間がかかっていた。
本発明は、上述の点に鑑みて為されたもので、その目的とするところは通信デバイス毎の認証鍵の設定が簡便に行えるネットワークシステムを提供することにある。
上述の目的を達成するために、請求項1の発明では、ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とする。
請求項1の発明によれば、通信デバイスで共用する認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
請求項2の発明では、請求項1の発明において、前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする。
請求項2の発明によれば、設定した認証鍵基礎数の乱雑度を最大限に活用でき、認証鍵の強度を高く保てることができる。
請求項3の発明では、請求項2の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
請求項3の発明によれば、長さが固定である認証鍵の生成において、均等分割によって乱雑度を最大限に高めたブロックを基にするので、認証鍵の強度を高く保てる。
請求項4の発明では、請求項2の発明において、前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする。
請求項4の発明によれば、通信デバイスがアドホック的に存在する場合で、通信デバイス数が設定した認証鍵基礎数の期待数よりも多く通信デバイスが存在しても、乱数の乱雑度を保ったまま固定長の認証鍵を生成することができる。
請求項5の発明では、請求項1の発明において、前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする。
請求項5の発明において、ポインタ手段が指し示す最後のビット位置によって認証鍵の割当てができるので、通信デバイスでの認証鍵の割当て処理が簡便になる。
請求項6の発明では、請求項1乃至5の何れかの発明において、前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする。
請求項6の発明によれば、認証鍵基礎数による認証鍵群の更新を、割当て移行認証手順を経て各通信デバイス間で自立的且つ安全に行え、そのため認証鍵基礎数の再設定が簡便に行える。
請求項7の発明では、請求項6の発明において、前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする。
請求項7の発明によれば、認証鍵の更新時に参加していなかった通信デバイスも、それ以降において認証鍵を更新することができる。
請求項8の発明では、請求項2乃至4、6、7の何れかの発明において、各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする。
請求項8の発明によれば、通信デバイスの順番が決められることで、認証鍵が第3者に漏れても、通信デバイスの順番を監視することで介入を防ぐことができる。
本発明は、共用認証鍵基礎数を用いながら認証鍵設定部において認証鍵を生成することで、各通信デバイスは認証鍵を持つことができるもので、通信デバイスの増減が発生しても通信デバイス毎の認証鍵の設定が簡便にできる。
以下本発明を実施形態により説明する。
(実施形態1)
本実施形態は、例えば図2(a)に示すようにネットワーク1上に照明器具、空調機器、パーソナルコンピュータ、デジタルTV等通信機能を備えた通信デバイス2(2〜2n)を複数接続し、通信デバイス2の相互間で通信を行うネットワークシステムであるが、例えば図2(b)に示すように認証鍵K(1)…を順列に集合させた決まった長さの乱数からなる認証鍵基礎数(以下ビットバーと称する)BBを、相互に通信する通信デバイス2に生成設定する点に特徴がある。
ビットバーBBは、通信デバイス2群に対して、共通に保持する事前鍵であって、その配布は工場出荷時に通信デバイス2の記憶部に書き込む、或いはネットワークで配布する、更にはICカードやUSBメモリ等外部メモリデバイスに保持し、各通信デバイス2のメモリスロットに挿入することで保持させる等種々の方法で行う。
そして全通信デバイス2(2〜2n)で同じ値のビットバーBBを保持して後述する認証鍵生成方法により認証鍵を各通信デバイス2(2〜2n)で設定することになる。
ビットバーBB自体の生成は、ビットバーBBを生成する専用装置を用い、この装置で生成したビットバーBBを上述の外部メモリデバイスに記憶させる方法や工場出荷時に通信デバイス2の記憶部に書き込むか、ネットワーク1を通じて通信により配布する。またネットワーク1上にビットバーBBの生成・配布のみを専ら行う通信デバイス2を設けても良く、更には通信デバイス2の一つに生成機能を持たせ、ネットワーク1を通じて配布するようにしても良い。
さて本実施形態に用いる通信デバイス2は、図1(a)に示すようにCPU20と、記憶部21と、通信部22とをバス23により接続した構成を基本的なハードウェア構成として備えている。
CPU20は、通信デバイス2固有の機能部(図示せず)の制御、通信部22による通信制御、更に記憶部21の書き込みや読み出しの制御、更に認証、乱数などの処理を行う。
記憶部21は、プログラムを格納しているEEPROM21aと、実行中のプログラムの保持、更に諸データの保持を担うRAM21bとから構成される。
通信部22はネットワーク1に接続するためのイーサネット(登録商標)に対応したLAN用通信部22aや、RS232C対応の汎用通信部22bとを備えている。
ここで、本実施形態に用いる通信デバイス2のCPU20には、図1(b)に示すように配布されたビットバーBBを記憶部21のEEPROM21a或いはRAM21bに記憶させるビットバー記憶処理部32、記憶されたビットバーBBを基に、後述する認証鍵K(i)を生成して設定する認証鍵設定部33、設定された認証鍵KをRAM21bに記憶させる認証鍵記憶処理部34、更に記憶した認証鍵Kを用いて通信を認証する通信認証部35を基本的に備え、また後述するように認証鍵K(i)を生成時においてハッシュ処理する場合にはハッシュ処理部36を、またビットバー更新を行う場合にはビットバー更新部37を、ポインタ処理を行う場合にはポインタ処理部38を機能して備える。
また通信デバイス2に、ビットバーBBを生成する機能を持たせる場合には、乱数生成部30を図1(c)に示すように持たせ、その乱数生成部30を働かせるか働かせないかで、ビットバーBBの配布兼用の通信デバイスとして用いることができるようなっており、その乱数生成部30を働かせるか否かは、設定部31で設定する。
次に本発明におけるビットバーBBを用いた認証鍵Kの生成方法を実施例により説明する。
(実施例1)
本実施例では、各通信デバイス2(2〜2n)が稼動すると、工場出荷時、記憶媒体による配布、ネットワーク1を通じた配布等によって、例えばEEPROM21aに既に記憶してあるビットバーBBから認証鍵設定部33により所定のビット長さの認証鍵Kを生成する。
この場合、予め工場出荷時に設定されている通信デバイス2の接続最大数等の所定数nで均等分割し、均等分割したブロックKb1〜Kbnにインデックスを付して夫々で認証鍵K(1)〜K(n)を生成する。
図3(a)はビット長さLのビットバーBBをn等分して状態を示す。ここで、認証鍵K(1)〜K(n)のビット長さLeは所定数nでビットバーBBを均等分割して得られるブロックKb(Kb1〜Kbn)のビット長に固定したものとする。
そして通信デバイス2(2〜2n)のCPU20の認証鍵設定部33は、工場出荷時に付されたシリアル番号、通信アドレス、MACアドレス、オブジェクトIDなどの番号順、或いはランダム、予め指定された設定順、種別等に基づいて自己の認証鍵K(i)のブロックKbiを割り当て、生成設定した認証鍵K(1)〜K(n)を例えばEEPROM21aに記憶保持する。
ここで、シリアル番号、通信アドレス、MACアドレス、オブジェクトIDなどの番号順を用いる場合には、通信デバイス2(2〜2n)群は、事前に各通信デバイス2が自己の番号を送信して互いのシリアル番号を取得し合い、そのリストを作成するとともに、シリアル番号のソート処理を行い、シリアル番号の若い順にビットバーBBの上位或いは下位から認証鍵K(i)のブロックKbiを割り当てる。MACアドレスを用いる場合にはARPテーブルを参照することで実現することもできる。
また、各通信デバイス2(2〜2n)が通信を行った順番を監視し、どの通信デバイス2(2〜2n)が通信を開始したかという順番のリストを保持し、その順番で認証鍵K(i)のブロックKbiを割り当てるようにしても良い。
ところで、上述の場合n個の通信デバイス数によって均等分割したブロックにより認証鍵K(i)を設定しているが、実際にネットワーク1に接続される通信デバイス数がn個より少ない場合には、例えば上位から順次割り当てた場合、余剰のブロックは捨てるものとする。
尚通信デバイス数を動的に検出する方法としては、例えばブロードキャストピングを用いる方法を用いて行う。ここで全ての通信デバイス2(2〜2n)がTCP/IPの実装を持ち、ブロードキャストピングに応答するものとする。そしてブロードキャストピングのエコーリクエストを送信した通信デバイス2において、タイムアウト期間を設け、その期間内のエコーリプライの応答数をカウントする。これにより動的に現在稼動中の通信デバイス数を検出することができるのである。ブロードキャストは、通信デバイス2が同一セグメント内に存在することが条件となるが、例えばマルチキャストを持ち入ればセグメントを跨るネットワークにも対応することができる。
また認証鍵K(i)のビット長さが固定長Leでない暗号通信、例えばワンタイムパッド(OTP)の暗号方式などでは、メッセージ長分の認証鍵K(i)のビット長さ必要であるが、本実施例の場合のように均等分割したブロックKbiのビット長さLeが、メッセージ長より長いければ不要部分は切り捨てする。
上述の場合、ビットバーBBを所定の通信デバイス数nで均等分割したブロックKbiで認証鍵K(i)を設定しているが、実際の稼動中の通信デバイス数でビットバーBBを均等分割してブロックを設定する場合、通信デバイス数が上述のnより少ない(n−α)と一つのブロックKbiのビット長さLbは認証鍵K(i)のビット長さLeよりも長くなる。この場合は、一つのブロックKbiから認証鍵K(i)のビット長Leを切り取り余った分を捨てる。
図3(b)はこの場合のビットバーBBにおけるブロックKbiのビット長と認証鍵K(i)のビット長さLeの関係を示す。
ところで、稼動中の通信デバイス数でビットバーBBを均等分割する場合、通信デバイス数が上述のnよりも大きい(n+α)の場合には、一つのブロックKbiのビット長さLbは認証鍵K(i)のビット長さLeよりも短くなる、
この場合は、ブロックKbiの先頭からLeのビット長さだけ切り取り、この切り取った部分で認証鍵K(i)を設定する。
図3(c)はこの場合のビットバーBBにおけるブロックKbiのビット長と認証鍵K(i)のビット長さLeの関係を示す。
また認証鍵K(i)に対応するブロックKb(i)がビットバーBBの最後尾のブロックで、ビット長さLeの範囲がビットバーBBの範囲を超えるときには、図3(d)に示すように越える部分Ltを先頭のブロックL1から補う。
(実施例2)
本実施例も、実施例1と同様に認証鍵K(i)が固定のビット長さLeで、ビットバーBBの長さがLrとした場合において、稼動中の通信デバイス数が所定数nよりも小さい(n−α)場合、つまりLe≦Le/(n−α)である場合は、通信デバイス2のCPU20のハッシュ処理部36の処理によって図4(a)に示すようにブロックKbiをハッシュし、認証鍵設定部33はこのハッシュした値により認証鍵K(i)を設定する。
また、通信デバイス数が所定数nが大きい(n+α)場合、つまりLer/(n+α))である場合は、図4(b)に示すように認証鍵(Ki)はブロックKbiの先頭のビットからLeの長さまでのブロックのハッシュをハッシュ処理部36の処理で行い、認証設定部33はこのハッシュした値により認証鍵K(i)を設定する。
また、ブロックKbiがビットバーBBの最後尾であり、且つLeの長さの範囲がビットバーBBの範囲を越えるときは実施例1の図3(d)の場合と同様に、越えた部分Ltを先頭のブロックKb1から補うこととする。
上述の場合は、Leの長さがハッシュの長さと同じであるが、Leの長さがハッシュの長さより長い場合、図4(c)のようにハッシュの長さを組み合わせ、Leの長さと一致させる補正としてqとすると、複数mのブロックをハッシュした長さ(Hash size)の和からqをはぎ取るようにする。つまり認証鍵K(i)は、Le=(Hash size)×m−qによって設定される。
以上のように何れかの実施例によって事前鍵であるビットバーBBから各通信デバイス2(2〜2n))は夫々において認証鍵K(i)を生成設定する。
尚、通信デバイス2がネットワーク1上から取り外されたり、稼動を停止する場合は、通信デバイス数が経るため、当該通信デバイス2iが認証鍵K(i)に用いていたブロックKbiを空きブロックする。逆に新たに通信デバイス2iがネットワーク1に接続されて稼動している場合、空きブロックがあれば当該ブロックを認証鍵設定のブロックとしてあてがい、もしなければ全体の認証鍵生成を実施例1或いは実施例2により構成し直す。
次に上述のように生成された認証鍵K(i)を用いた認証方法を例により説明する。
(例1)
本例は図5(a)に示すように例えば、2つの通信デバイス2aと2bとの間で暗号技術を用いてチェレンジレスポンス認証方法である。尚通信デバイス2aの認証鍵をK(a),通信デバイス2bの認証鍵をK(b)とする。
まず通信デバイス2a,2bの間で一方を認証する場合には、1)、2)の方法がある。
1)通信デバイス2aのCPU20の通信認証部35の働きにより通信デバイス2b宛にナンス値Naを送る。これに対して通信デバイス2bのCPU20の通信認証部35は記憶している通信デバイス2a,2b間の共通認証鍵K(a)(b)で暗号化して{Na}K(a)(b)を通信デバイス2a宛に送る。
通信デバイス2aのCPU20の通信認証部35は共通認証鍵K(a)(b)で暗号を復号化し、自己が送信したナンス値Naの応答が得られたことで、通信相手が通信デバイス2bであると認証する。
2)通信デバイス2aのCPU20の通信認証部35の働きによりナンス値Naを共通認証鍵K(a)(b)で暗号化して{Na}K(a)(b)を通信デバイス2b宛にナンス値Naを送る。これに対して通信デバイス2bのCPU20の通信認証部35は記憶している通信デバイス2a,2b間の共通認証鍵K(a)(b)で復号化してナンス値Naを通信デバイス2aに送る。
通信デバイス2aのCPU20の通信認証部35は自己が送信したナンス値Naの応答が得られたことで、通信相手が通信デバイス2bであると認証する。
通信デバイス2bと通信デバイス2aとの間で相互認証を行う場合、3)、4)の方法がある
3)通信デバイス2aのCPU20の通信認証部35の働きによりナンス値Naを共通認証鍵K(a)(b)で暗号化して{Na}K(a)(b)を通信デバイス2b宛に送る。これに対して通信デバイス2bのCPU20の通信認証部35は記憶している通信デバイス2a,2b間の共通認証鍵K(a)(b)でナンス値Naを復号化し、この復号によって得たナンス値Naと、ナンス値Nbを共通認証鍵K(a)(b)で暗号化し、{Nb}K(a)(b)、Naを通信デバイス2aに送る。
通信デバイス2aのCPU20の通信認証部35は自己が送信したナンス値Naの応答が得られれば、通信相手が通信デバイス2bであると認証し、更に共通認証鍵K(a)(b)でナンス値Nbを復号化し通信デバイス2b宛にNbを送る。
通信デバイス2bのCPU20の通信認証部35は自己が送信したナンス値Nbの応答が得られたことで、通信相手が通信デバイス2aであると認証する。
4)通信デバイス2aのCPU20の通信認証部35の働きによりナンス値Naを通信デバイス2b宛にナンス値Naを送る。これに対して通信デバイス2bのCPU20の通信認証部35は記憶している通信デバイス2a,2b間の共通認証鍵K(a)(b)でナンス値Naを暗号化し、この暗号化した値と所定のナンス値Nb、{Na}K(a)(b)、Nbを通信デバイス2aに送る。
通信デバイス2aのCPU20の通信認証部35は自己が送信したナンス値Naの応答が得られれば、通信相手が通信デバイス2bであると認証し、更に共通認証鍵K(a)(b)でナンス値Nbを復号化し通信デバイス2b宛にNbを送る。
通信デバイス2bのCPU20の通信認証部35は共通認証鍵K(a)(b)でナンス値Naを復号化し、自己が送信したナンス値Nbの応答が得られたことで、通信相手が通信デバイス2bであると認証する。そして共通認証鍵K(a)(b)でナンス値Nbを暗号化し、{Nb}K(a)(b)を通信デバイス2b宛に送る。
通信デバイス2bのCPU20の通信認証部35は共通認証鍵K(a)(b)でナンス値Nbを複合化し、自己が送信したナンス値Nbの応答が得られたことで、通信相手が通信デバイス2aであると認証する。
(例2)
本例は、ISO/IECの978−2標準として2者間の通信の認証する方法であって、片方向認証としてはタイムスタンプを用いて方法と、ナンス値を用いた方法とがある。
1)タイムスタンプを用いた片方向認証方式では、図5(a)において、一方の通信デバイス2aが他方の通信デバイス2bにタイムスタンプTaと、メッセージBとを共通認証鍵K(a)(b)で暗号化して{Ta,B}K(a)(b)を送る。これを受け取った通信デバイス2bのCPU20の通信認証部35は、共通認証鍵K(a)(b)で復号化し、送られてきたメッセージBが自己宛のメッセージであれば、相手を識別して認証するのである。
2)ナンス値を用いて相互認証を行う場合、まず一方の通信デバイス2bのCPU20の通信認証部35はナンス値Nbを他方の通信デバイス2a宛に送る。通信デバイス2aのCPU20の通信認証部35は受け取ったナンス値Nbと、自己のナンス値Naと、通信デバイス2bへのメッセージを識別するための値Bとを、共通認証鍵K(a)(b)で暗号化し、{Na,Nb、B}K(a)(b)を通信デバイス2b宛に送る。
通信デバイス2bのCPU20の通信認証部35は、共通認証鍵K(a)(b)で復号化し、自己のナンス値Nbと復号化したナンス値Naとを共通認証鍵K(a)(b)で暗号化し、{Na,Nb}K(a)(b)を通信デバイス2a宛に送る。
このようにして通信デバイス2a、2bは自己のナンス値Na,Nbが送り消されることで、相互を認証するのである。
(例3)
本例はNeedham-Schroederのような第三者認証に対応するものである。
まず本例では、通信デバイス2aと2bの間で直接認証を行わず、信頼できる第三者の通信デバイス(ここでは2Pとする)
まず、通信デバイス2aのCPU20の通信認証部35は、通信デバイス2Pに対して、送信したい通信相手の識別のために通信デバイス2a,2bの値A、B及びナンス値Naを送信する。
通信デバイス2PCPU20の通信認証部35は、通信デバイス2aと通信デバイス2Pの間の共通認証鍵K(a)(p)でナンス値Naと、値B,Aと、通信デバイス2a、2b間の共通認証鍵K(a)(b)、及び2bのみが復号できるように共通認証鍵K(a)(b)と、値Aとを通信デバイス2b、2Pの間の共通認証鍵K(b)(p)で暗号化し、更に共通認証鍵K(a)(p)で暗号化し、{Na,B,K(a)(b),{K(a)(b)、A}K(b)(p)}K(a)(p)として通信デバイス2aに送る。
通信デバイス2aのCPU20の通信認証部35は、共通認証鍵K(b)(p)で復号し、{K(a)(b)、A}K(b)(p)を通信デバイス2b宛に送る。
通信デバイス2bのCPU20の通信認証部35は、共通認証鍵K(b)(p)でそのメッセージを復号し、K(a)(b)を得る。そして得られた共通認証鍵K(a)(b)でナンス値Nbを暗号化し、通信デバイス2a宛に送る。
通信デバイス2aのCPU20の通信認証部35は、そのメッセージを共通認証鍵K(a)(b)で復号し、受け取った証しとして通信デバイス2bにナンス値Nbから1引いた値を共通認証鍵K(a)(b)で暗号化し、通信デバイス2bに送る。通信デバイス2aのCPU20の通信認証部35は、そのメッセージを共通認証鍵K(a)(b)で復号し、ナンス値Nbから1引かれていることで、認証されたことを確認する。
(例4)
本例は、ISO/lECの9798−3標準として公開鍵暗号を用いた認証方式に対応する。
1)タイムスタンプを用いた片方向認証方式の場合、通信デバイス2aから通信デバイス2bにCA(PKa),Ta,B,SlGN(Ta,B)PKa−1を送る。
この場合、認証としてタイムスタンプを用いるためナンス値は必要としない。またCA(PKa)は通信デバイス2aの公開鍵Pkaの証明書に含まれる例を示す。Taはタイムスタンプを示す。更にBは通信デバイス2bへのメッセージであるという識別の値を示し、SIGN(Ta,B)PKa−1は通信デバイス2aの公開鍵に対する秘密鍵PKa−1でデジタル署名を行っていることを示す。
2)ナンス値を用いた相互認証方式の場合には、通信デバイス2bから通信デバイス2aにナンス値Nbをまず送る。通信デバイス2aからは通信デバイス2aの公開鍵PKaを含む証明書CA(PKa),通信デバイス2aのナンス値Na,通信デバイス2bへのメッセージの識別の値B,Na,Nb,Bを秘密鍵PKa−1でデジタル署名して、
CA(PKa),Na,B,SIGN(Na,Nb,B)PKa−1を通信デバイス2bに送る。
通信デバイス2bは、通信デバイス2aに、通信デバイス2bの公開鍵PKbを含む証明書CA(PKb)、通信デバイス2aへのメッセージの識別の値a,ナンス値Nb,Naを秘密鍵PKb−1でデジタル署名して、CA(PKb),A,SIGN(Nb,Na,A)PKb−1を通信デバイス2aに送る。尚()内は共通認証鍵K(a)(b)で暗号化されていることを示す。
(例5)
本例は、暗号よりも処理が高速なハッシュ系の技術でKryptoKnightのMACを用いた2者間の認証プロトコルを用いるものである。
まず、通信デバイス2aから通信デバイス2bに非暗号のナンス値Naを送る。そして通信デバイス2bのCPU20の通信認証部35は、非暗号のナンス値Nbと共通認証鍵K(a)(b)でナンス値Na,Nbと通信デバイス2bからのメッセージを識別する値BをMAC処理し、Nb,MAC(Na,Nb,B)K(b)(a)として通信デバイス2aに送る。
通信デバイス2aは同様にナンス値Na、NbをMAC処理し、通信デバイス2bにMAC(Na,Nb)K(a)(b)として送る。
このようにISO/IECの標準の例では、タイムスタンプ方式を除けば、ナンス値を用いた認証方式は多岐に渡る。
以上の認証方法の例は二つの通信デバイス2a,2b間の片方若しくは双方向の認証方法であったが、通信デバイス2a…間でグループを形成する場合の認証方法を例6,例7により説明する。
(例6)
本例は、多数決の方法をとったグループ認証方法である。
例えば図5(b)に示すように複数の通信デバイス2a,2b,2c、2dが、或る認証子(ID)又はポリシーを持ち、通信デバイス間で連係動作するためのグループを形成したいとする。例えば図1(a)に示すシステムで通信デバイス2aのCPU20の通信認証部35が、自己のは認証鍵K(a)を用いて暗号化して認証子(ID)或いはポリシーをブロードキャストで送信したする。ここで認証鍵K(a)は既に認証されているので、受信側の通信デバイス2b〜2dは送信元が通信デバイス2aであることがわかる。
次に認証子(ID)又はポリシーの条件によって、通信デバイス2a以外の通信デバイス2b〜2dの内、或る通信デバイス2jはACK(許可)を返し、或る通信デバイス2mはNAK(不許可)を返すとする。ここで通信デバイス2aのCPU20の通信認証部35は、各通信デバイス2b〜2nからの応答のACK,NAKを受信してそれぞれの応答数をカウントする。ここで、閾値BLを事前に設定しておき、閾値BLをACKの総数が超えれば通信デバイス2a〜2dのグループ内で通信デバイス2aは認証されたこととなる。
ここで、閾値BLは、通信デバイス2の全数(n数)を上述のように動的に検出し、閾値BLの値を調停する。又は工場出荷時に設定するなどしても良い。
このようにして、グループ内での通信デバイス2の認証が可能となる。ここで、認証子(ID)の代わりにポリシー等アクセス権に関わる情報をやり取りしても良い。
そして予め定めている下限値LMを、参加通信デバイス数が下回る場合にはグループ内の認証が成立しないものする。
(例7)
本例は、ビットバーBBによって既に配布されている認証鍵によって、ブロードキャスト、マルチキャスト、ユニキャスト等の方法で配布する個別鍵からグループの認証方法である。
つまり、個別鍵生成を利用してストックされた鍵を各通信デバイス2が蓄積し、ストックSKa…を生成し、このストックSKa…の生成後、ストックKa…を結合しグループ鎚を生成する。
この場合、単純にストックした値をビットバーBBの通信デバイス2の順番でグループ化とするか、GK(a)(b)(c)=HASH(SKa|SKb|SKc|…)とハッシュを計算する。ここで通信デバイス2dが例6のグループ認証の結果NAKで不許可であったとしても、通信デバイス2dを含めて、グループ鍵を生成しても良く、また、その逆で、NAKで不許可であった通信デバイス2dを含めず、グループ鍵を生成しても良い。これはシステムのポリシーに依存する。
ところで、ビットバーBBは、工場出荷時などで秘密裏に各通信デバイス2に共有されることを前提とするため、一旦その値が悪意の第三者に漏れると、安全上の脅威となってしまう。
そこで、本実施形態では、第三者に漏れても通信デバイス2群の通信を終始監視し、sの間に介入していなければ、安全に更新する方法を採用している。
まず、ビットバーBBを図1(a)のシステムにおいて、更新したい通信デバイス2〜2nまでの全てが稼動している場合、古い認証鍵で各通信デバイス2〜2nが新しいビットバーBBのブロックKbを渡し合い、各通信デバイス2〜2nの順番に或るブロックと置き換える。つまり、通信デバイス2Kは当該通信デバイス2Kに割り当てられたビットバーBBのブロックKbkの認証鍵K(K)に対応して、CPU20のビットバー更新部37によってブロックKbkのビット長さに相当する乱数を生成し、新しい部分鍵K(K)’とする。この部分鍵K(K)’を現在の認証鍵K(K)で暗号化し、自己を除いた全通信デバイス2〜2nに更新メッセージとして送信する。全通信デバイス2〜2nは、既に上述の認証鍵生成設定と割当てにより、通信デバイス2Kから送信された更新メッセージの認証鍵K(K)でメッセージを復号し部分鍵K(K)’を得る。同様にして、全ての通信デバイス2〜2nが更新メッセージを送信し、全通信デバイス2〜2nが全ての部分鍵K(1)’〜K(n)’を得たならば、これを結合し新たなビットバーBBとする。
図6は通信デバイス2aで当該通信デバイス2aに割り当てられたビットバーBB0のブロックKbaの認証鍵K(a)に対応して、ブロックKbaのビット長さに相当する乱数を生成し、新しい部分鍵K(a)’とし、これを結合し新たなビットバーBB1とする。またこの部分鍵K(a)’を現在の認証鍵K(a)で暗号化(図では+を入れた○印で示す)し、例えば通信デバイス2bに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス2bは、既に上述の認証鍵生成設定と割当てにより、通信デバイス2aから送信された更新メッセージの認証鍵K(a)でメッセージを復号し部分鍵K(a)’を得る。通信デバイス2bが部分鍵K(a)’を得たならば、これを結合し新たなビットバーBB1としている。その後同様に新しい部分鍵K(a)”を生成し、この部分鍵K(a)”を用いてビットバーBB1をBB2に更新している。
また、通信デバイス2〜2nまでの全ての通信デバイスが起動していない場合、必ずしもビットバーBBを更新したい全ての通信デバイス2〜2nが更新時に起動しているとは限らない。そこで、更新期限があったとすれば、更新期限内に参加していない通信デバイス2の場合はそのまま古いブロックを部分鍵とする。この場合、新しいブロックKでの認証鍵を使ったメッセージを更新期限内に起動していなかった通信デバイスが受信した場合、メッセージを復号できない問題がある。この場合は、再更新の方法として、通信デバイス2が復号できない旨を伝え、通信デバイス2が古い認証鍵で認証されると、その通信デバイス2を除く全応答可能通信デバイス2は保持しておいた古い認証鍵で暗号化してその通信デバイス2に送るようにすることで更新する。
その他の更新方法としては、ビットバーBBの更新方法として複数のビットバーBBの履歴を持ち、古いビットバーBBから新しいビットバーBBを構築する方法もある。例えば、或る期間には起動していなかった通信デバイス2があり、古い認証鍵しかなかった場合、この通信デバイス2のビットバーBBを更新する方法として新しいビットバーBBを持つ通信デバイス2と古いビットバーBBを持つ通信デバイス2は常に時間又は回数(カウンタ)による履歴の管理を行い、ビットバーBBの時間又は回数を確認し、更新した時期のビットバーBBで通信させ、後に上述のビットバーBBの更新方法で更新する方法もある。
つまり、例えば、通信デバイス2Kにおいて、ビットバーBBから認証鍵K(K)を生成設定する際にCPU20のビットバー更新部37がビットバー履歴を作成して例えばEEPROM21aに保持する。そして更新に当たっては部分鍵K(K)’を乱数で生成する。この部分鍵K(K)’のサイズは認証鍵K(K)と同じブロックのビット長さとする。部分鍵K(K)’を古い認証鍵K(K)で暗号化して履歴付で自己を除く全通信デバイス2〜2nに送信する。全通信デバイス2〜2nは受け取ったメッセージを履歴に対応する古い認証鍵K(K)で復号し、送った相手(2K)に割り当てられたビットバーBBのブロックKbkを部分鍵K(K)’で更新するのである。
図7は通信デバイス2aで当該通信デバイス2aに割り当てられたビットバーBB0のブロックKbaの認証鍵K(a)に対応して、ブロックKbaのビット長さに相当する乱数を生成し、新しい部分鍵K(a)’とし、この部分鍵K(a)’で自己の現在のビットバーBB0を更新するとともに、このビットバーBB0の履歴を作成し、この履歴作成後、現在の認証鍵K(a)で暗号化(図では+を入れた○印で示す)し、古いビットバーBB0を用いていることを示す、つまり履歴(更新時間、更新回数、識別子等)を示すメッセージBB0_IDとともに、例えば通信デバイス2bに更新メッセージとして送信する様子を示しており、この図示例では、通信デバイス2bは、既に上述の認証鍵生成設定と割当てにより、通信デバイス2aから送信された更新メッセージの認証鍵K(a)でメッセージを復号し部分鍵K(a)’を得る。通信デバイス2bが部分鍵K(a)’を得たならば、これを結合し新たなビットバーBB1とし、また現在のビットバーBB0の履歴を作成する。
図7では、新たに通信デバイス2cが参加した場合を示しており、この通信デバイス2cは古いビットバーBB0を持つものであるので、例えば通信デバイス2aに認証を受ける場合、ナンス値を通信デバイス2aと共通の認証鍵K(a)(c)で暗号化し、メッセージBB0_IDとともに通信デバイス2a宛に送る。一方通信デバイス2aでは受け取った履歴を示すメッセージBB0_IDに基づいて対応する古いビットバーBB0による共通の認証鍵K(a)(c)を選択してナンス値を復号し、通信デバイス2cに返えす。これにより通信デバイス2cは認証が成功したことを知ることになる。これにより認証鍵更新時に参加していなかった通信デバイス2cも認証後、更新できることになる。
以上のように本実施形態では、上述したビットバーBBを事前鍵として各通信デバイス2に配布し、上述の実施例1、2のような方法により各通信デバイス2の認証鍵K(i)を設定することで、通信デバイス2の増減が発生しても通信デバイス2毎の認証鍵K(i)の設定が簡便にできることになる。
また、各通信デバイス2は、ネットワーク1上で通信した順番を記録する通信順リストを記憶部21のEEPROM21aにに保持することで、ビットバーBBの各ブロックKbは、その先頭ブロックから、記録した通信順リストに認識された通信デバイスの順番に対応して割り当てることで、順番が明確に分かることになり、後でノードに問題が分かった場合これを使わないようにする。
(実施形態2)
上述の実施形態1ではビットバーBBから認証鍵生成を行う場合、通信デバイス数でビットバーBBを分割し、その分割したブロックの値で認証鍵としていたが、本実施形態では、直ちに認証鍵として使わず、ポインタとして通知する方法を採用した点に特徴がある。
つまり、通信デバイス2は、CPU20に備えたポインタ処理部38によって、ブロックのN番目を利用すると宣言し、それをポインタとして全通信デバイス2に送信する。ポインタを受信した電子デバイス2のCPU20の認証鍵設定部33では、ビットバーBBにおいて、ポインタの先頭又は末尾から所定の鍵長分までを認証鍵として割り当てる。また受信しなければポインタ値=0とする。ポインタは割り当てた先まで進め、他の通信デバイス2に送信する。ポインタ送信及び受信では通信デバイス2間の認証を前提に送受信しても良い。
また、乱数を送信し、受信側は乱数を通信デバイス数で割ることでその値をポインタとすることもできる。
本実施形態のように認証鍵を順番に利用するのではなく、任意又はランダムに扱えるため、通信を解析する第三者によるビットバーBBの推測がより困難となる。
尚その他の構成、認証方法、更新方法は実施形態1と同じであるので、図示、説明は省略する。
(a)は実施形態1の通信デバイスの構成図、(b)はビットバー生成のための通信デバイスのCPUの機能ブロック図、(c)は通信デバイスのCPUの機能ブロック図である。 (a)は実施形態1のシステム構成図、(b)はビットバーの説明図である。 実施形態1のビットバーと認証鍵の生成に対応する実施例1の説明図である。 実施形態1のビットバーと認証鍵の生成に対応する実施例2の説明図である。 (a)、(b)は実施形態1における認証方法説明用のシステム図である。 実施形態1のビットバー更新の一例のシーケンス図である。 実施形態1のビットバー更新の別の例のシーケンス図である。 (a)、(b)は従来例のシステム構成図である。
符号の説明
2 通信デバイス
20 CPU
21 記憶部
22 通信部
23 バス
30 乱数発生部
31 設定部
32 ビットバー記憶処理部
33 認証鍵設定部
34 認証鍵記憶処理部
35 通信認証部
36 ハッシュ処理部
37 ビットバー更新部
38 ポインタ処理部

Claims (8)

  1. ネットワークに接続された通信デバイス間で、夫々の通信デバイスが保有する認証鍵を用いて相互の通信認証を行うネットワークシステムであって、
    各通信デバイスは、認証鍵を順列に集合させた決まった長さの乱数からなる認証鍵基礎数を記憶する記憶部と、
    前記認証鍵基礎数に基づいて自己の認証鍵を設定する認証鍵設定部と、
    設定された前記認証鍵を用いた他の通信デバイスに対して通信認証を行う通信認証部とを備えてなり、
    前記認証鍵基礎数は、通信認証を行う複数の通信デバイス間で事前に付与され、
    前記認証鍵設定部は、前記認証鍵基礎数から所定の基準に従って各通信デバイス用の認識鍵を生成することを特徴とするネットワークシステム。
  2. 前記認証鍵設定部は、通信認証を行う通信デバイスの個数で前記認識鍵基礎数を均等分割し、分割された各ブロックを夫々の通信デバイス用の認証鍵基準数として割り当てることを特徴とする請求項1記載のネットワークシステム。
  3. 前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも大きい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項2記載のネットワークシステム。
  4. 前記通信デバイスの認証鍵の長さが固定の場合で、前記ブロックのビット長さが、前記認証鍵のビット長さよりも小さい場合、当該ブロックをハッシュして前記認証鍵のビット長さに調整することを特徴とする請求項2記載のネットワークシステム。
  5. 前記認証鍵設定部は、前記認証鍵基礎数の内、既に認証鍵として使われた部分の最後のビット位置を示すポインタ手段を有するとともに、新しく認証鍵基礎数から設定するときは、前記ポインタ手段が指し示す最後のビット位置から取り出して自己の認証鍵とし、他の通信デバイスには、今回使用した最後のビット位置を通知することを特徴とする請求項1記載のネットワークシステム。
  6. 前記通信デバイスは、乱数を発生させる乱数発生部と、現在の認証鍵基礎数と同じビット長さを有する新規の認証鍵基礎数を生成する更新手段とを備えてなり、
    現在の認証鍵を使って他の通信デバイスと通信認証を行い、認証された場合には、当該他の通信デバイスに対し前記発生させた乱数を送信するとともに、当該他の通信デバイスの更新手段が生成した新規の認証鍵基礎数中に前記送信した乱数を、現在の認証鍵基礎数中で現在の認証鍵が占めるビット位置に対応する位置になるように割り当て、認証鍵基礎数を更新することを特徴とする請求項1乃至5の何れかの1項に記載のネットワークシステム。
  7. 前記認証鍵基礎数を更新する時点で認証鍵基礎数の更新を実行していなかった通信デバイスについては認証基礎数の過去の履歴を持つことで認証鍵基礎数の更新を再実行することを特徴とする請求項6項に記載のネットワークシステム。
  8. 各通信デバイスは、ネットワーク上で通信した順番を記録する通信順リストを保持し、前記認証鍵基礎数の各ブロックは、その先頭ブロックから、前記記録した通信順リストに認識された通信デバイスの順番に対応して割り当てられていることを特徴とする請求項2乃至4、6、7の何れかの1項に記載のネットワークシステム。
JP2007083007A 2007-03-27 2007-03-27 ネットワークシステム Expired - Fee Related JP5080837B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007083007A JP5080837B2 (ja) 2007-03-27 2007-03-27 ネットワークシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007083007A JP5080837B2 (ja) 2007-03-27 2007-03-27 ネットワークシステム

Publications (2)

Publication Number Publication Date
JP2008244885A true JP2008244885A (ja) 2008-10-09
JP5080837B2 JP5080837B2 (ja) 2012-11-21

Family

ID=39915667

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007083007A Expired - Fee Related JP5080837B2 (ja) 2007-03-27 2007-03-27 ネットワークシステム

Country Status (1)

Country Link
JP (1) JP5080837B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023195247A1 (ja) * 2022-04-06 2023-10-12 ソニーセミコンダクタソリューションズ株式会社 センサ装置、制御方法、情報処理装置、情報処理システム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10327142A (ja) * 1997-03-26 1998-12-08 Sony Corp 認証システムおよび方法、並びに認証装置および方法
JP2001211159A (ja) * 2000-01-27 2001-08-03 Victor Co Of Japan Ltd コンテンツ情報復号化方法、コンテンツ情報復号化装置
JP2004112510A (ja) * 2002-09-19 2004-04-08 Sony Corp データ処理方法、そのプログラムおよびその装置
JP2004254271A (ja) * 2002-12-25 2004-09-09 Hitachi Ltd ネットワーク機器、ネットワークシステム、および、グループ管理方法
JP2006352215A (ja) * 2005-06-13 2006-12-28 Felica Networks Inc 相互認証システム,情報処理装置,情報処理方法,およびコンピュータプログラム
JP2007074369A (ja) * 2005-09-07 2007-03-22 Mitsubishi Electric Engineering Co Ltd 無線lan暗号化通信システム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10327142A (ja) * 1997-03-26 1998-12-08 Sony Corp 認証システムおよび方法、並びに認証装置および方法
JP2001211159A (ja) * 2000-01-27 2001-08-03 Victor Co Of Japan Ltd コンテンツ情報復号化方法、コンテンツ情報復号化装置
JP2004112510A (ja) * 2002-09-19 2004-04-08 Sony Corp データ処理方法、そのプログラムおよびその装置
JP2004254271A (ja) * 2002-12-25 2004-09-09 Hitachi Ltd ネットワーク機器、ネットワークシステム、および、グループ管理方法
JP2006352215A (ja) * 2005-06-13 2006-12-28 Felica Networks Inc 相互認証システム,情報処理装置,情報処理方法,およびコンピュータプログラム
JP2007074369A (ja) * 2005-09-07 2007-03-22 Mitsubishi Electric Engineering Co Ltd 無線lan暗号化通信システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023195247A1 (ja) * 2022-04-06 2023-10-12 ソニーセミコンダクタソリューションズ株式会社 センサ装置、制御方法、情報処理装置、情報処理システム

Also Published As

Publication number Publication date
JP5080837B2 (ja) 2012-11-21

Similar Documents

Publication Publication Date Title
US10951400B2 (en) Authentication method, authentication system, and controller
CN111771390B (zh) 自组织网络
US11265709B2 (en) Efficient internet-of-things (IoT) data encryption/decryption
US9107069B2 (en) Addressable radio device
US8600063B2 (en) Key distribution system
JP5975594B2 (ja) 通信端末及び通信システム
US20170111357A1 (en) Authentication method and authentication system
US20080292105A1 (en) Lightweight key distribution and management method for sensor networks
US20020154782A1 (en) System and method for key distribution to maintain secure communication
EP3437247A1 (en) System and method for distribution of identity based key material and certificate
Tiloca et al. Axiom: DTLS-based secure IoT group communication
WO2017167771A1 (en) Handshake protocols for identity-based key material and certificates
US20220141004A1 (en) Efficient Internet-Of-Things (IoT) Data Encryption/Decryption
WO2014056744A1 (en) Addressable radio device
GB2494550A (en) Dynamic address allocation to a radio device
Das An efficient random key distribution scheme for large‐scale distributed sensor networks
US20080095369A1 (en) Method of configuring a node, related node and configuration server
CN104769907A (zh) 用于传输数据的装置和方法
US20170359178A1 (en) Network communication method having function of recovering terminal session
JP2008042655A (ja) 通信暗号化処理装置
EP2720404A1 (en) Addressable radio device
JP5080837B2 (ja) ネットワークシステム
Resner et al. Key establishment and trustful communication for the internet of things
CN110572788B (zh) 基于非对称密钥池和隐式证书的无线传感器通信方法和系统
CN109067705B (zh) 基于群组通信的改进型Kerberos身份认证系统和方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091023

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20101007

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A712

Effective date: 20120112

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120515

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120717

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120807

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120831

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150907

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5080837

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees