JP2013003733A

JP2013003733A - 通信装置、データアクセス方法、およびデータアクセスプログラム

Info

Publication number: JP2013003733A
Application number: JP2011132534A
Authority: JP
Inventors: Hiroki Oizumi; 博紀大泉
Original assignee: Docomo Systems Inc
Current assignee: Docomo Systems Inc
Priority date: 2011-06-14
Filing date: 2011-06-14
Publication date: 2013-01-07
Anticipated expiration: 2031-06-14
Also published as: JP5357927B2

Abstract

【課題】不正なアプリケーションからのアクセス要求を的確に拒絶する。
【解決手段】アプリ承認コードを受け付けると、認証情報管理サーバから認証情報テーブルを取得し、証明書抽出部１０５は、認証情報テーブルを利用して証明書情報をパッケージマネージャ１０６から抽出し、検証処理部１０７は、証明書情報に基づいて、クライアントアプリケーション１０１の検証を行なう。クライアントアプリケーション１０１が正当であるとの検証が行なわれると、リクエストＩＤ生成部１０８は、クライアントアプリケーション１０１のためのリクエストＩＤを生成し、通知部１０９は、リクエストＩＤをパッケージ名およびアクティビティ名に基づいて定められたクライアントアプリケーション１０１に通知する。
【選択図】図２

Description

本発明は、任意のサイトからダウンロードしたアプリケーションを保持する通信装置およびこのアプリケーションによるデータアクセス方法、およびデータアクセスプログラムに関する。

近年の携帯電話は、さまざまなアプリケーションをサイトからダウンロードすることができる。しかしながら、悪意あるアプリケーションも存在しており、全てのアプリケーションに対して携帯電話における各データベース（例えば電話帳）に対するアクセスを許容すると、個人情報が外部に流出する可能性が高まり、好ましくはない。そのために、アプリケーションに対する検証を行い、必要なアプリケーションに対してのみ各データベースに対するアクセスを許容する仕組みが必要となる。

特許文献１（特開平１１−１４３８４０号公報）においては、クライアントオブジェクトプログラムに対する署名検証を行い、検証後、管理テーブルを用いて登録の有無をチェックすることにより、不正プログラムのチェックを行っている。

特開平１１−１４３８４０号公報

しかしながら、この特許文献１に記載の技術では、署名検証をしたり、またクライアント端末側において予め登録した情報に基づいて、プログラムの適否を判断しているため、プログラムそれ自体が不正なものであった場合、その機能を停止させることができない。すなわち、正当な手続きをもってして証明書等を手に入れたプログラムがあった場合、後になってそのインストールをしたプログラムを排除することは困難となる。

そこで、本発明においては、プログラムなどのアプリケーションが詐称などされたとしても、不正なアプリケーションからのアクセス要求を的確に拒絶することができる通信装置、データアクセス方法、およびデータアクセスプログラムを提供することを目的とする。

上述の課題を解決するために、本発明の通信装置は、任意のサイトからダウンロードされたアプリケーションと、前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、を備える通信装置において、前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得手段と、前記取得手段により取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出手段と、前記証明書情報抽出手段により抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証手段と、前記検証手段により、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成手段と、前記生成手段により生成された許可情報を、認証情報テーブルに従って識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知手段と、を備えている。

この発明によれば、アプリケーションから登録番号を受け付けると、認証情報管理サーバから登録番号、識別子および回答先指定情報を対応付けた認証情報テーブルを取得し、取得された認証情報テーブルに基づいて、登録番号に対応する識別子を特定する。そして、特定された識別子に基づいて証明書情報を抽出し、この証明書情報に基づいて、アプリケーションの検証を行なう。ここで、アプリケーションが正当であるとの検証が行なわれると、アプリケーションにおけるアクセスを許可するための許可情報を生成し、生成された許可情報を、抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する。

これにより、不正なアプリケーションが他のアプリケーションを詐称した、データベースに対するアクセスは拒絶される。すなわち、他のアプリケーションを詐称した不正なアプリケーションは、データベースに必要な許可情報を受け取ることができないため、データベースに対してアクセスすることができず、よって不正な行為によるデータ流出を確実に防止することができる。

また、認証情報管理サーバから取得した識別子および回答先指定情報に基づいてリクエストＩＤをアプリケーションに通知するため、仮に登録情報自体を正当な手続きを持ってして取得したアプリケーションが、後になって不正なアプリケーションであることが分かった場合、認証情報管理サーバ側において、そのような不正なアプリケーションに対しては許可情報を通知しないように、その認証情報テーブルを書き換えることができ、この場合においても、不正なアプリケーションによるデータベースに対するアクセスを防止することができる。

また、本発明の通信装置において、アプリケーションは、アクセス要求および許可情報を、アクセス対象に対して送信し、前記アクセス対象は、前記許可情報が一致していた場合に、前記アプリケーションからのアクセスを許可するように構成してもよい。

この発明によれば、アプリケーションは、アクセス要求および許可情報を、アクセス対象に対して送信し、アクセス対象は、許可情報が一致していた場合に、アプリケーションからのアクセスを許可することで、不正なアプリケーションからのアクセスを防止することができる。

また、本発明の通信装置において、前記許可情報は、有効期限が定められており、前記アクセス対象は、前記許可情報の有効期限に基づいて、前記アプリケーションからのアクセスの可否を判断するようにしてもよい。

この発明によれば、許可情報は、有効期限が定められており、アクセス対象は、許可情報の有効期限に基づいて、アプリケーションからのアクセスの可否を判断することができ、アクセス対象先に対するアクセスを制限することができ、データ流出のリスクを軽減することができる。

また、本発明の通信装置において、前記許可情報の有効期限は、前記アプリケーションが起動している間であるようにしてもよい。

この発明によれば、許可情報の有効期限は、アプリケーションが起動している間とすることで、簡易に有効期限を設定することができるとともに、アクセス対象からのデータ流出のリスクを低減することができる。

また、本発明において、登録番号は、アプリ承認コードであり、識別子は、パッケージ名であり、回答先指定情報は、アクティビティ名であり、許可情報は、リクエストＩＤであり、それぞれアンドロイドにおいて規定されたものであるようにしてもよい。

なお、本発明は、上述通信装置の発明のほか、データアクセス方法およびデータアクセスプログラムの発明としても捉えることができる。

すなわち、本発明のデータアクセス方法は、任意のサイトからダウンロードされたアプリケーションと、前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、を備える通信装置におけるデータアクセス方法において、前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得ステップと、前記取得ステップにより取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出ステップと、前記証明書情報抽出ステップにより抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証ステップと、前記検証ステップにより、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成ステップと、前記生成ステップにより生成された許可情報を、認証情報テーブルに従って抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知ステップと、を備えている。

また、本発明のデータアクセスプログラムは、任意のサイトからダウンロードされたアプリケーションと、前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、を利用したデータアクセスプログラムにおいて、前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得モジュールと、前記取得モジュールにより取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出モジュールと、前記証明書情報抽出モジュールにより抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証モジュールと、前記検証モジュールにより、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成モジュールと、前記生成モジュールにより生成された許可情報を、認証情報テーブルに従って抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知モジュールと、を備えている。

本発明によれば、不正なアプリケーションが他のアプリケーションであると詐称して、データベースに対するアクセスをしようとしても、そのアクセスは拒絶される。すなわち、他のアプリケーションであると詐称した不正なアプリケーションは、データベースに必要なリクエストＩＤを受け取ることができないため、データベースにおける不正な行為によるデータ流出を確実に防止することができる。

本実施形態の通信装置である携帯電話１００を用いて通信システムのシステム構成を示すシステム図である。本実施形態の携帯電話１００の機能を示すブロック図である。携帯電話１００のハードウェア構成図である。認証情報管理サーバ２００に記憶されている認証情報テーブルの具体例を示す。ＯＳにおいて記憶されているパッケージ情報のリストを示す説明図である。アドレス帳１１０などのデータベースに対するアクセス処理を示すフローチャートである。アドレス帳１１０などのデータベースに対するアクセス処理を示すフローチャートである。

添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。

図１は、本実施形態の通信装置である携帯電話１００を用いて通信システムのシステム構成を示すシステム図である。図１に示されるとおり、この通信システムは、携帯電話１００および認証情報管理サーバ２００から構成されており、携帯電話１００は、ダウンロードしたアプリケーションを動作させようとしたときに、認証情報管理サーバ２００から認証情報テーブルを取得し、この認証情報テーブルを用いて、アプリケーションの正当性を判断することができる。この認証情報管理サーバ２００は、図１においては、非等だけ示しているが、後述するとおり、アプリケーションを管理するところは多数ある。そのため、アプリケーションを管理する会社（販売会社や、通信事業者）等ごとに存在するものである。

図２は、本実施形態の携帯電話１００の機能を示すブロック図である。図２に示されるとおり、この携帯電話１００は、クライアントアプリケーション１０１（アプリケーション）、セキュア処理部１０２、パッケージマネージャ１０６、およびセキュアアドレス帳１１２を含んで構成されている。セキュア処理部１０２は、さらに、テーブル取得部１０３（取得手段）、記憶部１０４、証明書抽出部１０５（証明書情報抽出手段）、検証処理部１０７（検証手段）、リクエストＩＤ生成部１０８（生成手段）、および通知部１０９（通知手段）を含んで構成されている。また、セキュアアドレス帳１１２は、アドレス帳１１０およびリクエストＩＤ記憶部１１１を含んで構成されている。

この携帯電話１００は、図３に示されるハードウェア構成により実現される。図３は、携帯電話１００のハードウェア構成図である。図２に示される携帯電話１００は、物理的には、図３に示すように、ＣＰＵ１１、主記憶装置であるＲＡＭ１２及びＲＯＭ１３、入力デバイスであるキーボード及びマウス等の入力装置１４、ディスプレイ等の出力装置１５、ネットワークカード等のデータ送受信デバイスである通信モジュール１６、半導体メモリ等の補助記憶装置１７などを含むコンピュータシステムとして構成されている。図２において説明した各機能は、図３に示すＣＰＵ１１、ＲＡＭ１２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１１の制御のもとで入力装置１４、出力装置１５、通信モジュール１６を動作させるとともに、ＲＡＭ１２や補助記憶装置１７におけるデータの読み出し及び書き込みを行うことで実現される。以下、図２に示す機能ブロックに基づいて、各機能ブロックを説明する。

クライアントアプリケーション１０１は、プログラム等のアプリケーションであって、ネットワークを介してダウンロードされたアプリケーションである。図２においては、便宜上、クライアントアプリケーション１０１ａから１０１ｃの３つしかクライアントアプリケーションを記述していないが、一般的に携帯電話１００には、複数のクライアントアプリケーション１０１をダウンロードして記憶することができる。以降、クライアントアプリケーション１０１ａから１０１ｃの一つ若しくは全てを含んで、クライアントアプリケーション１０１と称する。なお、このクライアントアプリケーション１０１は、携帯電話１００において保持されているアドレス帳などの、各種データベースに対してアクセスすることができる機能を有している。また、このクライアントアプリケーション１０１は、メモリ等に記憶された状態で携帯電話１００に保持されており、ＣＰＵにより処理されることにより各種機能を実行するものである。

セキュア処理部１０２は、クライアントアプリケーション１０１からアクセス認証要求およびアプリ承認コードを受信すると、このアプリ承認コードに従って、クライアントアプリケーション１０１が不正なものであるか否かを判断する。以下、さらに詳細に説明する。

テーブル取得部１０３は、クライアントアプリケーション１０１からアクセス認証要求、アプリ承認コードおよびコールバックアドレスを受信すると、アプリ承認コードに基づいて、記憶部１０４に記憶されているクライアントアプリケーション１０１の認証情報テーブルに、そのクライアントアプリケーション１０１に関する認証情報が記憶されているか否かを判断する。そして、記憶されていないと判断すると、認証情報管理サーバ２００から認証情報テーブルを取得する。その際、認証情報管理サーバ２００において記憶されている認証情報テーブルが前回取得した認証情報テーブルと比較して更新されたか否かを問い合わせ、更新されたとの回答を得た場合には、認証情報テーブル２００から認証情報テーブルを取得する。

例えば、テーブル取得部１０３は、ＨＴＴＰ(Hyper Text TransferProtocol)のＧＥＴコマンドを用いて、認証情報テーブルを示したファイル名を指定することで、認証情報管理サーバ２００から認証情報テーブルを取得することができる。なお、当然ながら、ＨＴＴＰや、ＧＥＴコマンドを用いることに限定するものではなく、インターネットを経由して情報を取得できる手段であるならば、その取得方法は問わない。取得した認証情報テーブルは、記憶部１０４において更新されて記憶される。また、更新されていないとの回答を得た場合には、取得処理は行わない。この場合、前回取得された認証情報テーブルが記憶部１０４に記憶されたままとなる。そして、認証情報管理サーバ２００において更新された場合には、アプリ承認コードに基づいて、更新された認証情報テーブルに、そのクライアントアプリケーション１０１に関する認証情報が記憶されているか否かを判断する。

なお、上述では、テーブル取得部１０３が、アプリ承認コードに基づいて、既に記憶されている認証情報テーブルに、クライアントアプリケーション１０１の認証情報が記憶されている場合には、認証情報テーブルを取得しないようにしているが、これに限るものではなく、常時、認証情報管理サーバ２００に対して、更新の有無の問い合わせを行うようにしてもよい。このような処理をすることで、不正なアプリケーションの発見を早期に行うことができる。また、テーブル取得部１０３は、クライアントアプリケーション１０１ごとに、その認証情報テーブルの取得先を変えるようにしてもよい。クライアントアプリケーション１０１ごとにその認証情報を管理する会社等は異なるため、認証情報テーブルを記憶しているサーバも当然に異なっている。なお、クライアントアプリケーション１０１には、認証情報管理サーバ２００のアクセス先や、それを示す識別子などが記述されているなどして、クライアントアプリケーション１０１によって、そのアクセス先が異なるように構成されている。

図４に、認証情報管理サーバ２００に記憶されている認証情報テーブルの具体例を示す。図４に示されるとおり、アプリ承認コード、パッケージ名、アプリ承認の有効／無効、およびアクティビティ名を対応付けて記憶している。アプリ承認コードは、アクセスコントロール管理元で払い出したクライアントアプリケーション１０１の登録番号である。ここでいうアクセスコントロール管理元とは、アプリケーションの作成者による申請に対してその許認可を行うところを指すものであり、例えばアプリケーションの販売管理会社であったり、通信キャリア事業者である。アプリ承認の有効／無効とは、アプリ承認コードの有効または無効を示す情報であり、認証情報管理サーバ２００のオペレータ（例えば、上述販売管理会社のオペレータ）により切り替えられるものである。例えば、クライアントアプリケーション１０１が不正なものであると、アプリ承認コード発行後に発覚した場合、アプリ承認コードを無効にすることにより、クライアントアプリケーション１０１のデータベースへのアクセス等を制限することができる。

また、パッケージ名は、ＯＳ上でのアプリケーションの識別子であり、アクティビティ名は、アプリケーションの画面を特定するための情報である。このアクティビティ名は、本実施形態では、認証情報を戻すためのアドレス情報（回答先指定情報）として利用している。

これら用語は、グーグル（登録商標）により規定された、スマートフォンなどの携帯端末のプラットフォームであるアンドロイド（Android）により規定されたものである。他のプラットフォームを利用した場合においても、上述と同様の機能や情報を持っている場合には、本実施形態の技術を適用することができる。

記憶部１０４は、テーブル取得部１０３において取得された認証情報テーブルを記憶する部分である。

証明書抽出部１０５は、テーブル取得部１０３により取得された認証情報テーブルを参照して、アプリ承認コードに対応するパッケージ名を特定し、このパッケージ名を利用してパッケージマネージャ１０６から、証明書を抽出する部分である。

パッケージマネージャ１０６は、ＯＳ（Operating System）に備えられている管理プログラムであり、ダウンロードされた各アプリケーションの証明書情報を管理し、記憶する部分である。このパッケージマネージャ１０６は、証明書抽出部１０５からの証明書の抽出指示に応じて、パッケージ名に対応する証明書を証明書抽出部１０５に出力する。なお、パッケージマネージャ１０６は、ダウンロードしたアプリケーションごとにパッケージ情報（Packageinfo）を記憶しており、このパッケージ情報には証明書が含まれている。

図５は、ＯＳにおいて記憶されているパッケージ情報のリストを示す説明図である。図５においては、Packageinfoで示されたパッケージ情報を記憶していることを示している。それぞれアプリケーションの証明書を保持している。

検証処理部１０７は、証明書抽出部１０５により抽出された証明書の検証を行い、クライアントアプリケーション１０１の正当性を判断する部分である。

リクエストＩＤ生成部１０８は、検証処理部１０７において、クライアントアプリケーション１０１が正当であると判断されると、リクエストＩＤを生成する部分である。このリクエストＩＤは、クライアントアプリケーション１０１によるデータアクセスを許可するための許可情報である。リクエストＩＤ生成部１０８は、セキュアアドレス帳１１２に、生成したリクエストＩＤを記憶させる。なお、このリクエストＩＤは、有効期限があるものとしてもよく、例えば、クライアントアプリケーション１０１が起動している間、有効なものとする。すなわち、クライアントアプリケーション１０１が起動するごとに、プロセスＩＤが発行され、それとともに、リクエストＩＤが発行されるが、クライアントアプリケーション１０１が終了すると、これらプロセスＩＤおよびリクエストＩＤは無効となる。例えば、クライアントアプリケーション１０１が起動している間には、有効なプロセスＩＤおよびリクエストＩＤを記憶するためのバッファ領域を設けておき、クライアントアプリケーション１０１が終了したときには、そのバッファ領域からプロセスＩＤおよびリクエストＩＤを削除することにより、クライアントアプリケーション１０１と、リクエストＩＤとの同期を取ることができる。上述のリクエストＩＤの有効期限の設定については、必須のものではなく、データ流出リスクの増加を許容できるのであれば、設定しなくてもよい。

そして、セキュアアドレス帳１１２は、このリクエストＩＤを用いて、有効期限内、すなわちクライアントアプリケーション１０１が、リクエストＩＤが発行されてから継続して起動しているのであれば、クライアントアプリケーション１０１による、携帯電話１００に保持されている各種データに対するアクセスを許可することができる。

通知部１０９は、リクエストＩＤ生成部１０８により生成されたリクエストＩＤを、パッケージ名およびアクティビティ名により特定されたクライアントアプリケーション１０１に通知する部分である。すなわち、通知部１０９は、認証情報テーブルを参照して、アプリ承認コードに基づいてパッケージ名およびアクティビティ名を抽出する。そして、抽出したパッケージ名およびアクティビティ名に基づいて特定されたクライアントアプリケーション１０１宛てにリクエストＩＤを通知する。

また、通知部１０９は、アプリ認証要求を行ったクライアントアプリケーション１０１に対して、コールバックアドレスを用いて、当該アプリ認証要求に対する応答として、アプリ認証要求結果（ＯＫまたはＮＧ）を送信する。なお、リクエストＩＤが通知されるクライアントアプリケーション１０１と、アプリ認証要求結果が送信されるクライアントアプリケーション１０１とは、必ずしも同じとは限らない。クライアントアプリケーション１０１がアプリ承認コードを詐称してアクセスしようとした場合、アプリ承認コードに基づいてパッケージ名やアクティビティ名が特定される。その場合、パッケージ名やアクティビティ名に基づいて、正しいクライアントアプリケーション１０１が特定される。

例えば、図２におけるクライアントアプリケーション１０１ｃが不正なアプリケーションとした場合、クライアントアプリケーション１０１ａであるとして詐称して、クライアントアプリケーション１０１ａのアプリ承認コードを送信したとする。しかしながら、アドレス帳１１０などのデータベースのアクセスに必要なリクエストＩＤは、アプリ承認コードに対応するアクティビティ名およびパッケージ名に基づいて特定されたクライアントアプリケーション１０１ａに送信されることになる。よって、詐称したクライアントアプリケーション１０１ｃにリクエストＩＤが送信されることはない。

アドレス帳１１０は、携帯電話１００が保持しているデータベースであり、宛先人名やその電話番号、メールアドレスを対応付けて記憶する部分である。なお、本実施形態では、一例としてアドレス帳を、アクセス対象となるデータベースとして挙げているが、これに限るものではなく、電子メールのデータや、電話・電子メールの発着信履歴、携帯電話１００の設定値情報などが、アクセス制限の対象のデータベースとして考えられる。

リクエストＩＤ記憶部１１１は、リクエストＩＤ生成部１０８により生成されたリクエストＩＤを記憶する部分である。アドレス帳１１０は、このリクエストＩＤ記憶部１１１に記憶されたリクエストＩＤに基づいて、クライアントアプリケーション１０１からのアクセス要求に対して、その適否を判断する。

このようにして、不正なクライアントアプリケーション１０１からのアクセスを確実に防止することができる。

つぎに、本実施形態の携帯電話１００を用いたデータアクセス処理方法について説明する。図６は、本実施形態の携帯電話１００の処理を示すフローチャートである。まず、クライアントアプリケーション１０１が起動されると、その旨の起動信号がセキュア処理部１０２に出力され、その後、アプリ承認コードおよびコールバックアドレスを含んだ認証要求がセキュア処理部１０２に出力される（Ｓ１０１、Ｓ１０２）。

そして、テーブル取得部１０３において、受け付けたアプリ承認コードに基づいて、認証情報テーブルから、アプリ承認コードに対応するアプリケーション情報の存在の有無が判断される（Ｓ１０３）。ここでアプリケーション情報がないと判断されると、テーブル取得部１０３により、認証情報管理サーバ２００において、認証情報テーブルの更新がされたものか否かが判断されて、その後更新された場合には、当該認証情報管理サーバ２００から認証情報テーブルが取得される（Ｓ１０４、Ｓ１０５）。なお、アプリケーション情報の存在の有無を判断することなく、常に認証情報管理サーバ２００において認証情報テーブルの更新の有無を問い合わせるようにしてもよい。

取得された認証情報テーブルは記憶部１０４に記憶され、更新される（Ｓ１０７）。なお、認証情報管理サーバ２００において認証情報テーブルが更新されていない場合には、取得処理は行われない。その後、証明書抽出部１０５により、アプリ承認コードに対応するパッケージ名が、認証情報テーブルに基づいて特定され（Ｓ１０８）、パッケージマネージャ１０６から証明書の取得処理が行われる（Ｓ１０９、Ｓ１１０）。検証処理部１０７では、取得した証明書に基づいて検証処理が行われる（Ｓ１１１）。そして、証明書の検証結果がメッセージとして、表示部（図示せず）に表示される（Ｓ１１２）。

その後、リクエストＩＤ生成部１０８によりリクエストＩＤが生成される（Ｓ１１３）。生成処理後、コールバックアドレスに基づいて、認証要求をしたクライアントアプリケーション１０１が特定され、当該クライアントアプリケーション１０１に対して認証結果が通知部１０９により通知される（Ｓ１１４）。また、アクティビティ名およびパッケージ名により特定されたクライアントアプリケーション１０１宛に、通知部１０９により、リクエストＩＤ生成部１０８により生成されたリクエストＩＤが送信される（Ｓ１１５、Ｓ１１６）。クライアントアプリケーション１０１では、送信されたリクエストＩＤが記憶される（Ｓ１１７）。

このようにして、各種データベースにアクセスに必要なリクエストＩＤは、アプリ承認コードに対応したパッケージ名およびアクティビティ名に基づいて定められたクライアントアプリケーション１０１宛に送信することになり、必ずしも認証要求をしたクライアントアプリケーション１０１に送られることはない。よって、認証要求をしたクライアントアプリケーション１０１が不正なものであり、アプリ承認コードを詐称して認証要求を行ったとしても、リクエストＩＤを入手することができない。よって、アドレス帳や、各種データベースを不正なクライアントアプリケーション１０１からのアクセスから守ることができる。

なお、もともと不正なクライアントアプリケーション１０１ｃに対して承認がおりて、証明書やアプリ承認コードが発行された場合においても、認証情報管理サーバ２００において、そのアプリ承認コードを含んだ認証管理テーブルを送らないように、送信対象となる認証管理テーブルには、アプリ承認コード若しくはそれに対応するアクティビティ名などを含めないようにすることで、不正なクライアントアプリケーション１０１によるアドレス帳１１０などのデータベースに対するアクセスを適切に防止することができる。

ここで、クライアントアプリケーション１０１がアドレス帳１１０などのデータベースに対してアクセスする際の処理について説明する。図７は、アドレス帳１１０などのデータベースに対するアクセス処理を示すフローチャートである。

クライアントアプリケーション１０１により、セキュアアドレス帳１１２に対してアクセス要求を行う際において、予め保持されているリクエストＩＤは読み出され、アクセス要求とともにリクエストＩＤが、セキュアアドレス帳１１２に対して送信される（Ｓ２０１）。

セキュアアドレス帳１１２では、アドレス帳１１０に対するアクセス要求を受けると、リクエストＩＤ記憶部１１１に記憶されているリクエストＩＤを読み出し、クライアントアプリケーション１０１から受け付けたリクエストＩＤと比較する（Ｓ２０２）。ここで、一致していれば、アドレス帳１１０によるアクセス許可が下され（Ｓ２０３）、一致していないのであれば、エラー処理行われる（Ｓ２０４）。

このようにして、アドレス帳などのデータベースは、クライアントアプリケーション１０１からのアクセス要求に対して、リクエストＩＤに基づいてアクセスの可否を判断することができ、不正なクライアントアプリケーション１０１からのアクセス要求を拒絶することができる。よって、不正なクライアントアプリケーション１０１をインストールしたことによる、データの流出を確実に防止することができる。

つぎに、本実施形態の携帯電話１００の作用効果について説明する。本実施形態の携帯電話１００によれば、テーブル取得部１０３において、クライアントアプリケーション１０１からアプリ承認コードを受け付けると、認証情報管理サーバ２００からアプリ承認コード、パッケージ名およびアクティビティ名を対応付けた認証情報テーブルを取得する。そして、証明書抽出部１０５は、取得された認証情報テーブルに基づいて、アプリ承認コードに対応するパッケージ名を抽出する。そして、証明書抽出部１０５は、抽出されたパッケージ名に基づいて証明書情報をパッケージマネージャ１０６から抽出し、検証処理部１０７は、証明書情報に基づいて、クライアントアプリケーション１０１の検証を行なう。ここで、クライアントアプリケーション１０１が正当であるとの検証が行なわれると、リクエストＩＤ生成部１０８は、クライアントアプリケーション１０１のためのリクエストＩＤを生成し、通知部１０９は、生成されたリクエストＩＤを、認証情報テーブルから抽出されたパッケージ名およびアクティビティ名に基づいて定められた宛先となるクライアントアプリケーション１０１に通知する。

これにより、例えば、不正なクライアントアプリケーション１０１ｃが、他のクライアントアプリケーション１０１ａであると詐称して、アクセス対象となるデータベースは、そのアクセスを拒絶することができる。すなわち、他のクライアントアプリケーション１０１ａであると詐称した不正なクライアントアプリケーション１０１ｃは、データベースに必要なリクエストＩＤを受け取ることができないため、データベースにおける不正な行為によるデータ流出を確実に防止することができる。

また、認証情報管理サーバ２００から取得したパッケージ名およびアクティビティ名に基づいてリクエストＩＤをクライアントアプリケーション１０１に通知するため、仮にアプリ承認コード自体を正当な手続きを持ってして取得したクライアントアプリケーション１０１が、後になって不正なクライアントアプリケーション１０１であることが分かった場合、認証情報管理サーバ２００側において、そのような不正なクライアントアプリケーション１０１に対してはリクエストＩＤを通知しないように、その認証情報テーブルを書き換えることができ、この場合においても、不正なクライアントアプリケーション１０１によるデータベースに対するアクセスを防止することができる。

また、本実施形態の携帯電話１００において、クライアントアプリケーション１０１は、アクセス要求およびリクエストＩＤを、アクセス対象であるセキュアアドレス帳１１２に対して送信し、セキュアアドレス帳１１２は、リクエストＩＤが一致していると判断する場合に、クライアントアプリケーション１０１（例えばクライアントアプリケーション１０１ａ）からのアクセスを許可することで、不正なクライアントアプリケーション１０１（例えば、クライアントアプリケーション１０１ｃ）からのアクセスを防止することができる。

また、本実施形態の携帯電話１００において、リクエストＩＤは、有効期限が定められており、アクセス対象であるセキュアアドレス帳１１２は、リクエストＩＤの有効期限に基づいて、クライアントアプリケーション１０１からのアクセスの可否を判断することができ、アクセス対象先に対するアクセスを制限することができ、データ流出のリスクを軽減することができる。

また、本実施形態の携帯電話１００において、リクエストＩＤの有効期限は、クライアントアプリケーション１０１が起動している間とすることで、簡易に有効期限を設定することができるとともに、アクセス対象からのデータ流出のリスクを低減することができる。

なお、リクエストＩＤの有効期限の管理方法として、上述のほか、タイマー等を利用して有効期限内であるか否かを判断することにより、リクエストＩＤの一致・不一致を判断するようにしてもよい。

なお、上述の実施形態においては、クライアントアプリケーション１０１からの認証要求は、アプリ承認コードとともに送信しているが、これに限るものではない。例えば、認証要求およびアプリ承認コードに加えて、アクティビティ名を追加して、セキュア処理部１０２に送信するようにしてもよい。このような処理をとった場合、認証情報管理サーバ２００においては、アクティビティ名との対応付けた認証情報テーブルは必要なくなり、認証情報テーブルは、アプリ承認コード、パッケージ名、およびアプリの有効／無効を対応付けて記憶しておけばよい。

なお、上述の通信装置１００におけるセキュア処理部１０２は、プログラムとして実現することができる。例えば、セキュア処理部１０２は、データアクセスプログラムとして存在するものであって、テーブル取得モジュール（取得モジュール）、記憶モジュール、証明書抽出モジュール（証明書情報抽出モジュール）、検証処理モジュール（検証モジュール）、リクエストＩＤ生成モジュール（生成モジュール）、および通知モジュール（通知モジュール）を含んで構成されているようにしてもよい。また、このようなプログラムをＣＤ−ＲＯＭ、ＤＶＤ、そのほか半導体メモリなどに記憶させておき、必要に応じて、通信装置にインストールすることにより本実施形態の機能を実現するようにしてもよい。

１００…携帯電話、１０１…クライアントアプリケーション、
１０１ａ…クライアントアプリケーション、１０１ｃ…クライアントアプリケーション、１０２…セキュア処理部、１０３…テーブル取得部、１０４…記憶部、１０５…証明書抽出部、１０６…パッケージマネージャ、１０７…検証処理部、１０８…リクエストＩＤ生成部、１０９…通知部、１１０…アドレス帳、１１１…リクエストＩＤ記憶部、１１２…セキュアアドレス帳、２００…認証情報管理サーバ。

Claims

任意のサイトからダウンロードされたアプリケーションと、
前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、
を備える通信装置において、
前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得手段と、
前記取得手段により取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出手段と、
前記証明書情報抽出手段により抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証手段と、
前記検証手段により、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成手段と、
前記生成手段により生成された許可情報を、認証情報テーブルに従って抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知手段と、
を備える通信装置。
アプリケーションは、アクセス要求および許可情報を、アクセス対象に対して送信し、
前記アクセス対象は、前記許可情報が一致していた場合に、前記アプリケーションからのアクセスを許可する
ことを特徴とする請求項１に記載の通信装置。
前記許可情報は、有効期限が定められており、
前記アクセス対象は、前記許可情報の有効期限に基づいて、前記アプリケーションからのアクセスの可否を判断する
ことを特徴とする請求項１または２に記載の通信装置。
前記許可情報の有効期限は、前記アプリケーションが起動している間であることを特徴とする請求項３に記載の通信装置。
登録番号は、アプリ承認コードであり、
識別子は、パッケージ名であり、
回答先指定情報は、アクティビティ名であり、
許可情報は、リクエストＩＤであり、
それぞれアンドロイドにおいて規定されたものである
ことを特徴とする請求項１から４のいずれか一項に記載の通信装置。
任意のサイトからダウンロードされたアプリケーションと、
前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、
を備える通信装置におけるデータアクセス方法において、
前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得ステップと、
前記取得ステップにより取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出ステップと、
前記証明書情報抽出ステップにより抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証ステップと、
前記検証ステップにより、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成ステップと、
前記生成ステップにより生成された許可情報を、認証情報テーブルに従って抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知ステップと、
を備えるデータアクセス方法。
任意のサイトからダウンロードされたアプリケーションと、
前記アプリケーションをダウンロードする際に、前記アプリケーションの検証のための証明書情報を、ＯＳ上においてアプリケーションを識別するための識別子と対応付けて記憶するパッケージマネージャと、
を利用したデータアクセスプログラムにおいて、
前記アプリケーションから、当該アプリケーションの管理元において割り当てられた登録番号を受け付けると、認証情報管理サーバから、アプリケーションの登録番号、ＯＳ上におけるアプリケーションの識別子およびアプリケーションに対して情報の回答先を特定するための回答先指定情報を対応付けた認証情報テーブルを取得する取得モジュールと、
前記取得モジュールにより取得された認証情報テーブルに基づいて、前記受け付けられた登録番号に対応する識別子を特定し、当該識別子に基づいて証明書情報を、前記パッケージマネージャから抽出する証明書情報抽出モジュールと、
前記証明書情報抽出モジュールにより抽出された証明書情報に基づいて、前記アプリケーションの検証を行なう検証モジュールと、
前記検証モジュールにより、前記アプリケーションが正当であるとの検証が行なわれると、前記アプリケーションにおけるデータに対するアクセスを許可するための許可情報を生成する生成モジュールと、
前記生成モジュールにより生成された許可情報を、認証情報テーブルに従って抽出された識別子および回答先指定情報に基づいて定められたアプリケーションに通知する通知モジュールと、
を備えるデータアクセスプログラム。