JP2019505887A - 信頼できる実行環境を有するモバイル装置 - Google Patents

Abstract

モバイル装置上で実行するためのモバイルａｐｐを安全にするための機構。この機構は、モバイルａｐｐの信頼できない部分を信頼できないアプリケーションプロバイダからモバイル装置にロードすることと、キー提供サーバを動作させて信頼できる実行環境と関連付けられたキーを生成し、信頼できる実行環境と関連付けられたキーをモバイル装置およびキーディレクトリサーバに送信することと、モバイル装置を認証することと、モバイル装置を認証すると、信頼できるアプリケーションを含むモバイルａｐｐの信頼できる部分をモバイル装置に送信することと、モバイルａｐｐの信頼できる部分をモバイル装置にインストールし、それにより、信頼できる実行環境を提供することとを含む。他のシステムおよび方法が開示される。

Description

本発明は一般に、モバイル装置に関し、より詳細には、信頼できる実行環境を有するモバイル装置、および、モバイル装置にロードされ実行される信頼できるアプリケーションのライフサイクルを通して、こうした信頼できるアプリケーションのセキュリティを管理することを提供することに関する。

モバイル通信装置の短い歴史において、装置は、主としてまたは完全に携帯電話通信のみに供せられるものから、非常に強力な多用途の装置へと急速に進化してきた。最近の技術の進歩とともに、モバイル装置たとえば携帯電話を、支払い、交通機関の切符発売、ポイントプログラム、銀行口座アクセス、建物または事務所への物理的アクセス制御などといった異なる用途に今や使用可能である。近距離無線通信は、こうした新しい機能をモバイル装置上で可能とする１つの実現技術である。

セキュリティは、多くのこうした機能についての重要な基準である。たとえば、成功する商用プログラムにとって、モバイル取引は安全であり、口座番号、取引パターン、個人データ、または、取引を安全なものとする際に使用される暗号キーといった情報を盗もうとする攻撃者によって容易に傍受されないといった信用を有することができることは、しばしば必要な要素である。

モバイル装置の主プロセッサの安全な領域である信頼できる実行環境（ＴＥＥ）は、あるモバイル装置上で実行するアプリケーションの強化されたセキュリティのための１つの機構を提供する。信頼できる実行環境はハードウェア内に実装される。ＴＥＥは、信頼できるアプリケーションのための隔離された実行環境を提供し、それにより、より高いレベルのセキュリティを提供する。

ＧｌｏｂａｌＰｌａｔｆｏｒｍは、標準化された信頼できる実行環境（ＴＥＥ）を提供することを含む、安全なチップ技術に基づく安全なコンピューティングのための仕様を公表している。ＴＥＥは主プロセッサ内に、信頼できる環境内で秘密データが記憶され、処理され、保護されることを保証する安全な領域を備えている。ＧｌｏｂａｌＰｌａｔｆｏｒｍは、標準的なアプリケーションプログラムインタフェース（ＡＰＩ）を提供する。ａｐｐとしても知られるアプリケーションプログラムは、ＡＰＩを通して、ＧｌｏｂａｌＰｌａｔｆｏｒｍの信頼できる実行環境の安全なプロセッサ領域によって提供される安全な機能にアクセスすることができる。

商用のＴＥＥソリューションの一例は、ＡＲＭ社、英国、ケンブリッジが提供するＡＲＭ ＴｒｕｓｔＺｏｎｅ技術である（ｈｔｔｐ：／／ｗｗｗ．ａｒｍ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｐｒｏｃｅｓｓｏｒｓ／ｔｅｃｈｎｏｌｏｇｉｅｓ／ｔｒｕｓｔｚｏｎｅ／）。ＴｒｕｓｔＺｏｎｅ技術は、プロセッサと強固に統合されている一方、安全な環境をプロセッサの外側、たとえばメモリおよび暗号ブロックといった周辺機器に拡張し、たとえばＴｒｕｓｔｅｄ Ａｐｐｌｉｃａｔｉｏｎｓといったセキュリティ意識の高いアプリケーションに対してシステム全体にわたるセキュリティを可能とする。

あいにく、多くのモバイル装置は、信頼できる実行環境をハードウェアに実装する技術を装備していない。しかし、このことは、こうしたより制限された装置に、信頼できる実行環境のような安全なコンピューティング機能を提供する必要性を減少させることにはならない。そうでなければ、装置上で実行するアプリケーションは、装置のユーザの秘密情報を暴露し、または、ユーザもしくはサービスプロバイダに経済的な損失を生じさせる恐れのあるマルウェア、および、広範な考えられる攻撃に対して脆弱である。

上述のことから、プロセッサのハードウェア内に実装された安全な領域を装備していない装置に対して、安全な信頼できる実行環境を提供するための、柔軟で使いやすくなおかつ強力な機構を提供する改良された方法が依然として必要であることは明らかであろう。理想的には、こうしたソリューションは、たとえばＧｌｏｂａｌＰｌａｔｆｏｒｍによって提供される、信頼できる実行環境ソリューションのハードウェア実装と互換性があり、それにより、プロセッサベースの信頼できる実行環境、ならびに、こうしたハードウェアを必要としない代替機構で実行するａｐｐを開発することができる。

上述のことから、ハードウェアＴＥＥの特定のハードウェア機能を欠くモバイル装置上に、ハードウェア実装されたＴＥＥと等しいセキュリティ強化を提供するための改良された方法が依然として必要なことは明らかであろう。

ＡＲＭ社、英国、ケンブリッジ、ＴｒｕｓｔＺｏｎｅ、ｈｔｔｐ：／／ｗｗｗ．ａｒｍ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｐｒｏｃｅｓｓｏｒｓ／ｔｅｃｈｎｏｌｏｇｉｅｓ／ｔｒｕｓｔｚｏｎｅ／ ＴＥＥクライアントＡＰＩ仕様ｖ１．０ ＧＰＤ＿ＳＰＥ＿００７、ＧｌｏｂａｌＰｌａｔｆｏｒｍ、２０１１年１２月（ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂａｌｐｌａｔｆｏｒｍ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓｄｅｖｉｃｅ．ａｓｐ） Ｓ．Ｃｈｏｗ、Ｐ．Ｅｉｓｅｎ、Ｈ．Ｊｏｈｎｓｏｎ、Ｐ．Ｃ．ｖａｎ Ｏｏｒｓｃｈｏｔ、Ｗｈｉｔｅ−Ｂｏｘ Ｃｒｙｐｔｏｇｒａｐｈｙ ａｎｄ ａｎ ＡＥＳ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ、第９回年次ワークショップ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ（ＳＡＣ ２００２）、８月１５−１６日 ２００２年 Ｊｕｌｉｅｎ Ｂｒｉｎｇｅｒ、Ｈｅｒｖｅ Ｃｈａｂａｎｎｅ、およびＥｍｍａｎｕｅｌｌｅ Ｄｏｔｔａｘ、Ｗｈｉｔｅ Ｂｏｘ Ｃｒｙｐｔｏｇｒａｐｈｙ：Ａ Ｎｅｗ Ａｔｔｅｍｐｔ、Ｃｒｙｐｔｏｌｏｇｙ ｅＰｒｉｎｔ Ａｒｃｈｉｖｅ、レポート２００６／４６８、２００６年 第３世代パートナーシッププロジェクトの３ＧＰＰ ＴＳ２３．００３仕様書

本発明の実施形態の諸態様は一般に、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法であって、モバイル装置は、
信頼できないアプリケーションプロバイダからのモバイルアプリケーションの信頼できない部分を、モバイル装置にロードし、
信頼できるアプリケーションプロバイダからのモバイルアプリケーションの信頼できる部分を、モバイル装置にロードし、
モバイルアプリケーションの信頼できる部分をモバイル装置にインストールし、それによって信頼できる実行環境を提供する
ように構成されることを含む、方法に関する。

本発明の一実施形態によれば、モバイルアプリケーションの信頼できる部分をモバイル装置にロードすることは、
モバイルアプリケーションが、モバイルアプリケーションの識別子およびモバイル装置の装置フィンガープリントから、信頼できる実行環境ｉｄ ＴＥＥ ＩＤを生成するステップであって、前記生成された信頼できる実行環境ｉｄ ＴＥＥ ＩＤが、モバイルアプリケーションによってキー提供サーバに送信されるステップと、
キー提供サーバを動作させて、信頼できる実行環境ｉｄ ＴＥＥ ＩＤと関連付けられるキーを生成し、キーディレクタに、信頼できる実行環境ｉｄ ＴＥＥ ＩＤおよび生成されたキーを送信し、モバイル装置に、生成されたキーを送信するステップと、
信頼できるアプリケーションプロバイダが、ＴＥＥ ＩＤ、および、モバイル装置によって送信された生成されたキーから計算されたＴＥＥ ＩＤのハッシュを受信し、キーディレクタサーバを通してモバイル装置を認証するように構成されるステップと、
モバイル装置を成功裏に認証した際に、信頼できるアプリケーションプロバイダを動作させて、信頼できるアプリケーションを含むモバイルアプリケーションの信頼できる部分をモバイル装置に送信するステップと、
モバイル装置が、モバイルアプリケーションの信頼できる部分をモバイル装置にインストールするように構成され、それにより、信頼できる実行環境を提供するステップと、
を含む。

本発明の一実施形態によれば、モバイルアプリケーションの信頼できない部分は、
モバイル装置のリッチ実行環境内で実行可能なクライアントアプリケーションと、
信頼できるアプリケーションを実装できる命令セットのための信頼できるアプリケーションインタープリタと、
を含む。

本発明の一実施形態によれば、信頼できるアプリケーションは、信頼できるアプリケーションインタープリタによって解釈できる命令セット内で実装される。

本発明の一実施形態によれば、モバイルアプリケーションに関連付けられたキーは、ホワイトボックスキー「ＷＢＣキー」およびイニシャルピン（ｐｉｎ）暗号キー「ＩＰＥＫ」を含み、さらに、方法は、モバイルアプリケーションと関連付けられたキーをモバイル装置に送信する前に、ＷＢＣキーを使用してＩＰＥＫを暗号化することを含み、ＩＰＥＫの暗号化バージョンがモバイル装置に送信される。

本発明の一実施形態によれば、モバイルアプリケーションの信頼できる部分は、信頼できるサーバプロバイダによってモバイル装置に送信される前に、イニシャルピン暗号キー「ＩＰＥＣ」から生成されたセッションキーを使用して暗号化される。

本発明の一実施形態によれば、モバイルアプリケーションの信頼できない部分は、信頼できる実行環境のハードウェア実装に似た機能を実装する、アプリケーションプログラムインタフェースを含む。

本発明の一実施形態によれば、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法は、
信頼できるアプリケーションを信頼できる安全な記憶装置と関連付けるステップと、
最初のランダム秘密をモバイル装置の安全な記憶装置に記憶するステップと、
信頼できるアプリケーションの安全な記憶装置内のデータにアクセスするたびに、最初のランダム秘密「ＩＲＳ」、装置のフィンガープリント、および、信頼できるアプリケーションのための一意のｉｄ「ＵＵＩＤ」を使用して、信頼できるアプリケーションと関連付けられた信頼できる記憶装置に記憶されたデータを暗号化するために、安全な記憶データキー「ＴＡ＿ＳＫ」を生成するステップと、
を含む。

本発明の一実施形態によれば、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法は、
信頼できるアプリケーションを実行する間に、
信頼できるアプリケーションのその特定の実行と関連付けられた１回限りのランタイムキーを決定するステップと、
信頼できるアプリケーションのその特定の実行中に、信頼できるアプリケーションによって使用されるランタイムメモリに数量を記憶するとき、１回限りのランタイムキーを使用してその数量をマスクするステップと、
信頼できるアプリケーションのその特定の実行中に、信頼できるアプリケーションによって使用されるランタイムメモリから数量を取得するとき、１回限りのランタイムキーを使用してその数量をアンマスクするステップと、
を含む。

本発明の一実施形態によれば、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法は、
実行または解釈するためにコンパイルされた形式を有する信頼できるアプリケーションを初回に実行した際に、信頼できるアプリケーションのコンパイルされた形式に基づいて第１の値を計算し、信頼できるアプリケーションのコンパイルされた形式に基づいてその値を記憶するステップと、
信頼できるアプリケーションの後続の実行をした際に、信頼できるアプリケーションのコンパイルされた形式に基づいて同じ計算を実施し、信頼できるアプリケーションのコンパイルされた形式に基づいて第２の値を生成し、第１の値と第２の値を比較し、第１の値と第２の値が同一でない場合は矯正アクションを行うステップと、
を含む。

本発明の一実施形態によれば、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法は、
ソフトウェアの信頼できる実行環境の初回の実行をした際に、モバイルアプリケーションの特定の命令の予想実行時間を決定し、
前記一定の命令の予想実行時間を記憶し、
ソフトウェアの信頼できる実行環境の後続の実行中に、
命令数を追跡し、
システムクロックを定期的にフェッチし、
現在の命令数から予想実行時間を計算し、
予想実行時間と現在のシステムクロックを比較し、
比較が受け入れがたい偏差を示す場合に矯正アクションを行う
ことにより、潜在的なタイムシフト攻撃を防御するステップをさらに含む。

本発明の一実施形態によれば、特定の命令はアプリケーションプログラムインタフェースの機能に対する呼び出しである。

本発明の一実施形態によれば、モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法は、
信頼できるアプリケーションの重要な部分を、複数のループを有し、各ループが短いループまたは長いループとして実行されることができるダミーコード部で修正するステップと、
ダミーコード部の内部および信頼できるアプリケーションの前記重要な部分の近傍に複数の検査ポイントを割り当てるステップと、
信頼できるアプリケーションを実行した際に、定義された数の短いループおよび長いループを実行する、ダミーコードを通る実行経路を決定するステップと、
各検査ポイントの予想到達時間を決定するステップと、
検査ポイントに到達した際に、予想到達時間と実際の到達時間を比較し、実際の到達時間と予想到達時間の間の偏差が所定のしきい値を超える場合に、矯正アクションを行うステップと、
を含む。

モバイルアプリケーションが、Ａｐｐ Ｓｔｏｒｅからモバイル計算装置にロードされ、サービスプロバイダ（ＳＰ）からのサービスにアクセスするために使用することができる環境を示すブロック図である。 図１のネットワークをより詳細に示す上位レベルの略図である。 図１および図２のモバイル装置のハードウェア構成要素を示すブロック図である。 図１、図２および図３のモバイル装置のメモリに記憶することができる、攻撃から保護すべきデータを含む例示的なソフトウェアモジュールおよびデータを示すブロック図である。 図１、図２、図３および図４のモバイル装置にモバイルａｐｐをロードし、一実施形態に従ってこうしたモバイルａｐｐのセキュリティ態様を初期化するステップを示す流れ図である。 一実施形態による、モバイルアプリケーションのための信頼できる実行環境を有するモバイル装置の一実施形態を示すブロック図である。 信頼できるアプリケーションと信頼できる記憶領域の関係を示すブロック図である。 モバイルアプリケーションがロードされるモバイル装置と、図６の信頼できるアプリケーションを供給する際に使用されるキー多様化を実施するための信頼できるサービスマネージャハブとの接続を示す接続図である。 信頼できるアプリケーションを安全に提供することを可能とする、キー多様化を示すタイミングシーケンス図である。 図６の信頼できるアプリケーション用の記憶装置を安全にするための信頼の基礎として、図９に示したプロセスからのホワイトボックス暗号キーの使用を示すデータフロー図である。 ランタイムメモリダンプからのデータの悪意ある取得を防止するためのランタイムメモリの一部の暗号化を示すタイミングシーケンス図である。 信頼できるアプリケーションの改竄を検出するための一実施形態の機構を示す流れ図である。 クロック完全性チェックが、クロック変更攻撃を防ぐために使用される一実施形態の機構を示す流れ図である。 知られている継続時間を有する選択されたループの実行時間が、たとえば、デバッガを使用しての改竄の可能性を決定するために検査される、モバイルａｐｐの例示の実行を示す実行経路図である。 ランダム化された実行継続時間が改竄の可能性を決定するために検査される、ランタイム中の実行経路のランダム化を示す流れ図である。

以下の詳細な説明において、本発明が実施される特定の実施形態を説明のために示す添付の図面を参照する。これらの実施形態は、当業者が当発明を実施できるように、十分詳細に記載されている。本発明の様々な実施形態は、異なってはいるものの、必ずしも互いに相容れないものではないことを理解されたい。たとえば、本明細書で一実施形態と関連して記載されている特定の機能、構造または特徴は、他の実施形態に実装することができる。さらに、開示された各実施形態の個々の要素の位置または配置は、本発明の趣旨および範囲から逸脱することなく、変更することができることを理解されたい。したがって、以下の詳細な説明を限定的な意味で受け取るべきではなく、本発明の範囲は、適切に解釈された添付の特許請求の範囲によって定義される。図面において、同じ番号はいくつかの図を通して同一または類似の機能を指している。

本発明の一実施形態において、信頼できる実行環境をサポートするためのハードウェア機構を備えていないモバイル装置上で、信頼できる実行環境（ＴＥＥ）が利用できるようになる機構を提供する技術が提供される。この提供された機構により、標準的なハードウェアでサポートされる信頼できる実行環境のアプリケーションプログラマインタフェースに対して開発されている一方で、エンドユーザおよびサービスプロバイダによって等しく信頼される信頼できるアプリケーションが開発できるようになり、それにより、こうしたハードウェアベースの信頼できる実行環境向けに本明細書に記載された機構のために開発されたアプリケーションを、容易に移植することができるようになる。

図１は、モバイル装置１０３を１つまたは複数のリモートサービスプロバイダ（ＳＰ）サーバ１１３に接続しているネットワーク１１１の略図である。ＳＰは任意の無数の可能なサービスを提供することができる。典型的な例としては、オンラインバンキング、オンライン取引、オンライン教育、オンライン投票などがあげられる。この文書の読者が認識するように、これらの例においては、取引のセキュリティが極めて重要である。

ユーザ１０１は、モバイル装置１０３を操作して、ネットワークを介してＳＰサーバ１１３のうちの１つと対話する。こうした対話は、モバイル装置１０３にダウンロードされた専用のアプリケーションプログラムを使用して実施するのが有利である。Ａｐｐとしても知られるこうした専用のアプリケーションプログラムは、ユーザに機能豊富な環境を提供し、ユーザ１０１は、それを通してサーバアプリケーションと対話する。ユーザは、ａｐｐ ｓｔｏｒｅ１１５からＡｐｐを入手することができる。ａｐｐ ｓｔｏｒｅ１１５の例としては、ｉＰｈｏｎｅ（登録商標）およびｉＰａｄ（登録商標）などＩＯＳ装置用のａｐｐ用のＡｐｐｌｅ社（Ｃｕｐｅｒｔｉｎｏ、Ｃａｌｉｆｏｒｎｉａ、ＵＳＡ）によって提供されるａｐｐ ｓｔｏｒｅ、Ｇｏｏｇｌｅ社（Ｍｏｕｎｔａｉｎ Ｖｉｅｗ、Ｃａｌｉｆｏｒｎｉａ、ＵＳＡ）によって提供されるＧｏｏｇｌｅ Ｐｌａｙ ａｐｐ ｓｔｏｒｅ、および、Ｍｉｃｒｏｓｏｆｔ社（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ、ＵＳＡ）によるＷｉｎｄｏｗｓ Ｓｔｏｒｅがあげられる。

この文書の読者が認識するように、多くのオンライン取引にとって、セキュリティが最も重要である。したがって、ａｐｐ自体が信頼されなければならず、ａｐｐによって管理されるデータは保護されなければならない。

図２は、ネットワーク１１１のさらなる詳細を示した上位レベルの略図である。各加入者モバイル装置１０３は、モバイルネットワークオペレータ（ＭＮＯ）１１７を介して他のネットワーク装置と通信を行う。装置１０３のユーザ１０１は、ＭＮＯ１１７の加入者であり、たとえば、ＭＮＯ１１７は、モバイル電話サービスのプロバイダといってよい。

個々のサービスプロバイダ（ＳＰ）が、メッセージの送信、アプリケーションの管理、サービスの提供、およびセキュリティ機構の提供のためにそれぞれ個々のモバイルネットワークオペレータと対話しなければならないとしたら、処理の一環にせよ、配備の一環にせよ、混乱が起こるであろう。したがって、信頼できるサービスマネージャ（ＴＳＭ）として知られる中心アクタが、ＳＰとＭＮＯとの間の通信を管理するためにＧｌｏｂａｌＰｌａｔｆｏｒｍに導入される。

図２は、サービスプロバイダ（ＳＰ）とモバイルネットワークオペレータ（ＭＮＯ）との関連において、信頼できるサービスマネージャ（ＴＳＭ）がいかにして役割を果たすことができるかの例を提供する。コンピュータハードウェア１１９−Ｃとソフトウェア（図示せず）の組合せである各ＴＳＭ１１９^１は、サービスプロバイダ（ＳＰ）１１５とモバイルネットワークオペレータ（ＭＮＯ）１１７との間のリンクを確立する。各ＴＳＭは、多数のＭＮＯを多数のＳＰに接続することができる。逆に、所与のＳＰ１１５またはＭＮＯ１１７は、１つのＴＳＭ１１９または多数のＴＳＭ１１９のどちらかに接続することができる。
（^１この説明において、いくつかの関連する要素はそれぞれｎ−Ｅ、ｎ−Ｃおよびｎ−Ｓと呼ばれる。Ｅはエンティティ、Ｃはコンピュータ、Ｓはソフトウェアを表す。したがって、ｎ−Ｅはエンティティｎ−Ｅであり、コンピュータｎ−Ｃを動作させ、コンピュータｎ−Ｃは命令ｎ−Ｓに従って実行する。たとえば、信頼できるサービスマネージャエンティティ１１９−Ｅは、信頼できるサービスマネージャソフトウェアを実行するコンピュータ１１９−Ｃを動作させる。説明を容易にするために、発明者らは時に数字ｎ、たとえばＴＳＭ１１９、によってこうした要素に言及する。文脈上明白に逆の意味となる場合を除いて、通常、これは、それぞれの役割を実施する３つの要素すべてを参照することを意味していると理解すべきである。たとえば、信頼できるサービスマネージャコンピュータ１１９−Ｃは、信頼できるサービスマネージャソフトウェア１１９−Ｓのソフトウェアによって指図されたいくつかの行動を実施する。）

図３はモバイル装置１０３の略図である。モバイル装置１０３は、バス２０２を介してランダムアクセスメモリ（ＲＡＭ）２０３、リードオンリメモリ（ＲＯＭ）２０４および不揮発性メモリ（ＮＶＭ）２０５に接続されたプロセッサ２０１を備えることができる。モバイル装置１０３は、この場合も通常はバス２０２を介して、プロセッサ２０１を、モバイル装置１０３をホストコンピュータまたは他の周辺機器に接続することができるアンテナ２１１に接続するための入力／出力インタフェース２０７をさらに備える。

ＮＶＭ２０５は、図４に示すように、コンピュータプログラム３０１を含むことができる。ここでは、コンピュータプログラム３０１は、すべてＮＶＭ２０５に配置されるように描かれているが、プログラムは多数のメモリにわたって配備することができ、一時的にＲＡＭ２０３にインストールすることさえ可能であるので、実務においてはこうした制約はない。さらに、モバイル装置１０３は、多数のＲＯＭまたはＮＶＭを備えることができる。プログラム３０１は、モバイル装置１０３にロードされた、オペレーティングシステムプログラムおよびアプリケーションプログラムを含む。モバイルａｐｐ２１５のＮＶＭ２０５はまた、秘密キー２１２または共有秘密キー２０９といった、基本形式または導出量のどちらかで記憶された個人データ、および、口座番号といった他のユーザ個人情報２１４を含むことができる。こうしたデータを安全にするための機構は本明細書で後に説明する。

モバイル装置１０３のプログラム３０１は、暗号モジュール２１３、通信モジュール２１７、およびオペレーティングシステムＯＳ２１９を含むことができる。

本明細書で既に論じたように、モバイルａｐｐ２１５は、極めて慎重な取り扱いを要するデータを操作する、たとえばオンラインバンキング口座にアクセスする、および、秘密データへのアクセスを提供するために使用することができる。こうしたモバイルａｐｐ２１５を安全にするために、本明細書で信頼できない部分と信頼できる部分と呼ばれる２つの部分に、モバイルａｐｐ２１５を分割する技術が提供される。信頼できない部分は、モバイルプラットフォーム、たとえばＩＯＳまたはＡｎｄｒｏｉｄ、によって提供されるリッチ実行環境（ＲＥＥ）５０１で実行する部分である。したがって、信頼できない部分は、モバイルプラットフォームによって提供されるリッチなユーザ体験を提供することができ、一方、開発者およびサービスプロバイダは、その部分のセキュリティ違反について心配する必要がない。言い換えれば、信頼できない部分の配信を、信頼できない配信者、たとえばあるａｐｐ ｓｔｏｒｅに対してアンロードすることは安全であると考えられる。

他方、信頼できる部分は、セキュリティ対策が必要とされるモバイルａｐｐ２１５の部分である。こうした部分は、信頼できるサイトから安全なチャネルを介してダウンロードされ、さらに暗号によって安全にされる。

図５は、一実施形態による安全なモバイルａｐｐ２１５をロードし初期化するステップを示す流れ図である。ユーザ１０１（またはモバイルネットワークオペレータ１１７など別のアクタ）は、信頼できない部分をモバイル装置１０３のＮＶＭ２０５にインストールする（ステップ５５１）。図５に示すように、最初のステップ５５１は、信頼できない部分をａｐｐ ｓｔｏｒｅからダウンロードすることからなるとしてよい。ａｐｐ ｓｔｏｒｅの例としては、ＩＯＳ装置にはＡｐｐｌｅ社のＡｐｐ Ｓｔｏｒｅ、Ａｎｄｒｏｉｄ装置にはＧｏｏｇｌｅ Ｐｌａｙがあげられる。信頼できない部分の詳細は、以下の図６に関連して論ずる。

モバイルａｐｐ２１５の信頼できる部分をロードして安全にすることは、通常、ブートストラップモジュール５０９の指揮下で、モバイルａｐｐ２１５を最初に使用する際に行われてよい（ステップ５５３）。サブステップ５５５において、信頼できる部分は、提供サーバ、たとえば、信頼できるサービスマネージャ１１９、サービスプロバイダまたは認証することができるサービスプロバイダの代行者として知られる信頼できるサーバからダウンロードされる。モバイルａｐｐ２１５の信頼できる部分の構成要素の詳細は、図６と関連して論ずるが、各モバイルａｐｐ２１５は、１つまたは複数の信頼できるアプリケーション５１９からなることに留意されたい。

モバイルａｐｐ２１５の信頼できる部分および信頼できない部分のロード後に、ステップ５５７が続いてもよい。ステップ５５７は、信頼できない部分からの方法の呼び出しが、期待される信頼できるアプリケーション２１９に到達するように、何らかの方法でこうした部分を関連付け、関連付けるステップは、リンクステップを含むことができる。

信頼できるアプリケーション２１９と関連付けられた信頼できる記憶装置に記憶された、信頼できる部分およびデータを安全にするための機構は、暗号キーに依存する。モバイルアプリケーションの初回の実行中に、キー提供ステップ５５９が実行されて必要なキーを入手する。キー提供ステップ５５９は、たとえば、図８および図９と関連させて以下でより詳細に説明する。

次いで、信頼できる部分がロードされ信頼できない部分とリンク付けされると、モバイルａｐｐ２１５が実行される（ステップ５６１）。

図６は、モバイルアプリケーション２１５に信頼できる実行環境を提供するための一実施形態を示す。上位レベルでは、モバイルａｐｐ２１５は、信頼できない部分と信頼できる部分の２つの部分からなる。前者は、信頼できないソースからダウンロードすることができ、安全化する必要はない。信頼できない部分は、モバイルプラットフォームＯＳによって提供されたリッチ実行環境（ＲＥＥ）５０１で実行するモバイルａｐｐ２１５の要素、および、安全化する必要のない信頼できる実行環境のインフラストラクチャ要素を含む。信頼できる部分は、暗号で安全化されている信頼できるソースからロードされ、次いで、モバイルａｐｐ２１５に組み込まれているソフトウェアの信頼できる実行環境（Ｓｏｆｔ ＴＥＥ）５０３を通して実行する。

モバイルプラットフォームＯＳのバーチャルマシンインタープリタ５１５が、モバイルａｐｐ２１５の信頼できない部分の命令を解釈する。

スマートフォンといったモバイルプラットフォームは、リッチ実行環境（ＲＥＥ）５０１を提供する。ＲＥＥ５０１は、広範囲にわたって柔軟性のある機能レパートリーを提供し、そこから、強力で魅力的かつ有用なモバイルａｐｐ２１５を作成することができる。電話を使用することができる多くのことに際してのスマートフォンの任意の使用、および、多彩なａｐｐによって提供される賢いユーザインタフェースを、ユーザは日々利用することができる。ＲＥＥがリッチで強力な実行環境を提供する一方で、ＲＥＥは装置が、その装置のユーザの秘密情報または貴重な情報を危うくするおそれがある攻撃を脆弱なままにしておく。本明細書で説明した技術は、Ｓｏｆｔ ＴＥＥ５０３をモバイルａｐｐ２１５に導入することにより、こうしたセキュリティリスクを軽減する機構を提供する。

ステップ５５１でロードされた信頼できない部分は、ＲＥＥ５０１で実行するモバイルａｐｐ２１５の部分を含む。こうしたＲＥＥ構成要素５０７は、クライアントアプリケーション５０５、ブートストラップモジュール５０９、ＲＥＥ プロキシ５１１および安全なアプリケーションＡＰＩ５１３を含む。ブートストラップモジュール５０９は、提供サーバからのキー提供を整理し、信頼できる構成要素を初回にロードし、その構成要素をリンク付する命令を含む。ＲＥＥ プロキシ５１１は、モバイルａｐｐ２１５が外部のサーバ、特に、信頼できるサービスマネージャ１１９と対話することができる機構を提供する。ＲＥＥ プロキシ５１１はさらに、発行者セキュリティドメイン（ＩＳＤ）５２９とインタフェースで接続する。特定のＧｌｏｂａｌＰｌａｔｆｏｒｍアプリケーションに割り当てられたメモリ領域は、セキュリティドメイン（ＳＤ）と呼ばれる安全な領域で管理することができる。セキュリティドメインは、オフデバイス権限のオンデバイス代表である。セキュリティドメイン（ＳＤ）は、キー処理、暗号化、復号、デジタル署名生成、および、各ＳＤ、たとえば発行者または信頼できるサービスマネージャと関連付けられたエンティティのアプリケーション検証といったセキュリティサービスをサポートする。各ＳＤは、特定のアクタ、たとえばカード発行者（発行者セキュリティドメイン）、アプリケーションプロバイダ（アプリケーションセキュリティドメイン）、またはＴＳＭ（ＴＳＭ ＳＤ）を代表して確立される。ＳＤは、キーおよび他の安全な情報を１つのアクタから他のアクタへ隔離するように確立される。逆もまた同様である。

したがって、ＩＳＤすなわち発行者セキュリティドメインは、装置の発行者と関連付けられたモバイル装置上のセキュリティドメインであり、発行者と関連付けられたキーを管理するために使用される。ＩＳＤ５２９は、ステップ５５１でモバイルａｐｐを初回にロードする間に、モバイル装置１０３にダウンロードすることができる。

安全なアプリケーションＡＰＩ５１３は、たとえば、ＴＥＥクライアントＡＰＩ仕様ｖ１．０ ＧＰＤ＿ＳＰＥ＿００７、ＧｌｏｂａｌＰｌａｔｆｏｒｍ、２０１１年１２月（ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂａｌｐｌａｔｆｏｒｍ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎｓｄｅｖｉｃｅ．ａｓｐ）において定義されたＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｃｌｉｅｎｔ ＡＰＩを実装することができる。モバイルａｐｐ２１５の安全でない部分は、安全なアプリケーションＡＰＩ５１３を使用して、モバイルａｐｐ２１５の安全な部分にアクセスする。ＧｌｏｂａｌＰｌａｔｆｏｒｍにおいて、信頼できる実行環境（ＴＥＥ）はハードウェアに実装され、ＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｃｌｉｅｎｔ ＡＰＩを使用して、アプリケーションによってアクセスされる。一実施形態において、安全なアプリケーションＡＰＩ５１３が実装され、モバイルａｐｐ２１５が一度書き込まれ、ＴＥＥのハードウェア実装を有する装置上で実行されるか、または本明細書で説明したＳｏｆｔ ＴＥＥ５０３を使用するように、ＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｃｌｉｅｎｔ ＡＰＩをエミュレートする。その結果、ＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｃｌｉｅｎｔ ＡＰＩエミュレーションとしての安全なアプリケーションＡＰＩ５１３の実装により、モバイルａｐｐ２１５は、ＧｌｏｂａｌＰｌａｔｆｏｒｍ ＴＥＥを実装する装置に容易に移植される。

安全なアプリケーションＡＰＩ５１３は、ステップ５５１でモバイルａｐｐを初回にロードする間に、モバイル装置１０３にダウンロードすることができる。

したがって、ＲＥＥ５０１のセキュリティリスクを克服するために、ソフトウェアの信頼できる実行環境（Ｓｏｆｔ ＴＥＥ）５０３が、モバイルアプリケーション２１５に提供される。Ｓｏｆｔ ＴＥＥ５０３のインフラストラクチャは、初回のダウンロードステップ５５１で、ＲＥＥ構成要素５０７とともにダウンロードされる。

Ｓｏｆｔ ＴＥＥバーチャルマシン（Ｓｏｆｔ ＴＥＥ ＶＭ）５１７は、Ｓｏｆｔ ＴＥＥ５０３の中心的な構成要素である。Ｓｏｆｔ ＴＥＥ ＶＭ５１７は、初回のダウンロードステップ５５１でダウンロードすることができる。Ｓｏｆｔ ＴＥＥ ＶＭ５１７は、モバイルａｐｐ２１５の内側にエミュレーション層を提供する。Ｓｏｆｔ ＴＥＥ ＶＭ５１７は、ホスト環境の命令セットとは異なる命令セットを実行する。したがって、マシン本来のバーチャルマシンインタープリタ５１５と混同すべきではない。Ｓｏｆｔ ＴＥＥ５０３で実行するプログラム、たとえば信頼できるアプリケーションは、この特別な命令セットに対してコンパイルされ、得られた信頼できるアプリケーションバイナリ５１９は、Ｓｏｆｔ ＴＥＥ ＶＭ５１７によって解釈される。

Ｓｏｆｔ ＴＥＥ５０３システム全体は、Ｓｏｆｔ ＴＥＥ ＶＭ５１７内で実行し、クライアントアプリケーション５０５からの実行隔離を保証する。クライアントアプリケーション５０５が、Ｓｏｆｔ ＴＥＥ５０３によって保護されるリソースへのアクセスを要求すると、それは安全なアプリケーションＡＰＩ５１３に対して呼び出しを行う。Ｓｏｆｔ ＴＥＥ ＶＭ５１７はこうした要求を取得し、これらの要求を対応する信頼できるアプリケーション５１９にディスパッチする。

先に説明したように、信頼できるアプリケーション５１９は、Ｓｏｆｔ ＴＥＥ ＶＭ５１７によって解釈可能な命令セットに対してコンパイルされる。ＴＥＥ５０３の機能にアクセスするために、信頼できるアプリケーションは、内部の安全なアプリケーションＡＰＩ５２５を介して、ＴＥＥカーネル５２７に対する呼び出しを使用する。

信頼できる実行環境の重要な機能は、保護する必要のあるデータ項目を、クライアントａｐｐ５０５など信頼できない構成要素から隔離することである。したがって、Ｓｏｆｔ ＴＥＥ５０３は信頼できる記憶装置５２３を含む。信頼できる記憶装置５２３の一部は、それぞれの信頼できるアプリケーション５１９と関連付けられている。図７は、信頼できるアプリケーション５１９と信頼できる記憶領域５２３の関係を示すブロック図である。信頼できる記憶領域５２３に記憶されたデータは、データ暗号キー、たとえば信頼できるアプリケーション記憶キー７０１を使用して、それぞれ暗号化される。信頼できるアプリケーション記憶キー７０１は、キー提供ステップ５５９の結果として信頼できるアプリケーション５１９に提供される。これについては以下でより詳細に説明する。

さらに、キー提供ステップ５５９中のモバイルａｐｐ２１５の個人化は、信頼できるアプリケーション５１９を安全に受信し、信頼できる各アプリケーション５１９のための信頼できるアプリケーション記憶キー７０１を導出するために使用される、個人化された暗号キー材料５２１を有する、Ｓｏｆｔ ＴＥＥ５０３を提供することを含む。

図８は、モバイルアプリケーションがロードされるモバイル装置１０３と、図６の信頼できるアプリケーションを提供する際に使用されるキー多様化を実施するための信頼できるサービスマネージャハブ６０５との間の接続を示す接続図である。

モバイル装置１０３は、信頼できるサービスマネージャ１１９に接続されており、図２に示したように、接続はモバイルネットワークオペレータ１１７を経由してもよい。

信頼できるサービスマネージャ１１９は、いくつかの関連するサーバ、たとえばキー提供サーバ６０１およびキーディレクトリサーバ６０３と、本明細書で信頼できるサービスマネージャハブ６０５と呼ぶことができる同じ場所に配置することができる。信頼できるサービスマネージャハブ６０５のこうした構成要素は、モバイル装置１０３と協働して、モバイルアプリケーション２１５のセキュリティを強化するために、ソフトウェアＴＥＥ５０３を提供する。

キー提供サーバ６０１の主要な役割は、モバイルアプリケーション２１５のＲＥＥ構成要素５０７に対応する、信頼できるアプリケーション５１９を提供する際に使用される、ホワイトボックス暗号キーおよびイニシャルピン暗号キー（ＩＰＥＫ）を生成することである。ホワイトボックス暗号法は、Ｓ．Ｃｈｏｗ、Ｐ．Ｅｉｓｅｎ、Ｈ．Ｊｏｈｎｓｏｎ、Ｐ．Ｃ．ｖａｎ Ｏｏｒｓｃｈｏｔ、Ｗｈｉｔｅ−Ｂｏｘ Ｃｒｙｐｔｏｇｒａｐｈｙ ａｎｄ ａｎ ＡＥＳ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ。第９回年次ワークショップ Ｓｅｌｅｃｔｅｄ Ａｒｅａｓ ｉｎ Ｃｒｙｐｔｏｇｒａｐｈｙ（ＳＡＣ ２００２）、８月１５−１６日 ２００２年、および、Ｊｕｌｉｅｎ Ｂｒｉｎｇｅｒ、Ｈｅｒｖｅ Ｃｈａｂａｎｎｅ、およびＥｍｍａｎｕｅｌｌｅ Ｄｏｔｔａｘ、Ｗｈｉｔｅ Ｂｏｘ Ｃｒｙｐｔｏｇｒａｐｈｙ：Ａ Ｎｅｗ Ａｔｔｅｍｐｔ、Ｃｒｙｐｔｏｌｏｇｙ ｅＰｒｉｎｔ Ａｒｃｈｉｖｅ、レポート２００６／４６８、２００６年に記載されており、両者とも引用により本明細書に組み込まれている。

秘密キー、Ｐｒ．Ｋ．Ｋｐｓは、キー提供サーバと関連付けられており、サーバが生成するキーにサインすることを可能とする。

キーディレクトリサーバ６０３の主要な役割は、特定の装置１０３で実行するモバイルａｐｐ２１５の特定のインスタンス化のために、ソフトウェアＴＥＥ５０３用の一意の識別子と関連付けられたＩＰＥＫキーのデータベースを維持することである。データベーステーブルでもよいディレクトリは、本明細書ではキーディレクトリ６０７と呼ばれる。ソフトウェアＴＥＥの一意の識別子は、本明細書ではＴＥＥ ＩＤと呼ばれ、以下でより詳細に説明する。特定のＴＥＥ ＩＤが与えられると、キーディレクトリサーバは、問い合わせを行ったクライアント、たとえば信頼できるサービスマネージャ１１９に、対応するＩＰＥＫを提供することができる。

モバイル装置１０３に信頼できるアプリケーション５１９を提供するという状況における、信頼できるサービスマネージャ１１９の主要な役割は、モバイル装置１０３から信頼できるアプリケーション５１９に対する要求を受信することである。要求には、モバイル装置１０３、特にモバイルアプリケーション２１５が、自身を識別し、その認証を、もっと細かに言うと、ＴＥＥ ＩＤおよびＩＰＥＫを提供することによって証明することができる機構が含まれる。一実施形態において、本明細書で以下に説明するように、ＩＰＥＫは、モバイル装置１０３によりハッシュ形式で提供される。

図９は、信頼できるアプリケーションを安全に提供することを可能とするキー多様化を示す、タイミングシーケンス図である。準備ステップ（図示せず）として、モバイルａｐｐ２１５のＲＥＥ構成要素が、たとえばａｐｐ ｓｔｏｒｅからモバイル装置１０３にダウンロードされる。

ステップ７０１。モバイルアプリケーション２１５、特にモバイルアプリケーション２１５のＲＥＥ構成要素は、モバイル装置１０３上で実行するとき、モバイルアプリケーション２１５用の一意の識別子（ＴＥＥ ＩＤ）を決定する。言い換えると、ＴＥＥ ＩＤはアプリケーションと装置の両者に依存する。一実施形態において、ＴＥＥ ＩＤは、アプリケーションに割り当てられた汎用一意識別子（ＵＵＩＤ）およびモバイル装置１０３の装置フィンガープリントに基づいて計算される。これらは、たとえばハッシュを生成するために使用する、またはＴＥＥ ＩＤを作成するために連結することができる。

装置フィンガープリントは、ハッシュ、たとえば、アプリケーション識別子、一意のＯＳ識別子、モバイル装置１０３の無線シリアルおよびモバイル装置１０３のＩＭＥＩの連結のＳＨＡ１として計算することができる。アプリケーション識別子は、アプリケーションのパッケージ名である（例として、ｃｏｍ．企業名．ａｐｐ名）。一意のＯＳ識別子は、Ａｎｄｒｏｉｄ ＯＳにおいてはＡｎｄｒｏｉｄ ＩＤ、および、ｉＯＳにおいてはＶｏｌｕｍｅ ＵＵＩＤなど、基礎をなすＯＳによって提供されたパラメータである。無線シリアルは、モバイル装置上の無線装置のシリアル番号である。ＩＭＥＩすなわち移動端末装置識別子（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）は、モバイル装置に割り当てられた一意の番号で、第３世代パートナーシッププロジェクトの３ＧＰＰ ＴＳ２３．００３仕様書に明記されている。

ステップ７０３。ＴＥＥ ＩＤがモバイルａｐｐ２１５からキー提供サーバ６０１に送信される。

ステップ７０５。キー提供サーバ６０１は、モバイルａｐｐ２１５からＴＥＥ ＩＤを受信し、ＴＥＥ ＩＤと関連付けられるイニシャルピン暗号キー（ＩＰＥＫ）およびダイナミックホワイトボックス暗号キー（ＷＢＣ ｋｅｙ、Ｋｍ）を生成する。

好ましい実施形態において、ＩＰＥＫは、キー提供サーバ６０１によって生成された一意のランダムＡＥＳ−２５６キーである。ＡＥＳ−２５６は、２５６ビットキーを使用した高度暗号化標準の１バージョンである。

ホワイトボックス暗号法は、この文書の範囲外である。しかし、以下の目立った点は、本明細書で発表された技術を理解するのに役立つ。ホワイトボックス暗号法は、配信者のアクセス制御実行を超えて配信された配信物を保護するために使用される。たとえば、現在の状況では、モバイル装置は、その装置の発行者の制御を超え、および、モバイル装置で使用するためのａｐｐを配信できるサービスプロバイダの制御を超えている。ホワイトボックス暗号法は、配信物を保護するために難読化技法を使用する。ステップ３（７０５）において、ホワイトボックス暗号法ライブラリ（ＷＢＣ）バイナリが、ＴＥＥ ＩＤのハッシュを含む一意のランダムＡＥＳ−１２８キー、および、ホワイトボックス暗号法技法を使用して、ＡＥＳによって暗号化されたメッセージ中に隠れているＷＢＣキーを含むように作成される。

ステップ７０７。ＩＰＥＫキーは、ＷＢＣキーを使用してキー提供サーバ６０１によって暗号化される。

ステップ７０９。ＴＥＥ ＩＤおよびＩＰＥＫキーは、キーディレクトリサーバ６０３に送信される。

ステップ７１１。キーディレクトリサーバ６０３は、ＴＥＥ ＩＤおよびＩＰＥＫキーを関連付け、それらをキーディレクトリ６０７に記憶する。

ステップ７１３。ＴＥＥ ＩＤおよびＩＰＥＫキーをキーディレクトリサーバ６０３に送信するのと並行して、キー提供サーバ６０１は、ＷＢＣキーライブラリおよび暗号化されたＩＰＥＫキーをモバイルアプリケーション２１５に送信する。

ステップ７１５。モバイルアプリケーション２１５は、ＷＢＣライブラリをインストールする。ＷＢＣライブラリをインストールすることにより、モバイルアプリケーション２１５は、ライブラリを使用して、ライブラリ、このケースではＩＰＥＫキーを用いて暗号化した情報を復号することができる。

ステップ７１７。モバイルアプリケーション２１５は、ＷＢＣライブラリを使用してＩＰＥＫキーを復号する。

ステップ７１９。ＩＰＥＫキーは、発行者セキュリティドメイン（ＩＳＤ）５２９に記憶される。ＩＳＤは、図５のステップ５５１でモバイルａｐｐ２１５の信頼できない構成要素を使用してダウンロードされていた。

ステップ７２３。モバイルアプリケーション２１５は、ＩＰＥＫ（ＨＭＡＣ（ＴＥＥＩＤ、ＩＰＥＫ））を使用して、ＴＥＥ ＩＤおよびＴＥＥＩＤのハッシュを信頼できるサービスマネージャ６０５に送信する。

ステップ７２５。信頼できるサービスマネージャ６０５は、一致することを確認するために、ＴＥＥ ＩＤおよびハッシュ（ＨＭＡＣ（ＴＥＥＩＤ、ＩＰＥＫ））をキーディレクトリサーバ６０３に転送する。キーディレクトリサーバ６０３が、ＴＥＥ ＩＤのテーブル（上記ステップ７１１）および対応するＩＰＥＫを維持しているので、キーディレクトリサーバ６０３は、ステップ７２３でモバイルａｐｐ２１５から信頼できるサービスマネージャ６０５に送信されたハッシュが、正しいＩＰＥＫから期待するハッシュと一致することを確認することができる。

ステップ７２７。キーディレクトリサーバ６０３が、ＩＰＥＫとＴＥＥ ＩＤの一致を確認すると、キーディレクトリサーバ６０３は、ＩＰＥＫを信頼できるサービスマネージャに送り返す。

ステップ７２９。信頼できるサービスマネージャ６０５はＩＰＥＫを記憶する。信頼できるサービスマネージャ６０５はまた、ＩＰＥＫを用いて生成されたセッションキーを使用してＴＡ５１９を暗号化する。

ステップ７３１。信頼できるサービスマネージャ６０５は、暗号化したＴＡ５１９をモバイルａｐｐ２１５に送信する。

ステップ７３３。モバイルａｐｐ２１５は、ＩＰＥＫから生成されたセッションキーを使用してＴＡ５１９を復号し、ＴＡ５１９をＳｏｆｔ ＴＥＥ５０３にインストールする。

それにより、モバイルａｐｐ２１５は、初回にダウンロードされた信頼できない構成要素のみならず、信頼できる構成要素、キー材料５２１およびＴＡ５１９を含めることを完了した。

上で言及したように、信頼できる各アプリケーション５１９に対応した信頼できる記憶装置５２３は、信頼できるアプリケーション記憶キー（ＴＡ＿ＳＫ）７０１によって保護される。図１０は、こうした記憶キーの生成を示す流れ図である。

ステップ１００１。最初のランダム秘密（ＩＲＳ）がモバイルａｐｐ２１５によって生成される。

ステップ１００３。ＩＲＳが、モバイルａｐｐ２１５により、図９のステップ７０５からのダイナミックホワイトボックス暗号キー（ＷＢＫ）を使用して暗号化され、ステップ７１３においてモバイルａｐｐに提供される。

ステップ１００５。暗号化されたＩＲＳは、モバイルａｐｐ２１５により、ＮＶＭ２０５中のモバイルａｐｐ２１５によって管理されるファイル記憶装置に記憶される。

一代替実施形態において、ステップ１００１からステップ１００５は、ユーザによるＰＩＮのエントリによって置き換えられる。ＰＩＮは記憶されない。むしろ、下記のステップ１００９で論ずるように、ＰＩＮは実行ごとに正しく再エントリされなければならず、そうしなければ、計算された記憶キーは、最初の実行時に使用された記憶キーと一致しないであろう。

ステップ１００７。ステップ１００１−ステップ１００５に並行して、装置フィンガープリント（ＤＦＰ）がモバイルａｐｐ２１５によって計算される。ＤＦＰは、アプリケーション識別子、一意のＯＳ識別子、無線シリアル番号および装置のＩＭＥＩ番号の連結からなるＳＨＡ１によって計算することができる。

図１０の先行するステップは、結果、すなわち暗号化されたＩＲＳおよびＤＦＰがＮＶＭ２０５に記憶された状態で、一度実施されるのが好都合である。引き続くステップは、信頼できる記憶装置にアクセスするときに使用されるランタイムステップである。

ステップ１００９。実行時に、各ＴＡ５１９に対して、ＴＡ記憶キー（ＴＡ＿ＳＫ）７０１が、たとえば、ＲＦＣ５８６９に明記された（ＩＥＴＦ、ＨＭＡＣベースの取得および拡張キー導出機能（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８６９）、２０１５年９月３日アクセスされた）ＨＭＡＣベースのキー導出関数を使用して計算される。ＨＡＳＨ関数への入力は、ＩＲＳ、ＤＦＰおよびＴＡ５１９のＵＵＩＤを含む。ユーザＰＩＮを使用する代替実施形態において、ユーザはＰＩＮ入力を促される。最初に入力されたＰＩＮは記憶されない。しかし、実行ごとにＰＩＮを使用してＴＡ記憶キーを計算するので、正しいＴＡ＿ＳＫが後続の実行時にステップ１００９で計算されるように、正しいＰＩＮを入力する必要がある。

ステップ１０１３。信頼できるアプリケーション５１９が、対応する記憶装置５２３にアクセスしようとするとき、信頼できるアプリケーション７０１は、その記憶キーＴＡ＿ＳＫ７０１を使用して、信頼できる記憶装置５２３から記憶されまたは取得されたコンテンツを暗号化または復号する。

モバイルａｐｐ２１５を対象とした攻撃に対する１つの脆弱性は、その実行中にモバイルａｐｐ２１５によって使用されるＲＡＭ内の記憶領域を攻撃することである。攻撃者は、モバイルａｐｐ２１５の実行中に、ＲＡＭ２０３に記憶されたデータのメモリダンプを実施し、ＲＡＭ２０３に記憶されているものから口座番号、暗号キー、個人識別子などの秘密情報を取得しようとする可能性がある。

こうした攻撃を阻止するために、その一実施形態では、ランタイムメモリダンプからの重要なデータの復元を阻止するために、モバイルａｐｐ２１５によって使用されるランタイムメモリの一部を暗号化する。図１１は、この実施形態を示すタイミングシーケンス図である。Ｓｏｆｔ ＴＥＥ５１５の内部で実行された信頼できる各アプリケーション５１９は、ヒープまたはスタックからＲＡＭ２０３にアクセスすることができる。各ＴＡ５１９のヒープまたはスタックは分離しており、任意の他の信頼できるアプリケーション５１９のヒープまたはスタックから隔離されている。

図９と関連して先に本明細書で論じたように、たとえば、キー提供サーバ６０１は、ＷＢＣ Ｋｅｙ、Ｋｍを含むホワイトボックス暗号ライブラリを生成し、このライブラリをモバイルａｐｐ２１５に送信する（ステップ７０５、７１３）。モバイルａｐｐ２１５は、ステップ７１５でＷＢＣライブラリをインストールする。

本実施形態によれば、信頼できるアプリケーションは、１回限りのキー（ＯＴＫ）を使用してデータを暗号化することにより、ＲＡＭ２０３に記憶されたデータを暗号化する：
Ｅ＝ＰｌａｉｎＴｅｘｔ ＸＯＲ ＯＴＫ
ＯＴＫは以下で導出される：

ステップ１１０１：ＴＡ５１９は、信頼できるアプリケーション５１９の各実行に対して、一意となるようにノンスを生成する。好ましい実施形態において、ノンスを使用してＯＴＫが生成される。しかし、ＯＴＫを生成するために代替の機構を使用することが可能であり、その場合にはノンスは必要ではない。

ステップ１１０３：ＴＡ５１９は、乱数発生器を使用してランタイムキーＫ_ｒを生成する。好ましい実施形態において、ＯＴＫはランダムキーを使用して生成される。しかし、代替の機構を使用してＯＴＫを生成することが可能であり、その場合にはランダムキーＫ_ｒは必要ではない。

各記憶動作１１０４に際して、信頼できるアプリケーション５１９のメモリ位置および特定の実行と関連付けられたＯＴＫが、生成され、記憶するためにマスクされ、ＲＡＭに記憶されるプレーンテキストがＯＴＫを使用して暗号化され、そのＯＴＫが破棄される。

ステップ１１０５：ＯＴＫが生成される。好ましい実施形態において、ＯＴＫは以下の式を使用して生成される：

ここで、
ｍｅｍ＿ａｄｄｒは、暗号化されるメモリページの開始アドレス。
ｃｏｕｎｔｅｒは、（１）ＴＡ５１９の各実行時にリセットされ、各メモリアクセス時にインクリメントされるカウンタ。
ＥＮＣは、連結

が、キーＫ_ｒを使用して暗号化される暗号関数。

ステップ１１０７：ＯＴＫはマスクされる。好ましい実施形態において、ＴＡ５１９はＷＢＣキー、Ｋ_ｍを使用してＯＴＫをマスクする：
ＯＴＫｍ＝ＯＴＫ ＸＯＲ Ｋｍ
［０００１］ステップ１１０９および１１１１：マスクされたＯＴＫ、ＯＴＫｍがＲＡＭ２０３に記憶される。
［０００２］ステップ１１１３：記憶される量のプレーンテキストがＯＴＫを使用してマスクされる：
Ｅ＝ＰｌａｉｎＴｅｘｔ ＸＯＲ ＯＴＫ
［０００３］ステップ１１１５および１１１７：マスクされた量のＥがＲＡＭ２０３に転送され記憶される。

ステップ１１１９：ＯＴＫが破棄される。その結果、ＲＡＭに記憶する前にプレーンテキストをマスクするために使用された実際のキー（ＯＴＫ）が保持されることはない。むしろ、ＯＴＫのマスク化バージョンであるＯＴＫｍのみが保持され、最初に成功裏にアンマスクされた場合、ＯＴＫｍのみを使用することができる。

逆に、ＲＡＭ２０３に記憶された値を読み取る各動作時に、マスクされたＯＴＫが取得されてアンマスクされ、暗号化された量がプレーンテキストに復号され、ＯＴＫが破棄される（ステップ１１２１）。

ステップ１１２３：ＴＡ５１９は、マスクされたＯＴＫ、すなわち、以前に書き込み動作中に記憶されたＯＴＫｍを取得する。

ステップ１１２５：ＯＴＫがホワイトボックスキーＫｍを使用してＯＴＫｍからアンマスクされる。

ステップ１１２７：暗号化された量Ｅが取得される。

ステップ１１２９：暗号化された量Ｅがプレーンテキストに復号される：
Ｐｌａｉｎｔｅｘｔ＝Ｅ ＸＯＲ ＯＴＫ

ステップ１１３１：ＯＴＫが再度破棄される。

このようにして、メモリダンプを利用して、悪意を持ってモバイルａｐｐの秘密情報を見つける攻撃から、ランタイムＲＡＭを保護する技法が提供される。

バーチャルマシンによって実行するソフトウェアアプリケーションは、アプリケーションの静的またはランタイムインスタンス化による変更に基づく攻撃を受けやすい。たとえば、攻撃者は、アプリケーションによって操作された保護されたコンテンツを取得し、アプリケーションの振る舞いを操って、直接、または攻撃者がなんとかして保護されたコンテンツを見つけることを可能とする形式で、アプリケーションに保護されたコンテンツを明らかにさせようとして、アプリケーションを検査し、アプリケーションを変更することができる。

こうした攻撃を妨害するために、本技術による実施形態は、１つまたは複数のいくつかの技法を採用している。

図１２に示した、こうした技法のうちの第１のものは、アプリケーション完全性チェックを提供することである。モバイルａｐｐ２１５の信頼できるアプリケーション５１９が、Ｓｏｆｔ ＴＥＥ５０３に最初にインストールされるとき、Ｓｏｆｔ ＴＥＥバーチャルマシン５１７は、比較値、たとえば信頼できるアプリケーション５１９に対応するハッシュ値を計算する（ステップ１２０１）。比較値は、信頼できるアプリケーション５１９のバイナリ上で計算されたＨＭＡＣ−ＳＨＡ２５６ ＭＡＣハッシュコードとすることができる。次いで、比較値は、たとえば、ＴＡ５１９バイナリの先頭に付加された信頼できるコンテナに記憶される（ステップ１２０３）。

ＴＡ５１９がＳｏｆｔ ＴＥＥバーチャルマシン５１７によって再度ロードされるすべての実行時に、同一の比較値計算がバイナリ上で実施され、最初のロードで計算された記憶された比較値（「現在値」と呼ばれる）と比較される（ステップ１２０５）。ステップ１２０７において、記憶された比較値と現在比較値が異なるかどうかが判定される。それらが同一の場合、Ｓｏｆｔ ＴＥＥバーチャルマシン５１７がＴＡ５１９をロードし、実行する。それらが異なる場合、Ｓｏｆｔ ＴＥＥバーチャルマシン５１７は、ＴＡ５１９をロードせず、ユーザ、発行者またはサービスプロバイダに攻撃の可能性を通知するといった矯正アクションを発行する（ステップ１２０９）。

モバイルａｐｐ２１５に対する別の攻撃の可能性に関して、攻撃者は、クロック速度を変更し、またはタイムシフトを実施する。後者は特にデジタル著作権管理ＤＲＭアプリケーションと関係がある。したがって、こうした攻撃を妨害するために、別の実施形態において、ＴＡ５１９を、クロック完全性確認技法を使用して、追加的または代替的に確認することができる。図１３は、クロック完全性確認技法を示す流れ図である。

クロック変更攻撃を阻止するために、たとえばステップ５５５またはステップ５５５の補助的なステップにおいて、モバイルａｐｐ２１５の信頼できる部分をインストールすると、信頼できる部分の一定の命令、たとえば、Ｓｏｆｔ ＴＥＥ５０３のバーチャルマシン５１７による、内部の安全なＡＰＩ５２５内の特定の命令に対する呼び出しの実行時間が測定され（ステップ１３０１）、安全な記憶装置１３０３に記録される（ステップ１３０２）。モバイルａｐｐ２１５が実行されるとき、クロック確認１３０５が実施される。モバイルａｐｐ２１５が実行され、Ｓｏｆｔ ＴＥＥバーチャルマシン５１７が命令数を追跡するとき（ステップ１３０９）、Ｓｏｆｔ ＴＥＥバーチャルマシン５１７が開始され（ステップ１３０７）。Ｓｏｆｔ ＴＥＥバーチャルマシン５１７は、システムクロックをフェッチし（ステップ１３１３）、命令数から予想時間を計算し（ステップ１３１５）、予想時間とシステムクロックを比較する（ステップ１３１７）ことにより、周期的にクロック確認チェック１３１１を実施する。予想時間とシステム時間の相違が、ある所定のしきい値に対して範囲外にあるとき、ある矯正アクション、たとえば、モバイルａｐｐ２１５を停止する、または、モバイルａｐｐ２１５がアクセスできるハードウェアリソースに制限をかけるアクションを取ることができる（ステップ１３１９）。一実施形態において、ｎの数の命令が一定量の時間ｔを必要とし、そして、そのため、特定の命令数、たとえばｍ＊ｎまで追跡した後で、実行時間はｍ＊ｔとなると予想できるであろう。特定のしきい値を超える偏差により、矯正アクションがトリガされるであろう。

モバイルａｐｐ２１５に対する攻撃には、バーチャルマシン５１５によって実行されている間に、デバッギング技法を使用して、モバイルａｐｐ２１５の重要な機能を検査することが含まれる。本明細書で説明した技術の実施形態はまた、信頼できるアプリケーション５１９のインストール中に、信頼できるアプリケーション５１９に追加された短いループおよび長いループをベンチマークすることにより、反デバッギング技法を迂回させるこうした検査攻撃を妨害するための技法を含む。図１４は、この概念を示すタイミングシーケンス図である。

図１４は、攻撃から保護されるべき、信頼できるアプリケーション５１９の重要な部分１４０１、たとえば暗号コードを示す。コードセグメント１４０３が重要な部分１４０１に付加されている。重要な部分は、多数の可能な経路およびいくつかのループを含んでいる。たとえば、第１のループ１４０５は、短いブロック１４０７および長いブロック１４０９を含む。第１のループの実行経路が短いブロック１４０７を通れば、第１のループ１４０５の所与の数の繰り返し実行は、その実行が長いブロック１４０９を通るとした場合よりもはるかに短くなるであろう。同様に、ループ２からｎ１４１１は、短いブロック１４１３を通るか、長いブロック１４１５を通って実行できるが、この場合も全体の実行時間に影響を与える。

コードセグメント１４０３にとって、どちらの実行経路が使用されるかは、どちらのブロックが実行されることになるのか、および何回繰り返すことになるのかを示す乱数によって決定される。

短いブロックおよび長いブロックのブロック実行時間、ならびに、各ループの繰り返し回数を知ることにより、コード内の、様々な位置間、検査ポイント間の予想される経過時間を予測することが可能である。たとえば、長いブロック１４０９はｔサイクル、短いブロックは０．５＊ｔサイクルを取ると予想され、ループ１ １４０５は短いブロックをｎ回実行すると予想されることが知られている場合、検査ポイント１４１７における時間ｂと、開始ポイント１４１９における時間ａとの間の時間差は、ｎ＊ｔとなると予測することができる。そこからの偏差は、コードがループ１の実行中に、デバッガによって何がしかの時間一時停止されたことを示す可能性がある。それぞれ、検査ポイント１４２１および１４２３における時間ｃおよびｄに関しても同様である。

あり得る操作を決定するために、ランダム化された実行継続時間が検査されるランタイム中に、実行経路をランダム化する図１４の機構の使用を示す流れ図である。

ステップ１５０１：追加されたダミーコードセグメント１４０３を通る実行経路を決定するために使用される乱数Ｒが生成される。

ステップ１５０３：乱数Ｒを使用して実行経路を決定する。たとえば、Ｒの異なるビットは、長いブロックまたは短いブロックのどちらが様々なループで実行されるかを示すことができる。他のビットは繰り返しの回数を示すことができる。

ステップ１５０５：短いブロックまたは長いブロックのどちらが実行されるか、および繰り返しの回数を含む実行経路を使用して、様々な識別された検査ポイントにおける予想到達時間を決定する。

ステップ１５０７：検査ポイントによってインデックス付けされた予想到達時間、および、検査ポイント１４２３において保護されることになる重要なコード１４０１を実行後の合計の予想実行時間は、信頼できる記憶装置５２３といったなんらかの保護された形式で記録されるのが理想的である。

ステップ１５０９：信頼できるアプリケーションを実行中。

ステップ１５１１：各検査ポイントにおいて、検査ポイントにおける到達時間が、予想到達時間と比較される。所定のしきい値を超える偏差がある場合（ステップ１５１３）、矯正アクション（ステップ１５１５）が行われる。

そうでない場合、すなわち、偏差が受け入れられる程度に小さい場合、ステップ１５１１で次の検査ポイントに遭遇するまで、実行は継続する１５１７。

したがって、信頼できるアプリケーションを実行中のなんらかのポイントにおいて、実行が、たとえばデバッガの使用により中断すると、実行時間が乱され、到達時間が予想到達時間と一致しなくなるであろう。それにより、矯正アクションが取られる状態がトリガされるであろう。

例示目的で、モバイル装置１０３に使用することができるように、本明細書に提示した技術が説明してある。しかし、提示した技術は、安全な信頼できる実行環境を必要とする任意のプログラム可能な電子装置に適用可能である。

今まで述べてきたことから、モバイル装置を使用しモバイルａｐｐを実行して、モバイル装置に記憶されたかまたはモバイル装置を使用して遠隔サーバにアクセスされた秘密データを操作するとき、強化されたレベルの信頼が期待できるように、信頼できる実行環境をモバイルａｐｐに導入する機構を提供することにより、モバイル装置上で実行するアプリケーションのセキュリティを向上させる技術が提供されるということは明白であろう。こうした強化は、モバイル装置ハードウェアを変更する必要はないが、モバイル装置ハードウェアの動作と関連付けられたセキュリティを強化する、堅牢で、柔軟かつ経済的な方法で達成される。

本発明の特定の実施形態が、説明され例示されているが、本発明は、説明され例示された特定の形式または部品の構成に限定されるものではない。本発明は、特許請求の範囲によってのみ限定される。

Claims (13)

1. モバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法であって、モバイル装置が、
   信頼できないアプリケーションプロバイダからのモバイルアプリケーションの信頼できない部分を、モバイル装置にロードし、
   信頼できるアプリケーションプロバイダからのモバイルアプリケーションの信頼できる部分を、モバイル装置にロードし、
   モバイルアプリケーションの信頼できる部分をモバイル装置にインストールし、それによって信頼できる実行環境を提供する
   ように構成されることを含む、方法。
2. モバイルアプリケーションの信頼できる部分をモバイル装置にロードすることが、
   モバイルアプリケーションが、モバイルアプリケーションの識別子およびモバイル装置の装置フィンガープリントから、信頼できる実行環境ｉｄ ＴＥＥ ＩＤを生成するステップであって、前記生成された信頼できる実行環境ｉｄ ＴＥＥ ＩＤが、モバイルアプリケーションによってキー提供サーバに送信される、生成するステップと、
   キー提供サーバを動作させて、信頼できる実行環境ｉｄ ＴＥＥ ＩＤと関連付けられるキーを生成し、キーディレクトリに、信頼できる実行環境ｉｄ ＴＥＥ ＩＤおよび生成されたキーを送信し、モバイル装置に、生成されたキーを送信するステップと、
   信頼できるアプリケーションプロバイダが、ＴＥＥ ＩＤ、および、モバイル装置によって送信された生成されたキーから計算されたＴＥＥ ＩＤのハッシュを受信し、キーディレクトリサーバを通してモバイル装置を認証するように構成されるステップと、
   モバイル装置を成功裏に認証した際に、信頼できるアプリケーションプロバイダを動作させて、信頼できるアプリケーションを含むモバイルアプリケーションの信頼できる部分をモバイル装置に送信するステップと、
   モバイル装置が、モバイルアプリケーションの信頼できる部分をモバイル装置にインストールするように構成され、それにより、信頼できる実行環境を提供するステップと、
   を含む、請求項１に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
3. モバイルアプリケーションの信頼できない部分が、
   モバイル装置のリッチ実行環境内で実行可能なクライアントアプリケーションと、
   信頼できるアプリケーションを実装できる命令セットのための信頼できるアプリケーションインタープリタと、
   を含む、請求項１または２に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
4. 信頼できるアプリケーションが、信頼できるアプリケーションインタープリタによって解釈できる命令セット内で実装される、請求項１から３のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
5. モバイルアプリケーションに関連付けられたキーが、ホワイトボックスキー「ＷＢＣキー」およびイニシャルピン暗号キー「ＩＰＥＫ」を含み、さらに、方法が、モバイルアプリケーションと関連付けられたキーをモバイル装置に送信する前に、ＷＢＣキーを使用してＩＰＥＫを暗号化することを含み、ＩＰＥＫの暗号化バージョンがモバイル装置に送信される、請求項１から４のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
6. モバイルアプリケーションの信頼できる部分が、信頼できるサーバプロバイダによってモバイル装置に送信される前に、イニシャルピン暗号キー「ＩＰＥＫ」から生成されたセッションキーを使用して暗号化される、請求項５に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
7. モバイルアプリケーションの信頼できない部分が、信頼できる実行環境のハードウェア実装に似た機能を実装する、アプリケーションプログラムインタフェースを含む、請求項１から６のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
8. 信頼できるアプリケーションを信頼できる安全な記憶装置と関連付けるステップと、
   最初のランダム秘密をモバイル装置の安全な記憶装置に記憶するステップと、
   信頼できるアプリケーションの安全な記憶装置内のデータにアクセスするたびに、最初のランダム秘密「ＩＲＳ」、装置のフィンガープリント、および、信頼できるアプリケーションのための一意のｉｄ「ＵＵＩＤ」を使用して、信頼できるアプリケーションと関連付けられた信頼できる記憶装置に記憶されたデータを暗号化するために、安全な記憶データキー「ＴＡ＿ＳＫ」を生成するステップと
   をさらに含む、請求項１から７のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
9. 信頼できるアプリケーションを実行する間に、
   信頼できるアプリケーションのその特定の実行と関連付けられた１回限りのランタイムキーを決定するステップと、
   信頼できるアプリケーションのその特定の実行中に、信頼できるアプリケーションによって使用されるランタイムメモリに数量を記憶するとき、１回限りのランタイムキーを使用してその数量をマスクするステップと、
   信頼できるアプリケーションのその特定の実行中に、信頼できるアプリケーションによって使用されるランタイムメモリから数量を取得するとき、１回限りのランタイムキーを使用してその数量をアンマスクするステップと、
   をさらに含む、請求項１から８のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
10. 実行または解釈するためにコンパイルされた形式を有する信頼できるアプリケーションを最初に実行した際に、信頼できるアプリケーションのコンパイルされた形式に基づいて第１の値を計算し、信頼できるアプリケーションのコンパイルされた形式に基づいてその値を記憶するステップと、
    信頼できるアプリケーションの後続の実行をした際に、信頼できるアプリケーションのコンパイルされた形式に基づいて同じ計算を実施して、信頼できるアプリケーションのコンパイルされた形式に基づいて第２の値を生成し、第１の値と第２の値を比較し、第１の値と第２の値が同一でない場合は矯正アクションを行うステップと、
    をさらに含む、請求項１から９のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
11. ソフトウェアの信頼できる実行環境の最初の実行をした際に、モバイルアプリケーションの特定の命令の予想実行時間を決定し、
    前記一定の命令の予想実行時間を記憶し、
    ソフトウェアの信頼できる実行環境の後続の実行中に、
    命令数を追跡し、
    システムクロックを定期的にフェッチし、
    現在の命令数から予想実行時間を計算し、
    予想実行時間と現在のシステムクロックを比較し、
    比較が受け入れがたい偏差を示す場合、矯正アクションを行う
    ことにより、潜在的なタイムシフト攻撃を防御するステップをさらに含む、請求項１から１０のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
12. 特定の命令が、アプリケーションプログラムインタフェースの機能に対する呼び出しである、請求項１１に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。
13. 信頼できるアプリケーションの重要な部分を、複数のループを有し、各ループが短いループまたは長いループとして実行されることができるダミーコード部で修正するステップと、
    ダミーコード部の内部および信頼できるアプリケーションの前記重要な部分の近傍に複数の検査ポイントを割り当てるステップと、
    信頼できるアプリケーションを実行した際に、定義された数の短いループおよび長いループを実行する、ダミーコード部を通る実行経路を決定するステップと、
    各検査ポイントの予想到達時間を決定するステップと、
    検査ポイントに到達した際に、予想到達時間と実際の到達時間を比較し、実際の到達時間と予想到達時間の間の偏差が所定のしきい値を超える場合に、矯正アクションを行うステップと、
    をさらに含む、請求項１から１２のいずれか一項に記載のモバイル装置上で実行するためのモバイルアプリケーションを安全にするための方法。

Images