(57)【要約】ソフトウェア流通に適した、安全にソフトウェアを実行する機構を提供する。送信者側のサイト３１２では、実行ファイル３３２と実行ファイルで処理されるデータファイル３３４がカプセル化される。２つの残りのファイル３３６，３３８は、送信者側のサイトのポット３２０では物理的に存在していない。アーカイーブ・ファイル３２０は受信者サイト３１４に転送される。受信者サイト３１４では、セキュリティ・ポリシー３４０の規定に従って、プログラム３３２は、ポット内の実体のないファイル３３６，３３８を、ローカル・ファイル・システムのファイル３５４や、他のポット３５０内のファイル３５６にマッピングして、ポット内のファイル３３４やマッピングされたファイル３５４，３５６を用いて、処理を行うことができる。
2003050662.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアを安全に実行可能とするソフトウェア安全実行システムであって、
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットと、
前記ファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段と
を備え、
実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするソフトウェア安全実行システム。
【請求項２】
請求項１に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行前に、前記ファイル格納部から実行するシステムにファイルを抽出する
ことを特徴とするソフトウェア安全実行システム。
【請求項３】
請求項１に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行中の必要とされたときに、前記ファイル格納部から実行するシステムにファイルを抽出する
ことを特徴とするソフトウェア安全実行システム。
【請求項４】
請求項１〜３のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、最初に起動する実行ファイル名を格納できることを特徴とするソフトウェア安全実行システム。
【請求項５】
請求項１〜４のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、前記ファイル格納部内のファイル以外のファイル名を格納しており、
前記マッピング手段は、該ファイル名を、実行するシステムのファイル及び／又は他のポットのファイルにマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項６】
請求項１〜５のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、ディレクトリ名を格納でき、
前記マッピング手段は、該ディレクトリ名を、実行するシステムのディレクトリ及び／又は他のポットのディレクトリにマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項７】
請求項６に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、前記ディレクトリ名に対して、複数のディレクトリと定まった順番で対応させ、その順に該ディレクトリ内のファイルとマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項８】
請求項１〜７のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、ネット上のサイトのファイル名を格納でき、
前記マッピング手段は、サイトから該ファイル名のファイルを実行するシステムに転送する
ことを特徴とするソフトウェア安全実行システム。
【請求項９】
請求項１〜８のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスをファイルとしてマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１０】
請求項１〜９のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスが作成したファイルとマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１１】
請求項１〜１０のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行するシステム内のセキュリティ・ポリシーの規定に従ってマッピングを行う
ことを特徴とするソフトウェア安全実行システム。
【請求項１２】
請求項１１に記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定には、実行中に発行できるシステム・コールの規定が含まれる
ことを特徴とするソフトウェア安全実行システム。
【請求項１３】
請求項１１又は１２に記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定は、ネット上の他のサイトからダウンロードできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１４】
請求項１〜１３に記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、ユーザごとのファイルへのアクセス権の規定を格納でき、
前記マッピング手段は、前記アクセス権の規定により、ファイルへのアクセスを制御する
ことを特徴とするソフトウェア安全実行システム。
【請求項１５】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとの読み出し権の鍵で、ファイルを復号化して読み出す
ことを特徴とするソフトウェア安全実行システム。
【請求項１６】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、読み出し権の鍵を復号化し、復号化した鍵を用いてファイルを復号化して読み出す
ことを特徴とするソフトウェア安全実行システム。
【請求項１７】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、公開鍵−秘密鍵のペアである読み出し権および書き込み権の鍵を復号化し、復号化した鍵を用いてファイルを復号化または暗号化する
ことを特徴とするソフトウェア安全実行システム。
【請求項１８】
ポット情報とセキュリティ・ポリシー情報とを格納したサーバー・システムであって、
ポット情報と、前記ポット情報に対応したセキュリティ・ポリシー規定を格納したデータベースと、
前記セキュリティ・ポリシーをポットを特定して検索できる検索手段と
を備えることを特徴とするサーバ・システム。
【請求項１９】
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットを記録した記録媒体。
【請求項２０】
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムを記録する記録媒体であって、
該プログラムを実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするプログラムを記録する記録媒体。
【請求項２１】
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムであって、
該プログラムを実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするプログラム。
【発明の詳細な説明】
技術分野
本発明は、ソフトウェアを安全に実行する機構に関するものであり、特に、ソフトウェア流通に適した機構に関するものである。
背景技術
インターネットの一番顕著な特徴の１つは、それが本当に開放的な環境であるということである。常に世界中に広がっているとともに、だれも完全には、だれがユーザであるかや、どのようなソフトウェアやコンテンツがこれを通じて交換されているかの制御や決定をできない。これらの特徴は、バッチ，ＴＳＳ，ＬＡＮやパーソナル・システム等の伝統的で、閉鎖的なコンピュータ環境に対して鋭く対峙している。コンピュータ・システムの歴史の全てにおいて、コンピュータ環境は常に閉鎖的であり、システム・ソフトウェアの設計者は、暗黙的に閉鎖的な環境が通常であると仮定している。コンピュータ・システムの発展の歴史の中で、比較的短い期間内で、インターネットの世界的な展開が行われたので、システム・ソフトウェアの設計者は、閉鎖的な環境が開放的になる場合に生じる問題に対して、手当てする時間がほとんどなかった。環境が劇的に開放されているが、われわれは、基本的な設計が閉鎖的な環境の仮定に基づいているソフトウェアを未だに使用している。このように、現在のコンピュータ・システムは、新しい酒を古い瓶に入れているようだと言われている。
ネットワーク環境が閉鎖的であり、ユーザが、インターネットのような開放的なネットワーク環境にアクセスできない場合、悪意のあるユーザや、そのようなユーザによって作成されたファイルは、存在しそうにもない。不運にも、インターネット環境では、このように仮定することはできない。このため、インターネットからファイル、特に実行可能又はインタープリット可能なコードを含んでいるソフトウェアを得ることは、リスクのある行為である。リスクを低減するために用いられているアプローチの１つは、マイクロソフトのＡｕｔｈｅｎｔｉｃｏｄｅのようなコード署名手法である。この問題を解決するために期待できる技術的アプローチは、「砂箱」を作成して、リスクのある影響を、ユーザの通常の環境から隔離された、制限された制御可能な環境に閉じこめることである。このアプローチは、Ｊａｖａ，ＳＦＩ，Ｊａｎｕｓ，Ｍａｐｂｏｘ，およびＳｕｂＤｏｍａｉｎなどの多数のシステムに適用されている。
安全なソフトウェア流通の概念を明確にするため、まず初めに、安全でないソフトウェア流通のモデルについて説明する。このモデルは、伝統的に行われているソフトウェア配布を一般化したものである。次に、安全なソフトウェア流通を説明し、その用い方を説明する。
＜安全でないソフトウェア流通のモデル＞
ソフトウェア流通（Ｓｏｆｔｗａｒｅ  Ｃｉｒｃｕｌａｔｉｏｎ）は、「ソフトウェア配布（Ｓｏｆｔｗａｒｅ  Ｄｉｓｔｒｉｂｕｔｉｏｎ）」の概念の一般化したものを指す用語として以下で使用する。ソフトウェア配布は、一方向、一時的、１対多のソフトウェア・パッケージの配布を意味する。これらの特性を緩くする、即ち、ソフトウェア配布を、多方向、多時的、多対多とすることで、ソフトウェア流通の概念を得ることができる。ソフトウェア流通は、カプセル化（Ｅｎｃａｐｓｕｌａｔｉｏｎ），転送（Ｔｒａｎｓｆｅｒ），抽出（Ｅｘｔｒａｃｔｉｏｎ），実行（Ｅｘｅｃｕｔｉｏｎ）の４つの基本的な処理で行われる。これらの処理を図１に示す。
図１（ａ）で示される「カプセル化処理」は、１以上のファイル１１０，１２０，１３０に対して適用され、これらのファイルでカプセル化したアーカイーブ・ファイル１５０を作成する。図１（ｂ）の「転送処理」では、カプセル化したファイル１５０を送信元サイト１６２から送信先サイト１６４に移動する。図１（ｃ）の「抽出処理」は、カプセル化処理の逆の処理である。即ち、１以上のファイル１１０，１２０，１３０がアーカイーブ・ファイル１５０から抽出される。抽出されたファイルは、処理が実行されたサイト１６４のファイル・システム中のどこかに格納される。ファイル位置、名前、アクセス制御設定はその時に行われる。図１（ｄ）の「実行処理」では、丸の中にクロスがあるもので示されている実行可能なプログラム１４０が実行される。実行中、ファイル（クロスがない丸）１１０，１２０，１３０は、入力され、出力され、修正される。
これらの処理を結合することにより、典型的なソフトウェア流通のシナリオを行うことができる。図２はソフトウェア配布を図示している。送信者サイト（例えば、ソフトウェア・パッケージ配布者）１６２では、ソフトウェア・プログラムを構成するファイルをカプセル化して、アーカイーブ・ファイル１５０を生成する。アーカイーブ・ファイル１５０は配布者のサイト１６２から受信者（ユーザ）のサイト１６４へ移動する。ユーザのサイト１６４では、アーカイーブ・ファイル１５０は抽出されて、ファイル処理又はインストールのプログラム１４０により、ユーザのファイル・システム中に格納される。
図３は、図２のソフトウェア配布の変形を示している。抽出及び／又はインストール・プログラム１４２はアーカイーブ・ファイル１５２中に含まれている。アーカイーブ・ファイルを受け取ったユーザは、アーカイーブ・ファイル１５２中のプログラム１４２を使用して、インストール等を行うことができる。この配布形態は、柔軟性があり、便利である。ユーザが抽出プログラムやインストール・プログラムを持っていなくても、配布者は、インストール・プログラム中に書き込むことで、どんなことでもインストール中に行うことができるからである。
図４および図５は、ソフトウェア流通の繰り返しスタイルを示している。図４は作業の流れをモデル化して示している。図４において、各サイト１６６，１６８のプログラム１４４，１４６は流通するファイル１５４，１５５等に適用されている。図５では、流通するファイル１５７，１５８に含まれているプログラム１４８が実行される。これはモバイル・エージェント・システムをモデル化している。
図１〜図５に示されたモデルは、次の観点で安全ではない。
（１）カプセル化処理で、悪意のある人間が、例えば、実行されたとき悪いことを行う、又は、抽出したときに悪意の目的で既存のファイルに上書きするファイルをアーカイーブ・ファイル中に含ませる罠を置くかもしれない。
（２）転送処理の間に、ファイルは悪意のある中途妨害、横取り、修正、偽造に会うかも知れない。
（３）抽出処理の間に、抽出されたファイルはユーザのファイル・システム中に格納される。この時に、このファイル格納が位置決めされ、名付けられて、これらのアクセス制御が設定される。これらの処理はユーザのファイル・システムの管理にとって危険である。そして、ユーザの管理手法に従って行われないと大変危険である。
これらの理由により、このモデルは安全でないソフトウェア流通（ＵＳＣ：Ｕｎｓｅｃｕｒｅ  Ｓｏｆｔｗａｒｅ  Ｃｉｒｃｕｌａｔｉｏｎ）モデルと呼ばれる。
発明の開示
本発明の目的は、上述の問題点を解消し、ソフトウェア流通に適した、安全にソフトウェアを実行する機構を提供することである。
上記の目的を達成するために、本発明は、ソフトウェアを安全に実行可能とするソフトウェア安全実行システムであって、実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットと、前記ファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段とを備え、実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とする。
前記マッピング手段は、実行前又は実行中の必要とされたときに、前記ファイル格納部から、実行するシステムにファイルを抽出することができる。
前記ファイル名格納部には、最初に起動する実行ファイル名を格納できる。
また、前記ファイル名格納部は、前記ファイル格納部内のファイル以外のファイル名を格納しており、前記マッピング手段は、該ファイル名を、実行するシステムのファイル及び／又は他のポットのファイルにマッピングすることができる。
その上、前記ファイル名格納部は、ディレクトリ名を格納でき、前記マッピング手段は、該ディレクトリ名を、実行するシステムのディレクトリ及び／又は他のポットのディレクトリにマッピングすることができる。このとき、前記ディレクトリ名に対して、複数のディレクトリと定まった順番で対応させ、その順に該ディレクトリ内のファイルとマッピングすることもできる。
前記ファイル名格納部は、ネット上のサイトのファイル名を格納でき、前記マッピング手段は、サイトから該ファイル名のファイルを実行するシステムに転送することもできる。
前記マッピング手段は、プロセスをファイルとしてマッピングすることや、プロセスが作成したファイルとマッピングすることもできる。
前記マッピング手段は、実行するシステム内のセキュリティ・ポリシーの規定に従ってマッピングを行うこともでき、このセキュリティ・ポリシーの規定には、実行中に発行できるシステム・コールの規定を含むこともできる。
このセキュリティ・ポリシーの規定は、ネット上の他のサイトからダウンロードして使用できる。
ポット情報とセキュリティ・ポリシー情報とを格納したサーバー・システムであって、ポット情報と、前記ポット情報に対応したセキュリティ・ポリシー規定を格納したデータベースと、前記セキュリティ・ポリシーをポットを特定して検索できる検索手段とを備えることを特徴とするサーバ・システムも本発明である。
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムやそのプログラムを記録する記録媒体であって、該プログラムを実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするものも本発明である。
発明を実施するための最良の形態
以下、図面を参照して、本発明の実施形態を説明する。
まず、安全であるソフトウェア流通（ＳＳＣ：Ｓｅｃｕｒｅｄ  Ｓｏｆｔｗａｒｅ  Ｃｉｒｃｕｌａｔｉｏｎ）モデルを考える。初めに、安全の意味を説明する必要がある。第１に、絶対的安全であるシステムは事実上設計不可能であることは一般的に認められていることである。このモデルおよびこのモデルを基にした我々の実装システムは、システマチックに容易に操作することで、安全に関する問題に関してＵＳＣモデルより、単にもっと安全であるものである。第２に、移転処理の安全でない面は、ソフトウェア流通に制限されるものではない。これはまた、一般的な情報移転に関する問題でもある。
以下に説明するＳＳＣモデルの中心的アイディアは、実行及びカプセル化の両方の間、流通されたソフトウェアの内側および外側を区別することである。これを可能とするため、２つのアイディアがこのモデルに導入された。第１は、ファイルをアーカイーブから抽出せず、代わりに、アーカイーブ・ファイルをファィル・システムとして使用するように概念を拡張した。第２に、アーカイーブ・ファイルと関連付けられた、区別された仮想アドレス空間内でプログラム実行を可能とした。ＳＳＣモデルは、仮想アドレス空間とファイル・システムの２つの空間を、１つに統合して、ポットと呼ばれる砂箱（ｓａｎｄｂｏｘ）を作成している。各ポットは、仮想アドレス空間と仮想ファイル・システムの両方に対して、自分自身の区別された観点を有している。
＜ＳＳＣモデルの基本処理＞
ＳＳＣモデルの基本処理について、次に述べるように定義した。図６はそれを図示したものである。なお、以下ではＵｎｉｘのシステムに適用した場合で説明する。
図６（ａ）に示したカプセル化処理は、１以上のファイル２１２，２１４，２１６に適用されて、これらをポット２２０中に格納する。格納する際に、各ファイルは、Ｕｎｉｘと互換性があるユニークなパス名を与えられる。そして、最新修正時刻や実行可能性等の属性情報が記録される。図６（ｂ）の移転処理は、送信元サイトＡ２３２から目的のサイトＢ２３４に、カプセル化されたファイル（ポット）２２０が移動する。
ＳＳＣモデルのマッピング処理は、ＵＳＣモデルの抽出処理に代わるものである。図６（ｃ）において、マッピング処理は白抜きの矢印で表されている。ポット中のファイルｆＡ２１２またはｆＡ’２１４から、ローカル・ファイルのファイルｆＢ２１６またはポット２２２中のファイルｆＢ’２１８にマッピングするとは、ポットでの実行中におけるファイルｆＡ２１２またはｆＡ’２１４へのアクセスは、ファイルｆＢ２１６またはｆＢ’２１８にリダイレクトされることである。
図６（ｄ）は実行処理を示している。実行処理中、ポット２４０中のプログラム２４２は、実行サイト２３４のファイル・システムと共有している仮想アドレス空間中では実行されない。代わりに、ポット２４０は自分自身のファイル・システムのような仮想アドレス空間と関連付けられる。そして、ポット中のプログラム２４２はこの環境内、即ち、ポット中に現れるファイル以外は見えない状況で実行される。この実行は、マッピング・スキームと使用許可される資源とで規定されている。
上述したように、本発明のポットは、処理がポットと関連付けられているかどうかにより、２つの状態を有している。２つの状態の間を区別するため、処理がポットと関連しない場合のポット・ファイル（ｐｏｔ−ｆｉｌｅ）と、処理に関連している場合のポット・プロセス（ｐｏｔ−ｐｒｏｃｅｓｓ）の用語を使用する。
図７は、４つの処理を結合した典型的なＳＳＣモデルの使用を図示している。図７において、送信者側のサイト３１２では、１つの実行ファイル（クロスを含む丸）３３２と実行ファイルで処理される１つのデータファイル（クロスなしの丸）３３４がカプセル化される。２つの残りのファイル（点線の丸）３３６，３３８は、送信者側のサイトのポット３２０では物理的に存在していない。このファイルは実行時に受信者側サイトでマップされる。これについては後で説明する。ポット・ファイル３２０は送信者サイト３１２から受信者サイト３１４に、ＦＴＰ，ＷＷＷ，電子メール等の転送方法で転送される。
受信者サイト３１４では、ユーザは、ポット中のファイルとローカル・ファイルとの間や、ポット中のファイルと他のポット中のファイルとの間のマッピング・スキームを特定するセキュリティ・ポリシー記述３４０を用意する。このセキュリティ・ポリシー３４０の規定により、ポット内でプログラムが実行中、他のローカル・ファイルを見ることができない。セキュリティ・ポリシー・ファイル３４０は、実行中に発行が許されるＯＳカーネルのシステム・コールも記述できる。このセキュリティ・ポリシーについては後で詳しく説明する。
受信者サイト３１４では、セキュリティ・ポリシー３４０の規定に従って、プログラム３３２は、ポット内の実体のないファイル３３６，３３８を、ローカル・ファイル・システムのファイル３５４や、他のポット３５０内のファイル３５６にマッピングして、ポット内のファイル３３４やマッピングされたファイル３５４，３５６を用いて、処理を行うことができる。
この様に、ポットは、ユーザの処理における通常の実行環境から区別される砂箱を形成している。
マッピング処理に対して２つの小さい拡張をしている。
（１）ディレクトリ・マッピング
ポット内のディレクトリを、他のポット内やローカルの通常のファイル・システムのディレクトリにマッピングすることを許している。これを図８（ａ）で説明する。図８（ａ）では、ポット３２０中のディレクトリ３６２，３６４と、ローカル・ファイル・システム中のディレクトリ３６６および他のポット３６７中のディレクトリ３６８とをマッピングしていることを示している。
（２）縦続マッピング（ｃａｓｃａｄｅ  ｍａｐｐｉｎｇ）
マッピングの縦続（ｃａｓｃａｄｅ）を許している。簡単な縦続マッピングの動作的意味は次の通りである。縦続マッピング処理は、ポット中及び／又は通常ファイル・システムの多重ディレクトリ（ｍｕｌｔｉｐｌｅ  ｄｉｒｅｃｔｏｒｉｅｓ）間の完全な順序関係を規定している。マッピング処理でファイルのパス名を得たとき、完全に順序付けられた複数のディレクトリがその順序で得られて、発見された最初のファイルがその結果である。これらの拡張は、セキュリティ・ポリシーの記述を簡単にし、容易にすることに役立つとともに、転送されたポットの処理をより柔軟にする。これを図８（ｂ）で説明する。
図８（ｂ）において、ポット中のディレクトリ３７２と、ポット３８２中のディレクトリ３９２およびポット３８６中のディレクトリ３９６とがこの順序で縦続マッピングされている。マッピング処理においては、ディレクトリ３７２中のファイルは、ディレクトリ３９２とディレクトリ３９６とをこの順序でサーチして、最初に発見したものとマッピングする。図８（ｂ）においては結果的に、ディレクトリ３７２中の３つのファイルは、ディレクトリ３９２内の２つのファイル，ディレクトリ３９６内の１つのファイルとマッピングされる。ポット３２０中のディレクトリ３７４も同様にマッピングされる。
＜ＳＳＣ（Ｓｅｃｕｒｅｄ  Ｓｏｆｔｗａｒｅ  Ｃｉｒｃｕｌａｔｉｏｎ）モデルの利用＞
ＳＳＣモデルを適用して、開放的なネットワーク環境中で安全なソフトウェア転送を必要としている典型的な処理（ｃｏｍｐｕｔａｔｉｏｎ）をいかにして表現するかを示す。
（１）ダウンロードされたコードの安全な解釈実行（ｉｎｔｅｒｐｒｅｔａｔｉｏｎ）
ＳＳＣの典型的な利用は、ダウンロードされたコードの安全な解釈実行である。この形式の処理は、広く使用されているＪａｖａやそのａｐｐｌｅｔシステムにより普及した。ＳＳＣは、ダウンロードされたコードの安全な解釈実行を可能とする一般的なフレームワークを提供する。これを図９で説明する。図９において、サーバ・サイト４３２で、コードのファイル４１２をポット４１０にカプセル化する。このコード４１２を含むポット４１０は、クライアント・サイト４３４に送られて、そのサイト４３４のポット４２０中に格納されているインタプリタ４１４で解釈実行される。クライアント・サイト４３４に送られたポット４１０は、インタプリタ実体４１４をマッピング処理により結びつけられる。そして、送信者から送られたポット４１０中にインタープリタが現れたかのように、関連するセキュリティ・ポリシー４４０の制御に基づき、コード４１２を解釈して実行する。この安全なダウンロードされたコードの解釈実行のためのフレームワークは、使用できるプログラミング言語システムや仮想マシン命令セットに制限されないことに注意されたい。
（２）動的に生成されたネイティブ・コードの安全な実行
次に、もっと進化したダウンロードされたコードの実行を説明する（図１０）。この形式の処理は、ジャスト・インタイム（ＪＩＴ）コンパイルと通常呼ばれている。
図１０（ａ）において、送信者サイト４３２から受信者サイト４３４にダウンロードされたポット４６０中のコード４６２は、マッピングされたコンパイラ４６４により、受信者サイト４３４のＣＰＵアーキテクチャに対するネイティブ・コード４６６にコンパイルされる。生成されたネイティブ・コード４６６は、受信者サイト４３４で、セキュリティ・ポリシー４４０の規定に従って、送られてきたポット４６０中で実行される。必要なら、その実行結果は、ローカル・ファイル・システムのファイル４６９にマッピングされる。
図１０（ｂ）は、生成されたネイティブ・コード４６６が、他のポット４８０中にマッピングされて、そのポット４８０中でセキュリティ・ポリシー４４０の規定に従って実行される。
図１０に示されるように、この処理は、基本的な処理を単純に組み合わせることで表現することができる。このように、比較的複雑な処理をシステマチックな手法で実現して、システムがＳＳＣモデルを実装できることを期待している。
（３）モバイル・エージェントの安全な実行
モバイル・エージェント・システムは、分散処理（ｄｉｓｔｒｉｂｕｔｅｄ  ｃｏｍｐｕｔａｔｉｏｎ）の最も精巧な形式の１つである。興味深いことに、この形式の処理は、ＳＳＣモデルを用いることにより、原理的に素直な手法で表現することができる。
図１１において、受信者サイト４５２，４５４では、ポット４９０を受信した後、ポット４９０中に格納されているプログラム４９２は、規定されたセキュリティ・ポリシー４４２，４４４の制御下、各サイトのポット環境内で実行される。この図は、モバイル・エージェント処理の原理のみを示している。もっと複雑な設定が現実の状況では必要である。例えば、受信者サイトのローカル・ファイル・システム中のファイルが、ポットに対してマッピングされており、実行コードは図９のように解釈されているか、図１０のようにＪＩＴコンパイラを用いて実行されている。
（４）安全なワークフロー処理（ｗｏｒｋｆｌｏｗ  ｃｏｍｐｕｔｉｎｇ）
安全なワークフロー処理の表現は、安全なモバイル・エージェント処理に対するものを少し修正することで得ることができる。相違点は、モバイル・エージェント処理ではプログラム・コードが転送されたポット中に含まれているが、ワークフロー処理では各実行プログラム・コードが各処理サイトでローカルに通常用意されていることである。典型的な設定例が図１２に示されてる。
図１２（ａ）において、プログラムが処理する対象のファイルを格納したポット５３０が、各サイト５１２，５１４を移転して、各サイトにあるポット５２０，５４０中のプログラム・コード５２２，５４２が処理することを示している。各サイトでは、プログラム５２２，５４２があるポット５２０，５４０から、移転してきたポット５３０内のファイルに対してマッピングしている。
図１２（ｂ）では、各サイト５１２，５１４で、移転してきたポット５５０から、各サイト５１２，５１４内のプログラム・コード５６２，５６４にマッピングして、ポット内のファイルに対して処理を行っている。
＜ソフトウェア・ポット（ＳｏｆｔｗａｒｅＰｏｔ）：ＳＳＣモデルの実装例＞  先に記述されているＳＳＣモデルは、いろいろな手法で実装することができる。ここでは、ＯＳカーネルを修正しない、移植可能なアプローチを記述する。その代わりに、この手法は、発行されたシステム・コールを解釈して操作する機能を使用する。このような機能は、多数の現在のオペレーティング・システム（例えば、Ｓｏｌａｒｉｓ，Ｌｉｎｕｘ，ＦｒｅｅＢＳＤ等）で提供されている。このアプローチを基に設計されているシステムをソフトウェア・ポットと呼ぶ。ソフトウェア・ポットは、図６に記述されているＳＳＣモデルの４つの処理をサポートしている。これらの処理の１つである転送処理は、よく知られたどのネットワーク転送方法（例えば、ＦＴＰ，Ｗｅｂ，電子メール等）を用いても実装することができる。以下に、他の３つの処理の実装スキームを、図１３〜図１９を用いて説明する。
（１）カプセル化処理
カプセル化処理は、カプセル化対象として規定されたファイルを集めて、これらのファイルをポット・ファイル中に格納することで実装される。図１３は、カプセル化の規定の例を示している。キーワードの″ｓｔａｔｉｃ：″６１２が前に置かれている静的ファイル・セクション６１０は、それぞれの行の第２項で規定されている、ローカル・ファイル・システム中のファイルが、第１項で規定されているパス名でポット・ファイル中に格納されることを規定している。例えば、図１３の第２行６１３は、ローカル・ファイルである／ｈｏｍｅ／ｕｓｅｒｌ／ｐｉｃｔｕｒｅ／ｐｉｃＡ．ｊｐｇがポット・ファイル中に／ｄａｔａ／ｐｉｃｌ．ｊｐｇのパス名で格納されることを規定している。
これを、図１４および図１５で説明する。図１４は、送信者サイト７１２でポット・ファイル７２２をカプセル化して、送信者サイト７１２から受信者サイト７１４へポット・ファイル７２２を転送している。図１５は、現在の実装におけるポット・ファイルの内部構造８００を示している。なお、図１５でマジック・ワード８１０とは、ポット・ファイルを識別するためのものである。
図１４では、送信者サイト７１２中のファイル７４２は、実体的にポット・ファイル７２２中に格納されている。これを静的に格納されているという。
静的に格納されたファイルは、図１５の静的ファイル情報８１２に静的ファイル・セクション６１０（図１３参照）内のパス名が格納されるとともに、ファイルの実体が「ファイル格納」領域８２２と名付けられている領域に格納される。ファイルをファイル格納領域８２２に格納するために、例えばモジュール構造を採用でき、現在はｔａｒ，ｔａｒ＋ｇｚｉｐ，又はｚｉｐのフォーマットを使用している。格納したフォーマットの選択は、次のセクションで説明される機構により、ポット・プロセス中で実行されるプログラムに対して完全に透明（ｔｒａｎｓｐａｒｅｎｔ）である。
ファイルを静的（ｓｔａｔｉｃａｌｌｙ）にポット・ファイル中に格納する基本的な機能に加えて、ソフトウェア・ポット・システムは、格納されるファイルのもともとの位置のみを格納して、ファイルの内容は要求されたときに動的（ｄｙｎａｍｉｃａｌｌｙ）に格納するときに使用する機能を有している。これは、図１３のカプセル化規定の″ｄｙｎａｍｉｃ：″６２２で示している動的ファイル・セクション６２０において規定されている。図１３の例では、行６２４におけるパス名／ｍｙｂｉｎ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ１のファイルは、ＵＲＬのｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ１で規定される位置から得るべきであり、行６２６でのファイル／ｍｙｂｉｎ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ２は、ポット・ファイルが作成されたサイトの／ｈｏｍｅ／ｕｓｅｒ１／ｂｉｎ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ２の位置から得るべきであることを規定している。
図１４では、送信者サイト７１２のファイル７４４，他のサイト７１６内のポット７２６に格納されているファイル７４６，他のサイト７１８のファイル７４８のそれぞれのパス名（他のサイトの場合は、それぞれのサイトのＵＲＬを含む）を、ポット７２２内にカプセル化の際に格納することを示している。これらのファイルは受信者サイト７１４での実行時に必要になったときに得ている。図１５で、これらの情報はファイル構造８００のおける動的ファイル情報８１４に含まれている。
静的メソッド（ｓｔａｔｉｃ  ｍｅｔｈｏｄ）は、絶対に必要なファイルを格納するために有効である。一方、動的メソッド（ｄｙｎａｍｉｃ  ｍｅｔｈｏｄ）は、選択的に必要なファイルを格納することや、ポット・ファイルのサイズを縮小することに有効である。
″ｒｅｑｕｉｒｅｄ：″６３２が前に置かれているセクション６３０は、実行時にマッピングされるファイルやディレクトリを規定している。図１３において、規定例では、ディレクトリ／ｖａｒ６３４および／ｅｘｔｅｒｎ＿ｗｏｒｌｄ６３６が、実行時にマッピングされることを規定している。図１５で、これらの情報はファイル構造８００のおけるマップ・ファイル情報８１６に含まれている。
″ｓａｖｅｄ：″６４２で始まるセクション６４０は、列挙されているディレクトリ中のファイルの修正は、ポット・ファイル・システム中に永久的に反映すべきであり、他のファイルの修正は、実行セッション中に一時的に反映されて、セッション後は捨てられることを規定している。また、″ｅｎｔｒｙ″６５２のセクション６５０は、最初に実行すべきデフォルトのファイル（図１３の６５４参照）を規定している。図１５で、これらの情報はファイル構造８００におけるセーブ・ファイル情報８１８およびエントリ情報８２０に含まれている。
（２）マッピングおよび実行処理
マッピング及び実行処理の実装は、ソフトウェア・ポット・システム中では統合されており、このため、これを一緒に、図１６〜図１９を用いて説明する。
双方の処理のエッセンスは名前の変換である。即ち、ファイルを操作する全ての基本的な処理（例えば、ｏｐｅｎ，ｒｅａｄ，ｗｒｉｔｅ，ｌｓｅｅｋ，ｃｌｏｓｅのシステム・コール）は、マッピングされた目的のファイルにリダイレクトされる。図１６は、この名前変換スキームを図示している。マッピングされている・されていないに関わらず、ポット内の全てのファイル・アクセスは、一様にマッピングを介して取り扱われる。これは、ファイルがアクセスされたときまでに、ポット中に静的に格納されている全てのファイルは、ローカル・ファイル・システムへ抽出されているからである。
図１６において、ポット・プロセス９１０の初期設定の途中で、名前変換スキームが、マッピング及びセキュリティ・ポリシー記述（ｍａｐｐｉｎｇ  ａｎｄ  ｓｅｃｕｒｉｔｙ  ｐｏｌｉｃｙ  ｄｅｓｃｒｉｐｔｉｏｎ）に従って用意される。ポット・プロセス９１０がプログラムで記述したファイルをアクセスするとき、名前変換により、ローカル・ファイル・システム中のポット９３０内のファイル９３２，９３４、ポット９４０内のファイル９４４、およびファイル９５２にアクセスされる。また、他のプロセス９６０に対してプロセス間通信（ＩＰＣ）を介してアクセスしたり、他のサイト９７０にＨＴＴＰ等のネットワーク・プロトコルを介してアクセスしている。
また、他のプロセス９８０が生成したテンポラリ・ファイル９８２に対してもアクセスすることができる。この機能により、ポット・プロセス９１０に見せてもよい情報を制限したり、あるいは実際には存在しないファイルをポット・プロセス９１０に対して存在するかのように見せることができる。
ポット・プロセス９１０から見たファイル・システム空間は、名前変換規定により生成された仮想的なものである。ポット・プロセス９１０は、実行してるオペレーション・システムの「実」ファイル・システムを直接見ることはない。
抽出に対して、２つのモードが用意されてる。イーガー抽出モード（ｅａｇｅｒ  ｅｘｔｒａｃｔｉｏｎ  ｍｏｄｅ）とレージー抽出モード（ｌａｚｙ  ｅｘｔｒａｃｔｉｏｎ  ｍｏｄｅ）である。イーガー抽出モードでは、ポットに静的に格納されている全てのファイルは、実行処理が起動されるときに、一度に抽出される。他方、レージー抽出モードでは、各ファイルが、アクセスに必要なときに抽出される。
図１７に示されている例を用いて、ソフトウェア・ポットにおいて、どのように名前マッピングとセキュリティ・ポリシーの規定が記述されているかを説明する。
″ｍａｐ：″セクション１０１０は、第１項で規定されているポット中の各ファイルまたはディレクトリが、第２項で規定されてる既存のファイル又はディレクトリにマッピングされることを規定している。例において、″／ｅｔｃ／ｔｅｒｍｃａｐ／ｌｉｂ／ｔｏｏｌｓ．ｐｏｔ：／ｅｔｃ／ｔｅｒｍｃａｐ″の行は、ポット・プロセス中でアクセスされる″／ｅｔｃ／ｔｅｒｍｃａｐ″ファイルが、″／ｌｉｂ／ｔｏｏｌｓ．ｐｏｔ″という名前のポット・ファイル中の同じ名前を有するファイルへリダイレクトされることを規定している。
″／ａｌｐｈａ／ｂｅｔａ，／ｇａｍｍａ，／ｄｅｌｔａ″の行は、縦続マッピングの規定の仕方を示している。例えば、″／ａｌｐｈａ／ｘ″ファイルへのアクセスは、″／ｂｅｔａ／ｘ″，″／ｇａｍｍａ／ｘ″，″／ｄｅｌｔａ／ｘ″の各ファイルの１つにリダイレクトされる。このファイル選択では、″／ｂｅｔａ／ｘ″ファイルが最も優先され、″／ｄｅｌｔａ／ｘ″ファイルが一番低い。
″ｔｅｍｐｏｒａｒｙ：″セクション１０２０は、″／ｓｂｉｎ／ａｃｃｏｕｎｔ＿ｐｒｏｃｅｓｓｉｎｇ／ｕｓｅｒｓ  ａｌｌ″という起動コマンドで指定されたプログラムの実行出力を一時ファイルに格納し、その一時ファイルにポット・プロセス内の″／ｅｔｃ／ａｃｃｏｕｎｔ″というファイルをマップすることを規定している。
″ｉｎｄｉｒｅｃｔ：″セクション１０３０は、「プロセス・マッピング（ｐｒｏｃｅｓｓ  ｍａｐｐｉｎｇ）」と呼ばれる特別のマッピング処理を規定している。即ち、ポット・プロセス中のファイルＩ／Ｏは、プロセス間通信にリダイレクトされる。この例では、″／ｅｔｃ／ｐａｓｓｗｄ／ｈｏｍｅ／ｕｓｅｒ２／ｂｉｎ／ｐａｓｓｗｄ＿ｆｉｌｔｅｒ″は、ポット・ファイル中の″／ｅｔｃ／ｐａｓｓｗｄ″ファイルへのアクセスは、コマンド″／ｈｏｍｅ／ｕｓｅｒ２／ｂｉｎ／ｐａｓｓｗｄ＿ｆｉｌｔｅｒ″で起動されたプロセスに対するプロセス間通信にリダイレクトされることを規定している。
上述したように、″ｉｎｄｉｒｅｃｔ″セクションで指定する機能は，起動したプロセスとのプロセス間通信を，ファイルであるかのようにマップする機能であるのに対し，ｔｅｍｐｏｒａｒｙセクションで指定する機能は、実行出力を一時ファイルに格納し、その一時ファイルにマッピングを行うものである。一時ファイルを生成するコスト（時間，ファイル容量）が小さいときは″ｔｅｍｐｏｒａｒｙ″セクション、大きいときは″ｉｎｄｉｒｅｃｔ″セクション機能を使うとよい。また，″ｉｎｄｉｒｅｃｔ″の方がより動的であり、内容を動的に生成することができる。なお、″ｔｅｍｐｏｒａｒｙ″セクションで規定したプログラムは、マップ前に一時ファイル内容を生成する必要がある。
残りのセクション１０４０，１０５０は、セキュリティ・ポリシーを規定している。″ｎｅｔｗｏｒｋ：″セクション１０４０では、例においては、全ての通信関連のシステム・コールは、ＩＰアドレス１３０．１５８．８０．＊のＴＣＰポート８０への接続（ｃｏｎｎｅｃｔｉｏｎ），１３０．１５８．８５．９７のＴＣＰポート２１への接続，″＊．ｔｓｕｋｕｂａ．ａｃ．ｊｐ″のＴＣＰポート２２への結び付き（ｂｉｎｄ）が許されていることを除いて、禁止されていることを規定している。
また、″ｓｙｓｃａｌｌ：″セクション１０５０では、ネットワーク関連以外のシステム・コールに対しての許可（ｐｅｒｍｉｓｓｉｏｎ）を規定している。例では、ネットワーク関連と（キーワード″ｄｅｎｙ″が前に置かれている）最後の２行に列挙されているもの以外の、全てのシステム・コールが許可されている。
ここで、名前変換を実装している方法について、図１８を用いて説明する。ここで示している例は、ポット・プロセス１１００で発行したオープン（ｏｐｅｎ）のシステム・コールの引数を、以下の様に実行時に書き換えるものである。
2003050662.tif 000003
さて、ほとんどの現在のオペレーティング・システムは、システム・コールを、ＯＳカーネル中のコールの実行の前および後に横取りして、横取りしたときにユーザ・レベルのコードを実行する機能をサポートしている。また、現在のＯＳは、ユーザ・プロセスが、他のユーザ・プロセスを、制限された仕方で調べて修正することを許容している。これらの機能を結合することで、ＯＳカーネルを修正することなく、要求される名前マッピング機構を透過的（ｔｒａｎｓｐａｒｅｎｔｌｙ）に実装できる。
図１８において、初期設定により、モニタ・プロセス（以下、モニタ）１２００は起動されて、ポット・プロセス１１００と関連付けられて実行を監視している。名前マッピングに対する設定は、図１８のパス名変換テーブル１２２０に記録されている。
ポット・プロセス１１００がオープン・システム・コールを発行したとき、カーネル１３００はそのコールを捕らえてモニタを呼び出す（Ｓ１３０２）。モニタ１２００は、ポット・プロセス１１００の内容を調べ、オープンされるべきファイルのパス名１１２２を得る（Ｓ１２０４）。パス名変換テーブル１２２０を参照して、モニタ１２００は、オープン・システム・コールが適用すべき実際のファイルを決定する。レージー・ファイル抽出モードが規定されている場合、ファイルがポット・ファイルのファイル格納から抽出される。縦続マッピングが規定されている場合、ファイル検索は、規定された完全順序付けのディレクトリ・リストに従って行われる。動的ファイル転送がマッピング規定に規定されている場合、適切なファイルがネットワークを介して獲得される。″ｉｎｄｉｒｅｃｔ：″オプションが規定されている場合、規定されたプロセスが起動され、ポット・プロセスと起動されたプロセスとの間で、プロセス間通信が確立される。
モニタ・プロセス１２００は、変換されたパス名１１４２をポット・プロセス１１００の使用されていない領域（図１８ではスタック・セグメント１１４０）に書き込み、レジスタに格納されているパス名へのポインタを、変換されたファイル名１１４２への参照として書き直す（Ｓ１２０６）。レジスタへの書き直しの直前、モニタ・プロセスは、レジスタの内容を、後で回復するためにセーブする。
次に、モニタ１２００は、その後、カーネル１３００にオープンの実際の処理を実行するように指示する（Ｓ１２０８）。カーネル１３００は、オープンの処理を実行する（Ｓ１３１０）。カーネル１３００が再びモニタ１２００を呼び出す（Ｓ１３１２）。モニタ１２００は、レジスタの内容を回復して、ステップＳ１２０６で書いた変換されたパス名を消去する（Ｓ１２１４）。モニタ１２００は最後に、カーネル１３００にポット・プロセス１１００を再開するように指示する。
実行中、ポット・プロセスはフォーク（ｆｏｒｋ）システム・コールを発行して、他のポット・プロセスを子プロセスとして生成できる。これを図１９を用いて説明する。図１９において、ポット・プロセス１４０８は、セキュリティ・ポリシーにより許可されている場合、フォーク・システム・コールを発行して、ポット・プロセス１４１０を子プロセスとして生成できる。このとき、モニタ１４０２もフォークして、子のモニタ・プロセス１４０４が子のポット・プロセス１４１０を監視する。
＜安全なソフトウェア流通＞
ソフトウェア・ポット内のソフトウェアを実行する際に、そのソフトウェアの挙動を監視して，ユーザの意図に反した挙動を示した場合は、異常終了させたり、その挙動の続行を許すかどうかをユーザが定める必要がある。これを規定するセキュリティ・ポリシーは、ソフトウェアごとに作成する必要がある。計算機システムに対する詳しい知識を有するユーザはこのセキュリティ・ポリシーを自身で作成してよい。そうではないユーザのために、第三者機関がセキュリティ・ポリシーを作成できるようにする必要がある。図２０を用いて、これらの関係について説明する。
図２０において、ソフトウェア作成は、ポット・ファイル１５１４としてポット・ファイル作成サイト１５１０で作成される。ソフトウェア作者は、ソフトウェアの配布前にあらかじめ認証局（認証登録サイト１５３０）にソフトウェア・ポット１５１４を登録する。この登録は、ソフトウェア・ポットのダイジェスト（ｄｉｇｅｓｔ）をとり、ダイジェスト１５３２とポット情報１５３４を認証局に登録しておけばよい。
また、このソフトウェアに対するセキュリティ・ポリシーを作成した作成者（図２０のセキュリティ・ポリシー・サイト１５２０参照）は、セキュリティ・ポリシー，対象ソフトウェア等を認証局１５３０に登録する。ソフトウェア・ポットのユーザは、そのソフトウェア・ポットのダイジェストを生成し、そのダイジェストを認証局に送って、それをキーとして登録されているセキュリティ・ポリシーを検索する（図２０のユーザ・サイト１５４０参照）。複数登録されている場合は、その中からもっとも自分にふさわしいものを選択入手する。ソフトウェア作成者，認証局，検査コード提供者，利用者が全く独立の組織である必要はなく、それらの二つ以上の組み合わせが同一組織であってもよい。
これらの処理について、図２１〜図２９を用いて詳しく説明する。
（ポット・ファイル登録）
図２０におけるポット・ファイル作成サイト１５１０と認証登録サイト１５３０におけるポット・ファイルの登録について、図２１，図２２を用いて説明する。
図２１において、ポット・ファイル作成者は、まず、登録対象となるポット・ファイルを指定して、そのダイジェストを例えばＭＤ５等のハッシュ値計算アルゴリズムを用いて計算する（Ｓ１６１２）。図２２（ａ）に示した送信ボタン１６３６を押下して、計算したポット・ファイルのダイジェスト（ハッシュ値）を送信内容１６３２に表示されているポット・ファイルの属性（作成者、内容等）と共に、登録のために認証登録サイト１５３０へ送る（Ｓ１６１４）。認証登録サイト１５３０では、ダイジェスト（ハッシュ値）と属性情報を受け取り、ハッシュ値をキーとしたテーブル１５３２，１５３４に登録する（Ｓ１６１６）。そして、ファイル作成サイト１５１０に登録が成功したことを通知する（Ｓ１６１８）。ポット作成者は、登録完了を図２２（ｂ）の画面１６４０で知ることができる（Ｓ１６２０）。
（セキュリティ・ポリシー登録）
図２０におけるセキュリティ・ポリシー・サイト１５２０と認証登録サイト１５３０の間におけるセキュリティー・ポリシーの登録について、図２３〜図２５を用いて説明する。
まず、入手したポット・ファイルに対するセキュリティ・ポリシーを作成した作成者は、作成したセキュリティ・ポリシーの登録のために、そのポット・ファイルのダイジェストであるハッシュ値を、例えばＭＤ５等のアルゴリズムを用いて計算する（Ｓ１７１２，Ｓ１７１４）。図２４（ａ）の画面１７４０の送信ボタン１７４６を押下することで、求めたダイジェスト（ハッシュ値）１７４２を認証と検索のために認証サイト１５３０へ送る（Ｓ１７１６）。認証サイト１５３０では、ハッシュ値を受け取る（Ｓ１７１８）と、これをキーとして検索を行い、ポット・ファイルの情報を得る（Ｓ１７２０）。得られた場合は入手したポット・ファイルが認証されたことになる。求めたポット・ファイルの属性情報をセキュリティ・ポリシー・サイト１５２０に送信する。ポット・ファイルが見つからない場合はその旨をサイト１５２０に送信する（Ｓ１７２２）。図２４（ｂ）に示すような画面を用いて、受信したポット・ファイルの属性情報をユーザに提示する（Ｓ１７２６）。ポット・ファイルの属性情報でポット・ファイルの認証を確認したユーザは、作成したセキュリティ・ポリシーを登録する。この登録には、図２５（ｃ）の画面１７６０のラジオボタン１７６４で、セキュリティ・ポリシーの実体か、又はセキュリティ・ポリシー・サイト１５２０のＵＲＬかを選択して、認証サイト１５３０に送ることで行う（Ｓ１７２８）。
受け取った認証サイト１５３０は、送られたセキュリティ・ポリシーの実体（ファイル）又はＵＲＬをポット・ファイルに対応するように登録して（Ｓ１７３０）、登録終了を図２５（ｄ）に示す画面１７７０で通知する（Ｓ１７３２）。ユーザはこの画面１７７０を見て、登録を確認する（Ｓ１７３４）。
（セキュリティ・ポリシーのダウンロード）
図２０におけるユーザ・サイト１５４０と認証登録サイト１５３０の間におけるポット・ファイルの認証と、これに対応するセキュリティー・ポリシーのダウンロードについて、図２６〜図２９を用いて説明する。
ユーザは、ポット・ファイルをメール，Ｗｅｂ，ＣＤ−ＲＯＭ等により入手する（Ｓ１８１２）。これを実行するためには、このファイルが例えばウィルス等に汚染されていないか等の認証を得ることと、セキュリティ・ポリシーを得る必要がある。このため、まず、入手したポット・ファイルのダイジェスト（ハッシュ値）を例えばＭＤ５等により得る（Ｓ１８１４）。図２７（ａ）の画面１８４０の送信ボタン１８４６を押下することで、このダイジェスト（ハッシュ値）を認証登録サイト１５３０に送信して、ポット・ファイルの認証を行う（Ｓ１８１６）。認証登録サイト１５３０は、ポット・ファイルのダイジェスト（ハッシュ値）を受け取り（Ｓ１８１８）、このハッシュ値をキーとして登録ファイルを検索する（Ｓ１８２０）。ポット・ファイルの検索が成功した場合、認証されたことになり、検索されたポット・ファイルの属性情報および登録されているセキュリティ・ポリシー・ファイルの属性情報をユーザ・サイト１５４０に送る（Ｓ１８２２）。見つからない場合は、その旨をユーザ・サイト１５４０に送る（Ｓ１８２２）。
ユーザ・サイト１５４０では、図２７（ｂ）の画面例１８５０のように受け取ったファイル属性情報１８５２を表示する（Ｓ１８２４）。これでポット・ファイルの認証が完了したので、次に、このポット・ファイルを安全に実行するためのセキュリティ・ポリシーをダウンロードする。セキュリティ・ポリシーは複数登録されているので、例えば、図２８（ｃ）の画面１８６０のラジオボタン１８６２のように、安全性の面から選択して（Ｓ１８２６）、この選択を認証サイト１５３０に送信する（Ｓ１８２８）。これを受けた認証サイト１５３０は、セキュリティ・ポリシーの実体かＵＲＬをユーザ・サイト１５４０へ送る（Ｓ１８３０）。ユーザ・サイトでは、セキュリティ・ポリシーを受け取る。ＵＲＬの場合は、そのＵＲＬのサイトにアクセスして、セキュリティ・ポリシーをダウンロードする（Ｓ１８３２）。これで、図２９（ｅ）の画面例１８８０に示す実行ボタン１８８６を押下して、入手したポット・ファイルを、セキュリティ・ポリシーを用いて安全に実行することができる（Ｓ１８３４）。
＜実施例＞
ソラリス５．６（Ｓｏｌａｒｉｓ５．６）オペレーティング・システム上に、前に記述した実装スキームを基礎としてソフトウェア・ポットを実装した（表１参照）。約５０００行のＣプログラム・コードが実装に必要であった。ここでは、実装した実施例の結果を説明する。ハードウエア・プラットフォームは、Ｓｕｎ  Ｕｌｔｒａ  ６０ワークステーション（ＣＰＵ：ＵｌｔｒａＳＰＡＲＣ  ＩＩ，４ＭＢ  Ｃａｃｈｅ  Ｍｅｍｏｒｙ，５１２ＭＢ  ｍａｉｎ  ｍｅｍｏｒｙ，３６ＧＢ  ｈａｒｄ  ｄｉｓｃ）である。
2003050662.tif 000004
３つのマイクロベンチマーク・プログラムが書かれ、ソフトウェア・ポットあり、なしでのこれらのプログラムの実行時間を比較することで、システム・コールに課したオーバーヘッドを特定した。ベンチマーク・プログラムは以下のものである。
（１）Ｆｉｂ
このプログラムは、フィボナッチ数を計算する。計算中はシステム・コールを呼び出さない。
（２）ｇｅｔｐｉｄ−ｃａｌｌｅｒ
このプログラムは、″ｇｅｔｐｉｄ″システム・コールを、メインループで繰り返し（１０００万回）呼び出すが、他のシステム・コールを呼び出さない。
（３）ｏｐｅｎ−ｃａｌｌｅｒ
このプログラムは、同じファイルを開き（ｏｐｅｎ）、すぐに閉じる（ｃｌｏｓｅ）処理を繰り返す。これはパス名システム・コールを多数回呼び出す。オープン・システム・コールとクローズ・システム・コールの対を１万回実行する。
イーガー抽出モードをこの実施例の実行では用いた。上述のプログラムにおけるファイル抽出時間は大変小さく、示す結果には含まれない。実施例の実行結果は表２で示す。
2003050662.tif 000005
表２において、Ｆｉｂの動作は、ソフトウェア・ポットで実行しているかどうかにより影響を受けない。これは大変自然であり、ソフトウェア・ポットにおけるモニタ・プロセスは、システム・コールのみを横取りしているからである。
″ｇｅｔｐｉｄ−ｃａｌｌｅｒ″では、ソフトウェア・ポットで実行したとき遅くなっている。これは予期しない結果である。なぜなら、″ｇｅｔｐｉｄ″はパス名システム・コールではなく、この呼び出しは横取りされないからである。システム・コールが横取りされるように構成されると、オーバーヘッドが全てのシステム・コールに追加されると思われる。″ｏｐｅｎ−ｃａｌｌｅｒ″ベンチマークは、ソフトウェア・ポットで１桁遅くなる（全ての実行時間での差は８，２４６ミリ秒であった）。″ｏｐｅｎ−ｃａｌｌｅｒ″は″ｏｐｅｎ″を１万回呼び出すので、各″ｏｐｅｎ″に対するペナルティは、０．８ミリ秒である。ソフトウェアが実行する、１つのパス名システム・コールを横取りするときの処理の量はシステム・コールの種類によらないので、同じペナルティが全てのパス名システム・コールに対して課せられている。
＜ファイルのアクセス制御機能＞
上述したように、本発明のソフトウェア安全実行システムによれば、ソフトウェアをポット・ファイル内に隔離した状態で、安全性を検証しながら実行することができる。これにより、ソフトウェアの導入時および実行時に悪意のある動作や誤動作が発生した場合でも、ユーザの計算機資源などの安全性を確保することができる。
また、本発明のシステムでは、ファイルを流通させる際に、ファイルの獲得法や生成法などを動的に定める機能を提供している。これにより、ファイルをソフトウェア・ポットに格納する際に、ファイルの実体そのものを格納するだけでなく、ファイルの所在場所もしくはファイルの動的獲得法を格納しておき、実行時にファイルを獲得することを、アプリケーションに透明に（すなわち、アプリケーションに意識させずに）実現している。
しかしながら、従来のファイル流通における他の問題として、特定のユーザに対してファイルへのアクセス権（読み出し権・書き込み権）を与えることを、アプリケーションに透明に実現することができていないという問題がある。
この問題を解決するために、本発明のソフトウェア安全実行システムには、さらにファイルのアクセス制御機能を追加することができる。ファイルのアクセス制御機能とは、あらかじめ定められたユーザに対してのみ、ファイルの読み出しおよびファイルへの書き込みを許可する機能である。この機能は、次の（１）および（２）を行なうことにより実現される。
（１）ファイル・ポット作成時のカプセル化処理において、カプセル化の規定にアクセス制御の規定を記述する。
（２）暗号技術を用いてファイル実体や鍵などを暗号化・復号化する。
以降、まず（１）について説明し、次に（２）について説明する。
（１）アクセス制御の規定の記述
上述の＜ソフトウェア・ポット（ＳｏｆｔｗａｒｅＰｏｔ）：ＳＳＣモデルの実装例＞の「（１）カプセル化処理」の項で説明したように、カプセル化処理は、カプセル化対象として規定されたファイルを集めて、これらのファイルをポット・ファイル中に格納することで実装される。上述では、図１３を用いてカプセル化の規定の例を説明した。
図１３に示すカプセル化の規定にアクセス制御の規定を付加した例を、図３０に示す。図３０において、アクセス制御の規定を付加した記述例は、６１８（静的ファイル・セクション６１０の第４行から第６行）および６２８（動的ファイル・セクション６２０の第４行から第６行）に示されている。なお、行末の記号″￥″は、記述が次の行に続いていることを示す記号である。
図３０の６１８において、１行目は、上述で図１３を用いて説明したとおり、ローカル・ファイルである静的ファイル／ｈｏｍｅ／ｕｓｅｒ１／ｐｉｃｔｕｒｅ／ｐｉｃＣ．ｊｐｇが、ポット・ファイル中に／ｄａｔａ／ｐｉｃ３．ｊｐｇのパス名で格納されることを規定している。そして、続く２行目・３行目でこのファイルのアクセス制御を規定している。２行目のｒｅａｄ＝｛ｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍ，ｙｏｓｈ＠ｂａｎａｎａ．ｃｏｍ｝は、このファイルの読み出し権をｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍとｙｏｓｈ＠ｂａｎａｎａ．ｃｏｍに与えることを示している。また、３行目のｗｒｉｔｅ＝｛ｋａｔｏ＠ｏｒａｇｎｅ．ｃｏｍ｝は、このファイルへの書き込み権をｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍに与えることを示している。
同様に、図３０の６２８において、１行目は、上述で図１３を用いて説明したとおり、動的ファイル／ｍｙｂｉｎ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ３のファイルは、ＵＲＬのｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎ３で規定される位置から得るべきであることを規定している。そして、続く２行目・３行目でこのファイルのアクセス制御を規定している。２行目のｒｅａｄ＝｛ｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍ，ｙｏｓｈ＠ｂａｎａｎａ．ｃｏｍ｝は、このファイルの読み出し権をｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍとｙｏｓｈ＠ｂａｎａｎａ．ｃｏｍに与えることを示している。また、３行目のｗｒｉｔｅ＝｛ｋａｔｏ＠ｏｒａｇｎｅ．ｃｏｍ｝は、このファイルへの書き込み権をｋａｔｏ＠ｏｒａｎｇｅ．ｃｏｍに与えることを示している。
なお、図３０において、″ｈｙｂｒｉｄ：″６６２で示している混合ファイル・セクション６６０は、混合ファイルに関する規定の例である。混合ファイルとは、静的ファイルと動的ファイルの機能を合わせたものである。混合ファイルでは、ファイル実体の獲得として、静的ファイルに対応するものを一つ、動的ファイルに対応するものを一つまたは複数、指定する。ポット・ファイル作成時には、指定された静的ファイルに対応するファイル実体獲得に基づき、ファイル実体がポット・ファイルに格納される。そして、ポット・ファイル使用時には、指定された動的ファイルに対応するファイル実体獲得に基づき、ファイル実体の獲得を試みる。なお、動的ファイルに対応するファイル実体獲得法が複数ある場合は、優先度（例えば、記述されている順番に優先度が高いものとする）の順に従う。ファイル実体の獲得の試みが成功しないときは、静的ファイルとして格納されたファイル実体が使用される。
混合ファイル・セクション６６０の２行目から４行目に示す６６４は、動的ファイルとして″ｄｙｎａｍｉｃ＝″で指定したｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎＡ＿１とｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎＡ＿２の二つのファイル（左側に指定したものほど、優先度が高いとする）が、静的ファイルとして″ｓｔａｔｉｃ＝″で指定したファイルｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎＡ＿１が、混合ファイル／ｍｙｂｉｎ／ｖｉｅｗｅｒ＿ｐｌｕｇｉｎＡとして登録される。
なお、図３０において上述で説明した以外の規定については、図１３と同様である。
（２）暗号技術を用いたアクセス制御
上述の（１）に示すようにアクセス制御の規定を記述することで、ポット・ファイルの作成者は、ファイル実体の読み出し権および書き込み権を持つユーザを指定することができる。ここで指定されたアクセス制御は、暗号技術を利用して実現される。
以降、図３１〜図３３を参照しながら、暗号技術を利用したアクセス制御について説明する。なお、本発明では、アクセス制御の実現に際し以下の二点を仮定しているものとする。
・ＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ；公開鍵暗号系基盤）を利用可能である。すなわち、指定されたユーザの正しい公開鍵を入手することができ、各ユーザは個々の公開鍵に対応する秘密鍵の秘密性を護持している。
・暗号化アルゴリズムは、特に断りがないときは、ＲＳＡアルゴリズムに代表される既存の公開鍵アルゴリズムを使用する。
本発明では、アクセス制御を実現するために、以下の方法１〜方法３に示す三つの方法を用いる。
方法１：単純公開鍵法によるアクセス制御
方法２：秘密鍵法によるアクセス制御
方法３：公開鍵技術を用いたｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御
以降、これらの三つの方法をそれぞれ順に説明する。
（方法１：単純公開鍵法によるアクセス制御）
方法１は、読み出し権のみを指定する場合に使用可能な方法である。方法１の単純公開鍵法によるアクセス制御の例を、図３１に示す。
図３１において、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権を、ユーザＡ（１９７２）、ユーザＢ（１９７４）、ユーザＣ（１９７６）に与えるものとする。
この場合、ファイル実体Ｆ（１９１０）はユーザＡ，Ｂ，Ｃの公開鍵を用いて暗号化され、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３１はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、ユーザＡの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３２）、ユーザＢの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３４）、ユーザＣの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３６）が、ポット・ファイル１９２０に格納される。
そして、各ユーザがポット・ファイル１９２０を使用する際、ファイル実体Ｆは各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されているファイル実体Ｆ（１９３２）が、ユーザＡの秘密鍵を用いて復号化される。この復号化により、各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。一方、読み出し権を与えられていないユーザは復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。
（方法２：秘密鍵法によるアクセス制御）
上述の方法１は、読み出し権を与えるユーザの数だけファイル実体を暗号化する必要があるため、大きな格納領域を必要とする場合がある。方法２は、方法１を改良したものであり、暗号化されたファイル実体の数を減らすことにより格納領域を節約することができる方法である。
方法２は、方法１と同様、読み出し権のみを指定する場合に使用可能な方法である。方法２の秘密鍵法によるアクセス制御の例を、図３２に示す。
図３２においては、方法１と同様に、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権を、ユーザＡ（１９７２）、ユーザＢ（１９７４）、ユーザＣ（１９７６）に与えるものとする。
この場合、まず、秘密鍵暗号アルゴリズム（例えばＤＥＳアルゴリズムなど）用の秘密鍵Ｋ（１９４０）が生成され、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いてファイル実体Ｆ（１９１０）が暗号化される。次に、秘密鍵ＫがユーザＡ，Ｂ，Ｃの公開鍵を用いて暗号化される。これらの暗号化されたファイルは、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３２はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いて暗号化されたファイル実体Ｆ（１９３０）、ユーザＡの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４２）、ユーザＢの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４４）、ユーザＣの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４６）が、ポット・ファイル１９２０に格納される。
そして、各ユーザがポット・ファイル１９２０を使用する際、まず、秘密鍵Ｋが各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されている秘密鍵Ｋ（１９４２）が、ユーザＡの秘密鍵を用いて復号化される。次に、秘密鍵Ｋを用いて暗号化されているファイル実体Ｆ（１９３０）が、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いて復号化される。この復号化により、各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。一方、読み出し権を与えられていないユーザは秘密鍵Ｋの復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。
（方法３：公開鍵技術を用いたｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御）  方法３は、一つのファイルについて、読み出し権のみを指定する場合にも、読み出し権と書き込み権の両方を指定する場合にも使用可能な方法である。方法３のｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御の例を、図３３に示す。
図３３において、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権および書き込み権を、ユーザＡ（１９７２）とユーザＢ（１９７４）に、読み出し権のみをユーザＣ（１９７６）に与えるものとする。
この場合、まず、ファイル実体Ｆ（１９１０）に対して公開鍵アルゴリズム用の公開鍵・秘密鍵のペアが一組生成され、一方がｒｅａｄ鍵（１９５０）、他方がｗｒｉｔｅ鍵（１９６０）とされる。次に、ｗｒｉｔｅ鍵を用いてファイル実体Ｆ（１９１０）が暗号化される。そしてｗｒｉｔｅ鍵は、書き込み権を与えるユーザ（Ａ，Ｂ）の公開鍵を用いて暗号化される。一方、ｒｅａｄ鍵は、読み出し権を与えるユーザ（Ａ，Ｂ，Ｃ）の公開鍵を用いて暗号化される。これらの暗号化されたファイルは、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３３はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、ｗｒｉｔｅ鍵を用いて暗号化されたファイル実体Ｆ（１９３０）、ユーザＡの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５２）およびｗｒｉｔｅ鍵（１９６２）、ユーザＢの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５４）およびｗｒｉｔｅ鍵（１９６４）、ユーザＣの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５６）が、ポット・ファイル１９２０に格納される。
そして、読み出し権を与えられている各ユーザ（Ａ，Ｂ，Ｃ）がポット・ファイル１９２０を使用する際、まず、ｒｅａｄ鍵が各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されているｒｅａｄ鍵（１９５２）が、ユーザＡの秘密鍵を用いて復号化される。次に、ｗｒｉｔｅ鍵を用いて暗号化されているファイル実体Ｆ（１９３０）が、ｒｅａｄ鍵を用いて復号化される。この復号化により、読み出し権を与えられている各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。
また、書き込み権を与えられている各ユーザ（Ａ，Ｂ）がファイル実体Ｆへの書き込みを行なう場合には、まず、ｗｒｉｔｅ鍵が各ユーザの秘密鍵を用いて復号化される。そして、書き込み後のファイル実体Ｆは、ｗｒｉｔｅ鍵を用いて暗号化される。
読み出し権を与えられていないユーザはｒｅａｄ鍵の復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。また、書き込み権を与えられていないユーザはｗｒｉｔｅ鍵の復号化を行なえないため、ソフトウェア・ポット・システムによって書き込み権がないことを検出される。たとえソフトウェア・ポット・システムを不正に操作して書き込みを行なおうとしても、ファイル実体Ｆの暗号化を正しく行なえないために、不正な書き込みは読み出し権を与えられたユーザによって検出される。
（ファイルのアクセス制御機能の効果）
上述のアクセス制御機能を用いることにより、特定のユーザに対してファイルへのアクセス権（読み出し権・書き込み権）を与えることを、アプリケーションに透明に（すなわち、アプリケーションに意識させずに）実現することができる。
さらに、上述のアクセス制御機能は暗号技術を用いているため、仮にアクセス権を与えられていないユーザが不当にソフトウェア・ポット・システム自体の改変を行なったとしても、改変されていない他のソフトウェア・ポット・システムは正しくアクセス制御を行なうことができる（すなわち、読み出し／書き込み権をもつユーザのみが読み出し／書き込みを行なえる）。
また、上述の方法３によれば、仮に不正な書き込み（改変）を行なったファイルを流通させようとしても、正常なソフトウェア・ポット・システムがその改変を検知することができる。すなわち、アクセス権のないユーザが不正な書き込み（改変）を行なったファイルを流通させようとした場合、そのファイルを読み出し権を与えられたユーザが読み出す際に、不正な改変が検知される。
また、ポット・ファイルの作成者が、アドホックにユーザグループを構成し、そのユーザグループ内でアクセス制御を設けたグループウェア処理を行なうことができる。このとき、既存のシングルユーザ用アプリケーション自体に全く手を加える事なく、グループウェア処理を行なうことができる。
産業上の利用の可能性
上述したような構成により、ソフトウェア流通に適した、安全にソフトウェアを実行する機構を提供することができる。
【図面の簡単な説明】
図１は、ソフトウェア流通の４つの基本処理を示す図である。
図２は、ソフトウェア配布を示す図である。
図３は、自己解凍の転送を示す図である。
図４は、ワークフローを示す図である。
図５は、モバイル・エージェントを示す図である。
図６は、実施形態の安全なソフトウェア流通の４つの基本処理を示す図である。
図７は、典型的なソフトウェア流通モデルを示す図である。
図８は、ディレクトリ等のマッピングを示す図である。
図９は、ダウンロードされたコードの解釈実行を示す図である。
図１０は、動的に生成されたコードの実行を示す図である。
図１１は、モバイル・エージェントの実行を示す図である。
図１２は、ワークフローの処理を示す図である。
図１３は、カプセル化の規定の例を示している。
図１４は、動的ファイル転送を示す図である。
図１５は、ファイル構成を示す図である。
図１６は、実装スキームの例を示す図である。
図１７は、マッピングおよび実行の規定例を示す図である。
図１８は、名前変換の実装例を示す図である。
図１９は、モニタのフォークの実装例を示す図である。
図２０は、安全なソフトウェア流通形態を示す図である。
図２１は、ファイル登録の処理を示すフローチャートである。
図２２は、ファイル登録処理における画面例を示す図である。
図２３は、セキュリティ・ポリシーの登録処理を示すフローチャートである。
図２４は、セキュリティ・ポリシー登録処理画面を示す図である。
図２５は、セキュリティ・ポリシー登録処理画面を示す図である。
図２６は、ファイル検索の処理を示すフローチャートである。
図２７は、ファイル検索の処理画面を示す図である。
図２８は、ファイル検索の処理画面を示す図である。
図２９は、ファイル検索の処理画面を示す図である。
図３０は、カプセル化の規定にアクセス制御を指定する例を示している。
図３１は、単純公開鍵法によるアクセス制御の例を示す図である。
図３２は、秘密鍵法によるアクセス制御の例を示す図である。
図３３は、ｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御の例を示す図である。
【図１】
2003050662.tif 000006
【図２】
2003050662.tif 000007
【図３】
2003050662.tif 000008
【図４】
2003050662.tif 000009
【図５】
2003050662.tif 000010
【図６】
2003050662.tif 000011
【図７】
2003050662.tif 000012
【図８】
2003050662.tif 000013
【図９】
2003050662.tif 000014
【図１０】
2003050662.tif 000015
【図１１】
2003050662.tif 000016
【図１２】
2003050662.tif 000017
【図１３】
2003050662.tif 000018
【図１４】
2003050662.tif 000019
【図１５】
2003050662.tif 000020
【図１６】
2003050662.tif 000021
【図１７】
2003050662.tif 000022
【図１８】
2003050662.tif 000023
【図１９】
2003050662.tif 000024
【図２０】
2003050662.tif 000025
【図２１】
2003050662.tif 000026
【図２２】
2003050662.tif 000027
【図２３】
2003050662.tif 000028
【図２４】
2003050662.tif 000029
【図２５】
2003050662.tif 000030
【図２６】
2003050662.tif 000031
【図２７】
2003050662.tif 000032
【図２８】
2003050662.tif 000033
【図２９】
2003050662.tif 000034
【図３０】
2003050662.tif 000035
【図３１】
2003050662.tif 000036
【図３２】
2003050662.tif 000037
【図３３】
2003050662.tif 000038
【手続補正書】
【提出日】平成15年9月4日(2003.9.4)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソフトウェアを安全に実行可能とするソフトウェア安全実行システムであって、
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットと、
前記ファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段と
を備え、
実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするソフトウェア安全実行システム。
【請求項２】
請求項１に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行前に、前記ファイル格納部から実行するシステムにファイルを抽出する
ことを特徴とするソフトウェア安全実行システム。
【請求項３】
請求項１に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行中の必要とされたときに、前記ファイル格納部から実行するシステムにファイルを抽出する
ことを特徴とするソフトウェア安全実行システム。
【請求項４】
請求項１〜３のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、最初に起動する実行ファイル名を格納できることを特徴とするソフトウェア安全実行システム。
【請求項５】
請求項１〜４のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、前記ファイル格納部内のファイル以外のファイル名を格納しており、
前記マッピング手段は、該ファイル名を、実行するシステムのファイル及び／又は他のポットのファイルにマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項６】
請求項１〜５のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、ディレクトリ名を格納でき、
前記マッピング手段は、該ディレクトリ名を、実行するシステムのディレクトリ及び／又は他のポットのディレクトリにマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項７】
請求項６に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、前記ディレクトリ名に対して、複数のディレクトリと定まった順番で対応させ、その順に該ディレクトリ内のファイルとマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項８】
請求項１〜７のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、ネット上のサイトのファイル名を格納でき、
前記マッピング手段は、サイトから該ファイル名のファイルを実行するシステムに転送する
ことを特徴とするソフトウェア安全実行システム。
【請求項９】
請求項１〜８のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスをファイルとしてマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１０】
請求項１〜９のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスが作成したファイルとマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１１】
請求項１〜１０のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、実行するシステム内のセキュリティ・ポリシーの規定に従ってマッピングを行う
ことを特徴とするソフトウェア安全実行システム。
【請求項１２】
請求項１１に記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定には、実行中に発行できるシステム・コールの規定が含まれる
ことを特徴とするソフトウェア安全実行システム。
【請求項１３】
請求項１１又は１２に記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定は、ネット上の他のサイトからダウンロードできる
ことを特徴とするソフトウェア安全実行システム。
【請求項１４】
請求項１〜１３に記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、ユーザごとのファイルへのアクセス権の規定を格納でき、
前記マッピング手段は、前記アクセス権の規定により、ファイルへのアクセスを制御する
ことを特徴とするソフトウェア安全実行システム。
【請求項１５】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとの読み出し権の鍵で、ファイルを復号化して読み出す
ことを特徴とするソフトウェア安全実行システム。
【請求項１６】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、読み出し権の鍵を復号化し、復号化した鍵を用いてファイルを復号化して読み出す
ことを特徴とするソフトウェア安全実行システム。
【請求項１７】
請求項１４に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、公開鍵−秘密鍵のペアである読み出し権および書き込み権の鍵を復号化し、復号化した鍵を用いてファイルを復号化または暗号化する
ことを特徴とするソフトウェア安全実行システム。
【請求項１８】
ポット情報とセキュリティ・ポリシー情報とを格納したサーバー・システムであって、
ポット情報と、前記ポット情報に対応したセキュリティ・ポリシー規定を格納したデータベースと、
前記セキュリティ・ポリシーをポットを特定して検索できる検索手段と
を備えることを特徴とするサーバ・システム。
【請求項１９】
削除
【請求項２０】
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムを記録する記録媒体であって、
該プログラムを実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするプログラムを記録する記録媒体。
【請求項２１】
実行ファイルを含む、使用するファイルのファイル名を格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムであって、
該プログラムを実行したときに、前記マッピング手段により、アクセスできるファイルを前記ポット中のファイル名格納部に記述したもののみに制限することを特徴とするプログラム。
【国際調査報告】
2003050662.tif 000039
2003050662.tif 000040