JP6901373B2 - ユーザ管理装置、ユーザ管理システム - Google Patents

Description

本発明は、ユーザ管理装置、及びユーザ管理方法に関する。

金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた取引を、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）によって直接的な取引に代替する技術として、分散台帳技術（又はブロックチェーン技術）がある。特に、ビットコイン（登録商標、以下同）と呼ばれる仮想通貨を用いて、銀行などの中央集権機関を必要としせずに決済取引を行う技術がある。ビットコインでは、Ｐ２Ｐネットワーク上で取引データ（以下、トランザクションとも呼ぶ）をマイナーと呼ばれるノードが正当性を判定した後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行う。確定されたトランザクションは、１つのブロックにまとめられ、ブロックチェーン（以下、ＢＣとも呼ぶ）と呼ばれる分散台帳に記載される。

さらに、近年では、上記のビットコインで実装されたＢＣをベースにして、ＢＣおよび分散台帳に関して様々な派生技術が提案され、進化を続けている。現状のＢＣの主な特徴としては、（１）ＢＣネットワーク上の参加者間の取引において、中央集権機関ではなく（任意又は特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを困難にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすることがある。

このようなＢＣ等の分散台帳技術は、以上のような特徴から、信頼できるデータの管理及び共有や、契約に基づく取引の執行及び管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）等の幅広い分野での応用が検討されている。分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも複数の主体（例えば、特定業界のコンソーシアムやサプライチェーンに関係する複数企業等）間で情報共有や取引を行うことができる。以下、分散台帳に参加する参加者（参加者のノード）によって構成されるネットワークのことをブロックチェーンネットワークとも呼ぶ。

分散台帳は従来ビットコインのような単純な仮想通貨の取引だけでなく、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で（取引）データだけでなくシステムロジック、業務ロジックも管理する。これらのロジックはスマートコントラクト（以下、ＳＣとも呼ぶ）と呼ばれる。

また、ＳＣの実行機能を有する分散台帳基盤に関する技術がある。分散台帳基盤では、ノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも呼ぶ）を受け入れ、各ノードがＴＸを実行することにより、複数のノード上で情報（台帳）を共有する。また、これらのノードは、ＴＸに対して予め決めたロジックを実行するスマートコントラクト（ＳＣ）実行機能を備える。

これらの分散台帳技術を用いて構築されたシステム（以下、分散台帳システム）を本番稼働させるためには、従来型システム（例えばＷｅｂサーバとＤＢサーバとを含むＷｅｂシステム）と同様に、ユーザ管理等のシステム運用管理が必要となる（例えば、台帳のバックアップ及びリストア、並びにサービス停止等も含む）。特開２００６−１８０４７２号公報（特許文献１）には、従来型システムにおけるユーザ管理において実施される電子署名方法が記載されている。具体的には、この公報には、「電子画像を複数の構成要素に分割し、その構成要素それぞれの特徴値を算出し、その特徴値を結合したものから署名を生成する。構成要素を削除する場合は、予め構成要素毎に用意した置換え用データに置換え、特徴値のみ保存する。検証時は、置き換えた構成要素は保存した特徴値を用い、他は改めて算出した特徴値を用い、検証用署名を生成し、電子画像に付与された署名と比較検証を行う。」と記載されている（要約参照）。

特開２００６−１８０４７２号公報

一方、分散台帳システムでは、複数の主体によってコンソーシアム等が構成されることによりＢＣネットワークが構築及び運用される。言い換えると、分散台帳システムは複数の組織にまたがって構成される。このような分散台帳システムに対して従来型システムの運用管理方法として、すべてのノードを単独の運用者が運用管理する第一の方法と、各ノードの運用者（例えば、各組織のノードの所有者）が個別に運用管理する第二の方法と、が考えられる。

第一の方法を用いた場合には、運用が中央集権化してしまい、ＢＣシステムの特徴である非中央集権性の強みが薄れてしまうという問題点がある。また、第一の方法では、マルチベンダでの運用には対応することができない。第ニの方法を用いた場合には、管理者やポリシーが組織ごとに異なるため、同じ取り決めやタイミングで運用できないという問題点がある。特に複数の主体にまたがるコンソーシアム型サービスを利用する際に、ユーザ管理、ユーザ認証をどの主体が行うかが課題となる。

また、分散台帳システムでは、絶対的な権限を持つシステム全体の管理者がいない場合が多く、既存のシステムにおける厳密なユーザ管理及びユーザ認証を、そのまま実施すること及びコンソーシアム全体で共有する事が困難である。従って、特許文献１に記載されているような電子署名を用いたユーザ管理を、分散台帳システムにそのまま適用することは困難である。

この問題に対する単純な解決方法として、分散台帳のスマートコントラクト上にユーザ管理システムを構築し、そこにユーザＩＤ、ユーザの属性情報、及び認証情報などのサービスに必要な情報を記載し、コンソーシアム全体でユーザ情報を共有する事で、非中央集権下においてもユーザ管理を実現する事が可能となる。

しかし、例えば、ユーザの属性情報（例えば、年齢、所属会社名、及び預金額）などは機微な情報である場合もあるため、正当なアクセス権限を持ったコンソーシアムの主体にのみ開示されるべきである。つまり、非中央集権環境の分散台帳上でユーザ情報を管理、運用する際に、その情報に関して適切にアクセス制御を行う必要がある。

上記課題を解決するために、本発明の一態様は以下の構成を採用する。ユーザ管理装置であって、プロセッサとメモリとを含み、前記メモリは、第１の暗号鍵で暗号化された情報を復号する第１の復号鍵、ユーザを識別する識別情報、第２の暗号鍵で暗号化された前記ユーザの属性情報である暗号化属性情報、及び前記暗号化属性情報を参照するための参照情報を示すトランザクションデータと、を保持し、前記参照情報は、前記第１の暗号鍵で暗号化された第２の復号鍵を含み、前記第２の復号鍵は前記第２の暗号鍵で暗号化された情報を復号する鍵であり、前記プロセッサは、前記第１の復号鍵を用いて前記参照情報に含まれる前記第２の復号鍵を取得し、前記第２の復号鍵を用いて前記暗号化属性情報を復号して、前記ユーザの属性情報を取得し、前記取得した属性情報が所定の条件を満たす場合に電子署名を生成し、前記識別情報と前記生成した電子署名とを含む署名トランザクションデータを出力する、ユーザ管理装置。

本発明の一態様によれば、例えば分散台帳のような非中央集権環境において、特定のユーザ管理者及び管理者端末を設置することなく、適切なアクセス制御がなされたユーザ情報の管理を実施することができる。

上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

実施例１におけるユーザ管理システムの構成の一例を示すブロック図である。 実施例１における、ユーザ端末のハードウェア構成の一例を示すブロック図である。 実施例１における事前鍵配布処理の一例を示すシーケンス図である。 実施例１におけるユーザ情報の登録処理、署名処理、検証処理の一例を示すシーケンス図である。 実施例１におけるユーザ情報テーブルのデータフォーマットの一例である。 実施例１における暗号化トランザクションのデータフォーマットの一例である。 実施例１におけるクエリトランザクションのデータフォーマットの一例である。 実施例１における暗号化データのデータフォーマットの一例である。 実施例１における署名トランザクションのデータフォーマットの一例である。 実施例１における暗号化データのデータフォーマットの一例である。 実施例１における暗号化トランザクションの生成処理の一例を示すフローチャートである。 実施例１における署名トランザクションの生成処理の一例を示すフローチャートである。 実施例１におけるユーザ情報テーブルのデータフォーマットの別例である。 実施例１におけるユーザ情報テーブルのデータフォーマットの別例である。

以下、添付図面を参照して本発明の実施形態を説明する。本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。各図において共通の構成については同一の参照符号が付されている。

本実施形態のユーザ管理システムは、非中央集権環境の分散台帳上でユーザ情報を管理及び運用する際に、ユーザ端末は、暗号化した属性情報を分散台帳に登録する。さらに、ユーザ管理システムは、暗号化に利用した鍵を署名者端末の公開鍵で暗号化し分散台帳に登録する。また、ユーザ端末から依頼を受けた署名者端末が属性情報を確認した後に、暗号化された属性情報に電子署名を生成し、分散台帳にその署名を登録する。これにより、署名者端末による認証が完了したことが示される。ユーザの属性情報を検証する検証者端末は、分散台帳上の署名者端末による署名を検証し、当該属性情報に署名者端末による確認が行われたことを検証する。検証者端末は自身の持つポリシーに従い検証の成功及び失敗を判断するため、必ずしも中央集権者を必要としない。

図１は、ユーザ管理システムの構成例を示すブロック図である。ユーザ管理システムは、ユーザ端末１００と、検証者端末２００と、署名者端末３００と、トランザクション承認者端末４００と、を含む。ユーザ管理システムに含まれる各構成は、ネットワーク５００を介して相互に情報を送受信できる。

ユーザ端末１００は、トランザクション承認者端末４００の分散台帳へのユーザ情報の登録を依頼する。ユーザ端末１００は、公開鍵／秘密鍵ペア生成プログラム１１０及び暗号化トランザクション生成プログラム１１１を有する。検証者端末２００は、ユーザ情報の検証を行う。検証者端末２００は、公開鍵／秘密鍵ペア生成プログラム２１０、クエリ生成プログラム２１１、及び検証プログラム２１２を有する。

署名者端末３００は、トランザクション承認者端末４００の分散台帳上のユーザ情報に対する電子署名を行う。署名者端末３００は、公開鍵／秘密鍵ペア生成プログラム３１０、クエリ生成プログラム３１１、及び署名トランザクション生成プログラム３１２を有する。トランザクション承認者端末４００は、分散台帳及びトランザクションの検証及び承認処理を実行し、実行結果に応じて自身が保持するステート情報（本実施例においてはユーザ情報テーブル９００）を更新する。トランザクション承認者端末４００は、公開鍵／秘密鍵ペア生成プログラム４１０、トランザクション承認プログラム４１１、及びユーザ情報テーブル９００を有する。

図２は、ユーザ端末１００のハードウェアの構成の一例を示すブロック図である。なお、検証者端末２００、署名者端末３００、及びトランザクション承認者端末４００のハードウェア構成は、例えば、ユーザ端末１００のハードウェア構成と同様であるため、説明を省略する。ユーザ端末１００は、例えば、ＣＰＵ１０１と、補助記憶装置１０２と、メモリ１０３と、表示装置１０５と、入出力インターフェース１０６と、通信インターフェース１０７と、が内部信号線１０４を介して接続されている計算機によって構成される。

ＣＰＵ１０１はプロセッサを含み、メモリ１０３に格納されたプログラムを実行する。メモリ１０３は、不揮発性の記憶素子であるＲＯＭ及び揮発性の記憶素子であるＲＡＭを含む。ＲＯＭは、不変のプログラム（例えば、ＢＩＯＳ）などを格納する。ＲＡＭは、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のような高速かつ揮発性の記憶素子であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを一時的に格納する。

補助記憶装置１０２は、例えば、磁気記憶装置（ＨＤＤ）、フラッシュメモリ（ＳＳＤ）等の大容量かつ不揮発性の記憶装置であり、ＣＰＵ１０１が実行するプログラム及びプログラムの実行時に使用されるデータを格納する。すなわち、プログラムは、補助記憶装置１０２から読み出されて、メモリ１０３にロードされて、ＣＰＵ１０１によって実行される。

入出力インターフェース１０６は、キーボードやマウスなどが接続され、オペレータからの入力を受けるインターフェースであり、ディスプレイ装置やプリンタなどが接続され、プログラムの実行結果をオペレータが視認可能な形式で出力するインターフェースである。

通信インターフェース１０７は、所定のプロトコルに従って、他の装置との通信を制御するネットワークインターフェース装置である。また、通信インターフェース１０７は、例えば、ＵＳＢ等のシリアルインターフェースを含む。

ＣＰＵ１０１が実行するプログラムは、リムーバブルメディア（ＣＤ−ＲＯＭ、フラッシュメモリなど）又はネットワークを介してユーザ端末１００に提供され、非一時的記憶媒体である不揮発性の補助記憶装置１０２に格納される。このため、ユーザ端末１００は、リムーバブルメディアからデータを読み込むインターフェースを有するとよい。

ユーザ端末１００は、物理的に一つの計算機上で、又は、論理的又は物理的に構成された複数の計算機上で構成される計算機システムであり、同一の計算機上で別個のスレッドで動作してもよく、複数の物理的計算機資源上に構築された仮想計算機上で動作してもよい。他の端末についても同様である。

なお、例えば、ＣＰＵ１０１は、メモリ１０３にロードされた公開鍵／秘密鍵ペア生成プログラム１１０に従って動作することで、公開鍵／秘密鍵ペア生成部として機能し、メモリ１０３にロードされた暗号化トランザクション生成プログラム１１１に従って動作することで、暗号化トランザクション生成部として機能する。他の端末におけるプログラムとＣＰＵとの関係についても同様である。

図５は、トランザクション承認者端末４００が保持する分散台帳上のユーザ管理用のユーザ情報テーブル９００の一例を示す図である。ユーザ情報テーブル９００は、例えば、ユーザ名欄、属性欄、参照可能者欄、及び電子署名欄を含む。各欄についての詳細な説明は図４に示す処理とともに後述する。なお、本実施例においてユーザ名は、ユーザを一意に識別する情報の一例であるものとする。

図３は、ユーザ端末１００と、検証者端末２００と、署名者端末３００と、トランザクション承認者端末４００と、の間で実行される事前鍵配布処理の一例を示すシーケンス図である。

まず、ユーザ端末１００の公開鍵／秘密鍵ペア生成プログラム１１０は、公開鍵である「ｐｋ−ユーザ」と当該公開鍵に対応する秘密鍵である「ｓｋ−ユーザ」とを生成する（Ｓ３０１）。同様に、検証者端末２００の公開鍵／秘密鍵ペア生成プログラム２１０は、公開鍵である「ｐｋ−検証者」と当該公開鍵に対応する秘密鍵である「ｓｋ−検証者」とを生成する（Ｓ３０２）。

同様に、署名者端末３００の公開鍵／秘密鍵ペア生成プログラム３１０は、公開鍵である「ｐｋ−署名者」と当該公開鍵に対応する秘密鍵である「ｓｋ−署名者」とを生成する（Ｓ３０３）。同様に、トランザクション承認者端末４００の公開鍵／秘密鍵ペア生成プログラム４１０は、公開鍵である「ｐｋ−トランザクション承認者」と当該公開鍵に対応する秘密鍵である「ｓｋ−トランザクション承認者」とを生成する（Ｓ３０４）。なお、本実施例における公開鍵と秘密鍵のペアの作成において、例えば、ＲＳＡ暗号や楕円曲線暗号等の手法が用いられる。

次に、ユーザ端末１００の公開鍵／秘密鍵ペア生成プログラム１１０はステップＳ３０１で生成した公開鍵「ｐｋ−ユーザ」を検証者端末２００、署名者端末３００、及びトランザクション承認者端末４００に送信する（Ｓ３０５〜Ｓ３０７）。同様に、検証者端末２００の公開鍵／秘密鍵ペア生成プログラム２１０はステップＳ３０２で生成した公開鍵「ｐｋ−検証者」をユーザ端末１００、署名者端末３００、及びトランザクション承認者端末４００に送信する（Ｓ３０８〜Ｓ３１０）。

同様に、署名者端末３００の公開鍵／秘密鍵ペア生成プログラム３１０はステップＳ３０３で生成した公開鍵「ｐｋ−署名者（Ｄ３００）」をユーザ端末１００、検証者端末２００、及びトランザクション承認者端末４００に送信する（Ｓ３１１〜Ｓ３１３）。次に、トランザクション承認者端末４００の公開鍵／秘密鍵ペア生成プログラム４１０はステップＳ３０４で生成した公開鍵「ｐｋ−トランザクション承認者」をユーザ端末１００、検証者端末２００、及び署名者端末３００に送信し（Ｓ３１４〜Ｓ３１６）、事前鍵配布処理を終える。上記処理により、ユーザ端末１００、検証者端末２００、署名者端末３００、及びトランザクション承認者端末４００、それぞれの端末上で公開鍵と秘密鍵が生成されて、公開鍵が相互に配布される。

図４は、ユーザ管理システムにおけるユーザ情報の登録、署名、及び検証処理の一例を示すシーケンス図である。以下の例ではユーザ端末１００のユーザ名が「Ａｌｉｃｅ」であり、Ａｌｉｃｅの属性情報として年齢「２５歳」が登録される例を示す。本実施例では、ユーザ端末１００が分散台帳へのユーザ情報の登録を行い、署名者端末３００がユーザ情報の確認の後に、分散台帳上のユーザ情報へ、電子署名を行い、検証者端末２００がユーザ情報の検証を行う処理を例示する。

まず、ユーザ端末１００の暗号化トランザクション生成プログラム１１１は、暗号化トランザクション生成処理を実行し、分散台帳に登録する暗号化トランザクションを生成し（Ｓ４０１）、生成した暗号化トランザクションを全てのトランザクション承認者端末４００に送信する（Ｓ４０２）。なお、暗号化トランザクション生成プログラム１１１は、成した暗号化トランザクションを必ずしも全てのトランザクション承認者端末４００に送信しなくてもよく、例えば、予め定められたポリシー、又はユーザ端末１００に入力された指示等に従って、一部のトランザクション承認者端末４００のみに送信してもよい。

図６は、暗号化トランザクションのデータフォーマットの一例である。暗号化トランザクションはユーザ情報テーブル９００と同種のカラムを有する。図６の例ではユーザ端末１００のユーザ名が「Ａｌｉｃｅ」であり、ユーザの属性（図６の例では年齢）が「２５歳」である。図６の例における暗号化トランザクションは、ユーザ名の値として［Ａｌｉｃｅ］、属性の値として［Ｅｎｃ（Ｋ，２５歳）］、参照可能者の値として［Ｐｕｂ−Ｅｎｃ（ｐｋ−署名者，Ｋ），Ｐｕｂ−Ｅｎｃ（ｐｋ−検証者，Ｋ）］、電子署名の値として［−（ブランク）］を保持している。

なお、Ｅｎｃ（Ｋ，Ｘ）は、秘密鍵［Ｋ］によって、平文［Ｘ］が暗号化された共通鍵暗号方式の暗号文を示す。なお、共通鍵暗号方式として、例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号等の既存の方式が用いられる。また、Ｐｕｂ−Ｅｎｃ（ｐｋ−Ｙ，Ｋ）は、公開鍵「ｐｋ−Ｙ」によって、平文［Ｋ］が暗号化された公開鍵暗号方式の暗号文を示す。なお、公開鍵暗号方式として、例えば、ＲＳＡ暗号及び楕円曲線暗号等の既存の方式が用いられる。なお［Ｘ］、［Ｙ］は暗号文であってもよい。

図４の説明に戻る。次に、暗号化トランザクションを受信したトランザクション承認者端末４００のトランザクション承認プログラム４１１は、トランザクション承認処理を実行する（Ｓ４０３）。トランザクション承認プログラム４１１は、承認結果が成功であれば、ステップＳ４０３において、暗号化トランザクションを分散台帳上のユーザ情報テーブル９００に登録する。一方、トランザクション承認プログラム４１１は、承認結果が失敗であれば、受信した暗号化トランザクションをステップＳ４０３において破棄する。なお、トランザクション承認処理の手法については、Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ手法が用いられてもよいし、ＰＢＦＴ（Ｐｒａｃｔｉｃａｌ Ｂｙｚａｎｔｉｎｅ Ｆａｕｌｔ Ｔｏｌｅｌａｎｃｅ）手法が用いられてもよいし、その他の分散台帳向けのトランザクション承認技術が用いられてもよい。

次に、署名者端末３００のクエリ生成プログラム３１１は、分散台帳に登録されているユーザ情報を取得するためのクエリ生成処理においてクエリトランザクションを生成し（Ｓ４０４）、生成したクエリトランザクションを全てのトランザクション承認者端末４００に送信する（Ｓ４０５）。なお、署名者端末３００のクエリ生成プログラム３１１は、成したクエリトランザクションを必ずしも全てのトランザクション承認者端末４００に送信しなくてもよく、例えば、予め定められたポリシー、又は署名者端末３００に入力された指示等に従って、一部のトランザクション承認者端末４００のみに送信してもよい。

なお、クエリ生成プログラム３１１は、ステップＳ４０４〜Ｓ４０５の処理を、例えば、定期的に実行する。また、ユーザ端末１００が暗号化トランザクションを分散台帳に送信した事を署名者端末３００に通知し、当該通知を署名者端末３００が受信した場合に、クエリ生成プログラム３１１は、ステップＳ４０４〜ステップＳ４０５の処理を行ってもよい。

なお、署名者端末３００の補助記憶装置に予めユーザ端末１００のユーザの本人確認用情報（例えば、ユーザの属性情報、及びユーザを識別する情報等）が予め格納されている場合には、ユーザの本人確認が行われてもよい。具体的には、例えば、署名者端末３００のユーザである署名者が電話や対面によって、ユーザ端末１００のユーザの本人確認等を行うことにより、本人確認用情報を取得する。署名者端末３００は、当該取得したユーザの情報の入力を、入力装置を介して受け付ける。この場合、クエリ生成プログラム３１１は、入力されたユーザの情報と、署名者端末３００の補助記憶装置に予め格納されている当該ユーザの情報と、が一致する場合に、クエリトランザクションを生成し、一致しない場合には、例えば、署名者端末３００の表示装置及びユーザ端末１００にエラーを出力する。なお、署名者端末３００のユーザである署名者が当該一致判定の結果を、入力装置等を介して署名者端末３００に直接入力してもよい。

図７は、ステップＳ４０４で生成されるクエリトランザクションのデータフォーマットの一例を示す図である。図７のクエリトランザクションにおいて、ＳＥＬＥＣＴ ＷＨＥＲＥ ユーザ名＝［Ａｌｉｃｅ］と記述されている。つまり、図７のクエリトランザクションは、分散台帳上のユーザ情報テーブル９００のユーザ名である「Ａｌｉｃｅ」に関するレコードを取得するためのクエリトランザクションである。なお、ステップＳ４０４において他のクエリ方式によるクエリトランザクションが生成されてもよい。

図４の説明に戻る。次に、クエリトランザクションを受信したトランザクション承認者端末４００のトランザクション承認プログラム４１１は、受信したクエリトランザクションに対応する暗号化データを分散台帳上のユーザ情報テーブル９００から検索し、当該署名者端末３００に返信する（Ｓ４０６）。なお、ユーザ情報テーブル９００に当該クエリトランザクションに対応する暗号化データが存在しない場合、トランザクション承認プログラム４１１は、当該署名者端末３００にエラーを返信する。

図８は、ステップＳ４０６において送信される暗号化データのデータフォーマットの一例を示す図である。図８の例は、図７の例においてユーザ名が「Ａｌｉｃｅ」であるクエリトランザクションに対する暗号化データの一例であり、ユーザ名の値が「Ａｌｉｃｅ」であるユーザ情報テーブル９００のレコードが暗号化データとして送信されている。

図４の説明に戻る。次に、暗号化データを受信した署名者端末３００の署名トランザクション生成プログラム３１２は、受信した暗号化データを、ステップＳ３０３における公開鍵／秘密鍵ペア生成処理で生成された秘密鍵「ｓｋ−署名者」を用いて復号し、復号の結果得られる平文の属性情報を検証する（Ｓ４０７）。

署名トランザクション生成プログラム３１２は、ステップＳ４０７における検証結果が失敗である場合は、例えば、ユーザ端末１００に対してエラーを通知して、図４の処理を終了する。

ステップＳ４０７において検証結果が成功である場合は、署名トランザクション生成プログラム３１２は、ステップＳ３０４で生成された秘密鍵「ｓｋ−署名者」を用いて、暗号化データに対する電子署名を生成し、生成した電子署名を含む署名トランザクションを生成し、生成した署名トランザクションを、トランザクション承認者端末４００に送信する(Ｓ４０８)。なお、署名トランザクション生成プログラム３１２は、生成した署名トランザクションを必ずしも全てのトランザクション承認者端末４００に送信しなくてもよく、例えば、予め定められたポリシー、又は署名者端末３００に入力された指示等に従って、一部のトランザクション承認者端末４００のみに送信してもよい。

図９は、署名トランザクションのデータフォーマットの一例を示す図である。図９は、ユーザ名の値が「Ａｌｉｃｅ」の属性情報に対する検証結果が成功の場合に生成される署名トランザクションの例である。電子署名欄には、署名者端末３００の秘密鍵である「ｓｋ−署名者」を用いて生成された電子署名の値である［Ｓｉｇｎｅｄ ｂｙ 署名者］が格納されている。

なお、図９の署名トランザクションの例では属性欄及び参照可能者欄がブランクであるが、例えば、属性欄に属性情報（Ａｌｉｃｅの暗号化された属性情報［Ｅｎｃ（Ｋ，２５歳）］又はＡｌｉｃｅの暗号化されていない属性情報［２５歳］）が格納されていてもよい。また、電子署名欄の値である［Ｓｉｇｎｅｄ ｂｙ 署名者］は署名者の公開鍵である「ｐｋ−署名者」を用いて、署名検証が可能である。なお、署名生成及び署名検証には、例えば、ＲＳＡ署名等の既存の方式が用いられてもよい。

図４の説明に戻る。次に、署名トランザクションを受信したトランザクション承認者端末４００のトランザクション承認プログラム４１１は、トランザクション承認処理を実行する（Ｓ４０９）。トランザクション承認プログラム４１１は、承認結果が成功であれば、ステップＳ４０９において、署名トランザクションに格納された電子署名を、分散台帳上のユーザ情報テーブル９００の、署名トランザクションが示すユーザに対応するレコード、に登録する。一方、承認結果が失敗であれば、トランザクション承認プログラム４１１は、受信した暗号化トランザクションを、ステップＳ４０９において破棄する。

次に、検証者端末２００のクエリ生成プログラム２１１は、分散台帳に登録されているユーザ情報を取得するためのクエリ生成処理を実行することによりクエリトランザクションを生成し（Ｓ４１０）、生成したクエリトランザクションをトランザクション承認者端末４００に送信する（Ｓ４１１）。なお、検証者端末２００のクエリ生成プログラム２１１は、生成したクエリトランザクションを必ずしも全てのトランザクション承認者端末４００に送信しなくてもよく、例えば、予め定められたポリシー、又は検証者端末２００に入力された指示等に従って、一部のトランザクション承認者端末４００のみに送信してもよい。

なお、ステップＳ４１０において生成されるクエリトランザクションは、例えば、図６に示されたデータフォーマットを有する。なお、検証者端末２００のクエリ生成プログラム２１１は、ステップＳ４１０〜Ｓ４１１の処理を、例えば、定期的に実行する。また、ユーザ端末１００が暗号化トランザクションを分散台帳に送信した事を検証者端末２００に通知し、クエリ生成プログラム２１１は当該通知を受信した場合にステップＳ４１０〜ステップＳ４１１の処理を行ってもよい。

次に、ステップＳ４１１で送信されたクエリトランザクションを受信したトランザクション承認者端末４００のトランザクション承認プログラム４１１は、受信したクエリトランザクションに対応する暗号化データを、ユーザ情報テーブル９００から検索し、当該検証者端末２００に返信する（Ｓ４１２）。なお、ユーザ情報テーブル９００に当該クエリトランザクションに対応する暗号化データが存在しない場合、トランザクション承認プログラム４１１は、当該検証者端末２００にエラーを返信する。

図１０は、ステップＳ４１１で送信される暗号化データデータフォーマットの一例を示す図である。図１０の例は、図９の例においてユーザ名が「Ａｌｉｃｅ」であるクエリトランザクションに対する暗号化データの一例であり、ユーザ名の値が「Ａｌｉｃｅ」であるユーザ情報テーブル９００のレコードが暗号化データとして送信されているなお、ステップＳ４０８において署名トランザクションを受信したため、ユーザ情報テーブル９００のユーザ名が［Ａｌｉｃｅ］であるレコードの電子署名欄の更新が行われている。従って、図８の暗号化データにおいて電子署名欄はブランクであったが、図１０の暗号化データにおいては、電子署名欄に［Ｓｉｇｎｅｄ ｂｙ 署名者］が格納されている。

図４の説明に戻る。次に、トランザクション承認者端末４００から暗号化データを受信した検証者端末２００の検証プログラム２１２は、ステップＳ３０２で生成された秘密鍵「ｓｋ−検証者」を用いて、受信した暗号化データを復号し、復号した平文の属性情報を検証する（Ｓ４１３）。

なお、ステップＳ４１３の属性情報の検証において、検証プログラム２１２は、例えば、平文の属性情報が予め定められた条件を満たすか否か（例えば、属性情報が年齢を示す場合には、年齢が所定の範囲に含まれるか（例えば２０歳以上かつ６０歳以下等）等）を検証する。また、ステップＳ４１３において、検証プログラム２１２は、受信した暗号化データに含まれる電子署名の検証を行う。ステップＳ４１３において、検証結果が失敗である場合、検証プログラム２１２は、検証者端末２００の表示装置等にエラーを出力して処理を終了し、検証結果が成功である場合、検証プログラム２１２は、検証結果が成功であることを示す表示を検証者端末２００の表示装置等に出力し処理を終了する。

本実施例のユーザ管理システムは、図４に示す処理によって、分散台帳上においても、特定のユーザ管理者及び管理者端末を設置することなく、適切なアクセス制御がなされたユーザ情報の管理を実施することができる。

図１１は、ステップＳ４０１における暗号化トランザクションの生成処理の詳細の一例を示すフローチャートである。まず、ユーザ端末１００の暗号化トランザクション生成プログラム１１１は、例えば、ユーザ端末１００に対応するユーザ名である［Ａｌｉｃｅ］を出力し、ユーザ名を設定する（Ｓ１１０１）。なお、ユーザ端末１００は、例えば、入力装置等を介して、ユーザからユーザ名の入力を受け付けてもよい。

次に、暗号化トランザクション生成プログラム１１１は、共通鍵生成アルゴリズムを実行し、属性情報暗号化用の共通鍵である［Ｋ］を生成し、出力する（Ｓ１１０２）。

次に、暗号化トランザクション生成プログラム１１１は、「Ａｌｉｃｅ」の平文の属性値である年齢［２５歳］を、共通鍵暗号アルゴリズムと共通鍵である「Ｋ」を用いて暗号化することにより属性値［Ｅｎｃ（Ｋ，２５歳）］を生成し、出力する（Ｓ１１０３）。

次に、暗号化トランザクション生成プログラム１１１は、ユーザの暗号化された属性を参照可能な参照可能者を設定する（Ｓ１１０４）。ここでは、署名者端末３００及び検証者端末２００が参照可能者である例を説明する。ステップＳ１１０４において、暗号化トランザクション生成プログラム１１１は、参照可能者を示す情報の入力を、例えば入力装置等を介して、受け付ける。

ステップＳ１１０４において、暗号化トランザクション生成プログラム１１１は、署名者端末３００の公開鍵である「ｐｋ−署名者」で共通鍵「Ｋ」を暗号化した暗号文［Ｐｕｂ−Ｅｎｃ（ｐｋ−署名者，Ｋ）］を生成し、さらに検証者端末２００の公開鍵である「ｐｋ−検証者」で共通鍵「Ｋ」を暗号化した暗号文［Ｐｕｂ−Ｅｎｃ（ｐｋ−検証者，Ｋ）］を生成し、これらの暗号文を参照可能者として出力する。

次に、暗号化トランザクション生成プログラム１１１は、上記の出力値を、暗号化トランザクションの各データフィールドに格納し（Ｓ１１０５）、暗号化トランザクションの生成処理を終了する。つまり、暗号化トランザクション生成プログラム１１１は、ユーザ名＝［Ａｌｉｃｅ］、属性＝［Ｅｎｃ（Ｋ，２５歳）］、参照可能者＝［Ｐｕｂ−Ｅｎｃ（ｐｋ−署名者，Ｋ）］、［Ｐｕｂ−Ｅｎｃ（ｐｋ−検証者，Ｋ）］、及び電子署名＝［−］（［−］はブランクを示す）を、暗号化トランザクション内の各データフィールドに格納する。

図１２は、ステップＳ４０７における署名トランザクション生成処理の詳細の一例を示すフローチャートである。以下、図８における暗号化データに対する署名トランザクション生成処理について説明する。

まず、署名者端末３００の署名トランザクション生成プログラム３１２は、暗号化データをトランザクション承認者端末４００から受信し（Ｓ１２０２）、復号処理を実行する（Ｓ１２０２）。署名トランザクション生成プログラム３１２は、ステップＳ１２０２において、暗号化データの参照可能者欄に格納されている［Ｐｕｂ−Ｅｎｃ（ｐｋ−署名者，Ｋ）］を署名者端末３００の秘密鍵「ｓｋ−署名者」で復号し、共通鍵「Ｋ」を得る。

次に、署名トランザクション生成プログラム３１２は、ステップＳ１２０２で取得した共通鍵「Ｋ」を用いて、暗号化データの属性［Ｅｎｃ（Ｋ，２５歳）］を復号して、平文２５歳を出力して、当該平文である属性の検証処理を実行する（Ｓ１２０３）。署名トランザクション生成プログラム３１２は、検証処理として、例えば、平文である属性と、予め署名者端末３００が保持する当該ユーザ（ここでは「Ａｌｉｃｅ」）の属性と、が一致する場合に検証に成功したと判定し、一致しない場合に検証に失敗したと判定する。また、検証処理において、ユーザ端末１００に対応するユーザＡｌｉｃｅに対して、署名者端末３００のユーザが、電話や対面によってユーザ端末１００のユーザＡｌｉｃｅの本人確認等を行った上で得た検証結果を、署名者端末３００に入力してもよい。

なお、検証処理には、属性情報に限らず、ユーザを特定する情報を用いることができる。つまり、ユーザを特定する情報が暗号化データに含まれていれば、検証処理に当該情報が用いられてもよい。署名トランザクション生成プログラム３１２は、検証結果が失敗であると判定した場合（Ｓ１２０３：検証失敗）、例えば、署名者端末３００の表示装置及びユーザ端末１００にエラーを出力して（Ｓ１２０４）、署名トランザクション生成処理を終了する。

署名トランザクション生成プログラム３１２は、検証結果が失敗であると判定した場合（Ｓ１２０３：検証成功）、署名生成処理を実行する（Ｓ１２０５）。ステップＳ１２０５において、署名トランザクション生成プログラム３１２は、電子署名の対象データであるユーザ名［Ａｌｉｃｅ］と属性：［Ｅｎｃ（Ｋ，２５歳）］に対して、電子署名アルゴリズムと秘密鍵「ｓｋ−署名者」とを用いて電子署名［Ｓｉｇｎｅｄ ｂｙ 署名者］を生成して、電子署名：［Ｓｉｇｎｅｄ ｂｙ 署名者］を出力する。次に、署名トランザクション生成プログラム３１２は、署名トランザクションデータの各データフィールドに、ユーザ名＝［Ａｌｉｃｅ］及び電子署名＝［Ｓｉｇｎｅｄ ｂｙ 署名者］を格納して（Ｓ１２０６）、署名トランザクション生成処理を終了する。

図１３は、ユーザ情報テーブル９００の他の例を示す図である。図５のユーザ情報テーブル９００は、属性欄を１つだけ有しているが、図１３のユーザ情報テーブル９００は、複数の属性欄（属性１欄、・・・、属性ｎ欄）を有することにより、複数種類の属性を格納することができる。

図１４は、ユーザ情報テーブル９００の他の例を示す図である。図１４の例では、ユーザ情報テーブル９００の同一のレコードに格納されている属性が、異なる暗号化方式及び／又は暗号鍵を用いて暗号化されている。具体的には、図１４のユーザ情報テーブル９００の最上段のレコードにおいて、属性１欄はＥｎｃ_１（Ｋ_１，２５歳）、・・・、属性ｎ欄はＥｎｃ_ｎ（Ｋ_ｎ，女性）といったように、属性ごとに異なる共通鍵／公開鍵暗号化方式及び／又は暗号鍵を用いて暗号化されている。

また、例えば、ユーザ情報テーブル９００において属性ごとに異なる参照可能者が、設定されてもよい。つまり、ユーザ端末１００は、参照可能者欄のデータフィールドの参照可能者ごとに、異なる復号鍵が登録することにより、属性ごとにアクセス権限を設定してもよい。

また、さらに属性を暗号化する方式として、暗号文を別の暗号化方式で暗号化するなどの多重暗号化が用いられてもよい。具体的には、例えば、平文である年齢「２５歳」を第１の共通鍵で暗号化すると暗号文「２０歳以上」が生成され、暗号文「２０歳以上」を第２の共通鍵で暗号化すると年齢を示唆しない暗号文が生成される場合を想定する。ユーザ端末１００は、例えば、第１の共通鍵及び第２の共通鍵を取得可能な参照可能者、第２の共通鍵のみを取得可能な参照可能者、及び第１の共通鍵及び第２の共通鍵のいずれも取得できない参照可能者を決定することにより、同一の属性情報におけるアクセスレベルを設定することができる。

また、ステップＳ４０７において、署名トランザクション生成プログラム３１２は、この際に特開２００６−１８０４７２号公報に記載の墨塗り署名技術を用いて、署名を生成してもよい。これにより、例えば、トランザクション承認者端末４００は、署名者端末３００が署名を行った後に暗号文の開示範囲を変更することができる。

つまり、例えば、署名トランザクション生成プログラム３１２は、全ての範囲を墨塗りした状態でも署名検証が可能な墨塗り署名を付与し、検証者端末２００から一部の属性情報の開示の要求又は指定を受けた後に、当該一部の範囲を開示してもよい。また、この場合、署名トランザクション生成プログラム３１２は、暗号文の当該一部が検証者端末２００に開示された状態で署名検証が可能な墨塗り署名を、予め検証者端末２００が検証可能なように電子署名欄に格納してもよい。

また、ステップＳ４０１において、暗号化トランザクション生成プログラム１１１は、検索可能暗号や関数型暗号を用いて、暗号化を実行してもよい、またこの場合に、トランザクション承認者端末４００は、暗号化された属性のデータフィールドに対して例えば特開２０１２−１２３６１４号公報に記載の方法で暗号文の検索処理を行ってもよいし、ユーザ端末１００は例えば特開２０１２−１３３２１４号公報に記載の方法で暗号文に対するアクセス権限のコントロールを行ってもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることも可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１００ ユーザ端末、１０１ ＣＰＵ、１０２ 補助記憶装置、１０３ メモリ、１１０ 暗号化トランザクション生成プログラム、２００ 検証者端末、２１２ 検証プログラム、３００ 署名者端末、署名トランザクション生成プログラム、４００ トランザクション承認者端末、４１１ トランザクション承認プログラム、９００ ユーザ情報テーブル

Claims (10)

1. ユーザ管理装置であって、
   プロセッサとメモリとを含み、
   前記メモリは、
   第１の暗号鍵で暗号化された情報を復号する第１の復号鍵と、
   ユーザを識別する識別情報、第２の暗号鍵で暗号化された前記ユーザの属性情報である暗号化属性情報、及び前記暗号化属性情報を参照するための参照情報を示すトランザクションデータと、を保持し、
   前記参照情報は、前記第１の暗号鍵で暗号化された第２の復号鍵を含み、
   前記第２の復号鍵は前記第２の暗号鍵で暗号化された情報を復号する鍵であり、
   前記プロセッサは、
   前記第１の復号鍵を用いて前記参照情報に含まれる前記第２の復号鍵を取得し、
   前記第２の復号鍵を用いて前記暗号化属性情報を復号して、前記ユーザの属性情報を取得し、
   前記取得した属性情報が所定の条件を満たす場合に電子署名を生成し、
   前記識別情報と前記生成した電子署名とを含む署名トランザクションデータを出力する、ユーザ管理装置。
2. 請求項１に記載のユーザ管理装置であって、
   前記トランザクションデータは、分散台帳を構成する複数の計算機に含まれる第１計算機から前記プロセッサが受信したデータであり、
   前記プロセッサは、前記署名トランザクションデータを、前記第１計算機に対して出力する、ユーザ管理装置。
3. 請求項２に記載のユーザ管理装置であって、
   前記トランザクションデータは、ユーザ端末が生成したデータであり、
   前記第１の暗号鍵は、前記ユーザ端末の共通鍵である、ユーザ管理装置。
4. 請求項１に記載のユーザ管理装置であって、
   前記第１の暗号鍵は、前記ユーザ管理装置の公開鍵であり、
   前記第１の復号鍵は、前記ユーザ管理装置の秘密鍵である、ユーザ管理装置。
5. 請求項１に記載のユーザ管理装置であって、
   前記トランザクションデータは、それぞれ異なる暗号鍵で暗号化された複数種類の暗号化属性情報を含み、
   前記複数種類の暗号化属性情報は、前記第２の暗号鍵で暗号化された暗号化属性情報を含む、ユーザ管理装置。
6. ユーザ管理装置によるユーザ管理方法であって、
   前記ユーザ管理装置は、
   第１の暗号鍵で暗号化された情報を復号する第１の復号鍵と、
   ユーザを識別する識別情報、第２の暗号鍵で暗号化された前記ユーザの属性情報である暗号化属性情報、及び前記暗号化属性情報を参照するための参照情報を示すトランザクションデータと、を保持し、
   前記参照情報は、前記第１の暗号鍵で暗号化された第２の復号鍵を含み、
   前記第２の復号鍵は前記第２の暗号鍵で暗号化された情報を復号する鍵であり、
   前記ユーザ管理方法は、
   前記ユーザ管理装置が、
   前記第１の復号鍵を用いて前記参照情報に含まれる前記第２の復号鍵を取得し、
   前記第２の復号鍵を用いて前記暗号化属性情報を復号して、前記ユーザの属性情報を取得し、
   前記取得した属性情報が所定の条件を満たす場合に電子署名を生成し、
   前記識別情報と前記生成した電子署名とを含む署名トランザクションデータを出力する、ユーザ管理方法。
7. 請求項６に記載のユーザ管理方法であって、
   前記トランザクションデータは、分散台帳を構成する複数の計算機に含まれる第１計算機から前記ユーザ管理装置が受信したデータであり、
   前記ユーザ管理方法は、前記ユーザ管理装置が、前記署名トランザクションデータを、前記第１計算機に対して出力する、ユーザ管理方法。
8. 請求項７に記載のユーザ管理方法であって、
   前記トランザクションデータは、ユーザ端末が生成したデータであり、
   前記第１の暗号鍵は、前記ユーザ端末の共通鍵である、ユーザ管理方法。
9. 請求項６に記載のユーザ管理方法であって、
   前記第１の暗号鍵は、前記ユーザ管理装置の公開鍵であり、
   前記第１の復号鍵は、前記ユーザ管理装置の秘密鍵である、ユーザ管理方法。
10. 請求項６に記載のユーザ管理方法であって、
    前記トランザクションデータは、それぞれ異なる暗号鍵で暗号化された複数種類の暗号化属性情報を含み、
    前記複数種類の暗号化属性情報は、前記第２の暗号鍵で暗号化された暗号化属性情報を含む、ユーザ管理方法。

Images