Data Management System

Abstract

This makes it possible to guarantee the authenticity of data generated on the network without using blockchain. [Solution] The client device 200 is assigned an individual number, a private key, and a public key, and generates evidence data for the data from the individual number, raw data, index data, and evidence data of the previous data, and signs the evidence data with the private key. The data server 300 receives the individual number, index data, raw data, and signature data from the client device 200, generates data corresponding to the evidence data from the previous evidence data, individual number, index data, and raw data, and further decrypts the signature data with the public key to restore the evidence data, verifies the evidence data, and registers the data based on successful verification.

Description

[Technical Field]

[0001] The present invention relates to a data management technique that can guarantee the authenticity of data exchanged over a communication network, such as the Internet. [Background technology]

[0002] Addressing data security is important in communication networks. The recent spread of IoT (Internet of Things) networks has brought about improved convenience, but at the same time has given rise to social issues related to data security. For example, these include "eavesdropping," in which data that should not be visible is intercepted, and "tampering," in which the contents of data are illegally altered.

[0003] To solve these social problems, secure data handling methods have been proposed (for example, Non-Patent Document 1). Non-Patent Document 1 proposes that when tracking the robotically automated logistics of large quantities of goods, inexpensive passive RFID tags are used for cost reasons, and that an RFID reader equipped with digital signature, location constraint, and tamper-proof functions reads and writes to the tags and also atomically writes evidence to the blockchain.

[0004] However, these proposed methods have had problems such as high costs due to the use of public blockchains to prevent data tampering, and they do not provide users with a sufficient method to verify the authenticity of the data, making it difficult to gain trust.

[0005] Patent Document 1 also discloses a system that includes an IoT sensor that measures the internal temperature and humidity of a wine brewing storage facility, a database that records winery information, wine ingredient information, and measurement data sent from the IoT sensor, and an AI that analyzes the ingredient information and measurement data recorded in the database to evaluate the quality of the wine, and hashes the winery information, ingredient information, measurement data, and AI evaluation result information and records them on a blockchain.This system also has the constraint of using a blockchain.

[0006] It should be noted that the above-mentioned prior art and its problems are described only to explain part of the background of the present invention, and that the present invention is not limited to the above-mentioned prior art and problems. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Laid-Open No. 2024-104794 [Non-patent literature]

[0008] [Non-Patent Document 1] Hiroshi Watanabe et. al, "Proof of Authenticity of Logistics Information with Passive RFID Tags and Blockchain", 2021 International Conference on Electronic Communications, Internet of Things and Big Data (ICEIB), 2021 DOI: 10.1109 / ICEIB53692.2021.9686409 Summary of the Invention [Problem to be solved by the invention]

[0009] This invention was made in consideration of the above circumstances, and aims to provide a data management technology that ensures the authenticity of data generated and stored on a communication network without using a blockchain. [Means for solving the problem]

[0010] In order to achieve the above object, the present invention employs the configurations set forth in the claims. Before describing the invention in detail, a supplementary explanation will be given below regarding the claims.

[0011] That is, according to one aspect of the present invention, in order to achieve the above-mentioned object, there is provided a data management system comprising a client device which sequentially generates or receives data to be stored, and a data storage device which stores the data to be stored provided by the client device, connected via a communication network, wherein: client device identification information for uniquely identifying the client device and a private key associated with the client device are assigned to the client device; the client device comprises: evidence data generation means which, for each of the data to be stored which is sequentially generated or received, applies a predetermined hash function to first integrated data which is formed by integrating at least the client device identification information, unique index data which is individually assigned to each of the data to be stored, the data to be stored, and preceding data as elements, to generate a hash value as evidence data, and the evidence data generation means, wherein for data to be stored that is generated or received thereafter, the preceding data is predetermined start data, and for data to be stored that is generated or received thereafter, the preceding information is the evidence data generated immediately before by the evidence data generation means; signature data generation means, which generates signature data for the evidence data generated by the evidence data generation means using the private key; and for each piece of data to be stored that is generated or received sequentially, supplies the client device identification information, the index data, the data to be stored, and the signature data of the evidence data to the data storage device; the data storage device, which: has storage means used to store the client device identification information, the index information, the data to be stored, the evidence data, and the signature data of the evidence data for each piece of data to be stored that is generated or received sequentially in the client device;a verification data generation means for receiving, for each piece of storage target data sequentially generated or received by the client device, the client device identification information, the storage target data, the signature data of the evidence data, and unique index data individually assigned to each piece of storage target data, which are supplied from the client device; and further, except for the case of the first generated or received storage target data, extracting from the storage means the evidence data generated for the previous storage target data based on the index data assigned to the previous storage target data; and generating, as verification data, a hash value using a hash function corresponding to the predetermined hash function on second integrated data obtained by integrating at least the evidence data generated for the previous storage target data, the client device identification information, the index data, and the storage target data as elements, wherein, for the first generated or received storage target data, the verification data generation means using the predetermined start data instead of the public key; evidence data restoration means restoring the evidence data from the signature data of the evidence data using a public key associated with the client device; and storage management means comparing the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, and verifying, based on the comparison result, whether the client device identification information, the storage target data, and the signature data of the evidence data supplied from the client device, and unique index data individually assigned to each piece of storage target data, are authentic, and storing and managing, in the storage means, the client device identification information, the storage target data, the signature data of the evidence data, and corresponding evidence data supplied from the client device, and unique index information individually assigned to each piece of storage target data, as authentic data, based on the verification result.

[0012] In this configuration, the authenticity of data generated and stored on a communication network can be easily guaranteed without using a blockchain.

[0013] In this configuration, the client device may generate the index data and provide it to the data storage device.

[0014] In this configuration, the data storage device may generate the index data and provide it to the client device.

[0015] In this configuration, the data storage device may store data in a key-value format.

[0016] In this configuration, the key data may be generated from the index data and the signature data, and the key data of the data to be stored, the evidence data, the client identification information, and the previous data may be used as the value data.

[0017] In this configuration, the data management system may further include a data verification device connected to the data storage device via the communication network and configured to verify the authenticity of the data stored in the data storage device, wherein the data verification device may: receive the evidence data of the block immediately before the verification target range, the client identification information, the index data, and the storage target data of the blocks within the verification target range, as well as the signature data of the final block of the verification target range, and a public key corresponding to the private key; and for each block in the verification target range, apply a predetermined hash function to third integrated information formed by integrating, in order from the preceding block, the starting data or the evidence data immediately before the block, and the client identification information, the index data, and the storage target data of the block as elements, to generate a hash value as the evidence data of the block; further decrypt the evidence data generated for the final block from the signature data of the final block using the public key; and compare the evidence data generated by the hash function with the evidence data decrypted using the public key to determine the authenticity of the data of the block in the verification target range.

[0018] In this configuration, in addition to the data storage device, there is a data disclosure device, and the data disclosure device stores data in a key-value format, generates key data from the index data and the signature data, and may use the key data of the data to be stored, the evidence data, the client identification information, and the previous data as value data.

[0019] In this configuration, the client device may be associated with a certification authority, and the data to be stored may be a registered business description of the certification authority.

[0020] In this configuration, in addition to the data storage device, there is a data disclosure device, and the data disclosure device stores data in a key-value format, generates key data from the client identification information, the index data, and the signature data, and may use the key data of the data to be stored, the evidence data, and the previous data as value data.

[0021] In this configuration, the client device is a device used in connection with transporting luggage, and the data to be stored may include a transport history.

[0022] In this configuration, the device may be provided with an RF-ID reader / writer, and may read and register data using the RF-ID reader / writer.

[0023] In this configuration, the device may be a shipping box.

[0024] In this configuration, the data to be stored may be BOM (Bill Of Materials) data. In this configuration, the data to be stored may be SBOM (Software Bill of Materials) data.

[0025] According to another aspect of the present invention, there is provided a data management system including a client device that sequentially generates or receives data to be stored, and a data storage device that stores the data to be stored provided by the client device, connected via a communication network, wherein: client device identification information for uniquely identifying the client device and a private key associated with the client device are assigned to the client device; the client device is: evidence data generation means that, for each of the data to be stored that is sequentially generated or received, applies a predetermined hash function to first integrated data that is formed by integrating at least the client device identification information, unique index data that is individually assigned to each of the data to be stored, the data to be stored, and preceding data as elements, to generate a hash value as evidence data, and the hash value is generated as evidence data for the data to be stored that is first generated or received by applying a predetermined hash function to the preceding data. the evidence data generation means, wherein the preceding data is predetermined start data, and for data to be stored that is generated or received thereafter, the preceding information is the evidence data that was generated immediately before by the evidence data generation means; signature data generation means, which generates signature data for the evidence data generated by the evidence data generation means using the private key; and supplies the client device identification information, the index data, the data to be stored, and the signature data of the evidence data to the data storage device for each of the data to be stored that is generated or received sequentially; the data storage device has storage means for storing the client device identification information, the index information, the data to be stored, the evidence data, and the signature data of the evidence data for each of the data to be stored that is generated or received sequentially in the client device.

[0026] Even with this configuration, the authenticity of data generated and stored on the communication network can be easily guaranteed without using a blockchain.

[0027] According to another aspect of the present invention, there is provided a data management system including a client device that sequentially generates or receives data to be stored, and a data storage device that stores the data to be stored provided by the client device, connected via a communication network, the client device being assigned client device identification information for uniquely identifying the client device and a private key associated with the client device; the client device having: evidence data generation means that, for each of the data to be stored that is sequentially generated or received, generates a hash value as evidence data by applying a predetermined hash function to first integrated data that is formed by integrating at least the client device identification information, unique index data individually assigned to each of the data to be stored, and the data to be stored; and signature data generation means that generates signature data for the evidence data generated by the evidence data generation means using the private key; and the data storage device is provided with: a storage means for storing the client device identification information, the index data, the storage target data, and the signature data of the evidence data for each piece of storage target data sequentially generated or received by the client device; and a verification data generation means for receiving the client device identification information, the storage target data, and the signature data of the evidence data, as well as unique index data individually assigned to each piece of storage target data, supplied from the client device for each piece of storage target data sequentially generated or received by the client device, and for generating a hash value as verification data by using a hash function corresponding to the predetermined hash function on second integrated data formed by integrating the client device identification information, the index data, and the storage target data as elements;the client device includes: evidence data restoration means for restoring the evidence data from the signature data of the evidence data by using a public key associated with the client device; and storage management means for comparing the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, and verifying, based on the comparison result, whether the client device identification information, the storage target data, and the signature data of the evidence data supplied from the client device, as well as the unique index data individually assigned to each piece of storage target data, are authentic, and, based on the verification result, storing and managing the client device identification information, the storage target data, the signature data of the evidence data, and the corresponding evidence data supplied from the client device, as well as the unique index information individually assigned to each piece of storage target data, in the storage means as authentic data;

[0028] Even with this configuration, the authenticity of data generated and stored on the communication network can be easily guaranteed without using a blockchain.

[0029] This invention can be realized not only as an apparatus or system but also as a method. It goes without saying that a part of such an invention can be configured as software. Furthermore, software products used to run such software on a computer are also naturally included in the technical scope of this invention.

[0030] These and other aspects of the present invention are set forth in the appended claims and are further illustrated by the following examples. [Effects of the Invention]

[0031] According to this invention, the authenticity of data generated and stored on a communication network can be easily guaranteed without using a blockchain. [Brief explanation of the drawings]

[0032] [Figure 1] 1 is a diagram illustrating an example of a usage environment of a data management system 100 according to a first embodiment of the present invention. [Figure 2] FIG. 1 is a block diagram illustrating a schematic configuration example of a client device 200 of a data management system 100 according to a first embodiment of the present invention. [Figure 3] FIG. 1 is a block diagram illustrating a schematic configuration example of a data server 300 of a data management system 100 according to a first embodiment of the present invention. [Figure 4] 1 is a block diagram illustrating a schematic configuration example of a verification device 400 of a data management system 100 according to a first embodiment of the present invention. [Figure 5] 4 is a flowchart illustrating an example of the operation of the client device 200 of the data management system 100 according to the first embodiment of the present invention. [Figure 6] 4 is a flowchart illustrating an example of the operation of the data server 300 of the data management system 100 according to the first embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating an example of the operation of the verification device 400 of the data management system 100 according to the first embodiment of the present invention. [Figure 8] FIG. 1 is a diagram illustrating computer resources of a client device 200, a data server 300, and a verification device 400 of a data management system 100 according to a first embodiment of the present invention. [Figure 9] FIG. 2 is a diagram illustrating an example of identification codes and data in the data management system 100 according to the first embodiment of the present invention. [Figure 10] 3A and 3B are diagrams illustrating an example of generation of evidence data and signature data in a client device 200 of a data management system 100 according to a first embodiment of the present invention. [Figure 11] FIG. 2 is a diagram illustrating an example of a method for registering data in a database 300 of a data management system 100 according to a first embodiment of the present invention. [Figure 12]FIG. 2 is a diagram illustrating an example of verification of data authenticity in a verification device 400 of the data management system 100 according to the first embodiment of the present invention. [Figure 13] FIG. 10 is a diagram illustrating a modified example in which a public evidence server is added to the first embodiment of the present invention. [Figure 14] FIG. 14 is a diagram showing an example in which the modified example shown in FIG. 13 is used to disclose a registered business certificate. [Figure 15] FIG. 10 is a diagram illustrating a second embodiment of the present invention in which the present invention is applied to the management of various data including transportation history when a logistics company transports luggage. [Figure 16] FIG. 10 is a diagram illustrating an example of data registration in a second embodiment of the present invention. [Figure 17] FIG. 10 is a diagram illustrating a modified example of the second embodiment of the present invention. [Figure 18] FIG. 10 is a diagram illustrating an example of data registration in a modified example of the second embodiment of the present invention. [Figure 19] FIG. 10 is a diagram illustrating a third embodiment of the present invention. [Figure 20] FIG. 10 is a diagram illustrating a third embodiment of the present invention. [Figure 21] FIG. 10 is a diagram illustrating a fourth embodiment of the present invention. [Figure 22] FIG. 10 is a diagram illustrating a fourth embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0033] An embodiment of the present invention will now be described.

[0034] [First Example] First, a data management system 100 according to a first embodiment will be described. FIG. 1 shows the entire data management system 100 according to the first embodiment of the present invention. In FIG. 1, a client device 200 and a data server 300 are connected via a communication network 500 (e.g., an IP network). A verification device 400 may also be connected to the communication network 500. The client device 200 may have the functions of the verification device 400. Although only one client device 200 and one verification device 400 are shown, there may be multiple client devices 200 and multiple verification devices 400. A plurality of data servers 300 may also be provided, for example, depending on the services to be provided.

[0035] 2, the client device 200 may include a raw data generation unit 201 that generates or receives raw data, an index data generation unit 202 that generates index data, an evidence data generation unit 203 that generates evidence data, a signature data generation unit 204 that generates signature data, and a transmission / reception unit 205 that transmits and receives information such as various data. The client device 200 is assigned an identification code A (uniform number), an identification code B (private key), and an identification code C (public key). The client device 200 may generate index data (data A), data B (raw data), data C (evidence data), and data D (signature data). The identification code A (uniform number), identification code B (private key), and identification code C (public key), as well as the index data (data A), data B (raw data), data C (evidence data), and data D (signature data), will be described later with reference to, for example, FIGS. 9 to 12.

[0036] 3, the data server 300 may include a database 301, a verification data generation unit 302, an evidence data restoration unit 303, a data registration management unit 304, and a transmission / reception unit 305 that transmits and receives information such as various data. As will be described later, the database 301 registers index data (data A), raw data (data B), evidence data (data C), signature data (data D), and an individual number (identification code A) as one data block.

[0037] As shown in FIG. 4, the verification device 400 may include an evidence data generation unit 401, an evidence data restoration unit 402, a verification unit 403, and a transmission / reception unit 404 that transmits and receives information such as various data.

[0038] The client device 200, the data server 300, and the verification device 400 may operate according to the operation examples shown in Figures 5, 6, and 7, respectively. Details of the operation examples will be further described later with reference to Figures 10 to 12, etc.

[0039] An example of the operation of the client device 200 (FIG. 5) is as follows. [Step S10]: Generate or receive raw data (data B). [Step S11]: Generate index data (data A). [Step S12]: Evidence data (data C) is generated from the individual number (identification code A), index data (data A), raw data (data B), and the evidence data generated previously (data C'; the first data is a predetermined initial value). [Step S13]: Signature data (data D) is generated from the evidence data (data C) using the encryption key (identification code B). [Step S14]: Send the individual number (identification code A), public key (identification code C), index data (data A), the previously used index data (data A), raw data (data B), and signature data (data D) to the data server 300.

[0040] An example of the operation of the data server 300 (FIG. 6) is as follows. [Step S20]: Receive from client device 200 the individual number (identification code A), public key (identification code C), index data (data A), raw data (data B), signature data (data D), and previously used index data (data A'). [Step S21]: Based on the previously used index data (data A'), the previously generated evidence data (data C) is extracted, and evidence data is generated from the identification code A (individual number), index data (data A), raw data (data B), and the previously generated evidence data (hash value N1, see Figure 11). [Step S22]: The signature data is decrypted using the public key (identification code C) to restore the evidence data (hash value N2, see FIG. 11). [Step S23]: Compare and verify the evidence data (N1, N2) obtained in steps S21 and S22. If the verification is successful, the data is registered.

[0041] An example of the operation of the verification device 400 (FIG. 7) is as follows. [Step S30]: Receive the individual number (identification code A) of the range to be verified, the index data (data A), and the raw data (data B), as well as the evidence data (data C') of the block immediately before the range to be verified, and the public key (identification code C) and signature data (data D) corresponding to the individual number (identification code A) of the final block. Step S31: For each block N within the range to be verified, the evidence data (data C') in the immediately preceding block N-1, the individual number (identification code A), index data (data A), and raw data (data B) of that block N are processed according to the first algorithm to generate a hash value N1 (data that should be equal to data C (evidence data) in block N in Figure 12). [Step S32]: Determine whether the processed block is the last block. If it is the last block, proceed to S34; if not, proceed to step S33. [Step S33]: N is incremented by 1, the next block is processed, and the process returns to block S31 to repeat the process. [Step S34]: The signature data (data D) in the final block is decrypted by the signature verification function in the second algorithm using the public key (identification code C) to obtain a hash value N2 (FIG. 12). [Step S35]: If the hash value N1 and the hash value N2 match, it can be verified that the data in the block within the verification range is definitely the same as that registered by the client device 200 (Step S36). If not, it is determined to be inauthentic (Step S37). In the example of FIG. 12, the number N of the last block is 3.

[0042] 8 shows a schematic configuration example of a computer constituting the client device 200, the data server 300, or the verification device 400, but is not limited to this. In FIG. 8, a computer 1000 includes a CPU (processor) 1001, a main memory 1002, an external interface 1003, and an external storage device 1004, and the operation of the client device 200, the data server 300, or the verification device 400 can be realized by installing an application 1005 on this computer 1000. The client device 200, the data server 300, or the verification device 400 may be configured in a distributed manner across multiple computers.

[0043] Next, the data management system 100 according to the first embodiment will be described in detail.

[0044] 9 explains the identification code and data handled by the data management system 100. The client device 200 of this data management system 100 has an identification code, generates data, and registers it in the data server 300.

[0045] [Contents of identification code] There are at least three types of identification codes: a unique individual number (identification code A) that is specific to each client device and is made publicly available, a private key (identification code B) that exists only within the client device 200 in principle and is difficult for a third party to read or copy, and a public key (identification code C) that is generated from the identification code B and made publicly available.

[0046] The identification code A may be anything unique within the system, such as the device name or MAC address of the client device 200, but is not limited to these.

[0047] Furthermore, the identification code C (public key) is generated in pair from the identification code B (private key) using a key generation algorithm such as RSA, ECDSA, EdDSA, etc., but the key generation algorithm is not limited to these. The identification code C may be registered in advance in the data server 1 in association with the identification code A, or may be made public on the network in a desired manner.

[0048] In addition, in the database 301 (see FIG. 3) of the data server 300, the data and the identification code are stored together as a data block as shown in FIG. 9. Note that since there may be multiple client devices 200, the identification code A in the data block is not necessarily a single code.

[0049] [Data generation method] The data consists of at least index data (data A), raw data (data B), evidence data (data C), and signature data (data D), which are generated as follows (see FIG. 10).

[0050] Data B (raw data) refers to any data generated by calculation or measurement by the client device 200 itself, or input from an external source, such as, but not limited to, timestamps, temperature, humidity, acceleration, opening and closing information of doors and lids, location information measured by GPS, image data or video data captured by a camera or scanned by a scanner, any digital data such as ID numbers or raw material information contained in products, or text data entered by a human.

[0051] Data A (index data) can be any data that corresponds one-to-one with data B (raw data) and is unique within the data server 300, such as, but not limited to, a timestamp, a serial number, or a combination of identification code A (individual number) and a timestamp or serial number. Furthermore, since it is possible that a series of data is written to the same table from different client devices, the client device 200 may not necessarily know data A (index data). In such cases, a mechanism must be provided to notify the client device 1 of data A (index data).

[0052] Data C (evidence data) is generated in the client device 200 in the following procedure (see FIG. 10).

[0053] First, the identification code A (unique number) of the client device 200 that generates and registers data C, data C (evidence data, data C') generated in the previous block, data A (index data) in the current block, and data B (raw data) are converted into binary data according to a predetermined procedure. This is then input into a desired cryptographic hash function such as SHA-1 or SHA-2 to obtain data C (evidence data) (first algorithm). In this case, the predetermined procedure may be, but is not limited to, converting data described in a data format such as ASN.1 (Abstract Syntax Notation One) into binary data using DER (Distinguished Encoding Rules) or serializing the data using protocol buffers.

[0054] In the first block, data C' (evidence data generated in the previous block) does not exist, so the desired start data is used as an input value instead. Specific examples of start data include, but are not limited to, various information about the data table in which a series of data is stored, such as an identifier, a data format, and properties. Furthermore, since it is expected that a series of data will be written to the same table from different client devices 200, the client device 200 may not necessarily know data C'. In such cases, it is necessary to provide a mechanism for notifying the client device 200 of data C'.

[0055] Furthermore, data D (signature data) is generated by signing data C (evidence data) using a signature function in a desired digital signature algorithm (second algorithm) such as RSA, ECDSA, or EdDSA using identification code B (private key).

[0056] [How to register data] The registration format of the database 301 of the data server 300 may be a structured database such as an SQL database, or an unstructured database of the key-value store (KVS) type. However, if raw data (data B) is unstructured, a KVS database is preferable because it is easy to handle unstructured data. For example, if data A (index data) is key data and the other data is value data, it is preferable to use value data that has been converted into binary data according to a predetermined procedure. In this case, the predetermined procedure may be, but is not limited to, converting data described in a data format such as ASN.1 (Abstract Syntax Notation One) into binary data using DER (Distinguished Encoding Rules) or serializing the data using protocol buffers.

[0057] The client device 200 registers the data generated as described above in units of blocks to the data server 300 (see FIG. 9). As shown by the dashed line in FIG. 11, when registering data for an arbitrary block N, the client device 200 receives the identification code A of the block N as an argument. N (Individual number), Identification code C N (public key), data A N (Index Data N), Data B N (Raw data N), Data D N (Signature data N) and data A in the previous block (block N-1) N-1 (index data N-1) is supplied to the data server 300.

[0058] When the data server 300 receives these data, it first checks the data C in the block N-1 corresponding to the index data N-1. Nー1 (Evidence data N-1) is read, and a hash value N1 (which is equal to evidence data N if all arguments are authentic) is obtained using the first algorithm.

[0059] Next, the signature data N (data D N ) is processed by the signature verification function in the second algorithm using the identification code C (public key) to obtain a hash value N2 (which is equal to the evidence data N if the signature data and public key are authentic).

[0060] If the hash value N1 and the hash value N2 match, it can be confirmed that the data was definitely sent from the legitimate client device 1, and the data registration management unit 304 of the data server 300 registers the data as authentic in its own database 301.

[0061] If the identification code C (public key) is registered in the data server 300 itself or is separately published on a network, it may be used without receiving it from the client device 200.

[0062] [Data authenticity verification procedure] A distinctive feature of this embodiment is the ability to verify whether registered data has been tampered with or fabricated by a third party. Specifically, it is possible to verify that any data set of data A (index data) and corresponding data B (raw data) disclosed by the data owner has not been tampered with or fabricated by following the procedure below (see Figure 12).

[0063] To verify the authenticity of data, the verifier (verification device 400) is provided with the identification code A (identity number), data A (index data), and data B (raw data) for the range to be verified for authenticity, as well as data C (evidence data) for the block immediately before the range to be verified, and the identification code C (public key) and data D (signature data) corresponding to the identification code A (identity number) for the final block.

[0064] The verifier (verification device 400) first processes data C (evidence data) in the block immediately preceding the verification target range, and the identification code A (identity number), data A (index data), and data B (raw data) of the first block according to the first algorithm, and obtains a hash value of 1. This data should be equal to data C (evidence data) of the first block.

[0065] Next, the hash values ​​are calculated in the same way up to the final block using the disclosed data. In the example of Figure 12, the hash value is calculated up to 31 for block 3.

[0066] Next, data D (signature data 3) in the final block is decrypted by a signature verification function in the second algorithm using the identification code 3 (public key) to obtain a hash value 32. If the hash value 31 and the hash value 32 match, it can be verified that the data in the block to be verified is definitely the same as that registered by the client device 1. In other words, the authenticity of the data can be verified.

[0067] In this case, since there may be multiple client devices, the identification code C (public key) used for verification must correspond to the identification code A (serial number) of the block in question (block 3).

[0068] [Modification of the first embodiment] Next, a modified example of the first embodiment will be described. In this modified example, a data server 300B (FIG. 13) for the purpose of disclosing data is provided in addition to the data server 300A.

[0069] Figure 13 shows a data management system 100A according to a modification of the first embodiment, and in Figure 13, parts corresponding to those in Figure 9 are assigned the same reference numerals. In Figure 13, a data server 300A has the same configuration as the data server 300 in Figure 9, or at least stores pairs of data A (index data) and data D (signature data) for each block.

[0070] Data server 300B is a data server established for the purpose of disclosing data, and may be a key-value database in which a set of data A (index data) and data D (signature data) is used as key data, and data B (raw data), data C (evidence data), identification code A (individual number), and key data from the previous block are used as value data.

[0071] In this modification, it is assumed that only the owner of the data can read data from the data server 300A, that is, the owner of the data treats the data server 300A as a normal database.

[0072] In contrast, it is assumed that data can be read from the data server 300B by anyone who knows the set of key data, i.e., data A (index data) and data D (signature data). In other words, data is basically made public in the data server 300B.

[0073] If data is registered using a method for verifying data authenticity at the time of data registration, and if the user can trust the data server 300B, the fact that the data has been registered can be considered to confirm the authenticity of the data. In other words, the user can omit verifying the authenticity of the data themselves.

[0074] Since it is difficult to guess data D (signature data), by doing this, the data owner can disclose value data including data B (raw data) only to users who have been given the set of data A (index data) and data D (signature data). Furthermore, since part of the value data contains the key data of the previous block, when a user is given the value data of a certain block, it is the same as if the data of all previous blocks had been disclosed.

[0075] Of course, if it is not necessary to make guessing difficult, data D (signature data) may not be included in the key data.

[0076] Furthermore, unnecessary data can be appropriately removed from the value data. In particular, if the key data of the previous block is not included, data before the disclosed block cannot be read.

[0077] When allowing the user to use the public data server 300B, the data owner may provide the user with a ticket instead of directly disclosing the set of data A (index data) and data D (signature data), and a set of data A (index data) and data D (signature data) may be generated in a confidential state based on this ticket, and a series of raw data may be provided. Conditions such as a usage period may be incorporated into this ticket.

[0078] By using this modified example, it is possible to make public a registered business certificate that guarantees the authenticity of data, as shown in FIG.

[0079] Consider a case where there are multiple certification bodies that issue licenses to companies that perform operations that require special handling, such as religious food, and the certification bodies use data server 300B as a database for registering and publishing the licenses.

[0080] Each certification authority has one or more client devices 200, and generates evidence data (data C) based on a data generation method using the device name (identification code A, individual number), license number (data A, index data), license data (data B, raw data), and evidence data (data C') of the previous block. If the client device does not know the evidence data C', it obtains it from the data server 300B.

[0081] Examples of license data include, but are not limited to, company names, website URLs, license numbers, and other text data related to the contents of licenses, as well as non-text data such as image data of licenses. Note that, since handling image data as raw data or parts of raw data is undesirable from the perspective of data size and ease of handling, it is preferable to combine the hash value of the image data or the file ID of cloud storage and use it instead of the image data itself.

[0082] The signature data (data D) is obtained by signing the evidence data (data C) with a signature function in a signature algorithm (second algorithm) using the private key (identification code B) of each client device.

[0083] According to this modification, when a business operator is asked by a third party whether or not it really has the license necessary for the business, it can show the data made public in data server 300B, thereby demonstrating that the data was indeed registered by client device 200 of the certification authority, and that the data has not been tampered with by anyone, including the certification authority, since registration. In other words, the authenticity of the data can be guaranteed.

[0084] It is not necessary to register data from multiple certification authorities in one system, and separate data servers and tables can be prepared for each certification authority. Furthermore, it is not necessarily limited to certification authorities, and any raw data linked to unique index data can be used with appropriate modifications if it is desired to make the data public while ensuring its authenticity.

[0085] [Second Example] Next, a second embodiment of the present invention will be described. This second embodiment relates to the management of various data, including transportation history, when a logistics company transports luggage. However, this embodiment can be applied to any similar data management, and is not necessarily limited to the transportation of luggage.

[0086] [Client device configuration and data generation method] Next, a data management system 100 according to a second embodiment of the present invention will be described. Fig. 15 shows an example of the configuration of a client device 200A according to this embodiment. The client device 200A is based on the configuration of the client device 200 in Fig. 9, and is equipped with various sensors such as a real-time clock, an open / close state sensor, a temperature / humidity sensor, and a vibration sensor, as well as an evidence calculator and a signature calculator. Note that the types of sensors are not limited to these.

[0087] In the client device 200A, data A (index data) corresponds to a timestamp, and data B (raw data) corresponds to various data such as the open / close state of the lid, temperature / humidity, and vibration state.

[0088] The evidence calculator is a calculator that generates data C (evidence data) using a first algorithm. That is, it generates data C (evidence data) of the current block from identification code A (individual number), data A (index data), data B (raw data), and data C' (evidence data of the previous block).

[0089] The signature calculator generates data D (signature data) by applying a digital signature to the obtained data C (evidence data) using the identification code B (private key) according to a second algorithm.

[0090] [Data registration and publication method] A data management method according to this embodiment is shown in Fig. 16. This example shows a case where at least one or more transport boxes 700 equipped with a client device 200A are transported from a first location to a third location via a second location. This embodiment can also be applied in the same way when there are more transport boxes or more locations.

[0091] The client device 200A registers the generated data in the data server 300C at an appropriate time. This data registration work may be performed sequentially, or may be performed collectively each time the data arrives at a location. The data server 300C may have a configuration similar to that of the data server 300 in FIG. 9. When registering data, the data server 300C verifies, according to the data authenticity verification procedure described above, that the data being registered is definitely from the desired client device 200A and that the blocks contained in the data are connected to the previous block via evidence data, and registers the data only if verification is successful. The data server 300C is intended to be public, like the data server 300 in FIG. 9. Of course, a private data server equivalent to the data server 300A in FIG. 14 may be separately prepared.

[0092] According to this embodiment, for example, the fact that "the temperature of the transport box never deviated from a specific temperature range before arriving at the base 3" can be proven using the temperature data made public by the data server 300C. In this case, if the verifier cannot trust the data server 300C, he or she can verify for himself or herself that the disclosed data has not been fabricated, following the data authenticity verification procedure described above.

[0093] [Modification of the second embodiment] In the second embodiment, the client device 200A is mounted on the transport box 700. In a modified example, the transport box 700 is equipped with, for example, an RF-ID tag, and data is read and registered by an RF-ID reader / writer, which is a client device 200B, installed at each base.

[0094] [Client device configuration and data generation method] An example configuration of a client device 200B according to this modification is shown in Fig. 17. The client device 200B is based on the configuration of the client device 200A in Fig. 15. However, it has an RF-ID reader instead of various sensors that generate raw data. The raw data is generated by the RF-ID reader reading data stored in or generated by an RF-ID tag.

[0095] Furthermore, in this modified example, it is assumed that data blocks are configured by linking them to the tag ID of the RF-ID tag, and the client device 200B does not necessarily have the evidence data (data C') of the previous block required to generate data C (evidence data). Therefore, it is assumed that the evidence data (data C') of the previous block is obtained from a data server. However, data blocks may also be configured by linking them to the identification information A (individual number) of the client device.

[0096] Furthermore, if data generated by the client device, such as a local timestamp, is used as index data (data A), multiple client devices may use the same index data (data A), so it is necessary to obtain unique index data from the data server.

[0097] The other configurations and data generation methods are the same as those of the client device 200A.

[0098] [Data registration and publication method] The data management method according to this modification is shown in FIG.

[0099] Each time the transport box 700A moves from location 1 to location 2 to location 3, the RF-ID tag is read by the client devices 200B1, 200B2, and 200B3 corresponding to the respective locations.

[0100] Each of the client devices 200B1, 200B2, and 200B3 generates data in accordance with the procedure shown in FIG. 18 and registers the data in the data server 300C.

[0101] First, the client device 200B1 reads the information of the RF-ID tag 1 and transmits the tag ID to the data server 300C to obtain data A (index data) and data C' (evidence data of the previous block). At this time, the data server 300C must authenticate that the client device 200B1 has legitimate access rights to this data block, for example by using the client device's identification code.

[0102] Next, the client device 200B1 creates data C (evidence data) and data D (signature data) according to the same procedure as described above, and registers them in the data server 300C.

[0103] When registering data, the data server 300C verifies that the data being registered in accordance with the above-mentioned data authenticity verification procedure is definitely from the desired client device, and that the blocks contained in the data are connected to the previous block via evidence data, and registers the data only if verification is successful.

[0104] Thereafter, the client devices 200B2 and 200B3 sequentially repeat these procedures each time the transport box 700A moves from one location to another, thereby registering data.

[0105] [Third Example] Next, a third embodiment of the present invention will be described. This embodiment relates to the case where a manufacturer manages various data including so-called BOM (Bill of Materials) data such as raw materials and processing history when manufacturing a product. However, this embodiment can be applied to any similar data management, and is not necessarily limited to product manufacturing. For example, it can be applied to so-called SBOM (Software Bill of Materials) data including dependencies between software libraries.

[0106] 19 shows the data management system of this embodiment. In this embodiment, the system comprises factory 1, which processes component 1 and component 2 to make product 1, factory 2, which uses product 1 as a component (component 3) and processes it to make product 2, and factory 3, which uses product 2 as a component (component 4) and further processes component 5 to make product 3. Client devices 200C1, 200C2, and 200C3 are provided in factories 1, 2, and 3, and they register data in data server 300C.

[0107] Each factory has one or more client devices for managing information on parts and processing history, i.e., BOM information, and these data are registered in the data server 300C in the same manner as in the first and second embodiments, with the serial number of each part or product being data A (index data) and the BOM data being data B (raw data). Although not shown in the figure, each client device also has an identification code A (individual number), an identification code B (private key), and an identification code C (public key), as in the other embodiments.

[0108] [How to generate BOM data] FIG. 20 shows a method for generating BOM data. In this example, it is assumed that a database is constructed that can retrieve BOM information for a product, tracing it back to its components. For this reason, BOM data includes BOM information for the components that make up a certain product. For example, BOM data 11, which is the BOM data for product 1, includes serial number 01 and serial number 02, which are identification codes for components 1 and 2.

[0109] In this way, if BOM data for product 11 is required, first obtain BOM data 11, and then obtain the BOM data for serial numbers 01 and 02 to obtain all BOM data included in product 11. Similarly, all BOM data for products 2 and 3 can be obtained by tracing the BOM data for those components in order.

[0110] The difference between this embodiment and other embodiments is whether the data blocks are connected in order in a single row or whether they branch out, forming a so-called graph structure. This results in, for example, a difference in the number of pieces of evidence data (data C') of the previous block used to generate evidence data (data C). Specifically, while in the previous embodiments there was only one piece of evidence data (data C3') of the immediately preceding block corresponding to a given piece of evidence data (data C), in this embodiment there may be multiple pieces of evidence data. In the example of Figure 20, when client device 200C1 generates evidence data 11, two pieces of evidence data, evidence data 01 and evidence data 02, are required as data C'.

[0111] To prepare for such a case, it is desirable that the data structure of data C' in the first algorithm allows multiple data to be input. In the case of ASN.1, a structure that can define a set of elements of the same type, such as SEQUENCE or SEQUENCE OF, or in the case of Protocol Buffers, a structure such as map, is used. Such a structure is also necessary for BOM data (data 2) for the same reasons.

[0112] [How to verify the authenticity of data] According to this embodiment, for example, if there is a request such as "Please certify that product 3 does not contain a certain chemical substance that is required to be labeled," this can be answered by disclosing the BOM data for all components traced back from BOM data 31. At this time, the verifier can verify that the disclosed data has not been fabricated according to the data authenticity verification procedure described above.

[0113] [Fourth Example] Next, a fourth embodiment will be described, in which data is registered regardless of the previous block.

[0114] 21 shows a method for generating evidence data in Example 4. That is, in this example, evidence data of the previous block is not taken into consideration when generating evidence data.

[0115] FIG. 22 shows an example of registration in a data server in the fourth embodiment.

[0116] In this example, similar to the example of Figure 13, the value data may be a set of index data and signature data, and the value data may include key data of the previous block, making it possible to obtain a series of data by tracing the blocks sequentially.

[0117] This concludes the description of the embodiment of the present invention. Note that the present invention is not limited to the above embodiment, and various modifications are possible without departing from the spirit of the present invention. [Explanation of symbols]

[0118] 100 Data Management System 200 client devices 201 Raw Data Generation Unit 202 Index Data Generation Unit 203 Evidence Data Generation Department 204 Signature Data Generation Unit 205 Transmitter / Receiver 300 Data Server 301 Database 302 Verification Data Generation Unit 303 Evidence Data Restoration Department 304 Data Registration Management Department 305 Transmitter / Receiver 400 Validation Device 401 Evidence Data Generation Department 402 Evidence Data Recovery Department 403 Verification Department 404 Transmitter / Receiver 500 Communication Network 700 shipping boxes 1000 computers 1001 CPUs (processors) 1002 Main memory 1003 External Interface 1004 External storage device 1005 Applications

Claims

1. A data management system comprising a client device that sequentially generates or receives data to be stored, and a data storage device that stores the data to be stored provided by the client device, connected via a communication network, client device identification information for uniquely identifying the client device and a private key associated with the client device are assigned to the client device; The client device an evidence data generation means for generating a hash value as evidence data by applying a predetermined hash function to first integrated data obtained by integrating at least the client device identification information, unique index data individually assigned to each of the storage target data, the storage target data, and preceding data as elements for each of the storage target data generated or received sequentially, wherein the preceding data for the first storage target data generated or received is predetermined start data, and the preceding data for the storage target data generated or received thereafter is the evidence data generated immediately before by the evidence data generation means; a signature data generation means for generating signature data for the evidence data generated by the evidence data generation means by using the private key; For each of the data to be stored that is sequentially generated or received, supply the client device identification information, the index data, the data to be stored, and the signature data of the evidence data to the data storage device; The data storage device is a storage means used to store, for each of the data to be stored that is sequentially generated or received in the client device, the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data; a verification data generation means for receiving, for each piece of storage target data sequentially generated or received by the client device, the client device identification information, the storage target data, and the signature data of the evidence data, as well as unique index data individually assigned to each piece of storage target data, which are supplied from the client device, and further, except for the case of the first generated or received storage target data, extracting from the storage means, based on the index data assigned to the previous storage target data, evidence data generated for the previous piece of storage target data, and generating, as verification data, a hash value using a hash function corresponding to the predetermined hash function on second integrated data obtained by integrating at least the evidence data generated for the previous piece of storage target data, the client device identification information, the index data, and the storage target data as elements, and which uses the predetermined start data for the first generated or received storage target data instead of the evidence data generated for the previous piece of storage target data; an evidence data restoring means for restoring the evidence data from the signature data of the evidence data by using a public key associated with the client device; a storage management means for comparing the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, and verifying, based on the comparison result, whether the client device identification information, the storage target data, the signature data of the evidence data, and the unique index data individually assigned to each of the storage target data supplied from the client device are authentic, and storing and managing, in the storage means, the client device identification information, the storage target data, the signature data of the evidence data, and the corresponding evidence data supplied from the client device, and the unique index data individually assigned to each of the storage target data as authentic data, based on the verification result; The data storage device stores data in a key-value format, A data management system characterized in that key data is generated from the index data and the signature data, and the key data of the data to be stored, the evidence data, the client device identification information, and the previous data is used as value data.

2. A data management system comprising a client device that sequentially generates or receives data to be stored and a data storage device that stores the data to be stored provided from the client device, connected via a communication network, client device identification information for uniquely identifying the client device and a private key associated with the client device are assigned to the client device; The client device an evidence data generation means for generating a hash value as evidence data by applying a predetermined hash function to first integrated data obtained by integrating at least the client device identification information, unique index data individually assigned to each of the storage target data, the storage target data, and preceding data as elements for each of the storage target data generated or received sequentially, wherein the preceding data for the first storage target data generated or received is predetermined start data, and the preceding data for the storage target data generated or received thereafter is the evidence data generated immediately before by the evidence data generation means; a signature data generation means for generating signature data for the evidence data generated by the evidence data generation means by using the private key; For each of the data to be stored that is sequentially generated or received, supply the client device identification information, the index data, the data to be stored, and the signature data of the evidence data to the data storage device; The data storage device is a storage means used to store, for each of the data to be stored that is sequentially generated or received in the client device, the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data; a verification data generation means for receiving, for each piece of storage target data sequentially generated or received by the client device, the client device identification information, the storage target data, and the signature data of the evidence data, as well as unique index data individually assigned to each piece of storage target data, which are supplied from the client device, and further, except for the case of the first generated or received storage target data, extracting from the storage means, based on the index data assigned to the previous storage target data, evidence data generated for the previous piece of storage target data, and generating, as verification data, a hash value using a hash function corresponding to the predetermined hash function on second integrated data obtained by integrating at least the evidence data generated for the previous piece of storage target data, the client device identification information, the index data, and the storage target data as elements, and which uses the predetermined start data for the first generated or received storage target data instead of the evidence data generated for the previous piece of storage target data; an evidence data restoring means for restoring the evidence data from the signature data of the evidence data by using a public key associated with the client device; a storage management means for comparing the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, and verifying, based on the comparison result, whether the client device identification information, the storage target data, the signature data of the evidence data, and the unique index data individually assigned to each of the storage target data supplied from the client device are authentic, and storing and managing, in the storage means, the client device identification information, the storage target data, the signature data of the evidence data, and the corresponding evidence data supplied from the client device, and the unique index data individually assigned to each of the storage target data as authentic data, based on the verification result; A data management system characterized in that in addition to the above-mentioned data storage device, it has a data disclosure device, wherein the data disclosure device stores data in a key-value format, generates key data from the index data and the signature data, and uses the key data of the data to be stored, the evidence data, the client device identification information, and the previous data as value data.

3. 3. The data management system according to claim 2, wherein said client device is associated with a certification authority, and said data to be stored is a description of registered business activities of the certification authority.

4. A data management system comprising a client device that sequentially generates or receives data to be stored and a data storage device that stores the data to be stored provided from the client device, connected via a communication network, client device identification information for uniquely identifying the client device and a private key associated with the client device are assigned to the client device; The client device an evidence data generation means for generating a hash value as evidence data by applying a predetermined hash function to first integrated data obtained by integrating at least the client device identification information, unique index data individually assigned to each of the storage target data, the storage target data, and preceding data as elements for each of the storage target data generated or received sequentially, wherein the preceding data for the first storage target data generated or received is predetermined start data, and the preceding data for the storage target data generated or received thereafter is the evidence data generated immediately before by the evidence data generation means; a signature data generation means for generating signature data for the evidence data generated by the evidence data generation means by using the private key; For each of the data to be stored that is sequentially generated or received, supply the client device identification information, the index data, the data to be stored, and the signature data of the evidence data to the data storage device; The data storage device is a storage means used to store, for each of the data to be stored that is sequentially generated or received in the client device, the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data; a verification data generation means for receiving, for each piece of storage target data sequentially generated or received by the client device, the client device identification information, the storage target data, and the signature data of the evidence data, as well as unique index data individually assigned to each piece of storage target data, which are supplied from the client device, and further, except for the case of the first generated or received storage target data, extracting from the storage means, based on the index data assigned to the previous storage target data, evidence data generated for the previous piece of storage target data, and generating, as verification data, a hash value using a hash function corresponding to the predetermined hash function on second integrated data obtained by integrating at least the evidence data generated for the previous piece of storage target data, the client device identification information, the index data, and the storage target data as elements, and which uses the predetermined start data for the first generated or received storage target data instead of the evidence data generated for the previous piece of storage target data; an evidence data restoring means for restoring the evidence data from the signature data of the evidence data by using a public key associated with the client device; a storage management means for comparing the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, and verifying, based on the comparison result, whether the client device identification information, the storage target data, the signature data of the evidence data, and the unique index data individually assigned to each of the storage target data supplied from the client device are authentic, and storing and managing, in the storage means, the client device identification information, the storage target data, the signature data of the evidence data, and the corresponding evidence data supplied from the client device, and the unique index data individually assigned to each of the storage target data as authentic data, based on the verification result; A data management system characterized in that in addition to the above-mentioned data storage device, it has a data disclosure device, wherein the data disclosure device stores data in a key-value format, generates key data from the client device identification information, the index data, and the signature data, and uses the key data of the data to be stored, the evidence data, and the previous data as value data.

Images