A data processing method, device, apparatus, and storage medium

Abstract

Embodiments of the present application disclose a data processing method, device and equipment, and a storage medium, wherein the method can comprise: obtaining a key acquisition request, the key acquisition request comprising a token of a target account and ciphertext of a first key of the target account; determining plaintext of the first key according to the ciphertext of the first key in the case that the token of the target account is verified, and returning the plaintext of the first key to a requester of the key acquisition request; obtaining to-be-verified data, the to-be-verified data being obtained by encrypting target data by the requester of the key acquisition request using the plaintext of the first key; performing integrity verification on the to-be-verified data; and returning validity proof of the to-be-verified data to the requester of the key acquisition request in the case that the to-be-verified data passes the integrity verification. It can be seen that the target data is encrypted by the plaintext of the first key, and the validity proof of the to-be-verified data is generated, so that the security of the data can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a data processing method, a data processing device, a computer equipment, and a computer-readable storage medium. Background Technology

[0002] With the continuous development of computer technology, more and more data is being stored on computer devices. Taking ticketing data as an example, after ticketing administrators synchronize the required ticketing data (such as ticketing data related to their department) from the network, they usually need to store this ticketing data on a computer device. Practice has shown that a single computer device may be used by multiple parties, and the data stored on such devices is at risk of leakage and tampering, resulting in low security. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and storage medium that can improve data security.

[0004] On one hand, embodiments of this application provide a data processing method, the method comprising:

[0005] Obtain a key retrieval request, which includes the target account's token and the ciphertext of the target account's first key;

[0006] If the token verification of the target account is successful, the plaintext of the first key is determined based on the ciphertext of the first key, and the plaintext of the first key is returned to the requester who requested the key acquisition request.

[0007] Obtain the data to be verified, which is obtained by encrypting the target data using the plaintext of the first key by the requester of the key acquisition request;

[0008] The integrity of the data to be verified is checked. If the data passes the integrity check, the validity of the data is returned to the requester who requested the key acquisition request.

[0009] On one hand, embodiments of this application provide a data processing method, the method comprising:

[0010] Send a key retrieval request to the trusted execution environment. The key retrieval request includes the target account's token and the ciphertext of the target account's first key.

[0011] If the token verification of the target account is successful, the plaintext of the first key returned by the trusted execution environment is received, and the target data is encrypted using the plaintext of the first key to obtain the data to be verified.

[0012] Provide the data to be verified to the trusted execution environment so that the trusted execution environment can perform integrity verification on the data to be verified.

[0013] If the data to be verified passes the integrity check, the system receives the validity certificate of the data to be verified returned by the trusted execution environment and stores the data to be verified and the validity certificate of the data to be verified together.

[0014] On one hand, embodiments of this application provide a data processing apparatus, which includes:

[0015] The acquisition unit is used to acquire a key acquisition request, which includes the token of the target account and the ciphertext of the first key of the target account;

[0016] The processing unit is configured to determine the plaintext of the first key based on the ciphertext of the first key when the token verification of the target account is successful, and return the plaintext of the first key to the requester of the key acquisition request.

[0017] The acquisition unit is also used to acquire data to be verified, which is obtained by encrypting the target data using the plaintext of the first key by the requester of the key acquisition request.

[0018] The processing unit is also used to perform integrity verification on the data to be verified. If the data to be verified passes the integrity verification, it returns a proof of the validity of the data to be verified to the requester of the key acquisition request.

[0019] In one embodiment, the processing unit is further configured to:

[0020] Obtain login information, including the target account's identifier and the target account's token;

[0021] If the token verification of the target account is successful, a key set is assigned to the target account, which includes a first key and a second key.

[0022] Return the ciphertext of the first key to the provider of the login information. The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key.

[0023] In one implementation, the processing unit is configured to determine the plaintext of the first key based on the ciphertext of the first key, specifically configured to:

[0024] Obtain the second key associated with the ciphertext of the first key;

[0025] The ciphertext of the first key is decrypted using the second key to obtain the plaintext of the first key.

[0026] In one implementation, the data processing method is executed in a trusted execution environment within a computer device, and the processing unit is configured to obtain a second key associated with the ciphertext of the first key, specifically for:

[0027] Based on the target account's identifier and preset parameters, generate a second key that is associated with the ciphertext of the first key;

[0028] The preset parameters include: the serial number of the computer device stored in the trusted execution environment.

[0029] In one implementation, the processing unit is configured to return a proof of the validity of the data to be verified to the requester of the key acquisition request, specifically configured to:

[0030] Calculate the total checksum of the data to be verified;

[0031] Sign the total checksum to obtain the signature data associated with the total checksum;

[0032] Based on the total checksum and the signature data associated with the total checksum, a validity proof of the data to be verified is generated;

[0033] Return a proof of the validity of the data to be verified to the requester of the key acquisition request, so that the requester can associate and store the data to be verified and the proof of validity.

[0034] In one embodiment, the processing unit is further configured to:

[0035] Check if the token currently belongs to the target account's validity period;

[0036] If the current time does not fall within the validity period of the target account's token, a renewal notification is sent to the party that requested the key acquisition request for the target account, so that the party that requested the key acquisition request for the target account can provide a new token.

[0037] In one implementation, the target data is obtained by synchronizing the data in the blockchain network after the target account logs in; the processing unit is further configured to:

[0038] Obtain the target account's token, which is provided by the requester of the target account's key retrieval request when it detects that the target account has logged out of the blockchain network;

[0039] Invalidate the token of the target account.

[0040] On one hand, embodiments of this application provide a data processing apparatus, which includes:

[0041] The processing unit is used to send a key acquisition request to the trusted execution environment. The key acquisition request includes the token of the target account and the ciphertext of the first key of the target account.

[0042] The receiving unit is used to receive the plaintext of the first key returned by the trusted execution environment when the token verification of the target account is successful, and to encrypt the target data using the plaintext of the first key to obtain the data to be verified.

[0043] The processing unit is also used to provide the data to be verified to the trusted execution environment so that the trusted execution environment can perform integrity verification on the data to be verified.

[0044] The receiving unit is also used to receive the validity certificate of the data to be verified returned by the trusted execution environment if the data to be verified passes the integrity check.

[0045] The processing unit is also used to associate and store the data to be verified with the validity proof of the data to be verified.

[0046] In one embodiment, the processing unit is further configured to:

[0047] The validity of the data to be verified proves that the data to be verified is being validated for its integrity.

[0048] If the data to be verified passes the integrity check, the plaintext of the first key is used to decrypt the data to be verified to obtain the target data.

[0049] In one embodiment, the processing unit is further configured to:

[0050] Send login information to the trusted execution environment. The login information includes the identifier of the target account and the token of the target account.

[0051] Receive the ciphertext of the first key returned by the trusted execution environment;

[0052] The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key. The first key and the second key are generated by the trusted execution environment based on the identifier of the target account.

[0053] Accordingly, this application provides a computer device, the device comprising:

[0054] A processor is used to load and execute computer programs;

[0055] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described data processing method.

[0056] Accordingly, this application provides a computer-readable storage medium storing a computer program adapted to be loaded by a processor and executed by the above-described data processing method.

[0057] Accordingly, this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned data processing method.

[0058] In this embodiment, a key acquisition request is obtained. This request includes the target account's token and the ciphertext of the target account's first key. If the target account's token is verified, the plaintext of the first key is determined based on the ciphertext and returned to the requester. Verification data is then obtained; this data is obtained by encrypting the target data using the plaintext of the first key. Integrity verification is performed on the verification data. If the verification data passes the integrity verification, a validity certificate is returned to the requester. Therefore, encrypting the target data using the plaintext of the first key reduces the risk of target data leakage; generating a validity certificate for the verification data better ensures the integrity and validity of the target data, thereby improving data security. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0060] Figure 1a This is a schematic diagram of the architecture of a data sharing system provided in an embodiment of this application;

[0061] Figure 1b A schematic diagram of a blockchain structure is provided for an embodiment of this application;

[0062] Figure 1c A schematic diagram of a block generation process provided in an embodiment of this application;

[0063] Figure 1d A schematic diagram of a two-layer network architecture provided for an embodiment of this application;

[0064] Figure 1e A scenario architecture diagram of an electronic invoice service based on a two-layer network provided for embodiments of this application;

[0065] Figure 1f A schematic diagram of a data processing flow provided in an embodiment of this application;

[0066] Figure 1g This application provides an illustration of a data processing application scenario.

[0067] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0068] Figure 3 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0069] Figure 4 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0070] Figure 5 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application;

[0071] Figure 6 This is a schematic diagram of another data processing apparatus provided in an embodiment of this application;

[0072] Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0073] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0074] This application relates to blockchain technology. The following is a brief introduction to the relevant terms and concepts of blockchain technology:

[0075] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. Essentially, it is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0076] A blockchain network can be understood as a data sharing system 100, which can refer to a system for sharing data between nodes. An exemplary structure of the data sharing system 100 can be found here. Figure 1a ;like Figure 1aAs shown, the data sharing system 100 refers to a system for data sharing between nodes. This data sharing system may include multiple nodes 101, which can refer to various clients within the system. Each node 101, during normal operation, can receive input information and maintain shared data within the system based on this information. To ensure interoperability within the data sharing system, information connections can exist between each node, allowing for information transmission. For example, when any node in the data sharing system receives input information, other nodes in the system obtain this input information according to a consensus algorithm and store it as part of the shared data, ensuring consistency of data stored on all nodes in the system.

[0077] Each node in the data sharing system has a corresponding node identifier. Furthermore, each node can store the node identifiers of other nodes in the data sharing system, so that generated blocks can be broadcast to other nodes in the system based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node; for example, the node identifier can also be a binary sequence code (such as 110001110). Table 1 only uses IP addresses as an example.

[0078] Node Name Node identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node X (X is a positive integer) xx.xxx.xxx.xxx

[0079] Each node in the data-sharing system stores the same blockchain. A blockchain consists of multiple blocks; see [link to blockchain documentation]. Figure 1b A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0080] When generating the individual blocks in the blockchain, see Figure 1cWhen a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0081] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0082] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0083] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and block body, resulting in the current block. Subsequently, the node hosting the blockchain broadcasts the newly generated block to other nodes in its data-sharing system based on the node identifiers of other nodes. These other nodes then perform consensus verification on the newly generated block and, after completing the verification, add it to their stored blockchain. Nodes can perform consensus verification on the newly generated block using a consensus algorithm, which may include, but is not limited to:

[0084] 1) Pow (Proof-of-Work):

[0085] Proof-of-Work (PoW) is a measurement method used by a system (such as the aforementioned data-sharing system) to achieve a specific goal. Simply put, it's a proof used to confirm the amount of work done. Essentially, whoever does more work has a greater chance of receiving additional rewards. In PoW, nodes in the blockchain network calculate a random number that meets certain rules through AND-OR operations. This number grants the node the right to record the data for that round, and the other nodes in the blockchain network verify and store the data. This gives PoW the following advantages: complete decentralization and free node entry and exit.

[0086] 2) PoS (proof-of-stake):

[0087] Proof-of-Stake (PoS) is an upgraded consensus mechanism of Proof-of-Work (PoW). Specifically, the longer a node holds electronic resources (holding time = quantity of electronic resources * holding time), the greater its chance of obtaining the right to record blocks. Electronic resources refer to resources stored electronically in electronic accounts and circulated via the internet. Based on the proportion and duration of electronic resources held by each node, the difficulty of obtaining proof-of-work is proportionally reduced, thus accelerating the process of finding random numbers. While PoS shortens the consensus time to some extent, it still requires the calculation of random numbers.

[0088] 3) DPoS (Delegated Proof of Stake) share authorization mechanism:

[0089] The Delegated Proof-of-Stake (DPoS) mechanism is similar to a board of directors vote, where holders of Bitcoin vote for a certain number of nodes to act as their agents for verification and record-keeping. To incentivize more participation, the system generates a small amount of Bitcoin as a reward. DPoS allows every Bitcoin holder to vote, resulting in 101 representatives, which can be understood as 101 supernodes or mining pools, with equal rights among them. If elected representatives fail to fulfill their duties (failing to generate blocks when it's their turn), they are removed, and the network elects new supernodes to replace them. This allows DPoS to significantly reduce the number of nodes involved in verification and record-keeping, achieving consensus verification in seconds, but the entire consensus mechanism still relies on Bitcoin.

[0090] 4) pbft (Practical Byzantine Fault Tolerance):

[0091] PBFT (Byzantine Fault Tolerance) is a message-passing-based consensus algorithm that achieves consensus through three phases, which may be repeated if failures occur. Specifically, assuming a total of 3f+1 nodes, where f represents the faulty Byzantine node, the algorithm first elects another replica node as the new leader when a node discovers that the leader (e.g., a representative node, ledger node, or supernode) is acting maliciously. Second, the leader broadcasts its chosen value to the other replica nodes via a pre-prepare message. Other replica nodes send a prepare message if they accept it, otherwise they do not. Third, once 2f nodes accept the prepare message, the node sends a commit message. Finally, when 2f+1 nodes accept the commit message, the value is considered finalized. The above process enables the PBFT Byzantine Fault Tolerance algorithm to reach a consensus that each node is composed of business stakeholders or regulators, and that security and stability are guaranteed by the relevant business stakeholders. Furthermore, the consensus latency is approximately 2 to 5 seconds, which basically meets the requirements of commercial real-time processing, improves consensus efficiency, and can meet the needs of high-frequency trading.

[0092] 5) Paxos (a distributed algorithm):

[0093] The Paxos algorithm is a two-phase algorithm with three main roles: proposer, acceptor, and learner. The proposer proposes a proposal, the acceptor agrees or rejects it, and the learner obtains the final value after consensus is reached. The Paxos algorithm consists of two phases: ① Preparation phase: The proposer selects a proposal number n and sends a prepare request to a majority of the acceptors; after receiving the prepare request, if the acceptor's proposal number is greater than all prepare requests it has already responded to, the acceptor replies to the proposer with the proposal it previously accepted and promises not to respond to proposals less than n. ② Approval Phase: Once a proposer receives responses to the prepare request from a majority of acceptors, it enters the approval phase. It sends an accept request to the acceptors that responded to the prepare request, including the number n and the value (if there is no value that has already been accepted, it can freely decide the value). Without violating its commitments to other proposers, the acceptor accepts the request upon receiving it.

[0094] The Paxos algorithm is suitable for simple fault-tolerant models, that is, the system can only have failed or faulty nodes and no malicious nodes. If the number of failed nodes is x (x is a positive integer), then the system can maintain normal operation as long as the number of non-failed nodes is x+1.

[0095] 6) Raft (a distributed consensus algorithm):

[0096] The Raft algorithm comprises three roles: follower, candidate, and leader. A node can only be in one of these three states at any given time, and these roles can transition between each other over time and under changing conditions. All nodes initially start as followers. Followers that do not receive a heartbeat within a timeout period become candidates and broadcast a vote request. The node that receives a majority of votes becomes the leader. In this round of voting, the first node to send a heartbeat has the advantage, and each node only gives its vote once. The leader node periodically sends heartbeats to other nodes. Leader failure triggers a new round of voting.

[0097] In practical applications, when blockchain is used in scenarios such as bill of exchange transactions and data storage for commercial institutions, not all nodes in the blockchain network have sufficient resources and the necessity to participate in the blockchain consensus. To adapt to business needs (such as separation of internal and external networks, business networks, and office networks) and further improve data security and confidentiality, this application provides a two-layer blockchain architecture. This architecture uses a P2P (Peer-to-Peer) network to form a "witness sub-network - consensus sub-network." The P2P network is a peer-to-peer connection network, where each node is called a peer node. Based on a specific network protocol, the P2P network eliminates the need for a central node to maintain the network state. Each node maintains the overall network state and its connection status with neighboring nodes through broadcast interactions.

[0098] Figure 1d This application provides an architecture diagram of a two-layer network; as shown in the embodiments. Figure 1dAs shown, the blockchain network includes a witness subnetwork and a consensus subnetwork. Business nodes are deployed in the witness subnetwork, which is on the public network, while the consensus subnetwork contains ledger nodes running the blockchain consensus protocol. The witness subnetwork and the consensus subnetwork interact through a routing boundary. The business nodes in the witness subnetwork primarily execute business logic and do not participate in the ledger consensus. They obtain block header data and partially authorized block data from the consensus subnetwork through identity authentication. The consensus subnetwork is the core network of the blockchain network, used for ledger consensus. Typically, the witness subnetwork and the consensus subnetwork operate in different network environments: the witness subnetwork is on a public network, while the consensus subnetwork is on a private network. Because the consensus subnetwork is in a relatively secure private network, their mutual access is inherently secure due to the consensus mechanism, requiring no additional identity management or network control. However, business nodes are on a public network and may be accessed by other unidentified network terminals. Therefore, the access of business nodes and other potential nodes to the consensus subnetwork needs to be strictly controlled.

[0099] Taking a blockchain network as an example, which provides consensus services for electronic invoices, the schematic diagram of the two-layer network scenario architecture proposed in this application embodiment can be found here. Figure 1e .like Figure 1e As shown, the blockchain network includes a business layer, a routing proxy layer, and a core consensus network layer. These three layers constitute the complete blockchain business system. Specifically: ① The business layer resides in the witness sub-network and includes at least one business node, which can be an SPV node. The SPV node maintains a normal unstructured P2P network and can handle business such as taxation (local tax bureau), invoicing (corporate invoicing), and payment (corporate cash flow). ② The core consensus network layer resides in the consensus sub-network and includes various consensus clusters, such as consensus cluster 102, consensus cluster 103, ..., etc. Each consensus cluster maintains its own blockchain sub-chain. For example, consensus cluster 104 maintains core chain 1 within its cluster, and consensus cluster 105 maintains core chain 2 within its cluster. ③ The routing proxy layer includes at least one proxy node, which can provide routing services, authentication services, certificate caching services, and peer-to-peer (P2P) services. The certificate caching service involves a Public Key Infrastructure (PKI) certificate system. In the PKI, a certificate is proof of identity for a public key holder, issued by an authoritative authority (CA). Based on the PKI, asymmetric encryption and digital signatures of information can be implemented. The business layer and the core consensus network layer exchange information through the routing proxy layer; that is, the business layer submits business operation interactions to the core consensus network layer through the routing proxy layer. In this way, the routing proxy layer isolates the business layer from the core consensus network layer.

[0100] Based on the above description of the basic structure of the two-layer network involved in the embodiments of this application, the following is a brief introduction to the blockchain-based data processing scheme proposed in the embodiments of this application based on the above-mentioned two-layer network structure, which can improve the verification efficiency of cross-chain transactions. This scheme can be... Figure 1e The execution occurs at any business node in the business layer shown. Specifically, a business node can be a terminal device or a server carrying a trusted execution environment. Terminal devices can include, but are not limited to, smartphones (such as Android phones, iOS phones, etc.), tablets, portable personal computers, and mobile internet devices (MIDs), etc. This application embodiment does not limit this. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, etc. This application embodiment does not limit this.

[0101] It is understood that in the specific implementation of this application, the synchronization of target data (such as ticketing data) is involved. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the corresponding data acquisition permissions (such as the data synchronization permissions of the currently logged-in account on the computer device), and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0102] Figure 1f This is a schematic diagram of a data processing flow provided in an embodiment of this application. Figure 1f As shown, the general principle of the data processing scheme in the specific implementation is as follows:

[0103] (1) When a data administrator needs to encrypt and store target data, a key acquisition request is sent to the Trusted Execution Environment (TEE) in the computer device. The key acquisition request includes the ciphertext of the first key and the token of the target account. The target account is the account used by the data administrator. The ciphertext of the first key is obtained by encrypting the plaintext of the first key assigned to the target account by the TEE when the data administrator logs into the computer device for the first time using the target account. In one implementation, when the data administrator logs into the computer device for the first time using the target account, the TEE assigns a key set to the target account (i.e., one key set per account). The key set includes a first key and a second key. The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key. After assigning the key set to the target account, the TEE outputs the ciphertext of the first key so that the computer device associates and stores the target account with the ciphertext of the first key corresponding to the target account.

[0104] (2) After receiving the key acquisition request, the Trusted Execution Environment (TEE) verifies the token of the target account. If the token of the target account passes the verification, the TEE determines the plaintext of the first key based on the ciphertext of the first key; for example, it decrypts the ciphertext of the first key using the second key to obtain the plaintext of the first key. After determining the plaintext of the first key, the TEE returns the plaintext of the first key to the requester of the key acquisition request (such as memory in a computer device).

[0105] (3) After obtaining the plaintext of the first key, the computer device encrypts the target data using the plaintext of the first key to obtain the data to be verified. When the data to be verified meets the verification conditions (e.g., the number of target data reaches the quantity threshold, the exit operation of the target account is detected, the current time matches the verification period of the data to be verified, the encryption of the target data is completed, etc.), the computer device provides the data to be verified to the trusted execution environment.

[0106] (4) After obtaining the data to be verified, the trusted execution environment performs an integrity check on the data to be verified. For example, it decrypts the data to be verified using the plaintext of the first key to obtain decrypted data and checks whether the decrypted data matches the target data. If they match, the data to be verified is determined to have passed the integrity check; if they do not match, the data to be verified is determined to have failed the integrity check. If the data to be verified passes the integrity check, the trusted execution environment generates a validity certificate of the data to be verified and returns the validity certificate of the data to the requester of the key request. In one embodiment, the trusted execution environment calculates the total checksum of the data to be verified and signs the total checksum; it packages the total checksum and the signature of the total checksum into a validity certificate of the data to be verified and returns the validity certificate to the requester of the key request, so that the requester of the key request can associate and store the data to be verified and the validity certificate of the data to be verified.

[0107] Figure 1g This is a diagram illustrating an application scenario for data processing provided in an embodiment of this application. For example... Figure 1g As shown, the computer equipment is a business node in the blockchain network, and the target data is the ticketing data synchronized by the business node from the consensus subnetwork. The following section combines... Figure 1g The data processing scheme provided in this application is described in detail below:

[0108] Once the ticketing administrator obtains data synchronization permissions for the consensus subnetwork through the target account, the business node initiates the data synchronization service, retrieves the ciphertext of the first key corresponding to the target account stored in the memory, and requests the plaintext of the first key from the trusted execution environment (TEX) mounted on the business node. In one implementation, the business node sends a key retrieval request to the TEX via the data synchronization service. This request includes the ciphertext of the first key and the target account's token. Upon receiving the key retrieval request, the TEX verifies the target account's token. If the token verification is successful, the TEX determines the plaintext of the first key based on the ciphertext and returns the plaintext of the first key to the service memory of the data synchronization service.

[0109] After obtaining the plaintext of the first key, the business node synchronizes the ticketing data associated with the target account (i.e., the target data) from the blockchain network through the data synchronization service, and encrypts the synchronized ticketing data associated with the target account using the plaintext of the first key to obtain the data to be verified. When the verification conditions are met (e.g., the number of synchronized ticketing data reaches a threshold, an exit operation of the target account is detected, the current time matches the verification period of the data to be verified, the current block synchronization is completed, etc.), the data to be verified is provided to the trusted execution environment. After obtaining the data to be verified, the trusted execution environment performs integrity verification on the data to be verified; in one implementation, the trusted execution environment calculates the total checksum of the data to be verified and signs the total checksum; the total checksum and the signature of the total checksum are packaged into a validity proof of the data to be verified, and the validity proof is returned to the data synchronization service. After obtaining the validity proof of the data to be verified, the business node associates and stores the data to be verified, the validity proof of the data to be verified, and the ciphertext of the first key. This allows the ticketing administrator to verify the data to be verified using the validity proof of the data to be verified in subsequent use. The plaintext of the first key is obtained through the ciphertext of the first key, and the verified data to be verified is then decrypted using the plaintext of the first key to obtain the ticketing data.

[0110] It's important to note that in a blockchain context, the target account can specifically be an SPVID. An SPVID is the ID registered by the ticketing administrator within the blockchain network, and its identity can be verified. Furthermore, the SPVID can be used to locate related transaction records within the blockchain network. When verifying data to be verified, the trusted execution environment includes checking whether the data matches the transaction records in the blockchain network. If they match, it can be determined that the synchronized data to be verified is ticketing data that has passed consensus within the blockchain network.

[0111] In this embodiment, a key acquisition request is obtained. This request includes the target account's token and the ciphertext of the target account's first key. If the target account's token is verified, the plaintext of the first key is determined based on the ciphertext and returned to the requester. Verification data is then obtained; this data is obtained by encrypting the target data using the plaintext of the first key. Integrity verification is performed on the verification data. If the verification data passes the integrity verification, a validity certificate is returned to the requester. Therefore, encrypting the target data using the plaintext of the first key reduces the risk of target data leakage; generating a validity certificate for the verification data better ensures the integrity and validity of the target data, thereby improving data security.

[0112] Based on the data processing scheme described above, this application proposes a more detailed blockchain-based data processing method. The data processing method proposed in this application will be described in detail below with reference to the accompanying drawings.

[0113] Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of this application. This data processing method can be... Figure 1e The trusted execution environment in any business node of the business layer shown executes the commands. For example... Figure 2 As shown, the data processing method may include, but is not limited to, steps S201-S204:

[0114] S201, Obtain Key Acquisition Request.

[0115] The key acquisition request includes the ciphertext of the first key and the token of the target account. The target account is the account used by the data administrator. The ciphertext of the first key is obtained by encrypting the plaintext of the first key assigned to the target account when the data administrator first logs into the computer device using the target account. After obtaining the ciphertext of the first key, the trusted execution environment outputs the ciphertext of the first key so that the business nodes (i.e., the computer devices) can associate and store the ciphertext of the first key with the target account. This allows business nodes logged into with the target account to provide the ciphertext of the first key to the trusted execution environment to retrieve the plaintext of the first key when they need to use it (e.g., to encrypt target data or to decrypt data to be verified).

[0116] In one implementation, when a data administrator logs into a computer device for the first time using a target account, the Trusted Execution Environment (TEE) assigns a key set to the target account. It is understood that in the TEE, one account corresponds to one key set, and the key set includes a first key and a second key. In one embodiment, the ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key.

[0117] S202. If the token verification of the target account is successful, determine the plaintext of the first key based on the ciphertext of the first key, and return the plaintext of the first key to the requester who made the key acquisition request.

[0118] After receiving a key acquisition request, the Trusted Execution Environment (TEE) verifies the target account's token; for example, it verifies whether the token is currently valid. If the target account's token passes verification, the TEE determines the plaintext of the first key based on the ciphertext of the first key; for example, it decrypts the ciphertext of the first key using a second key to obtain the plaintext. After determining the plaintext of the first key, the TEE returns the plaintext of the first key to the requester (such as memory in a computer device). Alternatively, the ciphertext and plaintext of the first key can be stored together in the TEE; after obtaining the ciphertext, the TEE can find and confirm the corresponding plaintext of the first key. Conversely, if the target account's token fails verification, the TEE outputs a token notification message indicating that the target account's token is invalid, and a new token must be provided for verification if the plaintext of the first key is required.

[0119] In one implementation, the plaintext of the first key returned by the trusted execution environment is stored in the memory of the target service (such as a data synchronization service used to synchronize target data, i.e., the requester of the key acquisition request is the data synchronization service). It is used only for encrypting the target data and is not exposed externally. In other words, the data administrator of the target account cannot obtain the plaintext of the first key from the business nodes. Therefore, whenever the plaintext of the first key is needed (such as encrypting target data or decrypting data to be verified), it must be obtained from the trusted execution environment, further reducing the risk of target data leakage and improving the security of the target data.

[0120] S203. Obtain the data to be verified.

[0121] The data to be verified is obtained by encrypting the target data using the plaintext of the first key, as requested by the key acquisition requester (such as a business node). In one implementation, after obtaining the plaintext of the first key, the computer device encrypts the target data using the plaintext of the first key to obtain the data to be verified; wherein, the target data can be data input by the data administrator or data synchronized by the data administrator from the network (such as a blockchain). When the data to be verified meets the verification conditions (e.g., the quantity of target data reaches a quantity threshold, an exit operation of the target account is detected, the current time matches the verification period of the data to be verified, the encryption of the target data is completed, etc.), the computer device provides the data to be verified to the trusted execution environment.

[0122] S204. Perform integrity verification on the data to be verified. If the data to be verified passes the integrity verification, return the validity certificate of the data to be verified to the requester who made the key acquisition request.

[0123] After acquiring the data to be verified, the Trusted Execution Environment performs an integrity check on the data. For example, it decrypts the data to be verified using the plaintext of the first key to obtain the decrypted data and checks whether the decrypted data matches the target data. If they match, the data to be verified is determined to have passed the integrity check; if they do not match, the data to be verified is determined to have failed the integrity check.

[0124] If the data to be verified passes the integrity check, the Trusted Execution Environment (TEE) generates a validity certificate for the data and returns it to the requester of the key request. In one implementation, the TEE calculates a checksum of the data to be verified and signs the checksum; it then packages the checksum and its signature into a validity certificate and returns it to the requester of the key request, enabling the requester to associate and store the data to be verified and its validity certificate.

[0125] In this embodiment, a key acquisition request is obtained. This request includes the target account's token and the ciphertext of the target account's first key. If the target account's token is verified, the plaintext of the first key is determined based on the ciphertext and returned to the requester. Verification data is then obtained; this data is obtained by encrypting the target data using the plaintext of the first key. Integrity verification is performed on the verification data. If the verification data passes the integrity verification, a validity certificate is returned to the requester. Therefore, encrypting the target data using the plaintext of the first key reduces the risk of target data leakage; generating a validity certificate for the verification data better ensures the integrity and validity of the target data, thereby improving data security.

[0126] Figure 3 This is a flowchart illustrating another data processing method provided in an embodiment of this application. This data processing method can be... Figure 1e The trusted execution environment in any business node of the business layer shown executes the commands. For example... Figure 3 As shown, the data processing method may include, but is not limited to, steps S301-S307:

[0127] S301. Obtain login information.

[0128] The login information includes the identifier and token of the target account. In one implementation, the login information is used to log in to the blockchain network; in another implementation, the ticketing administrator logs in to the blockchain network using an ID already registered on the blockchain network (such as an SPVID) and a login authorization code for the SPVID within a limited time (i.e., the target account's token). Specifically, the blockchain network can refer to... Figure 1d The consensus subnetwork in the two-layer network shown.

[0129] During the login process described above, the login information is also provided to the trusted execution environment in the business nodes; for example, the login information is provided to the trusted execution environment through the data synchronization service.

[0130] S302. If the token verification of the target account is successful, assign a key group to the target account.

[0131] After obtaining login information, the Trusted Execution Environment (TEE) verifies the token of the target account. In one implementation, the TEE has a built-in authentication service that can perform asymmetric key verification on the target account's token. The authentication service can perform asymmetric key verification on the target account's token by: detecting whether the current time belongs to the validity period of the target account's token using an asymmetric key; if the current time belongs to the validity period of the target account's token, the target account's token is determined to have passed verification; if the current time does not belong to the validity period of the target account's token, the target account's token is determined to have failed verification.

[0132] Upon successful token verification of the target account, a key set is assigned to the target account. It is understood that in a trusted execution environment (TEE), each account corresponds to one key set. In one implementation, the key set includes a first key and a second key. The TEE uses the second key to encrypt the plaintext of the first key, obtaining the ciphertext of the first key. In one embodiment, the encryption algorithm associated with the first key may be the SM4 algorithm.

[0133] S303. Return the ciphertext of the first key to the provider of the login information.

[0134] After obtaining the ciphertext of the first key, the Trusted Execution Environment (TEE) outputs the ciphertext of the first key so that business nodes can associate and store the target account and the ciphertext of the first key. This allows business nodes logged into with the target account to provide the ciphertext of the first key to the TEE when they need to use the plaintext of the first key (such as when they need to use the plaintext of the first key to encrypt target data or when they need to use the plaintext of the first key to decrypt data to be verified).

[0135] S304, Obtain Key Acquisition Request.

[0136] For a detailed implementation of step S304, please refer to Figure 2 The implementation method of step S201 will not be described in detail here.

[0137] S305. If the token verification of the target account is successful, obtain the second key associated with the ciphertext of the first key, and use the second key to decrypt the ciphertext of the first key to obtain the plaintext of the first key.

[0138] After receiving the key acquisition request, the Trusted Execution Environment (TEE) verifies the token of the target account. For a detailed implementation of the token verification process, please refer to the implementation of asymmetric key verification for the target account's token in step S302; it will not be repeated here.

[0139] If the token verification for the target account is successful, the Trusted Execution Environment (TEE) obtains a second key associated with the ciphertext of the first key. In one implementation, the TEE generates the second key associated with the ciphertext of the first key based on the target account's identifier and preset parameters (such as the serial number of the computer device's memory stored in the TEE, the TEE's certificate number, and other internal specific parameters). In other words, the TEE does not need to store the second key associated with the ciphertext of the first key, thus saving storage space.

[0140] After obtaining the second key associated with the ciphertext of the first key, the trusted execution environment uses the second key associated with the ciphertext of the first key to decrypt the ciphertext of the first key, obtain the plaintext of the first key, and returns the plaintext of the first key to the provider of the key acquisition request.

[0141] S306. Obtain the data to be verified.

[0142] For a detailed implementation of step S306, please refer to Figure 2 The implementation method of step S203 will not be described in detail here.

[0143] In one embodiment, during the process of the provider of the key acquisition request generating the data to be verified, the trusted execution environment can periodically verify the token of the target account. Specifically, it checks whether the current time is within the validity period of the target account's token; if the current time is within the validity period of the target account's token, it acquires the data to be verified and continues to execute the subsequent step S307; if the current time is not within the validity period of the target account's token, it sends a renewal notification to the requester of the key acquisition request of the target account, so that the requester of the key acquisition request of the target account can provide a new token; furthermore, if the requester of the key acquisition request of the target account cannot provide a new valid token, the current operation ends.

[0144] S307. Perform integrity verification on the data to be verified. If the data to be verified passes the integrity verification, return the validity certificate of the data to be verified to the requester of the key acquisition request.

[0145] The data to be verified is obtained by encrypting the target data using the plaintext of the first key by the requester of the key acquisition request.

[0146] In one implementation, the target data is data associated with itself (such as ticketing data, transaction data, etc.) synchronized from the blockchain network by the requester of the key acquisition request; that is, the target data is obtained by synchronizing data in the blockchain network. The data to be verified is sent to the trusted execution environment by the requester of the key acquisition request when it detects an exit operation of the target account.

[0147] On one hand, the trusted execution environment decrypts the plaintext of the first key into the data to be verified, obtaining the target data. The target data is then compared with the data in the blockchain associated with the requester who made the key acquisition request to determine the integrity of the data to be verified. Specifically, if the target data matches the data in the blockchain associated with the requester who made the key acquisition request, the data to be verified passes the integrity check; if the target data does not match the data in the blockchain associated with the requester who made the key acquisition request, the data to be verified fails the integrity check.

[0148] If the data to be verified passes the integrity check, the Trusted Execution Environment (TEE) calculates the checksum of the data and signs it to obtain the associated signature data. Based on the checksum and the associated signature data, the TEE generates a validity certificate for the data to be verified; for example, it packages the checksum and the associated signature data into a validity certificate. The validity certificate may also include information such as the generation time. After obtaining the validity certificate, the TEE returns it to the requester of the key acquisition request, enabling the requester to associate and store the data to be verified with the validity certificate.

[0149] On the other hand, when the requester of the key acquisition request for the target account detects that the target account has logged out of the blockchain network, it provides the target account's token to the trusted execution environment. The trusted execution environment obtains the target account's token and invalidates it, that is, it sets the target account's current token to invalid. In other words, in the scenario of synchronizing blockchain data, the token used by the same object to log in to the blockchain network each time is different. It can be seen that using dynamically changing tokens to authenticate objects can further improve data security.

[0150] The following section uses tax data from a blockchain network as an example to illustrate the data processing method provided in this application:

[0151] (1) The invoice clerk logs in to the SPV node (tax management terminal) using the target account (SPVID) and the target account's token (Auth Token). The SPVID is a unique ID of the invoice clerk that has been registered on the blockchain; the Auth Token is a login authorization code with a limited time.

[0152] (2) After login, the SPV node transmits the SPVID and AuthToken to the key generation service of the Trusted Execution Environment (TEE) through the data synchronization service. The TEE has built-in asymmetric key verification for the AuthToken, which can verify the AuthToken. After the AuthToken is verified, the TEE initializes a set of keys for the SPVID, namely the data encryption key (Key1) and the key encryption key (Key2). Key1 is used to encrypt the invoice data synchronized from the blockchain network, and Key2 is used to encrypt Key1. Key2 is generated by combining specific parameters inside the TEE with the SPVID and is not stored outside the TEE. After Key1 is encrypted by Key2, it is stored on the local disk of the SPV node.

[0153] (3) During the subsequent SPV node startup process, the plaintext of Key1 is first obtained from TEE using AuthToken and stored in the memory of the data synchronization service. After synchronizing the on-chain invoice data related to itself, the invoice data is encrypted using Key1 before being stored.

[0154] (4) AuthTokens may expire during use; for example, the validity period of an AuthToken is 2 hours; or the AuthToken expires when the target account logs out. Therefore, AuthTokens need to be renewed regularly.

[0155] (5) When the SPV node detects the logout operation of the currently logged-in SPVID, it first destroys Key1 in memory. After completing the preparations before logout, it sends the AuthToken to the logout program in the TEE. At this time, the TEE logout program performs the following steps:

[0156] (5.1) Set the AuthToken to be invalid for the TEE during its validity period, that is, invalidate the AuthToken.

[0157] (5.2) Perform integrity verification on the data to be verified, and calculate the checksum of the data to be verified (obtained by encrypting the invoice data in plaintext using Key1) after the integrity verification passes. TEE provides a signature for the checksum and combines the checksum and signature into a validity certificate, which is stored in the SPV node as a file.

[0158] (5.3) Check whether the data to be verified has been stored in the SPV node.

[0159] (6) After step (5) is completed, the current invoice issuer can log out. The data to be verified is stored in the SPV node after being securely encrypted. In addition, the SPV node also includes the integrity proof of the data to be verified, the ciphertext of Key1, etc. When the current invoice issuer logs in again, after the AuthToken is verified by the TEE, the data to be verified can be reused after checking the integrity of this part of the data.

[0160] (7) The new invoice clerk initializes through TEE via steps (1)-(5) and uses the encrypted data space corresponding to their own account.

[0161] In this embodiment, a key acquisition request is obtained. This request includes the target account's token and the ciphertext of the target account's first key. If the target account's token is verified, the plaintext of the first key is determined based on the ciphertext and returned to the requester. Verification data is then obtained; this data is obtained by encrypting the target data using the plaintext of the first key. Integrity verification is performed on the verification data. If the verification data passes the integrity verification, a validity certificate is returned to the requester. Therefore, encrypting the target data using the plaintext of the first key reduces the risk of target data leakage; generating a validity certificate for the verification data better ensures the integrity and validity of the target data, thereby improving data security.

[0162] Figure 4 This is a flowchart illustrating another data processing method provided in an embodiment of this application. This data processing method can be... Figure 1e Execution in memory within any business node of the business layer shown. For example... Figure 4 As shown, the data processing method may include, but is not limited to, steps S401-S406:

[0163] S401. Send login information to the trusted execution environment.

[0164] The login information includes the identifier and token of the target account. In one implementation, the login information is used to log in to the blockchain network to obtain data synchronization permissions within the blockchain network.

[0165] S402, Receive the ciphertext of the first key returned by the trusted execution environment.

[0166] The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key. Both the first and second keys are generated by the Trusted Execution Environment (TEE) based on the target account's identifier. For details on how the TEE assigns the first and second keys to the target account based on its identifier, please refer to [link to relevant documentation]. Figure 3The implementation method of step S302 will not be described in detail here.

[0167] In one implementation, after receiving the ciphertext of the first key, the service node associates and stores the identifier of the target account with the ciphertext of the first key.

[0168] S403. Send a key acquisition request to the trusted execution environment.

[0169] When the plaintext of the first key is needed (for example, when target data needs to be stored in encrypted form, or when data to be verified needs to be decrypted), a key retrieval request is sent to the trusted execution environment. The key retrieval request includes the target account's token and the ciphertext of the target account's first key.

[0170] S404. Receive the plaintext of the first key returned by the trusted execution environment, and encrypt the target data using the plaintext of the first key to obtain the data to be verified.

[0171] The plaintext of the first key is returned to the memory of the business node by the trusted execution environment after the target account's token verification is successful. The encryption algorithm for the target data may include, but is not limited to, SM4, DES, RSA, etc., and this application does not impose any restrictions on this.

[0172] S405. Send the data to be verified to the trusted execution environment.

[0173] When the verification conditions are met, the data to be verified is provided to the trusted execution environment so that the trusted execution environment can verify the data to be verified. The verification conditions may include: the amount of ticketing data synchronized from the blockchain network reaches a certain threshold, an exit operation of the target account is detected, the current time period matches the verification period of the data to be verified, and the current block synchronization is completed.

[0174] In one implementation, when a business node detects an exit operation of a target account, the business node also provides the target account's token to the trusted execution environment so that the trusted execution environment can invalidate the target account.

[0175] S406. If the data to be verified passes the integrity check, the validity certificate of the data to be verified returned by the trusted execution environment is received, and the data to be verified and the validity certificate of the data to be verified are stored together.

[0176] The validity certificate of the data to be verified is returned to the memory of the business node by the trusted execution environment after the data to be verified has passed integrity verification. After receiving the validity certificate of the data to be verified from the trusted execution environment, the business node associates and stores the data to be verified and the validity certificate together.

[0177] Furthermore, when the target data is needed subsequently, the integrity of the data to be verified is checked using the validity proof of the data to be verified. Specifically, the validity proof includes a first total checksum of the data to be verified and a signature of the trusted execution environment. First, the trustworthiness of the first total checksum is verified using the signature of the trusted execution environment. If the first total checksum is trustworthy, it is compared with a second total checksum calculated from the data to be verified. If the first and second total checksums match, the data to be verified is determined to have passed the integrity check. Conversely, if the first total checksum is untrustworthy, or if the first and second total checksums do not match, the data to be verified is determined to have failed the integrity check. If the target data is synchronized from the blockchain network, the target object can be prompted to resynchronize the required data from the blockchain network.

[0178] If the data to be verified passes the integrity check, the plaintext of the first key is obtained. The specific method for obtaining the plaintext of the first key is described in steps S403 and S404, and will not be repeated here. The plaintext of the first key is then used to decrypt the data to be verified to obtain the target data.

[0179] In this embodiment, a key acquisition request is sent to the trusted execution environment (TEE). The request includes the target account's token and the ciphertext of the target account's first key. If the target account's token is verified, the plaintext of the first key returned by the TEE is received. The target data is then encrypted using the plaintext of the first key to obtain the data to be verified. This data is provided to the TEE so that the TEE can perform integrity verification. If the data to be verified passes the integrity verification, the validity proof of the data to be verified returned by the TEE is received, and the data to be verified and its validity proof are stored together. Therefore, encrypting the target data using the plaintext of the first key reduces the risk of target data leakage; and verifying the data to be verified using the generated validity proof effectively ensures the integrity and validity of the target data.

[0180] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above solutions of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0181] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. The device can be mounted on a computer device, which can be a business node in a blockchain network. Figure 5 The data processing apparatus shown can be used to perform the above. Figure 2 and Figure 3Some or all of the functionality described in the method embodiments. Please refer to [link / reference]. Figure 5 The detailed descriptions of each unit are as follows:

[0182] The acquisition unit 501 is used to acquire a key acquisition request, which includes the token of the target account and the ciphertext of the first key of the target account;

[0183] Processing unit 502 is configured to determine the plaintext of the first key based on the ciphertext of the first key when the token verification of the target account is successful, and return the plaintext of the first key to the requester of the key acquisition request.

[0184] The acquisition unit 501 is also used to acquire data to be verified, which is obtained by encrypting the target data using the plaintext of the first key by the requester of the key acquisition request.

[0185] The processing unit 502 is also used to perform integrity verification on the data to be verified. If the data to be verified passes the integrity verification, it returns a proof of the validity of the data to be verified to the requester of the key acquisition request.

[0186] In one embodiment, the processing unit 502 is further configured to:

[0187] Obtain login information, including the target account's identifier and the target account's token;

[0188] If the token verification of the target account is successful, a key set is assigned to the target account, which includes a first key and a second key.

[0189] Return the ciphertext of the first key to the provider of the login information. The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key.

[0190] In one implementation, the processing unit 502 is configured to determine the plaintext of the first key based on the ciphertext of the first key, specifically for:

[0191] Obtain the second key associated with the ciphertext of the first key;

[0192] The ciphertext of the first key is decrypted using the second key to obtain the plaintext of the first key.

[0193] In one implementation, the data processing method is executed in a trusted execution environment within a computer device, and the processing unit 502 is configured to obtain a second key associated with the ciphertext of the first key, specifically for:

[0194] Based on the target account's identifier and preset parameters, generate a second key that is associated with the ciphertext of the first key;

[0195] The preset parameters include: the serial number of the computer device stored in the trusted execution environment.

[0196] In one implementation, the processing unit 502 is configured to return a validity certificate of the data to be verified to the requester of the key acquisition request, specifically configured to:

[0197] Calculate the total checksum of the data to be verified;

[0198] Sign the total checksum to obtain the signature data associated with the total checksum;

[0199] Based on the total checksum and the signature data associated with the total checksum, a validity proof of the data to be verified is generated;

[0200] Return a proof of the validity of the data to be verified to the requester of the key acquisition request, so that the requester can associate and store the data to be verified and the proof of validity.

[0201] In one embodiment, the processing unit 502 is further configured to:

[0202] Check if the token currently belongs to the target account's validity period;

[0203] If the current time does not fall within the validity period of the target account's token, a renewal notification is sent to the party that requested the key acquisition request for the target account, so that the party that requested the key acquisition request for the target account can provide a new token.

[0204] In one implementation, the target data is obtained by synchronizing the data in the blockchain network after the target account logs in; the processing unit 502 is further configured to:

[0205] Obtain the target account's token, which is provided by the requester of the target account's key retrieval request when it detects that the target account has logged out of the blockchain network;

[0206] Invalidate the token of the target account.

[0207] According to one embodiment of this application, Figure 2 and Figure 3 The data processing method shown may involve some steps that can be derived from... Figure 5 The data processing apparatus shown is executed by each unit within it. For example, Figure 2 Steps S201 and S203 shown can be derived from... Figure 5 The acquisition unit 501 shown is executed, and steps S202 and S204 can be performed by... Figure 5 The processing unit 502 shown executes the operation; Figure 3 Steps S301, S304, and S306 shown can be derived from... Figure 5 The acquisition unit 501 shown is executed, and steps S302, S303, S305, and S307 can be performed by... Figure 5 The processing unit 502 shown is executed. Figure 5 The data processing apparatus shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above-mentioned units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data processing apparatus may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0208] According to another embodiment of this application, the following can be executed by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM). Figure 2 and Figure 3 The computer program (including program code) involved in each step of the corresponding method shown, to construct such... Figure 5 The data processing apparatus shown herein, and the data processing method for implementing the embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and executed therein.

[0209] Based on the same inventive concept, the principle and beneficial effects of the data processing device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data processing method in the embodiments of this application in solving the problem. For the sake of brevity, the principle and beneficial effects of the method implementation can be referred to.

[0210] Please see Figure 6 , Figure 6 This is a schematic diagram of another data processing device provided in an embodiment of this application. The device can be mounted on a computer device, which can be a business node in a blockchain network. Figure 6 The data processing apparatus shown can be used to perform the above. Figure 4 Some or all of the functionality described in the method embodiments. Please refer to [link / reference]. Figure 6 The detailed descriptions of each unit are as follows:

[0211] Processing unit 601 is used to send a key acquisition request to a trusted execution environment. The key acquisition request includes the token of the target account and the ciphertext of the first key of the target account.

[0212] The receiving unit 602 is used to receive the plaintext of the first key returned by the trusted execution environment when the token verification of the target account is successful, and to encrypt the target data using the plaintext of the first key to obtain the data to be verified.

[0213] The processing unit 601 is also configured to provide data to be verified to the trusted execution environment so that the trusted execution environment can perform integrity verification on the data to be verified.

[0214] The receiving unit 602 is also configured to receive the validity certificate of the data to be verified returned by the trusted execution environment if the data to be verified passes the integrity check.

[0215] The processing unit 601 is also used to associate and store the validity proof of the data to be verified with the data to be verified.

[0216] In one embodiment, the processing unit 601 is further configured to:

[0217] The validity of the data to be verified proves that the data to be verified is being validated for its integrity.

[0218] If the data to be verified passes the integrity check, the plaintext of the first key is used to decrypt the data to be verified to obtain the target data.

[0219] In one embodiment, the processing unit 601 is further configured to:

[0220] Send login information to the trusted execution environment. The login information includes the identifier of the target account and the token of the target account.

[0221] Receive the ciphertext of the first key returned by the trusted execution environment;

[0222] The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key. The first key and the second key are generated by the trusted execution environment based on the identifier of the target account.

[0223] According to one embodiment of this application, Figure 4 The data processing method shown may involve some steps that can be derived from... Figure 6 The data processing apparatus shown is executed by each unit within it. For example, Figure 4 Steps S401, S403, and S405 shown can be derived from... Figure 6 The processing unit 601 shown executes the step S402, which can be performed by... Figure 6 The receiving unit 602 shown executes the steps S404 and S406, which can be performed by... Figure 6 The processing unit 601 and the receiving unit 602 shown cooperate in execution. Figure 6 The data processing apparatus shown can be constructed by combining each unit individually or entirely into one or more other units, or one or more of the units can be further divided into multiple functionally smaller units. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above-mentioned units are based on logical function division. In practical applications, the function of one unit can be implemented by multiple units, or the function of multiple units can be implemented by one unit. In other embodiments of this application, the data processing apparatus may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented collaboratively by multiple units.

[0224] According to another embodiment of this application, the following can be executed by running on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a central processing unit (CPU), random access memory (RAM), and read-only memory (ROM). Figure 4 The computer program (including program code) involved in each step of the corresponding method shown, to construct such... Figure 6 The data processing apparatus shown herein, and the data processing method for implementing the embodiments of this application, are described. A computer program may be recorded on, for example, a computer-readable recording medium, loaded onto the aforementioned computing device via the computer-readable recording medium, and executed therein.

[0225] Based on the same inventive concept, the principle and beneficial effects of the data processing device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data processing method in the embodiments of this application in solving the problem. For the sake of brevity, the principle and beneficial effects of the method implementation can be referred to.

[0226] Please see Figure 7 , Figure 7 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 7As shown, the computer device includes at least a processor 701, a communication interface 702, and a memory 703. The processor 701, communication interface 702, and memory 703 can be connected via a bus or other means. The processor 701 (or Central Processing Unit, CPU) is the computing and control core of the terminal. It can parse various instructions within the terminal and process various types of data. For example, the CPU can parse power-on / off commands sent to the terminal and control the terminal to perform power-on / off operations; it can also transmit various interactive data between internal structures within the terminal, and so on. The communication interface 702 can optionally include standard wired interfaces and wireless interfaces (such as Wi-Fi, mobile communication interfaces, etc.), and can be used to send and receive data under the control of the processor 701; the communication interface 702 can also be used for data transmission and interaction within the terminal. The memory 703 is the memory device in the terminal, used to store programs and data. It can be understood that the memory 703 here can include the terminal's built-in memory, or it can include extended memory supported by the terminal. The memory 703 provides storage space for storing the terminal's operating system, which may include, but is not limited to, Android, iOS, Windows Phone, etc. This application does not limit this.

[0227] This application embodiment also provides a computer-readable storage medium (Memory), which is a memory device in a terminal used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the terminal and extended storage media supported by the terminal. The computer-readable storage medium provides storage space that stores the terminal's processing system. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by the processor 701, which can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device; optionally, it can also be at least one computer-readable storage medium located remotely from the aforementioned processor.

[0228] In one embodiment, processor 701 performs the following operations by running executable program code in memory 703:

[0229] Obtain a key retrieval request, which includes the target account's token and the ciphertext of the target account's first key;

[0230] If the token verification of the target account is successful, the plaintext of the first key is determined based on the ciphertext of the first key, and the plaintext of the first key is returned to the requester who requested the key acquisition request.

[0231] Obtain the data to be verified, which is obtained by encrypting the target data using the plaintext of the first key by the requester of the key acquisition request;

[0232] The integrity of the data to be verified is checked. If the data passes the integrity check, the validity of the data is returned to the requester who requested the key acquisition request.

[0233] As an optional embodiment, the processor 701, by running the executable program code in the memory 703, also performs the following operations:

[0234] Obtain login information, including the target account's identifier and the target account's token;

[0235] If the token verification of the target account is successful, a key set is assigned to the target account, which includes a first key and a second key.

[0236] Return the ciphertext of the first key to the provider of the login information. The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key.

[0237] As an optional embodiment, the processor 701 determines the plaintext of the first key based on the ciphertext of the first key in the following specific embodiment:

[0238] Obtain the second key associated with the ciphertext of the first key;

[0239] The ciphertext of the first key is decrypted using the second key to obtain the plaintext of the first key.

[0240] As an optional embodiment, the data processing method is executed in a trusted execution environment in a computer device, and the specific embodiment in which the processor 701 obtains the second key associated with the ciphertext of the first key is as follows:

[0241] Based on the target account's identifier and preset parameters, generate a second key that is associated with the ciphertext of the first key;

[0242] The preset parameters include: the serial number of the computer device stored in the trusted execution environment.

[0243] As an optional embodiment, the processor 701 returns a proof of the validity of the data to be verified to the requester of the key acquisition request as follows:

[0244] Calculate the total checksum of the data to be verified;

[0245] Sign the total checksum to obtain the signature data associated with the total checksum;

[0246] Based on the total checksum and the signature data associated with the total checksum, a validity proof of the data to be verified is generated;

[0247] Return a proof of the validity of the data to be verified to the requester of the key acquisition request, so that the requester can associate and store the data to be verified and the proof of validity.

[0248] As an optional embodiment, the processor 701, by running the executable program code in the memory 703, also performs the following operations:

[0249] Check if the token currently belongs to the target account's validity period;

[0250] If the current time does not fall within the validity period of the target account's token, a renewal notification is sent to the party that requested the key acquisition request for the target account, so that the party that requested the key acquisition request for the target account can provide a new token.

[0251] As an optional embodiment, the target data is obtained by synchronizing the data in the blockchain network after the target account logs in; the processor 701 also performs the following operations by running the executable program code in the memory 703:

[0252] Obtain the target account's token, which is provided by the requester of the target account's key retrieval request when it detects that the target account has logged out of the blockchain network;

[0253] Invalidate the token of the target account.

[0254] In another embodiment, processor 801 performs the following operations by running executable program code in memory 803:

[0255] Send a key retrieval request to the trusted execution environment. The key retrieval request includes the target account's token and the ciphertext of the target account's first key.

[0256] If the token verification of the target account is successful, the plaintext of the first key returned by the trusted execution environment is received, and the target data is encrypted using the plaintext of the first key to obtain the data to be verified.

[0257] Provide the data to be verified to the trusted execution environment so that the trusted execution environment can perform integrity verification on the data to be verified.

[0258] If the data to be verified passes the integrity check, the system receives the validity certificate of the data to be verified returned by the trusted execution environment and stores the data to be verified and the validity certificate of the data to be verified together.

[0259] As an optional embodiment, the processor 801, by running executable program code in the memory 803, also performs the following operations:

[0260] The validity of the data to be verified proves that the data to be verified is being validated for its integrity.

[0261] If the data to be verified passes the integrity check, the plaintext of the first key is used to decrypt the data to be verified to obtain the target data.

[0262] As an optional embodiment, the processor 801, by running executable program code in the memory 803, also performs the following operations:

[0263] Send login information to the trusted execution environment. The login information includes the identifier of the target account and the token of the target account.

[0264] Receive the ciphertext of the first key returned by the trusted execution environment;

[0265] The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key. The first key and the second key are generated by the trusted execution environment based on the identifier of the target account.

[0266] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data processing method in the embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the method implementation. For the sake of brevity, they will not be repeated here.

[0267] This application also provides a computer-readable storage medium storing one or more instructions, which are adapted to be loaded by a processor and executed by the data processing method described in the above-described method embodiments.

[0268] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to execute the data processing method described in the above method embodiments.

[0269] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data processing method described above.

[0270] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0271] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0272] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0273] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art will understand that all or part of the processes for implementing the above embodiments and equivalent variations made in accordance with the claims of this application are still within the scope of this application.

Claims

1. A data processing method, characterized in that, The method is performed by a trusted execution environment in a computer device, and the method includes: Obtain a key acquisition request sent from the memory of a computer device, the key acquisition request including a token of the target account and the ciphertext of a first key of the target account; If the token verification of the target account is successful, the plaintext of the first key is determined based on the ciphertext of the first key, and the plaintext of the first key is returned to the memory in the computer device. The computer device obtains the data to be verified sent from its memory, wherein the data to be verified is obtained by encrypting the target data in plaintext using the first key from the memory of the computer device. The integrity of the data to be verified is checked. If the data to be verified passes the integrity check, a proof of the validity of the data to be verified is returned to the memory of the computer device.

2. The method as described in claim 1, characterized in that, The method further includes: Obtain login information sent from the memory of the computer device, the login information including the identifier of the target account and the token of the target account; If the token verification of the target account is successful, a key group is assigned to the target account, the key group including a first key and a second key; The ciphertext of the first key is returned to the memory of the computer device, the ciphertext of the first key being obtained by encrypting the plaintext of the first key using the second key.

3. The method as described in claim 1, characterized in that, Determining the plaintext of the first key based on its ciphertext includes: Obtain the second key associated with the ciphertext of the first key; The ciphertext of the first key is decrypted using the second key to obtain the plaintext of the first key.

4. The method as described in claim 3, characterized in that, The step of obtaining the second key associated with the ciphertext of the first key includes: Based on the identifier of the target account and preset parameters, a second key is generated that is associated with the ciphertext of the first key; The preset parameters include: the serial number of the computer device stored in the trusted execution environment.

5. The method as described in claim 1, characterized in that, The proof of validity of returning the data to be verified to the memory in the computer device includes: Calculate the total checksum of the data to be verified; Sign the total check code to obtain the signature data associated with the total check code; Based on the total checksum and the signature data associated with the total checksum, a validity proof of the data to be verified is generated; The validity proof of the data to be verified is returned to the memory in the computer device, so that the memory in the computer device stores the data to be verified and the validity proof together.

6. The method as described in claim 1, characterized in that, The method further includes: Detect whether the token currently belongs to the target account is within its validity period; If the current time does not belong to the validity period of the token of the target account, a renewal notification is sent to the memory in the computer device so that the memory in the computer device can provide a new token.

7. The method as described in claim 1, characterized in that, The target data is obtained by synchronizing data in the blockchain network after the target account logs in; the method further includes: Obtain the token of the target account, which is provided by the memory in the computer device when it detects that the target account has logged out of the blockchain network; The token of the target account is invalidated.

8. A data processing method, characterized in that, The method is executed by memory in a computer device, and the method includes: Send a key acquisition request to a trusted execution environment in a computer device, the key acquisition request including a token of a target account and the ciphertext of a first key of the target account; If the token verification of the target account is successful, the plaintext of the first key returned by the trusted execution environment is received, and the target data is encrypted using the plaintext of the first key to obtain the data to be verified. The data to be verified is provided to the trusted execution environment so that the trusted execution environment performs integrity verification on the data to be verified. If the data to be verified passes the integrity check, the validity certificate of the data to be verified returned by the trusted execution environment is received, and the data to be verified and the validity certificate of the data to be verified are stored together.

9. The method as described in claim 8, characterized in that, The method further includes: The integrity of the data to be verified is checked by proving the validity of the data to be verified. If the data to be verified passes the integrity check, the plaintext of the first key is used to decrypt the data to be verified to obtain the target data.

10. The method as described in claim 8, characterized in that, The method further includes: Send login information to the trusted execution environment, the login information including the identifier of the target account and the token of the target account; Receive the ciphertext of the first key returned by the trusted execution environment; The ciphertext of the first key is obtained by encrypting the plaintext of the first key using the second key, and the first key and the second key are generated by the trusted execution environment based on the identifier of the target account.

11. A data processing apparatus, characterized in that, The data processing device is mounted in the trusted execution environment of the computer device, and the data processing device includes: The acquisition unit is configured to acquire a key acquisition request sent from the memory of the computer device, wherein the key acquisition request includes a token of the target account and the ciphertext of a first key of the target account; The processing unit is configured to, upon successful token verification of the target account, determine the plaintext of the first key based on the ciphertext of the first key, and return the plaintext of the first key to the memory in the computer device. The acquisition unit is further configured to acquire the data to be verified sent by the memory in the computer device, wherein the data to be verified is obtained by encrypting the target data in the memory of the computer device using the plaintext of the first key; The processing unit is further configured to perform integrity verification on the data to be verified, and if the data to be verified passes the integrity verification, return a proof of the validity of the data to be verified to the memory in the computer device.

12. A data processing apparatus, characterized in that, The data processing device is mounted in the memory of the computer device, and the data processing device includes: A processing unit is configured to send a key acquisition request to a trusted execution environment in a computer device, the key acquisition request including a token of a target account and the ciphertext of a first key of the target account; The receiving unit is configured to receive the plaintext of the first key returned by the trusted execution environment when the token verification of the target account is successful, and encrypt the target data using the plaintext of the first key to obtain the data to be verified. The processing unit is further configured to provide the data to be verified to the trusted execution environment, so that the trusted execution environment can perform integrity verification on the data to be verified. The receiving unit is further configured to receive the validity proof of the data to be verified returned by the trusted execution environment if the data to be verified passes the integrity check. The processing unit is also used to associate and store the data to be verified and the validity proof of the data to be verified.

13. A computer device, characterized in that, include: Storage devices and processors; A memory, wherein a computer program is stored; A processor is configured to load the computer program to implement the data processing method as described in any one of claims 1-7, or to implement the data processing method as described in any one of claims 8-10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and execute the data processing method as described in any one of claims 1-7, or execute the data processing method as described in any one of claims 8-10.

15. A computer program product, characterized in that, The computer program product includes a computer program adapted to be loaded by a processor and execute the data processing method as described in any one of claims 1-7, or execute the data processing method as described in any one of claims 8-10.

Images