Session multiplexing method, storage medium, and program product

Abstract

The invention relates to the technical field of network communication security, and particularly provides a session multiplexing method, a storage medium and a program product. The method comprises the following steps: a target server receives a client greeting message from a client; when it is verified that the target domain identifier is the same as the domain identifier of the dynamic domain to which the target server belongs and a public key in the target server can decrypt the client signature, whether the target domain identifier is the same as the domain identifier of the historical dynamic domain is judged; if so, decrypting a session parameter corresponding to a session identifier obtained from an intra-domain account book by using a public key, and returning a first server greeting message to the client; otherwise, multiplexing the session corresponding to the session identifier according to the local federated bill cache, the gateway of the target domain and the gateway of the historical dynamic domain. According to the method, credible multiplexing of sessions in a cross-domain / cross-node environment is realized through a gateway of a historical dynamic domain and a gateway of a target domain, complete handshake is avoided, and zero-trust verifiability and security boundary control are kept at the same time.

Description

Technical Field

[0001] This disclosure relates to the field of network communication security technology, and in particular to a session multiplexing method, storage medium, and program product. Background Technology

[0002] The traditional TLS (Transport Layer Security) protocol is built on top of TCP. Its advantage lies in reliable transmission, but its connection establishment latency and retransmission characteristics are not suitable for business scenarios with extremely high real-time requirements. Therefore, the DTLS (Datagram Transport Layer Security) protocol was developed to port the security capabilities of TLS to UDP. Although DTLS provides secure communication capabilities for UDP, it still faces challenges in complex network environments. Therefore, how to further improve its efficiency and stability in weak network, cross-node, or cross-domain environments while maintaining the security features of DTLS is an urgent technical problem to be solved. Summary of the Invention

[0003] This disclosure is made in view of the above-mentioned problems. This disclosure provides a session multiplexing method, a storage medium, and a program product.

[0004] According to a first aspect of this disclosure, a session multiplexing method is provided, applied to a session multiplexing system, the session multiplexing system including a target server, a target domain gateway, a gateway for a historical dynamic domain, and a client, the method comprising: The target server receives a client greeting message from the client; the client greeting message includes a session identifier established by the client with a server in the historical dynamic domain that supports session reuse, a client signature, a domain identifier of the historical dynamic domain, and a target domain identifier; the client signature is a signature obtained by the client encrypting the session identifier, the domain identifier of the historical dynamic domain, and the target domain identifier using a private key. If the target domain identifier is the same as the domain identifier of the dynamic domain to which the target server belongs, and the public key in the target server can decrypt the client's signature, then determine whether the target domain identifier is the same as the domain identifier of the historical dynamic domain. If so, the session parameters corresponding to the session identifier obtained from the domain ledger are decrypted using the public key, and a first server greeting message is returned to the client. The first server greeting message carries a field indicating that the session corresponding to the session identifier is reused. Otherwise, the session corresponding to the session identifier is reused based on the local federal ticket cache, the target domain gateway, and the historical dynamic domain gateway.

[0005] Furthermore, according to the session reuse method of the first aspect of this disclosure, the session reuse corresponding to the session identifier is performed based on the local federated ticket cache, the target domain gateway, and the gateway of the historical dynamic domain, including: Determine whether the local federated ticket cache contains the federated ticket corresponding to the session identifier; If so, a second server greeting message is returned to the client, which instructs the target server to accept cross-domain session reuse and suggests caching the ticket; Otherwise, a cross-domain reuse request is sent to the target domain gateway, the cross-domain reuse request including the session identifier and the domain identifier of the historical dynamic domain; The target domain gateway sends a federation request to the gateway of the historical dynamic domain. The federation request carries the session identifier and indicates the cross-domain direction from the historical dynamic domain to the target dynamic domain corresponding to the target domain gateway. In response to the federation request, the gateway of the historical dynamic domain queries the domain ledger using the session identifier to obtain session parameters, converts the session parameters to obtain cross-domain materials, and returns a federation response to the target domain gateway, the federation response carrying the cross-domain materials. The target domain gateway activates the cross-domain material, obtains a session handle, and returns the session handle to the client; The client reuses the session based on the session handle.

[0006] Furthermore, according to the session multiplexing method of the first aspect of this disclosure, the session parameters are transformed to obtain cross-domain materials, including: The key management service within the historical dynamic domain is invoked to convert the session parameters into short-term tickets or repackaged blocks; The short-term notes or the repackaged blocks are used as the cross-domain material.

[0007] Furthermore, according to the session reuse method of the first aspect of this disclosure, the federated response also includes a signature of the federated response by the gateway of the historical dynamic domain; The method further includes: Upon receiving the federation response, the target domain gateway verifies the signature of the historical dynamic domain gateway on the federation response.

[0008] Furthermore, according to the session multiplexing method of the first aspect of this disclosure, the target domain gateway activates the cross-domain material to obtain a session handle, including: The target domain gateway invokes the key management service within the target dynamic domain to convert the cross-domain material into a session state usable in this domain, thereby obtaining the session handle.

[0009] Furthermore, the session multiplexing method according to the first aspect of this disclosure also includes: If the target domain identifier is determined to be the same as the domain identifier of the historical dynamic domain, the intra-domain ledger is queried using the session identifier and the domain identifier of the historical dynamic domain to obtain the return result of the intra-domain ledger. The return result includes the session parameters corresponding to the session identifier.

[0010] Furthermore, according to the session reuse method of the first aspect of this disclosure, the returned result also includes the signature of the client when initially establishing the session; the method further includes: Before returning the first server greeting message to the client, it is determined that the public key can decrypt the signature.

[0011] According to a second aspect of this disclosure, a network device is provided, including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the steps of the method described in the first aspect. According to a third aspect of this disclosure, a computer-readable storage medium is provided that stores a computer program / instructions thereon, which, when executed by a processor, implement the steps of the method described in the first aspect. According to a fourth aspect of this disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0012] As will be described in detail below, the session reuse method according to embodiments of this disclosure achieves trusted reuse of sessions in a cross-domain / cross-node environment through the gateway of the historical dynamic domain and the gateway of the target domain, avoiding a full handshake while maintaining zero-trust verifiability and security boundary control.

[0013] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0014] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0015] Figure 1 This is a flowchart illustrating a session multiplexing method according to an embodiment of the present disclosure.

[0016] Figure 2 This is a flowchart illustrating the initial session establishment of an application according to an embodiment of this disclosure.

[0017] Figure 3 This is a flowchart illustrating the application of intra-domain session multiplexing according to an embodiment of this disclosure.

[0018] Figure 4 This is a flowchart illustrating cross-domain session multiplexing according to an embodiment of this disclosure.

[0019] Figure 5 This is a flowchart illustrating an application example of a zero-trust scenario solution according to an embodiment of this disclosure.

[0020] Figure 6 This is a hardware block diagram of a network device according to an embodiment of the present disclosure.

[0021] Figure 7 This is a schematic diagram illustrating a computer program product according to an embodiment of the present disclosure. Detailed Implementation

[0022] The technical methods of the embodiments of the present invention will now be clearly and completely described with reference to the accompanying drawings.

[0023] In related technologies, DTLS faces challenges in providing secure communication capabilities for UDP in complex network environments, including: Handshake sensitivity: The handshake process involves multiple interactions. If there is a key mismatch or message loss, it can easily lead to authentication failure or connection delay. Insufficient session reuse: Repeated handshakes under weak network conditions will reduce performance and increase the risk of disconnection; Low retransmission efficiency: DTLS uses a fixed timeout retransmission mechanism, which is not well adapted to networks with large packet loss rate fluctuations; Segmentation is highly dependent: message segmentation and reassembly are more likely to fail in environments with high packet loss rates, affecting real-time performance.

[0024] Therefore, how to further improve the efficiency and stability of DTLS in weak network, cross-node, or cross-domain environments while maintaining its security features is an urgent technical challenge.

[0025] The following are definitions and explanations of the terms and concepts involved in this application.

[0026]

[0027] To facilitate understanding of this embodiment, a session multiplexing method disclosed in this disclosure will first be described in detail. See [link to relevant documentation]. Figure 1 The diagram shows a flowchart of a session multiplexing method provided in this embodiment of the present disclosure. The method includes the following steps: Step 101: The target server receives a client greeting message from the client; the client greeting message includes the session identifier established by the client with the server that supports session reuse in the historical dynamic domain, the client signature, the domain identifier of the historical dynamic domain, and the target domain identifier; the client signature is a signature obtained by the client encrypting the session identifier, the domain identifier of the historical dynamic domain, and the target domain identifier using a private key. In this embodiment, during the initial session establishment process, the client and the server in the historical dynamic domain negotiate whether to support blockchain enhancement functions through BlockchainSessionSupportIndication. Subsequently, a session identifier is generated and stored on the chain to provide a trusted state anchor for subsequent reuse.

[0028] In specific implementation, such as Figure 2 As shown, the initial session establishment process may include the following steps: Step 1. ClientHello The client sends a ClientHello message to the server, adding the following extended fields to the traditional DTLS fields (Note: the field types and values ​​mentioned in the solution are for implementation examples): BlockchainSessionSupportIndication Field type: 1 bit flag Values: Whether the key can be supported; the key negotiated now can be used later. 0: The client does not support blockchain session reuse; 1. The client supports blockchain session reuse.

[0029] Purpose: To determine whether the client has blockchain capabilities, as a condition for subsequent negotiations. A value of 1 indicates that the client wishes to use the blockchain mechanism to accelerate the establishment of future sessions.

[0030] Compatibility: If the server does not recognize this extension, the field should be ignored and the standard handshake should continue.

[0031] Step 2. Server Resolution Extension The server receives ClientHello and parses the extended fields: Determine if the client supports blockchain reuse; Determine whether adaptive optimization is supported; If any extension is not recognized, it is ignored and the handshake continues.

[0032] This step only assesses capabilities and does not return specific information.

[0033] Step 3. ServerHello The server responds to the ServerHello message with an extension to the traditional DTLS fields: BlockchainSessionSupportIndication (Blockchain Session Support Indication Extension) Field type: 1 bit flag Values: 0: The server does not support blockchain session reuse; 1. The server supports blockchain session reuse.

[0034] Purpose: To inform the client and server whether they support blockchain enhancements. If both sides have a value of 1, the enhancement process begins; otherwise, it reverts to standard DTLS.

[0035] Step 4. ClientKeyExchange (with optional ClientCert) Action: The client generates a pre-master secret (PMS), encrypts it with the server's public key, and sends it. (Note: The PMS is not directly used for business encryption, but serves as a seed for key derivation, ultimately yielding the symmetric key and key update status required for record protection.) Optional: If the server requested client authentication in the previous step, the client will also include a certificate (ClientCert, which is issued by the enterprise CA or carrier PKI and injected during registration; revocation / renewal is achieved through CRL / OCSP or domain policy synchronization; whether or not ClientCert is included depends on whether the server sends a CertificateRequest (usually in the server-side message after ServerHello). Function: Securely transmit critical key materials to the server to prepare for the derivation of the master key.

[0036] Note: When using a method that requires temporary server parameters, the calculation of ClientKeyExchange depends on the parameters provided by ServerKeyExchange in step 5. (In this case, step 5 should be executed first, followed by step 4, in the handshake process.) Step 5 (Conditionalized server-side parameters / authentication request) Following the ServerHello message, the server decides whether to send a ServerKeyExchange and / or CertificateRequest based on the key exchange method agreed upon in this negotiation. Symmetric key exchange requires client authentication. When using a key exchange method that requires a server temporary key parameter (such as the ECDHE-based method), the server sends a ServerKeyExchange message (carrying parameters such as curve / temporary public key / signature), which is a necessary input for the client to subsequently generate a ClientKeyExchange message. When the deployment strategy requires two-way authentication, the server sends a CertificateRequest to trigger the client to include ClientCert and the corresponding signature proof in subsequent messages; When using a key exchange method that "does not require temporary server parameters", ServerKeyExchange can be omitted.

[0037] Step 6. Client Certificate / Finished Action: The client (if requested) sends a Certificate to complete authentication; then sends a Finished message. (Whether the client sends a Certificate depends on whether it receives a CertificateRequest; if not received, it does not send one and continues with the Finished message.) Function: Verify the client's identity and confirm the integrity of the previous handshake messages.

[0038] Step 7. Server Finished Action: The server sends "Finished".

[0039] Function: To complete the integrity verification of the handshake between the two parties and confirm that the master key derivation is correct. That is, both parties verify the consistency between the handshake transcript and the key derivation through the Finished check value.

[0040] Step 8. Generate SessionID The client calculates the globally unique session identifier: SessionID = H(C-IP || S-IP || Port || Timestamp || Randoms) Function: To ensure that a session is unique across the entire network, serving as a reusable index.

[0041] Step 9. Signing and Submitting Session Materials on the Blockchain The client uses its private key pair (SessionID || SessionParams) to digitally sign Sign_C and constructs a BlockchainSessionSetupMessage: SessionID Enc(SessionParams) (encrypted storage) DomainID Sign_C The message was then broadcast to the ledger.

[0042] Step 10. Ledger Verification and Posting Action: Blockchain nodes within the domain receive messages, verify the legality of signatures and the validity of transactions, and write them into the ledger after consensus.

[0043] Function: Ensures secure storage of session anchors and parameters, visible only to nodes within the domain, and possesses traceability and tamper-proof properties.

[0044] Step 11. Record Encrypted Communication Successful on-chain connection → Both parties immediately enter into encrypted communication based on the negotiated master key using Record; If on-chain fails or the extension is not supported, fall back to standard DTLS Record communication.

[0045] Step 102: If the target domain identifier is the same as the domain identifier of the dynamic domain to which the target server belongs, and the public key in the target server can sign and decrypt the client, determine whether the target domain identifier is the same as the domain identifier of the historical dynamic domain. If yes, proceed to step 103; otherwise, proceed to step 104.

[0046] By verifying that the target domain identifier matches the domain identifier of the dynamic domain to which the target server belongs, unauthorized requests to establish a session can be avoided. When the public key on the target server can sign and decrypt the client's message, it indicates that the target server possesses the key associated with the client's established session, and this key can be used to reuse the session.

[0047] Step 103: Decrypt the session parameters corresponding to the session identifier obtained from the domain ledger using the public key, and return a first server greeting message to the client. The first server greeting message carries a field indicating the session corresponding to the reused session identifier.

[0048] When the target domain identifier is the same as the domain identifier of the historical dynamic domain, it indicates that the session is reused within the same domain, meaning that the target server and the server that initially established the session belong to the same dynamic domain.

[0049] In one optional embodiment, the domain ledger can be queried using a session identifier and the domain identifier of a historical dynamic domain to obtain the returned results of the domain ledger, which include the session parameters corresponding to the session identifier.

[0050] It should be understood that the session parameters here are encrypted session parameters. After obtaining the session parameters, they can be decrypted using the public key.

[0051] In an optional embodiment, the returned result of the domain ledger may further include a ledger certificate and / or the client's signature when initially establishing the session. Accordingly, the server can verify the consistency of the ledger state based on the ledger certificate, and simultaneously use the public key to verify whether the client's signature during the initial session establishment is correct (i.e., whether the public key can decrypt the signature). Verifying the consistency of the ledger state is for compatibility with existing session procedures, and verifying the client's signature during the initial session establishment is to implement secondary verification of the server's public key to ensure reliability.

[0052] It should be understood that after the target server returns the first server greeting message, the client and the target server can directly use the already used session parameters for Record layer encrypted communication, skipping the full handshake.

[0053] It should be understood that if the verification fails, the target server can still return a server greeting message, which carries a field indicating that the verification could not be reused this time. At this point, the client will automatically fall back to the standard DTLS full handshake process.

[0054] Step 104: Reuse the session corresponding to the session identifier based on the local federated ticket cache, the target domain gateway, and the gateway of the historical dynamic domain.

[0055] When the target domain identifier is different from the historical dynamic domain identifier, it means that the target dynamic domain and the historical dynamic domain are different dynamic domains, that is, the target server and the server that initially established the session belong to different dynamic domains.

[0056] In an optional embodiment, step 104 may include the following steps: Determine whether the local federated ticket cache contains a federated ticket corresponding to the session identifier; If so, a second server greeting message is returned to the client. The second server greeting message is used to instruct the target server to accept cross-domain session reuse and suggests caching the ticket. Otherwise, send a cross-domain reuse request to the target domain gateway. The cross-domain reuse request includes the session identifier and the domain identifier of the historical dynamic domain. The target domain gateway sends a federation request to the gateway of the historical dynamic domain. The federation request carries a session identifier and indicates the cross-domain direction from the historical dynamic domain to the target dynamic domain corresponding to the target domain gateway. In response to a federation request, the gateway of the historical dynamic domain queries the domain ledger using a session identifier to obtain session parameters, transforms the session parameters, obtains cross-domain materials, and returns a federation response to the target domain gateway, which carries the cross-domain materials. The target domain gateway activates cross-domain materials, obtains a session handle, and returns the session handle to the client; The client reuses the session based on the session handle.

[0057] It should be understood that after the target server returns the second service greeting message to the client, the client and the target server, based on the matched cross-domain session, skip the full handshake and directly enter DTLS Record encrypted communication.

[0058] In this embodiment, the cross-domain reuse request may also include a summary of the client greeting message, which is used to bind the context. The target server hands over the cross-domain reuse request to the target domain gateway and binds it to the handshake context using the summary of the client greeting message.

[0059] In this embodiment, the federation request may further include a summary of the client's greeting message and a signature of the federation request from the target domain gateway. The summary of the client's greeting message enables binding of the current handshake and domain replay / relocation. This federation request is used to request "cross-domain activatable" session material from the historical dynamic domain gateway.

[0060] In one or more embodiments, the results returned by the domain ledger may include, in addition to session parameters, ledger proofs and the client's signature at the initial session establishment. The ledger proof is an existence proof such as a Merkle path / block height. Accordingly, the server can verify the consistency of the ledger state based on the ledger proof, and simultaneously use the public key to verify whether the client's signature at the initial session establishment is correct (i.e., whether the public key can decrypt the signature). Verifying the consistency of the ledger state is for compatibility with existing session procedures, and verifying the client's signature at the initial session establishment is to perform secondary verification of the server's public key to ensure reliability.

[0061] In this embodiment, the key management service within the gateway of the historical dynamic domain can be invoked to convert session parameters into short-term tickets (FT, Federation Ticket) or rewrapped blobs (RWB); the short-term tickets or rewrapped blobs are then used as cross-domain materials. Both short-term tickets and rewrapped blobs can be used or activated within the target domain gateway.

[0062] In this embodiment, the federated response also carries ledger proof, the signature of the gateway of the historical dynamic domain, and / or policy fingerprint. The policy fingerprint is a snapshot / hash of the cross-domain policy that was in effect at the time.

[0063] In this embodiment, the target domain gateway converts cross-domain materials into a session state available in the target dynamic domain through the key management service within the target dynamic domain, obtains a session handle, and the client and server directly enter Record encrypted communication based on the activated session.

[0064] In the solution provided in this embodiment, trusted reuse of sessions in cross-domain / cross-node environments is achieved through the gateway of the historical dynamic domain and the gateway of the target domain, avoiding the complete handshake, while maintaining the verifiability of zero trust and security boundary control.

[0065] The following is an overall description of this plan.

[0066] The core innovation of this solution lies in: Define new DTLS protocol extension fields: BlockchainSessionSupportIndication: Used for client and server negotiation on whether blockchain session management is supported; BlockchainSessionReuseRequest: Used for session reuse requests, carrying SessionID, DomainID, and signature; FederationAck: Used for cross-domain session reuse confirmation, containing revocable short-term ticket information. These extended fields maintain compatibility with existing DTLS / TLS protocols, ensuring backward compatibility while providing protocol-level extension value.

[0067] Introducing domain ledger and cross-domain federated gateway mechanisms: Within the domain, the session parameters that have been successfully authenticated for the first time are signed by the gateway and stored on the blockchain (Ledger) to enable sharing among multiple gateways within the domain. In cross-domain scenarios, DomainGateway is introduced to perform session verification and ticket conversion, ensuring that session reuse remains trustworthy and controllable across different tenant domains and different PoP clusters.

[0068] Controlled cross-regional reuse based on short-term notes (FT / RWB): The source domain KMS (Key Management Service) generates short-term tickets that are valid only in the target domain based on session parameters. Cross-domain reuse can only be enabled after the target domain gateway verifies the ProofBundle, ensuring that session sharing does not equate to direct key transfer, and meeting the zero-trust principle of "least authorization and continuous verification".

[0069] Through the above mechanism, this solution can achieve the following: Rapid intra-domain reuse: Encrypted communication can be restored in weak network environments with only 0–1 RTTs; Smooth cross-domain handover: Controlled authentication can be completed in just 1–2 RTTs when roaming or switching across PoPs, avoiding repeated handshakes; Zero Trust Enhancement: Supports verifiable, revocable, and auditable cross-domain documents, ensuring clear security boundaries.

[0070] System architecture module functions: The overall architecture of the solution consists of the following four core modules (corresponding to the architecture diagram): Terminal Client: Supports the extended DTLS protocol; Include extended fields such as BlockchainSessionSupportIndication and BlockchainSessionReuseRequest in ClientHello / ReuseRequest; Based on the gateway response, you can choose to proceed with the full handshake, intra-domain reuse, or cross-domain reuse process.

[0071] Zero Trust Access Gateway (ZT-GW): As a DTLS access point within the domain, it is responsible for initial authentication, session anchoring, and the reuse process; In domain-integrated scenarios, session parameters are loaded directly from the ledger or cache; In cross-domain scenarios, interaction with DomainGateway is triggered to perform cross-domain verification.

[0072] Cross-domain federation gateway (DomainGateway): As an inter-domain anchor, it is responsible for the cross-domain FederationRequest / FederationResponse process; The domain ledger and KMS are invoked to generate and verify the ProofBundle; Ensure that cross-domain reuse is trustworthy, revocable, and controlled.

[0073] Ledger and Key Management Services (Ledger / KMS): Ledger: Responsible for storing session identifiers, signatures, and parameter hashes, and supports auditing and traceability; KMS: Responsible for generating and converting short-term notes (FT / RWB) to ensure that keys do not flow directly across domains, but are securely reused through controlled conversion.

[0074] Description of the innovative aspects of the solution: Cross-domain / cross-node trusted session reuse mechanism: The DTLS protocol introduces BlockchainSessionReuseRequest and DomainGateway, and combines Key Management Service (KMS) to generate short-term, revocable tickets (FT / RWB).

[0075] Unlike existing "on-chain storage of session information", this solution achieves cross-domain verification through ProofBundle (ledger proof + policy fingerprint + domain signature), ensuring that session reuse has verifiability, revocability and audit traceability in cross-domain / cross-node scenarios, thereby solving the problem that existing technologies cannot achieve trusted cross-domain reuse.

[0076] Protocol-level extension design: During the DTLS handshake phase, three extended fields are defined: BlockchainSessionSupportIndication, BlockchainSessionReuseRequest, and FederationAck, which are used for capability negotiation, reuse request, and cross-domain confirmation, respectively.

[0077] This extended design ensures the explicitness of the negotiation process, the triggering conditions for cross-domain requests, and fallback compatibility, while maintaining compatibility with existing DTLS / TLS protocols and possessing potential standardization value.

[0078] Through the above design, this solution can significantly reduce handshake round trips, improve authentication success rate in weak network environments, and enhance the security and controllability of cross-domain session management in scenarios such as cross-PoP roaming in operator networks, IoT weak network access, and multi-cluster deployment of zero-trust gateways. Domain creation and management: In this scheme, the security boundary for session reuse is defined by a "domain". A domain is a trust set consisting of a group of blockchain nodes, and controlled session reuse can be achieved between different domains through cross-domain mechanisms.

[0079] Domain initialization scenario (carrier scenario): In carrier network scenarios, domains are often configured during the system deployment phase. Carriers write key information about the domain into the genesis block, including: a unique DomainID, the initial node whitelist (NodeWhitelist), the chosen consensus algorithm (such as PBFT or PoS), and the domain gateway (DG) identifier (GatewayID) and certificate (GatewayCert). Additionally, a reference to the cross-domain policy (FederationPolicyRef) is recorded for future negotiation and reuse of permissions between domains.

[0080] In this way, operators can clearly define domain boundaries and trust anchors before the network is put into operation, avoiding security risks caused by unauthorized nodes joining during operation.

[0081] Dynamic domain generation (non-carrier scenario): In IoT or edge computing scenarios, domains may need to be dynamically generated. In this case, nodes must submit digital certificates to the administrator, who initiates a "join transaction." Existing nodes in the domain verify the certificate's legitimacy through consensus. Only after successful verification is the node added to the NodeWhitelist and confirmed by the ledger. Node exit is achieved through a "revocation transaction," which updates the ledger record, and other nodes in the domain automatically refuse to share sessions with it.

[0082] Compared to the carrier scenario, this approach is more flexible, but it relies on the consensus mechanism of blockchain to ensure trust.

[0083] The role of a domain gateway: Whether pre-configured or dynamically generated, each domain must have one or more domain gateways (DGs) as its sole trusted anchor point to the outside world. The domain gateway handles cross-domain session requests, internally accessing the domain's ledger and key management system (KMS), and externally interacting with gateways in other domains. This design prevents sensitive data within the domain from being directly exposed to external nodes, and makes cross-domain security boundaries clearer.

[0084] The core design of this solution consists of three progressively advancing processes, and the DTLS protocol process is embedded through two newly added extended fields: BlockchainSessionSupportIndication and BlockchainSessionReuseRequest. Initial session establishment: Based on the traditional DTLS handshake, the client and server negotiate whether to support blockchain enhancements through BlockchainSessionSupportIndication, and then generate a session identifier and store it on the blockchain to provide a trusted state anchor for subsequent reuse.

[0085] Intra-domain session reuse: Within the same domain, clients can carry BlockchainSessionReuseRequest in ClientHello to directly request the reuse of existing session parameters in the ledger, avoiding repeated full handshakes and reducing latency and resource overhead.

[0086] Cross-domain session reuse: In scenarios where users roam across domains, BlockchainSessionReuseRequest carries source and target domain information. The target domain gateway interacts with the source domain gateway to generate and verify ProofBundle, thus achieving controlled cross-domain session reuse. This is the core innovation of this solution.

[0087] By combining three processes with two extended fields, this solution achieves step-by-step optimization from single-domain to cross-domain, maintaining compatibility with existing DTLS protocols while significantly improving security and communication efficiency in multi-domain, weak network, and zero-trust scenarios.

[0088] For the process of establishing the initial session, please refer to [link / reference]. Figure 2 This will not be described in detail here.

[0089] Please refer to Figure 3 , Figure 3 This is a process for reusing sessions within a domain. This process mainly enables the rapid reuse of existing sessions within the same domain, skipping the full handshake and reducing latency and resource consumption.

[0090] like Figure 3 As shown, the process may include the following steps: Step 1. ClientHello (carrying the BlockchainSessionReuseRequest extension) The client sends a ClientHello message to server B in the same domain. A new extension has been added: BlockchainSessionReuseRequest Field structure: SessionID: The session identifier previously established by the client with other nodes within the domain; DomainID: Identifier of the domain to which the session belongs; ClientSig: The client uses a private key pair (SessionID || DomainID) to sign the application.

[0091] Purpose: To explicitly request the reuse of an existing session within this domain and to prove that the session origin is trustworthy.

[0092] Compatibility: If the server does not recognize the extension, the field is ignored and the full DTLS handshake is rolled back.

[0093] Step 2. Initial Server Verification Verify that the DomainID matches the domain itself; Verify the validity of the ClientSig signature. If the verification fails, reject the reuse request and roll back to a complete handshake.

[0094] Step 3. Ledger Inquiry If the initial verification passes, the server sends a query request to the domain ledger: Query(SessionID, DomainID) Function: To confirm whether the session has been recorded in the ledger.

[0095] Step 4. Ledger Return The ledger results include: Enc(SessionParams): Encrypted session parameters; Ledger proof: On-chain credentials confirming the existence of the session; Sign_C: The signature of the client during initial setup.

[0096] Step 5. Server verifies ledger results. Verify the consistency of the ledger status; Verify that Sign_C is correct; If verification succeeds, the session parameters are decrypted. If verification fails, the rollback process begins.

[0097] Step 6. ServerHello (Successfully reused path) The server returns ServerHello, and includes the following in the extended fields: BlockchainSessionSupportIndication Value: 1 Function: This indicates that the server supports the blockchain enhancement mode and that the current session can be reused directly.

[0098] Step 7. Enable Record encrypted communication The client and server directly use the reused session parameters for Record layer encrypted communication, skipping the full handshake.

[0099] Step 8. Fallback path (verification failed / no session) If steps 2 / 5 fail, the server will still return ServerHello, where: BlockchainSessionSupportIndication Value: 1 (indicates support for enhanced mode, but could not be reused in this instance).

[0100] The client will then automatically fall back to the standard DTLS full handshake process.

[0101] Please refer to Figure 4 , Figure 4 For cross-domain session reuse processes, such as Figure 4 As shown, the process may include the following steps: Step 1. ClientHello (carrying a cross-origin reuse request) The client sends a ClientHello message to the server in target domain B, with the following extension: BlockchainSessionReuseRequest Field structure: SessionID: The session identifier established in source domain A.

[0102] SourceDomainID=A: Source domain identifier.

[0103] TargetDomainID=B: Target domain identifier.

[0104] ClientSig: Client signature for SessionID || SourceDomainID || TargetDomainID.

[0105] Function: Explicitly declares "to reuse a session in domain A in domain B" and binds the current request to the specified domain to prevent session drift / replay.

[0106] Compatibility: If the server does not recognize the extension, it should be ignored and a fallback to the standard DTLS full handshake should be implemented.

[0107] Step 2. Local verification on the target server Verify that TargetDomainID == B; Verify ClientSig; Query the local FT cache (whether a valid Federation Ticket for this SessionID already exists).

[0108] If successful, proceed to step 3 (hit branch) or step 5 (missed branch); if unsuccessful, ultimately execute the failure rollback (see the rollback logic in steps 16 / 17). That is, a hit is an "optional optimization branch," while a miss results in the complete DG_B process. DG_A interactive link.

[0109] Step 3. (Hit the branch) ServerHello(Accepted + TicketHint) If the local FT hits: the server returns ServerHello{<ext:FederationAck(Accepted=true,TicketHint=true)>} Purpose: Inform the client that cross-domain reuse has been directly accepted and suggest caching the ticket (indicate that there is a reusable FT).

[0110] Step 4. (Hit the branch) Enter Record encrypted communication Based on the matched cross-domain session, the client and server skip the full handshake and directly enter DTLS Record encrypted communication.

[0111] The path has now been hit; steps 5–15 below are for paths that were not hit.

[0112] Step 5. (Missing) Target Server → Target Domain Gateway The target server encapsulates the above parameters into a CrossDomainLookup.start message and sends it to DG_B.

[0113] Field description: SessionID: The session identifier to be reused.

[0114] SourceDomain=A: Source Domain.

[0115] CH_digest: A summary of the current ClientHello, used for the binding context.

[0116] Function: Transfer the cross-domain reuse request to the domain gateway DG_B for processing and bind it to the current handshake context.

[0117] Step 6. DG_B → DG_A initiates a FederationRequest. FederationRequest{ SessionID, A->B, Binding=CH_digest, DG_B_Sig} Field description: A->B: Cross-domain direction.

[0118] Binding=CH_digest: Binds the current handshake to prevent replay / retransmission.

[0119] DG_B_Sig: DG_B's signature of the request (including its certificate chain).

[0120] Function: Requests "Cross-domain Activation" session materials from the source domain gateway DG_A.

[0121] Step 7. DG_A → Domain A Ledger Inquiry LedgerQuery(SessionID) Function: Verify session existence and metadata on the source domain chain to prepare for generating cross-domain materials.

[0122] Step 8. Return the ledger for record keeping and signature. Ledger return: { Enc(SessionParams_A), Ledger Proof, Sign_C} meaning: Enc(SessionParams_A): Session parameters stored in encrypted form in domain A.

[0123] Ledger proof: Existence proofs such as Merkle path / block height.

[0124] Sign_C: The signature of the client when it first joins the blockchain (for verifiable origin).

[0125] Step 9. Convert DG_A to KMS_A for cross-domain materials. Transform(Enc(SessionParams_A), Target=B) Function: Request KMS_A to convert domain A session materials into a form that can only be used / activated in domain B.

[0126] Step 10. KMS_A outputs cross-domain materials. Output one of the following: FT (Federation Ticket, short-term note, can be activated directly in domain B); or RWB (Rewrapped Blob, which can only be dewrapped / activated in the KMS_B domain of the B domain).

[0127] Purpose: To ensure that the original session key is not transmitted directly across domains, but rather that "controlled and activatable" material is transmitted.

[0128] Step 11. DG_A → DG_B returns FederationResponse. FederationResponse{ ProofBundle(ledger proof, domain A signature, policy fingerprint, FT / RWB)} Field description: Ledger proof: On-chain existence proof (same as step 8).

[0129] Domain A signature: DG_A is the signature of the response packet.

[0130] Policy fingerprint: A snapshot / hash of the cross-domain policy that was in effect at the time.

[0131] FT / RWB: The transdomain material generated in step 10.

[0132] Function: To deliver a verifiable "cross-domain credential package" to DG_B.

[0133] Step 12. DG_B verifies the ProofBundle Verify that the signature and certificate chain of domain A are trustworthy; Verify that the ledger proof matches the SessionID; The verification strategy fingerprint satisfies the cross-domain policy within this domain. Verify that Binding == CH_digest (bound to the current handshake).

[0134] If any verification fails, proceed with a rollback (see steps 16 / 17).

[0135] Step 13. Import / Activate DG_B → KMS_B Import / Activate (FT or RWB) Function: Activate cross-domain materials into a session state that is available in this domain within the B domain KMS (without exposing the original key).

[0136] Step 14. KMS_B returns the activation handle. ActivateHandle(ExpireAt) Function: Returns a short-lived session handle (reference) for the server to use; includes an expiration time for easy revocation and rotation.

[0137] Step 15. DG_B → Target server returns results CrossDomainLookup.done(ActivateHandle) Function: Notifies the server that it can directly use ActivateHandle to establish encrypted communication with the client.

[0138] Step 16. ServerHello (Accepted / or Fallback) Success path: ServerHello{<ext:FederationAck(Accepted=true)>} Failure path (any authentication / policy fails): ServerHello{<ext:FederationAck(Fallback=true)>} Purpose: To clearly indicate whether cross-origin reuse is accepted; if it fails, it instructs the client to roll back the full handshake. That is, the target server includes a FederationAck in its ServerHello message to the client, notifying them of the acceptance / rollback result for cross-origin reuse.

[0139] Step 17. Enter Record encrypted communication (or roll back) Accepted=true: The client and server directly enter into encrypted communication based on the activated session (cross-domain reuse is complete).

[0140] Fallback=true: The client falls back to the standard DTLS full handshake, ensuring interoperability and availability.

[0141] The following is an application example of a zero-trust scenario solution.

[0142] Scenario Description: In a typical zero-trust network architecture, the zero-trust access gateway (ZT-GW, DTLS access point) is in a default silent state, allowing only legitimate authenticated traffic to enter. User equipment must complete authentication and session establishment through a UDP-based DTLS handshake before it can access protected resources. However, in weak network environments (such as poor cellular network signal, Wi-Fi to 4G / 5G handover, international roaming, etc.), the following challenges arise: Low handshake success rate: DTLS multiple round trips are prone to timeouts or failures due to packet loss; Poor user experience: Frequent authentication retry results in "difficulty in logging in and difficulty in operation"; Multiple gateway fragmentation: Zero trust typically employs multiple PoP deployments. When users switch networks, they connect to a new gateway, but the new gateway cannot inherit the old authentication state and must re-handshake completely, further exacerbating latency and failure probability.

[0143] Solution Application: This solution introduces a "blockchain-based DTLS session trusted reuse mechanism" into the zero-trust authentication architecture. By adding new protocol extension fields and cross-domain gateway collaboration mechanisms, it significantly improves the authentication experience under weak network conditions. Please refer to Figure 5 , Figure 5 A flowchart illustrating an application example of a zero-trust scenario solution, such as... Figure 5 As shown, it includes the following steps: 1. Initial Authentication (Intra-Domain Session Anchoring) The user completes a full DTLS handshake for the first time through ZT-GW; Both parties negotiated the BlockchainSessionSupportIndication extended field to confirm whether on-chain session reuse is supported. After successful authentication, ZT-GW signs the generated SessionID and session parameters and writes them into the domain ledger (Ledger_A / B), which is then shared by other ZT-GW nodes within the domain. Value: Provides an anchor point for subsequent weak network reconnection or gateway switching, avoiding repeated full handshakes.

[0144] 2. Intra-domain reuse (weak network reconnection / same-domain gateway switching) The client carries BlockchainSessionReuseRequest {SessionID, DomainID, ClientSig} in ClientHello; The new ZT-GW node can load session parameters directly from the ledger or cache, skipping the full handshake and directly entering encrypted communication. Value: In weak network environments, connections can be restored in just 0–1 RTT, significantly improving success rate and response speed.

[0145] 3. Cross-domain reuse (roaming / cross-PoP switching) When a user roams from domain A to domain B, the target ZT-GW_B cannot find the ticket locally, thus triggering a cross-domain request; DomainGateway_B sends a FederationRequest to DomainGateway_A via a secure channel; DomainGateway_A queries Ledger_A and calls KMS_A to generate a short-term, revocable cross-domain ticket (FT / RWB). The ProofBundle (containing ledger proof, signature, policy fingerprint, and ticket) is returned to DomainGateway_B; After DomainGateway_B authentication, the ticket is activated via KMS_B, generating a session handle that is valid only in Domain B; The target ZT-GW_B uses this handle to quickly establish secure communication with the client. Value: Enables seamless roaming for users switching between zero-trust gateways across regions or PoPs, avoiding the need for complete re-authentication.

[0146] 4. Overall Value Improved availability in weak network environments: Authentication success rate is significantly improved in weak network environments; Latency is significantly reduced: intra-domain multiplexing requires only 0-1 RTT, and cross-domain multiplexing requires 1-2 RTT; Supports stateless scaling: The ledger + gateway architecture supports horizontal scaling and failover; It complies with the zero-trust principle: cross-domain vouchers are short-term instruments that are verifiable, revocable, and auditable, in line with the zero-trust concept of "least authorization and continuous verification".

[0147] This solution has the following technical advantages: Cross-domain controllability: Unlike the "simple on-chain storage" of existing technologies, this solution achieves cross-domain controllable restricted reuse through cross-domain gateways, KMS conversion and ProofBundle verification, thus solving the trust boundary problem.

[0148] Protocol standardization potential: Define extended fields during the DTLS handshake phase to ensure compatibility with existing protocol stacks and facilitate future IETF / 3GPP standardization.

[0149] Weak network friendliness: During weak network reconnection or cross-domain handover, reuse only requires 0–2 RTTs, greatly reducing handshake overhead and improving authentication success rate.

[0150] Zero Trust Enhancement: Short-term notes are revocable and auditable, which aligns with the zero trust principle of "minimum authorization and continuous verification".

[0151] This disclosure also provides a network device for performing the session multiplexing method described above. Please refer to... Figure 6 It illustrates a schematic diagram of a network device provided by some embodiments of this disclosure. For example... Figure 6 As shown, network device 6 includes: processor 600, memory 601, bus 602 and communication interface 603. The processor 600, communication interface 603 and memory 601 are connected through bus 602. The memory 601 stores a computer program that can run on the processor 600. When the processor 600 runs the computer program, it executes the session multiplexing method provided in any of the foregoing embodiments of this disclosure.

[0152] The memory 601 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between the device network element and at least one other network element is achieved through at least one communication interface 603 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0153] Bus 602 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. The memory 601 is used to store programs. After receiving an execution instruction, the processor 600 executes the program. The session multiplexing method disclosed in any of the foregoing embodiments of this disclosure can be applied to the processor 600, or implemented by the processor 600.

[0154] The processor 600 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 600 or by instructions in software form. The processor 600 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 601. Processor 600 reads the information in memory 601 and, in conjunction with its hardware, completes the steps of the above method.

[0155] The network device and the session multiplexing method provided in this disclosure are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0156] This disclosure also provides a computer-readable storage medium corresponding to the session multiplexing method provided in the foregoing embodiments. The computer-readable storage medium is an optical disc, on which a computer program (i.e., a computer program product) is stored. When the computer program is run by a processor, it executes the session multiplexing method provided in any of the foregoing embodiments.

[0157] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0158] The computer-readable storage medium provided in the above embodiments of this disclosure and the session multiplexing method provided in the embodiments of this disclosure are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0159] This disclosure also provides a computer program product; please refer to [reference needed]. Figure 7 The computer program product 700 carries program code, namely computer program 701. The instructions included in the computer program 701 can be used to execute the steps of the session multiplexing method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0160] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0161] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0162] The block diagrams of devices, apparatuses, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0163] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0164] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0165] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0166] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0167] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A session multiplexing method, characterized in that, The method, applied to a session multiplexing system, which includes a target server, a target domain gateway, a gateway for a historical dynamic domain, and a client, comprises: The target server receives a client greeting message from the client; the client greeting message includes a session identifier established by the client with a server in the historical dynamic domain that supports session reuse, a client signature, a domain identifier of the historical dynamic domain, and a target domain identifier; the client signature is a signature obtained by the client encrypting the session identifier, the domain identifier of the historical dynamic domain, and the target domain identifier using a private key. If the target domain identifier is the same as the domain identifier of the dynamic domain to which the target server belongs, and the public key in the target server can decrypt the client's signature, then determine whether the target domain identifier is the same as the domain identifier of the historical dynamic domain. If so, the session parameters corresponding to the session identifier obtained from the domain ledger are decrypted using the public key, and a first server greeting message is returned to the client. The first server greeting message carries a field indicating that the session corresponding to the session identifier is reused. Otherwise, the session corresponding to the session identifier is reused based on the local federal ticket cache, the target domain gateway, and the historical dynamic domain gateway.

2. The method according to claim 1, characterized in that, Session reuse corresponding to the session identifier based on the local federated ticket cache, the target domain gateway, and the historical dynamic domain gateway includes: Determine whether the local federated ticket cache contains the federated ticket corresponding to the session identifier; If so, a second server greeting message is returned to the client, which instructs the target server to accept cross-domain session reuse and suggests caching the ticket; Otherwise, a cross-domain reuse request is sent to the target domain gateway, the cross-domain reuse request including the session identifier and the domain identifier of the historical dynamic domain; The target domain gateway sends a federation request to the gateway of the historical dynamic domain. The federation request carries the session identifier and indicates the cross-domain direction from the historical dynamic domain to the target dynamic domain corresponding to the target domain gateway. In response to the federation request, the gateway of the historical dynamic domain queries the domain ledger using the session identifier to obtain session parameters, converts the session parameters to obtain cross-domain materials, and returns a federation response to the target domain gateway, the federation response carrying the cross-domain materials. The target domain gateway activates the cross-domain material, obtains a session handle, and returns the session handle to the client; The client reuses the session based on the session handle.

3. The method according to claim 2, characterized in that, Transforming the session parameters to obtain cross-domain materials includes: The key management service within the historical dynamic domain is invoked to convert the session parameters into short-term tickets or repackaged blocks; The short-term notes or the repackaged blocks are used as the cross-domain material.

4. The method according to claim 2, characterized in that, The federated response also includes the gateway's signature of the federated response for the historical dynamic domain; The method further includes: Upon receiving the federation response, the target domain gateway verifies the signature of the historical dynamic domain gateway on the federation response.

5. The method according to claim 2, characterized in that, The target domain gateway activates the cross-domain material and obtains a session handle, including: The target domain gateway invokes the key management service within the target dynamic domain to convert the cross-domain material into a session state usable in this domain, thereby obtaining the session handle.

6. The method according to claim 1, characterized in that, Also includes: If the target domain identifier is determined to be the same as the domain identifier of the historical dynamic domain, the intra-domain ledger is queried using the session identifier and the domain identifier of the historical dynamic domain to obtain the return result of the intra-domain ledger. The return result includes the session parameters corresponding to the session identifier.

7. The method according to claim 6, characterized in that, The returned result also includes the client's signature when the session was initially established; the method further includes: Before returning the first server greeting message to the client, it is determined that the public key can decrypt the signature.

8. A network device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1-7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1-7.

Images