(57)【要約】セキュアな移動体無線装置であって、前記装置にインストールされるべきネイティブで実行可能なコードには、前記装置上のアクセス可能な保護されたリソースを定義するケーパビリティのセットが割り当てられている。よって、本発明は、（マルチユーザ・システムでは、異なるユーザのケーパビリティ又はアクセス特権を定義するものとして知られている）ケーパビリティのアイデアを採用し、セキュアな、シングルユーザ用の移動体無線装置のために、異なるネイティブな実行可能なコードについてのケーパビリティ又はアクセス特権の定義に該アイデアを適用する。
2005528051.tif 000002
【特許請求の範囲】
【請求項１】
シングルユーザ用のセキュアな移動体無線装置であって、前記装置にインストールされるべきネイティブで実行可能なコードに、前記装置上のアクセス可能な保護されたリソースを定義するケーパビリティのセットが割り当てられていることを特徴とする装置。
【請求項２】
前記ケーパビリティは、特定のＡＰＩ（又は複数のＡＰＩの範囲）、ファイル又は他のオペレーティングシステムの保護されたリソースへのアクセスを許可することを特徴とする請求項１に記載の装置。
【請求項３】
前記実行可能なコードは、インストール時に許可された前記ケーパビリティを含むことを特徴とする請求項１に記載の装置。
【請求項４】
前記実行可能なコードは、前記実行可能なコードに割り当てられたケーパビリティのインテグリティを維持するために前記トラステッド・コンピューティング・ベースのみがアクセス可能な前記装置のメモリの所定の位置に不変に格納されていることを特徴とする請求項３に記載の装置。
【請求項５】
前記ローダーは、前記システムのインテグリティを維持するために、トラステッド・コンピューティング・ベースのみがアクセス可能な前記装置のメモリの所定の位置に不変に格納されていない実行可能なコードのロードを拒否することを特徴とする請求項４に記載の装置。
【請求項６】
強制的で、オペレーティングシステムカーネル、ファイルシステム及びシステムデータへのアクセスを制御するシステムケーパビリティを有する請求項１に記載の装置。
【請求項７】
前記装置内におけるクライアント−サーバ通信のそれぞれについて、前記装置のカーネルが前記クライアントのケーパビリティを前記サーバーへ送出することを特徴とする請求項１に記載の装置。
【請求項８】
前記ローダーは、実行可能なコードにロードされるべきライブラリのそれぞれについて、該ライブラリを要求している実行可能なコードについて許可されたケーパビリティの上位集合が割り当てられていることを検証することを特徴とする請求項１に記載の装置。
【請求項９】
前記ケーパビリティが、ルートケーパビリティ、システムケーパビリティ及びユーザに公表されるケーパビリティを備えるケーパビリティのリストから選択されることを特徴とする請求項１に記載の装置。
【請求項１０】
前記ユーザに公表されるケーパビリティは、
（ａ）電話ネットワークを利用して加入者のお金を消費する、
（ｂ）ユーザのプライベート情報をリードする、
（ｃ）ユーザのプライベート情報を修正する、
（ｄ）加入者のお金を消費することなくローカルネットワークに情報を送信する、
（ｅ）前記装置の位置を把握する、
機能を可能とすることを特徴とする請求項９に記載の装置。
【請求項１１】
セキュアな移動体無線装置において動作するソフトウェア・アプリケーションであって、前記アプリケーションには、前記装置上のアクセス可能な保護されたリソースを定義する幾つかのケーパビリティが割り当てられていることを特徴とする。
【請求項１２】
セキュアな移動体無線装置において動作するオペレーションシステムであって、前記オペレーティングシステムは、アクセス可能な保護されたリソースを定義する幾つかのケーパビリティが割り当てられるべき注意を要するリソースへのアクセスを要求する、ネイティブで実行可能なコードを要求することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セキュアな移動体無線装置（a secure mobile wireless device,以下同様）に関する。キー・オペレーティング・システム・リソースへの悪意あるアクセスを防止する、移動体無線装置に対するプラットフォーム・セキュリティ(platform security)についての新しいアプローチに関する。
【背景技術】
【０００２】
プラットフォーム・セキュリティは、悪意ある又は下手に書かれたコード（malicious or badly written code）に対するプラットフォーム防護メカニズムの思想、構造、実装をカバーするものである。これらの防護メカニズムにより、そのようなコードが害をもたらすことを妨げることができる。悪意あるコードは一般に２つの要素を有する。それは、ダメージを与えるペイロードメカニズム（payload mechanism）と、それを拡散する手助けをする拡散メカニズム（propagation mechanism）である。これらは通常、以下のように分類される。
【０００３】
トロイの木馬（Trojan horse）：良性でユーザにとって魅力的に出現する正規のアプリケーション(legitimate application that appears benign and attrative to the user)を有する。
ワーム（Ｗｏｒｍ）：その提供者、あるいはユーザによる更なるマニュアル操作によらず複製され、拡散する。
ウィルス（Ｖｉｒｕｓ）：正規のプログラムに侵入し、データを変更、或いは破壊する。
【０００４】
セキュリティの脅威は、（ａ）サービスやデータの守秘性(confidentiality)、インテグリティ（integrity：完全性）又は、利用可能性(availability)を連鎖的に損なう潜在性や、（ｂ）サービス機能の妥協を包含している。このような脅威は以下のように分類される。
【０００５】
１．データの守秘性及びインテグリティに関する脅威。例えば、ユーザのパスワードを入手したり、ファイルを破壊したりする。
２．サービスの守秘性及びインテグリティに関する脅威。例えば、電話ネットワークの加入者の帯域を無料で利用したり、ネットワーク・サービス・プロバイダとのトランザクションを無効化したりする。
３．サービスの利用可能性に関する脅威（又は、サービスの拒否とも呼ばれる）。例えば、ユーザがテキストメッセージを送信することを妨げたり、電話の着信を受けることを妨げたりする。
【０００６】
このように、移動体無線装置は、セキュリティ構造の設計者に対して相当数の課題を突きつけるものである。従来のアプローチは典型的に、まずコード（例えば、あるアプリケーション）がインストールするのに十分に信頼に値するかどうかを決定し、一旦インストールされると、逸脱した振る舞いからプラットフォームを保護することによりなされていた。信頼に関する決定については、サードパーティ・アプリケーションは、その作者の信頼の程度に応じて分類することができる。そのような訳で、許容可能な認証機関（Certificate Authority:CA）によって発行された有効なデジタル証明書（digital certificate）を提示した場合にのみ、装置上への自動的インストールを許可することが知られている。
【０００７】
しかしながら、デジタル証明書（digital certificate）は広く行き渡り始めたばかりであり、それらが採用される前に、主なプラットフォーム・セキュリティ・メカニズムは、アプリケーションよりもユーザに特権（privileges）を与えることになっていた。実行時には（at run time）、ユーザによって実行されるコードは、その特権が全て認められる。インストール時には、指定されたユーザのみが注意を要する（sensitive）なソフトウェアをインストールすることができる。これは、潜在的に害のあるコードを、インストール前に専門の管理者によって厳しく審査することが可能であることを意味する。数多くの良く知られたオペレーティングシステム、例えばＵＮＩＸ（登録商標）ベースのオペレーティングシステムは、このアプローチをプラットフォーム・セキュリティについて採用している。
【０００８】
所定の異なるユーザの異なるアクセス特権に基づくプラットフォーム・セキュリティ(platform security based on giving different users different access privileges)は、簡単な理由により移動体無線装置には適さない。その理由は、このカテゴリーの製品は、シングルユーザ（single user）用途だからである。それは、個人的な装置であって、典型的には“スマートフォン（smartphone）”、高機能の移動体電話機（enhanced mobile telephone）、ＰＤＡ、或いは、他の個人用の携帯可能なコンピュータ装置である。更に、シングルユーザは、コンピュータ技術の専門家でないことが多く、ゆえに、インストールの危険を確実に見極めてコードを実行することは困難である。移動体無線装置について、プラットフォーム・セキュリティが扱おうとしている重要な脅威（key threats）は、ユーザデータ、システムサービス、特にフォンスタック（phone stack）への権原なきアクセスに関するのものである。フォンスタックは特に重要である。というのも、それは、電話ネットワークへの不変のデータ接続(permanently data connection)を制御するものであり、また、モバイルコマース（mobile commerce）、モバイルバンキング(mobile banking)などは、フォンスタックを利用して実行されるので、その制御を失えば、上記のように悪意のある或いは下手に書かれたコード(malicious or badly written code)によって、装置のオーナーが潜在的に経済的に重大なダメージに晒されることになる。
【０００９】
今までのところ、移動体無線装置の為のプラットフォーム・セキュリティについては効果的な提案はなされていない。
【００１０】
［発明の概要］
本発明の第１の側面においては、セキュアな移動体無線装置が提供される。該装置にインストールされるべきネイティブで実行可能なコード(native executable code)に、該装置上の保護されたアクセス可能なリソースを定義するケーパビリティのセットが割り当てられる。ネイティブコードは、装置上のＣＰＵによって直接実行される命令によって構成される。
【００１１】
第２の側面においては、セキュアな移動体無線装置で実行するために採用され、ネイティブコードで書かれたソフトウェアアプリケーションが提供され、該アプリケーションには、装置上の保護されたアクセス可能なリソースを定義するケーパビリティのセットが割り当てられる。
【００１２】
第３の側面においては、セキュアな移動体無線装置上で実行するために採用されるオペレーティングシステムが提供され、該オペレーティングシステムは、装置上の保護されたアクセス可能なリソースを定義するケーパビリティのセットが割り当てられるべき注意を要するリソース(sensitive resources)へのアクセスを要求する実行可能なコードを要求する。
【００１３】
このようにして、本発明は、（マルチユーザ・システムでは、異なるユーザのケーパビリティ又はアクセス特権を定義するものとして知られている）ケーパビリティのアイデアを採用し、セキュアな、シングルユーザ用の移動体無線装置のために、異なるネイティブな実行可能なコードについてのケーパビリティ又はアクセス特権の定義に該アイデアを適用する。
【００１４】
本発明は、ネイティブで実行可能なコードに適用される、ケーパビリティベースのアクセス制御の利用を通じた、重要なオペレーティングシステムサーバのファイアウォール防護として実現することができる。各ケーパビリティは、特定のAPI（または複数のAPIの範囲）、ファイルまたは他の適用可能なリソースへのアクセスを許可することができる。実行可能なコード（例えば、プログラム（EXEｓ））や共有されている静的または動的なライブラリ（DLLｓ）は、インストール時に許可されたケーパビリティを含む。実行可能なコードのそれぞれは、トラステッド・コンピューティング・ベース（カーネル、ローダー、ファイルサーバー及びソフトウェアインストーラ、[詳細な記述]におけるセクション１．１を参照のこと）のみがアクセス可能な場所に不変に(permanently)格納されており、当該実行可能なコードに割り当てられたケーパビリティのインテグリティを維持する。一旦実行可能なコードが呼び出されると、ローダーは当該実行可能なコードをロードし、新しいプロセスを生成するか、あるいは、既存のプロセスへライブラリをロードする。新しいプロセスを生成する場合、このプロセスのケーパビリティは、当該プログラムに対して許可されているケーパビリティと等価である。このケーパビリティのセットに基づいて、ローダーはどのライブラリを（新しい）プロセスにロードできるかを制御する。各クライアント−サーバー通信については、カーネルはクライアントのケーパビリティをサーバーへ送出するであろう。それゆえに、サーバーはクライアントのケーパビリティを完全に信用することができる。というのも、それらはサーバではなく、トラステッド・コンピューティング・ベースのプロセス部分、例えばカーネルによりによって送出／是認されるからである。サーバーは、呼を処理するか、あるいは拒否するかを決定することができる。
【００１５】
好ましくは、ケーパビリティモデルは、少数のケーパビリティに慎重に限定される。システムケーパビリティは、強制的なものであり、また、オペレーティングシステムカーネル、ファイルシステム及びシステムデータへのアクセスを制御する。それらは、トラステッド・コンピューティング・環境（または、TCE−[詳細な記述]のセクション１．２を参照）のインテグリティを保証する。それらが制御される方法は装置のユーザによっては修正されず、またそれらがユーザに公表されることはない。他の種類のケーパビリティは、平均的なユーザに、それらのいくつかが、彼らがインストールしたものをコード化すること許可するか否かを決定させるのに十分意味があるので（as they are meaningful enough to average users to let them decide whether or not to grant some of them to code they have installed）、任意のものである。これらのケーパビリティは、以下のように分類される。
【００１６】
ルート（強制的）"すべてのファイルに対するフルアクセス−実行可能なコードと関連付けられたケーパビリティを修正できる。"
トラステッド・コンピューティング・ベースによってのみ利用される。
【００１７】
システムケーパビリティ（強制的）
例えば、以下のように定義される。
WriteSystemDataは、コンフィギュレーション・システム・データを修正する処理を許可する。
CommDDは、すべての通信及びイーサネット（登録商標）カード装置ドライバへのアクセスを許可する。
【００１８】
ユーザに公表されるケーパビリティ（任意）
例えば、以下のように定義できる。
PhoneNetwork "電話ネットワークサービスにアクセス可能である（また、潜在的にユーザのお金を消費する。）。"
ReadeUserData  "装置のユーザのプライベート情報をリードできる。"
【００１９】
［詳細な記述］
本発明は、添付する図面を参照して以下に記述される。
【００２０】
本発明は、シングルユーザ無線装置のために設計されたオブジェクト指向のオペレーティングシステムであるシンビアンＯＳのセキュリティ構造を参照して記載される。シンビアン・オペレーティング・システムは、英国ロンドンのシンビアン・リミテッドにより移動体無線装置のために開発されたものである。
【００２１】
シンビアンＯＳにおけるセキュリティ構造の基本的な概要は、中世の城の防護（a medieval castle defences）に類似している。類似の形態において、インストール境界（installation perimeter）に加えて、簡単で、スタッガード構造の（staggered）セキュリティレイヤーを採用する。当該モデルが取り扱おうとしている重要な脅威は、ユーザーデータ及びシステムサービス、特にフォンスタック(phone stack)への権原のないアクセスと関連している。フォンスタックはスマートフォンと関連して特に重要である。というのも、フォンスタックが電話ネットワークとの不変のデータ接続(permanent data connection)を制御するからである。当該モデルの後ろに位置する重要なデザインドライバ（key design drivers）が二つある。
【００２２】
・その一つは、ケーパビリティベースのアクセス制御を利用した重要なシステムリソースのファイアウォール防護である。
【００２３】
・もう一つは、標準的なソフトウェアがアクセスできない、保護された部分をファイルシステムに生成するデータ分割（data partitioning）である。
【００２４】
以下に記載するケーパビリティモデルの主たるコンセプトは、ユーザが何ができるかではなく、プロセスに何ができるかを制御することにある。このアプローチは、ウィンドウズ（登録商標）ＮＴやＵｎｉｘ（登録商標）といった既知のオペレーティングシステムとは極めて異なるものである。その主な理由は、以下のようになる。
【００２５】
・シングルユーザ用途のシンビアンＯＳの性質。
・シンビアンＯＳは、独立したサーバープロセスを介してサービスを提供している。それらは常に動作しており、かつ、ユーザセッションに付加されることがない。電力が供給されている限り、シンビアンＯＳはユーザがログオンしていない場合であっても常に起動状態にある。
【００２６】
・シンビアンＯＳは、技術的知識の無い、多くの公衆に利用される装置において使用されることを目的としている。ソフトウェアのインストール時に、どんな許可をアプリケーションに対して与えるかを決定する能力をユーザが有していなくても良い。さらに、常に接続されている装置に関しては、誤った或いは悪意のある決定の結果は、装置自体よりもドメインに遙かに大きなインパクトを与えるかもしれない。
【００２７】
本発明の特徴点は、カーネルやローダー（the loader）から暗号の利用が故意に除外されていることである。実行可能なコード（executables）は署名されず、また、ケーパビリティは格納されたり、暗号化されたり、署名されたりしない。このことは、データ分割により、実行可能なコードについてセキュアな格納エリアが提供されるために可能となる。よって、（装置内にビルトインされた）ＲＯＭから実行可能なコードを、セキュリティやパフォーマンスの妥協無しに、（ユーザによりインストールされた）ＲＡＭからのコードと同様に扱うことが可能となる。それゆえに、このコードに割り当てられたケーパビリティに対しては、装置の製造コード（device manufacturer code）の誤用や搾取は制限される。
【００２８】
１  トラステッド・コンピューティング・プラットフォーム(Trusted Computing Platform)
１．１  トラステッド・コンピューティング・ベース(Trusted Computing Base)
トラステッド・コンピューティング・ベース（ＴＣＢ）は、ロバストなプラットフォーム・セキュリティに対する基本的な構造的要求(basic architectural requirement)である。トラステッド・コンピューティング・ベースは、サブバート（subverted）されない多くの構造的要素(architectural elements)から構成され、装置のインテグリティを保証する。このベースをできるだけ小さく維持すること、更には、システムサーバー及びアプリケーションが、それらが機能するのに必要としない特権を与えられる必要がないことを保証するために最小特権の原理（the principle of least privilege）を適用することは、重要である。クローズな装置では、ＴＣＢはカーネル、ローダー及びファイルサーバーから構成される。オープンな装置では、ソフトウェアインストーラーもまた必要とされる。これらの処理の全ては、システムワイド・トラステッド(system-wide trusted)であり、それゆえに装置へのフルアクセスを有する。この信用できるコードは、他のプラットフォームコード（セクション２．１を参照）が利用できない“ルート”ケーパビリティとともに実行される。
【００２９】
トラステッド・コンピューティング・ベースのインテグリティを維持するための他の重要な要素は、本発明の範囲から外れるものであるが、それは即ち、ハードウェアである。特に、トラステッド・コンピューティング・ベース機能をフラッシュＲＯＭ内に有する装置では、セキュアなブートローダー（boot loader）を提供し、悪意のあるＲＯＭイメージによりトラステッド・コンピューティング・ベースをサブバートすることが不可能であることを保証する必要がある。
【００３０】
１．２  トラステッド・コンピューティング環境(Trusted Computing Environment)
他のシステム・コンポーネントは、コアを越えて（beyond the core）制限された直交システムケーパビリティ（restricted orthoglnal system capabilities）が許可されるであろうし、トラステッド・コンピューティング環境（ＴＣＥ）を構成するであろう。それらは、電話サーバーやウィンドウサーバーのようなシステムサーバーを含むであろう。例えば、ウィンドウサーバーは、フォンスタックアクセスのケーパビリティは許可されないであろうし、電話サーバーは、キーボードイベントに直接アクセスするケーパビリティは認められないでろう。ここで、できるだけ少ないシステムケーパビリティをソフトウェアコンポーネントに適用して、これらの特権の誤用による潜在的なダメージを制限することを強く薦めるものである。
【００３１】
ＴＣＢは、ＴＣＥの各要素があるサービスのインテグリティを保証するように、システム全体のインテグリティを保証するものである。ＴＣＥは、ＴＣＢ無しには存在し得ない、しかしＴＣＢはそれ自体として存在し、安全な“サンドボックス(sand box)”を各プロセスについて保証することができる。
【００３２】
２．プロセスケーパビリティ
ケーパビリティは、注意を要する行為（sensitive action）を実行する際の許可に対応するアクセストークン（access token）として考えることができる。ケーパビリティモデルの目的は、注意を要するシステムリソースへのアクセスを制御することである。アクセス制御を必要とする最も重要なリソースは、それ自体で実行可能なカーネル（kernel executive itself）であり、システムケーパビリティ（セクション２．１を参照）は、クライアントがカーネルＡＰＩを介して所定の機能にアクセスするために必要とされる。その他のリソースの全ては、ＩＰＣ（Inter Process Communication：プロセス間通信）を介してアクセスされるユーザ側のサーバーに属する。基本的なケーパビリティの小さなセットは、サーバー上での特定のクライアントの動作を取り締まるために定義される。例えば、発呼のケーパビリティ（make calls capability）の所有は、電話サーバーを利用するクライアントに認められるであろう。ケーパビリティが存在するリソースへのクライアントのアクセスを取り締まることは、対応するサーバーの責任であろう。ケーパビリティはまた、各ライブラリ（ＤＬＬ）及びプログラム（ＥＸＥ）と関連づけられ、カーネルによって保持されるであろうネット・プロセス・ケーパビリティ（net process capabilityes）を生成するために実行時に(at run time)ローダーによって結合される。オープンな装置の場合、セクション３において詳述するように、インストールパッケージに署名するために利用される証明書(certificate)に基づいたソフトウェアのインストールの間、或いは、ユーザによるソフトウェアインストール後のいずれかに、サード・パーティ・ソフトウェアについてケーパビリティが割り当てられる。ケーパビリティの取り締まりは、ローダー、カーネル及び影響を受けるサーバーの間で管理されるが、ＩＰＣメカニズムを通じて、カーネルで仲介されたもの（kernel-mediated）となる。
【００３３】
このプロセス・ケーパビリティ・モデルの重要な特徴は以下のようになる。
【００３４】
・システムサーバーと、これらのエンティティ間でのクライアント−サーバにおけるＩＰＣインタラクションの周りにまずフォーカスされる。
【００３５】
・ケーパビリティはプロセスと関連づけられ、スレッド(threads)とは関連づけられない。同一プロセスにおけるスレッドは、同一アドレス空間及びメモリアクセス許可を共有する。このことは、あるスレッドにより利用されるであろういかなるデータも、同一プロセス内の他のスレッドの全てがリードし、修正可能であることを意味する。
【００３６】
・ケーパビリティの取り締まりは、ローダー及びカーネルによって、ターゲットサーバーのケーパビリティ取締りを通じて管理される。カーネルＩＰＣメカニズムは、後者に含まれる。
【００３７】
・コードが実行されていない場合、ケーパビリティはライブラリ及びプログラムの内部に格納される。ライブラリ及びプログラムに格納されているケーパビリティは修正できない。これは、インストールの間に、トラステッド・コンピューティング・ベースによってのみアクセス可能な場所に格納されるためである。
【００３８】
・全てのサーバーが、クライアントケーパビリティを扱う必要はない。サーバーは、希望する場合にケーパビリティの解釈について責任を負う。
【００３９】
・この手法に含まれる唯一の暗号は、ソフトウェアのインストールステージに存在し、そこでは証明書（certificates）が適切なルート証明書（suitable root certificate）と照合される（サブセクション３を参照）。
【００４０】
２．１システムケーパビリティ：装置のインテグリティを保護する
ルート。”全てのファイルへのフルアクセス−実行可能なコードと関連づけられたケーパビリティを修正できる。”
“ルート”ケーパビリティ−トラステッド・コンピューティング・ベースのみにより利用され、装置内の全てのファイルへのフルアクセスを与える。
【００４１】
システムケーパビリティ
あるシステムサーバーは、トラステッド・コンピューティング・ベースへのある特定のアクセスを要求する。オブジェクト指向で実装されているシンビアンＯＳのために、システムサーバーによって要求される種類のリソースは、ほとんどの場合それ専用である。それ故に、あるシステムサーバーは、他のシステムサーバーが要求するものと直交する(orthogonal)、あるシステムケーパビリティが許可されるであろう。例えば、ウィンドウサーバーは、カーネルによって発行されるキーボード及びペンイベントへのアクセスが許可されるであろうが、フォンスタックへのアクセスの許可は得られないであろう。同様に、電話サーバーはフォンスタックへのアクセスは許可されるであろうが、カーネルからのイベントを受け取る許可は得られないであろう。
【００４２】
例えば、以下のように称することができる。
【００４３】
WriteSystemData  コンフィギュレーション・システム・データの修正を許可する。
【００４４】
CommDD  全ての通信及びイーサネット（登録商標）カード装置ドライバへのアクセスを許可する。
【００４５】
DiskAdmin  ディスクの管理タスク（administration task、リフォーマットやドライブの名称変更など）を実行できる。
【００４６】
２．２  ユーザに公表されるケーパビリティ(User-exposed apabilities)：実世界許可のマッピング（Mapping real-world permissions）
ケーパビリティの生成処理は困難となりえる。まず、取り締まりを要求するアクセスを識別しなければならず、その後、これらの要求をユーザにとって意味のあるものにマッピングしなければならない。更に、ケーパビリティが多くなればなるほど複雑性も大きくなるが、複雑性はセキュリティの最大の敵であることは広く認知されている。そこで、ケーパビリティベースのソリューションは、分散される全体数を最小化することを模索すべきである。以下のケーパビリティは、システムサービス（例えば、フォンスタック）への権限なきアクセスである主たる脅威に対し、かなり広くマッピングされ、ユーザデータの守秘性／インテグリティを維持する。
【００４７】
PhoneNetwork“電話ネットワークサービスにアクセス可能であり、潜在的にユーザの金を消費する。”
“電話をかける(Make telephone calls)”
“短いテキストメッセージを送信する(Send short text messages)”
WriteUserData“ユーザのプライベート情報をリードし、修正できる。”
“コンタクトを追加する(Add a contact)”
“アポイントメントとを削除する(Delete appointment)”
ReadUserData“ユーザのプライベート情報をリードできる。”
“コンタクトデータにアクセスする(Access contacts data)”
“アジェンダデータにアクセスする(Access agenda data)”
LocalNetwork“ローカルネットワークにアクセスできる。”
“ブルトゥースメッセージを送信する（Send Bluetooth messages）”
“ＩＲ接続を確立する(Establish an IR connection)”
“ＵＳＢ接続を確立する(Establish USB connection)”
Location“装置の現在のロケーションにアクセスできる”
“装置をマップ上に位置させる(Locate the device on a map)”
“最も近いレストランと映画館を表示する(Display closest restaurants and cinema)”
PhoneNetworkとLocalNetworkとを区別することは必要である。というのも、お金を消費することなくネットワークを介して情報を送信することができるからである（例えば、ブルトゥースのピコネット(Bluetooth piconet)）。この種のアクセスは、非常に便利なサードパーティソフトウェアの成功要因(a very useful third party software enabler)となりえるが、それでもなおトロイの木馬を介して注意を要する情報(sensitive information)をリークするローカルな方法を象徴しているので、たとえ、LocalNetworkでも、ケーパビリティで保護されなければならない。PhoneNetworkは、ユーザが許可すれば、トロイの木馬がその出口ルートとして電話ネットワークの利用を求めることを許容している（PhoneNetwork allow trojans seeking to use the phone network as their exit route）。即ち、潜在的によりダメージを被りやすくなり、ゆえに、その記述においてぶっきらぼうな警告(blunt wrning in its description)が多くなる。
【００４８】
ルート及びシステムのケーパビリティは、強制的なものである。もし実行可能なコードに対して許可されなければ、装置のユーザーは該コードの実行を決定できない。それらの厳格な制御により、トラステッド・コンピューティング・プラットフォームのインテグリティが保証される。しかしながら、サーバーがユーザに公表されたケーパビリティ（user-exposed capabilities）をチェックする方法やそれらを解釈する方法は完全に柔軟なものであって、ユーザに一任しても良い。
【００４９】
図１は、ランタイム処理、システム・ケーパビリティ・リング、及びユーザが視認可能なケーパビリティ・グルーピングを示す。
【００５０】
２．３  ケーパビリティのプロセスへの割当
ランタイムケーパビリティとプロセスとの関連性は、ローダーを含むものである。本質的に、それは、個々のライブラリ及びプログラムと関連づけられた静的なケーパビリティ設定を、カーネルが保持し、カーネルユーザライブラリＡＰＩを通じて要求され得るランタイム・ケーパビリティに変換する。
【００５１】
ルール１
プログラムからプロセスを生成する場合、ローダーは、そのプログラムのケーパビリティのセットと同一のケーパビリティのセットを割り当てる。
【００５２】
ルール２
ライブラリを実行可能なコード内にロードする場合、当該ライブラリのケーパビリティセットは、ロードする実行可能なコードのケーパビリティのセット(the capability set of the loading executable)よりも大きいか、或いは等価でなければならない。もし、この通りでなければ、ライブラリは実行可能なコード内にロードされない。
【００５３】
ルール３
実行可能なコードは、より高いケーパビリティを有するライブラリ（a library with higher capabilities）をロードすることができるが、そうすることによりケーパビリティが増強されることはない。
【００５４】
ルール４
ローダーは、ＴＣＢにリザーブされているファイルシステムの閉じられた部分のデータ(the data caged part of the file system reserved to the TCB)にない、いかなる実行可能なコードのロードも拒む。
【００５５】
ここで、以下の点には注意すべきである。
【００５６】
・ライブラリのケーパビリティは、ロード時においてのみチェックされる。その上で、ライブラリに含まれる全てのコードは自由に実行され、あるＩＰＣ呼を開始する場合に(when initiating some IPC calls)それが読み込まれるプログラム(the program it runs into)のケーパビリティセットと同一のケーパビリティのセットが割り当てられる。
【００５７】
・適切に実行されるＲＯＭイメージについて(for ROM images with execution in place)、ＲＯＭビルトツール（ROM built tool）は、実行時にローダーと同一のタスクを行う全てのシンボルを決定する。そのために、ROMビルトツールは、ROMイメージを構築する場合にローダーと同一のルールを強制する。
【００５８】
これらのルールは、
・注意を要するプロセス(sensitive process)、例えばシステムサーバーにおけるプラグイン、にマルウェア（malware）がロードされることを阻止する。
【００５９】
・また、バイパスを行わずに、プロセスの内部にある注意を要するコードのカプセル化を推奨する。
【００６０】
以下の例は、静的又は動的にロードされたライブラリのそれぞれの場合について、これらのルールがどのように適用されるかを示す。
【００６１】
２．３．１  リンクされたＤＬＬについての例
プログラムＰ．ＥＸＥは、ライブラリＬ１．ＤＬＬにリンクされている。
ライブラリＬ１．ＤＬＬは、ライブラリＬ０．ＤＬＬにリンクされている。
【００６２】
ケース１
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬがＬ０．ＤＬＬをロードできないために、プロセスＰは生成されず、ローダーは失敗する。Ｌ０．ＤＬＬは、Ｌ１．ＤＬＬよりも大きい、或いは、等価なケーパビリティセットを有していないので、ルール２が適用される。
【００６３】
ケース２
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１、Ｃａｐ２、Ｃａｐ３及びＣａｐ４を保持する。
プロセスＰは生成され、ローダーは成功し、新たなプロセスにＣａｐ１及びＣａｐ２が割り当てられる。新たなプロセスのケーパビリティは、ルール１を適用して決定される。ここで、ルール３に規定されるように、Ｌ１．ＤＬＬはＬ０．ＤＬＬが有するＣａｐ４ケーパビリティを取得できず、Ｐ１．ＥＸＥはＬ１．ＤＬＬが有するＣａｐ３ケーパビリティを取得できない。
【００６４】
２．３．２  動的にロードされるＤＬＬについての例
プログラムＰ．ＥＸＥは、ライブラリＬ１．ＤＬＬを動的にロードする。
ライブラリＬ１．ＤＬＬは、ライブラリＬ０．ＤＬＬを動的にロードする。
【００６５】
ケース１
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１及びＣａｐ２を保持する。
プロセスＰは無事に生成され、Ｃａｐ１及びＣａｐ２が割り当てられる。
【００６６】
ＰがローダーにＬ１．ＤＬＬ及びＬ０．ＤＬＬをロードすることを要求すると、ローダーはそれに成功する。これは、ＰがＬ１．ＤＬＬとＬ０．ＤＬＬとをロードすることができるからである。ここでは、ライブラリＬ１．ＤＬＬではなく、ロードする実行可能なコードである(the loading executable)プロセスＰに対してルール２が適用される。また、（該ローダーによって処理される）ＩＰＣロード要求は、プロセスＰによって送信される（the IPC load request that the loader processes is sent by the process P.）。呼(call)はＬ１．ＤＬＬ内にあるという事実は、ここでは不適切である。ルール１及び３が前のように適用され、Ｌ１．ＤＬＬのロードによっては、ＰがＣａｐ３を取得することはない。
【００６７】
ケース２
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ４を保持する。
プロセスＰは無事生成され、Ｃａｐ１及びＣａｐ２が割り当てられる。Ｐが、ローダーにＬ１．ＤＬＬとＬ０．ＤＬＬをロードすることを要求すると、ローダーはそれに成功する。これは、ＰがＬ１．ＤＬＬとＬ０．ＤＬＬをロードできるからである。ここで再度、ルール２が、Ｌ１．ＤＬＬではなく、ロードする実行可能なコードであるＰに適用され、その一方で、ルール３により、ＰはＣａｐ３及びＣａｐ４のいずれも取得しないことが確定される。
【００６８】
２．４  システムサーバー名の保護
重要なサーバーのなりすましを防ぐために、所定のシステムケーパビリティＰｒｏｔＳｅｒｖが生成される。このケーパビリティにプロセスが許可されると、それは“保護されたサーバー（Protected Server）”として、例えば、”！”で始まるような特定の名称形式の下、カーネルに登録することができる。もしコーリングプロセスがＰｒｏｔＳｅｒｖを有していない場合、カーネルは、”！”で始まるいかなる名称登録も拒否するであろう。しかしながら、保護されたサーバーコミュニティの全てのサーバーは、このコミュニティの他のサーバーになりすますことがないことを信頼されなければならない。この簡単なメカニズムにより、サービスの小セットにのみ許可されるＰｒｏｔＳｅｒｖを提供することで、十分なレベルのセキュリティが達成されるであろうと信じられている。もし、二つのサーバー・ドメインで十分でないと証明されれば、新しいケーパビリティと名称形式にリンクされる新しいドメインの追加を将来的に妨げるものは何もない。
【００６９】
２．５  シンビアンＯＳシステムサーバーのファイアウォーリング
２．５．１  ケーパビリティ・パーミッション・ライフタイム
しかるべく機能するカーネル仲介処理ケーパビリティモデルに関して（With a kernel-mediated process capability model in place）、特定のポリシー決定はサーバー自身に委託される。各サーバーは自身を取り締まらなければならず、それを異なる態様で行うであろう。例えば、あるサーバーは、他のサーバーより偏執的であり、アクセス毎にクライアントのケーパビリティ設定をチェックしたり、或いは、不可欠なケーパビリティ・ビット・セットのないアクセスをことごとく拒絶したりするかもしれない。セキュリティポリシーをサーバーにおけるローカルな決定に委託することは、セキュリティポリシーがローカルで望ましく解釈され得ることを意味するので、好ましい抽象化（good abstraction）となる。更に、ケーパビリティ・ビットの存在の解釈は、包括的許可（blanket permission）、プロセス許可（process permission）、セッション許可（session permission）及び選択的アクセス許可（selective access permission）の４通りの方法のうちの何れかにおいて実行することができる。
【００７０】
ユーザの視点からすると、プロセスやセッションのライフタイムを識別することは、更に困難となった。例えば、ほとんどのスマートフォンでは、ユーザが自身のアジェンダ（Agenda）にアクセスした場合、ユーザは、新しいアジェンダプロセスが生成されたのか、或いは、既存のものが再利用されているのか否かは分からない。同様に、ユーザーは、電話をかける際に電話のアプリケーションが新しいセッションを電話サーバーに対して生成したのか、或いは、従前のものを再利用しているのかについて、なんのアイデアも持っていない。ここで、ユーザはケーパビリティを許可する二つの方法のみを理解できると考える。即ち、包括的許可と選択的アクセス許可である。
【００７１】
これに従えば、ケーパビリティ・アウェア・サーバー（capability-aware servers）において、ユーザに公表されたケーパビリティ・ビット（user-exposed capability bit）の存在を解釈するための二つの有りうべき選択肢が存在するであろう。
【００７２】
包括的許可(Blanket permission)：ケーパビリティはワン・オフ・アクト（one off act）として許可される。プロセスが生成された場合に、もしケーパビリティが存在しなければ要求は失敗する。システムケーパビリティを要求する全てのアクセスは、このように取り締まられる。
【００７３】
単一アクション許可(Single action permission)：ケーパビリティは、サーバーへの注意を要するＡＰＩ呼のそれぞれ（each sensitive API call to the server）について確認される。これは、注意を要するＡＰＩ呼への各アクセスでは、サーバーにより生成されるダイアログボックスが、当該ケーパビリティを許可するかどうかをユーザに問い合わせることを意味する。しかしながら、ケーパビリティは、対応する注意を要するＡＰＩ呼の期間において持続するだけである。
【００７４】
この種の許可についてのユーザの認識(user perception)は、サーバーが要求されるケーパビリティをチェックする場合に混同されるべきではない。例えば、アプリケーションは包括的許可としてPhoneNetworkが許可されるかもしれないが、カーネルがクライアントケーパビリティのセットを各ＩＰＣ呼についてとりあえず送信するので、このアプリケーションによってなされた関連する呼のそれぞれについて、電話サーバーはPhoneNetworkケーパビリティをチェックするであろう。しかし、ユーザは（この呼についてPhoneNetworkを許可するか否かの）決定を行うように求められることはないであろうから、このセキュリティチェックはユーザには認識されない。
【００７５】
この設計の利点は以下のようになる。
【００７６】
・許可についてのプロセスの包括的なセットのいかなる修正(any modification of the process blanket set of permission)も、直ちに考慮されること。
【００７７】
・（ＴＯＣＴＯＵ（time of check - time of use flaws：チェック時から使用時まで）をさけるために）利用時間にできるだけ近くなるような時間のチェックを継続すること。
【００７８】
・サーバがケーパビリティ関連情報をプロセスの為に格納することを避けること。
【００７９】
３．ソフトウェア・インストーラ-境界セキュリティ（perimeter security）の強化  
ソフトウェア・インストーラは、どのケーパビリティが、製造後（after manufacture time）にインストールされるべきコードのピース(a piece of code)に対して純粋に許可できるのかを決定するためにプロセスケーパビリティモデルをサポートしなければならない。そのための方法は数多くあり、本発明はそれらのいずれかに強制するものではない。以下のセクションでは、どのようにして誰かがそれを行うことを選択するか、また、どの問題が考慮されるべきかを説明するために、公開鍵インフラストラクチャの存在をベースとした異なるシナリオについて検討する。
【００８０】
ソフトウェア・インストーラは、３つの主たるシナリオをサポートすることが好ましい。
【００８１】
・信用された（署名された）アプリケーションの（アン）インストール／失効（revocation）
・信用されていない（署名された）アプリケーションの（アン）インストール／失効（revocation）
・署名されていないアプリケーションの（アン）インストール／失効（revocation）
ここでの信用の相違は、装置に格納されているルート証明書（root certificate）の一つに対応する、署名チェーン(signing chain)におけるルート証明書の存在に基づく関数である（a function of the presence of a root certificate）。次のサブセクションでは、ユーザの検知からこれらの選択肢について検証する。
【００８２】
３．１  信用された（署名された）ソフトウェアのインストレーション
この場合、是認されたクライアント・アプリケーションは、認知された機関（recognized authority）によってチェックされるであろう。ソフトウェアは、それが要求するケーパビリティのリストに従い、インストレーション・パッケージに署名される。署名されるケーパビリティ(capabilities that could be signed for)は、システム及びユーザに公表されたケーパビリティであろう。ソフトウェアに含まれる証明書のチェーン（chain of certificates）は、ソフトウェア・インストーラが知っているルートＣＡによって終了され、この場合において、ルートＣＡがそれを保証しているという認識のもとに、ユーザはソフトウェアを安全にインストールすることができる。ある装置においては、証明書の署名についての詳細な検証を行っても良いが、インストール時において、いかなるユーザへのフィードバックもなくソフトウェアは装置にインストールされる。システムケーパビリティを求めるサードパーティのソフトウェアはいずれも、このルートを介することを強制されるであろうことは、注意されたい。
【００８３】
３．２  信用されない（署名された）ソフトウェアのインストレーション
この場合、サードパーティソフトウェアは、ルート証明書に照らしてチェックされることはないであろう。ソフトウェアは、不知のルートＣＡにより署名され、この場合には、ユーザには警告が提示されるが、処理を進めて、証明書の内容を確認した後に、とにかくソフトウェアをインストールすることはできる。ソフトウェアインストーラは、ユーザダイアログをインストール時に提供し、ユーザにアプリケーションのインストールのオプションと、アプリケーションが要求しようとするケーパビリティのリストを提示するであろう。このルートを介して許可される可能性のあるケーパビリティは、ユーザに公表される（user-exposed）ケーパビリティの範囲内のものであろう。言い換えれば、装置上のルート証明書の一つに照らしてチェックされることのなかった署名されたソフトウェアに対し、ユーザがシステムケーパビリティを許可することはできない。
【００８４】
３．３  署名されていないソフトウェアのインストール
ここでのシナリオは３．２と同様である。サードパーティは、インストレーションパッケージに関するケーパビリティ(capabilities with their installation package)を要求しなければならない。ここで再度、ユーザに公表されるケーパビリティのみがこのルートにおいて利用可能であり、ユーザは署名されていないソフトウェアに対してシステムケーパビリティを許可することはできない。
【００８５】
図２は、署名されていないアプリケーション、又は、署名されているアプリケーションであるが、そのルート証明による証明書が装置のルート証明書の何れとも一致しないようなアプリケーションのいずれかに適用するポリシーを、ユーザに任意に決定させることが望まれる場合の、インストールプロセスのありうべきものを記載する図である。
【００８６】
３．４  ケーパビリティを破棄するための制御パネル
インストール時以降に、ユーザに任意にセキュリティポリシーを決定させたい場合には、ソフトウェア・コントローラ・パネル・ダイアログには、現在インストールされている様々なサードパーティアプリケーションに対して許可されているケーパビリティ設定へのアクセスを提供することが求められるであろう。ユーザは、インストールされているサードパーティのコードについて、ユーザに公表されるケーパビリティを見たり、付加的に許可したり、破棄したりすることが可能であろう。更に、（もし必要であれば）証明書に署名している対応するコード(correspoinding code signing certificate)を見ることが可能であろう。以下のテーブルは、制御パネルダイアログがどのように見えるかを示した図である。
2005528051.tif 000003
【図面の簡単な説明】
【００８７】
【図１】本発明の実施における、ランタイム処理、システム・ケーパビリティ・リング、ユーザが視認可能なケーパビリティ・グルーピングを示す図である。
【図２】インストールのありうべき処理を示す図である。
【図１】
2005528051.tif 000004
【図２】
2005528051.tif 000005
【国際調査報告】
2005528051.tif 000006
2005528051.tif 000007
2005528051.tif 000008