そこで、クライアント側で、ファイル毎にデータを暗号化し、この暗号化ファイルをサーバへ送信して、サーバ側で保管する(各ファイルの暗号化を解くための鍵はクライアントしか持たない)ようにすると、ストレージ・サービス事業者は、各ファイルの内容を読むことができない。
しかしながら、サーバは、クライアントからのファイル読み出し要求等に応えて、保管している膨大なファイルの中から所望のファイルを検索する必要があり、このためには、通常、サーバ側でも、階層構造を有するディレクトリの下にファイルを配置して管理することになる。つまり、要求対象のファイルを特定するために、階層構造をルートから順に辿って所望のファイルに到達するまでのパスの情報(例えば、「ディレクトリ名/・・・/ディレクトリ名/ファイル名」)として共通の情報を、クライアントとサーバの双方が持つことになる。
従来の技術では、このパスの情報を、クライアントからサーバへそのまま(暗号化せずに)送信するしかなく、クライアント側で付与しているディレクトリ名やファイル名(以下、対象がディレクトリであるかファイルであるかを問わず「オブジェクト名」と呼ぶ)自体が、秘匿すべき情報を含む可能性があるにもかかわらず、サーバ側で、オブジェクト名を読むことができてしまっていた。
なお、ローカルなコンピュータの内部で、上記パスの情報を暗号化する技術として、ENCFS(ENCrypted FileSystem)が知られているが、この技術は、上記「ディレクトリ名/・・・/ディレクトリ名/ファイル名」の全体を秘密鍵方式で暗号化し、暗号化パス情報を得るものである。ENCFSは、ネットワークを介してファイル及びそのパス情報を共有することは全く想定していない技術であるため、秘密鍵方式でパス情報を暗号化しているが、仮に、本発明のようにネットワーク・ストレージ・サービスへの適用を検討するとすれば、複数のユーザがどのクライアント機器からでもサーバ上にある同一のデータを利用可能にできることが当該サービスの利点の一つであるから、公開鍵方式が採用できることが望ましい。
しかし、代表的な秘密鍵方式であるAES(Advanced Encryption Standard)の1ブロックを暗号化した結果が16バイト単位であるのに対し、代表的な公開鍵方式であるRSAの1ブロックを暗号化した結果は256バイト単位となり、上記パスの情報の全体を暗号化すると、ネットワークを介して共有するには長過ぎるものとなってしまう。よって、ENCFSの技術を利用して、ネットワーク・ストレージ・サービスにおけるパスの情報の暗号化を行うことは、否定される。
また、特許文献1には、上述したネットワーク・ストレージ・サービスにおける課題とは逆に、サーバが提供するURLをクライアント側で解読できないようにするという課題を解決するために、サーバ側からクライアントへ送信するURLを暗号化URLとし、その暗号化URLへのアクセス要求をクライアントが送信すると、URLを復号化してからサーバへアクセス要求が渡されるシステムが、記載されている。
この特許文献1のシステムでは、複数のクライアントと一つのサーバが存在する中で、一つのサーバだけがURLを解読できればよく、さらに、クライアント側では教えられたURLの全体を一つとして扱い、そのままそこへのアクセス要求を出すだけなので、URLのパス情報は、いずれのクライアントにも共有されていない。
本発明は、上記の事情に鑑み、クライアント側で暗号化したファイルをサーバ上で保管するネットワーク・ストレージ・サービスにおいて、ファイルを管理するためのパスの情報はクライアントとサーバに共通に持たせつつ、ファイルの内容だけでなくディレクトリ名やファイル名もサーバ側では解読できないようにするという、新規な課題を解決する仕組みを提供することを目的とする。
本発明の原理に従う一つのセキュア・ネットワーク・ストレージ・システムは、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるクライアント装置と、前記ファイルの内容が暗号化された暗号化ファイルを保存するためのストレージと前記階層構造に基づいて該暗号化ファイルを管理するための手段とを備えるサーバ装置とを有し、前記クライアント装置により作成されたディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記クライアント装置から前記サーバ装置へ送信する手段と、前記サーバ装置において、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名を登録するとともに、新たなオブジェクト識別子を割り当て、該オブジェクト識別子及び前記位置の情報を、前記サーバ装置から前記クライアント装置へ通知する手段と、前記クライアント装置がファイル内容を取得するために前記サーバ装置へ送信する要求は、要求対象のファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定するものであり、該要求に応えて前記サーバ装置から送信された暗号化ファイルを前記クライアント装置において復号化する手段とを備える。
この構成により、ファイルを管理するためのパスの情報は、サーバ側でもクライアント側でも、オブジェクト識別子を用いて与えられることになるので、クライアント側が作成したオブジェクト名をサーバ側に知らせることなく、共通の階層構造に基づいたファイルの管理が可能になる。例えば、従来技術における「ディレクトリAの名前/ディレクトリFの名前/ファイルXの名前」という情報ではなく、「識別子1001/識別子5023/識別子3087」という情報を用いて、サーバにおけるファイルX(ファイルXの名前もファイルXの内容も暗号化されている)の保管を行うことができる。
このために、クライアントは、「ディレクトリA」を作成する(名前を付ける)と、「ディレクトリAの名前」は送らず、例えば、ディレクトリAの位置(例えば、「ルートの下」)を示す第1の情報と、ディレクトリAの名前を少なくとも上記位置において同一の名前が異なる値になることがないように示す値を含む第2の情報をサーバに送る。
サーバは、これらの情報を受信すると、第1の情報が示す位置に、ディレクトリAの名前と同一の名前のディレクトリが既に登録されていないかどうか、第2の情報に基づいて確認することができる。同一の名前の既登録がないと確認されたら、サーバは、ディレクトリAに対して新たなオブジェクト識別子(上記の例では、「識別子1001」)を割り当て、上記位置の情報(「ルートの下」)を付加して、クライアントに通知する。
次に、クライアントが、ディレクトリAの下に「ディレクトリF」を作成する(名前を付ける)と、「ディレクトリAの名前/ディレクトリFの名前」を送るのではなく、例えば、ディレクトリFの位置(ルートの下のディレクトリAの下)を先に通知されたオブジェクト識別子を用いて特定する情報(「ルートの下の識別子1001の下」)を、第1の情報としてサーバに送る。クライアントはまた、ディレクトリFの名前を少なくとも上記位置において同一の名前が異なる値になることがないように示す値を含む第2の情報をサーバに送る。
サーバは、これらの情報を受信すると、第1の情報が示す位置に、ディレクトリFの名前と同一の名前のディレクトリが既に登録されていないかどうか、第2の情報に基づいて確認することができる。同一の名前の既登録がないと確認されたら、サーバは、ディレクトリFに対して新たなオブジェクト識別子(上記の例では、「識別子5023」)を割り当て、上記位置の情報(「ルートの下の識別子1001の下」)を付加して、クライアントに通知する。
さらに、クライアントが、ディレクトリFの下に「ファイルX」を作成する(名前を付ける)と、「ディレクトリAの名前/ディレクトリFの名前/ファイルXの名前」を送るのではなく、例えば、ファイルXの位置(ルートの下のディレクトリAの下のディレクトリFの下)を先に通知されたオブジェクト識別子を用いて特定する情報(「ルートの下の識別子1001の下の識別子5023の下」)を、第1の情報としてサーバに送る。クライアントはまた、ファイルXの名前を少なくとも上記位置において同一の名前が異なる値になることがないように示す値を含む第2の情報をサーバに送る。
サーバは、これらの情報を受信すると、第1の情報が示す位置に、ファイルXの名前と同一の名前のファイルが既に登録されていないかどうか、第2の情報に基づいて確認することができる。同一の名前の既登録がないと確認されたら、サーバは、ファイルXに対して新たなオブジェクト識別子(上記の例では、「識別子3087」)を割り当て、上記位置の情報(「ルートの下の識別子1001の下の識別子5023の下」)を付加して、クライアントに通知する。
クライアントが作成若しくは更新したファイルXの内容は、その位置を先に通知されたオブジェクトを用いて特定する(ファイルXの名前に到達するためのパスの情報であり、例えば、「ルートの下の識別子1001の下の識別子5023の下の識別子3087」のように表される)ことにより、クライアントにおいてファイル内容を暗号化した上で、サーバのストレージに保存することができる。
その後、クライアントがファイルXの内容を取得する場合にも、同様に位置を特定する(「ルートの下の識別子1001の下の識別子5023の下の識別子3087」を指定する)ことにより、サーバはファイルXの暗号化ファイルをストレージから読み出してクライアントに送ることができ、クライアントは自信の有する鍵でファイルXの内容を復号化することができる。
上記の例で、階層構造の段数が複数になる場合を説明したように、上記システムにおいて、前記クライアント装置により作成されたディレクトリ又はファイルが、以前に作成されたディレクトリの下に位置する場合、前記第1の情報が、以前に作成されたディレクトリに対して割り当てられ通知されたオブジェクト識別子により該位置を特定するようにしてもよい。
また、上記の例で、サーバ側でオブジェクトを登録する前にオブジェクト名の衝突を検出することを説明したように、上記システムにおいて、前記第1の情報及び前記第2の情報を受信した前記サーバ装置が、前記第1の情報が示す位置に前記ディレクトリ又はファイルの名前と同一の名前に対応する暗号化オブジェクト名が既に登録されていないことを確認し、この確認に応じて、前記第2の情報が示す暗号化オブジェクト名の登録及び新たなオブジェクト識別子の割り当てを行うようにしてもよい。
なお、上記の例で、サーバ側でオブジェクト名の衝突を検出するためにクライアント側から送る情報として説明したように、上記システムにおいて、前記第2の情報が、前記ディレクトリ又はファイルの名前を少なくとも前記位置において同一の名前が異なる値になることがないように示す値であって少なくとも許可されないユーザが該名前を復元することはできない値を含むようにしてもよい。
この値は、例えば、オブジェクトの名前から計算されるハッシュ値とすることができる。ハッシュ値は、原理的には、オブジェクト名が異なっていても同一の値になることがあり得るが、オブジェクト名が同一であれば必ず同一の値になる(同一の名前が異なる値になることはない)ものである。仮に、オブジェクト名が異なるのに同一の値になった場合には、本来は同一の名前の既登録がないので登録できるはずのオブジェクト名が、登録できずにエラーとなることになるが、そうなっても、クライアント側でオブジェクト名を変更して再度試みればよく、また、実用上は、名前の空間を十分に広く取ることにより、ハッシュ値と名前が一対一対応となるように構成することも可能である。また、ハッシュ値は、原理的に、元の名前を復元することができない性質を持つ。
上記値の代替例として、暗号化オブジェクト名を用いることも可能である。暗号化の方式によっては、元の平文にその都度異なるデータを加えてから暗号化するために、名前が同一であるのに暗号化された名前が異なる値となることがあり得るが、同一の位置においては加えるデータを同一にすることにより、少なくとも今その下にオブジェクトを登録しようとしているディレクトリにおいては同一の名前を暗号化して得られる値が異なる値になることがないようにすることができる。
ここで、上記の例では、サーバ側でオブジェクトを登録する処理として、新たなオブジェクト識別子の割り当て及びクライアントへの通知のみを説明したが、最終的には、クライアントが必要に応じてサーバから暗号化オブジェクト名を取得して復号化によりオブジェクト名を得ることができる状態にしたいのであるから、サーバにおいて暗号化オブジェクト名が登録されると、オブジェクトの登録処理が完了したといえることになる。
その登録される暗号化オブジェクト名は、クライアントからサーバに送られるが、上述したオブジェクト名の衝突検出のための情報を送るタイミングで送られてもよいし、それとは別に後から送られてもよい。上述した暗号化オブジェクト名に基づいてオブジェクト名の衝突を検出する例では、暗号化オブジェクト名自体が上記第2の情報に含まれることになる。上述したハッシュ値に基づいてオブジェクト名の衝突を検出する例では、ハッシュ値に加えて暗号化オブジェクト名を上記第2の情報に含めて送ってもよいし、上記第2の情報にはハッシュ値のみを含めて送り、後から別に暗号化オブジェクト名を送ってもよい。後者の場合でも、ハッシュ値を含む第2の情報に基づいて新たなオブジェクト識別子の割り当て及びクライアントへの通知が行われ、そのオブジェクト識別子に対応するように暗号化オブジェクト名がクライアントからサーバへ送られて登録されるため、第2の情報は、暗号化オブジェクト名を示すものであり、暗号化オブジェクト名の登録は、新たなオブジェクト識別子の割り当てとともに行われて、オブジェクトの登録処理を構成するものである。
上記システムにおいて、前記暗号化ファイル及び/又は前記暗号化オブジェクト名は、当該ファイル内容及び/又は当該オブジェクト名の復号化が許可されるユーザに対応する公開鍵を用いた暗号化を含む処理を行って得られるものとしてもよい。
上述したように、ファイルを管理するためのパスの情報は、サーバ側でもクライアント側でも、オブジェクト識別子を用いて与えられるため、暗号化オブジェクト名がファイルにアクセスする度に送受信されることはなく、しかも、オブジェクト識別子毎に別々に暗号化オブジェクト名が送受信されるため、公開鍵方式を採用しても、ネットワークを介して送受信されるデータが長くなり過ぎるという問題は生じない。
したがって、上記システムでは、公開鍵方式を採用し、複数のユーザがどのクライアント機器からでもサーバ上にある同一のファイルを利用可能にできるという、ネットワーク・ストレージ・サービスの利点を生かすことが可能である。さらに、例えば、システムの運用途中で暗号化アルゴリズムが変更された場合でも、オブジェクト識別子を変更する必要はなく、各オブジェクト識別子に対応する暗号化オブジェクト名を新しい暗号化アルゴリズムで計算し直したもので上書きすれば済むという利点もある。
上述した複数のユーザによるファイルの共有を実現するために、上記システムにおいて、前記クライアント装置の前記ファイルシステムのユーザとは異なるユーザが作成したディレクトリ又はファイルにつき、前記サーバ装置が登録した位置の情報及び前記サーバ装置が割り当てたオブジェクト識別子を取得することにより、前記クライアント装置の前記ファイルシステムの前記階層構造内に、当該異なるユーザが作成したオブジェクトを取り込み、当該異なるユーザが作成したファイル内容を取得可能にする手段を更に備えるようにしてもよい。
また、複数のユーザによるオブジェクト名を含めた共有を実現するために、上記システムにおいて、前記クライアント装置の前記ファイルシステムのユーザとは異なるユーザが作成したディレクトリ又はファイルにつき、前記サーバ装置が登録した位置の情報と暗号化オブジェクト名及び前記サーバ装置が割り当てたオブジェクト識別子を取得し、該暗号化オブジェクト名を復号化することにより、前記クライアント装置の前記ファイルシステムの前記階層構造内に、当該異なるユーザが作成したオブジェクトをその名前とともに取り込む手段を更に備えるようにしてもよい。
上記システムで用いる暗号化オブジェクト名は、オブジェクト名を該オブジェクト名の復号化が許可されるユーザに対応する公開鍵により直接的に暗号化したものとすることも可能であるが、そうすると、複数のユーザにより共有させる場合に、暗号化オブジェクト名の長さをユーザの人数倍したデータが送受信されることになり、ネットワーク資源の浪費につながる。そこで、オブジェクト名をセッション鍵により暗号化したものと、該オブジェクト名の復号化が許可されるユーザに対応する公開鍵により前記セッション鍵を暗号化したもので、暗号化オブジェクト名を構成するようにすれば、セッション鍵を暗号化した部分だけがユーザの人数倍されることになり、効率的である。
さらに、上記システムで用いる前記暗号化ファイルも、ファイル内容をセッション鍵により暗号化したものと、該ファイル内容の復号化が許可されるユーザに対応する公開鍵により前記セッション鍵を暗号化したもので構成するようにしてもよい。
また、ファイル内容を暗号化する鍵とオブジェクト名を暗号化する鍵とを異なるものとしたり、さらに、ファイル毎にファイル内容を暗号化するセッション鍵を異なるものとしたりオブジェクト毎にオブジェクト名を暗号化するセッション鍵を異なるものとしたりすれば、より安全性を増すことができる。
上述したように、複数のユーザによりオブジェクト名を共有する場合、前記サーバ装置において登録される暗号化オブジェクト名は、当該オブジェクト名の復号化が許可されるユーザが複数であるので、複数のユーザのそれぞれに対応する公開鍵により当該復号化に用いられる鍵をそれぞれ暗号化したものである複数の暗号化鍵を含むようにすることができる。この場合に、前記クライアント装置がオブジェクト名を取得するために前記サーバ装置へ送信する要求に応えて返送される暗号化オブジェクト名には、前記複数の暗号化鍵のうち、要求元のユーザ用の暗号化鍵が含まれるようにしてもよい。
また、前記クライアント装置において、前記暗号化ファイル又は前記暗号化オブジェクト名の復号化が許可されるユーザを追加するために、当該ファイル内容又は当該オブジェクト名の前記階層構造における位置を特定する情報を含む要求を、前記サーバ装置へ送信し、該要求に応えて返送された情報を復号化して、前記ファイル内容又は前記オブジェクト名を暗号化しているセッション鍵を取得し、該セッション鍵を前記追加となるユーザに対応する公開鍵により暗号化して得られる情報を、前記位置を特定する情報とともに前記サーバ装置へ送信する手段を更に備えるようにしてもよい。前記位置を特定する情報は、前記オブジェクト識別子を含むものとなる。
このように、共有させるユーザを追加する場合に、セッション鍵を新しくして暗号化ファイル又は暗号化オブジェクト名を全て作成し直して登録するのではなく、対象となる暗号化ファイル又は暗号化オブジェクト名で既に使われているセッション鍵を取得して、そのセッション鍵を追加するユーザ用に新たに暗号化して登録するだけとすれば、高速に新たなユーザに共有させることが可能になる。
上述したシステムにおいては、パスの情報(オブジェクト識別子を用いて表される位置の情報)と、オブジェクト名とが、分離されているため、サーバに対してオブジェクト名を秘匿しながらネットワーク・ストレージ・サービスが受けられることが可能になっている。この分離された情報は、対象となるオブジェクトを作成したユーザ若しくは共有が許可されたユーザが、クライアント側で選択的に統合することも可能であり、その場合、上記システムは、前記クライアント装置において、前記ファイルシステムの前記階層構造におけるある位置のオブジェクト名を取得するために前記サーバ装置へ送信する要求に、オブジェクト識別子を用いて前記ある位置を特定する情報を含め、該要求に応えて前記サーバ装置から送信された暗号化オブジェクト名を復号化する手段を更に備えてもよい。
上述したセキュア・ネットワーク・ストレージ・システムの発明は、システム全体の方法の発明としても、汎用のサーバクライアントシステムを本システムとして動作させるためのプログラム(又はそのプログラムを記録した記録媒体)の発明としても、クライアント装置の発明としても、サーバ装置の発明としても、汎用のコンピュータを本システムのクライアント又はサーバとして動作させるためのプログラム(又はそのプログラムを記録した記録媒体)の発明としても、クライアントにおいて実行される方法の発明としても、サーバにおいて実行される方法の発明としても、勿論成立するものである。
上記システム全体の方法の発明は、例えば、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるクライアント装置により、ディレクトリ又はファイルを作成し、前記ディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記クライアント装置からサーバ装置へ送信し、前記サーバ装置は、前記ファイルの内容が暗号化された暗号化ファイルを保存するためのストレージと前記階層構造に基づいて該暗号化ファイルを管理するための手段とを備えるものであり、前記サーバ装置により、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名を登録するとともに、新たなオブジェクト識別子を割り当て、該オブジェクト識別子及び前記位置の情報を、前記サーバ装置から前記クライアント装置へ通知し、前記クライアント装置により、取得したいファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定する要求を、前記サーバ装置へ送信し、前記要求に応えて前記サーバ装置から送信された暗号化ファイルを、前記クライアント装置において復号化するものである。
上記クライアント装置の発明は、例えば、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるクライアント装置であって、前記ファイルの内容が暗号化された暗号化ファイルを保存するためのストレージと前記階層構造に基づいて該暗号化ファイルを管理するための手段とを備えるサーバ装置に、接続するための手段と、前記ファイルシステム上で作成したディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記サーバ装置へ送信する手段と、前記サーバ装置において、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名が登録可能になるとともに、新たなオブジェクト識別子が割り当てられると、該オブジェクト識別子及び前記位置の情報を、前記サーバ装置から受信する手段と、取得したいファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定する要求を、前記サーバ装置へ送信する手段と、前記要求に応えて返送された暗号化ファイルを復号化する手段とを備えるものである。
上記サーバ装置の発明は、例えば、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるクライアント装置に、接続するための手段と、前記ファイルの内容が暗号化された暗号化ファイルを保存するためのストレージと、前記階層構造に基づいて前記暗号化ファイルを管理するための手段と、前記クライアント装置により作成されたディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記クライアント装置から受信する手段と、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名を登録するとともに、新たなオブジェクト識別子を割り当て、該オブジェクト識別子及び前記位置の情報を、前記クライアント装置へ通知する手段と、前記クライアント装置から送信される要求であって、取得したいファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定する要求を受信し、該要求が指示する暗号化ファイルを前記ストレージから読み出して、前記クライアント装置へ送信する手段とを備えるものである。
上記クライアント用プログラムの発明は、例えば、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるコンピュータを、セキュア・ネットワーク・ストレージ・システムのクライアントとして動作させるためのプログラムであって、前記ファイルの内容が暗号化された暗号化ファイルを保存するためのストレージと前記階層構造に基づいて該暗号化ファイルを管理するための手段とを備えるサーバに、接続するためのプログラムコードと、前記ファイルシステム上で作成したディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記サーバへ送信するためのプログラムコードと、前記サーバにおいて、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名が登録可能になるとともに、新たなオブジェクト識別子が割り当てられると、該オブジェクト識別子及び前記位置の情報を、前記サーバから受信するためのプログラムコードと、取得したいファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定する要求を、前記サーバへ送信して、前記要求に応えて返送された暗号化ファイルが復号化されるようにするためのプログラムコードとを備えるものである。
上記サーバ用プログラムの発明は、例えば、データを保存するためのストレージを備えるコンピュータを、セキュア・ネットワーク・ストレージ・システムのサーバとして動作させるためのプログラムであって、階層構造を有するディレクトリの下にファイルを配置して管理するファイルシステムを備えるクライアントに、接続するためのプログラムコードと、前記ファイルの内容が暗号化された暗号化ファイルを前記ストレージに保存するためのプログラムコードと、前記階層構造に基づいて前記暗号化ファイルを管理するためのプログラムコードと、前記クライアントにより作成されたディレクトリ又はファイルの前記階層構造における位置を示す第1の情報と、該ディレクトリ又はファイルの名前が暗号化された暗号化オブジェクト名を示す第2の情報とを、前記クライアントから受信するためのプログラムコードと、前記階層構造における前記第1の情報が示す位置に前記第2の情報が示す暗号化オブジェクト名を登録するとともに、新たなオブジェクト識別子を割り当て、該オブジェクト識別子及び前記位置の情報を、前記クライアントへ通知するためのプログラムコードと、前記クライアントから送信される要求であって、取得したいファイル内容の前記階層構造における位置を、前記オブジェクト識別子を用いて特定する要求を受信し、該要求が指示する暗号化ファイルを、前記クライアントへ送信するデータとして、前記ストレージから読み出すためのプログラムコードとを備えるものである。
以上のとおり、本発明によれば、ファイルの内容だけでなくディレクトリ名やファイル名もサーバ側では解読できないようにしたネットワーク・ストレージ・サービスを実現することが可能になる。
以下、図面を参照して、本発明の一実施形態に係るセキュア・ネットワーク・ストレージ・システムの例を説明する。
図1は、本システムを含む全体構成を示す図である。図1の例では、説明のため、ユーザAが、クライアント1(機器101)、クライアント2(機器102)の2つを使用し、ユーザBが、クライアント1(機器111)を使用するものとする。実際のシステムでは、多数のユーザが、それぞれ任意の数のクライアント機器を使用できることは勿論である。
これらのクライアントは、ネットワーク200を介して、サーバ300に接続可能である。サーバ300は、ストレージを備え、ファイルを保存し、管理するが、ここで扱うファイルは、いわゆるファイル形式のデータの他、メッセージ形式のデータ等でもよく、階層構造に基づいて管理されていれば、その階層構造の末端に位置するデータがファイルであり、それより上に位置する各ノードがディレクトリである。サーバ300は、いわゆるクラウドを形成するサーバ群であってよく、大規模なデータセンタであっても、一つのサーバであってもよい。ここでのデータセンタ(サーバ群)は、単一地点にあってもよいし、複数拠点に分散していてもよい。
ネットワーク200は、パブリッククラウドの場合は典型的にはインターネットであり、プライベートクラウドの場合は企業内ネットワークでもよい。各クライアントで作成されたファイルはサーバ300に保存され、ユーザはサーバ上のファイルを読み書きすることになるため、同一ユーザが複数のクライアント機器を持ち、ある機器で作成したデータを別の機器で利用することも簡単にできる。クライアント機器内にファイルを残さないようにすれば、セキュリティ上も利点がある。本実施形態によれば、ファイルの内容をクライアント機器内に残さないだけでなく、ディレクトリ名やファイル名(オブジェクト名)もクライアント機器内からは消去し、使用する際にその都度サーバから取得するようにすることも可能である。
各クライアントがオブジェクト名又はファイル内容をネットワーク200経由でサーバ300に保存するときには、暗号化したオブジェクト名又は暗号化したファイル内容をサーバへ向けて送信する。各クライアントとサーバとの間のファイルの同期は、例えば、特願2010−77959に記載した方式によっても、実現することが可能である。
図2には、1人のユーザでオブジェクト名及びファイル内容をサーバに保存する場合の処理の一例を示す。ユーザAの機器101は、平文のオブジェクト名又はファイル内容をランダムに生成したセッション鍵を用いて共通鍵暗号により暗号化する。次にセッション鍵を自身(ユーザA)のユーザ公開鍵で暗号化する。この暗号化データと暗号化されたセッション鍵をセットにして、サーバ300に送付する。サーバはこの状態で保存する。このデータを復号するためには、ユーザAのユーザ秘密鍵が必要であるが、サーバはこの鍵を持たないので、オブジェクト名もファイル内容も復号することができない。よって、ユーザが属する組織とは別の組織が運営するクラウドに、安心してファイルを預けることが可能になる。
次に復号の方法を説明する。ユーザAの機器101又は102は、サーバ300から暗号データと暗号化されたセッション鍵を取得する。機器101又は102では、暗号化されたセッション鍵を自身(ユーザA)のユーザ秘密鍵で復号する。ここで得られたセッション鍵を使って暗号データを共通鍵暗号により復号する。これによって平文のオブジェクト名又はファイル内容を取得することができる。なお、図2の例では、あるユーザ(ユーザA)がサーバに保存したデータを別のユーザ(ユーザB)が取得しても、復号化に必要なユーザ秘密鍵がないので、読むことはできない。
図3には、複数のユーザでオブジェクト名又はファイル内容を共有したい場合の処理の一例を示す。ユーザAが作成したあるファイルのファイル内容をユーザBに共有させる場合に、そのファイルに到達するパス上のオブジェクト名の一部または全部をユーザBに共有させてもよいし、オブジェクト名は全く共有させないことも可能である。ユーザAの機器101又は102は、自身(ユーザA)のユーザ公開鍵でセッション鍵を暗号化するとともに、そのセッション鍵で暗号化したオブジェクト名又はファイル内容を共有したい他ユーザ(ユーザB)のユーザ公開鍵で当該セッション鍵を暗号化して、両方を暗号データに付けて、サーバ300に保存する。これにより、図2のように同一ユーザ(ユーザA)の機器101及び102がサーバに保存したデータを利用できるだけでなく、異なるユーザ(ユーザB)の機器111も同じデータを利用できるようになる。つまり、機器111は、図3のように暗号化されたセッション鍵を自身(ユーザB)のユーザ秘密鍵で復号し、そのセッション鍵を用いて暗号データ(オブジェクト名又はファイル内容)を復号する。
以上のような暗号化及び復号化の処理と、後述するユーザ認証のためにクライアントからサーバへ送信される署名の作成(ユーザ秘密鍵で暗号化する処理)とに必要な、公開鍵及び秘密鍵は、予め各クライアント機器に格納されているものとして、以降の説明を行うが、この必要な鍵がクライアントに備えられている状態は、例えば、特願2010−37403に記載した方式によっても、実現することが可能である。
図4には、本システムにおけるサーバ300の内部構成例を示す。サーバは、一般的なサーバコンピュータで構成でき、メッセージ処理部410、認識処理部420、オブジェクト管理部430、ファイル管理部440を備える。
メッセージ処理部410は、クライアントとの間でメッセージを送受信し、そのメッセージの内容に従った処理を行う。認証処理部420は、メッセージ処理部410でクライアントからの認証にかかわるメッセージを受信したときに、ユーザ情報格納部450に格納されているユーザ情報を用いて認証する。オブジェクト管理部430は、メッセージ処理部410でクライアントからのオブジェクトにかかわるメッセージを受信したときに、オブジェクト管理の処理を行う。オブジェクトとは、ファイルおよびディレクトリの両方を指す。オブジェクト管理部430は、オブジェクトテーブル460を参照および更新する。ファイル管理部440は、クライアントからのファイルに関する登録・取得要求を処理し、ファイル格納部470にファイルを格納する。
図5には、本システムにおけるクライアント機器101、102、111、…の内部構成例を示す。クライアントは、一般的なクライアントコンピュータ(パソコン、PDA、スマートフォン等)で構成でき、メッセージ処理部510、認識処理部520、オブジェクト管理部530、ファイル管理部540を備える。
メッセージ処理部510は、サーバとの間でメッセージを送受信し、そのメッセージの内容に従った処理を行う。認証処理部520は、サーバとのメッセージ交換を行うときに、最初にユーザの認証を行う。この時に認証処理部520は、認証情報格納部550に記憶されている情報を使用して、サーバに認証用のメッセージを送信して、ユーザ認証を行う。オブジェクト管理部530は、クライアント内のオブジェクト(ファイル・ディレクトリ)の状態が変更されたときに、オブジェクト管理の処理を行う。具体的には、ファイルおよびディレクトリの作成・更新・削除時に、サーバに対して同期処理を行う。オブジェクト管理部530は、オブジェクトテーブル560を参照および更新する。また、オブジェクト管理部530は、暗号鍵格納部570に格納されている暗号鍵を管理する機能も備えている。ファイル管理部540は、サーバからのファイルに関する登録・取得要求を処理し、ファイル格納部580にファイルを格納する。
以上に説明したクライアント及びサーバの各部の機能は、汎用コンピュータにソフトウェアプログラムをインストールすることにより実装されてもよいし、機能の一部又は全部を専用ハードウェア化して実装してもよい。
次に本システムの暗号化方式について、一つの例を挙げて説明する。図6は、本システムの暗号化方式の説明図である。図6に示すように、本システムでは、例えば、「dir1」という平文のオブジェクト名に「1」というオブジェクト識別子が割り当てられる。また、平文のオブジェクト名「dir1」がセッション鍵を用いて暗号化され、暗号化されたオブジェクト名「k8dMgYp5phd6hbyJ」が生成される。さらに、この平文のオブジェクト名「dir1」のハッシュ値「#$!XZabI」が計算される。そして、これらの情報が、サーバ内のオブジェクトテーブルやクライアント内のオブジェクトテーブルに記録される。
図7は、サーバ内のオブジェクトテーブルの説明図である。図7に示すように、サーバ内のオブジェクトテーブルには、ユーザID(例えば「a」など)、オブジェクトの位置情報(例えば「/」、すなわち「ルートの下」など)、オブジェクトの種別(例えば「ディレクトリ」など)、オブジェクト名のハッシュ値(例えば「#$!XZabI」など)、暗号化されたオブジェクト名(例えば「k8dMgYp5phd6hbyJ」など)、オブジェクト識別子(例えば「1」など)が記録される。このサーバ内のオブジェクトテーブルは、オブジェクト(ファイル又はディレクトリ)の管理用のテーブルである。なお、各オブジェクトは、履歴管理をするためにバージョン情報を持っていてもよい。また、暗号化オブジェクト名で衝突を検出する場合には、ハッシュ値は必ずしも必要ではない。
図8は、クライアント内のオブジェクトテーブルの説明図である。図8に示すように、クライアント内のオブジェクトテーブルには、オブジェクトの位置情報(例えば「/」、すなわち「ルートの下」など)、オブジェクトの種別(例えば「ディレクトリ」など)、オブジェクト名のハッシュ値(例えば「#$!XZabI」など)、暗号化されたオブジェクト名(例えば「k8dMgYp5phd6hbyJ」など)、平文のオブジェクト名(例えば「dir1」など)、オブジェクト識別子(例えば「1」など)が記録される。
なお、クライアントは、図8のようなオブジェクトテーブルを、ディレクトリやファイルの新規作成時に自身の内部で作成して、機器のメモリ内にずっと保持していてもよく、あるいは、自身で作成・保持はせずに、本システムのサービスにログインするときに及び/又は適当なタイミングでサーバから取得するようにしてもよい。
図9は、上記の例のディレクトリ構造(暗号化したディレクトリ構造)を復号化したものを示す図である。図9のディレクトリ構造は、図7と図8のオブジェクトテーブルに対応する。つまり、図7と図8のオブジェクトテーブルは、図9のディレクトリ構造に対応する。
以上のように構成された本システムの動作について、図面を参照して説明する。ここでは、まず、本システムの各構成(サーバ、クライアント)の動作について説明する。
図10は、ディレクトリやファイルの作成イベント発生時におけるサーバ側のフロー図である。図10に示すように、ディレクトリやファイルの作成イベントが発生したときに、サーバは、クライアントからの作成要求メッセージ(後述する)を受信すると(S100)、ユーザ認証を実行する(S101)。ユーザ認証の結果が「NG」であった場合には、サーバは、作成応答メッセージとして、ユーザ認証失敗を示すエラーをクライアントに送信して(S102)、処理を終了する。
ユーザ認証の結果が「OK」であった場合には、作成要求に含まれるユーザIDや位置情報をキーにしてオブジェクトテーブルを検索し、オブジェクト名のハッシュ値を取得する(S103)。そして、取得したハッシュ値と作成要求に含まれるハッシュ値とが同一であるか比較する(S104)。ハッシュ値が同一であった場合には、サーバは、作成応答メッセージとして、同一オブジェクトが存在している旨のエラーをクライアントに送信して(S105)、処理を終了する。
同一オブジェクトが存在していなかった場合には、サーバは、オブジェクト識別子を割り当てて、オブジェクトテーブルに記録する(S106)。そして、作成応答メッセージとして、割り当てたオブジェクト識別子などの情報をクライアントに送信する(S107)。
図11は、ディレクトリやファイルの作成イベント発生時におけるクライアント側のフロー図である。図11に示すように、ディレクトリやファイルの作成イベントが発生すると(S110)、クライアントは、作成イベントのオブジェクト名のハッシュ値を計算し、作成イベントのオブジェクト名を暗号化する(S111)。つぎに、クライアントは、サーバに、作成要求メッセージを送信する(S112)。この作成要求メッセージには、ユーザID、ユーザの認証用の情報(認証情報)、オブジェクトの位置情報、オブジェクトの種別、オブジェクト名のハッシュ値、暗号化したオブジェクト名などの情報が含まれる。
そして、クライアントは、サーバから作成応答メッセージを受信すると、サーバに送信した情報、および、サーバから受信した情報(オブジェクト識別子など)を、オブジェクトテーブルに記録する(S113)。
図12は、ファイル内容の登録時におけるサーバ側のフロー図である。図12に示すように、サーバは、クライアントから登録要求メッセージを受信すると(S120)、ユーザ認証を実行する(S121)。ユーザ認証の結果が「NG」であった場合には、サーバは、登録応答メッセージとして、ユーザ認証失敗を示すエラーをクライアントに送信して(S122)、処理を終了する。
ユーザ認証の結果が「OK」であった場合には、登録要求に含まれるユーザIDや位置情報やオブジェクト識別子をキーにしてオブジェクトテーブルを検索し、処理対象のオブジェクトの存在を確認する(S123)。確認の結果、そのオブジェクトが存在していなかった場合には(S124)、サーバは、登録応答メッセージとして、そのオブジェクトが存在していない旨のエラーをクライアントに送信して(S125)、処理を終了する。
そのオブジェクトが存在していた場合には、サーバは、そのオブジェクトとして、登録要求メッセージ中のファイルの内容をファイル格納部に記録する(S126)。そして、登録応答メッセージとして、ファイルの内容が登録された旨の情報をクライアントに送信する(S127)。
続いて、本システム全体の動作を、シーケンス図を参照しながら説明する。
図13は、本システムにおけるユーザ認証のシーケンス図である。クライアントとサーバ間でメッセージを交換する場合には、まず、ユーザ認証を行う。図13に示すように、クライアントは、ユーザ認証のために、ユーザIDおよび認証情報を記載したユーザ認証要求メッセージをサーバに送信する(S130)。サーバは、メッセージ処理部でメッセージを受信した後、認証処理部に処理を渡し、ユーザ情報格納部に保存されているユーザ情報と比較して、ユーザ認証を行う。この後、サーバはクライアントにユーザ認証応答を行う(S131)。
図14は、本システムにおけるディレクトリ作成のシーケンス図である。上述のように、クライアントでは、ディレクトリが作成されたときに、作成イベントを受信して、図11の手順が実行される。
そして、図14に示すように、例えば、ユーザaが、ルートの下に「dir1」というディレクトリを作成した場合には、まず、このオブジェクト名「dir1」のハッシュ値を計算するとともに、このオブジェクト名「dir1」を暗号化する。ここでは、オブジェクト名のハッシュ値が「#$!XZabI」であり、暗号化されたオブジェクト名が「k8dMgYp5phd6hbyJ」であったとする。この場合、計算されたハッシュ値および暗号化オブジェクト名と、ユーザID、ユーザ認証時の認証情報、位置情報としての「/」、種別としての「ディレクトリ」が、作成要求メッセージに記載されて、サーバに送信される(S140)。
作成要求メッセージを受信したサーバでは、図10の手順が実行される。すなわち、ユーザIDおよび認証情報を確認して、ユーザ認証を行う。ユーザ認証に失敗した場合には、エラーメッセージを送信する。認証に成功した場合には、作成要求メッセージに記載されているユーザIDおよび位置情報をキーにしてオブジェクトテーブルを検索し、オブジェクトのハッシュ値を取得する。位置情報に指定されたディレクトリに複数のファイルおよびディレクトリが存在している場合には、ハッシュ値は複数取得される。取得したハッシュ値と作成要求メッセージ中のハッシュ値が同一であるか確認する。同じ場合には、同一名称のオブジェクトが存在しているので、エラーメッセージをクライアントに送信する。ハッシュ値が同一ではない場合には、サーバは、割り当てられていないオブジェクト識別子を割り当て、オブジェクトテーブルに記憶する。オブジェクト識別子は、時刻情報を使ってユニークに割り当てたり、1から連番に割り当てることで、オブジェクトテーブルに存在しないものを割り当てたりすることができる。オブジェクト識別子は、システム全体で唯一の値になるように決定してもよく、同一階層内で唯一の値になるように決定してもよい。ここでは、オブジェクト識別子に1が割り当てられたとする。そうすると、図7の1行目に示すように、位置情報・種別・オブジェクト名のハッシュ値・暗号化されたオブジェクト名・オブジェクト識別子が、サーバ内のオブジェクトテーブルに記憶される。最後に、サーバは、割り当てたオブジェクト識別子=1を作成応答メッセージに記載して、クライアントへ送信する(S141)。
次に、上記で作成した「ルートの下のdir1」の下に「dir2」を作成する場合を説明する。サーバ側およびクライアント側のフローは上記と同じである。オブジェクト名のハッシュ値および暗号化オブジェクト名は、同様に計算し、位置情報として、「ルートの下のdir1」のオブジェクト識別子である「1」を位置情報に記載して、サーバに送信する(S142)。
このメッセージを受信したサーバは、ユーザID=aと位置情報に記載されている「/1/」をキーにしてオブジェクトテーブルを検索する。同一のハッシュ値が登録されていない場合には、オブジェクト識別子を割り当て(ここでは「2」とする)、サーバ内のオブジェクトテーブルに、図7の2行目の情報を追加して、作成応答メッセージを送信する(S143)。
なお、図14では、ハッシュ値と暗号化オブジェクト名を、同時に、クライアントからサーバへ送信する例について説明したが、例えば、まずハッシュ値をクライアントからサーバへ送信し、サーバからクライアントへオブジェクト識別子の送信があった後に、暗号化オブジェクト名をクライアントからサーバへ送信するようにしてもよい。
次に、図15のシーケンス図を参照しながら、ファイルの作成・登録について説明する。図15に示すように、クライアント中でファイルが作成(新規作成)されると、すでに説明したディレクトリの作成(新規作成)と同様に、ハッシュ値および暗号化オブジェクト名を計算し、種別をファイルとしてサーバに作成要求を送信する(S150)。
サーバでは、ディレクトリの場合と同様に処理を進める。ここでは、位置情報が「/1/」にファイル名「File1」を作成するとする。サーバは、ハッシュ値によって重複するかをチェックした後、オブジェクト識別子として「5」を割り当てる。この割り当て後に、サーバ側のオブジェクトテーブルに、図7の5行目の情報を追加する。そして、サーバは、クライアントに、作成応答メッセージとしてオブジェクト識別子=5を送信する(S151)。
クライアントは、ファイルのオブジェクト識別子が「5」であることがわかるので、位置情報「/1/」とオブジェクト識別子「5」をファイル登録要求メッセージに記載し、暗号化したファイルの内容を含めて、サーバに送る(S152)。
登録要求メッセージを受信したサーバでは、図12の手順が実行される。すなわち、まず、ユーザ認証を行い、ユーザ認証に失敗したらエラーを送信する。次に登録要求メッセージ内のユーザID、位置情報「/1/」、オブジェクト識別子「5」をキーにしてオブジェクトテーブルを検索する。このオブジェクトがオブジェクトテーブルに存在しているか確認し、存在していない場合には、エラーとしてエラーメッセージをクライアントに送信する。オブジェクトが存在する場合には、登録要求メッセージ中の暗号化されたファイルの内容をファイル格納部に格納する。ファイルの格納部へのリンク情報としては、この例では、ユーザID、位置情報、オブジェクト識別子で表現される。ファイル格納部へ格納する処理が正常に終了したら、登録応答メッセージとして、ファイルの内容が登録されたことをクライアントに通知する(S153)。
次に、クライアントとサーバとの同期(サーバからのダウンロード)について説明する。サーバとの同期を行うときには、クライアントは、サーバからオブジェクトテーブルを取得し、サーバに保存されているオブジェクト一覧(ディレクトリ情報)を構築する。
図16は、本システムにおけるオブジェクトテーブル取得のシーケンス図である。図16に示すように、クライアントは、サーバに対してオブジェクトテーブル取得要求メッセージを送信し(S160)、ユーザ認証ができた場合には、サーバは、クライアントに対してオブジェクト取得応答として、サーバ内のユーザIDに関連する情報を送信する(S161)。このメッセージを受信したクライアントは、図8のようなクライアント内のオブジェクトテーブルを構築し、暗号化されたオブジェクト情報を復号し、ディレクトリ・ファイル名を構築する。なお、クライアント内でオブジェクトを復号した結果が、図9で示される。
次に、ファイル名「File1」のファイル内容の取得について説明する。図17は、本システムにおけるファイル取得のシーケンス図である。「File1」は、位置情報「/1/」、オブジェクト識別子「5」を有することがオブジェクトテーブルでわかる。クライアントは、図17に示すように、この情報を、ファイル取得要求メッセージとして、ユーザID、認証情報、位置情報、オブジェクト識別子とともに、サーバへ送信する(S170)。サーバは、ユーザID、位置情報、オブジェクト識別子をキーにしてファイル格納部に存在するファイルを取り出し、そのファイルをファイル取得応答としてクライアントに送信する(S171)。クライアントは、取得したファイルを暗号鍵格納部に格納されている鍵を使って復号し、ファイル格納部に保存する。
続いて、オブジェクトの変更について説明する。ファイル名やディレクトリ名を変更する場合には、オブジェクトの変更を行う。図18は、本システムにおけるオブジェクト変更のシーケンス図である。図18に示すように、ファイル名やディレクトリ名の変更時には、変更要求メッセージに、ユーザID、認証情報、位置情報、オブジェクト識別子、新しいファイル名やディレクトリ名から計算された新オブジェクト名ハッシュ値、新暗号化オブジェクト名を記載して、サーバに送信する(S180)。
サーバは、新規作成時と同様に、オブジェクトテーブルをユーザIDと位置情報をキーに検索し、ハッシュ値が同一なものがあるかを確認する。同一なものがない場合には、新オブジェクト名ハッシュ値と新暗号化オブジェクト名をオブジェクトテーブルに登録し、変更応答メッセージとして成功したことを伝える(S181)。
次に、オブジェクトの移動について説明する。ディレクトリやファイルの位置を移動する場合には、オブジェクトの移動を行う。図19は、本システムにおけるオブジェクト移動のシーケンス図である。図19に示すように、クライアントは、オブジェクトの移動をする場合、移動要求メッセージに、ユーザID、認証情報、位置情報、オブジェクト識別子、新しいディレクトリ名から計算された新オブジェクト名ハッシュ値、新暗号化オブジェクト名、新しいディレクトリの位置情報を記載して、サーバに送信する(S190)。
サーバは、新規作成時と同様に、オブジェクトテーブルをユーザIDと新位置情報をキーに検索し、ハッシュ値が同一なものがあるかを確認する。同一なものがない場合には、オブジェクト識別子を割り当てる。ここでは、新規にオブジェクト識別子を割り当てているが、以前のオブジェクト識別子を使う方法もある。このオブジェクト識別子とメッセージ中に含まれている情報をオブジェクトテーブルに記載し、移動応答メッセージとしてオブジェクト識別子を含めて送信する(S191)。
続いて、オブジェクトの削除について説明する。図20は、本システムにおけるオブジェクト削除のシーケンス図である。図20に示すように、ファイルやディレクトリが削除された場合には、クライアントからサーバにオブジェクト削除要求メッセージが送信される(S200)。このメッセージには、ユーザID、認証情報、位置情報、オブジェクト識別子が含まれる。サーバでは、ユーザ認証を行った後、ユーザID、位置情報、オブジェクト識別子をキーにオブジェクトテーブルを検索し、対応するオブジェクトを削除する。種別がファイルの場合には、ファイルの内容も削除する。次に、削除応答メッセージにより、削除が成功したか失敗したかをクライアントに知らせる(S201)。
次に、本システムでファイルやディレクトリを複数のユーザで共有する方法について説明する。なお、ここでは、「共有」の語は、許可されたクライアントに情報を持たせるという意味で使用する。本システムでは、許可されないクライアント(やサーバ)は情報を解読することができないため、ここでいう「共有」には該当しない。
本システムにおいて、ファイルあるいはディレクトリを複数ユーザで共有する方法には、例えば、サーバで共有ディレクトリを作成する方法(第1の共有方法)や、ユーザのディレクトリやファイルを共有する方法(第2の共有方法)がある。以下では、それぞれの場合を説明するが、オブジェクトテーブルに格納されるオブジェクト名の暗号化に関しては、同様の方法で格納し、共有している人のみでオブジェクト名を閲覧することができる。
図21は、第1の共有方法を示した図である。図21に示すように、サーバでは、ユーザごとのディレクトリやファイルと、共有しているディレクトリやファイルの両方が、オブジェクトテーブルに保存される。なお、図21では、説明の便宜上、ディレクトリやファイル名を実ファイル名で表示しているが、実際のサーバ内のオブジェクトテーブルでは暗号化されており、サーバでは閲覧することができない。
図22は、サーバでのオブジェクトテーブルを示した図である。図22に示すように、サーバでは、各ユーザごとのディレクトリおよびファイルについては、「ユーザID」の欄に一人のユーザが記録されている。「ユーザID」の欄に複数のユーザが記録されている場合には、複数のユーザで共有されていることになり、「共有」の欄に○印が付されている。
図23は、暗号化されたオブジェクト名の構成を示す説明図である。図23に示すように、ファイル名やディレクトリ名であるオブジェクト名は、オブジェクト名ごとにランダムに生成されるセッション鍵で暗号化される。このセッション鍵を共有するユーザの公開鍵で暗号化する。これらの情報を暗号化されたオブジェクト名として保管する。例えば、ユーザIDが「a」のオブジェクトに関しては、図23(1)のような形で暗号化されたオブジェクト名に保存され、ユーザIDが「a,b」の場合には、図23(2)のような形で暗号化されたオブジェクト名に保存される。その他の、オブジェクトテーブルの記載方法は、前述のとおりである。
次に、サーバ側のオブジェクトテーブルをクライアントが取得するときの流れについて説明する。図24は、オブジェクトテーブルのサーバからクライアントへの送信のフロー図である。図24に示すように、クライアントがオブジェクトテーブル取得要求を送信すると(S240)、このメッセージを受けたサーバは、まず、ユーザ認証を行う(S241)。認証が失敗した場合には、エラーをクライアントへ送信して(S242)、処理を終了する。認証が成功した場合には、オブジェクトテーブル取得要求メッセージのユーザIDと位置情報をキーにしてオブジェクトテーブルを検索する(S243)。この場合、オブジェクトテーブルの「ユーザID」の欄にメッセージ中のユーザIDが存在するもので、位置情報が「1」以下の行を検索する。図22のオブジェクトテーブルでは、ユーザIDが「a」と「a,b」の行が検索される。サーバは、検索された行をオブジェクトテーブル取得応答メッセージで送信する(S244)。ここでは、暗号化されたオブジェクト名をそのまま送っているが、対応するユーザの公開鍵で復号できるセッション鍵の情報のみを送ってもよい。
クライアントは、サーバからオブジェクトテーブルを取得すると、例えば、図25に示すようなオブジェクトテーブルを作成する。次に、クライアントは、暗号化されたオブジェクト名を平文のオブジェクト名に変換する。暗号化されたオブジェクト名には、ユーザaの秘密鍵で復号できるセッション鍵が含まれる。このセッション鍵を取り出し、オブジェクト名を復号することにより、平文のオブジェクト名を取り出し、このオブジェクトテーブルに記載する。
「共有」の欄に×印がついている項目に関しては、クライアントでは、前述と同様にディレクトリやファイルが構成される。「共有」の欄に○印がついている場合には、クライアントは、例えば「/share/A+B」のように特定のディレクトリ下に、共有しているユーザ名を記載し、そのディレクトリをルート(/)ディレクトリとする。そして、例えば、図26に示すように、このディレクトリ以下にオブジェクト識別子7および8のディレクトリやファイルを配置する。
図27は、第2の共有方法を示した図である。図27に示すように、この場合、サーバには、ユーザごとのディレクトリ・ファイルが記録されている。そして、あるユーザの共有したいディレクトリは、ほかのユーザからディレクトリとして閲覧できるようになる。この例では、「dir2」は、ユーザaの持ち物であり、ユーザbからもこのディレクトリが見えるようになっている。
図28は、第2の共有方法のときのオブジェクトテーブルを示す図である。図28のオブジェクトテーブルの7行目は、ユーザbからユーザaのディレクトリ「dir2」を参照するリンクになる。この行は、共有先として「a/1/2」が示されているので、ユーザaの位置情報「/1/」の下のオブジェクト識別子「2」を示している。ユーザbのディレクトリでは、位置情報「/」にユーザaの対象ディレクトリが表示されることになる。
次にクライアントからオブジェクトテーブル取得要求メッセージを受信したサーバの動作を説明する。ユーザbのクライアントがサーバにオブジェクトテーブル取得要求メッセージ送信すると、サーバは、オブジェクトテーブル内で「ユーザID」あるいは「共有」の項目にユーザbが存在しているものを取り出し、クライアントに応答する。
これを受信したクライアントは、図29のようなオブジェクトテーブルを作成する。この場合、オブジェクト名以外は、サーバからの受信したものが記憶される。オブジェクト名は、暗号化されたオブジェクト名から、図25で説明したのと同様に、平文のオブジェクト名を取り出し、このオブジェクトテーブルに格納する。
ここで、図29のオブジェクトテーブルからクライアントのディレクトリ構造への変換方法について説明する。3行目(OID=6)は、「dir6」のディレクトリを表している。4行目は、共有先のフィールドから、ユーザID=a、位置情報「/1/」、オブジェクト識別子「2」を位置情報「/」に連結することが表されている。この場合、ユーザID=a、位置情報「/1/」、オブジェクト識別子「2」は、1行目(OID=2)となり、このディレクトリ「dir2」をユーザbの「/」に連結する。2行目(OID=3)は、共有ではない場合の配置方法により、「dir2」の配下に接続する。このような手順により、図30のような共有ディレクトリ構造が得られる。
次に、図31を参照しながら、ユーザaがファイルをサーバに登録し、ユーザbと共有する暗号化手順を述べる。図31は、この共有(再暗号化)の説明図である。図31に示すように、ユーザaのクライアントは、すでに説明したファイル登録要求によって、サーバにファイルをアップロードする(S310)。サーバからはファイル登録応答が返信される(S311)。サーバにアップロードされたファイルは、暗号化される。例えば、ファイルごとにランダムに選択されたセッション鍵で、ファイルが暗号化される。このセッション鍵をユーザaの公開鍵で暗号化する。この2つパートを1つのファイルとしてサーバに保存する。このファイルをダウンロードしたユーザaは、自身の秘密鍵によって、セッション鍵を取り出し、そのセッション鍵によってファイルを復号する。
ユーザaがユーザbとこのファイルの共有する場合には、以下の手順で暗号化することによって、サーバとクライアント間で大きなファイル本体を通信することなく、ユーザbと共有することができる。
まず、ユーザaのクライアントは、セッション鍵取得要求メッセージをサーバに送信する(S312)。このメッセージには、ユーザID、認証情報、位置情報、オブジェクト識別子を含んでいる。このメッセージを受信したサーバは、ユーザIDと認証情報によりユーザ認証を行う。認証が確認できた場合には、ユーザID、位置情報、オブジェクト識別子をキーにオブジェクトテーブルからファイルの存在を確認する。ファイルが存在している場合には、ファイルのユーザaの公開鍵で暗号化されたセッション鍵をセッション鍵取得応答メッセージとしてユーザaに送信する(S313)。
ユーザaは、このセッション鍵を自身の秘密鍵で復号し、復号したセッション鍵を共有するユーザbの公開鍵で暗号化する。このユーザbの公開鍵で暗号化したセッション鍵をセッション鍵登録要求メッセージでサーバに送信する(S314)。セッション鍵登録要求メッセージには、セッション鍵取得要求メッセージと同様に、ユーザID、認証情報、位置情報、オブジェクト識別子を記載する。サーバでは、これらの情報により、ファイルを特定し、ユーザの認証ができる。ファイルが存在する場合には、ユーザbの公開鍵で暗号化したセッション鍵を登録し、セッション鍵登録応答を返信する(S315)。
ユーザbは、ファイル取得要求メッセージに、ユーザID、認証情報、位置情報、オブジェクト識別子を記載して、サーバへ送信する(S316)。サーバは、ユーザID、位置情報、オブジェクト識別子をキーにしてファイル格納部に存在するファイルを取り出し、そのファイルをファイル取得応答としてユーザbに送信する(S317)。このとき、ユーザa用とユーザb用の鍵の両方を、ユーザbに送信するファイル取得応答に含めても良いが、ユーザa用の鍵はユーザbには不要であるので、ユーザb用の鍵を選択して含めるようにすれば効率が良い。ユーザbは、取得したファイルを自らの秘密鍵を使って復号することができる。このようにして、ユーザaおよびユーザbの両者がファイルの内容を復号化することができる。
なお、この図には書いていないが、ファイルの内容と同様にオブジェクトテーブルに記載されているファイル名・ディレクトリ名も同様に暗号化することができる。暗号化されたオブジェクト名として、サーバでのファイルと同様のフォーマットで保存することができる。ディレクトリを共有した場合には、そのディレクトリ配下のすべてのオブジェクトも共有できるように、オブジェクトテーブルのオブジェクト名に共有ユーザでも復号できるように再帰的に鍵を追加する手順を行い、ファイルの内容も同様に鍵を追加する手順を再帰的に行う。
また、ここでは、ユーザ追加の場合のみ説明しているが、ユーザ削除の場合には、対応する暗号化されたセッション鍵をサーバで削除すればよい。また、ユーザの公開鍵が変更された場合には、対応する暗号化されたセッション鍵をクライアントが更新することによって対応することができる。
また、ディレクトリやファイルを「共有」にした場合、上述したように再帰的に、共有するオブジェクト名のすべてを見ることができるようにしてもよいが、オブジェクト名の一部のみを見ることができるようにしてもよい。後者の場合は、ユーザが指定したオブジェクト名に選択的に共有ユーザ用の鍵を追加する手順を行う。例えば、図30に示すように、「dir2」と「dir2/dir3」を「共有」にした場合、「dir2」というオブジェクト名を見られないようにしてもよい。その場合、「dir2」のオブジェクト名は表示されず、「dir3」のオブジェクト名は「**/dir3」などと表示される。
以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。