JP2010097594A - Ａｐｉ検査装置及び状態監視装置 - Google Patents

Abstract

【課題】オープン実行環境とクローズド実行環境とを備えるデバイスにおいて、オープン実行環境とクローズド実行環境とでのAPI呼出しによる連携に関して、低いオーバヘッドで安全性及び信頼性を確保できるAPI検査装置及び状態監視装置を提供する。
【解決手段】API検査装置３００は、API呼出しを許可するか否かの判定を要求する判定要求を受け付けるAPI検査要求受付部３０１と、デバイス１００の状態情報を取得する状態情報取得部３０３と、取得した状態情報に基づいて、API呼出しに対する検査モードを設定する検査モード設定部３０５と、設定された検査モードに基づいて、API呼出しを許可するか否かを判定し、API呼出しの検査結果を生成する判定部３０７と、判定部によって生成された検査結果を出力する検査結果出力部３０９とを備える。
【選択図】図１

Description

本発明は、携帯電話やPDA、PCなどのデバイスにおいて、ソフトウェアやハードウェアによって実現されるAPI検査装置及び状態監視装置に関し、特に、クローズド実行環境に配置されるAPI検査装置と、オープン実行環境に配置される状態監視装置とに関する。

従来、携帯電話やPDA、PCなどのデバイスでは、例えば、１つのCPU上において複数のオペレーティングシステム（OS）を並行して動作可能なソフトウェア或いはハードウェア、いわゆる仮想マシンモニタ（VMM）を設ける方法が知られている。

このようなデバイスでは、信頼されたプログラム以外のプログラムも自由に或いは一定の制限の下に実行することができる実行環境（以下、オープン実行環境という）と、オープン実行環境からのアプリケーション・プログラム・インタフェース（API）呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行されるクローズドな実行環境（以下、クローズド実行環境という）を、それぞれOS上で安全に隔離して実行できる。ここで、API呼出しとは、クローズド実行環境における機能の呼出しや、クローズド実行環境とのデータの受け渡しを行うための呼出しなどを指す。

このように、クローズド実行環境が提供するAPIの呼出しをオープン実行環境から可能とすることによって、オープン実行環境における自由なプログラムの追加を許容しつつ、守りたい機密の機能やデータをクローズド実行環境に隔離した状態で利用可能とできる（例えば、特許文献１）。

米国特許第７３２５０８３号明細書

上述した特許文献１に開示されている技術では、オープン実行環境内に配置されるOSなどが提供するアクセス制御機能によって、オープン実行環境におけるAPI呼出し元が正当なプログラムか認証し、不正なAPIの呼出しを防ぐ。しかしながら、オープン実行環境にはウィルスなどの悪意あるプログラムが入り込む可能性があるとともに、悪意のあるユーザ自身による解析及び攻撃によって、アクセス制御機能がバイパス或いは無効化された場合、不正なAPI呼出しが可能となる問題がある。

一方で、API呼出しの引数として用いられる値の範囲や不正な文字が含まれていないかの検査、受け渡しデータのフォーマット検査、及びウィルス検査などをクローズド実行環境で実行すれば、ウィルスや悪意のあるユーザからの攻撃の影響を受けず、安全に検査可能である。しかしながら、このような処理は、負荷が重く、携帯電話などでは、バッテリの消耗や応答性の低下などが問題となる。

そこで、ＯＳによるアクセス制御だけに依存せず、かつ引数やデータの検査に比べて処理負荷が低い検査手段として、オープン実行環境とクローズド実行環境の状態に応じた検査モードを設定することが考えられる。例えば、クローズド実行環境内のAPI検査装置が、オープン実行環境において当該API呼出し（連携）に必要なプログラム及び不正なプログラムが実行中か否かの状態情報を取得し、必要なプログラムが実行中で、かつ不正プログラムが実行中でない場合、API呼出しを許可し、そうでない場合はユーザに警告して確認を促すためのユーザ警告モードを設定することが考えられる。ここで、連携に必要なプログラムが実行中でないと、連携動作が失敗し、障害が起きる可能性があるため、あらかじめユーザへ警告するなどの対処が必要である。

しかしながら、この方法には、次のような問題がある。第１の問題は、オープン実行環境に導入され得る多様かつ新たに現れ続ける不正プログラムの出現に追随することは運用コストが高いため、より運用コストの低い方法が求められることである。

第２の問題は、あるAPI呼出しに対してユーザに警告して確認を促す際、ユーザが応答するまではユーザ確認待ちの状態となり、別の新たな連携要求は拒否され得るが、この状態でのオープン実行環境からの新たな連携要求の発行は、無駄な仮想マシン切替及び仮想マシン間通信を引き起こすことである。

さらに、第３の問題は、処理負荷が低い検査手段を導入することで、不正或いは不適切なAPI呼出しを、一次的なフィルタとして除外することはできるが、このようなAPI呼出しが当該検査手段をパスした後は、引数やウィルスの検査などの処理負荷が高い検査が実行されるため、API呼出しの処理遅延が増加し、応答性が低下し得ることである。

そこで、本発明は、オープン実行環境とクローズド実行環境とを備えるデバイスにおいて、オープン実行環境とクローズド実行環境とでのAPI呼出しによる連携に関して、低いオーバヘッドで安全性及び信頼性を確保できるAPI検査装置及び状態監視装置の提供を目的とする。

上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、信頼されたプログラム（許可プログラムＰ１）以外のプログラム（例えば、非信頼プログラムＰ２）も自由に或いは一定の制限の下に実行することができるオープン実行環境（オープン実行環境１２０）と、前記オープン実行環境からアプリケーション・プログラム・インタフェース（API１３１）を呼び出すAPI呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行されるクローズド実行環境（クローズド実行環境１３０）とを備えるデバイス（デバイス１００）において前記クローズド実行環境に配置されるAPI検査装置（API検査装置３００）であって、前記オープン実行環境から前記クローズド実行環境内の前記API呼出しを許可するか否かの判定を要求する判定要求を受け付けるAPI検査要求受付部（API検査要求受付部３０１）と、前記デバイスの状態を示す状態情報を取得する状態情報取得部（状態情報取得部３０３）と、前記状態情報取得部が取得した前記状態情報に基づいて、前記API呼出しに対する検査モードを設定する検査モード設定部（検査モード設定部３０５）と、前記検査モード設定部によって設定された前記検査モードに基づいて、前記API呼出しを許可するか否かを判定し、前記API呼出しの検査結果を生成する判定部（判定部３０７）と、前記判定部によって生成された前記検査結果を出力する検査結果出力部（検査結果出力部３０９）とを備えることを要旨とする。

本発明の第２の特徴は、本発明の第１の特徴に係り、前記状態情報取得部は、前記デバイスの前記状態情報として、ローカルロック状態、遠隔ロック状態または所定時間に渡って前記デバイスへの入力操作がないことを示す無入力操作状態の少なくとも何れかを取得し、前記検査モード設定部は、前記状態情報が前記ローカルロック状態、前記遠隔ロック状態または前記無入力操作状態である場合、前記検査モードをユーザ操作禁止モードに設定し、前記判定部は、前記ユーザ操作禁止モードに設定されており、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別のAPI呼出しである場合、前記API呼出しを禁止することを要旨とする。

本発明の第３の特徴は、本発明の第１の特徴に係り、前記状態情報取得部は、前記状態情報として非信頼フラグを用い、前記非信頼フラグは、信頼されていない非信頼プログラム（非信頼プログラムＰ２）が前記オープン実行環境において実行中、または前記非信頼プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記非信頼プログラムが実行中でない、または前記非信頼プログラムが前記デバイスにインストールされていない場合にリセットされ、前記検査モード設定部は、前記非信頼フラグがセット状態の場合、ユーザ警告モードに設定し、前記判定部は、前記ユーザ警告モードに設定されている場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを要旨とする。

本発明の第４の特徴は、本発明の第１の特徴に係り、前記状態情報取得部は、前記状態情報として許可フラグを用い、前記許可フラグは、前記クローズド実行環境に対するAPI呼出しを正常に実行するために必須とされる必須プログラムが前記オープン実行環境において正常動作中、または前記必須プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記必須プログラムが障害の場合、または前記必須プログラムが前記デバイスにインストールされていない場合にリセットされ、
前記検査モード設定部は、前記許可フラグがリセット状態の場合、ユーザ警告モードに設定し、前記判定部は、前記ユーザ警告モードに設定されている場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを要旨とする。

本発明の第５の特徴は、本発明の第１の特徴に係り、前記API検査要求受付部は、前記アプリケーション・プログラム・インタフェースの呼び出し元であるAPI呼出し元のプログラム識別子を含む判定要求を受け付け、前記状態情報取得部は、前記クローズド実行環境に対する前記API呼出しを許可された複数の許可プログラム（許可プログラムＰ１）それぞれについて、前記オープン実行環境において実行中、または前記許可プログラムが前記デバイスにインストールされている場合にセットされる許可フラグのリストを含む許可フラグリストを前記状態情報として取得し、前記判定部は、前記プログラム識別子に対応する前記許可フラグがリセット状態である場合に、前記ユーザに警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを要旨とする。

本発明の第６の特徴は、本発明の第１の特徴に係り、前記状態情報取得部は、前記ローカルロック状態または前記遠隔ロック状態が他の状態に変化したときに、変化後の状態に従ってロック解除待ち連携抑制フラグを設定するとともに、前記オープン実行環境において実行される前記プログラムの状態を監視する状態監視装置に、前記変化後の状態に従って前記ロック解除待ち連携抑制フラグを通知することを要旨とする。

本発明の第７の特徴は、本発明の第１の特徴に係り、前記状態情報取得部は、前記クローズド実行環境において前記ユーザの確認待ち状態が所定時間経過した場合、ユーザ確認待ち連携抑制フラグをセットするとともに、前記オープン実行環境において実行される前記プログラムの状態を監視する状態監視装置に前記ユーザ確認待ち連携抑制フラグがセットされたことを通知し、前記ユーザ確認待ち連携抑制フラグがセット状態においてユーザ確認待ち状態が終了した場合、前記ユーザ確認待ち連携抑制フラグをリセットするとともに、前記状態監視装置に前記ユーザ確認待ち連携抑制フラグがリセットされたことを通知することを要旨とする。

本発明の第８の特徴は、本発明の第１の特徴に係り、前記判定部は、前記検査結果として、前記API呼出しの禁止、前記API呼出しの許可、及び前記API呼出しの拒否の何れかを前記検査結果の理由を示すコードとともに生成することを要旨とする。

本発明の第９の特徴は、本発明の第１の特徴に係り、前記検査モード設定部は、許可と判定された前記API呼出しと同一種別のAPI呼出し、または同一のAPI呼出し元を示す前記プログラム識別子を含むAPI呼出しについて、所定回数または所定時間に渡って無条件に許可する検査省略モードを設定し、前記判定部は、前記検査省略モードに設定されている場合、前記API呼出しの検査を省略したことを示す前記検査結果を生成することを要旨とする。

本発明の第１０の特徴は、本発明の第１の特徴に係り、前記アプリケーション・プログラム・インタフェースの種別と、前記種別のAPI呼出しを許可または拒否する前記プログラム識別子とを管理するAPI制限管理部（API制限管理部３１１）を備え、前記API検査要求受付部は、前記API呼出し元のプログラム識別子と、前記種別を含む判定要求を受け付け、前記判定部は、前記API制限管理部に問い合わせ、前記判定要求に含まれる前記プログラム識別子がAPI呼出しを許可される前記種別に該当する場合、前記API呼出しを許可することを要旨とする。

本発明の第１１の特徴は、本発明の第１０の特徴に係り、前記API制限管理部は、前記種別と前記種別のAPI呼出しを許可または拒否する前記プログラム識別子とに加えて、前記デバイスのユーザに前記API呼出しの許可の問い合わせを行うか否かを示す問い合わせフラグと、前記問い合わせを行うか否かの判定に用いられるAPI呼出し引数の条件とを管理し、前記判定部は、前記API制限管理部に問い合わせ、前記判定要求に含まれる前記プログラム識別子がAPI呼出しを許可される前記種別に該当するとともに、前記問い合わせフラグがセットされ、前記API呼出し引数の条件を満足する場合、前記ユーザに前記問い合わせを行い、前記ユーザによって前記API呼出しが許可された場合、前記API呼出しを許可することを要旨とする。

本発明の第１２の特徴は、本発明の第１の特徴に係り、前記状態監視装置としての機能を提供する状態監視装置プログラムの完全性を検査し、前記状態監視装置プログラムに対する改ざんが検出された場合、前記API呼出しを禁止する完全性検査部（完全性検査部３１３）を備えることを要旨とする。

本発明の第１３の特徴は、本発明の第９の特徴に係り、前記検査モード設定部は、前記検査省略モードが設定されている場合において、前記デバイスの構成変更が行われた場合、前記検査省略モードを解除することを要旨とする。

本発明の第１４の特徴は、信頼されたプログラム（許可プログラムＰ１）以外のプログラム（例えば、非信頼プログラムＰ２）も自由に或いは一定の制限の下に実行することができるオープン実行環境（オープン実行環境１２０）と、前記オープン実行環境からアプリケーション・プログラム・インタフェース（API１３１）を呼び出すAPI呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行されるクローズド実行環境（クローズド実行環境１３０）とを備えるデバイス（デバイス１００、デバイス１００Ａ及びデバイス１００Ｂ）において前記オープン実行環境に配置される状態監視装置（状態監視装置２００）であって、前記デバイスの状態を取得し、取得した前記状態を示す状態情報を保持する状態管理部（状態管理部２０１）と、前記状態情報に基づいて、前記オープン実行環境から前記クローズド実行環境内の前記API呼出しを許可するか否かを決定する許可決定部（許可決定部２０３）とを備えることを要旨とする。

本発明の第１５の特徴は、本発明の第１４の特徴に係り、前記状態管理部は、前記デバイスがローカルロック状態、遠隔ロック状態、または所定時間に渡って前記デバイスへの入力操作がないことを示す無入力操作状態の場合にのみセットされるユーザ操作API禁止フラグを保持し、前記許可決定部は、前記ユーザ操作API禁止フラグがセット状態であり、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別の前記API呼出しである場合、前記API呼出しを禁止することを要旨とする。

本発明の第１６の特徴は、本発明の第１４の特徴に係り、前記状態管理部は、前記状態情報として非信頼フラグを保持し、前記非信頼フラグは、信頼されていない非信頼プログラムが前記オープン実行環境において実行中、または前記非信頼プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記非信頼プログラムが実行中でない、または前記非信頼プログラムが前記デバイスにインストールされていない場合にリセットされ、前記許可決定部は、前記非信頼フラグがセット状態の場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを決定することを要旨とする。

本発明の第１６の特徴は、本発明の第１５の特徴に係り、前記状態管理部は、前記状態情報として、前記クローズド実行環境に対する前記API呼出しを許可された複数の許可プログラムそれぞれについて、前記オープン実行環境において実行中の場合にセットされる前記許可フラグのリストである許可フラグリストを保持することを要旨とする。

本発明の第１７の特徴は、本発明の第１４の特徴に係り、前記状態管理部は、前記状態情報として許可フラグを保持し、前記許可フラグは、前記クローズド実行環境に対するAPI呼出しを正常に実行するために必須とされる必須プログラムが前記オープン実行環境において正常動作中、または前記必須プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記必須プログラムが障害の場合、または前記必須プログラムが前記デバイスにインストールされていない場合にリセットされ、
前記許可決定部は、前記許可フラグがリセット状態の場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを決定することを要旨とする。

本発明の第１８の特徴は、本発明の第１６の特徴に係り、前記非信頼フラグがセット状態に変化したとき、前記クローズド実行環境に配置されるAPI検査装置（API検査装置３００）に前記状態情報を通知する状態情報通知部（状態情報通知部２０５）を備えることを要旨とする。

本発明の第１９の特徴は、本発明の第１７の特徴に係り、前記許可フラグがリセット状態に変化したとき、前記クローズド実行環境に配置されるAPI検査装置（API検査装置３００）に前記状態情報を通知する状態情報通知部（状態情報通知部２０５）を備えることを要旨とする。

本発明の第２０の特徴は、本発明の第１４の特徴に係り、前記状態管理部は、ローカルロック状態または遠隔ロック状態が他の状態に変化したときに設定されるロック解除待ち連携抑制フラグ、またはクローズド実行環境において前記ユーザの確認待ち状態が所定時間経過したときにセットされるユーザ確認待ち連携抑制フラグの少なくとも何れかを、前記クローズド実行環境に配置されるAPI検査装置から前記状態情報として受信して保持し、前記許可決定部は、前記ロック解除待ち連携抑制フラグ及び前記ユーザ確認待ち連携抑制フラグの何れもがリセット状態である場合にのみ、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別の前記API呼出しを許可することを要旨とする。

本発明の第２１の特徴は、本発明の第２０の特徴に係り、前記状態管理部は、所定のタイムアウト時間が経過した場合、前記ユーザ確認待ち連携抑制フラグをリセットすることを要旨とする。

本発明の第２２の特徴は、本発明の第２０の特徴に係り、前記状態管理部は、前記API呼出しが要求された後、所定時間に渡って前記API呼出しに対する応答がない場合、前記ユーザによる確認待ち状態と判断し、前記ユーザ確認待ち連携抑制フラグをセットし、前記許可決定部は、前記ユーザ確認待ち連携抑制フラグがセット状態である場合にのみ、前記ユーザの操作によって要求された場合にのみ許可される前記API呼出しを禁止することを要旨とする。

本発明の特徴によれば、オープン実行環境とクローズド実行環境とを備えるデバイスにおいて、オープン実行環境とクローズド実行環境とでのAPI呼出しによる連携に関して、低いオーバヘッドで安全性及び信頼性を確保できるAPI検査装置及び状態監視装置を提供できる。

本発明の実施形態に係るデバイス１００の機能ブロック図である。 本発明の実施形態に係る状態情報の具体例を示す図である。 本発明の実施形態に係るロック状態や操作状態に応じたAPI呼出しの抑制手順を示す図である。 本発明の実施形態に係る状態情報の通知手順を示す図である。 本発明の実施形態に係る非信頼フラグまたは許可フラグによるAPI呼出しの抑制手順（その１）を示す図である。 本発明の実施形態に係る非信頼フラグまたは許可フラグによるAPI呼出しの抑制手順（その２）を示す図である。 本発明の実施形態に係る連携抑制フラグ（ロック解除待ち連携抑制フラグ及びユーザ確認待ち連携抑制フラグ）によるAPI呼出しの抑制手順（その１）を示す図である。 本発明の実施形態に係る連携抑制フラグ（ロック解除待ち連携抑制フラグ及びユーザ確認待ち連携抑制フラグ）によるAPI呼出しの抑制手順（その２）を示す図である。 本発明の実施形態に係る検査モードの設定手順を示す図である。 本発明の実施形態に係るAPI呼出しの検査手順を示す図である。 本発明の実施形態に係るAPI制限管理部３１１によるAPI１３１の制限例を示す図である。 本発明のその他の実施形態に係るデバイス１００Ａの機能ブロック図である。 本発明のその他の実施形態に係るデバイス１００Ｂの機能ブロック図である。

次に、本発明の実施形態について説明する。具体的には、（１）デバイスの機能ブロック構成、（２）状態監視装置の機能ブロック構成、（３）API検査装置の機能ブロック構成、（４）作用・効果、及び（５）その他の実施形態について説明する。

なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。

したがって、具体的な寸法などは以下の説明を参酌して判断すべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。

（１）デバイスの機能ブロック構成
図１は、本実施形態に係るデバイス１００の機能ブロック図である。デバイス１００では、１つのCPU（不図示）上において複数のオペレーティングシステム（OS）を並行して動作可能なソフトウェア或いはハードウェアである仮想マシンモニタ１１０（VMM）が設けられる。

本実施形態では、オープン実行環境１２０と、クローズド実行環境１３０とがそれぞれOSとして実現される。すなわち、デバイス１００は、オープン実行環境１２０とクローズド実行環境１３０とを備える。

オープン実行環境１２０では、デバイス１００の提供者（端末メーカや通信オペレータなど）によって信頼されたプログラムである許可プログラムＰ１以外のプログラム（非信頼プログラムＰ２及び）も自由に、或いは一定の制限の下に実行することができる。

クローズド実行環境１３０では、オープン実行環境１２０からアプリケーション・プログラム・インタフェース１３１（以下、API１３１）を呼び出すAPI呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行される。

オープン実行環境１２０には、状態監視装置２００が配置される。状態監視装置２００は、オープン実行環境１２０において実行されるプログラムの状態を監視し、当該状態を示す状態情報をAPI検査装置３００に通知する。

クローズド実行環境１３０には、API検査装置３００が配置される。API検査装置３００は、オープン実行環境１２０において実行されるプログラムによるAPI呼出しの正当性などを検査する。

オープン実行環境１２０とクローズド実行環境１３０は、仮想マシン（VM）間通信機能を利用して相互に通信する。なお、本実施形態では、状態監視装置２００及びAPI検査装置３００は、デバイスドライバとして実装されることを想定しているが、ミドルウェアなどOS上のソフトウェアとして実装されてもよいし、ハードウェアとして実装されてもよい。

（２）状態監視装置の機能ブロック構成
図１に示すように、状態監視装置２００は、状態管理部２０１、許可決定部２０３及び状態情報通知部２０５を備える。以下、各ブロックの機能について説明する。

（２．１）状態管理部２０１
状態管理部２０１は、デバイス１００の状態を取得し、取得した前記状態を示す状態情報を保持する。図２は、状態情報の具体例を示す。図２に示すように、状態管理部２０１は、デバイス１００の状態情報として、非信頼フラグを保持することができる。非信頼フラグは、信頼されていない非信頼プログラムＰ２がオープン実行環境１２０において実行中、または非信頼プログラムＰ２がデバイス１００にインストールされている場合にセットされる。一方、非信頼フラグは、非信頼プログラムＰ２が実行中でない、または非信頼プログラムＰ２がデバイス１００にインストールされていない場合にリセットされる。

非信頼プログラムの例として、デバッガソフト、USBやBluetoothを用いて外部のPCなどと接続して通信を中継するプログラム、ゲームに似せたウィルスやスパイウェアプログラムなどが考えられる。また、非信頼プログラムの識別は、例えば、デジタル署名の有無の検査によって実現できる。特定の組織（端末メーカ、通信オペレータ及び特定のソフトウェアベンダなど）のデジタル署名が付加されていないプログラムは、信頼できないとみなす。または、ホワイトリストに信頼するプログラムを記載し、当該プログラム以外を信頼できないとみなしてもよい。或いは、ブラックリストに信頼できないプログラムを記載し、当該プログラムを信頼できないとみなしてもよい。

また、状態管理部２０１は、状態情報として許可フラグを保持することができる。許可フラグは、クローズド実行環境１３０に対するAPI呼出しを正常に実行するために必須とされる必須プログラムＰ３がオープン実行環境１２０において正常動作中、または必須プログラムＰ３がデバイス１００にインストールされている場合にセットされる。また、必須プログラムＰ３が障害の場合、または必須プログラムＰ３がデバイス１００にインストールされていない場合にリセットされる。なお、必須プログラムＰ３の障害の検知は、状態管理部２０１が必須プログラムＰ３に問い合わせを行い、正常な応答があるか否かを確認することなどで実現できる。

必須プログラムＰ３は、例えば、VM間通信機能や、オープン実行環境１２０の安全性を守るためのウィルススキャンプログラム、クローズド実行環境１３０のAPIを呼び出せるアプリケーションが限定されている場合、そのAPI呼出しを許可された当該アプリケーションなどが考えられる。

さらに、状態管理部２０１は、デバイス１００がローカルロック状態、遠隔ロック状態、または無入力操作状態の場合にのみセットされるユーザ操作API禁止フラグを状態情報として保持することができる。

ローカルロック状態とは、正当な暗証番号やパスワードの入力、特定のボタン押下などを行わない限り、ユーザがデバイス１００の操作を行えないように、デバイス１００がロックしている状態である。ユーザが一定時間操作をしていなかったり、クラムシェル型の端末を閉じたり、特定のボタンや設定を行うことで、デバイス１００はローカルロック状態に遷移する。

一方、遠隔ロック状態とは、デバイス１００がデバイス１００を管理するサーバからの要求や、遠隔ユーザからの要求に基づき、デバイス１００の操作を行えないように、ロックしている状態である。ローカルロック状態及び遠隔ロック状態の何れもOSやミドルウェアなどの状態を管理するソフトウェアが提供しているAPIを通じてロック状態を取得することができる。

無入力操作状態とは、所定時間に渡ってデバイス１００への入力操作がない状態である。現在から一定時間における操作の有無は、例えば、キーパッドのデバイスドライバを用いてログを収集すれば判定できる。

また、プログラムの実行状態やインストール状態の取得は、OSのプロセス管理機能やアプリケーション管理機能の利用、RAM（不図示）のスキャン、各プログラムが特定の領域に書き込むフラグやデータの確認、またはプログラムが起動した際に発行する通知の受領などによって実現できる。状態管理部２０１は、状態情報をRAMまたはハードディスクなどのストレージに記憶することによって保持する。なお、状態情報は、改ざんできない安全な場所において保持することが望ましい。

さらに、状態管理部２０１は、ローカルロック状態または遠隔ロック状態が他の状態に変化したときに設定されるロック解除待ち連携抑制フラグをクローズド実行環境１３０に配置されるAPI検査装置３００から状態情報として受信して保持することもできる。また、状態管理部２０１は、クローズド実行環境１３０においてユーザの確認待ち状態が所定時間経過したときにセットされるユーザ確認待ち連携抑制フラグをAPI検査装置３００から状態情報として受信して保持することもできる。

状態管理部２０１は、所定のタイムアウト時間が経過した場合、ユーザ確認待ち連携抑制フラグをリセットする。また、状態管理部２０１は、API呼出しが要求された後、所定時間に渡ってAPI呼出しに対する応答がない場合、ユーザによる確認待ち状態と判断し、ユーザ確認待ち連携抑制フラグをセットする。

（２．２）許可決定部２０３
許可決定部２０３は、状態管理部２０１が保持している状態情報に基づいて、オープン実行環境１２０からクローズド実行環境１３０内のAPI呼出しを許可するか否かを決定する。具体的には、プログラム（アプリケーションなど）がVM間通信機能を呼び出す際、VM間通信機能は、状態監視装置２００にAPI呼出しを許可するか否かを問い合わせる。許可決定部２０３は、当該問い合わせに対してAPI呼出しを許可するか否かの決定結果を応答する。或いは、プログラムが状態監視装置２００に問い合わせてAPI呼出しが許可された場合に、VM間通信機能にアクセスしてAPI呼出しを実行してもよい。

許可決定部２０３は、ユーザ操作API禁止フラグがセット状態であり、ユーザの操作によって要求された場合にのみ許可されている種別のAPI呼出しである場合、当該API呼出しを禁止（抑制）することができる。また、許可決定部２０３は、非信頼フラグがセット状態の場合、ユーザに状態情報に従った警告を行い、API呼出しを許可するか否かのユーザに対する確認をした後、または当該確認をすることなくAPI呼出しを拒否することもできる。例えば、非信頼フラグがセット状態の場合、「システムが正常でない可能性があるため処理を中断します」といった内容の警告を行い、API呼出しを禁止する。

また、許可決定部２０３は、許可フラグがリセット状態の場合、ユーザに状態情報に従った警告を行い、API呼出しを許可するか否かのユーザに対する確認をした後、または当該確認をすることなくAPI呼出しを拒否することを決定することもできる。例えば、許可フラグがリセット状態の場合、「システムが正常でない可能性がありますが、処理を続行しますか」といった内容の警告を行う。この警告は、一度行った後は再度の警告を控えてもよい。例えば、デバイス１００の起動後に一度警告したらデバイス１００を再起動後するまで警告を控えてもよい。或いは、ユーザに対して警告を継続するか否かを問い合わせてもよい。

許可決定部２０３は、ロック解除待ち連携抑制フラグ及びユーザ確認待ち連携抑制フラグの何れもがリセット状態である場合にのみ、ユーザの操作によって要求された場合にのみ許可されている種別のAPI呼出しを許可することができる。また、API呼出しが要求された後、所定時間に渡ってAPI呼出しに対する応答がない場合において、状態管理部２０１はユーザによる確認待ち状態と判断し、ユーザ確認待ち連携抑制フラグをセットする。許可決定部は、ユーザ確認待ち連携抑制フラグがセット状態である場合に、ユーザの操作によって要求された場合にのみ許可されるAPI呼出しを禁止する。

（２．３）状態情報通知部２０５
状態情報通知部２０５は、API検査装置３００に状態情報を通知する。具体的には、状態情報通知部２０５は、メッセージパッシングや共有メモリなどを用いてAPI検査装置３００に状態情報を通知する。なお、状態情報の通知は、状態監視装置２００からAPI検査装置３００への一方向通信でもよいし、API検査装置３００の確認応答をもらってもよい。さらに、通知内容を暗号化したり、MAC（メッセージ認証コード）やデジタル署名を付与したりしてもよい。

また、状態情報通知部２０５は、非信頼フラグがセット状態に変化したとき、及び許可フラグがリセット状態に変化したとき、クローズド実行環境１３０に配置されるAPI検査装置３００に状態情報を通知する。なお、API検査装置３００は、必ずしもクローズド実行環境１３０に配置されていなくても構わない。

（２．４）状態監視装置の動作
次に、状態監視装置２００の動作について説明する。具体的には、（２．４．１）ロック状態や操作状態に応じたAPI呼出しの抑制手順、（２．４．２）状態情報の通知手順、（２．４．３）非信頼フラグまたは許可フラグによるAPI呼出しの抑制手順、及び（２．４．４）連携抑制フラグによるAPI呼出しの抑制手順について説明する。

（２．４．１）ロック状態や操作状態に応じたAPI呼出しの抑制手順
図３は、ロック状態や操作状態に応じたAPI呼出しの抑制手順を示す。ここでは、プログラムがAPI呼出しを行う際、VM間通信機能を呼び出し、VM間通信機能が状態監視装置２００にAPI呼出しを許可するか否かを問い合わせる。

ステップ３１は、デバイス１００がローカルロック状態または遠隔ロック状態になったとき、或いは所定時間デバイス１００への入力操作がない無入力操作状態になったときに実行される。ステップ３１において、状態管理部２０１は、ユーザ操作API禁止フラグをセットし、その状態を保持する。

ステップ３２は、デバイス１００がローカルロック状態または遠隔ロック状態が解除されたとき、或いは無入力操作状態においてデバイス１００への入力操作があったときに実行される。ステップ３２において、状態管理部２０１は、ユーザ操作API禁止フラグをリセットし、その状態を保持する。

ステップ３３は、VM間通信機能が状態監視装置２００に問い合わせをしたときに実行される。ステップ３３において、許可決定部２０３は、ユーザ操作API禁止フラグがセット状態か否かを確認する。

ユーザ操作API禁止フラグがセット状態の場合（ステップ３３のＹＥＳ）、ステップ３４において、許可決定部２０３は、API呼出しがユーザの操作によって要求された場合にのみ許可するAPI呼出しの種別か否かを確認する。

ユーザの操作によって要求された場合にのみ許可するAPI呼出しである場合（ステップ３４のＹＥＳ）、ステップ３５において、許可決定部２０３は、当該API呼出しを禁止（抑制）することを決定し、VM間通信機能に応答する。

ユーザの操作によって要求された場合にのみ許可するAPI呼出しでない場合（ステップ３４のＮＯ）、ステップ３６において、許可決定部２０３は、当該API呼出しを許可することを決定し、VM間通信機能に応答する。

（２．４．２）状態情報の通知手順
図４は、状態情報の通知手順を示す。図４に示すように、ステップ４１において、状態管理部２０１は、オープン実行環境１２０におけるプログラムの実行状態の変化を検知し、状態情報として保持する。状態管理部２０１は、１つ以上の非信頼プログラムＰ２がオープン実行環境１２０で実行中またはインストールされている場合に非信頼フラグをセットする。また、状態管理部２０１は、クローズド実行環境１３０のAPI呼出しを正常に実行するために必須とされる必須プログラムＰ３がオープン実行環境１２０で正常動作中であるかまたはインストールされている場合、許可フラグをセットする。

ステップ４２において、許可決定部２０３は、フラグの変化を検出し、変化したフラグに対応した処理を実行する。許可フラグの状態が変化した場合、許可決定部２０３は、ステップ４３の処理を実行する。非信頼フラグの状態が変化した場合、ステップ４５の処理を実行する。複数のフラグの状態が変化した場合、許可決定部２０３は、ステップ４７の処理を実行する。

ステップ４３において、状態情報通知部２０５は、許可フラグの状態情報をAPI検査装置３００に通知する。

ステップ４４において、状態情報通知部２０５は、オプションとして、許可フラグがリセット状態の場合、システム（デバイス１００）が正常でない旨をユーザに警告してもよい。その際、状態監視装置２００は、ユーザに確認の上、復旧のためデバイス１００を再起動してもよい。

ステップ４５において、状態情報通知部２０５は、非信頼フラグの状態情報をAPI検査装置３００に通知する。

ステップ４６において、状態情報通知部２０５は、オプションとして、非信頼フラグがセット状態の場合、システム（デバイス１００）が正常でない旨をユーザに警告してもよい。その際、状態監視装置２００は、ユーザに確認の上、復旧のためデバイス１００を再起動してもよい。

ステップ４７において、状態情報通知部２０５は、許可フラグ及び非信頼フラグの状態情報としてAPI検査装置３００に通知する。

ステップ４８において、状態情報通知部２０５は、オプションとして、上述したステップ４４及び４６と同様に、復旧のためデバイス１００を再起動してもよい。

（２．４．３）非信頼フラグまたは許可フラグによるAPI呼出しの抑制手順
図５及び図６は、非信頼フラグまたは許可フラグによるAPI呼出しの抑制手順を示す。図５及び図６に示す抑制手順は、上述した状態情報の通知手順と似ているが、ここでは、非信頼フラグ及び許可フラグの設定について、さらに詳細に説明する。

図５に示すように、ステップ１０１において、状態管理部２０１は、オープン実行環境１２０におけるプログラムの実行状態或いはインストール状態の変化が検知された際に呼び出される。

ステップ１０２において、状態管理部２０１は、１つ以上の非信頼プログラムＰ２がオープン実行環境１２０で実行中か否かを判定する。

非信頼プログラムＰ２がオープン実行環境１２０で実行中でない場合（ステップ１０２のＮＯ）、ステップＳ１０３において、状態管理部２０１は、１つ以上の非信頼プログラムＰ２がオープン実行環境１２０にインストールされているか否かを判定する。

非信頼プログラムＰ２がオープン実行環境１２０で実行中である場合（ステップ１０２のＹＥＳ）、または非信頼プログラムＰ２がオープン実行環境１２０にインストールされている場合（ステップ１０３のＹＥＳ）、ステップ１０４において、状態管理部２０１は、非信頼フラグをセットする。

非信頼プログラムＰ２がオープン実行環境１２０にインストールされていない場合（ステップ１０３のＮＯ）、ステップ１０５において、クローズド実行環境１３０のAPI呼出しを正常に実行するために必須とされる必須プログラムＰ３がオープン実行環境１２０で正常動作中か否かを判定する。

必須プログラムＰ３がオープン実行環境１２０で正常動作中でない場合（ステップ１０５のＮＯ）、ステップＳ１０６において、状態管理部２０１は、必須プログラムＰ３がオープン実行環境１２０にインストールされているか否かを判定する。

必須プログラムＰ３がオープン実行環境１２０で正常動作中である場合（ステップ１０５のＹＥＳ）、または必須プログラムＰ３がオープン実行環境１２０にインストールされている場合（ステップ１０６のＹＥＳ）、ステップ１０７において、許可フラグをリセットする。

図６に示すステップ１０８の処理は、VM間通信機能が状態監視装置２００に問い合わせをした際に実行される。ステップ１０８において、状態管理部２０１は、非信頼フラグがセット状態か否かを判定する。

非信頼フラグがセット状態の場合（ステップ１０８のＹＥＳ）、状態情報通知部２０５は、ステップ１０９において、システム（デバイス１００）が正常でないため、当該処理を続行できない旨をユーザに警告する。次いで、ステップ１１４において、許可決定部２０３は、当該API呼出しを禁止（抑制）することを決定し、VM間通信機能に応答する。

非信頼フラグがリセット状態の場合（ステップ１０８のＮＯ）、ステップ１１０において、状態管理部２０１は、許可フラグがリセット状態か否かを判定する。

許可フラグがリセット状態の場合（ステップ１１０のＹＥＳ）、状態情報通知部２０５は、ステップ１１１において、システムが正常でないが、当該処理を続行するか否かをユーザに確認する。

ステップ１１２において、状態情報通知部２０５は、ユーザからの応答が処理の続行を要求しているか否かを判定する。

ユーザからの応答が処理の続行を要求している場合（ステップ１１２のＹＥＳ）、ステップ１１３において、許可決定部２０３は、当該API呼出しを許可することを決定し、VM間通信機能に応答する。また、許可フラグがセット状態の場合（ステップ１１０のＮＯ）、ステップ１１３において、許可決定部２０３は、当該API呼出しを許可することを決定し、VM間通信機能に応答する。

ユーザからの応答が処理の続行を要求していない場合（ステップ１１２のＮＯ）、ステップ１１４において、許可決定部２０３は、当該API呼出しを禁止（抑制）することを決定し、VM間通信機能に応答する。

（２．４．４）連携抑制フラグによるAPI呼出しの抑制手順
図７及び図８は、連携抑制フラグ（ロック解除待ち連携抑制フラグ及びユーザ確認待ち連携抑制フラグ）によるAPI呼出しの抑制手順を示す。ここでは、プログラムがAPI呼出しを行う際、VM間通信機能を呼び出し、VM間通信機能が状態監視装置２００にAPI呼出しを禁止（抑制）するか否かを問い合わせる。

図７（ａ）に示すように、ステップ２０１において、状態管理部２０１は、ロック解除待ち連携抑制フラグまたはユーザ確認待ち連携抑制フラグの少なくとも何れかをAPI検査装置３００から受信し、当該フラグを保持する。

ステップ２０２において、状態管理部２０１は、受信したフラグがユーザ確認待ち連携抑制フラグか否かを判定する。

受信したフラグがユーザ確認待ち連携抑制フラグである場合（ステップ２０２のＹＥＳ）、ステップ２０３において、状態管理部２０１は、ユーザ確認待ち連携抑制フラグがセット状態か否かを判定する。

ユーザ確認待ち連携抑制フラグがセット状態の場合（ステップ２０３のＹＥＳ）、ステップ２０４において、状態管理部２０１は、指定されたタイムアウト時間を設定し、処理を終了する。

図７（ｂ）に示すステップ２０５は、周期的に実行される。ステップ２０５において、状態管理部２０１は、設定したタイムアウト時間を経過した否かを周期的に判定する。

タイムアウト時間を経過した場合（ステップ２０５のＹＥＳ）、ステップ２０６において、状態管理部２０１は、ユーザ確認待ち連携抑制フラグをリセットする。

次いで、図８に示すステップ２０７は、VM間通信機能が状態監視装置２００に問い合わせをした際に実行される。ステップ２０７において、状態管理部２０１は、ロック解除待ち連携抑制フラグまたはユーザ確認待ち連携抑制フラグがセット状態か否かを判定する。

何れかの連携抑制フラグがセット状態の場合（ステップ２０７のＹＥＳ）、ステップ２０８において、状態管理部２０１は、当該API呼出しがユーザの操作によって要求された場合にのみ許可するAPI呼出しか否かを確認する。

ユーザの操作によって要求された場合にのみ許可するAPI呼出しである場合（ステップ２０８のＹＥＳ）、ステップ２０９において、許可決定部２０３は、当該API呼出しを禁止（抑制）することを決定し、VM間通信機能に応答する。

連携抑制フラグがリセット状態の場合（ステップ２０７のＮＯ）、またはユーザの操作によって要求された場合にのみ許可するAPI呼出しでない場合（ステップ２０８のＮＯ）、ステップ２１０において、許可決定部２０３は、当該API呼出しを許可することを決定し、VM間通信機能に応答する。

（３）API検査装置の機能ブロック構成
API検査装置３００は、クローズド実行環境１３０のAPI呼出しを処理する機能やクローズド実行環境１３０側のVM間通信機能などから、オープン実行環境１２０からのクローズド実行環境１３０に対するAPI呼出しを許可するか否かの判定要求を受け付け、当該API呼出しを許可するか拒否するか否かを状態監視装置２００に応答する。

図１に示すように、API検査装置３００は、API検査要求受付部３０１、状態情報取得部３０３、検査モード設定部３０５、判定部３０７、検査結果出力部３０９、API制限管理部３１１及び完全性検査部３１３を備える。

（３．１）API検査要求受付部３０１
API検査要求受付部３０１は、オープン実行環境１２０からクローズド実行環境１３０に対するAPI呼出しを許可するか否かの判定を要求する判定要求を受け付ける。具体的には、クローズド実行環境１３０のAPI呼出しを処理する機能やクローズド実行環境１３０側のVM間通信機能から判定要求を受け付ける。

API検査要求受付部３０１は、API呼出し元のプログラム識別子を含む判定要求を受け付けることができる。API呼出し元のプログラム識別子は、プログラムの名前、プログラムのユニークな番号、プログラムのハッシュ値、プログラムがAPI１３１を呼び出す際に指定する識別番号などの何れでもよい。

また、API検査要求受付部３０１は、API呼出し元のプログラム識別子と、API１３１の種別を含む判定要求を受け付けることもできる。API１３１の種別は、API１３１の名前やカテゴリ名、番号やカテゴリの番号、ハッシュ値など何れでもよい。また、プログラム識別子とAPI１３１の種別を兼ねて、プログラムがAPI１３１を呼び出す際に指定する識別番号を利用してもよい。

（３．２）状態情報取得部３０３
状態情報取得部３０３は、状態監視装置２００またはクローズド実行環境１３０のOSやミドルウェアからデバイス１００の状態情報を取得し、取得した状態情報を保持する。状態情報取得部３０３は、取得した状態情報をRAMまたはハードディスクなどのストレージに記憶することによって保持する。また、状態情報取得部３０３は、VM間通信機能が提供するメッセージパッシングや共有メモリなどを用いて、状態監視装置２００から状態情報を取得する。

上述したように、図２は、状態情報の具体例を示す。なお、状態情報の通知は、状態監視装置２００からAPI検査装置３００への一方向通信でもよいし、確認応答が求められている場合は確認応答（ACK）を状態監視装置２００に送信してもよい。また、MACやデジタル署名の付与、状態情報が暗号化されている場合、状態情報取得部３０３は、必要に応じて検証や復号を実行する。

また、状態情報取得部３０３は、状態情報として、ローカルロック状態、遠隔ロック状態または無入力操作状態を取得することができる。なお、クローズド実行環境１３０や仮想マシンモニタ１１０、またはその他のオープン実行環境１２０でない環境においてローカルロック状態、遠隔ロック状態または無入力操作状態を管理している場合、状態情報取得部３０３は、安全に当該状態情報を取得できる。一方、オープン実行環境１２０において当該状態を管理している場合、状態情報が改ざんされる可能性があり、状態情報取得部３０３は、必ずしも正しい状態情報を取得することができない。

また、状態情報取得部３０３は、ローカルロック状態または遠隔ロック状態の場合にロック解除待ち連携抑制フラグをセットし、状態監視装置２００に当該フラグをセットしたことを通知してもよい。同様に、状態情報取得部３０３は、クローズド実行環境１３０においてユーザの確認待ち状態が所定時間経過した場合にユーザ確認待ち連携抑制フラグをセットし、状態監視装置２００に当該フラグをセットしたことを通知してもよい。

また、状態情報取得部３０３は、ローカルロック状態または遠隔ロック状態が他の状態に変化したときに、変化後の状態に従ってロック解除待ち連携抑制フラグを設定するとともに、状態監視装置２００に、当該変化後の状態に従ってロック解除待ち連携抑制フラグを通知してもよい。

また、状態情報取得部３０３は、ユーザ確認待ち連携抑制フラグがセット状態においてユーザの確認待ち状態が終了した場合、ユーザ確認待ち連携抑制フラグをリセットするとともに、状態監視装置２００にユーザ確認待ち連携抑制フラグがリセットされたことを通知してもよい。さらに、状態情報取得部３０３は、ユーザ確認待ち連携抑制フラグがセット状態において所定のタイムアウト時間を超えている場合、状態監視装置２００へのユーザ確認待ち連携抑制フラグのリセットの通知を省略してもよい。

状態情報取得部３０３は、上述した状態管理部２０１と同様に、状態情報として非信頼フラグ及び許可フラグを用いる。非信頼フラグ及び許可フラグは、オープン実行環境１２０で動作する状態監視装置２００からセットしてもよいし、仮想マシンモニタ１１０が非信頼フラグを管理している場合は仮想マシンモニタ１１０からセットしてもよい。なお、非信頼プログラムＰ２の例や判定方法などは、状態管理部２０１と同様である。

状態情報取得部３０３は、クローズド実行環境１３０に対するAPI呼出しを許可された複数の許可プログラムＰ１それぞれについて、オープン実行環境１２０において実行中、またはその許可プログラムＰ１がデバイス１００にインストールされている場合にセットされる許可フラグのリストを含む許可フラグリストを状態情報として取得することもできる（図２参照）。

状態情報取得部３０３は、（ａ）API呼出しが所定回数行われた際、（ｂ）API呼出しが所定回数拒否された際、（ｃ）最後のAPI呼出しがなされた後、所定時間が経過した際、状態監視装置２００に状態情報の通知を要求することもできる。このような通知によれば、状態情報の通知の失敗などが発生しても、次に通知において、状態監視装置２００とAPI検査装置３００との間における状態情報の不整合が解消される。また、所定時間に渡って状態監視装置２００からの応答がない場合、API検査装置３００は、障害が発生したと判定し、対策を講じてもよい。例えば、API検査装置３００は、API呼出しの禁止、デバイスの再起動、またはユーザに通知後のデバイス再起動などの対策を実行できる。

（３．３）検査モード設定部３０５
検査モード設定部３０５は、状態情報取得部３０３が取得した状態情報に基づいて、API呼出しに対する検査モードを設定する。検査モードは、API呼出しに対する検査のポリシーを示す。

検査モード設定部３０５は、状態情報がローカルロック状態、遠隔ロック状態または無入力操作状態である場合、検査モードをユーザ操作禁止モードに設定する。ユーザ操作禁止モードとは、ユーザ操作によって要求された場合にのみ許可する種別のAPI呼出しを禁止するモードである。

検査モード設定部３０５は、非信頼フラグがセット状態の場合、または許可フラグがリセット状態の場合、ユーザに状態情報に従った警告を行うユーザ警告モードに設定することができる。また、検査モード設定部３０５は、許可フラグの状態に基づいて検査モードを設定する場合、API検査要求受付部３０１が受け付けたプログラム識別子に対応するフラグがリセット状態である場合、ユーザ警告モードに設定することができる。

検査モード設定部３０５は、許可と判定されたAPI呼出しと同一種別のAPI呼出し、または同一のAPI呼出し元を示すプログラム識別子を含むAPI呼出しについて、所定回数または所定時間に渡って無条件に許可する検査省略モードを設定することができる。また、検査モード設定部３０５は、検査省略モードが設定されている場合において、デバイス１００の構成変更が行われた場合、検査省略モードを解除することができる。構成変更とは、アプリケーションの起動や終了、インストールやアンインストールなどである。

（３．４）判定部３０７
判定部３０７は、検査モード設定部３０５によって設定された検査モードに基づいて、API呼出しを許可するか否かを判定する。また、判定部３０７は、判定結果に基づいてAPI呼出しの検査結果を生成する。

判定部３０７は、ユーザ操作禁止モードに設定されており、ユーザの操作によって要求された場合にのみ許可されている種別のAPI呼出しである場合、当該API呼出しを禁止すると判定する。

また、判定部３０７は、ユーザ警告モードに設定されている場合、ユーザに当該状態情報に従った警告を行い、API呼出しを許可するか否かのユーザに対する確認をした後、または当該確認をすることなく当該API呼出しを拒否することができる。なお、ユーザに対する警告の内容は、上述した許可決定部２０３と同様で構わない。

判定部３０７は、API呼出しの禁止、API呼出しの許可及びAPI呼出しの拒否の何れかを検査結果として生成する。また、判定部３０７は、検査結果の理由を示すコードとともに当該検査結果を生成することもできる。当該コードとは、例えば、ユーザの操作に基づくAPI呼出しでないから禁止されているのか、API呼出しの実行に必須な必須プログラムＰ３が正常動作中でないから拒否されているのかである。

判定部３０７は、プログラム識別子に対応する許可フラグがリセット状態である場合、ユーザに警告を行い、API呼出しを許可するか否かの当該ユーザに対する確認をした後、または当該確認をすることなくAPI呼出しを拒否することができる。また、判定部３０７は、検査省略モードに設定されている場合、API呼出しの検査を省略したことを示す検査結果を生成する。

判定部３０７は、API検査要求受付部３０１が受け付けた判定要求に基づいて、API制限管理部３１１に問い合わせ、当該判定要求に含まれるプログラム識別子がAPI呼出しを許可される種別に該当する場合、当該API呼出しを許可することができる。さらに、判定部３０７は、許可フラグが許可フラグリストにおいてセット状態である場合、API制限管理部３１１に問い合わせ、判定要求に含まれるプログラム識別子がAPI呼出しを許可される種別に該当するとともに、問い合わせフラグがセットされ、API呼出し引数の条件を満足する場合、デバイス１００のユーザに問い合わせを行うことができる。

判定部３０７は、ユーザによってAPI呼出しが許可された場合、API呼出しを許可する。なお、ユーザに問い合わせる際、オープン実行環境１２０における不正なプログラムによる干渉を回避するため、クローズド実行環境１３０など、オープン実行環境１２０の外で、ユーザへの問い合わせメッセージの提示、問い合わせに対するユーザからの入力を行うことが望ましい。

また、判定部３０７は、API呼出し引数のサイズや型などのフォーマットや値、値の範囲を検査したり、受け渡しデータをスキャンしてウィルスの検査をしたりしてもよい。さらに、判定部３０７は、API呼出しの順序の履歴を検査し、特定のAPI呼出しの順序関係が正しいかを検査したりしてもよい。

（３．５）検査結果出力部３０９
検査結果出力部３０９は、判定部３０７によって生成されたAPI呼出しの検査結果を、API呼出しの判定を要求した判定要求元（API１３１の処理機能など）に出力する。

判定要求元は、上述したように、クローズド実行環境１３０のAPI呼出しを処理する機能やクローズド実行環境１３０側のVM間通信機能などである。判定要求元は、検査結果が「API検査省略」であった場合、リソース消費を削減するため、より詳細なAPI検査を省略してもよい。より詳細なAPI検査とは、例えば、API呼出し引数のサイズや型などのフォーマットや値、値の範囲の検査や 受け渡しデータのウィルス検査などである。

（３．６）API制限管理部３１１
API制限管理部３１１は、API１３１の種別と、当該種別のAPI呼出しを許可または拒否するプログラム識別子とを管理する。

図１１は、API制限管理部３１１によるAPI１３１の制限例を示す。図１１に示す制限例では、API１３１の種別として、DRM API、セキュアストレージAPI、及び暗号APIが規定されている。DRM APIについては、program1のみが許可される。セキュアストレージAPIについては、program1とprogram2が許可される。暗号APIについては、program1、program2、program3、program4が許可される。

API制限管理部３１１は、API１３１の種別と当該種別のAPI呼出しを許可または拒否するプログラム識別子とに加えて、デバイス１００のユーザにAPI呼出しの許可の問い合わせを行うか否かを示す問い合わせフラグと、問い合わせを行うか否かの判定に用いられるAPI呼出し引数の条件とを管理することもできる。例えば、API呼出し引数で指定されるURLのWebサイトにアクセスするAPI１３１において、当該URLが特定のドメイン名であった場合、API制限管理部３１１は、ユーザに問い合わせを行うことができる。他の例として、条件が指定されていない場合、無条件にユーザに問い合わせをすることができる。

（３．７）完全性検査部３１３
完全性検査部３１３は、状態監視装置２００としての機能を提供する状態監視装置プログラムの完全性を検査する。完全性検査部３１３は、状態監視装置プログラムに対する改ざんが検出された場合、API呼出しを禁止する。

完全性検査部３１３は、例えば、プログラムコードの正しいハッシュ値を保持しておき、周期的に或いは特定のイベントが起きた際に、当該プログラムコードのハッシュ値を計算して正しいハッシュ値と比較する。完全性検査部３１３は、比較結果が一致しない場合、改ざんがあったと判定することができる。特定のイベントとは、例えば、状態監視装置プログラムが格納されているメモリやファイル領域へのアクセス（読み込み或いは書き込み）があった場合、クローズド実行環境１３０の特定のAPI呼出しがあった場合、或いはオープン実行環境１２０での特定のAPIやシステムコールが呼出しされた場合などが考えられる。

さらに、完全性検査部３１３は、状態監視装置２００以外のオープン実行環境１２０内におけるOS、ミドルウェア及びアプリケーションプログラムなどの改ざん有無を検査してもよい。これらに対する改ざんが検出された場合、API呼出しを禁止することができる。また、完全性検査部３１３は、VMM（仮想マシンモニタ）の一部として実現されてもよい。

（３．８）API検査装置の動作
次に、API検査装置３００の動作について説明する。具体的には、検査モードの設定手順及びAPI呼出しの検査手順について説明する。

（３．８．１）検査モードの設定手順
図９は、API検査装置３００による検査モードの設定手順を示す。検査モードの設定手順は、状態監視装置２００からAPI検査装置３００（状態情報取得部３０３）に対して状態情報が入力された際か、状態情報取得部３０３が状態情報の変化を検知するか、通知された際に実行される。

図９に示すように、ステップ５１において、状態情報取得部３０３は、入力された状態情報を保持する。

ステップ５２において、状態情報取得部３０３は、入力された状態情報がユーザの操作に関する状態か否かを判定する。具体的には、状態情報取得部３０３は、ローカルロック状態、遠隔ロック状態または無入力操作状態であるか否かを判定する。

入力された状態情報がユーザの操作に関する状態である場合（ステップ５２のＹＥＳ）、ステップ５３において、検査モード設定部３０５は、検査モードをユーザ操作禁止モードに設定する。

ステップ５７において、状態情報取得部３０３は、入力された状態情報がローカルロック状態または遠隔ロック状態の何れであるか否かを判定する。

ローカルロック状態または遠隔ロック状態の何れであるか場合（ステップ５７のＹＥＳ）、ステップ５８において、状態情報取得部３０３は、ロック解除待ち連携抑制フラグを設定し、ロック解除待ち連携抑制フラグをセットしたことを状態監視装置２００に通知する。

一方、入力された状態情報がユーザの操作に関する状態でない場合、ステップ５４において、状態情報取得部３０３は、入力された状態情報が非信頼フラグか否かを判定する。

入力された状態情報が非信頼フラグでない場合（ステップ５４のＮＯ）、ステップ５５において、状態情報取得部３０３は、入力された状態情報が許可フラグか否かを判定する。

入力された状態情報が非信頼フラグである場合（ステップ５４のＹＥＳ）、または入力された状態情報が許可フラグである場合（ステップ５５のＹＥＳ）、ステップ５６において、検査モード設定部３０５は、検査モードをユーザ警告モードに設定する。

（３．８．２）API呼出しの検査手順
図１０は、API検査装置３００によるAPI呼出しの検査手順を示す。API呼出しの検査手順は、API検査要求受付部３０１が、クローズド実行環境１３０のAPI１３１の処理機能やクローズド実行環境１３０側のVM間通信機能などから、オープン実行環境１２０からのクローズド実行環境１３０に対するAPI呼出しを許可するかの判定要求を受け付けた際に実行される。ここでは、判定要求は、API呼出し元のプログラム識別子を含んでもよい。

ステップ６１において、判定部３０７は、設定されている検査モードを確認し、ユーザ操作禁止モードに設定されているか否かを判定する。

ユーザ操作禁止モードに設定されている場合（ステップ６１のＹＥＳ）、ステップ６２において、判定部３０７は、当該API呼出しがユーザの操作によって要求された場合にのみ許可される種別のAPI呼出しか否かを判定する。

当該API呼出しがユーザの操作によって要求された場合にのみ許可される種別のAPI呼出しである場合（ステップ６２のＹＥＳ）、ステップ６３において、判定部３０７は、検査結果として、API呼出しの禁止を生成する。

ユーザ操作禁止モードに設定されていない場合（ステップ６１のＮＯ）、ステップ６４において、判定部３０７は、検査モードがユーザ警告モードに設定されているか否かを判定する。

ユーザ警告モードに設定されている場合（ステップ６４のＹＥＳ）、ステップ６５において、判定部３０７は、非信頼フラグがセット状態か否かを判定する。

非信頼フラグがセット状態である場合（ステップ６５のＹＥＳ）、ステップ６６において、判定部３０７は、状態情報に従った警告を行う。

非信頼フラグがリセット状態である場合（ステップ６５のＮＯ）、ステップ６７において、判定部３０７は、許可フラグがリセット状態か否かを判定する。

許可フラグがリセット状態である場合（ステップ６７のＹＥＳ）、ステップ６８において、判定部３０７は、ユーザにAPI呼出しを許可するか否かを確認する。

ステップ６９において、判定部３０７は、ユーザが当該API呼出しを許可したか否かを判定する。

ステップ６６の処理に引き続いて、またはユーザが当該API呼出しを拒否した場合（ステップ６９のＮＯ）、ステップ７０において、判定部３０７は、検査結果として、API呼出しの拒否を生成する。

ユーザ警告モードに設定されていない場合（ステップ６４のＮＯ）、許可フラグがセット状態である場合（ステップ６７のＮＯ）、またはユーザが当該API呼出しを許可した場合（ステップ６９のＹＥＳ）、ステップ７１において、判定部３０７は、検査結果として、API呼出しの許可を生成する。

ステップ７２において、検査結果出力部３０９は、判定部３０７が生成した検査結果をAPI１３１の処理機能やVM間通信機能などに応答する。

なお、ステップ６７において、状態情報取得部３０３がプログラム識別子に対応するリストの形式で許可フラグを保持している場合、判定要求に含まれる「API呼出し元のプログラム識別子」に対応するプログラムが、判定部３０７は、許可フラグにおいてリセット状態でないかを確認してもよい。許可フラグがリセット状態である場合、当該プログラムが実行されていないことを示すため、不正なプログラムが正当なプログラムに成りすますことによって、API呼出しを行っている可能性がある。そこで、ユーザに警告したり、API呼出しを拒否したりしてもよい。

（４）作用・効果
本実施形態によれば、デバイス１００がローカルロック状態、遠隔ロック状態または無入力操作状態の場合、ユーザ操作禁止モードに設定される。ユーザ操作禁止モードでは、ユーザの操作によって要求された場合にのみ許可する種別のAPI呼出しの連携を禁止できる。これにより、不正プログラムが勝手に連携機能を呼び出すようなAPI呼出しを禁止することができる。すなわち、オーバヘッドを抑えつつ、不正なAPI呼出しを防止できる。

具体的には、比較的低い処理負荷で、状態情報を取得し、API呼出しを許可するか否かを判定できる。また、クローズド実行環境１３０において、当該状態を管理している場合、比較的低い処理負荷かつ安全な検査が実行できる。つまり、本実施形態によれば、OSによるアクセス制御だけに依存せず、かつ引数やデータの検査処理によるオーバヘッドを抑制できる。

本実施形態では、クローズド実行環境１３０からオープン実行環境１２０にロック解除待ち連携抑制フラグ及びユーザ確認待ち連携抑制フラグの状態が通知され、無効なAPI呼出しの連携が抑制される。このため、デバイス１００のバッテリ消耗を抑制できる。さらに、ユーザの確認待ちに係る連携抑制の解除については、タイマを用いることによって省略できるため、状態の通知頻度を最小化でき、通知に係るリソースの消費を削減できる。

本実施形態では、API呼出しの検査が成功した後は、指定回数のAPI呼出し、特定の種別のAPI呼出しについて検査を省略する（間引く）ことができるため、トレードオフの関係にある安全性とオーバヘッドとを適切なレベルに調整できる。

本実施形態では、状態情報に従った警告をユーザに対して行うことができる。このため、API呼出しが実行される前に、オープン実行環境１２０の安全性や信頼性に関する情報をユーザに知らしめることができる。ユーザは、当該情報に基づいて、API呼出しの許可を判断したり、未保存のデータを保存したりするなど、適切な対処をすることができる。

本実施形態では、プログラム識別子に対応する許可フラグがリセット状態である場合に、ユーザに警告を行うことができる。このため、許可プログラムＰ１以外のプログラムの成りすましによるAPI呼出しを確実に拒否できる。

本実施形態では、API呼出しの検査結果の理由を示すコードとともに検査結果を生成することができる。このため、プログラムやユーザによるAPI呼出しが失敗した際に、その理由を認識することができる。つまり、API呼出し元は、ユーザの操作に基づくAPI呼出しでないために禁止されているのか、API呼出しの実行に必須な必須プログラムＰ３が障害のため拒否されているのかなどを識別して適切な対応を取り得る。例えば、必須プログラムＰ３が障害の場合、ユーザは、デバイス１００を再起動することによって、デバイス１００を正常な状態に復旧し得る。

本実施形態では、検査省略モードが設けられているため、安全性を大きく犠牲にすることなく、API呼出しの検査頻度の低減による応答性低下の緩和やリソース消費の削減が期待できる。また、本実施形態では、システムの構成変更があった後には、検査省略モードが解除される。このため、一定の安全性も確保できる。

本実施形態では、判定要求に含まれるプログラム識別子がAPI呼出しを許可される種別に該当するとともに、問い合わせフラグがセットされ、API呼出し引数の条件を満足する場合、デバイス１００のユーザに問い合わせを行うことができる。このため、プログラムごとにきめ細かにAPI呼出しのアクセス制御ができ、信頼性や安全性を向上できる。また、判定要求に含まれるプログラム識別子がAPI呼出しを許可される種別に該当するとともに、問い合わせフラグがセットされ、API呼出し引数の条件を満足する場合、デバイス１００のユーザに問い合わせを行うことができる。このため、特定のAPI呼出しについてはユーザの確認に基づいて、その可否を判断できる。

本実施形態では、状態監視装置２００としての機能を提供する状態監視装置プログラムの完全性を検査する完全性検査部３１３が設けられる。このため、状態監視装置２００が攻撃された場合には、API呼出しを禁止することによって被害の拡大を防止できる。

本実施形態では、非信頼フラグがセット状態に変化したとき、または許可フラグがリセット状態に変化したとき、クローズド実行環境１３０に配置されるAPI検査装置３００に状態情報が通知される。このため、API呼出しが実行される前に、オープン実行環境１２０の安全性や信頼性の情報をクローズド実行環境１３０側においてユーザに通知できる。

（５）その他の実施形態
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。

上述したデバイス１００では、仮想マシンモニタ１１０を用いる場合を例として説明したが、マルチCPU（またはマルチコア）を用いて、オープン実行環境１２０とクローズド実行環境１３０とを形成しても構わない。

図１２は、マルチコア構成のCPU111Ａ及びCPU111Ｂを用いてオープン実行環境１２０とクローズド実行環境１３０とが形成されるデバイス１００Ａの機能ブロック図である。なお、状態監視装置２００及びAPI検査装置３００の構成は、上述したデバイス１００と同様であるため、その説明を省略する。

また、仮想マシンモニタ１１０に代えて、Java（登録商標）VMなどの仮想マシンを用いてオープン実行環境を形成し、ホストOSを用いてクローズド実行環境を形成してもよい。図１３は、仮想マシン及びホストOSを用いたデバイス１００Ｂの機能ブロック図である。デバイス１００Ｂでは、Java（登録商標）VMよってオープン実行環境１２０Ａが形成され、ホストOSによってクローズド実行環境１３０Ａが形成される。なお、状態監視装置２００及びAPI検査装置３００の構成は、上述したデバイス１００と同様であるため、その説明を省略する。

また、状態監視装置２００及びAPI検査装置３００は、それぞれ単独で提供しても構わない。

このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは勿論である。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。

１００，１００Ａ，１００Ｂ…デバイス、１１０…仮想マシンモニタ、111Ａ，１１１Ｂ…CPU、１２０，１２０Ａ…オープン実行環境、１３０，１３０Ａ…クローズド実行環境、１３１…アプリケーション・プログラム・インタフェース（API）、２００…状態監視装置、２０１…状態管理部、２０３…許可決定部、２０５…状態情報通知部、３００…API検査装置、３０１…API検査要求受付部、３０３…状態情報取得部、３０５…検査モード設定部、３０７…判定部、３０９…検査結果出力部、３１１…API制限管理部、３１３…完全性検査部、Ｐ１…許可プログラム、Ｐ２…非信頼プログラム、Ｐ３…必須プログラム

Claims (22)

1. 信頼されたプログラム以外のプログラムも自由に或いは一定の制限の下に実行することができるオープン実行環境と、前記オープン実行環境からアプリケーション・プログラム・インタフェースを呼び出すAPI呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行されるクローズド実行環境とを備えるデバイスにおいて前記クローズド実行環境に配置されるAPI検査装置であって、
   前記オープン実行環境から前記クローズド実行環境内の前記API呼出しを許可するか否かの判定を要求する判定要求を受け付けるAPI検査要求受付部と、
   前記デバイスの状態を示す状態情報を取得する状態情報取得部と、
   前記状態情報取得部が取得した前記状態情報に基づいて、前記API呼出しに対する検査モードを設定する検査モード設定部と、
   前記検査モード設定部によって設定された前記検査モードに基づいて、前記API呼出しを許可するか否かを判定し、前記API呼出しの検査結果を生成する判定部と、
   前記判定部によって生成された前記検査結果を出力する検査結果出力部と
   を備えるAPI検査装置。
2. 前記状態情報取得部は、前記デバイスの前記状態情報として、ローカルロック状態、遠隔ロック状態または所定時間に渡って前記デバイスへの入力操作がないことを示す無入力操作状態の少なくとも何れかを取得し、
   前記検査モード設定部は、前記状態情報が前記ローカルロック状態、前記遠隔ロック状態または前記無入力操作状態である場合、前記検査モードをユーザ操作禁止モードに設定し、
   前記判定部は、前記ユーザ操作禁止モードに設定されており、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別のAPI呼出しである場合、前記API呼出しを禁止する請求項１に記載のAPI検査装置。
3. 前記状態情報取得部は、前記状態情報として非信頼フラグを用い、
   前記非信頼フラグは、信頼されていない非信頼プログラムが前記オープン実行環境において実行中、または前記非信頼プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記非信頼プログラムが実行中でない、または前記非信頼プログラムが前記デバイスにインストールされていない場合にリセットされ、
   前記検査モード設定部は、前記非信頼フラグがセット状態の場合、ユーザ警告モードに設定し、
   前記判定部は、前記ユーザ警告モードに設定されている場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否する請求項１に記載のAPI検査装置。
4. 前記状態情報取得部は、前記状態情報として許可フラグを用い、
   前記許可フラグは、前記クローズド実行環境に対するAPI呼出しを正常に実行するために必須とされる必須プログラムが前記オープン実行環境において正常動作中、または前記必須プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記必須プログラムが障害の場合、または前記必須プログラムが前記デバイスにインストールされていない場合にリセットされ、
   前記検査モード設定部は、前記許可フラグがリセット状態の場合、ユーザ警告モードに設定し、
   前記判定部は、前記ユーザ警告モードに設定されている場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否する請求項１に記載のAPI検査装置。
5. 前記API検査要求受付部は、前記アプリケーション・プログラム・インタフェースの呼び出し元であるAPI呼出し元のプログラム識別子を含む判定要求を受け付け、
   前記状態情報取得部は、前記クローズド実行環境に対する前記API呼出しを許可された複数の許可プログラムそれぞれについて、前記オープン実行環境において実行中、または前記許可プログラムが前記デバイスにインストールされている場合にセットされる許可フラグのリストを含む許可フラグリストを前記状態情報として取得し、
   前記判定部は、前記プログラム識別子に対応する前記許可フラグがリセット状態である場合、前記ユーザに警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否する請求項１に記載のAPI検査装置。
6. 前記状態情報取得部は、前記ローカルロック状態または前記遠隔ロック状態が他の状態に変化したときに、変化後の状態に従ってロック解除待ち連携抑制フラグを設定するとともに、前記オープン実行環境において実行される前記プログラムの状態を監視する状態監視装置に、前記変化後の状態に従ってロック解除待ち連携抑制フラグを通知する請求項１に記載のAPI検査装置。
7. 前記状態情報取得部は、
   前記クローズド実行環境において前記ユーザの確認待ち状態が所定時間経過した場合、ユーザ確認待ち連携抑制フラグをセットするとともに、前記オープン実行環境において実行される前記プログラムの状態を監視する状態監視装置に前記ユーザ確認待ち連携抑制フラグを通知し、
   前記ユーザ確認待ち連携抑制フラグがセット状態においてユーザ確認待ち状態が終了した場合、前記ユーザ確認待ち連携抑制フラグをリセットするとともに、前記状態監視装置に前記ユーザ確認待ち連携抑制フラグがリセットされたことを通知する請求項１に記載のAPI検査装置。
8. 前記判定部は、前記検査結果として、前記API呼出しの禁止、前記API呼出しの許可、及び前記API呼出しの拒否の何れかを前記検査結果の理由を示すコードとともに生成する請求項１に記載のAPI検査装置。
9. 前記検査モード設定部は、許可と判定された前記API呼出しと同一種別のAPI呼出し、または同一のAPI呼出し元を示す前記プログラム識別子を含むAPI呼出しについて、所定回数または所定時間に渡って無条件に許可する検査省略モードを設定し、
   前記判定部は、前記検査省略モードに設定されている場合、前記API呼出しの検査を省略したことを示す前記検査結果を生成する請求項１に記載のAPI検査装置。
10. 前記アプリケーション・プログラム・インタフェースの種別と、前記種別のAPI呼出しを許可または拒否する前記プログラム識別子とを管理するAPI制限管理部を備え、
    前記API検査要求受付部は、前記API呼出し元のプログラム識別子と、前記種別を含む判定要求を受け付け、
    前記判定部は、前記API制限管理部に問い合わせ、前記判定要求に含まれる前記プログラム識別子がAPI呼出しを許可される前記種別に該当する場合、前記API呼出しを許可する請求項１に記載のAPI検査装置。
11. 前記API制限管理部は、前記種別と前記種別のAPI呼出しを許可または拒否する前記プログラム識別子とに加えて、前記デバイスのユーザに前記API呼出しの許可の問い合わせを行うか否かを示す問い合わせフラグと、前記問い合わせを行うか否かの判定に用いられるAPI呼出し引数の条件とを管理し、
    前記判定部は、前記API制限管理部に問い合わせ、前記判定要求に含まれる前記プログラム識別子がAPI呼出しを許可される前記種別に該当するとともに、前記問い合わせフラグがセットされ、前記API呼出し引数の条件を満足する場合、前記ユーザに前記問い合わせを行い、
    前記ユーザによって前記API呼出しが許可された場合、前記API呼出しを許可する請求項１０に記載のAPI検査装置。
12. 前記状態監視装置としての機能を提供する状態監視装置プログラムの完全性を検査し、前記状態監視装置プログラムに対する改ざんが検出された場合、前記API呼出しを禁止する完全性検査部を備える請求項１に記載のAPI検査装置。
13. 前記検査モード設定部は、前記検査省略モードが設定されている場合において、前記デバイスの構成変更が行われた場合、前記検査省略モードを解除する請求項９に記載のAPI検査装置。
14. 信頼されたプログラム以外のプログラムも自由に或いは一定の制限の下に実行することができるオープン実行環境と、前記オープン実行環境からアプリケーション・プログラム・インタフェースを呼び出すAPI呼出しに基づいて所定の処理が実行され、信頼されたプログラムのみが実行されるクローズド実行環境とを備えるデバイスにおいて前記オープン実行環境に配置される状態監視装置であって、
    前記デバイスの状態を取得し、取得した前記状態を示す状態情報を保持する状態管理部と、
    前記状態情報に基づいて、前記オープン実行環境から前記クローズド実行環境内の前記API呼出しを許可するか否かを決定する許可決定部と
    を備える状態監視装置。
15. 前記状態管理部は、前記デバイスがローカルロック状態、遠隔ロック状態、または所定時間に渡って前記デバイスへの入力操作がないことを示す無入力操作状態の場合にのみセットされるユーザ操作API禁止フラグを保持し、
    前記許可決定部は、前記ユーザ操作API禁止フラグがセット状態であり、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別の前記API呼出しである場合、前記API呼出しを禁止する請求項１４に記載の状態監視装置。
16. 前記状態管理部は、前記状態情報として非信頼フラグを保持し、
    前記非信頼フラグは、信頼されていない非信頼プログラムが前記オープン実行環境において実行中、または前記非信頼プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記非信頼プログラムが実行中でない、または前記非信頼プログラムが前記デバイスにインストールされていない場合にリセットされ、
    前記許可決定部は、前記非信頼フラグがセット状態の場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを決定する請求項１４に記載の状態監視装置。
17. 前記状態管理部は、前記状態情報として許可フラグを保持し、
    前記許可フラグは、前記クローズド実行環境に対するAPI呼出しを正常に実行するために必須とされる必須プログラムが前記オープン実行環境において正常動作中、または前記必須プログラムが前記デバイスにインストールされている場合にセットされるとともに、前記必須プログラムが障害の場合、または前記必須プログラムが前記デバイスにインストールされていない場合にリセットされ、
    前記許可決定部は、前記許可フラグがリセット状態の場合、前記デバイスのユーザに前記状態情報に従った警告を行い、API呼出しを許可するか否かの前記ユーザに対する確認をした後、または前記確認をすることなく前記API呼出しを拒否することを決定する請求項１４に記載の状態監視装置。
18. 前記非信頼フラグがセット状態に変化したとき、前記クローズド実行環境に配置されるAPI検査装置に前記状態情報を通知する状態情報通知部を備える請求項１６に記載の状態監視装置。
19. 前記許可フラグがリセット状態に変化したとき、前記クローズド実行環境に配置されるAPI検査装置に前記状態情報を通知する状態情報通知部を備える請求項１７に記載の状態監視装置。
20. 前記状態管理部は、ローカルロック状態または遠隔ロック状態が他の状態に変化したときに設定されるロック解除待ち連携抑制フラグ、またはクローズド実行環境において前記ユーザの確認待ち状態が所定時間経過したときにセットされるユーザ確認待ち連携抑制フラグの少なくとも何れかを、前記クローズド実行環境に配置されるAPI検査装置から前記状態情報として受信して保持し、
    前記許可決定部は、前記ロック解除待ち連携抑制フラグ及び前記ユーザ確認待ち連携抑制フラグの何れもがリセット状態である場合にのみ、前記デバイスのユーザの操作によって要求された場合にのみ許可されている種別の前記API呼出しを許可する請求項１４に記載の状態監視装置。
21. 前記状態管理部は、所定のタイムアウト時間が経過した場合、前記ユーザ確認待ち連携抑制フラグをリセットする請求項２０に記載の状態監視装置。
22. 前記状態管理部は、前記API呼出しが要求された後、所定時間に渡って前記API呼出しに対する応答がない場合、前記ユーザによる確認待ち状態と判断し、前記ユーザ確認待ち連携抑制フラグをセットし、
    前記許可決定部は、前記ユーザ確認待ち連携抑制フラグがセット状態である場合、前記ユーザの操作によって要求された場合にのみ許可される前記API呼出しを禁止する請求項２０に記載の状態監視装置。

Images