JP6991837B2 - 画像形成装置及びその制御方法 - Google Patents

Description

本発明は、アプリケーションプログラムのインストールに関するものである。

近年、画像形成装置においては、ＪＡＶＡ（登録商標）環境に代表されるようなアプリ動作環境が提供されている。ＪＡＶＡ（登録商標）の持つプログラムの可搬性を利用して、拡張可能なアプリを提供する技術が提案されている。

画像形成装置の機能やユーザビィリティの向上を図るために、上記ＪＡＶＡ（登録商標）環境などの環境下で動作するアプリを作成し、画像形成装置にインストールすることで、当該アプリにより所望の機能を実現できる。

アプリプラットフォームとしては、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ Ｉｎｉｔｉａｔｉｖｅ）Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（以下、ＯＳＧｉ）がある（非特許文献１）。ＯＳＧｉは、組み込み機器向けのＪＡＶＡ（登録商標）アプリプラットフォームである。ＯＳＧｉでは、ソフトウェアモジュールの管理単位としてバンドルを定義しており、インストール／開始／停止／更新／アンインストールからなるライフサイクルを管理するための仕様を定義している。ここで、バンドルとは、ＪＡＶＡ（登録商標）モジュールのことを指し、本発明においては、アプリケーションプログラム（以下「アプリ」と略称する）と同義である。そのため、以後アプリのことをバンドルと表記する。

このようなアプリプラットフォームでは、コピー、スキャン、プリント等の組み込み機能をバンドルが提供することができる。

各バンドルは、ＪＡＶＡ（登録商標）の標準仕様で設けられたパーミッションと呼ばれるセキュリティアクセス権限の仕組みを持つ。このパーミッションは、各バンドル個別に定義することが可能である。

「ＯＳＧｉ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ，Ｒｅｌｅａｓｅ４」， ｈｔｔｐ：／／ｗｗｗ．ｏｓｇｉ．ｏｒｇ／Ｄｏｗｎｌｏａｄ／Ｒｅｌｅａｓｅ４Ｖ４０， ２００５年１０月

しかしながら、バンドルが管理者権限のような強いパーミッションをもつことで、画像形成装置内に悪影響を与えるバンドルを作ることが可能である。例えば、開発中のバンドルとして、（ｊａｖａ．ｓｅｃｕｒｉｔｙ．ＡｌｌＰｅｒｍｉｓｓｉｏｎ）を保持するバンドルを作成する。それを開発時のテスト用の画像形成装置にインストールすることで、画像形成装置内のシステムバンドルへアクセスしてシステムバンドルの内部情報を抜き出すことも考えられる。

本発明は、開発中のアプリも含めて、画像形成装置の安全性を担保しながら、アプリのインストールを行う技術を提供することを目的とする。

本発明の画像形成装置は、アプリケーションのインストール時に、署名をチェックする設定になっているかを判定する第１の判定手段と、前記第１の判定手段で、署名をチェックする設定になっていない場合、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないかを判定する第２の判定手段と、前記第２の判定手段で、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないと判定された場合、前記アプリケーションのインストールを許可する手段を有することを特徴とする。

本発明によれば、開発中のアプリも含めて、画像形成装置の安全性を担保しながら、アプリのインストールを行うことができるという効果がある。

画像形成装置のハードウェア構成図 画像形成装置のソフトウェアモジュール階層図 バンドルのインストールする流れを示したブロック図 バンドル管理画面、インストール画面のＵＩを示した図 バンドルのリリースまでの状態と対応する画像形成装置の状態を説明したブロック図 バンドル管理サービスによる、署名チェック状態切り替えライセンスをインストールするフローチャート バンドルの内部構成について説明した図 禁止パーミッションリストの例を説明した図 画像形成装置にバンドルをインストールするときのインストール制御サービスのフローチャート バンドルインストール時のＯＳＧｉ拡張部のフローチャート ＯＳＧｉ拡張部が禁止パーミッション判定を行うときのフローチャート バンドルが保持するパーミッションが、禁止パーミッションに含まれるかどうかの判定方法について説明した図 ホワイトリスト形式の禁止パーミッションについて説明したブロック図 ＯＳＧｉ拡張部がホワイトリスト形式で定義された禁止パーミッションの禁止パーミッション保持判定を行うときのフローチャート バンドルが保持するパーミッションが、ホワイトリスト形式の禁止パーミッションに含まれるかどうかの判定方法について説明した図 ＯＳＧｉ拡張部がブラックリスト形式とホワイトリスト形式の両方で定義された禁止パーミッションの禁止パーミッション保持判定を行うときのフローチャート

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施形態１）
図１は、プリント機能やスキャン機能、ネットワーク通信機能などを備える画像形成装置１３０のハードウェア構成図である。

画像形成装置１３０は、スキャナ部１１３やプリンタ部１１４と電気的に接続され、一方でＬＡＮ１１６を介して外部デバイスと接続される。

ＣＰＵ１０１は、ＲＯＭ１０２に記憶された制御プログラム等に基づいて接続中の各種ハードウェアとのアクセスを統括的に制御し、またコントローラ内部で行われる各種処理についても統括的に制御する。

ＲＯＭ１０２は読み出し専用の不揮発記憶領域であり、画像形成装置１３０のブートプログラム、ファームウェアなどが格納されている。

ＲＡＭ１０３は、ＣＰＵ１０１が動作するためのシステムワークメモリであり、各種データを一時記憶するためのメモリである。このＲＡＭ１０３は、記憶した内容を電源ｏｆｆ後も保持可能なＦＲＡＭ（登録商標）およびＳＲＡＭ、電源ｏｆｆ後に記憶内容が消去されるＤＲＡＭなどにより構成される。

ＨＤＤ１０４は不揮発記憶領域であり、システムバンドルなどを格納する。図３で説明するインストールするバンドルを含むファームウェアは、ＨＤＤ１０４に格納される。

操作部Ｉ／Ｆ１０５は、システムバス１１９と操作部１１８を接続するインタフェース部である。具体的には操作部１１８に表示するデータをシステムバス１１９から受取り表示すると共に、操作部１１８からの入力情報をシステムバス１１９へ出力する。画像形成装置１３０に対するユーザの指示や情報提示は、操作部１１８を介して行う。

ネットワークＩ／Ｆ１０６はＬＡＮ１１６、ＷＡＮ１１７及びシステムバス１１９に接続し、外部との情報の入出力を行う。

スキャナＩ／Ｆ１０８は、スキャナ部１１３から受取った画像データに対して、補正、加工、及び編集を行う。

画像形成部１０９は、画像データの方向変換、画像圧縮、伸張部などを行う。

プリンタＩ／Ｆ１１０は、画像形成部１０９から送られた画像データを受取り、画像形成後にプリンタ部１１４にて印刷する。

図２は、本発明に関係する画像形成装置１３０のソフトウェアモジュール階層図である。なお図２以降に示す各ソフトウェアはＲＯＭ１０２、もしくは、ＨＤＤ１０４に保存され、ＣＰＵ１０１にて実行される。また、実行時に使用する各種情報はＲＡＭ１０３もしくはＨＤＤ１０４に保持してソフトウェア機能間での各種情報のやりとりを行う。さらに外部機器との通信は、ネットワークＩ／Ｆ１０６を用いて通信を行う。

次に各ソフトウェアの説明をする。ソフトウェアは、まずオペレーティングシステム（ＯＳ）プラットフォーム２０１を有する。

ＵＩ２０２はユーザインタフェースモジュールであり、オペレータが画像形成装置１３０に対する各種操作・設定を行う際に、装置とユーザ操作との仲介を行うモジュールである。このモジュールは、オペレータの操作に従い、後述の各種モジュールに入力情報を転送して処理の依頼、或いはデータの設定変更等を行う。

次に、ＪＡＶＡ（登録商標）側の構成について述べる。

ＪＡＶＡ（登録商標）側のソフトウェアプラットフォームは、ＪａｖａＶＭ２０７のランタイム環境として構成されており、インタプリタとしてのＪａｖａＶＭ２０７、ライブラリ２０８、フレームワーク群２０９で構成される。ライブラリ２０８は、標準のＡＰＩライブラリを含んで構成される。フレームワーク群２０９は、ＯＳＧｉ２１０を含んで構成され、このＯＳＧｉ２１０は、単一のＪａｖａＶＭ２０７に複数のバンドルを動作させる。更に、ＯＳＧｉ拡張部２１１は、インターフェース仕様であるＯＳＧｉ２１０に対する実装部分を担うモジュールである。ＯＳＧｉ拡張部２１１は、ＯＳＧｉ２１０の仕様を満たす範囲で必要に応じて機能を拡張可能であることを示す。このＯＳＧｉ２１０、及びＯＳＧｉ拡張部２１１は、バンドルのライフサイクルの管理やバンドル間通信機能などを提供する。

このＯＳＧｉ２１０上には、複数のシステムバンドル群２１２がある。システムバンドル群２１２としては、複数のバンドルを管理し、新たなバンドルの追加、更新、削除をするためのバンドル管理サービス２１４がある。バンドル管理サービス２１４は、ＰＣからのインストール指示を受信する受け口でもある。インストール指示を受診したバンドル管理サービス２１４は、インストール制御サービス２１３を利用して、バンドルの追加、更新を行う。

更に、システムバンドル群２１２の中には、画像形成装置１３０の認証機能を担う認証バンドル２１５がある。認証バンドル２１５は、ユーザが画像形成装置に認証中に任意のバンドルから任意のタイミングで認証情報の問い合わせがあるため、停止できない特性を持つバンドルである。

一方で、後からインストールするタイプの後入れバンドル群２１７がある。バンドルのインストールについては、図３で示す。後入れバンドル群２１７として、後入れバンドル２１９は、画像形成装置１３０において各種処理をユーザに提供する。例えば、画像の加工や圧縮バンドル、印刷制限などの部門管理を行うバンドルなどがある。

各種機能を実現する後入れバンドル２１９は、バンドル管理サービス２１４の管理下で動作する。バンドル管理サービス２１４は、管理下に追加されたバンドルのバージョンを含むバンドル情報、ライセンス情報などを保持している。

図３は、ＰＣ３００から画像形成装置１３０へ、後入れバンドル２１９をインストールする流れを示したブロック図である。

市販された後入れバンドル２１９は、図５で示すように改ざん防止の為、デジタル署名が付与され、そのうえで暗号化されている。また、後入れバンドル２１９は、パーミッション定義ファイル３０１が含まれる。このパーミッション定義ファイル３０１は、後入れバンドル２１９がインストール後に様々な機能を使用する上で利用可能なパーミッションを示す。ここで、パーミッションとは、ＪＡＶＡ（登録商標）の標準仕様で設けられたセキュリティアクセス権限の仕組みである。パーミッション定義ファイル３０１は、必要がなければ、保持しなくても構わない。このパーミッションは、通常以下のように、パーミッション名とｎａｍｅとａｃｔｉｏｎという形式で定義される。ｎａｍｅとａｃｔｉｏｎに取りうる値は、パーミッションの種類によって異なる。また、＊指定による、ワイルドカード指定が可能である。
（ＸＸＸＰｅｒｍｉｓｓｉｏｎ，“ｎａｍｅ”，“ａｃｔｉｏｎ”）

ＰＣ３００のＷＥＢブラウザにバンドルインストールＵＩ３０３を表示し、このバンドルインストールＵＩ３０３からインストールしたいバンドル２１９を指定し、インストールを行う。バンドルインストールＵＩ３０３で指定されたバンドルを受信したバンドル管理サービス２１４は、それをインストール制御サービス２１３に渡す。バンドルファイルを受信したインストール制御サービス２１３は、受信したバンドル２１９の復号化処理や正当性を示すデジタル署名をもつかの確認処理を行った上で、確認に問題がない場合は、最終的にＯＳＧｉ拡張部２１１にインストールを依頼する。図７で示す禁止パーミッションリスト３０２は、ＨＤＤ１０４に格納されている。ＯＳＧｉ拡張部２１１は、後述する画像形成装置１３０がデジタル署名チェックオフ状態の場合、この禁止パーミッションリスト３０２を参照し、バンドル２１９がもつパーミッションに禁止パーミッションを含むかどうかを確認した上でインストールを行う。ここで、パーミッションの管理は、ＯＳＧｉ２１０の規定に含まれ、また、最終的なバンドルのインストール処理を担っていることからも、禁止パーミッションのチェックは、ＯＳＧｉ拡張部２１１で実行することが最適と考えられる。インストールされたバンドルは、バンドル管理サービス２１４によって管理される。

図４は、バンドルインストールＵＩ３０３における、バンドル管理画面４００とインストール画面４３０を示した図である。

バンドル名４０１は、管理されているバンドル名を表示する。この例の場合、バンドルＡ４０５とバンドルＢ４０６の２つが管理されている。インストール日４０２は、各バンドルがインストールされた日付である。バンドルＩＤ４０３は、各バンドルに一意に割り振られたバンドルＩＤを表示している。状態４０４は、各バンドルの状態を示している。バンドルが開始であれば開始４０９、停止であれば停止４１２と表示される。開始ボタン４１６／停止ボタン４１３は、バンドルの開始停止を切り替える指示ボタンである。開始状態のバンドルの場合、停止ボタンとなり、停止状態のバンドルの場合、開始ボタンと表示される。開始状態のバンドル（本例では、「バンドルＡ４０５」）の停止ボタン４１３を押下すると、その状態４０４は停止に変更される。一方、停止状態のバンドル（本例では、「バンドルＢ４０６」）の開始ボタン４１６を押下すると、その状態４０４は開始に変更される。アンインストールボタン４１７、４２０は、各バンドルのアンインストール指示ボタンである。

次に、インストール画面４３０について説明する。参照ボタン４３３は、ファイルパスを選択する画面を表示する。その画面でバンドルファイルを指定すると、バンドルファイルのパス４３１にバンドルファイルへのパスが入力される。バンドルは、セキュリティやビジネス上の観点からインストール処理において、バンドルを復号するためのライセンスファイルが必要となる場合がある。その場合、参照ボタン４３４を押下すると、ファイルパスを選択する画面を表示する。そこでバンドル指定と同様にライセンスファイルを指定すると、ライセンスファイルのパス４３２にライセンスファイルへのパスが入力される。インストールボタン４３５が押下されると、バンドルファイルのパス４３１で指定したバンドルのインストールが開始される。

図５は、バンドルのリリースまでの状態と対応する画像形成装置の状態を説明したブロック図である。

開発環境５００は、開発中のバンドル５０１と画像形成装置５１０の状態について説明したものである。開発環境５００では、後述する市場環境とは異なり、ベリフィケーションを通す前の開発中であり、開発者は、自由にパーミッションを付与することができる。

バンドル５０１は、開発中であるため、バンドルの正当性を示すデジタル署名が付与されていない。そのため、バンドル５０１を画像形成装置５１０にインストール５３１を実行して動作確認を行う場合、画像形成装置５１０の署名チェック状態をオフ５１１にしておく必要がある。ここで署名チェックとは、バンドルインストール時に、バンドルに正規の署名が付与されているかをチェックするものであり、チェックした結果、正規の署名をもたない場合は、バンドルのインストールに失敗する。署名チェック状態５１１がオフ５１２とは、署名チェックを行わない状態を示す。

一方、市場環境５０２は、市場でリリースされた暗号化されたバンドル５０４と画像形成装置５２０の状態について説明したものである。市場環境５０２では、開発されたバンドルの市場リリース前には、バンドルの正当性の確認（ベリフィケーション）を行う。ベリフィケーションを行ったバンドルには、その正当性を証明する為のデジタル署名を付与する。バンドルを、画像形成装置にインストールする際に、必ずこの署名のチェックを行うことで、正当性が証明されたバンドルしかインストールすることができない。

開発したバンドル５０１を市場にリリースする為には、バンドルの正当性確認５３０が必要となる。このバンドルの正当性確認５３０とは、バンドルが利用するリソースが正常範囲内に収まるかなどの確認だけでなく、バンドルに適正なパーミッションが付与されているかどうかも確認される。その正当性が確認されたバンドル５０１には、デジタル署名５０３が付与される。その上で、セキュリティ確保の為に暗号化５０４が実施される。この暗号化を復号するめの鍵の情報を保持するために対応するライセンス５０５が必要となる。

また、市場環境５０２での画像形成装置５２０の状態は、署名チェック状態５１１をオン５２１にしておく必要がある。こうすることで、署名がない開発中のバンドル５０１は、市場の画像形成装置５２０にはインストールできなくなる。一方、署名５０３をもつリリースされた暗号化バンドル５０４は、ライセンス５０５と共にインストール５３２を実行することで画像形成装置５２０にインストール可能である。

このように、画像形成装置の署名チェック状態は重要な設定であるため、市場において簡単に切り替えることはできない仕組みが必要である。そこで、５３３で示すように、画像形成装置の署名チェック状態は、署名チェック状態を変更する専用の署名チェック状態切替ライセンス５３４を利用してのみ切り替えることを可能とする。また、この署名チェック状態５１１のオンオフの情報は、ＨＤＤ１０４に保持されている。

図６は、署名チェック状態切り替えライセンス５３４をインストールするフローチャートである。ＰＣ３００からライセンスインストールＵＩ（不図示）からバンドル管理サービス２１４に対して署名チェック状態切り替えライセンス５３４をインストールする。

Ｓ６００において、バンドル管理サービス２１４は、受信した署名チェック状態切り替えライセンス５３４のインストール処理を開始する。

Ｓ６０１において、受信した署名チェック状態切り替えライセンス５３４がオン指定であるかを判断する。オン指定である場合、Ｓ６０２に進む。オフ指定である場合、Ｓ６０３に進む。または、指定されたライセンスが不正な状態である場合、Ｓ６０４に進む。ここで、不正な状態とは、正しいフォオーマットでないなどの状態を指す。

Ｓ６０２において、コードチェック状態５１１をオンに設定する。Ｓ６０３において、コードチェック状態５１１をオフに設定する。Ｓ６０４において、署名チェック状態切り替えライセンス５３４のインストール処理を終了する。

図７（ａ）は、バンドルの内部構成について説明した図である。バンドルｊａｒファイル７００は、マニフェストファイル７０１やバンドルの実体であるクラスファイル７０３だけでなく、パーミッション定義ファイル７０２を保持している。このパーミッション定義ファイル７０２の例を図７（ｂ）に示す。ここに記載されたパーミッションが、バンドルｊａｒファイル７００が利用することができるパーミッションということになる。

図８は、禁止パーミッションリスト３０２の例を説明した図である。禁止パーミッションリスト３０２とは、バンドルがこれらのパーミッションを保持し、適宜プログラムを作成することで、例えば画像形成装置のシステムバンドルの情報を取得できる不正利用につながるパーミッション８０１の一覧である。これらをブラックリスト形式で列挙することで、バンドルが保持することを禁止するパーミッションであることを定義している。

図９は、画像形成装置にバンドルをインストールするときのインストール制御サービス２１３のフローチャートである。

Ｓ９００において、バンドル管理サービス２１４から指定されたバンドルを受信したインストール制御サービス２１３は、バンドルインストール処理を開始する。

Ｓ９０１において、指定されたバンドルが暗号化されているかを判断する。暗号化されている場合は、Ｓ９０２に進む。暗号化されていないと判断した場合は、Ｓ９０４に進む。ここで、暗号化されているのは市販のバンドル５０４の状態であり、暗号化されていないのは開発中のバンドル５０１の状態が想定される。

Ｓ９０２においては、暗号化されたバンドルの場合は、一緒に指定されたライセンスに付与されたバンドル復号の為の鍵を使用して、暗号化されたバンドルを復号化する。

Ｓ９０３において、バンドルの復号化に成功したかどうかを判断する。失敗した場合は、Ｓ９０７に進んでインストールの実行は失敗する。失敗する原因としては、バンドルとライセンスの組み合わせが正しくないことが想定される。Ｓ９０３において、バンドルの復号化が成功した場合は、Ｓ９０４に進む。Ｓ９０４において、デバイスの署名チェック状態を判断する。Ｓ９０４において、署名チェックオンの場合は、Ｓ９０５に進む。一方、署名チェックオフの場合は、Ｓ９０６に進む。

Ｓ９０５において、バンドルに付与されている署名５０３が正しいかどうかを判断する。Ｓ９０５において、正規の署名と判断された場合は、Ｓ９０６に進む。正規の署名と判断されなかった場合は、Ｓ９０７に進んでインストールの実行は失敗する。つまり、正規の署名が付与されているかどうかで、インストールの可否を判断する。Ｓ９０６において、図９で示すＯＳＧｉ拡張部２１１のインストール処理にバンドルを渡す。Ｓ９０８において、インストール制御サービス２１３のインストール処理が終了する。

図１０は、Ｓ９０６においてインストール制御サービス２１３からｊａｒを受信したバンドルインストール時のＯＳＧｉ拡張部２１１のフローチャートである。

Ｓ１０００において、ＯＳＧｉ拡張部２１１は、バンドルインストール処理を開始する。Ｓ１００１において、デバイスの署名チェック状態を判断する。Ｓ１００１において、署名チェックオンの場合は、Ｓ１００５に進む。一方、署名チェックオフの場合は、Ｓ１００２に進む。

Ｓ１００２において、インストールするｊａｒが、図３で示したように後入れのバンドルかどうかを判断する。ここで、後入れでないバンドルというのは、画像形成装置１３０に最初から同梱されているシステムバンドル群２１２である。Ｓ１００２において、後入れでないと判断された場合は、Ｓ１００５に進み、禁止パーミッションのチェックは省略する。これは、システムバンドル群２１２は、禁止パーミッションのような強いパーミッションを必要とする機能があるということと、同梱されているということで安全性は確保されているということから、省略可能とする。一方、後入れであると判断された場合は、Ｓ１００３に進む。Ｓ１００３において、バンドルがパーミッション定義ファイルを保持しているかを判断する。保持していない場合は、Ｓ１００５に進む。一方、保持している場合は、Ｓ１００４に進む。

Ｓ１００４において、バンドルが保持しているパーミッションが禁止パーミッションを含むかどうかを判断する。この判断方法については、図１１で示す。Ｓ１００４において、禁止パーミッションを判断していないと判断した場合は、Ｓ１００５に進む。一方、禁止パーミッションを保持していると判断した場合は、Ｓ１００６に進んでインストールの実行は失敗する。Ｓ１００５において、ｊａｒをインストール先フォルダにコピーし、バンドルのインストール実行を完了する。Ｓ１００７において、ＯＳＧｉ拡張部２１１のバンドルインストール処理が終了する。

図１１は、ＯＳＧｉ拡張部２１１が禁止パーミッション判定処理のフローチャートである。

Ｓ１１００において、バンドルが保持するパーミッションが禁止パーミッションに含まれるかの判定処理が開始される。

Ｓ１１０１において、バンドルが保持するパーミッション全てに対するチェックが開始される。そのため、バンドルが保持するパーミッション全てのパーミッションに対して次のチェックを行う。

Ｓ１１０２において、禁止パーミッションリスト３０２に記載されたパーミッション全てに対するループが開始される。

Ｓ１１０３において、禁止パーミッションリスト３０２に記載された最初のパーミッションと、バンドルが保持する最初のパーミッションが一致するかを判断する。この一致するかどうかの具体的な判断方法については、図１１で示す。一致したと判断した場合は、Ｓ１１０４に進み、禁止パーミッションを保持していると判定し、Ｓ１１０８において判定処理を終了する。この場合は、Ｓ１００４の判定結果として、ＹＥＳが返ることになる。一方、Ｓ１１０３において、一致していないと判断した場合は、Ｓ１１０５に進む。

Ｓ１１０５において、最後の禁止パーミッションかどうかを判定する。残っている場合は、Ｓ１１０３に戻り、引き続き次の禁止パーミッションとの判定処理を繰り返す。こうして、全ての禁止パーミッションのチェックが完了した後、Ｓ１１０６に進む。

Ｓ１１０６において、バンドルが保持する最後のパーミッションかどうかを判定し、残っている場合は、Ｓ１１０３に戻り、引き続きバンドルが保持する次のパーミッションで判定処理を繰り返す。こうして、全てのバンドルが保持するパーミッションのチェックが完了した後、Ｓ１１０７に進む。

Ｓ１１０７においては、禁止パーミッションを保持していないと判定し、Ｓ１１０８において判定処理を終了する。この場合は、Ｓ１００４の判定結果として、ＮＯが返ることになる。

図１２は、バンドルが保持するパーミッションが、禁止パーミッションに含まれるかどうかの判定方法について説明した図である。

例１として、禁止パーミッションが（１２００）の場合を説明する。この禁止パーミッション（１２００）は、パーミッションとしては、（ｊａｖａ．ｌａｎｇ．ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ）であり、ｎａｍｅとして、“ｌｏａｄＬｉｂｒａｒｙ．＊”が指定されている。ここで＊は、ワイルドカードを示している。

バンドルが保持するパーミッションが（ｊａｖａ．ｌａｎｇ．ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ“ｌｏａｄＬｉｂｒａｒｙ．ｘｘｘ．ｊａｒ”）（１２０１）であった場合、パーミッションとｎａｍｅが一致している。そのため、禁止パーミッションを保持していると判定される。一方、（ｊａｖａ．ｌａｎｇ．ＲｕｎｔｉｍｅＰｅｒｍｉｓｓｉｏｎ“ｃｒｅａｔｅＣｌａｓｓＬｏａｄｅｒ”）（１２０２）であった場合、パーミッションは一致しているが、ｎａｍｅは一致していないため、禁止パーミッションを保持していないと判定される。

例２として、禁止パーミッションが（１２０３）の場合を説明する。

この禁止パーミッション（１２０３）は、パーミッションとしては、（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＡｄｍｉｎＰｅｒｍｉｓｓｉｏｎ）であり、ｎａｍｅとして“＊”、ａｃｔｉｏｎとして“ｒｅｓｏｕｒｃｅ”が指定されている。ここで＊は、ワイルドカードを示している。

バンドルが保持するパーミッションが（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ．ＡｄｍｉｎＰｅｒｍｉｓｓｉｏｎ“ｘｘｘ”“ｒｅｓｏｕｒｃｅ”）（１２０４）であった場合、パーミッションとｎａｍｅ、ａｃｔｉｏｎ全てが一致している。そのため、禁止パーミッションを保持していると判定される。一方、（ｏｒｇ．ｏｓｇｉ．ｆｒａｍｅｗｏｒｋ，ＡｄｍｉｎＰｅｒｍｉｓｓｉｏｎ“＊”“ｍｅｔａｄａｔａ”）（１２０５）であった場合、パーミッションとｎａｍｅは一致しているが、ａｃｔｉｏｎは一致していな。そのため、禁止パーミッションを保持していないと判定される。

尚、図１１は、インストールしようとしているバンドルが、禁止パーミッションを保持するかを判定するためのフローチャートであるが、判定の仕方は一例である。つまり、図１１のフローチャート通りでなくてもよく、インストールしようとしているバンドルのパーミッション定義ファイルのパーミッションに、図８に記載の禁止パーミッションリストにあるパーミッションが含まれているか、いないかを判定すればよい。インストールしようとしているバンドルのパーミッション定義ファイルのパーミッションに、図８に記載の禁止パーミッションリストにあるパーミッションが含まれていない場合、禁止パーミッションが保持されていないと判定される。そして、禁止パーミッションが保持されていないと判定された場合に、インストールが実行される。

（実施形態１の変形例１）
変形例１では、実施形態１の図８で示したブラックリスト形式の禁止パーミッションではなく、ホワイトリスト形式の定義方法について述べる。

図１３は、ホワイトリスト形式の禁止パーミッションについて説明したブロック図である。１３００は、図８で示したブラックリスト形式の禁止パーミッション定義である。つまり、網掛けで示したここに記載されたパーミッションは、全て禁止パーミッションとなる。

一方、こうしたブラックリスト形式だと禁止パーミッションの指定が難しい（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ）の定義について説明する。

１３０１は、（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ）の禁止パーミッションを示している。ＦｉｌｅＰｅｒｍｉｓｓｉｏｎは、ｎａｍｅとして対象ファイルのパス、ａｃｔｉｏｎとして対象ファイルに対する操作の形式の指定となっている。

一部のＦｉｌｅＰｅｒｍｉｓｓｉｏｎを許容して、それ以外全てを禁止したいケースを考える。禁止したい対象ファイルのパスは無限にあるため、ブラックリスト形式では、禁止パーミッションの定義ができない。そこで、１３０２に示すように、許容したい対象ファイルを定義し、この許容した対象ファイル以外のＦｉｌｅＰｅｒｍｉｓｓｉｏｎを禁止パーミッションとした定義とする。このように、ＦｉｌｅＰｅｒｍｉｓｓｉｏｎは、ホワイトリスト形式の禁止パーミッション定義となる。

図１４は、ＯＳＧｉ拡張部がホワイトリスト形式で定義された禁止パーミッションの禁止パーミッション保持判定を行うときのフローチャートである。このフローチャートは、Ｓ１００４で示した禁止パーミッションが保持するかどうかの判定処理方法の一つであり、図１１で示したブラックリスト形式の禁止パーミッション保持判定処理に引き続いて行われると考えてよい。

Ｓ１４００において、バンドルが保持するパーミッションが、ホワイトリスト形式の禁止パーミッションに含まれるかの判定処理が開始される。

Ｓ１４０１において、バンドルが保持するパーミッション全てに対するチェックが開始される。そのため、バンドルが保持するパーミッション全てのパーミッションに対して次のチェックを行う。

Ｓ１４０２において、パーミッションがホワイトリスト形式で定義されたＦｉｌｅＰｅｒｍｉｓｓｉｏｎであるかどうかを判断する。ＦｉｌｅＰｅｒｍｉｓｓｉｏｎでない場合、Ｓ１４０８に進む。ＦｉｌｅＰｅｒｍｉｓｓｉｏｎである場合、Ｓ１４０３に進む。

Ｓ１４０３において、ホワイトリスト形式で定義された禁止パーミッションリスト１３０２に記載されたパーミッション全てに対するループが開始される。

Ｓ１４０４において、ホワイトリスト形式で定義された禁止パーミッションリスト１３０２に記載されたパーミッション全てと、バンドルが保持するＦｉｌｅＰｅｒｍｉｓｓｉｏｎが一致するかを判断する。この一致するかどうかの具体的な判断方法については、図１５で示す。一致したと判断した場合は、Ｓ１４０５に進み、Ｓ１４０５において、許容されたパーミッションを保持していると判定され、Ｓ１４０８に進む。

一方、Ｓ１４０４において、一致していないと判断した場合は、Ｓ１４０６に進む。

Ｓ１４０６において、最後のホワイトリスト形式で定義された禁止パーミッションリスト１３０２かどうかを判定する。残っている場合は、Ｓ１４０４に戻り、引き続き次のホワイトリスト形式で定義された禁止パーミッションとの判定処理を繰り返す。こうして、全ての禁止パーミッションのチェックが完了し、許容されたＦｉｌｅＰｅｒｍｉｓｓｉｏｎを持っていない場合は、Ｓ１４０７に進む。

Ｓ１４０７においては、禁止パーミッションを保持していると判定され、Ｓ１４１０において判定処理を終了する。この場合は、Ｓ１００４の判定結果として、ＹＥＳが返ることになる。

Ｓ１４０８において、バンドルが保持する最後のパーミッションかどうかを判定し、残っている場合は、Ｓ１４０２に戻り、引き続きバンドルが保持する次のパーミッションで判定処理を繰り返す。こうして、全てのバンドルが保持するパーミッションのチェックが完了した後、Ｓ１４０９に進む。

Ｓ１４０９においては、禁止パーミッションを保持していないと判定し、Ｓ１４１０において判定処理を終了する。この場合は、Ｓ１００４の判定結果として、ＮＯが返ることになる。

図１５は、バンドルが保持するパーミッションが、ホワイトリスト形式の禁止パーミッションに含まれるかどうかの判定方法について説明した図である。

例１として、禁止パーミッション（１５００）の場合を説明する。この禁止パーミッション（１５００）は、パーミッションとしては、（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ）である。ｎａｍｅとして、“／ｘｘｘ／ｙｙｙ／ｚｚｚ／－”、ａｃｔｉｏｎとして“ｒｅａｄ，ｗｒｉｔｅ，ｄｅｌｅｔｅ”が指定されている。ここで“－”は／ｘｘｘ／ｙｙｙ／ｚｚｚ／以下の全てのディレクトリ、ファイルを示している。

これに対して、バンドルが保持するパーミッションが（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ“＜＜ＡＬＬ ＦＩＬＥＳ＞＞”“ｒｅａｄ，ｗｒｉｔｅ，ｄｅｌｅｔｅ”）（１５０１）であった場合を考える。ここで、ｎａｍｅにおける＜＜ＡＬＬ ＦＩＬＥＳ＞＞は、全てのファイルが対象であることを意味する。そのため、許容されているファイルパス以外を含むとみなされ、禁止パーミッションを保持していると判定される。

また、バンドルが保持するパーミッションが（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ“／ｘｘｘ／ｙｙｙ／ｚｚｚ／－”“ｒｅａｄ，ｗｒｉｔｅ，ｄｅｌｅｔｅ，ｅｘｅｃｕｔｅ”）（１５０２）であった場合を考える。この場合、パーミッションとｎａｍｅは一致しているが、ａｃｔｉｏｎとしてｅｘｃｕｔｅは許容外とみなされて、禁止パーミッションを保持していると判定される。

バンドルが保持するパーミッションが（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ“／ｘｘｘ／ｙｙｙ／ｚｚｚ／ａａａ．ｌｏｇ”“ｗｒｉｔｅ”）（１５０３）であった場合、パーミッションとｎａｍｅ、ａｃｔｉｏｎ全てが許容範囲内とみなされる。そのため、禁止パーミッションを保持していないと判定される。

バンドルが保持するパーミッションが（ｊａｖａ．ｉｏ．ＦｉｌｅＰｅｒｍｉｓｓｉｏｎ“／ｘｘｘ／ｙｙｙ／ｚｚｚ／ｗｗｗ”“ｒｅａｄ，ｗｒｉｔｅ”）（１５０４）であった場合でも、パーミッションとｎａｍｅ、ａｃｔｉｏｎ全てが許容範囲内とみなされる。そのため、禁止パーミッションを保持していないと判定される。

尚、図１４は、インストールしようとしているバンドルが、禁止パーミッションを保持するかを判定するためのフローチャートであるが、判定の仕方は一例である。つまり、図１４のフローチャート通りでなくてもよく、インストールしようとしているバンドルのパーミッション定義ファイルのパーミッションに、図１３に記載の禁止パーミッションリストにあるパーミッションが含まれているか、いないかを判定すればよい。そして、禁止パーミッションが保持されていないと判定された場合に、インストールが実行される。

以上、説明した実施形態で示した方法により、具体的には以下に示すような効果を得ることができる。

（実施形態１の変形例２）
変形例２では、実施形態１の図８の８０１で示したブラックリスト形式と実施形態１の変形例１の図１３の１３０１で示したホワイトリスト形式の両方を合わせもつ禁止パーミッションの判定処理について述べる。

図１６は、ＯＳＧｉ拡張部２１１による、ブラックリスト形式とホワイトリスト形式の両方を合わせもつ禁止パーミッション判定処理のフローチャートである。

この判定処理は、インストール全体のフローを示す図１０のＳ１００４の判断に相当する。

Ｓ１６００において、バンドルが保持するパーミッションが禁止パーミッションに含まれるかの判定処理が開始される。

Ｓ１６０１において、バンドルが保持するパーミッション全てに対するブラックリスト形式の禁止パーミッションチェックが開始される。このフローの詳細は、図１１で示したとおりである。図１１のＳ１１０４で禁止パーミッション保持している判定をした場合、一致が返ってくるため、Ｓ１６０４に進む。一方、図１１のＳ１１０７で禁止パーミッション保持していない判定をした場合、一致しないが返ってくるため、Ｓ１６０２に進む。

続いて、Ｓ１６０２において、バンドルが保持するパーミッション全てに対するホワイトクリスト形式の禁止パーミッションチェックが開始される。このフローの詳細は、図１４で示したとおりである。図１４のＳ１４０７で禁止パーミッション保持している判定の場合、一致が返ってくるため、Ｓ１６０４に進む。一方、図１４のＳ１４０９で禁止パーミッション保持していない判定の場合、一致しないが返ってくるため、Ｓ１６０３に進む。

Ｓ１６０３においては、ブラックリスト形式、ホワイト形式ともに、禁止パーミッションを保持していない判定となり、Ｓ１００４に対して、ＮＯが返却される。

一方、Ｓ１６０４においては、ブラックリスト形式、または、ホワイト形式のどちらかで禁止パーミッションを保持している判定となり、Ｓ１００４に対して、ＹＥＳが返却される。

Ｓ１６０５において、ブラックリスト形式とホワイトリスト形式の両方を合わせもつ禁止パーミッション判定処理のフローが終了する。

バンドルの作成方法をソフトウェア開発キット（ＳＤＫ）として公開することで、画像形成装置を開発している自社だけでなく、外部のソフトウェアベンダー（以下、３ｒｄベンダー）が画像形成装置のカスタマイズした機能を開発することができる。カスタマイズしたバンドルを開発することができるということは、画像形成装置に悪影響のあるバンドルが開発できる可能性がある。

デバイスの署名チェック状態からバンドルの開発中という判断を行った場合、予め悪影響を及ぼす可能性のあるパーミッションとして定義した禁止パーミッションを保持するバンドルのインストールを不許可とする。そのため、結果として、ＳＤＫビジネスにおける画像形成装置の安全性が担保される。

以上、説明した実施形態によれば、開発中においても画像形成装置内の情報を抜く可能性があるパーミッションをもつアプリをインストールすることができなくなり、画像形成装置の安全性が担保される。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (14)

1. アプリケーションのインストール時に、署名をチェックする設定になっているかを判定する第１の判定手段と、
   前記第１の判定手段で、署名をチェックする設定になっていない場合、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないかを判定する第２の判定手段と、
   前記第２の判定手段で、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないと判定された場合、前記アプリケーションのインストールを許可する手段を有することを特徴とする画像形成装置。
2. アプリケーションのインストール時に、署名をチェックする設定に関する情報を保持する保持手段を有することを特徴とする請求項１に記載の画像形成装置。
3. 前記第２の判定手段で、アプリケーションに含まれるパーミッションが、禁止されたパーミッションであると判定された場合、前記アプリケーションのインストールを許可しないことを特徴とする請求項１又は請求項２に記載の画像形成装置。
4. 前記アプリケーションは、パーミッションを定義するファイルを含むことを特徴とする請求項１乃至３の何れか１項に記載の画像形成装置。
5. 前記第１の判定手段で、署名をチェックする設定になっている場合、アプリケーションに含まれる署名を用いて、前記アプリケーションのインストールの可否を判断することを特徴とする請求項１乃至４の何れか１項に記載の画像形成装置。
6. 前記第１の判定手段で、署名をチェックする設定になっている場合、アプリケーションに含まれるパーミッションは用いず、アプリケーションに含まれる署名を用いて、前記アプリケーションのインストールの可否を判断することを特徴とする請求項５に記載の画像形成装置。
7. 前記署名はデジタル署名であることを特徴とする請求項１乃至６のいずれか一項に記載の画像形成装置。
8. 画像形成装置の制御方法であって、
   前記画像形成装置が、アプリケーションのインストール時に、署名をチェックする設定になっているかを判定する第１の判定工程と、
   前記画像形成装置が、前記第１の判定工程で、署名をチェックする設定になっていない場合、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないかを判定する第２の判定工程と、
   前記画像形成装置が、前記第２の判定工程で、アプリケーションに含まれるパーミッションが、禁止されたパーミッションでないと判定された場合、前記アプリケーションのインストールを許可する工程を有することを特徴とする画像形成装置の制御方法。
9. 前記第２の判定工程で、アプリケーションに含まれるパーミッションが、禁止されたパーミッションであると判定された場合、前記アプリケーションのインストールを許可しないことを特徴とする請求項８に記載の画像形成装置の制御方法。
10. 前記アプリケーションは、パーミッションを定義するファイルを含むことを特徴とする請求項８又は請求項９に記載の画像形成装置の制御方法。
11. 前記第１の判定工程で、署名をチェックする設定になっている場合、アプリケーションに含まれる署名を用いて、前記アプリケーションのインストールの可否を判断することを特徴とする請求項８乃至１０の何れか１項に記載の画像形成装置の制御方法。
12. 前記第１の判定工程で、署名をチェックする設定になっている場合、アプリケーションに含まれるパーミッションは用いず、アプリケーションに含まれる署名を用いて、前記アプリケーションのインストールの可否を判断することを特徴とする請求項１１に記載の画像形成装置の制御方法。
13. 前記署名はデジタル署名であることを特徴とする請求項８乃至１２のいずれか一項に記載の画像形成装置の制御方法。
14. 請求項１乃至７の何れか１項に記載の画像形成装置としてコンピュータを機能させるための該コンピュータで読み取り可能なプログラム。

Images