JPWO2018088475A1 - 電子認証方法及びプログラム - Google Patents

Abstract

簡易且つ迅速に電子認証を行う技術を提供することを目的とする。ネットワークを介して通信可能な複数のコンピュータが認証局となり、個人又は組織体が正当な本人認証済み記録を有しているかをコンピュータ間で連携して証明する。このため、一部のコンピュータがダウンしても認証局全体としては常時稼働可能という耐障害性があり、常にタイムリーな電子認証が可能である。各コンピュータは、本人確認した事実があるか、内容の変更の有無等を完全同一な履歴データとして記録管理し、コンピュータ間で一致が図られた状態を保持する。本人確認の登録は複数のコンピュータにより合意形成がされた場合にのみ正当なデータとして登録が認められることから、登録データはユーザに関する確実な本人認証情報として利用することが可能になる。

Description

本発明は、電子認証に係り、特に、一の事業者との関係で本人確認済みがされている個人又は組織体が、他の事業者との関係でも本人確認の認証が必要な場合に、一の事業者との関係で記憶されている本人確認済みの事実を用いて他の事業者のための本人確認の認証に利用する技術に関する。

従来、個人が銀行又は証券会社等の金融機関に口座を開設する場合や、インターネットを介してネット業者から物品やサービス等を購入する際には、少なくとも氏名、住所、生年月日等を含む個人情報及びその証明書が要求される。この個人情報が悪用された場合、プライバシー侵害につながるのみならず経済的損失の可能性もあるため、秘密情報として扱っている企業も多い。例えば、個人ＸがＡ銀行に口座を開設するためＡ銀行へ身元確認を示す個人情報及び証明書を提供し、その後にＢ銀行にも口座を開設するときは、同じように個人情報及び証明書を提供する必要がある。したがって、個人は各金融機関に対して本人確認手続きをしなければならないという手間が生じていた。

近年、証明書に関しては電子認証が普及しつつある。インターネット上の情報のやりとりは相手が誰なのか、別人がなりすまししていないか、交わした情報は信用できるものかといった懸念がある。そこで、電子認証局から発行される電子証明書を用いてなりすまし防止や情報の改ざんを防止する有効な一手段が、電子認証技術である。例えば、すでに、多くの都道府県では納税をはじめとする様々な行政手続き等において公的個人認証サービスが利用可能であり、電子証明書が使用されている。公的個人認証サービスはこれまで行政機関等に限られていたが、総務省は平成２８年より、ＩＤ・パスワード方式よりも高いセキュリティレベルが要求される様々な民間サービスに対しても公的個人認証サービスを普及拡大させるよう推進している。最近では、金融機関等での口座開設時の個人情報及び証明書の提供に代わり、公的個人認証サービスによる電子証明書の利用が提案されはじめている。

上述した金融機関の口座開設のケースにおいて、従来では、個人情報を記入した口座開設申込書や本人確認書類を金融機関等に送付又は送信し、金融機関等が送られた書類を確認して、利用者カード等を書留郵便などで個人に返送するため、多くの時間及びコストがかかっていた。これに代わり、電子証明書を利用した手続きにすれば、口座開設の申込み後すぐに手続が開始され、コストもかなり安価に抑えることが期待できる。

公的個人認証サービスの他にも各電子認証サービス会社によって様々な種類の民間電子認証サービスがインターネット上のウェブサイトで提供されるようになると、ユーザは何が認証されるのかを判別し難くなったり、その電子認証サービスを提供するウェブサイトが信頼できるのかを確認することが新たな課題としてあらわれてくる。そこで、下記特許文献１は、様々な電子認証サービスを提供するウェブサイトの信頼性を画面上でユーザが確認できるシステムを開示している。

特開２０１０−６３０６９号公報

確かに、電子認証サービスによる電子証明書の利用は、従来に較べて即時性及びコスト面で優れているといえよう。しかしながら、電子証明書の取得をするには各ユーザが認証局に申込みをして所定の手続に従った操作が必要である。例えば、電子認証サービスを利用するための所定のプログラムを自分の端末にインストールすること等が要求されるので、手間のかかるセットアップ作業が面倒で電子認証サービスの利用を断念するユーザもいる。

また、電子証明書を発行する機関である認証局は、単一の組織又は団体であるか、若しくは認証パス上にルート認証局と中間認証局が存在するという複数体の構成である。後者は、発行元の認証局から順に、その認証局を認証している上位の認証局、さらに上位の認証局…といった具合に辿っていき、最終的にルート認証局にたどり着くという認証手順をとる。単一の組織又は団体である認証局の場合、その認証局が統括機能を実現していることは当然であるが、ルート認証局及び中間認証局で構成される場合であっても、１つ１つの認証局においてはやはり中央管理的な制御及び管理がなされていることに変わりはない。つまり、認証パス上の各認証局は、他の認証局による認証を順次引き継いではいるものの、それぞれのローカルな認証において複数の独立した認証局が同時並行に認証処理を行いながら協働体制で運営されているわけではない。

このため、従来の中央管理型認証局は、認証局のサーバ等が稼働していない時間帯では電子証明書の発行ができないので、電子証明書の発行を望むユーザは利用時間が制限されてしまうことになる。仮に一日２４時間のサービス利用可能な体制で運用したとしても、サーバメンテナンス等を定期的に行う必要があったり、様々な要因による不測のシステムダウンが発生し得るので、実際には年中無休のサービスにはならない。中央管理型で構成される認証局の場合は、いつでも好きな時に電子証明書を取得できるサービスを提供できないのである。

また、発行される電子証明書の中には、個人情報（例えば、氏名・住所・生年月日・性別の基本４情報）を含んでいるものがある。情報化の急速な進展に伴い、個人情報の目的外利用の禁止、適正な取得方法、安全管理措置、第三者提供の制限など個人情報に対する保護（個人情報保護法）が強化されている事情から、国や地方自自体、及び民間企業が保有・管理する情報サーバは、悪意者による不正侵入されないようにする対策を講じてはいる。しかし、厳重なセキュリティ体制が施されていると言われているサーバであっても、結果として情報漏洩が完全に防止できなかったニュースが後を絶たないことから理解できるとおり、認証局が個人情報の保有をしていた場合、その漏洩や改ざんがされないことを長期にわたり保証できないのが現状である。

ところで、最近は、主に金融関係の分野で分散型台帳技術（DLT, Distributed Ledger Technology)が注目をあびてきている。現時点で分散型台帳技術の正確な定義は確定していないが、台帳を承認する者がネットワークに接続する任意のノード端末にするか限定したノード端末にするか（Permissionless/Permissioned）を一つの指標として分類することができる。

公開型のPermissionlessトランザクションで、特にデータの公開をしている典型例が、暗号通貨（ビットコイン）のためのブロックチェーンである。これに対し、ネットワークの参加資格（特に、データ承認者）、取引を発行する者、ＡＰＩからデータを読み込む者が信頼性のあるノード端末に限定したPermissionedネットワークを対象としているのが、“Ripple”や“Hyperledger”と呼ばれている仕組みである。これらについては、下記を参照されたい。
https://ripple.com/files/ripple_consensus_whitepaper.pdf、及び
http://www.linuxfoundation.org/news-media/announcements/2016/02/linux-foundation
-s-hyperledger-project-announces-30-founding。

分散型台帳技術の特徴の一つは、トランザクション及びアクションの正当性を決定する際に特定のサーバにおける検証に依存することなく、非中央集権なピア・ツー・ピア（Ｐ２Ｐ）型ネットワークを基盤にしているという点である。特定のサーバがトランザクション等に関する台帳を統括して管理するのではなく、各端末が同一の台帳を管理することによって、新たなトランザクション等に対してどの台帳においても矛盾が生じないと認められた場合にのみ、各台帳に追加する正規なトランザクション等として認められるという管理構成をとる。例えば、或る端末が攻撃され、その端末が保有する分散型台帳が不正者によって改ざんされたとしても、ネットワーク上の承認者グループに参加する他の端末の台帳と整合しない場合は、改ざんトランザクションは拒絶されてしまう。ネットワーク上の承認者グループに参加する一定数以上の端末からの合意が得られなければ、分散型台帳の完全性の欠如となり、正規のデータとして記録されることはない。各端末のネットワーク接続をＰ２Ｐ型にすることにより、セキュリティ管理の分散化及び信頼性向上を図っているのである。

このように分散型台帳技術は各端末が保有するデータがネットワーク全体で完全同一であることを求める一方で、各端末それぞれでのローカルな事情、即ち、既存のシステム構成やトランザクション処理手順や内容に対して何ら変更を要求するわけではない柔軟性をあわせ持っている。したがって、各端末の独立性を維持しながらセキュリティ性の分散化・高信頼性を図る一手段として、分散型台帳技術は優れた手段の一つとして注目され始めている。

そこで、本発明は、電子認証に関する上述した様々な課題を解決するべく、分散型台帳技術を基に電子認証を行う技術を提供することを目的とする。

前記目的を達成するために本発明に係る情報共有のためのプログラム及び方法は、ネットワーク上に接続する複数のコンピュータを用いて認証処理を行うためのプログラムであって、前記複数のコンピュータに含まれる一のコンピュータは、ユーザ登録のリクエストに応答して、前記ネットワーク上に個人又は組織体を特定する情報を含むデータを出力する処理と、前記複数のコンピュータに含まれる前記一のコンピュータ以外の少なくとも１以上のコンピュータは、前記ネットワーク上に出力された前記データを取り込み、同一の演算を実行することによりコンピュータ間の合意形成が得られた場合に前記複数のコンピュータは各自の記録媒体に前記データを記憶する処理と、前記複数のコンピュータに含まれる任意のコンピュータが、前記ユーザ登録したユーザの本人認証の要求を事業体又は個人から受けた場合、前記複数のコンピュータの少なくとも１つのコンピュータが自身の記録媒体に前記データが記憶されているか否かを判定する処理と、前記データが記憶されていた場合、前記本人認証を要求する事業体又は個人に対し、本人認証済みの報告を送信する処理と、が実行されるようにすることを特徴とする。

また、前記複数のコンピュータの各コンピュータの記録媒体には、前記データが完全同一で記憶されている。前記合意形成の有無は、前記各コンピュータによる演算結果の一致が所定数以上か否かにより決定する。

本発明に係る電子認証処理によれば、ネットワークを介して通信可能な複数の独立したコンピュータ相互が認証局となり、個人又は組織体が正当な本人認証済み記録を有しているかをコンピュータ間で連携して証明する。このため、仮に複数の独立したコンピュータの一部のコンピュータが任意の要因により機能不全になったとしても認証局全体としては常時稼働可能という耐障害性があるので、常にタイムリーな電子認証が可能となる。従来の中央管理型の認証局が２４時間稼働を保証すようとすれば、耐障害性や冗長構成のためのコストがかかるが、本発明は複数のコンピュータがそれぞれ独立に同一の本人認証済み記録を分散共有することを前提とするＰ２Ｐ型分散型台帳技術の標準仕様を実装するため、低コストでゼロダウンタイムの認証局システムを構築することができる。

また、本発明の場合、或る事業者の業務の必要性からユーザ(個人又は組織体)の行った本人認証済みの事実が認証局システムとして機能する複数の独立したコンピュータに記憶されている場合、その本人認証済みの事実を別の事業者で必要となる本人認証に利用する。既に記憶された本人認証済みの事実を信頼して、当該ユーザの本人認証を完了させるものである。つまり、別の事業者は、本発明の認証局システムから正当な本人認証が記録されている報告を受け取った場合、有効な期間内の本人認証であれば、その別の事業者が改めて同様の本人確認作業を行う必要がない。これは、別の事業者の手間を削減することのみならず、事業者ごとに本人確認書類を送付していたユーザ側の煩雑な処理を省略させることができるという効果を奏する。

本人認証済みの事実を別の事業者での本人認証に利用するということは、認証局である複数のコンピュータに記憶された本人確認の事実が完璧に真性であることが認証の信頼性を担保する上で常に要求される。この点に関し、本発明における複数のコンピュータの各々は、本人確認済みの事実、確認内容の変更の有無等を完全同一な電子証明書履歴データとして時系列に保管しており、各コンピュータ間で不一致のない記録状態を保持している。このため、仮に複数のコンピュータに含まれる一のコンピュータにおいて、不正目的等で履歴データが変更されたとしても、複数のコンピュータに含まれる他のコンピュータ内の履歴データと同じでなければ、その変更された履歴データが正当なデータとして最終的に認められることはない。複数のコンピュータすべてが一致した状態で記録管理されていない履歴データは真性（正当）でないものと推定されることになる。不正者が複数のコンピュータすべてに対して履歴データの変更を一斉に実行することは事実上不可能であることから、本人認証済みの事実である電子証明書の改ざんリスクを無くすことが可能である。したがって、本発明に係る電子認証処理は、極めて高いセキュリティを保証することができる。

Ａ銀行に口座を開設し、本発明の認証処理を実行する認証システムにユーザ登録するときの手順を示したフローチャートである。 Ｂ銀行で口座を開設する際に、ユーザの本人確認を認証システムに依頼するときの手順を示したフローチャートである。 Ｂ銀行で口座を開設する際に、ユーザの本人確認を認証システムに依頼するときの手順を示したフローチャートである。 各コンピュータに記憶されたトランザクションデータ（電子証明書）のデータ構造を模式的に表した図である。 電子認証方法を実現する複数のコンピュータを示した図である。 図４（Ａ）と異なる構成例の複数のコンピュータを示した図である。

以下に図面を参照しながら、本発明に係る電子認証方法又はそのプログラムに規定する各処理を実行する認証局システムについて説明する。以下の実施の形態においては、個人が金融機関に口座を開設する際に必要な本人確認の事実をデータ化して記録し、別の金融機関の口座開設時においては個人から本人確認書類を受領せずとも本人確認を行える手順を例にしている。また、記録されたデータは本人確認がされていた事実の証拠となるため、いわゆる電子証明書として使用することも可能である。なお、個人に限らず、法人などの組織体に対する電子認証の場合であってもまったく同様である。

本発明の電子認証処理を実行するシステム構成は、個人を認証するための認証局が複数のコンピュータによって構築され、しかも複数のコンピュータは中央集権的な端末が存在しない複数の金融機関によるコンソーシアムを形成するというＰ２Ｐ型のネットワーク接続になっている。複数のコンピュータは互いに対等であり、詳細は後述するが、本人確認した事実を示すデータを複数のコンピュータそれぞれが保管し合うことで同一データの分散化を図っている。

以下では、まず、従来どおりに口座開設を行う手順、次に本発明の電子認証処理を実行する認証局となる認証システム１００に本人確認済み事実を登録していないユーザが本人確認の事実を登録する手順、そして、金融機関から登録後ユーザの本人確認済み事実の真偽のリクエストがあったとき、認証システム１００が実行する電子認証処理について説明する。

ユーザＸは認証システム１００に本人確認をまだ登録していないとする。ユーザＸは、Ａ銀行に口座を開設するため、従来のように、自分のコンピュータ端末からインターネット経由でＡ銀行のサイト上で、口座開設の申し込みをする。具体的には、口座開設に必要となる少なくとも、自分の氏名、住所、生年月日、性別（以下、この４つの情報を「基本４情報」と呼ぶ。）等をＷＥＢ画面上で入力する。本人確認書類の提出と住所確認などの手続きを経て口座開設が完了し、口座開設完了後に、Ａ銀行は所定のＩＤ及びパスワードをユーザＸに返送する。ここでは住所確認を兼ねる目的で郵送するが、ユーザＸのｅメールアドレスに送信するようにしてもよい。以降、ユーザＸはこのＩＤ及びパスワードを用いてＡ銀行にログインし残高を確認することや、取引実行などを行うこととなる。なお、ＩＤ及びパスワードは、口座番号やＡＴＭの暗証番号と同じ場合又は異なる場合の両方を含む。

口座開設のためには、基本４情報の真偽を証明する本人確認書類を送付することが必要である。本人確認書類のコピー書面を郵送してもよいが、郵送の代わりに本人確認書類の電子データの送信も従来から行われている。ここでは、本人確認書類を電子データにしてＡ銀行に送信するものとする。もっとも、口座を開設するためには、インターネット経由だけではなく、対面での申込も存在する。

Ａ銀行は、基本４情報を含む個人情報と、送信された本人確認書類の内容をチェックし、ユーザＸの本人確認作業を行う。具体的には、基本４情報が本人確認書類の内容の一致、住所の確認し、ブラックリストとの照合などで、ユーザＸが実在する人物として識別できて口座取引を許可してもよいと判断できた場合、本人確認済みであるとしてユーザＸの口座開設を行う。これにより、ユーザＸはＡ銀行の口座開設が完了したことを確認できる。ユーザＸは、Ａ銀行から送られたＩＤ及びパスワードを用いてＡ銀行のサイトにログインし、入出金や振込み等をインターネット経由で行ういわゆるネット取引を開始できるようになる。

ここまでの処理は、従来から既に行われてきたものであるが、本発明は、Ａ銀行がユーザＸの本人確認を行った事実を認証システム１００に登録することで、Ａ銀行以外の銀行等での口座開設時には本人確認済みの事実を利用できるという点に特徴がある。認証システム１００に登録するか否かはユーザＸからの申込みを前提とし、口座開設後、任意の時にユーザ登録アプリケーションを実行することによって認証システム１００に登録することができる。

＜認証システム１００への登録＞
図１は、認証システム１００を利用するための登録を行う手順を示したフローチャートである。図１の左部は、ユーザＸを認証システム１００に初めて登録するときの処理を時系列のフローで示し、各処理においてどのようなデータ又は信号がやりとりされているかをフローの右側にあらわしている。図示するとおり、ユーザＸのコンピュータ端末（Ｃ１）、スマートフォン等のユーザＸの携帯端末（Ｃ２）、認証端末（Ａ１）、認証局端末（Ａall）の間でデータ又は信号が送受信される。ここで、認証端末（Ａ１）とは、ユーザＸが口座開設したＡ銀行の端末に相当する。Ａ銀行の端末を“認証”端末と称しているのは、上述したようにＡ銀行がユーザＸの本人確認（認証）をしているからである。認証局端末（Ａall）は、認証システム１００において分散型台帳技術（ＤＬＴ）又はブロックチェーンを構築する所定の複数の端末である。この複数の端末が認証局としての機能を果たし、後述するように、Ａ銀行、即ち認証端末（Ａ１）が、ユーザの登録要求を受けて、認証局である認証システム１００に登録を依頼することになる。

Ａ銀行の口座開設が完了すると、上述したように、所定のＩＤ及びパスワードを記載した書面がユーザＸに返送される。ユーザＸが認証システム１００への登録を希望する場合、まずユーザＸはユーザＰＣ（Ｃ１）からＡ銀行のサイトに付与されたＩＤ及びパスワードを入力してログインする。（図１の「1. ユーザログイン」参照）。つぎに、ログイン画面上には認証システム１００による認証サービスを利用するために必要なユーザ登録申込みボタンが表示されているため、ユーザＸがこのボタンを押下する。これにより、Ａ銀行の端末である認証端末（Ａ１）は、ノンス（nonce）と呼ばれる使い捨てのランダムな値を発行し、このノンスに電子署名を付与してユーザＰＣ（Ｃ１）に送信する（図１の「2. nonce送信」参照）。そして、ユーザＰＣ（Ｃ１）は、受け取ったノンスなどを利用してＱＲコード（登録商標）を生成し、画面上に表示する。なお、電子署名自体は既知の技術的事項であるため、本明細書では説明を省略する。

図中における“Ａ１署名（nonce）”は、認証端末（Ａ１）による電子署名付きのノンスを意味する。同様に、図１及び図２（Ａ）−（Ｂ）において送受信される##署名（**）の記載の意味は、##による電子署名付きの**をあらわしている。
認証端末（Ａ１）がユーザＸにノンスを発行する目的は、後の手続処理で、ユーザ登録を要求するユーザＸが真に登録手続きを行っていることを確認するためであり、ノンスがユーザＸから認証端末（Ａ１）へ返信されなければ、ユーザＸ以外の者による登録手続きであると判定する。

ユーザＸは、次に、携帯端末（スマートフォン等）が認証システム１００で利用可能になる手続きを行う。これは、昨今は少なくとも１台の携帯端末（Ｃ２）を所持するユーザが増加し、携帯端末（Ｃ２）の使用によって二段階認証を利用してセキュリティを強化すると共に、出先からであっても入出金や振込み等のために個人認証を行いたい要求に応えるためである。

携帯端末（Ｃ２）には、所定のアプリサイトからダウンロードされたユーザ登録アプリケーションが起動されているとする。認証端末（Ａ１）の電子署名付きのノンスをユーザＰＣ（Ｃ１）で受信したユーザＸは、ユーザＰＣ（Ｃ１）の画面上に表示されているＱＲコードを携帯端末（Ｃ２）を用いて読み込む。ＱＲコードにはＡ銀行に関する銀行情報が含まれており、例えば、携帯端末（Ｃ２）からＡ銀行に接続する接続先アドレスを含んでいる。携帯端末（Ｃ２）は、読み込んだＱＲコードからの銀行情報及びユーザＰＣ（Ｃ１）で受信されたノンスを受信する（図１の「3. ＱＲコード読取」参照）。
なお、他の実施形態では、ＱＲコード（登録商標）は、所定のＩＤ及びパスワードが記載された書面に表示されていてもよい。

次に、携帯端末（Ｃ２）では、ユーザ登録アプリケーションによって秘密鍵及び公開鍵のキーペアを作成する（図１の「4. キーペア作成」参照）。キーペアのうち秘密鍵（Ｃ２秘密鍵）は、携帯端末（Ｃ２）内に保管される。一方、キーペアのうち公開鍵（Ｃ２公開鍵）は、Ａ銀行である認証端末（Ａ１）に送信される。このとき、携帯端末（Ｃ２）は、「3. ＱＲコード読取」の際に受信したノンス及びＣ２公開鍵に対してＣ２秘密鍵を用いて電子署名を付与する。携帯端末（Ｃ２）の電子書署名付きのノンス及びＣ２公開鍵は認証端末（Ａ１）に送信される（図１の「5. ユーザ公開鍵送信」参照）。

認証端末（Ａ１）は、受信したＣ２公開鍵を用いて携帯端末（Ｃ２）の電子署名を検証する。Ｃ２公開鍵に対応するのはキーペアを成すＣ２秘密鍵しか存在しない。したがって、Ｃ２秘密鍵を用いて付与した電子署名をＣ２公開鍵によって確認できれば、キーペアを成すＣ２秘密鍵を保管する携帯端末（Ｃ２）によってＣ２公開鍵が署名されたことを確認できる。さらに、認証端末（Ａ１）は、Ｃ２公開鍵の他にノンスも受信しており、このノンスが、「2. nonce送信」の際に認証端末（Ａ１）が発行したノンスと同一であるか否かを確認することで、ユーザＸがユーザ登録を望む真のユーザであることを確認する。ノンスの同一性を確認できなければ、ユーザＸ以外の者による手続として拒絶する。

認証端末（Ａ１）は、ユーザ登録をリクエストするユーザＸの真性を確認できると、次に、複数のコンピュータで構成された認証局端末（Ａall）へユーザ登録を依頼するため、Ｃ２公開鍵、基本４情報のハッシュ値、認証端末（Ａ１）の公開鍵（Ａ１公開鍵）に対して自身の電子署名を付与して認証局端末（Ａall）へ送信する（図１の「6. 認証局に登録」参照）。さらに、オプションとして、ユーザ登録の効力を期限付きなものにさせる有効期限を追加して認証局端末（Ａall）へ送信するようにしてもよい。なお、認証端末（Ａ１）は、口座開設にあたりユーザＸから基本４情報が提供されているので、この基本４情報に所定のハッシュ関数を用いてハッシュ演算を実行し、ハッシュ値を生成して送信する。ハッシュについては当業者であれば既知の技術的事項なため、本明細書では説明を省略する。

認証局端末（Ａall）では、いわゆる分散型台帳技術（ＤＬＴ）又はブロックチェーンといわれることもあるデータ構造で、認証端末（Ａ１）から送られてきたデータを、複数のコンピュータの各々が同じように記憶する（分散型台帳）。データ登録の具体的な処理方法については後述する。認証端末（Ａ１）は登録がされたかの確認を行い（図１の「7. 登録結果の確認」参照）、認証局端末（Ａall）はその確認結果を認証端末（Ａ１）に返す（図１の「8. 登録確認の結果」参照）。

正常に登録が完了されていた場合、認証端末（Ａ１）は、「5. ユーザ公開鍵送信」の際に受信したＣ２公開鍵を用いて基本４情報を暗号化して暗号データを作成する。そして、認証端末（Ａ１）は、暗号データ及び認証端末（Ａ１）の公開鍵（Ａ１公開鍵）に対して自身の電子署名を付与して携帯端末（Ｃ２）へ送信する（図１の「9. 基本４情報の登録」参照）。基本４情報の暗号データを作成するのは、通信回線上で生（平文）の基本４情報が盗聴されると不正利用等されてしまうリスクを回避するためである。

携帯端末（Ｃ２）は、受信したＡ１公開鍵を用いて認証端末（Ａ１）の電子署名を検証する。Ａ１公開鍵に対応するのはキーペアを成すＡ１秘密鍵しか存在しない。したがって、携帯端末（Ｃ２）は、Ａ１公開鍵によって、Ａ１秘密鍵を用いた認証端末（Ａ１）の電子署名を確認して認証端末（Ａ１）からの正しい通信であることを確認することができる。さらに、自身が保管するＣ２秘密鍵で基本４情報を復号化してアプリデータ以外の安全な領域（例えば、キーチェーンなど）に登録しておく。さらに、オプションとして有効期限を登録してもよい。

また、認証端末（Ａ１）は、ユーザＰＣ（Ｃ１）にも登録結果（基本４情報や有効期限を含んでもよい。）を送信し、ユーザ登録の事実が携帯端末（Ｃ２）と齟齬しないようにしておく（図１の「10. 登録結果通知」参照）。上述した一連の手続きにより、ユーザＸは認証システム１００に登録され、認証システム１００によるユーザ認証サービスを利用することが可能になる。

＜認証システム１００の利用＞
次に、ユーザＸがＡ銀行以外の別の金融機関（例えば、Ｂ銀行とする。）に口座開設をする場合を想定する。ユーザＸはＢ銀行の口座開設の申し込みをする際、従来であれば、Ｂ銀行もユーザＸに対して本人確認書類の送信を要求し、Ａ銀行と同じようにユーザＸの本人確認作業を行うものであるが、本実施形態の場合、この本人確認作業を認証システム１００に依頼する。

図２（Ａ）及び（Ｂ）は、Ｂ銀行の口座開設時に認証システム１００を利用した本人確認の手順を示すフローチャートである。認証システム１００による本人確認サービスの依頼は、ユーザＸからの申込みがあることを前提とする。本人確認サービスの申込みは、ＰＣ端末からでも、スマートフォン等の携帯端末からでも行える。ユーザＸが申込まなければ従来どおりＢ銀行へ本人確認書類のコピー書面を郵送又はデータ送信し、Ｂ銀行は基本４情報を含む個人情報を本人確認書類に基づき検証する。

ユーザＸは、ユーザＰＣ（Ｃ１）からＢ銀行の口座開設をリクエストする（図２（Ａ）の「1. V1の口座開設要求」参照）。

ＷＥＢ画面上には、本人確認書類のデータ送信に代わり認証システム１００を利用した本人確認サービスを利用するか否かの選択ボタンが表示され、ユーザＸが利用するボタンを選択した場合、認証システム１００にユーザ登録しているかの確認が行われる。ユーザ登録していなければ本人確認サービスを利用できないので、既存の本人確認フロー（すなわち、本人確認書類を提出して口座開設を行うなど）を行う。なお、ここでユーザ登録を希望すれば図１の手順に従いユーザ登録の処理を行うようにしてもよい。

上述したように、ユーザＸは既にユーザ登録しているので、Ｂ銀行の端末である検証端末（Ｖ１）は、ユーザＸにノンス（nonce）と呼ばれる使い捨てのランダムな値を発行すると、これに検証端末（Ｖ１）の電子署名を付与して、ユーザＸの端末であるユーザＰＣ（Ｃ１）に送信する（図２（Ａ）の「2. nonce送信」参照）。

Ａ銀行の口座開設時と同様、検証端末（Ｖ１）の電子署名付きのノンスをユーザＰＣ（Ｃ１）で受信したユーザＸは、ユーザＰＣ（Ｃ１）の画面上に表示されるＱＲコードを携帯端末（Ｃ２）を用いて読み込む。ＱＲコードにはＢ銀行に関する銀行情報が含まれており、例えば、携帯端末（Ｃ２）からＢ銀行に接続する接続先アドレスを含んでいる。携帯端末（Ｃ２）は、読み込んだＱＲコードから銀行情報及びユーザＰＣ（Ｃ１）で受信されたノンスを受信する（図２（Ａ）の「3. ＱＲコード読取」参照）。

図１（Ａ）の「4. キーペア作成」で説明したとおり、携帯端末（Ｃ２）はＣ２用のキーペア（秘密鍵、公開鍵）を保管している。そこで、次に携帯端末（Ｃ２）は、受信したノンス及びＣ２公開鍵に対してＣ２秘密鍵を用いて電子署名を付与する。携帯端末（Ｃ２）の電子書署名付きのノンス及びＣ２公開鍵が検証端末（Ｖ１）に送信される（図２（Ａ）の「4. ユーザ公開鍵送信」参照）。

検証端末（Ｖ１）は、受信したＣ２公開鍵を用いて携帯端末（Ｃ２）の電子署名を検証し、携帯端末（Ｃ２）から送信されたデータの正当性を確認する。さらに、「2. nonce送信」の際に自身が発行したノンスと同一であるか否かを確認することで、ユーザＸがＢ銀行の口座開設を望む真のユーザであることを確認する。ノンスの同一性を確認できなければ、ユーザＸ以外の者による登録手続として拒絶する。

次に、検証端末（Ｖ１）は、テンポラリーなキーペア（Ｔ秘密鍵、Ｔ公開鍵）を作成する（図２（Ａ）の「5. 一時的通信鍵作成」参照）。ユーザＸから基本４情報を受信するときの暗号化に用いるためである。検証端末（Ｖ１）は、テンポラリーなキーペアのＴ公開鍵及び発行済みのノンスに電子署名を付与して、携帯端末（Ｃ２）に送信する（図２（Ａ）の「6. 一時的通信鍵送信」参照）。Ｔ秘密鍵は検証端末（Ｖ１）が保管しておく。

Ｔ公開鍵を受信した携帯端末（Ｃ２）は、このＴ公開鍵を用いて基本４情報を暗号化して暗号データを作成する。そして、携帯端末（Ｃ２）は、暗号データ及びノンスに対して電子署名を付与して、検証端末（Ｖ１）に送信する（図２（Ａ）の「7. 基本４情報送信」参照）。

検証端末（Ｖ１）は、保管してあるＴ秘密鍵を用いて暗号データを復号化することによって基本４情報を平文に戻した上で、所定のハッシュ関数で基本４情報をハッシュする（hash（４情報））。次に、検証端末（Ｖ１）は、このhash（４情報）及びＣ２公開鍵を認証局端末（Ａall）に送信し、ユーザＸが認証局端末（Ａall）に真に登録された事実があるかの検証をリクエストする（図２（Ｂ）の「8. 既登録の確認要求」参照）。

認証局端末（Ａall）における複数のコンピュータの各々は、上述したように各自の記録媒体に同じようにユーザ登録の事実を保管及び管理している。本実施形態の場合、例えば、Ｃ２公開鍵を検索キーとして記録媒体内をサーチしてユーザ登録の有無を検出する。
同一ユーザに関して複数の登録がされていれば、登録が最新のものを検出したりする。これは、住所や氏名が変更されたケースに適用されるであろう。また、有効期限も含んで登録されている場合は失効されていないものを検出すればよい。このように、認証局端末（Ａall）は、(i)認証局端末（Ａall）を構成する少なくとも１つのコンピュータ（好ましくは、一定数以上のコンピュータ）がそのユーザ登録の事実を記録していること、及び(ii)記録されたhash（４情報）が検証端末（Ｖ１）から送られたhash（４情報）と同一であること、を確認できた場合はユーザ登録有りの結果、確認できなかった場合はユーザ登録無しの結果を、検証端末（Ｖ１）に返す（図２（Ｂ）の「9. 既登録の確認処理」参照）。

検証端末（Ｖ１）は、ユーザ登録有りの結果の場合は本人確認がとれたとみなして、ユーザＸのＢ銀行口座を開設する。ユーザ登録無しの結果の場合はＢ銀行口座を開設しない（図２（Ｂ）の「10. V1で口座開設」参照）。

さらに、検証端末（Ｖ１）は、ユーザＸのＢ銀行口座開設の事実を認証局端末（Ａall）に登録するリクエストを出す。本登録のため、検証端末（Ｖ１）は、Ｃ２公開鍵、ハッシュされた基本４情報であるhash（４情報）、検証端末（Ｖ１）の公開鍵（Ｖ１公開鍵）に対して電子署名を付与して、認証局端末（Ａall）に送信する。オプションとして、ユーザ登録の効力の期限を設けるための有効期限や登録した日時などを含んでいてもよい。更に他の実施形態では、有効期限を運転免許証や保険証の有効期限に設定したり、登録日時から例えば１年などと決めるようにすることを含む。
これを受けて、認証局端末（Ａall）は受信した上記データを登録する（図２（Ｂ）の「11. 認証局に登録」参照）。

また、検証端末（Ｖ１）は認証局端末（Ａall）に正常に登録がされたかの確認を行い、認証局端末（Ａall）はその確認結果を検証端末（Ｖ１）に返す（図２（Ｂ）の「12. 登録結果の確認」参照）。検証端末（Ｖ１）は、認証局端末（Ａall）にユーザ登録された報告を携帯端末（Ｃ２）に送信する（図２（Ｂ）の「13. 登録完了の報告」参照）。

なお、他の実施形態においては、ユーザ登録された報告を携帯端末（Ｃ２）に送信する際に「4. ユーザ公開鍵送信」の際に受信したＣ２公開鍵で暗号化した基本４情報と、検証端末（Ｖ１）の公開鍵とに、検証端末（Ｖ１）の電子署名（更に、オプションとして有効期限も含んでもよい。）を付与して携帯端末（Ｃ２）へ送信するようにしてもよい。検証端末（Ｖ１）からの送信を受けて、携帯端末（Ｃ２）は、検証端末（Ｖ１）の公開鍵を用いて検証端末（Ｖ１）の電子署名を検証するとともに、自身のＣ２秘密鍵で暗号データを復号化する。これにより、認証局端末（Ａall）にＢ銀行の口座開設が登録されたことを知るようにしてもよい。

その後、検証端末（Ｖ１）は、テンポラリーなキーペア（Ｔ秘密鍵、Ｔ公開鍵）を使用できなくする、鍵の破棄を実行しておく（図２（Ｂ）の「14. 一時的通信鍵破棄」参照）。そして、検証端末（Ｖ１）は、ユーザＰＣ（Ｃ１）にも登録結果（基本４情報や有効期限を含んでもよい。）を送信し、Ｂ銀行の口座開設の登録が携帯端末（Ｃ２）と齟齬しないようにしておく（図２（Ｂ）の「15. 登録結果通知」参照）

以上のとおり、Ｂ銀行は従来のような本人確認書類の送信をユーザＸに要求するのではなく、ユーザＸが他の事業者との間での取引等のために既に認証システム１００に登録されている事実をもって本人確認作業を行うものであり、事業者ごとに行っていた本人確認作業の代わりを処理することができるようになる。

＜登録データの構成と登録処理＞
以降は、認証システム１００を構成する複数のコンピュータに記憶されるデータの構成と、複数のコンピュータがユーザＸを各自の記録媒体に登録する際に行う演算処理について説明する。
本実施形態の認証システム１００は、分散型台帳技術に基づく処理を実行する。分散型台帳技術の特徴の一つは、ネットワークに参加する複数の端末間で同じ帳簿（即ち、履歴データ）をそれぞれ持ち合い、常に情報が共有されるように構成されている点である。Ｐ２Ｐ型でネットワーク接続するノード（端末）が履歴データを分散して保存しているのである。従来の多くのシステムのようなサーバを核とする中央集権型に構成され、ネットワーク上のインスタンスやデータを中央集権サーバがコントロールするような仕組みとは大きく異なる。したがって、本実施形態の認証システム１００の場合、複数のコンピュータの各コンピュータが各自の記録媒体に登録（記憶）しているユーザデータが、同一なデータであることを前提とすることに特徴がある。

１．登録されるデータ構成
図３は、認証局（Ａall）における各コンピュータが登録するデータの構成例を示している。図１の登録フローに従い、「6. 認証局に登録」の手順のとき登録されるデータは、図３の左部に示すとおり、携帯端末（Ｃ２）の公開鍵、ユーザＸの基本４情報のハッシュ値、Ａ銀行である認証端末（Ａ１）の公開鍵、そしてオプションとして有効期限、及び認証端末（Ａ１）の電子署名のデータ群３１を含む。必ずしもこれらのデータ群３１に限定しているわけではなく、他のデータを適宜含むこともある。例えば、記憶する時点のタイムスタンプ情報を含んでいてもよい。このタイムスタンプ情報は、認証局（Ａall）の各コンピュータで共通の日時、あるいは各コンピュータで記憶した日時の両方の場合がある。

また、Ａ銀行の口座開設時にユーザ登録した後、Ｂ銀行の口座開設時に本人確認を認証局（Ａall）にリクエストした事実を記録したデータ構成例を図３の右部に示す。このデータ構成では、Ａ銀行のときに記録したデータ群３１の直後にＢ銀行のときに記録したデータ群３２がつながって記録されているケースを概念的にあらわしている。このようなデータ群の連鎖として考えられることから、いわゆる分散型台帳技術（ＤＬＴ）又はブロックチェーン構造とも呼ばれている。

実際には、データ群３１の記録の後、Ａ銀行やＢ銀行等の任意の事業体で行われる他のユーザ登録が登録されることになるため、時系列でデータ登録をあらわすとすれば、データ群３１とデータ群３２との間にはユーザＹに関する同様のデータが記録されることになろう。この場合、データ群３１とデータ群３２は互いの記憶アドレスを示すリンク情報（例えば、ポインターなど）を有することで、ユーザＸという同一人物の記憶データを迅速にサーチできるようにしてもよい。認証局（Ａall）における各コンピュータは、これら複数のデータ群を同一のデータ構成で記憶する。

２．登録処理
次に、認証局（Ａall）における各コンピュータが合意形成をした上で、携帯端末（Ｃ２）の公開鍵、ユーザＸの基本４情報のハッシュ値、Ａ銀行である認証端末（Ａ１）の公開鍵を登録することについて説明する。

まず、複数のコンピュータの中から一のコンピュータをリーダーとして選定し、そのリーダーが下す結論を他のコンピュータが従うものとする。各コンピュータは自分の信頼度スコアがあり、複数のコンピュータは所定の信頼度レートを共有していることから、この信頼度レートを閾値として超えるコンピュータの中から例えば最も信頼度スコアが高いコンピュータをリーダーとして選定する。他の実施形態では、ランダムにリーダーを選定したり、所定の時間が経過すると順繰りにリーダーとなるようにすることもある。

リーダーとなったコンピュータは、他のコンピュータに、各自がユーザＸに関して記録している図３に示す構成の分散型台帳技術（ＤＬＴ）又はブロックチェーンのデータを用いて所定の演算を実行するよう指示する。所定の演算とはハッシュ関数Ｈを用いた数学計算である。例えば、本実施形態では、楕円曲線に基づく公開暗号技術を用い、使用するハッシュ関数Ｈは、５１２ビットのＳＨＡ３である。
秘密鍵Ｋをランダムな２５６ビット整数としたとき、秘密鍵Ｋに対応する公開鍵Ａは、
Ｈ（ｋ）＝（ｈ₀，ｈ₁，…，ｈ₅₁₁） (1)
ａ＝２²⁵⁶＋Σ２ⁱｈ_i（但し、３≦ｉ≦２５３） (2)
Ａ＝ａＢ (3)
の各ステップを実行することにより生成することができる。
ここで、Ｂは、所定の楕円曲線を形成するための基本ポイントの集合であり、膨大な数の要素を有する。Ａは、２５６ビット整数にエンコードされ得る集合Ｂの各要素でもある。このように、Ａは集合Ｂの要素であるため、公開鍵として機能する２５６ビット整数の公開鍵Ａにエンコードされる。

記憶する対象データとしてのメッセージＭ、秘密鍵Ｋ及び関連する公開鍵Ａとしたとき、
Ｈ（ｋ）＝（ｈ₀，ｈ₁，…，ｈ₅₁₁） (4)
ｒ＝Ｈ（ｈ₂₅₆，…，ｈ₅₁₁，Ｍ） (5)
Ｒ＝ｒＢ (6)
Ｓ＝（ｒ+Ｈ（Ｒ，Ａ，Ｍ）ａ） mod q (7)
の各ステップを実行することにより、署名を生成することができる。
また、（Ｒ，Ｓ）は、秘密鍵Ｋの下でのメッセージＭの署名となる。

各コンピュータは、所与のメッセージＭ及び公開鍵Ａに関する署名（Ｒ，Ｓ）を検証するため、Ｒ’＝ＳＢ―Ｈ（Ｒ，Ａ，Ｍ）Ａを計算し、Ｒ’＝Ｒであることを検証する。値が一致するコンピュータの数が所定の数を超えた場合、複数のコンピュータ間で登録の合意が形成されたものとみなし、登録対象にするデータと判定する。なお、合意が形成されなかった場合、そのデータはブロック分散型台帳技術（ＤＬＴ）又はチェーンの一要素として登録されることなく排除される。

なお、上述した各コンピュータによる実行される集団的合意（コンセンサス）に関する数学的演算は、あくまで一例であって上述の手順に限定するものではなく、例えばビットコインで行われるようなProof of Work(POW)の計算の手法を排除するわけではない。
複数のコンピュータが連携して記録対象のデータの正当性に対する集団的合意をとることは、不正データの複製や記憶データの改ざんを発見する上で極めて有効である。

これまで、説明してきた複数のコンピュータによる認証システム１００の構成例を図４（Ａ）及び図４（Ｂ）に示す。図４（Ａ）は、ネットワーク３に複数の認証局の端末Ｙ（１）〜Ｙ（Ｎ）が接続され、端末Ｙ（１）〜Ｙ（Ｎ）それぞれが同一のトランザクションデータを記録してＰ２Ｐ型分散型台帳技術を具現化する例である。一点波線で囲った端末Ｙ（１）〜Ｙ（Ｎ）端末が、特許請求の範囲に記載する「複数のコンピュータ」を指す。

また、図４（Ｂ）のように、端末Ｙ（１）〜Ｙ（Ｎ）以外の端末Ｚ（１）が認証システム１００に含まれることもある。このようなシステム構成の場合、端末Ｙ（１）〜Ｙ（Ｎ）及び端末Ｚ（１）が、特許請求の範囲に記載する「複数のコンピュータ」を指す。なお、端末Ｚが必ず単一であることを要求するものではない。したがって、２以上の第三者的な機関に対応して端末Ｚが複数であってもよい。

端末Ｚ（１）は、第三者的な立場（例えば、犯罪収益の移転を防止する目的で金融機関や認証局等を監督する組織体、本発明に係る認証サービスを提供する会社など）に位置づけられる端末である。分散型台帳として複数のコンピュータに記録される一連のデータ又はトランザクションは、過去の履歴記録が個人の認証事実を示すための証拠となるので、後から記録の改ざんを行なったかのトレースが容易である。法律上の要請から、情報漏洩に関連する事件等が発生した場合や金融機関の監査においては情報の流れを確認する必要があるので、過去の履歴記録を調べ直すことは避けられない。端末Ｚのような第三者的な機関が含まれていると、銀行等が拒否したとしても端末Ｚの記録媒体の履歴をトレースすることで送信記録をチェックでき、透明性が高いシステムを構築することができる。

上述した説明では、Ａ銀行やＢ銀行が、認証局の端末Ｙ（１）〜Ｙ（Ｎ）のいずれかに認証依頼して、ユーザの電子証明書の発行をリクエストするものであったが、Ａ銀行やＢ銀行が認証局の端末Ｙとして機能する場合もある。Ａ銀行及びＢ銀行が上述した認証サービスを利用するには、認証システム１００においてサービス提供事業者としてあらかじめ登録されていることは当然であるが、サービス提供事業者が認証局を構成するコンピュータとして機能してはいけないという制限は本実施形態において設けていない。別の実施形態では、本発明の認証サービス提供事業者（例えば、金融機関）と、認証局は区別するようにしてもよい。

また、端末Ｙ（１）〜Ｙ（Ｎ）及び端末Ｚには所定の実行プログラムがインストールされ、当該実行プログラムが起動することによって、本発明に係る各処理がそれぞれの端末で実行される。その実行プログラムは、端末Ｙ（１）〜Ｙ（Ｎ）及び端末Ｚがネットワーク経由で所定のサイトからダウンロードできるようにしたり、或いは実行プログラムが格納されたＣＤやＵＳＢメモリなどからインストールされるものとする。したがって、本発明は、ＣＤ−ＲＯＭ等の光学ディスク、磁気ディスク、半導体メモリなどの各種の記録媒体を通じて、又は通信ネットワークなどを介してダウンロードすることにより、コンピュータにインストール又はロードしたプログラム、及びこれら記憶媒体を発明の範疇として含む。

本発明に関する認証局システム１００は、中央管理主体を必要としないＰ２Ｐネットワークであって、複数のコンピュータでデータ記録を分散する。これにより、一部のコンピュータがダウンしても、システム全体がダウンしない耐障害性を有するのであり、不稼働時間のない２４時間運用システムの構築を実現する。そして、不正者による改ざんが極めて困難な分散型台帳技術（ＤＬＴ）又はブロックチェーン型のデータ構造であることから高いセキュリティ性のあるシステムを低コストで構築することが可能である。
なお、各コンピュータが各自の記録媒体内に記録する基本４情報は、生データではなくハッシュ化されているため、各コンピュータから基本４情報が読み出されたとしても、解読される事態にはならず、高いセキュリティ性がある。

上述した実施形態では、金融機関に口座を開設するときのユーザの認証について説明してきたが、必ずしも金融機関での認証に限定されるものではない。例えば、医療、通信、不動産、教育、行政、物流、保険、任意の契約、インターネットサービス、シェアリングエコノミーサービスなど様々な分野についても本発明の範疇に含まれる。また、個人情報に限らず、デジタルアセットとして定義可能な情報（例えば、権利や価値記録）を取得する際の認証を任意の機関又は組織で行う場合も本発明の技術的意義が発揮されることになろう。

２ ユーザのＰＣ端末
３ ネットワーク
１００ 認証システム
Ｘ ユーザのモバイル端末
Ｙ 認証局端末
Ｚ 監督組織体又は認証システム提供会社などの端末

Claims (4)

1. ネットワーク上に接続する複数のコンピュータを用いて認証処理を行うためのプログラムであって、
   前記複数のコンピュータに含まれる一のコンピュータは、ユーザ登録のリクエストに応答して、前記ネットワーク上に個人又は組織体を特定する情報を含むデータを出力する処理と、
   前記複数のコンピュータに含まれる前記一のコンピュータ以外の少なくとも１以上のコンピュータは、前記ネットワーク上に出力された前記データを取り込み、同一の演算を実行することによりコンピュータ間の合意形成が得られた場合に前記複数のコンピュータは各自の記録媒体に前記データを記憶する処理と、
   前記複数のコンピュータに含まれる任意のコンピュータが、前記ユーザ登録したユーザの本人認証の要求を事業体又は個人から受けた場合、前記複数のコンピュータの少なくとも１つのコンピュータが自身の記録媒体に前記データが記憶されているか否かを判定する処理と、
   前記データが記憶されていた場合、前記本人認証を要求する事業体又は個人に対し、本人認証済みの報告を送信する処理と、
   が実行されるようにする、プログラム。
2. 前記複数のコンピュータの各コンピュータの記録媒体には、前記データが完全同一で記憶されている、請求項１に記載のプログラム。
3. 前記合意形成の有無は、前記各コンピュータによる演算結果の一致が所定数以上か否かにより決定する、請求項１又は２に記載のプログラム。
4. ネットワーク上に接続する複数のコンピュータを用いた電子認証方法であって、
   前記複数のコンピュータに含まれる一のコンピュータが、ユーザ登録のリクエストに応答して、個人又は組織体を特定する情報を含むデータを、前記複数のコンピュータに含まれる他のコンピュータに送信し、
   前記複数のコンピュータの各コンピュータが、同一の演算を実行することによりコンピュータ間の合意形成が得られた場合に各自の記録媒体に前記データを記憶し、
   前記複数のコンピュータに含まれる任意のコンピュータが、前記ユーザ登録したユーザの本人認証の要求を事業体又は個人から受けた場合、前記複数のコンピュータの少なくとも１つのコンピュータが自身の記録媒体に前記データが記憶されているか否かを判定し、
   前記データが記憶されていた場合、前記本人認証を要求する事業体又は個人に対し、本人認証済みの報告を送信する、
   ことが実行される電子認証方法。

Images