JP2014060614A - 暗号化データ管理システム - Google Patents

Abstract

【課題】クラウドストレージ事業者に暗号化データを預ける場合において、クラウドストレージ事業者の内部不正により暗号化データが不正に復号されることを防ぐ。
【解決手段】暗号化データ管理システムは、データ３０１を暗号化した暗号化データ３０３をデータ保管サーバに預けることに加え、暗号鍵３０２を複数の鍵断片３０４に分割してデータ保管サーバと鍵管理サーバに配布し、データ保管サーバが保持する鍵断片のみ、または鍵管理サーバが保持する鍵断片のみでは、暗号鍵３０２が復元できないようにする。
【選択図】図３

Description

本発明は、暗号化データを管理するシステムに関する。

近年、スマートフォンやタブレット端末に代表されるスマートデバイスが普及してきている。また、クラウドコンピューティングの普及によりクラウド上にストレージサービスを提供するサービス事業者も増加している。このような背景を受けて、従来は企業内でＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等を用いて業務を行なっていたが、今後は業務データをクラウドストレージに保存し、出先からスマートデバイスを用いて業務データを参照するなど、場所を問わない業務形態が増加すると考えられる。

しかし、クラウドストレージに保存されたデータは平文で扱われるため、クラウドストレージから企業の知的財産に関わる情報が漏洩する可能性がある。また、クラウドストレージを提供する事業者の内部不正により業務データが暴露されてしまう可能性もある。

上記リスクを回避するため、利用者があらかじめデータを暗号化し、暗号化データをクラウドストレージに格納する方法が考えられる。この場合、暗号化に利用する暗号鍵を利用者側で用意すれば、クラウドストレージから暗号化データが漏洩したとしても、復号鍵がなければ復号できないため、情報漏洩対策となる。しかし、この方法は暗号鍵を利用者側で管理する必要があり、運用・管理コストが増え、情報管理部門その他の社員の負担が大きい。

暗号鍵のみを管理する鍵管理サービスを提供する事業者を利用すれば、上記の運用・管理コストの問題は解決できる。しかし、復号鍵を事業者が持つことになるため、事業者の内部不正による暴露の可能性が残ってしまう。

下記非特許文献１には、いわゆる（ｋ，ｎ）閾値秘密分散技術が開示されている。同技術においては、暗号鍵を用いず、データをｎ個の断片に分散する。ｎ個の断片のうちｋ個（ｋ≦ｎ）未満の断片からは元のデータを復元することができず、ｋ個以上の断片からのみ元のデータを復元できる。

Ronald L. Rivest and Adi Shamir and Yael Tauman, "How to share a secret", Communications of the ACM, vol.22(11), pp.612-613, 1979.

クラウドストレージ上に保存するデータを、非特許文献１に記載されている秘密分散技術によって分散管理することにより、事業者の内部不正を抑制することが考えられる。しかしこの手法は、以下の点において課題があると考えられる。

非特許文献１に記載されている技術をクラウドストレージに適用するに際して、クラウドストレージ事業者が有する複数のデータ保管サーバを利用して（ｋ，ｎ）閾値秘密分散技術を用いたとしても、各サーバが同じ事業者に属する以上は当該事業者が元のデータを復元できるため、事業者の内部不正を確実に防ぐことはできない。したがって、利用者は複数の異なったクラウドストレージ事業者を選択する必要がある。一般に各クラウドストレージ事業者が提供する機能はそれぞれ異なっているため、異なるクラウドストレージ事業者にデータを分散保存すると、利用者の利便性が悪い。

本発明は、上記のような課題に鑑みてなされたものであり、クラウドストレージ事業者に暗号化データを預ける場合において、クラウドストレージ事業者の内部不正により暗号化データが不正に復号されることを防ぐことを目的とする。

本発明に係る暗号化データ管理システムは、復号鍵を複数の鍵断片に分割してデータ保管サーバと鍵管理サーバに配布し、データ保管サーバが保持する鍵断片のみ、または鍵管理サーバが保持する鍵断片のみでは、復号化を実施できないようにする。

本発明に係る暗号化データ管理システムによれば、クラウドストレージ事業者の内部不正により暗号化データが不正に復号されることを防ぐことができる。

本発明に係る暗号化データ管理システム１００の構成図である。 クライアント端末１１０の機能ブロック図である。 クライアント端末１１０がデータ３０１を暗号化して各サーバに配布する手順を説明する図である。 クライアント端末１１０がデータ３０１を暗号化する手順を説明するフローチャートである。 クライアント端末１１０が暗号鍵断片３０４と暗号化データ断片３０５を用いてデータ３０１を復元する手順を説明するフローチャートである。

以下、図面に基づいて、本発明の実施形態を説明する。なお、本発明の実施態様は、後述する実施形態に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。また、実施形態を説明するための全図において、同一の機能を有する部材には同一または関連する符号を付し、その繰り返しの説明は省略する。

＜システム構成＞
図１は、本発明に係る暗号化データ管理システム１００の構成図である。暗号化データ管理システム１００は、暗号化されたデータを管理するシステムであり、クライアント端末１１０、鍵管理サーバ１２０、データ保管サーバ１３０を有する。これら機器の個数は１つ以上であれば任意でよい。

クライアント端末１１０は、ネットワーク１４０を介して、鍵管理サーバ１２０とデータ保管サーバ１３０に接続されている。ネットワーク１４０は、これら機器の間で情報通信することができれば任意の形態でよく、例えば有線もしくは無線のいずれか一方、または両方を用いて構成される。

鍵管理サーバ１２０は、クライアント端末１１０がデータを復号化する際に用いる復号鍵を管理する。以下では説明の簡易のため、暗号鍵と復号鍵が同一であるものとする。データ保管サーバ１３０は、クライアント端末１１０が暗号化したデータを保管する。鍵管理サーバ１２０は鍵管理事業者が管轄するネットワーク内に属し、データ保管サーバ１３０はクラウドストレージ事業者が管轄するネットワークに属する。

＜クライアント端末１１０の構成＞
図２は、クライアント端末１１０の機能ブロック図である。クライアント端末１１０は、暗号処理部１１１、分散処理部１１２、復元処理部１１３、データ通信部１１４を備える。暗号処理部１１１は、データの暗号化または復号化を実施する。分散処理部１１２は、暗号鍵と暗号化データを複数のデータ断片に分割する。分割処理の詳細については後述する。復元処理部１１３は、分割されたデータ断片から暗号鍵と暗号化データを復元する。データ通信部１１４は、他の装置と通信する。

クライアント端末１１０は、例えば企業内で使用するＰＣ、スマートフォン、タブレット端末などを用いて構成することができるが、これらに限定されない。また、クライアント端末１１０は、図２には示していないが、業務端末が備える一般的な機能が必要に応じて搭載されている。例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、フラッシュＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ハードディスク装置、ディスプレイ、入力指示装置（タッチパネル）、マウス、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）受信装置、ネットワークインタフェースカード、Ｗｉ−Ｆｉ（登録商標）に準拠した無線通信装置、などが搭載されている。

＜鍵管理サーバ１２０とデータ保管サーバ１３０の構成＞
鍵管理サーバ１２０は、クライアント端末１１０が暗号鍵を分割することによって生成した暗号鍵断片を格納する鍵データベース（ＤＢ）１２１を備える。

データ保管サーバ１３０は、クライアント端末１１０が暗号化データを分割することによって生成した暗号化データ断片、および暗号鍵を分割することによって生成した暗号鍵断片を格納する記憶部１３１を備える。

鍵管理サーバ１２０とデータ保管サーバ１３０は、パブリッククラウドやプライベートクラウド内の仮想マシン、データセンタや企業内の物理マシン等、サーバ装置として必要な機能を備えるコンピュータによって構成することができる。

また、鍵管理サーバ１２０とデータ保管サーバ１３０は、図１には示していないが、一般的なサーバ装置が必要とする機能を搭載している。例えば、ＣＰＵ、メモリ、ハードディスク装置、ディスプレイ、キーボード、マウス、ネットワークインタフェースカード、Ｗｉ−Ｆｉ（登録商標）に準拠した無線通信装置、などが搭載されている。

暗号化データや暗号鍵を複数の鍵管理サーバ１２０やデータ保管サーバ１３０に分散して保存するのは、暗号化データ断片や暗号鍵断片の一部がサーバ障害等で失われたとしても、元の暗号化データや暗号鍵を復元できるようにする、すなわち可用性や信頼性を向上させるためである。したがって、鍵管理サーバ１２０とデータ保管サーバ１３０は、互いに地理上の物理的位置が異なっているほうが望ましいが、これに限られるものではない。

＜暗号鍵の分散＞
図３は、クライアント端末１１０がデータ３０１を暗号化して各サーバに配布する手順を説明する図である。本発明においては、データ３０１を暗号化した暗号化データ３０３をデータ保管サーバ１３０に預けることに加え、暗号鍵３０２を秘密分散技術によって複数の暗号鍵断片３０４に分割し、各サーバに分散して保管させる。さらに暗号化データ３０３についても、複数の暗号化データ断片３０５に分割してもよい。

各事業者が暗号鍵３０２を不正に取得することができないようにするためには、クラウドストレージ事業者が保持する暗号鍵断片３０４のみ、または鍵管理事業者が保持する暗号鍵断片３０４のみによっては暗号鍵３０２を復元することができないようにする必要がある。具体的には、暗号鍵断片３０４を秘密分散技術によって生成する場合、暗号鍵３０２を復元するために必要な暗号鍵断片３０４の個数をａ、各鍵管理サーバ１２０が保持する暗号鍵断片３０４の合計数をＮ、各データ保管サーバ１３０が保持する暗号鍵断片３０４の合計数をＭとすると、ａ＞Ｎかつａ＞Ｍを満たす必要がある。簡易的に、各サーバが暗号鍵断片３０４を１つずつ保持すると仮定すると、Ｎ＜ａ≦Ｎ＋ＭかつＭ＜ａ≦Ｎ＋Ｍを満たす必要がある。

また、他の事業者に属するサーバが保持している暗号鍵断片３０４を自由に取得できるのであれば、暗号鍵３０２を分散させる意義が没却されるので、少なくとも鍵管理サーバ１２０はデータ保管サーバ１３０が保持している暗号鍵断片３０４にアクセスすることができないように構成され、データ保管サーバ１３０は鍵管理サーバ１２０が保持している暗号鍵断片３０４にアクセスすることができないように構成されている必要があると考えられる。

具体的には、例えば鍵管理サーバ１２０とデータ保管サーバ１３０の間の通信経路をネットワーク上で遮断する、事業者をまたがったアクセスに対して認証処理を設ける、などの手法が考えられる。必ずしも、他事業者内の暗号鍵断片３０４に対していかなる手段によってもアクセスすることができないように厳密なアクセス制限を課す必要はなく、求められるセキュリティレベルに応じて必要なアクセス制限を課せばよい。ただし、少なくとも他事業者に属する暗号鍵断片３０４に対して何らの許可なくアクセスすることができないようにする必要があると考えられる。

＜データの暗号化処理＞
図４は、クライアント端末１１０がデータ３０１を暗号化する手順を説明するフローチャートである。以下、図４の各ステップについて説明する。説明の簡易のため、各サーバは暗号鍵断片３０４を１つずつ保持し、データ保管サーバ１３０は暗号化データ断片３０５を１つずつ保持すると仮定する。また、鍵管理サーバ１２０がＮ個、データ保管サーバ１３０がＭ個存在するものと仮定する（図３に示す例では、Ｎ＝１、Ｍ＝２）。

（図４：ステップＳ４０１）
暗号処理部１１１は、暗号鍵３０２を用いてデータ３０１を暗号化し、暗号化データ３０３を作成する。暗号鍵３０２としては、例えば乱数を用いることができるが、これに限られるものではなく、鍵を生成する手法については限定しない。例えば、あらかじめクライアント端末１１０に割り当てられた固定値を暗号鍵３０２として用いることができる。また、暗号化アルゴリズムについても限定はしないが、例えばＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）などを用いることができる。

（図４：ステップＳ４０２）
分散処理部１１２は、図３で説明したように、秘密分散技術を用いて、暗号鍵３０２をａ個の暗号鍵断片３０４に分割する。秘密分散技術のアルゴリズムについては限定しないが、例えば非特許文献１に記載されている（ｋ，ｎ）閾値秘密分散法を用いることができる。

（図４：ステップＳ４０３）
分散処理部１１２は、暗号化データ３０３をｂ個以上集めなければ復元不可能な複数の暗号化データ断片３０５に分割する。鍵管理事業者は暗号化データ断片３０５を保持しないことを想定しているので、１≦ｂ≦Ｍとする必要がある。本ステップは、暗号化データ３０３の冗長性を高めるためのものであるため、必要性に応じて省略することもできる。特に、データ保管サーバ１３０が１つのみの場合（Ｍ＝１）は、暗号化データ３０３を分散させる意義は少ないので、本ステップは省略してもよいであろう。

（図４：ステップＳ４０３：補足その１）
暗号化データ３０３は、冗長性を持たせずに分散させてもよいし、Ｒｅｅｄ−Ｓｏｌｏｍｏｎ符号やＲａｐｔｏｒ符号等の誤り訂正技術を用いて冗長化することによって各暗号化データ断片３０５に分割してもよい。

（図４：ステップＳ４０３：補足その２）
暗号鍵３０２を分散させる手法と暗号化データ３０３を分散させる手法が異なる理由について補足する。暗号鍵３０２は平文であるため、暗号論的に安全な方法で分散させなければ、暗号鍵断片３０４から元の暗号鍵３０２が不正に復元される可能性がある。一方、暗号化データ３０３は既に暗号化されているため、個々の暗号化データ断片３０５が不正に取得されたとしても、暗号鍵３０２が保護されている限り元のデータ３０１は復元されない。したがって、暗号化データ３０３は必ずしも暗号論的に安全な方法で分散させる必要はない。

（図４：ステップＳ４０４）
データ通信部１１４は、データ保管サーバ１３０に対して暗号鍵断片３０４と暗号化データ断片３０５を送信する。データ保管サーバ１３０は、受信したデータ断片を記憶部１３１に格納する。またデータ通信部１１４は、鍵管理サーバ１２０に対して暗号鍵断片３０４を送信する。鍵管理サーバ１２０は、受信した暗号鍵断片３０４を鍵ＤＢ１２１に格納する。

＜データの復号化処理＞
図５は、クライアント端末１１０が暗号鍵断片３０４と暗号化データ断片３０５を用いてデータ３０１を復元する手順を説明するフローチャートである。以下、図５の各ステップについて説明する。

（図５：ステップＳ５０１）
データ通信部１１４は、鍵管理サーバ１２０とデータ保管サーバ１３０から、少なくともａ個以上の暗号鍵断片３０４と、少なくともｂ個以上の暗号化データ断片３０５とを取得する。

（図５：ステップＳ５０２）
復元処理部１１３は、ステップＳ５０１で取得したａ個以上の暗号鍵断片３０４とｂ個以上の暗号化データ断片３０５から、ステップＳ４０２と同様の秘密分散技術を用いて、暗号鍵３０２と暗号化データ３０３を復元する。

（図５：ステップＳ５０３）
暗号処理部１１１は、暗号鍵３０２を用いて暗号化データ３０３を復号化し、データ３０１を取得する。

＜本発明のまとめ＞
以上のように、本発明に係る暗号化データ管理システム１００は、秘密分散技術によって暗号鍵３０２をａ個の暗号鍵断片３０４に分割し、鍵管理事業者に属する鍵管理サーバ１２０とクラウドストレージ事業者に属するデータ保管サーバ１３０に分散して保持させる。これにより、各事業者が保持する暗号鍵断片３０４のみでは元の暗号鍵３０２を復元することができないので、各事業者がデータ３０１を不正に取得することを効果的に防ぐことができる。

１００：暗号化データ管理システム、１１０：クライアント端末、１１１：暗号処理部、１１２：分散処理部、１１３：復元処理部、１１４：データ通信部、１２０：鍵管理サーバ、１２１：鍵ＤＢ、１３０：データ保管サーバ、１３１：記憶部、１４０：ネットワーク、３０１：データ、３０２：暗号鍵、３０３：暗号化データ、３０４：暗号鍵断片、３０５：暗号化データ断片。

Claims (4)

1. データを暗号化するクライアント端末と、
   暗号化された前記データを格納する１以上のデータ保管サーバと、
   暗号化された前記データを復号化するために用いる復号鍵を格納する１以上の鍵管理サーバと、
   を有し、
   前記クライアント端末は、
   前記復号鍵を、所定個数以上集めなければ前記データを復号化できない複数の鍵断片に分割する分散処理部を備え、
   前記データ保管サーバは、
   １以上の前記データ保管サーバのうち少なくともいずれかが前記鍵断片を保持するとともに、各前記データ保管サーバが保持する前記鍵断片の合計数が前記所定個数未満となるように構成され、
   前記鍵管理サーバは、
   １以上の前記鍵管理サーバのうち少なくともいずれかが前記鍵断片を保持するとともに、各前記鍵管理サーバが保持する前記鍵断片の合計数が前記所定個数未満となるように構成され、
   前記データ保管サーバが保持している前記鍵断片に対して前記鍵管理サーバが少なくとも無許可でアクセスすることができないように構成され、
   前記鍵管理サーバが保持している前記鍵断片に対して前記データ保管サーバが少なくとも無許可でアクセスすることができないように構成されている
   ことを特徴とする暗号化データ管理システム。
2. 前記クライアント端末は、
   暗号化された前記データを、所定個数以上集めなければ元の状態を復元することができない複数の暗号化データ断片に分割し、
   前記データ保管サーバのうち少なくともいずれかは、前記暗号化データ断片を保持する
   ことを特徴とする請求項１記載の暗号化データ管理システム。
3. 前記クライアント端末は、暗号化された前記データを、誤り訂正符号技術により前記暗号化データ断片に分割する
   ことを特徴とする請求項２記載の暗号化データ管理システム。
4. 前記データ保管サーバと前記鍵管理サーバは、互いに異なる事業者が管轄するネットワークの配下に設置されている
   ことを特徴とする請求項１から３のいずれか１項記載の暗号化データ管理システム。

Images