Method and device for encrypting internal communication between CPUs of VPN device based on ECDH and BPF
By using the ECDH algorithm and BPF filter, fully encrypted communication between multiple CPUs is achieved within the VPN device, which solves the security risks of plaintext data transmission between CPUs and improves the security and communication performance of the VPN device.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NO 30 INST OF CHINA ELECTRONIC TECH GRP CORP
- Filing Date
- 2026-01-07
- Publication Date
- 2026-04-28
AI Technical Summary
The plaintext transmission of communication data between multiple physically isolated CPUs within a VPN device poses a security risk. Attackers can obtain plaintext communication data through software packet sniffing or hardware integration, leading to security harm.
The ECDH algorithm is used for key negotiation, a one-way hash function is used to generate BPF filtering options, which are compiled into BPF bytecode to capture and filter communication data packets, ensuring encrypted transmission of data packets.
It achieves fully encrypted communication of data within the VPN device, preventing plaintext data from being maliciously obtained, balancing confidentiality and transmission performance, and improving the device's security and communication efficiency.
Smart Images

Figure CN121940131A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the fields of communication and security encryption technology, and in particular to a method and device for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF. Background Technology
[0002] With the rapid development of network technology, numerous new network technologies are emerging, and network attack methods are becoming increasingly sophisticated. VPNs, as core security devices on the network, are facing growing challenges to their security. To meet higher security, performance, and other demands, VPN devices often use multiple physically isolated central processing units (CPUs) for internal and external data processing. These CPUs are physically isolated and operate independently, each processing data to enhance the VPN device's functionality, performance, and overall security. Communication data between CPUs flows within the VPN device, often employing methods such as shared memory, semaphores, message queues, SOCKETs, serial ports, and internal buses. However, shared memory and semaphores are only suitable for communication between multi-core CPUs on the same physical device or board, and not for internal communication between physically isolated CPUs. Serial ports and internal buses are less commonly used due to limitations in communication performance and implementation. SOCKET-based communication methods, due to their high reliability, good platform scalability and compatibility, and unified programming interface, have become the preferred choice for internal communication between multiple physically isolated CPUs within most VPN devices.
[0003] When multiple CPUs within a VPN device communicate internally via SOCKET, data flows within the device and is not transmitted externally. Therefore, in practice, communication data is often transmitted in plaintext. TCP / UDP-based SOCKET communication methods typically use agreed-upon listening ports, while RAW SOCKET-based methods often employ custom internal protocols. Both methods exhibit clear port and protocol information characteristics during plaintext transmission. If an attacker maliciously controls or acquires access to the VPN device, they can use software packet sniffing or hardware modifications to obtain the plaintext data of internal communications. This allows attackers to acquire and analyze the internal communication protocols and data, posing a security threat to the VPN device. Summary of the Invention
[0004] This application provides a method and device for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF. It addresses the problem of plaintext data transmission between multiple physically isolated CPUs within a VPN device by designing a method to encrypt and protect internal data, preventing malicious acquisition of plaintext data in internal communication. This method provides secure internal data transmission capabilities while balancing confidentiality and transmission performance.
[0005] This application provides a method for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF, applicable to scenarios where VPN devices require communication between CPUs, including: The ECDH key negotiation process is performed between the first CPU and the second CPU; After the negotiation process is completed, the negotiated key is hashed using a one-way hash function to obtain BPF filter options, where the BPF filter options are a specified number of bytes of the hash value of the key hash operation. Configure filtering rules according to the BPF filtering options and compile them into BPF bytecode; Based on the BPF bytecode, the communication data packets between the first CPU and the second CPU are captured, and the BPF bytecode is executed one by one when receiving packets to determine whether to retain or discard them.
[0006] This application provides a VPN device, which includes at least a first CPU and a second CPU. The first CPU and the second CPU work together to implement the aforementioned encrypted internal communication method between the CPUs of a VPN device based on ECDH and BPF.
[0007] This application provides a method for encrypting and protecting internal data to prevent malicious acquisition of plaintext data in internal communications. It balances confidentiality and transmission performance while providing secure internal data transmission capabilities.
[0008] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description
[0009] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a basic flowchart illustrating the encrypted internal communication method between CPUs of a VPN device according to an embodiment of this application. Figure 2 This is a schematic diagram of the internal communication negotiation packet for the encrypted internal communication method between the CPUs of a VPN device according to an embodiment of this application. Figure 3 This is a schematic diagram of the BPF filter setting and usage process for the VPN device CPU-to-CPU encrypted internal communication method according to an embodiment of this application. Figure 4 This is a schematic diagram of the fully encrypted communication data packet format of the VPN device CPU-to-CPU encrypted internal communication method according to an embodiment of this application; Figure 5 This is a schematic diagram of the fully encrypted internal communication process of the VPN device CPU encrypted internal communication method according to an embodiment of this application. Detailed Implementation
[0010] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.
[0011] This application innovatively proposes a method for efficient, fully encrypted internal communication between multiple CPUs in a VPN device based on ECDH and BPF. It utilizes the ECDH algorithm to securely negotiate communication keys between multiple CPUs, leverages the efficient packet processing capabilities of BPF, and employs filtering options from the key's one-way hash to achieve efficient, fully encrypted internal communication within the VPN device. This addresses the problems in the background technology and improves the security of the VPN device. Specifically, this application provides a method for encrypted internal communication between CPUs in a VPN device based on ECDH and BPF, applicable to scenarios where VPN devices require communication between CPUs, such as... Figure 1 As shown, it includes the following steps: In step S101, the first CPU and the second CPU perform an ECDH key negotiation process. ECDH is a Diffie-Hellman key exchange algorithm based on elliptic curve cryptography (ECC). Its security is based on the intractability of the discrete logarithm problem on elliptic curves, resulting in high security. It is widely used in TLS / SSL, SSH, and end-to-end encryption applications. The algorithm allows the communicating parties to negotiate a shared secret key on an insecure communication channel. During the negotiation phase, the two parties only share their respective public keys. The secret key calculated through negotiation can only be calculated by the two communicating parties, thereby achieving secure communication. The CPUs within the VPN device that need to perform encrypted communication have pre-defined, multi-party consistent elliptic curve parameters, with a base point G. Assuming the communicating parties are the first CPU A and the second CPU B, A needs to perform encrypted internal communication with B and actively initiates a key negotiation with B. In some embodiments of this application, the ECDH key negotiation process includes: The first CPU generates a random number PRIkeya as the private key, calculates the public key PUBkeya = PRIkeya * G, and sends the public key to the second CPU through the internal SOCKET. After receiving the public key, the second CPU generates a random number PRIkeyb as the private key, calculates the public key PUBkeyb = PRIkeyb * G, and sends the public key PUBkeyb to the first CPU through the internal SOCKET. The second CPU calculates the shared key Q' = PRIkeyb * PUBkeya = PRIkeyb * PRIkeya * G; After receiving the public key PUBkeyb, the first CPU calculates the shared key Q = PRIkeya * PUBkeyb = PRIkeyb * PRIkeya * G. If Q = Q', the first CPU and the second CPU have completed the shared key calculation that is consistent between them.
[0012] Specifically, in the ECDH key negotiation process, both parties only exchange their respective public keys. The private keys are kept secret by each party and not exposed on the channel. Even if the public key is captured, the shared key cannot be calculated. The ECDH internal communication key negotiation data packet includes a message length field, an internal communication classification identification code field, a public key field, and a checksum field. The message length field indicates the total length of the data packet; the identification code field identifies the type of internal communication for which this negotiation is conducted; the public key field contains the public key exchanged; and the checksum field is a cyclic redundancy check of the entire packet content. The internal communication negotiation packet format is as follows: Figure 2 As shown.
[0013] This application utilizes the ECDH algorithm to perform key negotiation before communication between CPUs. During internal data exchange, the negotiated key is used to encrypt the entire internal data packet, ensuring fully encrypted internal data exchange. In step S102, after the negotiation process is completed, a one-way hash function is used to hash the negotiated key to obtain BPF filter options, where the BPF filter options are a specified number of bytes of the hash value obtained from the key hash operation.
[0014] In step S103, filtering rules are configured according to the BPF filtering options and compiled into BPF bytecode.
[0015] In step S104, communication data packets between the first CPU and the second CPU are captured according to the BPF bytecode, and the BPF bytecode is executed one by one to determine whether to retain or discard the packets when they are received.
[0016] This application utilizes the efficient filtering mechanism of BPF. After key negotiation via ECDH, a one-way hash function is used to hash the key to obtain BPF filtering options. Filtering rules are written and compiled into BPF bytecode. During packet reception, BPF executes the bytecode line by line to determine whether to retain or discard packets. Considering both randomness and filtering performance, the filtering options use the first specified number of bytes of the key hash value. Each session uses this unique and fixed-length filtering option to efficiently filter data. Each session will only receive data packets that match the filtering options set in the session. After receiving the packets, the key is used to decrypt them and restore the plaintext data for further processing.
[0017] This application addresses the problem of plaintext data transmission between multiple physically isolated CPUs within a VPN device. It designs a method to encrypt and protect internal data, preventing malicious acquisition of plaintext data in internal communications. While providing secure internal data transmission capabilities, it is necessary to balance confidentiality and transmission performance.
[0018] In some embodiments of this application, the BPF filtering option is the first 8 bytes of the hash value of the key hash operation. Each session uses this unique and fixed-length 8-byte filtering option to filter and screen communication data. Setting the BPF filtering option to the first 8 bytes of the hash value of the key hash operation takes into account both randomness and filtering performance.
[0019] In some embodiments of this application, when the first CPU and the second CPU session perform internal interaction, the message format is "filtering options" + "fully encrypted internal data".
[0020] In some embodiments of this application, such as Figure 3 As shown, configuring filtering rules according to the BPF filtering options includes: The management process of the first CPU A initiates key negotiation with the second CPU B, the management process on the second CPU B responds, and calculates the shared key Q; CPU A and CPU B each perform a one-way hash on Q to obtain the filter option F = HASH(Q). The first specified number of bytes of F are then taken as the filter option, for example, the first 8 bytes of F. 0-7 As a filter option.
[0021] The first CPU A and the second CPU B respectively create threads THREADa and THREADb, and initialize the communication sockets FDA and FDb for this session respectively; CPU A and CPU B use the setsockopt function to set the filtering options for sockets FDa and FDb, respectively. For example, setting the filtering option F for sockets FDa and FDb. 0-7 .
[0022] The communication threads THREADa and THREADb on the first CPU A and the second CPU B respectively use FDA and FDb to communicate internally with each other.
[0023] At this point, the communication thread THREADa on CPU A and the communication thread THREADb on CPU B will only receive messages that match the filter option F. 0-7 For internal communication data packets, whether in a single process / thread or multiple processes / threads, BPF's efficient packet filtering ensures that a process / thread only receives data packets that match its filtering options. When multiple processes / threads communicate concurrently between CPUs or when there are many other interaction packets between CPUs, BPF's packet filtering features can significantly improve the performance of internal communication.
[0024] In some embodiments of this application, the communication data packet content for internal communication between the first CPU and the second CPU includes: total message length, filtering options, checksum, and a fully encrypted custom internal communication message. The format of the fully encrypted internal communication data packet is as follows: Figure 4 As shown, the custom internal communication message includes a command code, other custom fields, internal communication data payload, and a checksum.
[0025] Specifically, the total message length field indicates the total length of this communication message, the filter options field is the negotiated filter options, the command code field indicates the custom command code in internal communication, the custom field is other custom internal communication control fields, the internal communication data payload field is the payload of internal communication, check 1 is a cyclic redundancy check of all content within the encryption range, and check 2 is a cyclic redundancy check of the entire packet.
[0026] The command code, custom fields, internal communication data payload, and checksum 1 are all encrypted. Only the total message length, filtering options, and checksum 2 field are explicitly transmitted for efficient packet filtering, message length identification, and integrity verification of the entire packet. For cases requiring fragmentation, a fragmentation-then-encryption approach is used, with each CPU fragmenting and then encapsulating the data. Figure 4 The data is sent in the specified format. The control information for fragmentation and merging is customized by each CPU and filled into the internal communication data field within the encryption range.
[0027] In some embodiments of this application, such as Figure 5 As shown, this application further includes the following for efficient fully encrypted interaction process between multiple CPUs: each CPU establishes an internal communication information linked list and an internal communication session thread pool when it starts up. The internal communication information linked list stores keys and filtering options. Each internal communication information linked list item is uniquely bound to an internal interaction session thread. After multiple sets of internal communication session threads are started, they are in a waiting state and will run as needed when there is an internal interaction requirement.
[0028] In some embodiments of this application, such as Figure 5 As shown, in the case of internal communication between multiple CPUs, The key negotiation is initiated by the control program of the initiating CPU; After key negotiation is completed, the negotiated key and filtering options are added to the internal communication information linked list, and this linked list is bound to a session thread. The session thread sets the BPF filter based on the bound filtering options; When sending and receiving packets, use the bound key for encryption and decryption, and release and close the SOCKET after communication is complete to release this session.
[0029] This application utilizes ECDH to negotiate internal encryption and decryption keys, performing full packet encryption on SOCKET-based internal communication data to ensure the security of internal data in the event of malicious access. After one-way hashing of the key, BPF filtering options are derived. These filtering options serve as unique identifiers for inter-CPU session communication, eliminating the need for session differentiation at the protocol stack based on TCP or UDP ports, and also eliminating the need for session differentiation at the application layer based on internal command codes, thus improving the performance of fully encrypted internal communication.
[0030] The method in this application supports multiple concurrent fully encrypted internal communications. By leveraging BPF's efficient packet filtering capabilities, multiple sessions use different keys and different filtering options for fully encrypted internal communication. This approach achieves high security while mitigating the performance overhead caused by encryption and decryption. It is easy to implement and greatly improves the security of internal communication, which is of great significance for enhancing the overall security of VPN devices.
[0031] This application also proposes a VPN device, which includes at least a first CPU and a second CPU. The first CPU and the second CPU work together to implement the aforementioned encrypted internal communication method between the CPUs of a VPN device based on ECDH and BPF.
[0032] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0033] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0034] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0035] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.
Claims
1. A method for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF, characterized in that, This is applicable to scenarios where VPN devices require communication between CPUs, including: The ECDH key negotiation process is performed between the first CPU and the second CPU; After the negotiation process is completed, the negotiated key is hashed using a one-way hash function to obtain BPF filter options, where the BPF filter options are a specified number of bytes of the hash value of the key hash operation. Configure filtering rules according to the BPF filtering options and compile them into BPF bytecode; Based on the BPF bytecode, the communication data packets between the first CPU and the second CPU are captured, and the BPF bytecode is executed one by one when receiving packets to determine whether to retain or discard them.
2. The encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in claim 1, characterized in that, The key negotiation process between the first CPU and the second CPU for ECDH includes: The first CPU generates a random number PRIkeya as the private key, calculates the public key PUBkeya = PRIkeya * G, and sends the public key to the second CPU through the internal SOCKET. After receiving the public key, the second CPU generates a random number PRIkeyb as the private key, calculates the public key PUBkeyb = PRIkeyb * G, and sends the public key PUBkeyb to the first CPU through the internal SOCKET. The second CPU calculates the shared key Q' = PRIkeyb * PUBkeya = PRIkeyb * PRIkeya * G; After receiving the public key PUBkeyb, the first CPU calculates the shared key Q = PRIkeya * PUBkeyb = PRIkeyb * PRIkeya * G. If Q = Q', the first CPU and the second CPU have completed the shared key calculation that is consistent between them.
3. The encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in claim 2, characterized in that, The BPF filtering option is the first 8 bytes of the hash value of the key hash operation. Each session uses this unique, fixed-length 8-byte filtering option to filter and select communication data.
4. The encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in claim 3, characterized in that, When the first CPU and the second CPU communicate internally, the message format is "filtering options" + "fully encrypted internal data".
5. The method for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF as described in claim 2, characterized in that, Configuring filtering rules based on the BPF filtering options includes: The management process of the first CPU initiates key negotiation with the second CPU; The management process on the second CPU responds and calculates the shared key Q; The first CPU and the second CPU each perform a one-way hash on Q to obtain the filter option F=HASH(Q), and take the first specified number of bytes of F as the filter option; The first CPU and the second CPU respectively create threads THREADa and THREADb, and initialize the communication sockets FDA and FDb for this session respectively; The first CPU and the second CPU use the setsockopt function to set the filtering options for sockets FDa and FDb, respectively. The communication threads THREADa and THREADb on the first CPU and the second CPU respectively use FDA and FDb to communicate internally with each other.
6. The encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in claim 5, characterized in that, The communication data packets used for internal communication between the first CPU and the second CPU include: total message length, filtering options, checksum, and fully encrypted custom internal communication messages. The custom internal communication messages include command codes, other custom fields, internal communication data payload, and checksum.
7. The encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in claim 1, characterized in that, Also includes: When each CPU starts up, it establishes an internal communication information linked list and an internal communication session thread pool. The internal communication information linked list stores keys and filtering options. Each internal communication information linked list item is uniquely bound to an internal interaction session thread. After multiple sets of internal communication session threads are started, they are in a waiting state and will run as needed when there is an internal interaction requirement.
8. The method for encrypted internal communication between CPUs of a VPN device based on ECDH and BPF as described in claim 7, characterized in that, In the case of internal communication between multiple CPUs The key negotiation is initiated by the control program of the initiating CPU; After key negotiation is completed, the negotiated key and filtering options are added to the internal communication information linked list, and this linked list is bound to a session thread. The session thread sets the BPF filter based on the bound filtering options; When sending and receiving packets, use the bound key for encryption and decryption, and release and close the SOCKET after communication is complete to release this session.
9. A VPN device, characterized in that, It includes at least a first CPU and a second CPU, which work together to implement the encrypted internal communication method between CPUs of a VPN device based on ECDH and BPF as described in any one of claims 1-8.