Communication method, apparatus, storage medium, and computer program product

Abstract

The application discloses a communication method, device, storage medium and computer program product, and belongs to the technical field of communication. The method comprises the following steps: if a first application process needs to use a socket to interact with a second application process, the use permission of the socket is suspended, the first application process is an application process in a first node, and the second application process is an application process in a second node; a first key corresponding to the socket is acquired; and the use permission of the socket is allocated to the first application process, and the first application process is used to interact with the second application process by using the socket to protect application data by the first key. The application avoids the application process to interact with the application data which is not protected by the key before the first key is acquired, thereby realizing full-link encryption and improving the communication security. Moreover, the application also realizes the communication encryption of the socket granularity, and the encryption granularity is finer and the security is higher.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, device, storage medium, and computer program product. Background Technology

[0002] Currently, the communication environment is becoming increasingly complex, making communication security paramount. Among these security concerns, the security of communication between application processes is receiving increasing attention as applications evolve, and improving this security is a hot research topic in the industry. Summary of the Invention

[0003] This application provides a communication method, apparatus, storage medium, and computer program product, capable of end-to-end encryption of communication between application processes, thereby improving the security of communication between application processes. The technical solution is as follows:

[0004] Firstly, a communication method is provided, the method comprising:

[0005] If the first application process needs to use a socket to interact with the second application process for application data, then the allocation of usage rights for the socket is suspended. The first application process is the application process in the first node, and the second application process is the application process in the second node. The first key corresponding to the socket is obtained. The usage rights of the socket are allocated to the first application process, and the first application process uses the socket to interact with the second application process for application data protected by the first key.

[0006] In other words, before the first application process uses the socket to interact with the second application process to exchange application data, the allocation of usage rights for the socket is suspended. This prevents the first and second application processes from exchanging application data without key protection before obtaining the first key. After obtaining the first key, the usage rights for the socket are then allocated to the first application process, thereby enabling secure communication between application processes through the first key. This solution achieves end-to-end secure communication between application processes and improves communication security.

[0007] Furthermore, the first key in this application is the key corresponding to the socket, meaning that this application can achieve communication encryption at the socket level. Compared with communication encryption at the node level, the encryption granularity of this application is finer, which can prevent the security level of the entire node from being reduced after the node-level encryption is broken, thus providing higher security.

[0008] In this process, the first application process and the second application process can establish a communication connection through a three-way handshake. The three-way handshake is performed through the aforementioned socket. In one implementation, the allocation of usage rights for the socket can be suspended before the three-way handshake ends, thereby ensuring that during the time period between the end of the three-way handshake and the acquisition of the first key, the first application process and the second application process are not allowed to use the socket to interact with application data that is not protected by the key.

[0009] In one possible implementation, obtaining the first key corresponding to the socket includes: negotiating the first key with a second proxy through a first proxy and a second proxy, where the first proxy is a proxy in the first node and the second proxy is a proxy in the second node. That is, key negotiation is performed through proxies at both ends of the communication, without the application process being aware of it.

[0010] In one possible implementation, obtaining the first key through key negotiation between the first and second proxies includes: assigning usage rights of the socket to the first proxy; and the first proxy using the socket to negotiate the first key with the second proxy. That is, by reusing the socket created by the application process to complete key negotiation between proxies, it avoids creating too many sockets and causing unnecessary resource waste. Furthermore, it prevents the first application process from using the socket during this period, thereby ensuring application data security.

[0011] In one possible implementation, the key negotiation is completed through a secure handshake between the first agent and the second agent. This secure handshake is based on a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs. That is, the application certificates ensure the security of the key negotiation process and guarantee that the first key is not leaked.

[0012] In one possible implementation, the first application process runs in user space, and the kernel of the first node records key-value pairs corresponding to the socket. The key in the key-value pair is the metadata of the socket, and the value in the key-value pair includes the first key. The metadata is used to identify the first application process and the second application process. After allocating the socket usage rights to the first application process, the method further includes: based on the key-value pair, using the first key in the kernel to encrypt and / or decrypt application data interacting using the socket. That is, encrypting and decrypting application data in the kernel reduces the functional complexity of the application process. The metadata is used to identify the processes at both ends of the communication, i.e., to identify a process pair. In this application, the aforementioned socket metadata identifies the process pair of the first and second application processes. An application process may communicate with multiple application processes, and the metadata can uniquely identify a process pair.

[0013] Since the first application process is an application process in the first node, and the first node usually runs more than one process, each process may implement secure inter-process communication according to the communication method provided in this application. That is, there may be more than one process in the first node using a socket, and the socket used has a corresponding key. Based on this, the kernel can record the key-value pairs corresponding to the sockets of multiple processes in the first node. When any process in these multiple processes needs to use a socket to send data, it can query the key corresponding to the corresponding socket from the multiple key-value pairs recorded in the kernel.

[0014] Based on this, in one possible implementation, the step of encrypting and / or decrypting application data interacting with the socket using the first key in the kernel based on the key-value pair includes: using the metadata of the socket as the target key, querying the value in the key-value pair containing the target key in the kernel to obtain the first key; and using the first key in the kernel to encrypt and / or decrypt application data interacting with the socket.

[0015] Based on the above implementation, after obtaining the first key corresponding to the socket (for example, after the first agent and the second agent negotiate the first key to obtain the first key), the method further includes: recording the key-value pair corresponding to the socket in the kernel.

[0016] In one possible implementation, the first key is determined by a first proxy, for example, by key negotiation between the first proxy and a second proxy. The first proxy runs in user space and is a proxy in the first node. Before recording the key-value pair corresponding to the socket in the kernel, the method further includes: transmitting the metadata and the first key to the kernel through the first proxy.

[0017] It should be understood that when the first agent is running in user space, after obtaining the first key through key negotiation, the first agent can transmit the socket's metadata and the first key to the kernel. This allows the kernel to record the corresponding key-value pair in the kernel, enabling it to subsequently encrypt and decrypt application data based on this recorded key-value pair. In other words, before encrypting / decrypting the application data transmitted through the socket, the kernel can query the record for the value of the key-value pair containing the socket's metadata (i.e., the target key) to find the first key, and then use this first key to encrypt / decrypt the application data transmitted through the socket.

[0018] The kernel can record key-value pairs corresponding to multiple sockets. These sockets are used by multiple processes running in the first node, and the first application process can be any one of these processes. Based on this, whenever the kernel obtains application data transmitted using a particular socket, it can use the socket's metadata as a target key, query the value of the target key's key-value pair from the recorded key-value pairs corresponding to the multiple sockets, obtain the key corresponding to that socket, and use this key to encrypt / decrypt the application data transmitted by that socket.

[0019] In one possible implementation, the first key is determined using a first application certificate and a second application certificate, where the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs. After obtaining the first key corresponding to the socket, the method further includes: if the first application certificate and / or the second application certificate is updated, then obtaining the second key corresponding to the socket, and the first application process uses the socket to interact with the second application process to exchange application data protected by the second key. That is, considering that application certificates usually have a validity period, the previously obtained key is no longer secure after the application certificate expires. Therefore, it is necessary to update the key corresponding to the socket when the application certificate is updated.

[0020] In one possible implementation, obtaining the second key corresponding to the socket includes: upon reaching a first time point, obtaining the second key corresponding to the socket, where the first time point is prior to the certificate expiration time, and the duration between the first time point and the certificate expiration time is a first duration threshold, where the certificate expiration time refers to the expiration time of the certificate before the update. That is, a new key (i.e., the second key) needs to be determined before the certificate expires, thereby allowing sufficient time for key switching to complete before the certificate expires, thus ensuring communication security.

[0021] The process of obtaining the second key can be similar to that of obtaining the first key. For example, based on the updated application certificate, a secure handshake is performed between the first and second proxies to negotiate the key and obtain the second key.

[0022] In one possible implementation, the application data protected by the first key includes application data encrypted with the first key. This encrypted application data includes application data within a first time period. The first time period includes the time between the moment the first key is acquired and a second moment, where the second moment occurs after the moment the second key is acquired, and the duration between the second moment and the moment the second key is acquired is a second duration threshold. That is, after acquiring the second key, it is not immediately used to encrypt application data; instead, the first key continues to be used for encryption, thus reserving time for a smooth key switching.

[0023] In one possible implementation, the second time point occurs before the certificate expiration time, which refers to the expiration time of the certificate before the update. That is, during the period between obtaining the new key and the certificate expiration time, encryption can continue to be performed using the first key.

[0024] It should be understood that the aforementioned first time period is only used to limit the time period for encryption using the first key, and is not used to limit the time period for decryption using the first key. In this application, after obtaining the second key, the second key can be enabled, i.e., used for decryption. Based on this, in one possible implementation, after obtaining the second key corresponding to the socket, the method further includes: obtaining first application data received using the socket and encrypted; and decrypting the encrypted first application data using the first key and / or the second key.

[0025] The step of decrypting the encrypted first application data using the first key and / or the second key includes:

[0026] The encrypted first application data is decrypted using the first key; if decryption of the encrypted first application data using the first key fails, the encrypted first application data is decrypted using the second key; or...

[0027] The encrypted first application data is decrypted using the second key. If the decryption of the encrypted first application data using the second key fails, the encrypted first application data is decrypted using the first key.

[0028] In one possible implementation, the kernel of the first node records key-value pairs corresponding to the socket, where the key in the key-value pair is the metadata of the socket, and the value in the key-value pair includes the first key. The metadata is used to identify the first application process and the second application process. After obtaining the second key corresponding to the socket, the method further includes: updating the value in the key-value pair, where the updated value includes the first key and the second key. After obtaining the encrypted first application data received using the socket, and before decrypting the encrypted first application data using the first key and / or the second key, the method further includes: using the metadata of the socket as the target key, querying the value in the key-value pair containing the target key from the kernel to obtain the first key and the second key.

[0029] In one possible implementation, after updating the value in the key-value pair, the method further includes: upon reaching a third time point, deleting the first key from the value, wherein the third time point is after the second time point, and the duration between the third and second time points is a third duration threshold. That is, upon reaching the third time point, the key switching ends, and by deleting the first key from the value included in the key-value pair corresponding to the socket, both ends of the communication subsequently use the second key for encryption and decryption.

[0030] The third moment can be located before the certificate expires, to ensure that the key switch is completed before the certificate expires.

[0031] In one possible implementation, the first agent exists within a service mesh architecture.

[0032] Secondly, a communication device is provided, which has the function of implementing the communication method described in the first aspect. The communication device includes one or more modules for implementing the communication method provided in the first aspect.

[0033] That is, a communication device is provided, the communication device comprising:

[0034] The management module is used to suspend the allocation of socket usage permissions if the first application process needs to use a socket to interact with the second application process for application data. The first application process is the application process in the first node, and the second application process is the application process in the second node.

[0035] The key acquisition module is used to acquire the first key corresponding to the socket;

[0036] The management module is also used to assign the usage rights of the socket to the first application process, and the first application process is used to use the socket to interact with the second application process to exchange application data protected by the first key.

[0037] In one possible implementation, the key acquisition module includes:

[0038] The key negotiation submodule is used to negotiate the key with the second agent through the first agent to obtain the first key. The first agent is the agent in the first node, and the second agent is the agent in the second node.

[0039] In one possible implementation, the management module is further configured to: assign the socket usage rights to the first agent;

[0040] The key negotiation submodule is specifically used to: negotiate the first key with the second agent through the first agent using the socket.

[0041] In one possible implementation, the key negotiation is completed through a secure handshake between the first agent and the second agent. The secure handshake is based on a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs.

[0042] In one possible implementation, the first application process runs in user mode, and the kernel of the first node records key-value pairs corresponding to the socket. The key in the key-value pair is the meta-information of the socket, and the value in the key-value pair includes the first key. The meta-information is used to identify the first application process and the second application process.

[0043] The device further includes:

[0044] The query module is used to use the metadata of the socket as the target key to query the value in the key-value pair containing the target key from the kernel, and obtain the first key;

[0045] An encryption / decryption module is used in the kernel to encrypt and / or decrypt application data that is interacted using the socket.

[0046] In one possible implementation, the device further includes:

[0047] A recording module is used to record the key-value pairs corresponding to the socket in the kernel.

[0048] In one possible implementation, the first key is determined through a first proxy, which runs in user space and is a proxy in the first node; the device further includes:

[0049] The transmission module is used to transmit the metadata and the first key to the kernel through the first agent.

[0050] In one possible implementation, the first key is determined using a first application certificate and a second application certificate, wherein the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs; the apparatus further includes:

[0051] The key update module is used to obtain the second key corresponding to the socket after obtaining the first key corresponding to the socket, if the first application certificate and / or the second application certificate are updated. The first application process is also used to use the socket to interact with the second application process to exchange application data protected by the second key.

[0052] In one possible implementation, the key update module is specifically used for:

[0053] Upon reaching the first moment, the second key corresponding to the socket is obtained. The first moment is before the certificate expiration moment, and the duration between the first moment and the certificate expiration moment is a first duration threshold. The certificate expiration moment refers to the expiration moment of the certificate before the update.

[0054] In one possible implementation, the application data protected by the first key includes application data encrypted with the first key. The application data encrypted with the first key includes application data within a first time period. The first time period includes the time period between the moment when the first key is acquired and a second moment. The second moment is located after the moment when the second key is acquired, and the duration between the second moment and the moment when the second key is acquired is a second duration threshold.

[0055] In one possible implementation, the second time point is located before the certificate expiration time point, which refers to the expiration time of the certificate before the update.

[0056] In one possible implementation, the device further includes:

[0057] The data acquisition module is used to acquire, after acquiring the second key corresponding to the socket, the first application data received using the socket and encrypted.

[0058] An encryption / decryption module is used to decrypt the encrypted first application data using the first key and / or the second key.

[0059] In one possible implementation, the encryption / decryption module is specifically used for:

[0060] The encrypted first application data is decrypted using the first key; if decryption of the encrypted first application data using the first key fails, the encrypted first application data is decrypted using the second key; or...

[0061] The encrypted first application data is decrypted using the second key. If the decryption of the encrypted first application data using the second key fails, the encrypted first application data is decrypted using the first key.

[0062] In one possible implementation, the kernel of the first node records key-value pairs corresponding to the socket, where the key in the key-value pair is the metadata of the socket, and the value in the key-value pair includes the first key. The metadata is used to identify the first application process and the second application process. The device further includes:

[0063] The recording module is used to update the value in the key-value pair after obtaining the second key corresponding to the socket. The updated value includes the first key and the second key.

[0064] The query module is used to use the metadata of the socket as the target key to query the value in the key-value pair containing the target key from the kernel, and obtain the first key and the second key.

[0065] In one possible implementation, the recording module is further configured to:

[0066] After updating the value in the key-value pair, if the third time point is reached, the first key in the value is deleted, the third time point being after the second time point, and the duration between the second time point and the third time point being a third duration threshold.

[0067] In one possible implementation, the first proxy exists within a ServiceMesh architecture.

[0068] Thirdly, a computer device is provided, comprising a processor and a memory, the memory for storing a program for executing the communication method provided in the first aspect, and storing data related to implementing the communication method provided in the first aspect. The processor is configured to execute the program stored in the memory.

[0069] In one possible implementation, the computer device may further include a communication bus for establishing a connection between the processor and the memory.

[0070] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the communication method described in the first aspect.

[0071] Fifthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the communication method described in the first aspect.

[0072] The technical effects achieved by the second, third, fourth, and fifth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect, and will not be repeated here. Attached Figure Description

[0073] Figure 1 This is a schematic diagram illustrating the development of a service architecture according to an embodiment of this application;

[0074] Figure 2 This is a system architecture diagram related to the communication method provided in the embodiments of this application;

[0075] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0076] Figure 4 This is a flowchart of a communication method provided in an embodiment of this application;

[0077] Figure 5 This is a schematic diagram of an internal hardware and software architecture of a node provided in an embodiment of this application;

[0078] Figure 6 This is a flowchart of another communication method provided in an embodiment of this application;

[0079] Figure 7 This is a timing diagram illustrating the use of a key, provided in an embodiment of this application.

[0080] Figure 8 This is a flowchart of yet another communication method provided in the embodiments of this application;

[0081] Figure 9 This is a software system architecture diagram for inter-node communication provided in an embodiment of this application;

[0082] Figure 10 This is a flowchart illustrating a seamless socket migration method provided in an embodiment of this application;

[0083] Figure 11 This is a schematic diagram of another node internal hardware and software architecture provided in an embodiment of this application;

[0084] Figure 12 This is a flowchart of a multi-key management method provided in an embodiment of this application;

[0085] Figure 13 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0086] Figure 14 This is a schematic diagram of another communication device provided in an embodiment of this application;

[0087] Figure 15 This is a schematic diagram of the structure of another communication device provided in the embodiments of this application. Detailed Implementation

[0088] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0089] Before introducing the communication method provided in the embodiments of this application, the relevant knowledge background, application scenarios and implementation environment of the embodiments of this application will be introduced first.

[0090] First, the relevant knowledge background and application scenarios of the embodiments of this application will be introduced.

[0091] This application relates to the field of cloud-native service mesh technology. Cloud-native technology refers to a set of technologies and management methods for building and running applications, which fully utilize the advantages of cloud computing, such as elasticity, scalability, and flexibility. Its current development status is as follows... Figure 1 As shown.

[0092] Figure 1 This is a schematic diagram illustrating the development of a service architecture according to an embodiment of this application. See also... Figure 1With the increasing complexity of application scenarios and the explosive growth of information scale, modern software has evolved from traditional monolithic architecture (also known as monolithic system) and microservice architecture to Service Mesh architecture. In monolithic architecture, each business application (also known as a business application) has its own independent software development kit (SDK), such as encryption transmission SDK, authentication SDK, and traffic orchestration SDK. In microservice architecture, multiple business applications are abstracted into multiple microservice applications, each of which can use different software technology stacks, and each microservice application has 10+ SDK adaptation codes. Service Mesh architecture, based on microservice architecture, provides common technical capabilities such as traffic governance, authentication and encryption, and traffic monitoring for business applications. It features non-intrusive and loosely coupled business logic, greatly simplifying the development process of business applications. Further details on these three architectures can be found in related technologies; this application's embodiments will not elaborate further.

[0093] To achieve the non-intrusive and loosely coupled technical implementation of ServiceMesh, the industry currently employs two main approaches.

[0094] The first approach is the Istio microservice architecture, which uses a proxy to intercept (hold) data traffic and performs traffic governance functions such as encryption within the proxy. However, this method still has many shortcomings in traffic encryption scenarios, such as service interruption when the proxy restarts, inability to achieve end-to-end encryption (e.g., traffic remains in plaintext before being intercepted by the proxy), and poor network performance. This is due to inherent flaws in the proxy pattern's architectural design.

[0095] The second method is the more mature software Cilium. This method retains the Layer 7 traffic management function in user space and pushes some Layer 4 traffic management down to the kernel. Traffic encryption is also implemented in the kernel using node-to-node encryption tunnels. While this method improves network performance compared to Istio, its encryption capabilities suffer from drawbacks due to the use of inter-node tunnel encryption, including the inability to achieve end-to-end encryption, coarse encryption granularity, and poor encryption performance.

[0096] Based on this, the communication method provided in this application embodiment can achieve full-link network communication encryption, avoiding the transmission of plaintext business data over the network. Furthermore, compared with the node-level encryption schemes used in the industry, the technical solution in this application embodiment can achieve socket-level communication encryption, preventing the overall node security level from being downgraded after node-level encryption is compromised.

[0097] Although the communication method provided in this application is designed based on some existing technical problems of the ServiceMesh architecture, it is not limited to the ServiceMesh architecture. That is, the technical solution of this application can also be applied to other technical architectures.

[0098] Next, the implementation environment of the embodiments of this application will be introduced.

[0099] Figure 2 This is a system architecture diagram related to the communication method provided in the embodiments of this application. See also... Figure 2 The system architecture includes a first node 201 and a second node 202. A communication connection can be established between the first node 201 and the second node 202, and the first node 201 and the second node 202 are used to achieve secure communication according to the communication method provided in the embodiments of this application.

[0100] In this embodiment, the first node 201 may be the initiator of the aforementioned communication connection, or the second node 202 may be the initiator of the aforementioned communication connection. This application does not limit this.

[0101] The first node 201 can be a service node in a cloud scenario, and the second node 202 can also be a service node in a cloud scenario. For example, both the first node and the second node can be nodes in a service mesh architecture, that is, the system architecture can be a service mesh structure.

[0102] In this embodiment, both the first node 201 and the second node 202 can be servers or terminal devices, such as mobile phones or computers. The first node 201 and the second node 202 can be the same type of device or different types of devices. This embodiment does not limit the type and structure of the first node 201 and the second node 202.

[0103] Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. In some embodiments, the computer device is... Figure 2 The first node 201 is shown in the diagram. The computer device includes one or more processors 301, a communication bus 302, a memory 303, and one or more communication interfaces 304.

[0104] The processor 301 is a general-purpose central processing unit (CPU), a natural network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. In some embodiments, the PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0105] The communication bus 302 is used to transmit information between the aforementioned components. In some embodiments, the communication bus 302 is divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0106] The memory 303 may be a read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), optical disc (including compact disc read-only memory (CD-ROM), compressed optical disc, laser disc, digital versatile optical disc, Blu-ray disc, etc.), magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 303 exists independently and is connected to the processor 301 via a communication bus 302, or the memory 303 is integrated with the processor 301.

[0107] Communication interface 304 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 304 includes a wired communication interface and / or a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0108] In some embodiments, the computer device includes multiple processors, such as Figure 3 The processors 301 and 305 shown are illustrated. Each of these processors is either a single-core processor or a multi-core processor. Here, a processor refers to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0109] As one embodiment, the computer device also includes an output device 306 and an input device 307. The output device 306 communicates with the processor 301 and can display information in various ways. For example, the output device 306 can be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 307 communicates with the processor 301 and can receive user input in various ways. For example, the input device 307 can be a mouse, keyboard, touchscreen device, or sensing device.

[0110] In some embodiments, memory 303 stores program code 310 for executing the scheme of this application, and processor 301 is capable of executing the program code 310 stored in memory 303. The program code includes one or more software modules, and the computer device can implement the following by means of processor 301 and program code 310 in memory 303. Figure 4 The communication method provided in the embodiment.

[0111] It should be understood that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0112] Figure 4This is a flowchart illustrating a communication method provided in an embodiment of this application. The method is applied to a communication system including a first node and a second node. The steps of the method are executed by the first node, for example, by a process or service module within the first node. This process or service module can run on the processor of the first node. Please refer to... Figure 4 The method includes the following steps.

[0113] Step 401: If the first application process needs to use a socket to interact with the second application process for application data, then suspend the allocation of the socket usage permission. The first application process is the application process in the first node, and the second application process is the application process in the second node.

[0114] In this embodiment, the first application process can be any application process in the first node, and the second application process can be any application process in the second node. A socket serves as a bridge for communication between the first and second application processes. The first and second applications can use this socket to establish a communication connection and then use it for application data interaction. The initiator of this communication connection can be either the first or the second application; this embodiment does not limit this.

[0115] The socket can be created by the first application process when the communication connection is established. It should be understood that the second application process will also create a corresponding socket within the second node. The socket created by the first application process matches the socket created by the second application process. Meta-information is written into the socket. The meta-information of the sockets created by the two application processes is reversed. Specifically, the source process identifier and destination process identifier in the meta-information of the socket created by the first application process can be the identifier (identity, ID) of the first application process and the identifier of the second application process, respectively. Similarly, the source process identifier and destination process identifier in the meta-information of the socket created by the second application process can be the identifier of the second application process and the identifier of the first application process, respectively. Besides the meta-information, other attribute information written into the sockets created by the two application processes can be the same or match. A more detailed description of sockets can be found in related technologies; this application's embodiments will not elaborate further.

[0116] In one implementation, the first application and the second application establish a communication connection using this socket through a three-way handshake. The implementation process of the three-way handshake can be found in related technologies, and will not be described in detail in this embodiment.

[0117] To achieve secure communication, if the first application process needs to use this socket to interact with the second application process for application data, the allocation of usage rights for the socket is suspended first. Before the application data interaction, the first key corresponding to the socket is obtained through step 402, so as to protect the application data being interacted with using the first key.

[0118] When the aforementioned communication connection is established via a three-way handshake, the allocation of usage rights for the socket can be suspended before the three-way handshake ends, for example, during the three-way handshake process. It should be understood that suspending the allocation of usage rights for the socket means that the socket cannot be modified, such as data cannot be written to it. However, the first application process can still use the socket to complete the three-way handshake, but it cannot write application data to the socket. This ensures that during the period between the end of the three-way handshake and the acquisition of the first key corresponding to the socket, the socket is not allowed to be used for exchanging application data. This prevents the first and second application processes from exchanging application data without key protection during this period, thus ensuring application data security and achieving end-to-end encryption.

[0119] In this application embodiment, the user of the above-mentioned socket can be referred to as the socket owner. One way to suspend the allocation of the socket's usage rights is to clear (i.e. delete) the socket's owner information.

[0120] The operation of suspending the allocation of usage rights for this socket can be automatically triggered during the first application process's system call to complete the three-way handshake, thereby clearing the socket's owner information before the three-way handshake is completed. Since the three-way handshake is completed automatically in the kernel, it is not affected by the owner. After the owner information is cleared, the first application process may attempt to send and / or receive data through this socket. However, the system will first determine whether the current owner of the socket is the first application process. If not, the system may delay the response or directly return an error code.

[0121] As an example, after the above socket is created, the first node records the owner information of the socket, such as the identifier of the first application process. After the operation of pausing the allocation of usage rights for the socket is triggered, the owner information of the socket becomes empty.

[0122] Step 401 described above is the corresponding operation performed by the first node to ensure application data security. In this embodiment, the second node can also perform a similar operation to ensure application data security. That is, if the second application process needs to use a socket created by the second application process to interact with the first application process for application data, the second node will suspend the allocation of usage permissions for the socket created by the second application process. The specific implementation method is similar to the method of suspending socket usage permissions in the first node, and will not be described in detail here.

[0123] Figure 5 This is a schematic diagram of the internal hardware and software architecture of a node provided in an embodiment of this application. Figure 5 The node shown can be the first node or the second node; this node can be a server or other device. See also... Figure 5 This node includes user space 5011 and kernel space 5021. User space 5011 runs an application (APP) 5012, while kernel space 5021 includes a socket management module 5024, which in turn includes an owner management module 5022. Application 5021 is used to run application processes, such as a first application process or a second application process. Owner management module 5022 is used to allocate usage permissions for sockets, i.e., to manage the owner information of sockets, including clearing the owner information of sockets as mentioned above.

[0124] by Figure 5 Taking the first node as an example, during the execution of the first application process in application 5021, the first application process establishes a communication connection with the second application process in the second node through a three-way handshake. At the start of the three-way handshake, after the first application process creates a socket, the owner management module 5022 records the socket's owner information as the identifier of the first application process. During the three-way handshake process, when the first application process calls a system kernel function to complete the handshake, the owner management module 5022 is automatically triggered to clear the socket's owner information. This process is invisible to user-mode applications.

[0125] In some embodiments, the first application process may also be referred to as the first service process (hereinafter referred to as the first service) or the first business process (hereinafter referred to as the first business), and the second application process may also be referred to as the second service process (hereinafter referred to as the second service) or the second business process (hereinafter referred to as the second business).

[0126] Step 402: Obtain the first key corresponding to the socket.

[0127] After suspending the allocation of usage rights for the socket, you can then perform the operation of obtaining the first key corresponding to the socket.

[0128] In one implementation, the process of obtaining the first key corresponding to the socket is as follows: The first key is obtained through key negotiation between a first proxy and a second proxy. The first proxy is a proxy within the first node, and the second proxy is a proxy within the second node. In other words, key negotiation is performed through proxies at both ends of the communication.

[0129] In one possible implementation, see Figure 6 Step 402 may include step 4021: allocating the socket usage rights from step 401 to the first agent, and step 4022: the first agent using the socket to negotiate a key with the second agent to obtain a first key. That is, by reusing the socket, key negotiation between agents is completed. By reusing the socket, on the one hand, creating too many sockets and causing unnecessary resource waste can be avoided; on the other hand, it can also prevent the first application process from using the socket during this period, thereby ensuring application data security.

[0130] One way to implement the allocation of socket usage rights to the first agent in step 401 is to write the identifier of the first agent into the owner information of the socket, that is, to set the first agent as the owner of the socket.

[0131] As an example, it can be done by Figure 5 The owner management module 5022 in the middle is used to assign the usage rights of this socket to the first agent. Figure 5 Taking the first node as an example, user mode 5011 also runs agent 5013 (which can be called the first agent). The owner management module 5022 can assign the usage rights of the socket to agent 5013.

[0132] It should be understood that, in Figure 5 In the illustrated embodiments, the agent in the node (such as the first agent) runs in user mode. However, in some other embodiments, the agent in the node may also run in kernel mode, and this application does not limit this. Furthermore, the agent in this application embodiment can be a process or a service module, such as a service module in the operating system; it can be a resident agent, serving various application processes, or it can be a process triggered by an application process that needs to communicate, providing services one-to-one with the application process. In summary, this application embodiment does not limit the specific form or location of the agent in the node.

[0133] In another possible implementation, the first agent can create a new socket and use it to complete key negotiation with the second agent. In any case, the first agent can complete key negotiation with the second agent through any socket; this application embodiment does not limit which socket is used for key negotiation.

[0134] The aforementioned key negotiation can be completed through a secure handshake between the first and second proxies, thereby ensuring the security of the key negotiation process and preventing key leakage. This secure handshake can be implemented based on a first application certificate and a second application certificate, where the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs.

[0135] In one implementation, the first agent obtains a first application certificate and a second application certificate, and performs key negotiation with the second agent based on the first and second application certificates. Correspondingly, the second agent also obtains the first application certificate and the second application certificate, and performs key negotiation with the first agent based on the first and second application certificates.

[0136] The first application certificate contains a first public-private key pair, and the second application certificate contains a second public-private key pair. During the key negotiation process, messages sent from the first agent to the second agent can be encrypted using the public key in the second public-private key pair. After receiving the message encrypted with the public key, the second agent can decrypt it using the private key in the second public-private key pair. Similarly, messages sent from the second agent to the first agent can be encrypted using the public key in the first public-private key pair, and after receiving the message encrypted with the public key, the first agent can decrypt it using the private key in the first public-private key pair.

[0137] The above key negotiation process can be implemented based on the Transport Layer Security (TLS) protocol or other protocols, and this application embodiment does not limit this.

[0138] Furthermore, the embodiments of this application do not limit the key used in the key negotiation process to be the public-private key pair in the first application certificate and the second application certificate, nor do they limit the encryption method used in the encrypted message to asymmetric encryption or symmetric encryption. That is, the embodiments of this application do not limit the specific implementation method of the above key negotiation.

[0139] In addition to obtaining the first key corresponding to the socket through key negotiation between the first and second proxies as described above, the first key corresponding to the socket can also be obtained in other ways, such as by determining the first key corresponding to the socket through a trusted third-party node and passing it to the first and second nodes. This application will not provide further examples of such methods.

[0140] In some embodiments, the first proxy can exist in the ServiceMesh architecture, that is, the first proxy can be a functional module in the ServiceMesh architecture. The first proxy can serve multiple microservice programs to determine the key corresponding to the socket for multiple microservice programs. The first application process mentioned above can be the process of any one of the multiple microservice programs.

[0141] Step 403: Assign the usage rights of the socket to the first application process. The first application process uses the socket to interact with the second application process on application data protected by the first key.

[0142] After obtaining the first key corresponding to the socket, the usage rights of the socket can be assigned (i.e. switched to or returned to) the first application process, so that the first application process can use the socket to interact with the second application process to exchange application data protected by the first key.

[0143] The first key can be used to encrypt and decrypt application data exchanged between the first and second application processes. For example, the first key can be used to encrypt application data to be sent from the first application process to the second application process, and to encrypt application data to be sent from the second application process to the first application process. It can also be used to decrypt application data received by the first node that has been encrypted with the first key, and to decrypt application data received by the second node that has been encrypted with the first key. In other words, data protected by the first key includes data that has been encrypted and decrypted using the first key. It should be understood that, for one end of the communication, encryption may be involved without decryption, or both encryption and decryption may be involved, depending on whether the communication end is sending and / or receiving data.

[0144] In this embodiment, the first application process runs in user mode, but the encryption and decryption operations on application data can occur in kernel mode, that is, the encryption and / or decryption of application data are performed in the kernel. This will be described below.

[0145] In one possible implementation, the kernel of the first node records the key-value pairs corresponding to the aforementioned sockets. The key in each key-value pair is the socket's metadata, and the value includes a first key. This metadata is used to identify both the first and second application processes. Based on this, after allocating usage rights to the socket to the first application process, the kernel can use the first key, based on the key-value pair, to encrypt and / or decrypt application data used for interaction via the socket.

[0146] It should be understood that the first application process is only one application process in the first node. The first node usually runs more than one process, and each process may implement secure inter-process communication according to the communication method provided in the embodiments of this application. That is, there may be more than one process in the first node using a socket, and the socket used has a corresponding key. Based on this, the kernel can record the key-value pairs corresponding to the sockets of multiple processes in the first node. When any process in these multiple processes needs to use a socket to send data, it can query the key corresponding to the corresponding socket from the multiple key-value pairs recorded in the kernel.

[0147] Taking the example that the first application process needs to use the socket in step 403 to interact with application data, the above implementation process of encrypting and / or decrypting the application data interacting with the socket in the kernel based on the key-value pair can be as follows: take the metadata of the socket as the target key, query the value in the key-value pair where the target key is located in the kernel to obtain the first key; use the first key in the kernel to encrypt and / or decrypt the application data interacting with the socket.

[0148] Accordingly, after obtaining the first key through step 402, the key-value pair corresponding to the socket can also be recorded in the kernel.

[0149] Taking the first key being determined through the first agent as an example, if the first agent is running in user space, before recording the key-value pair corresponding to the socket in the kernel, the first agent transmits the aforementioned metadata and the first key to the kernel to instruct the kernel to record the key-value pair corresponding to the socket.

[0150] In one possible implementation, after obtaining the first key, the first agent writes the first key into the socket and passes the socket to the kernel. The kernel can then extract the metadata and the first key from the socket and record the correspondence between the metadata and the first key (i.e., the key-value pair mentioned above).

[0151] As an example, see further. Figure 5 The socket management module 5024 also includes a multi-key manager 5023, which is used to record the aforementioned key-value pairs. In one implementation, after the agent 5013 determines the first key, it writes the first key into the socket and passes the socket to the multi-key manager 5023. The multi-key manager 5023 extracts the metadata and the first key from the socket and records them as a key-value pair.

[0152] See also Figure 5 The kernel mode 5021 also includes an encryption module 5025, which is used to encrypt and decrypt application data using key-value pairs recorded in the multi-key manager 4023.

[0153] Taking sending application data using the aforementioned socket as an example, after the first application process writes the application data to be encrypted into the socket, the encryption module 5025 is triggered to obtain the metadata written into the socket and the application data to be encrypted. The obtained metadata is used as the target key, and the value of the key-value pair containing the target key is queried from the multi-key manager 5023 to obtain the first key. The first key is then used to encrypt the application data to be encrypted. Here, the socket can be data within the kernel. The first application process writing application data into the socket can be considered as transmitting application data to the kernel. After the first application process transmits the application data to the kernel, the encryption operation is completed in the kernel.

[0154] Figure 5 The hardware 5031 includes a network card 5032. After the encryption module 5025 completes the encryption operation, it sends application data encrypted with the first key to the network card 5032 and sends the application data encrypted with the first key to the second node through the network card 5032.

[0155] Taking the use of the aforementioned socket to receive application data as an example, the network card 5032 receives and transmits the encrypted application data to the encryption module 5025. After obtaining the metadata corresponding to the encrypted application data, the encryption module 5025 uses this metadata as the target key to query the value of the key-value pair containing the target key from the multi-key manager 5023, obtaining the first key. The first key is then used to decrypt the encrypted application data. The decrypted data can then be transmitted to the first application process in the application program 5012.

[0156] The kernel (such as encryption module 5025) can obtain the metadata corresponding to the encrypted application data by retrieving the metadata from the unencrypted header information in the data packet containing the application data.

[0157] Steps 401 to 403 can be executed when a communication connection is first established between the first application process and the second application process. They do not need to be executed repeatedly after a communication connection is established again (the socket's metadata remains unchanged). Alternatively, they can be executed after each communication connection is established. Or, the validity period of the first key can be set, and the execution can be repeated after the first key expires.

[0158] As discussed above, in one implementation, the first key can be determined using a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs. Considering that application certificates typically have an expiration date, the previously negotiated key is no longer secure after the application certificate expires. Therefore, it is necessary to renegotiate the key when the application certificate is updated. This will be discussed in the following section.

[0159] After obtaining the first key, if the first application certificate and / or the second application certificate are updated, the second key corresponding to the socket is obtained. The first application process can also use the socket to interact with the second application process to exchange application data protected by the second key.

[0160] The second key can be a renegotiated key. In one implementation, if the first application certificate is updated, the first node can send a request to the second node to re-determine the key; if the second application certificate is updated, the second node can send a request to the first node to re-determine the key.

[0161] It should be understood that the first application certificate and the second application certificate are usually not updated simultaneously. However, this application embodiment does not exclude the possibility of both application certificates being updated at the same time. That is, the application certificates that are updated include the first application certificate and / or the second application certificate.

[0162] In one implementation, the second key corresponding to the aforementioned socket can be obtained upon reaching the first time point. Here, the first time point is prior to the certificate expiration time, and the duration between the first and second time points is a first duration threshold. The certificate expiration time refers to the expiration time of the certificate before the update. That is, the new key (i.e., the second key) needs to be determined before the certificate expires, thus allowing sufficient time for key switching to complete before the certificate expires, thereby ensuring communication security. Here, the certificate before the update refers to the certificate before the update, and the first time point can be considered the time when the new key is generated.

[0163] It should be understood that application certificates are generally renewed before they expire, so that the application can continue to run legally.

[0164] The aforementioned first duration threshold can be flexibly set according to the actual situation. The first duration threshold can be one day, several hours, or other durations. This application embodiment does not impose any restrictions on the first duration threshold.

[0165] As an example, if the validity period of the application certificate is in years, the first duration threshold can be set to a larger value, such as a few days; if the validity period of the application certificate is in months or weeks, the first duration threshold can be set to a smaller value, such as a day or a few hours.

[0166] The process of obtaining the second key can be similar to that of obtaining the first key. For example, based on the updated application certificate, a secure handshake is performed between the first and second proxies to negotiate the key and obtain the second key. It is important to note that in one implementation of obtaining the first key, the first proxy can reuse the socket of the first application process. However, in the process of obtaining the second key, to avoid affecting the communication of the first application process, the first proxy does not reuse the socket of the first application process but uses other sockets (such as newly created sockets). However, in some embodiments, the socket of the first application process can still be reused for key negotiation; this application does not impose such restrictions.

[0167] In one possible implementation, the application data protected by the first key includes application data encrypted with the first key. This encrypted application data includes application data within a first time period. The first time period includes the time between the moment the first key is acquired and a second moment. The second moment occurs after the moment the second key is acquired, and the duration between the second moment and the moment the second key is acquired is a second duration threshold. That is, after acquiring the second key, it is not immediately used to encrypt application data; instead, the first key continues to be used for encryption, thus reserving time for a smooth key switching.

[0168] The aforementioned second duration threshold can be flexibly set according to actual conditions. The second duration threshold can be several hours, one day, or other possible durations. This application embodiment does not impose any restrictions on the second duration threshold.

[0169] In some embodiments, the second timeframe occurs before the certificate expiration time, which refers to the expiration date of the certificate before the update. That is, encryption continues using the first key for a period between obtaining the new key and the certificate expiration. In this implementation, the second timeframe threshold is less than the first timeframe threshold. This ensures that the first key is only used before the certificate expires and will definitely not be used after the certificate expires, thereby maximizing the security of application data. Of course, in other embodiments, the second timeframe may also occur after the certificate expiration time.

[0170] In another possible implementation, the first time period includes the time period between the moment the first key is obtained and the moment the second key is obtained. That is, after the second key is determined, the data sender immediately enables the second key for data encryption.

[0171] It should be understood that the aforementioned first time period is only used to limit the time period for encryption using the first key, and is not used to limit the time period for decryption using the first key. In this embodiment, after obtaining the second key, the second key can be enabled, i.e., used for decryption.

[0172] Therefore, in one implementation, after obtaining the second key, if encrypted first application data received using the aforementioned socket is obtained, the encrypted first application data is decrypted using the first key and / or the second key. It should be understood that the first application data is data sent from the second application process to the first application process.

[0173] In one possible implementation, decrypting the encrypted first application data using a first key and / or a second key includes: decrypting the encrypted first application data using the first key; if decryption using the first key fails, then decrypting the encrypted first application data using the second key. That is, first attempt is made to decrypt using the first key, and then attempt is made to decrypt using the second key. This design is because switching from the first key to the second key requires some time. After obtaining the second key, as described in the above embodiments, the second key has not yet been used to encrypt data. Therefore, the data receiving end can still first attempt to decrypt using the first key, which will likely succeed, thereby reducing the number of decryption operations and improving decryption efficiency.

[0174] Based on the principle of trying the first key first, then the second key, one possible implementation is that after a successful initial decryption attempt using the second key, subsequent received encrypted application data can be decrypted using the second key first, followed by the first key. In other words, a successful initial decryption attempt with the second key indicates that the other end has begun using the second key for data encryption. Therefore, subsequent application data received in the process will most likely be encrypted with the second key, resulting in a higher success rate for decryption. This reduces the number of decryption operations and improves decryption efficiency.

[0175] In another possible implementation, the encrypted first application data is decrypted using a first key and / or a second key. This includes: decrypting the encrypted first application data using the second key; and if decryption using the second key fails, then decrypting the encrypted first application data using the first key. That is, the second key is attempted to be used for decryption first, followed by an attempt to use the first key. Thus, if the data sender determines the second key and immediately enables (or briefly enables) the second key for data encryption, the data receiver's success rate in decrypting using the second key first is relatively high.

[0176] The above-mentioned implementation of trying the first key and the second key also takes into account factors such as communication network latency and network congestion. During the key switching process, both ends of the communication can try the first key and the second key to decrypt the data.

[0177] It should be understood that during the process of decrypting the encrypted first application data using the first key and / or the second key, under normal circumstances, decryption can be successful after trying the first key and the second key. Of course, it is possible that in some cases, decryption may still fail after trying the first key and the second key. For example, if the encrypted first application data transmitted in the network is damaged or modified due to some external factors, it is possible that decryption may still fail after trying the first key and the second key.

[0178] As described above, in one implementation, the kernel of the first node records the key-value pair corresponding to the socket. The key in this key-value pair is the socket's metadata, and the value includes a first key. This metadata is used to identify the first and second application processes. Based on this, after obtaining the second key (i.e., re-determining the key corresponding to the socket), the value in the key-value pair can be updated, and the updated value includes both the first and second keys. Therefore, after obtaining the encrypted first application data received using this socket, before decrypting the encrypted first application data using the first and / or second keys, the socket's metadata can be used as the target key. The kernel can then be queried for the value in the key-value pair containing the target key to obtain the first and second keys. After obtaining the first and second keys, data decryption can then be attempted using the first and / or second keys.

[0179] The method for updating the value in the key-value pair can be as follows: the first agent transmits the metadata and the second key to the kernel, and the kernel adds the second key to the value in the key-value pair.

[0180] The implementation method for the first agent to pass the metadata and the second key to the kernel can be as follows: the first agent writes the second key into the socket and passes the socket to the kernel.

[0181] As an example, in Figure 5 In the illustrated embodiment, a proxy 5013 can write a second key into the socket and transmit the socket to a multi-key manager 5023. The multi-key manager 5023 extracts the metadata, the first key, and the second key from the socket, uses the metadata as a key, queries the key-value pair containing the metadata, and after finding the key-value pair containing the metadata (at this point, the value already includes the first key), writes the second key into the value of the key-value pair containing the metadata.

[0182] In one implementation, after updating the values ​​in the aforementioned key-value pairs, upon reaching a third time point, the first key in that value is deleted. The third time point is located after the second time point, and the duration between the second and second time points is a third duration threshold. That is, upon reaching the third time point, the key switching ends, and by deleting the first key from the values ​​included in the key-value pairs corresponding to the socket, both ends of the communication subsequently use the second key for encryption and decryption.

[0183] The third duration threshold can be flexibly adjusted according to the actual situation. The third duration threshold can be several hours, tens of minutes, or a day. This application embodiment does not limit the third duration threshold.

[0184] In some embodiments, the third time is no later than the aforementioned certificate expiration time, to ensure that the key switch is completed before the certificate expires. Based on this, the sum of the third duration threshold and the second duration threshold may not exceed the first duration threshold. Of course, in other embodiments, the third time may also be located after the certificate expiration time.

[0185] Figure 7 This is a timing diagram illustrating the use of a key according to an embodiment of this application. See also... Figure 7 At time t1, the first key (denoted as S1) is determined. Encryption and decryption are performed using the first key from time t1 to t2. At time t2, due to an application certificate update, a new key is determined, resulting in a second key (denoted as S2). Encryption is still performed using the first key from time t2 to t3. However, after time t2, both the first and second keys can be used for decryption, meaning decryption can be attempted using either the first or second key from time t2 to t3. At time t3, encryption begins using the second key, but both the first and second keys can still be used for decryption. For a period after time t3, the application data exchanged between the two ends gradually becomes encrypted using the second key, thus allowing sufficient time for key switching. At time t4, the first key can be invalidated for all communication data between the two ends, and the second key is used for encryption and decryption. At time t5, the certificate before the update becomes invalid. This ensures sufficient time for key switching is allowed before the certificate expires.

[0186] exist Figure 7 In this embodiment, the first duration threshold is t5-t2; the second duration threshold is t3-t2; and the third duration threshold is t4-t3.

[0187] As described above, the communication method provided in this application embodiment ensures that application data is encrypted from the beginning of the communication link (e.g., the kernel of the first node) and decrypted only at the end of the communication link (e.g., the kernel of the second node), thus achieving end-to-end encryption. Furthermore, the key in this application embodiment is a socket-level key; that is, each socket corresponds to a key, and different sockets correspond to different keys. Compared to node-level encryption, the encryption granularity of this application embodiment is finer, achieving application process-level encryption and thus higher security.

[0188] Furthermore, the communication method provided in this application embodiment can support multi-key management, support setting multiple keys for a socket, and achieve seamless key switching of newly established links during key switching.

[0189] Next, please combine... Figures 8 to 12 The communication method provided in the embodiments of this application will be explained and illustrated again by way of example.

[0190] Figure 8 This is a flowchart of yet another communication method provided in an embodiment of this application. See also... Figure 8 The method includes the following steps.

[0191] Step 801: Application processes complete a connection handshake.

[0192] This step is performed within the user-space application. In this step, the application process creates a raw communication socket and attempts to establish a socket connection with the target object (i.e., the peer application process).

[0193] Step 802: During the three-way handshake between the two communicating parties, the owner information of the original socket is cleared without being noticed.

[0194] This step is automatically triggered during the execution flow of step 802 and is imperceptible to user-mode application processes. Typically, during an application process's call to a system function, the socket's owner information is cleared before the three-way handshake is completed, thus suspending the allocation of usage rights for that socket. Since the three-way handshake is automatically completed in the kernel, it is not affected by the owner. After the owner information is cleared, when the application process attempts to send or receive application data, it will first determine whether the current socket belongs to the application process. If it does not belong to the application process, it can delay the response or directly return the specified error code.

[0195] Step 803: The owner management module seamlessly migrates the socket to the agent and sets the owner information.

[0196] This step is completed automatically in the kernel. Through the owner management module, the socket is passed to the user-space proxy via the kernel / user-space communication mechanism, and the proxy is set as the owner. The proxy obtains the right to use the socket, waits for the three-way handshake to complete, and then can use the socket for communication operations.

[0197] Step 804: The agent completes key negotiation to generate key 1.

[0198] After the proxy obtains the right to use the socket in this step, it performs an encrypted communication handshake (i.e., a secure handshake) with the socket on the other end to negotiate the key 1 corresponding to the aforementioned socket.

[0199] Step 805: Set key 1 in the multi-key manager, and use key 1 for all sockets in the same process pair.

[0200] In this step, the agent sets key 1 into the kernel's multi-key manager via the kernel / user-space communication mechanism. The key-value pair consisting of key 1 and the socket's metadata is stored in kernel memory. The identity (i.e., metadata) of sockets under the same application process is consistent. To improve communication efficiency, subsequent new sockets will not re-negotiate the key; instead, the key already recorded in the multi-key manager will be reused.

[0201] Step 806: If the certificate of either of the communicating parties is about to expire, the agent will re-negotiate the key and obtain key 2.

[0202] In this step, a new certificate will be used to perform a secure handshake and negotiate key 2.

[0203] Step 807: Set key 2 in the multi-key manager.

[0204] In this step, the agent sets key 2 into the kernel's multi-key manager through the kernel / user space communication mechanism.

[0205] Step 808: The socket sender supports encryption using the latest key 2.

[0206] In this step, the sending end of the newly established socket between the above application processes will use the latest key 2 to encrypt the data.

[0207] Step 809: The socket receiver supports decryption using either key 1 or key 2.

[0208] In this step, after the receiving end receives the data from the socket interaction, it can simultaneously attempt to decrypt it using both keys corresponding to the socket to complete the decryption process. If the application certificate used for negotiated key 1 expires (i.e., becomes invalid), key 1 can be completely removed from the multi-key manager.

[0209] Figure 9 This is a software system architecture diagram for inter-node communication provided in an embodiment of this application. Figure 9 Node 1 and Node 2 in the data can be respectively used as Figure 4 The first node and the second node in the embodiment. In this embodiment, the software modules in node 1 and node 2 may include user-space agents, owner management modules, and multi-key managers, and may also include encryption modules in the kernel.

[0210] The primary function of the proxy is to perform a secure handshake with the peer proxy and obtain the key.

[0211] A new socket type has been added to the kernel: a socket with an owner. This type of socket supports the following features: seamless migration of the socket to other applications; only the socket's owner has permission to operate the socket, and non-owners are not allowed to operate the socket; the socket's owner can be switched under the control of the owner management module.

[0212] A new socket multi-key manager has been added to the kernel, which can achieve the following functions: support the management of one or more keys corresponding to a socket; support seamless key switching of newly established links in key switching scenarios.

[0213] The product implementation in this application embodiment can be contained in platform software in user mode and kernel mode, and deployed on node (e.g., server) hardware. Figure 5 and Figure 9 Based on the illustrated embodiments, the corresponding program code in this application embodiment can reside in the user-mode agent of the platform software and the kernel-mode socket management module (including the multi-key manager and owner management module). This program code can run in the host memory of the node.

[0214] Figure 10 This is a flowchart illustrating a seamless socket migration method provided in an embodiment of this application. Socket migration refers to migrating (or transferring) a socket to a proxy. See also... Figure 10Application process A (referred to as process A) on the sending side (e.g., the first node) initiates communication with application process B (referred to as process B) on the receiving side (e.g., the second node), performing a handshake connection. After the connection is initiated but before application data is sent, the owner manager on the sending side can obtain the socket information and seamlessly migrate the socket to process C on the sending side, which acts as a proxy on the sending side. Correspondingly, before process B receives application data, the owner manager on the receiving side seamlessly migrates the socket to process D on the receiving side, which acts as a proxy on the receiving side.

[0215] After socket migration, ownership transfer (i.e., owner switching) can be performed. In one implementation, the owner manager sets the owner of the sending socket to process C and intercepts data transmission from process A; process B sends messages normally; the owner manager sets the owner of the receiving socket to D and intercepts data reading from process C; process D receives messages normally; after processes C and D complete communication and obtain the key, they release the owner, and the owner manager resets the owner of the sending socket to process A and the owner of the receiving socket to process C, thus completing the socket usage permission transfer; the owner manager intercepts message transmission from process C; process A sends messages normally; the owner manager intercepts message reception from process D; process B receives messages normally.

[0216] Figure 11 This is a schematic diagram of another node internal hardware and software architecture provided in an embodiment of this application. Figure 11 and Figure 5 compared to, Figure 11 The owner management module includes two sub-modules: owner settings and owner migration; the multi-key manager includes two sub-modules: key storage and key settings; and the agent includes two sub-modules: certificate management and key negotiation.

[0217] Taking a server in a cloud-native scenario as an example, this node can use technologies such as the extended Berkeley packet filter (eBPF) to perform socket-related operations in the application. The owner setting submodule is used to clear the socket owner information according to the technical solution of this application embodiment. Then, the owner migration submodule uses technologies such as socket control message (SCM) and Unix socket to send the socket descriptor from kernel space to the agent in user space, thereby completing the socket migration.

[0218] The certificate management submodule obtains the application certificate and hands it over to the key negotiation submodule to conduct a secure handshake with the peer's agent using methods such as TLS communication to negotiate the key. The negotiated key is stored in the socket after key negotiation. The key negotiation submodule sends the socket to the multi-key manager via kernel / user space communication. The key storage submodule reads the key from the socket and establishes key-value pairs based on the socket's metadata. In subsequent instances where the application establishes a socket and accesses the same backend, the socket will directly index the key value using the key. After successful retrieval, a handshake is no longer required; instead, the key is directly set by the key setting submodule to improve performance.

[0219] After the key is set, the owner setting submodule will switch the owner back to the original APP, and the APP can then conduct business communication normally. Before the old certificate expires, when the new certificate arrives, the key negotiation module will actively use the new certificate to re-negotiate the key. The negotiated key is stored in the kernel's memory through the key storage submodule. For newly created sockets in the same process, the key setting submodule will temporarily use the old key, and then switch to the new key after a period of time. After the new key is determined, when application data is sent to the peer, the peer's encryption module will use multiple keys (such as key 1 and key 2) to attempt to decrypt the application data. In this way, the key switching is handled seamlessly.

[0220] Figure 12 This is a flowchart illustrating a multi-key management method provided in an embodiment of this application. See also... Figure 12Communication occurs between service A (e.g., an application process on node 1) and service B (e.g., an application process on node 2). This triggers a secure handshake between agents using the application certificates of service A and service B to negotiate and generate key 1. The agent sets key 1 in a multi-key manager, with the key being {service A's identifier, service B's identifier} and the value being {key 1}. Both local and peer sockets 'socket1' are written to key 1 and use it for encrypted communication. If service A's application certificate is about to expire, sufficient time is allowed before expiration for key switching. Agents re-establish a secure handshake with service B using service A's new certificate to obtain key 2. The agent sets key 2 in the multi-key manager, with the key being {service A's identifier and service B's identifier} and the value being {key 1, key 2}. After a delay, key 2 is used for data encryption. During the delay period, socket3 continues to use key 1 for encryption, and socket3' can simultaneously attempt to decrypt using both key 1 and key 2. After the delay ends, socket3 uses key 2 for encryption, and socket3' still supports decryption using both key 1 and key 2. After a further period, the key switching ends, the multi-key manager removes the expired key 1, and the key switching is complete. The newly created socket5 is set to use key 2 for encryption, and socket5' is set to use key 2 for decryption, completing the key switching between the two ends.

[0221] Combination Figure 8 To the end Figure 12 As can be seen from the embodiments, this application provides a socket with an owner state, which can achieve a smooth switch of owner state / control. Owner state control is used to block or allow user-mode applications to operate on the socket. Furthermore, the socket supports multi-key management, extending its encryption capabilities, supporting microservice-level socket key reuse, and allowing multiple keys to be set for the socket. In scenarios involving key reuse and key switching, it supports seamless key switching between newly established links.

[0222] In summary, in this embodiment, before the first application process uses a socket to interact with the second application process on application data, the allocation of usage rights for the socket is suspended. This prevents the first and second application processes from exchanging application data without key protection before obtaining the first key. After obtaining the first key, the usage rights for the socket are then allocated to the first application process, enabling secure communication between application processes via the first key. This solution achieves end-to-end secure communication between application processes, improving communication security. Furthermore, in this embodiment, the first key is the key corresponding to the socket, meaning this solution can achieve socket-level communication encryption. Compared to node-level encryption, this solution offers finer encryption granularity, preventing a decrease in the overall node's security level after node-level encryption is compromised, thus providing higher security.

[0223] Figure 13 This is a schematic diagram of a communication device provided in an embodiment of this application. The communication device can be implemented as part or all of a computer device by software, hardware, or a combination of both. The computer device can be... Figure 3 The computer equipment shown. See also Figure 13 The device includes a management module 1301 and a key acquisition module 1302.

[0224] The management module 1301 is used to suspend the allocation of the socket usage permission if the first application process needs to use the socket to interact with the second application process for application data. The first application process is the application process in the first node, and the second application process is the application process in the second node.

[0225] The key acquisition module 1302 is used to acquire the first key corresponding to the socket;

[0226] The management module 1301 is also used to assign the usage rights of the socket to the first application process, which uses the socket to interact with the second application process to exchange application data protected by the first key.

[0227] In one possible implementation, such as Figure 14 As shown, the key acquisition module 1302 includes:

[0228] The key negotiation submodule is used to negotiate the key with the first agent and the second agent to obtain the first key. The first agent is the agent in the first node, and the second agent is the agent in the second node.

[0229] In one possible implementation, the management module 1301 is further configured to: assign the usage rights of the socket to the first agent;

[0230] The key negotiation submodule is specifically used to: negotiate the first key with the second agent using the socket through the first agent.

[0231] In one possible implementation, the key negotiation is completed through a secure handshake between the first agent and the second agent. This secure handshake is based on a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs.

[0232] In one possible implementation, the first application process runs in user space, and the kernel of the first node records the key-value pairs corresponding to the socket. The key in the key-value pair is the metadata of the socket, and the value in the key-value pair includes a first secret. This metadata is used to identify the first application process and the second application process; for example... Figure 15 As shown, the device also includes:

[0233] The encryption / decryption module 1303 is used to encrypt and / or decrypt application data used for interaction using the socket in the kernel based on the key-value pair after the socket usage rights are allocated to the first application process.

[0234] In one possible implementation, the device further includes:

[0235] The query module is used to use the metadata of the socket as the target key to query the value in the key-value pair containing the target key in the kernel and obtain the first key;

[0236] The encryption / decryption module 1303 is specifically used in the kernel to encrypt and / or decrypt application data that is used to interact using the socket, using a first key.

[0237] In one possible implementation, the device further includes:

[0238] The recording module is used to record the key-value pair corresponding to the socket in the kernel after obtaining the first key corresponding to the socket.

[0239] In one possible implementation, the first key is determined through a first agent, which runs in user space and is the agent in the first node; the device further includes:

[0240] The delivery module is used to transmit the aforementioned metadata and the first key to the kernel through the first agent.

[0241] In one possible implementation, the first key is determined using a first application certificate and a second application certificate, wherein the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs; the device further includes:

[0242] The key update module is used to obtain the second key corresponding to the socket after obtaining the first key corresponding to the socket. If the first application certificate and / or the second application certificate are updated, the second key corresponding to the socket is obtained. The first application process is also used to use the socket to interact with the second application process to exchange application data protected by the second key.

[0243] In one possible implementation, the key update module is specifically used for:

[0244] Upon reaching the first moment, obtain the second key corresponding to the socket. The first moment is before the certificate expiration moment, and the duration between the first moment and the certificate expiration moment is the first duration threshold. The certificate expiration moment refers to the expiration moment of the certificate before the update.

[0245] In one possible implementation, the application data protected by the first key includes application data encrypted with the first key. The application data encrypted with the first key includes application data within a first time period. The first time period includes the time period between the moment when the first key is obtained and a second moment. The second moment is located after the moment when the second key is obtained, and the duration between the second moment and the moment when the second key is obtained is a second duration threshold.

[0246] In one possible implementation, the second time point is located before the certificate expiration time point, which refers to the time when the certificate expires before the update.

[0247] In one possible implementation, the device further includes:

[0248] The data acquisition module is used to acquire the first application data received using the socket and encrypted after acquiring the second key corresponding to the socket;

[0249] The encryption / decryption module 1303 is used to decrypt encrypted first application data using a first key and / or a second key.

[0250] In one possible implementation, the encryption / decryption module 1303 is specifically used for:

[0251] Use the first key to decrypt the encrypted first application data. If decryption of the encrypted first application data using the first key fails, then use the second key to decrypt the encrypted first application data; or...

[0252] Use the second key to decrypt the encrypted first application data. If decryption of the encrypted first application data using the second key fails, then use the first key to decrypt the encrypted first application data.

[0253] In one possible implementation, the kernel of the first node records key-value pairs corresponding to the socket, where the key in the key-value pair is the metadata of the socket, and the value in the key-value pair includes a first key. This metadata is used to identify the first application process and the second application process. The device further includes:

[0254] The recording module is used to update the value in the key-value pair after obtaining the second key corresponding to the socket. The updated value includes the first key and the second key.

[0255] The query module is used to use the socket's metadata as the target key to query the value in the key-value pair containing the target key from the kernel, thereby obtaining the first key and the second key.

[0256] In one possible implementation, the recording module is also used for:

[0257] After updating the values ​​in the key-value pair, in the case of reaching the third time point, delete the first key in the above values. The third time point is located after the second time point, and the duration between the second time point and the third time point is the third duration threshold.

[0258] In one possible implementation, the first proxy exists within the ServiceMesh architecture.

[0259] In this embodiment, before the first application process uses a socket to interact with the second application process on application data, the allocation of usage rights for the socket is suspended. This prevents the first and second application processes from exchanging application data without key protection before obtaining the first key. After obtaining the first key, the usage rights for the socket are then allocated to the first application process, enabling secure communication between application processes via the first key. This solution achieves end-to-end secure communication between application processes, improving communication security. Furthermore, in this embodiment, the first key is the key corresponding to the socket, meaning this solution can achieve socket-level communication encryption. Compared to node-level encryption, this solution offers finer encryption granularity, preventing a decrease in the overall node's security level after node-level encryption is compromised, thus providing higher security.

[0260] It should be noted that the communication device provided in the above embodiments is only illustrated by the division of the above functional modules when performing communication between application processes. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the communication device and communication method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0261] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the communication method shown in the above-described method embodiments.

[0262] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the steps of the communication method shown in the above-described method embodiments.

[0263] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0264] It should be understood that "at least one" as mentioned herein refers to one or more, and "multiple" refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., are not necessarily different.

[0265] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0266] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A communication method, characterized in that, The method includes: If the first application process needs to use a socket to interact with the second application process for application data, then the allocation of the socket usage permission is suspended. The first application process is the application process in the first node, and the second application process is the application process in the second node. Obtain the first key corresponding to the socket; The socket usage rights are assigned to the first application process, and the first application process uses the socket to interact with the second application process to exchange application data protected by the first key.

2. The method as described in claim 1, characterized in that, Obtaining the first key corresponding to the socket includes: The first key is obtained by negotiating the key between the first agent and the second agent. The first agent is the agent in the first node, and the second agent is the agent in the second node.

3. The method as described in claim 2, characterized in that, The step of obtaining the first key through key negotiation between the first and second agents includes: Assign the usage rights of the socket to the first agent; The first agent uses the socket to negotiate a key with the second agent and obtains the first key.

4. The method as described in claim 2 or 3, characterized in that, The key negotiation is completed through a secure handshake between the first agent and the second agent. The secure handshake is based on a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs.

5. The method according to any one of claims 1-4, characterized in that, The first application process runs in user space. The kernel of the first node records the key-value pairs corresponding to the socket. The key in the key-value pair is the meta-information of the socket, and the value in the key-value pair includes the first key. The meta-information is used to identify the first application process and the second application process. After allocating the socket usage rights to the first application process, the method further includes: Using the socket's metadata as the target key, the value of the key-value pair containing the target key is queried from the kernel to obtain the first key; The first key is used in the kernel to encrypt and / or decrypt application data that is interacted using the socket.

6. The method as described in claim 5, characterized in that, The method further includes: The key-value pairs corresponding to the socket are recorded in the kernel.

7. The method as described in claim 6, characterized in that, The first key is determined through the first agent, which runs in user space and is the agent in the first node; Before recording the key-value pair corresponding to the socket in the kernel, the method further includes: The first agent transmits the metadata and the first key to the kernel.

8. The method according to any one of claims 1-7, characterized in that, The first key is determined using a first application certificate and a second application certificate, wherein the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs; After obtaining the first key corresponding to the socket, the method further includes: If the first application certificate and / or the second application certificate are updated, the second key corresponding to the socket is obtained, and the first application process uses the socket to interact with the second application process to exchange application data protected by the second key.

9. The method as described in claim 8, characterized in that, Obtaining the second key corresponding to the socket includes: Upon reaching the first moment, the second key corresponding to the socket is obtained. The first moment is before the certificate expiration moment, and the duration between the first moment and the certificate expiration moment is a first duration threshold. The certificate expiration moment refers to the expiration moment of the certificate before the update.

10. The method as described in claim 8 or 9, characterized in that, The application data protected by the first key includes application data encrypted with the first key. The application data encrypted with the first key includes application data within a first time period. The first time period includes the time period between the moment when the first key is obtained and a second moment. The second moment is after the moment when the second key is obtained, and the duration between the second moment and the moment when the second key is obtained is a second duration threshold.

11. The method as described in claim 10, characterized in that, The second time point is located before the certificate expiration time, which refers to the expiration time of the certificate before the update.

12. The method as described in claim 10 or 11, characterized in that, After obtaining the second key corresponding to the socket, the method further includes: Obtain first application data that is received and encrypted using the socket; The encrypted first application data is decrypted using the first key and / or the second key.

13. The method as described in claim 12, characterized in that, The step of decrypting the encrypted first application data using the first key and / or the second key includes: The encrypted first application data is decrypted using the first key; if decryption of the encrypted first application data using the first key fails, the encrypted first application data is decrypted using the second key; or... The encrypted first application data is decrypted using the second key. If the decryption of the encrypted first application data using the second key fails, the encrypted first application data is decrypted using the first key.

14. The method as described in claim 12 or 13, characterized in that, The kernel of the first node records key-value pairs corresponding to the socket. The key in the key-value pair is the meta-information of the socket, and the value in the key-value pair includes the first key. The meta-information is used to identify the first application process and the second application process. After obtaining the second key corresponding to the socket, the method further includes: Update the value in the key-value pair, and the updated value includes the first key and the second key; After acquiring the encrypted first application data received using the socket, and before decrypting the encrypted first application data using the first key and / or the second key, the method further includes: Using the socket's metadata as the target key, the value in the key-value pair containing the target key is queried from the kernel to obtain the first key and the second key.

15. The method as described in claim 14, characterized in that, After updating the value in the key-value pair, the method further includes: Upon reaching the third time point, the first key in the value is deleted. The third time point is located after the second time point, and the duration between the second time point and the third time point is a third duration threshold.

16. The method according to any one of claims 2-4 or 7, characterized in that, The first agent exists within the ServiceMesh architecture.

17. A communication device, characterized in that, The device includes: The management module is used to suspend the allocation of socket usage permissions if the first application process needs to use a socket to interact with the second application process for application data. The first application process is the application process in the first node, and the second application process is the application process in the second node. The key acquisition module is used to acquire the first key corresponding to the socket; The management module is also used to assign the usage rights of the socket to the first application process, and the first application process is used to use the socket to interact with the second application process to exchange application data protected by the first key.

18. The apparatus as claimed in claim 17, characterized in that, The key acquisition module includes: The key negotiation submodule is used to negotiate the key with the second agent through the first agent to obtain the first key. The first agent is the agent in the first node, and the second agent is the agent in the second node.

19. The apparatus as claimed in claim 18, characterized in that, The management module is further configured to: assign the usage rights of the socket to the first agent; The key negotiation submodule is specifically used to: negotiate the first key with the second agent through the first agent using the socket.

20. The apparatus as claimed in claim 18 or 19, characterized in that, The key negotiation is completed through a secure handshake between the first agent and the second agent. The secure handshake is based on a first application certificate and a second application certificate. The first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs.

21. The apparatus according to any one of claims 17-20, characterized in that, The first application process runs in user space. The kernel of the first node records the key-value pairs corresponding to the socket. The key in the key-value pair is the meta-information of the socket, and the value in the key-value pair includes the first key. The meta-information is used to identify the first application process and the second application process. The device further includes: The query module is used to use the metadata of the socket as the target key to query the value in the key-value pair containing the target key from the kernel, and obtain the first key; An encryption / decryption module is used in the kernel to encrypt and / or decrypt application data that is interacted using the socket.

22. The apparatus as claimed in claim 21, characterized in that, The device further includes: A recording module is used to record the key-value pairs corresponding to the socket in the kernel.

23. The apparatus as claimed in claim 22, characterized in that, The first key is determined through a first agent, which runs in user space and is the agent in the first node; the device further includes: The transmission module is used to transmit the metadata and the first key to the kernel through the first agent.

24. The apparatus according to any one of claims 17-23, characterized in that, The first key is determined using a first application certificate and a second application certificate, wherein the first application certificate is the certificate of the application to which the first application process belongs, and the second application certificate is the certificate of the application to which the second application process belongs; The device further includes: The key update module is used to obtain the second key corresponding to the socket after obtaining the first key corresponding to the socket, if the first application certificate and / or the second application certificate are updated. The first application process is also used to use the socket to interact with the second application process to exchange application data protected by the second key.

25. The apparatus as claimed in claim 24, characterized in that, The key update module is specifically used for: Upon reaching the first moment, the second key corresponding to the socket is obtained. The first moment is before the certificate expiration moment, and the duration between the first moment and the certificate expiration moment is a first duration threshold. The certificate expiration moment refers to the expiration moment of the certificate before the update.

26. The apparatus as claimed in claim 24 or 25, characterized in that, The application data protected by the first key includes application data encrypted with the first key. The application data encrypted with the first key includes application data within a first time period. The first time period includes the time period between the moment when the first key is obtained and a second moment. The second moment is after the moment when the second key is obtained, and the duration between the second moment and the moment when the second key is obtained is a second duration threshold.

27. The apparatus as claimed in claim 26, characterized in that, The second time point is located before the certificate expiration time, which refers to the expiration time of the certificate before the update.

28. The apparatus as claimed in claim 26 or 27, characterized in that, The device further includes: The data acquisition module is used to acquire, after acquiring the second key corresponding to the socket, the first application data received using the socket and encrypted. An encryption / decryption module is used to decrypt the encrypted first application data using the first key and / or the second key.

29. The apparatus as claimed in claim 28, characterized in that, The encryption / decryption module is specifically used for: The encrypted first application data is decrypted using the first key; if decryption of the encrypted first application data using the first key fails, the encrypted first application data is decrypted using the second key; or... The encrypted first application data is decrypted using the second key. If the decryption of the encrypted first application data using the second key fails, the encrypted first application data is decrypted using the first key.

30. The apparatus as claimed in claim 28 or 29, characterized in that, The kernel of the first node records key-value pairs corresponding to the sockets, where the key in each key-value pair is the metadata of the socket, and the value in each key-value pair includes the first key. The metadata is used to identify the first application process and the second application process. The device further includes: The recording module is used to update the value in the key-value pair after obtaining the second key corresponding to the socket. The updated value includes the first key and the second key. The query module is used to use the metadata of the socket as the target key to query the value in the key-value pair containing the target key from the kernel, and obtain the first key and the second key.

31. The apparatus as claimed in claim 30, characterized in that, The recording module is also used for: After updating the value in the key-value pair, if the third time point is reached, the first key in the value is deleted, the third time point being after the second time point, and the duration between the second time point and the third time point being a third duration threshold.

32. The apparatus according to any one of claims 18-20 or 23, characterized in that, The first agent exists within the ServiceMesh architecture.

33. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-16.

34. A computer program product, characterized in that, The computer program product stores computer instructions, which, when executed by a processor, implement the method described in any one of claims 1-16.

Images