Secure communication method based on communication system and management node

Abstract

The invention discloses a secure communication method based on a communication system and a management node, which can improve the security of the whole system. The method comprises the following steps: a client can send a first signature request to a management node; then, the management node can generate and return a first signature to the client based on first metadata of the client included in the first signature request, so that the client sends a first access request including the first metadata and the first signature to the forwarding node. The forwarding node may then send a second signature request to the management node based on the first access request. And then, the management node can generate and return a second signature to the forwarding node based on the first metadata and the first signature contained in the second signature request and the second metadata of 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. If so, the server may determine whether to process the second access request based on the information.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311791872.X and the invention title "A Request Processing Method Based on a Trusted Signature Component and a Trusted Signature Component" filed with the National Intellectual Property Administration on December 22, 2023. The entire content thereof is incorporated herein by reference. Technical Field

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

[0003] In a communication system, for an access request initiated by a client for a server, it usually passes through one or more forwarding nodes to achieve request forwarding. For an access request, each forwarding node may add or append metadata to the access request for the server to determine whether to process the access request from the client.

[0004] In the communication system provided by the related art, when the client needs to access the server, the client can send an access request pointing to the server to the forwarding node. The access request includes the metadata of the client and the signature of the client. Then, the forwarding node can add the metadata of the forwarding node and the signature of the access node to the access request and send the modified access request to the server. Then, the server can verify whether the metadata of the client and the metadata of the forwarding node are trustworthy based on these signatures. If it is determined that these metadata are trustworthy, the modified access request is further processed, for example, rejecting the access request of the client or executing the access request of the client, etc.

[0005] In the above communication system, when a forwarding node is compromised by some attackers, it can tamper with the metadata of the client or the forwarding node, resulting in the server incorrectly processing the access request of the client. For example, the server should have rejected the access request of the client, but the server executed the access request of the client, which will lead to a series of secure communication problems and reduce the security of the entire system. Summary of the Invention

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

[0007] A first aspect of the embodiments of the present application provides a secure communication method based on a communication system. The communication system for implementing this 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 can generate a first signature request containing the 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. Therefore, the management node can process the first metadata to obtain the first signature. Then, the management node can send the first metadata and the first signature to the client so that the client can generate a first access request containing 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 can generate a second signature request containing 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. Therefore, the management node can process the first metadata, the first signature, and the second metadata to obtain the second signature. Then, the management node can 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 containing 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] As can be seen from the above method: Since the first signature for the first metadata of the client and the second signature for the first metadata of the client and the second metadata of the forwarding node are both generated by the management node. If the forwarding node is compromised by an attacker, even if the attacker tampers with the first metadata of the client or the second metadata of the forwarding node in the second access request, but 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 untrustworthy based on the second signature, that is, it is found that the original first metadata or second metadata has been tampered with. The server can choose not to process the client's access request, thus ensuring communication security and improving the security of the entire system.

[0014] In a possible implementation, 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 the first access request sent by the client and including the first metadata and the first signature, which includes: 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 the first signature chain, and obtains the first signature. 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, and the forwarding node receives the first access request sent by the client and including the first metadata, the first signature chain, and the first signature. In the foregoing implementation, after receiving the first signature request from the client, the management node can parse the first signature request to obtain the first metadata of the client, the identifier of the client's own private key, and the fifth signature. Then, the management node can 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, it indicates that the first signature request is trustworthy. Therefore, the management node can 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. Among them, the first signature chain is used to indicate that the first signature is obtained through the client. After obtaining the first signature chain and the first signature, the management node can 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 a possible implementation, the forwarding node receiving the first access request sent by the client and containing the first metadata, the first signature chain, and the first signature includes: the forwarding node receiving the first access request sent by the client and containing the first metadata, the first signature chain, the first signature, the identifier of the client's own private key, and the 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. In the foregoing 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, thereby obtaining the third signature, and generating 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. That is to say, 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 trustworthy, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are trustworthy, 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.

[0016] In a possible implementation, the management node receiving the second signature request sent by the forwarding node based on the first access request includes: the management node receiving the second signature request sent by the forwarding node, where the second signature request is sent by the forwarding node to the management node after determining that the first access request is trustworthy, the first metadata and the first signature chain are trustworthy, and the first signature has passed through the client. In the foregoing implementation, after receiving the first access request from the client, the forwarding node can 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 can 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 third signature using the client's own public key. If the signature verification is successful, it indicates that the first access request is trustworthy. Next, the forwarding node can perform a signature verification operation on the first signature. If the signature verification passes, it indicates that the first metadata and the first signature chain are trustworthy. Then, the forwarding node can compare the identifier of the client's own private key and the first signature chain. If both contain the client's information, it indicates that the first signature has passed through the client. After these multi-level trust proofs, the forwarding node can send the second signature request to the management node.

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

[0018] In a 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 a second access request including the first metadata, the second metadata, and the second signature to the server. Whether the server processes the second access request based on the first metadata, the second metadata, and the second signature includes: 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 trustworthy 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. 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. In the foregoing implementation, 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 private key of the forwarding node itself, and the sixth signature. Then, the management node can obtain the public key of the forwarding node itself based on the identifier of the private key of the forwarding node itself, and perform a signature verification operation on the sixth signature using the public key of the forwarding node itself. If the signature verification is successful, it indicates that the second signature request is trustworthy. Next, the management node can perform a signature verification on the first signature. If the signature verification passes, it indicates that the first metadata and the first signature chain are trustworthy. The management node can modify the first signature chain to the 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. Among them, the second signature chain is used to indicate that the second signature is obtained through the client and the forwarding node. After obtaining the second signature chain and the second signature, the management node can 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 a second access request including the first metadata, the second metadata, the second signature chain, and the second signature to the server.

[0019] In a possible implementation manner, 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 its own private key to obtain a fourth signature, and sends the second access request including the first metadata, the second metadata, the second signature chain, the second signature, the identifier of its own private key, and the fourth signature to the server. In the foregoing implementation manner, after obtaining the first metadata, the second metadata, the second signature chain, and the second signature, the forwarding node can perform a signature operation on the first metadata, the second metadata, the second signature chain, and the second signature through its own private key, so as to obtain the fourth signature, and generate a second access request based on the first metadata, the second metadata, the second signature chain, the second signature, the identifier of its own private key, and the fourth signature. That is to say, the second access request can include the first metadata, the second metadata, the second signature chain, the second signature, the identifier of its own private key, and the fourth signature. Then, the forwarding node can 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 a possible implementation manner, the server determining whether to process the second access request based on the first metadata, the second metadata, the second signature chain, and the second signature includes: After the server determines 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, the server processes the second access request based on the first metadata and the second metadata. In the foregoing implementation manner, after receiving the second access request from the forwarding node, the server can parse the second access request to obtain the first metadata, the second metadata, the second signature chain, the second signature, the identifier of its own private key, and the fourth signature. Then, the server can 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. If the signature verification is successful, it indicates that the second access request is credible. Next, the server can perform a signature verification operation on the second signature. If the signature verification passes, it indicates that the first metadata, the second metadata, and the second signature chain are credible. Then, the server can compare the identifier of the forwarding node's own private key and the second signature chain. If both of them contain the information of the forwarding node, it indicates that the second signature passes through the forwarding node. After these multi-level credibility proofs, the server can process the second access request based on the first metadata and the second metadata.

[0021] In a possible implementation manner, 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.

[0022] In a possible implementation manner, 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] The second aspect of the embodiments of the present application provides a communication system, which includes a management node, a forwarding node, and a server; the management node is configured 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, the first signature, and the second metadata of the forwarding node included in the second signature request, 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 configured to determine whether to process the second access request based on the first metadata, the second metadata, and the second signature.

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

[0025] In a possible implementation, a forwarding node is configured to receive a first access request sent by a client, the first access request including first metadata, a first signature chain, a 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; the identifier of the client's own private key is used by the forwarding node to obtain the client's own public key, and the client's own public key and the third signature are used by the forwarding node to determine whether the first access request is trustworthy, the first signature is used by the forwarding node to determine whether the first metadata and the first signature chain are trustworthy, 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.

[0026] In a possible implementation, a management node is configured to receive a second signature request sent by the forwarding node, where the second signature request is sent to the management node by the forwarding node after determining that the first access request is trustworthy, the first metadata and the first signature chain are trustworthy, and the first signature has passed 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 a 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; after determining that the first metadata is trustworthy 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 after passing 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 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 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 a possible implementation manner, a forwarding node is used to sign the first metadata, the second metadata, the second signature chain, and the second signature based on its own private key 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, the identifier of its 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 public key of the forwarding node, the public key of the forwarding node and the fourth signature are used for the server to determine whether the second access request is trustworthy, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are trustworthy, 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 a possible implementation manner, a 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 trustworthy, the first metadata, the second metadata, and the second signature chain are trustworthy, and the second signature passes through the forwarding node.

[0031] In a possible implementation manner, 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.

[0032] In a possible implementation manner, 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] The third aspect of the embodiments of the present application provides a management node. The management node is set in a communication system. The communication system further includes a client, a forwarding node, and a server. The management node includes: a first receiving module, configured to receive a first signature request sent by the client; a first processing module, 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, so that the client sends a first access request including the first metadata and the first signature to the forwarding node; a second receiving module, configured to receive a second signature request sent by the forwarding node based on the first access request; a second processing module, configured to generate 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 send the second signature to the forwarding node, so that the forwarding node sends a second access request including 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 a possible implementation manner, the first processing module is configured to: obtain the first metadata of the client from the first signature request; perform a signature operation on the first metadata and the 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; 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.

[0035] In a possible implementation manner, the first processing module is configured to: instruct the client to sign the first metadata, the first signature chain, and the first signature based on the private key of the client itself to obtain a third signature, and send a first access request including the first metadata, the first signature chain, the first signature, the identifier of the private key of the client itself, and the third signature to the forwarding node; where the identifier of the private key of the client itself is used for the forwarding node to obtain the public key of the client itself, the public key of the client itself and the third signature are used for the forwarding node to determine whether the first access request is trustworthy, the first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are trustworthy, and the identifier of the private key of the client itself and the first signature chain are used to determine whether the first signature passes through the client.

[0036] In a possible implementation manner, the second receiving module is configured to receive a second signature request sent by the forwarding node, where the second signature request is sent by the forwarding node to the management node after determining that the first access request is trustworthy, the first metadata and the first signature chain are trustworthy, and the first signature passes through the client.

[0037] In a possible implementation manner, 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.

[0038] In a possible implementation manner, 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 trustworthy 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; 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 a 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 a possible implementation manner, the second processing module is configured to: cause the forwarding node 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, the identifier of the private key of the forwarding node itself, and the fourth signature to the server; wherein, the identifier of the private key of the forwarding node itself is used for the server to obtain the public key of the forwarding node itself, the public key of the forwarding node itself and the fourth signature are used for the server to determine whether the second access request is trustworthy, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are trustworthy, and the identifier of the private key of the forwarding node itself and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0040] In a possible implementation manner, the second processing module is configured to cause 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 trustworthy, the first metadata, the second metadata, and the second signature chain are trustworthy, and the second signature passes through the forwarding node.

[0041] In a possible implementation manner, 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.

[0042] In a possible implementation manner, 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] The fourth aspect of the embodiments 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 execute the steps executed by the management node in the method described in the first aspect or any one of the possible implementation manners in 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 execute the steps executed by the forwarding node in the method described in the first aspect or any one of the possible implementation manners in 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 execute the steps executed by the server in the method described in the first aspect or any one of the possible implementation manners in the first aspect according to the third instruction.

[0044] The fifth aspect of the embodiments 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 manner of the first aspect.

[0045] The 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 manner of the first aspect.

[0046] In the embodiments of the present application, when a client needs to access a server, the client may send a first signature request to a management node. Then, the management node may generate a first signature based on the first metadata of the client included in the first signature request, and return the first signature to the client, so that the client sends a first access request including the first metadata and the first signature to a 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 included in the second signature request, and return the second signature to the forwarding node, so that the forwarding node sends a second access request including 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 foregoing 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 both generated by the management node, if the forwarding node is compromised by an attacker, even if the attacker tampers with the first metadata of the client or the second metadata of the forwarding node in the second access request, but 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 untrustworthy based on the second signature, that is, find that the original first metadata or second metadata has been tampered with. The server can choose not to process the access request of the client, thereby ensuring communication security and improving the security of the entire system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a schematic structural diagram of a communication system provided by the embodiments of the present application;

[0048] Figure 2 It is a schematic structural diagram of a cloud service system provided by the embodiments of the present application;

[0049] Figure 3 It is a schematic diagram of a secure communication method based on a communication system provided by the embodiments of the present application;

[0050] Figure 4 Another structural schematic diagram of the communication system provided by the embodiment of the present application;

[0051] Figure 5 Another structural schematic diagram of the communication system provided by the embodiment of the present application;

[0052] Figure 6 Another structural schematic diagram of the communication system provided by the embodiment of the present application;

[0053] Figure 7 Another structural schematic diagram of the communication system provided by the embodiment of the present application;

[0054] Figure 8 A structural schematic diagram of the management node provided by the embodiment of the present application;

[0055] Figure 9 A structural schematic diagram of the computing device provided by the embodiment of the present application;

[0056] Figure 10 A structural schematic diagram of the computing device cluster provided by the embodiment of the present application;

[0057] Figure 11 A schematic diagram showing the connection of computing devices in the computer cluster provided by the embodiment of the present application through a network. Detailed implementation manners

[0058] The embodiment of the present application provides 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] Terms such as "first" and "second" in the specification, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device including a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.

[0060] In a communication system, for an access request initiated by a client to a server, it usually passes through one or more forwarding nodes to implement the forwarding of the request. For an access request, each forwarding node may add or append metadata to the access request for the server to determine whether to process the access request from the client.

[0061] In the communication system provided by the related art, when the client needs to access the server, the client can send an access request pointing to the server to the forwarding node. The access request includes the metadata of the client and the signature of the client. Then, the forwarding node can add the metadata of the forwarding node and the signature of the access node to the access request, and send the modified access request to the server. Then, the server can verify whether the metadata of the client and the metadata of the forwarding node are trustworthy based on these signatures. If it is determined that these metadata are trustworthy, the server can further process the modified access request. For example, if it is determined based on the metadata of the client that the client is unauthorized, the server will reject the access request of the client. Another example is that if it is determined based on the metadata of the client that the client is authorized, the server can execute the access request of the client, and so on.

[0062] In the above communication system, when the forwarding node is compromised by some attackers, it can tamper with the metadata of the client or the forwarding node, resulting in the server misprocessing the access request of the client. For example, the server should have rejected the access request of the client, but the attacker modified the metadata of the unauthorized client to the metadata of the authorized client, resulting in the server wrongly executing the access request of the client. This will lead to a series of secure communication problems and reduce the security of the entire system.

[0063] Furthermore, when the forwarding node is compromised by some attackers, it can delete the metadata of the forwarding node, thereby denying the existence of the forwarding node. For example, the server only processes the access requests of the clients that directly access the server, and does not reject the access requests of the clients that pass through the forwarding node. The attacker can delete the metadata of the forwarding node at the forwarding node, causing the server to think that the client passing through the forwarding node is a client that does not pass through the forwarding node, and thus wrongly execute the access request of the client. This will also lead to a series of secure communication problems and further reduce the security of the entire system.

[0064] To solve the above problems, the embodiments of the present application provide a secure communication method based on a communication system, as Figure 1 shown ( Figure 1 which is a schematic structural diagram of the communication system provided by the embodiments of the present application). The secure system to which the method is applied may include a management node, a client (which can also be referred to as a client node), a forwarding node, and a server (which can also be referred to as a server node). The following will introduce each component of the communication system separately:

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

[0066] The client can be understood as the client of a certain user. It usually has the need to access the server, so it can initiate an access request to the server through the forwarding node. It should be noted that when the client needs to access the server, it can send a signature request containing the signature of its own metadata to the management node to request the management node to assist in implementing the signature of the client's metadata, and the client itself no longer needs to perform the signature operation. In addition, when the client sends a signature request to the management node and an access request to the forwarding node, it can generate the signature of the signature request and the signature of the access request to make the management node ensure that the signature request is trustworthy and make the forwarding node ensure that the access request is trustworthy.

[0067] A forwarding node, which can also be called a proxy node, can forward access requests from a client to a server to enable communication between the client and the server. It should be noted that after receiving an access request from the client, the forwarding node can first parse the access request to obtain the client's metadata, the signatures of these metadata, the signature chain for this signature, and the signature of the access request. When the forwarding node determines that the access request is trustworthy based on the signature of the access request, determines that the client's metadata, the signatures of these metadata, and the signature chain for this signature are trustworthy based on the signatures of these metadata, and determines that the signatures of these metadata have passed through the client based on the signature chain for this 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 signature operation. In addition, when the forwarding node sends a signature request to the management node and a new access request to the server, it can generate the signature of the signature request and the signature of the new access request to enable the management node to ensure that the signature request is trustworthy and enable the server to ensure that the new access request is trustworthy.

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

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

[0070] Further, when the above 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 multiple ways. For example, a cloud instance can be a physical server selected by the cloud management platform. Another example is that a cloud instance can be a bare metal server selected by the cloud management platform. Another example is that a cloud instance can be a virtual machine (VM) created by the cloud management platform on a physical server through virtualization technology. Another example is that a cloud instance can also be a container (docker) created by the cloud management platform on a physical server through virtualization technology. Another example is that a cloud instance can also be a micro virtual machine (microVM) created by the cloud management platform on a physical server through virtualization technology, and so on.

[0071] Further, these cloud instances can be deployed in the same site or different sites. The site can be presented in multiple forms. For example, a site can be a region in the infrastructure. Another example is that a site can be an availability zone in the infrastructure. Another example is that a site can be a data center (DC) in the infrastructure. Another example is that a site can be a computer room in the infrastructure. Another example is that a site can be a cabinet in the infrastructure, and so on.

[0072] Based on the above communication system, when the client needs to access the server, the client can provide its metadata to the management node so that the management node generates a signature for these 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 these 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 these 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 these metadata to the server so that the server determines whether to process the access request based on these metadata and the signature of these metadata. Since the signature of the client's metadata, 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 tampers with the client's metadata or the forwarding node's metadata in the access request, but the signature of these metadata comes from the management node and cannot be tampered with by the attacker. Therefore, after receiving the access request, the server can also find that the metadata is untrustworthy, that is, the metadata is tampered with, and choose not to process the client's access request, thus ensuring communication security and improving the security of the entire system. To further understand this process, the following will be combined with Figure 3 to further introduce this process. Figure 3A schematic diagram of the secure communication method based on a communication system provided by an embodiment of the present application. As Figure 3 shown, this method can be implemented through a communication system as Figure 1 shown. The communication system may 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 the client.

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

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

[0076] The client can perform a signature operation on the first metadata with its own private key to obtain a fifth signature (i.e., the signature for the first signature request), and generate a first signature request based on the first metadata, the identifier of the client's own private key, and the fifth signature. That is to say, the first signature request includes the first metadata, the identifier of the client's own private key, and the fifth signature. Then, the client can send the first signature request to the management node.

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

[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 signature request, the management node can parse the first signature request to obtain the first metadata. Therefore, the management node can process the first metadata to obtain the first signature. Then, the management node can send the first metadata and the first signature to the client so that the client can generate the first access request and send the first access request to the forwarding node, where 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 way:

[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 identifier of the client's own private key, and the fifth signature. Then, the management node can 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 (for example, perform a signature operation on the first metadata using the client's own public key and compare the obtained signature with the fifth signature). If the signature verification is successful (for example, the obtained signature is equal to the fifth signature), it indicates that the first signature request is trustworthy. Therefore, the management node can first generate the first signature chain and perform a signature operation on the first metadata and the first signature chain (the private key used for this signature operation can be either the management node's own private key or a private key specifically generated for the client by the management node in real time, and there is no restriction here), so as to obtain the first signature (that is, the signature for the first metadata and the first signature chain). Among them, the first signature chain is used to indicate that the first signature is obtained through the client.

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

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

[0084] Next, the TSC can generate a signature chain signedvia = client, and use the private key specific to client generated in real time by itself to perform a signature operation on UA = foo and signedvia = client, so as to obtain a signature signature = valid - metadata - sign for UA = foo and signedvia = client. Then, the TSC can return a signature response signresponse: UA = foo, signedvia = client, signature = valid - metadata - sign to the client.

[0085] More specifically, the client can generate a first access request in the following way:

[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, so as to obtain a third signature (i.e., the signature for the first access request), and generate 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. That is to say, 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.

[0087] It should be noted that the identifier of the client's own private key is used for the forwarding node to obtain the public key of the client. The public key of the client and the third signature are used for the forwarding node to determine whether the first access request is trustworthy. The first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are trustworthy. 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.

[0088] Still as in the above example, after obtaining signresponse: UA = foo, signedvia = client, signature = valid - metadata - sign, the client uses the private key of the client to perform a signature operation on UA = foo, signedvia = client, signature = valid - metadata - sign, thereby obtaining the signature requestsign for the access request: valid - client - sign. Then, the client can make the access request include UA = foo, signedvia = client, signature = valid - metadata - sign, key = client (the identifier of the private key of the client) and valid - client - sign.

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

[0090] More specifically, the public key and private key of the client itself have multiple sources:

[0091] (1) The private key of the client itself and the public key of the client itself can be generated by the client. For example, as Figure 4 shown, the public - private key pair of the client, i.e., key = client, is generated by the client itself and is used to generate the signature of the signature request pointing to the TSC and the signature of the access request pointing to proxy1. (2) The private key of the client itself and the public key of the client itself can also be generated by the management node. For example, as Figure 5 shown ( Figure 5 is another schematic diagram of the communication system provided by the embodiment of the present application), the public - private key pair of the client contains two pairs. One pair of public - private keys is key = client, which is used to generate the signature of the signature request pointing to the TSC, and the other pair of public - private keys is key = temp1, which is used to generate the signature of the access request pointing to proxy1, and this pair of public - private keys is provided by the TSC and can be sent to the client when the TSC returns the signature response to the client.

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

[0093] After obtaining the first access request, the forwarding node can generate a second signature request based on the first access request and send the second signature request to the management node. Among them, the second signature request includes the first metadata, the first signature, and the second metadata of the forwarding node.

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

[0095] After receiving the first access request from the client, the forwarding node can 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 can 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 third signature using the client's own public key (for example, perform a signature operation on the first metadata, the first signature chain, and the first signature using the client's own public key and compare the obtained signature with the third signature). If the signature verification is successful (for example, the obtained signature is equal to the third signature), it indicates that the first access request is trustworthy. Next, the forwarding node can perform a signature verification operation on the first signature (for example, perform a signature operation on the first metadata and compare the obtained signature with the first signature. The public key used for the signature operation here can be either the public key of the management node itself or a public key specifically generated for the client by the management node in real time, and there is no restriction here). If the signature verification passes (for example, the obtained signature is equal to the first signature), it indicates that the first metadata and the first signature chain are trustworthy. Then, the forwarding node can compare the identifier of the client's own private key (which can be used to represent the client itself) and the first signature chain. If both contain the client's information, it indicates that the first signature has passed through the client. After these multi-level trust proofs, the forwarding node can perform a signature operation on the first metadata, the first signature chain, the first signature, and the second metadata of the forwarding node using its own private key to obtain the sixth signature (i.e., the signature for the second signature request).

[0096] Then, the forwarding node can 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. That is to say, the second signature request contains 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 forwarding node can send the second signature request to the management node.

[0097] Still as in the above example, after receiving an access request from the client, proxy1 can first obtain the public key of the client based on key = client, and then use the public key of the client to verify the signature of valid-client-sign. After the signature verification passes, proxy1 can determine that the access request is trustworthy. Next, proxy1 can use the public key specifically generated for the client by TSC in real time to verify the signature of signature = valid-metadata-sign. After the signature verification passes, proxy1 can determine that UA = foo and signedvia = client are trustworthy. Then, proxy1 can compare key = client and signedvia = client. Since both contain client, proxy1 can determine that signature = valid-metadata-sign has passed through the client. Then, proxy1 can use the private key of proxy1 to perform a signature operation on UA = foo, signedvia = client, signature = valid-metadata-sign, and the metadata of proxy1, VIA-VPC-VPC1, to obtain the signature requestsign for the signature request signrequest: valid-request-sign1. Then, proxy1 can make the signrequest contain UA = foo, signedvia = client, signature = valid-metadata-sign, VIA-VPC-VPC1, clientkey = proxy1 (the identifier of the private key of proxy1), 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 included 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 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.

[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. Therefore, the management node can process the first metadata, the first signature, and the second metadata to obtain the second signature. Then, the management node can 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. Among them, 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 way:

[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 private key of the forwarding node itself, and the sixth signature. Then, the management node can obtain the public key of the forwarding node itself based on the identifier of the private key of the forwarding node itself, and perform a signature verification operation on the sixth signature using the public key of the forwarding node itself (for example, perform a signature operation on the first metadata, the first signature chain, the first signature, and the second metadata using the public key of the forwarding node itself, and compare the obtained signature with the sixth signature). If the signature verification is successful (for example, the obtained signature is equal to the sixth signature), it indicates that the second signature request is trustworthy. Next, the management node can perform signature verification on the first signature (the process will not be elaborated here). If the signature verification passes, it indicates that the first metadata and the first signature chain are trustworthy. The management node can modify the first signature chain to the 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 private key of the management node itself or a private key specifically generated for the forwarding node by the management node in real time, which is not restricted here), so as to obtain the second signature (that is, the signature for the first metadata, the second metadata, and the second signature chain). Among them, the second signature chain is used to indicate that the second signature is obtained after passing through the client and the forwarding node.

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

[0104] Still as in the above example, after the TSC receives the signrequest from proxy1, the TSC can first obtain the public key of proxy1 based on clientkey = proxy1, and then use the public key of proxy1 to verify the signature of requestsign: valid-request-sign1. After the signature verification passes, the TSC can determine that the signrequest is trustworthy. Then, the TSC can also verify the signature of valid-metadata-sign. After the signature verification passes, the TSC can determine that UA = foo and signedvia = client are trustworthy. Therefore, the TSC can extract UA = foo, VIA-VPC-VPC1, and signedvia = client from the signrequest. Then, the TSC can expand signedvia = client to signedvia = client, proxy1.

[0105] Subsequently, the TSC can use its own private key generated in real time and exclusive to proxy1 to perform a signature operation on UA = foo, VIA-VPC-VPC1, signedvia = client, proxy1, so as to obtain the signature signature = valid-metadata-sign1 for UA = foo, VIA-VPC-VPC1, and signedvia = client. Then, the TSC can return the signature response signresponse: UA = foo, VIA-VPC-VPC1, signedvia = client, proxy1, signature = valid-metadata-sign1 to the client.

[0106] More specifically, the forwarding node can generate a second access request in the following way:

[0107] After obtaining the first metadata, second metadata, second signature chain, and second signature, the forwarding node can use its own private key to perform a signature operation on the first metadata, second metadata, second signature chain, and second signature, so as to obtain the fourth signature (i.e., the signature for the second access request), and generate 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. That is to say, 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. Then, the forwarding node can send the second access request to the server.

[0108] It should be noted that the identifier of the private key of the forwarding node itself is used for the server to obtain the public key of the forwarding node itself. The public key of the forwarding node itself 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. The identifier of the private key of the forwarding node itself and the second signature chain are used to determine whether the second signature passes through the forwarding node.

[0109] Still as in the above example, after obtaining signresponse: UA=foo, VIA-VPC-VPC1, signedvia=client, proxy1, signature=valid-metadata-sign1, proxy1 performs a signature operation on UA=foo, VIA-VPC-VPC1, signedvia=client, proxy1, signature=valid-metadata-sign1 using the private key of proxy1, thereby obtaining the signature requestsign for the access request: valid-proxy-sign1. 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 the private key of proxy1) and valid-proxy-sign1.

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

[0111] More specifically, the public key and private key of the forwarding node itself have multiple sources:

[0112] (1) The private key of the forwarding node itself and the public key of the forwarding node itself can be generated by the forwarding node. For example, as Figure 4 shown, the public and private key pair of proxy1, i.e., key=proxy1, is generated by proxy1 itself and is used to generate the signature for the signature request pointing to the TSC and the signature for the access request pointing to the server. (2) The private key of the forwarding node itself and the public key of the forwarding node itself can also be generated by the management node. For example, as Figure 5As shown in the figure, the public-private key pair of proxy1 contains two pairs. One pair of public-private keys is key = proxy1, which is used to generate the signature of the signature request pointing to the TSC. The other pair of public-private keys is key = temp2, which is used to generate the signature of the access request pointing to the server. And this pair of public-private keys is provided by the TSC and can be sent to proxy1 when the TSC returns the signature response to proxy1.

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

[0114] After receiving the second access request from the forwarding node, the server can parse the second access request to obtain the first metadata, the second metadata, the second signature chain, the second signature, the identifier of the private key of the forwarding node itself, and the fourth signature. Then, the server can obtain the public key of the forwarding node itself based on the identifier of the private key of the forwarding node itself, and perform a signature verification operation on the fourth signature using the public key of the forwarding node itself (for example, perform a signature operation on the first metadata, the second metadata, the second signature chain, and the second signature using the public key of the forwarding node itself, and compare the obtained signature with the fourth signature). If the signature verification is successful (for example, the obtained signature is equal to the fourth signature), it indicates that the second access request is trustworthy. Next, the server can perform a signature verification operation on the second signature (for example, perform a signature operation on the first metadata, the second metadata, and the second signature chain, and compare the obtained signature with the second signature. The public key used for the signature operation here can be either the public key of the management node itself or the public key specifically generated for the forwarding node by the management node in real time, and there is no restriction here). If the signature verification passes (for example, the obtained signature is equal to the second signature), it indicates that the first metadata, the second metadata, and the second signature chain are trustworthy. Then, the server can compare the identifier of the private key of the forwarding node itself (which can be used to represent the forwarding node itself) and the second signature chain. If both contain the information of the forwarding node, it indicates that the second signature has passed through the forwarding node. After these multi-level trust proofs, the server can process the second access request based on the first metadata and the second metadata. For example, based on the first metadata and the second metadata, determine that the client is an authorized client, and the server then executes the second access request. Another example is that based on the first metadata and the second metadata, determine that the client accesses the server through the forwarding node, and the server then rejects the second access request (assuming that the server only allows direct access by the client), and so on.

[0115] Still as in 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 the signature of valid-proxy-sign1. After the signature verification passes, the server can determine that the access request is trustworthy. Next, the server can use the public key exclusive to the server generated by the TSC in real time to verify the signature of signature = valid-metadata-sign1. After the signature verification passes, the server can determine that UA = foo, VIA-VPC-VPC1, and signedvia = client, proxy1 are trustworthy. 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 through proxy1. Then, the server can process the access request based on UA = foo and VIA-VPC-VPC1.

[0116] It should be understood that in this embodiment, only one forwarding node is used for illustrative introduction, and it does not limit the number of forwarding nodes between the client and the server. In actual applications, the access request of the client can also pass through multiple forwarding nodes. During the forwarding process of the access request, the operations performed by each forwarding node can refer to the operations performed by this forwarding node in this embodiment, which will not be elaborated here. It should be noted that in the case of multiple forwarding nodes, each time the access request passes through an additional forwarding node, it contains the metadata of one more forwarding node, which will not be expanded here.

[0117] In the embodiments of the present application, when the client needs to access the 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 included in the first signature request, and return 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. 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 included in the second signature request, and return the second signature to the forwarding node, so that the forwarding node sends a second access request including 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 foregoing 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 both generated by the management node, if the forwarding node is compromised by an attacker, even if the attacker tampers with the first metadata of the client or the second metadata of the forwarding node in the second access request, but 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 untrustworthy based on the second signature, that is, it is found that the original first metadata or second metadata has been tampered with. The server can choose not to process the access request of the client, thereby ensuring communication security and improving the security of the entire system. For example, as Figure 6 shown ( Figure 6 is another schematic structural diagram of the communication system provided by the embodiments of the present application), assume that proxy1 is compromised by attacker A. Since the identifier of client is foo and it is not authorized by server, in order to make server process the access request of client, attacker A changes UA = foo to UA = abc (abc is the identifier of the client authorized by the server), but attacker A cannot tamper with signature = valid - metadata - sign1. Therefore, after receiving the access request, server can find that the signature verification for signature = valid - metadata - sign1 fails, determine that the metadata UA = abc is untrustworthy, and thus 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, instead of making the forwarding node initiate a second signature request to the management node, the attackers directly generate a third access request (without including the second metadata) based on the first metadata, the first signature, and the first signature chain included in the first access request from the client and send it to the server. Since the forwarding node will also include the identifier of its own private key when generating the third access request, although the server will determine that the third access request is trustworthy and the first metadata and the first signature chain are trustworthy after receiving the third access request, because the first signature chain only contains information of the client and does not contain information of the forwarding node, while the identifier of the forwarding node's own private key contains information of the forwarding node, resulting in a mismatch between the two, the server will also not process the access request of the client, thus further ensuring communication security and further improving the security of the entire system. For example, as Figure 7 shown( Figure 7 which is another schematic structural diagram of the communication system provided by the embodiment of the present application), assume that proxy1 is compromised by attacker A, and attacker A tries to deny proxy1. Since the server only processes requests from clients directly accessing the server, attacker A can make the access request sent by proxy1 to the server only include 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 thus does not process this access request, thereby ensuring communication security.

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

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

[0121] The first processing module 802 is 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, so that the client sends a first access request including the first metadata and the first signature to the forwarding node. For example, the first processing module 802 is used to implement Figure 3 step 302 in the embodiment shown.

[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 used to implement Figure 3 step 303 in the embodiment shown.

[0123] The second processing module 804 is configured to generate 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 send the second signature to the forwarding node, so that the forwarding node sends a second access request including 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. For example, the second processing module 804 is used to implement Figure 3 step 304 in the embodiment shown.

[0124] In a possible implementation manner, the first processing module is configured to: obtain the first metadata of the client from the first signature request; perform a signature operation on the first metadata and the first signature chain to obtain a first signature, where the first signature chain is used to indicate that the first signature passes through the client; 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.

[0125] In a possible implementation manner, the first processing module is configured to: instruct the client to sign the first metadata, the first signature chain, and the first signature based on the private key of the client itself to obtain a third signature, and send a first access request including the first metadata, the first signature chain, the first signature, the identifier of the private key of the client itself, and the third signature to the forwarding node. The identifier of the private key of the client itself is used for the forwarding node to obtain the public key of the client itself. The public key of the client itself and the third signature are used for the forwarding node to determine whether the first access request is trustworthy. The first signature is used for the forwarding node to determine whether the first metadata and the first signature chain are trustworthy. The identifier of the private key of the client itself and the first signature chain are used to determine whether the first signature passes through the client.

[0126] In a possible implementation manner, the second receiving module is configured to receive a second signature request sent by a forwarding node. The second signature request is sent to a management node by the forwarding node after determining that a first access request is trustworthy, a first metadata and a first signature chain are trustworthy, and the first signature has passed through a client.

[0127] In a possible implementation manner, the private key and the public key of the client itself are generated by the client, or the private key and the public key of the client itself are generated by the management node.

[0128] In a possible implementation manner, 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 trustworthy 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. The second signature chain is used to indicate that the second signature is obtained after passing through the client and the forwarding node; 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 a 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 a possible implementation manner, the second processing module is configured to: cause the forwarding node 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, the identifier of the private key of the forwarding node itself, and the fourth signature to the server; wherein, the identifier of the private key of the forwarding node itself is used for the server to obtain the public key of the forwarding node itself, the public key of the forwarding node itself and the fourth signature are used for the server to determine whether the second access request is trustworthy, the second signature is used for the forwarding node to determine whether the first metadata, the second metadata, and the second signature chain are trustworthy, and the identifier of the private key of the forwarding node itself and the second signature chain are used to determine whether the second signature has passed through the forwarding node.

[0130] In a possible implementation manner, the second processing module is configured to cause 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 trustworthy, the first metadata, the second metadata, and the second signature chain are trustworthy, and the second signature has passed through the forwarding node.

[0131] In a possible implementation manner, the private key and the public key of the forwarding node itself are generated by the forwarding node, or the private key and the public key of the forwarding node itself are generated by the management node.

[0132] In a 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 for the information interaction, implementation process, etc. among the above-mentioned device modules / units, since they are based on the same concept as the method embodiments of the present application, the technical effects brought by them are the same as those of the method embodiments of the present application. For the specific content, reference can be made to the description in the method embodiments shown above in the embodiments of the present application, and details will not be repeated here.

[0134] Please refer to Figure 9 , Figure 9 which is a schematic structural diagram of a computing device provided by an embodiment of the present application. As Figure 9 shown, the computing device 900 (which can be used to present the aforementioned management node, forwarding node or server. For the sake of convenience, in the following, the computing device 900 will be taken as an example of the management node for illustrative introduction) includes: a processor 901, a memory 902, a communication interface 903, and a bus 904. The processor 901, the memory 902, and the communication interface 903 are coupled through a bus (not labeled in the figure). The memory 902 stores instructions. 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 embodiments.

[0135] The computing device 900 may be one or more integrated circuits configured to implement the above method. For example: one or more application specific integrated circuits (ASICs), or, one or more digital signal processors (DSPs), or, one or more field programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms. Again, when the units in the device 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 processors that can call programs. Again, these units may be integrated together to be implemented in the form of a system-on-a-chip (SOC).

[0136] The processor 901 may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or 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. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (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 but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0138] The executable program code is stored in the memory 902, and the processor 901 executes the executable program code to respectively implement the functions of the foregoing first receiving module, first processing module, second receiving module, second processing control module, and other modules, thereby implementing the above-mentioned secure communication method based on the communication system. That is, the memory 902 stores instructions for executing the above-mentioned 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 communication networks.

[0140] In addition to the data bus, the bus 904 may also include a power bus, a control bus, a status signal bus, etc. 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), a Cache Coherent Interconnect for Accelerators (CCIX), etc. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0141] Please refer to Figure 10 , Figure 10 a schematic structural diagram of a computing device cluster provided by an embodiment of this application. As Figure 10 shown, the computing device cluster 1000 includes at least one computing device 900.

[0142] As Figure 10 shown, the computing device cluster 1000 includes at least one computing device 900. Instructions for executing the above-mentioned secure communication method based on a communication system may be stored in the same manner in the memories 902 of one or more of the computing devices 900 in the computing device cluster 1000.

[0143] In some possible implementation manners, partial instructions for executing the above-mentioned secure communication method based on a communication system may also be stored separately in the memories 902 of one or more of the computing devices 900 in the computing device cluster 1000. In other words, a combination of one or more computing devices 900 may jointly execute the secure communication method based on a communication system for execution.

[0144] It should be noted that the memories 902 in different computing devices 900 in the computing device cluster 1000 may store different instructions, which are respectively used to execute partial functions of the above-mentioned first receiving module, first processing module, second receiving module, and second processing and control module. That is, the instructions stored in the memories 902 of different computing devices 900 may implement the functions of one or more of the modules such as the first receiving module, first processing module, second receiving module, and second processing and control module.

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

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

[0147] In one possible implementation, the memory in the computing device 900A stores instructions for executing the functions of modules such as the first receiving module and the second receiving module, etc. At the same time, the memory in the computing device 900B stores instructions for executing the functions of modules such as the first processing module and the second processing module, etc.

[0148] It should be understood that Figure 11 the functions of the computing device 900A shown in

[0149] The embodiments of the present application also relate to a computer storage medium. The computer-readable storage medium stores a program for signal processing. When it runs on a computer, it causes the computer to execute the steps performed by the management node in the embodiments shown in Figure 3 the embodiments shown.

[0150] The embodiments of the present application also relate to a computer program product. The computer program product stores instructions. When the instructions are executed by a computer, it causes the computer to execute the steps performed by the management node in the embodiments shown in Figure 3 the embodiments shown.

[0151] Those skilled in the art can 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 foregoing method embodiments and will not be elaborated herein.

[0152] In several embodiments provided by the present 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 illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, 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 displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

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

[0154] In addition, the functional units in each embodiment of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0155] If the above-mentioned 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 such an understanding, the technical solution of the present application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions for causing 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 methods described in various embodiments of the present application. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs, and other various media that can store program codes.

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