WO2012077300A1 - 情報処理装置、及び、情報処理方法 - Google Patents

Abstract

　安全性を損なうことなく、システムコール処理の応答性を向上させるため、本発明に係る情報処理装置（１００Ａ）は、アプリ識別子を取得することにより情報処理装置において実行中のプログラムを特定するアプリ特定部（１５１１）と、特定されたプログラムが、プログラムコードの呼び出し時に、プログラムのどの部分からプログラムコードを呼び出したかを示す呼び出し元を特定する呼び出し元特定部（１５２３）と、特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理部（１５００）と、特定された呼び出し元とチェック結果とに基づいて、特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する攻撃チェック判定部（１５１０）とを備える。

Description

情報処理装置、及び、情報処理方法

　本発明は、不正なプログラムを付加したコンテンツによる情報の漏洩を防止する技術に関する。

　近年、デジタルカメラなどで撮影した写真データを、デジタルカメラや記録媒体から取り込み、蓄積し、ユーザの要求に応じて蓄積した写真データを表示する機器が普及しつつある。また、このような機器では、機器の所有者が撮影した写真データだけでなく、所有者以外が撮影した写真データや、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）などの他の機器に蓄積されている写真データも取り込み、蓄積する。

　このような機器に対して、不正なプログラムが付加された不正な写真データを取り込ませることにより、機器内部の他の写真データを漏洩させるという攻撃が考えられる。例えば、攻撃者が、ターゲットとする人のＰＣへ、メール等を利用して不正なプログラムが付加された不正な写真データを送付し、その写真データを上記のような機器に取り込ませる。又は、ＣＤ－Ｒ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅｃｏｒｄａｂｌｅ）やＤＶＤ－Ｒ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ　Ｒｅｃｏｒｄａｂｌｅ）等の記録メディアに不正なプログラムが付加された不正な写真データを含む写真データを記録する。記録メディアに記録された写真データをターゲットとする人へ渡すことにより、不正なプログラムが付加された不正な写真データをターゲットが使用する機器へ取り込ませてもよい。不正なプログラムが付加された不正な写真データを用いた攻撃としては、バッファーオーバーフローの脆弱性を利用した攻撃方法がある。

　ここで、バッファーオーバーフローの脆弱性を利用した攻撃方法について説明する。

　まず、アプリ（以後、計算機により実行されるプログラムであって、一定の処理を行う処理部のことを、アプリと呼ぶ）は、実行中に利用するデータをＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）上に確保されたスタック領域に格納する。スタック領域には、アプリ内の関数（アプリの一部分であり、モジュール化された処理部を意味する）ごとにスタックフレームが作られ、スタックフレームは後入れ先出し（ＬＩＦＯ：Ｌａｓｔ　Ｉｎ　Ｆｉｒｓｔ　Ｏｕｔ、ＦＩＬＯ：Ｆｉｒｓｔ　Ｉｎ　Ｌａｓｔ　Ｏｕｔ）の構造で、スタック領域に格納される。

　スタックフレームは、図１８に示す様に、ローカル変数領域２００、退避領域２０１、リターンアドレス２０２、引数領域２０３から構成される。ローカル変数領域２００には、関数内で使用するローカル変数が格納される。退避領域２０１には、関数が呼び出された時のＣＰＵの状態が退避（すなわち、記録）され、関数が終了した時には、記録されたＣＰＵ状態を退避領域から読み出すことで、ＣＰＵは退避前の状態へ復帰する。リターンアドレス２０２には、関数内で定義された処理の終了時に戻る戻り先のアドレス（すなわち、ＲＡＭ内のアドレス）が格納される。引数領域２０３には、関数を呼び出した時の引数が格納される。

　バッファーオーバーフローの脆弱性とは、スタック上のローカル変数領域２００に確保されたバッファー（変数）へ外部から入力されたデータを保存する際に問題となる。具体的には、バッファーのサイズより大きいデータが入力された結果、退避領域２０１、リターンアドレス２０２及び引数領域２０３が書き換えられてしまうという脆弱性である。

　このバッファーオーバーフローの発生時、例えば、攻撃者が写真データを工夫することで、ローカル変数領域２００を不正なプログラムで書き換え、リターンアドレス２０２を不正なプログラムの先頭アドレスに書き換えることができる。これにより、写真データに付加された不正なプログラムを、バッファーオーバーフローが発生した計算機上で実行できる。すなわち、バッファーオーバーフロー攻撃は、（１）特定のアプリ内の関数がバッファーオーバーフローの脆弱性を有しており、かつ、（２）その関数が、不正なプログラムが仕込まれた不正な写真データを読み込むことで、実行される。

　従来のバッファーオーバーフロー攻撃対策としては、カーネルのシステムコール処理などのプログラムコードの呼び出し時に、リターンアドレスが示すアドレスの属性情報（領域情報）に基づいて不正なプログラムからの呼び出しであるかを判断する方法がある（例えば、特許文献１、２参照）。図１９は、前記特許文献１に記載された従来のバッファーオーバーフロー攻撃対策を示すものである。

　図１９において、タスク１０１は、データ領域１０２からのデータの読み込みを伴うシステムコール要求をＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）１０７に入力する。ＯＳ１０７は、システムコール要求をシステムコールテーブル１０３で受けとると、正当性検証部１０４へシステムコール要求の正当性の検査を依頼する。正当性検証部１０４は、システムコール要求の正当性を判定し、判定結果を出力する。正当性検証部１０４が、不正なシステムコール要求と判断した場合、そのシステムコール要求を棄却し、攻撃対策部１１２へ通知する。攻撃対策部１１２は、システムコールを要求したタスク１０１に対して、対策を講じる。一方、正当性検証部１０４が、正当なシステムコール要求と判断した場合、命令実行部１０６にシステムコール１０５を実行させる。

特開２００４－１２６８５４号公報 特開２００９－１９９５２９号公報

　しかしながら、前記従来の構成では、全てのシステムコール要求に対して正当性の検査を実施するため、システムコール要求に対して、処理の応答性が悪化するという課題を有している。

　そこで本発明は、前記従来の課題を解決するもので、安全性を損なうことなく、システムコール処理の応答性を向上させる情報処理装置を提供することを目的とする。

　本発明のある局面に係る情報処理装置は、一意な識別子であるアプリ識別子を有する１以上のプログラムを実行する情報処理装置であって、前記アプリ識別子を取得することにより前記情報処理装置において実行中のプログラムを特定するアプリ特定部と、前記特定されたプログラムが、プログラムコードの呼び出し時に、前記プログラムのどの部分から前記プログラムコードを呼び出したかを示す呼び出し元を特定する呼び出し元特定部と、前記特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理部と、前記特定された呼び出し元と前記チェック結果とに基づいて、前記特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する攻撃チェック判定部とを備える。

　一般に、既に安全であることが確認されたプログラムコード（すなわち、システムコール）の呼び出しであれば、再度、安全性をチェックすることは、計算機資源の無駄となり、システムコール処理の応答性を害する。しかし、プログラムコードは、呼び出し経路で危険性が変化する。よって、過去、安全性をチェックし、安全であることが確認されたプログラムコードであっても、その呼び出し元が異なれば、安全とはいえない。よって、プログラムコードの安全性は、その呼び出し元とセットで、判断する必要がある。

　上記構成によると、呼び出し元特定部は、プログラムコードの呼び出し元を特定することができる。よって、攻撃チェック判定部は、特定された呼び出し元とセットで、プログラムコードが攻撃されているかのチェックする必要があるか否かを判定することができる。その結果、安全性を損なうことなく、システムコール処理の応答性を向上させる情報処理装置を提供することができる。

　具体的には、前記情報処理装置は、さらに、前記特定されたプログラムが攻撃されているかをチェックする攻撃チェック部を備えており、前記攻撃チェック部は、前記攻撃チェック判定部が、前記特定されたプログラムに対して攻撃チェックを行うと判定した場合には、前記特定されたプログラムが攻撃されているか否かをチェックするとしてもよい。

　より具体的には、前記呼び出し元特定部は、前記特定されたプログラムから前記プログラムコードを呼び出した後に前記特定されたプログラムへ実行処理を戻すための戻し先を示すメモリ内のアドレスであるリターンアドレスを用いて、前記呼び出し元を特定するとしてもよい。

　これによると、情報処理装置は、リターンアドレスから、プログラムコードの呼び出し元を具体的に特定することができる。

　さらに、前記呼び出し元特定部は、前記特定されたプログラムから前記プログラムコードを呼び出した場合に前記特定されたプログラムが使用するコールスタックのスタックポインタの値と、前記リターンアドレスとを用いて前記呼び出し元を特定するとしてもよい。

　プログラムコードを呼び出す際のリターンアドレスと、コールスタックのスタックポインタとの２つの情報により、そのプログラムコードの呼び出し元を一意に決定できる。よって、呼び出し元特定部は、これらの情報を取得することで、呼び出し元を特定できる。

　さらに、前記チェックアプリ管理部は、（Ａ）前記特定されたプログラムが攻撃されているか否かをチェックした結果を示す情報、及び、（Ｂ）前記特定されたプログラムが、攻撃されているか否かを判定するチェックが必要であるかを示す情報、の両方を含む情報を前記チェック結果として、前記特定されたプログラムが有する前記アプリ識別子と前記呼び出し元とに対応付けて記憶しているとしてもよい。

　これにより、攻撃チェック判定部は、呼び出し元特定部で特定された呼び出し元からのプログラムコードの呼び出しの安全性を、チェックアプリ管理部に記憶されている過去のチェック結果から、判定することができる。

　具体的には、前記攻撃チェック判定部は、前記特定されたプログラムが有するアプリ識別子に対応付けられて前記チェックアプリ管理部に記憶されている前記チェック結果を取得し、（Ａ）取得した前記チェック結果が、前記特定されたプログラムが攻撃されていないこと、又は、前記特定されたプログラムが攻撃されていることを表す場合には、攻撃されているかのチェックを行わないと判定し、（Ｂ）取得した前記チェック結果が、攻撃されているか否かを判定するチェックが必要であることを表す場合には、攻撃チェック部による攻撃がされているかのチェックを行うと判定するとしてもよい。

　また、さらに、前記特定されたプログラムが前記プログラムコードを呼び出すことにより読み込もうとしているデータファイルを、前記データファイルを示す識別子であるコンテンツ識別子を用いて特定するコンテンツ特定部と、前記特定されたデータファイルを読み込むか否かを判定する読み込み可否判定部とを備え、前記読み込み可否判定部は、（Ａ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されていないか、又は、（Ｂ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されており、かつ、前記チェック結果が、前記特定されたプログラムが攻撃されていないことを示す場合には、前記特定されたデータファイルを読み込むと判定し、（Ｃ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられている前記チェック結果が、前記チェックアプリ管理部に記憶されており、かつ、前記チェック結果が、前記特定されたプログラムが以前に攻撃されたことを示す場合には、前記特定されたデータファイルを読み込まないと判定するとしてもよい。

　一般に、プログラムコードにバッファーオーバーフローの脆弱性があり、かつ、そのプログラムコードがバッファーオーバーフローを利用した攻撃を意図した、悪意あるデータファイルを読み込んだ際に、実質的に危険性が高まる。よって、チェックアプリ管理部に、プログラムコードの呼び出し元と、呼び出されたプログラムコードが読み込むデータファイルの識別子をセットにして、その安全性に関するチェック結果を記録しておくことで、より正確に、安全性を判定することができる。

　また、前記読み込み可否判定部は、前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されていない場合には、前記アプリ識別子で特定されるプログラムが、攻撃されているか否かを判定するチェックが必要であることを示す情報を、前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けて前記チェックアプリ管理部に記憶させるとしてもよい。

　また、前記チェックアプリ管理部は、前記プログラムが削除又は更新された場合には、削除又は更新された前記プログラムが有するアプリ識別子に対応づけられて記憶されているチェック結果を削除するとしてもよい。

　これによると、アプリを最新のものに更新することによりバッファーオーバーフローの脆弱性が修正された場合には、情報処理装置は、読み込み処理を行えるようになる。また、アプリを削除した時、同じアプリ識別子を持つアプリが再度インストールされた場合には、情報処理装置は再度攻撃チェック処理を実施できるようになる。

　また、前記チェックアプリ管理部は、前記チェック結果を、当該チェックアプリ管理部を備える前記情報処理装置、及び、当該チェックアプリ管理部を備える前記情報処理装置とは異なる情報処理装置の少なくとも一方に記憶しているとしてもよい。

　これによると、他の情報処理装置が読み込んだことがあるファイルについては、自身が読み込んだことがなくても、チェックを行うことなく、安全性を判定することができる。

　また、前記チェックアプリ管理部は、前記特定されたデータファイルが変更された場合には、当該変更されたデータファイルを示すコンテンツ識別子に対応づけられて記憶されているチェック結果を削除するとしてもよい。

　これによると、既存のコンテンツが、不正なプログラムが付加されたコンテンツに変更された場合においても、不正なプログラムを検出することができる。

　なお、本発明は、このような情報処理装置として実現できるだけでなく、情報処理装置に含まれる特徴的な手段をステップとする情報処理方法として実現したり、そのような特徴的なステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ　Ｄｉｓｃ　Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）等の記録媒体及びインターネット等の伝送媒体を介して流通させることができるのはいうまでもない。

　さらに、本発明は、このような情報処理装置の機能の一部又は全てを実現する半導体集積回路（ＬＳＩ）として実現したりできる。

　本発明の情報処理装置によれば、安全性を損なうことなく、システムコール処理の応答性を向上させることができる。

図１は、本発明の実施の形態１におけるコンテンツ蓄積・表示システムの全体構成図である。 図２は、本発明の実施の形態１におけるコンテンツ蓄積・表示装置のソフトウェア構成図である。 図３は、本発明の実施の形態１におけるコンテンツ蓄積・表示装置のハードウェア構成図である。 図４は、本発明の実施の形態１における更新サーバの構成図である。 図５は、本発明の実施の形態１における関数の呼び出し関係図である。 図６は、本発明の実施の形態１における情報処理装置を有するＯＳの構成図である。 図７は、本発明の実施の形態１における攻撃チェック結果リストの構成図である。 図８は、本発明の実施の形態１における要チェックアプリリストの構成図である。 図９は、本発明の実施の形態１における情報処理装置の他の構成を示すブロック図である。 図１０は、本発明の実施の形態１におけるチェック要否判定処理のフローチャートである。 図１１は、本発明の実施の形態１におけるファイル読み込み処理のフローチャートである。 図１２は、本発明の実施の形態２における情報処理装置の構成図である。 図１３は、本発明の実施の形態２における攻撃チェック結果リストの構成図である。 図１４は、本発明の実施の形態２におけるチェック要否判定処理のフローチャートである。 図１５は、本発明の実施の形態３におけるコンテンツ蓄積・表示システムの全体構成図である。 図１６は、本発明の実施の形態３における情報処理装置の構成図である。 図１７は、本発明の実施の形態３におけるチェック要否判定処理のフローチャートである。 図１８は、スタックの構成の一例を示す図である。 図１９は、従来のＯＳの構成の一例を示す図である。

　以下、本発明に係る情報処理装置の実施の形態について、図面を参照しながら詳細に説明する。

　以下、本発明の実施の形態について、図面を用いて詳細に説明する。なお、以下で説明する実施の形態は、いずれも本発明の好ましい一具体例を示すものである。以下の実施の形態で示される数値、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。本発明は、請求の範囲だけによって限定される。よって、以下の実施の形態における構成要素のうち、本発明の最上位概念を示す独立請求項に記載されていない構成要素については、本発明の課題を達成するのに必ずしも必要ではないが、より好ましい形態を構成するものとして説明される。

　（実施の形態１）
　本発明の実施の形態１に係る情報処理装置は、カメラやＰＣなどの機器から写真データを取り込み、蓄積し、ユーザの要求に応じて、写真データを表示するコンテンツ蓄積・表示装置である。

　＜コンテンツ蓄積・表示システム１０００の構成＞
　図１は、本発明の実施の形態１におけるコンテンツ蓄積・表示システム１０００の構成図である。

　図１において、コンテンツ蓄積・表示システム１０００は、コンテンツ蓄積・表示装置１００１と、カメラ１０１０と、ＰＣ１０１１と、更新サーバ１０２０とを含む。

　コンテンツ蓄積・表示装置１００１は、カメラ１０１０やＰＣ１０１１などから写真データを取り込み、蓄積する。また、蓄積した写真データを、ユーザの要求に応じて表示する。さらに、記録ディスク１０３０などの記録媒体を読み取るための読み取り部を持ち、ユーザ以外が撮影した写真データを取り込むことも可能である。

　コンテンツ蓄積・表示装置１００１は、これらコンテンツの蓄積及び表示機能を実現するため、一意な識別子であるアプリ識別子を有する１以上のプログラムをＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）で実行する。

　カメラ１０１０は、コンテンツ蓄積・表示装置１００１とＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）や無線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）などを用いて接続される。カメラ１０１０は、ユーザが旅行などのイベントで写真を撮影した写真データを、カメラ１０１０に内蔵された不揮発メモリや、取り出し可能な記録媒体へ記録する。また、カメラ１０１０が、コンテンツ蓄積・表示装置１００１と接続された時に、記録した写真データをコンテンツ蓄積・表示装置１００１へ転送する。また、ユーザが、カメラ１０１０から記録媒体を取り出し、コンテンツ蓄積・表示装置１００１へ装着することにより、記録媒体に記録した写真データをコンテンツ蓄積・表示装置１００１へ転送することも可能である。

　ＰＣ１０１１は、ネットワークに接続され、ユーザがメールを受信したり、Ｗｅｂブラウジングを行う際に使用される計算機である。また、ＰＣ１０１１は、コンテンツ蓄積・表示装置１００１ともネットワークで接続される。メールに添付された写真データやＷｅｂブラウジング時にダウンロードした写真データなどは、ネットワークを介して、ＰＣ１０１１からコンテンツ蓄積・表示装置１００１へ取り込む。

　更新サーバ１０２０は、コンテンツ蓄積・表示装置１００１とネットワークで接続される。更新サーバ１０２０は、コンテンツ蓄積・表示装置１００１用の更新用ソフトウェアを格納し、コンテンツ蓄積・表示装置１００１からの要求に応じて、コンテンツ蓄積・表示装置１００１へ、更新用ソフトウェアを転送する。更新用ソフトウェアは、コンテンツ蓄積・表示装置１００１内で動作するソフトウェアに不具合が見つかった場合や、ソフトウェアに機能を追加する場合などに作成する。

　記録ディスク１０３０は、写真データを記録するための記録媒体である。

　また、コンテンツ蓄積・表示装置１００１は、本発明に係る情報処理装置を有する。

　＜コンテンツ蓄積・表示装置１００１のソフトウェア構成＞
　図２は、本発明の実施の形態１におけるコンテンツ蓄積・表示装置１００１のソフトウェア構成図である。

　図２において、コンテンツ蓄積・表示装置１００１は、ＯＳ１１０１と、コンテンツ収集アプリ１１０２と、表示アプリ１１０３と、編集アプリ１１０４と、管理アプリ１１０５とを備える。

　ＯＳ１１０１は、情報処理装置１００を有する。ＯＳ１１０１は、ＯＳ１１０１上で動作するアプリ（コンテンツ収集アプリ１１０２や表示アプリ１１０３、編集アプリ１１０４、管理アプリ１１０５等のプログラム）を、メモリ上にロードして実行する。また、ＯＳ１１０１が管理するリソースに対して、アプリから利用要求があった時に、ＯＳ１１０１は、要求してきたアプリがそのリソースを利用する権限があるかを確認する。確認の結果、権限があると判定した場合には、ＯＳ１１０１は、情報処理装置１００を介してアプリにリソースを提供する。アプリからＯＳ１１０１への要求としては、ファイルへの読み込み要求や書き込み要求、また、ネットワークで接続された他の機器への接続要求などがある。

　コンテンツ収集アプリ１１０２は、カメラ１０１０やＰＣ１０１１、記録ディスク１０３０に記録された写真データを収集し、コンテンツ蓄積・表示装置１００１内に蓄積するアプリである。コンテンツ収集アプリ１１０２は、カメラ１０１０などの機器がＵＳＢや無線ＬＡＮなどで接続されるかを監視し、接続されたことを検出した場合には、その機器内や機器に装着された記録メディアに記録されている写真データを収集する。また、ネットワーク接続を監視し、ＰＣ１０１１などの機器が接続されたことを検出した場合には、その機器内に記録されている写真データを収集する。コンテンツ収集アプリ１１０２は、収集した写真データをコンテンツ蓄積・表示装置１００１内の不揮発性記憶装置へ保存し、蓄積する。

　表示アプリ１１０３は、コンテンツ収集アプリ１１０２が蓄積した写真データを液晶ディスプレイなどの表示装置に表示するアプリである。表示アプリ１１０３は、写真データに付属するサムネイル画像を一覧表示したり、ユーザが指定した１つの写真データを表示したりする。また、表示アプリ１１０３は、ユーザが選択した複数の写真データを、一定時間間隔で表示するスライドショー表示も行う。

　編集アプリ１１０４は、コンテンツ蓄積・表示装置１００１に保存している写真データを編集するアプリである。編集アプリ１１０４は、ユーザの選択に応じて、編集した写真データを新しい写真データとして保存したり、編集した写真データを上書き保存する。また、編集アプリ１１０４は、ユーザが不要と判断した写真データを、コンテンツ蓄積・表示装置１００１から削除する。

　管理アプリ１１０５は、コンテンツ蓄積・表示装置１００１内にインストールされているアプリやＯＳを管理する。管理アプリ１１０５は、更新サーバ１０２０と通信し、コンテンツ蓄積・表示装置１００１内にインストールされているアプリやＯＳ用の更新用ソフトウェアがあるか定期的に確認する。管理アプリ１１０５は、更新用ソフトウェアを検出した場合、ユーザに対して通知を行い、該当するアプリやＯＳの更新用ソフトウェアを更新サーバ１０２０から受信し、更新処理を行う。

　＜コンテンツ蓄積・表示装置１００１のハードウェア構成＞
　図３は、本発明の実施の形態１におけるコンテンツ蓄積・表示装置１００１のハードウェア構成図である。

　図３において、コンテンツ蓄積・表示装置１００１は、システムＬＳＩ１２００と、メモリ１２１０と、不揮発性記憶装置１２２０とを含む。

　システムＬＳＩ１２００は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１２０１と、カードＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）１２０２と、ネットワークＩ／Ｆ１２０３と、入出力Ｉ／Ｆ１２０４とを含む。

　ＣＰＵ１２０１は、メモリ１２１０に格納されたＯＳ１１０１や各アプリに含まれる命令コードを実行することにより、コンテンツ蓄積・表示装置１００１全体の動作を制御する。また、ＣＰＵ１２０１は、特権モードと非特権モードの２つのモードを持つ。ＯＳ１１０１は特権モードで動作し、メモリ１２１０やカードＩ／Ｆ１２０２、ネットワークＩ／Ｆ１２０３、入出力Ｉ／Ｆ１２０４などの各種リソースに、自由にアクセスできる。したがって、ＯＳ１１０１が有する本発明に係る情報処理装置１００は、特権モードで動作する。

　また、コンテンツ収集アプリ１１０２と、表示アプリ１１０３と、編集アプリ１１０４と、管理アプリ１１０５は非特権モードで動作し、ＯＳ１１０１が設定した範囲内のみアクセス可能である。　メモリ１２１０は、ＯＳ１１０１と、コンテンツ収集アプリ１１０２と、表示アプリ１１０３と、編集アプリ１１０４と、管理アプリ１１０５とを格納する。なお、図３は、図２に示されるソフトウェア構成の各要素をメモリ１２１０にロードした様子を示している。

　不揮発性記憶装置１２２０は、呼び出し元チェック結果表１２２１と、コンテンツＡ１２２２と、コンテンツＢ１２２３とを格納する。また、図示しないが、不揮発性記憶装置１２２０は、図２に示されるソフトウェア構成をメモリ１２１０にロードする前の各構成要素を格納する。具体的には、図２に示されるコンテンツ収集アプリ１１０２、表示アプリ１１０３、編集アプリ１１０４、及び管理アプリ１１０５は、それぞれ、図３に示されるメモリ１２１０に格納されたコンテンツ収集アプリ１１０２、表示アプリ１１０３、編集アプリ１１０４、及び管理アプリ１１０５に対応する。これらの各構成要素を実現するためのソフトウェアが、ＣＰＵ１２０１上で実行されることにより、各機能が実現される。

　コンテンツ蓄積・表示装置１００１は、さらに、図３に図示されていない液晶ディスプレイなどの入出力装置を備えているが、これらは本発明の本質ではないので説明を省略する。また、システムＬＳＩ１２００は、さらに、図３に図示されていない周辺回路などを備えているが、これらは本発明の本質ではないので説明を省略する。また、メモリ１２１０は、さらに、図２や図３に図示されていないアプリや、写真データを処理するための作業領域を格納していてもよい。また、不揮発性記憶装置１２２０は、さらに、図２や図３に図示されていないアプリや、コンテンツを格納していてもよい。

　＜更新サーバ１０２０の構成＞
　図４は、本発明の実施の形態１における更新サーバ１０２０の構成図である。

　図４において、更新サーバ１０２０は、更新処理受付部１３００と、更新用ソフトウェア保持部１３０１とを含む。

　更新処理受付部１３００は、コンテンツ蓄積・表示装置１００１の管理アプリ１１０５から問い合わせを受ける。問い合わせの結果、更新が必要な場合には、更新処理受付部１３００は、管理アプリ１１０５と連携して、コンテンツ蓄積・表示装置１００１内のソフトウェアの更新処理を行う。更新処理において、更新処理受付部１３００は、更新用ソフトウェア保持部１３０１から更新用ソフトウェアを取得し、管理アプリ１１０５へ送信する。

　更新用ソフトウェア保持部１３０１は、コンテンツ蓄積・表示装置１００１内のソフトウェアの更新処理に必要な更新用ソフトウェアを保持する。

　＜攻撃チェック処理の実施タイミング＞
　攻撃チェック処理（すなわち、アプリが攻撃されているか否かを判定する処理）は、攻撃される前には実施する必要がなく、攻撃された後に実施する必要がある。つまり、攻撃される可能性のあるタイミングが分かれば、その直後に攻撃チェック処理を実施すればよいことになる。なぜなら、攻撃された後、すなわち、実行中のアプリが使用するコールスタック上で不正なプログラムが動作している状態でなければ、攻撃されているか否かを判定することは困難なためである。よって、攻撃された直後に、攻撃チェック処理を実施できることが望ましい。

　本発明の実施の形態１におけるコンテンツ蓄積・表示装置１００１は、ＰＣの様に、ユーザが自由にアプリを追加したり、ネットワークを経由して写真データやアプリをダウンロードしたり出来ない装置である。そのため、攻撃者が、コンテンツ蓄積・表示装置１００１を攻撃するためには、コンテンツ蓄積・表示装置１００１が取り込む写真データなどの写真データを細工する方法しかない。例えば、攻撃者は、コンテンツ蓄積・表示装置１００１内で写真データを表示する表示アプリ１１０３の脆弱性（バッファーオーバーフロー等）を衝くような細工を行った写真データ（不正なプログラムを付加したコンテンツ）を作成する。攻撃者は、この細工を行った写真データをコンテンツ蓄積・表示装置１００１に取り込ませることで、コンテンツ蓄積・表示装置１００１を攻撃する。

　上記の攻撃を行う時、コンテンツ蓄積・表示装置１００１は、表示アプリ１１０３で不正なプログラムを付加したコンテンツを読み込み、表示処理を行おうとしたタイミングで攻撃される。そのため、攻撃チェック処理は、写真データの読み込み処理を行った後のタイミングで実施する必要がある。

　そこで、本発明の実施の形態１では、コンテンツ蓄積・表示装置１００１が写真データの読み込み処理を行った後、その次のシステムコール要求のタイミングで攻撃チェック処理を実施する。

　また、バッファーオーバーフローの脆弱性を利用して攻撃する場合は、不正なプログラムを付加したコンテンツを表示アプリ１１０３が読み込めば、必ずバッファーオーバーフローが発生し、不正なプログラムが動作する。つまり、表示アプリ１１０３が攻撃されれば、その時に読み込んだ写真データは、不正なプログラムを付加したコンテンツであり、攻撃されなければ、通常の写真データを読み込んだと判断できる。

　そこで、以前読み込んで攻撃されなかった写真データを再度読み込んだ時、コンテンツ蓄積・表示装置１００１は、その次のシステムコール要求のタイミングで攻撃チェック処理を実施しない。これにより、攻撃チェック処理の実施を省くことが出来る。

　但し、写真データが、表示アプリ１１０３のどの部分で処理されたかにより、攻撃チェック処理の実施を省ける場合とそうでない場合がある。

　図５は、表示アプリ１１０３内の関数呼び出し関係を表した模式図である。

　図５において、表示アプリ１１０３は、ｍａｉｎ関数１５６０と、サムネイル取得関数１５６１と、データ本体取得関数１５６２と、ｒｅａｄ関数１５６３とを含む。

　ｍａｉｎ関数１５６０は、コンテンツ蓄積・表示装置１００１が蓄積している写真データを、サムネイルを用いて一覧表示したり、ユーザがサムネイルから選択した写真データを表示する処理を行う。

　サムネイル取得関数１５６１は、コンテンツ蓄積・表示装置１００１が蓄積している写真データからサムネイルデータを取得する。

　データ本体取得関数１５６２は、コンテンツ蓄積・表示装置１００１が蓄積している写真データから写真本体のデータを取得する。

　ｒｅａｄ関数１５６３は、サムネイル取得関数１５６１又はデータ本体取得関数１５６２から写真データの読み込み依頼を受けて、ＯＳ１１０１に対して、ファイル読み込みのシステムコール要求を行う。

　図５の表示アプリ１１０３において、例えば、データ本体取得関数１５６２にバッファーオーバーフローの脆弱性があった場合を考える。表示アプリ１１０３が、サムネイル表示を行う時には、ｍａｉｎ関数１５６０からサムネイル取得関数１５６１とｒｅａｄ関数１５６３とを経由し、ＯＳ１１０１に対して、ファイル読み込みのシステムコール要求を行う（経路１）。この場合、経路１の途中にバッファーオーバーフローの脆弱性を持つ関数はないため、攻撃されることはない。しかし、これだけの理由で、その後ユーザが同じ写真を選択し、この写真データの本体を表示する時に、攻撃チェック処理を実施しなくてもよいと判断することは危険である。バッファーオーバーフローの脆弱性を利用した攻撃は、前述の通り、不正なデータを、バッファーオーバーフローの脆弱性を有する関数から呼び出した時に、はじめて実行され、検出も可能になるためである。

　具体的に、写真データ本体の表示では、ｍａｉｎ関数１５６０からデータ本体取得関数１５６２とｒｅａｄ関数１５６３とを経由し、ＯＳ１１０１に対して、ファイル読み込みのシステムコール要求を行う（経路２）。ここで、経路２の途中にあるデータ本体取得関数１５６２にバッファーオーバーフローの脆弱性があるとする。この場合、読み込んだ写真データが、不正なプログラムが付加されたコンテンツであった場合、コンテンツ蓄積・表示装置１００１は不正なプログラムによって攻撃される。

　以上述べたように、攻撃チェック処理の実施を省くかどうかを、過去にその写真データを読み込んだか読み込んでいないかだけで単純に判断した場合、アプリに脆弱性があった場合には、攻撃される可能性が残る。よって、攻撃チェックが必要か否かを判定する際には、関数呼び出し関係における経路を特定し、特定された経路を考慮して、判定する仕組みが必要となる。

　そこで、本発明の実施の形態１に係る情報処理装置１００は、経路が異なる場合は、その途中で実行される関数が異なることを利用して、経路の違いを判定する。具体的には、経路が異なる場合には、システムコールを要求した時のアプリ（例えば、図５では表示アプリ１１０３）のスタックポインタの値が異なる値になることを利用して、経路の違いを判定する。そのため、後述するように、攻撃チェック判定部１５１０が判定に利用する攻撃チェック結果リスト１５３０には、アプリ識別子とコンテンツ識別子以外に、システムコールを要求した時の呼び出し元アドレスとスタックポインタ値も、チェック結果に対応付けられて、一緒に格納される。

　＜情報処理装置１００の構成＞
　図６は、本発明の実施の形態１におけるＯＳ１１０１が有する情報処理装置１００の構成図である。

　図６において、情報処理装置１００は、チェックアプリ管理部１５００と、システムコール管理部１５０１と、ファイル読み込み管理部１５０２とを含む。

　チェックアプリ管理部１５００は、アプリが攻撃されているかをチェックしたチェック結果を管理する。また、攻撃されているかチェックする必要があるアプリを管理する。

　具体的には、チェックアプリ管理部１５００は、（Ａ）アプリ特定部１５１１により特定されたプログラム（アプリ）が攻撃されているか否かをチェックした結果、及び、（Ｂ）特定されたプログラムが、攻撃されているか否かを判定するチェックが必要であるかを示す情報、の両方を含む情報であるチェック結果を、特定されたプログラムが有するアプリ識別子と、呼び出し元とに対応付けて記憶している。

　より具体的には、チェックアプリ管理部１５００は、図７に示される攻撃チェック結果リスト１５３０を有している。チェックアプリ管理部１５００は、攻撃チェック結果リスト１５３０を更新することにより、チェック結果の管理を行う。

　なお、本発明の実施の形態１～３において、「アプリが攻撃されている」とは、アプリに存在するバッファーオーバーフローの脆弱性を衝かれて、アプリのスタック上で不正なプログラムが動作している状態を意味する。

　図７は、攻撃チェック結果リスト１５３０の一例を示している。この攻撃チェック結果リスト１５３０は、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果とを含む。

　アプリ識別子は、ＯＳ１１０１上で動作するアプリを特定する識別子である。アプリ識別子は、例えば本発明の実施の形態１においては、アプリのファイル名である。

　コンテンツ識別子は、不揮発性記憶装置１２２０に格納される写真データファイルを識別するための識別子である。コンテンツ識別子は、例えば本発明の実施の形態１においては、写真データファイルのファイル名である。

　呼び出し元アドレスは、アプリがシステムコールを要求した時におけるアプリの実行コードのアドレスである。例えば、表示アプリが写真データの読み込み要求をした時の表示アプリの実行コードのアドレスである。すなわち、呼び出し元アドレスは、本発明の実施の形態１においては、ＯＳ１１０１から表示アプリへ戻る時に使用するリターンアドレスとして使用されるアドレスである。

　スタックポインタ値は、アプリがシステムコールを要求した時におけるアプリのスタックポインタの値である。例えば、表示アプリが写真データの読み込み要求をした時の、表示アプリのスタックポインタの値である。

　チェックアプリ管理部１５００は、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値とを、ファイル読み込み管理部１５０２から受け取る。

　攻撃チェック結果リスト１５３０には、攻撃チェック部１５１２によるチェック結果として、攻撃されたかどうかのチェック結果“○”、“×”、又は、攻撃されているかのチェックが必要なことを示す“要”の３つの値のうちいずれかが格納される。ここで、チェック結果が“○”であれば、対応するアプリ識別子を有するプログラム（アプリ）が攻撃されていないことを表す。また、チェック結果が“×”であれば、攻撃されていることを表す。また、チェック結果が“要”であれば、攻撃されているか否かを判定するチェックが必要であることを表す。なお、“○”、“×”、“要”という表記は、いずれも例示であり、任意のその他の文字や記号が攻撃チェック結果リスト１５３０に格納されてもよい。例えば、“○”の代わりに“ＯＫ”を、“×”の代わりに“ＮＧ”を、“要”の代わりに“不明”等を使用してもよい。

　チェック結果は、システムコール管理部１５０１が備える攻撃チェック部１５１２からチェックアプリ管理部１５００が受け取る。

　なお、攻撃チェック結果リスト１５３０は、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果とを含めばよく、その順番はこれに限らない。例えば、コンテンツ識別子、アプリ識別子、呼び出し元アドレス、スタックポインタ値、チェック結果の順番でも、チェック結果、アプリ識別子、コンテンツ識別子、呼び出し元アドレス、スタックポインタ値の順番でもよい。

　また、攻撃チェック結果リスト１５３０のデータ構造は、図７に示される表の形式である必要はない。アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果との組み合わせを識別できる形式であればよい。例えば、横軸にアプリ識別子、縦軸にコンテンツ識別子を持つ表を用い、それぞれのアプリ識別子とコンテンツ識別子の組み合わせごとに、呼び出し元アドレスとスタックポインタ値との組み合わせのリストへのリンクを持っていてもよい。

　再度、図６を参照し、チェックアプリ管理部１５００は、アプリ識別子で示されるアプリのチェックが必要かどうかの問い合わせをシステムコール管理部１５０１から受ける。チェックアプリ管理部１５００は、システムコール管理部１５０１から問い合わせを受けると、攻撃チェック結果リスト１５３０から、アプリのチェック結果を取得し、その取得したチェック結果を返す。

　また、チェックアプリ管理部１５００は、攻撃されていないかをチェックしたチェック結果とアプリ識別子とをシステムコール管理部１５０１が備える攻撃チェック部１５１２から受け取り、受け取ったチェック結果を攻撃チェック結果リスト１５３０へ記録する。

　システムコール管理部１５０１は、攻撃チェック判定部１５１０と、アプリ特定部１５１１と、攻撃チェック部１５１２とを備える。

　システムコール管理部１５０１は、システムコールを要求したアプリが攻撃されているかどうかを、攻撃チェック判定部１５１０を用いて判定する。攻撃されていないと判定した場合には、要求されたシステムコールの処理を実行する。攻撃されていると判定した場合には、システムコールを要求したアプリに対してエラーを返す。なお、システムコール要求時のチェック要否判定処理の詳細は、フローチャートを用いて後ほど説明する。

　攻撃チェック判定部１５１０は、システムコールを要求したアプリに対して、攻撃されているかどうかをチェックする必要があるかを判定する。具体的には、攻撃チェック判定部１５１０は、アプリ特定部１５１１で特定されたプログラムの呼び出し元に基づいて、特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する。

　より具体的には、攻撃チェック判定部１５１０は、特定されたプログラムが有するアプリ識別子に対応付けられてチェックアプリ管理部１５００が有する攻撃チェック結果リスト１５３０に記憶されているチェック結果を取得する。取得したチェック結果が、プログラム（アプリ）が攻撃されていないこと、又は、プログラム（アプリ）が攻撃されていることを表す場合には、攻撃チェック判定部１５１０は、攻撃されているかのチェックを行わないと判定する。一方、取得したチェック結果が、攻撃されているか否かを判定するチェックが必要である（すなわち、安全か否かが不明である）ことを表す場合には、攻撃チェック判定部１５１０は、攻撃チェック部１５１２によるチェックを行うと判定する。

　さらに具体的には、攻撃チェック判定部１５１０は、チェックアプリ管理部１５００からシステムコールを要求したアプリの攻撃チェック結果を取得する。取得したチェック結果が“要”であった場合には、攻撃チェック判定部１５１０は、攻撃チェック部１５１２へチェックを依頼する。また、チェック結果が“○”であった場合には、チェックを行わず、要求されたシステムコール処理を実行する。また、チェック結果が“×”であった場合には、システムコールを要求したアプリへエラーを返す。また、チェック結果がいずれの場合であっても、攻撃チェック判定部１５１０は、攻撃チェック部１５１２から取得したチェック結果の登録をチェックアプリ管理部１５００へ依頼する。

　アプリ特定部１５１１は、システムコールを要求したアプリを特定する。具体的には、コンテンツ蓄積・表示装置１００１で実行されているプログラムが有するアプリ識別子を取得することで、システムコールを要求したアプリを特定する。

　本発明の実施の形態１においては、アプリ特定部１５１１は、ＯＳ１１０１が管理するプロセス管理用の構造体に格納されているファイル名をアプリ識別子として用いて、アプリを特定する。アプリ特定部１５１１は、アプリ識別子であるアプリのファイル名を攻撃チェック判定部１５１０へ通知する。

　攻撃チェック部１５１２は、攻撃チェック判定部１５１０が、アプリ特定部１５１１で特定されたアプリに対して攻撃チェックを行うと判定した場合には、そのアプリ（すなわち、システムコールを要求したアプリ）が攻撃されているか否かをチェックする。

　チェック方法としては、例えば、前述した特許文献１又は特許文献２に詳しく説明されている。また、他のチェック方法を用いてもよい。

　ファイル読み込み管理部１５０２は、読み込み可否判定部１５２０と、コンテンツ特定部１５２１と、アプリ特定部１５２２と、呼び出し元特定部１５２３とを備える。

　ファイル読み込み管理部１５０２は、アプリからシステムコールによりファイル読み込みが要求された時に、システムコール管理部１５０１から呼び出され、ファイルの読み込み処理を行う。ファイル読み込み管理部１５０２は、ファイルの読み込み処理時に、攻撃チェック結果リスト１５３０を参照し、読み込み処理を実施するかどうかを判定する。なお、ファイル読み込み処理の詳細は、フローチャートを用いて後ほど説明する。

　読み込み可否判定部１５２０は、後述するコンテンツ特定部１５２１により特定されたデータファイルを読み込むか否かを判定する。すなわち、読み込み可否判定部１５２０は、（Ａ）コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部１５００に記憶されていないか、又は、（Ｂ）コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部１５００に記憶されており、かつ、チェック結果が、アプリ特定部１５１１により特定されたプログラム（アプリ）が攻撃されていないことを示す場合には、特定されたデータファイルを読み込むと判定する。

　また、コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられているチェック結果がチェックアプリ管理部１５００に記憶されており、かつ、チェック結果が、アプリ特定部１５１１により特定されたプログラム（アプリ）が以前に攻撃されたことを示す場合には、読み込み可否判定部１５２０は、特定されたデータファイルを読み込まないと判定する。

　より具体的には、読み込み可否判定部１５２０は、チェックアプリ管理部１５００から攻撃チェック結果を取得し、取得したチェック結果に応じて、読み込み可否を判定する。読み込み可否判定部１５２０は、チェック結果が“○”の場合は、読み込み可と判定し、チェック結果が“×”の場合は、読み込み不可と判定する。

　また、読み込み可否判定部１５２０は、攻撃チェック結果リスト１５３０にチェック結果が登録されていなかった場合には、読み込み可と判定し、チェックアプリ管理部１５００へチェック結果“要”を登録するように依頼する。すなわち、読み込み可否判定部１５２０は、判定を行った際に、コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部に記憶されていない場合には、アプリ特定部１５１１により特定されたプログラムが、攻撃されているか否かを判定するチェックが必要であることを示す情報を、コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けてチェックアプリ管理部１５００に記憶させる。

　より詳細には、後述する。

　コンテンツ特定部１５２１は、アプリ特定部１５１１で特定されたプログラム（アプリ）がプログラムコード（すなわち、システムコール）を呼び出すことにより読み込もうとしているデータファイルを、そのデータファイルを示す識別子であるコンテンツ識別子を用いて特定する。

　コンテンツ特定部１５２１は、例えば、ユーザの操作により表示アプリ１１０３が読み込んだ写真データを特定する。本発明の実施の形態１においては、コンテンツ特定部１５２１がデータファイルを特定するための方法として、読み込み依頼時に通知されるファイル識別子に格納されている写真データのファイル名を用いて、写真データを特定する方法を用いる。コンテンツ特定部１５２１は、写真データのファイル名をコンテンツ識別子として読み込み可否判定部１５２０へ通知する。

　アプリ特定部１５２２は、システムコール管理部１５０１が有するアプリ特定部１５１１と同じ機能を持つが、アプリ識別子を読み込み可否判定部１５２０へ通知する点が異なる。すなわち、アプリ特定部１５１１は、攻撃チェック結果リスト１５３０を参照するためにアプリ識別子を取得する。一方、アプリ特定部１５２２は、攻撃チェック結果リスト１５３０を更新するためにアプリ識別子を取得する。

　呼び出し元特定部１５２３は、アプリ特定部１５１１により特定されたプログラム（アプリ）が、プログラムコードの呼び出し時に、プログラムのどの部分からプログラムコードを呼び出したかを特定する。具体的には、呼び出し元特定部１５２３は、ＯＳ１１０１のファイルの読み込み処理を呼び出した呼び出し元が、アプリのどの部分であるかを特定する。

　本発明の実施の形態１に係る呼び出し元特定部１５２３は、呼び出し元を特定するための方法として、アプリが写真データの読み込み要求をした時のアプリの実行コードのアドレスとスタックポインタの値とを用いて、呼び出し元を特定する。すなわち、呼び出し元特定部１５２３は、アプリ特定部１５１１により特定されたプログラム（アプリ）からプログラムコード（システムコール）を呼び出した場合の、（Ａ）プログラムコードの実行処理後、特定されたプログラムへ実行処理を戻すための戻し先を示すメモリ内のアドレスであるリターンアドレスと、（Ｂ）特定されたプログラムが使用するコールスタックのスタックポインタの値とを用いて、呼び出し元を特定する。より具体的には、呼び出し元特定部１５２３は、ファイルの読み込み処理終了時にアプリに戻るためのリターンアドレスと、ファイルの読み込み要求をした時点でのアプリのスタックポインタの値を利用して、呼び出し元を特定する。

　なお、本発明の実施の形態１では、攻撃チェック判定部１５１０は攻撃チェック結果リスト１５３０を用いて攻撃チェック処理を行うかを判定したが、本発明はこれに限定されるものではない。例えば、チェックアプリ管理部１５００は、攻撃チェック処理が必要なアプリを要チェックアプリリスト１５３１として、攻撃チェック結果リスト１５３０とは別に管理してもよい。要チェックアプリリスト１５３１の構造の一例を図８に示す。この場合、チェックアプリ管理部１５００は、攻撃チェック結果リスト１５３０には、チェック結果として“○”又は“×”のみを格納する。

　この場合、チェックアプリ管理部１５００は、読み込み可否判定部１５２０からチェック結果“要”を登録するように依頼された場合には、図８に示される要チェックアプリリスト１５３１へ依頼されたアプリを登録する。また、攻撃チェック判定部１５１０は、チェックアプリ管理部１５００が備える要チェックアプリリスト１５３１へ、システムコールを要求したアプリのアプリ識別子が登録されているかを問い合わせる。

　また、攻撃チェック判定部１５１０は、攻撃チェック部１５１２によるチェック結果が“×”の場合、チェック結果が“×”となったコンテンツ識別子と同じコンテンツ識別子に関連するチェック結果を、全て“×”にするようにチェックアプリ管理部１５００へ依頼してもよい。具体的には、チェックアプリ管理部１５００は、過去のチェック結果に“×”が含まれているコンテンツ識別子と同じコンテンツ識別子を有する攻撃チェック結果リスト１５３０内の全ての行のチェック結果を“×”にしてもよい。

　さらに、“×”となったアプリ識別子と同じアプリ識別子に関連するチェック結果を、全て“×”にしてもよい。具体的には、チェックアプリ管理部１５００は、過去のチェック結果に“×”が含まれているアプリ識別子と同じアプリ識別子を有する攻撃チェック結果リスト１５３０内の全ての行のチェック結果を“×”にしてもよい。

　また、読み込み可否判定部１５２０は、過去のチェック結果に“×”が含まれているコンテンツ識別子と同じコンテンツ識別子を有する写真データ等の場合は、その写真データ等を読み込まないとしてもよい。さらに、過去のチェック結果に“×”が含まれている呼び出し元アドレスと同じ呼び出し元アドレスからの呼び出しは実行せず、その写真データ等を読み込まないとしてもよい。また、読み込み可否判定部１５２０は、アプリ識別子のほか、呼び出し元アドレスとスタックポインタの値とに関して同様の処理を行ってもよい。

　なお、システムコール管理部１５０１とファイル読み込み管理部１５０２は、別々に存在せずともよい。例えば、ファイル読み込み管理部１５０２がシステムコール管理部１５０１の内部にあってもよい。

　図９は、情報処理装置の、他の構成を示したブロック図である。

　図９に示されるように、情報処理装置１００Ａは、アプリ特定部１５１１と、呼び出し元特定部１５２３と、攻撃チェック判定部１５１０と、チェックアプリ管理部１５００とを備えている。

　この構成によっても、情報処理装置１００Ａは、図６に示される情報処理装置１００と同様の効果を奏する。

　すなわち、情報処理装置１００Ａは、システムコールを要求したアプリを特定するアプリ識別子を、アプリ特定部１５１１から取得できる。

　また、情報処理装置１００Ａは、アプリ識別子で特定されるアプリがシステムコールを要求した際の、アプリの実行スタックにおけるスタックポインタと、リターンアドレスとを、呼び出し元特定部１５２３から取得できる。

　また、攻撃チェック判定部１５１０が、攻撃チェック結果リスト１５３０を有するチェックアプリ管理部１５００に問い合わせることで、情報処理装置１００Ａは、スタックポインタとリターンアドレスとで特定される呼び出し経路をたどるシステムコール要求が、既に安全性が確認されているか否かを判定することができる。

　よって、図９の構成によっても、情報処理装置１００と同様の発明の効果を奏する。したがって、１度安全性が確認された呼び出し経路をたどるシステムコール要求については、攻撃チェックを省略することにより、情報処理装置１００Ａは、迅速にシステムコール要求を処理することができる。

　なお、本発明の実施の形態１では、読み込み可否判定部１５２０は、攻撃チェック結果リスト１５３０にチェック結果が登録されていなかった場合には、チェックアプリ管理部１５００へチェック結果“要”を登録するとしたが、これに限定されるものではない。読み込み可否判定部１５２０は、アプリから読み込みを依頼された写真データの取り込み元に応じて、チェック不要と判定してもよい。この時、チェック結果として“要”ではなく、“○”を登録する。読み込み可否判定部１５２０が、チェック不要と判定すべき取り込み元としては、写真データを攻撃者が書き換えられない、例えば、カメラ１０１０などがある。

　また、上記とは逆に、特定の取り込み元から取り込んだ時のみチェックしてもよい。この時、読み込み可否判定部１５２０は、特定の取り込み元から取り込んだ写真データの読み込みを依頼された場合のみ、チェック結果“要”を登録する。また、それ以外の取り込み元であった場合には、チェック結果として“○”を登録する。チェックする取り込み元としては、写真データを攻撃者が書き換えられる機器、例えば、ＰＣ等がある。また、Ｉｎｔｅｒｎｅｔなどのネットワークを経由して取り込んだ写真データは全てチェックするとしてもよい。

　＜チェック要否判定処理＞
　システムコール管理部１５０１は、システムコールを要求したアプリが攻撃されているかどうかを、攻撃チェック判定部１５１０を用いて判定する。攻撃されていないと判定した場合にのみ、要求されたシステムコールの処理を実行することで、不正なシステムコール要求の実行を防止する。この時、システムコールを要求したアプリに対して、そのアプリが攻撃されているかどうかのチェックが必要か判定し、チェックが必要な場合のみチェック処理を実行することで、システムコール要求時のＯＳ１１０１による処理を高速化する。

　以下、表示アプリ１１０３がＯＳ１１０１へシステムコールを依頼した時に、表示アプリ１１０３が攻撃されているかをチェックする必要があるか否かを判定する、チェック要否判定処理について、図１０のフローチャートを用いて説明する。

　まず、表示アプリ１１０３は、ＯＳ１１０１が有する情報処理装置１００のシステムコール管理部１５０１へシステムコールを依頼する（Ｓ１０００）。

　システムコール管理部１５０１は、アプリ特定部１５１１を利用して、システムコールを依頼したアプリである依頼アプリの識別子を取得する（Ｓ１００１）。アプリ特定部１５１１は、ＯＳ１１０１が管理するプロセス管理用の構造体に格納されているアプリのファイル名を取得し、このファイル名をアプリ識別子とする。

　次に、システムコール管理部１５０１が備える攻撃チェック判定部１５１０は、システムコールを依頼してきたアプリが攻撃されているかチェックする必要があるか否かを判定するために、システムコールを依頼してきたアプリの、過去の攻撃チェック結果をチェックアプリ管理部１５００へ問い合わせる（Ｓ１００２）。この時、攻撃チェック判定部１５１０は、チェックアプリ管理部１５００へＳ１００１で取得したアプリ識別子を通知する。

　チェックアプリ管理部１５００は、攻撃チェック判定部１５１０から通知されたアプリ識別子に関連づけられたデータの組を攻撃チェック結果として攻撃チェック結果リスト１５３０から取得する（Ｓ１００３）。アプリ識別子に関連づけられたデータの組とは、例えば、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果とを含む。すなわち、アプリ識別子に関連づけられたデータの組とは、攻撃チェック結果リスト１５３０の各行のうち、通知されたアプリ識別子と同一のアプリ識別子を含む行に含まれる情報である。

　チェックアプリ管理部１５００は、Ｓ１００３で取得した攻撃チェック結果を攻撃チェック判定部１５１０へ通知する（Ｓ１００４）。

　システムコール管理部１５０１が有する攻撃チェック判定部１５１０は、受けとった攻撃チェック結果をもとに、チェック要否判定を行う（Ｓ１００５）。具体的には、受け取った攻撃チェック結果の「チェック結果」列に“要”が含まれている場合は攻撃チェックが必要（Ｓ１００５で「要」）であると判定し、含まれない場合は攻撃チェックが不要（Ｓ１００５で「否」）であると判定する。

　攻撃チェック判定部１５１０は、ステップＳ１００５で「要」と判定した場合には、攻撃チェック部１５１２を利用して、システムコールを要求したアプリが攻撃されているかどうかをチェックする（Ｓ１００６）。チェック方法としては、例えば、特許文献１又は特許文献２に詳しく説明されている。また、他の方法を利用してもよい。

　システムコール管理部１５０１は、チェックが終了すると、そのチェック結果の登録を、チェックアプリ管理部１５００へ依頼する（Ｓ１００７）。攻撃チェック判定部１５１０は、ステップＳ１００４で受け取った結果のうち、チェック結果が“要”となっていたデータの組（すなわち、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果との組）に対して、チェック結果をステップＳ１００６でチェックした結果に書き換えたデータの組をチェックアプリ管理部１５００へ通知する。

　チェックアプリ管理部１５００は、攻撃チェック判定部１５１０から受け取ったデータの組を攻撃チェック結果リスト１５３０へ反映する（Ｓ１００８）。具体的には、攻撃チェック結果リスト１５３０に含まれる行のうち、攻撃チェック判定部１５１０から受け取ったデータの組に対応する行のチェック結果を、受けとったチェック結果で更新する。

　次にシステムコール管理部１５０１は、攻撃チェックの結果を判定する（Ｓ１００９）。具体的には、ステップＳ１００６における攻撃チェックの結果、アプリが攻撃されていなければ、ステップＳ１００９において「ＯＫ」と判定し、アプリが攻撃されていれば「ＮＧ」と判定する。

　システムコール管理部１５０１は、ステップＳ１００９で「ＯＫ」と判定した場合には、アプリに要求されたシステムコールの処理を実行する（Ｓ１０１０）。また、システムコール管理部１５０１は、システムコール処理の終了後、システムコール処理の結果を表示アプリ１１０３へ返す。

　一方、システムコール管理部１５０１は、ステップＳ１００９で「ＮＧ」と判定した場合、表示アプリ１１０３へエラーを返す。

　本発明の実施の形態１においては、システムコール処理時に、上記に示したチェック要否判定処理を情報処理装置１００が実施することにより、アプリが攻撃されているか否かについて、不要な攻撃チェック処理を省くことが可能となる。したがって、本実施の形態に係る情報処理装置１００は、システムコール要求時のＯＳ１１０１による処理を高速化することが可能となる。

　＜ファイル読み込み処理＞
　次に、ファイル読み込みを伴うシステムコールが要求された場合における、ファイル読み込み管理部１５０２が行う処理について説明する。

　ファイル読み込み管理部１５０２は、ファイルの読み込み処理前に、（１）そのファイルを読み込んでもよいかの判定と、（２）ファイル読み込み処理後のシステムコール処理で攻撃チェック処理を実施する必要があるかの判定（すなわち、チェック要否判定処理）とを行う。チェック要否判定処理では、ファイル読み込み処理でチェックする必要があると判定された時にのみ、チェック処理を実施する。これにより、不正なファイルの読み込みを防止でき、攻撃者による攻撃の拡大を防止できる。また、チェックが必要な場合のみチェック処理を実行するように指示できるため、チェック処理が省略でき、システムコール要求時のＯＳ１１０１による処理を高速化できる。

　以下、表示アプリ１１０３がＯＳ１１０１へファイルの読み込みを依頼した時の、ファイル読み込み処理を、図１１のフローチャートを用いて説明する。

　表示アプリ１１０３は、システムコール管理部１５０１へファイルの読み込みを依頼する（Ｓ１１００）。

　システムコール管理部１５０１が備える攻撃チェック判定部１５１０は、図１０で示されるチェック要否判定処理により、表示アプリ１１０３が攻撃されているかチェックする必要があるか否かの判定を行う（Ｓ１１０１）。チェック要否判定処理において、システムコールの処理を行うと判定された場合（図１０のＳ１００９で「ＯＫ」）、システムコール管理部１５０１は、ファイルの読み込み処理をファイル読み込み管理部１５０２へ要求する（Ｓ１１０２）。

　ファイル読み込み管理部１５０２は、コンテンツ特定部１５２１を利用して、読み込みが要求されているコンテンツの識別子であるコンテンツ識別子を取得する（Ｓ１１０３）。コンテンツ特定部１５２１は、読み込み要求時に通知されるファイル識別子に格納されている写真データのファイル名を取得し、このファイル名をコンテンツ識別子とする。

　また、ファイル読み込み管理部１５０２は、アプリ特定部１５２２を利用して、読み込みを要求したアプリのアプリ識別子を取得する（Ｓ１１０４）。アプリ特定部１５２２は、ＯＳ１１０１が管理するプロセス管理用の構造体に格納されているアプリのファイル名を取得し、このファイル名をアプリ識別子とする。

　さらに、ファイル読み込み管理部１５０２は、呼び出し元特定部１５２３を利用して、ファイル読み込み要求を呼び出した呼び出し元を識別するためのデータを取得する（Ｓ１１０５）。本発明の実施の形態１においては、アプリが写真データの読み込み要求をした時のアプリの実行コードのアドレス（リターンアドレス）と、スタックポインタの値を取得し、呼び出し元を識別するためのデータとする。

　次に、ファイル読み込み管理部１５０２は、チェックアプリ管理部１５００へ、攻撃チェック結果リスト１５３０から攻撃チェック結果を取得するよう、依頼を行う（Ｓ１１０６）。この時、ファイル読み込み管理部１５０２は、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値とをチェックアプリ管理部１５００へ通知する。

　チェックアプリ管理部１５００は、ファイル読み込み管理部１５０２から受け取ったアプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値との全てに該当するチェック結果が攻撃チェック結果リスト１５３０に存在するか確認する。チェックアプリ管理部１５００は、存在する場合には、その結果を取得する（Ｓ１１０７）。その後、チェックアプリ管理部１５００は、取得したチェック結果をファイル読み込み管理部１５０２へ返す。なお、チェック結果が存在しない場合は、存在しない旨を示す情報を通知する（Ｓ１１０８）。

　次に、ファイル読み込み管理部１５０２は、チェックアプリ管理部１５００から受け取ったチェック結果を用いて、ファイルを読み込んでもよいか否かを判定する（Ｓ１１０９）。ファイル読み込み管理部１５０２は、受けとったチェック結果が“○”、又はチェック結果が存在しない旨を示す情報であった場合は、「可」と判定する。一方、受け取ったチェック結果が“×”であった場合は、「否」と判定する。

　ファイル読み込み管理部１５０２は、ステップＳ１１０９で「可」と判定した場合には、ファイル読み込み要求を行ったアプリが攻撃されているかどうかをチェックする必要があるか否かを判定する（Ｓ１１１０）。具体的には、ファイル読み込み管理部１５０２は、ステップＳ１１０８で受けとったチェック結果が、チェック結果が存在しない旨を示す情報であった場合は、ステップＳ１１１０で「要」と判定する。また、受けとったチェック結果が“○”であった場合は、ステップＳ１１１０で「否」と判定する。

　次に、ファイル読み込み管理部１５０２は、ステップＳ１１１０で「要」と判定した場合には、チェックアプリ管理部１５００へアプリの攻撃チェックが必要である旨の登録を依頼する（Ｓ１１１１）。この時、ファイル読み込み管理部１５０２は、アプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値とをチェックアプリ管理部１５００へ通知する。

　チェックアプリ管理部１５００は、ファイル読み込み管理部１５０２から受け取ったアプリ識別子と、コンテンツ識別子と、呼び出し元アドレスと、スタックポインタ値とを攻撃チェック結果リスト１５３０へ追加する。さらに、対応するチェック結果を“要”に設定する（Ｓ１１１２）。

　また、ファイル読み込み管理部１５０２は、ステップＳ１１１０で「否」と判定した場合、及びステップＳ１１１２の処理後に、ファイルの読み込み処理を行う（Ｓ１１１３）。

　なお、攻撃チェック結果リスト１５３０、コンテンツＡ１２２２、及び、コンテンツＢ１２２３（いずれも、図３を参照）は不揮発性記憶装置１２２０に格納されるとしたが、これに限定されるものではない。例えば、システムＬＳＩ内部の保護されたメモリ（図示しない）や、耐タンパー化された不揮発性記憶装置（図示しない）に格納されてもよい。また、コンテンツＡ１２２２とコンテンツＢ１２２３は、コンテンツ収集アプリ１１０２により収集された直後は不揮発性記憶装置１２２０（図３を参照）へ格納され、攻撃チェック部１５１２によりチェックされた後、保護されたメモリや耐タンパー化された不揮発性記憶装置へ格納されるとしてもよい。

　また、管理アプリ１１０５（図２を参照）により、アプリを更新／削除した場合、チェックアプリ管理部１５００は、更新／削除されたアプリのアプリ識別子に対応するチェック結果を攻撃チェック結果リスト１５３０から削除してもよい。これにより、アプリを最新のものに更新することによりバッファーオーバーフローの脆弱性が修正された場合には、読み込み処理を行えるようになる。また、アプリを削除した時、同じアプリ識別子を持つアプリが再度インストールされた場合に、再度攻撃チェック処理を実施できる。

　さらに、編集アプリ１１０４により、写真データを更新／削除した場合、チェックアプリ管理部１５００は、更新／削除した写真データのコンテンツ識別子に関するチェック結果を攻撃チェック結果リスト１５３０から削除してもよい。これにより、写真データが不正なプログラムを付加したコンテンツに更新されてしまった場合に、それを検知可能となる。逆に、不正なプログラムを付加したコンテンツから通常の写真データへ更新された場合に、写真を表示できるようになる。

　以上述べたように、再度図９を参照して、本実施の形態に係る情報処理装置１００Ａは、一意な識別子であるアプリ識別子を有する１以上のプログラムを実行する。

　また、情報処理装置１００Ａは、アプリ識別子を取得することによりアプリ（すなわち、情報処理装置１００Ａにおいて実行中のプログラム）を特定するアプリ特定部１５１１と、特定されたアプリが、システムコール等の関数（すなわち、プログラムコード）を呼び出す時に、アプリの中のどの部分（すなわち、プログラム中のどの部分）から関数を呼び出したかを示す呼び出し元を特定する呼び出し元特定部１５２３と、特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理部１５００と、特定された呼び出し元とチェック結果とに基づいて、特定されたアプリ（プログラム）が攻撃されているかチェックを行うか否かを判定する攻撃チェック判定部１５１０とを備える。

　また、コンテンツ蓄積・表示装置１００１は、さらに、特定されたアプリが攻撃されているかをチェックする攻撃チェック部１５１２を備えており、攻撃チェック部は、攻撃チェック判定部１５１０が、特定されたアプリに対して攻撃チェックを行うと判定した場合には、特定されたアプリが攻撃されているか否かをチェックする。

　また、呼び出し元特定部１５２３は、特定されたアプリから関数を呼び出した後に特定されたアプリへ実行処理を戻すための戻し先を示すメモリ内のアドレスであるリターンアドレスを用いて呼び出し元を特定する。

　また、呼び出し元特定部１５２３は、特定されたアプリから関数を呼び出した場合に特定されたアプリが使用するコールスタックのスタックポインタの値と、リターンアドレスとを用いて呼び出し元を特定してもよい。

　また、チェックアプリ管理部１５００は、（Ａ）特定されたプログラムが攻撃されているか否かをチェックした結果を示す情報、及び、（Ｂ）特定されたプログラムが、攻撃されているか否かを判定するチェックが必要であるかを示す情報、の両方を含む情報をチェック結果として、特定されたプログラムが有するアプリ識別子と呼び出し元とに対応付けて記憶してもよい。

　この場合、攻撃チェック判定部１５１０は、アプリ識別子と、呼び出し元とに対応付けられた情報であって、アプリ識別子で特定されるアプリが攻撃されているかチェックを行う必要があることを示す情報が、チェックアプリ管理部１５００に記憶されている場合には、チェックを行うと判定し、記憶されていない場合には、チェックを行わないと判定する。

　すなわち、攻撃チェック判定部１５１０は、特定されたプログラムが有するアプリ識別子に対応付けられてチェックアプリ管理部１５００に記憶されているチェック結果を取得し、（Ａ）取得したチェック結果が、特定されたプログラムが攻撃されていないこと、又は、特定されたプログラムが攻撃されていることを表す場合には、攻撃されているかのチェックを行わないと判定し、（Ｂ）取得したチェック結果が、攻撃されているか否かを判定するチェックが必要であることを表す場合には、攻撃チェック部による攻撃されているかのチェックを行うと判定してもよい。

　また、さらに、特定されたアプリが関数を呼び出すことにより読み込もうとしているデータファイルを、データファイルを示す識別子であるコンテンツ識別子を用いて特定するコンテンツ特定部１５２１と、特定されたデータファイルを読み込むか否かを判定する読み込み可否判定部１５２０とを備えてもよい。

　ここで、読み込み可否判定部１５２０は、（Ａ）コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部１５００に記憶されていないか、又は（Ｂ）コンテンツ識別子と、アプリ識別子と、前記呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部１５００記憶されており、かつ、そのチェック結果が特定されたアプリが攻撃されていないことを示す場合には、特定されたデータファイルを読み込むと判定し、（Ｃ）コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられているチェック結果が、チェックアプリ管理部１５００に記憶されており、かつ、そのチェック結果が、特定されたアプリが以前に攻撃されたことを示す場合には、特定されたデータファイルを読み込まないと判定してもよい。

　より詳細には、読み込み可否判定部１５２０は、コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けられたチェック結果が、チェックアプリ管理部１５００に記憶されていない場合には、アプリ識別子で特定されるアプリが、攻撃されているか否かを判定するチェックが必要であることを示す情報を、コンテンツ識別子と、アプリ識別子と、呼び出し元とに対応付けてチェックアプリ管理部１５００に記憶させてもよい。

　また、チェックアプリ管理部１５００は、アプリが削除又は更新された場合には、攻撃チェック結果リスト１５３５として記憶しているチェック結果のうち、削除又は更新されたアプリが有するアプリ識別子に対応づけられて記憶されているチェック結果の記録を削除してもよい。

　また、チェックアプリ管理部１５００は、特定されたデータファイルが変更された場合には、変更されたデータファイルを示すコンテンツ識別子に対応づけられて記憶されているチェック結果を削除してもよい。

　以上説明したように、本発明の実施の形態１によれば、１度、安全性（攻撃されていないこと）が確認されたアプリからのシステムコールを処理する際は、攻撃チェック処理を省くことができる。さらに、システムコール内でファイルの読み込みが発生する際には、以前に攻撃されたファイルの読み込みを中止することができる。その結果、安全性を維持したまま、システムコール処理の応答性を向上させることが可能となる。

　（実施の形態２）
　本発明の実施の形態１では、ファイル読み込み管理部１５０２でアプリのチェックを実施するかを判定し、その判定結果に基づいてシステムコール管理部１５０１が攻撃チェック処理を行った。実施の形態２では、システムコール管理部１５０１がアプリのチェック実施の判定と、攻撃チェック処理を行う構成について説明する。

　以下、本発明の実施の形態２に係るシステムコール管理部１５０１の構成と、攻撃チェック結果リスト１５３５と、チェック要否判定処理とを説明する。なお、本発明の実施の形態１と同じ構成要素、同じ処理については、同じ符号を用い、説明を省略する。

　＜情報処理装置１００Ｂの構成＞
　図１２は、本発明の実施の形態２に係る情報処理装置１００Ｂの構成図である。

　図１２において、システムコール管理部１５０１Ａは、攻撃チェック判定部１５１０と、アプリ特定部１５１１と、攻撃チェック部１５１２と、呼び出し元特定部１５２３とを含む。

　攻撃チェック判定部１５１０は、システムコールを要求したアプリに対して、攻撃されているかどうかをチェックする必要があるかを判定する。攻撃チェック判定部１５１０は、アプリ特定部１５１１からアプリ識別子を取得し、呼び出し元特定部１５２３から呼び出し元アドレスとスタックポインタ値とを取得する。攻撃チェック判定部１５１０は、チェックアプリ管理部１５００を介して、後述する攻撃チェック結果リストに、指定したアプリ識別子、呼び出し元アドレス及びスタックポインタの値と一致するデータがあるか確認する。攻撃チェック判定部１５１０は、一致するデータがない場合には、攻撃チェック部１５１２を利用して攻撃チェックを行う。一方、一致するデータがあった場合には、攻撃チェックを行わない。

　図１３は、攻撃チェック結果リスト１５３５の一例を示している。この攻撃チェック結果リスト１５３５は、アプリ識別子と、呼び出し元アドレスと、スタックポインタ値と、チェック結果とを含む。チェック結果は、本発明の実施の形態１の攻撃チェック結果リスト１５３０及び攻撃チェック結果リスト１５３５とは異なり、攻撃されたかどうかのチェック結果を示す“○”又は“×”のみを格納している。

　なお、アプリ特定部１５１１と、攻撃チェック部１５１２と、呼び出し元特定部１５２３とに関しては、本発明の実施の形態１と同じである。

　＜チェック要否判定処理＞
　本発明の実施の形態２に係るチェック要否判定処理は、本発明の実施の形態１に係るチェック要否判定処理（図１０、図１１）と一部は同じ処理となる。処理の異なる部分を中心に説明する。

　図１４を参照して、本発明の実施の形態２に係るシステムコール管理部１５０１Ａは、ステップＳ１２０４における攻撃チェック結果の取得処理において、アプリ識別子と、呼び出し元アドレスと、スタックポインタ値とを指定して、チェックアプリ管理部１５００から攻撃チェック結果を取得する。この時、チェックアプリ管理部１５００は、指定されたアプリ識別子と、呼び出し元アドレスと、スタックポインタ値とを含む行が、攻撃チェック結果リスト１５３５に含まれている場合には、該当する行のチェック結果（“○”又は“×”）を返す。また、チェックアプリ管理部１５００は、指定されたアプリ識別子等の組み合わせに一致する行が攻撃チェック結果リスト１５３５に存在しなかった場合には、チェック結果として、“○”又は“×”に代わり、チェック結果が存在しないことを示す情報を返す。

　その後、チェックアプリ管理部１５００は、ステップＳ１２０６におけるチェック要否判定において、受け取ったチェック結果が、チェック結果が存在しないことを示す情報であった場合には「要」と判定する。また、“○”であった場合には「否」と判定する。また、“×”であった場合には、「ＮＧ」と判定する。

　次に、システムコール管理部１５０１Ａは、ステップＳ１２０６で「要」と判定された場合には、攻撃チェック処理（Ｓ１００６）と、その結果の登録処理（Ｓ１１０８）を行う。さらに、チェック結果の判定処理（Ｓ１００９）を行う。

　また、システムコール管理部１５０１Ａは、ステップＳ１２０６で「否」と判定された場合には、続けて、チェック結果の判定処理（Ｓ１００９）を行う。

　また、システムコール管理部１５０１Ａは、ステップＳ１２０６で「ＮＧ」と判定された場合には、呼び出した表示アプリ１１０３に対してエラーを返す。

　以上説明したように、本発明の実施の形態２によれば、アプリからのシステムコール要求時に、チェック要否判定処理を行うことにより、システムコール処理の応答性を向上させることが可能となる。

　（実施の形態３）
　本発明の実施の形態３に係る情報処理装置は、本発明の実施の形態２に係る情報処理装置１００Ｂのように攻撃チェック結果リスト１５３０を自機器内で生成及び管理せず、他の機器から攻撃チェック結果リスト１５３０を取得する。

　以下、本発明の実施の形態３に係る情報処理装置１００Ｃについて詳細に説明する。なお、本発明の実施の形態２に係る情報処理装置１００Ｂと同じ構成要素、同じ処理については、同じ符号を用い、説明を省略する。

　＜コンテンツ蓄積・表示システム１０００Ａの構成＞
　図１５は、本発明の実施の形態３におけるコンテンツ蓄積・表示システム１０００Ａの構成図である。

　図１５において、コンテンツ蓄積・表示システム１０００Ａは、コンテンツ蓄積・表示装置１００１Ａ、１００２Ａと、カメラ１０１０と、ＰＣ１０１１と、更新サーバ１０２０とを含む。

　コンテンツ蓄積・表示装置１００１Ａは、コンテンツ蓄積・表示装置１００２Ａとネットワークを介して接続される。

　コンテンツ蓄積・表示装置１００１Ａとコンテンツ蓄積・表示装置１００２Ａとで写真データを共有するために、コンテンツ蓄積・表示装置１００１Ａは、自機器内に蓄積する写真データをコンテンツ蓄積・表示装置１００２Ａへ送信する。この時、コンテンツ蓄積・表示装置１００１Ａは、写真データと一緒に、攻撃チェック結果リスト１５３５を送信する。

　コンテンツ蓄積・表示装置１００２Ａは、コンテンツ蓄積・表示装置１００１Ａとネットワークを介して接続される。コンテンツ蓄積・表示装置１００２Ａは、コンテンツ蓄積・表示装置１００１Ａから受信した写真データを表示する時には、コンテンツ蓄積・表示装置１００１Ａから受信した攻撃チェック結果リスト１５３５を参照し、チェック結果が“○”の写真データのみを表示する。

　コンテンツ蓄積・表示装置１００１Ａとコンテンツ蓄積・表示装置１００２Ａとは、上記以外の機能は本発明の実施の形態１に係るコンテンツ蓄積・表示装置１００１と同じである。

　なお、コンテンツ蓄積・表示装置１００１Ａ、１００２Ａと、カメラ１０１０と、ＰＣ１０１１と、更新サーバ１０２０とに関しては、本発明の実施の形態１及び２と同じである。

　＜情報処理装置１００Ｃの構成＞
　図１６は、本発明の実施の形態３に係るコンテンツ蓄積・表示装置１００１Ａ、及びコンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃの構成図である。

　図１６において、コンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃは、攻撃チェック判定部１５１０と、アプリ特定部１５１１と、呼び出し元特定部１５２３とを有する。また、コンテンツ蓄積・表示装置１００１Ａが備える情報処理装置１００Ｄは、チェックアプリ管理部１５００Ａと、攻撃チェック結果リスト１５３５とを有する。

　なお、コンテンツ蓄積・表示装置１００１Ａ、及びコンテンツ蓄積・表示装置１００２Ａの各構成要素のうち、実施の形態２と同様の構成要素については詳細な説明は省略する。

　攻撃チェック判定部１５１０は、システムコールを要求したアプリに対して、攻撃されているかどうかをチェックする必要があるかを判定する。攻撃チェック判定部１５１０は、アプリ特定部１５１１からアプリ識別子を取得し、呼び出し元特定部１５２３から呼び出し元アドレスとスタックポインタ値とを取得する。攻撃チェック判定部１５１０は、チェックアプリ管理部１５００を介して、チェックアプリ管理部１５００Ａが有している攻撃チェック結果リスト１５３５を取得する。その後、取得した攻撃チェック結果リスト１５３５の中に、アプリ識別子と、呼び出し元アドレスと、スタックポインタ値との全てが一致するデータ（行）があるか確認する。

　一致するデータがあった場合、一致するデータのチェック結果が“○”の場合は、システムコール処理を実施し、“×”の場合は、システムコール処理を実施しない。

　すなわち、本発明の実施の形態３に係る情報処理装置１００Ｃが有するチェックアプリ管理部１５００は、チェック結果を、当該チェックアプリ管理部１５００を有する情報処理装置Ｃとは異なる情報処理装置１００Ｄに記憶していてもよい。また、チェックアプリ管理部１５００が、チェック結果を、当該チェックアプリ管理部１５００を備える情報処理装置１００Ｃ、及び、当該チェックアプリ管理部を備える情報処理装置１００Ｃとは異なる情報処理装置１００Ｄの少なくとも一方に記憶していてもよい。

　なお、アプリ特定部１５１１と、呼び出し元特定部１５２３とが行う処理内容は、本発明の実施の形態２と同じである。

　＜チェック要否判定処理＞
　本発明の実施の形態３に係るコンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃが行うチェック要否判定処理は、本発明の実施の形態２に係るチェック要否判定処理（図１４）と大部分は同じ処理となる。よって、図１７を参照して、処理の異なる部分を中心に説明する。なお、本実施の形態に係るコンテンツ蓄積・表示装置１００１Ａが備える情報処理装置１００Ｄの処理は、実施の形態２と同様であるため、説明を省略する。

　図１７を参照して、本実施の形態に係るコンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃは、攻撃チェック結果の取得処理において、アプリ識別子と、呼び出し元アドレスと、スタックポインタ値とを指定する。また、情報処理装置１００Ｃを介して、ネットワークで接続されている情報処理装置１００Ｄが有するチェックアプリ管理部１５００Ａから、指定したアプリ識別子等に一致するチェック結果を取得する（Ｓ１２０４）。

　この時、コンテンツ蓄積・表示装置１００１Ａが備えるチェックアプリ管理部１５００Ａは、攻撃チェック結果リスト１５３５を参照する。その結果、チェック結果として、例えば“○”又は“×”を返す。また、チェックアプリ管理部１５００Ａは、指定されたアプリ識別子等の組み合わせに一致する行が攻撃チェック結果リスト１５３５に存在しなかった場合には、チェック結果として、“○”又は“×”に代わり、例えば、「チェック結果が存在しない」という結果を返す。

　攻撃チェック判定部１５１０は、その後のチェック結果判定処理において、受け取ったチェック結果が“○”であった場合には、ステップＳ１００９で「ＯＫ」と判定する。また、チェック結果が“×”又は「チェック結果が存在しない」であった場合には、ステップＳ１００９で「ＮＧ」と判定する（Ｓ１００９）。

　情報処理装置１００Ｃは、ステップＳ１００９で「ＯＫ」と判定された場合には、システムコール処理（Ｓ１０１０）を行う。一方、ステップＳ１００９で「ＮＧ」と判定された場合には、システムコールを呼び出したアプリに対してエラーを返す。

　なお、本実施の形態に係るコンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃは攻撃チェック処理を行わなくてもよいが、これに限定されるものではない。例えば、コンテンツ蓄積・表示装置１００２Ａが独自に収集した写真データを読み込んだ場合には、本発明の実施の形態１や実施の形態２と同様に、コンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃが攻撃チェック処理を実施し、一方、コンテンツ蓄積・表示装置１００１Ａから受信した写真データに関しては、攻撃チェック処理を実施しないというように、組み合わせてもよい。

　なお、本発明の実施の形態３では、コンテンツ蓄積・表示装置１００１Ａとコンテンツ蓄積・表示装置１００２Ａとの２台で写真データを共有する場合を説明したが、これに限定されるものではない。例えば、２台以上の任意の台数のコンテンツ蓄積・表示装置の間で、コンテンツ及び攻撃チェック結果リストを共有してもよい。より具体的には、コンテンツ蓄積・表示装置１００２Ａは、さらに、コンテンツ蓄積・表示装置１００１Ａ以外の第３のコンテンツ蓄積・表示装置とも写真データを共有してもよい。このとき、コンテンツ蓄積・表示装置１００２Ａは、コンテンツ蓄積・表示装置１００１Ａから取得した攻撃チェック結果リスト１５３５と、第３のコンテンツ蓄積・表示装置から取得した攻撃チェック結果リストとを結合し、１つの攻撃チェック結果リストとして利用・管理してもよい。

　なお、コンテンツ蓄積・表示装置１００２Ａが備える情報処理装置１００Ｃは、必ずしも、ステップＳ１２０４において、システムコールの発行ごとに攻撃チェック結果リスト１５３５を取得しなくてもよい。例えば、コンテンツ蓄積・表示装置１００２Ａがコンテンツ蓄積・表示装置１００１Ａから写真等のコンテンツを受信するタイミングで、同時に、攻撃チェック結果リスト１５３５を取得しておいてもよい。

　また、実施の形態１～３において、情報処理装置を有する装置の具体例として、コンテンツ蓄積・表示装置を用いて説明したが、本発明に係る情報処理装置が適用される対象は、コンテンツ蓄積・表示装置に限定されない。例えば、表示対象となるコンテンツを蓄積せず、外部のストレージから一時的に取得して表示を行う、コンテンツ表示装置に適用されてもよい。

　以上説明したように、本発明の実施の形態３によれば、コンテンツ蓄積・表示装置１００２Ａは、（Ａ）他の機器（例えば、コンテンツ蓄積・表示装置１００１Ａ）から写真データを受信する時に、攻撃チェック結果リスト１５３５を一緒に受信することにより、又は、（Ｂ）システムコールの発行ごとに、攻撃チェック結果リスト１５３５を他の機器（例えば、コンテンツ蓄積・表示装置１００１Ａ）から受信することにより、コンテンツ蓄積・表示装置１００２Ａ自身が攻撃チェック処理を行わなくてもよくなる。その結果、システムコール処理の応答性を大幅に向上させることが可能となる。

　なお、本発明は、上記の実施の形態１～３に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

　（１）上記実施の形態におけるコンテンツ識別子は、写真データファイルのファイル名としたが、これに限定されるものではない。例えば、ファイル名とファイルサイズの組み合わせとしてもよいし、写真データのハッシュ値としてもよいし、写真データに埋め込まれた識別子としてもよい。

　また、写真データは、ファイルではなくデータベースのように複数の写真が１つのファイルに含まれてもよい。

　（２）上記実施の形態１～３における「アプリが攻撃されている」とは、アプリに存在するバッファーオーバーフローの脆弱性を衝かれて、アプリのスタック上で不正なプログラムが動作している状態であるとしたが、これに限定されるものではない。例えば、アプリのコード領域が改ざんされるとしてもよい。この場合、攻撃チェック処理としては、メモリ１２１０上のアプリのコード領域の改ざん検出処理を行う。

　（３）上記実施の形態１～３における攻撃チェック処理は、リターンアドレスがスタック領域のアドレスではないかをチェックする処理としたが、これに限定されるものではない。例えば、「カナリア」と呼ばれる特殊な値をスタックのローカル変数領域とリターンアドレスの間に配置し、関数終了時に、「カナリア」の値をチェックしてもよい。

　また、上記実施の形態３において、コンテンツ蓄積・表示装置１００２Ａが独自に収集した写真データを読み込んだ場合には、情報処理装置１００Ｃは、本発明の実施の形態１や実施の形態２と同様に、攻撃チェック処理を実施してもよいと説明した。また、その場合においても、コンテンツ蓄積・表示装置１００１Ａから受信した写真データに関しては、情報処理装置１００Ｃは、攻撃チェック処理を実施しないというように、組み合わせてもよいと説明した。この時、情報処理装置１００Ｃは、コンテンツ蓄積・表示装置１００２Ａが独自に収集した写真データを読み込む場合は「カナリア」値をチェックするアプリを用い、コンテンツ蓄積・表示装置１００１Ａから受信した写真データを読み込む場合は、「カナリア」値をチェックしないアプリを用いるとしてもよい。

　（４）上記実施の形態１～３において、攻撃チェック処理は、システムコール要求時に、システムコール処理の前に実行するとしたが、これに限定されるものではない。例えば、システムコール処理と並行して処理してもよい。また、情報処理装置では、攻撃チェック処理の依頼のみを行い、実際の処理は、アプリが動作するバックグラウンドで行ってもよい。

　（５）上記実施の形態１～３におけるチェック要否判定処理や、ファイル読み込み処理は、ユーザが写真データを選択した時等を契機に処理を開始するとしたが、これに限定されるものではない。例えば、スリープモードなどユーザが装置を使用していない時や、写真データを取り込んだ直後等に、写真データの読み込み処理をバックグラウンドで行うことにより、ユーザが写真を表示する前に攻撃チェック結果リスト１５３０、１５３５を作成してもよい。

　（６）上記の各装置は、具体的には、マイクロプロセッサ、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭ又はハードディスクユニットには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わせされて構成されたものである。

　（７）上記の各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記憶されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。

　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていてもよいし、一部又は全てを含むように１チップ化されてもよい。

　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

　さらに、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

　（８）上記の各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしてもよい。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパー性を有するとしてもよい。

　（９）本発明は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。

　また、本発明は、前記コンピュータプログラム又は前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕ－ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。

　また、本発明は、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。

　また、本発明は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記憶しており、前記マイクロプロセッサは、前記コンピュータプログラムにしたがって動作するとしてもよい。

　また、前記プログラム又は前記デジタル信号を前記記録媒体に記録して移送することにより、又は前記プログラム又は前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

　（１０）上記実施の形態及び上記変形例をそれぞれ組み合わせるとしてもよい。

　本発明は、情報の漏洩を防止できる情報処理装置等に適用できる。

　１００、１００Ａ、１００Ｂ、１００Ｃ、１００Ｄ　情報処理装置
　１０１　タスク
　１０２　データ領域
　１０３　システムコールテーブル
　１０４　正当性検証部
　１０５　システムコール
　１０６　命令実行部
　１０７、１１０１　ＯＳ
　１１２　攻撃対策部
　１０００、１０００Ａ　コンテンツ蓄積・表示システム
　１００１、１００１Ａ、１００２Ａ　コンテンツ蓄積・表示装置
　１０１０　カメラ
　１０１１　ＰＣ
　１０２０　更新サーバ
　１０３０　記録ディスク
　１１０２　コンテンツ収集アプリ
　１１０３　表示アプリ
　１１０４　編集アプリ
　１１０５　管理アプリ
　１２００　システムＬＳＩ
　１２０１　ＣＰＵ
　１２０２　カードＩ／Ｆ
　１２０３　ネットワークＩ／Ｆ
　１２０４　入出力Ｉ／Ｆ
　１２１０　メモリ
　１２２０　不揮発性記憶装置
　１２２１　呼び出し元チェック結果表
　１２２２　コンテンツＡ
　１２２３　コンテンツＢ
　１３００　更新処理受付部
　１３０１　更新用ソフトウェア保持部
　１５００、１５００Ａ　チェックアプリ管理部
　１５０１、１５０１Ａ　システムコール管理部
　１５０２　ファイル読み込み管理部
　１５１０　攻撃チェック判定部
　１５１１、１５２２　アプリ特定部
　１５１２　攻撃チェック部
　１５２０　読み込み可否判定部
　１５２１　コンテンツ特定部
　１５２３　呼び出し元特定部
　１５３０、１５３５　攻撃チェック結果リスト
　１５３１　要チェックアプリリスト
　１５６０　ｍａｉｎ関数
　１５６１　サムネイル取得関数
　１５６２　データ本体取得関数
　１５６３　ｒｅａｄ関数
 

Claims (15)

1. 　一意な識別子であるアプリ識別子を有する１以上のプログラムを実行する情報処理装置であって、
   　前記アプリ識別子を取得することにより前記情報処理装置において実行中のプログラムを特定するアプリ特定部と、
   　前記特定されたプログラムが、プログラムコードの呼び出し時に、前記プログラムのどの部分から前記プログラムコードを呼び出したかを示す呼び出し元を特定する呼び出し元特定部と、
   　前記特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理部と、
   　前記特定された呼び出し元と前記チェック結果とに基づいて、前記特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する攻撃チェック判定部とを備える
   　情報処理装置。
2. 　前記情報処理装置は、さらに、
   　前記特定されたプログラムが攻撃されているかをチェックする攻撃チェック部を備えており、
   　前記攻撃チェック部は、前記攻撃チェック判定部が、前記特定されたプログラムに対して攻撃チェックを行うと判定した場合には、前記特定されたプログラムが攻撃されているか否かをチェックする
   　請求項１に記載の情報処理装置。
3. 　前記呼び出し元特定部は、前記特定されたプログラムから前記プログラムコードを呼び出した後に前記特定されたプログラムへ実行処理を戻すための戻し先を示すメモリ内のアドレスであるリターンアドレスを用いて、前記呼び出し元を特定する
   　請求項２に記載の情報処理装置。
4. 　前記呼び出し元特定部は、前記特定されたプログラムから前記プログラムコードを呼び出した場合に前記特定されたプログラムが使用するコールスタックのスタックポインタの値と、前記リターンアドレスとを用いて前記呼び出し元を特定する
   　請求項３に記載の情報処理装置。
5. 　前記チェックアプリ管理部は、（Ａ）前記特定されたプログラムが攻撃されているか否かをチェックした結果を示す情報、及び、（Ｂ）前記特定されたプログラムが、攻撃されているか否かを判定するチェックが必要であるかを示す情報、の両方を含む情報を前記チェック結果として、前記特定されたプログラムが有する前記アプリ識別子と前記呼び出し元とに対応付けて記憶している
   　請求項３又は４に記載の情報処理装置。
6. 　前記攻撃チェック判定部は、前記特定されたプログラムが有するアプリ識別子に対応付けられて前記チェックアプリ管理部に記憶されている前記チェック結果を取得し、
   　（Ａ）取得した前記チェック結果が、前記特定されたプログラムが攻撃されていないこと、又は、前記特定されたプログラムが攻撃されていることを表す場合には、攻撃されているかのチェックを行わないと判定し、
   　（Ｂ）取得した前記チェック結果が、攻撃されているか否かを判定するチェックが必要であることを表す場合には、攻撃チェック部による攻撃がされているかのチェックを行うと判定する
   　請求項５に記載の情報処理装置。
7. 　さらに、前記特定されたプログラムが前記プログラムコードを呼び出すことにより読み込もうとしているデータファイルを、前記データファイルを示す識別子であるコンテンツ識別子を用いて特定するコンテンツ特定部と、
   　前記特定されたデータファイルを読み込むか否かを判定する読み込み可否判定部とを備え、
   　前記読み込み可否判定部は、
   　（Ａ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されていないか、又は、（Ｂ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されており、かつ、前記チェック結果が、前記特定されたプログラムが攻撃されていないことを示す場合には、前記特定されたデータファイルを読み込むと判定し、
   　（Ｃ）前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられている前記チェック結果が、前記チェックアプリ管理部に記憶されており、かつ、前記チェック結果が、前記特定されたプログラムが以前に攻撃されたことを示す場合には、前記特定されたデータファイルを読み込まないと判定する
   　請求項５に記載の情報処理装置。
8. 　前記読み込み可否判定部は、
   　前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けられた前記チェック結果が、前記チェックアプリ管理部に記憶されていない場合には、前記アプリ識別子で特定されるプログラムが、攻撃されているか否かを判定するチェックが必要であることを示す情報を、前記コンテンツ識別子と、前記アプリ識別子と、前記呼び出し元とに対応付けて前記チェックアプリ管理部に記憶させる
   　請求項７に記載の情報処理装置。
9. 　前記チェックアプリ管理部は、前記プログラムが削除又は更新された場合には、削除又は更新された前記プログラムが有するアプリ識別子に対応づけられて記憶されているチェック結果を削除する
   　請求項５に記載の情報処理装置。
10. 　前記チェックアプリ管理部は、前記チェック結果を、当該チェックアプリ管理部を備える前記情報処理装置、及び、当該チェックアプリ管理部を備える前記情報処理装置とは異なる情報処理装置の少なくとも一方に記憶している
    　請求項１に記載の情報処理装置。
11. 　前記チェックアプリ管理部は、前記特定されたデータファイルが変更された場合には、当該変更されたデータファイルを示すコンテンツ識別子に対応づけられて記憶されているチェック結果を削除する
    　請求項７に記載の情報処理装置。
12. 　一意な識別子であるアプリ識別子を有する１以上のプログラムを実行する情報処理方法であって、
    　前記アプリ識別子を取得することにより前記情報処理方法によって実行中のプログラムを特定するアプリ特定ステップと、
    　前記特定されたプログラムが、プログラムコードの呼び出し時に、前記プログラムのどの部分から前記プログラムコードを呼び出したかを示す呼び出し元を特定する呼び出し元特定ステップと、
    　前記特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理ステップと、
    　前記特定された呼び出し元と前記チェック結果とに基づいて、前記特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する攻撃チェック判定ステップとを含む
    　情報処理方法。
13. 　請求項１２に記載の情報処理方法をコンピュータに実行させる
    　プログラム。
14. 　請求項１３に記載のプログラムを記録した
    　コンピュータ読み取り可能な記録媒体。
15. 　一意な識別子であるアプリ識別子を有する１以上のプログラムを実行する集積回路であって、
    　前記アプリ識別子を取得することにより前記集積回路において実行中のプログラムを特定するアプリ特定部と、
    　前記特定されたプログラムが、プログラムコードの呼び出し時に、前記プログラムのどの部分から前記プログラムコードを呼び出したかを示す呼び出し元を特定する呼び出し元特定部と、
    　前記特定されたプログラムを実行することに対する安全性について過去にチェックした結果を含む情報であるチェック結果を管理するチェックアプリ管理部と、
    　前記特定された呼び出し元と前記チェック結果とに基づいて、前記特定されたプログラムが攻撃されているかのチェックを行うか否かを判定する攻撃チェック判定部とを備える
    　集積回路。

Images