JP5126447B1 - アプリケーションプログラムの実行方法 - Google Patents

アプリケーションプログラムの実行方法 Download PDF

Info

Publication number
JP5126447B1
JP5126447B1 JP2012190943A JP2012190943A JP5126447B1 JP 5126447 B1 JP5126447 B1 JP 5126447B1 JP 2012190943 A JP2012190943 A JP 2012190943A JP 2012190943 A JP2012190943 A JP 2012190943A JP 5126447 B1 JP5126447 B1 JP 5126447B1
Authority
JP
Japan
Prior art keywords
program
application program
application
information
stage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2012190943A
Other languages
English (en)
Other versions
JP2014048866A (ja
Inventor
亮彦 吉田
義博 矢野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dai Nippon Printing Co Ltd
Original Assignee
Dai Nippon Printing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dai Nippon Printing Co Ltd filed Critical Dai Nippon Printing Co Ltd
Priority to JP2012190943A priority Critical patent/JP5126447B1/ja
Application granted granted Critical
Publication of JP5126447B1 publication Critical patent/JP5126447B1/ja
Priority to PCT/JP2013/062311 priority patent/WO2013161974A1/ja
Publication of JP2014048866A publication Critical patent/JP2014048866A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Stored Programmes (AREA)

Abstract

【課題】アプリケーションプログラムの改竄の有無を判定し、改竄のないアプリを実行許可リストに自動登録する。
【解決手段】アプリの起動指示を受けて、ＯＳによる署名情報の正当性確認（Ｓ７）を行い、更に、当該アプリ自身により、この署名情報に基づいて作成された秘匿情報の正当性確認（Ｓ９）を行う。双方で正当性確認がなされたら、改竄なしと判定し、当該アプリの識別コードを実行許可リストに自動登録（Ｓ１４）した上で、当該アプリの実行を続行する（Ｓ１２）。改竄ありと判定された場合は、当該アプリの実行を中止する（Ｓ１１）。ＯＳのマルチタスク処理により、アプリとは別個の監視プログラムを並列動作させ、リストに登録されていないアプリが起動していた場合には、登録するか否かをユーザに回答させる。登録する旨の回答があれば当該アプリを登録し、登録しない旨の回答があれば、当該アプリの実行を中止する。
【選択図】図２２

Description

本発明は、アプリケーションプログラムの実行方法に関し、特に、アプリケーションプログラムの改竄を検知する処理を行った上で、これを実行する技術に関する。
ここ数年来、電子機器は、パソコン、スマートホン、電子タブレット等と様々な形態のものが普及してきており、これら様々な電子機器において多様なアプリケーションプログラムが利用されている。このため、実社会で利用されているアプリケーションプログラムの数は膨大な数にのぼり、今後も急激な勢いでその数を増してゆくものと予想される。一方、アプリケーションプログラムの配布形態も、光学的記録媒体やＩＣメモリに格納して提供する形態や、インターネットなどを介してオンラインでデータファイルのみを送信する形態が普及しており、一般ユーザは、様々なルートで入手した様々なアプリケーションプログラムを電子機器にインストールして利用することができる。
このように、膨大な数のアプリケーションプログラムが様々な配布形態で提供されている現状では、配布途中のアプリケーションプログラムは、悪意をもったクラッカーによる改竄の標的になりやすい。たとえば、クラッカーは、インターネット経由で任意のアプリケーションプログラムを入手することが可能であり、入手したアプリケーションプログラムに対して改竄を施した後、これを再びインターネット経由あるいは様々な記録媒体に格納して再配布することができる。
一般ユーザにとって、実社会に配布されているアプリケーションプログラムが、正規のプロバイダーから提供された純正のものであるのか、クラッカーによる改竄が施されたものであるのかを見分けることは困難である。特に、改竄されたアプリケーションプログラムが、正規のアプリケーションプログラムと同じファイル名をもつファイルとして配布されていると、一般ユーザが両者を区別することは非常に困難であり、両者を混同せざるを得ない。
改竄されたアプリケーションプログラムを実行することによって受ける被害は、改竄の内容によって様々である。たとえば、ウイルスを混入させる改竄が行われた場合には、ユーザの電子機器内のファイルが破壊されたり、個人情報が外部へ漏洩されたり、重大な被害が生じることになる。一方、画像データや文字データを差し替えるような改竄が行われた場合、ウイルスほどの被害は生じないにしても、提示される情報が本来のものではなくなってしまうため、ユーザに混乱を生じさせることになる。
しかも、このような改竄されたアプリケーションプログラムの流布による被害は、一般ユーザだけではなく、コンテンツプロバイダにまで及ぶことになる。たとえば、コンテンツプロバイダであるＡ社が配布した正規のアプリケーションプログラムが、クラッカーによる改竄を受け、改竄されたアプリケーションプログラムが、あたかもＡ社の正規の製品であるかのようにして再配布された場合を考えてみよう。この場合、改竄されたアプリケーションプログラムをインストールしたユーザが、当該プログラムをＡ社から提供された正規の製品であると信じて実行したとすれば、Ａ社は不当な評価を受けることになる。たとえば、改竄によってプログラムの動作に不具合が生じたり、公序良俗に反するような内容が表示されたりすれば、Ａ社の製品に対するユーザの評価は低下することになり、Ａ社は風評被害を受けることになる。
このように、コンテンツプロバイダがアプリケーションプログラムを配布し、一般ユーザの電子機器にインストールして実行してもらう上では、クラッカーによる改竄を防止することが不可欠である。通常、デジタルデータの改竄を防止するためには、電子署名の技術が利用されている。たとえば、下記の特許文献１には、携帯電話のメモリ内のデータに電子署名を施し、これをチェックすることにより改竄の有無を検出するシステムが開示されている。また、特許文献２には、情報処理装置内のアプリケーションプログラムの改竄の有無を、電子署名やハッシュ値を利用して監視するシステムが開示されている。
一方、下記の特許文献３および特許文献４には、予め実行対象となるアプリケーションプログラムを登録しておき、未登録のプログラムについては実行を許可しない処理を行う技術が開示されている。この技術を利用すれば、改竄のおそれがない安全なアプリケーションプログラムと判断できるもののみを予め登録しておくようにし、改竄のおそれがあるアプリケーションプログラムの実行を抑制することができるようになる。
特開２００７−２９３８４７号公報 国際公開第ＷＯ２００８−０４７８３０号公報 特開２００２−３０４３１８号公報 特開２００５−１５７４２９号公報
上述したとおり、デジタルデータの改竄を防止するために、当該デジタルデータに対して電子署名を施すことは様々な産業分野で利用されており、前掲の特許文献１，２にも記載されているように、電子機器に配布するアプリケーションプログラムに対する改竄防止にも利用されている。たとえば、Android（登録商標）をＯＳとして採用するスマートホンの場合、インストールするアプリケーションプログラムには、必ず電子署名が付加されていることが仕様によって定められており、電子署名が付加されていないアプリケーションプログラムや、付加されている電子署名に不整合が生じているアプリケーションプログラムは、ＯＳによって不正なプログラムと判断され、実行が許可されない。
しかしながら、電子署名は、あくまでも署名対象データの内容を署名者が保証するものであり、署名者の身元まで保証するものではない。このため、クラッカーは、アプリケーションプログラムの内容を改竄した後、改竄後のアプリケーションプログラムを署名対象データとして自分自身を署名者とする電子署名を新たに行い、この新たな電子署名を付加して改竄後のアプリケーションプログラムを再配布することが可能である。このように、電子署名に対する改竄が行われた場合、上述したAndroid（登録商標）をＯＳとして利用している端末装置などでは、有効な改竄検知を行うことができない。
一方、前掲の特許文献３，４に記載されているように、予め登録されているアプリケーションプログラムだけについて、その実行を許可するような運用を行った場合、適切な登録作業が行われている限り、改竄されたプログラムの実行を阻止することができる。しかしながら、実際には、配布を受けたプログラムが改竄されたものであるか否かをユーザが正しく判断することは困難であり、また、仮に改竄されていないプログラムであることが判明した場合でも、ユーザがこれを個別に登録する作業を行う必要があるため、ユーザに煩雑な作業負担を課す結果になる。
そこで本発明は、電子署名に対する改竄が行われた場合にも、有効な改竄検知を行うことができ、更に、改竄なしと判定されたアプリケーションプログラムについては、ユーザに登録作業の負担を課すことなしに、実行許可リストへの自動登録が行われるアプリケーションプログラムの実行方法を提供することを目的とする。
(1) 本発明の第１の態様は、コンピュータが、アプリケーションプログラムを実行するアプリケーションプログラムの実行方法において、
コンピュータが、実行対象となるアプリケーションプログラムを含むデータファイルを入力する入力段階と、
コンピュータが、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
コンピュータが、改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録するリスト自動登録段階と、
コンピュータが、起動状態にあるアプリケーションプログラムの識別コードを認識する起動アプリ認識段階と、
コンピュータが、起動アプリ認識段階において認識した識別コードが実行許可リストに登録されているか否かを判定する登録有無判定段階と、
コンピュータが、登録有無判定段階において未登録と判定された場合に、当該未登録アプリを登録するか否かをユーザに問い合わせる登録照会段階と、
コンピュータが、問い合わせに対するユーザの回答として、登録する旨の回答があった場合には、未登録アプリの識別コードを実行許可リストに登録した上で当該アプリの実行を許可し、登録しない旨の回答があった場合には、当該未登録アプリの実行を中止させる回答処理段階と、
を行い、
入力段階では、改竄チェック機能付アプリケーションプログラムと、署名情報と、秘匿情報もしくはその所在を示す所在情報と、を含むデータファイルを入力し、
署名情報は、アプリケーションプログラムを署名対象データとする電子署名処理によって得られた情報であり、
秘匿情報は、改竄チェック機能付アプリケーションプログラムおよび署名情報を構成するデータの中の所定部分を秘匿化対象データとして抽出し、抽出した秘匿化対象データに対する秘匿化処理を施して得られた情報であり、
改竄判定段階は、署名情報に基づいて改竄の有無を確認する第１の確認段階と、秘匿情報に基づいて改竄の有無を確認する第２の確認段階と、を有し、
改竄チェック機能付アプリケーションプログラムには、秘匿化処理で行われた処理プロセスを勘案して秘匿化対象データに対する秘匿情報の正当性を確認する改竄チェックルーチンが含まれており、改竄チェックルーチンを実行することにより第２の確認段階が行われるようにしたものである。
(2) 本発明の第２の態様は、上述した第１の態様に係るアプリケーションプログラムの実行方法において、
一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
秘匿情報が、秘匿化対象データを一方の鍵を用いて暗号化することにより得られた情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報を他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイルから抽出した秘匿化対象データとが一致していた場合に改竄なしとの確認を行うようにしたものである。
(3) 本発明の第３の態様は、上述した第１の態様に係るアプリケーションプログラムの実行方法において、
秘匿情報が、秘匿化対象データに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して作成された情報であり、
改竄チェックルーチンが、入力段階で入力したデータファイルから抽出した秘匿化対象データに対して、特定鍵を用いたダイジェスト化処理を施して得られる情報が、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報と一致していた場合に改竄なしとの確認を行うようにしたものである。
(4) 本発明の第４の態様は、上述した第１〜第３の態様に係るアプリケーションプログラムの実行方法において、
ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータが、第１の確認段階をＯＳプログラムに基づいて実行し、第２の確認段階をアプリケーションプログラム内の改竄チェックルーチンに基づいて実行するようにしたものである。
(5) 本発明の第５の態様は、上述した第４の態様に係るアプリケーションプログラムの実行方法において、
ＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有しており、
コンピュータが、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行するようにしたものである。
(6) 本発明の第６の態様は、上述した第５の態様に係るアプリケーションプログラムの実行方法において、
コンピュータが、ＯＳプログラムによって、個々のアプリケーションプログラムについて、識別コード・起動時・終了時を示すログ情報を記録する処理を実行し、
コンピュータが、監視プログラムによって起動アプリ認識段階を実行する際に、ログ情報を参照することにより起動状態にあるアプリケーションプログラムの識別コードを認識するようにしたものである。
(7) 本発明の第７の態様は、上述した第１〜第６の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別コードを用いた処理を行うようにしたものである。
(8) 本発明の第８の態様は、上述した第７の態様に係るアプリケーションプログラムの実行方法において、
同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識するようにしたものである。
(9) 本発明の第９の態様は、上述した第１〜第８の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが外部の記憶装置もしくはサーバ装置内に保存された実行許可リストに対する登録を行い、
登録有無判定段階で、コンピュータが外部の記憶装置もしくはサーバ装置内に保存された実行許可リストを参照することにより判定を行うようにしたものである。
(10) 本発明の第１０の態様は、上述した第１〜第９の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが実行許可リストを暗号化する処理を行い、
登録有無判定段階で、コンピュータが暗号化されている実行許可リストを復号して内容の参照を行うようにしたものである。
(11) 本発明の第１１の態様は、上述した第１〜第１０の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが、識別コードとともに、入力段階で入力したデータファイル内に含まれている所定のチェックコードを登録するようにし、
登録有無判定段階で、コンピュータが、データファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにしたものである。
(12) 本発明の第１２の態様は、上述した第１〜第１０の態様に係るアプリケーションプログラムの実行方法において、
リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが、識別コードとともに、入力段階で入力したデータファイル内に含まれている所定の情報に対して一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードを登録するようにし、
登録有無判定段階で、コンピュータが、データファイル内に含まれている上記所定の情報に対して上記一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにしたものである。
(13) 本発明の第１３の態様は、上述した第５または第６の態様に係るアプリケーションプログラムの実行方法に用いる監視プログラムを独立して配布するようにしたものである。
本発明に係るアプリケーションプログラムの実行方法では、アプリケーションプログラムは、署名情報と、秘匿情報もしくはその所在を示す所在情報と、を含むデータファイルとして入力され、署名情報の正当性だけでなく、秘匿情報の正当性の確認も行われる。このため、アプリケーションパッケージ自体の改竄だけでなく、署名情報の改竄も検知することができるようになり、電子署名に対する改竄が行われた場合にも、有効な改竄検知が可能になる。しかも、アプリケーションプログラムに、自分自身が改竄されているか否かを判定する改竄チェックルーチンが含まれているため、当該アプリケーションプログラムを実行することにより、改竄の検知が可能になる。また、改竄されていない旨の判定がなされた場合には、実行許可リストへの自動登録が行われるため、ユーザが登録作業を行う必要はなくなる。
署名情報を付加した従来の一般的なアプリケーションプログラムの配布方法を示すブロック図である。 図１に示す配布用ファイル２０の具体的な作成方法を示すブロック図である。 図２に示す配布用ファイル２０について、署名情報２２の正当性を確認する処理を示すブロック図である。 図１に示す従来の配布方法に対してクラッカーＸが試みる改竄プロセスを示すブロック図である。 本発明に係るアプリケーションプログラムの配布方法の基本原理を示すブロック図である。 図５に示す配布用ファイル２０Ａについて、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を示すブロック図である。 本発明に係るアプリケーションプログラムの配布実行方法の基本手順を示す流れ図である。 図５に示す本発明に係る配布方法に対してクラッカーＸが試みる改竄プロセスを示すブロック図である。 図５に示す本発明の基本的な実施形態に係る配布方法のバリエーションを示すブロック図である。 図５に示す本発明の基本的な実施形態に係る配布方法の別なバリエーションを示すブロック図である。 図５に示す本発明に係る配布方法において、秘匿情報２３Ａとして暗号化された情報を用いる具体的実施例を示すブロック図である。 図１１に示す配布用ファイル２０Ａについて、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を示すブロック図である。 図５に示す本発明に係る配布方法において、秘匿情報２３Ａとしてダイジェスト化された情報を用いる具体的実施例を示すブロック図である。 図１３に示す配布用ファイル２０Ａについて、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を示すブロック図である。 本発明に係るアプリケーションプログラムの配布用ファイル作成装置の基本構成を示すブロック図である。 本発明に係るアプリケーションプログラムの配布実行方法の変形例を示すブロック図である。 本発明に係るアプリケーションプログラムの実行方法で利用される監視プログラムの監視ルーチンの手順を示す流れ図である。 図１７に示す起動アプリ認識段階Ｓ２１で起動アプリの認識に利用されるログ情報の一例を示す図である。 本発明に係るアプリケーションプログラムの実行方法で利用される実行許可リストの一例を示す図である。 図１７に示す登録照会段階Ｓ２４でユーザに提示されるメッセージ画面の一例を示す図である。 自己改竄チェック機能をもたない通常アプリを起動したときの処理手順を示す流れ図である。 自己改竄チェック機能をもつアプリを起動したときの処理手順を示す流れ図である。
以下、本発明を図示する実施形態に基づいて説明する。なお、本発明に係るアプリケーションプログラムの実行方法は、特願２０１２−０９９１３９号（平成２４年４月２４日出願、早期審査に基づき平成２４年６月２８日特許査定）に記載された発明（以下、先願発明という）に係るアプリケーションプログラムの配布実行方法および改竄検知方法を利用することを前提としている。そこで、以下、§１〜§８において、先願発明に係るアプリケーションプログラムの配布実行方法および改竄検知方法を説明し、§９および§１０において、これを利用した本発明に係るアプリケーションプログラムの実行方法を説明することにする。§１〜§８に記載した実施形態は、先願の§１〜§８に記載した実施形態と同一である。
＜＜＜ §１．署名情報を付加する一般的な配布方法 ＞＞＞
ここでは、説明の便宜上、署名情報を付加した従来の一般的なアプリケーションプログラムの配布方法を簡単に説明しておく。図１は、このような従来の配布方法を示すブロック図である。ここでは、具体的な例として、Android（登録商標）をＯＳとして採用するスマートホンやタブレット型電子機器（いわゆる、Android端末）に対して、アプリケーションプログラムを配布する場合を例にとって説明する。
Android端末用のアプリケーションプログラムのデータ構造およびその配布形態については、世界的な標準仕様が定められており、一般的なアプリケーションプログラムは、いずれもこの標準仕様に基づいて作成され、配布されることになる。
具体的には、プログラム提供者Ａ（コンテンツプロバイダー）は、まず、図１の上段に示すようなデータ構造を有するアプリケーションプログラム１０を作成する。Androidの標準仕様では、アプリケーションプログラム１０は、基本的には、図示のとおり、プログラム本体部１１，リソースデータ１２，サブルーチン群１３，補助ファイル１４によって構成され、場合によっては、この他にもいくつかのファイルが付加されたり、いくつかが省略されたりする（たとえば、プログラム本体部１１がサブルーチンを利用しないケースでは、サブルーチン群１３は不要である）。
ここで、プログラム本体部１１はJava（登録商標）で記述されたプログラムのコンパイル後のファイルであり、アプリケーションプログラムの中枢を構成する要素になる。アプリケーションプログラム１０が起動されると、このプログラム本体部１１の先頭から命令コードが順次実行されることになる。
リソースデータ１２は、プログラム本体部１１が必要に応じて利用する画像や文字列のデータ群である。画像データは、JPEG形式、GIF形式、BMP形式、PNG形式など、様々なフォーマットで記述されたデータファイルとして用意され、文字列データも同様に、XML形式など、様々なフォーマットで記述されたデータファイルとして用意される。
一方、サブルーチン群１３は、「Shared Object」と呼ばれている汎用のサブルーチンプログラム群から構成される。個々のサブルーチンは、プログラム本体部１１からのサブルーチンコール命令によって呼び出され、それぞれの役割に応じた所定の処理を実行する。呼び出されたサブルーチンプログラムがその任務を完了すると、制御は再びプログラム本体部１１内のプログラムに戻ることになる。プログラム本体部１１は、サブルーチンコールを行う際に、必要に応じて何らかのデータを引数としてサブルーチンへ引き渡すことができ、各サブルーチンプログラムは、必要に応じて、その実行結果をプログラム本体部１１へ引き渡すことができる。
補助ファイル１４は、一般に「マニフェスト」と呼ばれている補助的な情報を記述したXML形式のファイルである。ここには、Android端末で当該アプリケーションプログラムを実行する際のパーミッション情報（たとえば、当該プログラムが、インターネット接続を行うか否か、GPS情報を参照するか否か、電話機能を利用するか否か、といった情報）などが記録される。このパーミッション情報は、当該アプリケーションプログラムのインストール時や起動時にユーザに提示され、ユーザがこれに納得する旨の確認入力を行った場合に限り、インストールや起動が行われることになる。
以上、Android端末用アプリケーションプログラム１０の基本データ構造を説明したが、アプリケーションプログラム１０は、このままの状態では配布することができない。Androidの標準仕様によると、このアプリケーションプログラム１０を配布する際には、パッケージ化処理および署名情報付加処理が必要である。
パッケージ化処理は、主に、アプリケーションプログラム１０を構成する個々のファイルを圧縮して１つのパッケージにまとめる処理であり（その他、中間コンパイル処理なども併せて行われる）、図１の中段に示すように、このパッケージ化処理を施すことにより、アプリケーションプログラム１０は、１つのアプリケーションパッケージ２１にまとめられる。圧縮プロセスを経ることにより、アプリケーションパッケージ２１のデータ容量は元のアプリケーションプログラム１０の容量に比べて削減され、配布に適した形になる。
一方、署名情報付加処理は、このアプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａが自己の署名を施す処理であり、この処理によって、Ａの署名情報２２が作成される。具体的には、公開鍵暗号方式を利用した電子署名処理が採用されており、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いて、署名対象データＤ（すなわち、アプリケーションパッケージ２１）に対する署名値Ｓ（Ａ）を作成する処理が行われ、作成された署名値Ｓ（Ａ）と、プログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含むＡの署名情報２２が作成される。図１において太線で囲って示す部分は、署名対象データＤとなる部分を示しており、署名情報２２は、この太線枠内のデータに対して、プログラム提供者Ａが署名したことを示す情報ということになる。
ここで、第１の鍵Ｋ（ａ１）と第２の鍵Ｋ（ａ２）とは、公開鍵暗号方式における秘密鍵と公開鍵との関係を有するデジタルデータであり、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもっている。通常、第１の鍵Ｋ（ａ１）として秘密鍵が、第２の鍵Ｋ（ａ２）として公開鍵が、それぞれ用いられ、Androidの標準仕様上では、前者を秘密にし、後者を公開する取り決めになっているが、本願では、単に、第１の鍵Ｋ（ａ１），第２の鍵Ｋ（ａ２）と呼ぶことにする。
こうして作成されたＡの署名情報２２は、署名対象となるアプリケーションパッケージ２１について、プログラム提供者Ａがその内容を保証するための情報であり、万一、アプリケーションパッケージ２１の内容が改竄されていた場合には、後述するように、Ａの署名情報２２との間に不整合が生じることになるので、このＡの署名情報２２を利用した改竄検知が可能になる。
配布用ファイル２０は、アプリケーションパッケージ２１にＡの署名情報２２を付加することによって構成されるファイルである。プログラム提供者Ａは、アプリケーションプログラム１０に対して、上述したパッケージ化処理および署名情報付加処理を施して配布用ファイル２０を作成し、インターネット等を介して多数のユーザＵ１，Ｕ２，Ｕ３へと配布することになる。もちろん、光学的記録媒体やＩＣメモリ等に格納した状態で配布することも可能である。
Androidの仕様では、このようなデータ構造を有する配布用ファイル２０は、ＡＰＫファイルと呼ばれており、Android端末に配布するアプリケーションプログラムは、すべてこのＡＰＫファイルの形式で配布する必要がある。別言すれば、Androidの仕様では、配布するすべてのアプリケーションプログラムに署名情報を付加することが義務づけられており、Android端末では、配布されたＡＰＫファイルを実行する際に、署名情報に基づく改竄検知が行われることになる。
図２は、図１に示す配布用ファイル２０の具体的な作成方法、特に、署名情報２２の具体的な作成方法を示すブロック図である。署名情報付加処理では、まず、署名対象データＤ（すなわち、アプリケーションパッケージ２１）に対してハッシュ関数ＨＡＳＨを作用させた不可逆変換が行われ、ハッシュ値Ｈ＝ＨＡＳＨ（Ｄ）が求められる。ハッシュ関数は代表的な一方向性関数であり、もとのデータＤに対しては常に一義的なハッシュ値Ｈが得られるが、逆に、ハッシュ値ＨからはもとのデータＤを復元することはできない性質をもっている。このため、ハッシュ値Ｈは、もとのデータＤ（図示の例の場合は、アプリケーションパッケージ２１を構成する全データ）に比べてデータ容量を極めて小さくできる。
次に、このハッシュ値Ｈを、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた公開鍵暗号方式の暗号化アルゴリズムを用いて暗号化し、署名値Ｓ（Ａ）を求める。すなわち、署名値Ｓ（Ａ）は、ハッシュ値Ｈを暗号化したデータであり、プログラム提供者Ａの第２の鍵Ｋ（ａ２）を用いた復号を行うことにより、元のハッシュ値Ｈが得られることになる。結局、アプリケーションパッケージ２１を署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とによって、Ａの署名情報２２が作成されることになる。
前述したとおり、配布用ファイル（ＡＰＫファイル）２０は、アプリケーションパッケージ２１にＡの署名情報２２を付加したファイルであり、Android端末に対しては、このような形式をもったファイルとして、アプリケーションプログラム１０が配布されることになる。ここでは、便宜上、この配布用ファイル２０が「PatGame.apk」なるファイル名をもったゲーム用アプリケーションファイルとして配布されたものとしよう（ファイル名の拡張子.apkは、このファイルがＡＰＫファイルであることを示している）。
この配布用ファイル２０の実行時には、上述したとおり、署名情報に基づく改竄検知（署名情報２２の正当性確認）が行われる。図３は、Android端末において実行される署名情報２２の正当性確認処理を示すブロック図である。
Android端末が入手した「PatGame.apk」なるファイル名をもった配布用ファイル２０には、アプリケーションパッケージ２１とＡの署名情報２２とが含まれている。ここで、署名情報２２には、署名値Ｓ（Ａ）とＡの第２の鍵Ｋ（ａ２）とが含まれており、前述したように、署名値Ｓ（Ａ）に対して、Ａの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、元のハッシュ値Ｈを得ることができる。図３では、このような署名値Ｓ（Ａ）の復号によって得られたハッシュ値をハッシュ値Ｈ１と呼ぶことにする。
一方、アプリケーションパッケージ２１（署名対象データＤ）に対して、図２に示すハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ＝ＨＡＳＨ（Ｄ）を求める処理も行う。図３では、このような不可逆変換によって得られたハッシュ値をハッシュ値Ｈ２と呼ぶことにする。もし、Android端末が入手した「PatGame.apk」なるファイル名をもった配布用ファイル２０に含まれているアプリケーションパッケージ２１の内容が、図２の上段に示すアプリケーションパッケージ２１の内容と完全に同一であれば、ハッシュ値Ｈ１，Ｈ２は一致するはずである。
そこで、ユーザＵが利用するAndroid端末において、ハッシュ値Ｈ１，Ｈ２の一致を確認する処理を実行すれば、アプリケーションパッケージ２１に対する改竄が行われているか否かを判定することができる。AndroidＯＳには、アプリケーションプログラムの実行前にこのような一致確認を行い、両者が不一致であった場合には、アプリケーションパッケージ２１に対して何らかの改竄が行われたものと判断し、当該アプリケーションプログラムの実行を中止する機能が備わっている。
＜＜＜ §２．従来の配布方法の具体的な問題点 ＞＞＞
§１で述べたとおり、Android端末用のアプリケーションプログラムは、図１に示すように、配布用ファイル（ＡＰＫファイル）２０の形式で広く配布されることになるので、一般ユーザＵ１，Ｕ２，Ｕ３は、インターネット等を介してこれをダウンロードすることにより容易に入手することができる。これは、悪意をもったクラッカーＸも、配布用ファイル２０を容易に入手できることを意味する。したがって、クラッカーＸが、入手した配布用ファイル２０に対して改竄を施し、これをインターネット等を介して再配布することも容易である。
しかも、ＡＰＫファイルの仕様は広く公開されているため、クラッカーＸの立場からすると、改竄も容易であり、かつ、再配布も容易であるという、不正行為が行いやすい環境が整っていることになる。特に、アプリケーションプログラム１０を構成する各要素のうち、リソースデータ１２や補助ファイル１４に対する改竄は非常に容易である。
たとえば、リソースデータ１２を構成する画像データファイルや文字列データファイルは、JPEG形式，GIF形式，BMP形式，PNG形式，XML形式など、ごく一般的なファイルフォーマットで記述されたデータであるため、ファイルの内容を書き換えたり、ファイルを入れ替えるだけで改竄が可能になる。このため、本来の画像を猥褻な画像に入れ替えたり、本来の文字列を不適切な文字列に入れ替えたりする改竄は容易に行い得る。また、「YESボタン」の画像と「NOボタン」の画像とを入れ替えるような改竄が行われると、一見したところ改竄の事実に気づかないが、ユーザの回答入力画面における「YES」と「NO」の表示だけが入れ替わってしまうという重大な支障が生じることになる。
一方、補助ファイル１４（マニフェストファイル）も、XML形式で記載された判読容易な文字列データによって構成されているため、改竄の対象になりやすい。具体的には、補助ファイル１４内には、当該アプリケーションプログラムが、インターネット接続を行うか否か、GPS情報を参照するか否か、電話機能を利用するか否か、といったパーミッション情報が含まれており、この情報が改竄されると、ユーザが許可していない動作が実行されることになる。たとえば、インターネット接続および電話機能の利用を「行う」旨のパーミッション情報をもつアプリケーションプログラムについて、更に、GPS情報の参照を「行う」旨のパーミッション情報を追加するような改竄が行われると、本来のパーミッション情報では許可していない「GPS情報の参照」という動作が実行されることになり、GPS情報が外部に流出するといった被害が発生するおそれがある。
このような改竄による被害は、ユーザだけではなく、コンテンツプロバイダにまで及ぶ。たとえば、プログラム提供者Ａが配布している「PatGame.apk」なるアプリケーションプログラムの評判を聞いたユーザＵが、当該プログラムの正規の配布用ファイルの代わりに、改竄されたファイルをダウンロードして実行してしまった場合を考えてみよう。クラッカーＸは、通常、元のファイルと同じファイル名で改竄したファイルを再配布するので、「PatGame.apk」というファイル名を確認しただけでは、それが純正のファイルであるのか、改竄されたファイルであるのかを識別することができない。
この場合、たとえば、プログラム提供者Ａの本来のロゴ画像が猥褻な画像に入れ替わっているような顕著な改竄が行われたケースであれば、ユーザは、実行しているアプリケーションプログラムが改竄されたものであると認識することができるであろう。しかしながら、ユーザが改竄に気づかないケースでは、当該アプリケーションプログラムの不具合の責任は、プログラム提供者Ａにあると考えるであろう。このような不当な評価がインターネット等を介して流布すると、プログラム提供者Ａは風評被害を受けることになる。
もちろん、Androidの仕様によれば、§１で述べたとおり、配布用ファイル２０には、アプリケーションパッケージ２１とともに署名情報２２が付加されており、Android端末では、図３に示す手順に従って、アプリケーションパッケージ２１に対する署名情報２２の正当性が確認される。したがって、クラッカーＸが、リソースデータ１２内の画像ファイルや文字列ファイルを別なファイルに差し替えたり、補助ファイル１４内のパーミッション情報を書き替えたりしただけでは、図３に示す確認処理において不一致が生じ、改竄の事実を検知することができる。
すなわち、図３に示す例において、クラッカーＸがアプリケーションパッケージ２１の内容を書き替えた場合、署名対象データＤがＤ′に変わってしまうため、得られるハッシュ値Ｈ２も変わってしまうことになる。その結果、署名対象データＤに基づいて作成された署名値Ｓ（Ａ）を復号して得られるハッシュ値Ｈ１と不一致が生じることになり、改竄の事実が検知される。
このように、§１で述べた従来の配布方法では、アプリケーションパッケージ２１のみに対して行われた改竄については検知が可能である。しかしながら、署名情報２２に対する改竄まで行われてしまうと、これを検知することはできない。以下にその理由を説明する。
ここでは、図１に示すように、プログラム提供者Ａが配布した正規の配布用ファイル２０を、クラッカーＸが入手したものとしよう。図４は、このようにして入手した正規の配布用ファイル２０に対して、クラッカーＸが試みる改竄プロセスを示すブロック図である。クラッカーＸは、まず、入手した配布用ファイル２０に含まれるアプリケーションパッケージ２１に対して伸張処理を実行し、元のアプリケーションプログラム１０を復元する。パッケージ化処理は、基本的にはファイルの圧縮処理であるため、この圧縮処理に応じた伸張処理を行うことにより、元のアプリケーションプログラム１０を容易に復元することができる。§１で述べたとおり、アプリケーションプログラム１０は、プログラム本体部１１，リソースデータ１２，サブルーチン群１３，補助ファイル１４という要素によって構成されている（この他にもいくつかの要素が付加される場合もある）。
クラッカーＸは、これらの各要素に対して改竄を施すことになるが、前述したとおり、リソースデータ１２や補助ファイル１４に対する改竄は非常に容易であり、データファイルの入れ替えや、テキストデータの書き替えという簡単な作業によって行うことができる。そこで、ここでは、クラッカーＸが、図示のとおり、リソースデータ１２をリソースデータ１２Ｘに改竄し、補助ファイル１４を補助ファイル１４Ｘに改竄したものとしよう。プログラム本体部１１およびサブルーチン群１３に対する改竄は行われていないが、改竄されたリソースデータ１２Ｘおよび改竄された補助ファイル１４Ｘを含むアプリケーションプログラム１０Ｘは、もはや正常動作を行わないものになっている。
続いて、クラッカーＸは、アプリケーションプログラム１０Ｘに対する再パッケージ化処理を行い、改竄されたアプリケーションパッケージ２１Ｘを生成する。こうして生成したアプリケーションパッケージ２１Ｘを、正規の配布用ファイル２０内の正規のアプリケーションパッケージ２１とすり替えただけでは、Android端末で行われる通常の改竄検知処理によって改竄の事実が検知されることになる。すなわち、Ａの署名情報２２の正当性を確認する処理で不一致が生じることになる。
ところが、クラッカーＸは、改竄されたアプリケーションパッケージ２１Ｘを署名対象データＤ′として、自分自身を署名者とする署名を行うことにより、Ｘの署名情報２２Ｘを作成することができる。具体的には、クラッカーＸの第１の鍵Ｋ（ｘ１）を用いて、署名対象データＤ′（すなわち、改竄されたアプリケーションパッケージ２１Ｘ）に対する署名値Ｓ（Ｘ）を作成する処理を行い、作成された署名値Ｓ（Ｘ）と、クラッカーＸの第２の鍵Ｋ（ｘ２）とを含むＸの署名情報２２Ｘを作成すればよい。
プログラム提供者Ａが、第１の鍵Ｋ（ａ１）を秘密鍵として管理していれば、クラッカーＸは、Ａの第１の鍵Ｋ（ａ１）を入手することができないので、クラッカーＸが、改竄された署名対象データＤ′に対して、署名者Ａとして署名を行うことはできない。しかしながら、クラッカーＸは、自分自身の第１の鍵Ｋ（ｘ１）を用いて、署名者Ｘとして署名を行うことは可能であり、そのようにして得られた署名値Ｓ（Ｘ）に、自分自身の第２の鍵Ｋ（ｘ２）を付加して、Ｘの署名情報２２Ｘを作成することはできる。こうして作成された署名情報２２Ｘは、いわばクラッカーＸによる再署名というべき情報であり、改竄されたアプリケーションパッケージ２１Ｘに対して正当性を有している。
こうして、クラッカーＸが、改竄されたアプリケーションパッケージ２１ＸにＸの署名情報２２Ｘを付加すれば、改竄された配布用ファイル２０Ｘを得ることができる。そして、この配布用ファイル２０Ｘを、「PatGame.apk」なるファイル名をもったＡＰＫファイルとして再配布すれば、一見したところ、正規のＡＰＫファイルと区別できない改竄されたファイルを流布させることができる。
Androidの仕様は広く公開されており、ＡＰＫファイルの作成作業を支援するための様々なツールも広く普及している。たとえば、アプリケーションプログラム１０をパッケージ化してアプリケーションパッケージ２１を作成するツール、アプリケーションパッケージ２１に任意の者の署名情報２２を付加してＡＰＫファイル２０を作成するツール、ＡＰＫファイル２０内のアプリケーションパッケージ２１を伸張して元のアプリケーションプログラム１０を復元するツールなどは、インターネット上の様々なサイトから入手可能であり、クラッカーＸは、これらのツールを利用して、図４に示す改竄プロセスを実行し、改竄されたＡＰＫファイル２０Ｘを作成することができる。
このように、アプリケーションパッケージ２１に対する改竄とともに、署名情報２２に対する改竄が行われた場合、図３に示す従来の改竄検知方法では、改竄の検知を行うことができない。すなわち、図４に示す配布用ファイル２０Ｘにおいて、Ｘの署名情報２２Ｘは、アプリケーションパッケージ２１Ｘを署名対象データＤ′としてクラッカーＸが署名を行うことによって得られた情報であるから、図３に示す従来の改竄検知方法では何ら支障なく一致確認が得られることになる。したがって、一般ユーザＵが、改竄された配布用ファイル２０ＸをAndroid端末にダウンロードして実行すれば、改竄されたアプリケーションプログラム１０Ｘは、正規のアプリケーションプログラムとして実行されてしまうことになる。
このように、改竄されたアプリケーションパッケージ２１に対してクラッカーＸによる再署名が行われ、この再署名によって得られた署名情報による差し替えが行われてしまうと、署名情報の正当性は確保されてしまうため、Android端末の一般的な改竄検知機能によっては改竄の検知を行うことができない。これは、Androidの仕様が、そもそも署名者の身元まで確認した改竄検知を行うようになっていないためである。すなわち、Android端末は、正規のコンテンツプロバイダーであるプログラム提供者ＡとクラッカーＸとを区別することはできないので、署名者がＡであろうがＸであろうが、署名対象データと署名情報との間に整合性が確認できれば、改竄なしと判断せざるを得ない。
もちろん、認証サーバなどへ問い合わせを行えば、署名者の身元確認を行うことができる。官公庁への電子申請や電子商取引などを行う場合、通常、認証サーバなどへ問い合わせを行い、署名者の身元確認を行う処理が行われる。しかしながら、Android端末の場合、少なくともアプリケーションプログラムを実行する際の改竄判定処理では、署名者の身元確認まで行う仕様にはなっていない。これは、Android端末がオフライン状態（外部の認証サーバへの問い合わせができない状態）であっても、アプリケーションプログラムを支障なく実行できるようにするためだと思われる。
このように、署名情報の一致確認は行うものの、署名者の身元確認までは行わない端末装置に対してアプリケーションプログラムを配信する場合に、署名情報に対する改竄までが行われてしまうと、有効な改竄検知を行うことができない。本発明は、このような問題に対処するための新たなアプリケーションプログラムの効果的な配布実行方法を提供するものである。
＜＜＜ §３．本発明の基本的な実施形態に係る配布実行方法 ＞＞＞
ここに示す基本的な実施形態の原理は、図１に示す配布用ファイル２０において、配布前に、Ａの署名情報２２についての何らかのマーキングを行っておき、実行時には、このマーキングを利用して、Ａの署名情報２２に対する改竄の有無を検知する、というものである。クラッカーＸが、図４に示す方法で、Ａの署名情報２２をＸの署名情報２２Ｘにすり替えたとしても、Ａの署名情報２２に関する何らかの痕跡をマーキングしておけば、署名情報のすり替えを検知することができる。
もっとも、このマーキングの内容がクラッカーＸに察知されてしまうと、マーキングを含めた改竄が行われてしまうことになる。そこで、本発明では、マーキング対象を特定の方法で秘匿化するようにし、クラッカーＸにマーキングの内容が察知されないようにするとともに、秘匿化された情報に基づいてマーキングの内容の正当性を確認する改竄チェックルーチンを、アプリケーションプログラム１０自身に組み込むという手法を採る。以下、その基本原理を詳細に説明する。
図５は、本発明の基本的な実施形態に係るアプリケーションプログラムの配布方法の基本原理を示すブロック図である。この方法では、プログラム提供者Ａは、図１に示すアプリケーションプログラム１０の代わりに、図５に示すアプリケーションプログラム１０Ａを用意し、これをパッケージ化してアプリケーションパッケージ２１Ａを作成する。アプリケーションプログラム１０Ａは、アプリケーションプログラム１０内のプログラム本体部１１をプログラム本体部１１Ａに置き換え、サブルーチン群１３をサブルーチン群１３Ａに置き換えたものである。
サブルーチン群１３Ａは、サブルーチン群１３に、改竄チェックルーチンＦを付加したものである。この改竄チェックルーチンＦは、後述するアルゴリズムに基づいて、Ａの署名情報２２Ａが改竄されているかどうかを確認する機能をもったサブルーチンプログラムであり、第１の特定鍵Ｋ（ｓ１）を内蔵している。この第１の特定鍵Ｋ（ｓ１）は、Ａの署名情報２２Ａの改竄の有無を調べるために必須の鍵になる。
一方、プログラム本体部１１Ａは、プログラム本体部１１の所定箇所に、改竄チェックルーチンＦをコールするサブルーチンコール命令と、改竄チェックルーチンＦから「改竄あり」との判定結果が返された場合に、以後の命令群の実行を中止する命令と、を挿入したものである。したがって、改竄チェックルーチンＦから「改竄なし」との判定結果が返された場合には、プログラム本体部１１Ａは、以後の命令群の実行を引き続き実行することになるが、改竄チェックルーチンＦから「改竄あり」との判定結果が返された場合には、以後の命令群の実行は中止され、アプリケーションプログラム１０Ａは終了することになる。
結局、アプリケーションプログラム１０Ａは、基本的には、アプリケーションプログラム１０と同等の処理機能をもったプログラムであるが、改竄チェックルーチンＦを利用した自己改竄チェック機能が付加されたプログラムと言うことができる。Android端末において、このアプリケーションプログラム１０Ａが実行されると、改竄チェックルーチンＦによる改竄チェック処理が実行され、署名情報２２Ａに対する改竄の有無が判定される。そして、改竄ありとの判定結果が得られた場合には、アプリケーションプログラム１０Ａの実行は中止されることになる。したがって、実用上は、プログラム本体部１１Ａにおけるアプリケーションプログラム本来の機能を果たすための命令群の前に、改竄チェックルーチンＦをコールするサブルーチンコール命令を組み込むようにし、アプリケーションプログラム１０Ａの実行初期段階で改竄チェックルーチンＦが実行されるようにするのが好ましい。
続いて、§１で述べた従来方法と同様に、パッケージ化によって得られたアプリケーションパッケージ２１Ａを署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含む署名情報２２Ａを作成する。
ここで述べる基本的な実施形態では、更に、Ａの署名情報２２Ａを秘匿化対象データＣとして抽出し（図５では、秘匿化対象データＣを太線枠で示す）、この秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報２３Ａを作成する。秘匿化処理の具体的な方法は、§６で実例を挙げて説明するが、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３Ａを決定することができる処理であって、この第２の特定鍵Ｋ（ｓ２）に対して特別な関係をもった第１の特定鍵Ｋ（ｓ１）（すなわち、改竄チェックルーチンＦに内蔵されている鍵）を用いることによってのみ、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認できる、という条件を満たす処理であれば、どのような処理を秘匿化処理として採用してもかまわない（後述するように、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、同一の共通特定鍵Ｋ（ｓ０）を用いることも可能である）。
こうして、秘匿情報２３Ａが作成できたら、プログラム提供者Ａは、アプリケーションパッケージ２１Ａと、Ａの署名情報２２Ａと、秘匿情報２３Ａと、を含む配布用ファイル２０Ａを作成し、これをＡＰＫファイルとして配布すればよい。ここで、Ａの署名情報２２Ａは、アプリケーションパッケージ２１Ａが改竄されていないことを確認するために用いられるプログラム提供者Ａによる電子署名であり、秘匿情報２３Ａは、このＡの署名情報２２Ａが改竄されていないことを確認するために用いられるマーキング情報ということになる。Android端末では、Ａの署名情報２２Ａの正当性を確認するとともに、秘匿情報２３Ａの正当性を確認することにより、アプリケーションパッケージ２１Ａに対する改竄のみならず、Ａの署名情報２２Ａに対する改竄を検知することができる。
図６は、図５に示す配布用ファイル２０Ａについて、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を示すブロック図である。ユーザＵが、Android端末に配布用ファイル２０Ａをインストールし、これを実行しようとすると、アプリケーションプログラム１０Ａの実行前に、AndroidＯＳの基本機能により、Ａの署名情報２２Ａの正当性を確認する処理が実行される。
すなわち、§１でも述べたように、まず、署名情報２２Ａから署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、ハッシュ値Ｈ１を得る処理が行われる。続いて、アプリケーションパッケージ２１Ａ（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ２を求める処理を行う。そして、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行う。ここでは、このような確認処理のプロセスを第１の確認段階と呼ぶことにする。この第１の確認段階では、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性を確認する処理が行われることになる。
AndroidＯＳは、この第１の確認段階によって、署名情報２２Ａの正当性が確認できた場合、アプリケーションパッケージ２１Ａは改竄されていないものと判断し、そこに含まれているアプリケーションプログラム１０Ａを実行する。ただ、アプリケーションプログラム１０Ａの構成要素となるプログラム本体部１１Ａには、前述したとおり、改竄チェックルーチンＦをコールするサブルーチンコール命令が組み込まれているため、アプリケーションプログラム１０Ａの実行により、改竄チェックルーチンＦが実行されることになる。
ここで、改竄チェックルーチンＦは、内蔵している第１の特定鍵Ｋ（ｓ１）を利用して、秘匿化対象データＣ（この例の場合は、Ａの署名情報２２Ａ）に対する秘匿情報２３Ａの正当性を確認する処理を行う。ここでは、このような確認処理のプロセスを第２の確認段階と呼ぶことにする。前述したとおり、秘匿情報２３Ａは、秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して得られた情報であり、秘匿化対象データＣ（Ａの署名情報２２Ａ）に対する秘匿情報２３Ａの正当性は、第１の特定鍵Ｋ（ｓ１）を用いて確認することができる。
改竄チェックルーチンＦは、こうして実行された第２の確認段階の結果を、サブルーチンの実行結果としてプログラム本体部１１Ａへと返すことになる。プログラム本体部１１Ａは、改竄チェックルーチンＦから肯定的な判定結果（秘匿情報２３Ａの正当性が確認された旨の判定結果）が返された場合には、以後の命令群を引き続き実行することになるが、否定的な実行結果（秘匿情報２３Ａの正当性が確認されなかった旨の判定結果）が返された場合には、以後の命令群の実行を中止する。
かくして、Android端末では、第１の確認段階において、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性が確認され、かつ、第２の確認段階において、署名情報２２Ａに対する秘匿情報２３Ａの正当性が確認された場合にのみ、アプリケーションプログラム１０Ａは正常に実行されることになる。
図７は、ここに示す基本的な実施形態の基本手順を示す流れ図である。この基本手順は、アプリケーションプログラムを配布する配布プロセスと、配布されたアプリケーションプログラムを実行する実行プロセスと、によって構成されるアプリケーションプログラムの配布実行方法の手順ということになる。図示のとおり、前半の配布プロセスでは、ステップＳ１〜Ｓ５の各段階が実行され、後半の実行プロセスでは、ステップＳ６〜Ｓ１２の各段階が実行される。以下、これら各ステップの内容を順に説明する。
ここでは、便宜上、前半の配布プロセス（ステップＳ１〜Ｓ５）は、プログラム提供者Ａが利用するコンピュータによって実行され、後半の実行プロセス（ステップＳ６〜Ｓ１２）は、ユーザＵが利用するアプリケーション実行用コンピュータ（スマートホンなどのAndroid端末）によって実行されるものとして以下の説明を行うことにする。なお、前半の配布プロセスを構成するステップＳ１〜Ｓ５は、必ずしも同一のコンピュータで実行する必要はないが、後半の実行プロセスを構成するステップＳ６〜Ｓ１２は、ユーザＵが利用する同一のアプリケーション実行用コンピュータにおいて実行されることになる。
まず、ステップＳ１のパッケージ化段階では、図５に示すように、第１の特定鍵Ｋ（ｓ１）を含むアプリケーションプログラム１０Ａに対して、少なくとも圧縮処理を含むパッケージ化処理を施し、アプリケーションパッケージ２１Ａを作成する処理が行われる。ここで、パッケージ化処理の対象となるアプリケーションプログラム１０Ａには、図６に示す第２の確認段階を実行するための改竄チェックルーチンＦが含まれており、第１の特定鍵Ｋ（ｓ１）は、この改竄チェックルーチンＦ内に含まれている。
特に、Android端末に配布する場合は、その仕様により、アプリケーションプログラム１０Ａには、プログラム本体部１１Ａと、このプログラム本体部１１Ａから呼び出されるサブルーチン群１３Ａと、画像および文字列を含むリソースデータ１２と、ＸＭＬ形式のデータからなる補助ファイル１４（マニフェストファイル）とが含まれることになり、ステップＳ１のパッケージ化段階では、ＺＩＰ方式の圧縮処理を含むパッケージ化処理が実行されることになる。
続くステップＳ２の署名情報作成段階では、図５に示すように、ステップＳ１で作成されたアプリケーションパッケージ２１Ａを署名対象データＤとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者Ａの第２の鍵Ｋ（ａ２）とを含むＡの署名情報２２Ａを作成する処理が実行される。ここで、プログラム提供者Ａの第１の鍵Ｋ（ａ１）および第２の鍵Ｋ（ａ２）としては、公開鍵暗号方式に利用される一対の鍵、すなわち、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵が用いられる。
次に、ステップＳ３の秘匿情報作成段階では、Ａの署名情報２２Ａを秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報２３Ａを作成する処理が実行される。ここで、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）としては、一方の鍵を用いて秘匿化処理を施したデータの正当性を他方の鍵を用いて確認できる性質をもった一対の鍵が用いられる（後述するように、両者は同一の共通鍵でもかまわない）。
このステップＳ３で実行する秘匿化処理としては、前述したとおり、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３Ａを決定することができる処理であって、第１の特定鍵Ｋ（ｓ１）を用いることによってのみ、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認できる、という条件を満たす処理であれば、どのような処理であってもかまわない。秘匿化処理の具体例は§６で例示する。
一方、ステップＳ４の配布用ファイル作成段階では、ステップＳ１で作成されたアプリケーションパッケージ２１Ａと、ステップＳ２で作成された署名情報２２Ａと、ステップＳ３で作成された秘匿情報２３Ａと、をまとめることにより、配布用ファイル２０Ａが作成される。Android端末に配布する場合は、この配布用ファイル作成段階において、ＡＰＫ形式のフォーマットをもった配布用ファイル２０Ａ（拡張子.apkが付されたＡＰＫファイル）が作成されることになる。
なお、ＡＰＫファイルの実体は、ＺＩＰ方式の圧縮フォーマットで圧縮されたファイルであるので、ステップＳ４の配布用ファイル作成段階でＡＰＫファイルを作成する場合は、ＺＩＰ方式の圧縮フォーマットにおけるコメント領域に秘匿情報２３Ａを記録することができる。このコメント領域は、本来、ＡＰＫファイルの作成者が、任意のコメント文を記載できるようにするために設けられた領域であるから、秘匿情報２３Ａを構成するデータをコメント文の代わりに記録しても、何ら支障は生じない。別言すれば、コメント領域に秘匿情報２３Ａを記録した本発明に係る配布用ファイル２０Ａは、Androidの仕様に合致したＡＰＫファイルとしての条件を満たしており、そのままAndroid端末に配布しても何ら支障はなく、AndroidＯＳによって、仕様通りのＡＰＫファイルとして取り扱われることになる。
配布プロセスの最後には、ステップＳ５のファイル出力段階が行われる。この段階では、ステップＳ４で作成された配布用ファイル２０Ａ（ここに示す例の場合、Androidの仕様通りのＡＰＫファイル）が配布のために出力されることになる。たとえば、配布用のＷｅｂサーバなどに出力すれば、配布用ファイル２０Ａはインタネットを介して一般ユーザへ配布されることになり、光学的記録媒体やＩＣメモリ等の物理的記録媒体に記録して出力すれば、配布用ファイル２０Ａは、このような物理的記録媒体に格納された状態で配布されることになる。
続いて、後半の実行プロセスについて説明する。まず、ステップＳ６のファイル入力段階では、ユーザＵが利用するアプリケーション実行用コンピュータによって、前半の配布プロセスによって配布された配布用ファイル２０Ａが入力される。たとえば、ユーザＵがAndroid端末を利用している場合、ＡＰＫファイルの配布サイトからインターネット経由で配布用ファイル２０Ａをダウンロードする指示を与えることにより、当該Android端末に配布用ファイル２０Ａが取り込まれることになり、更に、ユーザＵの了承を得て、配布用ファイル２０Ａのインストールが行われることになる。Android端末の場合、このような処理は、ＯＳプログラムの基本機能によって実行される。
続くステップＳ７以降の各段階は、ユーザＵもしくは他のアプリケーションやサービスが、ステップＳ６でインストールしたアプリケーションプログラム（配布用ファイル２０Ａ）について、実行指示を与えた場合に行われる（第１のアプリケーションプログラムが、第２のアプリケーションプログラムを起動する機能を有しているケースでは、ユーザＵが、当該第１のアプリケーションプログラムの実行指示を与えた時点ではなく、その後、当該第１のアプリケーションプログラムが、当該第２のアプリケーションプログラムを起動する処理を実行した時点で、ステップＳ７以降の各段階が行われることになる。）。
まず、ステップＳ７では、図６に示す第１の確認段階が行われる。この第１の確認段階では、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性を確認する処理が行われる。すなわち、ステップＳ６で入力した配布用ファイル２０Ａについて、Ａの署名情報２２Ａに含まれているプログラム提供者Ａの第２の鍵Ｋ（ａ２）を用いた復号を利用した署名確認処理を行って、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性が確認される。
具体的には、図６を用いて説明したように、署名情報２２Ａから署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことによりハッシュ値Ｈ１を求め、アプリケーションパッケージ２１Ａ（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行いハッシュ値Ｈ２を求め、ハッシュ値Ｈ１とハッシュ値Ｈ２との一致確認が行われることになる。Android端末の場合、この第１の確認段階も、ＯＳプログラムの基本機能によって実行される。
ステップＳ７の第１の確認段階において肯定的な結果が得られた場合、すなわち、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性が確認された場合には、ステップＳ８を経てステップＳ９へと進み、第２の確認段階が実行される。これに対して、ステップＳ７の第１の確認段階において否定的な結果が得られた場合、すなわち、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ８を経てステップＳ１１へと進み、当該アプリケーションの実行は中止される。
Android端末の場合、ステップＳ８の分岐処理もＯＳプログラムの基本機能によって実行される。すなわち、ステップＳ７で肯定的な結果が得られた場合は、ＯＳプログラムはアプリケーションプログラム１０Ａを起動する処理を行い、ステップＳ７で否定的な結果が得られた場合は、ＯＳプログラムはアプリケーションプログラム１０Ａの起動を中止する。このような処理は、AndroidＯＳの標準仕様に基づく処理である。
ステップＳ９では、図６に示す第２の確認段階が行われる。この第２の確認段階では、署名情報２２Ａに対する秘匿情報２３Ａの正当性を確認する処理が行われる。すなわち、ステップＳ６で入力した配布用ファイル２０Ａから、秘匿化対象データＣとなるＡの署名情報２２Ａおよび秘匿情報２３Ａを抽出し、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認される。実際には、アプリケーションパッケージ２１Ａを伸張して得られるアプリケーションプログラム１０Ａに含まれている改竄チェックルーチンＦによって、第２の確認段階の処理が行われる。
前述したとおり、改竄チェックルーチンＦは、第１の特定鍵Ｋ（ｓ１）を内蔵しており、この第１の特定鍵Ｋ（ｓ１）を用いて、秘匿化対象データＣに対する秘匿情報２３Ａの正当性を確認する。正当性を確認するための具体的な処理については、§６において実例を挙げて説明する。改竄チェックルーチンＦは、アプリケーションプログラム１０Ａ内に組み込まれているサブルーチンであるから、結局、ステップＳ９の処理は、アプリケーションプログラム１０Ａによって実行される処理ということになる。
ステップＳ９の第２の確認段階において肯定的な結果が得られた場合、すなわち、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認された場合には、ステップＳ１０を経てステップＳ１２へと進み、アプリケーションプログラム１０Ａの処理を続行する実行段階が行われる。これに対して、ステップＳ９の第２の確認段階において否定的な結果が得られた場合、すなわち、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ１０を経てステップＳ１１へと進み、当該アプリケーションの実行は中止される。
結局、ステップＳ８およびステップＳ１０は、「改竄あり」もしくは「改竄なし」との判断を行う改竄判定段階を構成する処理になる。すなわち、ステップＳ６で入力した配布用ファイル２０Ａについて、ステップＳ７の第１の確認段階およびステップＳ９の第２の確認段階の双方において肯定的な結果が得られた場合には「改竄なし」との判断が行われ、第１の確認段階および第２の確認段階の少なくとも一方において否定的な結果が得られた場合には「改竄あり」との判断が行われる。
そして、この改竄判定段階において、「改竄なし」との判断が得られた場合は、ステップＳ１２へと進み、配布されたアプリケーションプログラム１０Ａを正常に実行する実行段階が行われるが、「改竄あり」との判断が行われた場合は、ステップＳ１１へと進み、配布されたアプリケーションプログラム１０Ａの実行は中止される。
このように、実行プロセスを、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うアプリケーション実行用コンピュータを用いる場合、ステップＳ７の第１の確認段階をＯＳプログラムに基づいて実行し、ステップＳ９の第２の確認段階をアプリケーションプログラム内の改竄チェックルーチンに基づいて実行する、という役割分担を行うことができる。Android端末のように、もともとＯＳプログラムが第１の確認段階を行う機能を備えている場合には、このような役割分担を行えば、第１の確認段階を行うためのプログラムを別途用意する手間を省くことができる。
Android端末の場合、ステップＳ７の第１の確認段階は、ＯＳプログラムの基本機能によって実行され、ステップＳ８において「改竄あり」との判断に基づいてステップＳ１１に分岐した場合の実行中止処理は、ＯＳプログラムによって実行されることになる。この場合、ユーザＵからは、アプリケーションプログラム１０Ａを起動する旨の指示が与えられているものの、実際には、アプリケーションプログラム１０Ａはまだ起動していない状態である。したがって、ステップＳ８からステップＳ１１に分岐した場合の実行中止処理とは、ユーザＵからの指示にかかわらず、ＯＳプログラムがアプリケーションプログラム１０Ａの起動を拒否する処理ということになる。
一方、ステップＳ９の第２の確認段階は、アプリケーションプログラム１０Ａが起動された後に、当該アプリケーションプログラム１０Ａ内の改竄チェックルーチンによって実行される処理ということになる。より詳細に説明すれば、アプリケーションプログラム１０Ａ内のプログラム本体部１１Ａからサブルーチン群１３Ａ内の改竄チェックルーチンＦがサブルーチンとしてコールされ、当該サブルーチン内のプロセスとして、第２の確認段階が実行されることになる。したがって、ステップＳ１０からステップＳ１１に分岐した場合の実行中止処理とは、アプリケーションプログラム１０Ａ自身が、以後の処理の実行を中止して終了する処理（制御をＯＳプログラムへ返す処理）ということになる。もちろん、ステップＳ１０において「改竄なし」との判断がなされた場合は、ステップＳ１２の実行段階の処理、すなわち、アプリケーションプログラム１０Ａが、以後の処理を継続して実行する処理が行われることなる。
要するに、図７に示す実施形態では、ＯＳプログラムに基づく第１の確認段階（ステップＳ７）が行われた後に、アプリケーションプログラム内の改竄チェックルーチンＦに基づく第２の確認段階（ステップＳ９）が実行されるようにしつつ、第１の確認段階において否定的な結果が得られた場合には、ＯＳプログラムにより改竄ありとの判断を伴う改竄判定段階（ステップＳ８）を実行し、第２の確認段階（ステップＳ９）を行わずに、当該判断対象となったアプリケーションプログラムの実行をＯＳプログラムの管理下で中止（ステップＳ１１）することになる。
一方、第１の確認段階（ステップＳ７）において肯定的な結果が得られた場合には、ＯＳプログラムの管理下で当該判断対象となったアプリケーションプログラムを実行して第２の確認段階（ステップＳ９）を行う。そして、この第２の確認段階において否定的な結果が得られた場合には、当該アプリケーションプログラム自身により改竄ありとの判断を伴う改竄判定段階（ステップＳ１０）を実行し、当該アプリケーションプログラム自身により、以後の処理の実行を中止（ステップＳ１１）する。また、第２の確認段階（ステップＳ９）において肯定的な結果が得られた場合には、当該アプリケーションプログラム自身により改竄なしとの判断を伴う改竄判定段階（ステップＳ１０）を実行し、当該アプリケーションプログラム自身により、以後の処理を引き続き実行する（ステップＳ１２）ことになる。
＜＜＜ §４．本発明の基本的な実施形態による改竄検知 ＞＞＞
ここでは、クラッカーＸが、図５に示す方法で作成された配布用ファイル２０Ａを入手し、これに改竄を加えて再配布した場合に、Android端末において、どのような方法で改竄検知が行われるかについて説明しよう。
図８は、図５に示す配布方法に対してクラッカーＸが試みる改竄プロセスを示すブロック図である。クラッカーＸは、まず、入手した配布用ファイル２０Ａに含まれるアプリケーションパッケージ２１Ａに対して伸張処理を実行し、元のアプリケーションプログラム１０Ａを復元し、その中味について改竄を行う。
図８の上段の図は、このような改竄が行われた後のアプリケーションプログラム１０Ｘ′を示す図である。§２でも述べたとおり、Android端末用のアプリケーションプログラム１０の構成要素の中でも、リソースデータ１２や補助ファイル１４は、容易に改竄することができる。そこで、ここでも、クラッカーＸが、リソースデータ１２および補助ファイル１４に対して改竄を施したものとしよう。図８に示すリソースデータ１２Ｘおよび補助ファイル１４Ｘは、クラッカーＸによる改竄を受けたものである。続いて、クラッカーＸは、アプリケーションプログラム１０Ｘ′に対する再パッケージ化処理を行い、改竄されたアプリケーションパッケージ２１Ｘ′を生成する。
もし、クラッカーＸが、こうして生成したアプリケーションパッケージ２１Ｘ′を、正規の配布用ファイル２０Ａ内の正規のアプリケーションパッケージ２１Ａとすり替えて再配布した場合、Android端末で行われる通常の改竄検知処理によって改竄の事実が検知されることは、既に§２で述べたとおりである。すなわち、Ａの署名情報２２Ａの正当性を確認する処理で不一致が生じることになる。本発明においても、図７に示す実行プロセスにおけるステップＳ７の第１の確認段階において、ＯＳプログラムによって当該改竄の検知が行われる。
そこで、ここでは、クラッカーＸが署名情報に対する改竄も行った場合を考えてみる。すなわち、図８の下段に示すように、クラッカーＸは、自分の第１の鍵Ｋ（ｘ１）を用いて、署名対象データＤ′（すなわち、改竄されたアプリケーションパッケージ２１Ｘ′）に対する署名値Ｓ（Ｘ′）を作成する処理を行い、作成された署名値Ｓ（Ｘ′）と、自分の第２の鍵Ｋ（ｘ２）とを含むＸの署名情報２２Ｘ′を作成し、改竄されたアプリケーションパッケージ２１Ｘ′にＸの署名情報２２Ｘ′を付加することにより、改竄された配布用ファイル２０Ｘ′を作成する。
このように署名情報に対する改竄も行われると、クラッカーＸによる再署名が行われたことになるので、Ｘの署名情報２２Ｘ′は署名対象データＤ′に対する正当性を有する。したがって、従来の方法では、このようにして作成された配布用ファイル２０Ｘ′については、改竄検知を行うことができない。本発明においても、図７に示す実行プロセスにおけるステップＳ７の第１の確認段階では、このような改竄を検知することはできない。
しかしながら、本発明に係る方法で配布される配布用ファイル２０Ａには、更に、秘匿情報２３Ａが付加されており、この秘匿情報２３Ａについての正当性が、ステップＳ９の第２の確認段階で確認される。秘匿情報２３Ａは、図５の下段に示すとおり、秘匿化対象データＣ（この例では、Ａの署名情報２２Ａ）を第２の特定鍵Ｋ（ｓ２）を用いて秘匿化することによって得られる情報であるが、第２の特定鍵Ｋ（ｓ２）が秘密の状態で管理されていれば、クラッカーＸはこれを入手することができない。したがって、クラッカーＸは、自身で作成したＸの署名情報２２Ｘ′を秘匿化対象データＣ′として、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を行い、改竄された秘匿情報２３Ｘを作成することはできない。図８の下段において、×印が付された部分は、実際には、クラッカーＸが行うことができない処理やクラッカーＸが作成することができない情報を示している。
結局、クラッカーＸは、作成した配布用ファイル２０Ｘ′内の秘匿情報については、元のままの状態（秘匿情報２３Ａのまま）にしておくか、これを削除してしまうか、あるいは新たに作成した任意の秘匿情報に置き換えるしかない。いずれの方法を採っても、図７に示す実行プロセスにおけるステップＳ９の第２の確認段階において、正当性の確認ができないため、改竄の検知が行われることになる。
すなわち、元のままの状態にしておいた場合、第２の確認段階において、Ｘの署名情報２２Ｘ′に対する秘匿情報２３Ａの正当性を確認する処理が行われることになるが、秘匿情報２３Ａは、Ａの署名情報２２Ａに対して正当性を有する情報であるため、Ｘの署名情報２２Ｘ′に対する正当性は確認できない。一方、秘匿情報を削除してしまった場合は、Ｘの署名情報２２Ｘ′に対する正当性確認の対象物がないため、そもそも正当性確認の処理を行うことができない。また、新たに作成した任意の秘匿情報に置き換えた場合も、当該置換後の秘匿情報が、Ｘの署名情報２２Ｘ′を第２の特定鍵Ｋ（ｓ２）を用いて秘匿化することによって得られる情報（別言すれば、第１の特定鍵Ｋ（ｓ１）を用いて正当性確認がなされる情報）に偶然一致しない限り、第２の確認段階における正当性確認はなされない。
結局、クラッカーＸが、アプリケーションパッケージ２１Ａおよび署名情報２２Ａに対する改竄を行ったとしても、秘匿情報２３Ａに対する改竄を行うことができなければ、第２の確認段階において改竄が検知されるので、改竄されたアプリケーションプログラムの実行は中止され、改竄検知後のプロセスが正常に実行されることはない。このように、本発明に係るアプリケーションプログラムの配布実行方法によれば、電子署名に対する改竄が行われた場合にも、有効な改竄検知を行うことが可能になり、改竄検知後は、当該アプリケーションプログラムの実行を中止することが可能になる。
もちろん、本発明に係るアプリケーションプログラムの配布実行方法による改竄検知機能は、１００％完全なものではない。理論的には、第１の確認段階と第２の確認段階との双方をパスするような改竄を施すことは可能である。
たとえば、サブルーチン群１３Ａを解析することにより、第１の特定鍵Ｋ（ｓ１）の所在を特定することができれば、この第１の特定鍵Ｋ（ｓ１）を別な鍵に書き替えることにより、第２の確認段階で正当性が確認されるような改竄を行うことが可能になる。また、サブルーチン群１３Ａを解析することにより、改竄チェックルーチンＦを構成するコード群を特定することができれば、改竄チェックルーチンＦ自身を改竄してしまうことにより、どのような場合にも第２の確認段階では改竄検知ができないようにすることも可能である。あるいは、プログラム本体部１１Ａを解析することにより、改竄チェックルーチンＦを呼び出すサブルーチンコール命令の所在を特定することができれば、当該サブルーチンコール命令を無意味な別な命令に書き替えてしまうことにより、改竄チェックルーチンＦが実行されないようにすることも可能である。
このように、プログラム本体部１１Ａ内のプログラムやサブルーチン群１３Ａ内のプログラムの内容を逐一解析した上で、プログラム本体部１１Ａやサブルーチン群１３Ａに対して第２の確認段階を不正な方法で回避するような改竄が施された場合、本発明では改竄検知を行うことはできない（もちろん、改竄チェックルーチン以外のサブルーチンの改竄や、改竄チェックルーチンをコールする部分以外のプログラム本体部の改竄など、第２の確認段階の実行が回避されないような改竄であれば、本発明により当該改竄の検知を行うことができる。）。しかしながら、実際には、プログラム本体部１１Ａやサブルーチン群１３Ａに対する改竄を行うには、プログラムに関する高度な知識をもったクラッカーが、十分な時間と労力を費やして作業を行う必要がある。これに対して、リソースデータ１２や補助ファイル１４に対する改竄は、ＡＰＫファイルに対する若干の知識をもったクラッカーであれば行うことができ、時間や労力も必要としない。
本発明は、このように比較的簡単に行われる可能性のある改竄に対して有効な検知方法を提供することを主目的とするものであり、実用上、改竄されたアプリケーションプログラムの多くを検知する十分な効果を奏するものである。特に、これまで述べてきた基本的実施形態では、改竄チェックルーチンＦがサブルーチン群１３Ａ内の１つのサブルーチンとして、アプリケーションプログラム１０Ａ内に組み込まれているため、第２の確認段階を実施するために、別なプログラムを改めて用意する必要はない。すなわち、配布用ファイル２０Ａの中に、自分自身が改竄されているか否かを判定する改竄チェックルーチンＦが組み込まれていることになり、これを実行するコンピュータ側には、改竄チェックのために別なアプリケーションを用意する必要はない。
一般に、改竄チェック用のアプリケーションを別途用意すると、当該アプリケーションを管理し、これを配布するための余分なコストが必要になる。そこで、これまで述べてきた基本的実施形態のように、改竄チェックルーチンＦをアプリケーションプログラム１０Ａ内に組み込む方法を採用すれば、改竄チェックプログラムを別体として管理したり配布したりする必要がなくなり、アプリケーションプログラム１０Ａだけを管理・配布すれば足りるため、余分なコストを削減できるというメリットが得られる。また、アプリケーション実行用コンピュータ側でも、アプリケーションプログラム１０Ａだけを実行すれば改竄チェックが可能になる。すなわち、アプリケーションプログラムの配布、インストール、実行という一連の流れに着目した場合、従来どおりの流れを何ら阻害せずに本発明を適用して改竄検知を行うことが可能になる。
たとえば、Android端末に対して配布するアプリケーションプログラムに本発明を適用する場合、入手した配布用ファイル２０Ａ（すなわち、ＡＰＫファイル）が改竄されているか否かを判定する改竄チェックルーチンＦが、当該ＡＰＫファイル自身に含まれているため、AndroidＯＳは、当該ＡＰＫファイルに対して、通常どおり第１の確認段階を実行して署名情報の正当性を確認した後、当該ＡＰＫファイルに含まれるアプリケーションプログラムを実行する処理を行うだけでよい。Android端末は、本発明に係るＡＰＫファイルを、一般のＡＰＫファイルと同等に取り扱うことができ、ＡＰＫファイルの実行により第２の確認段階が行われるので、Android端末に特別な機能は要求されない。また、第２の確認段階を行う際に、外部の認証サーバへの問い合わせ処理なども不要であり、改竄チェックルーチンＦは、Android端末がオフライン状態（外部に対する通信が遮断されている状態）であっても、何ら支障なくその処理機能を果たすことができる。
＜＜＜ §５．秘匿化対象データのバリエーション ＞＞＞
§３で説明した本発明の基本的な実施形態に係る配布実行方法では、図５に太線枠で囲って示すように、Ａの署名情報２２Ａ全体（すなわち、署名値Ｓ（Ａ）とＡの第２の鍵Ｋ（ａ２））を秘匿化対象データＣとして、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を行い、秘匿情報２３Ａを作成している。このようにして作成された秘匿情報２３Ａは、Ａの署名情報２２Ａの痕跡を残す情報というべきものであり、第１の特定鍵Ｋ（ｓ１）を用いた所定の確認方法により、Ａの署名情報２２Ａに対する正当性の確認が可能になるという固有の性質を有している。
このような性質を有する秘匿情報２３Ａを配布用ファイル２０Ａに含ませておけば、Ａの署名情報２２Ａに対する秘匿情報２３Ａの正当性を確認する処理（第２の確認段階）を行うことにより、Ａの署名情報２２Ａに対する改竄の有無を確認することができるようになる。
もっとも、本発明を実施する上で用いる秘匿化対象データＣは、必ずしもＡの署名情報２２Ａのみに限定されるものではない。ここでは、秘匿化対象データＣのバリエーションをいくつか述べておく。
図９は、図５に示す本発明の基本的な実施形態に係る配布方法のバリエーションを示すブロック図である。図５に示す実施形態との相違点は、秘匿化対象データＣの設定方法だけである。図５に示す例では、太線枠で囲って示すように、Ａの署名情報２２Ａ全体を秘匿化対象データＣに設定しているが、図９に示すバリエーションでは、太線枠で囲って示すように、Ａの署名情報２２Ａに含まれるＡの第２の鍵Ｋ（ａ２）を構成するデータのみを秘匿化対象データＣに設定している。
したがって、図９に示すバリエーションの場合、図７のステップＳ３の秘匿情報作成段階において、第２の特定鍵Ｋ（ｓ２）を用いてＡの第２の鍵Ｋ（ａ２）を秘匿化することにより秘匿情報２３Ａ′を作成することになる。また、ステップＳ９の第２の確認段階において、Ａの署名情報２２Ａに対する秘匿情報２３Ａの正当性を確認する代わりに、このバリエーションにおける秘匿化対象データＣであるＡの第２の鍵Ｋ（ａ２）に対する秘匿情報２３Ａ′の正当性が確認されることになる。
このように、秘匿化対象データＣとして、Ａの署名情報２２Ａの代わりにＡの第２の鍵Ｋ（ａ２）を用いたとしても、署名情報に対する改竄が行われたか否かを検知する上では支障は生じない。そもそもＡの署名情報２２Ａは、プログラム提供者Ａがアプリケーションパッケージ２１Ａを署名対象データＤとして、その内容を保証することを示すものであり、プログラム提供者Ａの痕跡はＡの第２の鍵Ｋ（ａ２）として記録されていることになる。そして、クラッカーＸが、署名情報に対する改竄を行う場合、図８に示すように、Ａの署名情報２２ＡをそっくりＸの署名情報２２Ｘ′に差し替えることになるので、当然、Ａの第２の鍵Ｋ（ａ２）もＸの第２の鍵Ｋ（ｘ２）に差し替えられることになる。
したがって、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣに設定し、これを秘匿化して秘匿情報２３Ａ′を作成し、第２の確認段階において、Ａの第２の鍵Ｋ（ａ２）に対する秘匿情報２３Ａ′の正当性を確認するようにしても、署名情報に対する改竄の有無を検知することができる。Ａの第２の鍵Ｋ（ａ２）がＸの第２の鍵Ｋ（ｘ２）に差し替えられていた場合、秘匿情報２３Ａ′は、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣとして作成された情報であるから、差し替えられたＸの第２の鍵Ｋ（ｘ２）に対しての正当性は確認できない。
結局、秘匿化対象データＣとして、少なくともプログラム提供者Ａの第２の鍵Ｋ（ａ２）を含むデータを用いるようにすれば、クラッカーＸが、署名情報に対する改竄を行ったとしても、第２の確認段階において、これを検知することができる。クラッカーＸは、第２の特定鍵Ｋ（ｓ２）を入手しない限り、改竄チェックルーチンＦ（第１の特定鍵Ｋ（ｓ１）によって正当性の確認を行うルーチン）によって正当性の確認が可能な秘匿情報２３Ｘを作成することはできないので、Ａの署名情報２２ＡをそっくりＸの署名情報２２Ｘ′に差し替えたとしても、第２の確認段階における改竄検知を免れることはできない。
このように、図５に示す例のように、Ａの署名情報２２Ａを秘匿化対象データＣとして設定することもできるし、図９に示すバリエーションのように、Ａの第２の鍵Ｋ（ａ２）を秘匿化対象データＣとして設定することもできるし、その他にも種々のバリエーションを採用することができる。
図１０は、別なバリエーションを示すブロック図である。このバリエーションでは、太線枠で囲って示すように、アプリケーションパッケージ２１ＡとＡの署名情報２２Ａとの双方を構成するデータ全体を秘匿化対象データＣに設定している。したがって、このバリエーションの場合、第２の特定鍵Ｋ（ｓ２）を用いて、図に太線枠で囲った部分のデータ全体を秘匿化することにより秘匿情報２３Ａ''を作成することになる。そして第２の確認段階では、この太線枠で囲った部分のデータ全体に対する秘匿情報２３Ａ''の正当性が確認されることになる。
この図１０に示すバリエーションでも、秘匿化対象データＣにＡの第２の鍵Ｋ（ａ２）が含まれているため、クラッカーＸがＡの署名情報２２ＡをＸの署名情報２２Ｘ′に差し替える改竄を行っても、第２の確認段階による改竄検知が有効に機能することになる。
結局、プログラム提供者Ａが署名した痕跡を何らかの形で配布用ファイル２０Ａに残しておくには、図７のステップＳ３の秘匿情報作成段階において、アプリケーションパッケージ２１Ａおよび署名情報２２Ａを構成するデータの中から、プログラム提供者の第２の鍵Ｋ（ａ２）を含む所定部分を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報を作成するようにすればよい。
図５に示す例は、署名情報２２Ａを構成するデータ全体を秘匿化対象データＣに設定して秘匿情報２３Ａを作成した例であり、図９に示す例は、署名情報２２Ａに含まれるプログラム提供者の第２の鍵Ｋ（ａ２）を構成するデータを秘匿化対象データＣに設定して秘匿情報２３Ａ′を作成した例であり、図１０に示す例は、アプリケーションパッケージ２１Ａと署名情報２２Ａとの双方を構成するデータ全体を秘匿化対象データＣに設定して秘匿情報２３Ａ''を作成した例ということになる。
プログラム提供者Ａが署名した痕跡を残しておく、という目的を達成する上では、図９に示す例のように、プログラム提供者の第２の鍵Ｋ（ａ２）のみを秘匿化対象データＣとする方法が最も簡便で直接的な方法である。このような観点からは、図５に示す例や図１０に示す例は、冗長な方法と言うことができる。しかしながら、プログラム提供者Ａが署名した痕跡に加えて、アプリケーションパッケージ２１Ａに関する何らかの痕跡も残しておく、という観点では、図５に示す例や図１０に示す例は意味のある方法になる。
たとえば、図１０に示す例では、太線枠で囲ったアプリケーションパッケージ２１Ａと署名情報２２Ａとの双方が秘匿化対象データＣに設定されており、第２の確認段階では、これらのデータ全体に対する秘匿情報２３Ａ''の正当性の確認が行われることになるので、アプリケーションパッケージ２１Ａに対する改竄検知と署名情報２２Ａに対する改竄検知との両方を行うことが可能である。
図５に示す基本的な実施形態では、アプリケーションパッケージ２１Ａに対する改竄検知は、Ａの署名情報２２Ａを用いた第１の確認段階で行い、署名情報２２Ａに対する改竄検知は、秘匿情報２３Ａを用いた第２の確認段階で行うことになるが、図１０に示すバリエーションの場合、アプリケーションパッケージ２１Ａに対する改竄検知は、Ａの署名情報２２Ａを用いた第１の確認段階で行われるとともに、秘匿情報２３Ａ''を用いた第２の確認段階でも重ねて行われることになる。
これまで述べてきた実施形態では、第２の確認段階の処理を、署名情報の改竄検知を行うための処理として捉えてきたが、第２の確認段階の処理は、上述したとおり、アプリケーションパッケージ２１Ａに対する改竄検知にも利用することが可能である。
したがって、第２の確認段階の処理を、署名情報の改竄検知ではなく、アプリケーションパッケージ２１Ａに対する改竄検知のみに利用するのであれば、秘匿化対象データＣには、必ずしもプログラム提供者Ａの第２の鍵Ｋ（ａ２）が含まれている必要はない。たとえば、アプリケーションパッケージ２１Ａの部分のみを秘匿化対象データＣに設定して、秘匿情報２３Ａ'''を作成した場合、第２の確認段階では、Ａの署名情報２２Ａに対する改竄検知を行うことはできないが、アプリケーションパッケージ２１Ａに対する改竄検知を行うことは可能である。
結局、本発明の基本的な技術思想は、アプリケーションプログラムの改竄を検知する方法として捉えることが可能である。この改竄検知方法は、コンピュータが、アプリケーションプログラム１０Ａ（これまで述べてきた実施形態の場合は、パッケージ化された状態のアプリケーションパッケージ２１Ａ）と、署名情報２２Ａと、秘匿情報２３Ａ（上述した各バリエーションの場合は、２３Ａ′，２３Ａ''，２３Ａ'''）とを含むデータファイルを入力する入力段階と、コンピュータが、当該アプリケーションプログラム１０Ａが改竄されているか否かを判定する判定段階と、を有する。
ここで、署名情報２２Ａは、アプリケーションプログラム１０Ａ（もしくは、アプリケーションパッケージ２１Ａ）を署名対象データＤとする電子署名処理によって得られた情報であり、秘匿情報２３Ａ（もしくは、２３Ａ′，２３Ａ''，２３Ａ'''）は、当該アプリケーションプログラム１０Ａ（もしくは、アプリケーションパッケージ２１Ａ）および署名情報２２Ａを構成するデータの中の所定部分を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対する秘匿化処理を施して得られた情報ということになる。
そして、判定段階は、署名情報２２Ａに基づいて改竄の有無を確認する第１の確認段階と、秘匿情報２３Ａ（もしくは、２３Ａ′，２３Ａ''，２３Ａ'''）に基づいて改竄の有無を確認する第２の確認段階と、を有しており、アプリケーションプログラム１０Ａには、秘匿化処理で行われた処理プロセスを勘案して秘匿化対象データＣに対する秘匿情報の正当性を確認する改竄チェックルーチンが含まれており、この改竄チェックルーチンを実行することにより第２の確認段階が行われることになる。
これまで述べてきた実施例は、このような改竄検知方法をアプリケーションプログラムの配布実行方法に組み込んだものであり、プログラム提供者の第２の鍵Ｋ（ａ２）を含む所定部分を秘匿化対象データＣとして用い、ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータによって、第１の確認段階をＯＳプログラムに基づいて実行し、第２の確認段階をアプリケーションプログラム内の改竄チェックルーチンに基づいて実行するようにした例ということになる。
＜＜＜ §６．秘匿化処理の具体的な実施形態 ＞＞＞
ここでは、本発明における秘匿情報作成段階（図７のステップＳ３）で行われる秘匿化処理の具体的な実施形態を述べる。図５に示すように、本発明における秘匿情報作成段階では、秘匿化対象データＣに対して、第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理が行われ、秘匿情報２３Ａが作成される。ここで、秘匿情報２３Ａは、秘匿化対象データＣおよび第２の特定鍵Ｋ（ｓ２）が与えられれば一義的に定まる何らかのデータであり、改竄チェックルーチンによって実行される第１の特定鍵Ｋ（ｓ１）を用いた所定のチェック処理によって、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認されることになる。
秘匿化対象データＣを秘匿化して秘匿情報２３Ａを作成するには、第２の特定鍵Ｋ（ｓ２）が必要である。したがって、第２の特定鍵Ｋ（ｓ２）を秘密に管理していれば、クラッカーＸは秘匿情報２３Ａを生成することができない。また、秘匿情報２３Ａは、文字通り「元の秘匿化対象データＣを秘匿化」した情報になっており、秘匿情報２３Ａだけを用いて、元の秘匿化対象データＣを復元することはできない。以下、このような性質を有する秘匿情報２３Ａを作成するための具体的な秘匿化処理の方法を述べる。
なお、以下の説明は、§３で述べた基本的な実施形態と同様に、Ａの署名情報２２Ａを秘匿化対象データＣに設定した例（図５の例）についてのものであるが、もちろん、以下に述べる秘匿化処理の具体的な処理方法は、§５で述べたように、秘匿化対象データＣについて様々な設定を行うバリエーション（たとえば、図９や図１０の例）についても有効である。
＜６−１：暗号化処理＞
本発明における秘匿化処理に適した第１の処理は、暗号化処理である。秘匿化処理として暗号化処理を利用する場合、秘匿化対象データＣと秘匿情報２３Ａとの関係は、前者を暗号化することにより後者が得られ、後者を復号することにより前者が得られる、という関係になる。
このような暗号化および復号を行うには、公開鍵暗号方式を利用するのが好ましい。公開鍵暗号方式では、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵が用いられる。したがって、秘匿情報２３Ａは、秘匿化対象データＣを一方の鍵を用いて暗号化することにより得られることになり、改竄チェックルーチンＦは、この秘匿情報２３Ａを他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイル２０Ａから抽出した秘匿化対象データＣとが一致していた場合に改竄なしとの確認を行うことになる。
図１１は、図５に示す配布方法における秘匿情報２３Ａとして、暗号化された情報を用いる具体的実施例を示すブロック図である。この実施例では、プログラム提供者Ａが配布用ファイル２０Ａを配布する際に、プログラム保証者Ｇの助力を受けることになる。プログラム保証者Ｇは、公的機関であってもよいし、民間企業であってもよいが、社会的に信用があり、安全に鍵を管理する能力をもった団体がその役割を担うようにするのが好ましい。
上述したとおり、秘匿化処理として、公開鍵暗号方式を利用した暗号化処理を採用する場合、図５に示す第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用いることになる。図１１に示す例は、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１）を第１の特定鍵Ｋ（ｓ１）として用い、プログラム保証者Ｇの第２の鍵Ｋ（ｇ２）を第２の特定鍵Ｋ（ｓ２）として用いた例である。より具体的には、第１の鍵Ｋ（ｇ１）としては、プログラム保証者Ｇの公開鍵を用い、第２の鍵Ｋ（ｇ２）としては、プログラム保証者Ｇの秘密鍵を用いればよい。もっとも、公開鍵と秘密鍵とを入れ替えて用いても、本発明を実施することは可能である。
プログラム保証者Ｇは、予め、自分の第１の鍵Ｋ（ｇ１）を内蔵した改竄チェックルーチンＦを作成しておき、この改竄チェックルーチンＦと、自分の第２の鍵Ｋ（ｇ２）とを記録した媒体を、プログラム提供者Ａに貸し与えればよい。そうすれば、プログラム提供者Ａは、この媒体を利用して、配布用ファイル２０Ａを作成することができる。したがって、ここに示す実施形態では、Ａの署名情報２２Ａは、プログラム提供者Ａが、自分自身の鍵を用いてアプリケーションパッケージ２１Ａの内容を保証するために付加する情報としての役割を果たし、秘匿情報２３Ａは、プログラム保証者Ｇが、自分自身の鍵を用いてＡの署名情報２２Ａの内容を保証するために付加する情報としての役割を果たすことになる。
プログラム提供者Ａは、まず、従来と同様の方法で、図１の上段に示すようなアプリケーションプログラム１０を作成する。続いて、プログラム保証者Ｇから借り受けた媒体から、改竄チェックルーチンＦを読み出し、これをサブルーチン群１３に付加することにより、図１１の上段に示すようなサブルーチン群１３Ａを作成する。また、プログラム本体部１１に、改竄チェックルーチンＦを呼び出すためのサブルーチンコール命令と、この改竄チェックルーチンＦから返された実行結果に基づいて、プログラムの実行を続行するか中止する処理プログラム（「改竄なし」の実行結果が返された場合には、プログラムの実行を続行し、「改竄あり」の実行結果が返された場合には、プログラムの実行を中止するプログラム）とを追加することにより、プログラム本体部１１Ａを作成する。
このようなプロセスを経れば、図１１の上段に示すようなアプリケーションプログラム１０Ａを作成できる。このアプリケーションプログラム１０Ａには、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１）を含む改竄チェックルーチンＦが組み込まれていることになる。こうしてアプリケーションプログラム１０Ａが用意できたら、これを従来の方法と同様にパッケージ化し（ＡＰＫファイル作成用の専用プログラムを用いればよい）、アプリケーションパッケージ２１Ａを作成する（図７のステップＳ１のパッケージ化段階）。次に、プログラム提供者Ａは、このアプリケーションパッケージ２１Ａを署名対象データＤとして、自分の第１の鍵Ｋ（ａ１）を用いた電子署名処理を行い、Ａの署名情報２２Ａを作成する（図７のステップＳ２の署名情報作成段階）。
続いて、今度は、プログラム保証者Ｇから借り受けた媒体から、Ｇの第２の鍵Ｋ（ｇ２）を読み出し、Ａの署名情報２２Ａを秘匿化対象データＣとして、Ｇの第２の鍵Ｋ（ｇ２）を用いた秘匿化処理を行い、秘匿情報２３Ａを作成する（図７のステップＳ３の秘匿情報作成段階）。この図１１に示す実施例の場合、秘匿化処理として暗号化処理を採用しているため、秘匿情報作成段階では、第２の特定鍵（すなわち、プログラム保証者Ｇの第２の鍵Ｋ（ｇ２））を用いて、秘匿化対象データＣに対する暗号化処理を施して秘匿情報２３Ａが作成される。
最後に、アプリケーションパッケージ２１Ａ、Ａの署名情報２２Ａ、秘匿情報２３Ａをまとめれば、配布用ファイル２０Ａ（ＡＰＫファイル）を作成することができる（図７のステップＳ４の配布用ファイル作成段階）。そこで、これをＷｅｂサーバや物理的媒体に出力して（図７のステップＳ５のファイル出力段階）、任意の方法で配布すればよい。
一方、アプリケーション実行用コンピュータ（Android端末）は、このような方法で作成された配布用ファイル２０Ａ（ＡＰＫファイル）を入手し（図７のステップＳ６のファイル入力段階）、これを実行することになるが、まず、ＯＳプログラムの機能により署名情報２２Ａの正当性が確認され（図７のステップＳ７の第１の確認段階）、続いて、当該配布用ファイル２０Ａに組み込まれている改竄チェックルーチンＦの機能により秘匿情報２３Ａの正当性が確認される（図７のステップＳ９の第２の確認段階）。
図１２は、図１１に示す配布用ファイル２０Ａについて、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を示すブロック図である。
まず、署名情報２２Ａの正当性の確認（第１の確認段階）は、既に述べたように、次のようにして行われる。はじめに、署名情報２２Ａから署名値Ｓ（Ａ）およびＡの第２の鍵Ｋ（ａ２）を抽出し、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことにより、ハッシュ値Ｈ１を得る。次に、アプリケーションパッケージ２１Ａ（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行い、ハッシュ値Ｈ２を求める処理を行う。そして、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行えば、第１の確認段階は終了する。
一方、秘匿情報２３Ａの正当性の確認（第２の確認段階）は、公開鍵暗号方式の基本原理を利用することによって行われる。すなわち、ここに示す実施例では、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１）と第２の鍵Ｋ（ｇ２）とは、公開鍵暗号方式における一対の鍵を構成しており、第２の鍵Ｋ（ｇ２）を用いて暗号化したデータは、第１の鍵Ｋ（ｇ１）を用いて復号することができる。そこで、改竄チェックルーチンＦは、次のような方法で第２の確認段階の処理を実行する。
はじめに、図１２に示すように、改竄チェックルーチンＦに内蔵されているプログラム保証者Ｇの第１の鍵Ｋ（ｇ１）を用いて、入力した配布用ファイル２０Ａから抽出した秘匿情報２３Ａを復号し、元の秘匿化対象データＣを得る。続いて、この復号によって得られた秘匿化対象データＣと、入力した配布用ファイル２０Ａから抽出した秘匿化対象データＣ（この例の場合は、Ａの署名情報２２Ａ）とが一致していた場合に、秘匿情報２３Ａが正当である旨の確認を行えばよい。
結局、ここで述べた方法は、秘匿化対象データＣを暗号化という手法で秘匿化して、秘匿情報２３Ａという形で配布用ファイル２０Ａに付加して配布し、アプリケーション実行用コンピュータ（Android端末）では、秘匿情報２３Ａを復号した結果が秘匿化対象データＣに一致することを確認することにより、改竄の有無を検知する方法ということができる。クラッカーＸは、暗号化に用いられたプログラム保証者Ｇの第２の鍵Ｋ（ｇ２）を入手することができないため、秘匿情報２３Ａの改竄を行うことはできない。
＜６−２：ダイジェスト化処理＞
本発明における秘匿化処理に適した第２の処理は、ダイジェスト化処理である。秘匿化処理としてダイジェスト化処理を利用する場合、秘匿化対象データＣと秘匿情報２３Ａとの関係は、前者をダイジェスト化することにより後者が得られる、という関係になる。
ここで、ダイジェスト化とは、元の情報から情報量を減らす演算処理を行って、元の情報に基づいて一義的に決定できる別な情報を得る処理である。具体的には、元の情報を構成するデータに対して、何らかの一方向性関数を作用させる処理を行えばよい。この場合、秘匿情報２３Ａは、秘匿化対象データＣに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して得られることになり、改竄チェックルーチンＦは、入力段階で入力したデータファイル２０Ａから抽出した秘匿化対象データＣに対して、上記特定鍵と同一の鍵を用いた上記ダイジェスト化処理と同一の処理を施して得られる情報が、入力段階で入力したデータファイル２０Ａに含まれている秘匿情報２０Ａと一致していた場合に改竄なしとの確認を行うことになる。
図１３は、図５に示す配布方法における秘匿情報２３Ａとして、ダイジェスト化された情報を用いる具体的実施例を示すブロック図である。この実施例でも、プログラム提供者Ａが配布用ファイル２０Ａを配布する際に、プログラム保証者Ｇの助力を受けることになる。ただ、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）としては、同一の共通特定鍵Ｋ（ｓ０）を用いる。
プログラム保証者Ｇは、予め、自己が秘密状態で管理している共通特定鍵Ｋ（ｓ０）を内蔵した改竄チェックルーチンＦを作成しておき、この改竄チェックルーチンＦと、当該共通特定鍵Ｋ（ｓ０）とを記録した媒体を、プログラム提供者Ａに貸し与えればよい。そうすれば、プログラム提供者Ａは、この媒体を利用して、配布用ファイル２０Ａを作成することができる。
具体的には、プログラム提供者Ａは、上述した暗号化処理を採用する実施例と同様に、プログラム保証者Ｇから借り受けた媒体を利用して、図１３の上段に示すようなアプリケーションプログラム１０Ａを作成する。このアプリケーションプログラム１０Ａには、プログラム保証者Ｇの共通特定鍵Ｋ（ｓ０）を含む改竄チェックルーチンＦが組み込まれていることになる。
こうしてアプリケーションプログラム１０Ａが用意できたら、これをパッケージ化し、アプリケーションパッケージ２１Ａを作成する。そして、プログラム提供者Ａは、このアプリケーションパッケージ２１Ａを署名対象データＤとして、自分の第１の鍵Ｋ（ａ１）を用いた電子署名処理を行い、Ａの署名情報２２Ａを作成する。
続いて、プログラム保証者Ｇから借り受けた媒体から、共通特定鍵Ｋ（ｓ０）を読み出し、Ａの署名情報２２Ａを秘匿化対象データＣとして、共通特定鍵Ｋ（ｓ０）を用いた秘匿化処理を行い、秘匿情報２３Ａを作成する。この図１３に示す実施例の場合、秘匿化処理としてダイジェスト化処理を採用しているため、秘匿情報作成段階では、共通特定鍵Ｋ（ｓ０）を用いて、秘匿化対象データＣに対するダイジェスト化処理を施して秘匿情報２３Ａが作成される。
ダイジェスト化処理は、前述したように、秘匿化対象データＣに対して、共通特定鍵Ｋ（ｓ０）をパラメータとして用いた一方向性関数を作用させる処理である。具体的には、共通特定鍵Ｋ（ｓ０）をパラメータとして用いたハッシュ関数を作用させる処理を行い、得られるハッシュ値を秘匿情報２３Ａとすればよい。
最後に、アプリケーションパッケージ２１Ａ、Ａの署名情報２２Ａ、秘匿情報２３Ａをまとめて配布用ファイル２０Ａ（ＡＰＫファイル）を作成し、これを配布すればよい。
一方、アプリケーション実行用コンピュータ（Android端末）は、このような方法で作成された配布用ファイル２０Ａ（ＡＰＫファイル）について、図１４のブロック図に示す方法を行い、署名情報２２Ａの正当性および秘匿情報２３Ａの正当性を確認する処理を行う。
ここで、署名情報２２Ａの正当性の確認（第１の確認段階）は、これまで述べてきた実施例と全く同様である。すなわち、署名値Ｓ（Ａ）に対してＡの第２の鍵Ｋ（ａ２）を用いた復号処理を行うことによりハッシュ値Ｈ１を得る処理を行うとともに、アプリケーションパッケージ２１Ａ（署名対象データＤ）に対して、ハッシュ関数ＨＡＳＨを作用させた不可逆変換を行ってハッシュ値Ｈ２を得る処理を行い、ハッシュ値Ｈ１とハッシュ値Ｈ２とが一致するか否かを確認する処理を行うことになる。
一方、秘匿情報２３Ａの正当性の確認（第２の確認段階）は、プログラム提供者Ａが秘匿情報２３Ａを作成する際に行った処理と全く同じ処理を実行し、同じ結果が得られるか否かを確認することによって行われる。
具体的には、まず、入力した配布用ファイル２０Ａから秘匿化対象データＣ（この例の場合、Ａの署名情報２２Ａ）および改竄チェックルーチンＦに内蔵されている共通特定鍵Ｋ（ｓ０）を抽出する。そして、抽出した秘匿化対象データＣに対して、抽出した共通特定鍵Ｋ（ｓ０）を用いたダイジェスト化処理（配布プロセスの秘匿情報作成段階で行われた処理と同一の処理）を実行する。すなわち、配布プロセスで行ったように、共通特定鍵Ｋ（ｓ０）をパラメータとして用いたハッシュ関数を作用させる処理を行い、ハッシュ値を得るようにすればよい。このダイジェスト化処理によって得られたハッシュ値が、入力した配布用ファイル２０Ａに含まれている秘匿情報２３Ａと一致していた場合に、当該秘匿情報２３Ａが正当である旨の確認を行うことになる。
結局、ここで述べた方法は、秘匿化対象データＣをダイジェスト化という手法で秘匿化して、秘匿情報２３Ａという形で配布用ファイル２０Ａに付加して配布し、アプリケーション実行用コンピュータ（Android端末）では、同じ手法で秘匿化対象データＣをダイジェスト化して、付加されていた秘匿情報２３Ａに一致することを確認することにより、改竄の有無を検知する方法ということができる。クラッカーＸは、ダイジェスト化に用いられたプログラム保証者Ｇの共通特定鍵Ｋ（ｓ０）を入手することができないため、秘匿情報２３Ａの改竄を行うことはできない。
秘匿化処理として暗号化を採用した場合、得られる秘匿情報には、復号によって元の秘匿化対象データＣを復元するために必要な情報がそのまま含まれている。したがって、元の秘匿化対象データＣの情報量が多ければ、得られる秘匿情報の情報量も多くなる。このため、たとえば、図１０に示す例のように、アプリケーションパッケージ２１ＡおよびＡの署名情報２２Ａをそっくり含むデータを秘匿化対象データＣとして用いる場合は、得られる秘匿情報２３Ａ''のデータ容量はかなり大きくなり、配布用ファイル２０Ａ''の肥大化を招くことになる。
これに対して、秘匿化処理としてダイジェスト化を採用した場合、得られる秘匿情報から元の秘匿化対象データＣを復元する必要はないため、秘匿情報の情報量を大幅に削減することが可能である。このため、たとえば、図１０に示す例のように、かなり大きなデータ容量をもつ秘匿化対象データＣを設定した場合でも、ダイジェスト化を採用すれば、得られる秘匿情報２３Ａ''のデータ容量を低く抑えることができ、配布用ファイル２０Ａ''の肥大化を防ぐことができる。
＜６−３：その他の秘匿化処理＞
以上、本発明における秘匿化処理の具体的な実施形態として、暗号化処理とダイジェスト化処理を例示したが、本発明を実施するにあたり、秘匿化処理の具体的な形態は、これら２つの処理に限定されるものではない。
本発明における秘匿化処理は、互いに特別な関係をもった第１の特定鍵Ｋ（ｓ１）と第２の特定鍵Ｋ（ｓ２）とを用いることを前提とした処理であり、第２の特定鍵Ｋ（ｓ２）を用いた何らかの演算処理によって、元の秘匿化対象データＣに対して一義的に秘匿情報２３Ａを決定することができ、しかも第１の特定鍵Ｋ（ｓ１）を用いることによって、秘匿化対象データＣに対する秘匿情報２３Ａの正当性が確認できる（すなわち、改竄を受けていないことを確認できる）、という条件を満たす処理であれば、どのような処理を秘匿化処理として採用してもかまわない。
前述した暗号化処理では、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、「公開鍵暗号方式に用いる一対の鍵」という互いに特別な関係をもった鍵がが採用されることになる。また、前述したダイジェスト化処理では、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、「同一の共通特定鍵Ｋ（ｓ０）である」という互いに特別な関係をもった鍵が採用されることになる。
＜＜＜ §７．配布用ファイル作成装置 ＞＞＞
次に、本発明に係る配布用ファイル作成装置の基本構成および動作を、図１５に示す実施形態に基づいて説明する。図１５にブロック図を示す装置は、アプリケーションプログラムの配布用ファイルを作成する装置であり、図７に示す配布プロセス（ステップＳ１〜Ｓ５）を実行する機能を有する。ここでは、プログラム提供者Ａが、この装置を用いて、Android端末に配布するための配布用ファイル（ＡＰＫファイル）を作成する場合を例にとって、装置の構成および動作を説明する。
図１５のブロック図において、矩形のブロックは、この配布用ファイル作成装置の基本構成要素を示し、楕円のブロックは、これらの基本構成要素によって取り扱われる情報（プログラム、データ、ファイル）を示している。なお、楕円のブロックで示す個々の情報については、これまでの説明で用いてきた符号と同一の符号を付してある。
図示のとおり、この作成装置は、３つの格納ユニット１１０，１２０，１３０を有している。アプリケーションプログラム格納ユニット１１０は、配布対象となるアプリケーションプログラム１０を格納するためのユニットである。ここで言う配布対象となるアプリケーションプログラム１０とは、図１の上段に示す形態のものに対応し、パッケージ化や本発明に特有の処理を行う前の状態のアプリケーションプログラムを指している。
既に述べたとおり、Android仕様によると、このアプリケーションプログラム１０は、プログラム本体部１１と、画像および文字列を含むリソースデータ１２と、プログラム本体部１１から呼び出されるサブルーチン群１３と、ＸＭＬ形式のデータからなる補助ファイル（マニフェストファイル）１４と、を含んでいる。
一方、改竄チェックルーチン格納ユニット１２０は、第１の特定鍵Ｋ（ｓ１）を内蔵した改竄チェックルーチンＦを格納したユニットであり、鍵格納ユニット１３０は、第２の特定鍵Ｋ（ｓ２）、プログラム提供者Ａの第１の鍵Ｋ（ａ１）、プログラム提供者Ａの第２の鍵Ｋ（ａ２）を格納したユニットである。もちろん、本願における「鍵」とは、特定の者によって管理される特定の文字やコードの配列からなるデータであり、鍵格納ユニット１３０は、そのようなデータを記録する機能をもった構成要素であれば、どのような形態のものでもかまわない。
ここで、プログラム提供者Ａの第１の鍵Ｋ（ａ１）および第２の鍵Ｋ（ａ２）は、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵であり、より具体的には、プログラム提供者Ａ自身の公開鍵および秘密鍵（公開鍵暗号方式に用いる一対の鍵）である。これに対して、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）は、一方の鍵を用いて秘匿化処理を施したデータの正当性を他方の鍵を用いて確認できる性質をもった一対もしくは同一の鍵であり、プログラム提供者Ａ自身が管理する鍵でもよいが、§６で述べたように、プログラム保証者Ｇが介在する実施形態を採用する場合は、当該プログラム保証者Ｇが管理する鍵ということになる。
改竄チェックルーチン付加ユニット１４０は、アプリケーションプログラム格納ユニット１１０に格納されているアプリケーションプログラム１０に改竄チェックルーチン格納ユニット１２０に格納されている改竄チェックルーチンＦを付加する処理を行うユニットである。すなわち、図１の上段に示すアプリケーションプログラム１０内のサブルーチン群１３に、改竄チェックルーチンＦを付加して、図５の上段に示すサブルーチン群１３Ａを作成する処理を実行する。
一方、プログラム提供者Ａは、アプリケーションプログラム１０に、この改竄チェックルーチンＦを呼び出すためのサブルーチンコール命令と、この改竄チェックルーチンＦから返された実行結果に基づいて、プログラムの実行を続行するか中止する続行中止処理プログラムとを追加することにより、図５の上段に示すプログラム本体部１１Ａを作成する。
なお、アプリケーションプログラム１０をアプリケーションプログラム１０Ａに変更する処理は、プログラム提供者Ａによる手作業ではなく、改竄チェックルーチン付加ユニット１４０による自動作業によって行うようにしてもよい。具体的には、改竄チェックルーチン付加ユニット１４０内に、予め、上述したサブルーチンコール命令および続行中止処理プログラムを用意しておけば、これらをアプリケーションプログラム１０の所定箇所（たとえば、プログラムの先頭や、Android仕様によって必須の初期設定処理が終了した直後など）に自動的に挿入する機能を、ユニット１４０自身にもたせることができる。そうすれば、アプリケーションプログラム１０をアプリケーションプログラム１０Ａに変更する処理は、すべて改竄チェックルーチン付加ユニット１４０による自動作業によって行うことができるようになる。
もちろん、アプリケーションプログラム格納ユニット１１０内に、プログラム本体部１１Ａ（上述したサブルーチンコール命令および続行中止処理プログラムが組み込まれたプログラム）を含むアプリケーションプログラムを用意しておくようにすれば、改竄チェックルーチン付加ユニット１４０は、サブルーチン群１３に、改竄チェックルーチンＦを付加してサブルーチン群１３Ａを作成する処理を行うだけでよい。
パッケージ化処理ユニット１５０は、改竄チェックルーチンＦが付加されたアプリケーションプログラム１０Ａに対して、少なくとも圧縮処理を含むパッケージ化処理を施し、アプリケーションパッケージ２１Ａを作成する処理を行う。Android仕様によれば、ＺＩＰ方式の圧縮処理を含むパッケージ化処理が実行されることになる。
署名情報作成ユニット１６０は、こうして作成されたアプリケーションパッケージ２１Ａを署名対象データとして、プログラム提供者Ａの第１の鍵Ｋ（ａ１）を用いた暗号化を利用した電子署名処理を行って署名値Ｓ（Ａ）を生成し、この署名値Ｓ（Ａ）とプログラム提供者の第２の鍵Ｋ（ａ２）とを含むＡの署名情報２２Ａを作成する。
一方、秘匿情報作成ユニット１７０は、アプリケーションパッケージ２１Ａおよび署名情報２２Ａを構成するデータの中から、プログラム提供者Ａの第２の鍵を含む所定部分を秘匿化対象データＣとして抽出し、抽出した秘匿化対象データＣに対して第２の特定鍵Ｋ（ｓ２）を用いた秘匿化処理を施して秘匿情報２３Ａを作成する。
図５に示す実施形態の場合、Ａの署名情報２２Ａを秘匿化対象データＣとして設定しているため、図１５に示すように、秘匿情報作成ユニット１７０は、署名情報作成ユニット１６０が作成した署名情報２２Ａを構成するデータ全体を秘匿化対象データＣとして、秘匿情報２３Ａを作成する処理を行うことになる。もちろん、図９に示すバリエーションを採用する場合は、秘匿情報作成ユニット１７０は、署名情報２２Ａに含まれるプログラム提供者Ａの第２の鍵Ｋ（ａ２）を構成するデータ部分だけを秘匿化対象データＣとして用いることになり、図１０に示すバリエーションを採用する場合は、秘匿情報作成ユニット１７０は、アプリケーションパッケージ２１Ａと署名情報２２Ａとの双方を構成するデータ全体を秘匿化対象データＣとして用いることになる。
配布用ファイル作成ユニット１８０は、アプリケーションパッケージ２１Ａと、署名情報２２Ａと、秘匿情報２３Ａと、をまとめることにより、図５の下段に示すような配布用ファイル２０Ａを作成する処理を行う。Android仕様に基づくのであれば、ＡＰＫ形式のフォーマットをもった配布用ファイルを作成する処理が行われることになる。前述したとおり、ＺＩＰ方式の圧縮フォーマットを採用したＡＰＫファイルには、任意のコメント文が記載可能なコメント領域が設けられているので、秘匿情報２３Ａを、このコメント領域に記録するようにすれば、配布用ファイル２０Ａは、Android仕様に合致したＡＰＫファイルとしての条件を満たすことになる。この配布用ファイル２０Ａは、デジタルデータとしてデータ記録媒体に格納した状態で配布することもできるし、インターネットなどのネットワークを介してデジタルデータの形のまま配布することもできる。
こうして配布された配布用ファイル（ＡＰＫファイル）２０Ａには、自分自身が改竄されているか否かを、付加された秘匿情報２３Ａを利用して判定する改竄チェックルーチンＦが含まれており、アプリケーション実行用コンピュータにおいて、この改竄チェックルーチンＦを実行することにより改竄検知を行うことができる。
既に述べたとおり、改竄チェックルーチンＦは、配布用ファイル２０Ａから秘匿化対象データＣおよび秘匿情報２３Ａを抽出し、秘匿化対象データＣに対する秘匿情報２３Ａの正当性を、内蔵している第１の特定鍵Ｋ（ｓ１）を用いて確認し、正当性が確認できない場合には、アプリケーションプログラムが改竄された旨の判定を行う機能を有している。そして、アプリケーションプログラムが改竄された旨の判定が行われた場合には、当該アプリケーションプログラムの以後の処理の実行を中止させる処理を行う機能も有している。
秘匿情報作成ユニット１７０が秘匿情報２３Ａを作成する際に行う秘匿化処理の具体的な方法としては、§６−１で述べた暗号化処理や、§６−２で述べたダイジェスト化処理を採用すればよい。
暗号化処理を採用する場合は、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として、一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵（公開鍵暗号方式に用いる一対の鍵）を用意し、秘匿情報作成ユニット１７０が、第２の特定鍵Ｋ（ｓ２）を用いて、秘匿化対象データＣに対する暗号化処理を施して秘匿情報２３Ａを作成すればよい。
プログラム保証者Ｇを介在させる実施形態の場合、第１の特定鍵Ｋ（ｓ１）としてプログラム保証者Ｇの第１の鍵Ｋ（ｇ１）（たとえば、公開鍵）を用い、第２の特定鍵Ｋ（ｓ２）としてプログラム保証者Ｇの第２の鍵Ｋ（ｇ２）（たとえば、秘密鍵）を用い、Ｇの第２の鍵Ｋ（ｇ２）を用いて暗号化したデータを、Ｇの第１の鍵Ｋ（ｇ１）を用いて復号できるようにしておけばよい。秘匿情報作成ユニット１７０は、Ｇの第２の鍵Ｋ（ｓ２）を用いて、秘匿化対象データＣに対する暗号化処理を施して秘匿情報２３Ａを作成することになる。
一方、改竄チェックルーチン格納ユニット１２０には、第１の特定鍵Ｋ（ｓ１）（すなわち、プログラム保証者Ｇの第１の鍵Ｋ（ｇ１））を用いて秘匿情報２３Ａを復号し、この復号によって得られた秘匿化対象データＣと、配布用ファイル２０Ａから抽出した秘匿化対象データＣとが一致していた場合に、秘匿情報２３Ａが正当である旨の確認を行う機能をもった改竄チェックルーチンＦを用意しておけばよい。
これに対して、ダイジェスト化処理を採用する場合は、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）として同一の共通特定鍵Ｋ（ｓ０）を用いるようにし、秘匿情報作成ユニット１７０が、秘匿化対象データＣに対して、共通特定鍵Ｋ（ｓ０）をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して秘匿情報２３Ａを作成すればよい。具体的には、共通特定鍵Ｋ（ｓ０）をパラメータとして用いたハッシュ関数を作用させるダイジェスト化処理を施して得られるハッシュ値を秘匿情報２３Ａとすればよい。
この場合、改竄チェックルーチン格納ユニット１２０には、配布用ファイル２０Ａから秘匿化対象データＣおよび共通特定鍵Ｋ（ｓ０）を抽出し、抽出した秘匿化対象データＣに対して、抽出した共通特定鍵Ｋ（ｓ０）を用いたダイジェスト化処理（秘匿情報作成ユニット１７０で実行されたダイジェスト化処理と全く同じ処理）を施して得られる情報が、配布用ファイル２０Ａに含まれている秘匿情報２３Ａと一致していた場合に、当該秘匿情報２３Ａが正当である旨の確認を行う機能をもった改竄チェックルーチンＦを用意しておけばよい。
なお、図１５に示す配布用ファイル作成装置は、実際には、汎用のコンピュータに専用のプログラムやデータを組み込むことによって構成されるものである。この場合、図１５に矩形ブロックで示す各構成要素は、必ずしも１台の同一コンピュータによって構成する必要はなく、各構成要素を、互いにネットワークで接続可能な複数台のコンピュータに分散して配置するようにしてもかまわない。
＜＜＜ §８．その他の変形例 ＞＞＞
最後に、これまで述べてきた種々の実施形態について適用可能な変形例をいくつか述べておく。
＜８−１：改竄検知時の中止処理＞
図５に示す基本的な実施形態の場合、アプリケーションプログラム１０Ａには、プログラム本体部１１Ａと、このプログラム本体部１１Ａから呼び出されるサブルーチン群１３Ａと、が含まれており、サブルーチン群１３Ａには、改竄チェックルーチンＦが含まれている。
ここで、この改竄チェックルーチンＦは、プログラム本体部１１Ａから呼び出されたときに、秘匿化対象データＣに対する秘匿情報２３Ａの正当性を確認する第２の確認段階を実行して、その実行結果をサブルーチンの実行結果としてプログラム本体部１１Ａへ返す機能を有している。
一方、プログラム本体部１１Ａには、改竄チェックルーチンＦをコールするサブルーチンコール命令と、改竄チェックルーチンＦから返された実行結果に応じて、以後の処理の続行もしくは中止を行う続行中止プログラムと、が組み込まれている。この続行中止プログラムは、改竄チェックルーチンＦから返された実行結果が肯定的な結果であった場合には以後の命令群を引き続き実行し、否定的な結果であった場合には以後の命令群の実行を中止する。
このように、これまで述べた実施形態では、改竄チェックルーチンＦは、あくまでも秘匿情報２３Ａの正当性を確認する第２の確認段階を実行し、その結果をプログラム本体部１１Ａに報告する機能しか有していなかった。別言すれば、第２の確認段階において改竄が検知された場合、改竄チェックルーチンＦは、否定的な実行結果をプログラム本体部１１Ａに返す処理を行い、プログラム本体部１１Ａ内の続行中止プログラムによって、以後の命令群の実行が中止されることになる。すなわち、アプリケーションプログラムの中止処理は、あくまでもプログラム本体部１１Ａの機能として実行されることになる（具体的には、プログラム本体部１１Ａ内のプログラムによって、アプリケーションを終了する処理が行われ、制御がＯＳプログラムに返されることになる）。
一般に、サブルーチン群１３Ａを構成するサブルーチンプログラムは、プログラム本体部１１Ａから呼び出されて実行される性質のプログラムであり、サブルーチンの実行が完了すれば、元のプログラム本体部１１Ａ内の命令群が引き続き実行されることになる。したがって、通常は、プログラム本体部１１Ａからサブルーチンが呼び出されると、ＣＰＵの実行対象コードは、一旦、サブルーチン内のコードに移り、サブルーチンが終了した時点で、再びプログラム本体部１１Ａ内のコードに戻ることになる。これまで述べた実施形態は、このような一般原則に基づいた処理であり、改竄チェックルーチンＦによって改竄が検知された場合も、プログラム本体部１１Ａによって、アプリケーションを終了する処理が行われることになる。
ただ、改竄が検知された場合のアプリケーション終了処理は、必ずしもプログラム本体部１１Ａによって行う必要はなく、改竄チェックルーチンＦによって行ってもかまわない。上述したように、一般原則に従えば、サブルーチンの処理が終了した場合には、当該サブルーチンを呼び出したプログラム本体部１１Ａに制御を戻すべきであるが、改竄チェックルーチンＦによって改竄が検知された場合は、いずれにしても当該アプリケーションを終了する必要があるので、制御をプログラム本体部１１Ａに戻すことなしに、改竄チェックルーチンＦ自身によって当該アプリケーションを終了する処理を行う運用を採ってもかまわない。
このような運用を採る場合、プログラム本体部１１Ａには、改竄チェックルーチンＦをコールするサブルーチンコール命令と、この改竄チェックルーチンＦから肯定的な結果が返された場合に、以後の命令群を引き続き実行するプログラムを組み込んでおき、改竄チェックルーチンＦには、第２の確認段階の実行結果が肯定的な結果であった場合には、当該結果をサブルーチンの実行結果としてプログラム本体部１１Ａに返す機能と、第２の確認段階の実行結果が否定的な結果であった場合には、当該アプリケーションプログラムの実行を中止する機能（アプリケーションを終了して、制御をＯＳプログラムに返す機能）とを組み込んでおけばよい。
なお、改竄チェックルーチンＦの実行は、できるだけ早く改竄検知を行うことができるように、できるだけ早い段階で行うのが好ましい。したがって、実用上は、プログラム本体部１１Ａには、アプリケーションプログラムの本来の機能を果たすための命令群の前に（たとえば、プログラム本体部１１Ａの先頭部分に）改竄チェックルーチンＦをコールするサブルーチンコール命令を組み込んでおくようにし、アプリケーションプログラムの本来の機能に関する命令群が実行される前に、改竄の検知が行われるようにするのが好ましい。
＜８−２：プログラム保証者Ｇによる貸与形態＞
§７では、プログラム保証者Ｇが介在する実施形態を述べた。このように、プログラム保証者Ｇが介在する場合は、第１の特定鍵Ｋ（ｓ１）および第２の特定鍵Ｋ（ｓ２）は、プログラム保証者Ｇから提供される鍵となり、改竄チェックルーチンＦも、プログラム保証者Ｇから提供されるプログラムになる。
この場合、プログラム保証者Ｇは、改竄チェックルーチンＦと、第２の特定鍵Ｋ（ｓ２）と、図１５に示す各ユニット１４０，１５０，１６０，１７０，１８０としての機能をコンピュータに実行させるためのプログラムと、を含むデジタルデータの記録媒体を、プログラム提供者Ａに貸し与えるようにすればよい。そうすれば、プログラム提供者Ａは、汎用のコンピュータに、この記録媒体に記録されているデータやプログラムをインストールすることにより、図１５に示す配布用ファイル作成装置を構成することができる（プログラム提供者Ａの第１の鍵Ｋ（ａ１）および第２の鍵Ｋ（ａ２）については、自分が管理している鍵を鍵格納ユニット１３０に組み込む必要がある）。
なお、第１の特定鍵Ｋ（ｓ１）を含む改竄チェックルーチンＦや、第２の特定鍵Ｋ（ｓ２）は、本来、プログラム保証者Ｇが秘密状態で管理すべき情報であるため、これらは、十分なセキュリティが確保された電子トークン（たとえば、ＩＣカードやＵＳＢメモリなど）に格納した状態でプログラム提供者Ａに貸与するようにし、プログラム提供者Ａによる直接アクセスができない状態にしておくのが好ましい。
＜８−３：プログラム提供者の識別コードの埋め込み＞
前述したように、プログラム保証者Ｇが介在する実施形態を採用する場合、プログラム保証者Ｇは、プログラム提供者Ａだけでなく、他のプログラム提供者Ｂ，Ｃ等に対しても同様のサービスを提供するのが一般的である。このような場合、各プログラム提供者Ａ，Ｂ，Ｃに貸し与える改竄チェックルーチンＦ内に、各プログラム提供者（コンテンツプロバイダー）の識別コードを埋め込んでおくようにするのが好ましい。
そうすれば、各プログラム提供者Ａ，Ｂ，Ｃが、汎用のコンピュータを用いて、それぞれ図１５に示すような配布用ファイル作成装置を構築した場合、改竄チェックルーチン格納ユニット１２０に格納されている改竄チェックルーチンＦに、プログラム提供者Ａ，Ｂ，Ｃの識別コードが埋め込まれることになるので、各プログラム提供者Ａ，Ｂ，Ｃが作成した配布用ファイル２０Ａに含まれている改竄チェックルーチンＦにも識別コードが埋め込まれた状態になり、配布用ファイル２０Ａを解析すれば、どのプログラム提供者が作成したファイルであるかを確認することができる。
たとえば、プログラム保証者Ｇが、プログラム提供者Ａ，Ｂ，Ｃに貸し与える改竄チェックルーチンＦに、それぞれプログラム提供者Ａ，Ｂ，Ｃの識別コードＩＤ（Ａ），ＩＤ（Ｂ），ＩＤ（Ｃ）を埋め込んでおくようにすれば（最も単純な埋め込み方法としては、改竄チェックルーチンＦのファイル名に識別コードＩＤ（Ａ），ＩＤ（Ｂ），ＩＤ（Ｃ）を含ませればよい）、個々の改竄チェックルーチンＦ（Ａ），Ｆ（Ｂ），Ｆ（Ｃ）は相互に区別することができるようになる。そうすれば、配布用ファイル２０Ａには、どのプログラム提供者に貸し与えた改竄チェックルーチンＦが含まれているのかを確認することができるので、万一、改竄チェックルーチンＦ自体が漏洩するような事態が生じても、責任の所在を明確にすることができるようになる。
＜８−４：第１および第２の確認段階の役割分担＞
これまで述べてきた実施形態は、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性を確認する第１の確認段階（アプリケーションパッケージ２１Ａが改竄されていないことを、署名情報２２Ａを利用して確認する段階）を、アプリケーション実行用のコンピュータのＯＳプログラムによって実行し、秘匿化対象データＣに対する秘匿情報２３Ａの正当性を確認する第２の確認段階（署名情報２２Ａが改竄されていないことを、秘匿情報２３Ａを利用して確認する段階）を、アプリケーションパッケージ２１Ａに含まれる改竄チェックプログラムによって実行する、という役割分担を行っている。
このような役割分担は、Android仕様のアプリケーションを配布して、Android端末においてこれを実行する環境では極めて有効である。すなわち、上記役割分担を行えば、本発明を実施する上で、Android端末側には何ら改変を加える必要はなく、配布対象となるＡＰＫファイルを図１５に示す装置で作成すれば足りる。
しかしながら、本発明の適用は、現在のAndroid仕様のアプリケーションの配布および実行に限定されるものではないので、上記役割分担は、本発明に必須のものではない。
たとえば、将来、Android仕様が変更になり、AndroidＯＳ自身に、第２の確認段階を実行するプログラムが組み込まれるようになれば、配布する個々のアプリケーションパッケージ２０Ａには、第１の特定鍵Ｋ（ｓ１）のみを組み込んでおけば足り、改竄チェックルーチンＦのその余の部分は組み込む必要はなくなる。この場合、第２の確認段階はＯＳプログラムによって実行されることになり、改竄が検知された場合のアプリケーションの中止処理も、ＯＳプログラムによって実行されることになる。別言すれば、第１の確認段階と第２の確認段階との双方が、ＯＳプログラムによって行われることになる。
逆に、将来、Android仕様が変更になり、現AndroidＯＳの機能から、第１の確認段階を行う処理機能が除外された場合には、第１の確認段階と第２の確認段階との双方を、アプリケーションプログラム側で行うようにすることも可能である。
＜８−５：秘匿情報の引き渡し方法の変形例＞
本発明に係るアプリケーションプログラムの配布実行方法では、まず、配布プロセスにおいて秘匿情報を作成し、続いて、実行プロセスにおいて、この秘匿情報を利用した改竄有無の判定を行うことになる。したがって、配布プロセスで作成した秘匿情報を、何らかの方法で実行プロセスに引き渡す必要がある。これまで述べてきた実施形態は、配布用ファイル作成段階において作成する配布用ファイル内に、作成した秘匿情報を組み込むことにより、配布用ファイルとともに秘匿情報の引き渡しが行われるようにしていた。
たとえば、図５に示す実施形態の場合、秘匿情報２３Ａは配布用ファイル２０Ａ内に組み込まれた状態で配布されることになり、図９に示す実施形態の場合、秘匿情報２３Ａ′は配布用ファイル２０Ａ′内に組み込まれた状態で配布されることになり、図１０に示す実施形態の場合、秘匿情報２３Ａ''は配布用ファイル２０Ａ''内に組み込まれた状態で配布されることになる。このように、秘匿情報を配布用ファイル内に組み込んでしまえば、アプリケーション実行用コンピュータは、配布用ファイルを入手した時点で、秘匿情報も併せて入手することが可能になる。
ただ、秘匿情報の引き渡し方法は、必ずしも配布用ファイル内に組み込む方法に限定されるものではない。ここでは、秘匿情報の引き渡し方法の変形例を述べておく。図１６は、図５に示す基本的な実施形態について、秘匿情報の引き渡し方法を変えた変形例を示すブロック図である。図の上段はプログラム提供者Ａによって実行される配布プロセスを示し、下段はユーザＵによって実行される実行プロセスを示している。この変形例の特徴は、配布プロセスで作成した秘匿情報２３Ａを、サーバ３０を介して実行プロセスに引き渡す方法を採る点である。
すなわち、図５に示す基本的な実施形態の場合、秘匿情報２３Ａは配布用ファイル２０Ａに組み込まれて配布されることになるが、図１６に示す変形例の場合、秘匿情報２３Ａはサーバ３０に格納され、その代わりに、この秘匿情報２３Ａの所在を示す所在情報２４Ａが配布用ファイル２０ＡＡに組み込まれて配布されることになる。図５に示す配布用ファイル２０Ａと図１６に示す配布用ファイル２０ＡＡとの相違は、前者の秘匿情報２３Ａが後者では所在情報２４Ａになっている点のみである。一般に、秘匿情報２３Ａのデータ容量が嵩むケースでは、秘匿情報２３Ａを配布用ファイル２０Ａに組み込んでしまうと、配布用ファイル２０Ａのデータ容量も嵩むことになる。このようなケースでは、図１６に示す変形例を採れば、秘匿情報２３Ａに比べてデータ容量の小さい所在情報２４Ａを組み込んて配布用ファイル２０ＡＡを作成することができるので、配布用ファイル２０ＡＡのデータ容量を抑えることができ便利である。
サーバ３０は、アプリケーション実行用コンピュータがネットワークを介してアクセス可能なサーバであれば、どのようなサーバであってもかまわない。ここに示す例では、インターネットに接続された任意のファイルサーバをサーバ３０として利用している。所在情報２４Ａは、サーバ３０およびその中における秘匿情報２３Ａの格納場所を特定する情報であり、具体的には、秘匿情報２３Ａの格納場所を示すＵＲＬを所在情報２４Ａとして用いればよい。結局、図１６に示す変形例の場合、プログラム提供者Ａは、所在情報２４Ａが組み込まれた配布用ファイル２０ＡＡを配布することになる。一方、ユーザＵは、この配布用ファイル２０ＡＡを入手することにより、所在情報２４Ａ（この例の場合は、秘匿情報２３Ａの格納場所を示すＵＲＬ）を入手することができるので、この所在情報２４Ａを用いてインターネットにアクセスし、秘匿情報２３Ａを入手することが可能になる。
このように、この変形例においても、プログラム提供者ＡからユーザＵに対して、秘匿情報２３Ａが引き渡される点は、これまで述べてきた実施形態と変わりはないので、秘匿情報２３Ａを用いた改竄有無判定処理も、これまで述べてきた実施形態と同様の処理を行えばよいことになる。要するに、本発明の配布プロセスにおける配布用ファイル作成段階では、アプリケーションパッケージと、署名情報と、秘匿情報もしくは秘匿情報の所在を示す所在情報と、を含む配布用ファイルを作成すればよく、実施プロセスにおける第２の確認段階では、入力した配布用ファイルに基づいて秘匿化対象データおよび秘匿情報を入手し、秘匿化対象データに対する秘匿情報の正当性を確認すればよい。
配布用ファイル作成段階で、秘匿情報２３Ａを含む配布用ファイル２０Ａを作成した場合（図５に示す実施形態の場合）は、第２の確認段階で、配布用ファイル２０Ａから秘匿情報２３Ａを直接抽出することにより、秘匿情報２３Ａの入手を行うことができる。これに対して、配布用ファイル作成段階で、秘匿情報２３Ａを所定の格納場所（サーバ３０）に格納する処理を行うとともに、当該格納場所を示す所在情報２４Ａを含む配布用ファイル２０ＡＡを作成した場合（図１６に示す変形例の場合）は、第２の確認段階で、配布用ファイル２０ＡＡから所在情報２４Ａを抽出し、この所在情報２４Ａに基づいて格納場所（サーバ３０）を認識し、格納場所（サーバ３０）から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うことができる。
なお、サーバ３０から秘匿情報２３Ａを入手する処理は、アプリケーション実行用コンピュータが、配布用ファイル２０ＡＡに含まれているアプリケーションについての第２の確認段階を実行するたびに毎回行うようにしてもよいが、実用上は、アプリケーション実行用コンピュータ内に、入力した個々の配布用ファイルについて、それぞれ秘匿情報を保存する保存場所（たとえば、アプリケーション実行用コンピュータ内の不揮発性メモリ内の、当該アプリケーションに割り当てられた領域）を設けておき、秘匿情報２３Ａを一度入手したら、これをその保存場所に保存するようにし、次回からは、この保存場所に保存されている秘匿情報２３Ａを利用するようにするのが好ましい。そうすれば、保存場所に秘匿情報２３Ａを保存した後は、インターネットに接続できない状態でも、当該アプリケーションを起動させることができる。
すなわち、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、所定の保存場所に、必要な秘匿情報２３Ａが保存されていない場合には、配布用ファイル２０ＡＡから所在情報２４Ａを抽出し、この所在情報２４Ａに基づいて格納場所（サーバ３０）を認識し、この格納場所（サーバ３０）から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報２３Ａをアプリケーション実行用コンピュータ内の保存場所に保存する処理を行うようにすればよい。そして、アプリケーション実行用コンピュータが第２の確認段階を実行する際に、当該コンピュータ内の保存場所に、必要な秘匿情報２３Ａが保存されている場合には、この保存場所から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うようにすればよい。
もちろん、ここで述べる変形例は、図５に示す基本的な実施形態だけでなく、その他の実施形態に対しても適用可能である。また、配布プロセスにおいて、秘匿情報２３Ａを任意のサーバに格納する際には、必ずしも１箇所のサーバ３０に格納しておく必要はなく、複数箇所に分散して格納するようにしてもよい。たとえば、秘匿情報２３Ａを３つのファイルに分割し、第１の分割ファイルを第１のサーバ３１に格納し、第２の分割ファイルを第２のサーバ３２に格納し、第３の分割ファイルを第３のサーバ３３に格納する、という格納方法を採ってもかまわない。この場合、所在情報２４Ａは、これら３箇所の格納場所を示す情報ということになる。また、この場合、所在情報２４Ａに、分割方法を示す情報も含ませておけば、実行プロセスにおいて、３箇所から入手した個々の分割ファイルに対して、分割方法を参照した合成処理を行い、元の秘匿情報２３Ａを復元することができる。
ここで述べた変形例を採用する場合、図１５に示す配布用ファイル作成装置にも若干の変更を行う必要がある。前述の§７で説明した配布用ファイル作成装置の場合、配布用ファイル作成ユニット１８０は、秘匿情報２３Ａを含む配布用ファイル２０Ａを作成し、改竄チェックルーチン格納ユニット１２０に格納されている改竄チェックルーチンＦは、配布用ファイル２０Ａから秘匿情報２３Ａを抽出することにより、当該秘匿情報の入手を行うことになっていた。
これに対して、ここで述べた変形例を採用する場合は、配布用ファイル作成ユニット１８０が、秘匿情報作成ユニット１７０によって作成された秘匿情報２３Ａを所定の格納場所（たとえば、図１６のサーバ３０）に格納する処理を行うとともに、当該格納場所を示す所在情報２４Ａを含む配布用ファイル２０ＡＡを作成し、改竄チェックルーチン格納ユニット１２０に格納されている改竄チェックルーチンＦが、この配布用ファイル２０ＡＡから所在情報２４Ａを抽出し、この所在情報２４Ａに基づいて格納場所（たとえば、図１６のサーバ３０）を認識し、認識した格納場所から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うようにすればよい。
また、アプリケーション実行用コンピュータ内に秘匿情報２３Ａの保存場所を確保するようにする場合は、改竄チェックルーチン格納ユニット１２０に格納されている改竄チェックルーチンＦが、当該改竄チェックルーチンを実行しているコンピュータ内に設けられた秘匿情報の保存場所に秘匿情報２３Ａが保存されていない場合には、配布用ファイル２０ＡＡから所在情報２４Ａを抽出し、この所在情報２４Ａに基づいて格納場所を認識し、この格納場所から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うとともに、入手した秘匿情報２３Ａを保存場所に保存する処理を行い、この保存場所に秘匿情報２３Ａが保存されている場合には、この保存場所から秘匿情報２３Ａを取り出すことにより、当該秘匿情報の入手を行うようにすればよい。
＜＜＜ §９．実行許可リストに基く実行制御 ＞＞＞
本発明に係るアプリケーションプログラムの実行方法の特徴は、アプリケーションプログラムの実行プロセスにおいて、実行許可リストに予め登録されているアプリケーションプログラムについてのみ、その実行を許可するという実行制御方法を採用しつつ、§１〜§８において述べた改竄検知方法を実行し、改竄が検知されなかったアプリケーションプログラムについては、リストへの自動登録を行うようにする点にある。そこで、まず、実行許可リストに基いてアプリケーションプログラムの実行制御を行う具体的な方法を説明する。
ここでは、これまで述べてきた例と同様に、Android（登録商標）をＯＳとして採用したスマートホンやタブレット型電子機器（いわゆる、Android端末）への適用例を述べることにする。この場合、Android端末に与えられるデータファイル（改竄チェック機能付アプリケーションプログラムが含まれているデータファイル）は、たとえば、図５に示すような配布用ファイル２０Ａ（ＡＰＫファイル）の形式で配布されることになる。ここで述べる実施形態では、アプリケーションプログラムの実行端末において、実行許可リストに基づく制御を行うために、専用のプログラムが用意される。このプログラムは、ＯＳの管理下で動作するアプリケーションプログラムの１つであるが、その役割は、専ら他のアプリケーションプログラムの動作を監視し、その制御を行うことにある。そこで、本願では、このプログラムのことを、他のアプリケーションプログラムとは区別して「監視プログラム」と呼ぶことにする。また、以下の説明では、単に「アプリケーションプログラム」といった場合、「監視プログラム」を除くアプリケーションプログラムを意味するものとする。
Androidをはじめとする多くのＯＳは、複数のアプリケーションプログラムを並行して実行させるマルチタスク処理機能を有している。もちろん、一般的なＣＰＵは、同時には１つのアプリケーションプログラムを実行する機能しか有していないが、マルチタスク処理機能を有するＯＳプログラムは、複数のアプリケーションプログラムを所定のタイミングで順次切り替えながらＣＰＵに実行させる処理を行うことができる。したがって、複数のアプリケーションプログラムを同時に起動状態にして、これらを時分割で切り替えることにより、あたかも複数のアプリケーションプログラムが同時に実行されているような制御が可能になる。
ここで述べる実施形態の場合、監視プログラムは、いわゆる「常駐プログラム」として常に起動状態に維持され、他のアプリケーションプログラムの監視を行う。上述したように、マルチタスク処理機能を有するＯＳ制御下では、複数のアプリケーションプログラムを同時に起動状態にすることができるので、監視プログラムを常に起動状態に維持したとしても、他のアプリケーションプログラムの起動に支障が生じることはない。なお、この監視プログラムそれ自体が攻撃されて改竄されてしまうことを防ぐために、実用上は、何らかの耐タンパ化処理が施された監視プログラムを用いるのが好ましい。
図１７は、アプリケーションプログラムの実行端末に組み込まれた監視プログラムによって実行される監視ルーチンの手順を示す流れ図である。標題部に「監視プログラム(1)」と記載されているのは、ここに示す手順が、監視プログラムに含まれている監視ルーチンの手順であることを示すものである。後述するように、この監視プログラムには、「監視プログラム(2)」として示すリスト自動登録ルーチンの手順も含まれている。
まず、ステップＳ２１において、現在、起動状態にあるアプリケーションプログラムの識別コードを認識する起動アプリ認識段階が実行される。Androidをはじめとする一般的なＯＳには、個々のアプリケーションプログラムについて、識別コード・起動時・終了時を示すログ情報を記録する処理機能が備わっている。したがって、監視プログラムによって起動アプリ認識段階Ｓ２１を実行する際には、このログ情報を参照することにより、現時点で起動状態にあるアプリケーションプログラムの識別コードを認識することができる。
図１８は、AndroidＯＳによって作成されたログ情報の一例を示す図である。この例では、ＡＰ３，ＡＰ１，ＡＰ６といったアプリケーションプログラムのファイル名を個々のアプリケーションを特定する識別コードとして用いている。そして、この識別コードと、起動もしくは終了のいずれか一方の動作と、日時と、を並べた１行分のデータが単位ログを構成しており、このような単位ログを時系列で複数組並べた集合体によってログ情報が構成されている。
具体的には、１行目の単位ログは、識別コード「ＡＰ３」で特定されるアプリケーションＡＰ３が、２０１２年７月２１日１６時５１分に起動されたことを示し、２行目の単位ログは、識別コード「ＡＰ１」で特定されるアプリケーションＡＰ１が、２０１２年７月２１日１６時５８分に起動されたことを示し、３行目の単位ログは、識別コード「ＡＰ１」で特定されるアプリケーションＡＰ１が、２０１２年７月２１日１７時１４分に終了されたことを示し、４行目の単位ログは、識別コード「ＡＰ６」で特定されるアプリケーションＡＰ６が、２０１２年７月２１日１７時３３分に起動されたことを示し、５行目の単位ログは、識別コード「ＡＰ３」で特定されるアプリケーションＡＰ３が、２０１２年７月２１日１７時５３分に終了されたことを示している。結局、図示のようなログ情報が得られた時点では、アプリケーションＡＰ６のみが起動状態であるとの認識がなされる。
AndroidＯＳは、インストールされているアプリケーションプログラムが起動されたり、終了されたりするたびに、図示のようなログ情報をＯＳ用の記録領域に記録してゆくことになる。もちろん、監視プログラムもアプリケーションプログラムの１つであるので、監視プログラム自身の起動や終了を示すログも、ログ情報として記録されることになる。
一方、監視プログラム用の記録領域には、図１９に例示するような実行許可リストが用意されている。この実行許可リストは、実行が許可されているアプリケーションプログラムの識別コードを記録したリストであり、いわば「ホワイトリスト」と呼ぶべきリストである。図１９(a) に示す例は、ＡＰ１，ＡＰ２，ＡＰ３といったアプリケーションプログラムのファイル名を個々のアプリケーションを特定する識別コードとして用い、これら識別コードを列挙することにより実行許可リストが構成されている。
これに対して、図１９(b) に示す例は、アプリケーションプログラムのファイル名にそのバージョン番号を括弧書きで付加したものを識別コードとして用いたものであり、バージョンが異なるアプリケーションプログラムには、それぞれ異なる識別コードが付与され、相互に区別されることになる。たとえば、同一のファイル名ＡＰ１をもったアプリケーションプログラムであっても、バージョン１．０のプログラムには識別コードＡＰ１（１．０）が付与され、バージョン２．０のプログラムには識別コードＡＰ１（２．０）が付与され、相互に異なるアプリケーションプログラムとして取り扱われることになる。なお、バージョンを区別して取り扱う場合は、図１８に示すログ情報にも、ＡＰ１（１．０）のようにバージョン番号を付加した識別コードを用いるようにする。
さて、図１７に示す起動アプリ認識段階Ｓ２１において、現時点で起動状態にあるアプリケーションプログラム（以下、単に、起動アプリという）の識別コードが認識できたら、続いて、認識した識別コードが実行許可リストに登録されているか否かを判定する登録有無判定段階が実行される。すなわち、ステップＳ２２において、図１９(a) に示すような実行許可リストが参照され、ステップＳ２３において、認識された起動アプリの識別コードがリストに掲載されているか否かが判定される。なお、ステップＳ２１において起動アプリが複数認識された場合は、ステップＳ２２以下の処理は、ステップＳ２８を経て、個々の起動アプリごとにそれぞれ繰り返し実行されることになる。
前述したように、図１８に示すようなログ情報が得られた場合は、アプリケーションＡＰ６が起動アプリとして認識されるので、ステップＳ２２において、実行許可リストを参照することにより、識別コードＡＰ６が掲載されているか否かが判定される。ここで、図１９(a) に示すような実行許可リストが用意されていたとすると、識別コードＡＰ６は掲載されているため、起動アプリＡＰ６は登録済みのアプリケーションプログラムと判定されることになる。その結果、ステップＳ２３からステップＳ２８へ進むことになる。
これに対して、登録有無判定段階において未登録と判定された場合、すなわち、ステップＳ２３においてリストに掲載されていないと判定された場合は、ステップＳ２４へ進み登録照会段階が行われる。たとえば、ログ情報から、アプリケーションプログラムＡＰ７が起動アプリとして認識された場合は、識別コードＡＰ７は図１９(a) に示す実行許可リストには掲載されていないので、未登録アプリと判定される。その結果、ステップＳ２３からステップＳ２４へと進み、登録照会段階が実行される。
ステップＳ２４の登録照会段階では、当該未登録アプリＡＰ７を実行許可リストに登録するか否かをユーザに問い合わせる処理が行われる。たとえば、Android端末のディスプレイ画面上に、図２０に示すようなメッセージ画面を提示する処理を行えばよい。ユーザは、このようなメッセージ画面による問い合わせに対して、「登録する」ボタンまたは「登録しない」ボタンをタップすることにより回答を行う。「登録する」旨の回答は、未登録アプリＡＰ７を登録して実行する指示に相当し、「登録しない」旨の回答は、未登録アプリＡＰ７を登録せず、実行もしない指示に相当する。
ユーザがいずれかのボタンをタップして、問い合わせに対する回答を行うと、当該回答に基づいて回答処理段階が行われる。すなわち、「登録する」ボタンのタップによって登録する旨の回答があった場合には、ステップＳ２５からステップＳ２６へと進み、当該未登録アプリＡＰ７の識別コードを新たに実行許可リストに登録する処理が行われる。この場合、起動状態にある当該アプリＡＰ７は、正式に実行が許可されたことになり、そのまま実行し続けることになる。一方、「登録しない」ボタンのタップによって登録しない旨の回答があった場合には、ステップＳ２５からステップＳ２７へと進み、当該未登録アプリＡＰ７の実行を中止させる処理が行われる。
以上述べたステップＳ２２〜Ｓ２７の処理が、全起動アプリについて完了するまで、ステップＳ２８を介して繰り返し実行されることになる。そして、全起動アプリについて処理が完了したら、ステップＳ２８からステップＳ２９へ進み、監視プログラムに対する終了指示が与えられていない限り、再び、ステップＳ２１からの処理が繰り返されることになる。前述したとおり、この監視プログラムは、本来、「常駐プログラム」として常に起動状態に維持され、他のアプリケーションプログラムの監視を行うべきものである。したがって、通常は、ユーザによって監視プログラムに対する終了指示が与えられることはなく、ステップＳ２９からステップＳ２１へ戻る処理が繰り返されることになる。
上述したように、マルチタスク処理機能を有するＯＳ制御下では、同時に起動状態となっている複数のアプリケーションプログラムが所定のタイミングで切り替えられながら順番に実行されることになる。したがって、図１７に示す監視プログラムによる監視ルーチンの手順においても、ある時点で中断され、別なアプリケーションプログラムの実行に制御が移り、再び監視プログラムに制御が戻ってきた時点で中断されていた手順が再開される、という処理が繰り返されることになる。
もっとも、マルチタスク処理によるアプリケーションプログラムの切替期間は、ｍｓｅｃ程度のオーダーであるため、ユーザの立場からは、監視プログラムを含めた複数のアプリケーションプログラムが同時に動作しているように見える。たとえば、新たなアプリケーションプログラムＡＰ７を起動させると、監視プログラムに制御が移った段階で、アプリＡＰ７が起動アプリとして認識され、ステップＳ２４の登録照会段階が行われる。したがって、ユーザから見ると、アプリＡＰ７を起動させる操作を行ったら、直ちに図２０に示すようなメッセージ画面が表示された状態になるので、監視プログラムの処理動作に切り替わったという違和感は生じない。
なお、監視プログラムもアプリＡＰ７も、アプリケーションプログラムという点では対等であり、いずれもＯＳプログラムの制御下で動作するプログラムであるが、ＯＳの機能を利用して、一方のアプリケーションプログラムから他方のアプリケーションプログラムを強制終了させることが可能である。ステップＳ２７の実行中止処理も、このようなＯＳの機能を利用して、監視プログラムからアプリＡＰ７を強制終了させる方法を採ればよい。具体的には、監視プログラムからＯＳに対して、アプリＡＰ７を強制終了させるコマンドを引き渡すようにすれば、ＯＳの制御機能により、アプリＡＰ７を強制終了させ、実行を中止させることができる。
結局、監視プログラムは、図１７に示す監視ルーチンを継続的に実行することにより、実行許可リストに登録されていない未登録アプリが起動状態になったか否かを常に監視する処理を行い、もし未登録アプリが起動状態になっていた場合には、ステップＳ２４の登録照会段階を実行し、ユーザの回答に応じて、当該未登録アプリを登録して実行を許可するか、登録せずに実行を中止させるか、いずれかの処理を採ることになる。かくして、実行許可リストに登録されているアプリケーションプログラムのみが実行を許可されるような制御が可能になる。
以上、図１７の流れ図を参照しながら、監視プログラムによる監視ルーチンの手順を説明した。続いて、個々のアプリケーションプログラムを起動する際の手順を述べながら、監視プログラムとの関係を説明しよう。
まず、「通常アプリ」を起動するときの処理手順を図２１の流れ図を参照して説明する。ここでいう「通常アプリ」とは、自己改竄チェック機能を有していない、従来の一般的なアプリケーションプログラム（たとえば、図１に示すアプリケーションプログラム１０）を指す。アプリケーションプログラムは、ＯＳの制御下で起動される。すなわち、特定のアプリケーションプログラムを起動する旨の指示が与えられると、ＯＳが当該特定のアプリケーションプログラムを実行するための環境を整える作業を行う。そして、準備が完了した時点で、当該特定のアプリケーションプログラムのルーチンが実行されることになる。
図２１の流れ図は、「通常アプリ」に対して起動指示が与えられた場合の処理手順を示している。起動指示は、たとえば、ユーザによる起動操作によって与えられる。Android端末の場合、ユーザがホーム画面上で特定のアプリケーションプログラムのアイコンをタップする操作を行うと、当該プログラムに対する起動指示が与えられる。なお、既に述べたとおり、起動指示は、必ずしもユーザから与えられるとは限らず、場合によっては、ＯＳや別なアプリケーションプログラムによって与えられる場合もある。
実は、この図２１に示されているステップＳ７，S８，Ｓ１１，Ｓ１２の手順は、図７の流れ図に実行プロセスとして示されている同符号の各手順と同じものであり、各ステップの右脇に記載した括弧書きは、個々の手順の実行主体となるプログラムを示している。
まず、ステップＳ７では、ＯＳプログラムによって、図６に示す第１の確認段階が行われる。この第１の確認段階は、アプリケーションパッケージ２１Ａに対する署名情報２２Ａの正当性を確認する処理であり、その詳細は§３で述べたとおりである。第１の確認段階において否定的な結果が得られた場合、すなわち、署名情報の正当性が確認されなかった場合には、「改竄あり」との判定がなされ、ステップＳ８を経てステップＳ１１へと進み、当該アプリケーションの実行は中止される。すなわち、当該アプリケーションプログラムに含まれるルーチンが実行される前に、ＯＳによって、実行が阻止されることになる。一方、第１の確認段階において肯定的な結果が得られた場合は、ステップＳ８を経てステップＳ１２へと進み、当該アプリケーションプログラムが実行される。前述したとおり、Android端末の場合、ステップＳ７，Ｓ８，Ｓ１１の処理は、ＯＳプログラムの標準仕様に基づく処理である。
続いて、「自己改竄チェック機能をもつアプリ」を起動するときの処理手順を図２２の流れ図を参照して説明する。ここでいう「自己改竄チェック機能をもつアプリ」とは、図５に示すアプリケーションプログラム１０Ａのように、改竄チェックルーチンＦを含んでおり、自分自身で改竄チェック処理を行う機能をもった本発明に特有のアプリケーションプログラムを指す。
図２２の流れ図は、「自己改竄チェック機能をもつアプリ」に対して起動指示が与えられた場合の処理手順を示している。この場合も、起動指示は、ユーザから与えられる場合もあれば、ＯＳや別なアプリケーションプログラムによって与えられる場合もある。この図２２に示されている手順のうち、ステップＳ７〜Ｓ１２の手順は、図７の流れ図に実行プロセスとして示されている同符号の各手順と同じものである。一方、ステップＳ１３，Ｓ１４の手順は、監視プログラムによるリスト自動登録ルーチンの手順である。この図２２でも、各ステップの右脇に記載した括弧書きは、個々の手順の実行主体となるプログラムを示している。ステップＳ１３，Ｓ１４の脇に「監視プログラム(2)」と記載されているのは、これらの手順が監視プログラムに含まれているリスト自動登録ルーチンの手順であることを示すものである。
要するに、図２２の流れ図に示す手順は、図７の流れ図におけるステップＳ７以降の手順に、新たにステップＳ１３，Ｓ１４を追加したものである。§３で述べたとおり、「自己改竄チェック機能をもつアプリ」に対して起動指示が与えられた場合、まずＯＳプログラムにより、署名情報の正当性を確認する第１の確認段階Ｓ７が実行される。そして、改竄なしとの結果が得られた場合は、当該アプリが起動され、自分自身によって、秘匿情報の正当性を確認する第２の確認段階Ｓ９が実行される。これらステップＳ７〜Ｓ１０の手順は改竄判定段階を構成することになり、ステップＳ１０において肯定的な判定がなされた場合には、署名情報と秘匿情報の双方について正当性が確認されたことになり、最終的に改竄なしとの判定結果が得られたことになる。一方、ステップＳ８，Ｓ１０のいずれかで否定的な判定がなされた場合には、改竄判定段階において改竄ありとの判定結果が得られたことになり、ステップＳ１１へと進み、当該「自己改竄チェック機能をもつアプリ」の実行は中止される。
ステップＳ１３，Ｓ１４の手順は、この改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録するリスト自動登録段階の手順であり、監視プログラム内の自動登録ルーチンによって実行されることになる。すなわち、ステップＳ１３において、当該「自己改竄チェック機能をもつアプリ」の識別コードが既に実行許可リストに登録されているか否かの判定が行われ、登録済みであった場合には、ステップＳ１３からステップＳ１２へと進むが、未登録であった場合には、ステップＳ１４において、当該識別コードを実行許可リストに登録した上で、ステップＳ１２へと進む処理が行われる。いずれの場合も、ステップＳ１２において、当該アプリが実行されることになり、しかも当該アプリの識別コードが実行許可リストに登録された状態になる。
なお、図２２の流れ図では、説明の便宜上、ステップＳ１０→Ｓ１３→Ｓ１４→Ｓ１２のような順序で各手順が実行される様子が示されているが、実際には、自己改竄チェック機能をもつアプリと監視プログラムとは、ＯＳプログラムのマルチタスク処理機能により並行して動作していることになるので、この流れ図は必ずしも時系列的な順序を示しているわけではない。たとえば、ステップＳ１０で肯定的な判定がなされた場合、アプリケーションプログラムは、監視プログラムに対して、自己の識別コードを引き渡して実行許可リストに登録する旨の登録コマンドを与え、そのままステップＳ１２の実行段階を行えばよい。一方、登録コマンドを受け取った監視プログラムは、引き渡された識別コードについて、リスト自動登録段階（ステップＳ１３，Ｓ１４）を実行すればよい。あるいは、ステップＳ８を経てアプリが起動されたことを監視プログラムが検知した場合に、監視プログラムによって当該アプリの実行を一旦停止させ、ステップＳ９，Ｓ１０をスキップしてステップＳ１３の登録済か否かの判断を行うようにしてもよい。この場合、当該アプリが実行許可リストに登録済であれば、ステップＳ１２へと進み、未登録であれば、ステップＳ９へ戻るようにすればよい。
続いて、各アプリケーションプログラムと監視プログラムとの関係を見てみよう。まず、従来の「通常アプリ」を初めて起動した場合を考えてみる。この場合、図２１の流れ図に示すように、ステップＳ７の第１の確認段階において署名情報の確認が行われ、改竄なしと判断された場合には、ステップＳ１２において、当該「通常アプリ」が起動され、その実行が開始される。ただ、監視プログラムが並行して実行されているため、図１７の流れ図のステップＳ２１において、当該「通常アプリ」の起動が認識される。当該「通常アプリ」は実行許可リストには登録されていない未登録アプリであるため、ステップＳ２４の登録照会段階が実行され、図２０に例示するようなメッセージが提示され、登録するか否かの選択が行われる。もちろん、このとき、当該「通常アプリ」も起動状態にあるが、ＯＳのマルチタスク処理機能により、監視プログラムに切り替えられた時点で、図示のメッセージが提示されることになる。
結局、ユーザがホーム画面やアプリ画面からアイコンをタップして未登録の「通常アプリ」を起動したり、他のアプリケーションプログラムからの指示に基づいて未登録の「通常アプリ」が起動したりした場合、図２０のようなメッセージが提示され、実行許可リストに登録するか否かの選択を迫られることになる。「通常アプリ」の場合も、一応、署名情報の正当性確認が行われているので、ユーザは、当該「通常アプリ」の安全性をある程度認識することができる。ただ、前述したとおり、署名情報自体が改竄されているケースもあるので、安全性はそれほど高いものではない。したがって、ユーザは、当該アプリの実行により得られるであろうメリットと、改竄されていた場合に被るであろう損害のデメリットとを天秤にかけ、「登録する」／「登録しない」のいずれかを選択することになる。
ユーザが、当該アプリの実行を許可してもよいと判断した場合は、「登録する」ボタンをタップすればよい。そうすれば、ステップＳ２６によって、当該アプリの識別コードが実行許可リストに登録されることになるので、以後、当該アプリに関して図２０のようなメッセージが提示されることはなくなる。一方、ユーザが、少なくともその時点では、当該アプリの実行を許可しない方がよいと判断した場合は、「登録しない」ボタンをタップすればよい。そうすれば、ステップＳ２７によって、当該アプリの実行は中止され、未登録の状態のままにおかれる。この場合、当該アプリを起動するたびに、図２０のようなメッセージが提示されることになる。
このように、監視プログラムによって、常時、起動状態にあるアプリケーションプログラムの監視を行い、未登録アプリが起動状態にあることが検知されたら、ステップＳ２４の登録照会段階によってユーザの判断を仰ぐようにすれば、実行対象となるプログラムを、ユーザの意思で実行許可リストに登録したプログラムのみに制限することができる。
しかしながら、実際には、上記運用は必ずしも奏功していない。その第１の理由は、一般ユーザにとって、個々のアプリケーションプログラムが改竄されているか否かを判定することが難しいためである。一般ユーザにとって、アプリケーションプログラムの信頼性を評価する手掛かりは、著名なソフトウエアであるとか、信頼性あるベンダーから供給されたソフトウエアであるとか、信頼性あるサイトからダウンロードしたソフトウエアであるといった情報であるが、クラッカーによって改竄されたソフトウエアが流通した場合、これらの手掛かりは役に立たない。したがって、実用上、一般ユーザが、個々のアプリケーションプログラムについて、改竄されているか否かを判定することは極めて困難である。
そして、第２の理由は、一般ユーザにとって、図２０に示すようなメッセージに応じて、未登録アプリを実行許可リストに手動登録する作業は煩雑であり、事実上、どのようなアプリケーションプログラムであっても「登録する」ボタンをタップすることが習慣化してしまうためである。もちろん、Android端末の工場出荷時にプリインストールされているアプリケーションプログラム（安全性が保証されているプログラム）については、当初から実行許可リストに掲載しておくようにすれば、初回起動時にユーザが手動登録の操作を行うことを省くことができるが、端末購入後にユーザがダウンロードした「通常アプリ」については、初回起動時にユーザが手動登録せざるを得ない。
本発明に係る「自己改竄チェック機能をもつアプリ」を利用すれば、上記問題を解決することができる。すなわち、「自己改竄チェック機能をもつアプリ」を初めて起動した場合、図２２の流れ図に示すように、改竄判定段階（ステップＳ７〜Ｓ１０）によって署名情報の正当性および秘匿情報の正当性の確認が行われ、最終的に改竄なしと判定されると、監視プログラムによってリスト自動登録段階（ステップＳ１３，Ｓ１４）が実行される。これにより、当該アプリの識別コードが実行許可リストに自動登録されることになる。一方、並行して実行されている監視プログラムでは、図１７の流れ図のステップＳ２１において、当該「自己改竄チェック機能をもつアプリ」の起動が認識されるが、ステップＳ２３において登録アプリと判定されるため、登録照会段階Ｓ２４が実行されることはない。
結局、ユーザがホーム画面やアプリ画面からアイコンをタップして未登録の「自己改竄チェック機能をもつアプリ」を起動したり、他のアプリケーションプログラムからの指示に基づいて未登録の「自己改竄チェック機能をもつアプリ」が起動したりした場合、当該アプリが改竄されていなければ、そのまま実行が継続されることになる（改竄されていた場合は、図２２のステップＳ１１において実行中止される）。すなわち、ユーザには、図２０のようなメッセージが提示されることはないので、ユーザが「登録する」／「登録しない」の選択を行う必要はなくなる。
もちろん、改竄判定段階（ステップＳ７〜Ｓ１０）による判定結果は、必ずしも１００％の精度をもった結果ではないが、一般ユーザによる判定に比べてはるかに高い精度をもった結果であり、実用上、十分に信頼できる結果である。しかも、そのような十分に信頼できる結果に基づいて、実行許可リストへの自動登録が行われることになる。かくして、ユーザは、改竄の有無を判定したり、煩雑な手動登録の操作を行ったりする必要がなくなる。このように、監視プログラムを導入した装置で、本発明に係る「自己改竄チェック機能をもつアプリ」を実行すれば、改竄なしと判定されたアプリケーションプログラムについては、ユーザに登録作業の負担を課すことなしに実行許可リストへの自動登録を行うことができるメリットが得られる。
＜＜＜ §１０．実行許可リストに基く実行制御の変形例 ＞＞＞
最後に、§９で述べた実行許可リストに基く実行制御を行う上でのいくつかの変形例を述べておく。
＜１０−１：アプリケーションプログラムのバーションの区別＞
本発明に用いる実行許可リストは、実行が許可されたアプリケーションプログラムを特定する識別コードを掲載した「ホワイトリスト」というべきものである。図１９(a) には、識別コードとして、各アプリケーションプログラムのファイル名を用いた例を示し、図１９(b) には、ファイル名にバージョン番号を付加したコードを用いた例を示した。
一般に、アプリケーションプログラムのバージョンアップ版を提供する場合、差分データファイルだけを配布する形態が採られたり、新バージョンのデータファイルをそっくり配布する形態が採られたりする。後者の場合は、新バージョンのプログラムは旧バージョンのプログラムとは全く別の独立したプログラムになるため、実行許可リスト上でも別個のアプリケーションプログラムとして取り扱うのが好ましい。したがって、実用上は、図１９(b) に示す例のように、バージョンごとにそれぞれ異なる識別コードを付与するようにし、リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別コードを用いた処理を行うようにするのが好ましい。
なお、バージョンの異なるアプリケーションプログラムを確実に区別するには、同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識するようにすればよい。一般に、アプリケーションプログラムを構成するデータの内容が完全に同一でなければ、ハッシュ値も同一にはならない。したがって、たとえば、アプリケーションプログラムを構成するデータ（ＡＰＫファイル全体でもよいし、その一部でもよい）のハッシュ値を、当該アプリケーションプログラムの識別コードとして利用するようにすれば、バージョンの異なるアプリケーションプログラムの識別コードを確実に区別することができる。
＜１０−２：実行許可リストの格納場所＞
上述したAndroid端末を用いた実施形態の場合、実行許可リストは、Android端末内で「常駐プログラム」として動作する監視プログラムによってアクセスされる情報であるので、Android端末内の記憶装置内に格納するのが最も一般的である。ただ、実行許可リストの格納場所は、必ずしもAndroid端末内に限定されるわけではなく、たとえば、Android端末に接続される外部の記憶装置や、Android端末からネットワークを介してアクセスされるサーバ装置に実行許可リストを格納してもかまわない。
この場合、リスト自動登録段階および回答処理段階で実行許可リストへの登録を行う際に、Android端末等のコンピュータは、外部の記憶装置もしくはサーバ装置内に保存された実行許可リストに対する登録を行い、登録有無判定段階では、当該外部の記憶装置もしくはサーバ装置内に保存された実行許可リストを参照することになる。
＜１０−３：実行許可リストの暗号化＞
§９で述べたアプリケーションプログラムの実行方法では、実行許可リストが重要な役割を果たすことになり、この実行許可リストが何らかの不正操作によって改竄されてしまうと、監視プログラムによる本来の実行制御機能は失われてしまう。そこで、より信頼性の高い制御を行うためには、実行許可リストに対して暗号化対策を施すようにすればよい。
具体的には、リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、実行許可リストを暗号化する処理を行うようにすればよい。たとえば、実行許可リストに登録する識別コードや後述するチェックコードを個別に暗号化した上で登録するようにしてもよいし、実行許可リストを復号した状態で新たな識別コードやチェックコードを登録し、登録後の実行許可リストを再び暗号化するようにしてもよい。登録有無判定段階では、暗号化されている実行許可リストを復号して内容の参照を行うことになる。なお、暗号化および復号には、監視プログラム内に含まれている専用鍵を用いるようにすればよい。
＜１０−４：チェックコードの付加＞
実行許可リストの信頼性を高める別な方法は、識別コードの他に何らかのチェックコードを登録しておく方法である。すなわち、リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、識別コードとともに、入力段階で入力したデータファイル内に含まれている何らかのデータをチェックコードとして登録するようにし、登録有無判定段階で、データファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うようにすればよい。
たとえば、図５に示すＡＰＫファイル２０Ａの場合、「Ａの第２の鍵Ｋ（ａ２）」（プログラム提供者の公開鍵）をチェックコードとして用い、当該アプリケーションプログラムを実行許可リストに登録する際には、識別コードとともに、「Ａの第２の鍵Ｋ（ａ２）」をチェックコードとして登録しておくようにする。そして、登録有無判定段階（図１７のステップＳ２２，Ｓ２３）では、実行許可リストに当該識別コードと当該チェックコードの双方が登録されていることが確認された場合に、「登録されている」との判定を行うようにすればよい。
もし、識別コードは掲載されているものの、チェックコードが不一致ということになった場合は、実行許可リストに対して何らかの不正行為（たとえば、不正な方法で、実行許可リストに掲載されている識別コードを別なアプリの識別コードに書き換えるような行為）が行われた可能性があると判断することができる。
もちろん、チェックコードは、プログラム提供者の公開鍵に限定されるものではなく、この他にも様々な情報をチェックコードとして用いることができる。たとえば、図５に示すＡＰＫファイル２０Ａの場合、「Ａの第２の鍵Ｋ（ａ２）」（プログラム提供者の公開鍵）の他、Ａの署名情報２２Ａ全体やＡＰＫファイル２０Ａ全体をチェックコードとして用いてもかまわない。
もっとも、Ａの署名情報２２Ａ全体やＡＰＫファイル２０Ａ全体を、そのままチェックコードとして用いると、チェックコードのデータ容量が膨大なものになり、チェックコードを登録する実行許可リストのデータ容量も膨大なものになってしまう。そこで、実用上は、入力段階で入力したデータファイル内に含まれている所定の情報（たとえば、図５に示すＡの署名情報２２Ａ全体やＡＰＫファイル２０Ａ全体）に対してハッシュ関数のような一方向性関数を作用させるダイジェスト化処理を行い、その結果得られたデータをチェックコードとして登録すればよい。
この場合、登録有無判定段階では、データファイル内に含まれている上記所定の情報に対して、上記一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことになる。なお、ダイジェスト化には、監視プログラム内に含まれている専用鍵を用いるようにすればよい。
＜１０−５：監視プログラムの代替＞
これまで述べてきた実施形態では、監視プログラムに、図１７の流れ図に示す監視ルーチン（監視プログラム(1)として示す手順）と、図２２の流れ図に示すリスト自動登録段階のルーチン（監視プログラム(2)として示す手順）とが含まれる例を示したが、もちろん、監視プログラム(1)と監視プログラム(2)とは、それぞれ別個のプログラムによって構成してもかまわない。
また、監視プログラム(2)の手順は、「自己改竄チェック機能をもつアプリ」内に組み込んでしまうことも可能である。この場合、図２２に示すステップＳ１３，Ｓ１４の手順は「自己改竄チェック機能をもつアプリ」によって実行されることになり、当該アプリケーションプログラムは、自分自身の改竄チェックを行う機能に加えて、自分自身を実行許可リストに登録する機能を備えることになる。
あるいは、監視プログラム(1)および監視プログラム(2)の手順を、そっくりＯＳプログラムに組み込んでしまうことも可能である。この場合、これまで述べてきた実施形態において監視プログラムの役割として述べた処理は、すべてＯＳプログラムによって実行されることになる。
ただ、現在提供されているAndroidＯＳには、監視プログラム(1)，(2)の機能は備わっていないので、現在のAndroid端末を利用して本発明を実施する場合には、上述した実施形態のように、監視プログラムとして機能するアプリケーションプログラムを用意するのが好ましい。要するに、端末装置のＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有していれば、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行することができる。
１０：アプリケーションプログラム
１０Ａ：アプリケーションプログラム
１０Ｘ，１０Ｘ′：改竄されたアプリケーションプログラム
１１：プログラム本体部
１１Ａ：プログラム本体部
１２：リソースデータ
１２Ｘ：改竄されたリソースデータ
１３：サブルーチン群
１３Ａ：サブルーチン群
１４：補助ファイル
１４Ｘ：改竄された補助ファイル
２０：配布用ファイル
２０Ａ，２０Ａ′，２０Ａ''，２０ＡＡ：配布用ファイル
２０Ｘ，２０Ｘ′：改竄された配布用ファイル
２１：アプリケーションパッケージ
２１Ａ：アプリケーションパッケージ
２１Ｘ，２１Ｘ′：改竄されたアプリケーションパッケージ
２２：Ａの署名情報
２２Ａ：Ａの署名情報
２２Ｘ，２２Ｘ′：Ｘの署名情報
２３Ａ，２３Ａ′，２３Ａ''：秘匿情報
２３Ｘ：改竄された秘匿情報
２４Ａ：所在情報
３０：サーバ
１１０：アプリケーションプログラム格納ユニット
１２０：改竄チェックルーチン格納ユニット
１３０：鍵格納ユニット
１４０：改竄チェックルーチン付加ユニット
１５０：パッケージ化処理ユニット
１６０：署名情報作成ユニット
１７０：秘匿情報作成ユニット
１８０：配布用ファイル作成ユニット
Ａ：プログラム提供者
ＡＰ１〜ＡＰ７：アプリケーションプログラムのファイル名
Ｃ，Ｃ′：秘匿化対象データ
Ｄ，Ｄ′：署名対象データ
Ｆ：改竄チェックルーチン
Ｇ：プログラム保証者
Ｈ，Ｈ１，Ｈ２：ハッシュ値
Ｋ（ａ１）：Ａの第１の鍵
Ｋ（ａ２）：Ａの第２の鍵
Ｋ（ｇ１）：Ｇの第１の鍵
Ｋ（ｇ２）：Ｇの第２の鍵
Ｋ（ｓ０）：共通特定鍵
Ｋ（ｓ１）：第１の特定鍵
Ｋ（ｓ２）：第２の特定鍵
Ｋ（ｘ１）：Ｘの第１の鍵
Ｋ（ｘ２）：Ｘの第２の鍵
Ｓ（Ａ）：署名値
Ｓ（Ｘ），Ｓ（Ｘ′）：署名値
Ｓ１〜Ｓ２９：流れ図の各ステップ
Ｕ，Ｕ１〜Ｕ３：ユーザ
Ｘ：クラッカー

Claims (13)

  1. コンピュータが、アプリケーションプログラムを実行する方法であって、
    コンピュータが、実行対象となるアプリケーションプログラムを含むデータファイルを入力する入力段階と、
    コンピュータが、入力したアプリケーションプログラムが改竄されているか否かを判定する改竄判定段階と、
    コンピュータが、前記改竄判定段階において改竄されていない旨の判定がなされたアプリケーションプログラムの識別コードを、実行許可リストに登録するリスト自動登録段階と、
    コンピュータが、起動状態にあるアプリケーションプログラムの識別コードを認識する起動アプリ認識段階と、
    コンピュータが、前記起動アプリ認識段階において認識した識別コードが前記実行許可リストに登録されているか否かを判定する登録有無判定段階と、
    コンピュータが、前記登録有無判定段階において未登録と判定された場合に、当該未登録アプリを登録するか否かをユーザに問い合わせる登録照会段階と、
    コンピュータが、前記問い合わせに対するユーザの回答として、登録する旨の回答があった場合には、前記未登録アプリの識別コードを前記実行許可リストに登録した上で当該アプリの実行を許可し、登録しない旨の回答があった場合には、当該未登録アプリの実行を中止させる回答処理段階と、
    を有し、
    前記入力段階では、改竄チェック機能付アプリケーションプログラムと、署名情報と、秘匿情報もしくはその所在を示す所在情報と、を含むデータファイルを入力し、
    前記署名情報は、前記アプリケーションプログラムを署名対象データとする電子署名処理によって得られた情報であり、
    前記秘匿情報は、前記改竄チェック機能付アプリケーションプログラムおよび前記署名情報を構成するデータの中の所定部分を秘匿化対象データとして抽出し、抽出した前記秘匿化対象データに対する秘匿化処理を施して得られた情報であり、
    前記改竄判定段階は、前記署名情報に基づいて改竄の有無を確認する第１の確認段階と、前記秘匿情報に基づいて改竄の有無を確認する第２の確認段階と、を有し、
    前記改竄チェック機能付アプリケーションプログラムには、前記秘匿化処理で行われた処理プロセスを勘案して前記秘匿化対象データに対する前記秘匿情報の正当性を確認する改竄チェックルーチンが含まれており、前記改竄チェックルーチンを実行することにより前記第２の確認段階が行われることを特徴とするアプリケーションプログラムの実行方法。
  2. 請求項１に記載のアプリケーションプログラムの実行方法において、
    一方の鍵を用いて暗号化したデータを他方の鍵を用いて復号できる性質をもった一対の鍵を用い、
    秘匿情報が、秘匿化対象データを前記一方の鍵を用いて暗号化することにより得られた情報であり、
    改竄チェックルーチンが、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報を前記他方の鍵を用いて復号し、この復号によって得られた秘匿化対象データと、入力段階で入力したデータファイルから抽出した秘匿化対象データとが一致していた場合に改竄なしとの確認を行うことを特徴とするアプリケーションプログラムの実行方法。
  3. 請求項１に記載のアプリケーションプログラムの実行方法において、
    秘匿情報が、秘匿化対象データに対して、所定の特定鍵をパラメータとして用いた一方向性関数を作用させるダイジェスト化処理を施して作成された情報であり、
    改竄チェックルーチンが、入力段階で入力したデータファイルから抽出した秘匿化対象データに対して、前記特定鍵を用いた前記ダイジェスト化処理を施して得られる情報が、入力段階で入力したデータファイルに含まれている秘匿情報もしくは入力段階で入力したデータファイルに含まれている所在情報に基づいて入手した秘匿情報と一致していた場合に改竄なしとの確認を行うことを特徴とするアプリケーションプログラムの実行方法。
  4. 請求項１〜３のいずれかに記載のアプリケーションプログラムの実行方法において、
    ＯＳプログラムの管理下でアプリケーションプログラムの実行を行うコンピュータが、第１の確認段階を前記ＯＳプログラムに基づいて実行し、第２の確認段階をアプリケーションプログラム内の改竄チェックルーチンに基づいて実行することを特徴とするアプリケーションプログラムの実行方法。
  5. 請求項４に記載のアプリケーションプログラムの実行方法において、
    ＯＳプログラムが、複数のアプリケーションプログラムを所定のタイミングで切り替えながら実行させるマルチタスク処理機能を有しており、
    コンピュータが、アプリケーションプログラムの１つとして用意された監視プログラムによって、リスト自動登録段階、起動アプリ認識段階、登録有無判定段階、登録照会段階、回答処理段階を実行することを特徴とするアプリケーションプログラムの実行方法。
  6. 請求項５に記載のアプリケーションプログラムの実行方法において、
    コンピュータが、ＯＳプログラムによって、個々のアプリケーションプログラムについて、識別コード・起動時・終了時を示すログ情報を記録する処理を実行し、
    コンピュータが、監視プログラムによって起動アプリ認識段階を実行する際に、前記ログ情報を参照することにより起動状態にあるアプリケーションプログラムの識別コードを認識することを特徴とするアプリケーションプログラムの実行方法。
  7. 請求項１〜６のいずれかに記載のアプリケーションプログラムの実行方法において、
    リスト自動登録段階、回答処理段階、および起動アプリ認識段階において、バージョンの異なるアプリケーションプログラムについては、それぞれ異なる識別コードを用いた処理を行うことを特徴とするアプリケーションプログラムの実行方法。
  8. 請求項７に記載のアプリケーションプログラムの実行方法において、
    同一のファイル名をもったデータファイルに含まれるアプリケーションプログラムであっても、ハッシュ値が異なる場合は、異なるバージョンと認識することを特徴とするアプリケーションプログラムの実行方法。
  9. 請求項１〜８のいずれかに記載のアプリケーションプログラムの実行方法において、
    リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが外部の記憶装置もしくはサーバ装置内に保存された実行許可リストに対する登録を行い、
    登録有無判定段階で、コンピュータが前記外部の記憶装置もしくはサーバ装置内に保存された実行許可リストを参照することにより判定を行うことを特徴とするアプリケーションプログラムの実行方法。
  10. 請求項１〜９のいずれかに記載のアプリケーションプログラムの実行方法において、
    リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが実行許可リストを暗号化する処理を行い、
    登録有無判定段階で、コンピュータが暗号化されている実行許可リストを復号して内容の参照を行うことを特徴とするアプリケーションプログラムの実行方法。
  11. 請求項１〜１０のいずれかに記載のアプリケーションプログラムの実行方法において、
    リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが、識別コードとともに、入力段階で入力したデータファイル内に含まれている所定のチェックコードを登録するようにし、
    登録有無判定段階で、コンピュータが、データファイル内に含まれているチェックコードと実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことを特徴とするアプリケーションプログラムの実行方法。
  12. 請求項１〜１０のいずれかに記載のアプリケーションプログラムの実行方法において、
    リスト自動登録段階もしくは回答処理段階で実行許可リストへの登録を行う際に、コンピュータが、識別コードとともに、入力段階で入力したデータファイル内に含まれている所定の情報に対して一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードを登録するようにし、
    登録有無判定段階で、コンピュータが、データファイル内に含まれている前記所定の情報に対して前記一方向性関数を作用させるダイジェスト化処理を行うことにより得られるチェックコードと、実行許可リストに登録されているチェックコードとの一致を確認し、一致確認がなされることを条件として、実行許可リストに登録されている旨の判定を行うことを特徴とするアプリケーションプログラムの実行方法。
  13. 請求項５または６に記載のアプリケーションプログラムの実行方法に用いる監視プログラム。
JP2012190943A 2012-04-24 2012-08-31 アプリケーションプログラムの実行方法 Active JP5126447B1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012190943A JP5126447B1 (ja) 2012-08-31 2012-08-31 アプリケーションプログラムの実行方法
PCT/JP2013/062311 WO2013161974A1 (ja) 2012-04-24 2013-04-19 改竄検知が可能なアプリケーションプログラムの配布実行方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012190943A JP5126447B1 (ja) 2012-08-31 2012-08-31 アプリケーションプログラムの実行方法

Publications (2)

Publication Number Publication Date
JP5126447B1 true JP5126447B1 (ja) 2013-01-23
JP2014048866A JP2014048866A (ja) 2014-03-17

Family

ID=47692925

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012190943A Active JP5126447B1 (ja) 2012-04-24 2012-08-31 アプリケーションプログラムの実行方法

Country Status (1)

Country Link
JP (1) JP5126447B1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014164392A (ja) * 2013-02-22 2014-09-08 Dainippon Printing Co Ltd 情報処理装置および情報処理システム
JP2015087997A (ja) * 2013-10-31 2015-05-07 株式会社東芝 電子機器および方法
JP2019040256A (ja) * 2017-08-22 2019-03-14 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
JP2020161189A (ja) * 2020-07-01 2020-10-01 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
CN112885175A (zh) * 2021-01-15 2021-06-01 杭州安恒信息安全技术有限公司 信息安全赛题生成方法、装置、电子装置和存储介质
CN116569167A (zh) * 2020-12-17 2023-08-08 三菱电机株式会社 信息处理装置、信息处理方法及信息处理程序

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10402059B1 (en) * 2013-12-20 2019-09-03 EMC IP Holding Company LLC System and method of smart framework for troubleshooting performance issues
EP3026558A1 (en) * 2014-11-28 2016-06-01 Thomson Licensing Method and device for providing verifying application integrity
EP3026557A1 (en) * 2014-11-28 2016-06-01 Thomson Licensing Method and device for providing verifying application integrity
JP6829168B2 (ja) 2017-09-04 2021-02-10 株式会社東芝 情報処理装置、情報処理方法およびプログラム
CN108460273B (zh) 2017-12-27 2022-10-14 ***股份有限公司 一种终端的应用管理方法、应用服务器及终端
JP6914899B2 (ja) 2018-09-18 2021-08-04 株式会社東芝 情報処理装置、情報処理方法およびプログラム
JP7249968B2 (ja) * 2020-03-09 2023-03-31 株式会社東芝 情報処理装置およびストレージ

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04163627A (ja) * 1990-10-29 1992-06-09 Hitachi Ltd プログラム変換方法
JPH07146788A (ja) * 1993-11-22 1995-06-06 Fujitsu Ltd ウイルス診断機構の作成システムと作成方法並びにウイルス診断機構と診断方法
JP2002230511A (ja) * 2001-02-01 2002-08-16 Dainippon Printing Co Ltd 多重認証可搬情報処理媒体
JP2004213339A (ja) * 2002-12-27 2004-07-29 Toshiba Corp ソフトウェア無線機及びその制御方法
JP2005293109A (ja) * 2004-03-31 2005-10-20 Canon Inc ソフトウェア実行管理装置、ソフトウェア実行管理方法、及び制御プログラム
WO2006016407A1 (ja) * 2004-08-12 2006-02-16 Fujitsu Limited Ｊａｖａアプレット、ＪＡＲファイル生成方法、ＪＡＲファイル生成プログラム、ＪＡＲファイル生成装置
JP2007249782A (ja) * 2006-03-17 2007-09-27 Nifty Corp 電子データ流出防止プログラム
US20080276314A1 (en) * 2007-05-03 2008-11-06 Microsoft Corporation Software protection injection at load time

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04163627A (ja) * 1990-10-29 1992-06-09 Hitachi Ltd プログラム変換方法
JPH07146788A (ja) * 1993-11-22 1995-06-06 Fujitsu Ltd ウイルス診断機構の作成システムと作成方法並びにウイルス診断機構と診断方法
JP2002230511A (ja) * 2001-02-01 2002-08-16 Dainippon Printing Co Ltd 多重認証可搬情報処理媒体
JP2004213339A (ja) * 2002-12-27 2004-07-29 Toshiba Corp ソフトウェア無線機及びその制御方法
JP2005293109A (ja) * 2004-03-31 2005-10-20 Canon Inc ソフトウェア実行管理装置、ソフトウェア実行管理方法、及び制御プログラム
WO2006016407A1 (ja) * 2004-08-12 2006-02-16 Fujitsu Limited Ｊａｖａアプレット、ＪＡＲファイル生成方法、ＪＡＲファイル生成プログラム、ＪＡＲファイル生成装置
JP2007249782A (ja) * 2006-03-17 2007-09-27 Nifty Corp 電子データ流出防止プログラム
US20080276314A1 (en) * 2007-05-03 2008-11-06 Microsoft Corporation Software protection injection at load time

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014164392A (ja) * 2013-02-22 2014-09-08 Dainippon Printing Co Ltd 情報処理装置および情報処理システム
JP2015087997A (ja) * 2013-10-31 2015-05-07 株式会社東芝 電子機器および方法
JP2019040256A (ja) * 2017-08-22 2019-03-14 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
JP2020161189A (ja) * 2020-07-01 2020-10-01 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
JP7074805B2 (ja) 2020-07-01 2022-05-24 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
CN116569167A (zh) * 2020-12-17 2023-08-08 三菱电机株式会社 信息处理装置、信息处理方法及信息处理程序
CN112885175A (zh) * 2021-01-15 2021-06-01 杭州安恒信息安全技术有限公司 信息安全赛题生成方法、装置、电子装置和存储介质
CN112885175B (zh) * 2021-01-15 2022-10-21 杭州安恒信息安全技术有限公司 信息安全赛题生成方法、装置、电子装置和存储介质

Also Published As

Publication number Publication date
JP2014048866A (ja) 2014-03-17

Similar Documents

Publication Publication Date Title
JP5126447B1 (ja) アプリケーションプログラムの実行方法
JP5190800B2 (ja) プログラムの実行制御システム、実行制御方法、実行制御用コンピュータプログラム
CN100578522C (zh) 电子设备、用于电子设备的更新方法和集成电路
US8381307B2 (en) Method for protecting a converted applet (CAP) file including encrypting the CAP file
US8392724B2 (en) Information terminal, security device, data protection method, and data protection program
CN111143869B (zh) 应用程序包处理方法、装置、电子设备及存储介质
US20100063996A1 (en) Information processing device, information recording device, information processing system, program update method, program, and integrated circuit
JP2019519827A (ja) アプリの偽変造が探知可能な２チャンネル認証代行システム及びその方法
CN101872404B (zh) 一种保护Java软件程序的方法
CN112861191B (zh) 一种应用程序监控方法及装置
CN101228531A (zh) 执行装置
WO2013161974A1 (ja) 改竄検知が可能なアプリケーションプログラムの配布実行方法
JP2008146479A (ja) ソフトウェア部品、ソフトウェア部品管理方法、及びソフトウェア部品管理システム
KR101756978B1 (ko) 트러스티드 실행 환경 기반의 어플리케이션 프로그램 보호 방법 및 시스템
JP5056995B1 (ja) 改竄検知が可能なアプリケーションプログラムの配布実行方法
JP2007233426A (ja) アプリケーション実行装置
WO2012051894A1 (zh) 一种widget应用保护方法及装置
Gallery et al. Trusted computing: Security and applications
JP2006164184A (ja) プログラム分割装置、プログラム実行装置、プログラム分割方法及びプログラム実行方法
JP5182445B1 (ja) アプリケーションプログラムの改竄検知方法
JP7331714B2 (ja) 情報処理装置、情報処理方法及びプログラム
CN111159712B (zh) 检测方法、设备及存储介质
JP2016012902A (ja) 電子データ利用システム、携帯端末装置、及び電子データ利用システムにおける方法
Bahaa-Eldin et al. A comprehensive software copy protection and digital rights management platform
KR101711024B1 (ko) 부정조작방지 장치 접근 방법 및 그 방법을 채용한 단말 장치

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

R150 Certificate of patent or registration of utility model

Ref document number: 5126447

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151109

Year of fee payment: 3