Technical field

The technology disclosed herein relates generally to the field of communication security in communications networks, and in particular to methods, performed in a network node and communication device, of protecting communication on two or more network instances, network node, communication device, computer programs and computer program products.

Background

Network slicing is a new concept that applies to both Long Term Evolution (LTE) and future fifth generation (5G) radio access technology (RAT) (denoted New Radio, NR, herein). In network slicing logically separated partitions of a network are created, wherein the partitions address different business purposes. These "network slices" may be logically separated to a degree such as to be regarded and managed as networks of their own. The logical network slices may enable operators to provide networks on an as-a service basis and thereby meet a wide range of expected use cases.

A driving force for introducing network slicing is a desired business expansion. Such business expansion is believed to be achievable by improving a cellular operator's ability to offer connectivity services in various business areas besides the currently provided mobile communication services. Such new connectivity services may have different network characteristics, e.g. in view of performance, security, robustness and complexity.

Figure 1 illustrates a possible architecture based on an assumption that there will be one shared Radio Access Network (RAN) infrastructure 1 that will connect to several Evolved Packet Core (EPC) instances 2a, 2b, in particular one EPC instance per network slice (Slice 1, Slice 2). As the EPC functions are being virtualized it is assumed that the operator can instantiate a new Core Network (CN) when a new slice should be supported. A communication device 3 (in the following exemplified by User Equipment, UE) may use a first slice (Slice 1) and a second slice (Slice 2). The first slice (Slice 1) may for example be a Mobile Broadband slice and the second slice (Slice 2) may for example be a Machine Type Communication network slice. LTE is used here as an exemplary RAT, but this may be applicable also for other RATs, e.g. 5G.

In such sliced network, with UEs that are capable of attaching to multiple network slices, issues will arise in view of how to handle the corresponding different connections, in particular in view of distribution of multiple independent keys and their derivatives used for the encryption and integrity protection of user plane (UP) traffic or slice specific non-access stratum (NAS) signaling, which is currently not supported by the standard.

Summary

An objective of the present teachings is to address and overcome the above

mentioned foreseen difficulties. A particular objective is to provide solutions for improving security in a communications network. This objective and others are achieved by the methods, devices, computer programs and computer program products according to the appended independent claims, and by the embodiments according to the dependent claims.

The objective is according to an aspect achieved by a method performed in a network node of protecting communication on two or more network instances, wherein the two or more network instances are used in serving a communication device. The method comprises obtaining, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the communication device on the respective network instances, and determining a joint key for use in protecting shared communication with the communication device on the two or more network instances.

The method provides a number of advantages. For instance, the method enables slice separation on user plane and slice specific NAS, whereby improvement of the security of a sliced network is achieved. Further, any issues relating to distribution of multiple independent keys and their derivatives used for the encryption and integrity protection of user plane (UP) or slice specific non-access stratum (NAS) not supported by the standard today, are avoided. The objective is according to an aspect achieved by a computer program for a network node for protecting communication on two or more network instances. The computer program comprises computer program code, which, when executed on at least one processor on the network node causes the network node to perform the method as above.

The objective is according to an aspect achieved by a computer program product comprising a computer program as above and a computer readable means on which the computer program is stored.

The objective is according to an aspect achieved by a network node for protecting communication on two or more network instances, wherein the two or more network instances are used in serving a communication device. The network node is configured to: obtain, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the

communication device on the respective network instances, and to determine a joint key for use in protecting shared communication with the communication device on the two or more network instances.

The objective is according to an aspect achieved by a method performed in a communication device of protecting communication on two or more network instances, wherein the two or more network instances are used in serving the communication device. The method comprises obtaining, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the network node on the respective network instances, and determining a joint key for use in protecting communication with the network node on the two or more network instances.

The objective is according to an aspect achieved by a computer program for a network node for protecting communication on two or more network instances. The computer program comprises computer program code, which, when executed on at least one processor on the communication device causes the communication device to perform the method as above. The objective is according to an aspect achieved by a computer program product comprising a computer program as above and a computer readable means on which the computer program is stored.

The objective is according to an aspect achieved by a communication device for protecting communication on two or more network instances, wherein the two or more network instances are used in serving the communication device. The communication device is configured to obtain, for each of the two or more network instances, a respective specific key for use in protecting session specific

communication with a network node on the respective network instances, and determine a joint key for use in protecting communication with the network node on the two or more network instances.

Further features and advantages of the embodiments of the present teachings will become clear upon reading the following description and the accompanying drawings.

Brief description of the drawings

Figure l illustrates a network slicing concept.

Figure 2 illustrates an environment, in particular an LTE architecture, in which embodiments according to the present teachings may be implemented.

Figure 3 illustrates an architecture according to the present teachings.

Figure 4 illustrates a first exemplary key hierarchy.

Figure 5 illustrates steps performed in a communication system when a UE attaches to a first network slice.

Figure 6 illustrates a second exemplary key hierarchy.

Figure 7 illustrates steps of performed in a communication system when a UE attaches to a first network slice.

Figure 8 illustrates a third exemplary key hierarchy. Figure 9 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

Figure 10 illustrates a fourth exemplary key hierarchy.

Figure 11 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

Figure 12 illustrates a fifth exemplary key hierarchy.

Figure 13 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

Figure 14 illustrates a sixth exemplary key hierarchy.

Figure 15 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

Figure 16 illustrates a seventh exemplary key hierarchy. In embodiments according to this key hierarchy, there are no separate ESM keys or EMM keys, the key joining is performed in a node of the RAN and there are separate UP key(s).

Figure 17 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

Figure 18 illustrates a flow chart over steps of an embodiment of a method in a network node in accordance with the present teachings.

Figure 19 illustrates network entities of a communication system comprising means for implementing embodiments of methods in accordance with the present teachings.

Figure 20 illustrates a network node comprising function modules/software modules for implementing methods in accordance with the present teachings.

Figure 21 illustrates a flow chart over steps of an embodiment of a method in a communication device in accordance with the present teachings.

Figure 22 illustrates a communication device comprising means for implementing embodiments of methods in accordance with the present teachings. Figure 23 illustrates a communication device comprising function modules/software modules for implementing methods in accordance with the present teachings.

Detailed description

In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding. In other instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description with unnecessary detail. Same reference numerals refer to same or similar elements throughout the description.

For sake of completeness and to provide a thorough understanding of the present teachings the non-access stratum (NAS) and Access Stratum (AS) are first described briefly. The NAS is a functional layer for example in the Universal Mobile

Telecommunications System (UMTS), LTE and 5G wireless telecom protocol stacks between the core network (e.g. Mobility Management Entity, MME, thereof, or Mobile Switching Center (MSC)/Serving General Packet Radio Service Support Node (SGSN)) and a user equipment (UE). This layer is used for managing the

establishment of communication sessions and for maintaining continuous

communications with the UE as it moves. It is noted that NAS traffic may comprise NAS signaling, but also user plane signaling transmitted from the UE to the MME. The AS is a functional layer in the UMTS and LTE wireless telecom protocol stacks (and most likely also in 5G wireless protocol stacks being defined) between radio access network (e.g. NodeB, evolved NodeB, eNB, Radio Network controller (RNC) thereof) and the UE. While the definition of the AS is very different between UMTS and LTE (and most likely also in 5G wireless protocol stacks being defined), in both (or all) cases the AS is responsible for transporting data over the wireless connection and managing radio resources.

Figure 2 illustrates an environment, in particular an LTE architecture, in which embodiments according to the present teachings may be implemented. Embodiments according to the present teachings may be implemented in the communication system 10. It is noted that although LTE is used herein as an exemplary

implementation, the teachings are applicable also to other systems and protocols than the specifically mentioned system and protocols. The communications system 10 comprises a radio access network (RAN) 13 comprising radio access nodes 11a, lib (denoted evolved NodeBs, eNBs) communicating over an air interface with

communication devices such as the UEs 14. The communications system 10 also comprises an evolved packet core (EPC) network 15 comprising EPC nodes such as Mobility Management Entity (MME) 12 and Serving Gateway (S-GW) 16. The interface connecting eNBs 11a, lib to the MME/S-GW 12, 16 is denoted Si, while the interface interconnecting peer eNBs 11a, 11b is denoted X2. The air interface of the RAN 13 is denoted Evolved Universal Terrestrial Radio Access (EUTRA(N)). The third generation partnership project (3GPP) is currently working on standardization of Release 15 of the Long Term Evolution (LTE) concept. The communication system 10 may also comprise a Home Subscriber Server (HSS)/Authentication Centre 17 comprising a database containing subscription related information. The HSS/AuC 17 may, for instance, provide keys needed for authentication and authorization of the communication device 14.

It is noted that although UE 14 is used as an example on a communication device, the network slices may be provided to other types of devices, e.g. machine type devices such as sensors, and for various applications. The communication device may be a wireless device, and it is noted that the communication device may be a virtual device running on a hardware platform. A network slice can thus be tailored for the needs of a specific use case, e.g. in view of speed, capacity, coverage, latency etc. The network slice may comprise virtualized network elements and/or physical resources. For instance, a network slice may comprise a virtualized MME (also denoted MME instance) and an eNB. The MME instance may, as suggested herein and as will be described, be separated into a Traffic Handling Function (THF) 21 and Connection Handling Function - control plane (CHF-C) 22a, 22b.

In a sliced network, slices will use the same Radio Resource Control (RRC) plane over the air, and thereby the access stratum is shared. If a Mobility Management Entity (MME) is shared by the slices, then the non-access stratum control plane is also shared. However, for the UE, which can be connected to multiple slices

simultaneously, security separation between the slices might be required, where separate, slice specific keys on the slice specific part of NAS and user plane may provide some security benefits. Currently this cannot be achieved as today's protocol is designed for distribution of one set of security keys. The present teachings address this issue and provide in various aspects improvements in this regards.

Figure 3 illustrates a suggested architecture for meeting the above described security concerns. An architecture is considered wherein the MME functionality is split into two parts, a THF) 21 and a CHF-C 22a, 22b. The THF 21 controls the evolved

Mobility Management signaling (EMM) (related functionality in 5G may be denoted MM) and the CHF-C 22a, 22b controls the evolved Session Management (ESM) (related functionality in 5G may be denoted SM) signaling. The same THF 21 may, as in the illustrated architecture, support more than one CHF-C 22a, 22b, i.e. be part of more than one network slice. When the THF 21 and CHF-C 22a, 22b of the MME are separated, they can be controlled by two separate entities in different trust domains. It may be envisioned that each CHF-C 22a, 22b would want to secure its own ESM traffic. One reason might be that the ESM traffic controls resources in the domain of the corresponding CN Instance (Core NW Instance in the figure) 23a, 23b owner. Due to this the traffic between the UE 14 and the CHF-C 22a, 22b may need to be integrity protected and possibly encrypted. Correspondingly, the THF 21 may want to secure the EMM traffic between itself and the UE 14. This traffic terminates in the domain of the CN control instance 20 (CN CTRL Instance in the figure), which is different from the domain where the CHF-C 22a, 22b resides. Consequently they cannot be based on the same keying material, unless the two entities (not shown in the figure) controlling these domains have strong trust in each other. The latter cannot always be assumed. In today's networks there is only one piece of keying material available from which to derive the keys and that makes it impossible to achieve the split in the trust model under consideration. The entity controlling the CHF-C 22a, 22b needs to trust the entity controlling the THF 21 to some degree regardless of the trust model split; the entity controlling the CHF-C 22a, 22b cannot affect mobility events. In this architecture thus, the CN control instance 20 constitutes the only interface between the RAN 13 and the CN 15 for a particular UE 14 supporting all network slices for this UE 14.

Further, the user plane 24a, 24b may also be affected by this split trust. It is possible that the UE 14 comprises two applications, connected to two different slices

(indicated as Slice 1, Slice 2 in figure 3), the providers of which do not trust each other. If one of the applications is malicious and the two slices were to use the same encryption keys, it may be possible for the malicious application to access data intended for the other application. In order to prevent this, individual encryption keys for the user plane traffic may be desired for the two slices.

Further, the entity controlling the CN instance 23a, 23b may have limited trust in the provider of the CN control instance 20 and only trusts that the eNB is not malicious. The eNB not being malicious may, for instance, be verified via remote attestation that the eNB has booted securely, runs a certain software etc. If this trust exists, the entity controlling the CN instance 23a, 23b could establish individual security for the transport to and from the eNB and thereby ensure that no one else can eavesdrop on the user plane traffic.

Figure 3 also shows an AAA server 18a, 18b located within the CN instances 23a, 23b. It is noted that this is one exemplary embodiment, and that in other embodiments also a separate AAA server (not shown) may be provided in the CN control instance 20. Such separate AAA server may be used for access authentication (related to EMM/MM signaling) while the AAA servers 18a, 18b of the CN instances 23a, 23b may be used for network slice related authorization and/or authentication (related to ESM/SM signaling). In still another exemplary embodiment, an AAA server is provided only in the common CN control instance. In this context it is noted that an exemplary term used in the current application for an AAA server is HSS/AuC (as indicated e.g. in figure 2).

Briefly, methods are presented in various embodiments, for joining of security keys for different slices, resulting in access security for the control plane being based on joint keys and access security for the user plane either being based on the joint keys or on slice specific keys. The joining of security keys can be made in (1) the core network or in (2) the radio access network.

Throughout the description the term "derived from" is used in relation to the determination of various keys. This term may be differently stated as "based on"; in essence a key is used in some way to obtain another key.

Embodiments described with reference to figures 4 and 5 are based on the following main principles: • Access authentication is performed between the UE 14 and the common CN Control instance 20 when the UE 14 attaches to the network (this authentication may also be repeated later on), "common" CN Control instance 20 as used in the description means that the CN Control instance 20 is shared between two or more network slices.

• Network slice specific authentication/authorization is performed between the UE 14 and the network slice specific CN instance 23a when the UE 14 attaches to that particular network slice (this authentication/authorization may also be repeated later on for additional network slices). The resulting keys are used to protect NAS-level ESM signaling between the UE 14 and the slice specific CN instance 23a.

• The keys used for access authentication and network slice specific authentication/ authorization are joined in the CN 15, in particular in the CN control instance 20 and/or CN instance 23a, 23b and used to create keys to protect NAS-level EMM signaling between the UE 14 and the Common CN Control instance 20. The joint key is also used to create a common AS-level key that is used in the RAN (e.g. node 11 thereof) to create keys to protect both control and user plane. This means that same keys are used in RAN/AS-level for all common and slice-specific control and user plane.

Figure 4 illustrates a key hierarchy, wherein use is made of separate ESM and EMM keys, wherein the key joining is performed in the common CN control instance 20, and wherein common UP key(s) are used. As illustrated, separate ESM and EMM keys are used in these embodiments. Access authentication between the UE 14 and the common CN Control instance 20 is performed when the UE 14 attaches to the common CN Control instance 20 and the access authentication is based on a key

KASME _O received from the HSS/AuC 17. In the common CN control instance 20 a joint key KASME-joint is created. If the joint key KASME-joint for the UE 14 does not yet have a value, then the common CN control instance 20 sets the joint key KASME-joint equal to the received key KASME _O . If there already exists a value of the joint key for the UE 14, then the common CN control instance 20 sets the joint key KASME-joint equal to, for instance, a function of the existing joint key and a key KASME_N corresponding to an additional network slice Slice N. The joint key KASME-joint is used for creating a NAS level integrity key Kms-into for EMM integrity and a NAS level encryption key KNAs-enco for EMM encryption. For a first network slice Slice l, a first CN instance 23a receives a NAS key KASMEI, based on which NAS integrity key KNAs-enci is created for ESM encryption and NAS integrity key Kms-inti is created for ESM integrity. Correspondingly, s second CN instance 23b receives a key KASME2 for a second network slice Slice 2. Based on the NAS key KASME2 NAS integrity key KNAs-enc2 is created for ESM encryption and NAS integrity key KNAs-int2 is created for ESM integrity.

It is noted that, for all embodiments described in the following, some steps may be described as two separate (sub)steps, but could equally well be described and seen as one step. For instance, a node may be described to derive e.g. a first key KeNB in a sub(step) and a second key KNAs_enc/KNAs_inc in another sub(step), although both (sub)steps may actually be performed in a single process. Thus, for all embodiments described in the following a node may perform certain steps one by one or in a single process, irrespective of being described as separate steps or merged in one step.

Figure 4, described above, illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 5.

Figure 5 illustrates steps performed in the communication system 10 when the UE 14 attaches to the network and to a first network slice Slice 1 (e.g. a mobile broadband service).

0. The UE attaches to the communication system.

1. A common CN control instance 20 obtains (Arrow Ai) an authentication vector containing at least the key KASMEO from the HSS/AuC 17 serving the CN control instance 20. The CN control instance 20 then uses data from the authentication vector to run (Arrow Ala) a NAS authentication procedure with the UE 14. This procedure results in that the UE 14 and CN control instance 20 are mutually authenticated based on a key K (associated with e.g. International Mobile Subscriber Identity, IMSI) shared between the UE 14 and the HSS/AuC 17 serving the CN control instance 20. In addition, the UE 14 derives (Arrow Alb) the same KASMEO as the CN control instance 20 as part of the authentication procedure. This example is in accordance with a regular LTE authentication. However, it is noted that other authentication methods resulting in a shared key KASMEO are possible, e.g. supported by an Access Authentication and Authorization (AAA) server instead of the HSS/AuC 17. The CN control instance 20 as well as the UE 14 may further notice that there is no KASME-joint established, e.g. by there being no value set yet into that key. The CN Control instance 20 as well as the UE 14 further notices that there is no KASME-joint established due the UE 14 not being connected to any slice (in addition to being attached), and hence the CN control instance 20 and the UE 14 independently sets KASME-joint equal to KASMEO-

2. The CN control instance 20 and UE 14 independently derive (Arrows A2a, A2b) the keys KNAs-into and KNAs-enco from KASME-joint for integrity protection and encryption of NAS traffic between the UE 14 and the CN control instance 20. The CN control instance 20 activates NAS security for the NAS traffic between the UE 14 and the CN control instance 20.

3. When a UE goes from IDLE to ACTIVE mode (Arrow A3) in a first network slice Slice 1, the CN control instance 20 derives (Arrow A3a) a key KeNB from the key KASME- joint and then the CN control instance 20 sends (Arrow A3b) it to the RAN node 11 in connection to the RRC setup (i.e. when the CN control instance 20 creates the UE context in the RAN node 11).

4. Keys KRRc-int and KRRc-enc are derived (Arrow A4) in the RAN node 11 from the key KeNB for integrity protection and encryption of RRC control plane signaling on

(PDCP) level.

5. Keys Kup-enc (and optionally Kup-int) may be derived (Arrow A5) in the RAN node 11 from the key KeNB for encryption (and optionally integrity protection) of future PDCP user plane traffic.

6. The UE 14 independently derives (Arrow A6a) the same key KeNB from the KASME- joint as the CN control instance 20 did in step 3 and then derives (Arrow A6b) the same keys KRRc-enc and KRRc-int, as the RAN node 11 did in step 4. The UE 14 may also derive (A6c) the keys for user plane encryption and integrity protection Kup-enc and Kup-int in the same way as the RAN node 11 may do in step 5.

7. The UE attaches to a first network slice (Slice 1)

8. The CN instance 23a serving the first network slice, Slice 1, obtains (Arrow A8) an authentication vector containing at least a key KASMEI from the HSS/AuC 17 serving slice l. It is noted that the slices may be served by different HSS/AuCs, although the same HSS/AuC 17 serves both slices in the illustrated case. The CN instance 23a serving the first network slice, Slice 1, then uses data from the authentication vector to run (Arrow A8b) a NAS-level authentication/authorization procedure with the UE 14, either independently or assisted by the CN control instance 20, which results in that the UE 14 is authenticated/authorized in the first network slice, Slice 1, based on the key K shared between the UE 14 and the HSS/AuC 17 serving the first network slice, Slice 1. In addition, the UE 14 also derives (ArrowA8c) the KASMEI during this procedure. The procedure may also result in mutual authentication i.e. that the UE 14 also authenticates the CN instance 23a. The procedure may be performed using NAS EMM signaling (if assisted by the CN control instance 20) or it may be also performed using NAS ESM signaling if the CN instance 23a performs the procedure independently from the CN control instance 20. In both cases the CN instance 23a needs to provide (Arrow A8a) the key KASMEI to the CN control instance 20.

9. The CN control instance 20 notices that there already is a KASME-jointkey active with this UE 14, and the CN Control instance 20 therefore derives (Arrow 9) a new key KASME-joinf = KDF(KASME-joint, KASMEI) wherein KDF stands for Key Derivation

Function. As a particular example of a KDF that may be used, Hash-based Message Authentication Code- Secure Hash Algorithm 256 (HMAC-SHA256) as used in LTE can be mentioned. However, it is noted that other pseudo random functions, such as e.g. keyed message authentication codes, stream ciphers may also be used. According to another aspect of the invention, the CN control instance 20 derives KASME-joint as KDF({KASME-I}) over the set of all established KASMES. This latter aspect however requires more storage since all keys KASME-ithen need to be stored.

10. The CN Control instance 20 runs (Arrow A10) a NAS security mode command procedure with the UE 14 indicating that this is a "KASME joining" type of key change. The indication can be a special flag, a special Key Set Identifier (KSI), or implicit in the sense that the UE 14 knows that when a network slice is activated this action is always performed by the CN Control instance 20, so any NAS Security Mode

Command received at this particular point in time is a "KASME joining" operation. Key KNAs-into and key KNAs-enco for integrity protection and encryption of shared NAS (i.e. NAS EMM) are independently derived in the CN Control instance 20 and in the UE 14 attaching to the first network slice, Slice 1, from the key Kasme-joint. In other embodiments, the UE 14 determines that a key joining operation has taken place by other implicit means, e.g., that a radio bearer has been established as a result of the UE 14 going from IDLE mode to ACTIVE mode in that network slice. In the latter case a NAS security mode command is not necessary. After the UE 14 and the CN Control instance 20 has agreed to use the new KASME-joint', the CN Control instance 20 sets KASME-joint = KASME-joinf (Arrow lie). In addition, the UE and the CN instance serving slice 1 independently derive (Arrows Audi, Anei) Kms-inti and Kms-end from key KASMEI and the derived keys are to be used to protect slice specific NAS signaling (i.e. NAS ESM).

11. The UE 14 derives the same keys that the CN Control instance 20 did in steps 8- 10: KASMEI (Arrow A8c) and KASME-joinf (Arrow Ana). After the UE 14 and the CN Control instance 20 have agreed to use the new KASME-joint', the CN Control Instance 20 and the UE 14 set (Arrow Anc, Arrow Anb) KASME-joint = KASME-joinf. The UE 14 and the CN control instance 20 also derives (Arrow And2, Arrow Ane2) the keys KNAs-into and KNAs-enco for integrity protection and encryption of shared NAS EMM signaling from KASME-joint and the UE 14 and the CN instance 23a serving slice 1 also derive (Arrow Audi, Anei) the keys KNAs-inti and KNAs-enci for the slice specific NAS ESM signaling from KASMEI (as also described in step 10).

12. A new key KeNB is derived (Arrow Ai2a) from the new KASME-joint (i.e. = KASME-joint') and sent (Arrow Ai2b) to the RAN node 11 from the CN Control instance 20 in connection to the UE 14 going to ACTIVE mode in the first network slice, Slice 1 (i.e. when the CN Control instance 20 creates the UE context in the RAN node 11 for the first network slice, Slice 1). The CN instance 23a serving the first network slice, Slice 1, activates NAS security for the UE 14 on the first network slice, Slice 1.

13. The UE 14 derives (Arrow A13) a new KeNB from the new KASME-joint.

14. New keys KRRc-int and KRRc-enc are derived (Arrow A14) in the RAN node 11 from the key KeNB for integrity protection and encryption of RRC control plane signaling on PDCP level.

15. New keys Kup-enc (and optionally Kup-int) are derived (Arrow A15) in the RAN node 11 from (the new) KeNB for encryption (and optionally integrity protection) of PDCP user plane traffic. 16. The RAN node 11 runs (Arrow A16) a "Key Change on the Fly" procedure with the UE 14 indicating that the KeNB is changed and activating the security based on the keys derived from the KeNB.

17. The UE 14 uses the same key KeNB to derive (Arrow A17) the keys KRRc-enc, KRRc-int, Kup-enc (and optionally Kup-int) as the RAN node 11 did in steps 14 and 15.

18. If the UE 14 attaches to any additional network slice (slice N), steps 7 to 17 will be applied again, except that it involves the core network of slice N instead of the first network slice, Slice 1. As the key generation is now depending on non-deterministic (non-predictable) user behavior/system setting, this will make the authentication and encryption much more secure by making it more difficult for an attacker to predict and keep track of the keys.

Above, steps 0-6 relate to EMM signaling, while steps 7-18 relate to ESM signaling to one particular network slice.

Embodiments described with reference to figures 6 and 7 are based on the following main principles:

• Access authentication is performed between the UE 14 and the common CN control instance 20 when the UE 14 attaches to the network (this authentication may also be repeated later on).

• Network slice specific authentication/authorization is performed between the UE 14 and the network slice specific CN instance 23a, 23b when the UE 14 attaches to that network slice (this authentication/authorization may also be repeated later on). The resulting keys are used to protect NAS-level ESM signaling between the UE 14 and the slice specific CN instance 23a, 23b.

• The keys used for access authentication and network slice specific authentication/ authorization are joined in the CN, and used to create keys to protect NAS-level EMM signaling between the UE and the Common CN control instance. The joined key is used to create a common AS-level key that is used in the RAN to create keys to protect control plane signaling. In addition, the key used for network slice specific authentication/ authorization is used to create a separate AS-level key that is used in the RAN to protect user plane transmission. This means that the same key is used in RAN/AS-level to protect control plane but user plane is however protected with slice specific keys.

Figure 6 illustrates a second exemplary key hierarchy. In embodiments according to this key hierarchy, there are separate ESM keys and EMM keys, the key joining is performed in the CN and there are also separate UP key(s). Figure 6 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 7.

Figure 7 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice. o. The UE attaches to the network:

The steps 1-4 described in relation to figure 5, are almost identical also for this embodiment, expect that KeNB in figure 5 is KeNBohere (i.e. in figure 7) and are not repeated here.

5. In contrast to the embodiment described in relation to figure 5, no user plane related keys are derived at this point in the RAN node 11 for encryption or optionally integrity protection of PDCP user plane traffic. Thus, this "step" is mentioned as a step in order to highlight the differences to the previous embodiment.

6. The UE 14 independently derives (Arrow B6a) the same key KeNBo from the KASME- joint as the CN control instance 20 did in step 3 and then the UE 14 derives (Arrow B6b) the same keys KRRc-enc, KRRc-int, as the RAN node 11 did in step 4. It is noted that no user plane related keys are derived in the UE 14 at this point (in line with "step" 5 for the RAN node 11).

The steps 7-11 described in relation to figure 5, are identical also for this embodiment and are not repeated here.

12. A new KeNBo is derived (Arrow Bi2a) in the from the new Kasme-joint and sent (Arrow Bi2b) to the RAN node 11 from the CN control instance 20 in connection to the UE 14 going to ACTIVE mode in a first network slice, Slice 1 (i.e. when the CN Control instance 20 creates the UE context in the RAN node 11 for the first network slice, Slice 1). A key KeNBi is derived (Arrow Bi2c) from a key Kasmei in the CN instance 23a serving the first network slice, Slice l and also sent (Arrow Bi2d) to the RAN node 11. The CN instance 23a serving the first network slice, Slice 1 activates NAS security for the UE 14 on the first network slice, Slice 1.

It is noted that this (step 12) is the same as the corresponding step in the previous embodiments, with the addition that the key KeNBi is derived.

13. The UE derives (Arrow Bi3a) a new KeNBo from the new KASME-joint and the key KeNBi is derived (Arrow Bi3b) from the key KASMEI. It is noted that this (step 13) is the same as the corresponding step in the previous embodiment, with the addition that the key KeNBi is derived.

14. Same as step 14 of the previous embodiment, i.e. new keys KRRc-int and KRRc-enc are derived (Arrow B14) in the RAN node 11 from the key KeNBo for integrity protection and encryption of RRC control plane signaling on PDCP level.

15. The keys Kup-enci (and optionally Kup-inti) are derived (Arrow B15) in the RAN node 11 from the key KeNBi for encryption (and optionally integrity protection) of PDCP user plane traffic. It is noted that this is the same as the corresponding step in the previous embodiment, except that the user plane keys are derived from the slice- specific key KeNBi.

16. The RAN node 11 runs (Arrow B16) a "Key Change on the Fly" procedure with the UE 14 indicating that the key KeNBo is changed and activating the security based on the keys derived from the KeNBo and KeNBi. It is noted that this is the same as the corresponding step in the previous embodiment, with the addition that the security based on the keys derived from the key KeNBi is also activated.

17. The UE 14 derives (Arrow Bi7a) the keys KRRc-enc, KRRc-int, and also (Arrow Bi7b) Kup-enci (and optionally Kup-inti). A reason for performing the key derivation in separate steps (Arrows Bi7a, Bi7b) is that if another slice is added, then Kupi-enc,(int) will not be regenerated and only KRRC -enc, int and KUP2 -enc,(int)c are derived.

The step 18 described in relation to figure 5, is identical also for this embodiment and is not repeated here. Embodiments described with reference to figures 8 and 9 are based on the following main principles:

• Access authentication is performed between the UE and the Common CN Control instance when the UE attaches to the network (this authentication may also be repeated later on). The resulting keys are used to protect both NAS-level EMM and ESM signaling between the UE and the Common CN Control instance.

• Network slice specific authentication/authorization is performed between the UE and the network slice specific CN instance when the UE attaches to that network slice (this authentication/authorization may also be repeated later on). The resulting keys are not used to protect NAS-level ESM signaling between the UE and the slice specific CN instance.

• The keys used for access authentication and network slice specific authentication/ authorization are joined in the CN, and used to create keys to protect NAS-level EMM and ESM signaling between the UE and the Common CN Control instance. The joined key is used to create a common AS-level key that is used in the RAN to create keys to protect control plane signaling. In addition, the key used for network slice specific authentication/ authorization is used to create a separate AS-level key that is used in the RAN to protect user plane transmission. This means that the same key is used in RAN/AS-level to protect control plane but user plane is however protected with slice specific keys.

Figure 8 illustrates a third exemplary key hierarchy. In embodiments according to this key hierarchy, there are no specific ESM keys or EMM keys, the key joining is performed in a node of the CN and there are separate UP key(s). Figure 8 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 9.

Figure 9 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

The steps 1-4 described in relation to figure 5, are almost identical also for this embodiment, expect that KeNB in figure 5 is KeNBohere (i.e. in figure 9), and are not repeated here. 5. In contrast to the embodiment described in relation to figure 5, no user plane related keys are derived at this point in the RAN node 11 for encryption or optionally integrity protection of PDCP user plane traffic. Thus, this "step" is mentioned as a step in order to highlight the differences to the previous embodiment.

6. The UE 14 independently derives (Arrow C6a) the same key KeNBo from the KASME- joint as the CN control instance 20 did in step 3 and then the UE 14 derives (Arrow C6b) the same keys KRRc-enc, KRRc-int, as the RAN node 11 did in step 4. It is noted that no user plane related keys are derived in the UE 14 at this point (in line with "step" 5 for the RAN node 11).

The steps 7-9 described in relation to figure 5 are identical also for this embodiment and are not repeated here.

10. The CN Control instance 20 runs (Arrow C10) a NAS security mode command procedure with the UE 14 indicating that this is a "Kasme joining" type of key change. The indication can be a special flag, a special Key Set Identifier (KSI), or implicit in the sense that the UE 14 knows that when a slice is activated this action is always performed by the CN Control instance, so any NAS Security Mode Command received at this particular point in time is a "KASME joining" operation. Key KNAs-into and KNAs-enco for integrity protection and encryption of both shared NAS (i.e. NAS EMM) and slice specific NAS (i.e. NAS ESM) are derived in the CN Control instance and in the UE attaching to slice 1 from the key KASME-joint. According to another aspect the invention the UE determines that a key joining operation has taken place by other implicit means, e.g., that a radio bearer has been established as a result of the UE going to ACTIVE mode in that slice. In the latter case a NAS security mode command is not necessary. After the UE 14 and the CN Control instance has agreed to use the new KASME-joinf, the CN Control instance 20 sets (Arrow Cue) KASME-joint = KASME-joinf. It is noted that step 10 is the same as the corresponding step 10 of the embodiments described with reference to figure 5, except that the keys KNAs-inti and KNAs-enci are not derived.

11. The UE 14 derives (Arrow Cua) the same keys KASMEI and KASME-joinf the CN Control instance 20 did in steps 8 - 10. After the UE 14 and the CN Control instance 20 has agreed to use the new KASME-joint', the CN control instance 20 and the UE 14 set (Arrows Cub, Cue) KASME-joint = KASME-joinf. The UE 14 and the CN control instance 20 also derives (Arrow Cud, Cue) the keys Kms-into and KNAs-enco for integrity protection and encryption of both shared NAS EMM signaling and slice specific NAS ESM signaling from the key KASME-joint (as also described in step 10). It is noted that step 11 is the same as the corresponding step 11 of the embodiments described with reference to figure 5, except that the keys Kms-inti and KNAs-enci are not derived.

12. A new KeNBo is derived (Arrow Ci2a) from the new Kasme-joint and sent (Arrow Ci2b) to the RAN node 11 in connection to the UE 14 going to ACTIVE mode in slice 1 (i.e. when the CN Control instance 20 creates the UE context in the RAN node 11 for the first network slice, Slice 1). The key KeNBi is derived (Arrow Ci2c) from the key KASMEI in the CN instance 23a serving the first network slice, Slice 1, and the key KeNBi is also sent (Arrow Ci2d) to the RAN node 11. The CN Control instance 23a serving the first network slice activates NAS security for the UE 14 on the first network slice. It is noted that this step is the same as the corresponding step in the embodiments described with reference to figure 5, with the addition that the key KeNBi is derived.

13. The UE 14 derives (Arrow Ci3a) a new KeNBo from the new key KASME-joint and the key KeNBi is derived (Arrow Ci3b) from the key KASMEI. It is noted that this step is the same as the corresponding step in the embodiments described with reference to figure 5, with the addition that the key KeNBi is derived.

14. New keys KRRc-int and KRRc-enc are derived (Arrow C14) in the RAN node 11 from the key KeNB for integrity protection and encryption of RRC control plane signaling on PDCP level.

15. The keys Kup-enci (and optionally Kup-inti) are derived (Arrow 15) in the RAN node 11 from KeNBi for encryption (and optionally integrity protection) of PDCP user plane traffic. It is noted that this step is the same as the corresponding step in the embodiments described with reference to figure 5, except that the user plane keys are derived from the slice-specific key KeNBi.

16. The RAN node runs (Arrow C16) a "Key Change on the Fly" procedure with the UE indicating that the KeNB is changed and activating the security based on the keys derived from the KeNBo and KeNBi. It is noted that this step is the same as the corresponding step in the embodiments described with reference to figure 5, with the addition that the security based on the keys derived from the key KeNBi is also activated.

17. The UE 14 uses the same key KeNBo to derive (Arrow Ci7a) the keys KRRc-enc and KRRc-int as the RAN node 11 did in step 14. Further, the UE 14 uses the same key KeNBi to derive (Arrow Ci7b) the Kup-enci (and optionally Kup-inti) as the RAN node 11 did in step 15.

18. If the UE 14 attaches to any additional slice (slice N), steps 7 to 17 will be applied again, except that it involves the core network of slice N instead of slice 1. As the key generation is now depending on un-deterministic user behavior, this will make the authentication and encryption much more secure.

In the embodiments described above (figures 4 through 9), the key joining was made in the core network. In the following, embodiments are described wherein the key joining is made in the RAN, e.g. a node thereof. In these embodiments, the joining of keys used to derive keys for the control plane part of the RRC security is done in the RAN. The keys for the user plane part of the access security is either derived from keys coming out of the key joining process or from the slice authorization process (resulting in slice-specific user plane keys).

Embodiments described with reference to figures 10 and 11 are based on the following main principles:

• Access authentication is performed between the UE 14 and the Common CN Control instance when the UE attaches to the network (this authentication may also be repeated later on).

• Network slice specific authentication/authorization is performed between the UE and the network slice specific CN instance when the UE attaches to that network slice (this authentication/authorization may also be repeated later on). The resulting keys are used to protect NAS-level ESM signaling between the UE and the slice specific CN instance.

• Dedicated AS-level key will be derived for each key used for access authentication and network slice specific authentication/ authorization. These dedicated AS-level keys will be transmitted and joined in RAN to create a common AS-level key to create keys to protect both control and user plane. This means that same keys are used in RAN/AS-level for all common and slice-specific control and user plane.

Figure 10 illustrates a fourth exemplary key hierarchy. In embodiments according to this key hierarchy, there are separate ESM keys and EMM keys, the key joining is performed in a node of the RAN and there are common UP key(s). Figure 10 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 11.

Figure 11 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

0. The UE attaches to the network

1. The common CN control instance 20 obtains (Arrow Di) an authentication vector containing at least the key KASMEO from the HSS/AuC 17 serving the CN control instance 20. The CN control instance 20 then uses data from the authentication vector to run a NAS authentication procedure (Arrow Dia) with the UE which results in that the UE 14 and CN control instance 20 are mutually authenticated based on the key K shared between the UE 14 and the HSS/AuC 17 serving the CN control instance 20. In addition, the UE 14 derives (arrow Dib) the same KASMEO as the CN control instance 20 as part of the authentication procedure. This is in the same way as a regular LTE authentication, but other authentication methods resulting in a shared key KASMEO are possible, for instance supported by an AAA server instead of the HSS/AuC 17.

2. The CN control instance 20 and UE 14 independently derive (Arrow D2a, D2b) the keys KNAs-into and KNAs-enco from KASMEO for integrity protection and encryption of NAS traffic between the UE 14 and the CN control instance 20. The CN control instance 20 activates (Arrow D2c) NAS security for the NAS traffic between the UE 14 and the CN control instance 20.

3. When a UE 14 goes from IDLE to ACTIVE mode (Arrow D3), the UE 14 and the CN control instance 20 derives the key KeNBo (Arrows D3a, D3b) from the key KASMEO and then the CN control instance 20 sends (Arrow D3C) it to the RAN node 11 in connection to the RRC setup (i.e. when the CN control instance creates the UE context in the RAN). The RAN control instance as well as the UE 14 further notices that there is no KeNB-joint established due to the UE 14 not being connected to any slice (in addition to being attached), and hence the RAN node 11 and the UE 14

independently sets (Arrows D3d, D3e) KeNB-joint equal to KeNBo.

4. Keys KRRc-int and KRRc-enc are derived (Arrow D4) in the RAN node 11 from the key KeNB-joint for integrity protection and encryption of RRC control plane signaling on PDCP level.

5. Keys Kup-enc (and optionally Kup-int) may be derived (Arrow D5) in the RAN node 11 from the key KeNB-joint for encryption (and optionally integrity protection) of future PDCP user plane traffic.

6. The UE 14 independently derives (see Arrows D3b, D3e) the same key KeNB-joint from the KASMEO as the CN control instance 20 did in step 3 and then derives (Arrow D6a) the same keys KRRc-enc and KRRc-int as the RAN node 11 did in step 4. The UE 14 may also derive (Arrow D6b) the keys for user plane encryption and integrity protection Kup-enc and Kup-int in the same way as the RAN node 11 may do in step 5 (see Arrow D5).

7. The UE attaches to network slice 1

8. The CN instance 23a serving the first slice (Slice 1) obtains (Arrow D8a) an authentication vector containing at least the key KASMEI from the HSS/AuC 17 serving first slice (Slice 1). The CN instance 23a serving the first slice (Slice 1) then uses data from the authentication vector to run (Arrow D8b) a NAS-level

authentication/authorization procedure with the UE 14, either independently or assisted by the CN control instance 20, which results in that the UE 14 being authenticated/authorized in the first slice (Slice 1), based on the key K shared between the UE 14 and the HSS/AuC 17 serving first slice (Slice 1). In addition, the UE 14 also derives (Arrow D8c) the KASMEI as part of this

authentication/authorization procedure. The procedure may also result in mutual authentication i.e. that the UE also authenticates the CN instance 23a. The procedure may be performed using NAS EMM signaling (if assisted by the CN control instance 20) or it may be also performed using NAS ESM signaling if the CN instance 23a performs the procedure independently from the CN control instance 20. 9. The CN instance 23a serving the first slice (Slice 1) and UE 14 independently derive (Arrows D9a, D9D) the keys Kms-inti and KNAs-enci from KASMEI for integrity protection and encryption of NAS traffic between the UE 14 and the CN instance 23a serving the first slice (Slice 1). The CN instance 23a serving the first slice (Slice 1) activates (Arrow D9C) NAS security for the NAS traffic between the UE 14 and the CN instance 23a serving the first slice (Slice 1) to protect slice specific NAS signaling (i.e. NAS ESM).

10. As a data transmission between the CN instance 23a serving the first slice (Slice 1) and the UE 14 is started, the UE 14 and the CN instance 23a derives (Arrows Diob, Dioa) the key KeNBi from the key KASMEI and then the CN instance 23a sends (Arrow Dioc) it to the RAN node 11 in connection to the RRC setup (i.e. when the CN instance 23a creates the UE context in the RAN) or Bearer setup (i.e. when the CN instance 23a setup the first bearer on an existing UE context in the RAN). The RAN node 11 notices that there already is a KeNB-jointkey active with this UE 14, and the RAN node 11 therefore derives (Arrow Diod) a new key KeNB-joinf = KDF(KeNB-joint, KeNBi). According to another aspect of the invention, the RAN node 11 derives KeNB-joint as KDF({KeNB-i}) over the set of all established KeNBs. This latter aspect however requires more storage, as has been noted earlier.

11. The RAN node 11 derives (Arrow Dua) new keys KRRc-int and KRRc-enc from the key KeNB-joinf for integrity protection and encryption of RRC control plane signaling on PDCP level, and (Arrow Dub) keys Kup-enc (and optionally Kup-int) from KeNB-joinf for encryption (and optionally integrity protection) of PDCP user plane traffic.

12. In case there is an existing security context in the RAN in step 10, the RAN node 11 runs (Arrow Di2a) a "Key Change on the Fly" procedure with the UE 14 indicating with a flag that this is a "KeNB joining" type of key change, and sets (Arrow Di2b) KeNB- joint equal tO KeNB-joinf.

13. The UE derives (Arrow Di3a) the same keys KeNBi and KeNB-joinf as the CN instance 23a and RAN node 11 did in steps 8 -11 (if not already derived; here the UE derived KeNBi at Arrow Diob, but could alternatively do it at Arrow Di3a instead). It is noted that the key KeNBi may be derived at any time after the UE 14 has derived KASMEI.

After the UE 14 and the RAN node have agreed to use the new KeNB-joinf, the RAN node 11 and the UE 14 set (Arrow Di3b) KeNB-joint = KeNB-joinf. The UE 14 also derives (Arrow Di3c)new keys KRRc-int and KRRc-enc for integrity protection and encryption of RRC control plane signaling on PDCP level from KeNB-joinf and new keys Kup-enc for encryption (and optionally Kup-int for integrity protection) of PDCP user plane traffic from KeNB-joinf (as also described in step 11 for the RAN node 11).

14. If the UE 14 attaches to any additional slice (slice N), steps 7 to 13 will be applied again, except that it involves the core network of slice N instead of slice 1. As the key generation is now depending on un-deterministic user behavior, this will make the authentication and encryption much more secure, as has been described for previous embodiments.

Embodiments described with reference to figures 12 and 13 are based on the following main principles:

• Access authentication is performed between the UE 14 and the common CN Control instance 20 when the UE 14 attaches to the network (this authentication may also be repeated later on).

• Network slice specific authentication/authorization is performed between the UE 14 and the network slice specific CN instance 23a when the UE 14 attaches to that network slice (Slice 1) (this authentication/authorization may also be repeated later on). The resulting keys are used to protect NAS-level ESM signaling between the UE 14 and the slice specific CN instance 23a.

• Dedicated AS-level key will be derived for each key used for access authentication and network slice specific authentication/ authorization. These dedicated AS-level keys will be transmitted and joined in RAN. The joined key is used to create a common AS-level key that is used in the RAN to create keys to protect control plane signaling. In addition, the dedicated AS-level key derived from network slice specific authentication/ authorization is used in the RAN to protect user plane transmission. This means that the same key is used in RAN/AS-level to protect control plane but user plane is however protected with slice specific keys.

Figure 12 illustrates a fifth exemplary key hierarchy. In embodiments according to this key hierarchy, there are separate ESM keys and EMM keys, the key joining is performed in a node of the RAN and there are separate UP key(s). Figure 12 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 13.

Figure 13 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

It is noted that in the below embodiments (described with reference to figures 12 and 13), the differences compared to the previous embodiments (described with reference to figures 10 and 11), are highlighted, i.e. if there is no difference described, the step is the same as in these embodiments. o. The UE attaches to the network

The steps 1-4 described in relation to figure 11 (Arrows Di, Dia, Dib, D2a, D2b, D2c, D3, D3a, D3b, D3C, D3d, D3e,D4), are identical for this embodiment and are not repeated here.

5. No user plane related keys are derived at this point in the RAN for encryption (and optionally integrity protection) of PDCP user plane traffic. This is in contrast to step 5 of the previous embodiment (figure 11), wherein at least the Kup-enc may have been derived for future use.

6. The UE 14 derives (Arrow E6) the same keys KRRc-enc, KRRc-int, as RAN did in step 4. No user plane related keys are derived in the UE 14 in line with the RAN node 11 in step 5.

It is thus noted that steps 5-6 are the same as the corresponding steps for the previous embodiments (described with reference to figures 10 and 11), except that no Kup-enc and Kup-int are derived.

Steps 7-10 described in relation to figure 11 (Arrows D8a, D8b, D8c, Dga, Dgb, D9C, Dioa, Diob, Dioc, Diod), are identical for this embodiment and are not repeated here.

11. The RAN node 11 derives (Arrow Ella) new keys KRRc-int and KRRc-encfrom the key KeNB-joinf for integrity protection and (Arrow Enb) encryption of RRC control plane signaling on PDCP level, and keys Kup-enci (and optionally Kup-inti) from KeNBi for encryption (and optionally integrity protection) of PDCP user plane traffic for the first network slice (Slice l).

It is noted that this is the same step as the corresponding step in the previous embodiments (described with reference to figures 10 and 11), except that the keys Kup-inti and Kup-enci are derived from KeNBi instead of KeNB-joinf.

Step 12 is the same as for the previous embodiments (described with reference to figures 10 and n).

13. The UE 14 derives (Arrow Ei3a) the same keys KeNBi and KeNB-joinf as the CN instance 23a and RAN node 11 did in steps 8 -11. After the UE 14 and the RAN node 11 have agreed to use the new KeNB-joinf, the RAN node 11 and the UE 14 set (Arrows Di2b, E13C) KeNB-joint = KeNB-joinf. The UE 14 also derives (Arrow Ei3d) new keys KRRC- int and KRRc-enc for integrity protection and encryption of RRC control plane signaling on PDCP level from KeNB-joinf and new keys Kup- _en ci for encryption (and optionally KUP- inti for integrity protection) of PDCP user plane traffic from KeNBi (as also described in step 11).

It is thus noted that step 13 are the same as the corresponding steps for the previous embodiments (described with reference to figures 10 and 11), except that the keys Kup-inti and Kup-enci are here derived from KeNBi instead of KeNB-joinf.

14. If the UE attaches to any additional slice (slice N), steps 7 to 13 will be applied again, except that it involves the core network of slice N instead of the first network slice (Slice 1). As the key generation is now depending on un-deterministic user behavior, this will make the authentication and encryption much more secure, as has been noted earlier.

Embodiments described with reference to figures 14 and 15 are based on the following main principles:

• Access authentication is performed between the UE 14 and the common CN Control instance 20 when the UE 14 attaches to the network (this authentication may also be repeated later on). The resulting keys are used to protect both NAS-level EMM and ESM signaling between the UE 14 and the common CN Control instance 20. • Network slice specific authentication/authorization is performed between the UE 14 and the network slice specific CN instance 23a when the UE 14 attaches to that network slice (this authentication/authorization may also be repeated later on). The resulting keys are not used to protect NAS-level ESM signaling between the UE and the slice specific CN instance. The protection is done by using the keys derived from the Access authentication.

• Dedicated AS-level key will be derived for each key used for access authentication and network slice specific authentication/authorization. These dedicated AS-level keys will be transmitted and joined in RAN to create a common AS-level key to create keys to protect both control and user plane. This means that same keys are used in RAN/AS-level for all common and slice-specific control and user plane.

Figure 14 illustrates a sixth exemplary key hierarchy. In embodiments according to this key hierarchy, there are no separate ESM keys or EMM keys (i.e. a common key is used for all NAS signaling), the key joining is performed in a node of the RAN and there are common UP key(s). Figure 14 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 15.

It is noted that in the below embodiments (described with reference to figures 14 and 15), the differences compared to the previous embodiments (described with reference to figures 10 and 11) are highlighted, i.e. if there is no difference described, the step is the same as in these previous embodiments.

Figure 15 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice. o. The UE 14 attaches to the network

The steps 1-6 described in relation to embodiments of figure 11 (Arrows Di, Dia, Dib, D2a, D2b, D3, D3a, D3b, D3C, D3d, D3e, D4, D5, D6a, D6b), are identical for this embodiment and are not repeated here.

7. The UE attaches to network slice 1.

The step 8 described in relation to figure 11 (Arrows D8a, D8b, D8c), are identical for this embodiment and are not repeated here. 9. There is no NAS security activated and no slice specific keys are derived for slice specific NAS signaling between the CN instance 23a serving the first network slice (Slice 1) and the UE 14. Keys Kms-into and KNAs-enco (derived in step 2) will be used for integrity protection and encryption for both shared NAS (i.e. NAS EMM) and slice specific NAS (i.e. NAS ESM). It is thus noted that this step is the same as the corresponding step described in relation to embodiments of figure 11, except that the keys KNAs-inti and Kms-end are not derived.

The steps 10-14 described in relation to embodiments of figure 11 (Arrows Dioa, Diob, Dioc, Diod. Dua, Dub, Di2a, Di2b, Di3a, Di3b, D13C), are identical for this embodiment and are not repeated here.

Embodiments described with reference to figures 16 and 17 are based on the following main principles:

• Access authentication is performed between the UE 14 and the common CN Control instance 20 when the UE 14 attaches to the network (this authentication may also be repeated later on). The resulting keys are used to protect both NAS-level EMM and ESM signaling between the UE 14 and the common CN Control instance 20.

• Network slice specific authentication/authorization is performed between the UE 14 and the network slice specific CN instance 23a when the UE 14 attaches to that network slice (this authentication/authorization may also be repeated later on). The resulting keys are not used to protect NAS-level ESM signaling between the UE 14 and the slice specific CN instance 23a. The protection is done by using the keys derived from the Access authentication.

• Dedicated AS-level key will be derived for each key used for access authentication and network slice specific authentication/ authorization. These dedicated AS-level keys will be transmitted and joined in RAN, in particular a node 11 thereof. The joined key is used to create a common AS-level key that is used in the RAN node 11 to create keys to protect control plane signaling. In addition, the dedicated AS-level key derived from network slice specific authentication/ authorization is used in the RAN to protect user plane transmission. This means that the same key is used in RAN/AS- level to protect control plane but user plane is however protected with slice specific keys. Figure 16 illustrates a seventh exemplary key hierarchy. In embodiments according to this key hierarchy, there are no separate ESM keys or EMM keys, the key joining is performed in a node of the RAN and there are separate UP key(s). Figure 16 illustrates the key architecture for the steps described below with reference to a signaling scheme of figure 17.

It is noted that in the below embodiments (described with reference to figures 16 and 17), the differences compared to the previous embodiments (described with reference to figures 10 and 11) are highlighted, i.e. if there is no difference described, the step is the same as in these previous embodiments.

Figure 17 illustrates steps of performed in a communication system when a UE attaches to the network and to a first network slice.

The steps 1-4 described in relation to figure 11 (Arrows Di, Dia, Dib, D2a, D2b, D2c, D3, D3a, D3b, D3C, D3d, D3e, D4), are identical for this embodiment and are not repeated here.

5. No user plane related keys are derived at this point in the RAN for encryption (and optionally integrity protection) of PDCP user plane traffic.

6. The UE 14 derives (Arrow G6) the same keys KRRc-enc, KRRc-int, as the RAN node 11 did in step 4. No user plane related keys (Kup-enc, Kup-int) are derived in the UE 14 in line with the RAN node 11 in step 5.

7. The UE 14 attaches to network slice 1

Step 8 described in relation to figure 11 (Arrows D8a, D8b, D8c), are identical for this embodiment and is not repeated here.

9. There are no "ESM" specific key and no slice specific keys are derived for Slice specific NAS signaling between the CN instance 23a serving the first network slice (Slice 1) and the UE 14. Keys Kms-into and KNAs-enco will be used for integrity protection and encryption for both shared NAS (i.e. NAS EMM) and slice specific NAS (i.e. NAS ESM).

Step 10 described in relation to figure 11 (Arrows Dioa, Diob, Dioc, Diod) is identical for this embodiment and is not repeated here. 11. The RAN node n derives (Arrow Gna) new keys KRRc-int and KRRc-enc from the key KeNB-joinf for integrity protection and encryption of RRC control plane signaling on PDCP level, and keys Kup-enci (and optionally Kup-inti) (Arrow Glib ) from KeNBi for encryption (and optionally integrity protection) of PDCP user plane traffic for the first network slice (Slice l).

Step 12 described in relation to figure n (Arrows Di2a, Di2b), is identical for this embodiment and is not repeated here.

13. The UE 14 derives (Arrow Gi3a) the same keys KeNBi and KeNB-joinf as the CN instance 23a and RAN node 11 did in steps 8 -11. After the UE 14 and the RAN node 11 have agreed to use the new KeNB-joinf, the RAN node 11 and the UE 14 set (Gi3b, G13C) KeNB-joint = KeNB-joinf. The UE 14 also derives (Gi3d) new keys KRRc-intand KRRc-encfor integrity protection and encryption of RRC control plane signaling on PDCP level from KeNBi-joinf and new keys Kup-enci for encryption (and optionally Kup-inti for integrity protection) of PDCP user plane traffic from KeNBi.

It is thus noted that this is the same as the corresponding step in the embodiments described with reference to figure 11, except that the keys Kup-inti and Kup-enci are derived from KeNBi instead of KeNB-joinf.

14. If the UE 14 attaches to any additional slice (slice N), steps 7 to 13 will be applied again, except that it involves the core network of slice N instead of slice 1. As the key generation is now depending on un-deterministic user behavior, this will make the authentication and encryption much more secure.

The various features of the embodiments described may be combined in different ways, also in ways not explicitly mentioned herein. Further examples on

embodiments are given in the following with reference first to figure 18.

Figure 18 illustrates a flow chart over steps of an embodiment of a method in a network node in accordance with the present teachings.

The method 30 of protecting communication on two or more network instances Slice 1, Slice 2 is performed in a network node 11, 20. The two or more network instances Slice 1, Slice 2 are used in serving a communication device 14. The method 30 comprises obtaining 31, for each of the two or more network instances Slice 1, Slice 2, a respective specific key KASME_siice_i, KASME_siice_ ₂ , KeNB_siice_i, KeNB_siice_ ₂ for use in protecting session specific communication with the communication device 14 on the respective network instances Slice 1, Slice 2. The slice specific key for a first network instance (Slice 1) KASME_siice_i may, for instance, be the key KASME 1 or the key KeNBi, that have been described in various embodiments. The slice specific key for a second network instance (Slice 2) KASME_siice_2 may, for instance, be the key KASME 2 or the key KeNB2, that have been described in various embodiments.

The method 30 comprises determining 32 a joint key KASME-joint, KeNB-joint for use in protecting shared communication with the communication device 14 on the two or more network instances Slice 1, Slice 2.

It is noted that the respective specific keys are used for protecting only the session specific signaling.

The method 30 provides a number of advantages. By means of the method 30, security keys for different network slices can be joined in different ways. The access security for the control plane may be based on joint keys and the access security for the user plane may be based on joint keys or on slice specific keys. The method 30 enables an improved security in a sliced network by, for instance, enabling network slice separation on user plane and slice specific NAS.

In an embodiment, the determining 32 the joint key KASME-joint, KeNB-joint is made based on the respective specific keys KASME_siice_i, KASME_sii _ce _2, KeNB_siice_i, KeNB_siice_2. The joint key may also be used to create a common AS-level key that is used in the RAN (e.g. node 11 thereof) to create keys to protect both control plane and user plane. This means that the same keys are used in RAN/AS-level for all common as well as slice-specific control plane and user plane communication.

In an embodiment, the determining 32 comprises deriving a first joint key based on a first specific key KASME_siice_i, KeNB_siice_i and, upon obtaining a second specific key KASME_siice_ ₂ , KeNB_siice_2, deriving the joint key KASME-joint, KeNB-joint based on the first joint key and the second specific key KASME_siice_ ₂ , KeNB_siice_2.

In an embodiment, the determining 32 comprises deriving a first joint key based on an access authentication key KASME_O and deriving the joint key KASME-joint based on the first joint key and a first specific key KASME_siice_i. In a variation of the above embodiment, the method 30 comprises deriving a second joint key based on the joint key KASME-joint and deriving an updated joint key based on the second joint key and a second specific key KASME_siice_2.

In some embodiments, the determining 32 comprises deriving a first joint key based on a common key KeNB_o and deriving the joint key KeNB-joint based on the first joint key and a first specific key KeNB_siice_i.

In a variation of the above embodiment, the method 30 comprises deriving a second joint key based on the joint key KeNB-joint and deriving an updated joint key based on the second joint key and a second specific key KeNB_siice_2.

In some embodiments, the method 30 comprises determining, based on the joint key KASME-joint, KeNB-joint, cryptographic keys for use in protecting the shared

communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the method 30 comprises determining, based on the specific keys KASME_siice_i, KASME_siice_ ₂ , KeNB_siice_i, KeNB_siice_2, one or more separate security cryptographic keys for use in protecting the session specific communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the session specific signaling comprises one or both of session related non-access stratum control signaling and access stratum user plane signaling.

In some embodiments, the shared signaling comprises one or both of common non- access stratum control signaling and access stratum control plane signaling.

Figure 19 illustrates network entities of a communication system comprising means for implementing embodiments of methods in accordance with the present teachings.

The method 30 in its various embodiments may be implemented in a CN control instance 20 and/or in other core network nodes and/or in a RAN node 11.

The network node 11, 20 comprises a processor 40, 50 comprising any combination of one or more of a central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc. capable of executing software instructions stored in a memory 41, 51 which can thus be a computer program product. The processor 40, 50 can be configured to execute any of the various embodiments of the method 30 for instance as described in relation to figure 18.

The memory 41, 51 of the network node 11, 20 can be any combination of read and write memory (RAM) and read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc. The memory 31 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The network node 11, 20 comprises an interface 43, 53 for communication with other devices. The interface 43, 53 may, for instance, comprise a protocol stack,

transmission circuitry, receiving circuitry for communication with other devices.

The network node 11, 20 may comprise additional processing circuitry, schematically indicated at reference numerals 44, 54 for implementing the various embodiments according to the present teachings.

It is noted that some embodiments according to the present teachings may be implemented in a distributed manner, wherein different steps are performed by different nodes or entities. The network node 11, 20 in which a method according to the teachings may be implemented may, for instance, be a server, virtual machine, processor or other entity.

A network node 11, 20 is provided for protecting communication on two or more network instances Slice 1, Slice 2, the two or more network instances Slice 1, Slice 2 used in serving a communication device 14. The network node 11, 20 is configured to:

- obtain, for each of the two or more network instances Slice 1, Slice 2, a respective specific key KASME_siice_i, KASME_siice_ ₂ , KeNB_siice_i, KeNB_siice_ ₂ for use in protecting session specific communication with the communication device 14 on the respective network instances Slice 1, Slice 2, and

- determine a joint key KASME-joint, KeNB-joint for use in protecting shared

communication with the communication device 14 on the two or more network instances Slice 1, Slice 2. The network node 11, 20 may be configured to perform the above steps e.g. by comprising one or more processors 40, 50 and memory 41, 51, the memory 41, 51 containing instructions executable by the processor 40, 50, whereby the network node 11, 20 is operative to perform the steps. That is, in an embodiment, a network node is provided for protecting communication on two or more network instances, the two or more network instances being used in serving a communication device, the network node comprising one or more processors and memory, the memory containing instructions executable by the processor, whereby the network node is operative to: obtain, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the

communication device on the respective network instances, and determine a joint key for use in protecting shared communication with the communication device on the two or more network instances.

In an embodiment, the network node 11, 20 is configured to determine the joint key

KASME-joint, KeNB-joint based on the respective specific keys K _A sME_siice_i, KASME_siice_ ₂ ,

KeNB Slice 1, KeNB Slice 2-

In some embodiments, the network node 11, 20 is configured to determine by deriving a first joint key based on a first specific key KASME_siice_i, KeNB_siice_i and, upon obtaining a second specific key KASME_siice_2, KeNB_siice_2, configured to derive the joint key KASME-joint, KeNB-joint based on the first joint key and the second specific key

KASME_Slice_2, KeNB_Slice_2.

In some embodiments, the network node 11, 20 is configured to determine by deriving a first joint key based on an access authentication key KASME_O and deriving the joint key KASME-joint based on the first joint key and a first specific key KASME_siice_i.

In some embodiments, the network node 11, 20 is configured to derive a second joint key based on the joint key KASME-joint and to derive an updated joint key based on the second joint key and a second specific key KASME_siice_2.

In some embodiments, the network node 11, 20 is configured to determine by deriving a first joint key based on a common key KeNB_o and deriving the joint key KeNB-joint based on the first joint key and a first specific key K _e NB_siice_i. In some embodiments, the network node 11, 20 is configured to derive a second joint key based on the joint key KeNB-joint and deriving an updated joint key based on the second joint key and a second specific key KeNB_sii _ce _2.

In some embodiments, the network node 11, 20 is configured to determine, based on the joint key KASME-joint, KeNB-joint, cryptographic keys for use in protecting the shared communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the network node 11, 20 is configured to determine, based on the specific keys KASME_siice_i, KASME_siice_ ₂ , KeNB_siice_i, KeNB_siice_2, one or more separate security cryptographic keys for use in protecting the session specific communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the session specific signaling comprises one or both of session related non-access stratum control signaling and access stratum user plane signaling.

In some embodiments, the shared signaling comprises one or both of common non- access stratum control signaling and access stratum control plane signaling.

The present teachings also encompass a computer program 42, 52 for a network node 11, 20 for protecting communication on two or more network instances Slice 1, Slice 2. The computer program 42, 52 comprises computer program code, which, when executed on at least one processor on the network node 11, 20, causes the network node 11, 20 to perform the method 30 according to any of the described

embodiments.

The present teachings also encompass computer program products 41, 51 for a network node 11, 20. The computer program product 41, 51 comprises a computer program 42, 52 for implementing the embodiments of the methods as described, and a computer readable means on which the computer program 42, 52 is stored. The computer program product, or the memory, thus comprises instructions executable by the processor 40, 50. Such instructions may be comprised in a computer program, or in one or more software modules or function modules. The computer program product 41, 51 may, as mentioned earlier, be any combination of random access memory (RAM) or read only memory (ROM), Flash memory, magnetic tape,

Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc. Figure 20 illustrates a network node comprising function modules/software modules for implementing methods in accordance with the present teachings. The function modules can be implemented using software instructions such as computer program executing in a processor and/or using hardware, such as application specific integrated circuits (ASICs), field programmable gate arrays, discrete logical components etc., and any combination thereof. Processing circuitry may be provided, which may be adaptable and in particular adapted to perform any of the steps of the method 30 that has been described.

A network node 11, 20 is provided for protecting communication on two or more network instances. The network node 11, 20 comprises a first module 61 for obtaining, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the communication device on the respective network instances. Such first module 61 may, for instance, comprise processing circuitry adapted to obtain specific keys.

The network node 11, 20 comprises a second module 61 for determining a joint key for use in protecting shared communication with the communication device (14) on the two or more network instances. Such second module 62 may, for instance, comprise processing circuitry adapted to determine a joint key.

It is noted that one or both of the modules 61, 62 may be replaced by units.

Figure 21 illustrates a flow chart over steps of an embodiment of a method in a communication device in accordance with the present teachings.

The method 90 of protecting communication on two or more network instances Slice 1, Slice 2 may be performed in a communication device 14. The two or more network instances Slice 1, Slice 2 are used in serving the communication device 14. The method 90 comprises obtaining 91, for each of the two or more network instances Slice 1, Slice 2, a respective specific key KASME_siice_i, KASME_siice_ _2; KeNB_siice_i;

KeNB_siice_2 for use in protecting session specific communication with the network node 11; 20 on the respective network instances Slice 1, Slice 2.

The method 90 comprises determining 92 a joint key KASME-joint; KeNB-joint for use in protecting communication with the network node 11; 20 on the two or more network instances Slice 1, Slice 2. In an embodiment, the determining 92 the joint key KASME-joint; KeNB-joint is made based on the respective specific keys KASME_siice_i, KASME_siice_ _2; KeNB_siice_i, KeNB_siice_ ₂ .

In some embodiments, the determining 92 comprises deriving a first joint key based on a first specific key KASME_siice_i| KeNB_siice_i and, upon obtaining a second specific key KASME_siice_ ₂ ; KeNB_siice_ ₂ , deriving the joint key KASME-joint; KeNB-joint based on the first joint key and the second specific key KASME_sii _ce _ ₂ ; KeNB_siice_ ₂ .

In some embodiments, the determining 92 comprises deriving a first joint key based on an access authentication key KASME_O and deriving the joint key KASME-joint based on the first joint key and a first specific key KASME_siice_i.

In a variation of the above embodiment, the method 90 comprises deriving a second joint key based on the joint key KASME-joint and deriving an updated joint key based on the second joint key and a second specific key KASME_siice_ ₂ .

In some embodiments, the determining 92 comprises deriving a first joint key based on a common key KeNB_o and deriving the joint key KeNB-joint based on the first joint key and a first specific key KeNB_siice_i.

In some embodiments, the method 90 comprises deriving a second joint key based on the joint key KeNB-joint and deriving an updated joint key based on the second joint key and a second specific key KeNB_siice_ ₂ .

In some embodiments, the method 90 comprises determining, based on the joint key KASME-joint; KeNB-joint, cryptographic keys for use in protecting the shared

communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the method 90 comprises determining, based on the specific keys KASME_siice_i, KASME_siice_ _2; KeNB_siice_i; KeNB_siice_ ₂ , one or more separate security cryptographic keys for use in protecting the session specific communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the session specific signaling comprises one or both of session related non-access stratum control signaling and access stratum user plane signaling.

In some embodiments, the shared signaling comprises one or both of common non- access stratum control signaling and access stratum control plane signaling. Figure 22 illustrates a communication device comprising means for implementing embodiments of methods in accordance with the present teachings.

The communication device 14 comprises a processor 100 comprising any

combination of one or more of a central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc. capable of executing software instructions stored in a memory 101 which can thus be a computer program product. The processor 100 can be configured to execute any of the various embodiments of the method 90 for instance as described in relation to figure 21.

The memory 101 of the communication device 14 can be any combination of read and write memory (RAM) and read only memory (ROM), Flash memory, magnetic tape, Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc. The memory 101 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The communication device 14 comprises an interface 104 for communication with other devices, e.g. network nodes 11, 20. The interface 104 may, for instance, comprise a protocol stack, transmission circuitry, receiving circuitry for

communication with other devices.

The communication device 14 may comprise additional processing circuitry, schematically indicated at reference numeral 103 for implementing the various embodiments according to the present teachings.

The communication device 14 in which a method according to the teachings may be implemented may, for instance, be user equipment, a smart phone, a tablet, a machine type device such as sensor or any other device capable of handling at least one network slice.

A communication device 14 is provided for protecting communication on two or more network instances Slice 1, Slice 2, the two or more network instances Slice 1, Slice 2 used in serving the communication device 14. The communication device 14 is configured to: - obtain, for each of the two or more network instances Slice 1, Slice 2, a respective specific key KASME_siice_i, KASME_siice_ _2; KeNB_siice_i; KeNB_siice_ ₂ for use in protecting session specific communication with a network node 11; 20 on the respective network instances Slice 1, Slice 2, and

- determine a joint key KASME-joint; KeNB-joint for use in protecting communication with the network node 11; 20 on the two or more network instances Slice 1, Slice 2.

The communication device 14 may be configured to perform the above steps e.g. by comprising one or more processors 100 and memory 101, the memory 101 containing instructions executable by the processor 100, whereby the communication device 14 is operative to perform the steps. That is, in an embodiment, a communication device 14 is provided for protecting communication on two or more network instances, the two or more network instances being used in serving the communication device, the communication device 14 comprising one or more processors 100 and memory 101, the memory 101 containing instructions executable by the processor 100, whereby the communication device 14 is operative to obtain, for each of the two or more network instances, a respective specific key for use in protecting session specific

communication with a network node on the respective network instances, and determine a joint key for use in protecting communication with the network node 11; 20 on the two or more network instances.

In an embodiment, the communication device 14 is configured to determine the joint key KASME-joint; KeNB-joint based on the respective specific keys KASME_siice_i, KASME_siice_ _2;

KeNB_Slice_l, KeNB_Slice_2.

In some embodiments, the communication device 14 is configured to determine by deriving a first joint key based on a first specific key KASME_siice_i; KeNB_siice_i and, upon obtaining a second specific key KASME_siice_2; KeNB_siice_2, deriving the joint key KASME-joint; KeNB-joint based on the first joint key and the second specific key

KASME_Slice_2; KeNB_Slice_2.

In some embodiments, the communication device 14 is configured to determine by deriving a first joint key based on an access authentication key KASME_O and deriving the joint key KASME-joint based on the first joint key and a first specific key KASME_siice_i. In some embodiments, the communication device 14 is configured to derive a second joint key based on the joint key KASME-joint and to derive an updated joint key based on the second joint key and a second specific key KASME_siice_2.

In some embodiments, the communication device 14 is configured to determine by deriving a first joint key based on a common key KeNB_o and deriving the joint key KeNB-joint based on the first joint key and a first specific key K _e NB_sii _ce _i.

In some embodiments, the communication device 14 is configured to derive a second joint key based on the joint key KeNB-joint and derive an updated joint key based on the second joint key and a second specific key KeNB_siice_2.

In some embodiments, the communication device 14 is configured to determine, based on the joint key KASME-joint; KeNB-joint, cryptographic keys for use in protecting the shared communication on the two or more network instances Slice 1, Slice 2.

In some embodiments, the communication device 14 is configured to determine, based on the specific keys K _A sME_siice_i, K _A sME_siice_2; KeNB_siice_i; KeNB_siice_ ₂ , one or more separate security cryptographic keys for use in protecting the session specific communication on the two or more network instances Slice 1, Slice 2.

In various embodiments, the session specific signaling comprises one or both of session related non-access stratum control signaling and access stratum user plane signaling.

In various embodiments, the shared signaling comprises one or both of common non- access stratum control signaling and access stratum control plane signaling.

The present teachings also encompass a computer program 102 for a communication device 14 for protecting communication on two or more network instances Slice 1, Slice 2. The computer program 102 comprises computer program code, which, when executed on at least one processor on the communication device 14, causes the communication device 14 to perform the method 90 according to any of the described embodiments.

The present teachings also encompass computer program products 101 for a communication device 14. The computer program product 101 comprises a computer program 102 for implementing the embodiments of the methods as described, and a computer readable means on which the computer program 102 is stored. The computer program product, or the memory, thus comprises instructions executable by the processor 100. Such instructions may be comprised in a computer program, or in one or more software modules or function modules. The computer program product 101 may, as mentioned earlier, be any combination of random access memory (RAM) or read only memory (ROM), Flash memory, magnetic tape,

Compact Disc (CD)-ROM, digital versatile disc (DVD), Blu-ray disc etc.

Figure 23 illustrates a communication device comprising function modules/software modules for implementing methods in accordance with the present teachings. The function modules can be implemented using software instructions such as computer program executing in a processor and/or using hardware, such as application specific integrated circuits (ASICs), field programmable gate arrays, discrete logical components etc., and any combination thereof. Processing circuitry may be provided, which may be adaptable and in particular adapted to perform any of the steps of the method 30 that has been described.

A communication device 14 is provided for protecting communication on two or more network instances. The communication device 14 comprises a first module 110 for obtaining, for each of the two or more network instances, a respective specific key for use in protecting session specific communication with the network node on the respective network instances. Such first module 110 may, for instance, comprise processing circuitry adapted to obtain specific keys.

The communication device 14 comprises a second module 120 for determining a joint key for use in protecting communication with the network node 11; 20 on the two or more network instances. Such second module 120 may, for instance, comprise processing circuitry adapted to determine a joint key for use in protecting

communication with the network node on the two or more network instances.

It is noted that one or both of the modules 110, 120 may be replaced by units.

The invention has mainly been described herein with reference to a few

embodiments. However, as is appreciated by a person skilled in the art, other embodiments than the particular ones disclosed herein are equally possible within the scope of the invention, as defined by the appended patent claims.