A secure remote sensing image data sharing system and method based on blockchain and IPFS

Abstract

The application designs a safe remote sensing image data sharing system and method based on a blockchain and IPFS, belongs to the technical field of computer blockchains and the field of network security; uses a blockchain and IPFS as a bottom network and a storage system respectively, provides a trust basis among data institutions through the characteristics of decentralization, traceability and non-tampering of the blockchain, creates a credible sharing environment and effectively reduces the sharing cost of the architecture; and a safe remote sensing image data sharing protocol is also designed, an authorization verification strategy based on discrete logarithm knowledge signature and a dynamic data access permission management strategy based on a smart contract are introduced, the smart contract is used to realize user access control and data access verification functions, provides permission authentication capabilities for all parties involved, performs data access control with low overhead, and limits the ability of malicious users to do evil.

Description

Technical Field

[0001] This invention relates to the fields of computer blockchain technology and network security, and in particular to a secure remote sensing image data sharing system and method based on blockchain and IPFS. Background Technology

[0002] In recent years, with the rapid development of aerospace and Earth observation technologies, research institutes and ground centers have collected a large amount of remote sensing image data. Furthermore, with the development of satellite communication capabilities, satellite data acquisition capabilities have gradually increased, data size has grown, and data update frequency has risen. To maximize data utilization, the need for institutions possessing remote sensing image data to jointly build data sharing systems is increasing. However, the high degree of independence and trust among institutions means that traditional remote sensing image data sharing methods suffer from trust issues and low sharing efficiency, failing to meet current practical needs. At the same time, due to the high value of remote sensing image data, security requirements such as privacy protection must be guaranteed.

[0003] Blockchain technology, also known as distributed ledger technology, is a peer-to-peer (P2P) network with excellent characteristics such as decentralization, traceability, and immutability, representing a major breakthrough in cryptography and security. Blockchain technology can establish trust relationships among participants at low cost, improve sharing efficiency, and ensure the security of data transmission.

[0004] The Inter-Planetary File System (IPFS) has been receiving continuous attention as a distributed file system designed to achieve decentralized data sharing. Its data partitioning, redundancy, and disaster recovery schemes have effectively improved the availability and reliability of the system.

[0005] While current data sharing solutions based on blockchain and IPFS mostly employ on-chain central node or central node group authentication for authorization verification, which effectively and simply achieves authorization verification, the following problems still exist for satellite remote sensing data sharing needs.

[0006] First, institutions possessing remote sensing image data are characterized by strong independence and weak trust. Adopting a centralized data-sharing solution may lead to increased costs, single points of failure, and trust crises, hindering cooperation. Therefore, measures are needed to ensure effective collaboration and data sharing among institutions even in untrusted environments.

[0007] Secondly, in the actual operating environment of the system, due to the diversity of remote sensing image data, some high-value data requires access control and permission management. Current blockchain-based sharing systems have election center nodes or power center node groups, which cannot guarantee the participation of all members of the sharing system, nor can it guarantee the permission management of remote sensing images shared by various institutions. Choosing BCOS as a consortium blockchain helps to further reduce costs by simplifying system deployment and management; however, having administrator nodes responsible for user access will require the platform maintainer to be constantly online, and the voting results of each node will be exposed to other users on the chain. Therefore, optimization of data access permission control is necessary.

[0008] Finally, due to the high value of remote sensing images, plaintext data is not suitable for direct upload to IPFS for storage; instead, a solution needs to be designed to ensure data privacy and security. Furthermore, the large data volume of remote sensing images makes directly encrypting the data using commonly used attribute encryption techniques prohibitively expensive and inefficient. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention designs a secure remote sensing image data sharing system and method based on blockchain and IPFS.

[0010] A secure remote sensing image data sharing system based on blockchain and IPFS consists of five parts: data providers, data requesters, authentication center, a consortium blockchain network composed of users as basic units, and an IPFS proprietary storage system composed of storage services provided by participating users.

[0011] Data Provider User Pro Users who share remote sensing image data in the system will encrypt the remote sensing image data according to the remote sensing image data sharing protocol, and then share the remote sensing image data to the system for easy access by data requesters;

[0012] Data Requester User Req User is a user who requests remote sensing image data from the system. Req Through blockchain and users Pro Interactive acquisition of remote sensing image data;

[0013] A Certificate Authority (CA) is an entity that issues identity verification, blockchain, and IPFS certificates to users in the system. The CA also needs to generate and update keys used for threshold signatures.

[0014] The blockchain network BC is a consortium blockchain composed of nodes provided by each user participating in the system. It is the basic network for the operation of the system. All user operations are propagated and implemented in the system through the blockchain network. Through the consensus protocol in the blockchain network, all nodes participate in the inspection and storage of information or data in the network. The operation of smart contracts and the generation of events are also realized and stored through the blockchain, ensuring the credibility and openness of user operation results.

[0015] The remote sensing image data sharing protocol, considering the diverse characteristics of remote sensing image data itself, designs three strategies: access control, data verification, and request / appeal. Reputation is incorporated as an incentive throughout the protocol's operation. Simultaneously, a data privacy protection scheme is introduced at each stage of the protocol. Utilizing the differences between symmetric and asymmetric encryption algorithms in terms of encryption / decryption speed and whether the key is fixed, a hybrid approach combining symmetric and asymmetric encryption with the three strategies mentioned above ensures the security of data access, data transmission, and data storage within the data sharing protocol process.

[0016] The workflow of the remote sensing image data sharing protocol includes the following five stages: system preparation stage, negotiation and authentication stage, data registration stage, data request stage, and request appeal stage. In each stage, users additionally sign the messages using their ECC private keys to ensure the non-repudiation of the messages.

[0017] System preparation phase: This phase is the system initialization phase; after the system is built, it is necessary to set the parameters in the system, deploy the required smart contracts, and set up the initial users in the system.

[0018] Negotiation and authentication phase: This phase includes two scenarios: the process of external users undergoing access authentication and joining the consortium blockchain network and IPFS, and the authorization and verification process for new users joining the system or users in the system to change permissions.

[0019] Data registration phase: This phase is the process by which data providers register data on the blockchain and set data access permissions.

[0020] Data Request Phase: This phase is when the data requester requests data and the data provider provides the IPFSHash and AES one-time key. When the data requester requests data, the data sharing contract will call the access management contract to verify permissions before continuing the sharing process.

[0021] Request for Appeal Stage: This stage is for appealing when disputes arise after the sharing process has ended. If a data provider maliciously sends incorrect IPFSHash and AES keys or provides data that does not match the description information, causing a sharing dispute, an appeal is required. At the same time, it is also necessary to prevent malicious data requesters from falsely accusing data providers.

[0022] The IPFS distributed storage system consists of user-provided storage services, including user-provided IPFS node entities (IPFSNode), which are responsible for storing and downloading remote sensing image data. IPFS will split, back up, and store the data, distribute it to nodes on the blockchain, and return the corresponding IPFSHash to the user.

[0023] A secure remote sensing image data sharing method based on blockchain and IPFS, implemented based on the aforementioned secure remote sensing image data sharing system based on blockchain and IPFS, specifically includes the following:

[0024] Step 1: The first step is the system preparation and initialization phase, which requires defining parameters, deploying contracts, and initializing the users in the system; the users in the system act as data providers. Pro Also as a data requester User Req The system prepares for the user's blockchain network by providing services and generating a unique blockchain address, Addr. The specific process for this preparation phase is as follows:

[0025] Step 1.1: Define parameters: Initialize the public parameters required for the threshold signature; the parameters include two multiplicative cyclic groups G1 and G2 of order P, where g1 and g2 are the generators of G1 and G2 respectively, and e is a bilinear mapping: G1*G2→G T H1:{0,1} * →G1 is a secure one-way hash function; additionally, seven parameters need to be set: the base reputation value BaseRepu, and the reputation value PerRepu corresponding to each permission. i Successful data sharing increases reputation value (ShareRepu). Succ AppealRepu, the party at fault, will have their reputation score deducted. Error Voting correctly increases your reputation score (VoteRepu). Cor Malicious voting deducts reputation points (VoteRepu) Incor The user-disabled and enabled threshold, BanThreshold, is a parameter that users negotiate and define based on their level of trust in the system; where BaseRepu is the user's reputation base, and PerRepu... i It's related to user permissions; the higher the permissions, the higher the user's visibility, and the corresponding PerRepu. iThe larger the size, the better; secondly, in order to effectively limit user behavior in the system, AppealRepu... Error It must be greater than ShareRepu Succ VoteRepu Incor It must be greater than VoteRepu Cor BanThreshold is defined as the minimum reputation value of a user account, which is related to whether the user account is disabled. In addition, it is necessary to define the mapping relationship between the user's actual ability and system permissions with the CA. After the CA assesses the user's actual ability, it will give the user the permissions that should be granted in the system.

[0026] Step 1.2: Deploying Contracts: To achieve the system's data sharing function, after the blockchain network is built, the system developers need to deploy four contracts: the data sharing contract ShareSC, the reputation management contract RepuManSC, the permission management contract PerManSC, and the access management contract AccManSC. ShareSC provides functions for obtaining data description information, data registration, and data request. RepuManSC implements the reputation setting and updating functions based on the calls of the other three contracts, as well as determining whether a user can work normally in the system. RepuManSC organizes and manages the authorization verification process, completing the user's permission storage and request verification functions. AccManSC implements the access permission management policy, determining whether the user's data request meets the permission requirements.

[0027] Step 1.3: Initial User Setup: Generate a key for threshold signatures for the initial user: The CA is responsible for generating the threshold key; first, the CA will select a random number x. R ∈Z P Use MSK as the master private key and calculate As the master public key MPK; then, in Z P Randomly select a polynomial P of order t-1 that satisfies P(0) = x R ,in User in the system i Request a threshold key from the CA, User i The private key xi = P(i) used for threshold signatures, and the public key Simultaneously set the initial user's permissions and reputation value (Repu). init =BaseRepu + PerRepu i Z p Let N be a finite field of size p. user Number of users;

[0028] Step 1.4: All users in the system use the same ECC key generation interface to construct ECC public-private key pairs (PK, SK), and PK is completely public on the blockchain;

[0029] Step 2: The system's authentication negotiation process is divided into access authentication and authorization verification. Access authentication is the process for external users to join the system, while authorization verification is required for users. NP There are two types: one is a newly added user who does not yet have permissions. New The first requirement is to obtain permissions for oneself through authorization verification; the second is for existing users in the system. Original To modify one's own permissions, authorization verification is required to change those permissions to another. Authorization verification is a process that needs to be performed when a user is authorized in the system. The authorization verification strategy based on discrete logarithm knowledge signatures uses the PerManSC permission management contract to standardize the two cases, allowing both different authorization goals to be achieved by simply calling the same function. The specific process of the negotiation authentication phase is as follows:

[0030] Step 2.1: External User Outside Send a request to all users within the system. After each user constructs a threshold signature, the User... Outside The data is aggregated into a complete threshold signature and sent to the CA; after verifying the correctness of the threshold signature, the CA sends the blockchain and IPFS certificates, at which point the User... Outside Join the system;

[0031] Step 2.2: Obtain the public and private keys for authorization verification: Because User NP The information requested for authorization is sensitive, containing the user's confidentiality level and organizational function information; therefore, the User NP Sensitive information should not be exposed to other members of the system; in this case, User NP The request is submitted to the CA to authorize the verification of public and private keys. After the CA approves the request, it generates a public and private key pair (y) for authorization and verification. SoK ,x SoK This public-private key pair proves user authorization without disclosing sensitive user authorization information; the authorization verification public-private key is based on... The calculation yields x, where g3 is a generator in the multiplicative cyclic group G3 of order n. Sok It is an element in G3, where both g3 and n are public parameters; CA is providing information to the User. NP Transmission (y SoK ,x SoK After that, y will be made public. SoK The corresponding permission is Per.

[0032] Step 2.3: Generate the knowledge signature for authorization verification based on the knowledge signature generation algorithm: User NP Upon receiving (y) SoK ,xSoK After that, a knowledge signature (c,s) for authorization verification needs to be generated as authorization verification evidence; first, User NP Generate a random number r (0 < r < n), where r is generated using a pseudo-random number algorithm; then, generate the required verification permissions Per. Need message m NP m was calculated NP =H2(m NP ), where H2:{0,1} * →{0,1} n It is a secure one-way hash function; finally, we get c = H2(m) NP ′|y SoK ||g3||g3 r ), s = r - cx SoK The constructed (c,s) is a verifiable knowledge signature, which is the evidence for this authorization verification;

[0033] Step 2.4: Initiate an authorization verification request: User NP Use your own ECC private key SK NP Sign (c,s) to obtain Sign SoK Then, User NP Will use Per Need Construct the hash value m of the message NP 'And the knowledge signature (c,s) is used as a parameter to call the authorization verification function AuthVeri(m) of the PerManSC authorization management contract. NP ',y SoK ,(c,s),Sign SoK );

[0034] Step 2.5: Record and initiate a vote: PerManSC receives User... NP The User is used first after the request is initiated. NP ECC public key PK NP For Sign SoK Upon successful verification, the corresponding information will be recorded in the authorization verification table within the contract. AV Start the countdown timer and generate a unique ID for it. AV After recording is complete, the user's blockchain address (Addr) that initiated the authorization verification request will be obtained from the on-chain transaction that called the PerManSC contract. NP and Id AV Addr NP y SoK m NP '、(c,s) Notify other users in the blockchain network who already have permissions and are functioning correctly.'HP ;

[0035] Step 2.6: Verify the knowledge signature and vote: Other users in the blockchain network who already have the necessary permissions and are properly enabled. Get the ID of this request AV Addr NP y SoK m NP '、(c,s), It will verify the correctness of the knowledge signature, that is Verify User NP The correctness of the provided (c,s); if User NP The provided (c,s) satisfies c = H2(m) NP ′||y SoK ||g3||g3 s y SoK c ), then prove User NP The provided (c,s) is a valid signature, thus proving that User... NP Yes (y) SoK ,x SoK The owner of ) At this point, confirm the correctness of this authorization verification; For User NP After the request is evaluated, the voting content (VoteContent) is generated. AV This indicates whether the verification passed; then, use your own ECC private key. For (Id) AV VoteContent AV Sign to obtain the Sign AV Then the PerManSC voting callback function AVCallback(Id) is called. AV VoteContent AV Sign AV ), complete this vote;

[0036] Step 2.7: Receive and record votes according to the authorized verification voting record algorithm: PerManSC receives... VoteContent AV Next, first query the user permissions table. UP verify The status is "available". Able Time indicates These are normal users who were not disabled; then, using ECC public key Validate SignVote The correctness; then, according to VoteContent AV Modify Table AV Information regarding this request; upon receiving VoteContent AV If it passes, the corresponding total number of passes, Num, will be... Pass Increase by 1 and record the number of confirmed votes cast. serial number When the received VoteContent AV If it fails, the corresponding total number of failures, Num, will be... Fail Increase by 1, and record the number of votes cast that do not pass. serial number

[0037] Step 2.8: Based on the authorization verification result, determine the following algorithm: The voting process ends when the countdown timer expires or all votes are received; otherwise, the voting process ends when the number of approved votes exceeds the total number N of all users with existing permissions and normal access. HP 2 / 3 of that, and User NP If the user does not have original permissions in the system, a unique ID will be generated for that user. NP , with Addr NP Per is recorded together in the user permission table Table within the contract. UP And set User NP Status is enabled. Able Then User NP Addr NP The user is given the parameter `Per` and called `InitRepu` in `RepuManSC` to set an initial reputation value; if the user... NP The purpose of this request is to modify permissions, so change it directly to Per; if the request fails and the number of votes exceeds N... HP If 2 / 3 of the data is received, the request will fail; finally, the authorization verification result (Result) will be displayed. AV Published to the blockchain;

[0038] Step 2.9: Change the reputation value according to the reputation score update algorithm in the authorization verification process: PerManSC obtains the Result AV Next, it is necessary to generate a set of user IDs (IdSet) whose reputation values ​​have been changed and to generate a change type (UpdateType); first, the VoteContent... AV With Result AV The user IDs that do not meet the criteria and the user IDs that did not vote will be combined to form a set IdSet that needs to have reputation points deducted. RedRepuAnd set UpdateType to the Voting Error type; secondly, set VoteContent AV With Result AV A matching user ID generates an IdSet that needs to have its reputation score increased. AddRepu And set UpdateType to the vote correctness type VoteCorrect; finally, PerManSC calls RepuManSC's reputation value change function UpdateRepu(IdSet,UpdateType) with IdSet and UpdateType as parameters; after receiving the reputation value change notification from PerManSC, RepuManSC will modify the user's reputation value recorded in the user reputation table F according to the parameters; when the original reputation value CurRepu i The modified Repu is higher than the user's disable or enable threshold BanThreshold. i When the value is above BanThreshold, RepuManSC will call PerManSC's user status change function ChangeStatus(Id, Status), passing Id. User And set Status to Disable; when CurRepu i Below BanThreshold, modified Repu i When the value is higher than BanThreshold, RepuManSC will call the PerManSC user state change function ChangeStatus(Id, Status), passing Id. User And set the Status to Able; users who have been disabled cannot participate in the authorization verification vote, so no users will be restored to the enabled state at this stage;

[0039] Step 3: Data Requester (User) Req Initiating data requests to the system and retrieving data; using dynamic data access permission management strategies to ensure that all users in the system can become Users. Req Obtain the registered data; the specific process for the data request phase is as follows:

[0040] Step 3.1: First, the data needs to be encrypted and preprocessed before uploading: User Pro Before registering Data, a one-time AES key AK must first be generated, and the Data must be encrypted with AES to obtain the ciphertext Ciph. Data Then, User Pro Ciph DataUploaded to IPFS, IPFS performs partitioning and storage, returning the IPFSHash value IH; then, access permissions are set for the data uploaded to the chain according to the access permission setting function, if Id Data In the access permission table Access If the address does not exist and the call address is ShareSC, then the ID will be... Data Addr Pro Access Data Add it to the table; only then can you retrieve the data description information and initiate a data request: User Req The User obtains descriptive information about all on-chain data through the ShareBC data sharing contract and then sends a request to one of those data points. Req You need to use your own ECC private key SK Req ID of the target data Data Sign up to get Sign Req and using Id Data and Sign Req Use it as a parameter to initiate a data request;

[0041] Step 3.2: Initiate permission verification: When User Req After sending a data request to ShareBC, ShareBC will first verify the Sign. Req After successful verification, ShareBC will transfer the User data. Req Addr Req With Id Data Call the access control function PerCheck(Id) in AccManSC as a parameter Data Addr Req );

[0042] Step 3.3: Access Management Contract Permission Verification: Access permissions are verified using the access permission verification function. After receiving the permission verification request sent by ShareBC via PerCheck, AccManSC will... Req The PerManSC permission query function SelectPer(Addr) is called as a parameter. Req This function is based on Addr Req Query Table UP Get User Req Per permissions Req and Id Req Then, Per Req With Table Access Chinese ID Data Corresponding Access Data Comparison, when Per ReqGreater than Access Data Access in LB or Access WL Contains Id Req At that time, User Req Pass the authorization check; finally, display the check result as Result. PC The process is returned to ShareBC; ShareBC continues the process after receiving a pass result from the AccManSC check, otherwise the process is aborted.

[0043] Step 3.4: IPFSHash and AES key transfer: This is for User Pro and User Req The process of interaction between IH and AK, User Pro Using User (IH||AK) Req ECC public key PK Req Encryption yields Ciph Share After that, Ciph needs to be... Share Using ECC private key SK Pro Get Sign by signing Share and Id Share Ciph Share With Sign Share Send it together to ShareBC; ShareBC uses the stored user's public key to verify the Sign. Share After confirming that there are no errors, proceed according to the ID. Share Query and notify User Req ;

[0044] Step 3.5: Update Reputation Score: In User Req Received Ciph from ShareBC Share After that, the data request ends; ShareBC will generate a file containing only the ID. Pro The IdSet is set, and UpdateType is set to ShareComplete. The ChangeRepu function of RepuManSC is then called to update the score. i =CurRepu i +ShareRepu Succ Perform calculations for User Pro Increase reputation points as an incentive;

[0045] Step 3.6: Download and decrypt data: User Req Using SK Req Decrypting Ciph Share Once you obtain (IH||AK), you can download and decrypt Ciph. DataGet User Req The requested data is Data;

[0046] Step 4: When User Req Discover User Pro If the provided IH and AK are incorrect or the Data does not match the Desc, an appeal will be initiated, and the success of the appeal will be determined by all users with normal privileges in the system.

[0047] Step 4.1: Initiate an appeal request: In the User... Req Received using PK Req After encryption (IH||AK), SK will be used. Req Decrypt the ciphertext to obtain the plaintext's IH and AK; at this point, a User error may occur. Pro The transmitted IH cannot be downloaded correctly in Ciph. Data Using an AK cannot correctly decrypt Ciph. Data Or Data and User Pro Disputes arising from discrepancies between uploaded Desc values; User Req Provide proof of the appeal consisting of (IH||AK) Appeal and for (Id) Req Proof Appeal Using SK Req Sign up Appeal Then, the request / appeal function ReqAppeal(Id) of the access management contract AccManSC is called. Share Proof Appeal Sign Appeal ); while malicious users Req It is also possible to frame a user. Pro The provided IH and AK are incorrect or the Data and User information are incorrect. Pro The uploaded Desc does not match, and an appeal is initiated by calling ReqAppeal;

[0048] Step 4.2: Contract Appeal Notification: After receiving the appeal request, AccManSC will use User... Req ECC public key PK Req Validate Sign Appeal Once verified, AccManSC will generate a unique ID for this appeal. Appeal , with Id Req 、Id Pro Store together in the Request / Appeal Table Appeal In the middle, start the countdown timer; finally, set the ID. Share 、Id Appeal Proof AppealPK Req The blockchain will notify all authorized users to review the appeal.

[0049] Step 4.3: Verify appeal evidence and vote: On-chain except for User Req and User Pro Normal users with privileges After receiving the appeal from AccManSC, from Proof Appeal Obtain (IH||AK) from the middle, and use PK. Req Encryption yields Ciph Share ', with Id Share Corresponding User Pro Ciph provided Share A comparison is performed; if the results do not match, it proves that the User... Req The provided evidence was incorrect, resulting in the generation of a rejected VoteContent. Appeal If Ciph Share 'With Ciph Share If they match, then download the Ciph data according to IH. Data And use AK to decrypt. If you encounter problems such as being unable to download, unable to decrypt, or the data description information (Desc) not matching, it proves that the User... Pro If the provided content is incorrect, a VoteContent will be generated indicating that the appeal has been approved. Appeal Otherwise, a VoteContent indicating that the appeal was unsuccessful will be generated. Appeal ;at last, Use your own ECC private key For (Id) Appeal VoteContent Appeal Sign to obtain the Sign AVote Call the AccManSC appeal voting callback function AppealCallback(Id) Appeal VoteContent Appeal Sign AVote );

[0050] Step 4.4: Receive and record votes: AccManSC receives... After a vote is cast, the system first checks whether the voter is a user with normal on-chain permissions; if not, the vote is discarded. Then, it uses... ECC public key Validate Sign AVote The correctness of Sign AVote If incorrect, discard the vote; then, check the VoteContent. AppealWhether the content contained therein is approved; if the content is approved, then the ID will be... Appeal The corresponding appeal request included the number of votes passed (Num). Pass Increase by 1, otherwise the vote will not pass (Num). Fail Increase by 1 and record. number

[0051] Step 4.5: Appeal Result Judgment: AccManSC will determine the appeal result if the number of votes passing exceeds N after collecting all votes or when the countdown ends. HP Two-thirds of the votes were required for the appeal to be successful; otherwise, the appeal would have been rejected if the number of votes exceeded N. HP If 2 / 3 of the results are received, the appeal is unsuccessful; then, AccManSC will send the Result. Appeal Publish it on the blockchain to notify all users;

[0052] Step 4.6: Reputation Score Update: After AccManSC determines the appeal result, it will generate a set of user IDs (IdSet) for which reputation values ​​need to be changed, and generate a change type (UpdateType). At this point, only the set of user IDs (IdSet) for which reputation points are deducted needs to be generated. RedRepu It also sets UpdateType to the voting error type VoteError, and sets the collection IdSet to which reputation points need to be increased. AddRepu And set UpdateType to the vote correctness type VoteCorrect, call the RepuManSC reputation value change function ChangeRepu; in addition, if Result Appeal For success, generate a generator containing only the ID. Pro IdSet RedRepu Set UpdateType to the data error type ShareError; if Result Appeal Failed; generated only containing Id Req IdSet RedRepu Set UpdateType to AppealError, the type of appeal error; then call ChangeRepu to deduct reputation points from the party at fault in the appeal.

[0053] Step 5: Finally, to address the privacy leakage risks in the architecture, BLS threshold signature, knowledge signature based on discrete logarithms, and all-user voting based on smart contracts, as well as AES keys, ECC keys, and IPFSHash ciphertexts were used to protect data security for User identity signature verification, authorization verification, and data access management involved in the remote sensing image data sharing protocol.

[0054] Identity authentication privacy protection is achieved through BLS threshold signatures; if an external adversary A attempts to forge a complete signature without sending an access authentication request, A needs to construct the master private key MSK; however, MSK is based on Z. P The randomly selected integer has pseudo-randomness in a cryptographic sense, so A cannot know MSK; furthermore, due to the discrete logarithm difficulty problem, it is also impossible to deduce MSK from the master public key MPK; assuming A has not collected enough signatures to aggregate signatures, and wants to forge other users' signatures, A needs to guess these users' private keys; however, A cannot know the random t-1 order polynomial P, cannot calculate the user's private key, and it is also impossible to deduce the user's private key from the user's public key, so A cannot forge other users' signatures to construct a complete threshold signature;

[0055] Authorization verification and privacy protection are achieved through knowledge signatures based on discrete logarithms and voting by all users on the smart contract; if an adversary A in the system does not have the private key x SoK In the case of y, to forge a knowledge signature to gain access, one needs to... SoK Values ​​and formulas Calculate the private key x SoK Or find the expression c = H(m||y) SoK ||g3||g3 s *y SoK c (c,s); For a large number n, if its factorization is unknown, it is impossible to compute the discrete logarithm on the multiplicative generating group G3 of order n in finite time, so A cannot be calculated without x. SoK Forging knowledge signatures in the following scenario; assuming the adversary set S in the system. A ,|S A |=N A One of the adversaries, A i Want to be with other N A -1 opponent {A k} Conspiring to gain higher privileges, at this point, A i This will provide an unverifiable knowledge signature (c′, s′), and the colluding {A} k The malicious claim that (c′,s′) is valid will be made; due to N A <1 / 3*N, while the threshold for successful authentication is 2 / 3*N, so A i Unable to pass authorization verification; when adversaries collude to disrupt other users' authentication processes, the process is the same as when adversaries collude to obtain higher privileges; in addition, the system will deduct reputation points from malicious users, and when the reputation points drop to a threshold, the user will be disabled to ensure that the number of times they commit malicious acts is limited;

[0056] Privacy protection for data access is achieved by layering different encryption algorithms. In the sharing process, the data requester needs to pass the AES key and IPFSHash used for encryption to the data requester. This process uses 160-bit ECC asymmetric encryption technology for privacy protection. The security of ECC encryption is based on the discrete logarithm problem on elliptic curves. Therefore, without obtaining the ECC private key, the probability of cracking the ciphertext of the AES key and IPFSHash is equivalent to the probability of cracking ECDLP. However, there is currently no attack algorithm that can crack ECDLP within an acceptable time. That is, it is secure to use ECC encryption to protect the privacy of the AES key and IPFSHash.

[0057] The beneficial effects of this invention are as follows:

[0058] This invention constructs a blockchain-based privacy-preserving remote sensing image data sharing architecture, using blockchain and IPFS as the underlying network and storage system, respectively. The decentralized, traceable, and immutable characteristics of blockchain provide a foundation of trust among data institutions, creating a reliable sharing environment and effectively reducing the sharing cost of the architecture. A secure remote sensing image data sharing protocol is designed, introducing an authorization verification strategy based on discrete logarithm knowledge signatures and a dynamic data access permission management strategy based on smart contracts. Smart contracts implement user access control and data access verification functions, providing authorization authentication capabilities for all participating parties, performing data access control with low overhead, and limiting the malicious capabilities of malicious users. Furthermore, different cryptographic techniques are introduced for different content during the data sharing process, rather than using the same method for all, thus flexibly and effectively ensuring data privacy and security within the system. Attached Figure Description

[0059] Figure 1 This is a diagram illustrating the architecture of a secure remote sensing image data sharing system based on blockchain and IPFS, according to an embodiment of the present invention.

[0060] Figure 2 This is a flowchart illustrating the system preparation and negotiation / authentication phases in an embodiment of the present invention.

[0061] Figure 3 This is a flowchart illustrating the data registration and data request phases in an embodiment of the present invention.

[0062] Figure 4 This is a flowchart of the appeal stage according to an embodiment of the present invention. Detailed Implementation

[0063] The present invention will be further described below with reference to the accompanying drawings and embodiments;

[0064] Secure remote sensing image data sharing based on blockchain and IPFS consists of three parts: remote sensing image data sharing architecture, secure remote sensing image data sharing protocol, and data privacy protection scheme.

[0065] First, construct as Figure 1 The system shown is a secure remote sensing image data sharing system based on blockchain and IPFS, consisting of five parts: data providers, data requesters, authentication center, a consortium blockchain network composed of users as basic units, and an IPFS proprietary storage system composed of storage services provided by participating users.

[0066] Data Provider User Pro Users who share remote sensing image data in the system will encrypt the remote sensing image data according to the remote sensing image data sharing protocol, and then share the remote sensing image data to the system for easy access by data requesters;

[0067] Data Requester User Req User is a user who requests remote sensing image data from the system. Req Through blockchain and users Pro Interactive acquisition of remote sensing image data;

[0068] A Certificate Authority (CA) is an entity that issues identity verification, blockchain, and IPFS certificates to users in the system. The CA also needs to generate and update keys used for threshold signatures.

[0069] The blockchain network BC is a consortium blockchain composed of nodes provided by each user participating in the system. It is the basic network for the system's operation. Almost all user operations are propagated and implemented in the system through the blockchain network. Through the consensus protocol in the blockchain network, all nodes participate in the inspection and storage of information or data in the network. The code execution and event generation of smart contracts are also implemented and stored through the blockchain, ensuring the credibility and openness of user operation results.

[0070] The proposed remote sensing image data sharing protocol addresses security issues in the data sharing process by addressing trust problems among participants. Considering the diverse characteristics of remote sensing image data, it designs three strategies: access control, data verification, and request / appeal. Furthermore, it incorporates reputation as an incentive within the protocol's operation, further enhancing the security and robustness of the proposed data sharing scheme. Simultaneously, at each stage of the protocol, a data privacy protection scheme is introduced. Leveraging the differences between symmetric and asymmetric encryption algorithms in terms of encryption / decryption rates and whether the key is fixed, a hybrid approach combining symmetric and asymmetric encryption with the three strategies mentioned above ensures the security of data access, data transmission, and data storage throughout the data sharing protocol process.

[0071] The workflow of the remote sensing image data sharing protocol includes the following five stages: system preparation stage, negotiation and authentication stage, data registration stage, data request stage, and request appeal stage. In each stage, users additionally sign the messages using their ECC private keys to ensure the non-repudiation of the messages.

[0072] System preparation phase: This phase is the system initialization phase; after the system is built, it is necessary to set the parameters in the system, deploy the required smart contracts, and set up the initial users in the system.

[0073] Negotiation and authentication phase: This phase includes two scenarios: the process of external users undergoing access authentication and joining the consortium blockchain network and IPFS, and the authorization and verification process for new users joining the system or users in the system to change permissions.

[0074] Data registration phase: This phase is the process by which data providers register data on the blockchain and set data access permissions.

[0075] Data Request Phase: This phase is when the data requester requests data and the data provider provides the IPFSHash and AES one-time key. When the data requester requests data, the data sharing contract will call the access management contract to verify permissions before continuing the sharing process.

[0076] Request for Appeal Stage: This stage is for appealing when disputes arise after the sharing process has ended. If a data provider maliciously sends incorrect IPFSHash and AES keys or provides data that does not match the description information, causing a sharing dispute, an appeal is required. At the same time, it is also necessary to prevent malicious data requesters from falsely accusing data providers.

[0077] The IPFS distributed storage system consists of user-provided storage services, including user-provided IPFS node entities (IPFSNode), which are responsible for storing and downloading remote sensing image data. IPFS will split, back up, and store the data, and distribute it to multiple nodes on the blockchain, returning the corresponding IPFSHash to the user.

[0078] A secure remote sensing image data sharing method based on blockchain and IPFS, implemented based on the aforementioned secure remote sensing image data sharing system based on blockchain and IPFS, specifically includes the following:

[0079] Step 1: The first step is the system preparation and initialization phase, and the protocol flowchart for the negotiation and authentication phase is as follows: Figure 2 As shown, it is necessary to define parameters, deploy contracts, and perform initial settings for users in the system; users in the system act as data providers. ProAlso as a data requester User Req The system prepares for the user's blockchain network by providing services and generating a unique blockchain address, Addr. The specific process for this preparation phase is as follows:

[0080] Step 1.1: Define parameters: Initialize the public parameters required for the threshold signature; the parameters include two multiplicative cyclic groups G1 and G2 of order P, where g1 and g2 are the generators of G1 and G2 respectively, and e is a bilinear mapping: G1*G2→G T H1:{0,1} * →G1 is a secure one-way hash function; additionally, seven parameters need to be set: the base reputation value BaseRepu, and the reputation value PerRepu corresponding to each permission. i Successful data sharing increases reputation value (ShareRepu). Succ AppealRepu, the party at fault, will have their reputation score deducted. Error Voting correctly increases your reputation score (VoteRepu). Cor Malicious voting deducts reputation points (VoteRepu) Incor The user-disabled and enabled threshold, BanThreshold, is a parameter that users negotiate and define based on their level of trust in the system; where BaseRepu is the user's reputation base, and PerRepu... i It's related to user permissions. Generally, users with higher permissions have higher visibility and corresponding perRepu. i The larger the size, the better; secondly, in order to effectively limit user behavior in the system, AppealRepu... Error It must be greater than ShareRepu Succ VoteRepu Incor It must be greater than VoteRepu Cor BanThreshold is defined as the minimum reputation value of a user account, which is related to whether the user account is disabled. In addition, it is necessary to define the mapping relationship between the user's actual ability and system permissions with the CA. After the CA assesses the user's actual ability, it will give the user the permissions that should be granted in the system.

[0081] Step 1.2: Deploying Contracts: To achieve the system's data sharing function, after the blockchain network is built, the system developers need to deploy four contracts: the data sharing contract ShareSC, the reputation management contract RepuManSC, the permission management contract PerManSC, and the access management contract AccManSC. ShareSC mainly provides functions for obtaining data description information, data registration, and data request. RepuManSC implements the functions of reputation setting and updating based on the calls of the other three contracts, as well as determining whether a user can work normally in the system. RepuManSC mainly organizes and manages the authorization verification process, and completes the functions of user permission storage and request verification. AccManSC mainly implements the access permission management policy and determines whether the user's data request meets the permission requirements.

[0082] Step 1.3: Initial User Setup: Generate a key for threshold signatures for the initial user: The CA is responsible for generating the threshold key; first, the CA will select a random number x. R ∈Z P Use MSK as the master private key and calculate As the master public key MPK; then, in Z P Randomly select a polynomial P of order t-1 that satisfies P(0) = x R ,in User in the system i Request a threshold key from the CA, User i The private key x used for threshold signatures i =P(i), public key Simultaneously set the initial user's permissions and reputation value (Repu). init =BaseRepu + PerRepu i Z p Let N be a finite field of size p. user Number of users;

[0083] Step 1.4: All users in the system use the same ECC key generation interface to construct ECC public-private key pairs (PK, SK), and PK is completely public on the blockchain;

[0084] Step 2: The system's authentication negotiation process is divided into access authentication and authorization verification. Access authentication is the process for external users to join the system, while authorization verification is required for users. NP There are two types: one is a newly added user who does not yet have permissions. New The first requirement is to obtain permissions for oneself through authorization verification; the second is for existing users in the system. OriginalTo modify one's own permissions, authorization verification is required to change those permissions to another. Authorization verification is a process that needs to be performed when a user is authorized in the system. The authorization verification strategy based on discrete logarithm knowledge signatures uses the PerManSC permission management contract to standardize the two cases, allowing both different authorization goals to be achieved by simply calling the same function. The specific process of the negotiation authentication phase is as follows:

[0085] Step 2.1: External User Outside Send a request to all users within the system. After each user constructs a threshold signature, the User... Outside The data is aggregated into a complete threshold signature and sent to the CA; after verifying the correctness of the threshold signature, the CA sends the blockchain and IPFS certificates, at which point the User... Outside Join the system;

[0086] Step 2.2: Obtain the public and private keys for authorization verification: Because User NP The information requested for authorization is sensitive, containing the user's confidentiality level and organizational function information; therefore, User NP Sensitive information should not be exposed to other members of the system; in this case, User NP The request is submitted to the CA to authorize the verification of public and private keys. After the CA approves the request, it generates a public and private key pair (y) for authorization and verification. SoK ,x SoK This public-private key pair proves user authorization without disclosing sensitive user authorization information; the authorization verification public-private key is based on... The calculation yields x, where g3 is a generator in the multiplicative cyclic group G3 of order n. Sok It is an element in G3, where both g3 and n are public parameters; CA is providing information to the User. NP Transmission (y SoK ,x SoK After that, y will be made public. SoK The corresponding permission is Per.

[0087] Step 2.3: Based on the knowledge signature generation algorithm in Table 1, generate the knowledge signature for authorization verification: User NP Upon receiving (y) SoK ,x SoK After that, a knowledge signature (c,s) for authorization verification needs to be generated as authorization verification evidence; first, User NP Generate a random number r (0 < r < n), where r is generated using a pseudo-random number algorithm; then, generate the required verification permissions Per. Need message m NP m was calculated NP =H2(m NP), where H2:{0,1} * →{0,1} n It is a secure one-way hash function; finally, we get c = H2(m) NP ′||y SoK ||g3||g3 γ ), s = r - cx SoK The constructed (c,s) is a verifiable knowledge signature, which is the evidence for this authorization verification;

[0088] Table 1. Knowledge Signature Generation Algorithm;

[0089]

[0090] Step 2.4: Initiate an authorization verification request: User NP Use your own ECC private key SK NP Sign (c,s) to obtain Sign SoK Then, User NP Will use Per Need Construct the hash value m of the message NP 'And the knowledge signature (c,s) is used as a parameter to call the authorization verification function AuthVeri(m) of the PerManSC authorization management contract. NP ',y SoK ,(c,s),Sign SoK );

[0091] Step 2.5: Record and initiate a vote: PerManSC receives User... NP The User is used first after the request is initiated. NP ECC public key PK NP For Sign SoK Upon successful verification, the corresponding information will be recorded in the authorization verification table within the contract. AV Start the countdown timer and generate a unique ID for it. AV After recording is complete, the user's blockchain address (Addr) that initiated the authorization verification request will be obtained from the on-chain transaction that called the PerManSC contract. NP and Id AV Addr NP y SoK m NP '、(c,s) Notify other users in the blockchain network who already have permissions and are functioning correctly.' HP ;

[0092] Step 2.6: Verify the knowledge signature and vote: Other users in the blockchain network who already have the necessary permissions and are properly enabled. Get the ID of this request AV Addr NP y SoK m NP '、(c,s), It will verify the correctness of the knowledge signature, that is Verify User NP The correctness of the provided (c,s); if User NP The provided (c,s) satisfies c = H2(m) NP ′||y SoK ||g3||g3 s y SoK c ), then prove User NP The provided (c,s) is a valid signature, thus proving that User... NP Yes (y) SoK ,x SoK The owner of ) At this point, confirm the correctness of this authorization verification; For User NP After the request is evaluated, the voting content (VoteContent) is generated. AV This indicates whether the verification passed; then, use your own ECC private key. For (Id) AV VoteContent AV Sign to obtain the Sign AV Then the PerManSC voting callback function AVCallback(Id) is called. AV VoteContent AV Sign AV ), complete this vote;

[0093] Step 2.7: Based on the authorization verification voting record algorithm in Table 2, receive and record the votes: PerManSC receives... VoteContent AV Next, first query the user permissions table. UP verify The status is "available". Able Time indicates These are normal users who were not disabled; then, using ECC public key Validate Sign Vote The correctness; then, according to VoteContent AV Modify Table AV Information regarding this request; upon receiving VoteContentAV If it passes, the corresponding total number of passes, Num, will be... Pass Increase by 1 and record the number of confirmed votes cast. serial number When the received VoteContent AV If it fails, the corresponding total number of failures, Num, will be... Fail Increase by 1, and record the number of votes cast that do not pass. serial number

[0094] Table 2. Authorization Verification Voting Record Algorithm;

[0095]

[0096]

[0097] Step 2.8: Based on the authorization verification results in Table 3, determine the verification results: The voting process ends when the countdown timer expires or all votes are received; otherwise, the voting process ends when the number of approved votes exceeds the total number N of all users with existing permissions and normal access. HP 2 / 3 of that, and User NP If the user does not have original permissions in the system, a unique ID will be generated for that user. NP , with Addr NP Per is recorded together in the user permission table Table within the contract. UP And set User NP Status is enabled. Able Then User NP Addr NP The user is given the parameter `Per` and called `InitRepu` in `RepuManSC` to set an initial reputation value; if the user... NP The purpose of this request is to modify permissions, so change it directly to Per; if the request fails and the number of votes exceeds N... HP If 2 / 3 of the data is received, the request will fail; finally, the authorization verification result (Result) will be displayed. AV Published to the blockchain;

[0098] Table 3. Algorithm for determining authorization verification results;

[0099]

[0100]

[0101] Step 2.9: Implement the reputation value change according to the reputation score update algorithm in the authorization verification process of Table 4: PerManSC obtains the Result AVNext, it is necessary to generate a set of user IDs (IdSet) whose reputation values ​​have been changed and to generate a change type (UpdateType); first, the VoteContent... AV With Result AV The user IDs that do not meet the criteria and the user IDs that did not vote will be combined to form a set IdSet that needs to have reputation points deducted. RedRepu And set UpdateType to the Voting Error type; secondly, set VoteContent AV With Result AV A matching user ID generates an IdSet that needs to have its reputation score increased. AddRepu And set UpdateType to the vote correctness type VoteCorrect; finally, PerManSC calls RepuManSC's reputation value change function UpdateRepu(IdSet,UpdateType) with IdSet and UpdateType as parameters; after receiving the reputation value change notification from PerManSC, RepuManSC will modify the user's reputation value recorded in the user reputation table F according to the parameters; when the original reputation value CurRepu i The modified Repu is higher than the user's disable or enable threshold BanThreshold. i When the value is above BanThreshold, RepuManSC will call PerManSC's user status change function ChangeStatus(Id, Status), passing Id. User And set Status to Disable; when CurRepu i Below BanThreshold, modified Repu i When the value is higher than BanThreshold, RepuManSC will call the PerManSC user state change function ChangeStatus(Id, Status), passing Id. User And set the Status to Able; users who have been disabled cannot participate in the authorization verification vote, so no users will be restored to the enabled state at this stage;

[0102] Table 4. Authorization Verification Reputation Score Update Algorithm;

[0103]

[0104]

[0105] Step 3: Data Requester (User) ReqInitiating data requests to the system and retrieving data; using dynamic data access permission management strategies to ensure that all users in the system can become Users. Req Obtain the registered data; the specific data registration and data request processes are as follows: Figure 3 As shown, the specific process of the data request phase is as follows:

[0106] Step 3.1: First, the data needs to be encrypted and preprocessed before uploading: User Pro Before registering Data, a one-time AES key AK must first be generated, and the Data must be encrypted with AES to obtain the ciphertext Ciph. Data Then, User Pro Ciph Data Uploaded to IPFS, IPFS performs partitioning and storage, returning the IPFSHash value IH; then, permissions are set for the data uploaded to the chain according to the access permission setting function in Table 5, if Id Data In the access permission table Access If the address does not exist and the call address is ShareSC, then the ID will be... Data Addr Pro Access Data Add it to the table; only then can you retrieve the data description information and initiate a data request: User Req The User obtains descriptive information about all on-chain data through the ShareBC data sharing contract and then sends a request to one of those data points. Req You need to use your own ECC private key SK Req ID of the target data Data Get Sign by signing Req and using Id Data and Sign Req Use it as a parameter to initiate a data request;

[0107] Table 5. Functions for setting access permissions;

[0108]

[0109]

[0110] Step 3.2: Initiate permission verification: When User Req After sending a data request to ShareBC, ShareBC will first verify the Sign. Req After successful verification, ShareBC will transfer the User data. Req Addr Req With Id DataCall the access control function PerCheck(Id) in AccManSC as a parameter Data Addr Req );

[0111] Step 3.3: Access Management Contract Permission Verification: Access permissions are verified using the PerCheck function. The pseudocode for PerCheck is shown in Table 6. After receiving the permission verification request sent by ShareBC via PerCheck, AccManSC will... Req The PerManSC permission query function SelectPer(Addr) is called as a parameter. Req This function is based on Addr Req Query Table UP Get User Req Per permissions Req and Id Req Then, Per Req With Table Access Chinese ID Data Corresponding Access Data Comparison, when Per Req Greater than Access Data Access LB or Access WL Contains Id Req At that time, User Req Pass the authorization check; finally, display the check result as Result. PC The process is returned to ShareBC; ShareBC continues the process after receiving a pass result from the AccManSC check, otherwise the process is aborted.

[0112] Table 6 Access permission verification functions;

[0113]

[0114] Step 3.4: IPFSHash and AES key transfer: This is for User Pro and User Req The process of interaction between IH and AK, User Pro Using User (IH||AK) Req ECC public key PK Req Encryption yields Ciph Share After that, Ciph needs to be... Share Using ECC private key SK Pro Sign up to get Sign Share and Id Share Ciph Share With SignShare Send it together to ShareBC; ShareBC uses the stored user's public key to verify the Sign. Share After confirming that there are no errors, proceed according to the ID. Share Query and notify User Req ;

[0115] Step 3.5: Update Reputation Score: In User Req Received Ciph from ShareBC Share After that, the data request ends; ShareBC will generate a file containing only the ID. Pro The IdSet is set, and UpdateType is set to ShareComplete. The ChangeRepu function of RepuManSC is then called to update the score. i =CurRepu i +ShareRepu Succ Perform calculations for User Pro Increase reputation points as an incentive;

[0116] Step 3.6: Download and decrypt data: User Req Using SK Req Decrypting Ciph Share Once you obtain (IH||AK), you can download and decrypt Ciph. Data Get User Req The requested data is Data;

[0117] Step 4: When User Req Discover User Pro If the provided IH and AK are incorrect, or if the Data does not match the Desc, an appeal is initiated. The success of the appeal is determined by all authorized users in the system. The appeal process is as follows: Figure 4 As shown.

[0118] Step 4.1: Initiate an appeal request: In the User... Req Received using PK Req After encryption (IH||AK), SK will be used. Req Decrypt the ciphertext to obtain the plaintext's IH and AK; at this point, a User error may occur. Pro The transmitted IH cannot be downloaded correctly in Ciph. Data Using an AK cannot correctly decrypt Ciph. Data Or Data and User Pro Disputes arising from discrepancies between uploaded Desc values; User Req Provide proof of the appeal consisting of (IH||AK) Appeal and for (Id)Req Proof Appeal Using SK Req Sign up Appeal Then, the request / appeal function ReqAppeal(Id) of the access management contract AccManSC is called. Share Proof Appeal Sign Appeal ); while malicious users Req It is also possible to frame a user. Pro The provided IH and AK are incorrect or the Data and User information are incorrect. Pro The uploaded Desc does not match, and an appeal is initiated by calling ReqAppeal;

[0119] Step 4.2: Contract Appeal Notification: After receiving the appeal request, AccManSC will use User... Req ECC public key PK Req Validate Sign Appeal Once verified, AccManSC will generate a unique ID for this appeal. Appeal , with Id Req 、Id Pro Store together in the Request / Appeal Table Appeal In the middle, start the countdown timer; finally, set the ID. Share 、Id Appeal Proof Appeal PK Req The blockchain will notify all authorized users to review the appeal.

[0120] Step 4.3: Verify appeal evidence and vote: On-chain except for User Req and User Pro Normal user with permissions HPi After receiving the appeal from AccManSC, from Proof Appeal Obtain (IH||AK) from the middle, and use PK. Req Encryption yields Ciph Share ', with Id Share Corresponding User Pro Ciph provided Share A comparison is performed; if the results do not match, it proves that the User... Req The provided evidence was incorrect, resulting in the generation of a rejected VoteContent. Appeal If Ciph Share 'With Ciph Share If they match, then download the Ciph data according to IH. DataAnd use AK to decrypt. If you encounter problems such as being unable to download, unable to decrypt, or the data description information (Desc) not matching, it proves that the User... Pro If the provided content is incorrect, a VoteContent will be generated indicating that the appeal has been approved. Appeal Otherwise, a VoteContent indicating that the appeal was unsuccessful will be generated. Appeal ;at last, Use your own ECC private key For (Id) Appeal VoteContent Appeal Sign to obtain the Sign AVote Call the AccManSC appeal voting callback function AppealCallback(Id) Appeal VoteContent Appeal Sign AVote );

[0121] Step 4.4: Receive and record votes: AccManSC receives... After a vote is cast, the system first checks whether the voter is a user with normal on-chain permissions; if not, the vote is discarded. Then, it uses... ECC public key Validate Sign AVote The correctness of Sign AVote If incorrect, discard the vote; then, check the VoteContent. Appeal Whether the content contained therein is approved; if the content is approved, then the ID will be... Appeal The corresponding appeal request included the number of votes passed (Num). Pass Increase by 1, otherwise the vote will not pass (Num). Fail Increase by 1 and record. number

[0122] Step 4.5: Appeal Result Judgment: AccManSC will determine the appeal result if the number of votes passing exceeds N after collecting all votes or when the countdown ends. HP Two-thirds of the votes were required for the appeal to be successful; otherwise, the appeal would have been rejected if the number of votes exceeded N. HP If 2 / 3 of the results are received, the appeal is unsuccessful; then, AccManSC will send the Result. Appeal Publish it on the blockchain to notify all users;

[0123] Step 4.6: Reputation Score Update: After AccManSC determines the appeal result, it will generate a set of user IDs (IdSet) for which reputation values ​​need to be changed, and generate a change type (UpdateType). At this point, only the set of user IDs (IdSet) for which reputation points are deducted needs to be generated. RedRepuIt also sets UpdateType to the voting error type VoteError, and sets the collection IdSet to which reputation points need to be increased. AddRepu And set UpdateType to the vote correctness type VoteCorrect, call the RepuManSC reputation value change function ChangeRepu; in addition, if Result Appeal For success, generate a generator containing only the ID. Pro IdSet RedRepu Set UpdateType to the data error type ShareError; if Result Appeal Failed; generated only containing Id Req IdSet RedRepu Set UpdateType to AppealError, the type of appeal error; then call ChangeRepu to deduct reputation points from the party at fault in the appeal.

[0124] Step 5: Finally, to address the privacy leakage risks in the architecture, BLS threshold signature, knowledge signature based on discrete logarithms, and all-user voting based on smart contracts, as well as AES keys, ECC keys, and IPFSHash ciphertexts were used to protect data security for User identity signature verification, authorization verification, and data access management involved in the remote sensing image data sharing protocol.

[0125] Identity authentication privacy protection is achieved through BLS threshold signatures; if an external adversary A attempts to forge a complete signature without sending an access authentication request, A needs to construct the master private key MSK; however, MSK is based on Z. P The randomly selected integer has pseudo-randomness in a cryptographic sense, so A cannot know MSK; furthermore, due to the discrete logarithm difficulty problem, it is also impossible to deduce MSK from the master public key MPK; assuming A has not collected enough signatures to aggregate signatures, and wants to forge other users' signatures, A needs to guess these users' private keys; however, A cannot know the random t-1 order polynomial P, cannot calculate the user's private key, and it is also impossible to deduce the user's private key from the user's public key, so A cannot forge other users' signatures to construct a complete threshold signature;

[0126] Authorization verification and privacy protection are achieved through knowledge signatures based on discrete logarithms and voting by all users on the smart contract; if an adversary A in the system does not have the private key x SoK In the case of y, to forge a knowledge signature to gain access, one needs to... SoK Values ​​and formulas Calculate the private key x SoK Or find the expression c = H(m||y) SoK||g3||g3 s *y SoK c (c,s); For a large number n, if its factorization is unknown, it is impossible to compute the discrete logarithm on the multiplicative generating group G3 of order n in finite time, so A cannot be calculated without x. SoK Forging knowledge signatures in the following scenario; assuming the adversary set S in the system. A ,|S A |=N A One of the adversaries, A i Want to be with other N A -1 opponent {A k} Conspiring to gain higher privileges, at this point, A i This will provide an unverifiable knowledge signature (c′, s′), and the colluding {A} k The malicious claim that (c′,s′) is valid will be made; due to N A <1 / 3*N, while the threshold for successful authentication is 2 / 3*N, so A i Unable to pass authorization verification; when adversaries collude to disrupt other users' authentication processes, the process is the same as when adversaries collude to obtain higher privileges; in addition, the system will deduct reputation points from malicious users, and when the reputation points drop to a threshold, the user will be disabled to ensure that the number of times they commit malicious acts is limited;

[0127] Privacy protection for data access is achieved by layering different encryption algorithms. In the sharing process, the data requester needs to pass the AES key and IPFSHash used for encryption to the data requester. This process uses 160-bit ECC asymmetric encryption technology for privacy protection. The security of ECC encryption is based on the discrete logarithm problem on elliptic curves. Therefore, without obtaining the ECC private key, the probability of cracking the ciphertext of the AES key and IPFSHash is equivalent to the probability of cracking ECDLP. However, there is currently no attack algorithm that can crack ECDLP within an acceptable time. That is, it is secure to use ECC encryption to protect the privacy of the AES key and IPFSHash.

Claims

1. A secure remote sensing image data sharing method based on blockchain and IPFS, characterized in that, Specifically, it includes the following: Step 1: In the initialization preparation phase, define parameters, deploy contracts, and perform initial settings for users in the system; users in the system act as data providers. Also as a data requester It provides services to become a node in the blockchain network and generates a unique blockchain address for that user. ; Step 2: The system's authentication process is divided into access authentication and authorization verification. Access authentication is the process for external users to join the system, while authorization verification is required for users. There are two types: one is newly joined users who do not yet have permissions. One requirement is to obtain permissions for oneself through authorization verification; the other is for existing users in the system. To modify your own permissions, you need to go through authorization verification to change your permissions to another permission. Authorization verification is the process that needs to be performed when a user is authorized in the system; The authorization and verification strategy based on discrete logarithm knowledge signatures uses permission management contracts. A unified standard was established for the two cases, so that the two different authorization goals can be achieved simply by calling the same function; Step 3: Data Requester Initiating data requests to the system and retrieving data; using dynamic data access permission management policies to ensure that all users in the system can become... Obtain the registered data; Step 4: When Discover Provided and Incorrect or and If a discrepancy is found, an appeal is initiated, and the success of the appeal is determined by all users with valid permissions in the system; among them, A one-time AES key, It is the IPFSHash value. for The requested data; Step 5: Finally, to address the privacy leakage risks in the architecture, BLS threshold signature, knowledge signature based on discrete logarithms, and all-user voting based on smart contracts, as well as AES keys, ECC keys, and IPFSHash ciphertexts were used to protect data security for User identity signature verification, authorization verification, and data access management involved in the remote sensing image data sharing protocol. Step 4 specifically involves: Step 4.1: Initiate an appeal request: In Received and used Encrypted After that, it will be used Decrypt the ciphertext to obtain the plaintext. and At this time, it may happen Transmitted Unable to download correctly ,use Unable to decrypt correctly or and Uploaded This does not match the dispute details; Provided by Composition of Appeal Evidence and to use Signature obtained Then call the access management contract Request / appeal function And malicious It is also possible to frame someone. Provided and Incorrect or and Uploaded Inconsistent and call Initiate an appeal; Step 4.2: Contract Appeal Notification: Upon receiving the appeal request, we will use ECC public key verify After verification, A unique number will be generated for this appeal. ,and , Store together in the appeal form In the middle, and start the countdown timer; finally, , , , The blockchain will notify all authorized users to review the appeal. Step 4.3: Verify appeal evidence and vote: On-chain except and Normal users with privileges Upon receiving After the appeal was filed, from Get from and use Encryption yields ciphertext ,and correspond Provided A comparison is performed; if the results do not match, then it proves... The provided evidence was incorrect, resulting in an unsuccessful appeal. ;if and If they match, then according to Download data and use Decryption; if you encounter issues such as inability to download, inability to decrypt, or other problems... Description information If they do not match, then it proves... If the information provided is incorrect, the appeal will be approved. Otherwise, the appeal will be rejected. ;at last, Use your own ECC private key right Obtain by signing , call Appeal voting callback function ; Step 4.4: Receive and record votes: Received After a vote is cast, the system first checks whether the voter is a user with normal on-chain permissions; if not, the vote is discarded. Then, it uses... ECC public key verify The correctness, if If incorrect, discard the vote; then, determine... Whether the content contained therein is approved; if the content is approved, then... The number of votes passed in the corresponding appeal request Increase by 1, otherwise the vote will not pass. Increase by 1 and record. number ; Step 4.5: Judgment of Appeal Result: If the number of votes exceeds the total number of all users with existing permissions and normal activation, the votes will be collected once all votes are collected or the countdown ends. of The appeal was successful; otherwise, the number of votes would have exceeded [a certain threshold]. of If not, the appeal will be unsuccessful; then, Will Publish it on the blockchain to notify all users; Step 4.6: Reputation Score Update: After determining the appeal outcome, a set of user IDs for whom reputation values ​​need to be changed will be generated. And generate change type At this point, it is only necessary to generate a set of scores deducted from the reputation score. and set Voting error type And the set that needs to increase its reputation score. and set For the correct voting type , call Reputation value change function Furthermore, if For success, the generated code will contain only... of ,set up For data error type ;if Failure; only generated content containing of ,set up For the type of appeal error Then, call Credit points will be deducted from the party at fault in the appeal; The system consists of five parts: data providers, data requesters, authentication center, a consortium blockchain network composed of users as basic units, and an IPFS distributed storage system composed of storage services provided by participating users. Data Provider Users who share remote sensing image data in the system will encrypt the remote sensing image data according to the remote sensing image data sharing protocol, and then share the remote sensing image data to the system for easy access by data requesters; Data requester This refers to the user who requests remote sensing image data within the system. Through blockchain and Interactive acquisition of remote sensing image data; Certification Center It is the entity that issues identity verification, blockchain, and IPFS certificates to users within the system. It also requires the generation and updating of keys used for threshold signatures; Blockchain Network It is a consortium blockchain composed of nodes provided by each user participating in the system. It is the basic network for the operation of the system. All user operations will be propagated and implemented in the system through the blockchain network. Through the consensus protocol in the blockchain network, all nodes will participate in the inspection and storage of information or data in the network. The operation of smart contracts and the generation of events are also realized and stored through the blockchain to ensure the credibility and openness of user operation results. The IPFS distributed storage system consists of user-provided storage services within the system, including user-provided IPFS node entities. It is responsible for storing and downloading remote sensing image data; the IPFS distributed storage system will split, back up, and store the data and distribute it to nodes on the blockchain, returning the corresponding IPFSHash to the user.

2. The secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, The remote sensing image data sharing protocol, considering the diverse characteristics of remote sensing image data itself, designs three strategies: access control, data verification, and request / appeal. Reputation is incorporated as an incentive throughout the protocol's operation. Simultaneously, a data privacy protection scheme is introduced at each stage of the protocol. Utilizing the differences between symmetric and asymmetric encryption algorithms in terms of encryption / decryption speed and whether the key is fixed, a hybrid approach combining symmetric and asymmetric encryption with the three strategies mentioned above ensures the security of data access, data transmission, and data storage within the data sharing protocol process. The workflow of the remote sensing image data sharing protocol includes the following five stages: system preparation stage, negotiation and authentication stage, data registration stage, data request stage, and request appeal stage. In each stage, users additionally sign the messages using their ECC private keys to ensure the non-repudiation of the messages. System preparation phase: This phase is the system initialization phase; after the system is built, it is necessary to set the parameters in the system, deploy the required smart contracts, and set up the initial users in the system. Negotiation and authentication phase: This phase includes two scenarios: the process of external users undergoing access authentication and joining the consortium blockchain network and IPFS, and the authorization and verification process for new users joining the system or users in the system to change permissions. Data registration phase: This phase is the process by which data providers register data on the blockchain and set data access permissions. Data Request Phase: This phase involves the data requester requesting data and the data provider providing the IPFSHash and AES one-time key. When a data requester requests data, the data sharing contract will call the access management contract at this stage to verify permissions before continuing the sharing process. Request for Appeal Stage: This stage is for appealing when disputes arise after the sharing process has ended. If a data provider maliciously sends incorrect IPFSHash and AES keys or provides data that does not match the description information, causing a sharing dispute, an appeal is required. At the same time, it is also necessary to prevent malicious data requesters from falsely accusing the data provider.

3. The secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, The specific process for the system preparation stage in Step 1 is as follows: Step 1.1: Define parameters: Public parameters required to initialize the threshold signature; the parameters include two orders. Multiplication cyclic group , , , They are , generator, It is a bilinear mapping: , It is a secure one-way hash function; in addition, seven parameters need to be set, namely the base reputation value. Reputation value corresponding to each permission Successful data sharing increases reputation score. The party at fault in the appeal will have their reputation score deducted. Voting correctly increases reputation value Malicious voting will result in the deduction of reputation points. User disable and enable thresholds Users negotiate and define parameters based on their level of trust in the system; among them, As the base for user credit score, It's related to user permissions; the higher the user's permissions, the greater their visibility. The larger the size, the better; secondly, in order to effectively limit user behavior in the system, Must be greater than , Must be greater than ; Defined as the minimum reputation score for a user account, it determines whether the user account is disabled; in addition, it needs to be submitted to... Define the mapping relationship between users' actual capabilities and system permissions. After the CA (Certificate Authority) assesses the users' actual capabilities, it assigns the permissions that users should be granted in the system. Step 1.2: Deploying Contracts: To implement the system's data sharing function, after the blockchain network is built, the system developers need to deploy four contracts, namely the data sharing contract. Credit Management Contract Access Management Contract and access management contract ; Provides functions for obtaining data description information, data registration, and data request. The system implements reputation setting and updating functions based on calls to three other contracts, and determines whether a user can work normally in the system. It organizes and manages the authorization verification process, and completes the functions of storing user permissions and verifying requests; Access control policies were implemented to determine whether a user's data request met the permission requirements. Step 1.3: Initial User Setup: Generate a key for threshold signatures for the initial user. Responsible for generating the threshold key; first, A random number will be selected. As the master private key and calculate As the master public key Then, in Random selection polynomial of order ,satisfy ,in Users in the system Towards Request a threshold key. Private key used for threshold signature Public key Simultaneously set the initial user's permissions and reputation score. ; For a finite field of size p, Number of users; Step 1.4: All users in the system use the same ECC key generation interface to construct ECC public-private key pairs. , Completely public on the blockchain.

4. The secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, The specific process for step 2, the negotiation and certification phase, is as follows: Step 2.1: External Users A request is sent to all users within the system. After each user constructs a threshold signature, the request is processed. Aggregate into a complete threshold signature and send to ; After verifying the correctness of the threshold signature, the blockchain and IPFS certificates will be sent. Join the system; Step 2.2: Obtain the public and private keys for authorization verification: Because The information requested for authorization is sensitive, containing the user's confidentiality level and organizational function information; therefore, Sensitive information must not be exposed to other members of the system; at this time, Towards Submit a request to authorize verification of public and private keys. After the application is approved, a public / private key pair for authorization verification is generated. This public-private key pair proves user authorization without disclosing sensitive user authorization information; the authorization verification public-private key is based on... The calculation yielded, where Therefore Multiplicative cyclic group of order 1 One of the generators, yes One of the elements, and All parameters are publicly available; In the direction transmission Afterwards, it will be made public. Corresponding permissions ; Step 2.3: Generate a knowledge signature for authorization verification based on the knowledge signature generation algorithm: Upon receiving Next, a knowledge signature for authorization verification needs to be generated. As evidence of authorization verification; firstly Generate a random number , It is generated using a pseudo-random number algorithm; then, the required verification permissions are generated. News Calculations yielded ,in It is a secure one-way hash function; finally, we get , , constructed A verifiable knowledge signature serves as evidence for this authorization verification. Step 2.4: Initiate an authorization verification request: Use your own ECC private key right Sign it and get ;Then, will use Construct the hash value of the message and knowledge signatures The permission management contract was invoked as a parameter. Authorization verification function ; Step 2.5: Record and initiate a vote: Upon receiving After the request is initiated, first use ECC public key right Upon successful verification, the relevant information will be recorded in the authorization verification form within the contract. Start the countdown timer and generate a unique number for it. After recording is complete, it will be retrieved from the caller. Obtain the user's blockchain address that initiated the authorization verification request during on-chain transactions within the contract. and will , , , , Notify other users in the blockchain network who already have the necessary permissions and are functioning correctly. ; Step 2.6: Verify the knowledge signature and vote: Other users in the blockchain network who already have the necessary permissions and are properly enabled. Obtain the request , , , , , It will verify the correctness of the knowledge signature, that is... verify Provided The correctness; if Provided Able to meet Then prove Provided It is a valid signature, thus proving... yes The owner, At this point, confirm the correctness of this authorization verification; right After the request is evaluated, the voting content is generated. This indicates whether the verification passed; then, use your own ECC private key. right Obtain by signing Call after voting callback function Complete this vote; Step 2.7: Receive and record votes according to the authorized verification voting record algorithm: Upon receiving of Next, first query the user permission table. verify The status is available. Time indicates These are normal users who were not disabled; then, using ECC public key verify The correctness; then, according to Revise Information regarding this request; upon receipt If it fails to pass, the corresponding total number of passes will be recorded. Increase by 1 and record the number of confirmed votes cast. serial number When received If it fails, the corresponding total number of failures will be... Increase by 1, and record the number of votes cast that do not pass. serial number ; Step 2.8: Based on the authorization verification result, determine the following algorithm: The voting process ends when the countdown timer expires or all votes are received; otherwise, the voting process ends when the number of approved votes exceeds the total number of users with existing permissions and normal access. of ,and If the user does not have the original permissions in the system, a unique ID will be generated for that user. ,and , Recorded together in the user permission table within the contract and set Status is enabled Then of , Called as a parameter of Set an initial reputation value for it; if The purpose of this request is to modify permissions, so we will directly modify it to... If the number of votes does not exceed of If the request fails, the authorization verification result will be sent. Published to the blockchain; Step 2.9: Change the reputation value according to the reputation score update algorithm in the authorization verification process: In obtaining Next, a set of user IDs whose reputation values ​​have been changed needs to be generated. And generate change type First, and The user IDs that do not meet the criteria and the user IDs that did not vote are combined to form a set that requires the deduction of reputation points. and set Voting error Type; secondly, will and The matching user IDs generate a set that needs to have its reputation score increased. and set For the correct voting type ;at last, Will and As a parameter, call Reputation value change function ; Upon receiving After receiving a notification of a change in the user's reputation score, the system will modify the user's reputation score recorded in the user reputation table F according to the parameters; when the original reputation score... Higher than the user's disable or enable threshold After modification Higher than hour, Will call User state change function ,transfer and set for ;when Below After modification Compare High time, Will call User state change function ,transfer and set for Users who have been disabled cannot participate in authorization verification voting, so no users will be restored to enabled status during this phase.

5. A secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, The specific process for step 3, the data request phase, is as follows: Step 3.1: First, the data needs to be encrypted and preprocessed before uploading. Registration First, a one-time AES key must be generated. and to AES encryption yields ciphertext ;Then, Will Uploaded to IPFS, IPFS splits and stores the data, returning the IPFSHash value. Then, permissions are set for the data uploaded to the chain based on the access permission setting function. In the access permission table It does not exist in and the call address is The address will be , , Add the data to the table; only then can you retrieve the data description information and initiate a data request. Through data sharing contracts Retrieve description information for all data on the chain, and then send a request to one of those data items; at this point, You need to use your own ECC private key For target data Obtain by signing and use and Use it as a parameter to initiate a data request; Step 3.2: Initiate permission verification: When Towards After initiating a data request, Will verify first After verification, Will of and Called as a parameter Access permission verification function in ; Step 3.3: Access Management Contract Permission Verification: Use the access permission verification function to verify access permissions. Upon receiving Call After sending the permission verification request, Called as a parameter Permission query function The function is based on Query Get Permissions and Then, and middle corresponding In comparison, when Greater than In or Includes hour, Pass the authorization check; finally, present the check results. Return to ; In obtaining If the verification result is satisfactory, continue the process; otherwise, terminate the process. Step 3.4: IPFSHash and AES key transfer: Yes and Interaction between and The process, In use ECC public key Encryption obtained After that, it is necessary to... Using ECC private key Obtain by signing and will , and Send together ; Authentication using stored user public keys After confirming that there are no errors, according to Query and notify ; Step 3.5: Update Reputation Score: In receive Transmitted After that, the data request ends; Will generate only of and set for , call of Function implementation; used when updating scores. Perform calculations for Increase reputation points as an incentive; Step 3.6: Download and decrypt the data: use Decryption ,get You can download and decrypt. ,get Requested data .

6. A secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, Step 5, identity authentication and privacy protection, is accomplished through BLS threshold signatures.

7. A secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, Step 5, authorization verification, and privacy protection are accomplished through knowledge signatures of discrete logarithms and voting by all users on the smart contract.

8. A secure remote sensing image data sharing method based on blockchain and IPFS according to claim 1, characterized in that, Privacy protection for data access in step 5 is achieved by layering different encryption algorithms.

Images