JP7427533B2 - システム、及び認証装置 - Google Patents

Description

本発明は、システム、及び認証装置に関する。

近年、車両を利用する際の認証にユーザの生体情報を使用することが検討されている。例えば、下記特許文献１では、予め車両に登録された指紋と、車両を利用しようとするユーザの指紋とを照合し、一致した場合に認証成功を判定して車両の利用を許可する技術が開示されている。

特開２００８－１７４０９５号公報

しかし、上記特許文献１では、１台の車両が複数人に共用される、いわゆるカーシェアについては検討されていなかった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、利用対象を複数人が共用するユースケースにおけるセキュリティを向上させることが可能な仕組みを提供することにある。

上記課題を解決するために、本発明のある観点によれば、ユーザにより利用可能な対象である利用対象を予約する前記ユーザである第１のユーザの体に関する情報である生体情報に基づく認証であって、前記第１のユーザの正当性を認証する第１の認証を行う第１の認証部と、前記利用対象を利用する前記ユーザである第２のユーザの前記生体情報に基づく認証であって、前記第２のユーザが前記第１のユーザと同一であることを認証する第２の認証を行う第２の認証部と、を備えるシステムが提供される。

また、上記課題を解決するために、本発明の別の観点によれば、ユーザにより利用可能な対象である利用対象を予約する前記ユーザである第１のユーザの体に関する情報である生体情報に基づく認証であって、前記第１のユーザの正当性を認証する第１の認証を行い、前記利用対象を利用する前記ユーザである第２のユーザの前記生体情報に基づく認証であって、前記第２のユーザが前記第１のユーザと同一であることを認証する第２の認証を行う第２の認証部に対し前記第２の認証のための情報を提供する第１の認証部、を備える認証装置が提供される。

以上説明したように本発明によれば、利用対象を複数人が共用するユースケースにおけるセキュリティを向上させることが可能な仕組みが提供される。

本発明の一実施形態に係るシステムの構成の一例を示すブロック図である。 本実施形態に係るシステムにおいて実行される処理の流れの一例を示すシーケンス図である。 本実施形態の第１の実施例において各装置により実行される処理を示す図である。 本実施形態の第２の実施例において各装置により実行される処理を示す図である。 本実施形態の第３の実施例において各装置により実行される処理を示す図である。 本実施形態の第４の実施例において各装置により実行される処理を示す図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜１．構成例＞
図１は、本発明の一実施形態に係るシステム１の構成の一例を示すブロック図である。図１に示すように、システム１は、携帯機１００、通信ユニット２００、鍵生成センタ３００、及びサービスサーバ４００を含む。本実施形態における通信ユニット２００は、車両２０２に搭載される。車両２０２は、ユーザにより利用可能な対象である利用対象の一例である。

システム１は、カーシェアサービスを提供する。ユーザは、携帯機１００を使用して、車両２０２の利用を予約する。そして、ユーザは、予約した時刻において、予約した車両２０２を利用する。とりわけ、本実施形態に係るシステム１は、ユーザの生体情報に基づいて、予約時の認証（後述する第１の認証）及び利用時の認証（後述する第２の認証）を行う。生体情報とは、ユーザの体に関する情報である。

詳しくは、鍵生成センタ３００は、これらの認証において使用される鍵を、ユーザの生体情報に基づいて生成する。そして、サービスサーバ４００は、鍵生成センタ３００により生成された鍵を使用して、予約時の認証を行う。予約時の認証が成功すると、予約が受け付けられる。他方、通信ユニット２００は、利用時の認証を行う。利用時の認証が成功すると、車両２０２のドア錠がアンロックされたりエンジンが始動可能な状態になったりして、車両２０２はユーザにより利用可能な状態になる。

以下、各構成要素について順に説明する。

（１）携帯機１００
携帯機１００は、ユーザに携帯して使用される任意の装置として構成される。任意の装置の一例として、電子キー、スマートフォン、及びウェアラブル端末等が挙げられる。図１に示すように、携帯機１００は、無線通信部１１０、生体情報取得部１２０、入出力部１３０、記憶部１４０、及び制御部１５０を備える。

無線通信部１１０は、所定の無線通信規格に準拠した通信を行う機能を有する。例えば、無線通信部１１０は、鍵生成センタ３００、及びサービスサーバ４００の各々との間で情報をやり取りするための無線通信を行う。所定の無線通信規格の一例は、セルラー通信、Ｗｉ－Ｆｉ（登録商標）、及びＢＬＥ（Bluetooth Low Energy（登録商標））である。

生体情報取得部１２０は、ユーザの生体情報を取得する機能を有する。一例として、生体情報取得部１２０は、画像センサを含んでいてもよい。その場合、生体情報取得部１２０は、ユーザの顔画像を生体情報として取得してもよい。他の一例として、生体情報取得部１２０は、指紋センサを含んでいてもよい。その場合、生体情報取得部１２０は、ユーザの指紋を生体情報として取得してもよい。

入出力部１３０は、ユーザからの情報の入力を受け付け、ユーザに対し情報を出力する機能を有する。一例として、入出力部１３０は、ディスプレイを含んでいてもよい。その場合、入出力部１３０は、画像を出力する。他の一例として、入出力部１３０は、タッチセンサを有していてもよい。その場合、入出力部１３０は、タッチセンサへのタッチ操作を受け付ける。

記憶部１４０は、携帯機１００の動作のための各種情報を記憶する機能を有する。記憶部１４０は、例えば、フラッシュメモリ等の記憶媒体、及び記憶媒体への記録再生を実行する処理装置により構成される。

制御部１５０は、携帯機１００における処理を実行する機能を有する。例えば、制御部１５０は、無線通信部１１０を制御して他の装置との間で無線通信を行う。また、制御部１５０は、生体情報取得部１２０を制御して、ユーザの生体情報を取得する。また、制御部１５０は、入出力部１３０を制御して、ユーザから入力された情報の取得、及びユーザへの情報の出力を行う。また、制御部１５０は、記憶部１４０からの情報の読み出し及び記憶部１４０への情報の書き込みを行う。その他、制御部１５０は、各種の情報処理を行う。制御部１５０は、例えばＣＰＵ（Central Processing Unit）及びマイクロプロセッサ等の電子回路によって構成される。

（２）通信ユニット２００
通信ユニット２００は、車両２０２に対応付けて設けられる。ここでは、通信ユニット２００が、車両２０２の車室内に設置される、又は通信モジュールとして車両２０２に内蔵される等、通信ユニット２００は車両２０２に搭載されるものとする。図１に示すように、通信ユニット２００は、無線通信部２１０、生体情報取得部２２０、記憶部２３０、及び制御部２４０を備える。

無線通信部２１０は、所定の無線通信規格に準拠した通信を行う機能を有する。例えば、無線通信部２１０は、サービスサーバ４００との間で情報をやり取りするための無線通信を行う。所定の無線通信規格の一例は、セルラー通信、Ｗｉ－Ｆｉ、及びＢＬＥである。

生体情報取得部２２０は、ユーザの生体情報を取得する機能を有する。一例として、生体情報取得部２２０は、画像センサを含んでいてもよい。その場合、生体情報取得部２２０は、ユーザの顔画像を生体情報として取得してもよい。他の一例として、生体情報取得部２２０は、指紋センサを含んでいてもよい。その場合、生体情報取得部２２０は、ユーザの指紋を生体情報として取得してもよい。

記憶部２３０は、通信ユニット２００の動作のための各種情報を記憶する機能を有する。記憶部２３０は、例えば、フラッシュメモリ等の記憶媒体、及び記憶媒体への記録再生を実行する処理装置により構成される。

制御部２４０は、通信ユニット２００、及び車両２０２に搭載された車載機器の動作全般を制御する機能を有する。一例として、制御部２４０は、無線通信部２１０を制御して他の装置との間で無線通信を行う。また、制御部２４０は、生体情報取得部２２０を制御して、ユーザの生体情報を取得する。また、制御部２４０は、記憶部２３０からの情報の読み出し及び記憶部２３０への情報の書き込みを行う。また、制御部２４０は、車両２０２のドア錠を制御するドアロック制御部としても機能し、ドア錠のロック及びアンロックを行う。また、制御部２４０は、車両２０２のエンジンを制御するエンジン制御部としても機能し、エンジンの始動／停止を行う。なお、車両２０２に備えられる動力源は、エンジンの他にモータ等であってもよい。その他、制御部２４０は、各種の情報処理を行う。制御部２４０は、例えばＥＣＵ（Electronic Control Unit）として構成される。

（３）鍵生成センタ３００
鍵生成センタ３００は、例えば、インターネット上のサーバとして構成される。図１に示すように、鍵生成センタ３００は、通信部３１０、記憶部３２０、及び制御部３３０を備える。

通信部３１０は、他の装置との間で通信を行う機能を有する。例えば、通信部３１０は、携帯機１００及びサービスサーバ４００の各々との間で、インターネットを介して通信する。

記憶部３２０は、鍵生成センタ３００の動作のための各種情報を記憶する機能を有する。記憶部３２０は、例えば、ＨＤＤ（Hard Disc Drive）等の記憶媒体、及び記憶媒体への記録再生を実行する処理装置により構成される。

制御部３３０は、鍵生成センタ３００における処理を実行する機能を有する。例えば、制御部３３０は、通信部３１０を制御して他の装置との間で通信を行う。また、制御部３３０は、記憶部３２０からの情報の読み出し及び記憶部３２０への情報の書き込みを行う。その他、制御部３３０は、各種の情報処理を行う。制御部３３０は、例えばＣＰＵ（Central Processing Unit）及びマイクロプロセッサ等の電子回路によって構成される。

（４）サービスサーバ４００
サービスサーバ４００は、例えば、インターネット上のサーバとして構成される。図１に示すように、サービスサーバ４００は、通信部４１０、記憶部４２０、及び制御部４３０を備える。

通信部４１０は、他の装置との間で通信を行う機能を有する。例えば、通信部４１０は、携帯機１００、通信ユニット２００、及び鍵生成センタ３００の各々との間で、インターネットを介して通信する。

記憶部４２０は、サービスサーバ４００の動作のための各種情報を記憶する機能を有する。記憶部４２０は、例えば、ＨＤＤ（Hard Disc Drive）等の記憶媒体、及び記憶媒体への記録再生を実行する処理装置により構成される。

制御部４３０は、サービスサーバ４００における処理を実行する機能を有する。例えば、制御部４３０は、通信部４１０を制御して他の装置との間で通信を行う。また、制御部４３０は、記憶部４２０からの情報の読み出し及び記憶部４２０への情報の書き込みを行う。その他、制御部４３０は、各種の情報処理を行う。制御部４３０は、例えばＣＰＵ（Central Processing Unit）及びマイクロプロセッサ等の電子回路によって構成される。

＜２．技術的特徴＞
＜２．１．基本的特徴＞
利用対象を予約するユーザを、第１のユーザとも称する。また、利用対象を利用するユーザを、第２のユーザとも称する。特に言及しない場合、携帯機１００を使用するユーザは、第１のユーザであって第２のユーザであるものとする。

（１）登録処理
登録処理とは、ユーザが、カーシェアサービスの利用者であることをシステム１に登録する処理である。以下、登録処理において実行される各処理を説明する。

鍵生成センタ３００は、本発明における鍵生成部の一例である。即ち、鍵生成センタ３００は、ユーザの生体情報に対応する公開鍵に基づいて秘密鍵を生成する。例えば、携帯機１００は、ユーザの生体情報を取得し、取得した生体情報を鍵生成センタ３００に送信する。そして、鍵生成センタ３００は、受信した生体情報に対応する公開鍵に基づいて、秘密鍵を生成する。

公開鍵及び秘密鍵とは、暗号化及び復号に用いられる暗号鍵のペアである。公開鍵とは、広く公開される暗号鍵である。秘密鍵とは、公開先が限定される暗号鍵である。鍵生成センタ３００は、ＩＤベース署名方式の鍵生成関数を用いて、秘密鍵を発行する。ＩＤベース署名方式とは、鍵生成センタ３００が、各ユーザを識別する情報に対応した署名用の秘密鍵を発行し、各ユーザに秘密裏に配布する方式である。鍵生成関数とは、公開鍵に対応する秘密鍵を出力する関数である。本実施形態では、鍵生成センタ３００は、ユーザの生体情報に対応する秘密鍵を発行する。

鍵生成センタ３００は、発行した秘密鍵を携帯機１００に送信する。そして、携帯機１００は、受信した秘密鍵を記憶する。

サービスサーバ４００は、公開鍵を記憶する。サービスサーバ４００は、ユーザの生体情報に対応する公開鍵を、当該ユーザの識別情報に対応付けて記憶してもよい。

公開鍵は、生体情報そのものであってもよい。その場合、サービスサーバ４００は、生体情報をユーザから携帯機１００を介して受信してもよいし、鍵生成センタ３００から取得してもよい。

公開鍵は、生体情報に基づいて生成される情報であってもよい。その場合、鍵生成センタ３００は、生体情報に基づいて公開鍵を生成する。サービスサーバ４００もまた、生体情報に基づいて公開鍵を生成してもよい。他にも、サービスサーバ４００は、鍵生成センタ３００により生成された公開鍵を取得してもよい。

車両２０２を予約するユーザである第１のユーザは、登録処理を事前に実行するものとする。以下では、第１のユーザの生体情報に対応する公開鍵に基づいて生成された秘密鍵を、第１の秘密鍵とも称する。

（２）予約処理
予約処理とは、車両２０２を予約する処理である。以下、予約処理において実行される各処理について説明する。

携帯機１００は、本発明における予約部の一例である。即ち、携帯機１００は、第１のユーザによる利用対象の予約に関する情報である予約情報に、予約情報及び鍵生成センタ３００により生成された秘密鍵に基づいて生成された電子署名を対応付けてサービスサーバ４００に送信することで、第１のユーザによる利用対象の予約を行う。予約情報は、例えば、予約する第１のユーザの識別情報、予約対象の車両２０２を指定する情報、利用開始時刻を示す情報、暗号通貨による支払いを示す情報、及びその他の要望を示す情報を含む。暗号通貨とは、暗号理論に基づいて取引の安全性が確保される、仮想的な通貨である。電子署名とは、署名対象の情報に付与される情報である。電子署名を検証する主体である検証者は、電子署名を生成するために使用された秘密鍵とペアである公開鍵を用いて電子署名を検証する。検証に成功した場合、署名対象の文章が秘密鍵の所有者により作成されたものであることが証明される。他方、検証に失敗した場合、署名対象の文章が秘密鍵の所有者により作成されたものでないことが証明される。つまり、電子署名が秘密鍵に基づいて生成されることで、予約情報が利用登録済みのユーザにより生成されたことを証明することが可能となる。さらに、電子署名が、予約情報に基づいて生成されることで、予約情報が偽造又は改ざんされていないことを証明することが可能となる。以上説明したように、予約情報及び秘密鍵に基づく電子署名を予約情報に付与することで、車両２０２の予約時のセキュリティを向上させることが可能となる。

サービスサーバ４００は、本発明における第１の認証部の一例である。また、サービスサーバ４００は、本発明における認証装置の一例である。即ち、サービスサーバ４００は、第１のユーザの生体情報に基づく認証であって、第１のユーザの正当性を認証する第１の認証を行う。第１のユーザの生体情報に基づく認証とは、第１の公開鍵を使用した認証である。第１のユーザの正当性を認証するとは、車両２０２を予約する第１のユーザが、登録処理済みのユーザであることを検証することを指す。かかる構成により、登録処理済みのユーザに限定して予約が可能となるという観点で、車両２０２の予約時のセキュリティを向上させることが可能となる。

具体的には、サービスサーバ４００は、第１のユーザの生体情報に対応する公開鍵である第１の公開鍵を使用して電子署名が正しいか否かを検証する。そして、サービスサーバ４００は、電子署名が正しいと検証した場合に認証成功を判定し、電子署名が不正であると検証した場合に認証失敗を判定することを、第１の認証として行う。電子署名が第１の秘密鍵に基づいて生成されるので、サービスサーバ４００は、予約情報が利用登録済みのユーザにより生成された場合に認証成功を判定し、そうでない場合に認証失敗を判定する。また、電子署名が予約情報に基づいて生成されるので、サービスサーバ４００は、予約情報が偽造又は改ざんされていない場合に認証成功を判定し、そうでない場合に認証失敗を判定する。このように、かかる構成によれば、車両２０２の予約時のセキュリティを向上させることが可能となる。

サービスサーバ４００は、第１の認証において認証成功を判定した場合に、予約を受け付ける。例えば、サービスサーバ４００は、認証成功を判定した場合、予約情報において指定された暗号通貨による支払いを受けたことを条件に、予約情報を記憶する。

他方、サービスサーバ４００は、第１の認証において認証失敗を判定した場合に、予約を破棄する。具体的には、サービスサーバ４００は、認証失敗を判定した場合、予約情報を破棄する。

（３）利用許可処理
利用許可処理とは、車両２０２の利用を許可する処理である。以下、利用許可処理において実行される各処理について説明する。

通信ユニット２００は、本発明における第２の認証部の一例である。即ち、通信ユニット２００は、第２のユーザの生体情報に基づく認証であって、第２のユーザが第１のユーザと同一であることを認証する第２の認証を行う。そして、通信ユニット２００は、認証成功を判定した場合に、予約情報に対応する条件での車両２０２の利用を許可し、認証失敗を判定した場合に車両２０２の利用を禁止する。予約情報に対応する条件での車両２０２の利用を許可するとは、例えば、予約情報において指定された利用開始時時刻から、暗号通貨による支払額に応じた期間、予約情報において指定された車両２０２において、ドアロックの解錠、及びエンジン始動が可能にすることを指す。車両２０２の利用を禁止するとは、例えば、ドアロックの解錠、及びエンジン始動を不可能にすることを指す。かかる構成により、予約した第１のユーザと異なる第三者により車両２０２が誤って利用されることを防止することができる、という観点で、車両２０２の利用時のセキュリティを向上させることが可能となる。

具体的には、通信ユニット２００は、第１の認証に成功した第１のユーザの生体情報に対応する公開鍵である第１の公開鍵と、第２のユーザの生体情報に対応する公開鍵である第２の公開鍵とが、対応するか否かを判定し、対応する場合に認証成功を判定し、対応しない場合に認証失敗を判定することを、前記第２の認証として行う。例えば、通信ユニット２００は、第２の生体情報を取得し、取得した第２の生体情報に対応する第２の公開鍵に基づいて第２の認証を行う。第１の公開鍵と第２の公開鍵とが対応することの一例は、第１の公開鍵と第２の公開鍵とが一致することである。第１の公開鍵と第２の公開鍵とが対応することの一例は、第１の公開鍵に基づいて生成された情報と第２の公開鍵に基づいて生成された情報とが一致することである。かかる構成によれば、第２のユーザの生体情報に基づいて第２の認証が行われるので、ユーザは携帯機１００を携帯せずとも、また携帯している場合であっても専用のアプリケーションを立ち上げる等の操作を行わずとも、車両２０２を利用することが可能となる。その上、ユーザが仮に携帯機１００を紛失した場合であっても、携帯機１００を不正に取得した第三者によりユーザが予約した車両２０２が利用されることを防止することも可能となる。

サービスサーバ４００は、通信ユニット２００に対し、第２の認証のための情報を提供する。第２の認証のための情報の一例は、予約情報、及び第１の公開鍵である。

（４）処理の流れ
図２は、本実施形態に係るシステム１において実行される処理の流れの一例を示すシーケンス図である。本シーケンスには、携帯機１００、通信ユニット２００、鍵生成センタ３００及びサービスサーバ４００が関与する。

図２に示すように、まず、システム１は、登録処理を実行する。以下、登録処理に含まれる処理の流れを説明する。

まず、携帯機１００の生体情報取得部１２０は、ユーザの生体情報を取得する。そして、携帯機１００の無線通信部１１０は、取得した生体情報を鍵生成センタ３００に送信する（ステップＳ１０２）。

鍵生成センタ３００の制御部３３０は、通信部３１０により生体情報が受信されると、生体情報に対応する公開鍵に基づいて秘密鍵を生成する（ステップＳ１０４）。

次に、鍵生成センタ３００の通信部３１０は、生成された秘密鍵を携帯機１００に送信する（ステップＳ１０６）。そして、携帯機１００の制御部１５０は、無線通信部１１０により秘密鍵が受信されると、受信された秘密鍵を記憶部１４０に記憶する（ステップＳ１０８）。

他方、サービスサーバ４００の制御部４３０は、ユーザの生体情報に対応する公開鍵を記憶部４２０に記憶する（ステップＳ１１０）。なお、サービスサーバ４００は、携帯機１００からユーザの生体情報を受信し、受信した生体情報に対応する公開鍵を記憶してもよい。他に、サービスサーバ４００は、鍵生成センタ３００からユーザの生体情報に対応する公開鍵を受信して記憶してもよい。

図２に示すように、続いて、システム１は、予約処理を実行する。以下、予約処理に含まれる処理の流れを説明する。

まず、携帯機１００の入出力部１３０は、ユーザ（第１のユーザに相当）による予約情報の入力を受け付ける。次いで、携帯機１００の制御部１５０は、ユーザにより入力された予約情報、及び登録処理において記憶した秘密鍵に基づいて、電子署名を生成する。そして、携帯機１００の無線通信部１１０は、予約情報に、生成した電子署名を対応付けてサービスサーバ４００に送信する（ステップＳ１１２）。

サービスサーバ４００の制御部４３０は、通信部４１０により予約情報及び電子署名が受信されると、第１の認証及び予約の受け付けを行う（ステップＳ１１４）。詳しくは、まず、サービスサーバ４００の制御部４３０は、登録処理において記憶した公開鍵に基づいて電子署名を検証する。そして、サービスサーバ４００の制御部４３０は、検証に成功した場合に認証成功を判定し、予約情報を記憶部４２０に記憶する。他方、サービスサーバ４００の制御部４３０は、検証に失敗した場合に認証失敗を判定し、予約情報を破棄する。

図２に示すように、続いて、システム１は、利用許可処理を実行する。以下、利用許可処理に含まれる処理の流れを説明する。

まず、通信ユニット２００の生体情報取得部２２０は、ユーザ（第２のユーザに相当）の生体情報を取得する（ステップＳ１１６）。例えば、ユーザは、予約した車両２０２に近づいて、通信ユニット２００に生体情報を入力する。

次いで、通信ユニット２００の無線通信部２１０は、現在時刻に対応する予約がなされているかをサービスサーバ４００に対し問い合わせ、第２の認証のための情報を取得する（ステップＳ１１８）。現在時刻に対応する予約とは、予約情報において指定された利用開始時刻から所定範囲内に現在時刻が含まれる予約である。第２の認証のための情報の一例は、現在時刻に対応する予約を行った第１のユーザの公開鍵である。

次に、通信ユニット２００の制御部２４０は、第２の認証、及び車両２０２の利用許可を行う（ステップＳ１２０）。詳しくは、通信ユニット２００の制御部２４０は、第１の公開鍵と、第２のユーザの生体情報に対応する第２の公開鍵とが対応するか否かを判定する。そして、通信ユニット２００の制御部２４０は、第１の公開鍵と第２の公開鍵とが対応する場合に、認証成功を判定し、車両２０２の利用を許可する。他方、通信ユニット２００の制御部２４０は、第１の公開鍵と第２の公開鍵とが対応しない場合に、認証失敗を判定し、車両２０２の利用を禁止する。

以上、システム１において実行される処理の流れの一例を説明した。本実施形態に係るシステム１の種々の実施例について、以下に説明する。

＜２．２．第１の実施例＞
第１の実施例では、ユーザの生体情報が公開鍵である。とりわけ、第１の公開鍵は、第１のユーザの生体情報である。また、第２の公開鍵は、第２のユーザの生体情報である。そして、生体情報の特徴量に基づいて秘密鍵が生成される。

図３は、本実施形態の第１の実施例において各装置により実行される処理を示す図である。以下、図３を参照しながら第１の実施例について説明する。

登録処理において、図３に示すように、鍵生成センタ３００は、ユーザの生体情報から抽出された特徴量に基づいて秘密鍵を生成する。詳しくは、まず、携帯機１００は、生体情報取得部１２０により取得したユーザの生体情報を鍵生成センタ３００に送信する。次いで、鍵生成センタ３００は、ユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。特徴量抽出関数とは、入力された情報の特徴量を出力する関数である。特徴量とは、特徴を示す情報である。そして、鍵生成センタ３００は、抽出された特徴量を鍵生成関数に入力することで、秘密鍵を生成する。鍵生成関数とは、入力された情報に応じた秘密鍵を出力する関数である。生体情報は同一人物から取得される場合であってもゆらぎが生じ得るところ、かかる構成によれば、生体情報の特徴量に基づいて秘密鍵が生成されるので、当該ゆらぎに起因する認証失敗を防止することが可能となる。そして、鍵生成センタ３００は、生成した秘密鍵を携帯機１００に送信する。

予約処理において、図３に示すように、サービスサーバ４００は、第１のユーザの生体情報から抽出された特徴量に基づいて電子署名が正しいか否かを検証することを、第１の認証として行う。詳しくは、サービスサーバ４００は、登録処理において記憶した第１の公開鍵である第１のユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、サービスサーバ４００は、予約情報、電子署名、及び第１のユーザの生体情報から抽出された特徴量を検証用関数に入力することで、認証成否を判定する。検証用関数とは、入力された予約情報が偽造又は改ざんされておらず、且つ、電子署名の検証のために入力された公開鍵（本実施例では、生体情報の特徴量）が電子署名の生成に使用された秘密鍵に対応する場合に、検証成功を出力し、そうでない場合に検証失敗を判定する関数である。生体情報は同一人物から取得される場合であってもゆらぎが生じ得るところ、かかる構成によれば、生体情報の特徴量に基づいて電子署名が検証されるので、当該ゆらぎに起因する認証失敗を防止することが可能となる。なお、サービスサーバ４００は、第１の公開鍵である第１のユーザの生体情報を、後の利用許可処理において通信ユニット２００に送信する。

利用許可処理において、図３に示すように、通信ユニット２００は、第１のユーザの生体情報から抽出された特徴量と、第２のユーザの生体情報から抽出された特徴量とが、一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、第２の認証として行う。詳しくは、通信ユニット２００は、サービスサーバ４００から取得した第１のユーザの生体情報（第１の公開鍵に相当）を特徴量抽出関数に入力することで、特徴量を抽出する。また、通信ユニット２００は、生体情報取得部２２０により取得した第２のユーザの生体情報（第２の公開鍵に相当）を特徴量抽出関数に入力することで、特徴量を抽出する。そして、通信ユニット２００は、抽出したこれらの特徴量が一致するか否かにより、認証成否を判定する。生体情報は同一人物から取得される場合であってもゆらぎが生じ得るところ、かかる構成によれば、生体情報の特徴量の一致／不一致により認証成否が判定されるので、当該ゆらぎに起因する認証失敗を防止することが可能となる。

＜２．３．第２の実施例＞
第２の実施例では、ユーザの生体情報に基づいて公開鍵が生成される。

図４は、本実施形態の第２の実施例において各装置により実行される処理を示す図である。以下、図４を参照しながら第２の実施例について説明する。

登録処理において、図４に示すように、鍵生成センタ３００は、ユーザの生体情報に基づいて公開鍵を生成する。詳しくは、まず、鍵生成センタ３００は、ユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、鍵生成センタ３００は、ユーザの生体情報から抽出された特徴量をハッシュ関数に入力することで得られたハッシュ値を、公開鍵として生成する。そして、鍵生成センタ３００は、生成した公開鍵としてのハッシュ値をサービスサーバ４００に送信する。なお、ハッシュ関数とは、入力された情報に応じて、入力された情報とは別の情報を出力する関数である。典型的には、ハッシュ関数は、入力された情報のビット長よりも短いビット長の情報を出力する。ハッシュ値とは、ハッシュ関数から出力される情報である。ハッシュ関数としては、ＳＨＡ－２５６等の、逆計算が困難な関数が採用されることが望ましい。逆計算とは、出力された情報から入力された情報を計算することである。かかる構成によれば、ハッシュ値が公開鍵となるので、生体情報そのものが公開鍵として広く公開されることを防止し、生体情報を秘匿することが可能となる。

また、鍵生成センタ３００は、ハッシュ値を鍵生成関数に入力することで、秘密鍵を生成する。そして、鍵生成センタ３００は、生成した秘密鍵を携帯機１００に送信する。

予約処理において、図４に示すように、サービスサーバ４００は、鍵生成センタ３００により生成された第１の公開鍵を使用して電子署名が正しいか否かを検証することを、第１の認証として行う。詳しくは、サービスサーバ４００は、予約情報、電子署名、及び登録処理において鍵生成センタ３００から取得した第１の公開鍵である第１のユーザの生体情報の特徴量のハッシュ値を検証用関数に入力することで、認証成否を判定する。かかる構成によれば、ハッシュ値を公開鍵として電子署名が検証されるので、生体情報そのものが公開鍵として広く公開されることを防止し、生体情報を秘匿することが可能となる。なお、サービスサーバ４００は、第１の公開鍵である第１のユーザの生体情報のハッシュ値を、後の利用許可処理において通信ユニット２００に送信する。

利用許可処理において、図４に示すように、通信ユニット２００は、鍵生成センタ３００により生成された第１の公開鍵と、第２のユーザの生体情報から抽出された特徴量をハッシュ関数に入力することで得られたハッシュ値である第２の公開鍵とが、一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、第２の認証として行う。詳しくは、まず、通信ユニット２００は、生体情報取得部２２０により取得した第２のユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、通信ユニット２００は、第２のユーザの生体情報から抽出された特徴量をハッシュ関数に入力することで得られたハッシュ値を、第２の公開鍵として生成する。そして、通信ユニット２００は、サービスサーバ４００から取得した第１の公開鍵であるハッシュ値と、生成した第２の公開鍵であるハッシュ値とが、一致するか否かにより、認証成否を判定する。かかる構成によれば、ハッシュ値を公開鍵として認証成否が判定されるので、生体情報そのものが公開鍵として広く公開されることを防止し、生体情報を秘匿することが可能となる。

＜２．４．第３の実施例＞
第３の実施例では、ユーザの生体情報に基づいて公開鍵が生成される。とりわけ、第３の実施例では、公開鍵の生成の際に、生体情報のゆらぎが補正される。

図５は、本実施形態の第３の実施例において各装置により実行される処理を示す図である。以下、図５を参照しながら第３の実施例について説明する。

登録処理において、図５に示すように、鍵生成センタ３００は、特徴量の抽出、公開鍵としてのハッシュ値の生成及びサービスサーバ４００への送信、並びに秘密鍵の生成及び携帯機１００への送信を行う。これらの処理は、図４を参照しながら説明した第２の実施例における処理と同様である。

本実施例においては、さらに、鍵生成センタ３００は、ユーザの生体情報から抽出された特徴量に基づいて、誤り訂正用補助データを生成する。誤り訂正用補助データとは、生体情報のゆらぎを訂正するための情報である。誤り訂正用補助データは、一例として、ファジーエクストラクタ（Fuzzy extractor）により生成されてもよい。ファジーエクストラクタによれば、類似する入力から同一の出力を得ることができる。つまり、同一のユーザから取得されたものの、ゆらぎにより厳密には異なる複数の生体情報から、同一の出力を得ることができる。鍵生成センタ３００は、生成した誤り訂正用補助データを、サービスサーバ４００に送信する。

なお、ファジーエクストラクタに関する詳細な技術は、例えば非特許文献「Yevgeniy Dodis, Rafail Ostrovsky, Leonid Reyzin, and Adam Smith. Fuzzy extractors: How to generate strong keys from biometrics and other noisy data. SIAM Journal on Computing, 38(1):97-139, 2008.」に開示されている。本非特許文献では、ノイズの多い情報を暗号化アプリケーションで使用可能な鍵情報に変換するための技術が開示されている。特に、ファジーエクストラクタが、入力された入力情報に対しランダムな出力情報を出力する特性、及び互いに異なるものの近しい入力情報が入力された場合に同一の出力情報を出力する特性を有することを指摘している。そして、これらの特性から、ファジーエクストラクタに生体情報を入力することで得られた出力情報を、鍵情報として安全に使用可能であることが指摘されている。

予約処理において、図５に示すように、サービスサーバ４００は、予約情報、電子署名、及び登録処理において鍵生成センタ３００から取得した第１の公開鍵であるハッシュ値を検証用関数に入力することで、認証成否を判定する。また、サービスサーバ４００は、第１の公開鍵である第１のユーザの生体情報のハッシュ値を、後の利用許可処理において通信ユニット２００に送信する。これらの処理は、図４を参照しながら説明した第２の実施例における処理と同様である。

本実施例においては、さらに、サービスサーバ４００は、鍵生成センタ３００から取得した誤り訂正用補助データを、後の利用許可処理において通信ユニット２００に送信する。

利用許可処理において、図５に示すように、通信ユニット２００は、鍵生成センタ３００により生成された誤り訂正用補助データに基づいて第２のユーザの生体情報から抽出された特徴量を訂正する。詳しくは、まず、通信ユニット２００は、生体情報取得部２２０により取得した第２のユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、通信ユニット２００は、第２のユーザの生体情報から抽出された特徴量、及びサービスサーバ４００から取得した誤り訂正用補助データを、誤り訂正関数に入力することで、誤り訂正後の特徴量を生成する。誤り訂正関数とは、誤り訂正対象の情報を、誤り訂正用補助データに従って訂正する関数である。

そして、通信ユニット２００は、訂正後の特徴量をハッシュ関数に入力することで得られたハッシュ値を第２の公開鍵として使用して、第１の公開鍵と前記第２の公開鍵とが一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、前記第２の認証として行う。詳しくは、通信ユニット２００は、誤り訂正後の特徴量をハッシュ関数に入力することで得られたハッシュ値を、第２の公開鍵として生成する。そして、通信ユニット２００は、サービスサーバ４００から取得した第１の公開鍵であるハッシュ値と、第２の公開鍵としてのハッシュ値とが、一致するか否かにより、認証成否を判定する。

以上、本実施例について説明した。本実施例によれば、誤り訂正用補助データにより、生体情報のゆらぎに起因する認証失敗をより防止することが可能となる。

＜２．５．第４の実施例＞
第４の実施例では、ユーザの生体情報に基づいて公開鍵が生成される。とりわけ、第４の実施例では、更新可能な公開鍵が生成される。また、第４の実施例では、第３の実施例と同様に、生体情報のゆらぎを補正するための、誤り訂正用補助データを用いた誤り訂正が行われる。

図６は、本実施形態の第４の実施例において各装置により実行される処理を示す図である。以下、図６を参照しながら第４の実施例について説明する。

登録処理において、図６に示すように、鍵生成センタ３００は、第１のユーザの生体情報から抽出された特徴量、及び鍵更新用補助データを、ハッシュ関数に入力することで得られたハッシュ値を、第１の公開鍵として生成する。鍵更新用補助データとは、公開鍵を新たに生成する度に変化する情報である。鍵更新用補助データの一例は、乱数である。詳しくは、まず、鍵生成センタ３００は、ユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、鍵生成センタ３００は、ユーザの生体情報から抽出された特徴量、及び鍵更新用補助データをハッシュ関数に入力することで得られたハッシュ値を、公開鍵として生成する。例えば、鍵生成センタ３００は、特徴量に鍵更新用補助データを連結したものをハッシュ関数に入力することで、公開鍵としてのハッシュ値を生成する。そして、鍵生成センタ３００は、生成した公開鍵としてのハッシュ値をサービスサーバ４００に送信する。

また、鍵生成センタ３００は、公開鍵の生成に用いた鍵更新用補助データを、サービスサーバ４００に送信する。

また、鍵生成センタ３００は、ハッシュ値を鍵生成関数に入力することで、秘密鍵を生成する。そして、鍵生成センタ３００は、生成した秘密鍵を携帯機１００に送信する。

また、鍵生成センタ３００は、ユーザの生体情報から抽出された特徴量に基づいて、誤り訂正用補助データを生成する。そして、鍵生成センタ３００は、生成した誤り訂正用補助データを、サービスサーバ４００に送信する。

予約処理において、図５に示すように、サービスサーバ４００は、予約情報、電子署名、及び登録処理において鍵生成センタ３００から取得した第１の公開鍵であるハッシュ値を検証用関数に入力することで、認証成否を判定する。また、サービスサーバ４００は、第１の公開鍵である第１のユーザの生体情報のハッシュ値、及び鍵生成センタ３００から取得した誤り訂正用補助データを、後の利用許可処理において通信ユニット２００に送信する。これらの処理は、図５を参照しながら説明した第３の実施例における処理と同様である。

本実施例においては、さらに、サービスサーバ４００は、鍵生成センタ３００から取得した鍵更新用補助データを、後の利用許可処理において通信ユニット２００に送信する。

利用許可処理において、図６に示すように、通信ユニット２００は、第２のユーザの生体情報から抽出された特徴量、及び鍵更新用補助データを、ハッシュ関数に入力することで得られたハッシュ値を第２の公開鍵として使用して、第１の公開鍵と第２の公開鍵とが一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、第２の認証として行う。詳しくは、まず、通信ユニット２００は、生体情報取得部２２０により取得した第２のユーザの生体情報を特徴量抽出関数に入力することで、特徴量を抽出する。次いで、通信ユニット２００は、第２のユーザの生体情報から抽出された特徴量、及びサービスサーバ４００から取得した誤り訂正用補助データを、誤り訂正関数に入力することで、誤り訂正後の特徴量を生成する。次に、通信ユニット２００は、訂正後の特徴量、及びサービスサーバ４００から取得した鍵更新用補助データを、ハッシュ関数に入力することで得られたハッシュ値を、第２の公開鍵として生成する。そして、通信ユニット２００は、サービスサーバ４００から取得した第１の公開鍵であるハッシュ値と、第２の公開鍵としてのハッシュ値とが、一致するか否かにより、認証成否を判定する。

秘密鍵が携帯機１００以外の第三者に漏洩した場合、第三者がユーザに成りすまして、即ち漏洩した秘密鍵を使用して車両２０２の予約を行うおそれがある。

そこで、秘密鍵の漏洩が疑われる場合、鍵生成センタ３００は、公開鍵、及び秘密鍵を更新する。詳しくは、鍵生成センタ３００は、過去に秘密鍵を生成するために使用した鍵更新用補助データとは異なる鍵更新用補助データを用いて、公開鍵としてのハッシュ値を新たに生成する。そして、鍵生成センタ３００は、新たに生成した公開鍵としてのハッシュ値に基づいて、秘密鍵を新たに生成する。

鍵生成センタ３００は、秘密鍵を新たに生成した場合、新たに生成した秘密鍵を携帯機１００に送信する。携帯機１００は、予約処理においては、新たに生成された秘密鍵を使用して電子署名を生成する。他方、鍵生成センタ３００は、公開鍵を新たに生成した場合、新たに生成した公開鍵に対し有効であることを示す情報を対応付け、過去に生成した公開鍵に対し無効であることを示す情報を対応付ける。当該対応付けられた情報は、サービスサーバ４００に対し公開（即ち、送信）される。そして、第１のユーザによる予約処理の際には、サービスサーバ４００は、有効であることを示す情報が対応付けられた第１の公開鍵を使用して、第１の認証を行う、その際、サービスサーバ４００は、有効であることを示す情報が対応付けられた、即ち新たに生成された秘密鍵に基づいて生成された電子署名については、認証成功を判定する。他方、サービスサーバ４００は、無効であることを示す情報が対応付けられた、即ち過去に生成された秘密鍵に基づいて生成された電子署名については、認証失敗を判定する。従って、無効な秘密鍵を使用して行われた予約を、高い信頼性で排除することが可能となる。即ち、過去に生成された秘密鍵を不正に取得した第三者がユーザに成りすますことを防止することが可能となる。

鍵生成センタ３００は、公開鍵を新たに生成した場合、新たに生成した公開鍵及び過去に生成した公開鍵の各々に対し、有効期間を示す情報を対応付けてもよい。公開鍵の有効期間の始期の一例は、当該公開鍵が生成された時刻である。公開鍵の有効期間の終期の一例は、当該公開鍵の漏洩が疑われる時刻である。当該対応付けられた情報は、サービスサーバ４００に対し公開（即ち、送信）される。

他方、サービスサーバ４００は、予約情報に対応付けられた時刻を有効期間に含まない第１の公開鍵を使用して行われた第１の認証について、認証失敗を判定する。そして、サービスサーバ４００は、認証失敗が判定された予約を破棄する。換言すると、サービスサーバ４００は、予約情報に対応付けられた時刻を有効期間に含む第１の公開鍵を使用して行われた第１の認証について、認証成功を維持する。予約情報に対応付けられた時刻の一例は、予約情報及び電子署名を受信した時刻である。かかる時刻を、以下では予約申し込み時刻とも称する。かかる構成によれば、漏洩が疑われた後のタイミングで申し込まれた予約を無効にしつつ、漏洩が疑われる前のタイミングで申し込まれた予約を有効のままにすることができる。従って、セキュリティを向上させつつ、鍵の無効化に伴う再予約の手間を不要にすることが可能となる。

ここで、第１の認証部は、ブロックチェーンにより構成されてもよい。ブロックチェーンとは、ブロックと呼ばれる単位のデータを生成し、ブロック間をリンク付けすることによりデータを管理する技術である。新たに生成されたブロックは、前回生成されたブロックに連結される。そのため、ブロックは、順序付けされながら増加していくこととなる。ブロックチェーンは、過去のデータの変更履歴をすべて記録し、公開する技術として、仮想通貨等の様々な技術に使用されている。ブロックチェーンにおいて、ブロックに含まれるデータに対し各種判断を行う主体は、スマートコントラクトとも称される。

鍵生成センタ３００は、生成した公開鍵をブロックチェーンにおけるブロックに書き込んでもよい。そして、第１の認証部としてのスマートコントラクトは、ブロックに書き込まれた公開鍵を使用して、第１の認証を行う。かかる構成によれば、公開鍵の公開及び公開鍵を使用した第１の認証を、より容易に実装することが可能となる。

とりわけ、第１の認証部としてのスマートコントラクトは、公開鍵がブロックに書き込まれた時刻に基づいて当該公開鍵の有効期間を認識してもよい。鍵生成センタ３００は、あるユーザの秘密鍵に漏洩が疑われる場合、公開鍵及び秘密鍵を再度発行し、新たに発行した公開鍵を前回発行した公開鍵に書き込まれたブロックの次のブロックに書き込む。よって、ある公開鍵の有効期間は、当該公開鍵がブロックに書き込まれた時刻から、次回発行された公開鍵が次のブロックに書き込まれた時刻までとなる。そして、スマートコントラクトは、予約申し込み時刻を有効期間に含まない第１の公開鍵を使用して行われた第１の認証について、認証失敗を判定する。他方、スマートコントラクトは、予約申し込み時刻を有効期間に含む第１の公開鍵を使用して行われた第１の認証について、認証成功を維持する。かかる構成によれば、ブロックに書き込まれた時刻が各公開鍵の有効期間を示すので、有効期間を別途管理せずに済むという点で、実装を容易にすることが可能となる。

また、携帯機１００は、予約情報及び電子署名をブロックチェーンにおけるブロックに書き込んでもよい。そして、第１の認証部としてのスマートコントラクトは、ブロックに書き込まれた予約情報及び電子署名に対し、第１の認証を行う。なお、予約情報及び電子署名が書き込まれるブロックチェーンと、公開鍵が書き込まれるブロックチェーンとは、別々に構成されてもよい。

そして、第１の認証部としてのスマートコントラクトは、予約情報及び電子署名がブロックに書き込まれた時刻を有効期間に含まない第１の公開鍵を使用して行われた第１の認証について、認証失敗を判定する。また、スマートコントラクトは、予約情報及び電子署名がブロックに書き込まれた時刻を有効期間に含む第１の公開鍵を使用して行われた第１の認証について、認証成功を維持する。かかる構成によれば、予約情報及び電子署名がブロックに書き込まれた時刻を予約申し込み時刻として取り扱うことができるので、予約申し込み時刻を別途管理せずに済むという点で、実装を容易にすることが可能となる。

＜３．まとめ＞
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、利用対象が車両２０２である例を説明したが、本発明はかかる例に限定されない。利用対象として、車両以外の、航空機、及び船舶等の任意の移動体に搭載されてもよい。ここで、移動体とは、移動する装置である。もちろん、利用対象は、移動体に限定されない。利用対象は、家又はホテルの部屋等であってもよく、例えばドア上の施錠／解錠が認証結果に基づいて実行されてもよい。

例えば、上記では、携帯機１００が生体情報取得部１２０を有する例を説明したが、本発明はかかる例に限定されない。例えば、携帯機１００は、生体情報取得部１２０を有していなくてもよい。その場合、登録処理においては、実店舗においてユーザの生体情報が取得され、鍵生成センタ３００に送信されてもよい。

なお、本明細書において説明した各装置による一連の処理は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組合せのいずれを用いて実現されてもよい。ソフトウェアを構成するプログラムは、例えば、各装置の内部又は外部に設けられる記録媒体（非一時的な媒体：non-transitory media）に予め格納される。そして、各プログラムは、例えば、コンピュータによる実行時にＲＡＭに読み込まれ、ＣＰＵなどのプロセッサにより実行される。上記記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等である。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信されてもよい。

また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。

１：システム、 １００：携帯機、 １１０：無線通信部、 １２０：生体情報取得部、 １３０：入出力部、 １４０：記憶部、 １５０：制御部、 ２００：通信ユニット、 ２１０：無線通信部、 ２２０：生体情報取得部、 ２３０：記憶部、 ２４０：制御部、 ３００：鍵生成センタ、 ３１０：通信部、 ３２０：記憶部、 ３３０：制御部、 ４００：サービスサーバ、 ４１０：通信部、 ４２０：記憶部、 ４３０：制御部

Claims (17)

1. ユーザにより利用可能な対象である利用対象を予約する前記ユーザである第１のユーザの体に関する情報である生体情報に基づく認証であって、前記第１のユーザの正当性を認証する第１の認証を行う第１の認証部と、
   前記利用対象を利用する前記ユーザである第２のユーザの前記生体情報に基づく認証であって、前記第２のユーザが前記第１のユーザと同一であることを認証する第２の認証を行う第２の認証部と、
   前記第１のユーザの前記生体情報に対応する公開鍵である第１の公開鍵に基づいて秘密鍵を生成する鍵生成部と、
   前記第１のユーザによる前記利用対象の予約に関する情報である予約情報に、前記予約情報及び前記鍵生成部により生成された前記秘密鍵に基づいて生成された電子署名を対応付けて前記第１の認証部に送信することで、前記第１のユーザによる前記利用対象の予約を行う予約部と、
   を備えるシステム。
2. 前記第１の認証部は、前記第１のユーザの前記生体情報に対応する公開鍵である第１の公開鍵を使用して前記電子署名が正しいか否かを検証し、前記電子署名が正しいと検証した場合に認証成功を判定し、前記電子署名が不正であると検証した場合に認証失敗を判定することを、前記第１の認証として行う、
   請求項１に記載のシステム。
3. 前記第２の認証部は、前記第１の認証に成功した前記第１のユーザの前記生体情報に対応する公開鍵である第１の公開鍵と、前記第２のユーザの前記生体情報に対応する公開鍵である第２の公開鍵とが、対応するか否かを判定し、対応する場合に認証成功を判定し、対応しない場合に認証失敗を判定することを、前記第２の認証として行う、
   請求項２に記載のシステム。
4. 前記第１の公開鍵は、前記第１のユーザの前記生体情報であり、
   前記鍵生成部は、前記第１のユーザの前記生体情報から抽出された特徴量に基づいて前記秘密鍵を生成する、
   請求項３に記載のシステム。
5. 前記第１の公開鍵は、前記第１のユーザの前記生体情報であり、
   前記第１の認証部は、前記第１のユーザの前記生体情報から抽出された特徴量に基づいて前記電子署名が正しいか否かを検証することを、前記第１の認証として行う、
   請求項３又は４に記載のシステム。
6. 前記第１の公開鍵は、前記第１のユーザの前記生体情報であり、
   前記第２の公開鍵は、前記第２のユーザの前記生体情報であり、
   前記第２の認証部は、前記第１のユーザの前記生体情報から抽出された特徴量と、前記第２のユーザの前記生体情報から抽出された特徴量とが、一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、前記第２の認証として行う、
   請求項３～５のいずれか一項に記載のシステム。
7. 前記鍵生成部は、前記第１のユーザの前記生体情報に基づいて前記第１の公開鍵を生成し、生成した前記第１の公開鍵を前記第１の認証部に送信する、
   請求項３に記載のシステム。
8. 前記鍵生成部は、前記第１のユーザの前記生体情報から抽出された特徴量をハッシュ関数に入力することで得られたハッシュ値を、前記第１の公開鍵として生成する、
   請求項７に記載のシステム。
9. 前記第１の認証部は、前記鍵生成部により生成された前記第１の公開鍵を使用して前記電子署名が正しいか否かを検証することを、前記第１の認証として行う、
   請求項８に記載のシステム。
10. 前記第２の認証部は、前記鍵生成部により生成された前記第１の公開鍵と、前記第２のユーザの前記生体情報から抽出された特徴量をハッシュ関数に入力することで得られたハッシュ値である前記第２の公開鍵とが、一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、前記第２の認証として行う、
    請求項８又は９に記載のシステム。
11. 前記鍵生成部は、前記第１のユーザの前記生体情報から抽出された特徴量に基づいて、前記生体情報のゆらぎを訂正するための情報である誤り訂正用補助データを生成し、
    前記第２の認証部は、
    前記鍵生成部により生成された前記誤り訂正用補助データに基づいて前記第２のユーザの前記生体情報から抽出された前記特徴量を訂正し、
    訂正後の前記特徴量を前記ハッシュ関数に入力することで得られたハッシュ値を前記第２の公開鍵として使用して、前記第１の公開鍵と前記第２の公開鍵とが一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、前記第２の認証として行う、
    請求項１０に記載のシステム。
12. 前記鍵生成部は、前記第１のユーザの前記生体情報から抽出された特徴量、及び前記第１の公開鍵を新たに生成する度に変化する情報である鍵更新用補助データを、ハッシュ関数に入力することで得られたハッシュ値を、前記第１の公開鍵として生成し、
    前記第２の認証部は、前記第２のユーザの前記生体情報から抽出された前記特徴量、及び前記鍵更新用補助データを、ハッシュ関数に入力することで得られたハッシュ値を前記第２の公開鍵として使用して、前記第１の公開鍵と前記第２の公開鍵とが一致するか否かを判定し、一致する場合に認証成功を判定し、不一致である場合に認証失敗を判定することを、前記第２の認証として行う、
    請求項１０又は１１に記載のシステム。
13. 前記鍵生成部は、前記第１の公開鍵を新たに生成した場合、新たに生成した前記第１の公開鍵に対し有効であることを示す情報を対応付け、過去に生成した前記第１の公開鍵に対し無効であることを示す情報を対応付け、
    前記第１の認証部は、有効であることを示す情報が対応付けられた前記第１の公開鍵を使用して、前記第１の認証を行う、
    請求項１２に記載のシステム。
14. 前記鍵生成部は、前記第１の公開鍵を新たに生成した場合、新たに生成した前記第１の公開鍵及び過去に生成した前記第１の公開鍵の各々に対し、有効期間を示す情報を対応付け、
    前記第１の認証部は、前記予約情報に対応付けられた時刻を前記有効期間に含まない前記第１の公開鍵を使用して行われた前記第１の認証について、認証失敗を判定する、
    請求項１３に記載のシステム。
15. 前記鍵生成部は、生成した前記第１の公開鍵をブロックチェーンにおけるブロックに書き込み、
    前記第１の認証部は、前記第１の公開鍵が前記ブロックに書き込まれた時刻に基づいて前記第１の公開鍵の有効期間を認識し、前記予約情報に対応付けられた時刻を前記有効期間に含まない前記第１の公開鍵を使用して行われた前記第１の認証について、認証失敗を判定する、
    請求項１３に記載のシステム。
16. 前記予約部は、前記予約情報及び前記電子署名をブロックチェーンにおけるブロックに書き込み、
    前記第１の認証部は、前記予約情報及び電子署名が前記ブロックに書き込まれた時刻を前記有効期間に含まない前記第１の公開鍵を使用して行われた前記第１の認証について、認証失敗を判定する、
    請求項１４又は１５に記載のシステム。
17. ユーザにより利用可能な対象である利用対象を予約する前記ユーザである第１のユーザの体に関する情報である生体情報に基づく認証であって、前記第１のユーザの正当性を認証する第１の認証を行い、
    前記利用対象を利用する前記ユーザである第２のユーザの前記生体情報に基づく認証であって、前記第２のユーザが前記第１のユーザと同一であることを認証する第２の認証を行う第２の認証部に対し前記第２の認証のための情報を提供する第１の認証部、
    を備え、
    前記第１の認証部は、前記第１のユーザによる前記利用対象の予約に関する情報である予約情報に対応付けられた、前記第１のユーザの前記生体情報に対応する公開鍵である第１の公開鍵に基づいて生成された秘密鍵に基づいて生成された電子署名を、前記第１の公開鍵を使用して検証することで前記第１の認証を行う、
    認証装置。
    

Images