(57)【要約】デバイス（１１０）は、アプリケーションのＡＰＫを受信する（Ｓ３０２）。その間に、コードは変更される（Ｓ３０６）。変更されたコードのためのチェックサムが生成され（Ｓ３０８）、デバイスのＯＳ（２１０）内の信頼できるエンティティ（２１４）の署名キー（２１５）を用いて署名される（Ｓ３１０）。署名付きチェックサム及び署名キーの証明書（２１６）は、メモリ内の予約スペース（２２６，２２８）において記憶される（Ｓ３１２）。変更されたアプリケーションが次いで実行され得る（Ｓ３１４）。その間に、アプリケーション（２２０）のライブラリ（２３０）内のインテグリティ確認モジュール（２３２）は、変更されたアプリケーションのインテグリティを確かめることができる。解決法は、インストール中にＤＥＸがＯＤＥＸへ最適化されるか又は署名が存在しないＥＬＦへコンパイルされるので、アンドロイドＯＳを使用するデバイスに特に適している。
2018503153.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを処理するデバイスであって、
前記アプリケーションを受信するよう構成されるインターフェイスと、
前記アプリケーションと、修正アプリケーションのための署名付きチェックサムとを記憶するよう構成されるメモリと、
プロセッシングユニットと
を有し、
前記プロセッシングユニットは、
前記アプリケーションを変更して、修正アプリケーションを取得し、
前記修正アプリケーションのためのチェックサムを生成し、
署名キーを用いて、前記修正アプリケーションのためのチェックサムに署名し、
前記署名付きチェックサムを前記メモリにおいて記憶する
よう構成される、デバイス。
【請求項２】
前記アプリケーションは、第１のチェックサムを有し、
前記プロセッシングユニットは、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用するよう更に構成される、
請求項１に記載のデバイス。
【請求項３】
前記第１のチェックサムは、署名付きであり、
前記プロセッシングユニットは、前記第１のチェックサムの署名を確かめるよう更に構成される、
請求項２に記載のデバイス。
【請求項４】
前記プロセッシングユニットは、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名付きチェックサムを使用するよう更に構成される、
請求項１に記載のデバイス。
【請求項５】
前記アプリケーションは、解釈コードとして実装され、
前記修正アプリケーションは、最適化された解釈コードとして実装される、
請求項１に記載のデバイス。
【請求項６】
当該デバイスは、スマートフォン又はタブレットである、
請求項１に記載のデバイス。
【請求項７】
前記署名キーは、ソフトウェア保護技術を用いて保護される、
請求項１に記載のデバイス。
【請求項８】
前記プロセッシングユニットは、複数のチェックサムを生成し、該複数のチェックサムが前記修正アプリケーションの異なる部分のために生成され、且つ、前記修正アプリケーションのための前記複数のチェックサムに署名するよう構成される、
請求項１に記載のデバイス。
【請求項９】
前記プロセッシングユニットは、前記修正アプリケーションのための前記複数のチェックサムについて単一の署名を生成するよう構成される、
請求項８に記載のデバイス。
【請求項１０】
前記メモリは、前記修正アプリケーションと、前記署名キーのための証明書とを記憶するよう更に構成され、
前記プロセッシングユニットは、前記署名キーのための前記証明書を前記メモリにおいて記憶するよう更に構成される、
請求項１に記載のデバイス。
【請求項１１】
アプリケーションを処理する方法であって、
デバイスにおいて、
前記アプリケーションを受信し、
前記アプリケーションを変更して、修正アプリケーションを取得し、
前記修正アプリケーションのためのチェックサムを生成し、
署名キーを用いて、前記修正アプリケーションのための前記チェックサムに署名し、
前記署名されたチェックサムをメモリにおいて記憶する
ことを有する方法。
【請求項１２】
前記アプリケーションは、第１のチェックサムを有し、
当該方法は、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用することを更に有する、
請求項１１に記載の方法。
【請求項１３】
前記第１のチェックサムは、署名付きであり、
当該方法は、前記第１のチェックサムの署名を確かめることを更に有する、
請求項１２に記載の方法。
【請求項１４】
当該方法は、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名されたチェックサムを使用することを更に有する、
請求項１１に記載の方法。
【請求項１５】
前記修正アプリケーションと、署名キーのための証明書とを前記メモリにおいて記憶すること
を更に有する請求項１１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、コンピュータシステムに関係があり、特に、そのようなシステムにおけるソフトウェアコードのインテグリティに関係がある。
【背景技術】
【０００２】
この項目は、以下で記載及び／又は請求される本開示の様々な態様に関係があり得る当該技術の様々な態様を読者に紹介することを目的とする。この議論は、本開示の様々な態様のより良い理解を促すよう読者に背景情報を提供するのに有用であると信じられる。然るに、それらの記述は、先行技術の承認としてではなく、この観点から読まれるべきであることが理解されるべきである。
【０００３】
様々な理由により、改ざんされていないソフトウェアをプロセッシングデバイスが実行することを確かにすることが、しばしば望まれる。このために、種々の技術が、改ざん攻撃からソフトウェア画像を保護するために使用され得る。最も一般的な技術は、コードセグメントに対する署名又はチェックサムを計算して、後の段階でその署名又はチェックサムを確かめることである。チェックサムは、一般に、如何なる秘密もなしで計算され確かめられ、一方、暗号署名の生成は、私有鍵、及び対応する公開鍵による署名の確認を必要とする。
【０００４】
チェックサムに基づく保護の一例は、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムで使用されるＰｏｒｔａｂｌｅ  Ｅｘｅｃｕｔａｂｌｅ（ＰＥ）フォーマットのためのＣＲＣ３２である。ＰＥヘッダは、対応するコードセクションのチェックサムを与えるＣＲＣ３２フィールドを含む。保護を成功裏に迂回するよう、攻撃者は、最初にコードセクションを変更し、次いで、元のチェックサムを、変更されたコードセクションに対して計算された新しい値により置き換える。このような攻撃は、攻撃者が変更されたコードセクションのチェックサムを更新するために如何なる秘密も必要としないので、起こり得る。
【０００５】
チェックサムの脆弱性を考えると、暗号署名は、好ましい解決法である。署名の生成は、コードリリースより前に実施され、私有（よって秘密）鍵を使用する。関連する公開鍵は、コードに添付され、後に、コードのインストール時に又はランタイム時にコードインテグリティを確認するために使用される。攻撃者は、依然としてコードを変更することができるが、コードの正確な署名が私有鍵なしでは生成され得ないので、攻撃者は失敗する。
【０００６】
多くの解決法が、ネイティブコードで配信及び実行されるアプリケーションのインテグリティを確認するために存在する。例えば、Ａｒｘａｎ（ＧｕａｒｄＩＴ）、Ｍｅｔａｆｏｒｉｃ（Ｍｅｔａｆｏｒｔｒｅｓｓ）、などによって提供される解決法がある。ネイティブコードは、プロセッサによって直接実行可能なアセンブラ命令の組である。命令の組は、インストール後に変化しない。これは、プログラムのインテグリティ値がインストールの前後で同じままである（すなわち、時間にわたって一定のままである）ことを意味する。この場合に、署名は、前もって生成され、アプリケーションパッケージとともに配信され得る。
【０００７】
他方で、Ｊａｖａ（登録商標）で書かれたコード、Ａｎｄｒｏｉｄ（登録商標）ＤＥＸコード、などのような解釈コード（interpreted  code）の形で分配されるアプリケーションは、実行される前にインタプリタ（interpreter）に通されるべき中間命令を有する。ネイティブコードと異なり、解釈コードは、最適化のためにインストール時間後に変更され得る。コード変更は、一般に、ターゲットプラットフォームに大いに依存し、よって、必ずしも予測可能でない。コードが変更される場合には、解釈コードに対して生成される署名は、ランタイム時に動的にコードのインテグリティ及び真偽を確認するために使用され得ない。
【０００８】
アプリケーションソフトウェアを分配し、前述のＡｎｄｒｏｉｄオペレーティングシステム上にインストールするよう、ＡＰＫ（Android  Application  PacKage）と呼ばれるファイルフォーマットが使用される。ＡＰＫファイルを作るよう、Ａｎｄｒｏｉｄのためのプログラムは、最初に、中間言語へコンパイルされ、次いで、その部分は圧縮アーカイブファイル（ＺＩＰフォーマット）にパッケージングされる。アーカイブファイルは、単一のＤＥＸ（Dalvik  Executable  code）ファイル、様々なリソース（例えば、画像ファイル）、及びＡＰＫファイルのマニフェストにおいてプログラムコード全体を含む。アーカイブファイルは、２つの追加ファイル、すなわち、ＣＥＲＴ．ＳＦ及びＣＥＲＴ．ＲＳＡを含む。ＣＥＲＴ．ＳＦは、他の全てのアーカイブファイルの暗号ハッシュを含み、ＣＥＲＴ．ＲＳＡは、署名確認のために使用される公開鍵を含む。ＣＥＲＴ．ＳＦのみがＲＳＡ私有鍵により署名される。ＣＥＲＴ．ＳＦのためのＲＳＡ署名は、インストール中のＡＰＫの全内容のバリデーションを可能にする。実際に、ＣＥＲＴ．ＳＦにおいて記述されている全てのファイルは、ＣＥＲＴ．ＳＦがそれらのハッシュを含むので、間接的に署名される。インストール前にいずれかのファイルを変更することは、エラーを引き起こしうる。これは、ファイルダイジェストがＣＥＲＴ．ＳＦファイル内のハッシュと一致しないことをソフトウェアが検出することになるからである。代替的に、（上述されたチェックサムに基づく確認に対する攻撃で見られたように）ＣＥＲＴ．ＳＦ内の暗号ハッシュ値を変更することは、署名確認中のエラーを引き起こしうる。
【０００９】
ＤＥＸファイルヘッダはまた、ＤＥＸファイルの内容のためのグローバルなチェックサムを含む。アプリケーションの最初の実行時に、Ａｎｄｒｏｉｄシステムは、実行前の間際に、ＤＥＸ解釈バイトコードを、ＯＤＥＸ（Optimized  DEX）と呼ばれる最適化されたマシン命令シーケンスに変更するオプティマイザ（optimizer）を使用する。オプティマイザはまた、チェックサムを更新する。ＯＤＥＸファイルは、次いで、将来の使用のために、Ａｎｄｒｏｉｄファイルシステム内の特定のリポジトリにおいて記憶される。ＯＤＥＸファイルは、次いで、アプリケーションソフトウェアのためのリファレンスになり、それが存在する場合に、元のＤＥＸファイルはもはや使用されない。
【００１０】
ランタイム時に、システムは、ＯＤＥＸチェックサムを用いてアプリケーションのインテグリティを確かめ得る。しかし、このオプションは、Ａｎｄｒｏｉｄオペレーティングシステム及びＤａｌｖｉｋマシンにおいてデフォルトで設定されていない。それは、ＯＤＥＸコードを実行するために使用されるが、ＯＤＥＸチェックサムを常に確認するわけではない。これは、チェックサムの確認が実行性能に対して無視できない影響を有するからである。
【００１１】
Ａｎｄｒｏｉｄバージョン５．０以降は、Ｄａｌｖｉｋマシンに取って代わるＡｎｄｒｏｉｄ  Ｒｕｎｔｉｍｅ（ＡＲＴ）を導入した。アプリケーションは依然としてＤＥＸコードにおいて展開されるが、インストール時に、ＤＥＸコードは、事前コンパイル（ＡＯＴ；ahead-of-time  compilation）機能を用いてネイティブコードへコンパイルされる。ＤＥＸファイルに対するＡＯＴコンパイルは、バイナリＥｘｅｃｕｔａｂｌｅ  Ｌｉｎｋａｂｌｅ  Ｆｏｒｍａｔ（ＥＬＦ）ファイルをもたらす。アプリケーションのＤＥＸコードは、次いで一度コンパイルされ、それから、ＥＬＦコードは、後に、アプリケーションが実行されるたびに起動される。ＡＲＴが直接にネイティブコード（ＥＬＦコード）を実行するので、それはアプリケーションの実行をより高速化し、全体の電力消費を改善する。よって、Ａｎｄｒｏｉｄシステムにおいて、ＡＰＫ署名はインストール時にのみ確認されることが分かる。更には、ＡＰＫは、中央当局によって署名されていない場合でさえ、ユーザが信頼できないソースに由来するアプリケーションのインストールを認めるときには、Ａｎｄｒｏｉｄデバイスにインストールされ得る。アプリケーション開発者は、その結果、如何なる信頼できる当局へもリンクされていない彼ら自身の自己署名証明書（self-signed  certificates）を使用する。その場合に、改ざんされたアプリケーションは、Ａｎｄｒｏｉｄデバイスに対する、その所有者に知られていないいずれかのハッカーによって、署名を付け直され、再インストールされ得る。
【００１２】
上述されたように、Ａｎｄｒｏｉｄアプリケーションは、インタプリタ・ポータブルフォーマット（ＤＥＸ）を使用する。このポータブルフォーマットは、異なるアーキテクチャ及び特性（例えば、ＡＲＭ、ｘ８６、ＭＩＰＳ、Ｌｉｔｔｌｅ／Ｂｉｇ  Ｅｎｄｉａｎなど）を備えたデバイスの大規模な組に対して実行することができる。性能を改善するために、ＤＥＸコードは、ターゲットデバイスのために最適化されているＯＤＥＸ又はＥＬＦを生成するよう、アプリケーションのインストール時又は最初の使用時に変更される。最適化又はＡＯＴコンパイルの間、様々なモノがコードにおいて変更され得る。例えば、命令は他の命令によって置換され得、命令のアライメントは変更されてよく、バイト順序は交換され得る、など。
【００１３】
最適化及びＡＯＴコンパイルは、その場合に、セキュリティ問題を引き起こす。ＤＥＸファイルの署名は、ＣＥＲＴ．ＳＦ及びＣＥＲＴ．ＲＳＡを用いて依然として確認され得るが、一方で、これは、ＯＤＥＸ及びＥＬＦファイルには当てはまらない。なぜなら、それらは変更されており、それらのインテグリティは元のＤＥＸ署名へもはやリンクされていないからである。すなわち、インテグリティ及び真偽は、インストール時にしか確認され得ず、以降ランタイム時に、攻撃者は、ＯＤＥＸ及びＥＬＦコードを変更し、ヘッダ内の最終的なチェックサムを然るべく更新することができる。
【００１４】
このように、システムは、少なくとも２種類の攻撃、すなわち、リモート攻撃及びルート攻撃を受けやすい。リモート攻撃では、ダウンロードされた悪意的アプリケーションがその特権を高め、システムパーミッションを得る。悪意的アプリケーションは、その場合に、内部ストレージのキャッシュリポジトリに記憶されているＯＤＥＸ及びＥＬＦファイルを改ざんし得る。ルート攻撃では、攻撃者は、例えば、デバイスを盗むことによって、又は所有者がデバイスセッションをロックせずに席を外しているときにデバイスにアクセスすることによって、Ａｎｄｒｏｉｄデバイスを入手する。攻撃者は、ＵＳＢリンクを通じてデバイスの内部ストレージからインストールされているアプリケーションを取り出し、アプリケーションを変更し、そして、変更されたアプリケーションを内部ストレージに戻すことができる。後の攻撃が成功するために、デバイスは“ルート化”されなければならない（すなわち、“ルートアクセス”が、デバイスのＡｎｄｒｏｉｄシステムの支配権を握るために必要とされる。）。
【００１５】
Ａｎｄｒｏｉｄアプリケーションのインテグリティにおける信用は、このようにして、アプリケーションのライフサイクルの間に壊され得る。Ａｎｄｒｏｉｄシステムにインストールされているものを信用することは可能であるが、実行されているものについては必ずしもそうではない。
【００１６】
解釈コードアプリケーションのインテグリティ及び真偽に関する問題の少なくとも一部を解決する解決法を有することが望まれていると認識されるだろう。本開示は、そのような解決法を提供する。
【発明の概要】
【００１７】
第１の態様において、本開示は、アプリケーションを処理するデバイスを対象とする。当該デバイスは、前記アプリケーションを受信するよう構成されるインターフェイスと、前記アプリケーション、及び修正アプリケーションのための署名付きチェックサムを記憶するよう構成されるメモリと、前記アプリケーションを変更して修正アプリケーションを取得し、該修正アプリケーションのためのチェックサムを生成し、署名キーを用いて前記修正アプリケーションのためのチェックサムに署名し、該署名付きチェックサムを前記メモリにおいて記憶するよう構成されるプロセッシングユニットとを有する。
【００１８】
第１の態様の様々な実施形態は、次の特徴を含む：
●  前記アプリケーションは、第１のチェックサムを有し、前記プロセッシングユニットは、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用するよう更に構成されること。前記第１のチェックサムは署名付きであり、前記プロセッシングユニットは前記第１のチェックサムの署名を確かめるよう更に構成されることが、有利である。
●  前記プロセッシングユニットは、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名付きチェックサムを使用するよう更に構成されること。
●  前記アプリケーションは解釈コードとして実装され、前記修正アプリケーションは、最適化された解釈コードとして実装されるか、あるいは、前記修正アプリケーションは、ネイティブコードとしてコンパイルされること。
●  当該デバイスは、スマートフォン又はタブレットであること。
●  前記署名キーは、ソフトウェア保護技術を用いて保護されること。
●  前記プロセッシングユニットは、前記修正アプリケーションのための複数のチェックサムを生成し、該複数のチェックサムが前記修正アプリケーションの異なる部分のために生成され、且つ、前記修正アプリケーションのための前記複数のチェックサムに署名するよう構成されること。
●  前記プロセッシングユニットは、前記修正アプリケーションのための前記複数のチェックサムについて単一の署名を生成するよう構成されること。
●  前記メモリは、前記修正アプリケーションと、前記署名キーのための証明書とを記憶するよう更に構成され、前記プロセッシングユニットは、前記署名キーのための前記証明書を前記メモリにおいて記憶するよう更に構成されること。
【００１９】
第２の態様において、本開示は、アプリケーションを処理する方法を対象とする。デバイスは、前記アプリケーションを受信し、前記アプリケーションを変更して修正アプリケーションを取得し、該修正アプリケーションのためのチェックサムを生成し、署名キーを用いて前記修正アプリケーションのための前記チェックサムに署名し、該署名されたチェックサムをメモリにおいて記憶する。
【００２０】
第２の態様の様々な実施形態は、次の特徴を含む：
●  前記アプリケーションは、第１のチェックサムを有し、当該方法は、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用することを更に有すること。
●  前記第１のチェックサムは、署名付きであり、当該方法は、前記第１のチェックサムの署名を確かめることを更に有すること。
●  当該方法は、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名されたチェックサムを使用することを更に有すること。
●  当該方法は、前記修正アプリケーションと、署名キーのための証明書とを前記メモリにおいて記憶することを更に有すること。
【図面の簡単な説明】
【００２１】
本開示の好適な特徴は、これより、非限定的な例を用いて、添付の図面を参照して記載される。
【図１】本開示が実施されるシステムの例を表す。
【図２】例となるシステムの機能的側面を表す。
【図３】本開示の好適な実施形態に従う方法のフローチャートを表す。
【発明を実施するための形態】
【００２２】
図１は、本開示が実施されるシステムの例を表す。システムは、デバイス１１０及びアプリケーションプロバイダ（アプリケーションストア）１２０を有する。デバイス１１０は、例えばスマートフォン又はタブレットのような、Ａｎｄｒｏｉｄ  ＯＳを実行する如何なる種類の適切なデバイスでもあることができ、それは、少なくとも１つのハードウェア・プロセッシングユニット（“プロセッサ”１１１）、メモリ１１２、ユーザと対話するためのユーザインターフェイス１１３、及び例えばインターネットのような接続１４０を介してアプリケーションプロバイダ１２０と通信するための通信インターフェイス１１４を有する。当業者に明らかなように、表されているデバイスは、明りょうさのために大いに簡略化されており、実際のデバイスは、電源及び永続性記憶装置のような機構を更に有し得る。アプリケーションプロバイダ１２０は、デバイス１１０によってダウンロードされ得る少なくとも１つのアプリケーションＡＰＫファイル１２２を記憶している。ＡＰＫファイルは、署名エンティティによって署名されたＡＰＫ証明書を有する。
【００２３】
図２は、例となるシステムの機能的側面を表す。デバイス１１０のＯＳ２１０は、署名モジュール２１２及び組み込み型信頼エンティティ２１４を有する。信頼エンティティ２１４は、対応する署名証明書２１６とともに署名キー２１５を記憶している。署名キー２１５は、デバイスにとって又はＯＳのバージョンにとって（少なくとも統計的に）一意であることができ、それは、夫々のデバイスについて一意であるデバイスキーによって保護され得る。証明書は、直接に又は信頼チェーン（chain  of  trust）を通じて署名エンティティによって署名される。
【００２４】
アプリケーション２２０は、署名エンティティによって署名されたＡＰＫ証明書２２２と、アプリケーションコード２２４（インストール前のＤＥＸ及びインストール後のＯＤＥＸ又はＥＬＦ）と、ＯＤＥＸ又はＥＬＦチェックサムを記憶するための予約スペース（reserved  space）２２６と、ＯＤＥＸ又はＥＬＦ署名及び署名証明書を記憶するための予約スペース２２８と、インテグリティ確認モジュール２３２を有するライブラリ２３０とを有する。
【００２５】
署名モジュール２１２は、アプリケーションのインストール時に、アプリケーションのＡＰＫ証明書２２２を確認し、アプリケーションのためのＯＤＥＸ又はＥＬＦチェックサムを計算し、ＯＤＥＸ又はＥＬＦチェックサムに署名するよう構成される。署名モジュール２１２は、Ｄａｌｖｉｋ仮想マシンにおいて、あるいは、ＤＥＸに対して最適化又はＡＯＴコンパイルを行うユニットにおいて、実装され得る。ＡＰＫ証明書２２２は、如何なる適切な先行技術の確認技術によっても確認される。署名モジュール２１２は、アプリケーションのキャッシュリポジトリ内の予約スペース２２６、２２８においてＯＤＥＸ又はＥＬＦチェックサム及び署名を書き込むよう構成される。署名モジュール２１２はまた、署名証明書２１６をキャッシュリポジトリにおいて記憶する。
【００２６】
複数のチェックサム、例えば、ＤＥＸコード全体のための１つのチェックサム及びＤＥＸコードのセクションのための少なくとも１つの更なるチェックサム、を使用することが可能であると理解されるだろう。この事例では、署名モジュール２１２は、全てのチェックサムを確認し、対応するＯＤＥＸ又はＥＬＦチェックサムを生成し、生成された全てのＯＤＥＸ又はＥＬＦチェックサムに（有利なことに、単一の署名を用いて）署名し、ＯＤＥＸ又はＥＬＦチェックサム及び署名をキャッシュリポジトリにおいて記憶する。
【００２７】
インテグリティ確認モジュール２３２は、ＡＰＫのネイティブライブラリにおいて含まれており、拡張ＪＮＩライブラリへのアクセスを有している。拡張ＪＮＩライブラリへのアクセスは、実行中にいつでもＯＤＥＸ又はＥＬＦチェックサム及び対応する署名をチェックすることを可能にする。インテグリティ確認モジュール２３２は、アプリケーションの部分として実行される場合に、如何なる適切な方法でも署名証明書をチェックし、ＯＤＥＸ又はＥＬＦチェックサムのための署名をチェックし、ＯＤＥＸ又はＥＬＦの現在のチェックサムを計算し、計算されたチェックサムを署名され（そして確認され）たチェックサムと比較するよう構成される。チェックのいずれかが失敗する場合に適切な対策が取られ得ることが、理解されるだろう。
【００２８】
図３は、好適な実施形態に従う方法のフローチャートを表す。ステップＳ３０２で、デバイス１１０は、アプリケーションのためのＡＰＫファイルを受信し、ステップＳ３０４で、ＡＰＫ証明書を確認する。アプリケーションのインストールの間、デバイス１１０は、ＡＰＫファイル内のＤＥＸに対して最適化又はＡＯＴコンパイルを行い、ステップＳ３０６で、キャッシュリポジトリにおいてＯＤＥＸ又はＥＬＦを取得する。ステップＳ３０８で、デバイス１１０は、ＯＤＥＸのための少なくとも１つのＯＤＥＸ又はＥＬＦチェックサムを計算し、ステップＳ３１０で、署名キー２１５を用いてＯＤＥＸ又はＥＬＦチェックサムに署名する。ステップＳ３１２で、デバイス１１０は、アプリケーションのためのキャッシュリポジトリ内の予約スペース２２６、２２８においてＯＤＥＸ又はＥＬＦチェックサム及び署名証明書を記憶する。デバイス１１０は、次いで、如何なる適切な時点でも、ステップＳ３１４で、ＯＤＥＸ又はＥＬＦを実行し、そして、実行中に、インテグリティ確認モジュール２３２は、ステップＳ３１６で、予約スペース２２６内の署名付きＯＤＥＸはＥＬＦチェックサムと比較される現在のＯＤＥＸ又はＥＬＦチェックサムを計算することによって、ＯＤＥＸ又はＥＬＦのインテグリティをチェックすることができる。インテグリティは、アプリケーションの実行中に複数回チェックされ得る。
【００２９】
解決法は、現在開発されているＡｎｄｒｏｉｄシステムに対するわずかな変更を必要とすることが知られる。
【００３０】
本明細書において、語「チェックサム」は、チェックサムの生成後にそのチェックサムが生成される元となったデータが変更されたか否かの確認を可能にする値をカバーするよう意図される。チェックサムは、よって、例えば、ハッシュ値、巡回冗長検査（ＣＲＣ；Cyclic  Redundancy  Check）値、又は他の種類のダイジェストであってもよい。チェックサムからコードを得ることが計算上実行不可能であることが望ましい。加えて、単一のチェックサムが明りょうさのために使用されてきたが、複数のチェックサムが使用されてよい。このとき、チェックサムは、コードの相異なる部分のために生成されてよく（なお、異なる部分は重なり合ってよい。）、コードの異なる部分のための複数のチェックサムは、比較のために使用される単一のグローバルなチェックサムを生成するために使用される。署名は、例えば、ハッシュに基づくメッセージ認証符号（ＨＭＡＣ；Hash-based  Message  Authentication  Code）、又は例えば、ＲＳＡ、デジタル署名アルゴリズム（ＤＳＡ；Digital  Signature  Algorithm）若しくは楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ；Elliptic  Curve   Digital  Signature  Algorithm）に基づく署名のような、如何なる適切な暗号署名であってもよい。
【００３１】
本解決法は、ルート攻撃及びリモート攻撃の両方に成功裏に対抗することができると理解されるだろう。
【００３２】
本解決法は、Ａｎｄｒｏｉｄ環境において記載されてきたが、一方で、それは、インストールされたアプリケーションの安全なインテグリティ確認をランタイム時に可能にすることなしにインストール中にコードを変更する他のオペレーティングシステムに適応され得る。
【００３３】
よって、本開示は、Ａｎｄｒｏｉｄデバイス上でアプリケーションのランタイムのインテグリティを可能にすることができる解決法を提供すると理解されるだろう。
【００３４】
本明細書並びに（必要に応じて）特許請求の範囲及び図面において開示されている夫々の特徴は、独立して、又はあらゆる適切な組み合わせにおいて、提供されてよい。ハードウェアにおいて実施されるものとして記載されている特徴は、ソフトウェアにおいても実施されてよく、その逆も同様である。特許請求の範囲において現れる参照符号は、単なる実例であって、特許請求の範囲の適用範囲を制限する効果を有するべきではない。
【図１】
2018503153.tif 000003
【図２】
2018503153.tif 000004
【図３】
2018503153.tif 000005
【手続補正書】
【提出日】平成29年5月31日(2017.5.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションを処理するデバイスであって、
前記アプリケーションを受信する手段と、
前記アプリケーションと、修正アプリケーションのための署名付きチェックサムとを記憶するメモリ手段と、
前記アプリケーションを変更して、修正アプリケーションを取得する手段と、
前記修正アプリケーションのためのチェックサムを生成する手段と、
署名キーを用いて、前記修正アプリケーションのためのチェックサムに署名する手段と、
前記署名付きチェックサムを前記メモリ手段において記憶する手段と
を有するデバイス。
【請求項２】
前記アプリケーションは、第１のチェックサムを有し、
当該デバイスは、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用する手段を更に有する、
請求項１に記載のデバイス。
【請求項３】
前記第１のチェックサムは、署名付きであり、
当該デバイスは、前記第１のチェックサムの署名を確かめる手段を更に有する、
請求項２に記載のデバイス。
【請求項４】
前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名付きチェックサムを使用する手段
を更に有する請求項１に記載のデバイス。
【請求項５】
前記アプリケーションは、解釈済みコードとして実装され、
前記修正アプリケーションは、最適化された解釈済みコードとして実装される、
請求項１に記載のデバイス。
【請求項６】
当該デバイスは、スマートフォン又はタブレットである、
請求項１に記載のデバイス。
【請求項７】
前記署名キーは、ソフトウェア保護技術を用いて保護される、
請求項１に記載のデバイス。
【請求項８】
前記チェックサムを生成する手段は、複数のチェックサムを生成し、該複数のチェックサムが前記修正アプリケーションの異なる部分のために生成され、
前記署名する手段は、前記修正アプリケーションのための前記複数のチェックサムに署名する、
請求項１に記載のデバイス。
【請求項９】
前記署名する手段は、前記修正アプリケーションのための前記複数のチェックサムについて単一の署名を生成する、
請求項８に記載のデバイス。
【請求項１０】
前記メモリ手段は、前記修正アプリケーションと、前記署名キーのための証明書とを記憶し、
当該デバイスは、前記署名キーのための前記証明書を前記メモリ手段において記憶する手段を更に有する、
請求項１に記載のデバイス。
【請求項１１】
アプリケーションを処理する方法であって、
デバイスにおいて、
受信手段によって前記アプリケーションを受信し、
変更手段によって前記アプリケーションを変更して、修正アプリケーションを取得し、
生成手段によって前記修正アプリケーションのためのチェックサムを生成し、
署名手段によって、署名キーを用いて、前記修正アプリケーションのための前記チェックサムに署名し、
記憶手段によって前記署名されたチェックサムをメモリ手段において記憶する
ことを有する方法。
【請求項１２】
前記アプリケーションは、第１のチェックサムを有し、
当該方法は、確認手段によって、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用することを更に有する、
請求項１１に記載の方法。
【請求項１３】
前記第１のチェックサムは、署名付きであり、
当該方法は、前記確認手段によって、前記第１のチェックサムの署名を確かめることを更に有する、
請求項１２に記載の方法。
【請求項１４】
当該方法は、確認手段によって、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名されたチェックサムを使用することを更に有する、
請求項１１に記載の方法。
【請求項１５】
前記記憶手段によって、前記修正アプリケーションと、署名キーのための証明書とを前記メモリ手段において記憶すること
を更に有する請求項１１に記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３４
【補正方法】変更
【補正の内容】
【００３４】
本明細書並びに（必要に応じて）特許請求の範囲及び図面において開示されている夫々の特徴は、独立して、又はあらゆる適切な組み合わせにおいて、提供されてよい。ハードウェアにおいて実施されるものとして記載されている特徴は、ソフトウェアにおいても実施されてよく、その逆も同様である。特許請求の範囲において現れる参照符号は、単なる実例であって、特許請求の範囲の適用範囲を制限する効果を有するべきではない。  
上記の実施形態に加えて、以下の付記を開示する。
（付記１）
アプリケーションを処理するデバイス（１１０）であって、
前記アプリケーションを受信するよう構成されるインターフェイス（１１４）と、
前記アプリケーションと、修正アプリケーションのための署名付きチェックサムとを記憶するよう構成されるメモリ（１１２）と、
プロセッシングユニット（１１１）と
を有し、
前記プロセッシングユニット（１１１）は、
前記アプリケーションを変更して、修正アプリケーションを取得し、
前記修正アプリケーションのためのチェックサムを生成し、
署名キーを用いて、前記修正アプリケーションのためのチェックサムに署名し、
前記署名付きチェックサムを前記メモリ（１１２）において記憶する
よう構成される、デバイス。
（付記２）
前記アプリケーションは、第１のチェックサムを有し、
前記プロセッシングユニットは、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用するよう更に構成される、
付記１に記載のデバイス。
（付記３）
前記第１のチェックサムは、署名付きであり、
前記プロセッシングユニットは、前記第１のチェックサムの署名を確かめるよう更に構成される、
付記２に記載のデバイス。
（付記４）
前記プロセッシングユニットは、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名付きチェックサムを使用するよう更に構成される、
付記１に記載のデバイス。
（付記５）
前記アプリケーションは、解釈済みコードとして実装され、
前記修正アプリケーションは、最適化された解釈済みコードとして実装される、
付記１に記載のデバイス。
（付記６）
当該デバイスは、スマートフォン又はタブレットである、
付記１に記載のデバイス。
（付記７）
前記署名キーは、ソフトウェア保護技術を用いて保護される、
付記１に記載のデバイス。
（付記８）
前記プロセッシングユニットは、複数のチェックサムを生成し、該複数のチェックサムが前記修正アプリケーションの異なる部分のために生成され、且つ、前記修正アプリケーションのための前記複数のチェックサムに署名するよう構成される、
付記１に記載のデバイス。
（付記９）
前記プロセッシングユニットは、前記修正アプリケーションのための前記複数のチェックサムについて単一の署名を生成するよう構成される、
付記８に記載のデバイス。
（付記１０）
前記メモリは、前記修正アプリケーションと、前記署名キーのための証明書とを記憶するよう更に構成され、
前記プロセッシングユニットは、前記署名キーのための前記証明書を前記メモリにおいて記憶するよう更に構成される、
付記１に記載のデバイス。
（付記１１）
アプリケーションを処理する方法であって、
デバイス（１１０）において、
前記アプリケーションを受信し（Ｓ３０２）、
前記アプリケーションを変更して、修正アプリケーションを取得し（Ｓ３０６）、
前記修正アプリケーションのためのチェックサムを生成し（Ｓ３０８）、
署名キーを用いて、前記修正アプリケーションのための前記チェックサムに署名し（Ｓ３１０）、
前記署名されたチェックサムをメモリにおいて記憶する（Ｓ３１２）
ことを有する方法。
（付記１２）
前記アプリケーションは、第１のチェックサムを有し、
当該方法は、前記アプリケーションのインテグリティを確かめるために前記第１のチェックサムを使用することを更に有する、
付記１１に記載の方法。
（付記１３）
前記第１のチェックサムは、署名付きであり、
当該方法は、前記第１のチェックサムの署名を確かめることを更に有する、
付記１２に記載の方法。
（付記１４）
当該方法は、前記修正アプリケーションの実行中に該修正アプリケーションのインテグリティを確かめるために前記署名されたチェックサムを使用することを更に有する、
付記１１に記載の方法。
（付記１５）
前記修正アプリケーションと、署名キーのための証明書とを前記メモリにおいて記憶すること
を更に有する付記１１に記載の方法。
【国際調査報告】
2018503153.tif 000006
2018503153.tif 000007
2018503153.tif 000008