Data encryption and interface signature method for improving network communication security based on HTTP (Hyper Text Transport Protocol)

Abstract

The invention provides a data encryption and interface signature method for improving network communication security based on an HTTP (Hyper Text Transport Protocol). The method comprises the following steps: packaging data to be sent through ProBuf; generating a random number, and obtaining an encryption and decryption key from an agreed password book according to the random number; encrypting the service data by using an AES symmetric encryption algorithm and an encryption and decryption key; packaging the encrypted service data according to a self-defined Body data packaging format; sending the packaged encrypted data and the request header signature to a server by adopting a POST request; the server receives the encrypted data and verifies the request header signature; and if the signature verification succeeds, the server decrypts the encrypted data by using a predetermined format to obtain the original data. According to the invention, the security and reliability of network communication can be improved, so that the ever-increasing network security requirement is met.

Description

Technical Field

[0001] The present invention relates to the technical field of network communication security, and in particular to a data encryption and interface signature method for improving network communication security based on HTTP protocol. Background Art

[0002] With the rapid development of network communication technology and the increasing popularity of Internet applications, multimedia services, live broadcasts, on-demand and other business scenarios have sprung up, and the amount of audio and video network data has shown explosive growth. At the same time, various applications such as mini-programs, micro-services, and apps are also increasing, providing users with a more convenient and rich network experience. However, with the continuous increase in network applications and the sharp increase in data volume, network communication security issues have become increasingly prominent. For companies or developers, it is particularly important to improve network communication security to ensure service quality.

[0003] At present, network communication mainly relies on the HTTP protocol and its secure version HTTPS protocol. In order to ensure the security of network communication, the industry has adopted a variety of technical means, mainly including:

[0004] Request method: Use GET or POST request method for data transmission. However, the data requested by GET method will be exposed in the URL, which poses a security risk for sensitive information; and although POST method transmits data in the request body, the plain text information of the data can still be obtained through packet capture tools such as Wireshark or tcpdump, which has limited security.

[0005] Data serialization method: Data is serialized in plain text formats such as JSON. This plain text transmission method is easily intercepted and tampered with, and cannot ensure the integrity and confidentiality of the data.

[0006] Data encryption: Encryption algorithms are used to encrypt transmitted data to improve data security. However, the implementation of encryption algorithms and key management are also complex, and encrypted data may still face the risk of being cracked under certain conditions.

[0007] Certificate signing: Apply for a certificate from a CA (certificate authority) through the HTTPS protocol, and perform certificate authentication and key exchange during the communication process. Although the HTTPS protocol can ensure the data security of the communication process to a certain extent, it may also be intercepted and cracked by some proxy software (such as fiddler) by replacing certificates and updating system certificates, which poses a security risk.

[0008] Audio and video data encryption: To ensure the security of audio and video data, some applications use audio and video encryption technology. However, this encryption method requires a large number of client players to support it, which is not conducive to the rapid application of services. At the same time, due to the large number of players and the different encryption methods of audio and video manufacturers, it has brought great trouble to actual applications.

[0009] In addition, the network request interface is easily exposed, and there are many simulated request situations. Even if the data is encrypted, attackers can still intercept the encrypted data and repackage the request interface to carry out malicious attacks or data theft.

[0010] In summary, existing network communication technologies have many deficiencies and defects in terms of security. Therefore, a new network communication security technology is urgently needed to solve the above problems and improve the security and reliability of network communication. This paper aims to provide a more secure and efficient network communication method to meet the growing network security needs. Summary of the invention

[0011] In view of the deficiencies in the prior art, the present invention provides a data encryption and interface signature method for improving the security of network communications based on the HTTP protocol. The method can improve the security and reliability of network communications to meet the growing demand for network security.

[0012] The present invention achieves the above-mentioned purpose through the following technical solutions:

[0013] A data encryption and interface signature method for improving network communication security based on HTTP protocol, comprising the following steps:

[0014] Encapsulate the data to be sent through ProBuf;

[0015] Generate a random number and obtain the encryption and decryption key from the agreed code book based on the random number;

[0016] Use the AES symmetric encryption algorithm and encryption and decryption keys to encrypt business data;

[0017] Encapsulate the encrypted business data according to the customized Body data encapsulation format, including setting the random number, encrypted data length, data serialization method identifier, encrypted business data, and cyclic checksum;

[0018] Send the encapsulated encrypted data and request header signature to the server using a POST request;

[0019] The server receives the encrypted data and verifies the request header signature; if the signature verification is successful, the server decrypts the encrypted data using a predetermined format to obtain the original data.

[0020] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, when performing interface signature authentication, after the client splices the request header and the request body in a predetermined order to generate the data to be signed, the client uses a Hash algorithm pre-agreed by both parties and containing security features to process the data to be signed to generate a signature string; wherein the Hash algorithm ensures that the generated signature string is unique and unpredictable, and the client sends the signature string as part of the request together with the request header and the request body to the server.

[0021] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, after receiving a request from a client, the server concatenates the received request header and request body in the same order as the client to restore the data to be signed used to generate a signature string;

[0022] The server uses the same hash algorithm as the client to process the restored data to be signed and generate a signature string on the server side;

[0023] The server compares the generated server-side signature string with the signature string passed by the client. If the two are consistent, the request is confirmed to be valid and has not been tampered with, and the request is processed continuously. If the two are inconsistent, the signature verification is determined to have failed, and the server discards the request data without performing subsequent decryption operations.

[0024] Furthermore, when the signature verification is successful, the server uses the random number agreed upon or pre-set with the client during the request process as a key to decrypt the encrypted data that may be contained in the request to obtain the actual content of the request.

[0025] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, the Body data encapsulation format includes:

[0026] Random Number: A random number, which occupies 1 byte and is a randomly generated value used as the basis for obtaining encryption and decryption keys.

[0027] Length: indicates the length of the encrypted data, which occupies 4 bytes. Its value is the result of the XOR operation between the business data length and RandomNumber. It is used to obtain the length of the valid data when the server parses.

[0028] Type: The identifier of the data serialization method, which occupies 1 byte and is used by the server to parse the data content according to the identifier;

[0029] Data: is the result of business data after AES encryption. The data before encryption must be serialized according to the serialization method specified by Type, and then the serialized data is encrypted by AES;

[0030] CRC: cyclic checksum, occupies 4 bytes, and its value is the MD5 value directly calculated from the business data before encryption. It is used by the server to verify the integrity and correctness of the data before decrypting and parsing the data.

[0031] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, after receiving the request data from the client, the server first calculates the actual length of the business data according to the Random Number and Length, then determines the serialization method of the data according to the Type, and then performs AES decryption on the Data, and uses the CRC check code to verify the correctness of the data before or after decryption to ensure the secure transmission and accurate processing of the data.

[0032] According to a data encryption and interface signature method for improving network communication security based on HTTP protocol provided by the present invention, after generating a random number, the client and the server pre-agreed on a codebook CodeBook, the length of which is 100; and at the same time, an encryption and decryption key Key is agreed upon, the length of which is 24;

[0033] Among them, each bit of the encryption key is calculated by the following formula:

[0034] KEY[i] = CodeBook[Random Number+i], where i is an integer from 0 to 23;

[0035] The random number generation rule is: Random Number = Random()% (100-24), which is used to ensure that the random number is within the range of the difference between the code book length and the encryption key length.

[0036] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, the logic of requesting signature includes:

[0037] According to a predetermined rule, the concatenated items in the request header and the request body and the order of the concatenated items are selected based on the parity of the seconds and minutes of the request arrival time.

[0038] According to a data encryption and interface signature method for improving network communication security based on HTTP protocol provided by the present invention, when the number of seconds is an odd number, the selected concatenation items include Timestamp and Cookie; when the number of seconds is an even number, the selected concatenation items include Timestamp, Cookie and Body;

[0039] Furthermore, when the number of minutes is an odd number, the order of the concatenated items is Timestamp, Cookie, Body, where Body is included if the number of seconds is an even number; when the number of minutes is an even number, the order of the concatenated items is Body, Cookie, Timestamp, where the order is adjusted if the number of seconds is an odd number or an even number;

[0040] The selected items and sequence are concatenated, and then the signature string X-Signature is generated through the Hash algorithm.

[0041] According to a data encryption and interface signature method for improving network communication security based on HTTP protocol provided by the present invention, first, a ProBuf message structure is defined, and the structure includes various fields and data types corresponding to the data to be sent; then, the data to be sent is filled according to the defined ProBuf message structure; then, the filled message structure is compiled into a data stream in binary format using a ProBuf compiler;

[0042] Send the encapsulated binary data stream as part of the request body, together with the generated request header and signature, to the server;

[0043] After receiving the request, the server first parses the binary format data stream in the request body, restores it to the structure of the original data to be sent through the ProBuf deserialization process, and then verifies and processes it in combination with the request header and signature.

[0044] According to a data encryption and interface signature method for improving network communication security based on the HTTP protocol provided by the present invention, the encapsulated encrypted data and the request header signature are sent to the server using a POST request, including:

[0045] Construct the encapsulated encrypted data into a request body in JSON format;

[0046] Generate a request header, which at least contains a field for identifying the request content type, and its value is set to "application / json" to indicate to the server that the request body data is in JSON format. At the same time, send the signature string as a field in the request header for the server to verify the request;

[0047] The constructed request body and the generated request header are sent to the server together; the POST method in the HTTP protocol is used, the request body is used as the message body, and the request header is used as the message header part, and is sent to the interface address specified by the server.

[0048] It can be seen that the present invention proposes a new network communication encryption and security mechanism to address the many deficiencies and defects in the security of existing network communication technologies, and its beneficial effects are mainly reflected in the following aspects:

[0049] 1. The present invention designs a complex code book and a random number encryption scheme, so that the transmitted data has higher randomness and complexity during the encryption process, greatly improving the difficulty of data cracking and enhancing the security of data transmission.

[0050] 2. The present invention adopts PB (Probuf) method to serialize data and customizes the random key encryption scheme to replace the original JSON data serialization method. The PB serialization method not only improves the data transmission efficiency, but also effectively prevents the data from being tampered with and stolen during the transmission process due to its combination of binary format and customized encryption scheme, further ensuring the security of the data.

[0051] 3. The present invention proposes a solution for requesting signatures, which ensures the legitimacy and authenticity of the request source through interface request signatures and the implementation of signature methods. This mechanism effectively prevents users from making malicious requests after grabbing links, avoids illegal access and abuse of resources, thereby protecting the legitimate rights and interests of service providers and effectively solving the problem of hotlink prevention.

[0052] 4. On the basis of the present invention, the HTTPS protocol is used for certificate verification and encrypted communication, forming a multiple security protection mechanism. The HTTPS protocol itself provides encryption and certificate verification functions during data transmission, which, combined with the encryption scheme proposed by the present invention, further improves the security of data. Even if an attacker can break through one layer of protection, it is difficult to break through the overall security system, thus ensuring the extremely high security of the communication process.

[0053] In summary, the present invention aims to solve the anti-hotlinking problem by designing a complex codebook and random number encryption scheme, adopting PB serialization data and a custom random key encryption scheme, and implementing request signature and signature methods, and on this basis, combining the HTTPS protocol for certificate verification and encrypted communication, thereby comprehensively improving the security, reliability and efficiency of network communications.

[0054] The present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 It is a flow chart of an embodiment of a data encryption and interface signature method for improving network communication security based on HTTP protocol of the present invention.

[0056] Figure 2It is a flow diagram of an embodiment of a data encryption and interface signature method for improving network communication security based on the HTTP protocol of the present invention.

[0057] Figure 3 It is a principle diagram of the Body data encapsulation format in an embodiment of a data encryption and interface signature method for improving network communication security based on the HTTP protocol of the present invention.

[0058] Figure 4 It is a principle diagram of a method for obtaining a code book and encryption and decryption keys in an embodiment of a data encryption and interface signature method for improving network communication security based on the HTTP protocol of the present invention.

[0059] Figure 5 It is a principle diagram of splicing items and the order of splicing items in an embodiment of a data encryption and interface signature method for improving network communication security based on HTTP protocol of the present invention. DETAILED DESCRIPTION

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

[0061] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0062] See also Figure 1 and Figure 2 This embodiment provides a data encryption and interface signature method based on the HTTP protocol to improve network communication security. The method includes the following steps:

[0063] Step S1, encapsulating the data to be sent through ProBuf;

[0064] Step S2, generating a random number, and obtaining an encryption and decryption key from the agreed code book according to the random number;

[0065] Step S3, encrypting the business data using the AES symmetric encryption algorithm and encryption and decryption keys;

[0066] Step S4, encapsulate the encrypted business data according to the customized Body data encapsulation format, including setting a random number (for obtaining encryption and decryption keys), encrypted data length (encrypted in XOR mode), data serialization mode identifier (0 for JSON, 1 for ProBuf), AES encrypted business data, and cyclic checksum (CRC);

[0067] Step S5, sending the encapsulated encrypted data and request header signature to the server using a POST request;

[0068] Step S6, the server receives the encrypted data and verifies the request header signature; if the signature verification is successful, the server decrypts the encrypted data using a predetermined format to obtain the original data.

[0069] When performing interface signature authentication, the client concatenates the request header and request body in a predetermined order to generate the data to be signed, and then uses a hash algorithm that is pre-agreed upon by both parties and contains security features to process the data to be signed to generate a signature string; the hash algorithm ensures that the generated signature string is unique and unpredictable, and the client sends the signature string as part of the request, together with the request header and request body, to the server.

[0070] After receiving the request from the client, the server concatenates the received request header and request body in the same order as the client to restore the data to be signed used to generate the signature string;

[0071] The server uses the same hash algorithm as the client to process the restored data to be signed and generate a signature string on the server side;

[0072] The server compares the generated server-side signature string with the signature string passed by the client. If the two are consistent, the request is confirmed to be valid and has not been tampered with, and the request is processed continuously. If the two are inconsistent, the signature verification is determined to have failed, and the server discards the request data without performing subsequent decryption operations.

[0073] Furthermore, when the signature verification is successful, the server uses the random number agreed upon or pre-set with the client during the request process as a key to decrypt the encrypted data that may be contained in the request to obtain the actual content of the request.

[0074] like Figure 3 As shown, the Body data encapsulation format includes:

[0075] Random Number: A random number that occupies 1 byte and is a randomly generated value used as the basis for obtaining encryption and decryption keys.

[0076] Length: indicates the length of the encrypted data, which occupies 4 bytes. Its value is the result of the XOR operation between the business data length and RandomNumber. It is used to obtain the length of valid data when the server parses it. The specific calculation formula is: Length = (business data length XOR Random Number). For example, if the business data length a = 5 and Random Number = 3, then Length = a^Random Number, Length = 6. Here, XOR is used for simple encryption.

[0077] Type: The identifier of the data serialization method. 0 indicates JSON, and 1 indicates ProBuf. It occupies 1 byte and is used by the server to parse the data content according to the identifier.

[0078] Data: is the result of business data after AES encryption. The data before encryption must be serialized according to the serialization method specified by Type (ProBuf serialization or JSON serialization), and then the serialized data is encrypted by AES.

[0079] CRC: cyclic checksum, occupies 4 bytes, and its value is the MD5 value directly calculated from the business data before encryption. It is used by the server to verify the integrity and correctness of the data before decrypting and parsing the data.

[0080] After receiving the request data from the client, the server first calculates the actual length of the business data based on the Random Number and Length, then determines the serialization method of the data based on the Type, and then decrypts the Data using AES. It also uses the CRC checksum to verify the correctness of the data before or after decryption to ensure secure transmission and accurate processing of the data.

[0081] In this embodiment, after generating the random number, the client and the server pre-agreed on a codebook CodeBook, the length of which is 100; and at the same time, an encryption and decryption key Key is agreed upon, the length of which is 24.

[0082] Among them, each bit of the encryption key is calculated by the following formula:

[0083] KEY[i] = CodeBook[Random Number+i], where i is an integer from 0 to 23;

[0084] The random number generation rule is: Random Number = Random()% (100-24), which is used to ensure that the random number is within the range of the difference between the code book length and the encryption key length.

[0085] Among them, Figure 4 As shown, Figure 4 This is the method for obtaining the codebook and encryption and decryption keys, where the length of the codebook and the length of the encryption and decryption keys can be agreed upon by yourself. Random number Random Number = 31, so KEY[0] = CodeBook[31+0], KEY[0] = 0X52, KEY[1] = CodeBook[31+1], KEY[0] = 0X37. By analogy, a 24-bit Key can be calculated. With a 24-bit encryption and decryption key, the business data can be randomly encrypting using the AES symmetric encryption algorithm.

[0086] In this embodiment, the logic of requesting a signature includes:

[0087] According to a predetermined rule, the concatenated items in the request header and the request body and the order of the concatenated items are selected based on the parity of the seconds and minutes of the request arrival time.

[0088] When the number of seconds is an odd number, the selected concatenation items include Timestamp and Cookie; when the number of seconds is an even number, the selected concatenation items include Timestamp, Cookie, and Body;

[0089] Furthermore, when the number of minutes is an odd number, the order of the concatenated items is Timestamp, Cookie, Body, where Body is included if the number of seconds is an even number; when the number of minutes is an even number, the order of the concatenated items is Body, Cookie, Timestamp, where the order is adjusted if the number of seconds is an odd number or an even number;

[0090] The selected items and sequence are concatenated, and then the signature string X-Signature is generated through the Hash algorithm.

[0091] Specifically, the logic of request signature is to concatenate the request header and request body in a certain order, and then generate the signature string X-Signature through the Hash algorithm (SHA256, MD5, etc.). After the request reaches the server, the signature string is generated according to the agreed order and compared with the string passed by the client to determine the unique request. All the key points are the concatenated items and the order of the concatenated items. The focus of this embodiment is the idea of ​​randomness, such as determining the concatenated items by the parity of the seconds, and determining the order of the concatenation by the parity of the minutes. Figure 5 As shown, when seconds are the base number, the concatenation items are Timestamp, Cookie, and when seconds are an even number, the concatenation items are Timestamp, Cookie, Body; when minutes are the base number, the order is Timestamp, Cookie, Body, and when minutes are an even number, the order is Body, Cookie, Timestamp.

[0092] Seconds as base, minutes as base

[0093] sign_str=[Timestamp:2024-12-05T10:01:01Z\nCookie:

[0094] CloudFront-Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdX]

[0095] Seconds are cardinal numbers, minutes are even numbers

[0096] sign_str=[Cookie:

[0097] CloudFront-Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdX\nTimestamp:2024-12-05T10:00:01Z\n]

[0098] Seconds are even, minutes are even

[0099] sign_str=[Body:Body\nCookie:

[0100] CloudFront-Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdX\nTimestamp:2024-12-05T10:00:00Z]

[0101] Seconds are even numbers, minutes are cardinal numbers

[0102] sign_str=[Timestamp:2024-12-05T10:01:00Z\nCookie:

[0103] CloudFront-Policy=eyJTdGF0ZW1lbnQiOiBbeyJSZXNvdX\nBody:Body]

[0104] In this embodiment, the data to be sent is serialized and encapsulated through ProBuf. The specific encapsulation process includes:

[0105] First, define the ProBuf message structure, which includes various fields and data types corresponding to the data to be sent; then, fill the data to be sent according to the defined ProBuf message structure; then, use the ProBuf compiler to compile the filled message structure into a binary data stream;

[0106] Send the encapsulated binary data stream as part of the request body, together with the generated request header and signature, to the server;

[0107] After receiving the request, the server first parses the binary format data stream in the request body, restores it to the structure of the original data to be sent through the ProBuf deserialization process, and then verifies and processes it in combination with the request header and signature.

[0108] In this embodiment, the encapsulated encrypted data and the request header signature are sent to the server using a POST request, including:

[0109] Construct the encapsulated encrypted data into a request body in JSON format;

[0110] Generate a request header, which at least contains a field for identifying the request content type, and its value is set to "application / json" to indicate to the server that the request body data is in JSON format. At the same time, send the signature string as a field in the request header for the server to verify the request;

[0111] The constructed request body and the generated request header are sent to the server together; the POST method in the HTTP protocol is used, the request body is used as the message body, and the request header is used as the message header part, and is sent to the interface address specified by the server.

[0112] In summary, this embodiment solves the anti-hotlinking problem by designing a complex codebook and random number encryption scheme, adopting PB serialization data and a custom random key encryption scheme, and implementing request signatures and signature methods, and on this basis combines the HTTPS protocol for certificate verification and encrypted communication, thereby comprehensively improving the security, reliability and efficiency of network communications.

[0113] Furthermore, this embodiment designs a complex code book and a random number encryption scheme, so that the transmitted data has higher randomness and complexity during the encryption process, greatly improving the difficulty of data cracking and enhancing the security of data transmission.

[0114] Furthermore, this embodiment uses PB (Probuf) to serialize data and customizes the random key encryption scheme to replace the original JSON data serialization method. The PB serialization method not only improves the data transmission efficiency, but also effectively prevents the data from being tampered with and stolen during the transmission process due to its combination of binary format and customized encryption scheme, further ensuring the security of the data.

[0115] Furthermore, this embodiment proposes a solution for requesting signatures, which ensures the legitimacy and authenticity of the request source through interface request signatures and the implementation of signature methods. This mechanism effectively prevents users from making malicious requests after grabbing links, avoids illegal access and abuse of resources, thereby protecting the legitimate rights and interests of service providers and effectively solving the problem of hotlink prevention.

[0116] Furthermore, based on this embodiment, the HTTPS protocol is used for certificate verification and encrypted communication, forming a multiple security protection mechanism. The HTTPS protocol itself provides encryption and certificate verification functions during data transmission, which, combined with the encryption scheme proposed in the present invention, further improves the security of data. Even if an attacker can break through one layer of protection, it is difficult to break through the overall security system, thereby ensuring the extremely high security of the communication process.

[0117] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The above-mentioned embodiments are only preferred embodiments of the present invention and cannot be used to limit the scope of protection of the present invention. Any non-substantial changes and substitutions made by technicians in this field on the basis of the present invention shall fall within the scope of protection required by the present invention.

Claims

1. A data encryption and interface signature method for improving network communication security based on HTTP protocol, characterized in that: The following steps are involved: Encapsulate the data to be sent through ProBuf; Generate a random number and obtain the encryption and decryption key from the agreed code book based on the random number; Use the AES symmetric encryption algorithm and encryption and decryption keys to encrypt business data; Encapsulate the encrypted business data according to the customized Body data encapsulation format, including setting the random number, encrypted data length, data serialization method identifier, encrypted business data, and cyclic checksum; Send the encapsulated encrypted data and request header signature to the server using a POST request; The server receives the encrypted data and verifies the request header signature; if the signature verification is successful, the server decrypts the encrypted data using a predetermined format to obtain the original data.

2. The method according to claim 1, characterized in that: When performing interface signature authentication, the client concatenates the request header and request body in a predetermined order to generate the data to be signed, and then uses a hash algorithm that is pre-agreed upon by both parties and contains security features to process the data to be signed to generate a signature string; the hash algorithm ensures that the generated signature string is unique and unpredictable, and the client sends the signature string as part of the request, together with the request header and request body, to the server.

3. The method according to claim 2, characterized in that: After receiving the request from the client, the server concatenates the received request header and request body in the same order as the client to restore the data to be signed used to generate the signature string; The server uses the same hash algorithm as the client to process the restored data to be signed and generate a signature string on the server side; The server compares the generated server-side signature string with the signature string passed by the client. If the two are consistent, the request is confirmed to be valid and has not been tampered with, and the request is processed continuously. If the two are inconsistent, the signature verification is determined to have failed, and the server discards the request data without performing subsequent decryption operations. Furthermore, when the signature verification is successful, the server uses the random number agreed upon or pre-set with the client during the request process as a key to decrypt the encrypted data that may be contained in the request to obtain the actual content of the request.

4. The method according to claim 1, characterized in that: The Body data encapsulation formats include: Random Number: A random number, which occupies 1 byte and is a randomly generated value used as the basis for obtaining encryption and decryption keys. Length: indicates the length of the encrypted data, which occupies 4 bytes. Its value is the result of the XOR operation between the business data length and RandomNumber. It is used to obtain the length of the valid data when the server parses. Type: The identifier of the data serialization method, which occupies 1 byte and is used by the server to parse the data content according to the identifier; Data: is the result of business data after AES encryption. The data before encryption must be serialized according to the serialization method specified by Type, and then the serialized data is encrypted by AES; CRC: cyclic checksum, occupies 4 bytes, and its value is the MD5 value directly calculated from the business data before encryption. It is used by the server to verify the integrity and correctness of the data before decrypting and parsing the data.

5. The method according to claim 4, characterized in that: After receiving the request data from the client, the server first calculates the actual length of the business data based on the Random Number and Length, then determines the serialization method of the data based on the Type, and then decrypts the Data using AES. It also uses the CRC checksum to verify the correctness of the data before or after decryption to ensure secure transmission and accurate processing of the data.

6. The method according to claim 1, characterized in that: After generating the random number, the client and the server agree on a codebook CodeBook in advance, the length of which is 100; at the same time, they agree on the encryption and decryption key Key, the length of which is 24; Among them, each bit of the encryption key is calculated by the following formula: KEY[i] = CodeBook[Random Number+i], where i is an integer from 0 to 23; The random number generation rule is: Random Number = Random()% (100-24), which is used to ensure that the random number is within the range of the difference between the code book length and the encryption key length.

7. The method according to claim 3, characterized in that: The logic for requesting a signature includes: According to a predetermined rule, the concatenated items in the request header and the request body and the order of the concatenated items are selected based on the parity of the seconds and minutes of the request arrival time.

8. The method according to claim 7, characterized in that: When the number of seconds is an odd number, the selected concatenation items include Timestamp and Cookie; when the number of seconds is an even number, the selected concatenation items include Timestamp, Cookie, and Body; Furthermore, when the number of minutes is an odd number, the order of the concatenated items is Timestamp, Cookie, Body, where Body is included if the number of seconds is an even number; when the number of minutes is an even number, the order of the concatenated items is Body, Cookie, Timestamp, where the order is adjusted if the number of seconds is an odd number or an even number; The selected items and sequence are concatenated, and then the signature string X-Signature is generated through the Hash algorithm.

9. The method according to any one of claims 1 to 8, characterized in that: The data to be sent is serialized and encapsulated through ProBuf. The specific encapsulation process includes: First, define the ProBuf message structure, which includes various fields and data types corresponding to the data to be sent; then, fill the data to be sent according to the defined ProBuf message structure; then, use the ProBuf compiler to compile the filled message structure into a binary data stream; Send the encapsulated binary data stream as part of the request body, together with the generated request header and signature, to the server; After receiving the request, the server first parses the binary format data stream in the request body, restores it to the structure of the original data to be sent through the ProBuf deserialization process, and then verifies and processes it in combination with the request header and signature.

10. The method according to claim 3, characterized in that Send the encapsulated encrypted data and request header signature to the server using a POST request, including: Construct the encapsulated encrypted data into a request body in JSON format; Generate a request header, which at least contains a field for identifying the request content type, and its value is set to "application / json" to indicate to the server that the request body data is in JSON format. At the same time, send the signature string as a field in the request header for the server to verify the request; The constructed request body and the generated request header are sent to the server together; the POST method in the HTTP protocol is used, the request body is used as the message body, and the request header is used as the message header part, and is sent to the interface address specified by the server.

Images