特許 6334275 認証装置、認証方法、認証プログラム、及び認証システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6334275

(24)【登録日】2018年5月11日

(45)【発行日】2018年5月30日

(54)【発明の名称】認証装置、認証方法、認証プログラム、及び認証システム

(51)【国際特許分類】

   G06F 21/33 20130101AFI20180521BHJP

   H04L 9/32 20060101ALI20180521BHJP

【ＦＩ】

   G06F21/33

   H04L9/00 675B

【請求項の数】14

【全頁数】26

(21)【出願番号】特願2014-115277(P2014-115277)

(22)【出願日】2014年6月3日

(65)【公開番号】特開2015-230520(P2015-230520A)

(43)【公開日】2015年12月21日

【審査請求日】2015年3月17日

【審判番号】不服2017-2587(P2017-2587/J1)

【審判請求日】2017年2月22日

(73)【特許権者】

【識別番号】500257300

【氏名又は名称】ヤフー株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】安藤 義裕

(72)【発明者】

【氏名】五味 秀仁

(72)【発明者】

【氏名】利波 泰史

【合議体】

【審判長】 辻本 泰隆

【審判官】 山崎 慎一

【審判官】 須田 勝巳

(56)【参考文献】

【文献】 特開２０１０−１９１８０１号公報

【文献】 特開２００４−１３３７４号公報

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F21/33

H04L9/32

(57)【特許請求の範囲】

【請求項1】

送信元のデバイスに対応する認証情報と、前記デバイスに格納された非公開情報により暗号化された情報であって前記認証情報により復号される要求情報とを、前記送信元とは異なる被認証側の他の送信元であって、前記送信元に関連するリソースを利用するために、前記送信元を利用するユーザから認証する権限を委譲された他の送信元から受け付ける受付部と、
前記受付部により受け付けられた認証情報により前記要求情報が復号化され、当該認証情報に対応する情報が記憶部に格納されている場合に認証処理を完了することにより、前記デバイスに対応するユーザを認証する認証部と、
を備えたことを特徴とする認証装置。

【請求項2】

前記受付部は、
前記認証情報と前記要求情報とをともに受け付け、
前記認証部は、
前記認証情報と、当該認証情報とともに受け付けた要求情報とに基づいて前記ユーザを認証する、
ことを特徴とする請求項１に記載の認証装置。

【請求項3】

前記受付部は、
有効期限に関する情報を含む前記要求情報を受け付け、
前記認証部は、
前記要求情報に含まれる前記有効期限に関する情報に基づいて有効期限の経過前であると判定した場合に前記デバイスに対応するユーザを認証する、
ことを特徴とする請求項１又は請求項２に記載の認証装置。

【請求項4】

前記ユーザに関するユーザ情報と、前記ユーザに関連する認証情報である関連認証情報とを関連付けて管理するユーザ管理装置に対して、前記認証情報の認証を要請する要請部、
をさらに備え
前記認証部は、前記ユーザ管理装置により前記認証情報の認証が成功した場合、前記認証情報と前記要求情報とに基づいて前記デバイスに対応するユーザを認証する、
ことを特徴とする請求項１〜３のいずれか一つに記載の認証装置。

【請求項5】

前記ユーザ情報に対応付けて記憶されているリソースのうち前記要求情報により要求されているリソースを特定する特定部、
をさらに備えたことを特徴とする請求項４に記載の認証装置。

【請求項6】

前記認証情報に対応付けて記憶されているリソースのうち前記要求情報により要求されているリソースを特定する特定部、
をさらに備えたことを特徴とする請求項１〜４のいずれか一つに記載の認証装置。

【請求項7】

前記受付部は、
前記ユーザの権限に関する情報を含む前記要求情報を受け付け、
前記特定部は、
前記要求情報に含まれる前記権限に関する情報に基づいて、前記要求情報により特定されるリソースへのアクセスが認められているかを判定する、
ことを特徴とする請求項５又は請求項６に記載の認証装置。

【請求項8】

前記要求情報に基づいて特定されたリソースに関する情報を前記送信元または前記他の送信元へ送信する送信部、
をさらに備えたことを特徴とする請求項５〜７のいずれか一つに記載の認証装置。

【請求項9】

コンピュータが実行する認証方法であって、
送信元のデバイスに対応する認証情報と、前記デバイスに格納された非公開情報により暗号化された情報であって前記認証情報により復号される要求情報とを、前記送信元とは異なる被認証側の他の送信元であって、前記送信元に関連するリソースを利用するために、前記送信元を利用するユーザから認証する権限を委譲された他の送信元から受け付ける受付工程と、
前記受付工程により受け付けられた認証情報により前記要求情報が復号化され、当該認証情報に対応する情報が記憶部に格納されている場合に認証処理を完了することにより、前記デバイスに対応するユーザを認証する認証工程と、
を備えたことを特徴とする認証方法。

【請求項10】

送信元のデバイスに対応する認証情報と、前記デバイスに格納された非公開情報により暗号化された情報であって前記認証情報により復号される要求情報とを、前記送信元とは異なる被認証側の他の送信元であって、前記送信元に関連するリソースを利用するために、前記送信元を利用するユーザから認証する権限を委譲された他の送信元から受け付ける受付手順と、
前記受付手順により受け付けられた認証情報により前記要求情報が復号化され、当該認証情報に対応する情報が記憶部に格納されている場合に認証処理を完了することにより、前記デバイスに対応するユーザを認証する認証手順と、
を備えたことを特徴とする認証プログラム。

【請求項11】

認証装置と、ユーザ管理装置とを含む認証システムであって、
前記認証装置は、
送信元のデバイスに対応する認証情報と、前記デバイスに格納された非公開情報により暗号化された情報であって前記認証情報により復号される要求情報とを、前記送信元とは異なる被認証側の他の送信元であって、前記送信元に関連するリソースを利用するために、前記送信元を利用するユーザから認証する権限を委譲された他の送信元から受け付ける受付部と、
前記ユーザ管理装置に対して前記認証情報の認証を要請する要請情報を送信する要請部と、
前記ユーザ管理装置により前記認証情報の認証が成功した場合、前記認証情報と前記要求情報とに基づいて前記デバイスに対応するユーザを認証する認証部とを備え、
前記ユーザ管理装置は、
前記ユーザに関するユーザ情報と、前記ユーザが所有する各デバイスに各々対応付けられた複数の認証情報である複数の関連認証情報とを関連付けて記憶部に格納し管理する管理部と、
前記認証装置から受け付けた前記要請情報により認証が要請された前記認証情報に対応する情報が前記記憶部に格納されている場合に前記認証情報の認証に成功したと判定する認証引受部と、
前記認証情報の認証の結果に関する情報を応答する応答部と、
を備えたことを特徴とする認証システム。

【請求項12】

前記管理部は、
前記ユーザ情報が削除された場合に、前記ユーザ情報に関連付けられた前記関連認証情報を失効させる、
ことを特徴とする請求項１１に記載の認証システム。

【請求項13】

前記管理部は、
前記要求情報の暗号化に用いた前記非公開情報が前記送信元から削除されるか又は漏洩した場合に、前記送信元に対応する前記関連認証情報を失効させる、
ことを特徴とする請求項１１又は請求項１２に記載の認証システム。

【請求項14】

前記ユーザ管理装置は、
ユーザに関するユーザ情報と新たな認証情報との関連付けに利用される関連付情報を、前記ユーザに関する宛先情報により指定される宛先へ送付する送付部と、
前記宛先に対応する送信元から受け付けた前記関連付情報と前記新たな認証情報と前記要求情報とに基づいて、前記ユーザ情報と前記新たな認証情報との関連付けを行うか判定する判定部をさらに備え、
前記管理部は、
前記判定部により関連付けを行うと判定された場合、前記新たな認証情報を新たな関連認証情報として前記ユーザ情報に関連付ける、
ことを特徴とする請求項１１〜１３のいずれか一つに記載の認証システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、認証装置、認証方法、認証プログラム、及び認証システムに関する。

【背景技術】

【0002】

従来、ＩＤとパスワードとを用いたログイン認証や、いわゆるＯＡｕｔｈ認証等のトークンを用いた認証等が用いられている。ＯＡｕｔｈ認証において、サービスプロバイダ等の認証装置は、発行したアクセストークンをユーザから許可された第３者であるコンシューマに対して返却し、認証装置はコンシューマからのアクセストークンに基づいて認証を行う。また、携帯電話等のユーザが利用するデバイスやユーザに関する情報を用いた認証が用いられている。例えば、携帯電話の固体識別情報を予め各会員のものとしてデータベース装置に登録し、認証用ホストコンピュータは、携帯電話からの認証用ホストコンピュータに対する認証要求メッセージに含まれる固体識別情報がデータベース登録されているものと一致することを確認することにより、特定の会員からの認証要求メッセージであることを、確認する認証方法が提供されている。

【0003】

また、ユーザ端末と多数のサービス提供先との間で公開鍵認証方式による認証が行えるユーザ認証システムも提供されている。このシステムにおいては、ユーザ管理システムがユーザ端末からの登録要求に応答して、第１ユーザ識別子、第１公開鍵および第１秘密鍵のペア、ならびに公開鍵証明書を生成してユーザ端末へ送信する。そして、ユーザ端末が、第２ユーザ識別子ならびに第２公開鍵および第２秘密鍵のペアを生成し、公開鍵証明書で署名された第２公開鍵の代理証明書を発行し、サービス提供サーバへ代理証明書を含むサービス要求を送信する。その後、サービス提供サーバが、代理証明書の検証をユーザ管理システムへ要求し、ユーザ管理システムが、受信した代理証明書に対応した公開鍵証明書を抽出して公開鍵証明書および代理証明書を検証し、その結果をサービス提供サーバへ送信する。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００８−１４６３６３号公報

【特許文献2】特開２００６−３１１４２５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、上記の従来技術では、認証を受けるユーザの負荷が大きく、かつ認証装置から情報が漏洩する可能性がある。具体的にいうと、ユーザは認証を受けるサービス毎にＩＤとパスワードとを管理し、ＩＤとパスワードとを用いたログイン認証を行う場合、ユーザはＩＤとパスワードとを入力するため、ユーザの負荷が大きい。また、アクセストークンや固体識別情報や第１秘密鍵等の認証に用いる情報は、他のユーザ等には秘匿状態で認証用ホストコンピュータやユーザ管理システム等の認証装置に格納されるため、これらの認証に用いる情報が認証装置から漏洩する可能性がある。

【0006】

本願は、上記に鑑みてなされたものであって、ユーザの負荷を軽減することができ、かつ情報が漏洩する可能性を低減することができる認証装置、認証方法、認証プログラム、及び認証システムを提供することを目的とする。

【課題を解決するための手段】

【0007】

本願に係る認証装置は、送信元のデバイスに対応する認証情報と、前記デバイスに格納された非公開情報により暗号化された情報であって前記認証情報により復号される要求情報とを受け付ける受付部と、前記認証情報と前記要求情報とに基づいて前記デバイスに対応するユーザを認証する認証部と、を備えたことを特徴とする。

【発明の効果】

【0008】

実施形態の一態様によれば、ユーザの負荷を軽減することができ、かつ情報が漏洩する可能性を低減することができるという効果を奏する。

【図面の簡単な説明】

【0009】

【図1】図１は、実施形態に係る認証システムの機能概要を示す図である。

【図2】図２は、実施形態に係る認証装置の構成例を示す図である。

【図3】図３は、実施形態に係るユーザ管理装置の構成例を示す図である。

【図4】図４は、実施形態に係る関連認証情報の一例を示す図である。

【図5】図５は、実施形態に係るユーザ情報の登録のフローチャートである。

【図6】図６は、実施形態に係る要求情報の一例を示す図である。

【図7】図７は、実施形態に係る認証システムによる認証処理を示すシーケンス図である。

【図8】図８は、実施形態に係るリカバリ処理のフローチャートである。

【図9】図９は、変形例に係る認証システムの機能概要を示す図である。

【図10】図１０は、変形例に係るリソースアクセスのフローチャートである。

【図11】図１１は、変形例に係る関連認証情報の一例を示す図である。

【図12】図１２は、変形例に係る認証システムの構成例を示す図である。

【図13】図１３は、認証装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

【発明を実施するための形態】

【0010】

以下に、本願に係る認証装置、認証方法、認証プログラム、及び認証システムを実現するための形態（以下、「実施形態」と呼ぶ）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る認証装置、認証方法、認証プログラム、及び認証システムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する記載は省略される。

【0011】

〔１．認証システム〕
まず、図１を用いて、実施形態に係る認証システムの一例について説明する。図１は、実施形態に係る認証システムの機能概要を示す図である。図１に示した認証装置１００は、認証情報と要求情報とに基づいたユーザの認証サービスを提供する。以下では、認証情報が公開鍵暗号方式で使用される公開鍵であり、要求情報として公開鍵暗号方式で使用される秘密鍵を使用して暗号化されたシグナチャを用いた例を示す。すなわち、以下の例では、送信元のデバイスに対応する認証情報は公開鍵に対応し、デバイスに格納された非公開情報は秘密鍵に対応する。

【0012】

〔１−１．認証システムの構成〕
まず、実施形態に係る認証システムの構成について説明する。図１に示す認証システム１は、ＩＤとパスワードとを用いずに認証を行う認証システムである。図１に示すように、認証システム１は、ユーザ端末１０と、ユーザ管理装置２０と、認証装置１００とが含まれる。ユーザ端末１０、ユーザ管理装置２０、及び認証装置１００は図示しない所定の通信網を介して、有線又は無線により通信可能に接続される。なお、図１に示した認証システム１には、複数台のユーザ端末１０や、複数台のユーザ管理装置２０や、複数台の認証装置１００が含まれてもよい。

【0013】

ユーザ端末１０は、ユーザによって利用される情報処理装置である。例えば、ユーザ端末１０は、ユーザによる操作に従って、認証情報である公開鍵や要求情報であるシグナチャを認証装置１００へ送信したり、ユーザ管理装置２０へ公開鍵の登録を要求する情報を送信したりする。なお、以下では、ユーザ端末１０をユーザと表記する場合がある。すなわち、以下では、ユーザをユーザ端末１０と読み替えることもできる。

【0014】

ユーザ管理装置２０は、例えば、ウェブサーバ等である。ユーザ管理装置２０は、認証装置１００からの公開鍵の認証を要請する要請情報を受信したとき、認証装置１００へ公開鍵の認証の結果に関する情報を応答する。また、ユーザ管理装置２０は、ユーザ端末１０からの入力に応じて、公開鍵を登録する処理を実行したりする。

【0015】

認証装置１００は、例えば、ウェブサーバ等である。認証装置１００は、ユーザの認証サービスを提供する。

【0016】

なお、上述したユーザ端末１０は、例えば、スマートフォン、タブレット端末、携帯電話機、ＰＤＡ（Personal Digital Assistant）、ノート型ＰＣ（Personal Computer）、デスクトップＰＣ等により実現される。

【0017】

〔１−２．認証処理〕
次に、図１を用いて、実施形態に係る認証処理の一例について説明する。図１に示す例において、認証装置１００は、認証情報である公開鍵ｏｋ１２、公開鍵ｏｋ１３等を含む公開鍵を認証情報として記憶する。また、認証装置１００は、それぞれの公開鍵に対応するユーザに関する情報であるリソースを公開鍵と関連付けて記憶する。図１に示す例の場合、公開鍵ｏｋ１２には、リソースｒ１２１、リソースｒ１２２等が関連付けて記憶され、公開鍵ｏｋ１３には、リソースｒ１３１等が関連付けて記憶される。

【0018】

ここで、ユーザ管理装置２０では、ユーザ情報を、複数の情報に関連付け、多様な情報を包括的に管理する。本実施形態においては、ユーザ情報をＮＩＤ（Neural Identifier）と表記する場合がある。すなわち、以下では、ユーザ情報をＮＩＤと読み替えることもできる。ユーザ管理装置２０は、ＮＩＤｉｄ１、ＮＩＤｉｄ２等を記憶する。ＮＩＤとは、複数の情報に関連付けられ、多様な情報を包括的に管理するために用いる情報である。ユーザ管理装置２０は、ＮＩＤｉｄ１、ＮＩＤｉｄ２等を記憶する。本実施形態では、ユーザ情報であるＮＩＤは複数の公開鍵に関連付けられる。また、ユーザ管理装置２０は、それぞれのＮＩＤに対応する認証情報である公開鍵をＮＩＤと関連付けて記憶する。図１に示す例の場合、ＮＩＤｉｄ１には、公開鍵ｏｋ１１、公開鍵ｏｋ１２等が関連付けて記憶され、ＮＩＤｉｄ２には、公開鍵ｏｋ２１等が関連付けて記憶される。

【0019】

図１に示すように、ユーザ端末１０は、非公開情報である秘密鍵ｓｋ１２を用いて認証装置１００へ送信する情報を暗号化してシグナチャｓｇ１２を生成する（ステップｓ１１）。ここで、シグナチャに含まれる情報は、送信先である認証装置１００やユーザ管理装置２０に要求する処理内容や、シグナチャ自体の有効期限等が含まれてもよい。なお、シグナチャに含まれる情報についての詳細は後述する。また、秘密鍵ｓｋ１２と公開鍵ｏｋ１２はユーザ端末１０により生成される。秘密鍵ｓｋ１２については、ユーザ端末１０は秘匿状態で記憶する。

【0020】

ここで、秘密鍵ｓｋ１２により暗号化された情報は、公開鍵ｏｋ１２を用いて復号できる。したがって、公開鍵ｏｋ１２を用いて復号できたシグナチャｓｇ１２は、秘密鍵ｓｋ１２を保有するユーザのデバイスであるユーザ端末１０により暗号化されたと判定できる。言い換えると、シグナチャｓｇ１２が公開鍵ｏｋ１２を用いて復号できた場合、認証装置１００は送信元であるユーザ端末１０を特定することが可能となる。

【0021】

次に、ユーザ端末１０は、シグナチャｓｇ１２と公開鍵ｏｋ１２とを認証装置１００へ送信する（ステップｓ１２）。つまり、ユーザ端末１０は、公開鍵ｏｋ１２のペアである秘密鍵ｓｋ１２により暗号化されたシグナチャｓｇ１２と、公開鍵ｏｋ１２とをセットとして送信する。このとき、ユーザ端末１０は、シグナチャｓｇ１２と公開鍵ｏｋ１２とともに送信してもよいし、異なるタイミングで送信してもよい。ここで、シグナチャｓｇ１２と公開鍵ｏｋ１２とともに送信するとは、シグナチャｓｇ１２と公開鍵ｏｋ１２とを同時に送信すること、シグナチャｓｇ１２と公開鍵ｏｋ１２とを一括して送信すること等を含む。

【0022】

認証装置１００は、ユーザ端末１０からシグナチャｓｇ１２と公開鍵ｏｋ１２とを受信すると、受信した公開鍵ｏｋ１２を用いてシグナチャｓｇ１２を復号する（ステップｓ１３）。上述したように、公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号された場合、認証装置１００は、シグナチャｓｇ１２の送信元であるユーザ端末１０が公開鍵ｏｋ１２に対応する秘密鍵ｓｋ１２を保有すると判定できる。公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号できなかった場合、認証装置１００は、シグナチャｓｇ１２の送信元であるユーザ端末１０が公開鍵ｏｋ１２に対応する送信元ではないと判定し、認証処理を中止する。このとき、認証装置１００は、認証処理に失敗したことを適宜の方法によりユーザ端末１０へ通知してもよい。

【0023】

次に、認証装置１００は、公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号された場合、公開鍵ｏｋ１２に対応する公開鍵が認証装置１００内に格納されているかを確認する（ステップｓ１４）。上述したように、認証装置１００は、認証情報として公開鍵を記憶している。認証装置１００は、認証装置１００内に公開鍵ｏｋ１２が格納されていると確認した場合、認証処理を完了する。このとき、認証装置１００は、認証処理に成功したことを適宜の方法によりユーザ端末１０へ通知してもよい。

【0024】

ここで、認証装置１００が公開鍵ｏｋ１２に対応する公開鍵が認証装置１００内に格納されていないと判定した場合について説明する。この場合、認証装置１００はユーザ管理装置２０へ公開鍵ｏｋ１２の認証を要請する要請情報を送信する（ステップｓ１５）。そして、ユーザ管理装置２０は、公開鍵ｏｋ１２の認証の結果に関する情報を応答する。認証装置１００は、ユーザ管理装置２０からユーザ管理装置２０内に公開鍵ｏｋ１２が格納されており公開鍵ｏｋ１２の認証に成功したとの応答を受信すると、公開鍵ｏｋ１２を認証情報として記憶する。一方、ユーザ管理装置２０からユーザ管理装置２０内に公開鍵ｏｋ１２が格納されていない等の理由により、公開鍵ｏｋ１２の認証に失敗したとの応答を受信すると、認証処理を中止する。

【0025】

例えば、図１に示す例において、認証装置１００が公開鍵ｏｋ１１をユーザ端末１１（図４参照）から受信した場合、認証装置１００は公開鍵ｏｋ１１を格納していないため、ユーザ管理装置２０へ公開鍵ｏｋ１１の認証を要請する要請情報を送信する。そして、ユーザ管理装置２０内に公開鍵ｏｋ１１が格納されているため、ユーザ管理装置２０から公開鍵ｏｋ１１の認証に成功したとの応答を受信した認証装置１００は、公開鍵ｏｋ１１を新たに認証情報として記憶する。

【0026】

ここで、認証装置１００が認証装置１００内に公開鍵ｏｋ１２が格納されていると確認して認証が完了した場合（ステップｓ１４）に戻って、以下説明する。このとき、認証装置１００は、復号されたシグナチャｓｇ１２に基づいてリソースの特定をする。さらに、認証装置１００は、復号されたシグナチャｓｇ１２によりリソースの取得が要求されていた場合、公開鍵ｏｋ１２に対応して記憶されたリソースｒ１２１をユーザ端末１０へ送信する（ステップｓ１６）。なお、このとき、認証装置１００は、公開鍵ｏｋ１２を用いて暗号化したリソースｒ１２１をユーザ端末１０へ送信してもよい。これにより、公開鍵ｏｋ１２により暗号化されたリソースｒ１２１は、秘密鍵ｓｋ１２を保有するユーザ端末１０しか復号できないため、認証装置１００は通信のセキュリティを向上することができる。

【0027】

このように、実施形態に係る認証装置１００がユーザ端末から受信したシグナチャと公開鍵とを用いて認証処理を行うため、認証装置１００から情報が漏洩する可能性を低減することができる。具体的には、認証装置１００は、送信元であるユーザ端末が保有する秘密鍵を用いて暗号化されたシグナチャと、公開されている公開鍵とを用いて認証を行う。また、シグナチャは、例えば、ユーザ端末が認証装置１００へアクセスする度に生成され、一度のアクセスにしか使用されない等、非常に短い時間でのみ有効な情報である。したがって、公開鍵とシグナチャは他のユーザ等に秘匿状態で保有しなくてもよいため、認証装置１００から認証情報である公開鍵とシグナチャが漏洩したとしても悪用されてリソースが盗まれたり、なりすましされたりする可能性を低減することができる。また、認証装置１００は、受信した認証情報である公開鍵を格納していない場合であっても、ユーザ管理装置２０へ公開鍵の認証を要請し、ユーザ管理装置２０から公開鍵の認証の結果を受け取ることにより、認証を行うことができる。つまり、認証装置１００は、受信した認証情報である公開鍵を格納していない場合であっても、ユーザの認証を行うことができる。また、認証装置１００がユーザ端末から受信したシグナチャと公開鍵とを用いて認証処理を行うとともにリソースの特定までを行うことで、認証と処理を一括して行うことが可能となる。これにより、認証装置１００は、ユーザビリティを向上させることができる。また、シグナチャに認証装置１００に格納されたリソースの取得を要求する情報が含まれていた場合、認証と併せて要求された情報をユーザ端末へ送信する処理も行うことができ、認証装置１００とユーザ端末とが通信する回数を少なくでき、通信負荷を低減し、処理速度を上げることが可能となる。また、認証装置１００は、ＩＤとパスワードとを用いたログインの必要ない認証を提供することができるため、ユーザの負担を軽減することができる。また、認証を必要とするサービスが複数ある場合であっても、ユーザは自身のＩＤやパスワードを管理してサービス毎に使い分ける必要がなくなり、ユーザがＩＤやパスワードを管理する必要がなくなる。そのため、ログインに用いるＩＤやパスワードの管理の煩雑さを回避するため、ユーザが複数のサービスに対して同じＩＤやパスワードを使いまわす等してセキュリティが低下することも防止できる。

【0028】

〔２．認証装置の構成〕
次に、図２を用いて、実施形態に係る認証装置１００の構成について説明する。図２は、実施例に係る認証装置１００の構成例を示す図である。図２に示すように、認証装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、認証装置１００は、認証装置１００の管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

【0029】

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）によって実現される。かかる通信部１１０は、所定の通信網と有線又は無線で接続される。そして、通信部１１０は、所定の通信網を介して、ユーザ端末１０やユーザ管理装置２０との間で情報の送受信を行う。

【0030】

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部１２０には、公開鍵が認証情報として記憶され、それぞれの公開鍵に対応するユーザに関する情報であるリソースが、公開鍵と関連付けて記憶されている。例えば図１に示した例においては、記憶部１２０には、公開鍵ｏｋ１２にリソースｒ１２１、ｒ１２２等が関連付けて記憶され、公開鍵ｏｋ１３にリソースｒ１３１等が関連付けて記憶されている。

【0031】

制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、認証装置１００内部の記憶装置に記憶されている各種プログラム（認証プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

【0032】

図２に示すように、制御部１３０は、受付部１３１と、認証部１３２と、特定部１３３と、要請部１３４と、送信部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図２に示した接続関係に限られず、他の接続関係であってもよい。

【0033】

（受付部１３１）
受付部１３１は、認証を希望するユーザであるユーザ端末１０から、公開鍵を認証情報として、シグナチャを要求情報として受け付ける。受付部１３１は、公開鍵とシグナチャとを同時に受け付けることが可能であり、また、公開鍵とシグナチャとを異なるタイミングで受け付けることも可能である。

【0034】

（認証部１３２）
認証部１３２は、受付部１３１によって受け付けられた公開鍵とシグナチャとに基づいてデバイスに対応するユーザを認証する。まず、認証部１３２は、受付部１３１によって受け付けられた公開鍵を用いてシグナチャを復号する。このとき、認証部１３２は、受付部１３１によって受け付けられた公開鍵によりシグナチャを復号できれば、次の処理へ進む。一方、認証部１３２は、受付部１３１によって受け付けられた公開鍵によりシグナチャを復号できなければ、認証処理を中止する。

【0035】

ここで、上記処理を図１に示した例に基づいて説明すると、認証部１３２は、受付部１３１によって受け付けられた公開鍵ｏｋ１２とシグナチャｓｇ１２とに基づいてデバイスに対応するユーザを認証する。まず、認証部１３２は、公開鍵ｏｋ１２を用いてシグナチャｓｇ１２を復号する。このとき、認証部１３２は、受付部１３１によって受け付けられた公開鍵ｏｋ１２によりシグナチャｓｇ１２を復号できれば、次の処理へ進む。一方、認証部１３２は、受付部１３１によって受け付けられた公開鍵ｏｋ１２によりシグナチャｓｇ１２を復号できなければ、シグナチャｓｇ１２の送信元であるユーザ端末１０が公開鍵ｏｋ１２に対応する送信元ではないと判定し、認証処理を中止する。

【0036】

次に、認証部１３２は、受付部１３１によって受け付けられた公開鍵に対応する公開鍵が記憶部１２０に格納されているかを確認する。認証部１３２は、記憶部１２０に受付部１３１によって受け付けられた公開鍵が格納されていると確認した場合、認証処理を完了する。

【0037】

上記処理を図１に示した例に基づいて説明すると、認証部１３２は、公開鍵ｏｋ１２に対応する公開鍵が記憶部１２０に格納されているかを確認する。認証部１３２は、記憶部１２０に公開鍵ｏｋ１２が格納されていると確認した場合、認証処理を完了する。

【0038】

（特定部１３３）
特定部１３３は、認証部１３２が記憶部１２０に受付部１３１によって受け付けられた公開鍵が格納されていると確認して認証が完了した場合、受付部１３１によって受け付けられた公開鍵により復号されたシグナチャの情報を確認する。そして、特定部１３３は、復号されたシグナチャに基づいてリソースの特定をする。このとき、特定部１３３は、復号されたシグナチャによりリソースの取得が要求されていた場合、受け付けられた公開鍵に対応して記憶されたリソースの中から復号されたシグナチャにより要求されているリソースを特定する。そして、特定部１３３は、特定したリソースを後述する送信部１３５を介する等の適宜の手段により、認証処理を要求してきたユーザ端末へ送信する。

【0039】

ここで、上記処理を図１に示した例に基づいて説明すると、特定部１３３は、認証部１３２が記憶部１２０に公開鍵ｏｋ１２が格納されていると確認して認証が完了した場合、公開鍵ｏｋ１２により復号されたシグナチャｓｇ１２の情報を確認する。そして、特定部１３３は、復号されたシグナチャｓｇ１２に基づいてリソースｒ１２１の特定をする。このとき、特定部１３３は、復号されたシグナチャｓｇ１２によりリソースの取得が要求されていた場合、公開鍵ｏｋ１２に対応して記憶されたリソースの中から復号されたシグナチャｓｇ１２により要求されているリソースｒ１２１を適宜の手段により、ユーザ端末１０へ送信する。

【0040】

（要請部１３４）
要請部１３４は、認証部１３２が記憶部１２０に受付部１３１によって受け付けられた公開鍵が格納されていないと判定した場合、ユーザ管理装置２０へ受付部１３１によって受け付けられた公開鍵の認証を要請する要請情報をユーザ管理装置２０へ送信する。ここで、要請情報には、公開鍵が含まれてもよい。要請部１３４は、ユーザ管理装置２０からユーザ管理装置２０内に認証を要請した公開鍵が格納されており、認証に成功したとの応答を受信すると、ユーザ管理装置２０が認証に成功した公開鍵を認証情報として記憶部１２０に記憶する。一方、ユーザ管理装置２０からユーザ管理装置２０内に認証を要請した公開鍵が格納されていない等の理由により、認証を要請した公開鍵の認証に失敗したとの応答を受信すると、認証処理を中止する。

【0041】

ここで、上記処理を図１において認証装置１００がユーザ端末１１（図４参照）から公開鍵ｏｋ１１とシグナチャｓｇ１１とを受信した場合に基づいて説明する。要請部１３４は、認証部１３２が記憶部１２０に公開鍵ｏｋ１１が格納されていないと判定した場合、ユーザ管理装置２０へ公開鍵ｏｋ１１の認証を要請する要請情報を送信する。要請部１３４は、公開鍵ｏｋ１１の認証に成功したとの応答を受信すると、ユーザ管理装置２０が認証に成功した公開鍵ｏｋ１１を認証情報として記憶部１２０に記憶する。一方、ユーザ管理装置２０から公開鍵ｏｋ１１の認証に失敗したとの応答を受信すると、認証処理を中止する。

【0042】

（送信部１３５）
送信部１３５は、認証処理を要求してきたユーザ端末へ特定部１３３により特定されたリソースを送信したり、認証部１３２や要請部１３４により認証処理に失敗したことをユーザ端末へ通知したりする。

【0043】

〔３−１．ユーザ管理装置の構成〕
次に、図３を用いて、実施形態に係るユーザ管理装置２０の構成について説明する。図３は、実施例に係るユーザ管理装置２０の構成例を示す図である。図３に示すように、ユーザ管理装置２０は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。なお、ユーザ管理装置２０は、ユーザ管理装置２０の管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

【0044】

（通信部２１０）
通信部２１０は、例えば、ＮＩＣ（Network Interface Card）によって実現される。かかる通信部２１０は、所定の通信網と有線又は無線で接続される。そして、通信部２１０は、所定の通信網を介して、ユーザ端末１０や認証装置１００との間で情報の送受信を行う。

【0045】

（記憶部２２０）
記憶部２２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。記憶部２２０には、ユーザに関するユーザ情報としてＮＩＤが記憶され、ユーザに関連する関連認証情報として公開鍵が対応するＮＩＤに関連付けて記憶されている。例えば図１に示した例においては、記憶部２２０には、ＮＩＤｉｄ１には、公開鍵ｏｋ１１、公開鍵ｏｋ１２等が関連付けて記憶され、ＮＩＤｉｄ２には、公開鍵ｏｋ２１等が関連付けて記憶されている。

【0046】

制御部２３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によってユーザ管理装置２０内部の記憶装置に記憶されている各種プログラム（認証プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部２３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

【0047】

図３に示すように、制御部２３０は、管理部２３１と、認証引受部２３２と、応答部２３３と、送付部２３４と、判定部２３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部２３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部２３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

【0048】

（管理部２３１）
管理部２３１は、ユーザに関するユーザ情報と、ユーザに関連する認証情報である関連認証情報とを関連付けて記憶部２２０へ格納し管理する。つまり、本実施形態において、管理部２３１は、ユーザ情報であるＮＩＤと関連認証情報である公開鍵とを関連付けて記憶部２２０へ格納し管理する。また、管理部２３１は、後述する関連認証情報の登録や新たなユーザ情報の登録を行う。つまり、本実施形態において、管理部２３１は、公開鍵の登録や新たなＮＩＤの登録を行う。

【0049】

（認証引受部２３２）
認証引受部２３２は、認証装置１００から公開鍵の認証を要請する要請情報を受信した場合、認証を要請された公開鍵が記憶部２２０に格納されているかを確認する。具体的には、認証引受部２３２は、認証を要請された公開鍵が記憶部２２０に格納されていれば、認証に成功したと判定し、認証を要請された公開鍵が記憶部２２０に格納されていなければ、認証に失敗したと判定する。

【0050】

ここで、上記処理を図１に示した例に基づいて説明すると、認証引受部２３２は、認証装置１００から公開鍵ｏｋ１２の認証を要請する要請情報を受信した場合、公開鍵ｏｋ１２は記憶部２２０に格納されているので、公開鍵ｏｋ１２の認証に成功したと判定する。例えば、記憶部２２０に格納されていない公開鍵ｏｋ１５の認証を要請する要請情報を受信した場合は、認証引受部２３２は、公開鍵ｏｋ１５認証に失敗したと判定する。

【0051】

（応答部２３３）
応答部２３３は、認証引受部２３２による認証結果に基づいて、認証を要請された公開鍵の認証の結果を認証装置１００へ応答する。具体的には、応答部２３３は、認証引受部２３２が認証を要請された公開鍵の認証に成功したと判定した場合、認証に成功したとの情報を認証装置１００へ応答し、認証引受部２３２が認証を要請された公開鍵の認証に失敗した判定したと場合、認証に失敗したとの情報を認証装置１００へ応答する。

【0052】

ここで、上記処理を図１に示した例に基づいて説明すると、応答部２３３は、認証装置１００から公開鍵ｏｋ１２の認証を要請する要請情報を受信し、認証引受部２３２が認証に成功したと判定した場合、公開鍵ｏｋ１２の認証に成功したとの情報を認証装置１００へ応答する。例えば、記憶部２２０に格納されていない公開鍵ｏｋ１５の認証を要請する要請情報を受信し認証引受部２３２が認証に失敗したと判定した場合、公開鍵ｏｋ１５の認証に失敗したとの情報を認証装置１００へ応答する。なお、認証に成功したとの情報には、関連認証情報である公開鍵が含まれてもよい。

【0053】

（送付部２３４）
送付部２３４は、後述するリカバリ処理を行う必要が生じた場合に、ユーザに関するユーザ情報と新たな認証情報との関連付けに利用される関連付情報を、ユーザに関する宛先情報により指定される宛先へ送付する。つまり、本実施形態において、送付部２３４は、後述するリカバリ処理を行う必要が生じた場合に、ユーザに関するユーザ情報であるＮＩＤと新たな認証情報である公開鍵との関連付けに利用される関連付情報を、ユーザに関する宛先情報により指定される宛先へ送付する。

【0054】

（判定部２３５）
判定部２３５は、後述するリカバリ処理を行う必要が生じた場合に、宛先に対応する送信元から受け付けた関連付情報と新たな公開鍵とシグナチャとに基づいて、ユーザ情報と新たな公開鍵との関連付けを行うか判定する。つまり、本実施形態において、判定部２３５は、後述するリカバリ処理を行う必要が生じた場合に、宛先に対応する送信元から受け付けた関連付情報と新たな公開鍵とシグナチャとに基づいて、ユーザ情報であるＮＩＤと新たな公開鍵との関連付けを行うか判定する。

【0055】

〔３−２．ユーザ管理装置とユーザ端末〕
ここで、ユーザ管理装置２０に格納されているユーザ情報であるＮＩＤ及び関連認証情報である公開鍵と、ユーザ端末が生成した公開鍵との関係を、図４に示す例に基づいて説明する。図４に示す例では、ユーザ管理装置２０内において、ＮＩＤｉｄ１には、公開鍵ｏｋ１１、公開鍵ｏｋ１２等が関連付けて記憶され、ＮＩＤｉｄ２には、公開鍵ｏｋ２１等が関連付けて記憶される。そして、ユーザ端末１０は、秘密鍵ｓｋ１２と公開鍵ｏｋ１２を生成し格納し、ユーザ端末１１は、秘密鍵ｓｋ１１と公開鍵ｏｋ１１を生成し格納する。

【0056】

そして、ユーザ端末１０の公開鍵ｏｋ１２と、ユーザ端末１１の公開鍵ｏｋ１１とは、ユーザ管理装置２０内において、同じＮＩＤｉｄ１に関連付けて記憶されている。したがって、図４に示す例においては、ユーザ端末１０とユーザ端末１１とは、ＮＩＤｉｄ１で示される同一のユーザの所有するデバイスであることがわかる。このように、ユーザが複数のデバイスを所有している場合であっても、同一のユーザが使用しているデバイスであると判定でき、ユーザとデバイスとの関連付けを行うことが可能となる。

【0057】

〔３−３．ユーザ情報の登録〕
次に、図５を用いて、ユーザ管理装置２０にユーザ情報であるＮＩＤが登録されていないユーザから、ＮＩＤの登録を要求された場合の処理手順について説明する。図５は、ユーザ管理装置２０によるＮＩＤの登録手順を示すフローチャートである。このようなＮＩＤの登録は、例えば、認証システム１を利用するアプリをユーザ端末１０にダウンロードした時に実行される。

【0058】

まず、ユーザ管理装置２０にＮＩＤの登録を行うユーザは、公開鍵と秘密鍵とを生成する（ステップｓ１０１）。そして、生成した秘密鍵を用いてシグナチャを生成する（ｓ１０２）。図６（ａ）には、シグナチャのフォーマットの一例を示している。図６（ａ）に示す例では、シグナチャには、有効期限に関する情報と、リソースパス等の情報が含まれる。図６（ｂ）には具体的な情報が含まれた例を示しており、有効期限に関する情報には有効期限を示す情報が含まれており、リソースパス等の情報には、公開鍵を登録することを要求する情報が含まれている。ユーザは、生成した公開鍵とシグナチャとを用いてユーザ管理装置２０の登録ＡＰＩをコールする（ステップｓ１０３）。

【0059】

登録ＡＰＩをコールされたユーザ管理装置２０において、管理部２３１は、ユーザから受信した公開鍵を用いてシグナチャを復号する。そして、管理部２３１は、シグナチャを復号することができれば、新しいＮＩＤを払い出す（ステップｓ１０４）。次に、管理部２３１は、新しいＮＩＤと受信した公開鍵とを関連付けて記憶部２２０に登録する（ステップｓ１０５）。

【0060】

〔４．認証処理手順〕
次に、図７を用いて、実施形態に係る認証システム１による認証処理の手順について説明する。図７は、実施形態に係る認証システム１による認証処理手順を示すシーケンス図である。

【0061】

図７に示すように、ユーザは、ユーザ端末１０を用いて秘密鍵と公開鍵とを生成し、秘密鍵を用いてシグナチャを生成する（ステップＳ２０１）。

【0062】

そして、認証装置１００は、ユーザ端末１０から公開鍵とシグナチャとを受信した場合に（ステップｓ２０２）、公開鍵でシグナチャを復号し、正しく復号できるかチェックする（ステップｓ２０３）。

【0063】

続いて、認証装置１００は、対応する公開鍵を特定し、シグナチャに基づいてリソースを特定する（ステップｓ２０４）。このとき、認証装置１００は、対応する公開鍵がなければ、ユーザ管理装置２０へ公開鍵の認証を要請する（ステップｓ２０５）。認証装置１００から要請を受けたユーザ管理装置２０は、対応する公開鍵に関する情報である認証の結果を認証装置１００へ応答する（ステップｓ２０６）。

【0064】

続いて、認証装置１００は、シグナチャにより要求されているリソースがある場合、特定したリソースをユーザ端末１０へ送信する（ステップｓ２０７）。

【0065】

〔５．リカバリ処理〕
ここで、ユーザ管理装置２０に登録されているユーザ情報であるＮＩＤに新たに公開鍵を関連付ける際に行うリカバリ処理について図８を用いて説明する。リカバリ処理を行う例としては、例えば機種変更した場合や、リセットにより秘密鍵及び公開鍵が消去された場合等が挙げられる。また、リカバリ処理を行う前提として、ユーザ管理装置２０に登録されているＮＩＤには、関連付情報を送付する宛先が関連付けて記憶されている必要がある。図８に示す例においては、宛先としてメールアドレスがＮＩＤに関連付けて記憶されている。なお、宛先としては、電話番号等、情報を伝達可能なものであればよい。

【0066】

まず、リカバリ処理を行いたいユーザは、ユーザ端末からメールアドレスを入力し（ステップｓ３０１）、そのメールアドレスを用いてリカバリＡＰＩをコールする（ステップｓ３０２）。

【0067】

リカバリＡＰＩをコールされたユーザ管理装置２０は、受信したメールアドレスから関連付けられているＮＩＤを逆引きして特定する（ステップｓ３０３）。そして、ユーザ管理装置２０は、メールアドレスに関連付けられる共通鍵と、認証に用いるコードとを作成する（ステップｓ３０４）。ユーザ管理装置２０は、作成した共通鍵で関連付情報を暗号化してリカバリキーを生成する（ステップｓ３０５）。なお、関連付情報には、有効期限、コード、メールアドレス、ＮＩＤ等の情報が含まれてもよい。そして、ユーザ管理装置２０は、送付部２３４により、入力されたメールアドレスを宛先としてコードをメールで送信し、リカバリキーをユーザへメールで送信する等して渡す（ステップｓ３０６）。

【0068】

コードやリカバリキー等が含まれるメールを受信したユーザは、受信したコードを、例えばユーザ管理装置２０が提供する認証画面等に入力して、ユーザ管理装置２０へ送信する（ステップｓ３０７）。そして、コードが認証されたユーザは、新たな公開鍵と秘密鍵とを生成し、生成した秘密鍵でシグナチャを生成する（ステップｓ３０８）。その後、ユーザは、コード、メールアドレス、リカバリキー、新たな公開鍵、シグナチャ等を用いてリカバリＡＰＩをコールする（ステップｓ３０９）。

【0069】

リカバリＡＰＩをコールされたユーザ管理装置２０は、判定部２３５により受信した新たな公開鍵を用いてシグナチャを復号し、正しく復号できるかチェックする（ステップｓ３１０）。そして、ユーザ管理装置２０は、判定部２３５により受信したリカバリキーをメールアドレスに関連付けられた共通鍵で復号し、コード及びメールアドレスの一致を確認する（ステップｓ３１１）。上記ステップｓ３１０及びｓ３１１が成功すれば、ユーザ管理装置２０は、新たな公開鍵を関連認証情報として対応するＮＩＤと関連付ける（ステップｓ３１２）。これにより、ＮＩＤと新たな公開鍵とを関連付けることができる。したがって、上記リカバリ処理を行うことで、ユーザに新しい端末を関連付けることが容易にできる。

【0070】

〔６．変形例〕
上述した実施形態に係る認証システム１は、上記実施形態以外にも様々な異なる形態にて実施されてよい。そこで、以下では、上記の認証システム１の他の実施形態について説明する。

【0071】

〔６−１．認証装置のユーザ情報の格納〕
上記実施形態においては、認証装置１００が認証情報である公開鍵に関連付けてリソースを格納する例を示した。しかし、認証装置には、ユーザ情報であるＮＩＤに関連付けてリソースを格納してもよい。以下では、図９を用いて、認証装置がＮＩＤに関連付けてリソースを格納する認証システム２の認証処理の一例について説明する。図９に示す例において、認証装置１０１は、ＮＩＤｉｄ１、ＮＩＤｉｄ３等を含むユーザ情報であるＮＩＤそれぞれに対応するユーザに関する情報であるリソースをＮＩＤと関連付けて記憶する。図９に示す例の場合、ＮＩＤｉｄ１には、リソースｒ１２１、リソースｒ１２２等が関連付けて記憶され、ＮＩＤｉｄ３には、リソースｒ１３１等が関連付けて記憶される。

【0072】

ここで、ユーザ管理装置２１は、ＮＩＤｉｄ１、ＮＩＤｉｄ２等を記憶する。また、ユーザ管理装置２１は、それぞれのＮＩＤに対応する公開鍵をＮＩＤと関連付けて記憶する。図９に示す例の場合、ＮＩＤｉｄ１には、公開鍵ｏｋ１１、公開鍵ｏｋ１２等が関連付けて記憶され、ＮＩＤｉｄ２には、公開鍵ｏｋ２１等が関連付けて記憶される。

【0073】

図９に示すように、ユーザ端末１０は、秘密鍵ｓｋ１２を用いて認証装置１０１へ送信する情報を暗号化してシグナチャｓｇ１２を生成する（ステップｓ２１）。また、秘密鍵ｓｋ１２と公開鍵ｏｋ１２はユーザ端末１０により生成される。秘密鍵ｓｋ１２については、ユーザ端末１０は秘匿状態で記憶する。

【0074】

ここで、秘密鍵ｓｋ１２により暗号化された情報は、公開鍵ｏｋ１２を用いて復号できる。したがって、公開鍵ｏｋ１２を用いて復号できたシグナチャｓｇ１２は、秘密鍵ｓｋ１２を保有するユーザのデバイスであるユーザ端末１０により暗号化されたと判定できる。言い換えると、シグナチャｓｇ１２が公開鍵ｏｋ１２を用いて復号できた場合、認証装置１０１は送信元であるユーザ端末１０を特定することが可能となる。

【0075】

次に、ユーザ端末１０は、シグナチャｓｇ１２と公開鍵ｏｋ１２とを認証装置１０１へ送信する（ステップｓ２２）。つまり、ユーザ端末１０は、公開鍵ｏｋ１２のペアである秘密鍵ｓｋ１２により暗号化されたシグナチャｓｇ１２と、公開鍵ｏｋ１２とをセットとして送信する。このとき、ユーザ端末１０は、シグナチャｓｇ１２と公開鍵ｏｋ１２とともに送信してもよいし、異なるタイミングで送信してもよい。ここで、シグナチャｓｇ１２と公開鍵ｏｋ１２とともに送信するとは、シグナチャｓｇ１２と公開鍵ｏｋ１２とを同時に送信することや、シグナチャｓｇ１２と公開鍵ｏｋ１２とを一括して送信すること等を含む。

【0076】

認証装置１０１は、ユーザ端末１０からシグナチャｓｇ１２と公開鍵ｏｋ１２とを受信すると、受信した公開鍵ｏｋ１２を用いてシグナチャｓｇ１２を復号する（ステップｓ２３）。上述したように、公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号された場合、認証装置１０１は、シグナチャｓｇ１２の送信元であるユーザ端末１０が公開鍵ｏｋ１２に対応する秘密鍵ｓｋ１２を保有すると判定できる。公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号できなかった場合、認証装置１０１は、シグナチャｓｇ１２の送信元であるユーザ端末１０が公開鍵ｏｋ１２に対応する送信元ではないと判定し、認証処理を中止する。このとき、認証装置１０１は、認証処理に失敗したことを適宜の方法によりユーザ端末１０へ通知してもよい。

【0077】

次に、認証装置１０１は、公開鍵ｏｋ１２によりシグナチャｓｇ１２が正しく復号された場合、認証装置１０１は、公開鍵ｏｋ１２に対応する公開鍵が認証装置１０１内に格納されているかを確認する。そして、公開鍵ｏｋ１２に対応する公開鍵が認証装置１０１内に格納されている場合、認証装置１０１は、入力された公開鍵に対応するＮＩＤを返却するユーザ管理装置２１のＡＰＩをコールし、格納されていない場合、認証装置１０１は、ユーザ管理装置２１へ公開鍵ｏｋ１２の認証を要請する要請情報を送信する（ステップｓ２４）。これにより、認証装置１０１は、受信した公開鍵に対応するＮＩＤをユーザ管理装置２１から取得することができる（ステップｓ２５）。認証装置１０１は、ユーザ管理装置２１へ送信した公開鍵に対応するＮＩＤが取得できないか、又は、ユーザ管理装置２１が送信した公開鍵の認証に失敗した場合、証処理を中止する。このとき、認証装置１０１は、認証処理に失敗したことを適宜の方法によりユーザ端末１０へ通知してもよい。

【0078】

図９に示す例において、公開鍵ｏｋ１２に対応する公開鍵が認証装置１０１内に格納されている場合、認証装置１０１は、公開鍵ｏｋ１２を用いてＮＩＤを返却するユーザ管理装置２１のＡＰＩをコールし、公開鍵ｏｋ１２に対応するＮＩＤｉｄ１を取得する。また、公開鍵ｏｋ１２に対応する公開鍵が認証装置１０１内に格納されていない場合、ユーザ管理装置２１へ公開鍵ｏｋ１２の認証を要請する要請情報を送信し、ユーザ管理装置２１から公開鍵ｏｋ１２の認証の結果を受信する。このとき、認証装置１０１は、公開鍵ｏｋ１２を対応するＮＩＤｉｄ１に関連付けて格納する。

【0079】

次に、認証装置１０１は、復号されたシグナチャｓｇ１２に基づいてリソースの特定をする。さらに、認証装置１０１は、復号されたシグナチャｓｇ１２によりリソースの取得が要求されていた場合、公開鍵ｏｋ１２に対応するＮＩＤｉｄ１に関連付けて記憶されたリソースｒ１２１をユーザ端末１０へ送信する（ステップｓ２６）。なお、このとき、認証装置１０１は、公開鍵ｏｋ１２を用いて暗号化したリソースｒ１２１をユーザ端末１０へ送信してもよい。これにより、公開鍵ｏｋ１２により暗号化されたリソースｒ１２１は、秘密鍵ｓｋ１２を保有するユーザ端末１０しか復号できないため、認証装置１０１は通信のセキュリティを向上することができる。

【0080】

ここで、上記の処理手順を、図１０に示すフローチャートを用いて説明する。まず、認証とリソースの要求を行うユーザは、ユーザ端末に格納された秘密鍵を用いてシグナチャを生成する（ステップｓ４０１）。そして、その秘密鍵に対応する公開鍵とシグナチャとを用いて、認証装置１０１のリソースＡＰＩをコールする（ステップｓ４０２）。

【0081】

リソースＡＰＩをコールされた認証装置１０１は、受信した公開鍵を用いてシグナチャを復号し、正しく復号できるかシグナチャをチェックし、検証する（ステップｓ４０３）。そして、認証装置１０１は、公開鍵からＮＩＤを逆引きして特定する（ステップｓ４０４）。認証装置１０１は、公開鍵から対応するＮＩＤを特定する際に、ユーザ管理装置２１へ公開鍵に関連付けられているＮＩＤの取得を要求し、ユーザ管理装置２１からの情報によりＮＩＤを特定する。

【0082】

続けて、認証装置１０１は、特定したＮＩＤからリソースを検索する（ステップｓ４０５）。そして、特定されたリソースをユーザへ返却する（ステップｓ４０６）。これにより、ユーザは異なるユーザ端末から認証装置１０１にアクセスしても、常に同じＮＩＤに紐づくリソースを取得することができる。

【0083】

〔６−２．ユーザ管理装置と認証装置〕
ここで、図９に示す認証システム２におけるユーザ管理装置２１に格納されるユーザ情報であるＮＩＤと、複数の認証装置１０１、１０２に格納されるＮＩＤとの関係を、図１１に示す例に基づいて説明する。図１１に示す例では、ユーザ管理装置２１内において、ＮＩＤｉｄ１には、公開鍵ｏｋ１１、公開鍵ｏｋ１２等が関連付けて記憶され、ＮＩＤｉｄ２には、公開鍵ｏｋ２１等が関連付けて記憶される。また、図９に示すように認証装置１０１、１０２は、それぞれＮＩＤに関連付けてリソースを格納する。

【0084】

そして、ユーザ端末１０の公開鍵ｏｋ１２と、ユーザ端末１１の公開鍵ｏｋ１１とは、ユーザ管理装置２１内において、同じＮＩＤｉｄ１に関連付けて記憶されている。したがって、図１１に示す例においては、認証装置１０１、１０２は、ユーザ端末１０とユーザ端末１１とのいずれから認証とリソースの要求をされても、同じＮＩＤに関連付けられたリソースを返却することができる。すなわち、認証装置１０１、１０２は、ユーザ端末１０とユーザ端末１１とが、ＮＩＤｉｄ１で示される同一のユーザの所有するデバイスであることがわかる。このように、ユーザが複数のデバイスを所有している場合であっても、同一のユーザが使用しているデバイスであると判定でき、そのユーザに関するリソースを返却することが可能となる。

【0085】

〔６−３．シグナチャ〕
シグナチャに含まれる情報としては、ユーザの権限に関する情報が含まれていてもよい。例えば、ユーザの権限に関する情報として、要求情報であるシグナチャにより特定されるリソースへのアクセスが認められているかの情報をシグナチャが含んでいる場合、特定部１３３は、ユーザの権限に関する情報に応じてリソースへのアクセス可否を判定する。そして、認証部１３２は、アクセスが認められている場合のみ、リソースの特定を行う。これにより、ユーザの権限を細かく設定できる。

【0086】

〔６−４．認証情報の失効〕
ユーザ管理装置２０の管理部２３１は、所定の条件を満たした場合、記憶部２２０に格納された認証情報である公開鍵を失効させてもよい。例えば、ユーザ情報であるＮＩＤが削除された場合に、ＮＩＤに関連付けられた関連認証情報である公開鍵を失効させる。図１に示した例に基づいて説明すると、ユーザ管理装置２０からＮＩＤｉｄ１が削除された場合、公開鍵ｏｋ１１、公開鍵ｏｋ１２等、ＮＩＤｉｄ１に関連付けられている全ての公開鍵を失効させる。また、例えば、要求情報であるシグナチャの暗号化に用いた秘密鍵が送信元であるユーザ端末から削除されるか又は漏洩した場合に、送信元に対応する関連認証情報である公開鍵を失効させる。図１に示した例に基づいて説明すると、送信元であるユーザ端末１０から秘密鍵ｓｋ１２が削除されるか又は漏洩した場合、ユーザ管理装置２０は、ユーザ端末１０に対応する関連認証情報である公開鍵ｏｋ１２を失効させる。つまり、複数ある認証装置側の認証情報である公開鍵を失効させる必要はなく、ユーザ管理装置の関連認証情報である公開鍵を失効させるだけでよい。これにより、不正なアクセス等を防止することができる。なお、ユーザ管理装置２０は、公開鍵を失効させたことを、適宜の手段により失効させた公開鍵を格納している認証装置１００へ通知してもよい。また、ユーザ管理装置２０が失効させた公開鍵に関する通知を受けた認証装置１００は、対応する公開鍵を失効させてもよい。

【0087】

〔６−５．認証の権限委譲〕
上記実施形態においては、公開鍵と秘密鍵のペアを生成したユーザ端末から受信した公開鍵とシグナチャとを用いて認証を行ったが、ユーザ端末は他のユーザ端末へ認証を受ける権限を委譲してもよい。例としては、店舗へ入ったユーザが所持するユーザ端末から他のユーザ端末である店舗端末へ権限の委譲を行う場合が挙げられる。図１２は認証の権限を委譲した場合の認証システム３の一例を示しており、その処理について以下説明する。図１２では、ユーザが所持するユーザ端末１２から権限が委譲された店舗端末であるユーザ端末１３が、ユーザ管理装置２２へ認証を要求し、ユーザ管理装置２２からリソースとしてメールアドレスを取得する場合を一例として示している。なお、リソースとしては、メールアドレスに限らず、住所や氏名等の個人情報や顔写真等の画像情報であってもよい。

【0088】

図１２に示す例においては、ユーザ管理装置２２は、ユーザ情報としてＮＩＤｉｄ１、ＮＩＤｉｄ２等を記憶する。また、ユーザ管理装置２２は、それぞれのＮＩＤに対応するメールアドレスをＮＩＤと関連付けて記憶している。図１２に示す例の場合、ＮＩＤｉｄ１には、メールアドレスｍ１が関連付けて記憶されており、ＮＩＤｉｄ２には、メールアドレスｍ２が関連付けて記憶されている。また、図示することは省略するが、図１２に示す例においては、各ＮＩＤには対応する公開鍵やリソースが関連付けられている。

【0089】

図１２に示すように、ユーザ端末１２は、秘密鍵ｓｋ１４を用いて認証装置１０１へ送信する情報を暗号化してシグナチャｓｇ１４を生成する（ステップｓ３１）。ユーザ端末１２は、シグナチャｓｇ１４と公開鍵ｏｋ１４とをユーザ端末１３へ送信する（ステップｓ３２）。

【0090】

ユーザ端末１３は、ユーザ端末１２から受信したシグナチャｓｇ１４と公開鍵ｏｋ１４とをユーザ管理装置２２へ送信する（ステップｓ３３）。

【0091】

ユーザ端末１３からシグナチャｓｇ１４と公開鍵ｏｋ１４とを受信したユーザ管理装置２２は、受信した公開鍵ｏｋ１４を用いてシグナチャｓｇ１４を復号し、正しく復号できるか確認する（ステップｓ３４）。公開鍵ｏｋ１４によりシグナチャｓｇ１４が正しく復号できなかった場合、ユーザ端末１３がユーザ端末１２から権限を委譲された送信元ではないと判定し、認証処理を中止する。このとき、ユーザ管理装置２２は、認証処理に失敗したことを適宜の方法によりユーザ端末１２やユーザ端末１３へ通知してもよい。

【0092】

次に、ユーザ管理装置２２は、公開鍵ｏｋ１４によりシグナチャｓｇ１４が正しく復号された場合、公開鍵ｏｋ１４に対応するＮＩＤがユーザ管理装置２２内に格納されているかを確認する（ステップｓ３５）。ユーザ管理装置２２が公開鍵ｏｋ１４に対応するＮＩＤｉｄ１がユーザ管理装置２２内に格納されていると判定した場合、公開鍵ｏｋ１４の認証に成功した判定し、ＮＩＤｉｄ１に関連付けられているメールアドレスｍ１をユーザ端末１３へ送信する（ステップｓ３６）。これにより、ユーザ端末１２から権限を委譲されたユーザ端末１３は、ユーザ管理装置２２からユーザ端末１２に関するリソースを取得することが可能となる。なお、ユーザ管理装置２２が公開鍵ｏｋ１４に対応するＮＩＤがユーザ管理装置２２内に格納されていないと判定した場合、公開鍵ｏｋ１４の認証に失敗したとの応答をユーザ端末１３へ送信し、認証処理を中止する。

【0093】

〔６−６．装置構成〕
また、図２に示した認証装置１００は、記憶部１２０を有しなくてもよい。具体的には、認証装置１００は、記憶部１２０を保持するデータベースサーバと接続されてもよい。また、図３に示したユーザ管理装置２０は、記憶部２２０を有しなくてもよい。具体的には、ユーザ管理装置２０は、記憶部２２０を保持するデータベースサーバと接続されてもよい。

【0094】

〔６−７．プログラム〕
また、上述してきた実施形態に係る認証装置１００やユーザ管理装置２０は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、認証装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

【0095】

ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

【0096】

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、通信網３０を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを通信網３０を介して他の機器へ送信する。

【0097】

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを入出力インターフェイス１６００を介して出力装置へ出力する。

【0098】

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

【0099】

例えば、コンピュータ１０００が実施形態に係る認証装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網３０を介してこれらのプログラムを取得してもよい。

【0100】

〔６−８．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

【0101】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図２に示した受付部１３１と送信部１３５とは統合されてもよい。

【0102】

また、上述してきた各実施形態は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

【0103】

〔６−９．効果〕
上述してきたように、実施形態に係る認証装置１００は、受付部１３１と、認証部１３２とを有する。受付部１３１は、送信元のデバイスに対応する認証情報（実施形態においては、公開鍵。以下同じ）と、前記デバイスに格納された非公開情報（実施形態においては、秘密鍵。以下同じ）により暗号化された情報であって認証情報により復号される要求情報（実施形態においては、シグナチャ。以下同じ）とを受け付ける。認証部１３２は、認証情報と要求情報とに基づいてデバイスに対応するユーザを認証する。

【0104】

これにより、認証装置１００がユーザ端末から受信したシグナチャと公開鍵とを用いて認証処理を行うため、認証装置１００から情報が漏洩する可能性を低減することができる。認証装置１００は、送信元であるユーザ端末が保有する秘密鍵を用いて暗号化されたシグナチャと、公開されている公開鍵とを用いて認証を行う。そのため、認証装置１００から認証情報である公開鍵やシグナチャが漏洩したとしても悪用されてリソースが盗まれたり、なりすましされたりする可能性を低減することができる。また、認証装置１００は、ＩＤとパスワードとを用いたログインの必要ない認証を提供することができるため、ユーザの負担を軽減することができる。

【0105】

また、実施形態に係る認証装置１００において、受付部１３１は、認証情報と要求情報とをともに受け付ける。認証部１３２は、認証情報と、当該認証情報とともに受け付けた要求情報とに基づいてユーザを認証する。

【0106】

これにより、実施形態に係る認証装置１００は、認証情報と要求情報とが同じ送信元から送信されており、送信元が公開鍵とペアとなる秘密鍵を確かに保持していることが確認できるので、認証情報と要求情報とに基づいて認証を行うことにより正確に認証することができる。したがって、認証装置１００は、なりすましされたりする可能性をさらに低減することができる。

【0107】

また、実施形態に係る認証装置１００において、受付部１３１は、有効期限に関する情報を含む要求情報を受け付ける。認証部１３２は、要求情報に含まれる有効期限に関する情報に基づいて有効期限の経過前であると判定した場合にデバイスに対応するユーザを認証する。

【0108】

これにより、実施形態に係る認証装置１００は、有効期限の経過前である場合のみ、認証を受け付けるため、よりセキュリティレベルの高いユーザ認証ができる。

【0109】

また、実施形態に係る認証装置１００は、要請部１３４を有する。要請部１３４は、ユーザに関するユーザ情報（実施形態においては、ＮＩＤ。以下同じ）と、ユーザに関連する認証情報である関連認証情報とを関連付けて管理するユーザ管理装置２０に対して、認証情報の認証を要請する。認証部１３２は、ユーザ管理装置２０により認証情報の認証が成功した場合、認証情報と要求情報とに基づいてデバイスに対応するユーザを認証する。

【0110】

これにより、実施形態に係る認証装置１００においては、認証装置１００に認証情報が格納されていないユーザについても認証できる。言い換えると、これにより、認証装置１００は新しい認証情報の追加が可能となる。

【0111】

変形例に係る認証装置１０１は、特定部を有する。特定部は、ユーザ情報に対応付けて記憶されているリソースのうち前記要求情報により要求されているリソースを特定する。

【0112】

これにより、変形例に係る認証装置１０１は、認証を行うとともに、認証に用いる情報によってリソースの特定までを行うことにより、ユーザビリティを向上させることができる。

【0113】

実施形態に係る認証装置１００は、特定部１３３を有する。特定部１３３は、認証情報に対応付けて記憶されているリソースのうち前記要求情報により要求されているリソースを特定する。

【0114】

これにより、実施形態に係る認証装置１００は、認証を行うとともに、認証に用いる情報によってリソースの特定までを行うことにより、ユーザビリティを向上させることができる。

【0115】

また、実施形態に係る認証装置１００において、受付部１３１は、ユーザの権限に関する情報を含む要求情報を受け付ける。認証部１３２は、要求情報に含まれる権限に関する情報に基づいて、要求情報により特定されるリソースへのアクセスが認められているかを判定する。

【0116】

これにより、実施形態に係る認証装置１００は、ユーザの権限を細かく設定でき、不要なリソースへのアクセス等を防止できる。

【0117】

また、実施形態に係る認証装置１００は、送信部１３５を有する。送信部１３５は、要求情報に基づいて特定されたリソースに関する情報を送信元へ送信する。

【0118】

これにより、実施形態に係る認証装置１００においては、ユーザへリソースを提供できる。

【0119】

また、実施形態に係るユーザ管理装置２０は、管理部２３１と、認証引受部２３２と、応答部２３３とを有する。管理部２３１は、ユーザに関するユーザ情報と、ユーザに関連する認証情報である関連認証情報とを関連付けて管理する。認証引受部２３２は、受け付けた要請情報に基づいて認証情報を認証する。応答部２３３は、認証情報の認証の結果に関する情報を応答する。

【0120】

これにより、実施形態に係るユーザ管理装置２０は、認証装置１００へ認証の結果を応答することができる。

【0121】

また、実施形態に係るユーザ管理装置２０において、管理部２３１は、ユーザ情報が削除された場合に、ユーザ情報に関連付けられた関連認証情報を失効させる。

【0122】

これにより、実施形態に係るユーザ管理装置２０は、不正なアクセス等を防止することができる。

【0123】

また、実施形態に係るユーザ管理装置２０において、管理部２３１は、要求情報の暗号化に用いた非公開情報が送信元から削除されるか又は漏洩した場合に、送信元に対応する関連認証情報を失効させる。

【0124】

これにより、複数ある認証装置側の認証情報である公開鍵を失効させる必要はなく、ユーザ管理装置２０の関連認証情報である公開鍵を失効させるだけでよい。したがって、実施形態に係るユーザ管理装置２０は、不正なアクセス等を防止することができる。

【0125】

また、実施形態に係るユーザ管理装置２０は、送付部２３４と、判定部２３５とを有する。送付部２３４は、ユーザに関するユーザ情報と新たな認証情報との関連付けに利用される関連付情報を、ユーザに関する宛先情報により指定される宛先へ送付する。判定部２３５は、宛先に対応する送信元から受け付けた関連付情報と新たな認証情報と要求情報とに基づいて、ユーザ情報と新たな認証情報との関連付けを行うか判定する。管理部２３１は、判定部２３５により関連付けを行うと判定された場合、新たな認証情報を新たな関連認証情報としてユーザ情報に関連付ける。

【0126】

これにより、実施形態に係るユーザ管理装置２０は、関連認証情報を新しく追加することができる。

【0127】

以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の行に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

【0128】

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、受付部は、受付手段や受付回路に読み替えることができる。

【符号の説明】

【0129】

１ 認証システム
１０ ユーザ端末
２０ ユーザ管理装置
１００ 認証装置
１２０ 記憶部
１３１ 受付部
１３２ 認証部
１３３ 特定部
１３４ 要請部
１３５ 送信部
２２０ 記憶部
２３１ 管理部
２３２ 認証引受部
２３３ 応答部
２３４ 送付部
２３５ 判定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】