JP2019062394A - 情報処理装置、情報処理方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】 本発明は、複数の認証鍵ペアを適切に使い分け、セキュリティを向上させることが可能な情報処理装置を提供することを目的とする。【解決手段】 複数の認証鍵ペアを用いてサービス提供装置にログインする情報処理装置であって、前記サービス提供装置への複数のリクエストと前記サービス提供装置からの複数のレスポンスとによって通信する通信手段と、前記複数のリクエストの種類に応じて、複数のセキュリティクラスを設定する設定手段と、前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いることを制限する制限手段と、を有することを特徴とする。【選択図】 図１

Description

本発明は、サービス提供装置にログインする情報処理装置、情報処理方法、およびコンピュータプログラムに関する。

リモートシステムにログインするユーザを識別する技術として、ユーザＩＤとパスワードによるユーザ認証が広く使われている。これに対し、近年はユーザによる煩雑なパスワード管理を回避する手段として公開鍵暗号を利用したユーザ認証技術が提案されている。

公開鍵暗号を利用したユーザ認証技術の一例としてＦＩＤＯ（Ｆａｓｔ ＩＤｅｎｔｉｔｙ Ｏｎｌｉｎｅ）による標準技術がある。ＦＩＤＯで標準化された認証プロトコルによれば、ユーザの操作するログイン端末でユーザの認証鍵ペアを生成し、この認証鍵ペアの公開鍵をリモートサービスに登録する。ユーザがリモートサービスにログインする場合には、サービスから送られてくるチャレンジに対して認証鍵ペアの秘密鍵で署名を生成してサービスに送り返す。サービスはチャレンジに対する署名をユーザに対応付けられた公開鍵で検証し、ログインの可否を判定する。ログイン端末で管理される認証鍵ペアは指紋認証などの認証デバイスによって管理され、認証デバイスは正当なユーザによる操作を確認してから秘密鍵による署名を許可することが通常である。

一方で、このような公開鍵を利用したログイン端末に複数の認証デバイスが備えられている場合における認証デバイスの選択に関する技術が提案されている。例えば、特許文献１で開示される技術によれば、ログイン端末に対してユーザが認証デバイスの利用可否を設定する機能を設けることによりユーザの匿名性を向上させている。

特表２０１６−５０２３７３号公報

ログイン端末に複数の認証デバイスが備えられている場合には、ユーザが利用する認証デバイスを適切に使い分けることでセキュリティを向上させることが可能である。例えば、リモートサービスへのログイン時に利用する認証鍵ペアと、サービス上での送金許可に利用する認証鍵ペアは異なる鍵ペアであることがセキュリティ上は望ましい。しかしながら、従来技術ではログイン端末において、複数の認証鍵ペアそれぞれを適切に使い分けることが出来なかった。本発明は、上記課題を鑑みてなされたものであり、複数の認証鍵ペアを適切に使い分け、セキュリティを向上させることが可能な情報処理装置を提供することを目的とする。

本発明は、複数の認証鍵ペアを用いてサービス提供装置にログインする情報処理装置であって、前記サービス提供装置への複数のリクエストと前記サービス提供装置からの複数のレスポンスとによって通信する通信手段と、前記複数のリクエストの種類に応じて、複数のセキュリティクラスを設定する設定手段と、前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いることを制限する制限手段と、を有することを特徴とする。

本発明によれば、複数の認証鍵ペアを適切に使い分け、セキュリティを向上させることが可能な情報処理装置を提供することが出来る。

認証システムの概要構成を示すブロック図 ログイン端末が利用するコンテンツの一例を示す図 認証鍵の利用状態を表現する鍵テーブルの一例を示す図 認証鍵利用条件の設定画面の一例を示す図 認証デバイスの認証鍵をサービス提供装置１０２に登録する処理の一例を示すフローチャート ログイン端末１０１によるサービス提供装置１０２のサービス利用処理の一例を示すフローチャート ログイン端末１０１による認証子生成処理の一例を示すフローチャート 鍵テーブル３０１の状態遷移の一例を示すシーケンス図

以下、添付の図面を参照して、本実施形態について詳細に説明する。なお、以下の実施例において示す構成は一例に過ぎず、本実施形態は図示された構成に限定されるものではない。

また、本実施形態においては、暗号化，復号，ハッシュ処理などを以下のような記法で記載する。以降、暗号技術に関連する処理、データを以下の記述規則によって記載する。暗号化処理Ｃ＝Ｅｎｃ（Ｋ，Ｐ）は秘密鍵Ｋを使って平文Ｐを暗号化し、暗号文Ｃを取得する。秘密鍵Ｋは対象鍵暗号方式の鍵でもよいし、非対称鍵暗号鍵方式の鍵（通常は公開鍵）でもよい。復号処理Ｐ＝Ｄｅｃ（Ｋ，Ｃ）は鍵Ｋを使って暗号文Ｃを復号し、平文Ｐを得る。ここで、ＲＳＡなどの非対称鍵暗号方式ではＫは通常は秘密鍵である。一方、署名処理Ｓ＝Ｓｉｇｎ（Ｋ，Ｄ）はデータＤに対して鍵ペアＫの秘密鍵で署名処理し、ディジタル署名Ｓを得る。Ｍａｃ （Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）の生成処理はＳ＝Ｍａｃ（Ｋ，Ｄ）と記述し、これは秘密鍵ＫでデータＤへのＭａｃ値Ｓを取得する。ディジタル署名及びＭａｃ値の検証処理はＶｅｒｉｆｙ（Ｋ，Ｓ）と記述する。Ｓがディジタル署名の場合はＫはＲＳＡ鍵ペアＫの公開鍵、ＳがＭａｃ値の場合にはＭａｃ値の生成に利用した秘密鍵ＫによってＳの完全性を検証する。検証処理の結果は成功或いは失敗となる。一方で、暗号化されたデータについては｛Ｄａｔａ｝Ｋは鍵ＫでＤａｔａが暗号化されていることを示す。ＫがＲＳＡなどの非対称鍵暗号方式の場合には、鍵ペアＫの公開鍵で暗号化されていることを示す。また、演算子“｜”はデータの連結を表し、さらにハッシュ関数内の“｜｜”はハッシュ処理の連鎖を表す。つまり、２つのデータＤ１及びＤ２のハッシュ演算はＨａｓｈ（Ｄ１｜｜Ｄ２）＝Ｈａｓｈ（Ｈａｓｈ（Ｄ１）｜Ｄ２）である。

一方、データの記載方法についてはＲＳＡなどの非対称鍵暗号アルゴリズムを利用した署名データは｛Ｄａｔａ｝Ｋ＾−１と示し、Ｄａｔａが鍵ペアＫの秘密鍵で署名（暗号化）されていることを示す。最後に、Ｃｅｒｔ｛ＩＤ，Ｋ｝ｃａはＣＡによって発行された証明書であり、公開鍵Ｋを保持する主体がＩＤで示される主体（例えばＵＲＬ）であることをＣＡが証明していることを示す。

＜システムの構成＞
図１に、本実施形態におけるＰＣやスマートフォンに代表されるログイン端末１０１（情報処理装置）において、サービス提供装置１０２が提供するリモートサービスシステムを利用するシステムの構成例を説明する。本システムの目的はサービス提供装置１０２がログイン端末１０１の利用者をユーザ認証し、ログイン端末１０１を通して正当なユーザにサービス提供を行うことである。例えば、サービス提供装置１０２はオンラインバンクや証券会社などの金融サービス，商品の購入や販売を行うサービスを提供する。このようなサービスにおいては利用するユーザを正しく認証し、適切なアクセス制御を行うことが重要である。

ログイン端末１０１は利用者の操作に応じてサービス提供装置１０２と通信を行い、サービス提供装置１０２が提供するサービスを利用する。ログイン端末１０１は、コンピュータプログラムを用いて動作する通常のパーソナルコンピュータでも構わない。ログイン端末１０１とサービス提供装置１０２の間のデータ通信は、イーサネット（登録商標）等の有線ＬＡＮなどを介して行ってもよいし、無線ＬＡＮ技術を利用してもよい。また、ログイン端末１０１はクライアントソフトがＨＴＴＰ／ＨＴＴＰＳプロトコルによるデータ通信を行ってもよいし、専用のプロトコルを利用したデータ通信を行ってもよい。クライアントソフトはウェブブラウザや専用のアプリケーションによって実現することも可能である。以降、ウェブブラウザがＨＴＴＰ／ＨＴＴＰＳを使ってサービス提供装置１０２と通信する場合における説明を行うが、本実施形態はアプリケーションの種類やプロトコルに限定するものではない。

なお、本システムにおけるログイン端末１０１及びサービス提供装置１０２は、一般に使われる汎用ＰＣ，モバイルフォンやスマートフォンなどの計算装置で実現することが可能である。これらのデバイスは、ＣＰＵ，メモリ（ＲＡＭ），ＨＤＤやＳＳＤ，フラッシュメモリなどのストレージから構成される汎用的な演算装置であるため、詳細な説明は省略する。

＜ログイン端末１０１＞
図１におけるログイン端末１０１のソフトウェア構成の一例について説明する。ログイン端末１０１はユーザがサービス提供装置１０２のサービスを利用するために操作する端末である。ログイン端末１０１は通信監視部１０５，通信処理部１０６，認証子生成部１０７，複数の認証デバイス（１０８〜１１０），鍵管理表記憶部１１１及び制限条件記憶部１１２から構成される。本実施例における複数の認証デバイスは、指紋でユーザ認証を行う認証デバイスＡ（１０８），顔画像でユーザ認証を行う認証デバイスＢ（１０９）及びＰＩＮ入力でユーザ認証を行う認証デバイスＣ（１１０）から構成される。

通信処理部１０６はサービス提供装置１０２とデータ通信を行う処理を行う。例えばウェブブラウザであれば、ユーザの指示したＵＲＬに対してページの取得要求を送信し、サービス提供装置１０２から返信されたコンテンツを描画する。返信されるコンテンツはＨＴＭＬ形式の文書や画像データであるが、ＨＴＴＰヘッダなどの制御情報が付加されることが通常である。受信データにユーザ認証の要求が含まれている場合には、要求に含まれるチャレンジデータに対して認証子生成部１０７で署名データ（認証子）を生成し、サービス提供装置１０２に送信する。チャレンジデータに対するディジタル署名処理は、サービス提供装置１０２から鍵の識別子によって指定された認証デバイスで行ってもよいし、ユーザが選択した認証デバイスで行ってもよい。いずれの場合においても、通信処理部１０６は認証子生成部１０７が生成した署名データをサービス提供装置１０２に送信する。認証子の生成処理についての詳細は後述する。本実施例においてログイン端末１０１が処理するコンテンツの一例を図２に示す。図２はユーザの送金要求を受け付けるＨＴＭＬコンテンツの一致例であり、２０１はログイン端末における画面表示を、２０２は画面表示に用いられるＨＴＭＬデータを示す。画面２０１ではユーザに対して送金額及び送金先の入力を促す。この画面において入力ボックスにユーザが送金額を入力し、“送金”と示されたボタンを押すことにより、サービス提供装置１０２に送金処理の要求が行われる。この画面表示に対するＨＴＭＬデータ２０２では、実際にサービス提供装置１０２に対して送信されるリクエストを構成するための情報が記述されている。例えば“ｆｏｒｍ”タグの“ａｃｔｉｏｎ”属性によって、リクエストを送信するＵＲＬが指定される。また、“ｎａｍｅ”属性に“ａｍｏｕｎｔ”と指定された“ｉｎｐｕｔ”タグによって、ユーザが入力する送金額が設定される。“ｎａｍｅ”属性に“ｂｒａｎｃｈＩＤ”及び“ａｃｃｏｕｎｔＩＤ”が指定されたストボックスは、それぞれ送金先の支店名と口座番号を示す。ここで、サービス提供装置１０２からログイン端末への認証要求は、本コンテンツがサービス提供装置１０２からログイン端末１０１に送られるようにしてよい。また、ユーザが“送金”ボタンを押すことにより発生するリクエストへの応答として送ってもよい。前者の場合には、画面２０１で表現されるページにアクセスするためにユーザ認証が行われる。

通信監視部１０５は通信処理部１０６とサービス提供装置の間のデータ通信を監視し、通信データにユーザ認証に関わるデータが含まれていた場合には制限条件記憶部１１２に保持された認証鍵の制限条件に応じた制御を行う。ユーザ認証が制限条件を逸脱する方法で行われる場合には、ユーザへの警告ダイアログの表示や通信の遮断などによって通信データがサービス提供装置１０２に送信されることを防止する。通信監視部１０５は様々な実装形態が考えられるが、ウェブブラウザのプラグインとして実装されてもよいし、ウェブブラウザとは別のユーザプロセスとして実装されてもよい。或いは、オペレーティングシステムにおけるネットワークトラフィックを監視するようなソフトウェアモジュール、或いはハードウェア回路として実装することも可能である。

認証子生成部１０７は通信処理部１０６から渡される認証要求に含まれるチャレンジデータに対してディジタル署名による認証子の生成を行う。具体的には認証子生成部１０７はチャレンジに対して認証デバイスＡ（１０８），認証デバイスＢ（１１０）乃至認証デバイスＣ（１１０）のいずれか／或いは複数の認証デバイスによって署名データを生成し、通信処理部１０６に返す。チャレンジに対するディジタル署名処理は、通信処理部１０６から指定された認証デバイスによって行う。

認証デバイスＡ（１０８），認証デバイスＢ（１０９）及び認証デバイスＣ（１１０）は、サービス提供装置１０２にログインするための認証鍵ペアをそれぞれ保持する。それぞれの認証デバイスはログイン端末１０１を操作するユーザの指示に従って認証鍵ペアの秘密鍵で入力データ（チャレンジデータ）に対してディジタル署名処理を行う。認証デバイスは認証鍵ペアによるディジタル署名処理を行う前にログイン端末を操作するユーザを認証し、正当なユーザによる操作であると判断した場合にディジタル署名処理を許可する。例えば、認証デバイスがユーザを認証する方法としては既存の認証処理を利用することが可能である。例えば、ユーザの生体認証を用いる場合は指紋，静脈，音声などのセンサー入力によってユーザを認証する。或いは、ユーザの知識を用いる場合はパスワードやＰＩＮコード、ユーザの所有物であればＩＣカードやＵＳＢトークンが用いられる。或いは、認証デバイスはログイン端末が正常なソフトウェア構成であるかを端末起動時に計測されるモジュールハッシュ値によって、ディジタル署名の可否を判断してもよい。ソフトウェア構成を用いた署名の判断については、Ｔｒｕｓｔｅｄ Ｂｏｏｔと呼ばれるＴＰＭ（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）を利用したブート処理が広く知られているため、詳細の説明は省略する。いずれにおいても、各々の認証デバイスは予め定められた条件を満たした場合に、管理する認証鍵ペアの秘密鍵によるディジタル署名を行う。

鍵管理表記憶部１１１はログイン端末１０１の認証デバイスで管理される認証鍵ペアの利用状態を管理する。本実施例における鍵管理表記憶部１１１で管理されるテーブルの一例を図３に示す。図３において、鍵テーブル３０１はログイン端末１０１において利用される認証鍵の管理表を示す。認証鍵の管理表は、後述する制限条件記憶部１１２が保持する認証鍵利用条件１１３の条件適用可否を判定するために利用される。

鍵テーブル３０１においてサービスＩＤ列３０２はログイン端末１０１が利用するサービスの識別子を示し、例えばサービス提供装置１０２のドメイン名を示す。サービス１を提供するサービス提供装置１０２はｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ，サービス２を提供するサービス提供装置１０２はｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ２．ｃｏｍのドメイン名で識別される。

ＫｅｙＩＤ列３０３はログイン端末１０１が利用する認証デバイスの認証鍵を識別する。例えば、鍵テーブル３０１では、サービス１にＫｅｙ１，Ｋｅｙ２及びＫｅｙ３で識別される認証鍵が登録されており、それぞれの認証鍵は指紋認証，顔認証，ＰＩＮコードでユーザ認証を行う認証デバイスで管理されている。また、サービス２にはＫｅｙ４で識別される認証鍵が登録され、指紋認証を行う認証デバイスで登録されている。

鍵テーブル３０１におけるセキュリティクラス列３０４は、サービスＩＤ列３０２で識別されるサービス提供装置１０２が提供する機能の分類を示す。本実施形態におけるセキュリティクラスとは、認証デバイスで管理する認証鍵が利用されるサービス機能の集合を表す。本実施形態における鍵テーブル３０１では、セキュリティクラスを表現する一例としてＵＲＬによって機能の分類を行っている。例えば、サービス１はログイン機能をｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ／ｌｏｇｉｎ．ｃｇｉで識別されるＵＲＬ１で、送金機能をｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ１．ｃｏｍ／ｔｒａｎｓｆｅｒ．ｃｇｉで提供されるＵＲＬ２で提供する。サービス機能はＵＲＬによって識別してもよいし、ＵＲＬとそれに付随するパラメータを利用して識別してもよい。つまり、図２で例示したウェブコンテンツではログイン端末１０１が送信するリクエストはＵＲＬに加えてＰＯＳＴメソッドのパラメータ（“ｂｒａｎｃｈＩＤ”，“ａｃｃｏｕｎｔＩＤ”，“ａｍｏｕｎｔ”）を使って識別してもよい。これにより、同一ＵＲＬにおいて複数のサービス機能を提供している場合においてもセキュリティクラスを適切に識別することが可能となる。

制限条件記憶部１１２はデバイスに予め設定された、或いはユーザによって設定された認証鍵利用条件１１３を記憶する。本実施形態における認証鍵利用条件１１３とは、認証デバイスにおいて管理される認証鍵の利用条件を鍵テーブル３０１におけるセキュリティクラスと対応付けて定義したものである。図４にユーザが設定する認証鍵利用条件１１３の設定画面の一例を示す。画面４０１では一つの認証鍵ペアを使いまわすことのできるセキュリティクラスの数を設定しており、２回以上使いまわされる場合はユーザに警告を、５回以上で利用をブロックすることを示す。後述のように、本実施形態における制限条件は回数による制限に限定されることはなく、Ｃｏｏｋｉｅに含まれる認証セッション情報を元にクラス分類し、制限を行うことも可能である。

＜サービス提供装置１０２＞
サービス提供装置１０２はログイン端末１０１を操作するユーザに対してサービス提供を行う処理装置である。サービス提供装置１０２は通信処理部１０３及び認証鍵管理部１０４によって構成される。

通信処理部１０３はサービスの処理ロジックに従ってログイン端末からのサービス要求（リクエスト）に対する応答を返す。本実施形態におけるサービス提供装置１０２は、必要に応じてログイン端末１０１を操作するユーザを認証し、適切なアクセス制御を行う。通信処理部１０３に実装される処理ロジックはオンラインバンクなどの金融サービス、商品の売買をユーザに提供する。ユーザ認証が必要なコンテンツへのアクセス要求があった場合には、通信処理部１０３はログイン端末１０１に対してユーザ認証要求とチャレンジを送信する。チャレンジに対するディジタル署名がログイン端末から返された場合には、後述する認証鍵管理部１０４で管理するユーザの認証鍵ペアの公開鍵で検証を行う。ディジタル署名の検証に成功した場合にはリクエストが正当なユーザから送信されたものであると判定し、サービスの提供を行う。検証に失敗した場合にはエラーコードなどを返すことによってサービスの提供を中止する。

認証鍵管理部１０４は、ログイン端末１０１が登録した認証鍵をユーザと対応付けて管理する。例えば、ユーザＸとしてサービスを利用するために必要な認証鍵ペアの公開鍵を記憶する。サービス提供装置１０２は、チャレンジに対して送り返された署名データ（認証子）がユーザＸと対応付けられた公開鍵で正しく検証できれば、ユーザ認証を成功と判定する。

＜認証鍵登録処理＞
図５は、ログイン端末１０１がサービス提供装置１０２に認証デバイスの認証鍵ペアを登録する処理の一例を示したフローチャートである。この登録処理によって、サービス提供装置１０２は、ログイン端末１０１に備えられた認証デバイスで管理される認証鍵ペアの公開鍵をユーザに対応付けることができる。

まず、ユーザはログイン端末１０１を用いてサービス提供装置１０２にログインする（Ｓ５０１）。ログインはパスワードを利用してもよいし、サービスに公開鍵を登録済みの認証デバイスがログイン端末１０１に備えられていれば、その認証鍵ペアを利用してもよい。

ログイン端末１０１に登録が必要な認証デバイスがあれば（Ｓ５０２−Ｙｅｓ）、サービス提供装置１０２に認証デバイスの登録要求を送信し（Ｓ５０３）、応答としてサービス提供装置１０２からチャレンジデータを受信する（Ｓ５０４）。ログイン端末１０１に登録が必要な認証デバイスがなければ（Ｓ５０２−Ｎｏ）、認証デバイスの登録処理を終了する。チャレンジデータを受け取ったログイン端末１０１は認証鍵ペアを生成し、Ｓ５０４で受信したチャレンジデータに認証鍵ペアの秘密鍵でディジタル署名処理を行う（Ｓ５０５）。続いてログイン端末１０１は、鍵管理表記憶部１１１に記憶した鍵テーブルに対して新しく登録した認証鍵を追加する（Ｓ５０６）。

以上、ログイン端末１０１に備えられた認証デバイスの認証鍵ペアをサービス提供装置１０２に登録する処理のフローを説明した。本ステップによって、ログイン端末１０１は認証デバイスで管理する認証鍵ペアをサービス提供装置１０２に登録することができる。以降は登録された認証鍵ペアの秘密鍵でサービス提供装置１０２からのチャレンジに署名をすることで、ユーザはパスワードを利用することなくログイン処理を行うことが可能である。

＜ログイン処理＞
図６は、ログイン端末１０１が認証デバイスで管理された認証鍵を用いてサービス提供装置１０２にログインする処理の一例を示したフローチャートである。

まず初めに、ユーザがログイン端末１０１におけるアプリケーションを起動する（Ｓ６０１）。例えば、本実施形態におけるアプリケーションとはウェブコンテンツにアクセスするウェブブラウザであり、ログイン端末１０１における通信処理部１０６で実行される。通信処理部１０６は、ＨＴＴＰ／ＨＴＴＰＳのプロトコルを介してサービス提供装置１０２とネットワーク通信を行う。ネットワーク通信はサーバ提供装置へのコンテンツリクエスト送信処理（Ｓ６０２）と、サービス提供装置１０２からのレスポンス受信処理（Ｓ６０３）によって行う。Ｓ６０２でリクエストを送ったコンテンツへのアクセス対してサービス提供装置１０２がアクセス制限を行っている場合には、サービス提供装置１０２はレスポンスにユーザ認証を促す要求を付与する。ユーザ認証要求は、ＨＴＴＰヘッダなどの通信プロトコルのパラメータとしてログイン端末１０１へ渡されてもよいし、ログインフォームなどのＨＴＭＬコンテンツとして渡されてもよい。レスポンスに認証要求が含まれている場合には（Ｓ６０４−Ｙｅｓ）、後述の認証子（署名データ）の生成を行い（Ｓ６０５）、サービス提供装置１０２へ返信する。サービス提供装置１０２からのレスポンスに認証要求が含まれていない場合には（Ｓ６０４−Ｎｏ）、レスポンスをウェブブラウザなどのアプリケーションで処理してユーザに提供する（Ｓ６０６）。通信処理部１０６におけるアプリケーションは、上記のＳ６０２〜Ｓ６０６の処理ステップを繰り返すことによってサービス提供装置１０２と通信する（Ｓ６０７−Ｎｏ）。ユーザが終了を指示した場合には（Ｓ６０７−Ｙｅｓ）アプリケーションの終了処理を行う（Ｓ６０８）。

以上、ログイン端末１０１によるサービス提供装置１０２との通信処理とログイン処理の一連の流れについて説明した。なお、本実施形態はアプリケーションがウェブブラウザである場合だけではなく、ＡｎｄｒｏｉｄやｉＯＳ上で実行されるモバイルアプリケーション，汎用ＰＣ上のアプリケーションなどにおいて実施することも可能である。

＜認証子（署名）の生成処理＞
図７は、フローチャート図６における処理ステップＳ６０５におけるログイン端末１０１でのログイン認証子の生成処理の一例を示したフローチャートである。前述の通り、認証子の生成は通信処理部１０６が受け取ったレスポンスにユーザ認証要求が含まれることをトリガとして開始される。本フローチャートにおける一連の処理の目的は、認証要求に含まれるチャレンジデータに対して認証子生成部１０７がディジタル署名を施し、サービス提供装置１０２に対してユーザ認証を行うことである。

まず初めに、通信処理部１０６が送受信する通信データを監視する通信監視部１０５がリクエストデータを基にセキュリティクラスを分類する（Ｓ７０１）。セキュリティクラスはログイン端末１０１から送信されるリクエストに基づいて分類される。セキュリティクラスの分類については図３を用いて説明済みであるため、詳細な説明は省略する。

通信監視部１０５は、鍵管理表記憶部１１１で管理される鍵テーブルと、制限条件記憶部１１２に保持される認証鍵利用条件１１３を用いて認証要求で指定される認証鍵の利用可否を判断する（Ｓ７０２）。利用条件内と判定されなかった場合には（Ｓ７０２−Ｎｏ）、通信監視部１０５が認証鍵の利用を制限する処理を行う（Ｓ７０７）。制限処理とは、例えば認証要求をＳ７０３〜Ｓ７０６認証処理の実行を防止（ブロック）する方法や、Ｓ７０３〜Ｓ７０６の認証処理の前にユーザに警告画面を表示する方法がある。利用条件内と判定された場合には（Ｓ７０２−Ｙｅｓ）、通信処理部１０６が受け取った認証要求に含まれるチャレンジデータが認証子生成部１０７によって処理される。認証子生成部１０７はチャレンジデータに署名を行う認証鍵ペアを管理する認証デバイスを選択し、チャレンジデータへのディジタル署名処理を要求する。選択された認証デバイスは予め定められたユーザ認証を実行し、ログイン端末１０１を操作するユーザが正当なユーザであることを識別した後（Ｓ７０３）、管理する認証鍵ペアの秘密鍵でチャレンジデータにディジタル署名を行う（Ｓ７０４）。認証デバイスがログイン端末１０１を操作するユーザを識別する方法は、指紋や静脈などの生体認証を用いるものでもよいし、ＰＩＮコードなどのユーザの知識を利用したものでもよい。

続いて、生成された認証子は通信処理部１０６を介してサービス提供装置１０２に送信される（Ｓ７０５）。通信監視部１０５は、鍵管理表記憶部１１１で管理される鍵テーブルに対して、認証子を生成した認証鍵の識別子とセキュリティクラスを対応付けて更新する（Ｓ７０６）。

以上、ログイン端末１０１による認証子の生成処理のステップを説明した。これにより認証デバイスが複数のセキュリティクラスに分類されるサービス処理に対して利用されることを防止することが可能になり、ユーザが認証デバイスを用いて不用意に認証処理を実行してしまうリスクが軽減される。

＜鍵管理表の更新過程＞
図８は、鍵管理表記憶部１１１における鍵テーブル３０１の更新を、ログイン端末１０１における認証デバイスでの認証履歴と対応付けて説明するシーケンス図の一例である。本シーケンスの説明は、認証鍵利用条件１１３として「認証鍵を２つ以上のセキュリティクラスに利用する場合はブロックする」という制限が設定されているものとする。また、セキュリティクラスはＵＲＬを単位として分類されるものとする。

鍵テーブル８０１は、図５で説明した認証デバイスの鍵登録処理後（Ｓ５０６）の鍵テーブル構成の一例である。ログイン端末１０１は３つの認証デバイスを備え、指紋認証で制御されるＫｅｙ１，顔認証で制御されるＫｅｙ２，ＰＩＮ入力で制御されるＫｅｙ３の３つの認証鍵をサービス１に登録している。鍵テーブル８０１で示すように、認証鍵登録後は認証鍵が未使用であるために各認証鍵のセキュリティクラスは未設定となっている。

続いて、サービス提供装置１０２が提供するＵＲＬ１で識別されるＵＲＬにログイン端末１０１がリクエストを送信すると、レスポンスとしてユーザ認証要求が返信される。この認証要求に対し、ログイン端末１０１は指紋認証で管理された認証鍵Ｋｅｙ１を利用してユーザ認証を行う。結果、鍵テーブル８０２のように、Ｋｅｙ１のセキュリティクラスにＵＲＬ１が対応付けられる。

さらに、ログイン端末１０１が送金手続きを行うためにＵＲＬ２にアクセスし、サービス提供装置１０２からユーザ認証要求を含んだレスポンスを受け取る。ここで、ログイン端末１０１がＵＲＬ２へアクセスするための認証デバイスとして再びＫｅｙ１を管理する指紋認証デバイスを利用した場合、鍵テーブル８０４のようにＫｅｙ１がＵＲＬ１とＵＲＬ２の認証に利用される状態になる。このため、認証鍵利用条件１１３に反することになるため、通信監視部１０５が認証鍵Ｋｅｙ１の利用をブロックする。一方で、顔認証デバイスで管理されるＫｅｙ２でＵＲＬ２にアクセスした場合には、鍵テーブル８０３のように一つの認証鍵が複数のセキュリティクラス（ＵＲＬ）に利用されることはない。このため、通信処理部１０６は通常の認証処理としてサービス提供装置１０２へのログインを行う。

以上、図８における認証鍵利用シーケンスの説明をした。上記のように、通信監視部１０５は通信データのリクエスト及びそのレスポンスを監視し、認証鍵が認証鍵利用条件１１３に従って利用されることを強制する。これにより、ユーザが意図せずに単一の認証デバイスで複数のセキュリティクラスのサービスへの認証を行うことを防止することが可能となる。

以上、本実施形態におけるログイン端末１０１とサービス提供装置１０２の構成及び処理ステップを説明した。本実施形態は、説明した装置構成での実現に限定されず、異なる装置構成に情報処理方法を適用することも可能である。例えば、認証デバイスをログイン端末１０１の外部に設け、無線／有線インターフェースで接続すること形態も可能である。なお、本実施形態においては図８で示したように、認証鍵登録時には鍵テーブル８０１で示したようにどの認証鍵とセキュリティクラスの対応が行われていない場合を用いて説明行った。これは、一般に使われているウェブサービスが提供セキュリティクラスに関する定義情報を配布していないような用途で広く適用可能であるという点で利便性が高い。しかしながら、本実施形態はこれに限定することなく、例えばサービス提供装置１０２がＵＲＬとセキュリティクラスの対応鍵テーブルを予め配信することで実現することも可能である。これにより、ログイン端末１０１はセキュリティクラスの定義をより正確に把握することができることになり、より適切な認証鍵の利用制御を行うことが可能となる。或いは、認証鍵登録時に認証デバイスのセキュリティクラスをユーザが選択することも可能である。この場合は、ユーザはログインなどの通常のセキュリティクラスに対する認証は指紋認証デバイスで、送金などの重要処理は顔認証で認証を行うなどのユーザの好みに応じた認証デバイスを設定できる。

また、セキュリティクラスの識別方法は、本実施形態で説明したようにＵＲＬを基準としたものに限定する必要はなく、サービスの状態に基づいたものでもよい。つまり、ウェブサービスの認証状態を管理する代表的な手段としてＣｏｏｋｉｅがあるが、このＣｏｏｋｉｅの状態に応じてセキュリティクラスを定義してもよい。この場合、例えばユーザ認証されていない状態を一つのセキュリティクラスとし、ユーザ認証がされた常態を別のセキュリティクラスとする。通常はユーザ認証が済みのセキュリティクラスに遷移するに際してユーザ認証が行われるため、鍵テーブル３０１では認証済みのセキュリティクラスに遷移するために利用される認証鍵（ＫｅｙＩＤ）及び認証デバイスが管理される。

上記実施形態はウェブブラウザとブラウザがアクセスするサービスのＵＲＬを元にした認証鍵ペアの利用制限を一例として説明したが、これに制限されることはなく、様々なアプリケーションにて協可能である。例えば、通信処理部１０６はＪａｖａ（登録商標）言語で記述されたモバイルアプリケーションなどとすることも可能である。この場合には、ＵＲＬだけではなくモバイルアプリケーションの画面遷移状態（Ｉｎｔｅｎｔ）や内部状態を利用してセキュリティクラスを定義することが可能である。

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

Claims (9)

1. 複数の認証鍵ペアを用いてサービス提供装置にログインする情報処理装置であって、
   前記サービス提供装置への複数のリクエストと前記サービス提供装置からの複数のレスポンスとによって通信する通信手段と、
   前記複数のリクエストの種類に応じて、複数のセキュリティクラスを設定する設定手段と、
   前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いることを制限する制限手段と、を有することを特徴とする情報処理装置。
2. 前記複数のセキュリティクラスは、前記リクエストに含まれるＵＲＬもしくはパラメータの種類により設定されていることを特徴とする請求項１に記載の情報処理装置。
3. 前記複数のセキュリティクラスは、前記リクエストを発行するアプリケーションの状態に応じて設定されていることを特徴とする請求項１に記載の情報処理装置。
4. 前記複数のセキュリティクラスは、前記認証鍵ペアの認証履歴に応じて設定されていることを特徴とする請求項１に記載の情報処理装置。
5. 前記認証履歴には、顔認証、指紋認証、ＰＩＮ入力の認証の少なくとも一つが含まれていることを特徴とする請求項４に記載の情報処理装置。
6. 前記複数のセキュリティクラスは、ユーザの指示に基づき設定されることを特徴とする請求項１に記載の情報処理装置。
7. 前記制限手段は、前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いる回数を制限することを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
8. 複数の認証鍵ペアを用いてサービス提供装置にログインする情報処理方法であって、
   通信手段が、前記サービス提供装置への複数のリクエストと前記サービス提供装置からの複数のレスポンスとによって通信する通信工程と、
   設定手段が、前記複数のリクエストの種類に応じて、複数のセキュリティクラスを設定する設定工程と、
   制限手段が、前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いることを制限する制限工程と、を有することを特徴とする情報処理方法。
9. コンピュータを、
   複数の認証鍵ペアを用いてサービス提供装置にログインする情報処理装置であって、
   前記サービス提供装置への複数のリクエストと前記サービス提供装置からの複数のレスポンスとによって通信する通信手段と、
   前記複数のリクエストの種類に応じて、複数のセキュリティクラスを設定する設定手段と、
   前記複数の認証鍵ペアの少なくとも一つを、前記複数のセキュリティクラスの少なくとも一つに対応するリクエストの通信に用いることを制限する制限手段と、を有することを特徴とする情報処理装置として機能させるためのコンピュータプログラム。

Images