基于IMS的多媒体广播和多播服务(MBMS)中的安全密钥管理

摘要

用于管理用户设备UE、诸如SCF/NAF的认证节点、以及诸如BM-SC或AS的服务节点之间的共享安全密钥的系统、方法、和节点。SCF/NAF从SCF/NAF管理的FQDN空间中向各BM-SC分配诸如完全合格域名FQDN的不同的SCF/NAF标识符。然后，SCF/NAF将这些分配的FQDN与连接的BM-SC以及与不同的服务本地地关联。该网络在预期服务的服务描述中向UE发送正确的FQDN，并且UE能够使用该FQDN来得出安全密钥。当UE请求预期服务时，SCF/NAF能够将服务标识符与正确FQDN及关联的BM-SC相关联。SCF/NAF使用FQDN从引导服务器获得安全密钥，并且将其发送到关联的BM-SC。因此，UE和关联的BM-SC共享特定安全密钥。

说明书

相关申请

本申请要求2009年4月1日提交的美国临时申请No.61/165809 的权益。

技术领域

一般来说，本发明涉及通信网络，并且具体来说，涉及用于管理 基于IP多媒体子系统(IMS)的多媒体广播/多播服务(MBMS)用户服务 中的共享安全密钥的系统、方法和网络节点。

背景技术

在若干第三代合作伙伴项目(3GPP)技术规范中描述与本发明相关 的现有规程。它们包括：

-3GPP TS 33.220 v8.5.0 Technical Specification Group  Services and System Aspects(技术规范组服务和系统方面)；Generic  Authentication Architecture(GAA)；Generic bootstrapping  architecture(一般鉴权架构(GAA)；一般引导架构(GBA))(发布版8)；

-3GPP TS 33.222 v8.0.0 Technical Specification Group  Services and System Aspects(技术规范组服务和系统方面)；Generic  Authentication Architecture(GAA)；Access to network  application functions using Hypertext Transfer Protocol over  Transport Layer Security(HTTPS)(一般鉴权架构(GAA)；使用超文 本传输协议在传输层安全性(HTTPS)上接入网络应用功能)(发布版 8)；

-3GPP TS 33.246 v8.2.0 Technical Specification Group  Services and System Aspects(技术规范组服务和系统方面)；3G  Security；Security of Multimedia Broadcast/Multicast Service (MBMS)(3G安全性；多媒体广播/多播业务(MBMS)的安全性)(发布版 8)；以及

-3GPP TS 26.237 v8.0.0 Technical Specification Group  Services and System Aspects(技术规范组服务和系统方面)；IP  Multimcdia Subsystem(IMS)based Paeket Switched Streaming(PSS) and Multimedia Broadcast/Multicast Service(MBMS)User Service； Protocols(基于IP多媒体子系统(IMS)的分组交换流动(PSS)和多媒 体广播/多播业务(MBMS)用户服务；协议)(发布版8)。

图1是来自TS 33.222的高级参考模型，示出使用引导服务的网 络应用功能(NAF)。网络实体在3GPP TS 33.220中定义，3GPP TS 33.220 规定通用引导架构(GBA)，其中移动通信装置(例如，用户设备(UE)11) 和引导服务器功能性(BSF)12通过Ub参考点来运行HTTP digest AKA， 并且因此建立共享密钥Ks。共享密钥Ks稍后用于得出NAF特定密钥(称 作Ks_NAF密钥)，以便保密UE与NAF 13之间通过Ua参考点的通信。 NAF通过Zn参考点来取回NAF特定密钥。

3GPP TS 33.222条款6规定NAF 13中的认证代理(AP)的使用。 AP与TS 33.220中规定的GBA架构兼容。当AP用于这种架构时，AP 通过充当NAF来减轻(relieve)应用服务器(AS)的安全任务。

图2是来自TS 33.222的高级参考模型，示出认证代理(AP)15的 环境和参考点。TS 33.222假定UE 11与NAF 13中的AP 15之间的使 用传输层安全性(TLS)。当HTTPS请求预计送往AP之后的应用服务器 (AS)16a-16n时，AP端接TLS隧道17，从BSF 12取回NAF密钥(Ks_NAF)， 并且执行UE认证。AP作为代理将从UE接收的HTTP请求送往一个或 多个AS。当AP将请求从UE转发给AS时，AP可添加订户识别码的断 言，供AS使用。

TS 33.222中为NAF密钥的使用定义的规程的问题在于，UE 11和 AS 16a-16n没有共享任何密钥资料，即使可能存在会需要这种共享密 钥资料的情况。AP 15充当TS 33.222中的NAF 13。因此，NAF密钥 (Ks_NAF)按照TS 33.220中规定的密钥推导规则是AP特定的，并且是 UE不知道的。

图3是来自TS 26.237的高级参考模型，示出用于密钥共享的当 前解决方案。NAF密钥与AS配合使用的上面定义的这个问题也可适用 于TS 26.237中定义的网络实体。在这种情况下，服务控制功能(SCF)21 充当NAF/AP的修改变体(并且因而标记为SCF/NAF)，并且MBMS广播/ 多播服务中心(BM-SC)22充当AS(并且因而标记为BM-SC/AS)。与图2 的AS相似，BM-SC/AS需要与UE 11的共享密钥，以便能够通过单播 或广播信道将受保护MIKEY密钥管理消息从BM-SC/AS直接发送到UE。

应当注意，TS 26.237没有提到与TS 33.222的AP 15和AS 16 的这种类比。TS 26.237中的设定与TS 33.222中不是精确相同的； 例如，不一定使用UE 11与SCF 21之间的TLS隧道。但是，类似问题 仍然保持不变。

在TS 26.237中，引入了一种解决方案，其中SCF 21将它自己的 NAF密钥(Ks_NAF)发送到BM-SC 22。BM-SC使用Ks_NAF作为MUK(MBMS 用户密钥)，这用于保护从BM-SC到UE 11的MIKEY密钥管理消息。图 3的步骤1-6按照当前GBA规范，而步骤7描述向BM-SC发送Ks_NAF 以及订户的被断言识别码。

只要仅一个BM-SC 22连接到SCF 21(并且只要SCF能够假定对 BM-SC的足够置信，使得BM-SC不会误用SCF特定NAF密钥)，则TS 26.237中的当前解决方案正常工作。当两个或更多BM-SC附连到SCF 时，则出现问题。这是因为，按照当前解决方案，SCF将它自己的Ks_NAF 发送到BM-SC，并且因此SCF会将同一Ks_NAF发送到所有连接的 BM-SC。将同一密钥给予若干节点不是良好的安全实践。这会引起同一 Ks_NAF密钥在UE 11与所有相关联的BM-SC之间使用的情况。这会揭 开诸如BM-SC对UE相互模仿的威胁。

图4是示出在现有基于IMS的MBMS登记过程期间在多种网络实体 之间发送的消息的消息流程图。该图基于如下前提：按照3GPP TS 33.203向IMS登记和认证了UE 11；UE与服务调度功能(SSF)(未示出) 进行了通信并且接收到如3GPP TS 26.237定义的可用服务的列表；UE 如3GPP TS 33.220所定义运行了与BSF 12的GBA引导；以及网络接 口采用3GPP TS 33.210中定义的网络域安全性(NDS/IP)来保护。

该过程如下，其中仅示出关于安全性过程的相关信息。UE 11经 由IP多媒体核心网络(IM CN)子系统32向SCF 21发送SIP INVITE消 息31。INVITE消息在请求URI中指示“SCF”，并且该消息在XML文 档的SIP消息主体中包含UE希望登记的被请求MBMS用户服务的识别 码(userServiceIds)。XML文档与用于TS 33.246中的MBMS登记的相 同，并且在TS 26.346中规定。另外，存在携带引导事务标识符(B-TID) 的XML文档。携带B-TID的XML文档在3GPP TS 26.237的附录I中定 义。

SCF 21从SIP INVITE消息31的报头接收UE 11的IP地址和UE 的一个或多个被断言识别码。SCF基于存储的预订信息来执行检查， 以便确定是否授权UE访问被请求MBMS用户服务。如果UE经过授权， 则该过程继续进行；如果未经授权，则该过程终止。如果不存在对该 UE存储的B-TID，或者如果接收的B-TID与对该UE存储的不同，则 SCF 21在33和34通过Zn参考点来运行与BSF 12的GBA使用过程， 以便取回与UE对应的NAF密钥，如TS 33.220所定义。SCF从NAF密 钥得出MBMS用户密钥(MUK)，如TS 33.246所定义。

SCF 21向BM-SC 22发送HTTP POST消息35。SCF按如下所述装 载HTTP POST消息：

-HTTP版本将为1.1，这在RFC 2616中规定；

-请求URI的基部(base)将包含完整BM-SC密钥管理URI(例如 http://bmsc.home1.net：1234)；

-请求URI将包含设置成“authorized-register”的URI参数 “requesttype”，即，请求URI采取 “/keymanagement？requesttype＝authorized-register”的形式；

-SCF可对请求URI添加附加URI参数；

-X-3GPP-Asserted-Identity报头，它包括UE的识别码；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-authorized-register+xml”；

-HTTP有效载荷将包含XML文档，其中包括UE希望登记的MBMS 用户服务的一个或多个userServiceIds、UE的IP地址、MBMS用户密 钥(MUK)、和MUK的存在期的列表。有效载荷的XML方案在3GPP TS 26.237的附录I中规定

-SCF可对HTTP POST请求添加附加HTTP报头。

BM-SC 22接收HTTP POST消息35，检验HTTP POST是有效的，并 且提取请求供进一步处理。由于HTTP POST消息来自具有被断言识别 码的SCF 21，所以BM-SC不需要认证UE 11，因为UE已经由IMS认证。 另外，HTTP POST消息还向BM-SC指示SCF已经授权UE向指示的MBMS 用户服务进行登记。

BM-SC存储接收的信息，并且向SCF 21返回HTTP 200 OK消息36。 BM-SC将按如下所述来装载HTTP 200 OK消息：

-HTTP状态行中的HTTP状态码将为200；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-register-response+xml”；

-HTTP有效载荷将包含XML文档，XML文档包括其中包含各MBMS 用户服务的一个状态码的列表。有效载荷的XML方案与用于TS 33.246 中的MBMS登记的相同，并且在TS 26.346中规定。

SCF 21接收HTTP 200 OK消息36，并把来自HTTP 200 OK消息的 XML主体包含到SIP 200 OK消息37中，并且经由IM CN子系统32向 UE 11发送SIP 200 OK消息。BM-SC 22这时能够按照TS 33.246中规 定的过程开始向指示的MBMS用户服务的UE发送MIKEY MSK消息(采用 MUK来保护)38、MTK消息(采用MSK来保护)39、和MBMS数据(采用MTK 来保护)40。

这个过程的问题与以上针对图3论述的相同，即，不存在当一个 以上BM-SC连接到SCF时提供BM-SC特定NAF密钥的方式。如果SCF 21 向所有连接的BM-SC发送同一Ks_NAF，则该同一Ks_NAF密钥会在UE 11 与所有相关联BM-SC之间使用。这会揭开诸如BM-SC对UE相互模仿的 威胁。

另外，在MIKEY MSK消息38中不存在足够信息向UE 11指示哪一 个MUK(即，NAF密钥)用于保护MIKEY MSK消息。在MBMS TS 33.246 中，NAF-Id和B-TID用于指示这个方面；但在TS 26.237中，BM-SC 22 没有充当NAF，并且因此它没有这种信息。

发明内容

在本发明的一个实施例中，SCF/NAF 21在GBA中如常从BSF 12 取回Ks-NAF。然后，不是SCF/NAF向(一个或多个)BM-SC/AS发送它自 己的Ks_NAF，而是SCF/NAF从SCF特定Ks_NAF进行进一步密钥推导， 以产生BM-SC/AS特定密钥Ks_AS。例如，Ks_AS＝KDF(Ks_NAF，nonce)， 其中，nonce(现时)是由SCF/NAF定义的并且是对相关联BM-SC/AS特 定的值。CF/NAF向UE 11指示nonce，UE 11则进行相同Ks_AS推导。 SCF/NAF还向UE指示BM-SC/AS的识别码，使得UE能够将得出的Ks_AS 密钥与正确BM-SC/AS相关起来。因此，UE和BM-SC/AS共享BM-SC/AS 特定密钥。

在一个实施例中，本发明针对一种在通信网络中用于管理通信装 置、认证节点、以及向通信装置提供请求服务的选择的服务节点之间 的共享安全密钥的方法。该方法包括下列步骤：由认证节点将多个认 证节点标识符与多个服务相关联，其中多个认证节点标识符标识认证 节点；以及由网络使预期服务的服务描述对通信装置可用，服务描述 包括多个认证节点标识符中与预期服务相关联的认证节点标识符，其 中认证节点标识符使通信装置能够得出安全密钥。该方法还包括由认 证节点向网络中的各服务节点分配多个认证节点标识符中的不同认证 节点标识符；并且由认证节点将分配的认证节点标识符与连接的服务 节点相关联。在从通信装置接收到预期服务的请求时，认证节点利用 与预期服务关联的分配的认证节点标识符来获得与分配的认证节点标 识符关联的连接的服务节点的安全密钥，并且将安全密钥从认证节点 发送到关联的服务节点。因此，当关联的服务节点向通信装置发送采 用安全密钥保护的密钥管理消息时，通信装置使用安全密钥对该消息 进行解密和检验。

在另一个实施例中，本发明针对一种在通信网络中用于管理通信 装置、认证节点、以及向通信装置提供请求服务的选择的服务节点之 间的共享安全密钥的方法。该方法包括下列步骤：由网络使至少一个 服务的服务描述对通信装置可用，服务描述包括认证节点的至少一个 标识符，其中各认证节点标识符与不同服务以及与不同服务节点相关 联；由通信装置基于已知信息以及在服务描述中接收的认证节点标识 符中的选择的一个来得出安全密钥，其中选择的认证节点标识符与预 期服务相关联；以及将预期服务的请求从通信装置发送到认证节点， 该请求包括事务标识符和预期服务的服务标识符。该方法还包括在认 证节点中将服务标识符与认证节点标识符相关联；由认证节点利用认 证节点标识符和事务标识符来获得安全密钥；识别与认证节点标识符 关联的服务节点；以及将预期服务的请求消息从认证节点发送到识别 的服务节点，该请求消息包括服务标识符、事务标识符、安全密钥和 通信装置的地址。因此，当识别的服务节点向通信装置发送采用安全 密钥保护的密钥管理消息时，通信装置使用安全密钥对该消息进行解 密和检验。

在另一个实施例中，本发明针对一种在通信网络中用于管理通信 装置以及向通信装置提供服务的服务节点之间的共享安全密钥的认证 节点。该认证节点包括运行存储器中存储的计算机程序指令的处理器， 该处理器控制认证节点的下列组件：用于将多个认证节点标识符与多 个服务相关联的部件，其中多个认证节点标识符标识认证节点；用于 向网络中的各服务节点分配多个认证节点标识符中的不同认证节点标 识符的部件；用于将分配的认证节点标识符与连接的服务节点相关联 的表；响应从通信装置接收到预期服务的请求而利用与预期服务关联 的分配的认证节点标识符来获得与分配的认证节点标识符关联的连接 的服务节点的安全密钥的部件；以及用于将安全密钥从认证节点发送 到关联的服务节点的通信部件。网络使预期服务的服务描述对通信装 置可用。服务描述包括多个认证节点标识符中与预期服务关联的认证 节点标识符，并且通信装置利用认证节点标识符来得出安全密钥。因 此，当关联的服务节点向通信装置发送采用安全密钥保护的密钥管理 消息时，通信装置使用安全密钥对该消息进行解密和检验。

在另一个实施例中，本发明针对一种在通信网络中用于利用共享 安全密钥向通信装置提供用户服务的服务节点。该服务节点包括运行 存储器中存储的计算机程序指令的处理器。该处理器控制服务节点的 下列组件：用于从认证节点获得认证节点标识符、通信装置的IP地址、 事务标识符和共享安全密钥的通信部件，其中事务标识符标识其中通 信装置已经请求服务节点提供的用户服务的事务；以及用于向通信装 置发送采用共享安全密钥保护的密钥管理消息的通信部件，密钥管理 消息包括认证节点标识符和事务标识符。当通信装置从服务节点接收 到密钥管理消息时，通信装置从认证节点标识符和事务标识符来识别 共享安全密钥。当认证节点向通信装置提供认证节点标识符时，或者 当通信装置接收服务描述中的认证节点标识符时，通信装置利用认证 节点标识符来得出共享安全密钥，并且使用共享安全密钥对密钥管理 消息进行解密和检验。

在另一个实施例中，本发明针对一种在通信网络中用于管理共享 安全密钥的系统。该系统包括：通信装置；与通信装置进行通信的认 证节点；以及与认证节点和通信装置进行通信的服务节点。该认证节 点包括：用于将多个认证节点标识符与多个服务相关联的部件，其中 多个认证节点标识符标识认证节点；用于向服务节点分配多个认证节 点标识符中的选择的认证节点标识符的部件；用于将分配的认证节点 标识符与连接的服务节点相关联的表；响应从通信装置接收到预期服 务的请求而利用与预期服务关联的分配的认证节点标识符来获得与分 配的认证节点标识符关联的连接的服务节点的安全密钥的部件；以及 用于向服务节点发送认证节点标识符、通信装置的IP地址、事务标识 符和共享安全密钥的通信部件，其中事务标识符标识其中通信装置已 经请求服务节点提供的用户服务的事务。该服务节点包括用于向通信 装置发送采用共享安全密钥保护的密钥管理消息的通信部件，密钥管 理消息包括认证节点标识符和事务标识符。移动通信装置包括：用于 从认证节点标识符和事务标识符来识别共享安全密钥的部件；用于接 收或者来自认证节点的或者在从网络获得的服务描述中的认证节点标 识符的通信部件；用于利用认证节点标识符来得出共享安全密钥的部 件；以及用于使用共享安全密钥对密钥管理消息进行解密和检验的部 件。

在基于IMS的MBMS和PSS用户服务中的密钥分发的一特定示范实 施例中，本发明有利地提供一种更安全的系统，其中UE与多个BM-SC 的每个共享不同(特定)的密钥，而不是与所有涉及的BM-SC共享同一 密钥。在用于获得认证代理(AP)情况的AS特定密钥的相关实施例中， 本发明有利地提供一种实现UE与应用服务器(AS)之间的共享秘密的 方式。这使得能够对具有AP的情况开发新种类的应用。本发明提供一 种更安全的系统，其中UE与各AS共享不同(特定)的密钥，而不是与 所有涉及的AS共享同一密钥。

附图说明

图1是取自TS 33.222的高级参考模型，示出使用引导服务的网 络应用功能(NAF)；

图2是取自TS 33.222的高级参考模型，示出认证代理(AP)的环 境和参考点；

图3是取自TS 26.237的高级参考模型，示出用于密钥共享的当 前解决方案；

图4是示出在现有基于IMS的MBMS登记过程期间在多种网络实体 之间发送的消息的消息流程图；

图5A-5B是示出在服务描述中向UE指示NAF-Id(SCF分配的FQDN) 时在发明的基于IMS的MBMS登记过程的第一实施例期间在多种网络实 体之间发送的消息的消息流程图的部分；

图6A-6B是示出在SIP 200 OK消息中向UE指示NAF-Id(SCF分配 的FQDN)时在发明的基于IMS的MBMS登记过程的第二实施例期间在多 种网络实体之间发送的消息的消息流程图的部分；

图7是示出用于基于IMS的MBMS和PSS用户服务中的密钥分发的 发明系统和方法的一实施例的高级参考模型；

图8是示出用于获得认证代理(AP)情况的AS特定密钥的发明系统 和方法的一实施例的高级参考模型；以及

图9是本发明系统的一示范实施例的简化框图。

具体实施方式

存在能够向UE指示将要在密钥推导中使用的NAF-Id的两种方式：

A)可在服务描述中向UE指示NAF-Id(SCF分配的FQDN)。基于 UE选择哪一个服务，UE则将使用对应NAF-Id。这与MBMS TS 33.246 中的当前过程相似，但是指示了BM-SC FQDN。

B)SCF可在SIP INVITE过程中向UE指示NAF-Id(SCF分配的 FQDN)，因为UE在SIP INVITE过程结束之前不需要使用NAF-Id。这 个备选方案的优点在于，SCF能够在服务请求被接收时向用户动态分 配BM-SC。这例如在负荷平衡中可能是有益的。

图5A-5B是示出在服务描述中向UE 11指示NAF-Id(SCF分配的 FQDN)时(即，上述备选方案A)在发明的基于IMS的MBMS登记过程期 间在多种网络实体之间发送的消息的消息流程图的部分。该图基于如 下前提：按照3GPP TS 33.203向IMS登记和认证了UE；SIP过程由 3GPP TS 33.203中定义的IMS安全性来保护；UE如3GPP TS 33.220 中定义的那样运行了与BSF 12的GBA引导；以及网络接口采用3GPP TS 33.210定义的网络域安全性(NDS/IP)来保护。

另外，SCF 21已经创建到一个或多个BM-SC 22a、22b的连接， BM-SC 22a、22b向UE提供实际MBMS用户服务。与TS 33.246中定义 的、其中BM-SC充当NAF的MBMS安全性不同，SCF代表BM-SC(一个或 多个)来充当NAF。BSF 12使用NAF-Id(它包括NAF的FQDN和Ua安全 协议标识符)作为对NAF密钥推导的输入。为了从BSF得到BM-SC特定 NAF密钥，SCF为各BM-SC分配分离的FQDN(从它管理的FQDN空间)。 SCF例如在表中将这些分配的FQDN本地地关联到连接的BM-SC。

由于两种原因而需要这些分配的分离的FQDN。首先，SCF 21不能 使用同一(例如，它自己的)FQDN，因为两个BM-SC则会得到同一NAF 密钥，这可能危及系统的安全性。其次，SCF不能使用BM-SC的FQDN， 因为BSF 12将进行检查以确定NAF是否有权使用NAF提供的NAF-Id。 作为一个示例，SCF可按如下方式为BM-SC_1 22a和BM-SC_2 22b分 配NAF-Id：

NAF-Id_1(FQDN)<＝>BM-SC1(FQDN)

NAF-Id_2(FQDN)<＝>BM-SC2(FQDN)

其中，例如，NAF-Id_1可以是server1.scf.operatorA.com，而 BM-SC1可以是bmsc123.operatorB.com。

参照图5A，在GBA引导过程42之后，执行服务描述检索过程43。 UE 11与SSF 41进行通信，并且检索服务描述44，即，可用服务及其 参数(例如，服务保护描述)的列表。服务保护描述与TS 33.246中定 义的相似，除了包含SCF分配的FQDN而不是BM-SC FQDN之外。假定 在这里还需要SCF 21的FQDN，使得UE知道将SIP INVITE消息47发 送到什么位置。

在45，用户从服务描述来选择服务，并且得出与服务描述中对选 择的服务指示的NAF-Id对应的NAF密钥。备选地，NAF密钥推导可在 SIP INVITE过程46之后执行。

UE 11经由IM CN子系统32向SCF 21发送SIP INVITE消息47。 INVITE消息在请求URI中指示SCF，并且该消息在XML文档的SIP消 息主体中包含UE希望登记的被请求MBMS用户服务的识别码 (userServiceIds)。XML文档与用于TS 33.246中的MBMS登记的相同， 并且在TS 26.346中规定。另外，存在携带引导事务标识符(B-TID) 的XML文档。携带B-TID的XML文档在3GPP TS 26.237的附录I中定 义。

SCF 21从SIP INVITE消息47的报头接收UE 11的IP地址和UE 的被断言识别码(一个或多个)。SCF基于存储的预订信息来执行检查， 以便确定是否授权UE访问被请求MBMS用户服务。如果是的话，则该 过程继续进行。如果不是的话，则该过程终止。

参照图5B，如果不存在对该UE存储的B-TID，或者如果接收的 B-TID与对该UE存储的不同，则SCF通过Zn参考点来运行与BSF 12 的GBA使用过程48，以便取回与UE对应的NAF密钥，如TS 33.220 定义的。SCF向BSF发送授权请求消息49，并且包括在服务描述中对 这个服务指示的NAF-Id。BSF在50使用NAF-Id来得出NAF密钥，并 且然后在授权响应消息51中返回NAF密钥。然后，SCF从NAF密钥得 出MUK，如TS 33.246定义的。应当注意，新Ua安全协议在3GPP TS  33.220中为此需要登记。

然后，在HTTP登记过程52中，SCF 21向BM-SC(在所示情况下， 向BM-SC_1 22a)发送HTTP POST消息53。SCF按如下所述装载HTTP POST 消息：

-HTTP版本将为1.1，这在RFC 2616中规定；

-请求URI的基部将包含完整BM-SC密钥管理URI(例如 http://bmsc.home1.net：1234)；

-请求URI将包含设置成“authorized-register”的URI参数 “requesttype”，即，请求URI采取 “/keymanagement？requesttype＝authorized-register”的形式；

-SCF可对请求URI添加附加URI参数；

-X-3GPP-Asserted-Identity报头，它包括UE的识别码；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-authorized-register+xml”；

-HTTP有效载荷将包含XML文档，其中包括UE希望登记的MBMS 用户服务的一个或多个userServiceIds、UE的IP地址、MBMS用户密 钥(MUK)以及MUK、NAF-Id、和B-TID的存在期的列表。包含NAF-Id 和B-TID，因为它们还包含在从BM-SC到UE的MIKEY消息中以标识使 用哪一个MUK(即，NAF密钥)。有效载荷的XML方案在3GPP TS 26.237 的附录I中规定。

-SCF可对HTTP POST请求消息添加附加HTTP报头。

BM-SC_1 22a接收HTTP POST消息53，检验HTTP POST消息是有 效的，并且提取请求供进一步处理。由于HTTP POST消息来自具有被 断言识别码的SCF 21，所以BM-SC_1不需要认证UE 11，因为UE已经 由IMS认证。另外，HTTP POST消息还向BM-SC_1指示SCF已经授权 UE向指示的MBMS用户服务进行登记。

BM-SC_1存储接收的信息，并且向SCF 21返回HTTP 200 OK消息 54。BM-SC_1将按如下所述来装载HTTP 200 OK消息：

-HTTP状态行中的HTTP状态码将为200；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-register-response+xml”；

-HTTP有效载荷将包含XML文档，XML文档包括其中包含各MBMS 用户服务的一个状态码的列表。有效载荷的XML方案与用于TS 33.246 中的MBMS登记的相同，并且在TS 26.346中规定。

SCF 21接收HTTP 200 OK消息54，把来自HTTP 200 OK消息的 XML主体包含到SIP 200 OK消息55中，并且经由IM CN子系统32向 UE 11发送SIP 200 OK消息。在MIKEY MSK过程56中，BM-SC_1 22a 这时能够按照TS 33.246中规定的过程开始向指示的MBMS用户服务的 UE发送MIKEY MSK消息(采用MUK来保护)57、MTK消息(采用MSK来保 护)58和MBMS数据(采用MTK来保护)59。在MIKEY MSK消息57中， BM-SC将使用在HTTP POST消息53中从SCF 21接收的NAF-Id(FQDN) 和B-TID。

图6A-6B是示出在SIP 200 OK消息中向UE 11指示NAF-Id(SCF 分配的FQDN)时(即，上述备选方案B)在发明的基于IMS的MBMS登记 过程的一实施例期间在多种网络实体之间发送的消息的消息流程图的 部分。如以上对于图5A-5B所述的相同前提适用。

参照图6A，在GBA引导过程42之后，执行服务检索过程43。UE 11 与SSF 41进行通信，并且检索服务描述62，即，可用服务及其参数(例 如，服务保护描述)的列表。服务保护描述与TS 33.246中定义的相似， 除了包含的FQDN指向SCF 21而不是BM-SC FQDN之外。假定在这里还 需要SCF 21的FQDN，使得UE知道将SIP INVITE消息47发送到什么 位置。然后，用户从服务描述来选择服务。

在SIP INVITE过程63中，UE 11经由IM CN子系统32向SCF 21 发送SIP INVITE消息64。INVITE消息在请求URI中指示SCF，并且 该消息在XML文档的SIP消息主体中包含UE希望登记的被请求MBMS 用户服务的识别码(userServiceIds)。XML文档与用于TS 33.246中 的MBMS登记的相同，并且在TS 26.346中规定。另外，存在携带引导 事务标识符(B-TID)的XML文档。携带B-TID的XML文档在3GPP TS  26.237的附录I中定义。

SCF 21从SIP INVITE消息64的报头接收UE 11的IP地址和UE 的被断言识别码(一个或多个)。SCF基于存储的预订信息来执行检查， 以便确定是否授权UE访问被请求MBMS用户服务。如果是的话，则该 过程继续进行。如果不是的话，则该过程终止。

参照图6B，如果不存在对该UE存储的B-TID，或者如果接收的 B-TID与对该UE存储的不同，则SCF通过Zn参考点来运行与BSF 12 的GBA使用过程65，以便取回与UE对应的NAF密钥，如TS 33.220 定义的。SCF向BSF发送授权请求消息66，并且包括SCF为这个服务 已经分配的NAF-Id。BSF在67使用NAF-Id来得出NAF密钥，并且然 后在授权响应消息68中返回NAF密钥。然后，SCF从NAF密钥得出MUK， 如TS 33.246定义的。应当注意，新Ua安全协议在3GPP TS 33.220 中为此需要登记。

然后，在HTTP登记过程69中，SCF 21向BM-SC(在所示情况下， 向BM-SC_1 22a)发送HTTP POST消息70。SCF按如下所述装载HTTP POST 消息：

-HTTP版本将为1.1，这在RFC 2616中规定；

-请求URI的基部将包含完整BM-SC密钥管理URI(例如 http://bmsc.home1.net：1234)；

-请求URI将包含设置成“authorized-register”的URI参数 “requesttype”，即，请求URI采取 “/keymanagement？requesttype＝authorized-register”的形式；

-SCF可对请求URI添加附加URI参数；

-X-3GPP-Asserted-Identity报头，它包括UE的识别码；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-authorized-register+xml”；

-HTTP有效载荷将包含XML文档，其中包括UE希望登记的MBMS 用户服务的一个或多个userServiceIds、UE的IP地址、MBMS用户密 钥(MUK)以及MUK、NAF-Id和B-TID的存在期的列表。包含NAF-Id和 B-TID，因为它们还包含在从BM-SC到UE的MIKEY消息中以标识使用 哪一个MUK(即，NAF密钥)。有效载荷的XML方案在3GPP TS 26.237 的附录I中规定。

-SCF可对HTTP POST请求消息添加附加HTTP报头。

BM-SC_1 22a接收HTTP POST消息70，检验HTTP POST消息是有 效的，并且提取请求供进一步处理。由于HTTP POST消息来自具有被 断言识别码的SCF 21，所以BM-SC_1不需要认证UE 11，因为UE已经 由IMS认证。另外，HTTP POST消息还向BM-SC_1指示SCF已经授权 UE向指示的MBMS用户服务进行登记。

BM-SC_1存储接收的信息，并且向SCF 21返回HTTP 200 OK消息 71。BM-SC_1将按如下所述来装载HTTP 200 OK消息：

-HTTP状态行中的HTTP状态码将为200；

-HTTP报头Content-Type将是有效载荷的MIME类型，即， “application/mbms-register-response+xml”；

-HTTP有效载荷将包含XML文档，XML文档包括其中包含各MBMS 用户服务的一个状态码的列表。有效载荷的XML方案与用于TS 33.246 中的MBMS登记的相同，并且在TS 26.346中规定。

SCF 21接收HTTP 200 OK消息71，把来自HTTP 200 OK消息的 XML主体以及使用的NAF-Id包含到SIP 200 OK消息72中，并且经由 IM CN子系统32向UE 11发送SIP 200 OK消息。当UE接收SIP 200 OK 消息时，UE在73使用接收的NAF-Id来得出与服务对应的NAF密钥， 并且得出MUK，如TS 33.246中定义。

在MIKEY MSK过程74中，BM-SC_1 22a这时能够按照TS 33.246 中规定的过程开始向指示的MBMS用户服务的UE发送MIKEY MSK消息 (采用MUK来保护)75、MTK消息(采用MSK来保护)76和MBMS数据(采 用MTK来保护)77。在MIKEY MSK消息75中，BM-SC将使用在HTTP POST 消息70中从SCF 21接收的NAF-Id(FQDN)和B-TID。

图7是示出用于基于IMS的MBMS和PSS用户服务中的密钥分发的 发明系统和方法的第一实施例的高级参考模型。在步骤1，UE 11和 BSF 12运行GBA引导过程，如TS 33.220中定义。结果是密钥Ks和 B-TID。在步骤2，UE得出NAF特定密钥材料(Ks_NAF)，如TS 33.220 中定义。在步骤3，UE通过向SCF 21(它充当NAF)发送SIP INVITE消 息(包含B-TID)，来发起会话初始协议(SIP)会话。在步骤4，SCF使 用B-TID从BSF请求Ks_NAF。在步骤5，BSF得出NAF特定密钥材料 (Ks_NAF)，如TS 33.220中定义。在步骤6，BSF向SCF发送Ks_NAF。

在新步骤6b，SCF 21确定哪一个BS-SC应当接收该请求。这个信 息可从UE的请求获得，或者SCF可基于其本地策略来进行本地判定。 SCF使用密钥推导函数(例如，Ks_AS＝KDF(Ks_NAF，nonce))从Ks_NAF 和nonce来得出BM-SC特定密钥Ks_AS。nonce可以是例如BM-SC的识 别码，例如完全合格域名(FQDN)、由SCF选择的(伪)随机值或者作为 nonce可使用的另外某个值。

在步骤7，SCF 21在HTTP请求中向识别的BM-SC 22a发送Ks-AS 以及BM-SC的识别码(例如，FQDN)。CR S4-090148中规定的其它信息 也可在请求中发送(但Ks_NAF由Ks_AS取代)。应当注意，将BM-SC 22a 的B-TID和FQDN发送到BM-SC，使得BM-SC能够将其包含在送往UE 11 的MIKEY消息的ID有效载荷中。UE将使用它们来识别正确MUK、即 Ks_AS。将FQDN从SCF发送到BM-SC使得有可能令BM-SC通过不同FQDN 对UE和SCF是已知的。因此，需要确保BM-SC向UE发送BM-SC从SCF 接收到的相同FQDN。

在步骤8，BM-SC 22a存储信息，并且以SIP 200 OK消息向SCF 21 确认HTTP请求。在步骤9，SCF向UE 11发送SIP 200 OK消息。200 OK 消息包括nonce和BM-SC的识别码。如果FQDN用作nonce，则这两者 可以是相同值。在步骤9b，UE使用密钥推导函数(例如， Ks_AS＝KDF(Ks_NAF，nonce))从Ks_NAF和nonce来得出BM-SC特定密 钥Ks_AS。UE存储密钥Ks_AS连同BM-SC识别码。最后，在步骤10， BM-SC 22a向UE发送采用作为MUK的Ks_AS保护的MIKEY密钥管理消 息(参见TS 33.246)。BM-SC把从SCF 21接收的BM_SC FQDN和B-TID 包含在MIKEY消息的ID有效载荷中。UE 11则能够使用Ks_AS对消息 进行解密和检验。UE使用MIKEY消息的ID有效载荷来识别正确 MUK(即，Ks_AS)。

图8是示出用于获得认证代理(AP)情况的AS特定密钥的发明系统 和方法的第二实施例的高级参考模型。这个实施例预计针对若干AS  16a和16b可驻留在AP 15之后的一般AP-AS情况。TLS隧道可在UE 11 与AP 15之间建立，但是该隧道与本发明不相关。

在步骤1，UE 11和BSF 12运行GBA引导过程，如TS 33.220中 定义。结果是密钥Ks和B-TID。在步骤2，UE得出NAF特定密钥材料 (Ks_NAF)，如TS 33.220中定义。在步骤3，UE向AP(它充当NAF)发 送HTTP请求(包含B-TID)。在步骤4，AP使用B-TID向BSF请求Ks_NAF。 在步骤5，BSF得出NAF特定密钥材料(Ks_NAF)，如TS 33.220中定义。 在步骤6，BSF向AP发送Ks_NAF。

在新步骤6b，AP 15确定哪一个AS应当接收该请求。这个信息可 从UE的请求获得，或者AP可基于其本地策略来进行本地判定。AP使 用密钥推导函数(例如，Ks_AS＝KDF(Ks_NAF，nonce))从Ks_NAF和nonce 来得出AP特定密钥Ks_AS。nonce可以是例如AS的识别码，例如是 FQDN、由AP选择的(伪)随机值或者作为nonce可使用的另外某个值。

在步骤7，AP 15在HTTP请求中向识别的AS 16a发送Ks_AS以及 AS的识别码(例如FQDN)。应当注意，AP需要向AS发送AS的FQDN， 因为AS可通过不同FQDN而对UE 11和AP 15是已知的。UE可使用FQDN 来识别正确Ks_As。因此，需要确保将同一FQDN从AP发送到AS以及 从AS发送到UE。

在步骤8，AS 16a存储信息，并且以SIP 200 OK消息向AP 15确 认HTTP请求。在步骤9，AP向UE 11发送SIP 200 OK消息。200 OK 消息包括nonce和BM-SC的识别码。如果FQDN用作nonce，则这两者 可以是相同值。在步骤9b，UE使用密钥推导函数(例如， Ks_AS＝KDF(Ks_NAF，nonce))从Ks_NAF和nonce来得出AS特定密钥 Ks_AS。然后，UE存储密钥Ks_As连同AS识别码。最后，在步骤10， AS 16a向UE发送采用Ks_AS保护的消息。UE 11则能够使用Ks_AS对 消息进行解密和检验。UE使用AS识别码来识别正确Ks_AS。

图9是本发明系统的一示范实施例的简化框图。该系统包括UE 11、 SCF 21、BSF 12和BM-SC_1 22a。这些单元的每个的操作例如可由运 行存储器上存储的计算机程序指令的处理器来控制。在图9所示的示 范实施例中，UE包括处理器81和存储器82；SCF包括处理器83和存 储器84；BSF包括处理器85和存储器86；以及BM-SC_1包括处理器 87和存储器88。

UE 11还示为包括Ks_NAF推导单元91。在图6所示的实施例中， UE接收来自SSF 41的服务描述中的NAF-Id(SCF分配的FQDN)，并且 在开始SIP INVITE过程46之前得出Ks_NAF。在图7所示的实施例中， UE接收SIP 200 OK消息72中的NAF-Id，并且然后得出Ks_NAF。

UE 11经由IM CN 32向SCF 21发送SIP INVITE消息。该消息在 SIP INVITE通信单元92中接收。SIP INVITE通信单元把来自INVITE 消息的userServiceId和B-TID转发给服务-NAF-Id映射单元93，它 将userServiceId映射到NAF-Id_1。将NAF-Id_1和B-TID转发给GBA 使用通信单元94，GBA使用通信单元94将这些参数转发给BSF 12。 BSF中的GBA使用通信单元95接收参数，并且将其转发给Ks_NAF推 导单元96，Ks_NAF推导单元96得出Ks_NAF。然后，将Ks_NAF返回 给SCF，其中将它转发给HTTP登记通信单元97。

HTTP登记通信单元97向BM-SC_1 22a发送HTTP POST消息，其 中它在HTTP登记通信单元98中被接收。HTTP POST消息包括 userServiceId、NAF-Id_1、UE IP地址、B-TID、MUK(＝Ks_NAF)和MUK 存在期。BM-SC_1从服务状态单元99获得各MBMS用户服务的状态， 并且在HTTP 200 OK消息中将包括各MBMS用户服务码的一个状态码的 列表连同userServiceId一起发送到SCF 21。SCF将这个信息转发给 UE 11。HTTP登记通信单元98还将信息发送到MIKEY MSK单元101。 信息包括MSK-Id_1、NAF-Id_1、B-TID和MUK(＝Ks_NAF)。

使用这个信息，使MIKEY MSK单元101能够向UE 11发送MIKEY MSK 消息(采用MUK来保护)、MTK消息(采用MSK来保护)和MBMS数据(采 用MTK来保护)，UE采用Ks_NAF推导单元91得出了MUK(＝Ks_NAF)。

因此，本发明解决了当一个以上BM-SC 22连接到SCF 21时提供 BM-SC特定NAF密钥的问题。另外，本发明解决了在MIKEY消息中不 存在足够信息向UE指示哪一个MUK(即，NAF密钥)用于保护MIKEY MSK 消息的问题。SCF 21向BM-SC 22发送B-TID和选择的NAF-Id，BM-SC  22在MIKEY消息内部进一步使用它们向UE指示哪一个NAF秘钥被使 用。

在图6和图7所示的实施例中，本发明具有不要求NAF密钥的进 一步推导的附加优点。NAF密钥的进一步推导要求对GSM和UMTS网络 的移动终端中使用的通用集成电路卡(UICC)智能卡的变更。如果基于 UICC的密钥管理正在使用中，则在UICC中处理NAF密钥。这在一些 情况下可能成问题，因为一般来说，UICC影响在标准化中不是合乎需 要的。本发明的这些实施例避免了这个潜在问题。

本发明当然可通过除了本文所述之外的其它特定方式来执行，而 没有背离本发明的本质特性。因此，当前实施例在所有方面被认为是 说明性而不是限制性的，并且落入所附权利要求的含意和等效范围之 内的所有变更预计包含在其中。