(57)【要約】  【課題】鍵を配布するサーバと複数のクライアント端末とを含む暗号通信システムにおいて、鍵の更新をフレキシブルに実行できる暗号通信システムを提供する。  【解決手段】鍵配布サーバは、順々にクライアント端末宛に鍵を配布する（S24）。配布に対する応答が無ければ（S25:No）、鍵の配布を中止する（S29）。また、鍵を配布し終えた後で、配布したクライアント端末に順々に更新指示を通知して、鍵を更新させる（S26,S27）。  【選択図】図１０
2009212850.tif 000002
【特許請求の範囲】
【請求項１】
鍵配布サーバと、相互に共通鍵方式の暗号通信を行う複数のクライアント端末とを含む暗号通信システムであって、
鍵配布サーバは、
前記複数のクライアント端末に順次、同じ鍵を配布する配布手段と、
前記鍵を配布した複数のクライアント端末から、配布に対する応答を受信する受信手段と、
配布した全てのクライアント端末からの応答が受信された場合に限って、複数のクライアント端末に順次、配布した前記鍵の使用を開始すべき旨を示す更新指示を通知する通知手段と、
複数のクライアント端末それぞれは、
配布された鍵を受信する受信手段と、
配布に対する応答を送信する送信手段と、
暗号通信に際して、第１の鍵を用いてデータの暗号化または復号を行う暗号処理手段と、
前記更新指示を受けると、受信した鍵を前記第１の鍵として設定する鍵設定手段とを備える
ことを特徴とする暗号通信システム。
【請求項２】
前記暗号処理手段は、暗号通信に際して、第１の鍵を用いたデータの復号に失敗した場合には、第２の鍵を用い、
前記鍵設定手段は、前記更新指示を受けると、それまで前記第１の鍵として使用していた鍵を前記第２の鍵として設定する
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項３】
前記鍵配布サーバ及び複数のクライアント端末はそれぞれ、同じ初期鍵を記憶しており、
前記鍵配布サーバは、
配布すべき同じ鍵を予め前記初期鍵を用いて暗号化する暗号化手段を備え、
前記配布手段は、暗号化された鍵を各クライアント端末に配布し、
前記暗号処理手段は、前記初期鍵を用いて配布された鍵を復号し、
前記鍵設定手段は、復号された鍵を前記第１の鍵として設定する
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項４】
前記鍵配布サーバは、
管理下にある複数のクライアント端末それぞれの識別子を含むクライアント端末管理テーブルを記憶するテーブル記憶手段を備え、
前記配布手段は、クライアント端末管理テーブルに登録された複数のクライアント端末宛に配布を行い、
前記複数のクライアント端末ぞれぞれは、
さらに、自己に関する情報を含み鍵配布サーバの管理下への参入要求を送出する参入要求送出手段とを備え、
前記鍵配布サーバは、
前記参入要求を受け取った場合に、参入要求の送出元クライアント端末に関する情報を表示し、参入可否の選択を受け付けるユーザインターフェイス手段と、
参入可を受け付けた場合には、前記送出元クライアント端末の識別子を前記クライアント端末管理テーブルに登録し、参入否の項目を受け付けた場合には、登録を行わないテーブル管理手段とを備える
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項５】
前記鍵配布サーバは、
前記配布を所与のスケジュールに従って繰り返し実行させるスケジュール手段と、
管理下にある複数のクライアント端末それぞれの識別子を含むクライアント端末管理テーブルを記憶するテーブル記憶と、
クライアント端末から受け取った鍵配布サーバの管理下への参入要求を、前記所与のスケジュールにおいて前回配布した鍵を用いて認証のために復号し、復号に失敗した場合には、さらに前に配布した鍵を用いて復号し、正しく復号できた場合には参入を許可する許可手段と、
参入を許可した場合には、前記送出元クライアント端末の識別子を前記クライアント端末管理テーブルに登録するテーブル管理手段とを備える
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項６】
前記鍵配布サーバは、
前記配布を所与のスケジュールに従って繰り返し実行させるスケジュール手段とを備え、
当該スケジュール手段は、前記配布した全てのクライアント端末からの応答が受信されるまでは、前記所与のスケジュールにおける次回の配布の実行を禁止する
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項７】
前記鍵配布サーバは、
前記鍵配布サーバは、さらに、複数のクライアント端末それぞれの生存／非生存の別を示す生存状況を監視する監視手段と、
管理下にある複数のクライアント端末それぞれの識別子と、それぞれの生存状況とを対応付けたクライアント端末管理テーブルを記憶するテーブル記憶手段を備え、
前記配布手段は、クライアント端末管理テーブルを参照して、複数のクライアント端末のうちで、生存しているクライアント端末に配布を行い、非生存のクライアント端末には配布を行わない
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項８】
前記鍵設定手段は、前記受信手段による鍵の受信から所定時間経過した場合に、
受信した鍵を前記第１の鍵として設定する
ことを特徴とする請求項１に記載の暗号通信システム。
【請求項９】
前記複数のクライアント端末は、扉開閉に係る情報を読み取る認証端末と、前記扉開閉に係る情報に基づいて扉開閉制御を行う管理装置とを含み、
前記認証端末と前記管理装置との間で、前記配布手段により配布された鍵を用いて、前記扉開閉に係る情報の暗号通信を行う
ことを特徴とする請求項１に記載の暗号通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置間で共通鍵暗号方式による通信を行う暗号通信システムに関し、特に鍵の更新技術に関する。
【背景技術】
【０００２】
従来から装置間の通信においては、通信内容の秘匿性を確保するべく、暗号化及び復号に共通鍵を用いて通信を行う共通鍵方式の暗号通信システムが知られている。
【０００３】
係る暗号通信システムにおいては、同じ共通鍵を使用し続けると、その共通鍵が解読される危険性が増す。このため、共通鍵を更新する技術が知られている（特許文献１）。
【特許文献１】特開2007-267301号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明者らは、扉の施錠・解錠制御などの入退室管理を行う入退室管理システムにおいて、装置間通信の暗号化導入を検討している。入退室管理システムは、例えば扉の側に設置されたカード認証端末装置と、監視装置とを含んで構成され、限られたスペック内で、レスポンスの良い扉開閉制御が要請されている。
【０００５】
一般的な共通鍵方式では、装置の台数が増えると鍵の数が膨大になる（Ｎ台の装置間で通信を行うとすると、ＮＣ２＝ｎ（ｎ−１）／２個必要）。上記導入にあたっては上述の要請に鑑み、装置間で同じ共通鍵を用いることで、鍵の管理負担を回避することとした。
【０００６】
さて、この同じ共通鍵を更新する場合には、鍵配布サーバからシステム内の各装置に新しい共通鍵をあまねく配布する必要がある。特にシステムが大規模化すると、各装置の中には新しい共通鍵を受信できなかった装置が発生し得る。
【０００７】
係る不受信は、一時的な通信障害等により鍵の受信に対応できなかったという事情も考えられる。このことを考慮すると、そのまま鍵更新を強行して、鍵を受信し損ねた装置をシステム内の通信から一律に脱落させるのは妥当ではない。
【０００８】
また、共通鍵を更新する際には、各装置間での通信に支障をきたさないように、最適な更新タイミングを探る必要がある。
【０００９】
以上述べた問題は、これは入退室管理システムに限られた課題ではなく、共通鍵暗号方式による通信を行うシステムにおいて鍵を更新する場合には同様に問題となる。
【００１０】
本発明は上述の問題に鑑みてなされたものであって、鍵を配布するサーバと複数のクライアント端末とを含む暗号通信システムにおいて、鍵の更新をフレキシブルに実行できる暗号通信システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
発明が解決しようとする課題を解決するために、本発明に係る暗号通信システムは、鍵配布サーバと、相互に共通鍵方式の暗号通信を行う複数のクライアント端末とを含む暗号通信システムであって、鍵配布サーバは、前記複数のクライアント端末に順次、同じ鍵を配布する配布手段と、前記鍵を配布した複数のクライアント端末から、配布に対する応答を受信する受信手段と、配布した全てのクライアント端末からの応答が受信された場合に限って、複数のクライアント端末に順次、配布した前記鍵の使用を開始すべき旨を示す更新指示を通知する通知手段と、複数のクライアント端末それぞれは、配布された鍵を受信する受信手段と、配布に対する応答を送信する送信手段と、暗号通信に際して、第１の鍵を用いてデータの暗号化または復号を行う暗号処理手段と、前記更新指示を受けると、受信した鍵を前記第１の鍵として設定する鍵設定手段とを備えることを特徴とする。
【発明の効果】
【００１２】
課題を解決するための手段に記載した構成によれば、前記通知手段は、配布した全てのクライアントからの応答が受信された場合に限って、更新指示を通知するため、配布した同じ共通鍵を受信し損なったクライアントを置き去りにして鍵を更新してしまうことを防ぐことができる。
【００１３】
なお、通信量を最小限にしたとしても、鍵配布時のデータ量は更新指示のデータ量と比べて大きいため、鍵配布は鍵更新と比べて所要時間が長くなる傾向がある。前記サーバは、全てのクライアントからの応答が受信された場合に限って、更新指示を通知するため、複数のクライアントそれぞれの鍵設定更新のタイミングをある程度は揃えることができる。
【００１４】
また、前記暗号処理手段は、暗号通信に際して、第１の鍵を用いたデータの復号に失敗した場合には、第２の鍵を用い、前記鍵設定手段は、前記更新指示を受けると、それまで前記第１の鍵として使用していた鍵を前記第２の鍵として設定することを特徴とする。
【００１５】
更新指示は、クライアント端末に順次通知されるため、クライアント端末の数が多いと、更新指示・鍵更新のタイミングのずれが顕著となる。この構成によれば、更新以前に第１の鍵として使用していた鍵を第２の鍵として設定しバックアップとして使用に供するため、例えば、既に鍵更新を終えたクライアント端末は、未だ鍵更新を行っていないクライアント端末から受信したデータを正しく復号することができる。
【００１６】
また、前記鍵配布サーバ及び複数のクライアント端末はそれぞれ、同じ初期鍵を記憶しており、前記鍵配布サーバは、配布すべき同じ鍵を予め前記初期鍵を用いて暗号化する暗号化手段を備え、前記配布手段は、暗号化された鍵を各クライアント端末に配布し、前記暗号処理手段は、前記初期鍵を用いて配布された鍵を復号し、前記鍵設定手段は、復号された鍵を前記第１の鍵として設定することを特徴とする。
【００１７】
この構成によれば、配布すべき鍵を初期鍵を用いて暗号化するため、配布先のクライアント端末にて初期鍵を用いて確実に復号することができる。つまり、初期鍵を用いて鍵を機密に配布しつつ、配布した鍵をクライアント端末で確実に復号できることを期待できる。
【００１８】
また、前記鍵配布サーバは、管理下にある複数のクライアント端末それぞれの識別子を含むクライアント端末管理テーブルを記憶するテーブル記憶手段を備え、前記配布手段は、クライアント端末管理テーブルに登録された複数のクライアント端末宛に配布を行い、前記複数のクライアント端末ぞれぞれは、さらに、自己に関する情報を含み鍵配布サーバの管理下への参入要求を送出する参入要求送出手段とを備え、前記鍵配布サーバは、前記参入要求を受け取った場合に、参入要求の送出元クライアント端末に関する情報を表示し、参入可否の選択を受け付けるユーザインターフェイス手段と、参入可を受け付けた場合には、前記送出元クライアント端末の識別子を前記クライアント端末管理テーブルに登録し、参入否の項目を受け付けた場合には、登録を行わないテーブル管理手段とを備えることを特徴とする。
【００１９】
この構成によれば、鍵配布サーバのユーザインターフェイス手段において参入可否の選択を受け付けるため、例えば、このユーザインターフェイスで、クライアント端末の台数や動作状況を把握したユーザに選択させることで、なりすまし端末からの不正な参入を防ぐことができる。
【００２０】
また、前記鍵配布サーバは、前記配布を所与のスケジュールに従って繰り返し実行させるスケジュール手段と、管理下にある複数のクライアント端末それぞれの識別子を含むクライアント端末管理テーブルを記憶するテーブル記憶と、クライアント端末から受け取った鍵配布サーバの管理下への参入要求を、前記所与のスケジュールにおいて前回配布した鍵を用いて認証のために復号し、復号に失敗した場合には、さらに前に配布した鍵を用いて復号し、正しく復号できた場合には参入を許可する許可手段と、参入を許可した場合には、前記送出元クライアント端末の識別子を前記クライアント端末管理テーブルに登録するテーブル管理手段とを備えることを特徴とする。
【００２１】
この構成によれば、鍵配布サーバにおいてクライアント端末を受け取ったデータを、上記前に配布した共通鍵を用いて復号するため、例えば、前回配布した鍵を持っておらず前々回に配布された鍵を持つクライアント端末、すなわち前回の鍵更新ができなかったクライアント端末を救済して暗号通信を行うことができる。
【００２２】
また、前記鍵配布サーバは、前記配布を所与のスケジュールに従って繰り返し実行させるスケジュール手段とを備え、当該スケジュール手段は、前記配布した全てのクライアント端末からの応答が受信されるまでは、前記所与のスケジュールにおける次回の配布の実行を禁止することを特徴とする。
【００２３】
この構成によれば、上記所与のスケジュールにおける次回の配布の実行を禁止することで、鍵更新を行えなかったクライアント端末を置き去りにすることを防止できる。また、更なる鍵更新を強行してクライアント端末間で使用する鍵が錯綜するような事態を回避できる。
【００２４】
また、前記鍵配布サーバは、前記鍵配布サーバは、さらに、複数のクライアント端末それぞれの生存／非生存の別を示す生存状況を監視する監視手段と、管理下にある複数のクライアント端末それぞれの識別子と、それぞれの生存状況とを対応付けたクライアント端末管理テーブルを記憶するテーブル記憶手段を備え、前記配布手段は、クライアント端末管理テーブルを参照して、複数のクライアント端末のうちで、生存しているクライアント端末に配布を行い、非生存のクライアント端末には配布を行わないことを特徴とする。
【００２５】
この構成によれば、例えば、非生存状態のクライアント端末には鍵配布を行なわないとすることで、通信リソースの無駄使いを抑止できる。
【００２６】
また、前記鍵設定手段は、前記受信手段による鍵の受信から所定時間経過した場合に、受信した鍵を前記第１の鍵として設定することを特徴とする。
【００２７】
この構成によれば、例えば、鍵配布サーバがダウンした場合であっても各クライアント端末は配布された鍵へと更新することが可能となる。特に、鍵配布サーバが更新指示を通知している途中でダウンしたような場合、更新指示を未だ受けていないクライアント端末も鍵更新が可能となり有用である。
【００２８】
また、前記複数のクライアント端末は、扉開閉に係る情報を読み取る認証端末と、前記扉開閉に係る情報に基づいて扉開閉制御を行う管理装置とを含み、前記認証端末と前記管理装置との間で、前記配布手段により配布された鍵を用いて、前記扉開閉に係る情報の暗号通信を行うことを特徴とする。
【発明を実施するための最良の形態】
【００２９】
（実施の形態１）
＜構成＞
図１は、実施の形態１に係る暗号通信システムの構成を示す図である。
【００３０】
図１に示すように、暗号通信システム１は、鍵配布サーバ１００と、８台のカード認証端末４ａ〜４ｈと、当該カード認証端末４ａ〜４ｈを２台ずつ管理する４台の入退室管理装置２ａ〜２ｄを含む。
【００３１】
ここで、図１におけるカード認証端末４ａ〜４ｈ、入退室管理装置２ａ〜２ｄ、扉６ａ〜６ｈは入退室管理システムを構成する。入退室管理システムは、オフィスへの人の入退室を制限することで物理的なセキュリティを確保するシステムである。
【００３２】
扉６ａ〜６ｈは、オフィスの出入り口の扉である。扉６ａ〜６ｈの電気錠は平常時にロックされており、解錠信号を受けた場合には一時的にロックが解除される仕組みである。
【００３３】
カード認証端末（カード読取端末）４ａ〜４ｈは、それぞれ扉６ａ〜６ｈの側に設置されており、ユーザ９にかざされたカードを読み取る。そして、カードから読み取ったカードＩＤ情報を入退室管理装置２ａ〜２ｄに送信する。
【００３４】
入退室管理装置は、受信したカードＩＤ情報を、ＩＤ毎の入退室権限が記述されたカードＩＤ管理テーブルと照らし合わせて、入退室の権限の有無を判断する。権限が有れば、入退室管理装置２ａ〜２ｄは、カード認証端末４ａ〜４ｈに対応する扉６ａ〜６ｈの電気錠に解錠信号を送り、扉６ａ〜６ｈのロックを解除させる。権限が無ければ、入退室管理装置２ａ〜２ｄは、カード認証端末４ａ〜４ｈにエラー信号を送り、カード認証端末４ａ〜４ｈに音によるエラー通知を行わせる。
【００３５】
本実施の形態では、上記カードＩＤ情報のように、カード認証端末４ａ〜４ｈと入退室管理装置２ａ〜２ｄとの間で通信される情報を、鍵を用いて暗号化することで通信回線上を流れる情報の機密性を高めている。
【００３６】
そして課題を解決するための手段で述べたように、カード認証端末４ａ〜４ｈのＣＰＵやメモリのスペック上の制約や、鍵の管理負担を考慮して１２台の入退室管理装置２ａ〜２ｄ、カード認証端末４ａ〜４ｈにおいて同じ鍵を用いた暗号通信を行うようにしている。
【００３７】
なお、以下では、鍵配布サーバから鍵の配布を受ける入退室管理装置２ａ〜２ｄ及びカード認証端末４ａ〜４ｈをまとめてクライアント端末と呼ぶことがある。
【００３８】
図２は、鍵配布サーバの機能ブロック図である。
【００３９】
鍵配布サーバ１００は、ユーザインターフェイス部１１０、制御部１２０、及び記憶部１４０を備える。
【００４０】
ユーザインターフェイス部１１０は、表示部１１２と操作部１１４とを備える。
【００４１】
表示部１１２は、例えば液晶ディスプレイから構成されており、制御部１２０からの表示制御信号に応じて入退室管理システムの管理ユーザに対して各種表示を行う。
【００４２】
操作部１１４は、例えば、キーボードとマウスから構成されており、上記管理ユーザからメニュー項目の選択やコマンド入力などの各種入力を受け付け、入力内容を示す制御信号を制御部１２０に送る。
【００４３】
制御部１２０は、ＲＯＭに格納された制御プログラムと当該制御プログラムを実行するＣＰＵから構成されており、暗号処理部１２２、鍵生成部１２８、鍵配布部１３０、鍵管理部１３２、スケジューラ１３４、生存状態監視部１３６、送受信部１３８を備える。
【００４４】
暗号処理部１２２は、平文を暗号文に変換する暗号化部１２４、暗号文を平文に変換する復号部１２６を備える。
【００４５】
鍵生成部１２８は、128ビット長の鍵を生成する。上記暗号化、復号、鍵生成は、公知の規格（例えば、AES（Advanced Encryption Standard））に従って実施される。
【００４６】
鍵配布部１３０は、鍵生成部１２８によって生成された鍵を、クライアント端末に配布する。配布先のクライアント端末は、クライアント管理テーブル１４４に基づいて決定する。
【００４７】
鍵管理部１３２は、クライアント端末に対して、鍵更新指示を示す鍵更新通知を行う。また、記憶部１４０の鍵管理テーブル１４６を管理する。
【００４８】
スケジューラ１３４は、所与のスケジュールに基づいて、鍵生成部１２８、鍵配布１３０に実行指示を送ることにより鍵更新を実行させる。上記所与のスケジュールは、ユーザ設定によってカスタマイズされたスケジュール（例えば60分間隔）である。
【００４９】
生存状態監視部１３６は、クライアント端末宛に随時ポーリングを行うことで、各クライアント端末の生存状態を取得し、取得結果に基づいてクライアント管理テーブル１４４を更新する。
【００５０】
送受信部１３８は、データの送受信を行う。
【００５１】
記憶部１４０は、鍵記憶部１４２、クライアント管理テーブル１４４、鍵管理テーブル１４６を記憶する。
【００５２】
鍵記憶部１４２は、(1)予め初期状態から組み込まれた初期鍵、(2)鍵更新のたびに生成した鍵、を記憶している。本実施の形態では、上記初期鍵は、鍵配布サーバ１００及びクライアント端末それぞれに予め記憶されている。
【００５３】
クライアント管理テーブル１４４は、管理下にあるクライアント端末のＩＤ、アドレス、生存状態の項目を含むテーブルである（図３）。
【００５４】
鍵管理テーブル１４６は、鍵記憶部１４２が記憶する鍵のＩＤと、当該鍵のＩＤの使用優先順位と記述されたテーブルである（図４）。
【００５５】
図３は、クライアント管理テーブルを示す図である。
【００５６】
鍵配布サーバ１００の記憶部１４０が記憶するクライアント管理テーブル１４４は、テーブル項目として「クライアントＩＤ」１４４ａ、「ＩＰアドレス」１４４ｂ、「生存状態」１４４ｃの項目を含む。
【００５７】
「生存状態」１４４ｃは、生存状態監視部１３６による生存状態の監視結果を示す項目であり、生存（値１）か不在（値０）かの値を取る。図３上では、ＧＵ−１〜ＧＵ−４までの４台が生存状態となっている。
【００５８】
図４は、鍵管理テーブルを示す図である。（ａ）は鍵生成前、（ｂ）は鍵生成後、（ｃ）は鍵更新後の状態を示している。
【００５９】
鍵配布サーバ１００の記憶部４０が記憶する鍵管理テーブル１４６は、テーブル項目として「順位」１４６ａ、「鍵ＩＤ」１４６ｂ、「鍵アイコン」１４６ｃの項目を含んでいる。なお、「鍵アイコン」１４６ｃの項目は、説明のビジュアル化の便宜のため追加したものであり、必ずしも必要ではない。
【００６０】
「順位」１４６ａの項目は、鍵の使用優先順位であり、暗号化及び復号の際に用いる鍵ＩＤを順位付ける。順位が「ー」は、順位が付与されていないことを示している。
【００６１】
「鍵ＩＤ」１４６ｂの項目は、鍵を一意に特定する鍵ＩＤを示す項目である。図４（ａ）において、順位３位の鍵Ｋ１は、上述した初期鍵である。順位１位の鍵Ｋｎは、前回配信した鍵（順位１位の通常用いる鍵であるので「現行鍵」とも言える。）である。順位２位の鍵Ｋｎ-1は、前々回配信した鍵（前回の鍵更新まで通常使用していた鍵であるので「旧鍵」とも言える。）である。
【００６２】
図５は、入退室管理装置の機能ブロック図である。
【００６３】
入退室管理装置２ａ〜２ｄは同様な構成であるため、入退室管理装置２ａを代表させて説明する。また、図５では、図２で示した鍵配布サーバ１００の機能ブロックと同様な機能ブロックについては下２桁同じ符号を付し説明を省略する。
【００６４】
入退室管理装置２ａは、制御部２０と記憶部４０とを含む。
【００６５】
制御部２０は、暗号化部２４及び復号部２６から構成される暗号処理部２２、鍵管理部３２、入退室管理部５０、送受信部３８を備える。
【００６６】
記憶部４０は、初期鍵、前回配信された鍵、及び前々回配信された鍵を記憶する鍵記憶部４２、鍵管理テーブル４６、カードＩＤ管理テーブル４８を記憶している。
【００６７】
入退室管理部５０は、管理下にあるカード認証端末４ａ，４ｂから受信したカードＩＤ情報を、カードＩＤ管理テーブル４８と照らし合わせて、入退室の権限の有無を判断する。権限が有れば、対応する扉６ａ〜６ｂの電気錠に解錠信号を送りロックを解除させる。
【００６８】
図６は、鍵管理テーブルを示す図である。（ａ）は新しい鍵の受信前、（ｂ）は鍵受信後、（ｃ）は鍵更新設定後の状態を示している。
【００６９】
クライアント端末である入退室管理装置２ａの記憶部４０に記憶された管理テーブル４６は、テーブル項目として「順位」４６ａ、「鍵ＩＤ」４６ｂ、「鍵アイコン」４６ｃの項目を含んでいる。
【００７０】
図７は、カード認証端末の機能ブロック図である。
【００７１】
同様な構成をしたカード認証端末４ａ〜４ｄのうちでカード認証端末４ａだけを代表させて説明する。また、図６で示した入退室管理装置２ａと同様な機能ブロックには同じ符号を付する。
【００７２】
カード認証端末４ａは、制御部２０、記憶部４０、カード読取部５２、スピーカ５４を備えている。
【００７３】
制御部２０は、暗号化部２４及び復号部２６から構成される暗号処理部２２、鍵管理部３２、送受信部３８を備える。
【００７４】
記憶部４０は、例えばフラッシュＲＯＭから構成されており、初期鍵を記憶する鍵記憶部４２、鍵管理テーブル４６、カードＩＤ管理テーブル４８を記憶している。上述のように、カード認証端末４ａは特にスペック上の制約が強いため、他装置と比べてフラッシュＲＯＭへの各種データの保存に時間を要する傾向がある。また、容量の制約や安全性に配慮すると、鍵記憶部４２に記憶させる鍵の数は、少ない方が好ましい。
【００７５】
カード読取部５２は、ユーザによってかざされたカードＩＤを読み取る。読み取ったカードＩＤ情報は、送受信部３８によりカード認証端末４ａを管理する入退室管理装置２ａに送信される。
【００７６】
スピーカ５４は、制御部２０の音声制御信号を受けて所定回数のビープ音を発する。例えば、正常時には１回のビープ音、エラー時には２回のビープ音を発する。
＜生存状態監視＞
次に、図８、図９を参照して、鍵配布サーバ１００が行うクライアント端末の生存状態監視（生存確認）について説明する。
【００７７】
図８に示すように、生存状態監視部１３６は、ポーリング周期が到来すると（S11:Yes）、クライアント端末宛にポーリングを行う（S12）。ポーリング実行からタイムアウト時間内に生存通知の応答を受信できた場合には（S13:Yes）、クライアント管理テーブル１４４において対応するクライアント端末の生存状態の項目を更新しポーリング周期のタイマーをリセットする（S14）。タイムアウト時間内に生存通知の応答を受信できなかった場合には（S13:No）、生存状態の項目を非生存（不在）に更新する（S15）。
【００７８】
図９に、鍵配布サーバ１００が、２台のクライアント端末（ＩＤ：ＧＵ−１，ＧＵ−２）の生存状態を監視する際のデータのやり取りを示す。このように、生存状態監視部１３６は、クライアント端末毎に生存状態の監視を並行して実行する。
【００７９】
なお、図９に示すように、ＧＵ−１から鍵配布サーバへの通常の通信（例えば、カードＩＤ情報の送信）においても、生存状態監視部１３６は、ＧＵ−１の生存が確認できたと判断してタイマーをリセットしている。
＜鍵配布・鍵更新＞
次に、図１０〜図１２を参照して鍵の配布及び更新について説明する。図１０は、鍵配布サーバ側における鍵配布・鍵更新の処理を示すフローチャートである。
【００８０】
鍵配布サーバ側では、図１０に示すように、スケジューラ１３４は鍵の配布周期が到来すると(S21:Yes)、鍵管理部１３２はステップS22,23の判断を行う。
【００８１】
新しい鍵を全クライアント端末へ配布済みであり(S22:Yes)、全クライント端末へ新しい鍵への更新指示が済んでいれば（S23:Yes）、鍵管理部１３２は鍵生成部１２８に新しい鍵を生成させる（S24）。なお、新しい鍵は、暗号化部１２４により鍵管理テーブル１４６において順位１位の鍵により配布前に暗号化される。また、ステップS24における新しい鍵は、ステップS23における新しい鍵より１世代次の鍵となる。
【００８２】
新しい鍵を配布済でないならば(S22:No)、ステップS25〜S28の配布系処理に移行する。新しい鍵を配布済みで、更新指示が済んでいないならば(S22:Yes,S23:No),ステップS29〜S31の更新系処理に移行する。
【００８３】
ステップS24で新しい鍵を生成すると、スケジューラ１３４は、クライアント管理テーブル１４４を参照して、生存しているクライアント端末のうち、未配布の端末を配布対象に設定する（S23）。図３に示したクライアント管理テーブル１４４の例では、生存していて未配布であるGU-1〜GU-4の４台を配布対象に設定する。なお、図示しないがクライアント管理テーブル１４４には、クライアント端末毎に新しい鍵の既配布／未配布を示す情報、及び鍵の更新／未更新を示す情報が含まれている。
【００８４】
鍵配布部１３０は、設定された配布対象のクライアント端末に順々に鍵を配布する（S26）。配布する順番は、例えばクライアントＩＤの降順とする。
【００８５】
配布対象のクライアント端末に、（成功／失敗問わず）配布し終え(S27:Yes）、かつ全ての配布が成功していれば(S28:Yes)、ステップS29〜S31の更新系処理に移行する。なお、配布したクライアント端末において、１つでも配布に対する応答がないクライアント端末がある場合には、配布に失敗したものとして（S28:No）、処理を終える。なお、配布に失敗したクライアント端末に関しては、次回の配布周期において(S21)、新しい鍵を配布済みでないと判断される（S22:No）。このため、これらの端末には再度新しい鍵が配布されることとなる（S25,S26）。
【００８６】
このように、配布対象の全てのクライアント端末に新しい鍵が行き渡らない限りは、鍵の更新に移行させないため、通信障害などで新しい鍵を受信し損なったクライアント端末を、置き去りに鍵更新するような事態を防止できる。
【００８７】
ステップS29〜S31の更新系処理では、鍵管理部１３２は、クライアント管理テーブル１４４を参照して、生存しているクライアント端末のうち、更新指示を行えていない端末を更新指示対象に設定する(S29)。そして、鍵管理部１３２は、更新指示対象のクライアント端末に、順々に更新指示を通知する（S30）。更新指示対象のクライアント端末に、通知し終えると(S31)処理を終了する。
【００８８】
なお、ステップS31後に、鍵管理部１３２は、サーバ１００自身の鍵管理テーブル１４６において(1)順位１位の鍵を順位２位に後退させ、(2)配布した新しい鍵を順位１位に更新する。
【００８９】
図１１は、クライアント端末側における鍵配布・更新処理を示すフローチャートである。
【００９０】
クライアント端末側では、図９に示すように、送受信部３８が鍵配布サーバから受信したデータを、鍵管理テーブル４６の順位１位の鍵を用いて復号部２６で復号する。そして、鍵管理部３２が、復号されたデータが新しい鍵であると判断すると（S41:Yes）、この鍵管理部３２は受信した新しい鍵を鍵記憶部４２に保存する（S42）。保存を終えると、鍵管理部３２は鍵受信に対する応答を鍵配布サーバ１００宛に送信する（S43）。
【００９１】
イベントとして更新指示の通知を受けると（S44：「更新指示」）、鍵管理部３２は鍵管理テーブル４６において(1)順位２位の鍵を鍵記憶部４２から消去し、(2)順位１位の鍵を順位２位に後退させ、(3)受信した新しい鍵を順位１位に更新設定する（S45）。
【００９２】
なお、鍵配布サーバ１００が更新指示通知を行えずダウンする場合（図１０のステップS31の通知が行えない場合）なども考えられるため、ステップＳ４４においては、新しい鍵の受信から所定時間経過した場合（タイムアウト）にも、ステップＳ４５に移行させても構わない。
【００９３】
本実施の形態において鍵の配布を鍵の更新に先立って行うのは、上述のように置き去りとなるクライアント端末発生を防ぐためであるが、もうひとつの目的としてはクライアント端末間で鍵更新の足並みを揃えるためである。このことを図１２を用いて説明する。
【００９４】
図１２は、鍵配布サーバと３台のクライアント端末とにおけるデータの送受と処理とを時系列に沿って示す図である。
【００９５】
図１２に示すように、鍵配布においては鍵更新と比べて多大な時間を要する傾向にある（鍵配布期間Ａ＞鍵配布期間Ｂ）。時間差の原因としては、(1)鍵配布は鍵更新と比べて通信のデータ量が大きさ、(2)鍵配布においては、クライアント端末側で配布された鍵をフラッシュＲＯＭなどに保存するの時間、などが挙げられる。
【００９６】
時間差の具体例としては、例えば、クライアント端末が１００台の環境下では、鍵更新の期間はせいぜい数百ミリ秒であるのに対して、鍵配布の期間は数十秒もかかる場合がある。もっとも、クライアント端末のスペックや用いる通信回線に応じて時間差は異なる。
【００９７】
このように、鍵配布と鍵更新では所要時間に大差があるため、予め鍵を配布して更新を後回しすることで、クライアント端末間で鍵更新のタイミングのずれを極小にすることができる。すなわち、鍵更新のタイミングがずれたクライアント端末どうしで通信ができない時間帯が発生することを抑制することができる。
＜データ受信＞
さて、上述のようにクライアント端末間で鍵更新のタイミングずれを極小にできるといっても、特にクライアント端末の台数が多い場合などには既に更新を終えた端末と、未更新の端末との間で通信が発生する場合がある。係る両端末は、それぞれ順位１位の鍵が異なるため正常な通信ができないおそれがある。
【００９８】
そこで本実施の形態では、クライアント端末においては、順位２位の鍵（前々回配布された鍵）をもバックアップとして用いる。
【００９９】
図１３は、クライアント端末側におけるデータ受信処理を示すフローチャートである。
【０１００】
すなわち、データを受信した際には（S51:Yes）、鍵管理部３２は、鍵管理テーブル４６の順位１位の鍵で復号を試み（S52）、正しく復号できず失敗した場合には（S53：No）、順位２位の鍵で復号を試みる（S54）。なお、復号が正しくできたか否かは、公知の検証方法を用いて判断する。
【０１０１】
さらに鍵管理部３２は、順位２位の鍵での復号にも失敗した場合には（S55:No）、鍵配布サーバに鍵配布要求を送る（S56)。
【０１０２】
この構成によれば、鍵更新のタイミングずれの狭間において順位１位の鍵が異なるクライアント端末どうしであったとしても、既に鍵更新を終えた端末は、未だ鍵更新を終えていない端末からのデータ受信を正しく復号することが可能となる。
（実施の形態２）
実施の形態２では、クライアント端末が暗号通信システムに参入する際の処理について説明する。実施の形態１と同様な構成については、説明を省略する。
【０１０３】
図１４は、クライアント端末における起動処理を示すフローチャートである。
【０１０４】
クライアント端末の起動処理では、まず鍵管理部３２は、鍵管理テーブル３２を参照して順位１位の鍵で起動通知を暗号化部２４で暗号化させ、鍵配布サーバ１００に送信する（S61）。この起動通知には、自己のクライアントＩＤやＭＡＣアドレスなどの関する情報が含まれている。
【０１０５】
なお、クライアント端末が鍵更新を正常に行なっていれば、送信時点での順位１位の鍵は、前回鍵配布サーバが配信した新しい鍵となる。
【０１０６】
また、前々回まで鍵更新を正常に行い、前回だけ鍵更新が行えなかったクライアント端末であれば、順位１位の鍵は、前々回鍵配布サーバ１００が配信した鍵となる。
【０１０７】
また、クライアント端末が入退室管理システムに新規参入するものであれば、順位１位の鍵は初期鍵となる。
【０１０８】
鍵配布サーバ１００からイベントとして起動時処理指示を受信すると（S62:「起動時処理指示受信」）、起動時処理指示を実行する。この起動時処理とは、クライアント端末が入退室管理装置２ａの場合には、例えば(1)扉の施錠・解錠監視処理の開始、(2)内蔵時計の時間同期である。
【０１０９】
イベントとして新しい鍵を受信すると（S62:「新しい鍵の受信」）、鍵管理部３２は、ステップS45同様に鍵の更新を実行する（S64）。
【０１１０】
図１５は、鍵配布サーバにおける参入可否判定処理を示すフローチャートである。
【０１１１】
クライアント端末からデータを受信すると（S71:Yes）、鍵管理部１３２は、鍵管理テーブル１４６の順位１位の鍵で復号を試みる（S72）。鍵管理部３２は、正しく復号できたと判断すると（S73:Yes）、起動時処理指示をクライアント端末に返信する（S80）。
【０１１２】
鍵管理部３２は、順位１位の鍵での復号に失敗した場合には（S73:No）、順位２位の鍵（S74）もしくは順位３位の初期鍵で復号を試みる（S76）。いずれかの鍵で正しく復号できれば（S75:Yes or S77:Yes）、ステップＳ７５かステップＳ７７で正しく復号できた鍵を用いて前回配信した鍵を暗号化し、送信元クライアント端末に配布する。
【０１１３】
両方の鍵で正しく復号できない場合には（S75:No and S77:No）、メニュー処理（S79）に移行する。
【０１１４】
図１６は鍵配布サーバにおけるメニュー処理のフローチャートを示す図である。
【０１１５】
まず、制御部１２０は表示部１１２に参入可否メニュー１１６を表示させる（S91）。参入可否メニュー１１６は、「次の機器を参入させますか？」というメッセージと、送信元クライアントを示す情報としての（1）GU番号（2）IPアドレス（3）MACアドレス、また参入可否を受け付ける「ＯＫ」ボタン１１８、「ＮＯ」ボタン１１９を含む。
【０１１６】
なお、参入可否メニュー１１６に表示させる情報は、ユーザに可否選択の参考として表示させるものであるから、上述の(1)〜(3)に限らず機器を特定できる情報であれば構わない。
【０１１７】
制御部１２０は、操作部１１４から「ＯＫ」ボタンの押下を受け付けると（S92:許可）、クライアント端末をクライアント管理テーブルに登録し、順位１位の鍵を配信する（S93）。
【０１１８】
制御部１２０は、操作部１１４から「ＮＯ」ボタンの押下を受け付けると（S92:拒否）、クライアント端末をクライアント管理テーブルに登録せず処理を終了する（S94）。
【０１１９】
以上説明したように、本実施の形態によれば、鍵配布サーバ１００は、前回配布した鍵を持っておらず前々回に配布された鍵を持つクライアント端末に対して鍵を配布するため、当該クライアント端末を暗号通信に参加させることが可能となる。すなわち、一時的に暗号通信システムから離脱していたクライアント端末を円滑に復帰させることができる。
【０１２０】
また鍵配布サーバ１００は、初期鍵を持つクライアント端末に対しても鍵を配布するため、暗号通信への新規参入を適切に行うことができる。
【０１２１】
また、鍵配布サーバ１００側でクライアント端末から受信したデータを正しく復号できない場合には、参入可否メニュー１１６を表示して、鍵配布サーバ１００の管理者ユーザに判断させることができる。
（実施の形態３）
実施の形態１では、鍵配布サーバ１００は、配布する鍵を予め順位１位の鍵で暗号化するとして説明したが、本実施の形態３では、配布する鍵に限っては初期鍵で暗号化して配布する。上述のように、全クライアント端末は初期鍵を保持しているため、クライアント端末側では配布された鍵を、初期鍵を用いて確実に正しく復号することができ、鍵配布時のトラブルを回避することができる。
【０１２２】
図１７は、鍵配布サーバにおける鍵配布・鍵更新の処理を示すフローチャートである。図１７のフローチャートは図１０と略同様であり同一な処理については同じステップ番号を付して説明を簡単にする。
【０１２３】
まず、スケジューラ１３４は配布周期が到来すると（S21:Yes）、鍵生成部１２８に新しい鍵を生成させる。そして鍵管理部３２は、生成した新しい鍵を初期鍵で暗号化する（S102）。
【０１２４】
このように、配布すべき新しい鍵を、鍵管理テーブル１４６を無視した形で例外的に初期鍵で暗号化するため、新しい鍵を受信するクライアント端末において初期鍵を用いて確実に復号できる。この効果を図１８を用いて説明する。
【０１２５】
図１８は、実施の形態３に係るクライアント端末における鍵管理テーブルを示す図である。（ａ）は新しい鍵の受信前、（ｂ）は鍵受信後、（ｃ）は鍵更新設定後の状態を示している。
【０１２６】
クライアント端末の記憶部４０が記憶する鍵管理テーブル４７は、テーブル項目として「順位」４７ａ、「鍵ＩＤ」４７ｂ、「鍵アイコン」４７ｃの項目を含んでいる。鍵管理テーブル４７は、実施の形態１で説明した鍵管理テーブル４６（図６参照）と異なり、初期鍵が順位２位に設定されている。このため、順位１位の鍵で復号できなかったとしても、順位２位の初期鍵を用いることにより、鍵配布サーバから受信した新しい鍵を確実に復号することができる。
【０１２７】
なお、図１８のようにクライアント端末側で初期鍵を順位２位に設定しなくとも、例えば、鍵配布サーバから配布する新しい鍵に、復号する鍵を初期鍵と指定する情報を付加しておくことで、クライアント端末側で初期鍵を用いることができ、同様の効果を得ることができる。
＜補足＞
以上、本発明を実施の形態に基づいて説明したが、本発明は上記した実施の形態に限定されない。例えば、次のように実施することもできる。
（１）実施の形態１においては、図１２に示すように、鍵配布サーバ１００からクライアント端末への更新指示の通知に関して、クライアント端末からの応答を受けないとして説明したが、鍵配布時と同様に更新指示の通知に対する応答を待つ構成としても構わない。特に、更新指示の通知に対する応答が無ければ、非応答なクライアント端末が鍵更新を逸するのを防ぐために鍵更新を中止するとしても構わない。
【図面の簡単な説明】
【０１２８】
【図１】実施の形態１に係る暗号通信システムの構成を示す図である。
【図２】鍵配布サーバの機能ブロック図である。
【図３】クライアント管理テーブルを示す図である。
【図４】鍵管理テーブルを示す図である。
【図５】入退室管理装置の機能ブロック図である。
【図６】鍵管理テーブルを示す図である。
【図７】カード認証端末の機能ブロック図である。
【図８】鍵配布サーバにおける生存状態監視処理を示すフローチャートである。
【図９】鍵配布サーバと２台のクライアント端末とにおけるデータのやり取りを示す図である。
【図１０】鍵配布サーバにおける鍵配布・鍵更新処理を示すフローチャートである。
【図１１】クライアント端末における鍵受信・鍵更新処理を示すフローチャートである。
【図１２】鍵配布サーバと３台のクライアント端末とにおけるデータの送受と処理とを時系列に沿って示す図である。
【図１３】クライアント端末におけるデータ受信処理を示すフローチャートである。
【図１４】クライアント端末における起動処理を示すフローチャートである。
【図１５】鍵配布サーバにおける参入可否判定処理を示すフローチャートである。
【図１６】鍵配布サーバにおけるメニュー処理のフローチャートを示す図である。
【図１７】鍵配布サーバにおける鍵配布・鍵更新の処理を示すフローチャートである。
【図１８】実施の形態３に係るクライアント端末における鍵管理テーブルを示す図である。
【符号の説明】
【０１２９】
１  暗号通信システム
２ａ〜２ｄ  入退室管理装置
４ａ〜４ｈ  カード認証端末
２０  制御部
４０  記憶部
２２  暗号処理部
２４  暗号化部
２６  復号部
３２  鍵管理部
４０  記憶部
４２  鍵記憶部
４６  鍵管理テーブル
５０  入退室管理部
５２  カード読取部
１００  鍵配布サーバ
１１０  ユーザインターフェイス部
１１２  表示部
１１４  操作部
１１６  参入可否メニュー
１２０  制御部
１２２  暗号処理部
１２４  暗号化部
１２６  復号部
１２８  鍵生成部
１３０  鍵配布部
１３２  鍵管理部
１３４  スケジューラ
１４４  クライアント管理テーブル
１４６  鍵管理テーブル
【図１】
2009212850.tif 000003
【図２】
2009212850.tif 000004
【図３】
2009212850.tif 000005
【図４】
2009212850.tif 000006
【図５】
2009212850.tif 000007
【図６】
2009212850.tif 000008
【図７】
2009212850.tif 000009
【図８】
2009212850.tif 000010
【図９】
2009212850.tif 000011
【図１０】
2009212850.tif 000012
【図１１】
2009212850.tif 000013
【図１２】
2009212850.tif 000014
【図１３】
2009212850.tif 000015
【図１４】
2009212850.tif 000016
【図１５】
2009212850.tif 000017
【図１６】
2009212850.tif 000018
【図１７】
2009212850.tif 000019
【図１８】
2009212850.tif 000020