CN120433962A

CN120433962A - A decentralized data access control method for cross-domain collaboration of drones

Info

Publication number: CN120433962A
Application number: CN202510491342.6A
Authority: CN
Inventors: 程子文; 文言; 陈勇; 屠双龙; 闵博瀚; 纪祖臻; 裴植; 杨炳珍; 季丽花; 林元浩; 林有彬
Original assignee: Zhejiang University of Technology ZJUT
Current assignee: Zhejiang University of Technology ZJUT
Priority date: 2025-04-18
Filing date: 2025-04-18
Publication date: 2025-08-05

Abstract

This paper discloses a decentralized data access control method for cross-domain collaboration of unmanned aerial vehicles (UAVs). This method is based on a blockchain network and deploys a smart contract-based access control module on the blockchain network. This module embeds the access control algorithm ScaBAC (Smart-contract-enabled attribute-based Access Control), a smart contract-driven attribute-based decentralized access control algorithm. Its working steps include data permission expression, data access execution, and data permission transfer and acquisition. This method effectively quantifies the permission attributes of UAV data in a decentralized environment and supports flexible authorization in dynamic tasks. It achieves efficient coordination between on-chain automatic decision-making and off-chain data verification through smart contracts, and ensures the controllability and traceability of the UAV data flow process. This method can effectively support real-time permission updates in multi-UAV collaborative tasks and achieve fine-grained permission expression.

Description

Unmanned aerial vehicle-oriented cross-domain collaboration decentralised data access control method

Technical Field

The invention belongs to the technical field of unmanned aerial vehicle data security and blockchain, and particularly relates to an unmanned aerial vehicle cross-domain cooperation-oriented decentralizing data access control method which is used for realizing fine granularity management, automatic decision and trusted flow of data authority in a dynamic task by an unmanned aerial vehicle group.

Background

Along with the rapid development of unmanned aerial vehicle technology, unmanned aerial vehicles are increasingly widely applied in the fields of military, logistics, agriculture, disaster relief and the like. However, in a large-scale collaboration scenario, the balanced safety and real-time requirements of the unmanned aerial vehicle face challenges, and a brand new unmanned aerial vehicle data access control technology is required to support trusted collaborative operations in a complex airspace.

The existing unmanned aerial vehicle data access control technology has the following problems:

1) The centralized dependence is that the authority management is carried out by relying on a central server or a cloud platform, and single-point faults and malicious attacks are easy to occur;

2) Rights are rigidified, that is, the traditional ABAC strategy cannot adapt to the unmanned aerial vehicle dynamic networking environment, and rights are regulated with lag;

3) The lack of on-chain and off-chain synergy, the separation of data storage and access decisions, results in low verification efficiency and difficulty in tracing.

For example, patent CN202410367300.7 proposes a data sharing scheme of unmanned aerial vehicle based on attribute encryption, but relies on a centralized policy server, which cannot support real-time rights update in multi-unmanned aerial vehicle collaborative tasks. In addition, existing blockchain access control schemes (e.g., BCAC) are limited by on-chain storage performance, making fine-grained rights expression difficult to achieve.

Disclosure of Invention

Aiming at the technical problems in the prior art, the invention aims to provide a cross-domain cooperation decentralizing data access control method for an unmanned aerial vehicle. The technical problems to be solved by the invention include the following points:

1) How to quantify the authority attribute of the unmanned aerial vehicle data in a decentralization environment and support flexible authorization in dynamic tasks;

2) How to realize the efficient coordination of automatic on-chain decision and off-chain data verification through intelligent contracts;

3) How to ensure the controllability and traceability of the unmanned aerial vehicle data flow process.

The technical scheme adopted for solving the technical problems is as follows:

The invention discloses a cross-domain cooperation-oriented decentralization data access control method for an unmanned aerial vehicle, which is implemented on the premise of constructing an effective decentralization access control model, and is shown in fig. 1. The decentralized data access Control model takes a blockchain network as an underlying architecture and consists of a trusted authority (Trusted Authority, TA), a data supply unmanned plane, a data request unmanned plane, an access Control module (Ownership AND ACCESS Control, OSAC) deployed on the blockchain, and an interstellar file-based under-chain data storage module (Inter-PLANETARY DATA SYSTEM, IPDS).

Further, the model framework comprises the following relevant modules:

1) A blockchain network. The blockchain network adopts a alliance chain as an underlying architecture for supporting model operation. Typically consisting of entities such as businesses, government agencies of different geographical distribution, etc. connected by P2P communications. They act as fully trusted blockchain nodes responsible for performing transaction verification, broadcast, blockcreation and consensus tasks related to data access. By deploying a data access control module on the blockchain, access control and flow management of data are performed strictly according to an access control algorithm embedded by the module.

2) Trusted authority TA. The trusted mechanism is used as an initialization component and is responsible for providing system parameters for any participant attempting to join the model, generating identity information (comprising a pair of public Key _Pub and private Key _Pri generated by a PKI system) of a digital certificate, and only a user who obtains the certificate can join the blockchain network and call a related interface to perform data sharing task operation, and the issued transaction data needs to be signed by an entity account with the private Key for other users to verify the authenticity of the transaction in the block.

3) The data is provided to the unmanned plane, the data authority and the access policy. The data supply drones (Data Providers, DPs) are the drones that supply the data, responsible for customizing the rights and access control policies of the data owned and storing them to the OSAC module on the chain. In addition, the Data supply unmanned aerial vehicle sends the Data to the IFDS in a ciphertext form Encry (Data), and synchronizes the Data to the blockchain ledger at the storage address of the IFDS through the transaction of the blockchain. Data rights are defined as intrinsic rights attributes of data as credentials for data access and flow use. The access authority is defined, and fine granularity authorities such as the attribution authority of data and the use authority of data flow are also related. A simple access policy can be formalized as p= (S, O, a, λ), where S represents a set of access principals, O represents a set of data resources, a represents a set of data permissions, and λ: S x o→a represents an access control function that maps principals and resources into a set of data permissions.

4) The data request unmanned aerial vehicle and the data access authority prove. The data requesting drones (Data Requesters, DRs), herein also referred to as data accessors, are drones that want to acquire data resources. The data request unmanned aerial vehicle matches the attribute of the data request unmanned aerial vehicle through OSAC modules to obtain the authority certificate of the corresponding data, and accesses and uses the data through the authority certificate. The activities of the data request unmanned aerial vehicle are recorded in a distributed account book of the blockchain, so that the traceability of the access process is ensured.

5) The smart contract-based access control module OSAC. The OSAC module is the core component of the model to implement data access control. The component is essentially an intelligent contract system deployed on a blockchain that supports the decentralized access control function without a centralized third party providing service. The process is modeled as an intelligent contract strategy driven access control algorithm, and the intelligent contract strategy driven access control algorithm comprises two functions of data authority expression and authority management. The former is responsible for generating and maintaining rights passcards ProofO _wner, providing fine-grained rights settings for the data provider. The latter maintains a list of policy information pi= (P1; P2; PM), P1; P2; PM, representing different policies, for access control decisions and constructs automated decision techniques by integrating attribute-based access control algorithms.

6) And a data storage module IFDS. IFDS is a distributed data storage module based on the interplanetary file system that uses content addressing as a de-centralized storage component to uniquely identify each data file in the data sharing network and to reduce storage pressure for the blockchain system. In the model, the IFDS provides persistent and reliable storage of the shared Data ciphertext Encry (Data) sent by the Data feed drone and returns a unique address identification Url. The data feeder synchronizes Url into the blockchain through transactions as an entry for data access.

Further, the smart contract-based access control module OSAC utilizes three characteristics of smart contracts:

Timestamp: timestamp SCTIMESTAMP of the smart contract, both to record and verify when the operation in the contract took place, and to make access decision decisions and the basis for decision execution OSAC. SCTIMESTAMP may be defined by validated transaction time stamps or blockchain time stamp fields, SCTIMESTAMP =tx.timestamp and SCTIMESTAMP =block.timestamp, respectively. The smart contract time stamp ensures consistency of time in the network, as well as fairness and non-tamper-ability of contract execution.

Transaction triggering-transaction transactions in a blockchain are generally considered to be triggers with data, and only transaction transactions that pass the consensus verification can be recorded and retained by the blockchain, with atomicity, consistency and persistence. The unique trigger setting performed as the smart contract in OSAC ensures that the contract performs the legal and trusted data access control decisions.

Automated execution-smart contracts are essentially a kind of agreement written in code form that can automatically execute and enforce contract terms under specific conditions such as time-stamped transaction triggers. The execution process relies on predefined rules and procedures and is verified by multiple nodes in the network without any human intervention.

On the basis of constructing an effective decentralised access control model, the intelligent contract-based decentralised data access control method for the unmanned aerial vehicle is based on a bottom layer architecture which is a blockchain network, an intelligent contract-based access control module is deployed on the blockchain network, an access control algorithm ScaBAC is embedded in the module, a frame schematic diagram of the ScaBAC algorithm is shown in fig. 2, and the working steps are as follows:

1) And expressing the data authority. In the data authority expression stage, the data provider (i.e. the data supply unmanned aerial vehicle) will first establish a hybrid pass model (Hybrid Data Token Model, HDTM) to establish fine-grained authority of data, and take pass as one of data attribute elements to create and manage access control policies, including release, update, revocation of attributes and policies, response to their query results, and the like.

2) Data access execution, data access execution phase, when the data request unmanned plane sends a request for executing a certain operation on certain data to the blockchain network, scaBAC algorithm firstly converts the request into a transaction and sends the transaction to a Policy execution contract (Policy Enforcement, PE contract), the PE contract firstly analyzes the transaction to obtain a subject, an object and operation semantics in the original access request, creates an access request based on attributes according to Attribute information obtained from an Attribute-Policy management contract (ACSC-Attribute-Policy Manager, ACSC-APM contract), encapsulates the access request and creates a transaction, and sends the transaction to a Policy Decision contract (PD contract) of a corresponding address, and waits for a Decision result of the contract.

3) And data authority is transferred and obtained. In the data authority Transfer and acquisition stage, the pass Transfer intelligent contract (ACSC-Transfer, ACSC-Trans contract) obtains transaction verification CheckProof containing access authority information after analyzing the transaction, and when the unmanned aerial vehicle with the data authority wants to Transfer the data authority to other unmanned aerial vehicles, the unmanned aerial vehicle needs to select some unused data authority passes as input according to the pass Transfer model UFTO (Unspent Fungible Token Outputs), and the address of the receiving party and the authority designated by Transfer CheckProof are designated. Once the inputs and outputs are determined, a data rights transfer transaction is created and broadcast into the network. This transaction contains the sender's digital signature, proving their ownership of the data rights license. Once the transfer transaction is confirmed and contained in a block, these data rights passes are marked as delivered and a new data rights pass is created and assigned to the recipient's address. Because each data rights transfer transaction is based on a previously undelivered data rights pass and each transaction creates a new unused data rights pass. The model makes the transfer and tracking of the data authority easier, and can effectively prevent the problems of data abuse and unauthorized use.

Further, the running algorithm of the update of the attributes and policies of step 1) involves the use of a request-oriented transaction driver module. The module contains the requested transaction representation and transaction verification. The transaction is used as a trigger of function call, and needs to contain a sending address, a receiving address and specific request content, and the form of the transaction is converted into a formula:

Where T represents the trade transaction, i.e., trade transaction expression and trade transaction verification. Se represents the address on the blockchain of a sender, namely an algorithm inputter, re _sc represents the intelligent contract address to be called, F and [ F _p ] respectively represent the function name in the contract and the input parameter, [ Hash (T _pl)]_sig represents signing the Hash value of the transaction load; transaction load T _pl composed of the above is issued into the blockchain network after the digital signature is completed by the initiator, transaction verification and transaction signature are carried out by nodes on the blockchain, if the returned Boolean value is true, the verification is passed, the corresponding intelligent contract is triggered by the transaction, the next operation of the algorithm is driven, otherwise, the operation of the algorithm is terminated:

Wherein Bool _result is a Boolean value returned by a formula, verify is a verification function, output the Boolean value, pub _key is a function for verifying signature legitimacy by using a public key corresponding to a sender, H (T _pl) is an operation of a verification node on transaction load Hash, namely, verification of the validity of the transaction load signature by Pub _key([Hash(T_pl)]_sig, and consistency and integrity of the transaction are verified by comparing with Hash (T _pl), namely, the transaction load Hash value.

Further, step 1 defines data attributes, and the running algorithm for creating and managing access control policies contains the use of data rights attributes and policy expression modules. The module is designed for the data supply unmanned aerial vehicle, and the data attribute and the access strategy are customized by the module, so that the module is a key component for ensuring the controllable data access of the unmanned aerial vehicle by the algorithm. This section is mainly composed of a data license management contract (ACSC-Token Manager, ACSC-ToM), an Attribute-Policy management contract (ACSC-Attribute-Policy Manager, ACSC-APM), and a Policy blockchain ledger. The ACSC-ToM contract is responsible for generating and managing a certification entity representing the fine-grained authority of data under the drive of a transaction facing the request, is used as a data attribute in a data access decision, and is used for the authority certification of an access stage. The ACSC-APM contract is responsible for maintaining attribute information of data resources, and makes and manages access control rules composed of attribute expressions. In order to solve the problems of high memory consumption caused by storing policies in intelligent contracts, low searching efficiency caused by storing policies in blocks, and the like, as shown in fig. 3, the invention stores policy information by establishing a policy blockchain ledger and adopting a data structure of a key-value pair, namely, when an access control policy is stored in the ledger, the formula is used:

the Policy _index generates a storage index, i.e. a "key", to ensure a unique correspondence between the data supply unmanned aerial vehicle and the data authority and to distinguish different data sharing tasks, wherein OwnerId, taskId and Hash (DataId) respectively represent an ID of the data supply unmanned aerial vehicle, an ID of the data sharing task, and a Hash value of the task, and Hash (ownerid+ TaskId +hash (DataId)) represents a Hash operation on the unmanned aerial vehicle body information set, which represents a "value". To ensure the uniqueness and security of the mapping index, the index is further transformed using a SHA-256 cryptographic hash function.

The policy store format design in the ledger is realized by the formula:

{key:<Policy_index>,value:<r₁;r₂;…;r_n>}

Where key is a "key", value is a "value", and r ₁;r₂;…;r_n represents several different sets of access policies.

Further, the mixed Data certification model (HDTM) in step 1 is composed of two parts, namely a Data attribution right identifier Data _os and a fine granularity authority set Pres, and the two parts have a dependency relationship. Wherein Data _os represents a unique identification on the blockchain of Data that encodes the feature set of the Data into a non-homogenous Data token that is stored in the blockchain account of the Data owner. Pers inherits the Data _os attribute and derives a fine-grained authority set consisting of several homogenous and non-homogenous pass characterizing different rights.

HDTM(Data)=Pers<Pft;Pnft>|Data_os

Pft represents a homogeneous pass, pnft represents a non-homogeneous pass, pers < Pft; pnft > represents a plurality of fine-grained authority sets consisting of homogeneous and non-homogeneous passes representing different rights, so that HDTM (Data) is a mixed Data pass model consisting of a Data attribution identifier Data _os and a fine-grained authority set Pers.

In the above model, data _os is defined as a triplet of Data, namely, a chain number identifier of Data _os＝(ID_os,Meta,BCadd.ID_os for identifying the pass Data _os, which is an important support for guaranteeing the attribution uniqueness of the Data. ID _os＝H(P_DP,Enc(Url||P_DP),Sig(H(Data)||PK_DP), t), is typically automatically generated by the data feeding drone by data assembling into a predefined structure and then sending to the smart contract. Wherein P _DP represents the public key of the data provider, url represents the storage address of the data in the IFDS, enc (Url P _DP) represents that the data provider unmanned aerial vehicle uses the public key P _DP to asymmetrically encrypt the data storage address, and only its corresponding private key Pk _DP can be decrypted. Sig (H (Data) ||Pk _DP) indicates that the Data feeding drone signs the hash H (Data) of the original Data using its private key Pk _DP, and its corresponding public key P _DP can verify its signature, thereby verifying the integrity of the Data and the authenticity of the Data ownership by the provider. t is a time stamp. Meta indicates metadata information of the pass Data _os, including contents such as name, function description information, ownership information, transaction record, etc., plays a vital role in determining the uniqueness, ownership, value and transaction transparency of Data _os. BCadd denotes creating an intelligent contract address for Data _os for verifying its authenticity. Pers inherits the Data _os property, and if Data _os is empty, pres is also empty.Representing the non-union set of the homogeneity and passing elements and preserving the source information of the elements, ensuring the unique identification of all the elements.The non-homogeneous verification elements are not crossed and the source information of the elements is reserved, so that the unique identification of all the elements is ensured.

Pft _i and pnft _j, respectively represent homogeneous and heterogeneous pass elements in a fine-grained authority set, where the former elements are generally used to represent operation authorities, such as readability, usage rights, etc., that do not involve data content modification, and have replicability and combinability. In contrast, the latter generally represents rights related to the data itself, such as a writable right update right, and is a minimum rights unit that is indivisible and has combinability.

pft_i＝(H(Data_os),pname,dt,num,metadata)

pnft_j＝(nftID,pname,dt,num,metadata,history＝(addr_from,addr_to))

Wherein pname, dt, num, metadata respectively represents the rights name (range), effective time period, usable times and meta information description related to the rights pass, which includes data owner, data information, pass generation time, user, etc. In contrast, pft _i is homogenous, so its in-chain ID can be identified with the hash character H (Data _os) of Data _os. The non-homogenous pnft _j on-chain logos nftID are unique logos generated by the associated smart contracts. In addition, pnft _j has the property of inseparable but circulation, so that the data structure also comprises the current circulation information of the pass card, which consists of a source address addr _from and a transfer address addr _to, and the metadata comprises the history transaction record of circulation, thereby ensuring the transparency and traceability of circulation after the data is accessed. The history represents current flow information.

Further, step 2 may be represented in the algorithm as a policy-based data access decision module. When an access request occurs, the module compares the attribute values of the access unmanned aerial vehicle and the accessed unmanned aerial vehicle with a strategy defined in a strategy blockchain account book, and judges whether an access subject has the right to access the data object and execute the requested operation. This process can be formally expressed as:

Decision=F(Ob,Su,Ac,En)

Where Decision represents the result of an access control Decision, i.e. either allow or reject. Ob, su, ac, en respectively represent attribute values of the basic elements, ob (Object) which is a data resource stored by an Object such as an unmanned plane, su (Object) which is a host such as a data requesting unmanned plane, ac (Action) which is a type of operation (e.g. read, write, modify, etc.) which is requested to be performed, en (Environment) which is an access occurring environment attribute (e.g. time, task state, context condition, etc.). F represents a decision criterion. The invention defines F as an automatically executed intelligent contract and a calling process thereof, and encapsulates 4 core parts, namely Policy execution (Policy Enforcement, PE), role attribute verification (Role Confirmation, RC), task information management (TASK MANAGEMENT, TM) and Policy Decision (PD) respectively according to a Decision process. And judging whether the access subject has the right to execute the operation corresponding to the request content on the data through the call among 4 contracts so as to realize the decentralized access control execution. The PE contract is responsible for receiving a request transaction, and the RC contract and the TM contract are respectively used for inquiring and verifying character attribute information of an access requester and attribute information of a current data sharing task and serve as auxiliary decision information of the PD contract. The block chain-based decentralization data sharing involves multiple participants, so that character attributes are introduced to distinguish different tasks, and the data sharing task attributes are used for representing the current task sequence and preventing the data sharing from being used repeatedly at one time. The PD contract is then responsible for performing authorization decision making decisions to either allow or deny requests to access the principal.

Further, step 3 may be represented in the algorithm as a rights transfer module. The rights transfer module realizes data flow judgment and tracing by designing a universal certificate transfer model UFTO (Unspent Fungible Token Outputs, UFTO). The UFTO pass transfer model simulates a bitcoin UTXO model, and when data passes are transferred among different data request unmanned aerial vehicles, the UFTO model can verify the legality of pass transfer and inflow, ensure that enough rights are available for data transfer operation, and enhance the traceability and controllability of data rights transfer.

UFTO the pass transfer model defines the data structure of the data authority of the pass representative transferred among different subjects, and helps the user to effectively control the data circulation range while decoupling the authority and the access subjects in the access control model.

tx_Trans＝{Num_Output,{Pers_Out},Num_Input,{Pers_In}}

From the modeling of the data passing evidence, the data passing evidence can be combined and transferred (including the rights represented by the data homogenizing passing evidence can be copied). Each combination and transfer of data passes generates a new data structure record, which may be represented by transfer transaction tx _Trans (Transfer transactions). Num _Output and Pers _Out respectively represent the number of data passes and the formed pass set output from the account of the currently accessed unmanned aerial vehicle data holder, and Num _Input and Pers _In respectively represent the number and set of passes transferred to the account of the accessing unmanned aerial vehicle. Meanwhile, the phenomenon of attribute inheritance in the constraint data pass transfer process is met in the pass transfer process, namely, inherent attributes such as authority range (pname), effective time (dt) and use times (num) in the data pass are inherited. In addition to inheriting some inherent properties, the meta information descriptions associated in the data pass, including the data owner, the pass generation time, the user, etc. need to be modified and recorded according to the properties of the inheriter. When Num _Output＝Num_Input, it indicates that all the certificates are passed through verification, and the legal validity of the data stream path is described. When Num _Output>Num_Input, it indicates that there is an illegal rights transfer procedure, the corresponding data operation request will be denied. Each UFTO passes the certificate through a chain of rights between the owner and the recipient based on encryption technology. In the blockchain, all UFTO form a set to ensure that the stream of data rights is auditable and verifiable, each pass leaving the data structure record to form a complete stream link of data.

A schematic diagram of UFTO pass-through syndrome transfer model is shown in FIG. 4.

The certificate passing intelligent contract (ACSC-Trans) is used as a predefined execution carrier and is responsible for managing the circulation and verification rules of data certificate passing. The validation of data may be combined and transferred (including the rights represented by the homomorphism validation of data may be replicated).

Further, the smart contracts presented herein will be further described at the embodiments.

Compared with the prior art, the invention has the beneficial effects that:

1) Fine granularity authority control, namely supporting independent management of data operation authorities (reading, writing, sharing, updating, deleting and circulating) of 6 unmanned aerial vehicles;

2) The decentralization high-efficiency decision is that experiments show that the throughput rate of the algorithm reaches 170TPS, and the time delay is lower than 5 seconds;

3) And the anti-attack capability is that the tampering probability of the malicious node approaches zero based on the PoW consensus.

Drawings

FIG. 1 is a schematic diagram of a decentralised data access control model (showing model framework and related modules)

FIG. 2 illustrates a schematic diagram of an intelligent contract-based decentralized access control algorithm (ScaBAC algorithm) framework (showing transaction drivers, rights attributes and policy expressions, data access decisions, rights delivery modules) for an unmanned aerial vehicle;

FIG. 3 is a schematic diagram of an attribute and policy store data structure (data structure store logic showing "key-value" pairs);

FIG. 4 is a schematic diagram of a UFTO certification transfer model (showing transfer and circulation paths of an input-output certification authority set);

FIG. 5 ScaBAC Algorithm Smart contract execution dependency (interactive logic showing contracts such as ACSC-ToM, ACSC-APM, ACSC-PD)

Detailed description of the preferred embodiments

The algorithm execution process in the above three steps of the present invention will be specifically described with reference to the accompanying drawings in combination with different smart contracts.

1) And expressing the data authority. In the data authority expression stage, the data supply unmanned aerial vehicle firstly establishes fine-grained authority of data according to the certification model HDTM, and creates and manages access control strategies including issuing, updating, cancelling of the attributes and the strategies, response to query results of the attributes and the strategies and the like by taking certification as one of data attribute elements. The dependencies between the data certification management intelligent contracts (ACSC-ToM) and the attribute-policy management intelligent contracts (ACSC-APM) involved in this process are shown in fig. 5.

ACSC-ToM contract (Create data evidence portion) is triggered by the transaction Tx _Create-Toekn (Create evidence transaction) created by the data-feeding drone, by parsing the transaction, the data-feeding drone with an identity ID and public Key < UserId, pub-Key > calls a contract with an address of API _ACSC-ToM, and executes an create data evidence operation CreateToken. Wherein Data, permits are respectively a Data information parameter set and a right parameter set which are customized by the Data supply unmanned aerial vehicle, sign (DataInfo) represents signing of the Data information, is equal to Sign (H (Data) ||pk _DP) operation, and represents signing of hash of the original Data by the Data supply unmanned aerial vehicle by using a private key thereof. t is a timestamp, and Type _token is a pass Type. The created data pass will be automatically stored in the account of the data feed drone for authorization and transfer in subsequent access control.

The key steps of ACSC-ToM contract are as follows:

An initialization operation is performed to generate a unique user identification UserInfo _index for the UserID (i.e., user ID) using the SHA-256 cryptographic hash function.

When fcn= "create token", i.e. the request operation is to create a data pass, if the Type _token = = nft, i.e. the pass Type is a non-homogenous pass, a Hash operation Hash (time. Now, userID, keyPub) is performed based on the time. Now, userID, keyPub) to generate a unique identity nftID. And extracting authority parameters, namely, a name (pname), a data type (dt) and a number (num) and assigning the authority parameters to the data type corresponding to the pass. The metadata is constructed to record the user ID, data identification, hash value, and empty history. And combining the nftID, the authority parameters, the metadata and the empty history to obtain the NFT pass, adding the NFT pass to the user account, and successfully creating the pass. If Type _token = ft, namely the pass Type is a homogeneous pass, generating a unique ftID based on a Hash value Hash (Data _os) of the Data identifier, and executing the same flow as above to successfully create the final pass.

The data supply drone invokes the ToM contract to create a data pass and then generates a transaction Tx _Attri-Policy representing a transaction relating to the drone attribute or policy. The transaction triggers ACSC-APM contract operation, and creates attributes and access policies of corresponding data for the data with identity information < UserId, pub-Key > for the unmanned aerial vehicle.

The core logic of ACSC-APM contracts is:

Definition:

1) The identity attribute sa= UserId, taskId, taskRole of the data request unmanned aerial vehicle represents the unique identity of the data visitor, the corresponding data sharing task number and the task role currently assumed by the data visitor.

2) The Data attribute da= DataId, ownerID, proTime, dueDate, taskId, HDTM (Data) includes the number identification of the Data, the Data owner, the Data generation time, the valid time the Data can access, the corresponding Data sharing task number, and the rights clearance information of the Data.

3) The data sharing persona attribute taa= TaskId, DRId, time _start;time_end, including the task identity, task publisher, start time, and end time of the data sharing.

4) Action attributesWherein the method comprises the steps ofRepresenting an empty set, i.e. rejecting the access request. { pft _i,…,pnft_j } represents a permission request and at the same time a permission pass of the data is generated, serving as a credential Proof of access.

When performing operation fcn= = "AddPolic" y (adding policy), checking the existence of policy, if policy does not exist, storing policy into policy public ledger, and returning that policy addition is successful. When the operation fcn= = "QueryPoliyc" (query policy) is performed, the queried policy information is directly returned. When fcn= "UpdatePolciy" (update policy) or fcn= "DelPolicy" (Delete policy) is executed, the user identity UserId and public Key Pub-Key are extracted from the transaction, and if UserId = = da. Userid, indicating that the user identity matches the data owner identity, the PutState function is invoked to override the original policy or the Delete function is invoked to remove the policy record.

The execution function Fcn _PM mainly includes storage, modification, query and deletion of attributes or policies, etc.:

Fcn_PM={AddPolicy(),UadatePolicy(),QueryPolicy(),DelPolicy()}

Wherein AddPolicy () function is used to create access policies, and index policy information is generated and stored as a value in the policy public ledger. When the data supply unmanned aerial vehicle needs to change the access policy information of the data, the intelligent contract UadatePolicy () function is called to update and maintain the policy information in the policy public ledger. QueryPolicy () function is used to query access policies and is also an important source of basis for ACSC-PD contract decisions. DelPolicy () function is used to delete the corresponding rights policy information. It should be noted that, before the last three functions are called, the identity information of the caller is checked according to the transaction, so that only the supplier corresponding to the data is authorized to execute the corresponding operation. The corresponding transaction triggering formula is as follows:

Wherein < UserId, pub-Key > represents the identity ID and public Key identification of the requesting machine, API _ACSC-APM is the deployment address of the attribute policy management contract, and < SA, DA, TAA, AA > is the data attribute set of the unmanned aerial vehicle, wherein SA is the unmanned aerial vehicle attribute allowed to be accessed, DA is the data supply unmanned aerial vehicle attribute, TAA is the cooperation task attribute, and AA is the access action attribute. Fcn _PM is an executive function based on ACSC-APM contracts, sig _pri-Key is a signature operation based on private keys.

2) And executing data access. The data access execution stage mainly carries out decision, response and execution of an access request, and the process involves the access execution intelligent contract (ACSC-PE), the policy decision intelligent contract (ACSC-PD), the task information management intelligent contract (ACSC-TM) and the role attribute verification intelligent contract (ACSC-RC) to be dependent and transacted to trigger as shown in figure 5. When a data requesting drone (or other data access machine) sends a request to the network to perform an operation on certain data, the ScaBAC algorithm first converts it into a transaction Tx _Req on the access request and sends it to the ACSC-PE. Where < UserId, pub-Key > represents the identity ID and public Key identity of the requestor, API _ACSC-CE represents the address at which the PE is on the chain, fcn _PE represents the corresponding function name in the PE contract, < UserId, dataId, action > represents the requesting operation by the requestor UserId that the Action proposed on the data identified as DataId is an Action. TID is the unique identifier of the transaction. Sig _pri-Key represents a private key based signature operation.

The core logic of the PE contract is that ACSC-PE firstly analyzes Tx _Req to obtain a subject UserId, a guest DataId and operation semantic actions in an original access request, creates an access request Attri-Rule based on attribute information obtained from the ACSC-APM contract, encapsulates the Attri-Rule and creates a transaction Tx _PD based on the PD contract, sends the transaction Tx _PD to the ACSC-PD contract with a contract address of API _ACSC-PD, and waits for a decision result.

The core logic of the PD contract is that an access request Attri-Rule based on the attribute is obtained by analyzing the transaction Tx _PD, and the index of the corresponding access strategy of the data on the chain is obtained by a formula according to the attribute of the requested data. Then, information such as index information, subject and object in the request is sent to ACSC-APM, ACSC-TM and ACSC-RC contract, and policy information, authentication information of the data sharing task, role authentication information of the access subject and the like are obtained respectively. This information will be used with Attri-Rule as an input parameter for ACSC-PD to perform the access decision. The specific formula is as follows:

Where API _ACSC-PD represents the address at which the PD closes on the chain, fcn _PD represents the corresponding function name in the PD contract, and TID is the unique identifier of the transaction. Attri-Rule is an attribute-based access request, i.e., an access Rule. Sig _pri-Key represents a private key based signature operation.

The decision process determines that the request is a satisfying policy by traversing the comparison if Attri-Rule satisfies the constraints and predicates in a certain access control policy, allows access, and creates a proof of authority CheckProof represented by the pass. If the decision is to deny access, the following situations may be included, where the policy of the accessed data does not exist, and the data is denied access. And secondly, if the verification of the task attribute fails, the data sharing task is finished, and the data is not in the validity period of the allowed access. Thirdly, the role verification of the access subject fails, which means that the subject is not a participant corresponding to the data sharing task. These measures can effectively reduce the risk of data misuse.

3) And data authority is transferred and obtained. The transmission and acquisition of the data authority are based on ACSC-Trans intelligent contracts, and the core logic is as follows:

By parsing the data transfer transaction Tx _Trans to obtain CheckProof containing access rights information, when a user with data rights wants to transfer the data rights to other users, they need to select some unused data rights passes as input according to the UFTO model and specify the address of the recipient and transfer CheckProof the rights specified. Once the inputs and outputs are determined, a data rights transfer transaction is created and broadcast to the network that contains the sender's digital signature, proving their ownership of the data rights. Once the transfer transaction is confirmed and contained in a block, these data rights passes are marked as delivered and a new data rights pass is created and assigned to the recipient's address. Because each data rights transfer transaction is based on a previously undelivered data rights pass and each transaction creates a new unused data rights pass. The model makes the transfer and tracking of the data authority easier, and can effectively prevent the problems of data abuse and unauthorized use.

Claims

1. A decentralized data access control method for cross-domain collaboration of drones, characterized in that the method is based on a blockchain network as its underlying architecture and deploys a smart contract-based access control module on the blockchain network. The module is embedded with the access control algorithm ScaBAC. The method operates 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 stage, a token transfer smart contract ACSC-Trans is established. The contract obtains the transaction verification CheckProof containing access rights information after parsing the transaction. 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, and specify the recipient's address and the rights specified by the transfer CheckProof; once the input and output are determined, a data rights transfer transaction will be created and broadcast to the network; this transaction contains the digital signature of the sending drone, proving their ownership of these data rights tokens; once the transfer transaction is confirmed and included in a block, these data rights tokens will be marked as transferred, and new data rights tokens will be created and assigned to the recipient's address.

2. The method according to claim 1, characterized in that the algorithm for updating attributes and policies in step 1) includes the use of a request-oriented transaction driver module, which includes a transaction expression and transaction verification for the request. The transaction, as a trigger for a function call, needs to include a sending address, a receiving address, and specific request content, which is converted into a formula:

Where T represents the transaction, i.e., the transaction expression and verification; Se represents the blockchain address of the sender, i.e., the algorithm input; Re _sc represents the address of the smart contract to be called; F and [F _p ] represent the function name and input parameters in the contract, respectively; [Hash(T _pl )] _sig represents the signature of the hash value of the transaction payload; the transaction payload T _pl composed of the above content is digitally signed by the initiator and 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 a verification function that outputs a Boolean value, the Pub _key function uses the sender's public key to verify the legitimacy of the signature, and H(T _pl ) represents the verification node's operation on the transaction payload hash, that is, verifying the legitimacy of the transaction payload signature through the Pub _key ([Hash(T _pl )] _sig ) and comparing it with Hash(T _pl ), the transaction payload hash value, to verify the consistency and integrity of the transaction.

3. The method of claim 1, wherein step 1) defines data attributes, and the algorithm for creating and managing access control policies includes the use of a data permission attribute and policy expression module. This module is designed for data-supplying drones. The module customizes data attributes and access policies, and is a key component of the algorithm to ensure controllable drone data access. This module is primarily composed of a data token management contract (ACSC-ToM), an attribute-policy management contract (ACSC-APM), and a policy blockchain ledger. Driven by request-oriented transactions, the ACSC-ToM contract is responsible for generating and managing token entities representing fine-grained data permissions, serving as data attributes in data access decisions and used for permission certification during the access phase. The ACSC-APM contract is responsible for maintaining attribute information of data resources, formulating and managing access control rules, and 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:

The Policy _index is used to generate the storage index, or "key," to ensure the unique correspondence between the data-supplying drone and the data permissions, and to distinguish 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 the hash operation performed on the aforementioned drone identity information set, representing the "value." To ensure the uniqueness and security of the mapping index, the SHA-256 cryptographic hash function is further used to convert the index.

The policy storage format design in the ledger is implemented through the following formula:

{key:<Polic _index >,value:<r ₁ ;r ₂ ;…;r _n >}

Where key is the key, value is the value, r ₁ ; r ₂ ;…; r _n represent several groups of different access strategies.

4. The method of claim 1, characterized in that step 2) a policy-based data access decision module performs data access execution. When an access request occurs, the 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 expressed as follows:

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 of claim 1, characterized in that step 3) transfers and obtains data permissions based on a permissions transfer module. The permissions transfer module implements data flow determination and traceability by designing a token transfer model UFTO. When data tokens are transferred between different data-requesting drones, the UFTO model verifies the legitimacy of token transfers and inflows, ensuring sufficient permissions for data transfer operations and enhancing the traceability and controllability of data permission transfers. The ACSC-Trans smart contract serves as a predefined execution carrier, responsible for managing the flow and verification rules of data tokens. Data tokens can be combined and transferred, including the permissions represented by homogeneous data tokens can be copied. Each combination and transfer of data tokens generates a new data structure record, which can be represented by the transfer transaction tx _Trans .