CN116830533A - Method and apparatus for distributing multicast encryption keys - Google Patents

Abstract

The present invention relates to a method for a primary station to distribute encryption keys to a plurality of secondary stations. The method comprises the following steps: determining whether a group key is required to be updated, the group key being used for multicasting an encrypted communication from the primary station to the plurality of secondary stations, upon determining that an update is required, transmitting a first set key by unicast to at least a first subset of the secondary stations via an encrypted unicast message, transmitting an updated group key to a first set of secondary stations in a multicast message encrypted via the first set key, or alternatively including the updated group key in an encrypted unicast message carrying a first step key, transmitting an updated group key to a further respective set of secondary stations in a respective multicast message encrypted via a respective set key associated with each respective set.

Description

Method and apparatus for distributing multicast encryption keys

Technical Field

The present invention relates to the field of wireless communications, and in particular to the security aspect 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). Other entities (e.g., security entities) may exist in such networks.

Background

In a wireless network, terminals connect to the network to exchange data. Security is particularly important for wireless devices that do not require physical interaction to access the network. Furthermore, encryption allows controlling access to resources such as multimedia streams. Thus, the wireless network must implement some measures to enable the exclusion of unauthorized devices in the network. 3GPP is an organization responsible for standardization of global solutions for mobile telecommunication systems. Telecommunication systems developed in 3GPP partnerships are no exception. In particular in 5G, security measures are being discussed to enhance the security of the network.

A 5G multicast broadcast service (5 MBS) allows subscribers to access data streams, in particular multimedia data streams. Typical applications are streaming video and further information, e.g. replaying video or additional information or enhancing performance, during live activities, e.g. live activities in a stadium (sports, concerts). An important aspect is to ensure that all subscribers and only subscribers can access the service. Thus, the stream is encrypted by a group encryption key shared between the terminals of all users.

However, different problems are found with the currently proposed solutions. As part of the background, the summary is as follows:

Background 1: 5MBS communication architecture for 5G r17

Background 2:5MBS current safety key problem and solution

Background 3: MBMS security architecture for 5g r 16.

Background 1: 5MBS communication architecture for 5G r17

TR 23.757v1.0.1 (hereinafter referred to as [1 ]]) Architecture enhancement studies for 5G multicast broadcast services (simply 5 MBS) of 5G (release 17) are described. In [1 ]]In section 4, architectural assumptions and principles are described,the following text adaptationFrom section 4:

first, 5MBS applies the following general architecture requirements and principles:

the solution should be built on top of the 5G system architecture principle in TS 23.501 (hereinafter [2 ]), including flexibility and modularity for newly introduced functions.

The system should provide efficient transmission for various multicast and broadcast services.

The solution should minimize the impact on existing external services.

The architecture reference model defined in clause 4.2 of TS 23.501 < 2 > is used as a baseline architecture for supporting multicast and broadcast services in the present study. In particular, FIG. 1 shows an advanced MBS architecture with 5G UE, NG-RAN and 5 GC.

In addition, there are certain specific requirements for Internet Protocol Television (IPTV):

the solution to IPTV should minimize the impact on the IPTV network and the Set Top Box (STB).

The solution to IPTV STB should reuse IGMP/MLD messages via the user plane to join/leave the IPTV channel group.

The solution to IPTV should provide an efficient mechanism for UEs to join/leave the IP channel group, including reduced latency and signaling.

The sequence of establishing and delivering MBS sessions is assumed as follows:

1. 5G MBS service information is optionally delivered from the application/service layer to the 5GC. Note that a framework for delivering 5G MBS service information to a 5G CN (core network) is available. However, this step may be replaced by a pre-agreement without explicit signaling.

The UE participates in receiving MBS streams, i.e. the UE requests to join an MBS session (for multicast session).

3. And establishing MBS stream transmission. Note that this step may occur before step 2 for individual UEs joining an MBS session that has already been started.

4. Delivering MBS data to the UE.

The ue stops receiving MBS streams (for multicast sessions).

6. MBS streaming (which was once session stopped) is released.

MBS services need to be delivered from a single data source (application service provider) to multiple UEs. Depending on many factors, MBS services in 5GS may be delivered using a variety of delivery methods. For clarity, the delivery method is not referred to as unicast/multicast/broadcast, but is as follows.

From the 5G CN point of view, two delivery methods are possible:

-5GC individual MBS service delivery method: the 5G CN receives a single copy of MBS data packets and via per-UE PDUs

The session delivers separate copies of these MBS data packets to the individual UEs.

-5GC sharing MBS service delivery method: the 5G CN receives single copies of MBS data packets and sends the MBS data packets to the mobile station

A single copy of the data packet is delivered to the RAN node, which then delivers the copies to one or more UEs.

If a 5GC individual MBS service delivery method is supported, the CN may deliver the same received single copy of the MBS data packet via the 5GC individual MBS service delivery method for some UEs and via the 5GC shared MBS service delivery method for other UEs.

From the RAN point of view, two delivery methods (in the case of shared delivery) may be used to transmit MBS packet streams over the air:

-point-to-point (PTP) delivery method: the RAN node delivers separate copies of the MBS data packets over the radio to the individual UEs.

-point-to-multipoint (PTM) delivery method: the RAN node delivers a single copy of the MBS data packet over the radio to the set of UEs.

Note here that the RAN node may use a combination of PTP/PTM to deliver MBS packets to the UE. As depicted in fig. 2, for a 5G MBS session, a shared PTP or PTM delivery method and an individual delivery method may be used simultaneously, depending on the solution selected.

In annex a.1 of [1], an alternative to the 5MBS reference architecture is described. In particular, transport layer and service layer aspects are considered. The following are denoted by the names a.1.1 and a.1.2.

A.1.1. Transport layer aspect of the reference architecture:

fig. 3 shows a 5G system architecture for integrating multicast transmission and unicast. This solution relies on enhancing existing 5GS network functions (NG-RAN and UE currently support only unicast transmissions) to support multicast transmissions.

The following new functions are added to the current AF, 5GC NFS (network functions), NG-RAN and UE:

-Application Function (AF):

supporting MBS service functions, negotiating with the NEF for service exposure.

-Network Exposure Function (NEF):

-5G MBS service exposure.

Negotiating 5G MBS services with the AF, including QoS, 5G MBS service areas.

-Policy Control Function (PCF):

support policies for multicast services, including QoS parameters, such as 5QI, MBR, GBR.

-providing policy information on MBS sessions to the SMF.

Receive MBS service information directly (operator owned) from AF or indirectly via NEF.

-Session Management Function (SMF):

-controlling MBS transmissions based on MBS policies received from the PCF.

-configuring User Plane Functions (UPFs) for MBS flows and point-to-point or point-to-multipoint transmissions.

-configuring the RAN for MBS flows and QoS information.

-SM configuration at the UE for MBS flows.

SMF can be used for unicast and MBS.

-User Plane Function (UPF):

support packet filtering of MBS streams and delivery of MBS streams to the RAN via point-to-point or point-to-multipoint N3.

-receiving a 5G MBS stream configuration from the SMF.

Detect Internet Group Management Protocol (IGMP) packets and notify the SMF (if UE joining is performed via IGMP).

UPF may receive both unicast and MBS streams.

-I-UPF may be used to deliver MBS streams from UPF attached to N6 to NG-RAN; the N9 interface may be used for MBS

And delivering the service.

-NG-RAN：

Receiving MBS streams via N3 and delivering over the air (delivery over-the-air).

Switching between multicast and unicast delivery of MBS streams.

UE configuration for MBS stream reception at the AS layer.

-UE：

Supporting UE policy configuration extension to MBS.

Support SM extensions for MBS streams.

Signaling for joining MBS streams (via SM signaling or user plane IGMP joining).

Supporting MBS at the AS layer.

A.1.2 service layer aspect of the reference architecture: the service layer may be supported on top orthogonal to the description of the multicast stream user plane model at the transport layer. The service layer is completely separated from the multicast transmission. This allows applications that do not require a service layer to establish multicast transmissions directly via Nnef (control plane and N6 (user plane data)).

Fig. 4 shows an example of service layer support for multicast/broadcast using xMB/MB2 as an entry point. A new network function is introduced, called Multicast Service Function (MSF). The MSF provides only the service layer functions and requests (via either Npcf or Nnef) the underlying multicast transport required for the multicast service from the 5G system. The MSF has the following functions:

an entry point for both control plane service layer signaling and user plane data, e.g. xMB/MB2. Interaction with external AF may occur directly or via 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.

-encoding data at the service layer.

-delivering multicast service layer data packets via N6.

If the application does not need any specific service layer functionality, the application may use:

-Nnef is directly used for multicast session configuration/negotiation, and

-N6 is used for multicast data delivery.

This is illustrated in fig. 5, fig. 5 depicts an exemplary MBS system with direct application server/function interactions.

In annex A.2 of [1], a 5G MBS system architecture based on dedicated MBS functionality is described.

To support MBS in 5GS user service delivery, there are two different modes of operation: one for the transport-only mode and the other for the full service mode (TS 23.246 clause 7.5).

For the transport-only mode, the MBS application data is transparent to the network functions in fig. 6.

For full service mode, the MBSF/MBSU knows the content flow and can convert the content flow to a 3GPP compliant flow.

Fig. 6 shows a single exemplary architecture for MBS in 5 GS. In this fig. 6, the SMF and UPF having roles to support the MB session are named "MB-SMF" and "MB-UPF". Nothing prevents MB-SMF and MB-UPF from supporting both PDU session and MB session, e.g., PDU session and MB session to the same DNN. However, MB-SMF and MB-UPF may also be deployed and configured to handle MB sessions exclusively. It is believed that this may reduce signaling and in some cases, operating a limited number of MB-SMFs and MB-UPFs dedicated to MBS may be simpler and more cost effective. This architecture makes it possible, if preferred.

Enhancements to existing entities and new functional components are as follows:

UE, NG-RAN, AMF, SMF, UPF, NEF and PCF support MBS.

-UE supporting 5G MBS services.

The NG-RAN supports point-to-multipoint (PTM) and point-to-point (PTP) delivery of MBS media. The NG-RAN independently controls the switching between PTM and PTP to achieve optimal quality of service and resource efficiency.

The AMF is enhanced to select MB-SMF and becomes part of the signaling distribution tree.

The MB-SMF is an enhanced SMF for controlling the MB session, signaling with AF (via NEF/MBSF), qoS control using PCF, and providing MB session information according to the AMF's request. The PDU session maintained by the UE for individual delivery of MBS services may be associated with MB sessions managed by MB-SMF.

The MB-UPF is a UPF enhanced with MBs user plane functions.

MBSF (multicast/broadcast service function) is a function, which may be part of the NEF or deployed separately.

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 has an interface to the MBSU. The MBSF may perform authorization for the UE to join the MB session.

The MBSU (multicast/broadcast service user plane) is a new entity handling the payload part to meet the needs of service level functions and management.

-NEF is an existing NF that provides an interface to AF.

The PCF is enhanced to handle QoS for MB sessions, e.g. authorizing QoS profiles for shared delivery.

Enhancements to existing interfaces and new interfaces are as follows:

the N2 interface controls the MB session, including managing 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 NG-RAN.

The N4 interface manages a shared N3 tunnel between the MB-UPF and the NG-RAN, including establishing the shared N3 tunnel.

The N7 and N30 interfaces enable policy control for MB sessions.

The N11 interface is enhanced with MBS control signaling, including managing a shared N3 tunnel between MB-UPF and NG-RAN.

The N29 interface is enhanced with MBS control signaling.

The N33 interface is enhanced with MBS control signaling.

-Ny: a new interface between the MBSF and the MBSU for managing the MBSU functions.

-NxMB-U: a new interface between the new MBS su and AF for MBS user plane traffic.

Following these architectures, a number of possible solutions are listed in [1 ]. For example, solution #2 in [1] assumes a 5G MBS system architecture based on dedicated MBS functions. Fig. 6.2.2.2a-1 describes a session starting with 5GC individual MBS service delivery (i.e. with PUD session to UE). Fig. 6.2.2.2-1 depicts session initiation for an MBS session. In connection with this, the AF delivers the media stream to the MB-UPF, which sends it further downstream in the network.

Background 2:5MBS current safety key problem and solution

Based on the above overall architecture of 5MBS [1], it is currently being investigated how to protect 5MBS systems. This is reflected in TR33.850 v0.2.0 (study on security aspects of 5G multicast-broadcast service enhancement) [2]. Three key problems need to be solved at present:

key issue #1: the 5GS should support authentication and authorization for multicast communication services. In particular, this key issue refers to the reference architecture in [1] and key issue #3 in [1] summarized above, which includes two aspects: (i) Defining and researching how to support the necessary level of authorization for a UE to access multicast communication services; (ii) How can a UE join/leave (including grant or revoke access to) a multicast communication service?

Key issue #2: the 5GS should support confidentiality protection, integrity protection, and anti-replay protection of MBS services.

Key issue #3: the distribution of keys for protecting MBS traffic between the key generator and the UE should be protected from confidentiality, integrity and replay protection.

In [2], there are three solutions for KI#2 and KI#3. These solutions are solution #1, solution #2, and solution #3.

Solution #1 focuses on protecting MBS traffic at the transport layer. In this case, the group key is used at PDCP level and generated in the RAN. The group key is used to protect MBS services.

Solution #2 focuses on protecting MBS traffic at the service layer. The group key is generated at (MB) -SMF. The key is securely transmitted to each UE using a MUK, which is a key derived from Kausf. The group key is used to protect MBS services.

Solution #3 focuses on protecting MBS traffic with Multicast Transmission Keys (MTKs) that are generated in the core network and distributed to UEs in a secure (unicast) manner. The MTK is used to protect MBS services.

Background 3: MBMS security architecture for 5G r16

Related to the description of the invention in 5MBS is how to implement security for MBMS in 4G. The security architecture for MBMS is described in TS 33.246[3 ]. Next, the most important aspects are summarized:

* Accessory B describes the security threat under consideration. B.1 is a threat in the radio interface. B.1.1 describes "unauthorized access to MBMS user service data" and others, and includes threats in which an intruder may eavesdrop on the MBMS user service data, threats in which users who have joined and left the MBMS user service continue to receive the service free of charge, and threats in which the subscriber derives the decryption key and distributes the decryption key to unauthorized parties. B.1.2 describes "threat to integrity" including modifying and replaying messages to spoof user content from actual sources.

* Accessory C describes the security requirements. In particular, C.4 describes requirements regarding MBMS key management, including "UE (user equipment) The MBMS key generator should support the operator to perform key updates as often as it deems necessary to ensure that: 1) Has already been provided with Users that join the MBMS user service but subsequently leave do not have to obtain access to the MBMS user without being properly charged Further access to the service; 2) Users joining the MBMS user service have to access from without being properly charged Previously transmitted data in MBMS user services; and 3) the influence of the subscribing user distributing the decryption key to the non-subscribing user should be Is controllable”。

* FIG. 7 (corresponding to [3 ]]In fig. 4.1) describes the entire MBMS security architecture. In Itec web page (inhttps://itectec.com/spec/4-2-key-management-overview/(hereinafter referred to as [4 ]]) Available) comprises the following steps of [3 ]]Key management and security in MBMS. According to [4 ]]And [3 ]]Section 4.2: "BM-SC controls the use of MBMS Service Keys (MSKs) to protect the different RTP sessions and FLUTE channels. MSK is used to protect delivery of MBMS Transport Keys (MTKs) used to protect RTP sessions and FLUTE channels specified in clauses 6.5 and 6.6. The delivery of MSKS is protected with a user specific MBMS User Key (MUK) received from GBA, reference clause 6.1. The MSK and the MTK are managed at the MBMS user service level. "this means that a UE capable of accessing a service receives an MSK protected with MUK. The MTK is distributed to a plurality of UEs protected with the MSK. This is shown below (where the arrow indicates protection with it):

MUK->MSK_0->MTK_00

->MTK_01

->…

->MSK_1->MTK_10

->MTK_11

->…

->…

* Section 6.3.2.2 describes the MSK request procedure required for 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 pull procedure requested by the BM-SC. The last process is described in 6.3.2.2.4 and depicted in fig. 6.2b in [3] and fig. 8 below. It shows that the BM-SC sends a MIKEY message to the UE, which verifies the message and if correct sends an HTTP POST request to get the MSK update.

* MIKEY stands for multimedia Internet keying (Multimedia Internet KEYing) and is defined in RFC3830 (https:// tools. Ietf org/html/RFC 3830). MIKEY is defined by Ericsson Research in 2004, and this document describes a key management scheme that can be used for real-time applications (for both peer-to-peer and group communications).

* [3] Section 6.3.2.3 in (i) describes how MSK is delivered to the UE, in particular (i) MSK push (section 6.3.2.3.1), where MB-SC delivers keys in MIKEY messages over UDP. The UE also replies with a MIKEY message over UDP.

*[3]Section 6.3.3 in (c) describes a procedure for MTK including their unique IDs that depend on the MSK ID.This means that the same MTK cannot be used with two different MSKs . The update of the MTK is protected with the MSK and the message may be included in the multicast/broadcast stream.

* Attachment I shows an example of how traffic is protected. In particular, the same MSK may be used to protect both subscriber services.

* Section 6.3.4 describes how to handle "multiple BM-SC deployments", which only applies when the same MBMS user service is sent over multiple BM-SCs. If this happens, the keys in the multiple BM-SCs (MSK (section 6.3.4.4) and MTK (section 6.3.4.5)) are identical, as they are used with the same traffic. [2] Solutions #1, #2, and #3 in (b) use a single group key to protect multicast/broadcast traffic. The problem is that if the group key is corrupted (e.g., the UE is malicious, or just the UE is removed from the MBS), these solutions do not describe how to update the group key so that the content distributed at a later point in time is not obtained or modified. In particular, if the group key cannot be updated, the attacker:

a) Content may still be accessed, for example, by passively monitoring communications.

b) Traffic may be injected, for example, in the context of a MitM attack.

Similarly, [3] describes a security architecture (r 16) for MBMS in which individual device keys (MUKs) are used to deliver Multicast Service Keys (MSKs) for protecting Multicast Transmission Keys (MTKs) for specific MBMS services. In this case, the group key is equivalent to the MTK. If the UE is corrupted, it is required to update MSK and MTK. [3] How to update the MSK is described, however, the update requires a lot of signalling, since each UE needs to contact the BM-SC to obtain a new MSK, as shown in fig. 8, fig. 8 describes the pulling of the BM-SC request.

Disclosure of Invention

It is an object of the present invention to alleviate the above problems.

It is a further object of the invention to ensure efficient updating of cryptographic keys.

It is a further object of the invention to reduce the amount of signalling required to reconfigure the system in case the terminal is destroyed or revoked.

It is a further object of the invention to provide a primary and secondary station which can update a shared cryptographic key more efficiently while improving the security of the system.

Accordingly, in a first aspect of the present invention, there is provided a method for a primary station to distribute cryptographic keys to a plurality of secondary stations, comprising the steps of:

a. determining whether a group key is required to be updated, the group key being used for multicasting protected communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, the updated cryptographic key is sent to at least a subset of the secondary stations via an encrypted message.

Thus, when the group key needs to be updated, the system automatically provides the updated cryptographic key to ensure that the system is not compromised. Note that the cryptographic key may correspond to an encryption key used to encrypt data information. In some variations, the cryptographic key may be used for integrity protection, e.g., to authenticate the source of the message or the freshness of the message.

In a variation of the first aspect of the invention, the updated cryptographic key is an updated group key, and wherein the encrypted message is encrypted by a user-specific encryption key and sent in a unicast manner. Unicast means that a message is addressed to a single target. This corresponds to a point-to-point message. This may be done, for example, by using a dedicated channel and/or by identifying the recipient of the message.

In another variation of the first aspect of the present invention, the step of determining whether the group key needs to be updated includes 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 expired, the validity time of the group key has expired, at least one of the secondary stations has left a predetermined location.

In another variation of the first aspect of the present invention, the updated cryptographic key is a first set key shared to the first set of secondary stations.

According to this variant, the secondary stations are grouped into sets. Each of the sets includes a plurality of secondary stations, and the secondary stations share the same set cryptographic key. The set cipher key or first set key allows some multicast messages addressed to the secondary stations in the first set to be encrypted/protected. Thus, when updating the group key, the master station can direct a corresponding multicast message to each set. This reduces the number of messages sent because they are sent in multicast rather than unicast to each secondary station. By multicasting this corresponds to a single message addressed to a group of secondary stations, for example using a common encrypted set key. This may be accomplished, for example, by using a broadcast channel. In an example of this variant, wherein it is determined at step a that the access rights of at least one of the secondary stations belonging to the first set are currently invalid, the first set key is updated. This effectively means that one of the secondary stations of the first set is destroyed or has been revoked. Thus, the first set needs to update its set key to ensure that an attacker cannot access the data sent to the first set.

Once the first set key is updated, the updated group key may be sent to each set of secondary stations via multicasting. This corresponds to the step of sending the updated group key to each set of secondary stations by means of a message protected with a respective set key associated to each set of secondary stations.

Note that in some cases, for example, in the case where the secondary station joins for the first time, or if the number of stations in the set is small, the message may instead be sent in unicast. Furthermore, in some specific cases, the message may be sent twice, once in unicast and once in multicast.

Note that the first set key may be used to encrypt and/or protect the integrity of messages sent to the set of secondary stations and/or to protect the freshness of the messages.

According to a second aspect of the present invention there is provided a method for a primary station to distribute cryptographic keys to a plurality of secondary stations, comprising the steps of:

a. determining whether a group key is required to be updated, the group key being used for protected multicast communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, the updated group key is sent to the respective set of secondary stations in a respective multicast message that is secured by the respective set key associated with each respective set.

Similar to what was explained previously, according to the second aspect of the invention, the secondary stations are grouped into sets. Each of the sets includes a plurality of secondary stations, and the secondary stations share the same set cryptographic key. The set cipher key or first set key allows some multicast messages addressed to the secondary stations in the first set to be encrypted/protected. Thus, when updating the group key, the master station can direct a corresponding multicast message to each set. This significantly reduces the number of messages sent because they are sent in multicast rather than unicast to each secondary station. By multicasting this corresponds to a single message addressed to a group of secondary stations, for example using a common encrypted set key. This may be accomplished, for example, by using a broadcast channel. In an example of this variant, wherein it is determined at step a that the access rights of at least one of the secondary stations belonging to the first set are currently invalid, the first set key is updated. This effectively means that one of the secondary stations of the first set is destroyed or has been revoked. Thus, the first set needs to update its set key to ensure that an attacker cannot access the data sent to the first set.

In this second aspect of the invention, determining whether the group key needs to be updated includes determining whether at least one of the following conditions is met:

at least one of the access rights of the secondary station has been revoked,

at least one of the access rights of the secondary station has expired,

the validity time of the group key has expired,

-at least one of the secondary stations has left a predetermined position.

The set key may also need to be updated if the need for updating is related to a problem with access rights of one of the stations. As an example, the method comprises: if it is determined at step a that the group key is not associated with an access grant invalidation of a first secondary station belonging to a first set of secondary stations, a new first set key is sent by unicast to each secondary station in the first set by means of a protected unicast message.

Once such an update of the first key is made for the first set, the secondary station of the first key may receive the updated encrypted group key. Thus, in such an example, the method would further comprise step c: the updated group key is sent to the first set of secondary stations in a multicast message, which is encrypted with the new first set key. This is similar to other sets, but these sets do not require updating the set key. Thus, the number of messages required for updating is reduced for all secondary stations of the other set.

In a different example, the group key may 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 avoiding the transmission of new multicast messages to the first set, thereby further reducing the amount of messages sent during the group key update.

In a third aspect of the invention, a method for a primary station to distribute cryptographic keys to a plurality of secondary stations is presented, comprising the steps of:

a. determining whether a group key is required to be updated, the group key being used for protected multicast communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, transmitting a first set key by unicast to at least a first subset of the secondary stations via a protected unicast message,

c. transmitting an updated group key to a first set of secondary stations in a multicast message, said multicast message being protected by said first set key, or alternatively including said updated group key in said protected unicast message of step b,

d. the updated group key is sent to the further respective sets of secondary stations in respective multicast messages protected by respective set keys associated with each respective set.

Note that the primary station may be a base station, e.g. an eNodeB (eNb) in LTE or a gndeb (gNb) in 5G. However, the master station may correspond to a higher level entity of the network, e.g. a core network element or a network trust center. In this case, the steps related to the transmission to the secondary station comprise the indirect transmission of the message through different interfaces (optical fiber, ethernet, air interface) and through different entities including, for example, base stations or repeaters. In such a case, it may not be directly from the master station. The message delivering the cryptographic key may be initiated by a given 5G network function within the core network, but the network function may provide it to another entity in the core network responsible for sending 5MBS traffic.

In a variation of the second or third aspect of the invention, the set of secondary stations is formed based on location, and wherein step d further comprises: the master station transmits the updated group key in at least one further multicast message encrypted by a corresponding set key used in the adjacent set. In an example, the neighbor set is a set of a plurality of secondary stations camping in a cell served by another primary station. For example, the neighbor set may be a set of secondary stations serving in a neighbor cell. These secondary stations may be served by the same primary station or different primary stations. This allows the secondary station to have a certain mobility without the risk of missing a group key update because the secondary station leaves its original cell. To further improve this reliability and reduce the risk of secondary stations missing updated keys, multicast messages may be periodically retransmitted.

However, in different examples of these aspects, the sets may be formed in a more random manner, e.g., based on the secondary station's identifier or based on the connection time.

In yet another variation of these aspects of the invention, the multicast message includes the updated group key and an authentication fingerprint message calculated as a hash of the updated group key.

According to a fourth aspect of the present invention, there is provided a method for a secondary station to receive a cryptographic key in a network, comprising the steps of:

a. receiving a first set key from a primary station via unicast via a protected unicast message, the first key being associated with a first set of secondary stations,

b. and receiving a multicast message of the first set of secondary stations and decrypting the multicast message into an updated group key, the decrypting using the first set key.

In a variation of the fourth aspect of the present invention, it is proposed that the multicast message comprises a protected updated group key and an authentication fingerprint message, and the method further comprises the secondary station authenticating the multicast message by checking whether a hash of the decrypted group key matches the received authentication fingerprint. Thus, when an attacker tries to simulate a primary station and send a false message, this allows all secondary stations to report any discrepancies. Thus, it may be proposed to report an exception to the primary station if the check fails.

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, comprising:

a controller adapted to determine whether a group key is required to be updated, the group key being for protected multicast communication from the primary station to the plurality of secondary stations,

a transmitter coupled to the controller is adapted to send the updated group key to a respective set of secondary stations in a respective multicast message, the multicast message being protected by a respective set key associated with each respective set, upon determining that an update is required.

Note that the primary station may be a base station, e.g. an eNodeB in LTE or a gndeb in 5G. However, the master station may correspond to a higher level entity of the network, e.g. a core network element or a network trust center. In this case, the steps related to the transmission to the secondary station comprise the indirect transmission of the message through different interfaces (optical fiber, ethernet, air interface) and through different entities including, for example, base stations or repeaters. In such a case, it may not be directly from the master station. The message delivering the cryptographic key may be initiated by a given 5G network function within the core network, but the network function may provide it to another entity in the core network responsible for sending 5MBS traffic.

Thus, 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 conventional unicast messages

According to a sixth aspect of the present invention there is provided a secondary station operating in a cellular network and in communication with a primary station, comprising: a receiver adapted to receive a first set key from a primary station by unicast over a protected unicast message, the first key being associated with a first set of secondary stations; and a controller adapted to decrypt multicast messages to the first set of secondary stations into updated group keys, the decrypting using the first set key.

Note that decrypting the multicast message may also be replaced or supplemented by an authenticity check and/or freshness check of the multicast message.

According to a seventh aspect of the present invention a computer program and/or program code means stored and/or distributed as dedicated hardware on a suitable medium, such as an optical storage medium or a solid state medium, the program code means being provided together with or as part of other hardware, but the program code means being also capable of being distributed in other forms, such as via the internet or other wired or wireless telecommunication systems, and the suitable medium comprising instructions for carrying out the method of the first, second, third or fourth aspect of the present invention.

Note that the above-described apparatus may be implemented based on an arrangement of discrete hardware circuits, integrated chips or chip modules with discrete hardware components, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer readable medium or downloaded from a network (e.g., the internet).

It shall be understood that the claimed method and the claimed apparatus (primary or secondary) may have similar and/or identical preferred embodiments, in particular as defined in the dependent claims.

It is to be understood that the preferred embodiments of the invention may also be any combination of the dependent claims or the above embodiments with the corresponding independent claims.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

Drawings

FIG. 1, which has been described, is a diagram illustrating a high level MBS architecture;

fig. 2, which has been described, is a diagram showing a delivery method for MBS;

fig. 3, which has been described, is a diagram illustrating a 5G system architecture for integrated multicast transmission with unicast;

fig. 4, which has been described, is a diagram showing an example of service layer support for multicast/broadcast;

FIG. 5, which has been described, is a diagram representing an exemplary MBS system with direct interaction with an application server;

FIG. 6, which has been described, is a block diagram representing a single exemplary architecture for MBS in 5 GS;

fig. 7, which has been described, is a diagram showing the entire MBMS security architecture;

fig. 8, which has been described, is a diagram showing a conventional method for updating a key in a UE;

fig. 9 is a diagram showing a process according to the first embodiment of the present invention;

fig. 10 is a diagram showing a process according to a second embodiment of the present invention;

FIG. 11 is a diagram representing a modified key hierarchy in accordance with an embodiment of the present invention;

FIG. 12 illustrates a particular exemplary embodiment of the present invention;

FIG. 13 is a diagram illustrating a process according to another embodiment of the present invention;

FIG. 14 is a block diagram representing a network in which embodiments of the present invention are implemented;

FIG. 15 is a diagram representing different key hierarchies for use in a proposed embodiment of the present invention; and

fig. 16 is a diagram proposed for use in the change in the 3GPP standard specification.

Detailed Description

As can be seen from the above, the present invention may be implemented in a cellular network (e.g., a 4G network or a 5G network).

In these telecommunication systems shown in fig. 14, the secondary station 100 serves as a terminal or end device (also referred to as user equipment UE in 5G). The secondary station may access different types of services including voice and data services through a base station 110 (also referred to as a gNB in 5G) deployed in the field. Each base station 110 serves and communicates with secondary stations 100 that are present in an area (also referred to as a cell 111). The base stations are connected to a Core Network (CN) 120 managed by a network operator, which Core Network (CN) 120 controls the telecommunication system and orchestrates the delivery of services.

As seen with respect to fig. 14, such a cellular network includes a plurality of terminals or secondary stations 100, which terminals or secondary stations 100 are mobile devices (or UEs) that may travel from a network cell to another network cell 111. Each cell 111 is served by a base station 110 (or gndeb), which base station 110 (or gndeb) forms the interface between the secondary station 100 and the core network 120.

Thus, secondary station 100 communicates with base station 110 on various radio channels, uplink (from secondary station to base station) and downlink (from base station to secondary station). Other radio channels exist, for example, between secondary stations (e.g., side link channels) and base stations (e.g., X2 interface), but are not shown for simplicity of fig. 14. Embodiments of the present invention may also be applied to these interfaces, however, the links between secondary stations and base stations will be focused in the following portions of the description.

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. The base station may also operate (partly or wholly) as a primary station in the sense of an embodiment of the invention.

According to the definition of the embodiment of the present invention, a procedure of updating a group key for protecting multicast/broadcast service is proposed in solution #2 and solution #3 in [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. Thus, this basic idea ensures that an attacker cannot access the content or inject traffic, but has the disadvantage that it involves a high overhead of distributing new content keys to all "N-1" uncorrupted UEs.

The basic idea described above is improved in the various embodiments and examples below (the extended idea) by defining "M" UE groups, each UE group being associated with a key group. The group may be based on, for example, the location of the UE. If the UE is corrupted, then:

updating content keys using group keys in M-1 uncorrupted groups

-updating the group and the content key with N/M-1 messages for UEs in the group corresponding to the corrupted UE.

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 will be reduced from 9999 messages to 63 messages. The extension idea is applicable to solutions such as #1, #2 and #3 in [2], and can also be used in [3] to reduce signaling overhead.

Note that one difference between this embodiment of the invention and the solution in [3] is that this embodiment allows the same k_group (similar to the MTK in [3] and used to protect multicast/broadcast content) to be distributed with different k_set keys (similar to the MSK in [3] and used to deliver the key set).

The basic embodiment of the invention is described in detail in the context of solution #2 in [2], however, similar approaches apply to similar solutions in [2] (e.g., solution # 3). This embodiment also applies to [3].

Basic embodiment

Fig. 9 depicts the basic procedure set forth in the present invention, wherein the alphabetical steps (a-f) are additional items of the solution applied to solution #2 in [2 ].

a) It is checked whether the UE is allowed to join the MBS group.

b) It is checked whether the UE access rights have been changed, e.g. revoked.

c) A request to update the group key is sent.

d) The group key is updated.

e) Unicast messages protected with MUK are sent to each non-revoked UE updating K_group_enc and K_group_int. Each UE uses its MUK to verify the authenticity of the message and decrypt the new group key. Freshness also needs to be verified (see example 3 below).

f) The updated group key is used to protect the content data and send it to the UE.

In fig. 9 AE stands for authenticated encryption (Authenticated Encryption), which means a message: i) Is authenticated by, for example, a Message Authentication Code (MAC) calculated using a key (e.g., authentication and integrity protection specific key (K int)); and ii) encrypted using a key (e.g., an encryption-specific key (K end)). An example of AE is AEs in GCM mode.

With this basic solution, k_group can be updated and revoked UEs are prevented from accessing or modifying broadcast data. This basic solution requires the exchange of N-1 messages if N UEs are subscribed to a given MBS.

Example 1: definition of UE sets and set keys

Fig. 10 depicts a modified embodiment of the basic embodiment of the present invention, in which the alphabetical steps (a-i) are additional items of the solution applied to solution #2 in [2 ].

a) It is checked whether the UE is allowed to join the MBS group.

b) Generating a key K_group to protect content and M keys K_sets to protect delivery of K_group, wherein

The set refers to a set of M-N/L UEs.

c) It is determined in which set the UE is placed.

d) Check if the UE has been revoked, has left the group, etc.

e) Send a request to update: 1) A group key for protecting multicast/broadcast content; and 2) a set key for protecting delivery of group keys in a set of devices affected by UE revocation.

f) The group keys (k_group_enc and k_group_int) are updated. The set keys (k_set_enc and k_set_int) associated with the set of UEs are updated.

g) The set keys of the M-1 UEs in the corrupted set are updated through M-1 point-to-point interactions.

h) The new group key for protecting 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.

With this embodiment, k_group can be updated and revoked UEs are prevented 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, whereas the method requires 64 messages.

If this embodiment is applied to the solution presented in [3], different sets of UEs accessing the same multicast broadcast service are given different set keys (MSKs). These different set keys are used to protect the same group key (MTK) at a given point in time without requiring unicast communication between the UE and the MB-BC, i.e., updating of the group key. This modification changes the key hierarchy in the MIKEY used in [3], as shown in fig. 11. The MSK is defined for a set of users and has L. Each of them can be updated individually and each of them has a different counter { i1, i2, …, iL }. If the set key (MSK) is updated, this implies a change in the group key (MTK). The MTKs have different counters t to identify them. The group key (MTK) may be updated in an proactive manner even if no set key (MSK) is updated, for example if the group key (MTK) has been used for too long a period of time.

Fig. 12 shows a more specific example, where three sets of devices have set keys identified with msk_1, msk_2, and msk_3. There is one device for each set of devices, in set 1 of devices, there is device a with device key denoted muk_a; in set 2 of devices, device b with device key denoted muk_b; and in the set 3 of devices, device c having a device key denoted muk_c.

The first set of keys for protecting the content data is denoted mtk_0.

In this case, the set of devices a is changed, for example, devices leave the set of devices. This will trigger an update of msk_1_i1 to msk_1_ (i1+1), i.e. a change of the set key and an increase of its index. Since the group key mtk_0 may be corrupted, msk1_ (i1+1), msk2_i2, and msk3_i3 are used to distribute the new mtk_1 to devices in different sets in a secure manner.

In this case mtk_1 is used for a long time. This will trigger an update to mtk_2, which is securely distributed using msk_1_ (i1+1), msk_2_i2, and msk_3_i3.

In this case, a change in the set of devices b occurs, for example, a device leaves the set of devices. This will trigger an update of msk2_i2 to msk2_ (i2+1), i.e. a change of the set key and an increase of its index. Since the group key MTK_2 may be corrupted, MSK_1_ (i1+1), MSK_2_ (i2+1) and MSK_3_i3 are used to distribute the new MTK_3 to devices in different sets in a secure manner.

This embodiment can also be applied to solution #1 in [2 ]. Instead of having to deliver N RRC reconfiguration requests, only M-1 RRC reconfiguration requests may be sent to update the new set key. The new group key must be delivered together with the multicast/broadcast service, in particular, the new group key is protected with 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 service. Note that if the last requirement is not viable, then the alternative would be to deliver the new group key through an RRC reconfiguration request, however, these messages are unicast messages, so that a change of RAN would be required to be able to deliver the RRC reconfiguration message through the broadcast channel.

This solution can be used in the context of solution #3 in [2 ]. In this solution, a Multicast Transmission Key (MTK) generated in the core network (MB-CP) is defined. The MTK is securely distributed to each UE (in unicast mode) and is used to protect MBs data from MB-UP to UE. If this embodiment is used, multiple set keys are generated in the core network (MB-CP). The set key is then transmitted to the UE in a secure manner via a secure unicast message. The set key is then used to update a group key that protects the content key from MB-UP to the UE.

An important aspect of this embodiment is how to define the set of UEs. One option is to define the set of UEs according to location. The location may be related to, for example, the base station or an area covered by an antenna beam of the base station, or based on a tracking area. This is important because all UEs in the area can receive content using the same radio resources. A specific example may be in a stadium where multicast/broadcast content (e.g. digital identification or information about a game) is to be delivered by a base station. In order to provide as good performance as possible, the base station uses multiple radio beams to address different sets of users in the stadium. Other methods of defining the set are possible, e.g. depending on the characteristics of the UEs, on the multicast and broadcast services to which they are subscribed.

Example 2: facilitating mobility

In solution #1 in [2], mobility may be further normalized. If the UE moves to a nearby cell, it is important to use the same group key when delivering multicast/broadcast content to avoid any service interruption. From this point of view, 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 the set key associated with the set of devices around its 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 and the UE may miss the message. Alternatively, the base station may broadcast the update of the group key using the set key of the surrounding area. In this way, if the UE is from the surrounding area, it will be able to decrypt the new group key. The advantage of this last method is that less keying material is provided to the UE, thereby reducing the risk of leakage. Another significant advantage is that the set key should be updated when the UE leaves the set of UEs. If the UE has a single set key, the amount of updates is low.

This is illustrated in fig. 13, where a UE (e.g., a UE within a bold circle) may have multiple set keys. In this case, UEs within the thick line circle may have k_0 and k_0i, where i= {0, …,5}. Alternatively, the UE may have only k_0 and the surrounding cells will broadcast the update of the group key with the surrounding set key.

We note that another benefit of doing so is the RAN architecture using DU/CU splitting. In such an architecture, each Distributed Unit (DU) may be a separate cell, and the Central Unit (CU) runs the RRC layer of all DUs. One approach may protect MBS traffic at a different group key than per DU. If the UE leaves the DU, only the UEs in the DU have to be updated. From this point of view, the solution may be similar to the performance with multiple set keys. The difference is that the CUs, because the CUs that distribute MBS traffic to all DUs, must protect MBS traffic with as many group keys as DUs it handles. With the proposed solution of the present invention, each DU will have its own set key for verifying and decrypting the delivery of the group key protecting the MBS data. The CU only has to encrypt MBS data once, which controls the group key shared by all DUs. When delivering this data, the CU must include a protected group key beside the protected MBS service, which is protected with each of the set keys assigned to each of the DUs under its control.

Example 3: maintaining synchronization

UEs that are part of the group may miss the key group update. If this occurs, the UE may not be able to decrypt the distributed content. To avoid this, the currently used key set is distributed periodically in an proactive manner, in particular shortly after performing the key update.

Another important aspect refers to how freshness is ensured. One way of ensuring this is to use time, e.g. UTC time, in the construction of the Initialization Vector (IV) used in AE. If a counter is used in the IV construction, the IV should be set to an initial value and should be increased continuously when a new group key is distributed. The UE should not accept any message with an IV older than it currently has. Since the transmission key is shared among all devices, an attacker may also attempt to inject spurious traffic. For this reason, 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. data transmission equivalent to seconds or minutes. If the IV is constructed by using the UTC-based counter, the UE should not accept a message containing an IV that differs from the current time by more than a small time window.

Example 4: ensuring source authentication in updating group keys

A problem encountered in the system described so far is the use of several set keys to update the group key (as described in embodiment 1). This problem also arises in [3], because the MTK is updated using MSK. Due to the set key (and MSK in [3 ]), an attacker may try to "forge" an update of the group key. This may lead to a situation where the set of devices obtains the wrong group key. The direct impact is that the received content will not be decrypted and the message authentication code will fail. If on this basis an attacker tries to inject dummy content protected with a previously injected dummy group key, the UEs in the set of devices will accept the dummy content.

Two methods of addressing this problem are proposed:

method 1: to address this problem in these systems, in [3], the network may construct a group key updated authentication fingerprint. The fingerprint is constructed by the steps of: 1) A new group key K is obtained randomly, which is for example 256 bits long; and 2) obtaining a HASH of K (e.g., SHA2 or SHA 3), i.e., r=hash (K). When the network broadcasts a key update, the network also appends R to the message by distributing a new group key that is protected with M set keys (step h in fig. 10).

Upon receiving the set of key update messages, the UE performs the following operations:

a) The lookup message includes the portion of the group key that is protected (encrypted/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 are successful, the UE decrypts the new group key.

b) It is checked whether the hash of the received value R is equal to the decrypted group key.

In the above attack, a node in the set of nodes will successfully check both conditions a) and b) above. However, since the information is sent over a broadcast channel, all devices will receive the message, while the devices in the other set will not be able to successfully verify condition b). Thus, those devices in the other set of devices may trigger an alarm to the core network indicating a mismatch and including the received message. The network can verify which one of the sets is affected/attacked by checking which one of the group key updates is erroneous.

Method 2: in the context of current research dealing with pseudo base stations, some solutions using digital signatures are being discussed. One of these solutions is digital signature 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, a group key update. In this case, message h in fig. 10 will also be signed by DSnF. To this end, the network entity that generated the message needs to first send a request to the DSnF to obtain the signature of the message. The signature is then appended to the group key update. If so, the UE accepts the decrypted key update only if:

1) Verification of the MAC using its set key is correct;

2) Freshness check using a counter (e.g. example 3) is correct;

3) The digital signature is successfully verified.

It is noted that if the generation and distribution of the group key is done within the RAN (as in solution #1 in [2 ]), the base station may also attach a signature. This may require that a request be sent first to DSnF. Or alternatively use its own public/private key pair if they are owned.

Furthermore, in view of the previous embodiments and variants of the invention, it is proposed to adjust the procedure described in TR33.850 as follows: 2 detailed proposal

KI #2 in TR 33.850 requires 5GS to support confidentiality protection, integrity protection, and anti-replay protection of MBS services. Ki#3 in TR 23.757 also requires investigation: how does a UE join/leave (including grant or withdraw access to) a multicast communication service? "

Combining these two key issues, risks and threats may be encountered, such as:

the content key for protecting 5MBS service is used for a long period;

devices in the group leave, which should be prevented from receiving new content;

device join, which should be prevented from accessing old content;

devices in the group are malicious and should be prevented from injecting spurious content.

The risk and threat requirements described above:

1. adapting to existing key issues or creating new key issues requires that 5GS be able to update the keys used to protect the multicast content.

2. An efficient solution for distributing and updating keys for protecting content makes it possible to distribute and update these keys in an efficient manner.

We consider SA3 to include two additional changes in TR 33.850.

The first change sets the requirements for the key update needs.

The second change describes an efficient and resilient method for key distribution and updating. For the sake of explanation, this is in the context of existing solution # 2.

* Change 1 start

Key problem #3: security protection for key distribution

5.3.1 details of Critical questions

MBS introduces the concept of point-to-multipoint service in 3GPP systems. MBS services are delivered from an application service provider to a plurality of UEs through 5 GS. In order to securely send data to a given set of users, MBS services need to be protected to mitigate potential attacks. As a fundamental basis of security, a key for protecting MBS services is required.

The key used to protect the MBS service is a one-to-many key compared to the UE key. When the UE joins the MBS session, only the authorized user can receive the key delivered from the key generator to protect the MBS service. The UE may also leave the MBS session or be corrupted.

5.3.2 security threats

An attacker can use the 3GPP network to obtain "free access" to MBS services if the keys used to protect the MBS services are not confidentiality protected.

If the key used to protect the MBS service is not integrity or playback-proof protected, the authorized user may not be able to properly acquire the MBS service.

If the key for protecting the MBS service cannot be updated, then:

if a device in the group leaves, the device is also able to access the content,

if a device joins the group, the device can access the previous content,

If a device in a group is malicious, the device can inject spurious content.

5.3.3 potential safety requirements

The distribution of keys for protecting MBS services between the key generator and the UE should be confidentiality, integrity and replay protection.

The 5GS should be able to update keys for protecting MBS services.

* Change 1 end

* Change 2 start

Solution #2: protecting MBS business at service layer

6.2.1 overview of the solution

This solution solves critical issue 2 and critical issue 3 to support secure MBS service delivery from a context provider to multiple UEs over 5 GS. In baseline architecture 2 in TR 23.757[2], the mbs u (Multicast/broadcast service user plane (Multicast/Broadcast Service User Plane)) is defined as a new entity that processes the payload portion to satisfy 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. It is independent of protection from the content provider in the application layer.

A key for protecting the MBS service is generated in the SMF. The keys are then distributed to the UE and the MBSU/MSF-U, respectively. UEs belonging to the multicast group acquire the same key in the mbs U/MSF-U. The key can be updated in an efficient manner.

6.2.2 solution details

Alternative to fig. 6.2.2-1. The procedure of protecting MBS service at the service layer is shown in fig. 16.

The process is described as follows:

the ue registers 5GS and establishes a PDU session.

2. The content provider advertises the availability of multicast using a higher layer (e.g., application layer).

The ue sends a PDU session modification request. Information about the multicast group should be transmitted, including an identifier of the multicast group that the UE wishes to join. The multicast_group_id may be a Multicast address or other identifier.

AMF calls Nsmmf_PDUSion_UpdateSMContext, which includes information about the multicast group.

The editor annotates: if SA2 agrees to support multicast session join/leave operation of UE via UP (e.g., IGMP join +.

Away), revision steps 3 and 4 are required.

5. If the MBS context is not available in the (MB) -SMF, the (MB) -SMF interacts with the UDM to check if there is a multicast context in the system for the multicast group.

6. The (MB) -SMF uses the namf_n1n2messagetransfer service request AMF to deliver a message to the RAN node to create a multicast context in the RAN (if it does not already exist). If the UE needs to find the MBSU/MBS-U, the IP address of the MBSU/MBS-U may be included.

7. An N2 session modification request is sent to the RAN.

The ran sends an RRC reconfiguration request message to the UE.

9. If the UE is allowed to access MBS services, the UE derives a Multicast User Key (MUK) from Kasuf and uses multicast_group_ID as an input parameter.

The editor annotates: the MUK derivation is FFS.

The editor annotates: the key update procedure after re-authentication is FFS.

The smf requests the MUK and sends multicast_group_id to the AUSF.

Ausf derives a Multicast User Key (MUK) based on Kasuf and multicast_group_id.

Ausf responds to SMF with MUK.

SMF distributes MUK to MBSU/MSF-U.

The MBSU/MSF-U receives and stores MUKs. Thereafter, an ACK is responded to the SMF.

15. The multicast service initiation procedure continues.

The MBS U/MSF-U checks if MBS security context for the multicast group is available. The MBS security context is used for MBS service protection and comprises key_ID, K_group_enc, K_group_int, encryption and integrity algorithm. The key_id is used to indicate the key pair used. The K_group_enc and the K_group_int are used for encryption and integrity protection of MBS services respectively.

If not, the MBSU/MSF-U generates K_group and derives K_group_enc and K_group_int. Encryption and integrity algorithms are selected.

The ue computes a token based on the MUK and requests a service key from the mbs U/MSF-U.

The editor annotates: the token construct is FFS.

The MBSU/MSF-U uses the MUK authentication token and, if successful, distributes the MBS security context to the UE.

The editor annotates: the message name and flow may be updated to stay consistent with the conclusions of SA2 and RAN WG.

The editor annotates: the roaming aspect is FFS.

6.2.2.1 MBS Security content for efficient group Key distribution and updating

This section explains the logic of step 18 in fig. 6.2.2.1.

A multicast group with N members is divided into M sets s_i, where i= {1, M }. Each set has approximately L to N/M UEs. Each UE has three keys: a device-specific key MUK; a transmission key K_transport_i shared with other L-1 devices in the same set; a group key shared with all N devices and used to protect multicast content. The MUK is used to securely deliver the transmission key in a point-to-point connection. The transport key is used to securely deliver the group key in a multicast manner. The key hierarchy is shown below, with the arrows indicating protection.

MUK->K_transport_i->K_group

E { K1; k2} represents that the key K2 is authentication-encrypted with the key K1 and is used to indicate secure delivery of the key.

The distribution and updating of the group key is done by two messages:

message 18a: the UE receives the key transmission for the set to which it belongs to protect with the UE's MUK.

The UE first verifies the message authentication code and if correct decrypts its transmission key. Freshness can be achieved in a variety of ways. For example, an increased initialization vector may be used that depends on the initial access token exchanged in step 17.

Message 18b: the new group key is distributed by protecting the new group key with the transmission key in the point-to-point or multicast message. Containing a hash of the group key.

The UE first searches for the portion of the message that is addressed to its set. For example, if the UE belongs to set z, the UE needs to find E { k_transport_z; k_group }. The UE then verifies the message authentication code and if correct decrypts the new group key. Freshness can be achieved by using the same freshness counter as used for content data distribution. Finally, the UE also checks whether the hash of the decrypted key is equal to the hash H of the group key appended to the end of the message.

These two messages can be combined to handle different situations:

1. initial key distribution to UE: the UE is provided with its transmission key and group key in the same message that combines 18a and 18 b.

2. Key updates triggered by too long a key set usage time: message 18b is used to distribute the new group key to all UEs.

3. Key updates triggered by new devices joining the group: message 18a is used to deliver the corresponding transmission key to the new UE. Message 18b is then used to distribute the new group key to all UEs.

4. Key update triggered by UE leave/revoked: if the UE leaves or is revoked, the transmission keys and group keys associated with its set are destroyed. To handle this, message 18a is sent to L-1 in its set to update the transmission key. Message 18b is then used to distribute the new group key to all UEs.

This method is efficient and resilient as follows:

updating the group key due to device departure requires only L-1+ m messages, not N messages as would be required if only point-to-point messages were involved. For example, if n=1600, m=40, l=40, then the key update requires only 39 point-to-point messages for transmitting the key update, and 40 messages for group key update.

Since M transmission keys are used, an attacker that breaks the UE can only attempt to update the group key of up to L-1 devices. This limits the impact of such attacks, in particular in comparison with the case where a single key is used to transfer the group key, where N-1 may be affected. Further, a hash of the group key is included in message 18b so that devices in other sets can check for consistency, detect attacks, and notify 5MBS. In this sense, this solution is M-elastic.

Reference is made below to the editor notes of solution 2 in TR 33.850-040 for UE re-authentication. The procedure during UE re-authentication is as follows:

step 0: the UE starts the re-authentication procedure and proceeds to step 1.

Step 1: during the re-authentication process:

step 1.1: the UE attempts to process the incoming protected MBS service using its known group key. If successful, step 2 is entered.

Step 1.2: if the UE cannot handle the incoming protected MBS service, the UE attempts to access the new group key periodically distributed in message 18b by using its previous transmission key. If the UE is successful, the UE accesses the new group key and proceeds to step 2.

Step 1.3: the UE waits for the delivery of new transmission keys and group keys. These two keys are delivered via messages 18a and 18 b. These keys will only be delivered if the re-authentication and re-authorization procedure is successful and MUK protection is utilized. Once the UE receives these keys, the UE proceeds to step 3, otherwise proceeds to step 2.

Step 2: the UE is not authenticated or authorized to access MBS services.

Step 3: the UE has the current group key and the transmission key and can access the protected MBS service and any group key updates.

We note that step 1.2 requires that the update of the new group key protected with the set (transport) key is not protected with the old group key. We note that it is advantageous not to do so when it is desired to optimise the key update procedure during UE re-authentication.

We note that the above procedure is optimized to improve the user experience, since by trying to use the group key and the transport key that the UE already has, the UE can try to access MBS services even before the UE is re-authenticated. This is done in step 1.1 and step 1.2. If these keys are active, the UE can directly access the traffic. If these keys are not functional, they may be for two reasons. The first reason is to update the key due to periodic key updates or other UEs leaving the multicast group. The second reason is that the UE itself is no longer allowed and it should not access MBS services.

It is noted that if no transmission key is used, step 1.2 above should be skipped and step 1.3 only contains message 18a.

The key hierarchy described in the above embodiments uses M different transport keys (k_transport_i) for updating the group key. Thus, this approach reduces the number of unicast messages/point-to-point interactions required to update the transmission key from N to N/M. The group key may then be updated by sending a new group key that is protected with M different transmission keys. This approach significantly reduces signaling overhead if the UE frequently leaves or joins MBS groups and in these cases applies security requiring updating of group keys. The reason is that if there is only a single transmission key (as is the case for LTE), the transmission key will be required to be updated, requiring N unicast interactions. Once the transmission key is updated, a group key, for example, protected with a new transmission key, may be distributed. In contrast, having M transport keys means that N/M-1 unicast messages are required to update the corrupted keys, and that M protected group keys need to be distributed over the multicast channel, thus requiring a total of N/M-1+M keys to be sent. When M is approximately SQRT (N), this is approximately equal to 2 x SQRT (N). Problems may occur in settings where the members of the MBS group are rather static (do not leave or join) and a policy is applied that requires the group key to rotate (rotate) very frequently. In such a setup, the approach presented above in the context of solution #2 in TR33.850 may have a higher overhead, as multiple transmission keys are used to protect the new group key. To solve this problem, a slightly more complex key hierarchy may be applied, which may be regarded as a combination of the key hierarchy in MBMS (LTE solution) and the key hierarchy set forth above. In this new key hierarchy, there are m+1 transport keys:

M transmission "set" keys (k_transport_i) as described above, i.e. each of these transmission keys is composed of l=n/M

Disjoint sets of individual UEs are used.

1 transmission "public" key (k_transport_common), which is common to all UEs.

In this setting, if:

MBS group UE members remain static and the group keys need to be rotated frequently and then the new group keys are securely distributed using the transmission "public" key. This is secure because the UE members have not changed and therefore all m+1 transmission keys remain valid. This is efficient because the updated group key is securely sent using a single key.

The MBS group UE members are dynamic, L-1 unicast messages are used to update "corrupted" when the UE leaves or joins "

The "set" key is transmitted. Recall that these L-1 messages are protected using UE-specific MUK keys. The new group key and the new transmission "public" key are then updated by sending these two keys, protected with M transmission "set" keys, via the multicast channel. Alternatively, the new transmission "public" key is updated by protecting it with M transmission "set" keys via the multicast channel, and then the new transmission "public" is also used via the multicast channel "

The key updates the new group key.

Fig. 15 depicts the associated key hierarchy. The first is the key hierarchy used in LTE, which is also used in solution 12 in TR 33.850. Here, each UE has a MUK for securely receiving the MSK through a unicast channel. The MSK is common to all UEs and may be used to distribute the MTK, i.e. the group key, to all UEs over the multicast channel. The second (key hierarchy a) refers to the default solution described above when no transmission key is used. In this key hierarchy, the MTK is directly updated with a UE-specific unique key. The third (key hierarchy B) has a plurality of M MTKs associated with disjoint sets of up to L UEs. The UE securely receives its MSK using the device-specific MUK. The MTK is then distributed using all M MSKs. The fourth (key hierarchy C) is the key hierarchy described above, where there are M MSKs, each of which binds to a disjoint set of up to L UEs (transmit "set" keys) and 1 MSK common to all UEs (transmit "common" keys). The key hierarchy in fig. 15 may be applied to solution #12 in TR 33.850 or other service layer solutions in this 3GPP study, for example.

The entity protecting the MBS service (e.g. NF or NF s interacting with each other) will manage the key hierarchy and the policies responsible for determining the update frequency of the keys and in which cases the updates:

periodic key updates of the group key, including e.g. frequency or maximum usage.

Periodic key updates that transmit the "public" key, including frequency or maximum usage.

Update of the transmission "set" key when UE leaves or joins.

Updates of the transmission "public" key and/or group key when the UE leaves or joins.

In TR 33.850, authentication and authorization is within the scope of critical issue # 1. The protection of MBS service is in the range of critical issue # 3. In the above solution the procedure of re-authentication only depends on the implementation of solution 2, however, (re) authentication will be handled as part of a different solution. For example, in TR 33.850-040, solution 6 performs authentication and authorization for multicast communication services. Solution 6 does this based on k_akma. In particular, the key k_mbs is derived from k_akma and used for authentication and authorization. In other solutions (e.g., solution 2), the device key MUK is used to deliver the group key. In this case, the MUK is derived from K_ausf. The next problem to be solved is how to put together solutions in TR 33.850 that solve different key problems (e.g. ki#1 and ki#3) but eventually need to work together.

To solve this problem, it is required to describe keys for authentication/authorization and keys for delivering key updates in the associated key hierarchy. In an embodiment that solves this problem, this is done as follows:

K_AUSF
		↓
K_AKMA
		↓
K_MBS
		↓	↓
K_MBS_Authentication_Authorization	K_MUK

k_akma is derived from k_ausf described in 3GPP TS 33.535 16.0.0 version 16. The k_akma is then used to derive the master k_mbs key for the UE and the given MBS service. From the k_mbs key, two keys are derived. The first key k_mbs_authentication_authorization is used for Authentication and Authorization procedures, for example in solution 6 of TR 33.850. This means that in solution 6, an additional key derivation step is missing in k_mbs. The second key k_muk is used to deliver a group key for protecting multicast traffic. For example, the k_muk appears in solution 2, which means that solution 2 should be modified to derive k_muk from k_mbs and k_akma, instead of directly from k_ausf. We note that when deriving some of the keys described above (e.g., k_muks), a counter c may be used as an input to a key derivation function to obtain multiple k_muks within the current authentication and authorization session.

An alternative to the above key hierarchy is as follows:

K_AUSF
	↓
K_AKMA
	↓
K_MBS
	↓
K_MUK

The difference here is that k_muk (for solution 2) is derived from k_mbs (for solution 6). In particular, the k_muk may be derived from the k_mbs, information exchanged during the authentication and authorization procedure, and the counter c. The counter allows deriving a plurality of k_muks when the key needs to be rotated in the current authentication and authorization session.

We note that if the UE re-authenticates, the key hierarchy described above does not describe whether the k_muk should change. In the case of re-authentication, triggering an update of the k_muk is an option. This can be done by the counter c described above.

We note that in case of UE re-authentication, the MUK may need to be changed even if the key hierarchy k_ausf→muk is maintained as in solution 2. The main reason is that the re-authentication may trigger an update of the k_ausf itself. TS 33.501-a.2 describes the procedure of k_ausf generation and it depends on e.g. the service network name. If this happens, maintaining the same MUK as proposed in proposal S3-210919 submitted to 3GPP SA3#102-e-Bis may lead to synchronization problems. For example, suppose that the UE joins the MBS service by authenticating and generating the first MUK key. The UE is then idle for a long time. Later, the UE rejoins triggering its re-authentication. However, it is assumed that the UE or the core network may have deleted the old MUK, for example, because the UE is idle for a long time. If only one party has removed the old MUK, that party will generate a new MUK. However, if the k_ausf has changed due to the re-authentication procedure (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 key used for distributing the transmission key or the group key should be updated after (re) authentication.

After k_muk, if the UE is using a solution using the set key (or transmission key), the corresponding set key may also require updating. The same is true for the group key used to protect MBS services. However, doing so may result in high signaling overhead. In general, the better approach is to keep the following independent: (i) Keys for authenticating/authorizing and distributing the set/group keys; and (ii) a set key and an MBS group key. In particular, the set key and the MBS group key may need to be updated only when the UE's re-authentication procedure fails.

The solution presented here may be considered as an in-band key update mechanism. However, some solutions split the control plane and the user plane. The control plane is used to deliver updates of the key set, while the user plane is responsible for delivering multicast traffic. This split occurs, for example, in solution 8, e.g., TR 33.850-040. In this solution, the (MB) -SMF solution is responsible for generating the group key (MTK) and the corresponding Key Identifier (KID). The key and identifier are later shared with the MBSF-U in the core network. The key and identifier are later shared with the UE over the control channel. The content provider delivers the multicast data to the MBSF-U, which is responsible for distributing the multicast data to all UEs connected to the service through the user plane. This is done by protecting the multicast data with the group key.

In the case of a key update, all N UEs subscribed to the service need to obtain the key update. As discussed in this document, this may involve many communication resources, not only because each UE needs to be notified, but also because each UE should also acknowledge the correct reception of the key update.

The ideas in this embodiment can also be applied to this solution that improves the split involving the user plane and the control MBS plane. When the group key is scheduled, the following operations will be performed:

step 1, (MB-) SMF generates a new group key.

Step 2, if the UE has left the MBS, has been revoked, etc., the (MB-) SMF also generates a new set key corresponding to the set of devices to which the UE belongs. The (MB-) SMF distributes a new set key to the (M-1) devices in the set through the control plane, which will be used to securely transfer the new group key. This message is equivalent to message 18a in solution 2 in TR 33.850.

Step 3, (MB-) SMF shares the new group key (as shown in the current description) with the MBSF-U and the key update message, where the new key group is protected with L group keys. This is equivalent to message 18b in solution 2 in TR 33.850.

Step 4, when the MBSF-U receives the key update, by sending this information in-band along with the regular multicast content, the MBSF-U first distributes the key update, i.e. the new group key protected with L group keys (equivalent to message 18b in solution 2 in TR 33.850). Thus, the information is protected with the current group key. This may be done multiple times to ensure that the UE receives the key update.

Step 5, mbsf-U may switch to use the new group key.

In an extension of the above procedure, the UE may also inform (MB-) SMF that such a key update is received when the UE gets a key update message in step 4. In this extension, (MB-) SMF will wait for most of the UEs to have acknowledged receipt of the key update or the timer expires, and then notify the MBSF-U of this event triggering the group key handover (step 5 above).

If the previous extension is applied, only the key update message may be included in step 3, and the delivery of the new group key may be delayed until such time as the (MB-) SMF informs the MBSF-U UE that most of the key updates have been received.

If the previous extension is applied, then "majority of the UEs" means a given percentage of N UEs subscribing to MBS services, e.g., 99% of the UEs. For the rest of the UEs, (MB-) SMF may choose to connect directly over the control channel. Similarly, "timer timeout" means that the MBSF-U has distributed the key update message for a sufficiently long period of time and should directly contact the UE that has not acknowledged receipt of the message over the control channel.

We note that this split applies to the delivery of the set key (or transport key) delivered over the control channel and the delivery of the group key delivered in-band over the user plane. Any parameter (N, M, L) may be done in the solution, in particular if there is a single set/transmission key.

In SA3#102-e-Bis, scheme S3-210857 provides a framework for secure key distribution. The framework defines the input and output of two key derivation functions that generate two broadcast keys (i.e., kmtet and KMTint) for encryption and integrity protection. Inputs to each of the KDFs include: 1) update key token, 2) multicast group token, 3) algorithm identifier, and 4) Temporary Mobile Group Identifier (TMGI). The network provides 2) and 4) to the UE in a secure manner, in particular by means of a secure RRC message. The UE and RAN may then generate the same kmtent and KMTint. If an update key is required, the network may provide an update key token to the UE so that both the UE and the RAN may generate new multicast keys kmtent and KMTint. Note that in this solution, element 2) the multicast group token plays the role of the master multicast key. Thus, the parameter should be generated in a safe manner and be long enough. The proposal S3-210857 may also benefit from the method described in the present application to reduce the amount of signaling messages. In particular, if a new multicast key needs to be generated by the UE, the proposal S3-210857 requires that N security messages be sent to each UE, including a new updated key token. Although updating the key token does not require confidentiality protection, it does require integrity protection. Instead of sending N integrity protection messages, N UEs may be divided into a set of m=n/L devices. Each set of devices has a different set key or transmission key. These transport keys are used to deliver the elements when required by the set of devices that remain unchanged. This delivery is done in multicast mode. If the set of devices has changed (new UE has joined/left), then the new transmission key and any of the above elements may be delivered through RRC-protected messages.

We note that in this solution, if the UE leaves the group, the leaving UE knows the multicast group token that is used as the master key. One way to apply the method described in this specification to this solution is to use a different updated key token for each base station. If a different update key token is used (i.e., the update key material is a function of the base station), only the update key token of the base station from which the UE was away needs to be updated. Otherwise, if the same update key token is used in all base stations, leaving the MBS group when the UE is located in a particular base station will force the 5GS to update all UEs in all base stations. This is inefficient and involves more signalling overhead.

In this particular solution (as well as S3-210857 and other solutions to update MBS encryption and integrity keys over control channels), once the update key token is sent to the UE over multiple RRC messages, new k_mt_enc and k_mt_int should be used. Old k_mt_enc and k_mt_int keys and new keys may need to be active for a period of time. When the base station starts to use a new MBS encryption and integrity key, the base station (or an entity protecting and transmitting the MBS service) may indicate the key switch to the UE by including an identifier of the MBS encryption and integrity key in the multicast data (user plane). Alternatively, the base station may use and flip a single bit in the multicast data channel to indicate a handoff from the old key to the new key.

We note that this proposal S3-210857 has two design drawbacks because it declares the RRC message encrypted in message 8 in fig. 6.X.2.2-1 and message 7 in fig. 6. X.2.3-1. The proposal does not mention integrity protection. In the case of message 8, the distribution of element 2) requires encryption. However, integrity protection is also necessary, as otherwise the message may be modified and service to the UE may be denied. In the case of message 7, the requirements are also integrity protection and freshness. If element 1) is a counter, the counter may be public, but the recipient needs to be able to verify its integrity and freshness.

It is noted that in the present proposal S3-210857, if 1) is a counter, the UE that has been revoked can still access MBS service even if the counter changes, since the UE only needs to update its counter. Thus, the update key token must be long enough (e.g., 128 bits or longer) and must be randomly generated. Shorter updated key tokens (e.g., 32 bits or 64 bits) are not sufficient because an attacker can pre-compute the key in advance and then pick up the correct key when distributing the updated key token. The attacker can also record the traffic and decrypt it at a later point in time.

In SA3#102-e-Bis, proposal S3-211144 provides another solution for generating MBS keys. This solution is similar to S3-210857 in that MBS encryption and integrity keys are derived from master keys from multiple parameters including counters and random values, rather than distributing new keys as needed. As in the case of S3-210857, this solution may also benefit from the method described in the present application to reduce the amount of signaling messages. For example, the set of keys may correspond to UEs receiving MBS services through a specific base station. Devices in the same set share a set key or a transmission key. When it is required to update the MBS encryption and integrity keys (KMRB-int and KMRB-enc in fig. 6.X.2.1-1 in S3-211144) in all UEs in the base station, the base station delivers parameters required for updating KMRB-int and KMRB-enc, e.g., RANDMBS and CountMBS, through multicast channel MRB (PTM). These parameters are protected with a corresponding transmission key.

Next, we note that S3-211144 assumes a key hierarchy in which KMBS is the master key delivered to the RAN. From this key, the gNB-specific key is generated as follows:

KMBS-RAN＝KDF{KMBS,TMGI,RANDMBS,CountMBS,PCI,ARFCN-DL}

the use of PCI and ARFCN-DL binds the key to a particular RAN cell. However, this has a great disadvantage in that if the UE leaves the MBS group or is revoked, the keys in all the base stations delivering the MBS service need to be updated. This results in a large signaling overhead. This is because the same master key is used for all base stations delivering a given MBS service. In this case, as well as in other systems, this can be improved by several ways:

Each base station randomly generates a different gNB-specific key KMBS-RAN.

The key hierarchy includes intermediate levels related to tracking areas, e.g., intermediate levels between the RAN and KMBS. The intermediate key KMBS-TA is tracking area specific and is intended to reduce the impact of key updates.

The UE does not receive KMBS but only the gNB specific key KMBS-RAN or intermediate keys, e.g. KMBS-TA in messages 5 and 11 in fig. 6.A.2.1-1 in S3-211144.

We note that if the UE cannot access 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.

It should be noted that due to

(i)K _MBS-RAN Calculated as KDF { K _MBS ,TMGI,RAND _MBS ,Count _MBS ,PCI,ARFCN-DL}，

(ii) If the UE leaves the group, K _MBS-RAN Depending on RAND only _MBS Security, and

(iii) K of gNB with leaving/revoked UE only _MBS-RAN There is a need for an update that,

therefore, the k_mbs is not required. The same applies to the proposal of multicast group tokens in S3-210857.

Furthermore:

1. this solution is essentially equivalent to securely handling RAND _MBS The solution (keys for RAN) is distributed directly to the UE as shown in equation (0) to derive from it k_mrb-int and k_mrb-enc as described in (1), (2), (3).

RRC(RAND _MBS ,TMGI,Count _MBS ,PCI,ARFCN-DL)(0)

In this method, the UE receives and examines all other parameters individually, i.e., TMGI, count _MBS PCI, ARFCN-DL. Alternatively, K _MBS-RAN Or may 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 discriminator value, algorithm identifier value } (2)

K _MRB-int ＝KDF{K _MBS-RAN Algorithm type discriminator value, algorithm identifier value } (3)

In (1), the K_MBS is removed compared to the current text in S3-211144, as security is not dependent on it.

3. In another alternative solution, the KDF operation may also be skipped and K may be added _MRB-enc And K _MRB-int Calculated as (4) and (5):

K _MRB-enc ＝KDF{TMGI,RAND _MBS ,Count _MBS ,PCI,ARFCN-DL,K _MBS-RAN algorithm type differentiator value, algorithm identifier value } (4) K _MRB-int ＝KDF{TMGI,RAND _MBS ,Count _MBS ,PCI,ARFCN-DL,K _MBS-RAN Algorithm type discriminator value, algorithm identifier value } (5)

Wherein all parameters are distributed to the UE by message (0).

In (1), (4) and (5), PCI can be removed because the message is distributed in an RRC message from the particular base station.

In SA3#102-e-Bis, proposal S3-210918 provides another solution for generating MBS keys, which is somewhat similar to solution 8 in TR 33.850. In this new solution, the MBSF-C generates a new group key (MTK 2) and the new group key (MTK 2) is distributed to the MBSF-U and (MB) -SMF. The (MB) -SMF is responsible for delivering this new key to the UE via unicast signaling messages. Once completed, (MB) -SMF informs MBSF-U. After this notification, the MBSF-U starts to use the key MTK2 to protect MBS data. This solution may benefit from the described embodiments to reduce signaling overhead. In particular, MBSF-C or (MB) -SMF may distribute UEs into sets, each set being associated with a respective transmission key. Thus, the new group key MTK2 may be distributed over the multicast stream to UEs that are protected with this transmission key and still protected with the old MTK2 key. When the UE receives the update, the UE informs (MB) -SMF that all UEs that know the new key will be tracked. For those UEs that do not respond, (MB) -SMF may use the unicast key update modification set forth in S3-210918. Once the (MB) -SMF has ensured that most of the UEs registered to the MBs service have received the new MTK2 key, the (MB) -SMF sends an MTK activation notification to the MBSF-U.

We note that proposal S3-210918 assumes in step 6 (key update notification) that the unidirectional link is from (MB) -SMF to UE. This may be insufficient because the UE may miss the signaling message, and this may cause interruption of reception of MBS data. We note that the current proposal may require a policy at (MB) -SMF describing how to handle when a certain percentage of UEs have not acknowledged receipt of the key update notification message. In particular, the policy may include a relative or absolute number of UEs that may not have acknowledged receipt of the message before the MTK activation notification is sent to the MBSF-U. The policy may also include a timer that triggers the notification to be sent if it expires. The policy may also define how UEs that do not acknowledge the key update notification should be managed, e.g. how many times the message should be sent.

In SA3#102-e-Bis, proposal S3-211070 provides another solution for the generation and distribution of MBS keys and MBS services. The solution relies on three keys: MUK (device specific key), MSK, and MTK. The MUK is used to distribute the MSK in unicast messages over the secure connection. MTK is protected by MSK. The MTK may be delivered in unicast or multicast messages. The MTK or a key derived therefrom is used to protect MBS data. The proposal S3-211070 is similar to the ideas disclosed in this document. The main difference is that S3-211070 appears to include a single MSK. If the UEs in MBS service are divided into M sets, each using a different MSK, S3-211070 may benefit from the ideas in this document. For this purpose, delivery of multicast traffic keys is required to contain MTKs encrypted with different MSKs. This solution uses a key hierarchy to derive MUKs from KAFs with AKMA, as previously described in this document (KAUSF- > KAKMA- > KMBS (KAF) - > MUKs).

These means may be implemented by a computer program and/or program code means, respectively, being dedicated hardware of the relevant device. The computer program may be 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 may also be distributed in other forms, such as via the internet or other wired or wireless telecommunication systems.

Reference to the literature

[1]TR 23.757v1.0.0

[2]TR 33.850v0.2.0

[3] TS 33.246-g00 3 (MBMS security)

[4]https://itectec.com/spec/4-2-key-management-overview/

Claims (22)

1. A method for a primary station to distribute cryptographic keys to a plurality of secondary stations, comprising the steps of:

a. determining whether a group key is required to be updated, the group key being used for multicasting protected communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, the updated cryptographic key is sent to at least a subset of the secondary stations via an encrypted message.

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

3. The method of claim 1, wherein determining whether a 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 expired, the validity time of the group key has expired, at least one of the secondary stations has left a predetermined location.

4. The method of claim 1, wherein the updated cryptographic key is a first set key shared to a first set of secondary stations.

5. The method of claim 4, wherein the first set key is updated upon determining at step a that the access rights of at least one of the secondary stations belonging to the first set are currently invalid.

6. The method of claim 5, further comprising the step of: the updated group key is sent to each set of secondary stations by a message protected with a respective set key associated with each set of secondary stations.

7. A method for a primary station to distribute cryptographic keys to a plurality of secondary stations, comprising the steps of:

a. Determining whether a group key is required to be updated, the group key being used for protected multicast communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, the updated group key is sent to the respective set of secondary stations in a respective multicast message that is secured by the respective set key associated with each respective set.

8. The method of claim 7, wherein determining whether a 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 station has been revoked,

at least one of the access rights of the secondary station has expired,

the validity time of the group key has expired,

-at least one of the secondary stations has left a predetermined position.

9. The method of claim 7 or 8, further comprising: if it is determined at step a that the group key is not associated with an access grant invalidation of a first secondary station belonging to a first set of secondary stations, a new first set key is sent by unicast to each secondary station in the first set by means of a protected unicast message.

10. The method of claim 9, further comprising step c: the updated group key is sent to the first set of secondary stations in a multicast message, which is encrypted with the new first set key.

11. The method of claim 9, wherein the protected unicast message further comprises an updated group key.

12. A method for a primary station to distribute cryptographic keys to a plurality of secondary stations, comprising the steps of:

a. determining whether a group key is required to be updated, the group key being used for protected multicast communications from the primary station to the plurality of secondary stations,

b. upon determining that an update is required, transmitting a first set key by unicast to at least a first subset of the secondary stations via a protected unicast message,

c. transmitting an updated group key to the first set of secondary stations in a multicast message, the multicast message being protected by the first set key, or alternatively including the updated group key in the protected unicast message of step b,

d. the updated group key is sent to the further respective sets of secondary stations in respective multicast messages protected by respective set keys associated with each respective set.

13. The method of any of claims 7-10, wherein the set of secondary stations is formed based on location, and wherein step d further comprises: the master station transmits the updated group key in at least one further multicast message encrypted by a corresponding set key used in the adjacent set.

14. The method of claim 13, wherein the neighbor set is a set of a plurality of secondary stations camping in a cell served by another primary station.

15. The method of any preceding claim, wherein the multicast message is retransmitted periodically.

16. The method of any of claims 7-15, wherein the multicast message includes the updated group key and an authentication fingerprint message calculated as a hash of the updated group key.

17. A method for a secondary station to receive a cryptographic key in a network, comprising the steps of:

a. receiving a first set key from a primary station via unicast via a protected unicast message, the first key being associated with a first set of secondary stations,

b. and receiving a multicast message of the first set of secondary stations and decrypting the multicast message into an updated group key, the decrypting using the first set key.

18. The method of claim 17, wherein the multicast message includes a protected updated group key and an authentication fingerprint message, and the method further comprises the secondary station authenticating the multicast message by checking whether a hash of the decrypted group key matches the received authentication fingerprint.

19. The method of claim 18, further comprising: if the check fails, an exception is reported to the master station.

20. A primary station operating in a cellular network and in communication with a plurality of secondary stations, comprising:

a controller adapted to determine whether a group key is required to be updated, the group key being for protected multicast communication from the primary station to the plurality of secondary stations,

a transmitter coupled to the controller is adapted to send the updated group key to a respective set of secondary stations in a respective multicast message, the multicast message being protected by a respective set key associated with each respective set, upon determining that an update is required.

21. A secondary station operating in a cellular network and in communication with a primary station, comprising: a receiver adapted to receive a first set key from a primary station by unicast over a protected unicast message, the first key being associated with a first set of secondary stations; and a controller adapted to decrypt multicast messages to the first set of secondary stations into updated group keys, the decrypting using the first set key.

22. A computer program stored and/or distributed on a suitable medium, such as an optical storage medium or a solid state medium, provided together with or as part of other hardware, but which can also be distributed in other forms, such as via the internet or other wired or wireless telecommunication systems, and/or as program code elements of special purpose hardware.