Data security transaction method based on searchable re-encryption technology

Abstract

The invention discloses a data security transaction method based on a searchable re-encryption technology, belongs to the technical field of data transaction, and solves the problem that the fairness and security of an existing data transaction mode are difficult to guarantee. The method comprises the steps that a data owner encrypts data based on keywords of the data and uploads the encrypted data to a cloud storage provider; the consumer generates a keyword trap door according to the keyword of the required data, generates a transaction request, sends the transaction request to the smart contract, and pays the guarantee deposit; when the data owner monitors a transaction request initiated to the data owner through the smart contract, generating a re-encryption key and sending the re-encryption key to the smart contract; the cloud storage provider retrieves matched encrypted data according to the transaction request and the re-encryption key, re-encrypts the data, and sends the re-encrypted data to the consumer; and the consumer verifies the re-encrypted data, if the verification is passed, the guarantee deposit of the payment transaction request is transferred to the cloud storage provider through the smart contract, and the data transaction is ended.

Description

Technical Field

[0001] The present invention relates to the field of data transaction technology, and in particular to a data security transaction method based on searchable re-encryption technology. Background Art

[0002] In traditional data transactions, data owners typically store their data on cloud servers so that consumers can easily retrieve and obtain the data they need. However, the trustworthiness of cloud servers is a key issue. On the one hand, cloud servers may tamper with retrieval results, preventing consumers from obtaining the data they truly need. On the other hand, in the absence of a trusted third party, dishonest behavior by both parties can prevent transactions from proceeding smoothly. For example, a cloud server might refuse to send data after receiving payment, or a consumer might refuse to pay after obtaining data.

[0003] To address these issues, searchable encryption (SE) and proxy re-encryption technologies have been introduced into the data transaction process. Searchable encryption allows users to search encrypted data without revealing the plaintext data, while proxy re-encryption protects data privacy by converting the data owner's ciphertext into ciphertext that consumers can decrypt. However, existing searchable encryption and proxy re-encryption schemes still have some limitations. For example, traditional searchable encryption methods cannot guarantee the integrity and correctness of search results in the face of malicious cloud servers. Furthermore, proxy re-encryption schemes may leak the data owner's decryption key during the data conversion process, compromising data security. Furthermore, existing data transaction models typically rely on a trusted third party to ensure transaction fairness. However, this reliance not only increases transaction costs but can also lead to single points of failure and privacy breaches.

[0004] Therefore, how to ensure the fairness of data transactions and the security of data privacy without relying on a trusted third party has become a technical problem that needs to be solved urgently. Summary of the Invention

[0005] In view of the above analysis, an embodiment of the present invention aims to provide a data security transaction method based on searchable re-encryption technology to solve the problem that existing data transaction methods are difficult to ensure the fairness and security of data transactions.

[0006] The present invention discloses a data security transaction method based on searchable re-encryption technology, the method comprising: The data owner encrypts the data itself based on the data's keywords and uploads the encrypted data to the cloud storage provider; The consumer generates a keyword trapdoor based on the keywords of the required data, combines the address information of the target data owner to generate a transaction request, and sends it to the smart contract to pay the deposit for the transaction request; When the data owner detects a transaction request initiated to it through the smart contract, it generates a re-encryption key in response to the transaction request and sends it to the smart contract; Based on the transaction request and the corresponding re-encryption key obtained from the smart contract, the cloud storage provider retrieves the matching encrypted data from the target data owner's encrypted data, re-encrypts it, and sends the generated re-encrypted data to the consumer. The consumer verifies the re-encrypted data within the specified time. If the verification is successful, the deposit for the payment transaction request is transferred to the cloud storage provider through the smart contract, ending the data transaction.

[0007] On the basis of the above solution, the present invention also makes the following improvements: Furthermore, the method further comprises: If the cloud storage provider does not receive the deposit for the payment transaction request within the specified time, the generated re-encrypted data will be sent to the smart contract within the verification time limit, and the smart contract will verify the re-encrypted data based on the keyword trapdoor. If the verification is successful, the smart contract transfers the deposit for the transaction request to the cloud storage provider, completing the data transaction. Otherwise, the smart contract transfers the deposit for the transaction request to the consumer, ending the data transaction.

[0008] Furthermore, the method further comprises: If the smart contract does not receive the re-encrypted data sent by the cloud storage provider within the verification time limit, the smart contract will transfer the deposit for paying the transaction request to the consumer, ending the data transaction.

[0009] Furthermore, the consumer generates a keyword trapdoor as follows and executes: The consumer generates a keyword trapdoor based on the keyword of the required data and its own private key.

[0010] Furthermore, the consumer generates a transaction request in the following manner: The consumer generates a transaction request by combining his or her own public key and address information, the generated keyword trapdoor, and the address information of the target data owner.

[0011] Furthermore, the data owner determines whether the transaction request is initiated to itself through the following methods: The data owner monitors the transaction requests received by the smart contract in real time and determines whether the address information of the target data owner in the transaction request is consistent with its own address information. If they are consistent, it indicates that the current transaction request is a transaction request initiated to itself.

[0012] Furthermore, the data owner generates a re-encryption key in response to the transaction request and sends it to the smart contract in the following way: If the data owner authorizes the corresponding transaction request, he or she uses his or her own private key and the consumer's public key to generate a re-encryption key in response to the transaction request.

[0013] Furthermore, the cloud storage provider retrieves the matching encrypted data as follows: The cloud storage provider continuously monitors the smart contract. When it detects a transaction request received by the smart contract and the corresponding re-encryption key generated by the data owner, the cloud storage provider searches the encrypted data of the target data owner stored in its own storage based on the transaction request and the corresponding re-encryption key obtained from the smart contract and retrieves the matching encrypted data.

[0014] Furthermore, the cloud storage provider retrieves the encrypted data of the target data owner stored in its own storage based on the transaction request and the corresponding re-encryption key obtained from the smart contract, and executes: The cloud storage provider uses the re-encryption key to verify the target data owner's access rights to the encrypted data and uses the keyword trapdoor to locate the encrypted data stored in the cloud storage provider with the same keyword as the desired data.

[0015] Furthermore, the cloud storage provider retrieves the matching encrypted data and re-encrypts it, executing: The cloud storage provider re-encrypts the retrieved matching encrypted data according to the re-encryption key to generate re-encrypted data.

[0016] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects.

[0017] The data security transaction method based on searchable re-encryption technology provided by the present invention has the following advantages: (1) Guarantee of transaction fairness Based on a searchable re-encryption scheme, this paper designs a smart contract-based data transaction solution. Leveraging the blockchain's immutability and traceability, this approach ensures transaction fairness and data integrity. Consumers pay a deposit at the outset of a transaction, which is considered complete only after the requested data has been successfully retrieved; otherwise, the deposit is returned to the consumer. This mechanism effectively prevents dishonest behavior from both cloud storage providers and consumers, ensuring smooth transactions and resolving the difficulty of ensuring fairness in existing data trading methods.

[0018] (2) Improved privacy The data owner's decryption key is not exposed to the cloud storage provider during the re-encryption process. The cloud storage provider only uses the temporarily negotiated re-encryption key to convert the data owner's ciphertext into ciphertext that can be decrypted by consumers. This enables data sharing while ensuring the core privacy of the data owner is not violated.

[0019] (3) Increased autonomy The trapdoors in this invention are completely independently generated by consumers, without requiring data owners to generate or confirm them. This changes the traditional situation where data owners generate trapdoors, increasing interaction costs and potentially causing process delays or privacy leaks, while consumer-generated trapdoors require confirmation from the data owner, which can lead to the risk of the data owner refusing to confirm or tampering with the trapdoor. This design gives consumers greater autonomy in the data retrieval process, enabling them to independently generate trapdoors, simplifying the process and improving efficiency while avoiding the risks associated with intermediate steps.

[0020] (4) Process compatibility optimization The trapdoor generation method in this invention is tightly integrated with the re-encryption process, seamlessly bridging the verification requirements before and after re-encryption. This stands in stark contrast to traditional solutions, where trapdoor generation is separated from the re-encryption process, resulting in a complex verification process and the need for multiple trapdoor generation. This design not only improves process compatibility but also supports dual-stage verification of retrieval and testing, further enhancing the security and reliability of the system.

[0021] In the present invention, the above-mentioned technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of the present invention will be described in the following description, and some advantages will become apparent from the description or be learned through practice of the present invention. The objectives and other advantages of the present invention can be realized and obtained through the contents particularly pointed out in the description and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings are only used for the purpose of illustrating specific embodiments and are not to be considered as limiting the present invention. Throughout the drawings, the same reference symbols denote the same components. Figure 1 A flowchart of a data security transaction method based on searchable re-encryption technology provided by an embodiment of the present invention; Figure 2 A flowchart of another data security transaction method based on searchable re-encryption technology provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0023] The preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings, wherein the accompanying drawings constitute a part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, and are not used to limit the scope of the present invention.

[0024] A specific embodiment of the present invention discloses a data security transaction method based on searchable re-encryption technology. The flowchart of the method is as follows: Figure 1 and Figure 2 As shown, the specific steps include: Step S1: The data owner encrypts the data itself based on the data's keywords and uploads the encrypted data to the cloud storage provider; Step S2: The consumer generates a keyword trapdoor based on the keywords of the required data, combines the address information of the target data owner, generates a transaction request, and sends it to the smart contract, paying a deposit for the transaction request; Step S3: When the data owner detects a transaction request initiated to it through the smart contract, it generates a re-encryption key in response to the transaction request and sends it to the smart contract; Step S4: The cloud storage provider retrieves the matching encrypted data from the target data owner's encrypted data based on the transaction request and the corresponding re-encryption key obtained from the smart contract, performs re-encryption processing, and sends the generated re-encrypted data to the consumer; Step S5: The consumer verifies the re-encrypted data within the specified time. If the verification is successful, the deposit for the payment transaction request is transferred to the cloud storage provider via the smart contract, ending the data transaction.

[0025] It should be noted that in the data security transaction method based on searchable re-encryption technology provided in this embodiment, key generation, data encryption, keyword trap, re-encryption key, re-encrypted data and its verification process are all implemented based on searchable re-encryption technology, as described below.

[0026] First, before encrypting the data itself, the data owner needs to generate their own public-private key pair. Furthermore, before generating a keyword trapdoor, the consumer also needs to generate their own public-private key pair. This process of generating a public-private key pair corresponds to the key generation phase in searchable re-encryption technology. The data owner's public key is used for data encryption and authorization, while the private key is used for data decryption and signature verification. The consumer's public key is used for authorization and verification, while the private key is used for decrypting data and signing.

[0027] In step S1, the data owner encrypts the data itself based on the data's keywords, generating encrypted data. This process corresponds to the searchable encryption stage in searchable re-encryption technology. Specifically, the data owner uses a searchable encryption algorithm based on their private key, the data, and the data's keywords to generate encrypted data.

[0028] Because encrypted data contains keywords, it facilitates subsequent search and retrieval. Furthermore, the encryption process ensures the confidentiality and integrity of data during transmission and storage, preventing unauthorized access and tampering. The data owner uploads the encrypted data to a cloud storage provider, which receives and stores the encrypted data, ensuring its secure storage and availability according to the instructions and protocol requirements of the smart contract.

[0029] In step S2, when a consumer wishes to purchase the data they need, they can generate a keyword trapdoor based on the keywords of the desired data and their own private key. This process corresponds to the trapdoor generation stage in searchable re-encryption technology. In this embodiment, the keyword trapdoor is an encrypted representation of the consumer's desired data and keywords, used to accurately search within the encrypted data while protecting the privacy of the consumer's query intent.

[0030] During implementation, the consumer generates a transaction request by combining their public key and (Ethereum) address information, the generated keyword trapdoor, and the target data owner's (Ethereum) address information, and sends it to the smart contract. The target data owner's (Ethereum) address information is used to determine the target of the data transaction request. It should be noted that the smart contract does not perform any special processing on the received keyword trapdoor; it is simply stored within the smart contract as the value of a defined variable. This keyword trapdoor serves as a key basis for subsequent data retrieval and dispute verification.

[0031] Afterward, the consumer pays the smart contract a deposit to support the transaction. It's important to note that the smart contract only records deposit payments and doesn't process them immediately. The deposit payment serves as a safeguard for the consumer's commitment to the transaction. By paying the deposit, the consumer demonstrates their sincerity in completing the transaction and their willingness to assume any risks that may arise from their actions. At the conclusion of the transaction, the smart contract processes the deposit based on the transaction results (such as whether the data meets the requirements and whether the consumer confirms on time), thereby constraining the behavior of both parties and ensuring a smooth transaction. This process lays the foundation for subsequent data retrieval, delivery, and verification. The automated and tamper-proof nature of smart contracts also ensures fair and transparent transactions.

[0032] In step S3, the following operations are specifically performed.

[0033] Step S31: The data owner monitors the transaction request received by the smart contract in real time, and determines whether the (Ethereum) address information of the target data owner in the transaction request is consistent with its own (Ethereum) address information. If they are consistent, it indicates that the current transaction request is a transaction request initiated to itself.

[0034] Step S32: If the data owner authorizes the corresponding transaction request, he or she uses his or her own private key and the consumer's public key to generate a re-encryption key in response to the transaction request.

[0035] In specific implementations, the data owner can decide whether to authorize the transaction request based on factors such as their own business strategy, data usage terms, and the consumer's historical reputation. If the transaction request is authorized, a re-encryption key is generated. This re-encryption key generation process corresponds to the re-encryption key generation stage in searchable re-encryption technology.

[0036] It should be noted that some existing schemes use bidirectional re-encryption keys, allowing the proxy to convert ciphertexts from both parties simultaneously, potentially leading to the risk of key leakage. This embodiment, however, uses a one-way re-encryption key, allowing only conversion from the data owner's public key ciphertext to the consumer's public key ciphertext, but not the reverse. In other words, the re-encryption key generation process supports only one-way conversion, preventing the consumer and cloud storage provider from colluding to reversely derive the data owner's private key, thereby enhancing key security. The re-encryption key generation process is the core component of the proxy re-encryption scheme, allowing the data owner to securely transfer access rights to encrypted data to the consumer without decrypting the data itself.

[0037] The data owner sends the generated re-encryption key to the smart contract. In this embodiment, the proxy re-encryption key acts like an authorization code, serving as a credential granted by the data owner to consumers to access specific encrypted data. The smart contract receives and stores this re-encryption key, which serves as critical information for subsequent data decryption and transaction verification. By submitting the re-encryption key to the smart contract, the data owner ensures that only authorized consumers can decrypt and access the encrypted data using this key. During the authorization process with the proxy re-encryption scheme, the data owner can complete authorization without decrypting the data, and consumers cannot obtain the data owner's private key information from the re-encryption key, thus ensuring data confidentiality and privacy. Furthermore, the smart contract, acting as the central node for the transaction, stores the re-encryption key and is responsible for subsequent verification and decryption operations. This mechanism leverages the immutability and transparency of smart contracts to ensure the fairness and credibility of the authorization process.

[0038] In step S4, the following operations are specifically performed.

[0039] Step S41: The cloud storage provider continuously monitors the smart contract. When it detects a transaction request received by the smart contract and the corresponding re-encryption key generated by the data owner, the cloud storage provider searches for the encrypted data of the target data owner stored in its own storage based on the transaction request and the corresponding re-encryption key obtained from the smart contract, and retrieves the matching encrypted data.

[0040] Specifically, the process of retrieving encrypted data corresponds to the cloud-based ciphertext search stage of the searchable re-encryption technology.

[0041] The re-encryption key ensures that only consumers authorized by the data owner can access specific data, while also protecting data privacy and security. The keyword trapdoor is an encrypted representation of the consumer's desired data content, enabling rapid location of data items matching the keyword without decrypting the data. The cloud storage provider uses the keyword trapdoor and re-encryption key to retrieve encrypted data items matching the consumer's request. This process ensures accurate and efficient data searches. It should be noted that the searchable proxy re-encryption scheme allows the cloud storage provider to perform data searches using the keyword trapdoor and re-encryption key without decrypting the data. This mechanism protects data privacy and improves data search efficiency. The combined use of the keyword trapdoor and re-encryption key ensures accurate and secure data searches. The cloud storage provider uses the re-encryption key to verify the target data owner's access rights to the encrypted data and the keyword trapdoor to locate encrypted data stored on the cloud storage provider with the same keyword as the desired data. As the infrastructure provider for data storage and retrieval, the cloud storage provider is responsible for executing data searches. Its role is neutral, operating solely based on the instructions of the smart contract and the provided keys. Through the operations in the above data search phase, cloud storage providers can complete data search tasks efficiently and securely, providing necessary data support for subsequent data delivery and transaction completion.

[0042] Step S42: The cloud storage provider re-encrypts the retrieved matching encrypted data according to the re-encryption key, and sends the generated re-encrypted data to the consumer.

[0043] In practice, the cloud storage provider re-encrypts the retrieved encrypted data using the re-encryption key obtained from the smart contract. This re-encryption process corresponds to the data re-encryption stage in searchable proxy re-encryption technology.

[0044] The re-encryption key converts the data owner's encrypted data into a form that consumers can decrypt. This process eliminates the need to decrypt the original data, ensuring data privacy and security. The cloud storage provider applies the re-encryption key to each matching piece of encrypted data, generating the corresponding re-encrypted data that can be decrypted by the consumer using their private key.

[0045] The cloud storage provider encapsulates the re-encrypted data to ensure its integrity and confidentiality during transmission. This encapsulation process may include adding digital signatures, timestamps, and other information to prevent data tampering or forgery. The cloud storage provider then sends the re-encrypted data to the consumer via a secure communication channel (e.g., using an encrypted network protocol). Data confidentiality and integrity must be ensured during transmission to prevent data theft or tampering.

[0046] In step S5, the following operations are specifically performed.

[0047] Step S51: The consumer receives the re-encrypted data and verifies it based on the keyword trapdoor. If the verification is successful within the specified time, the required data is recovered from the re-encrypted data; and a message confirming the completion of the transaction is sent to the smart contract. The smart contract transfers the deposit for the payment transaction request to the cloud storage provider, completing the data transaction.

[0048] The process of verifying the re-encrypted data and recovering the required data from the re-encrypted data corresponds to the ciphertext testing phase, which can be searched for in the ciphertext testing phase of the proxy re-encryption technology.

[0049] If the consumer does not send a message confirming the transaction completion to the smart contract within the specified time t1, this may be due to the following three situations: (1) simple network delay. (2) The consumer obtains the correct data but does not want to pay the transaction amount. (3) The cloud storage provider does not send the correct data that the consumer needs. In response to the above situations, the data security transaction method based on searchable re-encryption technology provided in this embodiment also includes the following steps.

[0050] Step S6: If the cloud storage provider does not receive the deposit for the payment transaction request within the specified time, the generated re-encrypted data will be sent to the smart contract within the verification time limit. The smart contract will verify the re-encrypted data based on the keyword trapdoor. If the verification is successful, the smart contract will transfer the deposit for the payment transaction request to the cloud storage provider and end the data transaction; otherwise, the smart contract will transfer the deposit for the payment transaction request to the consumer and end the data transaction.

[0051] More specifically, the cloud storage provider can choose to send the re-encrypted data to the smart contract between the specified time t1 and the verification time limit t2, allowing the smart contract to verify the correctness of the re-encrypted data. If correct, the smart contract will transfer the deposit to the cloud storage provider. This process can solve the problems in cases (1) and (2). If the smart contract verifies that the re-encrypted data is incorrect, it corresponds to case (3), that is, the cloud storage provider sent the consumer incorrect data, so the rational consumer did not send a message to the smart contract to confirm the completion of the transaction, and the smart contract will transfer the deposit back to the consumer.

[0052] In addition, the data security transaction method based on searchable re-encryption technology provided by this embodiment also includes the following steps.

[0053] Step S7: If the smart contract does not receive the re-encrypted data sent by the cloud storage provider within the verification time limit, the smart contract will transfer the deposit for paying the transaction request to the consumer and end the data transaction.

[0054] That is, if the cloud storage provider does not send data to the smart contract between t1 and t2, it means that the data provided by the data owner to the cloud storage provider does not meet the consumer's needs, so the data transaction is not established, and the smart contract will transfer the deposit back to the consumer.

[0055] In summary, there are several possible outcomes for the transaction process.

[0056] 1) If the consumer sends a confirmation message to the smart contract within the specified time t1, the transaction is complete and the smart contract transfers the deposit to the cloud storage provider. This is the most normal scenario and is the one that most transactions should follow.

[0057] 2) If the consumer fails to send a transaction confirmation message to the smart contract within the specified time t1, and the cloud storage provider sends the re-encrypted data to the smart contract within t2, and the smart contract verifies the data's accuracy, the transaction is complete, and the smart contract transfers the deposit to the cloud storage provider. This indicates a problem on the consumer's side, and the smart contract provides a way for the cloud storage provider to ensure fair transactions.

[0058] 3) If the consumer fails to send a transaction confirmation message to the smart contract within the specified time t1, and the cloud storage provider sends the re-encrypted data to the smart contract within t2, and the smart contract verifies the data for errors, the transaction is complete, and the smart contract returns the deposit to the consumer. This situation indicates a problem on the cloud storage provider's side. To ensure the fairness of the transaction, the smart contract provides a way for consumers to ensure fair transactions.

[0059] 4) If the consumer fails to send a message confirming the completion of the transaction to the smart contract within the specified time t1, and the cloud storage provider also fails to send the re-encrypted data to the smart contract within time t2, then the transaction is completed, and the smart contract will transfer the deposit back to the consumer. This situation indicates a problem on the part of the cloud storage provider. To ensure the fairness of the transaction, the smart contract provides a way for the consumer to guarantee transaction fairness.

[0060] First of all, it should be noted that in Figure 2 , the dashed line represents the interaction with the smart contract, the solid line represents the interaction between the participants in the data transaction model, and the serial numbers are used to identify the order of the normal transaction process. (6b) and (7c) represent the flow channels of the deposit when malicious transaction behaviors occur. In this embodiment, a commitment scheme based on blockchain time is formulated according to the public transparency of the blockchain. Therefore, two timers t1 and t2 are set in the scheme. They represent the time sequence through the blockchain height and satisfy t1 < t2. Among them, t1: is used to set the first key time point in the transaction process, such as the deadline for data delivery. t2: is used to set the second key time point in the transaction process, such as the trigger time for deposit refund or penalty.

[0061] To sum up, in this embodiment, the cloud storage provider can convert the ciphertext uploaded by the data owner into a ciphertext that the consumer can decrypt through the re-encryption key temporarily negotiated between the consumer and the data owner. At the same time, the decryption key of the data owner will not be displayed during this process, and the converted ciphertext can still maintain the ability of keyword search. The new scheme retains the advantages of both searchable encryption and proxy re-encryption. The advantage of the searchable encryption scheme is that it can search for the data required by the consumer without revealing the plaintext. The advantage of the proxy re-encryption scheme is that it can convert the data that only the data owner can decrypt into the data that only the consumer can decrypt, without revealing any information to the intermediate cloud storage provider. Therefore, the cloud storage provider can convert the ciphertext uploaded by the data owner into a ciphertext that the consumer can decrypt through the re-encryption key temporarily negotiated between the consumer and the data owner. At the same time, the decryption key of the data owner will not be displayed during this process, and the converted ciphertext can still maintain the ability of keyword search.

[0062] Next, the searchable re-encryption technology used in the data security transaction method based on searchable re-encryption technology provided in this embodiment will be highlighted as follows.

[0063] In this embodiment, the searchable re-encryption technique combines the functions of searchable encryption and proxy re-encryption, thereby being able to generate keyword trapdoors and re-encryption keys. In this embodiment, the searchable re-encryption scheme can be expressed in the following polynomial time random form: Γ= (KeyGen, KsEnc, Trapdoor, RekeyGen, Search, ReEnc, Test, , ).

[0064] First, let g and h be additive cyclic groups and The generators of , whose order is p, form a bilinear map e: × → , so that Z = e(g, h) ∈ ; Hash function H: → ; Finally, let the keyword w = e(g, ). On this basis, the following searchable proxy re-encryption scheme is constructed.

[0065] (1) Key generation phase KeyGen(1λ) → (sk, pk): Available to data owners and data consumers. After inputting the security parameter 1λ, the key generation algorithm outputs the private key sk and public key pk of the data owner and data consumer.

[0066] Specifically, this embodiment generates a public-private key pair based on a key generation algorithm of a bilinear mapping.

[0067] For the data owners, select a random number and Generate a private key = ( , ), calculate the public key = ( , ).

[0068] For the consumers, choose a random number and Generate a private key = ( , ), calculate the public key = ( , ).

[0069] (2) Searchable encryption stage KsEnc( )→ ( ), available to the data owner.

[0070] For the Data owner, according to the data owner's private key ,data and data keywords , using a searchable encryption algorithm to output encrypted data ("second-level ciphertext") .

[0071] (3) Trapdoor generation stage Trapdoor , ) → ( ): Available to consumers.

[0072] For the Consumers, requesting keywords with the required data Data, based on its own private key and the keyword for the desired data , using the trapdoor generation algorithm to generate keyword trapdoors , H is a hash function.

[0073] (4) Re-encryption key generation phase RekeyGen( , ) → ( ): Available to the data owner.

[0074] Assume that Consumers to The data owner requests the data, at this time, The data owner uses his own private key Hedi Consumer's public key , generate the re-encryption key =

[0075] (5) Cloud ciphertext search stage Search( , , ) → {0, 1}: The cloud storage provider is available.

[0076] When entering the second level ciphertext = KsEncKsEnc( ), keyword trapdoor =Trapdoor( , ) and the re-encryption key = RekeyGen( , ) After that, if = , then the search algorithm outputs 1, indicating that the relevant message is matched, otherwise it outputs 0.

[0077] (6) Data re-encryption stage ReEnc( , ) → : Cloud storage providers are available.

[0078] Cloud storage providers use re-encryption keys , for the retrieved matching encrypted data Perform re-encryption processing to obtain re-encrypted data .

[0079] (7) Ciphertext testing phase Test( , ) → {0, 1}: Consumers and smart contracts are available.

[0080] On input and keyword trapdoor =Trapdoor( , ) After that, if = , then the test algorithm outputs 1, indicating that the ciphertext and the trapdoor match, that is, the keyword that generates the trapdoor matches the message being tested, otherwise it outputs 0.

[0081] Dec1( , ) → m: Available to consumers. When entering the consumer's private key and ciphertext Afterwards, the decryption algorithm 1 outputs the decrypted message m.

[0082] In addition, data owners can also decrypt their own data, as described below.

[0083] Dec2( , ) → m: Available to the data owner. Enter the data owner's private key and ciphertext Afterwards, decryption algorithm 2 outputs the decrypted message m.

[0084] Based on the above content, the improvements of the searchable re-encryption technology in this embodiment are mainly reflected as follows.

[0085] (1) Some existing schemes use two-way re-encryption keys, allowing agents to convert ciphertexts of both parties at the same time, which may lead to the risk of key leakage. The scheme of this application uses a one-way re-encryption key, which only allows conversion from the data owner's public key ciphertext to the consumer's public key ciphertext, and cannot be converted in reverse. The specific implementation is: the re-encryption key is generated by the data owner's private key and the consumer's public key. The re-encryption key only supports one-way conversion, preventing the consumer and the storage from colluding to reversely deduce the data owner's private key, thereby enhancing key security.

[0086] (2) Existing solutions require data owners to generate trapdoors, which may lead to keyword privacy leakage (data owners know the consumer's search content). This application solution allows consumers to independently generate keyword trapdoors without exposing the keywords themselves to the data owner or cloud storage. Consumers submit trapdoors directly to cloud storage, reducing the risk of privacy leakage in the middle link. Cloud storage can only perform matching operations through trapdoors, but cannot parse keyword content to achieve "keyword privacy protection."

[0087] (3) Existing solutions do not achieve a strong binding between messages and keywords, and consumers cannot verify whether the search results actually match the trapdoor. This application solution uses bilinear mapping and hash functions to associate message encryption with keywords, ensuring that the ciphertext only contains content corresponding to legitimate keywords.

[0088] (4) The testing function of most solutions only supports a single ciphertext type before or after re-encryption, and cannot take into account the multi-level verification requirements in the transaction process. The trapdoor of this application solution can act on the second-level ciphertext (original ciphertext) and the first-level ciphertext (re-encrypted ciphertext) at the same time. The specific application scenario is: the smart contract can verify whether the re-encrypted ciphertext returned by the cloud storage matches the consumer trapdoor through the test algorithm to ensure the fairness of the transaction. After receiving the ciphertext, the consumer can verify it again ( Before decryption), to prevent cloud storage from tampering with the results.

[0089] Those skilled in the art will appreciate that all or part of the process steps of the above-described embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, such as a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0090] The above description is only a preferred specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention.

Claims

1. A data security transaction method based on searchable re-encryption technology, characterized in that: The method comprises: The data owner encrypts the data itself based on the data's keywords and uploads the encrypted data to the cloud storage provider; The consumer generates a keyword trapdoor based on the keywords of the required data, combines the address information of the target data owner to generate a transaction request, and sends it to the smart contract to pay the deposit for the transaction request; When the data owner detects a transaction request initiated to it through the smart contract, it generates a re-encryption key in response to the transaction request and sends it to the smart contract; Based on the transaction request and the corresponding re-encryption key obtained from the smart contract, the cloud storage provider retrieves the matching encrypted data from the target data owner's encrypted data, re-encrypts it, and sends the generated re-encrypted data to the consumer. The consumer verifies the re-encrypted data within the specified time. If the verification is successful, the deposit for the payment transaction request is transferred to the cloud storage provider through the smart contract, ending the data transaction.

2. The data security transaction method based on searchable re-encryption technology according to claim 1 is characterized in that: The method further comprises: If the cloud storage provider does not receive the deposit for the payment transaction request within the specified time, the generated re-encrypted data will be sent to the smart contract within the verification time limit, and the smart contract will verify the re-encrypted data based on the keyword trapdoor. If the verification is successful, the smart contract transfers the deposit for the transaction request to the cloud storage provider, completing the data transaction. Otherwise, the smart contract transfers the deposit for the transaction request to the consumer, ending the data transaction.

3. The data security transaction method based on searchable re-encryption technology according to claim 2 is characterized in that: The method further comprises: If the smart contract does not receive the re-encrypted data sent by the cloud storage provider within the verification time limit, the smart contract will transfer the deposit for paying the transaction request to the consumer, ending the data transaction.

4. The data security transaction method based on searchable re-encryption technology according to any one of claims 1 to 3, characterized in that: The consumer generates a keyword trapdoor as follows and executes: The consumer generates a keyword trapdoor based on the keyword of the required data and its own private key.

5. The data security transaction method based on searchable re-encryption technology according to claim 4 is characterized in that: The consumer generates a transaction request as follows: The consumer generates a transaction request by combining his or her own public key and address information, the generated keyword trapdoor, and the address information of the target data owner.

6. The data security transaction method based on searchable re-encryption technology according to claim 5 is characterized in that: The data owner determines whether the transaction request is directed to him / her in the following ways: The data owner monitors the transaction requests received by the smart contract in real time and determines whether the address information of the target data owner in the transaction request is consistent with its own address information. If they are consistent, it indicates that the current transaction request is a transaction request initiated to itself.

7. The data security transaction method based on searchable re-encryption technology according to claim 6 is characterized in that: The data owner generates a re-encryption key in response to the transaction request and sends it to the smart contract in the following way: If the data owner authorizes the corresponding transaction request, he or she uses his or her own private key and the consumer's public key to generate a re-encryption key in response to the transaction request.

8. The data security transaction method based on searchable re-encryption technology according to claim 7 is characterized in that: The cloud storage provider retrieves the matching encrypted data as follows: The cloud storage provider continuously monitors the smart contract. When it detects a transaction request received by the smart contract and the corresponding re-encryption key generated by the data owner, the cloud storage provider searches the encrypted data of the target data owner stored in its own storage based on the transaction request and the corresponding re-encryption key obtained from the smart contract and retrieves the matching encrypted data.

9. The data security transaction method based on searchable re-encryption technology according to claim 8 is characterized in that: The cloud storage provider retrieves the encrypted data of the target data owner stored in its own storage based on the transaction request and the corresponding re-encryption key obtained from the smart contract, and executes: The cloud storage provider uses the re-encryption key to verify the target data owner's access rights to the encrypted data and uses the keyword trapdoor to locate the encrypted data stored in the cloud storage provider with the same keyword as the desired data.

10. The data security transaction method based on searchable re-encryption technology according to claim 9 is characterized in that: The cloud storage provider retrieves the matching encrypted data and re-encrypts it, executing: The cloud storage provider re-encrypts the retrieved matching encrypted data according to the re-encryption key to generate re-encrypted data.

Images