(57)【要約】【課題】改ざんなど攻撃があった場合に攻撃内容を把握することができる認証方法及び認証システムを提供すること。【解決手段】一実施の形態にかかる認証方法は、サーバが、認証対象機器の識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値で構成した第１の認証情報を生成し、第１の認証情報を認証代行クライアントを介して認証対象機器へ送信し、認証対象機器が、識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値と、第１の認証情報とを比較することによって第１の認証情報の正当性を確認し、第１の認証情報の正当性を確認した後に、認証対象機器の識別子と共通鍵と第１の認証情報の確認結果とを引数とした疑似ランダム関数を用いて生成された値で構成した第２の認証情報を生成し、第２の認証情報を前記認証代行クライアントへ送信する。【選択図】図１
2018196085.tif 000002
【特許請求の範囲】
【請求項１】
サーバは、認証対象機器の識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値で構成した第１の認証情報を生成し、前記第１の認証情報を認証代行クライアントを介して前記認証対象機器へ送信し、
前記認証対象機器は、前記識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値と、前記第１の認証情報とを比較することによって前記第１の認証情報の正当性を確認し、前記第１の認証情報の正当性を確認した後に、前記認証対象機器の識別子と共通鍵と前記第１の認証情報の確認結果とを引数とした疑似ランダム関数を用いて生成された値で構成した第２の認証情報を生成し、前記第２の認証情報を前記認証代行クライアントへ送信する、認証方法。
【請求項２】
前記認証代行クライアントは、前記第２の認証情報を前記サーバへ送信し、
前記サーバは、前記第２の認証情報の正当性を確認する、請求項１に記載の認証方法。
【請求項３】
前記サーバは、前記第１の認証情報を生成する際の時刻に関する第１の時間情報を生成し、前記認証対象機器の識別子と前記共通鍵と前記第１の時間情報とを引数とした疑似ランダム関数を用いて生成された値で構成した前記第１の認証情報を生成する、請求項１に記載の認証方法。
【請求項４】
前記認証対象機器は、前記認証代行クライアントが前記第１の認証情報を受信した時刻に関する第２の時間情報と前記認証対象機器の識別子と前記共通鍵と前記第１の認証情報の確認結果とを引数とした疑似ランダム関数を用いて生成された値で構成した前記第２の認証情報を生成する、請求項１に記載の認証方法。
【請求項５】
前記認証対象機器は、前記第１の認証情報の正当性として、前記第１の認証情報のデータの長さが規定値通りであるか否かを判定し、
前記認証代行クライアントは、前記第１の認証情報のデータの長さが規定値通りであるか否かの判定結果を含む第２の認証情報を前記サーバへ送信する、請求項３に記載の認証方法。
【請求項６】
前記認証対象機器は、前記第１の時間情報と、前記認証代行クライアントが前記第１の認証情報を受信した時刻に関する第２の時間情報との差分が、予め定められた時間制約を満たしているか否かを確認する、請求項３に記載の認証方法。
【請求項７】
前記サーバは、前記第２の時間情報と、前記認証代行クライアントが前記第２の認証情報を受信した時刻に関する第３の時間情報との差分が、予め定められた時間制約を満たしているか否かをする、請求項４に記載の認証方法。
【請求項８】
前記サーバは、前記第１の認証情報の使用回数を制限するモノトニック・カウンタを用いる、請求項１に記載の認証方法。
【請求項９】
前記サーバは、前記モノトニック・カウンタが示す値を用いて前記第１の認証情報を生成する、請求項８に記載の認証方法。
【請求項１０】
前記認証代行クライアントは、複数の前記認証対象機器の識別子を前記サーバに送信し、
前記サーバは、それぞれの前記認証対象機器に関する前記第１の認証情報を生成する、請求項１に記載の認証方法。
【請求項１１】
前記認証対象機器は、前記第１の認証情報を受信した時刻に関する第４の時間情報と前記認証対象機器の識別子と前記共通鍵と前記第１の認証情報の確認結果とを引数とした疑似ランダム関数を用いて生成された値で構成した前記第２の認証情報を生成する、請求項１に記載の認証方法。
【請求項１２】
前記認証代行クライアントは、前記認証対象機器の識別子とともに自装置の識別子を前記サーバに送信し、
前記サーバは、前記第１の認証情報とともに、前記認証代行クライアントの識別子と前記共通鍵とを引数とした疑似ランダム関数を用いて生成された値で構成した第３の認証情報を生成する、請求項１に記載の認証方法。
【請求項１３】
認証代行クライアントは、収集した認証対象機器の識別子と通信の対応関係を識別するためのセッション識別子とをサーバに送信し、
前記サーバは、前記認証対象機器の識別子及び前記セッション識別子の正当性を確認する、請求項１に記載の認証方法。
【請求項１４】
認証対象機器と、
前記認証対象機器に対して共通鍵を選択するサーバと、
前記認証対象機器と前記サーバとの間の通信を中継する認証代行クライアントと、を備え、
前記サーバは、前記認証対象機器の識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値で構成した第１の認証情報を生成し、前記第１の認証情報を前記認証代行クライアントを介して前記認証対象機器へ送信し、
前記認証対象機器は、前記識別子と共通鍵とを引数とした疑似ランダム関数を用いて生成された値と、前記第１の認証情報とを比較することによって前記第１の認証情報の正当性を確認し、前記第１の認証情報の正当性を確認した後に、前記認証対象機器の識別子と共通鍵と前記第１の認証情報の確認結果とを引数とした疑似ランダム関数を用いて生成された値で構成した第２の認証情報を生成し、前記第２の認証情報を前記認証代行クライアントへ送信する、認証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は認証方法及び認証システムに関し、例えば認証代行クライアントを用いた認証方法及び認証システムに関する。
【背景技術】
【０００２】
ネットワーク接続機器が特にインターネットなど公衆回線網に接続されている場合、当該機器は常に不可視かつ検出不能なセキュリティ攻撃にさらされる事となる。実際、セキュリティの先端研究では、インシデント発生に先立って検出する事が出来ないマルウェアなどによる攻撃を、振る舞い異常検知で如何にして行うかの議論がなされている。以前と比べて比較にならないほど、公衆回線網にはセキュリティ・リスクがあり、接続＝感染、と考えるべきで状態ある。
【０００３】
特許文献１には、車両盗難防止システムのチャレンジレスポンス認証処理において、PUF（Physical Uncloanable Function）を搭載した被認証機器を用いる仕組みが開示されている。具体的には、電子キーから鍵登録サーバへ認証情報構成に必要となる情報を送付し、鍵登録サーバがオフライン認証チャレンジコードを作成し車両盗難防止装置へ送付する。車両盗難防止装置は、電子キーへUID要求を実施し、電子キーからUIDを受信するとオフライン認証チャレンジコードを電子キーへ送信する。電子キーがレスポンスコードを生成し車両盗難防止装置へ送付すると、車両盗難防止装置は電子キーのオフライン認証処理を実施し、認証に成功すると、車両のドアロックを解除する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−３６２５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の車両盗難防止システムにおいては、改ざんなど攻撃があった場合にサーバ等が攻撃内容を把握することができないという問題がある。
【０００６】
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００７】
一実施の形態によれば、認証対象機器、認証代行クライアント、及びサーバを含む認証システムにおいて実行される認証方法は、認証対象機器が、サーバにおいて生成された第１の認証情報の正当性を確認し、さらに、認証機器が、第２の認証情報を生成し、生成した第２の認証情報を認証代行クライアントへ送信するものである。
【０００８】
なお、上記実施の形態の方法を装置やシステムに置き換えて表現したもの、該装置または該装置の一部の処理をコンピュータに実行せしめるプログラムなども、本発明の態様としては有効である。
【発明の効果】
【０００９】
前記一実施の形態によれば、改ざんなど攻撃があった場合に攻撃内容に関する情報を含む認証情報を生成することができる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態１にかかるオフライン認証プロトコルの流れを示す図である。
【図２】実施の形態１にかかるオフライン認証プロトコルの流れを示す図である。
【図３】実施の形態１にかかる中間者による攻撃例を説明する図である。
【図４】実施の形態１にかかる中間者による攻撃例を説明する図である。
【図５】実施の形態１にかかるオフライン認証プロトコルの攻撃耐性示す図である。
【図６】実施の形態１にかかるオフライン認証プロトコルの攻撃耐性示す図である。
【図７】実施の形態１にかかる中間者による攻撃例を説明する図である。
【図８】実施の形態１にかかるオフライン認証プロトコルの攻撃耐性示す図である。
【図９】実施の形態１にかかるオフライン認証プロトコルの流れを示す図である。
【図１０】実施の形態１にかかる中間者による攻撃例を説明する図である。
【図１１】実施の形態１にかかるオフライン認証プロトコルの攻撃耐性示す図である。
【図１２】実施の形態２にかかるオフライン認証プロトコルの流れを示す図である。
【図１３】実施の形態２にかかるオフライン認証プロトコルの流れを示す図である。
【図１４】実施の形態３にかかるオフライン認証プロトコルの流れを示す図である。
【図１５】実施の形態３にかかるオフライン認証プロトコルの流れを示す図である。
【図１６】実施の形態４にかかるオフライン認証プロトコルの流れを示す図である。
【図１７】実施の形態４にかかるオフライン認証プロトコルの流れを示す図である。
【図１８】実施の形態４にかかるオフライン認証プロトコルの流れを示す図である。
【図１９】実施の形態４にかかるオフライン認証プロトコルの流れを示す図である。
【図２０】それぞれの実施の形態にかかる認証対象機器、認証代行クライアント、及びサーバの構成図である。
【発明を実施するための形態】
【００１１】
図１のシーケンス図を用いて、オフライン認証プロトコルの動作を以下に示す。尚、認証対象機器に対する共通対称鍵の初期設定として、下記設定が事前になされているものとする。
【００１２】
セキュリティパラメータをk としサーバは1^k を入力とする。サーバは認証識別子IDi ∈ {0,1}^k が割り振られている認証対象機器に対して対象鍵 ski ← {0,1}^k を選び、(ski,IDi) を送付する。認証対象機器は(ski,IDi)を不揮発性メモリに保存する。また、認証識別子IDの集合ID を認証代行クライアントに送付する。ここで、認証対象機器の総数をNとし、i ∈ [1,N]とする。例えば、認証対象機器を出荷する前にこれら処理を実施する事で、各認証対象機器に個別の鍵を設定するとともに、サーバに同鍵を格納しても良い。また、認証代行クライアントは事前に認証対象機器のIDを収集しているものとする。
【００１３】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは、認証対象機器からIDを受信すると（Ｓ１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ２）、(1,rp,ID) をサーバに送付する（Ｓ３）。サーバは(1,rp,ID) を受け取ると、下記手順（Ｓ４）を実施する。
【００１４】
1. rp,ID ∈ {0,1}^k であるか、そしてID ∈ ID であるかを検証する。もし異なっていれば処理を終了する。もし満たしていれば、以下を実行する。
2. 現在の時刻をtss ← TimeStamp として選ぶ。
3. 乱数をrh ← {0,1}^k として選ぶ。
4. r1 := PRF(sk,tss||ID||rh) を計算する。そして、サーバはData1 := (tss,ID,rh,r1) として認証代行クライアントに(1,rp,Data1)を送付する（Ｓ５）。ここでPRFは疑似ランダム関数(Pseudo Random Function)、演算子’||’はビット連接を表す。
【００１５】
(2) 認証対象機器での認証と結果収集
認証代行クライアントは現在の時刻をtsp ← TimeStamp として選び（Ｓ６）、(rp,tsp,Data1) を認証対象機器に送付する（Ｓ７）。認証対象機器は(rp,tsp,Data1 = (tss,ID,rh,r1)) を受け取ると、下記手順（Ｓ８）を実施する。
【００１６】
1. rp,tsp,tss,ID,rh,r1 ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、ID が自身のものと一致するかを確かめる。ここで、データは必要に応じて適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rc := rc||result1,r2 ← {0,1}^k とする。もし満たしている場合は、以下の操作を実行する。
2. r1 = PRF(sk,tss||ID||rh) が満たされるかを検証する。もし満たしていた場合はresult1 := 01 とし、そうでなければresult1 := 10 とする。
3. 乱数をrc ← {0,1}^(k-2) として選び、rc := rc||result1 ∈ {0,1}^k とする。
4. r2 := PRF(ski,tss||tsp||ID||rh||rc) を求める。そして、認証対象機器はData2 := (tss,ID,rh,rc,r2) として(rp,tsp,Data2) を認証代行クライアントに送付する（Ｓ９）。
【００１７】
尚サーバから認証代行クライアントへの送付に時間制約がある場合であってtspが信頼できる場合は、上記1のサイズチェック時に、tssとtspを比較する事で、その確認を実施しても良い。また、認証対象機器での認証処理への時間制約があり、認証代行クライアントの時計が信頼できる場合は、サーバは、tspと認証対象機器からの認証結果の受取り時刻(以下、tsp2と記載)を比較する事で、その確認を実施しても良い
【００１８】
(3) サーバでの認証結果の検証
認証代行クライアントは(2,rp,tsp,Data2) をサーバに送付する（Ｓ１０）。サーバは(2,rp,tsp,Data2 = (tss,ID,rh,rc,r2)) を受け取ると、rp,tss,tsp,ID,rh,rc,r2 ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とする。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、r2 = PRF(sk,tss||tsp||ID||rh||rc) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。そしてresult2 を認証結果として出力し、これを記録する（Ｓ１１）。
【００１９】
ここで、result2が01なら認証対象機器で認証成功、result2が10なら認証失敗、result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
【００２０】
尚、サーバから認証代行クライアントへ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、上記サイズチェック時に、tssとサーバでの現在時刻を比較する事で、その確認を実施しても良い。また、認証代行クライアントからの認証結果のサーバへの送付に時間制約があり、認証代行クライアントの時計が信頼できる場合は、tsp2を追加で認証代行クライアントからサーバへ送付し、サーバは、tsp2とtssを比較する事で、その確認を実施しても良い。
【００２１】
本プロトコルではrpが改竄されると、対応するセッションが非存在となるか、存在しても異なるセッションでの認証対象機器での認証が実施される事となり失敗するためフェールセーフである。rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄してもサーバで検証合格とする事はできない。tspを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【００２２】
即ち、rp、rc、tspの何れを改竄しても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。rp,rh,rcの全てまたは何れかが改竄された場合、例えば、サーバは、何らかの改竄があった事を検知可能である。
【００２３】
改竄による認証失敗や検証不合格を効率よく検出する目的で、tspに対してハッシュ値を付加しても良い。
【００２４】
上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスで実施される。図２の各メッセージの実行は、以下に定義された動作にて行われる。
ITU-TS Recommendation Z.120: Message Sequence Chart (MSC), ITU-TS, Geneva, 2011.
ITU-TS Recommendation Z.120: Message Sequence Chart (MSC) Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva, 1995.
【００２５】
（オフライン認証プロトコルが満たすべき安全性と対策）
認証処理時に考慮すべき安全性として、中間者攻撃とリプレイ攻撃がある。
【００２６】
図３に、通信路で盗聴（オフラインなら窃盗）され、送付データ改ざんによる中間者攻撃例を示す。窃盗での改ざんによる誤認証のシナリオは例えば下記である。
1. 車載ゲートウェイなどによる認証対象機器のIDの収集
2. 車載ゲートウェイなどによる収集IDの認証サーバへの送付
2'. IDを中間攻撃者が改ざんし、認証サーバへ送付
3'. 認証サーバは、受け取った改ざんIDに対して正規の認証情報を応答
3. 中間攻撃者が偽の認証情報にすり替え、車載ゲートウェイなどへ応答
4. 車載ゲートウェイなどによる偽の認証情報を用いた機器認証
5. 車載ゲートウェイなどによる機器認証結果の認証サーバへの送付
5'. 機器認証結果を中間攻撃者が改ざんし、認証サーバへ送付
【００２７】
上記で、認証サーバが機器認証を検証通過として識別した場合、中間攻撃者の攻撃は成功となる。例えば、認証対象機器を非正規品へ置き換える事が可能となる。また、認証対象機器の認証に成功し、かつ認証サーバが機器認証を検証通過として識別した場合も、中間攻撃者の攻撃は成功となる。例えば、不正ユーザの機器利用が可能となる。
【００２８】
図４に、例えば車載内の中継器であるゲートウェイや他制御機器にマルウェアが仕込まれ、攻撃対象とされている認証対象機器や認証サーバに偽の情報を送付する事で、誤認証させる攻撃例を示す。本例でのシナリオは例えば下記である。
1. マルウェアが偽の認証情報を用いて、認証対象機器の認証を実施
2. マルウェアが偽の認証情報を認証サーバへ送付
【００２９】
中間攻撃者の攻撃の成否は、図３と同様である。安全性として考慮すべきシナリオとして、以下が、中間者攻撃を用いた攻撃手法として挙げられる。
ケース1. 認証対象機器へ送付するメッセージ長の変更、
ケース2. 認証対象機器へ送付するッセージの中身の変更、
ケース3. 認証サーバへ送付するメッセージ長の変更、
ケース4. 認証サーバへ送付するメッセージの中身の変更
【００３０】
図５に、図1のオフライン認証プロトコルでケース1、ケース2への対策がなされている事を示す。具体的には、ケース1への対応として、認証対象機器では、先ずメッセージ長の検証を実施しており、メッセージ長変更による攻撃を排除している。さらに、ケース2への対応として、認証対象機器では、メッセージの改ざん検知を擬似ランダム関数を用いた検証で実施しており、メッセージの中身の変更による攻撃を排除している。
【００３１】
図６に、図1のオフライン認証プロトコルでケース3、ケース4への対策がなされている事を示す。具体的には、ケース3への対応として、認証サーバでは、先ずメッセージ長の検証を実施しており、メッセージ長変更による攻撃を排除している。さらに、ケース4への対応として、認証サーバでは、メッセージの改ざん検知を擬似ランダム関数を用いた検証で実施しており、メッセージの中身の変更による攻撃を排除している。
【００３２】
図７に、中間攻撃者が、認証サーバから送信されたデータを使いまわし、本来認証すべき認証対象機器ではない別の端末に認証情報に手を加えずに送付し、その結果をそのままサーバに中継することで、本来認証すべき認証対象機器に対する認証をすり抜けさせる、送付先変更によるリプレイ攻撃例を示す。送付先変更によるリプレイ攻撃での誤認証のシナリオは例えば下記である。
1. 車載ゲートウェイなどによる認証対象機器のID:AAAを収集
2. 車載ゲートウェイなどによる収集ID:AAAの認証サーバへの送付
2'. 中間攻撃者がID:AAAを認証サーバへ送付
3. 認証サーバは、ID:AAAに対して正規の認証情報を応答
3'. 中間攻撃者が偽の認証情報にすり替え、車載ゲートウェイなどへ応答
4. 車載ゲートウェイなどによるすり替えられた認証情報を用いたID:BBBの機器認証
5. 車載ゲートウェイなどによるID:BBBの機器の機器認証結果の認証サーバへの送付
5'. ID:BBBの機器認証結果を中間攻撃者が、認証サーバへ送付
【００３３】
上記で、認証サーバが機器認証を検証通過として識別した場合、中間攻撃者の攻撃は成功となる。例えば、認証対象機器を非正規品へ置き換える事が可能となる。
【００３４】
安全性として考慮すべきシナリオとして、以下が、リプレイ攻撃（送付先の変更）を用いた攻撃手法として挙げられる。
ケース5. 異なる認証対象機器への送付
【００３５】
図８に、図1のオフライン認証プロトコルでケース5への対策がなされている事を示す。具体的には、ケース5への対応として、認証対象機器では、先ず認証対象機器のIDが一致するかの検証を実施しており、異なる認証対象機器への送付による攻撃を排除している。
【００３６】
（ワンタイム・オフライン認証プロトコル）
【００３７】
図１に示すオフライン認証プロトコルの場合、認証代行クライアントに格納された認証情報は、対応する認証対象機器の認証に何度でも利用可能だという問題がある。認証回数を制限する方法も考えられるが、その部分が改ざんされると認証情報の悪用が可能となる。そこで、モノトニック・カウンタを導入する事でワンタイム認証、即ち各認証情報での認証対象機器での認証を高々1回に制限する拡張を図９に示す。
【００３８】
以下に、図１からの変更点を主に記載する。尚、サーバと認証対象機器に対するモノトニック・カウンタ（サーバ：cnt[j]、認証対象機器：pre_cnt[j](∀j∈[1,N])）がそれぞれ事前に０に初期設定されているものとする。また、モノトニック・カウンタ値は、自動更新されユーザが変更できないものとする。カウントアップによるオーバーフローにより０になる以外の方法では、一番最初の初期化を除いてリセットや電源遮断などでは０に変更できないものとする。
【００３９】
ここで、図９では、明示的にモノトニック・カウンタを導入しているが、サーバ時刻tssでそれを代替しても良い。また、認証代行クライアントは事前に認証対象機器のIDを収集しているものとする。
【００４０】
(1) 機器認証情報のサーバでの構築:
・認証代行クライアントは、認証対象機器からIDを受信すると（Ｓ２１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ２２）、(1,rp,ID) をサーバに送付する（Ｓ２３）。サーバは(1,rp,ID) を受け取ると、下記手順（Ｓ２４）を実施する。
【００４１】
1. rp,ID ∈ {0,1}^k であるか、そしてID ∈ ID であるかを検証する。もし異なっていれば処理を終了する。もし満たしていれば、以下を 実行する。
2. 現在の時刻をtss ← TimeStamp として選ぶ。
3. 乱数をrh ← {0,1}^k-m、rh:=rh||cnt[ID] として選ぶ。ここでcnt[ID]は、IDに対応する初期値０のモノトニック・カウンタ値である。
4. r1 := PRF(sk,tss||ID||rh) を計算する。そして、サーバはData1 := (tss,ID,rh,r1) として認証代行クライアントに(1,rp,Data1) を送付する（Ｓ２５）。送付後、cnt[ID]をインクリメントする。ここでPRFは疑似ランダム関数(Pseudo Random Function)、演算子’||’はビット連接を表す。
【００４２】
(2) 認証対象機器での認証と結果収集
認証代行クライアントは現在の時刻をtsp ← TimeStamp として選び（Ｓ２６）、(rp,tsp,Data1)を認証対象機器に送付する（Ｓ２７）。認証対象機器は(rp,tsp,Data1 = (tss,ID,rh,r1)) を受け取ると、下記手順（Ｓ２８）を実施する。
【００４３】
1. rp,tsp,tss,ID,rh,r1 ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、ID が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rc := rc||result1,r2 ← {0,1}^k とする。もし満たしている場合は、以下の操作を実行する。
2. r1 = PRF(sk,tss||ID||rh) が満たされるかを検証する。もし満たしていた場合は以下の処理を実施し、そうでなければresult1 := 10 として処理を4へ移行する。
3. cnt[ID]>pre_cnt[ID]またはcnt[ID]==0∧pre_cnt[ID]+1==0であるか 確認し、もし満たしている場合は、 result1 := 01とし、pre_cnt[ID]:=cnt[ID]とする。満たしていない場合は、result1:=11とする。ここで、pre_cnt[ID]はIDに対応する認証対象機器が持つ初期値０のモノトニック・カウンタである。
4. 乱数をrc ← {0,1}^(k-2) として選び、rc := rc||result1 ∈ {0,1}^k とする。
5. r2 := PRF(ski,tss||tsp||ID||rh||rc) を求める。そして、認証対象機器はData2 := (tss,ID,rh,rc,r2) として(rp,tsp,Data2) を認証代行クライアントに送付する（Ｓ２９）。
【００４４】
尚サーバから認証代行クライアントへの送付に時間制約がある場合であってtspが信頼できる場合は、上記1のサイズチェック時に、tssとtspを比較する事で、その確認を実施しても良い。また、認証対象機器での認証処理への時間制約があり、認証代行クライアントの時計が信頼できる場合は、サーバは、tspと認証対象機器からの認証結果の受取り時刻(以下、tsp2と記載)を比較する事で、その確認を実施しても良い。
【００４５】
(3) サーバでの認証結果の検証:
認証代行クライアントは(2,rp,tsp,Data2) をサーバに送付する（Ｓ３０）。サーバは(2,rp,tsp,Data2 = (tss,ID,rh,rc,r2))を受け取ると、rp,tss,tsp,ID,rh,rc,r2 ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とする。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、r2 = PRF(sk,tss||tsp||ID||rh||rc) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。そしてresult2 を認証結果として出力し、これを記録する（Ｓ３１）。
【００４６】
ここで、result2が01なら認証対象機器で認証成功、result2が11なら認証情報の再利用による認証失敗、result2が10なら擬似ランダム関数値不一致による認証失敗、 result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
【００４７】
尚、サーバから認証代行クライアントへ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、上記サイズチェック時に、tssとサーバでの現在時刻を比較する事で、その確認を実施しても良い。また、認証代行クライアントからの認証結果のサーバへの送付に時間制約があり、認証代行クライアントの時計が信頼できる場合は、tsp2を追加で認証代行クライアントからサーバへ送付し、サーバは、tsp2とtssを比較する事で、その確認を実施しても良い。
【００４８】
本プロトコルではrpが改竄されると、対応するセッションが非存在となるか、存在しても異なるセッションの認証対象機器での認証が実施される事となり失敗するためフェールセーフである。rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄しても、サーバで検証合格とする事はできない。tspを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【００４９】
rp、rc、tspの何れが改竄されても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。rp,rh,rcの全てまたは何れかが改竄された場合、何らかの改竄があった事を検知可能である。
【００５０】
改竄による認証失敗や検証不合格を効率よく検出する目的で、tspに対してハッシュ値を付加しても良い。
【００５１】
上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスと同様に定義される。
【００５２】
（ワンタイム・オフライン認証プロトコルが満たすべき安全性と対策）
図９に示したワンタイム・オフライン認証プロトコルが、ケース1〜ケース5への攻撃耐性がある事は、プロトコルの構成の仕方から明らかである。ここでは、考慮すべき安全性として新たに同一データの使いまわしによるリプレイ攻撃を示す。
【００５３】
図１０に、中間攻撃者が認証サーバから一度得たデータを使いまわし、認証対象機器に対して同一データを何度も送付することで、いつでも好きなときに認証に成功させ、認証対象機器が保有する当該機能を好きなときに実行させる攻撃例を示す。
【００５４】
当該攻撃のシナリオ例は、中間攻撃者がID認証で得た正規認証情報:CCCを何度も使いまわし、認証情報:CCCで実行可能な動作を好きなタイミングで実行する攻撃となる。
【００５５】
安全性として考慮すべきシナリオにおいて、リプレイ攻撃（同一データの使い回し）を用いた攻撃手法として以下が挙げられる。
ケース6.使い回しによる該当認証対象機器への複数回の送付
【００５６】
図１１に、図９のワンタイム・オフライン認証プロトコルでケース6への対策がなされている事を示す。ケース6への対応として、認証対象機器では、カウンタ値の検証を実施しており、カウンタ値は機器認証の度に値が増加するよう更新される事から同じ認証情報を使い回しての攻撃を排除している。
【００５７】
以上説明したように、実施の形態１において説明したオフライン認証プロトコルを実行することによって下記の効果を得ることができる。
【００５８】
1)事前にサーバ及び認証対象機器が共通鍵を保有しているとことを前提とする。この場合、認証代行者（認証代行クライアント）は、収集した認証対象機器の識別子情報と通信の対応関係を識別するためのセッション識別子をサーバに送付し、サーバで前記認証対象機器の識別子と共通鍵とから認証情報を構築する。サーバは、認証情報を認証代行者へ返し、認証代行者が識別情報を用いて認証対象機器の認証を実施する。認証代行者は、認証情報に不備が無い事を確認後に実施した認証結果が成否何れの場合であっても、共通鍵を用いた疑似ランダム関数で構成した認証結果をサーバに応答し、サーバで認証結果の検証を行う事で、認証対象機器の認証をセキュアに実現することができる。
【００５９】
2)サーバは、認証結果検証にて暗号復号処理が不要となる。
【００６０】
3)通信路を対象とした署名発行検証を伴わなくても、サーバでの認証結果検証にて、認証対象機器の認証合否のみならず、認証対象機器からサーバへの認証結果送付にて改竄検知が可能となる。
【００６１】
4)認証情報の使いまわしによる攻撃抑止が可能となる。
【００６２】
（実施の形態２）
図１２のシーケンス図を用いて、実施の形態２にかかるオフライン認証プロトコルの動作を以下に示す。尚、認証対象機器に対する共通対称鍵の初期設定として、下記設定が事前になされているものとする。
【００６３】
セキュリティパラメータをk としサーバは1^k を入力とする。サーバは認証識別子IDi ∈ {0,1}^k が割り振られている認証対象機器に対して対象鍵 ski ← {0,1}^k を選び、(ski,IDi) を送付する。認証対象機器は(ski,IDi)を不揮発性メモリに保存する。また、認証識別子IDの集合ID を認証代行クライアントに送付する。ここで、認証対象機器の総数をNとし、i ∈ [1,N]とする。例えば、認証対象機器を出荷する前にこれら処理を実施する事で、各認証対象機器に個別の鍵を設定するとともに、サーバに同鍵を格納しても良い。また、認証代行クライアントは事前に認証対象機器のIDを収集しているものとする。
【００６４】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは、認証対象機器からIDを受信すると（Ｓ４１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ４２）、認証対象機器群のIDの集合｛IDi; i∈[1,N]}とともに、(1,rp, ｛IDi; i∈[1,N]}) をサーバに送付する（Ｓ４３）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００６５】
サーバは(1,rp, ｛IDi; i∈[1,N]}) を受け取ると、下記手順（Ｓ４４）を実施する。
1. 現在の時刻をtss ← TimeStamp として選ぶ。
cnt:=1、Data1:=Φ(空集合)とする。
2. 各 i ∈ [1,N]に対して、下記3,4,5,6を実施する。
3. rp,IDi ∈ {0,1}^k であるか、そしてIDi ∈ ID であるかを検証する。もし異なっていれば cntをインクリメントし処理を6に移行する。もし満たしていれば、以下を実行する。
4. 乱数をrhi ← {0,1}^k として選ぶ。
5. r1i := PRF(ski,tss||IDi||rhi) を計算する。
6. Data1 := (IDi,rhi,r1i)∪Data1 とし、iをインクリメントする。ここで、演算子’||’はビット連接を表す。
7. cnt==Nなら処理を終了し、そうでないならば、Data1 := (tss)∪Data1として認証代行クライアントに(1,rp,Data1) を送付する（Ｓ４５）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００６６】
(2) 認証対象機器での認証と結果収集:
認証代行クライアントは現在の時刻をtsp ← TimeStamp として選び（Ｓ４６）、(rp,tsp,Data1) を認証対象機器に送付する（Ｓ４７）。
【００６７】
認証対象機器は(rp,tsp,Data1 = {(tss,IDi,rhi,r1i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ４８）を実施する。本受取りは、ネットワーク経由ではなく情報を書き込んだ記憶媒体の受取りで実現しても良い。
1. Data2:=Φ(空集合)
2. 各 i ∈ [1,N]に対して、下記3,4,5,6,7を実施する。
3. rp,tsp,tss,IDi,rhi,r1i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDi が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rci := rc||result1,r2i ← {0,1}^k とし処理を7へ移行する。もし満たしている場合は、以下の操作を実行する。
4. r1i = PRF(ski,tss||IDi||rhi) が満たされるかを検証する。もし満たしていた場合はresult1 := 01 とし、そうでなければ result1 := 10 とする。
5. 乱数をrc ← {0,1}^(k-2) として選び、rci := rc||result1 ∈ {0,1}^k とする。
6. r2i := PRF(ski,tss||tsp||IDi||rhi||rci) を求める。
7. Data2 := (tss,IDi,rhi,rci,r2)∪Data2とし、iをインクリメントする
8. Data2 := (tss)∪Data2として認証代行クライアントに (rp,tsp,Data2) を送付する（Ｓ４９）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００６８】
尚サーバから認証代行クライアントへの送付に時間制約がある場合であってtspが信頼できる場合は、上記1の検証にて、tssとtspを比較する事で、その確認を実施しても良い。また、認証対象機器での認証処理への時間制約があり、認証代行クライアントの時計が信頼できる場合は、サーバは、tspと認証対象機器からの認証結果の受取り時刻(以下、tsp2と記載)を比較する事で、その確認を実施しても良い。
【００６９】
(3) サーバでの認証結果の検証
認証代行クライアントは(2,rp,tsp,Data2) をサーバに送付する（Ｓ５０）。サーバは(2,rp,tsp,Data2 = {(tss,IDi,rhi,rci,r2i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ５１）を実施する。
1. result:=Φ
2. 各 i ∈ [1,N]に対して、下記3,4,5を実施する。
3. rp,tss,tsp,IDi,rhi,rci,r2i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とし処理を5へ移行する。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、以下を実施する。
4. r2i = PRF(sk,tss||tsp||IDi||rhi||rci) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。ここで、result2が01なら認証対象機器で認証成功、result2が10なら認証失敗、result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
5. result := result∪result2 とし、iをインクリメントする
6. result を認証結果として出力し、これを記録する。
【００７０】
尚、サーバから認証代行クライアントへ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、上記3でのサイズチェック時に、tssとサーバでの現在時刻を比較する事で、サーバは、その確認を実施しても良い。
【００７１】
また、認証代行クライアントからの認証結果のサーバへの送付に時間制約があり、認証代行クライアントの時計が信頼できる場合は、tsp2を追加で認証代行クライアントからサーバへ送付し、サーバはtsp2とtssを比較する事で、その確認を実施しても良い。
【００７２】
図1同様、図１２に示すプロトコルでもrpが改竄されると、認証対象機器での認証が失敗するためフェールセーフである。 rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄してもサーバで検証合格とする事はできない。攻撃者がtspを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【００７３】
即ち、rp、rc、tspの何れを改竄しても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。rp,rh,rcの全てまたは何れかが改竄された場合、何らかの改竄があった事を検知可能である。改竄による認証失敗や検証不合格を効率よく検出する目的で、tspに対してハッシュ値を付加しても良い。
【００７４】
上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスと同様に定義される。
【００７５】
（オフライン・バッチ認証プロトコルが満たすべき安全性と対策）
構成の仕方から明らかであるように、実施の形態２における認証プロトコルは、ケース1〜ケース5の攻撃への耐性がある。
【００７６】
（ワンタイム・オフライン・バッチ認証プロトコル）
図１２の場合、認証代行クライアントに格納された認証情報は、対応する認証対象機器の認証に何度でも利用可能だという問題がある。認証回数を制限する方法も考えられるが、その部分が改ざんされると認証情報の悪用が可能となる。
【００７７】
そこで、モノトニック・カウンタを導入する事でワンタイム認証、即ち各認証情報での認証対象機器での認証を高々1回に制限する拡張を図１３に示す。以下の図１３の説明においては、主に、図１２からの変更点について以下に記載する。尚、サーバと認証対象機器に対するモノトニック・カウンタ（サーバ：cnt[j]、認証対象機器：pre_cnt[j](∀j∈[1,N])）がそれぞれ事前に０に初期設定されているものとする。また、モノトニック・カウンタ値は、自動更新されユーザが変更できないものとする。カウントアップによるオーバーフローにより０になる以外の方法では、最初の初期化を除いてリセットや電源遮断などでは０に変更できないとする。
【００７８】
ここで、図１３では、明示的にモノトニック・カウンタを導入しているが、サーバ時刻tssでそれを代替しても良い。また、認証代行クライアントは以下に示すように事前に認証対象機器のIDを収集しているものとする。
【００７９】
セキュリティパラメータをk としサーバは1^k を入力とする。サーバは認証識別子IDi ∈ {0,1}^k が割り振られている認証対象機器に対して対象鍵 ski ← {0,1}^k を選び、(ski,IDi) を送付する。認証対象機器は(ski,IDi)を不揮発性メモリに保存する。また、認証識別子IDiの集合ID を認証代行クライアントに送付する。
【００８０】
ここで、認証対象機器の総数をNとし、i ∈ [1,N]とする。例えば、認証対象機器を出荷する前にこれら処理を実施する事で、各認証対象機器に個別の鍵を設定するとともに、サーバに同鍵を格納しても良い。
【００８１】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは認証対象機器から｛IDi; i∈[1,N]}を受信すると（Ｓ６１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ６２）、認証対象機器群のIDの集合｛IDi; i∈[1,N]}とともに、(1,rp, ｛IDi; i∈[1,N]})をサーバに送付する（Ｓ６３）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００８２】
サーバは(1,rp, ｛IDi; i∈[1,N]}) を受け取ると、下記手順（Ｓ６４）を実施する。
1. 現在の時刻をtss ← TimeStamp として選ぶ。cnt:=1、Data1:=Φ(空集合)とする。
2. 各 i ∈ [1,N]に対して、下記3,4,5,6を実施する。
3. rp,IDi ∈ {0,1}^k であるか、そしてIDi ∈ ID であるかを検証する。もし異なっていれば cntをインクリメントし処理を6に移行する。もし満たしていれば、以下を実行する。
4. 乱数をrh ← {0,1}^k-m、rh:=rh||cnt[i] として選ぶ。ここで cnt[i]は、IDiに対応する初期値０のモノトニック・カウンタ値である。
5. r1i := PRF(ski,tss||IDi||rhi) を計算する。
6. Data1 := (IDi,rhi,r1i)∪Data1 とし、iをインクリメントする。その後、cnt[i]をインクリメントする。ここで、演算子’||’はビット連接を表す。
7. cnt==Nなら処理を終了し、そうでないならば、Data1 := (tss)∪Data1として認証代行クライアントに(1,rp,Data1) を送付する（Ｓ６５）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００８３】
(2) 認証対象機器での認証と結果収集
認証代行クライアントは現在の時刻をtsp ← TimeStamp として選び（Ｓ６６）、(rp,tsp,Data1) を認証対象機器に送付する（Ｓ６７）。
【００８４】
認証対象機器は(rp,tsp,Data1 = {(tss,IDi,rhi,r1i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ６８）を実施する。本受取りは、ネットワーク経由ではなく情報を書き込んだ記憶媒体の受取りで実現しても良い。
1. Data2:=Φ(空集合)
2. 各 i ∈ [1,N]に対して、下記3,4,5,6,7を実施する。
3. rp,tsp,tss,IDi,rhi,r1i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDi が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rci := rc||result1,r2i ← {0,1}^k とし処理を7へ移行する。もし満たしている場合は、以下の操作を実行する。
4. r1i = PRF(ski,tss||IDi||rhi) が満たされるかを検証する。もし満たしていた場合は以下の処理を実施し、そうでなければresult1 := 10 として処理を4へ移行する。
5. cnt[i]>pre_cnt[i]またはcnt[i]==0∧pre_cnt[i]+1==0であるか確認し、もし満たしている場合は、 result1 := 01とし、pre_cnt[i]:=cnt[i]とする。満たしていない場合は、result1:=11とする。ここで、pre_cnt[i]はIDiに対応する認証対象機器が持つ初期値０のモノトニック・カウンタである。
6. 乱数をrc ← {0,1}^(k-2) として選び、rci := rc||result1 ∈ {0,1}^k とする。
7. r2i := PRF(ski,tss||tsp||IDi||rhi||rci) を求める。
8. Data2 := (tss,IDi,rhi,rci,r2)∪Data2とし、iをインクリメントする
9. Data2 := (tss)∪Data2として認証代行クライアントに (rp,tsp,Data2) を送付する（Ｓ６９）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【００８５】
尚サーバから認証代行クライアントへの送付に時間制約がある場合であってtspが信頼できる場合は、認証対象機器は、上記1の検証にて、tssとtspを比較する事で、その確認を実施しても良い。また、認証対象機器での認証処理への時間制約があり、認証代行クライアントの時計が信頼できる場合は、サーバは、tspと認証対象機器からの認証結果の受取り時刻(以下、tsp2と記載)を比較する事で、その確認を実施しても良い。
【００８６】
(3) サーバでの認証結果の検証:
認証代行クライアントは(2,rp,tsp,Data2) をサーバに送付する（Ｓ７０）。サーバは(2,rp,tsp,Data2 = {(tss,IDi,rhi,rci,r2i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ７１）を実施する。
1. result:=Φ
2. i ∈ [1,N]に対して、下記3,4,5を実施する。
3. rp,tss,tsp,IDi,rhi,rci,r2i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とし処理を5へ移行する。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、以下を実施する。
4. r2i = PRF(sk,tss||tsp||IDi||rhi||rci) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。ここで、result2が01なら認証対象機器で認証成功、result2が11なら認証情報の再利用による認証失敗、result2が10なら擬似ランダム関数値不一致による認証失敗、 result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
5. result := result∪result2 とし、iをインクリメントする
6. result を認証結果として出力し、これを記録する。
【００８７】
尚、サーバから認証代行クライアントへ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、サーバは、上記3でのサイズチェック時に、tssとサーバでの現在時刻を比較する事で、その確認を実施しても良い。
【００８８】
また、認証代行クライアントからの認証結果のサーバへの送付に時間制約があり、認証代行クライアントの時計が信頼できる場合は、tsp2を追加で認証代行クライアントからサーバへ送付し、サーバがtsp2とtssを比較する事で、その確認を実施しても良い。
【００８９】
図1同様、図１３に示すプロトコルでもrpが改竄されると、認証対象機器での認証が失敗するためフェールセーフである。 rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄してもサーバで検証合格とする事はできない。tspを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【００９０】
即ち、rp、rc、tspの何れを改竄しても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。rp,rh,rcの全てまたは何れかが改竄された場合、何らかの改竄があった事を検知可能である。改竄による認証失敗や検証不合格を効率よく検出する目的で、tspに対してハッシュ値を付加しても良い。
【００９１】
上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスと同様に定義される。
【００９２】
（ワンタイム・オフライン・バッチ認証プロトコルが満たすべき安全性と対策）
実施の形態２にかかるオフライン認証プロトコルが、ケース1〜ケース5への攻撃耐性がある事は、プロトコルの構成の仕方から明らかである。また、実施の形態２にかかるオフライン認証プロトコルは、構成の仕方から明らかであるように、ケース6の攻撃への耐性もある。
【００９３】
以上説明したように、実施の形態２において説明したオフライン認証プロトコルを実行することによって下記の効果を得ることができる。
【００９４】
1)事前にサーバと認証対象機器が共通鍵を保有しているという前提の下で、サーバ・認証代行者（認証代行クライアント）間、認証代行者・認証対象機器間の少なくとも一方が、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で、認証対象機器の認証をセキュアに実現することが可能となる。
2)サーバでの認証結果検証にて暗号復号処理が不要となる。
3)通信路を対象とした署名発行検証を伴わなくても、サーバでの認証結果検証にて、認証対象機器の認証合否のみならず、認証対象機器からサーバへの認証結果送付にて改竄検知が可能となる。
4)認証情報の使いまわしによる攻撃抑止が可能となる。
【００９５】
（実施の形態３）
実施の形態１及び２のプロトコルでは、認証対象機器に時計が搭載されていない状況を想定し、認証対象機器の時計を用いる代わりに認証代行クライアントの時計を用いたプロトコルとなっていた。
【００９６】
認証代行クライアントの時計の値はハッシュ値を付加するなどで保護可能であるが、ハッシュ関数を用いない場合改竄可能となり、改竄による検証不合格や、時間制約検証での不合格を攻撃者が実現する事が可能である。以下、認証対象機器に時計が搭載されている場合の、図１、図１２に対応するプロトコルをそれぞれ図１４、図１５に示す。
【００９７】
（端末時計付きオフライン認証プロトコル）
図１４のシーケンス図を用いて、認証対象機器が時計を持つ場合のオフライン認証プロトコルの動作を以下に示す。尚、認証対象機器に対する共通対称鍵の初期設定として、下記設定が事前になされているものとする。
【００９８】
セキュリティパラメータをk としサーバは1^k を入力とする。サーバは認証識別子IDi ∈ {0,1}^k が割り振られている認証対象機器に対して対象鍵 ski ← {0,1}^k を選び、(ski,IDi) を送付する。認証対象機器は(ski,IDi)を不揮発性メモリに保存する。また、認証識別子IDの集合ID を認証代行クライアントに送付する。
【００９９】
ここで、認証対象機器の総数をNとし、i ∈ [1,N]とする。例えば、認証対象機器を出荷する前にこれら処理を実施する事で、各認証対象機器に個別の鍵を設定するとともに、サーバに同鍵を格納しても良い。また、認証代行クライアントは事前に認証対象機器のIDを収集しているものとする。
【０１００】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは認証対象機器からIDを受信すると（Ｓ８１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ８２）、(1,rp,ID) をサーバに送付する（Ｓ８３）。サーバは(1,rp,ID) を受け取ると、下記手順（Ｓ８４）を実施する。
1. rp,ID ∈ {0,1}^k であるか、そしてID ∈ ID であるかを検証する。もし異なっていれば処理を終了する。もし満たしていれば、以下を実行する。
2. 現在の時刻をtss ← TimeStamp として選ぶ。
3. 乱数をrh ← {0,1}^k として選ぶ。
4. r1 := PRF(sk,tss||ID||rh) を計算する。そして、サーバはData1 := (tss,ID,rh,r1) として認証代行クライアントに(1,rp,Data1) を送付する（Ｓ８５）。ここで、演算子’||’はビット連接を表す。
【０１０１】
(2) 認証対象機器での認証と結果収集
認証代行クライアントは、(rp,Data1) を認証対象機器に送付する（Ｓ８６）。認証対象機器は(rp,Data1 = (tss,ID,rh,r1)) を受け取ると、以下手順（Ｓ８７）を実施する。
1. 現在の時刻情報 tsd ← TimeStamp を選ぶ
2. rp,tss,ID,rh,r1 ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、ID が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rc := rc||result1,r2 ← {0,1}^k とする。もし満たしている場合は、以下の操作を実行する。
3. r1 = PRF(sk,tss||ID||rh) が満たされるかを検証する。もし満たしていた場合はresult1 := 01 とし、そうでなければresult1 := 10 とする。
4. 乱数をrc ← {0,1}^(k-2) として選び、rc := rc||result1 ∈ {0,1}^k とする。
5. r2 := PRF(ski,tss||tsd||ID||rh||rc) を求める。そして、認証対象機器 はData2 := (tss,tsd,ID,rh,rc,r2) として(rp, Data2) を認証代行クライアントに送付する（Ｓ８８）。
【０１０２】
尚サーバから認証対象機器への認証情報の送付に時間制約がある場合であってtsdが信頼できる場合は、認証対象機器は、上記2のサイズチェック時に、tssとtsdを比較する事で、その確認を実施しても良い。
【０１０３】
(3) サーバでの認証結果の検証:
認証代行クライアントは(2,rp,Data2) をサーバに送付する（Ｓ８９）。サーバは(2,rp,Data2 = (tss,tsd,ID,rh,rc,r2)) を受け取ると、rp,tss,tsd,ID,rh,rc,r2 ∈ {0,1}^k あるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とする。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、r2 = PRF(sk,tss||tsd||ID||rh||rc) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。そしてresult2 を認証結果として出力し、これを記録する（Ｓ９０）。ここで、result2が01なら認証対象機器で認証成功、result2が10なら認証失敗、 result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
【０１０４】
尚、サーバから認証代行クライアントを介して認証対象機器へ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、上記サイズチェック時に、サーバは、tssとサーバでの現在時刻を比較する事で、その確認を実施しても良い。
【０１０５】
また、認証対象機器からの認証結果のサーバへの送付に時間制約があり、認証対象機器の時計が信頼できる場合は、サーバは、tsdとtssを比較する事で、その確認を実施しても良い。
【０１０６】
本プロトコルではrpが改竄されると、対応するセッションが非存在となるか、存在しても異なるセッションでの認証対象機器での認証が実施される事となり失敗するためフェールセーフである。 rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄してもサーバで検証合格とする事はできない。tsdを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【０１０７】
即ち、rp、rc、tsdの何れを改竄しても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。また、rp,rh,rc,tsdの全てまたは何れかが改竄された場合、何らかの改竄があった事を検知可能である。従って、tsdにハッシュ値を付加する必要はとくにない。認証情報のワンタイム化を、実施の形態１に示したモノトニック・カウンタ導入手法で実現しても良い。
・上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスと同様に定義される。
【０１０８】
（端末時計付きオフライン認証プロトコルが満たすべき安全性と対策）
図１４のオフライン認証プロトコルの構成の仕方から明らかであるように、図１４のオフライン認証プロトコルは、ケース1〜ケース5の攻撃への耐性がある。
【０１０９】
（端末時計付きオフライン・バッチ認証プロトコル）
・図１５のシーケンス図を用いて、認証対象機器が時計を持つ場合のバッチ処理化したオフライン認証プロトコルの動作を以下に示す。尚、全認証対象機器に対する共通対称鍵の初期設定が、実施の形態１と同様下記が事前になされているものとする。
【０１１０】
セキュリティパラメータをk としサーバは1^k を入力とする。サーバは認証識別子IDi ∈ {0,1}^k が割り振られている認証対象機器に対して対象鍵 ski ← {0,1}^k を選び、(ski,IDi) を送付する。認証対象機器は(ski,IDi)を不揮発性メモリに保存する。また、認証識別子IDiの集合ID を認証代行クライアントに送付する。
【０１１１】
ここで、認証対象機器の総数をNとし、i ∈ [1,N]とする。例えば、認証対象機器を出荷する前にこれら処理を実施する事で、各認証対象機器に個別の鍵を設定するとともに、サーバに同鍵を格納しても良い。また、認証代行クライアントは事前に認証対象機器のIDを収集しているものとする。
【０１１２】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは認証対象機器から｛IDi; i∈[1,N]}を受信すると（Ｓ９１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ９２）、認証対象機器群のIDの集合｛IDi; i∈[1,N]}とともに、(1,rp, ｛IDi; i∈[1,N]}) をサーバに送付する（Ｓ９３）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【０１１３】
サーバは(1,rp, ｛IDi; i∈[1,N]}) を受け取ると、下記手順（Ｓ９４）を実施する。
1. 現在の時刻をtss ← TimeStamp として選ぶ。cnt:=1、Data1:=Φ(空集合)とする。
2. 各 i ∈ [1,N]に対して、下記3,4,5,6を実施する。
3. rp,IDi ∈ {0,1}^k であるか、そしてIDi ∈ ID であるかを検証する。もし異なっていれば cntをインクリメントし処理を6に移行する。もし満たしていれば、以下を実行する。
4. 乱数をrhi ← {0,1}^k として選ぶ。
5. r1i := PRF(ski,tss||IDi||rhi) を計算する。
6. Data1 := (IDi,rhi,r1i)∪Data1 とし、iをインクリメントする。ここで、演算子’||’はビット連接を表す。
7. cnt==Nなら処理を終了し、そうでないならば、Data1 := (tss)∪Data1として認証代行クライアントに(1,rp,Data1) を送付する（Ｓ９５）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。
【０１１４】
(2) 認証対象機器での認証と結果収集
認証代行クライアントは、(rp,tsp,Data1) を認証対象機器に送付する（Ｓ９６）。認証対象機器は(rp,tsp,Data1 = {(tss,IDi,rhi,r1i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ９７）を実施する。本受取りは、ネットワーク経由ではなく情報を書き込んだ記憶媒体の受取りで実現しても良い。
1. 現在の時刻情報 tsd ← TimeStamp を選ぶ
2. Data2:=Φ(空集合)
3. 各 i ∈ [1,N]に対して、下記4,5,6,7,8を実施する。
4. rp,tsp,tss,IDi,rhi,r1i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDi が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1 := 00,rc ← {0,1}^(k-2),rci := rc||result1,r2i ← {0,1}^k とし処理を7へ移行する。もし満たしている場合は、以下の操作を実行する。
5. r1i = PRF(ski,tss||IDi||rhi) が満たされるかを検証する。もし満たしていた場合はresult1 := 01 とし、そうでなければresult1 := 10 とする。
6. 乱数をrc ← {0,1}^(k-2) として選び、rci := rc||result1 ∈ {0,1}^k とする。
7. r2i := PRF(ski,tss||tsd||IDi||rhi||rci) を求める。
8. Data2 := (tss,IDi,rhi,rci,r2)∪Data2とし、iをインクリメントする
9. Data2 := (tss,tsd)∪Data2として認証代行クライアントに (rp,Data2) を送付する（Ｓ９８）。本送付は、ネットワーク経由ではなく情報を書き込んだ記憶媒体を配達する事で実現しても良い。尚サーバから認証対象機器への認証情報の送付に時間制約がある場合であってtsdが信頼できる場合は、上記4のサイズチェック時に、認証対象機器は、tssとtsdを比較する事で、その確認を実施しても良い。
【０１１５】
(3) サーバでの認証結果の検証:
認証代行クライアントは(2,rp,Data2) をサーバ に送付する（Ｓ９９）。サーバは(2,rp,Data2 = {(tss,tsd,IDi,rhi,rci,r2i); i ∈ [1,N]}) を受け取ると、以下手順（Ｓ１００）を実施する。
1. result:=Φ
2. 各 i ∈ [1,N]に対して、下記3,4,5を実施する。
3. rp,tss,tsd,IDi,rhi,rci,r2i ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、満たしていなければresult2 := 00 とし処理を5へ移行する。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていれば、以下を実施する。
4. r2i = PRF(sk,tss||tsd||IDi||rhi||rci) であるかを検証する。もし正しければresult2 := rcの下位2bit とし、そうでなければresult2 := 00 とする。ここで、result2が01なら認証対象機器で認証成功、result2が10なら認証失敗、result2が00なら受信エラー(メッセージ改竄の可能性)、として記録される。
5. result := result∪result2 とし、iをインクリメントする
6. result を認証結果として出力し、これを記録する。
【０１１６】
尚、サーバから認証代行クライアントを介して認証対象機器へ認証情報を送付後、サーバが認証代行クライアントからの認証結果を取得するまでの間に時間制約がある場合、上記サイズチェック時に、サーバは、tssとサーバでの現在時刻を比較する事で、その確認を実施しても良い。
【０１１７】
また、認証対象機器からの認証結果のサーバへの送付に時間制約があり、認証対象機器の時計が信頼できる場合は、サーバは、tsdとtssを比較する事で、その確認を実施しても良い。
【０１１８】
本プロトコルではrpが改竄されると、対応するセッションが非存在となるか、存在しても異なるセッションでの認証対象機器での認証が実施される事となり失敗するためフェールセーフである。 rh改竄の場合もサーバでの認証結果の検証が失敗するためフェールセーフである。
【０１１９】
また、サーバでの認証結果の検証手段により、攻撃者がrcの値を改竄してもサーバで検証合格とする事はできない。tsdを改竄した場合も、サーバでの認証結果の検証手段により、サーバで検証合格とする事はできない。
【０１２０】
即ち、rp、rc、tsdの何れを改竄しても、認証対象機器の認証結果を攻撃者が認証成功や検証合格とする事ができない。また、rp,rh,rc,tsdの全てまたは何れかが改竄された場合、何らかの改竄があった事を検知可能である。従って、tsdにハッシュ値を付加する必要はとくにない。
【０１２１】
認証情報のワンタイム化を、実施形態２に示したモノトニック・カウンタ導入手法で実現しても良い。上記(1)(2)(3)の繰返し実行は、図２に示すシーケンスと同様に定義される。
【０１２２】
（端末時計付きオフライン・バッチ認証プロトコルが満たすべき安全性と対策）
実施の形態３のオフライン認証プロトコルの構成の仕方から明らかであるように、実施の形態３のオフライン認証プロトコルは、ケース1〜ケース5の攻撃への耐性がある。
【０１２３】
（端末時計付きワンタイム・オフライン認証プロトコル）
実施の形態１に示した構成方法と同様に、プロトコルを定義することが可能である。
【０１２４】
（端末時計付きワンタイム・オフライン認証プロトコルが満たすべき安全性と対策）
ケース1〜ケース5への攻撃耐性がある事は、プロトコルの構成の仕方から明らかである。構成の仕方から明らかであるように、ケース6の攻撃への耐性がある。
【０１２５】
（端末時計付きワンタイム・オフライン・バッチ認証プロトコル）
実施の形態1に示した構成方法と同様に、プロトコルを定義することが可能である。
【０１２６】
（端末時計付きワンタイム・オフライン・バッチ認証プロトコルが満たすべき安全性と対策）
ケース1〜ケース5への攻撃耐性がある事は、プロトコルの構成の仕方から明らかである。構成の仕方から明らかであるように、ケース6の攻撃への耐性がある。
【０１２７】
（実施の形態４）
メモリ空間をAとBに分割し、BからはAにアクセス可能だが、AからのBへのアクセスをB上に構築したAPI（Application Programming Interface）を介してのみ実施可能とする事で、B上のプログラムやリソースを保護する方法が考えられる。実際の製品開発では、デバッグなどの目的でB内リソースの消去APIやセキュリティ・リスクとなり得るプログラムの実行などを可能とするAPIを付加した状態で開発が実施される。
【０１２８】
製品出荷時にデバッグ目的で追加したAPIを削除すれば、B上のプログラムやリソース保護が実現されるが、出荷後の不具合対策などの理由からデバッグ目的で追加したAPIを削除せずに出荷してしまう事がしばしば行われる。
【０１２９】
この問題への対策としては、Bにセキュアに認証サーバとの事前共有鍵を配置し、B上のAPIをAから実行する際に、実行権限が与えられているか否か認証するという方法が考えられる。然るに、これではAPI実行の度にサーバとの通信が必要となり、通信による実行時間の長大化や消費電力増大、更には通信環境がない場合にAPI実行ができなくなり利便性が大きく既存するという問題がある。
【０１３０】
API実行にて、実施の形態１乃至３に示した認証方式を用いれば、そうした問題は解消され、通信環境がなくても端末での認証処理に必要となるオーバーヘッドのみで目的とするリソース保護やプログラム保護を達成可能なAPI実行が実現できる。以下に、図１６〜図１９のシーケンス図を用いて、実施の形態１乃至４に示した認証方式を、鍵配送を伴う認証へ拡張した動作について説明する。
【０１３１】
(1) 機器認証情報のサーバでの構築
認証代行クライアントは、認証対象機器からIDdを受信すると（Ｓ１０１）、セッション管理のためにrp ∈ {0,1}^k を選び（Ｓ１０２）、(1,rp,IDd,IDp) をサーバに送付する（Ｓ１０３）。IDdは、認証対象機器に割り当てられたIDである。IDpは、認証代行クライアントに割り当てられたIDである。サーバは(1,rp,IDd,IDp) を受け取ると、下記手順（Ｓ１０４）を実施する。
【０１３２】
1. rp,IDd,IDp ∈ {0,1}^k であるか、そしてID ∈ ID であるかを検証する。もし異なっていれば処理を終了する。もし満たしていれば、以下を実行する。
2. 現在の時刻をtss ← TimeStamp として選ぶ。
3. 乱数をrh ← {0,1}^k 及びk1 ← {0,1}^kとして選ぶ。
4. r1d := PRF(ski,tss||IDd||rh||1), r1’d := PRF(ski,tss||IDd||rh||2), r1p := PRF(ski,tss||IDp||rh||1), r1’p := PRF(ski,tss||IDp||rh||2), c1d := AE.Enc(r1’d, k1), c1p := AE.Enc(r1’p, k1)を計算する。そして、サーバはData1 := (tss,IDd,rh,r1d,c1d,IDp,r1p,c1p) として認証代行クライアントに(1,rp,Data1)を送付する（Ｓ１０５）。ここで、PRFは疑似ランダム関数(Pseudo Random Function)、AE.Encは認証付き暗号(Authenticated Encryption)方式での暗号化、演算子’||’はビット連接を表す。
【０１３３】
(2) 認証代行クライアントでの認証と結果収集
認証代行クライアントは、(rp,Data1 = rp,tss,IDd,rh,r1d,c1d,IDp,r1p,c1p) を受け取ると、下記手順（Ｓ１０６）を実施する。
1. 認証代行クライアントは現在の時刻をtsp ← TimeStamp として選び、乱数をr3p ← {0,1}^k として選ぶ。
2. rp,tss,IDd,rh,r1d,c1d,IDp,r1p,c1p ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDd及びIDp が自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1p := 00,rcp := rcp||result1p,r2p ← {0,1}^k とする。もし満たしている場合は、以下の操作を実行する。
3. r1p = PRF(skp,tss||IDp||rh||1) が満たされるかを検証する。もし満たしていれば、result1p := 01,r1’p := PRF(skp,tss||IDp||rh||2), k1 := AE.Dec(r1’p,c1p)とする。もし満たしていなければ、result1p := 11とする。ここで、AE.Decは認証付き暗号(Authenticated Encryption)方式での復号化を表す。
4. rcp := rc||result1p, とし、r2p := PRF(skp,tss||IDp||rh||rcp||1)を求める。
5. result1p := 01である場合、r3p := PRF(k1,tss||IDp||rh||1)を求める。そして、認証代行クライアントはData2 := (tss,IDd,rh,r1d,c1d,IDp,r1p,c1p,rcp,r2p,r3p) として(rp,tsp,Data2) を認証対象機器に送付する（Ｓ１０７）。
【０１３４】
(3) 認証対象機器での認証と結果収集
認証対象機器は、(rp,tsp,Data2 = rp, tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p) を受け取ると、下記手順（Ｓ１０８）を実施する。
1. 乱数をr3d ← {0,1}^k, rcd ← {0,1}^k, rcdp ← {0,1}^kとして選ぶ。
2. rp, tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDdが自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。もし満たしていなければ、result1d := 00,rcd := rcd||result1d,r2d ← {0,1}^k, result1dp := 00,rcdp := rcdp||result1dp,r3d ← {0,1}^kとする。もし満たしている場合は、以下の操作を実行する。
3. r1d = PRF(skd,tss||IDd||rh||1) が満たされるかを検証する。もし満たしていれば、result1d := 01,r1’d := PRF(skd,tss||IDd||rh||2), k1 := AE.Dec(r1’d,c1d)とする。もし満たしていなければ、result1d := 11とする。
4. rcd := rcd||result1d, とし、r2d := PRF(skd,tss||IDd||rh||rcd||1)を求める。
5. result1d := 01であり、r3d := PRF(k1,tss||IDd||rh||1)を満たす場合、result1dp := 01とし、満たさない場合、result1dp := 11とする。
6. rcdp := rcdp||result1dp, とし、r3d := PRF(k1,tss||tsp||IDd||rh||rcdp||1)を求める。そして、認証対象機器はData3 := (tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d) として(rp,tsp,Data3) を認証代行クライアントに送付する（Ｓ１０９）。
【０１３５】
(4) 認証代行クライアントでの認証結果の検証
認証代行クライアントは(rp,tsp,Data3 = (tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d)) を受け取ると、下記手順（Ｓ１１０）を実施する。
1. tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDdが自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。満たしていなければresult1pd := 000 とする。もし満たしていれば、r1d = PRF(skd,tss||tsp||IDd||rh||1) であるかを検証する。もし正しければresult1p := 001, r1’p := PRF(skp,tss||IDp||rh||2), k1 := AE,Dec (r1’p, c1p)とし、そうでなければresult1pd := 110 とする。
2. result1pd := 001である場合、r3d = PRF(k1,tss||tsp||IDd||rh||rcdp||1)であるかを検証する。もし正しければ、result1pd := 001とし、そうでなければ、result := 100とする。
3. result1pd := 001ならばresult2pd := rcdpの下位2bitとし、そうでなければ、result2pd := 00とする。そして、result2 を認証結果として出力し、これを記録する。認証代行クライアントは、Data3 := (tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d) として(rp,tsp,Data3) をサーバに送付する（Ｓ１１１）。
【０１３６】
(5) サーバでの認証結果の検証
認証代行クライアントは(rp,tsp,Data3 = (tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d)) を受け取ると、下記手順（Ｓ１１２）を実施する。
1. 乱数をr3d ← {0,1}^k, rcd ← {0,1}^k, rcdp ← {0,1}^kとして選ぶ。
2. tss, IDd, rh, r1d, c1d, IDp, r1p, c1p, rcp, r2p, r3p, rcd, r2d, rcdp, r3d ∈ {0,1}^k であるか、即ちそれぞれのデータの長さが規定値どおりの長さとなっているかを検証し、IDdが自身のものと一致するかを確かめる。ここで、データは必要に応じ適切にパディングされているものとする。満たしていなければresult2p := 00 とし、result2d := 00とする。もし満たしていれば、r2p = PRF(skp,tss||tsp||IDp||rh||rcp||1)、r2d = PRF(skd,tss||tsp||IDd||rh||rcd||1) であるかを検証する。もし正しければresult2p := rcpの下位2ビットとし、result2d := rcdの下位2ビットとする。
【０１３７】
以上説明したように、実施の形態３にかかるプロトコルを用いることにより、通信環境がなくても端末での認証処理に必要となるオーバーヘッドのみで目的とするリソース保護やプログラム保護を達成可能なAPI実行が実現できる。
【０１３８】
続いて、以下では、図２０を用いて、上述の実施の形態１乃至４において説明した、認証対象機器、認証代行クライアント、及びサーバの構成例について説明する。図２０は、認証対象機器、認証代行クライアント、及びサーバにおいて用いられるコンピュータ装置１０を示している。コンピュータ装置１０は、ネットワークインタフェース１２０１、プロセッサ１２０２、及びメモリ１２０３を含む。ネットワークインタフェース１２０１は、通信システムを構成する他のネットワークノード装置と通信するために使用される。ネットワークインタフェース１２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
【０１３９】
プロセッサ１２０２は、メモリ１２０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明された認証対象機器、認証代行クライアント、及びサーバの処理を行う。プロセッサ１２０２は、例えば、マイクロプロセッサ、MPU（Micro Processing Unit）、又はCPU（Central Processing Unit）であってもよい。プロセッサ１２０２は、複数のプロセッサを含んでもよい。
【０１４０】
メモリ１２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１２０３は、プロセッサ１２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０２は、図示されていないI/Oインタフェースを介してメモリ１２０３にアクセスしてもよい。
【０１４１】
図２０の例では、メモリ１２０３は、ソフトウェアモジュール群を格納するために使用される。プロセッサ１２０２は、これらのソフトウェアモジュール群をメモリ１２０３から読み出して実行することで、上述の実施形態において説明された認証対象機器、認証代行クライアント、及びサーバの処理を行うことができる。
【０１４２】
図２０を用いて説明したように、認証対象機器、認証代行クライアント、及びサーバが有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。
【０１４３】
また、様々な処理を行う機能ブロックとして図面に記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他の回路で構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。
【０１４４】
また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１４５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は既に述べた実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変更が可能であることはいうまでもない。
【符号の説明】
【０１４６】
１０  コンピュータ装置
１２０１  ネットワークインタフェース
１２０２  プロセッサ
１２０３  メモリ
【図１】
2018196085.tif 000003
【図２】
2018196085.tif 000004
【図３】
2018196085.tif 000005
【図４】
2018196085.tif 000006
【図５】
2018196085.tif 000007
【図６】
2018196085.tif 000008
【図７】
2018196085.tif 000009
【図８】
2018196085.tif 000010
【図９】
2018196085.tif 000011
【図１０】
2018196085.tif 000012
【図１１】
2018196085.tif 000013
【図１２】
2018196085.tif 000014
【図１３】
2018196085.tif 000015
【図１４】
2018196085.tif 000016
【図１５】
2018196085.tif 000017
【図１６】
2018196085.tif 000018
【図１７】
2018196085.tif 000019
【図１８】
2018196085.tif 000020
【図１９】
2018196085.tif 000021
【図２０】
2018196085.tif 000022