Fair verifiable double outsourcing function hidden inner product encryption method for iot data transaction
By employing a fair and verifiable double-outsourced function hidden inner product encryption method for IoT data transactions, the problems of excessive computational burden and unfair settlement in existing solutions are solved. This method enables lightweight operation on resource-constrained devices and publicly verifiable outsourced computation, ensuring traceability and fair settlement of transactions.
Patent Information
- Application Number
- CN202610932443.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-26
- Publication Date
- 2026-07-28
AI Technical Summary
Existing IoT data transaction solutions cannot simultaneously achieve function hiding of evaluation vectors and data vectors, transaction binding of conversion keys, public verifiability of external computations, and fair settlement. This is especially true when resource-constrained IoT devices and data consumers cannot afford the expensive key generation, pairing operations, and decryption calculations, and there is a lack of transaction binding evidence and fair dispute resolution.
The method of double-outsourced function hidden inner product encryption for fair and verifiable IoT data transactions is adopted. By delegating the generation of conversion key and ciphertext conversion to the data provider and cloud server respectively, transaction context binding, public verification and smart contract dispute handling mechanisms are introduced to reduce client computing overhead. Lightweight decryption operation and fair settlement mechanism are designed.
It enables lightweight operation on resource-constrained devices, provides publicly verifiable outsourced computation and fair settlement, ensures traceability of transactions, solves the problems of excessive computational burden and unfair settlement in existing solutions, and provides a transaction solution with privacy protection and verifiable results.
Smart Images

Figure CN122475944A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the fields of IoT data transaction and cryptography technology, specifically relating to a fair and verifiable double-outer-function hidden inner product encryption method for IoT data transactions. Background Technology
[0002] With the widespread deployment of the Internet of Things (IoT) in smart cities, industrial IoT, and intelligent transportation, massive amounts of sensor data have become important assets in the data trading market. In IoT data transactions, data consumers need to evaluate whether the purchased data meets their analytical needs before the transaction, while data providers are unwilling to disclose the raw sensor data in advance. At the same time, the consumer's evaluation vectors, model parameters, or query preferences are also commercially sensitive information and should not be exposed to the provider or third-party servers. This two-way privacy constraint makes the traditional disclosure-before-transaction model unsuitable. Function-hidden inner product encryption technology, in this ciphertext state, simultaneously hides both the data vector and the function vector, disclosing only the inner product result to the authorized party, providing a natural cryptographic basis for this requirement.
[0003] While existing function-hidden inner product encryption schemes achieve basic concealment protection, they still have shortcomings in practical IoT data transactions. First, resource-constrained IoT devices and data consumers may not be able to afford the expensive key generation, pairing, and decryption calculations in high-dimensional scenarios. Although outsourcing can transfer high-overhead operations to data providers, cloud servers, or edge servers, it also introduces issues of result correctness and attribution of responsibility. Second, existing privacy-preserving data transaction schemes typically focus on data delivery, search matching, or fair payment, while offering limited support for cryptographic domain function computation and verification of outsourced results. Existing function-hidden inner product encryption schemes primarily focus on privacy and efficiency, but lack transaction-bound evidence and fair dispute resolution. In practice, cloud servers may return incorrect transformation results, transformation keys or intermediate results may be replayed across transactions, and malicious consumers may refuse payment after obtaining valid results.
[0004] In summary, to address the problem that existing technologies cannot simultaneously support privacy-preserving function computation, lightweight client operation, publicly verifiable outsourcing, transaction binding, and fair settlement, a fair and verifiable double-outsourcing function-hidden inner product encryption method for IoT data transactions is proposed. Summary of the Invention
[0005] The main objective of this invention is to provide a fair and verifiable double-outsourced function-hidden inner product encryption method for IoT data transactions, in order to solve the problems in existing solutions that cannot simultaneously achieve function hiding of evaluation vectors and data vectors, transaction binding of conversion keys, public verifiability of external computation, and fair settlement.
[0006] Based on the first major aspect of the present invention, a fair and verifiable double-outsourced function hidden inner product encryption method for IoT data transactions is provided, which is executed by four types of entities: data provider, data consumer, cloud server, and blockchain platform. The method includes the following steps:
[0007] Obtain security parameters and vector dimensions, execute the initialization algorithm, and generate public parameters, master key, and the initial state of the smart contract;
[0008] The data provider encrypts the IoT data vector into ciphertext with data commitment and the data provider's digital signature based on the master key, while the data consumer generates a private recovery key, a public encoded key and an encryption request based on the transaction context and the private evaluation vector.
[0009] The data provider uses the master key, public encoded key, encryption request, and ciphertext to generate a conversion key bound to the transaction;
[0010] The cloud server performs an outsourced conversion based on the ciphertext and conversion key to generate a master intermediate ciphertext, a correction item, a conversion proof, and a server signature. Then, any entity among the data consumer, the cloud server, or the smart contract executes a verification algorithm to verify the data commitment, the data provider's digital signature, the conversion key label, and the conversion proof.
[0011] The data consumer performs affine offset elimination and multiplicative mask removal based on the private recovery key, master intermediate ciphertext, and correction term to obtain the inner product of the IoT data vector and the private evaluation vector.
[0012] When a smart contract receives a dispute, it runs an appeal algorithm based on the submitted evidence, outputs a ruling, and then releases or penalizes data payments, computing fees, or deposits based on the ruling.
[0013] In the above technical solutions, by delegating the generation of conversion keys and ciphertext conversion to the data provider and the cloud server respectively, the data consumer only needs to perform lightweight request generation and decryption operations, thereby further reducing the computational overhead of the client. At the same time, the introduction of transaction context binding, public verification and smart contract dispute resolution mechanisms lays the overall framework foundation for solving the technical problems of outsourcing results, lack of binding and unfair settlement.
[0014] As a further preferred embodiment, in the aforementioned method, the execution steps of the initialization algorithm are as follows:
[0015] Randomly select an invertible matrix, calculate the inverse of the transpose of the invertible matrix as the dual matrix, and for each row and each column in the vector dimension, calculate the public group code of the dual matrix.
[0016] For each row in the vector dimension, calculate its affine offset correction parameter;
[0017] The public parameters include public group coding and affine offset correction parameters, and the master key includes an invertible matrix and a dual matrix.
[0018] In the initialization phase, linear transformations of invertible and dual matrices provide a mathematical basis for the encryption of IoT data vectors and the hiding of evaluation vectors. Furthermore, the publication of public group coding and correction parameters makes it possible to verify the correctness of the conversion key and eliminate affine offsets in subsequent steps, thus solving the problem of the lack of public verification conditions in existing schemes.
[0019] As a further preferred embodiment, in the aforementioned method, the steps for encrypting the IoT data vector into ciphertext are as follows:
[0020] The data provider multiplies the invertible matrix in the master key with the IoT data vector to obtain the first intermediate vector;
[0021] For each component of each first intermediate vector, calculate the corresponding ciphertext component to obtain the first ciphertext component;
[0022] Based on auxiliary information, the data provider's identity, and the first ciphertext component, the data identifier and data commitment can be calculated using a collision-resistant hash function, as shown in the following formula;
[0023] ;
[0024] ;
[0025] in, Represents a data identifier. Represents a collision-resistant hash function. Indicates the identity of the data provider. Indicates auxiliary information, Indicates the first ciphertext component, Indicates a data commitment;
[0026] The data provider signs the encrypted data description, obtains the data provider's digital signature, and finally outputs the ciphertext. The tuple containing the data identifier, data commitment, auxiliary information and the data provider's digital signature is recorded in the smart contract.
[0027] The encrypted data description includes a data identifier, a data commitment, auxiliary information, and a first ciphertext component;
[0028] The ciphertext includes a first ciphertext component, a data identifier, a data commitment, supplementary information, and a digital signature from the data provider.
[0029] In the encryption process, the original data vector is mapped to the ciphertext space through linear transformation, and a collision-resistant hash function is used to generate a unique data identifier and commitment. Combined with the digital signature of the data provider, the integrity of the ciphertext and the authenticity of its source are ensured, providing verifiable credentials for transaction binding, outsourcing conversion and dispute arbitration in subsequent steps.
[0030] As a further preferred embodiment, in the aforementioned method, the steps for generating the private recovery key, the public encoded key, and the encryption request are as follows:
[0031] The data consumer uniformly and randomly samples the secret mask value and affine offset value, and combines the two to form a private recovery key;
[0032] For each component in the vector dimension, compute the affine mask group code: To form a public coded key, where, This represents affine mask group coding. Denotes the generator of the second cyclic group. Represents the secret mask value, Represents each component of the private evaluation vector. Indicates the affine offset value. Indicates the second cyclic group. Indicates column index;
[0033] The encoded key label is bound to the transaction context, and the data consumer signs the concatenation result of the encoded key label, the transaction context, and the public encoded key to obtain the data consumer's digital signature;
[0034] The encoded key tag is obtained by performing a collision-resistant hash function operation on the concatenation result of the transaction context and the public encoded key;
[0035] The encryption request includes a public encoding key, an encoding key label, and a digital signature from the data consumer.
[0036] This technical solution introduces a secret mask value and an affine offset value to hide the private evaluation vector within the public encoded key. Simultaneously, the affine offset ensures that all components of the public encoded key are non-unit group elements, thus preventing data providers from inferring zero-to-zero entries in the evaluation vector based on unit positions. Tags and signatures are bound to the public transaction context, resolving the issues of evaluation vector privacy leakage and request replay across transactions.
[0037] As a further preferred embodiment, in the aforementioned method, the steps for generating the transaction-bound conversion key are as follows:
[0038] After the data provider verifies the digital signature and transaction context of the data consumer, it parses the public encoded key and uses the dual matrix to calculate the transformation key component for each row in the vector dimension, thus forming the transformation key body.
[0039] A collision-resistant hash function is used to generate a transformation key tag based on the transformation key body, transaction context, data commitment, and public encoded key. The concatenation result of the transaction context, data commitment, public encoded key, transformation key body, and transformation key tag is then signed to obtain a transformation key digital signature. The output is a transformation key containing the transformation key body, public encoded key, transformation key tag, and transformation key digital signature.
[0040] When generating the transformation key, a linear combination of the dual matrix and the publicly encoded key is used to obtain a transformation key that is bound to a specific transaction context, data commitment, and data consumer request. This key can only be used for this transaction and the corresponding signature, and even if it is maliciously obtained, it cannot be reused in other transactions. At the same time, the existence of the public verification equation allows any third party to verify the correctness of the transformation key.
[0041] As a further preferred embodiment, in the aforementioned method, the execution steps for generating the master intermediate ciphertext, correction item, conversion proof, and server signature are as follows:
[0042] The cloud server parses the first ciphertext component and the conversion key, and uses a non-degenerate bilinear mapping to perform pairing operations and product on each row to generate the main intermediate ciphertext.
[0043] Using the affine offset correction parameters in the public parameters, perform pairing operations and multiplication on each row to generate a correction term to eliminate affine offset;
[0044] The cloud server calls the collision-resistant hash function to perform hash operations on the transaction context, ciphertext, conversion key, master intermediate ciphertext, and correction item to generate a conversion proof.
[0045] The cloud server signs the concatenation result of the master intermediate ciphertext, the first ciphertext component, the transaction context, the transformation proof, the correction item, and the transformation key tag to generate a server signature;
[0046] The final cloud server output includes the main intermediate ciphertext, correction items, conversion proof, and server signature.
[0047] In the above technical solution, the high-overhead bilinear pairing operation is completely outsourced to the cloud server, so that the data consumer does not need to perform any pairing operation. The generated correction term is used to eliminate affine offset during decryption. The transformation proof and server signature make the outsourced result publicly verifiable, ensuring the accountability of the outsourced computation.
[0048] As a further preferred embodiment, in the aforementioned method, the steps for obtaining the inner product value of the IoT data vector and the private evaluation vector are as follows:
[0049] The data consumer parses the private recovery key and performs the first step of eliminating affine offsets:
[0050] ;
[0051] in, This represents an intermediate result from the first stage. This indicates the ciphertext in the middle of the main text. Indicates the correction term. Indicates the affine offset value. Indicates the target cyclic group;
[0052] Next, perform the second step to remove the multiplicative mask:
[0053] ;
[0054] in, This indicates the intermediate decryption result of the second stage. This represents an intermediate result from the first stage. Represents the secret mask value, Denotes the generators of the target cyclic group. Represents a private evaluation vector. Represents IoT data vectors, Indicates the target cyclic group;
[0055] Finally, a bounded discrete logarithmic search is performed within the pre-defined finite interval of the inner product value to find a unique value such that... This unique value is the inner product of the IoT data vector and the private evaluation vector.
[0056] in, Denotes the generators of the target cyclic group. This indicates the intermediate decryption result of the second stage. This represents the inner product value.
[0057] In this invention, the data consumer only needs to perform two target group exponent operations and one discrete logarithm search, without involving any bilinear pairing operations, resulting in extremely low computational overhead. By uniquely determining the inner product value within a preset interval through bounded discrete logarithm search, the high-cost discrete logarithm solution is avoided, solving the problem that resource-constrained IoT devices cannot efficiently complete decryption, and achieving lightweight client-side processing.
[0058] As a further preferred embodiment, in the aforementioned method, the release and penalty of data payments, calculation fees, or deposits based on the adjudication result specifically includes:
[0059] When the transaction is deemed valid, the smart contract releases the data payment to the data provider and the computing fees to the cloud server.
[0060] When the ruling finds the data provider at fault, the smart contract refunds the data consumer and penalizes the data provider by locking up the deposit.
[0061] When the ruling indicates that the server is at fault, the smart contract refunds the data consumer and enforces penalties by withholding service fees or deposits from the cloud server smart contract.
[0062] In the final ruling, the smart contract automatically executes differentiated settlement logic to achieve precise accountability for three types of failures: invalid number submission, erroneous outsourced calculation, and malicious refusal to pay. This not only protects the interests of honest participants but also imposes economic penalties on malicious behavior, solving the technical problems of existing IoT transaction solutions that lack a fair settlement mechanism and rely on third-party arbitration for dispute resolution, which is inefficient.
[0063] Based on a second key aspect of the present invention, a fair and verifiable double-outsourced function-hidden inner product encryption system for implementing the method described above for Internet of Things data transactions is provided, comprising:
[0064] The initialization module is used to obtain security parameters and vector dimensions to execute the initialization algorithm, and generate public parameters, master key and the initial state of smart contract;
[0065] The data encryption module, deployed at the data provider, is used to encrypt IoT data vectors using public parameters and a master key.
[0066] The request generation module, deployed on the data consumer side, is used to generate a private recovery key, a public encoded key, and an encrypted request based on public parameters, transaction context, and a private evaluation vector.
[0067] The conversion key generation module, deployed at the data provider, is used to generate a transaction-bound conversion key based on the master key, public encoded key, encryption request, and ciphertext.
[0068] The ciphertext conversion module, deployed on a cloud server, takes encrypted IoT data and conversion keys as input and outputs the main intermediate ciphertext, correction items, conversion proof, and server signature.
[0069] The verification module, deployed on the data consumer, cloud server, or smart contract, is used to verify the correctness of the conversion key and outsourced data.
[0070] The decryption module, deployed on the data consumer side, is used to decrypt intermediate ciphertext using a private recovery key to obtain the inner product result.
[0071] The settlement module, deployed in smart contracts, is used to execute payment settlements and dispute resolution based on the ruling results.
[0072] Based on a third key aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed, implements the aforementioned method for fair and verifiable double-outer-package function-hidden inner product encryption of Internet of Things (IoT) data transactions.
[0073] Compared with existing technologies, this invention provides a fair and verifiable double-outsourced function-hidden inner product encryption method for IoT data transactions. First, by delegating the transformation key generation to the data provider and the ciphertext transformation to the cloud server in a double-outsourced architecture, combined with a transaction-bound transformation key mechanism, the computational overhead for data consumers is reduced. Consumers only need to perform a lightweight request generation operation and a target group exponentiation operation to complete decryption, without participating in the high-overhead bilinear pairing operation. This design overcomes the limitation of excessive client-side computational burden in existing function-hidden inner product encryption schemes, solves the technical problem that resource-constrained IoT devices cannot participate in high-dimensional data transactions, and enables data consumers to efficiently complete privacy-preserving utility evaluations on low-power terminals.
[0074] Secondly, this invention constructs a publicly verifiable outsourced computation system and transaction binding mechanism. Any third party can verify the correctness of the conversion key and the accuracy of the cloud server outsourced conversion through verification and other methods, preventing key reuse, result replay, and cross-transaction abuse. Based on this, this invention designs a dispute resolution and settlement mechanism based on smart contracts, capable of distinguishing between three fault types: invalid provider evidence, erroneous outsourced computation, and malicious payment refusal, and executing corresponding fund release or penalty operations accordingly. This invention achieves a unified approach to verifiable outsourced results, traceable transaction behavior, and fair settlement processes among mutually distrustful participants.
[0075] Finally, while ensuring the privacy of encrypted information through hidden inner products, this invention achieves a balance between lightweight client-side implementation, verifiable outsourcing results, traceable transaction behavior, and fair settlement process. Attached Figure Description
[0076] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, obtaining other drawings based on these drawings without creative effort still falls within the scope of the present invention.
[0077] Figure 1The following is a flowchart illustrating the execution of a fair and verifiable double-outsourced function hidden inner product encryption method for IoT data transactions, according to an embodiment of the present invention.
[0078] Figure 2 The diagram illustrates a system framework of a fair and verifiable double-outsourced function hidden inner product encryption method for IoT data transactions, according to one embodiment of the present invention. Detailed Implementation
[0079] The preferred embodiments of the present invention will be described in detail below to provide a clearer understanding of the purpose, features, and advantages of the invention. It should be understood that the following embodiments are not intended to limit the scope of the invention, but are merely illustrative of the essential spirit of the technical solution of the invention.
[0080] In the following description, certain specific details are set forth for the purpose of illustrating various disclosed embodiments in order to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the art will recognize that embodiments may be practiced without one or more of these specific details. In other instances, well-known techniques associated with the invention may not have been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.
[0081] Throughout this specification, references to "an embodiment" or "an embodiment" indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, the appearance of "in an embodiment" or "an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, or characteristic may be combined in any manner in one or more embodiments.
[0082] The following is a description of the specific meanings of technical terms, English abbreviations, and formula parameters that may be used in this invention:
[0083] Smart contract: A code-defined, automatically executed protocol deployed on a blockchain.
[0084] : Functions used by smart contracts to submit encrypted metadata generated by data providers.
[0085] : A function in a smart contract used to submit the conversion key tag.
[0086] : A function in a smart contract used to submit the results of outsourced transformations performed by the cloud server.
[0087] Gas cost: In blockchain platforms such as Ethereum, it is a unit of measurement for the computing resources consumed to execute each instruction or operation in a smart contract.
[0088] In one feasible embodiment, combined with Figure 1 As shown, this invention provides a fair and verifiable double-outsourced function hidden inner product encryption method for IoT data transactions, executed by four types of entities: data provider, data consumer, cloud server, and blockchain platform. The method includes the following steps S100~S600:
[0089] S100: Obtain security parameters and vector dimensions, execute the initialization algorithm, and generate public parameters, master key, and the initial state of the smart contract;
[0090] S200, the data provider encrypts the IoT data vector into ciphertext with data commitment and the data provider's digital signature based on the master key, while the data consumer generates a private recovery key, a public encoded key and an encryption request based on the transaction context and the private evaluation vector.
[0091] S300: The data provider uses the master key, public encoded key, encryption request, and ciphertext to generate a transaction-bound conversion key;
[0092] S400, the cloud server performs outsourced conversion based on the ciphertext and conversion key to generate master intermediate ciphertext, correction item, conversion proof and server signature; then the data consumer, cloud server or smart contract entity executes verification algorithm to verify the data commitment, data provider digital signature, conversion key label and conversion proof.
[0093] S500, the data consumer performs affine offset elimination and multiplicative mask removal based on the private recovery key, master intermediate ciphertext and correction term to obtain the inner product of the IoT data vector and the private evaluation vector;
[0094] When a dispute is received, the S600 smart contract runs an appeal algorithm based on the submitted evidence, outputs a ruling, and releases or penalizes data payments, computing fees, or deposits based on the ruling.
[0095] To implement the above methods, this invention provides a model framework for a fair and verifiable double-outsourced function hidden inner product encryption scheme (FVDO-FHIPE) for IoT data transactions, as follows: Figure 2 As shown.
[0096] It consists of four types of entities: data provider (DP), data consumer (DC), cloud server (S), and blockchain platform.
[0097] Data providers hold IoT data vectors This is encrypted into a function-hidden ciphertext, and a transaction-bound conversion key is provided to the authorized data consumer. Represents IoT data vectors, This represents the first component in the IoT data vector. This represents the last component in the IoT data vector. An integer vector space representing the modulus of a vector dimension. Represents the vector dimension. Represents a prime number.
[0098] Data consumers hold private evaluation vectors Its goal is to obtain only the inner product without disclosing the private evaluation vector to the data provider or server. .in, Represents a private evaluation vector. This represents the first component of the private evaluation vector. This represents the last component of the private evaluation vector. An integer vector space representing the modulus of a vector dimension. Represents the vector dimension. Representing prime numbers, This represents an IoT data vector.
[0099] The cloud server stores encrypted IoT data and performs outsourced conversion. Given the ciphertext and conversion key, the cloud server generates intermediate ciphertext and proof of correct conversion.
[0100] Blockchain maintains smart contracts used for order generation, evidence recording, public verification, and payment settlement.
[0101] This invention provides a fair and verifiable double-outer-function hidden inner product encryption method for IoT data transactions, defined by the following nine probabilistic polynomial-time algorithms:
[0102] ;
[0103] in, This indicates a fair and verifiable double-outsourcing function hidden inner product encryption method for IoT data transactions. Indicates the initialization algorithm. Indicates the data encryption algorithm. Indicates the request generation algorithm. This indicates the conversion key generation algorithm. Indicates the outsourcing conversion algorithm. This indicates that the verification algorithm is publicly available. Indicates the decryption algorithm. Indicates the appeal algorithm, This indicates the settlement algorithm.
[0104] Specifically, examples of each algorithm are as follows:
[0105] ;in, Indicates the initialization algorithm. Indicates safety parameters, Indicates safety strength. Indicates public parameters, Indicates the master key. This indicates the initial state of the smart contract.
[0106] The initialization algorithm takes security parameters and vector dimensions as input. It outputs public parameters. The master key held by the data provider and the initial state of the smart contract. .
[0107] ;in, Indicates the data encryption algorithm. Indicates public parameters, Indicates the master key. Represents IoT data vectors, Indicates auxiliary information, This indicates encrypted text.
[0108] Data providers disclose parameters and master key Encrypted IoT data vectors Auxiliary information Describe the data being traded, such as data type, collection time, and usage strategy. The algorithm outputs ciphertext. .
[0109] ;in, Indicates the request generation algorithm. Indicates public parameters, Indicates the transaction context. Represents a private evaluation vector. This indicates a private recovery key. This indicates the public key. This indicates an encrypted request.
[0110] Given public parameters Transaction context and private evaluation vector The data consumer generates a private recovery key. Publicly encoded key and encryption request Affine offset Ensure public coding key All components are non-unit group elements, thus preventing data providers from relying solely on the public coding key. Inferring private evaluation vectors The zero-value entries in the table.
[0111] ;in, This indicates the conversion key generation algorithm. Indicates public parameters, Indicates the master key. Indicates the transaction context. This indicates the public key. Indicates an encrypted request. Indicates ciphertext, This represents the conversion key.
[0112] The data provider uses the master key Publicly encoded key Encryption request and ciphertext Generate the conversion key bound to the transaction. .
[0113] ;in, Indicates the outsourcing conversion algorithm. Indicates public parameters, Indicates the transaction context. Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the server signature.
[0114] Cloud servers use encrypted IoT data and conversion key This is the input. It outputs the master intermediate ciphertext of the code mask inner product. Correction terms used to eliminate affine migration Correct conversion proof and server signature .
[0115] ;in, This indicates that the verification algorithm is publicly available. Indicates public parameters, Indicates the transaction context. Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the verification result.
[0116] The verification algorithm can be run by the data consumer, a cloud server, or a smart contract. It checks whether the master intermediate ciphertext was correctly generated from IoT data and the conversion key within the transaction context. The algorithm verifies the data commitment, signature, conversion key label, and conversion proof. If all checks pass, the algorithm outputs... Otherwise, output .
[0117] ;in, Indicates the decryption algorithm; Indicates public parameters, Indicates the transaction context. This indicates a private recovery key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This indicates the inner product value, meaning decryption was successful. This indicates that decryption failed.
[0118] The data consumer runs the final decryption algorithm. Using the private recovery key, it first eliminates the affine offset using a correction term, then removes the secret mask, and obtains the inner product. ,in Represents a private evaluation vector. Represents IoT data vectors, This represents the inner product value.
[0119] ;in, Indicates the appeal algorithm, Indicates public parameters, This indicates the initial state of the smart contract. Indicates the transaction context. To present evidence, This indicates the ruling result.
[0120] In the event of a dispute, the smart contract submits evidence. Run the appeal algorithm:
[0121] ;in, Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the server signature.
[0122] The algorithm first calls Check the correctness of the outsourced conversion. If the verification is successful, output the following: This indicates that the cloud server has successfully performed the conversion. If the data commitment, provider signature, or conversion key binding is invalid, the output will be... If the evidence provided by the party providing the evidence is valid but the transformation proof fails, then output... .
[0123] ;in, Indicates the settlement algorithm, Indicates public parameters, This indicates the initial state of the smart contract. Indicates the transaction context. Indicates the ruling result. This indicates the updated state of the smart contract.
[0124] The settlement algorithm is executed by the smart contract based on the ruling returned by the appeal algorithm. If The contract releases the data payment to the data provider and the computing fee to the cloud server.
[0125] like Data consumers receive refunds, while data providers are penalized.
[0126] like The data consumer receives a refund, and the cloud server loses its service fees or deposit. The updated smart contract state is recorded as follows: .
[0127] In one feasible embodiment, the method and the algorithm provided by the present invention will be described in detail below:
[0128] 1. ;in, Indicates the initialization algorithm. Indicates safety parameters, Indicates safety strength. Indicates public parameters, Indicates the master key. This indicates the initial state of the smart contract.
[0129] Initialization algorithm selects bilinear group parameters .in, Indicates the bilinear group parameters; Represents prime numbers; Let them represent the first cyclic group, the second cyclic group, and the target cyclic group, respectively; Represents a non-degenerate bilinear mapping; This represents the generator of the first cyclic group; This represents the generator of the second cyclic group; This represents the generator of the target cyclic group.
[0130] It randomly samples invertible matrices And calculate its dual matrix. .in Represents an invertible matrix; In this formula, we denote the general linear group. Indicates the order; Represents a finite field; Represents prime numbers; Represents the dual matrix; This represents the transpose of an invertible matrix, in this formula. This represents the transpose symbol.
[0131] Then, for each ,in Indicates row index; Indicates column index; Represent the vector dimension. Calculate the public group encoding of the dual matrix:
[0132] ;
[0133] in, Indicates a public group code; Indicates row index; Indicates column index; This represents the generator of the first cyclic group; Denotes the first digit of the dual matrix. Line number Column elements; This indicates the first cyclic group.
[0134] In addition, for each affine mask, release:
[0135] ;
[0136] in, Indicates the affine offset correction parameters; This represents the generator of the second cyclic group; Denotes the first digit of the dual matrix. Line number Column elements; Describe the dual matrix. Indicates row index; Indicates column index; Indicates the vector dimension; This indicates the second cyclic group.
[0137] The public parameters and master key are defined as follows:
[0138] ;
[0139] ;
[0140] in, Indicates publicly available parameters; Indicates the bilinear group parameters; Indicates the vector dimension; Indicates a finite interval of inner product values; Indicates a public group code; Indicates the affine offset correction parameters; Represents a collision-resistant hash function; Indicates row index; Indicates column index; Indicates the vector dimension; Indicates a digital signature scheme; Indicates the master key; Represents an invertible matrix; This represents the dual matrix.
[0141] Smart contracts initialize their state by recording the verification keys and contract addresses of the registered participants. .
[0142] 2. ;in, Indicates the data encryption algorithm. Indicates public parameters, Indicates the master key. Represents IoT data vectors, Indicates auxiliary information, This indicates encrypted text.
[0143] Data provider DP holds IoT data vectors .in, Represents IoT data vectors; This represents the first component in an IoT data vector; This represents the last component in an IoT data vector; An integer vector space representing the modulus of a vector dimension; Indicates the vector dimension; Represents prime numbers; in this formula This represents the transpose symbol.
[0144] It calculates:
[0145] ;in Represents the first intermediate vector; Represents IoT data vectors; Represents an invertible matrix; This represents the first component in the first intermediate vector; This represents the last component in the first intermediate vector; An integer vector space representing the modulus of a vector dimension; Indicates the vector dimension; Represents prime numbers; in this formula This represents the transpose symbol.
[0146] And generate ciphertext components:
[0147] ;in Indicates the ciphertext component; The first intermediate vector represents the first intermediate vector. One component; This represents the generator of the first cyclic group; Indicates the vector dimension; Indicates row index; Represents the vector dimension.
[0148] make .in, Indicates the first ciphertext component; The first component representing the ciphertext component; Represents the last component of the ciphertext; Represents the vector dimension.
[0149] Data identifiers and data commitments are calculated as follows:
[0150] ;
[0151] ;
[0152] in, Represents a data identifier; Represents a collision-resistant hash function; Indicates the identity of the data provider; Indicates auxiliary information; Indicates the first ciphertext component; DP indicates a data commitment; DP indicates a data provider.
[0153] The data provider signs the description of the encrypted data:
[0154] ;
[0155] in, This indicates the digital signature of the data provider; This indicates that the data provider signs the document; Represents a data identifier; Indicates a data commitment; The first ciphertext component is represented by DP; DP represents the data provider. This represents an IoT data vector.
[0156] Output ciphertext:
[0157] ;
[0158] in, Indicates ciphertext; Indicates the first ciphertext component; Represents a data identifier; Indicates a data commitment; Indicates auxiliary information; This indicates the digital signature of the data provider; DP represents the IoT data vector; DP represents the data provider.
[0159] tuple Recorded in a smart contract; among which, Represents a data identifier; Indicates a data commitment; Indicates auxiliary information; This indicates the digital signature of the data provider; DP represents the IoT data vector; DP represents the data provider.
[0160] 3. ; Indicates the request generation algorithm. Indicates public parameters, Indicates the transaction context. Represents a private evaluation vector. This indicates a private recovery key. This indicates the public key. This indicates an encrypted request.
[0161] Data consumer (DC) holds private evaluation vectors It uses uniform random sampling. ,in, Represents a private evaluation vector; This represents the first component of the private evaluation vector; This represents the last component of the private evaluation vector; An integer vector space representing the modulus of a vector dimension; Represents the secret mask value; Indicates the affine offset value; Represents the non-zero integer multiplication group modulo primes; Represents the vector dimension. Represents a prime number.
[0162] And set: ;in, Indicates the private recovery key; Represents the secret mask value; This represents the affine offset value.
[0163] For each ,in, Indicates column index; Represent the vector dimension; calculate the affine mask group code:
[0164] ;
[0165] in, This indicates an affine mask group encoding; This represents the generator of the second cyclic group; Represents the secret mask value; Indicates the affine offset value; Represent each component of the private evaluation vector; Indicates the second cyclic group; Indicates column index.
[0166] definition .in, This indicates that the key is publicly coded; This represents the first component of the public-coded key; This represents the last component of the public-coded key; Represents the vector dimension.
[0167] Request approved Bind to the transaction context, and have the consumer sign the request:
[0168] ;
[0169] in, Represents the encoded key tag; This indicates that the data consumer must sign the document. Indicates the transaction context; Represents a collision-resistant hash function; This indicates that the key is publicly coded; This represents the digital signature of the data consumer; DC represents the data consumer.
[0170] Encryption request is .in, Indicates an encrypted request; This indicates that the key is publicly coded; Represents the encoded key tag; This represents the digital signature of the data consumer; DC represents the data consumer.
[0171] 4. ;in, This indicates the conversion key generation algorithm. Indicates public parameters, Indicates the master key. Indicates the transaction context. This indicates the public key. Indicates an encrypted request. Indicates ciphertext, This represents the conversion key.
[0172] In examining the digital signatures of data consumers and transaction context Afterwards, the data provider analyzes... ; This indicates that the key is publicly coded; This represents the first component of the public-coded key; This represents the last component of the public-coded key; Represents the vector dimension.
[0173] Using dual matrix It applies to each calculate:
[0174] ;
[0175] in, Indicates the conversion of key components; Indicates the vector dimension; Indicates column index; Indicates row index; This indicates an affine mask group encoding; Represents the dual matrix; This represents the generator of the second cyclic group; Represents the secret mask value; Indicates the affine offset value; Represent each component of the private evaluation vector; Indicates the second cyclic group; Denotes the first digit of the dual matrix. Line number The elements of the column.
[0176] make ;in, Indicates the key body for conversion; This represents the first component of the conversion key; This represents the last component of the conversion key; Represents the vector dimension.
[0177] The conversion key tag is calculated as follows:
[0178] ;
[0179] in, Indicates the conversion key tag; Represents a collision-resistant hash function; Indicates the transaction context; Represents a collision-resistant hash function; This indicates that the key is publicly coded; Indicates a data commitment; This indicates the body of the conversion key.
[0180] The provider signs the conversion key:
[0181] ;
[0182] The output is:
[0183] ;
[0184] in, This indicates the conversion key digital signature; This indicates that the data provider signs the document; Indicates the transaction context; This indicates that the key is publicly coded; Indicates a data commitment; Indicates the key body for conversion; Indicates the conversion key tag; This represents the conversion key.
[0185] Without revealing the dual matrix, the correctness of the transformation key can be verified by checking each... Verify publicly by checking the following formula:
[0186] ;
[0187] In fact,
[0188] ;
[0189] in, Represents the dual matrix; Represents a non-degenerate bilinear mapping; Indicates a public group code; This indicates an affine mask group encoding; This represents the generator of the first cyclic group; Indicates the conversion of key components; Denotes the first digit of the dual matrix. Line number Column elements; Represent each component of the private evaluation vector; Represents the secret mask value; Indicates the affine offset value; This represents the generator of the second cyclic group; Represents the generator of the target cyclic group; Indicates row index; Indicates column index; Represents the vector dimension.
[0190] 5. ;in, Indicates the outsourcing conversion algorithm. Indicates public parameters, Indicates the transaction context. Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the server signature.
[0191] Cloud server analysis:
[0192] ;
[0193] in, Indicates the first ciphertext component; The first component representing the ciphertext component; Represents the last component of the ciphertext; Indicates the key body for conversion; This represents the first component of the conversion key; This represents the last component of the conversion key; Represents the vector dimension.
[0194] It first checks the ciphertext. and conversion key The validity of the check. If any check fails, output the following: .
[0195] in, Indicates ciphertext; Indicates the conversion key; This indicates that decryption failed.
[0196] Otherwise, it calculates the master intermediate ciphertext:
[0197] ;
[0198] In addition, a correction term for affine offset is calculated:
[0199] ;
[0200] ;
[0201] In the above three formulas, Representation and operations; This indicates the ciphertext in the middle of the main text; Indicates the correction term; Indicates the conversion of key components; Indicates the ciphertext component; Indicates the affine offset correction parameters; Represents a non-degenerate bilinear mapping; This represents the generator of the first cyclic group; This represents the generator of the second cyclic group; Represents the generator of the target cyclic group; Represents the dual matrix; Represents an invertible matrix; Represents the secret mask value; This represents the affine offset value; in this formula Indicates the transpose symbol; Indicates the vector dimension; Indicates column index; Indicates row index; Represents a private evaluation vector; Represents IoT data vectors; Indicates the target cyclic group; This represents the components of an IoT data vector.
[0202] The transformation proof is defined as:
[0203] ;
[0204] in, This represents a transformation proof; Represents a collision-resistant hash function; Indicates the transaction context; Indicates the first ciphertext component; Indicates the key body for conversion; This indicates the ciphertext in the middle of the main text; This indicates a correction term.
[0205] The server signs the conversion result:
[0206] ;
[0207] in, Indicates the server signature; This indicates that the cloud server is signing the document; Indicates the transaction context; This indicates the ciphertext in the middle of the main text; Indicates the correction term; This represents a transformation proof; This indicates the conversion key tag.
[0208] Algorithm output:
[0209] ;
[0210] in, This indicates the ciphertext in the middle of the main text; Indicates the correction term; This represents a transformation proof; This indicates the server signature.
[0211] 6. ;in, This indicates that the verification algorithm is publicly available. Indicates public parameters, Indicates the transaction context. Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the verification result.
[0212] The verification algorithm is publicly executable. It parses:
[0213] ;
[0214] in, Indicates ciphertext; Indicates the first ciphertext component; Represents a data identifier; Indicates a data commitment; Indicates auxiliary information; This indicates the digital signature of the data provider; This indicates the conversion key digital signature; This indicates that the data provider signs the document; Indicates the transaction context; This indicates that the key is publicly coded; Indicates the key body for conversion; Indicates the conversion key tag; This represents the conversion key.
[0215] It performs the following checks:
[0216] Data commitment check:
[0217] ;
[0218] in, Represents a data identifier. Represents a collision-resistant hash function. Indicates the identity of the data provider. Indicates auxiliary information, Indicates the first ciphertext component, Indicates a data commitment;
[0219] Provider signature check:
[0220] ;
[0221] in, This indicates a publicly disclosed verification algorithm for the signature; This indicates the digital signature of the data provider; This indicates that the data provider signs the document; Represents a data identifier; Indicates a data commitment; This represents the first ciphertext component.
[0222] Conversion key binding check:
[0223] ;
[0224] in, Indicates the conversion key tag; Represents a collision-resistant hash function; Indicates the transaction context; Represents a collision-resistant hash function; This indicates that the key is publicly coded; Indicates a data commitment; This indicates the body of the conversion key.
[0225] Key signature verification:
[0226] ;
[0227] in, This indicates a publicly disclosed verification algorithm for the signature; Indicates the conversion key tag; Indicates the transaction context; This indicates that the key is publicly coded; Indicates a data commitment; Indicates the key body for conversion; This indicates the conversion key for digital signature.
[0228] Conversion key correctness check:
[0229] ;
[0230] in, Represents a non-degenerate bilinear mapping; Indicates a public group code; This indicates an affine mask group encoding; This represents the generator of the first cyclic group; Indicates the conversion of key components; Indicates the vector dimension; Indicates column index; Indicates the row index.
[0231] Outsourcing conversion check:
[0232] ;
[0233] in, This indicates the ciphertext in the middle of the main text; Indicates the correction term; Indicates the conversion of key components; Indicates the ciphertext component; Indicates the affine offset correction parameters; Represents a non-degenerate bilinear mapping; Indicates the vector dimension; Indicates column index; Indicates row index;
[0234] Conversion proof check:
[0235] ;
[0236] in, This represents a transformation proof; Represents a collision-resistant hash function; Indicates the transaction context; Indicates the first ciphertext component; Indicates the key body for conversion; This indicates the ciphertext in the middle of the main text; This indicates a correction term.
[0237] For the conversion key correctness check, because and The left end can be unfolded into ;in, Indicates a public group code; This represents the generator of the first cyclic group; Denotes the first digit of the dual matrix. Line number Column elements; This indicates an affine mask group encoding; This represents the generator of the second cyclic group; Represents the secret mask value; Indicates the affine offset value; Represent each component of the private evaluation vector; Indicates the second cyclic group; Indicates column index; Represents the dual matrix; Indicates the vector dimension; This represents the generator of the target cyclic group.
[0238] According to the conversion key components The definition is equal to ;in, Indicates the conversion of key components; This represents the generator of the first cyclic group; This represents a non-degenerate bilinear mapping.
[0239] If all checks are true, the algorithm outputs... Otherwise, output ;in, This indicates the verification result.
[0240] 7.
[0241] Data consumer analysis And perform the following two-step demasking process, where, Indicates the private recovery key; Represents the secret mask value; This represents the affine offset value.
[0242] Step 1: Eliminate affine offset.
[0243] ;
[0244] in, This represents an intermediate result from the first stage. This indicates the ciphertext in the middle of the main text. Indicates the correction term. Indicates the affine offset value. Indicates the target cyclic group; Indicates the affine offset value;
[0245] Substituting into the aforementioned definition, we get:
[0246] ;
[0247] in, This indicates an intermediate result from the first stage; Represents the generator of the target cyclic group; Represents a private evaluation vector; Represents IoT data vectors; Representation and operations; Represents the secret mask value; This represents the affine offset value.
[0248] Step 2: Remove the multiplicative mask.
[0249]
[0250] in, yes exist Multiplicative inverse in the equation; This indicates the intermediate decryption result of the second stage; This indicates an intermediate result from the first stage; Represents the secret mask value; Denotes the generators of the target cyclic group. Represents a private evaluation vector; Represents IoT data vectors; Indicates the target cyclic group; Represents prime numbers; It represents a finite field.
[0251] Step 3: Bounded discrete logarithm search.
[0252] Subsequently, the data consumer searches for a unique value. , so that:
[0253] ;
[0254] If such a unique inner product value exists The algorithm outputs the inner product value. Otherwise, output .
[0255] in, Represents the generator of the target cyclic group; This indicates the intermediate decryption result of the second stage; Represents the inner product value; Represents a private evaluation vector; Represents IoT data vectors; Indicates a finite interval of inner product values; This indicates that decryption failed. It represents the upper bound of the absolute value of the inner product.
[0256] 8. ;in, Indicates the appeal algorithm, Indicates public parameters, This indicates the initial state of the smart contract. Indicates the transaction context. To present evidence, This indicates the ruling result.
[0257] In the event of a dispute, the smart contract receives evidence:
[0258] ;in, Indicates ciphertext, Indicates the conversion key. This indicates the ciphertext in the middle of the main text. Indicates the correction term. This represents a transformation proof. This indicates the server signature.
[0259] The smart contract first checks the provider's evidence. If the data commitment, provider signature, transformation key signature, transformation key label, or transformation key validity equation fails, then output... .in, Indicates the ruling result; This indicates that the provider is at fault.
[0260] If the evidence provided by the party providing the evidence is valid, but any of the following conditions are met:
[0261] ;
[0262] in, This indicates the ciphertext in the middle of the main text. Indicates the correction term; Indicates the conversion of key components; Indicates the ciphertext component; Represents a non-degenerate bilinear mapping; Indicates the server signature; Indicates the vector dimension; Indicates row index; This indicates that the verification failed.
[0263] Then the contract output ;in, Indicates the ruling result; This indicates a server error.
[0264] If all checks pass, the contract outputs. ;in, Indicates the ruling result; This indicates that the transaction is valid.
[0265] In this situation, any refusal made by the data consumer is considered a false claim.
[0266] 9. ;in, Indicates the settlement algorithm, Indicates public parameters, This indicates the initial state of the smart contract. Indicates the transaction context. Indicates the ruling result. This indicates the updated state of the smart contract.
[0267] The smart contract settles the transaction based on the ruling. If Smart contracts release data payments to data providers and computing costs to cloud servers.
[0268] like The smart contract refunds the data consumer and penalizes the data provider based on the locked deposit.
[0269] like The smart contract refunds the data consumer and penalizes the cloud server by withholding service fees or deposits.
[0270] in, Indicates the ruling result; This indicates a server error; This indicates that the transaction is valid; This indicates that the transaction is valid;
[0271] The updated smart contract state is recorded as follows .
[0272] Smart contracts contain six main functions, which are used for transaction creation, data commitment submission, key binding conversion, outsourcing result submission, dispute resolution, and final settlement.
[0273] Experimental analysis of the method provided by the present invention is performed in one of the following feasible embodiments:
[0274] First, the computational and communication costs of the proposed scheme are analyzed from a theoretical perspective.
[0275] Table 1: Symbols used in theoretical analysis
[0276] The method provided by this invention is compared with existing technologies 1 (supporting outsourced inner product calculation on encrypted databases), 2, and 3 (supporting delegated inner product decryption) in terms of computational cost, client computational cost, and communication cost.
[0277] As shown in Tables 1, 2, 3, and 4, in terms of computational cost and client-side computational cost, by assigning the high-overhead conversion key generation and ciphertext conversion to the data provider and cloud server respectively, the data consumer only needs to perform the request generation algorithm and the lightweight final decryption algorithm operation, where the latter only needs to perform an exponentiation operation once in the cyclic group and does not involve any pairing operation.
[0278] In terms of communication costs, ciphertext, hidden requests, and transaction binding conversion key size are the main communication overheads, and the main communication overheads are linearly related to the improvement dimension, which is on the same order of magnitude as existing solutions, but additionally achieves transaction binding, public verifiability and fair dispute resolution capabilities.
[0279] Table 2: Comparison of Client Computing Costs
[0280]
[0281] Table 3: Comparison of computational costs of basic algorithms
[0282]
[0283] Table 4: Communication Costs
[0284]
[0285] In this embodiment, the invention was also experimentally evaluated, and the specific results are as follows:
[0286] The experimental evaluation demonstrates the effectiveness of the invention from three dimensions: off-chain computing cost, on-chain computing cost, and resource-constrained IoT devices.
[0287] Regarding off-chain computation costs, the initialization, encryption, and request generation costs of this invention are all lower than those of the comparative schemes. Among them, the request generation cost is the lowest because the consumer only needs to generate a mask to hide the request. Although the conversion key generation and outsourced conversion costs are higher than some of the comparative schemes, these two operations are handled by the data provider and the cloud server, respectively. The consumer only performs lightweight decryption. Overall, the client computational overhead is lower than that of the comparative schemes in all test dimensions. The verification cost is low and stable, indicating that the public verification mechanism is efficient.
[0288] Regarding on-chain computation costs, the differences are analyzed by comparing the gas costs of various smart contract functions, the gas costs in the normal transaction process, the gas costs of the appeal contract under different dispute situations, and the appeal verification costs under different vector dimensions.
[0289] Specifically, the appeal algorithm generates the highest gas cost among all contract functions because it needs to verify the submitted evidence and determine whether the failure originated from the data provider, the cloud server, or the data consumer. , and The costs are relatively moderate because these functions primarily record commitments, binding tags, hash values, and signatures. Settlement contracts have the lowest costs because they only require updating the transaction status and releasing or refunding the deposit based on the ruling.
[0290] Under normal transaction gas costs, the contract only performs transaction creation, data commitment submission, key tag conversion submission, result submission, and settlement. Since there is no appeal process, the normal transaction process remains lightweight. The main costs come from... This function initializes the transaction context and locks the corresponding payments and deposits.
[0291] In the gas costs of appealing contracts under different disputed circumstances The cost is lower because the contract can be terminated early once invalid provider-side evidence is detected. In contrast, honesty cases, server failure cases, and false claims require more complete evidence verification, thus incurring higher gas costs. This result is consistent with the design goal of the proposed scheme: smart contracts can distinguish between invalid data submissions, erroneous outsourced computations, and malicious payment rejections.
[0292] In the appeal algorithm verification cost under different vector dimensions, the Gas cost increases with the increase of vector dimension, especially... and In this case, the contract needs to verify the correctness of the conversion key and the correctness of the outsourced conversion, and these pair-based checks grow with the vector dimension. Therefore, full on-chain verification provides strong public verifiability, but introduces high costs for large-scale vectors. In practical deployments, a hybrid model can be adopted, where high-overhead pair-based checks are performed off-chain, while the contract records commitments, hashes, signatures, and dispute results on-chain. This reduces gas consumption while maintaining auditability and fair settlement.
[0293] For resource-constrained IoT devices, the cost of data encryption, request generation, and decryption algorithms remains low despite the increase in vector dimension. This confirms that the operations performed by the data consumer are lightweight and suitable for resource-constrained IoT devices.
[0294] The technical terms, principles, or means related to the technical solutions of the present invention mentioned in the above embodiments, which are not described in detail above, are all well-known technologies or common practices that are known to those skilled in the art.
[0295] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.
Claims
1. A fair and verifiable double-outsourcing function hidden inner product encryption method for IoT data transactions, characterized in that, This method, executed by four types of entities—data providers, data consumers, cloud servers, and blockchain platforms—includes the following steps: Obtain security parameters and vector dimensions, execute the initialization algorithm, and generate public parameters, master key, and the initial state of the smart contract; The data provider encrypts the IoT data vector into ciphertext with data commitment and the data provider's digital signature based on the master key, while the data consumer generates a private recovery key, a public encoded key and an encryption request based on the transaction context and the private evaluation vector. The data provider uses the master key, public encoded key, encryption request, and ciphertext to generate a conversion key bound to the transaction; The cloud server performs an outsourced conversion based on the ciphertext and conversion key to generate a master intermediate ciphertext, a correction item, a conversion proof, and a server signature. Then, any entity among the data consumer, the cloud server, or the smart contract executes a verification algorithm to verify the data commitment, the data provider's digital signature, the conversion key label, and the conversion proof. The data consumer performs affine offset elimination and multiplicative mask removal based on the private recovery key, master intermediate ciphertext, and correction term to obtain the inner product of the IoT data vector and the private evaluation vector. When a smart contract receives a dispute, it runs an appeal algorithm based on the submitted evidence, outputs a ruling, and then releases or penalizes data payments, computing fees, or deposits based on the ruling.
2. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The execution steps of the initialization algorithm are as follows: Randomly select an invertible matrix, calculate the inverse of the transpose of the invertible matrix as the dual matrix, and for each row and each column in the vector dimension, calculate the public group code of the dual matrix. For each row in the vector dimension, calculate its affine offset correction parameter; The public parameters include public group coding and affine offset correction parameters, and the master key includes an invertible matrix and a dual matrix.
3. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The steps for encrypting IoT data vectors into ciphertext are as follows: The data provider multiplies the invertible matrix in the master key with the IoT data vector to obtain the first intermediate vector; For each component of each first intermediate vector, calculate the corresponding ciphertext component to obtain the first ciphertext component; Based on auxiliary information, the data provider's identity, and the first ciphertext component, the data identifier and data commitment can be calculated using a collision-resistant hash function, as shown in the following formula; ; ; in, Represents a data identifier. Represents a collision-resistant hash function. Indicates the identity of the data provider. Indicates auxiliary information, Indicates the first ciphertext component, Indicates a data commitment; The data provider signs the encrypted data description, obtains the data provider's digital signature, and finally outputs the ciphertext. The tuple containing the data identifier, data commitment, auxiliary information and the data provider's digital signature is recorded in the smart contract. The encrypted data description includes a data identifier, a data commitment, auxiliary information, and a first ciphertext component; The ciphertext includes a first ciphertext component, a data identifier, a data commitment, supplementary information, and a digital signature from the data provider.
4. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The steps for generating the private recovery key, the public encoded key, and the encryption request are as follows: The data consumer uniformly and randomly samples the secret mask value and affine offset value, and combines the two to form a private recovery key; For each component in the vector dimension, compute the affine mask group code: To form a public coded key, where, This represents affine mask group coding. Denotes the generator of the second cyclic group. Represents the secret mask value, Represents each component of the private evaluation vector. Indicates the affine offset value. Indicates the second cyclic group. Indicates column index; The encoded key label is bound to the transaction context, and the data consumer signs the concatenation result of the encoded key label, the transaction context, and the public encoded key to obtain the data consumer's digital signature; The encoded key tag is obtained by performing a collision-resistant hash function operation on the concatenation result of the transaction context and the public encoded key; The encryption request includes a public encoding key, an encoding key label, and a digital signature from the data consumer.
5. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The steps for generating the conversion key bound to the transaction are as follows: After the data provider verifies the digital signature and transaction context of the data consumer, it parses the public encoded key and uses the dual matrix to calculate the transformation key component for each row in the vector dimension, thus forming the transformation key body. A collision-resistant hash function is used to generate a transformation key tag based on the transformation key body, transaction context, data commitment, and public encoded key. The concatenation result of the transaction context, data commitment, public encoded key, transformation key body, and transformation key tag is then signed to obtain a transformation key digital signature. The output is a transformation key containing the transformation key body, public encoded key, transformation key tag, and transformation key digital signature.
6. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The execution steps for generating the master intermediate ciphertext, correction item, conversion proof, and server signature are as follows: The cloud server parses the first ciphertext component and the conversion key, and uses a non-degenerate bilinear mapping to perform pairing operations and product on each row to generate the main intermediate ciphertext. Using the affine offset correction parameters in the public parameters, perform pairing operations and multiplication on each row to generate a correction term to eliminate affine offset; The cloud server calls the collision-resistant hash function to perform hash operations on the transaction context, ciphertext, conversion key, master intermediate ciphertext, and correction item to generate a conversion proof. The cloud server signs the concatenation result of the master intermediate ciphertext, the first ciphertext component, the transaction context, the transformation proof, the correction item, and the transformation key tag to generate a server signature; The final cloud server output includes the main intermediate ciphertext, correction items, conversion proof, and server signature.
7. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The steps to obtain the inner product of the IoT data vector and the private evaluation vector are as follows: The data consumer parses the private recovery key and performs the first step of eliminating affine offsets: ; in, This represents an intermediate result from the first stage. This indicates the ciphertext in the middle of the main text. Indicates the correction term. Indicates the affine offset value. Indicates the target cyclic group; Next, perform the second step to remove the multiplicative mask: ; in, This indicates the intermediate decryption result of the second stage. This represents an intermediate result from the first stage. Represents the secret mask value, Denotes the generators of the target cyclic group. Represents a private evaluation vector. Represents IoT data vectors, Indicates the target cyclic group; Finally, a bounded discrete logarithmic search is performed within the pre-defined finite interval of the inner product value to find a unique value such that... This unique value is the inner product of the IoT data vector and the private evaluation vector. in, Denotes the generators of the target cyclic group. This indicates the intermediate decryption result of the second stage. This represents the inner product value.
8. The IoT data transaction fair and verifiable double-outsourcing function hidden inner product encryption method according to claim 1, characterized in that, The release and penalties for data payments, calculation fees, or deposits executed according to the ruling specifically include: When the transaction is deemed valid, the smart contract releases the data payment to the data provider and the computing fees to the cloud server. When the ruling finds the data provider at fault, the smart contract refunds the data consumer and penalizes the data provider by locking up the deposit. When the ruling indicates that the server is at fault, the smart contract refunds the data consumer and enforces penalties by withholding service fees or deposits from the cloud server smart contract.
9. A fair and verifiable double-outsourcing function-hidden inner product encryption system for implementing the methods described in claims 1-8, characterized in that, include: The initialization module is used to obtain security parameters and vector dimensions to execute the initialization algorithm, and generate public parameters, master key and the initial state of smart contract; The data encryption module, deployed at the data provider, is used to encrypt IoT data vectors using public parameters and a master key. The request generation module, deployed on the data consumer side, is used to generate a private recovery key, a public encoded key, and an encrypted request based on public parameters, transaction context, and a private evaluation vector. The conversion key generation module, deployed at the data provider, is used to generate a transaction-bound conversion key based on the master key, public encoded key, encryption request, and ciphertext. The ciphertext conversion module, deployed on a cloud server, takes encrypted IoT data and conversion keys as input and outputs the main intermediate ciphertext, correction items, conversion proof, and server signature. The verification module, deployed on the data consumer, cloud server, or smart contract, is used to verify the correctness of the conversion key and outsourced data. The decryption module, deployed on the data consumer side, is used to decrypt intermediate ciphertext using a private recovery key to obtain the inner product result. The settlement module, deployed in smart contracts, is used to execute payment settlements and dispute resolution based on the ruling results.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed, it implements the IoT data transaction fair and verifiable double-outsourced function hidden inner product encryption method as described in any one of claims 1 to 8.