Device verification method, blockchain node and storage medium

Abstract

The application provides a device verification method, a blockchain node and a storage medium, relates to the technical field of communication, and can improve the flexibility of users in obtaining data. The method comprises the following steps: obtaining a target data request message of a first device. The target data request message comprises an identifier of target data and request attribute information. The request attribute information comprises at least one of the following: an attribute of the first device and an attribute of the target data. A target access strategy is determined from a plurality of access strategies based on the identifier of the target data. The target access strategy comprises at least one of the following: a device attribute requirement having the permission to obtain the target data and an attribute requirement of the target data. A verification result of the first device is determined based on the request attribute information and the target access strategy. The verification result is used to represent whether the first device has the permission to access the target data. The embodiments of the application are used in the process of device verification.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, and particularly relates to a device verification method, a blockchain node and a storage medium. BACKGROUND

[0002] At present, in a government system, a traditional device verification method needs to know in advance the identity or role of a user and the corresponding relationship between the user and user permissions, so that the government system can verify whether a user device has the permission to request data based on the corresponding relationship between the user permissions and the identity or role of the user.

[0003] However, if the user device is verified only according to the corresponding relationship between the user permissions and the identity or role of the user, the range of data that can be obtained by the user device is very fixed. With the user device with a constantly changing identity or role, constantly changing data, and a constantly changing computing environment, the fixed device verification range will reduce the flexibility of the user in obtaining data. SUMMARY

[0004] The present application provides a device verification method, a blockchain node and a storage medium, which can improve the flexibility of the user in obtaining data.

[0005] To achieve the above object, the present application adopts the following technical solutions:

[0006] In a first aspect, the present application provides a device verification method, which comprises: obtaining a target data request message of a first device. The target data request message comprises: an identifier of target data, and request attribute information. The request attribute information comprises at least one of the following: an attribute of the first device and an attribute of the target data. The first device is a device requesting the target data. A target access policy is determined from a plurality of access policies based on the identifier of the target data. The target access policy comprises at least one of the following: a device attribute requirement having the permission to obtain the target data and an attribute requirement of the target data. A verification result of the first device is determined based on the request attribute information and the target access policy. The verification result is used to represent whether the first device has the permission to access the target data.

[0007] In a possible implementation manner, the method further comprises: determining a user attribute set, a resource attribute set and preset data. The user attribute set comprises a plurality of attribute information of a user device. The resource attribute set comprises a plurality of attribute information of data. The preset data is any one of a plurality of data. A preset access policy is configured for the preset data based on the plurality of attribute information of the user device and the plurality of attribute information of the data.

[0008] In a possible implementation, the method further includes: receiving a verification message from the second device. The verification message is used to request the target access policy. The second device is a device providing the target data. The target access policy is sent to the second device.

[0009] In a possible implementation, the attribute of the first device includes at least one of the following: a unit to which the first device belongs, a department to which the first device belongs, a role of the first device, a responsibility of the first device, and a system to which the first device belongs. The attribute of the target data includes at least one of the following: an identifier, a summary, a format, an item, a length, and a sharing attribute.

[0010] In a second aspect, the present application provides a blockchain node. The blockchain node is located in a data verification system including a plurality of blockchain nodes and a first device. The blockchain node includes a communication unit and a processing unit. The communication unit is configured to obtain a target data request message of the first device. The target data request message includes an identifier of target data and request attribute information. The request attribute information includes at least one of the following: an attribute of the first device and an attribute of the target data. The first device is a device requesting the target data. The processing unit is configured to determine a target access policy from a plurality of access policies based on the identifier of the target data. The target access policy includes at least one of the following: a device attribute requirement having a permission to obtain the target data and an attribute requirement of the target data. The processing unit is further configured to determine a verification result of the first device based on the request attribute information and the target access policy. The verification result is used to represent whether the first device has a permission to access the target data.

[0011] In a possible implementation, the communication unit is further configured to determine a user attribute set, a resource attribute set, and preset data. The user attribute set includes a plurality of attribute information of a user device. The resource attribute set includes a plurality of attribute information of data. The preset data is any one of a plurality of data. The processing unit is further configured to configure a preset access policy for the preset data based on the plurality of attribute information of the user device and the plurality of attribute information of the data.

[0012] In a possible implementation, the communication unit is further configured to receive a verification message from the second device. The verification message is used to request the target access policy. The second device is a device providing the target data. The communication unit is further configured to send the target access policy to the second device.

[0013] In a possible implementation, the attribute of the first device includes at least one of the following: a unit to which the first device belongs, a department to which the first device belongs, a role of the first device, a responsibility of the first device, and a system to which the first device belongs. The attribute of the target data includes at least one of the following: an identifier, a summary, a format, an item, a length, and a sharing attribute.

[0014] In a third aspect, the present application provides a blockchain node, comprising a processor and a communication interface. The communication interface and the processor are coupled, and the processor is configured to run computer programs or instructions to implement the device verification method as described in the first aspect and any possible implementation manner of the first aspect.

[0015] In a fourth aspect, the present application provides a computer readable storage medium, which stores instructions. When the instructions are run on a terminal, the terminal performs the device verification method as described in the first aspect and any possible implementation manner of the first aspect.

[0016] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when run on a blockchain node, causes the blockchain node to perform the device verification method as described in the first aspect and any possible implementation manner of the first aspect.

[0017] In a sixth aspect, the present application provides a chip, comprising a processor and a communication interface. The communication interface and the processor are coupled, and the processor is configured to run computer programs or instructions to implement the device verification method as described in the first aspect and any possible implementation manner of the first aspect.

[0018] Specifically, the chip provided in the present application further comprises a memory for storing computer programs or instructions.

[0019] The above technical solution at least brings the following beneficial effects: the device verification method provided in the present application, the blockchain node obtains a target data request message of a first device (i.e., comprising: an identifier of target data, request attribute information. The request attribute information comprises at least one of: an attribute of the first device, and an attribute of the target data), and determines a target access policy (i.e., comprising at least one of: a device attribute requirement having a permission to obtain the target data, and an attribute requirement of the target data) from a plurality of access policies based on the identifier of the target data. Then, the blockchain node determines a verification result of the first device (i.e., used to represent whether the first device has a permission to access the target data) based on the request attribute information and the target access policy.

[0020] Based on the above, the blockchain node can verify whether the first device has a permission to access the target data based on the access policy related to the device attribute and the data attribute. Compared with the access policy based on the user identity or role, the device verification method of the present application can flexibly configure the access policy of the data, improve the flexibility of the access policy setting, and further improve the flexibility of the user to obtain the data, greatly avoiding the device verification exception. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1A flowchart of data access based on an ABAC access control mechanism provided by an embodiment of the present application;

[0022] Figure 2 A structural diagram of a device verification system provided by an embodiment of the present application;

[0023] Figure 3 A flowchart of a device verification method provided by an embodiment of the present application;

[0024] Figure 4 A flowchart of another device verification method provided by an embodiment of the present application;

[0025] Figure 5 A flowchart of another device verification method provided by an embodiment of the present application;

[0026] Figure 6 A structural diagram of a blockchain node provided by an embodiment of the present application;

[0027] Figure 7 A structural diagram of another blockchain node provided by an embodiment of the present application. DETAILED DESCRIPTION

[0028] The device verification method, the blockchain node and the storage medium provided by the embodiments of the present application are described in detail below in combination with the drawings.

[0029] The term "and / or" in this document is merely a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can represent the three cases of A alone, A and B together, and B alone.

[0030] The terms "first" and "second" and the like in the description of the present application and the drawings are used to distinguish different objects or different treatments of the same object, and are not used to describe the specific order of the objects.

[0031] In addition, the terms "include" and "have" and any variations thereof mentioned in the description of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but can optionally include other steps or units that are not listed, or can optionally include other steps or units inherent to the process, method, product or device.

[0032] It should be noted that in the embodiments of the present application, the words such as "exemplary" or "for example" are used to mean serving as an example, instance, or illustration. Any embodiment or design presented as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or advantageous than other embodiments or design solutions. Rather, the use of the words such as "exemplary" or "for example" is intended to present concepts in a concrete manner.

[0033] In the description of the present application, "a plurality of" means two or more, unless otherwise specified.

[0034] In the following, the terms related to the embodiments of the present application are explained to facilitate the understanding of the readers.

[0035] 1. Blockchain

[0036] The blockchain refers to a chain type data structure in which data blocks are connected in the order of time sequence. The blockchain can integrate distributed storage, encryption technology, consensus algorithm, smart contract and other technologies, so that the blockchain has characteristics such as decentralization, tamper resistance, etc. Due to the above-mentioned characteristics such as decentralization, tamper resistance, etc., the blockchain has technical advantages in promoting data sharing, optimizing business processes, reducing operating costs, improving collaboration efficiency, and building a trusted system, etc.

[0037] It should be pointed out that the above-mentioned blockchain refers to a decentralized trust mechanism, which has three characteristics of decentralization, tamper resistance, and traceability. According to the degree of centralization, the blockchain is divided into three types: public chain, alliance chain, and private chain. The following will describe the above-mentioned three types of blockchains respectively:

[0038] Among them, the public chain refers to a completely decentralized blockchain type. In the public chain, there is no central server, and there is no official organization or management agency. All nodes on the chain can freely conduct transactions and are not controlled by other nodes. Each node maintains consistency through a consensus mechanism.

[0039] The private chain refers to a centralized blockchain type. All permissions in this chain are controlled by this centralized organization and agency. It is generally applied to the internal system of an enterprise, and its operation rules are set according to the specific requirements of the enterprise.

[0040] The alliance chain refers to a multi-centralized blockchain type. This chain allows authorized nodes to join the network, and each node usually has a corresponding entity organization. Each organization manages one or more nodes, and the data is only allowed to be read, written and sent by the organizations in the system according to the permissions.

[0041] Optionally, the blockchain mainly utilizes a distributed ledger to verify and store data, utilizes a consensus mechanism to generate and update data, utilizes asymmetric encryption to ensure the security of data transmission and access, and utilizes smart contracts composed of automated script code to program and operate data. The following describes the above-mentioned distributed ledger, asymmetric encryption, consensus mechanism, and smart contract technologies respectively:

[0042] 1.1. Distributed ledger

[0043] The distributed ledger refers to a decentralized data recording method. In the above-mentioned blockchain, the data stored by each node in the blockchain is encrypted in a cryptographic manner to obtain a distributed ledger (which can also be referred to as a distributed database). The advantages of the distributed ledger include: data transparency, information traceability, non-tamperability, and non-falsifiability.

[0044] It should be noted that since each record of the distributed ledger corresponds to a time point and a cryptographic signature, the transactions of the distributed ledger are traceable and auditable. Moreover, if the data in the distributed ledger needs to be changed, the consent of multiple nodes in the distributed ledger must be obtained, which ensures that the distributed ledger cannot be tampered with and cannot be falsified. In addition, the above-mentioned changes need to be recorded in each corresponding copy, which further ensures that the information of the distributed ledger is traceable.

[0045] 1.2. Asymmetric encryption

[0046] Asymmetric encryption refers to an encryption method based on two asymmetric keys. The two asymmetric keys include a public key and a private key. The public key is public and can be obtained by all users. The private key is private and can only be obtained by the encryption user, so that users other than the encryption user cannot obtain or calculate the private key. Based on this, asymmetric encryption has the advantage of high confidentiality, but also has the disadvantage of slow encryption and decryption speed. In the scenarios of information decryption, digital signature, and login authentication, asymmetric encryption is usually used to encrypt and decrypt information.

[0047] 1.3. Consensus mechanism

[0048] The consensus mechanism refers to a consensus (which can also be referred to as a trust system) reached by each node in the blockchain, so that each node can solve problems (such as how to ensure the validity of accounting, how to determine the accounting node, etc.) based on the consensus mechanism.

[0049] In some examples, the consensus mechanism can include at least one of the following: a Proof of Work (PoW) consensus mechanism (may also be referred to as a Proof of Work mechanism), a Proof of Stake (PoS) consensus mechanism, a Delegated Proof of Stake (DPoS) consensus mechanism, a Practical Byzantine Fault Tolerance (PBFT), and a regulatory coherence fault tolerance (RAFT). Among them, the PoW consensus mechanism (Proof of Work mechanism), the PoS consensus mechanism, and the DPoS consensus mechanism are usually applied to public chains. PBFT and RAFT are usually applied to consortium chains in order to improve efficiency.

[0050] 1.4. Smart contract

[0051] A smart contract refers to a set of commitments defined in digital form, and each node in the blockchain (i.e., a contract participant) needs to comply with the above commitments (i.e., a smart contract). When there is a potential dispute in the blockchain, the decision to handle the above potential dispute can be determined based on the smart contract, for example, in the case where a passenger has purchased flight delay insurance and the airport node and the insurance agency node have signed a smart contract, the airport node can record the personal information of the insured passenger, flight delay information, and flight dynamics in the form of a smart contract in the blockchain. In this case, if it is determined based on the above information that the flight delay meets the claim conditions, the insurance agency node will automatically transfer the claim amount to the account of the insured passenger.

[0052] 2. Access control technology

[0053] Access control technology refers to a technology that ensures that resources can only be executed by legitimate users according to a pre-set access control policy. The above access control technology can effectively prevent unauthorized access to information.

[0054] It should be noted that the research and development of access control technology can be roughly divided into the following four stages:

[0055] The first stage is in the 1970s, which refers to the access control technology applied to large mainframe systems. The representative work of this access control technology is the BLP and Biba models that ensure confidentiality and integrity, respectively.

[0056] The second phase, in the 1980s, refers to more flexible access control techniques to adapt to the increasing trust requirements of computers. The representative work of the access control technique is the Trusted Computer System Evaluation Criteria proposed by the relevant department. The Trusted Computer System Evaluation Criteria assigns different access permissions to access permission managers in different roles. The access control technique can include discretionary access control (DAC) and mandatory access control (MAC).

[0057] The third phase, around 2000, refers to more complex access control techniques to adapt to the development of information systems and the Internet. The AC and MAC in the access control technique of the second node have the disadvantages of limited expansion, which makes the access control technique of the second node difficult to handle the increasingly complex application layer access requirements, so the role-based access control (RBAC) (i.e. the access control technique of the third phase) emerges as the times require.

[0058] The fourth phase refers to more complex access control techniques to adapt to new computing environments such as cloud computing and the Internet of Things. The new computing environment brings great challenges to the application of access control techniques, making it difficult for traditional access control models for closed environments to be directly applicable to new computing environments, so the attribute-based access control (ABAC) mechanism emerges as the times require. The attribute-based ABAC mechanism depends on subject attributes, object attributes, and access policies. Each access object in the access control system must have at least one policy to define access rules, including the subjects allowed to access the object, operations, and environmental conditions, so that the access control system can check subject attributes, object attributes, and enforce access control decisions according to the logic provided in the policy. Among them, the subject attribute is established, published, stored and managed by the attribute authority (AA), including naming, definition, giving a set of allowed values, assigning a pattern. Object attributes need to be established, maintained and assigned to objects when creating or modifying objects.

[0059] The main functional components of the ABAC access control system include attribute authorities, policy enforcement points, policy decision points, and policy management points, which provide access control decisions and policy enforcement.

[0060] The attribute authority is responsible for collecting, storing and managing entity attributes. The policy enforcement point responds to the access request of the subject and enforces the policy decision of the policy decision point. The policy decision point generates an access control decision. The policy management point stores the access control policy.

[0061] Optionally, the data access process based on the ABAC access control mechanism can include a preparation phase and an execution phase. The preparation phase is mainly responsible for collecting and constructing the attribute set required for the access control mechanism, and describing the access control policy. The execution phase is mainly responsible for responding to the access request and updating the access policy. As shown in Figure 1 The following will be described in detail based on the data access process based on the ABAC access control mechanism:

[0062] Step 1, the attribute authority pre-collects, stores, and manages all attributes (i.e., attribute set) required for constructing a secure access control and the correspondence between the attributes and the permissions.

[0063] Step 2, the policy management point obtains the attribute set and the correspondence between the attributes and the permissions, and formally describes the access control policy based on the attribute set and the correspondence between the attributes and the permissions.

[0064] Step 3, the policy enforcement point obtains the original access request, and requests the subject attributes, object attributes and related environment attributes from the attribute authority.

[0065] Step 4, the policy enforcement point constructs an attribute-based access request according to the attribute result set sent by the attribute authority, and sends the attribute-based access request to the policy decision point.

[0066] Step 5, the policy decision point sends an access policy query request to the policy management point. Correspondingly, the policy management point receives the access policy query request from the policy decision point.

[0067] The access policy query request is used to request to determine whether the access request can be authorized.

[0068] Step 6, the policy management point sends an access policy query response to the policy decision point. Correspondingly, the policy decision point receives the access policy query response from the policy management point.

[0069] The access policy query response is used to indicate the result of determining whether the access request can be authorized.

[0070] Step 7, the policy decision point sends an access policy query response to the policy enforcement point. Correspondingly, the policy enforcement point receives the access policy query response from the policy decision point.

[0071] Step 8, the policy enforcement point executes the above result.

[0072] It's understandable that ABAC technology creates access control policies based on subject attributes and access object-specific attributes. It then examines the attributes of the access subject and access object based on these policies to determine whether to grant the access subject the corresponding access rights. Because these attributes can describe subjects and objects from multiple dimensions, and access control is a many-to-many approach, ABAC can more fully express access control requirements in real-world situations and meet fine-grained access control policies. Furthermore, since attributes are inherent to subjects and objects, object owners can formulate access control policies without prior knowledge of specific subjects, making ABAC management relatively flexible and simple.

[0073] The above is a brief introduction to some of the concepts involved in the embodiments of this application.

[0074] like Figure 2 As shown, Figure 2 The schematic diagram of the structure of a device verification system provided by an embodiment of the present application is shown. The device verification system includes: multiple blockchain nodes 201 ( Figure 2 In the example, N blockchain nodes are used, where N is a positive integer) and the first device 202. The above-mentioned multiple blockchain nodes 201 constitute a blockchain (also known as an attribute authority chain).

[0075] Blockchain node 201 is used to obtain the target data request message of the first device, determine the target access policy based on the identification of the target data, and determine the verification result of the first device based on the request attribute information and the target access policy.

[0076] The target data request message includes: an identifier of the target data and requested attribute information. The requested attribute information includes at least one of the following: attributes of the first device and attributes of the target data. The target access policy includes at least one of the following: attribute requirements for devices with permission to access the target data and attribute requirements for the target data. The verification result indicates whether the first device has permission to access the target data. The first device is the device requesting the target data.

[0077] The first device 202 is used to provide the blockchain node 201 with a target data request message of the first device.

[0078] Optionally, the blockchain can store the above attribute information and permissions, create access policies based on the above attribute information and permissions, and verify and execute the above access policies.

[0079] It can be understood that if a centralized device is used to verify the device, as the amount of devices and data increases, the centralized device cannot meet the large-scale device verification requirements, and cannot meet the requirements of the device verification method on the device function and the device performance. The above increasing device verification requirements will cause a large processing burden on the above centralized device, and in the above case, the data in the above centralized device is vulnerable to centralized attacks, thereby reducing the security of the data. In addition, as the data is shared and circulated among multiple devices, there are different trust relationships between the multiple first devices, the multiple second devices and the centralized device, resulting in poor credibility of the device verification system. In summary, the traditional device verification system faces great challenges in security performance and credibility. Based on the above situation, the centralized device is replaced by multiple blockchain nodes with distributed characteristics and high credibility in order to improve the security performance and credibility of the device verification system.

[0080] In a possible implementation manner, the blockchain node 201 can be a device that provides input / output (input / output, IO) processing capability in the blockchain system. Each blockchain node 201 stores a blockchain, and all blockchain nodes 201 in the device verification system can store the same blockchain, which can be a consortium chain / public chain / private chain. The blockchain node 201 operates the blockchain (such as adding a block, deleting a block, etc.). The blockchain node 201 can have one or more functions, such as at least one of endorsement function, ordering function or bookkeeping function.

[0081] In some examples, the first device 202 can be terminal equipment, user equipment (UE), a mobile station (MS), a mobile terminal (MT), a mobile phone, a tablet computer, or a computer with wireless transceiver function, and can also be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in unmanned driving, a wireless terminal in telemedicine, a wireless terminal in smart grid, a wireless terminal in smart city, a smart home, a vehicle-mounted terminal, a terminal device of a personal user, a terminal device of an enterprise user (for example, a high-definition video camera, a programmable logic controller (PLC) controller, a sensor), and the like. In the embodiments of the present application, the device for implementing the functions of the first device 202 can be the first device 202, or can be a device capable of supporting the first device 202 to implement the functions, such as a chip system.

[0082] It should be noted that, Figure 2 The example block diagram is only, Figure 2 The number of nodes included in the communication system is not limited, and in addition to the functional nodes shown in the figure, other nodes such as the second device 203 and the data exchange platform device 204 can also be included, and the present application does not make any limitation in this regard. Figure 2

[0083] The blockchain node 201 (or the blockchain) can send a data scheduling message to the second device 203, and the second device 203 receives the data scheduling message from the blockchain node 201. The data scheduling message is used to instruct the second device 203 to provide target data for the first device 202. Then, the second device 203 can send the target data to the first device 202 through the data exchange platform device 204.

[0084] Optionally, the first device 202 and the second device 203 each include a pre-exchange front-end module and a local database.

[0085] In addition, the communication system described in the embodiments of the present application is used to more clearly illustrate the technical solutions of the embodiments of the present application, and does not constitute a limitation on the technical solutions provided by the embodiments of the present application. It can be known by those skilled in the art that with the evolution of network architecture and the appearance of new communication systems, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0086] ​Currently, in a government system, a traditional device verification method needs to know in advance the identity or role of a user and a corresponding relationship between the user and a user right, so that the government system can verify whether a device of the user has a right to request data based on the corresponding relationship between the user right and the identity or role of the user.

[0087] However, if the device of the user is verified only according to the corresponding relationship between the user right and the identity or role of the user, the range of data that can be obtained by the device is very fixed. With the user device changing identity or role, data changing, and computing environment changing, the fixed device verification range will result in reduced flexibility of the user in obtaining data. In addition, the traditional device verification method determines the user right only according to the role or identity, which makes the factors on which the user right is determined relatively single and rough, and also affects the flexibility of the user right.

[0088] To solve the problems in the prior art, an embodiment of the present application provides a device verification method, which can improve the flexibility of the user in obtaining data. As shown in the method includes: Figure 3

[0089] S301, a blockchain node obtains a target data request message of a first device.

[0090] The target data request message includes an identifier of target data and request attribute information. The request attribute information includes at least one of the following: an attribute of the first device and an attribute of the target data.

[0091] In an optional embodiment, the attribute of the first device includes at least one of the following: a unit to which the first device belongs, a department to which the first device belongs, a role, a responsibility, and a system to which the first device belongs. The attribute of the target data includes at least one of the following: an identifier, an abstract, a format, an item, a length, and a sharing attribute.

[0092] Optionally, the above is only an exemplary description of the attribute of the first device and the attribute of the target data, and the attribute of the first device and the attribute of the target data can each include other attributes, which are not limited in the present application.

[0093] In a possible implementation, before S301, the first device can construct the target data request message based on the attribute of the first device and the attribute of the target data, and send the target data request message to the blockchain node.

[0094] Optionally, when the blockchain node obtains the target data request message of the first device, the blockchain node can automatically perform the device verification method described in the embodiment of the present application.

[0095] ​S302, determining, by the blockchain node, the target access policy based on the identifier of the target data.

[0096] The target access policy comprises at least one of the following: a device attribute requirement for obtaining the target data permission, and an attribute requirement of the target data.

[0097] In a possible implementation, the target access policy can be stored in each blockchain node in the form of a smart contract, so as to improve the security of the target access policy.

[0098] S303, determining, by the blockchain node, the verification result of the first device based on the request attribute information and the target access policy.

[0099] The verification result is used to represent whether the first device has the permission to access the target data.

[0100] As an optional implementation, the implementation process of S303 can be that the blockchain node can first compare the attribute of the first device in the request attribute information with the device attribute requirement for obtaining the target data permission in the target access policy to generate a first comparison result, and then compare the attribute of the target data in the request attribute information with the attribute requirement of the target data in the target access policy to generate a second comparison result. The first comparison result is used to represent whether the attribute of the first device is consistent with the device attribute requirement for obtaining the target data permission. The second comparison result is used to represent whether the attribute of the target data is consistent with the attribute requirement of the target data.

[0101] In a case where the first result is used to represent that the attribute of the first device is consistent with the device attribute requirement for obtaining the target data permission, and the second comparison result is used to represent that the attribute of the target data is consistent with the attribute requirement of the target data, the blockchain node can determine that the verification result of the first device is used to represent that the first device has the permission to access the target data.

[0102] In a case where the first result is used to represent that the attribute of the first device is inconsistent with the device attribute requirement for obtaining the target data permission, and / or the second comparison result is used to represent that the attribute of the target data is inconsistent with the attribute requirement of the target data, the blockchain node can determine that the verification result of the first device is used to represent that the first device does not have the permission to access the target data.

[0103] Optionally, after S303, the blockchain node can send a data scheduling message to the second device, and correspondingly, the second device receives the data scheduling message from the blockchain node. The data scheduling message is used to instruct the second device to provide the target data for the first device. Then, the second device can send the target data to the first device through the data exchange platform device.

[0104] The technical scheme has at least the following beneficial effects: The device verification method provided by the application, the blockchain node obtains a target data request message of a first device (i.e., including: an identifier of target data, request attribute information. The request attribute information includes at least one of: an attribute of the first device and an attribute of the target data), and determines a target access policy (i.e., including at least one of: a device attribute requirement having a permission to obtain the target data and an attribute requirement of the target data) from a plurality of access policies based on the identifier of the target data. Then, the blockchain node determines a verification result of the first device (i.e., used to represent whether the first device has a permission to access the target data) based on the request attribute information and the target access policy.

[0105] Based on the above, the blockchain node can verify whether the first device has a permission to access the target data based on the access policy related to the device attribute and the data attribute. Compared with the access policy based on the user identity or role, the device verification method of the application can flexibly and meticulously configure the access policy of the data, improve the flexibility of the access policy setting, and further improve the flexibility of the user to obtain the data, and greatly avoid the device verification exception.

[0106] In an optional embodiment, before S301, the blockchain node needs to determine the access policy of each data in a plurality of data in advance, so as to verify whether the first device has a permission to access the target data after the blockchain node obtains the target data request message of the first device. Figure 3 As shown in Figure 4 The implementation process of the blockchain node to determine the access policy of each data in a plurality of data can be determined by the following S401 to S402.

[0107] S401, the blockchain node determines a user attribute set, a resource attribute set, and preset data.

[0108] The user attribute set includes a plurality of attribute information of a user device. The resource attribute set includes a plurality of attribute information of data. The preset data is any one of a plurality of data.

[0109] As an optional implementation, the implementation process of the blockchain node to determine the user attribute set can be: the blockchain node first collects a plurality of attribute information of a user device (the user device can be all or part of the user devices that the blockchain node can collect), and constructs the user attribute set based on the plurality of attribute information of the user device. Then, the blockchain node can store the user attribute set.

[0110] As a possible implementation manner, the implementation process of the blockchain node to determine the user attribute set can be that the blockchain node first collects multiple attribute information of the data (the user equipment can be all or part of the user equipment that the blockchain node can collect) and constructs a resource attribute set based on the multiple attribute information of the data. Then, the blockchain node can store the resource attribute set.

[0111] It can be understood that the user attribute set and the resource attribute set can be stored in the blockchain node, so that the user attribute set and the resource attribute set cannot be tampered with, thereby improving the security of the user attribute set and the resource attribute set.

[0112] S402, the blockchain node configures a preset access policy for the preset data based on the multiple attribute information of the user equipment and the multiple attribute information of the data.

[0113] As an optional implementation manner, the implementation process of S402 can be that the blockchain node

[0114] The technical scheme at least brings the following beneficial effects: the device verification method provided by the present application, the blockchain node determines a user attribute set (that is, multiple attribute information of a user equipment), a resource attribute set (that is, multiple attribute information of data), and preset data (that is, any one of multiple data), and configures a preset access policy for the preset data based on the multiple attribute information of the user equipment and the multiple attribute information of the data, so as to facilitate the blockchain node to verify whether the first device has the access right to the target data after obtaining the target data request message of the first device.

[0115] In an optional embodiment, before the blockchain node determines that the first device has the access right to the target data and the second device sends the target data to the first device, the second device can request the target access policy from the blockchain node, so as to further verify whether the first device has the access right to the target data, thereby further improving the security of the target data. In combination Figure 4 As shown in Figure 5 The implementation process in which the second device verifies whether the first device has the access right to the target data can be determined through the following S501 to S502.

[0116] S501, the second device sends a verification message to the blockchain node. Correspondingly, the blockchain node receives the verification message from the second device.

[0117] The verification message is used to request the target access policy. The second device is a device that provides the target data.

[0118] Optionally, the description of the target access policy can be understood by referring to the description of the corresponding position, which will not be repeated here.

[0119] S502, the blockchain node sends the target access policy to the second device. Correspondingly, the second device receives the target access policy from the blockchain node.

[0120] Optionally, after S502, the blockchain node can re-verify whether the first device has the access right to the target data based on the target access policy. The implementation process of the second device verifying whether the first device has the access right to the target data can be understood by referring to the implementation process of the blockchain node verifying whether the first device has the access right to the target data, which will not be repeated here.

[0121] The technical solution described above at least brings the following beneficial effects: the device verification method provided by the present application, the blockchain node receives the verification message (i.e. for requesting the target access policy) from the second device, and sends the target access policy to the second device, so as to re-verify whether the first device has the access right to the target data, further improving the security of the target data.

[0122] It can be understood that the device verification method described above can be implemented by the blockchain node. In order to implement the above functions, the blockchain node contains the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should easily realize that, in combination with the modules and algorithm steps of each example described in the embodiments disclosed herein, the embodiments disclosed in the present application can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software driven hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments disclosed in the present application.

[0123] The blockchain node generated according to the method examples described above can be divided into functional modules by the embodiments disclosed in the present application. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The integrated module can be realized in the form of hardware or software functional module. It should be noted that the division of modules in the embodiments disclosed in the present application is illustrative, and is only a logical functional division. There can be another division way when actually implemented.

[0124] Figure 6 A structural schematic diagram of a blockchain node provided by the embodiments of the present application is shown in FIG. 6. Figure 6 As shown in FIG. 6, the blockchain node 60 can be used to execute the method examples described above. Figures 2-5The device verification method is shown. The blockchain node 60 comprises a communication unit 601 and a processing unit 602.

[0125] The communication unit 601 is configured to obtain a target data request message of a first device. The target data request message comprises an identification of target data and request attribute information. The request attribute information comprises at least one of the following: an attribute of the first device and an attribute of the target data. The first device is a device requesting the target data. The processing unit 602 is configured to determine a target access policy from a plurality of access policies based on the identification of the target data. The target access policy comprises at least one of the following: a device attribute requirement having a permission to obtain the target data and a target data attribute requirement. The processing unit 602 is further configured to determine a verification result of the first device based on the request attribute information and the target access policy. The verification result is used to represent whether the first device has a permission to access the target data.

[0126] In a possible implementation, the communication unit 601 is further configured to determine a user attribute set, a resource attribute set, and preset data. The user attribute set comprises a plurality of attribute information of a user device. The resource attribute set comprises a plurality of attribute information of data. The preset data is any one of a plurality of data. The processing unit 602 is further configured to configure a preset access policy for the preset data based on the plurality of attribute information of the user device and the plurality of attribute information of the data.

[0127] In a possible implementation, the communication unit 601 is further configured to receive a verification message from a second device. The verification message is used to request the target access policy. The second device is a device providing the target data. The communication unit 601 is further configured to send the target access policy to the second device.

[0128] In a possible implementation, the attribute of the first device comprises at least one of the following: a unit to which the first device belongs, a department to which the first device belongs, a role, a responsibility, and a system to which the first device belongs. The attribute of the target data comprises at least one of the following: an identification, an abstract, a format, an item, a length, and a sharing attribute.

[0129] In a case where the functions of the above-mentioned integrated modules are implemented in the form of hardware, the embodiments of the present application provide a possible structural diagram of the blockchain node involved in the above-mentioned embodiments. As shown in Figure 7 A blockchain node 70, for example, is used to execute Figures 2-5 The device verification method is shown. The blockchain node 70 comprises a processor 701, a memory 702, a bus 703, and a communication interface 704. The processor 701 and the memory 702 can be connected through the bus 703.

[0130] The processor 701 is the control center of the user equipment, and can be one processor or a collective term of multiple processing elements. For example, the processor 701 can be a general central processing unit 702 (CPU), or other general-purpose processors, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0131] As an embodiment, the processor 701 can include one or more CPUs, such as the CPU 0 and the CPU 1 shown in FIG. 7. Figure 7

[0132] The memory 702 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to this.

[0133] As a possible implementation, the memory 702 can exist independently of the processor 701, and the memory 702 can be connected to the processor 701 through the bus 703, for storing instructions or program codes. When the processor 701 invokes and executes the instructions or program codes stored in the memory 702, the device verification method provided by the embodiments of the present application can be implemented.

[0134] In another possible implementation, the memory 702 can also be integrated with the processor 701.

[0135] The bus 703 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 In FIG. 7, only one thick line is used to represent the bus, but it does not mean that there is only one bus or only one type of bus.

[0136] ​The communication interface 704 is configured to connect with other devices through a communication network. The communication network can be an Ethernet, a wireless access network, a wireless local area network (WLAN), or the like. The communication interface 704 can include a communication unit 601 configured to receive data, and can further include an acquisition unit and a receiving unit.

[0137] In one design, the communication interface in the blockchain node 70 provided by an embodiment of the present application can also be integrated in the processor.

[0138] It should be noted that, Figure 7 The illustrated structure does not constitute a limitation on the blockchain node 70. In addition to Figure 7 The blockchain node 70 can include more or fewer components than shown, or a combination of some components, or different arrangement of components.

[0139] As an example, in combination with Figure 6 The function implemented by the processing unit 602 in the blockchain node is the same as the function of the processor 701 in Figure 7

[0140] From the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0141] ​The computer readable storage medium, for example, can be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), registers, a hard disk, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing, or any other medium from which a computer can read instructions. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The processor and the storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the storage medium can exist as discrete components. In some implementations, the processor and the storage medium can be located in a single ASIC. The steps of a method or algorithm can be embodied in a program of instructions, either fixed or transitory, in a computer readable storage medium. The program of instructions can be configured to be executed by the processor to perform the methods or algorithms.

[0142] The specific implementation described above is merely an example of the application, but the scope of protection of the application is not limited thereto, and any changes or replacements within the technical scope disclosed in the application should be covered within the scope of protection of the application. Therefore, the scope of protection of the application should be subject to the scope of protection of the claims.

Claims

1. A device authentication method characterized by comprising: The application is applied to a blockchain node in a data verification system comprising a plurality of blockchain nodes and a first device, and comprises the following steps: determining a user attribute set, a resource attribute set, and preset data; the user attribute set comprises a plurality of attribute information of a user device; the resource attribute set comprises a plurality of attribute information of data; the preset data is any one of a plurality of data, and the blockchain node stores the user attribute set and the resource attribute set; configuring a plurality of preset access strategies for the preset data based on the plurality of attribute information of the user device and the plurality of attribute information of the data; obtaining a target data request message of the first device; the target data request message comprises an identifier of target data and request attribute information; the request attribute information comprises an attribute of the first device and an attribute of the target data; the first device is a device requesting the target data, and the attribute of the target data comprises at least one of an identifier, an abstract, a format, an item, a length, and a sharing attribute; determining a target access strategy from the plurality of access strategies based on the identifier of the target data; the target access strategy comprises at least one of a device attribute requirement having an access right to the target data and an attribute requirement of the target data; receiving a verification message from a second device; the verification message is used to request the target access strategy; the second device is a device providing the target data; sending the target access strategy to the second device to enable the second device to verify whether the first device has an access right to the target data; determining a verification result of the first device based on the request attribute information and the target access strategy; the verification result is used to represent whether the first device has an access right to the target data.

2. The method of claim 1, wherein, The attribute of the first device comprises at least one of a unit to which the first device belongs, a department to which the first device belongs, a role of the first device, a responsibility of the first device, and a system to which the first device belongs. 3.A blockchain node, characterized in that, The blockchain node is located in a data verification system comprising a plurality of blockchain nodes and a first device, and the blockchain node comprises a communication unit and a processing unit. The processing unit is configured to determine a user attribute set, a resource attribute set, and preset data; the user attribute set comprises a plurality of attribute information of a user device; the resource attribute set comprises a plurality of attribute information of data; the preset data is any one of a plurality of data, and the blockchain node stores the user attribute set and the resource attribute set; The processing unit is further configured to configure a plurality of preset access strategies for the preset data based on the plurality of attribute information of the user device and the plurality of attribute information of the data; The communication unit is configured to obtain a target data request message of the first device; the target data request message comprises an identifier of target data and request attribute information; the request attribute information comprises an attribute of the first device and an attribute of the target data; the first device is a device requesting the target data, and the attribute of the target data comprises at least one of an identifier, an abstract, a format, an item, a length, and a sharing attribute; The processing unit is further configured to determine a target access policy from the plurality of access policies based on the identification of the target data, wherein the target access policy comprises at least one of a device attribute requirement for having an access right to the target data and an attribute requirement of the target data. The communication unit is further configured to receive a verification message from a second device, wherein the verification message is used to request the target access policy, and the second device is a device providing the target data. The communication unit is further configured to send the target access policy to the second device, so that the second device verifies whether the first device has an access right to the target data. The processing unit is further configured to determine a verification result of the first device based on the request attribute information and the target access policy, wherein the verification result is used to represent whether the first device has an access right to the target data.

4. The blockchain node of claim 3, wherein, The attribute of the first device comprises at least one of a unit to which the first device belongs, a department to which the first device belongs, a role of the first device, a responsibility of the first device, and a system to which the first device belongs. 5.A blockchain node, characterized in that, The device comprises: a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is configured to run a computer program or instructions to implement the device verification method according to claim 1 or 2.

6. A computer-readable storage medium having stored therein instructions, the computer-readable storage medium comprising: When a computer executes the instructions, the computer executes the device verification method according to claim 1 or 2.

Images