取り外し可能な媒体に格納された実行可能なコードにタンパーエビデント性を提供する装置
【課題】取り外し可能な媒体に格納された実行可能なコードにタンパーエビデント性を提供する
【解決手段】通常の使用時に容易に着脱可能な媒体上のネイティブで実行可能なコードをインストール可能にプログラムされている移動体無線装置。前記コードのダイジェストを計算し、前記移動体無線装置内の取り外しできない固定的な格納部に格納し、前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算し、前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制することを特徴とする。
【解決手段】通常の使用時に容易に着脱可能な媒体上のネイティブで実行可能なコードをインストール可能にプログラムされている移動体無線装置。前記コードのダイジェストを計算し、前記移動体無線装置内の取り外しできない固定的な格納部に格納し、前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算し、前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、取り外し可能な（リムーバブルな）媒体に格納された実行可能なコードにタンパーエビデント性（tamper evidence）を提供する装置に関する。本装置は、プラットフォーム・セキュリティ構造においてある要素を形成するものである。
【背景技術】
【０００２】
プラットフォーム・セキュリティは、悪意ある又は下手に書かれたコード（malicious or badly written code）に対するプラットフォーム防護メカニズムの思想、構造、実装をカバーするものである。これらの防護メカニズムにより、そのようなコードが害をもたらすことを妨げることができる。悪意あるコードは一般に２つの要素を有する。それは、ダメージを与えるペイロードメカニズム（payload mechanism）と、それを拡散する手助けをする拡散メカニズム（propagation mechanism）である。
【０００３】
これらは通常、以下のように分類される。
・ トロイの木馬（Trojan horse）：良性でユーザにとって魅力的に出現する正規のアプリケーション(legitimate application that appears benign and attrative to the user)を有する。
・ ワーム（Ｗｏｒｍ）：その提供者、あるいはユーザによる更なるマニュアル操作によらず複製され、拡散する。
・ ウィルス（Ｖｉｒｕｓ）：正規のプログラムに侵入し、データを変更、或いは破壊する。
【０００４】
セキュリティの脅威は、（ａ）サービスやデータの守秘性(confidentiality)、インテグリティ（integrity：完全性）又は、利用可能性(availability)を連鎖的に損なう潜在性や、（ｂ）サービス機能の妥協を包含している。
【０００５】
このような脅威は以下のように分類される。
１．データの守秘性及びインテグリティに関する脅威。例えば、ユーザのパスワードを入手したり、ファイルを破壊したりする。
２．サービスの守秘性及びインテグリティに関する脅威。例えば、電話ネットワークの加入者の帯域を無料で利用したり、ネットワーク・サービス・プロバイダとのトランザクションを無効化したりする。
３．サービスの利用可能性に関する脅威（又は、サービスの拒否とも呼ばれる）。例えば、ユーザがテキストメッセージを送信することを妨げたり、電話の着信を受けることを妨げたりする。
【０００６】
このように、移動体無線装置は、セキュリティ構造の設計者に対して相当数の課題を突きつけるものである。この課題の重要な側面の一つは、移動体無線装置が一般的に取り外し可能な格納装置上にプログラムをインストールするであろうということである。主な動機は、どのプログラムセットをユーザが使用したいかに基づいて、無線装置のユーザが変更可能な特別なストレージ（extra storage）を提供することである。良く知られた例としては、パーソナル・コンピュータの環境におけるフロッピー（登録商標）ディスクやメモリーカードの利用が挙げられる。取り外し可能な格納装置は、原理的に、移動体無線装置にプラグインされていない場合でも、何らかの方法で手を加えられることがあり得るので、該装置上に格納されているプログラムはそのインテグリティを喪失するであろう。全ての環境において、取り外し可能な格納装置が再挿入されようとする場合を含めて、（例えば、セキュリティ特性を無効にするための悪意のある変更は行われていない、或いは、ウィルスが含まれていない、などといった）無線装置が実行可能なコードのインテグリティを信頼することは極めて重要である。
【０００７】
今までの所、移動体無線装置から転送され、元の装置に戻されようとしている実行可能なコードのインテグリティを保証するための効果的な提案はなされていない。
【発明の概要】
【０００８】
本発明の第一の側面においては、取り外し可能な媒体状のネイティブで実行可能なコードをインストールすることが可能な移動体無線装置が提供される。装置は、当該コードのダイジェスト（このダイジェストは、当該内容が異なる場合には、同一の値を生成することができないことを保証するアルゴリズムを利用して、当該コードの内容全体から生成される値である。）を演算し、装置内の取り外しができない固定的格納部（a persistent non-removable store）に格納するようにプログラムされている。ネイティブコード(native code)は、装置のＣＰＵによって直接に実行される命令で構成される。
【０００９】
取り外し可能な媒体が再度接続され、該実行可能なコードが呼び出された場合、装置は、当該取り外し可能な媒体からロードしようとするコードからダイジェストを再演算し、取り外しができない固定的格納部に格納されているダイジェストと比較する。もし、それらが一致しない場合、当該実行可能なコードは、改竄されたものであるから、装置から信用されることはありえない。当該ダイジェストは、（後述する）トラステッド・コンピューティング・ベース(Trusted Computing Base)におけるコンポーネントによってのみアクセス可能であって、それ自体は安全である。このダイジェストは、ハッシュや実行可能なコードの全体から再計算可能な他のユニークで代替的値であってもよい。
【００１０】
このアプローチは、ハッシュがメディアファイルから導出され、当該ファイルに挿入され、ファイルを気づかれない程度に修正する従来の電子透かしとは異なるものである。
【００１１】
ある実施態様では、ダイジェストは、実行可能なコードの"ケーパビリティ"と同様に、装置上で安全に格納される。"ケーパビリティ"は、特に注意を要する動作(sensitive action)の実行の認可に対応するアクセストークン（access token）として考えることができる。（ケーパビリティモデルの目的は、注意を要する(sensitive)システムリソースへのアクセスを制御することである。）ロード時において、ローダーはロード以前にハッシュを検証する。もし検証に失敗すると、実行可能なコードはロードされないであろう。もし、実行可能なコードが不知（unknown）である場合（関連するダイジェストがない場合）、実行可能なコードはケーパビリティなし（即ち、注意を要するリソースへのアクセス権がない）及び識別子なし（識別されたオペレーティングシステムプロセスにのみ公開されるデータへのアクセス権がない）でロードされる。もし、検証が成功すれば、実行可能なコードはロードされ、新しくロードされたコードに格納されているケーパビリティが割り当てられる。
【００１２】
本発明は、ユーザが、装置間において制約を受けることなくメモリーカード及び他の形態の取り外し可能な媒体を共有することを可能とする。また、媒体や他のユーザの選択とは独立に、ユーザがこれらのカードに格納されているアプリケーションに許可した特権をユーザが維持することを可能とする。
【発明を実施するための形態】
【００１３】
本発明は、シングルユーザ無線装置のために設計されたオブジェクト指向のオペレーティングシステムであるシンビアンＯＳのセキュリティ構造を参照して記載される。シンビアン・オペレーティング・システムは、英国ロンドンのシンビアン・リミテッドにより移動体無線装置のために開発されたものである。
【００１４】
シンビアンＯＳにおけるセキュリティ構造の基本的な概要は、中世の城の防護（a medieval castle defenses）に類似している。類似の形態において、インストール境界（installation perimeter）に加えて、簡単で、スタッガード構造の（staggered）セキュリティレイヤーを採用する。当該モデルが取り扱おうとしている重要な脅威は、ユーザーデータ及びシステムサービス、特にフォンスタック(phone stack)への権原のないアクセスと関連している。フォンスタックはスマートフォンと関連して特に重要である。というのも、フォンスタックが電話ネットワークとの不変のデータ接続(permanent data connection)を制御するからである。当該モデルの後ろに位置する重要なデザインドライバ（key design drivers）が二つある。
【００１５】
その一つは、ケーパビリティベースのアクセス制御を利用した重要なシステムリソースのファイアウォール防護である。
【００１６】
もう一つは、標準的なソフトウェアがアクセスできない、保護された部分をファイルシステムに生成するデータ分割（data partitioning）である。
【００１７】
以下に記載するケーパビリティモデルの主たるコンセプトは、ユーザが何ができるかではなく、プロセスに何ができるかを制御することにある。このアプローチは、ウィンドウズ（登録商標）ＮＴやＵｎｉｘ（登録商標）といった既知のオペレーティングシステムとは極めて異なるものである。その主な理由は、以下のようになる。
【００１８】
〔シングルユーザ用途のシンビアンＯＳの性質〕
【００１９】
シンビアンＯＳは、独立したサーバープロセスを介してサービスを提供している。それらは常に動作しており、かつ、ユーザセッションに付加されることがない。電力が供給されている限り、シンビアンＯＳはユーザがログオンしていない場合であっても常に起動状態にある。
【００２０】
シンビアンＯＳは、技術的知識の無い、多くの公衆に利用される装置において使用されることを目的としている。ソフトウェアのインストール時に、どんな許可をアプリケーションに対して与えるかを決定する能力をユーザが有していなくても良い。さらに、常に接続されている装置に関しては、誤った或いは悪意のある決定の結果は、装置自体よりもドメインに遙かに大きなインパクトを与えるかもしれない。
〔１ トラステッド・コンピューティング・プラットフォーム(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 orthogonal system capabilities）が許可されるであろうし、トラステッド・コンピューティング環境（ＴＣＥ）を構成するであろう。それらは、電話サーバやウィンドウサーバーのようなシステムサーバーを含むであろう。例えば、ウィンドウサーバーは、フォンスタックアクセスのケーパビリティは許可されないだろうし、電話サーバは、キーボードイベントに直接アクセスするケーパビリティは認められないであろう。ここで、できるだけ少ないシステムケーパビリティをソフトウェアコンポーネントに適用して、これらの特権の誤用による潜在的なダメージを制限することを強く薦めるものである。
【００２４】
ＴＣＢは、ＴＣＥの各要素があるサービスのインテグリティを保証するように、システム全体のインテグリティを保証するものである。ＴＣＥは、ＴＣＢ無しには存在し得ない、しかしＴＣＢはそれ自体として存在し、安全な"サンドボックス(sand box)"を各プロセスについて保証することができる。
〔２．プロセスケーパビリティ〕
【００２５】
ケーパビリティは、注意を要する行為（sensitive action）を実行する際の許可に対応するアクセストークン（access token）として考えることができる。ケーパビリティモデルの目的は、注意を要するシステムリソースへのアクセスを制御することである。アクセス制御を必要とする最も重要なリソースは、それ自体で実行可能なカーネル（kernel executive itself）であり、システムケーパビリティ（セクション２．１を参照）は、クライアントがカーネルＡＰＩを介して所定の機能にアクセスするために必要とされる。その他のリソースの全ては、ＩＰＣ（Inter Process Communication：プロセス間通信）を介してアクセスされるユーザ側のサーバに属する。基本的なケーパビリティの小さなセットは、サーバ上での特定のクライアントの動作を取り締まるために定義される。例えば、発呼のケーパビリティ（make calls capability）の所有は、電話サーバを利用するクライアントに認められるであろう。ケーパビリティが存在するリソースへのクライアントのアクセスを取り締まることは、対応するサーバの責任であろう。ケーパビリティはまた、各ライブラリ（ＤＬＬ）及びプログラム（ＥＸＥ）と関連づけられ、カーネルによって保持されるであろうネット・プロセス・ケーパビリティ（net process capabilities）を生成するために実行時に(at run time)ローダーによって結合される。オープンな装置の場合、インストールパッケージに署名するために利用される証明書(certificate)に基づいたソフトウェアのインストールの間、或いは、ユーザによるソフトウェアインストール後のいずれかに、サード・パーティ・ソフトウェアについてケーパビリティが割り当てられる。ケーパビリティの取り締まりは、ローダー、カーネル及び影響を受けるサーバの間で管理されるが、ＩＰＣメカニズムを通じて、カーネルで仲介されたもの（kernel-mediated）となる。
【００２６】
このプロセス・ケーパビリティ・モデルの重要な特徴は以下のようになる。
【００２７】
・ システムサーバーと、これらのエンティティ間でのクライアント−サーバにおけるＩＰＣインタラクションの周りにまずフォーカスされる。
【００２８】
・ ケーパビリティはプロセスと関連づけられ、スレッド(threads)とは関連づけられない。同一プロセスにおけるスレッドは、同一アドレス空間及びメモリアクセス許可を共有する。このことは、あるスレッドにより利用されるであろういかなるデータも、同一プロセス内の他のスレッドの全てがリードし、修正可能であることを意味する。
【００２９】
・ ケーパビリティの取り締まりは、ローダー及びカーネルによって、ターゲットサーバーのケーパビリティ取締りを通じて管理される。カーネルＩＰＣメカニズムは、後者に含まれる。
【００３０】
・ コードが実行されていない場合、ケーパビリティはライブラリ及びプログラムの内部に格納される。ライブラリ及びプログラムに格納されているケーパビリティは修正できない。これは、インストールの間に、トラステッド・コンピューティング・ベースによってのみアクセス可能な場所に格納されるためである。
【００３１】
・ 全てのサーバが、クライアントケーパビリティを扱う必要はない。サーバは、希望する場合にケーパビリティの解釈について責任を負う。
【００３２】
・ この手法に含まれる唯一の暗号は、ソフトウェアのインストールステージに存在し、そこでは証明書（certificates）が適切なルート証明書（suitable root certificate）と照合される。
〔２．１システムケーパビリティ：装置のインテグリティを保護する〕
【００３３】
（ルート： 全てのファイルへのフルアクセス−実行可能なコードと関連づけられたケーパビリティを修正できる）
"ルート"ケーパビリティ−トラステッド・コンピューティング・ベースのみにより利用され、装置内の全てのファイルへのフルアクセスを与える。
【００３４】
（システムケーパビリティ）
あるシステムサーバーは、トラステッド・コンピューティング・ベースへのある特定のアクセスを要求する。オブジェクト指向で実装されているシンビアンＯＳのために、システムサーバーによって要求される種類のリソースは、ほとんどの場合それ専用である。それ故に、あるシステムサーバーは、他のシステムサーバーが要求するものと直交する(orthogonal)、あるシステムケーパビリティが許可されるであろう。例えば、ウィンドウサーバーは、カーネルによって発行されるキーボード及びペンイベントへのアクセスが許可されるであろうが、フォンスタックへのアクセスの許可は得られないであろう。同様に、電話サーバはフォンスタックへのアクセスは許可されるであろうが、カーネルからのイベントを受け取る許可は得られないであろう。
【００３５】
例えば、以下のように称することができる。
【００３６】
WriteSystemData： コンフィギュレーション・システム・データの修正を許可する。
【００３７】
CommDD： 全ての通信及びイーサネット（登録商標）カード装置ドライバへのアクセスを許可する。
【００３８】
DiskAdmin： ディスクの管理タスク（administration task、リフォーマットやドライブの名称変更など）を実行できる。
〔２．２ ユーザに公表されるケーパビリティ(User-exposed capabilities)：実世界許可のマッピング（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)"
ルート及びシステムのケーパビリティは、強制的なものである。もし実行可能なコードに対して許可されなければ、装置のユーザは該コードの実行を決定できない。それらの厳格な制御により、トラステッド・コンピューティング・プラットフォームのインテグリティが保証される。しかしながら、サーバがユーザに公表されたケーパビリティ（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)はＬ１．ＤＬＬ内にあるという事実は、ここでは不適切である。ルール１及び３が前のように適用され、Ｌ１．ＤＬＬのロードによっては、ＰがＣａｐ３を取得することはない。
【００５８】
（ケース２）
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ４を保持する。
プロセスＰは無事生成され、Ｃａｐ１及びＣａｐ２が割り当てられる。Ｐが、ローダーにＬ１．ＤＬＬとＬ０．ＤＬＬをロードすることを要求すると、ローダーはそれに成功する。これは、ＰがＬ１．ＤＬＬとＬ０．ＤＬＬをロードできるからである。ここで再度、ルール２が、Ｌ１．ＤＬＬではなく、ロードする実行可能なコードであるＰに適用され、その一方で、ルール３により、ＰはＣａｐ３及びＣａｐ４のいずれも取得しないことが確定される。
〔２．４ 取り外し可能な媒体の柔軟性をどのようにプラットフォーム・セキュリティと結びつけるか〕
〔２．４．１ 今日〕
〔２．４．１．１ 装置のインテグリティ〕
【００５９】
今日、取り外し可能な媒体に格納されているファイルは完全に無防備である。それらは、完全にアクセス可能であり、修正を受けることができる。取り外し可能な媒体が装置に再度接続されると、システムのインテグリティを保証するためのチェックは一切実行されない。この事実と関連するリスクは、低く見られているかもしれない。というのも、媒体の所有はサブヴァージョン(subversion)のために必要とされるからである。しかしながら、例えば、悪意のあるユーザはマルウェア（malware）をインストールして、装置にはダメージを与えないが、ネットワークオペレータに対する武器として利用するかもしれない。今日、プラットフォーム・セキュリティを除けば、取り外し可能な媒体からのコードのロードを拒否するローダーを利用するしか保護の術はない。しかしながら、長い目で見れば、より多くのスペースがより多くのアプリケーションを格納するために必要とされ、この方法では、ユーザが装置用にソフトウェアを購入することの妨げとなってしまい、もしそれを利用することができないのであればオープンなプラットフォームを購入することを、暗黙のうちに阻止することとなってしまう。
〔２．４．１．２ データの守秘性（confidentiality）〕
【００６０】
データの守秘性に対する脅威は現実のものであるが、盗まれた取り外し可能な媒体に含まれるデータのみに限られる。このような脅威の大半は、次のようなプラットフォーム・セキュリティのサポートに依らずに既に防止することができる。
【００６１】
（１．媒体へのハードウェア・コントロール・アクセス）
平均的な装置では、例えば、セキュアＭＭＣ(Secure MMC)、ＰＩＮ保護されたＳＩＭ（PIN-protected SIM）媒体はパスワードにより保護される。
【００６２】
（２．ファイル暗号化）
ユーザがある注意を要するデータ（sensitive data）のセキュリティに関心を有し、そのデータを取り外し可能な媒体に格納するならば、該ユーザは暗号化を行うことが好ましい。
【００６３】
（３．ファイルシステム暗号化）
ファイルシステム暗号化は、ディスク装置ドライバレベルにおいて提供されるのが好ましい。
〔２．４．２ 提案に係る発明〕
【００６４】
提案に係る本発明は、現在の脅威を防止するだけでなく、取り外し可能な媒体の相互運用性（interoperability）及びコード分配利用（code distribution uses）を維持することをも目的とする。
【００６５】
プラットフォーム・セキュリティ構造では、取り外し可能な媒体が装置から取り外された場合になされる修正を防止することはできない。パスワードで保護された取り外し可能な媒体であっても、権限のあるユーザはそれを変更することができる。ゆえに、最も好ましいプラットフォーム・セキュリティは、既知の実行可能なコードについてはタンパーエビデンス機能(tamper evidence mechanism)を提供し、不知のコードについては安全な実行を提供することができる。
〔２．４．２．１ ソフトウェア・インストーラ〕
【００６６】
インストール時において、アプリケーションパッケージが取り外し可能な媒体に格納されるべきである場合：
ステップ１．ソフトウェア・インストーラは、取り外し可能な媒体にインストールされようとしている実行可能なコードが、正しいセキュア識別子（ＳＩＤ）を有し、かつ、他の正当な実行可能なコードになりすまして、そのプライベートデータにアクセスしようとしていないか、を検証する。
【００６７】
ステップ２．ソフトウェア・インストーラは、幾つかのシステム及びユーザのケーパビリティを、アプリケーションパッケージに含まれている実行可能なコードに割り当てる。
【００６８】
ステップ３．ソフトウェア・インストーラは、実行可能なコードをハッシュする。
【００６９】
ステップ４．ソフトウェア・インストーラは、全てのケーパビリティとハッシュ結果（即ち、ダイジェスト）を（例えば、移動不可能な）不変のファイルシステムのＴＣＢで制限されたエリア（TCB-restricted area of a permanent file system）に格納する。
【００７０】
デインストール時（de-install time）には、ソフトウェア・インストーラは実行可能なコードが存在する場合にはそれを取り外し可能な媒体から除去し、インストールステップ４において生成された関連ファイルを破壊する。
【００７１】
プレフォーマットされた取り外し可能な媒体（既にインストールされたファイル）については、ソフトウェア・インストーラにステップ１から３を実行させるために、アプリケーションパッケージの簡素なバージョン（lighter version）が提供されなければならない。本発明は、プリフォーマットされた取り外し可能な媒体上の新しいアプリケーションを検出するための装置を、いかなるものにも限定することはない。可能性のあるオプションとしては、無線装置へ取り外し可能な媒体が挿入された時点において新しいアプリケーションの存在を検出してもよいし、プリフォーマットされた取り外し可能な媒体の除去を、それが含むアプリケーションのデインストールの際に考慮してもよい。
〔２．４．２．２ ローダー(Loader)〕
【００７２】
ロード時において、ローダーは取り外し可能な媒体からロードするために実行可能なコードを識別する。ローダーは、対応するＨＡＳＨファイル、（例えば、移動不可能な）不変のファイルシステムのＴＣＢで制限されたエリア（TCB-restricted area of a permanent file system）に格納されたハッシュ結果、を参照する。
【００７３】
・ もし、該ハッシュファイルが存在する場合、実行可能なコードをハッシュして、両ハッシュ結果を比較する。
【００７４】
・ もし両者が一致する場合、ローダーはＨＡＳＨファイルから抽出されたシステム及びユーザのケーパビリティを、該実行可能なコードに割り当てて、通常のローディング処理を実行する。
【００７５】
・ もし両者が一致しない場合、ローダーはエラーを返す。
【００７６】
・ もし、対応するＨＡＳＨファイルが存在しない場合、ローダーは、システム及びユーザのケーパビリティを、該実行可能なコードに割り当てることはせずに、通常のローディング処理を実行する。ローダーは、当該"不知のコード（unknown）"にセキュア識別子（ＳＩＤ）を割り当てて（プロセスの該ＳＩＤ（セキュア識別子）は、ＯＳ上で実行可能なコードの一部をユニークに識別するための手法であって、関連する実行可能なコードに格納されている）、正当なプロセスへのなりすましを防止する。ケーパビリティ及びＳＩＤが不知のコードには許可されないので、このコードはトラステッド・コンピューティング・プラットフォームのインテグリティを危うくすることはない。
【００７７】
ハッシュ処理(hashing process)は、取り外し可能な媒体とは独立でなければならない。実行されるべきは、コードの一部の認証であって、それを提供する取り外し可能な媒体の認証ではない。好適な実施態様では、無線装置において利用するのに合理的な安全性と高速性を有する点から、ＳＨＡ−１が利用される。
〔２．４．３ 利用ケース（Use cases）〕
〔２．４．３．１ アクター（Actors）〕
【００７８】
１．Ｕは、ユーザである。
２．Ｐ１、Ｐ２は、Ｕによって所有されている２つの無線装置である。
３．Ｃ１、Ｃ２は、Ｕによって所有されている２つの取り外し可能な媒体である。
４．ＡＰＰは、実行可能なコードを１つのみ有するアプリケーションである。
５．ローダー
６．ＳＷＩｎｓｔａｌｌは、ソフトウェア・インストーラである。
７．ＥＴＥＬは、電話ネットワークへのアクセスを制御するプロセスである。
〔２．４．３．２ 仮定（Assumptions）〕
【００７９】
１．ＡＰＰは、PhoneNetworkケーパビリティを有する署名されたアプリケーションパッケージＡＰＰ．ｓｉｓとして配信される。
２．Ｃ：は、内部ドライブである。
３．Ｄ：は、取り外し可能な媒体用のドライブである。
４．Ｃ１はＡＰＰ．ｓｉｓをルート下に含む。ＡＰＰ．ｓｉｓは、ＡＰＰのインストレーション・パッケージである。
〔２．４．３．３ 利用ケース１−ＵがＰ１にＡＰＰをインストールする〕
【００８０】
１．ＵはＣ１をＰ１に接続する。
２．ＵはＰ１を利用する。
３．Ｕは、ＳＷＩｎｓｔａｌｌに、Ｄ：＼ＡＰＰ．ｓｉｓをドライブＤ：＼にインストールすることを依頼する。
４．ＳＷＩｎｓｔａｌｌは、署名証明書（signing certificate）を検証する。｛Ｅ１｝
５．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐを抽出する。
６．ＳＷＩｎｓｔａｌｌは、システム及びユーザのケーパビリティを実行可能なコードから除去し、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ(directory accessible to TCB only)＞＼ＡＰＰ．ｃａｐへコピーする。
７．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをハッシュして、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐに格納する。
８．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤ：へコピーする。
９．ＳＷＩｎｓｔａｌｌは、インストールを完了する。
【００８１】
Ｅ１−有効でない署名
１．利用ケース終了。
〔２．４．３．４ 利用ケース２−ＵがＣ１をＣ２にオフラインでコピーし、Ｃ２をＰ１で利用する〕
【００８２】
１．ＵはＣ１をＣ２にオフラインでコピーする。
２．ＵはＣ２をＰ１に接続する。
３．ＵはＰ１を利用する。
４．Ｕは、ローダーにＡＰＰの開始を依頼する。
５．ローダーはＡＰＰ．ａｐｐをＤ：＼に発見する。
６．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
７．ローダーは、ハッシュ結果の検証に成功する。｛Ｅ２｝
８．ローダーは、システム及びユーザのケーパビリティをＡＰＰ．ｃａｐから抽出する。
９．ローダーはＡＰＰ．ａｐｐをロードし、ＡＰＰ．ａｐｐにケーパビリティを割り当てる。
１０．Ｕは、ＡＰＰに番号のダイヤルを依頼する。
１１．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
１２．ＥＴＥＬは、ＡＰＰがPhoneNetworkを取得したことのチェックに成功する。
１３．ＥＴＥＬは番号をダイヤルする。
１４．Ｕは電話接続を利用する。
【００８３】
Ｅ２−ハッシュは一致しない
１．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラー（Binary Hash Mismatch error）を返す。
２．ＵはＡＰＰを利用できない。
〔２．４．３．５ 利用ケース３−ＵがＣ１をＰ２で利用する〕
【００８４】
１．ＵはＣ１をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはローダーにＡＰＰの開始を依頼する。
４．ローダーはＡＰＰ．ａｐｐをＤ：＼に発見する。
５．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを発見しない。
６．ローダーはＡＰＰ．ａｐｐをロードし、ＡＰＰ．ａｐｐに、ユーザ及びシステムのケーパビリティを割り当てない。
７．Ｕは、ＡＰＰに番号のダイヤルを依頼する。
８．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
９．ＥＴＥＬは、ＡＰＰがPhoneNetworkを取得していないことを検出する。
１０．ＥＴＥＬは、電話をかけたいかどうかをＵに問い合わせる。
１１．Ｕは許可する（U accepts）。｛Ｅ１｝
１２．ＥＴＥＬは番号をダイヤルする。
１３．Ｕは電話接続を利用する。
【００８５】
Ｅ１−Ｕは許可しない(U does not accept)
１．ＥＴＥＬは番号をダイヤルしない。
２．ＡＰＰはＵに対してエラーを表示する。
【００８６】
〔２．４．３．６ 利用ケース４−ＵはＡＰＰをＰ２にインストールし、ＡＰＰのPhoneNetworkをデモートする（demote）〕
【００８７】
１．ＵはＣ１をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはＰ２のＤ：＼にＡＰＰをインストールすることに成功する。（利用ケース１を参照。）
４．Ｕは、ＳＷＩｎｓｔａｌｌに、ＡＰＰのケーパビリティからPhoneNetworkを除去することを依頼する。
５．ＳＷＩｎｓｔａｌｌは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを修正し、ファイル内のユーザのケーパビリティをリセットする。
６．Ｕは、ローダーにＡＰＰの開始を依頼する。
７．ローダはＤ：＼にＡＰＰ．ａｐｐを発見する。
８．ローダーはｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
９．ローダーはハッシュ結果の検証に成功する。｛Ｅ２｝
１０．ローダーはケーパビリティをＡＰＰ．ｃａｐから抽出する。
１１．ローダーは、ＡＰＰ．ａｐｐをロードし、ケーパビリティをＡＰＰ．ａｐｐに割り当てる。
１２．ＵはＡＰＰに番号のダイヤルを依頼する。
１３．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
１４．ＥＴＥＬはＡＰＰがPhoneNetworkを取得していないことを検出する。
１５．ＥＴＥＬは、電話をかけたいかどうかをＵに問い合わせる。
１６．Ｕは許可する。｛Ｅ１｝
１７．ＥＴＥＬは番号をダイヤルする。
１８．Ｕは電話接続を利用する。
１９．ＵはＣ１をＰ１に接続する。
２０．ＵはＡＰＰに番号のダイヤルを依頼する。
２１．ＡＰＰは、ＥＴＥＬに番号のダイヤルを依頼する。
２２．ＥＴＥＬはＡＰＰがPhoneNetworkを取得したことのチェックに成功する。
２３．ＥＴＥＬは番号をダイヤルする。
２４．Ｕは電話接続を利用する。
【００８８】
Ｅ１−Ｕは許可しない。
１．ＥＴＥＬは番号をダイヤルしない。
２．ＡＰＰはＵに対してエラーを表示する。
【００８９】
Ｅ２−ハッシュ結果が不一致
１．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
２．ＵはＡＰＰを利用できない。
〔２．４．３．７ 利用ケース５−Ｕは、Ｐ２からＣ２を利用してＡＰＰをアンインストールする〕
【００９０】
１．ＵはＣ２をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはＳＷＩｎｓｔａｌｌにＡＰＰのアンインストールを依頼する。
４．ＳＷＩｎｓｔａｌｌは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを削除する。
５．ＳＷＩｎｓｔａｌｌは、ＵにＤ：上での削除の承認を依頼する。
６．Ｕは承認する。｛Ｅ１｝
７．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤ：から削除する。
８．ＵはＣ２をＰ１又はＰ２上で利用してＡＰＰを開始することができない。
【００９１】
Ｅ２−Ｕは承認しない。
１．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤから削除しない。
２．ＵはＣ２をＰ１で利用してＡＰＰを開始することができる。
〔２．４．３．８ 利用ケース６−ＵはＡＰＰ．ａｐｐをハックし、幾つかのシステムケーパビリティを追加する〕
【００９２】
１．Ｕは、Ｃ１上でオフラインでＡＰＰ．ａｐｐシステムケーパビリティを修正する。
２．ＵはＣ１をＰ１に接続する。
３．ＵはＰ１を利用する。
４．ＵはローダーにＡＰＰの開始を依頼する。
５．ローダーはＤ：にＡＰＰ．ａｐｐを発見する。
６．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
７．ローダーはハッシュの検証に失敗する。
８．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
９．ＵはＡＰＰを利用できない。
〔２．４．３．９ 結論〕
【００９３】
これらの利用ケースは、プラットフォーム・セキュリティにおいても、取り外し可能な媒体により提供される以下の柔軟性が維持されることを示している。
・ 異なるユーザケーパビリティ設定を有する装置間においてカードを共有すること。
・ カードを複製し、当該複製されたものを制限なく利用すること。
・ 取り外し可能な媒体から取得されるコードを安全に実行すること。
【技術分野】
【０００１】
本発明は、取り外し可能な（リムーバブルな）媒体に格納された実行可能なコードにタンパーエビデント性（tamper evidence）を提供する装置に関する。本装置は、プラットフォーム・セキュリティ構造においてある要素を形成するものである。
【背景技術】
【０００２】
プラットフォーム・セキュリティは、悪意ある又は下手に書かれたコード（malicious or badly written code）に対するプラットフォーム防護メカニズムの思想、構造、実装をカバーするものである。これらの防護メカニズムにより、そのようなコードが害をもたらすことを妨げることができる。悪意あるコードは一般に２つの要素を有する。それは、ダメージを与えるペイロードメカニズム（payload mechanism）と、それを拡散する手助けをする拡散メカニズム（propagation mechanism）である。
【０００３】
これらは通常、以下のように分類される。
・ トロイの木馬（Trojan horse）：良性でユーザにとって魅力的に出現する正規のアプリケーション(legitimate application that appears benign and attrative to the user)を有する。
・ ワーム（Ｗｏｒｍ）：その提供者、あるいはユーザによる更なるマニュアル操作によらず複製され、拡散する。
・ ウィルス（Ｖｉｒｕｓ）：正規のプログラムに侵入し、データを変更、或いは破壊する。
【０００４】
セキュリティの脅威は、（ａ）サービスやデータの守秘性(confidentiality)、インテグリティ（integrity：完全性）又は、利用可能性(availability)を連鎖的に損なう潜在性や、（ｂ）サービス機能の妥協を包含している。
【０００５】
このような脅威は以下のように分類される。
１．データの守秘性及びインテグリティに関する脅威。例えば、ユーザのパスワードを入手したり、ファイルを破壊したりする。
２．サービスの守秘性及びインテグリティに関する脅威。例えば、電話ネットワークの加入者の帯域を無料で利用したり、ネットワーク・サービス・プロバイダとのトランザクションを無効化したりする。
３．サービスの利用可能性に関する脅威（又は、サービスの拒否とも呼ばれる）。例えば、ユーザがテキストメッセージを送信することを妨げたり、電話の着信を受けることを妨げたりする。
【０００６】
このように、移動体無線装置は、セキュリティ構造の設計者に対して相当数の課題を突きつけるものである。この課題の重要な側面の一つは、移動体無線装置が一般的に取り外し可能な格納装置上にプログラムをインストールするであろうということである。主な動機は、どのプログラムセットをユーザが使用したいかに基づいて、無線装置のユーザが変更可能な特別なストレージ（extra storage）を提供することである。良く知られた例としては、パーソナル・コンピュータの環境におけるフロッピー（登録商標）ディスクやメモリーカードの利用が挙げられる。取り外し可能な格納装置は、原理的に、移動体無線装置にプラグインされていない場合でも、何らかの方法で手を加えられることがあり得るので、該装置上に格納されているプログラムはそのインテグリティを喪失するであろう。全ての環境において、取り外し可能な格納装置が再挿入されようとする場合を含めて、（例えば、セキュリティ特性を無効にするための悪意のある変更は行われていない、或いは、ウィルスが含まれていない、などといった）無線装置が実行可能なコードのインテグリティを信頼することは極めて重要である。
【０００７】
今までの所、移動体無線装置から転送され、元の装置に戻されようとしている実行可能なコードのインテグリティを保証するための効果的な提案はなされていない。
【発明の概要】
【０００８】
本発明の第一の側面においては、取り外し可能な媒体状のネイティブで実行可能なコードをインストールすることが可能な移動体無線装置が提供される。装置は、当該コードのダイジェスト（このダイジェストは、当該内容が異なる場合には、同一の値を生成することができないことを保証するアルゴリズムを利用して、当該コードの内容全体から生成される値である。）を演算し、装置内の取り外しができない固定的格納部（a persistent non-removable store）に格納するようにプログラムされている。ネイティブコード(native code)は、装置のＣＰＵによって直接に実行される命令で構成される。
【０００９】
取り外し可能な媒体が再度接続され、該実行可能なコードが呼び出された場合、装置は、当該取り外し可能な媒体からロードしようとするコードからダイジェストを再演算し、取り外しができない固定的格納部に格納されているダイジェストと比較する。もし、それらが一致しない場合、当該実行可能なコードは、改竄されたものであるから、装置から信用されることはありえない。当該ダイジェストは、（後述する）トラステッド・コンピューティング・ベース(Trusted Computing Base)におけるコンポーネントによってのみアクセス可能であって、それ自体は安全である。このダイジェストは、ハッシュや実行可能なコードの全体から再計算可能な他のユニークで代替的値であってもよい。
【００１０】
このアプローチは、ハッシュがメディアファイルから導出され、当該ファイルに挿入され、ファイルを気づかれない程度に修正する従来の電子透かしとは異なるものである。
【００１１】
ある実施態様では、ダイジェストは、実行可能なコードの"ケーパビリティ"と同様に、装置上で安全に格納される。"ケーパビリティ"は、特に注意を要する動作(sensitive action)の実行の認可に対応するアクセストークン（access token）として考えることができる。（ケーパビリティモデルの目的は、注意を要する(sensitive)システムリソースへのアクセスを制御することである。）ロード時において、ローダーはロード以前にハッシュを検証する。もし検証に失敗すると、実行可能なコードはロードされないであろう。もし、実行可能なコードが不知（unknown）である場合（関連するダイジェストがない場合）、実行可能なコードはケーパビリティなし（即ち、注意を要するリソースへのアクセス権がない）及び識別子なし（識別されたオペレーティングシステムプロセスにのみ公開されるデータへのアクセス権がない）でロードされる。もし、検証が成功すれば、実行可能なコードはロードされ、新しくロードされたコードに格納されているケーパビリティが割り当てられる。
【００１２】
本発明は、ユーザが、装置間において制約を受けることなくメモリーカード及び他の形態の取り外し可能な媒体を共有することを可能とする。また、媒体や他のユーザの選択とは独立に、ユーザがこれらのカードに格納されているアプリケーションに許可した特権をユーザが維持することを可能とする。
【発明を実施するための形態】
【００１３】
本発明は、シングルユーザ無線装置のために設計されたオブジェクト指向のオペレーティングシステムであるシンビアンＯＳのセキュリティ構造を参照して記載される。シンビアン・オペレーティング・システムは、英国ロンドンのシンビアン・リミテッドにより移動体無線装置のために開発されたものである。
【００１４】
シンビアンＯＳにおけるセキュリティ構造の基本的な概要は、中世の城の防護（a medieval castle defenses）に類似している。類似の形態において、インストール境界（installation perimeter）に加えて、簡単で、スタッガード構造の（staggered）セキュリティレイヤーを採用する。当該モデルが取り扱おうとしている重要な脅威は、ユーザーデータ及びシステムサービス、特にフォンスタック(phone stack)への権原のないアクセスと関連している。フォンスタックはスマートフォンと関連して特に重要である。というのも、フォンスタックが電話ネットワークとの不変のデータ接続(permanent data connection)を制御するからである。当該モデルの後ろに位置する重要なデザインドライバ（key design drivers）が二つある。
【００１５】
その一つは、ケーパビリティベースのアクセス制御を利用した重要なシステムリソースのファイアウォール防護である。
【００１６】
もう一つは、標準的なソフトウェアがアクセスできない、保護された部分をファイルシステムに生成するデータ分割（data partitioning）である。
【００１７】
以下に記載するケーパビリティモデルの主たるコンセプトは、ユーザが何ができるかではなく、プロセスに何ができるかを制御することにある。このアプローチは、ウィンドウズ（登録商標）ＮＴやＵｎｉｘ（登録商標）といった既知のオペレーティングシステムとは極めて異なるものである。その主な理由は、以下のようになる。
【００１８】
〔シングルユーザ用途のシンビアンＯＳの性質〕
【００１９】
シンビアンＯＳは、独立したサーバープロセスを介してサービスを提供している。それらは常に動作しており、かつ、ユーザセッションに付加されることがない。電力が供給されている限り、シンビアンＯＳはユーザがログオンしていない場合であっても常に起動状態にある。
【００２０】
シンビアンＯＳは、技術的知識の無い、多くの公衆に利用される装置において使用されることを目的としている。ソフトウェアのインストール時に、どんな許可をアプリケーションに対して与えるかを決定する能力をユーザが有していなくても良い。さらに、常に接続されている装置に関しては、誤った或いは悪意のある決定の結果は、装置自体よりもドメインに遙かに大きなインパクトを与えるかもしれない。
〔１ トラステッド・コンピューティング・プラットフォーム(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 orthogonal system capabilities）が許可されるであろうし、トラステッド・コンピューティング環境（ＴＣＥ）を構成するであろう。それらは、電話サーバやウィンドウサーバーのようなシステムサーバーを含むであろう。例えば、ウィンドウサーバーは、フォンスタックアクセスのケーパビリティは許可されないだろうし、電話サーバは、キーボードイベントに直接アクセスするケーパビリティは認められないであろう。ここで、できるだけ少ないシステムケーパビリティをソフトウェアコンポーネントに適用して、これらの特権の誤用による潜在的なダメージを制限することを強く薦めるものである。
【００２４】
ＴＣＢは、ＴＣＥの各要素があるサービスのインテグリティを保証するように、システム全体のインテグリティを保証するものである。ＴＣＥは、ＴＣＢ無しには存在し得ない、しかしＴＣＢはそれ自体として存在し、安全な"サンドボックス(sand box)"を各プロセスについて保証することができる。
〔２．プロセスケーパビリティ〕
【００２５】
ケーパビリティは、注意を要する行為（sensitive action）を実行する際の許可に対応するアクセストークン（access token）として考えることができる。ケーパビリティモデルの目的は、注意を要するシステムリソースへのアクセスを制御することである。アクセス制御を必要とする最も重要なリソースは、それ自体で実行可能なカーネル（kernel executive itself）であり、システムケーパビリティ（セクション２．１を参照）は、クライアントがカーネルＡＰＩを介して所定の機能にアクセスするために必要とされる。その他のリソースの全ては、ＩＰＣ（Inter Process Communication：プロセス間通信）を介してアクセスされるユーザ側のサーバに属する。基本的なケーパビリティの小さなセットは、サーバ上での特定のクライアントの動作を取り締まるために定義される。例えば、発呼のケーパビリティ（make calls capability）の所有は、電話サーバを利用するクライアントに認められるであろう。ケーパビリティが存在するリソースへのクライアントのアクセスを取り締まることは、対応するサーバの責任であろう。ケーパビリティはまた、各ライブラリ（ＤＬＬ）及びプログラム（ＥＸＥ）と関連づけられ、カーネルによって保持されるであろうネット・プロセス・ケーパビリティ（net process capabilities）を生成するために実行時に(at run time)ローダーによって結合される。オープンな装置の場合、インストールパッケージに署名するために利用される証明書(certificate)に基づいたソフトウェアのインストールの間、或いは、ユーザによるソフトウェアインストール後のいずれかに、サード・パーティ・ソフトウェアについてケーパビリティが割り当てられる。ケーパビリティの取り締まりは、ローダー、カーネル及び影響を受けるサーバの間で管理されるが、ＩＰＣメカニズムを通じて、カーネルで仲介されたもの（kernel-mediated）となる。
【００２６】
このプロセス・ケーパビリティ・モデルの重要な特徴は以下のようになる。
【００２７】
・ システムサーバーと、これらのエンティティ間でのクライアント−サーバにおけるＩＰＣインタラクションの周りにまずフォーカスされる。
【００２８】
・ ケーパビリティはプロセスと関連づけられ、スレッド(threads)とは関連づけられない。同一プロセスにおけるスレッドは、同一アドレス空間及びメモリアクセス許可を共有する。このことは、あるスレッドにより利用されるであろういかなるデータも、同一プロセス内の他のスレッドの全てがリードし、修正可能であることを意味する。
【００２９】
・ ケーパビリティの取り締まりは、ローダー及びカーネルによって、ターゲットサーバーのケーパビリティ取締りを通じて管理される。カーネルＩＰＣメカニズムは、後者に含まれる。
【００３０】
・ コードが実行されていない場合、ケーパビリティはライブラリ及びプログラムの内部に格納される。ライブラリ及びプログラムに格納されているケーパビリティは修正できない。これは、インストールの間に、トラステッド・コンピューティング・ベースによってのみアクセス可能な場所に格納されるためである。
【００３１】
・ 全てのサーバが、クライアントケーパビリティを扱う必要はない。サーバは、希望する場合にケーパビリティの解釈について責任を負う。
【００３２】
・ この手法に含まれる唯一の暗号は、ソフトウェアのインストールステージに存在し、そこでは証明書（certificates）が適切なルート証明書（suitable root certificate）と照合される。
〔２．１システムケーパビリティ：装置のインテグリティを保護する〕
【００３３】
（ルート： 全てのファイルへのフルアクセス−実行可能なコードと関連づけられたケーパビリティを修正できる）
"ルート"ケーパビリティ−トラステッド・コンピューティング・ベースのみにより利用され、装置内の全てのファイルへのフルアクセスを与える。
【００３４】
（システムケーパビリティ）
あるシステムサーバーは、トラステッド・コンピューティング・ベースへのある特定のアクセスを要求する。オブジェクト指向で実装されているシンビアンＯＳのために、システムサーバーによって要求される種類のリソースは、ほとんどの場合それ専用である。それ故に、あるシステムサーバーは、他のシステムサーバーが要求するものと直交する(orthogonal)、あるシステムケーパビリティが許可されるであろう。例えば、ウィンドウサーバーは、カーネルによって発行されるキーボード及びペンイベントへのアクセスが許可されるであろうが、フォンスタックへのアクセスの許可は得られないであろう。同様に、電話サーバはフォンスタックへのアクセスは許可されるであろうが、カーネルからのイベントを受け取る許可は得られないであろう。
【００３５】
例えば、以下のように称することができる。
【００３６】
WriteSystemData： コンフィギュレーション・システム・データの修正を許可する。
【００３７】
CommDD： 全ての通信及びイーサネット（登録商標）カード装置ドライバへのアクセスを許可する。
【００３８】
DiskAdmin： ディスクの管理タスク（administration task、リフォーマットやドライブの名称変更など）を実行できる。
〔２．２ ユーザに公表されるケーパビリティ(User-exposed capabilities)：実世界許可のマッピング（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)"
ルート及びシステムのケーパビリティは、強制的なものである。もし実行可能なコードに対して許可されなければ、装置のユーザは該コードの実行を決定できない。それらの厳格な制御により、トラステッド・コンピューティング・プラットフォームのインテグリティが保証される。しかしながら、サーバがユーザに公表されたケーパビリティ（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)はＬ１．ＤＬＬ内にあるという事実は、ここでは不適切である。ルール１及び３が前のように適用され、Ｌ１．ＤＬＬのロードによっては、ＰがＣａｐ３を取得することはない。
【００５８】
（ケース２）
Ｐ．ＥＸＥは、Ｃａｐ１及びＣａｐ２を保持する。
Ｌ１．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ３を保持する。
Ｌ０．ＤＬＬは、Ｃａｐ１、Ｃａｐ２及びＣａｐ４を保持する。
プロセスＰは無事生成され、Ｃａｐ１及びＣａｐ２が割り当てられる。Ｐが、ローダーにＬ１．ＤＬＬとＬ０．ＤＬＬをロードすることを要求すると、ローダーはそれに成功する。これは、ＰがＬ１．ＤＬＬとＬ０．ＤＬＬをロードできるからである。ここで再度、ルール２が、Ｌ１．ＤＬＬではなく、ロードする実行可能なコードであるＰに適用され、その一方で、ルール３により、ＰはＣａｐ３及びＣａｐ４のいずれも取得しないことが確定される。
〔２．４ 取り外し可能な媒体の柔軟性をどのようにプラットフォーム・セキュリティと結びつけるか〕
〔２．４．１ 今日〕
〔２．４．１．１ 装置のインテグリティ〕
【００５９】
今日、取り外し可能な媒体に格納されているファイルは完全に無防備である。それらは、完全にアクセス可能であり、修正を受けることができる。取り外し可能な媒体が装置に再度接続されると、システムのインテグリティを保証するためのチェックは一切実行されない。この事実と関連するリスクは、低く見られているかもしれない。というのも、媒体の所有はサブヴァージョン(subversion)のために必要とされるからである。しかしながら、例えば、悪意のあるユーザはマルウェア（malware）をインストールして、装置にはダメージを与えないが、ネットワークオペレータに対する武器として利用するかもしれない。今日、プラットフォーム・セキュリティを除けば、取り外し可能な媒体からのコードのロードを拒否するローダーを利用するしか保護の術はない。しかしながら、長い目で見れば、より多くのスペースがより多くのアプリケーションを格納するために必要とされ、この方法では、ユーザが装置用にソフトウェアを購入することの妨げとなってしまい、もしそれを利用することができないのであればオープンなプラットフォームを購入することを、暗黙のうちに阻止することとなってしまう。
〔２．４．１．２ データの守秘性（confidentiality）〕
【００６０】
データの守秘性に対する脅威は現実のものであるが、盗まれた取り外し可能な媒体に含まれるデータのみに限られる。このような脅威の大半は、次のようなプラットフォーム・セキュリティのサポートに依らずに既に防止することができる。
【００６１】
（１．媒体へのハードウェア・コントロール・アクセス）
平均的な装置では、例えば、セキュアＭＭＣ(Secure MMC)、ＰＩＮ保護されたＳＩＭ（PIN-protected SIM）媒体はパスワードにより保護される。
【００６２】
（２．ファイル暗号化）
ユーザがある注意を要するデータ（sensitive data）のセキュリティに関心を有し、そのデータを取り外し可能な媒体に格納するならば、該ユーザは暗号化を行うことが好ましい。
【００６３】
（３．ファイルシステム暗号化）
ファイルシステム暗号化は、ディスク装置ドライバレベルにおいて提供されるのが好ましい。
〔２．４．２ 提案に係る発明〕
【００６４】
提案に係る本発明は、現在の脅威を防止するだけでなく、取り外し可能な媒体の相互運用性（interoperability）及びコード分配利用（code distribution uses）を維持することをも目的とする。
【００６５】
プラットフォーム・セキュリティ構造では、取り外し可能な媒体が装置から取り外された場合になされる修正を防止することはできない。パスワードで保護された取り外し可能な媒体であっても、権限のあるユーザはそれを変更することができる。ゆえに、最も好ましいプラットフォーム・セキュリティは、既知の実行可能なコードについてはタンパーエビデンス機能(tamper evidence mechanism)を提供し、不知のコードについては安全な実行を提供することができる。
〔２．４．２．１ ソフトウェア・インストーラ〕
【００６６】
インストール時において、アプリケーションパッケージが取り外し可能な媒体に格納されるべきである場合：
ステップ１．ソフトウェア・インストーラは、取り外し可能な媒体にインストールされようとしている実行可能なコードが、正しいセキュア識別子（ＳＩＤ）を有し、かつ、他の正当な実行可能なコードになりすまして、そのプライベートデータにアクセスしようとしていないか、を検証する。
【００６７】
ステップ２．ソフトウェア・インストーラは、幾つかのシステム及びユーザのケーパビリティを、アプリケーションパッケージに含まれている実行可能なコードに割り当てる。
【００６８】
ステップ３．ソフトウェア・インストーラは、実行可能なコードをハッシュする。
【００６９】
ステップ４．ソフトウェア・インストーラは、全てのケーパビリティとハッシュ結果（即ち、ダイジェスト）を（例えば、移動不可能な）不変のファイルシステムのＴＣＢで制限されたエリア（TCB-restricted area of a permanent file system）に格納する。
【００７０】
デインストール時（de-install time）には、ソフトウェア・インストーラは実行可能なコードが存在する場合にはそれを取り外し可能な媒体から除去し、インストールステップ４において生成された関連ファイルを破壊する。
【００７１】
プレフォーマットされた取り外し可能な媒体（既にインストールされたファイル）については、ソフトウェア・インストーラにステップ１から３を実行させるために、アプリケーションパッケージの簡素なバージョン（lighter version）が提供されなければならない。本発明は、プリフォーマットされた取り外し可能な媒体上の新しいアプリケーションを検出するための装置を、いかなるものにも限定することはない。可能性のあるオプションとしては、無線装置へ取り外し可能な媒体が挿入された時点において新しいアプリケーションの存在を検出してもよいし、プリフォーマットされた取り外し可能な媒体の除去を、それが含むアプリケーションのデインストールの際に考慮してもよい。
〔２．４．２．２ ローダー(Loader)〕
【００７２】
ロード時において、ローダーは取り外し可能な媒体からロードするために実行可能なコードを識別する。ローダーは、対応するＨＡＳＨファイル、（例えば、移動不可能な）不変のファイルシステムのＴＣＢで制限されたエリア（TCB-restricted area of a permanent file system）に格納されたハッシュ結果、を参照する。
【００７３】
・ もし、該ハッシュファイルが存在する場合、実行可能なコードをハッシュして、両ハッシュ結果を比較する。
【００７４】
・ もし両者が一致する場合、ローダーはＨＡＳＨファイルから抽出されたシステム及びユーザのケーパビリティを、該実行可能なコードに割り当てて、通常のローディング処理を実行する。
【００７５】
・ もし両者が一致しない場合、ローダーはエラーを返す。
【００７６】
・ もし、対応するＨＡＳＨファイルが存在しない場合、ローダーは、システム及びユーザのケーパビリティを、該実行可能なコードに割り当てることはせずに、通常のローディング処理を実行する。ローダーは、当該"不知のコード（unknown）"にセキュア識別子（ＳＩＤ）を割り当てて（プロセスの該ＳＩＤ（セキュア識別子）は、ＯＳ上で実行可能なコードの一部をユニークに識別するための手法であって、関連する実行可能なコードに格納されている）、正当なプロセスへのなりすましを防止する。ケーパビリティ及びＳＩＤが不知のコードには許可されないので、このコードはトラステッド・コンピューティング・プラットフォームのインテグリティを危うくすることはない。
【００７７】
ハッシュ処理(hashing process)は、取り外し可能な媒体とは独立でなければならない。実行されるべきは、コードの一部の認証であって、それを提供する取り外し可能な媒体の認証ではない。好適な実施態様では、無線装置において利用するのに合理的な安全性と高速性を有する点から、ＳＨＡ−１が利用される。
〔２．４．３ 利用ケース（Use cases）〕
〔２．４．３．１ アクター（Actors）〕
【００７８】
１．Ｕは、ユーザである。
２．Ｐ１、Ｐ２は、Ｕによって所有されている２つの無線装置である。
３．Ｃ１、Ｃ２は、Ｕによって所有されている２つの取り外し可能な媒体である。
４．ＡＰＰは、実行可能なコードを１つのみ有するアプリケーションである。
５．ローダー
６．ＳＷＩｎｓｔａｌｌは、ソフトウェア・インストーラである。
７．ＥＴＥＬは、電話ネットワークへのアクセスを制御するプロセスである。
〔２．４．３．２ 仮定（Assumptions）〕
【００７９】
１．ＡＰＰは、PhoneNetworkケーパビリティを有する署名されたアプリケーションパッケージＡＰＰ．ｓｉｓとして配信される。
２．Ｃ：は、内部ドライブである。
３．Ｄ：は、取り外し可能な媒体用のドライブである。
４．Ｃ１はＡＰＰ．ｓｉｓをルート下に含む。ＡＰＰ．ｓｉｓは、ＡＰＰのインストレーション・パッケージである。
〔２．４．３．３ 利用ケース１−ＵがＰ１にＡＰＰをインストールする〕
【００８０】
１．ＵはＣ１をＰ１に接続する。
２．ＵはＰ１を利用する。
３．Ｕは、ＳＷＩｎｓｔａｌｌに、Ｄ：＼ＡＰＰ．ｓｉｓをドライブＤ：＼にインストールすることを依頼する。
４．ＳＷＩｎｓｔａｌｌは、署名証明書（signing certificate）を検証する。｛Ｅ１｝
５．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐを抽出する。
６．ＳＷＩｎｓｔａｌｌは、システム及びユーザのケーパビリティを実行可能なコードから除去し、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ(directory accessible to TCB only)＞＼ＡＰＰ．ｃａｐへコピーする。
７．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをハッシュして、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐに格納する。
８．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤ：へコピーする。
９．ＳＷＩｎｓｔａｌｌは、インストールを完了する。
【００８１】
Ｅ１−有効でない署名
１．利用ケース終了。
〔２．４．３．４ 利用ケース２−ＵがＣ１をＣ２にオフラインでコピーし、Ｃ２をＰ１で利用する〕
【００８２】
１．ＵはＣ１をＣ２にオフラインでコピーする。
２．ＵはＣ２をＰ１に接続する。
３．ＵはＰ１を利用する。
４．Ｕは、ローダーにＡＰＰの開始を依頼する。
５．ローダーはＡＰＰ．ａｐｐをＤ：＼に発見する。
６．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
７．ローダーは、ハッシュ結果の検証に成功する。｛Ｅ２｝
８．ローダーは、システム及びユーザのケーパビリティをＡＰＰ．ｃａｐから抽出する。
９．ローダーはＡＰＰ．ａｐｐをロードし、ＡＰＰ．ａｐｐにケーパビリティを割り当てる。
１０．Ｕは、ＡＰＰに番号のダイヤルを依頼する。
１１．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
１２．ＥＴＥＬは、ＡＰＰがPhoneNetworkを取得したことのチェックに成功する。
１３．ＥＴＥＬは番号をダイヤルする。
１４．Ｕは電話接続を利用する。
【００８３】
Ｅ２−ハッシュは一致しない
１．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラー（Binary Hash Mismatch error）を返す。
２．ＵはＡＰＰを利用できない。
〔２．４．３．５ 利用ケース３−ＵがＣ１をＰ２で利用する〕
【００８４】
１．ＵはＣ１をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはローダーにＡＰＰの開始を依頼する。
４．ローダーはＡＰＰ．ａｐｐをＤ：＼に発見する。
５．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを発見しない。
６．ローダーはＡＰＰ．ａｐｐをロードし、ＡＰＰ．ａｐｐに、ユーザ及びシステムのケーパビリティを割り当てない。
７．Ｕは、ＡＰＰに番号のダイヤルを依頼する。
８．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
９．ＥＴＥＬは、ＡＰＰがPhoneNetworkを取得していないことを検出する。
１０．ＥＴＥＬは、電話をかけたいかどうかをＵに問い合わせる。
１１．Ｕは許可する（U accepts）。｛Ｅ１｝
１２．ＥＴＥＬは番号をダイヤルする。
１３．Ｕは電話接続を利用する。
【００８５】
Ｅ１−Ｕは許可しない(U does not accept)
１．ＥＴＥＬは番号をダイヤルしない。
２．ＡＰＰはＵに対してエラーを表示する。
【００８６】
〔２．４．３．６ 利用ケース４−ＵはＡＰＰをＰ２にインストールし、ＡＰＰのPhoneNetworkをデモートする（demote）〕
【００８７】
１．ＵはＣ１をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはＰ２のＤ：＼にＡＰＰをインストールすることに成功する。（利用ケース１を参照。）
４．Ｕは、ＳＷＩｎｓｔａｌｌに、ＡＰＰのケーパビリティからPhoneNetworkを除去することを依頼する。
５．ＳＷＩｎｓｔａｌｌは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを修正し、ファイル内のユーザのケーパビリティをリセットする。
６．Ｕは、ローダーにＡＰＰの開始を依頼する。
７．ローダはＤ：＼にＡＰＰ．ａｐｐを発見する。
８．ローダーはｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
９．ローダーはハッシュ結果の検証に成功する。｛Ｅ２｝
１０．ローダーはケーパビリティをＡＰＰ．ｃａｐから抽出する。
１１．ローダーは、ＡＰＰ．ａｐｐをロードし、ケーパビリティをＡＰＰ．ａｐｐに割り当てる。
１２．ＵはＡＰＰに番号のダイヤルを依頼する。
１３．ＡＰＰはＥＴＥＬに番号のダイヤルを依頼する。
１４．ＥＴＥＬはＡＰＰがPhoneNetworkを取得していないことを検出する。
１５．ＥＴＥＬは、電話をかけたいかどうかをＵに問い合わせる。
１６．Ｕは許可する。｛Ｅ１｝
１７．ＥＴＥＬは番号をダイヤルする。
１８．Ｕは電話接続を利用する。
１９．ＵはＣ１をＰ１に接続する。
２０．ＵはＡＰＰに番号のダイヤルを依頼する。
２１．ＡＰＰは、ＥＴＥＬに番号のダイヤルを依頼する。
２２．ＥＴＥＬはＡＰＰがPhoneNetworkを取得したことのチェックに成功する。
２３．ＥＴＥＬは番号をダイヤルする。
２４．Ｕは電話接続を利用する。
【００８８】
Ｅ１−Ｕは許可しない。
１．ＥＴＥＬは番号をダイヤルしない。
２．ＡＰＰはＵに対してエラーを表示する。
【００８９】
Ｅ２−ハッシュ結果が不一致
１．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
２．ＵはＡＰＰを利用できない。
〔２．４．３．７ 利用ケース５−Ｕは、Ｐ２からＣ２を利用してＡＰＰをアンインストールする〕
【００９０】
１．ＵはＣ２をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはＳＷＩｎｓｔａｌｌにＡＰＰのアンインストールを依頼する。
４．ＳＷＩｎｓｔａｌｌは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを削除する。
５．ＳＷＩｎｓｔａｌｌは、ＵにＤ：上での削除の承認を依頼する。
６．Ｕは承認する。｛Ｅ１｝
７．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤ：から削除する。
８．ＵはＣ２をＰ１又はＰ２上で利用してＡＰＰを開始することができない。
【００９１】
Ｅ２−Ｕは承認しない。
１．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤから削除しない。
２．ＵはＣ２をＰ１で利用してＡＰＰを開始することができる。
〔２．４．３．８ 利用ケース６−ＵはＡＰＰ．ａｐｐをハックし、幾つかのシステムケーパビリティを追加する〕
【００９２】
１．Ｕは、Ｃ１上でオフラインでＡＰＰ．ａｐｐシステムケーパビリティを修正する。
２．ＵはＣ１をＰ１に接続する。
３．ＵはＰ１を利用する。
４．ＵはローダーにＡＰＰの開始を依頼する。
５．ローダーはＤ：にＡＰＰ．ａｐｐを発見する。
６．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
７．ローダーはハッシュの検証に失敗する。
８．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
９．ＵはＡＰＰを利用できない。
〔２．４．３．９ 結論〕
【００９３】
これらの利用ケースは、プラットフォーム・セキュリティにおいても、取り外し可能な媒体により提供される以下の柔軟性が維持されることを示している。
・ 異なるユーザケーパビリティ設定を有する装置間においてカードを共有すること。
・ カードを複製し、当該複製されたものを制限なく利用すること。
・ 取り外し可能な媒体から取得されるコードを安全に実行すること。
【特許請求の範囲】
【請求項１】
移動体無線装置であって、
通常の使用時に容易に着脱可能な媒体上のネイティブで実行可能なコードをインストール可能にプログラムされていることと；
前記コードのダイジェストを計算し、前記移動体無線装置内の取り外しできない固定的な格納部に格納するようにプログラムされていることと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算するようにプログラムされていることと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制するようにプログラムされていることと；
を特徴とする、移動体無線装置。
【請求項２】
前記格納されているダイジェストを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１に記載の移動体無線装置。
【請求項３】
前記実行可能なコードのケーパビリティを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１または２に記載の移動体無線装置。
【請求項４】
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードはケーパビリティ及び識別子なしでロードされることを特徴とする請求項１から３のいずれかに記載の装置。
【請求項５】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないように構成される、請求項１から４のいずれかに記載の移動体無線装置。
【請求項６】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てるように構成される請求項１から５のいずれかに記載の移動体無線装置。
【請求項７】
通常の使用時に容易に着脱可能な媒体に格納された実行可能なコードを利用することに関する処理において、移動体無線装置のコンピュータが、コンピュータ読み取り可能な命令に従って実行する方法であって、
前記コードの第１のダイジェストを計算し、前記移動体無線装置内の取り外しのできない固定的格納部に格納することと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算することと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制することと；
を含む、方法。
【請求項８】
前記格納されているダイジェストは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能である、請求項７に記載の方法。
【請求項９】
前記実行可能なコードのケーパビリティは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能であるように格納される、請求項７または８に記載の方法。
【請求項１０】
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードをケーパビリティ及び識別子なしでロードすることを含む、請求項７から９のいずれかに記載の方法。
【請求項１１】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないことを含む、請求項７から１０のいずれかに記載の方法。
【請求項１２】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てることを含む、請求項７から１１のいずれかに記載の方法。
【請求項１３】
請求項７から１２のいずれかに記載の方法を、移動体無線装置のコンピュータに実行させる命令を含む、コンピュータ・プログラム。
【請求項１】
移動体無線装置であって、
通常の使用時に容易に着脱可能な媒体上のネイティブで実行可能なコードをインストール可能にプログラムされていることと；
前記コードのダイジェストを計算し、前記移動体無線装置内の取り外しできない固定的な格納部に格納するようにプログラムされていることと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算するようにプログラムされていることと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制するようにプログラムされていることと；
を特徴とする、移動体無線装置。
【請求項２】
前記格納されているダイジェストを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１に記載の移動体無線装置。
【請求項３】
前記実行可能なコードのケーパビリティを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１または２に記載の移動体無線装置。
【請求項４】
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードはケーパビリティ及び識別子なしでロードされることを特徴とする請求項１から３のいずれかに記載の装置。
【請求項５】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないように構成される、請求項１から４のいずれかに記載の移動体無線装置。
【請求項６】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てるように構成される請求項１から５のいずれかに記載の移動体無線装置。
【請求項７】
通常の使用時に容易に着脱可能な媒体に格納された実行可能なコードを利用することに関する処理において、移動体無線装置のコンピュータが、コンピュータ読み取り可能な命令に従って実行する方法であって、
前記コードの第１のダイジェストを計算し、前記移動体無線装置内の取り外しのできない固定的格納部に格納することと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算することと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制することと；
を含む、方法。
【請求項８】
前記格納されているダイジェストは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能である、請求項７に記載の方法。
【請求項９】
前記実行可能なコードのケーパビリティは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能であるように格納される、請求項７または８に記載の方法。
【請求項１０】
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードをケーパビリティ及び識別子なしでロードすることを含む、請求項７から９のいずれかに記載の方法。
【請求項１１】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないことを含む、請求項７から１０のいずれかに記載の方法。
【請求項１２】
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てることを含む、請求項７から１１のいずれかに記載の方法。
【請求項１３】
請求項７から１２のいずれかに記載の方法を、移動体無線装置のコンピュータに実行させる命令を含む、コンピュータ・プログラム。
【公開番号】特開２０１０−２０５２７０（Ｐ２０１０−２０５２７０Ａ）
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願番号】特願２０１０−５７０９７（Ｐ２０１０−５７０９７）
【出願日】平成２２年３月１５日（２０１０．３．１５）
【分割の表示】特願２００４−５０７９７１（Ｐ２００４−５０７９７１）の分割
【原出願日】平成１５年５月２８日（２００３．５．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公開日】平成２２年９月１６日（２０１０．９．１６）
【国際特許分類】
【出願日】平成２２年３月１５日（２０１０．３．１５）
【分割の表示】特願２００４−５０７９７１（Ｐ２００４−５０７９７１）の分割
【原出願日】平成１５年５月２８日（２００３．５．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]