WO2024089774A1 - データ管理装置およびデータ管理方法 - Google Patents
データ管理装置およびデータ管理方法 Download PDFInfo
- Publication number
- WO2024089774A1 WO2024089774A1 PCT/JP2022/039770 JP2022039770W WO2024089774A1 WO 2024089774 A1 WO2024089774 A1 WO 2024089774A1 JP 2022039770 W JP2022039770 W JP 2022039770W WO 2024089774 A1 WO2024089774 A1 WO 2024089774A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- record
- distributed ledger
- control device
- token
- information
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 58
- 238000013523 data management Methods 0.000 title claims description 56
- 238000004891 communication Methods 0.000 claims description 73
- 230000004044 response Effects 0.000 claims description 28
- 238000005516 engineering process Methods 0.000 claims description 7
- 239000000725 suspension Substances 0.000 description 55
- 238000012545 processing Methods 0.000 description 29
- 238000010586 diagram Methods 0.000 description 26
- 230000006870 function Effects 0.000 description 24
- 230000005540 biological transmission Effects 0.000 description 22
- 238000012795 verification Methods 0.000 description 11
- 239000013256 coordination polymer Substances 0.000 description 5
- 230000005856 abnormality Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 2
- 238000005401 electroluminescence Methods 0.000 description 2
- 230000015654 memory Effects 0.000 description 2
- 230000003936 working memory Effects 0.000 description 2
- 230000010365 information processing Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or 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
Definitions
- This disclosure relates to a data management device and a data management method that manage data using distributed ledger technology.
- timestamp tokens have an expiration date. Therefore, methods are being considered for proving existence and integrity beyond the expiration date of timestamp tokens.
- Japanese Patent Application Laid-Open Publication No. 2014-42214 discloses a data certification system that uses timestamp technology to execute a process to extend the validity period of a long-term signature.
- This data certification system creates an ESR table that compiles original proof information (ES-A) that certifies the non-tampering of multiple original files, and executes a process to extend the validity period of the ESR table. This reduces the processing load compared to when a process to extend the validity period is executed for each ES-A (see Patent Document 1).
- ES-A original proof information
- Patent Document 1 takes measures to reduce the processing load on the system, but does not consider improving the tamper resistance of timestamp tokens.
- the present disclosure has been made to solve the above problems, and the purpose of the present disclosure is to make it possible to prove the validity of a timestamp token that has exceeded its expiration date, and to improve the tamper-resistance of the timestamp token.
- a data management device is a data management device that manages data using distributed ledger technology.
- the data management device includes a storage device that stores a distributed ledger, a control device that updates the distributed ledger, and a communication device configured to be able to communicate with a time stamp authority that assigns time stamp tokens.
- the distributed ledger includes a first distributed ledger that chronologically stores records including information about data, and a second distributed ledger that chronologically stores records including time stamp tokens obtained from the time stamp authority.
- the control device obtains, via the communication device, a first time stamp token from the time stamp authority, which is a time stamp token for information about a terminal record of the first distributed ledger, and stores a record including the first time stamp token in the second distributed ledger.
- the first timestamp token obtained for information about the terminal record of the first distributed ledger is managed in the second distributed ledger.
- all subsequent records of the record containing the timestamp token must be tampered with, making tampering with the first timestamp token difficult.
- the information about the terminal record in the first distributed ledger is a hash value of the terminal record.
- a timestamp token is obtained for the hash value of the terminal record stored in the first distributed ledger.
- the record itself stored in the first distributed ledger is not sent to the time stamp authority, so the record itself can be kept secret when obtaining the timestamp token.
- the first timestamp token is obtained in response to a user operation on the data management device.
- a user can obtain a first timestamp token at any time and store the first timestamp token in the two distributed ledgers.
- control device when a record is added to the first distributed ledger, the control device obtains a first timestamp token for the record.
- a first timestamp token can be automatically obtained and stored in the second distributed ledger.
- control device obtains a second time stamp token, which is a time stamp token for information about a terminal record in the second distributed ledger, from a time stamp authority via a communication device, and stores a record including the second time stamp token in the second distributed ledger.
- a second time stamp token which is a time stamp token for information about a terminal record in the second distributed ledger
- control device obtains a second timestamp token in response to a user operation on the data management device.
- a user can obtain a second timestamp token at any time and store the second timestamp token in the two distributed ledgers.
- control device acquires the second timestamp token when a predetermined time has elapsed since the second timestamp token was last acquired.
- a second timestamp token can be automatically obtained every time a predetermined time elapses, and the second timestamp token can be stored in the two distributed ledgers.
- the communication device is further configured to be able to communicate with an external server different from the data management device.
- the control device transmits information regarding the end record of the second distributed ledger at a given point in time to the external server via the communication device.
- information about the terminal record of the second distributed ledger is separated from the data management device and is also managed in an external server.
- the timestamp token the first timestamp token and/or the second timestamp token
- both the timestamp token managed by the data management device and the information about the terminal record managed by the external server must be tampered with. This makes it possible to increase the tamper-resistance of the timestamp token.
- the information about the terminal record in the second distributed ledger is a hash value of the terminal record.
- a timestamp token is obtained for the hash value of the terminal record stored in the second distributed ledger.
- the record itself stored in the second distributed ledger is not sent to the time stamp authority, so the record itself can be kept secret when obtaining the timestamp token.
- a data management method is a data management method using a data management device that manages data using distributed ledger technology.
- the data management device includes a storage device that stores a distributed ledger, a control device that updates the distributed ledger, and a communication device configured to be able to communicate with a time stamp authority that grants a time stamp token.
- the distributed ledger includes a first distributed ledger that chronologically stores records including information about data, and a second distributed ledger that chronologically stores records including time stamp tokens obtained from the time stamp authority.
- the data management method includes the steps of obtaining, via the communication device, from the time stamp authority, a first time stamp token that is a time stamp token for information about a terminal record of the first distributed ledger, and storing a record including the first time stamp token in the second distributed ledger.
- the method further includes the steps of obtaining, via a communication device, from a time-stamp authority, a second time-stamp token that is a time-stamp token for information about the terminal record of the second distributed ledger, and storing a record including the second time-stamp token in the second distributed ledger.
- the present disclosure makes it possible to prove the validity of a timestamp token that has passed its expiration date, and also improves the tamper-resistance of the timestamp token.
- FIG. 1 is a diagram showing a schematic configuration of a data management system according to a first embodiment;
- FIG. 1 is a diagram illustrating an example of the configuration of a distributed ledger set.
- FIG. 1 is a diagram illustrating an update to a distributed ledger set.
- FIG. 4 is a functional block diagram of a control device for executing a process in response to a first operation.
- FIG. 11 is a functional block diagram of a control device for executing a process in response to a second operation.
- FIG. 3 is a functional block diagram of a control device for executing a process in response to a third operation.
- FIG. 4 is a functional block diagram of a control device for executing a process in response to a fourth operation.
- FIG. 4 is a functional block diagram of a control device for executing received transaction data.
- 13 is a flowchart showing a procedure for generating transaction data when a first request is received.
- 13 is a flowchart showing a procedure for generating transaction data when a second request is received.
- 13 is a flowchart showing a procedure for generating transaction data when a third request is received.
- 13 is a flowchart showing a procedure of a process when a fourth request is received.
- 11 is a flowchart showing a procedure of a process executed when transaction data is received.
- FIG. 11 is a diagram showing a schematic configuration of a data management system according to a second embodiment. A diagram showing an example of the configuration of a ledger set.
- FIG. 4A and 4B are diagrams illustrating an example of a configuration of a suspension table.
- FIG. 13 is a diagram illustrating an example of the configuration of a commit table.
- 13 is a flowchart showing a procedure of a process executed in the data management system when an update request is received.
- 13 is a flowchart showing a processing procedure when a fourth request is received in the second embodiment.
- FIG. 1 is a diagram showing a schematic configuration of a data management system 1 according to a first embodiment.
- the data management system 1 according to the first embodiment is a system for forming a consortium network (hereinafter also simply referred to as a "network”) NW among a plurality of companies and managing data using a distributed ledger technology.
- the data management system 1 according to the first embodiment manages data of parts constituting a vehicle (hereinafter also simply referred to as "parts data").
- the parts data may be, for example, a specification of the parts.
- the data managed by the data management system 1 is not limited to data of parts constituting a vehicle, and may be various types of data.
- the data management system 1 includes four client servers 2, a platform server 5, a Time Stamp Authority (TSA) 8, and an external server 9.
- Each of the four client servers 2 belongs to a different company (e.g., company A, company B, company C, and company D).
- the platform server 5 manages the network NW.
- the platform server 5 accepts applications from each client server 2 to join the network NW.
- the platform server 5 permits the client server 2 to join the network NW based on an operation by the platform server 5 administrator to permit participation, or based on the results of judging predetermined conditions.
- four client servers 2 belonging to each of companies A, B, C, and D are permitted to join the network NW.
- the four client servers 2 form a network NW, and store hash values of part data in each distributed ledger.
- Distributed ledger platform software is installed in each of the client servers 2, and the installed distributed ledger platform software functions to cause each of the client servers 2 to function as a node.
- the client server 2 of Company A will be described as a representative example, but the client servers 2 of Company B, Company C, and Company D have the same configuration and function.
- the client server 2 corresponds to an example of a "data management device" according to the present disclosure.
- the network NW includes four client servers will be described, but the number of client servers 2 included in the network NW is arbitrary, and may be, for example, less than four or five or more.
- the client server 2 is configured to be able to communicate with a user terminal device 7.
- the user terminal device 7 is, for example, a desktop PC (Personal Computer), a notebook PC, a tablet terminal, a smartphone, or any other information processing terminal with communication capabilities, loaned to an employee of Company A.
- a database 4 is connected to the client server 2.
- the database 4 stores part data.
- the database 4 registers and updates the part data in accordance with control signals from the client server 2.
- a user of the client server 2 e.g., an employee of Company A
- the client server 2 (control device 21) generates a control signal for storing (registering/updating) the part data in response to an input to the input device 25 or a request from the user terminal device 7, and outputs the control signal to the database 4.
- the client server 2 When the client server 2 stores (registers/updates) part data in the database 4, it generates a hash value for the part data and generates transaction data for storing the hash value in the distributed ledger. The client server 2 then transmits the generated transaction data to the other client servers 2 that form the network NW, i.e., the client servers 2 of companies B, C, and D.
- the distributed ledger stores the hash values of the part data in chronological order, forming an evidence chain to prove the existence of the part data.
- the time-stamp authority 8 includes a server belonging to a certification authority that issues time-stamp tokens.
- the time-stamp authority issues a time-stamp token in response to a time-stamp issuance request from an applicant (in the first embodiment, the client server 2). More specifically, the time-stamp authority transmits to the applicant a time-stamp token that combines data received from the applicant (in the first embodiment, a record hash value, described below) with time information based on a time source that is traceable to international standard time.
- External server 9 is a server managed by a management entity that is not any of Company A, Company B, Company C, or Company D. External server 9 is configured to be able to communicate with client server 2. External server 9 receives a client certificate, which will be described later, from client server 2, and manages the received client certificate.
- the client server 2 includes a control device 21, a ROM (Read Only Memory) 22, a RAM (Random Access Memory) 23, a communication device 24, an input device 25, a display device 26, and a storage device 27.
- the control device 21, the ROM 22, the RAM 23, the communication device 24, the input device 25, the display device 26, and the storage device 27 are connected to a bus 29.
- the control device 21 is formed, for example, by an integrated circuit including a CPU (Central Processing Unit).
- the control device 21 deploys various programs stored in the ROM 22 into the RAM 23 and executes them.
- the various programs include an operating system, etc.
- the RAM 23 functions as a working memory and temporarily stores various data required for the execution of the various programs.
- the control device 21 has the function of updating part data recorded in the database 4, generating transaction data for updating the distributed ledger, and acquiring timestamp tokens.
- the communication device 24 is configured to be capable of communicating with external devices.
- the external devices include, for example, other client servers 2, user terminal devices 7, time stamping authorities 8, and external servers 9.
- Communication between the communication device 24 and the external devices is performed using the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet (registered trademark) network, a public network, a private network, a wired network, a wireless network, or the like, or a combination of these.
- WAN wide area network
- LAN local area network
- Ethernet registered trademark
- the input device 25 includes an input device.
- the input device is, for example, a mouse, a keyboard, a touch panel, and/or other device capable of receiving user operations.
- the display device 26 includes a display.
- the display device 26 displays various images on the display in accordance with control signals from the control device 21.
- the display is, for example, a liquid crystal display, an organic EL (Electro Luminescence) display, or other display device.
- the storage device 27 includes a storage medium such as a hard disk or a flash memory.
- the storage device 27 stores a private key 271, a plurality of public keys 272, and a distributed ledger set 50.
- the private key 271 is the private key of Company A.
- control device 21 when client server 2 first joins network NW, control device 21 generates a private key and a public key. Then, control device 21 sends the generated public key to a certification authority (not shown) for authentication.
- a certification authority is a certification body that issues electronic certificates. The certification authority issues an electronic certificate that includes information about the public key.
- Control device 21 stores private key 271 corresponding to the authenticated public key in storage device 27. Control device 21 also sends authenticated public keys (electronic certificates) 272 to client servers 2 of companies B, C, and D.
- the multiple public keys 272 include the public key of Company B, the public key of Company C, and the public key of Company D.
- the control device 21 stores the public keys received from the other client servers 2 in the storage device 27.
- the storage device 27 may also store its own (Company A's) public key.
- the distributed ledger set 50 includes multiple distributed ledgers.
- Figure 2 is a diagram showing an example of the configuration of the distributed ledger set 50.
- one part that constitutes a vehicle is managed by the data management system 1.
- the part whose data is managed in the distributed ledger is also referred to as the "target part”.
- the part data of the target part is also referred to as the "target data”.
- the distributed ledger set 50 includes two distributed ledgers 51 and 52.
- the distributed ledger 51 stores the update state of the target data in chronological order, and functions as an evidence chain for the target data (hereinafter also referred to as the "first evidence chain”).
- the distributed ledger 52 stores timestamp tokens in chronological order, and functions as an evidence chain for the timestamp tokens (hereinafter also referred to as the "second evidence chain”).
- the distributed ledger 51 stores records in chronological order, each containing a hash value of the target data.
- the records contain the following information: "Key”, “Age”, “Obj-HV”, “Nonce”, “Sig”, “Prev-HV”, and "HV”.
- Key is information that indicates the ID of the target part.
- the target part is assigned an ID of k1.
- the key can also be considered an ID for identifying distributed ledgers 51 and 52.
- Distributed ledger 51 stores records including the key k1 in chronological order
- distributed ledger 52 stores records including the key k2 in chronological order.
- Age is information that indicates the generation of a record.
- Age is 0.
- Age is incremented.
- Obj-HV is the hash value of the target data. For example, when the target data stored in the database 4 is updated, a hash value of the updated target data is generated and used as Obj-HV.
- the hash value is a numerical value obtained as a result of hashing the target data using a hash function.
- Nonce is a nonce value that indicates the number of transaction data.
- the nonce value is generated by the client server 2 (control device 21) as a processing number for storing the hash value of the updated target data in the distributed ledger 51.
- the nonce value is a hash value that is cryptographically difficult to collide with.
- Sig is an electronic signature created using the private key 271 of the client server 2 that issued the transaction data.
- the electronic signature is created, for example, by encrypting Obj-HV (i.e., the hash value of the target data) with the private key 271.
- the electronic signature may be created, for example, by encrypting a Nonce (nonce value) with the private key 271.
- Prev-HV is the hash value of the record (parent record) of the generation before the latest (end) record.
- Prev-HV is the HV of the parent record.
- HV is the hash value of the record. Specifically, HV is the hash value of the record information excluding HV (Key, Age, Obj-HV, Nonce, Sig, and Prev-HV) (hereinafter also referred to as the "record hash value").
- HV Key, Age, Obj-HV, Nonce, Sig, and Prev-HV
- the Prev-HV of the terminal record is "H2", which is the HV of the parent record (Age "1").
- the Prev-HV of the record with Age "3” becomes “H3", which is the HV of the record with Age "2”.
- the terminal record has a structure that includes the record hash value of the parent record. In other words, a chain of records is realized between the Prev-HV of the terminal record and the HV of the parent record.
- the distributed ledger 51 has a DAG (Directed Acyclic Graph) structure.
- Distributed ledger 52 stores records including timestamp tokens in chronological order.
- the records include the following information: “Key”, “Age”, “Obj-HV”, “Nonce”, “Sig”, “Prev-HV”, and “HV”. Details of the information “Age”, “Nonce”, “Sig”, “Prev-HV”, and “HV” are similar to those of the records in distributed ledger 51, and will not be described again.
- the key is information indicating the ID of the timestamp token obtained from the time stamp authority 8.
- the timestamp token is assigned the ID k2.
- Obj-HV is the value of the timestamp token. As described below, Obj-HV stores the timestamp token obtained for the record hash value of distributed ledger 51 or the timestamp token obtained for the record hash value of distributed ledger 52.
- the control device 21 of the client server 2 has the function of responding to the first to fourth operations described below.
- a user of client server 2 can perform an operation on input device 25 or user terminal device 7 to register target data in database 4, or an operation to update target data registered in database 4.
- the above-mentioned operations for registering and updating are collectively referred to as a "first operation.”
- the input device 25 or the user terminal device 7 When the first operation is performed, the input device 25 or the user terminal device 7 outputs a first request indicating that the first operation has been performed in response to the first operation.
- the client server 2 In response to the first request, the client server 2 (control device 21) registers the target data in the database 4 or updates the target data stored in the database 4. The client server 2 (control device 21) then generates transaction data for adding a record including the hash value of the registered or updated target data to the distributed ledger 51.
- This transaction data includes the information "Key”, "Age”, “Obj-HV", “Nonce”, “Sig”, “Prev-HV", and "HV".
- the transaction data may further include time information when the transaction data is broadcast to the network NW (sent to the network NW), and sender information of the transaction data.
- the time information may be, for example, information indicating the time when the target data was recorded in database 4.
- the sender information is, for example, information indicating Company A.
- the sender information of the transaction data may be, in more detail, information indicating the department (a division of Company A) that performed the operation to send the transaction data to the network NW, or information indicating an individual (an employee of Company A) that performed the operation to send the transaction data to the network NW.
- a user of the client server 2 can perform an operation (hereinafter also referred to as a “second operation”) on the input device 25 or the user terminal device 7 to obtain a timestamp token for a terminal record in the distributed ledger 51.
- an operation hereinafter also referred to as a “second operation”
- the input device 25 or the user terminal device 7 outputs a second request indicating that the second operation has been performed in response to the second operation.
- the client server 2 (control device 21) generates a record hash value of the terminal record in the distributed ledger 51 and obtains a timestamp token for the record hash value.
- the client server 2 (control device 21) then generates transaction data for adding a record including the timestamp token to the distributed ledger 52.
- This transaction data includes information on "Key”, “Age”, “Obj-HV", “Nonce”, “Sig”, “Prev-HV", and “HV”.
- the transaction data may also include time information and sender information.
- the client server 2 may be configured to automatically execute processing to respond to the second request when it detects that a new record has been added to the distributed ledger 51. That is, when the client server 2 (control device 21) detects that a new record has been added to the distributed ledger 51, it generates a record hash value of the record and obtains a timestamp token for the record hash value. Then, the client server 2 (control device 21) generates transaction data for adding a record including the timestamp token to the distributed ledger 52.
- a user of the client server 2 can perform an operation (hereinafter also referred to as the “third operation”) on the input device 25 or the user terminal device 7 to obtain a timestamp token for a terminal record in the distributed ledger 52.
- the input device 25 or the user terminal device 7 outputs a third request indicating that the third operation has been performed in response to the third operation.
- the client server 2 (control device 21) generates a record hash value of the terminal record in the distributed ledger 52 and obtains a timestamp token for the record hash value.
- the client server 2 (control device 21) then generates transaction data for adding a record including the timestamp token to the distributed ledger 52.
- This transaction data includes information on "Key”, “Age”, “Obj-HV", “Nonce”, “Sig”, “Prev-HV", and “HV”.
- the transaction data may also include time information and sender information.
- the user of the client server 2 can perform an operation for generating a client certificate (hereinafter also referred to as a “fourth operation”) on the input device 25 or the user terminal device 7.
- the client certificate is data including the record hash value of the terminal record in the distributed ledger 52 at the time the fourth operation is performed.
- the input device 25 or the user terminal device 7 outputs a fourth request indicating that the fourth operation has been performed in response to the fourth operation.
- the client server 2 (control device 21) generates a record hash value of the terminal record in the distributed ledger 52 and creates a client certificate including the record hash value.
- the client server 2 (control device 21) then transmits the client certificate to the external server 9 via the communication device 24.
- Fig. 3 is a diagram for explaining an update of a distributed ledger set 50.
- the upper part of Fig. 3 shows a schematic diagram of a distributed ledger 51 which is a first evidence chain
- the lower part of Fig. 3 shows a schematic diagram of a distributed ledger 52 which is a second evidence chain.
- hash values of part data (target data) of target parts are stored in chronological order.
- a record RA0 with Age "0" containing the hash value of the target data D0 is stored in the distributed ledger 51.
- the target data is updated by an operation (first operation) for updating the target data and the updated target data D1 is registered in the database 4
- a record RA1 with Age "1” containing the hash value of the updated target data D1 and the record hash value of the parent record RA0 with Age "0” is stored in the distributed ledger 51.
- the target data is updated by an operation (first operation) for updating the target data and the updated target data D2 is registered in the database 4
- a record RA2 with Age "2" containing the hash value of the updated target data D2 and the record hash value of the parent record RA1 with Age "1” is stored in the distributed ledger 51.
- records RA3 and RA4 containing the hash values of the target data D3 and D4 are stored in the distributed ledger 51.
- the second evidence chain (distributed ledger 52) stores timestamp tokens in chronological order. Assume that the first update of distributed ledger 51 is performed, record RA1 is added to distributed ledger 51, and record RA1 is the terminal record of distributed ledger 51. When the second operation is performed in this situation, a record hash value RH1 of record RA1 is generated. Then, a timestamp token T0 for the record hash value RH1 is obtained, and record RB0 with Age "0" including the timestamp token T0 is stored in distributed ledger 52. Next, assume that the distributed ledger 51 is updated, and record RA2 is added to distributed ledger 51.
- a record hash value RH2 of record RA2 is generated. Then, a timestamp token T1 for the record hash value RH2 is obtained, and a record RB1 with Age “1" that contains the timestamp token T1 and the record hash value of the parent record RB0 with Age "0" is stored in the distributed ledger 52. As described above, when a record is added to the distributed ledger 51, a timestamp token for the record hash value of the record may be automatically obtained.
- the second operation can be performed at any timing by the user. That is, although the above shows an example in which the second operation is performed every time a record is added to the distributed ledger 51, the second operation does not have to be performed every time a record is added to the distributed ledger 51.
- the second operation may be performed every predetermined number of times a record is added to the distributed ledger 51, or may be performed when a first predetermined time has elapsed since the last time the second operation was performed.
- the first predetermined time may be set, for example, taking into account the expiration date of the timestamp token.
- the terminal record of the distributed ledger 52 is record RB1.
- a third operation an operation for obtaining a timestamp token for the terminal record of the distributed ledger 52
- a record hash value RH3 of the terminal record RB1 of the distributed ledger 52 is generated.
- a timestamp token T2 for the record hash value RH3 is obtained, and a record RB2 with Age "2" including the timestamp token T2 and the record hash value of the parent record RB1 is stored in the distributed ledger 52.
- the third operation can be performed at any timing of the user.
- a timestamp token may be obtained for the record hash value of the terminal record of the distributed ledger 52 when a second predetermined time has elapsed since the record was last added to the distributed ledger 52.
- the second predetermined time may be set, for example, taking into consideration the expiration time of the timestamp token.
- the second predetermined time may be set to the same time as the first predetermined time described above, or may be set to a different time.
- the terminal record of distributed ledger 52 is record RB2.
- a fourth operation an operation to create a client certificate
- a record hash value RH4 of terminal record RB2 of distributed ledger 52 is generated.
- a client certificate CP including record hash value RH4 is created.
- This client certificate CP is managed separately from client server 2. For example, client certificate CP is sent to external server 9 via communication device 24.
- the fourth operation can be performed at any time. For example, when the terminal record of the distributed ledger 52 is record RB1, if the fourth operation is performed, a client certificate is created that includes the record hash value of the terminal record RB1 of the distributed ledger 52. This client certificate may be sent to the external server 9 via the communication device 24.
- a record including the hash value is stored in the distributed ledger 51.
- the tamper-resistance of the target data can be improved.
- a time stamp token generally has a set expiration date. With an expired time stamp token, it is not possible to prove the existence and integrity of the target data (hash value). Therefore, as described above, the time stamp token acquired for the terminal record of the distributed ledger 51 is stored in the distributed ledger 52.
- the distributed ledger 52 a chain of records is realized including the record hash value of the parent record, so in order to tamper with an expired time stamp token, all time stamp tokens added to the distributed ledger 52 after the expired time stamp token was stored must be tampered with. In this way, by storing the time stamp token in the distributed ledger 52, the tamper resistance of the time stamp token can be improved.
- the timestamp token T0 can be used to prove the existence and integrity of the target data D1.
- a timestamp token T2 is obtained for the record hash value RH3 of the terminal record RB1 in the distributed ledger 52.
- the timestamp token T2 for the record hash value RH3 in the distributed ledger 52 it becomes possible to prove that record RB1 existed at the time attested by the timestamp token T2, and that record RB1 has not been tampered with after the time attested by the timestamp token T2.
- the tamper resistance of the timestamp token T3 can be improved.
- the client certificate CP is separated from the client server 2 and managed by the external server 9. As a result, even if all records in the distributed ledger set 50 are tampered with, it is possible to prove that the distributed ledger set 50 has been tampered with by using the client certificate CP managed by the external server 9.
- first operation, second operation, third operation, and fourth operation may be, for example, operations in which the user selects the respective request buttons (first button, second button, third button, and fourth button) displayed on the display screen of the display device 26 or the user terminal device 7.
- Fig. 4 is a functional block diagram of control device 21 for executing a process in response to a first operation.
- control device 21 includes information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106.
- Control device 21 functions as information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106, for example, by executing a program stored in ROM 22.
- information acquisition unit 2101, hash generation unit 2102, nonce generation unit 2103, digital signature unit 2104, transaction data generation unit 2105, and transaction data transmission unit 2106 may be realized by, for example, dedicated hardware (electronic circuit).
- the input device 25 or the user terminal device 7 When a first operation for registering or updating target data is performed on the input device 25 or the user terminal device 7, the input device 25 or the user terminal device 7 outputs a first request indicating that the first operation has been performed.
- the information acquisition unit 2101 acquires a first request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 performs a first operation on the input device 25, the first request is input to the information acquisition unit 2101.
- the first request includes ID (Key) information M1 for identifying the distributed ledger 51 to which the record is to be added.
- the information acquisition unit 2101 outputs the first request to the hash generation unit 2102 and the nonce generation unit 2103.
- the hash generation unit 2102 When the hash generation unit 2102 receives the first request, it reads the target data from, for example, the database 4 and generates a hash value of the target data. The hash generation unit 2102 outputs the generated hash value and ID information M1 to the digital signature unit 2104 and the transaction data generation unit 2105.
- the nonce generation unit 2103 When the nonce generation unit 2103 receives the first request, it generates a nonce value.
- the nonce value is a hash value that is cryptographically unlikely to collide.
- the nonce generation unit 2103 outputs the generated nonce value and ID information M1 to the transaction data generation unit 2105. Note that if a nonce value is used to create a digital signature, the nonce generation unit 2103 may output the nonce value and ID information M1 to the digital signature unit 2104.
- the electronic signature unit 2104 reads the private key 271 from the storage device 27.
- the electronic signature unit 2104 creates an electronic signature by encrypting the hash value received from the hash generation unit 2102 with the private key 271.
- the electronic signature unit 2104 outputs the created electronic signature and ID information M1 to the transaction data generation unit 2105.
- the electronic signature unit 2104 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2103 with the private key 271.
- the electronic signature unit 2104 may also create an electronic signature by encrypting the hash value and the nonce value with the private key 271.
- the transaction data generation unit 2105 generates transaction data to be sent to the network NW.
- the transaction data generation unit 2105 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
- the transaction data generation unit 2105 recognizes the Age of the parent record by querying the distributed ledger set 50 for ID information M1 (Key), and increments the Age of the parent record to set it as the Age of the record to be added.
- the transaction data generation unit 2105 sets the hash value generated by the hash generation unit 2102 as Obj-HV, the nonce value generated by the nonce generation unit 2103 as Nonce, and the electronic signature created by the electronic signature unit 2104 as Sig.
- the transaction data generation unit 2105 also sets the record hash value of the parent record as Prev-HV.
- the transaction data generation unit 2105 hashes the information of Key, Age, Obj-HV, Nonce, Sig, and Prev-HV to generate HV.
- the transaction data may further include time information when the transaction data is broadcast (sent to the network NW) to the network NW, and sender information of the transaction data.
- the transaction data generation unit 2105 outputs the generated transaction data to the transaction data transmission unit 2106.
- the transaction data transmission unit 2106 outputs a control signal to the communication device 24 to transmit the transaction data to the network NW. As a result, the transaction data is transmitted to the network NW via the communication device 24.
- control device 21 includes an information acquisition unit 2111, a record hash generation unit 2112, a nonce generation unit 2113, a timestamp token acquisition unit 2114, an electronic signature unit 2115, a transaction data generation unit 2116, and a transaction data transmission unit 2117.
- Control device 21 functions as information acquisition unit 2111, record hash generation unit 2112, nonce generation unit 2113, timestamp token acquisition unit 2114, an electronic signature unit 2115, transaction data generation unit 2116, and transaction data transmission unit 2117, for example, by executing a program stored in ROM 22.
- the information acquisition unit 2111, the record hash generation unit 2112, the nonce generation unit 2113, the timestamp token acquisition unit 2114, the digital signature unit 2115, the transaction data generation unit 2116, and the transaction data transmission unit 2117 may be realized, for example, by dedicated hardware (electronic circuits).
- the input device 25 or the user terminal device 7 When a second operation is performed on the input device 25 or the user terminal device 7 to obtain a timestamp token for a terminal record in the distributed ledger 51, the input device 25 or the user terminal device 7 outputs a second request indicating that the second operation has been performed.
- the information acquisition unit 2111 acquires the second request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 performs a second operation on the input device 25, the second request is input to the information acquisition unit 2111.
- the second request includes ID information M2 for identifying the distributed ledger 51 from which the timestamp token is to be acquired, and ID information M3 for identifying the distributed ledger 52 to which the record is to be added.
- the information acquisition unit 2111 outputs the second request to the record hash generation unit 2112 and the nonce generation unit 2113.
- the information acquisition unit 2111 may monitor the update status of the distributed ledger 51 and determine that the second request has been acquired when a record has been added to the distributed ledger 51 in response to the first operation.
- the record hash generation unit 2112 When the record hash generation unit 2112 receives the second request, it generates a record hash value of the latest (terminal) record in the distributed ledger 51 identified by the ID information M2. The record hash generation unit 2112 outputs the generated record hash value and the ID information M3 to the timestamp token acquisition unit 2114.
- the nonce generation unit 2113 When the nonce generation unit 2113 receives the second request, it generates a nonce value. The nonce generation unit 2113 outputs the generated nonce value and ID information M3 to the transaction data generation unit 2116. Note that if a nonce value is used to create a digital signature, the nonce generation unit 2113 may output the nonce value and ID information M3 to the digital signature unit 2115.
- the timestamp token acquisition unit 2114 acquires a timestamp token for the record hash value received from the record hash generation unit 2112. Specifically, the timestamp token acquisition unit 2114 outputs a control signal for transmitting the record hash value to the time-stamp authority 8 to the communication device 24. As a result, the record hash value is transmitted to the time-stamp authority 8 via the communication device 24. The time-stamp authority 8 that has received the record hash value returns the timestamp token to the client server 2 that transmitted the record hash value. The timestamp token acquisition unit 2114 acquires the timestamp token from the time-stamp authority 8 via the communication device 24. The timestamp token acquisition unit 2114 outputs the timestamp token and ID information M3 for identifying the distributed ledger 52 that stores the timestamp token to the electronic signature unit 2115 and the transaction data generation unit 2116.
- the electronic signature unit 2115 reads the private key 271 from the storage device 27.
- the electronic signature unit 2115 creates an electronic signature by encrypting the timestamp token received from the timestamp token acquisition unit 2114 with the private key 271.
- the electronic signature unit 2115 outputs the created electronic signature and ID information M3 to the transaction data generation unit 2116.
- the electronic signature unit 2115 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2113 with the private key 271.
- the electronic signature unit 2115 may also create an electronic signature by encrypting the timestamp token and the nonce value with the private key 271.
- the transaction data generation unit 2116 generates transaction data to be sent to the network NW. For example, the transaction data generation unit 2116 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2116 uses ID information M3 (k2) as the Key. The transaction data generation unit 2116 also uses the timestamp token as Obj-HV. Other functions of the transaction data generation unit 2116 are basically the same as those of the transaction data generation unit 2105 described in FIG. 4.
- the transaction data transmission unit 2117 outputs a control signal to the communication device 24 to transmit the transaction data to the network NW. As a result, the transaction data is transmitted to the network NW via the communication device 24.
- control device 21 includes an information acquisition unit 2121, a record hash generation unit 2122, a nonce generation unit 2123, a timestamp token acquisition unit 2124, an electronic signature unit 2125, a transaction data generation unit 2126, and a transaction data transmission unit 2127.
- Control device 21 functions as information acquisition unit 2121, record hash generation unit 2122, nonce generation unit 2123, timestamp token acquisition unit 2124, an electronic signature unit 2125, transaction data generation unit 2126, and transaction data transmission unit 2127, for example, by executing a program stored in ROM 22.
- the information acquisition unit 2121, the record hash generation unit 2122, the nonce generation unit 2123, the timestamp token acquisition unit 2124, the digital signature unit 2125, the transaction data generation unit 2126, and the transaction data transmission unit 2127 may be realized, for example, by dedicated hardware (electronic circuits).
- the input device 25 or the user terminal device 7 When a third operation is performed on the input device 25 or the user terminal device 7 to obtain a timestamp token for a terminal record in the distributed ledger 52, the input device 25 or the user terminal device 7 outputs a third request indicating that the third operation has been performed.
- the information acquisition unit 2121 acquires the third request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 performs a third operation on the input device 25, the third request is input to the information acquisition unit 2121.
- the third request includes ID information M4 for identifying the distributed ledger 52 from which the timestamp token is to be acquired, and ID information M5 for identifying the distributed ledger 52 that stores the timestamp token.
- the information acquisition unit 2121 acquires the third request, it outputs the third request to the record hash generation unit 2122 and the nonce generation unit 2123.
- the record hash generation unit 2122 When the record hash generation unit 2122 receives the third request, it generates a record hash value of the latest (terminal) record in the distributed ledger 52 identified by the ID information M4. The record hash generation unit 2122 outputs the generated record hash value and the ID information N5 to the timestamp token acquisition unit 2124.
- the nonce generation unit 2123 When the nonce generation unit 2123 receives the third request, it generates a nonce value. The nonce generation unit 2123 outputs the generated nonce value and ID information M5 to the transaction data generation unit 2126. Note that if a nonce value is used to create an electronic signature, the nonce generation unit 2123 may output the nonce value and ID information M5 to the electronic signature unit 2125.
- the timestamp token acquisition unit 2124 acquires a timestamp token for the record hash value received from the record hash generation unit 2122. Specifically, the timestamp token acquisition unit 2124 outputs a control signal for transmitting the record hash value to the time-stamp authority 8 to the communication device 24. As a result, the record hash value is transmitted to the time-stamp authority 8 via the communication device 24. The time-stamp authority 8 that has received the record hash value returns the timestamp token to the client server 2 that transmitted the record hash value. The timestamp token acquisition unit 2124 acquires the timestamp token from the time-stamp authority 8 via the communication device 24. The timestamp token acquisition unit 2124 outputs the timestamp token and ID information M5 for identifying the distributed ledger 52 that stores the timestamp token to the electronic signature unit 2125 and the transaction data generation unit 2126.
- the electronic signature unit 2125 reads out the private key 271 from the storage device 27.
- the electronic signature unit 2125 creates an electronic signature by encrypting the timestamp token received from the timestamp token acquisition unit 2124 with the private key 271.
- the electronic signature unit 2125 outputs the created electronic signature and ID information M5 to the transaction data generation unit 2126.
- the electronic signature unit 2125 may also create an electronic signature by encrypting the nonce value received from the nonce generation unit 2123 with the private key 271.
- the electronic signature unit 2125 may also create an electronic signature by encrypting the timestamp token and the nonce value with the private key 271.
- the transaction data generation unit 2126 generates transaction data to be sent to the network NW. For example, the transaction data generation unit 2126 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. The transaction data generation unit 2126 sets the ID information M5 (k2) as the Key. The transaction data generation unit 2126 also sets the timestamp token as Obj-HV. Other functions of the transaction data generation unit 2126 are basically the same as those of the transaction data generation unit 2105 described in FIG. 4.
- the transaction data transmission unit 2127 outputs a control signal to the communication device 24 to transmit the transaction data to the network NW. As a result, the transaction data is transmitted to the network NW via the communication device 24.
- FIG. 7 is a functional block diagram of the control device 21 for executing a process responsive to the fourth operation.
- the control device 21 includes an information acquisition unit 2131, a record hash generation unit 2132, a client certificate creation unit 2133, and a transmission unit 2134.
- the control device 21 functions as the information acquisition unit 2131, the record hash generation unit 2132, the client certificate creation unit 2133, and the transmission unit 2134, for example, by executing a program stored in the ROM 22.
- the information acquisition unit 2131, the record hash generation unit 2132, the client certificate creation unit 2133, and the transmission unit 2134 may be realized, for example, by dedicated hardware (electronic circuitry).
- the input device 25 or the user terminal device 7 When a fourth operation for generating a client certificate is performed on the input device 25 or the user terminal device 7, the input device 25 or the user terminal device 7 outputs a fourth request indicating that the fourth operation has been performed.
- the information acquisition unit 2131 acquires the fourth request from the input device 25 or the user terminal device 7. For example, when a user of the client server 2 performs a fourth operation on the input device 25, the fourth request is input to the information acquisition unit 2131.
- the fourth request includes ID information M6(k2) for identifying the distributed ledger 52 for which the record hash value is to be generated.
- the information acquisition unit 2121 acquires the fourth request, it outputs the fourth request to the record hash generation unit 2132.
- the record hash generation unit 2132 generates a record hash value of the latest (terminal) record in the distributed ledger 52 for which a record hash value is to be generated.
- the record hash generation unit 2132 outputs the generated record hash value to the client certificate creation unit 2133.
- the client certificate creation unit 2133 creates a client certificate that includes the record hash value received from the record hash generation unit 2132.
- the client certificate may include, for example, information for identifying the client server 2 that created the client certificate.
- the client certificate creation unit 2133 outputs the created client certificate to the transmission unit 2134.
- the transmission unit 2134 outputs a control signal to the communication device 24 to transmit the client certificate to the external server 9. As a result, the client certificate is transmitted to the external server 9 via the communication device 24.
- FIG. 8 is a functional block diagram of the control device 21 for executing received transaction data.
- the control device 21 includes a transaction data acquisition unit 2141, a signature verification unit 2142, a record creation unit 2143, a ledger update unit 2144, and an output unit 2145.
- the control device 21 functions as the transaction data acquisition unit 2141, the signature verification unit 2142, the record creation unit 2143, the ledger update unit 2144, and the output unit 2145, for example, by executing a program stored in the ROM 22.
- the transaction data acquisition unit 2141, the signature verification unit 2142, the record creation unit 2143, the ledger update unit 2144, and the output unit 2145 may be realized, for example, by dedicated hardware (electronic circuitry).
- the transaction data acquisition unit 2141 acquires transaction data sent from other client servers 2.
- the transaction data acquisition unit 2141 outputs the acquired transaction data to the signature verification unit 2142.
- the signature verification unit 2142 verifies the validity of the electronic signature (Sig) included in the transaction data. First, the signature verification unit 2142 identifies the client server 2 that sent the transaction data based on the sender information included in the transaction data. Then, the signature verification unit 2142 reads the public key (one of the multiple public keys 272) of the identified client server 2 from the storage device 27. The signature verification unit 2142 uses the read public key to decrypt the electronic signature included in the transaction data. As described above, the electronic signature is obtained by encrypting the hash value or timestamp token of the target data using the private key of the sending client server 2. The signature verification unit 2142 compares the decrypted value with the Obj-HV (hash value or timestamp token) included in the transaction data. By confirming that the two match, the signature verification unit 2142 recognizes the validity of the electronic signature.
- the Obj-HV hash value or timestamp token
- the record creation unit 2143 creates a record to be added to the distributed ledger set 50 based on the transaction data.
- the record creation unit 2143 reads the information of Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV from the transaction data, and creates a record including this information.
- the ledger update unit 2144 adds the record created by the record creation unit 2143 to the distributed ledger set 50, and updates the distributed ledger set 50. Specifically, the ledger update unit 2144 references the key of the created record and identifies the distributed ledger to which the record is to be added. For example, the transaction data generated in response to the first operation of registering/updating the target data described above has "k1" as the key. Therefore, the ledger update unit 2144 adds the record to the distributed ledger 51, which is the evidence chain of the target data.
- the transaction data generated in response to the second operation for obtaining a timestamp token for the terminal record of the distributed ledger 51 and the third operation for obtaining a timestamp token for the terminal record of the distributed ledger 52 has "k2" as the key. Therefore, the ledger update unit 2144 adds the record to the distributed ledger 52, which is the evidence chain of the timestamp token.
- the ledger update unit 2144 When the ledger update unit 2144 has completed updating the distributed ledger set 50, it outputs a message to that effect to the output unit 2145.
- the output unit 2145 outputs a control signal to the communication device 24 to notify the client server 2 that transmitted the transaction data that the process of executing the transaction data (transaction processing) has been completed. As a result, a report of the completion of the transaction processing is transmitted via the communication device 24 to the client server 2 that transmitted the transaction data.
- Fig. 9 is a flowchart showing the procedure of a process for generating transaction data when a first request is received.
- the process of the flowchart shown in Fig. 9 is executed by the control device 21 when a first request is received from the input device 25 or the user terminal device 7.
- steps are abbreviated as "S" of the flowcharts shown in Fig. 9 and Figs. 10, 11, 12, and 13 described below will be described as being realized by software processing by the control device 21, but a part or all of the steps may be realized by hardware (electronic circuits) created within the control device 21.
- control device 21 In S1, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.
- control device 21 reads the target data from the database 4 and generates a hash value of the target data.
- the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the hash value generated in S2 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the nonce value generated in S1 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the hash value generated in S2 and the nonce value generated in S1 to create an electronic signature.
- the control device 21 In S4, the control device 21 generates transaction data including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. Specifically, the control device 21 sets the ID information M1 included in the first request as the Key. The control device 21 also sets the nonce value generated in S1 as the Nonce, the hash value generated in S2 as the Obj-HV, and the electronic signature created in S3 as the Sig. The control device 21 also queries the distributed ledger set 50 for the Key to recognize the Age of the parent record, and sets the Age to the incremented Age of the parent record. The control device 21 also sets the record hash of the parent record as the Prev-HV.
- the control device 21 also hashes the information on Key, Age, Obj-HV, Nonce, Sig, and Prev-HV to the HV.
- the control device 21 may also include in the transaction data time information for broadcasting the transaction data to the network NW and/or sender information of the transaction data.
- control device 21 outputs a control signal to the communication device 24 to transmit the transaction data generated in S4 to the network NW.
- the transaction data is transmitted to the network NW via the communication device 24.
- FIG. 10 is a flowchart showing the steps of the process for generating transaction data when a second request is received.
- the process of the flowchart shown in FIG. 10 is executed by the control device 21 when a second request is received from the input device 25 or the user terminal device 7. Note that the control device 21 may execute the process of the flowchart shown in FIG. 10 when it detects that a record has been added to the distributed ledger 51.
- control device 21 In S11, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.
- control device 21 In S12, the control device 21 generates a record hash value of the terminal record in the distributed ledger 51.
- the control device 21 outputs a control signal to the communication device 24 to transmit the record hash value generated in S12 to the time-stamp authority 8.
- the record hash value is transmitted to the time-stamp authority 8 via the communication device 24.
- the time-stamp authority 8 Having received the record hash value, the time-stamp authority 8 returns a timestamp token to the client server 2 that transmitted the record hash value.
- the control device 21 obtains the timestamp token from the time-stamp authority 8 via the communication device 24.
- the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the timestamp token acquired in S13 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the nonce value generated in S11 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the timestamp token acquired in S13 and the nonce value generated in S11 to create an electronic signature.
- the control device 21 In S15, the control device 21 generates transaction data including the information Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
- the control device 21 sets the ID information M3 (k2) included in the second request as the Key.
- the control device 21 also sets the timestamp token acquired in S13 as Obj-HV.
- the other processes in S15 are basically the same as those in S4 of FIG. 9, so they will not be described repeatedly.
- control device 21 outputs a control signal to the communication device 24 to transmit the transaction data generated in S15 to the network NW.
- the transaction data is transmitted to the network NW via the communication device 24.
- FIG. 11 is a flowchart showing the procedure for processing to generate transaction data when a third request is received. The processing of the flowchart shown in FIG. 11 is executed by the control device 21 when a third request is received from the input device 25 or the user terminal device 7.
- control device 21 In S21, the control device 21 generates a nonce value. This nonce value is used as a number for the transaction data.
- control device 21 In S22, the control device 21 generates a record hash value of the terminal record in the distributed ledger 52.
- control device 21 outputs a control signal to the communication device 24 to transmit the record hash value generated in S22 to the time-stamp authority 8.
- the record hash value is transmitted to the time-stamp authority 8 via the communication device 24.
- the time-stamp authority 8 Having received the record hash value, the time-stamp authority 8 returns a timestamp token to the client server 2 that transmitted the record hash value.
- the control device 21 obtains the timestamp token from the time-stamp authority 8 via the communication device 24.
- the control device 21 reads the private key 271 from the storage device 27, and uses the private key 271 to encrypt the timestamp token acquired in S23 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the nonce value generated in S21 to create an electronic signature.
- the control device 21 may also use the private key 271 to encrypt the timestamp token acquired in S23 and the nonce value generated in S21 to create an electronic signature.
- the control device 21 In S25, the control device 21 generates transaction data including the information Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
- the control device 21 sets the ID information M5 (k2) included in the third request as the Key.
- the control device 21 also sets the timestamp token acquired in S23 as Obj-HV.
- the other processes in S25 are basically the same as those in S4 of FIG. 9, so they will not be described repeatedly.
- control device 21 outputs a control signal to the communication device 24 to transmit the transaction data generated in S25 to the network NW.
- the transaction data is transmitted to the network NW via the communication device 24.
- FIG. 12 is a flowchart showing the procedure for processing when a fourth request is received. The processing of the flowchart shown in FIG. 12 is executed by the control device 21 when a fourth request is received from the input device 25 or the user terminal device 7.
- control device 21 In S31, the control device 21 generates a record hash value of the terminal record in the distributed ledger 52.
- control device 21 creates a client certificate that includes the record hash value generated in S31.
- the control device 21 may include information for identifying itself (Company A) in the client certificate.
- control device 21 outputs a control signal to the communication device 24 to transmit the client certificate created in S32 to the external server 9.
- the client certificate is transmitted to the external server 9 via the communication device 24.
- FIG. 13 is a flowchart showing the procedure of the process executed when transaction data is received. The process of the flowchart shown in FIG. 13 is executed by the control device 21 when transaction data is received.
- control device 21 identifies the client server 2 that sent the transaction data based on the sender information included in the received transaction data.
- control device 21 reads the public key of the client server 2 identified in S41 from the storage device 27.
- control device 21 uses the public key read in S42 to decrypt the electronic signature included in the transaction data.
- the control device 21 verifies the validity of the electronic signature decrypted in S43. Specifically, the control device 21 compares the decrypted value of the electronic signature with Obj-HV (hash value or timestamp token) included in the transaction data. If the two do not match, the control device 21 does not recognize the validity of the electronic signature (NO in S44) and proceeds to S45. If the two match, the control device 21 recognizes the validity of the electronic signature (YES in S44) and proceeds to S46.
- Obj-HV hail value or timestamp token
- control device 21 discards the currently received transaction data because the electronic signature is not valid, and ends the process.
- the control device 21 may cause the display device 26 to display a message indicating that the transaction data may have been tampered with.
- the control device 21 may also transmit a message indicating that the transaction data may have been tampered with to the client server 2 that sent the transaction data.
- control device 21 reads the Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV information from the received transaction data, and creates a record containing this information.
- control device 21 identifies the distributed ledger to which the record will be added based on the key of the record created in S46. The control device 21 then adds the record to the identified distributed ledger. This updates the distributed ledger set 50.
- control device 21 sends a notification (completion report) indicating that the transaction processing has been completed to the client server 2 that sent the transaction data.
- the client server 2 holds a distributed ledger set 50 including two distributed ledgers 51 and 52.
- the distributed ledger 51 is an evidence chain for proving the existence of target data
- the distributed ledger 52 is an evidence chain for proving the existence of a timestamp token.
- a record containing its hash value is stored in the distributed ledger 51. Because records containing the hash value of the target data are managed in the distributed ledger 51, the target data can be made more tamper-resistant. Furthermore, the records stored in the distributed ledger 51 contain the hash value of the target data, rather than the target data itself. This makes it possible to keep the target data itself secret from the other client servers 2 that form the network NW.
- a timestamp token is obtained for the record hash value of the added record (the terminal record of the distributed ledger 51), and a record including the timestamp token is stored in the distributed ledger 52.
- Storing the timestamp token in the distributed ledger 52 can improve the tamper resistance of the timestamp token.
- it can be proven that the expired timestamp token has not been tampered with by a record subsequent to the record including the timestamp token. In this way, the validity of the expired timestamp token can be proven, and the expiration date of the timestamp token can be effectively extended.
- a timestamp token is obtained for the record hash value of the terminal record in the distributed ledger 52. This makes it possible to prove the integrity of the record hash value, and therefore by proving that the record hash value has not been tampered with, it is possible to prove that the series of timestamp tokens stored in the distributed ledger 52 has not been tampered with.
- the tamper resistance of the timestamp token can be improved.
- a client certificate is created that includes the record hash value of the terminal record in the distributed ledger 52, and the client certificate is separated from the client server 2 and managed by the external server 9.
- the distributed ledger set 50 includes N distributed ledgers that are the evidence chains of the N parts, and a distributed ledger that is the evidence chain of the timestamp token.
- the first modification when any of the N distributed ledgers is updated and a second operation is performed, a timestamp token is obtained for the record hash value of the terminal record of the distributed ledger, and a record including the timestamp token is stored in the distributed ledger that is the evidence chain of the timestamp token. Then, similar to the first embodiment, by responding to the third operation and the fourth operation, the same effect as the first embodiment can be achieved.
- FIG. 14 is a diagram showing a schematic configuration of a data management system 1A according to the second embodiment.
- the data management system 1A includes four client servers 3, a platform server 6, a time authentication authority 8, and an external server 9.
- each of the four client servers 3 is a server belonging to a different company (for example, company A, company B, company C, and company D).
- company A for example, company A, company B, company C, and company D.
- company A for example, company A, company B, company C, and company D
- the client server 3 of company A will be described as a representative example, but the client servers 3 of companies B, C, and D also have similar functions.
- the platform server 6 manages the network NW and accepts applications from each client server 3 to participate in the network NW.
- the platform server 6 permits the client server 3 to participate in the network NW based on an operation by the platform server 6 administrator to permit participation, or based on the result of judging a predetermined condition.
- four client servers 3 belonging to each of companies A, B, C, and D are permitted to participate in the network NW.
- the four client servers 3 and the platform server 6 form a network NW.
- Distributed ledger infrastructure software is installed in each of the client servers 3, and each of the client servers 3 functions as a node as a result of the installed distributed ledger infrastructure software functioning.
- the client servers 3 are configured to be able to communicate with a user terminal device 7, similar to the client server 2 in embodiment 1.
- the client server 3 is connected to a database 4.
- the client server 3 (control device 31) generates a control signal for registering/updating the target data in response to an input to the input device 35 or a request from the user terminal device 7, and outputs the control signal to the database 4.
- the client server 3 When the client server 3 registers/updates part data in the database 4, it creates a hash value for the part data and generates transaction data for storing the hash value in the ledger held by the platform server 6 and in the distributed ledger (commit table, described below) held by each client server 3. The client server 3 then transmits the generated transaction data to the platform server 6.
- the platform server 6 has the function of providing finality to transaction data.
- the platform server 6 holds a ledger set 60, processes transaction data received from the client server 3, and updates the ledger set 60.
- the platform server 6 updates the ledger set 60 it transmits the records (proof records described below) that have been added to the ledger by the update to all client servers 3 participating in the network NW.
- the client server 3 stores a commit table 374 that stores the commit records.
- the commit table 374 corresponds to an example of a "distributed ledger" according to the present disclosure.
- Ledger set 60 includes ledger 67 and ledger 68.
- Ledger 67 like distributed ledger 51 according to embodiment 1, stores the update state of the target data in chronological order and forms an evidence chain of the target data.
- Ledger 68 like distributed ledger 52 according to embodiment 1, stores timestamp tokens in chronological order and forms an evidence chain of the timestamp tokens.
- Ledger set 60, ledger 67, and ledger 68 have the same configuration as distributed ledger set 50, distributed ledger 51, and distributed ledger 52 according to embodiment 1, respectively. Therefore, detailed description of these will not be repeated.
- FIG. 15 shows the data structures of ledgers 67 and 68 corresponding to the example shown in FIG. 3. That is, in ledgers 67 and 68, a record of Age "2" is stored as the latest (terminal) record.
- the client server 3 includes a control device 31, a ROM 32, a RAM 33, a communication device 34, an input device 35, a display device 36, and a storage device 37.
- the control device 31, the ROM 32, the RAM 33, the communication device 34, the input device 35, the display device 36, and the storage device 37 are connected to a bus 39.
- the ROM 32, the RAM 33, the communication device 34, the input device 35, and the display device 36 are basically configured in the same manner as the ROM 22, the RAM 23, the communication device 24, the input device 25, and the display device 26 of the client server 2 according to the first embodiment, respectively, and therefore the description thereof will not be repeated.
- the storage device 37 stores a private key 371 and proof data 372.
- the private key 371 is the private key of company A.
- the control device 31 when the client server 3 first joins the network NW, the control device 31 generates a private key and a public key. The control device 31 then sends the generated public key to a certification authority (not shown) for authentication. The certification authority issues an electronic certificate including information about the public key.
- the control device 31 stores the private key 371 corresponding to the authenticated public key in the storage device 37.
- the control device 31 also sends the authenticated public key (electronic certificate) 651 to the platform server 6.
- the proof data 372 includes a suspension table 373 and a commit table 374.
- FIG. 16 is a diagram for explaining an example of the configuration of the suspension table 373.
- FIG. 17 is a diagram for explaining an example of the configuration of the commit table 374.
- the suspension table 373 and the commit table 374 have a configuration corresponding to the ledger set 60.
- the suspension table 373 contains a predetermined type of information contained in unused transaction data. Specifically, the suspension table 373 stores suspension records containing, for example, key and nonce information. The control device 31 stores the key and nonce information contained in the transaction data generated in response to various requests (first to third requests) as a suspension record in the suspension table 373. Note that, below, when the first to third requests are not particularly distinguished from each other, the first to third requests are also collectively referred to as "update requests.”
- the update request received by the client server 3 from the input device 35 or the user terminal device 7 includes ID information for identifying the distributed ledger to which the record is to be added.
- the first request includes ID information M1 indicating "k1".
- the second request includes ID information M3 indicating "k2".
- the third request includes ID information M5 indicating "k2".
- the ID included in the update request for identifying the distributed ledger to which the record is to be added becomes the Key.
- the control device 31 when an update request is received, the control device 31 generates a nonce value.
- the nonce value represents the number of the update request (i.e., the number of the transaction data).
- the control device 31 creates a suspension record including the Key and Nonce information, and registers the suspension record in the suspension table 373.
- FIG. 16 shows an example in which a suspension record including the Key of k1 is registered in the suspension table 373.
- the control device 31 When processing responding to the update request is executed (i.e., when the transaction data is used), the control device 31 deletes from the suspension table 373 the suspension record that contains information about a key that is the same as the key contained in the transaction data used to execute the transaction processing.
- Duplicate suspension records containing the same key information are not registered in the suspension table 373.
- the control device 31 judges whether a suspension record containing a key matching the key contained in the suspension record to be registered has already been registered in the suspension table 373. If a suspension record containing a key matching the key contained in the suspension record to be registered has not been registered in the suspension table 373, the control device 31 registers the suspension record in the suspension table 373. If a suspension record containing a key matching the key contained in the suspension record to be registered has been registered in the suspension table 373, the control device 31 waits for the suspension record containing the matching key to be deleted from the suspension table 373. In other words, in the example shown in FIG. 16, a suspension record containing a key k2 can be registered in the suspension table 373, but a suspension record containing a key k1 cannot be registered.
- commit table 374 includes a predetermined type of information included in used transaction data. Specifically, commit table 374 stores commit records including information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV. In embodiment 2, the commit records have the same information as the records in ledger set 60. Commit table 374 includes commit data 375 that stores a commit record having a key of k1, and commit data 376 that stores a commit record having a key of k2.
- the platform server 6 executes transaction processing and updates the ledgers in the ledger set 60, it creates a proof record and transmits the proof record to all client servers 3 participating in the network NW.
- the proof record is a record that includes, for example, the Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV information of a record that was added to the ledger by a transaction processing executed using the transaction data.
- control device 31 When the control device 31 receives the proof record, it adds the proof record to the commit table 374 (commit data 375 or commit data 376) as a commit record. The control device 31 then deletes from the suspension table 373 any suspension records that contain the same key as the key contained in the added commit record.
- the platform server 6 includes a control device 61, a ROM 62, a RAM 63, a communication device 64, and a storage device 65.
- the control device 61, the ROM 62, the RAM 63, the communication device 64, and the storage device 65 are connected to a bus 69.
- the control device 61 is composed of an integrated circuit including a CPU.
- the control device 61 loads various programs stored in the ROM 62 into the RAM 63 and executes them.
- the various programs include an operating system, etc.
- the RAM 63 functions as a working memory, and temporarily stores various data required for the execution of the various programs.
- the control device 61 receives transaction data from the client server 3 and executes transaction processing.
- the communication device 64 is configured to be able to communicate with the client server 3 participating in the network NW.
- the storage device 65 stores multiple public keys 651 and ledger set 60.
- the multiple public keys 651 include the public keys of companies that manage client servers 3 participating in the network NW.
- the multiple public keys 651 include the public key of company A, the public key of company B, the public key of company C, and the public key of company D.
- ledger set 60 has a similar configuration to distributed ledger set 50 according to embodiment 1, and therefore will not be described again.
- FIG. 18 is a flowchart showing the procedure of processing executed by the data management system 1A when an update request is received.
- the processing of the flowchart shown in FIG. 18 is started by the control device 31 of the client server 3 when an update request is received from the input device 25 or the user terminal device 7.
- control device 31 of the client server 3 generates a nonce value.
- This nonce value is used as the number of the transaction data that is generated in response to the update request.
- the control device 31 of the client server 3 generates a suspension record. Specifically, the control device 31 of the client server 3 reads the ID of the distributed ledger to which the record is to be added, which is included in the update request, and sets it as the Key information, and generates a suspension record using the nonce value generated in S50 as the Nonce information.
- the control device 31 of the client server 3 judges whether the suspension record generated in S51 can be registered in the suspension table 373. If a suspension record having the same key information as the suspension record generated in S51 is registered in the suspension table 373, the control device 31 of the client server 3 makes a negative judgment (NO in S52) and waits for the suspension record having the same key information to be deleted from the suspension table 373. On the other hand, if a suspension record having the same key information as the suspension record generated in S51 is not registered in the suspension table 373, the control device 31 of the client server 3 makes an affirmative judgment (YES in S52) and proceeds to S53.
- control device 31 of the client server 3 registers the suspension record in the suspension table 373.
- the control device 31 of the client server 3 generates transaction data to respond to the update request. Specifically, if the update request is a first request, the control device 31 of the client server 3 executes processes similar to the processes of S2 to S4 described in FIG. 9 to generate transaction data, if the update request is a second request, the control device 31 of the client server 3 executes processes similar to the processes of S12 to S15 described in FIG. 10 to generate transaction data, and if the update request is a third request, the control device 31 executes processes similar to the processes of S22 to S25 described in FIG. 11 to generate transaction data. Details of each process are as described in FIGS. 9, 10, and 11, so they will not be described repeatedly.
- control device 31 of the client server 3 outputs a control signal to the communication device 34 to transmit the transaction data generated in S54 to the platform server 6.
- the transaction data is transmitted to the platform server 6 via the communication device 34.
- control device 61 of the platform server 6 decrypts the electronic signature included in the received transaction data to verify its validity. Specifically, the control device 61 of the platform server 6 executes the same processes as those of S41 to S43 described in FIG. 13 to decrypt the electronic signature. Details of each process are as described in FIG. 13, so they will not be described again.
- the control device 61 of the platform server 6 verifies the validity of the electronic signature decrypted in S60. Specifically, the control device 61 of the platform server 6 compares the decrypted value of the electronic signature with the hash value included in the transaction data (the hash value of the target data in the transaction data generated in response to the first request, and the timestamp token in the transaction data generated in response to the second and third requests). If the two do not match, the control device 61 of the platform server 6 does not recognize the validity of the electronic signature (NO in S61) and proceeds to S62. If the two match, the control device 61 of the platform server 6 recognizes the validity of the electronic signature (YES in S61) and proceeds to S63.
- control device 61 of the platform server 6 determines that the transaction data received from the client server 3 may have been tampered with, discards the transaction data, and creates an abnormality report indicating the possibility of tampering. The control device 61 of the platform server 6 then advances the process to S66.
- control device 61 of the platform server 6 executes transaction processing. Specifically, the control device 61 of the platform server 6 executes processing similar to the processing of S46 and S47 described in FIG. 13, generates a ledger record identified by the key information included in the transaction data, adds the generated record to the ledger, and updates the ledger set 60.
- the control device 61 of the platform server 6 generates a proof record.
- the proof record includes the Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV information contained in the record added to the ledger.
- control device 61 of the platform server 6 creates a success report indicating that the update of the ledger set 60 has been completed (i.e., the transaction data has been processed).
- the control device 61 of the platform server 6 includes a proof record in the success report.
- control device 61 of the platform server 6 outputs a control signal to the communication device 64 to transmit the abnormality report created in S62 or the normality report created in S65 to the client server 3.
- the abnormality report or normality report is transmitted to the client server 3 via the communication device 64.
- control device 61 of the platform server 6 outputs a control signal to the communication device 64 to transmit the proof record to other client servers 3 (e.g., client servers 3 of companies B, C, and D) other than the sender of the transaction data.
- client servers 3 e.g., client servers 3 of companies B, C, and D
- the proof record is transmitted to the other client servers 3 via the communication device 64.
- the control device 31 of the client server 3 determines whether or not a normal report has been received from the platform server 6. If it determines that a normal report has been received (YES in S56), the control device 31 of the client server 3 advances the process to S57. On the other hand, if it determines that a normal report has not been received, i.e., that an abnormality report has been received (NO in S56), the control device 31 of the client server 3 advances the process to S59.
- the control device 31 of the client server 3 adds the proof record included in the normal report as a commit record to the commit table 374. Specifically, the control device 31 of the client server 3 determines whether the target to which the commit record is to be added is commit data 375 or commit data 376, based on the key information of the proof record. Then, the control device 31 of the client server 3 adds the commit record to the target commit data.
- control device 31 of the client server 3 deletes the suspension record that has the same key information as the added commit record from the suspension table 373.
- control device 31 of the client server 3 displays the results of the processing for the update request on the display device 36 or transmits them to the user terminal device 7, for example.
- client servers 3 that received the proof record sent in S66 also add the proof record to the commit table 374 in a similar manner, thereby updating the commit table 374.
- FIG. 19 is a flowchart showing the processing steps when a fourth request is received in embodiment 2. The processing of the flowchart shown in FIG. 19 is executed by the control device 31 when a fourth request is received from the input device 35 or the user terminal device 7.
- control device 31 In S71, the control device 31 generates a record hash value for the terminal record of the commit data 376.
- control device 31 creates a client certificate that includes the record hash value generated in S71.
- the control device 31 may include information for identifying itself (Company A) in the client certificate.
- control device 31 outputs a control signal to the communication device 24 to transmit the client certificate created in S72 to the external server 9.
- the client certificate is transmitted to the external server 9 via the communication device 24.
- the platform server 6 provides finality to transaction data.
- the platform server 6 holds a ledger set 60 including two ledgers 67 and 68.
- the ledger 67 stores the update state of the target data in chronological order
- the ledger 68 stores timestamp tokens in chronological order.
- a proof record having information on the record added to the ledger set 60 is sent from the platform server 6 to each client server 3.
- Each client server 3 adds the proof record as a commit record to the commit table 374.
- the commit table 374 corresponds to the distributed ledger set 50 according to the first embodiment.
- Each client server 3 holds the commit table 374, thereby improving the tamper-resistance of the commit table 374.
- a timestamp token is obtained for the record hash value of the terminal record in the commit data 375 (ledger 67), and the record including the timestamp token is stored in the commit data 376 (ledger 68), making it possible to prove the validity of an expired timestamp token, just as in the first embodiment.
- the tamper resistance of the timestamp token can be improved.
- a client certificate is created that includes the record hash value of the terminal record of the commit data 376, and the client certificate is separated from the client server 3 and managed by the external server 9.
- each of the commit data 375, 376 in the commit table 374 has information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV.
- the commit table 374 may have a part of the information contained in the ledger set 60.
- each of the commit data 375, 376 in the commit table 374 may be configured to include information on Key, Age, Obj-HV, HV, and Nonce from the information on Key, Age, Obj-HV, Nonce, Sig, Prev-HV, and HV contained in each of the ledgers 67, 68 in the ledger set 60.
- the proof record is also generated to include information on Key, Age, Obj-HV, HV, and Nonce. That is, the commit data 375, 376 are summaries of the ledgers 67, 68.
- the amount of data stored in the storage device 37 of the client server 3 can be reduced compared to a case in which the commit data 375, 376 and the ledgers 67, 68 have similar information.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
クライアントサーバ(2)の制御装置(21)は、分散型台帳(51)にレコード(RA1)が格納されると、そのレコードハッシュ値(RH1)に対してタイムスタンプトークン(T0)を取得し、タイムスタンプトークン(T0)を含むレコード(RB0)を分散型台帳(52)に格納する。次に、分散型台帳(51)にレコード(RA2)が格納されると、制御装置(21)は、レコード(RA2)のレコードハッシュ値(RH2)に対してタイムスタンプトークン(T1)を取得する。そして、制御装置(21)は、タイムスタンプトークン(T1)と、レコード(RB0)のレコードハッシュ値とを含むレコード(RB2)を分散型台帳(52)に格納する。
Description
本開示は、分散型台帳技術を用いてデータを管理するデータ管理装置およびデータ管理方法に関する。
従来から、電子データに対してタイムスタンプトークンを取得することで、タイムスタンプトークンに記録されている時刻に上記電子データが存在していたことの証明(存在証明)、および、上記時刻以降に上記電子データが改ざんされていないことの証明(完全性の証明)が行なわれている。
ここで、タイムスタンプトークンには有効期限が存在する。そのため、タイムスタンプトークンの有効期限を超えて、存在証明および完全性の証明を行なう手法が検討されている。
たとえば、特開2014-42214号公報には、タイムスタンプ技術を用いて、長期署名の有効期限を延長する処理を実行するデータ証明システムが開示されている。このデータ証明システムは、複数の原本ファイルの非改ざんを証明する原本証明情報(ES-A)を纏めたESRテーブルを作成し、ESRテーブルの有効期限を延長させる処理を実行する。これによって、ES-A毎に有効期限を延長させる処理を実行する場合に比べて、処理負荷を低減させている(特許文献1参照)。
特許文献1に開示されたデータ証明システムでは、システムの処理負荷の低減について対策されているものの、タイムスタンプトークンの耐改ざん性の向上について考慮されていない。
本開示は、上記課題を解決するためになされたものであり、本開示の目的は、有効期限を超えたタイムスタンプトークンの有効性の証明を可能とするとともに、タイムスタンプトークンの耐改ざん性を向上させることである。
(1)本開示のある局面に係るデータ管理装置は、分散型台帳技術を用いてデータを管理するデータ管理装置である。データ管理装置は、分散型台帳を記憶する記憶装置と、分散型台帳を更新する制御装置と、タイムスタンプトークンを付与する時刻認証局と通信可能に構成された通信装置とを備える。分散型台帳は、データに関する情報を含むレコードを時系列に格納する第1分散型台帳と、時刻認証局から取得されたタイムスタンプトークンを含むレコードを時系列に格納する第2分散型台帳とを含む。制御装置は、通信装置を介して、第1分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第1タイムスタンプトークンを時刻認証局から取得し、第1タイムスタンプトークンを含むレコードを第2分散型台帳に格納する。
上記構成によれば、第1分散型台帳の終端レコードに関する情報に対して取得された第1タイムスタンプトークンが第2分散型台帳で管理される。第2分散型台帳に格納された第1タイムスタンプトークンを改ざんするためには、当該タイムスタンプトークンを含むレコードの後続レコードを全て改ざんしなければならず、第1タイムスタンプトークンの改ざんが困難である。また、第2分散型台帳に格納された、ある第1タイムスタンプトークンの有効期限が切れたとしても、当該第1タイムスタンプトークンを含むレコードの後続レコードにより、上記有効期限が切れた第1タイムスタンプトークンが改ざんされていないことを証明することができる。それゆえに、第1タイムスタンプトークンの有効期限が切れたとしても、その有効性を証明することができる。
(2)ある実施の形態においては、第1分散型台帳の終端レコードに関する情報は、当該終端レコードのハッシュ値である。
上記構成によれば、第1分散型台帳に格納された終端レコードのハッシュ値に対してタイムスタンプトークンが取得される。すなわち、第1分散型台帳に格納されたレコード自体は、時刻認証局に送られないので、タイムスタンプトークンを取得するにあたり、レコード自体を秘匿しておくことができる。
(3)ある実施の形態においては、データ管理装置に対するユーザ操作に応じて、第1タイムスタンプトークンを取得する。
上記構成によれば、ユーザは、任意のタイミングで第1タイムスタンプトークンを取得し、当該第1タイムスタンプトークンを2分散型台帳に格納することができる。
(4)ある実施の形態においては、制御装置は、第1分散型台帳にレコードが追加された場合に、当該レコードに対する第1タイムスタンプトークンを取得する。
上記構成によれば、第1分散型台帳にレコードが追加される毎に、自動的に第1タイムスタンプトークンを取得し、当該第1タイムスタンプトークンを2分散型台帳に格納することができる。
(5)ある実施の形態においては、制御装置は、通信装置を介して、第2分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第2タイムスタンプトークンを時刻認証局から取得し、第2タイムスタンプトークンを含むレコードを第2分散型台帳に格納する。
上記構成によれば、第2分散型台帳の終端レコードに関する情報に対する第2タイムスタンプトークンを取得することにより、当該終端レコードに関する情報の存在証明および完全性の証明を行なうことができる。当該終端レコードに関する情報の存在証明および完全性の証明を行なうことができれば、当該終端レコードより前に第2分散型台帳に格納されているレコード(すなわちタイムスタンプトークン)が改ざんされていないことを証明することができる。
(6)ある実施の形態においては、制御装置は、データ管理装置に対するユーザ操作に応じて、第2タイムスタンプトークンを取得する。
上記構成によれば、ユーザは、任意のタイミングで第2タイムスタンプトークンを取得し、当該第2タイムスタンプトークンを2分散型台帳に格納することができる。
(7)ある実施の形態においては、制御装置は、第2タイムスタンプトークンの前回の取得時点から所定時間が経過すると、第2タイムスタンプトークンを取得する。
上記構成によれば、所定時間が経過する毎に、自動的に第2タイムスタンプトークンを取得し、当該第2タイムスタンプトークンを2分散型台帳に格納することができる。
(8)ある実施の形態においては、通信装置は、さらに、データ管理装置とは異なる外部サーバと通信可能に構成される。制御装置は、通信装置を介して、所定の時点における第2分散型台帳の終端レコードに関する情報を外部サーバに送信する。
上記構成によれば、第2分散型台帳の終端レコードに関する情報がデータ管理装置から分離されて、外部サーバにおいても管理される。第2分散型台帳で管理されるタイムスタンプトークン(第1タイムスタンプトークンおよび/または第2タイムスタンプトークン)を改ざんするためには、データ管理装置で管理されているタイムスタンプトークン、および、外部サーバで管理されている終端レコードに関する情報の両方を改ざんしなければならない。これにより、タイムスタンプトークンの耐改ざん性を高めることができる。
(9)ある実施の形態においては、第2分散型台帳の終端レコードに関する情報は、当該終端レコードのハッシュ値である。
上記構成によれば、第2分散型台帳に格納された終端レコードのハッシュ値に対してタイムスタンプトークンが取得される。すなわち、第2分散型台帳に格納されたレコード自体は、時刻認証局に送られないので、タイムスタンプトークンを取得するにあたり、レコード自体を秘匿しておくことができる。
(10)本開示の他の局面に係るデータ管理方法は、分散型台帳技術を用いてデータを管理するデータ管理装置を用いたデータ管理方法である。データ管理装置は、分散型台帳を記憶する記憶装置と、分散型台帳を更新する制御装置と、タイムスタンプトークンを付与する時刻認証局と通信可能に構成された通信装置とを備える。分散型台帳は、データに関する情報を含むレコードを時系列に格納する第1分散型台帳と、時刻認証局から取得されたタイムスタンプトークンを含むレコードを時系列に格納する第2分散型台帳とを含む。データ管理方法は、通信装置を介して、第1分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第1タイムスタンプトークンを時刻認証局から取得するステップと、第1タイムスタンプトークンを含むレコードを第2分散型台帳に格納するステップとを含む。
(11)ある実施の形態においては、通信装置を介して、第2分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第2タイムスタンプトークンを時刻認証局から取得するステップと、第2タイムスタンプトークンを含むレコードを第2分散型台帳に格納するステップとをさらに含む。
本開示によれば、有効期限を超えたタイムスタンプトークンの有効性の証明を可能とするとともに、タイムスタンプトークンの耐改ざん性を向上させることができる。
以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付して、その説明は繰り返さない。
[実施の形態1]
<データ管理システムの全体構成>
図1は、実施の形態1に係るデータ管理システム1の概略的な構成を示す図である。実施の形態1に係るデータ管理システム1は、複数の企業間でコンソーシアムネットワーク(以下、単に「ネットワーク」とも称する)NWを形成し、分散型台帳技術を用いてデータを管理するためのシステムである。実施の形態1に係るデータ管理システム1は、車両を構成する部品のデータ(以下、単に「部品データ」とも称する)を管理する。部品データは、たとえば、部品の仕様書であってもよい。なお、データ管理システム1が管理するデータは、車両を構成する部品のデータに限られるものではなく、種々のデータであってよい。
<データ管理システムの全体構成>
図1は、実施の形態1に係るデータ管理システム1の概略的な構成を示す図である。実施の形態1に係るデータ管理システム1は、複数の企業間でコンソーシアムネットワーク(以下、単に「ネットワーク」とも称する)NWを形成し、分散型台帳技術を用いてデータを管理するためのシステムである。実施の形態1に係るデータ管理システム1は、車両を構成する部品のデータ(以下、単に「部品データ」とも称する)を管理する。部品データは、たとえば、部品の仕様書であってもよい。なお、データ管理システム1が管理するデータは、車両を構成する部品のデータに限られるものではなく、種々のデータであってよい。
図1を参照して、データ管理システム1は、4台のクライアントサーバ2と、プラットフォームサーバ5と、時刻認証局(TSA:Time Stamp Authority)8と、外部サーバ9とを備える。4台のクライアントサーバ2の各々は、異なる企業(たとえば、A企業、B企業、C企業およびD企業)に帰属するサーバである。
プラットフォームサーバ5は、ネットワークNWを管理する。プラットフォームサーバ5は、各クライアントサーバ2からのネットワークNWへの参加申請を受け付ける。プラットフォームサーバ5は、プラットフォームサーバ5の管理者による参加を許可する操作に基づき、または、所定の条件の判定結果に基づき、クライアントサーバ2のネットワークNWへの参加を許可する。実施の形態1では、A企業、B企業、C企業およびD企業のそれぞれに帰属する4台のクライアントサーバ2に対して、ネットワークNWへの参加が許可されている。
4台のクライアントサーバ2は、ネットワークNWを形成し、部品データのハッシュ値を各々の分散型台帳に記憶している。クライアントサーバ2の各々には、分散型台帳基盤のソフトウェアが導入されており、導入された分散型台帳基盤のソフトウェアが機能することにより、クライアントサーバ2の各々がノードとして機能する。以下においては、A企業のクライアントサーバ2について代表的に説明するが、B企業、C企業およびD企業のクライアントサーバ2も同様の構成および機能を有する。なお、クライアントサーバ2は、本開示に係る「データ管理装置」の一例に相当する。なお、実施の形態1に係るデータ管理システム1においては、ネットワークNWに4台のクライアントサーバが含まれる例について説明するが、ネットワークNWに含まれるクライアントサーバ2の台数は任意であり、たとえば、4台未満であってもよいし、5台以上であってもよい。
クライアントサーバ2は、ユーザ端末装置7と通信可能に構成されている。ユーザ端末装置7は、たとえば、A企業の従業員に貸与された、デスクトップ型のPC(Personal Computer)、ノート型のPC、タブレット端末、スマートフォン、または、通信機能を有するその他の情報処理端末である。
また、クライアントサーバ2には、データベース4が接続されている。データベース4は、部品データを記憶している。データベース4は、クライアントサーバ2からの制御信号に従って、部品データを登録したり、更新したりする。たとえば、クライアントサーバ2のユーザ(たとえば、A企業の従業員等)は、クライアントサーバ2の入力装置25(後述)への操作により部品データの更新を要求したり、ユーザ端末装置7への操作により部品データの更新を要求したりすることができる。クライアントサーバ2(制御装置21)は、入力装置25への入力、あるいは、ユーザ端末装置7からの要求に応じて、部品データを記憶(登録/更新)するための制御信号を生成し、データベース4に出力する。
クライアントサーバ2は、データベース4に部品データを記憶(登録/更新)すると、当該部品データのハッシュ値を生成し、当該ハッシュ値を分散型台帳に格納するためのトランザクションデータを生成する。そして、クライアントサーバ2は、生成されたトランザクションデータを、ネットワークNWを形成する他のクライアントサーバ2、すなわち、B企業,C企業,D企業のクライアントサーバ2に送信する。分散型台帳は、部品データのハッシュ値を時系列に格納し、部品データの存在を証明するための証拠チェーンを形成する。
時刻認証局8は、タイムスタンプトークンを発行する認証機関に帰属するサーバを含む。時刻認証局は、申請者(実施の形態1においては、クライアントサーバ2)からのタイムスタンプ発行要求に応じて、タイムスタンプトークンを発行する。より具体的には、時刻認証局は、申請者から受信したデータ(実施の形態1においては、後述のレコードハッシュ値)に、国際標準時に追跡性がある時刻源に基づく時刻情報を結合させたタイムスタンプトークンを、申請者に送信する。
外部サーバ9は、A企業、B企業、C企業およびD企業のいずれでもない管理主体によって管理されるサーバである。外部サーバ9は、クライアントサーバ2との通信が可能に構成される。外部サーバ9は、クライアントサーバ2から後述するクライアント証明書を受信し、受信されたクライアント証明書を管理する。
クライアントサーバ2は、制御装置21と、ROM(Read Only Memory)22と、RAM(Random Access Memory)23と、通信装置24と、入力装置25と、表示装置26と、記憶装置27とを備える。制御装置21、ROM22、RAM23、通信装置24、入力装置25、表示装置26、および、記憶装置27は、バス29に接続されている。
制御装置21は、たとえば、CPU(Central Processing Unit)を含む集積回路によって構成される。制御装置21は、ROM22に格納されている各種プログラムをRAM23に展開して実行する。各種プログラムには、オペレーティングシステム等が含まれる。RAM23は、ワーキングメモリとして機能し、各種プログラムの実行に必要な各種データを一時的に格納する。制御装置21は、後に詳しく説明するが、データベース4に記録されている部品データを更新したり、分散型台帳を更新するためのトランザクションデータを生成したり、タイムスタンプトークンを取得したりする機能を有する。
通信装置24は、外部の機器との通信が可能に構成される。外部の機器は、たとえば、他のクライアントサーバ2、ユーザ端末装置7、時刻認証局8、および外部サーバ9等を含む。通信装置24と外部の機器との通信は、インターネット、ワイドエリアネットワーク(WAN)、ローカルエリアネットワーク(LAN)、イーサネット(登録商標)ネットワーク、パブリックネットワーク、プライベートネットワーク、有線ネットワークまたは無線ネットワーク等、あるいは、これらの組み合わせを用いて行なわれる。
入力装置25は、入力デバイスを含む。入力デバイスは、たとえば、マウス、キーボード、タッチパネル、および/または、ユーザの操作を受け付けることが可能なその他の装置である。
表示装置26は、ディスプレイを含む。表示装置26は、制御装置21からの制御信号に従って、ディスプレイに各種の画像を表示させる。ディスプレイは、たとえば、液晶ディスプレイ、有機EL(Electro Luminescence)ディスプレイ、または、その他の表示機器である。
記憶装置27は、たとえば、ハードディスクまたはフラッシュメモリ等の記憶媒体を含んで構成される。記憶装置27は、秘密鍵271、複数の公開鍵272および分散型台帳セット50を記憶している。
秘密鍵271は、A企業の秘密鍵である。たとえば、クライアントサーバ2がネットワークNWに最初に参加するにあたり、制御装置21は、秘密鍵および公開鍵を生成する。そして、制御装置21は、生成された公開鍵を認証局(図示せず)に送信して、認証を受ける。認証局は、電子証明書を発行する認証機関である。認証局は、公開鍵の情報を含めた電子証明書を発行する。制御装置21は、認証を受けた公開鍵に対応する秘密鍵271を記憶装置27に記憶させる。また、制御装置21は、認証を受けた公開鍵(電子証明書)272を、B企業、C企業およびD企業のクライアントサーバ2に送信する。
複数の公開鍵272は、B企業の公開鍵、C企業の公開鍵およびD企業の公開鍵を含む。制御装置21は、他のクライアントサーバ2から受信した公開鍵を記憶装置27に記憶させる。また、記憶装置27は、自身(A企業)の公開鍵を記憶していてもよい。
分散型台帳セット50は、複数の分散型台帳を含む。図2は、分散型台帳セット50の構成の一例を示す図である。実施の形態1では、車両を構成する1個の部品がデータ管理システム1で管理される例を説明する。以下では、分散型台帳でデータが管理される部品を「対象部品」とも称する。また、対象部品の部品データを「対象データ」とも称する。
分散型台帳セット50は、2つの分散型台帳51,52を含む。分散型台帳51は、対象データの更新状態を時系列に記憶し、対象データの証拠チェーン(以下では「第1証拠チェーン」とも称する)として機能する。分散型台帳52は、タイムスタンプトークンを時系列に記憶し、タイムスタンプトークンの証拠チェーン(以下では「第2証拠チェーン」とも称する)として機能する。
分散型台帳51は、対象データのハッシュ値を含むレコードを時系列に記憶している。レコードは、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報を含む。
Keyは、対象部品のIDを示す情報である。対象部品には、k1のIDが割り当てられている。また、Keyは、分散型台帳51,52を識別するためのIDでもともいえる。分散型台帳51は、k1のKeyを含むレコードを時系列に記憶し、分散型台帳52は、k2のKeyを含むレコードを時系列に記憶する。
Ageは、レコードの世代を示す情報である。分散型台帳51に格納された、対象部品の最初のレコードでは、Ageは0である。対象部品の更新が行なわれ、レコードが追加されると、Ageはインクリメントされる。
Obj-HVは、対象データのハッシュ値である。たとえば、データベース4に記憶されている対象データが更新されると、更新された対象データのハッシュ値が生成され、Obj-HVとされる。ハッシュ値は、ハッシュ関数を用いて対象データをハッシュ化した結果として得られる数値である。
Nonceは、トランザクションデータの番号を示すナンス値である。つまり、ナンス値は、たとえば、データベース4に記憶された対象データが更新された場合に、当該更新された対象データのハッシュ値を分散型台帳51に格納する処理の番号として、クライアントサーバ2(制御装置21)により生成される。ナンス値は、暗号学的に衝突が困難なハッシュ値である。
Sigは、トランザクションデータを発行したクライアントサーバ2の秘密鍵271を用いて作成された電子署名である。電子署名は、たとえば、Obj-HV(すなわち、対象データのハッシュ値)を秘密鍵271により暗号化することにより作成される。あるいは、電子署名は、たとえば、Nonce(ナンス値)を秘密鍵271により暗号化することにより作成されてもよい。
Prev-HVは、最新(終端)レコードの1つ前の世代のレコード(親レコード)のハッシュ値である。すなわち、Prev-HVは、親レコードのHVである。
HVは、レコードのハッシュ値である。具体的には、HVは、HVを除くレコードの情報(Key、Age、Obj-HV、Nonce、SigおよびPrev-HV)のハッシュ値(以下「レコードハッシュ値」とも称する)である。
たとえば、図2に示されるように、分散型台帳51の最新(終端)レコード(Age「2」のレコード)に着目すると、終端レコードのPrev-HVは、親レコード(Age「1」)のHVである「H2」である。次に第1部品の部品データが更新されて、Age「3」のレコードが追加される場合には、Age「3」のレコードのPrev-HVは、Age「2」のレコードのHVである「H3」となる。このように、終端レコードは、親レコードのレコードハッシュ値を含む構造となっている。換言すると、終端レコードのPrev-HVと、親レコードのHVとの間でレコードの連鎖が実現されている。このようにして、分散型台帳51は、DAG(Directed Acyclic Graph)構造を成している。
分散型台帳52は、タイムスタンプトークンを含むレコードを時系列に記憶している。レコードは、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報を含む。「Age」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報の詳細は、分散型台帳51のレコードと同様であるため、繰り返し説明しない。
Keyは、時刻認証局8から取得されたタイムスタンプトークンのIDを示す情報である。タイムスタンプトークンには、k2のIDが割り当てられる。
Obj-HVは、タイムスタンプトークンの値である。Obj-HVには、後述するように、分散型台帳51のレコードハッシュ値に対して取得されたタイムスタンプトークン、または、分散型台帳52のレコードハッシュ値に対して取得されたタイムスタンプトークンが格納される。
クライアントサーバ2の制御装置21は、以下に説明する第1~第4操作に応答する機能を有する。
<第1操作>
図1および図2を参照して、たとえば、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、データベース4に対象データを登録するための操作、または、データベース4に登録された対象データを更新するための操作を行なうことができる。なお、以下では、上記の登録するための操作および更新するための操作を総称して「第1操作」とも称する。
図1および図2を参照して、たとえば、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、データベース4に対象データを登録するための操作、または、データベース4に登録された対象データを更新するための操作を行なうことができる。なお、以下では、上記の登録するための操作および更新するための操作を総称して「第1操作」とも称する。
第1操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第1操作に応答して、第1操作が行なわれたことを示す第1要求を出力する。クライアントサーバ2(制御装置21)は、第1要求に応答して、データベース4に対象データを登録、または、データベース4に記憶された対象データを更新する。そして、クライアントサーバ2(制御装置21)は、登録または更新された対象データのハッシュ値を含むレコードを分散型台帳51に追加するためのトランザクションデータを生成する。このトランザクションデータには、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報が含まれる。
トランザクションデータには、さらに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする(ネットワークNWへ送信する)時刻情報、および、当該トランザクションデータの送信者情報が含まれてもよい。時刻情報は、たとえば、対象データがデータベース4に記録された時刻を示す情報であってもよい。送信者情報は、たとえば、A企業を示す情報である。なお、トランザクションデータの送信者情報は、さらに詳細に、ネットワークNWへトランザクションデータを送信する操作を実行した部署(A企業の一部門)を示す情報であってもよいし、ネットワークNWへトランザクションデータを送信する操作を実行した個人(A企業の従業員)を示す情報であってもよい。
このトランザクションデータが処理されることによって、登録または更新された対象データのハッシュ値を含むレコードが分散型台帳51に追加される。
<第2操作>
また、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、分散型台帳51の終端レコードに対するタイムスタンプトークンを取得するための操作(以下「第2操作」とも称する)を行なうことができる。
また、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、分散型台帳51の終端レコードに対するタイムスタンプトークンを取得するための操作(以下「第2操作」とも称する)を行なうことができる。
第2操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第2操作に応答して、第2操作が行なわれたことを示す第2要求を出力する。クライアントサーバ2(制御装置21)は、第2要求に応答して、分散型台帳51の終端レコードのレコードハッシュ値を生成し、当該レコードハッシュ値に対するタイムスタンプトークンを取得する。そして、クライアントサーバ2(制御装置21)は、タイムスタンプトークンを含むレコードを分散型台帳52に追加するためのトランザクションデータを生成する。このトランザクションデータには、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報が含まれる。また、トランザクションデータには、時刻情報、および、送信者情報が含まれてもよい。このトランザクションデータが処理されることによって、分散型台帳51の終端レコードのレコードハッシュ値に対して取得されたタイムスタンプトークンを含むレコードが、分散型台帳52に追加される。
なお、クライアントサーバ2(制御装置21)は、分散型台帳51に新たなレコードが追加されたことを検知した場合に、第2要求に応答する処理を自動的に実行するように構成されてもよい。すなわち、クライアントサーバ2(制御装置21)は、分散型台帳51に新たなレコードが追加されたことを検知すると、当該レコードのレコードハッシュ値を生成し、当該レコードハッシュ値に対するタイムスタンプトークンを取得する。そして、クライアントサーバ2(制御装置21)は、タイムスタンプトークンを含むレコードを分散型台帳52に追加するためのトランザクションデータを生成する。
<第3操作>
さらに、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、分散型台帳52の終端レコードに対するタイムスタンプトークンを取得するための操作(以下「第3操作」とも称する)を行なうことができる。
さらに、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、分散型台帳52の終端レコードに対するタイムスタンプトークンを取得するための操作(以下「第3操作」とも称する)を行なうことができる。
第3操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第3操作に応答して、第3操作が行なわれたことを示す第3要求を出力する。クライアントサーバ2(制御装置21)は、第3要求に応答して、分散型台帳52の終端レコードのレコードハッシュ値を生成し、当該レコードハッシュ値に対するタイムスタンプトークンを取得する。そして、クライアントサーバ2(制御装置21)は、タイムスタンプトークンを含むレコードを分散型台帳52に追加するためのトランザクションデータを生成する。このトランザクションデータには、「Key」、「Age」、「Obj-HV」、「Nonce」、「Sig」、「Prev-HV」、および、「HV」の情報が含まれる。また、トランザクションデータには、時刻情報、および、送信者情報が含まれてもよい。
<第4操作>
さらに、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、クライアント証明書を生成するための操作(以下「第4操作」とも称する)を行なうことができる。クライアント証明書は、第4操作が行なわれた時点における、分散型台帳52の終端レコードのレコードハッシュ値を含むデータである。
さらに、クライアントサーバ2のユーザは、入力装置25あるいはユーザ端末装置7に対して、クライアント証明書を生成するための操作(以下「第4操作」とも称する)を行なうことができる。クライアント証明書は、第4操作が行なわれた時点における、分散型台帳52の終端レコードのレコードハッシュ値を含むデータである。
第4操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第4操作に応答して、第4操作が行なわれたことを示す第4要求を出力する。クライアントサーバ2(制御装置21)は、第4要求に応答して、分散型台帳52の終端レコードのレコードハッシュ値を生成し、当該レコードハッシュ値を含むクライアント証明書を作成する。そして、クライアントサーバ2(制御装置21)は、通信装置24を介して、クライアント証明書を外部サーバ9に送信する。
<分散型台帳セットの更新>
図3は、分散型台帳セット50の更新を説明するための図である。図3の上段には、第1証拠チェーンである分散型台帳51が模式的に示されており、図3の下段には、第2証拠チェーンである分散型台帳52が模式的に示されている。
図3は、分散型台帳セット50の更新を説明するための図である。図3の上段には、第1証拠チェーンである分散型台帳51が模式的に示されており、図3の下段には、第2証拠チェーンである分散型台帳52が模式的に示されている。
第1証拠チェーン(分散型台帳51)には、対象部品の部品データ(対象データ)のハッシュ値が時系列に記憶されている。対象データを登録するための操作(第1操作)により対象データD0が最初にデータベース4に登録されると、その対象データD0のハッシュ値を含むAge「0」のレコードRA0が分散型台帳51に格納される。次に、対象データを更新するための操作(第1操作)により対象データが更新され、更新された対象データD1がデータベース4に登録されると、更新された対象データD1のハッシュ値と、Age「0」である親レコードRA0のレコードハッシュ値とを含むAge「1」のレコードRA1が分散型台帳51に格納される。さらに、対象データを更新するための操作(第1操作)により対象データが更新され、更新された対象データD2がデータベース4に登録されると、更新された対象データD2のハッシュ値と、Age「1」である親レコードRA1のレコードハッシュ値とを含むAge「2」のレコードRA2が分散型台帳51に格納される。同様にして、対象データがD3,D4へと更新される毎に、対象データD3,D4のハッシュ値を含むレコードRA3,RA4が分散型台帳51に格納されていく。
第2証拠チェーン(分散型台帳52)には、タイムスタンプトークンが時系列に記憶されている。分散型台帳51の初回更新がなされ、分散型台帳51にレコードRA1が追加され、レコードRA1が分散型台帳51の終端レコードである場面を想定する。この場面において第2操作が行なわれると、レコードRA1のレコードハッシュ値RH1が生成される。そして、レコードハッシュ値RH1に対するタイムスタンプトークンT0が取得され、当該タイムスタンプトークンT0を含むAge「0」のレコードRB0が分散型台帳52に格納される。次に、分散型台帳51の更新がなされ、分散型台帳51にレコードRA2が追加された場面を想定する。この場面において第2操作が行なわれると、レコードRA2のレコードハッシュ値RH2が生成される。そして、レコードハッシュ値RH2に対するタイムスタンプトークンT1が取得され、当該タイムスタンプトークンT1と、Age「0」である親レコードRB0のレコードハッシュ値とを含むAge「1」のレコードRB1が分散型台帳52に格納される。なお、上述したとおり、分散型台帳51にレコードが追加された場合に、当該レコードのレコードハッシュ値に対するタイムスタンプトークンが自動的に取得されてもよい。
また、第2操作は、ユーザが任意のタイミングで行なうことができる。すなわち、上記では、分散型台帳51にレコードが追加される毎に第2操作が行なわれる例を示しているが、第2操作は、分散型台帳51にレコードが追加される毎に行なわれなくてもよい。たとえば、第2操作は、分散型台帳51にレコードが追加される所定回数おきに行なわれてもよいし、前回第2操作が行なわれてから第1所定時間が経過したときに行なわれてもよい。第1所定時間は、たとえば、タイムスタンプトークンの有効期限を考慮して設定してもよい。
分散型台帳52の終端レコードがレコードRB1である場面を想定する。この場面において、入力装置25またはユーザ端末装置7に対して第3操作(分散型台帳52の終端レコードに対するタイムスタンプトークンを取得するための操作)が行なわれると、分散型台帳52の終端レコードRB1のレコードハッシュ値RH3が生成される。そして、レコードハッシュ値RH3に対するタイムスタンプトークンT2が取得され、当該タイムスタンプトークンT2と、親レコードRB1のレコードハッシュ値とを含むAge「2」のレコードRB2が分散型台帳52に格納される。第3操作は、ユーザの任意のタイミングで行なうことができる。なお、第3操作によらず、前回に分散型台帳52にレコードが追加されてから第2所定時間が経過した場合に、分散型台帳52の終端レコードのレコードハッシュ値に対してタイムスタンプトークンが取得されてもよい。第2所定時間は、たとえば、タイムスタンプトークンの有効期限を考慮して設定してもよい。第2所定時間は、上述の第1所定時間と同じ時間に設定されてもよいし、異なる時間に設定されてもよい。
次に、分散型台帳52の終端レコードがレコードRB2である場面を想定する。この場面において、入力装置25またはユーザ端末装置7に対して第4操作(クライアント証明書を作成するための操作)が行なわれると、分散型台帳52の終端レコードRB2のレコードハッシュ値RH4が生成される。そして、レコードハッシュ値RH4を含めたクライアント証明書CPが作成される。このクライアント証明書CPは、クライアントサーバ2から分離して管理される。たとえば、クライアント証明書CPは、通信装置24を介して外部サーバ9に送られる。
なお、第4操作は、任意のタイミングで行なうことができる。たとえば、分散型台帳52の終端レコードがレコードRB1である場面において、第4操作が行なわれると、分散型台帳52の終端レコードRB1のレコードハッシュ値を含めたクライアント証明書が作成される。このクライアント証明書を通信装置24を介して外部サーバ9に送ってもよい。
上記のようにして、対象データが更新される毎に、そのハッシュ値を含むレコードを分散型台帳51に格納していく。対象データのハッシュ値を分散型台帳51で管理することにより、対象データの耐改ざん性を高めることができる。
また、一般に、タイムスタンプトークンには有効期限が定められている。有効期限の切れたタイムスタンプトークンでは、対象データ(ハッシュ値)の存在証明および完全性の証明を行なうことができない。そこで、上記のようにして、分散型台帳51の終端レコードに対して取得されたタイムスタンプトークンを分散型台帳52に格納していく。分散型台帳52では、親レコードのレコードハッシュ値を含んでレコードの連鎖が実現されているので、有効期限の切れたタイムスタンプトークンを改ざんするためには、当該有効期限の切れたタイムスタンプトークンが格納された以降に分散型台帳52に追加されたタイムスタンプトークンを全て改ざんしなければならない。このように、タイムスタンプトークンを分散型台帳52に格納していくことで、タイムスタンプトークンの耐改ざん性を高めることができる。たとえば、レコードRB0に格納されたタイムスタンプトークンT0の有効期限が切れた場合であっても、後続のレコードRB1,RB2により、タイムスタンプトークンT0が改ざんされていないことを証明することができる。このように、タイムスタンプトークンT0の有効性を証明することができるので、タイムスタンプトークンT0の有効期限を実質的に延長することができる。すなわち、タイムスタンプトークンT0により、対象データD1の存在証明および完全性の証明を行なうことができる。
さらに、任意のタイミングで分散型台帳52の終端レコードRB1のレコードハッシュ値RH3に対してタイムスタンプトークンT2を取得する。分散型台帳52のレコードハッシュ値RH3に対してタイムスタンプトークンT2を取得することにより、タイムスタンプトークンT2が証明する時刻にレコードRB1が存在したこと、および、タイムスタンプトークンT2が証明する時刻以降にレコードRB1が改ざんされていないことを証明することが可能となる。これにより、タイムスタンプトークンT2が証明する時刻にレコードRB1が存在し、かつ、分散型台帳52に格納されている一連のタイムスタンプトークンが改ざんされていないことを証明することができる。
さらに、レコードハッシュ値RH3に対して取得したタイムスタンプトークンT2と、親レコードRB1のレコードハッシュ値とを含むレコードRB2を分散型台帳52に格納することにより、タイムスタンプトークンT3の耐改ざん性を高めることができる。
また、クライアント証明書CPがクライアントサーバ2から分離されて、外部サーバ9で管理される。これにより、たとえ分散型台帳セット50の全てのレコードを改ざんされたとしても、外部サーバ9で管理されているクライアント証明書CPにより、分散型台帳セット50が改ざんされたことを証明することができる。
なお、第1操作、第2操作、第3操作および第4操作は、たとえば、表示装置26またはユーザ端末装置7の表示画面に表示された、それぞれの要求ボタン(第1ボタン、第2ボタン、第3ボタンおよび第4ボタン)をユーザが選択する操作であってもよい。
<機能ブロック>
図4は、第1操作に応答する処理を実行するための制御装置21の機能ブロック図である。図4を参照して、制御装置21は、情報取得部2101と、ハッシュ生成部2102と、ナンス生成部2103と、電子署名部2104と、トランザクションデータ生成部2105と、トランザクションデータ送信部2106とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104トランザクションデータ生成部2105、および、トランザクションデータ送信部2106として機能する。なお、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104、トランザクションデータ生成部2105、および、トランザクションデータ送信部2106は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
図4は、第1操作に応答する処理を実行するための制御装置21の機能ブロック図である。図4を参照して、制御装置21は、情報取得部2101と、ハッシュ生成部2102と、ナンス生成部2103と、電子署名部2104と、トランザクションデータ生成部2105と、トランザクションデータ送信部2106とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104トランザクションデータ生成部2105、および、トランザクションデータ送信部2106として機能する。なお、情報取得部2101、ハッシュ生成部2102、ナンス生成部2103、電子署名部2104、トランザクションデータ生成部2105、および、トランザクションデータ送信部2106は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
入力装置25あるいはユーザ端末装置7に対して、対象データを登録または更新する第1操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第1操作が行なわれたことを示す第1要求を出力する。
情報取得部2101は、入力装置25あるいはユーザ端末装置7から、第1要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25に対して第1操作を行なうと、第1要求が情報取得部2101に入力される。第1要求には、レコードを追加する対象となる分散型台帳51を特定するためのID(Key)情報M1が含まれている。情報取得部2101は、第1要求を取得すると、第1要求をハッシュ生成部2102およびナンス生成部2103に出力する。
ハッシュ生成部2102は、第1要求を受けると、たとえばデータベース4から対象データを読み出して対象データのハッシュ値を生成する。ハッシュ生成部2102は、生成されたハッシュ値およびID情報M1を、電子署名部2104およびトランザクションデータ生成部2105に出力する。
ナンス生成部2103は、第1要求を受けると、ナンス値を生成する。ナンス値は、暗号学的に衝突が困難なハッシュ値である。ナンス生成部2103は、生成されたナンス値およびID情報M1を、トランザクションデータ生成部2105に出力する。なお、電子署名の作成にナンス値が用いられる場合には、ナンス生成部2103は、ナンス値およびIDの情報M1を電子署名部2104に出力してもよい。
電子署名部2104は、記憶装置27から秘密鍵271を読み出す。電子署名部2104は、ハッシュ生成部2102から受けたハッシュ値を秘密鍵271により暗号化することで電子署名を作成する。電子署名部2104は、作成された電子署名およびID情報M1をトランザクションデータ生成部2105に出力する。また、電子署名部2104は、ナンス生成部2103から受けたナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。また、電子署名部2104は、ハッシュ値およびナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。
トランザクションデータ生成部2105は、ネットワークNWへ送信するためのトランザクションデータを生成する。たとえば、トランザクションデータ生成部2105は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。トランザクションデータ生成部2105は、たとえば、分散型台帳セット50にID情報M1(Key)を照会させることで親レコードのAgeを認識し、親レコードのAgeをインクリメントして、追加するレコードのAgeとする。トランザクションデータ生成部2105は、ハッシュ生成部2102により生成されたハッシュ値をObj-HVとし、ナンス生成部2103により生成されたナンス値をNonceとし、電子署名部2104により作成された電子署名をSigとする。また、トランザクションデータ生成部2105は、親レコードのレコードハッシュ値をPrev-HVとする。トランザクションデータ生成部2105は、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HVの情報をハッシュ化して、HVとする。トランザクションデータには、さらに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする(ネットワークNWへ送信する)時刻情報、および、当該トランザクションデータの送信者情報が含まれてもよい。トランザクションデータ生成部2105は、生成されたトランザクションデータをトランザクションデータ送信部2106に出力する。
トランザクションデータ送信部2106は、トランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図5は、第2操作に応答する処理を実行するための制御装置21の機能ブロック図である。図5を参照して、制御装置21は、情報取得部2111と、レコードハッシュ生成部2112と、ナンス生成部2113と、タイムスタンプトークン取得部2114と、電子署名部2115と、トランザクションデータ生成部2116と、トランザクションデータ送信部2117とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2111、レコードハッシュ生成部2112、ナンス生成部2113、タイムスタンプトークン取得部2114、電子署名部2115、トランザクションデータ生成部2116、および、トランザクションデータ送信部2117として機能する。なお、情報取得部2111、レコードハッシュ生成部2112、ナンス生成部2113、タイムスタンプトークン取得部2114、電子署名部2115、トランザクションデータ生成部2116、および、トランザクションデータ送信部2117は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
入力装置25あるいはユーザ端末装置7に対して、分散型台帳51の終端レコードに対するタイムスタンプトークンを取得するための第2操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第2操作が行なわれたことを示す第2要求を出力する。
情報取得部2111は、入力装置25あるいはユーザ端末装置7から、第2要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25に対して第2操作を行なうと、第2要求が情報取得部2111に入力される。第2要求には、タイムスタンプトークンの取得対象となる分散型台帳51を特定するためのID情報M2と、レコードを追加する対象となる分散型台帳52を特定するためのID情報M3が含まれている。情報取得部2111は、第2要求を取得すると、第2要求をレコードハッシュ生成部2112およびナンス生成部2113に出力する。
なお、情報取得部2111は、分散型台帳51の更新状態を監視し、第1操作に応答して分散型台帳51にレコードが追加されたことをもって、第2要求を取得したと判断してもよい。
レコードハッシュ生成部2112は、第2要求を受けると、ID情報M2により特定される分散型台帳51の最新(終端)レコードのレコードハッシュ値を生成する。レコードハッシュ生成部2112は、生成されたレコードハッシュ値と、ID情報M3とを、タイムスタンプトークン取得部2114に出力する。
ナンス生成部2113は、第2要求を受けると、ナンス値を生成する。ナンス生成部2113は、生成されたナンス値およびID情報M3を、トランザクションデータ生成部2116に出力する。なお、電子署名の作成にナンス値が用いられる場合には、ナンス生成部2113は、ナンス値およびID情報M3を電子署名部2115に出力してもよい。
タイムスタンプトークン取得部2114は、レコードハッシュ生成部2112から受けたレコードハッシュ値に対するタイムスタンプトークンを取得する。具体的には、タイムスタンプトークン取得部2114は、レコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。レコードハッシュ値を受信した時刻認証局8は、レコードハッシュ値の送信元のクライアントサーバ2へタイムスタンプトークンを返信する。タイムスタンプトークン取得部2114は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを取得する。タイムスタンプトークン取得部2114は、タイムスタンプトークン、および、タイムスタンプトークンを格納する分散型台帳52を特定するためのID情報M3を、電子署名部2115およびトランザクションデータ生成部2116に出力する。
電子署名部2115は、記憶装置27から秘密鍵271を読み出す。電子署名部2115は、タイムスタンプトークン取得部2114から受けたタイムスタンプトークンを秘密鍵271により暗号化することで電子署名を作成する。電子署名部2115は、作成された電子署名およびID情報M3をトランザクションデータ生成部2116に出力する。また、電子署名部2115は、ナンス生成部2113から受けたナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。また、電子署名部2115は、タイムスタンプトークンおよびナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。
トランザクションデータ生成部2116は、ネットワークNWへ送信するためのトランザクションデータを生成する。たとえば、トランザクションデータ生成部2116は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。トランザクションデータ生成部2116は、ID情報M3(k2)をKeyとする。また、トランザクションデータ生成部2116は、タイムスタンプトークンをObj-HVとする。トランザクションデータ生成部2116のその他の機能は、図4で説明したトランザクションデータ生成部2105と基本的に同様である。
トランザクションデータ送信部2117は、トランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図6は、第3操作に応答する処理を実行するための制御装置21の機能ブロック図である。図6を参照して、制御装置21は、情報取得部2121と、レコードハッシュ生成部2122と、ナンス生成部2123と、タイムスタンプトークン取得部2124と、電子署名部2125と、トランザクションデータ生成部2126と、トランザクションデータ送信部2127とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2121、レコードハッシュ生成部2122、ナンス生成部2123、タイムスタンプトークン取得部2124、電子署名部2125、トランザクションデータ生成部2126、および、トランザクションデータ送信部2127として機能する。なお、情報取得部2121、レコードハッシュ生成部2122、ナンス生成部2123、タイムスタンプトークン取得部2124、電子署名部2125、トランザクションデータ生成部2126、および、トランザクションデータ送信部2127は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
入力装置25あるいはユーザ端末装置7に対して、分散型台帳52の終端レコードに対するタイムスタンプトークンを取得するための第3操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第3操作が行なわれたことを示す第3要求を出力する。
情報取得部2121は、入力装置25あるいはユーザ端末装置7から、第3要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25に対して第3操作を行なうと、第3要求が情報取得部2121に入力される。第3要求には、タイムスタンプトークンの取得対象となる分散型台帳52を特定するためのID情報M4、および、タイムスタンプトークンを格納する分散型台帳52を特定するためのID情報M5が含まれている。情報取得部2121は、第3要求を取得すると、第3要求をレコードハッシュ生成部2122およびナンス生成部2123に出力する。
レコードハッシュ生成部2122は、第3要求を受けると、ID情報M4により特定される分散型台帳52の最新(終端)レコードのレコードハッシュ値を生成する。レコードハッシュ生成部2122は、生成されたレコードハッシュ値と、ID情報N5とを、タイムスタンプトークン取得部2124に出力する。
ナンス生成部2123は、第3要求を受けると、ナンス値を生成する。ナンス生成部2123は、生成されたナンス値およびID情報M5を、トランザクションデータ生成部2126に出力する。なお、電子署名の作成にナンス値が用いられる場合には、ナンス生成部2123は、ナンス値およびID情報M5を電子署名部2125に出力してもよい。
タイムスタンプトークン取得部2124は、レコードハッシュ生成部2122から受けたレコードハッシュ値に対するタイムスタンプトークンを取得する。具体的には、タイムスタンプトークン取得部2124は、レコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。レコードハッシュ値を受信した時刻認証局8は、レコードハッシュ値の送信元のクライアントサーバ2へタイムスタンプトークンを返信する。タイムスタンプトークン取得部2124は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを取得する。タイムスタンプトークン取得部2124は、タイムスタンプトークン、および、タイムスタンプトークンを格納する分散型台帳52を特定するためのID情報M5を、電子署名部2125およびトランザクションデータ生成部2126に出力する。
電子署名部2125は、記憶装置27から秘密鍵271を読み出す。電子署名部2125は、タイムスタンプトークン取得部2124から受けたタイムスタンプトークンを秘密鍵271により暗号化することで電子署名を作成する。電子署名部2125は、作成された電子署名およびID情報M5をトランザクションデータ生成部2126に出力する。また、電子署名部2125は、ナンス生成部2123から受けたナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。また、電子署名部2125は、タイムスタンプトークンおよびナンス値を秘密鍵271により暗号化することで電子署名を作成してもよい。
トランザクションデータ生成部2126は、ネットワークNWへ送信するためのトランザクションデータを生成する。たとえば、トランザクションデータ生成部2126は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。トランザクションデータ生成部2126は、ID情報M5(k2)をKeyとする。また、トランザクションデータ生成部2126は、タイムスタンプトークンをObj-HVとする。トランザクションデータ生成部2126のその他の機能は、図4で説明したトランザクションデータ生成部2105と基本的に同様である。
トランザクションデータ送信部2127は、トランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図7は、第4操作に応答する処理を実行するための制御装置21の機能ブロック図である。図7を参照して、制御装置21は、情報取得部2131と、レコードハッシュ生成部2132と、クライアント証明書作成部2133と、送信部2134とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、情報取得部2131、レコードハッシュ生成部2132、クライアント証明書作成部2133、および、送信部2134として機能する。なお、情報取得部2131、レコードハッシュ生成部2132、クライアント証明書作成部2133、および、送信部2134は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
入力装置25あるいはユーザ端末装置7に対して、クライアント証明書を生成するための第4操作が行なわれると、入力装置25あるいはユーザ端末装置7は、第4操作が行なわれたことを示す第4要求を出力する。
情報取得部2131は、入力装置25あるいはユーザ端末装置7から、第4要求を取得する。たとえば、クライアントサーバ2のユーザが、入力装置25に対して第4操作を行なうと、第4要求が情報取得部2131に入力される。第4要求には、レコードハッシュ値の生成対象となる分散型台帳52を特定するためのID情報M6(k2)が含まれている。情報取得部2121は、第4要求を取得すると、第4要求をレコードハッシュ生成部2132に出力する。
レコードハッシュ生成部2132は、レコードハッシュ値の生成対象となる分散型台帳52の最新(終端)レコードのレコードハッシュ値を生成する。レコードハッシュ生成部2132は、生成されたレコードハッシュ値を、クライアント証明書作成部2133に出力する。
クライアント証明書作成部2133は、レコードハッシュ生成部2132から受けたレコードハッシュ値を含めたクライアント証明書を作成する。クライアント証明書には、たとえば、当該クライアント証明書を作成したクライアントサーバ2を特定するための情報が含まれてもよい。クライアント証明書作成部2133は、作成されたクライアント証明書を送信部2134に出力する。
送信部2134は、クライアント証明書を外部サーバ9へ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、クライアント証明書が外部サーバ9に送信される。
図8は、受信したトランザクションデータを実行するための制御装置21の機能ブロック図である。図8を参照して、制御装置21は、トランザクションデータ取得部2141と、署名検証部2142と、レコード作成部2143と、台帳更新部2144と、出力部2145とを含む。制御装置21は、たとえば、ROM22に記憶されたプログラムを実行することにより、トランザクションデータ取得部2141、署名検証部2142、レコード作成部2143、台帳更新部2144、および、出力部2145として機能する。なお、トランザクションデータ取得部2141、署名検証部2142、レコード作成部2143、台帳更新部2144、および、出力部2145は、たとえば、専用のハードウェア(電子回路)により実現されてもよい。
トランザクションデータ取得部2141は、他のクライアントサーバ2から送信されたトランザクションデータを取得する。トランザクションデータ取得部2141は、取得されたトランザクションデータを署名検証部2142に出力する。
署名検証部2142は、トランザクションデータに含まれる電子署名(Sig)の有効性を検証する。まず、署名検証部2142は、トランザクションデータに含まれる送信者情報に基づいて、当該トランザクションデータの送信元のクライアントサーバ2を特定する。そして、署名検証部2142は、特定されたクライアントサーバ2の公開鍵(複数の公開鍵272のうちの1つ)を記憶装置27から読み出す。署名検証部2142は、読み出された公開鍵を用いて、トランザクションデータに含まれる電子署名を復号する。上述のとおり、電子署名は、対象データのハッシュ値またはタイムスタンプトークンが、送信元のクライアントサーバ2の秘密鍵を用いて暗号化されたものである。署名検証部2142は、復号した値と、トランザクションデータに含まれているObj-HV(ハッシュ値またはタイムスタンプトークン)とを比較する。両者が一致することを確認することにより、署名検証部2142は、電子署名の有効性を認める。
レコード作成部2143は、電子署名の有効性が認められた場合に、トランザクションデータに基づいて、分散型台帳セット50に追加するレコードを作成する。レコード作成部2143は、トランザクションデータから、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HV、および、HVの情報を読み出して、これらの情報を含むレコードを作成する。
台帳更新部2144は、レコード作成部2143により作成されたレコードを分散型台帳セット50に追加し、分散型台帳セット50を更新する。具体的には、台帳更新部2144は、作成されたレコードのKeyを参照し、当該レコードを追加する分散型台帳を特定する。たとえば、上述した、対象データを登録/更新する第1操作に応じて生成されたトランザクションデータは、「k1」をKeyとして有している。よって、台帳更新部2144は、当該レコードを、対象データの証拠チェーンである分散型台帳51に追加する。また、分散型台帳51の終端レコードに対するタイムスタンプトークンを取得するための第2操作、および、分散型台帳52の終端レコードに対するタイムスタンプトークンを取得するための第3操作に応じて生成されたトランザクションデータは、「k2」をKeyとして有している。よって、台帳更新部2144は、当該レコードを、タイムスタンプトークンの証拠チェーンである分散型台帳52に追加する。
台帳更新部2144は、分散型台帳セット50の更新が完了すると、その旨を出力部2145に出力する。
出力部2145は、トランザクションデータを実行する処理(トランザクション処理)が完了したことを、トランザクションデータの送信元のクライアントサーバ2に送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクション処理の完了の報告が、トランザクションデータの送信元のクライアントサーバ2に送信される。
<フローチャート>
図9は、第1要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図9に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第1要求を受けた際に、制御装置21によって実行される。なお、図9および後述する図10,11,12,13に示すフローチャートの各ステップ(以下ステップを「S」と略す)は、制御装置21によるソフトウェア処理によって実現される場合について説明するが、その一部あるいは全部が制御装置21内に作製されたハードウェア(電子回路)によって実現されてもよい。
図9は、第1要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図9に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第1要求を受けた際に、制御装置21によって実行される。なお、図9および後述する図10,11,12,13に示すフローチャートの各ステップ(以下ステップを「S」と略す)は、制御装置21によるソフトウェア処理によって実現される場合について説明するが、その一部あるいは全部が制御装置21内に作製されたハードウェア(電子回路)によって実現されてもよい。
S1において、制御装置21は、ナンス値を生成する。このナンス値は、トランザクションデータの番号として用いられる。
S2において、制御装置21は、データベース4から対象データを読み出して対象データのハッシュ値を生成する。
S3において、制御装置21は、記憶装置27から秘密鍵271を読み出し、秘密鍵271を用いて、S2で生成されたハッシュ値を暗号化して電子署名を作成する。なお、制御装置21は、秘密鍵271を用いて、S1で生成されたナンス値を暗号化して電子署名を作成してもよい。また、制御装置21は、秘密鍵271を用いて、S2で生成されたハッシュ値およびS1で生成されたナンス値を暗号化して電子署名を作成してもよい。
S4において、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。具体的には、制御装置21は、第1要求に含まれるID情報M1をKeyとする。また、制御装置21は、S1で生成されたナンス値をNonceとし、S2で生成されたハッシュ値をObj-HVとし、S3で作成された電子署名をSigとする。また、制御装置21は、分散型台帳セット50にKeyを照会させて親レコードのAgeを認識し、親レコードのAgeをインクリメントしたものをAgeとする。また、制御装置21は、親レコードのレコードハッシュをPrev-HVとする。また、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、および、Prev-HVの情報をハッシュ化して、HVとする。また、制御装置21は、トランザクションデータに、当該トランザクションデータをネットワークNWへ向けてブロードキャストする時刻情報、および/または、当該トランザクションデータの送信者情報を含めてもよい。
S5において、制御装置21は、S4で生成されたトランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図10は、第2要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図10に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第2要求を受けた際に、制御装置21によって実行される。なお、制御装置21は、分散型台帳51にレコードが追加されたことを検知した場合に、図10に示すフローチャートの処理を実行してもよい。
S11において、制御装置21は、ナンス値を生成する。このナンス値は、トランザクションデータの番号として用いられる。
S12において、制御装置21は、分散型台帳51の終端レコードのレコードハッシュ値を生成する。
S13において、制御装置21は、S12で生成されたレコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。レコードハッシュ値を受信した時刻認証局8は、レコードハッシュ値の送信元のクライアントサーバ2へタイムスタンプトークンを返信する。制御装置21は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを取得する。
S14において、制御装置21は、記憶装置27から秘密鍵271を読み出し、秘密鍵271を用いて、S13で取得されたタイムスタンプトークンを暗号化して電子署名を作成する。なお、制御装置21は、秘密鍵271を用いて、S11で生成されたナンス値を暗号化して電子署名を作成してもよい。また、制御装置21は、秘密鍵271を用いて、S13で取得されたタイムスタンプトークンおよびS11で生成されたナンス値を暗号化して電子署名を作成してもよい。
S15において、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。制御装置21は、第2要求に含まれるID情報M3(k2)をKeyとする。また、制御装置21は、S13で取得されたタイムスタンプトークンをObj-HVとする。S15における、その他の処理は、図9のS4の処理と基本的に同様であるため、繰り返し説明しない。
S16において、制御装置21は、S15で生成されたトランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図11は、第3要求を受けた場合のトランザクションデータを生成する処理の手順を示すフローチャートである。図11に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第3要求を受けた際に、制御装置21によって実行される。
S21において、制御装置21は、ナンス値を生成する。このナンス値は、トランザクションデータの番号として用いられる。
S22において、制御装置21は、分散型台帳52の終端レコードのレコードハッシュ値を生成する。
S23において、制御装置21は、S22で生成されたレコードハッシュ値を時刻認証局8に送信するための制御信号を、通信装置24に出力する。これにより、通信装置24を介して、時刻認証局8にレコードハッシュ値が送信される。レコードハッシュ値を受信した時刻認証局8は、レコードハッシュ値の送信元のクライアントサーバ2へタイムスタンプトークンを返信する。制御装置21は、通信装置24を介して、時刻認証局8からタイムスタンプトークンを取得する。
S24において、制御装置21は、記憶装置27から秘密鍵271を読み出し、秘密鍵271を用いて、S23で取得されたタイムスタンプトークンを暗号化して電子署名を作成する。なお、制御装置21は、秘密鍵271を用いて、S21で生成されたナンス値を暗号化して電子署名を作成してもよい。また、制御装置21は、秘密鍵271を用いて、S23で取得されたタイムスタンプトークンおよびS21で生成されたナンス値を暗号化して電子署名を作成してもよい。
S25において、制御装置21は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含めたトランザクションデータを生成する。制御装置21は、第3要求に含まれるID情報M5(k2)をKeyとする。また、制御装置21は、S23で取得されたタイムスタンプトークンをObj-HVとする。S25における、その他の処理は、図9のS4の処理と基本的に同様であるため、繰り返し説明しない。
S26において、制御装置21は、S25で生成されたトランザクションデータをネットワークNWへ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、トランザクションデータがネットワークNWに送信される。
図12は、第4要求を受けた場合の処理の手順を示すフローチャートである。図12に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から第4要求を受けた際に、制御装置21によって実行される。
S31において、制御装置21は、分散型台帳52の終端レコードのレコードハッシュ値を生成する。
S32において、制御装置21は、S31で生成されたレコードハッシュ値を含むクライアント証明書を作成する。制御装置21は、クライアント証明書に、自身(A企業)を特定するための情報を含めてもよい。
S33において、制御装置21は、S32で作成されたクライアント証明書を外部サーバ9へ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、クライアント証明書が外部サーバ9に送信される。
図13は、トランザクションデータを受信した場合に実行される処理の手順を示すフローチャートである。図13に示すフローチャートの処理は、トランザクションデータを受信した際に、制御装置21によって実行される。
S41において、制御装置21は、受信したトランザクションデータに含まれる送信者情報に基づいて、当該トランザクションデータの送信元のクライアントサーバ2を特定する。
S42において、制御装置21は、S41で特定されたクライアントサーバ2の公開鍵を記憶装置27から読み出す。
S43において、制御装置21は、S42で読み出された公開鍵を用いて、トランザクションデータに含まれる電子署名を復号する。
S44において、制御装置21は、S43で復号した電子署名の有効性を検証する。具体的には、制御装置21は、電子署名を復号した値と、トランザクションデータに含まれているObj-HV(ハッシュ値またはタイムスタンプトークン)とを比較する。両者が一致しなかった場合には、制御装置21は、電子署名の有効性を認めず(S44においてNO)、処理をS45に進める。両者が一致した場合には、制御装置21は、電子署名の有効性を認め(S44においてYES)、処理をS46に進める。
S45において、制御装置21は、電子署名が有効なものでないため、今回受信したトランザクションデータを破棄し、処理を終了する。なお、制御装置21は、トランザクションデータが改ざんされた可能性がある旨を表示装置26に表示させてもよい。また、制御装置21は、トランザクションデータが改ざんされた可能性がある旨を、トランザクションデータの送信元のクライアントサーバ2に送信してもよい。
S46において、制御装置21は、受信したトランザクションデータからKey、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を読み出して、これらの情報を含むレコードを作成する。
S47において、制御装置21は、S46で作成されたレコードのKeyに基づいて、当該レコードを追加する分散型台帳を特定する。そして、制御装置21は、特定された分散型台帳にレコードを追加する。これにより、分散型台帳セット50が更新される。
S48において、制御装置21は、トランザクション処理が完了したことを示す通知(完了報告)を、トランザクションデータの送信元のクライアントサーバ2に送信する。
以上のように、実施の形態1に係るデータ管理システム1において、クライアントサーバ2は、2つの分散型台帳51,52を含む分散型台帳セット50を保持する。分散型台帳51は、対象データの存在を証明するための証拠チェーンであり、分散型台帳52は、タイムスタンプトークンの存在を証明するための証拠チェーンである。
分散型台帳51には、対象データが更新される毎に、そのハッシュ値を含むレコードが格納される。対象データのハッシュ値を含むレコードが分散型台帳51で管理されるので、対象データの耐改ざん性を高めることができる。また、分散型台帳51に格納されるレコードには、対象データ自体ではなく、対象データのハッシュ値が含まれる。これによって、ネットワークNWを形成する他のクライアントサーバ2に対して、対象データ自体を秘匿しておくことができる。
また、分散型台帳51にレコードが追加され、第2操作が行なわれると、追加されたレコード(分散型台帳51の終端レコード)のレコードハッシュ値に対してタイムスタンプトークンが取得され、当該タイムスタンプトークンを含むレコードが分散型台帳52に格納される。タイムスタンプトークンを分散型台帳52に格納することにより、タイムスタンプトークンの耐改ざん性を高めることができる。そして、タイムスタンプトークンを分散型台帳52に格納していくことにより、有効期限が切れたタイムスタンプトークンがあったとしても、当該タイムスタンプトークンを含むレコードよりも後続のレコードにより、有効期限切れのタイムスタンプトークンが改ざんされていないことを証明することができる。このように、有効期限切れのタイムスタンプトークンの有効性を証明することができるので、タイムスタンプトークンの有効期限を実質的に延長することができる。
さらに、分散型台帳52の終端レコードのレコードハッシュ値に対してタイムスタンプトークンが取得される。これにより、上記レコードハッシュ値の完全性を証明することが可能となるので、当該レコードハッシュ値が改ざんされていないことを証明することにより、分散型台帳52に格納されている一連のタイムスタンプトークンが改ざんされていないことを証明することができる。
さらに、分散型台帳52の終端レコードのレコードハッシュ値に対して取得したタイムスタンプトークンを分散型台帳52に格納することにより、当該タイムスタンプトークンの耐改ざん性を高めることができる。
また、分散型台帳52の終端レコードのレコードハッシュ値を含むクライアント証明書が作成され、当該クライアント証明書がクライアントサーバ2から分離されて、外部サーバ9で管理される。これにより、たとえ分散型台帳セット50の全てのレコードを改ざんされたとしても、外部サーバ9で管理されているクライアント証明書により、分散型台帳セット50が改ざんされたことを証明することができる。
[変形例1]
実施の形態1では、データ管理システム1で管理される部品(車両を構成する部品)が1つである例について説明した。しかしながら、複数の部品がデータ管理システム1で管理されてもよい。たとえば、N(2以上の自然数)個の部品がデータ管理システム1で管理されてもよい。この場合には、分散型台帳セット50は、N個の部品のそれぞれの証拠チェーンとなるN個の分散型台帳と、タイムスタンプトークンの証拠チェーンとなる分散型台帳とを含む。変形例1においても、N個の分散型台帳のうちのいずれかが更新され、第2操作が行なわれると、当該分散型台帳の終端レコードのレコードハッシュ値に対してタイムスタンプトークンが取得され、当該タイムスタンプトークンを含むレコードが、タイムスタンプトークンの証拠チェーンである分散型台帳に格納される。そして、実施の形態1と同様に、第3操作および第4操作に応答することにより、実施の形態1と同様の効果を奏することができる。
実施の形態1では、データ管理システム1で管理される部品(車両を構成する部品)が1つである例について説明した。しかしながら、複数の部品がデータ管理システム1で管理されてもよい。たとえば、N(2以上の自然数)個の部品がデータ管理システム1で管理されてもよい。この場合には、分散型台帳セット50は、N個の部品のそれぞれの証拠チェーンとなるN個の分散型台帳と、タイムスタンプトークンの証拠チェーンとなる分散型台帳とを含む。変形例1においても、N個の分散型台帳のうちのいずれかが更新され、第2操作が行なわれると、当該分散型台帳の終端レコードのレコードハッシュ値に対してタイムスタンプトークンが取得され、当該タイムスタンプトークンを含むレコードが、タイムスタンプトークンの証拠チェーンである分散型台帳に格納される。そして、実施の形態1と同様に、第3操作および第4操作に応答することにより、実施の形態1と同様の効果を奏することができる。
[実施の形態2]
実施の形態1では、プラットフォームサーバ5が、ネットワークNWへの参加を許可する機能を有する例について説明した。そして、トランザクションデータのファイナリティは、ネットワークNWへの参加が許可されたクライアントサーバ2間で電子署名の有効性の確認することにより与えられた。実施の形態2では、プラットフォームサーバ6が、ネットワークNWへの参加を許可する機能に加えて、トランザクションデータにファイナリティを与える機能を有する例について説明する。
実施の形態1では、プラットフォームサーバ5が、ネットワークNWへの参加を許可する機能を有する例について説明した。そして、トランザクションデータのファイナリティは、ネットワークNWへの参加が許可されたクライアントサーバ2間で電子署名の有効性の確認することにより与えられた。実施の形態2では、プラットフォームサーバ6が、ネットワークNWへの参加を許可する機能に加えて、トランザクションデータにファイナリティを与える機能を有する例について説明する。
図14は、実施の形態2に係るデータ管理システム1Aの概略的な構成を示す図である。データ管理システム1Aは、4台のクライアントサーバ3と、プラットフォームサーバ6と、時刻認証局8と、外部サーバ9とを備える。実施の形態1と同様に、4台のクライアントサーバ3の各々は、異なる企業(たとえば、A企業、B企業、C企業およびD企業)に帰属するサーバである。以下においては、A企業のクライアントサーバ3について代表的に説明するが、B企業、C企業およびD企業のクライアントサーバ3も同様の機能を有する。
プラットフォームサーバ6は、実施の形態1に係るプラットフォームサーバ5と同様に、ネットワークNWを管理し、各クライアントサーバ3からのネットワークNWへの参加申請を受け付ける。プラットフォームサーバ6は、プラットフォームサーバ6の管理者による参加を許可する操作に基づき、または、所定の条件の判定結果に基づき、クライアントサーバ3のネットワークNWへの参加を許可する。実施の形態2においても、A企業、B企業、C企業およびD企業のそれぞれに帰属する4台のクライアントサーバ3に対して、ネットワークNWへの参加が許可されている。
4台のクライアントサーバ3およびプラットフォームサーバ6は、ネットワークNWを形成している。クライアントサーバ3の各々には、分散型台帳基盤のソフトウェアが導入されており、導入された分散型台帳基盤のソフトウェアが機能することにより、クライアントサーバ3の各々がノードとして機能する。クライアントサーバ3は、実施の形態1に係るクライアントサーバ2と同様に、ユーザ端末装置7と通信可能に構成されている。
また、クライアントサーバ3には、実施の形態1に係るクライアントサーバ2と同様に、データベース4が接続されている。クライアントサーバ3(制御装置31)は、入力装置35への入力、あるいは、ユーザ端末装置7からの要求に応じて、対象データを登録/更新するための制御信号を生成し、データベース4に出力する。
クライアントサーバ3は、データベース4に部品データを登録/更新すると、当該部品データのハッシュ値を作成し、当該ハッシュ値を、プラットフォームサーバ6に保有される台帳、および、各クライアントサーバ3に保有される分散型台帳(後述のコミットテーブル)に格納するためのトランザクションデータを生成する。そして、クライアントサーバ3は、生成されたトランザクションデータをプラットフォームサーバ6に送信する。
プラットフォームサーバ6は、トランザクションデータにファイナリティを与える機能を有する。プラットフォームサーバ6は、台帳セット60を保有し、クライアントサーバ3から受けるトランザクションデータを処理して、台帳セット60を更新する。プラットフォームサーバ6は、台帳セット60を更新すると、更新により台帳に追加されたレコード(後述のプルーフレコード)を、ネットワークNWに参加する全てのクライアントサーバ3に送信する。クライアントサーバ3はコミットレコードを格納するコミットテーブル374を記憶する。コミットテーブル374は、本開示に係る「分散型台帳」の一例に相当する。
図15は、台帳セット60の構成の一例を示す図である。台帳セット60は、台帳67と、台帳68とを含む。台帳67は、実施の形態1に係る分散型台帳51と同様に、対象データの更新状態を時系列に記憶し、対象データの証拠チェーンを形成する。台帳68は、実施の形態1に係る分散型台帳52と同様に、タイムスタンプトークンを時系列に記憶し、タイムスタンプトークンの証拠チェーンを形成する。台帳セット60、台帳67および台帳68は、実施の形態1に係る分散型台帳セット50、分散型台帳51および分散型台帳52とそれぞれ同様の構成を有する。そのため、これらの詳細な説明は繰り返さない。なお、図15では、図3に示した例に対応する台帳67,68のデータ構造が示されている。すなわち、台帳67,68には、それぞれ、Age「2」のレコードが最新(終端)レコードとして格納されている。
再び図14を参照し、クライアントサーバ3は、制御装置31と、ROM32と、RAM33と、通信装置34と、入力装置35と、表示装置36と、記憶装置37とを備える。制御装置31、ROM32、RAM33、通信装置34、入力装置35、表示装置36、および、記憶装置37は、バス39に接続されている。ROM32、RAM33、通信装置34、入力装置35、および、表示装置36は、基本的に、実施の形態1に係るクライアントサーバ2のROM22、RAM23、通信装置24、入力装置25、および、表示装置26とそれぞれ同様の構成であるため、その説明は繰り返さない。
記憶装置37は、秘密鍵371およびプルーフデータ372を記憶している。秘密鍵371は、A企業の秘密鍵である。たとえば、クライアントサーバ3がネットワークNWに最初に参加するにあたり、制御装置31は、秘密鍵および公開鍵を生成する。そして、制御装置31は、生成された公開鍵を認証局(図示せず)に送信して、認証を受ける。認証局は、公開鍵の情報を含めた電子証明書を発行する。制御装置31は、認証を受けた公開鍵に対応する秘密鍵371を記憶装置37に記憶させる。また、制御装置31は、認証を受けた公開鍵(電子証明書)651を、プラットフォームサーバ6に送信する。
プルーフデータ372は、サスペンションテーブル373と、コミットテーブル374とを含む。図16は、サスペンションテーブル373の構成の一例を説明するための図である。図17は、コミットテーブル374の構成の一例を説明するための図である。サスペンションテーブル373およびコミットテーブル374は、台帳セット60に対応した構成を有する。
図16を参照し、サスペンションテーブル373は、未使用のトランザクションデータに含まれる所定種類の情報を含む。具体的には、サスペンションテーブル373は、たとえば、KeyおよびNonceの情報を含んだサスペンションレコードを記憶する。制御装置31は、各種要求(第1要求~第3要求)に応答して生成されるトランザクションデータに含まれる情報のうちの、KeyおよびNonceの情報をサスペンションレコードとして、サスペンションテーブル373に格納する。なお、以下では、第1要求~第3要求を特に区別しない場合には、第1要求~第3要求を総称して「更新要求」とも称する。
入力装置35あるいはユーザ端末装置7からクライアントサーバ3が受ける更新要求には、レコードを追加する対象となる分散型台帳を特定するためのIDの情報が含まれている。たとえば、第1要求には「k1」を示すID情報M1が含まれている。第2要求には「k2」を示すID情報M3が含まれている。第3要求には「k2」を示すID情報M5が含まれている。すなわち、更新要求に含まれている、レコードを追加する対象となる分散型台帳を特定するためのIDがKeyとなる。また、更新要求を受けると制御装置31は、ナンス値を生成する。当該ナンス値は、更新要求の番号(すなわち、トランザクションデータの番号)を表わす。制御装置31は、KeyおよびNonceの情報を含むサスペンションレコードを作成し、当該サスペンションレコードをサスペンションテーブル373に登録する。図16には、サスペンションテーブル373に、k1のKeyを含むサスペンションレコードが登録されている例が示されている。
更新要求に応答する処理が実行されると(すなわち、トランザクションデータが使用されると)、制御装置31は、トランザクション処理の実行に使用されたトランザクションデータに含まれるKeyと同様のKeyの情報を含むサスペンションレコードを、サスペンションテーブル373から削除する。
サスペンションテーブル373には、同じKeyの情報を含むサスペンションレコードが重複して登録されない。サスペンションレコードをサスペンションテーブル373に登録するにあたり、制御装置31は、登録対象のサスペンションレコードに含まれるKeyと一致するKeyを含んだサスペンションレコードが既にサスペンションテーブル373に登録されているか否かを判断する。制御装置31は、登録対象のサスペンションレコードが含むKeyと一致するKeyを含んだサスペンションレコードがサスペンションテーブル373に登録されていなければ、サスペンションレコードをサスペンションテーブル373に登録する。制御装置31は、登録対象のサスペンションレコードが含むKeyと一致するKeyを含んだサスペンションレコードがサスペンションテーブル373に登録されていれば、一致するKeyを含んだサスペンションレコードがサスペンションテーブル373から削除されるのを待つ。つまり、図16に示す例においては、サスペンションテーブル373に、k2のKeyを含むサスペンションレコードは登録できるが、k1のKeyを含むサスペンションレコードは登録できない。
図17を参照して、コミットテーブル374は、使用済みのトランザクションデータに含まれる所定種類の情報を含む。具体的には、コミットテーブル374は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含むコミットレコードを記憶する。実施の形態2では、コミットレコードは、台帳セット60のレコードと同様の情報を有する。コミットテーブル374は、k1のKeyを有するコミットレコードを格納するコミットデータ375と、k2のKeyを有するコミットレコードを格納するコミットデータ376とを含む。
プラットフォームサーバ6は、トランザクション処理を実行して、台帳セット60の台帳を更新すると、プルーフレコードを作成し、当該プルーフレコードをネットワークNWに参加する全てのクライアントサーバ3に送信する。プルーフレコードは、たとえば、トランザクションデータを使用して実行されたトランザクション処理により台帳に追加されたレコードが有するKey、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含んで構成されたレコードである。
プルーフレコードを受けると、制御装置31は、当該プルーフレコードをコミットレコードとして、コミットテーブル374(コミットデータ375またはコミットデータ376)に追加する。そして、制御装置31は、追加したコミットレコードに含まれるKeyと同様のKeyを含むサスペンションレコードを、サスペンションテーブル373から削除する。
再び図14を参照して、プラットフォームサーバ6は、制御装置61と、ROM62と、RAM63と、通信装置64と、記憶装置65とを備える。制御装置61、ROM62、RAM63、通信装置64、および、記憶装置65は、バス69に接続されている。
制御装置61は、CPUを含む集積回路によって構成される。制御装置61は、ROM62に格納されている各種プログラムをRAM63に展開して実行する。各種プログラムには、オペレーティングシステム等が含まれる。RAM63は、ワーキングメモリとして機能し、各種プログラムの実行に必要な各種データを一時的に格納する。制御装置61は、クライアントサーバ3からトランザクションデータを受信し、トランザクション処理を実行する。
通信装置64は、ネットワークNWに参加しているクライアントサーバ3との通信が可能に構成される。
記憶装置65は、複数の公開鍵651および台帳セット60を記憶している。複数の公開鍵651は、ネットワークNWに参加しているクライアントサーバ3を管理する企業の公開鍵を含む。具体的には、複数の公開鍵651は、A企業の公開鍵、B企業の公開鍵、C企業の公開鍵およびD企業の公開鍵を含む。
台帳セット60は、上述のとおり、実施の形態1に係る分散型台帳セット50と同様の構成を有するため、繰り返し説明しない。
以下、フローチャートを示しながら、実施の形態2における更新要求への応答の処理について順に説明する。
図18は、更新要求を受けた場合にデータ管理システム1Aで実行される処理の手順を示すフローチャートである。図18に示すフローチャートの処理は、入力装置25あるいはユーザ端末装置7から更新要求を受けた際に、クライアントサーバ3の制御装置31によって開始される。
S50において、クライアントサーバ3の制御装置31は、ナンス値を生成する。このナンス値は、更新要求に応じて生成されるトランザクションデータの番号として用いられる。
S51において、クライアントサーバ3の制御装置31は、サスペンションレコードを生成する。具体的には、クライアントサーバ3の制御装置31は、更新要求に含まれているレコードの追加対象となる分散型台帳のIDを読み出してKeyの情報とし、S50で生成されたナンス値をNonceの情報として、サスペンションレコードを生成する。
S52において、クライアントサーバ3の制御装置31は、S51で生成されたサスペンションレコードをサスペンションテーブル373に登録できるか否かを判断する。S51で生成されたサスペンションレコードと同様のKeyの情報を有するサスペンションレコードがサスペンションテーブル373に登録されている場合、クライアントサーバ3の制御装置31は、否定判断をして(S52においてNO)、サスペンションテーブル373から同様のKeyの情報を有するサスペンションレコードが削除されるのを待つ。一方、S51で生成されたサスペンションレコードと同様のKeyの情報を有するサスペンションレコードがサスペンションテーブル373に登録されていない場合、クライアントサーバ3の制御装置31は、肯定判断をして(S52においてYES)、処理をS53に進める。
S53において、クライアントサーバ3の制御装置31は、サスペンションテーブル373にサスペンションレコードを登録する。
S54において、クライアントサーバ3の制御装置31は、更新要求に応じるためのトランザクションデータを生成する。具体的には、クライアントサーバ3の制御装置31は、更新要求が第1要求である場合には、図9において説明したS2~S4の処理と同様の処理を実行してトランザクションデータを生成し、更新要求が第2要求である場合には、図10において説明したS12~S15の処理と同様の処理を実行してトランザクションデータを生成し、更新要求が第3要求である場合には、図11において説明したS22~S25の処理と同様の処理を実行してトランザクションデータを生成する。各処理の詳細については、図9,図10および図11において説明したとおりであるので、繰り返し説明しない。
S55において、クライアントサーバ3の制御装置31は、S54で生成したトランザクションデータをプラットフォームサーバ6に送信するための制御信号を通信装置34に出力する。これにより、通信装置34を介して、トランザクションデータがプラットフォームサーバ6に送信される。
S60において、プラットフォームサーバ6の制御装置61は、受信したトランザクションデータに含まれる電子署名の有効性を検証するために、電子署名を復号する。具体的には、プラットフォームサーバ6の制御装置61は、図13において説明したS41~S43の処理と同様の処理を実行して、電子署名を復号する。各処理の詳細については、図13において説明したとおりであるので、繰り返し説明しない。
S61において、プラットフォームサーバ6の制御装置61は、S60で復号した電子署名の有効性を検証する。具体的には、プラットフォームサーバ6の制御装置61は、電子署名を復号した値と、トランザクションデータに含まれているハッシュ値(第1要求に応じて生成されたトランザクションデータにおいては、対象データのハッシュ値であり、第2要求および第3要求に応じて生成されたトランザクションデータにおいては、タイムスタンプトークンである)とを比較する。両者が一致しなかった場合には、プラットフォームサーバ6の制御装置61は、電子署名の有効性を認めず(S61においてNO)、処理をS62に進める。両者が一致した場合には、プラットフォームサーバ6の制御装置61は、電子署名の有効性を認め(S61においてYES)、処理をS63に進める。
S62において、プラットフォームサーバ6の制御装置61は、クライアントサーバ3から受けたトランザクションデータに改ざんの可能性があると判断して、トランザクションデータを破棄し、改ざんの可能性があることを示す異常報告を作成する。そして、プラットフォームサーバ6の制御装置61は、処理をS66に進める。
S63において、プラットフォームサーバ6の制御装置61は、トランザクション処理を実行する。具体的には、プラットフォームサーバ6の制御装置61は、図13において説明したS46,S47の処理と同様の処理を実行し、トランザクションデータに含まれるKeyの情報により特定される台帳のレコードを生成して、当該台帳に生成されたレコードを追加し、台帳セット60を更新する。
S64において、プラットフォームサーバ6の制御装置61は、プルーフレコードを生成する。プルーフレコードは、台帳に追加されたレコードに含まれるKey、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を含む。
S65において、プラットフォームサーバ6の制御装置61は、台帳セット60の更新が完了したこと(すなわち、トランザクションデータを処理したこと)を示す正常報告を作成する。プラットフォームサーバ6の制御装置61は、正常報告にプルーフレコードを含める。
S66において、プラットフォームサーバ6の制御装置61は、S62において作成された異常報告、または、S65において作成された正常報告をクライアントサーバ3に送信するための制御信号を通信装置64に出力する。これにより、通信装置64を介して、異常報告または正常報告がクライアントサーバ3に送信される。
また、S66において、プラットフォームサーバ6の制御装置61は、プルーフレコードを、トランザクションデータの送信元以外の他のクライアントサーバ3(たとえば、B企業,C企業、D企業のクライアントサーバ3)に送信するための制御信号を通信装置64に出力する。これにより、通信装置64を介して、プルーフレコードが他のクライアントサーバ3に送信される。
S56において、クライアントサーバ3の制御装置31は、プラットフォームサーバ6から正常報告を受信したか否かを判断する。正常報告を受信したと判断すると(S56においてYES)、クライアントサーバ3の制御装置31は、処理をS57に進める。一方、正常報告を受信していない、すなわち異常報告を受信したと判断すると(S56においてNO)、クライアントサーバ3の制御装置31は、処理をS59に進める。
S57において、クライアントサーバ3の制御装置31は、正常報告に含まれるプルーフレコードをコミットレコードとしてコミットテーブル374に追加する。具体的には、クライアントサーバ3の制御装置31は、プルーフレコードのKeyの情報に基づいて、コミットレコードを追加する対象がコミットデータ375であるかコミットデータ376であるかを判断する。そして、クライアントサーバ3の制御装置31は、対象のコミットデータにコミットレコードを追加する。
S58において、クライアントサーバ3の制御装置31は、追加したコミットレコードと同じKeyの情報を有するサスペンションレコードを、サスペンションテーブル373から削除する。
S59において、クライアントサーバ3の制御装置31は、更新要求に対する処理の結果を、たとえば、表示装置36に表示させたり、ユーザ端末装置7に送信したりする。
なお、S66において送信されたプルーフレコードを受信した他のクライアントサーバ3(B企業,C企業、D企業のクライアントサーバ3)も、同様にプルーフレコードをコミットテーブル374に追加することで、コミットテーブル374が更新される。
図19は、実施の形態2において、第4要求を受けた場合の処理の手順を示すフローチャートである。図19に示すフローチャートの処理は、入力装置35あるいはユーザ端末装置7から第4要求を受けた際に、制御装置31によって実行される。
S71において、制御装置31は、コミットデータ376の終端レコードのレコードハッシュ値を生成する。
S72において、制御装置31は、S71で生成されたレコードハッシュ値を含むクライアント証明書を作成する。制御装置31は、クライアント証明書に、自身(A企業)を特定するための情報を含めてもよい。
S73において、制御装置31は、S72で作成されたクライアント証明書を外部サーバ9へ送信するための制御信号を通信装置24に出力する。これにより、通信装置24を介して、クライアント証明書が外部サーバ9に送信される。
以上のように、実施の形態2に係るデータ管理システム1Aにおいては、プラットフォームサーバ6がトランザクションデータにファイナリティを与える。プラットフォームサーバ6は、2つの台帳67,68を含む台帳セット60を保持する。台帳67には、対象データの更新状態が時系列に記憶され、台帳68には、タイムスタンプトークンが時系列に記憶される。そして、台帳セット60が更新されると、台帳セット60に追加されたレコードの情報を有するプルーフレコードがプラットフォームサーバ6から各クライアントサーバ3に送られる。クライアントサーバ3の各々は、プルーフレコードをコミットレコードとして、コミットテーブル374に追加する。コミットテーブル374が実施の形態1に係る分散型台帳セット50に相当する。各クライアントサーバ3がコミットテーブル374を持ち合うことで、コミットテーブル374の耐改ざん性が高められる。
そして、実施の形態2に係るデータ管理システム1Aの構成においても、第2要求に応答して、コミットデータ375(台帳67)の終端レコードのレコードハッシュ値に対してタイムスタンプトークンを取得し、タイムスタンプトークンを含むレコードをコミットデータ376(台帳68)に格納していけば、実施の形態1と同様に、有効期限切れのタイムスタンプトークンの有効性を証明することができる。
さらに、コミットデータ376(台帳68)の終端レコードのレコードハッシュ値に対してタイムスタンプトークを取得することで、上記レコードハッシュ値の完全性を証明することが可能となる。よって、上記レコードハッシュ値が改ざんされていないことを証明することにより、コミットデータ376(台帳68)に格納されている一連のタイムスタンプトークンが改ざんされていないことを証明することができる。
さらに、コミットデータ376(台帳68)の終端レコードのレコードハッシュ値に対して取得したタイムスタンプトークをコミットデータ376(台帳68)に格納することにより、当該タイムスタンプトークンの耐改ざん性を高めることができる。
また、コミットデータ376の終端レコードのレコードハッシュ値を含むクライアント証明書を作成し、当該クライアント証明書をクライアントサーバ3から分離して、外部サーバ9で管理する。これにより、たとえコミットテーブル374および台帳セット60の全てのレコードを改ざんされたとしても、外部サーバ9で管理されているクライアント証明書により、コミットテーブル374および台帳セット60が改ざんされたことを証明することができる。
[変形例2]
実施の形態2では、コミットテーブル374は、台帳セット60に含まれる情報と同様の情報を有する例について説明した。具体的には、コミットテーブル374のコミットデータ375,376の各々は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を有した。コミットテーブル374は、台帳セット60に含まれる情報のうちの一部を有してもよい。たとえば、コミットテーブル374のコミットデータ375,376の各々は、台帳セット60の台帳67,68の各々が有する、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報のうちの、Key、Age、Obj-HV、HV、および、Nonceの情報を含んで構成されてもよい。この場合には、プルーフレコードも、Key、Age、Obj-HV、HV、および、Nonceの情報を含むように生成される。すなわち、コミットデータ375,376は、台帳67,68のサマリとなる。コミットデータ375,376を台帳67,68のサマリとすることによって、コミットデータ375,376と台帳67,68とが同様の情報を有する場合に比べ、クライアントサーバ3の記憶装置37に記憶されるデータ容量を抑制することができる。
実施の形態2では、コミットテーブル374は、台帳セット60に含まれる情報と同様の情報を有する例について説明した。具体的には、コミットテーブル374のコミットデータ375,376の各々は、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報を有した。コミットテーブル374は、台帳セット60に含まれる情報のうちの一部を有してもよい。たとえば、コミットテーブル374のコミットデータ375,376の各々は、台帳セット60の台帳67,68の各々が有する、Key、Age、Obj-HV、Nonce、Sig、Prev-HV、および、HVの情報のうちの、Key、Age、Obj-HV、HV、および、Nonceの情報を含んで構成されてもよい。この場合には、プルーフレコードも、Key、Age、Obj-HV、HV、および、Nonceの情報を含むように生成される。すなわち、コミットデータ375,376は、台帳67,68のサマリとなる。コミットデータ375,376を台帳67,68のサマリとすることによって、コミットデータ375,376と台帳67,68とが同様の情報を有する場合に比べ、クライアントサーバ3の記憶装置37に記憶されるデータ容量を抑制することができる。
今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本開示により示される技術的範囲は、上記した実施の形態の説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
1,1A データ管理システム、2,3 クライアントサーバ、4 データベース、5,6 プラットフォームサーバ、7 ユーザ端末装置、8 時刻認証局、9 外部サーバ、21 制御装置、22 ROM、23 RAM、24 通信装置、25 入力装置、26 表示装置、27 記憶装置、29 バス、31 制御装置、32 ROM、33 RAM、34 通信装置、35 入力装置、36 表示装置、37 記憶装置、39 バス、50 分散型台帳セット、51,52 分散型台帳、60 台帳セット、61 制御装置、62 ROM、63 RAM、64 通信装置、65 記憶装置、67,68 台帳、69 バス、271 秘密鍵、272 複数の公開鍵、371 秘密鍵、372 プルーフデータ、373 サスペンションテーブル、374 コミットテーブル、375,376 コミットデータ、651 複数の公開鍵、2101 情報取得部、2102 ハッシュ生成部、2103 ナンス生成部、2104 電子署名部、2105 トランザクションデータ生成部、2106 トランザクションデータ送信部、2111 情報取得部、2112 レコードハッシュ生成部、2113 ナンス生成部、2114 タイムスタンプトークン取得部、2115 電子署名部、2116 トランザクションデータ生成部、2117 トランザクションデータ送信部、2121 情報取得部、2122 レコードハッシュ生成部、2123 ナンス生成部、2124 タイムスタンプトークン取得部、2125 電子署名部、2126 トランザクションデータ生成部、2127 トランザクションデータ送信部、2131 情報取得部、2132 レコードハッシュ生成部、2133 クライアント証明書作成部、2134 送信部、2141 トランザクションデータ取得部、2142 署名検証部、2143 レコード作成部、2144 台帳更新部、2145 出力部、NW ネットワーク。
Claims (11)
- 分散型台帳技術を用いてデータを管理するデータ管理装置であって、
分散型台帳を記憶する記憶装置と、
前記分散型台帳を更新する制御装置と、
タイムスタンプトークンを付与する時刻認証局と通信可能に構成された通信装置とを備え、
前記分散型台帳は、
前記データに関する情報を含むレコードを時系列に格納する第1分散型台帳と、
前記時刻認証局から取得された前記タイムスタンプトークンを含むレコードを時系列に格納する第2分散型台帳とを含み、
前記制御装置は、
前記通信装置を介して、前記第1分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第1タイムスタンプトークンを前記時刻認証局から取得し、
前記第1タイムスタンプトークンを含むレコードを前記第2分散型台帳に格納する、データ管理装置。 - 前記第1分散型台帳の終端レコードに関する情報は、当該終端レコードのハッシュ値である、請求項1に記載のデータ管理装置。
- 前記制御装置は、前記データ管理装置に対するユーザ操作に応じて、前記第1タイムスタンプトークンを取得する、請求項1または請求項2に記載のデータ管理装置。
- 前記制御装置は、前記第1分散型台帳にレコードが追加された場合に、当該レコードに対する前記第1タイムスタンプトークンを取得する、請求項1または請求項2に記載のデータ管理装置。
- 前記制御装置は、
前記通信装置を介して、前記第2分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第2タイムスタンプトークンを前記時刻認証局から取得し、
前記第2タイムスタンプトークンを含むレコードを前記第2分散型台帳に格納する、請求項1から請求項4のいずれか1項に記載のデータ管理装置。 - 前記制御装置は、前記データ管理装置に対するユーザ操作に応じて、前記第2タイムスタンプトークンを取得する、請求項5に記載のデータ管理装置。
- 前記制御装置は、前記第2タイムスタンプトークンの前回の取得時点から所定時間が経過すると、前記第2タイムスタンプトークンを取得する、請求項5に記載のデータ管理装置。
- 前記通信装置は、さらに、前記データ管理装置とは異なる外部サーバと通信可能に構成され、
前記制御装置は、前記通信装置を介して、所定の時点における前記第2分散型台帳の終端レコードに関する情報を前記外部サーバに送信する、請求項1から請求項7のいずれか1項に記載のデータ管理装置。 - 前記第2分散型台帳の終端レコードに関する情報は、当該終端レコードのハッシュ値である、請求項5から請求項8のいずれか1項に記載のデータ管理装置。
- 分散型台帳技術を用いてデータを管理するデータ管理装置を用いたデータ管理方法であって、
前記データ管理装置は、
分散型台帳を記憶する記憶装置と、
前記分散型台帳を更新する制御装置と、
タイムスタンプトークンを付与する時刻認証局と通信可能に構成された通信装置とを備え、
前記分散型台帳は、
前記データに関する情報を含むレコードを時系列に格納する第1分散型台帳と、
前記時刻認証局から取得された前記タイムスタンプトークンを含むレコードを時系列に格納する第2分散型台帳とを含み、
前記データ管理方法は、
前記通信装置を介して、前記第1分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第1タイムスタンプトークンを前記時刻認証局から取得するステップと、
前記第1タイムスタンプトークンを含むレコードを前記第2分散型台帳に格納するステップとを含む、データ管理方法。 - 前記通信装置を介して、前記第2分散型台帳の終端レコードに関する情報に対するタイムスタンプトークンである第2タイムスタンプトークンを前記時刻認証局から取得するステップと、
前記第2タイムスタンプトークンを含むレコードを前記第2分散型台帳に格納するステップとをさらに含む、請求項10に記載のデータ管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2022/039770 WO2024089774A1 (ja) | 2022-10-25 | 2022-10-25 | データ管理装置およびデータ管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2022/039770 WO2024089774A1 (ja) | 2022-10-25 | 2022-10-25 | データ管理装置およびデータ管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2024089774A1 true WO2024089774A1 (ja) | 2024-05-02 |
Family
ID=90830202
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/039770 WO2024089774A1 (ja) | 2022-10-25 | 2022-10-25 | データ管理装置およびデータ管理方法 |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2024089774A1 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017157926A (ja) * | 2016-02-29 | 2017-09-07 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
WO2019228560A2 (en) * | 2019-09-02 | 2019-12-05 | Alibaba Group Holding Limited | Managing blockchain-based centralized ledger systems |
US20200076572A1 (en) * | 2018-08-30 | 2020-03-05 | International Business Machines Corporation | Guarantee of ledger immutability |
-
2022
- 2022-10-25 WO PCT/JP2022/039770 patent/WO2024089774A1/ja unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017157926A (ja) * | 2016-02-29 | 2017-09-07 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
US20200076572A1 (en) * | 2018-08-30 | 2020-03-05 | International Business Machines Corporation | Guarantee of ledger immutability |
WO2019228560A2 (en) * | 2019-09-02 | 2019-12-05 | Alibaba Group Holding Limited | Managing blockchain-based centralized ledger systems |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Huang et al. | Towards secure industrial IoT: Blockchain system with credit-based consensus mechanism | |
US11232478B2 (en) | Methods and system for collecting statistics against distributed private data | |
Syta et al. | Keeping authorities" honest or bust" with decentralized witness cosigning | |
CN111314067B (zh) | 区块存储方法、装置、计算机设备及存储介质 | |
WO2021233049A1 (zh) | 基于区块链的数据处理方法、装置、设备及可读存储介质 | |
CN108933667B (zh) | 一种基于区块链的公钥证书的管理方法及管理系统 | |
WO2018203817A1 (en) | Method and system for registering digital documents | |
US20010032314A1 (en) | Method and apparatus for validating a digital signature | |
CN110489946B (zh) | 基于区块链的版权认证方法、装置、设备和存储介质 | |
JP7426402B2 (ja) | スマートコントラクトでidベースのキー管理を実現する方法および装置 | |
CN110855445B (zh) | 一种基于区块链的证书管理方法、装置及存储设备 | |
CN101395599A (zh) | 电子签名的生成 | |
CN112075062A (zh) | 区块链网络中的自动提交交易管理 | |
Wan et al. | Electronic contract signing without using trusted third party | |
US10681035B1 (en) | Cryptographic services engine | |
CN115605868A (zh) | 跨网身份提供 | |
CN114679319A (zh) | 基于区块链的分布式数据同步加密方法 | |
US20050235140A1 (en) | System and method for secure preservation and long term archival of electronic documents | |
US20220329653A1 (en) | Blockchain declarative descriptor for cross-network communication | |
JP7564071B2 (ja) | データ管理装置およびデータ管理方法 | |
WO2024089774A1 (ja) | データ管理装置およびデータ管理方法 | |
CN116112506A (zh) | 基于联盟链系统的交易信息处理方法、装置、介质及设备 | |
US20130268764A1 (en) | Data event authentication and verification system | |
WO2024089775A1 (ja) | データ管理装置およびデータ管理方法 | |
JP7525455B2 (ja) | データ管理装置およびデータ管理方法 |
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: 22963426 Country of ref document: EP Kind code of ref document: A1 |