JP7047760B2 - システム、データ管理方法及びプログラム - Google Patents

システム、データ管理方法及びプログラム Download PDF

Info

Publication number
JP7047760B2
JP7047760B2 JP2018530424A JP2018530424A JP7047760B2 JP 7047760 B2 JP7047760 B2 JP 7047760B2 JP 2018530424 A JP2018530424 A JP 2018530424A JP 2018530424 A JP2018530424 A JP 2018530424A JP 7047760 B2 JP7047760 B2 JP 7047760B2
Authority
JP
Japan
Prior art keywords
taxi
data
public key
group signature
operation management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018530424A
Other languages
English (en)
Other versions
JPWO2018021535A1 (ja
Inventor
和恵 佐古
勇 寺西
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JPWO2018021535A1 publication Critical patent/JPWO2018021535A1/ja
Application granted granted Critical
Publication of JP7047760B2 publication Critical patent/JP7047760B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Operations Research (AREA)

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１６－１５０１００号（２０１６年７月２９日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、システム、データ管理方法及びプログラムに関する。特に、複数のノードが含まれ、各ノードのそれぞれがデータを送信するシステム、データ管理方法及びプログラムに関する。
ネットワーク技術、情報処理技術の向上により、競合関係にあるような複数の企業が連携し、利便性の高いサービスの提供を行うことがある。上記サービスの一例として、スマートフォン等の端末を用いたタクシー配車システムが挙げられる。タクシー配車システムには複数のタクシー会社が参加し、各タクシー会社のタクシーは、専用のタクシーメータ等を用いて自車の現在位置等を含むデータ（運用管理データ）を管理システム（配車サーバ）に送信するように構成されている。
管理システムは、運用管理データにより各タクシーの現在位置を把握する。また、各タクシー会社も運用管理データにアクセスし、自社のタクシーの運行状況等の把握に利用する。上記システム構成において、顧客が自身の端末を操作してタクシーの配車を依頼すると、管理システムは、サービス提供エリア内の顧客に近いタクシーを選択し、上記顧客の迎車を指示する。
上記タクシー配車システムでは、スマートフォン等に接続したタクシーメータを使用することが想定され、既存のモバイル回線等を介して運用管理データを送受信することが求められる。その際、運用管理データを送信する主体の正当性の保証（即ち、各タクシーの認証）が必要となる。このような正当性の保証に関し、デジタル署名を使用することが考えられる。
特許文献１には、委託者がアウトソーシング業者に会員情報を渡さずに、会員向けサービスをアウトソーシング業者に委託できるサービス提供システムが開示されている。特許文献１には、グループ署名方式を用いることによって、利用者装置が委託者装置の会員であるか否かを、委託者装置の公開情報のみで検証する、と記載されている。
特許文献２には、ユーザ装置のグループへの登録やグループからの脱退の際における情報処理の計算量を低減したグループ署名システム、および情報処理方法を提供する、と記載されている。
非特許文献１には、Camenisch-Grothの方式と称されるグループ署名の一方式が開示されている。また、非特許文献２には、非特許文献１にて開示されたCamenisch-Grothの方式の概要が説明されている。
特開２００７－００４４６１号公報 特許第５０９９００３号公報
Jan Camenisch. Jens Groth. Group Signatures, "Better Efficiency and New Theoretical Aspects" SCN 2004, vol. 3352 of LNCS, pp. 120-133, 2004 佐古和恵、米沢祥子、古川潤、"セキュリティとプライバシを両立させる匿名認証技術について"、情報処理学会誌、Vol. 47, No.4, pp.410-416, 2006.4
なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。
上述のように、運用管理データを送信する主体の正当性の保証に関し、タクシーメータが運用管理データを送信する際、公開鍵基盤（ＰＫＩ；Public Key Infrastructure）によるデジタル署名を添付することが考えられる。管理システムは、当該デジタル署名を検証することで、各タクシーの正当性を確認することができる。つまり、運用管理データを受け入れる管理システムは、当該運用管理データに付されたデジタル署名を検証することで、各タクシーの正当性を検証する。
一方で、デジタル署名を用いると、自社のタクシーに関する情報が他社に知られてしまうという問題が生じ得る。各タクシー（タクシーメータ）が付与したデジタル署名の検証には、当該タクシーの公開鍵が必要となる。また、公開鍵の所有者（タクシー）がタクシー配車システムへの参加資格を有するタクシーであることが確認可能であることが求められ、上記公開鍵の電子証明書（公開鍵証明書）には少なくともタクシーの所属会社等に関する情報が含まれている必要がある。
公開鍵が同じであればその所有者たるタクシーも同一であるので、公開鍵証明書からタクシーの所属会社が判明すると、各タクシー会社に所属するタクシーの数や運行履歴が特定され得る。例えば、デジタル署名が付与された複数の運用管理データからＡ社に所属すると判明した運用管理データを抽出し、且つ、抽出された運用管理データに適用された公開鍵の数を計数することで、タクシー配車システムに参加しているＡ社のタクシーの台数が判明する。このように、運用管理データの正当性保証にデジタル署名を用いると、運用管理データや公開鍵証明書を利用することで、競合他社が所有するタクシーの台数等が把握され得る。タクシー配車システムに参加している各タクシー会社は、本来、競合関係にあり、上記のような情報が他社に知られることは望ましくない。競合関係にあるような複数の会社、企業が連携してサービスを提供するようなシステムの場合、取得するデータの正当性検証と把握可能な情報の制限が望まれる。
本発明は、データの正当性を検証可能としつつ、当該データから得られる情報を適切に制限する、システム、データ管理方法及びプログラムを、提供することを目的とする。
本発明の第１の視点によれば、グループ署名が付与されたデータを送信する、複数のノードと、相互に直接接続されている、複数の管理サーバと、を含み、前記複数の管理サーバのそれぞれは、前記ノードから受信したデータを管理するための台帳を有し、前記複数の管理サーバのうち少なくとも１つの管理サーバによる前記台帳へのデータの追記は他の管理サーバの台帳に反映される、システムが提供される。
本発明の第２の視点によれば、それぞれがグループに属する、複数のノードと、それぞれのグループに属するノードを管理する、複数のノード管理サーバと、前記複数のノードそれぞれに対し、グループ署名を生成する際に用いるメンバ証明書を発行すると共に、管理者公開鍵を公開する証明書管理サーバと、を含み、前記複数のノード管理サーバのそれぞれは、特権者公開鍵を公開し、前記ノードは、データに付与するグループ署名の生成を、少なくとも前記管理者公開鍵と前記複数のノード管理サーバのそれぞれが公開する特権者公開鍵を用いて行う、システムが提供される。
本発明の第３の視点によれば、複数のノードと、相互に直接接続され、前記ノードから受信したデータを管理するための台帳を有する、複数の管理サーバと、を含むシステムにおいて、前記ノードが、グループ署名が付与されたデータを送信するステップと、前記管理サーバが、前記グループ署名が付与されたデータを受信するステップと、前記管理サーバが、前記受信したデータを前記台帳に追記するステップと、前記複数の管理サーバのうち少なくとも１つの管理サーバによる前記台帳へのデータの追記を、他の管理サーバの台帳に反映するステップと、を含む、データ管理方法が提供される。
本発明の第４の視点によれば、他の管理サーバと相互に直接接続され、ノードから受信したデータを管理するための台帳を有する管理サーバに搭載されたコンピュータに実行させるプログラムであって、前記ノードが送信する、グループ署名が付与されたデータを受信する処理と、前記受信したデータを前記台帳に追記する処理と、前記他の管理サーバの台帳へのデータの追記を、自装置の台帳に反映する処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。
本発明の各視点によれば、データの正当性を検証可能としつつ、当該データから得られる情報を適切に制限することに寄与する、システム、データ管理方法及びプログラムが、提供される。
一実施形態の概要を説明するための図である。 第１の実施形態に係るタクシー配車システムのシステム構成の一例を示す図である。 第１の実施形態に係る配車サーバのハードウェア構成の一例を示すブロック図である。 第１の実施形態に係るタクシーの概略構成の一例を示す図である。 第１の実施形態に係る配車サーバの処理構成の一例を示すブロック図である。 第１の実施形態に係る運用管理サーバの処理構成の一例を示すブロック図である。 第１の実施形態に係るタクシーメータの処理構成の一例を示すブロック図である。 運用管理データの一例を示す図である。 グループ署名の生成を説明するための図である。 グループ署名の生成を説明するための図である。 第１の実施形態に係る管理サーバの処理構成の一例を示すブロック図である。 管理サーバが生成するブロックの一例を示す図である。 第１の実施形態に係る管理サーバの動作の一例を示すシーケンス図である。 第１の実施形態に係るタクシー配車システムにおけるセットアップ動作の一例を示すシーケンス図である。 第１の実施形態に係るタクシー配車システムの運用時に係る動作の一例を示すシーケンス図である。 第２の実施形態に係るタクシー配車システムのシステム構成の一例を示す図である。 第２の実施形態に係る証明書管理サーバの処理構成の一例を示す図である。 第２の実施形態に係る運用管理サーバの処理構成の一例を示す図である。 第２の実施形態に係るグループ署名の生成を説明するための図である。 第２の実施形態に係るグループ署名の生成を説明するための図である。
初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。
一実施形態に係るシステムは、グループ署名が付与されたデータを送信する、複数のノード１０１と、相互に直接接続されている、複数の管理サーバ１０２と、を含む（図１参照）。複数の管理サーバ１０２のそれぞれは、ノード１０１から受信したデータを管理するための台帳を有する。複数の管理サーバ１０２のうち少なくとも１つの管理サーバ１０２による台帳へのデータの追記は他の管理サーバ１０２の台帳に反映される。
上記一実施形態に係るシステムでは、データに付与されたグループ署名により当該データを生成した主体の正当性を検証可能としている。また、グループ署名から得られる情報は、当該グループ署名を生成した主体が属するグループ（企業、団体）に限られ、当該生成主体を一意に特定することはできない。従って、データ及びその署名から得られる情報が適切に制限される。
以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。
［第１の実施形態］
第１の実施形態に係るシステムについて、図面を用いてより詳細に説明する。第１の実施形態では、タクシー配車システムを例に取り説明する。しかし、本願開示が適用可能なシステムをタクシー配車システムに限定する趣旨ではない。管理するデータの正当性を検証可能としつつ、当該データから得られる情報を適切に制限する必要のあるシステムであれば、どのようなシステムであってもよい。
例えば、タクシーの配車に係るシステム以外にも、タクシーメータから取り出すことのできる走行データを活用したタクシー料金事前予測システム、タクシー料金決定システム又は所要時間予測システム等が、上記要件に該当する。
あるいは、上記システムとして、複数の自動車メーカが提供する、電気自動車の充電システムが挙げられる。当該充電システムでは、充電システムを利用しようとしている自動車の資格（充電システムに参加している自動車メーカの自動車であるか否か）を検証する必要があるが、実際に充電システムを利用した自動車を特定する必要はなく、上記要件に適合する。
［システム構成概略］
図２は、第１の実施形態に係るタクシー配車システムのシステム構成の一例を示す図である。図２を参照すると、タクシー配車システムは、配車サーバ１０と、運用管理サーバ２０－１～２０－α（αは正の整数、以下同じ）と、各タクシー会社に所属するタクシー３０－１～３０－β（βは正の整数、以下同じ）と、データ管理システム４０と、を含んで構成される。なお、以降の説明において、運用管理サーバ２０－１～２０－αのそれぞれを区別する特段の必要がない場合には、単に「運用管理サーバ２０」と表記する。同様に、タクシー３０－１～３０－βのそれぞれを区別する特段の理由がない場合には、単に「タクシー３０」と表記する。
配車サーバ１０、運用管理サーバ２０及びデータ管理システム４０のそれぞれは、インターネット等のネットワークを介して相互に接続されている。また、タクシー３０は、モバイル回線等を利用してネットワークに接続可能に構成されている。
配車サーバ１０は、タクシー協会等に設置されるサーバである。配車サーバ１０は、タクシー配車システムの主たる機能の実現を担う装置である。具体的には、配車サーバ１０は、データ管理システム４０により管理される運用管理データを参照し、配車の依頼を行った顧客（より正確には顧客が使用する端末）に近いタクシー３０を選択する。その後、配車サーバ１０は、選択したタクシーに対し、顧客の位置を指定しつつ迎車指示を行う。
運用管理サーバ２０は、複数のタクシー会社が参加するタクシー配車システムにおいて自社のタクシー３０を管理するための装置である。運用管理サーバ２０は、タクシー３０をシステムに含まれるノードとした場合の「ノード管理サーバ」に相当する。運用管理サーバ２０は、自社のタクシー３０がタクシー配車システムに参加するのに（システムのメンバとなるのに）必要な手続、準備を行う。具体的には、運用管理サーバ２０は、自社のタクシー３０が運用管理データをデータ管理システムに送信する際に付与するグループ署名に必要な情報の生成等を行う。また、運用管理サーバ２０は、データ管理システム４０が提供する電子掲示板に格納されている運用管理データを参照し、自社のタクシーに関する運用状況を管理する機能も有する。
タクシー３０は、上記ノード１０１に相当する。タクシー３０は、タクシー配車システムに参加している複数のタクシー会社（グループ）のうち、いずれかのタクシー会社に属している。
タクシー３０には、スマートフォン等の端末を利用するタクシーメータが搭載されている。当該タクシーメータは、運用管理データを生成し、当該生成したデータをデータ管理システム４０に向けて送信する。その際、タクシーメータは、当該送信する運用管理データにグループ署名を付与してデータ管理システム４０に送信する。また、タクシーメータは、配車サーバ１０から自車向けの迎車指示を取得すると、当該迎車指示をディスプレイに表示し、運転手に通知する。
データ管理システム４０は、タクシー協会や各タクシー会社から独立した立場の機関等が運営するシステムである。データ管理システム４０は、外部（第３者）に対し追記及び読み出しの可能な電子掲示板を提供するシステムである。データ管理システム４０は、所謂、ブロックチェーンにより運用管理データを初めとした各種情報を管理する。
データ管理システム４０は、所定の手数料を支払うことで、どのような主体でも情報を追記できると共に、書き込まれた情報を読み出すことができ、且つ、一度書き込まれた情報は消去されたり改ざんされたりすることのない電子掲示板を提供する。より正確には、データ管理システム４０は、外部装置からは電子掲示板のように扱うことのできるデータ入出力に係るインターフェイスを提供するシステムである。
図２に示すタクシー配車システムでは、タクシーの配車に必要な情報（即ち、運用管理データ）の授受を、データ管理システム４０が提供する電子掲示板を介して行う。なお、上述のように、データ管理システム４０は、第３者に電子掲示板を提供するシステムであるため、当該電子掲示板には上記運用管理データとは無関係なデータ（例えば、タクシーの配車とは無関係な商品売上データ等）が混在することとなる。
データ管理システム４０は、複数の管理サーバ５０－１～５０－４から構成されている。なお、図２の例示は、データ管理システム４０を構成する管理サーバの台数を４台に限定する趣旨ではない。データ管理システム４０は２台以上の管理サーバを含んで構成されていればよい。また、運用管理サーバ２０等と同様に、管理サーバ５０－１～５０－４を区別する特段の理由がない場合には、単に「管理サーバ５０」と表記する。
データ管理システム４０をなす複数の管理サーバ５０は、図２に示すように、相互に直接接続されている。即ち、データ管理システム４０は、Ｐ２Ｐ（Peer to Peer）接続された複数の管理サーバ５０を含んで構成される。
データ管理システム４０では、Ｐ２Ｐ接続された複数の管理サーバ５０それぞれが、外部から受信したデータ（運用管理データや売上データ等）を管理するための台帳（以下、データ管理台帳と表記する）を有する。データ管理システム４０は、当該データ管理台帳を複数の管理サーバ５０に分散し共有し、管理する。
以降の説明において、データ管理システム４０とその外部とのデータの授受は、データ管理システム４０と、配車サーバ１０、運用管理サーバ２０及びタクシー３０の間に限って説明する。但し、実際には、データ管理システム４０は、汎用的な電子掲示板を広く第３者に提供するものであるため、配車サーバ１０等以外との間でもデータの授受が行われる。
［ハードウェア構成］
次に、第１の実施形態に係るタクシー配車システムを構成する各種装置のハードウェア構成を説明する。図３は、第１の実施形態に係る配車サーバ１０のハードウェア構成の一例を示すブロック図である。
配車サーバ１０は、情報処理装置（コンピュータ）により構成可能であり、図３に例示する構成を備える。例えば、配車サーバ１０は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）１１、メモリ１２、入出力インターフェイス１３及び通信手段であるＮＩＣ（Network Interface Card）１４等を備える。
但し、図３に示す構成は、配車サーバ１０のハードウェア構成を限定する趣旨ではない。配車サーバ１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス１３を備えていなくともよい。また、配車サーバ１０に含まれるＣＰＵ等の数も図３の例示に限定する趣旨ではなく、例えば、複数のＣＰＵが配車サーバ１０に含まれていてもよい。
メモリ１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）である。
入出力インターフェイス１３は、図示しない表示装置や入力装置のインターフェイスとなる手段である。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。
配車サーバ１０の機能は、後述する各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ１２に格納されたプログラムをＣＰＵ１１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能を何らかのハードウェア、及び／又は、ソフトウェアで実行する手段があればよい。
なお、運用管理サーバ２０や管理サーバ５０も配車サーバ１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成は配車サーバ１０と相違する点は無いので説明を省略する。
図４は、タクシー３０の概略構成の一例を示す図である。図４に示すように、タクシー３０には、スマートフォン３２を利用したタクシーメータ３１が含まれる。タクシーメータ３１とスマートフォン３２は、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信やケーブルを利用した有線接続により相互に通信可能に構成されている。タクシーメータ３１は、スマートフォン３２と通信することにより、そのハードウェア（例えば、モバイル回線へのアクセス手段やＧＰＳ（Global Positioning System）機能）を利用する。
なお、図４には、タクシーメータ３１やスマートフォン３２を図示しているが、タクシー（車両）としての機能を実現するハードウェアの図示は省略している。また、タクシーメータ３１やスマートフォン３２のハードウェアは実質的に情報処理装置（コンピュータ）と同様とすることができ、当業者にとって明らかでもあるのでその説明を省略する。
［配車サーバ］
次に、配車サーバ１０の詳細について説明する。
図５は、第１の実施形態に係る配車サーバ１０の処理構成の一例を示すブロック図である。図５を参照すると、配車サーバ１０は、通信制御部２０１と、記憶部２０２と、配車処理部２０３と、を含んで構成される。
通信制御部２０１は、他の装置との間の通信を実現する手段である。通信制御部２０１は、他の装置から受信したメッセージ（パケット）を各処理モジュール部に振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
記憶部２０２は、例えば、配車処理部２０３の処理等に必要なデータを記憶する。
配車処理部２０３は、顧客からの配車依頼を処理する手段である。配車処理部２０３は、顧客からの配車依頼を受信すると、データ管理システム４０から運用管理データを取得する。例えば、配車処理部２０３は、過去の所定時刻から現在までの所定期間の間に電子掲示板に格納された運用管理データの読み出し依頼をデータ管理システム４０に行い、運用管理データを取得する。あるいは、配車処理部２０３は、取得するデータ量を指定して運用管理データの読み出し依頼をデータ管理システム４０に行ってもよい。配車処理部２０３は、取得した運用管理データに基づいて、顧客の元に向かわせるタクシー３０を決定し、当該タクシー３０に対して迎車指示を行う。
配車処理部２０３は、署名検証部２１１と迎車決定部２１２の２つのサブモジュールを備える。
署名検証部２１１は、データ管理システム４０から取得する運用管理データに付与されているグループ署名の検証を行う手段である。後述するように、各タクシー会社の運用管理サーバ２０は、管理者公開鍵及び特権者公開鍵を公開するので、署名検証部２１１は、各タクシー会社の公開鍵（管理者公開鍵、特権者公開鍵）を用いて運用管理データに付与されているグループ署名の検証を行う。なお、グループ署名の検証は、非特許文献２の図７に示される「グループ署名検証アルゴリズム」に従って行うことができる。
検証の結果、運用管理データの正当性が確認できた場合には、署名検証部２１１は、当該データを迎車決定部２１２に引き渡す。検証の結果、運用管理データの正当性が確認できない場合には、署名検証部２１１は、当該データを破棄する。署名検証部２１１は、上記の様な検証処理を取得した運用管理データに対して実施し、正当性が確認できたデータを迎車決定部２１２に引き渡す。
迎車決定部２１２は、正当性が確認できた運用管理データを用いて、迎車指示を出すタクシー３０を決定する手段である。例えば、迎車決定部２１２は、配車依頼を行った顧客の現在位置と、運用管理データに含まれるタクシー３０の現在位置と、を比較し、顧客に最も近い現在地を含む運用管理データを特定する。後述するように、運用管理データには各タクシー３０のメッセージ通知先（例えば、メールアドレス）が含まれるため、迎車決定部２１２は、特定した運用管理データから得られる通知先に対して迎車指示を行う。その際、迎車決定部２１２は、上記迎車指示に顧客の現在位置を含ませる。
［運用管理サーバ］
次に、運用管理サーバ２０の詳細について説明する。
第１の実施形態に係る運用管理サーバ２０は、グループのメンバ（タクシー３０）に配布するメンバ証明書を発行する機能と、運用管理データを生成したタクシー３０を特定する機能と、を備える。つまり、第１の実施形態に係る運用管理サーバ２０は、非特許文献２に記載された「管理者」として役割と「特権者」としての役割を備える。
図６は、第１の実施形態に係る運用管理サーバ２０の処理構成の一例を示すブロック図である。図６を参照すると、運用管理サーバ２０は、通信制御部３０１と、記憶部３０２と、証明書管理部３０３と、を含んで構成される。なお、図６において、自グループに属するタクシー３０の運行状況を確認するための機能モジュールは図示を省略している。
通信制御部３０１は、他の装置との間の通信を実現する手段である。通信制御部３０１は、他の装置から受信したメッセージ（パケット）を各処理モジュール部に振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
記憶部３０２は、証明書管理部３０３による鍵生成やメンバ証明書の生成に必要な情報を記憶する。
証明書管理部３０３は、自社のタクシー３０が運用管理データに付与するグループ署名を生成するために必要な情報の生成、管理を行う手段である。証明書管理部３０３は、鍵生成部３１１と証明書生成部３１２の２つのサブモジュールを備える。
鍵生成部３１１は、グループ署名に用いる、管理者公開鍵と管理者秘密鍵によるペアと、特権者公開鍵と特権者秘密鍵によるペアを生成する。鍵生成部３１１は、管理者公開鍵と特権者公開鍵を公開する。公開された管理者公開鍵は、少なくとも配車サーバ１０により取得される。また、特権者公開鍵は、少なくとも自社の各タクシー３０及び配車サーバ１０により取得される。
証明書生成部３１２は、自社のタクシー３０がグループ署名を生成する際に必要となる「メンバ証明書」を生成し、発行する手段である。証明書生成部３１２は、後述するタクシーメータ３１の証明書取得部４０３と協働してメンバ証明を生成し、生成したメンバ署名書をタクシー３０に配布する。具体的には、非特許文献２の図５に示される「ユーザ登録プロトコル」に従うことにより、各タクシー３０は、自身の公開鍵、秘密鍵、さらにその公開鍵の正当性を管理者秘密鍵によって保証するメンバ証明書を入手する。
［タクシー］
次に、タクシー３０の詳細について説明する。
上述のように、タクシー３０がタクシー配車システムに参加するための機能は、タクシーメータ３１により実現される。そのため、以下、タクシーメータ３１の処理構成について説明する。
図７は、第１の実施形態に係るタクシーメータ３１の処理構成の一例を示すブロック図である。図７を参照すると、タクシーメータ３１は、通信制御部４０１と、記憶部４０２と、証明書取得４０３と、運用管理データ処理部４０４と、を含んで構成される。
通信制御部４０１は、スマートフォン３２との間の通信を制御し、他の装置との間の通信を実現する手段である。通信制御部４０１は、他の装置から受信したメッセージ（パケット）を各処理モジュール部に振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
記憶部４０２は、グループ署名の生成等に必要なデータを記憶する。
証明書取得部４０３は、運用管理サーバ２０の証明書生成部３１２と協働してメンバ証明書を作成し、運用管理サーバ２０からメンバ証明書を取得する手段である。なお、運用管理サーバ２０から取得したメンバ証明書は記憶部４０２に格納される。証明書取得部４０３は、メンバ証明書を生成する際に必要となる鍵（秘密鍵）を生成する。
運用管理データ処理部４０４は、運用管理データを生成し、当該生成した運用管理データをデータ管理システム４０に送信する手段である。
運用管理データ処理部４０４は、運用管理データ生成部４１１とグループ署名生成部４１２の２つのサブモジュールを備える。
運用管理データ生成部４１１は、運用管理データを生成する手段である。運用管理データには、少なくとも自車の現在位置と、メッセージ通知先（例えば、メールアドレス）が把握可能な情報が含まれる。例えば、図８に示すように、顧客を乗せた場所に関する情報（乗車位置）、顧客を降ろした場所に関する情報（降車位置）、自車の現在位置に関する情報、迎車指示を送信するメッセージ通知先に関する情報等が、運用管理データに含まれる。なお、運用管理データから当該データの生成主体が特定されることを困難とするため、メッセージ通知先には所定期間に限り使える使い捨てのメールアドレス等を用いるのが好ましい。
なお、図８において、運用管理データに「降車位置」と「現在位置」が含まれるのは、降車位置と現在位置が一致しない場合を考慮した結果である。また、図８に示す運用管理データは例示であって、運用管理データの内容を制限する趣旨ではない。例えば、乗車位置や降車位置に関する情報が運用管理データに含まれていなくてもよいし、他の情報（例えば、顧客の乗車、降車に関する時刻や走行距離等）が含まれていてもよい。
運用管理データ生成部４１１は、運用管理データに記載する「位置」に関する情報を、例えば、スマートフォン３２に内蔵されたＧＰＳにより取得する。運用管理データ生成部４１１は、例えば、運転手が顧客を乗せた旨の操作をタッチパネル等に行うと、スマートフォン３２のＧＰＳにより得られる位置情報を乗車位置に設定する。
なお、運用管理データを生成するタイミングは種々のものが考えられる。例えば、運用管理データ生成部４１１は、所定時刻や所定の間隔にて、運用管理データを生成してもよいし、顧客を降ろしたタイミングにて運用管理データを生成してもよい。つまり、運用管理データが定期的に生成されるようにしてもよいし、顧客を降ろす等のイベントを契機として運用管理データが生成されるようにしてもよい。運用管理データ生成部４１１は、生成した運用管理データをグループ署名生成部４１２に引き渡す。
グループ署名生成部４１２は、送信するメッセージ（運用管理データ）に付与するグループ署名を生成する手段である。グループ署名生成部４１２は、証明書取得部４０３が生成した秘密鍵、自社の運用管理サーバ２０から取得したメンバ証明書及び特権者公開鍵によりグループ署名を生成する。なお、グループ署名の生成は、非特許文献２の図６に示される「グループ署名作成アルゴリズム」に従って行うことができる。
グループ署名の生成が終了すると、運用管理データ処理部４０４は、生成された運用管理データにグループ署名を付与して、データ管理システム４０に送信する（電子掲示板への追記を依頼する）。なお、その際、運用管理データ処理部４０４は、運用管理データに、当該データがタクシー配車システムにて用いられることを識別する識別子を付与する。
上述のように、メンバ証明書の発行、グループ署名の作成及びグループ署名の検証等は、非特許文献２に開示されたアルゴリズム、プロトコルを使用することができ、また、これらのアルゴリズム等の更なる詳細は非特許文献１の開示を参考にすることができる。ここでは、図面を参照しつつ、非特許文献２の記載に準拠してタクシー配車システムにグループ署名を導入する際の概略動作を説明する。
なお、本願開示の数式に用いられる記号を下記のとおりとする。
Ｎ：２素数の積
Ａ、ａ、ｂ：剰余環の現
ｇ、ｕ：素数体の元
Ｈ：ハッシュ関数
ｃ：ハッシュ値
Ｐ、ｐ、ｑ：素数
ｒ、ｓ、ｘ、ν、ρ、τ：乱数
ｋ：整数
図９を参照すると、タクシー会社それぞれが１つのグループとして扱われる。１つのグループ（タクシー会社）には、複数のメンバ（タクシー）が所属している。各タクシー会社の運用管理サーバ２０は、タクシー配車システムに参加する際に、管理者公開鍵と管理者秘密鍵によるペアと、特権者公開鍵と特権者秘密鍵のペアを生成する。
ここでは、管理者公開鍵、特権者公開鍵、管理者秘密鍵及び特権者秘密鍵を以下の式（１）～（４）のように定める。
管理者公開鍵：ｇｐｋ１＝（Ｎ、ａ０、ａ１、ａ２、ｋｅ、Ｈ） ・・・（１）
特権者公開鍵：ｇｐｋ２＝（ｇ１、ｇ２、ｇ３、Ｐ、ｑ） ・・・（２）
管理者秘密鍵：（ｐ１、ｐ２）ｓ.ｔ. Ｎ＝ｐ１ｐ２ ・・・（３）
特権者秘密鍵：ｙ ｓ.ｔ. ｇ２＝ｇ１ ｙ ｍｏｄ Ｐ ・・・（４）
各タクシー会社（運用管理サーバ２０）は、管理者公開鍵と特権者公開鍵を公開する。また、各タクシー会社に属するタクシー３０それぞれには、識別子（ＩＤ；Identification）が割り振られている。
上述のように、各タクシー会社（運用管理サーバ２０）とタクシー３０との間でメンバ登録（ユーザ登録）に係る処理が実行される。
ここでは、ユーザ公開鍵と秘密鍵を以下の式（５）、（６）のように定める。
ユーザ公開鍵：ｈ＝ｇ２ ｘ ｍｏｄ Ｐ ・・・（５）
ユーザ秘密鍵：（ｘ、ｒ）ｓ.ｔ. ａ０ａ１ ｘａ２ ｒ＝Ａｅ ｍｏｄ Ｎ ・・・（６）
各タクシー３０の証明書取得部４０３は、上記（６）式に示すような秘密鍵を生成し、当該生成した秘密鍵から変換した情報を生成する。具体的には、証明書取得部４０３は、非特許文献２に記載されたように、ｘ、ｒ’をランダムに選択し、下記の式（７）に示す情報を生成する。
Ａ’← ａ１ ｘａ２ ｒ’ｍｏｄ Ｎ ・・・（７）
証明書取得部４０３は、上記（７）に示す情報（秘密鍵を変換した情報）と、上記（５）に示す公開鍵を運用管理サーバ２０に送信する。運用管理サーバ２０の証明書生成部３１２は、非特許文献２の図５に記載されたプロトコルに従い、下記の式（８）に示すメンバ証明書を生成する。
メンバ証明書：（Ａ、ｅ） ・・・（８）
各タクシー３０は、グループ署名生成のために、運用管理サーバ２０から発行されたメンバ証明書と上記生成した秘密鍵を準備する。例えば、ＩＤ＝ｉ（ｉは正の整数、以下同じ）のタクシー３０は、メンバ証明書（Ａｉ、ｅｉ）と秘密鍵ｓｋ（ｉ）を準備する。各タクシーに送信されたメンバ証明書（Ａｉ、ｅｉ）と秘密鍵ｓｋ（ｉ）が、各タクシー３０に関するグループ署名生成用秘密鍵ｓｋ（ｇｓ）となる。なお、以降の説明において、ＩＤ＝ｉのタクシーをタクシー（ｉ）と表記する。
タクシー（ｉ）のグループ署名生成部４１２は、グループ署名を生成する。例えば、図１０を参照すると、上記メンバ証明書（Ａｉ、ｅｉ）を有するタクシー（ｉ）は、グループ署名生成の際に、運用管理データであるメッセージＭに対しグループ署名生成用秘密鍵ｓｋ（ｇｓ）及び特権者公開鍵を適用しグループ署名ｓｉｇ（ｉ、Ｍ）を生成する。
より具体的には、グループ署名生成部４１２は、ｓ、νをランダムに選択した上で、下記の式（９）及び（１０）に示す情報を計算する。
ｂ←ａ２ ｓＡ ｍｏｄ Ｎ ・・・（９）
（ｕ１、ｕ２、ｕ３）←（ｇ１ ν、ｈｇ２ ν、ｇ３ ν＋ｅ’）ｍｏｄ Ｐ ・・・（１０）
次に、グループ署名生成部４１２は、ρｘ、ρｒ、ρ’ ｅ、ρνをランダムに選択した上で、下記の式（１１）～（１６）によりグループ署名を得る。
Figure 0007047760000001

Figure 0007047760000002

Figure 0007047760000003
τｘ＝ρｘ＋ｃｘ、τｒ＝ρｒ＋ｃ（ｒ＋ｓｅ） ・・・（１４）
τ’ｅ＝ρ’ｅ＋ｃｅ’、τν＝ρν＋ｃν ｍｏｄ ｑ ・・・（１５）
Ｓｉｇ＝（ｂ、ｕ１、ｕ２、ｕ３、ｃ、τｘ、τｒ、τ'ｅ、τν） ・・・（１６）
このグループ署名は、タクシー（ｉ）がタクシー会社の管理者公開鍵に対応する正しい管理者秘密鍵を持つ主体が発行するメンバ証明書を所有しており、さらに、特権者公開鍵に対応する正しい特権者秘密鍵を持つ主体により、正しくメンバ証明書を特定できることを保証するゼロ知識証明機能を持つものになっている。
続いて、グループ署名を用いた検証及び追跡の概略について説明する。上述のように、配車サーバ１０の署名検証部２１１は、運用管理データに付与されているグループ署名の検証を行う。具体的には、署名検証部２１１は、各タクシー会社により公開された管理者公開鍵と特権者公開鍵を用いて、グループ署名を検証する。より具体的には、署名検証部２１１は、下記の式（１７）～（１９）が成立するか否かによりグループ署名の検証を行う。
Figure 0007047760000004

Figure 0007047760000005

Figure 0007047760000006
例えば、Ａ社の管理者公開鍵と特権者公開鍵により、グループ署名の正当性が保証されれば、当該グループ署名が付された運用管理データは、タクシー配車システムに参加しているＡ社の正当な一員であることが判明する。さらに、Ａ社は、グループ署名から自社に所属するいずれのタクシーが生成した運用管理データか特定できる（自社のタクシーを特定できる）。
このように、管理者公開鍵と特権者公開鍵によるグループ署名の検証により、運用管理データを電子掲示板に書き込んだタクシー３０が、システム上の正当な資格を有するタクシー会社の一員であるか否か判明する。しかし、上記検証だけでは、配車サーバ１０等は、運用管理データを電子掲示板に書き込んだタクシー３０を特定することができない。つまり、グループ署名を使用することで、配車サーバ１０等が把握可能な情報は、運用管理データを電子掲示板に書き込んだタクシー３０の正当性に関する情報に制限される。また、このように情報が制限されたとしても、配車サーバ１０は、運用管理データの正当性が確認でき（システムへの正当な参加資格を有するタクシー会社の一員であることが保証され）、且つ、タクシー３０の現在位置とメッセージ通知先が把握できれば、システムの運用には支障がない。
対して、グループの管理者たるタクシー会社では、特権者秘密鍵を用いることで、当該グループ署名を付与したタクシー３０を一意に特定できる。具体的には、タクシー会社の運用管理サーバ２０は、下記の式（２０）を計算することで、グループ署名を生成したタクシー３０を特定できる。
ｈ＝ｕ２／ｕ１ ｙ ・・・（２０）
タクシー会社（運用管理サーバ２０）は、グループ署名に含まれるデータを、特権者秘密鍵を用いて変換すると、各タクシー３０のメンバ証明書を取り出すことができる。タクシー会社は、この取り出したメンバ証明書から、タクシー３０のＩＤを特定することができる。つまり、タクシー会社は、データ管理システム４０から運用管理データを取得し、グループ署名から当該運用管理データを送信したタクシー３０を一意に特定できる（メンバの追跡ができる）。その結果、タクシー会社は、自社のタクシー３０それぞれについて、運行状況、稼働状況等の詳細を知ることができる。
［管理サーバ］
次に、データ管理システム４０をなす管理サーバ５０の詳細について説明する。
図１１は、第１の実施形態に係る管理サーバ５０の処理構成の一例を示すブロック図である。図１１を参照すると、管理サーバ５０は、通信制御部５０１と、記憶部５０２と、台帳管理部５０３と、を含んで構成される。
通信制御部５０１は、他の装置との間の通信を実現する手段である。通信制御部５０１は、他の装置から受信したメッセージ（パケット）を各処理モジュール部に振り分ける、又は、各処理モジュールから取得したメッセージを他の装置に送信する手段でもある。
記憶部５０２は、各処理モジュールの処理に必要な情報を記憶する手段である。記憶部５０２には、データを一時的に記憶する一時記憶領域とデータ管理台帳を記憶する領域が含まれる。
台帳管理部５０３は、電子掲示板への配車サーバ１０やタクシー３０からのアクセス要求を処理する手段である。具体的には、例えば、タクシー３０から電子掲示板への運用管理データの書き込み要求を受け付けると、記憶部５０２に格納されているデータ管理台帳に運用管理データを追記する。また、台帳管理部５０３は、外部装置から電子掲示板の読み出しに係る要求を受け付けると、当該要求に付随する識別子（タクシー配車システム用のデータを示す識別子）をキーとしてデータ管理台帳を検索し、当該識別子が付されたデータ（即ち、運用管理データ）を抽出する。その際、台帳管理部５０３は、運用管理データの読み出し範囲が指定されている場合には、当該読み出し範囲に適合する運用管理データを抽出する。台帳管理部５０３は、抽出した運用管理データを配車サーバ１０等に送信する。
台帳管理部５０３は、ブロック生成部５１１とブロック検証部５１２の２つのサブモジュールを有する。
ブロック生成部５１１は、データ管理台帳を他の管理サーバ５０にて共有し、管理するためのブロックを生成する。
台帳管理部５０３は、タクシー３０等から運用管理データを取得すると、当該取得した運用管理データを記憶部５０２の一時記憶領域に保存する。その後、ブロック生成部５１１は、直前に生成されたブロックのヘッダと、当該一時記憶領域に保存されたデータ（例えば、運用管理データや売上データ；データ管理台帳への追記データ）から、「正当性保証データ」を生成する。例えば、ブロック生成部５１１は、追記データ、前ブロックのヘッダ及び正当性保証データのハッシュ値を計算すると、当該計算されたハッシュ値を所定の規則に適合するものにする値（所謂、ノンス値又はナンス値）を正当性保証データとして生成する。また、正当性保証データには、ブロックを生成した管理サーバ５０の電子署名が含まれる。
ブロック生成部５１１は、直前に生成されたブロックのヘッダと上記の正当性保証データからなるヘッダを有するブロックを生成する。具体的には、図１２に示すようなブロックが生成される。
ブロック生成部５１１によるブロック生成が終了すると、当該ブロックはデータ管理台帳に追記される。また、ブロック生成部５１１は、生成したブロックを、通信制御部５０１を介して他の管理サーバ５０に配布（送信）する。
他の管理サーバ５０から上記ブロックを受信した管理サーバ５０の通信制御部５０１は、取得したブロックをブロック検証部５１２に引き渡す。
ブロック検証部５１２は、自装置の記憶部５０２に格納されているデータ管理台帳（ブロック）に基づき、他の管理サーバ５０が送信するブロックの正当性を検証する手段である。具体的には、ブロックを受信した管理サーバ５０のブロック検証部５１２は、当該受信したブロックの正当性を、ブロックを送信した管理サーバ５０が生成したブロックと自装置（ブロックを受信した管理サーバ５０）が管理している直前に生成されたブロックのヘッダを用いて検証する。
初めに、ブロック検証部５１２は、受信したブロックに含まれる正当性保証データに送信元となる管理サーバ５０の電子署名が付与されていることを確認し、受信したブロックに記載された「前ブロックのヘッダ」を自身が管理するデータ管理台帳に基づき特定する。その後、ブロック検証部５１２は、受信したブロック内の追記データと前ブロックのヘッダを入力として、ヘッダ内の正当性保証データの整合がとれているか否か（正当性保証データが所定の規則に適合するか否か）を確認する。
ブロック検証部５１２は、正当性保証データの整合性が確認できれば、他の管理サーバ５０が送信するブロックは正当であると判定する。一方、正当性保証データの整合性が確認できなければ、ブロック検証部５１２は、他の管理サーバ５０が送信するブロックは不当であると判定する。
ブロック検証部５１２が、他の管理サーバ５０が送信するブロックが正当であると判定した場合には、台帳管理部５０３は、記憶部５０２のデータ管理台帳を更新する（追記データを含むブロックを追記する）。つまり、ブロック検証部５１２は、他の管理サーバ５０の台帳へのデータの追記を、自装置の台帳に反映する処理を行う。なお、ブロック検証部５１２は、他の管理サーバ５０が送信するブロックが不当であると判定した場合には、当該ブロックを破棄する。
また、ブロック検証部５１２は、検証結果（受信したブロックは正当、不当）に関する情報を、ブロックを送信してきた管理サーバ５０に通知する。
管理サーバ５０の動作をまとめると図１３に示すシーケンス図のとおりとなる。なお、図１３には、管理サーバ５０－１がタクシー３０から運用管理データを取得し、当該データをデータ管理台帳に追記する場合を示す。
管理サーバ５０－１は、タクシー３０から運用管理データを取得すると（ステップＳ１０１）、当該データを自装置の記憶部５０２の一部記憶領域に複製する（ステップＳ１０２）。
その後、一部記憶領域に複製されたデータが所定量蓄積される等の条件により、管理サーバ５０－１は、一時記憶領域に記憶された運用管理データに基づき、上述のブロックを生成する（ステップＳ１０３）。その後、管理サーバ５０－１は、生成したブロックを他の管理サーバ５０－２～５０－４に向けて送信する（ステップＳ１０４）。
ブロックを受信した管理サーバ５０－２～５０－４のそれぞれは、管理サーバ５０－１が生成したブロックを個別に検証する（ステップＳ１０５）。管理サーバ５０－２～５０－４のそれぞれは、ブロックの正当性が確認できた場合に自装置のデータ管理台帳を更新する（ステップＳ１０６）。このように、データ管理システム４０をなす複数の管理サーバ５０のうちの少なくとも１つの管理サーバ５０によるデータ管理台帳へのデータの追記は、他の管理サーバ５０のデータ管理台帳に反映される。
なお、他の管理サーバ５０から送信されたブロックの正当性が確認できない場合には、当該ブロックを破棄すると共に、管理サーバ５０はその旨を、ブロックを送信する管理サーバ５０に通知する。当該通知を受けた管理サーバ５０の台帳管理部５０３は、ブロック送信前のデータ管理台帳の状態を取り戻す。
次に、タクシー配車システムの動作について説明する。
図１４は、タクシー配車システムにおけるセットアップ動作の一例を示すシーケンス図である。
タクシー配車システムの運用開始にあたり、各タクシー会社は、上記２つの公開鍵秘密鍵ペアを生成する（ステップＳ０１）。その後、タクシー会社は、管理者公開鍵と特権者公開鍵を公開する。
各タクシー３０は、グループ署名の生成に必要な秘密鍵を生成する（ステップＳ０２）。その後、各タクシー３０は、生成した秘密鍵を変換した情報等をタクシー会社（運用管理サーバ２０）に送信する。
タクシー会社（運用管理サーバ２０）は、取得した秘密鍵を変換した情報に対して特権者秘密鍵による署名を生成し、メンバ証明書を生成する（ステップＳ０３）。生成したメンバ証明書は、各タクシー３０に送信される。
タクシー配車システムに参加するタクシー会社ごとに図１４に示すセットアップ処理が実行され、システム稼働の準備が完了する。また、新たなタクシー会社がシステムに参加する際にも、当該タクシー会社に関して図１４に示すセットアップ処理が実行される。
続いて、タクシー配車システムにおける通常動作（タクシーの配車処理）について説明する。
図１５は、タクシー配車システムの運用時に係る動作の一例を示すシーケンス図である。
タクシー配車システムのサービス提供エリアにあるタクシー３０は、所定の条件が満たされることにより、運用管理データを生成する（ステップＳ１１）。次に、タクシー３０は、当該生成した運用管理データのグループ署名を生成する（ステップＳ１２）。その後、タクシー３０は、運用管理データにグループ署名を付与してデータ管理システム４０に、当該データを送信する（ステップＳ１３）。データ管理システム４０の管理サーバ５０は、当該受信した運用管理データをデータ管理台帳に追記する（ステップＳ１４）。
ステップＳ１１～Ｓ１４の処理が繰り返されることにより、データ管理システム４０の電子掲示板には各タクシー３０の現在位置を含む情報が蓄積される。
配車サーバ１０は、顧客の現在位置を含む配車依頼を受信すると、データ管理システム４０から所定範囲の運用管理データを取得する（ステップＳ１５）。その後、配車サーバ１０は、取得した運用管理データのそれぞれについてグループ署名を検証（ステップＳ１６）し、システムに参加しているタクシー会社に属するタクシー３０が生成した運用管理データか否かを確認する。配車サーバ１０は、正当性が確認できた運用管理データのなかから、配車依頼を行った顧客に近いタクシー３０の現在位置を特定し、当該タクシー３０に対して迎車指示を行う（ステップＳ１７）。
以上のように、第１の実施形態では、運用管理データの生成主体に関する正当性の判定に、グループ署名を用いている。グループ署名を用いることで、運用管理データの生成主体が、タクシー配車システムに参加する正当な資格を有するタクシー会社の一員であるか否か判定できる。また、グループ署名による検証だけでは、運用管理データを生成したタクシー３０を一意に特定することはできない。このような特定が可能であるのは、グループ管理者であるタクシー会社に限られる。即ち、運用管理データの正当性を検証可能としつつ、当該データから得られる情報が適切に制限される。
［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。
第１の実施形態では、グループ署名を使用することで、運用管理データを生成した主体が、各タクシー会社の一員であることを保証している。その際、配車サーバ１０は、各タクシー会社が公開している管理者公開鍵及び特権者公開鍵を用いてグループ署名の検証を行う。
ここで、各タクシー会社が公開している管理者公開鍵及び特権者公開鍵は、他のタクシー会社も知ることができるので、他社も運用管理データに付されたグループ署名の検証が可能である。例えば、図９を参照すると、Ａ社の管理者公開鍵及び特権者公開鍵はＢ社も知ることが出来るので、Ａ社に属するタクシー３０が付与したグループ署名の検証が、Ａ社の管理者公開鍵及び特権者公開鍵により成功すれば、Ｂ社は、当該グループ署名が付された運用管理データはＡ社のタクシー３０により生成された事実を知ることができる。Ｂ社が、データ管理システム４０に格納されている運用管理データ及びそのグループ署名に関し、上記のような検証を繰り返すことで、Ａ社のタクシー３０の運用状況が把握され得る。
Ａ社のタクシー３０の運用状況が把握できれば、当該情報を分析することで、Ａ社の営業方針等が判明する可能性がある。例えば、Ａ社に関する、時間帯別やエリア別のタクシー稼働状況等の情報が作成できる可能性がある。
タクシー配車システムに参加しているタクシー会社は、本来、競合関係にあるため、上記のような情報が作成できることは望ましくない。つまり、第１の実施形態では、グループ署名を使用することで、運用管理データ及びその署名から得られる情報を各タクシーの所属会社に制限したが、当該制限でも不十分である可能性がある。即ち、運用管理データの生成主体が、タクシー配車システムに参加する資格があるか否かが検証可能であれば十分であり、当該生成主体の帰属するグループ（タクシー会社）はグループ署名から把握できないことが望ましい。
上記問題に対し、第２の実施形態では、グループ署名におけるメンバ登録機能（メンバ証明書発行機能）と追跡機能（自社のタクシーの識別機能）を分離することで、上記問題を解決する。具体的には、第２の実施形態では、タクシー協会がメンバ登録を行う。なお、第２の実施形態においても、第１の実施形態と同様に、各タクシー会社がグループ署名から自社のタクシーを特定できる。
第２の実施形態では、図２に示すシステム構成に対し、タクシー協会等に設置される証明書管理サーバ６０が追加される（図１６参照）。
図１７は、第２の実施形態に係る証明書管理サーバ６０の処理構成の一例を示す図である。証明書管理サーバ６０は、他の装置と同様な通信制御部６０１と記憶部６０２を備える。さらに、証明書管理サーバ６０は、証明書管理部６０３を含む。
証明書管理部６０３は、鍵生成部６１１と証明書生成部６１２の２つのサブモジュールを備える。上記サブモジュールを含む証明書管理サーバ６０の動作は後述する。
第１の実施形態では、運用管理サーバ２０にてメンバ証明書を生成していたが、当該機能は証明書管理サーバ６０が担うため、第２の実施形態に係る運用管理サーバ２０には証明書生成部が存在しない（図１８参照）。但し、後述するように、運用管理サーバ２０は、特権者公開鍵を生成し、公開する機能を有するので、第２の実施形態に係る運用管理サーバ２０には、特権者公開鍵及び特権者秘密鍵を生成する鍵生成部３１１ａが含まれる。
次に、図面を参照しつつ、第２の実施形態に係るグループ署名の生成について説明する。
図１９は、第２の実施形態に係るグループ署名の生成を説明するための図である。図１９を参照すると、証明書管理サーバ６０の鍵生成部６１１は、管理者公開鍵と管理者秘密鍵のペアを生成し、管理者公開鍵を公開する。また、各タクシー会社の運用管理サーバ２０（鍵生成部３１１ａ）は、特権者公開鍵と特権者秘密鍵のペアを生成し、特権者公開鍵を公開する。
各タクシー会社とそのタクシー３０は、第１の実施形態と同様の方法により、メンバ証明書の生成及び取得を行う。
タクシー３０は、運用管理データに付するグループ署名を生成するが、当該グループ署名の生成方法が、第１と第２の実施形態では異なる。第１の実施形態では、運用管理データ（メッセージＭ）のグループ署名ｓｉｇ（ｉ、Ｍ）を生成する際、メンバ証明書と自社の特権者公開鍵を用いて作成している（図１０参照）。対して、第２の実施形態では、各タクシー３０は、どの特権者公開鍵を使ったかを秘匿するために、すべてのタクシー会社の特権者公開鍵を入力する（図２０参照）。
グループ署名は、非特許文献２に記載されたように、「公開鍵について漏らす知識をゼロにして、正しく登録された公開鍵が暗号化されていることと、ユーザがこの公開鍵の持ち主であること」を示す技術である。そして当該技術の実現には「自分の公開鍵を暗号化し、その公開鍵にメンバ証明書が存在することと、なおかつ暗号化した人がこの公開鍵に対応する秘密鍵を持つことを証明するゼロ知識証明データ」を付与することが必要になる。しかしながら、この場合、どの特権者公開鍵を使って自分の公開鍵を暗号化したかを、検証者に伝えることが必要となる。しかし、当該事実（使用した特権者公開鍵）を伝えることによって、各タクシー３０の所属先が判明してしまう。
このような不都合、問題点を解消するため、第２の実施形態に係るグループ署名生成部４１２は、全てのタクシー会社の特権者公開鍵（図１９の例では、ｇｐｋ２Ａ、ｇｐｋ２Ｂ、・・・）を入力とし、グループ署名の生成に利用する。つまり、「自分の公開鍵を、いずれかの特権者公開鍵で暗号化し、その公開鍵にメンバ証明書が存在すること、なおかつ暗号化した人（主体）がこの公開鍵に対応する秘密鍵を持つことを証明するゼロ知識証明データ」を付与することにする。
当該変更を加えることにより、どのタクシー会社に所属しているかを秘匿しつつ、タクシー協会から発行されたメンバ証明書であり、なおかつ、各タクシーの所属は該当するタクシー会社のみが特定できるグループ署名を発行することができる。
ここで、「データがいずれかの公開鍵で暗号化したもの」であることのゼロ知識証明は、いわゆるＯＲｐｒｏｏｆと呼ばれるものであり、以下のようにその構成を得ることができる。
たとえば、上記第１の実施形態にて説明した式（１）～（２０）に基づいてゼロ知識証明を構成すると、下記のようになる。なお、下記の説明では、タクシー会社Ａに属するタクシー３０がグループ署名を生成する場合を例示する。さらに下記例示では、タクシー配車システムに参加しているタクシー会社は３社（Ａ社、Ｂ社、Ｃ社）としている。但し、システムに含まれるタクシー会社（グループ）の数を限定する趣旨ではないことは勿論である。
上記の式（１）～（４）に示した管理者公開鍵、特権者公開鍵、管理者秘密鍵、特権者秘密鍵に関し、第２の実施形態では、特権者公開鍵及び特権者秘密鍵が第１の実施形態とは異なる。具体的には、式（２）に示す特権者公開鍵をタクシー会社の数だけ用意する。その際、式（２）に示す特権者公開鍵のうち、（ｇ１、ｇ３、Ｐ、ｑ）はパラメータに関する情報であり、全てのタクシー会社に共通して設定される。タクシー会社ごとに異なるのは、特権者秘密鍵に依存して生成される要素ｇ２となる。例えば、Ａ社の特権者公開鍵を式（２１）、Ｂ社の特権者公開鍵を式（２２）のようにする。
Ａ社の特権者公開鍵：ｇｐｋ２Ａ＝（ｇ１、ｇ２Ａ、ｇ３、Ｐ、ｑ） ・・・（２１）
Ｂ社の特権者公開鍵：ｇｐｋ２Ｂ＝（ｇ１、ｇ２Ｂ、ｇ３、Ｐ、ｑ） ・・・（２２）
なお、以下の説明では、式（２１）に対応するタクシー会社Ａの特権者秘密鍵をｙＡ、式（２２）に対応するタクシー会社Ｂの特権者秘密鍵をｙＢとする。
上記の式（５）に示したユーザ公開鍵（各タクシー３０の公開鍵）は自社の特権者公開鍵に応じて生成される。例えば、Ａ社のタクシー３０に関するユーザ公開鍵は式（２３）、Ｂ社のタクシー３０に関するユーザ公開鍵は式（２４）のとおりとなる。
Ａ社タクシーの公開鍵：ｈ＝ｇ２Ａ ｘ ｍｏｄ Ｐ ・・・（２３）
Ｂ社タクシーの公開鍵：ｈ＝ｇ２Ｂ ｘ ｍｏｄ Ｐ ・・・（２４）
このように、ユーザ公開鍵は、自身が属するタクシー会社の特権者公開鍵に含まれる要素ｇ２（Ａ社；要素ｇ２Ａ、Ｂ社；要素ｇ２Ｂ）をｘ乗することで得られる値により生成される。
なお、メンバ証明書の発行に関しては、上述のとおり第１の実施形態と同様である。但し、各タクシー３０のユーザ公開鍵ｈは、自身が属するタクシー会社の特権者公開鍵に含まれる要素ｇ２をｘ乗することで得られる情報を含む。
次に、上記の式（９）～（１６）に示したグループ署名の生成に関し、第１及び第２の実施形態での相違点を以下のように示す。
第１の実施形態にて説明した式（１０）に関し、第２の実施形態では、ｕ２の生成に用いられる要素が第１の実施形態とは異なる。例えば、Ａ社のタクシー３０では、下記の式（２５）を用いる。
（ｕ１、ｕ２、ｕ３）←（ｇ１ ν、ｈｇ２Ａ ν、ｇ３ ν＋ｃ’）ｍｏｄ Ｐ ・・・（２５）
なお、Ｂ社のタクシー３０がグループ署名を生成する際に、上記の式（２５）が計算される場合には、式（２５）のｇ２Ａがｇ２Ｂとなる。
また、第２の実施形態では、式（１３）～（１６）の計算において、ρｘ、ρｒ、ρ’ ｅ、ρνをランダムに選択することに加え、ｃＢ、ｃＣもランダムに選択し、グループ署名の計算に利用する。なお、ｃＢ、ｃＣは、下記の式（２７）により計算されるハッシュ値ｃをＡ社用のチャレンジ値ｃＡ、Ｂ社用のチャレンジ値ｃＢ、Ｃ社用のチャレンジ値ｃＣに分割することを想定し、ランダムに選択されるものである。ここで、ゼロ知識証明は、コミット、チャレンジ、レスポンスの３つのプロセスで成り立ち、通常は、チャレンジにひとつのハッシュ値を用いる。ＯＲｐｒｏｏｆでは、ＡｏｒＢｏｒＣを証明するため、チャレンジをＡ用、Ｂ用、Ｃ用に分解し、どれかひとつに正しく答えられれば成立するゼロ知識証明を構成する。このために、第２の実施形態では、通常のチャレンジ値（ハッシュ値ｃ）を、それぞれ、タクシー会社用に分割する。第２の実施形態では、ゼロ知識証明の模倣可能という性質から、自分が証明できないチャレンジはランダムに生成し、(上記例示では、ｃＢとｃｃ)、自分が証明できるチャレンジ（上記例示では、ｃＡ）はハッシュ値ｃに依存して（ｃ－ｃＢ－ｃｃ）と計算する。さらに、ＯＲｐｒｏｏｆを実現するために、管理者公開鍵の証明に必要なアッパーバーｕ２の要素を、各タクシー会社の数分重複させる。すなわち、第２の実施形態では、上記の式（１２）は、下記の式（２６）のとおりとなる。
Figure 0007047760000007
上記の式（２６）により得られる値は、下記の式（２７）に示すようにハッシュ関数Ｈの入力パラメータの一部となる。

Figure 0007047760000008

なお、上述のように、第２の実施形態では、全てのタクシー会社の特権者公開鍵がグループ署名の生成に用いられる。そのため、第１の実施形態にて説明した式（１３）の特権者公開鍵ｇｐｋ２に替えて、各タクシー会社の特権者公開鍵ｇｐｋ２Ａ、ｇｐｋ２Ｂ、ｇｐｋ２Ｃが上記の式（２７）における入力パラメータとなる。
また、第１の実施形態にて説明した式（１４）及び式（１５）から得られるτｘ、τνに替えて、第２の実施形態では、以下の式（２８）、（２９）からτｘＡ、τｘＢ、τｘＣ、τνＡ、τνＢ、τνＣが計算される。
τｘＡ＝ρｘ＋ｃＡｘ、τｘＢ＝ρｘ＋ｃＢｘ、τｘＣ＝ρｘ＋ｃｃｘ ・・・（２８）
τνＡ＝ρν＋ｃＡν、τνＢ＝ρν＋ｃＢν、τνＣ＝ρν＋ｃｃν ・・・（２９）
なお、式（２８）、（２９）を含む下記の式において、ｃＡは、ｃＡ＝ｃ－ｃＢ－ｃＣにより求まる値である。その結果、ｃＢ、ｃＣなど、他のタクシー会社に関する成分は知らなくても、自社のｃＡに対する秘密鍵を知っていることで、各タクシーがどのタクシー会社に所属しているかを秘匿する、ＯＲｐｒｏｏｆを構成することができる。
上記の式（２８）、（２９）により算出された値を用いて、下記の式（３０）により署名が生成される。
Ｓｉｇ＝（ｂ、ｕ１、ｕ２、ｕ３、ｃＡ、ｃＢ、ｃＣ、τｘＡ、τｘＢ、τｘＣ、τｒ、τ’ｅ、τνＡ、τνＢ、τνＣ） ・・・（３０）
上記の式（３０）と第１の実施形態にて説明した式（１６）を比較すると、署名の生成に用いるパラメータｃがｃＡ、ｃＢ、ｃＣに、τｘがτｘＡ、τｘＢ、τｘＣに、τνがτνＡ、τνＢ、τνＣに、それぞれ変更となっている。
第２の実施形態に係る署名の検証は、以下の式（３１）～（３３）により行われる。

Figure 0007047760000009

Figure 0007047760000010

Figure 0007047760000011
第２の実施形態では、上記の式（３１）～（３３）の成立検証に加え、下記の式（３４）が成立することを検証する。
ｃ＝ｃＡ＋ｃＢ＋ｃＣ ・・・（３４）
タクシー会社Ａに所属するタクシー３０が生成したグループ署名に対して、当該タクシー３０の特定は、下記の式（３５）により行われる。
ｈ＝ｕ２／ｕ１ ｙＡ ・・・（３５）
式（３５）におけるｙＡはタクシー会社Ａの特権者秘密鍵である。
なお、上記のようにして生成されたグループ署名の検証には、証明書管理サーバ６０から公開された管理者公開鍵と、各タクシー会社が公開した特権者公開鍵を用いて検証が行える。例えば、Ａ社のタクシー３０が生成したグループ署名は、管理者公開鍵ｇｐｋ１とＡ社の特権者公開鍵ｇｐｋ２ＡとＢ社の特権者公開鍵ｇｐｋ２ＢとＣ社の特権者公開鍵ｇｐｋ２Ｃによって検証可能である。このように、第２の実施形態におけるグループ署名の検証には、管理者公開鍵に加えて、全てのグループの特権者が公開する特権者公開鍵が必要となるので、どの特権者公開鍵に対応するメンバ証明書を持っているのかが、秘匿される。つまり、上記グループ署名により、運用管理データを生成したタクシー３０がタクシー協会に加盟しているタクシー会社に所属しているか否かに限り確認可能となる。換言するならば、上記グループ署名の検証では、当該署名を作成したタクシーの所属会社まで把握することはできない。
また、運用管理データを生成したタクシー３０を特定できるのは、グループ署名の生成に使用された特権者公開鍵とペアになる特権者秘密鍵を持つタクシー会社に限られる。つまり、各タクシー会社は、自社のタクシーにより生成されたグループ署名から、当該グループ署名及び運用管理データを生成したタクシーを一意に特定することができる。
以上のように、第２の実施形態では、タクシー配車システムに参加するタクシー会社に属する、複数のタクシー３０を１つのグループと捉え、タクシー会社の上位組織であるタクシー協会が、各タクシー３０のメンバ証明書を発行する。当該メンバ証明書とタクシー配車システムに参加する全てのタクシー会社が公開する特権者公開鍵を用いて生成されたグループ署名は、タクシー協会が公開する管理者公開鍵と上記複数の特権者公開鍵より検証可能である。また、当該グループ署名により正当性が検証されたグループ署名の生成主体は、タクシー配車システムに参加する資格があるか否か（タクシー協会がメンバとして認めたか否か）という事実がグループ署名の検証により判明するに留まる。また、グループ署名を生成したタクシー３０を一意に特定するためのメンバ追跡機能は、各タクシー会社が備える。具体的には、各タクシー３０がグループ署名生成の際に使用する特権者公開鍵の生成、管理はタクシー会社（運用管理サーバ２０）に委ねられる。その結果、グループ署名からデータを取り出して各タクシーを特定することができるのは、各タクシー３０の所属会社に限られる。このように、第２の実施形態では、グループ署名におけるメンバ登録機能とメンバ追跡機能を適切に分離することで、データの正当性の検証と開示する情報の制限を両立させている。
なお、第１及び第２の実施形態にて説明したシステムの構成は例示であって、システムの構成を限定する趣旨ではない。例えば、必要に応じて、メンバの失効を管理するサーバ装置がシステムに含まれていても良い。あるいは、図２では、データ管理システム４０には複数の管理サーバ５０が含まれ、当該管理サーバ５０が、所謂ブロックチェーン技術を用いて、運用管理データを管理することを説明した。しかし、実質的に１台のサーバ等が集中的に運用管理データを管理するものであってもよい。
また、第１の実施形態では、データ管理システム４０は、タクシー協会等から独立した機関であることを前提としたが、データ管理システム４０はタクシー協会の管理下で運用されるものであっても良いことは勿論である。
また、第１及び第２の実施形態では、非特許文献１及び２に記載されたグループ署名の方式（Camenisch-Groth方式）を例にとり説明したが、他のグループ署名の方式を用いることができるのは勿論である。とりわけ、第２の実施形態に関し、既存のグループ署名の方式におけるチャレンジを分割することによって「どれかひとつの特権者公開鍵に対する正しいグループ署名である」というＯＲｐｒｏｏｆを構成することにより、非特許文献１及び２の方式（Camenisch-Groth方式）とは異なる他のグループ署名の方式に基づいても実現可能であることは明らかである。
上記の実施形態の一部又は全部は、以下のようにも記載され得るが、以下には限られない。
［形態１］
上述の第１の視点に係るシステムのとおりである。
［形態２］
前記複数のノードは、複数のグループのいずれかに属しており、
前記複数のグループそれぞれに属するノードを管理する、複数のノード管理サーバをさらに含み、
前記ノード管理サーバのそれぞれは、自グループに属する前記ノードに対し、グループ署名を生成する際に用いるメンバ証明書を発行する、好ましくは形態１のシステム。
［形態３］
前記複数のノードは、複数のグループのいずれかに属しており、
前記複数のグループそれぞれに属するノードを管理する、複数のノード管理サーバと、
前記複数のノードそれぞれに対し、グループ署名を生成する際に用いるメンバ証明書を発行する、証明書管理サーバと、をさらに含み、
前記複数のノード管理サーバのそれぞれは、特権者公開鍵を公開し、
前記証明書管理サーバは、管理者公開鍵を公開する、好ましくは形態１のシステム。
［形態４］
前記ノードは、前記管理者公開鍵と、前記複数のノード管理サーバそれぞれが公開する特権者公開鍵と、を用いてグループ署名を生成する、好ましくは形態３のシステム。
［形態５］
前記生成されたグループ署名は、前記証明書管理サーバが公開する管理者公開鍵と前記複数のノード管理サーバのそれぞれが公開した特権者公開鍵により、検証可能である、好ましくは形態４のシステム。
［形態６］
前記ノード管理サーバは、自身が管理するグループに属するノードが生成したグループ署名に含まれるデータを、前記特権者公開鍵とペアとなる特権者秘密鍵により取り出し、自身が管理するグループに属するノードを特定する、好ましくは形態３乃至５のいずれか一に記載のシステム。
［形態７］
上述の第２の視点に係るシステムのとおりである。
［形態８］
前記ノードが生成するグループ署名は、前記グループ署名を生成したノード自身の公開鍵を、前記複数のノード管理サーバが公開するいずれかの特権者公開鍵で暗号化し、前記自身の公開鍵にメンバ証明書が存在すること、且つ、暗号化した主体が前記自身の公開鍵に対応する秘密鍵を有すること、を証明するデータを含む、好ましくは形態７のシステム。
［形態９］
前記複数のノード管理サーバが公開する特権者公開鍵は、一部の要素が共通するように生成された公開鍵である、好ましくは形態７及び８のシステム。
［形態１０］
前記共通する一部の要素は、前記特権者公開鍵に対応する特権者秘密鍵に依存して生成される要素である、好ましくは形態９のシステム。
［形態１１］
前記ノードの公開鍵は、前記共通する一部の要素に基づき生成される、好ましくは形態１０のシステム。
［形態１２］
前記ノードは、自身が属するグループとは異なるグループのチャレンジ値をランダムに選択し、前記ランダムに選択されたチャレンジ値を用いて前記グループ署名を生成する、好ましくは形態７乃至１１のいずれか一に記載のシステム。
［形態１３］
前記ノードが生成したグループ署名の検証には、前記計算されたハッシュ値と、前記ランダムに選択されたチャレンジ値と、グループ署名を生成したノードが属するグループのチャレンジ値と、を用いる検証が少なくとも含まれる、好ましくは形態１２のシステム。
［形態１４］
上述の第３の視点に係るデータ管理方法のとおりである。
［形態１５］
上述の第４の視点に係るプログラムのとおりである。
なお、形態１４及び形態１５は、形態１と同様に、形態２～形態６のように展開することが可能である。
なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
１０ 配車サーバ
１１ ＣＰＵ（Central Processing Unit）
１２ メモリ
１３ 入出力インターフェイス
１４ ＮＩＣ（Network Interface Card）
２０、２０－１～２０－α 運用管理サーバ
３０、３０－１～３０－β タクシー
３１ タクシーメータ
３２ スマートフォン
４０ データ管理システム
５０、５０－１～５０－４、１０２ 管理サーバ
６０ 証明書管理サーバ
１０１ ノード
２０１、３０１、４０１、５０１、６０１ 通信制御部
２０２、３０２、４０２、５０２、６０２ 記憶部
２０３ 配車処理部
２１１ 署名検証部
２１２ 迎車決定部
３０３、６０３ 証明書管理部
３１１、３１１ａ、６１１ 鍵生成部
３１２、６１２ 証明書生成部
４０３ 証明書取得部
４０４ 運用管理データ処理部
４１１ 運用管理データ生成部
４１２ グループ署名生成部
４２１ リンググループ署名生成部
５０３ 台帳管理部
５１１ ブロック生成部
５１２ ブロック検証部

Claims (6)

  1. それぞれがグループに属する、複数のノードと、
    それぞれのグループに属するノードを管理する、複数のノード管理サーバと、
    前記複数のノードそれぞれに対し、グループ署名を生成する際に用いるメンバ証明書を発行すると共に、管理者公開鍵を公開する証明書管理サーバと、を含み、
    前記複数のノード管理サーバのそれぞれは、特権者公開鍵を公開し、
    前記ノードは、データに付与するグループ署名の生成を、少なくとも前記管理者公開鍵と前記複数のノード管理サーバのそれぞれが公開する特権者公開鍵を用いて行い、
    自身が属するグループとは異なるグループのチャレンジ値をランダムに選択し、前記ランダムに選択されたチャレンジ値を用いて前記グループ署名を生成する、システム。
  2. 前記ノードが生成するグループ署名は、前記グループ署名を生成したノード自身の公開鍵を、前記複数のノード管理サーバが公開するいずれかの特権者公開鍵で暗号化し、前記自身の公開鍵にメンバ証明書が存在すること、且つ、暗号化した主体が前記自身の公開鍵に対応する秘密鍵を有すること、を証明するデータを含む、請求項１のシステム。
  3. 前記複数のノード管理サーバが公開する特権者公開鍵は、一部の要素が共通するように生成された公開鍵である、請求項１及び２のシステム。
  4. 前記共通する一部の要素は、前記特権者公開鍵に対応する特権者秘密鍵に依存して生成される要素である、請求項３のシステム。
  5. 前記ノードの公開鍵は、特権者秘密鍵に依存して生成される、異なる一部の要素に基づき生成される、請求項４のシステム。
  6. 前記ノードが生成したグループ署名の検証には、前記計算されたハッシュ値と、前記ランダムに選択されたチャレンジ値と、グループ署名を生成したノードが属するグループのチャレンジ値と、を用いる検証が少なくとも含まれる、請求項１のシステム。
JP2018530424A 2016-07-29 2017-07-28 システム、データ管理方法及びプログラム Active JP7047760B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2016150100 2016-07-29
JP2016150100 2016-07-29
PCT/JP2017/027461 WO2018021535A1 (ja) 2016-07-29 2017-07-28 システム、データ管理方法及びプログラム

Publications (2)

Publication Number Publication Date
JPWO2018021535A1 JPWO2018021535A1 (ja) 2019-05-23
JP7047760B2 true JP7047760B2 (ja) 2022-04-05

Family

ID=61016563

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018530424A Active JP7047760B2 (ja) 2016-07-29 2017-07-28 システム、データ管理方法及びプログラム

Country Status (3)

Country Link
US (1) US11212112B2 (ja)
JP (1) JP7047760B2 (ja)
WO (1) WO2018021535A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107734021B (zh) * 2017-09-30 2020-04-07 深圳壹账通智能科技有限公司 区块链数据上传方法、系统、计算机系统及存储介质
WO2019193449A1 (en) * 2018-04-03 2019-10-10 Voice Life Inc. Receiver device for facilitating wireless power reception
KR102232641B1 (ko) * 2017-12-13 2021-03-26 서강대학교산학협력단 블록체인 기반 IoT 환경에서의 다중 검색을 지원하는 데이터 구조체를 이용한 검색 방법 및 그 방법에 따른 장치
EP4287104A3 (en) * 2018-01-29 2024-01-17 Panasonic Intellectual Property Corporation of America Control method, controller, data structure, and electric power transaction system
CN108712257B (zh) * 2018-04-03 2020-04-17 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
US10972274B2 (en) * 2018-08-29 2021-04-06 International Business Machines Corporation Trusted identity solution using blockchain
US11240001B2 (en) * 2018-11-06 2022-02-01 International Business Machines Corporation Selective access to asset transfer data
KR102293076B1 (ko) * 2019-01-17 2021-08-25 정상수 블록체인을 이용한 운송장치의 모빌리티 데이터 수집 시스템과 이를 이용한 모빌리티 데이터 수집 방법 및 프로그램
US11763383B2 (en) 2019-05-30 2023-09-19 Nec Corporation Cryptocurrency system, terminal, server, trading method of cryptocurrency, and program
CN112529707B (zh) * 2020-12-15 2022-12-13 从法信息科技有限公司 基于实例选举共识的交易上链防错方法、装置和电子设备
CN116484348A (zh) * 2022-01-17 2023-07-25 中兴通讯股份有限公司 云数据安全认证方法、系统和计算机可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002215026A (ja) 2001-01-18 2002-07-31 Nippon Telegr & Teleph Corp <Ntt> 署名付き暗号通信方法及びその装置
WO2006137250A1 (ja) 2005-06-23 2006-12-28 Nec Corporation サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
JP2011024011A (ja) 2009-07-16 2011-02-03 Nec Corp 署名生成装置、署名人特定装置、グループ署名システム、およびそれらの方法とプログラム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7624432B2 (en) * 2005-06-28 2009-11-24 International Business Machines Corporation Security and authorization in management agents
WO2007105749A1 (ja) 2006-03-16 2007-09-20 Nec Corporation グループ署名システムおよび情報処理方法
US7818256B1 (en) * 2008-11-20 2010-10-19 Citibank, N.A. Digital receipt for electronic data and methods and systems for generating same
CN101873301B (zh) * 2009-04-22 2015-10-21 索尼株式会社 匿名注册系统以及方法
EP2441207B8 (fr) * 2009-06-12 2020-08-05 Orange Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
US10153908B2 (en) * 2010-04-30 2018-12-11 T-Central, Inc. Secure communication of IOT devices for vehicles
US10515409B2 (en) * 2016-03-23 2019-12-24 Domus Tower, Inc. Distributing work load of high-volume per second transactions recorded to append-only ledgers
US20160379212A1 (en) * 2015-06-26 2016-12-29 Intel Corporation System, apparatus and method for performing cryptographic operations in a trusted execution environment
GB201511963D0 (en) * 2015-07-08 2015-08-19 Barclays Bank Plc Secure digital data operations
US9948467B2 (en) * 2015-12-21 2018-04-17 Mastercard International Incorporated Method and system for blockchain variant using digital signatures
US10164952B2 (en) * 2016-02-16 2018-12-25 Xerox Corporation Method and system for server based secure auditing for revisioning of electronic document files
KR101637868B1 (ko) * 2016-02-22 2016-07-08 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
US9985964B2 (en) * 2016-03-28 2018-05-29 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
US20170344983A1 (en) * 2016-05-30 2017-11-30 Business Information Exchange System Corp. BIXCoin: A Secure Peer-to-Peer Payment System Based on the Public Payments Ledger
US11829998B2 (en) * 2016-06-07 2023-11-28 Cornell University Authenticated data feed for blockchains
US10411905B2 (en) * 2016-07-01 2019-09-10 Intel Corporation Public key infrastructure using blockchains

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002215026A (ja) 2001-01-18 2002-07-31 Nippon Telegr & Teleph Corp <Ntt> 署名付き暗号通信方法及びその装置
WO2006137250A1 (ja) 2005-06-23 2006-12-28 Nec Corporation サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
JP2011024011A (ja) 2009-07-16 2011-02-03 Nec Corp 署名生成装置、署名人特定装置、グループ署名システム、およびそれらの方法とプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
佐古 和恵 ほか，セキュリティとプライバシを両立させる匿名認証技術について，情報処理，日本，社団法人情報処理学会，2006年04月15日，第47巻，第4号，pp.410-416
淵田 康之，ブロックチェーンと金融取引の革新，野村資本市場クォータリー，日本，株式会社野村資本市場研究所，2015年11月01日，Vol.19，No.2，pp.11-35

Also Published As

Publication number Publication date
WO2018021535A1 (ja) 2018-02-01
JPWO2018021535A1 (ja) 2019-05-23
US11212112B2 (en) 2021-12-28
US20190165948A1 (en) 2019-05-30

Similar Documents

Publication Publication Date Title
JP7047760B2 (ja) システム、データ管理方法及びプログラム
Li et al. Efficient and privacy-preserving carpooling using blockchain-assisted vehicular fog computing
AU2022204758B2 (en) Network topology
CN109451467B (zh) 一种基于区块链技术的车载自组织网络数据安全共享与存储系统
Baza et al. A light blockchain-powered privacy-preserving organization scheme for ride sharing services
US20190295069A1 (en) Systems and methods for integrating cryptocurrency wallet identifiers with digital certificates
JP2007004461A (ja) サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
US20230006840A1 (en) Methods and devices for automated digital certificate verification
JP6504639B1 (ja) サービス提供システムおよびサービス提供方法
JP2022532578A (ja) ブロックチェーンを用いる公開鍵管理のための方法及び装置
Li et al. PriParkRec: Privacy-preserving decentralized parking recommendation service
CN114760114B (zh) 身份认证方法、装置、设备及介质
KR20140036395A (ko) 이동체의 군집 주행 서비스 인증 방법 및 그 장치
Kang et al. A privacy-preserving mobile payment system for mass transit
CN115801260A (zh) 一种不可信网络环境下区块链辅助的协作式攻防博弈方法
Yi et al. Location privacy-preserving mobile crowd sensing with anonymous reputation
Zhang et al. A privacy-preserving authentication scheme for VANETs based on consortium blockchain
Liu et al. Secure and scalable cross-domain data sharing in zero-trust cloud-edge-end environment based on sharding blockchain
US20230421543A1 (en) Method, apparatus, and computer-readable medium for secured data transfer over a decentrlaized computer network
CN117714111A (zh) 一种基于云监管的网约车通信方法及系统
Symeonidis et al. HERMES: Scalable, secure, and privacy-enhancing vehicular sharing-access system
Kaurav et al. Blockchain for emergency vehicle routing in healthcare services: An integrated secure and trustworthy system
CN114944953A (zh) 一种车联网环境下用于路况监测的无证书匿名认证方法
Zhang et al. A location-aware verifiable outsourcing data aggregation in multiblockchains
WO2017114914A1 (en) Peer-to-peer transaction authorization

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200602

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210810

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211005

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220307

R151 Written notification of patent or utility model registration

Ref document number: 7047760

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151