JP2014022898A - 通信装置、通信方法および通信システム - Google Patents

通信装置、通信方法および通信システム Download PDF

Info

Publication number
JP2014022898A
JP2014022898A JP2012159044A JP2012159044A JP2014022898A JP 2014022898 A JP2014022898 A JP 2014022898A JP 2012159044 A JP2012159044 A JP 2012159044A JP 2012159044 A JP2012159044 A JP 2012159044A JP 2014022898 A JP2014022898 A JP 2014022898A
Authority
JP
Japan
Prior art keywords
key
node
application
resource information
communication
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
JP2012159044A
Other languages
English (en)
Other versions
JP5694247B2 (ja
Inventor
Yoshimichi Tanizawa
佳道 谷澤
Shinichi Baba
伸一 馬場
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2012159044A priority Critical patent/JP5694247B2/ja
Priority to CN201310064977.5A priority patent/CN103546276A/zh
Priority to US13/834,559 priority patent/US20140023192A1/en
Publication of JP2014022898A publication Critical patent/JP2014022898A/ja
Application granted granted Critical
Publication of JP5694247B2 publication Critical patent/JP5694247B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0827Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

【課題】通信装置(アプリケーション)が鍵生成装置(ノード)からアプリケーション鍵に関する情報(鍵生成量や鍵保有量など)を取得できるようにする。
【解決手段】アプリケーションは、暗号鍵を生成するノード100に接続される。ノード100は、取得部103と、算出部105と、送信部104と、を備える。取得部103は、鍵生成装置が提供可能な暗号鍵のリソースを表す鍵リソース情報を取得する。算出部105は、取得された鍵リソース情報に基づいて、暗号鍵を利用するアプリケーションに提供可能な暗号鍵の鍵リソース情報を算出する。送信部106aは、算出された鍵リソース情報をアプリケーションに送信する。
【選択図】図3

Description

本発明の実施形態は、通信装置、通信方法および通信システムに関する。
複数のリンクによって相互に接続され、ネットワーク化された複数のノードから構成される暗号通信ネットワークが知られている。各ノードは、リンクによって接続された対向ノードとの間で乱数を生成して共有する機能と、その乱数を暗号鍵(以下、リンク鍵)として利用して、リンク上で暗号通信を行う機能とを備える。また、ノードのうちの幾つかは、リンクとは独立に乱数を生成する機能と、別のノードに対し、生成した乱数を送信する機能とを備える。暗号通信ネットワークにおけるアプリケーションは、ノードから、乱数を取得し、これを暗号鍵(以下、アプリケーション鍵)として利用して、別のアプリケーションとの間で暗号通信を行う機能を備える。アプリケーションは、ノードと一体として実現されてもよいし、ノードと独立した端末として実現されてもよい。
ノードにおいて、リンクによって接続された対向ノードとの間で乱数(リンク鍵)を生成・共有する機能は、例えば、一般に量子暗号通信と呼ばれる技術により実現する。この場合、ノードにおいて、リンクとは独立に乱数(アプリケーション鍵)を生成し、生成した乱数を別のノードにリンクを介して送信する技術は、量子鍵配送(Quantum Key Distribution、QKD)と呼ばれることがある。
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
しかしながら、従来技術では、アプリケーションがノードから取得可能なアプリケーション鍵に関する情報を取得する手順が明らかになっていないため、例えばアプリケーションが取得可能なアプリケーション鍵に応じて適切な暗号アルゴリズムを決定することなどができなかった。
実施形態の通信装置は、暗号鍵を生成する鍵生成装置に接続される。通信装置は、取得部と、算出部と、送信部と、を備える。取得部は、鍵生成装置が提供可能な暗号鍵のリソースを表す鍵リソース情報を取得する。算出部は、取得された鍵リソース情報に基づいて、暗号鍵を利用するアプリケーションに提供可能な暗号鍵の鍵リソース情報を算出する。送信部は、算出された鍵リソース情報をアプリケーションに送信する。
本実施形態にかかる通信システムのネットワーク構成図。 本実施形態が想定するユースケースを示す図。 本実施形態のノードのブロック図。 本実施形態のアプリケーションのブロック図。 本実施形態における鍵リソース算出処理のフローチャート。 本実施形態の通信システムのネットワーク構成図。 本実施形態の通信システムのネットワーク構成図。 本実施形態にかかる装置のハードウェア構成図。
以下に添付図面を参照して、この発明にかかる通信装置の好適な実施形態を詳細に説明する。
通信装置(アプリケーション)は、種類によっては、通信(暗号通信)を開始する前に、どの程度のアプリケーション鍵が鍵生成装置(ノード)から取得可能かに関する情報を必要とする。例えば、継続的にデータ通信を継続する、ビデオまたは音声通信を実行するアプリケーションは、通信開始前に、継続して一定量以上のアプリケーション鍵がノードから取得できるか否かを問い合わせることで、利用できる帯域または暗号アルゴリズムを決定するかもしれない。また、例えば、一度に大きなファイルを転送するファイル転送アプリケーションは、通信開始前に、そのファイルを一度に転送するために十分なアプリケーション鍵を直ちに取得できるかを問い合わせるかもしれない。
すなわち、アプリケーションは、ノードから利用可能なアプリケーション鍵の鍵生成速度(スループット)、または、アプリケーション鍵の鍵保有量に関する情報を必要とすることがある。以下では、鍵生成速度および鍵保有量などの、ノードが提供可能なアプリケーション鍵のリソースを鍵リソース情報、または、単に鍵リソースという。鍵リソース情報は、鍵生成速度および鍵保有量に限られるものではない。また、複数の鍵リソース情報(例えば、鍵生成速度および鍵保有量)を重み付けて加算した値を鍵リソース情報として用いるように構成してもよい。
一方、ノードは、鍵生成速度および鍵保有量などの鍵リソースを応答するためには、自身が保持するアプリケーション鍵の情報だけでなく、他のノードが保持する鍵の情報、リンク鍵の情報、および、他のアプリケーションに関する情報等といった条件も考慮する必要がある。
そこで、本実施形態では、鍵リソースをアプリケーションに回答および割り当てるための、鍵リソースの算出、鍵リソースの管理、および、アプリケーションへの割り当ての方法を明らかにする。本実施形態の通信システムは、例えば以下のような構成を備える。
ノードは、鍵リソースを以下の手法にて算出、管理および割り当てることにより、アプリケーションからの鍵リソースの問い合わせに回答する。
(A1)鍵リソース情報の収集
(A2)他のアプリケーションの情報の収集
(A3)パス候補の算出
(A4)最適パス、および、アプリケーションへの回答の決定
図1は、本実施形態にかかる通信システムのネットワーク構成例を示す図である。通信システムは、鍵生成装置としてのノード100a〜100cと、通信装置としてのアプリケーション200a、200cと、を含む。
ノード100a〜100cを区別する必要がない場合は、単にノード100という場合がある。アプリケーション200a、200cを区別する必要がない場合は、単にアプリケーション200という場合がある。ノード100の個数は3に限られるものではない。また、アプリケーション200の個数は2に限られるものではない。
ノード100a〜100cは、上述のように、対向ノードとの間で乱数を生成して共有する機能と、生成した乱数をリンク鍵として利用して、リンク(リンク300a、300b)上で暗号通信を行う機能とを備える。ノード100は、リンクとは独立に乱数を生成する機能と、別のノードに対して生成した乱数を送信する機能とを備えてもよい。
図2は、本実施形態が想定するユースケースの一例を説明するための図である。以下、図2のユースケースについて説明する。
ノード100aに接続するアプリケーション200aが、ノード100cに接続するアプリケーション200cとの通信を開始するものとする。この際、以下の(1)〜(4)の処理が実行される。
(1)鍵リソース問い合わせ:アプリケーション200aは、ノード100aに対して、アプリケーション200cと通信する際に利用可能な鍵リソースについて問い合わせを行う。
(2)鍵リソース応答:ノード100aは、問い合わせに対して、アプリケーション200aが利用可能な鍵リソース情報を応答する。
(3)アプリケーション鍵取得:アプリケーション200aは、ノード100aに対してアプリケーション鍵を要求し、アプリケーション鍵をノード100aから取得する。
(4)暗号通信:アプリケーション200aは、ノード100aから取得したアプリケーション鍵を使って、アプリケーション200cとの間で暗号通信を行う。
図3は、ノード100の構成の一例を示すブロック図である。図3に示すように、ノード100は、第1通信部101と、リソース管理部102と、取得部103と、決定部104と、算出部105と、第2通信部106と、要求管理部107と、プラットフォーム部108と、を備えている。
第1通信部101は、他のノード100(外部装置)との間の通信リンク(ノード間リンク)によって接続された当該他のノード100(対向ノード)との間で、量子暗号通信技術を用いて乱数を生成共有し、生成した乱数をリンク鍵として管理する。また、第1通信部101は、ノード間リンクによって接続された他のノード100との間でデータの送受信(ノード間データ通信)を行う際に利用される。
ここで、他のノードとは、リンクによって直接接続された対向ノードである場合もあるし、その対向ノードの別のノード間リンクを介してさらに接続される別のノードである場合もある。後者の場合、第1通信部101は、暗号通信ネットワークにおいて、複数ノードを介して通信を行うためのルーティング機能を提供してもよい。第1通信部101を介してノード間で交換されるデータは、例えば、アプリケーション鍵のデータである。これらのデータは、ノード100が管理するリンク鍵を用いて暗号化された通信であってもよい。
リソース管理部102は、第1通信部101を介して交換するリンク鍵、およびアプリケーション鍵を管理および保持する。リソース管理部102は、直接接続された対向ノードとの間で交換したリンク鍵のみを保持する。一方、アプリケーション鍵については、リソース管理部102は、暗号通信ネットワーク上のどのようなノード100との間で交換したアプリケーション鍵であっても、保持管理することができる。
また、一般にリンク鍵は、ノード100との間のアプリケーション鍵の交換を安全に行うために利用される。利用が終了したリンク鍵は廃棄される。アプリケーション鍵は、後述の方法によって、ノード100からアプリケーション200に渡され、アプリケーション200によって利用される。アプリケーション200に提供されたアプリケーション鍵は、通常、ノード100では廃棄される。リソース管理部102が保持および管理する鍵は、暗号通信システムにおけるセキュリティ上最も重要なデータの1つである。このため、ファイルシステムやOS(オペレーティングシステム)によって暗号化、改竄防止、および、アクセス制限等のセキュリティ対策が施されていてもよい。リソース管理部102は、様々な実現方法が可能であるが、例えば、ファイルシステムやデータベースとして実装できる。
取得部103は、上述の(A1)および(A2)の処理を実行する。すなわち、取得部103は、他のノード100が提供可能なアプリケーション鍵の鍵リソース情報を取得(収集)する。また、取得部103は、鍵リソース情報を要求したアプリケーション200以外の他のアプリケーション200に関する情報(他アプリケーション情報)を取得する。取得部103は、鍵リソース情報、および、他アプリケーション情報の収集のために、第1通信部101、または、その他の図示しない通信インタフェースを用いて、他のノード100等と通信を行ってもよい。
決定部104は、上述の(A3)の処理を実行する。すなわち、決定部104は、自身のノード100から、暗号通信ネットワーク上の他の各ノード100へ至るためのパス(経路)の候補を洗い出す。
算出部105は、取得部103により取得された鍵リソース情報を参照し、鍵リソース情報を要求したアプリケーション200に提供可能な鍵リソース情報を算出する。このとき、算出部105は、決定部104により決定されたパスの候補のうち、最大の鍵リソースを提供可能なパス(最適パス)を算出する。そして、算出部105は、最適パスで提供可能な鍵リソース情報を、アプリケーション200に提供可能な鍵リソース情報として算出する。
第2通信部106は、アプリケーション200との間の通信リンク(アプリケーション通信リンク)によって接続された当該アプリケーション200との間でデータ通信を行う際に利用される。例えば、第2通信部106は、アプリケーション200からのアプリケーション鍵の取得要求などの要求を受け付け、アプリケーション200に対してアプリケーション鍵を提供する。また、第2通信部106は、アプリケーション200からの、鍵リソースの問い合わせ情報受付と、鍵リソース情報の回答のための通信にも用いられる。
第2通信部106は、送信部106aを備える。送信部106aは、アプリケーション200に対して各種データを送信する。例えば、送信部106aは、算出部105により算出された鍵リソース情報をアプリケーション200に送信する。
要求管理部107は、アプリケーション200が要求する鍵リソース情報の受付および管理、並びに、アプリケーション200に割り当てた鍵リソース情報の管理および通知等を行う。要求管理部107は、例えば、アプリケーション200の識別子(アドレス等)と、そのアプリケーション200が要求する鍵リソース情報と、を対応づけて記憶するデータベース等によって鍵リソース情報を管理する。
要求管理部107は、アプリケーション200との通信には第2通信部106を利用する。要求管理部107は、アプリケーション200から鍵リソース情報の要求を受け取り、受け取った鍵リソース情報を、算出部105等の要求に応じて提供する。一方、割り当てられた鍵リソース情報は、算出部105から要求管理部107に通知される。要求管理部107は、通知された鍵リソース情報を、対応するアプリケーション200に第2通信部106を介して提供する。
プラットフォーム部108は、ノード100上の他の構成要素の管理、動作に必要なコンピュータのオペレーティングシステム機能、基本的なネットワーク機能、および、セキュリティ機能等を提供する。
以上、本実施形態におけるノード100の構成について説明した。ただし、上記説明は一例である。
次に、本実施形態におけるアプリケーション200の構成について説明する。図4は、アプリケーション200の構成例を示すブロック図である。図4に示すように、アプリケーション200は、通信部201と、通信部202と、実行部203と、プラットフォーム部204と、を備えている。
通信部201は、ノード100との間の通信リンク(リンク52)を介して、ノード100(具体的にはノード100の第2通信部106)と接続して各種データを送受信する。例えば、通信部201は、暗号通信を行うために必要なアプリケーション鍵をノード100から取得する。この他、通信部201は、アプリケーション鍵の取得を開始する前に、利用可能な鍵リソースの問い合わせを行う。
アプリケーション200が、要求した鍵リソースが得られなかった場合にどのような処理を実行するかについては特に限定しない。また、ノード間リンクを用いて、アプリケーション200とノード100とが通信する手順については特に限定しないが、以下のような方法を適用できる。
例えば、通信部201は、ノード100からアプリケーション鍵を取得する通信に際して、ノード100との間でセッションの確立を行ってもよい。なお、このセッションの情報は、ノード100を介して、アプリケーション200による暗号通信の相手となるアプリケーション200、および、そのアプリケーション200が接続するノード100と共有されてもよい。
例えば、アプリケーション200aとアプリケーション200cとの暗号通信を行う際に、アプリケーション200aとノード100aは鍵利用セッションを確立し、また、アプリケーション200cとノード100cも、そのセッションと同一または関連付けられた鍵利用セッションを確立する。このため、通信部201は、何らかのセッション制御プロトコルを利用してノード100と通信してもよい。
実行部203は、暗号通信を行うアプリケーション機能を実行する。通信を行うものであれば特にアプリケーション機能の種類は限定しない。例えば、実行部203は、ビデオ送信およびファイル転送等の機能を実行する。実行部203は、暗号通信の際、通信部202を利用してデータを送受信する。
通信部202は、実行部203の動作に必要な通信機能を提供する。また、通信部202は、通信データの暗号化および復号機能を提供する。通信部202は、アプリケーション200から送信データを受けとると、送信データを暗号化し、暗号通信リンク(リンク53)を介してデータを送信する。また、通信部202は、暗号通信リンクからデータを受信すると、受信したデータを復号し、実行部203へと復号したデータを受け渡す。
暗号化および復号で必要になった場合は、通信部202は、ノード間リンクにより新たなアプリケーション鍵を要求する。通信部202は、どのような暗号アルゴリズムを用いて暗号通信を行ってもよい。例えば、ワンタイムパッドのようなバーナム暗号であってもよいし、AESのようなブロック暗号であってもよい。また暗号以外にメッセージ認証等を行っていてもよい。ただし、通信部202が利用する暗号アルゴリズムの少なくとも1つは、ノード100から提供されるアプリケーション鍵を利用するものとする。
プラットフォーム部204は、アプリケーション200上の他の構成要素の管理、動作に必要なコンピュータのオペレーティングシステム機能、基本的なネットワーク機能、および、セキュリティ機能等を提供する。
以上、本実施形態におけるアプリケーション200の構成について説明した。ただし、上記説明は一例である。
次に、このように構成された本実施形態にかかる通信システムによる鍵リソース算出処理について説明する。図5は、本実施形態における鍵リソース算出処理の一例を示すフローチャートである。図6は、通信システムのネットワーク構成例を示す図である。
まず、鍵リソース情報として鍵生成速度を扱う場合について説明する。図6は、鍵生成速度を鍵リソース情報とする場合の例を示す。図6の「リンク鍵n」の記載は、対応するリンクでのリンク鍵の鍵生成速度がnであることを表している。リンク鍵の鍵生成速度は、例えば、量子暗号通信における、方式、量子通信のスループット、光ファイバのケーブル長、および、ロス率等によって決定できる。リンク鍵の鍵生成速度は、例えば第1通信部101によって求められる。なお、リンク鍵の鍵生成速度は、システム運用中に固定的に決定できるものと考えることもできるし、動的に変動するものと考えてもよい。
ノード100は、図5に示す手順により、収集したリンク鍵の鍵生成速度等の情報を元にして、アプリケーション鍵の生成速度を算出し、アプリケーション200に回答する。なお、図5のステップS101〜ステップS104は、上述の(A1)〜(A4)に対応する。
まず、取得部103は、暗号通信ネットワーク上のすべてのノード100との間のパスにおける、リンク鍵の鍵生成速度の情報を収集する(ステップS101)。取得部103は、例えば、一定の時間間隔で何らかのノード間通信をすることでステップS101の処理を実行する。なお、アプリケーション200からの問い合わせを受ける前に事前にステップS101の処理を行っておいても良いし、アプリケーション200からの問い合わせを受けてからステップS101の処理を実行してもよい。アプリケーション200からの問合せとは無関係にステップS101を実行しても良い。
リンク鍵の鍵生成速度の収集にはいくつかの方法が存在する。各ノード100が、自身が保有するリンクにおけるリンク鍵の生成速度情報を図示しない管理サーバ(管理装置)に通知すると共に、必要なリンク鍵の生成速度情報を管理サーバから取得する方法を用いてもよい。管理サーバとは、例えばすべてのノード100のリンク鍵の生成速度情報を収集して管理するサーバである。この場合、取得部103が、管理サーバとの間の通信を行ってもよい。なお、このような管理サーバは、単純なデータベースやディレクトリサーバとして実現可能である。管理サーバが暗号通信ネットワーク上に存在する場合は、各ノード100は、第1通信部101を介して管理サーバと通信してもよい。管理サーバが別のネットワーク上に存在する場合は、各ノード100は、図示しない別のネットワークインタフェースを介して管理サーバと通信してもよい。
この他の方法として、各ノードが個別に前ノードと通信することで、全リンクのリンク鍵の生成速度情報を収集する方法もある。また、ルーティングプロトコルのメッセージ交換を用いて、各ノード100が、各ノード100が保有するリンク鍵の生成速度情報を、ルーティングプロトコルにおけるパラメータの1つとして収集する、という方法を用いてもよい。ルーティングプロトコルとは、暗号通信ネットワークにおけるルーティングを確立する上で実行されるプロトコルである。
このような目的に利用可能なルーティングプロトコルとして、OSPF(Open Shortest Path First)が存在する。OSPFは、リンクステートアップデートパケット(LSU)を通信システム内のすべてのノード間で交換することで、ルーティングプロトコルに必要なメトリックである各パス(リンク)のコスト情報を交換する。このコストの一種として、リンク鍵の生成速度情報を交換することで、ステップS101の実施が可能である。この場合、例えば取得部103と第1通信部101とにより、ルーティングプロトコルを実行するように構成できる。
収集したリンク鍵の生成速度情報は、取得部103にて保持される。なお、リンク鍵の生成速度情報とは、例えば図6のリンクそれぞれに示された数字(上述のn)のことである。図6の例では、生成速度情報は以下のように保持される。
ノード100a、100e間:5
ノード100e、100d間:10
ノード100d、100c間:12
ノード100a、100b間:8
ノード100b、100c間:4
ノード100a、100f間:7
ノード100f、100c間:10
図5に戻り、取得部103は、さらに他のアプリケーションの情報を収集する(ステップS102)。ステップS102は、暗号通信ネットワークにおいて、同時に複数のアプリケーション200を実行する場合に必要な手順である。同時に1つのアプリケーション200のみを実行する場合、本手順は必要ないため省略してよい。
例えば、ノード100aに接続するアプリケーション200aが、ノード100cに接続するアプリケーション200cと通信するための鍵リソースをノード100aに問い合わせると仮定する。また、このとき既に、アプリケーション200aと同じくノード100aに接続するアプリケーション200bが、アプリケーション200cと同じくノード100cに接続するアプリケーション200dと暗号通信するための鍵リソース(鍵生成速度)をある程度利用済み(割り当て済み)であったと仮定する。この場合、アプリケーション200bとアプリケーション200dとの間の暗号通信に割り当てた分の鍵リソース(鍵生成速度)は利用できない。このため、アプリケーション200aがノード100aから取得可能な鍵リソース(鍵生成速度)は、アプリケーション200bとアプリケーション200dとの間の暗号通信が存在しない場合と比べ、小さくなる。
従って、鍵リソースを分け合う他のアプリケーション200の存在を考慮し、他のアプリケーション200が使用している鍵リソース(鍵生成速度)を差し引いた鍵リソースが、実際にアプリケーション200aが利用可能な鍵リソース(アプリケーション鍵の鍵生成速度)であると考える必要がある。
そのため、取得部103は、以下の(対応1)および(対応2)のいずれかの処理を行う。
(対応1)
(A1)(すなわちステップS101)では、取得部103は、予め他のアプリケーション200に割り当て済みの鍵リソースを差し引いた鍵リソース情報を各ノード100から収集する。この場合、例えばノード100が予め他のアプリケーション200に割り当て済みの鍵リソースを差し引いた鍵リソース情報を取得部103に提供するように構成する。この処理により、(A2)(すなわちステップS102)では、特別な対応は不要となる。各ノード100における取得部103は、第1通信部101等から取得した各情報を共有できるように保持する。
ただし、他のアプリケーション200へのアプリケーション鍵の割り当て状況は、時刻とともに大きく変化しうる。このため、ステップS102を対応1により正確に行うためには、ステップS101の処理を細粒度で(短い時間間隔で)実行する必要がある。例えば、管理サーバへの問合せを頻繁に行う、あるいは、OSPFにおいて、定期的にリンク情報を交換するパケットである、LSUの送信間隔を短く設定する、等が具体的な対応となる。
(対応2)
(A1)では、他のアプリケーション200への割り当て済みの鍵リソースは考慮せずに情報収集を行う。一方、(A2)のために、鍵リソースの使用状況を管理する第2の管理サーバ(図示せず)を別途設ける。各ノード100の取得部103は、アプリケーション200への鍵リソースの割り当てを行った際、この第2の管理サーバに割り当て状況を通知する。また、各ノード100の取得部103は、定期的、または、必要に応じて、第2の管理サーバに、他ノード100における鍵リソースの割り当て情報を問い合わせる。この手順を実行することで、各ノード100は、他のアプリケーション200へ既に割り当て済みの鍵リソース(割り当て情報)を把握できる。また、各ノード100は、収集した鍵リソースから、割り当て済みの鍵リソースを差し引くことができる。なお、このような第2の管理サーバは、単純なデータベースやディレクトリサーバとして実現可能である。第2の管理サーバが暗号通信ネットワーク上に存在する場合は、各ノード100は、第1通信部101を介して第2の管理サーバと通信してもよい。第2の管理サーバが別のネットワーク上に存在する場合は、各ノード100は、図示しない別のネットワークインタフェースを介して第2の管理サーバと通信してもよい。なお、第2の管理サーバと管理サーバは、同一のサーバ、または、同一のサーバ上のプロセスとして実現されても良い。
ステップS101およびステップS102の後、決定部104は、パス候補を決定する(ステップS103)。決定部104は、例えばステップS101と同時に、または、別途ルーティングプロトコルを実行すること等により収集したノード間のグラフ情報を元に、自身のノード100から、暗号通信ネットワーク上の他の各ノード100へ至るためのパスの候補をすべて洗い出す。このためには、ネットワークにおける各ノードの接続関係に関する情報が必要である。このためには、既存のルーティングプロトコルによる接続情報収集の仕組みを利用して良い。前述のルーティングプロトコルと同時に実施しても良いし、別々に実施しても良い。
例えば、図6において、ノード100aからノード100cに至るパスの候補は、以下の3通りである。
候補A:ノード100a−ノード100e−ノード100d−ノード100c
候補B:ノード100a−ノード100b−ノード100c
候補C:ノード100a−ノード100f−ノード100c
なお、決定部104は、同じノードを二度通るパスは選択しない等の条件を用いて、ループになるパスなどの無駄なパスを排除するように構成してもよい。
次に、算出部105は、パス候補のうち鍵リソースが最適となるパス(最適パス)と最適パスで提供可能な鍵リソースを算出する(ステップS104)。例えば、算出部105は、求められたパス候補それぞれについて、鍵リソースの値(すなわち、リンク鍵の鍵生成速度)が最小である箇所(リンク)をそのパス候補のボトルネックとして求める。また、算出部105は、そのボトルネックの値が最大であるパスを最適パスとして選択する。
例えば上述の候補A〜Cの例の場合、ボトルネットとなるリンクの鍵生成速度は以下のようになる。
候補A:
ノード100a−ノード100e間の鍵生成速度:5
ノード100e−ノード100d間の鍵生成速度:10
ノード100d−ノード100c間の鍵生成速度:12
ボトルネック:5
候補B:
ノード100a−ノード100b間の鍵生成速度:8
ノード100b−ノード100c間の鍵生成速度:4
ボトルネック:4
候補C:
ノード100a−ノード100f間の鍵生成速度:7
ノード100f−ノード100c間の鍵生成速度:10
ボトルネック:7
このため、算出部105は、候補C(ノード100a−ノード100f−ノード100c)を最適パスとする。また、算出部105は、最適パスに対応する鍵生成速度を7×αと算出する。ここで、αは、リンク鍵の保有量と、そのリンク鍵を使って交換できるアプリケーション鍵の保有量との比である。αは、理想的には1となる。以上より、アプリケーション鍵の生成速度は7となる。
ノード100は、算出された鍵生成速度をアプリケーション200に回答する。鍵リソース情報の回答を受けたアプリケーション200の動作は特に限定しないが、例えば、以下のように動作してもよい。アプリケーション200は、回答された最適パスの鍵リソースの提供をノード100に要求する。ノード100は、この要求を受けて最適パスからアプリケーション鍵を得てアプリケーション200に送付する。アプリケーション200は、提供を受けたアプリケーション鍵を用いて、アプリケーション鍵を用いる暗号通信を開始する。
なお、ステップS103およびステップS104を、例えば算出部105が1つの手順として実行してもよい。また、最適パスとして選択するパスは、(P1)1本のパス(P2)途中で複数のパスに分かれるパス(すなわち、複数のパスを同時に利用し、より大量の鍵リソースを一度に利用する)のいずれであってもよい。上記例では、(P1)の場合を説明した。
一般に、(P2)の場合、最大フロー問題を解くことで上記手順を実現できる。最大フロー問題とは、単一の始点から単一の終点へのフローネットワークで、最大となるフローを求める数学の問題である。最大フロー問題の解法としては、線形計画法、および、フォード・ファルカーソンのアルゴリズム等、様々な解法が知られている。算出部105は、これらのどのようなアルゴリズムを用いて上記手順を実現しても構わない。
(P1)の場合も様々な方法が適用できる。算出部105は、どのようなアルゴリズムを用いて上記手順を実現しても構わない。前述の最大フロー問題の一部として解いても構わない。また、例えば、一般に最短経路問題を解くアルゴリズムとして知られているダイクストラのアルゴリズムが、ルーティングプロトコルOSPFには実装されているが、このプロトコルを改良して適用することでも実現できる。通常のダイクストラのアルゴリズムはで、宛先ノードの情報として、パス候補のコストの合計を保持し、これが最小となるパスが最短パスとして選択される。一方、改良ダイクストラアルゴリズムでは、パス候補のコスト(鍵リソース:鍵生成速度)の最小値を保持し、これが最大となるパスを、最適パスとして選択すればよい。
以上が、鍵リソースとして鍵生成速度を扱う場合の、鍵リソース割り当てアルゴリズムのシーケンスとなる。上述の手順の実行結果として、各ノード100は、自ノードから他のすべてのノード100との間で、アプリケーション200に提供可能な鍵生成速度という鍵リソースが決定できる。
ノード100は、この鍵リソース情報のうち、アプリケーション200から問い合わせを受けた他のノード100に関する鍵リソース情報を、該当アプリケーション200に対し応答する。
例えば、ノード100aが、アプリケーション200aから、アプリケーション200cと通信するために利用できる鍵リソースとしての鍵生成速度に関する問い合わせを受けたとする。この場合、ノード100aは、ノード100cとの間で利用可能な鍵生成速度に関する情報を応答する。
なお、アプリケーション200aは、ノード100cそのものの識別子(アドレス等)を直接指定して問い合わせを行ってもよいし、行わなくてもよい。後者の場合、例えば、問い合わせを受けたノード100a自身が、アプリケーション200aから通知された情報をもとに、アプリケーション200cが接続するノード100cを特定してもよい。
次に、鍵リソースとして鍵保有量を扱う場合について説明する。図7は、この場合の通信システムのネットワーク構成例を示す図である。図7の「リンク鍵n」の記載は、対応するリンクでのリンク鍵の鍵保有量がnであることを表している。また、例えば図7のノード100aに対応づけられた吹き出し内の「ノード100b...20」の記載は、ノード100aとノード100bとの間で共有するアプリケーション鍵の鍵保有量が20であることを表している。
まず、取得部103は、鍵保有量の情報を収集する(ステップS101)。鍵保有量のカウント方式には以下の方式Aおよび方式Bの2つの方式がある。
方式A:既にアプリケーション鍵として、自ノードにて保有されているもののみを、鍵保有量としてカウントする。
方式B:方式Aでカウントされた鍵保有量に加えて、自ノードと宛先ノードとの間のパス上のリンクにて既に保有されているリンク鍵を使用して交換可能なアプリケーション鍵に関しては、追加的に所有しうるアプリケーション鍵として、鍵保有量に追加してカウントする。
方式Aの場合、特に鍵リソース情報の収集手順は非常に単純となる。例えば、取得部103は、リソース管理部102が保持しているノード100毎のアプリケーション鍵の保有量のデータを参照することで、鍵保有量を決定できる。
方式Bの場合は、方式Aで述べた、リソース管理部102が保持しているノード100毎のアプリケーション鍵の保有量に加えて、リンク鍵の保有量についても考慮する必要がある。そのため、取得部103は、暗号通信ネットワーク上のすべてのノード100との間のパスにおける、リンク鍵の鍵保有量の情報を収集する。
図7では、鍵リソース情報として鍵保有量を扱う場合に必要な情報として、ノード100(実際に必要なのは自ノードに関する情報のみ)が保有する他の各ノード100と共有しているアプリケーション鍵の鍵保有量と、暗号通信ネットワーク上のすべてのリンクにおけるリンク鍵の鍵保有量と、が示されている。
アプリケーション鍵およびリンク鍵の鍵保有量の情報は、リソース管理部102にアクセスすることで求められる。前述の通り、アプリケーション鍵の鍵保有量は、アプリケーション鍵の該当ノードとの間で交換することで増加し、アプリケーション200にアプリケーション鍵を提供することで減少する。また、リンク鍵の鍵保有量は、量子暗号通信技術における鍵共有手順によって増加し、ノード間でリンク鍵を用いたセキュア通信を行う(例えばアプリケーション鍵の交換のため)ことで減少する。
図7におけるノード100aのリソース管理部102が保持する情報の例を以下に示す。
まず、各ノードが保有するアプリケーション鍵の保有量について示す。
ノード100b:20
ノード100c:30
ノード100d:40
ノード100e:50
ノード100f:60
次に、各ノード間のリンクで保有されるリンク鍵の保有量について示す。
ノード100a−ノード100e間のリンク:5
ノード100e−ノード100d間のリンク:10
ノード100d−ノード100c間のリンク:12
ノード100a−ノード100b間のリンク:8
ノード100b−ノード100c間のリンク:4
ノード100a−ノード100f間のリンク:7
ノード100f−ノード100c間のリンク:10
なお、方式Bの場合に追加で必要となる、暗号通信ネットワーク上のすべてのノード間のパスにおけるリンク鍵の鍵保有量の情報の収集方法は、鍵生成速度に関する鍵リソース情報の収集と同様の手順で可能であるため、説明を省略する。
方式Aの場合、他のアプリケーション200に既に割り当てているアプリケーション鍵の鍵保有量は、例えば、要求管理部107またはリソース管理部102にて記録されている。取得部103は、記録された鍵保有量を参照することにより、割り当て済みの鍵保有量(割り当て情報)を差し引いて、新たに提供可能な鍵保有量を算出することができる。
方式Bの場合、取得部103は、さらに、リンク鍵の鍵保有量のうち、既に他のアプリケーション200に割り当て済みのリンク鍵の鍵保有量の情報を収集する。収集の方法は、例えば、鍵生成速度に関する他のアプリケーション200の情報の収集と同様の方法を適用できる。
方式Aの場合、決定部104によるパス候補の決定処理(ステップS103)は不要である。方式Bの場合、決定部104は、鍵生成速度に関するパス候補の算出と同様の手順で、パス候補を算出する。
例えば、図7において、ノード100aからノード100cに至るパスの候補は、
候補A:ノード100a−ノード100e−ノード100d−ノード100c
候補B:ノード100a−ノード100b−ノード100c
候補C:ノード100a−ノード100f−ノード100c
の3通りある。
方式Aの場合、ノード100は、通信相手となる他のノード100に対応するアプリケーション鍵の鍵保有量をそのままアプリケーション200に回答する。
方式Bの場合、算出部105は、鍵生成速度に関する最適パスと同様の手順で、鍵保有量に関する最適パスを決定する。また、算出部105は、方式Aで求めたノード100が既に保有するアプリケーション鍵の鍵保有量と、方式Bで求めたリンク鍵の鍵保有量とを足し算した結果を、鍵保有量の値としてアプリケーション200に回答する。
図7の例では、ノード100aとノード100cとの間で共有しているアプリケーション鍵は、30である。また、各パス候補のリンク鍵保有量および追加で所有しうるアプリケーション鍵は、以下のようになる。
候補A:
ノード100a−ノード100e間のリンク鍵保有量:5
ノード100e−ノード100d間のリンク鍵保有量:10
ノード100d−ノード100c間のリンク鍵保有量:12
候補Aのパスによって追加的に所有しうるアプリケーション鍵:5×α
候補B:
ノード100a−ノード100b間のリンク鍵保有量:8
ノード100b−ノード100c間のリンク鍵保有量:4
候補Bのパスによって追加的に所有しうるアプリケーション鍵:4×α
候補C:
ノード100a−ノード100f間のリンク鍵保有量:7
ノード100f−ノード100c間のリンク鍵保有量:10
候補Cのパスによって追加的に所有しうるアプリケーション鍵:7×α
ここで、αは、リンク鍵の保有量と、そのリンク鍵を使って交換できるアプリケーション鍵の保有量との比であり、理想的には1となる。
以上より、アプリケーション鍵保有量は、最適パスとなる候補Cのパスを経由することにより、30+7=37となる。ノード100は、この値(37)をアプリケーション200に回答する。
このように、本実施形態にかかる通信システムでは、各ノードが、鍵生成速度または鍵保有量などの鍵リソース情報を収集し、アプリケーションに対して割り当て可能な鍵リソース情報を回答することができる。これにより、例えばアプリケーションは取得可能なアプリケーション鍵の情報を入手でき、適切な暗号アルゴリズムを決定するなどの処理を実現できる。
本実施形態のノード100およびアプリケーション200が備える各部は、ハードウェア回路により実現してもよいし、一部または全部をソフトウェア(プログラム)により実現してもよい。
次に、本実施形態にかかる装置(アプリケーション、ノード)のハードウェア構成について図8を用いて説明する。図8は、本実施形態にかかる装置のハードウェア構成を示す説明図である。
本実施形態にかかる装置は、CPU(Central Processing Unit)851などの制御装置と、ROM(Read Only Memory)852やRAM(Random Access Memory)853などの記憶装置と、ネットワークに接続して通信を行う通信I/F854と、各部を接続するバス861を備えている。
本実施形態にかかる装置で実行されるプログラムは、ROM52等に予め組み込まれて提供される。
本実施形態にかかる装置で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
さらに、本実施形態にかかる装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかる装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
本実施形態にかかる装置で実行されるプログラムは、コンピュータを上述した装置の各部として機能させうる。このコンピュータは、CPU851がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
100a〜100f ノード
101 第1通信部
102 リソース管理部
103 取得部
104 決定部
105 算出部
106 第2通信部
106a 送信部
107 要求管理部
108 プラットフォーム部
200a〜200d アプリケーション
201 通信部
202 通信部
203 実行部
204 プラットフォーム部

Claims (11)

  1. 暗号鍵を生成する鍵生成装置に接続される通信装置であって、
    前記鍵生成装置が提供可能な前記暗号鍵のリソースを表す鍵リソース情報を取得する取得部と、
    取得された前記鍵リソース情報に基づいて、前記暗号鍵を利用するアプリケーションに提供可能な前記暗号鍵の前記鍵リソース情報を算出する算出部と、
    を備える通信装置。
  2. 前記通信装置は複数の鍵生成装置に接続され、
    複数の前記鍵生成装置に含まれる第1装置に到達する経路を決定する決定部をさらに備え、
    前記算出部は、取得された前記鍵リソース情報に基づいて、前記経路を介して提供可能な前記暗号鍵の前記鍵リソース情報を算出する、
    請求項1に記載の通信装置。
  3. 前記決定部は、前記第1装置に到達する1以上の経路を決定し、
    前記算出部は、前記経路を介して提供可能な前記暗号鍵の前記鍵リソース情報のうち、最大の前記鍵リソース情報を算出する、
    請求項2に記載の通信装置。
  4. 前記鍵リソース情報は、提供可能な前記暗号鍵の生成速度である、
    請求項3に記載の通信装置。
  5. 前記鍵リソース情報は、提供可能な前記暗号鍵の保有量である、
    請求項3に記載の通信装置。
  6. 算出された前記鍵リソース情報を前記アプリケーションに送信する送信部をさらに備える、
    請求項3に記載の通信装置。
  7. 前記取得部は、さらに、前記鍵生成装置が割り当て済みの前記暗号鍵のリソースを表す割り当て情報を取得し、
    前記算出部は、取得された前記鍵リソース情報と前記割り当て情報とに基づいて、前記アプリケーションに提供可能な前記暗号鍵の前記鍵リソース情報を算出する、
    請求項1に記載の通信装置。
  8. 前記取得部は、OSFP(Open Shortest Path First)ルーティングプロトコルに従って交換されるメッセージに含まれる前記鍵リソース情報を前記鍵生成装置から取得する、
    請求項1に記載の通信装置。
  9. 前記取得部は、前記鍵生成装置の前記鍵リソース情報を記憶する管理装置から、前記鍵リソース情報を取得する、
    請求項1に記載の通信装置。
  10. 暗号鍵を生成する鍵生成装置に接続される通信装置で実行される通信方法であって、
    前記鍵生成装置が提供可能な前記暗号鍵のリソースを表す鍵リソース情報を取得する取得ステップと、
    取得された前記鍵リソース情報に基づいて、前記暗号鍵を利用するアプリケーションに提供可能な前記暗号鍵の前記鍵リソース情報を算出する算出ステップと、
    を含む通信方法。
  11. 鍵生成装置と、通信装置と、を備える通信システムであって、
    前記鍵生成装置は、
    暗号鍵を生成して前記通信装置に送信する通信部を備え、
    前記通信装置は、
    前記鍵生成装置が提供可能な前記暗号鍵のリソースを表す鍵リソース情報を取得する取得部と、
    取得された前記鍵リソース情報に基づいて、前記暗号鍵を利用するアプリケーションに提供可能な前記暗号鍵の前記鍵リソース情報を算出する算出部と、を備える、
    通信システム。
JP2012159044A 2012-07-17 2012-07-17 鍵生成装置、通信方法および通信システム Expired - Fee Related JP5694247B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2012159044A JP5694247B2 (ja) 2012-07-17 2012-07-17 鍵生成装置、通信方法および通信システム
CN201310064977.5A CN103546276A (zh) 2012-07-17 2013-03-01 通信设备、通信方法以及通信系统
US13/834,559 US20140023192A1 (en) 2012-07-17 2013-03-15 Communication device, communication method, and communication system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012159044A JP5694247B2 (ja) 2012-07-17 2012-07-17 鍵生成装置、通信方法および通信システム

Publications (2)

Publication Number Publication Date
JP2014022898A true JP2014022898A (ja) 2014-02-03
JP5694247B2 JP5694247B2 (ja) 2015-04-01

Family

ID=49946551

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012159044A Expired - Fee Related JP5694247B2 (ja) 2012-07-17 2012-07-17 鍵生成装置、通信方法および通信システム

Country Status (3)

Country Link
US (1) US20140023192A1 (ja)
JP (1) JP5694247B2 (ja)
CN (1) CN103546276A (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014241463A (ja) * 2013-06-11 2014-12-25 株式会社東芝 通信装置、通信方法、プログラムおよび通信システム
JP2015179974A (ja) * 2014-03-19 2015-10-08 株式会社東芝 通信装置、通信方法およびプログラム
US10223182B2 (en) 2015-01-06 2019-03-05 Kabushiki Kaisha Toshiba Communication device, communication system, and computer program product
US10348492B2 (en) 2014-11-19 2019-07-09 Kabushiki Kaisha Toshiba Quantum key distribution device, quantum key distribution system, and quantum key distribution method
JP2020501413A (ja) * 2016-11-04 2020-01-16 華為技術有限公司Huawei Technologies Co.,Ltd. 集中管理制御ネットワークに基づく量子鍵中継方法、および装置

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104486363B (zh) * 2015-01-05 2017-08-25 福建爱特点信息科技有限公司 一种云安全保障系统
CN106161402B (zh) * 2015-04-22 2019-07-16 阿里巴巴集团控股有限公司 基于云环境的加密机密钥注入系统、方法及装置
US11991273B2 (en) * 2018-09-04 2024-05-21 International Business Machines Corporation Storage device key management for encrypted host data
US11038698B2 (en) 2018-09-04 2021-06-15 International Business Machines Corporation Securing a path at a selected node
US11088829B2 (en) 2018-09-04 2021-08-10 International Business Machines Corporation Securing a path at a node
JP7282713B2 (ja) * 2020-04-16 2023-05-29 株式会社東芝 量子暗号装置、量子暗号通信料金計算システム及び量子暗号通信料金計算方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7392378B1 (en) * 2003-03-19 2008-06-24 Verizon Corporate Services Group Inc. Method and apparatus for routing data traffic in a cryptographically-protected network
US7706535B1 (en) * 2003-03-21 2010-04-27 Bbn Technologies Corp. Systems and methods for implementing routing protocols and algorithms for quantum cryptographic key transport
JP2011044768A (ja) * 2009-08-19 2011-03-03 Nec Corp 秘匿通信システムにおける通信装置および通信制御方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7016494B2 (en) * 2001-03-26 2006-03-21 Hewlett-Packard Development Company, L.P. Multiple cryptographic key precompute and store
US8615218B2 (en) * 2003-12-09 2013-12-24 Electronics And Telecommunications Research Institute Method for requesting, generating and distributing service-specific traffic encryption key in wireless portable internet system, apparatus for the same, and protocol configuration method for the same
US7953978B2 (en) * 2006-09-07 2011-05-31 International Business Machines Corporation Key generation and retrieval using key servers
JP5288087B2 (ja) * 2007-06-11 2013-09-11 日本電気株式会社 秘匿通信ネットワークにおける暗号鍵管理方法および装置
TW201201556A (en) * 2010-06-29 2012-01-01 Chunghwa Telecom Co Ltd Construction structure of quantum encryption service network
JP5634427B2 (ja) * 2012-03-23 2014-12-03 株式会社東芝 鍵生成装置、鍵生成方法およびプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7392378B1 (en) * 2003-03-19 2008-06-24 Verizon Corporate Services Group Inc. Method and apparatus for routing data traffic in a cryptographically-protected network
US7706535B1 (en) * 2003-03-21 2010-04-27 Bbn Technologies Corp. Systems and methods for implementing routing protocols and algorithms for quantum cryptographic key transport
JP2011044768A (ja) * 2009-08-19 2011-03-03 Nec Corp 秘匿通信システムにおける通信装置および通信制御方法

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014241463A (ja) * 2013-06-11 2014-12-25 株式会社東芝 通信装置、通信方法、プログラムおよび通信システム
US9928370B2 (en) 2013-06-11 2018-03-27 Kabushiki Kaisha Toshiba Communication device, communication method, computer program product, and communication system
JP2015179974A (ja) * 2014-03-19 2015-10-08 株式会社東芝 通信装置、通信方法およびプログラム
US10348492B2 (en) 2014-11-19 2019-07-09 Kabushiki Kaisha Toshiba Quantum key distribution device, quantum key distribution system, and quantum key distribution method
US10223182B2 (en) 2015-01-06 2019-03-05 Kabushiki Kaisha Toshiba Communication device, communication system, and computer program product
JP2020501413A (ja) * 2016-11-04 2020-01-16 華為技術有限公司Huawei Technologies Co.,Ltd. 集中管理制御ネットワークに基づく量子鍵中継方法、および装置
JP2021010179A (ja) * 2016-11-04 2021-01-28 華為技術有限公司Huawei Technologies Co.,Ltd. 集中管理制御ネットワークに基づく量子鍵中継方法、および装置
JP7026748B2 (ja) 2016-11-04 2022-02-28 華為技術有限公司 集中管理制御ネットワークに基づく量子鍵中継方法、および装置
US12028450B2 (en) 2016-11-04 2024-07-02 Huawei Technologies Co., Ltd. Quantum key relay method based on centralized management and control network, and apparatus

Also Published As

Publication number Publication date
US20140023192A1 (en) 2014-01-23
CN103546276A (zh) 2014-01-29
JP5694247B2 (ja) 2015-04-01

Similar Documents

Publication Publication Date Title
JP5694247B2 (ja) 鍵生成装置、通信方法および通信システム
JP7026748B2 (ja) 集中管理制御ネットワークに基づく量子鍵中継方法、および装置
US9306734B2 (en) Communication device, key generating device, and computer readable medium
JP6223884B2 (ja) 通信装置、通信方法およびプログラム
JP5634427B2 (ja) 鍵生成装置、鍵生成方法およびプログラム
JP5734934B2 (ja) 通信ノード、鍵同期方法、鍵同期システム
JP6192998B2 (ja) 通信装置、通信方法、プログラムおよび通信システム
CN110581763A (zh) 一种量子密钥服务区块链网络系统
JP2013046363A (ja) 鍵共有装置、鍵共有方法および鍵共有プログラム
EP3633949A1 (en) Method and system for performing ssl handshake
JP2016127482A (ja) 通信装置、通信システムおよびプログラム
CN109698791B (zh) 一种基于动态路径的匿名接入方法
US20140143443A1 (en) Communication device, communication system, and computer program product
US9509589B2 (en) Communication device, communication system, communication method, and computer program product
JP2014068313A (ja) 通信方法、アプリケーション装置、プログラム及び通信システム
KR20220092853A (ko) 안전한 대역외 대칭 암호화 키 전달
CN114142995A (zh) 面向区块链中继通信网络的密钥安全分发方法及装置
CN114095499A (zh) 区块链中继通信网络的中立性验证方法及装置
JP6211818B2 (ja) 通信装置、通信方法、プログラムおよび通信システム
US9083682B2 (en) Communication device and computer program product
JP2023136740A (ja) 鍵管理装置、量子暗号通信システム及びプログラム
Raj et al. Secure cloud communication for effective cost management system through msbe
JP2019195198A (ja) 通信装置、通信方法、プログラムおよび通信システム
JP5992578B2 (ja) 通信方法、アプリケーション装置、プログラム及び通信システム
JP2017038413A (ja) 通信装置、鍵生成装置、通信方法、プログラムおよび通信システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140514

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140610

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20141028

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20141127

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: 20150106

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150204

LAPS Cancellation because of no payment of annual fees