JP6223884B2 - 通信装置、通信方法およびプログラム - Google Patents

Description

本発明の実施形態は、通信装置、通信方法およびプログラムに関する。

複数のリンクによって相互に接続され、ネットワーク化された複数のノードから構成される暗号通信ネットワーク（鍵共有ネットワーク）が知られている。各ノードは、リンクによって接続された対向ノードとの間で乱数を生成して共有する機能と、その乱数を暗号鍵（以下、リンク鍵）として利用して、リンク上で暗号通信を行う機能とを備える。また、ノードのうちの幾つかは、リンクとは独立に乱数である暗号鍵（以下、アプリ鍵）を生成する機能と、別のノードに対し、生成したアプリ鍵をリンクを介して送信する機能とを備える。鍵共有ネットワークにおけるアプリケーションは、ノードから、アプリ鍵を取得し、これを暗号鍵として利用して、別のアプリケーションとの間で暗号通信を行う機能を備える。このときの暗号データ通信は、インターネット等の鍵共有ネットワークとは異なるネットワーク（アプリケーションネットワーク）によってなされてもよい。アプリケーションは、ノードと一体として実現されてもよい。アプリケーションをノードと独立した端末として構成し、アプリケーションとノードとの間でアプリ鍵を送受信するようにしてもよい。

ノードにおいて、リンクによって接続された対向ノードとの間で乱数（リンク鍵）を生成および共有する機能は、例えば、一般に量子暗号通信あるいは量子鍵配送（Quantum Key Distribution、ＱＫＤ）と呼ばれる技術により実現する。また、ノードにおいて、リンクとは独立に乱数（アプリ鍵）を生成し、生成した乱数を別のノードにリンクを介して送信する技術についても知られている。

Dianati, M., Alleaume, R., Gagnaire, M. and Shen, X. （2008）, Architecture and protocols of the future European quantum key distribution network. Security and Communication Networks, 1: 57-74. DOI: 10.1002/sec.13

しかしながら、従来技術では、暗号鍵を生成して共有するための処理遅延が生じうるという問題があった。例えばリンク鍵を用いてアプリ鍵を共有するように構成したとすると、単純にリンク鍵を用いる構成と比較すると処理遅延や処理負荷が大きくなる場合がある。

実施形態の通信装置は、第１管理部と第２管理部と第１通信部と判断部と制御部と第２通信部とを備える。第１管理部は、第１外部装置との間で第１暗号鍵を共有する。第２管理部は、第１外部装置との間および複数のリンクを介して接続される第２外部装置との間で第２暗号鍵を共有する。第１通信部は、第１暗号鍵を用いて暗号化した第２暗号鍵を第１外部装置に送信する。判断部は、アプリケーションに提供する第２暗号鍵を共有すべき装置が第１外部装置であるか否かを判断する。制御部は、アプリケーションに提供する第２暗号鍵を共有すべき装置が第１外部装置である場合、第１暗号鍵を変換した暗号鍵を第２暗号鍵として共有するように第２管理部を制御する。第２通信部は、第２暗号鍵をアプリケーションに送信する。

量子鍵配送による暗号鍵共有処理のシーケンス図。 量子鍵配送システムの構成例を示す図。 暗号鍵共有処理のシーケンス図。 暗号鍵共有処理のシーケンス図。 本実施形態におけるノードの機能ブロック図。 本実施形態における暗号鍵共有処理のシーケンス図。 本実施形態における暗号鍵共有処理のシーケンス図。 本実施形態にかかる通信装置のハードウェア構成図。

以下に添付図面を参照して、この発明にかかる通信装置の好適な実施形態を詳細に説明する。

量子鍵配送技術は、光ファイバーで接続された、単一光子を連続的に送信する送信ノードと、これを受信する受信ノードと、の間で、安全に暗号鍵を共有する手法である。ここで共有される暗号鍵は、量子力学の原理に基づいて、盗聴されていないことが保証されている。共有された暗号鍵を用いて、ワンタイムパッドと呼ばれる暗号通信方式を利用して暗号データ通信を行うと、このときのデータは、如何なる知識を有する盗聴者によっても解読できないことが情報理論によって保証されている。

図１は、量子鍵配送による暗号鍵共有処理の一例を示すシーケンス図である。量子鍵配送を実現する通信システム（量子鍵配送システム）は、ノード１０ａ、１０ｂと、アプリケーション２０ａ、２０ｂと、を含む。ノード１０ａ、１０ｂは、送信ノードおよび受信ノードの少なくとも一方に対応する。以下では、送信ノードおよび受信ノードを、ノードと総称する場合がある。アプリケーション２０ａ、２０ｂは、共有された暗号鍵を用いて暗号データ通信する機能である。上述のように、アプリケーション２０ａ、２０ｂは、それぞれノード１０ａ、１０ｂと一体として実現されてもよい。

ノード１０ａ、１０ｂは、リンク鍵の共有を開始する（ステップＳ１０１）。ノード１０ａは、共有したリンク鍵をアプリケーション２０ａに提供する（ステップＳ１０２）。同様に、ノード１０ｂは、共有したリンク鍵をアプリケーション２０ｂに提供する（ステップＳ１０３）。

このように、ノード１０ａ、１０ｂ間で共有された暗号鍵（リンク鍵）は、それぞれアプリケーション２０ａとアプリケーション２０ｂに提供される。アプリケーション２０ａおよびアプリケーション２０ｂは、この後、取得した暗号鍵を用いてデータを暗号化し、暗号データ通信を行う。ただし、ＱＫＤ技術で暗号鍵を共有する方式は、単一光子をメディアとして利用することに起因する、暗号鍵共有可能な距離の制約がある。

次に、本実施形態の鍵共有ネットワーク（ＱＫＤネットワーク）について説明する。図２は、鍵共有ネットワークを含む量子鍵配送システムの構成例を示す図である。なお、図２は、ノードとアプリケーションとが独立に実現される場合の一例である。量子鍵配送システムは、通信装置としてのノード１００ａ〜１００ｅと、アプリケーション２００ａ、２００ｂと、を含む。ノード１００ａ〜１００ｅは、鍵共有ネットワーク３０１によりリンク鍵を共有する。

ノード１００ａ〜１００ｅを区別する必要がない場合は、単にノード１００という場合がある。アプリケーション２００ａ、２００ｂを区別する必要がない場合は、単にアプリケーション２００という場合がある。ノード１００の個数は５に限られるものではない。また、アプリケーション２００の個数は２に限られるものではない。

鍵共有ネットワーク３０１は、複数のノード１００間が、それぞれ光ファイバーなどによるリンク（リンク４０１〜４０６）によって接続されるネットワークである。

なお、図２では、１つのノード１００が、送信ノードまたは受信ノードの機能を複数備えるような構成を例示している（例えば、ノード１００ａ、１００ｃ、１００ｄは２つ、ノード１００ｂ、１００ｅは３つ）。各ノード１００が、送信ノードおよび受信ノードを一体化した機能を備えるように構成してもよい。以下では主に後者の構成を例に説明する。

各ノード１００は、リンクによって接続されるノード１００（隣接ノード）との間でＱＫＤによって暗号鍵を共有する。リンクによって接続されるノード１００間でＱＫＤにより共有される暗号鍵がリンク鍵（第１暗号鍵）に相当する。さらにノード１００は、ＱＫＤとは無関係に、別途乱数情報等から、別の暗号鍵（アプリ鍵(第２暗号鍵)）を生成し、暗号鍵をリンク鍵で暗号化して隣接ノードに転送する機能を有する。

リンク鍵によってアプリ鍵を暗号化してアプリ鍵を転送する処理を繰り返すことによって、ノード１００は、鍵共有ネットワーク３０１上の任意のノード１００との間でアプリ鍵を共有することができる。このときアプリ鍵は、ＱＫＤによって共有されるリンク鍵によって暗号化された状態でリンク上を転送される。従って、ノード１００自体の安全性を仮定すると、アプリ鍵の安全性は、リンク鍵と同様に保証されると言える。

以下、アプリケーション２００が、鍵共有ネットワーク３０１を利用して暗号鍵を取得および共有し、暗号データ通信を行うシーケンスの例を説明する。図３は、３つのノード１００を介してアプリ鍵を共有する場合の暗号鍵共有処理の一例を示すシーケンス図である。

ノード１００ａ、１００ｂ、１００ｃは、事前にリンク鍵を共有している（ステップＳ２０１、ステップＳ２０２）。なお、リンク鍵の共有動作はこの後も繰り返されてよい。暗号通信を行いたいアプリケーション２００は、鍵共有ネットワーク３０１上のノード１００に接続する。例えば図２の例では、アプリケーション２００ａはノード１００ａに接続し、アプリケーション２００ｂはノード１００ｃに接続している。

アプリケーション２００ａは、ノード１００ａに対して、アプリケーション２００ｂと通信するために暗号鍵が利用したい旨を通知する（ステップＳ２０３）。この通知を受けたノード１００ａは、アプリケーション２００ａが通信したいアプリケーション２００ｂが接続しているノード１００ｃを特定し（ステップＳ２０４）、ノード１００ｃとの間でアプリ鍵を共有する。

具体的には、ノード１００ａは、アプリ鍵の共有制御を開始すると（ステップＳ２０５）、共有するアプリ鍵を生成する（ステップＳ２０６）。ノード１００ａは、リンク鍵（ノード１００ｂと共有するリンク鍵）を用いてアプリ鍵を暗号化し（ステップＳ２０７）、ノード１００ｂに送信する（ステップＳ２０８）。ノード１００ｂは、受信したアプリ鍵をリンク鍵（ノード１００ａと共有するリンク鍵）で復号化し、復号化したアプリ鍵をリンク鍵（ノード１００ｃと共有するリンク鍵）で暗号化する（ステップＳ２０９）。ノード１００ｂは、暗号化したアプリ鍵をノード１００ｃに送信する（ステップＳ２１０）。ノード１００ｃは、受信したアプリ鍵をリンク鍵（ノード１００ｂと共有するリンク鍵）で復号化し（ステップＳ２１１）、記憶部等に記憶する（ステップＳ２１２）。ノード１００ｃは、アプリ鍵の記憶が完了したことをノード１００ａに通知する（ステップＳ２１３）。

ノード１００ａは、共有したアプリ鍵をアプリケーション２００ａへ提供し（ステップＳ２１４）、ノード１００ｃは、アプリケーション２００ｂからの要求を受け（ステップＳ２１５）、共有したアプリ鍵をアプリケーション２００ｂへ提供する（ステップＳ２１６）。これによって、アプリケーション２００ａとアプリケーション２００ｂは、同一の暗号鍵（アプリ鍵）を共有することができる。この後、アプリケーション２００ａとアプリケーション２００ｂは、暗号データ通信ネットワーク３０２を介して安全な暗号データ通信を行うことができる。

以上のような、アプリ鍵とリンク鍵を組み合わせた暗号鍵共有方式は、ＱＫＤを使うことに起因する暗号鍵共有可能な距離の制約を克服できる。また、アプリケーション２００から接続されたノード１００が暗号鍵（アプリ鍵）の生成、共有、および、ルーティングを制御する本方式は、既存のネットワーク技術を活用してシンプルな構成要素によって実現することが可能である。ここでは、ノード１００ａが乱数等によって暗号鍵（アプリ鍵）を生成してこれを共有するシナリオを説明した。共有する情報はこれに限られるものではない。本方式は、ノード１００ａが、他のシステムで生成した暗号鍵、デジタル証明書、および、公開鍵方式における秘密鍵など、任意の秘密情報を共有する仕組みとして利用できる。

図４は、２つのノード１００を介してアプリ鍵を共有する場合の暗号鍵共有処理の一例を示すシーケンス図である。図３とは、中継するノード１００（図３のノード１００ｂ）が存在しない点が異なるのみである。例えば、ステップＳ３０１はステップＳ２０１に対応する。ステップＳ３０２からステップＳ３０７はステップＳ２０３からステップＳ２０８に対応する。ステップＳ３０８からステップＳ３１３はステップＳ２１１からステップＳ２１６に対応する。

図３および図４に示すように、アプリ鍵とリンク鍵を組み合わせた暗号鍵共有方式は、例えば図１に示すような通常のＱＫＤによる暗号鍵共有と比較すると、乱数生成、リンク鍵によるアプリ鍵の暗号化、および、リンク鍵による復号化等の手順の分、処理遅延および処理負荷が大きくなる。このように、アプリ鍵とリンク鍵を組み合わせた暗号鍵共有方式は、距離制約なく任意のノードとの間で暗号鍵（アプリ鍵）を共有できる機能を提供できるが、暗号鍵共有の処理遅延が大きくなる。一方、図１のような方式を用いる場合は、暗号鍵共有の処理遅延が小さいが、暗号鍵共有できる距離（ノード接続形態）に制約がある。すなわち、暗号鍵を共有可能な距離の制約と、共有処理の処理負荷（処理遅延）との間にはトレードオフの関係がある。

そこで、本実施形態にかかるノード１００は、可能な場合は、図１のような方式によって単純に共有した暗号鍵（リンク鍵）をアプリケーション２００に提供することで、暗号鍵共有に要する処理遅延を短くする。一方、それ以外の場合は、アプリ鍵とリンク鍵を組み合わせた暗号鍵共有方式によって、暗号鍵（アプリ鍵）を共有し、これをアプリケーション２００に提供する。これにより、上記のようなトレードオフを解消することが可能となる。また、シンプルな実装を維持しながら、ネットワーク上の任意のノードとの間で暗号鍵を共有することができる。

図５は、本実施形態におけるノード１００の機能構成例を示すブロック図である。ノード１００は、プラットフォーム部１４０と、第１共有処理部１１０と、第２共有処理部１２０と、を備える。

プラットフォーム部１４０は、ノード１００における基本的なネットワーク機能（ルーティング機能を含む）、セキュリティ機能、および、データ保持機能等の、コンピュータのオペレーティングシステムに相当する基本機能を提供する。

第１共有処理部１１０は、アプリ鍵の共有に関する処理を行う。第１共有処理部１１０は、アプリ鍵ＤＢ１３１と、アプリ鍵管理部１１１（第２管理部）と、アプリ鍵共有部１１２と、アプリ通信Ｉ／Ｆ（インタフェース）部１１３（第２通信部）と、制御部１１４と、判断部１１５と、を含む。

第２共有処理部１２０は、リンク鍵の共有に関する処理を行う。第２共有処理部１２０は、リンク鍵ＤＢ１３２と、リンク鍵管理部１２１（第１管理部）と、リンク鍵共有部１２２と、古典通信Ｉ／Ｆ部（第１通信部）１２３と、量子通信Ｉ／Ｆ部１２４と、を含む。

リンク鍵管理部１２１は、ノード１００における、リンク鍵の共有、記憶、および利用を管理する。

リンク鍵共有部１２２は、ＱＫＤの技術を用いて、光ファイバーで接続される隣接ノードとの間で、リンク鍵を生成および共有する機能を備える。そのためリンク鍵共有部１２２は、光学部品等からなるＱＫＤ装置を備えている。

リンク鍵ＤＢ１３２は、リンク鍵共有部１２２によって共有されたリンク鍵を記憶する。

光ファイバーによる隣接ノードとの接続は、古典通信Ｉ／Ｆ部１２３と量子通信Ｉ／Ｆ部１２４によって実現される。量子通信Ｉ／Ｆ部１２４は、リンク鍵共有部１２２が単一光子の送信または受信を行うために用いられる。古典通信Ｉ／Ｆ部１２３は、リンク鍵を共有するために、リンク鍵共有部１２２が、隣接ノードとの間で実行すべき制御データの通信等に用いられる。

なお、量子通信Ｉ／Ｆ部１２４と古典通信Ｉ／Ｆ部１２３は、同一かつ単一の光ファイバーを利用する通信路であってもよいし、異なる光ファイバーを利用する通信路であってもよい。ただし、接続するノード１００は、量子通信Ｉ／Ｆ部１２４および古典通信Ｉ／Ｆ部１２３で同一である。

第２共有処理部１２０は、隣接ノードごとに存在してもよい。図２の例では、ノード１００ａは、ノード１００ｂおよびノード１００ｄとの間でリンクを構成しているため、第２共有処理部１２０が２セット存在する。ノード１００ｂは、ノード１００ａ、１００ｃおよびノード１００ｅとの間でリンクを構成しているため、第２共有処理部１２０が３セット存在する。ただし、リンク鍵ＤＢ１３２は、異なるリンクであっても同一のデータベースシステムを利用していてもよい。

なお、古典通信Ｉ／Ｆ部１２３は、第２共有処理部１２０の外側（例えば第１共有処理部１１０内の各機能部）からも利用される。第２共有処理部１２０外の機能部が、隣接ノードに対して制御データやアプリ鍵を送信すべく、リンクを介してデータ転送する場合、この機能部から、リンク鍵管理部１２１にデータが通知される。リンク鍵管理部１２１は、リンク鍵ＤＢ１３２からリンク鍵を取得し、データを取得したリンク鍵によって暗号化する。暗号化されたデータが、古典通信Ｉ／Ｆ部１２３を介して隣接ノードへと転送される。

また、古典通信Ｉ／Ｆ部１２３を介して受信した暗号データも、第２共有処理部１２０外の機能部宛てのデータである場合、リンク鍵管理部１２１によって復号化される。例えば、リンク鍵管理部１２１は、リンク鍵ＤＢ１３２からリンク鍵を取得し、取得したリンク鍵を用いて受信された暗号データを復号化し、復号化したデータを宛先となる機能部へと受け渡す。

次に、第１共有処理部１１０の各機能部について説明する。

アプリ鍵ＤＢ１３１は、アプリ鍵共有部１１２によって共有されたリンク鍵を記憶する。

アプリ鍵管理部１１１は、ノード１００における、アプリ鍵の共有、記憶、および利用を管理する。アプリ鍵共有部１１２は、鍵共有ネットワーク３０１を介してノード１００間でアプリ鍵を共有するための機能部である。アプリ鍵共有部１１２は、乱数からアプリ鍵を生成する機能、生成したアプリ鍵をネットワークを介して送信する機能、他のノード１００が生成したアプリ鍵をネットワークを介して受信する機能、および、これらの制御を行う上で必要な制御データを他のノード１００との間で交換する機能、を備える。

ここで、共有されるアプリ鍵は、上述の仕組みを用いて、リンク上では暗号化されて転送される。同様に、交換される制御データは、上述の仕組みを用いて、リンク上で暗号化されて転送されてもよい。共有されたアプリ鍵は、アプリ鍵ＤＢ１３１に記憶される。

また、本実施形態では、アプリ鍵管理部１１１は、リンク鍵ＤＢ１３２から一部のリンク鍵を取得し、取得したリンク鍵をアプリ鍵に変換し、変換したアプリ鍵をアプリ鍵ＤＢ１３１に記憶する機能を有する。

判断部１１５は、アプリ鍵を共有するノード１００が、リンク鍵を共有しているノード１００であるか否かを判断する。例えば判断部１１５は、あるノード１００の情報（ノードを識別する情報（ノードＩＤ）、アドレス等）が示された場合、このノード１００と単一リンクによって接続されているか、そうでなく、複数のリンクを介して接続されているか、を判断する。判断方法の詳細は後述する。

アプリ通信Ｉ／Ｆ部１１３は、暗号データ通信ネットワーク３０２に収容されているアプリケーション２００からの接続を受け付け、アプリケーション２００との間で制御データを交換する機能部である。

制御部１１４は、ノード１００全体の制御を行う。例えば、制御部１１４は、接続してきたアプリケーション２００から受信する制御データ、現在保有しているアプリ鍵量、および、リンク鍵量等を考慮して、アプリ鍵の生成および交換動作を制御（開始、変更、停止など）したり、アプリ鍵を交換すべきノード１００を特定したりする。

また制御部１１４は、アプリケーション２００からの要求を受けて、アプリ鍵を生成および共有を行う前に、判断部１１５によって、アプリ鍵を共有すべきノード１００との接続関係を判断させ、その判断結果に基づいて、アプリ鍵の共有方法を選択する機能を有する。

アプリ鍵の共有方法は、上述のように、以下の方法（Ａ１）および（Ａ２）を含む。
（Ａ１）アプリ鍵を乱数から生成し、アプリ鍵をリンク鍵で暗号化しながら複数リンクおよびノード１００を介して、転送、中継および交換する方法
（Ａ２）リンク鍵またはその一部を、アプリ鍵に転用する方法

なお、制御部１１４は、アプリ鍵の共有方法を選択し、選択した共有方法を実行するために必要な付加的な制御データの送受信、および、ノード１００の動作変更も行う。例えば制御部１１４は、アプリ鍵を交換すべきノード１００が隣接ノードであった場合に、どのリンク鍵の範囲をアプリ鍵として利用すべきかを決定し、決定した範囲を特定する特定情報を隣接ノードに通知するための制御データを送信するように古典通信Ｉ／Ｆ部１２３を制御する。

また制御部１１４は、同様の制御データを隣接ノードから受信した場合に、隣接ノードの要求に従って該当リンク鍵をアプリ鍵として利用可能か否かを判断する。利用可能であれば、制御部１１４は、アプリ鍵共有部１１２に指示してリンク鍵をアプリ鍵に変換する動作を行わせる。

制御部１１４は、アプリ鍵を要求したノード１００との接続関係以外のパラメータも考慮して、アプリ鍵の共有方法を決定してもよい。例えば制御部１１４は、アプリ鍵を要求したノード１００が隣接ノードであると判断部１１５によって判断された場合であっても、現在蓄積しているリンク鍵の量（リンク鍵の残量）がある一定の閾値（第１閾値）未満であった場合には、リンク鍵をアプリ鍵に転用する方式（上記（Ａ２））を採用しない判断を行ってもよい。すなわち、リンク鍵の残量が一定の閾値以上であった場合にのみ、リンク鍵をアプリ鍵に転用する方式（上記（Ａ２））を採用する判断を行ってもよい。

ノード１００上で動作するアプリケーション２００が利用するアプリ鍵をネットワーク上の他のノード１００と共有するための処理でリンク鍵を利用することも重要である。このため、リンク鍵をアプリ鍵に転用する方式を採用しない判断を行ってもよい。

ここで、リンク鍵を、あるアプリケーション２００（アプリεとする）が利用するアプリ鍵として転用すべきか、または、別のアプリケーション２００（アプリζとする）が利用するアプリ鍵をネットワーク上のノード１００と共有するためのリンク鍵として消費すべきか、という判断を行う必要が生じる。

この判断には様々な判断基準が適用できる。例えば、アプリ鍵を共有するための処理にリンク鍵が利用されている頻度が一定の閾値（第２閾値）より大きい場合には、リンク鍵をアプリ鍵に転用する方式（上記（Ａ２））を採用しない判断を行ってもよい。すなわち、リンク鍵の利用頻度が一定の閾値以下であった場合にのみ、リンク鍵をアプリ鍵に転用する方式（上記（Ａ２））を採用する判断を行ってもよい。また例えば、単純に該当ノード１００における、アプリεとアプリζの優先度によって判断してもよい。または、稼働しているアプリケーション２００によって公平に利用されるように、アプリεのためのアプリ鍵に転用するリンク鍵の量と、アプリζのためのアプリ鍵を転送するために利用するリンク鍵の量を同じにするように制御してもよい。

ただし、一般には、新規にアプリケーション２００が追加される可能性があり、その場合にリンク鍵をリンク鍵として利用してアプリ鍵を転送する必要が生じる。このため、すべてのリンク鍵を特定のアプリケーション２００のためにアプリ鍵に転用することは避けることが望ましい。

なお、アプリ鍵ＤＢ１３１において、アプリ鍵は、このアプリ鍵を共有する宛先のノード１００ごとに別々に管理される。また、アプリ鍵ＤＢ１３１とリンク鍵ＤＢ１３２（第２共有処理部１２０ごとに複数存在する）は、単一のデータベースシステムによって実現されていてもよいし、異なるデータベースシステムによって実現されていてもよい。ただし、アプリ鍵とリンク鍵は以下のように性質が異なる点に注意が必要である。
リンク鍵：ＱＫＤによってリンク接続されたノード１００間で共有され、ノード１００がリンクごとに記憶する。古典通信Ｉ／Ｆ部１２３を介した通信（アプリ鍵や制御データの交換）の暗号化のために利用（消費）される。
アプリ鍵：ノード１００の乱数生成によって生成され、鍵共有ネットワーク３０１を介して任意のノード１００との間で共有される。ノード１００が共有先のノード１００ごとに記憶する。さらに、各ノード１００において、接続しているアプリケーション２００の数や特性（優先度等）を考慮して、個別のアプリケーション２００へ事前に割当てられてもよい。アプリケーション２００からの要求を受け、アプリケーション２００に提供することで利用（消費）される。

なお、アプリ鍵管理部１１１、アプリ鍵共有部１１２、アプリ通信Ｉ／Ｆ（インタフェース）部１１３、制御部１１４、判断部１１５、リンク鍵管理部１２１、リンク鍵共有部１２２、古典通信Ｉ／Ｆ部１２３、および、量子通信Ｉ／Ｆ部１２４は、例えば、ＣＰＵ（Central Processing Unit）などの処理装置にプログラムを実行させること、すなわち、ソフトウェアにより実現してもよいし、ＩＣ（Integrated Circuit）などのハードウェアにより実現してもよいし、ソフトウェアおよびハードウェアを併用して実現してもよい。またリンク鍵共有部１２２の一部は、光学回路装置によって実現してもよい。

また、アプリ鍵ＤＢ１３１およびリンク鍵ＤＢ１３２は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

次に、このように構成された本実施形態にかかるノード１００による暗号鍵共有処理について図６を用いて説明する。図６は、本実施形態における暗号鍵共有処理の一例を示すシーケンス図である。

図６の例では、ノード１００ａにアプリケーション２００ａが接続され、ノード１００ｂにアプリケーション２００ｂが接続される。アプリケーション２００ａとアプリケーション２００ｂが暗号データ通信を行いたいものとする。また、ノード１００ａとノード１００ｂは、ＱＫＤによって暗号鍵（リンク鍵）を共有する動作を繰り返している（ステップＳ４０１）。

アプリケーション２００ａは、ノード１００ａへ接続し、ノード１００ａに対して、アプリケーション２００ｂと通信したい旨（暗号鍵の要求）を通知する（ステップＳ４０２）。なお、アプリケーション２００とノード１００との間の通信は、何らかのセキュリティによって保護されているものとする。例えば、物理的に外部者が侵入できないように保護する等、任意の方法を適用できる。

アプリケーション２００ａからの接続を受けたノード１００ａは、アプリケーション２００ａがアプリケーション２００ｂと通信するためにいずれのノード１００との間で暗号鍵（アプリ鍵）を共有すべきかを決定する（ステップＳ４０３）。

例えばノード１００ａは、ディレクトリサービス機能等を参照することによって、各ノード１００と、各アプリケーション２００との接続関係を把握し、暗号鍵を共有すべきノード１００を特定する。この例では、ノード１００ａは、暗号鍵（アプリ鍵）を共有すべきノード１００が、アプリケーション２００ｂが接続しているノード１００ｂであると特定する。

次にノード１００ａの判断部１１５は、暗号鍵を共有すべきノード１００ｂとの接続関係（接続形態）を確認する（ステップＳ４０４）。接続関係は、例えば以下の（Ｂ１）および（Ｂ２）を含む。
（Ｂ１）自ノードと他のノード１００（以下、該当ノードともいう）との間が単一リンクで接続されており、ＱＫＤにより暗号鍵（すなわちリンク鍵）が共有されている状態にある
（Ｂ２）複数のリンクを介したネットワークによって接続されている状態にある

接続関係を確認する方法には様々な方法が利用可能である。以下、列挙する。
（Ｃ１）ＱＫＤの設定情報を参照する
（Ｃ２）リンク鍵のデータベース（リンク鍵ＤＢ１３２）を参照する
（Ｃ３）リンク情報を収集するプロトコルを利用する、または、プロトコルの実行結果を参照する
（Ｃ４）外部データベース・ディレクトリを参照する

（Ｃ１）は、ＱＫＤの設定情報を参照する方法である。リンク接続されており、ＱＫＤがセットアップされているのであれば事前に管理者等によって、リンク接続されているノード１００の情報（ノードＩＤ、アドレス等）が自ノードに設定されているはずである。従って、判断部１１５は、ＱＫＤの設定情報を参照し、該当ノードのノードＩＤまたはアドレスがＱＫＤの設定情報に含まれていれば、該当ノードとの接続は単一リンクであることが判断できる。

（Ｃ２）は、ＱＫＤによって生成されるリンク鍵が蓄積されているリンク鍵ＤＢ１３２を参照する方法である。リンク鍵は、単一リンクによって接続され、ＱＫＤによって直接生成される暗号鍵である。リンク鍵ＤＢ１３２は、単一リンクによって接続されたノード１００との間で共有された暗号鍵（リンク鍵）のみを記憶する。該当ノードとの間で暗号鍵（リンク鍵）が共有されていれば、判断部１１５は、該当ノードとの接続関係は、単一リンクであると判断できる。

（Ｃ３）は、外部のプロトコルまたはネットワーク情報を参照するものである。例えば判断部１１５は、利用しているデータリンク層の仕組みを用いて、隣接関係にあるノード１００を特定することができる。また、判断部１１５は、隣接関係にあるノード１００を特定した結果を記憶しているデータベースを参照することにより、隣接関係にあるノード１００を特定することができる。

例えば判断部１１５は、ＣＤＰ（Cisco Discovery Protocol）を用いることにより、リンク接続している機器の情報を取得できる。判断部１１５は、ＣＤＰ（またはＣＤＰと類似のプロトコル）を実行することによって隣接ノードを特定できる。判断部１１５は、このようなプロトコルの実行またはその結果を記憶しているデータベースを参照することによって、該当ノードとの接続関係を判断できる。

（Ｃ４）は、外部のデータベース・ディレクトリを参照するものである。ノード１００の隣接関係に関する情報を収集している外部のデータベースやディレクトリサービスが存在する場合、判断部１１５は、このようなデータベースまたはサービスに該当ノードのノードＩＤまたはアドレスを問い合わせることで、接続関係の情報を取得することができる。

この例では、判断の結果、自ノード（ノード１００ａ）と該当ノード（ノード１００ｂ）の接続関係は、隣接であると判断できる（上記（Ｂ１））。

本実施形態では、ノード１００ａの制御部１１４は、ノード１００ｂに対してアプリ鍵を共有する際に、実際に乱数から暗号鍵（アプリ鍵）を生成してこれを転送するのではなく、既に共有しているであろう、リンク鍵を暗号鍵（アプリ鍵）として用い、このアプリ鍵を各アプリケーション２００に提供するように制御する。

さらに、ノード１００ａの制御部１１４は、該当ノード（ノード１００ｂ）との間で共有されている暗号鍵の量を元に、実際にリンク鍵を暗号鍵（アプリ鍵）として用いるようにするか、または、乱数から暗号鍵（アプリ鍵）を生成してこれを転送するように動作するか、を改めて決定してもよい。

さらに、ノード１００ａの制御部１１４は、現在該当リンク鍵を用いてアプリ鍵の転送を行っている可能性があるが、この場合、リンク鍵を用いたアプリ鍵の転送動作を優先し、リンク鍵をアプリ鍵として用いることを行わない判断を行ってもよい。

引き続き、本実施形態のシーケンスの説明を進める。ノード１００ａは、ノード１００ｂに対して、アプリ鍵共有制御データを送信する（ステップＳ４０５）。この制御データは、少なくとも、「リンク鍵をアプリ鍵として利用する」旨を示すデータを含む。制御データがさらに、アプリ鍵として利用すべきリンク鍵の識別情報（鍵ＩＤ、シーケンス番号等）、および、該当リンク鍵をアプリ鍵として利用する場合に実施すべき、何らかの変換処理を特定する情報を含んでもよい。変換処理としては、例えば、複数のリンク鍵を結合して１つのアプリ鍵とする処理、および、リンク鍵を分割して複数のアプリ鍵に変換する処理などがある。制御データが、ノード１００が暗号鍵をアプリ鍵として管理する上で必要な鍵ＩＤやシーケンス番号の値をどのような値にするかを示す情報、該当する暗号鍵を利用させるアプリケーション２００のペアを識別する識別情報、および、セッション情報を識別する情報を含んでもよい。

この後、ノード１００ｂは、ノード１００ａに対して、応答情報を通知してもよい。応答情報は、単純に、ノード１００ａから指示されたリンク鍵をアプリ鍵として扱うことに同意するか、またはそれが可能か否か、の情報のみでもよい。

応答情報がその他の情報を含んでもよい。例えば、ノード１００ａがアプリ鍵として利用するリンク鍵の鍵ＩＤを含めてアプリ鍵共有制御データを送信し、この制御データをノード１００ｂが受け取ったとする。可能性として、この時すでに、ノード１００ｂは、ノード１００ａから指定されたリンク鍵の一部を使用してしまっており、これをアプリ鍵として利用することができないことがある。この場合、ノード１００ｂは、単純に、このアプリ鍵共有制御データに対して、対応できない旨を通知してもよい（すなわち、negative ackの通知）し、アプリ鍵として利用できるリンク鍵の範囲を改めてノード１００ａに提示してもよい。

以上の手続きのもと、ノード１００ａおよびノード１００ｂは、同一の範囲のリンク鍵を、アプリ鍵として記憶するように変換する（ステップＳ４０６、ステップＳ４０７）。ここで、リンク鍵をアプリ鍵に変換する際に、必ずしもデータの変換処理や、データのコピーが発生するとは限らない。例えば、リンク鍵とアプリ鍵が同一のデータベースシステムにおいて管理されている場合も考えられる。この場合、データベース上のエントリの管理を変更するのみで、リンク鍵からアプリ鍵への変換が行えることがある。

リンク鍵のアプリ鍵への変換が実施できた場合、ノード１００ｂは変換結果をノード１００ａに通知してもよい（ステップＳ４０８）。同様にノード１００ａは、変換結果をノード１００ｂに通知してもよい。

以上の手順によって、ノード１００ａとノード１００ｂは、乱数（アプリ鍵）の生成、リンク鍵を用いた乱数（アプリ鍵）の暗号化、暗号化したアプリ鍵の転送処理、および、ノード１００ｂにおける復号処理、といった処理手順および処理負荷を回避しつつ、既に共有しているリンク鍵を用いて、アプリ鍵を共有することができる。端的には、図４の手順であったものが図６の手順としてより低処理負荷および少手順で実施できるようになる。

この後、共有されたアプリ鍵は、ノード１００ａからアプリケーション２００ａへ提供される（ステップＳ４０９）。また、ノード１００ｂからアプリケーション２００ｂへ、アプリケーション２００ｂの要求に応じてアプリ鍵が提供される（ステップＳ４１０、ステップＳ４１１）。

次に図７を用いて、本実施形態における、暗号鍵共有処理の別の例を示す。図７は、本実施形態における暗号鍵共有処理の別の例を示すシーケンス図である。図７の例では、ノード１００ａにアプリケーション２００ａが接続され、ノード１００ｃにアプリケーション２００ｂが接続される。アプリケーション２００ａとアプリケーション２００ｂが暗号データ通信を行いたいものとする。また、ノード１００ａとノード１００ｂの間、および、ノード１００ｂとノード１００ｃとの間では、ＱＫＤによって暗号鍵（リンク鍵）を共有する動作が繰り返される（ステップＳ５０１、ステップＳ５０２）。

アプリケーション２００ａは、ノード１００ａへ接続し、ノード１００ａに対して、アプリケーション２００ｂと通信したい旨（暗号鍵の要求）を通知する（ステップＳ５０３）。アプリケーション２００ａからの接続を受けたノード１００ａは、アプリケーション２００ａがアプリケーション２００ｂと通信するためにいずれのノード１００との間で暗号鍵（アプリ鍵）を共有すべきかを決定する（ステップＳ５０４）。この例では、ノード１００ａは暗号鍵（アプリ鍵）を共有すべきノード１００が、アプリケーション２００ｂが接続しているノード１００ｃであると特定する。

次にノード１００ａの判断部１１５は、暗号鍵を共有すべきノード１００ｃとの「接続関係」を確認する（ステップＳ５０５）。接続関係の特定方法は、既に示したとおりである。ここでは、自ノード（ノード１００ａ）と該当ノード（ノード１００ｃ）の接続関係は、ネットワークを介した接続関係（Ｂ１）である、すなわち隣接（Ｂ２）ではないと判断される。

ノード１００ａの制御部１１４は、ノード１００ｂに対して、アプリ鍵を共有する際に、リンク鍵を活用した上述の方法（Ａ２）が利用できないことを判断し、例えば、乱数から暗号鍵（アプリ鍵）を生成してこれを転送する方法（Ａ１）を採用することを決定する。すなわち、以下の手順を実行する。

ノード１００ａは、アプリ鍵の共有制御を開始する（ステップＳ５０６）。アプリ鍵共有部１１２は、乱数から暗号鍵（アプリ鍵）を生成する（ステップＳ５０７）。アプリ鍵共有部１１２は、別途ノード１００において動作しているルーティング機構によって生成されるルーティングテーブルを参照し、該当ノードであるノード１００ｃへアプリ鍵を転送する際のネクストホップに相当するノード１００がノード１００ｂであることを特定する。

アプリ鍵共有部１１２は、アプリ鍵を、ノード１００ｂとの間で共有しているリンク鍵を用いて暗号化し（ステップＳ５０８）、ノード１００ｂと接続されているリンク上に転送する（ステップＳ５０９）。

暗号化されたアプリ鍵を受信したノード１００ｂは、受信したリンクを共有しているノード１００ａとの間で共有しているリンク鍵を用いて、受信したアプリ鍵を復号化する（ステップＳ５１０）。さらにノード１００ｂは、該当アプリ鍵をノード１００ｃへ転送するために、復号化したアプリ鍵を送信すべきリンクを特定し、ネクストホップに相当するノード１００がノード１００ｃそのものであることを特定する。

ノード１００ｂは、復号化したアプリ鍵をノード１００ｃとの間で共有しているリンク鍵を用いて暗号化し（ステップＳ５１０）、ノード１００ｃと接続されているリンク上に転送する（ステップＳ５１１）。

暗号化されたアプリ鍵を受信したノード１００ｃは、受信したリンクを共有しているノード１００ｂとの間で共有しているリンク鍵を用いて、受信したアプリ鍵を復号化する（ステップＳ５１２）。ノード１００ｃは、復号化した暗号鍵を、ノード１００ａと共有するアプリ鍵として記憶する（ステップＳ５１３）。

以上の説明では、直接アプリ鍵を転送する手順を示したが、実際には、アプリ鍵を送信する前、送信した後、または、送信前後の両方、のタイミングで、アプリ鍵共有制御データとして、ノード１００ａが、送信するアプリ鍵のサイズ、アプリ鍵に付与すべき鍵ＩＤ（またはシーケンス番号）、および、アプリ鍵を提供するアプリケーション２００に関する情報、等の付加データをノード１００ｃに送信してもよい。

ノード１００ｃは、アプリ鍵共有制御データを受信した後、実際のアプリ鍵を受信するよりも前に、アプリ鍵共有制御データに対して、対応できない旨を通知（すなわちnegative ack）し、アプリ鍵の共有を拒否してもよい。または、ノード１００ｃは、アプリ鍵共有制御データを受信した後、実際のアプリ鍵を受信するよりも前に、アプリ鍵共有制御データに対して、アプリ鍵共有制御データに含まれる情報の少なくとも一部を修正したい旨を含む応答メッセージをノード１００ａに送信してもよい。

ノード１００ｃは、ノード１００ａからアプリ鍵を受信して記憶した後、ノード１００ａに対して、応答情報を通知してもよい（ステップＳ５１４）。応答情報は、単純に、ノード１００ａから送信されたアプリ鍵を受信したこと、を示す情報のみでもよい。

以上の手続きのもと、ノード１００ａおよびノード１００ｃは、同一のアプリ鍵をそれぞれ記憶する。この後、共有されたアプリ鍵は、ノード１００ａからアプリケーション２００ａへ提供される（ステップＳ５１５）。また、ノード１００ｃからアプリケーション２００ｂへ、アプリケーション２００ｂの要求に応じてアプリ鍵が提供される（ステップＳ５１６、ステップＳ５１７）。

このように、本実施形態にかかる通信装置では、暗号鍵共有に要する処理遅延を抑制することができる。

次に、本実施形態にかかる通信装置のハードウェア構成について図８を用いて説明する。図８は、本実施形態にかかる通信装置のハードウェア構成を示す説明図である。

本実施形態にかかる通信装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ（Random Access Memory）５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。さらに量子鍵配送を実現するための光回路装置５５をバス６１に接続していてもよい。

本実施形態にかかる通信装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。

本実施形態にかかる通信装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

さらに、本実施形態にかかる通信装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかる通信装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

本実施形態にかかる通信装置で実行されるプログラムは、コンピュータを上述した通信装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００ａ、１００ｂ、１００ｃ、１００ｄ、１００ｅ ノード
１１０ 第１共有処理部
１１１ アプリ鍵管理部
１１２ アプリ鍵共有部
１１３ アプリ通信Ｉ／Ｆ部
１１４ 制御部
１１５ 判断部
１２０ 第２共有処理部
１２１ リンク鍵管理部
１２２ リンク鍵共有部
１２３ 古典通信Ｉ／Ｆ部
１２４ 量子通信Ｉ／Ｆ部
１３１ アプリ鍵ＤＢ
１３２ リンク鍵ＤＢ
１４０ プラットフォーム部
２００ａ、２００ｂ アプリケーション
３０１ 鍵共有ネットワーク
３０２ 暗号データ通信ネットワーク

Claims (7)

1. リンクを介して接続される第１外部装置との間で第１暗号鍵を共有する第１管理部と、
   前記第１外部装置との間、および、複数のリンクを介して接続される第２外部装置との間で、アプリケーションに提供する第２暗号鍵を共有する第２管理部と、
   前記第１暗号鍵を用いて暗号化した前記第２暗号鍵を前記第１外部装置に送信する第１通信部と、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置であるか否かを判断する判断部と、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置である場合、前記第１暗号鍵を変換した暗号鍵を前記第２暗号鍵として共有するように前記第２管理部を制御する制御部と、
   前記第２暗号鍵を前記アプリケーションに提供する第２通信部と、を備え、
   前記制御部は、さらに、前記第１暗号鍵の残量が第１閾値以上であった場合、および、
   前記第１暗号鍵を前記第２暗号鍵の暗号化に利用する頻度が第２閾値以下であった場合、の少なくとも一方に、前記第１暗号鍵を変換するように前記第２管理部を制御する、
   通信装置。
2. 前記第１通信部は、さらに、変換した前記第１暗号鍵を特定する特定情報を前記第１外部装置に送信する、
   請求項１に記載の通信装置。
3. 前記判断部は、前記第１管理部が前記第１暗号鍵を共有する処理の設定情報を参照して、前記アプリケーションが暗号化通信を行う装置が前記第１外部装置であるか否かを判断する、
   請求項１に記載の通信装置。
4. 前記判断部は、ネットワーク情報を参照して、前記アプリケーションが暗号化通信を行う装置が前記第１外部装置であるか否かを判断する、
   請求項１に記載の通信装置。
5. 前記第１管理部は、量子鍵配送に基づき前記第１暗号鍵を共有する、
   請求項１に記載の通信装置。
6. リンクを介して接続される第１外部装置との間で第１暗号鍵を共有する第１管理ステップと、
   前記第１外部装置との間、および、複数のリンクを介して接続される第２外部装置との間で、アプリケーションに提供する第２暗号鍵を共有する第２管理ステップと、
   前記第１暗号鍵を用いて暗号化した前記第２暗号鍵を前記第１外部装置に送信する第１通信ステップと、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置であるか否かを判断する判断ステップと、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置である場合、前記第１暗号鍵を変換した暗号鍵を前記第２暗号鍵として共有するように前記第２管理ステップを制御する第１制御ステップと、
   前記第２暗号鍵を前記アプリケーションに送信する第２通信ステップと、
   前記第１暗号鍵の残量が第１閾値以上であった場合、および、前記第１暗号鍵を前記第２暗号鍵の暗号化に利用する頻度が第２閾値以下であった場合、の少なくとも一方に、前記第１暗号鍵を変換するように前記第２管理ステップを制御する第２制御ステップと、
   を含む通信方法。
7. コンピュータを、
   リンクを介して接続される第１外部装置との間で第１暗号鍵を共有する第１管理部と、
   前記第１外部装置との間、および、複数のリンクを介して接続される第２外部装置との間で、アプリケーションに提供する第２暗号鍵を共有する第２管理部と、
   前記第１暗号鍵を用いて暗号化した前記第２暗号鍵を前記第１外部装置に送信する第１通信部と、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置であるか否かを判断する判断部と、
   前記アプリケーションに提供する前記第２暗号鍵を共有すべき装置が前記第１外部装置である場合、前記第１暗号鍵を変換した暗号鍵を前記第２暗号鍵として共有するように前記第２管理部を制御する制御部と、
   前記第２暗号鍵を前記アプリケーションに提供する第２通信部、として機能させ、
   前記制御部は、さらに、前記第１暗号鍵の残量が第１閾値以上であった場合、および、
   前記第１暗号鍵を前記第２暗号鍵の暗号化に利用する頻度が第２閾値以下であった場合、の少なくとも一方に、前記第１暗号鍵を変換するように前記第２管理部を制御する、
   プログラム。

Images