Decentralized data access control method for cross-domain cooperation of unmanned aerial vehicle

Abstract

The invention discloses a decentralized data access control method for cross-domain cooperation of an unmanned aerial vehicle, the method is based on a block chain network, an access control module based on a smart contract is deployed on the block chain network, an access control algorithm ScaBAC (Smart-Enabled Access Control) is embedded in the module, and the access control module is connected with the block chain network through the block chain network. An attribute-based decentralized access control algorithm driven by a smart contract comprises the working steps of data permission expression, data access execution and data permission transmission and obtainment, the method of the invention well quantifies the permission attribute of unmanned aerial vehicle data in a decentralized environment, supports flexible authorization in a dynamic task, and improves the reliability of the unmanned aerial vehicle data. And efficient cooperation of on-chain automatic decision and off-chain data verification is realized through the smart contract, and controllability and traceability of the unmanned aerial vehicle data circulation process are ensured. According to the method, real-time permission updating in a multi-unmanned aerial vehicle cooperative task can be well supported, and fine-grained permission expression is achieved.

Description

Technical Field

[0001] The present invention belongs to the field of drone data security and blockchain technology, and in particular relates to a decentralized data access control method for cross-domain collaboration of drones, which is used to implement fine-grained management, automatic decision-making and trusted flow of data permissions in drone swarms during dynamic tasks. Background Art

[0002] With the rapid development of drone technology, drones are increasingly being used in military, logistics, agriculture, disaster relief, and other fields. However, in large-scale collaborative scenarios, balancing the security and real-time requirements of drones faces challenges. This requires a new drone data access control technology to support trusted collaborative operations in complex airspaces.

[0003] Existing drone data access control technology has the following problems:

[0004] 1) Centralized Dependence: Relying on a central server or cloud platform for permission management, which is vulnerable to single point failures and malicious attacks;

[0005] 2) Rigid permissions: Traditional ABAC strategies cannot adapt to the dynamic networking environment of drones, and permission adjustments lag behind.

[0006] 3) Insufficient coordination between on-chain and off-chain: Data storage and access decisions are separated, resulting in low verification efficiency and difficulty in traceability.

[0007] For example, patent CN202410367300.7 proposes a drone data sharing solution based on attribute encryption. However, this solution relies on a centralized policy server and cannot support real-time permission updates in multi-drone collaborative missions. Furthermore, existing blockchain access control schemes (such as BCAC) are limited by on-chain storage performance, making it difficult to implement fine-grained permission expression. Summary of the Invention

[0008] In response to the above technical problems existing in the prior art, the present invention aims to provide a decentralized data access control method for cross-domain collaboration of drones. The technical problems that the present invention aims to solve include the following:

[0009] 1) How to quantify the permission attributes of drone data in a decentralized environment and support flexible authorization in dynamic tasks;

[0010] 2) How to achieve efficient coordination between on-chain automated decision-making and off-chain data verification through smart contracts;

[0011] 3) How to ensure the controllability and traceability of the drone data flow process.

[0012] The technical solution adopted by the present invention to solve its technical problem is:

[0013] The decentralized data access control method for cross-domain collaboration of UAVs described in this invention is based on the construction of an effective decentralized access control model. Figure 1 The decentralized data access control model uses the blockchain network as its underlying architecture and consists of a trusted authority (TA), data supply drones, data request drones, an ownership and access control module (OSAC) deployed on the blockchain, and an off-chain data storage module (IPDS) based on interplanetary files.

[0014] Furthermore, the model framework includes the following related modules:

[0015] 1) Blockchain Network. A blockchain network uses a consortium chain as the underlying architecture supporting its model. It is typically composed of geographically distributed entities, such as businesses and government agencies, connected through peer-to-peer communication. These entities, acting as fully trusted blockchain nodes, are responsible for performing tasks related to data access, such as transaction verification, broadcasting, block generation, and consensus. Data access control and flow management are implemented by deploying a data access control module on the blockchain and strictly following the module's embedded access control algorithm.

[0016] 2) Trusted Authority TA. As the initialization component, the trusted authority is responsible for providing system parameters to any participant who attempts to join the model, generating identity information of the digital certificate (including a pair of public keys generated by the PKI system) Pub and private key Pri ), only users who have obtained the certificate can join the blockchain network and call the relevant interface to perform data sharing tasks. The published transaction data must be signed by the entity account with the private key so that other users can verify the authenticity of the transactions in the block.

[0017] 3) Data Provider Drones, Data Permissions, and Access Policies. Data Provider Drones (DPs) are data-providing drones responsible for customizing permissions and access control policies for their data and storing them in the on-chain OSAC module. Furthermore, DPs send data in encrypted form (Encry(Data)) to the IFDS and synchronize the data's storage address on the IFDS to the blockchain ledger through blockchain transactions. Data permissions are defined as the intrinsic permission attributes of data, serving as credentials for data access and transfer. They not only define access permissions but also encompass fine-grained permissions such as data ownership and data transfer and use rights. A simple access policy can be formally expressed as P = (S, O, A, λ), where S represents the set of access subjects, O represents the set of data resources, and A represents the set of data permissions. λ:S×O→A represents the access control function, which maps subjects and resources to the set of data permissions.

[0018] 4) Data Requesting Drones and Data Access Permission Proof. Data Requesting Drones (DRs) are drones that seek to access data resources, also referred to here as data access machines. DRs use the OSAC module to match their attributes to obtain permission proofs for the corresponding data, and then use these permission proofs to access and use the data. The activities of DRs are recorded in the blockchain's distributed ledger to ensure traceability of the access process.

[0019] 5) Smart Contract-Based Access Control Module OSAC. The OSAC module is the core component of the model to implement data access control. This component is essentially a smart contract system deployed on the blockchain, supporting decentralized access control functions without centralized third-party service providers. This process is modeled as a smart contract policy-driven access control algorithm, including two major functions: data permission expression and permission management. The former is responsible for generating and maintaining permission tokens ProofO wner , providing fine-grained permission settings for data providers. The latter maintains a dictionary-type policy information list Π = (P1; P2; ...; PM) for access control decisions, where P1; P2; ...; PM represent different policies, and constructs automated decision-making technology by integrating attribute-based access control algorithms.

[0020] 6) Data Storage Module IFDS. IFDS is a distributed data storage module based on the InterPlanetary File System. As a decentralized storage component, it uses content addressing to uniquely identify each data file in the data sharing network and reduce storage pressure on the blockchain system. In the model, IFDS provides persistent and reliable storage for the shared data ciphertext Encry(Data) sent by the data supply drone and returns a unique address identifier (URL). The data supply machine synchronizes the URL to the blockchain through transactions, serving as the entry point for data access.

[0021] Furthermore, the smart contract-based access control module OSAC utilizes three characteristics of smart contracts:

[0022] Timestamp: The smart contract timestamp, SCtimestamp, is used to record and verify the time when operations within the contract occurred and is also used by OSAC to make access decisions and their execution. SCtimestamp can be determined by the timestamp of a verified transaction or the timestamp field of the blockchain, defined as SCtimestamp = Tx.timestamp and SCtimestamp = block.timestamp, respectively. Smart contract timestamps ensure time consistency across the network, as well as the fairness and immutability of contract execution.

[0023] Transaction Trigger: Transactions in blockchains are generally considered triggers with data. Only transactions that pass consensus verification are recorded and retained by the blockchain, ensuring atomicity, consistency, and durability. As the sole trigger for smart contract execution in OSAC, it ensures the legitimacy and credibility of contract execution data access control decisions.

[0024] Self-Execution: A smart contract is essentially an agreement written in code that automatically executes and enforces its terms under certain conditions, such as timestamped transactions. This execution relies on predefined rules and procedures, verified by multiple nodes in the network, without the need for any human intervention.

[0025] On the basis of building an effective decentralized access control model, the decentralized data access control method based on smart contracts for drones of the present invention is based on the underlying architecture of the blockchain network, and deploys an access control module based on smart contracts on the blockchain network. The module is embedded with the access control algorithm ScaBAC. The framework diagram of the ScaBAC algorithm is shown in the figure below. Figure 2 As shown, the working steps are as follows:

[0026] 1) Data permission expression. In the data permission expression phase, the data provider (i.e., the data supply drone) will first establish a hybrid data token model (HDTM) to establish fine-grained permissions for the data. Using the token as one of the data attribute elements, it will create and manage access control policies, including the publication, update, and revocation of attributes and policies, as well as responses to their query results.

[0027] 2) Data access execution: In the data access execution phase, when a data requesting drone sends a request to the blockchain network to perform a certain operation on a certain data, the ScaBAC algorithm first converts the request into a transaction and sends it to the Policy Enforcement contract (PE contract). The PE contract first analyzes the transaction to obtain the subject, object, and operation semantics in the original access request, and creates an attribute-based access request based on the attribute information obtained from the Attribute-Policy Management Contract (ACSC-Attribute-PolicyManager, ACSC-APM contract). The access request is encapsulated and a transaction is created, which is sent to the Policy Decision Contract (PD contract) at the corresponding address, waiting for the decision result of the contract.

[0028] 3) Data Rights Transfer and Acquisition. During the data rights transfer and acquisition phase, the token transfer smart contract (ACSC-Transfer, ACSC-Trans contract) parses the transaction and obtains a transaction verification checkproof containing access rights information. When a drone with data rights wishes to transfer data rights to another drone, it selects some unused data rights tokens as input based on the token transfer model (UFTO) and specifies the recipient's address and the permissions specified by the transfer checkproof. Once the inputs and outputs are determined, a data rights transfer transaction is created and broadcast to the network. This transaction includes the sender's digital signature, proving their ownership of the data rights tokens. Once the transfer transaction is confirmed and included in a block, the data rights tokens are marked as transferred, and a new data rights token is created and assigned to the recipient's address. Because each data rights transfer transaction is based on previously untransferred data rights tokens and each transaction creates new unused data rights tokens, this model makes the transfer and tracking of data rights easier and effectively prevents data misuse and unauthorized use.

[0029] Furthermore, the algorithm for updating attributes and policies in step 1) includes the use of a request-oriented transaction driver module. This module includes the requested transaction expression and transaction verification. As the trigger for function calls, the transaction needs to include the sending address, the receiving address, and the specific request content. This is converted into a formula:

[0030]

[0031] Where T represents the transaction, i.e., the transaction expression and transaction verification. Se represents the blockchain address of the sender, i.e., the algorithm input. sc Indicates the smart contract address to be called, F and [F p ] respectively represent the function name and input parameters in the contract, [Hash(T pl )] sig Indicates signing the hash value of the transaction payload. The transaction payload T composed of the above content pl After the initiator completes the digital signature, it is published to the blockchain network. The nodes on the blockchain perform transaction verification and transaction signature. If the returned Boolean value is true, the verification is passed, and the transaction triggers the corresponding smart contract to drive the next step of the algorithm. Otherwise, the algorithm terminates. The transaction verification formula is as follows:

[0032]

[0033] Where Bool result is the Boolean value returned by the formula, Verify is the verification function that outputs a Boolean value, and Pub key The function represents the use of the sender's corresponding public key to verify the validity of the signature, H(T pl ) indicates the operation of the verification node on the transaction load hash, that is, through Pub key ([Hash(T pl )] sig ) Verify the validity of the transaction payload signature and compare it with Hash(T pl ) is the comparison of transaction payload hash values to verify the consistency and integrity of the transaction.

[0034] Furthermore, step 1 defines data attributes, and the running algorithm for creating and managing access control policies includes the use of data permission attributes and policy expression modules. This module is designed for data-supplying drones. They customize data attributes and access policies through the module, and are key components of the algorithm to ensure controllable access to drone data. This part is mainly composed of the data token management contract (ACSC-Token Manager, ACSC-ToM), the attribute-policy management contract (ACSC-Attribute-Policy Manager, ACSC-APM) and the policy blockchain ledger. Among them, the ACSC-ToM contract is responsible for generating and managing token entities that represent fine-grained permissions of data under the drive of request-oriented transactions, as data attributes in data access decisions, and for proof of permissions in the access stage. The ACSC-APM contract is responsible for maintaining the attribute information of data resources, formulating and managing access control rules composed of attribute expressions. In order to solve the problems of high memory consumption caused by storing policies in smart contracts and low search efficiency caused by storing them in blocks, such as Figure 3 As shown, the present invention establishes a policy blockchain account book and uses a "key-value" pair data structure to store policy information, that is, the formula used when storing access control policies in the account book is:

[0035]

[0036] Policy index To generate a storage index, or "key," to ensure a unique correspondence between data-supplying drones and data permissions and to distinguish between different data-sharing tasks, OwnerId, TaskId, and Hash(DataId) represent the ID of the data-supplying drone, the ID of the data-sharing task, and the hash value of the task, respectively. Hash(OwnerId+TaskId+Hash(DataId)) represents a hash operation on the aforementioned drone identity information, representing the "value." To ensure the uniqueness and security of the mapping index, the index is further converted using the SHA-256 cryptographic hash function.

[0037] The policy storage format design in the ledger is implemented through the formula:

[0038] {key: <Policy index >,value: <r1;r2;…;r n >}

[0039] Among them, key is "key", value is "value", r1; r2; ...; r n Represents several different groups of access policies.

[0040] Furthermore, the hybrid data token model (HDTM) described in step 1 is represented by the data ownership identifier Data os and the fine-grained permission set Pres, and there is a dependency relationship between the two. os It represents the unique identifier of the data on the blockchain. It encodes the feature set of the data into a non-homogeneous data token and stores it in the account of the data owner on the blockchain. os attributes, and derives a fine-grained permission set consisting of several homogeneous and non-homogeneous tokens representing different rights and interests.

[0041] HDTM(Data)=Pers<Pft;Pnft> |Data os

[0042] Pft stands for homogeneous token, Pnft stands for non-homogeneous token, Pers<Pft;Pnft> It represents a fine-grained permission set consisting of several homogeneous and non-homogeneous tokens representing different rights and interests. Therefore, HDTM (Data) is the data ownership identifier Data os A hybrid data token model consisting of two parts: the Pers and the fine-grained permission set.

[0043]

[0044] In the above model, Data os Defined as a triple data, namely Data os =(ID os ,Meta,BCadd.ID os Used to identify the pass data os The on-chain digital identifier serves as an important support for ensuring the uniqueness of data ownership. os =H(P DP ,Enc(Url||P DP ),Sig(H(Data)||PK DP ),t), is usually generated automatically by the data provided by the drone through data assembly into a predefined structure and then sent to the smart contract. DP Indicates the public key of the data provider, Url indicates the storage address of the data in IFDS, Enc(Url||P DP ) indicates that the data is provided to the drone using the public key P DP The data storage address is asymmetrically encrypted, and only its corresponding private key Pk DP To decrypt. Sig(H(Data)||Pk DP ) indicates that the data is provided to the drone using its private key Pk DPSign the hash H(Data) of the original data, and its corresponding public key P DP Its signature can be verified to verify the integrity of the data and the authenticity of the data provider's ownership. t is the timestamp. Meta represents the token Data os The metadata information, including name, function description, ownership information, transaction records, etc., is very important for determining the os The uniqueness, ownership, value and transaction transparency of BCadd all play a vital role. os The smart contract address is used to verify its authenticity. Pers partially inherits Data os Attribute, if Data os is an empty set, then Pres is also an empty set. It represents the disjoint union of homogeneous token elements and retains the element source information to ensure that all elements are uniquely identified. It means that the elements of non-homogeneous tokens do not intersect and retain the source information of the elements, ensuring that all elements are uniquely identified.

[0045] pft i and pnft j , respectively representing homogeneous and non-homogeneous token elements within a fine-grained permission set. The former is generally used to represent operational permissions that do not involve changes to data content, such as read and use rights, and is replicable and composable. In contrast, the latter usually represents permissions related to the data itself, such as write and update rights, and is composable and an indivisible minimum permission unit.

[0046] pft i =(H(Data os ),pname,dt,num,metadata)

[0047] PNFT j =(nftID,pname,dt,num,metadata,history=(addr from ,addr to ))

[0048]

[0049] Among them, pname, dt, num, and metadata respectively represent the permission name (scope), valid period, number of times it can be used, and metadata description related to the permission token. The metadata description related to the permission token includes data owner, data information, token generation time, user, etc. The difference is that pft i The token is homogeneous, so its on-chain ID can be used with Dataos The hash character H (Data os ) to identify. Rather than homogeneous pnft j The on-chain identifier nftID is a unique identifier generated by the relevant smart contract. j The indivisible but transferable nature of the token means that its data structure also includes the current transfer information of the token, which is represented by the source address addr. from and the transfer address addr to The metadata contains the historical transaction records of the data flow, ensuring the transparency and traceability of the data flow after it is accessed. History indicates the current flow information.

[0050] Furthermore, step 2 can be represented in the algorithm as a policy-based data access decision module. When an access request occurs, this module compares the attribute values of the accessing and accessed drones with the policies defined in the policy blockchain ledger to determine whether the access subject has the right to access the data object and perform the requested operation. This process can be formally represented as:

[0051] Decision = F(Ob,Su,Ac,En)

[0052] Among them, Decision represents the result of the access control decision, that is, permission or rejection. Ob, Su, Ac, and En respectively represent the attribute values of the basic elements: Ob (Object): object such as data resources stored by drones; Su (Subject): subject such as data requesting drones; Ac (Action): type of operation requested to be performed (such as read, write, modify, etc.); En (Environment): environmental attributes of the access (such as time, task status, context conditions, etc.). F represents the judgment decision criterion. The present invention defines F as an automatically executed smart contract and its calling process, and encapsulates the four core parts of policy enforcement (PE), role attribute verification (RC), task information management (TM), and policy decision (PD) according to the decision-making process. Through the calls between the four contracts, it is judged whether the access subject has the right to perform the operation corresponding to the request content on the data, so as to realize decentralized access control execution. The PE contract is responsible for receiving transaction requests, while the RC contract and TM contract are used to query and verify the role attribute information of the access requester and the attribute information of the current data sharing task, respectively, serving as auxiliary decision-making information for the PD contract. Blockchain-based decentralized data sharing involves multiple parties, so role attributes are introduced to distinguish different tasks, while data sharing task attributes are used to characterize the current task sequence, preventing data from being shared once and then used multiple times. The PD contract is responsible for executing authorization decisions, determining whether to grant or deny access requests.

[0053] Furthermore, step 3 can be represented in the algorithm as a permission transfer module. This module implements data flow determination and traceability by designing a token transfer model called UFTO (Unspent Fungible Token Outputs). The UFTO token transfer model mimics Bitcoin's UTXO model. When data tokens are transferred between different data-requesting drones, the UFTO model verifies the legitimacy of token transfers, ensuring sufficient permissions for data transfer operations and enhancing the traceability and controllability of data permission transfers.

[0054] The UFTO token transfer model defines the data structure for transferring data permissions represented by tokens between different entities. While decoupling permissions and access subjects in the access control model, it helps users effectively control the scope of data flow.

[0055] tx Trans ={Num Output ,{Pers Out},Num Input,{Pers In}}

[0056]

[0057] From the above data token modeling, we can see that data tokens can be combined and transferred (including the permissions represented by the homogeneous tokens of data can be copied). Each combination and transfer of data tokens will generate a new data structure record, which can be transferred using transaction tx. Trans (Transfer transactions). Output and Pers Out They represent the number of data tokens output from the currently accessed drone data holder account and the token set formed, Num Input and Pers In They represent the number and set of tokens transferred to the drone account. At the same time, the token satisfies the above constraints during the transfer process. The data token transfer process has the phenomenon of attribute inheritance, that is, the inherent attributes of the data token such as the permission range (pname), validity time (dt) and number of uses (num). In addition to inheriting some inherent attributes, the relevant meta-information description in the data token, including the data owner, token generation time, user, etc., needs to be changed and recorded according to the attributes of the inheritor. When Num Output =Num Input When Num Output >Num Input If the token is not in the same state as the previous one, it indicates an illegal permission transfer process, and the corresponding data operation request will be rejected. Each UFTO token transfer process is based on a permission chain between the owner and the recipient based on encryption technology. In the blockchain, all UFTOs form a collection to ensure that the flow of data permissions is auditable and verifiable. Each transfer will leave a data structure record to form a complete data flow chain.

[0058] Among them, the UFTO token transfer model diagram is as follows Figure 4 shown.

[0059] The Token Transfer Smart Contract (ACSC-Trans) serves as a predefined execution vehicle, managing the transfer and verification rules of data tokens. Data tokens can be combined and transferred (including the ability to replicate the permissions represented by homogeneous data tokens).

[0060] Furthermore, the smart contracts presented herein will be further described in the embodiments.

[0061] Compared with the prior art, the present invention has the following beneficial effects:

[0062] 1) Fine-grained permission control: supports independent management of six types of drone data operation permissions (read, write, share, update, delete, transfer);

[0063] 2) Decentralized and efficient decision-making: Experiments show that the algorithm throughput rate reaches 170 TPS and the latency is less than 5 seconds;

[0064] 3) Anti-attack capability: Based on PoW consensus, the probability of malicious nodes tampering is close to zero. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 : Schematic diagram of the decentralized data access control model (showing the model framework and related modules)

[0066] Figure 2 : Schematic diagram of the framework of the smart contract-based decentralized access control algorithm (ScaBAC algorithm) for drones (showing transaction drive, permission attributes and policy expression, data access decision, and permission transfer modules);

[0067] Figure 3 : Schematic diagram of the attribute and policy storage data structure (showing the data structure storage logic of "key-value" pairs);

[0068] Figure 4 : Schematic diagram of the UFTO token transfer model (showing the transfer and circulation path of the input and output token permission sets);

[0069] Figure 5 :ScaBAC algorithm smart contract execution dependency (showing the interaction logic of ACSC-ToM, ACSC-APM, ACSC-PD and other contracts)

[0070] Specific implementation process

[0071] The following will refer to the accompanying drawings and combine different smart contracts to specifically explain the algorithm execution process in the above three steps of the present invention.

[0072] 1) Data permission expression. In the data permission expression phase, the data supply drone will first establish fine-grained permissions for the data based on the HDTM token model, and use the token as one of the data attribute elements to create and manage access control policies, including the release, update, and revocation of attributes and policies, as well as responses to their query results. This process involves dependencies between the Data Token Management Smart Contract (ACSC-ToM) and the Attribute-Policy Management Smart Contract (ACSC-APM), as shown below: Figure 5 shown.

[0073] ACSC-ToM contract (creating data token part) transaction Tx created by the data supply drone Create-Toekn (Create a token transaction) triggers execution, and by parsing the transaction, the identity ID and public key are<UserId,Pub-Key> The data supply drone calls the deployment address as API ACSC-ToM The contract executes the CreateToken operation to create a data token. Among them, Data and Permits are the data information parameter set and permission parameter set customized by the data supply drone respectively. Sign(DataInfo) represents the signature of the data information, which is equal to Sign(H(Data)||Pk DP ) operation, indicating that the data supply drone uses its private key to sign the hash of the original data. t is the timestamp, Type token This is a token type. The created data token will be automatically stored in the account of the data supply drone and used for authorization and transfer in subsequent access control.

[0074]

[0075] The core steps of the ACSC-ToM contract are as follows:

[0076] Perform initialization operations and use the SHA-256 cryptographic hash function to generate a unique user ID UserInfo for UserID (i.e. user ID) index .

[0077] When fcn=="create token", that is, the request operation is to create a data token, if Type token ==nft means the token type is a non-homogeneous token. Based on time.now, UserID, KeyPub (current timestamp, user ID and public key), a hash operation Hash(time.now, UserID, KeyPub) is performed to generate a unique identity identifier nftID. Extract permission parameters: including name (pname), data type (dt), quantity (num) and assign them to the data type corresponding to the token. Construct metadata metadata to record user ID, data identifier, hash value and empty history. Combine the generated nftID, permission parameters, metadata and empty history to obtain the NFT token and add it to the user account. The token is created successfully. If Type token ==ft means the token type is a homogeneous token, based on the hash value of the data identifier Hash (Data os ) Generate a unique ftID and execute the same process as above to successfully create the token.

[0078] The data supply drone calls the ToM contract to create a data token and then generates a transaction TxAttri-Policy , indicating a transaction regarding drone attributes or strategies. This transaction triggers the ACSC-APM contract to run, and the identity information is<UserId,Pub-Key> The data supplied to the drone creates the corresponding data attributes and access policies.

[0079] The core logic of the ACSC-APM contract is:

[0080] definition:

[0081] 1) The identity attribute SA of the data requesting drone is UserId, TaskId, TaskRole, which represents the unique identity of the data accessor, the corresponding data sharing task number, and the task role currently undertaken by the data accessor.

[0082] 2) Data attributes DA = DataId, OwnerID, ProTime, DueDate, TaskId, HDTM (Data), including the data number identification, data owner, data generation time, data access validity period, corresponding data sharing task number and data permission token information.

[0083] 3) Data sharing attribute TAA = TaskId; DRId; time start ;time end ,including data sharing task identifier, task publisher, start time and end time.

[0084] 4) Action attributes in Indicates an empty set, i.e., the access request is denied. i ,…,pnft j} indicates that the request is allowed and a data permission token is generated at the same time, which is used as a proof of access.

[0085] When executing the operation fcn == "AddPolicy", the policy's existence is checked. If it does not exist, it is stored in the policy public ledger and a successful policy addition is returned. When executing the operation fcn == "QueryPolicy", the policy information obtained from the query is directly returned. When executing fcn == "UpdatePolicy" or fcn == "DelPolicy", the user's identity UserId and public key Pub-Key are extracted from the transaction. If UserId == DA.UserID, indicating that the user's identity matches the data owner's identity, the PutState function is called to overwrite the original policy, or the Delete function is called to remove the policy record.

[0086] Execute function FcnPM , mainly including the storage, modification, query and deletion of attributes or policies:

[0087] Fcn PM ={AddPolicy(),UadatePolicy(),QueryPolicy(),DelPolicy()}

[0088] The AddPolicy() function is used to create an access policy, generate index policy information, and store it as a value in the policy public ledger. When the data supply drone needs to change the access policy information of the data, the smart contract UadatePolicy() function is called to update and maintain the policy information in the policy public ledger. The QueryPolicy() function is used to query the access policy and is also an important source of basis for ACSC-PD contract decision-making. The DelPolicy() function is used to delete the corresponding permission policy information. It is worth noting that before being called, the latter three functions will first check the identity information of the caller based on the transaction to ensure that only the supplier corresponding to the data has the authority to perform the corresponding operation. The corresponding transaction trigger formula is as follows:

[0089]

[0090] in,<UserId,Pub-Key> Indicates the identity ID and public key of the requesting machine, API ACSC-APM The deployment address of the attribute policy management contract.<SA,DA,TAA,AA> is the data attribute set of the above drone, where SA: allows access to drone attributes; DA: data supply drone attributes; TAA: collaborative task attributes; AA: access action attributes. PM It represents the execution function based on ACSC-APM contract, Sig pri-Key Represents a signature operation based on a private key.

[0091] 2) Data access execution. The data access execution phase mainly involves the judgment, response and execution of access requests. This process involves the dependencies and transaction triggers between the access execution smart contract (ACSC-PE), the policy decision smart contract (ACSC-PD), the task information management smart contract (ACSC-TM) and the role attribute verification smart contract (ACSC-RC). Figure 5 When a data requesting drone (or other data access machine) sends a request to the network to perform an operation on a certain data, the ScaBAC algorithm first converts it into a transaction Tx regarding the access request. Req And sent to ACSC-PE.<UserId,Pub-Key> Indicates the identity ID and public key of the requesting machine, APIACSC-CE Indicates the address of the PE contract on the chain, Fcn PE Indicates the corresponding function name in the PE contract,<UserId,DataId,Action> It means that the requesting machine UserId requested an action for the data identified as DataId. TID is the unique identifier of the transaction. pri-Key Represents a signature operation based on a private key.

[0092]

[0093] The core logic of the PE contract is: ACSC-PE first analyzes Tx Req Get the subject UserId, object DataId and operation semantics Action in the original access request, create an attribute-based access request Attri-Rule based on the attribute information obtained from the ACSC-APM contract, encapsulate the Attri-Rule and create a transaction Tx based on the PD contract PD , sent to the contract address as API ACSC-PD ACSC-PD contract, awaiting decision results.

[0094] The core logic of the PD contract is: by parsing the transaction Tx PD The attribute-based access request Attri-Rule is obtained, and based on the requested data attributes, the formula is used to obtain the index of the corresponding access policy on the chain. Next, the index information, the subject and object information in the request, and other information are sent to the ACSC-APM, ACSC-TM, and ACSC-RC contracts, respectively, to obtain policy information, data sharing task verification information, and access subject role verification information. This information, along with the Attri-Rule, will serve as input parameters for ACSC-PD to execute the access decision. The specific formula is as follows:

[0095]

[0096] Among them, API ACSC-PD Indicates the address of the PD contract on the chain, Fcn PD Indicates the corresponding function name in the PD contract, and TID is the unique identifier of the transaction. Attri-Rule is an access request based on the attribute, that is, the access rule. pri-Key Represents a signature operation based on a private key.

[0097] The decision-making process involves traversal and comparison. If an Attri-Rule satisfies the constraints and predicates in a specific access control policy, the request is deemed to satisfy the policy, access is allowed, and a permission proof, CheckProof, represented by a token, is created. If access is denied, the following situations may occur: First, the policy for the accessed data does not exist, denying access to the data. Second, task attribute verification fails, indicating that the data sharing task has ended and the data is no longer within the permitted access period. Third, role verification of the access subject fails, indicating that the subject is not a participant in the corresponding data sharing task. These measures can effectively reduce the risk of data misuse.

[0098] 3) Data permission transfer and acquisition. The transfer and acquisition of data permissions are based on the ACSC-Trans smart contract, and its core logic is:

[0099] Pass transaction Tx by parsing data Trans After obtaining a CheckProof containing access rights information, when a user with data rights wishes to transfer data rights to another user, they must select some unused data rights tokens as input according to the UFTO model, specify the recipient's address, and transfer the permissions specified by the CheckProof. Once the inputs and outputs are determined, a data rights transfer transaction is created and broadcast to the network. This transaction includes the sender's digital signature, proving their ownership of the data rights tokens. Once the transfer transaction is confirmed and included in a block, the data rights tokens are marked as transferred, and a new data rights token is created and assigned to the recipient's address. Because each data rights transfer transaction is based on a previously untransferred data rights token, and each transaction creates a new, unused data rights token, this model makes the transfer and tracking of data rights easier and effectively prevents data abuse and unauthorized use.

Claims

1. A decentralized data access control method for cross-domain collaboration of drones, characterized by The underlying architecture of the method is a blockchain network, and an access control module based on a smart contract is deployed on the blockchain network. The module is embedded with the access control algorithm ScaBAC. The working steps of the method are as follows: 1) Data Permission Expression: During the data permission expression phase, the data provider, i.e., the data supply drone, will first establish a hybrid token model (HDTM) and use it to establish fine-grained permissions for the data. Using the token as one of the data attribute elements, it will create and manage access control policies, including the publication, update, and revocation of attributes and policies, as well as responses to their query results. 2) Data access execution: During the data access execution phase, when a data requesting drone sends a request to the blockchain network to perform an operation on a certain data, the ScaBAC algorithm first converts the request into a transaction and sends it to the policy execution contract (PE). The PE contract first analyzes the transaction to obtain the subject, object, and operation semantics in the original access request, and then creates an attribute-based access request based on the attribute information obtained from the attribute-policy management contract (ACSC-APM). The access request is then encapsulated and a transaction is created. The transaction is then sent to the policy decision contract (PD) at the corresponding address, awaiting the decision result of the contract. 3) Data rights transfer and acquisition: In the data rights transfer and acquisition phase, a token transfer smart contract ACSC-Trans is established. The contract parses the transaction and obtains the transaction verification CheckProof containing access rights information. When a drone with data rights wants to transfer data rights to other drones, it needs to select some unused data rights tokens as input based on the token transfer model UFTO, specify the recipient's address and transfer the rights specified by CheckProof; once the input and output are determined, the data rights transfer transaction will be created and broadcast to the network; This transaction includes the sending drone’s digital signature, proving their ownership of the data rights tokens; once the transfer transaction is confirmed and included in a block, the data rights tokens are marked as transferred, and new data rights tokens are created and assigned to the recipient’s address.

2. The method according to claim 1, wherein Step 1) The algorithm for updating attributes and policies includes the use of a request-oriented transaction driver module. This module includes the requested transaction expression and transaction verification. The transaction, as the trigger for the function call, needs to include the sending address, the receiving address, and the specific request content. Its form is converted into a formula: Where T represents the transaction, i.e., the transaction expression and transaction verification; Se represents the blockchain address of the sender, i.e., the algorithm input; Re sc Indicates the smart contract address to be called, F and [F p ] respectively represent the function name and input parameters in the contract, [Hash(T pl )] sig Indicates signing the hash value of the transaction payload; the transaction payload T composed of the above content pl After the initiator completes the digital signature, it is published to the blockchain network. The nodes on the blockchain perform transaction verification and transaction signature. If the returned Boolean value is true, the verification is passed, and the transaction triggers the corresponding smart contract to drive the next step of the algorithm. Otherwise, the algorithm terminates. The transaction verification formula is as follows: Where Bool result is the Boolean value returned by the formula, Verify is the verification function that outputs a Boolean value, and Pub key The function represents the use of the sender's corresponding public key to verify the validity of the signature, H(T pl ) indicates the operation of the verification node on the transaction load hash, that is, through Pub key ([Hash(T pl )] sig ) Verify the validity of the transaction payload signature and compare it with Hash(T pl ) is the comparison of transaction payload hash values to verify the consistency and integrity of the transaction.

3. The method according to claim 1, wherein Step 1) Define data attributes and create and manage the access control policy operation algorithm, including the use of the data permission attribute and policy expression module. This module is designed for data supply drones. They customize data attributes and access policies through the module. It is a key component of the algorithm to ensure controllable drone data access. This part mainly consists of the data token management contract ACSC-ToM contract, the attribute-policy management contract ACSC-APM, and the policy blockchain ledger. Among them, the ACSC-ToM contract is responsible for generating and managing token entities representing fine-grained data permissions under the drive of request-oriented transactions. It serves as a data attribute in data access decisions and is used for permission proof in the access phase. The ACSC-APM contract is responsible for maintaining the attribute information of data resources and formulating and managing access control rules. The rules are composed of attribute expressions. In order to solve the problems of high memory consumption caused by storing policies in smart contracts and low search efficiency caused by storing them in blocks, a policy blockchain ledger is established and a "key-value" pair data structure is used to store policy information. That is, the formula used when storing access control policies in the ledger is: Policy index To generate a storage index, or "key," to ensure a unique correspondence between the data-supplying drone and the data permissions, and to distinguish between different data-sharing tasks, OwnerId, TaskId, and Hash(DataId) represent the ID of the data-supplying drone, the ID of the data-sharing task, and the hash value of the task, respectively. Hash(OwnerId+TaskId+Hash(DataId)) represents a hash operation on the aforementioned drone identity information set, representing the "value." To ensure the uniqueness and security of the mapping index, the index is further converted using the SHA-256 cryptographic hash function. The policy storage format design in the ledger is implemented through the following formula: {key:<Polic index >,value:<r1;r2;…;r n >} Among them, key is "key", value is "value", r1; r2; ...; r n Represents several different groups of access policies.

4. The method according to claim 1, wherein Step 2) The policy-based data access decision module performs data access execution. When an access request occurs, the module compares the attribute values of the accessing drone and the accessed drone with the policy defined in the policy blockchain account book to determine whether the access subject has the right to access the data object and perform the requested operation. This process can be formally expressed as: Decision = F(Ob,Su,Ac,En) Among them, Decision represents the result of the access control decision, that is, permission or rejection; Ob, Su, Ac, and En respectively represent the attribute values of the basic elements: Ob: the object, such as the data resource stored by the drone; Su: the subject, such as the data requesting drone; Ac: the type of operation requested, including read, write, and modify; En: the environmental attributes of the access, including time and task status. F represents the judgment decision criterion, which is defined as an automatically executed smart contract and its calling process. According to the decision process, it encapsulates four core parts: policy enforcement (PE), role confirmation (RC), task management (TM), and policy decision (PD). Through the calls between these four contracts, it is determined whether the access subject has the right to perform the operation corresponding to the requested content on the data, thereby realizing decentralized access control execution. Among them, the PE contract is responsible for receiving request transactions, and the RC contract and TM contract are used to query and verify the role attribute information of the access requester and the attribute information of the current data sharing task, respectively, which serve as auxiliary decision-making information for the PD contract. The PD contract is responsible for executing the authorization decision to determine whether to allow or deny the access subject's request.

5. The algorithm according to claim 1, wherein Step 3) Data authority is transferred and obtained based on the authority transfer module. The authority transfer module realizes data flow determination and traceability by designing the token transfer model UFTO. When the data token is transferred between different data request drones, the UFTO model will verify the legitimacy of the token transfer out and in, ensure that there is sufficient authority for data flow operations, and enhance the traceability and controllability of data authority flow. The ACSC-Trans smart contract is used as a predefined execution carrier to manage the flow and verification rules of data tokens; data tokens can be combined and transferred, including the permissions represented by the homogeneous tokens of data can be copied; each combination and transfer of data tokens will generate a new data structure record, and this process can be used to transfer transaction tx Trans express.

Images