Data management system
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2026-02-05
- Publication Date
- 2026-08-13
Smart Images
Figure JP2026004086_13082026_PF_FP_ABST
Abstract
Description
Data Management System
[0001] This invention relates to a data management technology that can guarantee the authenticity of data exchanged in a communication network, such as the Internet.
[0002] Addressing data security is crucial in communication networks. The recent proliferation of IoT (Internet of Things) networks has brought about increased convenience, but it has also given rise to social problems related to data security. For example, this includes "eavesdropping," where data that should not be accessible is secretly viewed, and "tampering," where the content of data is illegally altered.
[0003] To address these social issues, secure data handling methods have been proposed (for example, Non-Patent Document 1). This Non-Patent Document 1 proposes using inexpensive passive RFID tags for cost reasons when tracking the automated logistics of large quantities of goods, and further proposes that an RFID reader equipped with digital signature, location constraint, and tamper-proof functions reads and writes to the tags, while atomically writing the evidence to the blockchain.
[0004] However, this proposed method had several problems: it was costly due to the use of a public blockchain to prevent data tampering, and it was difficult to gain trust because it could not provide users with sufficient methods to verify the authenticity of the data.
[0005] Furthermore, Patent Document 1 discloses a system that includes an IoT sensor for measuring the internal temperature and humidity of a wine brewing storage facility, a database that records winery information, wine raw material information, and measurement data transmitted from the IoT sensor, and an AI that analyzes the raw material information and measurement data recorded in the database to evaluate the quality of the wine, and that hashes the winery information, raw material information, measurement data, and evaluation results information by the AI and records them on a blockchain. This system also has the constraint of using a blockchain.
[0006] The prior art and its problems described above are explained only to illustrate part of the background of this invention. Please note that this invention is not limited to the prior art and its problems described above.
[0007] Japanese Patent Publication No. 2024-104794
[0008] 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
[0009] This invention was made in consideration of the above circumstances and aims to provide a data management technology that guarantees the authenticity of data generated and stored on a communication network without using blockchain. However, blockchain technology may be used in conjunction with this invention, such as storing a portion of the data to be stored on a blockchain and detecting tampering or inauthenticity of the data stored thereafter, and the use of blockchain technology is not excluded.
[0010] In order to achieve the above-mentioned objectives, this invention employs the configuration described in the claims. Before describing the invention in detail, a supplementary explanation of the claims will be provided here.
[0011] In other words, according to one aspect of this invention, in order to achieve the above objective, a data management system is provided which connects a client device that sequentially generates or receives data to be stored and a data storage device that stores the data to be stored supplied from the client device via a communication network: Client device identification information for uniquely identifying the client device and a secret key associated with the client device are assigned to the client device; the client device is an evidence data generation means which, for each of the sequentially generated or received data to be stored, applies a predetermined hash function to a first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each of the data to be stored, the data to be stored, and prior data as elements, to generate a hash value as evidence data, and for the first data to be generated or received to be stored... The evidence data generation means comprises: the evidence data generation means, wherein the preceding data is predetermined starting data, and for data to be stored generated or received thereafter, the preceding data is the evidence data that was immediately preceding and generated by the evidence data generation means; and the signature data generation means generates signature data using the secret key for the evidence data generated by the evidence data generation means; for each data to be stored generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device; and the data storage device comprises: storage means used to store the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data for each data to be stored generated or received sequentially in the client device;Verification data generation means that, for each data to be stored that is sequentially generated or received by the client device, receives the client device identification information, the data to be stored, and the signature data of the evidence data supplied from the client device, as well as unique index data individually assigned to each data to be stored, and further retrieves the evidence data generated for the previous data to be stored from the storage means based on the index data assigned to the previous data to be stored, except for the data to be stored that was initially generated or received, and generates a hash value as verification data for a second integrated data which is formed by integrating at least the evidence data generated for the previous data to be stored, the client device identification information, the index data, and the data to be stored as elements, using the predetermined hash function and a corresponding hash function, wherein for the data to be stored that was initially generated or received, the evidence data generated for the previous data to be stored The system includes: a verification data generation means that uses the predetermined start data described above instead; an evidence data restoration means that restores the evidence data from the signature data of the evidence data using the public key associated with the client device; and a storage management means that compares the verification data output from the verification data generation means with the evidence data restoration result output from the evidence data restoration means, verifies based on the comparison result whether the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the unique index data individually assigned to each piece of data to be stored are authentic, and based on the verification result, stores and manages the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the corresponding evidence data, as well as the unique index data individually assigned to each piece of data to be stored, in the storage means as authentic data.
[0012] In this configuration, the authenticity of data generated and stored on a communication network can be easily guaranteed without using blockchain. The private and public keys may be generated using key generation algorithms such as RSA, ECDSA, or EdDSA, but are not limited to these.
[0013] Although the above explanation focuses on RSA signatures and describes signature verification by restoring evidence data, it is broadly applicable to signature verification using private key and public key calculations. In this case, the evidence data restoration means should not be interpreted narrowly by its name; rather, it involves performing a public key calculation on the signature data, and the authenticity of the data to be stored can be verified by comparing the public key calculation result with the verification data.
[0014] In this configuration, the client device may generate the index data and supply it to the data storage device.
[0015] In this configuration, the data storage device may generate the index data and supply it to the client device.
[0016] In this configuration, the data storage device may store data in a key-value format.
[0017] In this configuration, the key data is generated from the index data and signature data, and the stored data, evidence data, client device identification information, and the key data of the previous data may be used as the value data.
[0018] In this configuration, the data management system may further include a data verification device connected to the data storage device via the communication network, which verifies the authenticity of the data stored in the data storage device, the data verification device receiving: the evidence data of the block immediately preceding the verification range, the client device identification information of the blocks within the verification range, the index data, and the data to be stored, as well as the signature data of the final block within the verification range, and the public key corresponding to the private key, and for each block within the verification range, starting from the preceding block, the data verification device may further include the data immediately preceding the block. A predetermined hash function may be applied to a third integrated information formed by integrating the start data or the evidence data, as well as the client device identification information, index data, and storage target data of the block, to generate a hash value as the evidence data of the block. Furthermore, the evidence data generated for the last block and the evidence data restored from the signature data of the last block using the public key may be used to determine the authenticity of the data in the blocks within the scope of verification by comparing the evidence data generated by the hash function with the evidence data restored with the public key.
[0019] In this configuration, in addition to the data storage device, there is a data publishing device, which stores data in a key-value format, generates key data from the index data and signature data, and may use the stored data, evidence data, client device identification information, and the key data of the previous data as value data.
[0020] In this configuration, the client device is associated with the certification body, and the data to be stored may be a description of the certification body's registered business activities.
[0021] In this configuration, in addition to the above data storage device, a data disclosure device is provided. 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 may use the data to be stored, the evidence data, and the key data of the previous data as value data.
[0022] In this configuration, the client device is a device used in relation to transportation, and the data to be stored may include a transportation history.
[0023] In this configuration, the device includes an RF-ID reader / writer, and data reading and registration may be performed using the RF-ID reader / writer.
[0024] In this configuration, the device may be a transportation box.
[0025] 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.
[0026] According to another aspect of this invention, in 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 supplied from the client device, connected via a communication network: Client device identification information for uniquely identifying the client device and a secret key associated with the client device are assigned to the client device; the client device is an evidence data generation means that, for each of the sequentially generated or received data to be stored, applies a predetermined hash function to first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each of the data to be stored, the data to be stored, and prior data as elements, thereby generating a hash value as evidence data, wherein for the data to be stored that is first generated or received, the prior data The evidence data generation means is a predetermined starting data, and for data to be stored generated or received thereafter, the preceding data is the evidence data generated immediately before by the evidence data generation means; the evidence data generation means has a signature data generation means that generates signature data using the secret key for the evidence data generated by the evidence data generation means; for each data to be stored generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device; the data storage device has storage means that stores the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data for each data to be stored generated or received sequentially by the client device.
[0027] Even in this configuration, the authenticity of data generated and stored on the communication network can be easily guaranteed without using blockchain.
[0028] According to another aspect of this invention, in 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 supplied from the client device, connected via a communication network: Client device identification information for uniquely identifying the client device and a secret key associated with the client device are assigned to the client device; the client device has: evidence data generation means for generating evidence data as evidence data by applying a predetermined hash function to first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each piece of data to be stored, and the data to be stored as elements for each piece of data to be stored that is sequentially generated or received; and signature data generation means for generating signature data using the secret key on the evidence data generated by the evidence data generation means; and for each piece of data to be stored that is sequentially generated or received, the client The data storage device is supplied with client device identification information, the index data, the data to be stored, and the signature data of the evidence data; the data storage device includes: storage means used to store the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data for each data to be stored that is sequentially generated or received by the client device; and verification data generation means that receives the client device identification information, the data to be stored, and the signature data of the evidence data supplied from the client device, as well as unique index data individually assigned to each data to be stored, for each data to be stored that is sequentially generated or received by the client device, and generates a hash value as verification data for a second integrated data formed by integrating the client device identification information, the index data, and the data to be stored as elements, using a predetermined hash function and a corresponding hash function;Evidence data restoration means for restoring the evidence data from the signature data of the evidence data using the public key associated with the client device; 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 based on the comparison result, verifying 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 storage target data supplied from the client device 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, the corresponding evidence data, and the unique index data individually assigned to each storage target data as authentic data in the storage means.
[0029] Even in this configuration, the authenticity of data generated and stored on a communication network can be easily ensured without using a blockchain.
[0030] According to yet another aspect of this invention, in 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 supplied from the client device in a storage device, connected via a communication network: Client device identification information for uniquely identifying the client device and a secret key associated with the client device are assigned to the client device; the client device: for each of the sequentially generated or received data to be stored, applies a predetermined hash function to a first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each of the data to be stored, the data to be stored, and prior data as elements, to generate a hash value as evidence data, and initially generated or received For data to be stored, the preceding data is predetermined start data, and for data to be stored generated or received thereafter, the preceding data is the evidence data generated immediately before; signature data is generated for the evidence data using the private key; and for each piece of data to be stored generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device; the data storage device comprises a storage device used to store the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data for each piece of data to be stored sequentially generated or received by the client device;Furthermore, the data storage device: receives, for each piece of data to be stored sequentially generated or received by the client device, the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and a unique index data assigned individually to each piece of data to be stored; further, except for the first piece of data to be stored, retrieve the evidence data generated for the previous piece of data to be stored from the storage device based on the index data assigned to the previous piece of data to be stored; generate a hash value as verification data for a second integrated data which is formed by integrating at least the evidence data generated for the previous piece of data to be stored, the client device identification information, the index data, and the data to be stored as elements, and uses the predetermined hash function and a corresponding hash function; and for the first piece of data to be stored, The system is configured to use the predetermined start data instead of the evidence data generated for the previous data to be stored; to perform a public key operation on the signature data of the evidence data using the public key associated with the client device; to compare the verification data with the result of the public key operation on the signature data; and to verify, based on the comparison result, whether the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the unique index data individually assigned to each data to be stored are authentic; and based on the verification result, to store and manage in the storage device the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the corresponding evidence data, and the unique index data individually assigned to each data to be stored, as authentic data.
[0031] In this configuration, the authenticity of data generated and stored on the communication network can be easily guaranteed without using blockchain. The private and public keys may be generated using key generation algorithms such as RSA, ECDSA, or EdDSA, but the key generation algorithms are not limited to these.
[0032] Furthermore, this invention can be realized not only as an apparatus or system, but also as a method. Naturally, a part of such an invention can be configured as software. And, of course, software products used to run such software on a computer are also included within the technical scope of this invention.
[0033] The above-mentioned aspects and other aspects of this invention are described in the claims and will be elaborated upon using the following embodiments.
[0034] According to this invention, the authenticity of data generated and stored on a communication network can be easily guaranteed without using blockchain.
[0035] This figure shows an example of the usage environment for the data management system 100 of the first embodiment of this invention. This is a block diagram schematically illustrating an example of the configuration of the client device 200 of the data management system 100 of the first embodiment of this invention. This is a block diagram schematically illustrating an example of the configuration of the data server 300 of the data management system 100 of the first embodiment of this invention. This is a block diagram schematically illustrating an example of the configuration of the verification device 400 of the data management system 100 of the first embodiment of this invention. This is a flowchart illustrating an example of the operation of the client device 200 of the data management system 100 of the first embodiment of this invention. This is a flowchart illustrating an example of the operation of the data server 300 of the data management system 100 of the first embodiment of this invention. This is a flowchart illustrating an example of the operation of the verification device 400 of the data management system 100 of the first embodiment of this invention. This figure illustrates the computing resources of the client device 200, data server 300, and verification device 400 of the data management system 100 of the first embodiment of this invention. This figure illustrates an example of identification code and data in the data management system 100 of the first embodiment of this invention. This figure illustrates an example of generating evidence data and signature data in a client device 200 of a data management system 100 according to the first embodiment of this invention. This figure illustrates an example of a data registration method in a database 300 of a data management system 100 according to the first embodiment of this invention. This figure illustrates an example of verifying data authenticity in a verification device 400 of a data management system 100 according to the first embodiment of this invention. This figure illustrates a modified example in which a public evidence server is added to the first embodiment of this invention. This figure shows an example of using the modified example shown in Figure 13 for the publication of a registered business certificate. This figure illustrates a second embodiment of this invention, in which this invention is applied to the management of various data, including transportation history, when a logistics company transports goods. This figure illustrates an example of data registration in the second embodiment of this invention. This figure illustrates a modified example of the second embodiment of this invention. This figure illustrates an example of data registration in a modified example of the second embodiment of this invention. This figure illustrates a third embodiment of this invention. This figure illustrates a third embodiment of this invention. This figure illustrates a fourth embodiment of this invention.This figure illustrates a fourth embodiment of the present invention.
[0036] The following describes embodiments of this invention.
[0037] [First Embodiment] First, a data management system 100 according to the first embodiment will be described. Figure 1 shows the data management system 100 according to the first embodiment of the present invention as a whole. In Figure 1, a client device 200 and a data server 300 are connected via a communication network 500 (for example, 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. Multiple data servers 300 may also be provided, for example, depending on the services to be provided.
[0038] As shown in Figure 2, the client device 200 may comprise a raw data generation unit 201 for generating or receiving raw data, an index data generation unit 202 for generating index data, an evidence data generation unit 203 for generating evidence data, a signature data generation unit 204 for generating signature data, and a transmission / reception unit 205 for sending and receiving various data and other information. The client device 200 is also assigned an identification code A (unique 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 (unique 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 explained later with reference to, for example, Figures 9 to 12.
[0039] As shown in Figure 3, the data server 300 may comprise 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 for sending and receiving various data and other information. 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 individual number (identification code A) as a single data block.
[0040] As shown in Figure 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 for sending and receiving various data and other information.
[0041] The client device 200, data server 300, and 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 described later with reference to Figures 10 to 12, etc.
[0042] An example of the operation of the client device 200 (Figure 5) is as follows: [Step S10]: Generate or receive raw data (data B). [Step S11]: Generate index data (data A). [Step S12]: Generate evidence data (data C) from the individual number (identification code A), index data (data A), raw data (data B), and previously generated evidence data (data C', with a predetermined initial value for the first data). [Step S13]: Generate signature data (data D) 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), previously used index data (data A), raw data (data B), and signature data (data D) to the data server 300.
[0043] An example of the operation of the data server 300 (Figure 6) is as follows: [Step S20]: Receives the unique identification 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') from the client device 200. [Step S21]: Retrieves the evidence data (data C) that was previously generated based on the previously used index data (data A'), and generates evidence data (hash value N) from the identification code A (unique identification number), index data (data A), raw data (data B), and previously generated evidence data. １ (See Figure 11). [Step S22]: Process the signature data with the public key (identification code C) to restore the evidence data (hash value N). ２ (See Figure 11). [Step S23]: Evidence data obtained in Step S21 and Step S22 (N １ , N ２ ) are compared and verified. The data is registered only if the verification is successful.
[0044] An example of the operation of the verification device 400 (Figure 7) is as follows: [Step S30]: The device receives the individual number (identification code A), index data (data A), and raw data (data B) for the range to be verified, as well as the evidence data (data C') from the block immediately preceding 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) in the last block. [Step S31]: For each block N within the range to be verified, the device processes the evidence data (data C') from the previous block N-1, the individual number (identification code A), index data (data A), and raw data (data B) of that block N according to the first algorithm and generates a hash value N １(Figure 12, data that should be equal to data C (evidence data) of block N) is generated. [Step S32]: Determine if the processed block is the final block. If it is the final block, proceed to S34; otherwise, proceed to step S33. [Step S33]: Increment N by 1 and return to block S31 to process the next block and repeat the process. [Step S34]: The signature data (data D) in the final block is decrypted using the signature verification function in the second algorithm using the public key (identification code C) to obtain a hash value N ２ (Figure 12) is obtained. [Step S35]: The hash value N １ and hash value N ２ If they match, it can be verified that the data in the block within the verification range is indeed identical to that registered by the client device 200 (step S36). Otherwise, it is determined that it is not authentic (step S37). In the example in Figure 12, the number N of the last block is 3.
[0045] Figure 8 shows a schematic configuration example of a computer comprising a client device 200, a data server 300, or a verification device 400, but is not limited thereto. In Figure 8, the computer 1000 is configured to include a CPU (processor) 1001, main memory 1002, an external interface 1003, and an external storage device 1004, etc. By installing the application 1005 on this computer 1000, the operation of the client device 200, data server 300, or verification device 400 can be realized. The client device 200, data server 300, or verification device 400 may be configured in a distributed manner across multiple computers.
[0046] Next, a data management system 100 according to the first embodiment will be described in detail.
[0047] Figure 9 illustrates the identification codes 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 with the data server 300.
[0048] [Contents of the Identification Code] There are at least three types of identification codes. Specifically, there is a unique individual number (Identification Code A) that is specific to each client device and is made public to the outside, which is used to distinguish the client device from other client devices; a private key (Identification Code B) that, in principle, only exists inside the client device 200 and is difficult for third parties to read or copy; and a public key (Identification Code C) that is generated from Identification Code B and made public to the outside.
[0049] The identification code A can be anything unique within the system, such as the device name or MAC address of client device 200, but is not limited to these.
[0050] Furthermore, while identification code C (public key) is generated as a pair from identification code B (private key) using a key generation algorithm such as RSA, ECDSA, or EdDSA, the key generation algorithm is not limited to these. Identification code C may be pre-registered with data server 1 in association with identification code A, or it may be made public on the network in a desired manner.
[0051] Furthermore, in the database 301 of the data server 300 (see Figure 3), data and identification codes are stored together as data blocks, as shown in Figure 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.
[0052] [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), and the generation methods for these are as follows (see Figure 10).
[0053] Data B (raw data) refers to, but is not limited to, any data generated by the client device 200 itself through calculation, measurement, or external input, such as timestamps, temperature, humidity, acceleration, open / close information for doors and lids, location information measured by GPS, image data and video data captured by cameras or scanned by scanners, arbitrary digital data such as ID numbers and raw material information contained in products, or text data entered by humans.
[0054] Data A (index data) can be anything unique within the data server 300 while having a one-to-one correspondence with Data B (raw data). For example, it can be a timestamp, a serial number, or a combination of identification code A (individual number) and these timestamps or serial numbers, but it is not limited to these. Furthermore, since it is conceivable that a series of data may be written to the same table from different client devices, client device 200 does not necessarily know Data A (index data). In such cases, it is necessary to provide a mechanism to notify client device 1 of Data A (index data).
[0055] Data C (evidence data) is generated on the client device 200 using the following procedure (see Figure 10).
[0056] 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. Furthermore, by inputting this into a desired cryptographic hash function such as SHA-1 or SHA-2, data C (evidence data) is obtained (first algorithm). At this time, the predetermined procedure may be, but is not limited to, converting data written according to 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] In the first block, since data C' (evidence data generated in the previous block) does not exist, the desired starting data is used as the input value instead. Specific examples of starting data include, but are not limited to, various information about the data table where the series of data is stored, such as identifiers, data formats, and properties. Furthermore, since it is conceivable that a series of data may be written to the same table from different client devices 200, the client device 200 does not necessarily know data C'. In such cases, a mechanism is needed to notify the client device 200 of data C'.
[0058] Furthermore, data D (signature data) is generated by signing data C (evidence data) with a signature function in a desired digital signature algorithm (second algorithm) such as RSA, ECDSA, or EdDSA, using the identification code B (private key).
[0059] [Data Registration Method] The registration format of the database 301 of the data server 300 may be a standard database such as an SQL database or an amorphous database of the key-value store (KVS) type. However, when raw data (Data B) is amorphous, a KVS database that is easier to handle amorphous data is desirable. For example, when Data A (index data) is used as key data and other data is used as value data, it is desirable to use value data that has been converted into binary data according to a predetermined procedure. At this time, the predetermined procedure may be to convert data described according to a data format such as ASN.1 (Abstract Syntax Notation One) into binary data by DER (Distinguished Encoding Rules) or to serialize data using Protocol Buffers, but is not limited thereto.
[0060] The client device 200 registers the data generated as described above with the data server 300 block by block (see FIG. 9). As shown by the dashed line in FIG. 11, when registering the data of an arbitrary block N, the client device 200 uses, as arguments, the identification code A Ｎ (individual number), identification code C Ｎ (public key), Data A Ｎ (index data N), Data B Ｎ (raw data N), Data D Ｎ (signature data N) and Data A in the previous block (block N - 1) Ｎ－１ (index data N - 1) to the data server 300.
[0061] When the data server 300 receives these data, first, it reads the data C Ｎー１ (evidence data N - 1) in the block N - 1 corresponding to the index data N - 1 and obtains the hash value N １ (equal to the evidence data N if all arguments are genuine) by the first algorithm described above.
[0062] Next, signature data N (data D) Ｎ The data is processed using the identification code C (public key) by the signature verification function in the second algorithm, and the hash value N is obtained. ２ (If the signature data and public key are authentic, this is equal to the evidence data N.)
[0063] Hash value N １ and hash value N ２ If they match, it can be confirmed that this data was indeed sent from the legitimate client device 1, and the data registration management unit 304 of the data server 300 registers this data as genuine in its database 301.
[0064] Furthermore, if the identification code C (public key) is registered on the data server 300 itself or is publicly available on the network, it may be used without receiving it from the client device 200.
[0065] [Procedure for verifying data authenticity] 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, any dataset of data A (index data) and corresponding data B (raw data) disclosed by the data owner can be verified to be unaltered or fabricated by following the procedure below (see Figure 12).
[0066] To verify the authenticity of the data, the verifier (verification device 400) receives disclosure of the identification code A (unique number), data A (index data), and data B (raw data) for the range to be verified, as well as data C (evidence data) from the block immediately preceding the range to be verified, and identification code C (public key) and data D (signature data) corresponding to the identification code A (unique number) in the final block.
[0067] The verifier (verification device 400) first processes the data C (evidence data) from the block immediately preceding the verification range, along with the identification code A (unique number), data A (index data), and data B (raw data) from the first block, according to the first algorithm to obtain a hash value of 1. This is the data that should ideally be equal to the data C (evidence data) from the first block.
[0068] Next, the hash values are calculated in the same way up to the final block using the disclosed data. In the example in Figure 12, the hash value of block 3 is 3. １ To that extent.
[0069] Next, the data D (signature data 3) in the final block is decrypted by the signature verification function in the second algorithm using the identification code 3 (public key) to obtain a hash value 3. ２ Here, the hash value 3 １ and hash value 3 ２ If they match, it can be verified that the data in the block being verified is indeed identical to the data registered by client device 1. In other words, the authenticity of the data can be verified.
[0070] In this case, since there may be multiple client devices, the identification code C (public key) used for verification must always correspond to the identification code A (unique device number) of the block in question (block 3).
[0071] [Modification of the First Embodiment] Next, a modification of the first embodiment will be described. In this modification, in addition to the data server 300A, a data server 300B (Figure 13) is provided for the purpose of making data publicly available.
[0072] 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 denoted by corresponding reference numerals. In Figure 13, the data server 300A has the same configuration as the data server 300 in Figure 9, or at a minimum, stores pairs of data A (index data) and data D (signature data) for each block.
[0073] Data server 300B is a data server established for the purpose of making data public, 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 (unique number), and the key data from the previous block are used as value data.
[0074] In this modified example, it is assumed that only the data owner can read data from the data server 300A. In other words, the data owner treats the data server 300A as a regular database.
[0075] In contrast, data retrieval from data server 300B is assumed to be possible by anyone who knows the key data, i.e., the set of data A (index data) and data D (signature data). In other words, the data on data server 300B is basically made public.
[0076] Furthermore, if data is registered using a data authenticity verification method at the time of data registration, and the user trusts the data server 300B, the authenticity of the data can be considered to have been confirmed by the fact that the data has been registered. In other words, the user can omit verifying the authenticity of the data themselves.
[0077] Because it is difficult to guess data D (signature data), this method allows the data owner to 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, a user who is disclosed the value data of a certain block is entitled to have the data of all previous blocks disclosed.
[0078] Of course, if there is no need to make inference difficult, you may omit data D (signature data) from the key data.
[0079] Furthermore, unnecessary data can be removed from the value data as appropriate. In particular, by excluding the key data from the previous block, it becomes impossible to read data prior to the disclosed block.
[0080] Furthermore, when allowing users to use the publicly accessible data server 300B, the data owner may not directly disclose the set of data A (index data) and data D (signature data) to the user, but instead supply the user with a ticket, and based on this ticket, the set of data A (index data) and data D (signature data) will be generated in a private state and a series of raw data will be supplied. Conditions such as the usage period may be incorporated into this ticket.
[0081] By using this modified version, for example, it is possible to publish a registered business certificate that guarantees data authenticity, as shown in Figure 14.
[0082] Let's consider a scenario where there are multiple certification bodies that grant licenses to companies performing special tasks, such as religious food preparation, and these certification bodies use data server 300B as a database for registering and publishing licenses.
[0083] Each certification body has one or more client devices 200, and uses the device name (identification code A, unique number), license number (data A, index data), license data (data B, raw data), and evidence data from the previous block (data C') to generate evidence data (data C) based on the data generation method. If the client device does not know the evidence data C', it is obtained from the data server 300B.
[0084] Examples of license data include, but are not limited to, company names, website URLs, license numbers, and other text data related to the license content, as well as non-text data such as image data of the license. Furthermore, since handling image data as raw data or as part thereof is undesirable from the standpoint of data size and ease of handling, it is preferable to use a combination of the image data's hash value or the cloud storage file ID as a substitute for the image data itself.
[0085] The signature data (data D) is obtained by signing the evidence data (data C) with a signature function in a signature algorithm (second algorithm) that uses the private key (identification code B) of each client device.
[0086] According to this modified example, when a business operator is asked by a third party whether they truly possess the necessary licenses for the business in question, they can demonstrate by showing the data published on the data server 300B that this data was indeed registered by the certification authority's client device 200, and that the data has not been tampered with by anyone, including the certification authority, since its registration. In other words, the authenticity of the data can be guaranteed.
[0087] Furthermore, it is not necessary to register data from multiple certification authorities in a single system; separate data servers and tables can be prepared for each certification authority. Also, it is not limited to certification authorities; if you wish to publish any raw data linked to unique index data while ensuring data authenticity, you can modify and use it as appropriate.
[0088] [Second Embodiment] 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 goods. However, this embodiment can be applied to any similar data management, and is not necessarily limited to the transportation of goods.
[0089] [Client Device Configuration and Data Generation Method] Next, a data management system 100 of the second embodiment of the present invention will be described. Figure 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 Figure 9 and includes various sensors such as a real-time clock, an open / closed state sensor, a temperature and humidity sensor, a vibration sensor, an evidence calculator, and a signature calculator. Note that the types of sensors are not limited to these.
[0090] In client device 200A, data A (index data) corresponds to a timestamp, and data B (raw data) corresponds to various data such as the lid's open / closed state, temperature and humidity, and vibration status.
[0091] The evidence calculator is a calculator that generates data C (evidence data) using the first algorithm. Specifically, it generates data C (evidence data) for the current block from identification code A (individual number), data A (index data), data B (raw data), and data C' (evidence data from the previous block).
[0092] The signature calculator uses the identification code B (private key) to digitally sign the obtained data C (evidence data) using a second algorithm to generate data D (signed data).
[0093] [Data Registration and Publication Method] Figure 16 shows the data management method according to this embodiment. An example is shown where at least one transport box 700 equipped with a client device 200A is transported from a first base to a third base via a second base. This embodiment can be similarly applied when there are more transport boxes or bases.
[0094] The client device 200A registers the generated data with the data server 300C at the appropriate time. This data registration can be done sequentially or all at once upon arrival at each location. The data server 300C may have the same configuration as the data server 300 in Figure 9. When registering data, the data server 300C verifies, according to the data authenticity verification procedure described earlier, 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 blocks via evidence data. Only if verification is successful does the data server 300C register the data. The data server 300C is expected to be publicly accessible, similar to the data server 300 in Figure 9. Of course, a separate, private data server equivalent to the data server 300A in Figure 14 may also be provided.
[0095] According to this embodiment, for example, the fact that "the temperature of the transport box never deviated from a specific temperature range during its journey to base 3" can be proven using temperature data published by the data server 300C. In this case, if the verifier does not trust the data server 300C, they can verify that the disclosed data is not fabricated by following the data authenticity verification procedure described above.
[0096] [Modification of the Second Embodiment] In the second embodiment, the client device 200A was mounted in the transport box 700. In the modification, the transport box 700 is equipped with, for example, an RF-ID tag, and data reading and registration are performed by RF-ID reader / writers, which are client devices 200B, installed at each location.
[0097] [Client Device Configuration and Data Generation Method] Figure 17 shows an example configuration of client device 200B related to this modification. Client device 200B is based on the configuration of client device 200A in Figure 15. However, instead of the various sensors that generate raw data, it is equipped with an RF-ID reader. Raw data is generated when the RF-ID reader reads the data held or generated by the RF-ID tag.
[0098] Furthermore, this modified example assumes that data blocks are configured in association with the tag ID of the RF-ID tag, and the client device 200B does not necessarily possess the evidence data (data C') of the previous block necessary for generating data C (evidence data). Therefore, it is assumed that the evidence data (data C') of the previous block is obtained from the data server. However, data blocks may also be configured in association with the client device's identification information A (individual number).
[0099] Furthermore, if the index data (Data A) uses data generated by the client device, such as a local timestamp, multiple client devices may use the same index data (Data A). Therefore, it is necessary to obtain unique index data from the data server.
[0100] Other configurations and data generation methods are the same as those of client device 200A.
[0101] [Data Registration and Publication Method] Figure 18 shows the data management method related to this modified example.
[0102] Each time the transport box 700A moves from base 1 to base 2 to base 3, the client device 200B corresponding to each base is activated. １ ,200B ２ ,200B ３ Then read the RF-ID tag.
[0103] Each client device 200B １ , 200B ２ , 200B ３ The data is generated and registered with the data server 300C using the procedure shown in Figure 18.
[0104] First, client device 200B １ The RF-ID tag 1 reads the information and sends the tag ID to the data server 300C, thereby obtaining data A (index data) and data C' (evidence data from the previous block). At this time, the data server 300C receives client device 200B. １ The client device needs to be authenticated, for example by using its identification code, to prove that it has legitimate access rights to this data block.
[0105] Next, client device 200B １ The system then creates data C (evidence data) and data D (signature data) following the same procedure as described above, and registers them with data server 300C.
[0106] During data registration, the data server 300C verifies, according to the data authenticity verification procedure described above, that the data being registered is indeed from the desired client device and that the blocks contained in the data are connected to the previous blocks via evidence data. Only if this verification is successful does the data registration proceed.
[0107] These steps will be repeated each time the transport box 700A moves to a different location, on the client device 200B. ２ , 200B ３ This process is repeated sequentially to register the data.
[0108] [Third Embodiment] Next, a third embodiment of the present invention will be described. This embodiment relates to a case in which a manufacturer manages various types of 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 also be applied to so-called SBM (Software Bill of Materials) data that includes the dependencies of software libraries.
[0109] Figure 19 shows the data management system of this embodiment. In this embodiment, there is a factory 1 that processes member 1 and member 2 to produce product 1, a factory 2 that uses product 1 as a member (member 3) and processes it to produce product 2, and a factory 3 that uses product 2 as a member (member 4) and further processes it by adding member 5 to produce product 3. A client device 200C is installed in factories 1, 2, and 3. １ , 200C ２ , and 200C ３ A system is established to register the data to the data server 300C.
[0110] Each factory has one or more client devices for managing information about components and processing history, i.e., BOM information. The serial number of each component or product is used as data A (index data), and the BOM data is used as data B (raw data). This data is registered in the data server 300C in the same manner as in the first and second embodiments described above. 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.
[0111] [Method for Generating BOM Data] Figure 20 shows the method for generating BOM data. In this embodiment, it is assumed that a database will be constructed that can retrieve product BOM information traceable back to its components. For this reason, the 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 numbers 01 and 02, which are the identification codes for its components, components 1 and 2.
[0112] In this way, if BOM data for product 11 is needed, the BOM data for product 11 can be obtained first, and then the BOM data for serial numbers 01 and 02 can be obtained to acquire all the BOM data included in product 11. Similarly, the BOM data for products 2 and 3 can also be obtained by sequentially traversing the BOM data for their respective components.
[0113] The difference between this embodiment and other embodiments lies in whether the data blocks are connected sequentially in a single column or branch out, forming a so-called graph structure. This results in a difference in the number of evidence data (data C') from the previous block used to generate evidence data (data C). Specifically, while previous embodiments only had one evidence data (data C3') from the block immediately preceding a given evidence data (data C), this embodiment may have multiple such data. For example, in Figure 20, this applies to client device 200C. １When generating evidence data 11, two pieces of evidence data, evidence data 01 and evidence data 02, are required as data C'.
[0114] To prepare for such cases, it is desirable that the data structure of data C' in the first algorithm be able to accept multiple data inputs. In the case of ASN. 1, it should be a structure that can define a set of elements of the same type, such as SEQUENCE or SEQUENCE OF, and in the case of Protocol Buffers, it should be a structure such as map. Such a structure is also necessary for BOM data (data 2) for the same reasons.
[0115] [Method for verifying data authenticity] According to this embodiment, if a request is made, for example, to "prove that product 3 does not contain a certain chemical substance that requires labeling," the answer can be provided by disclosing the BOM data for all components traced from the BOM data 31. In this case, the verifier can verify that the disclosed data is not fabricated by following the data authenticity verification procedure described above.
[0116] [Fourth Embodiment] Next, a fourth embodiment will be described. In this embodiment, data is registered independently of the previous block.
[0117] Figure 21 shows the method for generating evidence data in the fourth embodiment. In this embodiment, the evidence data from the previous block is not considered when generating the evidence data.
[0118] Figure 22 shows an example of registration to the data server in the fourth embodiment.
[0119] In this example, similar to the example in Figure 13, the value data may be a set of index data and signature data, and the value data may include the key data of the previous block, so that a series of data can be obtained by sequentially traversing the blocks.
[0120] This concludes the description of the embodiments of this invention. It should be noted that this invention is not limited to the embodiments described above, and various modifications are possible without departing from its spirit.
[0121] 100 Data Management System 200 Client Device 201 Raw Data Generation Unit 202 Index Data Generation Unit 203 Evidence Data Generation Unit 204 Signature Data Generation Unit 205 Transmit / Receive Unit 300 Data Server 301 Database 302 Verification Data Generation Unit 303 Evidence Data Restoration Unit 304 Data Registration Management Unit 305 Transmit / Receive Unit 400 Verification Device 401 Evidence Data Generation Unit 402 Evidence Data Restoration Unit 403 Verification Unit 404 Transmit / Receive Unit 500 Communication Network 700 Transport Box 1000 Computer 1001 CPU (Processor) 1002 Main Memory 1003 External Interface 1004 External Storage Device 1005 Application
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 supplied from the client device, connected via a communication network, wherein the client device is assigned client device identification information for uniquely identifying the client device and a secret key associated with the client device, and the client device has evidence data generation means that, for each of the sequentially generated or received data to be stored, applies a predetermined hash function to first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each data to be stored, the data to be stored, and preceding data as elements, thereby generating a hash value as evidence data, wherein for the first data to be generated or received to be stored, the preceding data is predetermined start data, and for data to be generated or received thereafter, the preceding data is the evidence data that was immediately preceding and generated by the evidence data generation means, and signature data generation means that generates signature data using the secret key on the evidence data generated by the evidence data generation means, For each of the data to be stored that is generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device, and the data storage device includes storage means used to store the client device identification information, the index data, 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 by the client device.Verification data generation means that, for each piece of data to be stored that is sequentially generated or received by the client device, receives the client device identification information, the data to be stored, and the signature data of the evidence data supplied from the client device, as well as unique index data individually assigned to each piece of data to be stored, and, except for the first piece of data to be stored, retrieves the evidence data generated for the previous piece of data to be stored from the storage means based on the index data assigned to the previous piece of data to be stored, and generates a hash value as verification data for a second integrated data which is formed by integrating at least the evidence data generated for the previous piece of data to be stored, the client device identification information, the index data, and the data to be stored as elements, using a predetermined hash function and a corresponding hash function, wherein for the first piece of data to be stored that is sequentially generated or received by the client device, the verification data generation means uses the predetermined start data instead of the evidence data generated for the previous piece of data to be stored, and evidence data recovery means that recovers the evidence data from the signature data of the evidence data using a public key associated with the client device. A data management system characterized by comprising: a storage management means that compares the verification data output from the verification data generation means with the evidence data restoration results output from the evidence data restoration means, verifies, based on the comparison results, whether the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the unique index data individually assigned to each data to be stored are authentic, and based on the verification results, stores and manages the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, the corresponding evidence data, and the unique index data individually assigned to each data to be stored as authentic data in the storage means.
2. The data management system according to claim 1, wherein the client device generates the index data and supplies it to the data storage device.
3. The data management system according to claim 1, wherein the data storage device generates the index data and supplies it to the client device.
4. The data storage device described above stores data in a key-value format, according to claim 1.
5. The data management system according to claim 4, which generates key data from the above index data and the above signature data, and uses the above storage target data, the above evidence data, the above client device identification information, and the key data of the previous data as value data.
6. The above data management system is connected to the above data storage device via the above communication network and further comprises a data verification device that verifies the authenticity of the data stored in the above data storage device, and the above data verification device is A data management system according to claim 1, which receives the evidence data of the block immediately preceding the scope to be verified, the client device identification information, the index data, and the data to be stored for the blocks within the scope to be verified, the signature data of the last block within the scope to be verified, and the public key corresponding to the private key, and for each block within the scope to be verified, applies a predetermined hash function to a third integrated information which is formed by integrating the start data or evidence data of the block immediately preceding the block, the client device identification information, the index data, and the data to be stored for the block as elements, in order from the preceding block, to generate a hash value as the evidence data of the block, and further decrypts the evidence data generated for the last block using the public key from the evidence data generated for the last block and the signature data of the last block, and determines the authenticity of the data of the blocks within the scope to be verified by comparing the evidence data generated by the hash function and the evidence data decrypted with the public key.
7. The data management system according to claim 1, wherein in addition to the data storage device, it has a data publishing device, the data publishing device stores data in a key-value format, generates key data from the index data and the signature data, and uses the stored data, the evidence data, the client device identification information, and the key data of the previous data as value data.
8. The data management system according to claim 7, wherein the client device is associated with a certification body, and the data to be stored is a description of the registered business content of the certification body.
9. The data management system according to claim 1, wherein in addition to the data storage device, it has a data publishing device, the data publishing 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 stored data, the evidence data and the key data of the previous data as value data.
10. The data management system according to claim 1, wherein the client device is equipment used in connection with the transportation of goods, and the data to be stored includes transportation history.
11. The data management system according to claim 10, wherein the above-mentioned device comprises an RF-ID reader / writer, and the RF-ID reader / writer is used to read and register data.
12. The data management system according to claim 10, wherein the above-mentioned equipment is a transport box.
13. The data management system according to claim 1, wherein the data to be stored is a Bill of Materials (BOM).
14. The data management system according to claim 1, wherein the data to be stored is an SBOM.
15. 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 supplied from the client device, connected via a communication network, wherein the client device is assigned client device identification information for uniquely identifying the client device and a secret key associated with the client device, and the client device has evidence data generation means that, for each of the sequentially generated or received data to be stored, applies a predetermined hash function to first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each of the data to be stored, the data to be stored, and preceding data as elements, thereby generating a hash value as evidence data, wherein for the first data to be generated or received to be stored, the preceding data is predetermined start data, and for data to be generated or received thereafter, the preceding data is the evidence data that was immediately preceding and generated by the evidence data generation means, and signature data generation means that generates signature data using the secret key on the evidence data generated by the evidence data generation means, A data management system characterized in that, for each of the data to be stored which is generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device, and the data storage device has storage means for storing the client device identification information, the index data, the data to be stored, the evidence data, and the signature data of the evidence data for each of the data to be stored which is generated or received sequentially by the client device.
16. In 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 supplied from the client device in a storage device, connected via a communication network, the client device is assigned client device identification information for uniquely identifying the client device and a secret key associated with the client device, and the client device: For each of the sequentially generated or received data to be stored, it applies a predetermined hash function to a first integrated data which is formed by integrating at least the client device identification information, a unique index data individually assigned to each data to be stored, the data to be stored, and preceding data as elements, to generate a hash value as evidence data, wherein for the first data to be generated or received, the preceding data is predetermined start data, and for subsequent data to be generated or received, the preceding data is the evidence data that was generated immediately before; it generates signature data on the evidence data using the secret key;For each of the data to be stored that is generated or received sequentially, the client device identification information, the index data, the data to be stored, and the signature data of the evidence data are supplied to the data storage device, and the data storage device comprises a storage device used to store the client device identification information, the index data, 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 by the client device, and furthermore, the data storage device: For each piece of data to be stored that is sequentially generated or received by the client device, the client device identification information, the data to be stored, the signature data of the evidence data, and a unique index data assigned individually to each piece of data to be stored are received from the client device; and, except for the first piece of data to be stored that is generated or received, the evidence data generated for the previous piece of data to be stored is retrieved from the storage device based on the index data assigned to the previous piece of data to be stored; a hash value is generated as verification data for a second integrated data which is formed by integrating at least the evidence data generated for the previous piece of data to be stored, the client device identification information, the index data, and the data to be stored as elements, using the predetermined hash function and a corresponding hash function; for the first piece of data to be stored that is generated or received, the predetermined start data is used instead of the evidence data generated for the previous piece of data to be stored; and a public key operation is performed on the signature data of the evidence data using the public key associated with the client device;A data management system characterized by being configured to compare the above verification data with the result of the public key calculation on the above signature data, and based on the comparison result, verify whether the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, and the unique index data individually assigned to each data to be stored are authentic, and based on the verification result, store and manage the client device identification information supplied from the client device, the data to be stored, the signature data of the evidence data, the corresponding evidence data, and the unique index data individually assigned to each data to be stored as authentic data in the storage device.