Database and data transmission encryption method thereof, client and server

Abstract

The invention discloses a database and a data transmission encryption method thereof, a client and a server, and relates to the technical field of databases. The method is applied to a client of a database, the client comprises a first message transceiving module adopting a libuv framework, and the method comprises the following steps: acquiring a message type of target data, and determining a first encryption key corresponding to the target data according to the message type of the target data; performing segmented encryption on the target data by using the first encryption key and a second encryption key to obtain a ciphertext data packet, the second encryption key being a fixed key stored by the first message transceiving module; and asynchronously sending the ciphertext data packet to a server of a database by using a write function of the libuv framework. Therefore, the encryption method suitable for the database of the asynchronous message transceiving architecture is provided, and the security of data transmission encryption is improved.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database and a data transmission encryption method, a client, and a server. Background Art

[0002] With the advent of the digital age, a large amount of time series data has been generated in all walks of life. As the core tool for processing and analyzing a large amount of time series data, time series databases are widely used in many fields such as the Internet of Things, finance, and medical care. The data transmission security of time series databases has also become an issue that cannot be ignored.

[0003] However, the time series database design frameworks of different manufacturers are quite different, and traditional encryption methods are difficult to adapt to all time series database systems. For example, traditional encryption is generally implemented through the open source software package OpenSSL, and this encryption method needs to be bound to the Socket, but the asynchronous message sending and receiving architecture encapsulates the Socket internally, making it impossible for OpenSSL to quickly bind to the Socket, resulting in a more complicated implementation process of the encryption function. Therefore, this encryption method is not suitable for time series databases with asynchronous message sending and receiving architectures, and encrypting data during transmission will inevitably result in some performance loss. Summary of the invention

[0004] The main purpose of this application is to provide a database and its data transmission encryption method, client, and server, so as to provide an encryption method for a time series database suitable for an asynchronous message sending and receiving architecture and improve the security of data transmission encryption.

[0005] To achieve the above object, the present application provides a database data transmission encryption method, which is applied to a database client, wherein the client includes a first message transceiver module using a libuv framework, and the method includes:

[0006] Acquire a message type of target data, and determine a first encryption key corresponding to the target data according to the message type of the target data;

[0007] Using the first encryption key and the second encryption key to encrypt the target data in sections to obtain a ciphertext data packet, the second encryption key being a fixed key stored in the first message transceiver module;

[0008] The ciphertext data packet is asynchronously sent to the server of the database using the write function of the libuv framework.

[0009] Optionally, the target data includes a data header and a data body, and the use of the first encryption key and the second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet includes: encrypting the data header using the second encryption key to obtain a first sub-ciphertext data packet; encrypting the data body using the first encryption key to obtain a second sub-ciphertext data packet; and splicing the first sub-ciphertext data packet and the second sub-ciphertext data packet to obtain the ciphertext data packet.

[0010] Optionally, using the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database includes: placing the ciphertext data packet into a buf structure, the buf structure including a data packet content variable and a data packet length variable; using the write function of the libuv framework and based on the buf structure, asynchronously sending the ciphertext data packet to the server of the database.

[0011] Optionally, before obtaining the message type of the target data, the method further includes: determining whether the data packet length of the target data is an integer multiple of a preset length; if it is determined that the data packet length of the target data is not an integer multiple of the preset length, padding the target data.

[0012] In addition, to achieve the above-mentioned purpose, the present application also provides another database data transmission encryption method, which is applied to the server side of the database, and the server side includes a second message transceiver module using the libuv framework, and the method includes: receiving the ciphertext data packet sent by the client of the database in segments according to a preset number of bytes; wherein the ciphertext data packet is obtained by the client using a first encryption key and a second encryption key to segmentally encrypt the target data, the first encryption key is obtained by the client based on the message type of the target data, and the second encryption key is a fixed key stored in the first message transceiver module; the data header of the ciphertext data packet is decrypted using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and the second decryption key is determined based on the message type; the first decryption key is a fixed key stored in the second message transceiver module; the data body of the ciphertext data packet is decrypted using the second decryption key to obtain the target data.

[0013] Optionally, the method of decrypting the data header of the ciphertext data packet using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and determining the second decryption key based on the message type includes: decrypting the data header of the ciphertext data packet using the first decryption key to obtain the message type and data packet length corresponding to the ciphertext data packet; judging whether the received ciphertext data packet is complete based on the data packet length; and determining the second decryption key based on the message type when it is determined that the received ciphertext data packet is complete.

[0014] Optionally, the use of the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, and determining the second decryption key based on the message type includes: using the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type, data packet length and message verification code corresponding to the ciphertext data packet; judging whether the received ciphertext data packet is complete based on the data packet length, and judging whether the received ciphertext data packet is correct based on the message verification code; when it is determined that the received ciphertext data packet is complete and correct, determining the second decryption key based on the message type.

[0015] The present application also provides a database client, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the first database data transmission encryption method as described above when executing the computer program.

[0016] The present application also provides a database client, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the second database data transmission encryption method as described above when executing the computer program.

[0017] The present application also provides a database, including a client and a server, the client including a first message transceiving module, the server including a second message transceiving module, the first message transceiving module and the second message transceiving module being constructed using a libuv framework; the first message transceiving module is used to determine a first encryption key corresponding to the target data according to a message type of the target data, and to segmentally encrypt the target data using the first encryption key and the second encryption key to obtain a ciphertext data packet, and to asynchronously send the ciphertext data packet to the second message transceiving module using a write function of the libuv framework; the second encryption key is a fixed key stored in the first message transceiving module; the second message transceiving module is used to segmentally receive the ciphertext data packet sent by the first message transceiving module according to a preset number of bytes, and to decrypt a data header of the ciphertext data packet using a first decryption key to obtain a message type corresponding to the ciphertext data packet, determine a second decryption key based on the message type corresponding to the ciphertext data packet, and to decrypt a data body of the ciphertext data packet using the second decryption key to obtain the target data; the first decryption key is a fixed key stored in the second message transceiving module.

[0018] The data transmission encryption method of the database of the present application obtains the message type of the target data, and determines the first encryption key corresponding to the target data according to the message type of the target data; then uses the first encryption key and the second encryption key to encrypt the target data in segments to obtain a ciphertext data packet, and the second encryption key is a fixed key stored in the first message transceiver module; finally, uses the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database, thereby combining the libuv framework with the encryption algorithm to directly encrypt the target data inside the message transceiver module of the libuv framework. The encryption method of the present application is more suitable for a time series database with an asynchronous message transceiver architecture; and by using different keys to encrypt data of different message types, the security of data transmission encryption is effectively improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a scenario example of the method for encrypting data transmission of a database in an embodiment of the present application;

[0020] Figure 2 This is one of the flow charts of a method for encrypting data transmission of a database according to an embodiment of the present application;

[0021] Figure 3 This is the second flowchart of a method for encrypting data transmission of a database according to an embodiment of the present application;

[0022] Figure 4 is a flow chart of a method for encrypting data transmission of a database according to another embodiment of the present application;

[0023] Figure 5 A schematic diagram of the entity structure of a database client is illustrated.

[0024] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0026] In the digital age, time series databases, as core tools for processing and analyzing large amounts of time series data, are widely used in multiple fields such as the Internet of Things, finance, and healthcare. With the surge in the number of sensors and the explosive growth in data volume, the transmission security of sensor data between the client and server of the time series database has become an issue that cannot be ignored.

[0027] There are many transmission encryption methods available, but the most commonly used encryption method is to use the OpenSSL open source software package to implement transmission encryption. When using the OpenSSL open source software package to implement transmission encryption, the OpenSSL open source software package needs to be bound to the socket of the time series database. However, for a time series database whose message sending and receiving framework is an asynchronous framework (such as the libuv framework), since the asynchronous framework will completely encapsulate the socket inside it, it is difficult to bind the OpenSSL open source software package to the socket. The combination of the libuv framework and the OpenSSL open source software package is relatively complicated, which in turn leads to a more complicated process of implementing the data transmission encryption of the time series database. Therefore, ordinary data transmission encryption methods are not suitable for time series databases whose message sending and receiving framework is an asynchronous framework.

[0028] In addition, in the usage scenarios of time series databases, there are often tens of thousands, hundreds of thousands, or even millions of sensors collecting data. If the conventional OpenSSL open source software package encryption method is used, each sensor's corresponding client needs to distribute and configure the certificate, etc. This will increase the requirements for sensor information collection and storage. At the same time, since a large amount of calculation is required for each transmission encryption, the data storage performance drops sharply.

[0029] Based on this, the embodiments of the present application provide a database and its data transmission encryption method, client, and server. By combining the libuv framework with the encryption algorithm, the message sending and receiving module of the libuv framework can directly encrypt the data transmitted between the database client and the server. This is more suitable for time series databases whose message sending and receiving modules are asynchronous frameworks, and is very suitable for scenarios that require fast warehousing and encryption. In addition, by setting different encryption keys for different message types, the security of data transmission is effectively improved.

[0030] For ease of understanding, this specification provides an example scenario of a method for encrypting data transmission in a database. The example scenario is applied in the following example: Figure 1 In the application environment shown, the database in this scenario example is a time series database, and the database includes a server 110 and several servers 120. Each server 120 and the server 110 can establish a communication connection through the Transmission Control Protocol / Internet Protocol (TCP / IP) and the like.

[0031] In this scenario example, the server 120 can be used for users to upload time series data that needs to be stored, and can also be used for users to query data in the database, and can also provide users with management functions, backup functions, data restoration functions, etc. For example, users can upload data collected by sensors through the server 120, and the server 120 sends the sensor data to the server 110, so that the sensor data is stored in the database; one server 120 can be used to receive data collected by one sensor, and one server 120 can also be used to receive data collected by multiple sensors.

[0032] Taking a server 120 as an example, the server 120 may include a first message transceiving module and a heartbeat detection module. The first message transceiving module is constructed with libuv as a framework, and the first message transceiving module is mainly used to receive data sent by the server 110 or send data to the server 110. It should be noted that libuv is a high-performance event-driven library, which is mainly used to process various I / O operations, including timers, non-blocking network support, asynchronous file system access, etc.

[0033] The heartbeat detection module is mainly used to maintain the connection activity between the server 120 and the server 110. When the server 120 needs to continuously transmit data to the server 110, the server 120 can send heartbeat detection data to the server 110 through the heartbeat detection module to determine whether the server 120 still maintains a normal communication connection with the server 110.

[0034] In this scenario example, the server 110 may include a second message transceiving module. Similarly, the second message transceiving module is also built with libuv as a framework. The second message transceiving module is mainly used to receive data sent by each server 120 or transmit data to each server 120.

[0035] In the scenario where the user stores data in the database, the user uploads the target data through the server 120. The first message transceiver module of the server 120 determines the first encryption key corresponding to the target data according to the message type of the target data; then uses the first encryption key and the pre-stored second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet; finally, uses the write function of the libuv framework to asynchronously send the ciphertext data packet to the server 110. The second message transceiver module of the server 110 receives the ciphertext data packet sent by the server 120 in segments according to the preset number of bytes; and uses the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, and determines the second decryption key based on the message type; finally, uses the second decryption key to decrypt the data body of the ciphertext data packet to obtain the target data.

[0036] In the scenario where the user retrieves data from the database through the server 120, the second message transceiver module of the server 110 determines the first encryption key corresponding to the target data according to the message type of the target data; then uses the first encryption key and the pre-stored second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet; finally, uses the write function of the libuv framework to asynchronously send the ciphertext data packet to the server 120. The first message transceiver module of the server 120 receives the ciphertext data packet sent by the server 110 in segments according to the preset number of bytes; and uses the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, and determines the second decryption key based on the message type; finally, uses the second decryption key to decrypt the data body of the ciphertext data packet to obtain the target data.

[0037] Therefore, the server 120 or the server 110 of the database can encrypt the target data directly through their respective message sending and receiving modules, without the need to rely on the OpenSSL open source software package, and therefore there is no need to bind the OpenSSL open source software package to the socket to encrypt the target data at the socket layer. This not only achieves encryption but also allows the target data to be quickly stored in the database.

[0038] With reference to the scenario example of the method for encrypting database data transmission in the aforementioned embodiment, the method for encrypting database data transmission in the embodiment of the present application is introduced in detail below.

[0039] Figure 2This is one of the flow charts of a method for encrypting data transmission of a database in one embodiment of the present application. The method for encrypting data transmission of the database can be executed by the first message transceiving module of the database client in the aforementioned embodiment, such as Figure 2 As shown, the data transmission encryption method of the database may include the following steps:

[0040] Step 210: Obtain the message type of the target data, and determine the first encryption key corresponding to the target data according to the message type of the target data.

[0041] Step 220: Use the first encryption key and the second encryption key to encrypt the target data in segments to obtain a ciphertext data packet, where the second encryption key is a fixed key stored in the first message transceiver module.

[0042] Step 230: Use the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database.

[0043] It should be noted that the database described in the embodiment of the present application can be a time series database; different database operations generate messages of different message types. For example, database operations can include creating a database, creating a table, querying, deleting, etc., and the message types of messages generated by these database operations are all different. In this embodiment, the message type corresponding to each database operation can be numbered so that different message types correspond to different message numbers, so that the corresponding first encryption key can be determined later according to the number of the message type. In addition, this embodiment mainly takes the scenario in which the user stores data in the database through the client as an example to introduce the encryption sending and decryption receiving process of the target data. If it is a scenario in which data is retrieved from the database, it is only necessary to replace the execution subject of the encryption sending and decryption receiving process.

[0044] In this embodiment, when the client of the database needs to transmit target data to the server, the client first needs to read the sslSwitch parameter in the corresponding configuration file xgts.cfg to determine whether to enable data transmission encryption. The code example is: sslSwitch 0 / 1, where 0 is to disable encryption and 1 is to enable encryption. If the client reads the sslSwitch parameter to enable encryption, the client will notify the server to enable encryption when it turns on the encryption function; if the client reads the sslSwitch parameter to disable encryption, the client will notify the server to disable encryption when it turns off the encryption function.

[0045] Similarly, when the database server needs to transmit target data to the client, the server reads the sslSwitch parameter in the corresponding configuration file xgts.cfg to determine whether to enable data transmission encryption. If the server reads the sslSwitch parameter to enable encryption, the server will turn on the encryption function and notify the client to turn on the encryption function; if the server reads the sslSwitch parameter to turn off encryption, the server will turn off the encryption function and notify the client to turn off the encryption function.

[0046] It should be noted here that the target data can be data uploaded by the user and need to be stored in the database, or data already stored in the database, or heartbeat detection data generated by the client heartbeat detection module, disk drop messages, metadata management messages, etc. As long as the data needs to be transmitted between the database client and the server, the data can be used as the target data described in this embodiment.

[0047] When the client determines that the encryption function needs to be enabled according to the sslSwitch parameter, the first message transceiving module obtains the message type of the target data, and then determines the first encryption key according to the message type of the target data. Specifically, the first message transceiving module can determine the message type of the target data according to the operation type requested by the user through the client; or can directly obtain the message type of the target data through the data attribute contained in the data header of the target data.

[0048] Furthermore, a correspondence table between message types and encryption keys and decryption keys may be pre-constructed in the database. In this embodiment, the correspondence table may store correspondences between several message types, message type numbers, first encryption keys, and second decryption keys. After the first message transceiver module determines the message type of the target data, the corresponding first encryption key may be found from the correspondence table according to the number of the message type.

[0049] After obtaining the first encryption key, the first message transceiver module uses the first encryption key and the second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet. It should be noted here that the second encryption key can be a fixed key pre-stored in the first message transceiver module. For example, the second encryption key can be an SSL asymmetric encryption key. Finally, the first message transceiver module uses the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database.

[0050] Figure 3 This is the second flow chart of the method for encrypting data transmission of a database according to an embodiment of the present application. Figure 3As shown, in some implementations, the target data includes a data header and a data body; in step 220, the target data is segmented and encrypted using the first encryption key and the second encryption key to obtain a ciphertext data packet, which may include the following steps:

[0051] Step 310: Encrypt the data header using the second encryption key to obtain a first sub-ciphertext data packet.

[0052] Step 320: Encrypt the data body using the first encryption key to obtain a second sub-ciphertext data packet.

[0053] Step 330: concatenate the first sub-ciphertext data packet and the second sub-ciphertext data packet to obtain a ciphertext data packet.

[0054] It should be noted that the data header of the target data includes the attributes of the target data, such as data packet length, message type, message version, etc.

[0055] In this embodiment, the DES (Data Encryption Standard) encryption algorithm can be used to call the pre-created taosDesEncode function to implement encryption. Specifically, after calling the taosDesEncode function, the first message transceiver module first uses the second encryption key to encrypt the data header to obtain the first sub-ciphertext data packet, and then uses the first encryption key to encrypt the data body to obtain the second sub-ciphertext data packet; finally, the first sub-ciphertext data packet and the second sub-ciphertext data packet are concatenated to obtain a ciphertext data packet, and the uv_write function (write function) of the libuv framework is used to asynchronously send the ciphertext data packet to the server, so that the first message transceiver module can send the ciphertext data packet at one time.

[0056] In some embodiments, using the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database can include: placing the ciphertext data packet into a buf structure, the buf structure including a data packet content variable and a data packet length variable; using the write function of the libuv framework and based on the buf structure, asynchronously sending the ciphertext data packet to the server of the database.

[0057] It should be noted that the buf structure of the uv_write function of the libuv framework's message sending interface can be processed. There are two variables in the buf structure, one is base, which is the content of the target data; the other is len, which is the data packet length of the target data.

[0058] Specifically, the first sub-ciphertext data packet and the second sub-ciphertext data packet are placed in the allocated memory block to obtain a ciphertext data packet; the ciphertext data packet is then placed in the uv_buf structure of the libuv framework, and finally, the uv_write function (write function) of the libuv framework is used to asynchronously send the ciphertext data packet to the server, so that the first message transceiver module can send the ciphertext data packet at one time.

[0059] In some embodiments, before obtaining the message type of the target data, the data transmission encryption method of the database may also include: determining whether the data packet length of the target data is an integer multiple of a preset length; if it is determined that the data packet length of the target data is not an integer multiple of the preset length, padding the target data.

[0060] It should be noted that the preset length can be set according to the actual DES algorithm rules. For example, the preset length can be set to 8 bytes. The preset length is not specifically limited here.

[0061] Specifically, the first message transceiver module first determines whether it complies with the DES algorithm rules according to the data packet length in the target data header, that is, whether the data packet length is an integer multiple of the preset length. If the data packet length is an integer multiple of the preset length, the taosDesEncode function can be directly called to encrypt the target data; if the data packet length is not an integer multiple of the preset length, the target data can be padded to make the data packet length of the target data comply with the DES algorithm rules, and then the padded target data is encrypted. In this way, it is ensured that the length of the target data meets the requirements of the DES algorithm, avoiding encryption failure or errors caused by length mismatch.

[0062] The target data encryption and sending process of the first message transceiver module is further introduced below through a specific example.

[0063] First, the first message transceiver module determines whether the data packet length of the target data is an integer multiple of 8. If not, the data packet length of the target data is padded; if so, the taosDesEncode function is directly called to encrypt the target data. Furthermore, if the first 80 bytes of the target data are the data header, and the data body is all after 80 bytes, then after the first message transceiver module obtains the first encryption key from the preset relationship table according to the message type of the target data, the first message transceiver module uses the pre-stored second encryption key to encrypt the first 80 bytes of the target data to obtain the first sub-ciphertext data packet, and the first message transceiver module uses the first encryption key to encrypt the data after 80 bytes of the target data to obtain the second sub-ciphertext data packet. Finally, the first message transceiver module splices the first sub-ciphertext data packet and the second sub-ciphertext data packet, and uses the uv_write function to asynchronously send the ciphertext data packet to the server.

[0064] The code example for the above process is:

[0065] int len=8-(msg->len%8); / / msg->len is the original data packet length, len is used to determine whether the length needs to be supplemented

[0066] msg->len+=len;

[0067] void*tmp=calloc(1,msg->len);

[0068] Content1 = DesEncode (sslKey, msg->Content, 80); / / sslKey is the second encryption key

[0069] / / Key[msgType] is the first encryption key corresponding to the message type

[0070] Content2=DesEncode(Key[msgType],msg->Content+80,msg->len-80);

[0071] / / Put the encrypted first sub-ciphertext data packet and the second sub-ciphertext data packet into the allocated memory block

[0072] memcpy(tmp,Content1,80);

[0073] memcpy(tmp+80,Content2,msg->len-80);

[0074] / / At this time, the content in tmp is the encrypted first and second sub-ciphertext data packets, which are put into uv_buf

[0075] buf->base=temp; / / Put the ciphertext data packet temp into buf

[0076] buf>len=msg->len;

[0077] free(tmp);

[0078] / / Send message asynchronously

[0079] uv_write(req,(uv_stream_t*)pConn->pTcp,&buf,1,uvOnSendCb);

[0080] The above is the process of the database client encrypting the target data and sending the ciphertext data packet. If it is a database data retrieval scenario, the server encrypts the target data and sends the ciphertext data packet, you can directly refer to the client's encryption and sending process, which will not be repeated here. The following is a detailed introduction to the process of the server receiving the ciphertext data packet sent by the client and decrypting it.

[0081] Figure 4 1 is a flow chart of a method for encrypting data transmission of a database according to another embodiment of the present invention. The method for encrypting data transmission of the database can be executed by the second message transceiving module of the database server in the aforementioned embodiment, such as Figure 4 As shown, the data transmission encryption method of the database may include the following steps:

[0082] Step 410: Receive the ciphertext data packet sent by the client of the database in segments according to the preset number of bytes.

[0083] Step 420: Decrypt the data header of the ciphertext data packet using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and determine the second decryption key based on the message type.

[0084] Step 430: Decrypt the data body of the ciphertext data packet using the second decryption key to obtain the target data.

[0085] It should be noted that the ciphertext data packet is obtained by the client using the first encryption key and the second encryption key to encrypt the target data in segments. The first encryption key is obtained by the client based on the message type of the target data, and the second encryption key is a fixed key stored in the first message transceiver module; the first decryption key is a fixed key stored in the second message transceiver module. In addition, the preset number of bytes can be set by the staff according to actual needs. For example, the preset number of bytes can be set to 4096 bytes, that is, the maximum number of bytes that the second message transceiver module receives each message is 4096. The preset number of bytes is not specifically limited here.

[0086] In this embodiment, after the client sends a ciphertext data packet, the server immediately receives the ciphertext data packet using a callback function. However, before receiving the ciphertext data packet, in order to prevent the data packet from being too large, the ciphertext data packet can be received in segments. Specifically, the second message transceiver module receives the ciphertext data packet in segments according to a preset number of bytes. If the data packet length of the ciphertext data packet is less than or equal to the preset number of bytes, the second message transceiver module only needs to receive it once; if the data packet length of the ciphertext data packet is greater than the preset number of bytes, the second message transceiver module may need to receive it twice or more.

[0087] As an example, if the preset number of bytes is 4096 bytes and the ciphertext data packet is exactly 4096 bytes, the second message transceiver module only needs to receive the ciphertext data packet once. If the ciphertext data packet is 4104 bytes, the second message transceiver module needs to receive the ciphertext data packet twice, the first time to receive the first 4096 bytes of the ciphertext data packet, and the second time to receive the last 8 bytes of the ciphertext data packet.

[0088] After receiving the ciphertext data packet, the second message transceiver module may use the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, and determine the second decryption key based on the message type.

[0089] Specifically, the second message transceiver module first uses the pre-stored first decryption key to decrypt the data header of the ciphertext data packet. It should be noted that the first decryption key is also an SSL asymmetric key, and the first decryption key and the second encryption key are corresponding encryption and decryption keys. After decrypting the data header of the ciphertext data packet, the message type of the ciphertext data packet can be obtained, and then the corresponding second decryption key is found from the preset relationship table according to the message type. Further, the data body of the ciphertext data packet is decrypted using the second decryption key to obtain the target data.

[0090] As an example, if the data header of the ciphertext data packet is the first 80 bytes of data, the first decryption key can be used to decrypt the first 80 bytes of data to obtain the message type, and then the corresponding second decryption key can be determined according to the message type, and the second decryption key can be used to decrypt the data after 80 bytes to obtain the target data.

[0091] In some embodiments, decrypting the data header of a ciphertext data packet using a first decryption key to obtain a message type corresponding to the ciphertext data packet, and determining a second decryption key based on the message type may include: decrypting the data header of the ciphertext data packet using the first decryption key to obtain a message type and data packet length corresponding to the ciphertext data packet; determining whether the received ciphertext data packet is complete based on the data packet length; and determining the second decryption key based on the message type when it is determined that the received ciphertext data packet is complete.

[0092] Specifically, after receiving the ciphertext data packet, the second message transceiver module can use the pre-stored first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type and data packet length corresponding to the ciphertext data packet. The second message transceiver module can determine whether the ciphertext data packet has been received by comparing the length of the received ciphertext data packet with the parsed data packet length. If it is determined that the ciphertext data packet has been received, the corresponding second decryption key can be further found from the preset relationship table according to the message type, and the data body of the ciphertext data packet can be decrypted using the second decryption key to obtain the target data.

[0093] As an example, if the second message transceiver module currently receives 4096 bytes of ciphertext data, and the data packet length obtained by decrypting the data header of the ciphertext data packet using the first decryption key is 4104 bytes, it means that there are still 8 bytes of ciphertext data that have not been received. At this time, the second decryption key is not used to decrypt the last 4016 bytes of data. Instead, it waits to receive data again until 4104 bytes of data are received, and then the second decryption key is used to decrypt the last 4024 bytes of data.

[0094] In some embodiments, using a first decryption key to decrypt a data header of a ciphertext data packet to obtain a message type corresponding to the ciphertext data packet, and determining a second decryption key based on the message type may include: using the first decryption key to decrypt a data header of a ciphertext data packet to obtain a message type, a data packet length, and a message verification code corresponding to the ciphertext data packet; determining whether a received ciphertext data packet is complete based on the data packet length, and determining whether the received ciphertext data packet is correct based on the message verification code; when it is determined that the received ciphertext data packet is complete and correct, determining a second decryption key based on the message type.

[0095] Specifically, after receiving the ciphertext data packet, the second message transceiver module can use the pre-stored first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type, message version, data packet length, and message verification code corresponding to the ciphertext data packet. The second message transceiver module can determine whether the ciphertext data packet has been received by comparing the length of the received ciphertext data packet with the length of the data packet obtained by parsing. If it is determined that the current reception has been completed, it can be further determined whether the received data packet is wrong according to the message verification code. For example, if the received data is not encrypted data, it means that the received data is abnormal. At this time, the server can disconnect the connection with the client and delete the received abnormal data. If it is determined that the received data is correct according to the message verification code, the corresponding second decryption key can be found from the preset relationship table according to the message type, and the data body of the ciphertext data packet can be decrypted using the second decryption key to obtain the target data.

[0096] It is understandable that when the data received by the server is abnormal data, and the server still processes the data subsequently, it may cause the database to crash. Therefore, this embodiment verifies whether the received data is correct data through message verification code, etc. If it is abnormal data, the data is directly returned and the connection with the client is disconnected to ensure that the database system will not crash when the received target data content is subsequently processed due to encryption data errors.

[0097] The target data receiving and decrypting process of the second message transceiving module is further introduced below through a specific example.

[0098] After the second message transceiver module receives the ciphertext data packet sent by the first message transceiver module, the second message transceiver module first uses the pre-stored first decryption key to decrypt the first 80 bytes (data header) of the ciphertext data packet to obtain the message type, message version, data packet length (4104) and message verification code corresponding to the ciphertext data packet. The second message transceiver module determines that the ciphertext data packet has not been completely received by comparing the length 4096 of the received ciphertext data packet with the parsed data packet length 4104, and continues to receive the ciphertext data packet.

[0099] If it is determined that the ciphertext data packet has been received, it is further possible to determine whether the received data packet is erroneous based on the message verification code. If it is determined based on the message verification code that the received data is correct, it is further possible to find the corresponding second decryption key from the preset relationship table based on the message type, and use the second decryption key to decrypt the data after 80 bytes of the ciphertext data packet to obtain the target data.

[0100] The code example for the above process is:

[0101] / / nread is the length of the received data, buf->base is the received data

[0102] If(nread>0)

[0103] Content1 = desDecode (sslKey, buf->base, 80); / / sslKey is the first decryption key

[0104] msgHead head;

[0105] memcpy((char*)&head,Content1,80);

[0106] / / Head->magLen is the length of the data packet, which is used to determine when all messages have been received. For example, if 4096 bytes of data are currently received, and head->magLen is 4104 bytes, it means that there are still 8 bytes of data that have not been received. At this time, the subsequent 4016-byte message will not be decrypted temporarily, and will be decrypted after all messages are received.

[0107] / / Used to verify whether the message is wrong

[0108] int32_t tt=(int32_t)htonl(head.magicNum);

[0109] p->invalid=TRANS_NOVALID_PACKET(htonl(head.magicNum))||head.version! =TRANS_VER;

[0110] If(p->invalid!=0)conn->errCode=-1;

[0111] memcpy(Conn->readBuf,Content1,80)

[0112] memcpy(Conn->readBuf+80,Content1+80,nread-80) / / nread is the number of bytes currently received

[0113] Conn->len+=nread;

[0114] If(Conn->len==head->magLen){

[0115] Content2=desDecode(Key[head->msgType],Conn->readBuf+80,head->magLen-80);

[0116] memcpy(Conn->readBuf+80,Content2,head->magLen-80);

[0117] / / At this point, the data processing in Conn->readBuf is completed, that is, the encrypted data processing is completed,

[0118] / / Process the target data content

[0119] uvHandleReq(conn)

[0120] }

[0121] return;

[0122] }

[0123] if(nread==0){

[0124] return;

[0125] }

[0126] if(nread<0){

[0127] destroyConn(conn,true);

[0128] }

[0129] The above is the process of receiving and decrypting the target data on the server side. In order to maintain the connection activity between the client and the server, in some embodiments, the heartbeat detection module of the client can generate heartbeat detection data at a fixed time interval and an unfixed message length, and encrypt and send the heartbeat detection data through the first message transceiver module. The second message transceiver module of the server decrypts the heartbeat detection data and sends a feedback signal to the client. In this way, the client can determine whether it is currently connected normally with the server to avoid wasting resources; in addition, through the uninterrupted transmission of heartbeat detection data, metadata management messages, and disk messages, it is possible to interfere with external intercepted data packets at a deeper level.

[0130] In some embodiments, the memory allocation function of the second message sending and receiving module of the server can also be improved to ensure that there is enough buffer to store data for each read operation, reduce memory fragmentation, improve memory utilization, reduce frequent memory allocation and release operations, improve overall performance, and avoid loss or overflow of target data.

[0131] The following is a code example of the memory allocation function of the second message sending and receiving module before improvement:

[0132]

[0133] The following is an improved code example of the memory allocation function of the second message sending and receiving module:

[0134]

[0135]

[0136] By improving the memory allocation function, when the server receives the ciphertext data packet for the first time, the value in readBuf (read buffer) on conn (connection object) can be assigned according to the message header of the ciphertext data packet; the xgAllocBuffer function is further called to allocate the buffer and the result is stored in buf; the base address of the buffer is set to the end of the currently used buffer. If p->left is -1, it means that there is no limit on the remaining space, so the length of the buffer is the remaining capacity of the current buffer; if p->left is greater than or equal to 0, it means that the limit on the remaining space is specified. Based on this, the structure of the received message can be processed according to the value in ConnBuffer the next time it is received, so that according to the current buffer status and the limit on the remaining space, an appropriate buffer is allocated for storage of the target data, thereby avoiding the loss or overflow of the target data.

[0137] Therefore, by combining the libuv framework with the encryption algorithm, the client or server of the database can directly encrypt the target data through their respective message transceiver modules, without the need to use the OpenSSL open source software package, so there is no need to bind the OpenSSL open source software package to the socket to encrypt the target data at the socket layer, which makes the encryption transmission process of the database for the asynchronous message transceiver module simpler. Secondly, the user only needs to indicate in the configuration file whether encryption needs to be enabled, without manually configuring traditional SSL encryption content such as certificates and public keys, further improving the convenience of transmission encryption. In addition, the data header of the target data is encrypted by a unified second encryption key, and then the data body is encrypted by a first encryption key determined according to the message type. At the same time, various heartbeat monitoring, metadata management, disk drop and other messages are sent continuously, which achieves a deeper level of interference with external intercepted data packets, effectively improving the security of data transmission. Finally, the above-mentioned encrypted transmission and receiving decryption processes can be implemented inside the database system, reducing the steps such as certificate verification, improving transmission efficiency, reducing resource consumption caused by encryption and decryption, and realizing rapid storage of target data; by verifying the message and performing multi-step processing to determine whether the encrypted parsing message is incorrect, it is ensured that the database system will not crash due to errors in message encryption and decryption; by improving the memory allocation function of the second message transceiver module of the server, frequent memory allocation and release operations are reduced, avoiding the loss or overflow of target data. The data transmission encryption method of the database provided in the embodiment of the present application is suitable for the scenario of multi-client storage.

[0138] Based on the above embodiments, the embodiments of the present application also provide a database, including a client and a server, the client includes a first message sending and receiving module, the server includes a second message sending and receiving module, and the first message sending and receiving module and the second message sending and receiving module are constructed using the libuv framework.

[0139] The first message transceiver module is used to determine the first encryption key corresponding to the target data according to the message type of the target data, and use the first encryption key and the second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet, and use the write function of the libuv framework to asynchronously send the ciphertext data packet to the second message transceiver module; the second encryption key is a fixed key stored in the first message transceiver module.

[0140] The second message transceiver module is used to receive the ciphertext data packet sent by the first message transceiver module in segments according to a preset number of bytes, and use the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, determine the second decryption key based on the message type corresponding to the ciphertext data packet, and use the second decryption key to decrypt the data body of the ciphertext data packet to obtain the target data; the first decryption key is a fixed key stored in the second message transceiver module.

[0141] It should be noted that for details not disclosed in the database of this embodiment, please refer to the details disclosed in the embodiment of the data transmission encryption method of the database in the embodiment of this specification, which will not be repeated here.

[0142] Based on the above embodiments, Figure 5 The following is a schematic diagram of the entity structure of a database client: Figure 5 As shown, the client of the database may include: a processor 510, a communication interface 520, a memory 530 and a communication bus 540, wherein the processor 510, the communication interface 520 and the memory 530 complete mutual communication through the communication bus 540. The processor 510 may call the logic instructions in the memory 530 to execute the first database data transmission encryption method, the method comprising: obtaining the message type of the target data, and determining the first encryption key corresponding to the target data according to the message type of the target data; using the first encryption key and the second encryption key to encrypt the target data in segments to obtain a ciphertext data packet, the second encryption key being a fixed key stored in the first message transceiver module; using the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database.

[0143] In addition, the logic instructions in the above-mentioned memory 530 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0144] On the basis of the above embodiments, the embodiments of the present application also provide a database server, which may include: a processor, a communication interface, a memory and a communication bus. The processor may call the logic instructions in the memory to execute the second database data transmission encryption method, which includes: receiving the ciphertext data packet sent by the client of the database in segments according to a preset number of bytes; wherein the ciphertext data packet is obtained by the client using the first encryption key and the second encryption key to encrypt the target data in segments, the first encryption key is obtained by the client based on the message type of the target data, and the second encryption key is a fixed key stored in the first message transceiver module; the data header of the ciphertext data packet is decrypted using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and the second decryption key is determined based on the message type; the first decryption key is a fixed key stored in the second message transceiver module; the data body of the ciphertext data packet is decrypted using the second decryption key to obtain the target data. It should be noted that the specific structure of the database server can refer to the structure of the database client, which will not be repeated here.

[0145] On the basis of the above embodiments, on the other hand, the present invention also provides a computer program product, which includes a computer program. The computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the above-mentioned data transmission encryption method of the first database or the data transmission encryption method of the second database.

[0146] On the basis of the above embodiments, on another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the above-mentioned first database data transmission encryption method or the second database data transmission encryption method.

[0147] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0148] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

Claims

1. A method for encrypting data transmission of a database, characterized in that: A client applied to a database, the client comprising a first message transceiving module using a libuv framework, the method comprising: Acquire a message type of target data, and determine a first encryption key corresponding to the target data according to the message type of the target data; Using the first encryption key and the second encryption key to encrypt the target data in sections to obtain a ciphertext data packet, the second encryption key being a fixed key stored in the first message transceiver module; The ciphertext data packet is asynchronously sent to the server of the database using the write function of the libuv framework.

2. The method for encrypting data transmission of a database according to claim 1, characterized in that: The target data includes a data header and a data body, and the target data is segmented and encrypted using the first encryption key and the second encryption key to obtain a ciphertext data packet, including: Encrypting the data header using the second encryption key to obtain a first sub-ciphertext data packet; Encrypting the data body using the first encryption key to obtain a second sub-ciphertext data packet; The first sub-ciphertext data packet and the second sub-ciphertext data packet are concatenated to obtain the ciphertext data packet.

3. The method for encrypting database data transmission according to claim 1, characterized in that: The method of using the write function of the libuv framework to asynchronously send the ciphertext data packet to the server of the database includes: Put the ciphertext data packet into a buf structure, wherein the buf structure includes a data packet content variable and a data packet length variable; The ciphertext data packet is asynchronously sent to the server of the database by utilizing the write function of the libuv framework and based on the buf structure.

4. The method for encrypting database data transmission according to claim 1, characterized in that: Before obtaining the message type of the target data, the method further includes: Determining whether the data packet length of the target data is an integer multiple of a preset length; If it is determined that the data packet length of the target data is not an integer multiple of the preset length, the target data is padded to a length.

5. A method for encrypting data transmission in a database, characterized in that: A server end applied to a database, the server end including a second message transceiver module using a libuv framework, the method including: Receive the ciphertext data packet sent by the client of the database in segments according to a preset number of bytes; wherein the ciphertext data packet is obtained by the client encrypting the target data in segments using a first encryption key and a second encryption key, the first encryption key is obtained by the client based on the message type of the target data, and the second encryption key is a fixed key stored in the first message transceiver module; Decrypting the data header of the ciphertext data packet using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and determining the second decryption key based on the message type; the first decryption key is a fixed key stored in the second message transceiver module; The data body of the ciphertext data packet is decrypted using the second decryption key to obtain the target data.

6. The method for encrypting database data transmission according to claim 5, characterized in that: The decrypting the data header of the ciphertext data packet by using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and determining the second decryption key based on the message type, includes: Decrypting the data header of the ciphertext data packet using the first decryption key to obtain the message type and data packet length corresponding to the ciphertext data packet; Determining whether the received ciphertext data packet is complete based on the length of the data packet; When it is determined that the received ciphertext data packet is complete, the second decryption key is determined based on the message type.

7. The method for encrypting database data transmission according to claim 5, characterized in that: The decrypting the data header of the ciphertext data packet by using the first decryption key to obtain the message type corresponding to the ciphertext data packet, and determining the second decryption key based on the message type, includes: Decrypting the data header of the ciphertext data packet using the first decryption key to obtain the message type, data packet length, and message verification code corresponding to the ciphertext data packet; Determining whether the received ciphertext data packet is complete based on the data packet length, and determining whether the received ciphertext data packet is correct based on the message verification code; When it is determined that the received ciphertext data packet is complete and correct, the second decryption key is determined based on the message type.

8. A database client, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for encrypting data transmission of a database according to any one of claims 1 to 4 is implemented.

9. A database server, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for encrypting data transmission of a database according to any one of claims 5 to 7 is implemented.

10. A database, characterized in that: It includes a client and a server, the client includes a first message receiving and sending module, the server includes a second message receiving and sending module, and the first message receiving and sending module and the second message receiving and sending module are constructed using a libuv framework; The first message transceiver module is used to determine the first encryption key corresponding to the target data according to the message type of the target data, and use the first encryption key and the second encryption key to segmentally encrypt the target data to obtain a ciphertext data packet, and use the write function of the libuv framework to asynchronously send the ciphertext data packet to the second message transceiver module; the second encryption key is a fixed key stored in the first message transceiver module; The second message transceiver module is used to receive the ciphertext data packet sent by the first message transceiver module in segments according to a preset number of bytes, and use the first decryption key to decrypt the data header of the ciphertext data packet to obtain the message type corresponding to the ciphertext data packet, determine the second decryption key based on the message type corresponding to the ciphertext data packet, and use the second decryption key to decrypt the data body of the ciphertext data packet to obtain the target data; the first decryption key is a fixed key stored in the second message transceiver module.

Images