Method and apparatus for trust management in blockchain-based integrated network

Abstract

A method and apparatus for trust management in a comprehensive network including a plurality of different communication networks, each of the plurality of different communication networks including at least one miner node, at least one authentication node, and at least one network node. A blockchain system is constituted by the miner nodes in the different communication networks. A block of a blockchain of the blockchain system includes an identity of a previous block of the blockchain, a timestamp of generation of the block, a list of trust values including a trust value of each of the at least one network node in the plurality of different communication networks, and a hash code of trust-related data for evaluating the trust values in the list of trust values. The block can be shared within any of the different communication networks for trust management of the at least one network node based on the trust values of the at least one network node.

Description

Technical Field

[0001] This invention generally relates to trust management in communication networks, and more specifically, to a blockchain-based trust management framework for integrated networks. Background Technology

[0002] The era of 5G (5th generation mobile networks and wireless systems) has arrived. 5G is about to be commercially available. Researchers and practitioners are now discussing post-5G (beyond 5G) and 6G telecommunications technologies. A 6G summit was held in Finland in December 2018 to gather basic concepts, proposals, and suggestions regarding 6G and compile them into a white paper. 6G could be a massively heterogeneous network (LS-HetNet), integrating different types of networks such as space satellite networks, terrestrial networks, and maritime networks into a large-scale, integrated network. Such a network can truly support networking anytime, anywhere and highly guarantee the quality of service expected by mobile users. Furthermore, the ITU-T mandates the provision of trusted networking, prompting us to seek trust management solutions to support trusted networking in integrated HetNets.

[0003] LS-HetNet merges different types of networks into a comprehensive network system to provide seamless global network coverage. From this perspective, HetNet can encompass the most important networks, including the Internet, mobile cellular networks, satellite networks, and maritime networks. Unlike traditional homogeneous networks and other HetNets, LS-HetNet (also known as a space-air-ground integrated network) possesses characteristics such as heterogeneity, distribution, multi-carrier domains, dynamic topology, self-organization, openness, high latency, and scalability. These specific characteristics introduce new challenges to network management and pose serious threats to security, privacy, and trust in many aspects and at different layers, such as identity management, trusted network access and handover, secure and trusted routing, authentication / authorization / accounting (AAA) management, secure data transmission, and key management, especially end-to-end secure communication. Furthermore, privacy protection becomes crucial to safeguard user identity privacy, personal information privacy, and communication data privacy. Additionally, it is highly anticipated that trusted mobile terminals will support secure and efficient HetNet communication. However, current literature typically focuses on specific types of HetNets, such as wireless HetNets, sensor HetNets, and cellular HetNets, lacking support for generality and universality. Existing solutions often employ centralized network management frameworks, relying on a few trusted parties for secure authentication and management, and are therefore vulnerable to single points of attack and insider hacking. They cannot support authentication of network node trust, user identity, and route trust in a highly scalable and unified manner. In practice, this design is difficult to gain support from all relevant network operators and is difficult to deploy globally. Post-5G LS-HetNets require decentralized and efficient network management that is universal, ubiquitous, scalable, and trustworthy.

[0004] Blockchain is a promising technology for decentralized trust management, providing transparent and consistent data storage ensured through cryptographic methods. It offers advantages such as high fault tolerance, data consistency and non-repudiation, and information traceability. Applying blockchain to LS-HetNet management and security is becoming an interesting and important topic because it can simplify and unify network management and its security management in areas such as AAA, key management, routing, and network function extensions, and overcome some potential network attacks. However, adopting blockchain mechanisms in HetNet (especially LS-HetNet) still faces many technical challenges and limitations. For example, how to design an efficient and lightweight blockchain system for HetNet management and security, how to protect user privacy when multiple network domains belonging to different operators exist, and how to use blockchain to support secure and trusted routing. Furthermore, blockchain technology is still in its early stages, and its application to HetNet may present new problems and challenges.

[0005] Therefore, providing a trust management framework for integrated networks (such as LS-HetNet) would be an improvement. Summary of the Invention

[0006] To overcome the aforementioned problems and the obvious limitations in reading and understanding existing technologies, this disclosure provides a method and apparatus for trust management in a blockchain-based integrated network. This integrated network is also known as a heterogeneous network.

[0007] According to one aspect of this disclosure, a method for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The method includes constructing a blockchain system by a first miner node in a first communication network of the integrated network and miner nodes in at least one second communication network of the integrated network. The method further includes the first miner node obtaining blocks of the blockchain of the blockchain system, wherein the block includes the identity of the previous block of the blockchain, a timestamp of the generation of the block, a trust value list containing trust values ​​of each of the at least one network node in the multiple different communication networks, and hash codes for evaluating trust-related data in the trust value list. The method further includes sharing the blocks within the first communication network.

[0008] In an exemplary embodiment, the method may further include: certifying a trusted execution environment as a trust core for use in a blockchain system.

[0009] In an exemplary embodiment, the trust value list may include trust values ​​of network nodes based on pseudonyms of the network nodes. The method may further include: sending a pair of trust values ​​and a first pseudonym of the network node from a first miner node to a trusted execution environment; in response to the sending, receiving a pair of trust values ​​and a second pseudonym of the network node from the trusted execution environment, wherein the second pseudonym is an updated pseudonym of the network node verified by the trusted execution environment based on the first pseudonym; and generating a block by the first miner node including the pair of trust values ​​and the second pseudonym of the network node. The pseudonym of the network node may be the public key of the network node.

[0010] In an exemplary embodiment, the block may further include security parameters of at least one network node in multiple different communication networks. The method may further include: a first miner node receiving security parameters of a first network node in a first communication network from an authentication node in the first communication network; and recording the security parameters of the first network node in the next block of the blockchain. The method may further include: extracting security parameters of a second network node in a second communication network from the block; and sending the security parameters to an authentication node in the first communication network to verify the validity of the second network node's certificate using the security parameters.

[0011] In an exemplary embodiment, the block may further include the public key of at least one network node in a plurality of different communication networks. The method may further include: a first miner node receiving the public key from a public-private key pair of a first network node in the first communication network from an authentication node in the first communication network; and recording the public key of the first network node in the next block.

[0012] In an exemplary embodiment, the block may further include system security parameters and a public key of at least one of a plurality of different communication networks. The method may further include: a first miner node receiving the system security parameters and the public key from a public-private key pair of the first communication network from an authentication node in the first communication network; and recording the system security parameters and public key of the first communication network into the next block of the blockchain.

[0013] In an exemplary embodiment, at least one network node may be a router. The router's trust value is associated with its routing performance. The method may further include: receiving performance information indicating the router's routing performance by a first miner node; evaluating the router's trust value based on the performance information; and recording the router's trust value in the next block of the blockchain.

[0014] In an exemplary embodiment, a block may further include information indicating cross-domain access and usage records following the generation of the previous block in the blockchain. These cross-domain access and usage records can be used to calculate the cost of cross-domain communication.

[0015] In an exemplary embodiment, the block may further include transactions that record the communication costs of different networks across the integrated network.

[0016] According to another aspect, a method for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The method includes obtaining blocks of a blockchain system's blockchain from a first miner node in a first communication network. A blockchain system is formed between the first miner node and miner nodes in at least one second communication network in the integrated network. A block of the blockchain includes the identity of the previous block of the blockchain, a timestamp indicating that the block was generated, a trust value list containing the trust values ​​of each of the at least one network node in the multiple different communication networks, and a hash code for evaluating trust-related data in the trust value list. The method further includes extracting the trust values ​​of the network nodes from the blocks.

[0017] In an exemplary embodiment, the trust value list may contain trust values ​​for network nodes based on the pseudonyms of the network nodes. The method may further include sending the latest pseudonym and new pseudonym of the network node from the authenticating node to a trusted execution environment certified by the miner node, for updating the latest pseudonym in the next block. The latest pseudonym and new pseudonym are signed with the private key corresponding to the latest pseudonym for verification by the trusted execution environment. The pseudonym of the network node may be the public key of the network node.

[0018] In an exemplary embodiment, the block may further include security parameters of at least one network node from multiple different communication networks. The method may further include: an authentication node of the first communication network assigning a certificate to a first network node in the first communication network; and the authentication node sending security parameters to a miner node to verify the certificate of the first network node, such that the security parameters are recorded in a block of the blockchain. The method may further include: an authentication node receiving a certificate of a second network node in a second communication network; extracting the security parameters of the second network node from the block; and verifying the certificate of the second node using the security parameters of the second network node.

[0019] In an exemplary embodiment, the method may further include: extracting the trust value of the second network node from the block; and verifying the trust of the second network node by using the trust value of the second network node.

[0020] In an exemplary embodiment, the block may further include the public key of at least one network node in a plurality of different communication networks. The method may further include: sending the public key of the network node's public-private key pair from the authentication node to the miner node, such that the network node's public key is recorded in the block.

[0021] In an exemplary embodiment, the block may further include system security parameters and public keys of multiple different communication networks. The method may further include: generating system security parameters and a public-private key pair for the first communication network by an authentication node of the first communication network; and sending the public key from the system security parameters and public-private key pair from the authentication node to the miner node, such that the system security parameters and public key of the first communication network are recorded in the block. The method may further include: sending an encrypted public key of a first network node of the first communication network from the authentication node to a trusted execution environment authenticated by the miner node, wherein the public key of the first network node is encrypted with the private key from the public-private key pair for the first communication network; receiving an encrypted session key from the trusted execution environment by the authentication node to protect communication between the first network node and at least one second network node in at least one second communication network in the integrated network, wherein the session key is encrypted with the public key of the first network node; and sending the encrypted session key to the first network node. The method may further include sending an identifier of at least one second network node from the authentication node to the trusted execution environment.

[0022] In an exemplary embodiment, communication may be between a first network node and a plurality of second network nodes in at least one second communication network. The method may further include sending a group identifier from an authentication node to a trusted execution environment, identifying a group of the plurality of second network nodes.

[0023] In an exemplary embodiment, the method may further include: receiving a request from a trusted execution environment certified by a miner node for providing a public key of a first network node for a first communication network; and in response to the request, sending the encrypted public key of the first network node from the certified node to the trusted execution environment.

[0024] In an exemplary embodiment, at least one network node may be a router. The router's trust value may be associated with the router's routing performance. The method may further include: extracting the trust values ​​of at least two routers along a candidate route from a block; and selecting a route based on the trust values ​​of the at least two routers. Route selection may include: calculating the trust value of a candidate route based on the trust values ​​of the routers along the candidate route.

[0025] According to another aspect, a method for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The method includes: authenticating a trusted execution environment by one or more miner nodes in a blockchain system, wherein the blockchain system is constituted between miner nodes in a first communication network and at least one miner node in a second communication network within the integrated network. The method further includes the trusted execution environment retrieving blocks of the blockchain system's blockchain from the miner nodes in the blockchain system. A block of the blockchain includes the identity of the previous block of the blockchain, a timestamp indicating that the block was generated, a trust value list containing the trust values ​​of each of the at least one network node in the multiple different communication networks, and a hash code for evaluating trust-related data in the trust value list.

[0026] In an exemplary embodiment, the trust value list may include trust values ​​of network nodes based on pseudonyms of the network nodes. The method may further include: receiving, by a trusted execution environment, a latest pseudonym and a new pseudonym of a network node in a first communication network, and a signature of the latest pseudonym and the new pseudonym signed with the private key corresponding to the latest pseudonym; verifying, by the trusted execution environment, the received signature of the latest pseudonym and the received new pseudonym based on the latest pseudonym; receiving, by the trusted execution environment, a pair of trust values ​​and the latest pseudonym of the network node from a miner node; replacing the latest pseudonym in the pair with the new pseudonym; and sending the pair of trust values ​​and the new pseudonym of the network node from the trusted execution environment to the miner node. The pseudonym of the network node may be the public key of the network node.

[0027] In an exemplary embodiment, the block may further include system security parameters and public keys of multiple different communication networks. The method may further include: receiving, by a trusted execution environment, a public key of a first network node encrypted with the private key of the first communication network from a first authentication node in a first communication network; generating, by the trusted execution environment, a session key for communication between the first network node and at least one second network node in at least one second communication network; extracting the public key of the first communication network from the block by the trusted execution environment; decrypting the encrypted public key of the first network node with the public key of the first communication network; and sending, from the trusted execution environment, the session key encrypted with the public key of the first network node to the first node.

[0028] In an exemplary embodiment, the method may further include: sending a request from a trusted execution environment to a corresponding authentication node in at least one second communication network for providing a corresponding public key of each of the at least one second network node; in response to the request, receiving from the corresponding authentication node a corresponding encrypted public key of each of the at least one second network node, wherein the public key of the at least one second network node is encrypted with the private key of the communication network of the at least one second network node; extracting from a block of the blockchain a corresponding public key corresponding to the private key of the corresponding communication network of each of the at least one second network node; decrypting the corresponding encrypted public key of each of the at least one second network node with the public key of the corresponding communication network; and sending an encrypted session key from the trusted execution environment to each of the at least one second network node, wherein the session key sent to the at least one second network node is encrypted with the corresponding public key of the at least one second network node.

[0029] In an exemplary embodiment, the method may further include receiving the identifier of at least one second network node from the first authentication node by a trusted execution environment.

[0030] In an exemplary embodiment, communication may be between a first network node and multiple second network nodes in at least one second communication network. The method may further include receiving a group identifier identifying a group of the multiple second network nodes from a first authentication node by a trusted execution environment.

[0031] According to another aspect, an apparatus for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The apparatus includes: at least one processor; and at least one memory including computer program code. The memory and the computer program code are configured, together with the processor, to cause the apparatus to perform at least the following operations: forming a blockchain system by the apparatus in a first communication network of the integrated network and the miner nodes in at least one second communication network of the integrated network; obtaining a block of the blockchain of the blockchain system, wherein the block includes the identity of the previous block of the blockchain, a timestamp of the generation of the block, a trust value list containing the trust values ​​of each of the at least one network node in the multiple different communication networks, and a hash code for evaluating trust-related data in the trust value list; and sharing the block within the first communication network.

[0032] According to another aspect, an apparatus for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The apparatus includes: at least one processor; and at least one memory including computer program code. The memory and the computer program code are configured, together with the processor, to cause the apparatus to at least perform the following operations: obtaining blocks of a blockchain of a blockchain system from a first miner node in a first communication network, wherein a blockchain system is constituted between the first miner node and miner nodes in at least one second communication network in the integrated network, and wherein the blockchain block includes the identity of the previous block of the blockchain, a timestamp of the block generation, a trust value list containing the trust values ​​of each of the at least one network node in the multiple different communication networks, and a hash code for evaluating trust-related data in the trust value list; and extracting the trust values ​​of the network nodes from the blocks.

[0033] According to another aspect, an apparatus for trust management in an integrated network is provided. The integrated network includes multiple different communication networks, and each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The apparatus includes: at least one processor; and at least one memory including computer program code. The memory and computer program code are configured, together with the processor, to cause the apparatus to at least perform the following operations: authenticate a trusted execution environment with one or more miner nodes in a blockchain system, wherein a blockchain system is constituted between miner nodes in a first communication network and at least one miner node in a second communication network in the integrated network; and obtain blocks of the blockchain system's blockchain from the miner nodes in the blockchain system by the trusted execution environment. A block of the blockchain contains the identity of the previous block of the blockchain, a timestamp of the block generation, a trust value list containing the trust values ​​of each of the at least one network node in the multiple different communication networks, and hash codes for evaluating trust-related data in the trust value list.

[0034] According to another aspect, a non-transitory computer-readable storage medium is provided that stores instructions which, when executed by one or more processors, cause the processors to perform the method according to the above method.

[0035] Other aspects, features, and advantages of the invention will become apparent from the following detailed description of numerous specific embodiments and implementations, including the best mode contemplated for carrying out the invention. The invention is also capable of having other different embodiments, and several details thereof may be modified in various obvious ways without departing from the spirit and scope of the invention. Therefore, the drawings and descriptions should be considered illustrative in nature, rather than restrictive. Attached Figure Description

[0036] Embodiments of the invention are illustrated in the accompanying drawings by way of example and not limitation:

[0037] Figure 1 The illustration shows a system model for trust management in an integrated network according to an embodiment of the present disclosure;

[0038] Figure 2 The illustration depicts a method for trust management in an integrated network according to an embodiment of the present disclosure;

[0039] Figure 3 The illustration depicts a method for trust management in an integrated network according to an embodiment of the present disclosure;

[0040] Figure 4 The illustration shows the setup process of a blockchain system according to an embodiment of the present disclosure;

[0041] Figure 5 An exemplary structure of a block of a blockchain for trust management in an integrated network, according to an embodiment of the present disclosure, is illustrated.

[0042] Figure 6 An exemplary process for updating pseudonyms in an integrated network according to an embodiment of the present disclosure is illustrated;

[0043] Figure 7 The illustration depicts a method for pseudonym updates and blockchain announcements in an integrated network according to an embodiment of the present disclosure;

[0044] Figure 8 The illustration depicts a method for pseudonym updates and blockchain announcements in an integrated network according to an embodiment of the present disclosure;

[0045] Figure 9 The illustration depicts a method for pseudonym updates and blockchain announcements in an integrated network according to an embodiment of the present disclosure;

[0046] Figure 10 An exemplary process for anonymous cross-domain authentication in an integrated network is illustrated according to an embodiment of the present disclosure;

[0047] Figure 11 The illustration depicts a method for anonymous cross-domain authentication according to an embodiment of the present disclosure;

[0048] Figure 12 The illustration depicts an exemplary process for establishing end-to-end security in an integrated network according to an embodiment of the present disclosure;

[0049] Figure 13 The illustration depicts a method for establishing end-to-end security in an integrated network according to an embodiment of the present disclosure;

[0050] Figure 14 The illustration depicts a method for establishing end-to-end security in an integrated network according to an embodiment of the present disclosure;

[0051] Figure 15 The illustration depicts a process of trusted routing in an integrated network according to an embodiment of the present disclosure;

[0052] Figure 16 An exemplary method for trust-based routing selection according to an embodiment of the present disclosure is illustrated;

[0053] Figure 17 The illustration shows an apparatus on which embodiments of the present disclosure may be implemented; and

[0054] Figure 18 The illustration shows a chip set that can be used to implement embodiments of this disclosure. Detailed Implementation

[0055] Examples of methods and apparatus for trust management in integrated networks are disclosed. In the following description, numerous specific details are set forth for purposes of explanation to provide a thorough understanding of embodiments of the present disclosure. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details or with equivalent arrangements. In other instances, well-known structures and apparatuses are shown in block diagram form to avoid unnecessarily obscuring embodiments of the invention.

[0056] Most existing work on trust management focuses on specific, single networks, analyzing network security threats and needs to design security solutions. For example, in security standardization, the Internet Engineering Task Force (IETF) proposed IPSec and TLS protocols to protect the Internet network layer. The 3rd Generation Partnership Project (3GPP), aiming at secure authentication and key protocols for mobile communication networks (3G, 4G, and 5G), proposed the EPS-AKA (Evolved Packet System-Authentication and Key Protocol) protocol. On the other hand, the Space Network Standardization Organization (CCSDS) proposed the SCPS-SP (Space Communication Protocol Standard-Security Protocol) protocol for satellite network security. It can be seen that this lacks a unified security protection protocol for different types of networks, or a lack of integration of different protocols.

[0057] To address secure access and handover issues in HetNet within the context of mobile communication networks and wireless LANs, the IETF proposed introducing AAA (Authentication, Authorization, and Accounting) technology into mobile IPv6 handover to resolve these problems. Other suggestions and solutions exist in this area. For example, a novel secure handover authentication protocol based on bilinear encryption achieves signature verification without requiring certificate aggregation signatures, improving signature verification efficiency and enabling low-overhead secure handover. In satellite networks, there is an IPv6-based distributed handover management solution called DIPS; and a heuristic secure handover scheme for latency-tolerant networks can effectively improve handover success rates. However, past work has rarely investigated trusted handover across multiple network types and multiple network domains.

[0058] For secure routing, a solution based on node trust exists. A trust-level-based secure routing scheme for satellite communication networks has been proposed, which effectively detects the presence of malicious routing nodes and quickly responds to eliminate them. Furthermore, several routing protocols for ad-hoc networks have been proposed, such as the ASR (Adaptive Routing Selection) protocol based on DSR (Dynamic Source Routing) and the SAODV (Secure AODV) protocol based on AODV (Adaptive On-Demand Distance Vector Routing for Ad-hoc Networks). These protocols effectively guarantee the security of routing information. In addition, a secure routing protocol for wireless multi-hop heterogeneous networks based on trust management and energy awareness has been proposed. This protocol incentivizes trust behavior by routing nodes through a reward mechanism to ensure the security and reliability of routing information.

[0059] Several existing solutions exist for key management. For example, one solution proposes an identity-based group key management scheme for satellite networks. This solution improves the efficiency and security of key management. Another solution exists based on the characteristics of network layering and multi-domain architecture. This solution proposes a novel proxy-based re-encryption group key management scheme. This scheme effectively improves the scalability of key management in satellite networks. Furthermore, a multi-resource-oriented sensor network key management system has been proposed to effectively improve the applicability of key management schemes in sensor networks. However, the above solutions are only applicable to specific types of networks and are not suitable for guaranteeing the security of integrated heterogeneous networks.

[0060] However, current work on cybersecurity has the following problems:

[0061] (1) Specificity: Specific security solutions are proposed for specific types of networks. These solutions lack versatility and cannot be applied to comprehensive networks that integrate different types of networks, such as LS-HetNet.

[0062] (2) Centralized: Current solutions employ centralized security authentication or security architecture, which relies on "trusted" nodes in the network. It cannot uniformly support HetNet's source address authentication, user identity authentication, and routing information authentication in a general and privacy-preserving manner. However, LS-HetNet aims for decentralized trust management to support trusted authentication, routing, data transmission, etc., with automation and self-organization.

[0063] (3) Uniqueness: Current work focuses on one type of HetNet, such as wireless HetNet, sensor HetNet, and cellular HetNet. Therefore, it cannot guarantee the security of multiple types of heterogeneous networks (such as LS-HetNet). As a result, the solutions proposed in the current work lack universality.

[0064] (4) Vulnerability: The current work does not truly consider single points of vulnerability and insider attacks on so-called "trusted" nodes. However, the security design of next-generation networks can be based on a zero-trust model, in which no completely trusted node exists in the system, and each trust-centric network domain or network node acts in its own way driven by self-interest. Therefore, the solution proposed in the current work cannot guarantee true reliability.

[0065] In summary, current security solutions for HetNet lack the necessary support in terms of generality, universality, scalability, and trustworthiness. There is an urgent need for a decentralized and effective network trust management framework to seamlessly support integrated LS-HetNet.

[0066] This disclosure proposes a blockchain-based trust management framework for integrated networks. For example, the integrated network could be a 6G network, which is assumed to be highly heterogeneous and integrated. In a 6G network (also known as a 6G HetNet), different types of networks can work together to provide highly capable and high-quality network services with intelligence and automation.

[0067] 6G HetNets possess characteristics such as network heterogeneity, dynamic topology, self-organization, open communication links, high latency, and scalability. This leads to security threats across different aspects and layers of multiple network domains. It is impossible to operate a fully trusted entity to manage trust across the entire network because each part of the network is operated by different operators with different networking theories and functions. Different operators cannot trust each other. Trust management should be handled by multiple stakeholders to achieve the desired reliability. However, literature and industry still lack a universal, unified, and self-organizing trust management framework in integrated networks to realize or support these expected characteristics. These expected characteristics include, for example, secure and trusted network access and handover between multiple network domains operated by different operators and across different types of networks, trusted routing across multiple different types of networks, and secure data transmission and key management for end-to-end security.

[0068] This disclosure proposes a blockchain-based self-organizing trust management framework / solution / method for future integrated networks. For example, the integrated network could be a highly heterogeneous and integrated 6G network (or next-generation network). In an integrated network, different types of networks collaborate to provide highly capable and high-quality network services with intelligence, automation, and, most importantly, embedded trust. The security design of the next-generation network can be based on a zero-trust model, where no fully trusted nodes exist, and each trust-centric network domain in the next-generation network acts in its own way driven by self-interest.

[0069] The proposed trust management framework can provide Trust Management as a Service (TMaS). For example, trust management can support services in one or more of the following aspects: 1) secure and trusted network access and handover across different types of networks, with privacy protection between different types of networks operated by different operators; 2) trusted routing; 3) secure data transmission and key management supporting end-to-end communication security.

[0070] Specifically, this disclosure proposes a decentralized and efficient trust management framework for integrated networks (such as LS-HetNet) by developing a permissioned blockchain system. The integrated network comprises multiple distinct networks, which may be operated by different operators. The miner nodes of the blockchain system can be played by reliable gateway nodes selected from these multiple networks. For example, each of the multiple distinct networks may include at least one miner node of the blockchain system. The blockchain system embeds trust assessment into blockchain consensus to achieve trust consensus for network nodes across the multiple distinct networks. Trust assessment can be performed by miner nodes, for example, based on data transmission quality, traffic analysis, and node anomaly detection. The trust value of each network node assessed is recorded in the consensus-based blockchain of the blockchain system. In this regard, miner nodes can collect data associated with the trust values ​​of network nodes. When sufficient data is collected, the blockchain system updates the trust values ​​of network nodes based on the newly collected data by generating new blocks and recording new trust values ​​in the new blocks.

[0071] Authorized parties within any integrated network can access the blockchain. In this regard, authorized parties within a network can obtain the blockchain from miner nodes within the network. Therefore, network-wide authentication of trust in network nodes can be performed by obtaining the trust value recorded in the blockchain. In practice, by allowing fast node trust checks and pseudonymous authentication, new blocks of the blockchain can be pushed to at least one network edge device in each network within the integrated network, thereby supporting valid node authentication of trust during network access and switching at the network edge devices. This prevents untrusted nodes from accessing the network or switching to another network.

[0072] Furthermore, TEE (Trusted Execution Environment) technology can be used to establish the trust core of a blockchain system for processing privacy-preserving information. For example, the trust core could be an enclave powered by Intel® SGX (Software Protection Extensions) technology. Details of the trust core will be described later.

[0073] In this embodiment, the trust value and related information of a network node can be recorded in the blockchain based on the network node's pseudonym to support privacy. The pseudonym can be updated based on an update signal sent to the trust core of the blockchain system by the network node or its agent (such as an attribution authentication node that knows the network node's pseudonym and / or IP address). The trust core can further link the new pseudonym to its trust value in a privacy-preserving manner during block generation by employing a TEE (Trustee Exclusive).

[0074] In this embodiment, an anonymous trusted identity certificate can be issued to the UE (which is considered a network node), for example, by the UE's home authentication node. The corresponding security parameters used to verify the certificate are recorded in the blockchain to support cross-domain authentication and authorization. For example, during a handover or network handover between the UE and its home network, the authentication node in the foreign network can receive the anonymous trusted identity certificate from the UE, extract the corresponding security parameters of the UE from the block, and use the security parameters to verify the certificate. Furthermore, the authentication node in the foreign network can extract the UE's trust value from the block and check the trust value to block malicious intrusions initiated by untrusted nodes.

[0075] In this embodiment, session keys can be generated using the trust core of the blockchain system and distributed to all relevant parties in the end-to-end communication. In this regard, system security parameters and public-private key pairs can be provided to each network in the integrated network to secure transmissions within the network. The public key in the system security parameters and public-private key pairs can be recorded in the blockchain. The trust core can extract the system security parameters and public key from the blockchain and use them to decrypt the security keys from each end node in the end-to-end communication. The security keys can be used to protect the distribution of session keys from the trust core to each end node in the end-to-end communication. This ensures secure end-to-end communication.

[0076] In this embodiment, the trust value of a router can be evaluated, for example, based on data related to the routing performance of the respective router. The routing node can query the blockchain to retrieve the router's trust value and calculate the trust value of different routes based on the trust values ​​of routers along the respective routes. The optimal route can then be selected based on trust-related policies, such as source and / or destination trust policies. In this embodiment, trusted performance monitoring and trusted data collection can also be performed for trusted routes.

[0077] In the above embodiments, by embedding trust assessment into block generation, performing trusted and anonymous identity authentication based on the blockchain, and selecting the most trusted route for information transmission through blockchain queries, trusted networking in a comprehensive network can be achieved. The details of trust management in a comprehensive network will be described below.

[0078] Figure 1 A system architecture and security model for trust management in an integrated network, according to embodiments of this disclosure, are illustrated. Figure 1 As shown, HetNet is formed by integrating multiple different types of communication networks operated by different operators. Figure 1As shown, the integrated network 1000 includes a mobile cellular network 1100, an internet 1200, a satellite network 1300, a high-altitude platform 1400, and a maritime network 1500. A communication network operated by a dedicated operator can form a Trust-Centered Network Domain (TCND). A TCND is an abstraction of a network characterized by management features with a certain level of trust, and all members in a TCND have mutual trust relationships based on this trust-based technology. Communication networks operated by different operators cannot completely trust each other. Therefore, specific technologies should be applied to provide trusted networking across different TCNDs.

[0079] According to embodiments of this disclosure, a trust management system can be constructed for the entire integrated network 1000. The trust management system mainly includes several types of nodes: miners, authentication nodes for various TCNDs, and various network nodes. Network nodes include various communication nodes, such as user equipment (UE), routers, switches, network servers, network edge nodes, etc. The end users of the communication are the UEs of the communication network, such as mobile terminals in network 1100, computer terminals in network 1200, aircraft in network 1400, Internet of Things (IoT) devices, etc.

[0080] Miners construct a blockchain system using a specialized, reliable network. Miner nodes can be authorized nodes from the corresponding TCND. Figure 1 In the example shown, miner nodes 1101, 1201, 1301, 1401, and 1501 can be selected from networks 1100, 1200, 1300, 1400, and 1500, respectively, and constitute blockchain system 1600. For clarity, in Figure 1 In this system, only one miner node is allocated for each network. However, it should be understood that in Blockchain System 1600, a network can have more than one miner node. Established consensus mechanisms can be used to maintain the blockchain system. For example, the consensus mechanism could be based on a global trust assessment used for miner nodes, which will be described in detail later.

[0081] The generated blockchain can be stored in network nodes of each network, such as blockchain data storage servers 1104, 1204, 1304, 1404, and 1504. The blockchain data can be used for secure and reliable information sharing and dissemination between different TCNDs within the integrated network. For example, an authorized party in network 1100 (such as authentication node 1102, or other network nodes not shown) can access blockchain data storage server 1104 to retrieve the blockchain or query information from its blocks. Similarly, an authorized party in network 1200 (such as authentication node 1202, or other network nodes not shown) can access blockchain data storage server 1204 to retrieve the blockchain or query information from its blocks.

[0082] Each TCND can have one or more authentication nodes, which are responsible for registering network nodes (including UEs) to the TCND and distributing keys and other parameters (e.g., cross-domain pseudonymous trusted credentials). Authentication nodes can maintain a local database (not shown) to store the identity information, authorization information, billing information, and key information of registered nodes. Authentication nodes can further access the blockchain of the blockchain system 1600 and store the blockchain or information extracted from the blockchain data in their local database. Authentication nodes can share information with various network nodes in the same communication network through the blockchain.

[0083] In this trust management system, miner nodes are specialized devices and are assumed to be legitimate miners who will not engage in untrustworthy behavior, as they are selected and recommended nodes with the ability and reliability to maintain and manage the blockchain. However, miner nodes may malfunction or be attacked, which can lead to anomalous operations; therefore, they cannot be entirely trusted. With this in mind, corresponding mechanisms can be implemented during the setup of the blockchain system, which will be described later.

[0084] While some types of network authentication nodes possess strong security defenses, they can still be vulnerable to security threats such as internal attacks. When not under attack, they can authenticate various information about the UE (such as permissions, consumption rights, etc.) within their own TCND. However, authentication nodes and network nodes belonging to different TCNDs are not mutually trusting and malicious behavior may occur during cross-TCND communication. The trust management system is designed to enable secure and reliable communication between authentication nodes in different TCNDs based on blockchain technology.

[0085] Figure 2 The illustration shows a method 200 for trust management in an integrated network according to an embodiment of the present disclosure. The method is performed by a miner node, such as... Figure 1Any one of miners 1101, 1201, 1301, 1401, and 1501 shown. The integrated network includes multiple different communication networks. Each of the multiple different communication networks includes at least one miner node, at least one authentication node, and at least one network node. The method includes: at 210, a blockchain system (such as blockchain system 1600) is constructed by a first miner node (such as miner 1101) in a first communication network (such as 1100) in the integrated network (such as HetNet 1000) and miner nodes (such as miners 1201, 1301, 1401, and 1501) in at least one second communication network (such as corresponding networks 1200, 1300, 1400, and 1500). More than two communication networks may be involved in constructing the blockchain system. In other words, the miner nodes constructing the blockchain system may come from more than two communication networks. The method further includes: at 220, a block of the blockchain of the blockchain system is obtained by the first miner node (such as miner 1101). A block includes the identity of the previous block in the blockchain, a timestamp of the block's generation, a list of trust values ​​containing the trust values ​​of each network node in at least one of multiple different communication networks, and hash codes for trust-related data used to evaluate the trust values ​​in the trust value list. The method further includes: at point 230, a block is shared by a first miner node (e.g., miner 1101) within a first communication network (e.g., 1100). In each block of the blockchain, the trust value of a network node is a newly updated trust value based on the network performance of the network node. Thus, trust management for network nodes, including those belonging to different communication networks, can be performed based on the trust values ​​of the respective network nodes.

[0086] Figure 3 The illustration depicts a method 300 for trust management in an integrated network according to an embodiment of the present disclosure. The method is performed by an authentication node, such as... Figure 1Any of the authentication nodes 1102, 1202, 1302, 1402, and 1502 shown. Method 300 includes, for example, obtaining a block of the blockchain of a blockchain system (such as blockchain system 1600) from a first miner node (such as miner 1101) in a first communication network (such as network 1100) by an authentication node (such as authentication node 1102) in the first communication network (such as network 1100), as shown at 310. In this method, the blockchain system is constituted between the first miner node and miner nodes in at least one second communication network in the integrated network. In this method, a block of the blockchain includes the identity of the previous block of the blockchain, a timestamp of the block generation, a trust value list containing the trust values ​​of each of at least one network node in multiple different communication networks, and a hash code for evaluating trust-related data in the trust value list. Method 300 further includes: extracting the trust values ​​of network nodes from the block by the authentication node, as shown at 320. The network node may belong to a network different from the first communication network. In each block of the blockchain, the trust value of a network node is a newly updated trust value, for example, based on the network performance of the network node. Authenticating nodes can use the trust value to perform trust management for network nodes.

[0087] According to various embodiments, a number of key technologies are applied to implement the trust management platform, as described in detail below.

[0088] 1. Decentralized Trust Management Based on Permissioned Blockchain

[0089] Considering the efficiency and reliability of blockchain systems and the integration of heterogeneous networks, permissioned blockchains (collaborative blockchains) are applied to build platforms for trust management. Specifically, a dedicated blockchain network system can be embedded within a unified network and maintained by miners selected from the corresponding TCNDs. In this example, miners can be identified and authorized by the respective TCNDs. The blockchain system shares information with the authentication nodes of each TCND via the blockchain. Authentication nodes can maintain one or more information-sharing servers. The information shared between the information-sharing servers of each TCND can maintain a data summary of the blockchain. The consensus mechanism within the blockchain system ensures the trustworthiness and consistency of the data recorded in the blockchain.

[0090] In some embodiments, the trust values ​​of miners in different TCNDs can also be recorded in the blockchain. The blockchain system can dynamically guarantee the credibility and consistency of miners' trust values ​​through a dynamic trust guarantee mechanism. In this mechanism, each miner's trust value is calculated and aggregated to authenticate the corresponding miner (e.g., remote proof of a group of miner devices). It applies a trust-based consensus mechanism and can provide the blockchain system with security, throughput, and efficiency, while ensuring decentralization.

[0091] Furthermore, blockchain data can be sent to network nodes at all levels. For example, blockchain data can be sent to network edge nodes at the edge of each network to support rapid network access and switching. More details about the blockchain system are described below.

[0092] Blockchain system settings

[0093] Figure 4 The illustration depicts a setup process for a blockchain system according to an embodiment of the present disclosure. In this embodiment, process 400 may include the following steps:

[0094] At step 410, the policy and algorithm agreement is executed. In this example, at this step, all relevant operators of the network in the integrated network (such as HetNet1000) agree on the trust control policy, the expected trust assessment algorithm, the consensus mechanism, and other trusted system software of the blockchain system.

[0095] At step 420, the intended software and algorithms agreed upon in step 410 are installed in the miner nodes of the blockchain system. In this example, the miner nodes may install blockchain system software that includes the intended trust assessment and consensus mechanism.

[0096] At step 430, the miner nodes perform mutual trust authentication and embed the trust control policy agreed upon at step 410. In this example, miner nodes can remotely prove trust to each other and embed the expected and uniform trust control policy in the root trust module of all remote miner devices to ensure that miner nodes trust each other in future collaborations.

[0097] At step 440, a trust core is established for the blockchain system. In this example, all miner nodes can authenticate and prove the trust of a trusted execution environment, which is then used as the trust core to run the intended trusted code to handle trust-sensitive information within the blockchain system. For example, the trusted execution environment could be an enclave located within a server.

[0098] At step 450, a dynamic trust guarantee mechanism can be implemented. In this regard, the root trust module of each miner node can monitor the configuration and behavior of the corresponding miner node and determine whether this configuration and behavior do not match the trust control policy embedded in step 430. If any mismatch or violation exists, the device's action will be rejected. In specific cases where a miner node cannot meet the trust requirements of other miner nodes or the policy agreed upon in step 410, the root trust module of that miner node can automatically notify other miner nodes of its distrust. Later, the miner node can be kicked out of the blockchain system, or its trust value can be set to zero, meaning its contribution to block consensus will be ignored by other blocks.

[0099] At step 460, trust proof and guarantee are performed for the new miner. With a new miner node joining the blockchain system, the miner device can be remotely proven by other miners. Furthermore, a trust control policy can be embedded in its root trust module. The process then proceeds to step 450, where the new miner node can execute a dynamic trust guarantee mechanism.

[0100] Consensus mechanism based on trust assessment

[0101] In each block of a blockchain, the trust value of a network node is a newly updated trust value based on the network performance of that node. Many methods have been proposed for trust evaluation of each network node. For example, by detecting unwanted traffic and node anomalies in the network, miner nodes can collect information on all network nodes. Therefore, miner nodes can perform trust evaluations on nodes. For instance, each miner can calculate the trust value of a network node by applying common algorithms to facilitate consensus on the trust value of network nodes when generating and approving new blocks. The newly updated trust value of a network node is recorded in the new block. Simultaneously, the hash code of the data used to evaluate the trust value is also recorded in the new block.

[0102] In this embodiment, Trust-Weighted Practical Byzantine Fault Tolerance (PBFT) can be applied as the blockchain consensus mechanism for the blockchain system. According to this consensus mechanism, a miner node can approve a new block when the sum of the trust values ​​of all block-approving miners reaches a sufficient level. In this way, the communication cost of block consensus can be reduced, thereby improving the efficiency of the blockchain system.

[0103] Block structure

[0104] exist Figure 5 The diagram illustrates an exemplary structure of a blockchain block according to an embodiment. Figure 5As shown, the k-th block includes the identity (ID) 501 of the previous block (i.e., the (k-1)-th block) and the timestamp 502 for generating the k-th block. The k-th block also includes a trust value list 507 (containing the trust values ​​of network nodes in multiple TCNDs) and a hash code 506 for evaluating trust-related data recorded in the underlying blocks. The hash code 506 can be all trust-related data used to evaluate the trust values ​​recorded in the underlying blocks.

[0105] In some embodiments, the block may further include system parameters for each TCND and parameters for anonymous cross-domain authentication for each user, as shown in 503. For example, the system parameters include system security parameters and a public key for each TCND. An authenticating node of a TCND can generate system security parameters and a public-private key pair for its TCND and send the system security parameters and public key to the miner nodes of its TCND. The system security parameters and public key can then be recorded in the blockchain and, accordingly, published through the blockchain so that any authorized node (including authenticating nodes and the trust core in other TCNDs) can retrieve the system security parameters and public key.

[0106] Furthermore, the authentication node can generate a public-private key pair for each user (or UE) registered with the authentication node and send each user's public key to the miner node of its TCND. Each user's public key can then be recorded in the blockchain and published accordingly, allowing any authorized node to quickly retrieve the public key of each user (including users registered to a TCND different from the authorized node's TCND).

[0107] In some embodiments, a block may further include cross-domain network access and usage records after the (k-1)th block is generated and correspondingly before the kth block is generated, as shown in 504. Alternatively, these cross-domain network access and usage records can be stored off-chain by leaving the hashes of these records in the block. In the example, these records can be used to calculate the communication costs of cross-domain network access and usage.

[0108] 2. Authentication and Key Management in a Blockchain-Based Integrated Network

[0109] Enhanced node privacy

[0110] To support the privacy of network nodes, pseudonyms are used. For example, a network node's public key can serve as its pseudonym. In this embodiment, each network node's information is recorded based on its pseudonym in the blockchain. For example, the trust value of a network node recorded in the blockchain can be based on the pseudonym of the corresponding node. Figure 5As shown in 507, in the trust value list of the k-th block, the trust value of the network node (represented as node j) in the TCND (e.g., identified by n_id) is recorded as a pair of trust value and public key, which is represented as (TV j,k,n_id PK j ).

[0111] The pseudonym can be updated periodically for each network node. The pseudonym update is hidden from the miner node and any other node. In this embodiment, a trusted execution environment such as Intel SGX TEE can be applied to allow miner nodes to update the node's pseudonym while protecting the node's privacy. Figure 6 An example process for updating pseudonyms is shown.

[0112] Pseudonym updates can be handled directly by network nodes or trusted proxies of network nodes. Figure 6 In the illustrated embodiment, at step 620, the UE 602 of the TCND can send a request for pseudonym update to the trust core 603 through the secure channel between the UE 602 and the trust core 603 (which is established at step 610). In another embodiment, the authentication node of the TCND can send a request for pseudonym update to the trust core 603 through the secure channel between the authentication node and the trust core 603. For example, the UE could be... Figure 1 The network node 1203 shown can be an authentication node. Figure 1 The authentication node 1202 is shown. Trust core 603 can be an enclave running in the cloud. In the example where the pseudonym of the network node is the network node's public key, the request can include the UE's private key SK. j,old The old public key and new public key (e.g., denoted as network node j) of the signing UE (e.g., denoted as PK respectively) j,new and PK j,old ).

[0113] At step 630, the trust core 603 verifies the request for pseudonym update. This can be done using PK. j,old Verification by SK j,old The signature is used to verify the request. PK j,old It can be provided upon request. Trust Core 603 can check the PK. j,old Its existence within the blockchain. If the verification is positive, Trust Core 603 can record a valid request.

[0114] When a new block is generated at step 640, the miner will contact the Trust Core to retrieve the new pseudonym for the network node. As shown in step 650, miner 601 will send a pair of trust values ​​(TV) from UE 602. j,k,n_id ) and pseudonyms (e.g., old public key PK) j,oldIt is sent to Trust Core 603. Trust Core 603 can check the record for the corresponding pseudonym update request.

[0115] If it is determined that a PK exists for updating UE 602 j,old If the request is valid, then at step 650, the trust core 603 will use a valid PK. j,new Replacement pair (TV) j,k,n_id PK j,new PK in ) j,old In step 660, the latest valid pair of trust value and pseudonym (TV) is returned to miner 601. j,k,n_id PK j,new Next, at step 670, miner 601 announces the latest valid pair of trust values ​​and pseudonyms (TV) in the next block. j,k,n_id PK j,new ).

[0116] Figure 7 The illustration depicts a method 700 for pseudonym updating and blockchain announcements according to embodiments of the present disclosure. Method 700 can be executed by a miner node, such as... Figure 6 The miner 601 shown. At step 710, the miner node can connect to network nodes (e.g., Figure 6 In UE 602, a pair of trust values ​​and a first pseudonym are sent to the trusted execution environment. The first pseudonym can be the public key of a network node. For example, the public key can be an IP address, such as... Figure 1 The IP address of UE 1203 is shown. At step 720, in response to this transmission, the miner can receive a pair of trust values ​​and a second pseudonym from the network node from a trusted execution environment (such as Trust Core 603). The second pseudonym is an updated pseudonym used to replace the first pseudonym of the network node. The second pseudonym has been verified by the trusted execution environment based on the first pseudonym. Then, at step 730, the miner node generates a new block with the pair of trust values ​​and the second pseudonym of the network node, so that the latest valid link of the network node's trust values ​​and pseudonym can be announced.

[0117] Figure 8 The illustration depicts a method 800 for pseudonym updating and blockchain announcements according to embodiments of the present disclosure. Method 800 can be performed by a network node or its agent (e.g., an authentication node), such as... Figure 6 The UE or UE agent 602 shown. At step 810, the network node or its agent sends the network node's latest pseudonym and new pseudonym to the trusted execution environment, such as... Figure 6 The trust core shown is used to update the latest pseudonym with the new pseudonym in the blockchain. The latest pseudonym and the new pseudonym can be signed with the private key corresponding to the latest pseudonym so that it can be verified by a trusted execution environment with the latest pseudonym.

[0118] Figure 9 The illustration depicts a method 900 for pseudonym updating and blockchain announcements according to embodiments of the present disclosure. Method 900 can be executed by a trusted execution environment, such as... Figure 6 The Trust Core 603 is shown. At step 910, the Trusted Execution Environment receives the latest pseudonym and new pseudonym from the authentication node or network node (such as a UE or UE agent 602). The latest pseudonym and new pseudonym can be signed with the private key corresponding to the latest pseudonym. At step 920, the Trusted Execution Environment verifies the latest pseudonym and new pseudonym based on the latest pseudonym. At step 930, the Trusted Execution Environment receives the latest pseudonym and new pseudonym from the miner node (such as...). Figure 6 Miner 601 receives a pair of trust values ​​and the latest pseudonym from the network node. In response, at step 940, the trusted execution environment replaces the latest pseudonym in the pair with the new pseudonym. Next, at step 950, the trusted execution environment sends the pair of trust values ​​and the new pseudonym from the network node to the miner node so that the pair of trust values ​​and the new pseudonym from the network node can be announced through the next block of the blockchain.

[0119] Anonymous cross-domain authentication

[0120] When a user (or a user's UE) switches between different networks or network domains within a unified network, for data security and user privacy reasons, the authentication node of their home network cannot share their identity information with other networks. Therefore, this disclosure proposes a blockchain-based cross-domain pseudonym authentication mechanism to enable the authentication node of a TCND to authenticate the identity of a user on another TCND.

[0121] Figure 10 The illustration depicts an example process 10000 for anonymous cross-domain authentication. As shown in step 10100, when UE 10001 registers with authentication node 10002 of its home network (e.g., denoted as TCND1), the UE can obtain an anonymous trusted identity certificate from authentication node 10002. This certificate can specify communication permissions for UE 10001. For example, communication permissions can indicate whether the UE is permitted to perform cross-domain communication, the level or authority of permitted cross-domain communication, etc.

[0122] Authentication node 10002 can send security parameters to the blockchain required to verify the legitimacy of UE 10001. In this regard, at step 10200, authentication node 10002 can send the security parameters issued for UE 10001 to miner 10003 in TCND1. The security parameters can be recorded and announced in the blockchain of blockchain system 10006, as shown in step 10300.

[0123] When UE 10001 switches to a foreign network (represented as TCDN2), it sends its trusted identity certificate to the authentication node or edge authentication node 10005 of the switched foreign network (TCND2), as shown in step 10400. The authentication node or edge authentication node 10005 can retrieve security parameters for UE 10001 from the blockchain of the blockchain system (e.g., from miner 10004 in TCND2). The authentication node or edge authentication node 10005 can then use the security parameters to verify the validity of UE 10001's certificate and the specified communication permissions.

[0124] This enables the authentication of network nodes and the authorization of services involved in various cross-domain communications. In this way, the response time for cross-domain authentication can be significantly reduced.

[0125] In this embodiment, when a network node is accessing the network or undergoing a handover, authentication of the network node can be performed at two levels: user identity authentication and user trust authentication. In this regard, in addition to methods such as those described in the reference... Figure 10 In addition to using security parameters to authenticate the user's identity and the legitimacy of the UE's identity, as shown, the verification node 10005 can further authenticate the UE's trust. For example, the verification node 10005 can retrieve the UE's trust value from the blockchain and check whether the trust value meets predefined standards. In this way, valid users can be identified and network security intrusions can be blocked.

[0126] Similarly, UE 10001 can also be used by using, as referenced Figure 10 The method shown is similar to that used to authenticate the validity of external TCND nodes (such as authentication node 10005). Therefore, mutual authentication can be achieved.

[0127] The following describes one method for implementing user authentication:

[0128] Let G i (i=1, 2, ..., I) is a prime order p i The multiplicative cyclic group, g i It is G i A generator. An efficient, computable bilinear mapping defined on two groups. Satisfies the basic properties of bilinear pairing:

[0129] - Bilinear: For all a, b ∈ Zp, there exists e(g i a g i b ) = e(g i ; g i )ab

[0130] - Non-degeneracy: e(g i ; g i ) ≠ 1

[0131] - Computability: for any u, v ∈ G i There exists an efficient algorithm for calculating e(u; v).

[0132] Regarding G i System parameters can be tailored to specific networks (e.g., represented as TCND). i Use ) to set it.

[0133] For UE j,i UE belongs to TCND i TCND i The authentication node sends a message to the UE j,i Issue trusted identity certificate g i l / sj And correspondingly send a verification UE to the blockchain. j,i The corresponding security parameter required for the legality of (represented as g) i sj During cross-domain authentication, the authenticating node can access the blockchain to obtain g. i sj Then, the authentication node can calculate e(g). i sj ; g i l / sj ) = e(g i ; g i ) l In order to know the UE j,i The permission level. If the UE j,i If the permission level is determined by the protocol regarding cross-domain network access, then the access will be sent to the UE with the corresponding permission level. j,i .

[0134] Here, the safety parameter g i sj It is recorded in the blockchain. G i (i = 1, 2, …, I), p i and e(g) i ; g i ) l It can be pre-stored in the authentication node of each network domain.

[0135] Figure 11 The diagram illustrates method 11000 for anonymous cross-domain authentication. Method 11000 can be executed by the authentication node, such as... Figure 10The authentication nodes 10002 and 10005 are shown in the diagram. At step 11100, the authentication node in the first communication network can assign a certificate to a first network node in the first communication network. The first communication network can be the home network of the first network node. At step 11200, the authentication node can send the security parameters of the network node to the miner nodes of the blockchain system so that the security parameters can be recorded in a block of the blockchain system. At step 11300, the authentication node can receive a certificate for a second network node in the second communication network. The second network node is switching from a different network to the first communication network. Then, as shown in step 11400, the authentication node can extract the security parameters of the second network node from the block. In this respect, the security parameters of the second network node can be recorded in a block by another authentication node in the home network of the second network node. By utilizing the security parameters of the second network node, the authentication node can verify the validity of the second node's certificate.

[0136] Decentralized key management based on blockchain

[0137] Most traditional key management schemes for heterogeneous networks are based on a centralized certification authority. The certification authority is responsible for managing and coordinating the key generation, distribution, storage, updating, and revocation for each TCND.

[0138] This disclosure proposes a scheme for decentralized key management based on blockchain. In this scheme, each authentication node in the network can connect through the blockchain system, replacing the traditional central certification authority. This avoids the collapse of the entire network's key management due to attacks on the central certification authority.

[0139] In this embodiment, each network's authentication node can generate system security parameters and public-private key pairs for the corresponding network, and publish the public key of the system security parameters and public-private key pairs on the blockchain, so that each network's system security parameters and public key can be shared with nodes in other networks through the blockchain. Furthermore, each authentication node in the network can publish the user's (or UE's) public key on the blockchain, so that any node in a heterogeneous network can quickly retrieve the corresponding user's public key. In one example, the UE can generate a public-private key pair corresponding to the user's or UE's public key and provide the public key from the UE to the authentication node. In another example, the authentication node can generate a public-private key pair corresponding to the user's or UE's public key when the user or UE registers with the network.

[0140] When system security parameters, network public-private key pairs, or user or UE public-private keys are updated or revoked, the authentication node regenerates or revokes the corresponding security parameters and keys and promptly publishes them. Security parameters and public keys in the blockchain can be updated through a process similar to that described for updating pseudonyms. In this process, by generating the next block, unified and efficient management of key generation, distribution, storage, updating, and revocation can be achieved through miner consensus.

[0141] End-to-end security

[0142] In embodiments of this disclosure, the security and integrity of IP packets are protected by designing blockchain-based IKE and IPSec protocols within an integrated network. In this regard, public security parameters and algorithm information for cross-domain secure channels can be recorded on the blockchain. An exemplary implementation is described below and... Figure 12 As shown in the image.

[0143] Figure 12 The illustration shows an example process 12000 for establishing end-to-end security in an integrated network. In the example, end-to-end communication will be established between a source UE (represented as UE1 12001) in one network (represented as TCND1) and a destination UE (represented as UE2 12005) in another network (represented as TCND2).

[0144] At step 12020, the authentication node 12002 of TCND1 can contact the trust core 12003 of the blockchain system 12006 to send the public key of UE1 for end-to-end security of the session between UE1 and UE2. At step 12020, the identifier of UE2 (e.g., the ID of UE2) can be sent along with the public key of UE1. For privacy purposes, the public key can be encrypted using the private key of UE1's home domain (e.g., TCND1).

[0145] At step 12040, the trust core 12003 may notify the destination authentication node (e.g., authentication node 12004) of the destination UE2 12005 to pass the public key of the destination UE2 12005 to the trust core 12003. In response, the public key of the destination UE2 12005 is sent to the trust core 12003, as shown at step 12050. For privacy protection purposes, the public key of UE2 is also encrypted with the private key of the home domain of UE2 (e.g., TCND2).

[0146] At step 12060, the trust core 12003 can generate a secret and treat it as the session key for the end-to-end session between the two communication nodes UE1 and UE2;

[0147] At step 12070, the trust core 12003 can access the blockchain of the blockchain system 12006 to retrieve relevant system parameters (e.g., the public keys of the home domains TCND1 and TCND2 of the two UEs); decrypt the encrypted public key of UE1 with the public key of TCND1, and decrypt the encrypted public key of UE2 with the public key of TCND2; then, encrypt the session key with the public keys of the two UEs respectively.

[0148] Then, Trust Core 12003 distributes the protected session key to UE1 and UE2. As shown in step 12080, Trust Core 12003 can send the session key encrypted with UE1's public key to Authentication Node 12002. Next, in step 12090, Authentication Node 12002 can forward the encrypted session key to UE1. As shown in step 12100, Trust Core 12003 can send the session key encrypted with UE2's public key to Authentication Node 12004. Next, Authentication Node 12004 can forward the encrypted session key to UE2 12005.

[0149] Then, both terminal UEs obtain a session key. The session key is encrypted using the corresponding UE's public key. Only the UE holding the corresponding private key can decrypt the encrypted session key. As shown in step 12120, UE1 can decrypt the received encrypted session key using its private key and thus obtain the session key. In step 12130, UE2 can decrypt the received encrypted session key using its private key and thus obtain the same session key. They can then use the same session key to protect their end-to-end communication, as shown in step 12140. However, other parties (including miners, the server executing the trust core on it, and the authentication node of each UE) cannot know the session key. Therefore, end-to-end communication security can be achieved. Simultaneously, due to the protection of the trust core, the server containing the trust core cannot know who will communicate with each other.

[0150] Alternatively, a group session key can be generated in a similar manner by sharing session keys with multiple UEs using a trust core. In an embodiment, the authentication node of the source UE can send a group session identifier to the trust core 12003 to indicate that a group session key is required. For example, at step 12020, the authentication node 12002 can send a set of group IDs identifying the session group and the UE IDs of multiple destination UEs in the group. Then, in a manner similar to that shown in steps 12040 and 12050, the trust core can notify the corresponding authentication nodes of these destination UEs to pass the public keys of these destination UEs to the trust core. The received public keys of the multiple UEs in the group are encrypted using the private keys of the corresponding TCNDs of these UEs. The trust core can decrypt these encrypted public keys using the corresponding public keys of the respective TCNDs. The group session key can be encrypted separately using the public key of each UE and then sent to the corresponding UE.

[0151] In this embodiment, the trust core can also generate multiple session keys for different UE pairs simultaneously. To support large-scale communication, multiple trust cores with the same functionality can be established on different servers to process the above-mentioned processing tasks in parallel.

[0152] In process 12000, the authentication node of each TCND can know the public key of the UE in the corresponding TCND. For example, at steps 12010 and 12020, the public keys of UE1 and UE2 can be sent to their authentication nodes 12002 and 12004, respectively. The public key of the UE can be the UE's IP address or real identifier, or it can be the public key of the underlying link, such as a pseudonym.

[0153] Figure 13 The illustration depicts a method 13000 for establishing end-to-end security according to an embodiment of the present disclosure. Method 13000 can be performed by an authentication node, such as... Figure 12 The authentication nodes 12002 and 12004 are shown. At step 13100, the authentication node (e.g., authentication node 12002) of the first communication network (e.g., TCND1) sends the encrypted public key of the first network node (e.g., UE112001) to the trusted execution environment (e.g., trust core 12003) of the blockchain system (e.g., blockchain system 12006). The public key of the network node is encrypted with the private key from the public-private key pair of the first communication network. At step 13200, the authentication node receives an encrypted session key for protecting communication between the first network node and at least one second network node (e.g., UE2 12005) in at least one second communication network (e.g., TCND2) in the integrated network. The session key is encrypted with the public key of the first network node. Then, at step 13300, the authentication node sends the encrypted session key to the first network node.

[0154] In an embodiment, the authentication node may further receive a request from the trusted execution environment for providing the public key of the first network node of the first communication network, as shown at step 13400. In response to this request, the public key of the first network node of the first communication network is sent to the trusted execution environment.

[0155] Figure 14 The illustration depicts a method 14000 for establishing end-to-end security according to an embodiment of the present disclosure. Method 14000 can be executed by a trusted execution environment of a blockchain system (such as blockchain system 12006), such as... Figure 12 The Trust Core 12003 shown is used. A Trusted Execution Environment (TEE) can be installed and run on a server. At step 14100, the TEE receives an encrypted public key from a first authentication node (e.g., authentication node 12002) in a first communication network (e.g., TCND1) of a first network node (e.g., UE1 12001). The public key of the first network node is encrypted with the private key of the first communication network. At step 14200, the TEE receives an encrypted public key from at least one second network node (e.g., UE2 12005) in at least one second communication network (e.g., TCND1) of a corresponding authentication node (e.g., authentication node 12004). The public key of that second network node is encrypted with the private key of the communication network of that second network node.

[0156] At step 14300, the trusted execution environment generates a session key for communication between the first network node and at least one second network node.

[0157] At step 14400, the trusted execution environment extracts the public key of the first communication network and the public key of at least one second communication network from the blocks of the blockchain of the blockchain system.

[0158] At step 14500, the trusted execution environment decrypts the encrypted public key of the first network node using the public key of the first communication network, and decrypts the encrypted public key of each of at least one second network node using the public key of the corresponding communication network.

[0159] At step 14600, the trusted execution environment sends a session key encrypted with the public key of the first network node to the first network node, for example, via the first authentication node. At step 14700, the trusted execution environment sends a session key encrypted with the corresponding public key of each of the at least one second network node to each of the at least one second network node.

[0160] 3. Trusted Routing

[0161] Different routers exhibit varying quality and efficiency for intelligent message transmission. Security threats and attacks exist against routes in HetNet. Therefore, trust assessment of routes becomes crucial for guiding route selection. This disclosure proposes a routing scheme based on path trust, quality, and efficiency of intelligent message transmission. Figure 15 The diagram illustrates the process of trusted routing in a comprehensive network.

[0162] As shown in step 15100, process 15000 proves the trustworthiness of at least one monitoring node. In an embodiment, the trustworthiness of the monitoring node can be remotely proven by a blockchain system. For example, a trust guarantee mechanism based on trusted computing or SGX technology can be used to ensure the trustworthiness of data collected at the monitoring node.

[0163] As shown in step 15200, the monitoring node monitors the performance of routers in the network. In this example, the trusted monitoring node can observe various performance parameters of the network routers, such as throughput, latency, packet loss rate, and content retransmission rate, and provide these observations to the miners.

[0164] As shown in step 15300, the trust value of a router is evaluated based on observations. In the example, miners can evaluate the trust of each router based on its performance in terms of availability, quality optimization, and efficiency. Its level of trust (indicated by a trust value, for example) is recorded in the blockchain through block consensus.

[0165] As shown in step 15400, routing can be performed by the routing node based on the trust level of the evaluated router. Figure 16 An exemplary method 16000 for trust-based routing is illustrated. In the example, the routing node can query the blockchain to aggregate trust values. Figure 16 As shown, at step 16100, it can obtain a block of the blockchain from a miner or an authentication node. At step 16200, the routing node can extract the trust values ​​of routers along candidate routes from the block. Candidate routes can traverse several networks or TCNDs. In this embodiment, the authentication node can map the IP address of each router to its pseudonym and request the miner to retrieve the current trust value of the router.

[0166] At step 16300, the routing node may select a route based on a trust value used for the router. In an embodiment, the routing node may calculate the trust value of a candidate route based on the trust values ​​of routers along the candidate route, as shown at step 16400. For example, the trust value used for the candidate route may be the average of the trust values ​​of all routers along the candidate route. Candidate routes with higher average trust values ​​may be preferentially selected.

[0167] The embodiments disclosed herein have the following advantages:

[0168] Decentralization: The trust management platform can achieve decentralized HetNet network management by applying blockchain technology. The embodiments of this disclosure are applicable to integrated HetNet systems where no single party can be fully trusted.

[0169] High fault tolerance / failure tolerance: Embodiments of this disclosure can avoid single points of failure. Even if a part of the blockchain system is attacked or malfunctions, the blockchain system can still operate in a trustworthy manner. Therefore, it can support highly fault-tolerant networking.

[0170] Information consistency and tamper resistance: Embodiments of this disclosure record information shared among different certified nodes in a consensus-based blockchain throughout the integrated network, thereby ensuring the consistency of shared information. The tamper-resistant nature of blockchain inherently ensures the trustworthiness of blockchain data.

[0171] Traceability and non-repudiation: All sensitive and important data (e.g., AAA-related data) is recorded in the blockchain. In the event of any liability dispute, the information recorded in the blockchain can provide sufficient evidence.

[0172] Rich Network Functionality: Compared to traditional network functions, embodiments of this disclosure can support many novel functions. Some of these are listed below:

[0173] 1) Efficient cross-domain authentication and authorization. In the embodiments of this disclosure, the UE's authorization and authentication information can be recorded in the blockchain and pre-loaded onto each authentication node, or it can be stored at the edge nodes of the network or domain. Therefore, the UE's cross-domain authentication process does not require access to the authentication node of its home network. Thus, the embodiments of this disclosure can simplify the authentication process and reduce communication overhead.

[0174] 2) Cross-domain communication privacy protection. Embodiments of this disclosure do not allow non-home networks to obtain the UE's true identity information and can achieve anonymous identity authentication through blockchain. Therefore, the UE's privacy can be protected. Furthermore, with the help of a trust core, secure end-to-end cross-domain communication can be achieved.

[0175] 3) Easy billing. After the UE's billing information is written to the blockchain, regular payment settlement for each network domain can be easily achieved.

[0176] 4) Supports forward compatibility and backward scalability. The blockchain-based trust management platform does not affect the authentication, authorization, and billing mechanisms of traditional networks, but plays a crucial role in cross-domain communication. It supports forward compatibility and is also suitable for backward scalability by supporting the integration of new features into the comprehensive HetNet.

[0177] Figure 17 An apparatus 1700 is illustrated thereon on which embodiments of the present disclosure may be implemented. Although apparatus 1700 is depicted with respect to a particular device or apparatus, it is conceivable that... Figure 17 Other devices or apparatuses within the system (e.g., miner nodes, authentication nodes, network nodes, servers executing trusted execution environments thereon, etc.) may deploy the hardware and components shown in system 1700. Apparatus 1700 is designed and programmed (e.g., via computer program code or instructions) for trust management in an integrated network as described herein, and includes communication mechanisms, such as bus 1710, for transferring information between other internal and external components of apparatus 1700. Information (also referred to as data) is represented as a physical expression of a measurable phenomenon, typically voltage, but in other embodiments, includes phenomena such as magnetic, electromagnetic, pressure, chemical, biological, molecular, atomic, subatomic, and quantum interactions. Apparatus 1700, or a portion thereof, constitutes an apparatus in a virtualized network for performing one or more steps of security and trust technologies and solutions.

[0178] Bus 1710 includes one or more parallel information conductors to enable rapid information transfer between devices coupled to bus 1710. One or more processors 1702 for processing information are coupled to bus 1710.

[0179] Processor 1702 executes a set of operations on information specified by computer program code in relation to decentralized trust assessment in a distributed network as described herein. Computer program code is a set of instructions or statements that provide instructions for the operation of the processor and / or computer system to perform a specified function. For example, the code can be written in a computer programming language that is compiled into the processor's native instruction set. Code can also be written directly using a native instruction set, such as machine language. This set of operations includes introducing information from bus 1710 and placing information on bus 1710. This set of operations typically also includes comparing two or more units of information, moving the position of units of information, and combining two or more units of information such as by addition or multiplication or logical operations such as "OR", "XOR", and "AND". Each of the operations in this set that can be executed by the processor is represented to the processor by information called an instruction (such as an opcode of one or more numbers). The series of operations to be executed by processor 1702 (such as a series of opcodes) constitutes processor instructions, also known as computer system instructions or simply computer instructions. Processors can be implemented individually or in combination as mechanical, electrical, magnetic, optical, chemical, or quantum components, etc.

[0180] Device 1700 also includes a memory 1704 coupled to bus 1710. Memory 1704 (such as random access memory (RAM) or other dynamic storage devices) stores information including processor instructions for decentralized trust assessment in a distributed network as described herein. Dynamic memory allows information stored therein to be modified by device 1700. RAM allows information units stored at locations referred to as memory addresses to be stored and retrieved independently of information at adjacent addresses. Memory 1704 is also used by processor 1702 to store temporary values ​​during the execution of processor instructions. Device 1700 also includes a read-only memory (ROM) 1706 or other static storage device coupled to bus 1710 for storing static information, including instructions, that is not modified by device 1700. Some memories consist of volatile storage devices, which lose the information stored thereon when power is lost. Coupled to bus 1710 is a non-volatile (permanent) storage device 1708, such as a disk, optical disk, or flash memory card, for storing information, including instructions, that persists even when device 1700 is turned off or otherwise powered off.

[0181] Information, including instructions for trust management in the integrated network as described herein, is provided from external input device 1712 (such as a keyboard or sensor containing alphanumeric keys operated by a human user) to bus 1710 for use by the processor. Other external devices coupled to bus 1710 primarily for human interaction include display device 1714, such as a cathode ray tube (CRT) or liquid crystal display (LCD), or a plasma screen or printer for displaying text or images, and pointing device 1716, such as a mouse or trackball or cursor arrow keys or motion sensor, for controlling the position of a small cursor image displayed on display 1714 and issuing commands associated with graphical elements displayed on display 1714. In some embodiments, such as in the embodiment where device 1700 performs all functions automatically without human input, one or more of external input device 1712, display device 1714, and pointing device 1716 are omitted.

[0182] In the illustrated embodiment, dedicated hardware, such as an application-specific integrated circuit (ASIC) 1720, is coupled to bus 1710. The dedicated hardware is configured to perform operations not performed by processor 1702 at a sufficiently high speed for a specific purpose. Examples of dedicated ICs include graphics accelerator cards for generating images for display 1714, cryptographic pads for encrypting and decrypting messages sent over a network, speech recognition, and interfaces with specialized external devices, such as robotic arms and medical scanning devices that repeatedly execute complex sequences of operations that are more efficiently implemented in hardware.

[0183] The apparatus 1700 also includes one or more instances of a communication interface 1770 coupled to the bus 1710. The communication interface 1770 provides one-way or two-way communication coupling with various external devices, such as printers, scanners, and external disks, that operate with their own processors. Typically, the coupling is a network link to a local network to which various external devices, each with its own processor, are connected. For example, the communication interface 1770 may be a parallel port, a serial port, or a Universal Serial Bus (USB) port on a personal computer. In some embodiments, the communication interface 1770 is an Integrated Services Digital Network (ISDN) card, a Digital Subscriber Line (DSL) card, or a telephone modem providing information communication connectivity to a corresponding type of telephone line. In some embodiments, the communication interface 1770 is a cable modem that converts signals on the bus 1710 into signals for communication connections via coaxial cables or optical signals for communication connections via fiber optic cables. As another example, the communication interface 1770 may be a Local Area Network (LAN) card to provide data communication connectivity to a LAN-compatible network, such as Ethernet. A wireless link may also be implemented. For wireless links, communication interface 1770 transmits or receives, or transmits and receives, electrical, acoustic, or electromagnetic signals, including infrared and optical signals, that carry information streams such as digital data. For example, in wireless handheld devices (such as mobile phones, like cellular phones), communication interface 1770 includes a radio-band electromagnetic transmitter and receiver, referred to as a radio transceiver. In some embodiments, communication interface 1770 enables connection to virtualized networks used for decentralized trust evaluation in distributed networks as described herein.

[0184] As used herein, the term "computer-readable medium" means any medium that participates in providing information (including instructions for execution) to processor 1702. Such media can take many forms, including but not limited to computer-readable storage media (e.g., non-volatile media, volatile media) and transmission media. Non-volatile media, such as optical discs or magnetic disks, such as storage device 1708, are examples of non-volatile media. Volatile media include, for example, dynamic memory. Transmission media include, for example, coaxial cables, copper wires, fiber optic cables, and carrier waves, such as sound waves and electromagnetic waves, including radio waves, light waves, and infrared waves, that travel through spaces without wires or cables. Signals include transient changes in amplitude, frequency, phase, polarization, or other physical characteristics transmitted through the transmission medium. Common forms of computer-readable media include, for example, floppy disks, floppy hard disks, magnetic tapes, any other magnetic media, CD-ROMs, CDRWs, DVDs, any other optical media, punched cards, paper tapes, optical marking sheets, any other physical media with perforated patterns or other optically identifiable markings, RAM, PROMs, EPROMs, FLASH-EPROMs, any other memory chips or cartridges, carrier waves, or any other media that a computer can read. As used herein, the term computer-readable storage medium refers to any computer-readable medium other than a transmission medium.

[0185] Logic encoded in one or more tangible media includes one or both of processor instructions on a computer-readable storage medium and special-purpose hardware such as ASIC 1720.

[0186] At least some embodiments of this disclosure relate to using apparatus 1700 to implement some or all of the techniques described herein. According to one embodiment of this disclosure, these techniques are executed by apparatus 1700 in response to processor 1702 executing one or more sequences of one or more processor instructions contained in memory 1704. Such instructions (also referred to as computer instructions, software, and program code) may be read into memory 1704 from another computer-readable medium, such as storage device 1708 or a network link. Execution of the sequence of instructions contained in memory 1704 causes processor 1702 to perform one or more method steps described herein. In alternative embodiments, hardware such as ASIC 1720 may be used instead of or in combination with software to implement the invention. Therefore, embodiments of the invention are not limited to any particular combination of hardware and software unless expressly stated otherwise herein.

[0187] Signals transmitted via communication interface 1770 over network links and other networks carry information to and from device 1700. Device 1700 can send and receive information, including program code, via the network and communication interface 1770. The received code can be executed by processor 1702 upon receipt, or stored in memory 1704 or storage device 1108 or other non-volatile memory for later execution, or both. In this way, device 1100 can acquire application code in the form of signals on a carrier wave.

[0188] Figure 18 The illustration shows a chipset or circuitry 1800 on which embodiments of the present disclosure may be implemented. The chipset 1800 is programmed for trust management in an integrated network as described herein, and includes, for example, information incorporated in one or more physical packages (e.g., chips). Figure 18 The processor and memory components described. As an example, a physical package includes the arrangement of one or more materials, components, and / or wires on a structural component (e.g., a baseline board) to provide one or more characteristics, such as physical strength, dimensional protection, and / or limitation of electrical interactions. It is envisioned that in some embodiments, a chipset may be implemented in a single chip. Chipset 1800 or a portion thereof constitutes means for performing one or more steps of performing multiple forms of communication in the same communication session.

[0189] In one embodiment, chipset 1800 includes a communication mechanism, such as bus 1801, for transferring information between elements of chipset 1800. Processor 1803 is connected to bus 1801 to execute instructions and process information stored, for example, in memory 1805. Processor 1803 may include one or more processing cores, each configured to execute independently. Multi-core processors enable multiprocessing within a single physical package. Examples of multi-core processors include two, four, eight, or more processing cores. Alternatively or additionally, processor 1803 may include one or more microprocessors configured to execute instructions independently, pipelined, and multithreaded via bus 1801. Processor 1803 may also be accompanied by one or more dedicated components, such as one or more digital signal processors (DSPs) 1807 or one or more application-specific integrated circuits (ASICs) 1809, to perform specific processing functions and tasks. DSP 1807 is typically configured to process real-world signals (e.g., sound) in real time independently of processor 1803. Similarly, the ASIC 1809 can be configured to perform special-purpose functions that are not easily performed by general-purpose processors. Other special-purpose components that help perform the functions of the invention described herein include one or more field-programmable gate arrays (FPGAs) (not shown), one or more controllers (not shown), or one or more other special-purpose computer chips.

[0190] Processor 1803 and accompanying components are connected to memory 1805 via bus 1801. Memory 1805 includes both dynamic memory (e.g., RAM, disk, writable optical disc, etc.) and static memory (e.g., ROM, CD-ROM, etc.) for storing executable instructions that, when executed, perform the inventive steps described herein to perform various forms of communication within the same communication session. Memory 1805 also stores data associated with or generated by the execution of the inventive steps.

[0191] As used in this application, the term "circuit" refers to all of the following:

[0192] (a) Hardware circuit-only implementation (e.g., implementation using only analog and / or digital circuits).

[0193] (b) A combination of circuitry and software (and / or firmware), such as (if applicable): (i) a combination of (one or more) processors, or (ii) a combination of (one or more) processors / software (including (one or more) digital signal processors), software, and (one or more) memory working together to enable a device (such as a mobile phone or server) to perform various functions, and

[0194] (c) Circuits that require software or firmware to operate, such as one or more microprocessors or a portion thereof, even if the software or firmware does not actually exist.

[0195] The definition of "circuit" applies to all uses of the term in this application, including in any claim. As a further example, as used in this application, the term "circuit" also covers implementations of a processor (one or more) or a portion thereof and its accompanying software and / or firmware. For example, if applicable to a particular claimed element, the term "circuit" will also cover baseband integrated circuits or application processor integrated circuits for mobile phones, or similar integrated circuits in servers, cellular network devices, or other network devices.

[0196] The boxes shown in the diagram may represent steps in a method and / or code segments in a computer program. The illustration of a specific order of boxes does not necessarily imply a required or preferred order for the boxes, and the order and arrangement of the boxes can be varied. Furthermore, some boxes may be omitted.

[0197] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, element, segment, or portion of code, including at least one executable instruction for implementing a specified logical function(s). It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware or a combination of dedicated hardware and computer instructions that performs a specific function or action.

[0198] This disclosure includes any novel features or combinations of features expressly disclosed herein, or any generalization thereof. In view of the foregoing description, various modifications and adaptations to the foregoing exemplary embodiments of this disclosure will become apparent to those skilled in the art when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the non-limiting and exemplary-exemplary scope of the invention.

Claims

1. A method for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the method comprising: A (210) blockchain system is formed by a first miner node in a first communication network in the integrated network and a miner node in at least one second communication network in the integrated network; The first miner node authenticates the trusted execution environment as the trust core for the blockchain system. The first miner node obtains (220) a block of the blockchain of the blockchain system, wherein the block includes the identity of the previous block of the blockchain, the timestamp of generating the block, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data used to evaluate the trust value in the trust value list, wherein the trust value in the trust value list is based on the pseudonym of each network node. The block (230) is shared by the first miner node within the first communication network; Send a pair of trust values ​​and a first pseudonym from the first miner node to the trusted execution environment (710); In response to the transmission (710), the first miner node receives (720) a pair of trust values ​​and a second pseudonym of the network node from the trusted execution environment, wherein the second pseudonym is an updated pseudonym of the network node verified by the trusted execution environment based on the first pseudonym; and The first miner node generates (730) a block that includes the pair of trust values ​​and the second pseudonym of the network node.

2. A method for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the method comprising: The authentication node in the first communication network obtains (310) blocks of the blockchain system from the first miner node in the first communication network. The blockchain system is formed between the first miner node and miner nodes in at least one second communication network within the integrated network. The block of the blockchain includes the identity of the previous block of the blockchain, the timestamp of the block generation, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data used to evaluate the trust values ​​in the trust value list, wherein the trust values ​​in the trust value list are based on the pseudonyms of each network node. The authentication node extracts the trust value of the network node (320) from the block; and The authentication node sends (620) the latest pseudonym and new pseudonym of the network node to the trusted execution environment authentication certified by the first miner node, for use in updating the latest pseudonym in the next block. The latest pseudonym and the new pseudonym are signed by the private key corresponding to the latest pseudonym so that they can be verified by the trusted execution environment.

3. A method for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the method comprising: This enables (440) a trusted execution environment to be certified by one or more miner nodes in the blockchain system, wherein the blockchain system is constituted between miner nodes in a first communication network and at least one miner node in a second communication network in the integrated network. The trusted execution environment obtains blocks of the blockchain from the miner nodes in the blockchain system. The block of the blockchain includes the identity of the previous block of the blockchain, the timestamp of the block generation, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data used to evaluate the trust values ​​in the trust value list, wherein the trust values ​​in the trust value list are based on the pseudonyms of each network node. In the trusted execution environment, the latest pseudonym and new pseudonym of the network node in the first communication network, and the signature of the latest pseudonym and the new pseudonym signed by the private key corresponding to the latest pseudonym, are received from the network node or the authentication node acting as the agent of the network node (910). The trusted execution environment verifies (920) the signature of the latest received pseudonym and the new received pseudonym based on the latest pseudonym; In the trusted execution environment, a pair of trust values ​​and the latest pseudonym of the network node are received from the miner node (930); The trusted execution environment replaces the latest pseudonym in the pair (940) with the new pseudonym; and The trusted execution environment sends (950) a pair of trust values ​​and the new pseudonym of the network node to the miner node.

4. An apparatus for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the apparatus being a miner node, the apparatus comprising: At least one processor; as well as At least one memory including computer program code, the memory and the computer program code being configured, together with the processor, to cause the device to perform at least the following operations: The device in the first communication network of the integrated network and the miner node in at least one second communication network of the integrated network constitute a (210) blockchain system; The trusted execution environment is certified as the trust core for the blockchain system; Obtain (210) a block of the blockchain of the blockchain system, wherein the block includes the identity of the previous block of the blockchain, the timestamp of generating the block, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data for evaluating the trust value in the trust value list, wherein the trust value in the trust value list is based on the pseudonym of each network node. The block (230) is shared within the first communication network; Send (710) a pair of trust values ​​and a first pseudonym of the network node to the trusted execution environment; In response to the transmission (710), a pair of trust values ​​and a second pseudonym of the network node are received (720) from the trusted execution environment, wherein the second pseudonym is an updated pseudonym of the network node verified by the trusted execution environment based on the first pseudonym; and Generate (730) a block comprising the pair of trust values ​​and the second pseudonym of the network node.

5. The apparatus according to claim 4, wherein, The pseudonym of a network node is the public key of that network node.

6. The apparatus according to claim 4, wherein, The block further includes security parameters for at least one network node from the plurality of different communication networks.

7. The apparatus according to claim 6, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive security parameters from the first network node in the first communication network from the authentication node in the first communication network; as well as The security parameters of the first network node are recorded in the next block of the blockchain.

8. The apparatus according to claim 6, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Extract the security parameters of the second network node in the second communication network from the block; as well as The security parameters are sent to the authentication node in the first communication network to verify the validity of the certificate of the second network node.

9. The apparatus according to claim 4, wherein, The block further includes the public key of at least one network node from the plurality of different communication networks.

10. The apparatus according to claim 9, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive the public key from the public-private key pair of the first network node in the first communication network from the authentication node in the first communication network; as well as The public key of the first network node is recorded in the next block.

11. The apparatus according to claim 4, wherein, The block further includes system security parameters and public keys for at least one of the plurality of different communication networks.

12. The apparatus according to claim 11, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive the system security parameters of the first communication network and the public key from the public-private key pair from the authentication node of the first communication network; as well as The system security parameters and public key of the first communication network are recorded in the next block of the blockchain.

13. The apparatus according to claim 4, wherein, The at least one network node is a router, and the trust value of the router is associated with the routing performance of the router.

14. The apparatus according to claim 13, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive performance information indicating the routing performance of the router; Based on the performance information, assess the trust value of the router; as well as The trust value of the router is recorded in the next block of the blockchain.

15. The apparatus according to any one of claims 4 to 14, wherein, The block further includes information indicating cross-domain access and usage records after the previous block of the blockchain was generated, the cross-domain access and usage records being used to calculate the cost of cross-domain communication.

16. The apparatus according to any one of claims 4 to 14, wherein, The block further includes transactions that record communication costs across different networks in the integrated network.

17. An apparatus for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the apparatus being the authentication node, the apparatus comprising: At least one processor; as well as At least one memory including computer program code, the memory and the computer program code being configured, together with the processor, to cause the device to perform at least the following operations: Obtain the (310) blockchain block of the blockchain system from the first miner node in the first communication network. The blockchain system is formed between the first miner node and miner nodes in at least one second communication network within the integrated network. The block of the blockchain includes the identity of the previous block of the blockchain, the timestamp of the block generation, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data used to evaluate the trust values ​​in the trust value list, wherein the trust values ​​in the trust value list are based on the pseudonyms of each network node. Extract the trust value of the network node (320) from the block; and The latest pseudonym and new pseudonym of the network node are sent (620) to the trusted execution environment certified by the first miner node for updating the latest pseudonym in the next block. The latest pseudonym and the new pseudonym are signed by the private key corresponding to the latest pseudonym so that they can be verified by the trusted execution environment.

18. The apparatus according to claim 17, wherein, The pseudonym of the network node is the public key of the network node.

19. The apparatus according to claim 17, wherein, The block further includes security parameters for at least one network node from the plurality of different communication networks.

20. The apparatus according to claim 19, wherein, The memory and the computer program code are further configured to utilize the processor to further enable the device: Assign a certificate to the first network node in the first communication network; as well as Security parameters for verifying the certificate of the first network node are sent to the miner node so that the security parameters are recorded in the block of the blockchain.

21. The apparatus according to claim 19, wherein, The memory and the computer program code are further configured to utilize the processor to further enable the device: Receive the certificate of the second network node in the second communication network; Extract the security parameters of the second network node from the block; as well as The certificate of the second node is verified by using the security parameters of the second network node.

22. The apparatus according to any one of claims 17 to 21, wherein, The memory and the computer program code are further configured, together with the processor, to further enable the device: Extract the trust value of the second network node from the block; as well as The trust of the second network node is verified by using the trust value of the second network node.

23. The apparatus according to claim 17, wherein, The block further includes the public key of at least one network node from the plurality of different communication networks.

24. The apparatus according to claim 23, wherein, The memory and the computer program code are further configured, together with the processor, to further enable the device: Send the public key of the network node's public-private key pair to the miner node so that the network node's public key is recorded in the block.

25. The apparatus according to claim 17, wherein, The block further includes system security parameters and public keys for the multiple different communication networks.

26. The apparatus according to claim 25, wherein, The memory and the computer program code are further configured, together with the processor, to further enable the device: Generate system security parameters and public-private key pairs for the first communication network; The system security parameters and the public key from the public-private key pair are sent to the miner node so that the system security parameters and the public key of the first communication network are recorded in the block.

27. The apparatus according to claim 26, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: The encrypted public key of the first network node of the first communication network is sent to the trusted execution environment certified by the miner node, wherein the public key of the first network node is encrypted with the private key in the public-private key pair used for the first communication network. Receive an encrypted session key from the trusted execution environment to protect communication between the first network node and at least one second network node in at least one second communication network in the integrated network, wherein the session key is encrypted with the public key of the first network node; and The encrypted session key is sent to the first network node.

28. The apparatus according to claim 27, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Send the identifier of the at least one second network node to the trusted execution environment.

29. The apparatus according to claim 28, wherein, The communication is between the first network node and a plurality of second network nodes in the at least one second communication network, and wherein the memory and the computer program code are further configured, together with the processor, to enable the device to: Send a group identifier that identifies the group of the plurality of second network nodes to the trusted execution environment.

30. The apparatus according to claim 27, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive a request from the trusted execution environment certified by the miner node to provide the public key of the first network node of the first communication network; as well as In response to the request, the encrypted public key of the first network node is sent to the trusted execution environment.

31. The method according to claim 17, wherein, The at least one network node is a router, and the trust value of the router is associated with the routing performance of the router.

32. The apparatus according to claim 31, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Extract the trust values ​​of at least two routers along the candidate route from the block; as well as A route is selected based on the trust values ​​of the at least two routers.

33. The apparatus according to claim 32, wherein, The memory and the computer program code are further configured, together with the processor, to enable the device to select a route by: The trust value of the candidate route is calculated based on the trust value of the router along the candidate route.

34. An apparatus for trust management in an integrated network, the integrated network comprising multiple different communication networks, each of the multiple different communication networks comprising at least one miner node, at least one authentication node, and at least one network node, the apparatus being a trusted execution environment, the apparatus comprising: At least one processor; as well as At least one memory including computer program code, the memory and the computer program code being configured, together with the processor, to cause the device to perform at least the following operations: The trusted execution environment (440) is certified by one or more miner nodes in the blockchain system, wherein the blockchain system is constituted between miner nodes in the first communication network and at least the miner nodes in the second communication network in the integrated network. Obtain blocks of the blockchain from the miner nodes in the blockchain system; The block of the blockchain includes the identity of the previous block of the blockchain, the timestamp of the block generation, a trust value list containing the trust value of each network node in at least one of the multiple different communication networks, and a hash code for trust-related data used to evaluate the trust values ​​in the trust value list, wherein the trust values ​​in the trust value list are based on the pseudonyms of each network node. (910) Receive from a network node of the integrated network or an authentication node acting as an agent of the network node the latest pseudonym and new pseudonym of the network node in the first communication network, and the signature of the latest pseudonym and the new pseudonym signed by the private key corresponding to the latest pseudonym; The signatures of the latest and newest received pseudonyms are verified based on the latest pseudonyms (920); Receive a pair of trust values ​​and the latest pseudonym from the network node (930) from the miner node; Replace the latest kana in the pair (940) with the new kana; and Send (950) a pair of trust values ​​and the new pseudonym of the network node to the miner node.

35. The apparatus according to claim 34, wherein, The pseudonym of a network node is the public key of that network node.

36. The apparatus according to claim 35, wherein, The block further includes system security parameters and public keys for the multiple different communication networks.

37. The apparatus according to claim 36, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive the public key of the first network node encrypted with the private key of the first communication network in the plurality of communication networks from the first authentication node in the first communication network; Generate a session key for communication between the first network node and at least one second network node in the at least one second communication network; Extract the public key of the first communication network from the block; Decrypt the encrypted public key of the first network node using the public key of the first communication network; as well as Send the session key, encrypted with the public key of the first network node, to the first node.

38. The apparatus according to claim 37, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Send a request to the corresponding authentication node in the at least one second communication network to provide the corresponding public key of each of the at least one second network nodes; In response to the request, the corresponding encrypted public key of each of the at least one second network node is received from the corresponding authentication node, wherein the public key of the at least one second network node is encrypted with the private key of the communication network of the at least one second network node; Extract the corresponding public key from the block of the blockchain, which corresponds to the private key of the corresponding communication network of each of the at least one second network node; Decrypt the corresponding encrypted public key of each of the at least one second network node using the public key of the corresponding communication network; and An encrypted session key is sent to each of the at least one second network node, wherein the session key sent to the one of the at least one second network nodes is encrypted with the corresponding public key of the one of the at least one second network node.

39. The apparatus according to claim 37 or 38, wherein, The memory and the computer program code are further configured to, together with the processor, enable the device to: Receive the identifier of the at least one second network node from the first authentication node.

40. The apparatus according to claim 39, wherein, The communication is between the first network node and a plurality of second network nodes in the at least one second communication network, and wherein the memory and the computer program code are further configured, together with the processor, to enable the device to: Receive a group identifier from the first authentication node that identifies the group of the plurality of second network nodes.

41. A non-transitory computer-readable storage medium storing instructions that, when executed by the one or more processors, cause the processors to perform the method according to any one of claims 1 to 3.

Images