Method and apparatus for enforcing cross-domain device access control policy based on blockchain

Abstract

The present application discloses a method and device for forcibly implementing a cross-domain device access control policy based on a blockchain. The method includes: defining an access policy by a responder, reaching a consensus by the in-domain management committee, and submitting the Merkle root of the cross-domain device access control policy to the inter-domain public chain through a smart contract; after a requester initiates an access request, controlling the committees of the requester and the responder to call the smart contract in the inter-domain public chain, and respectively mortgaging a preset amount to establish data exchange between the requester and the responder; determining whether the requester receives correct data sent by the responder. When not received, the requester requests the smart contract to start enforcing the access control process, determining the malicious party in the data exchange through a preset verification method, and punishing the malicious party, which has good fairness and practicability.

Description

Technical Field

[0001] This application relates to the field of information security technology, and particularly to a method and device for forcibly implementing a cross-domain device access control policy based on a blockchain. Background Art

[0002] A complete authentication and access control mechanism is the "nerve center" for secure and efficient data access and exchange between different organizations and departments. Existing access control solutions can be divided into two categories. One is the traditional centralized access control mechanism, such as the access control list applied to router interfaces. This type of traditional access control mechanism relying on a single centralized network topology and a centralized storage and computing system has disadvantages such as single-point collapse and trust concentration. The second type of access control solution is the access control mechanism based on a blockchain. However, in this distributed architecture access control system, the use of blockchain technology replaces the traditional centralized institution. The absence of a trusted third party will lead to disputes. It is difficult to implement dispute arbitration, transaction supervision, etc. through a third party. When there is a contradiction between the two data exchange parties, it is difficult to determine responsibilities.

[0003] The process of access control can be simply described as follows: the requester requests to access a certain resource of a certain device. After the responder verifies the identity of the requester, it returns the corresponding data. However, in order to protect the data to the greatest extent, the data that the user needs to exchange should not be stored and sent by a trusted third party, but independently stored and sent by the device. Due to the point-to-point data sending form, there may be situations in the system where the requester submits an access control request that does not meet the policy, and situations where the requester has met the access control policy, but the responder is dishonest and refuses to send data or sends forged data. At this time, a generalized access control needs to be defined, that is, while ensuring that the resource is not accessed without authorization, ensuring that the data access rights of the requester who meets the access control conditions are not violated, and forcibly implementing access control at the resource owner side. Summary of the Invention

[0004] This application provides a method and device for forcibly implementing a cross-domain device access control policy based on a blockchain, effectively solving disputes between nodes regarding data authenticity.

[0005] An embodiment of the first aspect of the present application provides a method for forcibly implementing a cross-domain device access control policy based on a blockchain, including the following steps: defining an access policy by a responder, reaching a consensus by the in-domain management committee, and submitting the Merkle root of the cross-domain device access control policy to the inter-domain public chain through a smart contract; after a requester initiates an access request, controlling the committees of the requester and the responder to call the smart contract in the inter-domain public chain, and respectively mortgaging a preset amount to establish data exchange between the requester and the responder; determining whether the requester receives correct data sent by the responder, and when not received, requesting the smart contract through the requester to start enforcing the access control process, determining the malicious party in the data exchange through a preset verification method, and punishing the malicious party.

[0006] Optionally, in an embodiment of the present application, it further includes: when the requester receives the correct data sent by the responder, respectively returning the mortgaged preset amount to the accounts of the requester and the responder.

[0007] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes: controlling the requester by the smart contract to submit a policy legal proof within a first preset time, and verifying the policy legal proof. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, respectively return the mortgaged amounts of the requester and the responder. Otherwise, transfer the mortgaged amount of the requester to the responder.

[0008] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes: controlling the responder by the smart contract to submit a data legality proof within a second preset time, and storing the data legality proof by the smart contract; obtaining the data legality proof in the smart contract by the requester and verifying the data legality proof. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, respectively return the mortgaged amounts of the requester and the responder. Otherwise, continue to verify the key legality.

[0009] Optionally, in an embodiment of the present application, when verifying the data legality proof and the verification fails, continue to verify the key legality, including: sending the key obtained by decrypting during verification by the requesting party to the in-domain management committee, and after combining the key with the public key by the in-domain management committee, submitting it to the smart contract. The smart contract executes a plaintext-verifiable encryption verification algorithm to verify whether the symmetric key matches the ciphertext. If it matches, the protocol continues; otherwise, perform the responder data legality verification. The smart contract verifies whether the data can be correctly decrypted according to the symmetric key. If it can, the requesting party makes a false claim and the requesting party is punished; if not, the responder sends an error data tuple and the responder is punished.

[0010] Optionally, in an embodiment of the present application, the performing the responder data legality verification includes: the smart contract requests the responder to provide evidence to prove that the responder has legal data; the responder encrypts the legal symmetric key using the contract public key and submits it to the smart contract. The smart contract uses a plaintext-verifiable algorithm to verify whether the data tuple matches the current symmetric key, and decides to punish the requesting party, the responder, or confiscate the collateral amounts of both parties according to the output result of the algorithm.

[0011] An embodiment of the second aspect of the present application provides a blockchain-based cross-domain device access control policy enforcement device, including: a consensus module for defining an access policy by the responder and reaching a consensus by the in-domain management committee, and submitting the Merkle root of the cross-domain device access control policy to the inter-domain public chain through a smart contract; a switching module for controlling the requesting party and the responder's committee to call the smart contract in the inter-domain public chain and respectively pledge a preset amount after the requesting party initiates an access request, to establish data exchange between the requesting party and the responder; a control module for determining whether the requesting party receives the correct data sent by the responder. When not received, the requesting party requests the smart contract to start enforcing the access control process, and determines the malicious party in the data exchange through a preset verification method, and punishes the malicious party.

[0012] Optionally, in an embodiment of the present application, the control module is further configured to, when the requesting party receives the correct data sent by the responder, return the pledged preset amounts to the accounts of the requesting party and the responder respectively.

[0013] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes: controlling, by the smart contract, the requester to submit a proof of policy legality within a first preset time, and verifying the proof of policy legality. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, return the collateral amounts of the requester and the responder respectively. Otherwise, transfer the collateral amount of the requester to the responder.

[0014] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes:

[0015] Controlling, by the smart contract, the responder to submit a proof of data legality within a second preset time, and storing the proof of data legality through the smart contract; obtaining, by the requester, the proof of data legality in the smart contract, and verifying the proof of data legality. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, return the collateral amounts of the requester and the responder respectively. Otherwise, continue to verify the key legality.

[0016] The method and device for enforcing a cross-domain device access control policy based on blockchain in the present application are aimed at the fairness requirements during the data exchange between the requester and the responder in a decentralized access control system. Aiming at the problems of transaction supervision caused by the lack of a trusted third party in the current system and transaction arbitration in case of disputes, etc., it is intended to combine the blockchain technology, smart contract technology, and plaintext verifiable algorithm that are transparent, open, immutable, and decentralized to study the enforcement function between the requester and the responder in the access control scenario, and ensure that the data access is not affected by malicious requesters and responders.

[0017] Additional aspects and advantages of the present application will be given in part in the following description, become apparent in part from the following description, or be learned through the practice of the present application. Description of the Drawings

[0018] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description of the embodiments in conjunction with the drawings, where:

[0019] Figure 1 Is a flowchart of a method for enforcing a cross-domain device access control policy based on blockchain according to an embodiment of the present application;

[0020] Figure 2 Is a flowchart of a specific method for enforcing a cross-domain device access control policy based on blockchain according to an embodiment of the present application;

[0021] Figure 3 It is a timing diagram in the first stage provided according to an embodiment of the present application;

[0022] Figure 4 It is a timing diagram in the second stage provided according to an embodiment of the present application;

[0023] Figure 5 It is a timing diagram in the third stage provided according to an embodiment of the present application;

[0024] Figure 6 It is a timing diagram in the fourth stage provided according to an embodiment of the present application;

[0025] Figure 7 It is an example diagram of a blockchain-based cross-domain device access control policy enforcement device according to an embodiment of the present application. Detailed implementation manners

[0026] The embodiments of the present application will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions from beginning to end. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present application, and should not be construed as a limitation of the present application.

[0027] In order to effectively resolve disputes between nodes regarding data authenticity in a distributed access control system, the present application introduces blockchain, smart contract technology, and plaintext verifiable encryption algorithms, and combines the idea of game theory to design a set of access control enforcement solutions. Among them, plaintext verifiable encryption can ensure that the ciphertext c is generated from the specified plaintext m given the public key pk, and does not disclose the information of the private key sk. The plaintext verifiable encryption consists of the following four algorithms:

[0028] (1) PCE KeyGen (1 k ) → (pk, sk): The algorithm inputs the security parameter k and outputs the public and private keys pk and sk.

[0029] (2) PCE E (pk, m) → c: The algorithm inputs the public key pk and the plaintext m and outputs the ciphertext c.

[0030] (3) PCE D (sk, c) → m: The algorithm inputs the private key sk and the ciphertext c and outputs the plaintext m.

[0031] (4) PCE check (c, pk, m) → ω: If c is encrypted from m, output ω = 1, otherwise ω = 0.

[0032] The plaintext verifiable algorithm has the following four properties:

[0033] (1) Decryption correctness: For and m ∈ {0, 1} * , Pr[(pk, sk) ← KeyGen(1 k ), c ← Encrypt(1 k , pk, m): Decrypt(1 k , sk, c) = m] = 1.

[0034] (2) Plaintext verification correctness: For and m ∈ {0, 1} * ,

[0035] Pr[(pk, sk) ← KeyGen(1 k ), c ← Encrypt(1 k , pk, m): PCheck(1 k , c, pk, m) = 1] = 1.

[0036] (3) Verification integrity: For and the probabilistic polynomial-time adversary A, the following probability is negligible.

[0037] Pr[(pk, sk) ← KeyGen(1 k ), c ← A(1 k , pk),

[0038] m ← Decrypt(1 k , sk, c): PCheck(1 k , c, pk, m) = 0]

[0039] (4) Verification reliability: For and the probabilistic polynomial-time adversary A, the following probability is negligible.

[0040] Pr[(pk, sk) ← KeyGen(1 k ), (c, m * ) ← A(1 k , pk),

[0041] m ← Decrypt(1 k , sk, c): m ≠ m * ∧PCheck(1 k , c, pk, m) = 1]

[0042] The plaintext-verifiable encryption algorithm adopted in the scheme is based on the elliptic curve public key cryptosystem ECC and the Elgamal public key cryptosystem. It is improved by introducing the elliptic curve cryptosystem on the basis of the construction based on Elgamal in the literature.

[0043] This application includes five entities:

[0044] (1) In-Domain Management Committee (DMC): An in-domain management committee is usually the management department of an organization. The DMC exists externally in the form of an in-domain server, mainly responsible for interacting with Internet of Things (IoT) device nodes and management committees of other domains, and managing IoT device information, resources, and their access policies through the permission chain within the domain. At the same time, it is responsible for the regular update of Merkle tree information on the inter-domain public chain, and can greatly reduce the computing burden of IoT devices. Inside the in-domain management committee, the members are composed of nodes with certain computing power and storage resources within the security domain. The committee member identity does not conflict with the resource owner identity. The number of members in the committee should satisfy, where is the number of malicious nodes; the Byzantine fault-tolerant consensus algorithm is used inside the committee to complete the node authentication and policy management process. There is a replaceable leader in the committee, and the leader is elected by each security domain itself. The specific leader election algorithm and committee member election algorithm are determined independently by the security domain and are not described in this solution.

[0045] (2) Key Generation Center (KGC): In this solution, it is assumed that the key generation center is honest and is mainly responsible for providing services such as the generation, storage, backup, update, recovery, and query of encryption and decryption keys and signature keys, and providing public key legitimacy certificates.

[0046] (3) Internet of Things Device (IoTD): IoT devices mainly include sensors, intelligent processing devices, etc. Due to the large differences in the computing capabilities of devices in the IoT scenario, this solution assumes that there are multiple proxy nodes within the security domain, which are used to obtain resources from IoT devices with lower computing capabilities and act as proxies for the devices to perform data encryption, decryption, and sending operations during data exchange. This solution describes the proxy nodes as part of the IoT devices. IoT devices are identified by a unique identity ID, and the data in the devices exists in the form of resources. An IoT device can store multiple resources. For a user's access request, whether the device and resources can be accessed is completely determined by the management committee according to the pre-set access control policy. The device only follows the instructions of the committee and does not need to perform complex operations such as verification.

[0047] (4) Device Owner (DO): The device owner refers to the owner of the device and its resources. The relationship between the device and the device owner can be described as follows: A device owner can own multiple devices, and a device can only be managed by one owner. The device owner is only responsible for defining the access control policy, that is, defining who can access the resources in the device and in what way, etc. The committee conducts the legality verification of the policy and stores it on the chain. Since the processing capacity of the owner may not meet the needs of managing a large number of devices, the management right of the device and its resources is entrusted to the management committee, which is given the power to manage the device under the given policy. At the same time, device owners with computing and storage capabilities meeting certain conditions can join the in-domain management committee.

[0048] (5) Blockchain supporting smart contracts: The architecture of this solution includes a public chain jointly maintained among security domains. The public chain needs to deploy smart contracts to store the Merkle root value of the access control policy, which is convenient for preventing policy tampering among security domains and providing support for the mandatory implementation of access control.

[0049] Based on the plaintext verifiable encryption technology, this application designs a complete "mortgage - arbitration" mechanism. The general process can be described as follows: The main and object devices query the access control policy and forward requests through the committee. In the optimistic case, when the subject successfully verifies the object data received, the protocol ends, and the mortgage amounts of both parties are refunded to their original accounts respectively. In the non - optimistic case, there may be situations where the object sends false data or the subject makes false appeals. In this case, it is necessary to enforce the access control policy through smart contract technology, requiring both parties of the transaction to submit evidence in a specified form within a specified time limit. The evidence is constructed through cryptographic means such as verifiable encryption and signatures. After the smart contract verifies the evidence, it analyzes the existing possible situations to achieve the arbitration of disputes. In the non - optimistic case, the protocol will terminate when one party of the transaction is punished and its mortgage amount is transferred to the other party.

[0050] The method for mandatorily implementing cross - domain device access control policy based on blockchain in this application has good fairness and practicability. The specific proof of fairness is as follows:

[0051] In the access control mandatory implementation plan, the misbehavior of either the device owner or the committee within the security domain will lead to the failure of the optimistic path of the protocol. Therefore, to simplify the fairness proof of this plan, the device owner and the committee are regarded as a whole and described as the requester and the responder.

[0052] 1. Definition of fairness

[0053] Let the requester in the access control enforcement phase be A, the responder be B, the evidence submitted to the smart contract be I, and the final result output of the smart contract E be o. If P(x) is defined as punishing x, then the value set of o is O = {P(φ), P(A), P(B), P(A, B)}. The execution model of the smart contract is defined as:

[0054] o = E(A A , I B )

[0055] Among them, the evidence tuples I A 、I B are respectively composed of the following parts:

[0056] I A ≡ (I pk , I mr , I p , I pf , I r , I k )

[0057] I B ≡ (I pk , I mr , Id, I d′ , I k )

[0058] I pk is the user public key, I mr is the policy Merkle tree root value, I p is the policy, I pf is the policy Merkle tree proof, I r is the local verification result of the requester, I k is the session key, I d is the encrypted session key, I d′ is the encrypted data.

[0059] Suppose the set of possible adversaries is V = {φ, A, B, {A, B}}. For any adversary v ∈ V, the honest party can be expressed as u = {A, B}\v. Fairness can be defined as for any requester A and responder B, Pr[E(I A , I B ) = P(v)] ≈ 1, Pr[E(I A , I B ) = P(u)] ≈ 0. Fairness means that in the access control enforcement phase, the malicious party will not be exempt from punishment, and the honest party will not be punished.

[0060] 2. Proof of fairness

[0061] (1) The requester is malicious

[0062] This section discusses the case where v = A and u = B.

[0063] In the first stage of the protocol execution, assume that v submits false to make E(I A , I B ) ≠ P(A), that is, let At this time, there are two cases: one is that there is a hash collision such that Since the hash function is collision-resistant, this case does not hold; the other is that the adversary defines false I mr in the initialization stage to make the equation hold. Since I mr is jointly determined by A and B, the false value cannot be agreed upon between the two parties. In summary, in the first stage, v cannot submit false evidence that can pass the verification.

[0064] In the third stage of the protocol execution, assume that v submits false to make E(I A , I B ) ≠ P(A). Since B is honest at this time, the I d , I d′ submitted by it in the second stage can pass the local verification of v. At this time, v lies by that is, I d , I d′ cannot pass the verification to do evil. At this time, there are three cases: one is that the submitted by v is the decryption result of I d . After submitting it to the contract, the contract executes E(I A , I B ) = P(A), and this case does not hold; the second is that v forges so that it can decrypt I d′ and obtain the data data = d||Sig(H(d * )). In the worst case, that is, the selected encryption and signature algorithms do not have verification capabilities, case two can be reduced to the adversary v being able to construct hash(d) = H(d * ), but d ≠ d * , satisfying data = d||Sig(H(d * )). Due to the collision resistance of the hash function, case two cannot be realized; the third case is that the submitted by v cannot pass the verification of the plaintext verifiable algorithm, and the protocol enters the fourth stage.

[0065] In the fourth stage, the honest party B submits legal I k , passes the verification of the smart contract. At this time, the execution result of the smart contract is E(I A , I B) = P(A). A rational adversary will not make such a choice.

[0066] In summary, when the requester is malicious, v cannot submit false evidence that can pass the verification.

[0067] (2) The responder is malicious

[0068] This part discusses the case where v = B and u = A.

[0069] In the second stage of the protocol execution, assume that v submits false to make E(I A , I B ) ≠ P(B). Assume can pass the local verification of u. At this time, there are two cases: one is that the forged by v is not encrypted using PCE E , or not encrypted using the requester's public key, but passes the verification of PCE check at u. Case one can be reduced to the adversary v's ability to break the verification integrity of the plaintext verifiable algorithm. Since a polynomial-time adversary does not have such an ability, this case does not hold, and the protocol jumps to the fourth part; the other is that the session key obtained by decrypting is forged by v, not the key that matches the correct decryption, but can decrypt and obtain the data data = d * ||Sig(H(d * ))). In the worst case, that is, the selected encryption and signature algorithms do not have verification capabilities, case two can be reduced to the adversary v being able to construct hash(d′) = H(d * ), but d′ ≠ d * , satisfying data * = d * ||Sig(H(d′)). Due to the collision resistance of the hash function, case two cannot be achieved. *

[0070] In the fourth stage of the protocol execution, assume that v continues to submit false to make E(I A , I B ) ≠ P(B). Assume that v can forge a legitimate to make the decryption result pass the verification. It needs to satisfy and This is equivalent to the adversary being able to break the verification reliability of the plaintext verifiable algorithm, indicating that this case does not hold.

[0071] In summary, in the case where the responder is malicious, v cannot submit false evidence that can pass the verification.

[0072] (3) Both the requester and the responder are malicious

[0073] This part discusses the case where v = {A, B} and u = φ.

[0074] In the second stage of the protocol execution, assume that B submits false In the third stage of the protocol execution, assume that A submits false such that E(I A , I B ) ≠ P(A, B). In the first case, the contract output result is E(I A , B) = P(φ). The contract result shows that when A fails to verify the false data locally and feeds back success to the contract, this act violates the rational premise of A, so this case does not hold. In the second case, assume that the forged by A passes the verification, making E(I A , I B ) = P(B). Then it means that the adversary can break the verification integrity of the plaintext verifiable algorithm. Since an adversary in probabilistic polynomial time does not have this ability, this case does not hold. In the third case, the forged by A does not pass the verification, and the protocol enters the fourth stage. At the same time, the forged by B passes the contract verification, which is also equivalent to the adversary being able to break the verification reliability of the plaintext verifiable algorithm, indicating that this case does not hold.

[0075] In summary, in the case where both the requester and the responder are malicious, v cannot submit false evidence that can pass the verification.

[0076] The following will elaborate in detail the method for enforcing cross - domain device access control policies based on blockchain with reference to the accompanying drawings.

[0077] The symbol definitions of the method for enforcing cross - domain device access control policies based on blockchain are shown in Table 1 below.

[0078] Table 1 Symbol Definitions

[0079]

[0080] Figure 1 and Figure 2 is a flowchart of a method for enforcing cross - domain device access control policies based on blockchain provided by an embodiment of this application.

[0081] As Figure 1 and Figure 2As shown, the blockchain-based cross-domain device access control policy enforcement method includes the following steps:

[0082] In step S101, the access policy is defined by the respondent, and a consensus is reached by the intra-domain management committee, and the Merkle tree root of the cross-domain device access control policy is submitted to the inter-domain public chain through a smart contract.

[0083] like Figure 3 As shown, this is the request arbitration and policy verification stage, which is used to ensure that the requester A cannot forge an access control request.

[0084] First, in step 1, the respondent defines the access control policy, which is reviewed and agreed upon by the intra-domain committee, and then the Merkle tree root of the policy is submitted to the inter-domain public chain through a smart contract.

[0085] In step S102, after the requester initiates an access request, the committee controlling the requester and the responder calls the smart contract in the inter-domain public chain and pledges a preset amount respectively to establish data exchange between the requester and the responder.

[0086] Step 2: After the requester initiates the access request, the requester and the responder committee call the smart contract in the public chain and pledge a certain amount of money for the subsequent access control enforcement process. The requester committee verifies the access request and forwards it to the responder for secondary verification. If the verification is successful, the two committees notify the user and the device and approve the user's access request.

[0087] In step S103, it is determined whether the requesting party has received the correct data sent by the responding party. If not, the requesting party initiates the access control process by making a request to the smart contract, and determines the malicious party in the data exchange through a preset verification method, and punishes the malicious party.

[0088] Optionally, in one embodiment of the present application, when the requesting party receives the correct data sent by the responding party, the preset amount of the mortgage is returned to the accounts of the requesting party and the responding party respectively.

[0089] Optionally, in one embodiment of the present application, a malicious party in a data exchange is determined through a preset verification method, and the malicious party is punished, including: controlling the requesting party through a smart contract to submit a policy legitimacy certificate within a first preset time, and verifying the policy legitimacy certificate. If the verification passes, the cross-domain device access control policy continues to be executed, and after the policy execution is completed, the mortgage amounts of the requesting party and the responding party are returned respectively, otherwise the mortgage amount of the requesting party is transferred to the responding party.

[0090] Step 3: Data exchange occurs between the requester and the responder. At this time, if the requester does not receive legitimate data, or if the requester is malicious, it can file a complaint with the contract to enforce the access control process.

[0091] Step 4: The smart contract requires Party A to submit a policy and a Merkle proof (p, mproof) within a specified time.

[0092] Step 5: The contract performs the following two steps to verify the legitimacy of (p, mproof). The verification algorithm is shown in Table 2. If the access control policy verification fails, it means that Party A, the requester, does not have a legitimate access control policy, and this complaint is forged by Party A and is a false complaint. Therefore, Party A is punished.

[0093] If the policy and proof satisfy the Merkle root value mroot in the public chain, the protocol continues to execute;

[0094] If not, the contract transfers Party A's collateral amount to the responder Party B to enforce the punishment.

[0095] Table 2 Policy Legitimacy Verification Algorithm

[0096]

[0097] Optionally, in an embodiment of the present application, the malicious party in the data exchange is determined through a preset verification method, and the malicious party is punished, including: controlling the responder to submit a data legality proof within a second preset time through the smart contract, and storing the data legality proof through the smart contract; obtaining the data legality proof in the smart contract by the requester, and verifying the data legality proof. If the verification passes, the cross-domain device access control policy is continued to be executed, and after the policy execution ends, the collateral amounts of the requester and the responder are respectively returned. Otherwise, the key legality is continued to be verified.

[0098] Phase II, Digital Evidence Collection and Verification

[0099] The timing diagram of Phase II is as shown in the appendix Figure 4 This phase requires the responder Party B to submit evidence in a specified form within a specified time and verify it at device a to ensure that device b sends true and valid data.

[0100] Step 6: The contract requires the responder to submit a data legality proof within a specified time, and b constructs an evidence tuple {α, β}:

[0101] d = (x, s)

[0102]

[0103] β = Enc(k, d)

[0104] Step 7: When Committee B receives the evidence tuple, it forwards it to the smart contract for storage by the contract.

[0105] Step 8: A obtains {α, β} from the contract and verifies the legality of the evidence tuple through the algorithm in Table 3. If the r1 output by the algorithm is 0, the protocol enters Phase Three; if r1 = 1, the protocol ends normally and the collateral amount is refunded.

[0106] Table 3. Evidence Tuple Verification Algorithm

[0107]

[0108] In Phase Two, if the algorithm outputs 1, it proves that the data sent by Respondent B is correct, can successfully decrypt the data and pass the verification, the protocol ends and the collateral amount is refunded; if the output is 0, it indicates that malicious behavior still exists and the protocol continues to execute.

[0109] Optionally, in the embodiments of the present application, the verification of the data legality proof is performed. When the verification fails, the verification of the key legality is continued, including: the requester sends the key obtained by decrypting during verification to the in-domain management committee, and after combining the key with the public key by the in-domain management committee, it is submitted to the smart contract. The smart contract executes the verification algorithm of plaintext verifiable encryption to verify whether the symmetric key matches the ciphertext. If it matches, the protocol continues; otherwise, the verification of the respondent's data legality is performed; the smart contract verifies whether the data can be correctly decrypted according to the symmetric key. If it can, the requester makes a false claim and is punished; if not, the respondent sends an incorrect data tuple and the respondent is punished.

[0110] Phase Three: Key Legality Verification

[0111] The timing diagram of Phase Three is as shown in the appendix Figure 5 It is shown that Phase Three is used to determine the party where malicious behavior occurred in Phase Two.

[0112] Step 9: The requester sends the key obtained by decrypting in Phase Two to the committee.

[0113] Device a notifies the committee of "verification failed" and sends k1 obtained by decrypting α. Given that r1 = 0 is output in Phase Two, the symmetric key k1 or data d1 obtained by decryption at this time is invalid. Therefore, sending the symmetric key k1 to the smart contract will not disclose the real data information.

[0114] Step 10: The committee combines the key with its public key and submits it to the smart contract.

[0115] The committee constructs a key tuple {k1, pk A}, and submits it to the contract, where pk A is the public key of A.

[0116] Step 11: Execute the verification algorithm of verifiable encryption of the contract plaintext to verify whether the symmetric key matches the ciphertext.

[0117] Execute the verification algorithm of verifiable encryption of the contract to verify whether the symmetric key k1 is the decryption result of:

[0118] c = PCheck(k1, pk A , α)

[0119] Step 12: If they match, the protocol continues; if not, the protocol jumps to Phase Four.

[0120] c = 1 indicates that both Party A and Party B are honest about α, and the protocol jumps to Step 13; if c = 0, the protocol jumps to Step 15 of Phase Four, indicating that the symmetric key does not match α, that is, both trading parties have malicious behavior.

[0121] Step 13: The contract verifies whether the data can be correctly decrypted according to the symmetric key.

[0122] The contract continues to verify whether k1 can correctly decrypt the data:

[0123] d2 = Dec(k1, β)

[0124] Convert d2 to (x2, s2 = Sig(sk B , H(x2)))

[0125] r2 = VerifySig(pk B , s2)

[0126] Step 14: If it can, it indicates that the requester makes a false claim and punishes it; if not, it indicates that the responder sends an incorrect data tuple and the contract punishes the responder.

[0127] If r2 = 1, it indicates that the data tuple sent by the responder Party B is correct and Party A makes a false claim, and the contract transfers Party A's collateral amount to Party B; if r2 = 0, it indicates that the data cannot be correctly decrypted by the decryption key k1 and the data tuple sent by the responder is incorrect, and the contract transfers Party B's collateral amount to Party A.

[0128] Optionally, in the embodiment of the present application, the verification of the responder's data legality includes: requiring the responder to provide evidence through a smart contract to prove that the responder has legal data; encrypting the legal symmetric key by the responder using the contract public key and submitting it to the smart contract, and the smart contract uses the plaintext verifiable algorithm to verify whether the data tuple matches the current symmetric key, and decides to punish the requester, the responder, or confiscate the collateral amounts of both parties according to the output result of the algorithm.

[0129] Phase Four: Secondary Evidence Collection and Verification

[0130] The chronological diagram of Phase Four is as attached Figure 6 as shown. Phase Four is used to determine the following three situations:

[0131] 1. B is honest and A is malicious: A sends a false k1 to the smart contract, resulting in the failure of key verification.

[0132] 2. B is malicious and A is honest: The data α sent by B cannot be correctly decrypted, resulting in the failure of key verification.

[0133] 3. B is malicious and A is malicious: A sends a false k1 to the smart contract, and B submits an invalid α value.

[0134] Step 15: The contract requires the responder to provide evidence that it has legitimate data, that is, it has a valid k value.

[0135] Step 16: The responder encrypts the legitimate symmetric key using the contract public key and submits it to the contract.

[0136] The responder submits the data δ = Enc(pk SC , k) to the contract.

[0137] Step 17: The contract uses a plaintext verifiable algorithm to verify whether the data tuple matches the current symmetric key, and decides to punish the requester, the responder, or confiscate the collateral amounts of both parties according to the output result of the algorithm.

[0138] The contract decrypts with the private key to obtain k3, uses the PCE check function to verify k3, and runs Algorithm 3 again to verify the legitimacy of the data tuple and k3. Let the output results of the algorithm be k3, d3, and r3 respectively.

[0139] c3 = PCE check (k3, pk A , α)

[0140] For the above situations, the results may be:

[0141] 1. c3 = 1, r3 = 1, and the contract transfers A's collateral amount to B.

[0142] 2. If c3 = 0, the contract transfers B's collateral amount to A.

[0143] 3. If c3 = 1, r3 = 0, the contract confiscates the collateral amounts of A and B.

[0144] The key issue in this stage is whether B has a valid k value so that the data tuple {α, β} can pass the verification. If B can provide a valid k, it means that the k1 sent by the requester A is forged; if B cannot provide a valid k, it means that B has cheated in the data tuple, and it should continue to judge whether A has cheated. In the case of c3 = 1, the α provided by B can be decrypted to obtain the correct session key, and the key submitted by A in stage 3 has not passed the verification, indicating that both A and B have malicious behavior.

[0145] The plaintext verifiable algorithm used in the scheme can be specifically described as:

[0146] Key generation algorithm:

[0147]

[0148] Verifiable encryption algorithm:

[0149]

[0150] Verifiable decryption algorithm:

[0151]

[0152]

[0153] Verification algorithm:

[0154]

[0155] In summary: This application includes the initialization process, optimistic and non-optimistic dual paths, which are described as follows:

[0156] Initialization phase: During the system initialization phase, a public blockchain is initialized; each security domain autonomously runs the leader election algorithm and committee member election algorithm to complete the election of the domain management committee; the domain management committee initializes a consortium chain, initializes the BFT algorithm, plaintext verifiable encryption, and other related cryptographic parameters.

[0157] Optimistic path: The optimistic path represents the situation where the committees and device owners of the requester and responder are honest. In the optimistic path, the devices of the subject and the object are controlled by the committees of both parties, and the honest committees will follow the predetermined access control policy when issuing instructions, so both the subject and the object follow the policy. If the protocol is executed in an optimistic path, it means that the requester successfully decrypts the responder's data during the data exchange process and completes the verification process, then the collateral amounts of both parties will be returned to the accounts of both parties along the original path.

[0158] Non-optimistic path: During the execution of the protocol, situations such as the request submitted by the user not meeting the access control policy, the responder rejecting a legitimate request, or the data sent by the device failing to pass verification can all lead to the termination of the protocol. The non-optimistic path represents such situations that violate the pre-established access control policy, caused by dishonest committees or malicious device owners, and bring potential losses to both trading parties. In this case, the participants can initiate a request to the smart contract to arbitrate the malicious party in the transaction and impose corresponding penalties or compensations according to the behaviors of both participating parties. In the non-optimistic path, the protocol is divided into four stages according to possible malicious situations, which will not be repeated here.

[0159] Suppose the user in security domain A is the access requestor and security domain B is the responder. The description of stage one is as follows: If during the data exchange process, the requestor meets the policy but the responder refuses to respond, the requestor can file a complaint with the smart contract. After receiving the arbitration request, the smart contract analyzes two situations: one is that requestor A does not meet the access control policy but initiates a false complaint; the other is that responder B refuses to provide legitimate data to the requestor who meets the policy.

[0160] According to the method for enforcing cross-domain device access control policy based on blockchain proposed in the embodiments of the present application, by applying blockchain, smart contract and plaintext verifiable algorithm, the function of enforcing cross-domain access control in a decentralized access control system scenario is realized. A public chain between security domains and a management committee within a security domain are established, and the policy Merkle root is stored in the public chain to prevent cross-domain policy tampering and man-in-the-middle attacks, so that the function of enforcing access control is executed through a bet protocol guided by game theory. It can protect the legitimate rights and interests of both parties in the data exchange process during access control. Specifically, the present application has fairness, can punish malicious requestors or responders, and ensure that the legitimate rights and interests of honest parties are not violated.

[0161] Next, a device for the method for enforcing cross-domain device access control policy based on blockchain proposed in the embodiments of the present application is described with reference to the accompanying drawings.

[0162] Figure 7 It is a block diagram example of a device for the method for enforcing cross-domain device access control policy based on blockchain according to the embodiments of the present application.

[0163] As Figure 7 shown, the device 10 for enforcing cross-domain device access control policy based on blockchain includes: a consensus module 100, an exchange module 200, and a control module 300.

[0164] Among them, the consensus module 100 is used to define an access policy by the responder and reach a consensus by the in-domain management committee, and submit the Merkle root of the cross-domain device access control policy to the inter-domain public chain through a smart contract. The exchange module 200 is used to control the committee of the requester and the responder to call the smart contract in the inter-domain public chain and respectively pledge a preset amount after the requester initiates an access request, so as to establish data exchange between the requester and the responder. The control module 300 is used to determine whether the requester receives the correct data sent by the responder. When the correct data is not received, the control module 300 requests the smart contract through the requester to start enforcing the access control process, determines the malicious party in the data exchange through a preset verification method, and punishes the malicious party.

[0165] Optionally, in an embodiment of the present application, the control module is further configured to return the pledged preset amount to the accounts of the requester and the responder respectively when the requester receives the correct data sent by the responder.

[0166] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes: controlling the requester to submit a policy legality certificate within a first preset time through a smart contract, and verifying the policy legality certificate. If the verification passes, continue to execute the cross-domain device access control policy, and return the pledged amounts of the requester and the responder respectively after the policy execution ends. Otherwise, transfer the pledged amount of the requester to the responder.

[0167] Optionally, in an embodiment of the present application, determining the malicious party in the data exchange through a preset verification method and punishing the malicious party includes:

[0168] Controlling the responder to submit a data legality certificate within a second preset time through a smart contract, and storing the data legality certificate through the smart contract; obtaining the data legality certificate in the smart contract by the requester and verifying the data legality certificate. If the verification passes, continue to execute the cross-domain device access control policy, and return the pledged amounts of the requester and the responder respectively after the policy execution ends. Otherwise, continue to verify the key legality.

[0169] It should be noted that the foregoing explanation of the embodiments of the method for enforcing the cross-domain device access control policy based on blockchain also applies to the device for enforcing the cross-domain device access control policy based on blockchain in this embodiment, and will not be elaborated here.

[0170] The cross-domain device access control policy enforcement device based on blockchain proposed in the embodiments of the present application realizes the enforcement function of cross-domain access control in a decentralized access control system scenario by applying blockchain, smart contracts and plaintext verifiable algorithms. A public chain between security domains and a management committee within a security domain are established, and the policy Merkle root is stored in the public chain to prevent cross-domain policy tampering and man-in-the-middle attacks, so that the enforcement function of access control is executed through a bet protocol guided by game theory. It can protect the legitimate rights and interests of both parties in data exchange during the access control process. Specifically, the present application has fairness, which can punish malicious requesters or responders and ensure that the legitimate rights and interests of honest parties are not violated.

[0171] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or N embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0172] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "N" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0173] Any process or method description shown in a flowchart or described in other ways herein can be understood as representing a module, segment, or part of code including one or more executable instructions for implementing a customized logical function or process, and the scope of the preferred embodiments of the present application includes additional implementations, where the functions can be executed in a substantially simultaneous manner or in the reverse order according to the functions involved, rather than in the order shown or discussed, which should be understood by those skilled in the art of the embodiments of the present application.

Claims

1. A method for enforcing cross - domain device access control policies based on blockchain, characterized in that, It includes the following steps: The access policy is defined by the responder and consensus is reached by the in-domain management committee. The Merkle root of the cross-domain device access control policy is submitted to the inter-domain public chain through a smart contract. After the requester initiates an access request, the committees of the requester and the responder are controlled to call the smart contract in the inter-domain public chain, and a preset amount is mortgaged respectively to establish data exchange between the requester and the responder. It is judged whether the requester receives the correct data sent by the responder. When not received, the requester requests the smart contract to start enforcing the access control process, and the malicious party in the data exchange is determined through a preset verification method, and the malicious party is punished. Among them, determining the malicious party in the data exchange through the preset verification method and punishing the malicious party includes: The smart contract controls the requester to submit a policy legal proof within the first preset time, and verifies the policy legal proof. If the verification passes, the cross-domain device access control policy is continued to be executed, and after the policy execution ends, the mortgaged amounts of the requester and the responder are returned respectively. Otherwise, the mortgaged amount of the requester is transferred to the responder. The smart contract controls the responder to submit a data legality proof within the second preset time, and the smart contract stores the data legality proof. The requester obtains the data legality proof in the smart contract and verifies the data legality proof. If the verification passes, the cross-domain device access control policy is continued to be executed, and after the policy execution ends, the mortgaged amounts of the requester and the responder are returned respectively. Otherwise, the key legality is continuously verified.

2. The method according to claim 1, wherein It also includes: When the requester receives the correct data sent by the responder, the preset mortgaged amounts are respectively returned to the accounts of the requester and the responder.

3. The method according to claim 1, wherein Verifying the data legality proof. When the verification fails, continuously verifying the key legality includes: The requester sends the key obtained by decrypting during verification to the in-domain management committee, and after combining the key with the public key by the in-domain management committee, it is submitted to the smart contract. The smart contract executes the verification algorithm of plaintext verifiable encryption to verify whether the symmetric key matches the ciphertext. If it matches, the protocol continues. Otherwise, the responder data legality verification is performed. The smart contract verifies whether the data can be correctly decrypted according to the symmetric key. If it can, the requester makes a false appeal and the requester is punished. If not, the responder sends an incorrect data tuple and the responder is punished.

4. The method according to claim 3, characterized in that, Performing the responder data legality verification includes: The smart contract requires the responder to provide evidence to prove that the responder has legal data. The responder encrypts a legal symmetric key using the contract public key and submits it to the smart contract. The smart contract uses a plaintext-verifiable algorithm to verify whether the data tuple matches the current symmetric key, and based on the output result of the algorithm, decides to punish the requester, the responder, or confiscate the collateral amounts of both parties.

5. A cross-domain device access control policy enforcement device based on blockchain, characterized in that, Including: A consensus module for defining access policies through the responder and reaching a consensus by the in-domain management committee, and submitting the Merkle root of the cross-domain device access control policy to the inter-domain public chain through the smart contract; An exchange module for controlling the requester and the committee of the responder to invoke the smart contract in the inter-domain public chain after the requester initiates an access request, and respectively mortgaging a preset amount to establish a data exchange between the requester and the responder; A control module for determining whether the requester has received the correct data sent by the responder. When not received, the control module requests the smart contract through the requester to start enforcing the access control process, and determines the malicious party in the data exchange through a preset verification method and punishes the malicious party. Among them, determining the malicious party in the data exchange through the preset verification method and punishing the malicious party includes: Controlling, through the smart contract, the requester to submit a proof of policy legality within a first preset time and verifying the proof of policy legality. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, return the collateral amounts of the requester and the responder respectively; otherwise, transfer the collateral amount of the requester to the responder; Controlling, through the smart contract, the responder to submit a proof of data legality within a second preset time and storing the proof of data legality through the smart contract; Obtaining, through the requester, the proof of data legality in the smart contract and verifying the proof of data legality. If the verification passes, continue to execute the cross-domain device access control policy, and after the policy execution ends, return the collateral amounts of the requester and the responder respectively; otherwise, continue to verify the key legality.

6. The device according to claim 5, characterized in that The control module is further configured to, when the requester receives the correct data sent by the responder, return the preset mortgaged amount to the accounts of the requester and the responder respectively.

Images