JP7843944B1 - 情報処理システム、プログラム、認証方法 - Google Patents

Abstract

サーバは、チャンレジデータを発行し、クライアントに送信する。クライアントは、サーバ鍵で暗号化された暗号化データを複数含む暗号化群データ、および、パラメータデータＡをメモリに記憶し、チャレンジデータを受信し、クライアント側レスポンスキーを用いてレスポンスデータの生成を行い、サーバに、レスポンスデータ、暗号化群データ、および、パラメータデータＡの送信を行う。サーバは、受信したパラメータデータＡに基づいて、受信した暗号化群データのうち使用する暗号化データを選択し、選択した暗号化データをサーバ鍵で復号化したデータに基づいてサーバ側レスポンスキーの設定を行い、チャレンジデータとサーバ側レスポンスキーに基づいて、受信したレスポンスデータの検証を行い、クライアントに検証結果を通知する。クライアントは当該通知を受信する。

Description

本開示は、チャレンジ＆レスポンス方式を利用するデバイス認証方法に関する。

従来から、クライアントデバイスを認証するための手法として、チャレンジ＆レスポンス方式による認証方法が知られている（例えば、非特許文献１）。

ＲＦＣ Ｅｄｉｔｏｒ、"ＲＦＣ７６１６"、［online］、［令和６年８月２９日検索］、インターネット（ＵＲＬ：https://www.rfc-editor.org/info/rfc7616）

上記チャレンジ＆レスポンス方式を利用するデバイス認証方法について、新たな方法を提供する余地があった。

上記の点に鑑みて、例えば以下のような構成例が挙げられる。

（構成１）
構成１は、ネットワークに接続されたクライアント、および、サーバを備え、クライアントおよびサーバとの間で、チャレンジ＆レスポンス方式によりクライアントの認証処理を行う、情報処理システムである。
上記サーバ（サーバ群の意味であり、チャンレジデータを発行し、クライアントに送信するサーバ装置と異なるサーバ装置であってもよい）は、チャンレジデータを発行し、クライアントへの送信を行う手段を備える。
上記クライアントは、所定のサーバ鍵で暗号化された暗号化データを複数含む暗号化群データ、および、パラメータデータＡを記憶するメモリと、チャレンジデータの受信を行う手段と、クライアント側のレスポンスキーを用いて、受信されたチャレンジデータからレスポンスデータの生成を行う手段と、サーバに、生成されたレスポンスデータ、暗号化群データ、および、パラメータデータＡの送信を行う手段とを備える。
上記サーバは、さらに、レスポンスデータ、暗号化群データ、および、パラメータデータＡの受信を行う手段と、受信したパラメータデータＡに基づいて、受信した暗号化群データのうち使用する暗号化データの選択を行う手段と、選択された暗号化データをサーバ鍵で復号化し、復号化したデータに基づいて、サーバ側のレスポンスキーの設定を行う手段と、チャレンジデータと上記設定されたサーバ側のレスポンスキーに基づいて、受信されたレスポンスデータの検証を行う手段と、クライアントに検証の結果の通知を行う手段とを備える。
上記クライアントは、さらに、検証の結果を受信を行う手段を備える。

上記構成によれば、クライアントから複数の暗号化データを含む暗号化群データを送信するとともに、クライアントからパラメータデータＡを送信して、パラメータデータＡにより複数の暗号化データの中から暗号化データを選択してサーバ側のレスポンスキーが設定されるので、サーバ側のレスポンスキーのバリエーションを持たせることができる。
なお、パラメータデータＡは、署名されるデータ（例えば、後述の第１特定パラメータのようなデータ）であってもよいし、署名されないデータ（例えば、後述の第２特定パラメータのようなデータ）であってもよい。

（構成２）
構成２は、上記構成１において、暗号化群データと前記パラメータデータＡはまとめて署名がされるデータであり、サーバは、署名の検証を行う手段をさらに備え、上記選択は、検証が行われたパラメータデータＡに基づいて、上記受信した暗号化群データのうち使用する暗号化データを選択するように構成され、上記サーバ側のレスポンスキーの設定は、署名の検証が行われた暗号化データに基づいて行われるように構成されてもよい。

上記構成によれば、暗号化データの改ざんを防止するとともに、どの暗号化データを用いるかの情報の改ざんを防止できる。また、１つの署名で行われるので効率がよい。

（構成３）
構成３は、上記構成１または２において、暗号化群データは署名がされるデータであり、パラメータデータＡは署名がされないデータであってもよく、上記サーバは、署名の検証を行う手段をさらに備え、上記サーバ側のレスポンスキーの設定は、署名の検証が行われた暗号化データに基づいて行われるように構成されてもよい。

上記構成によれば、暗号化データの改ざんを防止するとともに、どの暗号化データを用いるかの決定に用いられる情報を後から設定できる。

（構成４）
構成４は、上記構成１ないし３のいずれかにおいて、暗号化群データに含まれる各暗号化データは、同一のマスターキーから生成される複数の派生鍵データであってもよい。

上記構成によれば、同一のマスターキーから生成される複数の派生鍵データの中から選択される派生鍵データによりサーバ側のレスポンスキーが設定されるので、サーバ側のレスポンスキーの設定に用いられる派生鍵のバリエーションを持たせることができる。

（構成５）
構成５は、上記構成１ないし４のいずれかにおいて、暗号化群データに含まれる各暗号化データは、マスターキーに加えて変動するパラメータ（以下、変動パラメータ）により、各暗号化データが異なるように生成される派生鍵データであってもよい。

上記構成によれば、変動パラメータにより複数の派生鍵データを生成するので、暗号化群データを効率的に生成することができる。

（構成６）
構成６は、上記構成１ないし５のいずれかにおいて、サーバは、パラメータデータＡと暗号化データとの対応関係を示すデータ（以下、対応関係データと呼ぶ）をさらに記憶するメモリを備え、上記選択は、対応関係データを参照して、パラメータデータＡに基づいて暗号化データを選択するように構成されてもよい。

上記構成によれば、パラメータデータＡと暗号化データの対応関係がサーバのデータで設定されるので、パラメータデータＡと暗号化データの対応付けを後から決められる。

（構成７）
構成７は、上記構成１ないし６のいずれかにおいて、暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであり、サーバは、さらに、受信したパラメータデータＡに基づいてサーバ鍵の特定処理を行う手段を備え、復号化は、特定されたサーバ鍵に基づいて行われるように構成されてもよい。

上記構成によれば、暗号化データごとに暗号化の鍵が異なるので、或る暗号化鍵が危殆化するようなことがあっても他の暗号化にまで影響が及ばず、セキュリティ上の回復力を備えることができる。また、暗号化データの選択に用いられるパラメータデータＡに基づいてサーバ鍵の特定も行うため、パラメータデータＡを有効活用することができる。

（構成８）
構成８は、上記構成１ないし６のいずれかにおいて、暗号化群データに含まれる各暗号化データは、サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を実行することにより生成されたデータであり、サーバ側のレスポンスキーの設定は、復号化したデータ、および、パラメータデータＡに基づいて、さらに所定の演算を行うことによってレスポンスキーを設定する処理であってもよい。

上記構成によれば、複数の演算によりレスポンスキーが設定されるため、予測が困難なレスポンスキーとすることができる。また、パラメータデータＡに基づいて、暗号化データの選択と２段階目の演算とが行われるため、パラメータデータＡを有効活用することができる。

（構成９）
構成９は、上記構成２において、メモリには、少なくとも暗号化群データ、パラメータデータＡ、および、非署名のパラメータデータＢがさらに記憶されてもよい。クライアントは、サーバに、パラメータデータＢを送信する手段をさらに備えてもよく、サーバにおける受信は、パラメータデータＢをさらに受信する処理であってもよい。サーバは、署名の検証を行う手段をさらに備え、上記選択は、署名の検証が行われたパラメータデータＡ、および、パラメータデータＢに基づいて、受信した暗号化群データのうち使用する暗号化データを選択するように構成されてもよい。

上記構成によれば、事前に署名することが容易なデータ（例えば、固定的なデータ）と、事前に署名することが困難なデータ（例えば、変化するデータ）の両方に基づいて、どの暗号化データを使用するか決定することができる。

（構成１０）
構成１０は、上記構成９において、暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであってもよく、サーバは、さらに、署名の検証が行われたパラメータデータＡ、および、パラメータデータＢに基づいてサーバ鍵の特定を行う手段を備えてもよく、復号化は、特定されたサーバ鍵に基づいて行われるように構成されてもよい。

上記構成によれば、事前に署名することが容易なデータ（例えば、固定的なデータ）と、事前に署名することが困難なデータ（例えば、変化するデータ）の両方に基づいてサーバ鍵の特定も行うことができる。

（構成１１）
構成１１は、上記構成９または１０において、サーバは、パラメータデータＡおよびパラメータデータＢと暗号化データの対応関係を示すデータ（以下、対応関係データと呼ぶ）をさらに記憶するメモリを備えてもよい。上記選択は、対応関係データを参照して、署名の検証が行われたパラメータデータＡおよびパラメータデータＢに基づいて暗号化データを選択するように構成されてもよい。

上記構成によれば、パラメータデータＡおよびＢと暗号化データの対応関係がサーバのデータで設定されるので、パラメータデータＡおよびＢと暗号化データの対応付けを後から決められる。また、事前に署名することが容易なデータ（例えば、固定的なデータ）と、事前に署名することが困難なデータ（例えば、変化するデータ）の両方に基づく処理とことができる。

（構成１２）
構成１２は、上記構成９ないし１１のいずれかにおいて、暗号化群データに含まれる各暗号化データは、サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を予め実行することにより生成されたデータであってもよい。サーバ側のレスポンスキーの設定は、復号化したデータ、パラメータデータＡ、および、パラメータデータＢに基づいて、さらに所定の演算を行うことによってレスポンスキーを設定する処理であってもよい。

上記構成によれば、事前に署名することが容易なデータ（例えば、固定的なデータ）と、事前に署名することが困難なデータ（例えば、変化するデータ）の両方に基づいてさらに演算を行ってサーバ側のレスポンスキーを設定も行うため、さらにセキュアなレスポンスキーの設定を行うことができる。

また、上記各構成例は、サーバとの間で、チャレンジ＆レスポンス方式により認証処理を行うクライアントのコンピュータを上記各手段として機能させるプログラムや、ネットワークに接続されたクライアントおよびサーバを備え、クライアントおよびサーバとの間でのチャレンジ＆レスポンス方式によるクライアントの認証方法に適用されてもよい。

本実施形態のシステムの全体像を示す模式図 レスポンスキー設定処理の概要を説明するための図 証明書作成処理の概要を示す図 証明書データＤ１０１の構成の一例 チャレンジデータセットの生成及び送信の処理の概要を示す図 チャレンジデータセットＤ１０２の構成の一例 レスポンスデータセットの生成処理の概要を示す図 クライアント３がサーバ１に送信するデータの一例 サーバ１におけるレスポンスキー設定処理の概要を示す図 カウンタ値特定テーブルＳＶ４０４のデータ構成の一例 第２ＫＤＦシードデータ特定テーブルＳＶ４０５のデータ構成の一例 検証処理の概要を説明するための図 クライアント３のハードウェア構成を示すブロック図 クライアント３の記憶部３２に記憶されるデータの一例 システムプログラムＣＬ２０１の機能的構成を説明するための図 サーバ１の記憶部１２に記憶されるデータの一例 ＰＣ４の記憶部４２に記憶されるデータの一例 証明書生成・書込処理のフローチャートの一例 チャレンジ発行セッションにおける処理の詳細を示す図 チャレンジ生成処理の詳細を示すフローチャート 検証セッションにおける処理の詳細を示す図 レスポンス生成処理の詳細を示すフローチャート 第１派生鍵設定処理の第１の例を示すフローチャート 第１派生鍵設定処理の第２の例を示すフローチャート 第２派生鍵設定処理の第１の例を示すフローチャート 第２派生鍵設定処理の第２の例を示すフローチャート レスポンスデータセット生成処理の詳細を示すフローチャート 検証処理の詳細を示すフローチャート 検証処理の詳細を示すフローチャート オンラインゲーム処理の詳細を示すフローチャート

以下、実施形態について説明する。

本実施形態は、デバイス認証にかかる処理に関する。本実施形態では、デバイスへ所定の通信サービスを提供したり、デバイスの所定の機能を実行可能にするにあたって（より、具体的には、例えば、オンラインサービスを提供する等（例えば、オンラインゲームや相手のマッチング、オンラインショップ（ソフトウェアやコンテンツのダウンロードサイト）へのアクセス等）にあたって）、デバイス認証を行う処理を例として説明する。デバイス認証において、クライアント装置（以下、単にクライアントと呼ぶ）の正当性が確認される。

本実施形態では、デバイス認証の手法として、チャレンジ＆レスポンス方式を用いる。この方式では、以下のような手法で認証が行われる。まず、図１に、本実施形態にかかる認証処理システムの全体的な構成を模式的に示す。図１では、クライアント認証サーバ（以下、単にサーバと呼ぶ）１と、クライアント装置（以下、単にクライアントと呼ぶ）３とがネットワークを介して接続されている。なお、サーバ１については、複数台のサーバ装置で構成されていてもよい。このような構成において、まず、（１）オンラインゲームの開始を希望するクライアント３がサーバ１（本実施形態では、オンラインゲームを提供するサーバとは異なる）にチャレンジデータの送信をリクエストする。（２）リクエストに応じて、サーバ１は、チャレンジデータを生成してクライアント３に送信する。（３）クライアント３は、チャレンジデータを元に所定の演算処理を行ってレスポンスデータを生成して、サーバ１に送信する。（４）サーバ１は、クライアントから受信したレスポンスデータを検証し、検証の成否に応じた所定のデータをクライアント３に送信することで、クライアント３の正当性の認証が行われる。複数台のサーバ装置で構成されるサーバの場合、上記（２）の処理を行うサーバ装置と（４）の処理をおこなうサーバ装置は異なることが許容されても良い。

次に、本実施形態における、チャレンジ＆レスポンス方式を用いたデバイス認証処理（以下、単に認証処理と呼ぶ）の概要を説明する。まず、認証処理で用いられる「レスポンスキー」に関して説明する。

［レスポンスキーについて］
レスポンスキーとは、レスポンスデータを作成する処理において用いられる鍵データである。サーバ１から受信したチャレンジデータに、このレスポンスキーを用いる演算を行うことでレスポンスデータが生成される。

図２は、本実施形態における、レスポンスキー設定処理の概要を説明するための図であり、当該処理におけるデータの流れを模式的に示すものである。図２では、楕円で示す要素はデータ・パラメータ的要素を示し、矩形で示す要素は処理的要素を示している。なお、説明の便宜上、図２では、データ・パラメータ的要素については、「Ｄｎｎ（ｎｎは整数）」の形式の参照符号を付している。以降、同様の図が出てくるが、これらについても同じように参照符号を付している。

図２に示す例では、鍵導出関数（key derivation function、以下、ＫＤＦと呼ぶ）を用いて、所定のデータから鍵データを生成して、生成した鍵データをレスポンスキーとして設定する。ここで、ＫＤＦとは、鍵データを元にして、別の鍵を生成するための関数である。鍵データと、シードデータと呼ばれる所定のデータをＫＤＦに入力すると、これらに基づいた別の鍵データが生成される。以下、ＫＤＦで出力された鍵データのことを「派生鍵」と呼ぶ。また、本実施形態では、複数段のＫＤＦ（本実施形態では、２段のＫＤＦ）を用いて生成される派生鍵データをレスポンスキーとして用いる。以下の説明では、１段階目のＫＤＦのことを「第１ＫＤＦ」、２段階目のＫＤＦのことを「第２ＫＤＦ」と呼び、第１ＫＤＦにより出力される鍵データを「第１派生鍵データ」または単に「第１派生鍵」と呼び、第２ＫＤＦにより出力される鍵データを「第２派生鍵データ」または単に「第２派生鍵」と呼ぶ。なお、各ＫＤＦの演算内容はどのようなものでもよいが、例えばＨＭＡＣまたはＣＭＡＣをＰＲＦとして使用するＫＤＦや、ハッシュ関数またはブロック暗号を使用するＫＤＦなどが挙げられる。また、各段のＫＤＦの演算内容は同じであってもよいし、異なってもよい。

図２を用いて、レスポンスキー設定の流れを説明する。レスポンスキーの設定処理は、サーバおよびクライアントのそれぞれで実行されるが、本実施形態では、後述するように、サーバで実行されるレスポンスキーの設定処理と、クライアントで実行されるレスポンスキーの設定処理には異なる点がある。図２では、クライアント３で実行されるレスポンスキーの設定処理を説明する。なお、クライアント３で設定されるレスポンスキーを「レスポンスキー（クライアント）」、サーバ１で設定されるレスポンスキーを「レスポンスキー（サーバ）」と呼ぶことがある。また、クライアント３で算出される第２派生鍵を「第２派生鍵（クライアント）」、サーバ１で算出される第２派生鍵を「第２派生鍵（サーバ）」と呼ぶことがある。

まず、クライアント３の記憶部には、マスターキーＤ０１、カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３、第２ＫＤＦシードデータＤ０４が記憶されている。マスターキーＤ０１は、第１ＫＤＦに入力される鍵データである。マスターキーＤ０１は、固定値のデータとして構成されていてもよいし、変更可能なデータとして構成されていてもよい。また、マスターキーＤ０１は、クライアントによって異なるデータであってもよい。クライアントをエミュレータ技術で実現する場合は、エミュレートする対象のマスターキーと同じデータであってもよい。

カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３、第２ＫＤＦシードデータＤ０４はそれぞれ、ＫＤＦのシードデータとして用いられるデータである。カウンタ値Ｄ０２は、クライアント３によって異なる値を取り得る。例えば、クライアント３のシステムのアップデート等に応じて変更され得る値であり、具体的には、１ずつインクリメントされる。本実施形態では、一例として、カウンタ値が０～３の４つの値のいずれかを取りうる場合を例として説明する。また、本実施形態では、カウンタ値Ｄ０２の初期値は０である。

第１ＫＤＦシードデータＤ０３は、第１ＫＤＦに入力されるシードデータであり、クライアント３によって異なる値を取り得る。第２ＫＤＦシードデータＤ０４は、第２ＫＤＦに入力されるシードデータであり、クライアント３によって異なる値を取り得る。これらのシードデータはどのようなデータでもよいが、例えば、第１ＫＤＦシードデータＤ０３は、固定値であってもよく、より具体的には、例えば、クライアント３の或る特性を示す識別データであってもよい。例えば、開発機または製品機のいずれかを示す識別データであってもよい。なお、クライアントをエミュレータ技術で実現する場合は、当該識別データは、エミュレートする対象の特性を示すデータであってもよい。また、第２ＫＤＦシードデータＤ０４は、クライアント３が、自ら、または、サーバ等の外部からの指示に応じて設定または変更可能なデータであってもよい。より具体的には、例えば、クライアント３の別の特性を示す識別データ（例えば、セキュリティ設定を示すデータ）であってもよい。また、システムバージョンに応じて異なるデータ（バージョンアップにより更新されるデータ）であってもよい。なお、クライアントをエミュレータ技術で実現する場合は、当該識別データは、エミュレートする対象の特性を示すデータであってもよい。また、各ＫＤＦシードデータＤ０３、Ｄ０４は、例えば、システムソフトウェアのアップデートにより変更されるものであってもよい。また、第１ＫＤＦシードデータＤ０３、第２ＫＤＦシードデータＤ０４は共に、クライアントによって異なる値となってもよい。

これらのデータのうち、まず、マスターキーＤ０１、（現在の）カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３が、第１ＫＤＦに入力される。その結果、第１ＫＤＦ演算により出力された派生鍵である「第１派生鍵」Ｄ０５が生成される。

次に、第２ＫＤＦシードデータＤ０４が、生成された第１派生鍵Ｄ０５と共に、第２ＫＤＦに入力される。これにより、第２ＫＤＦ演算により出力された派生鍵である「第２派生鍵（クライアント）」Ｄ０６が生成される。

そして、本実施形態では、第２派生鍵（クライアント）Ｄ０６がレスポンスキー（クライアント）として使用される。すなわち、本実施形態では、レスポンスキー（クライアント）の設定は、第２派生鍵の生成により行われ、後述するレスポンスデータセットＤ１０３を生成する処理に用いられる。

なお、レスポンスキー設定処理における各ＫＤＦの演算は、ランタイムで（すなわち、認証処理が行われる毎にその都度演算して）実行してもよいが、事前に演算した結果を記憶しておいて、認証処理が行われる際にそれを読み出すことで都度の演算をしないようにしてもよい。例えば、クライアント３のシステム起動時等に第１派生鍵データおよび／または第２派生鍵データを演算して記憶しておいて、認証処理が行われる際にそれを読み出すことでレスポンスキーを設定してもよい。また、例えば、演算済のデータ（第１派生鍵データおよび／または第２派生鍵データ）を外部から取得して記憶しておき、認証処理が行われる際にそれを読み出すことによってレスポンスキーを設定してもよい。また、第１ＫＤＦの演算と第２ＫＤＦの演算の一方をランタイムとし、他方を事前演算したデータを読み出すようにしてもよい。

上述した通り、本実施形態においては、サーバ１で実行されるレスポンスキーの設定処理と、クライアント３で実行されるレスポンスキーの設定処理は異なる。その相違の１つとして、サーバ１で行われるレスポンスキー設定処理において、第１ＫＤＦの演算処理は実行されない。より具体的には、事前に（認証処理の開始の前に、例えば、事前に行われるクライアント３の設定処理において、）第１ＫＤＦの演算を実行した結果である演算済データ（第１派生鍵データ。本実施形態では、後述する通り、暗号化した第１派生鍵データ）をクライアント３の記憶部に書き込んでおく。そして、認証処理が行われる際にその演算済データをクライアント３からサーバ１に送信し、サーバ１ではその演算済データを用いて、第１ＫＤＦの演算を実行することなく、第２ＫＤＦの演算を実行してレスポンスキーの設定を行う。本実施例では、後述の通り、この演算済データはクライアント証明書データ（以下、単に証明書データと呼ぶ）に含まれる。

ここで、証明書データの生成方法について説明する。クライアント３には、上記証明書データが予め（認証処理の開始前に）記憶される。当該証明書データは、クライアント３の設定処理時に、クライアント３の記憶部（後述）に書き込まれる。図３は、ＰＣ（以下、ＰＣ４と呼ぶ）によって書込処理が実行される場合の証明書作成処理の概要を模式的に示した図である。図３において、まず、製造対象のクライアント３のマスターキーＤ０１と、カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３が第１ＫＤＦに入力される。これにより、第１派生鍵Ｄ０５が生成される。なお、マスターキーＤ０１については、例えば、ＰＣ４に接続され、証明書データの書き込み処理の対象となっているクライアント３から読み出されればよい。ここで、上記のように、本実施形態ではカウンタ値Ｄ０２が取り得る値が４つである。そのため、ＰＣ４における第１ＫＤＦの演算はカウンタ値Ｄ０２の取りうる値（０～３）毎に行われ、カウンタ値Ｄ０２の値のそれぞれに対応した第１派生鍵Ｄ０５が生成される。すなわち、この例では、４つの第１派生鍵Ｄ０５が生成される。以下では、これら４つの第１派生鍵Ｄ０５を個別に表記するときは、第１派生鍵（カウンタ値０時）Ｄ０５Ａ、第１派生鍵（カウンタ値１時）Ｄ０５Ｂ、第１派生鍵（カウンタ値２時）Ｄ０５Ｃ、第１派生鍵（カウンタ値３時）Ｄ０５Ｄと表記する。

次に、各第１派生鍵Ｄ０５を暗号化する処理が行われる。具体的には、各第１派生鍵Ｄ０５を、暗号鍵である第１サーバ鍵Ｄ０７を用いて暗号化する処理が行われる。以下では、暗号化された第１派生鍵Ｄ０５を「暗号化第１派生鍵」Ｄ０８と呼ぶ。また、本実施形態では、第１サーバ鍵Ｄ０７は、カウンタ値Ｄ０２毎に異なるものが用意されている。以下では、カウンタ値Ｄ０２が０である場合に用いられる第１サーバ鍵Ｄ０７は「第１サーバ鍵（カウンタ値０時）Ｄ０７Ａ」、カウンタ値Ｄ０２が１である場合に用いられる第１サーバ鍵Ｄ０７は「第１サーバ鍵（カウンタ値１時）Ｄ０７Ｂ」などのように表記し、暗号化された暗号化第１派生鍵Ｄ０８を、「暗号化第１派生鍵（カウンタ値０時）Ｄ０８Ａ」、「暗号化第１派生鍵（カウンタ値１時）Ｄ０８Ｂ」などのように表記する。このように、カウンタ値Ｄ０２毎に暗号化第１派生鍵Ｄ０８が生成され、本実施形態では、合計４つの暗号化第１派生鍵Ｄ０８が生成される。なお、第１サーバ鍵Ｄ０７は共通鍵であってもよいし、秘密鍵／公開鍵であってもよい。

次に、クライアント証明書に付する電子署名（以下、単に署名と呼ぶ）Ｄ１２が生成される。署名Ｄ１２は、署名用の鍵である署名用鍵Ｄ０９を用いる所定の署名生成アルゴリズムによる演算を行うことで生成される。具体的には、（Ａ）クライアントＩＤ＿Ｄ１０と、（Ｂ）後述の第２ＫＤＦシード特定用第１パラメータ（以下、第１特定パラメータと呼ぶこともある）Ｄ１１と、（Ｃ）上記４つの暗号化第１派生鍵Ｄ０８と、の合計７つのデータ要素を含むデータに対して、署名用鍵Ｄ０９を用いて署名を行うことで生成される。

ここで、クライアントＩＤ＿Ｄ１０とは、クライアント３を識別するためのＩＤである。例えば、クライアントデバイスのＳｏＣのＩＤ、シリアル番号、または、製造番号等をクライアントＩＤ＿Ｄ１０としてもよい。なお、クライアントをエミュレータ技術で実現する場合は、当該番号は、エミュレートする対象のそれらの情報であってもよい。証明書生成に際しては、例えば、ＰＣ４に接続され、証明書データの書き込み処理の対象となっているクライアント３から当該クライアントＩＤ＿Ｄ１０が読み出されて用いられてもよい。また、第１特定パラメータＤ１１は、サーバ１において第２ＫＤＦシードデータＤ０４の値を特定するために用いられる（詳細は後述する）。

次に、クライアントＩＤ＿Ｄ１０と、第１特定パラメータＤ１１と、上記４つの暗号化第１派生鍵Ｄ０８とを含み、上述の通り生成された署名Ｄ１２が付された証明書データＤ１０１が生成される。図４に、証明書データＤ１０１の構成を示す。証明書データＤ１０１には、署名Ｄ１２、４つの暗号化第１派生鍵Ｄ０８Ａ～０８Ｄ、クライアントＩＤ＿Ｄ１０、上記第１特定パラメータＤ１１が含まれる。

最後に、生成した証明書データＤ１０１をクライアント３の不揮発記憶部（後述）に書き込む処理が実行される。後述の通り、証明書データＤ１０１は、認証処理の過程で、クライアント３からサーバ１に送信され、証明書データＤ１０１に含まれる各データはサーバ１で使用される。証明書データＤ１０１に含まれるデータのうち、暗号化第１派生鍵Ｄ０８（厳密には、それを復号化した第１派生鍵Ｄ０５）は、第１ＫＤＦ演算を行った結果である第１派生鍵データであり、サーバ１はこのデータを用いてレスポンスキーの設定を行う。そのため、サーバ１では第１ＫＤＦ演算を実行する必要がない。なお、証明書データＤ１０１は所定のサーバや他のＰＣからクライアント３にダウンロードまたは転送等されてクライアント３に書き込みされてもよい。

また、本実施形態では、カウンタ値Ｄ０２をレスポンスキー設定のためのＫＤＦ演算のシードデータとしている。これにより、状況に応じてレスポンスキーを変更することが可能になる。

また、本実施形態では、証明書内に複数の派生鍵を含めて選択して用いることができるようにしており、レスポンスキーの変更を効率的に実現できる。

［チャレンジの生成・送信の概要］
次に、サーバ１におけるチャレンジデータの生成・送信処理の概要について説明する。この処理は、クライアント３からのチャレンジ発行要求により実行される。クライアント３は、チャレンジ発行要求時に証明書データＤ１０１を送信する。図５は、サーバ１におけるチャレンジデータの生成及び送信の処理の概要を示し、当該処理におけるデータの流れを模式的に示した図である。当該処理では、まず、クライアント３から証明書データＤ１０１を受信し、その検証（署名の検証）が行われる、当該検証の結果、問題が無ければ、証明書データＤ１０１からクライアントＩＤ＿Ｄ１０が取り出される。

次に、当該クライアントＩＤ＿Ｄ１０と、「チャレンジバージョン」Ｄ１４と、「チャレンジ発行時刻」Ｄ１５とを演算対象にして、「第２サーバ鍵」Ｄ１３を用いた所定のＭＡＣ演算が行われて、第１ＭＡＣ（Message Authentication Code）値Ｄ１６が算出される。第１ＭＡＣ値Ｄ１６がチャレンジデータとして利用される。

なお、本実施態様では、ＭＡＣ演算によってチャレンジデータを生成したが、改ざん検証データ（改ざん検証に用いられるデータ）を生成可能な暗号学的演算であればなんでもよく、例えば、ＡＥＳ－ＧＣＭアルゴリズム等が用いられてもよい。また、当該演算に用いる第２サーバ鍵は、共通鍵であってもよいし、秘密鍵／公開鍵であってもよい。

ここで、チャレンジバージョンＤ１４は、サーバ１に記憶されているデータであり、ある時点でサーバ１で生成されるチャレンジデータの生成方法の「バージョン」を定義する情報であり、現在のバージョンを示す情報である。例えば、最初はチャレンジバージョンＤ１４は「１．０」と設定されており、所定の時点で「２．０」に変更され得る。

また、チャレンジ発行時刻Ｄ１５は、サーバ１でチャレンジデータを生成する処理が行われるときのサーバ１の時刻である。

また、第２サーバ鍵Ｄ１３は、第１ＭＡＣ値（チャレンジデータ）Ｄ１６の算出に用いられる鍵データであり、本実施形態では、チャレンジバージョンＤ１４毎に第２サーバ鍵Ｄ１３は異なり得る（バージョンが変わっても鍵が変わらないことがあってもよい。）。本実施形態では、現在のチャレンジバージョンＤ１４に対応する第２サーバ鍵Ｄ１３が選択され、これが第１ＭＡＣ値（チャレンジデータ）Ｄ１６の算出に用いられる。第１ＭＡＣ値Ｄ１６が、クライアント３においてレスポンスキーを用いた演算対象になるデータであり、いわゆるチャレンジデータである。

第１ＭＡＣ値Ｄ１６が算出されれば、（現在の）チャレンジバージョンＤ１４と、チャレンジ発行時刻Ｄ１５と、第１ＭＡＣ値（チャレンジデータ）Ｄ１６に基づいて、チャレンジデータセットＤ１０２が生成される。図６に、チャレンジデータセットＤ１０２の構成を模式的に示す。なお、チャレンジデータセットＤ１０２は、チャレンジデータを含み、それ以外のデータも含むデータである。本実施形態では、チャレンジデータセットＤ１０２は、「チャレンジバージョンＤ１４＋チャレンジ発行時刻Ｄ１５＋第１ＭＡＣ値（チャレンジデータ）Ｄ１６」という、各内容を含む構成のデータである。なお、ＭＡＣ演算の結果の値は、演算対象となるデータ（メッセージデータ）に付加されて送信されるのが一般的であるが、本実施形態においては、クライアントＩＤ＿Ｄ１０は第１ＭＡＣ値の演算に用いられるが、チャレンジデータセットには含まれない。

上記のようにして生成されたチャレンジデータセットＤ１０２が、チャレンジの送信要求をしてきたクライアント３に送信される。

［クライアント３におけるレスポンス生成処理の概要］
次に、チャレンジデータセットＤ１０２を受信したクライアント３で実行されるレスポンス生成処理の概要を説明する。図７は、当該処理の概要を説明するための図である。まず、サーバ１から受信したチャレンジデータセットＤ１０２に含まれる第１ＭＡＣ値（チャレンジデータ）Ｄ１６に対して、図２を用いて前述したように設定されたレスポンスキー（クライアント）（第２派生鍵（クライアント）Ｄ０６）を用いてＭＡＣ演算することによって、第２ＭＡＣ値（レスポンスデータ）Ｄ１７が算出される。第２ＭＡＣ値Ｄ１７がチャレンジデータをレスポンスキーで演算した結果であり、いわゆるレスポンスデータである。なお、第２ＭＡＣ値（レスポンスデータ）Ｄ１７を算出する際のＭＡＣ演算の内容は、第１ＭＡＣ値（チャレンジデータ）Ｄ１６を算出する際のＭＡＣ演算の内容と同じであってもよいし、異なる演算内容であってもよい。なお、第２ＭＡＣ演算に入力されるデータである第１ＭＡＣ値の長さは、第１ＭＡＣ演算の内容によって決まり、第１ＭＡＣ演算に入力されるデータの長さに関わらず固定の長さである。
本実施例においては、レスポンスキーを用いてチャレンジデータからレスポンスデータを生成する際にＭＡＣ演算を用いたが、レスポンスキーを用いてチャレンジデータからレスポンスデータを生成することができるアルゴリズムであればＭＡＣ演算に限らずなんでもよい。

次に、当該第２ＭＡＣ値（レスポンスデータ）Ｄ１７と、受信したチャレンジデータセットＤ１０２に含まれているチャレンジバージョンＤ１４、および、チャレンジ発行時刻Ｄ１５に基づいて、レスポンスデータセットＤ１０３が生成される。レスポンスデータセットＤ１０３は、レスポンスデータを含み、それ以外のデータ（本実施形態では、サーバ１から受信したチャレンジデータセットＤ１０２に含まれるチャレンジデータ以外のデータ。具体的には、チャレンジバージョンＤ１４、および、チャレンジ発行時刻Ｄ１５）も含むデータである。なお、前述の通り、ＭＡＣ演算の結果の値は、演算対象となるデータ（メッセージデータ）に付加されて送信されるのが一般的であるが、本実施形態においては、第１ＭＡＣ値（チャレンジデータ）Ｄ１６は、第２ＭＡＣ値（レスポンスデータ）Ｄ１７の演算に用いられるが、それをサーバに送信する際のデータ（後述のレスポンスデータセットやクライアント送信データ）には含まれない。

レスポンスデータセットＤ１０３が生成されれば、クライアント３は、（Ａ）レスポンスデータセットＤ１０３と、（Ｂ）証明書データＤ１０１と、（Ｃ）後述する第２ＫＤＦシードデータ特定用第２パラメータ（以下、第２特定パラメータと呼ぶこともある）Ｄ１９とを、サーバ１に送信する。図８は、クライアント３がサーバ１に送信するデータ（以下、総称してクライアント送信データＤ１０４と呼ぶこともある）の模式図である。なお、クライアント送信データの各データはひとまとまりで送信されてもよいし、別のタイミングで、別々に送信されてもよい。図８において、レスポンスデータセットＤ１０３は、チャレンジバージョンＤ１４、チャレンジ発行時刻Ｄ１５、第２ＭＡＣ値（レスポンスデータ）Ｄ１７とを含んでいる。これは、上記チャレンジデータセットＤ１０２の第１ＭＡＣ値（チャレンジデータ）Ｄ１６を第２ＭＡＣ値（レスポンスデータ）Ｄ１７に差し替えたような構成となっている。すなわち、チャレンジデータ受信時にサーバ１から受信したチャレンジデータセットに含まれるチャレンジバージョンＤ１４およびチャレンジ発行時刻Ｄ１５は、レスポンスデータセットに含まれて、レスポンスデータ送信時にサーバ１に送信される。証明書データＤ１０１は、チャレンジ発行要求の際に送信される証明書データＤ１０１と同じものである。すなわち、証明書データＤ１０１は、チャレンジデータの送信をサーバ１に要求する際と、レスポンスデータをサーバ１に送信する際に送信される。第２特定パラメータＤ１９は、第１特定パラメータＤ１１と共に、サーバ１の処理において第２ＫＤＦシードデータＤ０４の値を特定するために利用されるパラメータである（詳細は後述）。

次に、クライアント送信データＤ１０４を受信したサーバ１におけるレスポンス検証にかかる処理の概要を説明する。サーバ１では、まず、レスポンスキー（サーバ）が設定される。次に、設定されたレスポンスキー（サーバ）を用いて第２ＭＡＣ値（検証時）Ｄ２１７が算出される。そして、当該サーバ１で算出された第２ＭＡＣ値（検証時）Ｄ２１７とクライアントから送信された第２ＭＡＣ値（レスポンスデータ）Ｄ１７とが一致するか否かが判定されることで、レスポンスデータＤ１７の検証が行われる。

図９は、サーバ１におけるレスポンスキー設定処理の概要を説明するための図である。まず、クライアント送信データＤ１０４に含まれる証明書データＤ１０１について、署名Ｄ１２の検証が行われる。検証に問題がなければ、証明書データＤ１０１から暗号化第１派生鍵Ｄ０８、および、第１特定パラメータＤ１１が取り出される。ここで、上記のように、証明書データＤ１０１には４つの暗号化第１派生鍵Ｄ０８が含まれているが、このうちの１つが、以下の手順で特定して取り出される。まず、クライアント３における現在のカウンタ値Ｄ０２の特定が行われる。当該特定は、サーバ１に予め記憶されている「カウンタ値特定テーブル」を参照することで行われる。カウンタ値特定テーブルは、クライアント３から送信された第１特定パラメータＤ１１、および、第２特定パラメータＤ１９に基づいて、当該クライアントの現在のカウンタ値Ｄ０２を特定するためのテーブルである。つまり、証明書データＤ１０１から取り出した第１特定パラメータＤ１１と、証明書データＤ１０１と共に送信されてきた第２特定パラメータＤ１９とを用いて、レスポンスデータを送信したクライアント３（認証対象のクライアント３）における現在のカウンタ値Ｄ０２の特定が行われる。図１０に、カウンタ値特定テーブルＳＶ４０４のデータ構成の一例を示す。カウンタ値特定テーブルＳＶ４０４は、第１特定パラメータＤ１１の値、および、第２特定パラメータＤ１９の値の組み合わせに対応付けられて、カウンタ値Ｄ０２が定義されている。

図９に戻り、次に、サーバ１では、証明書データＤ１０１に含まれる複数の暗号化第１派生鍵Ｄ０８のうち、カウンタ値特定テーブルＳＶ４０４を用いて特定されたカウンタ値Ｄ０２に対応する暗号化第１派生鍵Ｄ０８が選択され、証明書データＤ１０１から取り出される。次に、サーバ１において、取り出した暗号化第１派生鍵Ｄ０８が、サーバ１に記憶されている第１サーバ鍵Ｄ０７を用いて復号されることで、第１派生鍵Ｄ０５が得られる。ここで、第１サーバ鍵Ｄ０７は、上記のようにカウンタ値Ｄ０２に応じて異なる鍵データである。ここで、クライアント３によってカウンタ値Ｄ０２が異なることがあり得る場合、サーバ１には、現在あり得るカウンタ値Ｄ０２に対応する各第１サーバ鍵Ｄ０７が記憶され、特定したカウンタ値Ｄ０２に応じた第１サーバ鍵Ｄ０７が使用される。

次に、復号された第１派生鍵Ｄ０５と、第２ＫＤＦシードデータＤ２０４とを用いて、第２ＫＤＦの処理が実行される。ここで、第２ＫＤＦの処理における第２ＫＤＦシードデータＤ２０４（の値）は、以下のようにして決定される。第２ＫＤＦシードデータＤ２０４の値の特定には、「第２ＫＤＦシードデータ特定テーブル」が用いられる。第２ＫＤＦシードデータ特定テーブルは、第１特定パラメータＤ１１、および、第２特定パラメータＤ１９に基づいて上記第２ＫＤＦシードデータＤ０４を特定するためのテーブルである。つまり、証明書データＤ１０１から取り出した第１特定パラメータＤ１１と、証明書データＤ１０１と共に上記クライアントから送信された第２特定パラメータＤ１９とを用いて、レスポンスデータを送信してきたクライアント３における第２ＫＤＦシードデータＤ０４が特定される。図１１に、第２ＫＤＦシードデータ特定テーブルＳＶ４０５のデータ構成の一例を示す。第２ＫＤＦシードデータ特定テーブルＳＶ４０５においては、第１特定パラメータＤ１１および第２特定パラメータＤ１９の組み合わせに対応付けられて、第２ＫＤＦシードデータＤ２０４の値が定義されている。すなわち、図２を用いて上述した通り、クライアント３のレスポンスキー設定処理においては、クライアント３に記憶される第２ＫＤＦシードデータを用いてレスポンスキーの設定が行われる。一方、サーバ１におけるレスポンスキー設定処理においては、クライアント３から受信する第１特定パラメータＤ１１および第２特定パラメータＤ１９に基づいて、レスポンスデータを送信してきたクライアント３に記憶される第２ＫＤＦシードデータＤ０４の値を特定し、その値を用いてレスポンスキーの設定が行われる。この点は、サーバで実行されるレスポンスキーの設定処理と、クライアントで実行されるレスポンスキーの設定処理の相違点の１つである。

本実施形態では、サーバ１において、クライアント３から送信された特定パラメータを用いて、ＫＤＦシードデータを特定する。このような構成により、クライアント（エミュレータ技術により実現する場合にはエミュレート対象のクライアントデバイス）の属性や状態等を考慮したレスポンスキー設定が可能となる。また、本実施形態では、ＫＤＦシードデータの特定のために、２つのパラメータを用いており、第１特定パラメータを署名対象とし、第２特定パラメータを署名対象としていない。この構成により、例えば、署名が可能なパラメータと署名が困難なパラメータを用いるなどして、ＫＤＦシードデータの構成を柔軟にすることができる。

どのようなパラメータを第１特定パラメータＤ１１、第２特定パラメータＤ１９とするかについては、適宜設計すればよい。例えば、第１特定パラメータＤ１１は、固定値であってもよい。例えば、クライアント３のハードウェアの属性情報であってもよい。第２特定パラメータＤ１９は、クライアント３において設定あるいは変更可能なデータであってもよい。例えば、ソフトウェアの属性情報であってもよく、または、システムソフトウェアの属性情報（例えば、システムソフトウェアのバージョン情報）であってもよい。第１特定パラメータＤ１１がクライアント３において設定または変更可能なデータであってもよいし、第２特定パラメータＤ１９が固定値であってもよい。なお、クライアント３をエミュレータ技術で実現する場合、第１特定パラメータ、第２特定パラメータは、エミュレート対象の属性情報等であってもよい。ただし、本実施例において、第１特定パラメータおよび第２特定パラメータは、第２ＫＤＦシードデータと異なるデータであり、第１特定パラメータと第２特定パラメータとの組み合わせにより第２ＫＤＦシードデータを特定することができるデータである。また、本実施例において、第１特定パラメータおよび第２特定パラメータは、第１ＫＤＦシードデータとも異なるデータである。

図９に戻り、サーバ１において、上記のようにして決定された第２ＫＤＦシードデータＤ２０４と、証明書データＤ１０１から取り出した第１派生鍵Ｄ０５を用いて第２ＫＤＦの演算処理を実行することで、第２派生鍵（サーバ）Ｄ２０６が生成される。なお、サーバ１で行われる第２ＫＤＦの演算内容（アルゴリズム）は、クライアント３で行われる第２ＫＤＦの演算内容と同じである。そして、サーバ１において、生成された第２派生鍵（サーバ）Ｄ２０６がレスポンスキーとして用いられる。すなわち、第２派生鍵（サーバ）Ｄ２０６の生成により、レスポンスキー（サーバ）が設定される。

ここで、ＫＤＦ演算の元になるデータやＫＤＦ演算の演算内容がクライアントの構成によって異なる場合には、サーバ１において派生鍵を生成する際に、各クライアントの構成に応じて、ＫＤＦ演算の元になるデータやＫＤＦ演算の演算内容を変更するためのデータベース等を管理する必要がある。しかしながら、本実施形態では、第１ＫＤＦ演算については、ＫＤＦ演算済のデータ（派生鍵）がクライアント３からサーバ１に送信され、サーバ１はそれを用いてレスポンスキーを生成するため、そのようなデータベースを持つ必要がない。

また、本実施形態では、ＫＤＦ演算を多段階とし、第１ＫＤＦ演算については、演算済の派生鍵をクライアント３からサーバ１に送信し、サーバ１において、それを用いつつ別のＫＤＦ演算（第２ＫＤＦ演算）は実行してレスポンスキーを生成する。これにより、検証の要素となる複数の側面について、一部を予め演算しておき、他の一部をサーバで演算することで、検証の要素の性質に応じた方法での検証が可能になる。

なお、図９で示されるように、サーバ１におけるレスポンスキー設定処理においては、レスポンスデータセットＤ１０３は利用していない。次に説明する検証処理において、レスポンスデータセットＤ１０３に含まれる第２ＭＡＣ値（レスポンスデータ）Ｄ１７の検証が行われる。

［検証処理の概要］
次に、サーバにおいて行われる検証処理（本実施例においては、レスポンスデータの検証だけでなく、後述の通り、レスポンスデータに含まれるチャレンジ発行時刻の検証を含む）の概要を説明する。図１２は、検証処理の概要を説明するための図である。検証処理では、サーバ１側で第２ＭＡＣ値（検証時）Ｄ２１７を算出して、クライアント３から送信されてきた第２ＭＡＣ値（レスポンスデータ）Ｄ１７と一致するか否かを判断することで、レスポンスデータである第２ＭＡＣ値Ｄ１７を検証する処理を行う。

まず、サーバ１において第１ＭＡＣ値（検証時）Ｄ２１６を算出する処理が行われる。この処理は、基本的には、図５を用いた上述した、チャレンジ生成処理において第１ＭＡＣ値（チャレンジデータ）Ｄ１６を算出する処理と同じ処理が行われる。クライアント３から送信されてきたレスポンスデータセットＤ１０３に含まれているチャレンジバージョンＤ１４に基づいて、チャレンジバージョンＤ１４に対応する第２サーバ鍵Ｄ１３を選択する。そして、選択した第２サーバ鍵Ｄ１３を用いて、「レスポンスデータセットＤ１０３に含まれるチャレンジバージョンＤ１４およびチャレンジ発行時刻Ｄ１５と、クライアントから送信された証明書データＤ１０１（検証要求時に送信された証明書データＤ１０１）に含まれるクライアントＩＤ＿Ｄ１０」を対象にしたＭＡＣ値を演算をすることで第１ＭＡＣ値（検証時）Ｄ２１６を算出する。

なお、第１ＭＡＣ値（検証時）Ｄ１６の算出処理に関して、他の実施形態では、上記チャレンジ生成処理において算出した第１ＭＡＣ値（チャレンジデータ）Ｄ１６をサーバ１に保存しておくようにしてもよい。そして、保存しておいた第１ＭＡＣ値（チャレンジデータ）Ｄ１６を、検証処理において利用するようにして、第１ＭＡＣ値（検証時）Ｄ１６の算出処理を省略するような構成にしてもよい。

次に、上記設定したレスポンスキー（サーバ）Ｄ２０６と、第１ＭＡＣ値（検証時）Ｄ２１６とを用いて、クライアント３におけるＭＡＣ演算と同じアルゴリズムによって第２ＭＡＣ値（検証時）Ｄ２１７が算出される。

次に、レスポンスデータセットＤ１０３に含まれる第２ＭＡＣ値（レスポンスデータ）Ｄ１７と、上記算出した第２ＭＡＣ値（検証時）Ｄ２１７とを比較し、一致するか否かを判定する。一致すれば、レスポンスの検証結果はＯＫ（肯定）と判定され、不一致の場合、レスポンスの検証結果はＮＧ（否定）と判定される。

さらに、本実施態様においては、サーバ１では、時間的な観点による検証処理が行われる。この処理では、サーバ１がチャレンジデータセットＤ１０２を発行してからクライアントがレスポンスデータセットＤ１０３等を返してくるまでの時間（またはチャレンジデータの発行から検証を実行するまでの時間）が、一定時間以内であるかどうかが判定される。具体的には、上記レスポンスデータセットＤ１０３に含まれるチャレンジ発行時刻Ｄ１５と、検証処理を実行する時点におけるサーバ１の現在時刻とを比較する。この時間が一定時間以内であれば、ＯＫと判断され、一定時間以上かかっている場合は、ＮＧと判定される。

そして、レスポンスデータＤ１７の検証、および、時間的観点による検証の双方ともＯＫであれば、認証成功と判定される。それ以外の場合は認証失敗と判定される。認証成功の場合は、所定のサービストークンをクライアントに送信する処理が実行される。認証失敗の場合は、エラーメッセージ等が送信されることになる。サービストークンの内容は、例えば、クライアントＩＤ、所定のオンラインサービスの識別子、有効期限、および、それらのデータの署名またはＭＡＣ値を含む情報である。

上述のように、本実施例では、チャレンジ発行時に、サーバ１からクライアント３に、少なくともチャレンジ発行時刻をＭＡＣ演算の対象としたＭＡＣ値（第１ＭＡＣ値）をチャレンジ発行時刻とともに送信している。また、レスポンスデータの生成時に、クライアント３はそのＭＡＣ値をレスポンスキーでさらにＭＡＣ演算した値（第２ＭＡＣ値）をレスポンスデータとして生成してサーバ１に送信している。サーバ１でそれを検証対象とし、さらに、サーバ１においては、チャレンジ発行時刻を用いた時間的な検証も行う。これにより、認証処理の過程における不正を防止できる。

以下、本実施形態に係る処理の詳細について説明する。

［クライアント３のハードウェア構成］
次に、上記クライアント３のハードウェア構成について説明する。図１３は、クライアント３のハードウェア構成を示すブロック図である。本実施形態では、クライアント３はゲーム装置であるが、一般的なＰＣやスマートフォン、タブレットデバイス等でもよい。クライアント３はコンピュータの一例であり、プロセッサ、メモリ、通信用プロセッサや表示用プロセッサなどの周辺プロセッサなどを含む。クライアント３は、処理部３１と、記憶部３２と、ネットワーク通信部３５と、操作デバイス３６（ゲームコントローラ）と、画像出力部３７とを少なくとも備えている。処理部３１は、例えば、プロセッサであり、クライアント３を制御するための各種プログラムを実行する。クライアント３は複数のデバイスにより構成されても良い。処理部３１は、複数のプロセッサにより構成されても良く、この場合、複数のデバイスの複数のプロセッサであってもよい。また、プロセッサは、汎用プロセッサでも専用プロセッサでもよく、いわゆる、Ｓｏｃ、ＣＰＵ、ＡＳＩＣ、マイコンなど態様を問わない。記憶部３２には、処理部３１によって実行される各種プログラムおよび利用される各種データが格納される。プログラムは複数のプログラムにより構成されるプログラム群であってもよく、各プログラムが異なるプロセッサにより実行されても良く、また、各プログラムが異なるメモリに記憶されても良い。また、プログラムは、アプリケーションソフトウェア、システムソフトウェア、ファームウェア、エミュレータなどソフトウェアの態様を問わない。プログラムは、コードに加えてデータやテーブルパラメータを含んでも良い。具体的には、記憶部３２は、不揮発記憶部３３と、揮発記憶部３４とを含む。不揮発記憶部３３は、例えばフラッシュメモリやＳＳＤ（Solid State Drive）等である。揮発記憶部３４は、例えばＤＲＡＭであり、メインメモリとして機能する。不揮発記憶部３３に記憶されている各種プログラムやデータが、必要に応じて揮発記憶部３４上に読み込まれ、処理部３１によって、後述するような各種処理が実行され得る。ネットワーク通信部３５は、例えばインターネットなどのネットワークを介して他のサーバやクライアント３と通信（無線であっても有線であってもよい）する。なお、ネットワークを介さずに通信相手と直接通信する構成としても良い。ネットワーク通信部３５は、例えば、ネットワークコントローラＩＣや無線通信ＩＣであってもよい。操作デバイス３６は、各種の操作デバイス（キーボード、マウス等）である。画像出力部３７は、処理部３１による情報処理の結果生成された所定の画像を出力する。

なお、不揮発記憶部３３や揮発記憶部３４について、その一部の領域がセキュア領域として構成されていてもよい。後述する各種データのうちの一部のデータについては、例えばＳｏＣ（System on a Chip）内のメモリ等のセキュア領域に格納されるように構成してもよい。

なお、サーバ１やＰＣ４のハードウェア構成は、一般的なサーバやＰＣのハードウェア構成であればよく、説明を省略するが、図１３と同様の構成である。なお、サーバ１は複数のサーバ装置により構成されてもよい。すなわち、サーバ１は、処理部１１と、フラッシュメモリ等の不揮発記憶部１３とＤＲＡＭ等の揮発記憶部１４を含む記憶部１２等により構成される。サーバ１はコンピュータの一例である。また、ＰＣ４は、処理部４１と、フラッシュメモリ等の不揮発記憶部４３とＤＲＡＭ等の揮発記憶部４４を含む記憶部４２等により構成される。

次に、本実施形態に係る処理で用いられる各種データに関して説明する。

［クライアント３で用いられるデータ］
図１４は、クライアント３の記憶部３２に記憶されるデータの一例である。図１４に示すデータは、不揮発記憶部３３に記憶されるデータを示しており、認証処理の実行に際して、これらのデータが必要に応じて揮発記憶部３４に読み込まれることで、認証処理が実行され得る。なお、これらのデータは、異なるメモリに分かれて記憶されていてもよい。例えば、一部のデータは上述したセキュア領域に記憶されていてもよい。

図１４において、不揮発記憶部３３には、システムプログラムＣＬ２０１、オンラインゲームプログラムＣＬ２０２、マスターキーＤ０１、カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３、第２ＫＤＦシードデータＤ０４、証明書データＤ１０１、第２ＫＤＦシードデータ特定用第２パラメータＤ１９、が少なくとも記憶されている。なお、図１４において、システムプログラムＣＬ２０１、オンラインゲームプログラムＣＬ２０２以外の各データは、内容的には上述した各種データと同じものである。

図１４において、システムプログラムＣＬ２０１は、クライアント３のシステムを制御するためのプログラムである。システムプログラムＣＬ２０１には、図１５に示すような、本実施形態の認証機能を実現するためのプログラムが少なくとも含まれている。まず、サーバ１に対してチャレンジの発行を要求するチャレンジ発行要求プログラムがシステムプログラムＣＬ２０１に含まれている。また、レスポンスキー（クライアント）を設定するための機能を有するレスポンスキー設定プログラムがシステムプログラムＣＬ２０１に含まれている。また、チャレンジデータセットＤ１０２を受信し、レスポンスデータセットＤ１０３を生成し、レスポンスデータセットＤ１０３等（上述したクライアント送信データ）を送信する機能を有するレスポンス生成・送信プログラムがシステムプログラムＣＬ２０１に含まれている。また、認証結果に基づいてオンラインゲームを開始させる機能を有する認証結果処理プログラムもシステムプログラムＣＬ２０１に含まれている。本実施形態に係るデバイス認証処理は、（アプリケーションの処理ではなく、）クライアント３を制御するシステム側の処理の一つとして実行される。

図１４に戻り、オンラインゲームプログラムＣＬ２０２は、所定のオンラインゲームのプログラムである。本実施形態では、上記のように、オンラインゲームのプレイの開始に際して、デバイス認証処理が実行される。

なお、上述した各種データ（レスポンスキー（クライアント）の設定に必要となる各種のデータ（各ＫＤＦ演算のシードデータ、証明書データ、シードデータ特定のためのパラメータ等）を含む）について、所定のタイミングでダウンロード、または、他の情報処理装置から転送されて記憶部３２に記憶するようにしてもよい。この場合、例えば、レスポンスキー設定プログラムは、ダウンロード又は転送した各種データを指定する機能があってもよい。あるいは、各種データが保存されている場所（クライアント３におけるフォルダ等）を指定する機能があってもよい。

また例えば、他の実施形態では、第１派生鍵Ｄ０５のデータが記憶部３２記憶される構成であってもよい。この場合は、マスターキーＤ０１、第１ＫＤＦシードデータＤ０３は、記憶部３２に記憶されなくてもよい。

また例えば、他の実施形態では、第２派生鍵Ｄ０６のデータが記憶部３２に記憶される構成であってもよい。この場合は、マスターキーＤ０１、第１ＫＤＦシードデータＤ０３、第２ＫＤＦシードデータＤ０４は記憶されなくてもよい。またこの場合は、レスポンスキー設定プログラムは、第１派生鍵設定機能を有さない構成としてもよい。

［サーバ１で用いられるデータ］
次に、サーバ１の記憶部１２に記憶されるデータについて説明する。図１６は、サーバ１の不揮発記憶部１３に記憶されるデータを示している。認証処理の実行に際して、これらのデータが必要に応じて適宜揮発記憶部１４に読み込まれることで、サーバ１側における認証処理が実行され得る。

サーバ１の不揮発記憶部１３には、認証プログラムＳＶ４０１、第１サーバ鍵Ｄ０７、第２サーバ鍵Ｄ１３、カウンタ値特定テーブルＳＶ４０４、第２ＫＤＦシードデータ特定テーブルＳＶ４０５、ＣＡ公開鍵ＳＶ４０６、チャレンジバージョンＤ１４等が記憶されている。

認証プログラムＳＶ４０１は、サーバ１側において認証処理を実行するためのプログラムである。認証プログラムＳＶ４０１は、上記チャレンジデータをクライアント３に発行しその他のデータを送信するするチャレンジ発行機能と、クライアント３からのレスポンスデータセットＤ１０３等を用いて検証する検証機能を有するプログラムである。また、検証機能には、図１２を用いて上述したレスポンスキー（サーバ）を設定する機能も含まれる。

ここで、第１サーバ鍵Ｄ０７について補足する。上記のように、本実施形態においては、第１サーバ鍵Ｄ０７についてはカウンタ値に応じた複数の鍵データが用意されているが、サーバ１に記憶される第１サーバ鍵Ｄ０７としては、このうちのいずれか１つの鍵データが記憶される。そして、カウンタ値がインクリメントされる度に、各カウンタ値に応じた鍵データに入れ替えるようにして記憶される。

なお、クライアント３のカウンタ値Ｄ０２のインクリメントが、クライアント３のシステムアップデートで行われる場合、各クライアント３におけるカウンタ値Ｄ０２の更新タイミングは同じとは限らない。そのため、カウンタ値Ｄ０２のインクリメントの発生（例えば、システムアップデートのタイミング）から一定期間の間は、インクリメント前のカウンタ値Ｄ０２に対応する第１サーバ鍵Ｄ０７を「旧第１サーバ鍵」として記憶しておくようにしてもよい。そして、一定期間の間は、まだシステムアップデートがされていないクライアント３から認証を要求された場合でも、「旧第１サーバ鍵」を利用して、認証成功と判定され得るように構成してもよい。

上記のように、本実施形態においては、第２サーバ鍵Ｄ１３は、チャレンジバージョンＤ１４毎に異なる内容の鍵データである。そして、サーバ１の記憶部１２には、現在用いるチャレンジバージョンＤ１４に応じた内容の鍵データが、第２サーバ鍵Ｄ１３として記憶される。チャレンジバージョンＤ１４が変更された際には、旧チャレンジバージョンで発行されたチャレンジを用いて検証要求を行うクライアント３が存在する可能性があるため、旧チャレンジバージョンに対応する第２サーバ鍵Ｄ１３を記憶しておいて、そのようなクライアント３からの検証要求に対応してもよい。

カウンタ値特定テーブルＳＶ４０４は、上記図１０で示したようなデータである。そのため、ここでは詳細な説明は割愛する。

第２ＫＤＦシードデータ特定テーブルＳＶ４０５は、上記図１１で示したようなデータである。そのため、ここでは詳細な説明は割愛する。

ＣＡ公開鍵ＳＶ４０６は、署名用鍵Ｄ０９と対になる鍵データであり、サーバ１において証明書データＤ１０１の署名Ｄ１２を検証する際に用いられる鍵データ（公開鍵暗号方式における復号鍵あるいは検証鍵）である。

チャレンジバージョンＤ１４は、その時点で発行するチャレンジに付するチャレンジバージョンである。上記のように、本実施形態では、第２サーバ鍵Ｄ１３はチャレンジバージョン毎に異なるため、チャレンジデータＤ１６が生成された際に、どの第２サーバ鍵Ｄ１３を用いて第１ＭＡＣ値（チャレンジデータ）Ｄ１６が算出されたのかを把握するために、チャレンジバージョンＤ１４が用いられる。なお、チャレンジバージョンによって、第２サーバ鍵Ｄ１３の変更以外の、サーバ１および／またはクライアント３の各種処理を変更するようにしてもよい。この場合には、チャレンジに含まれるチャレンジバージョンＤ１４に応じて、処理の分岐が行われるようにしてもよい。

［ＰＣ４で用いられるデータ］
次に、図１７に、上述したＰＣ４の記憶部４２に記憶されるデータの一例を示す。すなわち、図３を用いて上述した証明書作成処理において用いられるデータの一例を示す。ＰＣ４の記憶部４２には、証明書生成・書込プログラムＦＣ５０１、マスターキーＤ０１（製造対象のクライアント３に対応するマスターキーＤ０１）、第１ＫＤＦシードデータＤ０３（製造対象のクライアント３に対応する第１ＫＤＦシードデータＤ０３）、４つの第１サーバー鍵Ｄ０７Ａ～Ｄ０７Ｄ、署名用鍵Ｄ０９、クライアントＩＤ＿Ｄ１０（製造対象のクライアント３に対応するクライアントＩＤ＿Ｄ１０）、第１特定パラメータＤ１１（製造対象のクライアント３に対応する第２ＫＤＦシードデータ特定用第１パラメータＤ１１）、が記憶される。

証明書生成・書込プログラムＦＣ５０１は、図３を用いて上述した証明書データＤ１０１を生成してクライアント３の不揮発記憶部３３に書き込むためのプログラムである。

なお、ＰＣ４で用いられる第２ＫＤＦシードデータ特定用第１パラメータＤ１１には、例えば、書き込み対象のクライアント３に応じた所定の値が予め設定されているものとする。

以下、ＰＣ４、クライアント３、サーバ１のそれぞれで行われる処理の詳細について、フローチャートを用いて説明する。なお、以下に示すフローチャートは、処理過程の単なる一例にすぎない。そのため、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよい。また、変数の値や、判定ステップで利用される閾値も、単なる一例であり、必要に応じて他の値を採用してもよい。

まず、上記ＰＣ４で実行される証明書生成・書込処理の詳細について説明する。図１８は、証明書生成・書込処理のフローチャートの一例である。まず、ＰＣ４の処理部４１は、変数であるカウンタ値ｎに０を設定する（ステップＳ２０１）。

次に、処理部４１は、マスターキーＤ０１、第１ＫＤＦシードデータＤ０３、クライアントＩＤ＿Ｄ１０を、証明書データＤ１０１の書き込み対象としているクライアント３から読み出し、記憶部４２に記憶する（ステップＳ２０２）。例えば、これらのデータは、ＰＣ４に接続されている、書き込み処理の対象となっているクライアント３から読み出される。なお、これらのデータは、クライアント３から読み出すのではなく、製造設備側で生成し、または、製造設備側の記憶装置から読み出すようにしてもよい。

次に、処理部４１は、マスターキーＤ０１、現在のカウンタ値ｎ、および第１ＫＤＦシードデータＤ０３に基づき、第１ＫＤＦ演算を行い、現在のカウンタ値ｎに対応する第１派生鍵ｎを生成する（ステップＳ２０３）。

次に、処理部４１は、生成された第１派生鍵ｎを、現在のカウンタ値ｎに対応する第１サーバ鍵Ｄ０７（カウンタ値ｎ時の鍵）で暗号化する（ステップＳ２０４）。

次に、処理部４１は、カウンタ値ｎに１を加算する（ステップＳ２０５）。

次に、処理部４１は、カウンタ値ｎが所定値より大きい値になったか否かを判定する（ステップＳ２０６）。本実施形態では、カウンタ値ｎは０～３の４つの値をとる場合を例示しているため、この所定値は３である。当該判定の結果、所定値より大きい値になっていない場合は（ステップＳ２０６でＮＯ）、上記ステップＳ２０３に戻り、処理が繰り返される。

一方、カウンタ値ｎが所定値より大きい値になった場合は（ステップＳ２０６でＹＥＳ）、処理部４１は、「４つの暗号化第１派生鍵Ｄ０８と、クライアントＩＤ＿Ｄ１０と、第１特定パラメータＤ１１」のハッシュ値、および、署名用鍵ＦＣ－Ｄ０９を用いて、署名Ｄ１２を作成する（ステップＳ２０７）。

次に、処理部４１は、４つの暗号化第１派生鍵Ｄ０８、クライアントＩＤ＿Ｄ１０、第１特定パラメータＤ１１を含み、上記で作成された署名Ｄ１２が付与された証明書データＤ１０１（図４参照）を作成する。さらに、処理部４１は、証明書データＤ１０１をクライアント３の不揮発記憶部３３に書き込む（ステップＳ２０８）。なお、所定のサーバや他のＰＣから証明書データをダウンロードまたは転送等して、クライアント３の不揮発記憶部３３に書き込んでも良い。

次に、認証処理の詳細について説明する。本実施形態において、認証処理は、チャレンジ発行セッションと検証セッションとにより構成される。チャレンジ発行セッションは、クライアント３からチャレンジ発行要求がされることで開始され、主に、チャレンジデータＤ１６をサーバ１で発行し、クライアント３に送信するためのセッションである（後述の通り、その他の処理も行われる）。検証セッションは、クライアント３から（レスポンスの検証を要求する）検証要求がされることで開始され、主に、クライアント３からレスポンスを送信し、サーバ１でこのレスポンスの検証を行い、その結果をクライアント３に送信するためのセッションである。本実施形態において、チャレンジ発行セッションと検証セッションは別の通信セッションである。なお、サーバ１について、複数台のサーバ装置で構成される場合、チャレンジ発行セッションと検証セッションは別のサーバ装置で実行されてもよい。チャレンジ発行セッションと検証セッションは異なる通信セッションであり、それら通信セッションは一連の処理ではない。それゆえに、発行したチャレンジがレスポンスの検証時にそのまま使えるわけではない。本実施形態では、チャレンジとともにチャレンジの元になったデータをクライアントに送信し、そのデータ（チャレンジの元になったデータ）をクライアントからレスポンスとともにサーバに返し、サーバではそのデータからチャレンジを再度生成することで発行したチャレンジとレスポンスとの関係を担保している。図１９から図３０を用いて、サーバ１の処理部１１とクライアント３の処理部３１が実行する処理を説明する。なお、図１９から図３０において説明する処理の順番は一例にすぎず、適宜順番を入れ替えても良い。また、複数の処理を並行して行っても良い。

［チャレンジ発行セッションの処理の詳細］
図１９は、チャレンジ発行セッションにおける処理の詳細を示す図である。図１９は、システムプログラム（認証機能）ＣＬ２０１を実行するクライアント３の処理部３１と認証プログラムＳＶ４０１を実行するサーバ１の処理部１１の処理を示す。図１９において、まず、クライアント３の処理部３１は、サーバ１との間でセッションを確立して、チャレンジ発行を要求する旨と証明書データＤ１０１とをネットワーク通信部３５を介して送信する処理を行う（ステップＳ１）。

次に、サーバ１の処理部１１は、ネットワーク通信部１５を介して証明書データＤ１０１を受信する処理を行う（ステップＳ２）。

次に、処理部１１は、署名Ｄ１２の検証を行う（ステップＳ３）。具体的には、処理部１１は、上記ＣＡ公開鍵ＳＶ４０６を用いて署名Ｄ１２を復号する。そして、復号結果を用いて、証明書データＤ１０１に含まれる上記４つの暗号化第１派生鍵Ｄ０８、クライアントＩＤ＿Ｄ１０、第１特定パラメータＤ１１が改ざんされていないことを判定し、一致していれば、検証の結果、肯定として判定する。なお、復号結果が一致しなかった場合は、否定として、チャレンジデータセットＤ１０２の送信は行わずに、その旨をクライアント３に通知して（通知せずに通信を打ち切ってもよい）、処理は終了する。

検証の結果、肯定であった場合は、処理部１１は、証明書データＤ１０１からクライアントＩＤ＿Ｄ１０を取り出す（ステップＳ４）。次に、処理部１１は、チャレンジ生成処理を実行する（ステップＳ５）。

図２０は、チャレンジ生成処理（ステップＳ５）の詳細を示すフローチャートである。まず、処理部１１は、サーバ１の現在時刻をチャレンジ発行時刻Ｄ１５として取得する（ステップＳ２１）。

次に、処理部１１は、記憶部１２から読み出したチャレンジバージョンＤ１４、ステップＳ２１で取得したチャレンジ発行時刻Ｄ１５、ステップＳ４で取得したクライアントＩＤ＿Ｄ１０を対象にして、チャレンジバージョンＤ１４に対応する第２サーバ鍵Ｄ１３を用いて第１ＭＡＣ値（チャレンジデータ）Ｄ１６を算出する（ステップＳ２２）。

次に、処理部１１は、チャレンジバージョンＤ１４と、チャレンジ発行時刻Ｄ１５と、ステップＳ２２で算出した第１ＭＡＣ値（チャレンジデータ）Ｄ１６とを含むチャレンジデータセットＤ１０２を生成する（ステップＳ２３）。以上で、チャレンジ生成処理は終了する。

図１９に戻り、チャレンジデータセットＤ１０２が生成されれば、処理部１１は、チャレンジデータセットＤ１０２をネットワーク通信部１５を介してクライアント３に送信する処理を行う（ステップＳ６）。

次に、クライアント３の処理部３１は、チャレンジデータセットＤ１０２をネットワーク通信部３５を介して受信する処理を行う（ステップＳ７）。その後、チャレンジ発行セッションは終了される（ステップＳ８）。

図２１は、検証セッションにおける処理の詳細を示す図である。まず、チャレンジデータセットＤ１０２を受信したクライアント３の処理部３１は、レスポンス生成処理を実行する（ステップＳ９）。

図２２は、クライアント３において実行される、レスポンス生成処理の詳細を示すフローチャートである。図２２において、まず、処理部３１は、第１派生鍵設定処理を実行する（ステップＳ３１）。

図２３は、上記第１派生鍵設定処理の第１の例を示すフローチャートである。図２３において、処理部３１は、マスターキーＤ０１、カウンタ値Ｄ０２、および、第１ＫＤＦシードデータＤ０３を記憶部３２から読み出す（ステップＳ４１）。

次に、処理部３１は、読み出したマスターキーＤ０１、カウンタ値Ｄ０２、第１ＫＤＦシードデータＤ０３に基づいて第１ＫＤＦの演算を行い、第１派生鍵Ｄ０５を生成する（ステップＳ４２）。以上で、第１派生鍵設定処理は終了する。

なお、事前に演算した第１派生鍵Ｄ０５を記憶部３２に記憶するようにしてもよいが、この態様の場合は、第１派生鍵設定処理として、図２４のように、処理部３１は、事前に記憶した第１派生鍵データを記憶部３２から読み出す（ステップＳ４３）ことにより、第１派生鍵を設定してもよい。つまり、クライアント３で第１ＫＤＦ演算済の第１派生鍵Ｄ０５をデータとして記憶している場合は、第１ＫＤＦを用いた演算処理が省略されてもよい。

図２２に戻り、次に、処理部３１は、第２派生鍵設定処理を実行する（ステップＳ３２）。図２５は、第２派生鍵設定処理の第１の例を示すフローチャートである。図２５において、処理部３１は、記憶部３２から第２ＫＤＦシードデータＤ０４を読み出す（ステップＳ５１）。次に、処理部３１は、第１派生鍵Ｄ０５および第２ＫＤＦシードデータＤ０４に基づいて第２ＫＤＦの演算を行い、第２派生鍵（クライアント）Ｄ０６を生成する（ステップＳ５２）。以上で、第２派生鍵設定処理は終了する。

なお、事前に演算した第２派生鍵（クライアント）Ｄ０６を記憶部３２に記憶するようにしてもよいが、この態様の場合は、図２６のように、処理部３１は、事前に記憶した第２派生鍵（クライアント）Ｄ０６のデータを記憶部３２から読み出す（ステップＳ５３）ことにより、第２派生鍵を設定してもよい。つまり、クライアント３で第２ＫＤＦ演算済のデータである第２派生鍵を記憶している場合は、第２ＫＤＦ演算の処理は省略されてもよい。また、この例の場合は、上記第１派生鍵設定処理自体も省略されてもよい。

本実施形態においては、第２派生鍵設定処理により設定された第２派生鍵（クライアント）がレスポンス生成処理においてレスポンスキー（クライアント）として使用される。

図２２に戻り、次に、処理部３１は、レスポンスデータ生成処理を実行する（ステップＳ３４）。図２７は、レスポンスデータ生成処理の詳細を示すフローチャートである。まず、処理部３１は、図１９のステップＳ８で受信したチャレンジデータセットＤ１０２から第１ＭＡＣ値（チャレンジデータ）Ｄ１６を読み出す（ステップＳ６１）。

次に、処理部３１は、第１ＭＡＣ値（チャレンジデータ）Ｄ１６と上記の通り設定されたレスポンスキー（クライアント）（第２派生鍵設定処理により設定された第２派生鍵（クライアント））とに基づいて、第２ＭＡＣ値（レスポンスデータ）Ｄ１７を算出する（ステップＳ６２）

次に、処理部３１は、図２１のステップＳ８で受信したチャレンジデータセットＤ１０２に含まれるチャレンジバージョンＤ１４、チャレンジ発行時刻Ｄ１５、および、上記で算出した第２ＭＡＣ値（レスポンスデータ）Ｄ１７とを含むレスポンスデータセットＤ１０３（上記図８参照）を生成する（ステップＳ６３）。以上で、レスポンスデータセット生成処理は終了する。

なお、ここでは、図２２のレスポンス生成処理として上記ステップＳ３１～Ｓ３４の処理が一連の流れで実行される例を示した。他の実施形態では、レスポンスキー（クライアント）を設定する処理（ステップＳ３１～Ｓ３２）は、事前に演算したものを記憶部３２に記憶しておき、ステップＳ９ではそれを読み出すようにしても良い。例えば、クライアント３の起動時に実行して、レスポンスキー（クライアント）のデータを記憶部３２に記憶しておき、ステップＳ９ではそれを読み出すようにしてもよい。

図２１に戻り、レスポンス生成処理が終われば、処理部３１は、サーバ１（同じサーバ装置でなくてもよい）との間で再度セッションを確立する。そして、処理部３１は、検証要求と、上記クライアント送信データＤ１０４とをネットワーク通信部３５を介してサーバ１に送信する処理を行う（ステップＳ１０）。すなわち、ステップＳ９で生成したレスポンスデータセットＤ１０３と、記憶部３２から読み出した証明書データＤ１０１と第２特定パラメータＤ１９とがサーバ１に送信される。なお、システムプログラム（認証機能）ＣＬ２０１は、証明書データＤ１０１が記憶される領域を指定する機能を有し、それにより指定された領域から証明書データＤ１０１を読み出すようにしても良い。また、レスポンス生成・送信プログラムは、第２特定パラメータＤ１９が記憶される領域を指定する機能を有し、それにより指定された領域から第２特定パラメータＤ１９を読み出すようにしても良い。また、システムプログラム（認証機能）ＣＬ２０１は、証明書データＤ１０１および／または第２特定パラメータＤ１９を所定のサーバまたはＰＣから取得（例えば、ダウンロード）する機能を有し、取得した証明書データＤ１０１および／または第２特定パラメータＤ１９を上記指定された領域に記憶するようにしても良い。

次に、サーバ１の処理部１１は、レスポンスデータセットＤ１０３、証明書データＤ１０１、第２特定パラメータＤ１９をネットワーク通信部１５を介して受信する処理を行う（ステップＳ１１）。

次に、処理部１１は、検証処理を実行する（ステップＳ１２）。図２８～図２９は、検証処理の詳細を示すフローチャートである。図２８において、まず、処理部１１は、受信した証明書データＤ１０１の署名Ｄ１２を検証する（ステップＳ７１）。この処理は上述した処理と同じであるため、詳細説明は割愛する。

署名検証に問題なければ、次に、処理部１１は、証明書データＤ１０１から第１特定パラメータＤ１１を取り出す（ステップＳ７２）。

次に、処理部１１は、取り出した第１特定パラメータＤ１１および、クライアント３から受信した第２特定パラメータＤ１９に基づき、第２ＫＤＦシードデータ特定テーブルＳＶ４０５を参照して、上記第２ＫＤＦシードデータＤ０４の値を特定する。また、処理部１１は、第１特定パラメータＤ１１および第２特定パラメータＤ１９に基づき、カウンタ値特定テーブルＳＶ４０４を参照して、カウンタ値Ｄ０２を特定する（ステップＳ７３）。

次に、処理部１１は、特定したカウンタ値Ｄ０２に対応する暗号化第１派生鍵Ｄ０８をクライアント３から受信した証明書データＤ１０１から取り出す（ステップＳ７４）。

次に、処理部１１は、取り出した暗号化第１派生鍵Ｄ０８に対して、上記特定したカウンタ値Ｄ０２に対応した第１サーバ鍵Ｄ０７を用いて、第１派生鍵Ｄ０５に復号する（ステップＳ７５）。

次に、処理部１１は、第１派生鍵Ｄ０５およびステップＳ７３で特定した第２ＫＤＦシードデータＤ０４の値に基づいて第２ＫＤＦの演算を行い、第２派生鍵（サーバ）Ｄ２０６を生成する。この第２派生鍵（サーバ）Ｄ２０６がレスポンスキー（サーバ）として使用される（ステップＳ７６）。すなわち、第２派生鍵Ｄ２０６の生成によりレスポンスキー（サーバ）が設定される。

次に、処理部１１は、ステップＳ１１で受信したレスポンスデータセットＤ１０３に含まれるチャレンジバージョンＤ１４、および、チャレンジ発行時刻Ｄ１５と、ステップＳ１１で受信した証明書データＤ１０１に含まれるクライアントＩＤ＿Ｄ１０と、チャレンジバージョンＤ１４に対応する第２サーバ鍵Ｄ１３とに基づき、第１ＭＡＣ値（検証時）Ｄ２１６を算出する（ステップＳ７７）

次に、処理部１１は、上記第１ＭＡＣ値（検証時）Ｄ２１６とステップＳ７６で設定されたレスポンスキー（サーバ）（ステップＳ７６で生成された第２派生鍵（サーバ）Ｄ２０６）とに基づき、第２ＭＡＣ値（検証時）Ｄ２１７を算出する（ステップＳ７８）。なお、この処理における演算アルゴリズムは、クライアント３における第２ＭＡＣ値演算のアルゴリズムと同じである。

次に、処理部１１は、クライアント３から受信した第２ＭＡＣ値（レスポンスデータ）Ｄ１７と、サーバ１で算出した第２ＭＡＣ値（検証時）Ｄ２１７とが一致するかを検証する（ステップＳ７９）。

次に、処理部１１は、上記検証の結果、一致したか否かを判定する（ステップＳ８０）。一致しなかった場合は（ステップＳ８０でＮＯ）、処理部１１は、クライアント３にエラーを返す処理を実行する（ステップＳ８３）。その後、検証処理は終了する。一方、一致した場合は（ステップＳ８０でＹＥＳ）、クライアント３から受信したレスポンスデータＤ１７の正当性があると考えられる。なお、ＭＡＣ値はクライアントＩＤが演算対象になっているため、第２ＭＡＣ値（レスポンスデータ）と第２ＭＡＣ値（検証時）が一致している場合、チャレンジ発行セッションにおいてチャレンジデータを発行した先のクライアントと、検証セッションにおいてレスポンスデータＤ１７等を送ってきたクライアントとが同じクライアント３である（一致性がある）と判断できる。なお、チャレンジ発行セッションにおけるクライアントＩＤと検証セッションにおけるクライアントＩＤのＩＤ自体を比較することは必要ではない。

ステップＳ８０でＹＥＳの場合、処理部１１は、時間的観点からの検証を行う。具体的には、処理部１１は、サーバ１の現在時刻が、受信したレスポンスデータセットＤ１０３に含まれるチャレンジ発行時刻Ｄ１５から一定時間以上経過しているか否かを判定する。当該判定の結果、経過している場合は（ステップＳ８１でＹＥＳ）、上記ステップＳ８３に処理が進められ、クライアント３にエラーを返す処理が実行される。一方、経過していない場合は（ステップＳ８１でＮＯ）、処理部１１は、クライアント３の正当性が確認でき、検証に成功したものとして、所定のサービストークンを生成する。その後、レスポンス検証処理は終了する。

なお、上記の例では、第２ＭＡＣ値の検証を行ってから、時間的観点からの検証を行う流れの例を示したが、この検証の順番は逆であってもよい。

図２１に戻り、レスポンス検証処理が終われば、次に、処理部１１は、検証に成功している場合は、所定のサービストークンをネットワーク通信部１５を介してクライアントに送信する処理を行う（ステップＳ１３）。

次に、クライアント３の処理部３１は、ネットワーク通信部３５を介してサービストークンを受信する処理を行う（ステップＳ１４）。その後、レスポンスセッションが終了される（ステップＳ１５）。

次に、処理部３１は、サービストークンを、アプリケーション、本実施形態ではオンラインゲームプログラムに渡す（ステップＳ１６）。これにより、オンラインゲームプログラムがこのサービストークンを用いて所定のサーバにサービスを要求することで、当該サーバからオンラインゲームのサービスが提供される。

なお、上記チャレンジ発行セッションに係る通信、および、検証セッションに係る通信は、どのような通信方式を用いてもよい。例えばＳＳＬ等の暗号化通信で行われてもよいし、非暗号化通信で行われてもよい。

次に、図３０を用いて、上述した認証処理を利用する、クライアント３におけるオンラインゲーム処理の一例を説明する。図３０において、まず、処理部３１は、オンラインゲームの開始要求を受け付ける（ステップＳ１０１）。例えば、処理部３１は、ユーザによりオンラインゲームの起動操作等を受け付ける。

次に、処理部３１は、システムソフトウェア（認証機能）を起動する(ステップＳ１０２)。これにより、上述したような認証処理が行われる。

次に、処理部３１は、サービストークンをシステムソフトウェアから受領したか否かを判定する（ステップＳ１０３）。当該判定の結果、受領していない場合は（ステップＳ１０３でＮＯ）、受領するまで待機する。

一方、サービストークンを受領すれば（ステップＳ１０３でＹＥＳ）、次に、処理部３１は、受領したサービストークンを利用してオンラインゲームサーバにサービスを要求する（ステップＳ１０４）。

その後、処理部３１は、必要に応じてオンラインゲームサーバや他のクライアント３と通信しながら、オンラインゲームを実行する（ステップＳ１０５）。次に、処理部３１は、オンラインゲームの終了条件が満たされたか否かを判定する（ステップＳ１０６）。満たされていなければ（ステップＳ１０６でＮＯ）、オンラインゲームの実行を継続し、満たされた場合は（ステップＳ１０６でＹＥＳ）、オンラインゲーム処理を終了する。

以上で、本実施形態に係る各処理の詳細説明を終了する。

［変形例］
なお、他の実施形態では、第１ＫＤＦのシードデータとしてカウンタ値を用いないような構成としてもよい。すなわち、上記マスターキーＤ０１と第１ＫＤＦシードデータＤ０３を用いて上記第１ＫＤＦの演算を行って、上記第１派生鍵Ｄ０５を生成するような構成としてもよい。この場合、証明書には、１つの暗号化第１派生鍵Ｄ０５が含まれることになる。また、カウンタ値の取りうる値は０～３に限られないことは言うまでもない。また、カウンタの代わりに所定の変数値を用いても良く、インクリメントの方式で変更されなくてもよい。

また、上記実施形態では、レスポンスキー設定処理において、第１ＫＤＦ演算と第２ＫＤＦ演算という、２段階でＫＤＦ演算を用いる例を示した。他の実施形態では、ＫＤＦ演算は１段階でもよいし、または、ＫＤＦ演算の段階をさらに増やし、第２ＫＤＦ演算の後に、更なるＫＤＦ演算を行った結果（派生鍵）をレスポンスキーとして設定してもよい。「更なるＫＤＦ演算」としては、例えば、クライアント３の揮発性メモリまたは不揮発性メモリ上のデータまたはそれを加工したデータをシードデータとするＫＤＦ演算を行ってもよい。このメモリ上のデータは、システムソフトウェアのバージョン毎に異なるデータであってもよい。

また、上記実施形態では、サーバ１におけるレスポンスキー設定処理において、第１特定パラメータＤ１１および第２特定パラメータＤ１９基づいて、第２ＫＤＦシードデータＤ０４を特定して用いていた。この点、他の実施形態では、これらのパラメータは用いずに、レスポンスキーを設定してもよい。例えば、１つのパラメータを用いて第２ＫＤＦシードデータを特定してもよいし、第２ＫＤＦシードデータ自体をクライアント３からサーバ１に送信してもよい。または、第２ＫＤＦシードデータが全クライアント共通の場合には、第２ＫＤＦシードデータをサーバ１に記憶しておけばよい。

また、上記実施形態では、第１ＫＤＦの演算をサーバ１で行わないようにしたが、サーバ１でマスターキーＤ０１および第１ＫＤＦシードデータを特定し、第１ＫＤＦの演算をサーバ１で行うようにしてもよい。その場合、証明書データＤ１０１内の暗号化第１派生鍵Ｄ０８は不要となる。この場合、マスターキーＤ０１を第１サーバ鍵で暗号化したデータを証明書データＤ１０１内に含めてもよい。そして、サーバ１においては、マスターキーＤ０１を復号し、上述した第１ＫＤＦの処理を実行して第１派生鍵Ｄ０５を得るようにすればよい。

また、チャレンジデータの生成に関して、上記の例では第２サーバ鍵を用いてＭＡＣ演算を行って第１ＭＡＣ値を算出する例を示した。他の実施形態では、ＭＡＣ演算の代わりに、署名を行うような構成としてもよい。例えばＲＳＡ署名を用いてもよい。

また、上記レスポンスキーを用いたレスポンスデータの生成に関して、上記第２ＭＡＣ値の演算の代わりに、ブロック化暗号化演算を用いてレスポンスデータを生成してもよい。ブロック化暗号化演算は、例えば、ＡＥＳであってもよい。

また、他の実施形態では、クライアント３がレスポンスデータＤ１７を送信する際にレスポンスデータＤ１７と共に、カウンタ値Ｄ０２の現在値を特定するためのパラメータとを送信するように構成してもよい。そして、サーバ１では、この送信されたパラメータを用いてカウンタ値Ｄ０２を特定して、上述したような処理でレスポンスキーを設定してもよい。

また、上記実施形態では、チャレンジ発行セッションと検証セッションを異なる通信セッションとしたが、１回のセッションでチャレンジ発行と検証を行ってもよい。

また、上記実施形態では、暗号化された派生鍵をクライアント証明書に含めたが、レスポンスデータ送信時に、クライアント証明書とは別に、暗号化された派生鍵をサーバに送信してもよい。第２ＫＤＦシードデータ特定用第１パラメータ同様である。また、第２ＫＤＦシードデータ特定用第２パラメータを証明書に含めてもよく、また、証明書等は別に署名を付与して送信してもよい。

本開示にかかる情報処理システムは、クライアントをデバイス認証するための新規な認証方法を提供できる。

１ サーバ
３ クライアント
４ ＰＣ
１１ 処理部
１２ 記憶部
１３ 不揮発記憶部
１４ 揮発記憶部
１５ ネットワーク通信部
１６ 操作デバイス
１７ 画像出力部
３１ 処理部
３２ 記憶部
３３ 不揮発記憶部
３４ 揮発記憶部
３５ ネットワーク通信部
３６ 操作デバイス
３７ 画像出力部
４１ 処理部
４２ 記憶部
４３ 不揮発記憶部
４４ 揮発記憶部
４５ ネットワーク通信部
４６ 操作デバイス
４７ 画像出力部

Claims (23)

1. ネットワークに接続されたクライアント、および、サーバを備え、前記クライアントおよび前記サーバとの間で、チャレンジ＆レスポンス方式により前記クライアントの認証処理を行う、情報処理システムであって、
   前記サーバは、チャレンジデータを発行し、前記クライアントへの送信を行う手段を備え、
   前記クライアントは、
   所定のサーバ鍵で暗号化された暗号化データを複数含む暗号化群データ、および、パラメータデータＡを記憶するメモリと、
   前記チャレンジデータの受信を行う手段と、
   クライアント側のレスポンスキーを用いて、前記受信されたチャレンジデータからレスポンスデータの生成を行う手段と、
   前記サーバに、前記生成されたレスポンスデータ、前記暗号化群データ、および、前記パラメータデータＡの送信を行う手段とを備え、
   前記サーバは、さらに、
   前記レスポンスデータ、前記暗号化群データ、および、前記パラメータデータＡの受信を行う手段と、
   前記受信したパラメータデータＡに基づいて、前記受信した暗号化群データのうち使用する暗号化データの選択を行う手段と、
   前記選択された暗号化データをサーバ鍵で復号化し、前記復号化したデータに基づいて、サーバ側のレスポンスキーの設定を行う手段と、
   前記チャレンジデータと前記設定されたサーバ側のレスポンスキーに基づいて、前記受信されたレスポンスデータの検証を行う手段と、
   前記クライアントに前記検証の結果の通知を行う手段とを備え、
   前記クライアントは、さらに、
   前記検証の結果を受信を行う手段を備える、情報処理システム。
2. 前記暗号化群データと前記パラメータデータＡはまとめて署名がされるデータであり、
   前記サーバは、前記署名の検証を行う手段をさらに備え、
   前記選択は、前記検証が行われた前記パラメータデータＡに基づいて、前記受信した暗号化群データのうち使用する暗号化データを選択するように構成され、
   前記サーバ側のレスポンスキーの設定は、前記署名の検証が行われた前記暗号化データに基づいて行われるように構成される、請求項１に記載の情報処理システム。
3. 前記暗号化群データは署名がされるデータであり、前記パラメータデータＡは署名がされないデータであり、
   前記サーバは、
   前記署名の検証を行う手段をさらに備え、
   前記サーバ側のレスポンスキーの設定は、前記署名の検証が行われた前記暗号化データに基づいて行われるように構成される、請求項１に記載の情報処理システム。
4. 前記暗号化群データに含まれる各暗号化データは、同一のマスターキーから生成される複数の派生鍵データである、請求項１に記載の情報処理システム。
5. 前記暗号化群データに含まれる各暗号化データは、マスターキーに加えて変動するパラメータ（以下、変動パラメータ）により、各暗号化データが異なるように生成される派生鍵データである、請求項１に記載の情報処理システム。
6. 前記サーバは、前記パラメータデータＡと前記暗号化データとの対応関係を示すデータ（以下、対応関係データと呼ぶ）をさらに記憶するメモリを備え、
   前記選択は、前記対応関係データを参照して、前記パラメータデータＡに基づいて前記暗号化データを選択するように構成される、請求項１に記載の情報処理システム。
7. 前記暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであり、
   前記サーバは、さらに、前記受信したパラメータデータＡに基づいてサーバ鍵の特定処理を行う手段を備え、
   前記復号化は、前記特定されたサーバ鍵に基づいて行われるように構成される、請求項１ないし６のいずれかに記載の情報処理システム。
8. 前記暗号化群データに含まれる各暗号化データは、前記サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を予め実行することにより生成されたデータであり、
   前記サーバ側のレスポンスキーの設定は、前記復号化したデータ、および、前記パラメータデータＡに基づいて、さらに所定の演算を行うことによって前記レスポンスキーを設定する処理である、請求項１ないし６のいずれかに記載の情報処理システム。
9. 前記メモリには、少なくとも前記暗号化群データ、前記パラメータデータＡ、および、非署名のパラメータデータＢがさらに記憶され、
   前記クライアントは、前記サーバに、前記パラメータデータＢを送信する手段をさらに備え、
   前記サーバにおける受信は、前記パラメータデータＢをさらに受信する処理であり、
   前記サーバは、前記署名の検証を行う手段をさらに備え、
   前記選択は、前記署名の検証が行われた前記パラメータデータＡ、および、前記パラメータデータＢに基づいて、前記受信した暗号化群データのうち使用する暗号化データを選択するように構成される、請求項２に記載の情報処理システム。
10. 前記暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであり、
    前記サーバは、さらに、前記署名の検証が行われた前記パラメータデータＡ、および、前記パラメータデータＢに基づいてサーバ鍵の特定を行う手段を備え、
    前記復号化は、前記特定されたサーバ鍵に基づいて行われるように構成される、請求項９に記載の情報処理システム。
11. 前記サーバは、前記パラメータデータＡおよび前記パラメータデータＢと前記暗号化データの対応関係を示すデータ（以下、対応関係データと呼ぶ）をさらに記憶するメモリを備え、
    前記選択は、前記対応関係データを参照して、前記署名の検証が行われた前記パラメータデータＡおよび前記パラメータデータＢに基づいて前記暗号化データを選択するように構成される、請求項９に記載の情報処理システム。
12. 前記暗号化群データに含まれる各暗号化データは、前記サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を予め実行することにより生成されたデータであり、
    前記サーバ側のレスポンスキーの設定は、前記復号化したデータ、前記パラメータデータＡ、および、前記パラメータデータＢに基づいて、さらに所定の演算を行うことによって前記レスポンスキーを設定する処理である、請求項９ないし１１のいずれかに記載の情報処理システム。
13. サーバとの間で、チャレンジ＆レスポンス方式により認証処理を行う、クライアントのコンピュータを、
    サーバからチャレンジデータの受信を行う手段と、
    クライアント側のレスポンスキーを用いて、前記受信されたチャレンジデータからレスポンスデータの生成を行う手段と、
    所定のサーバ鍵で暗号化されたサーバ側のレスポンスキーの設定のために用いられる暗号化データを複数含む暗号化群データ、および、前記暗号化群データのうち使用する暗号化データの選択に用いられるパラメータデータＡを前記クライアントのメモリから読み出す手段と、
    前記サーバに、前記生成されたレスポンスデータ、前記暗号化群データ、および、前記パラメータデータＡの送信を行う手段と、
    前記サーバから、前記暗号化群データのうち前記パラメータデータＡに基づいて選択された暗号化データを用いて行われる、前記レスポンスデータの検証の結果を受信する手段として機能させるためのプログラム。
14. 前記暗号化群データと前記パラメータデータＡはまとめて署名がされるデータである、請求項１３に記載のプログラム。
15. 前記暗号化群データは署名がされるデータであり、前記パラメータデータＡは署名がされないデータである、請求項１３に記載のプログラム。
16. 前記暗号化群データに含まれる各暗号化データは、同一のマスターキーから生成される複数の派生鍵データである、請求項１３に記載のプログラム。
17. 前記暗号化群データに含まれる各暗号化データは、マスターキーに加えて変動するパラメータ（以下、変動パラメータと呼ぶ）により、各暗号化データが異なるように生成される派生鍵データである、請求項１３に記載のプログラム。
18. 前記暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであり、前記パラメータデータＡは前記サーバ鍵の特定に用いられるデータである、請求項１３に記載のプログラム。
19. 前記暗号化群データに含まれる各暗号化データは、前記サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を予め実行することにより生成されたデータである、請求項１３ないし１８のいずれかに記載のプログラム。
20. 前記コンピュータをさらに、
    前記サーバに、前記選択に用いられる非署名のパラメータデータＢを送信する手段として機能させるための、請求項１３に記載のプログラム。
21. 前記暗号化群データに含まれる各暗号化データは、それぞれ異なるサーバ鍵で暗号化されたデータであり、前記パラメータデータＡおよび前記パラメータデータＢは前記サーバ鍵の特定に用いられるデータである、請求項２０に記載のプログラム。
22. 前記暗号化群データに含まれる各暗号化データは、前記サーバ側のレスポンスキーを設定するための演算のうちの少なくとも一部の演算を予め実行することにより生成されたデータである、請求項２０または２１に記載のプログラム。
23. ネットワークに接続されたクライアント、および、サーバを備え、前記クライアントおよび前記サーバとの間で、チャレンジ＆レスポンス方式による前記クライアントの認証方法であって、
    前記サーバは、チャレンジデータを発行し、前記クライアントへの送信を行い、
    前記クライアントは、
    前記チャレンジデータの受信を行い、
    クライアント側のレスポンスキーを用いて、前記受信されたチャレンジデータからレスポンスデータの生成を行い、
    前記サーバに、前記生成されたレスポンスデータ、所定のサーバ鍵で暗号化された暗号化データを複数含む暗号化群データ、および、パラメータデータＡの送信を行い、
    前記サーバは、さらに、
    前記レスポンスデータ、前記暗号化群データ、および、前記パラメータデータＡの受信を行い、
    前記受信したパラメータデータＡに基づいて、前記受信した暗号化群データのうち使用する暗号化データを選択し、
    前記選択された暗号化データをサーバ鍵で復号化し、前記復号化したデータに基づいて、サーバ側のレスポンスキーの設定を行い、
    前記チャレンジデータと前記設定されたサーバ側のレスポンスキーに基づいて、前記受信されたレスポンスデータを検証を行い、かつ、
    前記クライアントに前記検証の結果の通知を行い、
    前記クライアントは、さらに、
    前記検証の結果を受信を行う、認証方法。