JP4526383B2

JP4526383B2 - 実行可能なコードを格納するタンパーエビデントな取り外し可能な媒体

Info

Publication number: JP4526383B2
Application number: JP2004507971A
Authority: JP
Inventors: コリンヌディヴ−ルクリュー，
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-05-28
Filing date: 2003-05-28
Publication date: 2010-08-18
Anticipated expiration: 2023-05-28
Also published as: JP2010205270A; ES2265105T3; AU2003234040A1; EP1512060A1; WO2003100583A1; EP1512060B1; JP2005527905A; DK1512060T3; GB0312199D0; ATE326718T1; JP4975127B2; DE60305315T2; GB2390918B; GB2390918A; US8205094B2; US20050216907A1; DE60305315D1; GB0212318D0

Description

本発明は、取り外し可能な（リムーバブルな）媒体に格納された実行可能なコードにタンパーエビデント性（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 defences）に類似している。類似の形態において、インストール境界（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 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)”
ルート及びシステムのケーパビリティは、強制的なものである。もし実行可能なコードに対して許可されなければ、装置のユーザーは該コードの実行を決定できない。それらの厳格な制御により、トラステッド・コンピューティング・プラットフォームのインテグリティが保証される。しかしながら、サーバーがユーザに公表されたケーパビリティ（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を取得したことのチェックに成功する。
２３．ＥＴＥＬは番号をダイヤルする。
２４．Ｕは電話接続を利用する。

Ｅ１−Ｕは許可しない。
１．ＥＴＥＬは番号をダイヤルしない。
２．ＡＰＰはＵに対してエラーを表示する。

Ｅ２−ハッシュ結果が不一致
１．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
２．ＵはＡＰＰを利用できない。

２．４．３．７利用ケース５−Ｕは、Ｐ２からＣ２を利用してＡＰＰをアンインストールする
１．ＵはＣ２をＰ２に接続する。
２．ＵはＰ２を利用する。
３．ＵはＳＷＩｎｓｔａｌｌにＡＰＰのアンインストールを依頼する。
４．ＳＷＩｎｓｔａｌｌは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを削除する。
５．ＳＷＩｎｓｔａｌｌは、ＵにＤ：上での削除の承認を依頼する。
６．Ｕは承認する。｛Ｅ１｝
７．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤ：から削除する。
８．ＵはＣ２をＰ１又はＰ２上で利用してＡＰＰを開始することができない。

Ｅ２−Ｕは承認しない。
１．ＳＷＩｎｓｔａｌｌは、ＡＰＰ．ａｐｐをＤから削除しない。
２．ＵはＣ２をＰ１で利用してＡＰＰを開始することができる。

２．４．３．８利用ケース６−ＵはＡＰＰ．ａｐｐをハックし、幾つかのシステムケーパビリティを追加する
１．Ｕは、Ｃ１上でオフラインでＡＰＰ．ａｐｐシステムケーパビリティを修正する。
２．ＵはＣ１をＰ１に接続する。
３．ＵはＰ１を利用する。
４．ＵはローダーにＡＰＰの開始を依頼する。
５．ローダーはＤ：にＡＰＰ．ａｐｐを発見する。
６．ローダーは、ｃ：＼＜ＴＣＢのみがアクセス可能なディレクトリ＞＼ＡＰＰ．ｃａｐを開く。
７．ローダーはハッシュの検証に失敗する。
８．ローダーはＡＰＰをロードせず、バイナリハッシュ不一致エラーを返す。
９．ＵはＡＰＰを利用できない。

２．４．３．９結論
これらの利用ケースは、プラットフォーム・セキュリティにおいても、取り外し可能な媒体により提供される以下の柔軟性が維持されることを示している。
−異なるユーザケーパビリティ設定を有する装置間においてカードを共有すること
−カードを複製し、当該複製されたものを制限なく利用すること
−取り外し可能な媒体から取得されるコードを安全に実行すること

Claims

移動体無線装置であって、
取り外し可能な媒体上のネイティブで実行可能なコードをインストール可能にプログラムされていることと；
前記コードのダイジェストを計算し、前記移動体無線装置内の取り外しできない固定的な格納部に格納するようにプログラムされていることと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算するようにプログラムされていることと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制するようにプログラムされていることと；
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードをケーパビリティ及び識別子なしでロードするように構成されることと；
を特徴とする、移動体無線装置。
前記格納されているダイジェストを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１に記載の移動体無線装置。
前記実行可能なコードのケーパビリティを、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能とするように構成される、請求項１または２に記載の移動体無線装置。
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないように構成される、請求項１から３のいずれかに記載の移動体無線装置。
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てるように構成される請求項１から４のいずれかに記載の移動体無線装置。
取り外し可能な媒体に格納された実行可能なコードを利用することに関する処理において、移動体無線装置のコンピュータが、コンピュータ読み取り可能な命令に従って実行する方法であって、
前記コードの第１のダイジェストを計算し、前記移動体無線装置内の取り外しのできない固定的格納部に格納することと；
前記取り外し可能な媒体が前記移動体無線装置に再度接続され、前記コードが呼び出された場合に、前記移動体無線装置は、前記取り外し可能な媒体よりロードしようとするコードからダイジェストを再計算することと；
前記再計算したダイジェストと、前記取り外しできない固定的な格納部に格納されているダイジェストとを比較して、前記再計算したダイジェストと前記格納されているダイジェストとが異なる場合は、前記ロードしようとするコードの利用を抑制することと；
前記実行可能なコードについてのダイジェストが格納されていないため、前記比較ができない場合、前記実行可能なコードをケーパビリティ及び識別子なしでロードすることと；
を含む、方法。
前記格納されているダイジェストは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能である、請求項６に記載の方法。
前記実行可能なコードのケーパビリティは、トラステッド・コンピューティング・ベースのコンポーネントによってのみアクセス可能であるように格納される、請求項６または７に記載の方法。
前記再計算したダイジェストと、前記格納されているダイジェストとが一致しない場合は、前記実行可能なコードをロードしないことを含む、請求項６から８のいずれかに記載の方法。
前記再計算したダイジェストと、前記格納されているダイジェストとが一致した場合、前記移動体無線装置に格納されているケーパビリティを前記実行可能なコードに割り当てることを含む、請求項６から９のいずれかに記載の方法。
請求項６から１０のいずれかに記載の方法を、移動体無線装置のコンピュータに実行させる命令を含む、コンピュータ・プログラム。