(57)【要約】  デバイス（１１０）がアプリケーションのＡＰＫファイルをダウンロードしてインストールし（Ｓ２０４）、その間にコードが変更される。変更済みコードのチェックサムが信頼されているエンティティ（１３０）に送られ（Ｓ２０６）、信頼されているエンティティ（１３０）は、受け取られたチェックサムがアプリケーションの記憶されているチェックサムと一致することを確認する（Ｓ２０８）。一致する場合、受け取られたチェックサムが署名され（Ｓ２１０）、デバイス（１１０）に返され（Ｓ２１２）、デバイス（１１０）に記憶される（Ｓ２１４）。次に、デバイスは、署名済みチェックサムと比較される変更済みコードのチェックサムを計算することにより、変更済みコードの整合性を確認することができる（Ｓ２１６）。本ソリューションは、特に、Android OSを使用するデバイスに適しており、これは、ＤＥＸがインストール中に最適化されて、証明済みチェックサムが存在しないＯＤＥＸになるためである。
2018503157.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを処理するデバイス（１１０）であって、
前記アプリケーションを受け取るように構成されたインタフェース（１１４）と、
前記アプリケーションと署名済みチェックサムとを記憶するように構成されたメモリ（１１２）と、
処理装置（１１１）であって、
前記アプリケーションを変更して変更済みアプリケーションを取得することと、
前記変更済みアプリケーションについて生成されたチェックサムを信頼されているエンティティに送ることと、
前記送られたチェックサムに対応する署名済みチェックサムを前記信頼されているエンティティから受け取ることと、
前記署名済みチェックサムを前記メモリ（１１２）に記憶することと
を行うように構成された処理装置（１１１）と
を含むデバイス。
【請求項２】
前記アプリケーションは、第１のチェックサムとともに受け取られ、前記処理装置は、前記第１のチェックサムを使用して前記アプリケーションの整合性を検証するように更に構成されている、請求項１に記載のデバイス。
【請求項３】
前記処理装置は、前記署名済みチェックサムを使用して、前記変更済みアプリケーションの実行時に前記変更済みアプリケーションの整合性を検証するように更に構成されている、請求項１に記載のデバイス。
【請求項４】
前記アプリケーションは、インタプリタ型コードとして実装され、及び前記変更済みアプリケーションは、最適化されたインタプリタ型コードとして又はネイティブコードとして実装される、請求項１に記載のデバイス。
【請求項５】
前記処理装置は、前記インタプリタ型コード又は前記最適化されたインタプリタ型コードのヘッダにおいて、前記インタプリタ型コードのチェックサムを、前記署名済みチェックサムに置き換えるように構成されている、請求項４に記載のデバイス。
【請求項６】
スマートフォン又はタブレットである、請求項１に記載のデバイス。
【請求項７】
前記信頼されているエンティティは、前記デバイス内で実装される、請求項１に記載のデバイス。
【請求項８】
前記信頼されているエンティティは、前記アプリケーションの少なくとも１つのチェックサムを記憶することと、前記変更済みアプリケーションの前記チェックサムが前記アプリケーションの記憶されているチェックサムと一致することを検証することと、署名鍵（１３２）を使用して、前記変更済みアプリケーションの前記チェックサムに署名することとを行うように構成されている、請求項７に記載のデバイス。
【請求項９】
前記署名鍵は、ソフトウェア保護技術を使用して保護される、請求項８に記載のデバイス。
【請求項１０】
前記信頼されているエンティティは、独立したデバイスであり、前記インタフェース（１１４）は、前記処理装置から前記変更済みアプリケーションの前記チェックサムを受け取り、前記変更済みアプリケーションの前記チェックサムを前記信頼されているエンティティに送ることと、前記信頼されているエンティティから前記署名済みチェックサムを受け取り、前記署名済みチェックサムを前記処理装置に送ることとを行うように更に構成されている、請求項１に記載のデバイス。
【請求項１１】
前記処理装置は、前記変更済みアプリケーションの前記チェックサムと一緒に、前記アプリケーションのアクティベーションコードを送るように更に構成されている、請求項１に記載のデバイス。
【請求項１２】
前記処理装置は、前記署名済みチェックサムを署名証明書と一緒に受け取るように構成されている、請求項１に記載のデバイス。
【請求項１３】
アプリケーションを処理する方法であって、デバイス（１１０）において、
前記アプリケーションを受け取ること（Ｓ２０４）と、
前記アプリケーションを変更して変更済みアプリケーションを取得すること（Ｓ２０６）と、
前記変更済みアプリケーションについて生成されたチェックサムを信頼されているエンティティに送ること（Ｓ２０６）と、
前記送られたチェックサムに対応する署名済みチェックサムを前記信頼されているエンティティから受け取ること（Ｓ２１２）と、
前記署名済みチェックサムをメモリ（１１２）に記憶すること（Ｓ２１４）と
を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して、コンピュータシステムに関し、特に、そのようなシステムにおけるソフトウェアコードの整合性に関する。
【背景技術】
【０００２】
本セクションは、以下で説明及び／又は特許請求される本開示の様々な態様に関連し得る当該技術分野の様々な態様を読者に紹介することを意図している。この説明は、本開示の様々な態様のよりよい理解を促進するための背景情報を読者に提供することに役立つと考えられる。従って、これらの記載がこの観点から読まれるべきであり、先行技術の容認として読まれるべきでないことが理解されるべきである。
【０００３】
様々な理由により、処理装置が実行するソフトウェアが改ざんされていないことを保証することが多くの場合で望ましい。このため、ソフトウェアイメージを改ざん攻撃から保護するために様々な技術が使用され得る。最も一般的な技術は、コードセグメントの署名又はチェックサムを計算し、後の段階でこの署名又はチェックサムを検証することである。チェックサムは、一般的に、秘密性が全くない状態で計算及び検証されるが、暗号署名の生成にはプライベート鍵が必要であり、署名の検証には、対応する公開鍵が必要である。
【０００４】
チェックサム方式の保護の一例として、Windows（登録商標）オペレーティングシステムで使用されるPortable Executable（ＰＥ）フォーマットのためのＣＲＣ３２がある。ＰＥヘッダがＣＲＣ３２フィールドを含み、このフィールドは、対応するコードセクションのチェックサムを与える。この保護を首尾よく回避するために、攻撃者は、まずコードセクションを変更し、次に、元のチェックサムを、変更されたコードセクションに対して計算された新しい値に置き換える。攻撃者が秘密性を全く必要とせずに、変更されたコードセクションのチェックサムを更新できるため、このタイプの攻撃が可能である。
【０００５】
チェックサムでは弱い場合、暗号署名が好ましいソリューションである。署名の生成はコードの公開前に行われ、プライベート鍵（従って秘密鍵）を使用する。関連付けられた公開鍵はコードに付加され、その後、コードのインストール時又は実行時にコード整合性をチェックするために使用される。この場合も攻撃者はコードを変更できるが、このコードの正しい署名はプライベート鍵がないと生成できないため、攻撃は失敗する。
【０００６】
ネイティブコードで配信されて実行されるアプリケーションの整合性をチェックするソリューションが多く存在し、例えば、Arxan社（GuardIT（商標））、Metaforic社（Metafortress（商標））などから提供されるソリューションが存在する。ネイティブコードは、プロセッサが直接実行できるアセンブラ命令セットである。この命令セットは、インストール後に変化しない。即ち、インストールの前後でプログラムの整合性値は同じままである（即ち、時間に対して一定である）。この場合、署名は、あらかじめ生成され、アプリケーションパッケージとともに配信され得る。
【０００７】
これに対し、インタプリタ型コード（例えば、Java（登録商標）で書かれたコード、Android（登録商標） DEXコードなど）の形式で配布されるアプリケーションは、実行前にインタプリタを通さなければならない中間命令を含む。ネイティブコードと異なり、インタプリタ型コードは、インストール時より後に最適化のために変更され得る。コード変更は、一般に、ターゲットプラットフォームに非常に依存するので、必ずしも予測可能ではない。コードが変更された場合、インタプリタ型コードに対して生成された署名は、コードの整合性及び信憑性を実行時に動的に確認するために使用することができない。
【０００８】
前述のAndroidオペレーティングシステムにアプリケーションソフトウェアを配布してインストールするために、ＡＰＫ  −  Androidアプリケーションパッケージ  −  と呼ばれるファイルフォーマットが使用される。ＡＰＫファイルを作成するには、まず、Android用プログラムを中間言語にコンパイルし、その各部分を圧縮アーカイブファイル（ＺＩＰフォーマット）にパッケージする。このアーカイブファイルは、単一ＤＥＸ（Dalvik（登録商標）実行可能コード）ファイル内の全プログラムコード、様々なリソース（例えば、イメージファイル）、及びＡＰＫファイルのマニフェストを含む。このアーカイブファイルは、２つの追加ファイルＣＥＲＴ．ＳＦ及びＣＥＲＴ．ＲＳＡを含む。ＣＥＲＴ．ＳＦは、他の全てのアーカイブファイルの暗号ハッシュを含み、ＣＥＲＴ．ＲＳＡは、署名の検証に使用される公開鍵を含む。ＣＥＲＴ．ＳＦのみがＲＳＡプライベート鍵によって署名される。ＣＥＲＴ．ＳＦのＲＳＡ署名は、インストール中のＡＰＫファイルの全内容の妥当性検査を可能にする。実際、ＣＥＲＴ．ＳＦファイル内で言及されている全てのファイルが間接的に署名されている。なぜなら、それらのハッシュがＣＥＲＴ．ＳＦに含まれているからである。インストール前にいずれかのファイルを変更すると、ファイルダイジェストがＣＥＲＴ．ＳＦファイル内のハッシュと一致しないことをソフトウェアが検出するので、エラーが発生することになる。或いは、ＣＥＲＴ．ＳＦファイル内の暗号ハッシュ値を変更することは、（既に述べたチェックサム方式の検証に対する攻撃の場合と同様に）署名の検証中のエラーにつながることになる。
【０００９】
ＤＥＸファイルヘッダは、ＤＥＸファイルの内容のグローバルチェックサムも含む。アプリケーションの最初の実行時に、Androidシステムはオプティマイザを使用する。オプティマイザは、実行の直前に、ＤＥＸインタプリタ型バイトコードを、ＯＤＥＸ（最適化ＤＥＸ）と呼ばれる最適化機械語命令シーケンスに変更する。オプティマイザはチェックサムの更新も行う。その後、ＯＤＥＸファイルは、後の使用のためにAndroidファイルシステム内の特定のリポジトリに格納される。その後、ＯＤＥＸファイルは、アプリケーションソフトウェアにとっての基準になり、これが存在する場合、元のＤＥＸファイルはもはや使用されない。
【００１０】
実行時、本システムは、ＯＤＥＸチェックサムを使用して、アプリケーションの整合性を検証することができる。しかしながら、この選択肢は、Androidオペレーティングシステムではデフォルトで設定されておらず、Dalvikマシンは、ＯＤＥＸコードを実行するために使用されているが、常にＯＤＥＸチェックサムを確認するわけではなく、これは、チェックサムの検証が実行のパフォーマンス及びブート時間に無視できない影響を有するためである。
【００１１】
Androidバージョン５．０以上では、Dalvikマシンに取って代わるAndroidランタイム（ＡＲＴ）が導入されている。アプリケーションは引き続きＤＥＸコードで配備されるが、ＤＥＸコードは、インストール時に事前（ＡＯＴ）コンパイル機能によりネイティブコードにコンパイルされる。先行ソリューションと同様に、ＤＥＸファイルに対するＡＯＴコンパイルの結果として、バイナリのExecutable Linkable Format（ＥＬＦ）のファイルが得られる（これは先行ソリューションにおけるＯＤＥＸに取って代わるものである）。アプリケーションのＤＥＸコードは、その後、いったんコンパイルされ、後にアプリケーションが実行されるたびにＥＬＦコードが起動される。ＡＲＴは、ネイティブコード（ＥＬＦコード）を直接実行するので、アプリケーションの実行を高速化し、全体の電力消費を改善する。
【００１２】
従って、Androidシステムでは、ＡＰＫ署名が検証されるのはインストール時のみであることがわかる。更に、信頼されないソースからのアプリケーションのインストールをユーザが許可すれば、中央機関の署名がないＡＰＫでもAndroidデバイスにインストールすることができる。従って、アプリケーション開発者は、いずれの信頼されている機関にもリンクしていない独自の自己署名証明書を使用する。その場合、Androidデバイスの所有者が知らないうちに、そのデバイス上で、改ざんされたアプリケーションの再署名及び再インストールが何らかのハッカーによって行われる可能性がある。
【００１３】
既に述べたように、Androidアプリケーションではインタプリタポータブルフォーマット（ＤＥＸ）を使用する。このポータブルフォーマットは、ＡＲＭ、ｘ８６、ＭＩＰＳ、リトル／ビッグエンディアンなどの様々なアーキテクチャ及び特性を有する大規模デバイス群において実行することができる。性能を向上させるために、ＤＥＸコードはインストール時又はアプリケーションの最初の使用時に変更されて、ターゲットデバイスに合わせて最適化されたＯＤＥＸ又はＥＬＦバイナリが生成される。最適化又はＯＡＴコンパイル中、コード内の様々なものが変更され得る。即ち、命令を他の命令で置き換えることができ、命令の並びを変更することができ、バイト順を入れ替えることができるなどである。
【００１４】
従って、最適化及びＯＡＴコンパイルは、セキュリティの問題を提起する。ＤＥＸファイルの署名は、依然としてＣＥＲＴ．ＳＦ及びＣＥＲＴ．ＲＳＡにより検証され得るが、これはＯＤＥＸファイル及びＥＬＦファイルに当てはまらず、なぜなら、これらが変更されており、その整合性がもはや元のＤＥＸ署名にリンクしていないためである。換言すると、整合性及び信憑性はインストール時にのみ検証することができ、実行時には不可能である。これは、攻撃者がＯＤＥＸ及びＥＬＦのコードを変更し、これに応じてヘッダ内のチェックサムを更新することが可能なためである。
【００１５】
従って、このシステムは少なくとも２種類の攻撃、即ち、リモート攻撃及びルート攻撃に対して脆弱である。リモート攻撃では、ダウンロードされた悪意のあるアプリケーションがその特権を高め、システムパーミッションを入手する。その後、その悪意のあるアプリケーションは、内部記憶装置のキャッシュリポジトリに格納されているＯＤＥＸファイル及びＥＬＦファイルを改ざんする可能性がある。ルート攻撃では、攻撃者はAndroidデバイスを手に入れる。これは、例えば、デバイスを盗むか、又は所有者がデバイスのセッションをロックせずにいなくなった時点でデバイスにアクセスすることによって行われる。攻撃者は、ＵＳＢリンクを介してデバイスの内部記憶装置からインストール済みアプリケーションを取り出し、そのアプリケーションを変更し、その後、変更したアプリケーションをプッシュして内部記憶装置に戻すことができる。ルート攻撃が成功するには、デバイスを「ルート化」しなければならない（即ち、デバイスのAndroidシステムを制御するために「ルートアクセス権」が必要である）。
【００１６】
従って、Androidアプリケーションのライフサイクル中、アプリケーション整合性の信頼が失われる可能性がある。Androidシステムにインストールされているアプリケーションを信頼することはできるが、実行中のアプリケーションを信頼することは必ずしもできない。
【００１７】
当然のことながら、インタプリタ型コードアプリケーションの整合性及び信憑性に関連する問題の少なくとも一部を克服するソリューションを有することが望ましい。本開示は、そのようなソリューションを提供する。
【発明の概要】
【００１８】
第１の態様では、本開示は、アプリケーションを処理するデバイスを提供する。本デバイスは、アプリケーションを受け取るように構成されたインタフェースと、アプリケーションと署名済みチェックサムとを記憶するように構成されたメモリと、処理装置であって、アプリケーションを変更して変更済みアプリケーションを取得することと、変更済みアプリケーションについて生成されたチェックサムを信頼されているエンティティに送ることと、送られたチェックサムに対応する署名済みチェックサムを信頼されているエンティティから受け取ることと、署名済みチェックサムをメモリに記憶することとを行うように構成された処理装置とを含む。
【００１９】
第１の態様の様々な実施形態は、以下を包含する。
【００２０】
アプリケーションは、第１のチェックサムとともに受け取られ、処理装置は、第１のチェックサムを使用してアプリケーションの整合性を検証するように更に構成されている。
【００２１】
処理装置は、署名済みチェックサムを使用して、変更済みアプリケーションの実行時に変更済みアプリケーションの整合性を検証するように構成されている。
【００２２】
アプリケーションは、インタプリタ型コード（ＤＥＸ）として実装され、及び変更済みアプリケーションは、最適化されたインタプリタ型コード（ＯＤＥＸ）として実装されるか、又は変更済みアプリケーションは、ネイティブコード（ＥＬＦ）としてコンパイルされる。有利には、処理装置は、インタプリタ型コード又は最適化されたインタプリタ型コードのヘッダにおいて、インタプリタ型コードのチェックサムを、署名済みチェックサムに置き換えるように構成されている。
【００２３】
本デバイスは、スマートフォン又はタブレットである。
【００２４】
信頼されているエンティティは、本デバイス内で実装される。有利には、信頼されているエンティティは、アプリケーションの少なくとも１つのチェックサムを記憶することと、変更済みアプリケーションのチェックサムがアプリケーションの記憶されているチェックサムと一致することを検証することと、署名鍵を使用して、変更済みアプリケーションのチェックサムに署名することとを行うように構成されている。署名鍵は、ソフトウェア保護技術を使用して保護されることが好ましい。
【００２５】
信頼されているエンティティは、独立したデバイスであり、インタフェースは、処理装置から変更済みアプリケーションのチェックサムを受け取り、変更済みアプリケーションのチェックサムを信頼されているエンティティに送ることと、信頼されているエンティティから署名済みチェックサムを受け取り、署名済みチェックサムを処理装置に送ることとを行うように更に構成されている。
【００２６】
処理装置は、変更済みアプリケーションのチェックサムと一緒に、アプリケーションのアクティベーションコードを送るように構成されている。
【００２７】
処理装置は、署名済みチェックサムを署名証明書と一緒に受け取るように構成されている。
【００２８】
第２の態様では、本開示は、アプリケーションを処理する方法を提供する。デバイスが、アプリケーションを受け取り、アプリケーションを変更して変更済みアプリケーションを取得し、変更済みアプリケーションについて生成されたチェックサムを信頼されているエンティティに送り、送られたチェックサムに対応する署名済みチェックサムを信頼されているエンティティから受け取り、署名済みチェックサムをメモリに記憶する。
【図面の簡単な説明】
【００２９】
以下では、次に示す添付図面を参照しながら、本開示の好ましい特徴を非限定的な実施例として説明する。
【００３０】
【図１】本開示が実施される一例示的システムを示す。
【図２】本開示の好ましい一実施形態による方法の好ましい一実施形態を示す。
【発明を実施するための形態】
【００３１】
図１は、本開示が実施される一例示的システムを示す。本システムは、デバイス１１０と、アプリケーションプロバイダ（アプリケーションストア）１２０と、信頼されているエンティティ１３０とを含む。デバイス１１０は、Android OSが動作する任意の種類の適切なデバイス、例えば、スマートフォン又はタブレットであってよく、これは、少なくとも１つのハードウェア処理装置（「プロセッサ」）１１１と、メモリ１１２と、ユーザと対話するユーザインタフェース１１３と、インターネットなどの接続１４０を介してアプリケーションプロバイダ１２０及び信頼されているエンティティ１３０と通信する通信インタフェース１１４とを含む。当業者であれば理解されるように、図示されているデバイスは明確さのために非常に簡略化されており、実際のデバイスは、電源及び永続記憶装置などの機能を更に含むであろう。
【００３２】
アプリケーションプロバイダ１２０は、デバイス１１０がダウンロードできる少なくとも１つのアプリケーションＡＰＫファイル１２２を備える。アプリケーションプロバイダ１２０は、また、アプリケーションＤＥＸファイルに対応する様々なＯＤＥＸファイル又はＥＬＦファイルのチェックサムを生成するように構成されたハードウェアプロセッサ１２４を含む。これらのチェックサムは、様々な検査デバイス又は基準デバイスにＤＥＸファイルをインストールし、結果として得られるＯＤＥＸファイル又はＥＬＦファイルからチェックサムを計算することにより生成され得る。アプリケーションプロバイダ１２０は、また、アプリケーションＤＥＸファイルに対応する様々なＯＤＥＸファイル又はＥＬＦファイルのチェックサムを、信頼されているエンティティ１３０に送るように構成されている。
【００３３】
信頼されているエンティティ１３０は、Android OSの内部に又は独立したデバイス上で実装されてよい。信頼されているエンティティ１３０は、アプリケーションのＯＤＥＸチェックサム又はＥＬＦチェックサムを記憶するメモリと、デバイス１１０上のAndroid OSからＯＤＥＸチェックサム又はＥＬＦチェックサムを受け取るためのインタフェースと、アプリケーションの受け取られたＯＤＥＸチェックサム又はＥＬＦチェックサムがそのアプリケーションの記憶されているＯＤＥＸチェックサム又はＥＬＦチェックサムと一致することを検証する処理装置と、ＯＤＥＸチェックサム又はＥＬＦチェックサムに署名するために使用されるプライベート署名鍵１３２と、署名済みのＯＤＥＸチェックサム又はＥＬＦチェックサムをデバイス１１０に送るためのインタフェースとを含む。信頼されているエンティティ１３０がAndroid OSの内部で実装される場合、プライベート署名鍵は、コード難読化及びホワイトボックス暗号化などのソフトウェア保護技術を使用して、又は鍵ストア若しくは暗号化エンジンなどの専用ハードウェアを使用して保護されることが好ましい。
【００３４】
図２は、好ましい一実施形態による方法のフローチャートを示す。ステップＳ２０２において、アプリケーションプロバイダ１２０は、Androidデバイスに提供するアプリケーションの複数のＯＤＥＸチェックサム又はＥＬＦチェックサムを信頼されているエンティティ１３０に送る。ステップＳ２０４において、デバイス１１０は、そのアプリケーションのＡＰＫファイルをダウンロードしてインストールする。既に述べたように、デバイス１１０は、インストール中、ＡＰＫファイル内のＤＥＸを最適化又はＯＡＴコンパイルし、ＯＤＥＸ又はＥＬＦを取得し、ＯＤＥＸコード又はＥＬＦコードのチェックサムをＤＥＸヘッダに追加する。なお、ＣＥＲＴ．ＳＦファイル内のハッシュにより、デバイス１１０がＤＥＸの整合性を検証することを可能にする。
【００３５】
アプリケーションが最初に実行される際、ソース取得モジュールは、ＯＤＥＸファイル又はＥＬＦファイルの内容をメモリ１１２に読み込み、ステップＳ２０６において、ＯＤＥＸチェックサム（ＣＳ）又はＥＬＦ  ＣＳをＤＥＸヘッダから読み出して、信頼されているエンティティ１３０に送信する。ＯＤＥＸチェックサム又はＥＬＦチェックサムは、セキュア認証チャネルのような保護された接続により送られることが好ましい。ソース取得モジュールは、アプリケーションのネイティブライブラリに含まれる（Androidアプリケーションの一部は、Java以外のコード、例えば、Ｃ／Ｃ＋＋などの言語を使用して開発され得る）。Javaネイティブインタフェース（ＪＮＩ）は、Dalvikマシンで動作しているJAVAコードがアプリケーションとともに配信されたネイティブライブラリを呼び出すことを可能にする。
【００３６】
アプリケーションがアクティベーションコードの入力を必要とする場合、チェックサムは、アクティベーションコードと一緒に、リモートの信頼されているエンティティ１３０に送られ得る。
【００３７】
信頼されているエンティティ１３０は、ステップＳ２０８において、受け取られたＯＤＥＸチェックサム又はＥＬＦチェックサムがアプリケーションの記憶されているＯＤＥＸチェックサム又はＥＬＦチェックサムの一方と一致することを確認することが好ましい。この場合、信頼されているエンティティ１３０は、ステップＳ２１０において、受け取られたＯＤＥＸチェックサム又はＥＬＦチェックサムに、プライベート署名鍵を使用して署名し、ステップＳ２１２において、署名したＯＤＥＸチェックサム又はＥＬＦチェックサムをデバイス１１０に返す。信頼されているエンティティ１３０は、また、対応する公開鍵を含む署名証明書を署名済みのＯＤＥＸチェックサム又はＥＬＦチェックサムとともに送ることができる。
【００３８】
ステップＳ２１４において、ソース取得モジュールは、署名済みのＯＤＥＸチェックサム又はＥＬＦチェックサムを受け取って記憶する（及び利用可能で必要であれば、署名証明書を受け取って記憶する）。
【００３９】
アプリケーション又はAndroid OSは、プライベート署名鍵に対応する公開鍵へのアクセスを有し、ステップＳ２１６において、ＯＤＥＸ又はＥＬＦのチェックサムを計算し、これを署名済みのＯＤＥＸチェックサム又はＥＬＦチェックサムと比較することにより、ＯＤＥＸ又はＥＬＦの整合性を確認することができる。デバイスにインストールされている信頼されているルート証明書を使用することにより、又は最終的に信頼されているルート証明書につながる証明書チェーンを使用することにより、署名証明書の整合性を検証することもできる。
【００４０】
その後のアプリケーションの実行時、又はアプリケーションの現在の実行中の任意の時点において、アプリケーションの整合性をステップＳ２１６と同様に、即ち、ＯＤＥＸ又はＥＬＦのチェックサムを計算し、これを署名済みのＯＤＥＸチェックサム又はＥＬＦチェックサムと比較することにより検証することができる。この目的に向けて、有利には、Androidオペレーティングシステム内にＯＤＥＸ又はＥＬＦの整合性を確認する選択肢が設定されている。
【００４１】
なお、このソリューションは、現在配備されているAndroidシステムと互換であり、それは、実行時の整合性検証に必要なコードが既存のAndroid OSの一部分であるか、又は配信されたアプリケーション用ＡＰＫパッケージの一部分であるためである。
【００４２】
本明細書では、「チェックサム」という用語は、チェックサムが生成されたデータがチェックサムの生成後に変更されたかどうかの検証を可能にする値を包含することを意図されている。従って、チェックサムは、例えば、ハッシュ値、巡回冗長検査（ＣＲＣ）値、又は他の種類のダイジェストであってもよく、チェックサムからコードを取り出すことが計算では不可能であることが好ましい。更に、明確さのために単一のチェックサムを使用したが、複数のチェックサムを使用してもよく、コードの別個の部分についてチェックサムを生成してよく（これらの別個の部分は一部が重なり合ってよい）、コードの複数の別個の部分についての複数のチェックサムを使用して、比較用の単一のグローバルチェックサムが生成される。署名は、任意の適切な暗号署名であってよく、例えば、ＨＭＡＣ（ハッシュ方式のメッセージ認証コード）であってよく、又は例えば、ＲＳＡ、ＤＳＡ（デジタル署名アルゴリズム）、若しくはＥＣＤＳＡ（楕円曲線デジタル署名アルゴリズム）に基づく署名であってよい。
【００４３】
当然のことながら、本ソリューションは、リモート攻撃に問題なく対処することができる。
【００４４】
受け取られたＯＤＥＸチェックサム又はＥＬＦチェックサムが「正当な」コードに対応することを信頼されているエンティティが確認すれば、ルート攻撃にも対処することができる。これは、受け取られたＯＤＥＸチェックサムが、変更されたコードを含むＡＰＫのチェックサム（これは、アプリケーションプロバイダからダウンロードされたコードを攻撃者が変更した場合にはあり得る）ではないことを検証することである。この理由により、アプリケーションプロバイダ１２０が、可能なＯＤＥＸチェックサム又はＥＬＦチェックサムを信頼されているエンティティ１３０に送ることが好ましく、変形形態では、信頼されているエンティティ１３０が、アプリケーションのＤＥＸコードを所与のターゲットデバイスに合うようにＯＡＴコンパイル又は最適化することにより、様々なＯＤＥＸチェックサム又はＥＬＦチェックサムを生成する。なお、潜在的なチェックサムの数は、ある限られたデバイスハードウェアパラメータのセット（ＣＰＵエンディアンネス、ＣＰＵ対称型マルチプロセッシング（ＳＭＰ）モードなど）に依存し、従って、パラメータの組み合わせの数は限られる。例えば、ＤＥＸ最適化に関しては、Nexus 7とサムスンギャラクシータブＰ５１００との間でＳＭＰモードのみが異なる。
【００４５】
ここまで本ソリューションをAndroid環境に関して説明してきたが、本ソリューションは、インストール時にコードを変更し、インストールされたアプリケーションの安全な整合性検証を実行時に可能にしない他のオペレーティングシステムにも適応され得る。
【００４６】
従って、当然のことながら、本開示は、Androidデバイス上でのアプリケーションの実行時整合性を有効にすることができるソリューションを提供する。
【００４７】
本明細書並びに（該当する場合には）特許請求の範囲及び図面に開示される各特徴は、単独で又は何らかの適切な組み合わせで提供されてよい。ハードウェアで実施されるように説明された特徴がソフトウェアで実施されてもよく、その逆であってもよい。請求項中に記載される参照符号は例示に過ぎず、請求項の範囲を限定する効果を有するものではない。
【図１】
2018503157.tif 000003
【図２】
2018503157.tif 000004
【国際調査報告】
2018503157.tif 000005
2018503157.tif 000006