Patent Description:
Examples of mobile or wireless telecommunication systems may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro, and/or fifth generation (<NUM>) radio access technology or new radio (NR) access technology. <NUM> wireless systems refer to the next generation (NG) of radio systems and network architecture. <NUM> is mostly built on a new radio (NR), but a <NUM> (or NG) network can also build on E-UTRA radio. It is estimated that NR provides bitrates on the order of <NUM>-<NUM> Gbit/s or higher, and can support at least enhanced mobile broadband (eMBB) and ultra-reliable low-latency-communication (URLLC) as well as massive machine type communication (mMTC). NR is expected to deliver extreme broadband and ultra-robust, low latency connectivity and massive networking to support the Internet of Things (IoT). With IoT and machine-to-machine (M2M) communication becoming more widespread, there will be a growing need for networks that meet the needs of lower power, low data rate, and long battery life. The next generation radio access network (NG-RAN) represents the RAN for <NUM>, which can provide both NR and LTE radio access. It is noted that, in <NUM>, the nodes that can provide radio access functionality to a user equipment (i.e., similar to Node B in UTRAN or eNB in LTE) may be named gNB when built on NR radio and may be named NG-eNB when built on E-UTRA radio.

<CIT> relates to a security mechanism for a distributed data processing system. Each server in the system maintains a set of security ratings giving its view of the security levels within the system. When a first server wishes to initiate a connection with a second server, the two servers exchange security information, by means of messages, so as to establish an overall security level for the connection, based on a combination of the security information maintained by both servers. However, if the first server decides that the second server cannot be trusted to discuss security, messages are exchanged containing no security information, and each server establishes its own security level for the connection, based on its own locally held security information.

In accordance with some embodiments, a method includes creating an adaptive trust model, by a trust model adaptor of an apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The method further includes applying security controls between the apparatus and the other apparatus.

In accordance with some embodiments, an apparatus includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to at least create an adaptive trust model, by a trust model adaptor of the apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to at least apply security controls between the apparatus and the other apparatus.

Further the apparatus includes means for creating an adaptive trust model, by a trust model adaptor of an apparatus, configured to establish a trust relationship with another apparatus according to a composition of trust of the other apparatus and a composition of trust of the apparatus. The apparatus further includes means for applying security controls between the apparatus and the other apparatus.

In accordance with some embodiments, a non-transitory computer readable medium is encoded with instructions that may, when executed in hardware, perform a method. The method creates an adaptive trust model, by a trust model adaptor of the apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The method further applies security controls between the apparatus and the other apparatus.

In accordance with some embodiments, a method includes creating an adaptive trust model, by a trust model adaptor of an apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The method further includes applying security controls between the apparatus and the other apparatus. The method further includes receiving, from the other apparatus, an indication of a change on the other apparatus. The method further includes deriving a new trust model and establish a new trust relationship to reflect a new composition of trust based on the change.

In accordance with some embodiments, an apparatus includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus to at least create an adaptive trust model, by a trust model adaptor of the apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to at least apply security controls between the apparatus and the other apparatus. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus to at least receive, from the other apparatus, an indication of a change on the other apparatus. The at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to at least derive a new trust model and establish a new trust relationship to reflect a new composition of trust based on the change.

In accordance with some embodiments, an apparatus includes means for creating an adaptive trust model, by a trust model adaptor of an apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The apparatus further includes means for applying security controls between the apparatus and the other apparatus. The apparatus further includes means for receiving, from the other apparatus, an indication of a change on the other apparatus. The apparatus further includes means for deriving a new trust model and establish a new trust relationship to reflect a new composition of trust based on the change.

In accordance with some embodiments, a non-transitory computer readable medium may be encoded with instructions that may, when executed in hardware, perform a method. The method may create an adaptive trust model, by a trust model adaptor of the apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The method may further apply security controls between the apparatus and the other apparatus. The method may further receive, from the other apparatus, an indication of a change on the other apparatus. The method may further derive a new trust model and establish a new trust relationship to reflect a new composition of trust based on the change.

It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for implementing adaptive mutual trust models for dynamic and diversity multi-domain networks, is not intended to limit the scope of certain embodiments but is representative of selected example embodiments.

Additionally, if desired, the different functions or procedures discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the following description should be considered as merely illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

<FIG> shows an example <NUM> ecosystem <NUM> and its technological breakthroughs, such as Network Slicing, software-driven and service-based architecture, which allows new business models and value creation across multiple industry domains <NUM>, including verticals, mobile network operators, infrastructure service providers, and application providers.

The disruptive deployment of <NUM> network triggers the need for network transformation and radical change in the way networks and services are managed and orchestrated. <FIG> shows an example of a Zero-touch Service and Network Management (ZSM) <NUM>, which is a full end-to-end automation of network and service management framework and solutions, that was designed to manage and orchestrate the future service and network including <NUM> network.

Mutual Trust should be established between entities inside a domain or inter different domains, before they interact with each other for service booking and consuming, as well as service, network management, and orchestration, to ensure confidentially, integrity, availability, and regulation compliance of each entity.

To build trust relationship between different entities, traditionally, there are several trust models defined to establish trust relationship between different entities that allow one entity to obtain the levels of trust needed to form partnerships, collaborate with other organizations, share information, or receive information/services. The conventional trust models were defined in NIST800-<NUM> including validated trust, direct historical trust, mediated trust, mandated trust, and hybrid trust. Further, European Telecommunication Standard Institute (ETSI) Network Function Virtualization (NFV) decomposed transitive trust to several more granular models such as direct delegated trust, collaborative trust, transitive trust, and reputational trust. Those trust models can be applied to statically to various entities to build different levels of trust.

ETSI NFV introduced a concept of dynamics. However, it still focused on the relationship between VNF and serving virtual infrastructure, and always took virtual infrastructure components (e.g. TPM on HW), Management and Orchestration (MANO) entities, or Certificate Authorities (CA) as trust root to build static transitive/collaborative trust models for VNF or MANO entities. Therefore, NFV did not provide a solution to handle potential trust model transformation because of the dynamics of a NFV ecosystem.

<FIG> illustrates the openness of a <NUM> ecosystem <NUM> which involved players from multiple industry domains <NUM>, like enterprise, finance, governments, web-scale, operator, and cloud provider. The trust levels required by different domains vary, and the trust levels of the same domain in different context can also be different. In addition, a cloud native service-based architecture is adopted by ZSM to facilitate fast deployment and update of the service to satisfy the diversity requirements from various vertical customers. The trust context and relationship between management functions of same domain or different domains could change dynamically along with the change of the management function itself, its consumer or its producer.

The dynamics and diversity of the <NUM> network and ZSM framework, cause the existing trust models, either single trust model or a combination of multiple trust models, to be inadequate to ensure confidentiality, integrity, and availability of the <NUM> network and ZSM services and data.

<FIG> shows as an example of the trust relationship <NUM> between Management Function (MnF) C1 <NUM> in <NUM> Core Management Domain (MnD) <NUM> and MnF V1 <NUM> in NFV MnD <NUM> in which a trust relationship between MnF R1 <NUM> in <NUM> RAN MnD <NUM> and MnF V1 <NUM> in NFV MnD <NUM> can be different because the trust capability and assurance of <NUM> Core MnD <NUM> and <NUM> RAN MnD <NUM> are different. In addition, the trust relationship between MnF C1301 and MnF V1303 can be changed from time to time as the change of MnFs (e.g. operational status and security postures of the MnF, package upgrade to support new features, scale to other region, etc.), its service consumers (e.g. new consumer from a new industry domain, such as webscale), and its service producers (e.g. compromising of a service producer, etc.) change. All the existing trust models mentioned above could not be used independently and statically to satisfy the basic security assurance requirement of the system.

<FIG> illustrates an example block diagram of a model according to certain embodiments. As illustrated in <FIG>, the example of certain embodiments introduce a Reflective and Adaptive mutual trust model <NUM> to adapt to the dynamics and diversity of <NUM> networking and the ZSM framework with centralized trust evaluator and distributed trust adapter.

The adaptive mutual trust model <NUM> may include a Common Knowledge based Trust Evaluator <NUM> that acts as an intelligent Function Block (FB) to evaluate trustworthiness of a cross domain entity based on Chain of Risk, Trust Profile, Trust Assurance, and other context data of the entity.

A Distributed Knowledge based Trust Evaluator <NUM> may acts as the adaptive mutual trust model's <NUM> intelligent FB to evaluate trustworthiness of an intra domain entity based on Chain of Risk, Trust Profile, Trust Assurance, and other context data of the entity. There could be one or more Trust Evaluators in a single domain.

A Common Knowledge based Trust Model Adapator <NUM> may act as the adaptive mutual trust model's <NUM> intelligent FB to create a trust relationship and a trust model between two inter-domain entities based on Composition of Trust from Trust Evaluator.

A Distributed Knowledge based Trust Model Adaptor <NUM> may act as the adaptive mutual trust model's <NUM> intelligent FB to create a trust relationship and a trust model between two inter/intra-domain entities based on Composition of Trust from Trust Evaluator. There could be one or more Trust Model Adapters in a single domain.

A Composition of Trust may be information evaluated by a trust evaluator according to analytics on Chain of Risk, Trust Profile, Trust Assurance, and other context data of an entity. An Entity may be a Service consumer or Service Producer or both.

<FIG> illustrates an example of functional blocks for an adaptive trust model <NUM>, according to an embodiment. Certain embodiments provide that Trust Evaluator A <NUM> or Trust Evaluator B <NUM> can be combined with Common Trust Evaluator <NUM>; Trust Model Adaptor A <NUM> or Trust Model Adaptor B <NUM> can be combined with Common Trust Model Adaptor <NUM>.

In certain embodiments, the workflow of an adaptive mutual trust model between diverse entities in dynamic <NUM> network and network management system may include Trust Model Adaptor A <NUM> of Entity A <NUM> creating an adaptive trust model to establish trust relationship with Entity B <NUM> according to Composition of Trust of Entity B <NUM> and Composition of Trust of Entity A <NUM>.

Based on the Trust Model and related policies defined in the Trust Model, Entity A <NUM> may apply security controls between the apparatus and the other apparatus such as authenticate Entity B <NUM>, may define access control rules for Entity B <NUM>, may build secure channel with Entity B <NUM>, and may record behaviors of Entity B <NUM> on Entity A <NUM>.

Entity A <NUM> and Entity B <NUM> may be a service consumer, service producer, or both. The Trust Model created may be a validated/direct trust model, mediated/transitive trust model, mandated trust model, or hybrid trust model, etc..

Composition of Trust of Entity A <NUM> mentioned above may be derived by Trust Evaluator A <NUM> of Entity A <NUM> according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM>.

Composition of Trust of Entity B <NUM> mentioned above may be either derived by Trust Evaluator of Entity A <NUM> according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity B <NUM>, or received from other trusted entities directly.

Chain of Risk mentioned above may be derived by a Trust Evaluator of an entity according to Trust Profile, Trust Assurance, and other context data of chain of service consumers and chain of service producers of the entity.

The Chain of Service Consumer discussed above may be a list of Service Consumers of an entity including direct consumers of the entity and consumers of its consumers. A Service Consumer can be Management Function, Network Function, Tenant, Operator, or any software or human entity.

Chain of Service Producer mentioned above may be a list of Service Producers of an entity including direct producer of the entity and producers of its producers. A Service Producer can be Management Function, Network Function, Operator, or any software or hardware.

A Trust profile mentioned above may define security characters (e.g. security threat and risk, applied countermeasure, security polices, regulations, etc.) and security capability (e.g. available security functions, etc.) of an entity. The Trust Profile can be changed according to upgrade, scaling of the entity, or adding/deleting/updating of services provided by the entity, adding/removing/changing of consumers or producers of the entity, security status and threat surface changing of the entity itself or its consumers or producers, the policy or regulation change on the entity, etc..

A Trust assurance may define capability and level of Security enforcement, verification, monitoring and compliance of an entity. Trust assurance can be dynamically changed based on change of the entity or change of its Trust profile, etc..

Similarly, Trust Model Adaptor B <NUM> of Entity B <NUM> may create adaptive trust model to establish trust relationship with Entity A <NUM> according to Trust Compositions of Entity B <NUM> and Entity A <NUM>.

If there is change on Entity A <NUM>, Trust Evaluator A <NUM> may derive a new Composition of Trust of Entity A <NUM> according to the change of the Entity A <NUM>, and may inform Entity B <NUM> the change of the Entity A <NUM> directly or indirectly based on trust model between Entity A <NUM> and Entity B <NUM>.

To reflect new Composition of Trust of Entity A <NUM>, Trust Model Adapter A <NUM> may update/delete trust model and/or establish new trust relationship or delete the trust relationship with Entity B <NUM>. Similarly, to reflect the change of Entity A <NUM>, Trust Model Adaptor B <NUM> of Entity B <NUM> may update/delete trust model and/or establish new trust relationship or delete the trust relationship with Entity A <NUM>.

The change of Entity A <NUM> mentioned above may include the entity upgrading, scaling, moving, security state change, adding/deleting consumer/producer of the entity of the entity, changing of security context of its consumers or producers, changing of threat surface related to the entity, changing of Security Policies or regulations related to the entity, etc..

The change of Entity A <NUM> received by Entity B <NUM> includes updated Composition of Trust of Entity A <NUM> or updated Chain of Risk, Trust Profile, Trust Assurance of Entity A <NUM> based on trust model between Entity A <NUM> and Entity B <NUM>.

Based on the new Trust Model and related policies defined in the new Trust Model, Entity A <NUM> and Entity B <NUM> may apply security controls between the apparatus and the other apparatus such as authenticate the other Entity, define access control rules for the other Entity, build secure channel with the other Entity, and/or record behaviors of the other Entity.

In an example scenario, a trust relationship between Entity A <NUM> and Entity B <NUM> is established. As a precondition, the management system is a system with Service Based Management Architecture (SBMA) (e.g. ETSI ZSM framework-based system, 3GPP Rel15 defined network management system, etc.) or a network with Service Based Architecture (SBA) (e.g. 3GPP defined <NUM> Core), and before an entity is able to interact with another entity, mutual trust should be established between entities and the framework, as well as between the two entities to ensure confidentiality, integrity, availability and regulation compliance of both entities and the framework.

In this example, Entity A <NUM> consumes services produced by Entity B <NUM>, and both Entity A <NUM> and Entity B <NUM> are deployed in an SBA/SBMA framework. Trustworthiness of framework entities (e.g. Common Trust Evaluator <NUM>, Common Trust Model Adaptor <NUM>) have been self-evaluated, and related Composition of Trust has been derived.

A unilateral trust relationship from Entity A <NUM> and Entity B <NUM> to framework entities has been established (e.g. based on a root of trust). In light of this assumption, Entity A <NUM> and Entity B <NUM> trust services and information produced by framework entities (e.g. Common Trust Evaluator <NUM>, Common Trust Model Adaptor <NUM>, etc.) based on established trust model, and Entity A <NUM> and Entity B <NUM> allow framework entities to consume their services based on established trust model.

Common Trust Evaluator <NUM> could retrieve trust related information of an entity in the framework from a trusted 3rd party entity, or from the entity itself after it builds related trust with the entity. In an embodiment, AI/ML technology could be used on Trust Evaluator and Trust Model adapter for knowledge based evaluation and adaptation.

In the example scenario, before providing any services to Entity A <NUM>, Common Trust Evaluator <NUM> of the framework evaluates the trustworthy of the Entity A <NUM> according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM> from a trusted entity, and derives Composition of Trust of Entity A <NUM>. The trusted entity may be a third party entity or Entity A <NUM> itself. The third party entity can be hardware, software, or human, etc..

Based on Composition of Trust of Common Trust Evaluator <NUM> and Composition of Trust of Entity A <NUM>, Common Trust Model Adaptor <NUM> creates relevant Trust Model to establish unilateral trust relationship from Common Trust Evaluator to Entity A <NUM>. Similarly, Common Trust Model Adaptor <NUM> creates relevant Trust Model to establish unilateral trust relationship from Common Trust Evaluator <NUM> to Entity B <NUM>.

Before consuming any services produced by Entity B <NUM>, Trust Evaluator A <NUM> for Entity A <NUM> checks the trustworthiness of Entity B <NUM> with Common Trust Evaluator <NUM>. Based on mutual trust model between Entity A <NUM> and Common Trust Evaluator <NUM>, as well as mutual trust model between Entity B <NUM> and Common Trust Evaluator <NUM>, Common Trust Evaluator <NUM> either returns Composition of Trust of Entity B <NUM> to Entity A <NUM> or returns Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity B <NUM> to Entity A <NUM>. In some cases, Common Trust Evaluator <NUM> may return an error to Entity A <NUM>.

If Common Trust Evaluator <NUM> returns Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity B <NUM> to Entity A <NUM>, Trust Evaluator A <NUM> evaluates the trustworthiness of Entity B <NUM> according to Chain of Risk, Trust Profile, Trust Assurance, and other context data of Entity B <NUM>, and derives Composition of Trust of Entity B <NUM>.

Trust Evaluator A <NUM> self-evaluates the trustworthiness of Entity A according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM>, and derives Composition of Trust of Entity A <NUM>. Based on the Composition of Trust of Entity B <NUM> and the Composition of Trust of Entity A <NUM>, Trust Model Adaptor A <NUM> creates a relevant Trust Model (e.g. validated/direct trust, mediated/transitive trust, mandated trust, etc.) to establish unilateral trust relationship from Entity A <NUM> to Entity B <NUM>.

Based on the Trust Model and related policies defined in the Trust Model, Entity A <NUM> applies security controls between the apparatus and the other apparatus such as Entity A <NUM> authenticates Entity B <NUM> and builds a secure channel with Entity B <NUM> to access services of Entity B <NUM>.

Before providing any services to Entity A <NUM>, Trust Evaluator B <NUM> for Entity B <NUM> checks the trustworthiness of Entity A <NUM> with Common Trust Evaluator <NUM>.

Based on the mutual trust model between Entity B <NUM> and Common Trust Evaluator <NUM>, as well as mutual trust model between Entity A <NUM> and Common Trust Evaluator <NUM>, Common Trust Evaluator <NUM> either returns Composition of Trust of Entity A <NUM> to Entity B <NUM> or returns Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM> to Entity B <NUM>. In some cases, Common Trust Evaluator <NUM> may return an error to Entity B <NUM>.

If Common Trust Evaluator <NUM> returns Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM> to Entity B <NUM>, Trust Evaluator B <NUM> evaluates the trustworthiness of Entity A <NUM> according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A, and derives Composition of Trust of Entity A <NUM>.

Trust Evaluator B <NUM> self-evaluates the trustworthiness of Entity B <NUM> according to Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity B <NUM>, and derives Composition of Trust of Entity B <NUM>.

Based on Composition of Trust of Entity B <NUM> and Composition of Trust of Entity A <NUM>, Trust Model Adaptor B <NUM> creates a relevant Trust Model (e.g. validated/direct trust, mediated/transitive trust, mandated trust, etc.) to establish a unilateral trust relationship from Entity B <NUM> to Entity A <NUM>.

Based on the Trust Model and related policies defined in the Trust Model, Entity B <NUM> applies security controls between the apparatus and the other apparatus such as Entity B <NUM> authenticates Entity A <NUM>, defines access control rules for Entity A <NUM> and builds a secure channel with Entity A <NUM> to provide services to Entity A <NUM>, and record behaviors of Entity A <NUM> on Entity B <NUM>.

In another example scenario, the trust relationship between Entity A <NUM> and Entity B <NUM> is changed according to dynamic change of Entity A <NUM>, Entity B <NUM>, or their producers <NUM>, <NUM> or consumers <NUM>, <NUM>.

As a precondition to this example, the mutual trust between Entity A <NUM> and Common Evaluator <NUM> was already established with specific trust models, the mutual trust between Entity B <NUM> and Common Evaluator <NUM> was already established with specific trust models, and the mutual trust between Entity A <NUM> and Entity B <NUM> was already established with specific trust models.

In an embodiment, the trust relationship and related trust models between entities may be changed dynamically based on change of the entities. The change of an entity may include one or more of a change of entity itself (e.g. the entity is upgrade, introduces new feature, a new service, or uses a new technology, software, or hardware, etc.), the entity may be scaled or moved, especially to new geo-location, security state of the entity may change (e.g. the entity was compromised or damaged, etc.), change of context of the entity (e.g. Add/delete consumer/producer of the entity, add consumer of specific industry domain), the security context of its consumers or producers may change (e.g. security policy changes of its consumer), the threat surface related to the entity is changed (e.g. there may be a new vulnerability exposed, or new attack mode disclosed, etc.), and/or the security policies or regulations related to the entity may change.

In the example scenario, according to certain embodiments, when there is change on Entity A <NUM>, Trust Evaluator A <NUM> re-evaluates the trustworthiness of Entity A <NUM> according to updated Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM>, and derives new Composition of Trust of Entity A <NUM>.

Based on trust relationship between Entity A <NUM> and Common Trust Evaluator <NUM>, Trust Evaluator A <NUM> may sync the change of Entity A <NUM> with Common Trust Evaluator <NUM>, and based on trust relationship between Common Trust Evaluator <NUM> and Entity A <NUM>, and trust relationship between Common Trust Evaluator <NUM> and Entity B <NUM>, Common Trust Evaluator <NUM> may further sync the change of Entity A <NUM> to Entity B <NUM>.

Based on trust relationship between Entity A <NUM> and Entity B <NUM>, Trust Evaluator A <NUM> may sync the change of Entity A <NUM> with Entity B <NUM> directly.

The sync information can be the updated Composition of Trust of Entity A <NUM>, or the updated Chain of Risk, Trust Profile, Trust Assurance and other context data of Entity A <NUM>, etc..

To reflect the new Composition of Trust of Entity A <NUM>, Trust Model Adapter A <NUM> may update trust models (e.g. validated/direct trust, mediated/transitive trust, mandated trust, etc.) for new trust relationships to Common Trust Evaluator <NUM> and/or Entity B <NUM>. Based on the new Trust Model and related policies defined in the new Trust Model, Entity A <NUM> applies security controls between the apparatus and the other apparatus such as Entity A <NUM> authenticates Entity B <NUM> and builds a secure channel with Entity B <NUM> to access services of Entity B <NUM>.

If Entity B <NUM> received Chain of Risk, Trust Profile and Trust Assurance of Entity A <NUM> from either Common Trust Evaluator <NUM> or Entity A <NUM>, Trust Evaluator B <NUM> re-evaluates the trustworthiness of Entity A <NUM> according to the updated Chain of Risk, Trust Profile, and Trust Assurance of Entity A <NUM>, and derives new Composition of Trust of Entity A <NUM>. Based on the new Composition of Trust of Entity A <NUM>, Trust Model Adaptor B <NUM> may update the Trust Model (e.g. validated/direct trust, mediated/transitive trust, mandated trust, etc.) for the new trust relationship from Entity B <NUM> to Entity A <NUM>.

Based on the new Trust Model and related policies defined in the new Trust Model, Entity B <NUM> apply security controls between the apparatus and the other apparatus such as Entity B <NUM> authenticates Entity A <NUM>, defines access control rules for Entity A <NUM>, builds a secure channel with Entity A <NUM> to provide services to Entity A <NUM>, and records behaviors of Entity A <NUM> on Entity B <NUM>.

<FIG> illustrates an example flow diagram of for implementing an adaptive mutual trust model for dynamic and diversity multi-domain networks, according to an embodiment.

As illustrated in the example of <FIG>, the method may include at <NUM> creating an adaptive trust model, by a trust model adaptor of an apparatus, configured to establish a trust relationship with an other apparatus according to a composition of trust derived by a trust evaluator of the other apparatus and a composition of trust derived by a trust evaluator of the apparatus. The method may also include authenticating the other apparatus based on the adaptive trust model and policies defined in the adaptive trust model at <NUM>, and at <NUM>, the method may include defining access control rules for the other apparatus based on the adaptive trust model and the policies defined in the adaptive trust model.

In an embodiment, at <NUM> the method may include building a secure channel with the other apparatus based on the adaptive trust model and policies defined in the adaptive trust model, and at <NUM> recording behaviors of the other apparatus on the apparatus. The method, as shown at <NUM> may also include authenticating the other apparatus based on the new trust model, at <NUM> defining access control rules for the other apparatus based on the new trust model, at <NUM> building a secure channel with the other apparatus based on the new trust model, and at <NUM> recording behaviors of the other apparatus based on the new trust model.

<FIG> illustrates an example of an apparatus <NUM> according to an embodiment. In an embodiment, apparatus <NUM> may be a node, host, or server in a communications network, a network/service management system or serving such a network. For example, apparatus <NUM> may be a communication service management function, network slice management function, network slice subnet management function, network function management function, base station, a Node B, an evolved Node B (eNB), <NUM> Node B or access point, next generation Node B (NG-NB or gNB), CU of a gNB, WLAN access point, Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Authentication Server Function (AUSF), Network Repository Function (NRF), Network Slice Selection Function (NSSF), a data management entity (e.g., UDM), or other entity associated with a radio access network, such as <NUM> or NR. In one example, apparatus <NUM> may represent a management service producer.

Processor <NUM> may perform functions associated with the operation of apparatus <NUM>, which may include, for example, management and orchestration, and overall control of the apparatus <NUM>, including processes related to management of communication resources.

As introduced above, in certain embodiments, apparatus <NUM> may be a network node or entity, such as a management service producer, or the like. According to certain embodiments, apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to perform the functions associated with any of the embodiments described herein. For example, in some embodiments, apparatus <NUM> may be configured to perform one or more of the processes depicted in any of the flow charts or signaling diagrams described herein, such as <FIG>.

<FIG> illustrates an example of an apparatus <NUM> according to an example embodiment. In example embodiments, apparatus <NUM> may be a node or server associated with a radio access network, a network/service management system, such as a LTE network, <NUM> or NR or other radio systems which might benefit from an equivalent procedure. For example, apparatus <NUM> may be a communicant service management function, network slice management function, network slice subnet management function, network function management function, base station, a Node B, an evolved Node B (eNB), <NUM> Node B or access point, next generation Node B (NG-NB or gNB), Access &Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Authentication Server Function (AUSF), Network Repository Function (NRF), Network Slice Selection Fucntion (NSSF), and/or DU or CU of a gNB associated with a radio access network, such as <NUM> or NR. In one example, apparatus <NUM> may represent a client, such as a management service consumer, a network function, a network element or a management function.

While a single processor <NUM> is shown in <FIG>, multiple processors may be utilized according to other example embodiments. For example, it should be understood that, in certain example embodiments, apparatus <NUM> may include two or more processors that may form a multiprocessor system (e.g., in this case processor <NUM> may represent a multiprocessor) that may support multiprocessing. In certain example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).

In an example embodiment, apparatus <NUM> may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium.

In example embodiments, apparatus <NUM> may also include or be coupled to one or more antennas <NUM> for receiving a downlink signal and for transmitting via an uplink from apparatus <NUM>.

In an example embodiment, memory <NUM> stores software modules that provide functionality when executed by processor <NUM>.

According to some example embodiments, processor <NUM> and memory <NUM> may be included in or may form a part of processing circuitry or control circuitry. In addition, in some example embodiments, transceiver <NUM> may be included in or may form a part of transceiving circuitry.

In some example embodiments, the functionality of any of the methods, processes, diagrams, or flow charts described herein may be implemented by software and/or computer program code or portions of code stored in memory or other computer readable or tangible media, and executed by a processor.

In some example embodiments, an apparatus may be included or be associated with at least one software application, module, unit or entity configured as arithmetic operation(s), or as a program or portions of it (including an added or updated software routine), executed by at least one operation processor. Programs, also called program products or computer programs, including software routines, applets and macros, may be stored in any apparatus-readable data storage medium and may include program instructions to perform particular tasks.

A computer program product may include one or more computer-executable components which, when the program is run, are configured to carry out some example embodiments. The one or more computer-executable components may be at least one software code or portions of code. Modifications and configurations required for implementing functionality of an example embodiment may be performed as routine(s), which may be implemented as added or updated software routine(s). In one example, software routine(s) may be downloaded into the apparatus.

As an example, software or computer program code or portions of code may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers may include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and/or software distribution package, for example. The computer readable medium or computer readable storage medium may be a non-transitory medium.

In other example embodiments, the functionality may be performed by hardware or circuitry included in an apparatus (e.g., apparatus <NUM> or apparatus <NUM>), for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, such as a non-tangible means, that can be carried by an electromagnetic signal downloaded from the Internet or other network.

Claim 1:
An apparatus (<NUM>), comprising:
means for creating an adaptive trust model, by a trust model adaptor (<NUM>) of the apparatus (<NUM>), configured to establish a trust relationship with another apparatus (<NUM>) according to a composition of trust of the other apparatus (<NUM>) and a composition of trust of the apparatus (<NUM>), the composition of trust of the apparatus (<NUM>) being derived by a trust evaluator (<NUM>) of the apparatus (<NUM>); and
means for applying security controls between the apparatus (<NUM>) and the other apparatus (<NUM>) based on the adaptive trust model,
wherein the trust evaluator (<NUM>) of the apparatus (<NUM>), when there is a change on the apparatus (<NUM>), according to the change, is configured to:
derive a new composition of trust of the apparatus (<NUM>); and
inform the other apparatus (<NUM>) of the change on the apparatus (<NUM>),
wherein, to reflect the new composition of trust of the apparatus (<NUM>), the trust model adaptor (<NUM>) of the apparatus (<NUM>) is configured to update the adaptive trust model and establish a new trust relationship.