JP7313232B2

JP7313232B2 - 情報処理装置及びその制御方法、並びにプログラム

Info

Publication number: JP7313232B2
Application number: JP2019153190A
Authority: JP
Inventors: 直基土樋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-08-23
Filing date: 2019-08-23
Publication date: 2023-07-24
Anticipated expiration: 2039-08-23
Also published as: JP2021033645A

Description

本発明は、情報処理装置及びその制御方法、並びにプログラムに関する。

ネットワークで接続した機器間の通信において、セキュリティを確保するために通信経路の暗号化が必須の技術となっている。暗号化通信の目的としては通信経路の暗号化による盗聴対策の他に、メッセージ認証による通信経路の改ざん対策、そして証明書検証による通信相手のなりすまし対策が挙げられる。

証明書検証においては、通信相手が送信してきたデジタル証明書（以下、証明書と呼ぶ）が権威のあるＣＡ（ＣｅｒｔｉｆｉｃａｔｅＡｕｔｈｏｒｉｔｙ）局によってデジタル署名されているか否かを検証する。そして、検証結果が正しいと確認された場合には証明書に記載された情報を信用することが可能となる。検証の手続きは非特許文献１等の標準規格によって定義されている。

ここで用いられるルートＣＡ証明書は通常、情報処理装置の出荷状態において、メーカーによって予めインストールされて出荷される。しかし、利用者が個別に接続するサーバー機器においても検証可能とするために、利用者が自由に追加できるように構成されている情報処理装置が存在する。この場合、ネットワークインターフェースあるいはＵＳＢなどのローカルインターフェースを介して管理者が入手したルートＣＡ証明書をインストールする。

クラウドなどのインターネットで実施されるサービスの中には、情報処理装置の全てのソフトウェアや有償のソフトウェアライセンス情報など、利用者によって改ざんされてはならないベンダー資産を扱うものがある。ベンダー資産の不正な暴露や改ざんを防ぐために、サーバー証明書の検証を用いて信頼のあるサーバーとの通信であることを確認している。

ＲＦＣ５２８０、［ｏｎｌｉｎｅ］、［令和１年８月８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５２８０＞

上記のようにベンダー資産を扱う暗号化通信においては、サーバー側から提供されるサーバー証明書の検証を行うことにより、信頼のあるサーバーとの通信であることを保証している。一方、サーバー証明書の検証に用いるルートＣＡ証明書は、利用者によって追加のインストールが可能であるが、追加インストールがベンダー資産を扱うサーバーとの信頼関係に影響を与えるべきではない。

本発明は、利用者のルートＣＡ証明書の追加インストールなどによる不正なベンダー資産の暴露や改ざんに起因した不正な外部サーバーへの通信を防ぐことを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、１または複数のアプリケーションが動作可能な情報処理装置であって、外部サーバーとの暗号化通信を行う際に用いられるルート証明書を管理する管理手段と、アプリケーションから前記外部サーバーとの暗号化通信の要求を受け付けた際に、当該アプリケーションが、前記情報処理装置における所定の情報を利用するか否かを判定する判定手段と、前記判定手段にて前記アプリケーションが前記所定の情報を利用すると判定された場合、前記管理手段にて管理されているルート証明書のうち、所定の属性情報が設定されたルート証明書を用いて、前記外部サーバーのサーバー証明書を検証する検証手段とを有する。

本発明によれば、暗号化通信を行う際に外部サーバーを正しく検証することが可能となり、ベンダー資産を安全にやり取りすることが可能となる。

本発明の一実施形態に係る情報処理システムの構成例を示す概略図。本実施形態に係るＭＦＰ内にて動作するソフトウェアの構成例を示す図。第１の実施形態に係るデジタル証明書検証部の処理のフローチャート。本実施形態に係る外部アプリケーションの構成と属性情報を説明するための図。本実施形態に係る暗号通信部の処理のフローチャート。本実施形態に係る鍵管理部の構成と外部との関連を示す図。第２の実施形態に係るデジタル証明書検証部の処理のフローチャート。第３の実施形態に係る鍵管理部のエクスポート処理のフローチャート。第３の実施形態に係る鍵管理部のインポート処理のフローチャート。

＜第１の実施形態＞
以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

［システム構成］
図１は、本発明の一実施形態に係る情報処理システムの構成例を示す概略図である。情報処理システムは、ＭＦＰ（Ｍｕｌｔｉ－ＦｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）１１０、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）１２０、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）１３０、インターネット１５０、およびクラウドサーバー１４０を含んで構成される。インターネット１５０とＬＡＮ１２０はルーター１６０によって通信可能に接続されている。図１において、各装置は１台ずつが示されているが、更に多くの装置が含まれてもよい。また、本実施形態では、ＭＦＰを例に挙げて説明するが、これに限定するものではなく、後述するようなベンダー資産に相当する各種情報を扱う機器であれば、本願発明は適用可能である。

ＭＦＰ１１０は、ネットワーク通信部１１１、操作部１１３、ＣＰＵ１１４、ＲＡＭ１１５、および記憶装置１１６を含んで構成される。ＭＦＰ１１０は、上記構成の他、プリンタ部やスキャナ部など、機能に応じて他の部位を備えてよい。ＭＦＰ１１０は、クラウドサーバー１４０と接続することにより、インターネット１５０を介した各種サービス（Ｗｅｂサービス等）を利用することができる。クラウドサーバー１４０は、ＭＦＰ１１０に各種サービスを提供する外部サーバーである。本実施形態において、クラウドサーバー１４０は、上述するベンダー資産の情報をＭＦＰ１１０から収集することも可能である。また、ＭＦＰ１１０は、ＰＣ１３０からの指示に基づき、ＬＡＮ１２０を介してＭＦＰ１１０の設定やアプリケーションのインストールを行うことが可能である。また、ＭＦＰ１１０は、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）などの外付けの記憶装置を接続可能であってもよい。

［ソフトウェア構成］
図２は、ＭＦＰ１１０内にて動作するソフトウェアの構成例を示す。本実施形態において、ＭＦＰ１１０において、複数のアプリケーションが動作可能であり、ここでは、組み込みアプリケーション２０１と外部アプリケーション２０７の２つを例に挙げて説明する。組み込みアプリケーション２０１は、ＭＦＰ１１０の中で動作するアプリケーションのうち、ＭＦＰ１１０に最初（例えば、装置出荷時）から組み込まれているアプリケーションである。暗号通信部２０２は、アプリケーションから呼び出されて、外部装置であるＰＣ１３０やクラウドサーバー１４０と暗号化通信を行う。設定記憶部２０３は、ＭＦＰ１１０の設定を記憶装置１１６などの記憶領域に記憶する。デジタル証明書検証部２０４は、暗号通信部２０２から呼び出され、サーバーなどから提供される証明書の検証を行う。鍵管理部２０５は、デジタル証明書検証部２０４によりサーバー証明書の検証に用いられるルートＣＡ証明書（ルート証明書とも称する）を管理する。

証明書インストール部２０６は、利用者の指定したルート証明書を鍵管理部２０５に管理させる。外部アプリケーション２０７は、組み込みアプリケーション２０１とは異なり、ＭＦＰ１１０の出荷後に外部から任意のタイミングにてインストールされ、ＭＦＰ１１０のアプリケーションとして動作するアプリケーションである。外部アプリケーションインストール部２０８は、利用者の指示に従い、外部アプリケーション２０７のインストールを行う。外部アプリケーション管理部２０９は、外部アプリケーション２０７がインストールされたことに応じて、外部アプリケーション２０７の情報を管理する。ソフトウェアアップデート部２１０は、ＭＦＰ１１０が動作するソフトウェア全体とルートＣＡ証明書などのベンダーが配布するデータを取得し、更新を行う。

上記ソフトウェアは記憶装置１１６に永続的に格納され、利用する際にはＲＡＭ１１５にロードされてからＣＰＵ１１４によって実行される。また、設定記憶部２０３が格納する設定情報や、鍵管理部２０５が保存するルートＣＡ証明書は、記憶装置１１６によって永続的に記憶され、それぞれのソフトウェアで利用されるときにＲＡＭ１１５にロードされて利用される。

組み込みアプリケーション２０１、外部アプリケーション２０７、外部アプリケーション２０８、証明書インストール部２０６、および設定記憶部２０３に設定を行う際の操作は、操作部１１３を利用者が操作することによって実施される。

デジタル証明書検証部２０４による証明書の検証は、サーバーに接続した際にサーバーから送られるサーバー証明書を、ＭＦＰ１１０が保持しているルートＣＡ証明書を用いて行われる。サーバー証明書の検証方式についてはＲＳＡ署名検証やＥＣＤＳＡ署名検証などの既知の方式を用いるものとし、ここでの詳細の説明は割愛する。

［ベンダー資産利用］
次にアプリケーションのベンダー資産利用について説明する。ここでいうベンダー資産とは、ＭＦＰ１１０を提供するベンダーによって、ＭＦＰ１１０に関するサービスのために扱われる所定の情報であり、利用者には開示されない情報である。ベンダー資産としては、例えば、ＭＦＰ１１０を動作させるファームウェアの利用情報、ＭＦＰ１１０のプリンタ利用枚数などの課金情報などが含まれる。なお、各アプリケーションがベンダー資産として扱う情報は特に限定するものではなく、例えば、ＭＦＰ１１０が出力可能なベンダー資産のうち、アプリケーションごと利用するベンダー資産の種類を定義してよい。

利用者に開示されない理由として、様々なものが挙げられる。例えば、図２に示すような複数のソフトウェアの正常動作を脅かすような不正な改変からシステムを保護するためや、機器のメンテナンスや課金情報への改ざんによりサービス不能や不正な課金回避を引き起こすような攻撃を未然に防ぐためである。これらの情報を扱うアプリケーションは、暗号通信の際にサーバーのなりすましが起こりえないように証明書の検証に用いるルートＣＡ証明書の厳格化を指示することができる。

アプリケーションがベンダー資産を扱うことを宣言する方法には２種類ある。ひとつは、アプリケーションが暗号通信部２０２を呼び出す際に、引数として当該アプリケーションがベンダー資産を扱うことを示す属性を渡すことである。図２において組み込みアプリケーション２０１は、暗号通信部２０２に対し、ベンダー属性として「ベンダー資産利用属性」の情報を渡す。これは組み込みアプリケーション２０１がベンダー資産を利用することを示している。組み込みアプリケーション２０１の場合には、予めベンダーがベンダー資産を扱うか否かを判定できるため、このように直接指定することが組み込みアプリケーション２０１には許可されている。

アプリケーションがベンダー資産を扱うことを宣言するもうひとつの方法として、インストール時に、属性ファイルにベンダー資産利用属性情報を記載することにより、宣言を行うことが可能である。例えば、ＭＦＰ１１０の出荷後にインストールされる外部アプリケーション２０７の場合、アプリケーションそのものからの指定がない場合でも、アプリのベンダー属性を定義した属性ファイルにベンダー資産利用属性情報を記載することにより宣言することができる。なお、本実施形態では、外部アプリケーション２０７はベンダー資産を扱うか否かを直接指定しないものとして説明するが、この構成に限定するものではない。

図４は、外部アプリケーション２０７の構成と、属性情報を説明するための図である。外部アプリケーション２０７は、実体の構成としては、アプリケーションパッケージファイル４０１のデータ構造を持っており、アプリケーションデータ４０２とアプリケーション属性ファイル４０３を含んで構成される。アプリケーションデータ４０２は、ＣＰＵ１１４によって動作可能なソフトウェアコードの実体を示す。アプリケーション属性ファイル４０３は、当該アプリケーションの属性が記載されたテキスト形式あるいはＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）形式のデータである。

データ４０４は、アプリケーション属性ファイル４０３の内部構成の一例を模式的に示したものである。データ４０４において、Ａｐｐｌｉｃａｔｉｏｎ－Ｎａｍｅはアプリケーションの名称を示し、“Ｓａｍｐｌｅ”が設定されている。Ａｐｐｌｉｃａｔｉｏｎ－ＩＤは、アプリケーションに付与された固有のＩＤ（識別情報）を示し、“ａｂｃ”が設定されている。ＩＤを固有に割り振るのはＭＦＰ１１０のベンダーの責務である。Ａｐｐｌｉｃａｔｉｏｎ－Ｔｙｐｅはアプリケーションの種別を示す。アプリケーションの種別の例として、操作部１１３を用いるものをアプレット（“ａｐｐｌｅｔ”）、ネットワークのサーバーとして機能するものをサーブレット（“ｓｅｒｖｌｅｔ”）が挙げられる。Ｖｅｎｄｅｒ－Ａｓｓｅｔｓは当該アプリケーションがベンダー資産を扱うか否かを示すベンダー資産利用属性である。“Ｔｒｕｅ”が設定されている場合はアプリケーションがベンダー資産を扱い、“Ｆａｌｓｅ”が設定されている場合は扱わないことを示す。

このような構成を持った外部アプリケーション２０７は、外部アプリケーションインストール部２０８を用いてネットワーク経由あるいはＵＳＢメモリなどの記憶媒体からＭＦＰ１１０内の外部アプリケーション管理部２０９にインストールされる。ここでの外部アプリケーション２０７に対応するアプリケーションパッケージファイルの提供方法は、特に限定するものではない。

外部アプリケーション管理部２０９は、インストールされたアプリケーションに関する情報を格納するデータベース４０５を有する。データベース４０５には、インストールされたアプリケーションのアプリケーション属性ファイル４０３にて示される各属性をキーとした値が格納される。具体的には、データ４０４に示したＡｐｐｌｉｃａｔｉｏｎ－Ｎａｍｅ、Ａｐｐｌｉｃａｔｉｏｎ－ＩＤ、Ａｐｐｌｉｃａｔｉｏｎ－Ｔｙｐｅ、Ｖｅｎｄｅｒ－Ａｓｓｅｔｓの値が管理される。例えば、アプリケーションパッケージファイル４０１に関わる情報は、レコード４０６に対応し、アプリケーション属性ファイル４０３に記載された内容がデータベース４０５に格納される。上述したように、Ｖｅｎｄｅｒ－Ａｓｓｅｔｓに記載された情報が“Ｔｒｕｅ”の場合には、当該アプリケーションがベンダー資産を扱うことを示すことが可能となる。なお、データ４０４に示した属性は一例であり、他の属性値が更に記載されてよい。また、これに応じて、外部アプリケーション管理部２０９のデータベース４０５にて管理される情報が増加してよい。

［鍵管理部］
次に、本実施形態に係る鍵管理部２０５について説明する。図６は、鍵管理部２０５の構成と外部との関連を説明するための図である。鍵管理部２０５は、ＭＦＰ１１０の動作開始とともに起動され、以降、ＭＦＰ１１０の電源遮断まで動作が継続する。鍵管理部２０５は、デジタル証明書検証部２０４による検証処理が行われる際に用いられるルートＣＡ証明書を記憶装置１１６上にて管理し、要求に応じてルートＣＡ証明書を渡す。

管理テーブル６０４は、鍵管理部２０５が管理するルートＣＡ証明書の管理テーブルであり、記憶装置１１６上に構成される。データベース６０８は、管理テーブル６０４で格納されている情報の一例を示す。列６０９は、記憶装置１１６に格納されているルートＣＡ証明書の実ファイル名を示す。列６１０は、操作部１１３に表示する際に用いられる証明書名を示す。列６１１は、ルートＣＡ証明書に対して設定されたベンダー属性を示す。

ルートＣＡ証明書６０５～６０７は、記憶装置１１６に保持されているルートＣＡ証明書の実体ファイルを示す。各ルートＣＡ証明書に対して示された“ｒｏｏｔｃａ１．ｃｅｒ”～“ｒｏｏｔｃａ３．ｃｅｒ”は、ルートＣＡ証明書の実体のファイル名を示し、データベース６０８の列６０９に対応する。ルートＣＡ証明書は鍵管理部２０５に対して登録手続きが行われた場合、管理テーブル６０４に当該ルートＣＡ証明書のファイル名、および証明書名称をそれぞれ列６０９、６１０に記録される。更に、各ルートＣＡ証明書に対し、登録を行うモジュールに応じて「ベンダー属性あり」、または、「ベンダー属性なし」の設定が列６１１に記録される。

本実施形態に係るベンダー属性について説明する。証明書インストール部２０６は、利用者がルートＣＡ証明書を登録する際に用いられるモジュールである。このようなモジュールを用いてインストールされるルートＣＡ証明書は任意のものが許されているため、ベンダー資産にアクセスするサーバーのサーバー証明書の検証に使えるとなりすましによる不正アクセスのリスクがある。そのため、本実施形態では、証明書インストール部２０６によりインストールされるルートＣＡ証明書に対しては、「ベンダー属性なし」としてデータベース６０８に登録する。

一方、ソフトウェアアップデート部２１０は、ベンダーが提供するソフトウェア全体を更新するために利用される。ここで更新されるソフトウェアは例えば、ＭＦＰのファームウェアなどが該当し、これらは全て、ベンダー由来であることが保証される。配信されるソフトウェアの一部にルートＣＡ証明書が含まれる場合があり、これはベンダーが提供する証明書であり、信頼できるものである。そのため、このようなルートＣＡ証明書は、ベンダー資産にアクセスするサーバーのサーバー証明書の検証に使うことが可能である。したがって、本実施形態では、ソフトウェアアップデート部２１０によりインストールされるルートＣＡ証明書に対しては、「ベンダー属性あり」としてデータベース６０８に登録する。なお、「ベンダー属性あり」として設定されるルートＣＡ証明書は上記に限定されるものではなく、ベンダー由来のものであるとして保証される場合には、他の方法にてインストールされたルートＣＡ証明書にも設定してよい。例えば、サービスマンなど特定の権限を有する利用者がインストールした場合や、特定のサービスツールを介してインストールした場合などが挙げられる。また、ＭＦＰ１１０の出荷時に予めインストールされたルートＣＡ証明書については、「ベンダー属性あり」として設定してよい。

［暗号通信部］
次に、本実施形態に係る暗号通信部２０２の動作を説明する。暗号通信部２０２は、組み込みアプリケーション２０１または外部アプリケーション２０７から呼び出され、標準規格に従って暗号通信を行うモジュールである。暗号通信の標準規格としては、ＯＳＩ（ＯｐｅｎＳｙｓｔｅｍＩｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）の７階層におけるトランスポート層あるいはアプリケーション層で暗号化を行うＳＳＬ／ＴＬＳ（ＳｅｃｕｒｅＳｏｃｋｅｔＬａｙｅｒ／ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）やネットワーク層で暗号化を行うＩＰＳｅｃが挙げられるが、これらの標準規格以外でも適用可能である。

図５は、本実施形態に係る暗号通信部２０２の処理のフローチャートである。暗号通信部２０２は、組み込みアプリケーション２０１または外部アプリケーション２０７から暗号通信の要求があった際に起動され、暗号通信が完了したら動作を終了する。また、複数の暗号通信が同時に要求された場合は、複数の暗号通信部がそれぞれ独立に動作を行う。

Ｓ５０１にて、暗号通信部２０２は、アプリケーションからの暗号通信の要求を受け付ける。暗号通信が開始する際にはアプリケーションからアプリケーションＩＤ、およびベンダー資産属性が渡される。ただし、上述したように、ベンダー資産属性については、アプリケーションが外部アプリケーション２０７である場合には渡されないため、必須の情報ではない。

Ｓ５０２にて、暗号通信部２０２は、アプリケーションがクライアント側かサーバー側かの判定を行う。つまり、アプリケーションがサーバーとして動作するか、クライアントとして動作するかの判定が行われる。これはアプリケーション側からの暗号通信要求を行う際にパラメーターとして渡される値から判定してよい。クライアント側であると判定した場合（Ｓ５０２ににてＹＥＳ）Ｓ５０３へ進み、サーバー側であると判定した場合（Ｓ５０２にてＮＯ）Ｓ５０８へ進む。

Ｓ５０３にて、暗号通信部２０２は、対向（通信相手）となるサーバーに対してサーバー証明書を要求する。そして、その応答として、暗号通信部２０２は、サーバー証明書を受信する。

Ｓ５０４にて、暗号通信部２０２は、Ｓ５０３にてサーバーから受信したサーバー証明書の検証を、デジタル証明書検証部２０４に要求する。この際、暗号通信部２０２は、Ｓ５０３にて取得したサーバー証明書と共に、Ｓ５０１にてアプリケーションから渡されるアプリケーションＩＤおよびアプリケーションのベンダー資産属性をデジタル証明書検証部２０４に渡す。ここでのデジタル証明書検証部２０４による検証処理については、図３を用いて後述する。その後、暗号通信部２０２は、デジタル証明書検証部２０４からサーバー証明書の検証結果を取得する。

Ｓ５０５にて、暗号通信部２０２は、デジタル証明書検証部２０４による検証が成功したか否かを判定する。検証が成功した場合（Ｓ５０５にてＹＥＳ）Ｓ５０６へ進み、検証が失敗した場合（Ｓ５０５にてＮＯ）Ｓ５０７へ進む。

Ｓ５０６にて、暗号通信部２０２は、Ｓ５０１にて受信した暗号通信の要求に対応するサーバーとの通信を完了するまで継続する。その後、本処理フローを終了する。

Ｓ５０７にて、暗号通信部２０２は、Ｓ５０１にて受信した暗号通信の要求に対応するサーバーとの接続を遮断する。そして、本処理フローを終了する。

Ｓ５０８にて、暗号通信部２０２は、サーバー証明書をクライアントに送信する。この場合、アプリケーションがサーバーとして動作するため、サーバー証明書の検証は不要となる。その後、Ｓ５０６へ進み、暗号通信部２０２は、Ｓ５０１にて受信した暗号通信の要求に対応する通信の完了までクライアントとの通信を継続する。そして、本処理フローを終了する。

［サーバー証明書の検証処理］
次に、本実施形態に係るデジタル証明書検証部２０４によるサーバー証明書の検証処理について説明する。図３は、デジタル証明書検証部２０４の動作を説明するフローチャートである。デジタル証明書検証部２０４は、暗号通信部２０２から呼び出されることにより動作を開始し、処理が完了すると動作を停止する。ここでの開始タイミングは、図５のＳ５０４における要求を暗号通信部２０２から受信したタイミングに対応する。

Ｓ３０１にて、デジタル証明書検証部２０４は、暗号通信部２０２から検証対象となるサーバー証明書を受け取る。併せて、アプリケーションＩＤが取得される。

Ｓ３０２にて、デジタル証明書検証部２０４は、Ｓ３０１にてアプリケーションからベンダー資産属性が利用ありの指示を受け付けたか否かを判定する。上述したように、アプリケーションが組み込みアプリケーション２０１である場合には、ベンダー資産属性によるベンダー資産属性の利用のあり／なしの指示を直接行うことができる。一方、アプリケーションが外部アプリケーション２０７である場合には、ベンダー資産属性が利用ありの指示は行われない。一方、指示があると判定された場合（Ｓ３０２にてＹＥＳ）Ｓ３０５へ進み、指示がないと判定された場合（Ｓ３０２にてＮＯ）Ｓ３０３へ進む。

Ｓ３０３にて、デジタル証明書検証部２０４は、Ｓ３０１にて取得したアプリケーションのアプリケーションＩＤに基づいて、外部アプリケーション管理部２０９のデータベース４０５を参照し、ベンダー資産属性（Ｖｅｎｄｅｒ－Ａｓｓｅｔｓ情報）を確認する。

Ｓ３０４にて、デジタル証明書検証部２０４は、Ｓ３０３にて参照したベンダー資産属性の値が“Ｔｒｕｅ”か否かを判定する。上述したように、“Ｔｒｕｅ”である場合には、当該外部アプリケーションがベンダー資産を扱うことを示す。ベンダー資産属性の値が“Ｔｒｕｅ”であると判定された場合（Ｓ３０４にてＹＥＳ）Ｓ３０５へ進み、“Ｆａｌｓｅ”であると判定された場合（Ｓ３０４にてＮＯ）Ｓ３０６へ進む。なお、ベンダー資産属性の値が“Ｆａｌｓｅ”である場合には、記憶装置１１６に保持されているすべてのルートＣＡ証明書が検索対象となる。

Ｓ３０５にて、デジタル証明書検証部２０４は、検証対象となるルートＣＡ証明書からベンダー属性がないものを、一時的に除外する。つまり、管理テーブル６０４のデータベース６０８に含まれるルートＣＡ証明書のうち、列６１１の値が「ベンダー属性なし」の値を有するルートＣＡ証明書を除外する。図６の例の場合、ルートＣＡ証明書６０７（“ｒｏｏｔｃａ３．ｃｅｒ”）が除外される。

Ｓ３０６にて、デジタル証明書検証部２０４は、検索対象となるルートＣＡ証明書から、サーバー証明書を検証できるルートＣＡ証明書を検索する。

Ｓ３０７にて、デジタル証明書検証部２０４は、Ｓ３０６の検索結果により、サーバー証明書を検証できるルートＣＡ証明書が存在するか否かを判定する。ルートＣＡ証明書が存在すると判定された場合（Ｓ３０７にてＹＥＳ）Ｓ３０８へ進み、存在しない場合はＳ３１０へ進む。

Ｓ３０８にて、デジタル証明書検証部２０４は、サーバー証明書を、Ｓ３０６にて検索されたルートＣＡ証明書を用いて検証を行う。サーバー証明書の検証方式についてはＲＳＡ署名検証やＥＣＤＳＡ署名検証などの一般的に使われている既知の方式を用いるものとし、詳細の説明は割愛する。

Ｓ３０９にて、デジタル証明書検証部２０４は、Ｓ３０８における検証が成功したか否かを判定する。検証が成功した場合（Ｓ３０９にてＹＥＳ）Ｓ３１１へ進み、検証が失敗した場合（Ｓ３０９にてＮＯ）Ｓ３１０へ進む。

Ｓ３１０にて、デジタル証明書検証部２０４は、サーバー証明書の検証に失敗した旨を暗号通信部２０２へ返す。そして、本処理フローを終了する。

Ｓ３１１にて、デジタル証明書検証部２０４は、サーバー証明書の検証に成功した旨を暗号通信部２０２へ返す。そして、本処理フローを終了する。

以上、本実施形態では、アプリケーションがベンダー資産を扱う場合には検証対象となるルートＣＡ証明書を用いる際に信頼のあるモジュールからインストールされたルートＣＡ証明書だけを使う。これにより、ベンダー資産を安全にやり取りすることが可能となる。

＜第２の実施形態＞
ＭＦＰ１１０によってはサーバー証明書の検証を実施するか／しないかの検証設定を設定記憶部２０３に持つものがある。そこで、本願発明の第２の実施形態として、そのような構成を有する場合の形態について説明する。なお、第１の実施形態と重複する箇所については説明を省略し、差分を説明する。

［デジタル証明書検証部］
図７は、本実施形態に係るデジタル証明書検証部２０４の動作を説明するフローチャートである。第１の実施形態にて述べた図３の処理と同じ処理については、同じ参照番号を付し、差分のみを説明する。

Ｓ３０３の処理の後、Ｓ７０１にて、デジタル証明書検証部２０４は、Ｓ３０３にて参照したベンダー資産属性の値が“Ｔｒｕｅ”か否かを判定する。上述したように、“Ｔｒｕｅ”である場合には、当該外部アプリケーションがベンダー資産を扱うことを示す。ベンダー資産属性の値が“Ｔｒｕｅ”であると判定された場合（Ｓ７０１にてＹＥＳ）Ｓ３０５へ進み、“Ｆａｌｓｅ”であると判定された場合（Ｓ７０１にてＮＯ）Ｓ７０２へ進む。

Ｓ７０２にて、デジタル証明書検証部２０４は、設定記憶部２０３からサーバー証明書の検証設定を取得する。

Ｓ７０３にて、デジタル証明書検証部２０４は、Ｓ７０２にて取得した検証設定が“ＯＮ”か否かを判定する。検証設定が“ＯＮ”である場合とは、サーバー証明書の検証を行うことを意味する。“ＯＮ”である場合（Ｓ７０３にてＹＥＳ）Ｓ３０６へ進み、“ＯＦＦ”である場合（Ｓ７０３にてＮＯ）Ｓ３１１へ進む。

以上、本実施形態では、ベンダー資産を扱うアプリケーションは信頼のあるルートＣＡ証明書を用いた検証を行えるようにするとともに、ベンダー資産を扱わないアプリケーションでは証明書の検証設定に応じて任意に証明書の検証の実施を制御する。これにより、サーバー証明書の検証に係る可用性を維持することが可能となる。

＜第３の実施形態＞
以下、本願発明の第３の実施形態について説明する。なお、第１、第２の実施形態と重複する箇所については説明を省略し、差分を説明する。また、本実施形態は、上記実施形態と任意に組み合わせ可能である。

ＭＦＰ１１０の記憶装置１１６が故障した場合でも元の状態に復旧するための動作として、エクスポート機能や、インポート機能がある。これは、ＭＦＰ１１０のすべての設定を外部の記憶媒体やサーバーに設定ファイルとしてエクスポートすることにより、ＭＦＰ１１０の記憶装置１１６が故障による交換を行っても、エクスポートした設定ファイルをインポートすることにより復旧が可能とする。しかし、エクスポートした設定ファイルは利用者が手元で書き換えが可能であるため、ルートＣＡ証明書も改ざんのおそれがある。その結果、このような情報を利用する場合には、信頼性が消失する恐れがある。

そこで、本実施形態では、ベンダー属性の値が“ベンダー属性あり”のルートＣＡ証明書の場合は、利用者が書き換えられないように暗号化処理を行ってからエクスポートする。また、インポートの際にはベンダー属性のあるルートＣＡ証明書の場合は復号化処理を行ってからインポートを実施する。

［エクスポート処理］
図８は、本実施形態に係る鍵管理部２０５のエクスポート処理の動作を説明するフローチャートである。本処理フローは、ＭＦＰ１１０の利用者がＭＦＰ１１０の各種データのエクスポート処理の実行を指示した際に開始される。

Ｓ８０１にて、鍵管理部２０５は、機体固有の共通鍵を生成する。この共通鍵はＭＦＰ１１０の利用者には公開されないものである。本実施形態では、記憶装置１１６に依存しない情報から生成される共通鍵（例えば、ＭＦＰ１１０の機体番号など）を用いる。なお、生成方法については特に限定するものではなく、任意の方法が用いられてよい。

Ｓ８０２にて、鍵管理部２０５は、管理テーブル６０４にて管理されているルートＣＡ証明書のうち先頭のルートＣＡ証明書に着目し、そのベンダー属性の情報を読み込む。

Ｓ８０３にて、鍵管理部２０５は、Ｓ８０２の読み込みの結果、“ベンダー属性あり”の値であるか否かを判定する。“ベンダー属性あり”と判定された場合（Ｓ８０３にてＹＥＳ）Ｓ８０４へ進み、“ベンダー属性なし”と判定された場合（Ｓ８０３にてＮＯ）Ｓ８０５へ進む。

Ｓ８０４にて、鍵管理部２０５は、着目しているルートＣＡ証明書の実体ファイルを、Ｓ８０１にて生成した共通鍵を用いて暗号化し、任意の記憶領域に保存する。ここでの任意の記憶領域は、ユーザーによって指定された外部記憶装置やネットワーク上のサーバーなどが用いられてよい。そして、Ｓ８０６へ進む。

Ｓ８０５にて、鍵管理部２０５は、着目しているルートＣＡ証明書の実体ファイルを平文で任意の記憶領域に保存する。そして、Ｓ８０６へ進む。

Ｓ８０６にて、鍵管理部２０５は、管理テーブル６０４から未処理のルートＣＡ証明書を検索する。

Ｓ８０７にて、鍵管理部２０５は、Ｓ８０６の検索の結果、未処理のルートＣＡ証明書のファイルがあるか否かを判定する。未処理のルートＣＡ証明書のファイルがあると判定された場合（Ｓ８０７にてＹＥＳ）Ｓ８０２へ戻り、未処理のルートＣＡ証明書に対して処理を繰り返す。図６の例の場合、ルートＣＡ証明書６０５～６０７の３つの実体ファイルに対して、順次処理が繰り返される。未処理のルートＣＡ証明書のファイルが無いと判定された場合（Ｓ８０７にてＮＯ）Ｓ８０８へ進む。

Ｓ８０８にて、鍵管理部２０５は、管理テーブル６０４そのものを任意の記憶領域に保存する。なお、管理テーブル６０４の保存位置と、Ｓ８０４やＳ８０５における実態ファイルの保存位置は同じであってもよいし、別の場所であってもよい。そして、本処理フローを終了する。

［インポート処理］
図９は、本実施形態に係る鍵管理部２０５のインポート処理の動作を説明するフローチャートである。本処理フローは、ＭＦＰ１１０の利用者がＭＦＰ１１０の各種データのインポート処理の実行を指示した際に開始される。また、本処理にて用いられるインポートデータは、図８にて示したエクスポート処理により得られたエクスポートデータであるものとし、そのデータの格納場所が利用者等によって指定されるものとする。

Ｓ９０１にて、鍵管理部２０５は、機体固有の共通鍵を生成する。なお、生成方法については特に限定するものではなく、任意の方法が用いられてよい。ここでは、図８に示したエクスポート処理のＳ８０１と同様の方法により、対応する共通鍵が生成される。

Ｓ９０２にて、鍵管理部２０５は、任意の記憶領域からエクスポートデータに含まれる管理テーブル６０４を読み込む。管理テーブル６０４を読み込む記憶領域はユーザーから指定されてもよい。

Ｓ９０３にて、鍵管理部２０５は、管理テーブル６０４にて管理されているルートＣＡ小証書のうち、先頭のルートＣＡ証明書に着目し、そのベンダー属性の情報を読み込む。

Ｓ９０４にて、鍵管理部２０５は、Ｓ９０３の読み込みの結果、“ベンダー属性あり”の値であるか否かを判定する。“ベンダー属性あり”と判定された場合（Ｓ９０４にてＹＥＳ）Ｓ９０５へ進み、“ベンダー属性なし”と判定された場合（Ｓ９０４にてＮＯ）Ｓ９０６へ進む。

Ｓ９０５にて、鍵管理部２０５は、着目しているルートＣＡ証明書の実体ファイルを任意の記憶領域から読み込み、Ｓ９０１にて生成された共通鍵を用いて復号化し、記憶装置１１６に保存する。そして、Ｓ９０７へ進む。

Ｓ９０６にて、鍵管理部２０５は、着目しているルートＣＡ証明書の実体ファイルを任意の記憶領域から読み込み、記憶装置１１６に保存する。ここでは、着目しているルートＣＡ証明書の実体ファイルは、図８のＳ８０５の処理に基づき暗号化されていないものとし、読み込んだ実体ファイルがそのまま記憶装置１１６に保存される。そして、Ｓ９０７へ進む。

Ｓ９０７にて、鍵管理部２０５は、エクスポートデータに含まれる管理テーブル６０４から未処理のルートＣＡ証明書を検索する。

Ｓ９０８にて、鍵管理部は、Ｓ９０７の検索の結果、未処理のルートＣＡ証明書のファイルがあるか否かを判定する。未処理のルートＣＡ証明書のファイルがあると判定された場合（Ｓ９０８にてＹＥＳ）Ｓ９０３へ戻り、未処理のルートＣＡ証明書に対して処理を繰り返す。図６の例の場合、ルートＣＡ証明書６０５～６０７の３つの実体ファイルに対して、順次処理が繰り返される。未処理のルートＣＡ証明書のファイルが無いと判定された場合（Ｓ９０８にてＮＯ）本処理フローを終了する。

以上、本実施形態により、機器内に保存されている信頼できるルートＣＡ証明書を外部にエクスポート、インポートする場合でも、共通鍵で暗号化／復号化を行う。これにより、利用者がベンダー資産を使用するアプリケーションの認証に用いられるルートＣＡ証明書の中身を見たり、改ざんしたりすることができなくなるため、信頼性を維持したまま復旧が可能となる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１１０…ＭＦＰ、１１４…ＣＰＵ、１１６…記憶装置、２０１…組み込みアプリケーション、２０２…暗号通信部、２０３…設定記憶部、２０４…デジタル証明書検証部、２０５…鍵管理部、２０６…証明書インストール部、２０７…外部アプリケーション、２０８…外部アプリケーションインストール部、２０９…外部アプリケーション管理部、２１０…ソフトウェアアップデート部

Claims

１または複数のアプリケーションが動作可能な情報処理装置であって、
外部サーバーとの暗号化通信を行う際に用いられるルート証明書を管理する管理手段と、
アプリケーションから前記外部サーバーとの暗号化通信の要求を受け付けた際に、当該アプリケーションが、前記情報処理装置における所定の情報を利用するか否かを判定する判定手段と、
前記判定手段にて前記アプリケーションが前記所定の情報を利用すると判定された場合、前記管理手段にて管理されているルート証明書のうち、所定の属性情報が設定されたルート証明書を用いて、前記外部サーバーのサーバー証明書を検証する検証手段と
を有することを特徴とする情報処理装置。
ユーザーの指示に基づいて新たなルート証明書をインストールするインストール手段を更に有し、
前記管理手段は、前記インストール手段にてインストールされたルート証明書には前記所定の属性情報を設定しないことを特徴とする請求項１に記載の情報処理装置。
前記情報処理装置に備えられたファームウェアをアップデートするアップデート手段を更に有し、
前記管理手段は、前記アップデート手段によるアップデートに用いられるデータに含まれるルート証明書には前記所定の属性情報を設定することを特徴とする請求項１または２に記載の情報処理装置。
前記管理手段は、前記情報処理装置の出荷時にインストールされていたルート証明書には前記所定の属性情報を設定して管理することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理装置。
前記情報処理装置にインストールされているアプリケーションの情報を管理する第２の管理手段を更に有し、
前記判定手段は、アプリケーションから前記外部サーバーとの暗号化通信の要求を受け付けた際に、当該アプリケーションから前記所定の情報を利用するか否かを示す指示を受け付けたか否かを判定し、
前記指示を受け付けていない場合、前記第２の管理手段にて管理されている情報に基づいて、当該アプリケーションが、前記所定の情報を利用するか否かを判定することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
前記外部サーバーのサーバー証明書の検証を行うか否かの設定を行う設定手段を更に有し、
前記検証手段は、前記判定手段にて前記外部サーバーとの暗号化通信の要求を行ったアプリケーションが前記所定の情報を利用せず、かつ、前記設定手段にてサーバー証明書の検証を行わない設定がされている場合に、当該サーバー証明書の検証を行わないことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
前記情報処理装置の固有の情報を用いて共通鍵を生成する生成手段と、
前記情報処理装置にインストールされているルート証明書のうち、前記所定の属性情報が設定されたルート証明書を前記生成手段にて生成された共通鍵を用いて暗号化してエクスポートするエクスポート手段と、
前記エクスポート手段にて出力されたデータを前記情報処理装置にインポートする際に、前記生成手段にて生成された共通鍵を用いて暗号化されたルート証明書を復号化してインポートするインポート手段と
を更に有することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
前記エクスポート手段は、前記情報処理装置にインストールされているルート証明書のうち、前記所定の属性情報が設定されていないルート証明書は暗号化せずにエクスポートすることを特徴とする請求項７に記載の情報処理装置。
前記所定の情報は、前記情報処理装置のベンダーにて管理されるものとして定義されたベンダー資産の情報であることを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
前記所定の属性情報は、前記情報処理装置のベンダーから提供されたものであることを示す情報であることを特徴とする請求項１乃至９のいずれか一項に記載の情報処理装置。
前記検証手段の検証結果に基づいて、前記外部サーバーとの暗号化通信を行う通信手段を更に有することを特徴とする請求項１乃至１０のいずれか一項に記載の情報処理装置。
１または複数のアプリケーションが動作可能な情報処理装置の制御方法であって、
外部サーバーとの暗号化通信を行う際に用いられるルート証明書を管理手段にて管理する管理工程と、
アプリケーションから前記外部サーバーとの暗号化通信の要求を受け付けた際に、当該アプリケーションが、前記情報処理装置における所定の情報を利用するか否かを判定する判定工程と、
前記判定工程にて前記アプリケーションが前記所定の情報を利用すると判定された場合、前記管理手段にて管理されているルート証明書のうち、所定の属性情報が設定されたルート証明書を用いて、前記外部サーバーのサーバー証明書を検証する検証工程と
を有することを特徴とする情報処理装置の制御方法。
１または複数のアプリケーションが動作可能なコンピューターを、
外部サーバーとの暗号化通信を行う際に用いられるルート証明書を管理する管理手段、
アプリケーションから前記外部サーバーとの暗号化通信の要求を受け付けた際に、当該アプリケーションが、前記コンピューターにおける所定の情報を利用するか否かを判定する判定手段、
前記判定手段にて前記アプリケーションが前記所定の情報を利用すると判定された場合、前記管理手段にて管理されているルート証明書のうち、所定の属性情報が設定されたルート証明書を用いて、前記外部サーバーのサーバー証明書を検証する検証手段
として機能させるためのプログラム。