基于ims的多媒體廣播和多播服務(mbms)中的安全密鑰管理的制作方法
【專利說明】基于IMS的多媒體廣播和多播服務(MBMS)中的安全密鑰管理
[0001]相關申請
[0002]本申請要求2009年4月I日提交的美國臨時申請N0.61/165809的權益。
技術領域
[0003]一般來說，本發(fā)明涉及通信網(wǎng)絡，并且具體來說，涉及用于管理基于IP多媒體子系統(tǒng)(IMS)的多媒體廣播/多播服務(MBMS)用戶服務中的共享安全密鑰的系統(tǒng)、方法和網(wǎng)絡節(jié)點。
【背景技術】
[0004]在若干第三代合作伙伴項目(3GPP)技術規(guī)范中描述與本發(fā)明相關的現(xiàn)有規(guī)程。它們包括:
[0005]-3GPP TS 33.220 v8.5.0 Technical Specificat1n Group Servicesand System Aspects (技術規(guī)范組服務和系統(tǒng)方面)；Generic Authenticat1nArchitecture (GAA) ；Generic bootstrapping architecture (—般鑒權架構(GAA);—般引導架構(GBA))(發(fā)布版8);
[0006]-3GPP TS 33.222 v8.0.0 Technical Specificat1n Group Servicesand System Aspects (技術規(guī)范組服務和系統(tǒng)方面)；Generic Authenticat1nArchitecture (GAA) ；Access to network applicat1n funct1ns using HypertextTransfer Protocol over Transport Layer Security (HTTPS)(—般鑒權架構(GAA);使用超文本傳輸協(xié)議在傳輸層安全性(HTTPS)上接入網(wǎng)絡應用功能)(發(fā)布版8)；
[0007]-3GPP TS 33.246 v8.2.0 Technical Specificat1n Group Services andSystem Aspects (技術規(guī)范組服務和系統(tǒng)方面);3G Security ；Security of MultimediaBroadcast/Multicast Service (MBMS) (3G安全性；多媒體廣播/多播業(yè)務(MBMS)的安全性)(發(fā)布版8);以及
[0008]-3GPP TS 26.237 ν8.0.0 Technical Specificat1n Group Services andSystem Aspects (技術規(guī)范組服務和系統(tǒng)方面);IP Multimedia Subsystem (IMS) basedPaeket Switched Streaming (PSS) and Multimedia Broadcast/Multicast Service (MBMS)User Service Protocols (基于IP多媒體子系統(tǒng)(MS)的分組交換流動(PSS)和多媒體廣播/多播業(yè)務(MBMS)用戶服務；協(xié)議)(發(fā)布版8)。
[0009]圖1是來自TS 33.222的高級參考模型，示出使用引導服務的網(wǎng)絡應用功能(NAF) ο網(wǎng)絡實體在3GPP TS 33.220中定義，3GPP TS 33.220規(guī)定通用引導架構(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規(guī)定NAF 13中的認證代理(AP)的使用。AP與TS 33.220中規(guī)定的GBA架構兼容。當AP用于這種架構時，AP通過充當NAF來減輕(relieve)應用服務器(AS)的安全任務。
[0011]圖2是來自TS 33.222的高級參考模型，示出認證代理(AP) 15的環(huán)境和參考點。TS 33.222假定UE 11與NAF 13中的AP 15之間的使用傳輸層安全性(TLS)。當HTTPS請求預計送往AP之后的應用服務器(AS)16a-16n時，AP端接TLS隧道17，從BSF 12取回NAF密鑰(Ks_NAF)，并且執(zhí)行UE認證。AP作為代理將從UE接收的HTTP請求送往一個或多個AS。當AP將請求從UE轉發(fā)給AS時，AP可添加訂戶識別碼的斷言，供AS使用。
[0012]TS 33.222中為NAF密鑰的使用定義的規(guī)程的問題在于，UE 11和AS 16a_16n沒有共享任何密鑰資料，即使可能存在會需要這種共享密鑰資料的情況。AP 15充當TS33.222中的NAF 13。因此，NAF密鑰(Ks_NAF)按照TS 33.220中規(guī)定的密鑰推導規(guī)則是AP特定的，并且是UE不知道的。
[0013]圖3是來自TS 26.237的高級參考模型，示出用于密鑰共享的當前解決方案。NAF密鑰與AS配合使用的上面定義的這個問題也可適用于TS 26.237中定義的網(wǎng)絡實體。在這種情況下，服務控制功能(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直接發(fā)送到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)發(fā)送到BM-SC 22。BM-SC使用Ks_NAF作為MUK (MBMS用戶密鑰)，這用于保護從BM-SC到UE 11的MIKEY密鑰管理消息。圖3的步驟1_6按照當前GBA規(guī)范，而步驟7描述向BM-SC發(fā)送Ks_NAF以及訂戶的被斷言識別碼。
[0016]只要僅一個BM-SC 22連接到SCF 21 (并且只要SCF能夠假定對BM-SC的足夠置信，使得BM-SC不會誤用SCF特定NAF密鑰)，則TS26.237中的當前解決方案正常工作。當兩個或更多BM-SC附連到SCF時，則出現(xiàn)問題。這是因為，按照當前解決方案，SCF將它自己的Ks_NAF發(fā)送到BM-SC，并且因此SCF會將同一 Ks_NAF發(fā)送到所有連接的BM-SC。將同一密鑰給予若干節(jié)點不是良好的安全實踐。這會引起同一 Ks_NAF密鑰在UE 11與所有相關聯(lián)的BM-SC之間使用的情況。這會揭開諸如BM-SC對UE相互模仿的威脅。
[0017]圖4是示出在現(xiàn)有基于MS的MBMS登記過程期間在多種網(wǎng)絡實體之間發(fā)送的消息的消息流程圖。該圖基于如下前提:按照3GPP TS33.203向MS登記和認證了 UE 11 ；UE與服務調度功能(SSF)(未示出)進行了通信并且接收到如3GPP TS 26.237定義的可用服務的列表；UE如3GPP TS 33.220所定義運行了與BSF 12的GBA引導；以及網(wǎng)絡接口采用3GPP TS 33.210中定義的網(wǎng)絡域安全性(NDS/IP)來保護。
[0018]該過程如下，其中僅示出關于安全性過程的相關信息。UE 11經(jīng)由IP多媒體核心網(wǎng)絡(IM CN)子系統(tǒng)32向SCF 21發(fā)送SIP INVITE消息31。INVITE消息在請求URI中指示“SCF”，并且該消息在XML文檔的SIP消息主體中包含UE希望登記的被請求MBMS用戶服務的識別碼(userServicelds)。XML文檔與用于TS 33.246中的MBMS登記的相同，并且在TS 26.346中規(guī)定。另外，存在攜帶引導事務標識符(B-TID)的XML文檔。攜帶B-TID的XML文檔在3GPP TS 26.237的附錄I中定義。
[0019]SCF 21從SIP INVITE消息31的報頭接收UE 11的IP地址和UE的一個或多個被斷言識別碼。SCF基于存儲的預訂信息來執(zhí)行檢查，以便確定是否授權UE訪問被請求MBMS用戶服務。如果UE經(jīng)過授權，則該過程繼續(xù)進行；如果未經(jīng)授權，則該過程終止。如果不存在對該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 發(fā)送 HTTP POST 消息 35。SCF 按如下所述裝載 HTTP POST 消息:
[0021]-HTTP版本將為1.1，這在RFC 2616中規(guī)定；
[0022]-請求URI的基部(base)將包含完整BM-SC密鑰管理URI(例如http://bmsc.home1.net: 1234)；
[0023]-請求URI 將包含設置成“authorized-register”的 URI 參數(shù)“requesttype”，即，請求 URI 米取‘‘/keymanagement ? requesttype = authorized-register^ 的形式；
[0024]-SCF可對請求URI添加附加URI參數(shù)；
[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中規(guī)定
[0028]-SCF可對HTTP POST請求添加附加HTTP報頭。
[0029]BM-SC 22接收HTTP POST消息35，檢驗HTTP POST是有效的，并且提取請求供進一步處理。由于HTTP POST消息來自具有被斷言識別碼的SCF 2