專(zhuān)利名稱(chēng)：基于密鑰管理服務(wù)器的ims媒體安全的合法監(jiān)聽(tīng)系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信安全技術(shù)，尤其涉及一種基于密鑰管理服務(wù)器(KMS，Key Management Servicer)的IP多媒體子系統(tǒng)(IMS)媒體安全的合法監(jiān)聽(tīng)系統(tǒng)。
背景技術(shù)：
基于KMS的安全通信技術(shù)方案是一種保護(hù)媒體流端到端的技術(shù)方案，其是針對(duì)與信令和傳輸網(wǎng)絡(luò)無(wú)關(guān)的具有更高要求的安全需求而提出的。該基于KMS的安全通信技術(shù)方案是基于使用KMS和一個(gè)票據(jù)(Ticket) ”的概念來(lái)實(shí)現(xiàn)的，其中，KMS用于負(fù)責(zé)提供安全、用戶(hù)鑒權(quán)以及密鑰生成等功能。KMS在IMS媒體面安全中，作為第三方服務(wù)器，主要起到發(fā)放Ticket，解析Ticket的作用，KMS也可以稱(chēng)為密鑰
管理系統(tǒng)。所述基于KMS的安全通信技術(shù)方案主要是針對(duì)具有較高安全需求的用戶(hù)，該基于 KMS的安全通信技術(shù)方案可以完全不依賴(lài)于信令面的安全，也就是說(shuō)，即便信令面的數(shù)據(jù)被竊取，攻擊者也無(wú)法獲取通話(huà)雙方的媒體密鑰，從而為用戶(hù)提供較高的安全保障。然而，該基于KMS的安全通信技術(shù)方案需要增加新的網(wǎng)元，即增加一個(gè)KMS。考慮到用戶(hù)設(shè)備(UE)和IMS中各個(gè)網(wǎng)元的參與，基于KMS的安全通信技術(shù)方案可參見(jiàn)圖1所示的系統(tǒng)架構(gòu)。其中，代理-呼叫會(huì)話(huà)控制功能(P-CSCF)和服務(wù)-呼叫會(huì)話(huà)控制功能(S-CSCF)都屬于IMS網(wǎng)元。該基于KMS的安全通信技術(shù)方案的實(shí)現(xiàn)流程，包括如下步驟步驟1、用戶(hù)A (即UE A)與KMS用通用認(rèn)證機(jī)制(GBA)機(jī)制建立安全通道。這里，GBA是3GPP定義的一種基于移動(dòng)通信網(wǎng)絡(luò)、輕量級(jí)的安全基礎(chǔ)設(shè)施，可以為應(yīng)用層業(yè)務(wù)提供統(tǒng)一的安全認(rèn)證服務(wù)。KMS作為一個(gè)可信任的第三方，能實(shí)現(xiàn)密鑰的管理和分發(fā)功能，KMS所在的位置還可以采用網(wǎng)絡(luò)應(yīng)用功能(NAF)。步驟2、用戶(hù)A向KMS申請(qǐng)一個(gè)用于與用戶(hù)B(即UE B)通訊的媒體密鑰和一張加密的Ticket (包括媒體密鑰和用戶(hù)B的信息)。步驟3、KMS生成媒體密鑰和加密的Ticket發(fā)送給用戶(hù)A。步驟4、用戶(hù)A通過(guò)IMS核心網(wǎng)發(fā)送通訊請(qǐng)求和加密的Ticket給用戶(hù)B。步驟5、用戶(hù)B接收到用戶(hù)A發(fā)送的通訊請(qǐng)求和加密的Ticket。步驟6、用戶(hù)B與KMS用GBA機(jī)制建立安全通道。步驟7、用戶(hù)B發(fā)送接收到的加密的Ticket給KMS，請(qǐng)求得到Ticket中的媒體密鑰。步驟8、KMS解密用戶(hù)B發(fā)來(lái)的Ticket，驗(yàn)證用戶(hù)B和Ticket中的被叫用戶(hù)信息是否一致，如果一致，發(fā)送Ticket中的媒體密鑰給用戶(hù)B。步驟9、用戶(hù)B獲得媒體密鑰后，接受用戶(hù)A的通訊請(qǐng)求，這樣用戶(hù)A，用戶(hù)B就可用這個(gè)媒體密鑰進(jìn)行通訊了。以上所述的安全通信技術(shù)的解決方案是采用MIKEY-Ticket密鑰協(xié)商機(jī)制來(lái)實(shí)現(xiàn)。MIKEY-Ticket密鑰協(xié)商機(jī)制是用來(lái)擴(kuò)充MIKEY (RFC3830)協(xié)議的一種新的模式， 這個(gè)新的模式使用了 KMS和Ticket的概念。MIKEY-Ticket對(duì)MIKEY協(xié)議的擴(kuò)展的需求來(lái)源于愛(ài)立信公司的基于Ticket的系統(tǒng)(TBS)方案，該方案中使用了 Ticket這一概念，而實(shí)際中，該Ticket實(shí)體沒(méi)有一個(gè)具體的協(xié)議來(lái)承載，使之能在信令中傳輸。在RFC4568的會(huì)話(huà)描述協(xié)議(SDP)的密鑰協(xié)商協(xié)議擴(kuò)展中，SDP已經(jīng)能支持傳輸MIKEY，讓MIKEY支持Ticket， 則問(wèn)題迎刃而解。MIKEY-Ticket機(jī)制中包含三次交互，如圖2所示，分別為票據(jù)請(qǐng)求 (TicketRequets)；票據(jù)傳輸(Ticket Transfer)和票據(jù)解決(Ticket Resolve)。在圖2中，用戶(hù)I表示發(fā)起會(huì)話(huà)用戶(hù)，用戶(hù)R表示應(yīng)答會(huì)話(huà)用戶(hù)，KMS表示密鑰管理服務(wù)器。下面針對(duì)上述三種交互過(guò)程分別進(jìn)行詳細(xì)說(shuō)明，其中交互參數(shù)中可分為三類(lèi)表示方式，即[]表示該參數(shù)可選，0表示可含一個(gè)或超過(guò)一個(gè)該類(lèi)參數(shù)，H表示不含或含超過(guò)零個(gè)該類(lèi)參數(shù)。一、針對(duì)Ticket Request而言，首先會(huì)話(huà)發(fā)起方即用戶(hù)I向KMS發(fā)送一個(gè) REQUEST_INIT消息，用于向KMS請(qǐng)求一個(gè)Ticket，該REQUEST_INIT消息中包含了會(huì)話(huà)信息 (例如，被呼叫者的標(biāo)識(shí))，并且這個(gè)REQUEST_INIT消息由基于用戶(hù)I和KMS的共享密鑰的消息認(rèn)證碼(MAC)來(lái)保護(hù)。Ticket Request分為兩種模式1、共享密鑰；2、公私鑰機(jī)制。由于公私鑰機(jī)制需要HiI的支持而不被采用，這里只介紹共享密鑰模式。該REQUEST_INIT消息中所帶的參數(shù)具體見(jiàn)圖 3 所示，包括HDR，T，RAND, [IDi]，[IDkms]，(IDre), {SP}，IDtp, [KEMAC], [IDpsk]，V，其中HDR表示消息頭，T表示時(shí)間戳，RAND表示隨機(jī)數(shù)；IDi包含發(fā)送方的標(biāo)識(shí)，這個(gè)標(biāo)識(shí)一般存在Ticket中的“發(fā)送到”字段，由于發(fā)送方的標(biāo)識(shí)可以從消息的發(fā)送方字段讀取到，所以在REQUEST_INIT消息中該參數(shù)有時(shí)可以省去；IDkms應(yīng)包含在該消息中，但如果KMS只有一個(gè)惟一標(biāo)識(shí)的時(shí)候可?。籌Dre為接收方的標(biāo)識(shí)，可為單個(gè)用戶(hù)或者一組用戶(hù)。如果超過(guò)一個(gè)接受方時(shí)，每個(gè)接收方的標(biāo)識(shí)都必需放在一個(gè)單獨(dú)的ID載荷中；IDtp是所希望采用的Ticket策略的標(biāo)識(shí)；SP為安全策略載荷；KEMAC為密鑰數(shù)據(jù)傳輸載荷，簡(jiǎn)單說(shuō)就是用來(lái)存放傳輸各個(gè)密鑰的地方，這里 KEMAC = E (encr_key, [MPK] | | {TGK | TEK})，其中 MPK (MIKEYProtection Key)為 MIKEY 消息保護(hù)密鑰，即用encr_key將MPK，TGK或者TEK加密，TGK可以不止一個(gè)，encr_key即由PSK 生成，該參數(shù)可選；IDpsk不是必需參數(shù)，只有當(dāng)PSK超過(guò)一個(gè)，需要指定是使用哪個(gè)PSK時(shí)使用；V是驗(yàn)證載荷，存放相應(yīng)MAC值。如果發(fā)起方被認(rèn)證合法發(fā)起這個(gè)請(qǐng)求，那么KMS產(chǎn)生所需要的密鑰，并將這些密鑰進(jìn)行編碼放在Ticket中，在REQUEST_RESP消息中返回Ticket給發(fā)起方用戶(hù)I，該消息中的具體參數(shù)見(jiàn)下圖4所示，包括:HDR, Τ, [IDkms]，[IDtp]，[TICKET]，[KEMAC]，V，其中有[] 的參數(shù)均為可選，其中Ticket包含Ticket類(lèi)型以及Ticket數(shù)據(jù)，Ticket類(lèi)型和數(shù)據(jù)均取決于IDtp。上述T icket Request這一交互流程是可選的，當(dāng)用戶(hù)自身有能力產(chǎn)生Ticket而無(wú)需和KMS進(jìn)行交互時(shí)，Ticket Request步驟可省略。二、針對(duì)Ticket Transfer而言，收到KMS發(fā)回的REQUEST_RESP消息后，用戶(hù)I將 Ticket放在TRANSFER_INIT消息中發(fā)給被叫方用戶(hù)R，即圖2中步驟13所示。如果用戶(hù)R 檢查策略為可接受，它就把Ticket放在RES0LVE_INIT消息中轉(zhuǎn)發(fā)給KMS，讓KMS返回包含在ticket中的密鑰信息，見(jiàn)圖2中的步驟14，其中RES0LVE_INIT消息也采用基于用戶(hù)R和 KMS的共享密鑰的MAC保護(hù)?；赥icket的類(lèi)型，步驟14也是可選的，僅在用戶(hù)R離開(kāi)KMS 的協(xié)助無(wú)法或者Ticket中所包含信息時(shí)使用。TRANSFER_INIT和RES0LVE_INIT消息中具體參數(shù)分別如圖5，6所示TRANSFER_INIT消息中的IDi與IDr參數(shù)在有其他途徑可以獲取發(fā)送方和接收方的標(biāo)識(shí)時(shí)，在該消息中可不包含。在最后面的驗(yàn)證載荷中，驗(yàn)證密鑰auth_key由MPK生成。 由于發(fā)送方和接收方此時(shí)并沒(méi)有共享密鑰，接收方不能在Ticket在處理前驗(yàn)證自己從接收方收到的消息，所以接收方首先需要檢查自己接受的策略，如果所收到的消息中的IDtp 自己不能接受，則拒絕該消息，不再與KMS進(jìn)行交互。這也是提前預(yù)防對(duì)KMS的DoS攻擊的一個(gè)方法。三、針對(duì)Ticket Resolve而言，在RES0LVE_INIT消息中，Ticket載荷攜帶需要被 KMS解密的Ticket，IDtp和IDi載荷必需和TRANSFER_INIT中相應(yīng)參數(shù)一致。V是驗(yàn)證載荷，驗(yàn)證密鑰auth_key由PSK生成。KMS收到RES0LVE_INIT消息后，驗(yàn)證用戶(hù)R是否是合法接受者，如果是，則KMS取回在Ticket中的密鑰和其他信息，并給用戶(hù)R發(fā)送RES0LVE_RESP消息，如果KMS不能正確解析收到的消息或者發(fā)送RES0LVE_INIT的用戶(hù)R未通過(guò)驗(yàn)證，則KMS應(yīng)該返回相應(yīng)的錯(cuò)誤消息。KMS在RES0LVE_RESP消息中將相關(guān)密鑰和其他附加信息一起發(fā)給用戶(hù)R，參見(jiàn)圖2 中的步驟15。該RES0LVE_RESP消息中的具體參數(shù)見(jiàn)圖7 其中HDR除了消息類(lèi)型，下一個(gè)載荷以及V標(biāo)簽外，其他頭部載荷需和RES0LVE_INIT消息中的頭一致，時(shí)間戳類(lèi)型和值需和 RES0LVE_INIT 消息中一致，KEMAC = E(encr_key, MPK | [MPK] | | {TGK|TEK})。如果是 lurking情況，KMS則需要兩個(gè)分叉MI3K和多個(gè)TGK。這種情況下，第一個(gè)MI3K用來(lái)保護(hù) TRANSFER_INIT消息，而第二個(gè)MPK用來(lái)保護(hù)TRANSFER_RESP消息。用來(lái)生成不同分叉密鑰的修改因子包含在IDmod載荷中。用戶(hù)R收到該RES0LVE_RESP消息后，發(fā)送TRANSFER_RESP消息給用戶(hù)I作為確認(rèn)，見(jiàn)圖2中的步驟16，在TRANSFER_RESP消息中可能包含用于密鑰生成的一些信息，具體參數(shù)見(jiàn)圖8。實(shí)際中的信令流程需要依賴(lài)具體的Ticket類(lèi)型和KMS域的策略而定，其中， Ticket的類(lèi)型由Ticket的策略決定。以下對(duì)MIKEY-Ticket各密鑰的派生方法進(jìn)行說(shuō)明針對(duì)非Forking場(chǎng)景下MIKEY-Ticket中使用的各層密鑰以及它們之間互相生成的關(guān)系而言，IPK為保護(hù)Ticket的密鑰，一般采用僅為KMS自己所知的密鑰，Ticket中的隨機(jī)數(shù)RAND由KMS生成，基于該隨機(jī)數(shù)RAND和TPK，KMS使用密鑰生成函數(shù)KDF生成相應(yīng)的 MPK、TGK及SALT，Ke為根據(jù)I^re-shared key生成的加密ticket中密鑰材料的加密密鑰，用Ke加密MPK、TGK和SALT放入KEMAC載荷中。由pre-shared key再生成用于驗(yàn)證的密鑰Ka，計(jì)算出MAC值放在MAC載荷中。在發(fā)送方發(fā)送TRANSFER_INIT消息給接收方時(shí)，它使用自己生成的RAND和從KMS 獲得的MPK基于KDF生成驗(yàn)證密鑰Ka，用來(lái)計(jì)算出MAC值，根據(jù)HDR中的信息，隨機(jī)數(shù)RAND 以及TGK使用KDF生成TEKJP KEMAC中包含的SALT —起作為SRTP協(xié)議的密鑰輸入。針對(duì)lurking場(chǎng)景下MIKEY-Ticket中密鑰的生成而言，lurking情況下與非 Forking情況的惟一的區(qū)別在于KMS中會(huì)為每一個(gè)終端生成一個(gè)修正因子MOD，用來(lái)生成新的MPK和TGK。基于MOD和MPK生成分叉MPK，該分叉MPK和HDR中的參數(shù)以及隨機(jī)數(shù) RAND生成驗(yàn)證密鑰Ka，用來(lái)計(jì)算MAC?；贛OD，HDR中的參數(shù)，隨機(jī)數(shù)RAND和TGK生成分叉TEK，該TEK和KEMAC中的SALT作為SRTP協(xié)議的密鑰輸入。由于各國(guó)法律都有規(guī)定，執(zhí)法部門(mén)必須要能力對(duì)任何通話(huà)進(jìn)行合法監(jiān)聽(tīng)，所以基于KMS的端到端媒體安全解決方案也必須滿(mǎn)足合法監(jiān)聽(tīng)的需求。目前公開(kāi)成為標(biāo)準(zhǔn)的IMS控制面的合法監(jiān)聽(tīng)解決方案如圖9所示，包括監(jiān)聽(tīng)中心(LEMF)、傳送單元(DF2)、管理實(shí)體(ADMF)、被監(jiān)聽(tīng)對(duì)象(Interc印ted Subscriber)、與被監(jiān)聽(tīng)對(duì)象通話(huà)一方(Other party)、P_CSCF、S_CSCF ；LEMF通過(guò) P-CSCF 和 S-CSCF 對(duì) Intercepted Subscriber 進(jìn)行監(jiān)聽(tīng)。由于該方案沒(méi)有包含KMS網(wǎng)元，而僅僅從IMS核心網(wǎng)元截取數(shù)據(jù)，所以不具備對(duì)基于KMS的媒體安全機(jī)制的監(jiān)聽(tīng)能力，從而無(wú)法實(shí)現(xiàn)對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，能實(shí)現(xiàn)對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的一種基于密鑰管理服務(wù)器KMS的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，該系統(tǒng)包括管理實(shí)體(ADMF)、IP多媒體子系統(tǒng)(IMS)網(wǎng)元和監(jiān)聽(tīng)中心(LEMF)；該系統(tǒng)還包括KMS和信令截取單元所述ADMF，用于向所述KMS發(fā)出監(jiān)聽(tīng)命令；所述KMS，與所述ADMF相連，用于從所述ADMF接收所述監(jiān)聽(tīng)命令后，向所述信令截取單元發(fā)送監(jiān)聽(tīng)數(shù)據(jù)；所述信令截取單元，與所述KMS相連，用于將所述監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給LEMF ；所述信令截取單元或LEMF，將從所述信令截取單元中獲得的監(jiān)聽(tīng)數(shù)據(jù)與從IMS網(wǎng)元獲得的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行關(guān)聯(lián)；所述LEMF，根據(jù)關(guān)聯(lián)后的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行監(jiān)聽(tīng)。其中，所述信令截取單元單獨(dú)設(shè)置或者與IMS網(wǎng)元中的信令截取單元DF2合設(shè)。其中，所述信令截取單元與IMS網(wǎng)元中的信令截取單元DF2合設(shè)的情況下，合設(shè)后的信令截取單元，用于將從所述IMS網(wǎng)元和所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)先進(jìn)行信息關(guān)聯(lián)后，再發(fā)送給所述LEMF ；或者，將從所述IMS網(wǎng)元和所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)直接發(fā)送給所述LEMF，由所述LEMF進(jìn)行信息關(guān)聯(lián)。其中，所述信息關(guān)聯(lián)所采用的信息包括以下之一或任意組合時(shí)間戳、呼叫方的用戶(hù)地址、接收方的用戶(hù)地址。其中，所述信令截取單元單獨(dú)設(shè)置的情況下，所述IMS網(wǎng)元的信令截取單元DF2，用于將從所述IMS網(wǎng)元截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述LEMF ；所述信令截取單元，用于將從所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述LEMF ；所述LEMF根據(jù)從DF2及所述信令截取單元中接收到的數(shù)據(jù)，進(jìn)行信息關(guān)聯(lián)。其中，所述信息關(guān)聯(lián)所采用的信息包括以下之一或任意組合時(shí)間戳、呼叫方的用戶(hù)地址、接收方的用戶(hù)地址。一種基于密鑰管理服務(wù)器的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，該系統(tǒng)包括ADMF、 IMS網(wǎng)元和LEMF ；其特征在于，該系統(tǒng)還包括KMS和信令截取單元，所述信令截取單元，用于從所述IMS網(wǎng)元獲得監(jiān)聽(tīng)數(shù)據(jù)，并將其發(fā)送給所述KMS ；所述KMS，與所述信令截取單元相連，用于對(duì)所述監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行解析，并將解析結(jié)果返回信令截取單元。其中，所述信令截取單元為IMS網(wǎng)元中的信令截取單元DF2的情況下，所述DF2，用于當(dāng)所述監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述KMS，所述監(jiān)聽(tīng)數(shù)據(jù)包含的MIKEY-Ticket信息。其中，所述DF2將所述監(jiān)聽(tīng)數(shù)據(jù)中包含的MIKEY-Ticket信息發(fā)送到所述KMS ；所述KMS，進(jìn)一步用于根據(jù)所述MIKEY-Ticket信息解析，并將解析結(jié)果返回給所述 DF2。其中，所述信令截取單元為IMS網(wǎng)元中的信令截取單元DF2的情況下，所述DF2，根據(jù)本地策略，識(shí)別出從IMS網(wǎng)元中獲得不可信消息后，將從所述IMS 網(wǎng)元和信令面獲取的信息發(fā)送到KMS，從所述IMS網(wǎng)元獲取的信息包括被監(jiān)聽(tīng)用戶(hù)所使用的KMS-ID、事件的時(shí)間戳中的至少一種；從所述信令面獲取的信息包括呼叫方的用戶(hù)標(biāo)識(shí)符、接收方的用戶(hù)標(biāo)識(shí)符中的至少一種；所述KMS，進(jìn)一步用于根據(jù)DF2所提供的從所述IMS網(wǎng)元和信令面獲取的信息，找到對(duì)應(yīng)的MIKEY-Ticket信息，進(jìn)行解析，并將解析結(jié)果發(fā)送給DF2。本發(fā)明為了實(shí)現(xiàn)引入KMS這一新增網(wǎng)元后，對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)，包括兩種系統(tǒng)實(shí)現(xiàn)方案，即為引入KMS這一新增網(wǎng)元后分別對(duì)應(yīng)的推(PUSH)方案和拉 (PULL)方案。其中，PUSH方案中，該系統(tǒng)包括新增的KMS和信令截取單元；新增的KMS與 ADMF相連，用于從ADMF接收監(jiān)聽(tīng)命令，主動(dòng)向信令截取單元發(fā)送監(jiān)聽(tīng)數(shù)據(jù)；新增的信令截取單元，用于從KMS和IMS網(wǎng)元截取監(jiān)聽(tīng)數(shù)據(jù)。采用本發(fā)明，能實(shí)現(xiàn)對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)，為基于KMS的安全通信技術(shù)方案，所對(duì)應(yīng)提供的切實(shí)有效的監(jiān)聽(tīng)方案。


圖1為現(xiàn)有MIKEY-Ticket的系統(tǒng)架構(gòu)圖；圖2為現(xiàn)有MIKEY-Ticket中定義的三個(gè)密鑰協(xié)商交互流程的示意圖；圖3為現(xiàn)有REQUEST_INIT消息的示意圖；圖4為現(xiàn)有REQUEST_RESP消息的示意圖；圖5為現(xiàn)有TRANSFER_INIT消息的示意圖6為現(xiàn)有RES0LVE_INIT消息的示意圖；圖7為現(xiàn)有RES0LVE_RESP消息的示意圖；
圖8為現(xiàn)有TRANSFER_RESP消息的示意圖；圖9為現(xiàn)有已標(biāo)準(zhǔn)化的控制面的IMS合法監(jiān)聽(tīng)系統(tǒng)架構(gòu)圖；圖10為本發(fā)明系統(tǒng)的KMS-PUSH方案的系統(tǒng)架構(gòu)圖；圖11為應(yīng)用本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)下，KMS和其他監(jiān)聽(tīng)網(wǎng)元的接口示意圖；圖12為應(yīng)用本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)下，被叫方被布控時(shí)的監(jiān)聽(tīng)流程示意圖；圖13為應(yīng)用本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)下，呼叫方被布控時(shí)的監(jiān)聽(tīng)流程示意圖；圖14為本發(fā)明系統(tǒng)的KMS-PULL方案的系統(tǒng)架構(gòu)圖；圖15應(yīng)用為本發(fā)明系統(tǒng)的KMS-PULL架構(gòu)下，監(jiān)控對(duì)象為被叫方時(shí)的消息流程示意圖；圖16為應(yīng)用本發(fā)明系統(tǒng)的KMS-PULL架構(gòu)下，監(jiān)控對(duì)象為呼叫方時(shí)的消息流程示意圖。
具體實(shí)施例方式本發(fā)明的基本思想是為了實(shí)現(xiàn)引入KMS這一新增網(wǎng)元后，對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)，包括兩種系統(tǒng)實(shí)現(xiàn)方案，即為引入KMS這一新增網(wǎng)元后分別對(duì)應(yīng)的PUSH 方案和PULL方案。下面結(jié)合附圖對(duì)技術(shù)方案的實(shí)施作進(jìn)一步的詳細(xì)描述。一種基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，為了實(shí)現(xiàn)引入KMS這一新增網(wǎng)元后，對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)，包括兩種系統(tǒng)實(shí)現(xiàn)方案，即為引入KMS這一新增網(wǎng)元后分別對(duì)應(yīng)的PUSH方案和PULL方案，也可以稱(chēng)為KMS-PUSH系統(tǒng)架構(gòu)方案和 KMS-PULL系統(tǒng)架構(gòu)方案。采用KMS-PUSH系統(tǒng)架構(gòu)時(shí)，系統(tǒng)即為基于KMS的PUSH模式的系統(tǒng)；采用KMS-PULL系統(tǒng)架構(gòu)時(shí)，系統(tǒng)即為基于KMS的PULL模式的系統(tǒng)。這里需要指出的是本發(fā)明既然是基于KMS的安全通信技術(shù)方案下所提供的切實(shí)有效的監(jiān)聽(tīng)方案，由于基于KMS的安全通信技術(shù)方案不依賴(lài)于信令面的安全，因此，本發(fā)明的監(jiān)聽(tīng)方案也不依賴(lài)于信令面的安全。本發(fā)明主要包括以下內(nèi)容針對(duì)KMS-PUSH方案而言，如圖10，圖11所示即為KMS-PUSH方案的系統(tǒng)架構(gòu)，從圖 10可以看出ADMF作為用于向網(wǎng)元發(fā)送監(jiān)聽(tīng)指令的實(shí)體，對(duì)IMS網(wǎng)元和KMS單獨(dú)發(fā)出監(jiān)聽(tīng)命令，IMS網(wǎng)元和KMS獨(dú)立向DF2和DF2’發(fā)監(jiān)聽(tīng)數(shù)據(jù)。這里，DF2和DF2’即為信令截取單元的具體實(shí)現(xiàn)，DF2的全稱(chēng)為DeliveryFunction 2，可稱(chēng)為傳送單元；DF2’也可稱(chēng)為傳送單元，表示在功能上區(qū)別于DF2的傳送單元。針對(duì)傳送單元而言，傳送單元在合法監(jiān)聽(tīng)中用來(lái)截取信令面數(shù)據(jù)，并且將截取到的信息轉(zhuǎn)換成標(biāo)準(zhǔn)格式,發(fā)送到監(jiān)聽(tīng)中心(LEMF，LawEnforcement Monitoring Facility)。在實(shí)際應(yīng)用中對(duì)于信令截取單元的處理包括兩種方式一種方式，可以將DF2和DF2’作為不同的網(wǎng)絡(luò)實(shí)體， 也就是說(shuō)，在信令截取單元中分別獨(dú)立配置兩個(gè)功能單元，即DF2和DF2’，以各自實(shí)現(xiàn)不同7/
的功能，這樣進(jìn)行的功能劃分能提高系統(tǒng)整體運(yùn)行速度和效率；另一種方式可以將DF2和 DF2’整合為同一個(gè)網(wǎng)絡(luò)實(shí)體，也就是說(shuō)，在信令截取單元中僅僅配置一個(gè)功能單元，該功能單元整合了 DF2和DF2’的全部功能，并不作功能劃分，比如，信令截取單元的具體實(shí)現(xiàn)可以?xún)H僅是DF2，不過(guò)該DF2的含義指升級(jí)的DF2，既包括現(xiàn)有DF2的功能，也包括DF2’的功能， 以區(qū)別于現(xiàn)有技術(shù)中的DF2。這里，DF2和DF2’將監(jiān)聽(tīng)數(shù)據(jù)發(fā)到LEMF進(jìn)行信息關(guān)聯(lián)，如果DF2和DF2’是同一個(gè)網(wǎng)絡(luò)實(shí)體，則DF2可以將IMS網(wǎng)元和KMS發(fā)來(lái)的監(jiān)聽(tīng)數(shù)據(jù)先關(guān)聯(lián)后發(fā)給LEMF，或直接發(fā)給 LEMF,由LEMF關(guān)聯(lián)。如圖11所示，KMS和ADMF有XI) 1接口，用來(lái)接收來(lái)自ADMF的監(jiān)聽(tīng)指令； KMS和DF2有X2接口，用來(lái)向DF2傳送跟監(jiān)聽(tīng)對(duì)象有關(guān)的票據(jù)解析請(qǐng)求(Resolve Init)， 票據(jù)解析結(jié)果(Resolve Resp)，票據(jù)申請(qǐng)請(qǐng)求(Request hit)，票據(jù)申請(qǐng)響應(yīng)(Request Resp)，事件發(fā)生的時(shí)間等信息。DF2和DF2’消息的關(guān)聯(lián)可以通過(guò)無(wú)法通過(guò)信令面篡改的信息來(lái)關(guān)聯(lián)，如時(shí)間的時(shí)間戳、呼叫方和接受方的用戶(hù)地址等。針對(duì)KMS-PULL方案而言，如圖14所示即為KMS PULL方案的系統(tǒng)架構(gòu)，DF2從IMS 網(wǎng)元截取目標(biāo)用戶(hù)的會(huì)話(huà)消息，如果會(huì)話(huà)信息中包含MIKEY-Ticket消息，則DF2根據(jù)本地策略，比如分針對(duì)可信和不可信的不同策略來(lái)決定向KMS發(fā)送監(jiān)聽(tīng)命令的內(nèi)容，如果DF2從信令面截取到消息可信，DF2可以直接將截取到的Ticket發(fā)到KMS，獲得Ticket的解析結(jié)果。如果DF2從信令面截取到的信息不可信，DF2從IMS網(wǎng)元中獲得被監(jiān)聽(tīng)用戶(hù)的所使用的KMS-IDJfW IMS網(wǎng)元中獲得事件的時(shí)間戳，和從信令面獲取的不易被篡改的信息如呼叫雙方的用戶(hù)標(biāo)識(shí)符等發(fā)送到指定KMS。KMS根據(jù)DF2提供信息，找到相關(guān)的Ticket，并將 Ticket的解析結(jié)果發(fā)送給DF2。DF2可以將Ticket的解析結(jié)果發(fā)送給LEMF，由LEMF來(lái)做 Ticket信息和呼叫信息的關(guān)聯(lián)。也可以自己實(shí)現(xiàn)Ticket信息和呼叫信息的關(guān)聯(lián)處理，并將處理過(guò)的信息發(fā)送給LEMF。DF2向KMS發(fā)送監(jiān)聽(tīng)命令的時(shí)候，根據(jù)本地策略，決定發(fā)送到 KMS的數(shù)據(jù)。以下對(duì)本發(fā)明進(jìn)行舉例闡述。系統(tǒng)實(shí)施例一本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)時(shí)的實(shí)施例，信令截取單元包括DF2 和DF2’，且DF2和DF2’分別獨(dú)立設(shè)置。本實(shí)施例中，DF2作為IMS網(wǎng)元的信令截取單元， DF2’作為KMS的信令截取單元。如圖10 所示，該系統(tǒng)包括ADMF、P-CSCF, S-CSCF, KMS、DF2、DF2，和 LEMF ；其中， P-CSCF和S-CSCF都屬于IMS網(wǎng)元。ADMF，用于向KMS發(fā)出監(jiān)聽(tīng)命令。KMS，與ADMF相連，還與DF2’相連，用于從ADMF接收監(jiān)聽(tīng)命令后，向DF2’發(fā)送監(jiān)聽(tīng)數(shù)據(jù)。P-CSCF和S-CSCF，用于從ADMF接收監(jiān)聽(tīng)命令，主動(dòng)向DF2發(fā)送監(jiān)聽(tīng)數(shù)據(jù)。DF2，用于將從P-CSCF和S-CSCF截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給LEMF，由LEMF進(jìn)行信息關(guān)聯(lián)。DF2’，用于將從KMS截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給LEMF，由LEMF進(jìn)行信息關(guān)聯(lián)。LEMF，用于將從DF2和DF2’中獲得的監(jiān)聽(tīng)數(shù)據(jù)與從IMS網(wǎng)元獲得的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行關(guān)聯(lián)；根據(jù)關(guān)聯(lián)后的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行監(jiān)聽(tīng)。這里需要指出的是本系統(tǒng)實(shí)施例中的信令截取單元所包括的DF2和DF2’是分別獨(dú)立設(shè)置的。也就是說(shuō)，此時(shí)DF2和DF2’為不同的網(wǎng)絡(luò)實(shí)體，分別起作用。這里，KMS-PUSH架構(gòu)時(shí)，信令截取單元所包括的DF2和DF2’能整合為一個(gè)升級(jí)的網(wǎng)絡(luò)實(shí)體，信令截取單元即為升級(jí)的網(wǎng)絡(luò)實(shí)體。與以上系統(tǒng)實(shí)施例一的不同之處僅在于將 DF2和DF2’整合后構(gòu)成的一個(gè)升級(jí)的網(wǎng)絡(luò)實(shí)體作為信令截取單元。也就是說(shuō)，此時(shí)DF2和 DF2’為同一個(gè)網(wǎng)絡(luò)實(shí)體。DF2和DF2’是同一個(gè)網(wǎng)絡(luò)實(shí)體時(shí)，如圖11所示的接口示意圖可以看出KMS和 ADMF有Xll接口，用來(lái)接收來(lái)自ADMF的監(jiān)聽(tīng)指令；KMS和DF2有X2接口，用來(lái)向DF2傳送 β艮監(jiān)聽(tīng)對(duì)象有關(guān)的 Resolve Init, Resolve Resp, Request Init，Request Resp，事件發(fā)生的時(shí)間等信息。系統(tǒng)實(shí)施例二 本發(fā)明系統(tǒng)的KMS-PULL架構(gòu)時(shí)的實(shí)施例，且信令截取單元為IMS 網(wǎng)元的信令截取單元的情況，IMS網(wǎng)元的信令截取單元仍以DF2表示。如圖14所示，該系統(tǒng)包括ADMF、P-CSCF、S-CSCF、KMS、DF2 和 LEMF ；其中，P-CSCF 和 S-CSCF 都屬于 IMS 網(wǎng)元。DF2，用于從P-CSCF和S-CSCF截取監(jiān)聽(tīng)數(shù)據(jù)目標(biāo)用戶(hù)的會(huì)話(huà)消息，根據(jù)所述監(jiān)聽(tīng)數(shù)據(jù)采用不同的本地策略向KMS發(fā)送針對(duì)監(jiān)聽(tīng)命令的內(nèi)容。這里需要指出的是監(jiān)聽(tīng)數(shù)據(jù)也可以稱(chēng)為目標(biāo)用戶(hù)的會(huì)話(huà)消息。KMS,與DF2相連，用于根據(jù)所述針對(duì)監(jiān)聽(tīng)命令的內(nèi)容進(jìn)行解析，并將解析結(jié)果返回DF2。這里需要指出的是此處涉及的監(jiān)聽(tīng)命令與上述系統(tǒng)實(shí)施例一中涉及的監(jiān)聽(tīng)命令表達(dá)不同含義，即為二者雖然都屬于監(jiān)聽(tīng)命令，但是具體內(nèi)容和格式可能不一樣，上述系統(tǒng)實(shí)施例一中涉及的監(jiān)聽(tīng)命令是ADMF和KMS之間的；而此處涉及的監(jiān)聽(tīng)命令是DF2和KMS 之間的，二者的接口和參數(shù)都可能不一樣，不作贅述。針對(duì)不同的本地策略，DF2向KMS發(fā)送針對(duì)監(jiān)聽(tīng)命令的內(nèi)容包括以下兩種具體實(shí)現(xiàn)一 DF2用于當(dāng)采用針對(duì)可信消息的本地策略時(shí)，DF2直接將截取到消息中的 Ticket 發(fā)送到 KMS。相應(yīng)的，KMS用于根據(jù)Ticket直接解析，并將針對(duì)Ticket的解析結(jié)果返回給DF2。二 DF2用于當(dāng)采用針對(duì)不可信消息的本地策略時(shí)，DF2將從P-CSCF和S-CSCF和信令面獲取的信息發(fā)送到KMS ；其中，從P-CSCF和S-CSCF獲取的信息包括被監(jiān)聽(tīng)用戶(hù)所使用的KMS-ID、事件的時(shí)間戳中的至少一種；從信令面獲取的信息包括呼叫方的用戶(hù)標(biāo)識(shí)符、接收方的用戶(hù)標(biāo)識(shí)符中的至少一種。相應(yīng)的，KMS用于根據(jù)DF2所提供的從P-CSCF和S-CSCF和信令面獲取的信息，找到相關(guān)的Ticket，并將Ticket的解析結(jié)果發(fā)送給DF2。以下對(duì)應(yīng)用本發(fā)明系統(tǒng)架構(gòu)下的信令交互流程進(jìn)行舉例闡述。應(yīng)用實(shí)例一當(dāng)應(yīng)用本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)時(shí)的實(shí)例，如圖12所示是當(dāng)接收方(用戶(hù)B)是監(jiān)控對(duì)象時(shí)的消息流程，包括以下步驟步驟101 用戶(hù)A向KMS_A發(fā)送Ticket請(qǐng)求消息。步驟102 :KMS_A收到用戶(hù)A的請(qǐng)求后，將密鑰和Ticket通過(guò)Request Resp消息發(fā)給用戶(hù)A。步驟103 用戶(hù)A向IMS網(wǎng)絡(luò)發(fā)送Transfer Init消息。步驟104 =IMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)收到的Transfer Init消息。0126]步驟105 =IMS網(wǎng)絡(luò)向用戶(hù)B轉(zhuǎn)發(fā)Transfer Init消息
0127]步驟106 用戶(hù)B向KMS_B發(fā)送Ticket解析請(qǐng)求Resolve Init。
0128]步驟107 :KMS_B 轉(zhuǎn)發(fā) Ticket 解析請(qǐng)求 Resolve Init 到 DF2，。
0129]步驟108 :KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init 到 KMS_A。
0130]步驟109 :KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 KMS_B。
0131]步驟110 :KMS_B 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 DF2，.
0132]步驟111 :KMS_B發(fā)送Ticket解析結(jié)果Resolve Resp發(fā)給用戶(hù)B。
0133]步驟112 用戶(hù)B將向IMS網(wǎng)絡(luò)發(fā)送Transfer Resp消息。
0134]步驟113 JMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)Transfer Resp消息。
0135]步驟114 =IMS網(wǎng)絡(luò)向用戶(hù)A發(fā)送Transfer Resp消息。
0136]應(yīng)用實(shí)例二 當(dāng)應(yīng)用本發(fā)明系統(tǒng)的KMS-PUSH架構(gòu)時(shí)的實(shí)例，如圖13所示是當(dāng)發(fā)起方(用戶(hù)A)是監(jiān)控對(duì)象時(shí)的消息流程，包括以下步驟
0137]步驟201 用戶(hù)A向KMS_A發(fā)送Ticket請(qǐng)求消息。
0138]步驟202 :KMS_A向DF2，轉(zhuǎn)發(fā)Ticket請(qǐng)求消息。
0139]步驟203 :KMS_A收到用戶(hù)A的請(qǐng)求后，將密鑰和Ticket通過(guò)Request Resp消息發(fā)給用戶(hù)A。
KMS_A 將 Request Resp 消息轉(zhuǎn)發(fā)給 DF2，。 用戶(hù)A向IMS網(wǎng)絡(luò)發(fā)送Transfer Init消息。 IMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)收到的Transfer Init消息。 IMS網(wǎng)絡(luò)向用戶(hù)B轉(zhuǎn)發(fā)Transfer Init消息。 用戶(hù)B向KMS_B發(fā)送Ticket解析請(qǐng)求Resolve Init。 KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init 到 KMS_A。 KMS_A 轉(zhuǎn)發(fā) Resolve Init 到 DF2，。 KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 KMS_B。 KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 DF2，。 KMS_B發(fā)送Ticket解析結(jié)果Resolve Resp給用戶(hù)B。 用戶(hù)B將向IMS網(wǎng)絡(luò)發(fā)送Transfer Resp消息。 IMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)Transfer Resp消息。 IMS網(wǎng)絡(luò)向用戶(hù)A發(fā)送Transfer Resp消息。
三當(dāng)應(yīng)用本發(fā)明系統(tǒng)的KMS-PULL架構(gòu)時(shí)的實(shí)例，如圖15所示，當(dāng)信令面不可信，并且當(dāng)用戶(hù)B是監(jiān)聽(tīng)對(duì)象時(shí)的監(jiān)聽(tīng)流程，包括以下步驟
0154]步驟301 用戶(hù)A向KMS_A發(fā)送Ticket請(qǐng)求消息。
0155]步驟302 :KMS_A收到用戶(hù)A的請(qǐng)求后，將密鑰和Ticket通過(guò)Request Resp消息發(fā)給用戶(hù)A。
0156]步驟303 用戶(hù)A向IMS網(wǎng)絡(luò)發(fā)送Transfer Init消息。
0157]步驟304 =IMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)收到的Transfer Init消息，以及用戶(hù)B的 KMS-ID (及KMS B)，已經(jīng)事件發(fā)生的時(shí)間戳等信息。 步驟305 :DF2將事件發(fā)生的時(shí)間戳，和從Transfer Init消息中獲取不易在信令面被篡改的信息比如呼叫上方的身份標(biāo)識(shí)，發(fā)送到KMS_B。
0140]步驟2040141]步驟2050142]步驟2060143]步驟2070144]步驟2080145]步驟2090146]步驟2100147]步驟2110148]步驟2120149]步驟2130150]步驟2140151]步驟2150152]步驟2160153]應(yīng)用實(shí)例
步驟306 =IMS網(wǎng)絡(luò)向用戶(hù)B轉(zhuǎn)發(fā)Transfer Init消息。步驟307 用戶(hù) B 向 KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init。步驟308 :KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init 到 KMS_A。步驟309 :KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 KMS_B。步驟310 :KMS_B 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 DF2。步驟311 :KMS_B 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給用戶(hù) B。步驟312 用戶(hù)B將向IMS網(wǎng)絡(luò)發(fā)送Transfer Resp消息。步驟313 JMS 網(wǎng)絡(luò)向 DF2 轉(zhuǎn)發(fā) Transfer Resp 消息。步驟314 =IMS網(wǎng)絡(luò)向用戶(hù)A發(fā)送Transfer Resp消息。應(yīng)用實(shí)例四當(dāng)應(yīng)用本發(fā)明系統(tǒng)的KMS-PULL架構(gòu)時(shí)的實(shí)例，如圖16所示，當(dāng)信令面不可信，并且當(dāng)呼叫方(用戶(hù)A)是監(jiān)聽(tīng)對(duì)象時(shí)的監(jiān)聽(tīng)流程，包括以下步驟步驟401 用戶(hù)A向KMS_A發(fā)送Ticket請(qǐng)求消息。步驟402 :KMS_A收到用戶(hù)A的請(qǐng)求后，將密鑰和Ticket通過(guò)Request Resp消息發(fā)給用戶(hù)A。步驟403 用戶(hù)A向IMS網(wǎng)絡(luò)發(fā)送Transfer Init消息。步驟404 IMS網(wǎng)絡(luò)向DF2轉(zhuǎn)發(fā)收到的Transfer Init消息，以及用戶(hù)A的 KMS-ID (及KMS_A)，已經(jīng)事件發(fā)生的時(shí)間戳等信息。步驟405 :DF2將事件發(fā)生的時(shí)間戳，和從Transfer Init消息中獲取不易在信令面被篡改的信息比如呼叫上方的身份標(biāo)識(shí)，發(fā)送到KMS_A。步驟406 =IMS網(wǎng)絡(luò)向用戶(hù)B轉(zhuǎn)發(fā)Transfer Init消息。步驟407 用戶(hù) B 向 KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init。步驟408 :KMS_B 發(fā)送 Ticket 解析請(qǐng)求 Resolve Init 到 KMS_A。步驟409 :KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 DF2。步驟410 :KMS_A 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給 KMS_B。步驟411 :KMS_B 發(fā)送 Ticket 解析結(jié)果 Resolve Resp 給用戶(hù) B。步驟412 用戶(hù)B將向IMS網(wǎng)絡(luò)發(fā)送Transfer Resp消息。步驟413 JMS 網(wǎng)絡(luò)向 DF2 轉(zhuǎn)發(fā) Transfer Resp 消息。步驟414 =IMS網(wǎng)絡(luò)向用戶(hù)A發(fā)送Transfer Resp消息。這里，對(duì)以上文字包括附圖中文字的中英文進(jìn)行說(shuō)明BSF指服務(wù)功能；Media Key指媒體密鑰；KMS指密鑰管理服務(wù)器；NAF指應(yīng)用服務(wù)器；Key-info指；P-CSCF指代理呼叫會(huì)話(huà)控制單元；S-CSCF指服務(wù)呼叫會(huì)話(huà)控制單元；Request Init指票據(jù)請(qǐng)求；Request Resp指票據(jù)請(qǐng)求結(jié)果；Transfer Init指票據(jù)傳輸請(qǐng)求；Transfer Resp指票據(jù)傳輸請(qǐng)求應(yīng)答；Resolve Init指票據(jù)解析請(qǐng)求；Resolve Resp指票據(jù)解析結(jié)果信息。以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種基于密鑰管理服務(wù)器KMS的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，該系統(tǒng)包括管理實(shí)體(ADMF)、IP多媒體子系統(tǒng)(IMS)網(wǎng)元和監(jiān)聽(tīng)中心(LEMF)；其特征在于，該系統(tǒng)還包括 KMS和信令截取單元所述ADMF，用于向所述KMS發(fā)出監(jiān)聽(tīng)命令；所述KMS，與所述ADMF相連，用于從所述ADMF接收所述監(jiān)聽(tīng)命令后，向所述信令截取單元發(fā)送監(jiān)聽(tīng)數(shù)據(jù)；所述信令截取單元，與所述KMS相連，用于將所述監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給LEMF ； 所述信令截取單元或LEMF，將從所述信令截取單元中獲得的監(jiān)聽(tīng)數(shù)據(jù)與從IMS網(wǎng)元獲得的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行關(guān)聯(lián)；所述LEMF，根據(jù)關(guān)聯(lián)后的監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行監(jiān)聽(tīng)。
2.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述信令截取單元單獨(dú)設(shè)置或者與IMS網(wǎng)元中的信令截取單元DF2合設(shè)。
3.根據(jù)權(quán)利要求2所述的系統(tǒng)，其特征在于，所述信令截取單元與IMS網(wǎng)元中的信令截取單元DF2合設(shè)的情況下，合設(shè)后的信令截取單元，用于將從所述IMS網(wǎng)元和所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)先進(jìn)行信息關(guān)聯(lián)后，再發(fā)送給所述LEMF ；或者，將從所述IMS網(wǎng)元和所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)直接發(fā)送給所述LEMF，由所述LEMF進(jìn)行信息關(guān)聯(lián)。
4.根據(jù)權(quán)利要求3所述的系統(tǒng)，其特征在于，所述信息關(guān)聯(lián)所采用的信息包括以下之一或任意組合時(shí)間戳、呼叫方的用戶(hù)地址、接收方的用戶(hù)地址。
5.根據(jù)權(quán)利要求2所述的系統(tǒng)，其特征在于，所述信令截取單元單獨(dú)設(shè)置的情況下， 所述IMS網(wǎng)元的信令截取單元DF2，用于將從所述IMS網(wǎng)元截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述LEMF ；所述信令截取單元，用于將從所述KMS截取的監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述LEMF ； 所述LEMF根據(jù)從DF2及所述信令截取單元中接收到的數(shù)據(jù)，進(jìn)行信息關(guān)聯(lián)。
6.根據(jù)權(quán)利要求5所述的系統(tǒng)，其特征在于，所述信息關(guān)聯(lián)所采用的信息包括以下之一或任意組合時(shí)間戳、呼叫方的用戶(hù)地址、接收方的用戶(hù)地址。
7.一種基于密鑰管理服務(wù)器的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，該系統(tǒng)包括ADMF、IMS 網(wǎng)元和LEMF ；其特征在于，該系統(tǒng)還包括KMS和信令截取單元，所述信令截取單元，用于從所述IMS網(wǎng)元獲得監(jiān)聽(tīng)數(shù)據(jù)，并將其發(fā)送給所述KMS ； 所述KMS，與所述信令截取單元相連，用于對(duì)所述監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行解析，并將解析結(jié)果返回信令截取單元。
8.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述信令截取單元為IMS網(wǎng)元中的信令截取單元DF2的情況下，所述DF2，用于當(dāng)所述監(jiān)聽(tīng)數(shù)據(jù)發(fā)送給所述KMS，所述監(jiān)聽(tīng)數(shù)據(jù)包含的MIKEY-Ticket信息。
9.根據(jù)權(quán)利要求8所述的系統(tǒng)，其特征在于，所述DF2將所述監(jiān)聽(tīng)數(shù)據(jù)中包含的 MIKEY-Ticket信息發(fā)送到所述KMS ；所述KMS，進(jìn)一步用于根據(jù)所述MIKEY-Ticket信息解析，并將解析結(jié)果返回給所述DF2。
10.根據(jù)權(quán)利要求7所述的系統(tǒng)，其特征在于，所述信令截取單元為IMS網(wǎng)元中的信令截取單元DF2的情況下，所述DF2，根據(jù)本地策略，識(shí)別出從IMS網(wǎng)元中獲得不可信消息后，將從所述IMS網(wǎng)元和信令面獲取的信息發(fā)送到KMS，從所述IMS網(wǎng)元獲取的信息包括被監(jiān)聽(tīng)用戶(hù)所使用的 KMS-ID、事件的時(shí)間戳中的至少一種；從所述信令面獲取的信息包括呼叫方的用戶(hù)標(biāo)識(shí)符、接收方的用戶(hù)標(biāo)識(shí)符中的至少一種；所述KMS，進(jìn)一步用于根據(jù)DF2所提供的從所述IMS網(wǎng)元和信令面獲取的信息，找到對(duì)應(yīng)的MIKEY-Ticket信息，進(jìn)行解析，并將解析結(jié)果發(fā)送給DF2。
全文摘要
本發(fā)明公開(kāi)了一種基于密鑰管理服務(wù)器的IMS媒體安全的合法監(jiān)聽(tīng)系統(tǒng)，包括推(PUSH)和拉(PULL)兩種系統(tǒng)實(shí)現(xiàn)方案；其中，PULL模式的系統(tǒng)包括信令截取單元，用于從所述IMS網(wǎng)元獲得監(jiān)聽(tīng)數(shù)據(jù)，并將其發(fā)送給所述KMS；KMS與信令截取單元相連，用于用于對(duì)所述監(jiān)聽(tīng)數(shù)據(jù)進(jìn)行解析，并將解析結(jié)果返回信令截取單元。采用本發(fā)明，能實(shí)現(xiàn)對(duì)基于KMS的IMS媒體安全的合法監(jiān)聽(tīng)。
文檔編號(hào)H04W12/04GK102223356SQ20101015083
公開(kāi)日2011年10月19日 申請(qǐng)日期2010年4月19日 優(yōu)先權(quán)日2010年4月19日
發(fā)明者朱允文, 田甜, 韋銀星, 高峰 申請(qǐng)人:中興通訊股份有限公司