Communication encryption method and apparatus, electronic device, and storage medium

By adopting the communication encryption method based on the ECDH algorithm in end-to-end communication, problems such as key exchange and use are solved, and efficient and secure key negotiation and encryption verification are achieved, ensuring the confidentiality and integrity of communication data.

WO2025086824A1PCT designated stage expired Publication Date: 2025-05-01TRUSTASIA TECH INC

Patent Information

Application Number
PCT/CN2024/111657
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-10-25
Filing Date
2024-08-13
Publication Date
2025-05-01

AI Technical Summary

Technical Problem

In end-to-end communication, how to effectively use the elliptic curve Diffie-Hellman (ECDH) algorithm to implement encryption and signature verification, solve problems such as key exchange and use, and ensure the confidentiality, integrity and authentication of communication content.

Method used

A communication encryption method based on the ECDH algorithm is designed, including two parties initializing operations, generating and parsing pre-key information, calculating negotiated encryption keys, handshake requests and verifications, and data encryption transmission. This method realizes key exchange through the ECDH algorithm and uses the ECDSA key for signature and verification.

Benefits of technology

It realizes efficient and secure key negotiation and end-to-end encryption verification, enhances the confidentiality and integrity of communication data, reduces the risk of man-in-the-middle attacks, and improves the user's ability to independently identify and choose.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024111657_01052025_PF_FP_ABST
    Figure CN2024111657_01052025_PF_FP_ABST
Patent Text Reader

Abstract

The present invention relates to the field of network security communications. Disclosed are a communication encryption method and apparatus, an electronic device, and a storage medium, for use in solving the confidentiality, integrity and authentication problems of communication content, making a communication process safer. The method comprises: two communication parties respectively complete initialization operations; a second communication party generates pre-key information PreKey, and a first communication party acquires and parses PreKey; after finishing parsing PreKey, the first communication party calculates an agreed encryption secret key Secret1, and initiates a handshake request to the second communication party; the second communication party receives the handshake request and verifies the handshake request, and after the verification is passed, the first communication party establishes connection with the second communication party; and the two communication parties start to perform encrypted data transmission. The method can achieve more efficient and safe secret key agreement, ensure the confidentiality and integrity of communication data, and allow a user to select whether to establish connection, thereby enhancing the capability of the user to perform autonomous identification and selection.
Need to check novelty before this filing date? Find Prior Art

Description

Communication encryption method, device, electronic device and storage medium Technical Field

[0001] The present invention relates to the field of network security, and in particular to the field of end-to-end communication security. Background Art

[0002] In today's society, information security has become a critical issue. With the widespread adoption of the internet and mobile devices, people are increasingly reliant on digital communications for information exchange and business transactions. Therefore, ensuring the confidentiality and integrity of this information has become crucial. Encryption technology has become essential to protecting this information. Public-key cryptography-based encryption algorithms are widely used in various applications. However, due to their limited encryption strength and key management, they present numerous security risks in practical applications. Traditional public-key cryptography algorithms present numerous security risks, such as improper key management, digital certificate tampering, and man-in-the-middle attacks. These vulnerabilities hinder the effective protection of the confidentiality, integrity, and authentication of communications. Technical issues

[0003] Encryption algorithms based on elliptic curve cryptography (ECC) are more efficient and secure than traditional public-key cryptography. The Elliptic Curve Diffie-Hellman (ECDH) algorithm is an ECC-based key exchange protocol used to negotiate a shared secret key between two communicating parties. The ECDH algorithm's irreversibility and high computational complexity effectively prevent eavesdropping and man-in-the-middle attacks, making it widely used in secure communications. However, in practical applications, implementing end-to-end encryption and signature verification using the ECDH algorithm still presents many challenges, such as key exchange and key usage. Technical Solutions

[0004] The purpose of the present invention is to provide a communication encryption method, device, electronic device and storage medium, and a secure communication mechanism is designed based on the ECDH algorithm, which is mainly used to solve the problem of end-to-end encryption signature verification.

[0005] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by practice of the present disclosure.

[0006] According to one aspect of the present disclosure, a communication encryption method is provided, comprising:

[0007] S101, both parties in communication complete initialization operations respectively;

[0008] S102, the second communication party generates pre-key information PreKey, and the first communication party obtains and parses the PreKey;

[0009] S103, after parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party;

[0010] S104, after the second communication party receives the handshake request and verifies that it is correct, the first communication party establishes a connection with the second communication party;

[0011] S105, the communicating parties begin to encrypt and transmit data.

[0012] In some embodiments, the two communicating parties perform initialization operations separately, including: the communicating parties generate and save two pairs of keys respectively, namely, a pair of ECDSA keys and a pair of ECDH keys, wherein the ECDSA key is mainly used for data signing / verification, and is referred to as a signature key in the present invention, and the ECDH key is mainly used for key exchange, and is referred to as a negotiation key in the present invention; the communicating parties also need to each generate a corresponding initialization ID to identify their own identity.

[0013] In some embodiments, the initialization ID can be generated according to the actual application scenario, including but not limited to using UUID, nickname, code name, but it must be able to uniquely identify the communicating party.

[0014] In some embodiments, the second communication party generates pre-key information PreKey, and the first communication party obtains and parses PreKey, including: the second communication party obtains the public key of the signing key generated by itself during the initialization operation, the public key of the negotiated key, the initialization ID, and the signature information, the above information composing the pre-key information PreKey, wherein the signature information is the result of signing the public key information of the negotiated key using the signing key of the second communication party;

[0015] After the first communication party obtains the PreKey, it first uses the parsed signature public key of the second communication party to verify the signature. If the signature verification fails, it is considered to be an illegal prekey and can be ignored.

[0016] At the same time, the first communication party temporarily caches the public key of the signature key and the public key of the negotiation key of the second communication party.

[0017] In some embodiments, the first communication party obtains the PreKey, including but not limited to using HTTP request and GRPC service method.

[0018] In some embodiments, after parsing the PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party, including: after parsing the PreKey, the first communication party uses the ECDH algorithm to calculate the negotiated encryption key Secret1 based on the public key of the second communication party's negotiated key and the negotiated key of the first communication party; calculates a Thumbprint1 consisting of 6 characters based on the negotiated key Secret1, and then initiates a handshake request to the second communication party.

[0019] In some embodiments, a 6-character Thumbprint1 is calculated based on the negotiated key Secret1, including:

[0020] S3001: Calculate a hash value using the SHA-256 algorithm based on the negotiated key, i.e., H = {h₁, h₂, h₃, ..., hₙ}, where H represents a hash value array, curly brackets {} represent a set, and h₁, h₂, h₃, ..., hₙ represent each hash value element in the array.

[0021] S3002, each element h in the HASH value i (i=1,..,n, here n=32) is converted into a hexadecimal string, and the length of each hexadecimal string should be 2 characters, and then all the strings are concatenated into a string hexString with a length of 64;

[0022] S3003, convert the hexString into an integer bigInt of type BigInt;

[0023] S3004 converts bigInt into a string Str, and extracts the first 6 characters of Str, ultimately obtaining 6 characters as a return value.

[0024] In some embodiments, the handshake request should include the signature public key of the first communication party, the exchange public key, the identity identifier, the encrypted ciphertext and a signature, wherein the encrypted ciphertext refers to the encryption of special information agreed upon by the two communication parties using the negotiated encryption key Secret1 calculated by the first communication party, and the encryption method is AES-256 (CBC mode). The signature refers to signing the encrypted ciphertext using the signature key of the first communication party.

[0025] In some embodiments, after the second communication party receives the handshake request and verifies that the handshake request is correct, the first communication party establishes a connection with the second communication party, including:

[0026] When the second communication party receives the handshake request, it first uses the signature public key of the second communication party in the handshake request to verify the signature information contained in the handshake request message. After the verification is passed, it uses the negotiated key of the second communication party and the public key of the negotiated key of the first communication party to calculate a negotiated encryption key Secret2. It uses Secret2 to decrypt the encrypted information to verify whether it is consistent with the plaintext information negotiated by both parties. If it is consistent, it calculates and displays Thumbprint2 based on Secret2 to confirm whether the communication connection is established. The calculation method of Thumbprint2 is the same as Thumbprint1, but Thumbprint2 is calculated based on Secret2;

[0027] When the Thumbprint1 and Thumbprint2 displayed by the first communication party and the second communication party are consistent, the user can choose whether to accept the request to establish a communication connection. If they are inconsistent, the communication request is directly rejected.

[0028] After the user allows the connection to be established, the communicating parties respectively save each other's signature public key and the public key of the negotiated key. At this time, the first communicating party and the second communicating party successfully establish a connection.

[0029] In some embodiments, the communicating parties begin to perform data encryption transmission, including: when one communicating party sends data to the other party, it needs to encrypt the transmitted data first, and the transmitted data contains two parts: encrypted ciphertext and signature information, wherein the encryption method of the ciphertext is to perform AES-256 (CBC mode) encryption based on the negotiated encryption key Secret1, and the encryption method of the signature information is to use the signature key of the communicating party to sign the ciphertext; after receiving the message from the other party, the other communicating party needs to first verify whether the signature information is correct, and then perform the message decryption operation.

[0030] According to another aspect of the present disclosure, there is provided a communication encryption device, comprising:

[0031] Initialization module, the first communication party and the second communication party complete the initialization operation;

[0032] Pre-key module: the second communication party generates pre-key information PreKey, and the first communication party obtains and parses the PreKey;

[0033] Handshake module: After parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party. After the second communication party receives the handshake request and verifies it, it establishes a connection with the first communication party.

[0034] The encryption communication module starts the data encryption transmission between the first communication party and the second communication party.

[0035] According to another aspect of the present disclosure, an electronic device is provided, comprising: a memory storing multiple instructions; and a processor loading instructions from the memory to execute steps in any one of the communication encryption methods provided in the embodiments of the present application.

[0036] According to another aspect of the present disclosure, a computer-readable storage medium is provided, including: the computer-readable storage medium stores multiple instructions, and the instructions are suitable for a processor to load to execute the steps in any one of the communication encryption methods provided in the embodiments of the present application. Beneficial effects

[0037] The present invention adopts a key exchange protocol based on the ECDH algorithm, which can achieve efficient and secure key negotiation. Compared with the traditional key exchange protocol based on the RSA algorithm, the ECDH algorithm has a shorter key length and faster encryption speed.

[0038] This invention uses end-to-end encryption and signature verification to ensure the confidentiality and integrity of communication data. Compared with traditional mechanisms that only encrypt and verify the communication link, end-to-end encryption and signature verification can better protect user privacy and data security.

[0039] The present invention standardizes the process of key exchange using the ECDH algorithm and the structure of message communication, solves the problems of confidentiality, integrity and authentication of communication content, and makes the communication process more secure.

[0040] When establishing a connection, the present invention requires both communicating parties to jointly display a thumbprint, and the user can choose whether to establish the connection. This mechanism allows the user to determine whether a man-in-the-middle attack exists in the connection between the two parties. The user can choose whether to establish the connection based on the information displayed by both parties, thereby enhancing the user's ability to independently identify and choose. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0042] FIG1 is an architecture diagram of a communication encryption method provided in an embodiment of the present application;

[0043] FIG2 is a flow chart of a communication encryption method provided in an embodiment of the present application;

[0044] FIG3 is a schematic diagram of the structure of a communication encryption device provided in an embodiment of the present application;

[0045] FIG4 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. Modes for Carrying Out the Invention

[0046] Exemplary embodiments of the present invention will now be described more fully with reference to the accompanying drawings. However, exemplary embodiments can be implemented in various forms, and it should not be understood that the present invention is limited to the embodiments set forth herein. On the contrary, providing these exemplary embodiments enables the present invention to be more comprehensive and complete, making it easier to fully convey the inventive concept to those skilled in the art. In the figures, the same reference numerals represent the same or similar elements, components or parts, and thus their repeated description will be omitted.

[0047] Under the premise of being consistent with the technical concept of the present invention, the features, structures, characteristics or other details described in a specific embodiment do not exclude that they can be combined in one or more other embodiments in a suitable manner.

[0048] In the description of specific embodiments, the features, structures, characteristics, or other details of the present invention are described to enable those skilled in the art to fully understand the embodiments. However, this does not preclude those skilled in the art from practicing the technical solutions of the present invention without one or more of the specific features, structures, characteristics, or other details.

[0049] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0050] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0051] The term "and / or" or "and / or" includes all combinations of any one or more of the associated listed items.

[0052] Embodiments of the present application provide a communication encryption method, device, electronic device, and storage medium.

[0053] The communication encryption device can be integrated into an electronic device, such as a terminal or a server. The terminal can be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, or personal computer (PC); the server can be a single server or a server cluster consisting of multiple servers.

[0054] In some embodiments, the communication encryption device can also be integrated into multiple electronic devices. For example, the communication encryption device can be integrated into multiple servers, and the communication encryption method of the present application can be implemented by multiple servers.

[0055] In some embodiments, the server may also be implemented in the form of a terminal.

[0056] It should be noted that the serial numbers of the following embodiments are not intended to limit the preferred order of the embodiments.

[0057] In this embodiment, a digital certificate statistics method is provided, as shown in FIG2 , which is applied to a server. The specific process of the communication encryption method can be as follows:

[0058] S101, both parties in communication complete initialization operations respectively.

[0059] In some embodiments, the two communicating parties complete initialization operations separately, including: the communicating parties generate and save two pairs of keys respectively, namely, a pair of ECDSA keys and a pair of ECDH keys, wherein the ECDSA key is mainly used for data signing / verification, and is referred to as a signature key in the present invention, and the ECDH key is mainly used for key exchange, and is referred to as a negotiation key in the present invention; the communicating parties also need to each generate a corresponding initialization ID to identify their own identity.

[0060] In some embodiments, the initialization ID can be generated according to the actual application scenario, including but not limited to using UUID, nickname, code name, but it must be able to uniquely identify the communicating party.

[0061] S102: The second communication party generates pre-key information PreKey, and the first communication party obtains and parses the PreKey.

[0062] In some embodiments, the second communication party generates pre-key information PreKey, and the first communication party obtains and parses PreKey, including: the second communication party obtains the public key of the signing key generated by itself during the initialization operation, the public key of the negotiated key, the initialization ID, and the signature information, the above information composing the pre-key information PreKey, wherein the signature information is the result of signing the public key information of the negotiated key using the signing key of the second communication party;

[0063] After the first communication party obtains the PreKey, it first uses the parsed signature public key of the second communication party to verify the signature. If the signature verification fails, it is considered to be an illegal prekey and can be ignored.

[0064] At the same time, the first communication party temporarily caches the public key of the signature key and the public key of the negotiation key of the second communication party.

[0065] In some embodiments, the first communication party obtains the PreKey, including but not limited to obtaining it using an HTTP request or a GRPC service.

[0066] S103: After parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party.

[0067] In some embodiments, after parsing the PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party, including: after parsing the PreKey, the first communication party uses the ECDH algorithm to calculate the negotiated encryption key Secret1 based on the public key of the second communication party's negotiated key and the negotiated key of the first communication party; calculates a Thumbprint1 consisting of 6 characters based on the negotiated key Secret1, and then initiates a handshake request to the second communication party.

[0068] In some embodiments, a 6-character Thumbprint1 is calculated based on the negotiated key Secret1, including:

[0069] S3001: Calculate a hash value using the SHA-256 algorithm based on the negotiated key, i.e., H = {h₁, h₂, h₃, ..., hₙ}, where H represents a hash value array, curly brackets {} represent a set, and h₁, h₂, h₃, ..., hₙ represent each hash value element in the array.

[0070] S3002, each element h in the HASH value i (i=1,..,n, here n=32) is converted into a hexadecimal string, and the length of each hexadecimal string should be 2 characters, and then all the strings are concatenated into a string hexString with a length of 64;

[0071] S3003, convert the hexString into an integer bigInt of type BigInt;

[0072] S3004 converts bigInt into a string Str, and extracts the first 6 characters of Str, ultimately obtaining 6 characters as a return value.

[0073] In some embodiments, the handshake request should include the signature public key of the first communication party, the exchange public key, the identity identifier, the encrypted ciphertext and a signature, wherein the encrypted ciphertext refers to the encryption of special information agreed upon by the two communication parties using the negotiated encryption key Secret1 calculated by the first communication party, and the encryption method is AES-256 (CBC mode). The signature refers to signing the encrypted ciphertext using the signature key of the first communication party.

[0074] S104: After the second communication party receives the handshake request and verifies it as correct, the first communication party establishes a connection with the second communication party.

[0075] In some embodiments, after the second communication party receives the handshake request and verifies it as correct, the first communication party establishes a connection with the second communication party, including: when the second communication party receives the handshake request, first using the signature public key of the second communication party in the handshake request to verify the signature information contained in the handshake request message, after the verification is passed, using the negotiation key of the second communication party and the public key of the negotiation key of the first communication party to calculate a negotiated encryption key Secret2, using Secret2 to decrypt the encrypted information to verify whether it is consistent with the plaintext information negotiated by both parties, if consistent, then calculating and displaying Thumbprint2 based on Secret2 to confirm whether to establish a communication connection, the calculation method of Thumbprint2 is the same as Thumbprint1, but Thumbprint2 is calculated based on Secret2; when the Thumbprint1 and Thumbprint2 displayed by the first communication party and the second communication party are consistent, the user can choose whether to accept the request to establish a communication connection, if not, directly reject the communication request; after the user allows the connection to be established, the communication parties respectively save each other's signature public key and the public key of the negotiation key, at which time the first communication party and the second communication party successfully establish a connection.

[0076] S105, the communicating parties begin to encrypt and transmit data.

[0077] In some embodiments, the communicating parties begin to perform data encryption transmission, including: when one communicating party sends data to the other party, it needs to encrypt the transmitted data first, and the transmitted data contains two parts: encrypted ciphertext and signature information, wherein the encryption method of the ciphertext is to perform AES-256 (CBC mode) encryption based on the negotiated encryption key Secret1, and the encryption method of the signature information is to use the signature key of the communicating party to sign the ciphertext; after receiving the message from the other party, the other communicating party needs to first verify whether the signature information is correct, and then perform the message decryption operation.

[0078] The present invention adopts a key exchange protocol based on the ECDH algorithm, which can achieve efficient and secure key negotiation. Compared with the traditional key exchange protocol based on the RSA algorithm, the ECDH algorithm has a shorter key length and faster encryption speed.

[0079] This invention uses end-to-end encryption and signature verification to ensure the confidentiality and integrity of communication data. Compared with traditional mechanisms that only encrypt and verify the communication link, end-to-end encryption and signature verification can better protect user privacy and data security.

[0080] The present invention standardizes the process of key exchange using the ECDH algorithm and the structure of message communication, solves the problems of confidentiality, integrity and authentication of communication content, and makes the communication process more secure.

[0081] When establishing a connection, the present invention requires both communicating parties to display a thumbprint, and the user can choose whether to establish the connection. This mechanism allows the user to determine whether a man-in-the-middle attack exists in the connection between the two parties. The user can choose whether to establish the connection based on the code displayed by both parties, thereby enhancing the user's ability to independently identify and select.

[0082] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides a communication encryption device. Referring to FIG3 , an embodiment of the communication encryption device in the embodiment of the present invention includes:

[0083] Initialization module 301: used for the first communication party and the second communication party to complete the initialization operation;

[0084] Pre-key module 302: used for the second communication party to generate pre-key information PreKey, and the first communication party to obtain and parse the PreKey;

[0085] Handshake module 303: After parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party. After the second communication party receives and verifies the handshake request, it establishes a connection with the first communication party.

[0086] Encryption communication module 304: used for the first communication party and the second communication party to start encrypted data transmission.

[0087] The specific implementation of the device in the above embodiment can be found in the method embodiment, and has the corresponding beneficial effects of the method embodiment, which will not be repeated here.

[0088] In some embodiments, the initialization module 301 includes a key generation module, and the key generation module is configured to: the communicating parties respectively generate and save two pairs of keys, namely, a pair of ECDSA keys and a pair of ECDH keys, wherein the ECDSA key is mainly used for data signing / verification, and is referred to as a signature key in the present invention, and the ECDH key is mainly used for key exchange, and is referred to as a negotiation key in the present invention; the communicating parties also need to each generate a corresponding initialization ID to identify their own identity.

[0089] In some embodiments, the initialization ID includes but is not limited to using a UUID, a nickname, or a code name, but must be able to uniquely identify the communicating party.

[0090] In some embodiments, the pre-key module 302 includes a pre-key generation module, a pre-key acquisition module, and a pre-key parsing and verification module, wherein the pre-key generation module is configured to: the second communication party obtains the public key of the signing key, the public key of the negotiated key, the initialization ID, and the signature information generated by itself during the initialization operation, and the above information constitutes the pre-key information PreKey, wherein the signature information is the result of signing the public key information of the negotiated key using the signing key of the second communication party;

[0091] The pre-key acquisition module is configured to: the first communication party obtains the PreKey, including but not limited to obtaining it using HTTP request or GRPC service;

[0092] The pre-key parsing and verification module is configured as follows: after the first communication party obtains the PreKey, it first uses the parsed signature public key of the second communication party to verify the signature. If the signature verification fails, it is considered to be an illegal pre-key and can be ignored. At the same time, the first communication party temporarily caches the public key of the signature key and the public key of the negotiation key of the second communication party.

[0093] In some embodiments, the handshake module 303 includes a negotiated encryption key calculation module, a communication connection parameter calculation module, and a handshake request initiation module, wherein the negotiated encryption key calculation module is configured to: after the first communication party parses the PreKey, calculate the negotiated encryption key Secret1 based on the public key of the negotiated key of the second communication party and the negotiated key of the first communication party using the ECDH algorithm;

[0094] The communication connection parameter calculation module is configured to calculate a Thumbprint1 consisting of 6 characters based on the negotiated key Secret1. The specific steps are as follows:

[0095] S601: Calculate a hash value using the SHA-256 algorithm based on the negotiated key, i.e., H = {h₁, h₂, h₃, ..., hₙ}, where H represents a hash value array, curly brackets {} represent a set, and h₁, h₂, h₃, ..., hₙ represent each hash value element in the array.

[0096] S602, each element h in the HASH value i (i=1,..,n, here n=32) is converted into a hexadecimal string, and the length of each hexadecimal string should be 2 characters, and then all the strings are concatenated into a string hexString with a length of 64;

[0097] S603, converting the hexString into an integer bigInt of the BigInt type;

[0098] S604, converting bigInt into a string Str, and intercepting the first 6 characters of Str, and finally obtaining 6 characters as a return value.

[0099] The handshake request initiation module is configured as follows: the first communication party initiates a handshake request to the second communication party based on the calculated communication connection parameters. The handshake request information should include the signature public key, exchange public key, identity identifier, encrypted ciphertext and a signature of the first communication party. Among them, the encrypted ciphertext refers to the use of the negotiated encryption key Secret1 calculated by the first communication party to encrypt a special information agreed upon by the two communication parties. The encryption method is AES-256 (CBC mode). The signature refers to signing the encrypted ciphertext using the signature key of the first communication party.

[0100] In some embodiments, the encryption communication module 304 includes a handshake verification module, a communication establishment module, and an encryption communication module, wherein:

[0101] The handshake verification module is configured to: when the second communication party receives the handshake request, first use the signature public key of the second communication party in the handshake request to verify the signature information included in the handshake request message;

[0102] The module for determining whether to establish communication is configured to: calculate a negotiated encryption key Secret2 using the negotiated key of the second communication party and the public key of the negotiated key of the first communication party after verification, decrypt the encrypted information using Secret2, and verify whether it is consistent with the plaintext information negotiated by both parties. If they are consistent, calculate and display Thumbprint2 based on Secret2 to confirm whether to establish a communication connection. The calculation method of Thumbprint2 is the same as that of Thumbprint1, but Thumbprint2 is calculated based on Secret2. When the Thumbprint1 and Thumbprint2 displayed by the first communication party and the second communication party are consistent, the user can choose whether to accept the request to establish a communication connection. If they are inconsistent, the communication request is directly rejected. After the user allows the connection to be established, the communication parties respectively save the other party's signature public key and the public key of the negotiated key. At this time, the first communication party and the second communication party successfully establish a connection;

[0103] The encrypted communication module is configured to: After the connection is established, the communicating parties begin encrypted data transmission. Specifically, when one party sends data to the other party, it needs to encrypt the transmitted data first. The transmitted data consists of two parts: encrypted ciphertext and signature information. The ciphertext is encrypted using AES-256 (CBC mode) based on the negotiated encryption key Secret1. The signature information is encrypted by signing the ciphertext using the signature key of the communicating party.

[0104] After receiving the message from the other party, the other party must first verify whether the signature information is correct and then decrypt the message.

[0105] In specific implementation, the above units can be implemented as independent entities, or can be arbitrarily combined to be implemented as the same or several entities. The specific implementation of the above units can be found in the previous method embodiments and will not be repeated here.

[0106] The specific implementation of the device in the above embodiment can be found in the method embodiment, and has the corresponding beneficial effects of the method embodiment, which will not be repeated here.

[0107] The present application also provides an electronic device, as shown in FIG4 , which is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. In FIG4 , the electronic device may include: a processor 401, a memory 402, an input / output interface 403, a communication interface 404, and a bus 405. The processor 401, the memory 402, the input / output interface 403, and the communication interface 404 are connected to each other within the device via the bus 405.

[0108] The memory 402 stores machine-readable instructions executable by the processor 401. When the electronic device is running, the processor 401 communicates with the memory 402 through the bus 405. When the machine-readable instructions are executed by the processor 401, the steps of the communication encryption method in the method embodiment shown in Figures 1, 2 and 3 above can be executed.

[0109] The input / output interface 403 is used to connect to an input / output module to enable information input and output. The input / output module can be configured as a component within the device (not shown) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., while output devices may include a display, speaker, vibrator, indicator light, etc.

[0110] The communication interface 404 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0111] The bus 405 comprises a pathway for transmitting information between various components of the device (eg, the processor 401 , the memory 402 , the input / output interface 403 , and the communication interface 404 ).

[0112] It should be noted that although the above device only shows the processor 401, the memory 402, the input / output interface 403, the communication interface 404, and the bus 405, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0113] The specific implementation of the electronic device of the above embodiment can be found in the method embodiment, and has the corresponding beneficial effects of the method embodiment, which will not be repeated here.

[0114] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, the steps of the communication encryption method in the method embodiment shown in Figures 1, 2 and 3 above can be executed. The specific implementation method can be found in the method embodiment and will not be repeated here.

[0115] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the methods, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division, and other division methods may be used in actual implementation.

[0117] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0119] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium that is executable by a processor. Based on this understanding, the technical solution of the present application, 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media that can store program codes.

[0120] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The scope of protection of the present application is not limited thereto. Although the present application has been described in detail with reference to the above-mentioned embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-mentioned embodiments within the technical scope disclosed in the present application, or perform equivalent replacements for some of the technical features thereof. These modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A communication encryption method, characterized in that: The method comprises: S1, the two communicating parties complete the initialization operation respectively; S2, the second communication party generates pre-key information PreKey, and the first communication party obtains and parses PreKey; S3, after parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party; S4, after the second communication party receives the handshake request and verifies it, the first communication party establishes a connection with the second communication party; S5, the communicating parties start encrypting and transmitting data.

2. The communication encryption method according to claim 1, characterized in that: The two parties in communication respectively complete initialization operations, including: The communicating parties respectively generate and save two pairs of keys, namely, a pair of ECDSA keys and a pair of ECDH keys, wherein the ECDSA key is mainly used for data signing / verification, and is referred to as a signature key in the present invention, and the ECDH key is mainly used for key exchange, and is referred to as a negotiation key in the present invention; the communicating parties also need to generate corresponding initialization IDs respectively to identify their own identities.

3. The communication encryption method according to claim 2, characterized in that: The initialization ID can be generated according to the actual application scenario, including but not limited to using UUID, nickname, code name, but it must be able to uniquely identify the communicating party.

4. The communication encryption method according to claim 1, characterized in that: The second communication party generates pre-key information PreKey, and the first communication party obtains and parses PreKey, including: The second communication party obtains the public key of the signature key, the public key of the negotiation key, the initialization ID and the signature information generated by itself during the initialization operation, and the above information constitutes the pre-key information PreKey, wherein the signature information is the result of signing the public key information of the negotiation key using the signature key of the second communication party; After the first communication party obtains the PreKey, it first uses the parsed signature public key of the second communication party to verify the signature. If the signature verification fails, it is considered to be an illegal prekey and the PreKey can be ignored; At the same time, the first communication party temporarily caches the public key of the signature key and the public key of the negotiation key of the second communication party.

5. The communication encryption method according to claim 1 or 4, characterized in that: The first communication party obtains PreKey, including but not limited to obtaining it using HTTP request or GRPC service.

6. The communication encryption method according to claim 1, characterized in that: After parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party, including: After parsing PreKey, the first communication party uses the ECDH algorithm to calculate the negotiated encryption key Secret1 based on the public key of the negotiated key of the second communication party and the negotiated key of the first communication party; A 6-character Thumbprint1 is calculated based on the negotiated key Secret1, and then a handshake request is initiated to the second communication party.

7. The communication encryption method according to claim 6, characterized in that: The method calculates a 6-character Thumbprint1 based on the negotiated key Secret1, including: S701, calculate a HASH value based on the negotiated key using the SHA-256 algorithm, that is, H = {h₁, h₂, h₃, ..., hₙ}, where H represents a hash value array, curly brackets {} represent a set, and h₁, h₂, h₃, ..., hₙ represent each hash value element in the array; S702, each element h in the HASH value i (i=1,..,n, here n=32) is converted into a hexadecimal string, and the length of each hexadecimal string should be 2 characters, and then all the strings are concatenated into a string hexString with a length of 64; S703, converting the hexString into an integer bigInt of the BigInt type; S704, converting bigInt into a string Str, and intercepting the first 6 characters of Str, and finally obtaining 6 characters as a return value.

8. The communication encryption method according to claim 1 or 6, characterized in that: The handshake request shall include the signature public key, exchange public key, identity, encrypted ciphertext and a signature of the first communication party, wherein the encrypted ciphertext refers to the encryption of special information agreed upon by the two communication parties using the negotiated encryption key Secret1 calculated by the first communication party, and the encryption method is AES-256 (CBC mode). The signature refers to signing the encrypted ciphertext using the signature key of the first communication party.

9. The communication encryption method according to claim 1, characterized in that: After the second communication party receives the handshake request and verifies that it is correct, the first communication party establishes a connection with the second communication party, including: When the second communication party receives the handshake request, it first uses the signature public key of the second communication party in the handshake request to verify the signature information contained in the handshake request message. After the verification is passed, it uses the negotiation key of the second communication party and the public key of the negotiation key of the first communication party to calculate a negotiated encryption key Secret2, and uses Secret2 to decrypt the encrypted information to verify whether it is consistent with the plaintext information negotiated by both parties. If it is consistent, Thumbprint2 is calculated and displayed based on Secret2 to confirm whether the communication connection is established. The calculation method of Thumbprint2 is the same as Thumbprint1, but Thumbprint2 is calculated based on Secret2; When the Thumbprint1 and Thumbprint2 displayed by the first communication party and the second communication party are consistent, the user can choose whether to accept the request to establish a communication connection. If they are inconsistent, the communication request is directly rejected; After the user allows the connection to be established, the communicating parties respectively save each other's signature public key and the public key of the negotiated key. At this time, the first communicating party and the second communicating party successfully establish a connection.

10. The communication encryption method according to claim 1, characterized in that: The communicating parties begin to perform data encryption transmission, including: When one party in communication sends data to the other party, it needs to encrypt the transmitted data first. The transmitted data consists of two parts: encrypted ciphertext and signature information. The method of encrypting ciphertext is to encrypt it with AES-256 (CBC mode) according to the negotiated encryption key Secret1, and the method of encrypting signature information is to sign the ciphertext with the signature key of the communicating party. After receiving the message from the other party, the other party in the communication must first verify whether the signature information is correct before decrypting the message.

11. A communication encryption device, characterized in that: Applicable to a first communication party and a second communication party, comprising: An initialization module, in which the first communication party and the second communication party complete an initialization operation; Pre-key module, the second communication party generates pre-key information PreKey, and the first communication party obtains and parses PreKey; Handshake module: after parsing PreKey, the first communication party calculates the negotiated encryption key Secret1 and initiates a handshake request to the second communication party. After the second communication party receives the handshake request and verifies it, it establishes a connection with the first communication party. The encryption communication module, the first communication party and the second communication party start to perform data encryption transmission.

12. An electronic device, characterized in that: It includes a processor and a memory, wherein the memory stores a plurality of instructions; the processor loads the instructions from the memory to execute the steps in the communication encryption method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a plurality of instructions, and the instructions are suitable for loading by a processor to execute the steps in the communication encryption method described in any one of claims 1 to 10.

Citation Information

Patent Citations

  • Communication encryption method and device, electronic equipment and storage medium

    CN117278217A

  • Method of performing XZ-elliptic curve cryptography for use with network securtiy protocols

    US20140064491A1

  • End-to-End Encryption During a Secure Communication Session

    US20200259640A1

  • Method of establishing a cryptographic key shared between a first and a second terminal

    US20200396066A1

  • Method for establishing communication channel, and user terminal

    US20230284027A1

Cited By

  • OpenVPN security customization method and system, and medium

    CN121217489A