CN116830533A - 用于分发多播加密密钥的方法和设备 - Google Patents

Abstract

本发明涉及一种用于主站向多个次站分发加密密钥的方法。该方法包括以下步骤：确定组密钥是否需要被更新，所述组密钥用于从主站到多个次站的多播经加密的通信，在确定要求更新时，通过经加密的单播消息向次站的至少一个第一子集通过单播发送第一集合密钥，在多播消息中向次站的第一集合发送更新后的组密钥，所述多播消息通过第一集合密钥来加密，或者替代地在携带第一步骤密钥的经加密的单播消息中包括所述更新后的组密钥，在相应的多播消息中向次站的另外的相应集合发送更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来加密。

Description

用于分发多播加密密钥的方法和设备

技术领域

本发明涉及无线通信的领域，并且特别地涉及在主站(例如，基站)与至少一个次站(例如，形成网络的终端或移动站)之间的通信的安全方面。其他实体(例如，安全实体)可以存在于这样的网络中。

背景技术

在无线网络中，终端连接到网络以交换数据。安全性对于不要求物理交互以访问网络的无线设备特别重要。此外，加密允许控制对诸如多媒体流之类的资源的访问。因此，无线网络必须实现一些措施，以使得能够排除网络中未授权的设备。3GPP是负责移动电信系统全球解决方案标准化的组织。在3GPP伙伴关系中开发的电信系统也不例外。特别是在5G中，正在讨论安全措施以加强网络的安全性。

5G多播广播服务(5MBS)允许订户访问数据流，特别是多媒体数据流。典型的应用是在现场活动(例如，体育场中的现场活动(运动会、音乐会))期间流式传输视频和进一步的信息，例如，重放视频或附加信息或增强性能。一个重要的方面是确保所有订户且只有订户可以访问服务。因此，通过在所有用户的终端之间共享的组加密密钥来对流进行加密。

然而，关于当前提出的解决方案发现了不同的问题。作为背景的一部分，总结如下：

-背景1：针对5G r17的5MBS通信架构

-背景2：5MBS当前安全关键问题及解决方案

-背景3：针对5G r16的MBMS安全架构。

背景1：针对5G r17的5MBS通信架构

TR 23.757v1.0.1(以下称为[1])描述了针对5G的5G多播广播服务(简称5MBS)(第17版)的架构增强研究。在[1]的第4节中，描述了架构假设和原则，以下文本改编自第4节：

首先，5MBS应用以下通用架构要求和原则：

-解决方案应建立在TS 23.501(以下称为[2])中的5G系统架构原则之上，包括针对新引入功能的灵活性和模块性。

-系统应为各种多播和广播服务提供高效的传输。

-解决方案应使对现有外部服务的影响最小化。

-在TS 23.501[2]条款4.2中定义的架构参考模型用作本研究中支持多播和广播服务的基线架构。特别地，图1示出了具有5G UE、NG-RAN和5GC的高级MBS架构。

此外，对互联网协议电视(IPTV)有一些特定要求：

-对IPTV的解决方案应使对IPTV网络和机顶盒(STB)的影响最小化。

-对IPTV STB的解决方案应经由用户平面重用IGMP/MLD消息以加入/离开IPTV频道组。

-对IPTV的解决方案应为UE加入/离开IP频道组提供高效的机制，包括减少延时和信令。

建立和递送MBS会话的序列假设如下：

1.可选地将5G MBS服务信息从应用/服务层递送到5GC。注意，用于将5G MBS服务信息递送到5G CN(核心网)的框架是可用的。然而，该步骤可以在没有明确信令的情况下由预先协定代替。

2.UE参与接收MBS流，即，UE请求加入MBS会话(用于多播会话)。

3.建立MBS流传输。注意，对于加入已经开始的MBS会话的个体UE，该步骤可能发生在步骤2之前。

4.将MBS数据递送到UE。

5.UE停止接收MBS流(用于多播会话)。

6.释放MBS流传输(其曾经是会话停止)。

MBS业务需要从单个数据源(应用服务提供商)递送到多个UE。取决于许多因素，可以使用多种递送方法来递送5GS中的MBS业务。为了清楚起见，递送方法不称为单播/多播/广播，而是如下所述。

从5G CN的角度而言，两种递送方法是可能的：

-5GC个体MBS业务递送方法：5G CN接收MBS数据分组的单个副本，并经由每UE PDU

会话向个体UE递送这些MBS数据分组的单独副本。

-5GC共享MBS业务递送方法：5G CN接收MBS数据分组的单个副本，并将这些MBS

数据分组的单个副本递送到RAN节点，该RAN节点随后将这些副本递送到一个或多个UE。

如果支持5GC个体MBS业务递送方法，则CN可以针对一些UE经由5GC个体MBS业务递送方法并且针对其他UE经由5GC共享MBS业务递送方法来递送MBS数据分组的相同的接收到的单个副本。

从RAN的观点而言，(在共享递送的情况下)两种递送方法可用于通过无线电传输MBS分组流：

-点到点(PTP)递送方法：RAN节点通过无线电将MBS数据分组的单独副本递送到个体UE。

-点到多点(PTM)递送方法：RAN节点通过无线电将MBS数据分组的单个副本递送到UE的集合。

这里注意，RAN节点可以使用PTP/PTM的组合来将MBS分组递送到UE。如图2中描绘的，对于5G MBS会话，取决于所选的解决方案，可以同时使用共享PTP或PTM递送方法和个体递送方法。

在[1]的附件A.1中，描述了5MBS参考架构的替代方案。特别地，考虑了传输层和服务层方面。下面以A.1.1和A.1.2的名称表示。

A.1.1.参考架构的传输层方面：

图3示出了用于集成多播传输和单播的5G系统架构。该解决方案依赖于增强现有的5GS网络功能(NG-RAN和UE目前只支持单播传输)以支持多播传输。

以下新功能被添加到当前的AF、5GC NFS(网络功能)、NG-RAN和UE中：

-应用功能(AF)：

-支持MBS服务功能，与NEF协商以进行服务暴露。

-网络暴露功能(NEF)：

-5G MBS服务暴露。

-与AF协商5G MBS服务，包括QoS、5G MBS服务区域。

-策略控制功能(PCF)：

-针对多播服务的支持策略，包括QoS参数，如5QI、MBR、GBR。

-向SMF提供关于MBS会话的策略信息。

-从AF直接(运营商拥有)或经由NEF间接地接收MBS服务信息。

-会话管理功能(SMF)：

-基于从PCF接收到的MBS策略来控制MBS传输。

-针对MBS流和点到点或点到多点传送配置用户平面功能(UPF)。

-针对MBS流和QoS信息配置RAN。

-针对MBS流在UE处进行SM配置。

-SMF可以用于单播和MBS。

-用户平面功能(UPF)：

-支持MBS流的分组过滤，以及经由点到点或点到多点N3将MBS流递送到RAN。

-从SMF接收5G MBS流配置。

-检测互联网组管理协议(IGMP)分组并通知SMF(如果经由IGMP执行UE加入)。

-UPF可以接收单播和MBS流两者。

-I-UPF可以用于将MBS流从附接到N6的UPF递送到NG-RAN；N9接口可以用于MBS

业务递送。

-NG-RAN：

-经由N3接收MBS流并通过空中递送(delivery over-the-air)。

-在MBS流的多播和单播递送之间切换。

-针对AS层处的MBS流接收进行UE配置。

-UE：

-支持UE策略配置扩展到MBS。

-支持针对MBS流的SM扩展。

-用于加入MBS流的信令(经由SM信令或用户平面IGMP加入)。

-在AS层处支持MBS。

A.1.2参考架构的服务层方面：正交于传输层处的多播流用户平面模型的描述，可以在顶部支持服务层。服务层与多播传输完全分离。这允许不要求服务层的应用直接经由Nnef(控制平面和N6(用户平面数据))建立多播传输。

图4示出了使用xMB/MB2作为入口点的多播/广播的服务层支持的示例。介绍了新的网络功能，称为多播服务功能(MSF)。MSF只提供服务层功能，并(经由Npcf或Nnef)向5G系统请求多播服务所需的底层多播传输。MSF具有以下功能：

-用于控制平面服务层信令和用户平面数据两者的入口点，例如，xMB/MB2。可以直接发生或经由NEF发生与外部AF的交互。

-MSF控制平面(MSF-C)：

-多播服务配置。

-MBS服务水平管理。

-xMB-C/MB2-C终止。

-编解码器配置(如果需要的话)。

-MSF用户平面(MSF-U)：

-xMB-U/MB2-U终止。

-对服务层处的数据进行编码。

-经由N6递送多播服务层数据分组。

如果应用不需要任何特定的服务层功能，则应用可以使用：

-Nnef直接用于多播会话配置/协商，以及

-N6用于多播数据递送。

这如图5所示，图5描绘了具有直接应用服务器/功能交互的示例性MBS系统。

在[1]的附件A.2中描述了基于专用MBS功能的5G MBS系统架构。

为了在5GS用户服务递送中支持MBS，存在两种不同的操作模式：一种用于仅传输模式，另一种用于全服务模式(TS 23.246条款7.5)。

-对于仅传输模式，MBS应用数据对图6中的网络功能是透明的。

-对于全服务模式，MBSF/MBSU知道内容流并能够将内容流转换为3GPP兼容流。

图6示出了5GS中用于MBS的单个示例性架构。在该图6中，具有支持MB会话的角色的SMF和UPF被命名为“MB-SMF”和“MB-UPF”。没有什么能阻止MB-SMF和MB-UPF同时支持PDU会话和MB会话两者，例如，到同一DNN的PDU会话和MB会话。然而，MB-SMF和MB-UPF也可以被部署并配置为专门处理MB会话。人们相信，这可以减少信令，并且在一些情况下，操作专用于MBS的有限数量的MB-SMF和MB-UPF会更简单且更成本高效。如果优选的话，这种架构使其成为可能。

对现有实体和新功能组件的增强如下：

-UE、NG-RAN、AMF、SMF、UPF、NEF和PCF支持MBS。

-UE支持5G MBS服务。

-NG-RAN支持MBS媒体的点到多点(PTM)和点到点(PTP)递送。NG-RAN独立地控制在PTM与PTP之间的切换，以实现最佳服务质量和资源效率。

-AMF被增强以选择MB-SMF并成为信令分发树的一部分。

-MB-SMF是一种增强的SMF，其用于控制MB会话、利用AF(经由NEF/MBSF)发送信令、使用PCF进行QoS控制以及根据AMF的请求提供MB会话信息。UE针对MBS服务的个体递送而维护的PDU会话可以与由MB-SMF管理的MB会话相关联。

-MB-UPF是利用MBS用户平面功能增强的UPF。

-MBSF(多播/广播服务功能)是一种功能，其可以是NEF的一部分，或者被独立部署。

MBSF可以支持TMGI分配或用于服务级别管理的其他MBS信令。MBSF还提供到应用功能或内容提供商的接口，并且具有到MBSU的接口。MBSF可以执行对UE加入MB会话的授权。

-MBSU(多播/广播服务用户平面)是一种处理有效负载部分的新实体，以满足服务级别功能和管理的需要。

-NEF是现有的NF，其提供到AF的接口。

-PCF被增强以处理针对MB会话的QoS，例如，授权QoS简档用于共享递送。

对现有接口和新接口的增强如下：

-N2接口控制MB会话，包括管理在MB UPF与NG-RAN之间的共享N3隧道。

-N3接口支持在MB-UPF与NG-RAN之间的共享N3隧道。

-N4接口管理在MB-UPF与NG-RAN之间的共享N3隧道，包括建立共享N3隧道。

-N7和N30接口能够对MB会话进行策略控制。

-N11接口利用MBS控制信令进行增强，包括管理在MB-UPF与NG-RAN之间的共享N3隧道。

-N29接口利用MBS控制信令进行增强。

-N33接口利用MBS控制信令进行增强。

-Ny：在MBSF与MBSU之间的新接口，其用于管理MBSU功能。

-NxMB-U：在新的MBSU与AF之间的新接口，其用于MBS用户平面业务。

遵循这些架构，在[1]中列出了多种可能的解决方案。例如，[1]中的解决方案#2假设了基于专用MBS功能的5G MBS系统架构。图6.2.2.2a-1描述了以5GC个体MBS业务递送(即，以到UE的PUD会话)开始的会话。图6.2.2.2-1描述了针对MBS会话的会话开始。与此相关的是，AF将媒体流递送到MB-UPF，该MB-UPF将其发送到网络的更下游。

背景2：5MBS当前安全关键问题及解决方案

基于以上5MBS的总体架构[1]，目前正在研究如何保护5MBS系统。这反映在TR33.850 v0.2.0(对5G多播-广播服务增强的安全方面的研究)[2]。目前需要解决三个关键问题：

-关键问题#1：5GS应支持针对多播通信服务的认证和授权。特别地，这个关键问题指代上面总结的[1]中的参考架构和[1]中的关键问题#3，其包括两个方面：(i)定义和研究如何支持UE的必要级别的授权以访问多播通信服务；(ii)UE如何可以加入/离开(包括授权或撤销访问)多播通信服务？

-关键问题#2：5GS应支持MBS业务的机密性保护、完整性保护和防重放保护。

-关键问题#3：用于保护密钥生成器与UE之间的MBS业务的密钥的分发应受到机密性、完整性和防重放保护。

在[2]中，针对KI#2和KI#3有三种解决方案。这些解决方案是解决方案#1、解决方案#2和解决方案#3。

-解决方案#1侧重于保护传输层处的MBS业务。在这种情况下，组密钥在PDCP级别使用并在RAN中生成。该组密钥用于保护MBS业务。

-解决方案#2侧重于保护服务层处的MBS业务。在(MB)-SMF处生成组密钥。该密钥利用MUK安全地发送到每个UE，该MUK是根据Kausf推导的密钥。组密钥用于保护MBS业务。

-解决方案#3侧重于利用多播传输密钥(MTK)来保护MBS业务，该MTK是在核心网中生成的并以安全(单播)方式分发给UE。该MTK用于保护MBS业务。

背景3：针对5G r16的MBMS安全架构

与5MBS中的发明描述相关的是如何在4G中实现针对MBMS的安全性。用于MBMS的安全架构在TS 33.246[3]中进行了描述。接下来，总结了最重要的几个方面：

*附件B描述了所考虑的安全威胁。B.1是无线电接口中的威胁。B.1.1描述了“未授权访问MBMS用户服务数据”以及其他，并包括入侵者可能窃听MBMS用户服务数据的威胁、已经加入并离开MBMS用户服务的用户继续免费接收服务的威胁、以及订户推导解密密钥并将解密密钥分发给未授权的各方的威胁。B.1.2描述了“对完整性的威胁”，包括修改和重放消息，以欺骗用户内容来自实际来源。

*附件C描述了安全要求。特别地，C.4描述了关于MBMS密钥管理的要求，包括“UE和 MBMS密钥生成器应支持运营商在其认为必要时尽可能频繁地执行密钥更新，以确保：1)已 经加入MBMS用户服务但随后离开的用户在没有被适当收费的情况下不得获得对MBMS用户 服务的进一步访问；2)加入MBMS用户服务的用户在未被适当收费的情况下不得访问来自 MBMS用户服务中的先前传输的数据；以及3)订阅用户向非订阅用户分发解密密钥的影响应 是可控的”。

*图7(对应于[3]中的图4.1)描述了整个MBMS安全架构。在Itectec网页(在https://itectec.com/spec/4-2-key-management-overview/(以下引用为[4])可获得)中，包括了基于[3]的对MBMS中密钥管理和安全性的描述。根据[4]和[3]中的第4.2节：“BM-SC控制MBMS服务密钥(MSK)的使用，以保护不同的RTP会话和FLUTE信道。MSK用于保护MBMS传输密钥(MTK)的递送，该MTK用于保护条款6.5和6.6中规定的RTP会话和FLUTE信道。MSKS的递送是利用特定于用户的MBMS用户密钥(MUK)保护的，该MUK是从GBA接收的，参考条款6.1。在MBMS用户服务级别处管理MSK和MTK。”这意味着能够访问服务的UE接收利用MUK保护的MSK。MTK被分发到利用MSK保护的多个UE。这如下所示(其中箭头指示利用其进行保护)：

MUK->MSK_0->MTK_00

->MTK_01

->…

->MSK_1->MTK_10

->MTK_11

->…

->…

*第6.3.2.2节描述了UE获得新MSK所要求的MSK请求过程。该过程是其他过程的一部分，例如，当UE错过了密钥更新(超出覆盖范围)或由BM-SC请求的拉取过程时。最后一个过程在6.3.2.2.4中描述，并在[3]中的图6.2b和下面的图8中进行了描绘。其示出了BM-SC向UE发送MIKEY消息，UE验证该消息，并且如果正确，则发送HTTP POST请求以获得MSK更新。

*MIKEY表示多媒体互联网键控(Multimedia Internet KEYing)，并且在RFC 3830(https://tools.ietf.org/html/RFC3830)中进行了定义。MIKEY由Ericsson Research于2004年定义，并且本文档描述了一种可以用于实时应用(用于对等通信和组通信两者)的密钥管理方案。

*[3]中的第6.3.2.3节描述了MSK如何被递送到UE，特别是(i)MSK推送(第6.3.2.3.1节)，其中MB-SC通过UDP在MIKEY消息中递送密钥。UE也通过UDP利用MIKEY消息进行应答。

*[3]中的第6.3.3节描述了用于MTK的过程，包括依赖于MSK ID的它们的唯一ID。这意味着相同的MTK不能与两个不同的MSK一起使用。MTK的更新用MSK来保护，并且该消息可以被包括在多播/广播流中。

*附件I示出了如何保护业务的示例。特别地，可以使用相同的MSK来保护两个用户服务。

*第6.3.4节描述了如何处理“多个BM-SC部署”，这仅在相同的MBMS用户服务通过多个BM-SCS发送时适用。如果发生这种情况，则多个BM-SC中的密钥(MSK(第6.3.4.4节)和MTK(第6.3.4.5节))是相同的，因为它们与相同的业务一起使用。[2]中的解决方案#1、#2和#3使用单个组密钥来保护多播/广播业务。问题在于，如果组密钥被破坏(例如，UE是恶意的，或者仅仅UE从MBS中移除)，则这些解决方案没有描述如何更新组密钥，使得不获得或修改在稍后时间点分发的内容。特别地，如果无法更新组密钥，则攻击者：

a)仍然可以访问内容，例如，通过被动地监视通信。

b)可以注入业务，例如，在MitM攻击的上下文中。

类似地，[3]描述了用于MBMS的安全架构(r16)，其中使用个体设备密钥(MUK)来递送用于保护特定MBMS服务的多播传输密钥(MTK)的多播服务密钥(MSK)。在这种情况下，组密钥等效于MTK。如果UE被破坏，则要求更新MSK和MTK。[3]描述了如何更新MSK，然而，更新要求大量的信令，因为每个UE需要联系BM-SC以获得新的MSK，如图8所示，图8描述了BM-SC请求的拉取。

发明内容

本发明的一个目的是减轻上述问题。

本发明的另一目的是确保高效地更新密码密钥。

本发明的又一目的是减少在终端被破坏或撤销的情况下重新配置系统所要求的信令的量。

本发明的又一目的是提供一种主站和次站，其可以更高效地更新共享密码密钥，同时改进系统的安全性。

因此，在本发明的第一方面中，提出了一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的多播受保护的通信，

b.在确定要求更新时，通过经加密的消息向所述次站的至少一个子集发送更新后的密码密钥。

因此，在组密钥需要被更新时，系统自动提供更新后的密码密钥，以确保系统不会被破坏。注意，密码密钥可以对应于用于加密数据信息的加密密钥。在一些变型中，密码密钥可以用于完整性保护，例如，用于认证消息的来源或消息的新鲜度。

在本发明的第一方面的变型中，所述更新后的密码密钥是更新后的组密钥，并且其中，所述经加密的消息通过特定于用户的加密密钥进行加密并且以单播方式发送。单播意味着消息被寻址到单个目标。这对应于点到点消息。这可以例如通过使用专用信道和/或通过识别消息的接收者来完成。

在本发明的第一方面的另一变型中，确定组密钥是否需要被更新的步骤包括确定是否满足以下条件中的至少一个条件：所述次站的访问权限中的至少一个访问权限已经被撤销、所述次站的访问权限中的至少一个访问权限已经过期、所述组密钥的有效时间已经过期、所述次站中的至少一个次站已经离开预定位置。

在本发明的第一方面的另一变型中，所述更新后的密码密钥是共享给次站的第一集合的第一集合密钥。

根据该变型，次站被分组到集合中。集合中的每个集合包括多个次站，并且这些次站共享相同的集合密码密钥。该集合密码密钥或第一集合密钥允许对被寻址到第一集合中的次站的一些多播消息进行加密/保护。因此，当更新组密钥时，主站可以将相应的多播消息定向到每个集合。这减少了发送消息的数量，因为这些消息是以多播方式发送的，而不再是以单播方式发送到每个次站。通过多播，这对应于例如使用公共加密集合密钥寻址到一组次站的单个消息。例如，这可以通过使用广播信道来完成。在该变型的示例中，其中，在步骤a处确定所述次站中的属于所述第一集合的至少一个次站的访问权限当前无效时，更新所述第一集合密钥。这实际上表示第一集合的次站中的一个次站被破坏或已经被撤销。因此，第一集合需要更新其集合密钥，以确保攻击者无法访问发送到第一集合的数据。

一旦该第一集合密钥被更新，更新后的组密钥就可以通过多播发送到次站的每个集合。这对应于通过利用关联于次站的每个集合的相应集合密钥保护的消息，将更新后的组密钥发送到次站的每个集合的步骤。

注意，在一些情况下，例如，在次站首次加入的情况下，或者如果该集合中的站的数量较少，则该消息可以反而以单播方式发送。此外，在一些特定情况下，可以发送消息两次，一次以单播方式发送，一次以多播方式发送。

注意，第一集合密钥可以用于加密和/或保护发送到次站的集合的消息的完整性和/或保护该消息的新鲜度。

根据本发明的第二方面，提出了一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

b.在确定要求更新时，在相应的多播消息中向次站的相应集合发送更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

类似于先前所解释的，根据本发明的第二方面，次站被分组到集合中。集合中的每个集合包括多个次站，并且这些次站共享相同的集合密码密钥。该集合密码密钥或第一集合密钥允许对被寻址到第一集合中的次站的一些多播消息进行加密/保护。因此，当更新组密钥时，主站可以将相应的多播消息定向到每个集合。这显著减少了发送消息的数量，因为这些消息是以多播方式发送的，而不再是以单播方式发送到每个次站。通过多播，这对应于例如使用公共加密集合密钥寻址到一组次站的单个消息。例如，这可以通过使用广播信道来完成。在该变型的示例中，其中，在步骤a处确定所述次站中的属于所述第一集合的至少一个次站的访问权限当前无效时，更新所述第一集合密钥。这实际上表示第一集合的次站中的一个次站被破坏或已经被撤销。因此，第一集合需要更新其集合密钥，以确保攻击者无法访问发送到第一集合的数据。

在本发明的该第二方面，确定组密钥是否需要被更新包括确定是否满足以下条件中的至少一个条件：

-所述次站的访问权限中的至少一个访问权限已经被撤销，

-所述次站的访问权限中的至少一个访问权限已经过期，

-所述组密钥的有效时间已经过期，

-所述次站中的至少一个次站已经离开预定位置。

如果更新的需要与站中的一个站的访问权限的问题相关，则可能也需要更新集合密钥。作为示例，该方法包括：如果在步骤a处确定所述组密钥与属于次站的第一集合的第一次站的访问权限无效相关，则通过受保护的单播消息向所述第一集合中的每个次站通过单播发送新的第一集合密钥。

一旦针对第一集合进行了第一密钥的这种更新，第一密钥的次站就可以接收更新后的加密组密钥。因此，在这样的示例中，该方法将还包括步骤c：在多播消息中向所述次站的第一集合发送更新后的组密钥，所述多播消息通过所述新的第一集合密钥被加密。这与其他集合类似，但这些集合不要求更新集合密钥。因此，对于其他集合的所有次站，更新所要求的消息的数量减少。

在不同的示例中，可以通过用于新的第一集合密钥的相同的单播消息来更新组密钥。因此，受保护的单播消息还包括更新后的组密钥。这允许避免将新的多播消息传输到第一集合，从而进一步减少在组密钥更新期间发送出去的消息的量。

在本发明的第三方面，提出了一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

b.在确定要求更新时，通过受保护的单播消息向所述次站的至少一个第一子集通过单播发送第一集合密钥，

c.在多播消息中向次站的第一集合发送更新后的组密钥，所述多播消息通过所述第一集合密钥来保护，或者替代地在步骤b的所述受保护的单播消息中包括所述更新后的组密钥，

d.在相应的多播消息中向次站的另外的相应集合发送所述更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

注意，主站可以是基站，例如，LTE中的eNodeB(eNb)或5G中的gNodeB(gNb)。然而，主站可以对应于网络的更高级别的实体，例如，核心网元件或网络信任中心。在这种情况下，与到次站的传输相关的步骤包括通过不同接口(光纤、以太网、空中接口)和通过包括例如基站或中继器的不同实体间接传输消息。在这样的情况下，可能不是直接来自主站。递送密码密钥的消息可能由核心网内的给定5G网络功能发起，但该网络功能可能将其提供给核心网中负责发送5MBS业务的另一实体。

在本发明的第二方面或第三方面的变型中，次站的集合是基于位置形成的，并且其中，步骤d还包括：所述主站在至少一个另外的多播消息中发送所述更新后的组密钥，所述另外的多播消息通过在相邻集合中使用的相应集合密钥被加密。在示例中，相邻集合是驻留在由另一主站服务的小区中的多个次站的集合。例如，相邻集合可以是在相邻小区中服务的次站的集合。这些次站可以由相同的主站或不同的主站服务。这允许次站具有一定的移动性，同时不会因为次站离开其原始小区而有错过组密钥更新的风险。为了进一步改进这种可靠性，并降低次站错过更新后的密钥的风险，可以周期性地重传多播消息。

然而，在这些方面的不同示例中，这些集合可以以更随机的方式形成，例如，基于次站的标识符或基于连接时间来形成。

在本发明的这些方面的又一变型中，所述多播消息包括所述更新后的组密钥以及认证指纹消息，所述认证指纹消息被计算为所述更新后的组密钥的散列。

根据本发明的第四方面，提出了一种用于次站在网络中接收密码密钥的方法，包括以下步骤：

a.通过受保护的单播消息从主站通过单播接收第一集合密钥，所述第一密钥与次站的第一集合相关联，

b.接收到所述次站的第一集合的多播消息并将所述多播消息解密为更新后的组密钥，所述解密使用第一集合密钥。

在本发明的第四方面的变型中，提出了所述多播消息包括受保护的更新后的组密钥以及认证指纹消息，并且所述方法还包括所述次站通过检查经解密的组密钥的散列是否与接收到的认证指纹匹配来认证所述多播消息。因此，当攻击者试图模拟主站并发送假消息时，这允许所有次站报告任何差异。因此，可以提出如果所述检查失败，则向所述主站报告异常。

根据本发明的第五方面，提出了一种在蜂窝网络中操作并且与多个次站通信的主站，包括：

控制器，其适于确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

耦合到所述控制器的发射机，其适于在确定要求更新时，在相应的多播消息中向次站的相应集合发送更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

注意，主站可以是基站，例如，LTE中的eNodeB或5G中的gNodeB。然而，主站可以对应于网络的更高级别的实体，例如，核心网元件或网络信任中心。在这种情况下，与到次站的传输相关的步骤包括通过不同接口(光纤、以太网、空中接口)和通过包括例如基站或中继器的不同实体间接传输消息。在这样的情况下，可能不是直接来自主站。递送密码密钥的消息可能由核心网内的给定5G网络功能发起，但该网络功能可能将其提供给核心网中负责发送5MBS业务的另一实体。

因此，主站可以以更高效的方式将组密钥更新到所有次站，因为可以使用许多多播消息而不是常规的单播消息

根据本发明的第六方面，提出了一种在蜂窝网络中操作并且与主站通信的次站，包括：接收机，其适于通过受保护的单播消息从主站通过单播接收第一集合密钥，所述第一密钥与次站的第一集合相关联；以及控制器，其适于将到所述次站的第一集合的多播消息解密为更新后的组密钥，所述解密使用所述第一集合密钥。

注意，解密多播消息也可以由多播消息的真实性检查和/或新鲜度检查来代替或补充。

根据本发明的第七方面，提出了一种计算机程序和/或作为专用硬件存储和/或分发在适当介质上的程序代码单元，所述适当介质例如为光存储介质或固态介质，所述程序代码单元与其他硬件一起提供或作为其他硬件的一部分提供，但所述程序代码单元也能够以其他形式分发，例如，经由互联网或者其他有线或无线电信系统分发，并且所述适当介质包括用于执行本发明的第一方面、第二方面、第三方面或第四方面的方法的指令。

注意，上述装置可以基于具有分立硬件组件的分立硬件电路、集成芯片或芯片模块的布置，或者基于由存储在存储器中、写入在计算机可读介质上或从网络(例如，互联网)下载的软件例程或程序控制的信号处理设备或芯片来实现。

应当理解，所要求保护的方法和所要求保护的装置(主站或次站)可以具有类似和/或相同的优选实施例，特别是如从属权利要求中定义的。

应当理解，本发明的优选实施例也可以是从属权利要求或上述实施例与相应的独立权利要求的任何组合。

本发明的这些和其他方面将从以下描述的实施例中变得明显并参考以下描述的实施例来阐明。

附图说明

已经描述的图1是示出高级别MBS架构的图；

已经描述的图2是示出用于MBS的递送方法的图；

已经描述的图3是示出用于利用单播的集成多播传输的5G系统架构的图；

已经描述的图4是示出多播/广播的服务层支持的示例的图；

已经描述的图5是表示具有与应用服务器的直接交互的示例性MBS系统的图；

已经描述的图6是表示用于5GS中的MBS的单个示例性架构的框图；

已经描述的图7是示出整个MBMS安全架构的图；

已经描述的图8是示出用于更新UE中的密钥的常规方法的图；

图9是表示根据本发明的第一实施例的过程的图；

图10是表示根据本发明的第二实施例的过程的图；

图11是表示根据本发明的实施例的修改后的密钥层级的图；

图12示出了本发明的特定示例性实施例；

图13是表示根据本发明的另一实施例的过程的图；

图14是表示其中实现本发明的实施例的网络的框图；

图15是表示用于本发明提出的实施例的不同密钥层级的图；以及

图16是被提出用于3GPP标准规范中的改变的图。

具体实施方式

如上面可以看出的，本发明可以在蜂窝网络(例如，4G网络或5G网络)中实现。

在图14所示的这些电信系统中，次站100用作终端或最终设备(在5G中也称为用户设备UE)。次站可以通过部署在现场的基站110(在5G中也称为gNB)访问包括语音和数据服务的不同类型的服务。每个基站110为存在于区域(也称为小区111)中的次站100服务并与其通信。基站连接到由网络运营商管理的核心网(CN)120，该核心网(CN)120控制电信系统并且编排服务的递送。

如关于图14看出的，这样的蜂窝网络包括多个终端或次站100，这些终端或次站100是可以从网络小区行进到另一网络小区111的移动设备(或UE)。每个小区111由基站110(或gNodeB)服务，该基站110(或gNodeB)构成次站100与核心网120之间的接口。

因此，次站100在各种无线电信道、(从次站到基站的)上行链路和(从基站到次站的)下行链路上与基站110通信。其他无线电信道例如存在于次站之间(例如，侧链路信道)和基站之间(例如X2接口)，但是为了图14的简单起见没有示出。本发明的实施例也可以应用于这些接口，然而，将在说明书的以下部分中侧重于在次站与基站之间的链路。

应当注意，各个实施例在次站与主站之间实现。在一些实施例中，主站可以对应于核心网120的一些实体。在本发明的实施例的意义上，基站还可以(部分或全部地)作为主站操作。

根据本发明的实施例的定义，在[2]中的解决方案#2和解决方案#3中提出了更新用于保护多播/广播业务的组密钥的过程。基本思路在于生成新的组密钥并将其分发给UE，使得利用新的组密钥保护多播/广播内容。因此，这种基本思路确保攻击者无法访问内容或注入业务，但这种基本思路的缺点在于，其涉及将新的内容密钥分发到所有“N-1”个未破坏的UE的高开销。

上述基本思路在以下各种实施例和示例(扩展思路)中通过定义“M”个UE组而得到改进，每个UE组与密钥组相关联。组可以基于例如UE的位置。如果UE被破坏，则：

-使用M-1个未破坏的组中的组密钥来更新内容密钥

-针对与被破坏的UE相对应的组中的UE，利用N/M-1个消息更新组和内容密钥。

以这种方式，信令开销从N-1减少到N/M+M-2。例如，如果N＝10000且M＝25，那么开销将从9999个消息减少到63个消息。该扩展思路适用于诸如[2]中的#1、#2和#3之类的解决方案，并且还可以用于[3]中以减少信令开销。

注意，本发明的该实施例与[3]中的解决方案之间的一个区别在于，该实施例允许利用不同的K_set密钥(类似于[3]中的MSK并且用于递送密钥组)分发相同的K_group(类似于[3]中的MTK并且用于保护多播/广播内容)。

本发明的基本实施例在[2]中的解决方案#2的上下文中详细描述，然而，类似方法适用于[2]中的类似解决方案(例如，解决方案#3)。本实施例也适用于[3]。

基本实施例

图9描述了在本发明中提出的基本过程，其中字母步骤(a-f)是应用于[2]中解决方案#2的解决方案的附加项。

a)检查UE是否被允许加入MBS组。

b)检查UE访问权限是否已经改变，例如，是否已经被撤销。

c)发送更新组密钥的请求。

d)更新组密钥。

e)向更新K_group_enc和K_group_int的每个未撤销UE发送利用MUK保护的单播消息。每个UE使用其MUK来验证消息的真实性并对新的组密钥进行解密。新鲜度也需要被验证(见下文实施例3)。

f)更新后的组密钥用于保护内容数据并将其发送给UE。

在图9中，AE代表经认证的加密(Authenticated Encryption)，这意味着消息：i)是通过例如使用密钥(例如，特定于认证和完整性保护的密钥(K_int))计算出的消息认证码(MAC)来认证的；以及ii)是使用密钥(例如，特定于加密的密钥(K_end))加密的。AE的示例是GCM模式下的AES。

利用该基本解决方案，可以更新k_group，并防止被撤销的UE访问或修改广播数据。如果N个UE被订阅到给定的MBS，则该基本解决方案要求交换N-1个消息。

实施例1：UE集合和集合密钥的定义

图10描述了本发明的基本实施例的改进实施例，其中字母步骤(a-i)是应用于[2]中解决方案#2的解决方案的附加项。

a)检查UE是否被允许加入MBS组。

b)生成密钥K_group以保护内容，并且生成M个密钥K_sets以保护K_group的递送，其中

集合指代M～N/L个UE的集合。

c)确定UE被放置在哪个集合中。

d)检查UE是否已经被撤销、是否已经离开组等。

e)发送请求以更新：1)用于保护多播/广播内容的组密钥；以及2)用于保护受UE撤销影响的设备的集合中的组密钥的递送的集合密钥。

f)更新组密钥(K_group_enc和K_group_int)。更新与UE的集合相关联的集合密钥(K_set_enc和K_set_int)。

g)通过M-1个点到点交互来更新被破坏的集合中的M-1个UE的集合密钥。

h)通过向未受影响的集合发送L个消息来更新用于保护内容的新的组密钥。

i)更新后的组密钥用于保护内容数据并将其发送给UE。

利用该实施例，可以更新k_group，并防止被撤销的UE访问或修改广播数据。该基本解决方案要求交换M-1个点到点消息和递送L个多播消息。例如，如果N＝1000、M＝40且L＝25，则基本实施例要求999个消息，而该方法要求64个消息。

如果该实施例应用于[3]中提出的解决方案，则访问相同多播广播服务的UE的不同集合被给予不同的集合密钥(MSK)。这些不同的集合密钥用于在给定的时间点保护相同的组密钥(MTK)，而不要求UE与MB-BC之间的单播通信，即，组密钥的更新。该修改改变了[3]中使用的MIKEY中的密钥层级，如图11所示。MSK是针对用户的集合定义的，并且具有L个。它们中的每一个都可以被单独更新，并且它们中的每一个都具有不同的计数器{i1，i2，…，iL}。如果更新了集合密钥(MSK)，则这暗示着组密钥(MTK)的改变。MTK具有不同的计数器t来标识它们。即使没有集合密钥(MSK)被更新，也可以以主动的方式更新组密钥(MTK)，例如，如果组密钥(MTK)已经被使用了太长时间段。

图12示出了更具体的示例，其中设备的三个集合具有利用MSK_1、MSK_2和MSK_3标识的集合密钥。对于设备的每个集合都有一个设备，在设备的集合1中，具有设备密钥表示为MUK_a的设备a；在设备的集合2中，具有设备密钥表示为MUK_b的设备b；以及在设备的集合3中，具有设备密钥表示为MUK_c的设备c。

-用于保护内容数据的第一组密钥表示为MTK_0。

-在这种情况下，设备a的集合发生了改变，例如，设备离开了该设备的集合。这将触发MSK_1_i1到MSK_1_(i1+1)的更新，即，集合密钥改变，并且其索引增加。由于组密钥MTK_0可能被破坏，因此使用MSK_1_(i1+1)、MSK_2_i2和MSK_3_i3以安全的方式将新的MTK_1分发给不同集合中的设备。

-在这种情况下，长时间使用MTK_1。这将触发对MTK_2的更新，其使用MSK_1_(i1+1)、MSK_2_i2和MSK_3_i3被安全地分发。

-在这种情况下，设备b的集合中发生了改变，例如，设备离开了该设备的集合。这将触发MSK_2_i2到MSK_2_(i2+1)的更新，即，集合密钥改变，并且其索引增加。由于组密钥MTK_2可能被破坏，因此使用MSK_1_(i1+1)、MSK_2_(i2+1)和MSK_3_i3以安全的方式将新的MTK_3分发给不同集合中的设备。

该实施例也可以适用于[2]中的解决方案#1。与必须递送N个RRC重新配置请求相反，可以只发送M-1个RRC重新配置请求以更新新的集合密钥。新的组密钥必须连同多播/广播业务一起递送，特别地，新的组密钥是利用UE的L个集合的L个集合密钥保护的。注意，这要求RAN能够在多播/广播业务中包含该密钥信息。注意，如果最后一个要求不可行，则替代方案将是通过RRC重新配置请求来递送新的组密钥，然而，这些消息是单播消息，使得将要求RAN的改变才能够通过广播信道递送RRC重新配置消息。

该解决方案可以在[2]中解决方案#3的上下文中使用。在该解决方案中，定义了在核心网(MB-CP)中生成的多播传输密钥(MTK)。该MTK安全地被分发给每个UE(以单播方式)，并用于保护从MB-UP到UE的MBS数据。如果使用该实施例，则在核心网(MB-CP)中生成多个集合密钥。然后，通过安全单播消息以安全的方式将该集合密钥传输到UE。然后使用集合密钥来更新组密钥，该组密钥保护从MB-UP到UE的内容密钥。

该实施例的重要方面是关于如何定义UE的集合。一种选择是根据位置定义UE的集合。该位置可以例如与基站或基站的天线波束覆盖的区域相关，或者基于跟踪区域。这是重要的，因为该区域中的所有UE可以使用相同的无线电资源接收内容。具体的示例可以是在体育场中，其中多播/广播内容(例如，数字标识或关于比赛的信息)要由基站递送。为了提供尽可能好的性能，基站使用多个无线电波束来对体育场中的不同集合的用户进行寻址。定义集合的其他方法是可行的，例如，取决于UE的特征、取决于它们订阅的多播和广播服务。

实施例2：促进移动性

在[2]中的解决方案#1中，移动性可以进一步规范。如果UE移动到附近的小区，则在递送多播/广播内容时使用相同的组密钥以避免任何业务中断是很重要的。从这个角度而言，相同的组密钥用于在周围小区中广播内容。由于集合密钥用于更新组密钥，因此推荐向UE提供与其位置周围的设备的集合相关联的集合密钥。不遵循该推荐的风险在于，当UE移动到周围小区时，可能利用该小区的集合密钥来更新组密钥，并且UE可能会错过该消息。可替代地，基站可以使用周围区域的集合密钥来广播组密钥的更新。以这种方式，如果UE来自周围区域，则它将能够解密新的组密钥。该最后一种方法的优点在于向UE提供较少的密钥材料，从而降低了泄漏的风险。另一显著优点在于，当UE离开UE的集合时，应更新集合密钥。如果UE具有单个集合密钥，则更新的量较低。

这在图13中示出，其中UE(例如，在粗线圆圈内的UE)可能具有多个集合密钥。在这种情况下，在粗线圆圈内的UE可能具有K_0和K_0i，其中i＝{0,…,5}。可替代地，UE可能仅具有K_0，并且周围小区将用周围的集合密钥广播组密钥的更新。

我们注意到，这样做的另一好处是使用DU/CU拆分的RAN架构。在这样的架构中，每个分布式单元(DU)可能是独立的小区，并且中央单元(CU)运行所有DU的RRC层。一种方法可以在与使每DU的不同的组密钥来保护MBS业务。如果UE离开DU，则只有DU中的UE必须被更新。从这个角度而言，该解决方案可能与具有多个集合密钥的性能相似。区别在于CU，因为将MBS业务分发给所有DU的CU必须利用与其处理的DU一样多的组密钥来保护MBS业务。利用本发明提出的解决方案，每个DU将具有其自己的集合密钥，该集合密钥用于对保护MBS数据的组密钥的递送进行验证和解密。CU只需对MBS数据加密一次，其控制所有DU共享的组密钥。当递送该数据时，CU必须在受保护的MBS业务旁边包括受保护的组密钥，该组密钥是利用指派给其控制下的DU中的每个DU的集合密钥中的每个集合密钥来保护的。

实施例3：保持同步

作为组的一部分的UE可能会错过密钥组更新。如果发生这种情况，则UE可能无法解密所分发的内容。为了避免这种情况，特别是在执行密钥更新后不久，以主动的方式周期性地分发当前使用的密钥组。

另一重要方面指代如何确保新鲜度。一种确保方式是在AE中使用的初始化向量(IV)的构造中使用时间，例如，UTC时间。如果在IV构造中使用计数器，则在分发新的组密钥时，该IV应被设置为初始值，并且应不断增加。UE不应接受具有比其当前具有的IV更旧的IV的任何消息。由于传输密钥在所有设备之间共享，因此攻击者也可能试图注入虚假业务。为此，攻击者必须使用具有较高值的IV。UE不应接受其IV远高于它们当前具有的IV的消息，例如，相当于几秒或几分钟的数据传输。如果通过使用基于UTC的计数器构造IV，则UE不应接受包含与当前时间相差超过小的时间窗口的IV的消息。

实施例4：在组密钥的更新中确保源认证

在到目前为止所描述的系统中遇到的问题是使用若干集合密钥来更新组密钥(如实施例1中所描述的)。这个问题也出现在[3]中，因为MTK是使用MSK更新的。由于集合密钥(和[3]中的MSK)，攻击者可能试图“伪造”组密钥的更新。这可能导致设备的集合获得错误的组密钥的情况。直接的影响是，将无法解密接收到的内容，消息认证码将失败。如果在此基础上，攻击者设法注入利用先前注入的假组密钥保护的假内容，则该设备的集合中的UE将接受假内容。

提出了处理该问题的两种方法：

方法1：为了解决这些系统中的这个问题，在[3]中，网络可以构造组密钥更新的认证指纹。该指纹通过以下步骤构造：1)随机获得新的组密钥K，该密钥例如为256位长；以及2)获得K的散列(例如，SHA2或SHA3)，即，R＝HASH(K)。当网络广播密钥更新时，通过分发利用M个集合密钥保护的新的组密钥(图10中的步骤h)，网络还将R附加到该消息。

在接收到该组密钥更新消息时，UE执行以下操作：

a)查找消息中包括利用其集合密钥保护的(加密/完整性)的组密钥的部分。UE检查消息认证码，UE检查更新消息的新鲜度，并且如果两个条件都成功，则UE解密新的组密钥。

b)检查接收到的值R的散列是否等于经解密的组密钥。

在上述攻击中，节点的集合中的节点将成功检查上述所有两个条件a)和b)。然而，由于信息是通过广播信道发送的，所以所有设备都将接收到该消息，而其他集合中的设备将无法成功验证条件b)。因此，设备的其他集合中的那些设备可以触发对核心网的警报，该警报指示失配并包括接收到的消息。网络可以通过检查组密钥更新中的哪一个组密钥更新是错误的来验证集合中的哪一个集合受到影响/受到攻击。

方法2：在处理伪基站的当前研究的上下文中，正在讨论使用数字签名的一些解决方案。这些解决方案中的一个解决方案是数字签名网络功能(DSnF)。DSnF是可以用于对SI进行签名的功能，但其也可以用于对其他信息进行签名。例如，组密钥更新。在这种情况下，图10中的消息h也将由DSnF签名。为此，生成该消息的网络实体需要首先向DSnF发送请求以获得消息的签名。然后将该签名被附加到组密钥更新中。如果这样做，则UE仅在以下情况下接受经解密的密钥更新：

1)使用其集合密钥对MAC的验证是正确的；

2)使用计数器(如实施例3)的新鲜度检查是正确的；

3)数字签名被成功验证。

我们注意到，如果组密钥的生成和分发是在RAN内完成的(如[2]中的解决方案#1)，则基站也可以附加签名。这可能要求首先向DSnF发送请求。或者替代地，使用其自己的公钥/私钥对(如果它们拥有的话)。

此外，鉴于本发明的先前实施例和变型，建议调整TR33.850中描述的过程，如下所示：2详细提案

TR 33.850中的KI#2要求5GS来支持MBS业务的机密性保护、完整性保护和防重放保护。TR 23.757中的KI#3还要求研究：“UE可以如何加入/离开(包括授权或撤销访问)多播通信服务？”

结合这两个关键问题，可能会遇到风险和威胁，例如：

·用于保护5MBS业务的内容密钥被长期使用；

·组中的设备离开，应防止其接收新内容；

·设备加入，应防止其访问旧内容；

·组中的设备是恶意的，应防止其注入虚假内容。

上述风险和威胁要求：

1.适应现有的关键问题或创建新的关键问题，要求5GS能够更新用于保护多播内容的密钥。

2.分发和更新用于保护内容的密钥的高效解决方案，使得可以以高效的方式分发和更新这些密钥。

我们请SA3考虑在TR 33.850中包括附加的两个改变。

·第一改变设置了针对密钥更新需要的要求。

·第二改变描述了一种用于密钥分发和更新的高效且有弹性的方法。为了解释起见，这在现有解决方案#2的上下文中。

****变化1开始****

关键问题#3：密钥分发的安全保护

5.3.1关键问题详情

MBS在3GPP系统中引入了点到多点服务的概念。MBS业务通过5GS从应用服务提供商递送到多个UE。为了将数据安全地发送到给定的用户集合，需要保护MBS业务以减轻潜在的攻击。作为安全的根本基础，要求用于保护MBS业务的密钥。

与UE密钥相比，用于保护MBS业务的密钥是一对多密钥。当UE加入MBS会话时，只有授权用户能够接收从密钥生成器递送的密钥以保护MBS业务。UE也可能离开MBS会话或被破坏。

5.3.2安全威胁

如果用于保护MBS业务的密钥没有机密性保护，则攻击者可以使用3GPP网络获得对MBS服务的“自由访问”。

如果用于保护MBS业务的密钥没有完整性或防重放保护，则授权用户可能无法正确获取MBS业务。

如果无法更新用于保护MBS业务的密钥，则：

·如果组中的设备离开，则该设备也能够访问内容，

·如果设备加入组，则该设备能够访问先前的内容，

·如果组中的设备是恶意的，则该设备能够注入虚假内容。

5.3.3潜在的安全要求

用于保护MBS业务的密钥在密钥生成器与UE之间的分发应是机密性、完整性和防重放保护的。

5GS应能够更新用于保护MBS业务的密钥。

****变化1结束****

****变化2开始****

解决方案#2：在服务层保护MBS业务

6.2.1解决方案概述

该解决方案解决了关键问题2和关键问题3，以支持通过5GS从上下文提供商到多个UE的安全MBS业务递送。在TR 23.757[2]中的基线架构2中，MBSU(多播/广播服务用户平面(Multicast/Broadcast Service User Plane))被定义为处理有效载荷部分以满足服务级功能和管理的新实体。类似地，基线架构1中的MSF用户平面(MSF-U)也被定义在服务层中。该解决方案保护了在运营商域中的MBSU/MSF-U与UE之间的MBS业务。它独立于应用层中来自内容提供商的保护。

在SMF中生成用于保护MBS业务的密钥。然后，将密钥分别分发到UE和MBSU/MSF-U。属于多播组的UE在MBSU/MSF-U中获取相同的密钥。可以以高效的方式更新密钥。

6.2.2解决方案详情

替换图6.2.2-1。在服务层保护MBS业务的过程如图16所示。

过程描述如下：

1.UE注册5GS并建立PDU会话。

2.内容提供商使用较高层(例如，应用层)公告多播的可用性。

3.UE发送PDU会话修改请求。应该发送关于多播组的信息，包括UE希望加入的多播组的标识符。Multicast_group_ID可以是多播地址或其他标识符。

4.AMF调用Nsmf_PDUSession_UpdateSMContext，其中包括关于多播组的信息。

编者注：如果SA2同意经由UP支持UE的多播会话加入/离开操作(例如，IGMP加入/

离开)，则需要修订步骤3和步骤4。

5.如果MBS上下文在(MB)-SMF中不可用，则(MB)-SMF与UDM交互，以检查系统中是否存在用于多播组的多播上下文。

6.(MB)-SMF使用Namf_N1N2MessageTransfer服务请求AMF将消息传送到RAN节点，以在RAN中创建多播上下文(如果它尚未存在的话)。如果UE需要查找MBSU/MBS-U，则可以包括MBSU/MBS-U的IP地址。

7.将N2会话修改请求发送到RAN。

8.RAN向UE发送RRC重新配置请求消息。

9.如果允许UE访问MBS业务，则UE根据Kasuf推导多播用户密钥(MUK)，并使用Multicast_group_ID作为输入参数。

编者注：MUK推导是FFS。

编者注：在重新认证后的密钥更新过程是FFS。

10.SMF请求MUK并向AUSF发送Multicast_group_ID。

11.AUSF基于Kasuf和Multicast_group_ID推导多播用户密钥(MUK)。

12.AUSF利用MUK响应SMF。

13.SMF将MUK分发给MBSU/MSF-U。

14.MBSU/MSF-U接收并存储MUK。之后，向SMF响应ACK。

15.继续多播服务发起过程。

16.MBSU/MSF-U检查针对该多播组的MBS安全上下文是否可用。MBS安全上下文用于MBS业务保护，包括key_ID、K_group_enc、K_group_int、加密和完整性算法。key_ID用于指示使用的密钥对。K_group_enc和K_group_int分别用于MBS业务的加密和完整性保护。

如果为否，则MBSU/MSF-U生成K_group并推导K_group_enc和K_group_int。选择加密和完整性算法。

17.UE基于MUK来计算令牌并向MBSU/MSF-U请求业务密钥。

编者注：令牌构造是FFS。

18.MBSU/MSF-U使用MUK验证令牌，如果成功，则向UE分发MBS安全上下文。

编者注：消息名称和流可能会更新，以与SA2和RAN WG的结论保持一致。

编者注：漫游方面是FFS。

6.2.2.1用于高效组密钥分发和更新的MBS安全内容

本节解释图6.2.2.1中步骤18的逻辑。

将具有N个成员的多播组划分为M个集合S_i，其中i＝{1,M}。每个集合大致有L～N/M个UE。每个UE具有三个密钥：特定于设备的密钥MUK；与同一集合中的其他L-1个设备共享的传输密钥K_transport_i；与所有N个设备共享并用于保护多播内容的组密钥。MUK用于在点到点连接中安全地递送传输密钥。传输密钥用于以多播方式安全地递送组密钥。密钥层级如下所示，其中箭头指示保护。

MUK->K_transport_i->K_group

E{K1；K2}表示利用密钥K1对密钥K2进行认证加密，并且用于指示密钥的安全递送。

组密钥的分发和更新通过两个消息完成：

·消息18a：UE接收针对其所属的集合的密钥传输，以利用UE的MUK进行保护。

UE首先验证消息认证码，如果正确，则解密其传输密钥。新鲜度可以通过多种方式实现。例如，可以使用依赖于在步骤17中交换的初始访问令牌的增加的初始化向量。

·消息18b：通过利用点到点或多播消息中的传输密钥来保护新的组密钥，从而分发新的组密钥。包含组密钥的散列。

UE首先搜索消息中被寻址到其集合的部分。例如，如果UE属于集合z，则UE需要查找E{K_transport_z；K_group}。然后，UE验证消息认证码，如果正确，则解密新的组密钥。可以通过使用与用于内容数据分发的相同的新鲜度计数器来实现新鲜度。最后，UE还检查经解密的密钥的散列是否等于附加在该消息末尾的组密钥的散列H。

这两个消息可以结合起来以处理不同的情况：

1.到UE的初始密钥分发：在组合了18a和18b的相同消息中向UE提供其传输密钥和组密钥。

2.由密钥组使用时间过长而触发的密钥更新：消息18b用于向所有UE分发新的组密钥。

3.由新设备加入组而触发的密钥更新：消息18a用于向新UE递送对应的传输密钥。然后，消息18b用于向所有UE分发新的组密钥。

4.由UE离开/被撤销而触发的密钥更新：如果UE离开或被撤销，则与其集合相关联的传输密钥和组密钥被破坏。为了处理这种情况，消息18a被发送到其集合中的L-1以更新传输密钥。之后，消息18b用于向所有UE分发新的组密钥。

这种方法是高效且有弹性的，如下：

·由于设备离开而更新组密钥只要求L-1+M个消息，而不是在只涉及点到点消息时要求的N个消息。例如，如果N＝1600、M＝40、L＝40，那么密钥更新只要求39个点到点消息用于传输密钥更新，并且要求40个消息用于组密钥更新。

·由于使用了M个传输密钥，因此破坏UE的攻击者只能尝试更新最多L-1个设备的组密钥。这限制了这种攻击的影响，特别是与使用单个密钥传输组密钥的情况相比，其中N-1会受到影响。此外，在消息18b中包括组密钥的散列，使得其他集合中的设备可以检查一致性、检测攻击、并通知5MBS。从这个意义上说，这个解决方案是M弹性的。

以下参考TR 33.850-040中关于UE重新认证的解决方案2的编者注。UE重新认证期间的过程如下：

·步骤0：UE开始重新认证过程，进入步骤1。

·步骤1：在重新认证过程期间：

o步骤1.1：UE尝试使用其已知的组密钥来处理传入的受保护的MBS业务。如果成功，则进入步骤2。

o步骤1.2：如果UE无法处理传入的受保护的MBS业务，则UE尝试通过使用其先前的传输密钥访问消息18b中定期分发的新的组密钥。如果UE成功，则UE访问新的组密钥并进入步骤2。

o步骤1.3：UE等待新的传输密钥和组密钥的递送。这两个密钥通过消息18a和18b递送。只有在重新认证和重新授权过程成功并且利用MUK保护的情况下，才会递送这些密钥。一旦UE接收到这些密钥，UE就进入步骤3，否则进入步骤2。

·步骤2：UE未被认证或授权访问MBS业务。

·步骤3：UE具有当前组密钥和传输密钥，并且可以访问受保护的MBS业务和任何组密钥更新。

我们注意到，步骤1.2要求利用集合(传输)密钥保护的新的组密钥的更新不利用旧的组密钥保护。我们注意到，当希望在UE重新认证期间优化密钥更新过程时，不这样做是有利的。

我们注意到，上述过程被优化以改进用户体验，因为通过尝试使用UE已经具有的组密钥和传输密钥，即使在UE被重新认证之前，UE也可以尝试访问MBS业务。这是步骤1.1和步骤1.2中所做的。如果这些密钥起作用，则UE可以直接访问业务。如果这些密钥不起作用，可能是由于两个原因。第一个原因是由于定期密钥更新或其他UE离开多播组而更新密钥。第二个原因是UE本身不再被允许，并且它不应该访问MBS业务。

我们注意到，如果不使用传输密钥，则应跳过上面的步骤1.2，并且步骤1.3只包含消息18a。

上述实施例中描述的密钥层级使用用于更新组密钥的M个不同的传输密钥(K_transport_i)。因此，这种方法减少了将传输密钥从N到N/M的更新所要求的单播消息/点到点交互的数量。然后，可以通过发送利用M个不同的传输密钥保护的新的组密钥来更新组密钥。如果UE频繁地离开或加入MBS组，并且在这些情况下应用了要求更新组密钥的安全性，则该方法显著地减少了信令开销。原因在于，如果只具有单个传输密钥(就像LTE的情况一样)，则将要求更新传输密钥，从而要求N个单播交互。一旦更新了传输密钥，就可以分发例如利用新的传输密钥保护的组密钥。相反，具有M个传输密钥意味着要求N/M-1个单播消息来更新被破坏的密钥，并且需要通过多播信道分发M个受保护的组密钥，因此总共需要发送N/M-1+M个密钥。当M大致为SQRT(N)时，这大约等于2*SQRT(N)。在MBS组的成员相当静态(不离开或加入)并且应用了要求组密钥非常频繁地轮换(rotation)的策略的设置中可能会出现问题。在这样的设置中，上面在TR33.850中的解决方案#2的上下文中提出的方法可能具有更高的开销，因为使用了多个传输密钥来保护新的组密钥。为了解决这个问题，可以应用稍微更复杂的密钥层级，该密钥层级可以被视为MBMS(LTE解决方案)中的密钥层级和上面提出的密钥层级的组合。在这个新的密钥层级中，有M+1个传输密钥：

·M个如上所述的传输“集合”密钥(K_transport_i)，即，这些传输密钥中的每一个由L＝N/M

个UE的不相交集合使用。

·1个传输“公共”密钥(K_transport_common)，该密钥对所有UE都是公共的。

在该设置中，如果：

·MBS组UE成员保持静态，并且组密钥需要频繁轮换，然后使用传输“公共”密钥安全地分发新的组密钥。这是安全的，因为UE成员没有改变，因此所有M+1个传输密钥保持有效。这是高效的，因为使用单个密钥安全地发送更新后的组密钥。

·MBS组UE成员是动态的，当UE离开或加入时，L-1个单播消息用于更新“被破坏的”

传输“集合”密钥。回想一下，这L-1个消息是使用特定于UE的MUK密钥来保护的。然后，通过经由多播信道发送利用M个传输“集合”密钥保护的这两个密钥来更新新的组密钥和新的传输“公共”密钥。可替代地，通过经由多播信道利用M个传输“集合”密钥来保护新的传输“公共”密钥来更新该新的传输“公共”密钥，然后也经由多播信道使用新的传输“公共”

密钥来更新新的组密钥。

图15描述了相关的密钥层级。第一个是在LTE中使用的密钥层级，也是TR 33.850中的解决方案12中使用的密钥层级。这里，每个UE具有用于通过单播信道安全地接收MSK的MUK。MSK对于所有UE是公共的，并且可以用于通过多播信道向所有UE分发MTK，即，组密钥。第二个(密钥层级A)指代在不使用传输密钥时的上述默认解决方案。在该密钥层级中，使用特定于UE的唯一密钥直接更新MTK。第三个(密钥层级B)有与多达L个UE的不相交集合相关联的多个M个MTK。UE使用特定于设备的MUK来安全地接收其MSK。然后，使用所有M个MSK来分发MTK。第四个(密钥层级C)是上面描述的密钥层级，其中有M个MSK，这些MSK中的每一个绑定到多达L个UE的不相交集合(传输“集合”密钥)和对所有UE公共的1个MSK(传输“公共”密钥)。图15中的密钥层级可应用于例如TR 33.850中的解决方案#12或该3GPP研究中的其他服务层解决方案。

保护MBS业务的实体(例如，NF或彼此交互的多个NF)将管理密钥层级和负责确定密钥的更新频率以及在哪些情况下更新的策略：

·组密钥的定期密钥更新，包括例如频率或最大使用。

·传输“公共”密钥的定期密钥更新，包括频率或最大使用。

·当UE离开或加入时的传输“集合”密钥的更新。

·当UE离开或加入时的传输“公共”密钥和/或组密钥的更新。

在TR 33.850中，认证和授权在关键问题#1的范围内。MBS业务的保护在关键问题#3的范围内。在上述解决方案中，重新认证的过程仅取决于解决方案2的实现方式，然而，(重新)认证将作为不同解决方案的一部分进行处理。例如，在TR 33.850-040中，解决方案6针对多播通信服务执行认证和授权。解决方案6基于K_AKMA这样做。特别地，根据K_AKMA推导密钥K_MBS并将其用于认证和授权。在其他解决方案(例如，解决方案2)中，设备密钥MUK用于递送组密钥。在这种情况下，MUK是根据K_ausf导出的。接下来解决的问题关于如何将TR33.850中解决不同关键问题(例如，KI#1和KI#3)但最终需要一起工作的解决方案放在一起。

为了解决这个问题，要求在相关的密钥层级中描述用于认证/授权的密钥和用于递送密钥更新的密钥。在解决该问题的实施例中，这是如下完成的：

K_AUSF
		↓
K_AKMA
		↓
K_MBS
		↓	↓
K_MBS_Authentication_Authorization	K_MUK

根据3GPP TS 33.535 16.0.0版本16中描述的K_AUSF推导K_AKMA。然后使用K_AKMA来推导用于UE和给定的MBS服务的主K_MBS密钥。根据该K_MBS密钥，推导两个密钥。第一密钥K_MBS_Authentication_Authorization用于认证和授权过程，例如，在TR 33.850的解决方案6中。这意味着在解决方案6中，K_MBS中缺少了附加的密钥推导步骤。第二密钥K_MUK用于递送用于保护多播业务的组密钥。例如，该K_MUK出现在解决方案2中，这意味着解决方案2应该被修改为根据K_MBS和K_AKMA推导K_MUK，而不是直接根据K_AUSF推导。我们注意到，当推导上述密钥中的一些密钥(例如，K_MUK)时，计数器c可以用作密钥推导函数的输入，以在当前认证和授权会话内获得多个K_MUK。

以上密钥层级的替代方案如下：

K_AUSF
	↓
K_AKMA
	↓
K_MBS
	↓
K_MUK

这里的区别在于K_MUK(用于解决方案2)是根据K_MBS(用于解决方案6)推导的。特别地，K_MUK可以根据K_MBS、在认证和授权过程期间交换的信息以及计数器c来推导。在密钥需要在当前认证和授权会话中轮换时，计数器允许推导多个K_MUK。

我们注意到，如果UE重新认证，则上述密钥层级没有描述K_MUK是否应该改变。在重新认证的情况下，触发K_MUK的更新是一种选择。这可以通过上述计数器c来完成。

我们注意到，在UE重新认证的情况下，即使像解决方案2中一样保持密钥层级K_AUSF→MUK，也可能需要改变MUK。主要原因在于重新认证可能会触发K_AUSF本身的更新。TS33.501-A.2描述了K_AUSF生成的过程，并且其取决于例如服务网络名称。如果发生这种情况，则保持与提交给3GPP SA3#102-e-Bis的提案S3-210919中提出的相同的MUK可能会导致同步问题。例如，假设UE通过认证和生成第一MUK密钥而加入MBS服务。然后UE空闲很长时间。稍后，UE重新加入触发其重新认证。然而，假设UE或核心网可能已经删除了旧的MUK，例如，因为UE空闲的时间很长。如果只有一方已经移除了旧的MUK，则该方将生成一个新的MUK。然而，如果K_AUSF由于重新认证过程已经改变(例如，如果UE通过不同的服务网络加入)，则新的MUK将不匹配旧的MUK。通常，并且独立于解决方案2，用于分发传输密钥或组密钥的设备密钥应该在(重新)认证之后更新。

在K_MUK之后，如果UE正在使用使用集合密钥(或传输密钥)的解决方案，则对应的集合密钥也可能要求更新。对于用于保护MBS业务的组密钥也是如此。然而，这样做可能会导致高信令开销。通常，更好的方法是保持以下各项独立：(i)用于认证/授权和分发集合密钥/组密钥的密钥；以及(ii)集合密钥和MBS组密钥。特别地，可能只有在UE的重新认证过程失败时才需要更新集合密钥和MBS组密钥。

这里呈现的解决方案可以被认为是带内密钥更新机制。然而，一些解决方案将控制平面和用户平面拆分开。控制平面用于递送密钥组的更新，而用户平面负责递送多播业务。例如，这种拆分出现在例如TR 33.850-040的解决方案8中。在该解决方案中，(MB)-SMF解决方案负责生成组密钥(MTK)和对应的密钥标识符(KID)。该密钥和标识符稍后在核心网中与MBSF-U共享。该密钥和标识符稍后通过控制信道与UE共享。内容提供商将多播数据递送到MBSF-U，该MBSF-U负责通过用户平面将多播数据分发到连接到服务的所有UE。这是通过利用组密钥保护多播数据完成的。

在密钥更新的情况下，订阅该服务的所有N个UE都需要获得密钥更新。如在本文档中所讨论的，这可能涉及许多通信资源，不仅因为每个UE都需要被通知，而且因为每个UE也应该确认密钥更新的正确接收。

本实施例中的思路也可以应用于改进涉及用户平面和控制MBS平面的拆分的该解决方案。当调度组密钥时，将执行以下操作：

·步骤1，(MB-)SMF生成新的组密钥。

·步骤2，如果UE已经离开MBS、已经被撤销等，则(MB-)SMF还生成与UE所属的设备的集合相对应的新的集合密钥。(MB-)SMF通过控制平面将新的集合密钥分发到集合中的(M-1)个设备，该新的集合密钥将用于安全地传输新的组密钥。该消息等效于TR 33.850中解决方案2中的消息18a。

·步骤3，(MB-)SMF与MBSF-U共享新的组密钥(如当前描述所示)和密钥更新消息，其中新的密钥组利用L个组密钥来保护。这等效于TR 33.850中解决方案2中的消息18b。

·步骤4，当MBSF-U接收到该密钥更新时，通过将该信息连同常规多播内容一起在带内发送，MBSF-U首先分发密钥更新，即，利用L个组密钥保护的新的组密钥(等效于TR33.850中解决方案2中的消息18b)。因此，利用当前的组密钥保护该信息。这可以多次进行，以确保UE接收到该密钥更新。

·步骤5，MBSF-U可以切换到使用新的组密钥。

在上述过程的扩展中，当UE在步骤4中获得密钥更新消息时，UE还可以通知(MB-)SMF接收到这样的密钥更新。在该扩展中，(MB-)SMF将等待UE中的大多数已经确认接收到密钥更新或计时器超时，然后将触发组密钥切换的该事件通知MBSF-U(上面的步骤5)。

如果应用了先前的扩展，则在步骤3中可能仅包括密钥更新消息，并且新的组密钥的递送可以延迟到(MB-)SMF通知MBSF-U UE中的大多数已经接收到密钥更新的时刻。

如果应用了先前的扩展，则“UE中的大多数”意味着订阅MBS服务的N个UE的给定百分比，例如，UE的99％。对于其余的UE，(MB-)SMF可能选择通过控制信道进行直接连接。类似地，“计时器超时”意味着MBSF-U已经分发密钥更新消息达足够长的时间段，并且应该通过控制信道直接联系尚未确认接收到消息的UE。

我们注意到，这种拆分适用于通过控制信道递送的集合密钥(或传输密钥)的递送和通过用户平面在带内递送的组密钥的递送。对于任何参数(N，M，L)都可以在该解决方案中完成，特别地，如果存在单个集合/传输密钥，也可以这样做。

在SA3#102-e-Bis中，方案S3-210857提供了用于安全密钥分发的框架。该框架定义了生成用于加密和完整性保护的两个广播密钥(即，KMTentt和KMTint)的两个密钥推导函数的输入和输出。到KDF中的每一个KDF的输入包括：1)更新密钥令牌，2)多播组令牌，3)算法标识符，以及4)临时移动组标识符(TMGI)。网络以安全的方式(特别是通过安全的RRC消息)向UE提供2)和4)。然后，UE和RAN可以生成相同的KMTentt和KMTint。如果要求更新密钥，则网络可以向UE提供更新密钥令牌，使得UE和RAN两者可以生成新的多播密钥KMTentt和KMTint。注意，在该解决方案中，元素2)多播组令牌扮演主多播密钥的角色。因此，该参数应该以安全的方式生成，并且要足够长。该提案S3-210857还可以受益于本申请中描述的方法，以减少信令消息的量。特别地，如果需要由UE生成新的多播密钥，则该提案S3-210857要求向每个UE发送N个安全消息，包括新的更新密钥令牌。虽然更新密钥令牌不要求机密性保护，但它确实要求完整性保护。可以将N个UE划分为M＝N/L个设备的集合，而不是发送N个完整性保护消息。每个设备的集合都具有不同的集合密钥或传输密钥。这些传输密钥用于在那些保持不变的设备的集合要求时递送上述元素。这种递送是以多播方式进行的。如果设备的集合已经改变(新的UE已经加入/离开)，那么新的传输密钥和上述元素中的任一个可以通过RRC保护的消息来递送。

我们注意到，在该解决方案中，如果UE离开组，则离开的UE知道用作主密钥的多播组令牌。将本说明书中描述的方法应用于该解决方案的一种方式是使用每个基站不同的更新密钥令牌。如果使用不同的更新密钥令牌(即，更新密钥材料是基站的函数)，则只需要更新UE从其离开的基站的更新密钥令牌。否则，如果在所有基站中使用相同的更新密钥令牌，则当UE在位于特定基站时离开MBS组将迫使5GS更新所有基站中的所有UE。这是不高效的，并涉及更多的信令开销。

在该特定解决方案(以及S3-210857和通过控制信道更新MBS加密和完整性密钥的其他解决方案)中，一旦通过多个RRC消息向UE发送更新密钥令牌，则应使用新的K_MT_enc和K_MT_int。旧的K_MT_enc和K_MT_int密钥和新的密钥可能需要在一段时间内处于活动状态。当基站开始使用新的MBS加密和完整性密钥时，基站(或保护和发送MBS业务的实体)可以通过在多播数据(用户平面)中包括MBS加密和完整性密钥的标识符来向UE指示该密钥切换。可替代地，基站可以使用和翻转多播数据信道中的单个位来指示从旧密钥到新密钥的切换。

我们注意到，这个提案S3-210857有两个设计缺陷，因为它在图6.X.2.2-1中的消息8和图6.X.2.3-1中的消息7中声明RRC消息是加密的。该提案没有提及完整性保护。在消息8的情况下，元素2)的分发需要加密。然而，完整性保护也是必须的，因为否则的话可能修改消息并拒绝对UE的服务。在消息7的情况下，要求也是完整性保护和新鲜度。如果元素1)是计数器，则计数器可以是公共的，但接收方需要能够验证其完整性和新鲜度。

我们注意到，在本提案S3-210857中，如果1)是计数器，则即使计数器改变，已经被撤销的UE仍然能够访问MBS业务，因为UE只需要更新其计数器。因此，更新密钥令牌必须足够长(例如，128位或更长)并且必须随机生成。较短的更新密钥令牌(例如，32位或64位)是不够的，因为攻击者可以提前预计算密钥，然后在分发更新密钥令牌时拾取正确的密钥。攻击者还能够记录业务，并在稍后的时间点进行解密。

在SA3#102-e-Bis中，提案S3-211144为生成MBS密钥提供了另一种解决方案。该解决方案类似于S3-210857，因为MBS加密和完整性密钥是根据来自包括计数器和随机值的多个参数的主密钥推导的，而不是根据需要分发新密钥。与S3-210857的情况一样，该解决方案还可以受益于本申请中描述的方法以减少信令消息的量。例如，密钥的集合可以对应于通过特定基站接收MBS服务的UE。同一集合中的设备共享集合密钥或传输密钥。当需要在基站中的所有UE中更新MBS加密和完整性密钥(S3-211144中图6.X.2.1-1中的KMRB-int和KMRB-enc)时，基站通过多播信道MRB(PTM)递送更新KMRB-int和KMRB-enc所要求的参数，例如，RANDMBS和CountMBS。这些参数利用对应的传输密钥来保护。

接下来，我们要注意的是，S3-211144假设其中KMBS是递送给RAN的主密钥的密钥层级。根据该密钥，生成特定于gNB的密钥如下：

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

PCI和ARFCN-DL的使用将密钥绑定到特定的RAN小区。然而，这也有很大的缺点，即，如果UE离开MBS组或被撤销，则需要更新递送MBS业务的所有基站中的密钥。这导致了很大的信令开销。这是因为对于递送给定MBS服务的所有基站使用相同的主密钥。在这种情况下以及在其他系统中，可以通过几种方式来改进这一点：

·每个基站随机生成不同的特定于gNB的密钥KMBS-RAN。

·密钥层级包括与跟踪区域相关的中间级别，例如，在RAN与KMBS之间的中间级别。该中间密钥KMBS-TA是特定于跟踪区域的，并且旨在减少密钥更新的影响。

·UE不接收KMBS，而是只接收特定于gNB的密钥KMBS-RAN或中间密钥，例如，S3-211144中图6.a.2.1-1中的消息5和11中的KMBS-TA。

我们注意到，如果UE不能访问主MBS密钥，则移动性(切换)过程应该被修改，使得UE被告知目标MBS RAN密钥或目标MBS TA密钥。

需要注意的是，由于

(i)K_MBS-RAN被计算为KDF{K_MBS,TMGI,RAND_MBS,Count_MBS,PCI,ARFCN-DL}，

(ii)如果UE离开组，则K_MBS-RAN只取决于RAND_MBS安全性，以及

(iii)只有具有离开/被撤销的UE的gNB的K_MBS-RAN需要更新，

因此，不需要K_MBS。这同样适用于提案S3-210857中的多播组令牌。

此外：

1.该解决方案实质上等效于安全地将RAND_MBS(用于RAN的密钥)直接分发给UE的解决方案，如方程(0)所示，以根据其推导K_MRB-int和K_MRB-enc，如(1)、(2)、(3)所述。

RRC(RAND_MBS,TMGI,Count_MBS,PCI,ARFCN-DL)(0)

在该方法中，UE单独接收并检查所有其他参数，即，TMGI、Count_MBS、PCI、ARFCN-DL。可替代地，K_MBS-RAN也可以被直接分发。

2.如果我们如下计算参数，则可以得到类似的解决方案：

K_MBS-RAN＝KDF{TMGI,RAND_MBS,CountMBS,PCI,ARFCN-DL}(1)

K_MRB-enc＝KDF{K_MBS-RAN，算法类型区分器值，算法标识符值}(2)

K_MRB-int＝KDF{K_MBS-RAN，算法类型区分器值，算法标识符值}(3)

在(1)中，与S3-211144中的当前文本相比，移除了K_MBS，因为安全性不依赖于它。

3.在另一替代解决方案中，也可以跳过KDF操作，并将K_MRB-enc和K_MRB-int计算为(4)和(5)：

K_MRB-enc＝KDF{TMGI,RAND_MBS,Count_MBS,PCI,ARFCN-DL,K_MBS-RAN,算法类型区分器值，算法标识符值}(4)K_MRB-int＝KDF{TMGI,RAND_MBS,Count_MBS,PCI,ARFCN-DL,K_MBS-RAN,算法类型区分器值，算法标识符值}(5)

其中通过消息(0)将所有参数分发给UE。

在(1)、(4)和(5)中，由于该消息是在来自该特定基站的RRC消息中分发的，因此可以移除PCI。

在SA3#102-e-Bis中，提案S3-210918提供了另一种用于生成MBS密钥的解决方案，该解决方案在某种程度上类似于TR 33.850中的解决方案8。在这个新的解决方案中，MBSF-C生成新的组密钥(MTK2)，并且该新的组密钥(MTK2)被分发给MBSF-U和(MB)-SMF。(MB)-SMF负责通过单播信令消息将这个新密钥递送给UE。一旦完成，(MB)-SMF通知MBSF-U。在该通知之后，MBSF-U开始使用该密钥MTK2来保护MBS数据。该解决方案可以受益于所描述的实施例以减少信令开销。特别地，MBSF-C或(MB)-SMF可以将UE分发到集合中，每个集合与相应的传输密钥相关。因此，新的组密钥MTK2可以通过多播流被分发到利用该传输密钥保护并且仍然利用旧的MTK2密钥保护的UE。当UE接收到更新时，UE通知(MB)-SMF将跟踪知道新密钥的所有UE。对于那些没有响应的UE，(MB)-SMF可以使用S3-210918中提出的单播密钥更新修改。一旦(MB)-SMF已经确保注册到MBS业务的UE中的大多数已经接收到新的MTK2密钥，(MB)-SMF就向MBSF-U发送MTK激活通知。

我们注意到，提案S3-210918在步骤6(密钥更新通知)中假定单向链路从(MB)-SMF到UE。这可能是不够的，因为UE可能错过信令消息，并且这可能导致MBS数据的接收中断。我们注意到，当前的提案可能要求在(MB)-SMF处的策略，描述当UE的某个百分比尚未确认接收到密钥更新通知消息时要如何处理。特别地，该策略可以包括在MTK激活通知被发送到MBSF-U之前可能尚未确认接收到消息的UE的相对或绝对数量。该策略还可以包括计时器，如果计时器过期，则触发发送该通知。该策略还可以定义应该如何管理未确认密钥更新通知的UE，例如，该消息应该被发送多少次。

在SA3#102-e-Bis中，提案S3-211070为MBS密钥和MBS业务的生成和分发提供了另一种解决方案。该解决方案依赖于三个密钥：MUK(特定于设备的密钥)、MSK和MTK。MUK用于通过安全连接在单播消息中分发MSK。MTK通过MSK来保护。MTK可以在单播或多播消息中递送。MTK或根据其推导的密钥用于保护MBS数据。该提案S3-211070与本文档中公开的思路相似。主要区别在于S3-211070似乎包括单个MSK。如果MBS服务中的UE被划分为M个集合，每个集合使用不同的MSK，则S3-211070可以受益于本文档中的思路。为此，要求多播业务密钥的递送包含利用不同MSK加密的MTK。该解决方案使用密钥层级以根据具有AKMA的KAF推导MUK，如本文档中先前所描述的(KAUSF->KAKMA->KMBS(KAF)->MUK)。

这些装置可以分别通过一种计算机程序和/或作为相关设备的专用硬件的程序代码单元来实现。该计算机程序可以存储和/或分布在适当介质上，该适当介质例如为光存储介质或固态介质，该计算机程序与其他硬件一起提供或作为其他硬件的一部分提供，但该计算机程序也能够以其他形式分布，例如，经由互联网或者其他有线或无线电信系统分布。

参考文献

[1]TR 23.757v1.0.0

[2]TR 33.850v0.2.0

[3]TS 33.246-g00 3(MBMS安全性)

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

Claims (22)

1.一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的多播受保护的通信，

b.在确定要求更新时，通过经加密的消息向所述次站的至少一个子集发送更新后的密码密钥。

2.根据权利要求1所述的方法，其中，所述更新后的密码密钥是更新后的组密钥，并且其中，所述经加密的消息通过特定于用户的加密密钥进行加密并且以单播方式发送。

3.根据权利要求1所述的方法，其中，确定组密钥是否需要被更新包括确定是否满足以下条件中的至少一个条件：所述次站的访问权限中的至少一个访问权限已经被撤销、所述次站的访问权限中的至少一个访问权限已经过期、所述组密钥的有效时间已经过期、所述次站中的至少一个次站已经离开预定位置。

4.根据权利要求1所述的方法，其中，所述更新后的密码密钥是共享给次站的第一集合的第一集合密钥。

5.根据权利要求4所述的方法，其中，在步骤a处确定所述次站中的属于所述第一集合的至少一个次站的访问权限当前无效时，更新所述第一集合密钥。

6.根据权利要求5所述的方法，还包括以下步骤：通过利用关联于次站的每个集合的相应集合密钥保护的消息，将更新后的组密钥发送到次站的每个集合。

7.一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

b.在确定要求更新时，在相应的多播消息中向次站的相应集合发送更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

8.根据权利要求7所述的方法，其中，确定组密钥是否需要被更新包括确定是否满足以下条件中的至少一个条件：

-所述次站的访问权限中的至少一个访问权限已经被撤销，

-所述次站的访问权限中的至少一个访问权限已经过期，

-所述组密钥的有效时间已经过期，

-所述次站中的至少一个次站已经离开预定位置。

9.根据权利要求7或8所述的方法，还包括：如果在步骤a处确定所述组密钥与属于次站的第一集合的第一次站的访问权限无效相关，则通过受保护的单播消息向所述第一集合中的每个次站通过单播发送新的第一集合密钥。

10.根据权利要求9所述的方法，还包括步骤c：在多播消息中向所述次站的第一集合发送更新后的组密钥，所述多播消息通过所述新的第一集合密钥被加密。

11.根据权利要求9所述的方法，其中，所述受保护的单播消息还包括更新后的组密钥。

12.一种用于主站向多个次站分发密码密钥的方法，包括以下步骤：

a.确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

b.在确定要求更新时，通过受保护的单播消息向所述次站的至少一个第一子集通过单播发送第一集合密钥，

c.在多播消息中向所述次站的第一集合发送更新后的组密钥，所述多播消息通过所述第一集合密钥来保护，或者替代地在步骤b的所述受保护的单播消息中包括所述更新后的组密钥，

d.在相应的多播消息中向次站的另外的相应集合发送所述更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

13.根据权利要求7-10中任一项所述的方法，其中，所述次站的集合是基于位置形成的，并且其中，步骤d还包括：所述主站在至少一个另外的多播消息中发送所述更新后的组密钥，所述另外的多播消息通过在相邻集合中使用的相应集合密钥被加密。

14.根据权利要求13所述的方法，其中，相邻集合是驻留在由另一主站服务的小区中的多个次站的集合。

15.根据前述权利要求中任一项所述的方法，其中，多播消息是周期性地重传的。

16.根据权利要求7-15中任一项所述的方法，其中，所述多播消息包括所述更新后的组密钥以及认证指纹消息，所述认证指纹消息被计算为所述更新后的组密钥的散列。

17.一种用于次站在网络中接收密码密钥的方法，包括以下步骤：

a.通过受保护的单播消息从主站通过单播接收第一集合密钥，所述第一密钥与次站的第一集合相关联，

b.接收到所述次站的第一集合的多播消息并将所述多播消息解密为更新后的组密钥，所述解密使用所述第一集合密钥。

18.根据权利要求17所述的方法，其中，所述多播消息包括受保护的更新后的组密钥以及认证指纹消息，并且所述方法还包括所述次站通过检查经解密的组密钥的散列是否与接收到的认证指纹匹配来认证所述多播消息。

19.根据权利要求18所述的方法，还包括：如果所述检查失败，则向所述主站报告异常。

20.一种在蜂窝网络中操作并且与多个次站通信的主站，包括：

控制器，其适于确定组密钥是否需要被更新，所述组密钥用于从所述主站到所述多个次站的受保护的多播通信，

耦合到所述控制器的发射机，其适于在确定要求更新时，在相应的多播消息中向次站的相应集合发送更新后的组密钥，所述多播消息通过与每个对应的集合相关联的相应集合密钥来保护。

21.一种在蜂窝网络中操作并且与主站通信的次站，包括：接收机，其适于通过受保护的单播消息从主站通过单播接收第一集合密钥，所述第一密钥与次站的第一集合相关联；以及控制器，其适于将到所述次站的第一集合的多播消息解密为更新后的组密钥，所述解密使用所述第一集合密钥。

22.一种存储和/或分布在适当介质上的计算机程序和/或作为专用硬件的程序代码单元，所述适当介质例如为光存储介质或固态介质，所述计算机程序与其他硬件一起提供或作为其他硬件的一部分提供，但所述计算机程序也能够以其他形式分布，例如，经由互联网或者其他有线或无线电信系统分布。