JP2023040843A - クラウド鍵管理サービス基盤システム - Google Patents

Abstract

【課題】クラウドシステム上で量子鍵の提供を含む量子暗号通信サービスを提供するクラウド鍵管理サービス基盤システムを提供する。【解決手段】実施形態によれば、基盤システムは、クラウドシステム上で量子暗号通信サービスを提供する。クラウドシステムは、複数のデータセンタによって複数のサービスエリアを設定する。第１サービスエリア内の各データセンタは、第１サービスエリア内の他のデータセンタと協働して、第１サービスエリア内の他のユーザとの間で量子暗号通信を行うユーザ向けの量子鍵を生成し、または、第１サービスエリア内および第２サービスエリア内の他のデータセンタと協働して、第２サービスエリア内の他のユーザとの間で量子暗号通信を行うユーザ向けの量子鍵を生成する。基盤システムは、複数のサービスエリア内の任意の２点間で量子暗号通信を行う両ユーザに対して当該２点間で共有化された量子鍵を提供する。【選択図】図１

Description

本発明の実施形態は、クラウド鍵管理サービス基盤システムに関する。

近年、通信経路上でのデータの漏洩を防止するために、データを暗号化して送受信する暗号通信が広く行われている。暗号通信でデータの保護を図るためには、たとえば複数の拠点間で共有する暗号鍵の管理も重要である。このようなことから、インターネット経由で暗号鍵の管理サービスを提供するクラウドシステムが登場するに至っている。

また、最近では、量子力学の原理を利用して暗号鍵（量子鍵）を２拠点間で安全に共有することができる量子鍵配送（ＱＫＤ：Ｑｕａｎｔｕｍ Ｋｅｙ Ｄｉｓｔｒｉｂｕｔｉｏｎ）が注目を集めている。量子鍵配送は、光子の挙動を利用する技術であり、光ファイバなどを媒体として２拠点間で光子によって暗号鍵情報を送受信する。量子鍵配送によって２拠点間で共有化された量子鍵を用いた当該２拠点間における暗号通信は、量子暗号通信などと称される。量子暗号通信に関しては、ＥＴＳＩにおいて鍵提供ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）が標準化されるに至っている（ＥＴＳＩ ＧＳ ＱＫＤ ０１４）。

特許第６６０９０１０号公報

量子暗号通信の導入にあたっては、量子鍵配送で光ファイバの敷設が必要となる等、ユーザによっては、量子暗号通信のための設備を独自に構築することはコスト的に困難な場合がある。従って、既存の非量子鍵の暗号鍵管理サービスと同様に、クラウドサービスとして、量子鍵の提供を含む暗号鍵管理サービスが提供されることを望む声も多い。

しかし、量子鍵配送は２拠点間での量子鍵の共有を前提としている。一方、既存の非量子鍵の暗号鍵管理サービスを含む各種サービスを提供するクラウドシステムは、ある程度の地理的範囲毎に１以上のデータセンタによってサービスエリアを形成し、当該サービスエリア毎に各種サービスを提供・管理することが一般的である。そして、クラウドシステムでは、各種サービスを提供・管理する拠点が、各サービスエリアを形成するデータセンタの論理的な集合体で表現される。なお、クラウドシステムは、狭域のサービスエリアを下位層とし、複数の狭域のサービスエリアを含む広域のサービスエリアを上位層とする多階層のサービスエリアを設定する場合がある。

そのため、２拠点間での量子鍵の共有という量子鍵配送の概念は、各拠点が１以上のデータセンタの論理的な集合体で表現されるクラウドシステムには馴染まない。従って、クラウドサービスの１つとして、既存の非量子鍵の暗号鍵管理サービスを、単純に、量子鍵の暗号鍵管理サービスへと移植することはできない。

本発明が解決しようとする課題は、クラウドシステム上で量子鍵の提供を含む量子暗号通信サービスを提供するクラウド鍵管理サービス基盤システムを提供することである。

実施形態によれば、クラウド鍵管理サービス基盤システムは、非量子鍵の暗号鍵を管理するクラウド鍵管理サービスを含む各種サービスを提供するクラウドシステム上でクラウド鍵管理サービスのインターフェースに準じた拡張インターフェースによる量子鍵の提供を含む量子暗号通信サービスを提供する。クラウドシステムは、量子暗号通信サービスの提供拠点となる複数のデータセンタを有し、複数のデータセンタによって、各々が１以上のデータセンタで形成される複数のサービスエリアを設定する。複数のデータセンタのそれぞれは、量子鍵配送システムと、量子鍵流通システムと、鍵管理システムと、を具備する。量子鍵配送システムは、直接的に接続されている他のデータセンタとの間の量子暗号通信のための量子鍵であるＱ鍵を生成して他のデータセンタとの間で共有化する。量子鍵流通システムは、量子暗号通信を行うユーザに提供する量子鍵であるＧ鍵を、他のデータセンタとの間でＱ鍵を用いた量子暗号通信によって送受信する。鍵管理システムは、Ｇ鍵をサービスエリア単位で管理する。鍵管理システムは、ユーザからのＧ鍵の要求を拡張インターフェースによって受け付け、量子鍵用の鍵提供ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）によって量子鍵流通システムから取得したＧ鍵をユーザに提供する。第１サービスエリア内の各データセンタは、第１サービスエリア内の他のデータセンタと協働して、第１サービスエリア内の他のユーザとの間で量子暗号通信を行う前記第１サービスエリア内のユーザ向けの第１Ｇ鍵を生成し、または、第１サービスエリア内および第１サービスエリアと異なる第２サービスエリア内の他のデータセンタと協働して、第２サービスエリア内の他のユーザとの間で量子暗号通信を行う第１サービスエリア内のユーザ向けの第２Ｇ鍵を生成する。クラウド鍵管理サービス基盤システムは、複数のサービスエリア内の任意の２点間で量子暗号通信を行う両ユーザに対して当該２点間で共有化された第１Ｇ鍵または第２Ｇ鍵を拡張インターフェースによって提供する。

実施形態のクラウド鍵管理サービス基盤システム（基盤システム）の概要を示す図 第１比較例の量子暗号通信システムを示す図 第２比較例のクラウドシステムで用いられるエンベローブ暗号化を説明するための図 第２比較例のクラウドシステムのクラウド鍵管理サービスの概要を示す図 第２比較例のクラウドシステムのクラウド鍵管理サービスの一利用様態例を示す図 第２比較例のクラウドシステムによるサービスエリアの一形成例を示す図 実施形態の基盤システムでのクラウドシステムへの量子鍵配送の一適用例を示す図 実施形態の基盤システムのシステム全体の機能ブロックの一例を示す図 実施形態の基盤システムのデータセンタの機能ブロックの一例を示す図 実施形態の基盤システムの量子鍵流通システムの機能ブロックの一例を示す図 実施形態の基盤システムの量子鍵配送システム３０の機能ブロックの一例を示す図 実施形態の基盤システムにおける量子暗号通信サービス利用開始時の動作の流れを示すフローチャート 実施形態の基盤システムにおける量子鍵を用いた暗号化を行う場合の動作の流れを示すフローチャート 実施形態の基盤システムにおける量子鍵を用いた復号を行う場合の動作の流れを示すフローチャート 実施形態の基盤システムにおける量子暗号通信サービス利用終了時の動作の流れを示すフローチャート 実施形態の基盤システムの第１ユースケースを示す図 実施形態の基盤システムの第２ユースケースを示す図 実施形態の基盤システムの第３ユースケースを示す図

以下、実施の形態について、図面を参照して説明する。
図１は、実施形態のクラウド鍵管理サービス基盤システム１の概要を示す図である。図１には、ユーザ（Ａ、Ｂ）によるクラウド鍵管理サービス基盤システム１の利用イメージが併せて示されている。なお、以下、クラウド鍵管理サービス基盤システム１を、単に、基盤システム１と称することがある。基盤システム１は、インターネット経由で各種サービスを提供するクラウドシステム上で量子鍵の提供を含む量子暗号通信サービスを提供する。

図１では、ユーザＡが、基盤システム１から量子鍵（ａ１）を取得し、当該取得した量子鍵でデータを暗号化してユーザＢへ送信する。一方、ユーザＢも、基盤システム１から量子鍵を取得し、暗号化されたデータを復号する。つまり、ユーザＡとユーザＢとが、基盤システム１から量子鍵の提供を受けて量子暗号通信（ａ２）を行う。

換言すれば、基盤システム１は、クラウドシステムのサービスエリア内の任意の２点間で量子暗号通信を行うユーザＡとユーザＢとのそれぞれに対して、両者が共有すべき量子鍵をクラウドサービスとして提供する。

クラウドシステムは、複数のデータセンタ１００でサービスエリアを形成する。複数のデータセンタ１００のそれぞれは、鍵管理システム（ＫＭＳ：Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅ）１０と、量子鍵流通システム２０と、量子鍵配送システム３０とを有する。なお、以下、量子鍵流通システム２０および量子鍵配送システム３０を、ＱＫＤシステムと総称することがある。

鍵管理システム１０は、既存の非量子鍵の暗号鍵管理サービスに加えて、量子鍵の暗号鍵管理サービスを提供する機能を有する。鍵管理システム１０は、ユーザが通信相手との間で共有すべき量子鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによって量子鍵流通システム２０から取得し、既存の非量子鍵の暗号鍵管理サービスのインターフェースに準じた拡張インターフェースによってユーザに提供する。従って、ユーザは、量子鍵用の鍵提供ＡＰＩを持つ必要がなく、非量子鍵の暗号鍵管理サービス用の既存のインターフェースに準じた拡張インターフェース（ａ３）で量子鍵を取得することができる。既存のインターフェースや拡張インターフェースについては後述する。以下、非量子鍵の暗号鍵管理サービスおよび量子鍵の暗号鍵管理サービスを、クラウド鍵管理サービスと総称することがある。

量子鍵流通システム２０は、ユーザに提供する量子鍵を生成し、ユーザの実質的な窓口となっているデータセンタ１００間で当該量子鍵を共有化するための通信を実行する。具体的には、量子鍵流通システム２０は、隣接する、即ち直接的に接続されているデータセンタ１００（または中継拠点）の量子鍵流通システム２０との間で、ユーザに供給する量子鍵を量子暗号通信によって送受信する。つまり、量子鍵は、たとえば複数のデータセンタ１００（または中継拠点）の量子鍵流通システム２０の中継を経て、ユーザの実質的な窓口となっているデータセンタ１００間で送受信される。

量子鍵配送システム３０は、量子鍵流通システム２０が他の量子鍵流通システム２０との間で量子暗号通信を行うための量子鍵を生成する。量子鍵配送システム３０は、他の量子鍵配送システム３０と協働して、量子鍵流通システム２０の量子暗号通信のための量子鍵の共有化を実行する。

つまり、基盤システム１は、水面下で、量子鍵の中継を適応的に行うことで、クラウドシステムのサービスエリア内の任意の２点間で量子暗号通信を行う両ユーザに対して、両者が共有すべき量子鍵を供給することを実現している。量子鍵の中継を量子暗号通信で行うことで、当該量子鍵の保護も図っている。以下、ユーザに提供する量子鍵をＧ鍵（Ｇｌｏｂａｌ ｋｅｙ）と称することがあり、Ｇ鍵の暗号化のための量子鍵をＱ鍵（Ｑｕａｎｔｕｍ ｋｅｙ）と称することがある。

ここで、図２を参照して、第１比較例について説明する。第１比較例は、ＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってユーザへ量子鍵を提供する量子暗号通信システムである。図２中、二重線の枠は、物理的にセキュリティが確保された拠点であることを表している。

暗号アプリなどの暗号化処理を行う主体（ｍａｓｔｅｒ ＳＡＥ［Ｓｅｃｕｒｅ Ａｐｐｌｉｃａｔｉｏｎ Ｅｎｔｉｔｙ］）は、復号アプリなどの復号処理を行う主体（ｓｌａｖｅ ＳＡＥ）の識別子（ｓｌａｖｅ ＳＡＥ ＩＤ）をパラメータ等として含む量子鍵の要求を、自拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０に対して鍵提供ＡＰＩによって送信する（１）。この要求を受信した量子鍵流通システム２０は、量子鍵（Ｇ鍵）と、量子鍵の識別子（鍵ＩＤ）とをｍａｓｔｅｒ ＳＡＥに送信する（２）。

ｍａｓｔｅｒ ＳＡＥは、量子鍵流通システム２０から受け取った量子鍵でデータを暗号化し（３）、ｓｌａｖｅ ＳＡＥに対して、暗号データと、その暗号データの暗号化に用いた量子鍵の鍵ＩＤとを送信する（４）。

一方、ｓｌａｖｅ ＳＡＥは、ｍａｓｔｅｒ ＳＡＥの識別子（ｍａｓｔｅｒ ＳＡＥ ＩＤ）と、ｍａｓｔｅｒ ＳＡＥから受信した鍵ＩＤとをパラメータ等として含む量子鍵の要求を、自拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０に対して鍵提供ＡＰＩによって送信する（５）。この要求を受信した量子鍵流通システム２０は、鍵ＩＤで示される量子鍵（Ｇ鍵）をｓｌａｖｅ ＳＡＥに送信する（６）。

ｓｌａｖｅ ＳＡＥは、量子鍵流通システム２０から受け取った量子鍵を用いて、ｍａｓｔｅｒ ＳＡＥから受信した暗号データを復号する（７）。

ここでは、ｍａｓｔｅｒ ＳＡＥの拠点とｓｌａｖｅ ＳＡＥの拠点との間に１つの中継拠点が介在しているものと想定する。ｍａｓｔｅｒ ＳＡＥの拠点の量子鍵配送システム（量子鍵配送システム_Ａ）３０は、中継拠点の量子鍵配送システム（量子鍵配送システム_Ｂ）３０との間でＱ鍵（Ｑ鍵_ＡＢ）の共有化を実行する。また、ｓｌａｖｅ ＳＡＥの拠点の量子鍵配送システム（量子鍵配送システム_Ｄ）３０は、中継拠点の量子鍵配送システム（量子鍵配送システム_Ｃ）３０との間でＱ鍵（Ｑ鍵_ＣＤ）の共有化を実行する。

ｍａｓｔｅｒ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０は、中継拠点との間で共有化されているＱ鍵（Ｑ鍵_ＡＢ）を用いて、ｍａｓｔｅｒ ＳＡＥに提供した量子鍵（Ｇ鍵）を暗号化し、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０に送信する。なお、ｍａｓｔｅｒ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０は、パラメータ等として受け取ったｓｌａｖｅ ＳＡＥ ＩＤに基づき、ｓｌａｖｅ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０を認識し、その上で、量子鍵（Ｇ鍵）の直接的な送信先として、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０を特定する。

中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０は、Ｑ鍵（Ｑ鍵_ＡＢ）を用いて、ｍａｓｔｅｒ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０から受信した、暗号化された状態の量子鍵（Ｇ鍵）を復号する。そして、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０は、ｓｌａｖｅ ＳＡＥの拠点との間で共有化されているＱ鍵（Ｑ鍵_ＣＤ）を用いて、量子鍵（Ｇ鍵）を再暗号化し、ｓｌａｖｅ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０に送信する。中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０は、ｍａｓｔｅｒ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０によって設定された量子鍵（Ｇ鍵）の宛先情報に基づき、ｓｌａｖｅ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０へ量子鍵（Ｇ鍵）を送信すべきことを認識する。

ｓｌａｖｅ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０は、Ｑ鍵（Ｑ鍵_ＣＤ）を用いて、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０から受信した、暗号化された状態の量子鍵（Ｇ鍵）を復号する。そして、ｓｌａｖｅ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｚ）２０は、パラメータ等として受け取ったｍａｓｔｅｒ ＳＡＥ ＩＤで示されるｍａｓｔｅｒ ＳＡＥの拠点の量子鍵流通システム（量子鍵流通システム_Ｘ）２０との間で共有化されている量子鍵（Ｇ鍵）であって、同じくパラメータ等として受け取った鍵ＩＤで示される量子鍵（Ｇ鍵）を、ｓｌａｖｅ ＳＡＥに供給する。

この第１比較例の、ＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩを適用した量子暗号通信システムでは、ユーザが、鍵提供ＡＰＩに対応したアプリケーション（暗号アプリや復号アプリ）を使用する必要がある。

続いて、図３から図５を参照して、第２比較例について説明する。第２比較例は、既存の非量子鍵の暗号鍵管理サービス（クラウド鍵管理サービス）を提供するクラウドシステムである。

クラウド鍵管理サービスでは、一般的に、鍵管理システム１０を介した鍵の共有が、エンベローブ暗号化を利用して行われる。図３は、エンベローブ暗号化を説明するための図である。

エンベローブ暗号化は、暗号鍵をさらに別の鍵で暗号化することである。データの暗号化・復号に用いられる鍵は、データキーなどと称される。また、データキーの暗号化・復号に用いられる鍵は、マスターキーなどと称される。鍵管理システム１０は、マスターキーを保存・管理する機能を有する。鍵管理システム１０は、マスターキーによって暗号化が施されるデータキーの保存・管理は行わない。

図３（Ａ）は、エンベローブ暗号化を利用する鍵管理システム１０におけるデータキーの暗号化の概要を示している。

鍵管理システム１０は、たとえば暗号通信を行う送信側ユーザと受信側ユーザとのうちの送信側ユーザからの要求に応じて、データの暗号化に用いるデータキーをマスターキーによって暗号化する。たとえば暗号通信を行う送信側ユーザと受信側ユーザとは、鍵管理システム１０によって暗号化されたデータキー（暗号化済みデータキー）を、当該データキーによって暗号化したデータと共に共有する。なお、送信側ユーザと受信側ユーザとによるデータの共有は、暗号通信に限らず、たとえば記憶装置を介して授受するものであってもよい。

図３（Ｂ）は、エンベローブ暗号化を利用する鍵管理システム１０における暗号化済みデータキーの復号の概要を示している。

鍵管理システム１０は、たとえば暗号通信を行う送信側ユーザと受信側ユーザとのうちの受信側ユーザからの要求に応じて、暗号化済みデータキーをマスターキーによって復号する。受信側ユーザは、鍵管理システム１０によって復号されたデータキーを用いて、当該データキーによって暗号化したデータ（暗号データ）を復号する。

図４は、エンベローブ暗号化を利用する鍵管理システム１０が提供するクラウド鍵管理サービスの概要を示す図である。

鍵管理システム１０は、マスターキー（ＣＭＳ：Ｃｕｓｔｏｍｅｒ Ｍａｓｔｅｒ ｋｅｙ）を管理するにあたり、各マスターキーについてアクセスポリシーを設定する。このアクセスポリシーは、たとえば、特定のグループに属するユーザにアクセス権限を付与するといったものであってもよいし、特定のユーザにアクセス権限を付与するといったものであってもよい。あるいは、特定の属性を持つユーザにアクセス権限を付与するといったものであってもよい。

たとえば、あるマスターキーのアクセスポリシーが、あるグループに属するユーザにアクセス権限を付与するといったものであった場合、そのグループに属する各ユーザは、そのマスターキーを介して、当該グループに属する他のユーザとの間でデータを安全に共有することができる。

図５は、エンベローブ暗号化を利用する鍵管理システム１０が提供するクラウド鍵管理サービスの一利用様態例を示す図である。ここでは、あるマスターキーのアクセス権限を持つユーザＡとユーザＢとが記憶装置を介してデータを共有する場合を想定する。

たとえばユーザＡは、鍵管理システム１０に対して、自身がアクセス権限を持つマスターキー（ＣＭＫ）を指定して、データキーの暗号化を要求する（１）。この要求を受けた鍵管理システム１０は、データキーの生成を行い（２）、かつ、指定されたマスターキーによる当該データキーの暗号化を行う（３）。そして、鍵管理システム１０は、データキーと暗号化済みデータキーとをユーザＡに提供する（４）。前述したように、鍵管理システム１０は、データキーの保存・管理は行わない。

ユーザＡは、鍵管理システム１０から受け取ったデータキーを用いて、ユーザＢと共有するデータ（平文）を暗号化する（５）、ユーザＡは、暗号データと暗号化済みデータキーとを記憶装置に保存する（６）。

一方、ユーザＢは、暗号化済みデータキーを記憶装置から取得し（１１）、鍵管理システム１０へ送信する（１２）。鍵管理システム１０は、ユーザＢがアクセス権限を持つマスターキーを用いて、暗号化済みデータキーの復号を行い（１３）、得られたデータキーをユーザＢに提供する（１４）。

ユーザＢは、鍵管理システム１０から受け取ったデータキーを用いて、記憶装置に保存されている暗号データの復号を行う（１５）。

記憶装置に保存されている暗号化済みデータキーは、当該暗号化済みデータキーの暗号化に用いられたマスターキーのアクセス権限を持つユーザのみが復号でき、かつ、データキーは鍵管理システム１０にも存在しないので、マスターキーのアクセス権限を持つユーザ間でのデータの安全な共有が実現される。

また、図６は、クラウド鍵管理サービスを含む各種サービスを提供するクラウドシステムによるサービスエリアの一形成例を示す図である。

クラウドシステムは、たとえば、ゾーンｂ１、リージョンｂ２、グローバルｂ３といった多階層のサービスエリアを設定する。ゾーンｂ１は、各種サービスの提供拠点となる１以上のデータセンタ１００によって形成され、当該ゾーンｂ１を形成する１以上のデータセンタ１００によってゾーンサービスｂ１１が提供される。

リージョンｂ２は、複数のゾーンｂ１を含む、ゾーンｂ１の上位層のサービスエリアである。リージョンｂ２では、当該リージョンｂ２配下の複数のデータセンタ１００によってリージョンサービスｂ１２が提供される。さらに、グローバルｂ３は、複数のリージョンｂ２を含む、リージョンｂ２の上位層のサービスエリアである。グローバルｂ３では、当該グローバルｂ３配下の複数のデータセンタ１００によってグローバルサービスｂ１３が提供される。

つまり、クラウドシステムでは、ゾーンサービスｂ１１、リージョンサービスｂ１２およびグローバルサービスｂ１３の提供拠点が、データセンタ１００の論理的な集合体であるゾーンｂ１、リージョンｂ２およびグローバルｂ３として表現される。たとえば、第１ゾーンｂ１におけるゾーンサービスｂ１１の提供は、現実的には、当該第１ゾーンｂ１配下のいずれかのデータセンタ１００が拠点となって行われるが、その拠点は第１ゾーンとして抽象化される。リージョンサービスｂ１２およびグローバルサービスｂ１３も同様である。

以上の第１比較例および第２比較例を踏まえて、次に、図７を参照して、実施形態の基盤システム１が、サービスの提供拠点が各サービスエリアを形成するデータセンタの論理的な集合体で表現されるクラウドシステムに対して、２拠点間で量子鍵を共有する量子鍵配送を適用する一例について説明する。

実施形態の基盤システム１では、Ｇ鍵を共有する最小単位をリージョンｂ２とする。基盤システム１は、（１）リージョンｂ２間でのＧ鍵の共有のための量子鍵配送、（２）各リージョンｂ２配下のデータセンタ１００間でのＧ鍵のレプリケーションのための量子鍵配送、（３）ユーザと当該ユーザが属するリージョンｂ２配下のデータセンタ１００間でのＧ鍵の授受のための量子鍵配送、の３種類の量子鍵配送をクラウドシステム上にマッピングする。

（２）のＧ鍵のレプリケーションは、各リージョンｂ２内のデータセンタ１００が協働してＧ鍵の一貫性を保つための処理を行うことである。このＧ鍵のレプリケーションによって、Ｇ鍵をサービスエリア内でプール化することにより、たとえば第１リージョンｂ２と第２リージョンｂ２との間で量子暗号通信を並列に行っている複数組のユーザの各組に対して、当該第１リージョンｂ２と第２リージョンｂ２との間で共有化されたＧ鍵を重複なく割り振って供給することが可能となる。また、このＧ鍵のレプリケーションによって、２つのリージョンｂ２間でのＧ鍵の共有化を、その時々で変化する需要量に応じて適応的に行うことが可能となる。

（３）の量子鍵配送について、ユーザは、あるデータセンタ１００との間で光ファイバの敷設などが必要となるが、当該ユーザが多数の他のユーザとの間で量子鍵配送を行う場合、本来、当該多数の他のユーザ間の各々について光ファイバの敷設などが必要となるところ、１つのデータセンタ１００との間の光ファイバの敷設などで済む。たとえばＮ箇所の拠点を有する企業などにおいて、当該Ｎ箇所の拠点間で量子鍵配送を行うための設備を独自に構築するとした場合、（Ｎ×（Ｎ－１）／２）個の組み合わせの２拠点間すべてについて光ファイバの敷設などが必要となるが、各拠点からデータセンタ１００までのＮ個の光ファイバの敷設などで済む。

以上の３種類の量子鍵配送をクラウドシステム上にマッピングすることで、実施形態の基盤システム１は、任意の２拠点で量子暗号通信を行う両ユーザのそれぞれに対して、各ユーザが属するリージョンｂ２配下のデータセンタ１００から、当該両ユーザが共有すべき量子鍵を提供することを可能とする。

さらに、実施形態の基盤システム１は、ユーザが、自身が属するリージョンｂ２（より詳しくは、当該リージョンｂ２配下のいずれかのデータセンタ１００）から量子鍵の提供を受けるためのインターフェースとして、エンベローブ暗号化におけるマスターキーの指定といった既存のインターフェースに準じた拡張インターフェースを採用する。拡張インターフェースの例としては、パラメータの流用や追加などが挙げられる。

具体的には、鍵管理システム１０は、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩで授受される情報を、エンベローブ暗号化のためのインターフェースで授受される情報に当て嵌める。鍵管理システム１０は、ユーザとの間のエンベローブ暗号化のためのインターフェースを、量子鍵流通システム２０との間のたとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩに変換し、また、量子鍵流通システム２０との間のたとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩを、ユーザとの間のエンベローブ暗号化のためのインターフェースに変換することを内部的に実行する。

この拡張インターフェースの採用によって、ユーザは、既存の非量子鍵の暗号鍵管理サービスと同じ感覚で量子鍵を取得することができ、たとえば量子鍵流通システム２０から量子鍵を取得するためのＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩなどをユーザが持つことを不要とすることができる。

図８は、実施形態の基盤システム１のシステム全体の機能ブロックの一例を示す図である。

前述したように、クラウドシステムは、ゾーンｂ１、リージョンｂ２およびグローバルｂ３といった多階層のサービスエリアを設定する。各ゾーンｂ１は、１以上のデータセンタ１００によって形成される。各リージョンｂ２は、複数のゾーンｂ１によって形成される。基盤システム１は、このリージョンｂ２を、Ｇ鍵を共有する最小単位とする。そのために、基盤システム１は、２つのリージョンｂ２間に量子暗号通信のための１以上の中継拠点を設けている。中継拠点は、量子鍵流通システム２０と量子鍵配送システム３０とを有する。なお、近距離のリージョンｂ２間では、中継拠点を設けず、直接的に量子暗号通信を行うことも可能である。

また、前述したように、各データセンタ１００は、鍵管理システム１０と、量子鍵流通システム２０と、量子鍵配送システム３０とを有する。各データセンタ１００の量子鍵流通システム２０は、同一ゾーンｂ１内の隣接する他のデータセンタ１００の量子鍵流通システム２０と古典通信網（ｃ１）で接続されている。古典通信網とは、光子による暗号鍵情報に特化していない一般的なデータを送受信するための通信網である。各データセンタ１００の量子鍵配送システム３０は、同一ゾーンｂ１内の隣接する他のデータセンタ１００の量子鍵配送システム３０と量子通信網（ｃ２）で接続されている。量子通信網とは、光子による量子鍵情報の送受信のための通信網である。

また、各ゾーンｂ１のいくつかのデータセンタ１００の量子鍵流通システム２０および量子鍵配送システム３０は、同一リージョンｂ２内の他のゾーンｂ１のデータセンタ１００の量子鍵流通システム２０および量子鍵配送システム３０と接続されている。

さらに、各リージョンｂ２のいくつかのデータセンタ１００の量子鍵流通システム２０および量子鍵配送システム３０は、他のリージョンｂ２との間に介在する中継拠点の量子鍵流通システム２０および量子鍵配送システム３０と接続されている。

つまり、実施形態の基盤システム１は、リージョンｂ２内においてＧ鍵のレプリケーションを行うことができ、かつ、リージョンｂ２間においてＧ鍵の共有化を行うことができる通信網（ｃ１、ｃ２）を有している。

図９は、データセンタ１００の機能ブロックの一例を示す図である。図２と同様、二重線の枠は、物理的にセキュリティが確保された拠点であることを表している。

前述したように、データセンタ１００は、鍵管理システム１０と、量子鍵流通システム２０と、量子鍵配送システム３０とを有する。

たとえば、あるデータセンタ１００が、Ｎ個の他のデータセンタ（隣接ノード）１００と接続されているものとする。隣接ノードの中には、同一ゾーンｂ１内の他のデータセンタ１００だけでなく、同一リージョンｂ２内の他のゾーンｂ１のデータセンタ１００が含まれ得るし、他のリージョンｂ２との間に介在する中継拠点が含まれ得る。

量子鍵配送システム３０は、Ｎ個の隣接ノードの量子鍵配送システム３０のそれぞれと協働して、各隣接ノードとの間で共有化されたＱ鍵を生成する。つまり、データセンタ１００内には、隣接ノード分のＱ鍵が蓄えられている。

量子鍵流通システム２０は、量子鍵配送システム３０からＱ鍵の供給を受けて、隣接ノードの量子鍵流通システム２０との間でＧ鍵を送受信するための量子暗号通信を行う。具体的には、量子鍵流通システム２０は、Ｇ鍵をＱ鍵で暗号化して送信し、または、暗号化された状態のＧ鍵を受信してＱ鍵で復号する。この量子鍵流通システム２０によるＧ鍵の送受信は、異なるリージョンｂ２間でのＧ鍵の共有化のために実行され得るし、同一のリージョンｂ２内でのＧ鍵のレプリケーションのために実行され得る。

前述したように、基盤システム１は、Ｇ鍵を共有する最小単位をリージョンｂ２としている。各リージョンｂ２内には、同一のリージョンｂ２に属する他のユーザとの間で量子暗号通信を行うユーザへ提供するＧ鍵と、異なるリージョンｂ２に属する他のユーザとの間で量子暗号通信を行うユーザへ提供するＧ鍵との、（自リージョンｂ２を含む）各リージョンｂ２分のＧ鍵が蓄えられる。各リージョンｂ２内で蓄えられるＧ鍵は、一貫性が保たれるのであれば、各リージョンｂ２内の複数のデータセンタ１００によってどのように保持されるのかは問わない。たとえば、各データセンタ１００がすべて（複製）を保持してもよいし、データセンタ１００間で分散して保持してもよい。一貫性を保つためのＧ鍵のレプリケーションの手法は、特定の手法に限らず、様々な手法を適用し得る。

鍵管理システム１０は、たとえば、あるリージョンｂ２に属する他のユーザと量子暗号通信を行うユーザからのＧ鍵の要求を、既存の非量子鍵の暗号鍵管理サービスのインターフェースに準じた拡張インターフェースで受け付け、当該あるリージョンｂ２との間で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによって量子鍵流通システム２０から取得して、当該ユーザに供給する。つまり、鍵管理システム１０は、クラウドサービスとして、量子鍵を提供するサービスを提供する。ユーザとの間のＧ鍵の送受信も量子暗号通信で行われるが、ここでは、ユーザとの間の量子暗号通信の説明は省略する。なお、鍵管理システム１０は、既存の非量子鍵の暗号鍵管理サービスも継続して提供する。よって、ユーザは、たとえばデータの機密レベルに応じて、暗号通信方法を選択する等が可能である。

図１０は、量子鍵流通システム２０の機能ブロックの一例を示す図である。二重線の枠は、ここでも、物理的にセキュリティが確保された拠点であることを表している。

量子鍵流通システム２０は、乱数生成装置２１と、暗号化装置２２と、復号装置２３と、鍵提供ＡＰＩ２４とを有する。なお、データセンタ（リージョン＃１）１００側の量子鍵流通システム２０には復号装置２３が示されておらず、一方、データセンタ（リージョン＃２）１００側の量子鍵流通システム２０には乱数生成装置２１および暗号化装置２２が示されていないが、これらは、説明を分かり易くするために、便宜的に不図示としたものである。

たとえば、リージョン（＃１）ｂ２のデータセンタ１００で稼働する量子鍵流通システム（量子鍵流通システム_Ｘ）２０の乱数生成装置２１は、リージョン（＃２）ｂ２のデータセンタ１００との間で共有すべきＧ鍵を生成する。暗号化装置２２は、リージョン（＃１）ｂ２のデータセンタ１００とリージョン（＃１）ｂ２のデータセンタ１００との間に介在する中継拠点との間で共有されるＱ鍵（Ｑ鍵_ＡＢ）の供給を量子鍵配送システム３０から受け、当該Ｑ鍵（Ｑ鍵_ＡＢ）でＧ鍵を暗号化する。量子鍵流通システム２０は、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０に対して、暗号化したＧ鍵を送信する。

一方、中継拠点の量子鍵流通システム（量子鍵流通システム_Ｙ）２０では、復号装置２３が、リージョン（＃１）ｂ２のデータセンタ１００との間で共有されるＱ鍵（Ｑ鍵_ＡＢ）の供給を量子鍵配送システム３０から受け、一旦、当該Ｑ鍵（Ｑ鍵_ＡＢ）で、暗号化されているＧ鍵を復号する。続いて、暗号化装置２２が、リージョン（＃２）ｂ２のデータセンタ１００との間で共有されるＱ鍵（Ｑ鍵_ＢＣ）の供給を量子鍵配送システム３０から受け、当該Ｑ鍵（Ｑ鍵_ＢＣ）でＧ鍵を再暗号化する。量子鍵流通システム２０は、リージョン（＃２）ｂ２のデータセンタ１００の量子鍵流通システム（量子鍵流通システム_Ｚ）２０に対して、再暗号化したＧ鍵を送信する。

リージョン（＃２）ｂ２のデータセンタ１００で稼働する量子鍵流通システム（量子鍵流通システム_Ｚ）２０では、復号装置２３が、中継拠点との間で共有されるＱ鍵（Ｑ鍵_ＢＣ）の供給を量子鍵配送システム３０から受け、当該Ｑ鍵（Ｑ鍵_ＢＣ）で、暗号化されているＧ鍵を復号する。

そして、量子鍵流通システム（量子鍵流通システム_Ｘ）２０および量子鍵流通システム（量子鍵流通システム_Ｘ）２０の鍵提供ＡＰＩ２４は、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによる鍵管理システム１０からの要求に応じて、以上のような手順で共有化を行ったＧ鍵を鍵管理システム１０に提供する。

図１１は、量子鍵配送システム３０の機能ブロックの一例を示す図である。二重線の枠は、ここでも、物理的にセキュリティが確保された拠点であることを表している。

量子鍵配送システム３０は、乱数生成装置３１と、送信機３２と、受信機３３と、鍵蒸留装置３４とを有する。なお、左側の量子鍵配送システム３０には受信機３３が示されておらず、一方、右側の量子鍵配送システム３０には乱数生成装置３１および送信機３２が示されていないが、これらは、説明を分かり易くするために、便宜的に不図示としたものである。

乱数生成装置３１は、他のデータセンタ１００または中継拠点の量子鍵配送システム３０との間で送受信する乱数列（暗号鍵情報）を生成する。送信機３２は、乱数生成装置３１が生成する乱数列を量子通信網（ｃ２）経由で他のデータセンタ１００または中継拠点の量子鍵配送システム３０に送信する。一方、受信機３３は、他のデータセンタ１００または中継拠点の量子鍵配送システム３０から量子通信網（ｃ２）経由で送られてくる乱数列を受信する。

鍵蒸留装置３４は、乱数列の送信側と受信側とが協働して、当該乱数列の中の盗聴の可能性のある部分を取り除く秘匿性増強処理を実行する。送信側と受信側との間で送受信された乱数列の中の不適切部分が鍵蒸留装置３４によって除去された乱数列が、当該送信側と受信側との間で共有されるＱ鍵として双方で蓄えられる。

図１２は、実施形態の基盤システム１における、ユーザが量子鍵の提供を含む量子暗号通信サービスの利用を開始する場合の動作の流れを示すフローチャートである。なお、図１２の「クラウドＫＭＳ」とは、ある１つのリージョンｂ２内の複数のデータセンタ１００の鍵管理システム１０の論理的な集合体である。換言すれば、「クラウドＫＭＳ」の実体は、ある１つのリージョンｂ２内の複数のデータセンタ１００に分散配置されている。

量子暗号通信サービスの利用を開始するユーザは、自身が属するリージョンｂ２（より詳しくは、当該リージョンｂ２配下のいずれかのデータセンタ１００）の鍵管理システム１０に対して、マスターキーの作成を要求する（Ｓ１０１）。このとき、ユーザは、属性情報として宛先リージョンｂ２を入力する（Ｓ１０２）。宛先リージョンｂ２は、通信相手のユーザが属するリージョンｂ２である。さらに、ユーザは、当該マスターキーについてのアクセスポリシーの定義等を必要に応じて入力する（Ｓ１０３）。

一方、ユーザからの要求を受け付けた当該リージョンｂ２の鍵管理システム１０は、ユーザから入力された情報に基づき、マスターキーを作成する（Ｓ１０４）。当該リージョンｂ２の鍵管理システム１０は、宛先リージョンｂ２の鍵管理システム１０に対して、同一のマスターキーの作成を指示する。この指示を受けた宛先リージョンｂ２の鍵管理システム１０は、同一のマスターキーを作成する（Ｓ１０５）。当該リージョンｂ２の鍵管理システム１０は、作成したマスターキーのＩＤをユーザへ送信する（Ｓ１０６）。

図１３は、実施形態の基盤システム１における、ユーザが量子鍵を用いた暗号化を行う場合の動作の流れを示すフローチャートである。図１３の「クラウドＫＭＳ」は、前述の「クラウドＫＭＳ」と同様である。また、図１３の「ＱＫＤシステム」は、ある１つのリージョンｂ２内の複数のデータセンタ１００のＱＫＤシステム（量子鍵流通システム２０および量子鍵配送システム３０）の論理的な集合体である。換言すれば、「ＱＫＤシステム」の実体は、ある１つのリージョンｂ２内の複数のデータセンタ１００に分散配置されている。

ユーザは、自身が属するリージョンｂ２（より詳しくは、当該リージョンｂ２配下のいずれかのデータセンタ１００）の鍵管理システム１０に対して、データの暗号化に用いるデータキーを要求する（Ｓ２０１）。このとき、ユーザは、量子暗号通信サービスの利用開始時に入手したマスターキーＩＤを入力する（Ｓ２０２）。このマスターキーＩＤの入力は、既存の非量子鍵の暗号鍵管理サービスのインターフェースに準じている。

鍵管理システム１０は、ユーザから受け取ったマスターキーＩＤに基づき、当該マスターキーＩＤで示されるマスターキーの属性情報、即ち宛先リージョンを参照する（Ｓ２０３）。鍵管理システム１０は、その宛先リージョン名を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩで用いられるＳＡＥ ＩＤに変換し（Ｓ２０４）、当該ＳＡＥ ＩＤを自リージョンｂ２（より詳しくは、自データセンタ１００）のＱＫＤシステム（量子鍵流通システム２０および量子鍵配送システム３０）へ送信する（Ｓ２０５）。

当該ＱＫＤシステムは、受信したＳＡＥ ＩＤに対応する目的のＱＫＤシステムを特定し（Ｓ２０６）、当該目的のＱＫＤシステムとの間で鍵共有を行う（Ｓ２０７）。これにより、宛先リージョンのＱＫＤシステムは、ユーザが属するリージョンｂ２のＱＫＤシステムとの間で共有化されたＧ鍵を蓄積する（Ｓ２０８）。なお、当該Ｇ鍵の蓄積は、自リージョンのＱＫＤシステムでも行われる。また、当該２つのリージョンのユーザによる量子鍵暗号は、複数並列に実行され得るので、各リージョン内でＧ鍵のレプリケーションが行われる。当該ＱＫＤシステム（自リージョンｂ２のＱＫＤシステム）は、宛先リージョンのＱＫＤシステムとの間で共有化されたＧ鍵と、当該Ｇ鍵のＩＤとを鍵管理システム１０に送信する（Ｓ２０９）。

鍵管理システム１０は、ＱＫＤシステムから受け取ったＧ鍵をデータキーとし、同じくＱＫＤシステムから受け取ったＧ鍵ＩＤを暗号化済みデータキーとして、当該Ｇ鍵およびＧ鍵ＩＤをユーザへ送信する（Ｓ２１０）。当該Ｇ鍵およびＧ鍵ＩＤの送信も、既存の非量子鍵の暗号鍵管理サービスのインターフェースに準じている。

ユーザは、鍵管理システム１０からデータキー（Ｇ鍵）と暗号化済みデータキー（Ｇ鍵ＩＤ）とを入手すると（Ｓ２１１）、当該データキーを用いてデータを暗号化し（Ｓ２１２）、暗号データ、マスターキーＩＤおよび暗号化済みデータキーを（たとえば量子暗号通信の相手である）他のユーザと共有する（Ｓ２１３）。

図１４は、実施形の基盤システム１における、ユーザが量子鍵を用いた暗号データの復号を行う場合の動作の流れを示すフローチャートである。図１４の「クラウドＫＭＳ」および「ＱＫＤシステム」は、前述の「クラウドＫＭＳ」および「ＱＫＤシステム」と同様である。

ユーザは、（たとえば量子暗号通信の相手である）他のユーザから暗号データ、マスターキーＩＤおよび暗号化済みデータキーを入手する（Ｓ３０１）。ユーザは、自身が属するリージョンｂ２（より詳しくは、当該リージョンｂ２配下のいずれかのデータセンタ１００）の鍵管理システム１０に対して、暗号データを復号するためのデータキーを要求する（Ｓ３０２）。このとき、ユーザは、暗号データと共に入手したマスターキーＩＤおよび暗号化済みデータキーを入力する（Ｓ３０３）。このマスターキーＩＤの入力は、既存の非量子鍵の暗号鍵管理サービスのインターフェースにパラメータを追加することで対応できる。

鍵管理システム１０は、ユーザから受け取ったマスターキーＩＤに基づき、当該マスターキーＩＤで示されるマスターキーの属性情報、即ち宛先リージョンを参照する（Ｓ３０４）。鍵管理システム１０は、その宛先リージョン名を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩで用いられるＳＡＥ ＩＤに変換し、かつ、ユーザから受け取った暗号化済みデータキーをＧ鍵ＩＤに変換する（Ｓ３０５）。鍵管理システム１０は、当該変換後のＳＡＥ ＩＤおよびＧ鍵ＩＤを自リージョンｂ２（より詳しくは、自データセンタ１００）のＱＫＤシステムへ送信する（Ｓ３０６）。

ＱＫＤシステムは、鍵管理システム１０から受け取ったＧ鍵ＩＤに対応するＧ鍵のデータを参照し（Ｓ３０７）、当該Ｇ鍵を鍵管理システム１０に送信する（Ｓ３０８）。鍵管理システム１０は、ＱＫＤシステムから受け取ったＧ鍵をデータキーとしてユーザへ送信する（Ｓ３０９）。このデータキーとしてのＧ鍵の送信は、既存の非量子鍵の暗号鍵管理サービスのインターフェースに準じている。

ユーザは、鍵管理システム１０からデータキー（Ｇ鍵）を入手すると（Ｓ３１０）、そのデータキーを用いて、暗号データの復号を実施する（Ｓ３１１）。

図１５は、実施形態の基盤システム１における、ユーザが量子鍵の提供を含む量子暗号通信サービスの利用を終了する場合の動作の流れを示すフローチャートである。図１５の「クラウドＫＭＳ」は、前述の「クラウドＫＭＳ」と同様である。

量子暗号通信サービスの利用を終了するユーザは、自身が属するリージョンｂ２（より詳しくは、当該リージョンｂ２配下のいずれかのデータセンタ１００）の鍵管理システム１０に対して、マスターキーの削除を要求する（Ｓ４０１）。このとき、ユーザは、マスターキーＩＤを入手する（Ｓ４０２）。

一方、ユーザからの要求を受け付けた当該リージョンｂ２の鍵管理システム１０は、マスターキーＩＤで示されるマスターキーを削除する（Ｓ４０３）。当該リージョンｂ２の鍵管理システム１０は、当該マスターキーに付随する属性情報で示される宛先リージョンｂ２の鍵管理システム１０に対して、同一のマスターキーの削除を指示する。この指示を受けた宛先リージョンｂ２の鍵管理システム１０は、同一のマスターキーを削除する（Ｓ４０５）。

以上のように、実施形態の基盤システム１は、（１）リージョンｂ２間でのＧ鍵の共有のための量子鍵配送、（２）各リージョンｂ２配下のデータセンタ１００間でのＧ鍵のレプリケーションのための量子鍵配送、（３）ユーザと当該ユーザが属するリージョンｂ２配下のデータセンタ１００間でのＧ鍵の授受のための量子鍵配送、の３種類の量子鍵配送をクラウドシステム上にマッピングし、かつ、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩで授受される情報を、エンベローブ暗号化のためのインターフェースで授受される情報に当て嵌めるための変換を内部的に行うことによって、既存の非量子鍵の暗号鍵管理サービスと同じ感覚で利用可能な量子鍵の提供を含む量子暗号通信サービスをクラウドシステム上で提供することができる。

次に、実施形態の基盤システム１において想定され得るいくつかのユースケースについて説明する。

図１６は、実施形態の基盤システム１の第１ユースケースを示す図である。第１ユースケースは、同一リージョンｂ２のクラウド上のアプリケーション（Ａｐｐ）同士が鍵管理システム１０で共有された量子鍵を取得するケースである。このケースは、たとえば、ユーザに対して、量子鍵の提供だけでなく、当該量子鍵を用いた通信（量子暗号通信）用の設備を提供する場合などが該当する。

送信側のアプリケーションは、誰に暗号データを送りたいか決定し、その相手に対応するマスターキーの作成を鍵管理システム１０に要求する（１）。あるいは、マスターキーが作成済みである場合、アプリケーションは、その相手に対応するマスターキーを選択する。マスターキーの作成時には、アプリケーションは、鍵種別（ｄ１）、アクセスポリシー、宛先リージョン（ｄ２）などを入力する。鍵種別（ｄ１）および宛先リージョン（ｄ２）は、既存のインターフェースからの拡張部分である。鍵種別は、たとえば量子鍵か否かを示す情報である。量子鍵を示す情報（ＱＫＤ）が入力された場合に、宛先リージョンが入力される。マスターキーに関する情報は、たとえばマスターキーメタデータとして鍵管理システム１０によって管理される。

送信側のアプリケーションは、暗号データを送る相手に対応するマスターキーを作成または選択すると、そのマスターキーＩＤを指定して、データキーの作成を鍵管理システム１０に要求する（２）。このとき、鍵管理システム１０は、マスターキーの作成時に入力されたアクセスポリシー等に基づき、アプリケーションの認証処理を実行する。

鍵管理システム１０は、宛先リージョンとの間（ここでは、同一リージョン内）で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステム（量子鍵流通システム２０および量子鍵配送システム３０）から取得する（３）。鍵管理システム１０は、当該取得したＧ鍵をデータキーとし、そのＧ鍵ＩＤを鍵情報として、Ｇ鍵およびＧ鍵ＩＤをアプリケーションへ送信する（４）。

送信側のアプリケーションは、鍵管理システム１０から供給されたＧ鍵を用いてデータを暗号化し、暗号化済みデータと、マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３）を含む鍵情報とを取得する（５）。鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。送信側のアプリケーションは、受信側のアプリケーションに対して、暗号データ（暗号化済みデータ）と、暗号化済みデータキー（Ｇ鍵ＩＤ）およびマスターキーＩＤとを送信し、これらを受信側のアプリケーションとの間で共有する（６）。

一方、受信側のアプリケーションは、送信側のアプリケーションから受け取った鍵情報（マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３））を指定して、データキーの復号を鍵管理システム１０に要求する（７）。前述したように、鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。このとき、鍵管理システム１０は、マスターキーの作成時に入力されたアクセスポリシー等に基づき、アプリケーションの認証処理を実行する。

鍵管理システム１０は、送信側のアプリケーションが属するリージョンとの間（ここでは、同一リージョン内）で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステムから取得する（８）。鍵管理システム１０は、当該取得したＧ鍵をデータキーとしてアプリケーションへ送信する（９）。受信側のアプリケーションは、鍵管理システム１０から供給されたＧ鍵を用いて、暗号データを復号する（１０）。

図１７は、実施形態の基盤システム１の第２ユースケースを示す図である。第２ユースケースは、量子鍵通信を行う、オンプレミスのサイトＡ、サイトＢのユーザ（アプリケーション）が、鍵管理システム１０で共有された量子鍵を同一リージョンｂ２から取得するケースである。

サイトＡのアプリケーションは、誰に暗号データを送りたいか決定し、その相手に対応するマスターキーの作成を鍵管理システム１０に要求する（１）。あるいは、マスターキーが作成済みである場合、アプリケーションは、その相手に対応するマスターキーを選択する。マスターキーの作成時には、アプリケーションは、鍵種別（ｄ１）、アクセスポリシー、宛先リージョン（ｄ２）などを入力する。前述したように、鍵種別（ｄ１）および宛先リージョン（ｄ２）は、既存のインターフェースからの拡張部分である。

サイトＡのアプリケーションは、暗号データを送る相手に対応するマスターキーを作成または選択すると、そのマスターキーＩＤと鍵の長さとを指定して、データキーの作成を鍵管理システム１０に要求する（２）。鍵の長さは、たとえば規定値と異なる長さのデータキーを要求する場合のオプションである。また、このとき、鍵管理システム１０は、マスターキーの作成時に入力されたアクセスポリシー等に基づき、アプリケーションの認証処理を実行する。

鍵管理システム１０は、宛先リージョンとの間（ここでは、同一リージョン内）で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステム（量子鍵流通システム２０および量子鍵配送システム３０）から取得する（３）。鍵管理システム１０は、当該取得したＧ鍵をデータキーとし、そのＧ鍵ＩＤを鍵情報として、Ｇ鍵およびＧ鍵ＩＤをサイトＡのアプリケーションへ送信する（４）。

サイトＡのアプリケーションは、鍵管理システム１０から供給されたＧ鍵を用いてデータを暗号化し、暗号化済みデータと、マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３）を含む鍵情報とを取得する（５）。前述したように、鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。サイトＡのアプリケーションは、サイトＢのアプリケーションに対して、暗号データ（暗号化済みデータ）と、暗号化済みデータキー（Ｇ鍵ＩＤ）およびマスターキーＩＤとを送信し、これらをサイトＢのアプリケーションとの間で共有する（６）。

一方、サイトＢのアプリケーションは、サイトＡのアプリケーションから受け取った鍵情報（マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３））を指定して、データキーの復号を鍵管理システム１０に要求する（７）。前述したように、鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。このとき、鍵管理システム１０は、マスターキーの作成時に入力されたアクセスポリシー等に基づき、アプリケーションの認証処理を実行する。

鍵管理システム１０は、サイトＡのアプリケーションが属するリージョンとの間（ここでは、同一リージョン内）で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステムから取得する（８）。鍵管理システム１０は、当該取得したＧ鍵をデータキーとしてサイトＢのアプリケーションへ送信する（９）。サイトＢのアプリケーションは、鍵管理システム１０から供給されたＧ鍵を用いて、暗号データを復号する（１０）。

図１８は、実施形態の基盤システム１の第３ユースケースを示す図である。第３ユースケースは、サイトＡ、サイトＢのアプリケーションが、鍵管理システム１０で共有された量子鍵を、それぞれ別リージョンｂ２（リージョンＡ、リージョンＢ）から取得するケースである。

サイトＡのアプリケーションは、誰に暗号データを送りたいか決定し、その相手に対応するマスターキーの作成をリージョンＡの鍵管理システム１０に要求する（１）。あるいは、マスターキーが作成済みである場合、サイトＡのアプリケーションは、その相手に対応するマスターキーを選択する。マスターキーの作成時には、サイトＡのアプリケーションは、鍵種別（ｄ１）、アクセスポリシー、宛先リージョン（ｄ２）などを入力する。前述したように、鍵種別（ｄ１）および宛先リージョン（ｄ２）は、既存のインターフェースからの拡張部分である。

サイトＡのアプリケーションは、暗号データを送る相手に対応するマスターキーを作成または選択すると、そのマスターキーＩＤを指定して、データキーの作成をサイトＡの鍵管理システム１０に要求する（２）。このとき、サイトＡの鍵管理システム１０は、マスターキーの作成時に入力されたアクセスポリシー等に基づき、アプリケーションの認証処理を実行する。

リージョンＡの鍵管理システム１０は、宛先リージョン（リージョンＢ）との間で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステム（量子鍵流通システム２０および量子鍵配送システム３０）から取得する（３）。リージョンＡの鍵管理システム１０は、当該取得したＧ鍵をデータキーとし、そのＧ鍵ＩＤを鍵情報として、Ｇ鍵およびＧ鍵ＩＤをサイトＡのアプリケーションへ送信する（４）。

サイトＡのアプリケーションは、リージョンＡの鍵管理システム１０から供給されたＧ鍵を用いてデータを暗号化し、暗号化済みデータと、マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３）を含む鍵情報とを取得する（５）。前述したように、鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。サイトＡのアプリケーションは、サイトＢのアプリケーションに対して、暗号データ（暗号化済みデータ）と、暗号化済みデータキー（Ｇ鍵ＩＤ）およびマスターキーＩＤとを送信し、これらをサイトＢのアプリケーションとの間で共有する（６）。

一方、サイトＢのアプリケーションは、サイトＡのアプリケーションから受け取った鍵情報（マスターキーＩＤおよびＧ鍵ＩＤ（ｄ３））を指定して、データキーの復号をリージョンＢの鍵管理システム１０に要求する（７）。前述したように、鍵情報中のＧ鍵ＩＤ（ｄ３）は、既存のインターフェースからの拡張部分である。このとき、リージョンＢの鍵管理システム１０は、リージョンＡの鍵管理システム１０が管理するマスターキー情報を確認し（８）、アクセスポリシー等に基づき、サイトＢのアプリケーションの認証処理を実行する。

リージョンＢの鍵管理システム１０は、サイトＡのアプリケーションが属するリージョン（リージョンＡ）との間で共有化されたＧ鍵を、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩによってＱＫＤシステムから取得する（９）。リージョンＢの鍵管理システム１０は、当該取得したＧ鍵をデータキーとしてサイトＢのアプリケーションへ送信する（１０）。サイトＢのアプリケーションは、鍵管理システム１０から供給されたＧ鍵を用いて、暗号データを復号する（１１）。

図１７および図１８から明らかなように、実施形態の基盤システム１では、量子暗号通信を行う双方のユーザが、同一リージョンから量子鍵を取得する場合と、それぞれ別リージョンから量子鍵を取得する場合とのいずれであっても、ユーザは同じ手続き（インターフェース）によって量子鍵を取得することができる。また、基盤システム１は、既存のインターフェースに準じた拡張インターフェースを採用するので、ユーザが、既存の非量子鍵の暗号鍵管理サービスと同じ感覚で量子鍵を取得することを可能とし、たとえばＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩなどを持つことを不要にできる。

つまり、実施形態の基盤システム１は、クラウドシステム上で量子鍵の提供を含む量子暗号通信サービスを提供することができる。

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

１…基盤システム、１０…鍵管理システム（ＫＭＳ）、２０…量子鍵流通システム、３０…量子鍵配送システム、１００…データセンタ。

Claims (5)

1. 非量子鍵の暗号鍵を管理するクラウド鍵管理サービスを含む各種サービスを提供するクラウドシステム上で前記クラウド鍵管理サービスのインターフェースに準じた拡張インターフェースによる量子鍵の提供を含む量子暗号通信サービスを提供するクラウド鍵管理サービス基盤システムであって、
   前記クラウドシステムは、前記量子暗号通信サービスの提供拠点となる複数のデータセンタを有し、前記複数のデータセンタによって、各々が１以上のデータセンタで形成される複数のサービスエリアを設定し、
   前記複数のデータセンタのそれぞれは、
   直接的に接続されている他のデータセンタとの間の量子暗号通信のための量子鍵であるＱ鍵を生成して前記他のデータセンタとの間で共有化する量子鍵配送システムと、
   量子暗号通信を行うユーザに提供する量子鍵であるＧ鍵を、前記他のデータセンタとの間で前記Ｑ鍵を用いた量子暗号通信によって送受信する量子鍵流通システムと、
   前記Ｇ鍵をサービスエリア単位で管理する鍵管理システムと、を具備し、
   前記鍵管理システムは、ユーザからの前記Ｇ鍵の要求を前記拡張インターフェースによって受け付け、量子鍵用の鍵提供ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）によって前記量子鍵流通システムから取得した前記Ｇ鍵を当該ユーザに提供し、
   第１サービスエリア内の各データセンタは、前記第１サービスエリア内の他のデータセンタと協働して、前記第１サービスエリア内の他のユーザとの間で量子暗号通信を行う前記第１サービスエリア内のユーザ向けの第１Ｇ鍵を生成し、または、前記第１サービスエリア内および前記第１サービスエリアと異なる第２サービスエリア内の他のデータセンタと協働して、前記第２サービスエリア内の他のユーザとの間で量子暗号通信を行う前記第１サービスエリア内のユーザ向けの第２Ｇ鍵を生成し、
   前記複数のサービスエリア内の任意の２点間で量子暗号通信を行う両ユーザに対して当該２点間で共有化された前記第１Ｇ鍵または前記第２Ｇ鍵を前記拡張インターフェースによって提供するクラウド鍵管理サービス基盤システム。
2. 前記第１サービスエリア内の各データセンタは、前記第１サービスエリア内の他のデータセンタと協働して、前記第１サービスエリア内での前記第１Ｇ鍵および前記第２Ｇ鍵のレプリケーションを実行する請求項１に記載のクラウド鍵管理サービス基盤システム。
3. 前記クラウド鍵管理サービスのインターフェースは、マスターキーの指定を含むエンベローブ暗号化のためのインターフェースであり、前記拡張インターフェースは、前記マスターキーの属性情報として少なくとも通信先のサービスエリアが追加されている請求項１または２に記載のクラウド鍵管理サービス基盤システム。
4. 前記拡張インターフェースは、前記エンベローブ暗号化でのデータキーとして前記Ｇ鍵が適用され、かつ、鍵情報として前記Ｇ鍵の識別子が適用される請求項３に記載のクラウド鍵管理サービス基盤システム。
5. 前記量子鍵用の鍵提供ＡＰＩは、ＥＴＳＩ ＧＳ ＱＫＤ ０１４準拠の鍵提供ＡＰＩである請求項１～４のいずれか１項に記載のクラウド鍵管理サービス基盤システム。

Images