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

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

Info

Publication number
WO2018021535A1
WO2018021535A1 PCT/JP2017/027461 JP2017027461W WO2018021535A1 WO 2018021535 A1 WO2018021535 A1 WO 2018021535A1 JP 2017027461 W JP2017027461 W JP 2017027461W WO 2018021535 A1 WO2018021535 A1 WO 2018021535A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
node
taxi
public key
management server
Prior art date
Application number
PCT/JP2017/027461
Other languages
English (en)
French (fr)
Inventor
和恵 佐古
勇 寺西
Original Assignee
日本電気株式会社
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 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US16/320,621 priority Critical patent/US11212112B2/en
Priority to JP2018530424A priority patent/JP7047760B2/ja
Publication of WO2018021535A1 publication Critical patent/WO2018021535A1/ja

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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G06Q50/40—
    • 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/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/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

Definitions

  • the present invention is based on the priority claim of Japanese patent application: Japanese Patent Application No. 2016-150100 (filed on July 29, 2016), the entire contents of which are incorporated herein by reference. Shall.
  • the present invention relates to a system, a data management method, and a program.
  • the present invention relates to a system, a data management method, and a program that include a plurality of nodes, each of which transmits data.
  • a taxi dispatch system using a terminal such as a smartphone.
  • Multiple taxi companies participate in the taxi dispatch system, and each taxi company's taxi uses a dedicated taxi meter etc. to store data (operation management data) including its current location etc. into the management system (allocation server) Configured to send.
  • the management system knows the current location of each taxi from the operation management data. Each taxi company also accesses operation management data and uses it to understand the status of taxi operations. In the system configuration described above, when a customer operates his / her own terminal to request a taxi dispatch, the management system selects a taxi close to the customer in the service providing area and instructs the customer to pick up the vehicle.
  • Patent Document 1 discloses a service providing system in which a consignor can entrust a service for a member to an outsourcing company without giving the member information to the outsourcing company. Patent Document 1 describes that by using a group signature method, whether or not a user device is a member of a consignor device is verified only by public information of the consignor device.
  • Patent Document 2 describes that a group signature system and an information processing method are provided that reduce the amount of information processing when registering a user device in a group or withdrawing from a group.
  • Non-patent document 1 discloses a group signature method called the Camenisch-Groth method.
  • Non-Patent Document 2 describes the outline of the Camenisch-Groth method disclosed in Non-Patent Document 1.
  • JP 2007-004461 A Japanese Patent No. 5099003
  • the taximeter transmits the operation management data
  • a digital signature based on a public key infrastructure (PKI).
  • PKI public key infrastructure
  • the management system can confirm the validity of each taxi by verifying the digital signature.
  • the management system that accepts the operation management data verifies the validity of each taxi by verifying the digital signature attached to the operation management data.
  • the taxi that is the owner of the taxi is the same, so if the taxi company is identified from the public key certificate, the number of taxis belonging to each taxi company and the operation history can be specified. For example, by extracting operation management data found to belong to company A from a plurality of operation management data to which a digital signature is given, and counting the number of public keys applied to the extracted operation management data, The number of taxis of Company A participating in the taxi dispatch system is revealed. As described above, when the digital signature is used to guarantee the validity of the operation management data, the number of taxis owned by competitors can be grasped by using the operation management data and the public key certificate.
  • Each taxi company participating in the taxi dispatch system is inherently in a competitive relationship, and it is not desirable for such information to be known to other companies.
  • the object of the present invention is to provide a system, a data management method, and a program for appropriately restricting information obtained from the data while enabling verification of the validity of the data.
  • the management server includes a plurality of nodes that transmit data to which a group signature is attached, and a plurality of management servers that are directly connected to each other.
  • Each has a ledger for managing data received from the node, and the addition of data to the ledger by at least one management server among the plurality of management servers is reflected in the ledgers of other management servers
  • a system is provided.
  • a plurality of nodes each belonging to a group a plurality of node management servers managing nodes belonging to each group, and a group signature for each of the plurality of nodes
  • a system is provided for generating a group signature to be added to data using at least the administrator public key and a privileged person public key disclosed by each of the plurality of node management servers.
  • a third aspect of the present invention in a system including a plurality of nodes and a plurality of management servers that are directly connected to each other and have a ledger for managing data received from the nodes, the nodes Transmitting the data with the group signature, the management server receiving the data with the group signature, and the management server appending the received data to the ledger. And a step of reflecting the addition of data to the ledger by at least one management server among the plurality of management servers in a ledger of another management server.
  • This program can be recorded on a computer-readable storage medium.
  • the storage medium may be non-transient such as a semiconductor memory, a hard disk, a magnetic recording medium, an optical recording medium, or the like.
  • the present invention can also be embodied as a computer program product.
  • a system a data management method, and a program that contribute to appropriately restricting information obtained from the data while making it possible to verify the validity of the data.
  • the system includes a plurality of nodes 101 that transmit data to which a group signature is attached, and a plurality of management servers 102 that are directly connected to each other (see FIG. 1).
  • Each of the plurality of management servers 102 has a ledger for managing data received from the node 101.
  • the addition of data to the ledger by at least one management server 102 among the plurality of management servers 102 is reflected in the ledgers of the other management servers 102.
  • the system it is possible to verify the legitimacy of the subject that generated the data based on the group signature attached to the data.
  • the information obtained from the group signature is limited to the group (company or organization) to which the entity that generated the group signature belongs, and the generation entity cannot be uniquely specified. Therefore, the information obtained from the data and its signature is appropriately limited.
  • a taxi fare pre-prediction system for example, in addition to a system related to taxi dispatch, a taxi fare pre-prediction system, a taxi fare determination system, or a required time prediction system using travel data that can be extracted from a taxi meter meet the above requirements.
  • FIG. 2 is a diagram illustrating an example of a system configuration of the taxi dispatch system according to the first embodiment.
  • the taxi dispatch system includes a dispatch server 10, operation management servers 20-1 to 20- ⁇ ( ⁇ is a positive integer, the same applies hereinafter), and taxis 30-1 to 30 belonging to each taxi company.
  • - ⁇ ( ⁇ is a positive integer, the same shall apply hereinafter) and the data management system 40.
  • operation management servers 20-1 to 20- ⁇ they are simply expressed as “operation management server 20”.
  • taxi 30 when there is no particular reason for distinguishing each of the taxis 30-1 to 30- ⁇ .
  • the vehicle allocation server 10, the operation management server 20, and the data management system 40 are connected to each other via a network such as the Internet.
  • the taxi 30 is configured to be connectable to a network using a mobile line or the like.
  • the dispatch server 10 is a server installed in a taxi association or the like.
  • the dispatch server 10 is a device responsible for realizing the main functions of the taxi dispatch system.
  • the vehicle allocation server 10 refers to the operation management data managed by the data management system 40 and selects a taxi 30 that is close to the customer who requested the vehicle allocation (more precisely, the terminal used by the customer). . Thereafter, the dispatch server 10 issues a pick-up instruction to the selected taxi while designating the position of the customer.
  • the operation management server 20 is a device for managing the taxi 30 of the company in a taxi dispatch system in which a plurality of taxi companies participate.
  • the operation management server 20 corresponds to a “node management server” when the taxi 30 is a node included in the system.
  • the operation management server 20 performs procedures and preparations necessary for the company taxi 30 to participate in the taxi dispatch system (to become a member of the system). Specifically, the operation management server 20 generates information necessary for a group signature given when the taxi 30 of the company transmits operation management data to the data management system.
  • the operation management server 20 also has a function of referring to operation management data stored on an electronic bulletin board provided by the data management system 40 and managing the operation status of the company's taxi.
  • the taxi 30 corresponds to the node 101 described above.
  • the taxi 30 belongs to one of a plurality of taxi companies (groups) participating in the taxi dispatch system.
  • the taxi 30 is equipped with a taxi meter that uses a terminal such as a smartphone.
  • the taximeter generates operation management data and transmits the generated data to the data management system 40.
  • the taximeter assigns a group signature to the operation management data to be transmitted and transmits it to the data management system 40.
  • the taximeter displays the incoming instruction on the display and notifies the driver.
  • the data management system 40 is a system operated by a taxi association or an organization independent from each taxi company.
  • the data management system 40 is a system that provides an electronic bulletin board that can be additionally written and read out to the outside (third party).
  • the data management system 40 manages various types of information including operation management data using a so-called block chain.
  • the data management system 40 can add information to any subject by paying a predetermined fee, and can read out written information, and once written information is erased or altered. Provide an electronic bulletin board. More precisely, the data management system 40 is a system that provides an interface related to data input / output that can be handled from an external device like an electronic bulletin board.
  • information necessary for taxi dispatch (that is, operation management data) is exchanged via an electronic bulletin board provided by the data management system 40.
  • the data management system 40 is a system that provides an electronic bulletin board to a third party, the electronic bulletin board has data unrelated to the operation management data (for example, unrelated to taxi dispatch). Product sales data etc.).
  • the data management system 40 is composed of a plurality of management servers 50-1 to 50-4. 2 is not intended to limit the number of management servers constituting the data management system 40 to four.
  • the data management system 40 may be configured to include two or more management servers. Similarly to the operation management server 20 or the like, if there is no particular reason for distinguishing the management servers 50-1 to 50-4, they are simply expressed as “management server 50”.
  • the plurality of management servers 50 constituting the data management system 40 are directly connected to each other as shown in FIG.
  • the data management system 40 includes a plurality of management servers 50 connected by P2P (Peer to Peer).
  • each of the plurality of management servers 50 connected in P2P has a ledger (hereinafter referred to as a data management ledger) for managing data (operation management data, sales data, etc.) received from the outside.
  • a data management ledger for managing data (operation management data, sales data, etc.) received from the outside.
  • the data management system 40 distributes and manages the data management ledger among a plurality of management servers 50.
  • the data management system 40 provides a general-purpose electronic bulletin board widely to a third party, and therefore, data is exchanged with other than the dispatch server 10 or the like.
  • FIG. 3 is a block diagram illustrating an example of a hardware configuration of the vehicle allocation server 10 according to the first embodiment.
  • the vehicle allocation server 10 can be configured by an information processing device (computer) and has a configuration illustrated in FIG.
  • the dispatch server 10 includes a CPU (Central Processing Unit) 11, a memory 12, an input / output interface 13, and a NIC (Network Interface Card) 14 that are communication means, which are connected to each other via an internal bus.
  • the vehicle allocation server 10 may include hardware (not shown) or may not include the input / output interface 13 as necessary. Further, the number of CPUs and the like included in the dispatch server 10 is not limited to the example illustrated in FIG. 3. For example, a plurality of CPUs may be included in the dispatch server 10.
  • the memory 12 is a RAM (Random Access Memory), a ROM (Read Only Memory), or an auxiliary storage device (hard disk or the like).
  • the input / output interface 13 is a means to be an interface of a display device and an input device (not shown).
  • the display device is, for example, a liquid crystal display.
  • the input device is a device that accepts user operations such as a keyboard and a mouse, for example.
  • the function of the dispatch server 10 is realized by various processing modules described later.
  • the processing module is realized, for example, by the CPU 11 executing a program stored in the memory 12.
  • the program can be downloaded through a network or updated using a storage medium storing the program.
  • the processing module may be realized by a semiconductor chip. That is, it is sufficient if there is a means for executing the function performed by the processing module with some hardware and / or software.
  • the operation management server 20 and the management server 50 can also be configured by an information processing device in the same manner as the vehicle allocation server 10, and the basic hardware configuration is not different from the vehicle allocation server 10, so description thereof is omitted.
  • FIG. 4 is a diagram illustrating an example of a schematic configuration of the taxi 30.
  • the taxi 30 includes a taximeter 31 using a smartphone 32.
  • the taximeter 31 and the smartphone 32 are configured to be able to communicate with each other by short-range wireless communication such as Bluetooth (registered trademark) or wired connection using a cable.
  • the taximeter 31 uses its hardware (for example, access means to a mobile line or GPS (Global Positioning System) function) by communicating with the smartphone 32.
  • the taximeter 31 and the smartphone 32 are illustrated, but illustration of hardware that realizes a function as a taxi (vehicle) is omitted. Further, the hardware of the taximeter 31 and the smartphone 32 can be substantially the same as that of the information processing apparatus (computer), and since it is obvious to those skilled in the art, the description thereof is omitted.
  • FIG. 5 is a block diagram illustrating an example of a processing configuration of the dispatch server 10 according to the first embodiment.
  • the vehicle allocation server 10 includes a communication control unit 201, a storage unit 202, and a vehicle allocation processing unit 203.
  • the communication control unit 201 is means for realizing communication with other devices.
  • the communication control unit 201 is also means for distributing a message (packet) received from another device to each processing module unit or transmitting a message acquired from each processing module to another device.
  • the storage unit 202 stores, for example, data necessary for processing of the dispatch processing unit 203.
  • the vehicle allocation processing unit 203 is a means for processing a vehicle allocation request from a customer. Upon receiving a vehicle allocation request from a customer, the vehicle allocation processing unit 203 acquires operation management data from the data management system 40. For example, the vehicle allocation processing unit 203 requests the data management system 40 to read the operation management data stored in the electronic bulletin board during a predetermined period from a predetermined time in the past to the present, and acquires the operation management data. Alternatively, the vehicle allocation processing unit 203 may request the operation management data to be read from the data management system 40 by specifying the amount of data to be acquired. The vehicle allocation processing unit 203 determines a taxi 30 to be directed to the customer based on the acquired operation management data, and issues a pick-up instruction to the taxi 30.
  • the vehicle allocation processing unit 203 includes two submodules, a signature verification unit 211 and an incoming vehicle determination unit 212.
  • the signature verification unit 211 is a means for verifying the group signature given to the operation management data acquired from the data management system 40. As will be described later, since the operation management server 20 of each taxi company publishes the administrator public key and the privileged person public key, the signature verification unit 211 performs the public key of each taxi company (administrator public key, privileged person public key). The group signature attached to the operation management data is verified using a key. The verification of the group signature can be performed according to the “group signature verification algorithm” shown in FIG.
  • the signature verification unit 211 delivers the data to the arrival determination unit 212. If the validity of the operation management data cannot be confirmed as a result of the verification, the signature verification unit 211 discards the data.
  • the signature verification unit 211 performs the verification processing as described above on the acquired operation management data, and passes the data whose validity has been confirmed to the arrival determination unit 212.
  • the incoming vehicle determination unit 212 is a means for determining the taxi 30 that issues an incoming vehicle instruction using the operation management data whose validity has been confirmed. For example, the arrival vehicle determination unit 212 compares the current position of the customer who requested the vehicle allocation with the current position of the taxi 30 included in the operation management data, and specifies the operation management data including the current location closest to the customer. As will be described later, since the operation management data includes message notification destinations (for example, e-mail addresses) of each taxi 30, the arrival determination unit 212 issues a pickup instruction to the notification destination obtained from the specified operation management data. Do. At that time, the incoming vehicle determination unit 212 includes the current location of the customer in the incoming vehicle instruction.
  • message notification destinations for example, e-mail addresses
  • the operation management server 20 according to the first embodiment has a function of issuing a member certificate to be distributed to a group member (taxi 30) and a function of specifying the taxi 30 that has generated the operation management data. That is, the operation management server 20 according to the first embodiment has a role as “manager” and a role as “privileged” described in Non-Patent Document 2.
  • FIG. 6 is a block diagram illustrating an example of a processing configuration of the operation management server 20 according to the first embodiment.
  • the operation management server 20 includes a communication control unit 301, a storage unit 302, and a certificate management unit 303.
  • the functional module for confirming the operation condition of the taxi 30 which belongs to the own group is abbreviate
  • the communication control unit 301 is means for realizing communication with other devices.
  • the communication control unit 301 is also means for distributing a message (packet) received from another device to each processing module unit or transmitting a message acquired from each processing module to another device.
  • the storage unit 302 stores information necessary for key generation and member certificate generation by the certificate management unit 303.
  • the certificate management unit 303 is a means for generating and managing information necessary for generating a group signature that the taxi 30 of the company gives to the operation management data.
  • the certificate management unit 303 includes two submodules, a key generation unit 311 and a certificate generation unit 312.
  • the key generation unit 311 generates a pair of an administrator public key and an administrator secret key and a pair of a privileged person public key and a privileged person secret key used for the group signature.
  • the key generation unit 311 discloses the administrator public key and the privileged person public key.
  • the released administrator public key is acquired by at least the dispatch server 10.
  • the privileged person public key is acquired at least by each taxi 30 and the dispatch server 10 of the company.
  • the certificate generation unit 312 is a means for generating and issuing a “member certificate” required when the taxi 30 of the company generates a group signature.
  • the certificate generation unit 312 generates a member certificate in cooperation with the certificate acquisition unit 403 of the taximeter 31 described later, and distributes the generated member signature to the taxi 30.
  • each taxi 30 determines its public key, private key, and the validity of the public key using the administrator private key. Get a guaranteed member certificate.
  • the function for the taxi 30 to participate in the taxi dispatch system is realized by the taximeter 31. Therefore, the processing configuration of the taximeter 31 will be described below.
  • FIG. 7 is a block diagram showing an example of the processing configuration of the taximeter 31 according to the first embodiment.
  • the taximeter 31 includes a communication control unit 401, a storage unit 402, a certificate acquisition 403, and an operation management data processing unit 404.
  • the communication control unit 401 is means for controlling communication with the smartphone 32 and realizing communication with other devices.
  • the communication control unit 401 is also means for distributing a message (packet) received from another device to each processing module unit or transmitting a message acquired from each processing module to another device.
  • the storage unit 402 stores data necessary for generating a group signature.
  • the certificate acquisition unit 403 is a unit that creates a member certificate in cooperation with the certificate generation unit 312 of the operation management server 20 and acquires the member certificate from the operation management server 20.
  • the member certificate acquired from the operation management server 20 is stored in the storage unit 402.
  • the certificate acquisition unit 403 generates a key (secret key) necessary for generating the member certificate.
  • the operation management data processing unit 404 is a means for generating operation management data and transmitting the generated operation management data to the data management system 40.
  • the operation management data processing unit 404 includes two submodules, an operation management data generation unit 411 and a group signature generation unit 412.
  • the operation management data generation unit 411 is a means for generating operation management data.
  • the operation management data includes at least information capable of grasping the current position of the vehicle and a message notification destination (for example, an e-mail address). For example, as shown in FIG. 8, information related to the place where the customer is placed (boarding position), information related to the place where the customer was dropped off (drop-off position), information related to the current position of the host vehicle, and a message notification destination that transmits an arrival instruction. Information etc. are included in the operation management data.
  • a disposable mail address or the like that can be used only for a predetermined period as the message notification destination.
  • the “exit position” and the “current position” are included in the operation management data in consideration of the case where the get-off position and the current position do not match.
  • the operation management data illustrated in FIG. 8 is an example, and is not intended to limit the contents of the operation management data.
  • the information regarding the boarding position and the getting-off position may not be included in the operation management data, and other information (for example, time and distance traveled on the customer's boarding and getting-off) may be included.
  • the operation management data generation unit 411 acquires information on the “position” described in the operation management data, for example, by a GPS built in the smartphone 32.
  • the operation management data generation unit 411 sets the position information obtained by the GPS of the smartphone 32 as the boarding position when, for example, an operation to the effect that the driver has placed the customer is performed on the touch panel or the like.
  • the operation management data generation unit 411 may generate the operation management data at a predetermined time or a predetermined interval, or may generate the operation management data at a timing when the customer is dropped. That is, the operation management data may be generated periodically, or the operation management data may be generated in response to an event such as dropping a customer.
  • the operation management data generation unit 411 delivers the generated operation management data to the group signature generation unit 412.
  • the group signature generation unit 412 is a means for generating a group signature to be added to a message to be transmitted (operation management data).
  • the group signature generation unit 412 generates a group signature using the private key generated by the certificate acquisition unit 403, the member certificate acquired from the company's operation management server 20, and the privileged person public key.
  • the generation of the group signature can be performed according to the “group signature creation algorithm” shown in FIG.
  • the operation management data processing unit 404 adds a group signature to the generated operation management data and transmits it to the data management system 40 (requests addition to the electronic bulletin board). At that time, the operation management data processing unit 404 gives an identifier for identifying that the data is used in the taxi dispatch system to the operation management data.
  • Non-Patent Document 1 the disclosure of Non-Patent Document 1 can be referred to.
  • a schematic operation when a group signature is introduced into a taxi dispatch system according to the description of Non-Patent Document 2 will be described with reference to the drawings.
  • N product of two prime numbers A, a, b: current g of remainder ring, u: element of prime number field H: hash function c: hash value P, p, q: prime numbers r, s, x, ⁇ , ⁇ , ⁇ : Random number k: Integer
  • each taxi company is treated as one group.
  • a plurality of members (taxi) belong to one group (taxi company).
  • the operation management server 20 of each taxi company When participating in the taxi dispatch system, the operation management server 20 of each taxi company generates a pair of an administrator public key and an administrator private key, and a privileged person public key and privileged person private key pair.
  • the administrator public key, the privileged person public key, the administrator secret key, and the privileged person secret key are defined as in the following formulas (1) to (4).
  • Administrator public key: gpk 1 (N, a 0 , a 1 , a 2 , k e , H) (1)
  • Privileged public key: gpk 2 (g 1 , g 2 , g 3 , P, q) (2)
  • N p 1 p 2
  • G 2 g 1 y mod P (4)
  • Each taxi company (operation management server 20) discloses the administrator public key and the privileged person public key.
  • an identifier (ID) is assigned to each taxi 30 belonging to each taxi company.
  • the process related to member registration is executed between each taxi company (operation management server 20) and the taxi 30.
  • the user public key and secret key are defined as in the following formulas (5) and (6).
  • User public key: h g 2 x mod P (5)
  • User secret key: (x, r) st . A 0 a 1 x a 2 r A e mod N (6)
  • the certificate acquisition unit 403 of each taxi 30 generates a secret key as shown in the above equation (6), and generates information converted from the generated secret key. Specifically, as described in Non-Patent Document 2, the certificate acquisition unit 403 randomly selects x and r ′, and generates information represented by the following formula (7). A ′ ⁇ a 1 x a 2 r ′ mod N (7) The certificate acquisition unit 403 transmits the information shown in (7) (information obtained by converting the secret key) and the public key shown in (5) to the operation management server 20.
  • the certificate generation unit 312 of the operation management server 20 generates a member certificate represented by the following formula (8) according to the protocol described in FIG. Member certificate: (A, e) (8)
  • Each taxi 30 prepares a member certificate issued from the operation management server 20 and the generated secret key for generating a group signature.
  • the member certificate (Ai, ei) and the private key sk (i) transmitted to each taxi become the group signature generation private key sk (gs) for each taxi 30.
  • the group signature generation unit 412 of the taxi (i) generates a group signature.
  • the taxi (i) having the member certificate (Ai, ei) receives the group signature generation private key sk (gs) for the message M, which is the operation management data, when generating the group signature. ) And the privileged person public key are applied to generate a group signature sig (i, M).
  • the group signature generation unit 412 calculates information shown in the following equations (9) and (10) after randomly selecting s and ⁇ . b ⁇ a 2 s A mod N (9) (U 1 , u 2 , u 3 ) ⁇ (g 1 ⁇ , hg 2 ⁇ , g 3 ⁇ + e ′ ) mod P (10)
  • the group signature generation unit 412 randomly selects ⁇ x , ⁇ r , ⁇ ′ e , ⁇ ⁇ , and obtains a group signature by the following equations (11) to (16).
  • ⁇ x ⁇ x + cx
  • ⁇ r ⁇ r + c (r + se)
  • ⁇ ′ e ⁇ ′ e + ce ′
  • ⁇ ⁇ ⁇ ⁇ + c ⁇ mod q
  • Sig (b, u 1 , u 2 , u 3 , c, ⁇ x , ⁇ r , ⁇ ′ e , ⁇ ⁇ ) (16)
  • This group signature has a member certificate issued by the subject having the correct administrator private key corresponding to the taxi company's administrator public key, and the taxi (i) is correct corresponding to the privileged person public key. It has a zero-knowledge proof function that ensures that a member certificate can be correctly specified by a subject having a privileged person private key.
  • the signature verification unit 211 of the dispatch server 10 verifies the group signature given to the operation management data. Specifically, the signature verification unit 211 verifies the group signature using the administrator public key and the privileged person public key disclosed by each taxi company. More specifically, the signature verification unit 211 verifies the group signature depending on whether the following equations (17) to (19) are satisfied.
  • the operation management data with the group signature will be sent to the company A participating in the taxi dispatch system. It turns out to be a legitimate member.
  • Company A can identify the operation management data generated by any taxi belonging to the company from the group signature (the company's taxi can be identified).
  • the vehicle allocation server 10 or the like cannot identify the taxi 30 in which the operation management data is written on the electronic bulletin board only by the above verification. That is, by using the group signature, the information that can be grasped by the dispatch server 10 or the like is limited to information related to the legitimacy of the taxi 30 in which the operation management data is written on the electronic bulletin board.
  • the dispatch server 10 can confirm the validity of the operation management data (guaranteed to be a member of a taxi company having a right to participate in the system), and If the current position of the taxi 30 and the message notification destination can be grasped, there is no problem in the operation of the system.
  • the taxi 30 to which the group signature is assigned can be uniquely specified by using the privileged person private key.
  • the taxi company (operation management server 20) can extract the member certificate of each taxi 30 by converting the data included in the group signature using the privileged person private key.
  • the taxi company can specify the ID of the taxi 30 from the retrieved member certificate.
  • the taxi company can acquire operation management data from the data management system 40 and uniquely identify the taxi 30 that has transmitted the operation management data from the group signature (members can be tracked). As a result, the taxi company can know the details of the operation status, operation status, etc. for each taxi 30 of the company.
  • FIG. 11 is a block diagram illustrating an example of a processing configuration of the management server 50 according to the first embodiment.
  • the management server 50 includes a communication control unit 501, a storage unit 502, and a ledger management unit 503.
  • the communication control unit 501 is means for realizing communication with other devices.
  • the communication control unit 501 is also means for distributing a message (packet) received from another device to each processing module unit or transmitting a message acquired from each processing module to another device.
  • the storage unit 502 is a means for storing information necessary for processing of each processing module.
  • the storage unit 502 includes a temporary storage area for temporarily storing data and an area for storing a data management ledger.
  • the ledger management unit 503 is a means for processing an access request from the dispatch server 10 or the taxi 30 to the electronic bulletin board. Specifically, for example, when a request for writing operation management data from the taxi 30 to the electronic bulletin board is received, the operation management data is added to the data management ledger stored in the storage unit 502.
  • the ledger management unit 503 searches the data management ledger using an identifier (identifier indicating data for taxi dispatch system) associated with the request as a key, and Data with an identifier (that is, operation management data) is extracted. At that time, when the operation management data read range is designated, the ledger management unit 503 extracts operation management data that conforms to the read range.
  • the ledger management unit 503 transmits the extracted operation management data to the dispatch server 10 or the like.
  • the ledger management unit 503 has two submodules, a block generation unit 511 and a block verification unit 512.
  • the block generation unit 511 generates a block for sharing and managing the data management ledger with other management servers 50.
  • the ledger management unit 503 When the ledger management unit 503 acquires the operation management data from the taxi 30 or the like, the ledger management unit 503 stores the acquired operation management data in the temporary storage area of the storage unit 502. After that, the block generation unit 511 reads the “validity from the header of the block generated immediately before and the data stored in the temporary storage area (for example, operation management data and sales data; additional data to the data management ledger). "Guaranteed data" is generated. For example, when the block generation unit 511 calculates the hash value of the postscript data, the header of the previous block, and the validity guarantee data, a value that makes the calculated hash value conform to a predetermined rule (so-called nonce value or Nonce value) is generated as the validity guarantee data. Further, the validity guarantee data includes the electronic signature of the management server 50 that generated the block.
  • the block generation unit 511 generates a block having a header including the header of the block generated immediately before and the above-described validity guarantee data. Specifically, a block as shown in FIG. 12 is generated.
  • the block generation unit 511 distributes (transmits) the generated block to the other management server 50 via the communication control unit 501.
  • the communication control unit 501 of the management server 50 that has received the block from the other management server 50 delivers the acquired block to the block verification unit 512.
  • the block verification unit 512 is a unit that verifies the validity of the block transmitted by the other management server 50 based on the data management ledger (block) stored in the storage unit 502 of the own device. Specifically, the block verification unit 512 of the management server 50 that has received the block determines the validity of the received block by comparing the block generated by the management server 50 that has transmitted the block with its own device (the management server 50 that has received the block). ) Is verified using the header of the block generated immediately before management.
  • the block verification unit 512 confirms that the electronic signature of the management server 50 serving as the transmission source is added to the validity guarantee data included in the received block, and the “previous block” described in the received block Is specified based on the data management ledger managed by itself. Thereafter, the block verification unit 512 receives the additional data in the received block and the header of the previous block as input, and checks whether the validity guarantee data in the header is consistent (the validity guarantee data conforms to a predetermined rule). To check).
  • the block verification unit 512 determines that the block transmitted by the other management server 50 is valid if the integrity of the validity guarantee data can be confirmed. On the other hand, if the integrity of the validity guarantee data cannot be confirmed, the block verification unit 512 determines that the block transmitted by the other management server 50 is invalid.
  • the ledger management unit 503 updates the data management ledger in the storage unit 502 (adds a block including additional data) To do). That is, the block verification unit 512 performs a process of reflecting the addition of data to the ledger of another management server 50 in the ledger of its own device. If the block verification unit 512 determines that a block transmitted by another management server 50 is invalid, the block verification unit 512 discards the block.
  • the block verification unit 512 notifies the management server 50 that has transmitted the block of information regarding the verification result (the received block is valid or invalid).
  • the operation of the management server 50 is summarized as shown in the sequence diagram of FIG. FIG. 13 shows a case where the management server 50-1 acquires operation management data from the taxi 30 and adds the data to the data management ledger.
  • the management server 50-1 When the management server 50-1 acquires the operation management data from the taxi 30 (step S101), the management server 50-1 copies the data to a partial storage area of the storage unit 502 of the own device (step S102).
  • the management server 50-1 generates the above-described block based on the operation management data stored in the temporary storage area under the condition that a predetermined amount of data copied in the partial storage area is accumulated (step S1). S103). Thereafter, the management server 50-1 transmits the generated block to the other management servers 50-2 to 50-4 (step S104).
  • Each of the management servers 50-2 to 50-4 that received the block individually verifies the block generated by the management server 50-1 (step S105).
  • Each of the management servers 50-2 to 50-4 updates its own data management ledger when the validity of the block is confirmed (step S106).
  • the addition of data to the data management ledger by at least one management server 50 among the plurality of management servers 50 constituting the data management system 40 is reflected in the data management ledgers of the other management servers 50.
  • the ledger management unit 503 of the management server 50 retrieves the state of the data management ledger before the block transmission.
  • FIG. 14 is a sequence diagram showing an example of the setup operation in the taxi dispatch system.
  • each taxi company When starting operation of the taxi dispatch system, each taxi company generates the above two public key / private key pairs (step S01). Thereafter, the taxi company discloses the administrator public key and the privileged person public key.
  • Each taxi 30 generates a secret key necessary for generating a group signature (step S02). Thereafter, each taxi 30 transmits information obtained by converting the generated secret key to the taxi company (operation management server 20).
  • the taxi company (operation management server 20) generates a signature using the privileged person private key for the information obtained by converting the acquired private key, and generates a member certificate (step S03).
  • the generated member certificate is transmitted to each taxi 30.
  • the setup process shown in FIG. 14 is executed for each taxi company that participates in the taxi dispatch system, and the preparation for system operation is completed. Further, when a new taxi company joins the system, the setup process shown in FIG. 14 is executed for the taxi company.
  • FIG. 15 is a sequence diagram showing an example of operations related to the operation of the taxi dispatch system.
  • the taxi 30 in the service providing area of the taxi dispatch system generates operation management data when a predetermined condition is satisfied (step S11).
  • the taxi 30 generates a group signature of the generated operation management data (step S12).
  • the taxi 30 gives a group signature to the operation management data and transmits the data to the data management system 40 (step S13).
  • the management server 50 of the data management system 40 adds the received operation management data to the data management ledger (step S14).
  • the information including the current position of each taxi 30 is accumulated on the electronic bulletin board of the data management system 40 by repeating the processing of steps S11 to S14.
  • the vehicle allocation server 10 When the vehicle allocation server 10 receives a vehicle allocation request including the current location of the customer, the vehicle allocation server 10 acquires operation management data within a predetermined range from the data management system 40 (step S15). Thereafter, the vehicle allocation server 10 verifies the group signature for each of the acquired operation management data (step S16), and confirms whether the operation management data is generated by the taxi 30 belonging to the taxi company participating in the system. The vehicle allocation server 10 identifies the current position of the taxi 30 close to the customer who requested the vehicle allocation from the operation management data whose validity has been confirmed, and issues an incoming call instruction to the taxi 30 (step S17).
  • the group signature is used to determine the validity of the operation management data generation subject.
  • the group signature it can be determined whether or not the operation management data generating entity is a member of a taxi company having a valid qualification to participate in the taxi dispatch system.
  • the taxi 30 that has generated the operation management data cannot be uniquely identified only by the verification based on the group signature. Such identification is possible only for taxi companies that are group managers. That is, the information obtained from the data is appropriately limited while the validity of the operation management data can be verified.
  • the vehicle allocation server 10 verifies the group signature by using the administrator public key and the privileged person public key disclosed by each taxi company.
  • taxi companies can know the administrator public key and privileged person public key that each taxi company discloses, so other companies can verify the group signature attached to the operation management data.
  • company B since company B can know the manager public key and privileged person public key of company A, the verification of the group signature given by taxi 30 belonging to company A is performed by the manager of company A. If it succeeds with the public key and the privileged person public key, the company B can know the fact that the operation management data with the group signature is generated by the taxi 30 of the company A.
  • the operation status of the taxi 30 of the company A can be grasped by the company B repeating the above verification regarding the operation management data stored in the data management system 40 and its group signature.
  • the sales policy of Company A may be revealed by analyzing the information. For example, there is a possibility that information regarding the taxi operation status by time zone or by area regarding Company A can be created.
  • the operation management data and the information obtained from the signature are restricted to the affiliated company of each taxi, but the restriction may be insufficient. That is, it is sufficient that the operation management data generation entity can verify whether or not it is eligible to participate in the taxi dispatch system, and the group (taxi company) to which the generation entity belongs cannot be grasped from the group signature. Is desirable.
  • the second embodiment solves the above problem by separating the member registration function (member certificate issuing function) and the tracking function (in-house taxi identification function) in the group signature.
  • the taxi association performs member registration.
  • each taxi company can identify its taxi from the group signature as in the first embodiment.
  • a certificate management server 60 installed in a taxi association or the like is added to the system configuration shown in FIG. 2 (see FIG. 16).
  • FIG. 17 is a diagram illustrating an example of a processing configuration of the certificate management server 60 according to the second embodiment.
  • the certificate management server 60 includes a communication control unit 601 and a storage unit 602 that are the same as other devices. Further, the certificate management server 60 includes a certificate management unit 603.
  • the certificate management unit 603 includes two submodules, a key generation unit 611 and a certificate generation unit 612. The operation of the certificate management server 60 including the submodule will be described later.
  • the member certificate is generated by the operation management server 20, but since the function is performed by the certificate management server 60, the operation management server 20 according to the second embodiment includes a certificate. There is no generation unit (see FIG. 18). However, as will be described later, since the operation management server 20 has a function of generating and disclosing the privileged person public key, the operation management server 20 according to the second embodiment includes the privileged person public key and the privileged user secret. A key generation unit 311a for generating a key is included.
  • FIG. 19 is a diagram for explaining generation of a group signature according to the second embodiment.
  • the key generation unit 611 of the certificate management server 60 generates a pair of an administrator public key and an administrator private key, and publishes the administrator public key.
  • the operation management server 20 (key generation unit 311a) of each taxi company generates a privileged person public key and privileged person private key pair, and discloses the privileged person public key.
  • Each taxi company and its taxi 30 generate and acquire a member certificate by the same method as in the first embodiment.
  • the taxi 30 generates a group signature attached to the operation management data, but the generation method of the group signature is different between the first and second embodiments.
  • the group signature sig (i, M) of the operation management data (message M) is generated, it is created using the member certificate and the company's privileged person public key (see FIG. 10).
  • each taxi 30 inputs the privileged person public keys of all taxi companies in order to conceal which privileged person public key was used (see FIG. 20).
  • the group signature is “the public key registered correctly with zero knowledge leaked about the public key and that the user is the owner of this public key. It is a technology that shows ".” And the realization of this technology is “zero to certify that the public key is encrypted and that the member certificate exists in the public key and that the encrypted person has a private key corresponding to this public key. It is necessary to give "knowledge proof data”. However, in this case, it is necessary to inform the verifier which privileged person public key was used to encrypt his public key. However, by telling the fact (the privileged person public key used), the affiliation of each taxi 30 becomes clear.
  • the group signature generation unit 412 uses the privileged person public keys of all taxi companies (in the example of FIG. 19, gpk 2A , gpk 2B ,... ⁇ ) Is used as input to generate a group signature.
  • a group signature “Encrypt your public key with one of the privileged person's public keys, and that there is a member certificate in the public key, and the encrypted person (subject) has a private key corresponding to this public key. "Zero knowledge proof data that proves possession" is given.
  • the zero knowledge proof is configured based on the equations (1) to (20) described in the first embodiment, the following is obtained.
  • the taxi 30 belonging to the taxi company A generates a group signature is illustrated.
  • the number of taxi companies (groups) included in the system is not limited.
  • the privileged person public key, the administrator private key, and the privileged person private key shown in the above formulas (1) to (4) in the second embodiment, the privileged person public key and the privileged person private key are used. Is different from the first embodiment. Specifically, as many privileged person public keys as shown in Equation (2) are prepared. At that time, (g 1 , g 3 , P, q) among the privileged person public keys shown in Expression (2) is information regarding parameters, and is set in common to all taxi companies. What differs for each taxi company is the element g 2 generated depending on the privileged person private key. For example, the privileged person public key of company A is expressed by equation (21), and the privileged user public key of company B is expressed by equation (22).
  • the privileged person secret key of taxi company A corresponding to equation (21) is yA
  • the privileged person secret key of taxi company B corresponding to equation (22) is yB.
  • the user public key (public key of each taxi 30) shown in the above equation (5) is generated according to the company's privileged person public key.
  • the user public key related to the taxi 30 of company A is given by equation (23)
  • the user public key related to the taxi 30 of company B is given by equation (24).
  • Public key of company A taxi: h g 2A x mod P (23)
  • Public key of company B taxi: h g 2B x mod P (24)
  • the user public key is obtained by multiplying the element g 2 (company A; element g 2A , company B; element g 2B ) included in the privileged person public key of the taxi company to which the user belongs by x power. Generated.
  • the member certificate issuance is the same as in the first embodiment as described above.
  • elements used for generating u 2 are different from those in the first embodiment.
  • the following formula (25) is used. (U 1 , u 2 , u 3 ) ⁇ (g 1 v , hg 2A v , g 3 v + c ′ ) mod P (25)
  • g 2A in the equation (25) becomes g 2B .
  • c B and c C are also randomly selected. Select and use for group signature calculation.
  • c B, c C is a hash value c calculated by the following equation (27) challenge value c A of company A, challenge value c B of company B, the challenge value c C of C company Assuming that it is divided, it is selected at random.
  • zero knowledge proof consists of three processes of commit, challenge, and response, and usually one hash value is used for the challenge.
  • the value obtained by the above equation (26) becomes a part of the input parameter of the hash function H as shown in the following equation (27).
  • the privileged person public keys of all taxi companies are used for generating the group signature. Therefore, instead of the privileged person public key gpk 2 of the equation (13) described in the first embodiment, the privileged person public keys gpk 2A , gpk 2B , and gpk 2C of the respective taxi companies in the above equation (27) It becomes an input parameter.
  • ⁇ xA ⁇ x + c A x
  • ⁇ xB ⁇ x + c B x
  • ⁇ xC ⁇ x + c c x
  • ⁇ ⁇ A ⁇ ⁇ + c A ⁇
  • ⁇ ⁇ B ⁇ ⁇ + c B ⁇
  • ⁇ ⁇ C ⁇ ⁇ + c c ⁇ ⁇
  • a signature is generated by the following equation (30) using the values calculated by the above equations (28) and (29).
  • Sig (b, u 1, u 2, u 3, c A, c B, c C, ⁇ xA, ⁇ xB, ⁇ xC, ⁇ r, ⁇ 'e, ⁇ ⁇ A, ⁇ ⁇ B, ⁇ ⁇ C) ⁇
  • parameters c used for signature generation are c A , c B , c C , and ⁇ x is ⁇ xA , ⁇ xB.
  • ⁇ ⁇ is ⁇ ⁇ A, ⁇ ⁇ B, to ⁇ ⁇ C, it has become each change.
  • the signature verification according to the second embodiment is performed by the following equations (31) to (33).
  • the taxi 30 is specified by the following equation (35).
  • h u 2 / u 1 yA (35)
  • YA in Expression (35) is a privileged person secret key of taxi company A.
  • the verification of the group signature generated as described above can be performed using the administrator public key released from the certificate management server 60 and the privileged person public key released by each taxi company.
  • the group signature generated by the taxi 30 of the company A includes the administrator public key gpk 1 , the privileged public key gpk 2A of the company A, the privileged public key gpk 2B of the company B, and the privileged public key gpk 2C of the company C.
  • a privileged public key released by the privileged users of all groups is required. Whether the corresponding member certificate is possessed is kept secret.
  • the taxi 30 that has generated the operation management data can be specified only by a taxi company having a privileged person private key paired with the privileged person public key used for generating the group signature. That is, each taxi company can uniquely identify the taxi that generated the group signature and operation management data from the group signature generated by its taxi.
  • a plurality of taxis 30 belonging to a taxi company that participates in a taxi dispatch system are regarded as one group, and a taxi association that is a higher-level organization of the taxi company is a member of each taxi 30. Issue a certificate.
  • the group signature generated using the member certificate and the privileged person public key published by all taxi companies participating in the taxi dispatch system is based on the administrator public key published by the taxi association and the above-mentioned plural privileged person public keys. It can be verified.
  • the fact that the group signature generator whose validity was verified by the group signature is qualified to participate in the taxi dispatch system (whether or not the taxi association has accepted as a member) It remains to be found.
  • Each taxi company has a member tracking function for uniquely identifying the taxi 30 that generated the group signature. Specifically, the generation and management of the privileged person public key used when each taxi 30 generates the group signature is left to the taxi company (operation management server 20). As a result, data can be extracted from the group signature and each taxi can be specified only by the company to which each taxi 30 belongs. As described above, in the second embodiment, by properly separating the member registration function and the member tracking function in the group signature, both verification of data validity and restriction of information to be disclosed are compatible.
  • the system configurations described in the first and second embodiments are merely examples, and are not intended to limit the system configurations.
  • a server device that manages member revocation may be included in the system as necessary.
  • the data management system 40 includes a plurality of management servers 50, and the management server 50 manages operation management data using a so-called block chain technology.
  • substantially one server or the like may manage operation management data intensively.
  • the data management system 40 is an organization independent of the taxi association, but the data management system 40 may be operated under the management of the taxi association. Of course it is good.
  • Non-Patent Documents 1 and 2 the group signature scheme (Camenisch-Groth scheme) described in Non-Patent Documents 1 and 2 has been described as an example. However, other group signature schemes can be used. Of course. In particular, regarding the second embodiment, by dividing the challenge in the existing group signature scheme, by constructing an ORprof that “is a correct group signature for any one privileged person public key”, Non-Patent Document 1 It is obvious that the present invention can also be realized based on another group signature scheme different from the schemes 1 and 2 (Camenisch-Groth scheme).
  • the plurality of nodes belong to one of a plurality of groups, A plurality of node management servers for managing nodes belonging to each of the plurality of groups; Preferably, each of the node management servers issues a member certificate used for generating a group signature to the nodes belonging to the group.
  • the plurality of nodes belong to one of a plurality of groups, A plurality of node management servers for managing nodes belonging to each of the plurality of groups; A certificate management server that issues a member certificate used when generating a group signature to each of the plurality of nodes; Each of the plurality of node management servers publish a privileged person public key, Preferably, the certificate management server publishes an administrator public key.
  • the node Preferably, the node generates a group signature using the administrator public key and a privileged person public key disclosed by each of the plurality of node management servers.
  • the generated group signature can be verified by an administrator public key released by the certificate management server and a privileged person public key released by each of the plurality of node management servers.
  • the node management server extracts data included in a group signature generated by a node belonging to a group managed by the node management server using a privileged person private key paired with the privileged person public key, and selects a node belonging to the group managed by the node management server.
  • [Form 7] This is the same as the system according to the second viewpoint described above.
  • the group signature generated by the node is obtained by encrypting the public key of the node that generated the group signature with any one of the privileged person public keys disclosed by the plurality of node management servers, and adding a member certificate to the public key of the node.
  • the system of aspect 7 comprising data certifying that the certificate exists and that the encrypted entity has a private key corresponding to its own public key.
  • the privileged person public key disclosed by the plurality of node management servers is a public key generated so that some elements are common, preferably the system according to modes 7 and 8.
  • the common partial element is an element generated depending on a privileged person private key corresponding to the privileged person public key.
  • the public key of the node is generated based on the common partial element, preferably the system of form 10.
  • the node randomly selects a challenge value of a group different from the group to which the node belongs, and generates the group signature using the randomly selected challenge value, preferably according to any one of forms 7 to 11 The described system.
  • Verification of the group signature generated by the node includes at least verification using the calculated hash value, the randomly selected challenge value, and the challenge value of the group to which the node that generated the group signature belongs.
  • the system of form 12 is as the data management method according to the third aspect described above.
  • [Form 15] It is as the program which concerns on the above-mentioned 4th viewpoint. It is to be noted that form 14 and form 15 can be developed like form 2 to form 6 as with form 1.
  • Vehicle allocation server 11
  • CPU Central Processing Unit
  • Memory 13
  • Input / output interface 14
  • NIC Network Interface Card
  • 20-1 to 20- ⁇ Operation management server 30, 30-1 to 30- ⁇ Taxi 31 Taximeter
  • Smartphone 40 Data management system 50, 50-1 to 50-4, 102
  • Certificate management server 101 Nodes 201, 301, 401, 501, 601 Communication control units 202, 302, 402, 502, 602 Storage unit 203
  • Vehicle dispatch processing unit 211
  • Signature verification unit 212
  • Pick-up decision unit 303
  • 603 Certificate management unit 311, 311a, 611 Key generation Units 312 and 612 certificate generation unit 403 certificate acquisition unit
  • operation management data processing unit 411 operation management data generation unit 412 group signature generation unit 421
  • ring group signature generation unit 503 ledger management unit 511 block generation unit 512 block verification unit

Abstract

データの正当性を検証可能としつつ、当該データから得られる情報を適切に制限するシステムを提供する。システムは、グループ署名が付与されたデータを送信する、複数のノードと、相互に直接接続されている、複数の管理サーバと、を含む。複数の管理サーバのそれぞれは、ノードから受信したデータを管理するための台帳を有する。複数の管理サーバのうち少なくとも１つの管理サーバによる台帳へのデータの追記は他の管理サーバの台帳に反映される。

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 JPOXMLDOC01-appb-I000001

Figure JPOXMLDOC01-appb-I000002

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

Figure JPOXMLDOC01-appb-I000005

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

Figure JPOXMLDOC01-appb-I000008

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

Figure JPOXMLDOC01-appb-I000009

Figure JPOXMLDOC01-appb-I000010

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

Claims (15)

  1. 　グループ署名が付与されたデータを送信する、複数のノードと、
    　相互に直接接続されている、複数の管理サーバと、
    　を含み、
    　前記複数の管理サーバのそれぞれは、前記ノードから受信したデータを管理するための台帳を有し、
    　前記複数の管理サーバのうち少なくとも１つの管理サーバによる前記台帳へのデータの追記は他の管理サーバの台帳に反映される、システム。
  2. 　前記複数のノードは、複数のグループのいずれかに属しており、
    　前記複数のグループそれぞれに属するノードを管理する、複数のノード管理サーバをさらに含み、
    　前記ノード管理サーバのそれぞれは、自グループに属する前記ノードに対し、グループ署名を生成する際に用いるメンバ証明書を発行する、請求項１のシステム。
  3. 　前記複数のノードは、複数のグループのいずれかに属しており、
    　前記複数のグループそれぞれに属するノードを管理する、複数のノード管理サーバと、
    　前記複数のノードそれぞれに対し、グループ署名を生成する際に用いるメンバ証明書を発行する、証明書管理サーバと、をさらに含み、
    　前記複数のノード管理サーバのそれぞれは、特権者公開鍵を公開し、
    　前記証明書管理サーバは、管理者公開鍵を公開する、請求項１のシステム。
  4. 　前記ノードは、前記管理者公開鍵と、前記複数のノード管理サーバそれぞれが公開する特権者公開鍵と、を用いてグループ署名を生成する、請求項３のシステム。
  5. 　前記生成されたグループ署名は、前記証明書管理サーバが公開する管理者公開鍵と前記複数のノード管理サーバのそれぞれが公開した特権者公開鍵により、検証可能である請求項４のシステム。
  6. 　前記ノード管理サーバは、自身が管理するグループに属するノードが生成したグループ署名に含まれるデータを、前記特権者公開鍵とペアとなる特権者秘密鍵により取り出し、自身が管理するグループに属するノードを特定する、請求項３乃至５のいずれか一項に記載のシステム。
  7. 　それぞれがグループに属する、複数のノードと、
    　それぞれのグループに属するノードを管理する、複数のノード管理サーバと、
    　前記複数のノードそれぞれに対し、グループ署名を生成する際に用いるメンバ証明書を発行すると共に、管理者公開鍵を公開する証明書管理サーバと、を含み、
    　前記複数のノード管理サーバのそれぞれは、特権者公開鍵を公開し、
    　前記ノードは、データに付与するグループ署名の生成を、少なくとも前記管理者公開鍵と前記複数のノード管理サーバのそれぞれが公開する特権者公開鍵を用いて行う、システム。
  8. 　前記ノードが生成するグループ署名は、前記グループ署名を生成したノード自身の公開鍵を、前記複数のノード管理サーバが公開するいずれかの特権者公開鍵で暗号化し、前記自身の公開鍵にメンバ証明書が存在すること、且つ、暗号化した主体が前記自身の公開鍵に対応する秘密鍵を有すること、を証明するデータを含む、請求項７のシステム。
  9. 　前記複数のノード管理サーバが公開する特権者公開鍵は、一部の要素が共通するように生成された公開鍵である、請求項７及び８のシステム。
  10. 　前記共通する一部の要素は、前記特権者公開鍵に対応する特権者秘密鍵に依存して生成される要素である、請求項９のシステム。
  11. 　前記ノードの公開鍵は、前記共通する一部の要素に基づき生成される、請求項１０のシステム。
  12. 　前記ノードは、自身が属するグループとは異なるグループのチャレンジ値をランダムに選択し、前記ランダムに選択されたチャレンジ値を用いて前記グループ署名を生成する、請求項７乃至１１のいずれか一項に記載のシステム。
  13. 　前記ノードが生成したグループ署名の検証には、前記計算されたハッシュ値と、前記ランダムに選択されたチャレンジ値と、グループ署名を生成したノードが属するグループのチャレンジ値と、を用いる検証が少なくとも含まれる、請求項１２のシステム。
  14. 　複数のノードと、
    　相互に直接接続され、前記ノードから受信したデータを管理するための台帳を有する、複数の管理サーバと、
    　を含むシステムにおいて、
    　前記ノードが、グループ署名が付与されたデータを送信するステップと、
    　前記管理サーバが、前記グループ署名が付与されたデータを受信するステップと、
    　前記管理サーバが、前記受信したデータを前記台帳に追記するステップと、
    　前記複数の管理サーバのうち少なくとも１つの管理サーバによる前記台帳へのデータの追記を、他の管理サーバの台帳に反映するステップと、
    　を含む、データ管理方法。
  15. 　他の管理サーバと相互に直接接続され、ノードから受信したデータを管理するための台帳を有する管理サーバに搭載されたコンピュータに実行させるプログラムであって、
    　前記ノードが送信する、グループ署名が付与されたデータを受信する処理と、
    　前記受信したデータを前記台帳に追記する処理と、
    　前記他の管理サーバの台帳へのデータの追記を、自装置の台帳に反映する処理と、
    　を実行させるプログラム。
PCT/JP2017/027461 2016-07-29 2017-07-28 システム、データ管理方法及びプログラム WO2018021535A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/320,621 US11212112B2 (en) 2016-07-29 2017-07-28 System, data management method, and program
JP2018530424A JP7047760B2 (ja) 2016-07-29 2017-07-28 システム、データ管理方法及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-150100 2016-07-29
JP2016150100 2016-07-29

Publications (1)

Publication Number Publication Date
WO2018021535A1 true WO2018021535A1 (ja) 2018-02-01

Family

ID=61016563

Family Applications (1)

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

Country Status (3)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200095588A (ko) * 2019-01-17 2020-08-11 정상수 블록체인을 이용한 운송장치의 모빌리티 데이터 수집 시스템과 이를 이용한 모빌리티 데이터 수집 방법 및 프로그램
JP2021521667A (ja) * 2018-04-03 2021-08-26 ボイス・ライフ・インコーポレーテッド 無線電力受信を効率化する受信装置
US11763383B2 (en) 2019-05-30 2023-09-19 Nec Corporation Cryptocurrency system, terminal, server, trading method of cryptocurrency, and program

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107734021B (zh) * 2017-09-30 2020-04-07 深圳壹账通智能科技有限公司 区块链数据上传方法、系统、计算机系统及存储介质
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
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
EP1998493A4 (en) 2006-03-16 2015-12-09 Nec Corp GROUP SIGNATURE SYSTEM AND METHOD FOR INFORMATION PROCESSING
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 (1)

* Cited by examiner, † Cited by third party
Title
YASUYUKI FUCHITA: "Block Chain to Kn'yu Torihiki no Kakushin", NOMURA CAPITAL MARKETS QUARTERLY, vol. 19, no. 2, 1 November 2015 (2015-11-01), pages 11 - 35 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021521667A (ja) * 2018-04-03 2021-08-26 ボイス・ライフ・インコーポレーテッド 無線電力受信を効率化する受信装置
JP7165934B2 (ja) 2018-04-03 2022-11-07 ボイス・ライフ・インコーポレーテッド 無線電力受信を効率化する受信装置
KR20200095588A (ko) * 2019-01-17 2020-08-11 정상수 블록체인을 이용한 운송장치의 모빌리티 데이터 수집 시스템과 이를 이용한 모빌리티 데이터 수집 방법 및 프로그램
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

Also Published As

Publication number Publication date
JP7047760B2 (ja) 2022-04-05
JPWO2018021535A1 (ja) 2019-05-23
US11212112B2 (en) 2021-12-28
US20190165948A1 (en) 2019-05-30

Similar Documents

Publication Publication Date Title
WO2018021535A1 (ja) システム、データ管理方法及びプログラム
CN109451467B (zh) 一种基于区块链技术的车载自组织网络数据安全共享与存储系统
JP4796971B2 (ja) Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル
CN101689241B (zh) 电子处方的安全认证
JP2007004461A (ja) サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
US20120124379A1 (en) Anonymous authentication signature system, user device, verification device, signature method, verification method, and program therefor
JP4704406B2 (ja) 匿名選択可能認証情報のための通信システムおよびその方法
CN103621040A (zh) 促成对等覆盖网络中对数据对象的群访问控制
EP3966997B1 (en) Methods and devices for public key management using a blockchain
CN114760114B (zh) 身份认证方法、装置、设备及介质
Uddin et al. An efficient selective miner consensus protocol in blockchain oriented IoT smart monitoring
WO2021105816A1 (en) Methods and devices for automated digital certificate verification
Tan et al. An efficient vehicle-assisted aggregate authentication scheme for infrastructure-less vehicular networks
KR20140036395A (ko) 이동체의 군집 주행 서비스 인증 방법 및 그 장치
Kang et al. A privacy-preserving mobile payment system for mass transit
Abdelfatah et al. Secure VANET authentication protocol (SVAP) using Chebyshev chaotic maps for emergency conditions
CN115801260A (zh) 一种不可信网络环境下区块链辅助的协作式攻防博弈方法
Yi et al. Location privacy-preserving mobile crowd sensing with anonymous reputation
US20230421543A1 (en) Method, apparatus, and computer-readable medium for secured data transfer over a decentrlaized computer network
US20240013170A1 (en) Method for secure, traceable and privacy-preserving digital currency transfer with anonymity revocation on a distributed ledger
JP4679163B2 (ja) デジタル署名情報生成装置、デジタル署名情報生成方法及びプログラム
CN114944953A (zh) 一种车联网环境下用于路况监测的无证书匿名认证方法
US8572383B2 (en) Key exchange device, key exchange processing system, key exchange method, and program
Zhang et al. A location-aware verifiable outsourcing data aggregation in multiblockchains
US11580506B2 (en) Method for issuing authorisation tickets in an intelligent transport system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17834537

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2018530424

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17834537

Country of ref document: EP

Kind code of ref document: A1