JP2008541248A - コンテンツ暗号化ファイアウォールシステム - Google Patents

Abstract

コンピューティングステーションとストレージまたはコンテンツとの間の様々な操作を管理するシステムおよび方法。規則の集合を備えるポリシによって、ストレージまたはホスティングコンテンツコンテナとコンピューティングステーションとの間でのコンテンツ（データ）の交換またはアクセスを伴うかまたはそれをもたらし得る任意の操作の管理が可能である。規則は、ストレージの種類、コンテンツの種類、コンテンツの属性、およびストレージ装置および／またはコンテンツに関連する他の属性を含む個々の基準によって定義してもよい。ポリシは個々のユーザに対してコンピューティングステーション上で動的にインストール／更新され、ポリシの評価に基づいてコンピューティングステーションとストレージまたはコンテンツとの間で行われ得るデータ操作を管理する。ポリシの評価に基づいて、要求された操作は、許可、ある領域に制限、または拒否される。

Description

本発明は、一般にデータ通信の分野に関し、特に、暗号化による安全な方式により、一般化されたポリシによる管理の元でストレージとコンピューティングステーションとの間のデータ通信を管理する方法に関する。

従来、組織内では、ユーザに関連するデータは、ユーザコンピュータに関連するハードディスクまたはサーバに関連するハードディスク上に格納されていた。個人がディスクドライブ上に格納されたデータへのアクセスを希望する場合、まずコンピュータにログオンすることを要求された。一旦ログインし適当なディスクドライブへのアクセスが許可されると、ユーザはコンテンツにアクセスすることができた。

現在のコンピューティング環境では、組織間および組織内のユーザ間で転送および交換されるデータの量は常に増大している。その結果、従来のディスクドライブは、データ格納のための新しい方法論によって増強されつつある。データの可搬性に対する要望は、モバイルストレージ装置の開発につながった。こうしたモバイルストレージ装置の例には、ＵＳＢストレージ装置、外部ハードドライブ、ＣＤ、およびＤＶＤが含まれる。こうしたモバイルストレージ装置によって、様々なユーザとコンピューティングステーションとの間の情報が容易に流れるようになる。

ストレージの使用に関連する固有のリスクが存在する。本書で使用される場合、ストレージという用語は、電子的にアクセス可能なデータコンテンツを備えた物理または論理エンティティを指す。本書で使用される場合、コンテンツという用語は、電子的にアクセス、格納、または伝送が可能な、データを収容するアプリケーション固有の論理データ構造を備えた論理エンティティ（例えば、ワープロファイル、スプレッドシートファイル、またはデータベースファイル等の電子アプリケーションファイル）やその構造を記述する関連メタデータを指す。ポリシという用語は、本書で使用される場合、コンピューティングステーションやストレージへのアクセス、ならびにコンピューティングステーションとストレージとの間のデータ通信を制御する規則の集合を指す。組織内では、組織が所有権を有するコンテンツは、許可されない個人／エンティティによるアクセスから保護しなければならない。

コンテンツ、またはデータの横領の潜在的脅威に対処するため、組織によっては、ある種のストレージ装置の使用を禁止したところもある。この場合、セキュリティ上のリスクはある程度抑制される。一方、モバイルストレージ装置はデータの転送および格納を容易にする非常に効率的なツールだが、作業効率と生産性が犠牲になっている。組織によっては、モバイルストレージ装置の使用を完全に禁止するのが有効または効率的とは限らないという認識から、各組織のセキュリティプロトコルに応じてモバイルストレージ装置の制限付き使用を許可するポリシを導入したところもある。しかし、こうしたポリシに関しては、ポリシを自動的に施行する有効な制御機構が欠けている。従って、モバイルストレージ手段が関与するデータ転送に関する１つまたは複数のポリシへの準拠は、エンドユーザに委ねられることが多い。自動施行機構を有しないポリシは、モバイルストレージ装置の使用を通じてもたらされる、１）機密情報を収容したモバイルストレージ装置が盗難または紛失にあった場合、２）モバイルストレージ装置から許可されていないコンピューティング装置への機密データのコピー、および３）コンピューティング装置からモバイルストレージ装置への機密データのコピー、といった種類の脅威には対処できない。

コンピューティングステーションとストレージすなわちコンテンツとの間の様々な操作を管理するシステムおよび方法。コンピューティングステーションは、パーソナルデスクトップコンピュータ、ワークステーションコンピュータ、サーバコンピュータ、ラップトップコンピュータ、またはモバイルハンドヘルドコンピュータでもよい。ストレージとは、電子的にアクセス可能なコンテンツすなわちデータを備えた物理または論理エンティティである。物理ストレージはコンピューティングステーションの内部にあってもよく、また外部にあって、外部インタフェースを介してコンピューティングステーションと接続されるものでもよい。物理ストレージの例には、ＵＳＢフラッシュドライブ、ＣＤ、ＤＶＤ、ＺＩＰ（登録商標）ディスク、ハードドライブ、ネットワークドライブ、フロッピ（登録商標）ディスク、ＰＣＭＣＩＡドライブが含まれる。論理ストレージの例は、ファイルである。コンテンツとは、データを収容するアプリケーション固有の論理データ構造を備えた論理エンティティや関連メタデータである。コンテンツの例には、ＸＭＬファイル、ＨＴＭＬファイル、画像ファイル、ワープロファイル、スプレッドシートファイル、データベースファイルおよびそれらに含まれるコンテンツ／データのサブセットが含まれる。

ストレージとコンピューティングステーションとの間のコンテンツ（データ）の交換またはアクセスを伴うかまたはそれをもたらし得る操作の管理が可能である。操作には、コンテンツの読み取り、コンテンツの書き込み、コンテンツのコピー、コンテンツの削除、ファイルの実行、コンピューティングステーションにとってアクセスが可能になるストレージのマウント、および特定のインタフェースを介したコンテンツの伝送の許可が含まれる場合があるが、それらに制限されない。

コンピューティングステーションとストレージとの間で行われ得る操作を管理するため、管理者アプリケーションおよびクライアントアプリケーションを使用する。管理者アプリケーションは、アクセスが信頼できるユーザに制限されるように、サーバのような、信頼できるコンピューティングステーションにインストールする。クライアントアプリケーションは、コンピューティングステーションによるストレージとの対話が管理できるように、ラップトップのようなコンピューティングステーションにインストールする。

クライアントアプリケーションは、コンピューティングステーションとストレージとの間で許可される操作に基づいて、各コンピューティングステーションに対してカスタマイズされる。クライアントアプリケーションは、定義される様々なポリシによってカスタマイズされる。定義されるポリシによって、コンピューティングステーションとストレージとの間で行われ得る操作を支配および管理する規則の集合が提供される。ポリシは、管理者アプリケーションを使用する管理者または他の信頼できる個人／エンティティによって決定される。

ポリシは様々な規則に応じて定義してよい。さらに詳しく言うと、規則は、ストレージの種類、インタフェース、コンテンツの種類、メタデータ情報、操作、および様々な認証識別子に応じて指定してよい。

ストレージとは、そこにデータを格納できる任意の構成要素でよい。ストレージは内部でコンピューティングステーションに接続してもよく、外部でインタフェースによって接続されるようになっていてもよい。ストレージは必ずしも１つの物理装置である必要はなく、１つまたは複数のストレージ装置から構成されてもよい。

インタフェースとは、コンピューティングステーションとストレージとの間を接続する構成要素である。こうしたインタフェースの例には、ＰＣＩ、ＵＳＢ、ＳＣＳＩといったデータバス、およびイーサネット（登録商標）およびファイバチャネルといったネットワークインタフェースが含まれる場合がある。

コンテンツの種類とは、ストレージに収容されるコンテンツ（データ）のフォーマットである。異なる種類のコンテンツが存在し得るので、例えば、コンテンツが画像アプリケーションまたは文書処理アプリケーションのどちらに関連するかに基づく規則といった、特定のコンテンツの種類に関連する規則を定義することが可能であってもよい。

メタデータ情報とはコンテンツに関する情報である。例えば、メタデータ情報は、コンテンツに関連する属性でもよく、ファイルの作成日、ファイル名、ファイルの所有者、およびファイルに関連し得るアクセス許可が含まれることがある。

認証識別子は、ユーザ、エンティティまたはコンテンツ自体に関連する識別子を含んでもよい。例えば、ユーザ識別子によって、個々のユーザについてのコンピューティングステーションとストレージとの間のデータ操作を管理する規則を定義することができる。また、認証識別子は、セキュリティドメイン及びセキュリティサブドメインを含んでもよい。これによって、割り当てられるセキュリティドメインおよびセキュリティサブドメインに応じてコンピューティングステーションとストレージとの間で行われ得る操作を管理できるような、コンピューティングステーション及びストレージが割り当てられるドメインの定義を可能にするものである。

クライアントアプリケーションは、定義された、個々のコンピューティングステーションに関連する規則を施行する。クライアントアプリケーションは、コンピューティングステーションに接続される全てのインタフェースを監視し、定義された規則に基づいて、ストレージから、またはストレージへなされたどの要求を許可すべきかを決定する。

また、管理者アプリケーションは、ストレージをプロビジョニングするために使用される。ストレージのプロビジョニングとは、ストレージに暗号化された情報を書き込むようにする処理を指す。この処理によって、プロビジョニング済のストレージとインタフェースを取ろうとする試みが行われた時、コンピューティングステーションのクライアントアプリケーションが、定義済の規則に基づいてストレージとコンピューティングステーションとの間のどの操作（もしあれば）を許可すべきかを決定することができるようになる。

本出願で説明されるシステムおよび方法の実施形態をよりよく理解し、それらをいかに実現するかをより明瞭に示すため、例として添付の図面を参照する。

本発明のコンテンツ暗号化ファイアウォールシステム（ＣＣＦＳ）１０を図示する図１を参照する。ＣＣＦＳ１０は、管理者アプリケーション１４がインストールされているか、または管理者アプリケーション１４からアクセス可能な１つまたは複数の管理者ステーション１２と、クライアントアプリケーション１８がインストールされたコンピューティングステーション１６とから構成されている。管理者ステーション１２は、ネットワークを介してコンピューティングステーション１６に接続してもよい。管理者ステーション１２およびコンピューティングステーション１６はストレージ２０に接続してもよい。ストレージ２０はコンテンツ２２を収容し、インタフェース２４によって管理者ステーション１２および／またはコンピューティングステーション１６に接続される。

管理者ステーション１２は、サーバ型コンピュータのようなコンピュータであり、そのアクセスは、ネットワーク管理者のようなネットワーク内の信頼できる個人に制限されている。管理者ステーション１２には、管理者アプリケーション１４がインストールされており、これについては以下でより詳細に説明する。

コンピューティングステーション１６は、パーソナルデスクトップコンピュータ、ワークステーションコンピュータ、サーバコンピュータ、ラップトップコンピュータ、またはモバイル／ハンドヘルドコンピュータといった任意の種類のコンピューティング装置でよい。コンピューティングステーション１６には、クライアントアプリケーション１８がインストールされており、これについては以下でより詳細に説明する。

管理者ステーション１２およびコンピューティングステーション１６は、ストレージ２０に関連づけられてもよい。ストレージ２０は、コンテンツ２２を収容してもよい。ストレージ２０の例には、磁気ハードディスク、フラッシュディスク、フロッピディスク、ＣＤ、ＤＶＤ、ＺＩＰディスク、ｉＰｏｄｓ（登録商標）、外部ファイヤワイヤ（登録商標）ドライブ、外部ＵＳＢドライブ、ＰＣＭＣＩＡフラッシュドライブ、ネットワークドライブおよびファイルが含まれるが、それらに制限されない。ストレージ２０は、コンピューティングステーション１６の内部または外部にあるものでよい。ストレージ２０上に格納されるコンテンツ２２は、異なるフォーマットでもよい。ストレージ２０上に格納された個々のファイルに関連するコンテンツ２２は、ファイルのフォーマットを示すファイル名を有する。例えば、コンテンツは、画像、テキスト文書、マルチメディアファイル、等に関連づけてもよい。

コンテンツまたはデータは、関連するメタデータを有する。メタデータは、コンテンツ２２を記述する情報である。メタデータは、ファイル名、ファイルの作成日、ファイルの作成者、およびファイルに課され得る何らかのアクセス制限に関する情報といった情報を含んでもよい。メタデータの存在は、ファイルを作成するために使用された個々のアプリケーションまたは操作に依存する。ソフトウェアアプリケーションの中には、作成したファイルに関連するメタデータを有しないものもあることに注意されたい。

ストレージ２０は、インタフェース２４によって管理者ステーション１２またはコンピューティングステーション１４に接続してもよい。インタフェース２４には、ＰＣＩ、ＵＳＢ、ファイヤワイヤ（ＩＥＥＥ１３９４）、ＡＴＡ（ＩＤＥ）、ＳＡＴＡ、ＳＣＳＩ、イーサネット、またはファイバチャネルが含まれる場合があるが、それらに制限されない。

管理者アプリケーション１４の構成要素を例示の実施形態で図示する図２を参照する。管理者アプリケーション１４は、セキュリティドメインモジュール３０、ポリシ定義モジュール３２、およびプロビジョニングモジュール３４を収容する。セキュリティドメインモジュール３０は様々なドメインの定義を可能にするが、その際管理者ステーション１２、コンピューティングステーション１６、ストレージ２０またはコンテンツ２２、およびネットワークのユーザは、１つまたは複数のドメインに関連する場合がある。ドメインを図３に例示し、以下でさらに詳細に説明する。ポリシ定義モジュール３２は、コンピューティングステーション１６とストレージ２０またはコンテンツ２２との間の対話を支配するポリシの、管理者または他の信頼できる個人／エンティティによる定義を可能にする。定義されたポリシによって、コンピューティングステーション１６とストレージ２０との間で行われ得る様々な種類の対話が決定される。ポリシを定義し、その後ポリシを施行する方法を以下で詳細に説明する。ポリシは、マウント操作、コピー操作、削除操作、安全な削除操作、読み取り操作、書き込み操作、伝送操作、および実行操作を含むが、それらに制限されない様々な種類の対話を管理する。マウント操作は、ストレージ２０またはコンテンツ２２をコンピューティングステーション１６がアクセスできるようにする。コピー操作は、通常はファイルである、コンテンツ（データ）の一定のブロックの、ストレージ２０からのコピーに関わる。削除操作は、コンテンツまたはデータをストレージ２０またはコンテンツ２２から除去する処理である。コンテンツまたはデータの削除は、一般に、削除するコンテンツが格納されているストレージの特定のブロックを割り当てられていないストレージとして指定することによって、その後ストレージのその特定のブロックに上書きできるようにすることに関わる。安全な削除操作は、この削除操作とは対照的に、ストレージ２０のブロックに上書きを実行する。読み取り操作は、ストレージ２０からのコンテンツの取り出しに関わる。書き込み操作は、ストレージ２０へのコンテンツまたはデータの記録に関わる。伝送操作は、ストレージ２０またはコンテンツ２２から、特定のインタフェース２４を介して、インタフェース２４に接続された装置にデータを送ることに関わる。実行操作は、実行可能な命令形式（例えば、．ｅｘｅファイル）でストレージ装置上に格納されたコンテンツを読み取ることに関わる。

ポリシモジュール３２は、コンピューティングステーション１６とストレージ２０またはコンテンツ２２との間の対話を支配する規則を指定するために使用される。規則は、クライアントアプリケーション１８によってコンピューティングステーション上にインストールされる。ポリシは、制御基準と呼ばれるものに基づく、規則の集合として定義される。制御基準は、コンピューティングステーション１６とストレージ２０またはコンテンツ２２との間で許可される対話の厳密な性質を指定するために使用される。制御基準は、ストレージ２０の種類、インタフェースの種類、コンテンツの種類、コンテンツに関連する属性（メタデータ）、認証識別子、および上記で論じた操作を含む。認証識別子は、一般にポリシを定義するために使用され得る識別子を指すために使用され、セキュリティドメインおよびセキュリティサブドメイン、ならびにユーザ名を含む。

プロビジョニングモジュール３４は、ストレージ２０上にプロビジョニング済モジュールをインストールするために使用される。プロビジョニング済モジュール２６とそのコンテンツについては以下でさらに詳細に説明する。プロビジョニング済モジュール２６がストレージ２０またはコンテンツ２２上にインストールされると、ストレージ２０またはコンテンツ２２はプロビジョニング済と呼ばれる。プロビジョニング済モジュール２６がインストールされていないストレージ２０またはコンテンツ２２は、未プロビジョニングと呼ばれる。プロビジョニング済モジュール２６は暗号化データを備え、ストレージ２０またはコンテンツ２２に書き込まれるデータを暗号化する。プロビジョニング済モジュール２６は、コンピューティングステーション１６がコンピューティングステーション１６とストレージ２０またはコンテンツ２２との間で（もしあれば）どの操作が実行可能かを決定することを可能にする。

セキュリティドメインをさらに詳細に説明する図３を参照する。図３では、一般に組織に関連するコンピューティングステーション１６のグループを指す組織ネットワーク５０を例示する。セキュリティドメインのメンバであるコンピューティングステーション１６および管理者ステーション１２のいくつかは、コンピュータネットワークを介して接続するものでもよい。しかしながら、コンピューティングステーション１６または管理者ステーション１２は、必ずしもセキュリティドメインの一部であるコンピュータネットワークの一部である必要はない。図３では、組織５０内の全てのコンピューティングステーションが１つのセキュリティドメイン６０に属することが示されている。システム１０は、少なくとも１つのセキュリティドメイン６０の作成を必要とする。システム１０は、１つまたは複数のセキュリティサブドメインを有してもよい。図３では、セキュリティサブドメイン６２ａおよびセキュリティサブドメイン６２ｂという、２つのセキュリティサブドメインが存在することが示されている。セキュリティサブドメインは、一般に、ある部門に関連し得るかまたはコンピューティング装置間に何らかの他の論理関係が存在し得る全てのコンピューティング装置を含むように編成される。コンピューティング装置は、全てのコンピューティング装置１６上にインストールされるクライアントアプリケーション１８によって、セキュリティドメインおよびオプションのセキュリティサブドメインに関連付けられる。以下でさらに詳細に説明するクライアントアプリケーション１８は、暗号化およびデジタル署名によって暗号で保護されるようにコンピューティング装置１６上にインストールされる。クライアントアプリケーション１８は検出の有無にかかわらず改竄されない。その結果、管理者による指定がない限り、コンピューティングステーション１６に関連するセキュリティドメインおよびセキュリティサブドメインも変更されない。

クライアントアプリケーション１８の構成要素を例示の実施形態で図示する図４を参照する。クライアントアプリケーション１８は、ＣＣＦＳ１０の一部となる全てのコンピューティングステーション１６上にインストールされる。クライアントアプリケーションは、ポリシの作成を通じてコンピューティングステーション１６についてカスタマイズされるソフトウェアアプリケーションである。クライアントアプリケーションは、クライアントアプリケーションがインストールされたそれぞれのコンピューティング装置を、セキュリティドメインおよびオプションのセキュリティサブドメインに割り当てる役目を果たす。１つの実施形態では、クライアントアプリケーション１８は、ポリシモジュール７０、ファイアウォールモジュール７２、および監視モジュール７４を備える。ポリシモジュール７０は、個々のコンピューティングステーション１６に関連して指定された規則から構成される。規則を指定する方法を以下で詳細に説明する。ファイアウォールモジュール７２は、コンピューティングステーション１６とストレージ２０またはコンテンツ２２との間で行われ得る操作を制御する。ファイアウォールモジュール７２は、ポリシモジュール７０において定義され含まれる規則を施行する。規則は、あるストレージ２０またはコンテンツ２２によって、あるいはあるストレージ２０またはコンテンツ２２に対して実行される個々の操作に関する要求を許可または拒否する。ファイアウォールモジュール７２は、ストレージ２０またはコンテンツ２２がコンピューティングステーションとのインタフェースを取ろうとする試行を検出する監視モジュール７４からの情報を受け取る。監視モジュール７４によって、コンピューティング装置１６とストレージ２０またはコンテンツ２２との間でなされる要求の性質（すなわち、読み取り操作、書き込み操作、および上記で説明した他の操作、といった要求される操作の種類）が決定される。クライアントアプリケーション１８は、コンピューティングステーション１６上にインストールされると、以下でさらに詳細に説明するように暗号で保護される。したがって、アプリケーションのコンテンツ（特に、規則を収容するポリシモジュール７０）は変更されない。クライアントアプリケーション１８の各構成要素は、一旦それぞれのコンピューティングステーション１６上にインストールしてから、管理者が、クライアントアプリケーション１８の他の構成要素に影響を与えることなく交換または変更することができる。

ここで、セキュリティドメイン作成方法１００のステップを図示する図５を参照する。ドメイン作成方法１００は、管理者アプリケーション１４、さらに詳しく言うとセキュリティドメインモジュール３０の一部である。上記のように、管理者は、システム１０について少なくとも１つのセキュリティドメインを作成する必要がある。管理者アプリケーション１４は、セキュリティドメインの作成と、その後のセキュリティドメインおよびセキュリティサブドメインの管理を担当する。

セキュリティドメイン作成方法１００はステップ１０２で開始される。ここで、管理者に、新しいセキュリティドメインの作成、または新しいセキュリティサブドメインの作成（セキュリティドメインが存在する場合）というオプションが与えられる。ユーザが新しいセキュリティドメインの作成を選択すると、方法１００はステップ１０４に進む。ステップ１０４では、セキュリティドメインの名前がユーザによって指定され、セキュリティドメインモジュールはセキュリティドメイン秘密を生成する。セキュリティドメイン秘密は、暗号化のために使用されるグローバル一意識別子である。これは、ユーザが指定するセキュリティドメインの名前と無関係であり、管理者アプリケーション１４によって再生成されることはない。

ユーザが新しいセキュリティドメインを指定すると、方法１００はステップ１０６に進む。ステップ１０６では、ステップ１０４で指定されたセキュリティドメインに関連する新しいセキュリティサブドメインを指定するオプションが提供される。ステップ１０６はオプションのステップである。ステップ１０６では、１つのセキュリティドメインについて１つまたは複数のセキュリティサブドメインを定義してよい。ユーザが定義する各セキュリティサブドメインに関して、セキュリティドメインモジュールは、全体で一意の識別子であり、生成される他のいかなるセキュリティドメイン秘密またはセキュリティサブドメイン秘密とも異なるセキュリティサブドメイン秘密を生成する。

ユーザが、ステップ１０４でセキュリティドメインを指定し、ステップ１０６で作成すするセキュリティサブドメインをオプションで指定すると、セキュリティドメインの名前および秘密、ならびにセキュリティサブドメインの名前および秘密は、暗号化されて管理者ステーション１２上に格納される。

ステップ１０２において、ユーザが、既存のセキュリティドメインについてのセキュリティサブドメインの定義を選択した場合、方法１００はステップ１０８に進む。ステップ１０８では、ユーザは、新しいセキュリティサブドメインを定義する対象となるセキュリティドメインを指定する。ステップ１０８では、ユーザは、既に作成済のセキュリティドメインを提示され、セキュリティドメインの１つを選択する。

ステップ１０８でユーザがセキュリティドメインを選択すると、方法１００はステップ１１０に進む。ステップ１１０では、ユーザは作成を希望する新しいセキュリティサブドメインを指定する。ユーザが新しいセキュリティサブドメインを作成すると、作成されたセキュリティサブドメインの名前および秘密は、管理者ステーション１２上に安全に格納される。

管理者は、方法１００をいつ呼び出してもよく、従って、セキュリティドメインおよびセキュリティサブドメインはいつ作成してもよい。ポリシは、管理者アプリケーション１４へのアクセス権を有する管理者または他の信頼できるユーザが指定する。システム１０の中で、１つまたはそれ以上のポリシを定義してよい。ポリシとは、それぞれのポリシに関連したコンピューティングステーション１６と、ストレージ２０またはコンテンツ２２との間の対話を支配する規則の集合を指す。ポリシは、クライアントアプリケーション１８の一部、さらに詳しく言うと、ポリシモジュール７０の一部としてコンピューティングステーション１６上にインストールされる。

管理者アプリケーション１４は、管理者または他の信頼できる個人による規則の集合の定義を可能にするポリシ定義モジュール３２を収容する。規則の集合によって、コンピューティング装置１６とストレージ２０またはコンテンツ２２との間の対話が支配される。

規則指定方法１５０のステップを例示の実施形態で図示する図６を参照する。規則指定方法１５０は、管理者ステーション上で管理者または他の信頼できる個人によって実行される。規則指定方法１５０の結果、規則の集合からなるポリシが定義される。このポリシはその後、クライアントアプリケーション１８に、さらに詳しく言うと、ポリシモジュール７０の一部として含めてよい。ポリシおよび規則の指定方法は、以前作成したポリシおよび規則を編集するために使用してもよい。

規則指定方法１５０はステップ１５２で開始され、そこでは管理者が、作成する規則の名前を指定する。

そして、方法１５０はステップ１５４に進み、そこでは制御基準が指定される。制御基準は、前に説明したように、ストレージの種類、コンテンツの種類、インタフェース、およびメタデータに関する情報、認証識別子、（ａｎｄ（論理積）、ｏｒ（論理和）、ｎｏｔ（否定）、および他の論理識別子といった）演算子を含んでもよいが、それらに制限されない。

そして、方法１５０はステップ１５６に進み、そこでは論理演算子が選択される。これは、ａｎｄ（論理積）、ｏｒ（論理和）、ｎｏｔ（否定）、ｎｏｒ（否定和）、ｅｘｃｌｕｓｉｖｅ ｏｒ（排他的論理和）、ｉｓ（ｅｑｕａｌ）〜（〜である（〜と等しい））、ｉｓ ｎｏｔ〜（〜でない）、ｌｅｓｓ ｔｈａｎ〜（〜より小さい）、ｇｒｅａｔｅｒ ｔｈａｎ〜（〜より大きい）、ｉｓ ａ ｍｅｍｂｅｒ ｏｆ〜（〜のメンバである）、ｉｓ ｎｏｔ ａ ｍｅｍｂｅｒ ｏｆ〜（〜のメンバでない）、などでもよいが、それらに制限されない。ステップ１５４で指定された制御基準とステップ１５６で指定された論理演算子とを結合し、ブール代数の標準規則に従って真または偽の評価が可能な論理式を作成する。論理式の例は、“Ｓｔｏｒａｇｅ ｉｓ Ｐｒｏｖｉｓｉｏｎｅｄ（ストレージはプロビジョニング済である）”である。ここで、Ｓｔｏｒａｇｅは制御基準であり、Ｐｒｏｖｉｓｉｏｎｅｄはストレージのあり得る属性であり、論理演算子は“ｉｓ”である。この式の真または偽を評価する。

次に、方法１５０はステップ１５８に進み、そこで、追加の制御基準を指定する場合、方法１５０はステップ１５４に戻る。追加の基準を選択しない場合、方法１５０はステップ１６０に進む。ステップ１６０では、管理者は、規則で指定された全ての論理演算が真である場合になされる動作を指定する。可能な動作として、許可、読み取り専用許可、拒否、暗号化、通知を含んでもよいがそれらに制限されない。この許可動作によって、規則で指定された制御基準によって識別されたストレージ２０またはコンテンツ２２への全てのアクセスを許可する。読み取り専用許可動作は、読み取り操作を許可するが、書き込みのような他の操作はブロックする。拒否動作は、全ての操作をブロックする。暗号化動作は、書き込みデータを暗号化することおよび読み取りデータを解読することを指定する。通知動作は、指定された制御基準が真である場合、情報メッセージを送ることを指定する。通知動作は、メッセージテキストおよびメッセージの配布先で修飾してもよい。可能な配布先は、ログファイル、電子メールアドレスまたは電話番号でもよい。

ステップ１６０が完了したとき、規則は定義されている。ＵＳＢストレージが未プロビジョニングの場合そのストレージへのアクセスをブロックする規則の例は、“Ｉｆ （Ｓｔｏｒａｇｅ Ｉｓ ＵＳＢ） Ａｎｄ （Ｐｒｏｖｉｓｉｏｎｅｄ Ｉｓ Ｆａｌｓｅ） Ｔｈｅｎ Ｄｅｎｙ（もし（ストレージはＵＳＢである）かつ（プロビジョニング済は偽である）ならば拒否する）”である。メタデータのカテゴリが汎用とマークされている場合、プロビジョニング済または未プロビジョニングの何れのストレージからもワープロ文書ファイルの読み取りを許可する規則の例は、“Ｉｆ （Ｏｐｅｒａｔｉｏｎ Ｉｓ Ｒｅａｄ） Ａｎｄ （ＣｏｎｔｅｎｔＴｙｐｅ Ｉｓ ＷｏｒｄＤｏｃ） Ａｎｄ （ＭｅｔａｄａｔａＣａｔｅｇｏｒｙ Ｉｓ “Ｇｅｎｅｒａｌ”） Ｔｈｅｎ Ｐｅｒｍｉｔ（もし（操作は読み取りである）かつ（コンテンツの種類はワープロ文書である）かつ（メタデータカテゴリは「汎用」である）ならば許可する）”である。あるプログラムがアプリケーションの許可リストにない場合その実行をブロックする規則の例は、“Ｉｆ （Ｏｐｅｒａｔｉｏｎ Ｉｓ Ｅｘｅｃｕｔｅ） Ａｎｄ （ＣｏｎｔｅｎｔＴｙｐｅ Ｉｓ Ｎｏｔ ａ Ｍｅｍｂｅｒ ｏｆ ＡｐｐｌｉｃａｔｉｏｎＬｉｓｔ） Ｔｈｅｎ Ｄｅｎｙ（もし（操作は実行である）かつ（コンテンツ種類はアプリケーションリストのメンバではない）ならば拒否する）”である。

ポリシを構成すべく定義済規則のリストを指定することによってそのポリシを作成してもよい。そして、クライアントアプリケーション１８を備えたシステム１０の一部となるコンピューティングステーション１６上に、このポリシをインストールしてもよい。そして、ポリシモジュール７０を収容するクライアントアプリケーションを使用して、その特定のコンピューティングステーション１６またはそのコンピューティングステーションにログオンする特定のユーザに対して適当なポリシを施行する。管理者アプリケーション１４、および特に、ポリシ定義モジュール３２を使用してポリシを定義するので、管理者ステーション１２上でクライアントアプリケーション１８をカスタマイズする際に、定義されたポリシをクライアントアプリケーション１８のポリシモジュール７０に含めてもよい。クライアントアプリケーション１８はそれぞれのポリシと共に、ネットワークインストールまたは他の従来の手段によってインストールしてもよい。クライアントアプリケーション１８、および特にポリシモジュール７０は、コンピューティングステーション２０上にインストールされると、非対称型または対称型の暗号化手段を提供し、ポリシの許可されていない改竄または変更を検出する。

上記で説明したように、ストレージ２０またはコンテンツ２２は、プロビジョニング済または未プロビジョニングの何れかである場合がある。プロビジョニング済のストレージ２０またはコンテンツ２２には、プロビジョニング済モジュール２６が書き込まれる。図８で説明するプロビジョニング済モジュール２６は、クライアントアプリケーション１８が、個々のプロビジョニング済ストレージ２０またはコンテンツ２２と通信すべきか否か、かつ通信すべき場合、プロビジョニング済ストレージ２０またはコンテンツ２２とコンピューティングステーション１６との間でどんな操作が許可されるかを決定することを可能にする。

ここで、プロビジョニング方法３００のステップを１つの例示の実施形態で図示する図７を参照する。プロビジョニング済モジュール２６のコンテンツを詳細に説明した図８を参照することによって、プロビジョニング済モジュール２６をさらに説明する。プロビジョニング方法３００は、プロビジョニング済モジュール２６を通じてポリシ情報をストレージ２０またはコンテンツ２２上にインストールする処理である。プロビジョニング方法３００はステップ３０５で開始される。ここで、管理者が、ストレージ２０またはコンテンツ２２に対して、方法１５０で作成されたポリシ、セキュリティドメインおよびオプションのセキュリティサブドメインを指定する。

そして、方法３００はステップ３１０に進む。ステップ３１０では、図８に示す暗号鍵３６６のような暗号材料が生成され、その後ストレージ２０またはコンテンツ２２を保護するために使用される。

そして、方法３００はステップ３１５に進む。ここでは、暗号による保護がプロビジョニング済モジュール２６に適用される。暗号による保護は、暗号鍵３６６を暗号化し、プロビジョニング済モジュール２６に関連する署名を計算することを含む。

そして、方法３００はステップ３２０に進む。ここで、プロビジョニング済モジュール２６がストレージ２０またはコンテンツ２２に書き込まれる。

再び、プロビジョニング済モジュール２６がインストールされたストレージ２０またはコンテンツ２２を図示する図８を参照する。プロビジョニング済モジュール２６は、クライアントアプリケーション１８によるストレージ２０またはコンテンツ２２に対するアクセスの制御およびポリシの施行を可能にする。プロビジョニング済モジュール２６中に収容される情報は、プロビジョニング方法３００でなされた選択に基づいている。

１つの実施形態では、プロビジョニング済モジュール２６は一意識別子３５２を含み、これを使用してプロビジョニング済モジュール２６を識別する。プロビジョニング済モジュール２６はプロビジョニング情報３５５を含む。このプロビジョニング情報３５５は、セキュリティドメイン、セキュリティサブドメイン、ユーザ供給の識別子、有効期限情報、ならびに、暗号鍵３６６およびプロビジョニングモジュール２６自体を保護するために使用される追加の暗号材料を提供する。プロビジョニング方法３００の代替実施形態では、プロビジョニング済モジュール２６についての有効期限日を指定してもよい。有効期限日とは、その日以降ストレージ２０またはコンテンツ２２の内容がどのコンピューティングステーション１６からも読み取りできなくなる日付であり、こうした日付はプロビジョニング情報３５５の一部であってもよい。暗号鍵３６６はストレージ２０またはコンテンツ２２に書き込まれたデータを暗号化するために使用され、署名３６８はプロビジョニング済モジュール２６の完全性を検証するために使用される。１つの実施形態では、暗号鍵３６６は、ストレージ２０またはコンテンツ２２に最初に書き込まれる時に、ＰＫＣＳ＃５のような動的鍵生成手段を使用して生成された暗号鍵によって暗号化される。デフォルトのパスワードおよびセキュリティドメイン秘密は、以下で説明するように鍵導出関数への入力として使用される。鍵導出関数は、暗号鍵３６６の暗号化に使用される鍵を動的に生成する。プロビジョニング済のストレージ２０またはコンテンツ２２を使用して、システム１０の一部であるコンピューティングステーション１６とインタフェースを取る場合、ユーザは自分のパスワードを入力して指定されたデフォルトのパスワードを変更する必要がある。セキュリティドメイン秘密と共に入力されるパスワードは、デフォルトのパスワードについて指定されたのと同じ手段を使用して暗号鍵３６６を暗号化するために使用される。１つの実施形態では、署名フィールド３６８は、プロビジョニング済モジュール２６のコンテンツが変更されたか否かを決定するためにシステム１０が使用するＨＭＡＣ ＳＨＡ２５６署名を収容する。

ストレージ２０またはコンテンツ２２上に暗号鍵３６６を格納した結果、（それぞれのポリシおよびその規則が操作を許可する場合に）ストレージ２０またはコンテンツ２２に書き込まれるデータは、暗号鍵３６６によって暗号化される。その結果、ユーザがシステム１０の一部でないコンピューティングステーション１６を使用してプロビジョニング済のストレージ２０またはコンテンツ２２にアクセスしようとすると、コンピューティングステーション１６は暗号化されたデータにアクセスすることができず、しかるべき解読を行うことができない。

ここで、コンピューティングステーション１６の構成要素とストレージ２０またはコンテンツ２２との間の対話を１つの例示の実施形態で図示する構成図を示す図９を参照する。アプリケーション４００は、ストレージ２０またはコンテンツ２２からのデータを要求し得るコンピューティングステーション１６に常駐またはそれに接続する何らかのアプリケーションであってよい。こうしたアプリケーションの例を提示の目的で提供すると、例えば、ワープロアプリケーション、ウェブブラウザ、およびデータベースプログラムを含んでもよい。ファイルシステム４０５は、コンピューティングステーション１６上にインストールされるオペレーティングシステムの一部であり、アプリケーション４００からのデータに対する要求を受け取りそれに応答するために使用される。従来のシステムでは、ファイルシステム４０５は、特定のロケーションから取り出そうとするデータに対するアプリケーション４００からの要求を受け取った後、その要求をストレージ／コンテンツドライバ４１０に送るものであった。ストレージ／コンテンツドライバ４１０は、ストレージ２０またはコンテンツ２２からのデータを最初に受け取るオペレーティングシステムドライバである。ストレージ／コンテンツドライバ４１０は、例えば、いずれもストレージ／コンテンツドライバ４１０の一部になり得るボリュームクラスドライバ、ディスククラスドライバ、およびポートドライバといった複数のドライバから構成してもよい。システム１０では、クライアントアプリケーション１８、さらに詳しく言うと、監視モジュール７４は、ファイルシステム４０５とストレージ／コンテンツドライバ４１０との間の全ての要求を受け取る。監視モジュール７４は、なされている要求の性質をファイアウォールモジュール７２に送り、ファイアウォールモジュール７２は、ポリシモジュール７０で指定された規則に基づいて、その要求を許可すべきか否かを決定する。従って、クライアントアプリケーション１８は、ポリシモジュールの一部として含まれたポリシを施行し、ポリシがサポートする操作だけを許可する。

装置アクセス方法５００のステップを図示する図１０を参照する。装置アクセス方法５００はクライアントアプリケーション１８によって実行され、コンピューティングステーション１６がストレージ２０またはコンテンツ２２と対話してよいか否かを決定するために使用される。一例として、プロビジョニング済のストレージ２０またはコンテンツ２２へのアクセス試行に関して、装置アクセス方法５００が図示されている。

方法５００はステップ５０２で開始され、そこではクライアントアプリケーション１８がデータに対する要求を受け取る。方法５００は、１つの実施形態に関して一例として使用されているファイルシステム４０５から、データに対する要求を受け取ってもよい。

そして、方法５００はステップ５０４に進む。ここで、データの要求先となるストレージ２０またはコンテンツ２２、さらに詳しく言うと、プロビジョニング済モジュール２６が、クライアントアプリケーション１８の監視モジュール７４によって検出される。そして、方法５００はステップ５０６に進み、そこではポリシモジュール７０から、コンピューティングステーション１６上にインストールされたポリシを取り出す。

そして、方法５００はステップ５０８に進む。ここで、プロビジョニング済モジュール２６からプロビジョニング情報３５５が取り出される。そして、方法５００はステップ５０８に進む。ここで、プロビジョニング済モジュール２６からプロビジョニング情報３５５が取り出される。そして、方法５００はステップ５１２に進む。ここで、ステップ５０６で取り出されたセキュリティドメイン情報がステップ５０８で取り出されたセキュリティドメイン情報と比較される。それらが一致する場合、方法５００はステップ５２０に進む。それらが一致しない場合、方法５００はステップ５１６に進む。また、（セキュリティサブドメインが指定されている場合）セキュリティサブドメインが一致するか否かを検査するオプションのステップをステップ５１２で実行してもよい。ステップ５１６では、コンピューティングステーション１６とストレージ２０またはコンテンツ２２との間で実行される操作に対する要求が拒否され、その操作の実行を要求したアプリケーション４００は、操作が実行されない旨通知される。これによって、プロビジョニング済のストレージ２０またはコンテンツ２２にアクセスするためには、プロビジョニング済のストレージ２０またはコンテンツ２２がコンピューティングステーション１６と同じセキュリティドメインに関連していなければならなくなる。１つの実施形態では、ポリシモジュール７０はセキュリティドメイン秘密を収容し、プロビジョニング情報３５５はセキュリティドメイン秘密のハッシュ値（ＳＨＡ−２５６）を収容する。ポリシモジュール７０中のセキュリティドメイン秘密のハッシュ値を計算し、それをプロビジョニング情報３５５中のハッシュ値と比較することによって、ステップ５１２での照合がなされる。

そして、方法５００はステップ５２０に進む。ここで、要求された操作に関する制御基準情報が取り出される。要求に関する制御基準は、アクセスが要求されたデータに関連し得るメタデータおよび他のコンテンツ関連情報を提供する。

そして、方法５００はステップ５２４に進む。ここで、ステップ５２０のコンテンツ識別情報を使用して、５０６で取り出されたポリシを構成する規則が評価される。規則評価の詳細を図１１で説明する。規則が要求された操作の実行を許可しないことが決定されると、方法５００はステップ５１６に進み要求は拒否される。そうでない場合、方法５００はステップ５２６に進み、動作が許可される。

規則評価方法６００のステップを図示する図１１を参照する。方法６００はある特定のポリシに関連する全ての規則を評価するために使用される。

方法６００はステップ６０２で開始される。ここで、クライアントアプリケーション１８、さらに詳しく言うと、ポリシモジュール７０からポリシが取り出される。そして、方法６００はステップ６０４に進む。ここで、デフォルトとして、規則評価方法の結果が、要求された動作を拒否するように設定される。

そして、方法６００はステップ６０６に進む。ここで、ポリシに評価すべき別の規則がまだあるか否かを決定する検査が行われる。ステップ６０６で、評価すべき規則がないことが決定されると、方法６００はステップ６０８に進む。ステップ６０８では、規則評価方法の結果が拒否に設定されているか否かを決定する検査が実行される。結果が拒否に設定されている場合、方法６００はステップ６１０に進む。ここで、方法６００が終了し、要求された操作が拒否される。ステップ６０８で、結果が拒否に設定されていないことが検査によって示された場合、許可となるので、方法６００はステップ６１２に進み、そこでは要求された操作が許可される。

ステップ６０６で、評価すべき規則がまだあると決定された場合、方法６００はステップ６１４に進み、そこでは規則が評価される。規則が真と評価された場合、方法６００はステップ６１６に進み、そこでは、その規則に関連する動作が要求された操作を拒否するように設定されているか否かが決定される。動作が要求された操作を拒否するように設定されている場合、方法６００はステップ６１０に進む。ここで、要求された操作が拒否され、方法６００は終了する。

ステップ６１６で、動作が要求を拒否しないと決定された場合、方法６００はステップ６１８に進む。ここで、動作が許可されるか否かを決定する検査が実行される。動作が許可される場合、方法６００はステップ６２０に進み、そこで、結果が許可に設定される。ステップ６１８で、検査の結果動作が許可に設定されておらず、（かつ拒否に設定されていないことが以前に決定されている場合）、方法６００はステップ６２２に進み、そこで、動作が実行される。ステップ６２２で動作が実行されるのは、その動作が操作を許可または拒否する以外の、通知の要求に関するものであり得るからである。

ステップ６１８で実行された検査の結果とは無関係に、ステップ６２０および６２２の両方が完了すると、方法６００はステップ６０６に戻り、評価すべき他の規則がまだあるか否かを決定する。

これまで説明したデータの暗号化の際に使用される鍵は、鍵管理システムで利用される鍵導出階層を使用して導出される。以下ルート鍵と呼ばれる鍵はシステム１０に関連する。ルート鍵は、対称鍵または非対称鍵でよく、（例えば、プロビジョニング済モジュール２６の一部である暗号鍵３６６のような）暗号化の際に使用される鍵を導出するために、システム１０によって使用される。

以下の節では、「鍵管理」という表題の下で、鍵管理システムを説明する。
［鍵管理］

ＣＣＦＳは安全な鍵を使用して認証、完全性検査、暗号化／解読を実行するので、鍵管理はその寿命全体を通じてＣＣＦＳ全体のセキュリティに責任を負う非常に重要な構成要素である。

ＣＣＦＳ鍵管理プロトコルは、１）強力な暗号化、２）十分なスループット、３）鍵回復、４）ワンステップ電子データシュレッド、５）良好な鍵の予測不可能性、および６）ポリシ主導のデータアクセス、をサポートする。

ＣＣＦＳ鍵管理（ＫＭ）は、頂点にある１つのマスタ鍵（ＭＫ）とその下の従属鍵のツリーとによる階層的鍵モデルを使用する。レベルＮの各鍵は、レベルＮ−１のその親、並びにＮレベルのセキュリティオフィサおよび、場合によっては、他のＮレベルの秘密保持者によって生成された種メッセージに依存する（レベル０が最上位で、レベル１が次位、以下それに続く）。一方、そのＮ＋１レベルの子鍵を導出するには、レベルＮの鍵を使用しなければならない。ＭＫ以外の各鍵は正確に１つの親を有するが、それに関連する多くの子鍵を有し得る。関連とは、その親鍵を種メッセージに適用することによって、チケット（下記参照）および専用鍵導出関数（ＫＤＦ）が子鍵を導出できるということである。

ＭＫ以外の各鍵は、垂直および水平両方向に依存する（下記の式参照）。ＫＤＦとして、ＫＭＳはパスワードベース鍵導出関数−ＰＢＫＤＦ（例えば、ＰＫＣＳ＃５ ｖ２標準に記載のＰＢＫＤＦ２）を使用する。ＰＢＫＤＦは良好な鍵エントロピーを示す。ＫＭＳでは、ＰＢＫＤＦのための種として、Ｍ個のプライベートパスワードから種を生成し、それらのうち任意のＫ個を使用して種を再生できる（ＭおよびＫ（Ｋ≦Ｍ−１）の値は設定可能である）、シャミアの鍵分割スキームか、またはストレートパスワードかの何れかをサポートする。これは上記の特徴（６）に対処する。ＫＭＳプロトコルは、対称型の高度暗号標準−ＡＥＳを利用することによって（例えば、ＡＥＳ−２５６を使用することによって）、特徴（１）に対処する。ＡＥＳ暗号は非常に強力であると共に大きなスループットを可能にし、ソフトウェアのみによっても達成できる（上記の特徴１、２）。鍵は、ユーザログインおよびＰＢＫＤＦを使用したパスワードによってラップされた媒体上に格納される。これは鍵の配布を容易にする。

容易なワンステップ暗号シュレッドを促進するため、ＭＫ以外の各レベルの鍵は共有チケットを有する。チケットは、（各鍵に一意の）種と共にそのレベルの鍵を導出するために使用されるＳＨＡの半分のバイト数のメッセージである。何れかのレベルでチケットを破壊することによって、そのレベル（を含む）から下位の全ての鍵が事実上回復不能になる。

各レベルのチケットは、ＨＳＭに格納されユーザＩＤおよびパスワードによってアクセス可能となるか、またはローカルに格納され、例えば、ＰＫＣＳ＃５プロトコルを使用したラップが可能になる。Ｎ＋１レベルの鍵を回復しなければならない時はいつでも、秘密保持者はその秘密を供給しなければならず、関連するチケットを取得しなければならない。そのレベルのチケットを取得する処理は専用アプリケーションによって一度だけ可能になり、その後そのレベルの全ての鍵が作成／回復可能になる。

以下、鍵管理システムで利用される鍵導出関数の例を示す。
ＰｒＫ、ＰｕｂＫはＭＫＰのプライベート鍵および公開鍵である。
Ｐ１、Ｐ２、・・・は、ＭＫのための種（シャミアの技術用語における共有秘密）を生成する、パスワード保持者のパスワードである。
ＳＨＡＭＩＲ−シャミアの鍵分割手順。
ＳＨＡ−安全なハッシュ関数（例えば、３２バイトのフィンガープリントを生成するＳＨＡ２）。
ＰＢＫＤＦ−パスワード主導鍵導出関数。
ＡＥＳｎ−レベルＮのＡＥＳ鍵。
この場合、鍵導出処理は以下の通りである。
ＭＫ導出：
ＰＢＫＤＦ（ＰｒＫ（ＳＨＡ（ＳＨＡＭＩＲ（Ｐ１，Ｐ２，．．．，ＰＭ））））＝ＡＥＳ₀
そして、ＭＫフィンガープリント（ＭＫＦ）を以下のように計算する。
ＰｕｂＫ（ＳＨＡ（ＳＨＡＭＩＲ（Ｐ１，Ｐ２，．．．，ＰＭ）））＝ＭＫＦ
ＭＫＦは公知であり、これを使用してＭＫが正しく回復されたか否かを検証する。
ＭＫＦを検証するため、
１）ＨＳＭはＰｒＫを使用してＭＫＦを解読しＳＨＡ（ＳＨＡＭＩＲ（Ｐ１，Ｐ２，．．．））を得る。
２）ＳＨＡＭＩＲ関数を適用して種：ＳＨＡＭＩＲ（Ｐ１，Ｐ２，．．．）を得る。
３）種に対するＳＨＡを計算する。
４）３）の結果を１）と比較する。
どちらの式もＰ１，．．．，ＰＫである入力のみによってＨＳＭにおいて実現されなければならない。

レベルＮ＋１の鍵導出は以下の式を通じて達成される。
ＰＢＫＤＦ（ＡＥＳｎ（＜ＳＨＡの前半（種｜Ｔ）＞））＝ＡＥＳ_n+1

ここで、ＴはＮレベルのチケットであり、演算「｜」はバイトストリームの連結を意味する。

種は、鍵ＡＥＳ_n+1の元で保護されようとしているデータを担当するセキュリティオフィサによって選択された秘密、またはＮ＋１レベルの秘密保持者からの入力に対してＳＨＡＭＩＲ手順によって生成された共有秘密の何れかでもよい。鍵管理システムで選択できるようになっている。

各ルート鍵は鍵階層の始点であり、ルートから直接的または間接的に導出される鍵によって保護されるオブジェクトの集合であるセキュリティドメインを定義する。異なるドメインのオブジェクトは解読できないので、アクセスできない。ドメインは暗号境界を表すが、これは多くのセキュリティ規則に適合しなければならないため重要である。同じ暗号機構を適用することによって、任意の数のセキュリティサブドメインを作成することができる。例えば、いくつかのチケットが同じバイトサブセットを有する場合、それらは事実上同じサブドメインに入る。共有チケット情報を知られないようにすることによって、オブジェクトはアクセスされなくなる。従って、鍵によって暗号操作を実行する任意のアプリケーションは、ドメインおよびサブドメイン両方の制限に基づいてアクセスポリシを課すことができる。十分に長いチケットを適用することによって、任意の望ましいレベルを達成できる。ドメイン／サブドメイン制限を促進するため、鍵を生成するのと同時に、（例えば、大きな一意の整数の形態で）ドメイン／サブドメインＩＤを生成してもよい。

ＭＫ以外のＮレベルの鍵はどれも、ラップされた鍵と共に媒体上にローカルに格納されたポリシファイルを有しなければならない（鍵のラップについては鍵配布の節を参照）。鍵ポリシファイルはＸ．５０９ ｖ３証明書またはバイナリファイルとして符号化してもよい。

ポリシファイルは、ポリシ作成日、鍵の有効期限日、アクセスレベル（ＣＣＦＳ管理者、または外部ユーザの何れか）、暗号形態のセキュリティドメインＩＤまたはそのＳＨＡ、暗号形態のセキュリティサブドメインＩＤまたはそのＳＨＡ、確認スケジュール（ポリシを確認する時間間隔）、鍵に関連するユーザのログイン名（何人かのユーザを同じ鍵に関連させてもよいが、１人のユーザに関連するのは１つの鍵だけである）、鍵が関連するボリューム、管理者のログイン名、起動状態、鍵のハッシュ（ドライバのＩＤ）、署名（例えば、ＨＭＡＣ−ＳＨＡに基づく）、といったフィールドの一部または全部を収容する。

鍵ポリシファイルがバイナリファイルとして符号化されている場合、暗号化されていないフィールドの配置は以下のようでもよい。符号化はＡＳＮ．１アプローチを使用してもよい。各フィールドは１バイトのタグ、バイト長、およびバイト値、すなわち｛ｔａｇ，ｌｅｎｇｔｈ＿ｂｙｔｅ、ｖａｌｕｅ＿ｂｙｔｅｓ．．．｝を有する。

ポリシ全体は、例えば、ＰＫＣＳ＃５プロトコルを使用したラップ鍵によって暗号化される。ラップ鍵は専用のラップパスワードを使用して作成されるが、このラップパスワードはどこにも格納されず、鍵とポリシファイルとの両方が配布される都度適用される。ラップの前に、ポリシファイルはラップパスワードによって再署名される。

従って、ラップには、鍵を作成するために使用されたパスワードと、ラップパスワードとの両方のパスワードが必要である。このことはラップ処理に対する認証を提供する。しかし、鍵とポリシファイルとの両方をアンラップし、ポリシの署名を検査するために必要とされるのはラップパスワードだけである。

鍵回復は、ラップ鍵のパスワードを知らずに暗号鍵を復元する能力である。これはパスワードを紛失した際にデータの回復を可能にする非常に重要な機能である。しかし、鍵回復をエンドユーザが行うことはできないので、データに対する強力な暗号による保護が提供される。許可された秘密保持者だけが、専用アプリケーションの助けによって、ＭＫ以外の任意の鍵を回復することができる。

シャミアのしきい値スキームを適用したり鍵導出の式を適用したりすることによって種を復元するのに必要なレベルのチケットおよび十分な秘密保持者を有する場合にＭＫ以外の任意の鍵を回復することができる鍵回復機能が、鍵スキームおよびそれに関する専用アプリケーションに組み込まれる。このアプリケーションは、まず、秘密保持者の証明書または個人プロファイルファイルの何れかを検証することによって、秘密保持者の信用性を検証する。

鍵を消去したりまたは鍵を保持するＨＳＭをゼロ化したりすることによって、鍵は破壊される。また、いくつかの秘密を破壊すると、秘密保持者は、たとえチケットを取得してもその鍵を回復できなくなる。破壊される秘密の数はしきい値を越えなければならない。鍵を破壊すると、その鍵によって暗号化されたデータは使用不能になる。

電子シュレッドとは、その鍵によって暗号化された任意のデータを、事実上、無用な「電子ゴミ」にするような回復不能な鍵の破壊を指す。レベル全体を電子シュレッドするには、まずそのレベルのチケットを破壊した後、特定のノードの物理鍵と共に、シャミアの閾値スキームを無効にするのに十分な秘密を破壊しなければならない。大量の電子シュレッドを促進するためには、専用階層が必要である（次節参照）。

鍵管理および電子シュレッドを促進する鍵階層に関するいくつかの示唆が存在する。例えば、いくつかのデータをオフサイトでアーカイブしようとする場合、周知のノードからの部分木を表す鍵（単数または複数）によって暗号化しなければならない。そして、そのノードについての鍵を破壊することによって有効にデータがシュレッドされる。代替的には、アーカイブされたボリューム内のいくつかのデータが異なる寿命（異なる寿命範囲または有効期間）を有する場合、同じ有効期間のデータを独立した鍵（単数または複数）の部分木によって暗号化すべきである。鍵階層中の各ノードでは、有効期間が交互にならないように、データを暗号化するために使用される鍵の新しい部分木を開始すべきである。有効期限日を有しないデータを第１のレベルの鍵によって暗号化してもよい。一般に、鍵階層が深くなるほど、データの寿命は短くなる。

対称型暗号化は、入力データ長が、例えば８バイト（ＤＥＳ／ＤＥＳ３の場合）または１６／３２バイト（ＡＥＳ−１２８／２５６の場合）で割り切れることを必要とするので、データの長さが不適合な場合、暗号化の前に何らかの余分のデータを追加し、解読したデータを表示する前に余分のデータを取り除くようにしなければならない。この処理をパディングと呼ぶ。標準的なパディングスキームはまだないが、１つのスキームが広範に使用され「事実上の」標準になっている。ＲＳＡセキュリティーズ社（ＲＳＡ Ｓｅｃｕｒｉｔｉｅｓ）のＰＫＣＳ＃１標準で符号化するＲＳＡ鍵と共にこのスキームを説明する。

このスキームは以下のように動作する。暗号化の前に、入力データは常にパディングされる。つまり、ＡＥＳの場合データの長さが１６で割り切れる場合でも、追加の１６バイトが追加される。さらに正確に言うと、Ｌが入力データの長さ（単位：バイト）、％がＬを１６で割るときの剰余演算子、である時、追加されるバイト数Ｎは、式Ｎ＝１６−（Ｌ ％ １６）によって計算できる。Ｎは［１−１６］の範囲内である。Ｎバイトを追加することによって、Ｌ＋Ｎは１６で割り切れるようになる。追加された各バイトは、Ｎに等しい同じ値を含む。その後、パディングされたデータを暗号化する。

解読の後解読されたデータを提示する前に、パディングした部分を取り除かなければならない。そのアルゴリズムは、１）最終バイトの値Ｎを得る、２）少なくともＮ個の最終バイトが全て値Ｎを有するか否かを検査する、３）Ｎ個の最終バイトを「削除」し、Ｎを減算することによってデータ長を更新する（「削除」は単に長さを更新することによって行ってもよい）、というように説明することができる。

このパディングスキームはかなり以前から使用されているので、他の暗号プロバイダが当方のデータを処理しなければならないという相互運用性を必要とする場合でも、他の暗号プロバイダはＰＫＣＳ＃１パディングを理解しているだろう。

鍵管理システムをサポートするためには、１）ハッシュ関数−ＳＨＡ１またはＳＨＡ２、２）ＥＣＢ／ＣＢＣモードでのＡＥＳ−２５６（ＡＥＳ−２５６／ＥＣＢモードはＴＷＥＡＫと結合して「カットアンドペースト」攻撃を防止する）、３）ＴＷＥＡＫ実装、４）ＰＫＣＳ＃５ ｖ２に記載のＰＢＫＤＦ２鍵導出関数、５）ＰＫＣＳ＃１標準によるＰＫＣＳ＃１パディング、６）ＨＭＡＣ−ＳＨＡ署名／検証、および７）ディフィ−ヘルマン鍵共有方式、のサポートが必要である。

鍵管理システムが顧客のＰＫＩインフラストラクチャに統合され、また、ユーザの鍵およびポリシを配布するための証明書をサポートする必要がある場合、ＰＫＩおよびＲＳＡのサポートが必要になることがある。

ＰＫＩ鍵管理システムは、１）ＡＳＮ．１パーサ、２）ＰＫＣＳ１、５、８、９、１０および恐らくＰＫＣＳ１１およびＰＫＣＳ１２のサポート、３）標準Ｘ．５０９証明書の拡張子および属性のサポート、４）予想される顧客専用の属性および拡張子ならびにワールドワイド名を備えたＸ．５０９ ｖ３証明書のサポート、５）サードパーティ暗号プロバイダとシームレスに作業するために予想される、ディフィ−ヘルマン鍵交換（ＰＫＣＳ＃３）、ＣＢＣモードのトリプルＤＥＳ、およびＰＫＣＳ＃１１のサポート、を必要とする。

何らかの種類の暗号サポートを必要とする全ての構成要素が共有する共通暗号インタフェース（暗号抽象層−ＣＡＬ）が必要な場合がある。この層は、当方の将来の顧客が既に使用し、そのため信頼を置き使用の継続を希望しているサードパーティの暗号ライブラリのような異なる暗号プロバイダに容易にプラグインできるものでなければならない。ＣＡＬは、サードパーティの暗号ライブラリと共に多数のハードウェア暗号プロバイダおよび暗号アクセラレータをサポートすることができる。ＣＡＬは、（一方はＡＥＳ用、もう一方はＳＨＡ１およびＨＭＡＣ−ＳＨＡ１用といった）異なるタスクのための（ソフトウェアまたはハードウェアの）異なる暗号プロバイダの登録を可能にする。

各セキュリティシステムは、通常、他の鍵またはルート証明書などの最も重要なデータを保護するために使用される、ルート鍵（ＲＫ）またはマスタ鍵と呼ばれる少なくとも１つの非常に重要なセキュリティ鍵を有する。この鍵自体を保護することが課題である。ＭＫを保護するためには、１）全ての保護が利用可能な安全な物理ロケーション、２）ＭＫをＦＩＰＳ−１４０．１レベル２以上の安全なハードウェアモジュールに格納する、および３）シャミアの鍵分割スキーム、という３つの基本的なアプローチが存在する。

ＭＫを保護することは問題の一方の側面に過ぎない。もう一方の側面は、ＭＫが必要な場合容易に利用できるようにしておくことである。ＭＫを１つしか有しない場合、「この鍵を紛失したらどうすればよいか？」という別の問題が出てくる。追加のコピーを作成することがこの問題を緩和する普通のアプローチであるが、これはセキュリティリスクを追加し鍵の取り消しを複雑にする。最初の２つのアプローチは、理論的に、ＭＫの高いストレージセキュリティを達成するが、容易な利用可能性および簡単な取り消し処置の両方を欠いている。最後の２つの問題を有効に解決するために、シャミアの鍵分割スキーム（ＳＫＳ）を導入した。

ＳＫＳの概念は、鍵、パスワード等となり得る任意のビット列である共有秘密（Ｓ）をＮ個の部分に分割するが、その際Ｋ＜Ｎであり、Ｋ個より少ない部分を有してもＳを回復できないが、任意のＫ個以上の部分を有すればＳを明瞭に回復できるというものである。

ＳＫＳスキームは多くの数学的実現を有するが、シャミア自身が提案した、最も簡単な、しきい値秘密分散法と呼ばれる概念を以下で説明する。

確率的アルゴリズムＰＡはしきい値秘密分散法を定義する。ここでは入力としてある有限の集合Ｆ_Sから秘密Ｓを受け取り、ｎ個の分散情報、すなわち、ビット列Ｓ１，．．．，Ｓｎを出力する。最後に、秘密分散スキームでは、０＜Ｋ＜Ｎであるしきい値Ｋが使用される。このアルゴリズムは、以下で概説するプライバシと正当性の要求に適合しなければならない。プライバシに関しては、インデックス｛１，２，．．．ｎ｝のサイズがＫ−１以下の任意のサブセットＩを取り、任意の入力Ｓ’に対してアルゴリズムが実行されると、｛Ｓｉ｜ｉ∈Ｉ｝の確率分布はＳ’と独立である。正当性に関しては、インデックス｛１，２，．．．Ｎ｝のサイズがＫ以上の任意のサブセットＪを取ると、アルゴリズムによって、｛Ｓｉ｜ｉ∈Ｊ｝からＳが計算される。実際に、｛Ｓｉ｜ｉ∈Ｊ｝からＳを計算する有効なアルゴリズムが存在する。

一例として、Ｐ＞Ｎである、ある素数Ｐについて、Ｓ＝Ｚ_Pと設定し、Ｋが希望するしきい値であると想定する。すると、シャミアが提案したアルゴリズムを以下のように記述することができる。
１）要素ａ₁，ａ₂，．．．ａ_n∈Ｚ_Pをランダムに選択し、ｆ（ｘ）を多項式とする。
ｆ（ｘ）＝Ｓ＋ａ₁＊ｘ＋ａ₂＊（ｘ＊＊２）＋．．．＋ａ_k＊（ｘ ＊＊ｋ） 別言すれば、ｆ（０）＝Ｓとなる次数が最大ＫのＺ_Pにおけるランダム多項式を選択する。
２）ｓ_i＝ｆ（ｉ） ｍｏｄ Ｐ、ｉ＝１，．．．，Ｎによって、分散情報を定義する。

このスキームは、ラグランジュ補間の古典的な結果のため、上記で概説した特性を有する。ラグランジェ補間では、任意のフィールドＦと、ｘ_iが判明している場合のｘ_iとｙ_iの組の任意の集合｛（ｘ_i，ｙ_i）｜０＜ｉ＜Ｋ＋１｝∈Ｆ×Ｆについて、次数が最大ＫであるＦに対して、ｇ（ｘ_i）＝ｙ_i、ｉ＝１．．．Ｋ＋１となる１つの多項式ｇ（ｘ）が確かに存在する。この多項式の全ての係数は有効に計算することができる。証明のため、

という多項式が、ｇ（ｘ_i）＝１で、ｊ≠Ｉの場合ｇ（ｘ_j）＝０を満足し、最大Ｋの次数を有することに注意されたい。従って、
ｇ（ｘ）＝ｙ₁ｇ₁（ｘ）＋．．．＋ｙ_k+1ｇ_k+1（ｘ）
は適切な特性を有する。従って、構造によって直接的に、ｇは有効に計算可能であるということになる。２つの異なる多項式ｇ（ｘ）、ｇ’（ｘ）がどちらも解であったとすれば、ｇ（ｘ）−ｇ’（ｘ）は次数が最大ＫでＫ＋１個の根を有するゼロでない多項式となる。しかしながら、このような多項式は存在しないので、１つの解しかあり得ない。

コンテンツ暗号化ファイアウォールシステムに関連する構成要素を例示する構成図である。 管理者アプリケーションの構成要素を例示する構成図である。 １つのセキュリティドメインと複数のセキュリティサブドメインとの図である。 クライアントアプリケーションの構成要素を例示する構成図である。 セキュリティドメイン作成方法のステップを例示するフローチャートである。 規則指定方法のステップを例示するフローチャートである。 プロビジョニング方法のステップを例示するフローチャートである。 プロビジョニング済モジュールを例示する構成図である。 クライアントアプリケーションの構成要素とコンピューティングステーションとの間の対話を例示する構成図である。 コンテンツアクセス方法のステップを例示するフローチャートである。 規則評価方法のステップを例示するフローチャートである。

Claims (19)

1. モバイルストレージ装置のストレージまたはコンテンツとコンピューティングステーションとの間の対話を管理する方法であって、前記方法が、
   ａ）前記モバイルストレージ装置のストレージまたはコンテンツと前記コンピューティングステーションとの間で実行する操作に関する要求がなされているか否かを決定するステップと、
   ｂ）前記ストレージまたはコンテンツからプロビジョニング情報を取り出すステップと、
   ｃ）前記ストレージまたはコンテンツに関連するセキュリティドメイン情報と前記コンピューティングステーションに関連するセキュリティドメイン情報とを比較するステップと、
   ｄ）前記要求された操作に基づいて実現すべき動作を決定するため前記コンピューティングステーションに関連する１つまたは複数の規則を評価するステップと、を含む方法。
2. 前記要求された操作を、マウント操作、コピー操作、削除操作、安全な削除操作、読み取り操作、書き込み操作、伝送操作、および実行操作からなるグループから選択することができる、請求項１に記載の方法。
3. 前記プロビジョニング情報が一意識別子を含む、請求項１に記載の方法。
4. 前記プロビジョニング情報がセキュリティドメイン情報を含む、請求項１に記載の方法。
5. 前記プロビジョニング情報がセキュリティサブドメイン情報を含むことができる、請求項４に記載の方法。
6. 前記１つまたは複数の規則を評価する前記ステップが、前記ストレージまたはコンテンツの種類を決定するステップを含む、請求項１に記載の方法。
7. 前記１つまたは複数の規則を評価するステップが、前記ストレージまたはコンテンツ上に格納されたコンテンツの種類を決定するステップを含む、請求項１に記載の方法。
8. 前記１つまたは複数の規則を評価するステップが、前記ストレージまたはコンテンツ上に格納された前記コンテンツの種類に関連するメタデータ情報を決定するステップを含む、請求項７に記載の方法。
9. 前記１つまたは複数の規則を評価する前記ステップが、前記ストレージまたはコンテンツに関連するインタフェースの種類を決定するステップを含む、請求項１に記載の方法。
10. 前記実現すべき動作が前記要求された操作を許可する動作である、請求項１に記載の方法。
11. 前記実現すべき動作が前記要求された操作を拒否する動作である、請求項１に記載の方法。
12. 前記実現すべき動作が前記要求された操作を読み取り専用で許可する動作である、請求項１に記載の方法。
13. 前記プロビジョニング情報が、前記ストレージまたはコンテンツ上で暗号によって保護されている、請求項１に記載の方法。
14. コンピューティングステーションとストレージまたはコンテンツとの間の対話を支配するポリシを導入する方法であって、前記方法が、
    ａ）前記ポリシに関連する１つまたは複数の規則を定義するステップであって、要求された操作、１つまたは複数の制御基準、１つまたは複数の論理演算および１つまたは複数の動作に基づいて、該１つまたは複数の規則を定義するステップと、
    ｂ）前記定義された１つまたは複数の規則に基づいて、ポリシモジュールを作成するステップと、
    ｃ）前記コンピューティングステーション上に前記ポリシモジュールをインストールするステップと、を含む方法。
15. 前記要求された操作を、マウント操作、コピー操作、削除操作、安全な削除操作、読み取り操作、書き込み操作、伝送操作、および実行操作からなるグループから選択することができる、請求項１４に記載の方法。
16. モバイルストレージ装置上のストレージまたはコンテンツをプロビジョニングする方法であって、前記方法が、
    ａ）前記ストレージまたはコンテンツに関連する１つまたは複数の規則から構成されるポリシを指定するステップと、
    ｂ）暗号鍵および署名を生成するステップと、
    ｃ）プロビジョニング情報を生成し、前記暗号鍵、署名およびプロビジョニング情報を前記ストレージまたはコンテンツ上に書き込むステップと、を含む方法。
17. 前記プロビジョニング情報がセキュリティドメイン情報を含む、請求項１６に記載の方法。
18. 前記プロビジョニング情報がセキュリティサブドメイン情報を含む、請求項１６に記載の方法。
19. 前記プロビジョニング情報が有効期限情報を含む、請求項１６に記載の方法。

Images