基于ims的多媒体广播和多播服务(mbms)中的安全密钥管理的制作方法
【专利说明】基于IMS的多媒体广播和多播服务(MBMS)中的安全密钥管理
[0001]相关申请
[0002]本申请要求2009年4月I日提交的美国临时申请N0.61/165809的权益。
技术领域
[0003]一般来说，本发明涉及通信网络，并且具体来说，涉及用于管理基于IP多媒体子系统(IMS)的多媒体广播/多播服务(MBMS)用户服务中的共享安全密钥的系统、方法和网络节点。
【背景技术】
[0004]在若干第三代合作伙伴项目(3GPP)技术规范中描述与本发明相关的现有规程。它们包括:
[0005]-3GPP TS 33.220 v8.5.0 Technical Specificat1n Group Servicesand System Aspects (技术规范组服务和系统方面)；Generic Authenticat1nArchitecture (GAA) ；Generic bootstrapping architecture (—般鉴权架构(GAA);—般引导架构(GBA))(发布版8);
[0006]-3GPP TS 33.222 v8.0.0 Technical Specificat1n Group Servicesand System Aspects (技术规范组服务和系统方面)；Generic Authenticat1nArchitecture (GAA) ；Access to network applicat1n funct1ns using HypertextTransfer Protocol over Transport Layer Security (HTTPS)(—般鉴权架构(GAA);使用超文本传输协议在传输层安全性(HTTPS)上接入网络应用功能)(发布版8)；
[0007]-3GPP TS 33.246 v8.2.0 Technical Specificat1n Group Services andSystem Aspects (技术规范组服务和系统方面);3G Security ；Security of MultimediaBroadcast/Multicast Service (MBMS) (3G安全性；多媒体广播/多播业务(MBMS)的安全性)(发布版8);以及
[0008]-3GPP TS 26.237 ν8.0.0 Technical Specificat1n Group Services andSystem Aspects (技术规范组服务和系统方面);IP Multimedia Subsystem (IMS) basedPaeket Switched Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS)User Service Protocols (基于IP多媒体子系统(MS)的分组交换流动(PSS)和多媒体广播/多播业务(MBMS)用户服务；协议)(发布版8)。
[0009]图1是来自TS 33.222的高级参考模型，示出使用引导服务的网络应用功能(NAF) ο网络实体在3GPP TS 33.220中定义，3GPP TS 33.220规定通用引导架构(GBA)，其中移动通信装置(例如，用户设备(UE)Il)和引导服务器功能性(BSF) 12通过Ub参考点来运行HTTP digest AKA，并且因此建立共享密钥Ks。共享密钥Ks稍后用于得出NAF特定密钥(称作Ks—NAF密钥)，以便保密UE与NAF 13之间通过Ua参考点的通信。NAF通过Zn参考点来取回NAF特定密钥。
[0010]3GPP TS 33.222条款6规定NAF 13中的认证代理(AP)的使用。AP与TS 33.220中规定的GBA架构兼容。当AP用于这种架构时，AP通过充当NAF来减轻(relieve)应用服务器(AS)的安全任务。
[0011]图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使用。
[0012]TS 33.222中为NAF密钥的使用定义的规程的问题在于，UE 11和AS 16a_16n没有共享任何密钥资料，即使可能存在会需要这种共享密钥资料的情况。AP 15充当TS33.222中的NAF 13。因此，NAF密钥(Ks_NAF)按照TS 33.220中规定的密钥推导规则是AP特定的，并且是UE不知道的。
[0013]图3是来自TS 26.237的高级参考模型，示出用于密钥共享的当前解决方案。NAF密钥与AS配合使用的上面定义的这个问题也可适用于TS 26.237中定义的网络实体。在这种情况下，服务控制功能(SCF) 21充当NAF/AP的修改变体(并且因而标记为SCF/NAF)，并且MBMS广播/多播服务中心?1^0 22充当45(并且因而标记为81-5(:/^5)。与图2的AS相似，BM-SC/AS需要与UE 11的共享密钥，以便能够通过单播或广播信道将受保护MIKEY密钥管理消息从BM-SC/AS直接发送到UE。
[0014]应当注意，TS 26.237没有提到与TS 33.222的AP 15和AS 16的这种类比。TS26.237中的设定与TS 33.222中不是精确相同的；例如，不一定使用UE 11与SCF 21之间的TLS隧道。但是，类似问题仍然保持不变。
[0015]在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以及订户的被断言识别码。
[0016]只要仅一个BM-SC 22连接到SCF 21 (并且只要SCF能够假定对BM-SC的足够置信，使得BM-SC不会误用SCF特定NAF密钥)，则TS26.237中的当前解决方案正常工作。当两个或更多BM-SC附连到SCF时，则出现问题。这是因为，按照当前解决方案，SCF将它自己的Ks_NAF发送到BM-SC，并且因此SCF会将同一 Ks_NAF发送到所有连接的BM-SC。将同一密钥给予若干节点不是良好的安全实践。这会引起同一 Ks_NAF密钥在UE 11与所有相关联的BM-SC之间使用的情况。这会揭开诸如BM-SC对UE相互模仿的威胁。
[0017]图4是示出在现有基于MS的MBMS登记过程期间在多种网络实体之间发送的消息的消息流程图。该图基于如下前提:按照3GPP TS33.203向MS登记和认证了 UE 11 ；UE与服务调度功能(SSF)(未示出)进行了通信并且接收到如3GPP TS 26.237定义的可用服务的列表；UE如3GPP TS 33.220所定义运行了与BSF 12的GBA引导；以及网络接口采用3GPP TS 33.210中定义的网络域安全性(NDS/IP)来保护。
[0018]该过程如下，其中仅示出关于安全性过程的相关信息。UE 11经由IP多媒体核心网络(IM CN)子系统32向SCF 21发送SIP INVITE消息31。INVITE消息在请求URI中指示“SCF”，并且该消息在XML文档的SIP消息主体中包含UE希望登记的被请求MBMS用户服务的识别码(userServicelds)。XML文档与用于TS 33.246中的MBMS登记的相同，并且在TS 26.346中规定。另外，存在携带引导事务标识符(B-TID)的XML文档。携带B-TID的XML文档在3GPP TS 26.237的附录I中定义。
[0019]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密钥，如TS33.220所定义。SCF从NAF密钥得出MBMS用户密钥(MUK)，如TS 33.246所定义。
[0020]SCF 21 向 BM-SC 22 发送 HTTP POST 消息 35。SCF 按如下所述装载 HTTP POST 消息:
[0021]-HTTP版本将为1.1，这在RFC 2616中规定；
[0022]-请求URI的基部(base)将包含完整BM-SC密钥管理URI(例如http://bmsc.home1.net: 1234)；
[0023]-请求URI 将包含设置成“authorized-register”的 URI 参数“requesttype”，即，请求 URI 米取‘‘/keymanagement ? requesttype = authorized-register^ 的形式；
[0024]-SCF可对请求URI添加附加URI参数；
[0025]-X-3GPP-Asserted_Identity 报头，它包括 UE 的识别码；
[0026]-HTTP 报头 Content-Type 将是有效载荷的 MIME 类型，即，“applicat1n/mbms-authorized-register+xml，，；
[0027]-HTTP有效载荷将包含XML文档，其中包括UE希望登记的MBMS用户服务的一个或多个userServicelds、UE的IP地址、MBMS用户密钥(MUK)、和MUK的存在期的列表。有效载荷的XML方案在3GPP TS26.237的附录I中规定
[0028]-SCF可对HTTP POST请求添加附加HTTP报头。
[0029]BM-SC 22接收HTTP POST消息35，检验HTTP POST是有效的，并且提取请求供进一步处理。由于HTTP POST消息来自具有被断言识别码的SCF 2