Dynamic hybrid encryption communication method based on block chain

Abstract

The invention provides a dynamic hybrid encryption communication method based on a block chain. The method comprises the following steps: S1, distributing keys; s2, performing dynamic hybrid encryption on the data; s3, the data are decrypted; s4, verifying the validity of the timestamp; s5, after the timestamp verification is passed, verification is carried out based on block chain evidence storage data; s6, the server performs compression and AES encryption on the response data and then returns the response data to the client; and S7, the client obtains response data through AES decryption and decompression, the communication security is good, the data transmission is high, and scenes with high requirements such as unmanned aerial vehicle communication can be met.

Description

Technical Field

[0001] This invention relates to the field of blockchain encrypted communication technology, and more specifically to a dynamic hybrid encrypted communication method based on blockchain. Background Technology

[0002] In the field of communication security technology, especially in scenarios with extremely high requirements for real-time and reliable data transmission, such as drone communication and the Internet of Things, ensuring the confidentiality and integrity of the communication process has always been a core issue. Most current mainstream solutions adopt encryption mechanisms. Although such solutions improve security to a certain extent, their security models still rely on a centralized trust architecture. Key distribution and verification, hardware identity information comparison, and timestamp verification all need to be completed through a central server or database. Blockchain, on the other hand, is a distributed ledger technology that combines data blocks into a chain-like data structure in chronological order and uses cryptography to ensure immutability and unforgeability.

[0003] For example, patent document with patent application number CN202011555244.8, publication date June 6, 2023, and classification number H04L9 / 08 discloses a trusted sharing system for deep learning datasets based on blockchain smart contracts, including a data mart module, a blockchain adaptation module, and a cloud computing module. The cloud computing module supports the blockchain adaptation module, and the blockchain adaptation module supports the data mart module. The data mart module is mainly responsible for data display and sharing. The blockchain adaptation module is mainly responsible for data recording and storage, and it fully includes the smart contract module.

[0004] The above-mentioned documents use the AES symmetric key encryption algorithm, where the data provider generates the key locally and encrypts the dataset locally using the AES symmetric key encryption algorithm. Alternatively, they use the RSA asymmetric key encryption algorithm, where the trusted computing environment generates a public-private key pair upon startup. The private key is stored in the secure area of ​​the trusted environment, and the public key is transmitted to the data provider. The data provider then uses the public key to encrypt the AES symmetric key locally. However, these documents merely generate the private key using the AES encryption algorithm and encrypt the data. In other words, the private key generation is achieved simply by using fixed data with the AES encryption algorithm, making the plaintext of the private key vulnerable to tampering and attack resistance. If the plaintext of the private key is leaked, it is easily attacked, resulting in poor security. Furthermore, the verification method only involves decryption through trusted nodes in the blockchain, without verifying the key through multiple methods during decryption to improve the overall data's attack resistance. Additionally, the encrypted data is sent all at once, making it susceptible to data tampering. Summary of the Invention

[0005] This invention provides a dynamic hybrid encrypted communication method based on blockchain, which integrates the immutability of blockchain into the decryption and verification process of dynamic hybrid encrypted communication, resulting in high security.

[0006] To achieve the above objectives, the technical solution of the present invention is: a dynamic hybrid encrypted communication method based on blockchain, applied to communication between a client and a server, comprising the following steps: S1. Distribute the public key: The client requests the RSA public key from the server, and the server returns the RSA public key and digital signature; S2. Private key generation and data encryption: The client generates a random AES key and a random initialization vector IV for each timestamp, and encrypts the random AES key and random initialization vector IV with an RSA public key to form a private key; the client encrypts the data and timestamp with the private key to obtain encrypted data; the client writes the hash value of the encrypted data and timestamp into the blockchain; the client compresses the encrypted data according to the data type to generate encrypted data packets and sends them to the server. S3. Decrypting the encrypted data: After receiving the encrypted data packet, the server decompresses it, decrypts it using the public key to obtain the private key, and then decrypts the encrypted data using the private key. S4. Verify the validity of the timestamp. If the verification is successful, verify the encrypted data stored on the blockchain. If the verification is successful, return the data request.

[0007] The above method verifies the integrity of the RSA public key through digital signatures, preventing man-in-the-middle attacks and public key tampering. Each time, the client generates a random AES key and a random initialization vector (IV), and encrypts the random key using the public key to form a private key. This ensures the plaintext of the private key is randomly generated, possessing a degree of randomness, and each generated private key is different. This makes it impossible to meet time requirements even if attacks exploit randomness. Furthermore, encrypted data is simultaneously sent and written to the blockchain. After encryption, the data can be double-verified by checking the timestamp in the decrypted encrypted data and the encrypted data in the blockchain to determine whether to return the requested data. This double verification on the server side ensures communication security and leverages the reliable communication characteristics of the blockchain to ensure communication reliability. Additionally, the encrypted data is categorized and compressed according to different data types for transmission, reducing data transmission pressure and further preventing tampering during transmission of the entire data at once.

[0008] Furthermore, after step S4, the process also includes: S5, executing business logic and preparing response data; S6. The server compresses and encrypts the response data with AES before returning it to the client. S7. The client obtains the response data and data by decrypting and decompressing using AES.

[0009] With the above settings in place, assuming no issues with dual authentication, the server also compresses the response data before returning it, optimizing the bandwidth of the bidirectional communication link and improving response speed.

[0010] Furthermore, step S1 also includes: collecting hardware information and generating machine code using the SHA256 hash algorithm; the client sending the machine code and requesting the RSA public key to the server; the server returning the RSA public key and digital signature after verifying the validity of the machine code; and proceeding to step S2 if the digital signature verification is successful.

[0011] The above settings bind communication requests to specific physical devices, making it impossible for other devices to forge valid requests and improving the reliability of verification.

[0012] Furthermore, the hardware information includes the CPU ID, motherboard serial number, and disk serial number.

[0013] The above settings generate machine code using hardware information from key components in the controller, thereby further increasing the difficulty of the attack.

[0014] Furthermore, the validity period of the verification timestamp in step S4 is ±5 minutes; if the validity period of the verification timestamp is exceeded, the request is rejected and an expired request error is returned.

[0015] The above settings, by setting the difference range, can prevent replay attacks and ensure the reliability of requests.

[0016] Furthermore, step S2, "compressing the encrypted data according to its data type to generate encrypted data packets and sending them to the server," also includes: determining the data type, including numerical data, text data, pattern data, and other types of data; using a numerical compression algorithm for numerical data, a dictionary compression algorithm for text data, a pattern recognition compression algorithm for pattern data, and a zlib compression algorithm for other types of data.

[0017] The above settings optimize compression ratios for different types of data by using different compression algorithms.

[0018] Furthermore, step S2 also includes: before determining the type of data, determining the structure of the data, predicting the next data based on historical data for flight data, then determining the difference between the actual data and the predicted next data, and compressing the difference to generate encrypted data.

[0019] The above settings involve processing data structures before determining the data type. For flight data with minimal differences, only the differences need to be compressed, thereby further reducing the data transmission pressure.

[0020] Furthermore, step S2 also includes: extracting the common part, the variable part, and generating an index for the timestamp and the XYZ axis data in the flight data, and then generating a compressed data packet from the common part, the variable part, and the generated index for transmission.

[0021] The above settings, by extracting common and variable parts, eliminate redundant information in the data.

[0022] Furthermore, the dictionary compression algorithm in S2 includes: generating a personalized dictionary based on the client hardware code, and compressing text data using the personalized dictionary; after receiving the compressed and encrypted data, the server generates the same personalized compression dictionary based on the client hardware code, which is used to decompress the data and verify its validity through blockchain.

[0023] The above settings improve compression efficiency and add an extra layer of security by using the client's hardware code as a seed to generate a personalized compression dictionary, thus complementing the project's existing encryption system.

[0024] Furthermore, in step S2, writing the hash value of the encrypted data into the blockchain includes: the entire process of generating, uploading, and verifying the blockchain timestamp is recorded in the blockchain distributed ledger, and each node stores a complete copy of the data; The verification process for the encrypted data stored on the blockchain in step S4 includes: tracing the corresponding block information, client, and corresponding node signature based on the timestamp hash value. If the corresponding block information, client, and corresponding node signature are all successfully verified, the verification is successful.

[0025] The above settings, by adding timestamps to the blockchain and recording and storing the timestamp information in the blockchain, facilitate subsequent blockchain verification. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the framework of the present invention.

[0027] Figure 2 This is a flowchart outlining the framework of step S1 of the present invention.

[0028] Figure 3 This is a flowchart outlining the framework of step S2 of the present invention.

[0029] Figure 4 This is a flowchart outlining the framework of step S3 of the present invention.

[0030] Figure 5This is a flowchart outlining steps S4 and S5 of the present invention.

[0031] Figure 6 This is a flowchart illustrating the framework for generating machine code for this invention.

[0032] Figure 7 This is a flowchart illustrating the framework of the adaptive compression algorithm of this invention.

[0033] Figure 8 This is a flowchart illustrating the framework for predictive compression in this invention.

[0034] Figure 9 This is a flowchart illustrating the framework of intelligent compression in this invention.

[0035] Figure 10 This is a flowchart illustrating the framework of personalized compression in this invention. Detailed Implementation

[0036] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0037] like Figures 1 to 10 As shown, a blockchain-based dynamic hybrid encrypted communication method, applied to communication between a client and a server, includes the following steps: S1. Public key distribution: The client requests an RSA public key from the server, and the server returns the RSA public key and digital signature; S2. Private key generation and data encryption: The client generates a random AES key and a random initialization vector IV for each timestamp, and encrypts the random AES key and random initialization vector IV with an RSA public key to form a private key; the client encrypts the data and timestamp with the private key to obtain encrypted data; the client writes the hash value of the encrypted data and timestamp into the blockchain; the client compresses the encrypted data according to the data type to generate encrypted data packets and sends them to the server. S3. Decrypting the encrypted data: After receiving the encrypted data packet, the server decompresses it, decrypts it using the public key to obtain the private key, and then decrypts the encrypted data using the private key. S4. Verify the validity of the timestamp. If the verification is successful, verify the encrypted data stored on the blockchain. If the verification is successful, return the data request.

[0038] S5. Execute business logic and prepare response data certificates; S6. The server compresses and encrypts the response data with AES before returning it to the client. S7. The client obtains the response data by decrypting and decompressing using AES.

[0039] like Figure 2As shown, the hardware information is collected by generating machine code using the SHA256 hash algorithm. The client sends the machine code and requests an RSA public key to the server. If the server verifies the validity of the machine code, it returns the RSA public key and a digital signature. If the digital signature verification is successful, the process proceeds to step S2, where the client requests the RSA public key from the server. The server pre-generates an RSA key pair, where the RSA public key has a length of 2048 bits and uses the OAEP padding scheme. The private key is stored in the server's secure storage module. Before communication, the client sends an RSA public key request to the server through a preset interface. The request information must include the machine code generated by the client. The server performs preliminary verification of the client using the machine code. Hardware information includes the CPUID, motherboard serial number, and disk serial number.

[0040] like Figures 3 to 6 As shown, data is dynamically encrypted using a hybrid approach. A 32-byte AES key is generated by combining an RSA encryption key with AES encryption of the business data, ensuring the uniqueness of the AES key for each communication. Simultaneously, a 16-byte random initialization vector (IV) is generated using a random algorithm. The client invokes the RSA encryption algorithm in CBC mode, encrypting the constructed data using the generated AES key and IV input. Because CBC mode introduces randomness into the IV, the same plaintext will produce different ciphertexts, preventing the leakage of plaintext characteristics. The client then Base64 encodes both the random initialization vector IV and the AES-encrypted business data. The encoded contents are combined to form an encrypted data packet, which is then transmitted to the server over the network.

[0041] Step S3, decrypting the data, is the reverse operation of the encryption process in step S2. The server restores the business data using the corresponding algorithm and key. After receiving the encrypted data packet from the client, the server first Base64 decodes the fields in the data packet to obtain the encrypted ciphertext. Then, the server calls the RSA decryption algorithm, using the locally securely stored RSA private key to decrypt the random initialization vector IV and the AES key respectively. The decryption process also follows the OAEP padding scheme, restoring the original AES key and random initialization vector IV. The server then calls the AES decryption algorithm, using the same CBC mode as the encryption stage, with the restored AES key and random initialization vector IV as input, to decrypt the business data ciphertext. After decryption, the padding is removed to obtain the plaintext data.

[0042] To prevent replay attacks and expired requests, and to ensure the freshness of communication data, timestamp validity verification is required after data decryption. The specific process is as follows: The server extracts the timestamp field from the data decrypted in step S3, processes the timestamp format, and obtains the time the client sent the request through the parsed timestamp field. Simultaneously, the server obtains its current time to ensure time consistency. The server calculates the time difference between the client's request time and the server's current time, takes the absolute value, and checks if it exceeds 300 seconds. If the time difference is ≤300 seconds, the timestamp verification is successful, and the process proceeds to the subsequent blockchain evidence verification step. If the time difference is >300 seconds, the request is deemed expired or at risk of a replay attack, and the server immediately rejects the request and returns an expired request error.

[0043] After the timestamp verification is passed, the server extracts the communication data based on the blockchain evidence data. In step S2, the hash value of the encrypted data is written into the blockchain. The entire process of generating, uploading and verifying the blockchain timestamp is recorded in the blockchain distributed ledger, and each node saves a complete copy of the data. The verification process for the encrypted data stored on the blockchain in step S4 includes: tracing the corresponding block information, client, and corresponding node signature based on the timestamp hash value. If the corresponding block information, client, and corresponding node signature are all successfully verified, the verification is successful.

[0044] like Figures 7 to 10 As shown, after the server completes the business logic processing, it compresses and encrypts the response data. The specific implementation process includes the server executing the business logic, generating the original response data, and performing compression operations on the original response data, and selecting the compression method according to the data type.

[0045] In this embodiment, the server performs an adaptive compression algorithm based on data type. The server analyzes the type of the original data and determines that the data type is divided into numerical, text, pattern data and others. For numerical data, a numerical compression algorithm is used; for text data, a dictionary compression algorithm is used; for pattern data, a pattern recognition compression algorithm is used; and for other types of data, a zlib compression algorithm is used. After compression, compressed data in a unified format is generated.

[0046] Based on the data structure, the server determines the data structure. For flight data, it uses machine learning-based prediction compression, specifically: predicting the next data through historical data, then determining the difference between the actual data and the predicted next data, and compressing the difference to generate encrypted data. A smart compression algorithm is applied to the XYZ axis data in timestamps and flight data. Specifically, this involves extracting common parts and variable parts, generating an index, and then generating a compressed data packet from the common parts, variable parts, and generated index for transmission.

[0047] The server performs personalized compression based on hardware information. Using the machine code as a seed, a personalized compression dictionary is generated. The original response data is then compressed using dictionary encoding to generate compressed data. After the compressed data is transmitted, its validity will be verified through blockchain.

[0048] After processing the data, the server generates a new random 32-byte AES key and a 16-byte random initialization vector (IV). It then encrypts the compressed response data using CBC mode. Once encrypted, the server returns the encrypted response data to the client. The client receives the encrypted response data from the server, uses the locally stored AES key and IV, and decrypts the encrypted response data using CBC mode to obtain the compressed response data. The client then performs the corresponding decompression operation based on the compression scheme used by the server. After decompression, the client retrieves the original response data, completing the communication process.

[0049] The working principle of this invention is as follows: Digital signatures are used to verify the integrity of the RSA public key, preventing man-in-the-middle attacks and public key tampering. Each time, the client generates a random AES key and a random initialization vector (IV), and encrypts the random key using the public key to form a private key. This ensures that the plaintext of the private key is randomly generated, possessing a certain degree of randomness, and each generated private key is different. This makes it impossible to meet time requirements even if attacks are launched using randomness. Additionally, encrypted data is simultaneously sent and written to the blockchain. Therefore, after encryption, the data can be double-verified by checking the timestamp in the decrypted encrypted data and the encrypted data in the blockchain to determine whether to return the requested data. This double verification on the server side ensures communication security. Furthermore, the reliable communication characteristics of the blockchain ensure communication reliability. The encrypted data is categorized and compressed according to different data types for transmission, reducing data transmission pressure and further preventing tampering during transmission of the entire data.

Claims

1. A blockchain-based dynamic hybrid encryption communication method applied to communication between a client and a server, characterized in that: The method comprises the following steps: S1, distributing the public key: the client requests the RSA public key from the server, and the server returns the RSA public key and the digital signature; S2, generating the private key and encrypting the data: the client generates a random AES key and a random initialization vector IV for each timestamp, encrypts the random AES key and the random initialization vector IV through the RSA public key to form the private key; The encrypted data is obtained by encrypting the data and the timestamp through the private key; the hash value of the encrypted data and the timestamp is written into the blockchain; the encrypted data is compressed according to the data type to generate an encrypted data packet and sent to the server; S3, decrypting the encrypted data: the server decompresses the encrypted data packet after receiving it, decrypts the private key through the public key, and decrypts the encrypted data through the private key, S4, verifying the validity of the timestamp, if the verification is successful, verifying the encrypted data stored in the blockchain, if the verification is successful, returning the data request.

2. The dynamic hybrid encryption communication method based on blockchain according to claim 1, characterized in that: After step S4, it further comprises: S5, executing the business logic and preparing the response data; S6, the server returns the response data to the client after compressing and AES encrypting the response data; S7, the client obtains the response data through AES decryption and decompression. 3.The dynamic hybrid encryption communication method based on blockchain of claim 1, wherein: S1 further comprises: collecting hardware information, generating a machine code through a SHA256 hash algorithm, sending the machine code and the request RSA public key to the server, returning the RSA public key and the digital signature by the server under the condition that the machine code is verified to be valid, and entering step S2 under the condition that the digital signature is verified to be qualified.

4. The method of claim 1, wherein: The hardware information comprises a CPU ID, a motherboard serial number and a disk serial number.

5. The method of claim 1, wherein: The valid time of the timestamp in step S4 is ±5 minutes; if the valid time of the timestamp is exceeded, the request is rejected and an expired request error is returned.

6. The method of claim 1, wherein: In step S2, "compressing the encrypted data according to the data type to generate an encrypted data packet and sending it to the server" further comprises: determining the type of the data, including numerical type, text type data, pattern data and other types of data, using a numerical compression algorithm for numerical type data, using a dictionary compression algorithm for text type data, using a pattern recognition compression algorithm for pattern data, and using a zlib compression algorithm for other types of data.

7. The method of claim 1, wherein: Step S2 further comprises: before determining the type of the data, it further comprises determining the structure of the data, predicting the next data through historical data for flight data, then determining the difference value between the actual data and the predicted next data, and generating the encrypted data after compressing the difference value. 8.The dynamic hybrid encryption communication method based on blockchain of claim 7, wherein: Step S2 further comprises: for the timestamp and the XYZ axis data in the flight data, extracting the common part, the change part and generating the index, and then generating the compressed data packet by the common part, the change part and the generated index part for transmission. 9.The dynamic hybrid encryption communication method based on blockchain of claim 1, wherein: The dictionary compression algorithm in S2 comprises: generating a personalized dictionary according to the client hardware code, and compressing the text type data through the personalized dictionary; the server receives the compressed and encrypted data, generates the same personalized compression dictionary based on the client hardware code, and uses the same personalized compression dictionary to decompress the data and verify the validity through the blockchain. 10.The dynamic hybrid encryption communication method based on blockchain of claim 1, wherein: The writing of the hash value of the encrypted data into the blockchain in step S2 includes that the whole process of generation, uploading and verification of the blockchain timestamp is recorded in the blockchain distributed ledger, and each node saves a complete data copy; The verification process of the blockchain notarized encrypted data in step S4 includes that the corresponding block information, client and corresponding node signature are traced according to the timestamp hash value, and if the corresponding block information, client and corresponding node signature are all verified successfully, the verification is successful.

Images