Method and device for distributing multicast encryption keys

Abstract

To provide a method for a primary station for distributing an encryption key to a plurality of secondary stations, the primary station and the secondary stations.SOLUTION: The method includes determining whether a group key needs to be updated, the group key being used for multicast encrypted communication from a primary station to a plurality of secondary stations, and when determining that an update is needed, transmitting a first set key by unicast to at least one first subset of the secondary stations through an encrypted unicast message, the multicast message being encrypted by the first set key or including the updated group key in the encrypted unicast message carrying the key of the first step, and transmitting the updated group key to a further respective set of secondary stations in a respective multicast message, the multicast message being encrypted by a respective set key associated with each corresponding set.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present invention relates to the field of wireless communications, and in particular to security aspects of communications between a primary station, e.g. a base station, and at least one secondary station, e.g. a terminal or mobile station, forming a network in which other entities, such as security entities, may be present. [Background technology]

[0002] In wireless networks, terminals connect to the network to exchange data. Security is particularly important for wireless devices, where physical interaction is not required to access the network. Encryption also makes it possible to control access to resources such as multimedia flows. Wireless networks must therefore implement some measures to be able to exclude devices that are not authorized in the network. 3GPP (registered trademark) is an organization responsible for standardizing global solutions for mobile telecommunications systems. Telecommunications systems being developed within the 3GPP (registered trademark) partnership are no exception. In particular, security measures are being discussed to enhance network security for 5G.

[0003] 5G Multicast Broadcast Service (5MBS) allows subscribers to gain access to data streams, especially multimedia data streams. A typical application example is the streaming of video and further information during live events, such as live events in stadiums (sports, concerts), such as replayed video or additional information or enhanced performances. An important aspect is to ensure that all subscribers, and only subscribers, can gain access to the service. Therefore, the stream is encrypted by a group encryption key shared between all users' terminals.

[0004] However, different problems have been found with currently proposed solutions, which are summarized below as part of the background: - Background 1: 5MBS Communication Architecture for 5G, r17 - Background 2: Current security key issues and solutions for 5MBS - Background 3: MBMS Security Architecture for 5G, r16.

[0005] Background 1: 5MBS Communication Architecture for 5G, r17 TR23.757v1.0.1 (hereafter referred to as [1]) describes a study on architecture enhancements for 5G Multicast Broadcast Services (abbreviated as 5MBS) for 5G (Release 17). Section 4 of [1] describes the architecture assumptions and principles, and the following text is adapted from Section 4.

[0006] First, 5MBS applies the following general architectural requirements and principles: - The solution shall be based on 5G system architecture principles, similar to those in TS 23.501 (hereinafter referred to as [2]), including flexibility and modularity for newly introduced functions. - The system shall provide efficient transport for a variety of multicast and broadcast services. - The solution shall have minimal impact on existing external services. The architecture reference model defined in TS23.501[2] clause 4.2 is used as the baseline architecture for supporting multicast and broadcast services in this study. In particular, Figure 1 shows a high-level MBS architecture with 5G UE, NG-RAN and 5GC.

[0007] Additionally, there are some specific requirements for Internet Protocol Television (IPTV). - The solution for IPTV shall have minimal impact on the IPTV network and set-top boxes (STBs). - The solution for IPTV STBs shall reuse IGMP / MLD messages via the user plane to subscribe / unsubscribe to IPTV channel groups. The solution for IPTV shall provide an efficient mechanism for UEs to subscribe / unsubscribe to IP channel groups, including reducing latency and signaling.

[0008] The sequence for establishing and delivering an MBS session is assumed to be as follows: 1. Optional distribution of 5G MBS service information from the application / service layer to the 5G CN. Note that a framework is available for distributing 5G MBS service information to the 5G CN (Core Network). However, this step can be exchanged by prior agreement without explicit signaling. 2. The UE participates in receiving the MBS flow, i.e., the UE requests to join the MBS session (in the case of a multicast session). 3. Establishment of MBS flow transport. Note that this step may occur before step 2 for individual UEs joining an already started MBS session. 4.MBS data delivery to UE. 5. The UE stops receiving the MBS flow (in case of a multicast session). 6. Release of MBS flow transport (session stop).

[0009] MBS traffic needs to be delivered from a single data source (application service provider) to multiple UEs. Depending on many factors, multiple delivery methods may be used to deliver MBS traffic in 5GS. For clarity, the delivery methods are not referred to as unicast / multicast / broadcast, but as described below.

[0010] From the 5G CN perspective, two delivery methods are possible. - 5GC individual MBS traffic delivery method: The 5G CN receives a single copy of MBS data packets and delivers separate copies of those MBS data packets to individual UEs via per-UE PDU sessions. - 5GC shared MBS traffic delivery method: The 5G CN receives a single copy of MBS data packets and delivers a single copy of those MBS packets to a RAN node, which then delivers them to one or more UEs.

[0011] If the 5GC individual MBS traffic delivery method is supported, the same received single copy of an MBS data packet by the CN may be delivered via both the 5GC individual MBS traffic delivery method for some UEs and the 5GC shared MBS traffic delivery method for other UEs.

[0012] From the RAN perspective, two distribution methods are available for transmitting MBS packet flows over the air (in the case of shared distribution). - Point-to-Point (PTP) delivery method: The RAN node delivers separate copies of the MBS data packets over the air to individual UEs. - Point-to-multipoint (PTM) delivery method: The RAN node delivers a single copy of the MBS data packet over the air to a set of UEs.

[0013] It should be noted here that the RAN node may use a combination of PTP / PTM to deliver MBS packets to the UE. As shown in Figure 2, depending on the selected solution, a shared PTP or PTM delivery method and a dedicated delivery method may be used simultaneously for a 5G MBS session.

[0014] Appendix A.1 of [1] describes the 5MBS reference architecture alternatives, which are considered in particular as transport layer aspects and service layer aspects, which are identified below as A.1.1 and A.1.2.

[0015] A.1.1. Transport Layer Aspects of the Reference Architecture: Figure 3 shows the 5G system architecture for integrated multicast transport with unicast. The solution relies on extending existing 5GS network capabilities, NG-RAN and UE, which currently only support unicast transport, to support multicast transport.

[0016] The following new functions will be added to the current AF, 5GC NF (Network Function), NG-RAN, and UE: - Application Functions (AF): - MBS service function, supporting negotiation with NEF for service exposure. - Network Exposure Function (NEF): - 5GMBS service exposure. - Negotiation of 5G MBS services with AF, including QOS and 5G MBS service area. - Policy Control Function (PCF): - Supports policies for multicast services, including QoS parameters such as 5QI, MBR, and GBR. - Provides policy information about MBS sessions to the SMF. - Receives MBS service information directly from the AF (operator owned) or indirectly via the NEF. - Session Management Facility (SMF): - Control of MBS transport based on MBS policies received from the PCF. - Configuration of a User Plane Function (UPF) for MBS flows and for point-to-point or point-to-multipoint transport. - RAN configuration for MBS flows and QOS information. - SM configuration in the UE for MBS flows. - SMF can be used for both unicast and MBS. - User Plane Function (UPF): - Support for packet filtering of MBS flows and delivery of MBS flows to the RAN via point-to-point or point-to-multipoint N3. - Receive 5G MBS flow configuration from the SMF. - Detecting Internet Group Management Protocol (IGMP) packets and notifying the SMF (if UE join is performed via IGMP). - The UPF can receive both unicast and MBS flows. - The I-UPF may be used for delivery of MBS flows from the UPF attached to N6 to the NG-RAN, and the N9 interface may be used for MBS traffic delivery. - NG-RAN: - Receiving MBS flows via N3 and delivering them over the air. - Switching between multicast and unicast delivery of MBS flows. - UE configuration for MBS flow reception at the AS layer. -UE: - Support for UE policy configuration extensions to MBS. - Support for SM extensions for MBS flows. - Signaling to join MBS flows (via SM signaling or user plane IGMP join). - MBS support at the AS layer.

[0017] A.1.2 Service Layer Aspects for Reference Architecture: Orthogonal to the description of the multicast flow user plane model at the transport layer, a service layer can be supported above. The service layer is completely separate from the multicast transport. This allows applications that do not require a service layer to establish multicast transport directly over Nnef (control plane) and N6 (user plane data).

[0018] Figure 4 shows an example implementation of service layer support for multicast / broadcast using xMB / MB2 as entry point. A new network function called Multicast Service Function (MSF) is introduced. MSF provides only service layer functionality and requires the 5G system for the underlying multicast transport required for multicast services (via Npcf or Nnef). MSF has the following functions: - Entry point for both control plane service layer signaling and user plane data, e.g. xMB / MB2. Interaction can occur directly with an external AF or via the NEF. - MSF Control Plane (MSF-C): - Multicast service configuration. - MBS Service Level Management. - xMB-C / MB2-C termination. - Codec configuration (if required). - MSF User Plane (MSF-U): - xMB-U / MB2-U termination. - Data encoding in the service layer. - Multicast service layer data packet delivery via N6.

[0019] If your application does not require a particular service layer feature, your application should: - Nnef directly for multicast session configuration / negotiation, - N6 for multicast data distribution can be used.

[0020] This is illustrated in FIG. 5, which shows an exemplary MBS system with direct application server / function interaction.

[0021] Appendix A.2 of [1] describes the 5GMBS system architecture based on dedicated MBS functions.

[0022] To support MBS in 5GS user service delivery, there are two variant operating modes, one for transport-only mode and the other for full-service mode (TS23.246 clause 7.5). In transport-only mode, the MBS application data is transparent to the network functions in Figure 6. In full service mode, the MBSF / MBSU is aware of the content stream and is able to convert it into a 3GPP compliant stream.

[0023] Figure 6 shows a single exemplary architecture for MBS in 5GS. In this Figure 6, the SMF and UPF responsible for supporting MB sessions are referred to as "MB-SMF" and "MB-UPF." Nothing prevents the MB-SMF and MB-UPF from simultaneously supporting both PDU sessions and MB sessions, for example, PDU sessions and MB sessions to the same DNN. However, the MB-SMF and MB-UPF can also be deployed and configured to handle MB sessions exclusively. It is believed that it would reduce signaling and, in some cases, be simpler and more cost-effective to operate a limited number of MB-SMFs and MB-UPFs dedicated to MBS. This architecture allows for this, if preferred.

[0024] The extensions to existing entities and new functional components are as follows: - UE, NG-RAN, AMF, SMF, UPF, NEF and PCF support MBS. - The UE supports 5G MBS services. - NG-RAN supports point-to-multipoint (PTM) and point-to-point (PTP) delivery of MBS media. NG-RAN independently controls the switching between PTM and PTP for best quality of service and resource efficiency. - The AMF selects the MB-SMF and is extended to be part of the signaling distribution tree. - MB-SMF is an SMF extended to control MB sessions, signaling with AF (via NEF / MBSF), QoS control using PCF, and provision of MB session information upon request from AMF. PDU sessions maintained by the UE for individual delivery of MBS services can be associated with MB sessions managed by the MB-SMF. - MB-UPF is a UPF extended with MBS user plane functions. - MBSF (Multicast / Broadcast Service Function) is a function that can be part of the NEF or deployed independently. The MBSF may support TMGI allocation or other MBS signaling for service level management. The MBSF also provides an interface to application functions or content providers, and it has an interface to the MBSU. The MBSF may perform authorization of UEs to join MB sessions. - MBSU (Multicast / Broadcast Service User Plane) is a new entity for processing the payload part for service level functions and management. - NEF is an existing NF that provides an interface to the AF. -PCF is extended to handle QOS for MB sessions, e.g., to allow QoS profiles for shared delivery.

[0025] The extensions to existing interfaces and new interfaces are as follows: - The N2 interface controls the MB sessions, including the management of the shared N3 tunnel between the MB-UPF and the NG-RAN. - The N3 interface supports a shared N3 tunnel between the MB-UPF and the NG-RAN. - The N4 interface manages the shared N3 tunnel between the MB-UPF and the NG-RAN, including the establishment of the shared N3 tunnel. - The N7 interface and N30 interface are capable of policy control of MB sessions. - The N11 interface is extended with MBS control signaling, including management of the shared N3 tunnel between the MB-UPF and the NG-RAN. - The N29 interface is extended with MBS control signaling. - The N33 interface is extended with MBS control signaling. - Ny: A new interface between MBSF and MBSU to manage MBSU functions. -N×MB-U: A new interface between the new MBSU and the AF for MBS user plane traffic.

[0026] Following these architectures, several possible solutions are described in [1]. For example, solution #2 in [1] assumes a 5G MBS system architecture based on dedicated MBS functionality. Figure 6.2.2.2a-1 describes session initiation with 5GC dedicated MBS traffic delivery (i.e., with a PUD session to the UE). Figure 6.2.2.2-1 describes session initiation for an MBS session. It is important to ensure that the AF delivers the media stream to the MB-UPF, which then sends it further down the network.

[0027] Background 2: Current security issues and solutions for 5MBS Based on the above overall architecture for 5MBS [1], currently, research is being conducted on how to secure the 5MBS system. This is reflected in TR33.850 v0.2.0 (Study on Security Aspects of Enhancements for 5G Multicast-Broadcast Services) [2]. Currently, there are three main issues that need to be resolved: - Key Problem #1: 5GS shall support authentication and authorization for multicast communication services. In particular, this key problem relates to the reference architecture of [1] summarized above and to Key Problem #3 of [1], which includes two aspects: (i) define and study how UEs support the required level of authorization to access multicast communication services, and (ii) how UEs can subscribe / unsubscribe to multicast communication services (including being authorized or revoked from accessing them). - Key Issue #2: 5GS shall support confidentiality, integrity and anti-replay protection of MBS traffic. - Key Issue #3: The distribution of keys for protection of MBS traffic between the key generator and the UE shall be confidentiality, integrity and anti-replay protected.

[0028] In [2], there are three solutions for KI#2 and KI#3. These solutions are solutions #1, #2 and #3. - Solution #1 focuses on protecting MBS traffic at the transport layer. In this case, a group key is used at the PDCP level and is generated in the RAN. This group key is used to protect the MBS traffic. - Solution #2 focuses on protecting MBS traffic at the service layer. A group key is generated in the (MB)-SMF. This key is securely sent to each UE using a Kausf-derived key, the MUK. The group key is used to protect the MBS traffic. - Solution #3 focuses on protecting MBS traffic with a Multicast Transport Key (MTK) that is generated in the core network and distributed to the UEs in a secure (unicast) manner. This MTK is used to protect the MBS traffic.

[0029] Background 3: MBMS Security Architecture for 5G, r16 Important to the description of the invention in 5MBS is how security is implemented in 4G for MBMS. The security architecture for MBMS is described in TS33.246 [3]. The most important aspects are summarized below.

[0030] *Appendix B lists the security threats that have been considered. B.1 is a threat at the air interface. B.1.1 lists, among other things, "unauthorized access to MBMS user service data," which includes threats that an intruder could eavesdrop on MBMS user service data, such as a user subscribing to an MBMS user service and then continuing to receive the service without being charged, and a subscriber deriving decryption keys and distributing them to unauthorized parties. B.1.2 lists "threats to integrity," which includes modifying and replaying messages in a way that deceives the user of content from its actual source.

[0031] *Appendix C lists security requirements. In particular, C.4 lists requirements for MBMS key management, including that "UEs and MBMS key generators shall support re-keying as frequently as the operator deems necessary to ensure that 1) a user who subscribes to an MBMS user service but subsequently unsubscribes shall not be able to further access the MBMS user service without being appropriately charged, 2) a user who has subscribed to an MBMS user service shall not be able to access data from a previous transmission in the MBMS user service without being appropriately charged, and 3) the impact of subscribed users distributing decryption keys to unsubscribed users shall be controllable."

[0032] *Figure 7 (corresponding to Figure 4.1 in [3]) describes the overall MBMS security architecture. (From the Itectec web page available at https: / / itectec.com / spec / 4-2-key-management-overview / (hereinafter referred to as [4]), a description of key management and security in MBMS based on [3] is included. According to [4], and section 4.2 of [3], "The BM-SC controls the use of MBMS Service Keys (MSKs) to secure the different RTP sessions and FLUTE channels. The MSKs are used to protect the distribution of MBMS Transport Keys (MTKs), which are used to secure the RTP sessions and FLUTE channels as specified in clauses 6.5 and 6.6. The distribution of the MSKs is secured using user-specific MBMS User Keys (MUKs) received from the GBA, see clause 6.1. The MSKs and MTKs are managed at the MBMS user service level." This means that a UE that has access to the service receives an MSK protected with the MUK. The MTKs are distributed to multiple UEs protected with the MSKs. This is shown below (arrows indicate protection): [Table 1]

[0033] *Section 6.3.2.2 describes the MSK request procedure required by the UE to obtain a new MSK. This procedure is part of other procedures, for example when the UE misses a key update (out of coverage) or a solicited pull procedure with the BM-SC. This last procedure is described in 6.3.2.2.4 and is shown in Figure 6.2b of [3] and Figure 8 below. It shows that the BM-SC sends a MIKEY message to the UE, which the UE verifies and, if correct, sends an HTTP POST request to obtain the MSK update.

[0034] *MIKEY stands for Multimedia Internet Keying, and it is defined in RFC3830 (https: / / tools.ietf.org / html / rfc3830). MIKEY was defined by Ericsson Research in 2004 and describes a key management scheme that can be used for real-time applications (both for peer-to-peer and group communication).

[0035] *Section 6.3.2.3 of [3] describes how the MSK is delivered to the UE, in particular (i) MSK Push (Section 6.3.2.3.1), where the MB-SC delivers the key in a MIKEY message over UDP. The UE responds with a MIKEY message, also over UDP.

[0036] *Section 6.3.3 of [3] describes the procedures for MTKs, including their unique ID, which depends on the MSK ID. This means that the same MTK cannot be used with two different MSKs. MTK updates are protected using the MSK, and this message can be included in the multicast / broadcast stream.

[0037] *Appendix I shows an example of how traffic can be protected. In particular, the same MSK can be used to protect two user services.

[0038] *Section 6.3.4 describes how to handle "multiple BM-SC deployments," which is only applicable when the same MBMS user service is transmitted through multiple BM-SCs. When this happens, the keys in the multiple BM-SCs, MSK (Section 6.3.4.4) and MTK (Section 6.3.4.5), are the same because they are used with the same traffic. Solutions #1, #2, and #3 in [2] use a single group key to protect multicast / broadcast traffic. The problem is that if the group key is compromised (e.g., the UE is malicious or the UE is removed from the MBS), those solutions do not describe how to update the group key so that the distributed content cannot be obtained or modified at a later point in time. In particular, if the group key cannot be updated, an attacker can: a) You can still have access to the content, for example by passively monitoring communications. b) Traffic can be injected, for example in the context of a MitM attack.

[0039] Similarly, [3] describes a security architecture for MBMS in which an individual device key (MUK) is used to distribute a multicast service key (MSK), which is used to protect a multicast transport key (MTK) for a particular MBMS service (r16). In this case, the group key is equivalent to the MTK. If a UE is compromised, the UE needs to update the MSK and MTK. [3] describes how to update the MSK, but updating it requires a lot of signaling, as each UE needs to contact the BM-SC to obtain a new MSK, as shown in Figure 8, which describes a BM-SC-responsive pull. Summary of the Invention [Problem to be solved by the invention]

[0040] One object of the present invention is to alleviate the above-mentioned problems.

[0041] Another object of the present invention is to ensure that cryptographic keys are updated efficiently.

[0042] It is yet another object of the present invention to reduce the amount of signaling required to reconfigure the system when a terminal is compromised or disabled.

[0043] It is yet another object of the present invention to provide a primary station and a secondary station that can more efficiently update a shared encryption key while improving the security of the system. [Means for solving the problem]

[0044] Accordingly, in a first aspect of the present invention there is provided a method for a primary station to distribute an encryption key to a plurality of secondary stations, the method comprising: a. determining whether a group key needs to be updated, the group key being used for multicast secured communications from a primary station to multiple secondary stations; b. when determining that an update is required, transmitting the updated encryption key to at least a subset of the secondary stations via an encrypted message; The present invention proposes a method having the following features.

[0045] Thus, when the group key needs to be updated, the system automatically provides an updated encryption key, ensuring that the system is not compromised. Note that the encryption key may correspond to the encryption key used to encrypt the data information. In some variations, the encryption key may be used for integrity protection, for example, to authenticate the origin or freshness of a message.

[0046] In a variant of the first aspect of the invention, the updated encryption key is an updated group key, and the encrypted message is encrypted with a user-specific encryption key and sent unicast. Unicast means that the message is addressed to a single target. This corresponds to a point-to-point message. This can be done, for example, by using a dedicated channel and / or by identifying the recipient of the message.

[0047] In yet another variation of the first aspect of the present invention, the step of determining whether the group key needs to be updated comprises determining whether at least one of the following conditions is met: at least one of the access rights of the secondary stations has been revoked; at least one of the access rights of the secondary stations has disappeared; the validity time of the group key has expired; at least one of the secondary stations has moved away from a predetermined location.

[0048] In yet another variation of the first aspect of the present invention, the updated encryption key is a first set key shared with a first set of secondary stations.

[0049] According to this variant, the secondary stations are grouped into sets. Each set includes several secondary stations, all of which share the same set encryption key. This set encryption key, or first set key, allows for encrypting / protecting several multicast messages addressed to the secondary stations of the first set. Therefore, when updating the group key, the primary station can direct each multicast message to each set. This reduces the number of messages sent, since the messages are sent by multicast to each secondary station and no longer by unicast. By multicast, this corresponds, for example, to a single message addressed to a group of secondary stations, for example, using a common encrypted set key. This can be done, for example, by using a broadcast channel. In one example of this variant, the first set key is updated when it is determined in step a. that the access rights of at least one secondary station belonging to the first set are not currently valid. This actually means that one of the secondary stations of the first set has been compromised or disabled. Therefore, the first set needs to update its set key to ensure that an attacker cannot access the data sent to the first set.

[0050] Once this first set key is updated, the updated group key may be sent by multicast to each set of secondary stations, which corresponds to sending the updated group key to each set of secondary stations in a message protected with the respective set key associated with each set of secondary stations.

[0051] Note that in some cases, for example, if a secondary station is joining for the first time or if the number of stations in the set is small, this message can be sent unicast instead. Furthermore, in certain cases, it is possible to send the message twice: once unicast and once multicast.

[0052] It should be noted that the first set key may be used to encrypt messages sent to the set of secondary stations, and / or to protect the integrity of messages sent to the set of secondary stations, and / or to protect the freshness of messages sent to the set of secondary stations.

[0053] According to a second aspect of the present invention, there is provided a method for a primary station to distribute an encryption key to a plurality of secondary stations, the method comprising: a. determining whether a group key needs to be updated, said group key being used for secured multicast communications from a primary station to multiple secondary stations; b. when it determines that an update is required, sending the updated group key to each set of secondary stations in a respective multicast message, the multicast message being protected by a respective set key associated with each corresponding set; A method is proposed, which has the following:

[0054] Similar to what has been described previously, according to this second aspect of the invention, the secondary stations are grouped into sets. Each set includes several secondary stations, all of which share the same set encryption key. This set encryption key, or first set key, allows for encrypting / protecting several multicast messages addressed to the secondary stations of the first set. Thus, when updating the group key, the primary station can direct each multicast message to each set. This dramatically reduces the number of messages sent, since the messages are sent by multicast to each secondary station and no longer by unicast. By multicast, this corresponds, for example, to a single message addressed to a group of secondary stations, for example, using a common encrypted set key. This can be done, for example, by using a broadcast channel. In one example of this variant, the first set key is updated when it is determined in step a. that the access rights of at least one secondary station belonging to the first set are not currently valid. This actually means that one of the secondary stations of the first set has been compromised or revoked. Therefore, the first set needs to update its set key to ensure that an attacker cannot access data sent to the first set.

[0055] In this second aspect of the invention, the step of determining whether the group key needs to be updated is based on the following condition: - at least one of the access rights of the secondary station has been revoked; - the loss of access rights of at least one of the secondary stations; - The validity period of the group key has expired, - At least one of the secondary stations has left its designated location is satisfied.

[0056] If the need for updating is linked to an access rights issue with one of the stations, the set key may also need to be updated. By way of example, the method comprises, in step a., if the decision that the group key is linked to the access rights of a first secondary station belonging to a first set of secondary stations is not valid, transmitting a new first set key by unicast to each secondary station of said first set through a protected unicast message.

[0057] Once this update of the first key for the first set has occurred, the secondary stations of the first key may receive the updated encrypted group key. Thus, in such an example, the method further includes step c. of sending the updated group key to the first set of secondary stations in a multicast message, which will be encrypted with the new first set key. This is similar to the other sets, but which did not require a set key update. Thus, for all secondary stations of the other sets, the number of messages required for updating is reduced.

[0058] In a different example, the group key can be updated by the same unicast message used for the new first set key. Thus, the protected unicast message also includes the updated group key. This allows for avoiding sending a new multicast message to the first set, thereby further reducing the amount of messages issued during group key update.

[0059] In a third aspect of the present invention, there is provided a method for a primary station to distribute an encryption key to a plurality of secondary stations, the method comprising: a. determining whether a group key needs to be updated, said group key being used for secured multicast communications from a primary station to multiple secondary stations; b. when determining that an update is required, transmitting the first set key by unicast to at least a first subset of secondary stations through a protected unicast message; c. sending the updated group key to the first set of secondary stations in a multicast message, the multicast message being protected by a first set key, or alternatively including the updated group key in the protected unicast message of step b.; d. sending the updated group key to each further set of secondary stations in a respective multicast message, the multicast message being protected by a respective set key associated with each corresponding set; A method is proposed, which has the following:

[0060] It should be noted that the primary station may be a base station, e.g., an eNodeB (eNB) in LTE or a gNodeB (gNB) in 5G. However, the primary station may correspond to a higher-level entity in the network, e.g., a core network element or a trust center of the network. In such cases, the step of transmitting to the secondary station involves indirect transmission of the message through different interfaces (fiber optic, Ethernet, air interface) and through different entities, e.g., a base station or a relay. In such cases, it may not be directly from the primary station. The message delivering the encryption key may be originated by a given 5G network function in the core network, which may then give it to another entity in the core network responsible for transmitting 5MBS traffic.

[0061] In a variation of the second or third aspect of the present invention, the set of secondary stations is formed based on location, and step d. further comprises the primary station transmitting the updated group key in at least one further multicast message, the further multicast message being encrypted by the respective set keys used in the neighbor set. In one example, the neighbor set is a set of multiple secondary stations camping in a cell served by another primary station. It can be, for example, a set of secondary stations served in adjacent cells. These can be served by the same or different primary stations. This allows the secondary station a degree of mobility without risking missing the group key update as it has moved away from its original cell. To further improve this reliability and reduce the risk of the secondary station missing the updated key, the multicast message can be periodically retransmitted.

[0062] In different examples of these aspects, however, the sets may be formed in a more random manner, for example based on the identifiers of the secondary stations or based on the connection time.

[0063] In yet another variation of these aspects of the invention, the multicast message includes the updated group key along with an authentication footprint message that is computed as a hash of the updated group key.

[0064] According to a fourth aspect of the present invention, there is provided a method for a secondary station to receive an encryption key in a network, the method comprising: a. receiving a first set key by unicast through a protected unicast message from a primary station, the first key being associated with a first set of secondary stations; b. receiving and decrypting the updated group key in a multicast message to a first set of secondary stations, said decrypting using the first set key; A method is proposed, which has the following:

[0065] In a variant of the fourth aspect of the present invention, it is proposed that the multicast message includes an authentication footprint message together with the protected updated group key, and the method further comprises the secondary stations authenticating the multicast message by checking whether the hash of the decrypted group key matches the received authentication footprint. This therefore allows all secondary stations to report a malfunction if an attacker tries to impersonate the primary station and send a fake message. It can therefore be proposed to report the anomaly to the primary station if the check fails.

[0066] According to a fifth aspect of the present invention, there is provided a primary station operating in a cellular network and in communication with a plurality of secondary stations, the primary station comprising: a controller adapted to determine whether a group key needs to be updated, the group key being used for protected multicast communication from a primary station to a plurality of secondary stations; a transmitter coupled to the controller, adapted to transmit an updated group key to each set of secondary stations in a respective multicast message when determining that an update is required, the multicast message being protected by a respective set key associated with each corresponding set; A primary station is proposed, which comprises:

[0067] It should be noted that the primary station may be a base station, e.g., an eNodeB in LTE or a gNodeB in 5G. However, the primary station may correspond to a higher-level entity in the network, e.g., a core network element or a network trust center. In such cases, the step of transmitting to the secondary station involves indirect transmission of the message through different interfaces (fiber optic, Ethernet, air interface) and through different entities, e.g., including a base station or a relay. In such cases, it may not be directly from the primary station. The message delivering the encryption key may be originated by a given 5G network function in the core network, which may then give it to another entity in the core network responsible for transmitting 5MBS traffic.

[0068] Therefore, the primary station can update the group key to all secondary stations in a more efficient manner, since many multicast messages can be used instead of the traditional unicast messages.

[0069] According to a sixth aspect of the present invention, a secondary station is proposed, operating in a cellular network and in communication with a primary station, the secondary station comprising: a receiver adapted to receive by unicast a first set of keys from the primary station through a protected unicast message, said first keys being associated with the first set of secondary stations; and a controller adapted to decrypt an updated group key in a multicast message to the first set of secondary stations, said decrypting using the first set of keys.

[0070] It should be noted that decoding the multicast message may also be replaced or complemented by authenticity and / or freshness checks of the multicast message.

[0071] According to a seventh aspect of the present invention, it is proposed program code means as a computer program and / or dedicated hardware comprising instructions for carrying out the method of the first, second, third or fourth aspect of the present invention, stored and / or distributed on a suitable medium, such as an optical storage medium or a solid state medium, supplied together with or as part of other hardware, but which may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0072] It should be noted that the above apparatus may be implemented based on a discrete hardware circuit having the configuration of discrete hardware components, an integrated chip, or a chip module, or based on a signal processing device or chip controlled by a software routine or program stored in a memory that is written to a computer-readable medium or downloaded from a network, such as the Internet.

[0073] It is to be understood that the claimed method and the claimed apparatus (primary station or secondary station) may have preferred embodiments similar and / or equivalent to those defined in particular in the dependent claims.

[0074] It is to be understood that a preferred embodiment of the present invention can also be any combination of the above embodiments with the dependent claims or the respective independent claims.

[0075] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. [Brief explanation of the drawings]

[0076] [Figure 1] 1 is a diagram showing the high-level MBS architecture previously described. [Figure 2] 1 is a diagram showing the distribution method for MBS, previously described. [Figure 3]1 is a diagram showing the 5G system architecture for integrated multicast transport with unicast, as previously described. [Figure 4] 1 is a diagram illustrating an example of service layer support for multicast / broadcast, as previously described. [Figure 5] 1 is a diagram illustrating an exemplary MBS system with direct interaction with an application server, as previously described. [Figure 6] FIG. 1 is a block diagram illustrating a single exemplary architecture for MBS in 5GS, as previously described. [Figure 7] 1 is a diagram illustrating the overall MBMS security architecture previously described. [Figure 8] 1 is a diagram illustrating a conventional method for updating keys in a UE, as previously described. [Figure 9] 1 is a diagram illustrating a procedure according to a first embodiment of the invention. [Figure 10] 4 is a diagram illustrating a procedure according to a second embodiment of the invention. [Figure 11] 1 is a diagram illustrating a modified key hierarchy according to one embodiment of the present invention. [Figure 12] 1 illustrates a specific exemplary embodiment of the present invention. [Figure 13] 10 is a diagram illustrating a procedure according to another embodiment of the present invention. [Figure 14] 1 is a block diagram representing a network in which an embodiment of the present invention is implemented; [Figure 15] 1 is a diagram illustrating different key hierarchies for a proposed embodiment of the present invention. [Figure 16] 1 is a diagram of proposed changes in the 3GPP® standard. DETAILED DESCRIPTION OF THE INVENTION

[0077] As seen above, the present invention may be implemented in a cellular network, such as a 4G or 5G network.

[0078] In these telecommunication systems, shown in Figure 14, secondary stations 100 act as terminals or end devices (also called user equipment, UE, in 5G). The secondary stations can access different types of services, including voice and data services, through base stations 110 (also called gNB in ​​5G) deployed in the field. Each base station 110 serves and communicates with secondary stations 100 present in an area, also called a cell 111. The base stations are connected to a core network (CN) 120, managed by a network operator, which controls the telecommunication system and coordinates the delivery of services.

[0079] As can be seen in relation to Figure 14, such a cellular network comprises a number of terminals or secondary stations 100, which are mobile devices (or UEs) that can move from one network cell 111 to another. Each cell 111 is served by a base station 110 (or gNodeB) that forms the interface between the secondary stations 100 and the core network 120.

[0080] Thus, the secondary station 100 communicates with the base station 110 on various wireless channels, in the uplink (from the secondary station to the base station) and in the downlink (from the base station to the secondary station). For example, other wireless channels exist between secondary stations (e.g., sidelink channels) and between base stations (e.g., the X2 interface), but are not shown for the sake of brevity in Figure 14. Although embodiments of the present invention may also be applied to these interfaces, in the remainder of this specification, embodiments of the present invention focus on the link between the secondary station and the base station.

[0081] It should be noted that the various embodiments are implemented between a secondary station and a primary station. In some embodiments, the primary station may correspond to some entity of the core network 120. A base station may also act (partially or fully) as a primary station in the sense of embodiments of the present invention.

[0082] According to the definition of an embodiment of the present invention, a procedure is proposed to update the group key used to protect multicast / broadcast traffic in solutions #2 and #3 of [2]. The basic idea is to generate a new group key and distribute it to the UEs so that the multicast / broadcast content is protected with the new group key. This basic idea therefore ensures that an attacker cannot access the content or inject traffic, but it has the drawback of involving a high overhead to distribute the new content key to all "N-1" intact UEs.

[0083] The above basic idea is improved in various following embodiments and examples (extended ideas) by defining "M" UE groups, each associated with a key group. The groups can be based on, for example, the location of the UE. If the UE is compromised, - The content keys are updated using the group keys in the M-1 intact groups. - The group key and content keys are updated using N / M-1 messages directed to the UEs in the group corresponding to the compromised UE.

[0084] In this way, the signaling overhead is reduced from N-1 to N / M+M-2. For example, if N=10000 and M=25, the overhead is reduced from 9999 messages to 63 messages. This extended idea applies to solutions such as #1, #2 and #3 in [2] and can also be used to reduce the signaling overhead in [3].

[0085] Note that one difference between this embodiment of the present invention and the solution in [3] is that this embodiment allows distributing the same K_group (used to protect multicast / broadcast content, similar to the MTK in [3]) with a different K_set key (used to distribute the key group, similar to the MSK in [3]). [Table 2]

[0086] Although the basic embodiment of the present invention is detailed in the context of Solution #2 in [2], similar techniques are applicable to similar solutions in [2] (e.g., Solution #3). This embodiment is also applicable to [3].

[0087] Basic embodiment FIG. 9 describes the basic procedure proposed in this invention, where the alphabetical steps (af) are additions applied to the solution of Solution #2 in [2]. a) Check whether the UE is allowed to join the MBS group. b) Check whether the UE access rights have changed, for example whether they have been revoked. c) Send a request to update the group key. d) Update the group key. e) Send a protected unicast message with the MUK to each non-revoked UE updating K_group_enc and K_group_int. Each UE verifies the authenticity of the message and uses its MUK to decrypt the new group key. Freshness also needs to be verified (see embodiment 3 below). f) The updated group key is used to protect the content data and send it to the UE.

[0088] In Figure 9, AE stands for authenticated encryption, which means that a message is i) authenticated by, for example, a message authentication code (MAC) calculated using a key, for example, a unique key (K_int) for authentication and integrity protection, and ii) encrypted using a key, for example, a unique key (K_enc) for encryption. An example of AE is AES in GCM mode.

[0089] With this basic solution, it is possible to update k_group and prevent disabled UEs from accessing or modifying the broadcast data, which requires the exchange of N-1 messages if N UEs are subscribed to a given MBS.

[0090] Embodiment 1: Definition of UE Set and Set Key FIG. 10 illustrates an improved embodiment from the basic embodiment of the present invention, where the alphabetical steps (ai) are additions applied to the solution of Solution #2 of [2]. a) Check whether the UE is allowed to join the MBS group. b) Generate a key K_group to protect the content, and generate M keys K_sets to protect the delivery of the K_group, where a set refers to a set of M to N / L UEs. c) Determine which set the UE is placed in. d) Check whether the UE has been disabled, left the group, etc. e) Send a request to update 1) the group key used to protect multicast / broadcast content and 2) the set key used to protect distribution of the group key among the set of devices affected by the UE revocation. f) Group keys (K_group_enc and K_group_int) are updated. Set keys (K_set_enc and K_set_int) associated with a set of UEs are updated. g) The set keys of the M-1 UEs in the compromised set are updated through M-1 point-to-point interactions. h) A new group key used to protect the content is updated by sending L messages to the unaffected set. i) The updated group key is used to protect the content data and send it to the UE.

[0091] Using this embodiment, it is possible to update k_group and prevent disabled UEs from accessing or modifying broadcast data. This basic solution requires the exchange of M-1 point-to-point messages and the delivery of L multicast messages. For example, if N=1000, M=40, and L=25, the basic embodiment requires 999 messages, while this approach requires 64.

[0092] When this embodiment is applied to the solution proposed in [3], different sets of UEs accessing the same multicast / broadcast service are given different set keys (MSK). Instead of requiring unicast communication between the UE and the MB-BC, and group key updates, these different set keys are used to protect the same group key (MTK) at a given time. This modification changes the key hierarchy in MIKEY used in [3], as shown in Figure 11. An MSK is defined for a set of users, and there are L sets of users. Each of them can be updated individually, and each of them has a different counter {i1, i2, ..., iL}. When the set key (MSK) is updated, this implies a change in the group key (MTK). The MTK has a different counter to identify them. Even if the set key (MSK) is not updated, for example, if it has been used for a very long period of time, the group key (MTK) can be updated in a proactive manner.

[0093] 12 shows a more specific example where there are three sets of devices with set keys identified using MSK_1, MSK_2, and MSK_3. For each set of devices, there is also a device: in set 1 of devices, there is device a with a device key denoted MUK_a, in set 2 of devices, there is device b with a device key denoted MUK_b, and in set 3 of devices, there is device c with a device key denoted MUK_c. - The first group key in use for protecting content data is denoted MTK_0. - In this situation, a change occurs in set a of devices, e.g., a device leaves that set of devices. This triggers an update in MSK_1_i1 to MSK_1_(i1+1), i.e., the set key changes and its index increases. Since the group key MTK_0 can be compromised, a new MTK_1 is distributed in a secure way to the devices in the different sets using MSK_1_(i1+1), MSK_2_i2, and MSK_3_i3. In this situation, MTK_1 is used for a long period of time, which triggers an update to MTK_2, which is securely distributed using MSK_1_(i1+1), MSK_2_i2, and MSK_3_i3. - In this situation, a change occurs in set b of devices, e.g., a device leaves that set of devices. This triggers an update in MSK_2_i2 to MSK_2_(i2+1), i.e., the set key changes and its index increases. Since the group key MTK_2 can be compromised, a new MTK_3 is distributed in a secure way to the devices in the different sets using MSK_1_(i1+1), MSK_2_(i2+1), and MSK_3_i3.

[0094] This embodiment may also be compatible with solution #1 in [2]. Instead of having to broadcast N RRC reconfiguration requests, it is possible to send only M-1 RRC reconfiguration requests updating the new set key. The new group key must be broadcast together with the multicast / broadcast traffic; in particular, the new group key is protected with the L set keys of the L sets of UEs. Note that this requires that the RAN be able to include this key information in the multicast / broadcast traffic. If this last requirement is not feasible, an alternative would be to broadcast the new group key via the RRC reconfiguration request; however, note that these messages are unicast messages, so that a change in the RAN is needed to be able to broadcast the RRC reconfiguration message over a broadcast channel.

[0095] This solution can be used in the context of solution #3 in [2]. In this solution, a Multicast Transport Key (MTK) is defined, which is generated in the core network (MB-CP). This MTK is distributed (unicast) to each UE in a secure manner, and it is used to protect MBS data from the MB-UP to the UEs. When this embodiment is used, multiple set keys are generated in the core network (MB-CP). The set keys are then transported to the UEs in a secure manner by secure unicast messages. The set keys are then used to update the group keys that protect the content keys from the MB-UP to the UEs.

[0096] An important aspect of this embodiment is how the sets of UEs are defined. An option is to define them according to location. The location can, for example, refer to the area covered by a base station, or by the base station's antenna beam, or based on a tracking area. This is important because all UEs in that area can receive content using the same radio resources. A concrete example could be in a stadium where multicast / broadcast content (e.g., digital signage or information about a match) is to be delivered by a base station. To give the best possible performance, the base station uses multiple radio beams to address different sets of users in the stadium. Other ways to define the sets are possible, for example, depending on the characteristics of the UEs and the multicast and broadcast services they subscribe to.

[0097] Embodiment 2: Promoting mobility In Solution #1 of [2], mobility is further supported. When a UE moves to a nearby cell, it is important to use the same group key for multicast / broadcast content delivery to avoid traffic interruptions. From this perspective, the same group key is used to broadcast content in surrounding cells. Since the set key is used to update the group key, it is recommended to provide the UE with a set key associated with the set of devices surrounding the UE's location. The risk of not following this recommendation is that when the UE moves to a surrounding cell, the group key may be updated with the set key of that cell, causing the UE to miss the message. Alternatively, the base station could broadcast a group key update using the set key of the surrounding area. In this way, if a UE comes from the surrounding area, the UE will be able to decrypt the new group key. The advantage of this last method is that less key material is provided to the UE, reducing the risk of leakage. Another obvious benefit is that the set key should be updated when the UE leaves the UE's set. If the UE has a single set key, the amount of updates is smaller.

[0098] This is shown in Figure 13, where a UE (e.g., the UE in the bold circle) may have multiple set keys. In this case, the UE in the bold circle may have K_0 and K_0i, i = {0,...,5}. Alternatively, the UE may only have K_0, and surrounding cells would be broadcasting group key updates using the surrounding set keys.

[0099] Note that an additional benefit of this relates to RAN architectures that use DU / CU splitting. In such an architecture, each distributed unit (DU) can be an independent cell, and a central unit (CU) runs the RRC layer for all DUs. An approach can be to have a different group key for each DU to protect MBS traffic. When a UE leaves a DU, only the UEs in the DU need to be updated. From this perspective, this solution may appear to have similar performance to having multiple set keys. The difference lies in the CU, since the CU distributing MBS traffic to all DUs must protect the MBS traffic with as many group keys as the DUs it handles. With the solution proposed in this invention, each DU will have its own set key that is used to verify and decrypt the distribution of the group key that protects the MBS data. The CU only needs to encrypt the MBS data once using the group key shared by all DUs under its control. When distributing this data, the CU must include, next to the protected MBS traffic, a protected group key that is protected with each of the set keys assigned to each of the DUs under its control.

[0100] Example 3: Maintaining synchronization A UE that is part of a group may miss a key group update. If this happens, the UE may not be able to decrypt the delivered content. To avoid this situation, the currently used key group is distributed periodically in a proactive manner, especially shortly after a key update has been performed.

[0101] Another important aspect relates to how freshness is guaranteed. The way to ensure it is by using time, e.g., UTC time, in the construction of the initialization vector (IV) used in the AE. If a counter is used in IV construction, the IV should be set to an initial value when a new group key is distributed, and it should always increase. A UE should not accept a message with an IV older than the IV it currently has. Because the transport key is shared among all devices, an attacker could also try to inject fake traffic. For this purpose, an attacker must use an IV with a higher value. UEs should not accept messages whose IV is much higher than they currently have, e.g., equivalent to several seconds or minutes of data transmission. If the IV is constructed by using a UTC-based counter, a UE should not accept a message containing an IV that differs from the current time by more than a small time window.

[0102] Embodiment 4: Ensuring source authentication during group key updates A problem encountered in systems such as those described so far is that the group key is updated using several set keys (as described in embodiment 1). This problem also appears in [3], since the MTK is updated using the MSK. After the set key (and the MSK in [3]), an attacker can try to "fake" the group key update. This can lead to a situation where a set of devices obtains an incorrect group key. The immediate impact is that they will not be able to decrypt received content, and the message authentication code will fail. Furthermore, if an attacker manages to inject fake content protected using a previously injected fake group key, the UEs in that set of devices will accept the fake content.

[0103] We propose two ways to deal with this problem.

[0104] Method 1: To solve this problem in these systems and in [3], the network can construct an authentication footprint for group key updates. This footprint is constructed by 1) randomly deriving a new group key K (this key is, for example, 256 bits long), and 2) obtaining a hash (for example, SHA2 or SHA3) of K, i.e., R = HASH(K). When the network broadcasts the key update by distributing the new group key protected with M set keys (step h in Figure 10), the network also appends R to the message.

[0105] Upon receiving this group key update message, the UE will: a) The UE looks for the part of the message containing its group key update that has been protected (encryption / integrity) with its set key. The UE checks the message authentication code, the UE checks the freshness of the update message, and if both conditions succeed, the UE decrypts the new group key. b) The UE checks whether the hash of the received value R is equal to the decrypted group key.

[0106] In the attack described above, a node in the set of nodes successfully checks all two of the above conditions a) and b). However, since the information is sent over a broadcast channel, all devices receive this message and devices in the other sets do not successfully verify condition b). Therefore, those devices in the other sets of devices may indicate an inconsistency and trigger an alarm towards the core network containing the received message. The network can verify which of the sets are affected / under attack by checking which of the group key updates are incorrect.

[0107] Method 2: In the context of current research to tackle fake base stations, several solutions using digital signatures have been discussed. One of them is the Digital Signing Network Function (DSnF). DSnF is a function that can be used to sign SI, but it can also be used to sign other information. For example, group key updates. In this case, message h in Figure 10 would also be signed by the DSnF. For this purpose, the network entity generating this message needs to first send a request to the DSnF to obtain the signature of the message. This signature is then appended to the group key update. If this is done so, 1) The MAC verification using that set key is correct 2) (Similar to the third embodiment) The freshness check using a counter is correct. 3) The digital signature was successfully verified The UE will only accept the decrypted key update if

[0108] Note that if the group key generation and distribution is done within the RAN (as in solution #1 in [2]), the base stations can add the signature. This may require them to first send a request to the DSnF, or alternatively, use their own public / private key pair if they possess it.

[0109] Furthermore, in view of the previous embodiments and variants of the present invention, we propose to adapt the process described in TR33.850 as follows.

[0110] 2 Detailed proposal KI#2 of TR33.850 requires 5GS to support confidentiality, integrity, and anti-replay protection of MBS traffic. KI#3 of TR23.757 also requires studying "How can a UE subscribe / unsubscribe to multicast communication services (including whether access is permitted or disabled)?"

[0111] Putting both major issues into context, risks and threats that may be encountered include: The content keys used to protect 5MBS traffic are used for a long period of time. When a device in a group leaves, it should be prevented from receiving new content. · Once a device is subscribed, it should be prevented from having access to old content. If a device in the group is malicious, it should be prevented from injecting fake content.

[0112] The above dangers and threats require: 1. Adapting existing key problems or creating new ones that require 5GS to address updating keys used to protect multicast content. 2. An efficient solution for distributing and updating keys used to protect content so that these keys can be distributed and updated in an efficient manner.

[0113] We have asked SA3 to consider including two additional changes in TR33.850. The first change establishes requirements regarding key rollover needs. The second modification describes an efficient and resilient method for key distribution and update. For illustration purposes, this is in the context of existing solution #2.

[0114] ****Start of Change 1**** Key Problem #3: Securing Key Distribution 5.3.1 Main issue details MBS introduces the concept of point-to-multipoint service to the 3GPP system. MBS traffic is distributed from an application service provider to multiple UEs through 5GS. To securely transmit data to a given set of users, the MBS traffic needs to be protected to mitigate potential attacks. As a basic principle of security, a key for protecting MBS traffic is required. Compared with the UE key, the key for protecting MBS traffic is a one-to-many key. When a UE joins an MBS session, only authorized users can receive the key distributed from the key generator for protecting MBS traffic. The UE can also leave or be compromised from the MBS session.

[0115] 5.3.2 Security Threats If the keys for securing MBS traffic are not confidentially protected, attackers can use the 3GPP network to gain "free access" to MBS services.

[0116] If the keys for protecting the MBS traffic are not integrity or anti-replay protected, authorized users may not be able to properly collect the MBS traffic.

[0117] If it is not possible to update the keys that protect MBS traffic, If a device in the group leaves, it may be able to access the content; When a device joins a group, it may be able to access previous content; If a device in the group is malicious, it may be able to inject fake content.

[0118] 5.3.3 Potential Security Requirements The distribution of keys for protection of MBS traffic between the key generator and the UE shall be confidentiality, integrity and anti-replay protected.

[0119] 5GS shall be able to update the keys for protecting MBS traffic. ****END OF CHANGE 1****

[0120] ****Start of Change 2**** Solution #2: Protecting MBS traffic at the service layer 6.2.1 Solution Overview This solution addresses key issues 2 & 3 to support secure MBS traffic delivery from a context provider to multiple UEs over 5GS. In Baseline Architecture 2 of TR23.757 [2], the MBSU (Multicast / Broadcast Service User Plane) is defined as a new entity to process the payload portion responsible for service level functions and management. Similarly, the MSF User Plane (MSF-U) in Baseline Architecture 1 is also defined in the service layer. This solution protects MBS traffic between the MBSU / MSF-U and the UE in the operator domain, which is independent of protection at the application layer from the content provider.

[0121] Keys for protecting MBS traffic are generated in the SMF. Then, the keys are distributed to the UEs and the MBSU / MSF-U, respectively. UEs belonging to a multicast group acquire the same keys in the MBSU / MSF-U. Keys can be updated in an efficient manner.

[0122] 6.2.2 Solution Details Replacement of Figure 6.2.2-1: Procedure for protecting MBS traffic at the service layer, as shown in Figure 16 The procedure is explained as follows: 1. The UE registers with 5GS and establishes a PDU session. 2. The content provider advertises the availability of multicast using a higher layer (eg, application layer). 3. The UE sends a PDU Session Modification Request. Information about the multicast group shall be sent, including the identifier of the multicast group that the UE wants to join. Multicast_group_ID can be a multicast address or other identifier. 4. The AMF calls Nsmf_PDUSession_UpdateSMContext, which contains information about the multicast group. Editor's Note: If SA2 agrees to support UE multicast session join / leave behavior over UP, e.g., IGMP join / leave, steps 3 & 4 need to be modified. 5. If the MBS context is not available in the (MB)-SMF, the (MB)-SMF interacts with the UDM to check whether a multicast context for the multicast group exists in the system. 6. To create a multicast context in the RAN if one does not already exist, the (MB)-SMF requests the AMF to convey a message to the RAN node using the Namf_N1N2MessageTransfer service. The IP address of the MBSU / MBS-U may be included if needed for the UE to find the MBSU / MBS-U. 7. An N2 session modification request is sent to the RAN. 8. The RAN sends an RRC reconfiguration request message to the UE. 9. If the UE is authorized to access the MBS service, the UE derives a Multicast User Key (MUK) from Kasuf, with Multicast_group_ID used as an input parameter. Editor's note: The derivation of MUK is FFS. Editorial Note: The key update procedure after reauthentication is FFS. 10. The SMF requests a MUK and sends the Multicast_group_ID to the AUSF. 11. AUSF derives a Multicast User Key (MUK) based on Kasuf and Multicast_group_ID. 12. AUSF responds to SMF with MUK. 13.SMF distributes MUK to MBSU / MSF-U. 14. The MBSU / MSF-U receives and stores the MUK, then sends an ACK response to the SMF. 15. Continue with the multicast service initiation procedure. 16. The MBSU / MSF-U checks whether an MBS security context for this multicast group is available. The MBS security context used for MBS traffic protection includes key_ID, K_group_enc, K_group_int, an encryption algorithm, and an integrity algorithm. The key_ID is used to indicate which key pair is used. K_group_enc and K_group_int are used for encryption and integrity protection of MBS traffic, respectively. If not, the MBSU / MSF-U generates K_group and derives K_group_enc and K_group_int. The encryption algorithm and integrity algorithm are selected. 17. The UE calculates a token based on the MUK and requests a traffic key from the MBSU / MSF-U. Editor's note: Token structure is FFS. 18. The MBSU / MSF-U verifies the token using the MUK and, if successful, distributes the MBS security context to the UE. Editor's Note: Message names and flows may be updated to align with conclusions from SA2 and the RAN WG. Editor's note: Roaming behavior is FFS.

[0123] 6.2.2.1 MBS Security Content for Efficient Group Key Distribution and Update This section explains the logic of step 18 in Figure 6.2.2.1.

[0124] A multicast group with N members is divided into M sets S_i, i={1, M}. Each set has approximately L~N / M UEs. Each UE has three keys: a device-specific key MUK, a transport key K_transport_i shared with the other L-1 devices in the same set, and a group key shared with all N devices and used to protect the multicast content. The MUK is used to securely distribute the transport key in a point-to-point connection. The transport key is used to securely distribute the group key in a multicast manner. The key hierarchy is as follows, with arrows indicating protection: MUK->K_transport_i->K_group

[0125] E{K1, K2} denotes the authenticated encryption of key K2 with key K1 and is used to indicate the secure distribution of the keys.

[0126] Group key distribution and updating is done through two messages. Message 18a: The UE receives a key transport for the set to which it belongs, protected using the UE's MUK. The UE first verifies the message authentication code, and if it is correct, the UE decrypts its transport key. Freshness can be achieved in several ways. For example, an increasing initialization vector can be used that depends on the initial access token exchanged in step 17. Message 18b: The new group key is distributed by protecting it with the transport key in a point-to-point or multicast message. A hash of the group key is included.

[0127] The UE first looks for the part of the message addressed to its set. For example, if the UE belongs to set z, the UE needs to look for E{K_transport_z, K_group}. The UE then verifies the message authentication code, and if it is correct, the UE decrypts the new group key. Freshness can be achieved by using the same freshness counter as used for distributing the content data. Finally, the UE also checks whether the hash of the decrypted key is equal to the hash of the group key, H, appended to the end of this message.

[0128] These two messages can be combined to handle different situations. 1. Initial key distribution to the UE: The UE is given its transport and group keys in the same message that combines 18a and 18b. 2. Key update triggered by very long usage of key group: Message 18b is used to distribute a new group key to all UEs. 3. Key update triggered by a new device joining the group: Message 18a is used to deliver the corresponding transport key to the new UE, and message 18b is then used to distribute the new group key to all UEs. 4. Key update triggered by UE leaving / disabled: When a UE leaves or is disabled, its transport and group keys associated with its set are compromised. To handle this situation, message 18a is sent to the L-1 UEs in the set to update the transport keys. Message 18b is then used to distribute the new group key to all UEs.

[0129] This approach is efficient and resilient as follows: Group key updates due to a device leaving require only L-1+M messages instead of the N required when only point-to-point messages are involved. For example, if N=1600, M=40, and L=40, then key updates require only 39 point-to-point messages for the transport key update and 40 messages for the group key update. Because M transport keys are used, an attacker who compromises a UE can only attempt to update the group keys of up to L-1 devices. This limits the impact of such an attack, especially compared to a situation where a single key is used to transport the group key, where N-1 devices would be affected. Furthermore, a hash of the group key is included in message 18b so that devices in other sets can check consistency, detect the attack, and notify the 5MBS. In this sense, the solution is M-resilient.

[0130] The following is an editorial note in TR33.850-040, Solution 2 regarding UE recertification: The process during UE recertification is as follows: Step 0: The UE starts the re-authentication process and proceeds to step 1. Step 1: During the re-authentication process: Step 1.1: The UE attempts to process the incoming protected MBS traffic by using its known group key. If that is successful, the UE proceeds to step 2. Step 1.2: If the UE is unable to process the incoming protected MBS traffic, it attempts to access a new group key, which is distributed at regular intervals in message 18b, by using its previous transport key. If the UE is successful, it accesses the new group key and proceeds to step 2. Step 1.3: The UE waits for the delivery of the new transport and group keys. These two keys are delivered by messages 18a and 18b. These keys are delivered only if the re-authentication and re-authorization process is successful and are protected using the MUK. If the UE receives them, it proceeds to step 3, otherwise it proceeds to step 2. Step 2: The UE is not authenticated or authorized to access the MBS traffic. Step 3: The UE has the current group key and transport key and can access the protected MBS traffic and any group key updates.

[0131] Note that step 1.2 requires that the new group key update, which is protected with the set (transport) key, is not protected with the old group key. Note that it is advantageous not to do so when wanting to optimize the key update process during UE re-authentication.

[0132] Note that the above process is optimized to improve user experience, since the UE can attempt to access MBS traffic even before it is re-authenticated by attempting to use the group and transport keys that it already has. This is what is done in steps 1.1 and 1.2. If these keys work, the UE can directly access the traffic. If these keys do not work, it can be due to two reasons. The first reason is that the keys have been updated by a normal key update, or another UE has left the multicast group. The second reason is that the UE itself is no longer authorized and is forbidden to access MBS traffic.

[0133] Note that if a transport key is not used, step 1.2 above should be skipped and only step 1.3 includes message 18a.

[0134] The key hierarchy described in the above embodiment uses M different transport keys (K_transport_i) used to update the group key. This approach therefore reduces the number of unicast messages / point-to-point interactions needed to update the transport key from N to N / M. The group key can then be updated by sending a new group key protected with the M different transport keys. This approach strongly reduces signaling overhead when UEs frequently leave or join the MBS group and security applies that necessitates group key updates in those cases. The reason for this is that if there is only a single transport key (as in LTE), the transport key needs to be updated, which requires N unicast interactions. Once the transport key is updated, for example, a group key protected with the new transport key can be distributed. In contrast, having M transport keys means that N / M-1 unicast messages are needed to update a compromised key and M protected group keys need to be distributed over the multicast channel, thus a total of N / M-1+M keys need to be sent. This is approximately equal to 2*SQRT(N) when M is approximately SQRT(N). A problem can arise in settings where the members of an MBMS group are fairly static (they do not leave or join) and policies are applied that require very frequent rotation of the group key. In such settings, the approach proposed above in the context of Sol#2 of TR33.850 may have higher overhead because multiple transport keys are used to protect new group keys. To address this issue, it is possible to apply a slightly more complex key hierarchy, which can be seen as a combination of the key hierarchy in MBMS (LTE solution) and the key hierarchy proposed above. In this new key hierarchy, there are M+1 transport keys. · M transport "set" keys (K_transport_i) as described above, i.e., each of these transport keys is used by a disjoint set of L=N / M UEs. One transport "common" key (K_transport_common) that is common to all UEs.

[0135] In this setting, If MBS group UE membership remains static and the group key needs to be rotated frequently, a transport "common" key is used to securely distribute new group keys. This is secure because UE membership does not change, and therefore all M+1 transport keys remain valid. This is efficient because a single key is used to securely send updated group keys. MBS group UE membership is dynamic, in that when a UE leaves or joins, L-1 unicast messages are used to update the "compromised" transport "set" key. Recall that these L-1 messages are protected using a MUK key that is UE-specific. A new group key as well as a new transport "common" key are then updated by sending those two keys protected with the M transport "set" keys over a multicast channel. Alternatively, a new transport "common" key is updated by protecting it with the M transport "set" keys over a multicast channel, and the new transport "common" key is then used to update the new group key, also over a multicast channel.

[0136] Figure 15 describes the relevant key hierarchies. The first key hierarchy is the one used in LTE and in Solution 12 of R33.850. Here, each UE has a MUK that is used to securely receive MSKs over a unicast channel. The MSK is common to all UEs and can be used to distribute MTKs, i.e., group keys, to all UEs over a multicast channel. The second key hierarchy (Key Hierarchy A) relates to the default solution described above when no transport keys are used. The key hierarchy uses a UE-specific unique key to directly update the MTK. The third key hierarchy (Key Hierarchy B) has multiple M MTKs associated with disjoint sets of up to L UEs. A UE uses a device-specific MUK to securely receive its MSK. All M MSKs are then used to distribute the MTK. The fourth key hierarchy (key hierarchy C) is the key hierarchy described above in which there are M MSKs (transport "set" keys), each bound to a disjoint set of up to L UEs, and one MSK (transport "common" key) that is common to all UEs. The key hierarchy in Figure 15 is applicable, for example, to Sol#12 of TR33.850 or other service layer solutions in that 3GPP work.

[0137] The entities protecting MBS traffic, e.g., NFs or several NFs interacting with each other, may have a key hierarchy and a policy responsible for determining how frequently the keys should be updated. Regular rekeying of group keys, including for example frequency or maximum usage. Regular re-keying of transport "symmetric" keys, including for example frequency or maximum usage. · Transport "set" key updates when a UE leaves or joins. Update of transport "common" keys and / or group keys when a UE leaves or joins It will be managed under these circumstances.

[0138] In TR33.850, authentication and authorization are within the scope of Key Problem #1. Protection of MBS traffic is within the scope of Key Problem #3. In the above solutions, the process for re-authentication depends only on the implementation of Solution 2, but (re)authentication is handled as part of a different solution. For example, in TR33.850-040, Solution 6 performs authentication and authorization for multicast communication services. Solution 6 does so based on K_AKMA. In particular, key K_MBS is derived from K_AKMA and used for authentication and authorization. In other solutions, e.g., Solution 2, device keys MUK are used for group key distribution. In this case, MUK is derived from K_ausf. The next issue addressed is how to bring together solutions in TR33.850 that address different key issues (e.g., KI#1 and KI#3) but ultimately need to work together.

[0139] To address this issue, the keys for authentication / authorization and the keys used for distributing key updates need to be accounted for in a related key hierarchy. In one embodiment that addresses this issue, this is done as follows:

[0140] [Table 3]

[0141] K_AKMA is derived from K_AUSF as described in 3GPP TS33.535 16.0.0 Release 16. K_AKMA is then used to derive a master K_MBS key for the UE and a given MBS service. Two keys are derived from this K_MBS key. The first key, K_MBS_Authentication_Authorization, is used for the authentication and authorization procedure, for example, in Solution 6 of TR33.850. This means that in Solution 6, an additional key derivation step has disappeared from K_MBS. The second key, K_MUK, is used in distributing the group key used to protect multicast traffic. This K_MUK appears, for example, in Solution 2, which means that Solution 2 should be modified to derive K_MUK from K_MBS and K_AKMA instead of deriving it directly from K_AUSF. Note that when deriving some of the above keys, e.g., K_MUK, a counter c can be used as input to a key derivation function to obtain multiple K_MUKs within the current authentication and authorization session.

[0142] An alternative to the above key hierarchy is the following:

[0143] [Table 4]

[0144] The difference here is that K_MUK (used in Solution 2) is derived from K_MBS (used in Solution 6). In particular, K_MUK can be derived from K_MBS, information exchanged during the authentication and authorization process, and a counter c. The counter allows for the derivation of multiple K_MUKs in case keys need to be rotated within the current authentication and authorization session.

[0145] Note that the above key hierarchy does not describe whether K_MUK should change if the UE re-authenticates. Triggering an update of K_MUK in case of re-authentication is optional. This can be done by the counter c described above.

[0146] Note that in the case of UE re-authentication, as in Solution 2, even if the key hierarchy K_AUSF → MUK is maintained, the MUK may also need to be changed. The main reason is that re-authentication may trigger an update of K_AUSF itself. TS33.501-A.2 describes the process for K_AUSF generation, which depends, for example, on the serving network name. If this happens, keeping the same MUK may cause synchronization issues, as proposed in Proposal S3-210919 submitted to 3GPP® SA3 #102-e-Bis. For example, assume that a UE subscribes to an MBS service by authenticating and generating a first MUK key. The UE is then idle for a long time. Later, the UE re-subscribes, triggering its re-authentication. However, assume that either the UE or the core network may have deleted the old MUK, for example, because the UE has been idle for a long time. If only one of the parties deleted the old MUK, that party generates a new MUK. However, if K_AUSF changes due to a re-authentication process, e.g., if the UE joins through a different serving network, the new MUK will not match the old MUK. In general, and independently of solution 2, the device keys used to distribute transport or group keys should be updated after (re-)authentication.

[0147] Next to the K_MUK, if the UE uses a solution that uses set keys (or transport keys), the corresponding set keys may also need to be updated. The same may be true for group keys used to secure MBS traffic. However, doing so may incur high signaling overhead. In general, a better approach is to keep (i) the keys used for authentication / authorization and distribution of set keys / group keys and (ii) the set keys and MBS group keys independent. In particular, the set keys and MBS group keys may need to be updated only if the UE re-authentication process fails.

[0148] The solution presented here can be considered an in-band key update mechanism. However, some solutions split the control plane and the user plane. The control plane is used for the distribution of key group updates, while the user plane is responsible for the distribution of multicast traffic. This split appears, for example, in Solution 8 of TR33.850-040. In this solution, the (MB)-SMF solution is responsible for generating a group key (MTK) and a corresponding key identifier (KID). This key and identifier are later shared with the MBSF-U in the core network. This key and identifier are later shared with the UE through a control channel. The content provider delivers multicast data to the MBSF-U, which is responsible for distributing the multicast data via the user plane to all UEs connected to the service. This is done by protecting the multicast data using the group key.

[0149] In the case of a key update, all N UEs subscribed to the service need to get the key update. As explained throughout this document, this can involve a lot of communication resources, since not only does every single UE need to be notified, but every single UE should also confirm proper receipt of the key update.

[0150] The ideas in this embodiment can be applied to improve this solution with also splitting the user plane and the control MBS plane. When the group key is scheduled, the following is done: Step 1: (MB-)SMF generates a new group key. In step 2, if the UE leaves the MBS, is revoked, etc., the (MB-)SMF also generates a new set key corresponding to the set of devices to which the UE belonged. The (MB-)SMF distributes the new set key, which is used to securely transport the new group key, to the (M-1) devices in the set via the control plane. This message is equivalent to message 18a in solution 2 of TR33.850. Step 3: The (MB-)SMF shares with the MBSF-U (as in the current description) the new group key and a key update message in which the new key group is protected with the L set keys. This is equivalent to message 18b in solution 2 in TR33.850. Step 4: Once the MBSF-U receives this key update, it distributes the key update, i.e., the new group key protected with the L set keys (equivalent to message 18b in solution 2 of TR33.850), by first sending this information in-band together with the normal multicast content. This information is therefore protected with the current group key. This can be done multiple times to ensure that UEs receive this key update. Step 5: The MBSF-U can switch to using the new group key.

[0151] In an extension of the above procedure, when the UE gets the key update message in step 4, it may also notify the (MB-)SMF of the receipt of such key update. In this extension, the (MB-)SMF waits until the majority of UEs confirm the receipt of the key update or until a timer times out, and then notifies the MBSF-U about this event which triggers a group key switch (step 5 above).

[0152] If the previous extensions are applied, step 3 may consist of only a key update message and the distribution of the new group key may be delayed until the moment when the (MB-)SMF notifies the MBSF-U that the majority of UEs have received the key update.

[0153] If the previous extension applies, "the majority of the UEs" means a given percentage of N UEs that are subscribed to the MBS service, for example 99% of the UEs. For the remaining UEs, the (MB-)SMF may choose a direct connection through the control channel. Similarly, "the timer times out" means that the MBSF-U has been distributing the key update message for a sufficiently long period of time and that UEs that have not acknowledged receipt of the message should be contacted directly through the control channel.

[0154] Note that this division applies to the distribution of the set key (or transport key) distributed over the control channel and the distribution of the group key distributed in-band over the user plane. This can be done for any parameters (N, M, L) in this solution, and in particular it can be done when there is a single set / transport key.

[0155] In SA3#102-e-Bis, proposal S3-210857 provides a framework for secure key distribution. This framework defines the inputs and outputs to two key derivation functions that generate two broadcast keys, KMTentt and KMTint, for encryption and integrity protection. The inputs to each KDF include 1) a re-keying token, 2) a multicast group token, 3) an algorithm identifier, and 4) a temporary mobile group identifier (TMGI). The network provides 2) and 4) to the UE in a secure manner, specifically via a secure RRC message. The UE and RAN can then generate the same KMTentt and KMTint. When re-keying is required, the network can provide the UE with the re-keying token so that both the UE and RAN can generate new multicast keys KMTentt and KMTint. Note that in this solution, element 2) the multicast group token plays the role of the master multicast key. This parameter should therefore be generated in a secure manner and be of sufficient length. This proposal S3-210857 can also benefit from the methods described in this application to reduce the amount of signaling messages. In particular, if a new multicast key needs to be generated by the UE, this proposal S3-210857 requires the transmission of N secure messages containing a new re-keying token to each and every UE. The re-keying token does not require confidentiality protection, but it does require integrity protection. Instead of sending N integrity-protected messages, the N UEs can be divided into M=N / L sets of devices. Each set of devices has a different set or transport key. These transport keys are used for the delivery of the above elements when needed for the set of devices that remained unchanged. This delivery is done in a multicast manner. If the set of devices changes (new UEs join / leave), new transport keys and any of the above elements can be delivered by RRC-protected messages.

[0156] Note that in this solution, when a UE leaves a group, the leaving UE knows the multicast group token, which serves as the master key. A way to apply the method described herein to this solution is to use a different re-keying token for each base station. If different re-keying tokens are used (i.e., the re-keying material is base station specific), only the re-keying token for the base station from which the UE left needs to be updated. Otherwise, if the same re-keying token was used at all base stations, a UE leaving an MBS group when located at a particular base station would force 5GS to update all UEs at all base stations. This is inefficient and involves more signaling overhead.

[0157] In this particular solution (as well as S3-210857 and other solutions where the MBS encryption and integrity keys are updated over the control channel), when a re-keying token is sent to the UE through multiple RRC messages, new K_MT_enc and K_MT_int should be used. There may be a time interval during which the old and new K_MT_enc and K_MT_int keys may need to be active. When the base station begins using new MBS encryption and integrity keys, the base station (or the entity protecting and transmitting MBS traffic) may indicate this key switch to the UE by including MBS encryption and integrity key identifiers in the multicast data (user plane). Alternatively, the base station may use and flip a single bit in the multicast data channel to indicate the switch from the old key to the new key.

[0158] Note that proposal S3-210857 has two design flaws because it states that the RRC messages are encrypted in message 8 in Figure 6.X.2.2-1 and message 7 in Figure 6.X.2.3-1. The proposal does not mention integrity protection. In the case of message 8, encryption is required for the distribution of element 2). However, integrity protection is also essential, as otherwise it would be possible to modify the message and deny service to the UE. In the case of message 7, the requirements are also integrity protection and freshness. If element 1) is a counter, the counter can be public, but the receiving party needs to be able to verify its integrity and freshness.

[0159] Note that in this proposal S3-210857, if 1) is a counter, the UE only needs to update its counter, so a disabled UE may still be able to access MBS traffic even if the counter changes. Therefore, the re-keying token must be sufficiently long (e.g., 128 bits or longer) and must be randomly generated. A shorter re-keying token (e.g., 32 or 64 bits) is not sufficient because an attacker can pre-calculate the key in advance and pick up the correct key when the re-keying token is distributed. An attacker may also be able to record traffic and decrypt it at a later point in time.

[0160] In SA3#102-e-Bis, proposal S3-211144 provides another solution for MBS key generation. This solution is similar to S3-210857 because instead of distributing new keys on demand, MBS encryption and integrity keys are derived from a master key from several parameters, including a counter and a random value. As in S3-210857, this solution can also benefit from the methods described in this application to reduce the amount of signaling messages. For example, a set of keys can correspond to a UE receiving MBS services through a specific base station. Devices in the same set share a set key or transport key. When the MBS encryption and integrity keys (KMRB-int and KMRB-enc in Figure 6.X.2.1-1 of S3-211144) need to be updated in all UEs at the base station, the base station distributes the parameters needed to update KMRB-int and KMRB-enc, such as RANDMBS and CountMBS, through the multicast channel MRB(PTM). These parameters are protected using the corresponding transport keys.

[0161] Next to this, note that S3-211144 assumes a key hierarchy where KMBS is a master key distributed to the RAN, from which gNB-specific keys are generated as follows: KMBS-RAN=KDF{KMBS, TMGI, RANDMBS, CountMBS, PCI, ARFCN-DL}

[0162] The use of PCI and ARFCN-DL binds keys to a specific RAN cell. However, this also has a major drawback: when a UE leaves or is revoked from an MBS group, keys in all base stations delivering MBS traffic need to be updated. This leads to a large signaling overhead, since the same master key is used for all base stations delivering a given MBS service. This can be improved in several ways, in this case as well as in other systems. Each base station randomly generates a different gNB-specific key, KMBS-RAN. The key hierarchy includes an intermediate level related to the tracking area, e.g., between RAN and KMBS. This intermediate key, KMBS-TA, is specific to the tracking area and aims to reduce the impact of key updates. Instead of receiving KMBS, the UE only receives the gNB-specific key KMBS-RAN or an intermediate key, e.g., KMBS-TA in messages 5 and 11 in Figure 6.a.2.1-1 of S3-211144.

[0163] It should be noted that if the UE does not have access to the master MBS key, the mobility (handover) procedure should be modified so that the UE is informed of the target MBS RAN key or the target MBS TA key.

[0164] (i)K MBS-RAN is a KDF {K MBS , TMGI, RAND MBS , Count MBS , PCI, ARFCN-DL}, (ii)K MBS-RAN relies only on RANDMBS in terms of security when a UE leaves the group, (iii) K of gNBs with departing / disabled UEs MBS-RAN Note that K_MBS is not required, since only K needs to be updated. The same applies to the multicast group token in proposal S3-210857.

[0165] moreover, 1. This solution is essentially a RAND as in equation (0) from which K_MRB-int and K_MRB-enc are derived, as explained by (1), (2), and (3). MBS This is equivalent to a solution that securely distributes the RAN keys directly to the UE. RRC(RAND MBS , TMGI, CountMBS , PCI, ARFCN-DL)(0) In this approach, the UE determines all other parameters individually, i.e., TMGI, Count MBS , PCI, ARFCN-DL is received and inspected. Alternatively, K MBS-RAN can also be distributed directly. 2. A similar solution can be obtained if we calculate the parameters as follows: K MBS-RAN =KDF{TMGI, RAND MBS , CountMBS, PCI, ARFCN-DL}(1) K MRB-enc =KDF{K MBS-RAN , algorithm type distinguisher value, algorithm identifier value}(2) K MRB-int =KDF{K MBS-RAN , algorithm type identification prime value, algorithm identifier value}(3) In (1), K_MBS is removed, since security does not depend on K_MBS, compared to the current text in S3-211144. 3. Another alternative solution is to skip the KDF operation and use K as in (4) and (5). MRB-enc and K. MRB-int can be calculated. K MRB-enc =KDF{TMGI, RAND MBS , Count MBS ,PCI,ARFCN-DL,K MBS-RAN , algorithm type identification prime value, algorithm identifier value}(4) K MRB-int =KDF{TMGI, RAND MBS , Count MBS ,PCI,ARFCN-DL,K MBS-RAN , algorithm type identification prime value, algorithm identifier value}(5) Here, all parameters are distributed to the UE by message (0).

[0166] In (1), (4), and (5), the PCI can be removed since the message is distributed in the RRC message coming from that particular base station.

[0167] In SA3#102-e-Bis, proposal S3-210918 provides another solution for MBS key generation, somewhat similar to solution 8 in TR33.850. In this new solution, the MBSF-C generates a new group key (MTK2) that is distributed to the MBSF-U and (MB)-SMF. The (MB)-SMF is responsible for distributing this new key to the UEs via unicast signaling messages. Once this is done, the (MB)-SMF notifies the MBSF-U. After this notification, the MBSF-U starts using this key MTK2 to protect MBS data. This solution may benefit the described embodiments in order to reduce signaling overhead. In particular, the MBSF-C or the (MB)-SMF may distribute the UEs into sets, each linked to a respective transport key. The new group key MTK2 can thus be distributed to UEs protected with this transport key via multicast streams, still protected with the old MTK2 key. Once the UE receives the update, it notifies the (MB)-SMF, which will keep track of all UEs that are aware of the new key. For UEs that did not respond, the (MB)-SMF may use the unicast key update modification proposed in S3-210918. Once the (MB)-SMF is assured that the majority of UEs registered for MBS traffic have received the new MTK2 key, it sends an MTK activation notification to the MBSF-U.

[0168] Note that proposal S3-210918 assumes a unidirectional link, the key update notification, going from the (MB)-SMF to the UE in step 6. This may not be sufficient, since the UE may miss the signaling message, which may cause an interruption in the reception of MBS data. Note that the current proposal may require a policy in the (MB)-SMF that describes how to handle the situation when a certain percentage of UEs do not acknowledge receipt of the key update notification message. In particular, this policy may include the relative or absolute number of UEs that may not acknowledge receipt of the MTK activation notification message before it is sent to the MBSF-U. This policy may also include a timer that, upon expiration, triggers the sending of this notification. This policy may also define how UEs that do not acknowledge the key update notification should be managed, e.g., how many times this message should be sent.

[0169] In SA3#102-e-Bis, proposal S3-211070 provides another solution for generating and distributing MBS keys and MBS traffic. This solution relies on three keys: a MUK (Device Unique Key), an MSK, and an MTK. The MUK is used to distribute the MSK in unicast messages over a secure connection. The MTK is protected by the MSK. The MTK can be distributed in unicast or multicast messages. The MTK, or a key derived from it, is used to protect MBS data. This proposal S3-211070 is similar to the idea disclosed in this application. The main difference is that S3-211070 appears to include a single MSK. S3-211070 can benefit from the idea in this application when UEs in MBS services are divided into M sets, each using a different MSK. For this purpose, distribution of multicast traffic keys is required to include MTKs encrypted using different MSKs. This solution uses a key hierarchy for the derivation of the MUK from the KAF using the AKMA (KAUSF->KAKMA->KMBS(KAF)->MUK), as previously described in this application.

[0170] Each of these units may be implemented by program code means of a computer program and / or as dedicated hardware in the device concerned. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, distributed together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0171] References [1]TR23.757v1.0.0 [2]TR33.850v0.2.0 [3] TS33.246-g00 3 (MBMS Security) [4]https: / / itectec.com / spec / 4-2-key-management-overview /

Claims

1. 1. A method for a primary station to distribute an encryption key to a plurality of secondary stations, the method comprising: a. determining whether a group key needs to be updated, said group key being used for multicast secured communications from said primary station to said plurality of secondary stations; b. when determining that an update is required, transmitting an updated encryption key to at least a subset of the secondary stations via an encrypted message, the updated encryption key being a first set key shared with a first set of secondary stations, the first set key enabling encryption of multicast messages addressed to the first set of secondary stations; A method comprising:

2. 2. The method of claim 1, wherein the updated encryption key is an updated group key, and the encrypted message is encrypted with a user-specific encryption key and sent unicast.

3. 2. The method of claim 1, wherein the step of determining whether the group key needs to be updated includes determining whether at least one of the following is satisfied: at least one of the access rights of the secondary stations has been revoked; at least one of the access rights of the secondary stations has disappeared; a validity period of the group key has expired; or at least one of the secondary stations has moved away from a predetermined location.

4. 2. The method of claim 1, wherein in step a., the first set key is updated when it is determined that the access rights of at least one of the secondary stations belonging to the first set are not currently valid.

5. 5. The method of claim 4, further comprising the step of transmitting the updated group key to each set of secondary stations in a message protected with a respective set key associated with each set of secondary stations. transmitting the updated group key to at least a set of first and second secondary stations by means of a multicast message including at least a first and a second protected group key; 5. The method of claim 4, wherein the first protected group key is protected with a first set of keys associated with the first set of secondary stations, and the second protected group key is protected with a second set of keys associated with the second set of secondary stations.

7. A method as described in claim 5 or 6, wherein the multicast message includes, together with the protected and updated group key, an authentication footprint message that enables the integrity of the decrypted group key to be verified.

8. 4. The method of claim 3, further comprising, if in step a. the determination that the group key is linked to the access rights of a first secondary station belonging to the first set of secondary stations is not valid, sending a new first set key by unicast to each secondary station of the first set through a protected unicast message.

9. 9. The method of claim 8, further comprising the step of: c) transmitting the updated group key to the first set of secondary stations in the multicast message, wherein the multicast message is encrypted with the new first set key.

10. The method of claim 8 , wherein the protected unicast message also includes the updated group key.

11. 11. The method according to claim 9 or 10, wherein the multicast message is retransmitted periodically.

12. 12. The method of claim 9, wherein the multicast message includes the updated group key together with an authentication footprint message computed as a hash of the updated group key.

13. 1. A method for a secondary station receiving an encryption key in a network, the method comprising: a. receiving a first set key by unicast through a protected unicast message from a primary station, said first key being associated with a first set of said secondary station; b. receiving and decrypting an updated group key in a multicast message to the first set of secondary stations, said decrypting using said first set of keys, said updated encryption key being a first set of keys shared with the first set of secondary stations, said first set of keys enabling encryption of multicast messages addressed to the first set of secondary stations; A method comprising:

14. 14. The method of claim 13, wherein the multicast message includes an authentication footprint message along with the protected updated group key, the method further comprising the secondary station authenticating the multicast message by checking whether the hash of the decrypted group key matches the received authentication footprint.

15. A method for establishing a secure group key using a multicast message comprising: transmitting the updated group key to a set of at least first and second secondary stations by means of a multicast message including at least the first and second protected group keys; the first protected group key is protected with a first set of keys associated with the first set of secondary stations, and the second protected group key is protected with a second set of keys associated with the second set of secondary stations; Receiving and decoding the multicast message includes: determining, by said secondary station, the set of secondary stations to which said secondary station belongs; determining, by the secondary station, the protected group key associated with the set of secondary stations to which the secondary station belongs; and decrypting, by the secondary station, the determined protected group key using the set key.

16. 15. The method of claim 14, further comprising reporting an anomaly to the primary station if the check fails.

17. 1. A primary station operating in a cellular network and in communication with a plurality of secondary stations, the primary station comprising: a controller adapted to determine whether a group key needs to be updated, the group key being used for protected multicast communication from the primary station to the plurality of secondary stations; a transmitter coupled to the controller adapted to send an updated encryption key to each set of secondary stations in a respective multicast message when it determines that an update is required, the multicast message being protected by a respective set key associated with each corresponding set, the updated encryption key being a first set key shared with a first set of secondary stations, the first set key enabling the encryption of a multicast message addressed to the first set of secondary stations; A primary station comprising:

18. 1. A secondary station operating in a cellular network and in communication with a primary station, said secondary station comprising: a receiver adapted to receive a first set of keys by unicast from a primary station through a protected unicast message, the first keys being associated with a first set of secondary stations; a controller adapted to decrypt an updated encryption key in a multicast message to the first set of secondary stations, wherein the decryption uses the first set of keys, the updated encryption key being a first set of keys shared with the first set of secondary stations, and the first set of keys enabling the encryption of a multicast message addressed to the first set of secondary stations; A secondary station equipped with:

19. A computer program for causing a computer to execute each step of the method described in any one of claims 1 to 16.

Images