Communication system-based secure communication method and management node

Abstract

The present application discloses a communication system-based secure communication method and a management node, which can improve the security of an entire system. According to the method of the present application, a client may send a first signature request to a management node. Next, the management node may, on the basis of first metadata of the client contained in the first signature request, generate and return a first signature to the client, such that the client sends to a forwarding node a first access request containing the first metadata and the first signature. Next, the forwarding node may, on the basis of the first access request, send a second signature request to the management node. Next, the management node may, on the basis of the first metadata, the first signature, and second metadata of the forwarding node contained in the second signature request, generate and return a second signature to the forwarding node, such that the forwarding node sends to a server a second access request containing the first metadata, the second metadata, and the second signature. Then, the server may, on the basis of the foregoing information, determine whether to process the second access request.

Description

A secure communication method and management node based on communication system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 22, 2023, with application number 202311791872.X, and with the invention name “A request processing method based on a trusted signature component and a trusted signature component”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 29, 2024, with application number 202410381433.X, and with the invention name “A secure communication method and management node based on a communication system”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of communication technology, and in particular to a secure communication method and management node based on a communication system. Background Art

[0003] In a communication system, an access request initiated by a client to a server is usually forwarded through one or more forwarding nodes. Each forwarding node may add or append metadata to the access request to allow the server to determine whether to process the access request from the client.

[0004] In the communication system provided by the related art, when a client needs to access a server, it can send an access request to the forwarding node, which contains the client's metadata and the client's signature. The forwarding node can then add its metadata and the access node's signature to the access request and send the modified access request to the server. The server can then verify the authenticity of the client's metadata and the forwarding node's metadata based on these signatures. If the metadata is deemed authentic, it can further process the modified access request, for example, by rejecting the client's access request or executing it.

[0005] In the above-mentioned communication system, when a forwarding node is compromised by some attackers, they can tamper with the metadata of the client or forwarding node, causing the server to incorrectly process the client's access request. For example, the server should have rejected the client's access request, but the server executed the client's access request. This will cause a series of security communication problems and reduce the security of the entire system. Summary of the Invention

[0006] The embodiments of the present application provide a secure communication method and a management node based on a communication system, which can ensure communication security and thus improve the security of the entire system.

[0007] A first aspect of an embodiment of the present application provides a secure communication method based on a communication system. The communication system used to implement the method may include a management node, a client, a forwarding node, and a server. The method includes:

[0008] When the client needs to access the server, the client may generate a first signature request including first metadata of the client, and send the first signature request to the management node.

[0009] After receiving the first signature request, the management node can parse the first signature request to obtain the first metadata. The management node can then process the first metadata to obtain the first signature. The management node can then send the first metadata and the first signature to the client, so that the client can generate a first access request including the first metadata and the first signature, and send the first access request to the forwarding node.

[0010] After receiving the first access request, the forwarding node may generate a second signature request including the first metadata, the first signature, and the second metadata of the forwarding node based on the first access request, and send the second signature request to the management node.

[0011] After receiving the second signature request, the management node can parse the second signature request to obtain the first metadata, the first signature, and the second metadata. The management node can then process the first metadata, the first signature, and the second metadata to obtain the second signature. The management node can then send the first metadata, the second metadata, and the second signature to the forwarding node, so that the forwarding node can generate a second access request including the first metadata, the second metadata, and the second signature, and send the second access request to the server.

[0012] In this way, the server can determine whether to process the second access request based on the first metadata, the second metadata, and the second signature.

[0013] It can be seen from the above method that: since the first signature for the first metadata of the client and the second signature for the first metadata of the client and the first metadata of the forwarding node are all generated by the management node, if the forwarding node is compromised by an attacker, even if the attacker tampered with the first metadata of the client or the second metadata of the forwarding node in the second access request, the second signatures for the first metadata and the second metadata are derived from the management node and cannot be tampered with by the attacker. Therefore, after receiving the second access request, the server can also find that the tampered metadata is unreliable based on the second signature, that is, it finds that the original first metadata or second metadata has been tampered with. The server can choose not to process the client's access request, thereby ensuring communication security and improving the security of the entire system.

[0014] In one possible implementation, a management node generates a first signature based on first metadata of a client included in a first signature request, and sends the first signature to the client. The forwarding node receives a first access request sent by the client including the first metadata and the first signature, including: the management node obtains the first metadata of the client from the first signature request; the management node performs a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain indicates that the first signature was obtained by the client; the management node sends the first metadata, the first signature chain, and the first signature to the client, and the forwarding node receives the first access request sent by the client including the first metadata, the first signature chain, and the first signature. In the aforementioned implementation, after receiving the first signature request from the client, the management node may parse the first signature request to obtain the first metadata of the client, an identifier of the client's own private key, and a fifth signature. Then, the management node may obtain the client's own public key based on the identifier of the client's own private key, and perform a signature verification operation on the fifth signature using the client's own public key. If the signature verification is successful, indicating that the first signature request is authentic, the management node may first generate the first signature chain and perform a signature operation on the first metadata and the first signature chain to obtain the first signature. The first signature chain indicates that the first signature was obtained by the client. After obtaining the first signature chain and the first signature, the management node may send the first metadata, the first signature chain, and the first signature to the client, so that the client sends a first access request including the first metadata, the first signature chain, and the first signature to the forwarding node.

[0015] In one possible implementation, the forwarding node receives a first access request sent by a client that includes first metadata, a first signature chain, and a first signature, including: the forwarding node receives a first access request sent by the client that includes the first metadata, the first signature chain, the first signature, an identifier of the client's own private key, and a third signature, wherein the third signature is obtained by the client signing the first metadata, the first signature chain, and the first signature based on the client's own private key. In the aforementioned implementation, after obtaining the first metadata, the first signature chain, and the first signature, the client can perform a signature operation on the first metadata, the first signature chain, and the first signature using its own private key to obtain the third signature, and generate the first access request based on the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. In other words, the first access request can include the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. Then, the client can send the first access request to the forwarding node. It should be noted that the identifier of the client's own private key is used for the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used for the forwarding node to determine whether the first access request is credible, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature has passed the client.

[0016] In one possible implementation, the management node receiving a second signature request sent by a forwarding node based on a first access request includes: the management node receiving the second signature request sent by the forwarding node, the second signature request being sent to the management node after the forwarding node determines that the first access request is authentic, the first metadata and the first signature chain are authentic, and the first signature has passed through the client. In the aforementioned implementation, after receiving the first access request from the client, the forwarding node may parse the first access request to obtain the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. The forwarding node may then obtain the client's own public key based on the identifier of the client's own private key and verify the third signature using the client's own public key. If the verification succeeds, the first access request is authentic. The forwarding node may then verify the first signature. If the verification succeeds, the first metadata and the first signature chain are authentic. The forwarding node may then compare the identifier of the client's own private key with the first signature chain. If both contain client information, the first signature has passed through the client. After this multi-level trustworthiness verification, the forwarding node may send the second signature request to the management node.

[0017] In a possible implementation, the client's own private key and the client's own public key are generated by the client, or the client's own private key and the client's own public key are generated by the management node.

[0018] In one possible implementation, the management node generates a second signature based on the first metadata, the first signature, and the second metadata of the forwarding node included in the second signature request, and sends the second signature to the forwarding node. The forwarding node sends the second access request including the first metadata, the second metadata, and the second signature to the server. The server determines whether to process the second access request based on the first metadata, the second metadata, and the second signature, including: the management node obtains the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; after the management node determines that the first metadata is credible based on the first signature, the management node performs a signature operation on the first metadata, the second metadata, and the second signature chain to obtain a second signature, where the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; the management node sends the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node; the forwarding node sends the second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server; the server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature. In the aforementioned implementation, after receiving the second signature request from the forwarding node, the management node may parse the second signature request to obtain the first metadata, the first signature chain, the first signature, the second metadata, the identifier of the forwarding node's own private key, and the sixth signature. The management node may then obtain the forwarding node's own public key based on the identifier of the forwarding node's own private key and verify the sixth signature using the forwarding node's own public key. If the verification succeeds, the second signature request is deemed authentic. The management node may then verify the first signature. If the verification succeeds, the first metadata and the first signature chain are deemed authentic. The management node may then modify the first signature chain to a second signature chain and perform a signature operation on the first metadata, the second metadata, and the second signature chain to obtain the second signature. The second signature chain indicates that the second signature was obtained via the client and the forwarding node. After obtaining the second signature chain and the second signature, the management node may send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node, causing the forwarding node to send a second access request containing the first metadata, the second metadata, the second signature chain, and the second signature to the server.

[0019] In one possible implementation, the forwarding node sending a second access request including first metadata, second metadata, a second signature chain, and a second signature to a server includes: the forwarding node signing the first metadata, second metadata, the second signature chain, and the second signature using its own private key to obtain a fourth signature, and sending the second access request including the first metadata, the second metadata, the second signature chain, the second signature, an identifier of the forwarding node's own private key, and the fourth signature to the server. In the aforementioned implementation, after obtaining the first metadata, the second metadata, the second signature chain, and the second signature, the forwarding node may perform a signing operation on the first metadata, the second metadata, the second signature chain, and the second signature using its own private key to obtain the fourth signature, and generate the second access request based on the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature. In other words, the second access request may include the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature. The forwarding node may then send the second access request to the server. It should be noted that the identifier of the forwarding node's own private key is used for the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used for the server to determine whether the second access request is credible, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0020] In one possible implementation, the server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature, including: after the server determines that the second access request is authentic, the first metadata, the second metadata, and the second signature chain are authentic, and the second signature has passed through a forwarding node, then processes the second access request based on the first metadata and the second metadata. In the aforementioned implementation, after receiving the second access request from the forwarding node, the server may parse the second access request to obtain the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature. The server may then obtain the forwarding node's own public key based on the identifier of the forwarding node's own private key and verify the fourth signature using the forwarding node's own public key. If the verification succeeds, the second access request is authentic. The server may then verify the second signature. If the verification succeeds, the first metadata, the second metadata, and the second signature chain are authentic. The server may then compare the identifier of the forwarding node's own private key with the second signature chain. If both contain information about the forwarding node, the second signature has passed through the forwarding node. After these multiple levels of trusted proof, the server can process the second access request based on the first metadata and the second metadata.

[0021] In a possible implementation, the forwarding node's own private key and the forwarding node's own public key are generated by the forwarding node, or the forwarding node's own private key and the forwarding node's own public key are generated by the management node.

[0022] In one possible implementation, the communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in the infrastructure for providing cloud services in the cloud service system.

[0023] A second aspect of an embodiment of the present application provides a communication system, which includes a management node, a forwarding node and a server; the management node is used to receive a first signature request sent by a client; the management node is also used to generate a first signature based on the first metadata of the client contained in the first signature request, and send the first signature to the client; the forwarding node is used to receive a first access request sent by the client containing the first metadata and the first signature; the management node is also used to receive a second signature request sent by the forwarding node based on the first access request; the management node is also used to generate a second signature based on the first metadata, the first signature and the second metadata of the forwarding node contained in the second signature request, and send the second signature to the forwarding node; the forwarding node is also used to send a second access request containing the first metadata, the second metadata and the second signature to the server; the server is used to determine whether to process the second access request based on the first metadata, the second metadata and the second signature.

[0024] In one possible implementation, a management node is configured to obtain first metadata of a client from a first signature request; the management node is configured to perform a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature was obtained through the client; the management node is configured to send the first metadata, the first signature chain, and the first signature to the client; and the forwarding node is configured to receive a first access request sent by the client that includes the first metadata, the first signature chain, and the first signature.

[0025] In one possible implementation, a forwarding node is used to receive a first access request sent by a client, which includes first metadata, a first signature chain, a first signature, an identifier of the client's own private key, and a third signature. The third signature is obtained by the client signing the first metadata, the first signature chain, and the first signature based on the client's own private key. The identifier of the client's own private key is used for the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used for the forwarding node to determine whether the first access request is credible, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature has passed the client.

[0026] In one possible implementation, the management node is used to receive a second signature request sent by the forwarding node. The second signature request is for the forwarding node to determine that the first access request is credible, the first metadata and the first signature chain are credible, and the first signature is sent to the management node after passing through the client.

[0027] In a possible implementation, the client's own private key and the client's own public key are generated by the client, or the client's own private key and the client's own public key are generated by the management node.

[0028] In one possible implementation, the management node is configured to obtain the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; the management node is configured to, after determining that the first metadata is credible based on the first signature, perform a signature operation on the first metadata, the second metadata, and the second signature chain to obtain a second signature, where the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; the management node is configured to send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node; the forwarding node is configured to send the second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server; and the server is configured to determine whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature.

[0029] In one possible implementation, a forwarding node is used to sign the first metadata, the second metadata, the second signature chain, and the second signature based on the forwarding node's own private key to obtain a fourth signature, and send a second access request containing the first metadata, the second metadata, the second signature chain, the second signature, an identifier of the forwarding node's own private key, and the fourth signature to a server; wherein, the identifier of the forwarding node's own private key is used for the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used for the server to determine whether the second access request is credible, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0030] In one possible implementation, the server is configured to process the second access request based on the first metadata and the second metadata after determining that the second access request is credible, the first metadata, the second metadata, and the second signature chain are credible, and the second signature passes through the forwarding node.

[0031] In a possible implementation, the forwarding node's own private key and the forwarding node's own public key are generated by the forwarding node, or the forwarding node's own private key and the forwarding node's own public key are generated by the management node.

[0032] In one possible implementation, the communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in the infrastructure for providing cloud services in the cloud service system.

[0033] A third aspect of an embodiment of the present application provides a management node, which is arranged in a communication system. The communication system also includes a client, a forwarding node and a server. The management node includes: a first receiving module for receiving a first signature request sent by the client; a first processing module for generating a first signature based on the first metadata of the client contained in the first signature request, and sending the first signature to the client, so that the client sends a first access request containing the first metadata and the first signature to the forwarding node; a second receiving module for receiving a second signature request sent by the forwarding node based on the first access request; a second processing module for generating a second signature based on the first metadata, the first signature and the second metadata of the forwarding node contained in the second signature request, and sending the second signature to the forwarding node, so that the forwarding node sends a second access request containing the first metadata, the second metadata and the second signature to the server, so that the server determines whether to process the second access request based on the first metadata, the second metadata and the second signature.

[0034] In one possible implementation, a first processing module is configured to: obtain first metadata of the client from a first signature request; perform a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature was obtained through the client; and send the first metadata, the first signature chain, and the first signature to the client, so that the client sends a first access request including the first metadata, the first signature chain, and the first signature to a forwarding node.

[0035] In one possible implementation, the first processing module is used to: enable the client to sign the first metadata, the first signature chain and the first signature based on the client's own private key to obtain a third signature, and send a first access request containing the first metadata, the first signature chain, the first signature, the identifier of the client's own private key and the third signature to a forwarding node; wherein the identifier of the client's own private key is used for the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used for the forwarding node to determine whether the first access request is credible, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature has passed the client.

[0036] In one possible implementation, the second receiving module is used to receive a second signature request sent by the forwarding node. The second signature request is for the forwarding node to determine that the first access request is credible, the first metadata and the first signature chain are credible, and the first signature is sent to the management node after passing through the client.

[0037] In a possible implementation, the client's own private key and the client's own public key are generated by the client, or the client's own private key and the client's own public key are generated by the management node.

[0038] In one possible implementation, the second processing module is configured to: obtain the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; after determining that the first metadata is credible based on the first signature, perform a signature operation on the first metadata, the second metadata, and the second signature chain to obtain a second signature, where the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; and send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node, so that the forwarding node sends the second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server, so that the server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature.

[0039] In one possible implementation, the second processing module is used to: instruct the forwarding node to sign the first metadata, the second metadata, the second signature chain, and the second signature based on the forwarding node's own private key to obtain a fourth signature, and send a second access request containing the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature to the server; wherein, the identifier of the forwarding node's own private key is used for the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used for the server to determine whether the second access request is credible, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0040] In one possible implementation, the second processing module is used to enable the server to process the second access request based on the first metadata and the second metadata after determining that the second access request is credible, the first metadata, the second metadata and the second signature chain are credible, and the second signature passes through the forwarding node.

[0041] In a possible implementation, the forwarding node's own private key and the forwarding node's own public key are generated by the forwarding node, or the forwarding node's own private key and the forwarding node's own public key are generated by the management node.

[0042] In one possible implementation, the communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in the infrastructure for providing cloud services in the cloud service system.

[0043] A fourth aspect of an embodiment of the present application provides a computing device cluster, which includes a management node, a forwarding node and a server; the management node includes a first processor and a first memory, the first memory is used to store a first instruction, and the first processor is used to enable the management node to execute the steps performed by the management node in the method described in the first aspect or any possible implementation method of the first aspect according to the first instruction; the forwarding node includes a second processor and a second memory, the second memory is used to store a second instruction, and the second processor is used to enable the forwarding node to execute the steps performed by the forwarding node in the method described in the first aspect or any possible implementation method of the first aspect according to the second instruction; the server includes a third processor and a third memory, the third memory is used to store a third instruction, and the third processor is used to enable the server to execute the steps performed by the server in the method described in the first aspect or any possible implementation method of the first aspect according to the third instruction.

[0044] A fifth aspect of an embodiment of the present application provides a computer storage medium, which stores one or more instructions. When the instructions are executed by one or more computers, the one or more computers implement the method described in the first aspect or any possible implementation method of the first aspect.

[0045] A sixth aspect of the embodiments of the present application provides a computer program product, which stores instructions. When the instructions are executed by a computer, the computer implements the method described in the first aspect or any possible implementation method of the first aspect.

[0046] In an embodiment of the present application, when a client needs to access a server, the client may send a first signature request to the management node. Then, the management node may generate a first signature based on the first metadata of the client contained in the first signature request, and return the first signature to the client, so that the client sends the first access request containing the first metadata and the first signature to the forwarding node. Then, the forwarding node may send a second signature request to the management node based on the first access request. Subsequently, the management node may generate a second signature based on the first metadata, the first signature and the second metadata of the forwarding node contained in the second signature request, and return the second signature to the forwarding node, so that the forwarding node sends the second access request containing the first metadata, the second metadata and the second signature to the server. Then, the server may determine whether to process the second access request based on the first metadata, the second metadata and the second signature. In the above process, since the first signature for the first metadata of the client and the second signature for the first metadata of the client and the first metadata of the forwarding node are all generated by the management node, if the forwarding node is hacked by an attacker, even if the attacker tampered with the first metadata of the client or the second metadata of the forwarding node in the second access request, the second signature for the first metadata and the second metadata comes from the management node and cannot be tampered with by the attacker. Therefore, after receiving the second access request, the server can also find that the tampered metadata is unreliable based on the second signature, that is, it finds that the original first metadata or second metadata has been tampered with. The server can choose not to process the client's access request, thereby ensuring communication security and improving the security of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG1 is a schematic structural diagram of a communication system provided in an embodiment of the present application;

[0048] FIG2 is a schematic diagram of the structure of a cloud service system provided in an embodiment of the present application;

[0049] FIG3 is a schematic diagram of a secure communication method based on a communication system provided in an embodiment of the present application;

[0050] FIG4 is another schematic diagram of the structure of the communication system provided in an embodiment of the present application;

[0051] FIG5 is another schematic diagram of the structure of the communication system provided in an embodiment of the present application;

[0052] FIG6 is another schematic diagram of the structure of the communication system provided in an embodiment of the present application;

[0053] FIG7 is another schematic structural diagram of a communication system provided in an embodiment of the present application;

[0054] FIG8 is a schematic diagram of the structure of a management node provided in an embodiment of the present application;

[0055] FIG9 is a schematic diagram of a structure of a computing device provided in an embodiment of the present application;

[0056] FIG10 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0057] FIG11 is a schematic diagram of computer devices in a computer cluster provided by an embodiment of the present application being connected via a network. DETAILED DESCRIPTION

[0058] The embodiments of the present application provide a secure communication method and a management node based on a communication system, which can ensure communication security and thus improve the security of the entire system.

[0059] The terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequential order. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, and this is merely a way of distinguishing the objects of the same attributes when describing them in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that the process, method, system, product or equipment comprising a series of units need not be limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or equipment.

[0060] In a communication system, an access request initiated by a client to a server is usually forwarded through one or more forwarding nodes. Each forwarding node may add or append metadata to the access request to allow the server to determine whether to process the access request from the client.

[0061] In the communication system provided by the related art, when a client needs to access a server, the client can send an access request directed to the server to the forwarding node. The access request contains the client's metadata and the client's signature. The forwarding node can then add the forwarding node's metadata and the access node's signature to the access request and send the modified access request to the server. The server can then verify whether the client's metadata and the forwarding node's metadata are credible based on these signatures. If the metadata is determined to be credible, the modified access request can be further processed. For example, if the client is determined to be unauthorized based on the client's metadata, the server will refuse to process the client's access request. For another example, if the client is determined to be authorized based on the client's metadata, the server can execute the client's access request, and so on.

[0062] In the above-mentioned communication system, when a forwarding node is compromised by some attackers, they may tamper with the metadata of the client or the forwarding node, causing the server to incorrectly process the client's access request. For example, the server should have rejected the client's access request, but the attacker modified the metadata of the unauthorized client to the metadata of the authorized client, causing the server to incorrectly execute the client's access request. This will lead to a series of security communication problems and reduce the security of the entire system.

[0063] Furthermore, when the forwarding node is compromised by certain attackers, they may delete the metadata of the forwarding node, thereby denying the existence of the forwarding node. For example, the server only processes access requests from clients that directly access the server, and does not refuse to process access requests from clients that pass through the forwarding node. The attacker may delete the metadata of the forwarding node at the forwarding node, causing the server to mistakenly believe that the client that has passed through the forwarding node is a client that has not passed through the forwarding node, thereby erroneously executing the client's access request. This will also lead to a series of security communication problems, causing the security of the entire system to further decline.

[0064] To solve the above problems, an embodiment of the present application provides a secure communication method based on a communication system, as shown in Figure 1 (Figure 1 is a structural diagram of a communication system provided in an embodiment of the present application). The security system used by this method may include a management node, a client (also referred to as a client node), a forwarding node, and a server (also referred to as a server node). The following describes each component of the communication system separately:

[0065] The management node may include a trusted signing component (TSC), so the management node has a digital signature function. Due to the data signature function, the management node can complete the signature for metadata on behalf of the client and the forwarding node. For example, when the client needs to access the server, the client can request the management node to enable the management node to generate the signature of these metadata and the signature chain for the signature based on the client's metadata (used to identify that the signature has passed the client), and provide the signature of these metadata and the signature chain for the signature to the client, so that the client can generate an access request, which carries the client's metadata, the signature of these metadata and the signature chain, and use the access request to access the forwarding node. For another example, after receiving the access request, the forwarding node may also request the management node to enable the management node to generate the signature of the metadata and the signature chain for the signature based on the client's metadata and the forwarding node's metadata (used to identify that the signature has passed through the client and the forwarding node), and return the signature of the metadata and the signature chain for the signature to the forwarding node, thereby enabling the forwarding node to convert the access request into a new access request. The new access request includes the client's metadata, the forwarding node's metadata, the signature of the metadata and the signature chain for the signature, and sends the new access request to the server. Therefore, the server can determine whether to process the new access request based on the metadata carried by the new access request, the signature of the metadata and the signature chain for the signature.

[0066] A client can be understood as a user's client, which typically needs to access a server and can therefore initiate an access request to the server through a forwarding node. It should be noted that when a client needs to access a server, it can send a signed request containing its own metadata to the management node, requesting the management node to assist in signing the client's metadata, and the client itself no longer needs to perform the signing operation. Furthermore, when the client sends a signed request to the management node and an access request to the forwarding node, it can generate a signature for the signed request and a signature for the access request, ensuring that the management node and the forwarding node are credible.

[0067] A forwarding node, also known as a proxy node, can forward access requests from clients to the server to enable communication between the client and the server. It should be noted that when a forwarding node receives an access request from a client, it can first parse the access request to obtain the client's metadata, the signature of these metadata, the signature chain for the signature, and the signature of the access request. After the forwarding node determines that the access request is credible based on the signature of the access request, the client's metadata and the signature chain for the signature are credible based on the signature of these metadata, and the signature chain for the signature is credible based on the signature of the signature, the forwarding node can initiate a signature request to the management node to request the management node to assist in signing the client's metadata and the forwarding node's metadata, and the forwarding node itself no longer needs to perform the signing operation. Furthermore, when the forwarding node sends a signature request to the management node and sends a new access request to the server, it can generate a signature for the signature request and a signature for the new access request to ensure that the management node is credible and that the server is credible.

[0068] The server can be understood as another user's server, which can provide certain data processing services to the client. Therefore, it can receive the client's access request and further determine whether to process the client's access request. It should be noted that when the server receives a new access request from the forwarding node, it can first parse the new access request to obtain the client's metadata, the forwarding node's metadata, the signature of these metadata, the signature chain for the signature, and the signature of the new access request. The server determines that the new access request is credible based on the signature of the new access request, the client's metadata, the forwarding node's metadata, and the signature chain for the signature are credible based on the signature of these metadata, and after determining that the signature of these metadata has passed through the client and the forwarding node based on the signature chain for the signature, the server can process the new access request, for example, reject the new access request or execute the new access request.

[0069] Furthermore, the above-mentioned communication system can be applied in a variety of scenarios. For example, as shown in Figure 2 (Figure 2 is a structural diagram of the cloud service system provided in an embodiment of the present application), the communication system can be a cloud service system in a cloud scenario. Accordingly, the management node can be a cloud management platform in the cloud service system, the forwarding node can be a cloud instance in the cloud service system for providing network forwarding services (for example, a gateway instance, etc.), and the server can be a cloud instance in the cloud service system for providing data processing services (for example, a tenant's business instance, etc.).

[0070] Furthermore, when the above-mentioned communication system is a cloud service system, the forwarding node and the server can be cloud instances in the cloud service system. These cloud instances can be presented in a variety of ways. For example, the cloud instance can be a physical server selected by the cloud management platform. For example, the cloud instance can be a bare metal server selected by the cloud management platform. For example, the cloud instance can be a virtual machine (VM) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a container (docker) created by the cloud management platform on the physical server through virtualization technology. For example, the cloud instance can also be a micro virtual machine (microVM) created by the cloud management platform on the physical server through virtualization technology, and so on.

[0071] Furthermore, these cloud instances can be deployed in the same site or different sites. The site can be presented in various forms. For example, the site can be a region in the infrastructure, or an availability zone in the infrastructure, or a data center (DC) in the infrastructure, or a room in the infrastructure, or a cabinet in the infrastructure, etc.

[0072] Based on the above communication system, it can be seen that when a client needs to access a server, the client can provide its metadata to the management node, so that the management node generates a signature for the metadata and provides the signature to the client. Therefore, the client can send an access request carrying the client's metadata and the signature of the metadata to the forwarding node. Then, the forwarding node can also provide the client's metadata and its own metadata to the management node, so that the management node generates a signature for the metadata and provides the signature to the forwarding node. Therefore, the forwarding node can send an access request carrying the client's metadata, the forwarding node's metadata, and the signature of the metadata to the server, so that the server determines whether to process the access request based on the metadata and the signature of the metadata. Since the signature of the client's metadata, the signature of the client's metadata, and the signature of the forwarding node's metadata are all generated by the management node, if the forwarding node is compromised by an attacker, even if the attacker tampered with the client's metadata or the forwarding node's metadata in the access request, the signature of the metadata comes from the management node and cannot be tampered by the attacker. Therefore, after receiving the access request, the server can also find that the metadata is untrustworthy based on the signature of the metadata, that is, the metadata has been tampered with, and choose not to process the client's access request, thereby ensuring communication security and improving the security of the entire system. To further understand this process, the following further describes the process in conjunction with FIG3 . FIG3 is a schematic diagram of a secure communication method based on a communication system provided in an embodiment of the present application. As shown in FIG3 , the method can be implemented by the communication system shown in FIG1 . The communication system can include a management node, a client, a forwarding node, and a server. The method includes:

[0073] 301. The management node receives a first signature request sent by a client.

[0074] In this embodiment, when the client needs to access the server, the client may generate a first signature request and send the first signature request to the management node, wherein the first signature request may include first metadata of the client.

[0075] Specifically, the client can generate the first signature request in the following manner:

[0076] The client can use its own private key to sign the first metadata to obtain the fifth signature (i.e., the signature for the first signature request), and generate the first signature request based on the first metadata, the identifier of the client's own private key, and the fifth signature. In other words, the first signature request includes the first metadata, the identifier of the client's own private key, and the fifth signature. The client can then send the first signature request to the management node.

[0077] For example, as shown in FIG4 (FIG4 is another structural diagram of the communication system provided by an embodiment of the present application), when a client client needs to access a webapp on a server, the client can send a signature request signrequest to the TSC in the management node. The signrequest includes the client's metadata UA=foo (which can also be understood as the client's identifier), the client's private key identifier clientkey=client, and the signature requestsign:valid-request-sign for the signrequest. The requestsign:valid-request-sign is obtained by the client using the client's private key to sign UA=foo.

[0078] 302. The management node generates a first signature based on the first metadata of the client included in the first signature request, and sends the first metadata and the first signature to the client, so that the client sends a first access request including the first metadata and the first signature to the forwarding node.

[0079] After receiving the first signed request, the management node can parse the first signed request to obtain the first metadata. The management node can then process the first metadata to obtain the first signature. The management node can then send the first metadata and the first signature to the client, allowing the client to generate a first access request and send the first access request to the forwarding node. The first access request can include the first metadata and the first signature.

[0080] Specifically, the management node can generate the first signature in the following manner:

[0081] After receiving the first signature request from the client, the management node can parse the first signature request to obtain the client's first metadata, the client's own private key identifier, and the fifth signature. Then, the management node can obtain the client's own public key based on the client's own private key identifier, and use the client's own public key to verify the fifth signature (for example, use the client's own public key to sign the first metadata and compare the obtained signature with the fifth signature). If the verification is successful (for example, the obtained signature is equal to the fifth signature), it means that the first signature request is credible, so the management node can first generate a first signature chain and perform a signature operation on the first metadata and the first signature chain (the private key used for the signature operation can be the management node's own private key or a private key generated by the management node in real time and exclusive to the client, which is not limited here), thereby obtaining the first signature (i.e., the signature for the first metadata and the first signature chain). The first signature chain is used to indicate that the first signature was obtained through the client.

[0082] After obtaining the first signature chain and the first signature, the management node may send the first metadata, the first signature chain, and the first signature to the client.

[0083] Still as in the above example, after TSC receives signrequest from the client, TSC can first obtain the client's public key based on clientkey=client, and then use the client's public key to verify requestsign:valid-request-sign. After the verification passes, TSC can determine that signrequest is authentic, so TSC can extract UA=foo from signrequest.

[0084] The TSC then generates a signature chain, signedvia=client, and uses its own private key, generated in real time and specific to the client, to sign UA=foo and signedvia=client, resulting in a signature, signature=valid-metadata-sign, for UA=foo and signedvia=client. The TSC then returns a signed response, signresponse:UA=foo, signedvia=client, signature=valid-metadata-sign, to the client.

[0085] More specifically, the client may generate the first access request in the following manner:

[0086] After obtaining the first metadata, the first signature chain, and the first signature, the client can perform a signature operation on the first metadata, the first signature chain, and the first signature using its own private key to obtain a third signature (i.e., a signature for the first access request). The client then generates a first access request based on the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. In other words, the first access request can include the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. The client can then send the first access request to the forwarding node.

[0087] It should be noted that the identifier of the client's own private key is used for the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used for the forwarding node to determine whether the first access request is credible, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature has passed the client.

[0088] Continuing with the example above, after obtaining signresponse:UA=foo,signedvia=client,signature=valid-metadata-sign, the client uses its private key to sign UA=foo,signedvia=client,signature=valid-metadata-sign, resulting in the signature requestsign:valid-client-sign for the access request. The client can then include UA=foo,signedvia=client,signature=valid-metadata-sign,key=client (the identifier of the client's private key), and valid-client-sign in the access request.

[0089] Then, the client can send the access request to the proxy node proxy1.

[0090] More specifically, the client's own public and private keys come from a variety of sources:

[0091] (1) The client's own private key and the client's own public key can be generated by the client. For example, as shown in FIG4 , the client's public-private key pair, namely key=client, is generated by the client itself and is used to generate the signature of the signature request directed to TSC and the signature of the access request directed to proxy1. (2) The client's own private key and the client's own public key can also be generated by the management node. For example, as shown in FIG5 ( FIG5 is another structural diagram of the communication system provided in an embodiment of the present application), the client's public-private key pair includes two pairs, one of which is key=client, which is used to generate the signature of the signature request directed to TSC, and the other is key=temp1, which is used to generate the signature of the access request directed to proxy1. This pair of public-private keys is provided by TSC and can be sent to the client when TSC returns a signature response to the client.

[0092] 303. The management node receives a second signature request sent by the forwarding node based on the first access request.

[0093] After receiving the first access request, the forwarding node may generate a second signature request based on the first access request and send the second signature request to the management node, wherein the second signature request includes the first metadata, the first signature, and the second metadata of the forwarding node.

[0094] Specifically, the forwarding node may generate the second signature request in the following manner:

[0095] After receiving the first access request from the client, the forwarding node may parse the first access request to obtain the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the third signature. Then, the forwarding node may obtain the client's own public key based on the identifier of the client's own private key, and use the client's own public key to perform a signature verification operation on the third signature (for example, using the client's own public key to perform a signature operation on the first metadata, the first signature chain, and the first signature, and comparing the obtained signature with the third signature). If the signature verification succeeds (for example, the obtained signature is equal to the third signature), it indicates that the first access request is authentic. Next, the forwarding node may perform a signature verification operation on the first signature (for example, performing a signature operation on the first metadata and comparing the obtained signature with the first signature. The public key used for the signature operation can be either the management node's own public key or a public key generated by the management node in real time and specific to the client, which is not limited here). If the signature verification succeeds (for example, the obtained signature is equal to the first signature), it indicates that the first metadata and the first signature chain are authentic. The forwarding node can then compare the client's own private key identifier (which can be used to represent the client itself) with the first signature chain. If both contain the client's information, it means that the first signature has passed through the client. After this multi-level trustworthy proof, the forwarding node can use its own private key to sign the first metadata, the first signature chain, the first signature, and the forwarding node's second metadata, thereby obtaining the sixth signature (i.e., the signature for the second signature request).

[0096] The forwarding node can then generate a second signature request based on the first metadata, the first signature chain, the first signature, the second metadata, the identifier of the forwarding node's own private key, and the sixth signature. In other words, the second signature request includes the first metadata, the first signature chain, the first signature, the second metadata, the identifier of the forwarding node's own private key, and the sixth signature. The forwarding node can then send the second signature request to the management node.

[0097] Continuing with the example above, after receiving an access request from the client, proxy1 first obtains the client's public key based on key=client and then verifies valid-client-sign with the client's public key. If the verification succeeds, proxy1 determines that the access request is authentic. Next, proxy1 verifies signature=valid-metadata-sign with the client's public key, generated in real time by the TSC. If the verification succeeds, proxy1 confirms that UA=foo and signedvia=client are authentic. Proxy1 then compares key=client and signedvia=client. Since both contain client, proxy1 confirms that signature=valid-metadata-sign passed through the client. Proxy1 then uses its private key to sign UA=foo, signedvia=client, signature=valid-metadata-sign, and proxy1's metadata VIA-VPC-VPC1, resulting in the signature requestsign:valid-request-sign1 for the signature request signrequest. Then, proxy1 can make the signrequest include UA=foo, signedvia=client, signature=valid-metadata-sign, VIA-VPC-VPC1, clientkey=proxy1 (the identifier of proxy1's private key) and signature=valid-request-sign1.

[0098] Then, proxy1 can send the signrequest to TSC.

[0099] 304. The management node generates a second signature based on the first metadata, the first signature, and the second metadata of the forwarding node contained in the second signature request, and sends the first metadata, the second metadata, and the second signature to the forwarding node, so that the forwarding node sends the second access request containing the first metadata, the second metadata, and the second signature to the server, so that the server determines whether to process the second access request based on the first metadata, the second metadata, and the second signature.

[0100] After receiving the second signature request, the management node can parse the second signature request to obtain the first metadata, the first signature, and the second metadata. The management node can then process the first metadata, the first signature, and the second metadata to obtain the second signature. The management node can then send the first metadata, the second metadata, and the second signature to the forwarding node, so that the forwarding node can generate a second access request and send the second access request to the server. The second access request can include the first metadata, the second metadata, and the second signature. In this way, the server can determine whether to process the second access request based on the first metadata, the second metadata, and the second signature.

[0101] Specifically, the management node can generate the second signature in the following manner:

[0102] After receiving the second signature request from the forwarding node, the management node can parse the second signature request to obtain the first metadata, the first signature chain, the first signature, the second metadata, the identifier of the forwarding node's own private key, and the sixth signature. Then, the management node can obtain the forwarding node's own public key based on the identifier of the forwarding node's own private key, and use the forwarding node's own public key to verify the sixth signature (for example, using the forwarding node's own public key to sign the first metadata, the first signature chain, the first signature, and the second metadata, and comparing the obtained signature with the sixth signature). If the verification is successful (for example, the obtained signature is equal to the sixth signature), it indicates that the second signature request is authentic. Next, the management node can verify the first signature (this process is not further described). If the verification is successful, it indicates that the first metadata and the first signature chain are credible. The management node can then modify the first signature chain into a second signature chain and perform a signature operation on the first metadata, the second metadata, and the second signature chain (the private key used in this signature operation can be either the management node's own private key or a private key generated in real time by the management node and dedicated to the forwarding node, without limitation here), thereby obtaining the second signature (i.e., the signature for the first metadata, the second metadata, and the second signature chain). The second signature chain is used to indicate that the second signature was obtained through the client and the forwarding node.

[0103] After obtaining the second signature chain and the second signature, the management node may send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node.

[0104] Continuing with the example above, after receiving the signrequest from proxy1, the TSC first obtains proxy1's public key based on clientkey=proxy1. It then uses proxy1's public key to verify requestsign:valid-request-sign1. Once the verification passes, the TSC determines that signrequest is authentic. The TSC then verifies valid-metadata-sign. Once the verification passes, the TSC determines that UA=foo and signedvia=client are authentic. Therefore, the TSC extracts UA=foo,VIA-VPC-VPC1, and signedvia=client from signrequest. The TSC then expands signedvia=client to signedvia=client,proxy1.

[0105] The TSC then uses its own private key, generated in real time and dedicated to proxy1, to sign the pair UA=foo,VIA-VPC-VPC1,signedvia=client,proxy1, thereby obtaining the signature signature=valid-metadata-sign1 for UA=foo,VIA-VPC-VPC1 and signedvia=client. The TSC then returns a signed response to the client: signresponse:UA=foo,VIA-VPC-VPC1,signedvia=client,proxy1,signature=valid-metadata-sign1.

[0106] More specifically, the forwarding node may generate the second access request in the following manner:

[0107] After obtaining the first metadata, second metadata, second signature chain, and second signature, the forwarding node can perform a signature operation on the first metadata, second metadata, second signature chain, and second signature using its own private key to obtain a fourth signature (i.e., a signature for the second access request). The forwarding node then generates a second access request based on the first metadata, second metadata, second signature chain, second signature, the identifier of the forwarding node's own private key, and the fourth signature. In other words, the second access request can include the first metadata, second metadata, second signature chain, second signature, the identifier of the forwarding node's own private key, and the fourth signature. The forwarding node can then send the second access request to the server.

[0108] It should be noted that the identifier of the forwarding node's own private key is used for the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used for the server to determine whether the second access request is credible, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0109] As in the previous example, after obtaining signresponse:UA=foo,VIA-VPC-VPC1,signedvia=client,proxy1,signature=valid-metadata-sign1, proxy1 uses its private key to sign UA=foo,VIA-VPC-VPC1,signedvia=client,proxy1,signature=valid-metadata-sign1, thereby obtaining the signature requestsign:valid-proxy-sign1 for the access request. Then, proxy1 can make the access request include UA=foo,VIA-VPC-VPC1,signedvia=client,proxy1,signature=valid-metadata-sign1,key=proxy1 (the identifier of proxy1's private key) and valid-proxy-sign1.

[0110] Then, proxy1 can send the access request to the server.

[0111] More specifically, the forwarding node's own public and private keys come from a variety of sources:

[0112] (1) The forwarding node's own private key and public key can be generated by the forwarding node. For example, as shown in Figure 4, the public-private key pair of proxy1, key=proxy1, is generated by proxy1 itself and is used to generate the signature of the signature request directed to the TSC and the signature of the access request directed to the server. (2) The private key of the forwarding node and the public key of the forwarding node can also be generated by the management node. For example, as shown in Figure 5, the public-private key pair of proxy1 includes two pairs, one of which is key=proxy1, which is used to generate the signature of the signature request directed to the TSC, and the other is key=temp2, which is used to generate the signature of the access request directed to the server. This pair of public-private keys is provided by the TSC and can be sent to proxy1 when the TSC returns a signed response to proxy1.

[0113] More specifically, the server may determine whether to process the second access request in the following manner:

[0114] After receiving the second access request from the forwarding node, the server may parse the second access request to obtain the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature. The server may then obtain the forwarding node's own public key based on the identifier of the forwarding node's own private key and perform a signature verification operation on the fourth signature using the forwarding node's own public key (e.g., performing a signature operation on the first metadata, the second metadata, the second signature chain, and the second signature using the forwarding node's own public key, and comparing the resulting signature with the fourth signature). If the signature verification succeeds (e.g., the resulting signature is equal to the fourth signature), the second access request is deemed authentic. The server may then perform a signature verification operation on the second signature (e.g., performing a signature operation on the first metadata, the second metadata, and the second signature chain, and comparing the resulting signature with the second signature. The public key used in the signature operation can be either the management node's own public key or a public key generated by the management node in real time and specific to the forwarding node, without limitation). If the signature verification succeeds (e.g., the resulting signature is equal to the second signature), the first metadata, the second metadata, and the second signature chain are deemed authentic. The server can then compare the forwarding node's own private key identifier (which can be used to represent the forwarding node itself) with the second signature chain. If both contain forwarding node information, it means that the second signature has passed through the forwarding node. After this multi-level trusted proof, the server can process the second access request based on the first metadata and the second metadata. For example, if the server determines that the client is an authorized client based on the first metadata and the second metadata, the server will execute the second access request. For another example, if the server determines that the client accesses the server through the forwarding node based on the first metadata and the second metadata, the server will reject the second access request (assuming that the server only allows direct access by the client), and so on.

[0115] Still like the above example, after receiving the access request from proxy1, the server can first obtain the public key of proxy1 based on key=proxy1, and then use the public key of proxy1 to verify valid-proxy-sign1. After the verification is passed, the server can determine that the access request is credible. Next, the server can use the public key generated by TSC in real time that is exclusive to the server to verify signature=valid-metadata-sign1. After the verification is passed, the server can determine that UA=foo,VIA-VPC-VPC1 and signedvia=client,proxy1 are credible. Then, the server can compare key=proxy1 and signedvia=client,proxy1. Since both contain proxy1, the server can determine that signature=valid-metadata-sign1 has passed proxy1. Then, the server can process the access request based on UA=foo and VIA-VPC-VPC1.

[0116] It should be understood that this embodiment uses only one forwarding node for illustrative purposes and does not limit the number of forwarding nodes between the client and server. In actual applications, the client's access request may also pass through multiple forwarding nodes. During the forwarding process of the access request, the operations performed by each forwarding node can be referenced to those performed by the forwarding node in this embodiment and will not be further described here. It should be noted that in the case of multiple forwarding nodes, each additional forwarding node through which the access request passes includes metadata for an additional forwarding node, which will not be further explained here.

[0117] In an embodiment of the present application, when a client needs to access a server, the client may send a first signature request to the management node. Then, the management node may generate a first signature based on the first metadata of the client contained in the first signature request, and return the first signature to the client, so that the client sends the first access request containing the first metadata and the first signature to the forwarding node. Then, the forwarding node may send a second signature request to the management node based on the first access request. Subsequently, the management node may generate a second signature based on the first metadata, the first signature and the second metadata of the forwarding node contained in the second signature request, and return the second signature to the forwarding node, so that the forwarding node sends the second access request containing the first metadata, the second metadata and the second signature to the server. Then, the server may determine whether to process the second access request based on the first metadata, the second metadata and the second signature. In the above process, since the first signature for the first metadata of the client and the second signature for the first metadata of the client and the first metadata of the forwarding node are all generated by the management node, if the forwarding node is hacked by an attacker, even if the attacker tampered with the first metadata of the client or the second metadata of the forwarding node in the second access request, the second signature for the first metadata and the second metadata comes from the management node and cannot be tampered with by the attacker. Therefore, after receiving the second access request, the server can also find that the tampered metadata is unreliable based on the second signature, that is, it finds that the original first metadata or second metadata has been tampered with. The server can choose not to process the client's access request, thereby ensuring communication security and improving the security of the entire system. For example, as shown in Figure 6 (Figure 6 is another structural diagram of the communication system provided by an embodiment of the present application), suppose that proxy1 is hacked by attacker A. Since the client's identifier is foo, which has not been authorized by the server, attacker A modifies UA=foo to UA=abc (abc is the identifier of the client authorized by the server) in order to allow the server to process the client's access request. However, attacker A cannot tamper with signature=valid-metadata-sign1. Therefore, after receiving the access request, the server can find that the signature verification for signature=valid-metadata-sign1 fails, and determines that the metadata UA=abc is unreliable, so it will not process the access request, thereby ensuring communication security.

[0118] Furthermore, if the forwarding node is compromised by some attackers, the attackers can also deny the existence of the forwarding node. In this case, the attacker will not cause the forwarding node to initiate a second signature request to the management node, but will directly generate a third access request (excluding the second metadata) based on the first metadata, first signature, and first signature chain contained in the first access request from the client and send it to the server. Since the forwarding node also adds the identifier of the forwarding node's own private key when generating the third access request, although the server will determine that the third access request is credible and the first metadata and first signature chain are credible after receiving the third access request, the first signature chain only contains the client's information and does not contain the forwarding node's information, while the identifier of the forwarding node's own private key contains the forwarding node's information, resulting in a mismatch between the two. This will cause the server to also not process the client's access request, thereby further ensuring communication security and further improving the security of the entire system. For example, as shown in FIG7 (FIG7 is another structural diagram of the communication system provided by an embodiment of the present application), assume that proxy1 is compromised by attacker A. Attacker A attempts to disown proxy1. Since the server only processes requests from clients that directly access the server, attacker A can make the access request sent by proxy1 to the server contain only UA=foo, signedvia=client, signature=valid-metadata-sign, key=proxy1, and valid-proxy-sign1. However, the server will find that signedvia=client does not match key=proxy1, and will not process the access request, thereby ensuring communication security.

[0119] The above is a detailed description of the secure communication method based on the communication system provided in the embodiment of the present application. The management node provided in the embodiment of the present application will be introduced below. FIG8 is a structural diagram of the management node provided in the embodiment of the present application. As shown in FIG8, the management node is provided in the communication system. The communication system further includes a client, a forwarding node, and a server. The management node includes:

[0120] The first receiving module 801 is configured to receive a first signature request sent by a client; for example, the first receiving module 801 is configured to implement step 301 in the embodiment shown in FIG. 3 .

[0121] The first processing module 802 is used to generate a first signature based on the first metadata of the client contained in the first signature request, and send the first signature to the client, so that the client sends the first access request containing the first metadata and the first signature to the forwarding node; for example, the first processing module 802 is used to implement step 302 in the embodiment shown in Figure 3.

[0122] The second receiving module 803 is configured to receive a second signature request sent by the forwarding node based on the first access request; for example, the second receiving module 803 is configured to implement step 303 in the embodiment shown in FIG. 3 .

[0123] The second processing module 804 is configured to generate a second signature based on the first metadata and the first signature included in the second signature request, and the second metadata of the forwarding node, and to send the second signature to the forwarding node, thereby instructing the forwarding node to send the second access request including the first metadata, the second metadata, and the second signature to the server, thereby instructing the server to determine whether to process the second access request based on the first metadata, the second metadata, and the second signature. For example, the second processing module 804 is configured to implement step 304 in the embodiment shown in FIG. 3 .

[0124] In one possible implementation, a first processing module is configured to: obtain first metadata of the client from a first signature request; perform a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature was obtained through the client; and send the first metadata, the first signature chain, and the first signature to the client, so that the client sends a first access request including the first metadata, the first signature chain, and the first signature to a forwarding node.

[0125] In one possible implementation, a first processing module is configured to: cause a client to sign first metadata, a first signature chain, and a first signature using the client's own private key to obtain a third signature, and to send a first access request including the first metadata, the first signature chain, the first signature, an identifier of the client's own private key, and the third signature to a forwarding node. The identifier of the client's own private key is used by the forwarding node to obtain the client's own public key; the client's own public key and the third signature are used by the forwarding node to determine whether the first access request is authentic; the first signature is used by the forwarding node to determine whether the first metadata and the first signature chain are authentic; and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature has passed through the client.

[0126] In one possible implementation, the second receiving module is used to receive a second signature request sent by the forwarding node. The second signature request is for the forwarding node to determine that the first access request is credible, the first metadata and the first signature chain are credible, and the first signature is sent to the management node after passing through the client.

[0127] In a possible implementation, the client's own private key and the client's own public key are generated by the client, or the client's own private key and the client's own public key are generated by the management node.

[0128] In one possible implementation, the second processing module is configured to: obtain the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; after determining that the first metadata is credible based on the first signature, perform a signature operation on the first metadata, the second metadata, and the second signature chain to obtain a second signature, where the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; and send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node, so that the forwarding node sends the second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server, so that the server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature.

[0129] In one possible implementation, the second processing module is used to: instruct the forwarding node to sign the first metadata, the second metadata, the second signature chain, and the second signature based on the forwarding node's own private key to obtain a fourth signature, and send a second access request containing the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the forwarding node's own private key, and the fourth signature to the server; wherein, the identifier of the forwarding node's own private key is used for the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used for the server to determine whether the second access request is credible, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0130] In one possible implementation, the second processing module is used to enable the server to process the second access request based on the first metadata and the second metadata after determining that the second access request is credible, the first metadata, the second metadata and the second signature chain are credible, and the second signature passes through the forwarding node.

[0131] In a possible implementation, the forwarding node's own private key and the forwarding node's own public key are generated by the forwarding node, or the forwarding node's own private key and the forwarding node's own public key are generated by the management node.

[0132] In one possible implementation, the communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in the infrastructure for providing cloud services in the cloud service system.

[0133] It should be noted that the information interaction, implementation process, etc. between the modules / units of the above-mentioned device are based on the same concept as the method embodiment of the present application, and the technical effects they bring are the same as those of the method embodiment of the present application. For specific contents, please refer to the description in the method embodiment shown above in the embodiment of the present application, and no further details will be given here.

[0134] Please refer to Figure 9, which is a structural diagram of a computing device provided in an embodiment of the present application. As shown in Figure 9, the computing device 900 (which can be used to present the aforementioned management node, forwarding node or server, for the sake of convenience, the following is a schematic introduction using the computing device 900 as an example of a management node) includes: a processor 901, a memory 902, a communication interface 903 and a bus 904, and the processor 901, the memory 902 and the communication interface 903 are coupled via a bus (not marked in the figure). The memory 902 stores instructions, and when the execution instructions in the memory 902 are executed, the computing device 900 executes the method executed by the management node in the above method embodiment.

[0135] The computing device 900 may be one or more integrated circuits configured to implement the above method, such as one or more application specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more field programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms. For example, when a unit in the apparatus can be implemented in the form of a processing element scheduler, the processing element may be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call a program. For example, these units may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0136] The processor 901 may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0137] The memory 902 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0138] Memory 902 stores executable program code. Processor 901 executes this executable program code to implement the functions of the aforementioned first receiving module, first processing module, second receiving module, and second processing control module, thereby implementing the aforementioned secure communication method based on the communication system. In other words, memory 902 stores instructions for executing the aforementioned secure communication method based on the communication system.

[0139] The communication interface 903 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 900 and other devices or a communication network.

[0140] In addition to the data bus, bus 904 may also include a power bus, a control bus, and a status signal bus. The bus may be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a unified bus (Ubus or UB), a Compute Express Link (CXL), or a Cache Coherent Interconnect for Accelerators (CCIX). Buses can be categorized as address buses, data buses, and control buses.

[0141] Please refer to Figure 10 , which is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application. As shown in Figure 10 , the computing device cluster 1000 includes at least one computing device 900 .

[0142] As shown in Figure 10, the computing device cluster 1000 includes at least one computing device 900. The memory 902 in one or more computing devices 900 in the computing device cluster 1000 may store the same instructions for executing the above-mentioned secure communication method based on the communication system.

[0143] In some possible implementations, the memory 902 of one or more computing devices 900 in the computing device cluster 1000 may also store partial instructions for executing the above-mentioned secure communication method based on the communication system. In other words, the combination of one or more computing devices 900 can jointly execute the above-mentioned secure communication method based on the communication system.

[0144] It should be noted that the memory 902 in different computing devices 900 in the computing device cluster 1000 may store different instructions, each for executing a portion of the functions of the first receiving module, the first processing module, the second receiving module, and the second processing control module. In other words, the instructions stored in the memory 902 in different computing devices 900 may implement the functions of one or more modules among the first receiving module, the first processing module, the second receiving module, the second processing control module, and so on.

[0145] In some possible implementations, one or more computing devices 900 in the computing device cluster 1000 may be connected via a network, which may be a wide area network or a local area network.

[0146] Please refer to Figure 11, which is a schematic diagram of computer devices in a computer cluster provided by an embodiment of the present application being connected via a network. As shown in Figure 11, two computing devices 900A and 900B are connected via a network. Specifically, each computing device is connected to the network via a communication interface.

[0147] In one possible implementation, the memory of computing device 900A stores instructions for executing the functions of the first receiving module, the second receiving module, and the like. Meanwhile, the memory of computing device 900B stores instructions for executing the functions of the first processing module, the second processing module, and the like.

[0148] It should be understood that the functions of the computing device 900A shown in Figure 11 may also be completed by multiple computing devices. Similarly, the functions of the computing device 900B may also be completed by multiple computing devices.

[0149] An embodiment of the present application also relates to a computer storage medium, in which a program for signal processing is stored. When the computer storage medium is run on a computer, the computer executes the steps executed by the management node in the embodiment shown in FIG3 .

[0150] An embodiment of the present application further relates to a computer program product, which stores instructions that, when executed by a computer, enable the computer to execute the steps executed by the management node in the embodiment shown in FIG3 .

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

[0152] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0154] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0155] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

Claims

1. A secure communication method based on a communication system, characterized in that: The communication system includes a management node, a forwarding node and a server, and the method includes: The management node receives a first signature request sent by the client; The management node generates a first signature based on the first metadata of the client included in the first signature request, and sends the first signature to the client; The forwarding node receives a first access request sent by the client and including the first metadata and the first signature; The management node receives a second signature request sent by the forwarding node based on the first access request; The management node generates a second signature based on the first metadata included in the second signature request, the first signature, and the second metadata of the forwarding node, and sends the second signature to the forwarding node; The forwarding node sends a second access request including the first metadata, the second metadata and the second signature to the server; The server determines whether to process the second access request based on the first metadata, the second metadata, and the second signature.

2. The method according to claim 1, characterized in that The management node generates a first signature based on the first metadata of the client included in the first signature request, and sends the first signature to the client, and the forwarding node receives the first access request sent by the client including the first metadata and the first signature, including: The management node obtains first metadata of the client from the first signature request; The management node performs a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature is obtained through the client; The management node sends the first metadata, the first signature chain, and the first signature to the client; The forwarding node receives a first access request sent by the client, including the first metadata, the first signature chain, and the first signature.

3. The method according to claim 2, characterized in that The forwarding node receiving the first access request sent by the client and including the first metadata, the first signature chain, and the first signature includes: The forwarding node receives a first access request sent by the client, including the first metadata, the first signature chain, the first signature, an identifier of the client's own private key, and a third signature, where the third signature is obtained by the client signing the first metadata, the first signature chain, and the first signature based on the client's own private key; Among them, the identifier of the client's own private key is used by the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used by the forwarding node to determine whether the first access request is credible, the first signature is used by the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature passes through the client.

4. The method according to claim 3, characterized in that The management node receiving the second signature request sent by the forwarding node based on the first access request includes: The management node receives a second signature request sent by the forwarding node, where the second signature request is for the forwarding node to determine that the first access request is credible, the first metadata and the first signature chain are credible, and the first signature is sent to the management node after passing through the client.

5. The method according to claim 3 or 4, characterized in that: The private key of the client itself and the public key of the client itself are generated by the client, or the private key of the client itself and the public key of the client itself are generated by the management node.

6. The method according to any one of claims 1 to 5, characterized in that: The management node generates a second signature based on the first metadata, the first signature, and the second metadata of the forwarding node included in the second signature request, and sends the second signature to the forwarding node. The forwarding node sends a second access request including the first metadata, the second metadata, and the second signature to the server. The server determines whether to process the second access request based on the first metadata, the second metadata, and the second signature, including: The management node obtains the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; After determining that the first metadata is credible based on the first signature, the management node performs a signature operation on the first metadata, the second metadata, and a second signature chain to obtain a second signature, where the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; The management node sends the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node; The forwarding node sends a second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server; The server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature.

7. The method according to claim 6, characterized in that The forwarding node sending the second access request including the first metadata, the second metadata, the second signature chain and the second signature to the server includes: The forwarding node signs the first metadata, the second metadata, the second signature chain, and the second signature based on the forwarding node's own private key to obtain a fourth signature, and sends a second access request including the first metadata, the second metadata, the second signature chain, the second signature, an identifier of the forwarding node's own private key, and the fourth signature to the server; Among them, the identifier of the forwarding node's own private key is used by the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used by the server to determine whether the second access request is credible, the second signature is used by the forwarding node to determine whether the first metadata, the second metadata and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

8. The method according to claim 7, characterized in that The server determines whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature, including: The server processes the second access request based on the first metadata and the second metadata after determining that the second access request is credible, the first metadata, the second metadata and the second signature chain are credible, and the second signature passes through the forwarding node.

9. The method according to claim 8, characterized in that The private key of the forwarding node itself and the public key of the forwarding node itself are generated by the forwarding node, or the private key of the forwarding node itself and the public key of the forwarding node itself are generated by the management node.

10. The method according to any one of claims 1 to 9, characterized in that: The communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in an infrastructure for providing cloud services in the cloud service system.

11. A communication system, characterized in that: The communication system includes a management node, a forwarding node and a server; The management node is used to receive a first signature request sent by a client; The management node is further configured to generate a first signature based on the first metadata of the client included in the first signature request, and send the first signature to the client; The forwarding node is configured to receive a first access request sent by the client and including the first metadata and the first signature; The management node is further configured to receive a second signature request sent by the forwarding node based on the first access request; The management node is further configured to generate a second signature based on the first metadata included in the second signature request, the first signature, and the second metadata of the forwarding node, and send the second signature to the forwarding node; The forwarding node is further configured to send a second access request including the first metadata, the second metadata, and the second signature to the server; The server is used to determine whether to process the second access request based on the first metadata, the second metadata, and the second signature.

12. The communication system according to claim 11, characterized in that: The management node is used to obtain first metadata of the client from the first signature request; The management node is used to perform a signature operation on the first metadata and a first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature is obtained through the client; The management node is used to send the first metadata, the first signature chain, and the first signature to the client; The forwarding node is used to receive a first access request sent by the client, including the first metadata, the first signature chain, and the first signature.

13. The communication system according to claim 12, characterized in that: The forwarding node is configured to receive a first access request sent by the client, including the first metadata, the first signature chain, the first signature, an identifier of the client's own private key, and a third signature, where the third signature is obtained by the client signing the first metadata, the first signature chain, and the first signature based on the client's own private key; Among them, the identifier of the client's own private key is used by the forwarding node to obtain the client's own public key, the client's own public key and the third signature are used by the forwarding node to determine whether the first access request is credible, the first signature is used by the forwarding node to determine whether the first metadata and the first signature chain are credible, and the identifier of the client's own private key and the first signature chain are used to determine whether the first signature passes through the client.

14. The communication system according to claim 13, characterized in that: The management node is used to receive a second signature request sent by the forwarding node, where the second signature request is for the forwarding node to determine that the first access request is credible, the first metadata and the first signature chain are credible, and the first signature is sent to the management node after passing through the client.

15. The communication system according to claim 13 or 14, characterized in that: The private key of the client itself and the public key of the client itself are generated by the client, or the private key of the client itself and the public key of the client itself are generated by the management node.

16. The communication system according to any one of claims 11 to 15, characterized in that: The management node is configured to obtain the first metadata, the first signature, and the second metadata of the forwarding node from the second signature request; The management node is configured to, after determining that the first metadata is credible based on the first signature, perform a signature operation on the first metadata, the second metadata, and a second signature chain to obtain a second signature, wherein the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node; The management node is configured to send the first metadata, the second metadata, the second signature chain, and the second signature to the forwarding node; The forwarding node is used to send a second access request including the first metadata, the second metadata, the second signature chain and the second signature to the server; The server is used to determine whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature.

17. The communication system according to claim 16, characterized in that: The forwarding node is configured to sign the first metadata, the second metadata, the second signature chain, and the second signature based on the private key of the forwarding node itself to obtain a fourth signature, and send a second access request including the first metadata, the second metadata, the second signature chain, the second signature, an identifier of the private key of the forwarding node itself, and the fourth signature to the server; Among them, the identifier of the forwarding node's own private key is used by the server to obtain the forwarding node's own public key, the forwarding node's own public key and the fourth signature are used by the server to determine whether the second access request is credible, the second signature is used by the forwarding node to determine whether the first metadata, the second metadata and the second signature chain are credible, and the identifier of the forwarding node's own private key and the second signature chain are used to determine whether the second signature passes through the forwarding node.

18. The communication system according to claim 17, characterized in that: The server is used to process the second access request based on the first metadata and the second metadata after determining that the second access request is credible, the first metadata, the second metadata and the second signature chain are credible, and the second signature passes through the forwarding node.

19. The communication system according to claim 18, characterized in that: The private key of the forwarding node itself and the public key of the forwarding node itself are generated by the forwarding node, or the private key of the forwarding node itself and the public key of the forwarding node itself are generated by the management node.

20. The communication system according to any one of claims 11 to 19, characterized in that: The communication system is a cloud service system, the management node is a cloud management platform in the cloud service system, and the forwarding node and the server are cloud instances in an infrastructure for providing cloud services in the cloud service system.

21. A computing device cluster, characterized in that: The computing device cluster includes a management node, a forwarding node and a server; The management node comprises a first processor and a first memory, the first memory is used to store a first instruction, and the first processor is used to enable the management node to execute the steps executed by the management node in any one of the methods of claims 1 to 10 according to the first instruction; The forwarding node comprises a second processor and a second memory, the second memory is used to store a second instruction, and the second processor is used to enable the forwarding node to execute the steps executed by the forwarding node in any one of the methods of claims 1 to 10 according to the second instruction; The server includes a third processor and a third memory, the third memory is used to store a third instruction, and the third processor is used to enable the server to execute the steps performed by the server in any one of the methods of claims 1 to 10 according to the third instruction.

22. A computer storage medium, characterized in that The computer storage medium stores one or more instructions, which, when executed by one or more computers, enable the one or more computers to implement the method of any one of claims 1 to 10.

23. A computer program product, characterized in that The computer program product stores instructions, which, when executed by a computer, enable the computer to implement the method according to any one of claims 1 to 10.

Images