WO2026007279A1 - System and methods on end-to-end security protection for communications among cross-domains - Google Patents

Abstract

Methods and systems are provided for deriving and distributing encryption keys across domains of networks, especially 6G networks. Embodiments can be used to frustrate network attacks and facilitate secure end-to-end communications among network entities belonging to separate domains. In embodiments, multiple root keys are derived, each facilitating either intra-domain or cross-domain communications. These root keys can be derived from separate master keys that are obtained from authentication procedures and can be used to generate unique terminal keys for users, network functions, and services according to the specific security context. Embodiments further provide signaling procedures for requesting keys and distributing them among network entities.

Description

SYSTEM AND METHODS ON END-TO-END SECURITY PROTECTION FOR COMMUNICATIONS AMONG CROSS-DOMAINS

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Patent Application No. 63/668,017, filed on July 5, 2024, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present disclosure generally relates to communication networks, and more particularly methods, apparatus, and systems for security protection in communication networks.

BACKGROUND

Next generation (e.g., 5.5 generation (5.5G) , 6 generation (6G) or future generation) communication networks are expected to include multiple domains, such as a user domain and a service provider domain. In many cases, data may need to be transferred between domains. For example, data may be collected from a user in a first domain and delivered to a service provider in a second domain. In typical communication networks, to provide security against attacks seeking to acquire sensitive information, communications between two network entities may be encrypted according to unique keys provided to each of the network entities. However, currently available frameworks for key derivation and distribution are not transferable to cross-domain communication networks. In particular, currently available frameworks fail to define which network entities should generate the keys, how the keys should be distributed between domains, and how the keys should be synchronized.

Therefore, there is a need for methods, apparatus, and systems for key derivation and distribution that obviate or mitigate one or more limitations of the prior art.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY

An object of embodiments of the present disclosure is to provide methods and systems for key derivation for inter-domain and intra-domain communication.

A first aspect of the present disclosure is to provide a method that comprises generating a first root key configured for terminal key derivation for respective communications between a first-domain network entity (NE) in a first network domain and each of one or more further first-domain NEs in the first network domain, and generating a second root key configured for terminal key derivation for respective communications between the first-domain NE and each of one or more second-domain NEs in a second network domain connected to the first network domain.

In some embodiments of the first aspect, the first-domain NE may be a first user in the first network domain, the one or more further first-domain NEs may include a first network function, and the first root key may be used for terminal key derivation for respective communications between the first user and the first network function.

In some embodiments of the first aspect, the first-domain NE may be a first user, the one or more second-domain NEs may include a second user and a second network function, and the second root key may be used for deriving a third root key and a fourth root key. The third root key may be used for terminal key derivation for respective communications between the first user and the second user, and the fourth root key may be used for terminal key derivation for respective communications between the first user and the second network function. In some embodiments, the first root key may be generated based on a first negotiated key, with the first negotiated key being generated during a mutual authentication procedure. In some embodiments, the one or more further first-domain NEs may include a first network function and the method may further comprise, before generating the first root key: receiving a request for key configuration, generating a master key according to random values, and generating the first  negotiated key based on the master key. The request may include security context, which may be used for terminal key derivation for respective communications between the first user and the first network function. In some of these embodiments, the method may further comprise deriving, from the first root key and based on the security context, a terminal key for respective communications between the first user and the first network function. In some embodiments, the second root key may be generated based on a second negotiated key, with the second negotiated key being generated during a mutual authentication procedure. In some of these embodiments, the method may further comprise, before generating the second root key: receiving, a request for key configuration, generating a master key according to random values, and generating the second negotiated key based on the master key, with the request including security context, which may be used for terminal key derivation for respective communications between the first user and the second network function. In some of these embodiments, the method may further comprise deriving, from the third root key and based on the security context, a terminal key for respective communications between the first user and the second user, and/or deriving, from the fourth root key and based on the security context, a terminal key for respective communications between the first user and the second network function. In some other embodiments the method may further comprise: sending a service request including a first identifier (ID) of the first user; receiving a response including a second ID of the second user, with the response being in response to the first service request; generating a master key based on random values; generating a first negotiated key based on the master key; generating security context, the security context being used for terminal key derivation for respective communications between the first user and the second user; deriving, from the second root key and based on the security context, a terminal key for communication between the first user and the second user; and sending the security context to the second user.

In some embodiments of the first aspect, the method may further comprise obtaining a first extended master session key (EMSK) and a second EMSK. The first EMSK may depending from a first authentication procedure to authenticate, for the first network domain, the first domain NE, and the second EMSK may depend from a second authentication procedure to authenticate, for each of the first network domain and the second network domain, the first domain NE and the one or more second domain NEs. In these embodiments, the first root key may be generated according to the first EMSK, and the second root key may be generated according to the second EMSK. In some of these embodiments, generating, according to the first EMSK, the first root key may include generating, according to the first EMSK, one of a real root key (RRK) and a virtual intra-root key (VIK) . In addition, in some of these embodiments, where the one or more second-domain NEs includes a user equipment and a network service, generating, according to the second EMSK, the second root key may include generating, according to the second EMSK, a virtual root key (VRK) . In these embodiments, the method may further comprise deriving, from the VRK, at least one of: a virtual sub-root key (VSK) configured for terminal key derivation for communication between the first-domain NE and the user equipment, and a real-virtual root key (RVRK) configured for terminal key derivation for communication between the first-domain NE and the network service. In some embodiments, wherein the one or more second-domain NEs includes a user equipment and a network service, generating, according to the second EMSK, the second root key may include generating, according to the second EMSK, a virtual root key (VRK) . In these embodiments, the method may further comprise deriving, from the VRK, at least one of: a virtual sub-root key (VSK) configured for terminal key derivation for communication between the first-domain NE and the user equipment, and a virtual real-root key (VRRK) configured for terminal key derivation for communication between the first-domain NE and the network service. In some embodiments, obtaining the second EMSK may include: generating, for the first-domain NE, a respective random value; providing, to each of the one or more second-domain NEs, the respective random value for the first-domain NE; and receiving, for each of the one or more second-domain NEs, a respective random value. In some of these embodiments, obtaining the second EMSK may further include: generating, in accordance with each respective value of the first-domain NE and the one or more second-domain NEs, the second EMSK; or receiving the second EMSK.

In some embodiments of the first aspect, the method may further comprise deriving, from the first root key, one or more terminal keys each providing security protection for respective communications between the first-domain NE and a respective further first-domain NE of the one or more further first-domain NEs. In some of these embodiments: the first root key may be a VIK; the first-domain NE may be a user equipment; the respective further first-domain NE is an anything-as-a-service gateway (XaaS-GW) ; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K_{C/M- XGWuser-int} terminal key in accordance with a respective identifier of the Xaas-GW, a respective identifier of the user equipment,  a service identifier, a number of communication messages, and an identifier of a control/management integrity algorithm. In some other embodiments: the first root key may be a VIK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a XaaS-GW; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K_{C/M-XGWuser-enc} terminal key in accordance with a respective identifier of the Xaas-GW, a respective identifier of the user equipment, a service identifier, a number of communication messages, and an identifier of a control/management encryption algorithm. In some other embodiments: the first root key may be a VIK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a XaaS-GW; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K_GW terminal key in accordance with a respective identifier of the Xaas-GW and a respective identifier of the user equipment. In some other embodiments: the first root key may be a VIK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a sub-anything-as-a-service gateway (SubXaaS-GW) ; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K_SXGWuser-int terminal key in accordance with a service identifier, a number of communication messages, and an identifier of a control/management integrity algorithm. In some other embodiments: the first root key may be a VIK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a SubXaaS-GW; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K_SXGWuser-int terminal key in accordance with a service identifier, a number of communication messages, and an identifier of a control/management encryption algorithm. In some other embodiments: the first root key may be a RRK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a 6G gateway (6G-GW) ; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K1_{C/M- 6GWuser-int} terminal key in accordance with a respective identifier of the user equipment, a number of communication messages, and an identifier of a control/management integrity algorithm. In some other embodiments: the first root key may be a RRK; the first-domain NE may be a user equipment; the respective further first-domain NE may be a 6G-GW; and deriving, from the first root key, the one or more terminal keys may include deriving, from the VIK, a K1_{C/M-6GWuser-enc} terminal key in accordance with a respective identifier of the user equipment, a number of communication messages, and an identifier of a control/management encryption algorithm.

In some embodiments of the first aspect, the method may further comprise deriving, from the second root key, one or more terminal keys each providing security protection for respective communication between the first-domain NE and a respective second-domain NE of the one or more second domain NEs. In some of these embodiments: the second root key may be a VRK; the first-domain NE may be a first user equipment; the one or more second-domain NEs may include a second user equipment; the method may further comprise deriving, from the VRK, a VSK configured for terminal key derivation for communication between the first-domain NE and the second user equipment; and deriving, from the second root key, the one or more terminal keys may include deriving, from the VRK, a K_C/M-user-enc terminal key in accordance with a number of communication messages and an identifier of a control/management encryption algorithm. In some other embodiments: the second root key may be a VRK; the first-domain NE is a first user equipment; the one or more second-domain NEs may include a second user equipment; the method may further comprise deriving, from the VRK, a VSK configured for terminal key derivation for communication between the first-domain NE and the second user equipment; and deriving, from the second root key, the one or more terminal keys may include deriving, from the VRK, a K_C/M-user-int terminal key in accordance with a number of communication messages and an identifier of a control/management integrity algorithm. In some other embodiments: the second root key may be a VRK; the first-domain NE may be a first user equipment; the one or more second-domain NEs may include a 6G-GW; the method may further comprise deriving, from the VRK, a VRRK configured for terminal key derivation for communication between the first-domain NE and the 6G-GW; and deriving, from the second root key, the one or more terminal keys may include deriving, from the VRRK, a K_{C/M- 6GWuser-enc} terminal key in accordance with a number of communication messages, an identifier of a control/management encryption algorithm, and a respective identifier of the 6G-GW. In some other embodiments: the second root key may be a VRK; the first-domain NE may be a first user equipment; the one or more second-domain NEs may include a 6G-GW; the method may  further comprise deriving, from the VRK, a VRRK configured for terminal key derivation for communication between the first-domain NE and the 6G-GW; and deriving, from the second root key, the one or more terminal keys may include deriving, from the VRRK, a K_{C/M-6GWuser-int} terminal key in accordance with a number of communication messages, an identifier of a control/management integrity algorithm, and a respective identifier of the 6G-GW. In some other embodiments: the second root key may be a VRK; the first-domain NE may be a first user equipment; the one or more second-domain NEs may include a XaaS-GW;the method may further comprise deriving, from the VRK, a RVRK configured for terminal key derivation for communication between the first-domain NE and the XaaS-GW; and deriving, from the second root key, the one or more terminal keys may include deriving, from the RVRK, a K_XGWuser-int terminal key in accordance with a number of communication messages, an identifier of a control/management integrity algorithm, and a respective identifier of the XaaS-GW. In some other embodiments: the second root key may be a VRK; the first-domain NE may be a first user equipment; the one or more second-domain NEs may include a XaaS-GW; the method may further comprise deriving, from the VRK, a RVRK configured for terminal key derivation for communication between the first-domain NE and the XaaS-GW; and deriving, from the second root key, the one or more terminal keys may include deriving, from the RVRK, a K_XGWuser-enc terminal key in accordance with a number of communication messages, an identifier of a control/management encryption algorithm, and a respective identifier of the XaaS-GW.

In some embodiments of the first aspect, the method may further comprise receiving, from at least one second-domain NE of the one or more second-domain NEs, a respective identifier. In some embodiments, the method may further comprise providing, for the first-domain NE, a respective identifier.

In some embodiments of the first aspect, the method may further comprise providing, to one of the one or more further first-domain NEs, a service identifier request, and receiving, from the one further first-domain NE, a service identifier response.

In some embodiments of the first aspect, the method may further comprise providing, to one of the one or more further first-domain NEs, a key identification request, and receiving, from the one further first-domain NE, a key identification response.

In some embodiments of the first aspect, the method may further comprise generating, for the first-domain NE, one or more security contexts. In some embodiments, the method may further comprise providing the one or more security contexts for the first-domain NE. In some embodiments, the method may further comprise receiving, for the first-domain NE, one or more security contexts. In some of embodiments, the method may further comprise deriving, from the first root key, in accordance with the one or more security contexts, one or more terminal keys each providing security protection for respective communications between the first-domain NE and a respective further first-domain NE of the one or more further first-domain NEs. In some other embodiments, the method may further comprise deriving, from the second root key, in accordance with the one or more security contexts, one or more terminal keys each providing security protection for respective communications between the second-domain NE and a respective second-domain NE of the one or more second-domain NEs.

In some embodiments of the first aspect, the method may further comprise providing, to at least one second-domain NE of the one or more second-domain NEs, a key configuration request, and receiving, from the at least one second-domain NE, a key configuration response. In some embodiments, the method may further comprise receiving, from at least one second-domain NE of the one or more second-domain NES, a key configuration request, and providing, to the at least one second-domain NE, a key configuration response.

A second aspect of the present disclosure is to provide a system comprising a network having a first domain connected to a second domain, one or more first-domain NEs located in the first domain of the network, and one or more second-domain NEs located in the second domain of the network. At least one first-domain NE of the one or more first-domain NEs may be configured to generate: a first root key configured for terminal key derivation for communication between a set of first-domain NEs from among the one or more first-domain NEs, and a second root key configured for terminal key derivation for respective communications between a further set of first-domain NEs from among the one or more first-domain NEs and each of the one or more second-domain NEs.

In some embodiments of the second aspect, the set of first-domain NEs or the further set of first-domain NEs may include the at least one first-domain NE. In some embodiments, each of the one or more first-domain NEs and each of the one or more second-domain NEs are selected from a group consisting of user equipment and network functions.

Embodiments of the present disclosure may facilitate key derivation for inter-domain and intra-domain communication that is secure against attacks. Embodiments may provide architectures for key derivation that define roles for different network entities and that define call-flows for synchronizing key derivation and distribution.

Embodiments have been described above in conjunction with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example structure of a 6G system.

FIG. 2 shows an example deployment of an evolutionary solution for a 6G system.

FIG. 3 shows an example of an apparatus in a communication system.

FIG. 4 shows an example of a multi-domain scenario in a 6G system.

FIG. 5 shows a system model for an example of a multi-domain scenario.

FIG. 6 shows an example of key protection for end-to-end communication.

FIG. 7A shows an example of root key derivation in fifth generation (5G) systems.

FIG. 7B shows root key derivation for a first user in a first domain, according to embodiments of the present disclosure.

FIG. 7C shows root key derivation for a second user in a second domain, according to embodiments of the present disclosure.

FIG. 8 shows root keys for entities in a 6G system, according to embodiments of the present disclosure.

FIG. 9 shows an example of terminal key derivation, according to an embodiment of the present disclosure.

FIG. 10A shows an example of a call flow for end-to-end key generation between users of different domains, according to an embodiment of the present disclosure.

FIG. 10B shows an example of a call flow for end-to-end key generation for a user in cross-domain communication, according to an embodiment of the present disclosure.

FIG. 10C shows an example of a call flow for end-to-end key generation for communications in a domain, according to an embodiment of the present disclosure.

FIG. 10D shows an example of a call flow for end-to-end key generation for a user in cross-domain communication, according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure are generally directed towards providing methods, systems, and apparatus for key derivation and distribution in 6G communication systems. In particular, embodiments are directed towards enabling key derivation and distribution for cross-domain communication. In embodiments, a plurality of root keys may be generated for network entities connected across multiple domains. For example, a root key may be generated for communications within a domain, such as those among network entities belonging to the domain. Another root key may be generated for communications between domains, such as between a network entity of one domain and another network entity of another domain. Each root key may be configured for generating respective terminal keys according to specific security contexts. A plurality of extended master session keys may be used to generate each root key and may be obtained from an authentication procedure. Network entities may include users and user equipment as well as network functions and services. For example, embodiments may be implemented for key generation for communications between a user in one domain and a service gateway in another domain or between a user in one domain and a network gateway in that domain. In embodiments, the root keys may include a real root key, a virtual root key, a virtual sub-root key, a real-virtual root key, and a virtual intra-root key.

The present disclosure sets forth various embodiments via the use of block diagrams, flowcharts, and examples. Insofar as such block diagrams, flowcharts, and examples contain one or more functions and/or operations, it will be understood by a  person skilled in the art that each function and/or operation within such block diagrams, flowcharts, and examples can be implemented, individually or collectively, by a wide range of hardware, software, firmware, or combination thereof. As used herein, the term “about” should be read as including variation from the nominal value, for example, a +/-10%variation from the nominal value. It is to be understood that such a variation is always included in a given value provided herein, whether or not it is specifically referred to.

An evolutionary solution of a 6G system architecture design and procedure design are described in the present disclosure. The evolutionary solution is designed by enhancement of a 5G system.

The proposed 6G network architecture has been designed with a few important principles and requirements: openness, trustworthiness, simplicity in standardization, scalability, rapid deployment of 6G networks and future-proofing.

The proposed 6G network architecture design applies modularization strategy, utilizes service-based ( “anything-as-a-service” or “XaaS” ) concepts and network virtualization techniques.

For all of the procedure designs, modularization of procedures may be implemented. A procedure of the 6G System may include some procedures that can be reused by other procedures. Such a reusable procedure is defined as a basic procedure.

A complex procedure may, thus, include multiple sequential or parallel basic procedures. It is expected that such methodology can simplify designs of procedures.

The 6G System may leverage service-based architectures and XaaS concepts. XaaS services in the 6G System may be categorized into three layers. FIG. 1 shows an example of a conceptual scheme for a 6G System. The 6G System may include an infrastructure layer 100, a service layer 110, and a control/management (C/M) layer 120.

The infrastructure layer 100 may include infrastructures supporting 6G services. Among these infrastructures may be wireless networks (Radio Access Network (RAN) 101, Core Network (CN) 102 infrastructures, cloud/data center infrastructures, satellite networks 103, storage/database infrastructures 104, and sensing networks 105, etc. These infrastructures may be provided by a single provider or by multiple providers.

In the example of FIG. 1, each XaaS service is provided by identified 5G logical functions. In the evolutionary solution, a XaaS service can be provided with 5G enhancement by more than one approaches. The “+” represents that a function is enhanced. In the 6G System conceptual structure:

● Network for AI (NET4AI) 111 is a new type of service (provided “as a service” or “aaS” ) in 6G CN/RAN which may enable networks with the capability to conduct/execute artificial intelligence (AI) training/inferencing task (s) ; i.e., it may enable AI task (s) , by network-based computing and communication resources. In this disclosure, the evolutionary solution supports NET4AI service 111 by enhancing the network data analytics function (NWDAF) in 5G systems. The NET4AI service 111 may further be supported by a 6G Point Spread Function (PSF) .

● A network for data service (NET4Data) 112 may provide a decentralized architecture for data stakeholders to collaboratively manage data lifecycle events. These data lifecycle events may include data storage and data sharing. The data may be public, private, sensitive, or confidential. In the present disclosure, the NET4Data service 112 may be integrated into a 5G system, or could be enhanced by a 5G system. The NET4Data service 112 may be supported by an enhanced Analytical Data Repository Function (ARDF+) and an enhanced Unstructured Data Storage Function (UDSF+) .

● Data analysis and management (DAM) 113 may focus on different types of data: network data (e.g., data collected from network functions and/or XaaS services) , integrated sensing and communication (ISAC) data third generation partnership (3GPP) -based sensing data (e.g., from user equipment (UE) and RAN 101) , non-3GPP-based sensing data (e.g., from radar, LiDAR, or WiFi sensing) , sensor data (e.g., data from camera sensors, video sensors) , and other data (e.g., digital user data, 3rd party data, synthetization data, and AI data) . DAM 113 may provide services for a variety of data consumers, e.g., XaaS services, 3rd parties, network functions (NFs) , UE, etc. 5G system logical functions, such as the NWDAF, data collection coordination function (DCCF) , and messaging framework adaptor function (MFAF) of a network control plane, can be enhanced to support DAM service 113 in an evolutionary solution.

● Network for BlockChain (NET4BC) 114 as a service may provide blockchain service. The NET4BC service 114 may be supported by a 6GBC function.

● Network for Digital World (NET4DW) 114 as a service may provide a capability of intelligent integration/synthesis of information from the physical world and digital world (DW) . Customers of NET4DW 115 may be individuals, industries, and  governments. The customers may have the capability of creation, control, and management of a variety of applications running in the DW, such as virtual reality applications. DW services may be supported by enhancing 5G functions and adding new functions (e.g., an evolutionary solution) where necessary. The NET4DW service 115 may be supported by a 6G Dual-Way Communications (DWC) function, a 6G Dynamic Waveform Processing (DWP) function, an enhanced NWDAF function, and an enhanced Unified Data Repository (UDR) function.

● Network for connectivity (NET4CON) 116 as a service may provide a capability to support exchanges of messages and data among new 6G services. The basic capabilities of NET4CON 116 may include managing logical topology among XaaS services and between 6G XaaS services and all types of 6G system customers, introducing intelligent gateways (GWs) for controlling dynamic forwarding based on configured procedure principles, and supporting anonymous interactions among XaaS services and customers by the introduced intelligent GWs. The NET4CON service 116 may be provided by enhancement of a 5G system.

● Mission Management (MM) 121 as a service may provide a capability to program provisioning of XaaS services at the service layer 110 to provide mission services. A mission may be to achieve a designated goal, known as mission goal, which may include providing protocol data unit (PDU) connectivity and optionally providing data processing. The MM services 121 may include the following: mission information management service, mission session management service, mission execution and access management service. The MM services 121 may be supported by an enhanced Session Management Function (SMF+) , an enhanced Network Exposure Function (NEF+) , an enhanced Policy Control Function (PCF+) , and a UDR+.

● Resource Management (RM) 122 as a service may provide a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices. The RM service 122 may be supported by an enhanced Radio Resource Management (RRM+) , and an enhanced Network Slice Selection Function (NSSF+) .

● Service Provisioning Management (SPM) 123 as a service provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability may be provided by identifier (ID) management, unified authentication, anonymous service authorization and key management. The SPM service 123 may be supported by an enhanced Authentication Server Function (AUSF+) , a 6G Author function, an enhanced Identity Management (IDM+) function, an Access Management Function-Mobility (AMF-Mobility) function, and a Radio Resource Control-Security (RRC-security) function.

● Connectivity Management (CM) 124 as a service may provide a capability of reachability management of 6G wireless devices and D-users in NET4DW 115 in order to support connectivity establishment between wireless devices/D-Users and XaaS services of a 6G System. Physical locations of D-Users may be changed. A CM service 124 can be deployed across multiple Broadband Access Server (BAS) domains.

● Protocol as a service 126 may provide a capability to design service customized protocol stacks for identified interfaces. The Protocol service 126 may be supported by an enhanced Quick User datagram protocol Internet Connections (QUIC+) function, a GIPU+ function, and an enhanced Service Data Adaptation Protocol (SDAP+) .

FIG. 2 shows an example of a deployment of a 6G system in the evolutionary solution. The “+” represents “enhanced” , for example, the 5G AMF-Mobility function is enhanced, denoted as AMF-Mobility+; the 5G Radio Resource Control (RRC) function is enhanced, denoted as RRC+; the 5G Network Repository Function (NRF) is enhanced, denoted as NRF+; the 5G Session Management Function (SMF) is enhanced, denoted as SMF+; the 5G NEF is enhanced, denoted as NEF+; and the 5G Authentication Server Function (AUSF) is enhanced, denoted as AUSF+. Other enhanced functions are not described in detail herein.

A C/M Radio Bearer (C/M RB) of a 6G device may be an over-the-air connection for carrying control signaling for over-the-air interface management and C/M plane messages. A 6G device may have multiple C/M RBs.

A Data Radio Bearer (Data RB) of a 6G device may be an over-the-air connection for carrying Data plane traffic. A 6G device may have multiple Data RBs.

An RB endpoint may be an endpoint of an RB at network side. An endpoint of an RB protocol stack (e.g., PDCP) may be in, e.g., a RAN BAS domain, but not limited to. In other words, an RB endpoint can be flexibly deployed/selected for a device.

An RB handler may be an over-the-air interface protocol stack handler. An RB handler may be a logical function that performs RB protocol stack operations after getting configurations. A protocol handler may be a packet-data convergence protocol  (PDCP) -only handler or whole protocol stack handler. An RB handler may accept an RB configuration from a Connectivity Management (CM) service 124. An RB handler may also accept a security configuration, e.g., keying material, from a SPM service 123.

The NET4CON service 116, which may be the main service impacting a 6G system architecture, may be implemented by an enhanced 5G Service Communication Proxy (SCP+) as a C/M plane GW and by an enhanced 5G User Plane Function (UPF+) as a data plane GW. A proposed per device/D-User C/M session and data session may be a logical connection between a device/D-User and its serving SCP+ (C/M-TW-GW) and serving UPF+ (Data-TW-GW) . All XaaS services may be deployed across multiple BAS/clouds.

The 6G customer may be of various types, including a device (e.g., an electronic device ED, or a terminal device) , an apparatus, a chip, an equipment (e.g., a user equipment) , etc. For example, the 6G customer may be an individual customer, a business customer, etc. The 6G customer may be used to connect persons, objects, machines, etc. The 6G customer may be widely used in various scenarios, including, for example, cellular communications, device-to-device (D2D) , vehicle-to-everything (V2X) , peer-to-peer (P2P) , machine-to-machine (M2M) , machine-type-communication (MTC) , internet-of-things (IoT) , virtual reality (VR) , augmented reality (AR) , mixed reality (MR) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

Each 6G customer may represent any suitable end user device for wireless operation and may include such devices (or may be referred to but not limited to) as a user equipment (UE) or a user device or a terminal device, a wireless transmit/receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation 6G customers may be referred to using other terms. When a 6G customer performs (or is configured to perform) a method described herein, it may be interpreted as the ED, one or more modules (or units) in the ED, a circuit or chip, or a combination thereof. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system-on-chip (SoC) including a modem core, or system-in-package (SIP) , and the like, and may be responsible for one or more communication functions in the ED.

FIG. 3 shows an example of an apparatus 300 in a communication system (e.g., the 6G system shown in FIG. 2) . The apparatus 300 may be an electronic device (e.g. ED or other 6G customer) , a network node such as in a RAN, any components in a RAN or CN, or any network function of a CN. As shown in FIG. 3, apparatus 300 may include at least one processor 310. Only one processor 310 is illustrated to avoid congestion in the drawing. The processor 310 may perform (or control the apparatus 300 to perform) operations (or methods) described herein as being performed by the apparatus 300.

When the apparatus 300 is a RAN device, components of the RAN or a UE, the apparatus 300 may further include a transmitter 320 and a receiver 330 coupled to one or more antennas. One, some, or all of the antennas may alternatively be panels. The transmitter 320 and the receiver 330 may be integrated, e.g. as a transceiver. The transceiver may be configured to modulate data or other content for transmission by at least one antenna or network interface controller (NIC) . The transceiver may also be configured to demodulate data or other content received by the at least one antenna. Each transceiver may include any suitable structure for generating signals for wireless or wired transmission and/or for processing signals received wirelessly or by wire. Each antenna may include any suitable structure for transmitting and/or receiving wireless or wired signals. In the present disclosure, the transceiver (or transmitter 320 and/or receiver 330) may be viewed as an interface circuit.

The apparatus 300 may include at least one memory 340. The memory 340 may store instructions used to perform operations described herein. The memory 340 may also store data used, generated, or collected by the apparatus 300. For example, the memory 340 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by the one or more processors 310.

A person skilled in the art should understand that embodiments of this application may be provided as a method, an apparatus (or system) , computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and  hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

A 6G System (6GS) may include multiple un-trusted domains, e.g., a user domain, a service provider domain, and/or a resource control management domain. The user domain may support users in providing access to the 6GS, which may apply to services thereof. The service provider domain may provide services, such as XaaS services (e.g., AI training services, or metaverse services) . The resource control management domain may provide functionalities of a core network and functionalities of infrastructures, such as access authentication, access authorization, and resource allocation. FIG. 4 provides an example of a scenario for a 6GS. A first user 401 (user1) connects to a first domain 402 (domain1) (e.g., a resource control management domain) that provides access authentication, access authorization and secure signaling/data exchange. A second user 403 (user2) connects a second domain 404 (domain2) (e.g., service provider domain) that provides XaaS services, such as metaverse services. These XaaS services may have sub-XaaS services. Data from user1 401 is collected by the domain1 402 (e.g., core network) and delivered to the domain2 404 (e.g., XaaS services or sub-XaaS services) . For example, the data may be used for further training related to the user2 403. All the domains mentioned above can be referred to as a network domain.

Embodiments of the present disclosure are generally directed towards end-to-end security protection for communications in cross-domains (i.e., communication across or between domains) . In the present disclosure, multiple root keys that are used for terminal key derivation, may be provided for end-to-end secure communications in cross-domains, and intra-domains. Embodiments of the present disclosure may include: an architecture of multiple root keys that is designed to provide key derivation for cross-domains and intra-domains; and a framework of key derivation that provides end-to-end security protection for communications. These keys may be associated with at least some of the following information, for example, a user ID, domain ID, and/or service ID. Embodiments of the present disclosure may provide unique keys for secure communications in cross-domains and intra-domains.

In an attack model for 6GS, the main objective of an attacker is to try to acquire sensitive information through passive or active attack on information communicated between parties, or users, communicating through a common channel. When an attack is successful, the attacker may be able to monitor all traffic on the network. According to the attack model, unique keys for a user could be used to limit the damage of an attack.

FIG. 5 shows an example of a system model for a 6GS. A domain1 402 (i.e., a first network domain) may include at least two network functions, a 6G gateway (6G-GW) 501 and a first AUSF (AUSF1) 502 (i.e., first-domain network entities) . The 6G-GW 501 may be a network function, and may be used for functionalities of data routing, data processing, and/or quality-of-service (QoS) enhancement. The 6G-GW 501 may be an AMF, or a UPF, or a GW, or a data process function. The AUSF1 502 may be responsible for authentication and generation of root keys. These root keys may be used for derivation of terminal keys that may be used for encryption protection and integrity protection on communications. A domain2 404 (i.e., a second network domain) may include at least three network functions, an XaaS service gateway (XaaS-GW) 503, a sub-XaaS service gateway (SubXaaS-GW) 504, and a second AUSF (AUSF2) 505 (i.e., second-domain network entities) . The XaaS-GW 503 may be used for functionalities of data processing, QoS enhancement, and/or routing signaling/packets in cross-domains. The SubXaaS-GW 504 may be used for functionalities of data processing, and routing signaling/packets in domain2 404. The SubXaaS-GW 504 may connect to a user2 403. The SubXaaS-GW 504 may correspond to a network function that supports sub-XaaS services. In an optional implementation, the domain1 402 can be the second network domain, the domain2 404 can be the first network domain.

FIG. 6 shows an example of unique terminal keys 600 for security protection on communications related to a user1 401 in a domain1 402 and a user2 403 in a domain2 404. Current techniques (e.g., Transport Layer Security (TLS) , Internet Protocol Security (IP Sec) ) typically provide security protection on communications between the 6G-GW 501 and XaaS-GW 503, and security protection on communications between the SubXaaS-GW 504 and XaaS-GW 503. Terminal keys for security protection on end-to-end communications related to users may provide customized security protection on communications in cross-domains and intra-domains. For example, a first terminal key (K1_6GWuser) 600 may be used for secure communication between the user1 401 and the 6G-GW 501, a second terminal key (K1_XGWuser) 600 may be used for secure communication between the user1 401 and the XaaS-GW 503, a third terminal key (K_user) 600 may be used for secure protection between the user1 401 and the user2  403, a fourth terminal key (K_XGWuser) 600 may be used for secure protection between the XaaS-GW 503 and the user2 403, a fifth terminal key (K_6GWuser) 600 may be used for secure protection between the 6G-GW 501 and the user2 403, and a sixth terminal key (K_SXGWuser) 600 may be used for secure protection on communications between the user2 403 and the SubXaaS-GW 504. These unique terminal keys 600 could prevent the attacks according to the attack model.

Several problems may be expected for current techniques in deriving keys:

● According to the attack model, each user should have unique terminal keys 600 for different communications related to the user. These unique terminal keys 600 should be securely generated based on the different communications, and should be securely configured for network functions related to these communications for the user. Current techniques do not address who generates/configures these keys for each user, how the confidential keys are transferred to the user through the cross-domain, and how these keys (key materials) are synchronized during key derivation or encryption /integrity protection.

● Current techniques (such as key derivation in 3GPP specification 33.501) focus on two-way trust (between the network side and UE side) , and do not consider multiple-way trust (such as between a user, domain1 402, and domain2 404) . The existing two-way trust that depends on a single root key is not feasible in cross-domains due to the attack model. Key deviation from the single root key suffers from attacks and violates the requirements of a unique terminal key 600 for communications for each user.

Embodiments of the present disclosure may generally be directed towards methods that enable each user in different domains to have unique terminal keys 600 that are derived from multiple root keys. These unique terminal keys 600 may protect secure communications in cross-domains and intra-domains. Embodiments may include: an architecture of multiple root keys that is designed to provide key derivation for cross-domains and intra-domains; and a framework of key derivation that provides end-to-end security protection for communications. Keys may be associated with at least some of the following information, e.g., a user ID, domain ID, and/or service ID. Embodiments may further include: procedures for key configuration are discussed for providing details of how to generate keys and how to synchronize these keys for encryption/integrity protection.

In embodiments of the present disclosure, a 6G System (6GS) may have multiple providers, e.g., a mobile operator that provides a network infrastructure and a core network, and a XaaS provider that deploys processing functions to implement services (such as AI training, data collection, and metaverse services) . Each provider may deploy or provide a network domain. For example, a domain1 402 may be provided by the mobile operator, and a domain2 404 may be deployed by the XaaS provider. In some embodiments, domain2 may be provided by another mobile operator. Each domain may have one or more network entities (i.e., first-domain network entities or second-domain network entities) , including users such as user equipment, network services such as XaaS services, and network functions. For example, a user1 401 may be in the domain1 402 and a user2 403 may be in the domain2 404 (as shown in FIG. 4) . A mutual authentication among user1 401, user2 403, domain1 402 and domian2 404 may have been successfully implemented. In embodiments, root keys may be negotiated during the authentication procedure.

FIGs. 7A, 7B and 7C show a framework for root keys, in accordance with a 5GS and with embodiments of the present disclosure. In a 5GS, as shown in FIG. 7A, each key (KAUSF) 701 would typically be derived from a single root key, an Extended Master Session Key (EMSK) 702, that is negotiated during a primary authentication and key agreement procedure. In contrast, a 6GS may have separate keys for cross-domains.

FIG. 7B shows user1 401 in domain1 402 may have two types of root keys. FIG. 7C shows a user2 403 in the domain2 404 may have two types of root keys, based on FIG. 7B and FIG. 7C, the present application provides a method comprising: generating a first a first root key configured for terminal key derivation for respective communications between a first-domain network entity (NE) in a first network domain and each of one or more further first-domain NEs in the first network domain, and generating a second root key configured for terminal key derivation for respective communications between the first-domain NE and each of one or more second-domain NEs in a second network domain connected to the first network domain.

As shown in FIG. 7B, user1 401 in domain1 402 may have two types of root keys, the domain1 may be considered as the first network domain:

● A Real Root Key (RRK) 703 for the core network that located in the domain1 402, which may be used for key derivation for security protection on communications in the domain1 402 (as shown in the FIGs. 5 and 6) . In other words, the RRK 703 may be configured for terminal key derivation for respective communications between a network entity of the domain1 402 and each  of one or more further network entities of the domain1 402. The RRK 703 may be derived from an EMSK-RRK 704 (i.e., an EMSK specific to the RRK) that is negotiated during a primary authentication and key agreement procedure (i.e., a first negotiated key generated during a mutual authentication procedure) . In other words, the EMSK-RRK 704 may depend from an authentication procedure to authenticate for the domain1 402 one or more network entities of the domain1 402. In some embodiments, the RRK 703 may be considered a first root key, which may be configured for terminal key derivation for respective communications between a first-domain NE in the first network domain and each of one or more further first-domain NEs in that first network domain. In some embodiments, the first-domain NE is a first user (user1) , the one or more further first-domain NEs includes a first network function.

● A Virtual Root Key (VRK) 705 for an XaaS service that may be located in the domain2 404, which may be used for key derivation for security protection on communications in the cross-domain. In some embodiments, the domain2 404 may be considered as a second network domain. The VRK 705 may be derived as an intermediary root key from an EMSK-VRK 706 (i.e., an EMSK specific to the VRK) that is negotiated during a primary authentication and key agreement procedure (i.e., a second negotiated key generated during a mutual authentication procedure) . In other words, the EMSK-VRK 706, may depend from an authentication procedure to authenticate, for the domain1 402 and the domain2 404, a network entity of the domain1 402 and one or more network entities of the domain2 404. A first final root key, a Virtual Sub-root Key (VSK) 707, may be derived from the VRK 705, and may be used for key derivation for security protection on communications between the user1 401 and the user2 403. A second final root key, a Real-Virtual Root Key (RVRK) 708, may be derived from the VRK 705, and may be used for key derivation for security protection on communications related to the user1 401 in the cross-domain. In other words, the VRK 705, and consequently each of the VSK 707 and the RVRK 708, may be used for terminal key derivation for respective communications between a network entity of the domain1 402 and each of one or more network entities of the domain2 404. In some embodiments, the VRK 705 may be considered a second root key, which may be configured for terminal key derivation for respective communications between a first-domain NE in a first network domain and each of one or more second-domain NEs in a second network domain connected to the first network domain. In some embodiments, the first-domain NE is a first user (user1) , the one or more second-domain NEs includes a second user (user2) and a second network function, the VSK 707 may be considered a third root key, which may be derived from the second root key and may be used for terminal key derivation for respective communications between the first user in the first network domain and the second user in the second network domain. In some embodiments, the RVRK 708 may be considered a fourth root key, which may be used for terminal key derivation for respective communications between the first user in the first network domain and the second network function in the second network domain.

The RRK 703 and the VRK 705 may be confident in the domain1 402 and the domain2 404. Key derivation from root keys may be only identified by their domains. For example, terminal keys 600 derived from the RRK 703 may be used for security protection on communication in the domain1 402 and may not be able to be identified by any functions in the domain2 404.

As shown in FIG. 7C, a user2 403 in the domain2 404 may have two types of root keys, the domain2 may be considered as the first network domain:

● A VRK 705 for derivation of final root keys. The VRK 705 may be derived as an intermediary root key from an EMSK-VRK 706 that is negotiated during a primary authentication and key agreement procedure (i.e., a second negotiated key generated during a mutual authentication procedure) . In other words, the EMSK-VRK 706, may depend from an authentication procedure to authenticate, for the domain1 402 and the domain2 404, a network entity of the domain1 402 and one or more network entities of the domain2 404. A first final root key, a VSK 707, may be derived from the VRK 705 and may be used for key derivation for security protection on communications between the user1 401 and the user2 403. A second final root key, a Virtual-Real Root Key (VRRK) 710, may be derived from VRK 705 and may be used for key derivation for security protection on communications related to the user2 403 in cross-domains. In other words, the VRK 705, and consequently each of the VSK 707 and the VRRK 710, may be used for terminal key derivation for respective communications between a network entity of the domain2 404 and each of one or more network entities of the domain1 402. In some embodiments, the VRK 705 may be considered a second root key, which may be configured for terminal key derivation for respective communications between a first-domain NE in a first network domain and each of one or more second-domain NEs in a second network domain connected to the first network domain. In some embodiments, the domain 1 402 can be the second network domain, the VSK 707 may be considered a third root key, which may be derived from the second root key and may be used for terminal key derivation for respective communications between a first  user (user2) in the first network domain and a second user (user1) in the second network domain. In some embodiments, the RVRK 708 may be considered a fourth root key, which may be used for terminal key derivation for respective communications between a first user in the first network domain and a second network function in the second network domain.

● A Virtual Intra-root Key (VIK) 709, which may be for a metaverse and may be used for key derivation for security protection on communications in the domain2 404. In other words, the VIK 709 may be configured for terminal key derivation for respective communications between a network entity of the domain2 404 and each of one or more further network entities of the domain2 404. The VIK 709 may be derived from an EMSK-VIK 711 that is negotiated during a primary authentication and key agreement procedure (i.e., a first negotiated key generated during a mutual authentication procedure) . In other words, the EMSK-VIK 711 may depend from an authentication procedure to authenticate for the domain2 404 one or more network entities of the domain2 404. In some embodiments, the VIK 709 may be considered a first root key, which may be configured for terminal key derivation for respective communications between a first-domain NE in a first network domain and each of one or more further first-domain NEs in that first network domain. In some embodiments, the first-domain NE is a first user (user2) , the one or more further first-domain NEs includes a first network function.

The method described above can be implemented by the first user or any network functions in the first network domain. The first user and the second user can be the 6G customer illustrated in previous paragraph or the first user can be any virtual representative of the 6G customer. The network functions can be any network function or network entity in core network or in radio access network.

FIG. 8 shows root keys for entities in the 6GS, according to an embodiment of the present disclosure. Terminal keys 600 on the user1 401 side and a core network function 801 side (i.e., only in domain1 402) may be derived from an RRK 703, which may be used for security protection on communications between the user1 401 and the core network 801 in domain1 402. Terminal keys 600 on the user1 401 side and user2 403 side (i.e., cross-domain) may be derived from a VSK 707, which may be used for security protection on communications between the user1 401 and the user2 403. Terminal keys 600 on the user1 401 side and one or more functions 802 in domain2 404 side (i.e., cross-domain) may be derived from a RVRK 708, which may be used for security protection on communications related to user1 401 in the cross-domain. Terminal keys 600 on the user2 403 side and the one or more functions 802 in domain2 404 side (i.e., only in domain2 404) may be derived from a VIK 709, which may be used for security protection on communications related to the user2 403 in domain2 404. Terminal keys 600 on the user2 403 side and core network function 801 in domain1 side (i.e., in the cross-domain) could be derived from a VRRK 710, which may be used for security protection on communications related to the user2 403 in the cross-domain.

In contrast with existing techniques having a key derivation framework with a single root key, embodiments of the present invention may support multiple root keys. Embodiments may provide a framework, or architecture, for multiple root keys for key derivation in cross-domains. In embodiments, the architecture of root keys may not be a line structure, akin to that used in the 5GS, but rather it may have two separate branches wherein one branch may be a line structure and the other branch may be a tree structure. This architecture of root keys may provide security protection for unique communications in 6GS. Embodiments of the present disclosure may enhance security and resist attacks.

A 6G System is expected to allow for use of encryption and integrity protection algorithms for signaling keys and data keys, derived from different root keys. The keys used for signaling protection and data protection, may be dependent on the algorithms with which they are used. All keys may be generated by network functions or users. The system model described in relation to FIGs. 5 and 6 may be used herein as an example to discuss how to generate keys for communications in the cross-domain. According to FIGs. 5 and 6, the following terminals keys may be available for the user2 403 side: K_6GWuser may be used for secure communication between the user2 403 and the 6G-GW 501, K_XGWuser may be used for secure communication between the user2 403 and the XaaS-GW 503, K_user may be used for secure protection between the user1 401 and the user2 403, K_SXGWuser may be used for secure protection on communications between the user2 403 and the SubXaaS-GW 504. Similarly, the following terminal keys 600 may be available for the user1 401 side: K1_6GWuser may be used for secure communication between the user1 401 and the 6G-GW 501, K1_XGWuser may be used for secure communication between the user1 401 and the XaaS-GW 503. In  some embodiments, one or more of the above terminal keys 600 may be used for encryption and integrity protection algorithms for signaling keys and data keys.

Table 1 provided below shows inputs for key derivation, in accordance with embodiments of the present disclosure. In some cases one or more input may be used for key derivation. The *COUNT value, as an input, may indicate a number of uplink/downlink messages in different communications.

Table 1: Definition and inputs for keys

FIG. 9 shows an example of key derivation from root keys, in accordance with an embodiment of the present disclosure. FIG. 9 shows a framework for key derivation for signaling protections related to the user2 403 side. A framework for key derivation for data protections may be similar to the framework shown in FIG. 9. In the framework of FIG. 9, a root key, VIK 709, may be generated by a trust function in the domain2 404 according to a shared-key, the EMSK-VIK 711. The EMSK-VIK 711 may be negotiated between an authentication server 901 in the domain2 404 and the user2 403 after a successful authentication. Terminals keys (e.g., K_{C/M-XGWuser-int}, K_{C/M-XGWuser-enc}) may be derived from the VIK 709 and configured to the user2 403 and a XaaS-GW 503. Similarly, terminals keys (e.g., K_{C/M-SXGWuser-int}, K_{C/M-SXGWuser-enc}) may be derived from an intermediate key K_GW  that is derived from the VIK 709, and may be configured to the user2 403 and a SubXaaS-GW 504. In some embodiments, these keys may be generated by a trust function (e.g., a key management function) , and configured into functions, or may be generated by user2 403.

FIG. 10A provides a procedure for key configuration between the user1 401 and user2 403 according to the example shown in FIG. 5, FIG. 7B, FIG. 7C and according to an embodiment of the present disclosure. The 6G-SMF 1001 shown in FIG. 10A may be a network function in the domain1 402, e.g., a SMF or an AMF. The 6G-AUSF 1002 shown in FIG. 10A may be a trust network function in the domain1 402, e.g., an AUSF. Similarly, the XaaS-AUSF 1003 shown in FIG. 10A may be a trust network function that is deployed into the domain2 404 by the XaaS provider. At action 1004, the user1 401 may send a request to the 6G-SMF 1001. The request may be, for example, a service request, or access request, or session establishment request. The request may include an ID of the user1 401. At action 1005, if the uer1 401 and user2 403 do not trust each other, the 6G-SMF 1001 may send an authentication request to the 6G-AUSF 1002. The request may include information about the user1 401, such as an ID of the user1 401, and/or an authentication credential for the user1 401. At action 1006, the 6G-AUSF 1002 may trigger an authentication among users, and networks. A person of skill in the art will appreciate how to implement the authentication, which may include current techniques such as the Extensible Authentication Protocol (EAP) method, or, the Authentication and Key Agreement (AKA) method in 5GS) . After a successful authentication, each entity may generate a random value that may be used for generating master secrets between different entities. For example, random values a, b, c, and d, may be generated by the user1 401, 6G-AUSF 1002, XaaS-AUSF 1003, and user2 403, respectively. At action 1007, the 6G-AUSF 1002 may trigger a procedure for exchanging random values. In some embodiments, this procedure may be merged into action 1006. For example, in existing methods, the AKA protocol is a process that is based on the challenge–response pair, and the AKA protocol allows the communicating entities to mutually authenticate each other while exchanging authenticated session key (or master secrets) and establishing secured communication channels. Further, this has been proposed as a solution to support an efficient three-party authenticated key agreement protocol for fog-based vehicular ad-hoc networks. At action 1008, the 6G-AUSF 1002 may send an authentication response to the 6G-SMF 1001. This response may indicate a successful authentication and may include an ID of user2 403. At action 1009, the 6G-SMF 1001 may determine a service ID if the request is a service request or session establishment request. At action 1010, the 6G-SMF 1001 may send a response according to the request, as described in relation to action 1004, from the user1 401. This response may include the ID of the user2 403 and may include the service ID. At action 1011, the user1 401 may calculate master keys according to the exchanged random values, and may generate an EMSK-VRK 706. The EMSK-VRK 706 may be derived from a master key that is associated with a master secret that is linked to the random values that may be known by the user1 401, user2 403, and 6G-AUSF 1002. The user1 401 may generate a VRK 705 according to the EMSK-VRK 706. At action 1012, the user1 401 may send a request for a service ID to the 6G-SMF 1001. This request may include the ID of the user1 401 and the ID of the user2 403. At action 1013, the 6G-SMF 1001 may send a response back to the user1 401. This response may include the service ID. At action 1014, the user1 401 may set up an ID for the VRK 705, generate security contexts for the user1 401, and generate terminal keys 600 (e.g., K_C/M-user-enc, K_C/M-user-int, K_{data-user-enc}, and K_{data-user-int}) according to the security contexts for the user1 401. The security contexts for the user1 401 may include one or more parameters: a C/M_algorithm_enc ID, C/M_algorithm_int ID, data_algorithm_int ID, data_algorithm_enc ID, and/or *COUNT value. In some embodiments, the *COUNT value may indicate the number of uplink/downlink signaling messages. At action 1015, the user1 401 sends a request for key configuration (KEY_Config) to the user2 403. This request may include at least one of: the ID of the user2 403, the service ID, security contexts for the user1 401, the ID of the VRK 705, and/or the ID of the user1 401, the security context is used for terminal key derivation for respective communications between the user1 and the user2. At action 1016, the user2 403 may calculate master keys according to the exchanged random values, and generate the EMSK-VRK 706 for itself. The user2 403 may generate for itself the VRK 705 according to the EMSK-VRK 706. The user2 403 may generate terminal keys 600 (e.g., a K_C/M-user-enc, K_C/M-user-int, K_{data-user-enc}, K_{data-user-int}) according to the security contexts for the user1 401. At action 1017, the user2 403 may send a key configuration (KEY_Config) response to the 6G-AUSF 1002. This response may indicate successful configuration of the terminal keys 600.

FIG. 10B provides a procedure for key configuration between a 6G-GW 501 and user2 403, in accordance with the example shown in FIG. 5, FIG. 7B, FIG. 7C and an embodiment of the present disclosure. The 6G-SMF 1001 shown in FIG. 10B  may be a network function in domain1 402, e.g., a SMF, or an AMF. The 6G-GW 501 may be a network function in the domain1 402, e.g., an AMF, or a UPF. The 6G-AUSF 1002 shown in FIG. 10B may be a trust network function in the domain1 402, such as an AUSF. Similarly, the XaaS-AUSF 1003 shown in FIG. 10B may be a trust network function that may be deployed into the domain2 404 by a XaaS provider. At action 1018, the 6G-AUSF 1002 may trigger an authentication among users, and networks. A person of skill in the art will appreciate how to implement the authentication, which may include current techniques (e.g. the EAP method, or, the AKA method in 5GS) . After a successful authentication, each entity may generate a random value that may be used for generating master secrets between different entities. For example, random values a, b, c, and d, may be generated by the user1 401, 6G-AUSF 1002, XaaS-AUSF 1003, and user2 403, respectively. At action 1019, the 6G-AUSF 1002 may trigger a procedure for exchanging the random values. In some embodiments, this procedure may be merged into action 1018. For example, in existing methods, the AKA protocol is a process that is based on the challenge–response pair, and the AKA protocol allows the communicating entities to mutually authenticate each other while exchanging authenticated session keys (or master secrets) and establishing secured communication channels. Further, this has been proposed as a solution to support an efficient three-party authenticated key agreement protocol for fog-based vehicular ad-hoc networks. At action 1020, the 6G-AUSF 1002 may calculate master keys according to the exchanged random values, and may generate an EMSK-VRK 706. The EMSK-VRK 706 may be derived from a master key that is associated with a master secret that may be linked to the random values known by the user1 401, user2 403, and 6G-AUSF 1002. The 6G-AUSF 1002 may generate a VRK 705 according to the EMSK-VRK 706. At action 1021, the 6G-AUSF 1002 may send a request for a service ID to the 6G-SMF 1001. This request may include an ID of the user2 403, and/or an ID of the user1 401. At action 1022, the 6G-SMF 1001 may determine the service ID. At action 1023, the 6G-SMF 1001 may send a response back to the user1 401. This response may include the service ID. At action 1024, the 6G-AUSF 1002 may send a key identification (KEY_ID) request to the user1 401. This request may include the ID of user2 403. At action 1025, the user1 401 may send a KEY_ID response to the 6G-AUSF 1002. This response may include an ID of the VRK 705. At action 1026, the 6G-AUSF 1002 may generate security contexts for the user2 403, and generate terminal keys 600 (e.g., K_{C/M-6GWuser-enc}, K_{C/M-6Gwuser-int}, K_{data-6Gwuser-enc}, and K_{data-6Gwuser-int}) according to the security contexts for the user2 403. The security contexts for the user2 403 may include one or more parameters: a C/M_algorithm_enc ID, C/M_algorithm_int ID, data_algorithm_int ID, data_algorithm_enc ID, and/or *COUNT value. In some embodiments, *COUNT value may indicate the number of uplink/downlink signaling messages. At action 1027, the 6G-AUSF 1002 may send a KEY_Config request to the 6G-GW 501. This request may include terminal keys 600, the ID of the VRK 705, and/or the ID of the user2 403. At action 1028, the 6G-GW 501 may keep the terminal keys 600, ID of the VRK 705, and/or the ID of user2 403. At action 1029, the 6G-GW 501 may send a KEY_Config response to the 6G-AUSF 1002. This response may indicate successful configuration of the terminal keys 600. At action 1030, the 6G-AUSF 1002 may send a KEY_Config request to the user2 403. This request may include the security contexts for the user2 403, and/or the ID of the VRK 705. The security context is used for terminal key derivation for respective communications between the user2 and the 6G-GW in domain1 402. At action 1031, the user2 403 may calculate master keys according to the exchanged random values, and may generate the EMSK-VRK 706 for itself. The user2 403 may generate the VRK 705 for itself according to EMSK-VRK 706. The user2 403 may generate terminal keys 600 (e.g., K_{C/M-6Gwuser-enc}, K_{C/M- 6Gwuser-int}, K_{data-6Gwuser-enc}, K_{data-6Gwuser-int}) according to the security contexts for the user2 403. At action 1032, the user2 403 may send a KEY_Config response to the 6G-AUSF 1002. This response may indicate successful configuration of the terminal keys 600.

FIG. 10C shows a procedure for key configuration between a XaaS-GW 503, a SubXaaS-GW 504, and a user2 403, according to the example shown in FIG. 5, FIG. 7B, FIG. 7C and an embodiment of the present disclosure. The XaaS-AUSF 1033 shown in FIG. 10C may be a trust network function that may be deployed into the domain2 404 by a XaaS provider. At action 1034, the XaaS-AUSF 1033 may trigger an authentication among users and obtains an EMSK-VIK 711. A person of skill in the art will appreciate how to implement the authentication. At action 1035, the XaaS -AUSF 1033 may generate a VIK 709 according to the EMSK-VIK 711, and may set up an ID for the VIK 709. At action 1036, the XaaS -AUSF 1033 may obtain a service ID from a network function in the domain2 404. At action 1037, the XaaS-AUSF 1033 may generate security contexts, and generate terminal keys (e.g., K_{C/M-XGWuser-enc}, K_{C/M-XGWuser-int}, K_{data-XGWuser-enc}, and K_{data-XGWuser-int}) for the XaaS-GW 503, and  terminal keys 600 (e.g., K_{C/M-SXGWuser-enc}, K_{C/M-XSGWuser-int}, K_{data-XSGWuser-enc}, K_{data-XSGWuser-int}) for the SubXaaS-GW 504. The security contexts may include one or more parameters: a C/M_algorithm_enc ID, C/M_algorithm_int ID, data_algorithm_int ID, data_algorithm_enc ID, and/or *COUNT value. In some embodiments, the *COUNT value may indicate the number of uplink/downlink signaling messages. At action 1038, the XaaS-AUSF 1033 may send a KEY_ID request to the XaaS-GW 503. This request may include an ID of the user2 403, terminal keys for the XaaS-GW 503, and/or the ID of VIK 709. At action 1039, the XaaS -GW 503 may keep the terminal keys 600 for the XaaS-GW 503, the ID of VIK 709, and/or the ID of user2 403. At action 1040, the XaaS-GW 503 may send a KEY_Config response to the XaaS-AUSF 1033. This request may indicate successful configuration of the terminal keys 600. At action 1041, the XaaS-AUSF 1033 may send a KEY_ID request to the SubXaaS-GW 504. This request may include the ID of the user2 403, terminal keys 600 for the SubXaaS-GW 504, and/or the ID of the VIK 709. At action 1042, the SubXaaS-GW 504 may keep the terminal keys 600 for the SubXaaS-GW 504, the ID of the VIK 709, and/or the ID of the user2 403. At action 1043, the SubXaaS-GW 504 may send a KEY_Config response to the XaaS-AUSF 1033. This request may indicate successful configuration of the terminal keys 600. At action 1044, the XaaS-AUSF 1033 may send a KEY_Config request to the user2 403. This request may include security contexts and/or the ID of the VIK 709. The security context is used for terminal key derivation for respective communications between the user2 and network function in domain2. At action 1045, the user2 403 may generate for itself the VIK 709 according to the EMSK-VIK 711. The user2 403 may further generate terminal keys 600 (e.g., K_{C/M-XGWuser-enc}, K_{C/M-XGWuser-int}, K_{data-XGWuser-enc}, K_{data-XGWuser-int}, K_{C/M- SXGWuser-enc}, K_{C/M-XSGWuser-int}, K_{data-XSGWuser-enc}, and K_{data-XSGWuser-int}) according to the security contexts. At action 1046, the user2 403 may send a KEY_Config response to the XaaS-AUSF 1033. This response may indicate successful configuration of the terminal keys 600.

In some embodiments, the XaaS-GW 503 and the SubXaaS-GW 504 may have functionalities for key generation and security context maintenance. Under these scenarios, the XaaS-AUSF 1033 may send a KEY-Config request to the XaaS-GW 503. This request may include the VIK 709, the ID of the VIK 709 and/or security contexts. This request may further include the service ID.The XaaS-GW 503 may generate terminal keys for the XaaS-GW 503 according to the VIK 709. Then, the XaaS-GW 503 may generate a key K_GW, and send a KEY-Config request to the SubXaaS-GW 504. This request may include the K_GW, the ID of the VIK 709 and/or security contexts. The SubXaaS-GW 504 may generate terminal keys 600 for the SubXaaS-GW 504. Similarly, the SubXaaS-GW 504 may send a KEY-Config request to the user2 403. This request may include the ID of the VIK 709 and/or security contexts. Then, the user2 403 may generate the VIK 709 for itself according to EMSK-VIK 711. The user2 403 may generate terminal keys 600 (e.g., K_{C/M-XGWuser-enc}, K_{C/M-XGWuser-int}, K_{data-XGWuser-enc}, K_{data-XGWuser-int}, K_{C/M-SXGWuser- enc}, K_{C/M-XSGWuser-int}, K_{data-XSGWuser-enc}, K_{data-XSGWuser-int}) according to the security contexts.

In another embodiment, similar to that described in relation to FIG. 10C, a key configuration procedure may be performed between a user1 401 and a 6G-GW 501, instead of between the XaaS-GW 503, the SubXaaS-GW 504, and the user2 403. Here, an EMSK-RRK 704 may be negotiated during an authentication and obtained by the user1 401 and a 6G-AUSF 1002. The 6G-AUSF 1002 may generate a RRK 703 according to the EMSK-RRK 704, set an ID of the RRK 703, and generate security contexts. In some embodiments, the 6G-AUSF 1002 may generate terminal keys 600 (e.g., K1_{C/M-6GWuser-enc}, K1_{C/M-6Gwuser-int}, K1_{data- 6Gwuser-enc}, and K1_{data-6Gwuser-int}) for the 6G-GW 501. Inputs for key derivation may include those provided in Table 1. Then, the 6G-AUSF 1002 may send the terminal keys 600 to the 6G-GW 501 for key configuration. The 6G-GW 501 may keep the terminal keys 600 and the ID of the RRK 703. In some embodiments, the 6G-GW 501 may generate terminal keys 600 for 6G-GW 501 by itself according to the RRK 703 and security contexts.

On the user1 401 side, the 6G-AUSF 1002 may send the ID of the RRK 703 and security contexts to the user2 403. The user2 403 may generate the RRK 703 for itself according to EMSK-RRK 704 and security contexts, and then generate terminal keys 600 (e.g., K1_{C/M-6GWuser-enc}, K1_{C/M-6Gwuser-int}, K1_{data-6Gwuser-enc}, and K1_{data-6Gwuser-int}) according to the RRK 703.

In some embodiments, currently available techniques may be used to configure keys to the 6G-GW 501 and the user1 401.

FIG. 10D provides a procedure for key configuration between a XaaS-GW 503 and a user1 401, in accordance with the example shown in FIG. 5, FIG. 7B, FIG. 7C and an embodiment of the present disclosure. The 6G-SMF 1001 shown in FIG. 10D may be a network function in the domain1 402, e.g., a SMF or AMF. The 6G-GW 503 could be a network function in domain1, e.g., AMF, or UPF. The 6G-AUSF 1002 shown in FIG. 10D may be a trust network function in the domain1 402, e.g., an AUSF. At action 1047, the 6G-AUSF 1002 may trigger an authentication among network entities and obtain an EMSK-VRK 706. A person of skill will appreciate how to implement the authentication. At action 1048, the 6G-AUSF 1002 may generate a VRK 705 according to the EMSK-VRK 706. At action 1049, the 6G-AUSF 1002 may send a request for a service ID to the 6G-SMF 1001. This request may include the ID of the user2 403, and an ID of the user1 401. At action 1050, the 6G-SMF 1001 may determine the service ID. At action 1051, the 6G-SMF 1001 may send a response back to the user1 401. This response may include the service ID.At action 1052, the 6G-AUSF 1002 may send a KEY_ID request to the user1 401. This request may include the ID of the user2 403. At action 1053, the user1 401 may send a KEY_ID response to the 6G-AUSF 1002. This response may include an ID of the VRK 705. At action 1054, the 6G-AUSF generates a RVRK 708 according to the VRK 705, and generates security contexts. Then, the 6G-AUSF 1002 may generate terminal keys 600 (e.g., K1_{C/M-XGWuser-enc}, K1_{C/M-XGwuser-int}, K1_{data-XGwuser-enc}, and K1_{data-XGwuser-int}) according to the security contexts. At action 1055, the 6G-AUSF 1002 may send a KEY_Config request to the XaaS-GW 503. This request may include the terminal keys 600, the ID of the VRK 705, and/or the ID of the user1 401. At action 1056, the XaaS-GW 503 may keep the terminal keys 600, the ID of the VRK 705, and/or the ID of the user1 401. At action 1057, the XaaS-GW 503 may send a KEY_Config response to the 6G-AUSF 1002. This request may indicate successful configuration of the terminal keys 600. At action 1058, the 6G-AUSF 1002 may send a KEY_Config request to the user1 401. This request may include the security contexts. The security context is used for terminal key derivation for respective communications between the user1 and network function in domain1. At action 1059, the user1 401 may generate the RVRK 708 for itself according to the VRK 705. The user1 401 may generate terminal keys 600 according to the security contexts. At action 1060, the user1 401 may send a KEY_Config response to the 6G-AUSF 1002. This request may indicate successful configuration of the terminal keys 600.

In some embodiments, a procedure for dynamic key negotiation between a user1 401 and a user2 403 may be implemented after a channel between the user1 401 and the user2 403 is setup. Currently available techniques (e.g. a Diffie-Hellman key exchange) may be used to securely exchange a master key between the user1 401 and the user2 403 over the public channel. Then, each of the user1 401 and the user2 403 may generate terminal keys 600 (e.g., K_C/M-user-enc, K_C/M-user-int, K_{data-user-enc}, and K_{data-user-int}) according to the master keys. Note that, inputs for terminal keys 600 may be securely exchanged between the user1 401 and the user2 403 using the master key.

Embodiments of the present disclosure may provide advantageous effects over the prior art. This can include security enhancements: terminal key derivation from multiple root keys may prevent attacks by providing a unique root key for communications in cross-domains. Advantages can further include customized security protection: different types of terminal keys 600 may be used for security protections on different sessions (e.g., hop-to-hop sessions, or end-to-end sessions) .

The word “a” or “an” when used in conjunction with the term “comprising” or “including” in the claims and/or the specification may mean “one” , but it is also consistent with the meaning of “one or more” , “at least one” , and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise. The phrase "at least one" means one or more, and "a plurality of" means two or more. In addition, "and/or" describes an association relationship of associated objects, and indicates that there may be three relationships. For example, A and/or B may indicate cases including “only A” , “both A and B” , and “only B” , where A and B may be singular or plural. The character "/" generally indicates that the associated objects are in an OR relationship. "At least one of the following items" or a similar expression thereof refers to any combination of these items, including any combination of a single item or a plurality of items. For example, “at least one of a, b, or c” may represent “a” , “b” , “c” , “a and b” , “a and c” , “b and c” , or “a, b and c” , where a, b, and c may be a single or multiple form.

The terms “coupled” , “coupling” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements  or devices via a mechanical element depending on the particular context. The term “and/or” herein when used in association with a list of items means any one or more of the items comprising that list.

Although a combination of features is shown in the illustrated embodiments, not all of them need to be combined to realize the benefits of various embodiments of this disclosure. In other words, a system or method designed according to an embodiment of this disclosure will not necessarily include all features shown in any one of the Figures or all portions schematically shown in the Figures. Moreover, selected features of one example embodiment may be combined with selected features of other example embodiments.

Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

The following table provides acronyms, abbreviations, and initialisms used throughout the present disclosure.

Claims (27)

1. A method comprising:

   generating a first root key configured for terminal key derivation for respective communications between a first-domain network entity (NE) in a first network domain and each of one or more further first-domain NEs in the first network domain,

   and

   generating a second root key configured for terminal key derivation for respective communications between the first-domain NE and each of one or more second-domain NEs in a second network domain connected to the first network domain.
2. The method of claim 1 wherein:

   the first-domain NE is a first user in the first network domain,

   the one or more further first-domain NEs includes a first network function,

   and

   the first root key is used for terminal key derivation for respective communications between the first user and the first network function.
3. The method of claim 1 wherein:

   the first-domain NE is a first user;

   the one or more second-domain NEs includes a second user and a second network function;

   and

   the second root key is used for deriving a third root key and a fourth root key, the third root key used for terminal key derivation for respective communications between the first user and the second user, the fourth root key used for terminal key derivation for respective communications between the first user and the second network function.
4. The method of claim 3, wherein the first root key is generated based on a first negotiated key, the first negotiated key being generated during a mutual authentication procedure.
5. The method of claim 4, wherein the one or more further first-domain NEs includes a first network function, before generating the first root key, the method further comprises:

   receiving a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the first network function;

   generating a master key according to random values;

   and

   generating the first negotiated key based on the master key.
6. The method of claim 5, wherein the method further comprises: deriving, from the first root key and based on the security context, a terminal key for respective communications between the first user and the first network function.
7. The method of claim 3, wherein the second root key is generated based on a second negotiated key, the second negotiated key being generated during a mutual authentication procedure.
8. The method of claim 7, wherein before generating the second root key, the method further comprises:

   receiving, a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the second user;

   generating a master key according to random values;

   and

   generating the second negotiated key based on the master key.
9. The method of claim 8, wherein the method further comprises: deriving, from the third root key and based on the security context, a terminal key for respective communications between the first user and the second user.
10. The method of claim 7, wherein before generating the second root key, the method further comprises:

    receiving, a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the second network function;

    generating a master key according to random values;

    and

    generating the second negotiated key based on the master key.
11. The method of claim 10, wherein the method further comprises: deriving, from the fourth root key and based on the security context, a terminal key for respective communications between the first user and the second network function.
12. The method of claim 7, wherein the method further comprises:

    sending a service request including a first identifier (ID) of the first user;

    receiving a response including a second ID of the second user, the response being in response to the first service request;

    generating a master key based on random values;

    generating a first negotiated key based on the master key;

    generating security context, the security context being used for terminal key derivation for respective communications between the first user and the second user;

    deriving, from the second root key and based on the security context, a terminal key for communication between the first user and the second user;

    and

    sending the security context to the second user.
13. An apparatus, configured to perform the method to any one of claims 1 to 12.
14. The apparatus of claim 13, wherein comprising:

    a processing unit configured to generate a first root key configured for terminal key derivation for respective communications between a first-domain network entity (NE) in a first network domain and each of one or more further first-domain NEs in the first network domain,

    and generate a second root key configured for terminal key derivation for respective communications between the first-domain NE and each of one or more second-domain NEs in a second network domain connected to the first network domain.
15. The apparatus of claim 14, wherein:

    the first-domain NE is a first user in the first network domain,

    the one or more further first-domain NEs includes a first network function,

    and

    the first root key is used for terminal key derivation for respective communications between the first user and the first network function.
16. The apparatus of claim 14, wherein:

    the first-domain NE is a first user;

    the one or more second-domain NEs includes a second user and a second network function;

    and

    the second root key is used for deriving a third root key and a fourth root key, the third root key used for terminal key derivation for respective communications between the first user and the second user, the fourth root key used for terminal key derivation for respective communications between the first user and the second network function.
17. The apparatus of claim 16, wherein the first root key is generated based on a first negotiated key, the first negotiated key being generated during a mutual authentication procedure.
18. The apparatus of claim 17, wherein the one or more further first-domain NEs includes a first network function and, before generating the first root key, the apparatus further comprises a receiving unit configured to:

    receive a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the first network function;

    the processing unit is further configured to generate a master key according to random values;

    and

    generate the first negotiated key based on the master key.
19. The apparatus of claim 18, wherein the processing unit is further configured to: derive from the first root key and based on the security context, a terminal key for respective communications between the first user and the first network function.
20. The apparatus of claim 16, wherein the second root key is generated based on a second negotiated key, the second negotiated key being generated during a mutual authentication procedure.
21. The apparatus of claim 20, wherein before generating the second root key, the processing unit is configured to:

    receive a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the second user;

    the processing unit is further configured to generate a master key according to random values and

    generate the second negotiated key based on the master key.
22. The apparatus of claim 21, wherein the processing unit is further configured to: derive from the third root key and based on the security context, a terminal key for respective communications between the first user and the second user.
23. The apparatus of claim 20, wherein before generating the second root key, the processing unit is configured to:

    receive a request for key configuration, the request including security context, the security context being used for terminal key derivation for respective communications between the first user and the second network function;

    the processing unit is further configured to generate a master key according to random values and

    generate the second negotiated key based on the master key.
24. The apparatus of claim 23, wherein the processing unit is further configured to: derive from the fourth root key and based on the security context, a terminal key for respective communications between the first user and the second network function.
25. The apparatus of claim 20, wherein the apparatus further comprises:

    a transmitting unit configured to:

    send a service request including a first identifier (ID) of the first user;

    a receiving unit configured to:

    receive a response including a second ID of the second user, the response being in response to the first service request;

    the processing unit is further configured to:

    generate a master key based on random values;

    generate a first negotiated key based on the master key;

    generate security context, the security context being used for terminal key derivation for respective communications between the first user and the second user;

    derive from the second root key and based on the security context, a terminal key for communication between the first user and the second user;

    and

    the transmitting unit configured to:

    send the security context to the second user.
26. An apparatus, comprising one or more processors, the one or more processor is configured to execute instructions stored in one or more memory to implement the method of any one of claims 1 to 12.
27. A computer-readable storage medium having instructions stored thereon which, when executed by a one or more processors cause the one or more processors to perform the method of any one of claims 1 to 12.