JP2010134935A - ファイル操作を実行するための方法及び装置 - Google Patents

Abstract

【課題】
ファイルなどの情報エンティティの操作を制限できるシステムを提供する。
【解決手段】
メタ情報が格納されたヘッダと実ファイルコンテンツとを含むファイルに対する操作をＯＳ上で走るアプリケーションが実行するための方法が提供される。本方法は、アプリケーションプログラムがＯＳのシステムコールを呼び出すステップと、インターセプトモジュールがシステムコールをインターセプトするステップと、インターセプトモジュールがヘッダに格納されたメタ情報を読み出すステップと、そのメタ情報に基づいて、前記システムコールの実行が許可されるか拒否されるかを判断するステップと、前記システムコールの実行が許可されると判断された場合には、ファイルポインタをヘッダに相当する量だけ移動させてシステムコールが実ファイルコンテンツに対して実行されるようにするステップとを含む。
【選択図】 図１

Description

本発明は、ファイル操作を実行するための方法及び装置に関する。具体的には、ファイルのヘッダによって定められたポリシに基づいてファイル操作を実行するための方法及び装置に関する。

機密かつ重要なデータの量は常に増加しつつある。個人の関心、あるいは法律の要請によって、このようなデータは不正に利用されないように保護されなければならない。この意味における保護には、いくつかの意味があり、それぞれ異なるものを意味している。

アクセス制御（Access Control）は、誰がどのようなデータにアクセスできるかを記述するものであり、データへのアクセスが許可されている人の集合を定めるものである。アクセス制御では、専用の技術がなければ、このようなデータを将来的な利用に対して保護を与えることができないが、将来的な利用の規制が重要ではないということを意味するものではない。したがって、１つの可能性として、利用の制御メカニズムによってデータに対する規制を広げることができる。例えば、データ保護は、人のプライバシーに関係し、機密データの利用を規制するものである。

実際には、次のような例が考えられる。競合する企業２社は、ある特定のエリアで協力することがお互いの企業にとって有益であることを認識しているものの、なおも競合状態にあり、しかも互いに独立した関係にある。協力するためには両企業は貴重な情報を交換する必要がある一方で、相手がそのデータを用いて何でもできるような無制限なやり方での情報を交換することは望んでいない。このような貴重な情報の所有者は、他方の当事者がこの情報を用いてできることを正確に指定できる場合には、その情報を渡したいとする意思を持っているに過ぎない。例えば、受信者が受信メールを第三者へ転送することは不可能でなければならないということや、株主総会の情報の印刷又はｍｐ３ファイルの再生が４回以上は許されないということがある。昔とは異なり、このような指定は、書面への署名によってではなく、技術的手段によって行う必要がある。

したがって、本発明の目的は、ファイルなどの情報エンティティに対する上記のような制約を付与し又は操作を行えるシステムを提供することにある。

本発明は、上記課題を解決するための手段として、メタ情報（meta-information）が格納されたヘッダと実ファイルコンテンツ（actual file content）とを含むファイルに対する操作を、オペレーティングシステム（ＯＳ）上で走るアプリケーションプログラムにより行うコンピュータにより実行する方法を提供する。本方法は、前記ファイルにアクセスするために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコール（system call）を呼び出すステップと、インターセプトモジュール（intercepting module）が前記システムコールをインターセプトするステップと、前記インターセプトモジュールが前記ヘッダに格納されたメタ情報を読み出すステップと、前記メタ情報に基づいて、前記ファイルに対する前記システムコールの実行が許可されるか拒否されるかを判断するステップと、前記判断の結果、前記システムコールが許可される場合には、アクセスされるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記システムコールが前記実ファイルコンテンツに対して実行されるようにするステップとを含む。

このようにして、ファイルへのアクセスは、そのファイル内にメタ情報として格納することができる利用制御ポリシ（usage control policy）によって制御又は制限することができる。ファイルポインタをシフトすなわち移動させることで、ファイルアクセスが、オペレーティングシステム（ＯＳ）上で動作するアプリケーションプロセス又はアプリケーションプログラムに気付かれないように（透過的に）実行される。アプリケーションは、インターセプトもヘッダも認識せず、ヘッダはアプリケーションプログラムからシールドされる。このようにして、ファイルの扱いに関するポリシは、メタ情報として格納することができ、必要に応じてシステムコールを拒否又は変更するインターセプタによってポリシを設定することができる。１つの態様におけるファイルポインタの移動は、カーネル内部で行われる。つまり、この操作は、アプリケーションプログラム又はアプリケーションプロセスによるアクセスから「シールド」されている。

１つの態様として、前記メタ情報は、前記ファイルにアクセスするときに設定（enforce）されるポリシ（policy）についての情報を含み、前記ポリシは、変更されない方法で前記システムコールが前記ファイルへアクセスすることが許される１つ以上の条件の定義と、前記システムコールが前記ファイルへアクセスすることが許されない１つ以上の条件の定義と、変更された方法でのみ前記システムコールが前記ファイルへアクセスすることが許される１つ以上の条件の定義とのうちの１つ以上を含む。

このようにして、メタ情報は、ファイルへアクセスするときに設定されるべき実際のポリシ、例えば、どの条件下でそのファイルへのアクセスが拒否されるべきか、許可されるべきか、あるいは変更された方法でアクセスの実行が許可されるべきかを定義することができる。

１つの態様として、前記システムコールの実行は変更された方法で実行され、この変更された実行は前記実ファイルコンテンツの暗号化又は復号化を含む。

これにより、アプリケーションプロセスに気付かれない形でファイルの自動的な暗号化及び／又は復号化が実行できる。アプリケーションプログラムが暗号化ファイルにアクセスすることが許されることをポリシが定めている場合、システムコールの変更は、アプリケーションが実データファイルへ暗号化されていない形でアクセスできるように、実ファイルコンテンツの自動的な復号化をもたらす。他方、ポリシが復号化を許さないアプリケーションに関しては、このようなアプリケーションは復号化された形でファイルにアクセスすることはできない。このアプリケーションは、暗号化された状態のファイルのみ認識できる。

１つの態様として、前記システムコールの実行が許可されるか拒否されるかの前記判断は、前記メタ情報に基づくだけなく、前記システムコールの発行元であるアプリケーションプログラム又はアプリケーションプロセスの種類にも基づいている。例えば、１つの態様として、前記メタ情報は、ある特定のアプリケーションプログラム（又は、ある種類のアプリケーションプログラム又はアプリケーションプロセス）に対して前記システムコールが許可されるか拒否されるかに関する情報を含む。ある特定のアプリケーションプログラムに対してシステムコールが許可されるか拒否されるかは、メタ情報に定義されたポリシの一部によって定まる。

これにより、システムコールを要求したアプリケーションプロセスのタイプに応じて、ファイル操作の実行を許可又は拒否することができる。ポリシは、例えば、システムコールによってファイルにアクセスする権限が与えられた特定のアプリケーションプロセスを指定する。そして更に、ポリシは、ファイルにアクセスすることが拒否されたアプリケーションプログラム又はプロセスを指定する。例えば、ファイルを電子メールに添付するとかファイルをプリントアウトするといったような特定のアプリケーションプロセスが拒否される。あるいは、ワードプロセッサのような特定のアプリケーションプログラムがファイルへのアクセスを許可もしくは拒否される。

１つの態様として、前記ファイルは実ファイルコンテンツとして暗号化されたデータを含み、前記メタ情報は前記暗号化データの復号化が許される１つ以上の条件を定義する利用制御ポリシを含む。また、一態様として、前記メタ情報は、前記暗号化データを復号化するための１つ以上の暗号鍵を更に含む。暗号化されたファイルが復号化され、それにより復号化後のコンテンツにアクセスすることが可能となる条件として、例えば、復号化後のコンテンツにアクセスすることが許される１つ以上のアプリケーションプログラム又はプロセスを指定することができる。また、復号化後のコンテンツにアクセスすることが拒否されるアプリケーションプログラムも定めることができる。このような条件の定義に応じて、復号化が実行されるか否かが決定でき、それにより、復号化後のコンテンツにアクセスすることを許可又は拒否することができる。もっと一般的に言えば、このような条件は、利用制御ポリシを定義することができる。この場合、利用制御ポリシは、どの条件下で復号化が実行されるかを定め、それにより、どの条件下で、暗号化されていないコンテンツへのアクセスが、システムコールを要求したアプリケーションプログラムに対して許可されるかを定める。

このようにして自動的な暗号化又は復号化が実現できる。ただし、利用制御ポリシがそれを許す場合にのみ、データはメタ情報内の１つ以上の鍵を用いて復号化できる。復号化が許可されない場合、データにアクセスしようとしているアプリケーションプログラムにとってそのデータは暗号化されたままである。なぜなら、復号化に必要な鍵は、インターセプタだけがアクセスできるヘッダ内に格納されていることにより、保護されているからである。

１つの態様として、前記メタ情報は、復号化が実行されるべきかどうかを定めるだけでなく、復号化がどのように実行されるべきかも定める。これは例えば、使用すべき暗号化アルゴリズムの識別子を含む。例えば、復号化のために用いる鍵へのポインタもしくはリファレンス又はこのような鍵の取得の仕方の何らかの指示も含む。鍵をどのようにして取得するかの情報は例えば、シード値（seed value）に基づいて実行してそれにより鍵を取得するためのアルゴリズムの識別子を含む。

１つの態様として、前記メタ情報は前記暗号化データ（実ファイルコンテンツ）を復号化するための１つ以上の暗号鍵を含むことがある、あるいは、前記メタ情報は、前記暗号化データを復号化するための前記１つ以上の暗号鍵を導くことができる情報を含む。

前記１つ以上の鍵をメタ情報として格納することで、他のコンピュータ上でも、格納されたメタ情報に基づいてファイルを復号化することができる。

更なる態様として、前記鍵はヘッダに格納されず、例えば鍵管理プログラムのような、他のエンティティによって管理される。

１つの態様として、前記メタ情報は暗号化された形で格納される。これにより、復号化は、メタ情報を復号化することが可能なシステムによってのみ実行される。インターセプタ（interceptor）モジュールにはこれを実行するための機能と鍵とを有しており、他の「標準の」オペレーティングシステム（ＯＳ）はそうではないため、ファイルコンテンツとメタ情報は、「標準の」オペレーティングシステム（ＯＳ）が仮にそれを読み出せたとしてもコンテンツは暗号化されたままなので、保護されたままである。

１つの態様として、前記インターセプトモジュールは暗号化されたメタ情報を復号化する。これにより、メタ情報の復号化と実ファイルコンテンツの復号化が可能となる。しかし、これは他の標準のシステムでは実行できない。

１つの態様として、前記ファイルは、メタ情報を格納した前記ヘッダと実ファイルコンテンツとを含むファイルであると特定されるための情報を含む。

これにより、当該ファイルが「コンテナファイル（container file）」であること、そしてそれは適切に、つまりメタ情報を読み出して、そこに格納されたポリシを設定し、更にファイルポインタをヘッダサイズに相当する量だけ移動させるといったような処理がなされる。

１つの態様として、インターセプタ（interceptor）モジュールは２つのコンポーネントを有する。１つはシステムコールをインターセプトするためのインターセプト（intercepting）コンポーネントである。もう１つは、システムコール又はその引数の任意の変更を実行するための、例えばシステムコールが関係するデータの暗号化を実行するための、コンポーネント（「データハンドラ」）である。一態様における第１のコンポーネントはカーネル空間（kernel space）に実装されるが、第２のコンポーネントはユーザ空間のライブラリ及びプログラムの利用を可能にするためにユーザ空間（user space）に実装できる。このようなケースでは、システムコールとそのパラメータは第１のコンポーネントから第２のコンポーネントへフォワードされなければならない。しかし、第２のコンポーネントはユーザ空間で機能しているので、第２のコンポーネントが、アプリケーションのバッファ内にある、アプリケーションのシステムコールが関係するデータに直接アクセスするができない場合がある。なぜなら、ある１つのユーザ空間アプリケーションは通常、別のユーザ空間アプリケーションのデータに直接アクセスすることを禁止されているからである。この理由から、データは一態様によればコピーされる。次いで、コピーされたデータへの新たなポインタが（暗号化を実行する）第２のコンポーネントにフォワードされ、インターセプトモジュールの第２のコンポーネントがそのデータにアクセスできる。

本方法の更なる態様として、前記インターセプトモジュールは完全にカーネル空間で動作しており、アプリケーションプログラムからのシステムコールをインターセプトするためにそれらのシステムコールをアプリケーションプログラムから（それを通じて）受信するインタフェースを有する。

本発明は、上記課題を解決するための手段として、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むファイルを作成するための書き込み操作をオペレーティングシステム上で動作するアプリケーションがコンピュータにより実行するための方法（ファイル作成方法）も提供する。本方法は、前記ファイルをそのデータを記憶媒体に書き込むことによって作成するために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと、インターセプトモジュールが前記システムコールをインターセプトするステップと、前記インターセプトモジュールが前記ヘッダのメタ情報を前記記憶媒体に書き込んで、それにより前記インターセプトモジュールが、前記ファイルに対してその後システムコールがあった場合に該メタ情報に基づいて、前記ファイルに対する該システムコールの実行が許可されるか拒否されるかを判断することができるようにするステップと、書き込まれるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記実ファイルコンテンツの書き込み操作が前記ファイル内の前記ヘッダの後に実行されるようにするステップとを含む。

このようにして、書き込み操作は、ファイルの作成にあたって、ヘッダが書き込まれた後にデータをファイルに書き込むことによって、アプリケーションにとって透過的な方法でファイルが作成される。

本方法の書き込み操作は、前記ファイル操作方法の上記いずれかの態様の任意の特徴を更に含む。

本発明は、上記課題を解決するための手段として、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むファイルに対する操作をオペレーティングシステム上で動作するアプリケーションが実行するための装置も提供する。本装置は、前記ファイルにアクセスするために前記アプリケーションプログラムから前記オペレーティングシステムのシステムコールを受信するモジュールと、前記システムコールをインターセプトするためのインターセプトモジュールと、前記インターセプトモジュールによって前記ヘッダに格納されたメタ情報を読み出すためのモジュールと、前記メタ情報に基づいて、前記ファイルに対する前記システムコールの実行が許可されるか拒否されるかを判断するとともに、前記判断の結果、前記システムコールが許可される場合には、アクセスされる前記ファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記システムコールが前記実ファイルコンテンツに対して実行されるようにするためのモジュールとを備えている。

このようにして、上記課題を解決することができる１つの手段としての装置が実現できる。

本発明は、上記課題を解決するための手段として、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むファイルを作成するための書き込み操作をオペレーティングシステム上で動作するアプリケーションが実行するための装置も提供する。本装置は、データを記憶媒体に書き込むことによって前記ファイルを作成するために前記アプリケーションプログラムから前記オペレーティングシステムのシステムコールを受信するモジュールと、前記システムコールをインターセプトするためのインターセプトモジュールと、前記インターセプトモジュールによって前記ヘッダのメタ情報を前記記憶媒体に書き込んで、それにより前記インターセプトモジュールが、前記ファイルに対してその後システムコールがあった場合に該メタ情報に基づいて、前記ファイルに対する該システムコールの実行が許可されるか拒否されるかを判断することができるようにするとともに、書き込まれるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記実ファイルコンテンツの書き込み操作が前記ファイル内の前記ヘッダの後に実行されるようにするためのモジュールとを備えている。

このようにして、上記課題を解決することができるもう１つの手段としての装置が実現できる。

これらの装置は、前記ファイル操作方法の上記いずれかの態様における任意の特徴を実装するためのモジュール又は手段を更に含む。

本発明は、上記課題を解決するための手段として、上記いずれかの態様の方法をコンピュータに実行させるコンピュータプログラムコードを含むコンピュータプログラムも提供する。

本発明の実施の一形態を示す図である。 本発明の更なる実施形態を示す図である。 本発明の実施の一形態によるフローチャートである。 Systraceフレームワークを示す図である。 本発明の実施の一形態によるインターセプタのコンポーネント図である。 本発明の実施の一形態によるシーケンス図である。 本発明の実施の一形態によるファイル構造を概略的に示す図である。 本発明の実施の一形態によるファイル構造を概略的に示す図である。 本発明の実施の一形態によるファイル操作を概略的に示す図である。

本発明の実施形態を説明する前に、最初に、以下の記述で用いられるいくつかの用語について説明する。

・システムコール（System Call）は、ユーザ空間アプリケーションが、カーネル（Kernel）によって提供されるディスクドライブ、ネットワーク接続などのサービス又はアクセス保護リソースを要求するための機構である。これらのサービスは、ユーザ空間においてアプリケーションが直接呼び出すことが許されていないカーネル空間における一連の特権的機能によって実装される。アプリケーションは、適切なシステムコールを使用することによって、カーネルに対してこれらの機能の呼び出しを求めなければならない。
・システムコールインターポジション（System Call Interposition）は、呼び出されたシステムコールをインターセプトし、それらの実行を拒否もしくはそれらの引数（argument）を変更するための機構である。
・アクセス制御（Access Control）は、認証（authentication）、承認（authorization）、監査（audit）の各エリアにおける機構とサービスとから成る。アクセス制御（Access Control）モデルでは、サブジェクト（subject）はオブジェクト（object）に対して、ある特定の操作を実行することができる。許可（permission）は、３つの主要部分、すなわち、任意アクセス制御（Discretionary Access Control）と、強制アクセス制御（Mandatory Access Control）と、ロールベースのアクセス制御（Role-Based Access Control）とに分類されるアクセス制御方法によって定められる。
・利用制御（Usage Control）は、データが第三者へリリースされたときは常にそのデータに何が起こらなければならないかという要件を定める機構を提供することにより、アクセス制御を拡張するものである。通常、許可される操作として、例えば、ファイルは２回しかプリントアウトできないとか、電子メールは他の誰にも転送できないといったことは、ポリシ（policy）によって記述されている。
・管理情報（Managed Information）は、利用制御という意味におけるデータである。ポリシはそのデータの要件を決定する情報へと割り当てられている。したがって、管理情報は、データとポリシとからなるタプル（tuple）であり、つまり管理情報＝データ×ポリシである。
・監視対象アプリケーション（Traced Application）は、本発明の実施形態においてフレームワーム内で実行されるアプリケーションである。アプリケーションはサンドボックス化され、アプリケーションの挙動を制御するハンドラ（handler）の監視下で実行される。

実施の一形態によれば、データの取り扱いに関する制約又はポリシを設定できる機構が提供される。例えば、情報のプロバイダは情報の流れをコントロールし、特定の状況において特定のアクションを取ることに関心を持っている。情報のこの種の制御されたリリースは、管理情報（managed information）の利用制御（usage control）と呼ぶことができる。なぜなら、情報はプロバイダの制御エリアを出て他の誰かへ転送されるからである。

実施の一形態によれば、設定がシステム全体に及ぶように、オペレーティングシステムレイヤに働きかけるか、又はオペレーティングシステムに追加のレイヤを付加する機構が導入されている。

実施の一形態においては、アプリケーションからのシステムコールが、例えばハードディスク、あるいはバッファその他の記憶媒体といった任意の記憶媒体に格納されたファイルに作用し始める前に、そのシステムコールをインターセプトするインターセプトモジュール（intercepting module）が提供される。インターセプタ（interceptor）は、このようなシステムコールがデータに対して実行される前に、そのシステムコールをインターセプトする。次いで、インターセプトモジュールはデータの取り扱いに関するポリシ又は必要とされる制約（例えば暗号化又は復号化）を設定し、続いて、対象のデータに対して実行されるようにシステムコールを転送する。

以上述べたことを図１に概略的に示している。図１において、インターセプタモジュールはオペレーティングシステム（ＯＳ）レイヤ内に位置している。言い換えると、インターセプタモジュールは、アプリケーションレイヤと、対象のデータを格納する実際のハードウェア（ＨＷ）との間に位置している。オペレーティングシステム（ＯＳ）上のアプリケーションは、対象の記憶媒体（例えばハードディスク）に格納されたデータへアクセスしようとする。意図されるアクセス操作としては、例えば読み出し操作、書き込み操作である。

このような状況において、アプリケーションはいわゆるシステムコールによってオペレーティングシステム（ＯＳ）に対してデータの書き込み操作又は読み出し操作を要求する。システムコールとは、アプリケーションプログラムがオペレーティングシステム（ＯＳ）又はオペレーティングシステム（ＯＳ）内のカーネルからのサービスを要求するために用いられる機構である。次いでオペレーティングシステム（ＯＳ）は、アプリケーションプログラムによる追加的な制御を受けることなく、それ自体の体制下でシステムコールを実行する。言い換えると、システムコールを発行したアプリケーションプログラムは、それ自体の実行フローの中で（データ書き込み又はデータ読み出しといった）操作を実行するために必要な権限を有していない。システムコールはプロセスとカーネルとの間のインタフェースを提供する。システムコールは、そのシステムコールを呼び出したアプリケーション又はプロセスが、呼び出したサービスを単独で実行する権限を持っていない場合において、ある特権レベルでのサービスの実行を提供する。オペレーティングシステム（ＯＳ）は、最高の特権レベル（あるいは、少なくともアプリケーションプロセス又はアプリケーションよりも高い特権レベル）で動作しており、アプリケーションがシステムコールを用いてサービスを要求することを可能とする。

実施の一形態によれば、システムコールをインターセプトする機構が提供される。この機構は、オペレーティングシステム（ＯＳ）へシステムコールが発行された際に、そのシステムコールが変更できるように、または変更された方法でそのシステムコールが実行できるように、あるいはアプリケーションプログラムが期待するものを超える方法でシステムコールが実行されるようにするためのものである。このようにして、システムコールの実行をインターセプトモジュールで変更することによって、図１に示したバイトストリームは、変更された方法で読み出し又は書き込みがなされる。

実施の一形態によれば、システムコールはファイルへ作用するものである。次に、インターセプトモジュール（インターセプタ）によって実行される変更について、図２を参照して説明する。

インターセプタは、ファイルに作用するシステムコールを受信する。ファイル（及び操作）が始まる位置を特定するために、ファイルポインタがシステムコールとともに提供される。図２では、ファイルポインタは値ｘとしている。次にインターセプタモジュールは、値ｙを加えることによって、ファイルポインタをｘ＋ｙに変更する。これは次のような効果を持つ。

ファイルに作用する際に、ファイル操作は、ファイルの実際の開始位置ｘから始まらずに、ファイルの実際の開始位置よりも後の位置ｘ＋ｙから始まる。つまり、図２に示したような、ファイルの冒頭に位置する「ヘッダ」は、位置ｘ＋ｙ（ヘッダより後の位置）からのみ始まる通常のファイル操作によってアクセスされることはない。

このようにして、システムコールを要求したアプリケーションがアクセスできないファイルの一部（ヘッダ）が提供される。したがって、ヘッダはシステムコールを要求したアプリケーションプログラムにとっては透過的である。よって、ヘッダはアプリケーションプログラムから「保護（プロテクト）」又は「遮蔽（シールド）」されている。その理由は、オペレーティングシステム（ＯＳ）と比べてアプリケーションの特権レベルが低い結果、システムコールの実行がそのシステムコールを呼び出したアプリケーションプログラムの及ぶ範囲を超えているために、アプリケーションプログラムはシステムコールが作用する仕方に影響を及ぼすことがない点にある。

図２によれば、実施の一形態の機構は、あるタイプのファイル、すなわち、メタ情報を含む（ファイルの冒頭にある）ヘッダと、実際のファイルデータ（「ペイロード」）とを含むファイルを用いる。この構造を有するファイルを、以下、「コンテナファイル（container file）」と呼ぶことにする。ヘッダのサイズは、アプリケーションプログラムが要求する操作を実行するために、ファイルにアクセスするときにインターセプタモジュールがファイルをシフトする量（図２に示した「ｙ」）に相当する。このように、ファイルヘッダは、アプリケーションにとっては「透過的」であり、アプリケーションプログラムからシールドされている。

したがって、実施の一形態によれば、インターセプトされたシステムコールが作用するファイルは、ヘッダと通常のファイルコンテンツとを有する「コンテナファイル」である点に留意すべきである。さらに、インターセプタは、アプリケーションプログラムに気付かれない方法（透過的な方法）で通常のファイルコンテンツ（ペイロード）に作用するために、ヘッダのサイズに相当する量だけファイルポインタをシフトすることによって、通常のファイルコンテンツにアクセスできるようにする点にも留意すべきである。ファイル操作の完了後、ファイルポインタはシフト量と同じ量だけシフトバックさせることができる。

ヘッダはアプリケーションプログラムにとってはアクセスできないが、インターセプタモジュール（又はオペレーティングシステムレベルで提供された任意の他のモジュール）にとってはアクセス可能である。このとき、インターセプタモジュールは、ファイルの読み出し又は書き込みの際にどのような制約や規則、ポリシが適用されるべきかについてのメタ情報（meta-information）を含むことができるヘッダを読み出す。実施の一形態において、メタ情報は、ファイルへアクセスするときに設定されるポリシについての情報を含んでいる。このような情報は、例えば、システムコールが、変更されていない方法でファイルへアクセスできるといった１つ以上の条件の定義を含んでいる。このような情報は、システムコールがファイルへアクセスすることが全く許されない１つ以上の条件の定義を更に含むことができ、及び／又は、このような情報は、変更された方法でのみ、例えば、暗号化又は復号化といった追加の操作を実行することによって、実ファイルデータへアクセスすることが許される１つ以上の条件の定義を含むことができる。

このため、実施の一形態におけるインターセプタは、ファイルのヘッダを読み出すモジュール又はコンポーネント（例えば、決定モジュール又は設定モジュール）を含んでいる。この場合、そのヘッダのコンテンツに基づいて、インターセプタはファイルの取り扱いに関するポリシを決定し、設定することができる。ポリシの設定としては、例えば、ファイルに対する特定の操作が許可されること、又はそれが拒否されること、あるいはそれが変更できることである。操作の変更とは、例えば、暗号化の操作又は復号化操作の追加である。この結果、ファイルは書き込まれる前に暗号化され、あるいはファイルが読み出される前に復号化される。

実施の一形態によれば、ポリシの設定はヘッダのコンテンツのみに基づいているのではなく、追加的又は代替的に、ポリシの設定はシステムコールを要求するアプリケーションプログラムのタイプにも依存する。ヘッダは、例えば、特定のアプリケーション（例えばＭＳ−Ｗｏｒｄ）のみがファイルを読み出すことが許されるといった情報を含む。この場合、インターセプタ（又は決定モジュール）は、どのような種類のアプリケーションがシステムコールを要求したかを特定し、それがＭＳ−Ｗｏｒｄでなかった場合には、ファイルへのアクセスは拒否される。

ヘッダ内に示されている、このような種類のポリシは、相対的にみて具体的である。例えば、ファイルはＭＳ−Ｗｏｒｄによって開くことができるが、そのファイルを電子メールに添付することは許されないという定義がヘッダ内にポリシとして含まれる。この場合、あるシステムコールがそのファイルを電子メールに添付したいとするアプリケーションプログラムに基づいていることをインターセプタが認識したときには、その操作は拒否されることになる。

これは、システムコールを要求したプロセスのプロセスＩＤ（process identifier：ＰＩＤ）を用いることによって実装できる。オペレーティングシステム（ＯＳ）は、プロセスＩＤとその対応するアプリケーションプログラムとの間のマッピング（対応関係）を有している。メタ情報内のポリシが、アプリケーションプログラムと、そのアプリケーションプログラムがアクセスを許可されているのか拒否されているのかとを示すものである場合には、システムコールとともにオペレーティングシステム（ＯＳ）へ渡されたプロセスＩＤに基づいてこのマッピングを参照することができる。

図３はこのような実施形態のフローチャートを示している。最初に、システムコールがインターセプトされる。次いでコンテナファイルのヘッダが読み出され、オプションとして、当該システムコールを要求したアプリケーションが特定される。この情報は後続の判断プロセスで用いられるものである。判断プロセスでは、システムコールの実行が許可されているか拒否されているかを判断するために、この情報に基づいてポリシ（例えば利用制御ポリシ）が設定される。処理手順は、システムコールは許可されるものの、その実行に際して、例えばペイロードデータの暗号化又は復号化を追加的に実行するなど、変更される必要があることを決定することを追加のステップとして含むことができる。

実行が許可されているという判断された場合には、処理手順は「ｙｅｓ」に導かれる次のステップに進み、ファイルポインタをヘッダの量だけ前進させてから、ヘッダの後に続くファイルデータに対して、変更された方法又は変更されていない方法でシステムコールを実行する。設定されたポリシに基づいて、システムコールの実行を拒否すべきであるという判断が行われた場合には、処理手順は「ｎｏ」に導かれる次のステップに進み、システムコールの実行を拒否する。この場合には、エラーメッセージが表示されたり、あるいはエラーメッセージのない「サイレント拒否」が行われたりする場合がある。

他方、実施の一形態によれば、ファイルポインタはシフトされず、アプリケーションは、変更されない仕方でメタ情報も含めてファイルを取得することもできる。これは、ファイルが変更されることなく（保護された方法で）別のシステムへと送信されることになっており、それによりファイルが送られるシステムがそのファイルを、メタ情報も含めて完全に受信するような場合などに特に有用である。

別のオプションとして、判断プロセスは、システムコールの実行が何らかの更なる情報、例えばユーザによるコードの入力を必要とするという結果をもたらす。この場合、処理手順は次のステップに進み、対応するユーザ入力を促し、続いて、ユーザによって正しいデータが入力されたことがチェックされた場合には、更に次のステップに進み、ユーザからの情報が暗号化又は復号化に必要な鍵であった場合には、データの暗号化又は復号化に際しユーザからの情報を使用して、ファイルに対してシステムコールを実行する。

実施の一形態によれば、当該システムはデータの自動暗号化及び自動復号化を提供する。実施の一形態において、データ記憶媒体に書き込まれるファイルは自動的に暗号化される。つまり、書き込み操作の場合にインターセプタモジュールによって実行されるシステムコールの変更は、実ファイルデータ（actual file data）が書き込まれる前にそれを暗号化することを含むものであり、データが記憶媒体に書き込まれるときにそのデータはヘッダとともに暗号化された形で書き込まれる。実ファイルコンテンツの自動暗号化は、許可されていないアクセスからその実ファイルコンテンツを保護する。ヘッダに定義されたメタ情報又はポリシは、ファイルの復号化が許可される条件を定めることができる。例えば、ある特定のタイプのアプリケーションプログラムが復号化の後のファイルへアクセスできるということを定める場合があり、この場合、そのアプリケーションを発行元とするシステムコールは、実データがそのアプリケーションプログラムへ返される前にその実データが復号化されるように、変更される。他方、呼び出し元のアプリケーションプログラムがメタ情報内にアクセスが許可されているとして定義されていない場合には、復号化は行われず、復号化された形でデータへアクセスすることができない。

書き込み操作と読み出し操作は、ある程度までは対称的なものであると見なすことができることは理解されよう。つまり、実施の一形態におけるファイルの書き込みは、ヘッダと、それに続く実ファイルコンテンツがともに１つのファイルに書き込まれてコンテナファイルを形成する形で行われる。ヘッダは当該ファイルを取り扱うためのポリシを定める。実施の一形態によれば、書き込みの対象となる全てのファイルはコンテナファイルである。別の実施形態によれば、書き込みの対象となるファイルの一部のみがコンテナファイルである。書き込み操作によってコンテナファイルが生成されるか、又は「通常の」ファイルが生成されるかについても、インターセプタモジュールに関して設定されるポリシとして定めることができる。例えば、ある特定のアプリケーションについて、これらのアプリケーションによって実行される全ての書き込み操作はコンテナファイルを生成するものとすると定められる。他のアプリケーションについては、通常のファイルを生成することが許されると定められる。

実施の一形態によれば、ヘッダ内のメタ情報は、鍵、又は実ファイルコンテンツを復号化するために必要な鍵を取得もしくは導くために使用可能な何らかのデータもしくは情報（例えば、キージェネレータ、又はキージェネレータの初期値など）を含む。この情報は、ファイルが記憶媒体に格納される際にヘッダに書き込まれている。このような場合において、ファイルを復号化するために必要な情報は、ある特定のマシン又はコンピュータの範囲を越えて別のマシンへ送ることができる。そして、ファイル自体はなおも保護された状態のままであり、他のマシンは、そのオペレーティングシステム（ＯＳ）がヘッダと実ファイルコンテンツとを読み出して解釈できるインターセプタモジュールを有している場合には、復号化の後のファイルへアクセスできる。

実施の一形態によれば、ヘッダ内に含まれる鍵又は鍵を取得するためのデータも暗号化される。また、ヘッダの復号化は例えば、本発明の実施形態によるインターセプトモジュールを有していて、かつヘッダ情報を復号化するために必要な鍵を有するオペレーティングシステム（ＯＳ）にとってのみ可能である。ヘッダを復号化するための鍵は例えば、本発明の実施形態によるインターセプタモジュールを有する全てのオペレーティングシステム（ＯＳ）が利用可能なマスターキーである。様々なファイルの実ファイルデータを暗号化するために異なる鍵を使用することができる。そして、これらの異なる鍵は、暗号化された形で、それぞれのコンテナファイルのヘッダ内に格納される。本発明の実施形態によるインターセプタモジュールのマスター鍵は、ヘッダ内に格納されたこのような鍵（異なる鍵）を復号化することができ、復号化された鍵は実ファイルコンテンツを復号化するために使用することができる。このようなコンポーネント（とこのようなマスター鍵）を持たない他のオペレーティングシステム（ＯＳ）は、ヘッダを読み出すことは可能かもしれないが、それを復号化することはできない。また、ヘッダが実ファイルデータを復号化するために必要な鍵を含んでいる場合には、ヘッダを復号化できないオペレーティングシステム（ＯＳ）は実ファイルデータも復号化できない。このようにして、コンテナファイルはインターセプタモジュールと連携して、様々なマシン、コンピュータ、オペレーティングシステム（ＯＳ）にわたってファイルコンテンツの保護を実現することができる。言い換えると、ファイルポリシが設定され、ファイルは「ポータブル（持ち運び可能）」でありながらなおも保護される。

上記の実施形態は、管理情報（managed information）の保護に対処する目標を達成することができる。コンテナファイルの概念は、ある特定のポリシを設定するため、例えばファイルシステムにおいて管理情報を暗号化して保存するために利用される。本アプローチは以下のようないくつかの利点を有している。

最初に、ポリシの設定（例えばファイルの暗号化）は、アプリケーションに気付かれないように（透過的に）実行される。つまり、アプリケーションがファイルからデータを読み出しているとき、あるいはファイルへデータを書き込んでいるときはいつでも、データは暗号化あるいは復号化されている。コンテナファイル内のデータのこの処理は、オペレーティングシステム（ＯＳ）レベルで行われるものであり、アプリケーションによってトリガー又は実行されることはない。したがって、いずれのアプリケーションも適応化や再コンパイルすることなく本発明の利益を享受することができる。第２に、暗号化は特定のファイルのみへ選択的に行うことができる。つまり、ファイル内のデータの暗号化を要求するポリシを定義することができる。ファイルへのポリシのバインディング（関連付け）はコンテナファイルを用いて行われる。このバインディングは、いずれのアプリケーションにも気付かれず（透過的であり）、いずれのアプリケーションからも独立している。さらに、別のシステムへ送られる場合にも、ポリシとファイルとのバインディングが変更されることはなく、それゆえデータはシステム間でコンテナファイルによって保護されている。

第３に、ファイルの暗号化は、以下の理由から、ファイルシステムの暗号化を利用するといった別のアプローチよりも好適である。まず、ファイルシステムの暗号化は、パーティションに保存されたデータが暗号化されるということを保証するのみである。いずれのアプリケーションも、復号化されたデータへ（ユーザの認証が成功した後に）アクセスできる。しかし、本アプローチでは、コンテナファイル内の復号化されたデータへのアクセスは、アプリケーション単位で（アプリケーションを変更することなく）、かつポリシによって暗号化が実行できる。さらに、通常、ディスク全体でただ１つの鍵しか存在しない。セキュリティを高めるためには様々なファイルは異なる鍵で暗号化されることが理に適っており、これは本提案の機構によって可能となる。加えて、利便性という特徴がある。ポリシによって保護された貴重な情報を受け取りたいと考えている第三者が、暗号化されたディスクを最初に用意しなければならないとしたら非常に不便であろう。これでは負担が過大なものとなる。

コンテナファイルは、既に述べたような動作を行うインターセプタが提供される限り、すなわちコンテナファイルを読み出したり、コンテナファイルへ書き込んだりする際にそれがどのように処理されるかが与えられている限り、Linux、Windows(登録商標)、Symbian、Windows(登録商標) Mobileといった任意のオペレーティングシステム（ＯＳ）がサポートすることができるコンセプトである。本提案の実施形態は、読み出し及び書き込みと、入力パラメータのほかに出力パラメータの操作とのために、システムコールのインターポジションを用いる。システムコールのインターポジションは、上記のオペレーティングシステム（ＯＳ）で使用できるコンセプトである。したがって、本提案のソリューションは様々なシステムに実装でき、システム及びデスクトップから携帯電話機までカバーする。

実施の一形態によれば、本提案の機構は、管理情報（managed information）、つまり機密（例えば個人データ、企業機密）を含んだ情報、つまり保護されなければならない任意の情報の制御を扱う。具体的には、本発明の実施形態は情報を暗号化することによって情報の保護に対処することができる。実施の一形態における暗号化は、ユーザと、管理情報を処理するアプリケーションとに気付かれないように（透過的に）行われる。管理情報を特定し、その管理情報がどのように処理されるべきかを特定するポリシが定義されているため、暗号化はユーザにとって透過的である。また、ポリシの設定はオペレーティングシステム（ＯＳ）レベルで行われるので、それ自体アプリケーションにとって透過的である。

技術的には、新たなファイルがアプリケーションによって生成される場合にはいつでも追加のメタ情報が格納される状況を考えることができる。このメタ情報は例えば、新たなファイルのポリシ又は分類を符号化（エンコード）するために使用することができ、ファイルの冒頭に格納されるが、ファイルの残りの部分は通常のファイルコンテンツを格納する。冒頭の保護エリアと、ファイルコンテンツを格納する第２のエリアとから成るこのファイルはコンテナファイル（container file）と呼ばれる。

本発明は、実施の一形態によればアクセス及び利用制御という意味で容易に使用することができる。本発明はアクセス及び利用のポリシを設定するための制御機構を提案するものである。制御機構はオペレーティングシステム（ＯＳ）レベルで実装されるため、データへアクセスして、そのデータを利用する任意のアプリケーションは、制御機構を実行するオペレーティングシステム（ＯＳ）上で実行されることが求められる。さらに、データプロバイダはデータが任意の第三者、つまりデータの利用者へリリースされる前にそのデータを暗号化することによってデータを保護することができるため、利用制御が行われる。この場合も同じく、データ利用者のシステムが制御機構をサポートしている場合には、データ利用者は容易にデータへアクセスして、そのデータを利用することができる。

以下、本発明の更なる実施形態をより詳しく説明する。

実施の一形態によれば、システムコールのインターポジションを取り扱うことができ、本発明の実施形態を実装するために変更した既存のフレームワークが使用される。

使用することができる１つのフレームワークは、Systrace（非特許文献「Niels Provos. Improving host security with system call policies. In SSYM'03: Proceedings of the 12th conference on USENIX Security Symposium, pages 18-18, Berkeley, CA, USA, 2003. USENIX Association」参照）である。実施の一形態によれば、Systraceフレームワークはファイル処理の機構を実装するために使用される。

以下、Systraceフレームワークを用いることによって、上記実施形態で説明したようなインターセプタモジュールとその動作を実現する実施形態を説明する。これは実装の１つの可能なオプションに過ぎず、同じ機能を実現できるのであれば他のフレームワークも使用できることを理解されたい。

Systraceは、先に紹介したシステムコールのインターポジションすなわちインターセプションを実装するシステムコールフレームワーク全体の中の１つのものである。Systraceはコンピュータセキュリティ・ユーティリティであって、その主な目的はシステムコールのインターポジションに基づいて特定のアプリケーションに対するセキュリティポリシを設定することにある。原則、Systraceはアプリケーションのシステムコールをインターセプトして、それらを所与のポリシと比較する。したがって、Systraceは、監視対象アプリケーションをある種のサンドボックスに入れて、第一の段階においてその挙動を監視する。システム全体のセキュリティを高めるため、Systraceは呼び出されたシステムコールも制御する。Systraceのウェブサイトで言及されている典型的な例は、ウェブサーバである。ウェブサーバは主に、事前に定めらた文書をインターネット上に公開するものであるが、ウェブサーバが「／ｅｔｃ」、「／ｕｓｒ」といったディレクトリにあるファイルへのアクセス権を持つべきというシナリオは全く存在しない。Systraceフレームワークは、ウェブサーバがその主要なタスクを果たすためにアクセスする必要のないディレクトリに存在するファイルへアクセスするためのウェブサーバの機能を制限するために使用することができる。Systraceポリシは、どのファイルがウェブサーバによってアクセスできるかと、どのアクセスが拒否されるべきかとを正確に記述する。ウェブサーバが、保護エリア内のファイルを参照する１つ以上のパラメータを含んだシステムコールを呼び出した場合には、Systraceは常にそのシステムコールの実行を阻止する。このアプローチは、攻撃者（attacker）が、例えばバッファオーバフローを利用して、ウェブサーバが公開するつもりのないファイルへアクセスできるというリスクをなくす。これは実現可能である。なぜならば、大部分の攻撃は、攻撃自体がシステムコールの機能を必要とするように、抽象的な階層におけるシステムコールのレベルよりも上のレベルで起こるからである。

Systraceのアーキテクチャを図４に示している。

図４に示すように、Systraceアーキテクチャは２つの部分から成る。１つはカーネル空間（kernel space）であり、もう１つはユーザ空間（user space）である。

［カーネル空間］
Systraceのカーネル空間は、２つの主な機能を有する。まず、システムコールが呼び出されるコントロールフローポイントにおいてフックイン（hook in）し、次いでシステムコールをユーザ空間へ転送する。二番目の重要な機能はIn-Kernelポリシである。この機構は、常に許可又は拒否されるべきシステムコールに必要とされる高速パス評価（fast path evaluation）と呼ばれる。この高速パス評価はパフォーマンスの理由から導入されている。というのも、システムコールは、In-Kernelポリシに基づいて許可される場合、ユーザ空間へリダイレクトされるのではなく、通常のように実行されるからである。したがって、導入されるオーバヘッドは可能な限り小さい。なぜなら、ユーザ空間へのリダイレクトは、システムコールが許可されるべきか拒否されるべきかをIn-Kernelポリシが決定できない場合にのみ起こるからである。

［ユーザ空間］
In-Kernelポリシが、システムコールが許可されるか拒否されるかどうかを決定できない場合には、Systraceのカーネルは、システムコールをユーザ空間へフォワードする。これは自動的にコンテキストスイッチをもたらし、パフォーマンスに何らかの影響を及ぼす。このようにフォワードされたシステムコールの意義（semantic）は、ユーザ空間のデーモンに対して、システムコールが許可されるべきか拒否されるべきかを照会するという点である。ユーザ空間のデーモンは、システムコールの引数を見て、そのシステムコールを（引数を抜きにしてシステムコール自体を評価するIn-Kernel部分と比べて）更に深く調べる。セキュリティポリシが適切なエントリを有している場合には、システムコールはユーザとの相互作用なく許可又は拒否できる。この自動的な評価ができない場合、あるいはSystraceポリシがイクスプリシットに自動的な評価を無効としている場合、実行アプリケーションのユーザは照会を受けなければならない。これは、システムコールに関する情報とそのシステムコールを許可又は拒否する可能性を提供するポップアップウィンドウにより行われる。セキュリティをさらに高めるため、ユーザ空間のデーモンはアプリケーションを継続して監視している。例えば、ユーザ空間のデーモンはプロセスがその状態を変えるときはいつでも通知を受ける。そうすることによって、ユーザ空間のデーモンは、監視プロセスの分岐（fork）、終了、ｕｉｄ又はｐｉｄの変更などの時点を知る。

システムコールをユーザ空間へフォワードすることで、システムコールが関係するデータをメモリ内の新たな場所へコピーすることが呼び出されることがあり、次いでその新たな場所へのポインタもユーザ空間で動作するコンポーネントへフォワードされる。その理由は、１つのユーザ空間アプリケーションは通常、別のユーザ空間アプリケーションのデータへ直接的にアクセスすることができないため、第２のコンポーネントが、そのアプリケーションのシステムコールが関係する、該アプリケーションのバッファ内のデータへ直接的にアクセスすることはできないと考えられるからである。このため、データは実施の一形態によればコピーされ、コピーされたデータに対する新たなポインタは、ユーザ空間で動作する（後で暗号化を実行する）コンポーネントがアクセスできるように、そのユーザ空間で動作するコンポーネントへフォワードされる。

Systraceモジュールは、以下に説明する実施形態を実現するために使用される。図５にこの実施形態の全体の構造を概略的に示している。

全体のアーキテクチャは４つのモジュールから成り、各モジュールは異なる処理を担当する。これらは、全体で先の実施形態の「インターセプタ」を構成する。

このモジュラアーキテクチャの背後にあるアイデアは柔軟性であるが、各モジュールは単一のモジュールに組み込むこともできる。

しかし、特異的になり過ぎたためにただ１つの特殊な状況にしか適用できないといったことにならないように、多くのシナリオに適用することができるフレームワークを提供する。その柔軟性により、実施の一形態において次のような４つのメインパッケージに区別できる。ハンドラ（Handler）はアーキテクチャの中心であり、メインコントローラである。ハンドラは、その機能を遂行するため、他の３つのコンポーネント、すなわちカーネルコネクタ（KernelConnector）、データハンドラ（DataHandler）、（オプションとして）GUIコンポーネントへアクセスする。

カーネルコネクタは、ハンドラとカーネルとの間の接続を担当する。具体的な実施形態として、カーネルコネクタは、SystraceフレームワークのＡＰＩ（Application Programming Interface）を利用する。基礎となるフレームワークを交換したい場合、あるいはSystraceをサポートしないが異なるものをサポートする別のシステムへそのフレームワークを移したい場合は、カーネルコネクタのみを更新するだけで済むであろう。これが、図５に示したようにカーネルコネクタがインスタンス化できる理由である。他の全てのコンポーネントは、基礎となるフレームワークの選択には影響されない。

ハンドラは呼び出されたシステムコールから情報を抽出する役割を担う。柔軟性を更に高めるため、ハンドラ自体に代わり別のデータハンドラが、呼び出されたシステムコールの引数を変更するか、あるいは応答する。つまり、ハンドラは情報をデータハンドラへフォワードし、変更された結果を得る。情報を得た後、ハンドラは当初のシステムコールの引数を変更後の引数に上書きする。

データハンドラは、データに関して何が起こるべきかを決定する。実施の一形態におけるデータハンドラはユーザ空間で動作するため、利用可能な任意の更なるライブラリにアクセスできることからデータを可能な限り自由に変更できる。

最後のモジュールはＧＵＩコンポーネントである。状況によっては、フレームワークは全てのデータを完全には自動的に処理することができない場合がある。時として、アプリケーションのユーザは、特別なファイルに関するメタ情報といった不足データを提供するなどしなければならない。ＧＵＩコンポーネントは、実施の一形態によればアーキテクチャ内の別個のコンポーネントであり、シンプルなポップアップウィンドウから複雑なデータベースクエリまで、異なるやり方でインスタンス化できる。何千もの他のデータリソースが存在するため、理論的には全てこのフレームワークで使用できる。それゆえ、ＧＵＩコンポーネントは、不足している情報のための、フレームワークとデータソースとの間のインタフェースの機能を果たす。

様々なコンポーネント間の相互作用の非常にシンプルな例を示す。本例において、write()というシステムコールにより書き込まれるあらゆるバッファは、暗号化される必要がある。つまり、図６に示すように、カーネルコネクタはシステムコールとバッファとに関する情報をカーネルから受信し、バッファをハンドラへフォワードする。ハンドラはバッファを変更しないので、ハンドラはバッファを、データを暗号化するデータハンドラへフォワードする。ハンドラが当初のプレインテキストバッファを暗号化されたものへ置き換えると、カーネルは、変更されたバッファが元のバッファに代えて書き込まれるように、write()というシステムコールを実行する。図６はこのシンプルな例のシーケンス図である。

フレームワークのアーキテクチャを、図５のコンポーネント図により示している。カーネルコネクタ、データハンドラ、及びＧＵＩコンポーネントは、それらが特定の状況に適したものとなるように、インスタンス化が可能であることに留意すべきである。具体的な方法は、管理情報に関して既に言及したコンテナファイルである。コンテナは、ファイルコンテンツと、適用可能なポリシ又は分類とを区別するが、その両方を、ファイルシステムに（できれば暗号化した上で）保存される１つの物理的ファイルとして組み合わせる。

このアーキテクチャによれば、read()及びwrite()というシステムコールをインターセプトすることを可能にするとともに、ファイルから読み出すべきデータ又はファイルへ書き込むべきデータの復号化と暗号化を実行することも可能にするシステムを実装することができる。さらに、暗号化されたデータ（つまりファイルコンテンツ）をメタ情報と結びつけたファイル構造「コンテナファイル」が実装される。メタ情報は、例えば、利用制御ポリシのほかに暗号鍵も含む。read()又はwrite()というシステムコールが行われる際の、ファイルコンテンツの暗号化と復号化は、そのシステムコールを呼び出したアプリケーションに対しては透過的（transparent）である。

実施の一形態によれば、コンテナファイルは、例えばコンテナファイルの冒頭に配置される特定の識別子によって、コンテナファイルであると特定することができる。これは例えば、コンテナファイルをコンテナファイルとして特定するための一意の「マジックナンバー（magic number）」である。非コンテナファイルが偶然にマジックナンバーを冒頭に持つ蓋然性を低減するために、より複雑な識別子、例えばマジックナンバーとして使用される計算されたチェックサムがヘッダ上で使用できる。しかし、この場合、コンテナファイルを特定するためには、常にチェックサムを計算し、それがマジックナンバーとしてファイルの冒頭に正しく配置されているかどうかをチェックする必要がある。

ファイルがコンテナファイルであると特定された場合には、インターセプトモジュールはそれをコンテナファイルとして扱う。つまり、インターセプトモジュールはポリシを設定するためにファイルポインタを移動させてヘッダを読み出す。ファイルがコンテナファイルでない場合には、そのファイルは通常のファイルとして扱われる。

ファイルがコンテナファイルか否かの判断は、他の方法でも行うことができる。１つの方法は、特定のファイル名をコンテナファイル名として定めることである。つまり、それらのファイル名を１つのリストに集めておき、そのリストに属するファイル名を有する全てのファイルをコンテナファイルとして扱う。

［ファイルポインタの移動］
次に、実施の一形態による、アプリケーションのファイルポインタを移動させる機能について説明する。既に言及したように、これは、Systraceのカーネルのモジュールに新たな機能として追加されるものである。この機能は、ハンドラによって異なる状況で何度も使用される。透過性を実現したい、あるいはアプリケーションがファイルポインタが置かれている位置とは異なる位置から読み出しもしくは書き込みをしたいときは常に、ハンドラは、ファイルポインタを別の場所に移すためにmoveFilepointer()という関数を呼び出す。この関数は、監視の対象となるプロセス（traced process）のＰＩＤと、移動させたいファイルポインタと、オフセットとをパラメータとし、この構造をioctl()コマンドにより基礎となるフレームワークへ送る。ファイルポインタを移動させる関数から見れば、通常通り、戻り値は新たな現ファイルポインタの位置である。

［ＧＵＩコンポーネントとしてのポップアップウィンドウ］
ＧＵＩインタフェースは、任意のコンポーネントである。シンプルな実施形態では、このコンポーネントは、何らかのデータ、例えば４つの整数値を入力することができるようにするシンプルなポップアップウィンドウである。実施の一形態によれば、アプリケーションが、メタデータヘッダをまだ格納していないコンテナファイルを開くときは常に、アプリケーションのユーザはポップアップウィンドウを見て不足データをメタ情報として入力することになる。このあと、この情報はコンテナファイルのヘッダに格納される。

更なる実施形態によれば、復号化又は暗号化のために不足しているキーの入力がユーザに要求される。

［データハンドラとしてのコンテナファイル］
データハンドラは多くの異なる方法でインスタンス化できる。この節では、新たなファイルがアプリケーションによって生成されるときはいつでも、追加のメタ情報が格納されなければならないという状況を考えることにする。このメタ情報は例えば、ファイルのポリシ又は分類を符号化するために使用することができ、ファイルの冒頭に格納される。ファイルの残りの部分は通常のファイルコンテンツを格納する。冒頭にある保護エリアと、ファイルコンテンツを格納する第２のエリアとからなるファイルは「コンテナファイル」と呼ばれる。

コンテナファイルは、他にも理由はあるが特に以下の２つの特性により意義を持つ。
１．ポリシで保護されたファイルの取り扱いは可能な限り簡単であるべきである。管理情報が２つ以上の異なるファイルに分割される状況は避けることが望ましい。それゆえ、ポリシを１つのファイルに格納し、ファイルコンテンツを別のファイルに格納することは、単一のファイルのみの場合と比べて不便である。したがって、最も簡単な方法は単一のファイルを扱うことである。
２．ポリシとファイルコンテンツが分離されていると、ポリシが交換できないようにするために、ポリシとファイルコンテンツとを何らかの方法で関連付ける必要がある。ポリシとファイルコンテンツとを同じファイルに書き込むだけでは問題は全く解決しないが、異なる２つのファイルとするよりも扱いがより簡単になる。

管理データ（managed data）とは何か、及び管理データはどのように取り扱われるかという疑問に対しては、次のように答えることができる。管理データはコンテナファイルの抽象概念と見なすことができる。この特別なファイルは、図７と図８に示すように、異なる２つのエリア、すなわちヘッダとファイルコンテンツとからなる。

図７は、ヘッダが可変長の場合のコンテナファイルを示している。プレフィックスフリーコード（prefix free code）の後に、タイプ定義が続き、その後にヘッダ長の定義と、ファイルの利用制御ポリシ又は分類を定義する実ヘッダコンテンツが続く。続いて、実ファイルコンテンツ又はオリジナルファイルコンテンツが続く。

コンテナファイルのよりシンプルな例を図８に示す。

本実施形態では、ヘッダは５つの異なるフィールドに分割されている。最初のフィールドは、ヘッダをファイルコンテンツと区別するために用いられるマジックナンバーである。別の考えとしては、４つのメタデータフィールドにわたってチェックサムを計算し、そのチェックサムをマジックナンバーとして最初のフィールドに格納することである。しかし、パフォーマンスという観点と、ヘッダは後で暗号化されるという観点から、ヘッダを認識するには固定的なマジックナンバーで十分であると考えられる。

最後の４つのフィールドはメタデータ（metadata）を格納する。実施の一形態によれば、各フィールドは整数値を格納する。これらのフィールドは、個別に又は一緒に、どのようにファイルアクセスを取り扱うべきか、例えば、どのアプリケーションがファイルへアクセスすることが許可されるか、暗号化又は復号化が実行されなければならないかなどを定めるポリシを定義することができる。ヘッダは、実ファイルコンテンツを暗号化又は復号化するために使用する１つ以上の鍵も含むことができる。

ヘッダの目的は具体的な実施形態に応じて定めることができ、ハンドラはメタデータに対して適切に応答するように何らかの適切な方法で実装されるべきである。

セキュリティの観点から、攻撃者は、例えばヘッダを上書きできるwrite()というシステムコールによって書き込めるデータを用意できる可能性を持つかどうかという疑問があるだろう。このような脆弱性が存在する場合、攻撃者はヘッダをその攻撃者自身のポリシで無効にする（override）可能性を持つことが考えられる。この攻撃は特別に用意されたwrite()というシステムコールによっては可能でないことを示すものである。

ファイルポインタは負のファイル位置を持つことができない。つまり、ファイルポインタは少なくともファイルの冒頭又はファイル内部を示すが、ファイルよりも前の位置は決して示さない。

アプリケーションのファイルポインタは、ファイル内のヘッダについては何も知らず、それゆえ、ファイルコンテンツはファイルの０という位置から始まるものと認識している。アプリケーションが、例えば何らかのデータをちょうどファイルの冒頭に書き込みたいと考えている場合には、アプリケーションはファイルポインタを位置０に移動させて、write()というシステムコールを呼び出す。データが実際に書き込まれる前に、ハンドラはこのシステムコールをインターセプトして、データの書き込みに先立って更にファイルポインタを移動させる。技術的に言えば、ハンドラは、最初にファイルポインタを「+sizeof(header)」のオフセットだけ移動させて、その後に書き込みを開始する。そうすることで、本発明の実施形態のフレームワークにおけるハンドラが元のバーションのまま変更されない限り、攻撃者はヘッダに上書きすることはできない。

先の説明は、既存のヘッダを上書きできないこと示しているが、残念ながら、これは攻撃者がヘッダを別のヘッダに置き換える唯一の方法ではない。データハンドラがコンテナファイルを実装するという想定の下では、マジックナンバーと任意のメタ情報で始まる新たなファイルを作成することは比較的容易であると考えられる。別のファイルのファイルコンテンツをこの新たに作成されたファイルに付加した後は、上記任意のメタ情報はこの付加されたファイルコンテンツに属する。このような攻撃を防止するために、実施の一形態によるデータハンドラは暗号化手段を利用してこのコンテナファイルのヘッダを保護する。そのためのデータハンドラは、暗号化、復号化の機構と、ヘッダを暗号化、復号化するために必要な鍵を含む。

［コンテナファイルのファイルコンテンツの読み出しと書き込み］
各コンテナファイルの冒頭にあるヘッダは、２つの追加操作のみを要求する。図９の具体例は、通常のファイルとコンテナファイルとの違いを示している。通常のファイルを使用する場合、ファイルポインタは絶対的位置ｘに置かれ、アプリケーションはｙ−ｘバイトを読み出すよう求められる。読み出しの最後に、ファイルポインタは絶対的位置ｙに置かれる。次に、コンテナファイルの場合を考える。読み出し操作の前は、ファイルポインタは通常のファイルと同じように位置ｘにある。これは可能な限りの透過性を保証するデザインである。データを読み出す前に、ファイルポインタは、「+sizeof(header)」のオフセットだけシフトされ、読み出しの完了後にこのサイズ分だけ元に戻される。この振る舞いにより、以下の可能性が生まれる。
１．アプリケーションが本発明の実施形態のフレームワークによって監視される限り、ファイルの冒頭に、通常の読み出し又は書き込みの操作によっては読み出しも書き込みもできない保護されたエリアが置かれる。
２．読み出し又は書き込みの操作の前は、アプリケーションが通常のファイルに作用しようがコンテナファイルに作用しようが関係なく、両ケースともファイルポインタの位置は同じである。

［ヘッダの設定］
実施の一形態によれば、ヘッダは読み出しと書き込みがなおも可能であることが保証される。実施の一形態においてフレームワークのハンドラは、ファイルポインタを移動させるので、このような特徴は比較的容易に実現できる。本実施形態は、open()というシステムコールの後にヘッダの有無を常にチェックする。ハンドラは、ファイルポインタをファイルの絶対的位置０に移動させてからsizeof(header)バイト分を読み出すことによって、このようなチェックを行うことができる。マジックナンバーが正しい場合には、ハンドラはヘッダが存在すると見なす。逆にマジックナンバーが正しくない場合には、ハンドラはユーザにメタデータを求め、位置０から書き込みを開始する。

［ヘッダの変更］
アプリケーションはコンテナファイルに作用することを知らないため、データハンドラはヘッダを変更する唯一の要素である。データハンドラは読み出し又は書き込みの操作の場合にファイルポインタを移動させる。それゆえ、実施の一形態によれば、データハンドラに、ヘッダを変更する別の関数が提供される。データハンドラはコンテナファイルの位置０にある先頭ヘッダについて知っているからである。

［ファイルをコンテナファイルとして定義する］
実施の一形態において、アプリケーションが新たなファイルを開くときはいつでも、このファイルはコンテナファイルとすべきか、あるいは通常のファイルとすべきかが定義される。この選択は、実施の一形態によれば、システムの別の部分がこの選択に対して回答することが想定できるため、事前に定められたコンテナファイル名のリストを提供することによって簡単に解決できる。コンテナファイル名のリストは、「filename ->{true, false}」というマッピングを定義する「struct fd_table_entry」という要素からなる。ファイルが開かれるときは常に、ハンドラはこのリストを用いて、ファイルがコンテナファイルか通常のファイルかを判断する。この判断に応じて、ハンドラはシステムコールを正しく処理する方法を認識する。

他の実施形態では、異なる識別機構を利用して、ファイルがコンテナファイルであるか否かを特定する。それに基づいて、ファイルの扱いが決定される。つまり、インターセプタを使用することによって、そのファイルは「通常の」ファイルとして扱われるべきか、「コンテナファイル」として扱われるべきかが決定される。実施の一形態によれば、ファイルの冒頭のマジックナンバーが使用されるか、ファイルの何らかの特別なフォーマットが使用されるか、あるいは、ファイルをコンテナファイルとして特定する任意の識別子が使用される。

［攻撃シナリオ］
以下、コンテナファイルと暗号化とを実装する現データハンドラに対するシンプルな攻撃シナリオが存在することを示す。攻撃は、アプリケーションがコンテナファイルのファイルコンテンツエリアに書き込むことができる限り、コンテナファイルのファイルコンテンツを交換し、よってファイルのポリシを置き換えることを可能とする。必要なタスクの流れは非常にシンプルである。
１．ファイルコンテンツ「ａ」とポリシ「Ａａ」を有するファイル「Ａ」を開く。
２．ファイルコンテンツ「ｂ」とポリシ「Ｂｂ」を有するファイル「Ｂ」を開く。
３．ファイルコンテンツ「ａ」を読み出す。
４．ファイルコンテンツ「ａ」をファイル「Ｂ」に書き込む。

このとき、ファイル「Ｂ」はファイルコンテンツ「ａ」を格納しているが、コンテナファイルのヘッダはポリシ「Ｂｂ」を含んでいる。それゆえ、攻撃者はファイルのポリシを容易に置き換えることができる。この問題に対する１つの可能な解決法は、いわゆる「終了フラグ（finalize flag）」と、ヘッダ内のチェックサムの利用である。このようなフラグが真（true）に設定されると、ヘッダ内のチェックサムがコンテナファイルのファイルコンテンツエリアに合致する場合にのみ、このファイルへの任意の読み出しアクセス権が与えられる。終了フラグが設定されている場合は、書き込みアクセス権は常に拒否される。終了フラグが設定されていない場合は、読み出しアクセス権と書き込みアクセス権は両方とも許可される。

上記の実施形態は、ハードウェア、ソフトウェア、あるいはハードウェアとソフトウェアの組み合わせによって実施することができることは当業者であれば理解できよう。本発明の実施形態に関連して説明されたモジュール及び機能は、全体的又は部分的に、本発明の実施形態に関連して説明した方法の通りに動作するように適切にプログラムされたマイクロプロセッサ又はコンピュータによって実現することができる。本発明の実施形態を実現する装置は例えば、本発明の実施形態で説明された機構を実行することが可能なように適切にプログラムされたコンピュータ又はネットワーク内のノードその他の構成要素を構成することができる。

本発明の実施の一形態として、データキャリアに格納された、あるいは何か他の方法で、記録媒体もしくは伝送リンクといった何らかの物理的手段によって具現化されたコンピュータプログラムであって、コンピュータ上で実行されたときにこのコンピュータが本発明の上記実施形態に従って動作することを可能にするコンピュータプログラムが提供される。

ＨＷ ハードディスク
ＯＳ オペレーティングシステム

Claims (15)

1. オペレーティングシステム上で動作するアプリケーションプログラムがファイルに対する操作を実行するコンピュータにより実行される方法であって、該ファイルは、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり、
   前記ファイルにアクセスするために前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと、
   インターセプトモジュールが前記システムコールをインターセプトするステップと、
   前記インターセプトモジュールが前記ヘッダに格納されたメタ情報を読み出すステップと、
   前記メタ情報に基づいて、前記ファイルに対して前記システムコールの実行が許可されるか拒否されるかを判断するステップと、
   前記システムコールが許可されると判断された場合には、アクセスされるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記システムコールが前記実ファイルコンテンツに対して実行されるようにするステップと
   を含む方法。
2. 前記メタ情報は、前記ファイルにアクセスする際に設定されるポリシについての情報を含むものであり、
   前記ポリシは、
   前記システムコールが変更されない方法で前記ファイルへアクセスすることが許される１つ以上の条件の定義と、
   前記システムコールが前記ファイルへアクセスすることが許されない１つ以上の条件の定義と、
   前記システムコールが変更された方法でのみ前記ファイルへアクセスされることが許される１つ以上の条件の定義と
   のうちの１つ以上を含むものである、請求項１に記載の方法。
3. 前記システムコールの実行は、変更された方法で実行されるものであり、
   変更された実行は前記実ファイルコンテンツの暗号化又は復号化を含むものである、請求項１又は２に記載の方法。
4. 前記システムコールの実行が許可されるか拒否されるかの前記判断は、前記メタ情報に加えて、前記システムコールの発行元であるアプリケーションプログラム又はアプリケーションプロセスのタイプに基づくものである、請求項１〜３のいずれか一項に記載の方法。
5. 前記ファイルは実ファイルコンテンツとして暗号化データを含むものであり、
   前記メタ情報は、前記暗号化データの復号化が許される１つ以上の条件を定義する利用制御ポリシを含むものである、請求項１〜４のいずれか一項に記載の方法。
6. 前記メタ情報は、前記暗号化データを復号化するための１つ以上の暗号鍵、又は、前記暗号化データを復号化するための１つ以上の暗号鍵を導くことのできる情報を含むものである、請求項１〜５のいずれか一項に記載の方法。
7. 前記メタ情報は暗号化された形で格納されるものである、請求項１〜６のいずれか一項に記載の方法。
8. 前記インターセプトモジュールは暗号化されたメタ情報を復号化するものである、請求項７に記載の方法。
9. 前記ファイルは、前記実ファイルコンテンツと、メタ情報を格納したヘッダとを含むファイルであると特定されるための情報を含むものである、請求項１〜８のいずれか一項に記載の方法。
10. オペレーティングシステム上で動作するアプリケーションプログラムがファイルを作成するための書き込み操作を実行するコンピュータにより実行される方法であって、前記ファイルは、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり、
    データを記憶媒体に書き込むことによりファイルを作成するために、前記アプリケーションプログラムが前記オペレーティングシステムのシステムコールを呼び出すステップと、
    インターセプトモジュールが前記システムコールをインターセプトするステップと、
    前記インターセプトモジュールが前記ヘッダのメタ情報を前記記憶媒体に書き込むことにより、その後、当該ファイルに対してシステムコールがあった場合に、前記インターセプトモジュールが、前記メタ情報に基づき当該ファイルに対して該システムコールの実行が許可されるか拒否されるかを判断できるようにするステップと、
    書き込まれるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記実ファイルコンテンツの書き込み操作が前記ファイル内の前記ヘッダの後で行われるようにするステップと
    を含む方法。
11. 請求項２〜９のいずれか一項に記載の特徴の１つ以上を更に含む請求項１０に記載の方法。
12. オペレーティングシステム上で動作するアプリケーションプログラムがファイルに対する操作を実行するための装置であって、該ファイルはメタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり、
    前記ファイルへアクセスしようとするアプリケーションプログラムから前記オペレーティングシステムのシステムコールを受信するモジュールと、
    前記システムコールをインターセプトするインターセプトモジュールと、
    前記インターセプトモジュールが前記ヘッダ内のメタ情報を読み出すためのモジュールと、
    前記メタ情報に基づいて、前記ファイルに対する前記システムコールの実行が許可されるか拒否されるかを判断するとともに、その判断の結果、前記システムコールが許可される場合には、アクセスされるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記システムコールが前記実ファイルコンテンツに対して実行されるようにするモジュールと
    を備えている装置。
13. オペレーティングシステム上で動作するアプリケーションがファイルを作成するための書き込み操作を実行するための装置であって、該ファイルは、メタ情報が格納されたヘッダと実ファイルコンテンツとを含むものであり、
    データを記憶媒体に書き込むことによって前記ファイルを作成しようとする前記アプリケーションプログラムから前記オペレーティングシステムのシステムコールを受信するモジュールと、
    前記システムコールをインターセプトするインターセプトモジュールと、
    前記インターセプトモジュールが前記ヘッダのメタ情報を前記記憶媒体に書き込むことにより、その後、前記ファイルに対してシステムコールがあった場合に、前記インターセプトモジュールが、前記メタ情報に基づき前記ファイルに対して前記システムコールの実行が許可されるのか拒否されるのかを判断することができるようにするとともに、書き込まれるファイルのファイルポインタを前記ヘッダに相当する量だけ移動させて、前記実ファイルコンテンツの書き込み操作が前記ファイル内の前記ヘッダの後で実行されるようにするためのモジュールと
    を備えている装置。
14. 請求項２〜９のいずれか一項に記載の操作を実行するモジュールを更に備えている請求項１２又は１３に記載の装置。
15. 請求項１〜１１のいずれか一項に記載の方法をコンピュータに実行させるコンピュータプログラムコードを含むコンピュータプログラム。