JP5494171B2 - ファイル管理システム、ストレージサーバ、クライアント、ファイル管理方法およびプログラム - Google Patents

Description

本発明は、ファイル管理システム、ストレージサーバ、クライアント、ファイル管理方法およびプログラムに関し、特に、暗号化してファイルを管理するファイル管理システム、ストレージサーバ、クライアント、ファイル管理方法およびプログラムに関する。

ストレージ上のファイルに対し、ある一定のユーザからのアクセスを許容し、情報共有、業務の分担に役立てることのできるファイル管理システムに対するニーズがある。例えば、異なる組織に所属するユーザに対してネットワークを介して直接的あるいは間接的にストレージサービスを提供するサービスなどが挙げられる。また、この種のファイル管理システムを用いて、複数ユーザ間のデータの相関分析やトレンド分析などに基づくリコメンデーションの作成・提供や、ＨＳＭ（Ｈｉｅｒａｒｃｈｉｃａｌ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ）、ＩＬＭ（Ｉｎｆｏｒｍａｔｉｏｎ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）、またデータ圧縮や重複排除などを行うことも知られている。この種のファイル管理システムにおいては、ファイルの暗号化に使用した鍵やデータそのものを危険にさらすことなく、個々のユーザがその権限に応じたファイルにアクセスできるように制御することが望まれる。

特許文献１に、共通鍵暗号方式と、公開鍵暗号方式を併用し、ユーザ秘密鍵で暗号化されたファイルを格納するファイル格納部及びユーザからのファイルアクセス要求に対して該当ファイルを検索・送信するファイル送信部を備える共有ファイルサーバと、前記ユーザ秘密鍵をユーザ公開鍵で暗号化し、ユーザＩＤ及びファイルＩＤに関連付けて格納するクライアント秘密鍵格納部を備える暗号管理サーバとを備えたファイル管理システムが開示されている。

また、特許文献２には、暗号化ファイルのヘッダ部分に複数のキー情報を埋め込むことで、あるキー情報が正しくない場合でも別のキー情報を使用して復号することができ、また、あらかじめ共通のキー情報を作成し配布しておくことでこのグループキーを持つユーザだけがファイルを復号化できるようにしたセキュリティシステムが開示されている。

さらに、非特許文献１には、ファイルの暗号化に使用した鍵（同文献の図８のコンテンツキー）をアクセス権を持つユーザのみが安全に取り出せるよう暗号化した上でファイルに付加し、安全にファイルの共有を実現する方法の一例が記載されている。

特開２００５−２０９１８１号公報 特開２０００−９９３８５号公報

Ｍｉｃｒｏｓｏｆｔ、"ＲＭＳとＩＲＭによる情報保護"、テクニカルホワイトペーパー、２００４年３月１８日、［online］、［平成22年3月29日検索］、インターネット〈URL：http://technet.microsoft.com/ja-jp/library/CC984234.aspx〉

しかしながら、上記した特許文献および非特許文献記載の各技術は、ユーザの秘密情報（ファイル暗号鍵や暗号化ファイル暗号鍵の復号鍵）が漏洩した際に、当該ユーザの秘密情報を利用した不正アクセスを遮断することが難しいという問題点がある。例えば、特許文献１の場合、ファイルの暗号化に用いたユーザ秘密鍵（ユーザＤＥＳキー）を復号するためのユーザ秘密鍵（ＲＳＡ秘密鍵）が漏洩することはないとの前提の下に、クライアントからのファイルへのアクセス要求を受け付けた場合に、ユーザ公開鍵（ＲＳＡ公開鍵）で暗号化したユーザ秘密鍵（ユーザＤＥＳキー）および暗号化ファイルをクライアントに送信する構成を採っているため、一度ユーザ秘密鍵（ＲＳＡ秘密鍵）が漏洩してしまうと、当該ユーザがアクセス可能な他のファイルにアクセスされてしまう可能性がある。

同様に、特許文献２や非特許文献１の技術も、ユーザの秘密情報が漏洩することはないとの前提の下に設計されているため、秘密情報（特許文献２のユーザ情報、パスワード等、非特許文献１のユーザ秘密鍵）を用いて、暗号化ファイルに添付された鍵（セッションキー、コンテンツキー）を入手して、暗号化ファイル内の平文やコンテンツにアクセスされてしまう可能性がある。

上記の問題は、前記ユーザの秘密情報（ユーザのパスワードやファイル暗号鍵の復号鍵として用いる秘密鍵）が漏洩した場合のほか、当該ユーザの秘密情報を持った構成員の人事異動、休退職、あるいは、冒頭に述べた各種のサービスからのユーザの退会やサービス変更などの場合にも起こりうる。これらに対し、その都度、暗号化されたファイル自体を別の暗号鍵で暗号化し直すことは現実的ではない。

本発明は、上記した事情に鑑みてなされたものであって、その目的とするところは、上記したユーザの秘密情報（ユーザのパスワードやファイル暗号鍵の復号鍵として用いる秘密鍵）が漏洩した場合であっても、可及的速やかに対策を講じ、当該ユーザの秘密情報を用いた不正アクセスを抑止できるようにしたファイル管理システム、ストレージサーバ、クライアント、ファイル管理方法およびプログラムを提供することにある。

本発明の第１の視点によれば、予め定められたファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備えるストレージサーバと、前記ストレージサーバから受け取った前記暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を前記公開鍵に対応する秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアントまたはサービスインスタンスと、を含み、前記ストレージサーバは、前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すファイル管理システムが提供される。

本発明の第２の視点によれば、ストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ；Ｅｎｃｒｙｐｔｅｄ−Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアントまたはサービスインスタンスと、接続され、ファイル暗号鍵（ＦＥＫ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備え、前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すストレージサーバが提供される。

本発明の第３の視点によれば、上記したストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ；Ｅｎｃｒｙｐｔｅｄ−Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアントまたはサービスインスタンスが提供される。

本発明の第４の視点によれば、予め定められたファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備えるストレージサーバが、クライアントまたはサービスインスタンスからの要求に応じて、前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すステップと、前記クライアントまたはサービスインスタンスが、前記ストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を前記公開鍵に対応する秘密鍵で復号するステップと、前記復号したファイル暗号鍵（ＦＥＫ）を用いてファイルを暗復号する暗復号ステップと、を含むファイル管理方法が提供される。本方法は、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すストレージサーバという、特定の機械に結びつけられている。

本発明の第５の視点によれば、上記したストレージサーバ、クライアントまたはサービスインスタンスをそれぞれ構成するコンピュータに実行させるプログラムが提供される。なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。

本発明によれば、ユーザの秘密情報（ユーザのパスワードやファイル暗号鍵の復号鍵として用いる秘密鍵）が漏洩した場合であっても、事後的に当該ユーザの秘密情報を用いた不正アクセスを抑止することが可能になる。

本発明の概要を説明するための図である。 本発明の第１の実施形態の構成を表したブロック図である。 図２の暗号化ファイル記憶部に記憶される暗号化ファイルの構成例を示す図である。 図２のＥ−ＦＥＫ記憶部における暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を管理するためのリストの構成例を示す図である。 本発明の第１の実施形態の動作（ファイル作成時）を示す流れ図である。 本発明の第１の実施形態の動作（ファイル利用時）を示す流れ図である。 本発明の第１の実施形態の動作（サービス開始時）を示す流れ図である。 本発明の変形実施形態の構成を表したブロック図である。

はじめに、本発明の概要について説明する。図１に示すように、本発明は、予め定められたファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部２６と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて前記ファイル暗号鍵（ＦＥＫ）を暗号化するファイル暗号鍵暗号化部２２と、前記暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部２５と、を備えるストレージサーバ２０と、ネットワーク経由でストレージサーバ２０にアクセス可能なクライアント１０Ａ、１０Ｂと、を含んで構成される。

ストレージサーバ２０は、さらに、アクセス要求受付部２１を備え、クライアント１０Ａ、１０Ｂから、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）の払い出し要求を受けた際に、無効化公開鍵情報記憶部２３に、該当ユーザまたはサービスの公開鍵が登録されているか否かを確認し、公開鍵の有効性を確認できた場合に、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出す。

ストレージサーバ２０から前記暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を受け取ったクライアント１０Ａ、１０Ｂは、自身の公開鍵に対応する秘密鍵を用いて暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を復号し、得られたファイル暗号鍵（ＦＥＫ）を用いてファイルを暗復号する。

例えば、図１に示すように、クライアント１０Ａ、１０Ｂが、それぞれ正規ユーザであり、暗号化ファイルが暗号化ファイル記憶部２６に、自身のファイル暗号鍵（ＦＥＫ＿Ａ、ＦＥＫ＿Ｂ）で暗号化した暗号化ファイルを登録していたものとする。その後、何らかの理由（例えば、クライアント１０Ａのユーザ秘密鍵＿Ａの漏洩）でクライアント１０Ａの公開鍵が無効になり、無効化公開鍵情報記憶部２３に当該公開鍵が無効になった旨が記録されると、以後、ストレージサーバ２０は、クライアント１０Ａの公開鍵にて暗号化された暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出し要求を拒否する。

これにより、暗号化ファイル記憶部２６に記憶した暗号化ファイルの再暗号化等を行わなくとも、暗号化ファイルの復号を阻止することが可能になる。

［第１の実施形態］
続いて、本発明の第１の実施形態について図面を参照して詳細に説明する。図２は、本発明の第１の実施形態の構成を表したブロック図である。図２を参照すると、クライアント１００と、サービスインスタンス２００と、暗号化ファイル記憶部４０１、Ｅ−ＦＥＫ記憶部４０２、無効化公開鍵リスト記憶部４０３、サービスユーザリスト記憶部４０４にアクセス可能なストレージサーバ３００と、を含む構成が示されている。

クライアント１００は、ファイルを取り扱う各種アプリケーションとの間で、ファイルの入出力処理を行うファイル入出力部１０１と、自身の秘密鍵（ファイルオーナー秘密鍵）や他のノードの公開鍵（ストレージサーバ公開鍵等）を用いて、ファイル暗号鍵（以下、「ＦＥＫ」とする。）の暗復号を行うＦＥＫ暗復号処理部１０２と、ＦＥＫ暗復号処理部１０２にて復号されたＦＥＫを用いて、ストレージサーバ２００から受信した暗号化ファイルの暗復号処理を行うファイル暗復号処理部１０３と、主にストレージサーバ３００との通信を行う通信部１０５とを含んで構成される。なお、図２の例では、クライアント１００が１台接続された構成を示しているが、クライアント１００は、複数存在してかまわない。また、クライアント１００がなく、サービスインスタンス２００のみがあるという構成も採用可能である。

サービスインスタンス２００は、サービスの実行を行うサービス実行部２０１と、自身の秘密鍵（サービス秘密鍵）を用いて、ＦＥＫの暗復号処理を行うＦＥＫ暗復号処理部２０２と、ＦＥＫ暗復号処理部２０２にて復号されたＦＥＫを用いて、ストレージサーバ２００から受信した暗号化ファイルの暗復号処理を行うファイル暗復号処理部２０３と、主にストレージサーバ３００との通信を行う通信部２０５とを含んで構成される。サービスインスタンス２００は、あるサービスをそのサービスを提供するユーザの集合ごとに準備したもので、複数存在しえる。また、サービス自体も複数存在してかまわない。また、サービスインスタンス２００がなく、クライアント１００のみがあるという構成も採用可能である。

ストレージサーバ３００は、クライアント１００から受信したメッセージに付されたデジタル署名の検証を行うデジタル署名検証部３０１と、所定の認証方式を用いてクライアント１００やサービスインスタンス２００の認証を行う認証部３０２と、クライアント１００やサービスインスタンス２００との通信を行う通信部３０３と、所定の鍵生成方式を用いてＦＥＫを生成するＦＥＫ生成器３０４と、ＦＥＫの暗復号処理を行うＦＥＫ暗復号処理部３０５と、暗号化ファイル記憶部４０１、Ｅ−ＦＥＫ記憶部４０２、無効化公開鍵リスト記憶部４０３、サービスユーザリスト記憶部４０４へのアクセスを行うストレージアクセス部３０６と、アクセスリクエストを依頼してきたクライアント１００やサービスインスタンス２００のリクエストの有効性を検証するリクエスト有効性検証部３０７とを含んで構成される。なお、図２の例では、ストレージサーバ３００が１台接続された構成を示しているが、ストレージサーバ３００は複数存在してかまわない。

暗号化ファイル記憶部４０１は、ＦＥＫで暗号化した状態でファイルを保管するデータベース等により構成される。暗号化ファイルの具体的な構成については後に図３を用いて説明する。

Ｅ−ＦＥＫ記憶部４０２は、ユーザあるいはサービス毎に定められた公開鍵と、この公開鍵でＦＥＫを暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）とを対応付けて記憶する。ＦＥＫ記憶部４０２の具体的な構成については後に図４を用いて説明する。

無効化公開鍵リスト記憶部４０３は、無効化されたユーザあるいはサービスの公開鍵のリスト（Ｒｅｖｏｋｅｄ Ｐｕｂ Ｋｅｙ Ｌｉｓｔ）を記憶する。無効化公開鍵リスト記憶部４０３への無効化公開鍵の追加・削除は、例えば、ユーザからの通報等により、ストレージサーバの管理者により行われる。無効化公開鍵リストに代えて、有効な公開鍵のリストを記憶して、当該リストに記載されていない公開鍵は無効であると判断する構成であってもよい。

サービスユーザリスト記憶部４０４は、サービスインスタンスとそのサービスインスタンスを利用するユーザ群の組を格納するサービスユーザリストを記憶する。

以上の暗号化ファイル記憶部４０１、Ｅ−ＦＥＫ記憶部４０２、無効化公開鍵リスト記憶部４０３、サービスユーザリスト記憶部４０４は、一または複数の記憶装置によって実現することができる。また、図２の例では、ストレージサーバ３００の外部に暗号化ファイル記憶部４０１、Ｅ−ＦＥＫ記憶部４０２、無効化公開鍵リスト記憶部４０３、サービスユーザリスト記憶部４０４が接続されている構成を示しているが、ストレージサーバ３００に内蔵された記憶装置に暗号化ファイル、Ｅ−ＦＥＫ、無効化公開鍵リスト、サービスユーザリストのうちの一部または全部を記憶する構成も採用可能である。

ここで、暗号化ファイル記憶部４０１に記憶される暗号化ファイルと、Ｅ−ＦＥＫ記憶部４０２の具体的構成例を説明する。

図３は、暗号化ファイルの構成を模式的に表した図である。図３の例では、暗号化ファイル５００は、データ本体をＦＥＫで暗号化した暗号化ファイル本体５０１に、その暗号化に使用したＦＥＫ ＩＤ５０２を付加して構成されている。このように、暗号化ファイル自体に、鍵情報やこれに関連する情報を添付しない構成とすることで、鍵情報の解析を困難化することができる。

図４は、Ｅ−ＦＥＫ記憶部４０２に保持される、公開鍵とＥ−ＦＥＫを管理するためのリスト６００の構造を表した図である。図４の例では、あるファイルを暗号化した際に用いたＦＥＫのＩＤ毎に、そのファイルに対しアクセス権限を持つアクセス主体（ファイルオーナ、ストレージサーバ、他のユーザ、他のサービス）の公開鍵と、該当アクセス主体の公開鍵で暗号化されたＥ−ＦＥＫと、を組にして、必要な数（１〜ｎ；ｎは当該ファイルにアクセスを許可された主体の数）だけ一まとめに格納される。このようなリストをＦＥＫ（ＦＥＫ ＩＤ）毎に用意することで、公開鍵と、その公開鍵を用いて暗号化したＥ−ＦＥＫの管理が容易化される。

図３、図４からも明らかなように、公開鍵によって暗号化されていないＦＥＫそのものは、図２の示すシステム全体のどこにも保存されない。あるアクセス主体が、あるファイルについてアクセスしようとする場合、Ｅ−ＦＥＫ記憶部４０２から、図３のＦＥＫ ＩＤに対応するＥ−ＦＥＫのリストを参照し、自身の公開鍵にて暗号化されたＥ−ＦＥＫを取り出す。前記アクセス主体は、自身の公開鍵に対応する秘密鍵を保持しているので、Ｅ−ＦＥＫを復号することができる。前記復号の結果、得られたＦＥＫを用いて、目的とするファイルの暗復号が可能となる。

なお、図２に示したクライアント１００、サービスインスタンス２００、ストレージサーバ３００の各部（処理手段）は、これらを構成するコンピュータに、そのハードウェアを用いて、上記した各処理を実行させるコンピュータプログラムにより実現することができる。

続いて、本実施形態の動作についてファイルの作成、ファイルの利用、ファイルを利用するサービスの開始に分けて、詳細に説明する。

［ファイルの作成］
図５は、本発明の第１の実施形態の動作（ファイル作成時）を示す流れ図である。図５を参照すると、まず、ファイルの作成者（ファイルオーナ）がファイルの作成に先立ってクライアント１００を利用してストレージサーバ３００に認証を依頼する（ステップＳ１００）。

ストレージサーバ３００は、認証部３０２を利用しファイルオーナの認証を行いファイルオーナの公開鍵を確定する（ステップＳ１０１）。なお、ステップＳ１００、Ｓ１０１における認証方式については、特に限定するものではなく、パスワードやバイオメトリクス情報を用いる方式などを適宜採用することができる。また、ここで確定する公開鍵としてファイルオーナから受信したものを用いてもよいし、あるいは、ストレージサーバ３００側に保持されている正規ユーザ（認証済みユーザ）の公開鍵を読み出して公開鍵を確定することとしてもよい。

次に、ストレージサーバ３００は、無効化公開鍵リスト記憶部４０３から無効化された公開鍵のリストを読み出し（ステップＳ１０２）、ファイルオーナの公開鍵の有効性を検証する（ステップＳ１０３）。なお、図５では省略されているが、前記公開鍵の有効性の検証の結果、ファイルオーナの公開鍵が無効化されていた場合には、ファイルオーナにその旨通達するなどのエラー処理を行った後、処理を終了する。

ファイルオーナの公開鍵の有効性が検証されると、クライアント１００にて、その搭載アプリケーションを利用してファイルの作成が行われる（ステップＳ１０４）。前記ファイルの作成が完了すると、クライアント１００から、ストレージサーバ３００に対し、そのファイルの暗号化に使用するＦＥＫの生成依頼が行われる（ステップＳ１０５）。

前記生成依頼を受けたストレージサーバ３００は、ＦＥＫ生成器３０４を利用してＦＥＫを生成する（ステップＳ１０６）。また、生成したＦＥＫには、ＦＥＫを一意に特定するためのＦＥＫ ＩＤが付与される。

続いて、ストレージサーバ３００は、ＦＥＫ暗復号処理部３０５を用いて、当該ファイルにアクセスが認められている各アクセス主体の公開鍵を用いて、前記生成したＦＥＫを暗号化する。ストレージサーバ３００は、ファイルオーナの公開鍵でＦＥＫを暗号化する（ステップＳ１０７）。同様に、ストレージサーバ３００は、ストレージサーバ自身の公開鍵でＦＥＫを暗号化する（ステップＳ１０８）。さらに、ストレージサーバ３００は、サービスユーザリスト記憶部４０４からサービスユーザリストを読み出し（ステップＳ１０９）、ファイルオーナが当該ファイルへのアクセスを許可している他のユーザもしくはサービスの公開鍵でＦＥＫを暗号化する（ステップＳ１１０）。

ストレージサーバ３００は、上記ステップＳ１０７、Ｓ１０８、Ｓ１１０で作成したＥ−ＦＥＫと、当該Ｅ−ＦＥＫの暗号化に使用した各公開鍵とを組にして、ＦＥＫ ＩＤを付加したリストを作成し（図４のリスト６００参照）、Ｅ−ＦＥＫ記憶部４０２に格納する（ステップＳ１１１）。

ストレージサーバ３００は、ステップＳ１０５のＦＥＫ生成依頼の応答として、ファイルオーナの公開鍵を用いて暗号化したＥ−ＦＥＫをＦＥＫ−ＩＤとともにクライアント１００に送信する。

Ｅ−ＦＥＫを受信したクライアント１００は、ファイルオーナの秘密鍵を用いて、前記受信したＥ−ＦＥＫを復号化する（ステップＳ１１２）。

クライアント１００は、ＦＥＫ暗復号処理部１０２にて、ステップＳ１１２で得られたＦＥＫを用いて、ステップＳ１０４にて作成したファイルを暗号化する（ステップＳ１１３）。その後、クライアント１００は、図４に示したようにＦＥＫ ＩＤを付加した暗号化ファイル（図４の暗号化ファイル５００参照）をストレージサーバ３００に送信する（ステップＳ１１４）。

ストレージサーバ３００は、クライアント１００から受信した暗号化ファイルを、暗号化ファイル記憶部４０１に格納する（ステップＳ１１５）。

以上により、暗号化ファイルが暗号化ファイル記憶部４０１に記憶されるとともに、ファイルオーナを含む当該ファイルにアクセス可能な主体のＥ−ＦＥＫが、Ｅ−ＦＥＫ記憶部４０２に記憶されて、いつでも利用可能な状態となる。

［ファイルの利用］
図６は、本発明の第１の実施形態の動作（ファイル利用時）を示す流れ図である。図６を参照すると、まず、ファイル利用者（ユーザあるいはサービス）がファイルの利用に先立ってクライアント１００あるいはサービスインスタンス２００を利用してストレージサーバ３００に認証を依頼する（ステップＳ２００）。

ストレージサーバ３００は、認証部３０２を利用しファイル利用者の認証を行い、その公開鍵を確定する（ステップＳ２０１）。なお、ステップＳ２００、Ｓ２０１における認証方式については、ステップＳ１００、Ｓ１０１と同様、特に限定するものではなく、パスワードやバイオメトリクス情報を用いる方式などを適宜採用することができる。また、ここで確定する公開鍵としてファイル利用者から受信したものを用いてもよいし、あるいは、ストレージサーバ３００側に保持されている正規ユーザ（認証済みユーザ）の公開鍵を読み出して公開鍵を確定することとしてもよい。

次に、ストレージサーバ３００は、無効化公開鍵リスト記憶部４０３から無効化された公開鍵のリストを読み出し（ステップＳ２０２）、ファイル利用者の公開鍵の有効性を検証する（ステップＳ２０３）。

前記公開鍵の有効性の検証の結果、ファイル利用者の公開鍵が無効化されていた場合、ストレージサーバ３００は、Ｅ−ＦＥＫ記憶部４０２に記憶されているリスト６００を読み出し（ステップＳ２０７）、無効化された公開鍵と対応するＥ−ＦＥＫが登録されているリスト６００から、無効化された公開鍵とＥ−ＦＥＫを削除する（ステップＳ２０４）。これにより、無効化された公開鍵にて暗号化されたＥ−ＦＥＫがシステム全体から削除され、無効化された公開鍵に対応する秘密鍵にて復号可能なＦＥＫが存在しなくなる。なお、前記無効化された公開鍵とＥ−ＦＥＫの削除に代えて、これらを利用できないように、別の情報に書き換えてしまうなどの方法も適宜採用可能である。

ファイル利用者の公開鍵の有効性が検証されると、ファイル利用者はストレージサーバ３００に対し、ファイルのリクエストを行うことが可能となる。ファイル利用者がファイルのリクエストを行うと（ステップＳ２０５）、ストレージサーバ３００は暗号化ファイル記憶部４０１からリクエストされた暗号化ファイルを読み出すとともに（ステップＳ２０６）、ＦＥＫ ＩＤおよび公開鍵に基づいて、Ｅ−ＦＥＫ記憶部４０２から該当ファイル利用者の公開鍵で暗号化したＥ−ＦＥＫを読み出し（ステップＳ２０７）、ファイルリ利用者に返送する（ステップＳ２０８）。

ファイル利用者は、まず、ストレージサーバ３００から受信したＥ−ＦＥＫを自身の秘密鍵で復号化し（ステップＳ２０９）、復号化したＦＥＫを用いて暗号化ファイルを復号する（ステップＳ２１０）。

その後、ファイル利用者は、ファイルを利用し（ステップＳ２１１）、再度ファイルをＦＥＫで暗号化する（ステップＳ２１２）。

その後、ファイル利用者は、図４に示したようにＦＥＫ ＩＤを付加した暗号化ファイル（図４の暗号化ファイル５００参照）をストレージサーバ３００に送信する（ステップＳ２１３）。

ストレージサーバ３００は、ファイル利用者から受信した暗号化ファイルを、暗号化ファイル記憶部４０１に格納する（ステップＳ２１４）。

以上により、利用後の暗号化ファイルが暗号化ファイル記憶部４０１に記憶される。

［ファイルを利用するサービスの開始］
図７は、本発明の第１の実施形態の動作（サービス開始時）を示す流れ図である。図７を参照すると、まず、サービスインスタンス２００は新ユーザへのサービス提供開始指示をどこかから受けると（ステップＳ３００）、ストレージサーバ３００に認証を依頼する（ステップＳ３０１）。

ストレージサーバ３００は、認証部３０２を利用しサービスインスタンス２００の認証を行い、その公開鍵を確定する（ステップＳ３０２）。なお、ステップＳ３０１、Ｓ３０２における認証方式については、ステップＳ１００、Ｓ１０１と同様、特に限定するものではなく、パスワードやバイオメトリクス情報を用いる方式などを適宜採用することができる。また、ここで確定する公開鍵としてサービスインスタンス２００側から受信したものを用いてもよいし、あるいは、ストレージサーバ３００側に保持されている正規ユーザ（認証済みユーザ）の公開鍵を読み出して公開鍵を確定することとしてもよい。

次に、ストレージサーバ３００は、無効化公開鍵リスト記憶部４０３から無効化された公開鍵のリストを読み出し（ステップＳ３０３）、サービスインスタンス２００の公開鍵の有効性を検証する（ステップＳ３０４）。

前記公開鍵の有効性の検証の結果、サービスインスタンス２００の公開鍵が無効化されていた場合、ストレージサーバ３００は、Ｅ−ＦＥＫ記憶部４０２に記憶されているリスト６００を読み出し、無効化された公開鍵と対応するＥ−ＦＥＫが登録されているリスト６００から、無効化された公開鍵とＥ−ＦＥＫを削除する（ステップＳ３０５）。これにより、無効化された公開鍵にて暗号化されたＥ−ＦＥＫがシステム全体から削除され、無効化された公開鍵に対応する秘密鍵にて復号可能なＦＥＫが存在しなくなる。なお、前記無効化された公開鍵とＥ−ＦＥＫの削除に代えて、これらを利用できないように、別の情報に書き換えてしまうなどの方法も適宜採用可能である。

サービスインスタンス２００の公開鍵の有効性が検証されると、サービスインスタンス２００は、ストレージサーバ３００に対し、新ユーザへのサービス開始依頼を行うことが可能となる。サービスインスタンス２００が新ユーザへのサービス開始依頼を行うと（ステップＳ３０６）、ストレージサーバ３００は、サービスユーザリスト記憶部４０４からサービスユーザリストを読み出すとともに（ステップＳ３０７）、新ユーザと既存ユーザのそれぞれに対し、サービス提供伺いを送信する（ステップＳ３０８）。

前記サービス提供伺いを受信した新ユーザおよび既存ユーザは、それぞれサービスの利用を判断し（ステップＳ３０９、Ｓ３１１）、返答にデジタル署名をして返信する（ステップＳ３１０、Ｓ３１２）。

ストレージサーバ３００は、デジタル署名検証部３０１を用いてそれらの回答の正当性を検証し（ステップＳ３１３）、新ユーザへのサービスを開始する場合、サービスユーザリスト記憶部４０４のサービスユーザリストに新ユーザを追加する（ステップＳ３１４）。

さらに、ストレージサーバ３００は、すでに暗号化ファイル記憶部４０１に登録されている新ユーザの暗号化ファイルに、サービスインスタンス２００経由でアクセスできるようにするため、サービスの公開鍵と、前記新ユーザの暗号化ファイルを復号するためのＦＥＫを暗号化したＥ−ＦＥＫをＥ−ＦＥＫ記憶部４０２に追加する（ステップＳ３１５）。より具体的には、Ｅ−ＦＥＫ記憶部４０２に記憶されているリストのうち、新ユーザの暗号化ファイルに対応するリストを抽出し、当該リストの中のストレージサーバの公開鍵で暗号化されているＥ−ＦＥＫを、ストレージサーバ３００の秘密鍵で復号化し、サービスの公開鍵で再度暗号化し、リストに格納する処理が行われる。

以上のように、本実施の形態によれば、データの復号化に必要な秘密情報（おもにＦＥＫ）や、秘密情報から計算されるキー情報（おもにＥ−ＦＥＫ）を必要以上にストレージシステムの外部に出さずともユーザ間あるいはユーザとサービスの間でデータの共有を実現することができる。その理由は、ファイルの復号化に必要なＦＥＫを、アクセスが許可されたユーザあるいはサービスの公開鍵で暗号化（Ｅ−ＦＥＫ）し、暗号化ファイルとは別の記憶媒体に保管し、暗号化ファイルへのアクセス時にはアクセス主体のＥ−ＦＥＫのみを選択使用するように構成したためである。

また、本実施の形態では、ＦＥＫとして、ファイル毎に生成したランダムな情報を用いることができる。前記ＦＥＫの暗号化には公開鍵暗号が使用されているため、あるデータのＦＥＫが漏洩したとしても他のデータの安全性は脅かされることはないし、あるユーザのＥ−ＦＥＫが漏洩したとしてもそこからユーザのパスワードに代表される秘密情報が漏洩することはない。

また、本実施の形態では、さらに、無効化された公開鍵のリストを持ち、ストレージアクセスの際にストレージサーバ３００がアクセス主体からのアクセスリクエストの有効性を検証した上で、適切なＥ−ＦＥＫを返却するようになっている。このため、秘密情報漏洩の検知と、該当する公開鍵の無効化公開鍵リストへの登録ができている場合においては、たとえ一部のユーザあるいはサービスのパスワードあるいは公開鍵暗号の秘密鍵に代表される秘密情報が漏洩したとしても、システムの他の部分の安全性が守られる。

また、本実施の形態では、さらに、暗号化ファイルにそのファイルの暗号化に使用したＦＥＫのＩＤを付加するとともに、Ｅ−ＦＥＫ記憶部４０２には、ＦＥＫ ＩＤ毎に、アクセス主体の公開鍵とＥ−ＦＥＫとを組にしたリストを格納するようにしている。このため、データアクセスの際の認証時にアクセス主体の公開鍵が特定されれば、Ｅ−ＦＥＫ記憶部４０２から、当該公開鍵に対応するＥ−ＦＥＫを読みだすことができる。つまり、Ｅ−ＦＥＫを総当り的に探索せずに済み、オーバーヘッドを抑えることのできる構成となっている。

また、本実施の形態では、さらに、ファイルアクセスの際あるいはサービス開始の際に行われるファイル利用者あるいはサービスインスタンスの有効性検証の結果（図６のステップＳ２０３、図７のステップＳ３０４参照）、ファイル利用者あるいはサービスインスタンスの公開鍵が無効化されていた場合、ストレージサーバ３００が、Ｅ−ＦＥＫ記憶部４０２から、無効化された公開鍵と対応するＥ−ＦＥＫを削除するようになっている（図６のステップＳ２０４、図７のステップＳ３０５参照）。このため、たとえＥ−ＦＥＫ記憶部４０２の漏洩と、無効化された公開鍵のユーザの秘密鍵の漏洩が発生してしまった場合にも、当該ユーザの秘密鍵からＦＥＫを計算されないようにすることができる。

また、本実施の形態では、さらに、ユーザがサービスの利用を開始した際に、特に何かアクションを起こさずとも、ユーザが新たにサービスの利用を開始した場合に既存のファイルに関してもそのサービスのアクセス範囲に含めることができる。その理由は、ストレージサーバ３００は、ユーザがサービスの利用を開始した際に、該当ユーザの既存ファイルにサービスインスタンス２００経由でアクセスできるようにするため、サービスの公開鍵と、前記新ユーザの暗号化ファイルを復号するためのＦＥＫを暗号化したＥ−ＦＥＫをＥ−ＦＥＫ記憶部４０２を追加するようにしているためである（図７のステップＳ３１５）。

また、本実施の形態では、Ｅ−ＦＥＫ記憶部４０２にストレージサーバ３００の公開鍵と、その公開鍵で暗号化したＥ−ＦＥＫを格納しているため、非常時に、ストレージサービス提供者側が、ファイルの内容を復元あるいはアクセスすることも可能となっている。

［第２の実施形態］
続いて、上記本発明の第１の実施形態に変更を加えた第２の実施形態について説明する。本発明の第２の実施形態は、上記第１の実施形態と同一の構成で実現可能であり、基本的な動作も共通するので、以下、その相違点を説明する。

本発明の第２の実施形態では、上記第１の実施形態における図６のステップＳ２０４と、図７のステップＳ３０５をそれぞれ省略するものである。

このように、図６のステップＳ２０４と、図７のステップＳ３０５を省略することで処理の高速化が期待できる。なお、Ｅ−ＦＥＫ記憶部４０２の漏洩と、ユーザやサービスの秘密鍵の漏洩が同時に起こった場合に、各ファイルの暗号化に使用したＦＥＫが計算されてしまう可能性が生じるが、これについては、別途、既存の情報漏洩策を講ずればよい。

［第３の実施形態］
続いて、上記本発明の第１の実施形態に変更を加えた第３の実施形態について説明する。本発明の第３の実施形態は、上記第１の実施形態と同一の構成で実現可能であり、基本的な動作も共通するので、以下、その相違点を説明する。

本発明の第３の実施形態では、上記第１の実施形態における図７のステップＳ３１５を省略するとともに、図５のステップＳ１０８を省略するものである。

このように、図７のステップＳ３１５と、図５のステップＳ１０８を省略することで、
Ｅ−ＦＥＫ記憶部４０２に、ストレージサーバの公開鍵と対応するＥ−ＦＥＫを格納しなくて済むようになる。これは、ストレージサービス提供者側ですらファイルの内容にアクセスすることはできないという厳格なファイル管理ができることを意味する。

［第４の実施形態］
続いて、上記本発明の第１の実施形態に変更を加えた第４の実施形態について説明する。本発明の第４の実施形態は、上記第１の実施形態とほぼ同一の構成で実現可能であり、基本的な動作も共通するので、以下、その相違点を説明する。

本発明の第４の実施形態では、ストレージサーバ３００が、Ｅ−ＦＥＫ記憶部４０２に記憶するリスト６００（図４参照）を、別途定めた共通鍵暗号等を用いて、暗号化するものである。

このようにＥ−ＦＥＫ記憶部４０２に記憶するリスト６００（図４参照）を暗号化することで、ユーザやサービスインスタンスの秘密鍵が漏洩してしまい、かつ、その情報が無効化公開鍵リスト記憶部４０３に登録される前であっても、各ファイルの暗号化に用いたＦＥＫの安全性を向上させることができる。

［第５の実施形態］
続いて、上記本発明の第１の実施形態に変更を加えた第５の実施形態について説明する。本発明の第５の実施形態は、上記第１の実施形態とほぼ同一の構成で実現可能であり、基本的な動作も共通するので、以下、その相違点を説明する。

本発明の第５の実施形態では、クライアント１００またはサービスインスタンス２００のファイル暗復号処理部１０３、２０３が、ＦＥＫでファイル全体を一度に暗号化するのではなく、ファイルをより小さな構成単位に分割したものを単位に、暗復号するようにしたものである。

このようにより細かい単位で暗復号するようにすることで、ファイルの部分更新時の性能が改善される。

以上、本発明の実施形態を説明したが、本発明は、上記した各実施形態に限定されるものではなく、本発明の基本的技術的思想を逸脱しない範囲で、更なる変形・置換・調整を加えることができる。

例えば、上記した各実施形態では、ストレージサーバ３００側にＦＥＫ生成器を備えた構成を前提に説明したが、図８に示すように、クライアント１００（サービスインスタンス２００も同様）側に、ＦＥＫ生成器１０４を配置する構成も採用可能である。この場合、原則として、クライアント１００でＦＥＫの暗復号が行われることになる。また、この場合、システム全体で、ユニークなＦＥＫ ＩＤを採番する必要があるが、例えば、各クライアント１００に、予めクライアント毎に、ＦＥＫ ＩＤを割り当てておく方法やＦＥＫ ＩＤの作成ルールを取り決めておく方法を採用できる。後者のＦＥＫ ＩＤの作成ルールとしては、例えば、ＦＥＫのハッシュ値などを元にＦＥＫ ＩＤを採番して払い出すモジュールをストレージサーバ３００および各クライアント１００側に備えておく方法が考えられる。

例えば、上記した各実施形態では、サービスユーザリスト記憶部４０４は、ストレージサーバ３００からアクセスされるものとして説明したが、図８に示すように、サービスインスタンス２００側でサービスユーザリスト記憶部２０６を管理する構成も採用可能である。

本発明は、ネットワークを介して複数のユーザにディスクスペースを提供するストレージサービスや、ウェブベースのサービスのバックエンドのストレージシステムといった用途に適用できる。

最後に、本発明の好ましい形態を要約する。
［第１の形態］
（上記第１の視点によるファイル管理システム参照）
［第２の形態］
第１の形態において、
前記暗号化ファイル暗号鍵記憶部は、ファイル暗号鍵毎に、各ユーザまたはサービスの公開鍵と、当該公開鍵を用いて暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）の組を列記したリストにより、公開鍵と暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）の組を管理するファイル管理システム。
［第３の形態］
第１、２の形態において、
前記ストレージサーバが、無効化された公開鍵を格納するリストに、前記ユーザまたはサービス毎に定められた公開鍵が格納されているか否かにより、前記公開鍵の有効性を確認するファイル管理システム。
［第４の形態］
第１−３の形態において、
前記ストレージサーバが、前記公開鍵の有効性の確認の結果、有効でないと判定された公開鍵にて暗号化された前記暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を、書き換えまたは削除するファイル管理システム。
［第５の形態］
第１−４の形態において、
前記暗号化ファイル暗号鍵記憶部には、前記ストレージサーバの公開鍵で暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）が格納されており、
前記ストレージサーバは、前記自身の公開鍵で暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を、前記公開鍵に対応する秘密鍵で復号して得られたファイル暗号鍵（ＦＥＫ）を、新規に追加するユーザまたはサービスの公開鍵で暗号化することにより、前記暗号化ファイル暗号鍵記憶部に、ファイルへのアクセス権を持つユーザまたはサービスの暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を追加するファイル管理システム。
［第６の形態］
第１−５の形態において、
さらに、サービスインスタンスとそのサービスインスタンスを利用するユーザの組を格納するサービスユーザリストを用いてユーザを管理するファイル管理システム。
［第７の形態］
（上記第２の視点によるストレージサーバ参照）
［第８の形態］
（上記第３の視点によるクライアント参照）
［第９の形態］
（上記第３の視点によるサービスインスタンス参照）
［第１０の形態］
（上記第４の視点によるファイル管理方法参照）
［第１１の形態］
（上記第５の視点によるプログラム参照）
［第１２の形態］
（上記第５の視点によるプログラム参照）
なお、上記第７〜第１２の形態は、第１の形態から派生する第２〜第６の形態と同様に展開することが可能である。

１０Ａ、１０Ｂ、１００ クライアント
２０、３００ ストレージサーバ
２１ アクセス要求受付部
２２ ファイル暗号鍵暗号化部
２３ 無効化公開鍵情報記憶部
２５、４０２ 暗号化ファイル暗号鍵記憶部（Ｅ−ＦＥＫ記憶部）
２６、４０１ 暗号化ファイル記憶部
１０１ ファイル入出力部
１０２ ＦＥＫ暗復号処理部
１０３ ファイル暗復号処理部
１０４、３０４ ＦＥＫ生成器
１０５、２０５、３０３ 通信部
２００ サービスインスタンス
２０１ サービス実行部
２０２ ＦＥＫ暗復号処理部
２０３ ファイル暗復号処理部
２０６、４０４ サービスユーザリスト記憶部
３０１ デジタル署名検証部
３０２ 認証部
３０５ ＦＥＫ暗復号処理部
３０６ ストレージアクセス部
３０７ リクエスト有効性検証部
４０１ 暗号化ファイル記憶部
４０２ Ｅ−ＦＥＫ記憶部
４０３ 無効化公開鍵リスト記憶部
５００ 暗号化ファイル
５０１ 暗号化ファイル本体
５０２ ＦＥＫ ＩＤ
６００ リスト

Claims (10)

1. 予め定められたファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備えるストレージサーバと、
   前記ストレージサーバから受け取った前記暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を前記公開鍵に対応する秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアントまたはサービスインスタンスと、を含み、
   前記ストレージサーバは、前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すファイル管理システム。
2. 前記暗号化ファイル暗号鍵記憶部は、ファイル暗号鍵毎に、各ユーザまたはサービスの公開鍵と、当該公開鍵を用いて暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）の組を列記したリストにより、公開鍵と暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）の組を管理する請求項１のファイル管理システム。
3. 前記ストレージサーバは、無効化された公開鍵を格納するリストに、前記ユーザまたはサービス毎に定められた公開鍵が格納されているか否かにより、前記公開鍵の有効性を確認する請求項１または２のファイル管理システム。
4. 前記ストレージサーバは、前記公開鍵の有効性の確認の結果、有効でないと判定された公開鍵にて暗号化された前記暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を、書き換えまたは削除する請求項１から３いずれか一のファイル管理システム。
5. 前記暗号化ファイル暗号鍵記憶部には、前記ストレージサーバの公開鍵で暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）が格納されており、
   前記ストレージサーバは、前記自身の公開鍵で暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を、前記公開鍵に対応する秘密鍵で復号して得られたファイル暗号鍵（ＦＥＫ）を、新規に追加するユーザまたはサービスの公開鍵で暗号化することにより、前記暗号化ファイル暗号鍵記憶部に、ファイルへのアクセス権を持つユーザまたはサービスの暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を追加する請求項１から４いずれか一のファイル管理システム。
6. さらに、サービスインスタンスとそのサービスインスタンスを利用するユーザの組を格納するサービスユーザリストを用いてユーザを管理する請求項１から５いずれか一のファイル管理システム。
7. ストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ；Ｅｎｃｒｙｐｔｅｄ−Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアントまたはサービスインスタンスと、接続され、
   ファイル暗号鍵（ＦＥＫ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備え、
   前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すストレージサーバ。
8. 請求項７のストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ；Ｅｎｃｒｙｐｔｅｄ−Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いてファイルを暗復号する暗復号処理部と、を備えるクライアント。
9. 請求項７のストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ；Ｅｎｃｒｙｐｔｅｄ−Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を秘密鍵で復号する復号処理部と、前記復号したファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いてファイルを暗復号する暗復号処理部と、を備えるサービスインスタンス。
10. 予め定められたファイル暗号鍵（ＦＥＫ；Ｆｉｌｅ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ）を用いて暗号化されたファイルを格納する暗号化ファイル記憶部と、ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵を用いて、前記ファイル暗号鍵（ＦＥＫ）を暗号化した暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を格納する暗号化ファイル暗号鍵記憶部と、を備えるストレージサーバが、クライアントまたはサービスインスタンスからの要求に応じて、前記ファイルへのアクセス権を持つユーザまたはサービス毎に定められた公開鍵の有効性を確認してから、前記クライアントまたはサービスインスタンスに対し、暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を払い出すステップと、
    前記クライアントまたはサービスインスタンスが、前記ストレージサーバから受け取った暗号化ファイル暗号鍵（Ｅ−ＦＥＫ）を前記公開鍵に対応する秘密鍵で復号するステップと、
    前記復号したファイル暗号鍵（ＦＥＫ）を用いてファイルを暗復号する暗復号ステップと、
    を含むファイル管理方法。

Images