(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023159786
(43)【公開日】2023-11-01
(54)【発明の名称】情報処理装置、情報処理方法及び情報処理プログラム
(51)【国際特許分類】
G06F 21/33 20130101AFI20231025BHJP
G06F 21/32 20130101ALI20231025BHJP
H04L 9/32 20060101ALI20231025BHJP
【FI】
G06F21/33
G06F21/32
H04L9/32 200B
H04L9/32 200F
【審査請求】未請求
【請求項の数】11
【出願形態】OL
(21)【出願番号】P 2022069712
(22)【出願日】2022-04-20
(71)【出願人】
【識別番号】319013263
【氏名又は名称】ヤフー株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】伊藤 雄哉
(72)【発明者】
【氏名】吉岡 知彦
(72)【発明者】
【氏名】渡邉 康平
(72)【発明者】
【氏名】倉林 雅
(72)【発明者】
【氏名】五味 秀仁
(57)【要約】
【課題】認証技術における認証器管理の手法をさらに向上させる。
【解決手段】本願に係る情報処理装置は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する認証処理部と、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する管理部と、を備える。管理部は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。認証処理部は、認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。管理部は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。
【選択図】
図8
【特許請求の範囲】
【請求項1】
アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する認証処理部と、
前記アテステーション文書を保管し、前記アテステーション文書の認証強度を継続的に管理する管理部と、
を備えることを特徴とする情報処理装置。
【請求項2】
前記管理部は、セキュリティ強化を決定した際に、既に保管している前記アテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する
ことを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記管理部は、時間経過又は問題の発見により、前記認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する
ことを特徴とする請求項1又は2に記載の情報処理装置。
【請求項4】
前記管理部は、セキュリティポリシーの変更により、前記認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する
ことを特徴とする請求項1又は2に記載の情報処理装置。
【請求項5】
前記管理部は、前記アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する
ことを特徴とする請求項1又は2に記載の情報処理装置。
【請求項6】
前記認証処理部は、前記認証器の秘密鍵を用いた署名を、前記秘密鍵に対応する公開鍵で検証し、
前記管理部は、前記公開鍵の信頼性強度を管理し、前記公開鍵の信頼性強度が低下した場合、前記公開鍵の変更を要求する
ことを特徴とする請求項1又は2に記載の情報処理装置。
【請求項7】
前記管理部は、時間経過により、前記公開鍵の信頼性強度が低下したと判断し、前記公開鍵の変更を要求する
ことを特徴とする請求項6に記載の情報処理装置。
【請求項8】
前記管理部は、前記公開鍵の有効期限が切れた場合、前記公開鍵の信頼性強度が低下したと判断し、前記公開鍵の変更を要求する
ことを特徴とする請求項6に記載の情報処理装置。
【請求項9】
前記管理部は、前記公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、前記公開鍵の信頼性強度が低下したと判断し、前記公開鍵の変更を要求する
ことを特徴とする請求項6に記載の情報処理装置。
【請求項10】
情報処理装置が実行する情報処理方法であって、
アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間で認証を実施する認証処理工程と、
前記アテステーション文書を保管し、前記アテステーション文書の認証強度を継続的に管理する管理工程と、
を含むことを特徴とする情報処理方法。
【請求項11】
アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間で認証を実施する認証処理手順と、
前記アテステーション文書を保管し、前記アテステーション文書の認証強度を継続的に管理する管理手順と、
をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
【背景技術】
【0002】
認証に関する技術であって、認証器を用いる技術が開示されている(特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記の従来技術では、認証技術における認証器管理の手法に関してまだまだ改善の余地がある。
【0005】
本願は、上記に鑑みてなされたものであって、認証技術における認証器管理の手法をさらに向上させることを目的とする。
【課題を解決するための手段】
【0006】
本願に係る情報処理装置は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する認証処理部と、前記アテステーション文書を保管し、前記アテステーション文書の認証強度を継続的に管理する管理部と、を備えることを特徴とする。
【発明の効果】
【0007】
実施形態の一態様によれば、認証技術における認証器管理の手法をさらに向上させることができる。
【図面の簡単な説明】
【0008】
【
図1】
図1は、実施形態に係る情報処理方法の概要を示す説明図である。
【
図3】
図3は、アイデンティティサービスの概要を示す説明図である。
【
図4】
図4は、認証時に本人確認を要求する実施例の概要を示す説明図である。
【
図5】
図5は、アテステーションの仕組みの概要を示す説明図である。
【
図6】
図6は、認証強度の管理の概要の概要を示す説明図である。
【
図7】
図7は、認証強度の管理におけるFIDO登録の実施例の概要を示す説明図である。
【
図8】
図8は、アテステーションの再実施の実施例の概要を示す説明図である。
【
図9】
図9は、動的な秘密の質問作成の実施例の概要を示す説明図である。
【
図10】
図10は、子供から親へのアカウントリカバリーの権限委譲の実施例の概要を示す説明図である。
【
図11】
図11は、実施形態に係る情報処理システムの構成例を示す図である。
【
図12】
図12は、実施形態に係る端末装置の構成例を示す図である。
【
図13】
図13は、実施形態に係るサーバ装置の構成例を示す図である。
【
図14】
図14は、利用者情報データベースの一例を示す図である。
【
図15】
図15は、履歴情報データベースの一例を示す図である。
【
図16】
図16は、認証情報データベースの一例を示す図である。
【
図17】
図17は、実施形態に係る処理手順を示すフローチャートである。
【発明を実施するための形態】
【0009】
以下に、本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態(以下、「実施形態」と記載する)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【0010】
〔1.情報処理方法の概要〕
まず、
図1を参照し、実施形態に係る情報処理装置が行う情報処理方法の概要について説明する。
図1は、実施形態に係る情報処理方法の概要を示す説明図である。なお、
図1では、認証技術における認証器管理の手法をさらに向上させる場合を例に挙げて説明する。
【0011】
図1に示すように、情報処理システム1は、端末装置10とサーバ装置100とを含む。端末装置10とサーバ装置100とは、ネットワークN(
図11参照)を介して有線又は無線で互いに通信可能に接続される。本実施形態では、端末装置10は、サーバ装置100と連携する。
【0012】
端末装置10は、利用者U(ユーザ)により使用されるスマートフォンやタブレット端末等のスマートデバイスであり、4G(Generation)やLTE(Long Term Evolution)等の無線通信網を介して任意のサーバ装置と通信を行うことができる携帯端末装置である。また、端末装置10は、液晶ディスプレイ等の画面であって、タッチパネルの機能を有する画面を有し、利用者Uから指やスタイラス等によりタップ操作、スライド操作、スクロール操作等、コンテンツ等の表示データに対する各種の操作を受付ける。なお、画面のうち、コンテンツが表示されている領域上で行われた操作を、コンテンツに対する操作としてもよい。また、端末装置10は、スマートデバイスのみならず、デスクトップPC(Personal Computer)やノートPC等の情報処理装置であってもよい。
【0013】
本実施形態では、端末装置10は、FIDO認証(Fast Identity Online)におけるFIDOクライアントとして機能する。FIDOクライアントは、認証器(Authenticator)と連携してユーザの認証を行う。なお、認証器は、FIDOクライアントと同一のデバイスに実装されることがあってもよく(内蔵認証器)、FIDOクライアントとは物理的に異なるデバイスに実装されていてもよい(外部認証器)。
【0014】
例えば、FIDO認証では、PIN(Personal Identification Number)、USB(Universal Serial Bus)セキュリティキー、スマートカードなどの記憶や所有物を用いた認証方式や、指紋、顔、虹彩、静脈、声紋などの生体情報や行動情報を用いた認証方式を実装できる。認証方式は、これらに限定されず、あらゆる方式を導入することができる。また、複数の認証方式を組み合わせて、マルチモーダル生体認証や多要素認証を実現することもできる。
【0015】
以下、説明の簡略化のため、FIDOクライアントと認証器とを区別せず、端末装置10をFIDOクライアントかつ認証器として説明する。すなわち、認証器が内部認証器である場合を例に説明する。なお、実際には、認証器は、端末装置10から物理的に独立し、端末装置10と連携可能な外部認証器であってもよい。
【0016】
また、FIDOクライアントのWebブラウザに表示されるウェブコンテンツから認証器を呼び出し、認証サーバとのやり取りでFIDO認証を可能にするためのWeb認証API(Application Programming Interface)も実装可能であるが、本実施形態では説明を割愛する。
【0017】
サーバ装置100は、FIDO認証における認証サーバ(FIDOサーバ)として機能する情報処理装置であり、コンピュータやクラウドシステム等により実現される。認証サーバは、RP(Relying Party)/IdP(Identity Provider)に相当する。FIDO認証では、認証器(Authenticator)と認証サーバとの間で、パスワードや生体情報のような「秘密」を共有しないので、フィッシングに対する耐性がある。
【0018】
図1に示すように、FIDO認証では、認証サーバは、ユーザからの認証要求を受けると、ユーザ側の認証器にチャレンジ(Challenge)を送る。チャレンジは、一度だけ有効なランダムな文字列であり、乱数を元に決めた毎回異なるデータ列である。ユーザは、認証器を用いてユーザ検証(User verification)を行い、本人性の検証をローカルで実施する。そして、認証器は、検証結果を秘密鍵(Private Key)で署名し、署名付き検証結果(Signed response)として認証サーバに送る。認証サーバは、署名付き検証結果を受け取ると、公開鍵(Public Key)で署名検証する。
【0019】
このように、FIDO認証では、認証サーバが、公開鍵を用いて、ユーザ側の認証器が適切な秘密鍵を保有することを確認することによって認証を実現する。認証器と認証サーバは「秘密鍵」を共有しない。
【0020】
また、サーバ装置100は、FIDO認証に対応したRP/IdPとのID連携(フェデレーション)によりアイデンティティサービスを提供する連携RP/SP(Service Provider)としても機能する。FIDO認証とID連携とを組み合わせると、認証コンテキストは認証器からRP/IdPを介して連携RP/SPへと伝搬する。
【0021】
以下、説明の簡略化のため、RP/IdPと連携RP/SPとを区別せず、サーバ装置100をRP/IdPかつ連携RP/SPとして説明する。なお、実際には、RP/IdPとしてのサーバ装置100と、連携RP/SPとしてのサーバ装置100とは、物理的に独立した異なるサーバ装置100であってもよい。
【0022】
例えば、サーバ装置100は、各利用者Uの端末装置10と連携し、各利用者Uの端末装置10に対して、各種アプリケーション(以下、アプリ)等に対するAPI(Application Programming Interface)サービス等と、各種データを提供してもよい。
【0023】
また、サーバ装置100は、各利用者Uの端末装置10に対して、オンラインで何らかのWebサービスを提供する情報処理装置であってもよい。例えば、サーバ装置100は、Webサービスとして、インターネット接続、検索サービス、SNS(Social Networking Service)、電子商取引(EC:Electronic Commerce)、電子決済、オンラインゲーム、オンラインバンキング、オンライントレーディング、宿泊・チケット予約、動画・音楽配信、ニュース、地図、ルート検索、経路案内、路線情報、運行情報、天気予報等のサービスを提供してもよい。実際には、サーバ装置100は、上記のようなWebサービスを提供する各種サーバと連携し、Webサービスを仲介してもよいし、Webサービスの処理を担当してもよい。
【0024】
なお、サーバ装置100は、利用者Uに関する利用者情報を取得可能である。例えば、サーバ装置100は、利用者Uの性別、年代、居住地域といった利用者Uの属性に関する情報を取得する。そして、サーバ装置100は、利用者Uを示す識別情報(利用者ID等)とともに利用者Uの属性に関する情報を記憶して管理する。
【0025】
また、サーバ装置100は、利用者Uの端末装置10から、あるいは利用者ID等に基づいて各種サーバ等から、利用者Uの行動を示す各種の履歴情報(ログデータ)を取得する。例えば、サーバ装置100は、利用者Uの位置や日時の履歴である位置履歴を端末装置10から取得する。また、サーバ装置100は、利用者Uが入力した検索クエリの履歴である検索履歴を検索サーバ(検索エンジン)から取得する。また、サーバ装置100は、利用者Uが閲覧したコンテンツの履歴である閲覧履歴をコンテンツサーバから取得する。また、サーバ装置100は、利用者Uの商品購入や決済処理の履歴である購入履歴(決済履歴)を電子商取引サーバや決済処理サーバから取得する。また、サーバ装置100は、利用者Uのマーケットプレイスへの出品の履歴である出品履歴や販売履歴を電子商取引サーバや決済処理サーバから取得してもよい。また、サーバ装置100は、利用者Uの投稿の履歴である投稿履歴を口コミの投稿サービスを提供する投稿サーバやSNSサーバから取得する。なお、上記の各種サーバ等は、サーバ装置100自体であってもよい。すなわち、サーバ装置100が上記の各種サーバ等として機能してもよい。
【0026】
〔1-1.本人強度管理〕
図2に示すように、一般的な認証システムでは、本人確認(Identity proofing)により、ユーザが本人かどうかを確認する。
図2は、本人確認の事例を示す図である。本人確認では、本人があらかじめ登録した属性情報と、提示された属性情報が一致することの確認することによって、ユーザ本人とみなす。サーバ装置100は、本人確認が適切に行われていることが前提で、本人に特化したパーソナルなアイデンティティサービスを提供することができる。例えば、ユーザの自己申告の属性情報では本人強度は低いため、高い本人確度が要求されるサービスではサービスを提供できない。
【0027】
また、ユーザの個人属性情報は、本人確認の方法によって様々で信頼度にばらつきがあったり、時間の経過によって情報が陳腐化したり、実際の個人属性情報に対応して管理情報が更新されないなどの理由で信頼度が低下したりするため、従来技術では、情報の信頼性を適切に維持することが困難である。
【0028】
また、技術進歩や脆弱性の発見、社会的要請や企業方針等により、セキュリティポリシーは頻繁に変更されることがある。
【0029】
図3に示すように、本実施形態では、サーバ装置100は、本人確認(身元確認)する際の個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。
図3は、アイデンティティサービスの概要を示す説明図である。
【0030】
例えば、サーバ装置100は、個人属性情報の信頼度を適切に継続的に管理し、アイデンティティサービスを提供するアクセス制御時に、セキュリティポリシーに満たしてなければ満たすように、新たな認証や本人確認処理を発動する。
【0031】
サーバ装置100は、アイデンティティサービスを提供するアクセス制御時に、認証中のオンラインユーザに対する属性の確度を、認証確度と本人確度との掛け合わせにより求める。認証確度:p1、本人確度:p2とした場合、認証中のオンラインユーザに対する属性の確度は、下記の式(1)で表される。ここでは、一例として、両方の確率を掛け算する。
【0032】
【0033】
元々の本人確度が低ければ、IDと紐づけられた属性の信憑性がない。認証確度が弱ければ、そもそもユーザに紐づいたIDが適切ではない(なりすまし)の可能性がある。ID:id、ユーザ:u、属性:A、認証確度:p1、本人確度:p2とした場合、評価関数は、下記の式(2)で表される。ここで「*」は掛け合わせを意味し、どのような演算を定義してもよい。
【0034】
【0035】
図3に示すように、ユーザ:uとID:idとのリンクL1は、各認証試行の成功後に確立する(認証セッション)。認証セッションの有効時間をこえると、強度は0になる。このリンクL1の強度が、認証確度:p1を示す。
【0036】
属性:Aは、認証サーバが管理する。属性:Aは、属性集合(a1, a2, …an)としての強度を持つ。属性:Aは、個々の属性ごとの強度を持っていてもよいが、本人確認文書(本人確認書類)の形態に依存する。
【0037】
また、ID:idと属性:AとのリンクL2は本人確認時に確立する。強度は属性のタイプによって変化(減衰、あるいは、増加など)する。このリンクL2の強度が、本人確度:p2を示す。
【0038】
また、ID:idと認証情報:パスワードとのリンクL3も本人強度の1つと考えうるが、IDを開設した人が(あるいは管理者が)設定するので、確度は1と考えて良い。
【0039】
このように、サーバ装置100は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると0になる。本人確度は、個人属性情報のタイプによって変化する。
【0040】
〔1-1-1.アイデンティティ管理機能〕
(1)ユーザの属性の管理
認証サーバであるサーバ装置100は、ユーザの属性を管理する。例えば、サーバ装置100は、登録、更新、削除などのライフサイクル処理を実施する。
【0041】
(2)属性のメタ情報の管理
また、サーバ装置100は、ユーザの属性と紐づけて、属性のメタ情報を管理する。例えば、サーバ装置100は、ユーザの属性を入手する際の本人確認方法、本人確認書類、本人確認書類のメタ情報(発行者など)、本人確認日時等を管理する。
【0042】
(3)本人確度の管理
また、サーバ装置100は、本人確度を管理する。例えば、サーバ装置100は、上記属性とメタ情報を使って、所定の評価関数より算出し、継続的に管理する。また、サーバ装置100は、アクセス制御などの必要時をトリガーとする、あるいは、定期的に更新する。このとき、サーバ装置100は、減衰を考慮に入れた評価を実施する。また、サーバ装置100は、セキュリティポリシーを使って確度情報の管理方法を記載し、制御してもよい。例えば、サーバ装置100は、1日ごとに更新する。あるいは、サーバ装置100は、人確認書類の有効期限が期限切れしていたらアラートを投げる、あるいは、認証時に本人確認の実施要求(お願い)をする。あるいは、サーバ装置100は、1日ごとに本人確度を(本人確認書類発行日から)0.01ずつ減らす。
【0043】
〔1-1-2.認証時に本人確認要求〕
図4を参照して、認証時に本人確認を要求する実施例について説明する。
図4は、認証時に本人確認を要求する実施例の概要を示す説明図である。
【0044】
図4に示すように、ユーザである利用者Uは、端末装置10を用いて、ネットワークN(
図11参照)を介して、認証サーバであるサーバ装置100との間でIDとパスワードによる認証を行う(ステップS1)。なお、当該認証は、事前に行われていてもよい。例えば、ユーザである利用者Uは、最初に認証を受けた後、サーバ装置100へのログイン状態を維持し続けていてもよい。
【0045】
続いて、ユーザである利用者Uは、端末装置10を用いて、ネットワークN(
図11参照)を介して、認証サーバであるサーバ装置100に対してサービス要求を送信する(ステップS2)。
【0046】
続いて、認証サーバであるサーバ装置100は、ユーザである利用者Uからのサービス要求に応じて、認証確度、本人確度、及び評価関数を算出する(ステップS3)。
【0047】
続いて、認証サーバであるサーバ装置100は、アイデンティティ管理機能を有し、セキュリティポリシーを参照し、制御判断を行い、セキュリティポリシー及び制御判断に基づき、ユーザである利用者Uの本人確認要求の実施を決定する(ステップS4)。例えば、サーバ装置100は、本人確認文書:運転免許証(紙コピー)、有効期限: 2021年12月である場合、セキュリティポリシーに基づき、属性情報が有効期限切れなら本人確認を要求する。
【0048】
続いて、認証サーバであるサーバ装置100は、ネットワークN(
図11参照)を介して、認証器としての端末装置10に対して、属性情報がセキュリティポリシーを満たしていないことを示すエラーや新たな本人確認処理の要求を含むサービス応答を送信する(ステップS5)。本実施形態では、認証器としての端末装置10は、ユーザである利用者Uの端末装置10である。このとき、認証サーバであるサーバ装置100は、認証器としての端末装置10に対して、チャレンジを送信する。
【0049】
続いて、認証器としての端末装置10は、認証サーバであるサーバ装置100からのサービス応答に応じて、ユーザである利用者Uの身分証明書(運転免許証、マイナンバーカード等)に含まれる属性情報を取得する(ステップS6)。このとき、端末装置10は、ユーザである利用者Uに対して身分証明書に含まれる属性情報の入力を要求し、属性情報の入力を受け付けてもよい。属性情報の入力方法は、手入力に限らず、データのアップロード、画像データスキャン及び画像解析、音声入力等であってもよい。あるいは、端末装置10は、自身が内部に保有している属性情報を抽出してもよい。
【0050】
続いて、認証器としての端末装置10は、ネットワークN(
図11参照)を介して、認証サーバであるサーバ装置100に対して、IDと属性情報との組(セット)を含むサービス要求を送信する(ステップS7)。このとき、認証器としての端末装置10は、認証用秘密鍵を用いてサーバ装置100からのチャレンジに署名して送信する。
【0051】
続いて、認証サーバであるサーバ装置100は、認証器としての端末装置10からのサービス要求に応じて、ユーザである利用者UのIDと属性情報に基づいて、ユーザである利用者Uの本人確認文書を確認し、変更点があればデータを更新し、セキュリティポリシーとの合致を検証する(ステップS8)。このとき、認証サーバであるサーバ装置100は、認証器としての端末装置10からの署名付きチャレンジに対して、認証用公開鍵を用いて署名を検証する。
【0052】
続いて、認証サーバであるサーバ装置100は、ネットワークN(
図11参照)を介して、認証器としての端末装置10に対して、OKを示すサービス応答を送信する(ステップS9)。
【0053】
なお、本人確認の確度関数に、データの確度を時間の経過とともに減衰することを考慮にいれたものにしてもよい。
【0054】
また、リスクベース認証の考え方を導入してもよい。例えば、利用環境が普段と異なる場合には、閾値を高く設定する(そのようなセキュリティポリシーにする)。
【0055】
また、セキュリティポリシーを以下のものにしてもよい。
(1)評価関数が所定の閾値よりも低ければ、本人確認必要とする。
(2)ユーザの属性の自己申告の入力(初めての記載か更新)があれば、該当する本人確認書類を要求する。
(3)ユーザの属性の自己申告があれば、本人確認書類なしとして登録する。
【0056】
このように、本実施形態では、サーバ装置100は、ユーザ本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する。そして、サーバ装置100は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。
【0057】
このとき、サーバ装置100は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0058】
これにより、サーバ装置100は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。また、サーバ装置100は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。
【0059】
また、サーバ装置100は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。
【0060】
また、サーバ装置100は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0061】
〔1-2.認証器管理〕
本実施形態では、認証器出生証明文書(アテステーション:Attestation)を管理し、認証の方法を変えることができる認証システムを実現する。
【0062】
図5を参照して、通常(従来)のFIDO認証において、認証器出生証明文書(アテステーション)を使って、認証サーバが認証器の信頼性を判断する仕組みについて説明する。
図5は、アテステーションの仕組みの概要を示す説明図である。
【0063】
図5に示すように、アテステーション用の鍵ペア(秘密鍵、公開鍵)を認証器ベンダーが出荷時に生成・配布する。本実施形態では、認証器ベンダー等が、アテステーション用秘密鍵を出荷時に認証器に格納する。認証サーバであるサーバ装置100は、アテステーション用公開鍵を認証器ベンダー等から事前に入手する。
【0064】
また、ユーザは、認証器の登録時に、アテステーション用の鍵ペアを使って、認証用の鍵ペアを配置する。本実施形態では、認証器としての端末装置10は、認証器の登録時に認証用の鍵ペアを生成する。そして、認証器としての端末装置10は、認証用秘密鍵を登録して格納する。また、認証器としての端末装置10は、アテステーション用秘密鍵で署名したデータ(署名付きデータ)とともに/に含めて、認証用公開鍵を認証サーバであるサーバ装置100に送付する。認証サーバであるサーバ装置100は、認証器としての端末装置10から受け取った署名付きデータに対してアテステーション用公開鍵で署名検証し、成功した場合、認証器としての端末装置10から受け取った認証用公開鍵を登録して格納する。
【0065】
しかし、通常のFIDO認証において、ユーザが、アテステーションの仕組みを使ってFIDO認証器を登録する場合、その後、認証サーバのセキュリティポリシーが変わっても、認証方法を変えることができない。その理由は、ユーザの認証確度の拠り所がアテステーション文書であるからである。
【0066】
そこで、本実施形態では、認証サーバであるサーバ装置100は、FIDO登録時に受け取ったユーザのアテステーション文書を保管し、管理する。
【0067】
〔1-2-1.認証強度の管理〕
図6を参照して、認証強度の管理の概要について説明する。
図6は、認証強度の管理の概要の概要を示す説明図である。
【0068】
図6に示すように、ユーザ:uとID:idとのリンクL1は、各認証試行が成功後に確立する(認証セッション)。認証セッションの有効時間をこえると、強度は0になる。このリンクL1の強度が、認証確度:p1を示す。
【0069】
認証確度:p1は、公開鍵信頼性強度に基づく。すなわち、信頼性の低いアテステーションで公開鍵を作成したら、毎回の認証試行における認証強度は低くなる。
【0070】
なお、認証強度の管理では、ID:idと属性:AとのリンクL2は関係ない。すなわち、本人確度:p2は考慮しない。ただし、実際には、認証確度:p1と本人確度:p2を組み合わせて認証強度の管理を行うオプションはあり得る。
【0071】
また、ID:idと認証情報:公開鍵とのリンクL3’は、公開鍵信頼性強度を示す。
認証情報:公開鍵は、FIDO登録時に設定される。この信頼性を計る尺度として認証器出生証明文書(アテステーション文書)が使用される。
【0072】
認証器出生証明文書(アテステーション文書)は、公開鍵を作成した認証器・デバイスの信頼性を証明する。この内容によって公開鍵信頼性強度が決まる。
【0073】
本実施形態では、認証サーバであるサーバ装置100は、FIDO登録機能と、FIDO認証機能とに加え、認証器出生証明管理機能と、認証強度管理機能とを有する。
【0074】
〔1-2-2.FIDO登録の実施〕
図7を参照して、認証強度の管理におけるFIDO登録の実施例について説明する。
図7は、認証強度の管理におけるFIDO登録の実施例の概要を示す説明図である。
【0075】
図7に示すように、認証サーバであるサーバ装置100は、認証器としての端末装置10に対して、認証要求として、ランダム文字列であるチャレンジを送信する(ステップS11)。
【0076】
続いて、認証器としての端末装置10は、認証サーバからの認証要求に応じて、ユーザである利用者Uに対して、生体認証など所定の認証手段でユーザ検証を行う(ステップS12)。
【0077】
続いて、認証器としての端末装置10は、ユーザ検証に成功した場合、保有しているアテステーション用秘密鍵1で認証サーバからのチャレンジに署名するとともに、認証用鍵ペア(認証用秘密鍵1、認証用公開鍵1)を生成し、認証用秘密鍵1を保管する(ステップS13)。
【0078】
続いて、認証器としての端末装置10は、認証サーバであるサーバ装置100に対して、認証要求に対する認証応答として、署名付きチャレンジと、認証用公開鍵1と、アテステーション文書1とを送信する(ステップS14)。
【0079】
続いて、認証サーバであるサーバ装置100は、認証器からの認証応答に応じて、保有しているアテステーション用公開鍵1で署名付きチャレンジの署名検証を行うとともに、認証用公開鍵1を保管する(ステップS15)。
【0080】
なお、実際には、認証サーバであるサーバ装置100は、署名検証に成功した場合にのみ、認証用公開鍵1を保管するようにしてもよい。
【0081】
続いて、認証サーバであるサーバ装置100は、署名検証に成功した場合、ユーザである利用者Uを示すユーザIDを抽出する(ステップS16)。
【0082】
続いて、認証サーバであるサーバ装置100は、抽出されたユーザIDと紐づけてアテステーション文書1を保管する(ステップS17)。なお、アテステーション文書は、認証強度を評価するものの一例である。
【0083】
〔1-2-3.アテステーションの再実施〕
認証サーバであるサーバ装置100は、セキュリティ強化を決定した際に、既に保管しているユーザのアテステーション文書1では認証強度(レベル)を満たさない場合、設定した強度を満たすアテステーションを再実施する。
【0084】
例えば、現在使用している認証器Aの脆弱性が見つかったとする。そして、バグのある認証器Aからの認証要求は許可しないセキュリティポリシーに更新したとする。この場合、ユーザから認証器Aを使った認証要求を受けると、認証器Aのファームウェア更新を促すと同時に、更新した認証器Aでの再登録を促し、アテステーション文書を更新する。あるいは、新たな認証器Bでの再登録を促し、アテステーション文書を更新する。
【0085】
図8を参照して、アテステーションの再実施の実施例について説明する。
図8は、アテステーションの再実施の実施例の概要を示す説明図である。
【0086】
図8に示すように、認証サーバであるサーバ装置100は、事前に、ユーザの認証器出生証明文書(アテステーション文書)を参照し、強度不足を確認した場合、次回以降の認証の機会に再登録を促すように設定する(ステップS20)。
【0087】
そして、認証サーバであるサーバ装置100は、認証の機会に、認証器としての端末装置10に対して、認証要求として、ランダム文字列であるチャレンジを送信するとともに、ユーザの認証器出生証明文書の再登録を促す(ステップS21)。
【0088】
続いて、認証器としての端末装置10は、認証サーバからの認証要求に応じて、ユーザである利用者Uに対して、生体認証など所定の認証手段でユーザ検証を行う(ステップS22)。
【0089】
続いて、認証器としての端末装置10は、ユーザ検証に成功した場合、保有しているアテステーション用秘密鍵2で認証サーバからのチャレンジに署名する(ステップS23)。
【0090】
例えば、現在使用している認証器Aのファームウェア更新(又は認証用アプリ更新)や、新たな認証器Bの使用開始により、認証器としての端末装置10は、アテステーション用秘密鍵1とは異なるアテステーション用秘密鍵2を保管した状態となる。すなわち、認証器ベンダー等が、新たなアテステーション用の鍵ペア(秘密鍵、公開鍵)を生成・配布した状態となる。
【0091】
このとき、認証器としての端末装置10は、保有している認証用秘密鍵1を削除してもよい。これにより、上記のFIDO登録の再実施(
図8参照)が必要となる。すなわち、認証器としての端末装置10は、今回のアテステーションの再実施の後、FIDO登録を再度実施し、新たな認証用鍵ペアの生成・配布を行う。また、認証器としての端末装置10は、認証強度(レベル)を満たさないアテステーション用秘密鍵1が内部に残っている場合、アテステーション用秘密鍵1を削除してもよい。
【0092】
続いて、認証器としての端末装置10は、認証サーバであるサーバ装置100に対して、認証要求に対する認証応答として、署名付きチャレンジと、アテステーション文書2とを送信する(ステップS24)。
【0093】
続いて、認証サーバであるサーバ装置100は、認証器からの認証応答に応じて、保有しているアテステーション用公開鍵2で署名付きチャレンジの署名検証を行う(ステップS25)。
【0094】
なお、認証サーバであるサーバ装置100は、認証器としての端末装置10がアテステーション用秘密鍵2を保管した(又は取得可能となった)タイミングで、ペアとなるアテステーション用公開鍵2を取得し保管しているものとする。例えば、認証サーバであるサーバ装置100は、アテステーション用公開鍵2を認証器ベンダー等から入手して保管する。
【0095】
続いて、認証サーバであるサーバ装置100は、署名検証に成功した場合、ユーザである利用者Uを示すユーザIDを抽出する(ステップS26)。
【0096】
続いて、認証サーバであるサーバ装置100は、抽出されたユーザIDと紐づけてアテステーション文書2を保管し、認証器出生証明文書を更新する(ステップS27)。
【0097】
このとき、認証サーバであるサーバ装置100は、ユーザIDと紐づけられていたアテステーション文書1を破棄(削除)してもよい。例えば、認証サーバであるサーバ装置100は、ユーザIDと紐づけられていたアテステーション文書1を、アテステーション文書2で上書きしてもよい。
【0098】
これにより、セキュリティポリシーを変わっても、本人確認強度(レベル)を、セキュリティポリシーを満たすように柔軟に変えることができる。また、ユーザの認証処理(手順)を変えることなく、セキュリティポリシーに合わせた本人確認強度にすることができる。
【0099】
このように、本実施形態では、認証サーバであるサーバ装置100は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する。そのために、サーバ装置100は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する。
【0100】
例えば、サーバ装置100は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。あるいは、サーバ装置100は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。あるいは、サーバ装置100は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。
【0101】
また、サーバ装置100は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。サーバ装置100は、認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。このとき、サーバ装置100は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。
【0102】
例えば、サーバ装置100は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。あるいは、サーバ装置100は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。さらに、サーバ装置100は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。
【0103】
〔1-3.動的な秘密の質問作成〕
本人確認をする際の判断となる情報は事前に登録が必要で手間がかかる。また、登録がされてない限り、本人であると確認できない。
【0104】
そこで、本実施形態では、本人確認をするための「秘密の質問」(ユーザ本人固有の質問)を動的に生成する。例えば、ユーザの行動ログをもとにして、ユーザの「秘密の質問」を動的に作成する。
【0105】
図9を参照して、動的な秘密の質問作成の実施例について説明する。
図9は、動的な秘密の質問作成の実施例の概要を示す説明図である。
【0106】
図9に示すように、認証サーバであるサーバ装置100は、事前に、ユーザである利用者Uのログを分析し、質問の雛形を生成する(ステップS30)。
【0107】
ユーザである利用者Uの端末装置10は、認証サーバであるサーバ装置100に対し、ユーザである利用者Uを示すユーザIDを含むアクセス要求を行う(ステップS31)。
【0108】
続いて、認証サーバであるサーバ装置100は、ユーザである利用者Uの端末装置10からのアクセス要求に応じて、ユーザである利用者Uに対する質問・回答を生成するとともに、認証画面(質問を含む)を生成する(ステップS32)。
【0109】
続いて、認証サーバであるサーバ装置100は、認証器としての端末装置10に対して、認証要求として、質問を含む認証画面を提供(表示)する(ステップS33)。
【0110】
続いて、ユーザである利用者Uは、認証器としての端末装置10に表示された認証画面に対して、認証画面に含まれる質問への回答を入力する(ステップS34)。
【0111】
続いて、認証器としての端末装置10は、認証サーバであるサーバ装置100からの認証要求に対する認証応答として、ユーザである利用者Uにより入力された回答を送信する(ステップS35)。
【0112】
続いて、認証サーバであるサーバ装置100は、認証器としての端末装置10からの回答を検証し、認証結果に関する結果画面を生成する(ステップS36)。
【0113】
例えば、認証サーバであるサーバ装置100は、質問とともに作成した回答と、認証器としての端末装置10からの回答とを照合し、合致している場合に、成功と判断する。なお、完全一致に限らず、部分一致も可としてもよい。
【0114】
続いて、認証サーバであるサーバ装置100は、認証器としての端末装置10に対して、アクセス応答として、認証結果に関する結果画面や、要求画面を送信する(ステップS37)。
【0115】
〔1-3-1.ログ分析〕
本実施形態では、認証サーバであるサーバ装置100は、ユーザである利用者Uの行動ログの形式を特定する。
【0116】
例えば、サーバ装置100は、利用者Uの商品購入やサービス利用の履歴である購入履歴を特定する。また、サーバ装置100は、SNSへの利用者Uの投稿の履歴である投稿履歴を特定する。また、サーバ装置100は、端末装置10の決済アプリを用いた電子決済の履歴である決済履歴を特定する。
【0117】
そして、認証サーバであるサーバ装置100は、形式が特定された行動ログの中から、質問項目の特定・抽出を行う。
【0118】
例えば、サーバ装置100は、利用者Uの購入履歴から、日時、商品、価格、商品モデル/ブランド、商品の種類、購買店、複数の購買履歴からの頻度、パターン、よく買う店舗、周期等を、質問項目として特定・抽出する。
【0119】
また、サーバ装置100は、利用者UのSNSの投稿履歴から、日時、交信相手、投稿先、会話の内容等、複数の投稿からの頻度、パターン、よく会話する相手等を、質問項目として特定・抽出する。
【0120】
また、サーバ装置100は、利用者Uの決済履歴から、日時、店舗、金額、複数の取引からの頻度、パターン、よく行く店舗等を、質問項目として特定・抽出する。
【0121】
あるいは、認証サーバであるサーバ装置100は、所定のログ形式の検索ではなく、機械学習など統計的な分析手法によりデータ質問項目を特定してもよい。
【0122】
また、認証サーバであるサーバ装置100は、上記事前に選ばれた質問項目に、統計的な分析手法により特定した質問項目を追加して、次回以降に利用してもよい。
【0123】
〔1-3-2.質問作成〕
(1)質問対象ログの抽出
認証サーバであるサーバ装置100は、ユーザである利用者Uの行動ログのデータセットから、質問の対象となる1つのイベントを取り出す。例えば、サーバ装置100は、利用者Uの購入履歴から、「2022年1月14日午後3時15分、YショッピングのAAAストアから、商品BBBを1つ(価格5000円)を購入した。」というイベントを取り出す。
【0124】
(2)質問テンプレートの作成
認証サーバであるサーバ装置100は、質問対象ログから質問項目(1つ以上)を決めた質問テンプレートを作成する。例えば、サーバ装置100は、購入日時(時刻)を質問項目として決定した場合、「時刻xxxx、YショッピングのAAAストアから、パソコンBBBを1つ(価格5000円)を購入した。」という質問テンプレートを作成する。
【0125】
(3)質問項目生成ポリシーの決定
認証サーバであるサーバ装置100は、質問項目を生成する上でのポリシー(質問項目生成ポリシー)を決定する。例えば、サーバ装置100は、質問項目生成ポリシーとして、フリーテキスト、あるいは、曖昧化した時間帯にした選択式にする等のポリシーを決定する。
【0126】
(4)質問と正解の生成
認証サーバであるサーバ装置100は、質問項目生成ポリシーに従って、質問と、その回答(正解)とを生成する。例えば、サーバ装置100は、「何時ごろ、Yショッピングで電化製品を書いましたか?」という質問と、回答の選択肢として「(a)1~4時、(b)4~7時、(c)7~10時」、正解として「(a)1~4時」を生成する。
【0127】
(5)その他
なお、認証サーバであるサーバ装置100は、質問にダミーのもの(ダミー質問)を入れてもよい。例えば、サーバ装置100は、ユーザである利用者Uの行動ログに基づいておらず、利用者Uが回答できない質問(無回答が正解)を生成してもよい。この場合、全ての質問の回答の選択肢に、「正解なし」や「スキップ」を設定してもよい。また、フリーテキストでの回答入力の場合、未入力(空欄)の回答を受け付けるようにしてもよい。ダミーの作成にも様々な方法が考えられる。
【0128】
また、認証サーバであるサーバ装置100は、サービスごとではなく、複数のサービスをまたぐログを活用して質問を作成するようにしてもよい。これにより、単体の質問で攻撃されないようにセキュリティを強化できる。
【0129】
また、認証サーバであるサーバ装置100は、プライバシー対策として、匿名性(K-匿名性などの評価尺度)を加味した質問を生成してもよい。例えば、位置情報を曖昧化してもよい。
【0130】
また、認証サーバであるサーバ装置100は、質問項目を1つに限らず、2つ以上にすると好ましい。すなわち、質問項目が限定的でなければよい。
【0131】
このように、本実施形態では、サーバ装置100は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する。そして、サーバ装置100は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する。
【0132】
例えば、サーバ装置100は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。あるいは、サーバ装置100は、機械学習を用いた統計的な分析手法により質問項目を特定する。
【0133】
また、サーバ装置100は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから1以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。
【0134】
このとき、サーバ装置100は、秘密の質問とともに、ダミーの質問を生成し、秘密の質問とともに、ダミーの質問をユーザに提示するようにしてもよい。また、サーバ装置100は、正解とともに、ダミーの回答を生成し、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させるようにしてもよい。
【0135】
なお、サーバ装置100は、ユーザの複数の行動ログに基づいて1つの質問を生成するようにしてもよい。
【0136】
また、サーバ装置100は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させるようにしてもよい。
【0137】
例えば、サーバ装置100は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。このとき、サーバ装置100は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。
【0138】
あるいは、サーバ装置100は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。あるいは、サーバ装置100は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。
【0139】
このとき、サーバ装置100は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメール(注文内容確認メール、商品発送の連絡メール等)のデータを入力させるようにしてもよい。例えば、サーバ装置100は、ユーザが行った複数の購買行動に関連する各メールの内容(文面)の組合せと、あらかじめ登録された正解データとを照合することで、本人確認することが可能になる。称号は、データ自体であってもよいし、ハッシュ値であってもよい。さらに、複数の購買行動に関連する各メールの内容(文面)と、それぞれの購入日時(又はメール受信日時)とを組み合わせてもよい。
【0140】
〔1-4.本人確認判定〕
認証サーバであるサーバ装置100は、本人確認(Identity proofing)において、ユーザが本人かどうかを確認する場合、本人があらかじめ登録した属性情報と、入力された属性情報が一致することの確認することによって、ユーザ本人とみなす。なお、(当人)認証に失敗してアカウントにアクセスできなくなった時には、アカウントリカバリーを行う。
【0141】
現状のアカウントリカバリーでは、リカバリー画面において本人確認を受ける際に、本人の属性情報を始め、いくつかの質問項目を回答する形式となっている場合がある。質問項目には、住所など一般的な質問がある一方で、決済アプリ連携やメンバーカード(自社発行のクレジットカード)の保有に関する質問など特別な質問もある。また、「秘密の質問」などの本人確認方法を採用していることもある。
【0142】
しかし、従来の「秘密の質問」などの本人確認方法は、質問が固定的であるため、質問に対する正解を予想したり調べたりするなどして攻撃対象となる可能性がある。
【0143】
そこで、本実施形態では、非固定的でプライバシー保護を考慮にいれた「秘密の質問」を動的に作成し、安全に本人確認を実現する。例えば、「秘密の質問」の入力を促す画面を動的に作成する。
【0144】
本実施形態では、認証サーバであるサーバ装置100は、認証機能と、本人確認判定機能と、本人確認画面生成機能とを有する。サーバ装置100は、確認属性を一通り表示するが、毎回違うものが出たり、ダミー質問を入れたりする。
【0145】
〔1-4-1.本人確認判定ロジック〕
本実施形態では、認証サーバであるサーバ装置100は、本人確認判定ロジックとして、下記の式(3)、式(4)を用いる。
【0146】
【0147】
【0148】
ここで、重みWについて、W={w1,w2,…,wn}とし、w1+w2+…+wn=1とする。また、f_An(x)は、属性Anの判定関数であり、xの確度を返す。判定関数f(A)の値が、所定の閾値よりも大きければ本人とみなす。なお、a1,a2,…が空であってもよい。また、a1とa2が独立ではなければf(a1,a2)としてよい。また、ダミーの質問に含まれるAnに該当する重みはwn=0とする。
【0149】
本人確認のための属性入力画面が変わっても、対応する上記の判定関数を調整するだけで本人確認判定が可能、柔軟に対応できる。
【0150】
〔1-4-2.画面作成ロジック〕
本実施形態では、認証サーバであるサーバ装置100は、C:「動的な秘密の質問作成」のログ生成ロジックを使って、所定のログ形式(ショッピング、オークション等)から複数の質問テンプレートを作成する。例えば、サーバ装置100は、「Yショッピングで、何時ごろ、電化製品を書いましたか?」等の質問テンプレートを作成する。
【0151】
これにより、統一的な共通画面で、多様な属性情報を質問項目に入れ、本人確認を実現できる。また、共通の画面なので、人によって異なる属性情報が現れることにより、登録属性を推測されるなどのプライバシー漏洩を防止できる。
【0152】
なお、認証サーバであるサーバ装置100は、必ず含める静的な質問に加えて実施する付加的な質問については、積極的に質問する属性情報を変化させる。この場合も、判定関数を調整すればよい。ただし、本人確認試行(セッション)ごとに判定関数を登録する。例えば、ID、時間帯、コンテキストによって変える。あるいは、ランダムにする。また、ダミー質問を適度に入れる。
【0153】
また、認証サーバであるサーバ装置100は、画面をステップにしてもよい(multi-step proofing)。例えば、ある質問に答えられて、初めて次の所定の質問が見れるようにする。
【0154】
〔1-4-3.秘密の質問の回答としての行動ログ自体の利用〕
本実施形態では、認証サーバであるサーバ装置100は、事前に秘密の「行動履歴(文書)」を登録し、本人確認の質問に使用する。このとき、サーバ装置100は、IDと紐づけて種類と行動履歴(文書)を登録する。
【0155】
(1)登録時
サーバ装置100は、本人確認の質問に使う行動履歴(文書)を分類して種類を特定し、登録する。例えば、サーバ装置100は、行動履歴(文書)の種類を「Yショッピングでのかばんの購買」と分類して登録する。
【0156】
また、サーバ装置100は、行動履歴(文書)として、例えば「Yショッピングでの購買結果(メール)」を登録する。これ自体(購買結果のメール内容)をユーザにフリーテキストで作らせてもよい。
【0157】
(2)本人確認時
サーバ装置100は、本人確認時に、IDに紐づけられた種類とダミー種類とを入れた選択肢を作成し、リストで表示し、ユーザに選択させる。例えば、サーバ装置100は、ユーザに上記選択した「種類」に対応した「行動履歴(文書)」の入力を求める。
【0158】
なお、種類だけではなく、行動履歴(文書)についても、サーバ装置100は、本人確認時に、IDに紐づけられた行動履歴(文書)とダミー行動履歴(文書)とを入れた選択肢を作成し、リストで表示し、ユーザに選択させるようにしてもよい。
【0159】
そして、サーバ装置100は、行動履歴(文書)のハッシュ値を照合するなどして、行動履歴(文書)の真正性を確認する。例えば、サーバ装置100は、ユーザに入力(又は選択)された複数の行動履歴(文書)の内容から1つのハッシュ値を求め、あらかじめ登録されたハッシュ値(正解データ)と照合して、これらの行動履歴(文書)の真正性を確認するとともに、ユーザの本人性を確認する。
【0160】
また、サーバ装置100は、アカウントリカバリー等で本人確認をする際に、事業者が提供するPIM(Product Information Management(商品情報管理))系、メディア系、生活ツール系、金融系なども対象に質問を生成してもよい。特に、コマース、決済のユーザがARPU(Average Revenue Per User)が高いユーザであるため、アカウントリカバリーをさせる優先度が高い。
【0161】
また、サーバ装置100は、ニュースのコメントやQAサービスを利用するユーザの優先度を高めてもよい。
【0162】
また、メッセージアプリなども含め一般的なSNSのユーザは、日常生活の行動や写真などパーソナルデータを預けているので、リカバリーの優先度がやはり高い。また、メールサービス等、通信の秘密という個人情報も絡む部分でライフラインになっている各種サービスのユーザについてもリカバリーの必要性は高い。サーバ装置100は、これらのユーザの優先度を高めてもよい。
【0163】
例えば、メールやカレンダーなどのPIMサービスにおいては、メールアドレスを登録して送受信している他社サービス名や、よく受信する旅行やコマースなどのカテゴリ名、そのサービスの予約や購買など、メールチームが件名や文面の解析結果を本願実施形態で説明した技術に適用することができる。
【0164】
また、ユーザがフォローしているニュースのテーマやよく閲覧するコンテンツのカテゴリ等の解析結果を、本願実施形態で説明した技術に適用することができる。また、これら以外にも、天気、自宅の位置情報、最寄り駅、経路・乗車履歴、ナビゲーションサービスの目的地等、各種サービスの履歴の解析結果を、本願実施形態で説明した技術に適用することができる。また、証券口座情報や取り扱っている株式や投資信託、銀行口座やカード請求関連情報なども質問に活用できる。
【0165】
〔1-5.アカウントリカバリーの権限委譲〕
本実施形態では、認証サーバであるサーバ装置100は、ユーザから、そのユーザの行動に対して責任ある立場の者へアカウントリカバリーの権限委譲(権限委任)を許容してもよい。例えば、子供(認証対象者、権限委譲者)の端末装置のアカウントリカバリーを実施する際に、アカウントリカバリーの権限をその子供の親(被権限委譲者)に委譲することを許可してもよい。
【0166】
図10を参照して、子供から親へのアカウントリカバリーの権限委譲の実施例について説明する。
図10は、子供から親へのアカウントリカバリーの権限委譲の実施例の概要を示す説明図である。
【0167】
図10に示すように、子供である利用者U(U1)は、認証サーバであるサーバ装置100に対して、リカバリー協力者として、親である他の利用者U(U2)のアカウントを登録する(ステップS40)。
【0168】
例えば、子供である利用者U(U1)の端末装置10(10A)は、認証サーバであるサーバ装置100に対して、リカバリー協力者として、子供である利用者U(U1)を示す子IDとともに、親である他の利用者U(U2)を示す親IDを送信する。認証サーバであるサーバ装置100は、子供を示す子IDと、親を示す親IDとを紐づけて登録する。これにより、認証サーバであるサーバ装置100は、親である他の利用者U(U2)のFIDO認証が可能となる。
【0169】
このとき、認証サーバであるサーバ装置100は、子供である利用者U(U1)が親である他の利用者U(U2)から許可を受けたことを証明できた場合にのみ、リカバリー協力者として、親である他の利用者U(U2)のアカウントを登録できるようにしてもよい。例えば、サーバ装置100は、親である他の利用者U(U2)の端末装置10(10B)と通信し、親である他の利用者U(U2)の同意を求めてもよい。あるいは、子供である利用者U(U1)が端末装置10同士の近距離無線通信で、親である他の利用者U(U2)から許可を受けてから登録を要求するようにしてもよい。
【0170】
また、認証サーバであるサーバ装置100は、親である他の利用者U(U2)が既知のユーザ(登録済みのユーザ)である場合には、子供を示す子IDと、親を示す親IDとを紐づけて登録するだけでよいが、親である他の利用者U(U2)が未知のユーザ(未登録のユーザ)である場合には、親である他の利用者U(U2)の端末装置10(10B)に対して、登録(ユーザ登録、認証器の登録)を要求してもよい。
【0171】
続いて、子供である利用者U(U1)の端末装置10(10A)は、アカウントリカバリーが必要になった場合、認証サーバであるサーバ装置100に対して、リカバリー要求(子ID、親ID)を送信する(ステップS41)。
【0172】
例えば、子供である利用者U(U1)の端末装置10(10A)は、アカウントリカバリーが必要になった場合、子供である利用者U(U1)の操作に応じて、あるいは自動的に、認証サーバであるサーバ装置100に対して、リカバリー要求(子ID、親ID)を送信する。親IDは、アカウントリカバリーの権限の委譲先を示す。なお、認証サーバであるサーバ装置100側で、子IDと親IDとが1対1で対応付けられて保管されている場合、リカバリー要求として、子IDのみ送信するようにしてもよい。
【0173】
続いて、認証サーバであるサーバ装置100は、子供である利用者U(U1)の端末装置10からのリカバリー要求に応じて、チャレンジを生成する(ステップS42)。
【0174】
続いて、認証サーバであるサーバ装置100は、子供である利用者U(U1)の端末装置10(10A)に対して、チャレンジと親IDとを含むリカバリー許可要求を送信する(ステップS43)。
【0175】
続いて、子供である利用者U(U1)の端末装置10(10A)は、親である他の利用者U(U2)の端末装置10(10B)に対して、サーバ装置100からのリカバリー許可要求を送信(転送)する(ステップS44)。
【0176】
本実施形態では、親は子供の近くにいるものとする。例えば、子供である利用者U(U1)がBLE(Bluetooth(登録商標) Low Energy)など端末装置10同士の近距離無線通信で、親である他の利用者U(U2)に対して、サーバ装置100からのリカバリー許可要求を送信してもよい。
【0177】
続いて、親である他の利用者U(U2)の端末装置10(10B)は、FIDO認証(認証器を用いてユーザ検証)を行い、サーバ装置100からのリカバリー許可要求に対する承認として、秘密鍵を用いてチャレンジに署名する(ステップS45)。
【0178】
続いて、親である他の利用者U(U2)の端末装置10(10B)は、子供である利用者U(U1)の端末装置10(10A)に対して、リカバリー許可要求に対する応答として、署名付きチャレンジを含むリカバリー許可応答を送信する(ステップS46)。
【0179】
続いて、子供である利用者U(U1)の端末装置10(10A)は、認証サーバであるサーバ装置100に対して、親である他の利用者U(U2)の端末装置10(10B)からのリカバリー許可応答(署名付きチャレンジ)を送信(転送)する(ステップS47)。
【0180】
続いて、認証サーバであるサーバ装置100は、子供である利用者U(U1)の端末装置10(10A)からのリカバリー許可応答(署名付きチャレンジ)に応じて、公開鍵を用いて署名を検証し、リカバリー協力者を確認する(ステップS48)。
【0181】
続いて、認証サーバであるサーバ装置100は、署名の検証に成功し、親である他の利用者U(U2)がリカバリー協力者であることを確認できた場合、リカバリー制御を行う(ステップS49)。
【0182】
続いて、認証サーバであるサーバ装置100は、リカバリー要求をした子供である利用者U(U1)の端末装置10(10A)に対して、リカバリー制御に基づくリカバリー応答を送信する(ステップS50)。これにより、サーバ装置100は、子供である利用者U(U1)の端末装置10(10A)のアカウントリカバリーを実施する。
【0183】
なお、子供から親へのアカウントリカバリーの権限委譲は一例に過ぎない。実際には、企業等の従業員からその上司又はシステム管理者等へのアカウントリカバリーの権限委譲であってもよい。また、利用者Uに対して端末装置10を貸与している者へのアカウントリカバリーの権限委譲であってもよい。すなわち、認証対象者である権限委譲者から被権限委譲者へのアカウントリカバリーの権限委譲であればよい。
【0184】
また、子供である利用者U(U1)の端末装置10(10A)をFIDOクライアントとし、親である他の利用者U(U2)の端末装置10(10B)を認証器としてもよい。すなわち、FIDOクライアントを使用するユーザと、認証器によりユーザ検証されるユーザとは別人であってもよい。
【0185】
このように、本実施形態では、サーバ装置100は、認証対象者と、認証対象者が指定した被権限委譲者との情報を管理する。そして、サーバ装置100は、認証対象者からのアカウントリカバリーの要求に対して、被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する。このとき、サーバ装置100は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。
【0186】
例えば、サーバ装置100は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信する。なお、認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。その結果、サーバ装置100は、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信する。そして、サーバ装置100は、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。
【0187】
このとき、サーバ装置100は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。そして、サーバ装置100は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。
【0188】
例えば、サーバ装置100は、認証対象者である子供と、被権限委譲者である親との情報を管理する。そして、サーバ装置100は、子供からのアカウントリカバリーの要求に対して、親の承認で子供のアカウントリカバリーを実施する。このとき、サーバ装置100は、親に対してFIDO認証を実施する。
【0189】
〔2.情報処理システムの構成例〕
次に、
図11を用いて、実施形態に係るサーバ装置100が含まれる情報処理システム1の構成について説明する。
図11は、実施形態に係る情報処理システム1の構成例を示す図である。
図11に示すように、実施形態に係る情報処理システム1は、端末装置10とサーバ装置100とを含む。これらの各種装置は、ネットワークNを介して、有線又は無線により通信可能に接続される。ネットワークNは、例えば、LAN(Local Area Network)や、インターネット等のWAN(Wide Area Network)である。
【0190】
また、
図11に示す情報処理システム1に含まれる各装置の数は図示したものに限られない。例えば、
図11では、図示の簡略化のため、端末装置10を1台のみ示したが、これはあくまでも例示であって限定されるものではなく、2台以上であってもよい。
【0191】
端末装置10は、利用者Uによって使用される情報処理装置である。例えば、端末装置10は、スマートフォンやタブレット端末等のスマートデバイス、フィーチャーフォン、PC(Personal Computer)、PDA(Personal Digital Assistant)、通信機能を備えたゲーム機やAV機器、カーナビゲーションシステム、スマートウォッチやヘッドマウントディスプレイ等のウェアラブルデバイス(Wearable Device)、スマートグラス等である。
【0192】
また、かかる端末装置10は、LTE(Long Term Evolution)、4G(4th Generation)、5G(5th Generation:第5世代移動通信システム)等の無線通信網や、Bluetooth(登録商標)、無線LAN(Local Area Network)等の近距離無線通信を介してネットワークNに接続し、サーバ装置100と通信することができる。
【0193】
サーバ装置100は、例えばPCやブレードサーバ(blade server)等のコンピュータ、あるいはメインフレーム又はワークステーション等である。なお、サーバ装置100は、クラウドコンピューティングにより実現されてもよい。
【0194】
〔3.端末装置の構成例〕
次に、
図12を用いて、端末装置10の構成について説明する。
図12は、端末装置10の構成例を示す図である。
図12に示すように、端末装置10は、通信部11と、表示部12と、入力部13と、測位部14と、センサ部20と、制御部30(コントローラ)と、記憶部40とを備える。
【0195】
(通信部11)
通信部11は、ネットワークN(
図11参照)と有線又は無線で接続され、ネットワークNを介して、サーバ装置100との間で情報の送受信を行う。例えば、通信部11は、NIC(Network Interface Card)やアンテナ等によって実現される。
【0196】
(表示部12)
表示部12は、位置情報等の各種情報を表示する表示デバイスである。例えば、表示部12は、液晶ディスプレイ(LCD:Liquid Crystal Display)や有機ELディスプレイ(Organic Electro-Luminescent Display)である。また、表示部12は、タッチパネル式のディスプレイであるが、これに限定されるものではない。
【0197】
(入力部13)
入力部13は、利用者Uから各種操作を受け付ける入力デバイスである。例えば、入力部13は、文字や数字等を入力するためのボタン等を有する。なお、入力部13は、入出力ポート(I/O port)やUSB(Universal Serial Bus)ポート等であってもよい。また、表示部12がタッチパネル式のディスプレイである場合、表示部12の一部が入力部13として機能する。また、入力部13は、利用者Uから音声入力を受け付けるマイク等であってもよい。マイクはワイヤレスであってもよい。
【0198】
(測位部14)
測位部14は、GPS(Global Positioning System)の衛星から送出される信号(電波)を受信し、受信した信号に基づいて、自装置である端末装置10の現在位置を示す位置情報(例えば、緯度及び経度)を取得する。すなわち、測位部14は、端末装置10の位置を測位する。なお、GPSは、GNSS(Global Navigation Satellite System)の一例に過ぎない。
【0199】
また、測位部14は、GPS以外にも、種々の手法により位置を測位することができる。例えば、測位部14は、位置補正等のための補助的な測位手段として、下記のように、端末装置10の様々な通信機能を利用して位置を測位してもよい。
【0200】
(Wi-Fi測位)
例えば、測位部14は、端末装置10のWi-Fi(登録商標)通信機能や、各通信会社が備える通信網を利用して、端末装置10の位置を測位する。具体的には、測位部14は、Wi-Fi通信等を行い、付近の基地局やアクセスポイントとの距離を測位することにより、端末装置10の位置を測位する。
【0201】
(ビーコン測位)
また、測位部14は、端末装置10のBluetooth(登録商標)機能を利用して位置を測位してもよい。例えば、測位部14は、Bluetooth(登録商標)機能によって接続されるビーコン(beacon)発信機と接続することにより、端末装置10の位置を測位する。
【0202】
(地磁気測位)
また、測位部14は、予め測定された構造物の地磁気のパターンと、端末装置10が備える地磁気センサとに基づいて、端末装置10の位置を測位する。
【0203】
(RFID測位)
また、例えば、端末装置10が駅改札や店舗等で使用される非接触型ICカードと同等のRFID(Radio Frequency Identification)タグの機能を備えている場合、もしくはRFIDタグを読み取る機能を備えている場合、端末装置10によって決済等が行われた情報とともに、使用された位置が記録される。測位部14は、かかる情報を取得することで、端末装置10の位置を測位してもよい。また、位置は、端末装置10が備える光学式センサや、赤外線センサ等によって測位されてもよい。
【0204】
測位部14は、必要に応じて、上述した測位手段の一つ又は組合せを用いて、端末装置10の位置を測位してもよい。
【0205】
(センサ部20)
センサ部20は、端末装置10に搭載又は接続される各種のセンサを含む。なお、接続は、有線接続、無線接続を問わない。例えば、センサ類は、ウェアラブルデバイスやワイヤレスデバイス等、端末装置10以外の検知装置であってもよい。
図12に示す例では、センサ部20は、加速度センサ21と、ジャイロセンサ22と、気圧センサ23と、気温センサ24と、音センサ25と、光センサ26と、磁気センサ27と、画像センサ(カメラ)28とを備える。
【0206】
なお、上記した各センサ21~28は、あくまでも例示であって限定されるものではない。すなわち、センサ部20は、各センサ21~28のうちの一部を備える構成であってもよいし、各センサ21~28に加えてあるいは代えて、湿度センサ等その他のセンサを備えてもよい。
【0207】
加速度センサ21は、例えば、3軸加速度センサであり、端末装置10の移動方向、速度、及び、加速度等の端末装置10の物理的な動きを検知する。ジャイロセンサ22は、端末装置10の角速度等に基づいて3軸方向の傾き等の端末装置10の物理的な動きを検知する。気圧センサ23は、例えば端末装置10の周囲の気圧を検知する。
【0208】
端末装置10は、上記した加速度センサ21やジャイロセンサ22、気圧センサ23等を備えることから、これらの各センサ21~23等を利用した歩行者自律航法(PDR:Pedestrian Dead-Reckoning)等の技術を用いて端末装置10の位置を測位することが可能になる。これにより、GPS等の測位システムでは取得することが困難な屋内での位置情報を取得することが可能になる。
【0209】
例えば、加速度センサ21を利用した歩数計により、歩数や歩くスピード、歩いた距離を算出することができる。また、ジャイロセンサ22を利用して、利用者Uの進行方向や視線の方向、体の傾きを知ることができる。また、気圧センサ23で検知した気圧から、利用者Uの端末装置10が存在する高度Yロアの階数を知ることもできる。
【0210】
気温センサ24は、例えば端末装置10の周囲の気温を検知する。音センサ25は、例えば端末装置10の周囲の音を検知する。光センサ26は、端末装置10の周囲の照度を検知する。磁気センサ27は、例えば端末装置10の周囲の地磁気を検知する。画像センサ28は、端末装置10の周囲の画像を撮像する。
【0211】
上記した気圧センサ23、気温センサ24、音センサ25、光センサ26及び画像センサ28は、それぞれ気圧、気温、音、照度を検知したり、周囲の画像を撮像したりすることで、端末装置10の周囲の環境や状況等を検知することができる。また、端末装置10の周囲の環境や状況等から、端末装置10の位置情報の精度を向上させることが可能になる。
【0212】
(制御部30)
制御部30は、例えば、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM、入出力ポート等を有するマイクロコンピュータや各種の回路を含む。また、制御部30は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路等のハードウェアで構成されてもよい。制御部30は、送信部31と、受信部32と、処理部33とを有する。
【0213】
(送信部31)
送信部31は、例えば入力部13を用いて利用者Uにより入力された各種情報や、端末装置10に搭載又は接続された各センサ21~28によって検知された各種情報、測位部14によって測位された端末装置10の位置情報等を、通信部11を介してサーバ装置100へ送信することができる。
【0214】
(受信部32)
受信部32は、通信部11を介して、サーバ装置100から提供される各種情報や、サーバ装置100からの各種情報の要求を受信することができる。
【0215】
(処理部33)
処理部33は、表示部12等を含め、端末装置10全体を制御する。例えば、処理部33は、送信部31によって送信される各種情報や、受信部32によって受信されたサーバ装置100からの各種情報を表示部12へ出力して表示させることができる。
【0216】
(記憶部40)
記憶部40は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、又は、HDD(Hard Disk Drive)、SSD(Solid State Drive)、光ディスク等の記憶装置によって実現される。かかる記憶部40には、各種プログラムや各種データ等が記憶される。
【0217】
〔4.サーバ装置の構成例〕
次に、
図13を用いて、実施形態に係るサーバ装置100の構成について説明する。
図13は、実施形態に係るサーバ装置100の構成例を示す図である。
図13に示すように、サーバ装置100は、通信部110と、記憶部120と、制御部130とを備える。
【0218】
(通信部110)
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。また、通信部110は、ネットワークN(
図11参照)と有線又は無線で接続される。
【0219】
(記憶部120)
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、又は、HDD、SSD、光ディスク等の記憶装置によって実現される。
図13に示すように、記憶部120は、利用者情報データベース121と、履歴情報データベース122と、認証情報データベース123と、ポリシー情報データベース124とを有する。
【0220】
(利用者情報データベース121)
利用者情報データベース121は、利用者Uに関する利用者情報を記憶する。例えば、利用者情報データベース121は、利用者Uの属性等の種々の情報を記憶する。
図14は、利用者情報データベース121の一例を示す図である。
図14に示した例では、利用者情報データベース121は、「利用者ID(Identifier)」、「年齢」、「性別」、「自宅」、「勤務地」、「興味」といった項目を有する。
【0221】
「利用者ID」は、利用者Uを識別するための識別情報を示す。なお、「利用者ID」は、利用者Uの連絡先(電話番号、メールアドレス等)であってもよいし、利用者Uの端末装置10を識別するための識別情報であってもよい。
【0222】
また、「年齢」は、利用者IDにより識別される利用者Uの年齢を示す。なお、「年齢」は、利用者Uの具体的な年齢(例えば35歳など)を示す情報であってもよいし、利用者Uの年代(例えば30代など)を示す情報であってもよい。あるいは、「年齢」は、利用者Uの生年月日を示す情報であってもよいし、利用者Uの世代(例えば80年代生まれなど)を示す情報であってもよい。また、「性別」は、利用者IDにより識別される利用者Uの性別を示す。
【0223】
また、「自宅」は、利用者IDにより識別される利用者Uの自宅の位置情報を示す。なお、
図14に示す例では、「自宅」は、「LC11」といった抽象的な符号を図示するが、緯度経度情報等であってもよい。また、例えば、「自宅」は、地域名や住所であってもよい。
【0224】
また、「勤務地」は、利用者IDにより識別される利用者Uの勤務地(学生の場合は学校)の位置情報を示す。なお、
図14に示す例では、「勤務地」は、「LC12」といった抽象的な符号を図示するが、緯度経度情報等であってもよい。また、例えば、「勤務地」は、地域名や住所であってもよい。
【0225】
また、「興味」は、利用者IDにより識別される利用者Uの興味を示す。すなわち、「興味」は、利用者IDにより識別される利用者Uが関心の高い対象を示す。例えば、「興味」は、利用者Uが検索エンジンに入力して検索した検索クエリ(キーワード)等であってもよい。なお、
図14に示す例では、「興味」は、各利用者Uに1つずつ図示するが、複数であってもよい。
【0226】
例えば、
図14に示す例において、利用者ID「U1」により識別される利用者Uの年齢は、「20代」であり、性別は、「男性」であることを示す。また、例えば、利用者ID「U1」により識別される利用者Uは、自宅が「LC11」であることを示す。また、例えば、利用者ID「U1」により識別される利用者Uは、勤務地が「LC12」であることを示す。また、例えば、利用者ID「U1」により識別される利用者Uは、「スポーツ」に興味があることを示す。
【0227】
ここで、
図14に示す例では、「U1」、「LC11」及び「LC12」といった抽象的な値を用いて図示するが、「U1」、「LC11」及び「LC12」には、具体的な文字列や数値等の情報が記憶されるものとする。以下、他の情報に関する図においても、抽象的な値を図示する場合がある。
【0228】
なお、利用者情報データベース121は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、利用者情報データベース121は、利用者Uの端末装置10に関する各種情報を記憶してもよい。また、利用者情報データベース121は、利用者Uのデモグラフィック(人口統計学的属性)、サイコグラフィック(心理学的属性)、ジオグラフィック(地理学的属性)、ベヘイビオラル(行動学的属性)等の属性に関する情報を記憶してもよい。例えば、利用者情報データベース121は、氏名、家族構成、出身地(地元)、職業、職位、収入、資格、居住形態(戸建、マンション等)、車の有無、通学・通勤時間、通学・通勤経路、定期券区間(駅、路線等)、利用頻度の高い駅(自宅・勤務地の最寄駅以外)、習い事(場所、時間帯等)、趣味、興味、ライフスタイル等の情報を記憶してもよい。
【0229】
(履歴情報データベース122)
履歴情報データベース122は、利用者Uの行動を示す履歴情報(ログデータ)に関する各種情報を記憶する。
図15は、履歴情報データベース122の一例を示す図である。
図15に示した例では、履歴情報データベース122は、「利用者ID」、「位置履歴」、「検索履歴」、「閲覧履歴」、「購入履歴」、「投稿履歴」といった項目を有する。
【0230】
「利用者ID」は、利用者Uを識別するための識別情報を示す。また、「位置履歴」は、利用者Uの位置や移動の履歴である位置履歴を示す。また、「検索履歴」は、利用者Uが入力した検索クエリの履歴である検索履歴を示す。また、「閲覧履歴」は、利用者Uが閲覧したコンテンツの履歴である閲覧履歴を示す。また、「購入履歴」は、利用者Uによる購入の履歴である購入履歴を示す。また、「投稿履歴」は、利用者Uによる投稿の履歴である投稿履歴を示す。なお、「投稿履歴」は、利用者Uの所有物に関する質問を含んでいてもよい。
【0231】
例えば、
図15に示す例において、利用者ID「U1」により識別される利用者Uは、「位置履歴#1」の通りに移動し、「検索履歴#1」の通りに検索し、「閲覧履歴#1」の通りにコンテンツを閲覧し、「購入履歴#1」の通りに所定の店舗等で所定の商品等を購入し、「投稿履歴#1」の通りに投稿したことを示す。
【0232】
ここで、
図15に示す例では、「U1」、「位置履歴#1」、「検索履歴#1」、「閲覧履歴#1」、「購入履歴#1」及び「投稿履歴#1」といった抽象的な値を用いて図示するが、「U1」、「位置履歴#1」、「検索履歴#1」、「閲覧履歴#1」、「購入履歴#1」及び「投稿履歴#1」には、具体的な文字列や数値等の情報が記憶されるものとする。
【0233】
なお、履歴情報データベース122は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、履歴情報データベース122は、利用者Uの所定のサービスの利用履歴等を記憶してもよい。また、履歴情報データベース122は、利用者Uの実店舗の来店履歴又は施設の訪問履歴等を記憶してもよい。また、履歴情報データベース122は、利用者Uの端末装置10を用いた決済(電子決済)での決済履歴等を記憶してもよい。
【0234】
(認証情報データベース123)
認証情報データベース123は、利用者UのFIDO認証に関する各種情報を記憶する。
図16は、認証情報データベース123の一例を示す図である。
図16に示した例では、認証情報データベース123は、「利用者ID」、「認証器」、「アテステーション用公開鍵」、「認証用公開鍵」、「本人確認文書」、「有効期限」、「質問事項」、「正解」、「被権限委譲者」といった項目を有する。
【0235】
「利用者ID」は、利用者Uを識別するための識別情報を示す。また、「認証器」は、利用者Uが使用する認証器を示す。なお、「認証器」は、認証器出生証明文書(アテステーション文書)を記憶してもよい。
【0236】
また、「アテステーション用公開鍵」は、利用者Uが使用する認証器のアテステーション用公開鍵を示す。また、「認証用公開鍵」は、利用者Uが使用する認証器の認証用公開鍵を示す。
【0237】
また、「本人確認文書」は、利用者Uから提出された本人確認文書を示す。また、「有効期限」は、本人確認文書(又はその記載事項)の有効期限を示す。
【0238】
また、「質問事項」は、利用者Uの本人確認のため、動的に作成される秘密の質問を示す。なお、「質問事項」は、質問に対する回答としての選択肢を記憶してもよい。また、「正解」は、質問事項に対する正解を示す。なお、「正解」は、利用者Uに入力を要求し照合する文書又は画像データ(の組)を記憶してもよいし、その文書又は画像データ(の組)に基づくハッシュ値やデータの特徴等を記憶してもよい。
【0239】
また、「被権限委譲者」は、アカウントリカバリーの権限委譲の際に、利用者Uから権限を委譲される他のユーザを識別するための識別情報を示す。すなわち、「被権限委譲者」は、利用者Uがアカウントリカバリーの権限委譲の対象として指定・登録した他のユーザを示す。例えば、被権限委譲者は、利用者Uが子供である場合、その子供の親等である。
【0240】
例えば、
図16に示す例において、利用者ID「U1」により識別される利用者Uの認証器である「認証器#1」からの署名を検証するための公開鍵として、「アテステーション用公開鍵#1」と、「認証用公開鍵#1」とが登録されており、利用者Uの「本人確認文書#1」は「有効期限#1」を経過すると失効し、利用者Uの本人確認のための「質問事項#1」に対して「正解#1」が回答された場合にユーザ本人と認証し、利用者Uからアカウントリカバリーの要求を受けた時には、「被権限委譲者#1」に承認を求めることを示す。
【0241】
ここで、
図16に示す例では、「U1」、「認証器#1」、「アテステーション用公開鍵#1」、「認証用公開鍵#1」、「本人確認文書#1」、「有効期限#1」、「質問事項#1」、「正解#1」及び「被権限委譲者#1」といった抽象的な値を用いて図示するが、「U1」、「認証器#1」、「アテステーション用公開鍵#1」、「認証用公開鍵#1」、「本人確認文書#1」、「有効期限#1」、「質問事項#1」、「正解#1」及び「被権限委譲者#1」には、具体的な文字列や数値等の情報が記憶されるものとする。
【0242】
なお、認証情報データベース123は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、認証情報データベース123は、利用者Uの認証確度及び本人確度に関する情報等を記憶してもよい。また、認証情報データベース123は、本人確度の評価関数や属性の判定関数に関する情報等を記憶してもよい。また、認証情報データベース123は、利用者Uのパスワード等を記憶してもよい。
【0243】
(ポリシー情報データベース124)
ポリシー情報データベース124は、認証サーバであるサーバ装置100のセキュリティポリシーに関する各種情報を記憶する。セキュリティポリシーは変更可能である。
【0244】
なお、セキュリティポリシーは、アイデンティティサービスごとに設定されていてもよいし、サービスの対象となるユーザのセグメントごとに設定されていてもよい。
【0245】
(制御部130)
図13に戻り、説明を続ける。制御部130は、コントローラ(Controller)であり、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等によって、サーバ装置100の内部の記憶装置に記憶されている各種プログラム(情報処理プログラムの一例に相当)がRAM等の記憶領域を作業領域として実行されることにより実現される。
図13に示す例では、制御部130は、取得部131と、生成部132と、認証処理部133と、管理部134と、提供部135とを有する。
【0246】
(取得部131)
取得部131は、通信部110を介して、ユーザである利用者Uの端末装置10から、利用者Uにより入力されたデータを取得する。例えば、取得部131は、利用者Uの端末装置10から、利用者Uによる各種の登録情報を取得する。
【0247】
また、取得部131は、利用者Uにより入力された検索クエリを取得する。例えば、取得部131は、利用者Uが検索エンジン等に検索クエリを入力してキーワード検索を行った際に、通信部110を介して、当該検索クエリを取得する。すなわち、取得部131は、通信部110を介して、利用者Uにより検索エンジンやサイト又はアプリの検索窓に入力されたキーワードを取得する。
【0248】
また、取得部131は、通信部110を介して、利用者Uに関する利用者情報を取得する。例えば、取得部131は、利用者Uの端末装置10から、利用者Uを示す識別情報(利用者ID等)や、利用者Uの位置情報、利用者Uの属性情報等を取得する。また、取得部131は、利用者Uのユーザ登録時に、利用者Uを示す識別情報や、利用者Uの属性情報等を取得してもよい。そして、取得部131は、利用者情報を、記憶部120の利用者情報データベース121に登録する。
【0249】
また、取得部131は、通信部110を介して、利用者Uの行動を示す各種の履歴情報(ログデータ)を取得する。例えば、取得部131は、利用者Uの端末装置10から、あるいは利用者ID等に基づいて各種サーバ等から、利用者Uの行動を示す各種の履歴情報を取得する。そして、取得部131は、各種の履歴情報を、記憶部120の履歴情報データベース122に登録する。
【0250】
(生成部132)
生成部132は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する。例えば、生成部132は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。あるいは、生成部132は、機械学習を用いた統計的な分析手法により質問項目を特定する。
【0251】
また、生成部132は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから1以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。
【0252】
このとき、生成部132は、秘密の質問とともに、ダミーの質問を生成してもよい。また、生成部132は、正解とともに、ダミーの回答を生成してもよい。また、生成部132は、ユーザの複数の行動ログに基づいて1つの質問を生成してもよい。
【0253】
(認証処理部133)
認証処理部133は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する。このとき、認証処理部133は、秘密の質問とともに、ダミーの質問をユーザに提示してもよい。また、認証処理部133は、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させる。
【0254】
なお、認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させてもよい。このとき、認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメールのデータを入力させてもよい。
【0255】
例えば、認証処理部133は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。このとき、認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。
【0256】
あるいは、認証処理部133は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。あるいは、認証処理部133は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。
【0257】
また、認証処理部133は、ユーザ(利用者U)本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する。
【0258】
また、認証処理部133は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する。例えば、認証処理部133は、信頼できる認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。
【0259】
また、認証処理部133は、認証対象者(権限委譲者)からのアカウントリカバリーの要求に対して、認証対象者が指定した被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する。
【0260】
例えば、認証処理部133は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信する。なお、認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。
【0261】
そして、認証処理部133は、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信する。このとき、認証処理部133は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。
【0262】
そして、認証処理部133は、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。このとき、認証処理部133は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。
【0263】
例えば、認証処理部133は、認証対象者である子供からのアカウントリカバリーの要求に対して、被権限委譲者である親の承認で子供のアカウントリカバリーを実施する。このとき、認証処理部133は、親に対してFIDO認証を実施する。
【0264】
(管理部134)
管理部134は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する。また、管理部134は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0265】
例えば、管理部134は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。あるいは、管理部134は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。
【0266】
また、管理部134は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。
【0267】
また、管理部134は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0268】
また、管理部134は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると0になる。本人確度は、個人属性情報のタイプによって変化する。
【0269】
また、管理部134は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する。また、管理部134は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。
【0270】
例えば、管理部134は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。あるいは、管理部134は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。
【0271】
また、管理部134は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。また、管理部134は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。
【0272】
例えば、管理部134は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。また、管理部134は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。また、管理部134は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。
【0273】
また、管理部134は、他人へのアカウントリカバリーの権限委譲(例えば、子供から親へのアカウントリカバリーの権限委譲)に関して、認証対象者(権限委譲者)と、認証対象者が指定した被権限委譲者との情報を管理する。例えば、管理部134は、認証対象者である子供と、被権限委譲者である親との情報を管理する。このとき、管理部134は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。
【0274】
(提供部135)
提供部135は、通信部110を介して、FIDO認証に成功したユーザにアイデンティティサービスを提供する。すなわち、提供部135は、ユーザである利用者Uの端末装置10に対して、ユーザである利用者Uへのアイデンティティサービスを提供する。
【0275】
また、提供部135は、通信部110を介して、ユーザである利用者Uの端末装置10に対して、画面情報(入力画面等)を提供してもよい。このとき、利用者Uの端末装置10は、提供された画面情報に基づいて、入力画面等を表示する。
【0276】
また、提供部135は、通信部110を介して、ユーザである利用者Uの端末装置10に対して、FIDO認証の成否に関する情報を提供してもよい。また、提供部135は、通信部110を介して、ユーザである利用者Uの端末装置10に対して、FIDO認証に関連した各種情報を提供してもよい。
【0277】
〔5.処理手順〕
次に、
図17を用いて実施形態に係るサーバ装置100による処理手順について説明する。
図17は、実施形態に係る処理手順を示すフローチャートである。なお、以下に示す処理手順は、サーバ装置100の制御部130によって繰り返し実行される。
【0278】
図17に示すように、サーバ装置100の認証処理部133は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する(ステップS101)。
【0279】
続いて、サーバ装置100の管理部134は、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する(ステップS102)。
【0280】
続いて、サーバ装置100の管理部134は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する(ステップS103)。
【0281】
続いて、サーバ装置100の管理部134は、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する(ステップS104)。
【0282】
続いて、サーバ装置100の管理部134は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する(ステップS105)。
【0283】
続いて、サーバ装置100の生成部132は、認証に失敗してアカウントにアクセスできなくなった時には、ユーザのアカウントリカバリーを実施する前に、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する(ステップS106)。
【0284】
続いて、サーバ装置100の認証処理部133は、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する(ステップS107)。例えば、認証処理部133は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。
【0285】
続いて、サーバ装置100の管理部134は、他人へのアカウントリカバリーの権限委譲(例えば、子供から親へのアカウントリカバリーの権限委譲)に関して、認証対象者(権限委譲者)と、認証対象者が指定した被権限委譲者との情報を管理する(ステップS108)。
【0286】
続いて、サーバ装置100の認証処理部133は、認証対象者(権限委譲者)からのアカウントリカバリーの要求に対して、認証対象者が指定した被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する(ステップS109)。
【0287】
〔6.変形例〕
上述した端末装置10及びサーバ装置100は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、実施形態の変形例について説明する。
【0288】
上記の実施形態において、サーバ装置100が実行している処理の一部又は全部は、実際には、端末装置10が実行してもよい。例えば、スタンドアローン(Stand-alone)で(端末装置10単体で)処理が完結してもよい。この場合、端末装置10に、上記の実施形態におけるサーバ装置100の機能が備わっているものとする。また、上記の実施形態では、端末装置10はサーバ装置100と連携しているため、利用者Uから見れば、サーバ装置100の処理も端末装置10が実行しているように見える。すなわち、他の観点では、端末装置10は、サーバ装置100を備えているともいえる。
【0289】
また、上記の実施形態において、サーバ装置100は、FIDO認証と他の認証とを組み合わせて多段階認証としてもよい。例えば、サーバ装置100は、FIDO認証とパスワード認証とを組み合わせて2段階認証としてもよい。あるいは、サーバ装置100は、FIDO認証と秘密の質問とを組み合わせて2段階認証としてもよい。
【0290】
また、上記の実施形態において、サーバ装置100は、FIDO認証において、認証の3要素である「知識情報」、「所持情報」、「生体情報」のうち、2つ以上を組み合わせて認証するようにしてもよい。すなわち、サーバ装置100は、多要素認証(MFA:Multi-Factor Authentication)を採用してもよい。
【0291】
また、上記の実施形態において、サーバ装置100は、ユーザの行動に関連してユーザが入手した文書のデータを入力させ、入力された文書のデータを自然言語処理(文章解析)してベクトル化した値と、正解としてあらかじめ保管している値とを照合し、本人確認してもよい。すなわち、サーバ装置100は、ハッシュ値に限らず、文書のベクトル値を照合して本人確認してもよい。
【0292】
また、上記の実施形態において、サーバ装置100は、動的に秘密の質問を作成する際に、検索履歴を用いてもよい。例えば、サーバ装置100は、ユーザが入力(又は選択)した複数の検索クエリの組合せのハッシュ値と、あらかじめ登録された正解データとを照合して、本人確認してもよい。なお、ハッシュ値に限らず、検索クエリの組合せを自然言語処理(文章解析)してベクトル化した値であってもよい。
【0293】
また、上記の実施形態において、サーバ装置100は、アテステーション用公開鍵や認証用公開鍵、及び認証器出生証明文書(アテステーション文書)をブロックチェーン(BC)で管理してもよい。例えば、FIDO公開鍵を分散台帳装置が管理する。分散台帳装置は、ネットワークを構成する各ノードが同じ台帳を管理/共有することができる分散型台帳技術(DLT:Distributed Ledger Technology)に対応したサーバ装置である。分散台帳装置は、このネットワークを構成するノードの1つであってもよい。ブロックチェーンのブロックにハッシュが入るので、公開鍵が改ざんされていないかを認証できる。また、公開鍵の適切性を検証してから、認証を行うことができる。
【0294】
〔7.効果〕
上述してきたように、本願に係る情報処理装置(端末装置10及びサーバ装置100)は、ユーザ本人があらかじめ登録した個人属性情報と、ユーザにより提示された個人属性情報が一致することを確認することによって、本人確認する認証処理部133と、本人確認する際の登録済みの個人属性情報を、セキュリティポリシーを満たすように継続的に管理する管理部134と、を備える。
【0295】
管理部134は、ユーザにアイデンティティサービスを提供するアクセス制御時に、個人属性情報がセキュリティポリシーを満たしていなければ、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0296】
管理部134は、セキュリティポリシーに基づき、本人確認の方法の違いによる個人属性情報の信頼度のばらつきを抑制し、個人属性情報の信頼度を継続的に管理する。
【0297】
管理部134は、セキュリティポリシーに基づき、時間の経過による個人属性情報の信頼度の低下を抑制し、個人属性情報の信頼度を継続的に管理する。
【0298】
管理部134は、セキュリティポリシーが変更された場合、個人属性情報が変更後のセキュリティポリシーを満たすように継続的に管理する。
【0299】
管理部134は、登録済みの個人属性情報の根拠となる本人確認書類の有効期限が過ぎている場合、又は本人確認書類が失効している場合、個人属性情報がセキュリティポリシーを満たしていないと判断し、セキュリティポリシーを満たすように新たな認証及び本人確認処理を発動する。
【0300】
管理部134は、認証中のオンラインユーザに対する個人属性情報の確度を、認証確度と本人確度の掛け合わせにより求める。認証確度は、各認証試行の成功後に確立する認証セッションの有効時間を超えると0になる。本人確度は、個人属性情報のタイプによって変化する。
【0301】
また、他の観点では、本願に係る情報処理装置(端末装置10及びサーバ装置100)は、アテステーション文書に基づいて認証器の信頼性を判断し、信頼できる認証器との間でFIDO認証を実施する認証処理部133と、アテステーション文書を保管し、アテステーション文書の認証強度を継続的に管理する管理部134と、を備える。
【0302】
管理部134は、セキュリティ強化を決定した際に、既に保管しているアテステーション文書が認証強度を満たさない場合、認証強度を満たすアテステーションを再実施する。
【0303】
管理部134は、時間経過又は問題の発見により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。
【0304】
管理部134は、セキュリティポリシーの変更により、認証器がセキュリティポリシーを満たさなくなった場合、アテステーションを再実施する。
【0305】
管理部134は、アテステーション文書の内容に基づいて、公開鍵の信頼性強度を決定する。
【0306】
認証処理部133は、認証器の秘密鍵を用いた署名を、秘密鍵に対応する公開鍵で検証する。管理部134は、公開鍵の信頼性強度を管理し、公開鍵の信頼性強度が低下した場合、公開鍵の変更を要求する。
【0307】
例えば、管理部134は、時間経過により、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。
【0308】
また、管理部134は、公開鍵の有効期限が切れた場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。
【0309】
また、管理部134は、公開鍵の信頼性強度がセキュリティポリシーを満たしていない場合、公開鍵の信頼性強度が低下したと判断し、公開鍵の変更を要求する。
【0310】
また、他の観点では、本願に係る情報処理装置(端末装置10及びサーバ装置100)は、ユーザの行動ログに基づいて、本人確認をするための秘密の質問と正解とを動的に生成する生成部132と、秘密の質問に対するユーザの回答と正解とを照合し、本人確認する認証処理部133と、を備える。
【0311】
例えば、生成部132は、行動ログの形式を特定し、行動ログから質問項目の特定及び抽出を行う。
【0312】
あるいは、生成部132は、機械学習を用いた統計的な分析手法により質問項目を特定する。
【0313】
生成部132は、ユーザの複数の行動ログのうち質問対象ログを抽出し、質問対象ログから1以上の質問項目を決めた質問テンプレートを作成し、質問項目生成ポリシーを決定し、質問項目生成ポリシーに基づいて質問と正解を生成する。
【0314】
生成部132は、秘密の質問とともに、ダミーの質問を生成する。認証処理部133は、秘密の質問とともに、ダミーの質問をユーザに提示する。
【0315】
生成部132は、正解とともに、ダミーの回答を生成する。認証処理部133は、正解とともにダミーの回答を選択肢としてユーザに提示し、ユーザに選択させる。
【0316】
生成部132は、ユーザの複数の行動ログに基づいて1つの質問を生成する。
【0317】
認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの行動に関連してユーザが入手した文書又は画像のデータを入力させる。
【0318】
認証処理部133は、入力された文書又は画像のデータと、正解としてあらかじめ保管している文書又は画像のデータとを照合し、本人確認する。
【0319】
認証処理部133は、入力された文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。
【0320】
認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの複数の行動のそれぞれに関連してユーザが入手した複数の文書又は画像のデータを入力させ、複数の文書又は画像のデータに基づくハッシュ値と、正解としてあらかじめ保管しているハッシュ値とを照合し、本人確認する。
【0321】
認証処理部133は、入力された文書又は画像のデータの特徴と、正解としてあらかじめ保管している特徴とを照合し、本人確認する。
【0322】
認証処理部133は、秘密の質問に対するユーザの回答として、ユーザの購買行動に関連してユーザが入手したメールのデータを入力させる。
【0323】
また、他の観点では、本願に係る情報処理装置(端末装置10及びサーバ装置100)は、認証対象者と、認証対象者が指定した被権限委譲者との情報を管理する管理部134と、認証対象者からのアカウントリカバリーの要求に対して、被権限委譲者の承認で認証対象者のアカウントリカバリーを実施する認証処理部133と、を備える。
【0324】
管理部134は、認証対象者からリカバリー協力者として被権限委譲者のアカウントの登録を受け付け、認証対象者のアカウントと被権限委譲者のアカウントとを紐づけて管理する。
【0325】
認証処理部133は、認証対象者の端末装置からのリカバリー要求に応じて、認証対象者の端末装置を介して被権限委譲者の端末装置にチャレンジを含むリカバリー許可要求を送信し、リカバリー許可要求に対する応答として、認証対象者の端末装置を介して被権限委譲者の端末装置から署名付きチャレンジを含むリカバリー許可応答を受信し、署名の検証に成功した場合、認証対象者のアカウントリカバリーを実施する。
【0326】
認証処理部133は、被権限委譲者がリカバリー許可要求に対する承認としてチャレンジに署名して生成した署名付きチャレンジを含むリカバリー許可応答を受信する。
【0327】
認証処理部133は、署名の検証に成功した場合、被権限委譲者がリカバリー協力者であることを確認し、認証対象者のアカウントリカバリーを実施する。
【0328】
認証対象者の端末装置と被権限委譲者の端末装置との間では近距離無線通信でデータの送受信が行われる。
【0329】
管理部134は、認証対象者である子供と、被権限委譲者である親との情報を管理する。認証処理部133は、子供からのアカウントリカバリーの要求に対して、親の承認で子供のアカウントリカバリーを実施する。このとき、認証処理部133は、親に対してFIDO認証を実施する。
【0330】
上述した各処理のいずれかもしくは組合せにより、本願に係る情報処理装置は、認証技術における認証器管理の手法をさらに向上させることができる。
【0331】
〔8.ハードウェア構成〕
また、上述した実施形態に係る端末装置10やサーバ装置100は、例えば
図18に示すような構成のコンピュータ1000によって実現される。以下、サーバ装置100を例に挙げて説明する。
図18は、ハードウェア構成の一例を示す図である。コンピュータ1000は、出力装置1010、入力装置1020と接続され、演算装置1030、一次記憶装置1040、二次記憶装置1050、出力I/F(Interface)1060、入力I/F1070、ネットワークI/F1080がバス1090により接続された形態を有する。
【0332】
演算装置1030は、一次記憶装置1040や二次記憶装置1050に格納されたプログラムや入力装置1020から読み出したプログラム等に基づいて動作し、各種の処理を実行する。演算装置1030は、例えばCPU(Central Processing Unit)、MPU(Micro Processing Unit)、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等により実現される。
【0333】
一次記憶装置1040は、RAM(Random Access Memory)等、演算装置1030が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置1050は、演算装置1030が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ROM(Read Only Memory)、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ等により実現される。二次記憶装置1050は、内蔵ストレージであってもよいし、外付けストレージであってもよい。また、二次記憶装置1050は、USB(Universal Serial Bus)メモリやSD(Secure Digital)メモリカード等の取り外し可能な記憶媒体であってもよい。また、二次記憶装置1050は、クラウドストレージ(オンラインストレージ)やNAS(Network Attached Storage)、ファイルサーバ等であってもよい。
【0334】
出力I/F1060は、ディスプレイ、プロジェクタ、及びプリンタ等といった各種の情報を出力する出力装置1010に対し、出力対象となる情報を送信するためのインターフェースであり、例えば、USB(Universal Serial Bus)やDVI(Digital Visual Interface)、HDMI(登録商標)(High Definition Multimedia Interface)といった規格のコネクタにより実現される。また、入力I/F1070は、マウス、キーボード、キーパッド、ボタン、及びスキャナ等といった各種の入力装置1020から情報を受信するためのインターフェースであり、例えば、USB等により実現される。
【0335】
また、出力I/F1060及び入力I/F1070はそれぞれ出力装置1010及び入力装置1020と無線で接続してもよい。すなわち、出力装置1010及び入力装置1020は、ワイヤレス機器であってもよい。
【0336】
また、出力装置1010及び入力装置1020は、タッチパネルのように一体化していてもよい。この場合、出力I/F1060及び入力I/F1070も、入出力I/Fとして一体化していてもよい。
【0337】
なお、入力装置1020は、例えば、CD(Compact Disc)、DVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、又は半導体メモリ等から情報を読み出す装置であってもよい。
【0338】
ネットワークI/F1080は、ネットワークNを介して他の機器からデータを受信して演算装置1030へ送り、また、ネットワークNを介して演算装置1030が生成したデータを他の機器へ送信する。
【0339】
演算装置1030は、出力I/F1060や入力I/F1070を介して、出力装置1010や入力装置1020の制御を行う。例えば、演算装置1030は、入力装置1020や二次記憶装置1050からプログラムを一次記憶装置1040上にロードし、ロードしたプログラムを実行する。
【0340】
例えば、コンピュータ1000がサーバ装置100として機能する場合、コンピュータ1000の演算装置1030は、一次記憶装置1040上にロードされたプログラムを実行することにより、制御部130の機能を実現する。また、コンピュータ1000の演算装置1030は、ネットワークI/F1080を介して他の機器から取得したプログラムを一次記憶装置1040上にロードし、ロードしたプログラムを実行してもよい。また、コンピュータ1000の演算装置1030は、ネットワークI/F1080を介して他の機器と連携し、プログラムの機能やデータ等を他の機器の他のプログラムから呼び出して利用してもよい。
【0341】
〔9.その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。
【0342】
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0343】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【0344】
例えば、上述したサーバ装置100は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をAPI(Application Programming Interface)やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。
【0345】
また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【0346】
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【符号の説明】
【0347】
1 情報処理システム
10 端末装置
100 サーバ装置
110 通信部
120 記憶部
121 利用者情報データベース
122 履歴情報データベース
123 認証情報データベース
124 ポリシー情報データベース
130 制御部
131 取得部
132 生成部
133 認証処理部
134 管理部
135 提供部