CN116781292A

CN116781292A - Data processing method, device, equipment and readable storage medium

Info

Publication number: CN116781292A
Application number: CN202210225128.2A
Authority: CN
Inventors: 张慧; 蓝虎; 王宗友
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-03-07
Filing date: 2022-03-07
Publication date: 2023-09-19

Abstract

The application discloses a data processing method, a device, equipment and a readable storage medium, wherein the method comprises the following steps: the server acquires 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 comprises a first random number, a server public key and a target cipher suite; receiving client encryption information sent by a client; decrypting the client encrypted information based on the server private key in the trusted execution environment to obtain a second random number; generating a session key based on the first random number, the second random number and a third random number carried in the key negotiation request; the session key is used to encrypt or decrypt application data during transmission with the client. By adopting the application, the security of the private key can be improved in the scene of negotiating the session key, thereby improving the communication security. The embodiment of the application can be applied to vehicle-mounted scenes.

Description

Data processing method, device, equipment and readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a data processing method, apparatus, device, and readable storage medium.

Background

Currently, when two devices desire to encrypt data for transmission via a secure transport layer protocol (Transport Layer Security, TLS), a session key is negotiated together for encrypting the transmitted data.

For the negotiation of the session key, a private key of the device is needed, however, at present, the private key of the device is mainly stored in the device in the clear, the private key is at risk of being stolen by a third party, and the session key can be decrypted and acquired by the third party after being stolen, so that data in communication transmission can be acquired. In the TLS transmission scenario, the storage and use modes of the private key are at risk, and the security of the transmitted data is very low.

Disclosure of Invention

The embodiment of the application provides a data processing method, a device, equipment and a readable storage medium, which can improve the security of a private key in the scene of negotiating a session key, thereby improving the communication security.

In one aspect, an embodiment of the present application provides a data processing method, including:

the server acquires 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 comprises a first random number, a server public key and a target cipher suite;

Receiving client encryption information sent by a client; the client side encryption information is information obtained by encrypting a second random number by the client side based on a server public key, and the second random number is generated by the client side based on a target password suite;

acquiring a server private key in a trusted execution environment, and decrypting the client encrypted information based on the server private key in the trusted execution environment to obtain a 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 packaging a key management logic program; the trusted execution environment is isolated from the operating system of the server;

generating a session key based on the first random number, the second random number and a third random number carried in the key negotiation request; the session key is used to encrypt or decrypt application data during transmission with the client.

In one aspect, an embodiment of the present application provides a data processing apparatus, including:

the request acquisition module is used for acquiring a key negotiation request sent by the client;

a response return module, configured to return 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 cipher suite;

The encryption information receiving module is used for receiving client encryption information sent by the client; the client encryption information is information obtained by encrypting a second random number by the client based on the server public key, and the second random number is generated by the client based on the target password suite;

the private key acquisition module is used for acquiring a server private key in the trusted execution environment;

the decryption module is used for decrypting the client encrypted information based on the server 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 packaging a key management logic program; the trusted execution environment is isolated from the operating system of the server;

a session key generation module, configured to generate a session key based on the first random number, the second random number, and a third random number carried in the key negotiation request; the session key is used for encrypting or decrypting the application data in the process of transmitting the application data with the client.

In one embodiment, the key agreement request carries a list of available cipher suites for the client;

a response return module comprising:

a random number generation unit configured to generate the first random number based on the key negotiation request;

a suite selection unit, configured to select the target cipher suite from the available cipher suite list;

a certificate acquisition unit for acquiring a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server public key;

and the response return unit is used for determining the first random number, the first digital certificate and the target cipher suite as the key negotiation response information and returning the key negotiation response information to the client.

In one embodiment, each available cryptographic kit in the list of available cryptographic kits includes an encryption algorithm supportable by the client; the second random number is generated by the client based on an encryption algorithm included in the target cipher suite; the first digital certificate further comprises first signature information for signing the first digital certificate by adopting a node private key of the trusted node, wherein the first signature information is used for verifying the first digital certificate by the client based on the node private key of the trusted node, and the server public key is obtained after verification is passed.

In one embodiment, the key negotiation response information further includes a certificate verification request, where the certificate verification request is used to request the client to send a second digital certificate of the client to the server; the client encryption information also carries the second digital certificate sent to the server by the client based on the certificate verification request; the second digital certificate is issued by the trusted node for the client, and the second digital certificate comprises second signature information for signing the second digital certificate by a node private key of the trusted node;

the private key acquisition module comprises:

a certificate verification unit configured to verify the second digital certificate based on a node public key of the trusted node and the second signature information;

and the private key acquisition unit is used for acquiring the server private key in the trusted execution environment when the verification is passed.

In one embodiment, the server supports a secure transport layer protocol, the key agreement request being generated based on the secure transport layer protocol;

the data processing apparatus further includes:

the program acquisition module is used for acquiring 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;

The program packaging module is used for taking the key management logic program as a trusted program, taking the calling function as a common program, and packaging the trusted program, the communication interface and the common program to obtain the key management software development kit;

the tool pack integration module is used for integrating the key management software development tool pack into a security protocol library of the server and determining the trusted program in the key management software development tool pack integrated in the security protocol library as the trusted execution environment; the safety protocol library refers to a protocol library corresponding to the safety transmission layer protocol.

In one embodiment, the generic program includes a decryption function; the communication interface is used for communicating between the common program and the trusted program, and comprises a decryption function communication interface; the trusted program comprises a decryption function logic program;

a decryption module comprising:

a function calling unit, configured to call the decryption function in the normal program, obtain the decryption function communication interface from 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;

The decryption unit is used for decrypting the client encrypted information by adopting the server private key in the decryption function logic program to obtain the second random number; the decryption function logic program is used for returning the second random number to the common program through the decryption function communication interface;

and the random number receiving unit is used for receiving the second random number returned by the common program.

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

the data processing apparatus further includes:

the encrypted data receiving module is used for receiving the encrypted data sent by the client; the encrypted data is obtained by encrypting the application data by the client by adopting the encryption key;

and the data decryption module is used for decrypting the encrypted data by adopting the decryption key to obtain the application data.

In one embodiment, the data processing apparatus further comprises:

the private key storage module is used for acquiring the server private key issued by the trusted node for the server and storing the server private key into the trusted execution environment; the trusted execution environment is used for encrypting the server private key based on an environment encryption key corresponding to the trusted execution environment to obtain an encrypted server private key; the environment encryption key is derived from an environment root key corresponding to the trusted execution environment.

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

the data processing apparatus further includes:

the block generation module is used for receiving service transaction data which are sent by the data node and are associated with the target service, and generating a transaction block according to the service transaction data;

the block signature module is used for signing the transaction block based on the server private key in the trusted execution environment to obtain a block digital signature;

the block sending module is used for sending the transaction block and the block digital signature to the rest consensus nodes; the remaining consensus nodes are the consensus nodes except the target consensus node in the consensus node cluster; the block digital signature is used for the remaining consensus nodes to acquire a server public key corresponding to the target consensus node, the block digital signature is checked based on the server public key, and the block digital signature and the target consensus node jointly carry out consensus on the transaction block after the block digital signature passes the check;

the block consensus module is used for receiving voting information returned by the residual consensus nodes; the voting information is obtained by the rest consensus nodes after the server public key corresponding to the target consensus node is obtained, the block digital signature is checked based on the server public key, and the block digital signature is determined after the check is passed;

The block uplink module is used for determining the consensus result of the transaction block based on the voting information;

and the block uplink module is also used for uplink the target block when the consensus result of the transaction block is a consensus passing result.

In one embodiment, the number of the remaining consensus nodes is at least two, and the number of the voting information is at least two;

the block uplink module includes:

the quantity determining unit is used for determining the voting information with the voting type being the passing type in the at least two voting information as voting passing information;

the quantity determining unit is further used for obtaining the total quantity of nodes corresponding to the target consensus nodes and the residual consensus nodes, the quantity of nodes corresponding to the target consensus nodes and the passing quantity corresponding to the voting passing information;

the number determining unit is further used for adding the number of nodes corresponding to the target consensus nodes with the passing number to obtain the total number of nodes passing through;

and the result determining unit is used for determining the consensus result of the transaction block according to the total number of the node passes and the total number of the nodes.

In one aspect, an embodiment of the present application provides a computer device, including: a processor and a memory;

The memory stores a computer program that, when executed by the processor, causes the processor to perform the methods of embodiments of the present application.

In one aspect, embodiments of the present application provide a computer-readable storage medium storing a computer program, the computer program comprising program instructions that, when executed by a processor, perform a method according to embodiments of the present application.

In one aspect of the application, a computer program product or computer program is provided that includes computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the method provided in an aspect of the embodiment of the present application.

In the embodiment of the application, after the key management logic program is packaged to obtain the software development kit, the trusted execution environment can be determined according to the trusted program in the software development kit, the server private key of the server can be stored in the trusted execution environment, and decryption is performed in the trusted execution environment when the server private key is used for decryption. Therefore, when the client and the server negotiate the session key, the server private key does not need to be stored on the hard disk of the server, and because the trusted execution environment is mutually isolated from the operating system of the server, the server private key cannot be snooped by the outside when being stored in the trusted execution environment, and data obtained by decrypting the private key in the trusted execution environment cannot be obtained by the outside, so that the session key negotiated based on the private key cannot be known by the outside, the security of the private key can be well protected, the security of the session key can be well improved, and the security of the transmitted data can be well improved. In summary, the application can improve the security of the private key in the scene of negotiating the session key, thereby improving the communication security.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a diagram of a network architecture according to an embodiment of the present application;

FIG. 2 is a schematic flow chart of a data processing method according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a key management software development kit according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a blockchain dual-layer chain for TLS communications according to an embodiment of the present application;

FIG. 5 is a flowchart of a method for providing a trusted execution environment based uplink block according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

Referring to fig. 1, fig. 1 is a network architecture diagram according to an embodiment of the present application. As shown in fig. 1, the network architecture may include a service server 1000 and a terminal device cluster, which may include one or more terminal devices, the number of which will not be limited here. As shown in fig. 1, the plurality of terminal devices may include a terminal device 100a, a terminal device 100b, terminal devices 100c, …, a terminal device 100n; as shown in fig. 1, the terminal devices 100a, 100b, 100c, …, 100n may respectively perform network connection with the service server 1000, so that each terminal device may perform data interaction with the service server 1000 through the network connection.

It will be appreciated that each terminal device as shown in fig. 1 may be provided with a target application, and when the target application is run in each terminal device, data interaction may be performed between the target application and the service server 1000 shown in fig. 1, so that the service server 1000 may receive service data from each terminal device. The target application may include an application having a function of displaying data information such as text, image, audio, and video. For example, the application may be a multimedia class application (e.g., a video application), an entertainment class application (e.g., a gaming application), a social application, an educational application, and so forth. It should be understood that, in the present application, the service data may be application related data corresponding to an application, for example, when the target application is a video application, the service data may refer to video related data; where the target application is a gaming application, the business data may refer to game related data, which will not be illustrated herein.

It will be appreciated that in the case of data interaction between the terminal device and the service server, the transmission channel of the hypertext transfer protocol (Hyper Text Transfer Protocol, HTTP) may be used for the common, publicly available data. Among other things, the hypertext transfer protocol (HTTP) is a simple request-response protocol that generally runs on top of the transmission control protocol (Transmission Control Protocol, TCP). It specifies what messages the client might send to the server and what responses it gets. The header of the request and response messages are given in ASCII form; whereas the message content has a MIME-like format. For special, private data that needs to be transmitted in an encrypted manner, the secure transmission channel of the secure transport layer protocol (Transport Layer Security, TLS) may be used for transmission. The TLS according to the embodiments of the present application is used to provide confidentiality and data integrity between two communication applications, and the protocol is composed of two layers, including a TLS Record protocol (TLS Record) and a TLS Handshake protocol (TLS Handshake).

The TLS protocol has the advantage of being uncoupled from higher-level application layer protocols (e.g., HTTP protocol, FTP protocol, telent protocol, etc.). The application layer protocol can run transparently on top of the TLS protocol, which performs the negotiations and authentications needed to create the encrypted channels. The data transmitted by the application layer protocol is encrypted when passing through the TLS protocol, so that the privacy of communication is ensured. It can be understood that, for the TLS protocol, a client and a server need to be configured to use the TLS protocol, and in the embodiment of the present application, the terminal device may be a client, and the server may be a service server. With early deployment, once both the client and server agree to use the TLS protocol for data transfer, a stateful connection can be negotiated for transferring application data by using a TLS handshake procedure. Through the TLS handshake, the client and server may negotiate various parameters for creating a secure connection. The process of performing the TLS handshake procedure between the client and the server may be actually understood as a process of negotiating a session key between the client and the server, and is used for encrypting and decrypting the application data when the application data is subsequently transmitted.

It can be understood that in the process of negotiating the session key between the client and the server, the private key of the server is required, but in order to enhance the security of the private key of the server, the TLS protocol is modified in order to improve the security of communication, where the private key is used may be executed in a trusted execution environment (Trusted Execution Environments, TEE), and by storing and using the private key in the trusted execution environment, it may be avoided that the relevant private key in TLS is obtained by external acquisition. The trusted execution environment according to the embodiment of the present application is a technology based on hardware protection data and algorithm, is an isolated environment of a processor and a memory, and only a central processing unit (Central Processing Unit, CPU) can access an application program in the trusted execution environment, and accesses to the trusted execution environment by other layers (such as other hardware, a kernel, other application programs, etc.) are blocked by the CPU. Therefore, by storing the private key and using the private key in the trusted execution environment, the security of the private key can be well improved, the possibility of leakage of the private key is reduced, the security of the session key can be protected, and the transmission security of the application data can be improved when the TLS protocol is adopted to transmit the application data.

For ease of understanding, the following will specifically describe a process of performing TLS handshake for a client and a server based on a trusted execution environment, negotiating various parameters to create a secure connection (i.e., a process of negotiating session keys through TLS handshake), and for the client and the server to perform TLS handshake based on the trusted execution environment, the following steps 1-6 may be specifically included:

step 1: when a client connects to a server supporting the TLS protocol, it is required to create a secure connection, a list of understandably supported cryptographic suites (including cryptographic algorithms, cryptographic hash functions, etc.) is listed, and the client randomly generates a random number, and a handshake begins.

Step 2: the server selects and decides a target cipher suite from the cipher suite list, and informs the client of the target cipher suite and the random number randomly generated by the server.

Step 3, the server sends back its digital certificate, which typically contains the name of the server, the trusted certificate authority (Certification Authority, CA) and the public key of the server.

Step 4, the client confirms the validity of the certificate issued by the client, after the verification is passed, in order to generate a session key for secure connection, the client can generate another random number (which can be called a random key) by adopting a target cipher suite, the client can encrypt the random key generated randomly by using the public key of the server, and the client can send the encrypted random key to the server.

And step 5, the server acquires the private key of the server from the trusted execution environment and decrypts the private key to obtain the random key generated by the client. It should be appreciated that since the private key is stored in a trusted execution environment, the outside cannot snoop, and only the server can decrypt it using the private key, providing extremely high security.

And 6, the server and the client generate a symmetric key for encryption and decryption by using the random numbers and the random keys of the two parties, wherein the symmetric key can be a session key negotiated by the two parties. The symmetric key may be used for encryption or decryption at a later time of transmission of the application data.

It should be understood that steps 1-6 are TLS protocol handshaking procedures, and the connection after the handshaking is completed is very secure until the connection is closed. If any of the above steps fail, the TLS handshake procedure also fails and all connections are broken. For a specific implementation manner of deploying a trusted execution environment in a server, reference may be made to the description in the corresponding embodiment of fig. 2 below.

The embodiment of the application can select one terminal device from a plurality of terminal devices as a target terminal device, and the terminal device can comprise: smart terminals carrying multimedia data processing functions (e.g., video data playing functions, music data playing functions) such as smart phones, tablet computers, notebook computers, desktop computers, smart televisions, smart speakers, desktop computers, smart watches, smart voice interaction devices, car-mounted devices, and the like, but are not limited thereto. For example, the embodiment of the present application may take the terminal device 100a shown in fig. 1 as the target terminal device, where the target terminal device may be integrated with the target application, and at this time, the target terminal device may perform data interaction between the target application and the service server 1000.

It will be appreciated that the method provided by the embodiments of the present application may be performed by a computer device, including but not limited to a terminal device or a service server. The service server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, basic cloud computing services such as big data and artificial intelligence platforms.

The terminal device and the service server may be directly or indirectly connected through wired or wireless communication, which is not limited herein.

Alternatively, it is understood that the computer device (e.g., the service server 1000, the terminal device 100a, the terminal device 100b, etc.) may be a node in a distributed system, where the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the plurality of nodes through a network communication. For ease of understanding, the blockchain will be specifically described as follows: the blockchain is a novel application mode of computer technologies such as distributed data storage, peer-To-Peer (P2P) transmission, consensus mechanism, encryption algorithm and the like; which is essentially a de-centralized database, is a string of data blocks that are generated in association using cryptographic methods. The data block herein may also be referred to as a block, which is essentially a block for recording the validity (i.e., anti-counterfeit) of the data information. Networks based on blockchains and point-to-point networks (P2P networks) may be referred to as blockchain networks. It should be appreciated that any computer device (i.e., node) in the blockchain network may be either a terminal device or a server. Nodes in the blockchain network can also comprise a trusted execution environment, and private keys of the nodes can also be stored in the trusted execution environment; the use of the private key of the nodes can be performed in a trusted execution environment, so that the communication security between the nodes can be protected.

It should be noted that, a computer device performing certificate issue in the blockchain network may be referred to as a node issue device (abbreviated as an issue node). To better enable certificate issuance, the issuing node in the embodiments of the present application may refer to a node in a blockchain network that provides a certificate issuing server by performing trusted computing (Trusted Computing, TC) in a trusted execution environment; the feasible execution environment may be a secure area located in the issuing node and isolated from an operating system (Soc) of the issuing node; so-called trusted computing, which may also be referred to as trusted computing, is a technology that is driven and developed by a trusted computing group (trusted computing cluster, abbreviated TCPA).

It should be appreciated that in physically deploying a blockchain network, nodes corresponding to key departments involved in the blockchain network (e.g., the administrative departments of an enterprise) may be selected as issuing nodes. The issuing node may at least include: trusted execution environments, other areas, and hardware supporting the issuing node. Wherein the trusted execution environment may include a trusted application (Trusted Application, TA), an API (Application Programming Interface, application program interface) of the trusted execution environment, and a security system; the trusted execution environment can ensure the safe transmission, storage and processing of related data and the confidentiality and integrity of TA execution through the combination of hardware and software. Other regions may include other modules, other API interfaces, and an operating system (e.g., an android system); the hardware may then include a video transmitter for communication, a Central Processing Unit (CPU), a hard disk, etc. It can be appreciated that the security of the private key of the node can be protected while the secure issuance of the certificate is protected by the trusted execution environment in the issuing node and the trusted execution environments in the respective nodes.

In the specific embodiment of the present application, if data related to user information, user data, and the like (such as the above-mentioned transmitted application data includes data related to user information, user data, and the like), the data related to user information, user data, and the like need to be acquired with user authorization approval. That is, when the above embodiments of the present application are applied to specific products or technologies, user approval or consent needs to be obtained, and the collection, use and processing of user-related data needs to comply with relevant laws and regulations and standards of the relevant countries and regions.

For ease of understanding, please refer to fig. 2, fig. 2 is a flow chart of a data processing method according to an embodiment of the present application. The data processing method may be performed by a computer device, where the computer device may refer to a server (e.g., a service server in the embodiment corresponding to fig. 1 described above) or may refer to a terminal device (e.g., any one of the terminal devices in the terminal device cluster in the embodiment corresponding to fig. 1 described above). As shown in fig. 3, the flow of the data processing method may at least include the following steps S101 to S104:

Step S101, a server acquires a key negotiation request sent by a client, and returns key negotiation response information to the client based on the key negotiation request; the key agreement response information includes a first random number, a server public key, and a target cipher suite.

In the application, when some special data with privacy needs to be transmitted between the client and the server, the data transmission channel of the TLS protocol can be adopted to carry out encryption transmission on the application data. Once both the client and the server agree to use the TLS protocol for data transfer, a TLS handshake is required to create a secure connection, i.e., to co-negotiate a session key, based on the TLS protocol, prior to communication between the client and the server for encrypting the application data or decrypting the encrypted application data during subsequent transfer of the application data. When a client connects to a server supporting the TLS protocol, it is required to create a secure connection, and a list of understandably supported cryptographic suites (including cryptographic algorithms, cryptographic hash functions, etc.) is listed, along with random numbers randomly generated by the client, a handshake begins.

The key agreement request here may in fact be understood as a request sent by the client to the server requiring the creation of a secure connection, which key agreement request may carry a list of key suites (which may be referred to as a list of available cipher suites) that the client can understand, wherein each available cipher suite in the list of available cipher suites may contain a cryptographic key algorithm, a cryptographic hash function, a hash function, etc. The key agreement request may also carry a random number (which may be referred to as a third random number) that the client randomly generates. When the client sends a key agreement request to the server carrying a list of available cipher suites, a third random number, the TLS handshake between the client and the server can be characterized as beginning (i.e. starting to create a secure connection between the client and the server).

Further, the server may return a response message (which may be referred to as key agreement response message) to the client based on the key agreement request. The specific implementation mode of the method can be as follows: the first random number may be generated based on the key agreement request; a target cipher suite may be selected in the list of available cipher suites; a first digital certificate issued by a trusted node for a server may be obtained; wherein the first digital certificate comprises a server public key; the first random number, the first digital certificate, and the target cipher suite may then be determined to be key agreement response information, which is returned to the client.

It will be appreciated that the key agreement response information may include the target cipher suite selected by the server from the list of available cipher suites, the digital certificate of the server (which may be referred to herein as the first digital certificate for ease of distinction), and the random number generated by the server (which may be referred to herein as the first random number for ease of distinction). When receiving the key negotiation request, the server may select one cipher suite from the available cipher suite list as a target cipher suite, may acquire a digital certificate of the server, generate a random number, and may form key negotiation response information based on the target cipher suite, the first digital certificate and the first random number, where the server may return the key negotiation response information to the client. The digital certificate of the server may be issued by a trusted node, where the trusted node may refer to an individual or organization trusted by a client, a server, or a browser.

Step S102, receiving client encryption information sent by a client; the client encrypted information is information obtained by encrypting a second random number by the client based on a server public key, and the second random number is generated by the client based on a target cipher suite.

In the application, for each digital certificate, the signature information of signing the digital certificate by adopting the node private key can be included, so that for the first digital certificate of the server, the signature information (which can be called as first signature information) of signing the first digital certificate by adopting the node private key of the trusted node is also included, after the client receives the key negotiation information, the first digital certificate can be verified based on the node public key of the trusted node, and after the verification is passed, the server public key can be obtained. In addition, since each cipher suite includes the encryption algorithm that the client can support, the client can generate a new random number (which may be called a second random number or a random preparation key) based on the encryption algorithm in the target cipher suite in the key negotiation response information, and the client can encrypt the second random number by using the obtained server public key, so as to obtain an encrypted message (which may be called client encrypted message), and the client encrypted message can decrypt the encrypted message only by using the private key of the server.

That is, each available cipher suite in the list of available cipher suites includes an encryption algorithm that can be supported by the client; and the second random number is generated by the client based on an encryption algorithm included in the target cipher suite; the first digital certificate also comprises first signature information for signing the first digital certificate by adopting a node private key of the trusted node, the first signature information is used for verifying the first digital certificate by the client based on the node public key of the trusted node, a server public key is acquired after verification is passed, and the client encrypts the second random number by adopting the server public key after acquiring the server public key to obtain client encryption information.

Step S103, a server private key is obtained in a trusted execution environment, and the client encrypted information is decrypted based on the server private key in the trusted execution environment to obtain a second random number; the trusted execution environment comprises trusted programs in a key management software development kit, wherein the key management software development kit is a software development kit obtained by packaging a key management logic program; the trusted execution environment is isolated from the operating system of the server.

In the application, after the client returns the client encryption information, the server can acquire the server private key from the trusted execution environment, and decrypt the client encryption information in the trusted execution environment based on the server private key to obtain the second random number. The trusted execution environment may include trusted programs in a software development kit, in order to improve security of a private key in a TLS communication scenario, in this embodiment of the present application, a TLS protocol may be modified, and a key management manner may be adopted to secure a key, and by implementing a software layer, related logic programs of key management (such as a key initialization logic program, a sealed key logic program, an unsealed key logic program, a logic program that uses a private key to sign, a logic program that uses a private key to decrypt, etc.) are packaged to obtain a key management software development kit (i.e., key management sdk); the key management software development kit may be integrated into a TLS library (i.e., an open source library corresponding to the TLS protocol, which may also be referred to as a security protocol library), and the trusted program in the software development kit integrated in the TLS library may be used as a trusted execution environment of the server, where storage and use of a private key of the server may be performed in the trusted program.

As can be seen from the foregoing, the server may support a secure transport layer protocol (TLS protocol), the key negotiation request is generated based on the secure transport layer protocol, and the specific implementation manner of encapsulating the key management sdk and integrating it into the TLS library to obtain the trusted execution environment may be: 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 can be obtained; then, the key management logic program can be used as a trusted program, the calling function is used as a common program, and the trusted program, the communication interface and the common program can be packaged to obtain a key management software development kit; subsequently, the key management software development kit can be integrated into a security protocol library of the server, and a trusted program in the key management software development kit integrated in the security protocol library can be determined as a trusted execution environment; the security protocol library refers to a protocol library corresponding to a security transport layer protocol.

It will be appreciated that the present application may encapsulate trusted portions (key management logic programs executing in a secure environment), untrusted portions (code executing in a common application program), and communication interfaces in a hardware security mechanism to yield key management sdk. The trusted portion may operate on keys (e.g., private key initialization, private key storage, private key decryption, etc.), and the untrusted portion may communicate with the trusted portion through the communication interface so that a program associated with the trusted portion may be invoked to process the associated logic. In the hardware security mechanism, the trusted part can be understood as a black box, and the outside of the content in the black box can not be snooped, and the black box can be understood as a trusted execution environment in the hardware security mechanism. The trusted part in the hardware security mechanism only exposes the communication interface relevant to data computing (for example, for a secret key, only the communication interface relevant to secret key initialization can be exposed, the communication interface which adopts the secret key for signing, the communication interface which adopts the secret key for decryption, etc.), and the secret data (such as the secret key) can never leave the black box (the trusted part), so that the security of the secret key can be ensured. The data in the black box is visible only to the CPU, and the operating system, common applications, and hardware outside the CPU cannot snoop the contents of the black box.

The embodiment of the present application may implement the key management sdk by using a hardware security mechanism, and may encapsulate a trusted part of the program in the hardware security mechanism (i.e., a key management logic program executed in a black box), and the key management sdk may also be divided into a trusted program (i.e., a key management logic program) and an untrusted program (which may be referred to as a normal program, i.e., a normal code including a calling function). The key management logic program may operate the private key, and the normal program may communicate with the trusted program through the communication interface, and the normal program may call the relevant key function program in the trusted program through the communication interface. That is, the key management sdk includes a trusted program (key management logic program), a normal program (including a calling function), and a communication interface (for communication between the normal program and the trusted program), and since the trusted program can only run in the CPU and cannot make a system call, all relevant file operations, network operations, and the like need to be implemented in the normal program. When the private key is expected to be used, the common program can send the data to be processed to the trusted program through the related communication interface by calling the related function in the common program, and then the related operation can be carried out on the data to be processed by adopting the private key in the trusted program.

For ease of understanding, please refer to fig. 3, fig. 3 is a schematic structural diagram of a key management software development kit according to an embodiment of the present application. As shown in fig. 3, the key management software development kit may include a trusted part (i.e., a trusted program) and an untrusted part (i.e., a normal program), the trusted program may include a key management logic program (e.g., a key initialization logic program, a sealing key logic program, a decryption key logic program, a signature function logic program, a decryption function logic program, etc.), the normal program may include a call function (e.g., a call function corresponding to the key initialization logic program, the sealing key logic program, the decryption key logic program, the signature function logic program, the decryption function logic program, etc.), and the key management software development kit may further include a communication interface for communicating between the trusted program and the trusted program. The key management software development kit is used for storing the key management software development kit, wherein the key management software development kit is used for storing the key management software development kit, and the key management software development kit is used for managing the key management software development kit. When the key management software development kit is deployed in the TLS library, the key management software development kit can be used as a trusted execution environment of the server, and all operations related to the server private key are executed in the trusted execution environment, so that the security of the server private key can be well protected.

From the above, it can be seen that, if all operations related to the private key are performed in a trusted execution environment (trusted program), the normal program in the embodiment of the present application may include a decryption function; the communication interface is used for communicating between the common program and the trusted program, and the communication interface can comprise a decryption function communication interface; the trusted program may include a decryption function logic program; the specific implementation manner of decrypting the client encrypted information based on the server private key in the trusted execution environment to obtain the second random number may be: the decryption function in the common program can be called, the decryption function communication interface can be obtained in the communication interface through the decryption function, and then the client encrypted information can be sent to the decryption function logic program through the decryption function communication interface; the server private key can be adopted 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 for returning the second random number to the common program through the decryption function communication interface; the server may then receive the second random number returned by the normal program.

Optionally, in a possible embodiment, the server may further verify the digital certificate of the client, and then the key negotiation response information may further include a certificate verification request, where the certificate verification request may be used to request the client to send the second digital certificate of the client to the server; the client may return the second digital certificate of the client to the server based on the certificate verification request, that is, the client encryption information may also carry the second digital certificate sent by the client to the server based on the certificate verification request; wherein the second digital certificate may be issued by the trusted node for the client, the second digital certificate comprising second signature information for signing the second digital certificate by a node private key of the trusted node.

It will be appreciated that in this case, the specific implementation for the server to obtain the server private key in the trusted execution environment may be: the second digital certificate may be verified based on the node public key of the trusted node and the second signature information; and when the verification is passed, acquiring a server private key in the trusted execution environment.

Step S104, generating 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 transmission with the client.

In the present application, after the server decrypts the second random number, the server may generate the session key based on the first random number, the second random number, and the third random number. Similarly, the client may also generate the session key based on the first random number, the second random number, and the third random number, and then the client may send a key encryption notification message to the server, which is the same as notifying the server that the data will be sent in an encryption manner using session key encryption later.

It can be understood that the session key in the present application may be a symmetric key, or may be a key pair, where the session key may include a first key and a second key, where the first key and the second key may be encrypted and decrypted with each other, that is, data encrypted by using the first key may only be decrypted by using the second key; or data encrypted with the second key, can only be decrypted with the first key. Either one of the first key and the second key may be used as an encryption key, and the other one may be used as a decryption key. That is, the session key may include an encryption key and a decryption key, and the client may encrypt the application data with the encryption key to obtain encrypted data; subsequently, the client may send the encrypted data to the server; after receiving the encrypted data sent by the client, the server can decrypt the encrypted data by adopting the corresponding decryption key to obtain the application data.

It should be appreciated that embodiments of the present application modify the TLS protocol to integrate key management sdk into the TLS library when TLS communication is performed between the client and the server. The embodiment of the application can register the related functions using the private key in the TLS library, and all logic using the private key can call the trusted program in the key management sdk to execute. The private key may be stored in a trusted execution environment (trusted program) of the key management sdk, and the trusted execution environment may seal the private key, so that the private key cannot be snooped by the outside, and even if the related file is copied to other machines, the plaintext cannot be recovered, and the private key cannot be seen. The trusted execution environment ensures that the data encrypted by the hardware of the trusted execution environment cannot be decrypted on other hardware.

Taking a storage server private key as an example, specific implementation modes for storing the private key can be as follows: a server private key issued by the trusted node for the server may be obtained, and then the server private key may be stored to the trusted execution environment; the trusted execution environment is used for encrypting the server private key based on the environment encryption key corresponding to the trusted execution environment to obtain an encrypted server private key; the environment encryption key is derived from an environment root key corresponding to the trusted execution environment. That is, the trusted execution environment can derive the encryption key through the root key of the trusted hardware, and the encryption key can be used to encrypt the server private key to obtain the encrypted server private key, where the encrypted server private key never leaves the trusted execution environment and cannot be snooped by the outside, and even if the encrypted server private key can be copied to other machines, the plaintext cannot be recovered.

In the embodiment of the application, the key management logic program can be packaged based on trusted computing to obtain the software development kit, the trusted execution environment can be determined according to the trusted program in the software development kit, the server private key of the server can be stored in the trusted execution environment, and decryption is performed in the trusted execution environment when the server private key is used for decryption. Therefore, when the client and the server negotiate the session key, the server private key does not need to be stored on the hard disk of the server, and because the trusted execution environment is mutually isolated from the operating system of the server, the server private key cannot be snooped by the outside when being stored in the trusted execution environment, and data obtained by decrypting the private key in the trusted execution environment cannot be obtained by the outside, so that the session key negotiated based on the private key cannot be known by the outside, the security of the private key can be well protected, the security of the session key can be well improved, and the security of the transmitted data can be well improved. In summary, the application can improve the security of the private key in the scene of negotiating the session key, thereby improving the communication security.

In the present application, the server or the terminal device may also be a node in a distributed system, where the distributed system may be referred to as a blockchain system. It is appreciated that enhanced TLS communication may also be employed in a dual-layer chain architecture of a blockchain system. For ease of understanding, please refer to fig. 4, fig. 4 is a schematic diagram illustrating TLS communication by a blockchain dual-layer chain according to an embodiment of the present application. As shown in figure 4 of the drawings,

in the two-layer chain structure, a witness network layer and a consensus network layer may be included, in which different data nodes (such as data node 1 and data node 2) may be included, and in which different consensus nodes (such as consensus node 1, consensus node 2, consensus node 3, and consensus node 4) may be included. As shown in fig. 4, in each consensus node, a trusted execution environment may be deployed (e.g., key management sdk is integrated in the TLS library, and trusted programs in key management sdk in the TLS library are used as trusted execution environments). The node private key of the consensus node may be stored in the trusted execution environment and executed in the trusted execution environment when the private key is subsequently used. When a TLS session is performed between the data node and the consensus node, the consensus node may obtain the private key in the trusted execution environment and use the private key in the trusted execution environment. Therefore, the security of private keys of the common nodes in the block chain can be protected, and the communication security is enhanced.

It will be appreciated that the client may be a data node in a blockchain network and the server may be a consensus node (which may be referred to as a target consensus node) in a cluster of consensus nodes in the blockchain network. When the data node sends certain transaction data to the target consensus node, the target consensus node can also generate a block, sign the block based on a private key in a trusted execution environment, then perform broadcast consensus on the block, and add the block into a blockchain after passing the consensus. For ease of understanding, please refer to fig. 5, fig. 5 is a flowchart of a trusted execution environment-based uplink block according to an embodiment of the present application. As shown in fig. 5, the flow may include at least the following steps S201 to S205:

step S201, receiving business transaction data associated with a target business sent by a data node, and generating a transaction block according to the business transaction data.

Specifically, the target transaction may include a transaction such as transfer and storage, the data node may send transaction data to the target consensus node, and the target consensus node may generate a block (may be referred to as a transaction block) according to the transaction data.

In step S202, in the trusted execution environment, the transaction block is signed based on the server private key, so as to obtain a block digital signature.

Specifically, a trusted execution environment may be deployed in the target consensus node, and the target consensus node may sign the transaction block based on the server private key (i.e., the node private key of the target consensus node) in the trusted execution environment to obtain a digital signature (for convenience of distinction, the digital signature may be referred to as a block digital signature). Specifically, the trusted execution environment may refer to a trusted program in the TLS library, where the trusted program may include a signature function logic program, a generic program in the key management software tool package may include a signature function, and a communication interface in the key management software tool package may include a signature function communication interface. The target consensus node can call the signature function in the common program, the signature function interface can be obtained in the communication interface through the signature function, and the transaction block can be sent to the signature function logic program through the signature communication interface; in the signature function procedure, the transaction block may be signed with a server private key to obtain a block digital signature. The signature function logic program can also return the block digital signature to the common program through the signature function communication interface; and the target consensus node may receive the full helmet digital signature.

Step S203, the transaction block and the block digital signature are sent to the rest consensus nodes; the rest consensus nodes are the consensus nodes except the target consensus node in the consensus node cluster; the block digital signature is used for the remaining consensus nodes to acquire a server public key corresponding to the target consensus node, the block digital signature is checked based on the server public key, and the block digital signature and the target consensus node jointly perform consensus on the transaction block after the check passes.

Specifically, the target consensus node may broadcast the transaction block to other consensus nodes (i.e., the remaining consensus nodes) for consensus. The other consensus nodes can acquire the server public key corresponding to the target consensus node to check the block digital signature, and after the check passes, the block digital signature can be commonly matched with the target consensus node.

Step S204, receiving voting information returned by the rest consensus nodes; the voting information is determined after the rest consensus nodes acquire the server public keys corresponding to the target consensus nodes, and the block digital signature is checked based on the server public keys and passes the check.

Specifically, each remaining consensus node may return voting information to the target consensus node, and the types of the voting information may include a pass type, a reject pass type, and a pending type.

Step S205, determining the consensus result of the transaction block based on the voting information, and when the consensus result of the transaction block is a consensus passing result, the target block is uplink.

Specifically, the target consensus node may determine a consensus result of the transaction block based on voting information of each remaining consensus node. Taking at least two remaining consensus nodes and at least two voting information as examples, the specific implementation manner of determining the consensus result of the transaction block based on the voting information may be: voting information of which the voting type is a passing type in at least two voting information can be determined as voting passing information; then, the total number of nodes corresponding to the target consensus nodes and the rest consensus nodes, the number of nodes corresponding to the target consensus nodes and the passing number corresponding to voting passing information can be obtained; the node quantity corresponding to the target consensus node and the passing quantity can be added to obtain the total node passing quantity; and determining the consensus result of the transaction block according to the total number of the node passes and the total number of the nodes.

The specific implementation manner of determining the consensus result of the transaction block according to the total number of node passes and the total number of nodes may be: a ratio value between the total number of node passes and the total number of nodes can be determined; if the ratio value is greater than or equal to the ratio threshold value, determining the consensus result of the transaction block as a consensus passing result; if the proportion value is smaller than the proportion threshold value, the consensus result of the transaction block can be determined as a consensus failure result. The ratio threshold may be defined as a predetermined value (e.g., 2/3, 3/4, etc.). That is, when more than a certain proportion of the consensus nodes in the consensus node cluster pass the voting information, the consensus result can be determined as a consensus passing result.

Further, referring to fig. 6, fig. 6 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus may be a computer program (including program code) running in a computer device, for example the data processing apparatus is an application software; the data processing device may be used to perform the method shown in fig. 3. As shown in fig. 6, the data processing apparatus 1 may include: a request acquisition module 11, a response return module 12, an encryption information receiving module 13, a private key acquisition module 14, a decryption module 15, and a session key generation module 16.

A request acquisition module 11, configured to acquire a key negotiation request sent by a client;

a response return module 12, configured to return 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 cipher suite;

an encryption information receiving module 13, configured to receive client encryption information sent by the client; the client encryption information is information obtained by encrypting a second random number by the client based on the server public key, and the second random number is generated by the client based on the target password suite;

A private key obtaining module 14, configured to obtain a server private key in a trusted execution environment;

a decryption module 15, configured to decrypt, in the trusted execution environment, the client encrypted information based on the server private key, 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 packaging a key management logic program; the trusted execution environment is isolated from the operating system of the server;

a session key generation module 16, configured to generate a session key based on the first random number, the second random number, and a third random number carried in the key negotiation request; the session key is used for encrypting or decrypting the application data in the process of transmitting the application data with the client.

The specific implementation manners of the request obtaining module 11, the response returning module 12, the encryption information receiving module 13, the private key obtaining module 14, the decryption module 15, and the session key generating module 16 may be referred to the description of step S101 to step S104 in the embodiment corresponding to fig. 2, and will not be described herein.

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.

A random number generation unit 121 for generating the first random number based on the key negotiation request;

a suite selection unit 122, configured to select the target cipher suite from the available cipher suite list;

a certificate acquisition unit 123 for acquiring a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server public key;

and a response returning unit 124, configured to determine the first random number, the first digital certificate, and the target cipher suite as the key negotiation response information, and return the key negotiation response information to the client.

The specific implementation manners of the random number generating unit 121, the suite selecting unit 122, the certificate acquiring unit 123, and the response returning unit 124 may be referred to the description of step S101 in the embodiment corresponding to fig. 2, and will not be described herein.

Private key acquisition module 14 may include: the certificate verification unit 141 and the private key acquisition unit 142.

A certificate verification unit 141 that verifies the second digital certificate based on the node public key of the trusted node and the second signature information;

the private key obtaining unit 142 is configured to obtain the server private key in the trusted execution environment when the authentication is passed.

For a specific implementation manner of the certificate verification unit 141 and the private key obtaining unit 142, reference may be made to the description of step S103 in the embodiment corresponding to fig. 2, and the description will not be repeated here.

the data processing apparatus 1 may further include: program acquisition module 17, program encapsulation module 18, and toolkit integration module 19.

A program obtaining module 17, configured to obtain a key management logic program, a communication interface corresponding to the key management logic program, and a call function corresponding to the key management logic program;

a program packaging module 18, configured to use the key management logic program as a trusted program, use the calling function as a normal program, and package the trusted program, the communication interface, and the normal program to obtain the key management software development kit;

A tool pack integration module 19, configured to integrate the key management software development tool pack into a security protocol library of the server, and determine the trusted program in the key management software development tool pack integrated in the security protocol library as the trusted execution environment; the safety protocol library refers to a protocol library corresponding to the safety transmission layer protocol.

The specific implementation manner of the program obtaining module 17, the program packaging module 18 and the tool package integration module 19 may be referred to the description of step S103 in the embodiment corresponding to fig. 2, and will not be described herein.

the decryption module 15 may include: a function calling unit 151, a decryption unit 152, and a random number receiving unit 153.

A function calling unit 151, configured to call the decryption function in the normal program, obtain the decryption function communication interface from 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;

A decryption unit 152, configured to decrypt the client encrypted information by using the server private key in the decryption function logic program, to obtain the second random number; the decryption function logic program is used for returning the second random number to the common program through the decryption function communication interface;

and a random number receiving unit 153, configured to receive the second random number returned by the normal program.

The specific implementation manner of the function calling unit 151, the decryption unit 152, and the random number receiving unit 153 may be referred to the description of step S103 in the embodiment corresponding to fig. 2, and will not be described herein.

the data processing apparatus 1 may further include: the encrypted data receiving module 21 and the data decrypting module 22.

An encrypted data receiving module 21, configured to receive encrypted data sent by the client; the encrypted data is obtained by encrypting the application data by the client by adopting the encryption key;

and the data decryption module 22 is configured to decrypt the encrypted data by using the decryption key to obtain the application data.

The specific implementation manner of the encrypted data receiving module 21 and the data decrypting module 22 may be referred to the description of step S104 in the embodiment corresponding to fig. 2, and will not be described herein.

In one embodiment, the data processing apparatus 1 may further include: private key storage module 23.

A private key storage module 23, configured to obtain the server private key issued by the trusted node for the server, and store the server private key to the trusted execution environment; the trusted execution environment is used for encrypting the server private key based on an environment encryption key corresponding to the trusted execution environment to obtain an encrypted server private key; the environment encryption key is derived from an environment root key corresponding to the trusted execution environment.

For a specific implementation of the private key storage module 23, refer to the description of step S104 in the embodiment corresponding to fig. 2, which will not be described herein.

the data processing apparatus 1 may further include: block generation module 24, block transmission module 25, block consensus module 26 and block uplink module 27.

A block generating module 24, configured to receive service transaction data associated with a target service sent by the data node, and generate a transaction block according to the service transaction data;

a block signature module 24, configured to, in the trusted execution environment, sign the transaction block based on the server private key, to obtain a block digital signature;

a block transmitting module 25, configured to transmit the transaction block and the block digital signature to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes except the target consensus node in the consensus node cluster; the block digital signature is used for the remaining consensus nodes to acquire a server public key corresponding to the target consensus node, the block digital signature is checked based on the server public key, and the block digital signature and the target consensus node jointly carry out consensus on the transaction block after the block digital signature passes the check;

the block consensus module 26 is configured to receive voting information returned by the remaining consensus nodes; the voting information is obtained by the rest consensus nodes after the server public key corresponding to the target consensus node is obtained, the block digital signature is checked based on the server public key, and the block digital signature is determined after the check is passed;

A block uplink module 27 for determining a consensus result of the transaction block based on the voting information;

the block uplink module 27 is further configured to uplink the target block when the consensus result of the transaction block is a consensus passing result.

The specific implementation manners of the block generating module 24, the block transmitting module 25, the block consensus module 26 and the block uplink module 27 can be referred to the description of step S201-step S205 in the embodiment corresponding to fig. 5, and will not be repeated here.

the block uplink module 27 may include: a number determination unit 271 and a result determination unit 272.

A number determining unit 271 configured to determine, as voting passing information, voting information whose voting type is a passing type, of the at least two voting information;

the number determining unit 271 is further configured to obtain a total number of nodes corresponding to the target consensus node and the remaining consensus nodes, a number of nodes corresponding to the target consensus node, and a passing number corresponding to the voting passing information;

the number determining unit 271 is further configured to add the number of nodes corresponding to the target consensus node to the passing number, so as to obtain a total number of node passing;

The result determining unit 272 is configured to determine a consensus result of the transaction block according to the total number of node passes and the total number of nodes.

For specific implementation manners of the number determining unit 271 and the result determining unit 272, reference may be made to the description of step S205 in the embodiment corresponding to fig. 5, and the description will not be repeated here.

Further, referring to fig. 7, fig. 7 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 7, the apparatus 1 in the embodiment corresponding to fig. 6 may be applied to the computer device 8000, and the computer device 8000 may include: processor 8001, network interface 8004, and memory 8005, and further, the above-described computer device 8000 further includes: a user interface 8003, and at least one communication bus 8002. Wherein a communication bus 8002 is used to enable connected communications between these components. The user interface 8003 may include a Display screen (Display), a Keyboard (Keyboard), and the optional user interface 8003 may also include standard wired, wireless interfaces, among others. Network interface 8004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). Memory 8005 may be a high speed RAM memory or a non-volatile memory, such as at least one disk memory. Memory 8005 may optionally also be at least one memory device located remotely from the aforementioned processor 8001. As shown in fig. 7, an operating system, a network communication module, a user interface module, and a device control application program may be included in the memory 8005, which is one type of computer-readable storage medium.

In the computer device 8000 shown in fig. 7, the network interface 8004 may provide a network communication function; while user interface 8003 is primarily an interface for providing input to the user; and the processor 8001 may be used to invoke a device control application stored in the memory 8005 to implement:

acquiring a key negotiation request sent by a client, and returning 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 cipher suite;

It should be understood that the computer device 8000 according to the embodiment of the present application may perform the description of the data processing method according to the embodiment of fig. 2 to 5, and may also perform the description of the data processing apparatus 1 according to the embodiment of fig. 6, which is not repeated herein. In addition, the description of the beneficial effects of the same method is omitted.

Furthermore, it should be noted here that: the embodiment of the present application further provides a computer readable storage medium, where a computer program executed by the computer device 1000 for data processing mentioned above is stored, where the computer program includes program instructions, when the processor executes the program instructions, the description of the data processing method in the embodiment corresponding to fig. 2 to 5 can be executed, and therefore, will not be repeated herein. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the computer-readable storage medium according to the present application, please refer to the description of the method embodiments of the present application.

The computer readable storage medium may be the data processing apparatus provided in any one of the foregoing embodiments or an internal storage unit of the computer device, for example, a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the computer device. Further, the computer-readable storage medium may also include both internal storage units and external storage devices 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 may also be used to temporarily store data that has been output or is to be output.

The terms first, second and the like in the description and in the claims and drawings of embodiments of the application are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the term "include" and any variations thereof is intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, article, or device that comprises a list of steps or elements is not limited to the list of steps or modules but may, in the alternative, include other steps or modules not listed or inherent to such process, method, apparatus, article, or device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The method and related apparatus provided in the embodiments of the present application are described with reference to the flowchart and/or schematic structural diagrams of the method provided in the embodiments of the present application, and each flow and/or block of the flowchart and/or schematic structural diagrams of the method may be implemented by computer program instructions, and combinations of flows and/or blocks in the flowchart and/or block diagrams. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or structural diagram block or blocks. 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 such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or structures.

The foregoing disclosure is illustrative of the present application and is not to be construed as limiting the scope of the application, which is defined by the appended claims.

Claims

1. A method of data processing, comprising:

the method comprises the steps that a server obtains a key negotiation request sent by a client, and key negotiation response information is returned 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 cipher suite;

receiving client encryption information sent by the client; the client encryption information is information obtained by encrypting a second random number by the client based on the server public key, and the second random number is generated by the client based on the target password suite;

acquiring a server private key in a trusted execution environment, and decrypting the client encrypted information based on the server private key in the trusted execution environment to obtain the second random number; the trusted execution environment comprises trusted programs in a key management software development kit, wherein the key management software development kit is a software development kit obtained by packaging a key management logic program; the trusted execution environment is isolated from the operating system of the server;

Generating a session key based on the first random number, the second random number, and a third random number carried in the key negotiation request; the session key is used for encrypting or decrypting the application data in the process of transmitting the application data with the client.

2. The method of claim 1, wherein the key agreement request carries a list of available cipher suites for the client;

the returning key negotiation response information to the client based on the key negotiation request includes:

generating the first random number based on the key agreement request;

selecting the target cipher suite in the available cipher suite list;

acquiring a first digital certificate issued by a trusted node for the server; the first digital certificate includes the server public key;

and determining the first random number, the first digital certificate and the target cipher suite as the key negotiation response information, and returning the key negotiation response information to the client.

3. The method of claim 2, wherein each available cipher suite in the list of available cipher suites includes an encryption algorithm supportable by the client; the second random number is generated by the client based on an encryption algorithm included in the target cipher suite; the first digital certificate further comprises first signature information for signing the first digital certificate by adopting a node private key of the trusted node, wherein the first signature information is used for verifying the first digital certificate by the client based on the node private key of the trusted node, and the server public key is obtained after verification is passed.

4. The method according to claim 1, wherein the key agreement response information further includes a certificate verification request, the certificate verification request being used for requesting the client to send a second digital certificate of the client to the server; the client encryption information also carries the second digital certificate sent to the server by the client based on the certificate verification request; the second digital certificate is issued by the trusted node for the client, and the second digital certificate comprises second signature information for signing the second digital certificate by a node private key of the trusted node;

the obtaining the server private key in the trusted execution environment comprises the following steps:

verifying the second digital certificate based on the node public key of the trusted node and the second signature information;

when the verification is passed, the server private key is acquired in the trusted execution environment.

5. The method of claim 1, wherein the server supports a secure transport layer protocol, the key agreement request being generated based on the secure transport layer protocol;

the method further comprises the steps of:

Acquiring 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;

taking the key management logic program as a trusted program, taking the calling function as a common program, and packaging the trusted program, the communication interface and the common program to obtain the key management software development kit;

integrating the key management software development kit into a security protocol library of the server, and determining the trusted program in the key management software development kit integrated in the security protocol library as the trusted execution environment; the safety protocol library refers to a protocol library corresponding to the safety transmission layer protocol.

6. The method of claim 5, wherein the generic program comprises a decryption function; the communication interface is used for communicating between the common program and the trusted program, and comprises a decryption function communication interface; the trusted program comprises a decryption function logic program;

the decrypting the client encrypted information based on the server private key in the trusted execution environment to obtain the second random number includes:

Invoking the decryption function in the common program, acquiring the decryption function communication interface from the communication interface through the decryption function, and sending the client encryption information to the decryption function logic program through the decryption function communication interface;

decrypting the client encrypted information by adopting the server private key in the decryption function logic program to obtain the second random number; the decryption function logic program is used for returning the second random number to the common program through the decryption function communication interface;

and receiving the second random number returned by the common program.

7. The method according to claim 1, wherein the session key comprises an encryption key and a decryption key;

the method further comprises the steps of:

receiving the encrypted data sent by the client; the encrypted data is obtained by encrypting the application data by the client by adopting the encryption key;

and decrypting the encrypted data by adopting the decryption key to obtain the application data.

8. The method according to claim 1, wherein the method further comprises:

Acquiring the server private key issued by the trusted node for the server, and storing the server private key into the trusted execution environment; the trusted execution environment is used for encrypting the server private key based on an environment encryption key corresponding to the trusted execution environment to obtain an encrypted server private key; the environment encryption key is derived from an environment root key corresponding to the trusted execution environment.

9. The method of claim 1, wherein the client is a data node in a blockchain network and the server is a target consensus node in a cluster of consensus nodes in the blockchain network;

the method further comprises the steps of:

receiving service transaction data which is sent by the data node and is associated with a target service, and generating a transaction block according to the service transaction data;

in the trusted execution environment, signing the transaction block based on the server private key to obtain a block digital signature;

transmitting the transaction block and the block digital signature to the remaining consensus nodes; the remaining consensus nodes are the consensus nodes except the target consensus node in the consensus node cluster; the block digital signature is used for the remaining consensus nodes to acquire a server public key corresponding to the target consensus node, the block digital signature is checked based on the server public key, and the block digital signature and the target consensus node jointly carry out consensus on the transaction block after the block digital signature passes the check;

Receiving voting information returned by the remaining consensus nodes; the voting information is obtained by the rest consensus nodes after the server public key corresponding to the target consensus node is obtained, the block digital signature is checked based on the server public key, and the block digital signature is determined after the check is passed;

and determining the consensus result of the transaction block based on the voting information, and when the consensus result of the transaction block is a consensus passing result, uploading the target block.

10. The method of claim 9, wherein the number of remaining consensus nodes is at least two and the number of voting information is at least two;

the determining the consensus result of the transaction block based on the voting information comprises:

the voting information with the voting type being the passing type in the at least two voting information is determined to be voting passing information;

acquiring the total number of nodes corresponding to the target consensus nodes and the residual consensus nodes, the number of nodes corresponding to the target consensus nodes and the passing number corresponding to the voting passing information;

adding the node quantity corresponding to the target consensus node with the passing quantity to obtain the total node passing quantity;

And determining the consensus result of the transaction block according to the total number of the node passes and the total number of the nodes.

11. A data processing apparatus, comprising:

12. A computer device, comprising: a processor, a memory, and a network interface;

the processor is connected to the memory, the network interface for providing network communication functions, the memory for storing program code, the processor for invoking the program code to cause the computer device to perform the method of any of claims 1-10.

13. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program adapted to be loaded by a processor and to perform the method of any of claims 1-10.

14. A computer program product or computer program, characterized in that it comprises computer instructions stored in a computer-readable storage medium, which are adapted to be read and executed by a processor to cause a computer device with the processor to perform the method of any of claims 1-10.