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

發(fā)明內容
本發(fā)明所要解決的技術問題在于，提供一種基于密鑰管理服務器的媒體安全合法 監(jiān)聽方法及系統(tǒng)，解決現(xiàn)有監(jiān)聽技術中根據(jù)截取的會話信息獲取媒體密鑰時，可能會出錯 而無法保證準確獲取媒體密鑰進行安全監(jiān)聽的問題。為了解決上述問題，本發(fā)明提出了一種基于密鑰管理服務器的媒體安全合法監(jiān)聽 方法，包括如下步驟密鑰管理服務器保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒體 密鑰請求；所述密鑰管理服務器向所述監(jiān)聽設備返回所述媒體主密鑰或用于生成媒體主密 鑰的密鑰材料；監(jiān)聽設備根據(jù)接收的所述媒體主密鑰或者根據(jù)所接收的所述用于生成媒體主密 鑰的密鑰材料生成的媒體主密鑰，進行會話監(jiān)聽。所述密鑰材料包括票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機數(shù)、接收方生成 的隨機數(shù)、MOD值。所述密鑰材料，來自于發(fā)起呼叫的呼叫發(fā)起終端和/或來自于接收呼叫的呼叫接 收終端。所述監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，獲取用戶標識信息，在向所 述密鑰管理服務器發(fā)送的媒體密鑰請求中攜帶所述用戶標識信息。所述密鑰管理服務器向所述監(jiān)聽設備返回所述媒體主密鑰或用于生成媒體主密 鑰的密鑰材料之前，按照所述媒體密鑰請求中攜帶的用戶標識信息，查找與用戶標識信息對應的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所述監(jiān)聽設備返回所 述媒體主密鑰或用于生成媒體主密鑰的密鑰材料。所述密鑰管理服務器向所述監(jiān)聽設備返回的媒體主密鑰，可采用根據(jù)用戶標識信 息直接查找到的媒體主密鑰，或者采用根據(jù)用戶標識信息查找到的密鑰材料由密鑰管理服 務器生成的媒體主密鑰。所述的媒體安全合法監(jiān)聽方法進一步包括監(jiān)聽設備從信令面獲取通話終止的信令后，通知密鑰管理服務器釋放在通話期間 保存的密鑰材料。本發(fā)明還提供一種基于密鑰管理服務器的媒體安全合法監(jiān)聽系統(tǒng)，包括密鑰管 理服務器，監(jiān)聽設備，其中密鑰管理服務器，用于保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，根 據(jù)監(jiān)聽設備的請求向所述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備，從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒 體密鑰請求，并根據(jù)從密鑰管理服務器接收的媒體主密鑰或者根據(jù)所接收的用于生成媒體 主密鑰的密鑰材料生成的媒體主密鑰進行會話監(jiān)聽。所述密鑰材料包括票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機數(shù)、接收方生成 的隨機數(shù)、MOD值。所述密鑰材料，來自于發(fā)起呼叫的呼叫發(fā)起終端和/或來自于接收呼叫的呼叫接 收終端。所述監(jiān)聽設備，還用于從信令面截取到會話初始協(xié)議消息中獲取用戶標識信息， 在向所述密鑰管理服務器發(fā)送的媒體密鑰請求中攜帶所述用戶標識信息。所述密鑰管理服務器，是按照所述媒體密鑰請求中攜帶的用戶標識信息，查找與 用戶標識信息對應的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所述監(jiān) 聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料。所述密鑰管理服務器向所述監(jiān)聽設備返回的媒體主密鑰，是根據(jù)用戶標識信息直 接查找到的媒體主密鑰，或者是根據(jù)用戶標識信息查找到的密鑰材料由密鑰管理服務器生 成的媒體主密鑰。所述監(jiān)聽設備，進一步還用于在從信令面獲取通話終止的信令后，通知密鑰管理 服務器釋放在通話期間保存的密鑰材料。本發(fā)明的基于密鑰管理服務器的媒體安全合法監(jiān)聽方法及系統(tǒng)，為避免從會話信 息截取進而獲取媒體密鑰時存在的問題，由密鑰管理服務器直接保存媒體主密鑰或者用于 生成媒體主密鑰的密鑰材料，根據(jù)監(jiān)聽設備的請求向所述監(jiān)聽設備返回媒體主密鑰或用于 生成媒體主密鑰的密鑰材料；監(jiān)聽設備根據(jù)從密鑰管理服務器接收的媒體主密鑰或者根據(jù) 按照所接收的密鑰材料生成的媒體主密鑰進行會話監(jiān)聽。由于密鑰管理服務器KMS保存的密鑰材料都來自發(fā)送方和/或接收方，而不是從 會話中截取上報，因而，可以避免因截取信息錯誤而導致的無法正確獲得媒體密鑰的問題 出現(xiàn)，可以保證監(jiān)聽設備總可以獲得正確的媒體密鑰，按照媒體密鑰進行合法監(jiān)聽業(yè)務。并 且，密鑰材料或媒體主密鑰可以來自發(fā)送方或接收方，可多方面保證獲取密鑰信息，進一步 保證了密鑰準確性。


圖1是MIKEY-TICKET的架構圖；圖2是MIKEY-TICKET中定義的三個密鑰協(xié)商交互流程示意圖；圖3是REQUEST_INIT消息示意圖；圖4是REQUEST_RESP消息示意圖；圖5是TRANSFER_INIT消息示意圖；圖6是RES0LVE_INIT消息示意圖；圖7是RES0LVE_RESP消息示意圖；圖8是TRANSFER_RESP消息示意圖；圖9是MIKEY-TICKET中非lurking情況下密鑰關系及生成示意10是Forking場景中MIKEY-TICKET中密鑰關系及生成示意圖；圖11是本發(fā)明的基于KMS的媒體安全合法監(jiān)聽方法流程圖；圖12是本發(fā)明的基于KMS的媒體安全合法監(jiān)聽系統(tǒng)示意圖。
具體實施例方式為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，以下結合附圖對本發(fā)明作進一步 地詳細說明。本發(fā)明的基于密鑰管理服務器的媒體安全合法監(jiān)聽方法及系統(tǒng)，針對現(xiàn)有合法監(jiān) 聽的技術方案中，采用端到端共享密鑰進行完整性保護而無法保證合法監(jiān)聽設備根據(jù)所截 取到的信令都能獲得正確的密鑰參數(shù)的問題，通過對密鑰管理服務器KMS的改進，增加保 存密鑰材料，利用票據(jù)、發(fā)送方和接收方生成的隨機數(shù)RANDi、RANDr以及MOD值等，來保證 監(jiān)聽設備獲得正確的媒體密鑰。如圖11所示，本發(fā)明的一種基于密鑰管理服務器的媒體安全合法監(jiān)聽方法，包括 如下步驟密鑰管理服務器保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒體 密鑰請求；所述密鑰管理服務器向所述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的 密鑰材料；監(jiān)聽設備根據(jù)接收的媒體主密鑰或者根據(jù)按照所接收的密鑰材料生成的媒體主 密鑰進行會話監(jiān)聽。其中，所述密鑰材料包括但不限于票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機 數(shù)RANDi、接收方生成的隨機數(shù)RANDr、MOD值等。其中，所述監(jiān)聽設備從信令面截取到的會話初始協(xié)議SIP消息(包含 MIKEY-TICKET消息)后，從截取到的會話消息中獲取SIP URI (會話地址)，TEL URI (電話 地址)等用戶標識信息，在所述媒體密鑰請求中攜帶關于會話的用戶標識信息。其中，所述密鑰管理服務器按照所述關于會話的用戶標識信息，查找與用戶標識 信息對應的保存在本地的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料。其中，密鑰管理服務器所保存的所述密鑰材料，可以來自于發(fā)起呼叫的呼叫發(fā)起 終端，呼叫發(fā)起終端可以將票據(jù)和自己生成的呼叫方隨機數(shù)發(fā)送給KMS進行保存；也可以 來自呼叫接收終端，呼叫接收終端將所收到的票據(jù)和呼叫方隨機數(shù)，以及自己產生的接收 方隨機數(shù)一起發(fā)送給KMS進行保存；或者呼叫接收終端僅發(fā)送自己產生的接收方隨機數(shù)； 或者，僅發(fā)送所收到的票據(jù)和自己產生的接收方隨機數(shù)。一種接收方上報密鑰材料的方式為接收方收到來自發(fā)送方的基于密鑰管理服務 器的端到端呼叫請求后，向所述密鑰管理服務器發(fā)送票據(jù)解析請求，所述票據(jù)解析請求攜 帶待解析的票據(jù)、發(fā)送方生成的隨機數(shù)RANDi和接收方生成的隨機數(shù)RANDr。其中，所述密鑰管理服務器KMS接收到監(jiān)聽設備發(fā)來的監(jiān)聽媒體密鑰請求消息 時，可以使用兩種方式獲得媒體主密鑰AUKMS根據(jù)從監(jiān)聽設備截取到的SIP URI,TEL URI等用戶標識信息找到存在KMS 的密鑰材料，按照所述密鑰材料生成媒體主密鑰；A2、KMS直接根據(jù)從監(jiān)聽設備截取到的SIP URI, TEL URI等用戶標識信息找到存 在本地的密鑰主密鑰。其中，所述密鑰管理服務器KMS可以使用兩種方式將媒體主密鑰發(fā)送給監(jiān)聽設 備Bi、KMS獲取對應會話的密鑰材料后，可以將密鑰材料發(fā)給監(jiān)聽設備，由監(jiān)聽設備 按照密鑰材料生成媒體主密鑰。B2、KMS獲取對應會話的密鑰材料后可以按照密鑰材料派生出媒體主密鑰，然后將 媒體主密鑰發(fā)送給監(jiān)聽設備，或者查找到自己保存的媒體主密鑰，將自己保存的媒體主密 鑰直接發(fā)送給監(jiān)聽設備。進一步地，監(jiān)聽設備從信令面獲取通話終止的信令后，需要通知KMS釋放在通話 期間保存的密鑰材料。根據(jù)以上所述，KMS需要和監(jiān)聽設備建立接口，該接口需要具備以下功能Cl、監(jiān)聽設備向KMS發(fā)送監(jiān)聽到的會話信息，KMS能根據(jù)從監(jiān)聽設備發(fā)來的消息來 識別通話的開始和結束以及通話雙方的身份信息，這樣KMS才可從本地保存的媒體主密鑰 或媒體材料中查找到對應的媒體主密鑰或媒體材料。C2、KMS需要向監(jiān)聽設備發(fā)送媒體主密鑰或密鑰材料。如圖12所示，本發(fā)明的一種基于密鑰管理服務器的媒體安全合法監(jiān)聽系統(tǒng)，包 括密鑰管理服務器，監(jiān)聽設備，發(fā)送方終端，接收方終端；密鑰管理服務器，用于保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，根 據(jù)監(jiān)聽設備的請求向所述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備，從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒 體密鑰請求，并根據(jù)從密鑰管理服務器接收的媒體主密鑰或者根據(jù)按照所接收的密鑰材料 生成的媒體主密鑰進行會話監(jiān)聽。其中，所述密鑰材料包括但不限于票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機 數(shù)RANDi、接收方生成的隨機數(shù)RANDr、MOD值等。其中，所述監(jiān)聽設備從信令面截取到的會話初始協(xié)議SIP消息(包含MIKEY-TICKET消息)后，從截取到的會話消息中獲取SIP URI (會話地址)，TEL URI (電話 地址)等用戶標識信息，在所述媒體密鑰請求中攜帶關于會話的用戶標識信息。其中，所述密鑰管理服務器按照所述關于會話的用戶標識信息，查找與用戶標識 信息對應的保存在本地的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所 述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料。其中，密鑰管理服務器所保存的所述密鑰材料，可以來自于發(fā)起呼叫的呼叫發(fā)起 終端，呼叫發(fā)起終端可以將票據(jù)和自己生成的呼叫方隨機數(shù)發(fā)送給KMS進行保存；也可以 來自呼叫接收終端，呼叫接收終端將所收到的票據(jù)和呼叫方隨機數(shù)，以及自己產生的接收 方隨機數(shù)一起發(fā)送給KMS進行保存；或者呼叫接收終端僅發(fā)送自己產生的接收方隨機數(shù)； 或者，僅發(fā)送所收到的票據(jù)和自己產生的接收方隨機數(shù)。一種接收方上報密鑰材料的方式為接收方收到來自發(fā)送方的基于密鑰管理服務 器的端到端呼叫請求后，向所述密鑰管理服務器發(fā)送票據(jù)解析請求，所述票據(jù)解析請求攜 帶待解析的票據(jù)、發(fā)送方生成的隨機數(shù)RANDi和接收方生成的隨機數(shù)RANDr。其中，所述密鑰管理服務器KMS接收到監(jiān)聽設備發(fā)來的監(jiān)聽媒體密鑰請求消息 時，可以使用兩種方式獲得媒體主密鑰AUKMS根據(jù)從監(jiān)聽設備截取到的SIP URIjTEL URI等用戶標識信息找到存在KMS 的密鑰材料，按照所述密鑰材料生成媒體主密鑰；A2、KMS直接根據(jù)從監(jiān)聽設備截取到的SIP URI, TEL URI等用戶標識信息找到存 在本地的密鑰主密鑰。其中，所述密鑰管理服務器KMS可以使用兩種方式將媒體主密鑰發(fā)送給監(jiān)聽設 備Bi、KMS獲取對應會話的密鑰材料后，可以將密鑰材料發(fā)給監(jiān)聽設備，由監(jiān)聽設備 按照密鑰材料生成媒體主密鑰。B2、KMS獲取對應會話的密鑰材料后可以按照密鑰材料派生出媒體主密鑰，然后將 媒體主密鑰發(fā)送給監(jiān)聽設備，或者查找到自己保存的媒體主密鑰，將自己保存的媒體主密 鑰直接發(fā)送給監(jiān)聽設備。進一步地，監(jiān)聽設備從信令面獲取通話終止的信令后，需要通知KMS釋放在通話 期間保存的密鑰材料。根據(jù)以上所述，KMS需要和監(jiān)聽設備建立接口，該接口需要具備以下功能Cl、監(jiān)聽設備向KMS發(fā)送監(jiān)聽到的會話信息，KMS能根據(jù)從監(jiān)聽設備發(fā)來的消息來 識別通話的開始和結束以及通話雙方的身份信息，這樣KMS才可從本地保存的媒體主密鑰 或媒體材料中查找到對應的媒體主密鑰或媒體材料。C2、KMS需要向監(jiān)聽設備發(fā)送媒體主密鑰或密鑰材料。以上所述僅為本發(fā)明的實施例而已，并不用于限制本發(fā)明，對于本領域的技術人 員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、 等同替換、改進等，均應包含在本發(fā)明的權利要求范圍之內。
權利要求
1.一種基于密鑰管理服務器的媒體安全合法監(jiān)聽方法，其特征在于，包括如下步驟密鑰管理服務器保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒體密鑰 請求；所述密鑰管理服務器向所述監(jiān)聽設備返回所述媒體主密鑰或用于生成媒體主密鑰的 密鑰材料；監(jiān)聽設備根據(jù)接收的所述媒體主密鑰或者根據(jù)所接收的所述用于生成媒體主密鑰的 密鑰材料生成的媒體主密鑰，進行會話監(jiān)聽。
2.如權利要求1所述的媒體安全合法監(jiān)聽方法，其特征在于，所述密鑰材料包括票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機數(shù)、接收方生成的隨 機數(shù)、MOD值。
3.如權利要求2所述的媒體安全合法監(jiān)聽方法，其特征在于，所述密鑰材料，來自于發(fā)起呼叫的呼叫發(fā)起終端和/或來自于接收呼叫的呼叫接收終端。
4.如權利要求1所述的媒體安全合法監(jiān)聽方法，其特征在于，所述監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，獲取用戶標識信息，在向所述密 鑰管理服務器發(fā)送的媒體密鑰請求中攜帶所述用戶標識信息。
5.如權利要求4所述的媒體安全合法監(jiān)聽方法，其特征在于，所述密鑰管理服務器向所述監(jiān)聽設備返回所述媒體主密鑰或用于生成媒體主密鑰的 密鑰材料之前，按照所述媒體密鑰請求中攜帶的用戶標識信息，查找與用戶標識信息對應 的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所述監(jiān)聽設備返回所述媒 體主密鑰或用于生成媒體主密鑰的密鑰材料。
6.如權利要求5所述的媒體安全合法監(jiān)聽方法，其特征在于，所述密鑰管理服務器向所述監(jiān)聽設備返回的媒體主密鑰，可采用根據(jù)用戶標識信息直 接查找到的媒體主密鑰，或者采用根據(jù)用戶標識信息查找到的密鑰材料由密鑰管理服務器 生成的媒體主密鑰。
7.如權利要求1所述的媒體安全合法監(jiān)聽方法，其特征在于，所述的媒體安全合法監(jiān) 聽方法進一步包括監(jiān)聽設備從信令面獲取通話終止的信令后，通知密鑰管理服務器釋放在通話期間保存 的密鑰材料。
8.一種基于密鑰管理服務器的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，包括密鑰管理 服務器，監(jiān)聽設備，其中密鑰管理服務器，用于保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，根據(jù)監(jiān) 聽設備的請求向所述監(jiān)聽設備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備，從信令面截取到會話初始協(xié)議消息后，向所述密鑰管理服務器發(fā)送媒體密 鑰請求，并根據(jù)從密鑰管理服務器接收的媒體主密鑰或者根據(jù)所接收的用于生成媒體主密 鑰的密鑰材料生成的媒體主密鑰進行會話監(jiān)聽。
9.如權利要求8所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述密鑰材料包括票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機數(shù)、接收方生成的隨機數(shù)、MOD值。
10.如權利要求9所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述密鑰材料，來自于發(fā)起呼叫的呼叫發(fā)起終端和/或來自于接收呼叫的呼叫接收終端。
11.如權利要求8所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述監(jiān)聽設備，還用于從信令面截取到會話初始協(xié)議消息中獲取用戶標識信息，在向 所述密鑰管理服務器發(fā)送的媒體密鑰請求中攜帶所述用戶標識信息。
12.如權利要求11所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述密鑰管理服務器，是按照所述媒體密鑰請求中攜帶的用戶標識信息，查找與用戶 標識信息對應的媒體主密鑰或者用于生成媒體主密鑰的密鑰材料，找到后，向所述監(jiān)聽設 備返回媒體主密鑰或用于生成媒體主密鑰的密鑰材料。
13.如權利要求12所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述密鑰管理服務器向所述監(jiān)聽設備返回的媒體主密鑰，是根據(jù)用戶標識信息直接查 找到的媒體主密鑰，或者是根據(jù)用戶標識信息查找到的密鑰材料由密鑰管理服務器生成的 媒體主密鑰。
14.如權利要求8所述的媒體安全合法監(jiān)聽系統(tǒng)，其特征在于，所述監(jiān)聽設備，進一步還用于在從信令面獲取通話終止的信令后，通知密鑰管理服務 器釋放在通話期間保存的密鑰材料。
全文摘要
本發(fā)明公開了一種基于密鑰管理服務器的媒體安全合法監(jiān)聽方法及系統(tǒng)，所述系統(tǒng)包括密鑰管理服務器KMS和監(jiān)聽設備，所述KMS保存媒體主密鑰或者用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備從信令面截取到會話初始協(xié)議消息后，向所述KMS發(fā)送媒體密鑰請求；所述KMS向所述監(jiān)聽設備返回所述媒體主密鑰或用于生成媒體主密鑰的密鑰材料；監(jiān)聽設備根據(jù)接收的所述媒體主密鑰或者根據(jù)所接收的所述用于生成媒體主密鑰的密鑰材料生成的媒體主密鑰，進行會話監(jiān)聽。所述密鑰材料包括票據(jù)或者票據(jù)的解析結果、發(fā)送方生成的隨機數(shù)、接收方生成的隨機數(shù)、MOD值。本發(fā)明可以保證監(jiān)聽設備準確獲取媒體密鑰進行安全監(jiān)聽。
文檔編號H04L9/08GK102055585SQ20091021208
公開日2011年5月11日 申請日期2009年11月4日 優(yōu)先權日2009年11月4日
發(fā)明者朱允文, 田甜, 韋銀星, 高峰 申請人:中興通訊股份有限公司