(57)【要約】      （修正有）【課題】機密データを安全な方法で効率よく限られた複数のメンバーで共有する暗号化プログラムと復号化プログラムとファイル管理プログラムとを含むファイル共有補助システムを提供する。。【解決手段】暗号化プログラムは、予め生成された共通鍵に基づいてパスワードを生成し生成したパスワードを用いて１つ以上のファイル又はフォルダを暗号化する。復号化プログラムはパスワードによって暗号化ファイルを復号化する。ファイル管理プログラムは、ストレージサーバーとの共有フォルダと、予め指定されたローカル保存用フォルダとを比較監視し、ローカル保存用フォルダ内に保存された１つ以上のファイル又はフォルダを暗号化してから共有フォルダ内にコピーし、共有フォルダ内に保存された暗号化ファイルを認識するとローカル保存用フォルダ内にコピーし、復号化してローカル保存用フォルダ内に保存する。【選択図】なし【特許請求の範囲】
【請求項１】
ファイル共有補助システムであって、
暗号化プログラムと、復号化プログラムと、ファイル管理プログラムとを含み、
前記暗号化プログラムは予め生成された又は前記システムが生成した共通鍵に基づいてパスワードを生成すると共に、前記生成したパスワードを用いて１つ以上のファイル又はフォルダを暗号化して暗号化ファイルを生成する機能を有し、
前記復号化プログラムは前記生成したパスワードによって前記暗号化ファイルを復号化する機能を有し、
前記ファイル管理プログラムは、
（１）ネットワークを通じて接続されたストレージサーバーとの共有フォルダと、予め指定されたローカル保存用フォルダとを比較監視し、
（２）前記ローカル保存用フォルダ内に保存された１つ以上のファイル又はフォルダを、前記暗号化プログラムによって暗号化してから前記共有フォルダ内にコピーすると共に、
（３）前記共有フォルダ内に保存された暗号化ファイルを認識すると前記ローカル保存用フォルダ内にコピーし、復号化して前記ローカル保存用フォルダ内に保存する
機能を有することを特徴とするファイル共有補助システム。
【請求項２】
前記ファイル管理プログラムは、
前記共有フォルダ内に複数のユーザーＩＤを記録したＩＤファイルと前記暗号化ファイルの復号化処理が完了したユーザーＩＤとを記録した履歴ファイルとを保持し、
前記履歴ファイルを監視して、前記ＩＤファイルに含まれる全てのユーザーＩＤが、特定の暗号化ファイルのコピー及び復号化処理を終えたと判定した以後、当該暗号化ファイルを削除する機能を有する請求項１記載のファイル共有補助システム。
【請求項３】
前記暗号化プログラムは、ランダムな文字列を生成して、前記暗号化ファイルのファイル名として保存する機能を有する請求項１又は請求項２記載のファイル共有補助システム。
【請求項４】
前記生成したパスワードは、前記共通鍵と他の情報とに基づいて一意に生成されたワンタイム・パスワードであることを特徴とする請求項１乃至請求項３のいずれか１項記載のファイル共有補助システム。
【請求項５】
前記暗号化プログラムは、
フォルダ構造を維持したままファイルサイズを圧縮して暗号化ファイルを生成することを特徴とする請求項１乃至請求項４のいずれか１項記載のファイル共有補助システム。
【請求項６】
前記ファイル共有補助システムは、前記暗号化ファイルを復号化した後、さらに、前記ローカルディスクのユーザーが入力した任意のパスワードを用いて再度暗号化する機能を有するプログラムをさらに含むことを特徴とする請求項１乃至請求項５のいずれか１項記載のファイル共有補助システム。
【請求項７】
前記再度暗号化する機能は、１ファイルごとに又は複数のファイル又はフォルダを圧縮ファイル形式として暗号化するか、又は自走式の暗号化機能を用いて暗号化する機能を有することを特徴とする請求項６記載のファイル共有補助システム。
【請求項８】
前記ローカル保存用フォルダ内に保存されたデータを前記ローカルディスクのユーザーが入力した任意のパスワードで暗号化しまたは暗号化することなく前記ローカル保存用フォルダとは異なるフォルダ内にコピーする機能を実行するプログラムをさらに含むことを特徴とする請求項１乃至請求項７のいずれか１項記載のファイル共有補助システム。
【請求項９】
前記共有フォルダ内に、任意の暗号化ファイルを常時１つ以上保持し、
前記共通鍵又は前記共通鍵に基づいて生成されたパスワードによって復号できた場合に、当該共有フォルダを当該ユーザーのローカルディスク内に登録することを許可することを特徴とする請求項１乃至請求項７のいずれか１項記載のファイル共有補助システム。
【請求項１０】
前記ファイル共有補助システムを利用する各ユーザーに割り当てるための秘密鍵と公開鍵のペアをそれぞれ生成すると共に
前記各ユーザーの公開鍵で前記共通鍵を暗号化し、
前記各ユーザーの公開鍵で暗号化された共通鍵を前記各ユーザーの秘密鍵で暗号化する機能を具備することを特徴とする請求項１乃至請求項９のいずれか１項記載のファイル共有補助システム。
【請求項１１】
前記公開鍵及び前記公開鍵で暗号化された共通鍵の受け渡しの少なくともいずれかを前記ストレージサーバーを介して実施することを特徴とする請求項１０記載のファイル共有補助システム。
【請求項１２】
１つのプロジェクトに対して、１組のローカル保存フォルダ及び共有フォルダを各ユーザーが利用する端末に割り当てることを特徴とする請求項１乃至１１のいずれか１項記載のファイル共有補助システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子データを、オープンな通信回線網を通じて安全に配布するファイル共有のためのファイル共有補助システムに関する。
【背景技術】
【０００２】
ファイル共有の技術として、ネットワークに接続された端末のローカルディスク内に保存された電子データを、ネットワーク越しに複数人で共有することを可能にするファイル同期サービスが知られている。このようなサービスは、クラウド上のファイル同期サーバーを介して実現される。しかし、クラウド上のサーバーに電子データ、特に、機密性の高いデータを保存することは、組織やチームのセキュリティ上問題視される場合がある。
【０００３】
「サーバにアクセスして秘密データを検索、閲覧するシステムに関する技術」として、秘密データを予め安全な方法で利用者に配布しておき、インターネットなどのオープンな通信回線で検索条件をサーバに渡し、サーバは検索を行い該当するデータの識別子だけを利用者の端末機に返し、利用者に渡されセットされた秘密データを利用者の端末機に表示し参照する秘密データ閲覧システムが知られている（特許文献１）。
【０００４】
このシステムによれば、サーバがデータ削除情報を識別子で渡し、サーバがデータの更新情報として識別子と更新情報のみを渡すことで、利用者ごとに秘密データに追跡情報を入れることにより遺漏した場合の追跡が可能となる。また、秘密データ（Ｈ）をサーバ（Ｚ）上に常時保存しないようにするために、「期限を切ってサーバ（Ｚ）に秘密データ（Ｈ）を保存し上記安全性の高い通信回線で受け取る」などの方法が開示されている。
【０００５】
また、マルチメディアデータに電子透かしを埋め込み、本人であることが確認された場合にのみその配信用データから機密データを取り出すデコーダ手段を備えた機密データ配信システムなども知られている（特許文献２）
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１８５１７６号公報
【特許文献２】特開２０００−６８９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、上記特許文献１のシステムでは、秘密データそのものは運送などの安全な手段で利用者に配布しておく必要がある。上記特許文献２では、「電子透かし」を受け込む操作が必要となり、また、そもそも「電子透かし」を埋め込むことのできないファイルには対応できない。
【０００８】
ファイルを共有するためのもっとも手軽な方法として、パスワードで暗号化した機密データを電子メールに添付して送付する方法がある。この方法は、（１）万一誤送信した場合、回復不可能（すなわち、データを回収する方法がなく、悪意のある第三者が送信データを取得した場合、時間をかければデコードが可能）であること、（２）実際にはパスワード自体も電子メールで別送しているケースも散見され、その場合電子メールのアカウント情報が漏えいした場合等にはセキュリティーを担保できないこと、（３）電子メールを送信する毎に暗号化する手間が必要であること、（４）パスワードを使い回されていると、別サービスのパスワードが漏えいするという脆弱性を含むこと（パスワードリスト攻撃）、（５）送信可能なデータ容量が制限されること、など、種々の問題がある。
【０００９】
共有すべき機密データを配布者が先ず、ファイルサーバーなど、配布先のメンバーがアクセス可能なインターネット上のサーバー上に保存し、そのリンク先を電子メールで送付するという方法もある。この方法は、上記の方法と比べると、万一誤送信に気づいた場合には、直ちにリンク先を変更するなどの対処が可能であり、また電子メールよりも大容量のファイルを送信しやすいなどの利点はある。しかし、メールアカウントのハッキングに対する脆弱性があることは、電子メール同様である。公開状態となっているリンクと、単一のパスワードのみでデータ受信が可能となるものも多く、アクセス制御にも難がある。更に、送信側、受信側いずれにも手作業が必要となり、煩雑である（頻回に送信している場合、ダウンロードされずに放置されるケースもある）。アップロードデータ自体を暗号化する運用をとると、送信側受信側共に更に煩雑となる。そのため、今度はリンクやファイルのパスワードがいずれも簡単なものとなるなど形骸化するおそれがある。
【００１０】
チャットやファイル同期サービス、その他のクラウドサービスを利用してデータを共有する方法も考えられる。
しかし、クラウド上へのデータ保存は、そもそも第三者への機密情報委託を意味しており、そのこと自体がリスクと評価される。更に、クラウド上に全データを長期に保存し続けることは、セキュリティリスクを大きく高める。
一方、エンドツーエンドの暗号化を実現するショートメッセージサービスなども存在するが、多数・大容量のファイルを転送するのに適した設計とはいえない。
【００１１】
インターネットのようなオープンな通信回線網上で、様々なデータ形式で保存された機密データを安全に配布することは、意外に難しい。
特に、多数の電子ファイルを継続的かつ頻繁に配付するような場面（プロジェクト）において問題が大きくなる。前記各手法は、ファイルが膨大・多様な場面で、そもそも適用が困難であるか、セキュリティを担保できない。
更にプロジェクトにおいては、統一的な情報管理が要求されるが、受信側が毎回手動で保存操作をおこなわなければならない構成では、しばしば保存漏れが起きたり、データの所在もユーザー毎にまちまちとなるという問題が起きる可能性もあり、プロジェクトの情報共有に大きな支障をきたすおそれがある。
【００１２】
本発明は上記の問題に鑑みてなされたもので、インターネット上で、様々なデータ形式で保存された機密データを安全な方法で効率よく限られた複数のメンバーで共有する手段を提供することを主たる技術的課題とする。多量・継続的・頻繁なデータ配付に対応できることは課題の重要な一部である。更に、データの送受信を自動化すると共に、システム側がデータの整理をおこなうことが望まれる。
【課題を解決するための手段】
【００１３】
本発明に係るファイル共有補助システムは、
暗号化プログラムと、復号化プログラムと、ファイル管理プログラムとを含み、
前記暗号化プログラムは予め生成された又は前記システムが生成した共通鍵に基づいてパスワードを生成すると共に、前記生成したパスワードを用いて１つ以上のファイル又はフォルダを暗号化して暗号化ファイルを生成する機能を有し、
前記復号化プログラムは前記生成したパスワードによって前記暗号化ファイルを復号化する機能を有し、
前記ファイル管理プログラムは、
（１）ネットワークを通じて接続されたストレージサーバーとの共有フォルダと、予め指定されたローカル保存用フォルダとを比較監視し、
（２）前記ローカル保存用フォルダ内に保存された１つ以上のファイル又はフォルダを、前記暗号化プログラムによって暗号化してから前記共有フォルダ内にコピーすると共に、
（３）前記共有フォルダ内に保存された暗号化ファイルを認識すると前記ローカル保存用フォルダ内にコピーし、復号化して前記ローカル保存用フォルダ内に保存する
機能を有することを特徴とする。
【００１４】
上記のファイル共有補助システムは、このシステムを利用するユーザーのローカル端末上で実行されるプログラムとして実現されうる。ここで、ローカル端末とは、複数のユーザーでファイルを共有する際に、各ユーザーが用いるクライアント端末である。具体的には、デスクトップパソコンやノート型パソコン、タブレット端末などが該当する。ストレージサーバーとは、ファイル同期サービスを提供するクラウド上のファイルサーバーなどが典型例としてあげられる。但し、例えばＷｅｂサーバーやＦＴＰサーバーなど、ローカルエリアネットワーク内にあるＮＡＳその他、完全に信頼できる「ローカルストレージ」以外の、外部ネットワーク経由で提供されるストレージ全てが含まれる。ストレージサーバーは、それ自身が、パスワードなどによるアクセス制御能力を持っていることが想定される。また、「ローカル保存用フォルダ」とは、各ローカル端末に接続されたローカルディスク内のフォルダを、「共有フォルダ」とは、ストレージサーバー上で複数のユーザーが共有するためのフォルダを指す。
【００１５】
共通鍵は、例えば、共通鍵を記録媒体に保存したキーファイルを、運送するなどの安全な方法で予め各ユーザーのローカルディスク内にコピーしておくという方法が考えられる。なお、共通鍵１つで構成することに代えて、秘密鍵と公開鍵とを用いた公開鍵暗号方式を採用することも可能である。この場合、ストレージサーバーを介して他のユーザーと鍵を交換できる。
【００１６】
このようなシステムによれば、各ローカル端末側に保存されたファイルが、パスワードで暗号化された状態でネットワーク上のストレージサーバーに同期（コピー）される。そして、ストレージサーバー上の暗号化ファイルは他のユーザーのローカルディスクに同期（コピー）された後、各ユーザーの端末で復号化され、結果として、全てのユーザーが同じファイルを複数のユーザーで安全に共有することができる。しかも、ストレージサーバーとの共有フォルダに保存されるファイルは暗号化されているため、機密性が保持される。
【００１７】
上記構成におけるファイル管理プログラムは、
前記共有フォルダ内に複数のユーザーＩＤを記録したＩＤファイルと、前記暗号化ファイルの復号化処理が完了したユーザーＩＤとを記録した履歴ファイルとを保持し、
前記履歴ファイルを監視して、前記ＩＤファイルに含まれる全てのユーザーＩＤが、特定の暗号化ファイルのコピー及び復号化処理を終えたと判定した以後、当該暗号化ファイルを削除する機能を有するように構成してもよい。
【００１８】
このように、ストレージサーバーとの共有フォルダに保存される暗号化ファイルは、各ユーザーのローカルディスクにコピーされた後は、削除しても差し支えなく、むしろ速やかに削除されることはセキュリティー上も好ましい。その削除は、上記のようにファイル管理プログラムがユーザーＩＤと履歴ファイルとを用いて自動的に行うこともできる。
【００１９】
また、上記構成における前記暗号化プログラムは、ランダムな文字列を生成して、前記暗号化ファイルのファイル名として保存する機能を有していてもよい。このようにすれば、ファイル名から内容を推測されるリスクを防止できるからである。
【００２０】
また、上記構成における前記生成したパスワードは、前記共通鍵と他の情報とに基づいて一意に生成されたワンタイム・パスワードであってもよい。他の情報とは、暗号化を行うファイル名やフォルダ名、或いは暗号化の日時などの情報とすることが考えられる。
【００２１】
また、暗号化前のデータがフォルダである場合は、前記暗号化プログラムは、フォルダ構造を維持したままファイルサイズを圧縮して暗号化ファイルを生成するように構成しておくことが好ましい。このようにすれば、配布先においてファイルを復号化して得られる圧縮ファイルを展開すれば、フォルダ構造を維持したまま暗号化前のフォルダ構造が復元されるからである。
【００２２】
また、上記構成における前記ファイル共有補助システムは、前記暗号化ファイルを復号化した後、さらに、前記ローカルディスクのユーザーが入力した任意のパスワードを用いて再度暗号化する機能を有するプログラムをさらに含むようにしてもよい。このようにすれば、各ユーザーが必要に応じてセキュリティーを高めてデータを安全に保存できるからである。なお、この場合の前記再度暗号化する機能は、１ファイルごとに又は複数のファイル又はフォルダを圧縮ファイル形式として暗号化するか、又は自走式の暗号化機能を用いて暗号化する機能を有するように構成してもよい。ここで、自走式暗号ファイルとは、パスワードにより復号可能な自己復号型の実行ファイル(ｅｘｅ形式とする、あるいはｐｄｆ形式などの各バイナリ形式自身が保持する暗号化機能を利用するもの)である。
【００２３】
また、前記ローカル保存用フォルダ内に保存されたデータを、前記ローカルディスクのユーザーが入力した任意のパスワードで暗号化しまたは暗号化することなく、前記ローカル保存用フォルダとは異なるフォルダ内にコピーする機能を実行するプログラムをさらに含むように構成してもよい。本ファイル管理プログラムは、ストレージサーバーに常時暗号化データを保存し続けるのではなく、あくまでファイルデータの受け渡しのために利用することを前提とする。このため、データの受け渡し後は、各ユーザーが自身のローカル端末のローカルディスク内でデータを管理する必要がある。このようなニーズに対応するため、各ユーザーがローカルエリアネットワーク内のＮＡＳや、ローカル端末に接続されたバックアップ用のハードディスクディスク等にコピーしておく機能があれば、万一ファイルが破損したり誤って削除したりした場合にも、容易に復元できるからである。
【００２４】
また、前記共有フォルダ内に、任意の暗号化ファイルを常時１つ以上保持し、前記共通鍵又は前記共通鍵に基づいて生成されたパスワードによって復号できた場合に、当該共有フォルダを当該ユーザーのローカルディスク内に登録することを許可するように構成してもよい。
【００２５】
また、前記ファイル共有補助システムを利用する各ユーザーに割り当てるための秘密鍵と公開鍵のペアをそれぞれ生成すると共に前記各ユーザーの公開鍵で前記共通鍵を暗号化し、前記各ユーザーの公開鍵で暗号化された共通鍵を前記各ユーザーの秘密鍵で暗号化する機能を具備するように構成してもよい。この場合、前記公開鍵及び前記公開鍵で暗号化された共通鍵の受け渡しの少なくともいずれかを前記ストレージサーバーを介して実施することが可能である。
【００２６】
上記のファイル共有補助システムは、１つのプロジェクトに対して、１組のローカル保存フォルダ及び共有フォルダを各ユーザーが利用する端末に割り当てるようにしてもよい。
【発明の効果】
【００２７】
本発明に係るファイル共有補助システムによれば、インターネットのようなオープンな通信回線網上で、（例えばクラウド上の）ファイル同期サーバーなどを介して様々なデータ形式で保存された機密データを安全かつ効率よく限られた複数のメンバーに配布することが可能となる。
【図面の簡単な説明】
【００２８】
【図１】図１は、第１の実施形態を説明するための図であり、ファイル同期サービスを提供するクラウド上のサーバーに、インターネットを介して複数のローカル端末が接続されている様子を示す図である。
【図２】図２は、第１の実施形態を説明するための図であり、端末Ａからクラウド上のファイル同期サーバー１０に暗号化ファイル３０がアップロードされ、その暗号化ファイル３０が他の端末にダウンロードされる様子を説明するための図である。
【発明を実施するための形態】
【００２９】
（実施形態）
−前提条件−
本実施形態では、共同で取り組む案件（プロジェクト）Ｐに関連して、例えば、毎月１００件以上の機密文書を継続的に共有しようとしている弁護士がユーザーであると想定する。そこで、以下では一般的な弁護士が用いる環境を踏まえ、次のような前提状況があるものとして説明を進める。
【００３０】
利用ＯＳ：  「ｗｉｎｄｏｗｓ（登録商標）１０」
ファイル同期に用いるソフトウェア：  「Ｄｒｏｐｂｏｘ」（同期プログラム）
ユーザー    管理ユーザーＡ（端末Ａ）、一般ユーザーＢ，Ｃ，Ｄ（端末Ｂ，Ｃ，Ｄ）
（ここで、ユーザーらはいずれも弁護士であることを想定する）
暗号化に用いるプログラム：  ７ｚｉｐ
【００３１】
図１に示すように、クラウド上のファイル同期サーバー１０が、複数のローカル端末２０（端末Ａ、端末Ｂ、端末Ｃ、・・・）に接続されている状況を想定する。
【００３２】
１  プログラムの配付・インストール
本件実施形態で説明するアルゴリズムは、一般的なプログラミング言語であれば実装することができる。発明者はＰｙｔｈｏｎを用いて動作を確認している。本件発明にかかるシステムは適宜の方法で実行ファイル化するなどして、あらかじめユーザーに配付し、各端末にインストールしておく。通常の実装ではプログラムは軽量かつシンプルなものとなり、インストールにあたって特別な困難はない。暗号化プログラムとして７ｚｉｐを用いる想定であれば、システムと共に７ｚｉｐも配付する。
【００３３】
２  フォルダの作成
典型的な実装においては、各端末に、以下の２種類のフォルダを作成する。
・ローカル保存用フォルダ
各ローカル端末２０におけるローカルディスク内のフォルダの１つを、「ローカル保存用フォルダ」として設定する。ローカル保存用フォルダは、プロジェクトにおいて共有された電子文書を保存するためのフォルダである。一般的には、自身が共有したファイルと、他のユーザーが共有したファイルとを区別せず、同一のフォルダに保存するように構成することが便利である。
・共有フォルダ
一方、各ローカル端末２０におけるローカルディスク内の他のフォルダの１つを、「共有フォルダ」として設定する。クラウド上のファイル同期サーバー１０と同期させるためのフォルダとして他ユーザーとのデータ共有に用いるためのフォルダである。共有フォルダはファイル同期サービスの配下フォルダ内に準備する。共有フォルダに保存されたファイルは、ファイル同期サーバー１０を介して他のローカル端末に同期される。
【００３４】
ローカル保存用フォルダは、ローカル端末で作成された文書データや、各ユーザーとの間で共同作業を行う際にプログラムなどによって生成されたファイルデータ（例えば、データベースファイル等）が保存されるフォルダである。このローカル保存用フォルダは共有フォルダとは別に設ける。
【００３５】
以上を踏まえ、本実施例では、次のようにフォルダを準備したものとする。
ユーザーＡの端末（端末Ａ）
ローカル保存フォルダは、共有されない場所に１個のフォルダを準備する。
（例）C:\Users\userA\Documents\projectP_local
共有フォルダはＤｒｏｐｂｏｘフォルダの配下に１個のフォルダを準備する。
（例）C:\Users\userA\Dropbox\projectP_share
ユーザーＡは、Ｄｒｏｐｂｏｘ上で所要の操作をし、上記の共有フォルダを、ユーザーＢ，Ｃ，Ｄの端末（端末Ｂ，Ｃ，Ｄ）上で共有するものとする。その結果、たとえばユーザーＢの端末Ｂは次のようなフォルダ状況となる。
ローカル保存フォルダは、任意の場所に作成しておく。
（例）C:\Users\userB\myProjectFolders\projectP_local
共有フォルダは、Ｄｒｏｐｂｏｘ上で共有された結果として生成される。
（例）C:\Users\userB\Dropbox\projectP_share
ユーザーＣ，Ｄの端末（端末Ｃ，Ｄ）についても同様となる。
【００３６】
３  共通鍵の生成と配布
次に、各ユーザー間で共通鍵Ｋ（キーファイル）を共有する。共通鍵Ｋは乱数或いはランダムな文字列で構成され、かつ、十分な長さがあればそれで足りるが、実施例のシステムに共通鍵生成機能を持たせることもできる。本実施例ではシステムが共通鍵生成機能を有するものとし、管理ユーザーＡは、自身の端末Ａにおいて所要の操作をおこない、実施例のシステムで１２８ｂｉｔの共通鍵Ｋを生成したとする。
管理ユーザーＡは、共通鍵Ｋを安全な方法でユーザーＢ，Ｃ，Ｄの端末（端末Ｂ，Ｃ，Ｄ）に受け渡す。たとえば、ＵＳＢメモリなどの物理媒体に保存して、物理的な手段で受け渡す方法をとる。ユーザーＢ，Ｃ，Ｄは、共通鍵Ｋをシステムに認識させて、それぞれの端末内に保存する。
共通鍵Ｋの保存場所は、システムに認識可能な場所であればそれで足りる。ローカル保存用フォルダ内であってもよいし、適宜の場所にフォルダを生成してもよい。共通鍵Ｋは平文で保存してもよいが、システムに組み込んだ鍵を利用するなどして更に暗号化することで、セキュリティを高めることもできる。
なお、ユーザーの利便性を高める上では、共通鍵Ｋも自動で共有できることが望ましい。そのためのアルゴリズムとして、公開鍵暗号を用いて共通鍵Ｋを配付する方法もある（後述）。
ここまでが、システム稼働のための準備となる。
【００３７】
４  ファイルを認識させる操作
次に、ファイルを暗号化して共有するプロセスについて説明する。
たとえば、ユーザーＡが、自身の端末Ａ内に、新たに機密文書００１〜機密文書１００の１００個のファイル（例えば、ｐｄｆファイル）を取得又は作成したとし、これをユーザーＢ，Ｃ，Ｄに共有しようと考えたとする。
初めに、ユーザーＡは（自身の端末Ａ内の）システムに対して、所定の操作をおこなって、共有するためのファイルを認識させる。実装としては大きく２通り考えられる。
ａ．所定のインターフェースで、システムにファイルを認識させる。たとえば、ファイル選択ダイアログやドラッグアンドドロップを利用する。
ｂ．共有ファイルを投入するためのフォルダを利用する。たとえば、「送信フォルダ」を準備して、そこに共有するファイルをコピーさせる。システムは所定の操作によって、あるいはフォルダを監視して、送信フォルダ内のファイルを、共有対象のフォルダとして認識する。
【００３８】
５  ファイルの暗号化と共有
システムはファイルを認識すると、これに対して暗号化処理を行う。７ｚｉｐを用いる実装においては次のような方法となる。
システムは共通鍵Ｋを利用して、適宜のアルゴリズムによって、十分な強度のパスワード（たとえば１６桁）を生成する。システムは、７ｚｉｐのプログラムを実行し、生成したパスワードを用いて、ファイルを７ｚｉｐ形式で暗号化する。
ここで、７ｚｉｐファイルは、１ファイルに対して１個作成してもよいし、複数ファイルをまとめて１個の７ｚｉｐとしてもよい。一般的には適宜の大きさのサイズ（たとえば２０ＭＢ）となるように、ファイルサイズを計算して組み合わせるように実装することが望ましい。
【００３９】
ここでセキュリティを強化するために、ｚｉｐファイルのパスワードをワンタイムパスワードとしてもよい（実装は後述）。
システムは上記のように暗号化したファイルを共有フォルダ内にコピーする。ここでは、７ｚｉｐファイル０１〜７ｚｉｐファイル１０がコピーされたものとする。
なお、実際の７ｚｉｐプログラムは、指定したパスに７ｚｉｐファイルを生成するものとなっているので、暗号化とコピーとは、処理としては一体化している。
また、システムは、この時点で、送信者であるユーザーＡの端末Ａのローカル保存フォルダに、当該機密文書００１〜１００をコピーするように構成することができる。このように実装することで、ユーザーは、送信ファイル、受信ファイルの双方を含めて、プロジェクトの文書を１個のフォルダ内で統一的に管理することができるようになる。
【００４０】
６  共有されたファイルの復号化
上記の処理を終えると、Ｄｒｏｐｂｏｘのソフトウェアによって、ユーザーＢ，Ｃ，Ｄの共有フォルダ（Ｄｒｏｐｂｏｘのフォルダ）内には、７ｚｉｐファイル０１〜７ｚｉｐファイル１０が共有された状態となる。
システムは共有フォルダ内に新たな７ｚｉｐファイルを見つけると、これを復号化して、自身のローカル保存フォルダ内にコピーする。このとき、システムは前記３で配付済みの共通鍵Ｋを用い、前記５と同様のアルゴリズムを利用して、当該７ｚｉｐファイルのパスワードを自ら生成する。
以上の結果、たとえばユーザーＢは、自身のC:\Users\userB\myProjectFolders\projectP_localフォルダ内に、機密文書００１〜機密文書１００の１００個のファイルを取得することになる。
【００４１】
ここで、システムは、７ｚｉｐファイルを重複してダウンロードしないために、ダウンロードを終えたファイル名をログとして残すことが望ましい。なお、後述の実装によれば、７ｚｉｐファイル名は一意のものとなる。
また、Ｄｒｏｐｂｏｘ内に新たに共有された７ｚｉｐファイルを認識する方法としては、ユーザーの明示的な操作や、所定のイベント、あるいはフォルダの監視などの方法を利用することができる。
【００４２】
なお、上記の実装から明らかなように、本実施形態における共有処理は、随時双方向でなされるものではなく、指定したファイルを、指定したタイミングで共有させるものである。その意味で、「送信」「受信」に近いものとなる。本実施形態は共有対象として機密文書を想定している。機密文書は固定性・原本性が要求されることが多く、その内容が随時変更・更新されることは予定されないので、送信・受信型の構成が適する。
【００４３】
７  共有の完了とファイルの削除
以上のようにして、ユーザーＢ，Ｃ，Ｄ全員がファイルの復号化と、ローカル保存を終えたとする。
この段階で、共有フォルダ内の７ｚｉｐファイルはいずれも用済みとなり、任意のタイミングで削除することが許される。
ここで、共有フォルダ内にデータが存在する期間は短ければ短いほど、セキュリティを高めることができる。そこで、全ユーザーがローカル保存を終えた時点で、システムがそれを検知し、共有フォルダ内のファイルを自動的に削除する機能を実装してもよい（後述）。
【００４４】
全体の処理の流れは次のように整理される。
ここで、ステップＳ１として、「ユーザーＡのもとで共有すべきデータの変更（例えば、データベースファイルの更新や電子文書ファイルの追加）」が生じた状況を想定する。このとき、各ユーザーのローカル端末上で動作するファイル共有補助システムの動作は、下記の各ステップのとおりである（図２参照）。
【００４５】
Ｓ１：ユーザーＡのもとで共有すべきデータ（同期対象ファイル）が特定される（例えば、ローカル保存用フォルダに保存されることで特定される）
Ｓ２：端末Ａは共通鍵Ｋに基づいてパスワードを生成する
Ｓ３：端末Ａは生成したパスワードを用いて同期対象ファイルを暗号化し、暗号化ファイル３０を生成する
Ｓ４：端末Ａの共有フォルダに暗号化ファイル３０が保存される
Ｓ５：（ファイル同期サーバーを介して）他のユーザーのローカル端末内の共有フォルダに、端末Ａの暗号化ファイル３０が同期される
Ｓ６：端末Ｂのファイル共有補助システムが、端末Ｂの共有フォルダ内に暗号化ファイル３０を見つける
Ｓ７：Ｓ６で見つけた暗号化ファイル３０を端末Ｂ内の予め設定されたローカル保存用フォルダにコピーし、端末Ｂ内の共通鍵Ｋからパスワードを生成して暗号化ファイル３０を復号化する。
Ｓ８：他のユーザーＣ，Ｄの端末Ｃ，Ｄも同様にローカルに保存する。このとき、共有フォルダ内に、各ユーザーのダウンロードログを残すようにする。
Ｓ９：ユーザー全員（今回であればユーザーＢ，Ｃ，Ｄ）がローカル保存を終えると、最後にダウンロードした端末上で動作するプログラムがそれを検知する
Ｓ１０：検知後、システム（最後にダウンロードした端末）は共有フォルダ内の暗号化ファイル３０を削除する
【００４６】
ファイルの削除機能は必須ではないが、端末のハードウェア構成の制限などがない限り、一部の端末のみが有するよりもできるだけ全ての端末が有する構成とする方が、セキュリティーの観点からは好ましい。このような構成の方が、最後にファイル同期サーバーからデータをダウンロード（コピー）した端末が速やかにファイル同期サーバーから削除できる利点があるためである。
【００４７】
上記のようにすれば、クラウド上のファイル同期サーバーにデータが保存される期間は、全ユーザーが同期を終えるまでとなる。各ユーザーの利用形態にもよるが、その期間は通常、数時間から数日程度に収まることが期待できる。
上記の実施態様においては、暗号化の際に、７ｚｉｐを用いる例を挙げたが、他の暗号化プログラムを利用してもよい。
上記実施態様において、ユーザーがなんらかの理由で共通鍵Ｋを喪失することが考えられるが、その点は問題を生じない。全てのオリジナルデータは平文でローカルに保存されているから（いかなる処理段階であっても、少なくとも送信者のもとに平文データが必ずある）、共通鍵Ｋを喪失してもデータを喪失することはない。システムの稼働には共通鍵Ｋが必要であるが、別のユーザーのローカル端末内に共通鍵Ｋが残存していればそれを再度受領してもよいし、共通鍵Ｋを再発行し、再配布してもよい。
【００４８】
−実施形態の効果−
上記実施態様は、多量の電子ファイル（機密文書）を限られたメンバーに継続的かつ安全に配付するという課題を解決する。更にその送受信は自動化され、電子ファイルはシステムによって自動的に整理・保存される。
上記実施態様によれば、ファイルの共有は、ファイル保持を想定したクラウドサービスへのファイルアップロードによる。ファイル数やデータ量の上限が問題となることは事実上ない。また、ファイルは全てｚｉｐ形式となり、ファイルの種類による制限も生じない。
【００４９】
クラウドサーバーは、サーバー自身のアクセス制御機能（ワンタイムパスワード認証など信頼できる強度のものを含む）によって、メンバーのみのアクセスを許容する。更に、サーバー上のファイルはいずれもたとえば１６桁といった十分な強度のパスワードで暗号化されている。サービス提供者による閲読の可能性は否定される。
上記強度によれば、総当たりによるパスワードの解読は事実上不可能である。共通鍵なしでパスワードを生成することも想定されない。共通鍵はローカル端末のみに保持されており、クラウド上での漏洩リスクは無い（共通鍵によるエンドツーエンドの暗号化となっている）。更に、パスワードはファイルごとのワンタイムパスワードとすることもでき、よりセキュリティを高める。
【００５０】
ファイルの受信及び復号化はシステムによって自動化されており、煩雑さが回避されると共に、手作業に付きものの保存漏れが起きない。そして、ローカル保存フォルダ内のフォルダ構造やファイル名は、システムによって共通のルールで自動管理できる。送信者を含めた全ユーザーの間で、常に同一のフォルダ構成、ファイル構成が再現可能であり、統一的な情報共有が実現される。この特性を利用すると、ローカルインストール型の文書管理システムなどとも容易に協働できる。
更に、上記実施態様では、クラウド上にデータを常置することが回避されている。１回のデータ共有は、送信データのアップロードとダウンロード（ローカル保存）によって完結する。ファイルの受信後は、ファイルの自動削除が実施され、クラウド上でのデータ保存は、データの量及び期間の双方で最小限におさえられている。たとえば全データの数％程度を数日間クラウドに保持する程度となる。
更に、データの冗長化の恩恵も存在する。機密文書は喪失も許されない。本実施形態では、全ユーザーのローカルマシンの数だけデータは冗長化されており、外部サーバー等を利用することなく、事実上のバックアップが実現される。
【００５１】
一般的なデータ共有方法の問題点は次の通り解決される。
・電子メールの問題点
電子メールの利用においてはデータ量が限定され、かつ、多くの運用では毎回パスワードをメール送信している。更に手動でのダウンロード・保存によるデータの不統一が頻発する。上記実施態様はこれを解決している。
−リンク利用の問題点−
サーバーへのアップロードによるリンク発行（Ｆｉｒｅｓｔｏｒａｇｅなどのサービス）では、アクセス制御が１個のパスワードのみである上（しかもユーザーはしばしば非常に脆弱なものを設定する）、そのパスワードはメールで送信されることが多く、セキュリティに難がある。また、手動でのダウンロード・保存によるデータの不統一が頻発する。上記実施態様はこれを解決している。
・ファイル同期サービスの問題点
一般的なファイル同期サービスの運用では、プロジェクト内の全てのデータをクラウド上に常置しており、この点で（たとえ暗号化していても）リスクが高い。PDFファイルなどにパスワードを付加する運用がなされる場合もあるが、前記のように全データの常置というのが基本的リスクである上に、パスワードが大抵単一かつ脆弱となる（強固なものは煩雑で実用に堪えないし、パスワード喪失時に、全データが開かなくなるという別のリスクを強める）。上記実施態様はこれを解決している。
【００５２】
また、ファイル同期サービスの一般的利用においては、ファイル・フォルダ構成を完全に共有できる反面、１人のユーザーのデータの誤編集や誤削除が、直ちに全ユーザーに影響するという問題も知られている。本実施形態においては、ファイル・フォルダ構成を全ユーザーのローカルで同様に再現できるが、そこで仮に削除や編集をおこなっても、その結果は他のユーザーに影響しない。すなわち、機密文書の安全な保持を実現できる。
【００５３】
以上のように、本実施形態は、従来のファイル共有方法と比較して、優れた安全性と利便性を提供する。特に、プロジェクト形態で機密文書を継続的に共有する場面において高度の優位性を持つ。
【００５４】
−パスワード生成と暗号化−
ここで、共通鍵に基づくパスワードの生成について説明する。共通鍵と暗号化の対象となるファイル名又はディレクトリ名やタイムスタンプなどの情報とを用いて一意のパスワード（ワンタイム・パスワード）を生成する。このワンタイム・パスワードの生成には公知のハッシュ関数を用いることができる。このようにすれば、ファイル毎又はディレクトリ毎にパスワードが異なり、かつ、共通鍵なしでは復号できない。パスワードは、例えば２０桁以上のランダムな文字列のような、十分に暗号化強度の強いパスワードを用いることが好ましい。
【００５５】
このとき、暗号化ファイルの名称や拡張子もランダムな名称となるようにすれば、ファイル名からの漏洩を防ぐことができる。例えば、７ｚｉｐなどの公知の暗号化プログラムにＳＨＡ２５６など公知のハッシュ関数を組み合わせて実装可能である。７ｚｉｐの場合、暗号化強度はＡＥＳ２５６であり、また、ｚｉｐ形式とは異なりファイル名が隠蔽される。
【００５６】
−共通鍵の配布方法について−
上記のとおり、本実施形態においては、安全な手段で予め全ての端末に共通鍵を配布することが極めて重要となる。電子メールやウェブサイトなどインターネットを介しての配布は、避けるべきである。しかし、本システムを多数のプロジェクトで利用する場合などに、共通鍵配付の煩雑さを回避したい（ファイル同期サーバーを介して自動的に共通鍵も配付したい）というニーズが生じうる。その場合、ファイル同期サーバーと公知の公開鍵暗号を利用すれば、比較的安全に共通鍵を配布することもできる。以下、その方法について説明する。
【００５７】
いま、管理者ユーザーＡ（端末Ａ）から、一般ユーザーＢ〜Ｄ（端末Ｂ，端末Ｃ，端末Ｄとする）に、共通鍵（shared_key）を配布する場合について説明する。
【００５８】
前提として、まず管理ユーザーＡがシステム内で、プロジェクト立ち上げ操作をおこなったものとする。システムは、共通鍵を生成すると共に、Ｄｒｏｐｂｏｘ配下に共有フォルダを作成する。
ここでシステムは、共有フォルダ内に鍵共有処理のための専用フォルダを作成することが望ましい。たとえば、
C:\Users\userA\Dropbox\projectP_share\Key
というフォルダを設ける
ユーザーＡは、Ｄｒｏｐｂｏｘアプリ上で、前記共有フォルダ（projectP_share）をユーザーＢ，Ｃ，Ｄに共有する操作をおこなう。そして、ユーザーＢ，Ｃ，Ｄのシステムは、自身のＤｒｏｐｂｏｘフォルダの配下に、新たな共有フォルダの存在を認識する。
【００５９】
次に、一般ユーザーＢ〜Ｄのシステムは、端末内に公開鍵と秘密鍵の組を生成し保存する（公知のアルゴリズムを用いる）。
public_key_B  / private_key_B
public_key_C  / private_key_C
public_key_D  / private_key_D
【００６０】
ユーザーＢ、ユーザーＣ、ユーザーＤは、各自の端末内の共有フォルダに、自身の名前などを付したテキストファイルを作り、その中に自身の公開鍵を書き込む。ユーザーＢならば、たとえば
C:\Users\userB\Dropbox\projectP_share\Key\B_public_key.txt
というファイルを生成する。以下、ユーザーＢを想定して説明する。
【００６１】
管理者ユーザーＡは、Ｄｒｏｐｂｏｘアプリにより、自身の共有フォルダ内にユーザーＢの公開鍵が記録されたファイル（B_public_key.txt）を保持するようになる。ユーザーＡのシステムはこれを読み取って、Bの公開鍵（public_key_B）を取得する。ユーザーＡのシステムは、この公開鍵を用いて、自身の端末内に保存している共通鍵を暗号化する（encrypted_shared_key_forBとする）。
ユーザーＡのシステムは、この共通鍵をテキストファイルに書き込み、共有フォルダ内に置く。たとえば、端末Ａにおいて、
C:\Users\userA\Dropbox\projectP_share\Key\encrypted_shared_key_forB.txt
というファイルを生成する。
【００６２】
これにより、ユーザーＢの公開鍵で暗号化された共通鍵を記録したファイルが、ユーザーＢの環境下に同期されることになる。
たとえば、
C:\Users\userB\Dropbox\projectP_share\Key\encrypted_shared_key_forB.txt
というファイルが同期される。
【００６３】
ユーザーＢのシステムは、encrypted_shared_key_forB.txtを見つけると、これを読み取って、自身の秘密鍵を用いて復号化する。これによって、ユーザーＡの端末ＡからユーザーＢの端末Ｂに対して、共通鍵が安全に配布された。
【００６４】
ここで、システムが共通鍵の取得を終え次第、共有フォルダ上のencrypted_shared_key_forX.txtファイルを直ちに削除するように実装してもよい。
以上の処理は、ユーザーＡの端末ＡとユーザーＣの端末Ｃとの間で、あるいは、ユーザーＡの端末ＡとユーザーＤの端末Ｄとの間でも同様にして処理される。
なお、以上の処理はシステムが自動でおこなうことが可能である。これによって、共通鍵を共有するというステップ自体がユーザーから隠蔽され、運用をシンプルにすることが期待できる。
【００６５】
−変形例（複数プロジェクトでの運用）−
ここまでの説明は単一のプロジェクトを想定していたが、本実施形態で説明したシステムは、複数プロジェクトが存在する際にも有効に機能する。
複数プロジェクトが存在するとは、たとえば、ユーザーＡに対して、
プロジェクトＰ  ユーザーＡ，Ｂ，Ｃ，Ｄ
プロジェクトＱ  ユーザーＡ，Ｅ，Ｆ
プロジェクトＲ  ユーザーＡ，Ｂ，Ｇ，Ｈ，Ｉ（案件Ｘ）
プロジェクトＳ  ユーザーＡ，Ｂ，Ｇ，Ｈ，Ｉ（案件Ｙ）
というように、異なるメンバー、あるいは、異なる内容のプロジェクトが併存する場合である。
【００６６】
この場合、上述した例によれば、１つのプロジェクトに対して、それぞれ１組のローカル保存フォルダ・共有フォルダを割り当てることによって、プロジェクト単位での文書管理が成立することとなる。
ここで、システムは、更にローカルインストール型の文書管理システムと協働することができる。システムによれば、メンバー間で安全に機密文書ファイルを共有できるだけでなく、メタ情報を記録したデータベースファイルなども同時に共有することができる。これによって、ローカル型の文書管理システムを利用して、安全かつ効果的に文書共有・文書整理を実現することもできる。
【００６７】
更に文書管理システムがプロジェクト管理機能を有していれば、ユーザーは適宜のユーザーインターフェイス（ＵＩ）を通して、随時プロジェクトを切り替え、かつ、当該プロジェクト内の文書を検索したり、メタ情報を付加したりすることができる。ユーザーから見た場合、１個のＵＩを随時操作するだけで、複数プロジェクトを一括して扱うことができ、更に文書検索・メタ情報編集機能を得ることとなり、その利便性は高い。
【００６８】
上記実施形態では、機密性の高い文書を扱う必要性の高い弁護士の業務を想定して説明したが、本システムが弁護士の業務に用いられるものに限定される趣旨でないことは、言うまでも無い。
【符号の説明】
【００６９】
１０  ファイル同期サーバー
２０  ローカル端末（端末Ａ，端末Ｂ，端末Ｃ，端末Ｄ，・・・）
３０  暗号化ファイル
Ｋ  共通鍵（キーファイル）
【図１】
2020170412.tif 000002
【図２】
2020170412.tif 000003