Distributed ledger-based cryptographic systems and methods for improving data integrity

Abstract

This invention provides a distributed ledger-based cryptographic system, method, and data recording device for improving data integrity. [Solution] The ecosystem that improves data integrity using a distributed ledger includes numerous network node managers managing transactions on both the distributed integrity ledger and the distributed identity ledger, data recording devices, manufacturers of the devices, users of the devices, data centers that store the recorded data fragments, and verifiers that need to verify the authenticity of the recorded data. The distributed integrity ledger is used to store commitments generated by data recording devices and to verify the authorization of the recorded data fragments. In addition, commitments cannot track or link to personal information, so even if commitments are made public, the possibility of privacy violations is minimized.

Description

Technical Field

[0004]

[0001] (Cross - reference to Related Applications) This application claims priority to U.S. Provisional Patent Application No. 63 / 088,412, filed on October 6, 2020, entitled "BLOCKCHAIN BASED MEDIA ANTI - TAMPERING METHODS AND SYSTEMS".

[0002] This application claims the benefit of U.S. Non - Provisional Patent Application No. 第16 / 801,114, filed on February 25, 2020, entitled "CREDENTIAL VERIFICATION AND ISSUANCE THROUGH CREDENTIAL SERVICE PROVIDERS", which is hereby incorporated by reference in its entirety.

[0003] The present invention relates to a blockchain - based cryptographic system and method for improving data integrity and privacy. More specifically, it relates to a blockchain - based cryptographic system and method for ensuring the integrity and privacy of private data generated by a data recording device and remotely stored in a remote data storage area.

Background Art

[0004] Note: There seems to be an error in the original text where "第16 / 801,114" in the English translation of ID=11 should be corrected to "16 / 801,114" for accurate representation. The corrected translation for ID=11 is: This application claims the benefit of U.S. Non - Provisional Patent Application No. 16 / 801,114, filed on February 25, 2020, entitled "CREDENTIAL VERIFICATION AND ISSUANCE THROUGH CREDENTIAL SERVICE PROVIDERS", which is hereby incorporated by reference in its entirety.The emergence of distributed ledger technology (DLT), including blockchain, provides a solution to improve data integrity. DLT is trusted because it is extremely difficult, or even impossible, to alter transactions recorded on such a distributed ledger across a network of nodes. For this reason, various blockchain confidentiality methods have been implemented to provide secure transactions across the entire network. Blockchain itself can be seen as an open distributed ledger on which transactions can be recorded between parties. After blocks in a blockchain are recorded and concatenated, the data in any given block cannot be altered or tampered with without altering all other blocks; therefore, blockchain is suitable for many record-keeping activities, such as cryptocurrencies. However, DLTs such as blockchain are also secure and transparent because transactions are recorded on a large number of blocks or network nodes that form a distributed transaction consensus network. As a result, recording data itself on a distributed ledger can raise privacy issues or even violate relevant regulations. Moreover, there have been few DLT-based cryptographic systems and methods for maintaining the integrity and privacy of data generated by data recording devices and remotely stored in remote data storage areas. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] U.S. Provisional Patent Application No. 63 / 088,412 [Patent Document 2] U.S. Nonprovisional Patent Application No. 16 / 801,114 [Overview of the project] [Problems that the invention aims to solve]

[0006] Therefore, the present invention aims to implement DLT technology that protects the integrity of data generated by data recording devices such as surveillance cameras, drive recorders, or mobile devices. [Means for solving the problem]

[0007] This disclosure relates to a distributed ledger-based cryptographic system and method for improving data integrity. In the age of the Internet of Things (IoT), various types of data are recorded at any given moment by different devices and spread across various wired and wireless networks. In addition, advanced data processing technologies further make it possible that data recorded by data recording devices can be easily corrupted, forged, fabricated, tampered with, or altered without authorization. As already mentioned, distributed ledger technologies (DLTs), including blockchain, offer a solution for improving data integrity.

[0008] This disclosure describes a system and method for generating and storing commitments in a distributed ledger. A commitment is a cryptographic algorithm that allows one party to commit a chosen value or statement while keeping the other party's chosen value or statement hidden, and has the ability to later reveal the committed value. A commitment is binding because the committing party can no longer change the chosen value or statement. In this case, the chosen statement is a data signature generated by a data recording device that signs a data fragment. By storing commitments in a distributed ledger, it becomes extremely difficult, or even impossible, to alter the commitment. In addition, the committed value or statement, such as the data signature, is also immutable. In the future, the data signature is verified by revealing the commitment. The authenticity of the data fragment is then verified. At the same time, the commitment does not contain any personal information, is untrackable, and cannot be linked to data fragments recorded by data recording devices such as digital video recorders.

[0009] In one embodiment, an ecosystem for improving data integrity using a distributed ledger may include a distributed integrity ledger, a distributed identity ledger, a number of network node managers managing transactions on both ledgers, data recording equipment, manufacturers of the equipment, users of the equipment, a data center storing the recorded data fragments, and verifiers who need to verify the authenticity of the recorded data.

[0010] In one embodiment, a distributed integrity ledger maintained by a first distributed transaction consensus network ("first distributed network") is used to store commitments generated by data recording devices and verify the authenticity of recorded data fragments. A distributed identity ledger maintained by a second distributed transaction consensus network ("second distributed network") is used to store DIDs (distributed identifiers), credential schemas, credential definitions, and public keys associated with credential holders and credential issuers to verify the identification of users, data centers, and verifiers. Multiple network node managers may manage nodes in the first and second distributed networks, respectively. As a result, network node managers may record transactions and retrieve information from both the distributed integrity ledger and the distributed identity ledger.

[0011] In one embodiment, the data recording device may be any device capable of recording data and transmitting the data to other relevant parties by various wired or wireless means. In one embodiment, the data recording device may be a digital recorder or dashcam that records video clips of surrounding traffic conditions.

[0012] In one embodiment, the manufacturer may store the initial device certificate, the device signing private key and public key, and any other device-related information within the data recording device. After purchasing the data recording device, the user must register the device with the manufacturer. The user must also establish a DID, i.e., user identification, in the distributed identity ledger. The user can then begin recording data fragments using the data recording device.

[0013] In one embodiment, each recorded data fragment is encrypted with a data encryption key, and the encrypted data fragment is transmitted to a data center for storage. The data recording device also generates a data signature, a commitment string, and a commitment. The data signature and commitment string may be stored in the data center. The commitment may be recorded in a distributed integrity ledger through a network node manager.

[0014] In one embodiment, the user may initiate a verification procedure in which the verifier ultimately receives a data encryption key, encrypted data fragments, a commitment, a data signature, and a commitment string. The verifier, such as a judge / court, may then use the data encryption key to decrypt the encrypted data fragments, use the data signature to verify the authenticity of the recorded data, use the commitment and commitment string to verify the data signature, and query the distributed integrity ledger to verify the commitment. [Brief explanation of the drawing]

[0015] [Figure 1] This is a schematic diagram of an ecosystem for improving data integrity using a distributed ledger, according to an embodiment of the present invention. [Figure 2] This is a schematic diagram of the manufacturing stage of a data recording device using a distributed ledger-based cryptographic system and method according to this embodiment of the present invention. [Figure 3] This is a schematic diagram of the registration stage of a data recording device in a distributed ledger-based cryptographic system and method according to this embodiment of the present invention. [Figure 4] This is a schematic diagram of the data recording stage of a distributed ledger-based cryptographic system and method according to this embodiment of the present invention. [Figure 5] This is a schematic diagram of the verification stage of a distributed ledger-based cryptographic system and method according to this embodiment of the present invention. [Modes for carrying out the invention]

[0016] The technical terms used in the following descriptions are intended to be interpreted in the broadest reasonable manner, even if they are used in connection with detailed descriptions of certain specific embodiments of the technology. Certain terms may even be emphasized below, but any technical terms intended to be interpreted in any restricted manner are specifically defined as such in this “Modes for Carrying Out the Invention” section.

[0017] This disclosure relates to a distributed ledger-based cryptographic system and method for improving data integrity. In the age of the Internet of Things (IoT), various types of data are recorded at any given moment by different devices and spread across various wired and wireless networks. In addition, advanced data processing technologies also mean that data recorded by data recording devices can be easily corrupted, forged, fabricated, tampered with, or altered without authorization. The emergence of distributed ledger technologies (DLTs), including blockchain, offers a solution to improve data integrity. DLTs are trusted because it is extremely difficult, or even impossible, to alter transactions recorded on such a distributed ledger across a network of nodes. However, DLTs should also be transparent because they record transactions on a large number of network nodes that form a distributed transaction consensus network. As a result, recording the data itself on a distributed ledger can create privacy issues or even violate relevant regulations.

[0018] The present disclosure describes a system and method for generating a commitment and storing the commitment in a distributed ledger. A commitment is an encryption algorithm that allows one party to commit while hiding a selected value or statement from the other party, and has the ability to later reveal the committed value. A commitment is binding because the committing party can no longer change the selected value or statement. In this case, the selected statement is a data signature generated by a data recording device that signs a data fragment. Recording the commitment in a distributed ledger makes it very difficult or even impossible to modify the commitment. In addition, committed values or statements such as data signatures cannot be changed either. In the future, the data signature is verified by revealing the commitment. Then the authenticity of the data fragment is verified. At the same time, the commitment does not contain any personal information, cannot be traced, and cannot be linked to the data fragment recorded by a data recording device such as a digital video recorder.

[0019] As shown in FIG. 1, an ecosystem 100 for improving data integrity using a distributed ledger may include a distributed integrity ledger 110, a distributed identity ledger 120, a number of network node managers 130, 132, 134, 136 that manage transactions in both ledgers, a data recording device 150, a manufacturer 140 that makes the device, a user 160 that uses the device, a data center 170 that stores the recorded data fragments, and a verifier 180 that needs to verify the authenticity of the recorded data.

[0020] Using the distributed integrity ledger 110 maintained by the first distributed transaction consensus network ("the first distributed network") 115, the data recording device 150 stores the commitments generated and verifies the authenticity of the recorded data fragments. Using the distributed identifier ledger 120 maintained by the second distributed transaction consensus network ("the second distributed network") 125, the DIoriginD (distributed identifier), the certificate schema, the certificate definition, and the public keys related to the certificate owner and the certificate issuer are stored to verify the identities of the user 160, the data center 170, and the verifier 180. A number of network node managers 130, 132, 134, 136 may each manage the nodes within the first distributed network and the second distributed network. As a result, the network node manager may record transactions and retrieve information from both the distributed integrity ledger 110 and the distributed identifier ledger 120. The network node manager may be a telecommunications carrier such as ATT and Sprint in the United States, an organization operated by a government agency, or another DLT-related company such as TBCASOFT. One of the network node managers may be the network administrator. In one embodiment, certain functions are reserved for the network administrator, such as generating and recording DIDs in the distributed identifier ledger 120.

[0021] The data recording device 150 may be any device that can record data and transmit the data to other parties with which it has various wired or wireless relationships. In one embodiment, the data recording device 150 may be a digital recorder or a drive recorder that records video clips of the surrounding traffic conditions. The data recording device 150 may have a recording module for recording data fragments, a memory module for storing the original device certificate signed by the manufacturer, the device signature public key, and the device signature private key, and a processor module for generating a data encryption key, encrypting the data fragments using the data encryption key, and encrypting the data encryption key using the encryption public key.

[0022] The data recording device 150 is manufactured by manufacturer 140. As part of the manufacturing process, manufacturer 140 may store the initial device certificate, device signing private key and device signing public key, and any other device-related information in the data recording device 150. After purchasing the data recording device 150, user 160 must register the device with manufacturer 140. The user must also establish a DID, or user identifier, in the distributed identity ledger.

[0023] User 160 can then begin recording data fragments using the data recording device. Each recorded data fragment is encrypted with a data encryption key, and the encrypted data fragments are transmitted to the data center 170 for storage. The data recording device 150 also generates a data signature, a commitment string, and a commitment. The data signature and commitment string may be stored in the data center 170. The commitment may be recorded in the distributed integrity ledger 110 through the network node manager.

[0024] In various situations, it becomes necessary to verify the authenticity of recorded data. For example, in the case of a traffic accident where liability is in dispute, the user or judge / court may need to examine the video clip recorded by the dashcam at the time the accident occurred to verify the authenticity of the recorded video clip. In one embodiment, user 160 may initiate a verification procedure in which the verifier ultimately receives a data encryption key, encrypted data fragments, a commitment, a data signature, and a commitment string. As a result, the verifier, such as a judge / court, may decrypt the encrypted data fragments using the data encryption key, verify the authenticity of the recorded data using the data signature, verify the data signature using the commitment and commitment string, and verify the commitment by querying the distributed integrity ledger 110.

[0025] Manufacturers 140, data recording devices, users, data centers, and verifiers may need to interact with either or both of the distributed integrity ledger 110 and the distributed identity ledger 120 through one of the network node managers 130, 132, 134, or 136. Each may have its own network node manager. In another embodiment, two or more may share the same network node manager.

[0026] As shown in Figure 2, during the manufacturing phase, manufacturer 140 generates the initial equipment certificate by signing some product information, such as module number and serial number, using the manufacturer's private key. Manufacturer 140 has a pair of signing keys, namely a signing private key and a signing public key. As described above, the manufacturer uses its signing private key to sign the product information and generates equipment certificates, including the initial equipment certificate and updated equipment certificates. The manufacturer's signing public key is distributed to others, such as network node managers, who need to verify the authenticity of the information provided and signed by the manufacturer's signing private key. Manufacturer 140 also generates a pair of signing keys for the data recording device 150, namely an equipment signing private key and an equipment signing public key. Manufacturer 140 stores the initial equipment certificate, equipment signing private key, and equipment signing public key in the data recording device. Additional product information, such as warranty period, country of origin, and manufacturing date, may also be recorded in the data recording device 150. Manufacturer 140 may outsource manufacturing to an OEM or ODM. As a result, the steps described above may be implemented by other parties working on behalf of Manufacturer 140. In this disclosure, these other parties are considered to be Manufacturer 140.

[0027] Figure 3 illustrates the interaction between user 160, data recording device 150, manufacturer 140, network node manager 130, and distributed identification ledger 120 during the registration phase. User 160, after obtaining the data recording device 150, for example by purchase, starts the device registration phase by turning on the data recording device 150 and connecting it to manufacturer 140 for wired or wireless information transmission. In step 310, user 160 may be required to enter their own personal information into the data recording device 150, such as user ID, name, gender, and date of birth. In step 320, the data recording device 150 provides manufacturer 140 with the device signature public key, the initial device certificate, user-related information received from the user in step 310, and other device-related information, such as the vehicle registration number of the vehicle in which the drive recorder is installed. Some of the above information may be optional. For example, manufacturer 140 may still hold the device signature public key for the data recording device 150.

[0028] The manufacturer 140 then verifies the original device certificate by using the manufacturer's signing public key to confirm that the original device certificate is authentic. In step 330, after verification, the manufacturer 140 provides the network node manager 130 with the device signing public key, the original device certificate, and information related to the device and user. In step 340, the user 160 may also provide the network node manager 132 with personal information of the user, such as user ID, name, gender, and date of birth, as well as device-related information. As already described, the manufacturer 140 may use its own network node manager 130, and the user 160 may use its own network node manager 132. The manufacturer 140 and the user may also use the same network node manager (130 or 132).

[0029] As a result, the following processes must be carried out between the two network node managers 130 and 132. First, the network node manager (130 or 132) may verify the original device certificate by using the manufacturer's signing public key. Second, the network node manager may verify the user's DID via the distributed identity ledger 120, assuming that user 160 has already recorded their DID in the distributed identity ledger 120, and may also verify other user information via the user's identity credentials if necessary. If user 160 is new, a DID must be created for that user and recorded in the distributed identity ledger 120. The user's DID serves as a user identifier. An example of a DID is did.sovrin.V4SDRN84Z56d7YV7PBUe6f. Similar to a virtual wallet address, the DID is a globally unique identifier created by the owner of the DID or its network node manager. A DID has its associated public key and communication endpoint, i.e., an address to which messages can be delivered for DID identification. The owner of a DID's credentials holds the corresponding private key in their own wallet, which can be managed by the DID's network node manager.

[0030] Third, the network node manager (130 or 132) generates a pair of cryptographic keys, cryptographic secret keys, and cryptographic public keys for data recording. Fourth, the network node manager (130 or 132) issues a user device credentials certificate to user 160. The user device credentials certificate may include the following fields: the user's DID, device signing public key, cryptographic public key, device information, and user information. In one embodiment, the device information may include the drive recorder model number and serial number, the vehicle registration number of the vehicle in which the drive recorder is installed, and the vehicle model and color. The user information includes the driver's name, date of birth, and driver's license number. Fifth, the network node manager (130 or 132) generates a certificate relating to the user device credentials certificate, including the cryptographic public key. Step 350 is for the two network node managers 130 and 132 to provide each other with the relevant information to accomplish the five processes described above.

[0031] In step 360, the network node manager (130 or 132) provides the manufacturer 140 with the user's device credentials certificate, cryptographic public key, and user's DID. The manufacturer 140 may verify the user's device credentials certificate. After verification is successful, the manufacturer 140 generates an updated device certificate signed with the manufacturer's signing private key. The updated device certificate includes the user's DID, cryptographic public key, and device-related information. In step 370, the manufacturer 140 provides the data recording device 150 with the certificate for the updated device certificate, the user's DID, and the cryptographic public key.

[0032] Figure 4 illustrates the interaction between the data recording device 150, the data center, the network node manager 132, and the distributed integrity ledger 110 during the recording phase. When the recording function of the data recording device 150 is activated, the data recording device 150 begins recording data fragments. First, the data recording device 150 generates a data encryption key for the recorded data fragment, then encrypts the recorded data fragment to derive an encrypted data fragment. Second, the data recording device 150 encrypts the data encryption key using a cryptographic public key to generate an encrypted data encryption key. Third, the data recording device 150 signs the recorded data fragment using a device signing private key to generate a data signature. Fourth, the data recording device 150 generates a commitment string. The commitment string may be a random number, such as a 256-bit digit like ba3253876aed6bc22d4a6ff53d8406c6ad864195ed144ab5c87621b6c233b548. The data recording device 150 then uses the commitment string to generate a commitment and lock the data signature. An example of a commitment is 3627909a29c31381a071ec27f7c9ca97726182aed29a7ddd2e54353322cfb30a. Fifth, the data recording device 150 generates a commitment signature by signing the commitment using the device signing secret key.

[0033] In step 410, the data recording device 150 provides the data center 170 with encrypted data fragments, encrypted data encryption keys, data signatures, commitments, and commitment strings for storage. In some situations, updated device certificates and associated device information may also be provided from the data recording device 150 to the data center 170. In step 420, the data recording device provides the commitments, commitment signatures, updated device certificates, and device-related information to the network node manager 132.

[0034] The network node manager 132 first verifies the updated device certificate by using the manufacturer's signing public key, and then verifies the commitment by using the commitment signature and the device signing public key. After verification, the network node manager 132 writes (records) the commitment to the distributed integrity ledger 110. In this case as well, the network node manager at the recording stage may be any network node manager.

[0035] Figure 5 illustrates the interaction between user 160, data center 170, verifier 180, their corresponding network node managers 132, 134, and 136, distributed integrity ledger 110, and distributed identity ledger 120 during the verification phase. In one embodiment, in step 510, user 160 initiates the verification phase by providing data center 170 with proof of the user's identity credentials. The data center verifies the proof via its network node manager 134, which accesses the distributed identity ledger 120. After verifying the proof, in step 515, data center 170 provides user 160 with a commitment and possibly further metadata. User 160 obtains proof of the user's equipment credentials via its network node manager 132, which accesses the distributed identity ledger 120. User 160 signs the commitment using the user's signing private key to generate the user's authorization. In step 520, user 160 provides verifier 180 with the commitment, proof of user identity credentials, and user authorization. In step 525, verifier 180 verifies the proof of user identity credentials and user authorization via its network node manager 136, which has access to the distributed identity ledger 120. Verifier 180 then searches for the commitment via its network node manager 136, which has access to the distributed integrity ledger 110, and confirms its existence. After verification and confirmation, verifier 180 signs the commitment and user authorization using the verifier's signing private key to generate the verifier's authorization. In step 530, verifier 180 provides the commitment, proof of verifier identity credentials, user authorization, and verifier's authorization to data center 170. In step 535, data center 170 verifies such information via its network node manager 134, which has access to both distributed ledgers 110 and 120. After verification, data center 170 uses its own signing secret key to sign the commitment, user authorization, and verifier authorization, thereby generating the data center authorization.In step 540, the data center 170 provides the user 160 and the verifier 180 with the authorization of the data center. At the same time, the data center 170 also provides the user with the encrypted data encryption key. At the same time, the data center 170 also provides the verifier with the encrypted data fragment, data signature, and commitment string.

[0036] Upon receiving authorization for the data center and the encrypted data encryption key, in step 545, the user obtains the cryptographic secret key from the network node manager, decrypts the encrypted data encryption key, and ultimately derives the data encryption key. In step 550, user 160 provides the data encryption key to the verifier. The verifier then verifies the authorization for the data center, decrypts the encrypted data fragments to derive the original data fragments, verifies the authenticity of the data fragments by data signatures, and verifies the data signatures by commitments.

[0037] The following is an example of pseudocode to implement the method described above. ********************* ssk: Signing private key spk:Signing public key esk: Cryptographic private key epk: public key encryption aes_key: Data encryption key cipher key: encrypted data encryption key cipher data: encrypted data fragments sig_com: Commitment Signature signature: data signature carrier: Network Node Manager

[0038] ***Carrier (Network Node Manager)*** class Carrier { constructor(id_chain, data_chain) { carrier.id_chain = id_chain carrier.data_chain = data_chain spk, ssk = DigitalSignature.key_generation() carrier.spk = spk carrier.ssk = ssk carrier.did = carrier.create_did(spk) } function create_did() { return carrier.id_chain.create_did() } function issue(did, credential_detail) { credential = Credential.issue(carrier.ssk, (did, credential_detail)) carrier.add(did, credential) return credential } function prove(credential) { return Credential.proof(credential) } function sign(document) { return DigitalSignature.sign(carrier.ssk, document) } function certify_manufacturer(manufacturer_spk) { return carrier.sign(manufacturer_spk) } function register_device(user_did, device_spk, device_certificate) { if device_certificate is valid do / / Generate a pair of encryption keys epk, esk = AsymmetricEncryption.key_generation() / / Issue a certificate of eligibility and connect the device to the user. credential = carrier.issue(did, (spk, epk)) / / Generate a certificate based on the certificate of qualification cred_proof = carrier.prove(credential) carrier.add(user_did, device_spk, device_certificate, credential, epk, esk) data_center = Allocate a datacenter. return cred_proof, did, epk, data_center end } function get_cred_proof(user_spk) { find credential from user_spk return carrier.prove(credential) } function decrypt(cipher_key, device_spk) { Find esk by device_spk. aes_key = AsymmetricEncryption.decrypt(esk, cipher_key) return aes_key }}

[0039] ***Data Center*** classDatacenter { constructor(carrier) { spk, ssk = DigitalSignature.key_generation() datacenter.spk = spk datacenter.ssk = ssk datacenter.carrier = carrier datacenter.did = carrier.create_did() carrier.issue(did, spk) datacenter.data_chain = carrier.data_chain } function upload(cipher_data, cipher_key, signature, com, com_r, sig_com, device.certificate) { / / Check 1: The certificate is valid. if device_certificate is not valid exit() end / / Check 2: The signature sig_com is valid. device_spk = device_certificate.get_public_key() if DigitalSignature.verify(device_spk, (com, sig_com)) is not valid do exit() end / / Check 3: Commitment.com is valid. if Commit.verify(com, com_r, signature) is not valid do exit() end / / If all checks pass, save the record. data_center.add(cipher_data, cipher_key, signature, com, com_r) / / Pass some information to the data_chain datacenter.data_chain.upload(com, sig_com, device_certificate) } function sign(document) { return DigitalSignature.sign(data_center.ssk, document) } function select_data(cred_proof) { if Credential.verify(cred_proof) is not valid do exit() end / / The user selects one record and obtains its COM. if data_center.carrier.data_chain.check(com) does not exist do exit() end return.com } function authorize(com, cred_proof_verifier, auth_1, auth_2) { / / Check 1: User cred_proof is valid. if Credential.verifier(cred_proof_verifier) ​​is not valid do exit() end / / Check 2: Signature auth_1 is valid verifier_spk = cred_proof_verifier.get_public_key() if DigitalSignature.verify(verifier_spk, (com, auth_1), auth_2) is not valid do exit() end auth = data_center.sign(com, auth_1, auth_2) return auth } function get_record(com) { find (cipher_data, cipher_key, signature, com, com_r) from com return (cipher_data, cipher_key, signature, com, com_r) } }

[0040] ***Equipment (Data Recording Equipment)*** class Device { constructor(spk, ssk, certificate) { device.spk = spk device.ssk = ssk device.certificate = certificate } function register(did, epk, data_center) { device.did = did device.epk = epk device.data_center = data_center } function record() { video = device.record() aes_key = AES.key_generation() cipher_data = AES.encrypt(aes_key, video) cipher_key = AsymmetricEncryption.encrypt(device.epk, aes_key) signature = DigitalSignature.sign(device.ssk, video) com, com_r = Commit.commit(signature) sig_com = DigitalSignature.sign(device.ssk, com) device.data_center.upload(cipher_data, cipher_key, signature, com, com, sig_com, device.certificate)) } }

[0041] ***identity_chain(Distributed Identity Ledger)*** class IdentityBlockchain { constructor() { } function create_did() { Generate did. ​​​​}

[0042] ***integrity_chain (distributed integrity ledger)*** class IntegrityBlockchain { constructor() { } function upload(com, sig_com, device_certificate) { / / Check 1: The certificate is valid. if device_certificate is not valid exit() end / / Check 2: The signature sig_com is valid. device_spk = device_certificate.get_public_key() if DigitalSignature.verify(device_spk, com, sig_com) is not valid do exit() end / / If all checks pass, save the commitment. integrity_blockchain.save(com) } function check(com) { return com on integrity_blockchain or not } }

[0043] ***main*** / / Initialize two blockchains, id_chain and data_chain. id_chain = IdentityBlockchain() data_chain = IntegrityBlockchain() / / Initialize carrier and manufacturer manufacturer_carrier = Carrier(id_chain, data_chain) manufacturer = Manufacturer(manufacturer_carrier) certificate = manufacturer_carrier.certify_manufacturer(manufacturer.epk) manufacturer.set_certificate(certificate) / / Initialize user and device user_carrier = Carrier(id_chain, data_chain) user = User(user_carrier, car_info, driver_info) device = manufacturer.manufact() / / Register the device with the user user.register_device(device, manufacturer) / / Record video device.record() / / Initialize the verifier verifier_carrier = Carrier(id_chain, data_chain) verifier = Verifier(verifier_carrier) / / Verify the recorded video / / 1.3 Granting of Party Authority / / 1-1 Get commitments from the data center data_center = device.data_center cred_proof_user = user.get_cred_proof() com = data_center.select_data(cred_proof_user) / / 1-2 The user grants access permissions. auth_1 = user.authorize(com) / / 1-3 The verifier grants access permissions. auth_2, cred_proof_verifier = verifier.authorize(com, cred_proof_user, auth_1) / / 1-4 The data center grants access privileges. auth = data_center.authorize(com, cred_proof_verifier, auth_1, auth_2) (cipher_data, cipher_key, signature, com, com_r) = data_center.get_record(com) / / 2. Deliver the records aes_key = user.decrypt_aes_key(auth, auth_2, cred_proof_verifier, cipher_key) cred_proof_device = user.carrier.get_cred_proof(user.device.spk) / / 3. Verify the integrity of the data. verifier.decrypt_video(aes_key, cipher_data, cred_proof_device, signature, com)

[0044] ***Manufacturer*** class Manufacturer { constructor(carrier) { spk, ssk = DigitalSignature.key_generation() manufacturer.spk = spk manufacturer.ssk = ssk manufacturer.carrier = carrier manufacturer.did = carrier.create_did() carrier.issue(did, spk) } function sign(document) { return DigitalSignature.sign(manufacturer.ssk, document) } function set_certificate(certificate) { manufacturer.certificate = certificate } function manufact() { spk, ssk = DigitalSignature.key_generation() certificate = manufacturer.sign(spk) device = Device(spk, ssk, certificate) return device } function register(user_carrier, device_spk, device_certificate, user_car_info, user_driver_info) { if device_certificate is valid do / / Re-instruct the user to log in to user_carrier user_did = login() cred_proof, did, epk, data_center = user_carrier.register_device(user_did, device_spk, device_certificate) if Credential.verify(cred_proof) == true do return did, epk, data_center end end } }

[0045] ***User*** class User { constructor(carrier, car_info, driver_info) { user.car_info = car_info user.driver_info = driver_info spk, ssk = DigitalSignature.key_generation() user.spk = spk user.ssk = ssk user.carrier = carrier user.did = carrier.create_did() carrier.issue(did, spk) } function register_device(device, manufacturer) { Plug the device into a PC. Connect to manufacturer's website. did, epk, data_center = manufacturer.register(user.carrier, device.spk, device.certificate, user.car_info, user.driver_info) device.register(did, epk, data_center) user.add(device) } function get_cred_delivery() { return user.carrier.get_cred_proof(user.spk) } function sign(document) { return DigitalSignature.sign(user.ssk, document) } function authorize(com) { if user.carrier.data_chain.check(com) exists do return user.sign(com) end } function decrypt_aes_key(auth, auth_2, cred_proof_verifier, cipher_key) { / / Check 1: User cred_proof is valid. if Credential.verifier(cred_proof_verifier) ​​is not valid do exit() end / / Check 2: Signature auth_1 is valid verifier_spk = cred_proof_verifier.get_public_key() if DigitalSignature.verify(verifier_spk, (com, auth_1), auth_2) is not valid do exit() end / / Check 3: The signature authentication is valid. data_center_spk = device.data_center.spk if DigitalSignature.verify(data_center_spk, (com, auth_1, auth_2), auth) is not valid do exit() end aes_key = user.carrier.decrypt(cipher_key, device_spk) return aes_key } }

[0046] ***Verifier*** class Verifier { constructor(carrier) { spk, ssk = DigitalSignature.key_generation() verifier.spk = spk verifier.ssk = ssk verifier.carrier = carrier verifier.did = carrier.create_did() carrier.issue(did, spk) } function sign(document) { return DigitalSignature.sign(verifier.ssk, document) } function authorize(com, cred_proof_user, auth_1) { / / Check 1: User cred_proof is valid. if Credential.verifier(cred_proof_user) is not valid do exit() end / / Check 2: Signature auth_1 is valid user_spk = cred_proof_user.get_public_key() if DigitalSignature.verify(user_spk, com, auth_1) is not valid do exit() end auth_2 = verifier.sign(com, auth_1) cred_proof_verifier = verifier.carrier.get_cred_proof(verifier.spk) if verifier.carrier.data_chain.check(com) does not exist do exit() end return auth_2, cred_proof_verifier } function decrypt_video(aes_key, cipher_data, cred_proof_device, signature, com) { / / Check 1: The user's device cred_proof_device is enabled. if Credential.verifier(cred_proof_device) is not valid do exit() end / / Check 2: Signature auth_1 is valid video = AES.decrypt(aes_key, cipher_data) device_spk = cred_proof_device.get_public_key() if DigitalSignature.verify(device_spk, video, signature) is not valid do exit() end / / Check 3: The record exists in data_cain if verifier.carrier.data_chain.check(com) does not exist do exit() end Accept the video with confidence. } } ********************

[0047] The above description of embodiments is provided to enable those skilled in the art to construct and utilize the subject matter. Various modifications of these embodiments will be readily apparent to those skilled in the art, and the novel principles and subject matter disclosed herein may be applied to other embodiments without employing innovative capabilities. The claimed subject matter as set forth in the claims is not intended to be limited to the embodiments shown herein, but should adhere to the broadest scope consistent with the principles and novel features disclosed herein. Additional embodiments are intended to fall within the spirit and true scope of the disclosed subject matter. Accordingly, the present invention is intended to include modifications and variations that fall within the scope of the appended claims and their equivalents.

Claims

1. A distributed ledger-based cryptographic method for improving data integrity, used by a network node manager. The steps include receiving a commitment from a data recording device managed by the user, which is generated to lock the data signature using the original device certificate signed by the manufacturer of the data recording device and a commitment string, and which is stored in a distributed integrity ledger to verify the authenticity of the data fragments recorded by the data recording device, The steps include verifying the initial device certificate and The steps include verifying user identification in a distributed identification ledger, or generating said user identification. A method for providing this.

2. The step of generating a private cryptographic key and a public cryptographic key for the data recording device. The method according to claim 1, further comprising:

3. Steps to generate a device credentials certificate for a user possessing the aforementioned cryptographic public key, and a certificate relating to the user's device credentials certificate. The method according to claim 2, further comprising:

4. The method according to claim 1, characterized in that the data recording device is a digital video recorder.

5. A distributed ledger-based cryptographic method for improving data integrity, used by a network node manager. The steps include receiving from a data recording device managed by a user, an updated device certificate signed by the manufacturer of the data recording device, a commitment generated to lock a data signature generated by signing a data fragment recorded by the data recording device using the device signing secret key, and a commitment signature generated by signing the commitment using the device signing secret key; The steps include verifying the updated device certificate using the manufacturer's signature public key, The steps include verifying the commitment by using the aforementioned commitment signature, If both verifications are valid, the steps include recording the commitment in the distributed integrity ledger maintained by the first distributed transaction consensus network, and A method for providing this.

6. The steps include receiving a request to confirm the aforementioned commitment and the aforementioned commitment recorded in the distributed integrity ledger, A step of confirming the existence of the commitment using the distributed complete ledger. The method according to claim 5, further comprising:

7. The steps include receiving a request for the encryption secret key of the data recording device and the authorization granted by the user, A step to verify the granting of the aforementioned permissions by the aforementioned user, The steps include providing the user with the encryption key in order to decrypt the encrypted data encryption key, and The method according to claim 5, further comprising:

8. A distributed ledger-based cryptographic method for improving data integrity in data recording devices, The steps include: signing the data fragments recorded by the data recording device to generate a data signature; The steps include generating a commitment string which is a random number, The steps include generating a commitment to lock the data signature using the aforementioned commitment string, and storing the commitment in the distributed integrity ledger maintained by the first distributed transaction consensus network through the network node manager, The steps include providing the network node manager with the device signature public key already stored in the data recording device, The second step involves receiving the cryptographic public key and user identification recorded in the distributed identity ledger maintained by the second distributed transaction consensus network from the network node manager. A method for providing this.

9. The steps include providing the manufacturer of the data recording device with the original device certificate stored in the data recording device, The steps include receiving an updated device certificate from the manufacturer of the data recording device, which includes the user identification and the cryptographic public key, and which is signed by the manufacturer. In a way to further enhance this, The device signature public key is provided to the network node manager through the manufacturer, and the cryptographic public key and user identification are received from the network node manager through the manufacturer. The method according to claim 8.

10. The steps include generating a data encryption key for the data fragment, The steps include: encrypting the data fragment using the data encryption key; The steps include: encrypting the data encryption key using the public encryption key; A step of generating a data signature by signing the data fragment using a device signing secret key, Steps to generate a commitment string, The steps include: generating a commitment to be recorded in a distributed integrity ledger maintained by a first distributed transaction consensus network by providing the aforementioned data signature and commitment string; A step of generating a commitment signature by signing the commitment using the aforementioned device signing secret key. The method according to claim 8, further comprising:

11. The method according to claim 8, characterized in that the data recording device is a digital video recorder.

12. A distributed ledger-based cryptographic method for verifiers to improve data integrity, The steps include receiving encrypted data fragments, data signatures of the data fragments, commitments, and commitment strings from a data center, and receiving data encryption keys from the user. The steps include: decrypting the encrypted data fragment using the data encryption key to obtain the data fragment; The steps include verifying the authenticity of the data fragment by using the aforementioned data signature and device signature public key, The steps include verifying that the aforementioned commitment is recorded in the distributed integrity ledger maintained by the first distributed transaction consensus network, A step of verifying the commitment by using the data signature and the commitment string. A method comprising: a data fragment being recorded by a data recording device; a commitment string being a random number; and a commitment being generated by locking the data signature using the commitment string.

13. The steps include receiving authorization from a user of the data recording device or from a data center storing the encrypted data fragment, the commitment, the data signature, and the commitment string, A step to verify the authorization using the user's signature public key or the data center's signature public key. The method according to claim 12, further comprising:

14. A data recording device, A recording module for recording data fragments, A memory module for storing the original device certificate signed by the manufacturer, the device signing public key, and the device signing private key, A processor module for generating a data encryption key, a commitment string, and a commitment, for encrypting the data fragment using the data encryption key, and for encrypting the data encryption key using the public encryption key. A data recording device comprising the following, characterized in that the commitment is generated by locking the data signature of the data fragment using the commitment string.

15. The data recording device according to claim 14, characterized in that the processor module generates a data signature, a commitment string, and a commitment to lock the data signature by signing the data fragment using the device signing secret key.

16. The data recording device according to claim 14, characterized in that the recording module is a digital video recorder.

Images