Equipment attribute verification method based on block chain and zero-knowledge proof

Abstract

The invention belongs to the technical field of information data security, and particularly relates to an equipment attribute verification method based on a block chain and zero-knowledge proof. The invention relates to four main roles: a data collector, a block chain platform, a data consumer as a certifier, and an authorization supervisor as a verifier. Through combination of a block chain technology and zero-knowledge proof, verification of inherent attributes and dynamic attributes of decentralized equipment is carried out, and data integrity and user privacy are ensured at the same time; a solution is provided for managing access permissions of equipment across different regions, wherein the access permissions are determined by factors such as equipment identities, user roles and geographic positions. The system reduces the burden of the block chain by using decentralized storage, realizes safe access verification through zero-knowledge proof, and does not expose sensitive data at the same time; according to the invention, more flexible and accurate equipment authentication can be realized, and the method is especially suitable for complex equipment management requirements in medical scenes.

Description

Technical Field

[0001] The present invention belongs to the technical field of information data security, and in particular relates to a device attribute verification method. Background Art

[0002] Most of the existing data access authorization and sharing solutions are server-centric, that is, they rely on trusted server control, which increases the security and privacy issues of data users. The existing decentralized access authorization method based on blockchain makes it difficult to perform fine-grained access authorization for different attribute characteristics while protecting the key information of the visitor. For example, in cross-border medical scenarios, different countries and regions need to be authorized and agreed by both parties to see specific eye health screening data information and reports. However, depending on the role of the visitor, which country, department, etc., whether it is a patient health manager or on-site medical staff, the granularity of the accessed information is different. Different data access content should be granted for different user levels. How to obtain permission to access data of the corresponding level without leaking the original attribute information of the accessing user, and how to design a privacy-protected and verifiable data sharing framework to simultaneously protect user privacy and data integrity are topics that need to be studied urgently.

[0003] In the existing zero-knowledge proof-based attribute feature verification, a constraint circuit is designed, the original data is used as a secret input, and the required attribute feature range is used as a public input. The original secret input data value is compared with the required attribute feature range (such as country, age, and access location) in the circuit to prove that a certain feature is met, and the authenticity of the original secret input data is verified by calculating the hash value of the secret input data in the circuit. However, calculating the hash value in the circuit requires a large number of constraint circuit gates, usually tens of thousands of constraint gate circuits, which affects the performance of the overall system.

[0004] Glossary:

[0005] Zero-knowledge proofs:

[0006] zk-SNARKs: zero-knowledge succinct non-interactive arguments of knowledge. Summary of the invention

[0007] The purpose of the present invention is to provide a device attribute verification method based on blockchain and zero-knowledge proof that ensures data integrity and user privacy at the same time, so as to solve the complexity and vulnerability problems of regional data management faced by centralized models in complex distributed environments.

[0008] The device attribute verification method based on blockchain and zero-knowledge proof provided by the present invention has a block diagram, see Figure 1 As shown in the figure, there are four main roles involved: (i) Data Collector, (ii) Blockchain platform, (iii) Data Consumer as Prover, and (iv) Authorization Regulator as Verifier. The devices here refer to handheld devices, smartphones, etc. used by data collectors to collect and access data. The specific steps include:

[0009] (I) Equipment registration, authentication and authorization. For the process, see Figure 2 shown.

[0010] Data Collector: Also the user of the device, registers the device and provides its attribute information, including metadata, user identity, registration location and timestamp.

[0011] During the device registration process, the SHA256 algorithm is used to generate a hash commitment to ensure data integrity and prevent tampering. The data record of each device is modeled as a tuple, and the tuple identifier of the i-th device is as follows: i = <id i ,Device i >, where id i It is the unique identifier of the device, while Devicei defines the attribute data of the device in detail.

[0012] To ensure the authenticity and immutability of the data, a verifiable data structure (ADS) of device attributes is constructed, and a Merkle Hash Tree (MHT) is further constructed to store the attribute data of the data collector's device. The use of the Merkle Hash Tree greatly reduces the space requirements for on-chain storage, because only the root value of the MHT (i.e., the mRoot value) needs to be stored on the blockchain. The ADS root value of this verifiable data structure cannot be tampered with on the blockchain, and it exists as a notarization of the original device attribute data.

[0013] The specific registration process is as follows:

[0014] (1) Device identity registration: The data collector’s terminal device first registers its identity with the blockchain-based data management system; the system generates a unique device fingerprint ID (i.e. Figure 1 Step ①);

[0015] (2) Data structure and storage: Device attributes are structured into a Merkle hash tree (i.e., the organizational form of the verifiable data structure ADS). A tree structure is built for each attribute of the device, which helps to achieve fine-grained data authorization and verification of device attributes. The blockchain stores ADS to ensure the integrity and tamper-proofness of query results. In order to reduce the storage space of the blockchain, multiple data records are classified into a Merkle hash tree (MHT), and only the root node of the MHT is stored. The system adopts an on-chain and off-chain collaborative storage architecture to optimize storage space. The tree root (mRoot value) of the ADS is uploaded to the blockchain as a notarization and integrity proof of the data, while the detailed device attribute data is stored in the off-chain database (i.e., Figure 1 Step ②);

[0016] (3) Decentralized registration and hash summary generation: The device undergoes a decentralized registration process through the blockchain, and in this process generates a unique hash summary as the device identifier; this hash summary not only uniquely identifies the device, but also ensures the integrity and authenticity of the device data during the registration process;

[0017] The device registration process ensures the integrity, authenticity and immutability of device data by combining technical means such as SHA256 algorithm, Merkle hash tree, on-chain and off-chain collaborative storage.

[0018] (II) Device Verification and Access Authorization Based on Device Attributes: The process is as follows (see Figure 3 shown):

[0019] (1) Initiating a request: The data consumer is the user who requests access to the data. It may also be the data collector, acting as the prover of the zero-knowledge proof, for example, a doctor or patient user who registers a terminal device and uploads data records. A user who has registered a terminal device and uploaded data records may later request access to specific data. The data consumer uses zk-SNARK to generate a zero-knowledge proof to prove that the registered attributes of the device are valid and that the location, time and user ID of the access are within the authorized scope. (See (IV) for the generation and verification process of the zero-knowledge proof.)

[0020] (2) Device attribute verification: The authoritative authorization management agency, as the verifier, receives the access request from the terminal device and calculates the hash value of the attribute information sent by the current requesting device through the SHA256 algorithm. At the same time, it obtains the ADS root hash value of the device registered with the unique identity fingerprint from the blockchain platform, compares it, and verifies it.

[0021] (3) Access authorization: The permission verification module in the smart contract will query the device's attribute set in the hash table based on the device identifier, which contains the device's identifier and target information to verify whether the device has the required permissions to perform the requested operation; if the device has the required permissions, the system will send the device an authorization license and an accessible data resource information table, allowing the device to perform the operation;

[0022] (4) The authoritative authorization management agency returns the relevant data (such as medical record data) to the requester based on the database (such as the medical record database) and the access authorization policy.

[0023] (3) Permission Management and Authorization;

[0024] During the device registration and authentication process, the generated hash summary is used as the unique fingerprint ID and data storage address of the device. The unique fingerprint ID is the identifier of the device. In the off-chain database, the identifier, attributes and user identity information of the device are stored in the hash table; the authorization agency creates a user ID list (userIDs) based on the fingerprint ID of the device. (For example, the user record of a patient in a medical scenario is as follows: pat ient record = {userID1, userID2, ...}; in order to prevent the PL list from being tampered with (for example, malicious personnel trying to steal unauthorized data), a Merkle hash tree is constructed for the user ID in userIDs, and the root of the tree is stored on the blockchain; in order to achieve authorized management of access under privacy protection, the access rights of the device are bound to the time range and geographic location information range, such as Range = {region1, region2, timeRange}; the authorization management agency further subdivides the user data and cross-validates it with the dynamic information and attribute mapping in the system to determine the data accessible to the device; different data consumers may access different resources; when the attributes of the device change, the system will regenerate the hash summary according to the new attributes, update the off-chain database, and delete the original device identification and attribute information;

[0025] The authorization authority acts as an authorization verifier and also a zero-knowledge proof verifier. It ensures the integrity of the data based on the ADS stored on the blockchain. Specifically, it uses the provided user ID list (userIDs) to reconstruct the ADS, calculates and compares it with the Merkle root node stored on the blockchain. In addition, it uses the public and private input attributes of the device to reconstruct the Merkle tree root node of the device attributes and compares it with the Merkle tree root mRoot associated with the device's unique ID on the blockchain. The verifier also uses zero-knowledge proof to verify the prover's device identity and access rights.

[0026] Based on the device attribute information used to access data, the range requirements of attribute values, and the non-interactive zero-knowledge proof system, a zero-knowledge proof constraint circuit is designed to transform the numerical attribute feature problem to be proved into an arithmetic circuit problem without leaking any information about the input record (see (IV) below) the zero-knowledge proof generation and verification process for details).

[0027] Furthermore, the present invention also includes:

[0028] (iv) Generation and verification of zero-knowledge proofs;

[0029] The secret input data of the designed circuit is the identity data for subsequent calculation operations. The public input: attribute feature requirements, the public commitment value used to verify the attribute data; circuit operation logic: whether the identity secret input data belongs to a certain range, whether the Hash commitment value corresponding to the identity secret data is consistent with the public commitment value;

[0030] Here, for the commitment value corresponding to the secret attribute data, there are two ways to constrain the circuit calculation logic: 1. If the verifier has great trust in the off-chain data management center, the prover can obtain the corresponding Hash commitment value from the off-chain data center based on the transaction uploaded to the blockchain by the current user identity information, and then declare it to be equal to the public commitment value; 2. If the verifier does not fully trust the off-chain data management center, or has very high requirements for the authentication security level of privacy data, the prover is required to calculate the Hash commitment value based on the user's secret input data and random numbers in the circuit calculation logic, and re-root the Merkle tree (ADS), and then declare it to be equal to the commitment value of the public root.

[0031] In the present invention, the generation algorithm flow of zero-knowledge proof is as follows:

[0032] Assume that Cx is a constraint circuit represented as an arithmetic circuit over a finite field F; λ is a security parameter used to generate public and private keys;

[0033] Generate two keys: proof key (pk) and verification key (vk); input security parameter 1λ , private input: {location, time, owner}, public input: {deviceID, deviceName, deviceAttribute i ,...,regionRange,timeRange,{userIDs}}; This scheme allows the prover to show the verifier that the accessed user ID is authorized within the specified region and time range by inputting public device attributes and sensitive private data; it includes the following algorithms:

[0034] Setup(1 λ ,Cx): key generation algorithm, input security parameter 1 λ (determines the security level, usually set to a power of a large integer to set security-related parameters such as key length), circuit Cx is a designed constraint circuit that outputs crs (public reference string), pk (proof key), and vk (verification key).

[0035] Zero-knowledge proof function zkProve(pk,<private input> ,<public input> ): zk proof algorithm, input pk, private input (such as sensitive attribute data) and public input (such as public device attributes, range, user ID), generate zero-knowledge evidence π by executing circuit Cx; private input private input = (region, time).

[0036] The algorithm is as follows:

[0037] public input={(deviceID,name,..),regionRange,timeRange,{patientIDs}}

[0038] π←zkProve(pk,private input,public input){

[0039] / / Prove that the region and time are within the set range

[0040] region in regionRange

[0041] time in timeRange

[0042] }

[0043] The verification function of zero-knowledge proof zkVerify(vk,π,<public input> ): Verification algorithm zkVerify, input vk, proof π and public input, output 1 if the verification is valid.

[0044] Blockchain verification algorithm: blockChainVerify(mRootPath, mRootblockchain), the verifier obtains the Merkle root node (mRoot) of the original device attribute from the blockchain to verify the integrity of the query result. This integrity verification includes verifying the integrity of the device attribute ADS and the authorized user ID.

[0045] Based on zk-SNARKs technology, it is proved that a data record that satisfies the secret input does exist and that the data item satisfies certain properties without leaking the patient's privacy data.

[0046] Data Owner: uploads data records to the blockchain. Each record forms a transaction, records each attribute value, calculates the Hash commitment value, and forms a Merkle hash tree. The Hash Root is chained as a transaction leaf node, and finally generates a Merkle Root.

[0047] Prover: Design the circuit file Cx, verify zkVerify (proof key, secret input, public input) to generate zero-knowledge proof evidence π, for example, secret input V2 (geographic location region), V5 (time time), public input (N1, N34, N6, Root). By proving the key, prove that the secret input data is within a certain range (proving that region belongs to regionRange and time belongs to timeRange in the circuit); and recalculate Root' in the circuit file, and prove that the calculated mRoot is equal to the original mRoot value stored on the blockchain.

[0048] Verifier: Verifies the secret key and public input. On the one hand, it verifies whether the zero-knowledge proof passes, and returns 1 if it passes, otherwise returns 0. On the other hand, it verifies the integrity of the data and sets the user's access authorization based on the verification result. For example, to verify whether the specific access location v2 of the device user is within the publicly defined area, whether the date v5 of the device visitor is within the range of the last month, etc., then in the designed circuit Cx, the correctness of the secret input value v2, the region range regionRange and v5 of the public input, and the time range timeRange of the public input are calculated to prove the correctness of the statement based on the circuit of the zero-knowledge proof; then, the verifier reconstructs the ADS, that is, reconstructs the merkle tree root mRoot with the hash commitment value Hash(v2) and Hash(v5) of the secret input value calculated according to the zero-knowledge proof, and the verification path N1, N34, N6, to verify the integrity of the input data, see. Figure 4 shown.

[0049] Data integrity verification of userIDs, the user list of authorized access to the device, see Figure 5 shown.

[0050] The present invention also includes designing two proof generation methods.

[0051] The first is non-strict verification. In the proof circuit, the prover directly extracts the Hash commitment value corresponding to the original data from the DC in the off-chain data center according to the transaction number Txid. There is no need to calculate the Hash value of the secret data in the circuit. This method can avoid the overhead of calculating the Hash value in the circuit. The prover sends the Hash commitment value corresponding to the secret data and the path Hash used to reconstruct the Merkle tree root to the verifier; the verifier ADS the tree root and compares the tree root value with the publicly input tree root value to verify the authenticity of the original data.

[0052] The second type is strict verification. In the constraint proof circuit, the prover recalculates the Hash commitment value of the secret input data based on the original secret input data Dw provided, and then reconstructs the ADS based on the Hash commitment value on the verification path. The root of the tree is then compared with the public input data, that is, the Hash commitment value used for verification, to verify the authenticity of the original data.

[0053] Beneficial effects of the present invention:

[0054] Data collection and application are critical to driving research and improving various industries. However, privacy and security issues, especially involving sensitive data, pose huge challenges. Traditional identity-based verification systems rely on centralized servers, but in complex distributed environments, centralized models face the complexity and fragility of regional data management, which makes these systems difficult to adapt. The privacy-preserving device verification method and system provided by the present invention are intended to address these challenges. By combining blockchain technology with zero-knowledge proof, the present invention proposes decentralized verification of inherent and dynamic properties of devices while ensuring data integrity and user privacy. The system provides a solution for managing device access rights across different regions, where access rights are determined by factors such as device identity, user role, and geographic location. The system uses decentralized storage to reduce the burden on the blockchain and achieves secure access verification through zero-knowledge proof without exposing sensitive data.

[0055] Compared with the existing decentralized authentication system of blockchain, the present invention provides a more flexible and accurate device authentication mechanism through decentralized device registration and verification based on the inherent attributes and dynamic attributes of the device. Existing solutions support decentralized device registration, but fail to effectively solve the refined management of device attribute verification, especially device management in a dynamic environment. The present invention not only uses blockchain to achieve decentralized device registration, but also utilizes attribute-based verification to ensure higher security and efficiency. Through this innovative mechanism, the present invention can achieve more flexible and accurate device authentication, which is particularly suitable for complex device management requirements in medical scenarios. In general, the innovations of the present invention in privacy protection, access control, device registration and verification performance give it significant technical advantages over existing frameworks, and can better meet the complex needs of verification authorization management and data privacy protection of acquisition devices in related fields with data privacy protection and integrity requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 This is a diagram of the structure of the device attribute verification system based on blockchain and zero-knowledge proof of the present invention.

[0057] Figure 2 Illustration of the blockchain-based device registration and authentication process.

[0058] Figure 3 Diagram of the access authentication and authorization process for device users under the privacy protection of sensitive data.

[0059] Figure 4 Illustration of the hash commitment value of the device attribute field under privacy protection. (a) ADS is reconstructed to verify the integrity of attribute data, and (b) attribute verification under privacy data protection based on zksnark zero-knowledge proof.

[0060] Figure 5 To construct the ADS tree root value corresponding to the user list userIDs, which is used for user list data integrity verification.

[0061] Figure 6 Attestation size for authorization of device attribute authentication under privacy protection.

[0062] Figure 7 Proof of time for authorization of device attribute authentication under privacy protection.

[0063] Figure 8 Verification time for device attribute authentication authorization under privacy protection. DETAILED DESCRIPTION

[0064] The present invention is further described below through specific embodiments in conjunction with the accompanying drawings.

[0065] This embodiment is aimed at cross-border medical scenarios. Accordingly, the authorized management agency is an authoritative medical management agency, and the relevant data is medical record data; and so on.

[0066] Device registration: When registering a device, you must submit 10 basic attributes including the International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Bluetooth MAC address, manufacturer, SIM card serial number, asset ID, access area, time, and device owner.

[0067] Devices are granted access to a specific number of patient records based on authorization, ranging from 50 to 1,500 records.

[0068] Access control and zero-knowledge proof: When a data consumer (i.e., device) requests access to patient records, the system uses zero-knowledge proof technology to verify the legitimacy of the request while protecting sensitive information (such as the specific location of the device, access time, and requested patient IDs) from being leaked.

[0069] Performance evaluation method:

[0070] The present invention uses three key indicators to evaluate device attribute authentication authorization under privacy protection and ensure the privacy protection of patient ID. The three indicators are: proof size, proof generation time, and proof verification time.

[0071] By comparing four different verification methods (device attribute verification DV only, patient identifier integrity verification PV, zero-knowledge proof verification ZKPV of patient ID, and the comprehensive verification scheme of MedZKChain of the present invention), the system performance is comprehensively evaluated.

[0072] Proof Size Assessment:

[0073] By simulating a scenario where the number of authorized patient IDs increases from 100 to 1500, Figure 6 It is shown that the proof size of the proposed scheme remains relatively small (<400KB), thanks to the simplicity of zk-SNARKs proofs.

[0074] Compared to device attribute verification (DV) only, the proof size of the DV method is extremely small (<1KB) due to the existence of the attribute directory structure (ADS).

[0075] As the number of records increases, although the size of the verification object increases, the batch verification mechanism effectively reduces the overhead of repeated verification paths.

[0076] Proof of Time Assessment:

[0077] like Figure 7 As shown, as the number of patient ID records increases, the proof time in MedZKChain (including the time to build ADS, upload to the blockchain, and generate zk proof) remains below 3 seconds, ensuring the real-time performance of the system.

[0078] Although the generation of zero-knowledge proofs requires additional time to protect sensitive attributes, the overall proof time remains within an acceptable range.

[0079] Verification time assessment:

[0080] like Figure 8 As shown, the verification time is very fast (< 1 second) in all cases, thanks to the fast verification property of zk-SNARKs.

[0081] Even for zkPV verification of 1500 records, the time is below 0.6 seconds, and the combined verification time of MedZKChain is below 0.8 seconds.

[0082] Zero-knowledge proof performance evaluation:

[0083] The performance of zero-knowledge proof in protecting different attribute characteristics (such as patient ID privacy, integrity, etc.) was further tested, and the results are shown in Table 1.

[0084] Table 1. Performance of zero-knowledge privacy protection for device access time only

[0085]

[0086] The performance of protecting a specific location (as shown in Table 2) and protecting both location and time access (as shown in Table 3) are also evaluated, both showing good privacy protection capabilities and efficiency.

[0087] Table 2. Performance of zero-knowledge privacy protection for device-only access to location information

[0088]

[0089] Table 3. Simultaneous zero-knowledge privacy protection for location and time

[0090]

[0091] By implementing the above technical solution, the present invention successfully builds a safe and efficient medical Internet of Things device registration and authentication system. The system can not only effectively verify the legitimacy of the device, but also realize the legal access of the device to specific patient records while protecting the patient's privacy. Through performance evaluation, it is proved that the present invention has excellent performance in terms of proof size, proof generation time and verification time, providing strong support for the safe application of medical Internet of Things.

Claims

1. A device attribute verification method based on blockchain and zero-knowledge proof, which involves four main roles: data collector, blockchain platform, data consumer as prover, and authorized regulator as verifier; the device refers to a handheld device or smart phone used by the data collector to collect and access data; it is characterized in that, The specific steps are as follows: (1) Equipment registration, authentication and authorization; The data collector, who is also the user of the device, registers the device and provides its attribute information, including metadata, user identity, registration location and timestamp; During the device registration process, the SHA256 algorithm is used to generate a hash commitment to ensure data integrity and prevent tampering; the data record of each device is modeled as a tuple oi= <id i ,Device i >, where idi is the unique identifier of the device and Device i The attribute data of the device is defined in detail; To ensure the authenticity and immutability of the data, an attribute data structure (ADS) is constructed, and a Merkle hash tree (MHT) is further constructed to store the attribute data of the data collector's device; the root value of the MHT, i.e., the mRoot value, is stored on the blockchain; this ADS root value cannot be tampered with on the blockchain, and it exists as a notarization of the original device attribute data; The specific registration process is as follows: (1) Device identity registration: The data collector’s terminal device first registers its identity with the blockchain-based data management system; the system generates a unique device fingerprint ID by encrypting the device’s feature information; (2) Data structure and storage: Device attributes are structured into a Merkle hash tree (ADS). This tree structure helps to achieve fine-grained data authorization and verification. The blockchain stores ADS to ensure the integrity and tamper-proofness of query results. In order to reduce the storage space of the blockchain, multiple data records are classified into a Merkle hash tree (MHT), and only the root node of the MHT is stored. The system adopts an on-chain and off-chain collaborative storage architecture to optimize storage space. The tree root (mRoot value) of the ADS is uploaded to the blockchain as a notarization and integrity proof of the data, while the detailed device attribute data is stored in the off-chain database. (3) Decentralized registration and hash summary generation: The device undergoes a decentralized registration process through the blockchain, and in this process generates a unique hash summary as the device identifier; this hash summary not only uniquely identifies the device, but also ensures the integrity and authenticity of the device data during the registration process; (II) Verification and access authorization based on device attributes. The workflow is as follows: (1) Initiate a request: The data consumer, i.e., the user who requests access to the data, or the data collector, acts as the prover of the zero-knowledge proof. The data consumer uses zk-SNARK to generate a zero-knowledge proof to prove that the registered attributes of the device are valid, and that the location, time, and user ID of the access are within the authorized scope. (2) Device attribute verification: The authoritative authorization management agency, as the verifier, receives the access request from the terminal device and calculates the hash value of the attribute information sent by the current requesting device through the SHA256 algorithm. At the same time, it obtains the ADS root hash value of the device registered with the unique identity fingerprint from the blockchain platform, compares it, and verifies it. (3) Access authorization: The permission verification module in the smart contract queries the device's attribute set in the hash table based on the device identifier, which contains the device's identifier and target information to verify whether the device has the required permissions to perform the requested operation; if the device has the required permissions, the system sends the device an authorization license and an accessible data resource information table, allowing the device to perform the operation; (4) The authoritative authorization management agency returns relevant data to the requester based on the database and access authorization policy; (3) Authority management and authorization; During the device registration and authentication process, the generated hash summary is used as the device's unique fingerprint ID and data storage address. The unique fingerprint ID is the device's identifier. In the off-chain database, the device's identifier, attributes, and user identity information are stored in the hash table; the authorization agency creates a user ID list (userIDs) based on the device's fingerprint ID; a Merkle hash tree is built for the user IDs in userIDs, and the tree root is stored on the blockchain to prevent the PL list from being tampered with; in order to achieve authorized access management under privacy protection, the device's access rights are bound to the time range and geographic location information range; the authorization management agency further subdivides user data and cross-validates it with dynamic information and attribute mapping in the system to determine the data accessible to the device; different data consumers access different resources; when the device's attributes change, the hash summary is regenerated based on the new attributes, and the off-chain database is updated, while the original device identification and attribute information is deleted; The authorization authority acts as the authorization verifier and the verifier of zero-knowledge proof, ensuring the integrity of the data based on the ADS stored on the blockchain; Specifically, using the provided user ID list (userIDs), reconstruct the ADS, calculate and compare it with the Merkle root node stored on the blockchain; in addition, using the public and private input attributes of the device, reconstruct the Merkle tree root node of the device attributes and compare it with the Merkle tree root mRoot associated with the device's unique ID on the blockchain; the verifier also uses zero-knowledge proof to verify the prover's device identity and access rights; That is, according to the attribute information of the device used to access the data, the range requirements of the attribute values, and the non-interactive zero-knowledge proof system, a zero-knowledge proof constraint circuit is designed to transform the numerical attribute feature problem to be proved into an arithmetic circuit problem without leaking any information about the input records.

2. The device attribute verification method based on blockchain and zero-knowledge proof according to claim 1 is characterized in that: It also includes the generation and verification of zero-knowledge proofs; The secret input data of the designed circuit is the identity data for subsequent calculation operations. The public input: attribute feature requirements, the public commitment value used to verify the attribute data; circuit operation logic: whether the identity secret input data belongs to a certain range, whether the Hash commitment value corresponding to the identity secret data is consistent with the public commitment value; Here, for the commitment value corresponding to the identity secret data, there are two ways to constrain the circuit calculation logic: if the verifier has great trust in the off-chain data management center, (1) the prover can obtain the corresponding Hash commitment value from the off-chain data center based on the transaction Txid uploaded to the blockchain by the current user identity information, and then declare it to be equal to the public commitment value; (2) If the verifier does not fully trust the off-chain data management center, or has very high requirements for the authentication security level of private data, the prover is required to calculate the Hash commitment value based on the user's secret input data and random numbers in the circuit calculation logic, and then declare it to be equal to the public commitment value.

3. The device attribute verification method based on blockchain and zero-knowledge proof according to claim 2 is characterized in that: The generation algorithm of zero-knowledge proof is as follows: Assume that Cx is a constraint circuit represented as an arithmetic circuit over a finite field F and λ is the security parameter used to generate the public and private keys; Generate two keys: proof key (pk) and verification key (vk); input security parameter 1 λ , private input: {region, time, owner}, public input: {deviceID, deviceName, deviceAttribute i ,...,regionRange,timeRange,{userIDs}}; This scheme allows the prover to show the verifier that the accessed user ID is authorized within the specified region and time range by inputting public device attributes and sensitive private data; it includes the following algorithms: Setup(1 λ ,Cx): key generation algorithm, input security parameter 1 λ ,Circuit Cx is the designed constraint circuit, which outputs the public reference string (crs), the proof key (pk), and the verification key (vk); Zero-knowledge proof function zkProve(pk,<private input> ,<public input> ): zk proof algorithm, input pk, private input and public input, generate zero-knowledge proof π by executing circuit Cx; private input privateinput=(region,time), The algorithm is as follows: public input={(deviceID,name,..),regionRange,timeRange,{patientIDs}}π←zkProve(pk,private input,public input){ / / Prove that the region and time are within the set range region in regionRange time in timeRange } The verification function of zero-knowledge proof zkVerify(vk,π,<public input> ): Verification algorithm zkVerify, input vk, proof π and public input, output 1 if the verification is valid; Blockchain verification algorithm (mRootPath, mRootblockchain): The verifier obtains the Merkle root node (mRoot) of the original device attribute from the blockchain to verify the integrity of the query result; this integrity verification includes verifying the integrity of the device attribute ADS and the authorized user ID; Based on zk-SNARKs technology, it is proved that a data record that satisfies the secret input does exist and that the data item satisfies certain properties without leaking the patient's private data. Data owner: uploads data records to the blockchain. Each record forms a transaction. Each attribute value attr is recorded to calculate the Hash commitment value and form a Merkle hash tree. The Hash Root is chained as a transaction leaf node, and finally a Merkle Root is generated. Prover: Design the circuit file Cx and verify zkVerify to generate the evidence π of the zero-knowledge proof; prove the secret input data is within a certain range by proving the key; recalculate Root' in the circuit file and prove that it is equal to Root; Verifier: By verifying the secret key and public input, on the one hand, it verifies whether the zero-knowledge proof passes, returning 1 if passed and 0 if not; on the other hand, it verifies the integrity of the data and sets the user's access authorization based on the verification result.

4. The device attribute verification method based on blockchain and zero-knowledge proof according to claim 3 is characterized in that: There are two ways to generate proof: The first is non-strict verification. In the proof circuit, the prover uses DC directly from the off-chain data center to extract the Hash commitment value corresponding to the original data according to the transaction Txid, and compares it with the public input data, that is, the Hash commitment value used for verification, to verify the authenticity of the original data. The second type is strict verification. In the constraint proof circuit, the prover recalculates the Hash commitment value based on the original secret input data provided, and then compares it with the public input data, that is, the Hash commitment value used for verification, to verify the authenticity of the original data.

Images