JP2009059008A - ファイル管理システム - Google Patents

Abstract

【課題】アプリケーション・プログラムを改変せずに、暗号化ファイルの操作を、ファイル単位で行う。
【解決手段】アプリケーションプログラム３２は、ファイルを操作するためのＡＰＩ呼出コード３２１を備える。監視層３４は、アプリケーションプログラム３２からのＡＰＩ呼び出しをフックし、暗号化ファイル１４を復号化するための復号命令を復号制御モジュール３６に送る。復号制御モジュール３６は、監視層３４から送られた復号命令に基づいて、ＯＳカーネル３７に復号処理を依頼する。ＯＳカーネル３７は、復号制御モジュール３６からの依頼に基づいて、ファイル１４を復号処理して、復号済みファイルを生成し、さらに、この復号済みファイルを復号制御モジュール３６に返す。さらに、復号制御モジュール３６は、ＯＳカーネル３７から返された復号済みファイルをアプリケーションプログラム３２に返す。
【選択図】図２

Description

本発明は、暗号化されたファイルをコンピュータにより安全に操作するための技術に関するものである。

情報共有のために、文書や画像、動画などのデータを関係者のみが安全に閲覧したいという要望がある。

このような情報を保護するためには、データに対して暗号化処理を施し、権利のある人のみが復号用の鍵を取得して閲覧するという対応方法がある。そのためには、従来、暗号化されたデータを復号する処理をアプリケーション・プログラム（以下「アプリケーション」ということがある）に組み込むことで対応していた。この場合は、アプリケーションを起動すると、そこに組み込まれた復号化処理によってデータを復号して、アプリケーションによる処理（例えばファイルを開いたり印刷する等）が可能になる。

一方、アプリケーションによっては、改変が困難な場合が存在する。この場合は、ユーザ自身が、別のアプリケーションを用いて、暗号化ファイルの復号処理を行う必要がある。この方法によっても、復号されたファイルを当初のアプリケーションで利用することが可能である。しかしながら、この場合は、復号済みのデータが流出したり、改ざんされる危険があるという問題があった。また、このような処理は、ユーザの手間が非常にかかるという問題もあった。

さらに、データを保存するためのＨＤＤ（ハードディスクドライブ）全体を暗号化するというソリューションも存在する。この場合では、ユーザがデータを利用する時には、ＨＤＤに記録された全てのデータファイルが復号化された状態となる。つまり、この状態では、全てのファイルに対する操作が可能となる。すると、この技術においては、ファイル交換ソフトの利用などに起因して、復号済みのデータファイルが外部に流出するという問題を生じる可能性がある。

本発明は、前記した状況に鑑みてなされたものである。本発明は、アプリケーション・プログラムを改変せずに、暗号化ファイルの操作を、ファイル単位で行うことができる技術を提供するものである。

前記した課題を解決するために、本発明は、以下のいずれかの項目に記載される構成を備えている。

（項目１）
以下の（ａ）〜（ｄ）を備えるファイル管理システム：
（ａ）アプリケーションプログラム、
（ｂ）監視層、
（ｃ）復号制御モジュール、
（ｄ）ＯＳカーネル、
ここで、
前記アプリケーションプログラムは、ファイルを操作するためのＡＰＩ呼出コードを備えており、
前記監視層は、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックし、前記ファイルを復号化するための復号命令を前記復号制御モジュールに送るようになっており、
前記復号制御モジュールは、前記監視層から送られた前記復号命令に基づいて、ＯＳカーネルに復号処理を依頼するようになっており、
前記ＯＳカーネルは、前記復号制御モジュールからの依頼に基づいて、前記ファイルを復号処理して、復号済みファイルを生成し、さらに、この復号済みファイルを復号制御モジュールに返すようになっており、
さらに、前記復号制御モジュールは、前記ＯＳカーネルから返された前記復号済みファイルを前記アプリケーションプログラムに返す構成となっている。

本発明によれば、ファイル操作のためのＡＰＩ呼出コードをフックして、当該ファイルを復号し、アプリケーションプログラムに返すことができる。本発明では、ＡＰＩ呼出コードを操作するだけなので、アプリケーションプログラム本体を改変する必要がない。また、操作が必要なファイル毎に復号しているので、ＨＤＤ全体を復号する場合に比べて、情報漏洩の危険性が低い。なお、本発明において、復号されるファイルとは、ファイル中の一部のデータである場合を含む。つまり、ファイル単位の復号とは、必ずしも、ファイル全部の復号を意味せず、ファイル中における必要なデータのみの復号を含む。

（項目２）
さらに、
（ｅ）監視制御モジュール、
を備えた、項目１に記載のファイル管理システムであって、
前記監視制御モジュールは、前記アプリケーションプログラムが備えている前記ＡＰＩ呼出コードを書き換えることにより、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックできる構成となっている。

このようにＡＰＩ呼出コードを書き換えることにより、ＡＰＩ呼出コードのフックを簡便かつ確実に実装できる。

（項目３）
さらに、
（ｆ）二次記憶装置
を備えた、項目１又は２に記載のファイル管理システムであって、
前記二次記憶装置は、暗号化された前記ファイルを格納している。

（項目４）
さらに、
（ｇ）鍵送信サーバ
を備えた、項目１〜３のいずれか１項に記載のファイル管理システムであって、
前記復号制御モジュールは、前記鍵送信サーバから受け取った鍵を用いて、前記復号処理を行う構成となっている、項目１〜３のいずれか１項に記載のファイル管理システム。

（項目５）
前記ＡＰＩ呼出コードは、ファイルを開くためのものである、項目１〜４のいずれか１項に記載のファイル管理システム。

（項目６）
前記ＡＰＩ呼出コードは、さらに、ファイルの印刷を行うためのものを含む、項目５に記載のファイル管理システム。

（項目７）
さらに、
（ｈ）暗号処理モジュール
を備えた、項目１〜６に記載のファイル管理システムであって、
前記監視層は、前記フックしたＡＰＩ呼び出しに基づいて、暗号化命令を、前記暗号処理モジュールに送るようになっており、
前記暗号処理モジュールは、前記暗号化命令を受け取った後、前記アプリケーションプログラムの動作に必要なデータを、暗号化した上でテンポラリファイルに書き出す処理を行う構成となっている。

（項目８）
以下の（ａ）〜（ｄ）を備えるファイル管理システムを用いた、ファイル管理方法：
（ａ）アプリケーションプログラム、
（ｂ）監視層、
（ｃ）復号制御モジュール、
（ｄ）ＯＳカーネル、
ここで、
前記アプリケーションプログラムは、ファイルを操作するためのＡＰＩ呼出コードを備えている；
この方法は、以下のステップを備える：
前記監視層が、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックし、前記ファイルを復号化するための復号命令を前記復号制御モジュールに送るステップ、
前記復号制御モジュールが、前記監視層から送られた復号命令に基づいて、ＯＳカーネルに復号処理を依頼するステップ、
前記ＯＳカーネルが、前記復号制御モジュールからの依頼に基づいて、前記ファイルを復号処理して、復号済みファイルを生成し、さらに、この復号済みファイルを復号制御モジュールに返すステップ、
さらに、前記復号制御モジュールが、前記ＯＳカーネルから返された前記復号済みファイルを前記アプリケーションプログラムに返すステップ。

（項目９）
項目８に記載の方法をコンピュータに実行させるためのコンピュータプログラム。

本発明によれば、本発明は、アプリケーション・プログラムを改変せずに、暗号化ファイルの操作を、ファイル単位で行うことが可能になる。

以下、本発明の一実施形態を、添付図面を参照して説明する。

（システムの構成例）
まず、本発明の一実施形態に係るファイル管理システムを、図１に基づいて説明する。このシステムは、コンテンツ提供者の内部環境１と、公開サーバ環境２と、ユーザコンピュータ３と、インターネット４とを、機能要素として備えている。

（内部環境）
内部環境１は、コンテンツ暗号化システム１１と、コンテンツ用ストレージ１２とを備えている。

コンテンツ暗号化システム１１は、コンテンツファイル１３を暗号化するものである。また、コンテンツ暗号化システム１１は、コンテンツＩＤと復号鍵とを生成して、公開サーバ環境２に送るようになっている。ここで、コンテンツファイル１３としては、文書、画像、動画、実行ファイルなど、各種のものが利用できる。つまり、本実施形態のシステムで対象となるファイルの形式は制約されない。

また、コンテンツ暗号化システム１１は、暗号化されたコンテンツファイル１４を、ストレージ１２に格納するようになっている。

コンテンツ用ストレージ１２は、暗号化されたコンテンツファイル１４を、公開サーバ環境２に受け渡すことができるようになっている。

（公開サーバ環境）
公開サーバ環境２は、コンテンツ配布サーバ２１と、鍵送信サーバ２２と、鍵記録用のストレージ２３とを備えている。

コンテンツ配布サーバ２１は、コンテンツ用ストレージ１２から、暗号化されたファイル１４を受け取り、インターネット４を経由して、ユーザコンピュータ３に送るようになっている。

鍵送信サーバ２２は、コンテンツ暗号化システム１１から、コンテンツＩＤと復号鍵とを受け取り、ユーザコンピュータ３に送ることができるようになっている。

鍵記録用のストレージ２３は、鍵送信サーバ２２が受け取ったコンテンツＩＤと復号鍵とを対応させて、保存しておくものである。

（ユーザコンピュータ）
ユーザコンピュータ３は、コンテンツダウンローダ３１と、アプリケーションプログラム（アプリケーション）３２と、監視制御モジュール３３と、監視層３４と、標準ＡＰＩ３５と、復号制御／暗号処理モジュール３６と、ＯＳカーネル３７と、デバイスドライバ３８と、二次記憶装置３９とを備えている。

コンテンツダウンローダ３１は、コンテンツ配布サーバ２１から、インターネット４を介して、暗号化されたコンテンツファイル１４を受け取るものである。このような機能は、ブラウザなど適宜のコンピュータソフトウエアにより提供することができる。ただし、ユーザコンピュータ３がコンテンツファイル１４を受け取る手段としては、インターネット経由に限らず、例えば、ＣＤやＤＶＤなどの媒体経由であってもよい。この場合は、コンテンツダウンローダ３１に代えて、記録媒体の読み出し装置を用いることができる。

アプリケーションプログラム３２は、ファイル操作や印刷などの機能を実行するためのコンピュータソフトウエアである。この実施形態では、アプリケーションプログラム３２として、各種のビューアアプリケーションを想定しているが、これのみに制約されるものではない。アプリケーションプログラム３２の例としては、インターネット・エクスプローラー、Flashプレイヤー、ＰＤＦビューア、MS-Officeなどである。なお、これらは商標あるいは登録商標である。アプリケーションプログラム３２は、ファイルを操作するためのＡＰＩ呼出コード３２１（図２参照）を備えている。

監視制御モジュール３３は、アプリケーションプログラム３２におけるＡＰＩ呼出コードを書き換えることにより、ＡＰＩフックを実現する機能を有するコンピュータプログラムである。

さらに、監視制御モジュール３３は、ユーザ側から、
・復号許可アプリケーション
・暗号化書き出し可能フォルダ
・アプリケーションによる印刷の制限
・画面キャプチャの制限
についてのデータを受け付けるようになっている。

監視制御モジュール３３についての詳しい動作は後述する。

監視層３４は、アプリケーションプログラム３２からのＡＰＩ呼び出しをフックし、ファイルを復号するための復号命令を復号制御モジュール３６に送るようになっている。なお、本実施形態では、ファイル中のデータの復号も、ファイルの復号という概念に含まれるものとする。もちろん、ファイル全体を復号することも可能である。また、アプリケーションプログラム３２からのＡＰＩ呼び出しの結果として複数のファイルを復号することも可能である。監視層３４についても詳しい動作は後述する。

標準ＡＰＩ３５は、ＯＳ（例えばWindows（登録商標））に付随して備えられた、標準的なＡＰＩ群である。このようなＡＰＩは既によく知られているので、詳しい説明は省略する。

復号制御／暗号処理モジュール３６は、復号制御モジュールと、暗号制御モジュールとが組み合わされた機能ブロックである。実際のプログラムコードとしては、両モジュールが一体のファイルになっていてもよいし、別のファイルであってもよい。要するに両方の機能を発揮できる構成であればよい。

復号制御／暗号処理モジュール３６は、復号制御の機能として、監視層３４から送られた復号命令に基づいて、ＯＳカーネル３７に復号処理を依頼するようになっている。さらに、復号制御／暗号処理モジュール３６は、ＯＳカーネル３７から返された復号済みファイルをアプリケーションプログラム３２に返す構成となっている。

また、復号制御／暗号処理モジュール３６は、暗号処理の機能として、監視層３４から暗号化命令を受け取った後、アプリケーションプログラムの動作に必要なデータを、暗号化した上でテンポラリファイルに書き出す処理を行う構成となっている。

復号制御／暗号処理モジュール３６の詳しい動作も後述する。

ＯＳカーネル３７は、復号制御モジュール３６からの依頼に基づいて、ファイルから必要な部分のデータを逐次復号処理し、その結果を復号制御モジュール３６に返すようになっている。

（本実施形態に係るファイル管理方法）
次に、前記したシステムを用いたファイル管理方法の一例を、図２〜図６に基づいて説明する。なお、以下に説明する方法は、コンピュータを動作させるためのコンピュータプログラムにより実行することができる。

（図２のステップ０）
まず、ユーザの操作により、
・対象復号許可アプリケーション（具体的にはそのバイナリハッシュ値）、
・暗号化書き出し可能フォルダ、
・印刷およびキャプチャに対する制限の有効、無効
という情報を、一覧のリスト３３１として、制御監視モジュール３３に登録する。この登録は、アプリケーションの動作前に行われる。

ここで、「対象復号許可アプリケーション」とは、復号処理が許可されているアプリケーションである。この情報は、アプリケーションのバイナリハッシュ値を用いて記録されている。アプリケーションの情報としては、例えば、アプリケーションの名称やバイナリパスも可能であるが、これらは一般に環境依存なので、本実施形態では使用しない。つまり、アプリケーションをそのバイナリハッシュ値で特定することにより、環境依存性を低減させることができる。。ここでバイナリハッシュ値とは、アプリケーションのファイル（実行ファイル）から、適宜なハッシュ関数を用いて生成されたハッシュ値である。

「暗号化書き出し可能フォルダ」とは、後述する暗号化書き出し処理において使用されるフォルダの情報である。この実施形態では、二次記憶装置３９におけるフォルダであるが、他の適宜な記憶装置におけるフォルダであってもよい。

「印刷およびキャプチャに対する制限の有効、無効」とは、当該アプリケーションによる印刷や、システムによる画面キャプチャを許すかどうかの情報である。以下の例では、キャプチャに対する制限は有効として説明する。制限が無効であれば、キャプチャに対する制限は行われない。

（図２のステップ１）
監視制御モジュール３３は、開くべきファイルに対応した復号許可アプリケーション３２を起動する。具体的には、例えば、開くべきファイル（暗号化されたファイル）と復号許可アプリケーションとを関連付けておき、ファイルがダブルクリックされると、復号許可アプリケーション３２を起動するようになっている。このような関連付けは、ＯＳでのサービスを利用することで容易に実現できる。

さらに、監視制御モジュール３３は、復号許可アプリケーション３２の起動時に、この復号許可アプリケーション３２が改ざんされていないかを、ハッシュ値を元にチェックする。また、同時に、ハッシュ値を用いることで、一覧リスト３３１に登録されている復号許可アプリケーション３２の特定も可能である。チェックの結果、問題がない場合のみ、復号許可アプリケーション３２を起動する。また、一覧リスト３３１に登録されていないアプリケーションや、ハッシュ値があわないアプリケーションは起動しない。

また、アプリケーション３２を起動した後は、監視制御モジュール３３はデスクトップ全体のイベントを監視し、画面キャプチャイベントが発生した場合はエラーを返す。

さらに、監視制御モジュール３３は、アプリケーション３２が起動した後、メモリ上のアプリーション・コードをチェックする。具体的には、監視制御モジュール３３は、起動したアプリケーション３２が、リスト３３１に記録されている復号処理アプリケーションである場合に、そのアプリケーションにおけるファイル操作ＡＰＩ呼出コードおよび印刷操作ＡＰＩ呼出コードを、監視層３４のコードを呼び出すように書き換える。ここで、起動したアプリケーションが、復号処理アプリケーションではない場合、このようなＡＰＩの書き換えは行われない。このため、本実施形態によれば、復号処理アプリケーション以外のアプリケーションは、監視層３４を呼び出すことができない。その結果、そのようなアプリケーションによる、暗号化ファイルの復号を防ぐことができ、暗号化ファイルへの不正なアクセスを防止できるという利点がある。

（図２のステップ２）
ついで、アプリケーション３２がＡＰＩ呼出を行う。ここで、ＡＰＩ呼出コードが、ファイル操作又は印刷操作の場合は、前記したステップ１においてコードが書き換えられているので、実際には、監視層３４が呼び出される。この例では、ファイル操作のＡＰＩとは、ファイルを開くためのＡＰＩである。

監視層３４は、書き換えられたコードを読み取ることにより、アプリケーション３２からの要求が印刷操作であるか、あるいはファイル操作であるかをチェックする。

印刷操作の場合は、印刷が許可されているアプリケーション３２からの呼び出しであれば、そのまま標準の印刷用ＡＰＩを呼び出す。これにより、ファイルの印刷が可能である。ここで、印刷の前提としては、後述するファイル操作により、ファイルが既に開かれているものとする。一方、印刷が不許可とされているアプリケーション３２からの呼び出しの場合は、エラーをアプリケーション３２に返すことで印刷を禁止することができる。

（図２のステップ３）
ファイル操作のＡＰＩである場合は、監視層３４は、書き換えられる前のＡＰＩ呼出のパラメータをチェックし、実際に復号処理または暗号化書き出しが必要かどうかを判断する（暗号化書き出しについては後述する）。例えばファイルをオープンするＡＰＩの場合、ＡＰＩのパラメータにファイルのアクセス方式が指定されている。アクセス方式の指定は、以下の種類がある。
・読み込みのみ
・書き込みのみ
・読み書き
・読み書きなし（ファイル属性取得のために利用される）

パラメータが「読み書きなし」の場合は、暗号関連の処理（復号を含む）は一切行わず、監視層３４は、標準ＡＰＩの呼び出しを行う。「読み込みのみ」を指定している場合は、復号のための処理を行う。

パラメータが「書き込みのみ」、後述する暗号化書き込みのための処理を行う。パラメータが「読み書き」を指定している場合は、復号及び暗号化書き込みのための処理を行う。

パラメータに基づいて復号処理または暗号化書き出しが必要である場合、監視層３４は、復号制御／暗号処理モジュール３６を呼び出す。つまり、監視層３４は、暗号化ファイルから処理に必要なデータを復号するための復号命令を、復号制御／暗号処理モジュール３６に送る。

（図２のステップ４〜９）
ついで、復号制御／暗号処理モジュール３６は、監視層３４からの復号命令に基づいて、ＯＳカーネル３７を呼び出す。ＯＳカーネル３７は、暗号化コンテンツ１４（復号対象となるファイル）を、デバイスドライバ３８を介して、二次記憶装置３９から取得する。また、復号制御／暗号処理モジュール３６は、暗号化コンテンツ１４に埋め込まれたコンテンツＩＤを取得する。

ここで、復号制御／暗号処理モジュール３６は、「監視制御モジュール３３から起動されたアプリケーションから呼び出される監視層３４」とのみ通信を行う。監視層３４と監視制御モジュール３３は、アプリケーション起動時に個別の通信路（パイプ）を用いて接続されており、この通信路を用いてのみ、相互間の通信を行う。監視層３４は、ＤＬＬとして実装できるので、この監視層３４を不正に組み込むアプリケーションも予想できる。しかし、監視制御モジュール３３から起動されていない（つまり復号許可アプリケーションでない）他のアプリケーションに仮に監視層（ＤＬＬ)を組み込んでも、その監視層は、上記理由により、復号制御／暗号処理モジュール３６との通信ができない。このため、本実施形態によれば、監視層３４を不正利用されることはない。

ついで、復号制御／暗号処理モジュール３６は、取得したコンテンツＩＤに対応した復号鍵を、鍵送信サーバ２２から送られた復号鍵表２３１とマッチングすることにより取得する。この実施形態では、復号処理／暗号処理モジュール３６は、鍵送信サーバ２２から、セキュアな手順を用いて、復号鍵を取得することができる。また、復号鍵を、インターネット以外の他の手段で（例えば記録媒体を介して）取得することも可能である。

（図２のステップ１１）
復号制御／暗号処理モジュール３６は、復号対象データと復号鍵とを、ＯＳカーネル３７の復号機能を呼び出すことによって復号する。つまり、ＯＳカーネル３７は、復号制御モジュール３６からの依頼に基づいて、ファイル１４から処理に必要なデータを逐次復号処理して（いわゆる「on-the-fly」）、復号済みデータを生成し、さらに、この復号済みデータを復号制御モジュール３６に返すようになっている。また、このモジュール３６は、復号した結果を監視層３４に返す。このように、本実施形態では、復号を、ファイル中のデータブロックの単位で行っている。これにより、本実施形態によれば、ファイル中において必要な部分のみを復号することができる。

（図２のステップ１２）
監視層３４は、復号した結果（つまり復号化したファイル）を、アプリケーション３２に対して、ＡＰＩ呼び出しの結果として返す。これによりアプリケーション３２は、安全にファイルの内容を取得することができる。したがって、ユーザは、アプリケーション３２により、暗号化されたファイルを開いて、ディスプレイ装置により閲覧することができる。

本実施形態の方法によれば、ファイル単位で、暗号化されたファイルを開いたり、印刷する等の処理を行うことができる。ＨＤＤ全体を復号してファイルを処理する方法では、ファイル交換ソフトウエアなどによってファイルが流出するおそれがあった。これに対して、本実施形態の方法では、ファイル単位で復号するので、そのような心配がなく、ファイルの安全性を高めることができる。

さらに、本実施形態の方法では、プログラムに対する改変を行うことなく、ＡＰＩ呼出コードの書き換えだけで、前記したような復号処理が可能になる。このため多様なプログラムに対応することができる。また、取り扱うファイルの種類に制約がないという利点がある。

（一時的なファイルの書き出し処理）
つぎに、復号化されたファイル中のデータを一時的に書き出すための手順を、図３をさらに参照して説明する。ただし、前記した処理と同様の処理については、説明を省略あるいは簡略化する。

（図３のステップ０）
まず、ユーザは、復号許可アプリケーション及び暗号化書き出し可能フォルダを一覧リストに事前に登録する。これは図２におけるステップ０と同様である。

（図３のステップ１）
さらに、監視制御モジュール３３は、アプリケーション実行時に、メモリ上のアプリーション・コードをチェックする。さらに監視制御モジュール３３は、復号処理又は暗号化書き出しが必要となる一覧リストに登録されているアプリケーションにおける、ファイル操作用のＡＰＩ呼出コードを、監視層３４のコードを呼び出すように書き換える。この操作は、図２のステップ１と基本的に同様である。ただし、図３の例では、コードが書き換えられた結果、呼び出されるようになった監視層３４にて、書き出しの可否を制御することができる。

（図３のステップ１'）
さらに図３の処理においては、復号制御／暗号処理モジュール３６に対して、監視制御モジュール３３が
・暗号化書き出しを許可するフォルダの情報と、
・この暗号化書き出しでの暗号化において利用する鍵情報と
を渡す。

（図３のステップ２）
アプリケーション３２がＡＰＩ呼び出しを行う。ただし、ステップ１でコードが書き換えられているので、実際には監視層３４が呼び出される。

（図３のステップ３）
監視層３４は、書き換えられる前のＡＰＩ呼出コードのパラメータ（図２のステップ３において説明したもの）をチェックし、暗号化書き出しが必要かどうかを判断する。これらの処理が必要である場合、復号制御／暗号処理モジュール３６を呼び出す。つまり、監視層３４は、暗号化命令を、復号制御／暗号処理モジュール３６に送る。

（図３のステップ４〜１０）
暗号化命令を受け取った復号制御／暗号処理モジュール３６では、アプリケーションから求められた書き出し処理における保存先フォルダが、予め一覧表３３１として渡されている暗号化書き出し許可フォルダと一致するかどうかを判断する。一致した場合は、復号制御／暗号処理モジュール３６は、ＯＳカーネル３７を呼び出して、書き出しの対象となるデータを取得する。さらに、復号制御／暗号処理モジュール３６は、許可された保存先に、取得したデータを暗号化して保存する。この暗号化のための鍵は、プロセスおよびファイルごとに異なるものを生成して用いる(すなわち、同じファイルでも、プロセスが異なれば鍵が異なる。また、プロセスが同じでも、ファイルが異なれば鍵が異なる。)。

もし、アプリケーション３２が指定する保存先フォルダが、暗号化書き出し許可フォルダと一致しない場合は、復号制御／暗号処理モジュール３６は、エラーをアプリケーション３２に返す。本実施形態では、この処理により、アプリケーション３２による任意フォルダへのデータの保存を禁止することができる。これにより、ファイル中のデータの安全性を高めることができる。

本実施形態の方法によれば、アプリケーションプログラム３２の動作に必要な動作であるテンポラリファイルの書き出しを実現することができる。また、データは、暗号化された状態で書き出されるので、ファイル内容の安全性を高めることができる。

（図３のステップ１１）
ついで、監視層３４は、保存した結果（具体的には、例えば「保存完了」のメッセージ）を、アプリケーション３２に、ＡＰＩ呼出の結果として返す。

（復号処理を必要としないＡＰＩ呼び出しの処理）
次に、復号処理を必要としないＡＰＩ呼び出しの処理手順について、図４に基づいて概略的に説明する。この処理は、基本的に、通常のＡＰＩ呼び出しと同じである。また、既に述べた処理と同様の処理については説明を省略する。

（図４のステップ１）
復号許可アプリケーション３２におけるＡＰＩ呼出コードのうち、復号処理や印刷に関係しないコードについては、監視制御モジュール３３は、コードの書き換えを行わない。このようなコードをアプリケーション３２が呼び出した場合、標準のＡＰＩコード３５が通常通りに呼び出される。この場合、監視層３４は呼び出されない。つまり、ＡＰＩ呼出コードが監視層３４を透過することになる。

（図４のステップ２〜７）
呼び出された標準のＡＰＩ３５は、通常どおり、ＯＳカーネル３７を呼び出し、処理結果を取得する。

（図４のステップ８）
処理結果を取得した後、標準のＡＰＩ３５は、アプリケーション３２にＡＰＩ呼び出しの結果を返す。

本実施形態では、このようにして、ファイルの復号処理や印刷に関係しないＡＰＩ呼出コードについては、標準のＡＰＩを通常通りに呼び出すことが可能である。呼び出された標準のＡＰＩは、通常通りに動作して、処理結果をアプリケーション３２に返すことができる。

（復号処理を必要としないＡＰＩパラメータの処理）
次に、復号処理を必要としないＡＰＩパラメータの処理手順について、図５に基づいて概略的に説明する。この処理も、基本的に、通常のＡＰＩ呼び出しと同じである。また、既に述べた処理と同様の処理については説明を省略する。

（図５のステップ１）
監視制御モジュール３３は、復号許可アプリケーション３２の実行時に、メモリ上のアプリケーション・コードをチェックする。さらに、監視制御モジュール３３は、ファイル操作ＡＰＩ呼出コードを、監視層３４のコードを呼び出すように書き換える。この点は前記の例と同様である。

（図５のステップ２及び３）
ついで、アプリケーション３２がＡＰＩ呼出を行う。ただし、前記のステップ１においてコードが書き換えられているので、実際には監視層３４が呼び出される。

監視層３４は、ＡＰＩ呼出のパラメータをチェックし、実際に復号処理が必要かどうかを判断する。パラメータの例は、図２のステップ３で説明した通りである。復号処理が実際には不要であった場合、標準のＡＰＩを呼び出す。

（図５のステップ４〜９）
標準のＡＰＩは、通常どおりにＯＳカーネル３７を呼び出し、処理結果を取得する。その後、標準ＡＰＩは、監視層３４に、ＡＰＩ呼出の結果を返す。

（図５のステップ１０及び１１）
監視層３４は、標準のＡＰＩ３５から受け取った処理結果を、アプリケーション３２に対して、ＡＰＩ呼び出しの結果として返す。

（復号対象アプリケーションでないアプリケーションからのＡＰＩ呼び出しの処理）
次に、一覧表３３１において復号対象アプリケーションとして記載されていないアプリケーションからのＡＰＩ呼び出しの処理について、図６に基づいて概略的に説明する。この処理は、基本的に、通常のＡＰＩ呼び出しと同じである。また、既に述べた処理と同様の処理については説明を省略する。

（図６のステップ１）
復号対象アプリケーションとして一覧表３３１に記載されていないアプリケーションからのファイル操作（印刷を含む）のＡＰＩについては、監視制御モジュール３４はコードの書き換えを行わない。したがって、アプリケーション３２におけるファイル操作のためのＡＰＩ呼出コードは、そのまま、標準のＡＰＩ３５を呼び出す。

（図６のステップ２〜７）
呼び出された標準のＡＰＩ３５は、通常どおりにＯＳカーネル３７を呼び出し、処理結果を取得する。

（図６のステップ８）
標準のＡＰＩ３５は、アプリケーション３２に、ＡＰＩ呼び出しの結果を返す。

本実施形態のファイル管理方法によれば、監視制御モジュール３３に書き込む内容（例えば復号許可アプリケーション、暗号化書き出し可能フォルダ、書き換えの対象となるＡＰＩ呼出コード、書き換えの内容など）を変更することで、各種のアプリケーションに対応することができ、非常に汎用性が高いという利点がある。

なお、本発明の範囲は、前記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることはもちろんである。

例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良い。本発明における複数の機能要素が一つの機能要素により実現されても良い。

また、機能要素は、物理的に離間した位置に配置されていてもよい。この場合、機能要素どうしがネットワークにより接続されていても良い。

本発明の一実施形態に係るファイル管理装置の全体的な機能ブロック図である。 本発明の一実施形態に係るファイル管理方法の手順（復号処理）を説明するための説明図である。 本発明の一実施形態に係るファイル管理方法の手順（暗号化書き出し処理）を説明するための説明図である。 本発明の一実施形態に係るファイル管理方法の手順（対象外ＡＰＩ呼び出しの処理）を説明するための説明図である。 本発明の一実施形態に係るファイル管理方法の手順（対象外ＡＰＩパラメータの処理）を説明するための説明図である。 本発明の一実施形態に係るファイル管理方法の手順（対象外アプリケーションの処理）を説明するための説明図である。

符号の説明

１ 内部環境（コンテンツ提供者社内環境）
１１ コンテンツ暗号化システム
１２ コンテンツ用ストレージ
１３ コンテンツのファイル
１４ 暗号化コンテンツ
２ 公開サーバ環境
２１ コンテンツ配布サーバ
２２ 鍵送信サーバ
２３ 鍵記録用のストレージ
２３１ コンテンツＩＤ及び復号鍵
３ ユーザコンピュータ
３１ コンテンツダウンローダ
３２ アプリケーションプログラム
３２１ ＡＰＩ呼出コード
３３ 監視制御モジュール
３３１ 一覧表
３４ 監視層
３５ 標準のＡＰＩ
３６ 復号処理／暗号処理モジュール
３７ ＯＳカーネル
３８ デバイスドライバ
３９ ローカルディスク（二次記憶装置）
４ インターネット

Claims (9)

1. 以下の（ａ）〜（ｄ）を備えるファイル管理システム：
   （ａ）アプリケーションプログラム、
   （ｂ）監視層、
   （ｃ）復号制御モジュール、
   （ｄ）ＯＳカーネル、
   ここで、
   前記アプリケーションプログラムは、ファイルを操作するためのＡＰＩ呼出コードを備えており、
   前記監視層は、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックし、前記ファイルを復号化するための復号命令を前記復号制御モジュールに送るようになっており、
   前記復号制御モジュールは、前記監視層から送られた前記復号命令に基づいて、ＯＳカーネルに復号処理を依頼するようになっており、
   前記ＯＳカーネルは、前記復号制御モジュールからの依頼に基づいて、前記ファイルを復号処理して、復号済みファイルを生成し、さらに、この復号済みファイルを復号制御モジュールに返すようになっており、
   さらに、前記復号制御モジュールは、前記ＯＳカーネルから返された前記復号済みファイルを前記アプリケーションプログラムに返す構成となっている。
2. さらに、
   （ｅ）監視制御モジュール、
   を備えた、請求項１に記載のファイル管理システムであって、
   前記監視制御モジュールは、前記アプリケーションプログラムが備えている前記ＡＰＩ呼出コードを書き換えることにより、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックできる構成となっている。
3. さらに、
   （ｆ）二次記憶装置
   を備えた、請求項１又は２に記載のファイル管理システムであって、
   前記二次記憶装置は、暗号化された前記ファイルを格納している。
4. さらに、
   （ｇ）鍵送信サーバ
   を備えた、請求項１〜３のいずれか１項に記載のファイル管理システムであって、
   前記復号制御モジュールは、前記鍵送信サーバから受け取った鍵を用いて、前記復号処理を行う構成となっている、請求項１〜３のいずれか１項に記載のファイル管理システム。
5. 前記ＡＰＩ呼出コードは、ファイルを開くためのものである、請求項１〜４のいずれか１項に記載のファイル管理システム。
6. 前記ＡＰＩ呼出コードは、さらに、ファイルの印刷を行うためのものを含む、請求項５に記載のファイル管理システム。
7. さらに、
   （ｈ）暗号処理モジュール
   を備えた、請求項１〜６に記載のファイル管理システムであって、
   前記監視層は、前記フックしたＡＰＩ呼び出しに基づいて、暗号化命令を、前記暗号処理モジュールに送るようになっており、
   前記暗号処理モジュールは、前記暗号化命令を受け取った後、前記アプリケーションプログラムの動作に必要なデータを、暗号化した上でテンポラリファイルに書き出す処理を行う構成となっている。
8. 以下の（ａ）〜（ｄ）を備えるファイル管理システムを用いた、ファイル管理方法：
   （ａ）アプリケーションプログラム、
   （ｂ）監視層、
   （ｃ）復号制御モジュール、
   （ｄ）ＯＳカーネル、
   ここで、
   前記アプリケーションプログラムは、ファイルを操作するためのＡＰＩ呼出コードを備えている；
   この方法は、以下のステップを備える：
   前記監視層が、前記アプリケーションプログラムからのＡＰＩ呼び出しをフックし、前記ファイルを復号化するための復号命令を前記復号制御モジュールに送るステップ、
   前記復号制御モジュールが、前記監視層から送られた復号命令に基づいて、ＯＳカーネルに復号処理を依頼するステップ、
   前記ＯＳカーネルが、前記復号制御モジュールからの依頼に基づいて、前記ファイルを復号処理して、復号済みファイルを生成し、さらに、この復号済みファイルを復号制御モジュールに返すステップ、
   さらに、前記復号制御モジュールが、前記ＯＳカーネルから返された前記復号済みファイルを前記アプリケーションプログラムに返すステップ。
9. 請求項８に記載の方法をコンピュータに実行させるためのコンピュータプログラム。

Images