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

Abstract

The application discloses a data processing method, device and equipment and a readable storage medium. The method comprises the following steps: a server acquires a key negotiation request sent by a client, returns key negotiation response information to the client based on the key negotiation request, the key negotiation response information comprises a first random number, a server public key and a target cryptographic suite; the client encryption information sent by the client is received; the client encryption information is decrypted based on a server private key in a trusted execution environment, and a second random number is obtained; a session key is generated based on the first random number, the second random number and a third random number carried in the key negotiation request; and the session key is used for encrypting or decrypting application data in the process of transmitting the application data between the client. By using the application, the security of the private key can be improved in the scene of negotiating the session key, so that the communication security is improved. The application embodiment can be applied to a vehicle-mounted scene.

Description

Technical Field

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

[0002] Currently, when two devices wish to transmit data encrypted via Transport Layer Security (TLS), they need to negotiate a session key to encrypt the transmitted data.

[0003] Negotiating session keys requires the device's private key. However, currently, these private keys are primarily stored in plaintext on the device itself, posing a risk of being stolen by third parties. Once stolen, the session key can be decrypted, allowing the third party to access the data transmitted. Therefore, in TLS transmission scenarios, the storage and use of private keys are risky, resulting in very low data security. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, and readable storage medium that can improve the security of private keys in scenarios involving negotiation of session keys, thereby enhancing communication security.

[0005] One embodiment of this application provides a data processing method, including:

[0006] The server receives the key negotiation request sent by the client and returns key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite;

[0007] Receive client-encrypted information sent by the client; the client-encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite;

[0008] The server's private key is obtained in the Trusted Execution Environment (TEE). The encrypted information from the client is then decrypted using the server's private key in the TEE to obtain a second random number. The TEE refers to a trusted program in a key management software development kit (SDK). The key management software development kit is a software development kit that encapsulates the key management logic program. The TEE is isolated from the server's operating system.

[0009] A session key is generated based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt application data during the transmission of application data with the client.

[0010] One embodiment of this application provides a data processing apparatus, including:

[0011] The request retrieval module is used to retrieve key negotiation requests sent by the client;

[0012] The response return module is used to return key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite.

[0013] An encrypted information receiving module is used to receive client encrypted information sent by the client; the client encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite;

[0014] The private key acquisition module is used to obtain the server's private key in a trusted execution environment;

[0015] The decryption module is used to decrypt the client's encrypted information based on the server's private key in the trusted execution environment to obtain the second random number; the trusted execution environment refers to a trusted program in a key management software development kit, and the key management software development kit refers to a software development kit obtained by encapsulating the key management logic program; the trusted execution environment is isolated from the server's operating system;

[0016] The session key generation module is used to generate a session key based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt the application data during the transmission of application data with the client.

[0017] In one embodiment, the key negotiation request carries a list of available cipher suites for the client;

[0018] The response return module includes:

[0019] A random number generation unit is used to generate the first random number based on the key negotiation request;

[0020] A cipher suite selection unit is used to select the target cipher suite from the list of available cipher suites.

[0021] The certificate acquisition unit is used to acquire a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server's public key;

[0022] The response return unit is used to determine the first random number, the first digital certificate, and the target cryptographic suite as the key negotiation response information, and return the key negotiation response information to the client.

[0023] In one embodiment, each available cipher suite in the list of available cipher suites includes encryption algorithms supported by the client; the second random number is generated by the client based on the encryption algorithms included in the target cipher suite; the first digital certificate also includes first signature information that is signed using the private key of the trusted node, the first signature information being used by the client to verify the first digital certificate based on the public key of the trusted node, and to obtain the server public key after successful verification.

[0024] In one embodiment, the key negotiation response information further includes a certificate verification request, which requests the client to send its second digital certificate to the server; the client encryption information also carries the second digital certificate sent by the client to the server based on the certificate verification request; the second digital certificate is issued by the trusted node for the client, and the second digital certificate includes second signature information in which the trusted node's private key signs the second digital certificate;

[0025] The private key acquisition module includes:

[0026] The certificate verification unit is used to verify the second digital certificate based on the node public key of the trusted node and the second signature information;

[0027] The private key acquisition unit is used to obtain the server's private key in a trusted execution environment when verification is successful.

[0028] In one embodiment, the server supports a secure transport layer protocol, and the key negotiation request is generated based on the secure transport layer protocol;

[0029] The data processing device also includes:

[0030] The program acquisition module is used to acquire the key management logic program, the communication interface corresponding to the key management logic program, and the calling function corresponding to the key management logic program;

[0031] The program encapsulation module is used to encapsulate the key management logic program as a trusted program, the calling function as a regular program, and the trusted program, the communication interface, and the regular program to obtain the key management software development kit.

[0032] The toolkit integration module is used to integrate the key management software development kit into the security protocol library of the server, and to determine the trusted program in the key management software development kit integrated in the security protocol library as the trusted execution environment; the security protocol library refers to the protocol library corresponding to the secure transport layer protocol.

[0033] In one embodiment, the ordinary program includes a decryption function; the communication interface is used for communication between the ordinary program and the trusted program, and the communication interface includes a decryption function communication interface; the trusted program includes a decryption function logic program.

[0034] The decryption module includes:

[0035] The function call unit is used to call the decryption function in the ordinary program, obtain the decryption function communication interface in the communication interface through the decryption function, and send the client encrypted information to the decryption function logic program through the decryption function communication interface.

[0036] The decryption unit is used to decrypt the client's encrypted information using the server's private key in the decryption function logic program to obtain the second random number; the decryption function logic program is used to return the second random number to the normal program through the decryption function communication interface;

[0037] A random number receiving unit is used to receive the second random number returned by the ordinary program.

[0038] In one embodiment, the session key includes an encryption key and a decryption key;

[0039] The data processing device also includes:

[0040] An encrypted data receiving module is used to receive encrypted data sent by the client; the encrypted data is data obtained by the client encrypting the application data using the encryption key;

[0041] The data decryption module is used to decrypt the encrypted data using the decryption key to obtain the application data.

[0042] In one embodiment, the data processing apparatus further includes:

[0043] The private key storage module is used to obtain the server private key issued by the trusted node for the server and store the server private key in the trusted execution environment; the trusted execution environment is used to encrypt the server private key based on the environment encryption key corresponding to the trusted execution environment to obtain the encrypted server private key; the environment encryption key is derived from the environment root key corresponding to the trusted execution environment.

[0044] In one embodiment, the client is a data node in a blockchain network, and the server is a target consensus node in a consensus node cluster of the blockchain network;

[0045] The data processing device also includes:

[0046] The block generation module is used to receive business transaction data related to the target business sent by the data node, and generate transaction blocks based on the business transaction data;

[0047] The block signing module is used to sign the transaction block based on the server's private key in the trusted execution environment to obtain a digital signature of the block;

[0048] A block sending module is used to send the transaction block and its digital signature to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes in the consensus node cluster other than the target consensus node; the digital signature is used by the remaining consensus nodes to obtain the server public key corresponding to the target consensus node, verify the digital signature based on the server public key, and, after the verification is successful, jointly reach a consensus on the transaction block with the target consensus node;

[0049] The block consensus module is used to receive voting information returned by the remaining consensus nodes. The voting information is determined by the remaining consensus nodes after obtaining the server public key corresponding to the target consensus node, verifying the digital signature of the block based on the server public key, and only after the verification is successful.

[0050] The block on-chain module is used to determine the consensus result of the transaction block based on the voting information;

[0051] The block-on-chain module is also used to upload the target block to the blockchain when the consensus result of the transaction block is a consensus pass result.

[0052] In one embodiment, the number of remaining consensus nodes is at least two, and the number of voting information is at least two.

[0053] The block on-chain module includes:

[0054] The quantity determination unit is used to determine the voting information with the voting type of "pass" from at least two voting information as the voting pass information;

[0055] The quantity determination unit is further configured to obtain the total number of nodes corresponding to the target consensus node and the remaining consensus nodes, the number of nodes corresponding to the target consensus node, and the number of passes corresponding to the voting pass information;

[0056] The quantity determination unit is further configured to add the number of nodes corresponding to the target consensus node to the number of nodes that have passed, so as to obtain the total number of nodes that have passed.

[0057] The result determination unit is used to determine the consensus result of the transaction block based on the total number of nodes and the total number of nodes.

[0058] One embodiment of this application provides a computer device, including: a processor and a memory;

[0059] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the methods described in the embodiments of this application.

[0060] One aspect of this application provides a computer-readable storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions perform the methods described in this application.

[0061] One aspect of this application provides a computer program product or computer program including 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 method provided in one aspect of the embodiments of this application.

[0062] In this embodiment, after encapsulating the key management logic program into a software development kit (SDK), a trusted execution environment (TEX) can be determined based on the trusted program within the SSD. The server's private key can be stored within this TEX, and decryption using the private key also occurs within the TEX. Therefore, when the client and server negotiate session keys, the server's private key no longer needs to be stored on the server's hard drive. Since the TEX and the server's operating system are isolated, the server's private key stored in the TEX cannot be accessed externally. Data decrypted using the private key within the TEX is also unobtainable externally. Consequently, the session key negotiated based on the private key is also unknowable externally, effectively protecting the security of the private key and improving the security of the session key, thereby significantly enhancing the security of transmitted data. In summary, this application improves the security of the private key in session key negotiation scenarios, thereby enhancing communication security. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 This is a network architecture diagram provided in an embodiment of this application;

[0065] Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of this application;

[0066] Figure 3 This is a schematic diagram of the structure of a key management software development kit provided in an embodiment of this application;

[0067] Figure 4 This is a schematic diagram illustrating TLS communication between two blockchain layers provided in an embodiment of this application;

[0068] Figure 5 This is a schematic diagram of a process for uploading blocks to the blockchain based on a trusted execution environment, provided in an embodiment of this application.

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

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

[0071] 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.

[0072] Please see Figure 1 , Figure 1 This is a network architecture diagram provided in an embodiment of this application. For example... Figure 1 As shown, this network architecture may include a service server 1000 and a terminal device cluster. The terminal device cluster may include one or more terminal devices; the number of terminal devices is not limited here. Figure 1 As shown, multiple terminal devices may include terminal device 100a, terminal device 100b, terminal device 100c, ..., terminal device 100n; as Figure 1As shown, terminal devices 100a, 100b, 100c, ..., 100n can each connect to the business server 1000 via a network, so that each terminal device can interact with the business server 1000 through the network connection.

[0073] It is understandable that, such as Figure 1 Each terminal device shown can have the target application installed. When the target application runs on each terminal device, it can interact with... Figure 1 The business servers 1000 shown interact with each other, enabling each business server 1000 to receive business data from each terminal device. The target application may include applications capable of displaying text, images, audio, and video data. For example, the application may be a multimedia application (e.g., a video application), an entertainment application (e.g., a game application), a social application, an educational application, etc. It should be understood that the business data in this application may be application-related data corresponding to the application. For example, when the target application is a video application, the business data may refer to video-related data; when the target application is a game application, the business data may refer to game-related data. Examples will not be provided here.

[0074] It should be understood that when data interaction occurs between a terminal device and a business server, ordinary, publicly available data can be transmitted using a Hypertext Transfer Protocol (HTTP) transmission channel. HTTP is a simple request-response protocol that typically runs on top of the Transmission Control Protocol (TCP). It specifies what messages a client might send to the server and what responses it might receive. The headers of request and response messages are given in ASCII format, while the message content has a MIME-like format. For special, confidential data that requires encrypted transmission, a secure transmission channel using a Transport Layer Security (TLS) protocol can be used. Specifically, the TLS protocol involved in this application embodiment is used to provide confidentiality and data integrity between two communicating applications. This protocol consists of two layers: the TLS Record protocol and the TLS Handshake protocol.

[0075] The advantage of the TLS protocol is its decoupling from higher-level application layer protocols (such as HTTP, FTP, and Telenet). Application layer protocols can run transparently on top of the TLS protocol, with the TLS protocol handling the negotiation and authentication required to create encrypted channels. Data transmitted by application layer protocols is encrypted when passing through the TLS protocol, thus ensuring the confidentiality of communication. It is understood that the TLS protocol requires configuration of both the client and server to be used; in this embodiment, the terminal device can be the client, and the server can be the business server. After initial deployment, once both the client and server agree to use the TLS protocol for data transmission, a stateful connection can be negotiated through a TLS handshake process to transmit application data. Through the TLS handshake, the client and server can negotiate various parameters to create a secure connection. The TLS handshake process between the client and server can essentially be understood as the process of negotiating a session key, which is used to encrypt and decrypt application data during subsequent transmissions.

[0076] It is understandable that the server's private key is needed during the negotiation of session keys between the client and server. To enhance the security of the server's private key and thus improve communication security, this application modifyes the TLS protocol. The use of the private key can be performed within a Trusted Execution Environment (TEE). By storing and using the private key in the TEE, the possibility of external access to the private key in TLS can be prevented. The TEE involved in this application is a hardware-based technology for protecting data and algorithms. It is an isolated environment for the processor and memory; only the Central Processing Unit (CPU) can access applications within the TEE. Access from other layers (such as other hardware, kernel, other applications, etc.) to the TEE is blocked by the CPU. Therefore, storing and using the private key in the TEE significantly improves the security of the private key and reduces the possibility of its leakage. This protects the security of the session key and, consequently, enhances the security of application data transmission when using the TLS protocol.

[0077] For ease of understanding, the following will elaborate on the process of a client and server performing a TLS handshake based on a trusted execution environment to negotiate various parameters and establish a secure connection (i.e., the process of negotiating the session key through a TLS handshake). The TLS handshake process between the client and server based on a trusted execution environment can specifically include the following steps 1-6:

[0078] Step 1: When a client connects to a server that supports the TLS protocol and requests to establish a secure connection, it provides a list of supported cipher suites (including cryptographic algorithms, cryptographic hash functions, etc.) and a random number generated by the client, and the handshake begins.

[0079] Step 2: The server selects the target cipher suite from the list of cipher suites and notifies the client of the target cipher suite, along with a random number generated by the server.

[0080] Step 3: The server sends back its digital certificate, which typically includes the server's name, a trusted Certificate Authority (CA), and the server's public key.

[0081] Step 4: The client verifies the validity of the certificate it issued. After successful verification, in order to generate a session key for secure connection, the client can use the target cipher suite to generate another random number (which can be called a random key). The client can use the server's public key to encrypt the randomly generated random key, and the client can send the encrypted random key to the server.

[0082] Step 5: The server obtains its private key from the Trusted Execution Environment (TEE) and decrypts it to obtain the random key generated by the client. It should be understood that because the private key is stored in the TEE and cannot be accessed externally, only the server can use it to decrypt the key, ensuring extremely high security.

[0083] Step 6: The server and client use their respective random numbers and random keys to generate a symmetric key for encryption and decryption. This symmetric key serves as the session key negotiated by both parties. This symmetric key can be used for encryption or decryption during subsequent application data transmission.

[0084] It should be understood that steps 1-6 above constitute the TLS handshake process. Once the handshake is complete, the connection is highly secure until it is closed. If any of the above steps fails, the TLS handshake process will also fail, and all connections will be disconnected. For specific implementation details on deploying a trusted execution environment on the server, please refer to the subsequent sections. Figure 2 The description in the corresponding embodiments.

[0085] This application embodiment can select one terminal device from multiple terminal devices as the target terminal device. This terminal device may include: smartphones, tablets, laptops, desktop computers, smart TVs, smart speakers, desktop computers, smartwatches, smart voice interaction devices, in-vehicle devices, and other smart terminals with multimedia data processing functions (e.g., video data playback functions, music data playback functions), but is not limited to these. For example, this application embodiment can... Figure 1 The terminal device 100a shown is the target terminal device. The target terminal device may integrate the aforementioned target application. At this time, the target terminal device can interact with the business server 1000 through the target application.

[0086] It is understood that the methods provided in this application embodiment can be executed by computer devices, including but not limited to terminal devices or business servers. The business 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, and big data and artificial intelligence platforms.

[0087] The terminal equipment and the business server can be connected directly or indirectly through wired or wireless communication, and this application does not impose any restrictions on this.

[0088] Optionally, and understandably, the aforementioned computer devices (such as the aforementioned business server 1000, terminal device 100a, terminal device 100b, etc.) can be nodes in a distributed system, where the distributed system can be a blockchain system. This blockchain system can be a distributed system formed by connecting multiple nodes through network communication. For ease of understanding, the following will elaborate on blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer (P2P) transmission, consensus mechanisms, and encryption algorithms. Essentially, it is a decentralized database, a chain of data blocks linked together using cryptographic methods. These data blocks are also called blocks, which are essentially blocks used to record the validity (i.e., anti-counterfeiting) of data information. A network based on blockchain and a peer-to-peer (P2P) network can be called a blockchain network. It should be understood that any computer device (i.e., node) in a blockchain network can be a terminal device or a server. Nodes in a blockchain network can also include trusted execution environments (TEAs). Node private keys can also be stored in a TEA. The use of node private keys can be performed in a TEA, thereby protecting the security of communication between nodes.

[0089] It should be noted that the computer device that issues certificates in a blockchain network can be called a node issuing device (or simply issuing node). To better implement certificate issuance, the issuing node in this embodiment can refer to a node in the blockchain network that provides a certificate issuance server by executing Trusted Computing (TC) within a Trusted Execution Environment (TEE). The TEE can refer to a secure area located within the issuing node and isolated from its operating system (System on Chip, SoC). Trusted Computing, also known as Trusted Computing, is a technology promoted and developed by the Trusted Computing Group (Trusted Computing Cluster, or TCPA for short).

[0090] It should be understood that when physically deploying a blockchain network, nodes corresponding to key departments involved in the blockchain network (such as the management department of an enterprise) can be selected as issuing nodes. An issuing node may include at least: a trusted execution environment (TA), other areas, and the hardware supporting the issuing node. The TA may include a trusted application (TA), the TA's API (Application Programming Interface), and a security system; through the combination of hardware and software, the TA can ensure the secure transmission, storage, and processing of relevant data, as well as the confidentiality and integrity of the TA execution. Other areas may include other modules, other API interfaces, and operating systems (such as Android); the hardware may include a video transmitter for communication, a central processing unit (CPU), a hard drive, etc. It is understood that through the TA in the issuing node, and the TAs in each node, the security of the node's private key can be protected while ensuring the secure issuance of the certificate.

[0091] It should be noted that, in the specific embodiments of this application, if user information, user data, or other related data are involved (such as the application data transmitted above containing user information or user data), such user information, user data, or other related data can only be obtained with the user's authorization and consent. In other words, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use, and processing of user-related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0092] For ease of understanding, please refer to the following: Figure 2 , Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of this application. The data processing method can be executed by a computer device, which may refer to a server (e.g., the one described above). Figure 1 The service server in the corresponding embodiment can also refer to a terminal device (such as the one mentioned above). Figure 1 (The corresponding embodiment refers to any terminal device in the terminal device cluster). For example... Figure 3 As shown, the data processing method may include at least the following steps S101-S104:

[0093] Step S101: The server obtains the key negotiation request sent by the client and returns key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite.

[0094] In this application, when a client and server need to transmit special, confidential data, a TLS protocol data transmission channel can be used to encrypt the application data. Once both the client and server agree to use the TLS protocol for data transmission, a TLS handshake is required before communication between them to establish a secure connection. This involves negotiating a session key, which is used to encrypt or decrypt application data during subsequent transmissions. The handshake begins when the client connects to a TLS-enabled server, requests a secure connection, and provides a list of supported cipher suites (including encryption algorithms, cryptographic hash functions, etc.) and a randomly generated number.

[0095] The key negotiation request here can be understood as a request sent by the client to the server to establish a secure connection. This request may carry a list of key suites that the client can understand (referred to as the available cipher suite list). Each available cipher suite in the list may contain an encryption key algorithm, a cryptographic hash function, a hash function, etc. The key negotiation request may also carry a random number generated by the client (referred to as a third random number). When the client sends a key negotiation request carrying the list of available cipher suites and the third random number to the server, it signifies the start of the TLS handshake between the client and the server (i.e., the beginning of establishing a secure connection between the client and the server).

[0096] Furthermore, the server can return a response message (referred to as a key negotiation response message) to the client based on the key negotiation request. Specifically, this can be implemented as follows: a first random number can be generated based on the key negotiation request; a target cipher suite can be selected from the list of available cipher suites; a first digital certificate issued by a trusted node for the server can be obtained; wherein the first digital certificate includes the server's public key; subsequently, the first random number, the first digital certificate, and the target cipher suite can be used to determine the key negotiation response message, which is then returned to the client.

[0097] Understandably, the key negotiation response information may include the target cipher suite selected by the server from the aforementioned list of available cipher suites, the server's digital certificate (for clarity, this can be referred to as the first digital certificate), and a random number generated by the server (for clarity, this can be referred to as the first random number). Upon receiving a key negotiation request, the server can select a cipher suite from the list of available cipher suites as the target cipher suite, obtain the server's digital certificate, and generate a random number. Based on the target cipher suite, the first digital certificate, and the first random number, the server can compose the key negotiation response information and return it to the client. The server's digital certificate can be issued by a trusted node, which can refer to an individual or organization trusted by the client, server, and browser.

[0098] Step S102: Receive client-encrypted information sent by the client; the client-encrypted information refers to the information obtained by the client encrypting the second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite.

[0099] In this application, each digital certificate may include signature information where the trusted node signs the digital certificate using its private key. Therefore, the first digital certificate of the server also includes signature information (referred to as the first signature information) where the trusted node signs the first digital certificate using its private key. After receiving the key negotiation information, the client can verify the first digital certificate based on the trusted node's public key. Upon successful verification, the client can obtain the server's public key. Furthermore, since each cipher suite includes encryption algorithms supported by the client, the client can generate a new random number (referred to as the second random number, or random pre-key) based on the encryption algorithm in the target cipher suite from the key negotiation response information. The client can then encrypt this second random number using the obtained server public key to obtain encrypted information (referred to as client-encrypted information). This client-encrypted information can only be decrypted using the server's private key.

[0100] In other words, each available cipher suite in the above list includes encryption algorithms that the client can support; the second random number is generated by the client based on the encryption algorithms included in the target cipher suite; and the first digital certificate also includes first signature information that is signed by the trusted node's private key. The first signature information is used by the client to verify the first digital certificate based on the trusted node's public key, and after successful verification, the client obtains the server's public key. After obtaining the server's public key, the client then uses the server's public key to encrypt the second random number to obtain the client's encrypted information.

[0101] Step S103: Obtain the server private key in the trusted execution environment, and decrypt the client's encrypted information based on the server private key in the trusted execution environment to obtain the second random number; the trusted execution environment contains trusted programs in the key management software development kit, which refers to the software development kit obtained by encapsulating the key management logic program; the trusted execution environment is isolated from the server's operating system.

[0102] In this application, after the client returns encrypted client information, the server can obtain the server's private key from the trusted execution environment (TEA). Based on this private key, the server decrypts the client's encrypted information within the TEA to obtain the second random number. The TEA can include trusted programs within a software development kit (SDK). To improve the security of private keys in TLS communication scenarios, this application can modify the TLS protocol by employing a trusted black-box approach for secure key management. Through software implementation, the relevant key management logic programs (e.g., key initialization, key sealing, key desealing, signing with the private key, decryption with the private key, etc.) are encapsulated to obtain a key management SDK. This SDK can then be integrated into a TLS library (the open-source library corresponding to the TLS protocol, also known as a security protocol library). The trusted programs within the SDK integrated into the TLS library serve as the server's trusted execution environment, allowing the storage and use of the server's private key to be executed within these trusted programs.

[0103] As described above, the server supports the Transport Layer Security (TLS) protocol. Key negotiation requests are generated based on TLS. The specific implementation method for encapsulating the key management SDK and integrating it into the TLS library to obtain a trusted execution environment can be as follows: The key management logic program, its corresponding communication interface, and its corresponding calling function can be obtained. Subsequently, the key management logic program can be treated as a trusted program, and the calling function as a regular program. The trusted program, communication interface, and regular program can be encapsulated to obtain a key management software development kit (SDK). Then, the SSD can be integrated into the server's security protocol library. The trusted program within the SSD integrated into the security protocol library can be identified as the trusted execution environment. Here, the security protocol library refers to the protocol library corresponding to the Transport Layer Security (TLS) protocol.

[0104] Understandably, this application encapsulates the trusted part (the key management logic program executing in a secure environment), the untrusted part (the code executing in a normal application), and the communication interface in a hardware security mechanism to obtain a key management SDK. The trusted part can manipulate keys (such as private key initialization, private key storage, and private key decryption), while the untrusted part can communicate with the trusted part through the communication interface, thereby calling the relevant programs of the trusted part to process related logic. In the hardware security mechanism, the trusted part can be understood as a black box, the contents of which are not visible from the outside; this black box can be understood as the trusted execution environment in the hardware security mechanism. The trusted part in the hardware security mechanism only exposes communication interfaces related to data computation (e.g., for keys, only communication interfaces related to key initialization, key signing, and key decryption can be exposed). Private data (such as the private key) never leaves the black box (trusted part), thus ensuring the security of the private key. The data in the black box is only visible to the CPU; the operating system, normal applications, and hardware other than the CPU cannot access the contents of the black box.

[0105] This application embodiment can employ a hardware security mechanism to implement the key management SDK. The trusted portion of the hardware security mechanism (i.e., the key management logic program executed in a black box) can be encapsulated. The key management SDK can also be divided into a trusted program (i.e., the key management logic program) and an untrusted program (which can be called a normal program, containing ordinary code such as function calls). The key management logic program can manipulate the private key, while the normal program can communicate with the trusted program through a communication interface. The normal program calls the relevant key function programs in the trusted program through the communication interface. In other words, the key management SDK contains a trusted program (key management logic program), a normal program (containing function calls), and a communication interface (for communication between the normal program and the trusted program). Since the trusted program can only run on the CPU and cannot make system calls, all related file operations, network operations, etc., must be implemented in the normal program. When the private key is desired, the relevant function in the normal program can be called. The normal program can then send the data to be processed to the trusted program through the relevant communication interface. The trusted program can then use the private key to perform relevant operations on the data.

[0106] For ease of understanding, please refer to the following: Figure 3 , Figure 3 This is a schematic diagram of the structure of a key management software development kit provided in an embodiment of this application. For example... Figure 3 As shown, this key management software development kit (SDK) can include a trusted component (trusted program) and an untrusted component (ordinary program). The trusted program can include key management logic programs (e.g., key initialization logic programs, key sealing logic programs, key decryption logic programs, signature function logic programs, decryption function logic programs, etc.), and the ordinary program can include calling functions (the calling functions corresponding to the key initialization logic programs, key sealing logic programs, key decryption logic programs, signature function logic programs, and decryption function logic programs, etc.). The SSD can also include a communication interface for communication between the trusted program and the untrusted program. The trusted program in the SSD is inaccessible externally (e.g., other applications, operating systems, hardware other than the CPU). External access is only to the ordinary program, which then communicates with the trusted program through the communication interface. When the SSD is deployed in a TLS library, it serves as a trusted execution environment for the server. All operations related to the server's private key are executed within this trusted execution environment, effectively protecting the security of the server's private key.

[0107] As described above, all operations related to the private key are performed within a trusted execution environment (trusted program). Therefore, the ordinary program in this embodiment may include a decryption function; the communication interface is used for communication between the ordinary program and the trusted program, and may include a decryption function communication interface; the trusted program may include a decryption function logic program; the specific implementation of decrypting client-encrypted information based on the server's private key in the trusted execution environment to obtain a second random number can be as follows: the decryption function in the ordinary program can be called, and the decryption function communication interface can be obtained through the communication interface. Subsequently, the client-encrypted information can be sent to the decryption function logic program through the decryption function communication interface; the server's private key can be used in the decryption function logic program to decrypt the client-encrypted information to obtain a second random number; the decryption function logic program is also used to return the second random number to the ordinary program through the decryption function communication interface; subsequently, the server can receive the second random number returned by the ordinary program.

[0108] Optionally, in a feasible embodiment, the server can also verify the client's digital certificate. Therefore, the key negotiation response information may further include a certificate verification request, which can be used to request the client to send its second digital certificate to the server. The client can then return its second digital certificate to the server based on this certificate verification request. In other words, the aforementioned client encryption information can also carry the second digital certificate sent by the client to the server based on the certificate verification request. Here, the second digital certificate can be issued by a trusted node for the client, and the second digital certificate includes second signature information, which is signed by the trusted node's private key.

[0109] Understandably, in this scenario, the specific implementation method for the server to obtain the server private key in a trusted execution environment could be as follows: the second digital certificate can be verified based on the public key of the trusted node and the second signature information; and the server private key can be obtained in the trusted execution environment after the verification is successful.

[0110] Step S104: Generate a session key based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt application data during the transmission of application data with the client.

[0111] In this application, after the server decrypts and obtains the second random number, it can then generate a session key based on the first, second, and third random numbers. Similarly, the client can also generate the session key based on the first, second, and third random numbers, and then send a key encryption notification to the server, effectively informing the server that it will begin using session key encryption to send data in the future.

[0112] It is understood that the session key in this application can be a symmetric key or a key pair. The session key may include a first key and a second key, which can be mutually encrypted and decrypted. That is, data encrypted with the first key can only be decrypted with the second key; or data encrypted with the second key can only be decrypted with the first key. Either the first key or the second key can be used as an encryption key, and the other as a decryption key. In other words, the session key can include both an encryption key and a decryption key. The client can use the encryption key to encrypt application data, obtaining encrypted data; subsequently, the client can send the encrypted data to the server; and after receiving the encrypted data sent by the client, the server can use the corresponding decryption key to decrypt the encrypted data, obtaining the application data.

[0113] It should be understood that in this application embodiment, when conducting TLS communication between the client and server, the TLS protocol has been modified by integrating the key management SDK into the TLS library. This application embodiment can register functions related to the use of the private key in the TLS library, and all logic using the private key can be executed by calling trusted programs in the key management SDK. The private key can be stored in the trusted execution environment (trusted program) of the key management SDK, and the trusted execution environment can seal the private key, thus preventing it from being viewed externally. Even if the relevant files are copied to other machines, the plaintext cannot be recovered, and the private key cannot be viewed. The trusted execution environment ensures that data encrypted by the trusted execution environment hardware cannot be decrypted on other hardware.

[0114] Taking the storage of a server's private key as an example, the specific implementation of private key storage can be as follows: The server's private key, issued by a trusted node, can be obtained and then stored in a trusted execution environment (TEA). The TEA uses its own environment encryption key to encrypt the server's private key, resulting in an encrypted server private key. This environment encryption key is derived from the TEA's root key. In other words, the TEA can derive an encryption key from the root key of its trusted hardware, and use this encryption key to encrypt the server's private key, obtaining an encrypted server private key. This encrypted server private key never leaves the TEA and cannot be accessed externally. Even if it is copied to another machine, the plaintext cannot be recovered.

[0115] In this embodiment, the key management logic program can be encapsulated into a software development kit (SDK) based on trusted computing. A trusted execution environment (TEA) can be determined based on the trusted program within the SSD. The server's private key can be stored in this TEA, and decryption using the private key also occurs within the TEA. Therefore, when the client and server negotiate session keys, the server's private key no longer needs to be stored on the server's hard drive. Because the TEA is isolated from the server's operating system, the server's private key stored in the TEA cannot be accessed externally. Data decrypted using the private key in the TEA is also unobtainable externally. Consequently, the session key negotiated based on the private key is also unknowable externally, effectively protecting the security of the private key and improving the security of the session key, thereby significantly enhancing the security of transmitted data. In summary, this application improves the security of the private key in session key negotiation scenarios, thereby enhancing communication security.

[0116] In this application, the aforementioned server or terminal device can also be a node in a distributed system, which can refer to a blockchain system. It is understood that enhanced TLS communication can also be used in the two-layer chain architecture of a blockchain system. For ease of understanding, please refer to [further details omitted]. Figure 4 , Figure 4 This is a schematic diagram illustrating TLS communication via a two-layer blockchain according to an embodiment of this application. Figure 4 As shown,

[0117] This two-layer chain structure can include a witness network layer and a consensus network layer. The witness network can include different data nodes (such as data node 1 and data node 2), and the consensus network can include different consensus nodes (such as consensus node 1, consensus node 2, consensus node 3, and consensus node 4). Figure 4As shown, a trusted execution environment (TEX) can be deployed in each consensus node (e.g., integrating the key management SDK into the TLS library, and using the trusted program in the key management SDK within the TLS library as the TEX). The consensus node's private key can be stored in the TEX, and subsequent use of the private key will be executed within the TEX. During TLS sessions between data nodes and consensus nodes, the consensus node can obtain and use its private key within the TEX. This protects the security of the consensus node's private key in the blockchain and enhances communication security.

[0118] It is understandable that the aforementioned client can be a data node in the blockchain network, and the server can be a consensus node (referred to as the target consensus node) within the consensus node cluster of the blockchain network. When a data node sends transaction data to the target consensus node, the target consensus node can also generate a block, sign the block based on its private key in the trusted execution environment, broadcast the block for consensus, and add the block to the blockchain after passing consensus. For ease of understanding, please refer to [further details omitted]. Figure 5 , Figure 5 This is a schematic diagram illustrating a process for uploading blocks to the blockchain based on a trusted execution environment, as provided in an embodiment of this application. Figure 5 As shown, the process may include at least the following steps S201-S205:

[0119] Step S201: Receive business transaction data related to the target business sent by the data node, and generate a transaction block based on the business transaction data.

[0120] Specifically, the target business can include transaction businesses such as transfers and storage. Data nodes can send transaction data to the target consensus node, and the target consensus node can generate blocks (which can be called transaction blocks) based on the business transaction data.

[0121] Step S202: In a trusted execution environment, the transaction block is signed based on the server's private key to obtain the block's digital signature.

[0122] Specifically, a trusted execution environment (TEA) can be deployed within the target consensus node. Within this TEA, the target consensus node can sign transaction blocks based on the server's private key (i.e., the target consensus node's own private key), obtaining a digital signature (for clarity, this digital signature can be referred to as the block digital signature). Specifically, the TEA can refer to a trusted program within the key management software toolkit integrated into the TLS library. This trusted program can include a signature function logic program, while the ordinary programs within the key management software toolkit can include signature functions. The communication interface within the key management software toolkit can include a signature function communication interface. The target consensus node can then call the signature function in the ordinary program, thereby obtaining the signature function interface through the communication interface. The transaction block can then be sent to the signature function logic program via this signature communication interface. In the signature function program, the server's private key can be used to sign the transaction block, obtaining the block digital signature. This signature function logic program can also return the block digital signature to the ordinary program through the signature function communication interface; the target consensus node can then receive this digital signature.

[0123] Step S203: Send the transaction block and its digital signature to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes in the consensus node cluster other than the target consensus node; the digital signature of the block is used by the remaining consensus nodes to obtain the server public key corresponding to the target consensus node, verify the digital signature of the block based on the server public key, and reach a consensus on the transaction block together with the target consensus node after the verification is successful.

[0124] Specifically, the target consensus node can broadcast the transaction block to other consensus nodes (i.e., the remaining consensus nodes) to achieve consensus. Other consensus nodes can obtain the server public key corresponding to the target consensus node to verify the digital signature of the block. After successful verification, they can jointly reach a consensus on the transaction block with the target consensus node.

[0125] Step S204: Receive voting information returned by the remaining consensus nodes; the voting information is determined by the remaining consensus nodes after obtaining the server public key corresponding to the target consensus node, verifying the digital signature of the block based on the server public key, and only after the verification is successful.

[0126] Specifically, each remaining consensus node can return voting information to the target consensus node. The type of voting information can include pass, reject, or pending.

[0127] Step S205: Determine the consensus result of the transaction block based on the voting information. When the consensus result of the transaction block is a consensus pass result, upload the target block to the chain.

[0128] Specifically, the target consensus node can determine the consensus result of the transaction block based on the voting information of each remaining consensus node. Taking a minimum of two remaining consensus nodes and a minimum of two voting information as an example, the specific implementation of determining the consensus result of the transaction block based on voting information can be as follows: Voting information with the "pass" type among the at least two voting information can be identified as "pass" information; subsequently, the total number of nodes corresponding to the target consensus node and the remaining consensus nodes, the number of nodes corresponding to the target consensus node, and the number of passes corresponding to the "pass" voting information can be obtained; the number of nodes corresponding to the target consensus node and the number of passes can be added together to obtain the total number of passes; based on the total number of passes and the total number of nodes, the consensus result of the transaction block is determined.

[0129] The specific implementation method for determining the consensus result of a transaction block based on the total number of nodes passing the vote and the total number of nodes can be as follows: A ratio between the total number of nodes passing the vote and the total number of nodes can be determined. If this ratio is greater than or equal to a threshold, the consensus result of the transaction block can be determined as a passed consensus result; if the ratio is less than the threshold, the consensus result of the transaction block can be determined as a failed consensus result. This threshold can be a predefined value (such as 2 / 3, 3 / 4, etc.). In other words, when more than a certain proportion of consensus nodes in the consensus node cluster have all passed their votes, the consensus result can be determined as a passed consensus result.

[0130] In this embodiment, the key management logic program can be encapsulated into a software development kit (SDK) based on trusted computing. A trusted execution environment (TEA) can be determined based on the trusted program within the SSD. The server's private key can be stored in this TEA, and decryption using the private key also occurs within the TEA. Therefore, when the client and server negotiate session keys, the server's private key no longer needs to be stored on the server's hard drive. Because the TEA is isolated from the server's operating system, the server's private key stored in the TEA cannot be accessed externally. Data decrypted using the private key in the TEA is also unobtainable externally. Consequently, the session key negotiated based on the private key is also unknowable externally, effectively protecting the security of the private key and improving the security of the session key, thereby significantly enhancing the security of transmitted data. In summary, this application improves the security of the private key in session key negotiation scenarios, thereby enhancing communication security.

[0131] Further, please see Figure 6 , Figure 6This is a schematic diagram of the structure of a data processing apparatus provided in an embodiment of this application. The data processing apparatus can be a computer program (including program code) running on a computer device; for example, the data processing apparatus is an application software. The data processing apparatus can be used to execute... Figure 3 The method shown. (As illustrated) Figure 6 As shown, the data processing device 1 may include: a request acquisition module 11, a response return module 12, an encrypted information receiving module 13, a private key acquisition module 14, a decryption module 15, and a session key generation module 16.

[0132] The request acquisition module 11 is used to acquire the key negotiation request sent by the client;

[0133] The response return module 12 is used to return key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite.

[0134] The encrypted information receiving module 13 is used to receive client encrypted information sent by the client; the client encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite;

[0135] Private key acquisition module 14 is used to acquire the server private key in a trusted execution environment;

[0136] The decryption module 15 is used to decrypt the client's encrypted information based on the server's private key in the trusted execution environment to obtain the second random number; the trusted execution environment refers to a trusted program in a key management software development kit, and the key management software development kit refers to a software development kit obtained by encapsulating the key management logic program; the trusted execution environment is isolated from the server's operating system;

[0137] The session key generation module 16 is used to generate a session key based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt the application data during the transmission of application data with the client.

[0138] The specific implementation methods of the request acquisition module 11, response return module 12, encrypted information receiving module 13, private key acquisition module 14, decryption module 15, and session key generation module 16 can be found in the above description. Figure 2 The descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here.

[0139] In one embodiment, the key negotiation request carries a list of available cipher suites for the client;

[0140] The response return module 12 may include: a random number generation unit 121, a suite selection unit 122, a certificate acquisition unit 123, and a response return unit 124.

[0141] Random number generation unit 121 is used to generate the first random number based on the key negotiation request;

[0142] The suite selection unit 122 is used to select the target cipher suite from the list of available cipher suites;

[0143] The certificate acquisition unit 123 is used to acquire a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server's public key;

[0144] The response return unit 124 is used to determine the first random number, the first digital certificate, and the target cryptographic suite as the key negotiation response information, and return the key negotiation response information to the client.

[0145] The specific implementation methods of the random number generation unit 121, the kit selection unit 122, the certificate acquisition unit 123, and the response return unit 124 can be found in the above description. Figure 2 The description of step S101 in the corresponding embodiment will not be repeated here.

[0146] In one embodiment, each available cipher suite in the list of available cipher suites includes encryption algorithms supported by the client; the second random number is generated by the client based on the encryption algorithms included in the target cipher suite; the first digital certificate also includes first signature information that is signed using the private key of the trusted node, the first signature information being used by the client to verify the first digital certificate based on the public key of the trusted node, and to obtain the server public key after successful verification.

[0147] In one embodiment, the key negotiation response information further includes a certificate verification request, which requests the client to send its second digital certificate to the server; the client encryption information also carries the second digital certificate sent by the client to the server based on the certificate verification request; the second digital certificate is issued by the trusted node for the client, and the second digital certificate includes second signature information in which the trusted node's private key signs the second digital certificate;

[0148] The private key acquisition module 14 may include a certificate verification unit 141 and a private key acquisition unit 142.

[0149] The certificate verification unit 141 verifies the second digital certificate based on the node public key of the trusted node and the second signature information;

[0150] The private key acquisition unit 142 is used to acquire the server private key in a trusted execution environment when the verification is successful.

[0151] The specific implementation methods of the certificate verification unit 141 and the private key acquisition unit 142 can be found in the above description. Figure 2 The description of step S103 in the corresponding embodiment will not be repeated here.

[0152] In one embodiment, the server supports a secure transport layer protocol, and the key negotiation request is generated based on the secure transport layer protocol;

[0153] The data processing device 1 may also include: a program acquisition module 17, a program encapsulation module 18, and a toolkit integration module 19.

[0154] The program acquisition module 17 is used to acquire the key management logic program, the communication interface corresponding to the key management logic program, and the calling function corresponding to the key management logic program;

[0155] The program encapsulation module 18 is used to encapsulate the key management logic program as a trusted program, the calling function as a normal program, the trusted program, the communication interface and the normal program to obtain the key management software development kit.

[0156] The toolkit integration module 19 is used to integrate the key management software development kit into the security protocol library of the server, and to determine the trusted program in the key management software development kit integrated in the security protocol library as the trusted execution environment; the security protocol library refers to the protocol library corresponding to the secure transport layer protocol.

[0157] The specific implementation methods of the program acquisition module 17, the program encapsulation module 18, and the toolkit integration module 19 can be found in the above description. Figure 2 The description of step S103 in the corresponding embodiment will not be repeated here.

[0158] In one embodiment, the ordinary program includes a decryption function; the communication interface is used for communication between the ordinary program and the trusted program, and the communication interface includes a decryption function communication interface; the trusted program includes a decryption function logic program.

[0159] The decryption module 15 may include: a function call unit 151, a decryption unit 152, and a random number receiving unit 153.

[0160] Function call unit 151 is used to call the decryption function in the ordinary program, obtain the decryption function communication interface in the communication interface through the decryption function, and send the client encrypted information to the decryption function logic program through the decryption function communication interface;

[0161] Decryption unit 152 is used to decrypt the client encrypted information using the server private key in the decryption function logic program to obtain the second random number; the decryption function logic program is used to return the second random number to the normal program through the decryption function communication interface;

[0162] The random number receiving unit 153 is used to receive the second random number returned by the ordinary program.

[0163] The specific implementation methods of the function call unit 151, the decryption unit 152, and the random number receiving unit 153 can be found in the above description. Figure 2 The description of step S103 in the corresponding embodiment will not be repeated here.

[0164] In one embodiment, the session key includes an encryption key and a decryption key;

[0165] The data processing device 1 may further include: an encrypted data receiving module 21 and a data decryption module 22.

[0166] The encrypted data receiving module 21 is used to receive encrypted data sent by the client; the encrypted data is data obtained by the client encrypting the application data using the encryption key;

[0167] The data decryption module 22 is used to decrypt the encrypted data using the decryption key to obtain the application data.

[0168] The specific implementation methods of the encrypted data receiving module 21 and the data decryption module 22 can be found in the above description. Figure 2 The description of step S104 in the corresponding embodiment will not be repeated here.

[0169] In one embodiment, the data processing device 1 may further include a private key storage module 23.

[0170] The private key storage module 23 is used to obtain the server private key issued by the trusted node for the server and store the server private key in the trusted execution environment; the trusted execution environment is used to encrypt the server private key based on the environment encryption key corresponding to the trusted execution environment to obtain the encrypted server private key; the environment encryption key is derived from the environment root key corresponding to the trusted execution environment.

[0171] For details on the implementation of the private key storage module 23, please refer to the above. Figure 2 The description of step S104 in the corresponding embodiment will not be repeated here.

[0172] In one embodiment, the client is a data node in a blockchain network, and the server is a target consensus node in a consensus node cluster of the blockchain network;

[0173] The data processing device 1 may further include: a block generation module 24, a block sending module 25, a block consensus module 26, and a block on-chain module 27.

[0174] Block generation module 24 is used to receive business transaction data related to the target business sent by the data node, and generate transaction blocks based on the business transaction data;

[0175] Block signing module 24 is used to sign the transaction block based on the server private key in the trusted execution environment to obtain a block digital signature;

[0176] The block sending module 25 is used to send the transaction block and its digital signature to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes in the consensus node cluster other than the target consensus node; the block digital signature is used by the remaining consensus nodes to obtain the server public key corresponding to the target consensus node, verify the block digital signature based on the server public key, and, after the verification is successful, jointly reach a consensus on the transaction block with the target consensus node;

[0177] The block consensus module 26 is used to receive voting information returned by the remaining consensus nodes; the voting information is determined by the remaining consensus nodes after obtaining the server public key corresponding to the target consensus node, verifying the digital signature of the block based on the server public key, and only after the verification is successful.

[0178] Block-on-chain module 27 is used to determine the consensus result of the transaction block based on the voting information;

[0179] The block on-chain module 27 is also used to put the target block on the chain when the consensus result of the transaction block is a consensus pass result.

[0180] The specific implementation methods of the block generation module 24, block sending module 25, block consensus module 26, and block on-chain module 27 can be found in the above description. Figure 5 The descriptions of steps S201-S205 in the corresponding embodiments will not be repeated here.

[0181] In one embodiment, the number of remaining consensus nodes is at least two, and the number of voting information is at least two.

[0182] The block on-chain module 27 may include: a quantity determination unit 271 and a result determination unit 272.

[0183] The quantity determination unit 271 is used to determine the voting information with the voting type of "pass" from at least two voting information as the voting pass information;

[0184] The quantity determination unit 271 is further configured to obtain the total number of nodes corresponding to the target consensus node and the remaining consensus nodes, the number of nodes corresponding to the target consensus node, and the number of passes corresponding to the voting pass information;

[0185] The quantity determination unit 271 is further configured to add the number of nodes corresponding to the target consensus node to the number of nodes that have passed, so as to obtain the total number of nodes that have passed.

[0186] The result determination unit 272 is used to determine the consensus result of the transaction block based on the total number of nodes and the total number of nodes.

[0187] The specific implementation methods of the quantity determination unit 271 and the result determination unit 272 can be found in the above description. Figure 5 The description of step S205 in the corresponding embodiment will not be repeated here.

[0188] In this embodiment, after encapsulating the key management logic program into a software development kit (SDK), a trusted execution environment (TEX) can be determined based on the trusted program within the SSD. The server's private key can be stored within this TEX, and decryption using the private key also occurs within the TEX. Therefore, when the client and server negotiate session keys, the server's private key no longer needs to be stored on the server's hard drive. Since the TEX and the server's operating system are isolated, the server's private key stored in the TEX cannot be accessed externally. Data decrypted using the private key within the TEX is also unobtainable externally. Consequently, the session key negotiated based on the private key is also unknowable externally, effectively protecting the security of the private key and improving the security of the session key, thereby significantly enhancing the security of transmitted data. In summary, this application improves the security of the private key in session key negotiation scenarios, thereby enhancing communication security.

[0189] Further, please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 7 As shown above, Figure 6 The device 1 in the corresponding embodiment can be applied to the aforementioned computer device 8000. The computer device 8000 may include a processor 8001, a network interface 8004, and a memory 8005. Furthermore, the computer device 8000 also includes a user interface 8003 and at least one communication bus 8002. The communication bus 8002 is used to enable communication between these components. The user interface 8003 may include a display screen and a keyboard; optionally, the user interface 8003 may also include a standard wired interface or a wireless interface. The network interface 8004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 8005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 8005 may also be at least one storage device located remotely from the aforementioned processor 8001. Figure 7 As shown, the memory 8005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0190] exist Figure 7In the computer device 8000 shown, the network interface 8004 provides network communication functionality; the user interface 8003 is mainly used to provide an input interface for the user; and the processor 8001 can be used to call the device control application program stored in the memory 8005 to achieve:

[0191] The system retrieves the key negotiation request sent by the client and returns a key negotiation response to the client based on the request. The key negotiation response includes a first random number, the server's public key, and the target cipher suite.

[0192] Receive client-encrypted information sent by the client; the client-encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite;

[0193] The server's private key is obtained in the Trusted Execution Environment (TEE). The encrypted information from the client is then decrypted using the server's private key in the TEE to obtain a second random number. The TEE refers to a trusted program in a key management software development kit (SDK). The key management software development kit is a software development kit that encapsulates the key management logic program. The TEE is isolated from the server's operating system.

[0194] A session key is generated based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt application data during the transmission of application data with the client.

[0195] It should be understood that the computer device 8000 described in the embodiments of this application can execute the foregoing text. Figures 2 to 5 The description of the data processing method in the corresponding embodiment can also be performed as described above. Figure 6 The description of the data processing apparatus 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0196] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing computer device 1000. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figures 2 to 5 The description of the data processing method in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0197] The aforementioned computer-readable storage medium can be an internal storage unit of the data processing apparatus or computer device provided in any of the foregoing embodiments, such as a hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0198] One aspect of this application provides a computer program product or computer program including 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 method provided in one aspect of the embodiments of this application.

[0199] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0200] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0201] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0202] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method, characterized in that, The method is applied to communication between a client and a server based on a secure transport layer protocol. The method includes: The server receives a key negotiation request sent by the client and returns key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite; The system receives client-encrypted information sent by the client; the client-encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite. The server's private key is obtained in a trusted execution environment, and the client's encrypted information is decrypted based on the server's private key in the trusted execution environment to obtain the second random number; the trusted execution environment is isolated from the server's operating system. A session key is generated based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt the application data during the transmission of application data with the client. The construction process of the trusted execution environment includes: obtaining a key management logic program, a communication interface corresponding to the key management logic program, and a calling function corresponding to the key management logic program; treating the key management logic program as a trusted program and the calling function as a regular program, and encapsulating the trusted program, the communication interface, and the regular program to obtain a key management software development kit (SDK); integrating the SSD into the security protocol library of the server, and determining the trusted program in the SSD integrated into the security protocol library as the trusted execution environment; the security protocol library refers to the protocol library corresponding to the secure transport layer protocol; the regular program calls the key management logic program in the trusted program through the communication interface to execute key management tasks, and the key management logic program includes: a key initialization logic program, a key sealing logic program, a key decryption logic program, a signature function logic program, and a decryption function logic program.

2. The method according to claim 1, characterized in that, The key negotiation request carries a list of available cipher suites for the client; The step of returning key negotiation response information to the client based on the key negotiation request includes: The first random number is generated based on the key negotiation request; Select the target cipher suite from the list of available cipher suites; Obtain a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server's public key; The first random number, the first digital certificate, and the target cryptographic suite are identified as the key negotiation response information, and the key negotiation response information is returned to the client.

3. The method according to claim 2, characterized in that, Each available cipher suite in the list of available cipher suites includes encryption algorithms supported by the client; the second random number is generated by the client based on the encryption algorithms included in the target cipher suite; the first digital certificate also includes first signature information that is signed by the trusted node's private key, the first signature information being used by the client to verify the first digital certificate based on the trusted node's public key, and to obtain the server's public key after successful verification.

4. The method according to claim 1, characterized in that, The key negotiation response information also includes a certificate verification request, which is used to request the client to send the client's second digital certificate to the server. The client encryption information also carries the second digital certificate sent by the client to the server based on the certificate verification request; The second digital certificate is issued by a trusted node for the client, and the second digital certificate includes second signature information in which the trusted node signs the second digital certificate with its node private key; The step of obtaining the server private key in a trusted execution environment includes: The second digital certificate is verified based on the public key of the trusted node and the second signature information. Upon successful verification, the server's private key is obtained within the trusted execution environment.

5. The method according to claim 1, characterized in that, The ordinary program includes a decryption function; the communication interface includes a decryption function communication interface. The step of decrypting the client's encrypted information based on the server's private key in the trusted execution environment to obtain the second random number includes: The decryption function in the ordinary program is called, and the decryption function communication interface is obtained in the communication interface through the decryption function. The client encrypted information is sent to the decryption function logic program through the decryption function communication interface. In the decryption function logic program, the server private key is used to decrypt the client's encrypted information to obtain the second random number; the decryption function logic program is used to return the second random number to the normal program through the decryption function communication interface; Receive the second random number returned by the normal procedure.

6. The method according to claim 1, characterized in that, The session key includes an encryption key and a decryption key; The method further includes: Receive encrypted data sent by the client; the encrypted data is obtained by the client encrypting the application data using the encryption key; The encrypted data is decrypted using the decryption key to obtain the application data.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the server private key issued by the trusted node for the server, and store the server private key in the trusted execution environment; the trusted execution environment is used to encrypt the server private key based on the environment encryption key corresponding to the trusted execution environment to obtain the encrypted server private key; the environment encryption key is derived from the environment root key corresponding to the trusted execution environment.

8. The method according to claim 1, characterized in that, The client is a data node in the blockchain network, and the server is a target consensus node in the consensus node cluster of the blockchain network; The method further includes: Receive business transaction data related to the target business sent by the data node, and generate a transaction block based on the business transaction data; In the trusted execution environment, the transaction block is signed based on the server's private key to obtain a digital signature for the block; The transaction block and its digital signature are sent to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes in the consensus node cluster other than the target consensus node; the digital signature is used by the remaining consensus nodes to obtain the server public key corresponding to the target consensus node, verify the digital signature of the block based on the server public key, and, after the verification is successful, jointly reach a consensus on the transaction block with the target consensus node; The remaining consensus nodes receive voting information returned by the remaining consensus nodes. The voting information is determined by the remaining consensus nodes after they obtain the server public key corresponding to the target consensus node, verify the digital signature of the block based on the server public key, and the verification is successful. The consensus result of the transaction block is determined based on the voting information. When the consensus result of the transaction block is a consensus pass, the target block is added to the blockchain.

9. The method according to claim 8, characterized in that, The number of remaining consensus nodes is at least two, and the number of voting information is at least two. The consensus result for determining the transaction block based on the voting information includes: Among at least two sets of voting information, those with the voting type "pass" are identified as passing voting information; Obtain the total number of nodes corresponding to the target consensus node and the remaining consensus nodes, the number of nodes corresponding to the target consensus node, and the number of passes corresponding to the voting pass information; Add the number of nodes corresponding to the target consensus node to the number of nodes that have passed to obtain the total number of nodes that have passed. The consensus result of the transaction block is determined based on the total number of nodes and the total number of nodes.

10. A data processing apparatus, characterized in that, The device is used as a server in a communication process, whereby the communication process refers to the process of communication between a client and the server based on a secure transport layer protocol. The device includes: The request retrieval module is used to retrieve key negotiation requests sent by the client; The response return module is used to return key negotiation response information to the client based on the key negotiation request; the key negotiation response information includes a first random number, the server public key, and the target cipher suite. An encrypted information receiving module is used to receive client encrypted information sent by the client; the client encrypted information refers to the information obtained by the client encrypting a second random number based on the server's public key, and the second random number is generated by the client based on the target cipher suite; The private key acquisition module is used to obtain the server's private key in a trusted execution environment; A decryption module is used to decrypt the client's encrypted information based on the server's private key in the trusted execution environment to obtain the second random number; the trusted execution environment is isolated from the server's operating system; The session key generation module is used to generate a session key based on the first random number, the second random number, and the third random number carried in the key negotiation request; the session key is used to encrypt or decrypt the application data during the transmission of application data with the client. The construction process of the trusted execution environment includes: obtaining a key management logic program, a communication interface corresponding to the key management logic program, and a calling function corresponding to the key management logic program; treating the key management logic program as a trusted program and the calling function as a regular program, and encapsulating the trusted program, the communication interface, and the regular program to obtain a key management software development kit (SDK); integrating the SSD into the security protocol library of the server, and determining the trusted program in the SSD integrated into the security protocol library as the trusted execution environment; the security protocol library refers to the protocol library corresponding to the secure transport layer protocol; the regular program calls the key management logic program in the trusted program through the communication interface to execute key management tasks, and the key management logic program includes: a key initialization logic program, a key sealing logic program, a key decryption logic program, a signature function logic program, and a decryption function logic program.

11. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to cause the computer device to execute the method according to any one of claims 1-9.

12. 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 to execute the method of any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, the computer instructions being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-9.

Images