專利名稱：安全協(xié)商會話密鑰的方法及裝置的制作方法
技術領域：
本發(fā)明涉及密鑰處理技術，尤其涉及一種安全協(xié)商會話密鑰的方法及裝置。
背景技術：
在下一代網(wǎng)絡(NGN)系統(tǒng)中，運營商為了減少建設成本和方便用戶接入，網(wǎng)絡電 話(VoIP)的信令和媒體數(shù)據(jù)均通過互聯(lián)網(wǎng)(Internet)傳輸。由于互聯(lián)網(wǎng)協(xié)議(IP)網(wǎng)絡 是一個開放的網(wǎng)絡，其安全性不高，因此，為了防止用戶電話被竊聽，需要對會話中傳輸?shù)?媒體流進行加密以保障語音通話安全，用于加密媒體流的密鑰稱為會話密鑰(SK， Session Key)。 目前，現(xiàn)有技術中關于會話密鑰的協(xié)商方式主要有兩種點對點直接協(xié)商與軟交 換(SS)分配密鑰。 圖1示出了兩個接入網(wǎng)關(AG)點對點直接協(xié)商獲取SK的實例，如圖1所示在進 行呼叫前，作為密鑰發(fā)起方的AG1向密鑰接收方AG2發(fā)送請求消息(LMESSAGE)，其中攜帶 會話密鑰協(xié)商的相關信息；AG2接收會話密鑰協(xié)商的相關信息后，向AG1發(fā)送應答消息(R_ MESSAGE)，這樣，雙方就可根據(jù)具體的安全協(xié)議如安全實時傳輸協(xié)議(SRTP)用獲得的會話 密鑰分別加密和解密媒體流。但是，點對點直接協(xié)商方式不是非常適用于AG這種組交換設 備的應用場景，因為AG的用戶很多，如果多個用戶同時需要進行呼叫，則密鑰協(xié)商的消息 交互數(shù)量非常多，會造成大量系統(tǒng)資源的浪費。 因此，業(yè)界大多傾向于SS分配密鑰的方式SS為需要進行呼叫的AG1和AG2分配 會話密鑰并通過信令通道傳送給AG1和AG2，如圖2所示。 其中，由于信令通道也存在不安全性，因此為了保證會話密鑰不被竊取，需要對會
話密鑰進行加密?，F(xiàn)有技術中對會話密鑰的加密主要有以下幾種方式
1、預設共享密鑰 為每個AG手工配置原始密鑰作為預設共享密鑰，SS直接采用該原始密鑰對會話 密鑰加密。 2、公共密鑰 利用公鑰基礎設施(PKI)為每個AG配置一個密鑰對，該密鑰對包括公鑰和私鑰， SS用每個AG的公鑰對會話密鑰進行加密。
3、DH交換 每次呼叫前都進行一次DH(Differ-Hellman)交換，SS用DH交換得到的密鑰對會 話密鑰進行加密。 然而，上述三種方式各有不可忽視的缺點，其中，預設共享密鑰這種方式的缺點 是算法簡單、安全性差、容易被破解；公共密鑰這種方式的缺點是需要PKI系統(tǒng)的支持， 而目前應用于通訊領域的PKI系統(tǒng)還有待建立，所以這種方式暫時不具備可行性；DH交換 這種方式的缺點是雖然安全性高，但由于算法復雜，且每次呼叫前都要進行一次DH交換， 所以計算量過大，嚴重影響系統(tǒng)的性能。由于這些原因，導致目前NGN系統(tǒng)中的語音安全性保障難以實現(xiàn)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種非安全通道下容易實施且有效的安全
協(xié)商會話密鑰的方法及裝置，以保證語音通話的安全。 為達到上述目的，本發(fā)明的技術方案是這樣實現(xiàn)的 —種安全協(xié)商會話密鑰的方法，接入網(wǎng)關向軟交換注冊成功后，二者分別獲取共 享密鑰，并各自在自身存儲所述共享密鑰；該方法還包括 已注冊的接入網(wǎng)關每次進行會話前，所述軟交換根據(jù)接入網(wǎng)關的請求為會話分配 會話密鑰，并且用所述共享密鑰對所分配的會話密鑰進行加密，之后將加密的會話密鑰發(fā) 送給所述接入網(wǎng)關； 所述接入網(wǎng)關每次收到加密的會話密鑰后，均用所述共享密鑰對已加密的會話密 鑰進行解密，獲取會話密鑰。 其中，所述接入網(wǎng)關解密會話密鑰后，該方法還包括 所述接入網(wǎng)關用解密后的會話密鑰對會話中需發(fā)送的媒體流加密、或?qū)捴薪?收到的媒體流解密。 其中，所述用共享密鑰對會話密鑰進行加密或解密的算法為MD5。 —種安全協(xié)商會話密鑰的裝置，包括共享密鑰的產(chǎn)生及存儲模塊、會話密鑰的分
配模塊、會話密鑰的加密模塊、會話密鑰的發(fā)送模塊、會話密鑰的接收模塊和會話密鑰的解
密模塊，其中 共享密鑰的產(chǎn)生及存儲模塊，用于在接入網(wǎng)關向軟交換注冊成功后產(chǎn)生共享密 鑰，并存儲所述已產(chǎn)生的共享密鑰； 會話密鑰的分配模塊，用于為每次會話分配會話密鑰； 會話密鑰的加密模塊，用于利用所述共享密鑰對所分配的會話密鑰進行加密；
會話密鑰的發(fā)送模塊，用于發(fā)送加密的會話密鑰；
會話密鑰的接收模塊，用于接收加密的會話密鑰； 會話密鑰的解密模塊，用于利用所述共享密鑰對收到的已加密的會話密鑰進行解 密。 其中，所述共享密鑰的產(chǎn)生及存儲模塊分別位于所述接入網(wǎng)關及軟交換中；
所述會話密鑰的分配模塊及會話密鑰的加密模塊位于所述軟交換中，所述會話密 鑰的解密模塊位于所述接入網(wǎng)關中； 所述會話密鑰的發(fā)送模塊位于所述軟交換中，所述會話密鑰的接收模塊位于所述 接入網(wǎng)關中。 另外，所述裝置還包括媒體流的加密模塊和媒體流的解密模塊，其中 媒體流的加密模塊，用于利用解密后的會話密鑰對會話中需發(fā)送的媒體流進行加
密； 媒體流的解密模塊，用于利用解密后的會話密鑰對會話中接收到的媒體流進行解 密。 其中，所述媒體流的加密模塊及媒體流的解密模塊位于所述接入網(wǎng)關中。
4
由以上技術方案可以看出，本發(fā)明僅在接入網(wǎng)關向軟交換進行注冊時進行一次共 享密鑰協(xié)商，所獲得的共享密鑰在整個工作期間將一直分別存儲在接入網(wǎng)關和軟交換上， 軟交換每次均用協(xié)商獲得的共享密鑰對分配的會話密鑰進行加密，相應地，接入網(wǎng)關每次 都用協(xié)商獲得的共享密鑰對已加密的會話密鑰解密，因此這種方式不僅容易實施，而且能 大大減少計算量，進一步地能減少系統(tǒng)開銷。并且，該共享密鑰是通過DH交換的密鑰協(xié)商 方式獲得的，因此安全性高、會話密鑰不容易被竊取，進而能保證會話中傳輸?shù)拿襟w流的安 全。所以，本發(fā)明非常適用于當前建立在未集成IPsec的IPv4網(wǎng)絡上的NGN系統(tǒng)中，來確 保語音通話安全。


圖1為現(xiàn)有技術接入網(wǎng)關點對點直接協(xié)商獲取會話密鑰的示意圖； 圖2為現(xiàn)有技術軟交換分配會話密鑰的示意圖； 圖3為本發(fā)明安全協(xié)商會話密鑰的示意圖； 圖4為本發(fā)明安全協(xié)商會話密鑰的裝置的示意圖； 圖5a和圖5b為本發(fā)明接入網(wǎng)關向軟交換請求注冊的流程圖。
具體實施例方式
為使本發(fā)明所屬技術領域的技術人員更清楚地了解本發(fā)明，現(xiàn)結(jié)合附圖詳細說明 本發(fā)明的實現(xiàn)過程。 圖3為本發(fā)明安全協(xié)商會話密鑰的示意圖，如圖3所示，本發(fā)明安全協(xié)商會話密鑰 的方法包括以下步驟 步驟A， AG向SS注冊成功后，二者分別獲取共享密鑰KEY_AG、KEY_SS，并各自在自
身存儲共享密鑰。 步驟B，已注冊的AG每次進行會話前，SS根據(jù)AG的請求為會話分配SK，并且用共
享密鑰KEY-SS對所分配的SK進行加密； 其中，SS側(cè)按公式(1)對SK進行加密KEY-SALT = MD5 (KEY-SS ， SK) (1) 公式(1)中采用的加密算法是MD5，在實際應用中，也可采用其他加密算法，此處 不再--列舉。 步驟C， SS將加密的會話密鑰發(fā)送給AG ; 根據(jù)現(xiàn)有技術，SS可以通過在增加上下文(ADD)消息中的會話描述協(xié)議(SDP)描 述符中增加密碼(crypto)屬性行，將加密的會話密鑰KEY-SALT放在crypto屬性行中發(fā)送 給AG。 步驟D， AG每次收到加密的會話密鑰后，均用共享密鑰KEY-AG對已加密的會話密 鑰解密，獲取SK; 當然，解密應采用與加密同樣的算法，如MD5。 進一步地，還可執(zhí)行步驟E :AG用解密后的會話密鑰對會話中需發(fā)送的媒體流加 密、或?qū)捴薪邮盏降拿襟w流解密。 例如，當AG作為呼叫發(fā)起方時，如圖3所示，AG側(cè)可根據(jù)具體的安全協(xié)議如SRTP用會話密鑰對本次會話需發(fā)送的媒體流進行加密，進而將加密過的媒體流發(fā)送給作為呼叫 接收方的另一 AG(圖中未示)，呼叫接收方AG則用相同的會話密鑰對該加密過的媒體流進 行解密。類似地，該會話密鑰可由SS用與呼叫接收方AG的注冊流程中獲取的共享密鑰加 密后傳送給呼叫接收方AG，不同之處在于該注冊流程為呼叫接收方AG向SS的注冊流程。
為實現(xiàn)上述安全協(xié)商會話密鑰的方法，本發(fā)明相應提供了一種安全協(xié)商會話密鑰 的裝置，如圖4所示，該裝置包括 共享密鑰的產(chǎn)生及存儲模塊，用于在AG向SS注冊成功后產(chǎn)生共享密鑰，并存儲已 產(chǎn)生的共享密鑰；其中，所述共享密鑰的產(chǎn)生及存儲模塊分別位于AG及SS中；
會話密鑰的分配模塊，用于為每次會話分配會話密鑰；其中，所述會話密鑰的分配 模塊位于SS中； 會話密鑰的加密模塊，用于利用所述共享密鑰對所分配的會話密鑰進行加密；其
中，所述會話密鑰的加密模塊位于SS中； 會話密鑰的發(fā)送模塊，用于發(fā)送加密的會話密鑰；其中，所述會話密鑰的發(fā)送模塊 位于SS中； 會話密鑰的接收模塊，用于接收加密的會話密鑰；其中，所述會話密鑰的接收模塊 位于AG中；及 會話密鑰的解密模塊，利用所述共享密鑰對收到的已加密的會話密鑰進行解密； 其中，所述會話密鑰的解密模塊位于AG中。 進一步地，所述裝置還包括媒體流的加密模塊，用于利用解密后的會話密鑰對會 話中需發(fā)送的媒體流進行加密；及媒體流的解密模塊，用于利用解密后的會話密鑰對會話 中接收到的媒體流進行解密； 其中，媒體流的加密模塊及媒體流的解密模塊位于AG中。 由以上分析可知，本發(fā)明一直采用注冊流程中協(xié)商獲得的共享密鑰對每次分配的 會話密鑰進行加密，這種方式容易實施、且安全又簡便。進一步地，經(jīng)過加密后的媒體流在 傳輸過程中即使被截獲，由于難以得到會話密鑰而不能恢復出語音信息，因此，本發(fā)明能有 效地確保語音通話的安全。 下面詳細說明AG與SS通過注冊流程分別獲取共享密鑰KEY-AG、 KEY-SS的過程， 該注冊流程是基于H. 248協(xié)議運行的。 在說明之前，先介紹一下將在注冊過程中使用到的四個靜態(tài)配置的鑒權(quán)認證參 數(shù) 初始共享密鑰Ki，長度通常為128位；
網(wǎng)關設備識別碼MGID，長度通常為128位； 用于DH交換的底數(shù)g和模數(shù)P， g通常在2、3、5、7和9中選值，P為質(zhì)數(shù)，其長度 通常為768位。 這些鑒權(quán)認證參數(shù)在初始配置時就由AG本身和管理該AG的SS分別獲知，并不在 H. 248協(xié)議接口上公開傳送。 如圖5a和圖5b所示，AG向SS請求注冊的流程包括以下步驟 步驟401， AG向SS發(fā)送服務更改(ServiceChange)消息請求注冊，且
ServiceChange消息中攜帶有用于認證的X字段，包括算法ID、隨機數(shù)Randjiig、用于DH交換的密鑰A及接入網(wǎng)關的數(shù)字簽名MGAUTH ;
以下詳述用于認證的X字段的由來 AG首先產(chǎn)生一個通常為64位的隨機數(shù)Rand_mg、以及一個用于DH交換的私人數(shù) 字a，其通常為32位的隨機數(shù)； 接著，按公式(2)計算用于DH交換的密鑰A:
A = gamod (P) (2) 然后，按公式(3)計算AG的數(shù)字簽名MGAUTH :
MGAUTH = MD5 (Ki ， MGID， A， Rand_mg) (3) 這里，計算數(shù)字簽名MGAUTH時采用MD5算法，實際應用中，也可選用其他的加密算 法，在此不再一一列舉； 如此，即得到四個用于認證的X字段 X-EA——算法ID，本發(fā)明采用MD5算法，并賦值為1 ; X-RANDOM——AG生成、用于計算MGAUTH的隨機數(shù)，賦值為Rand_mg ; X-DH——AG根據(jù)g、 a、 P計算出來的用于DH交換的密鑰，賦值為A ; X-AUTH——AG計算出來的數(shù)字簽名，賦值為MGAUTH。 步驟402 404， SS利用收到的ServiceChange消息中的隨機數(shù)Randj11g、密鑰A 及算法ID計算鑒權(quán)值MGKES，并判斷鑒權(quán)值MGKES是否等于AG的數(shù)字簽名MGAUTH，如果二者相 等，則SS向AG發(fā)送正確應答R印ly消息，否則，發(fā)送錯誤R印ly消息，并結(jié)束當前認證流 程； 其中，按公式(4)計算鑒權(quán)值MGKES :
MGKES = MD5 (Ki ， MGID， A， Rand_mg) (4) 如果MGKES = MGAUTH，則說明是合法的AG發(fā)過來的認證信息，故認證通過；否則認證 拒絕。 步驟405， SS向AG發(fā)送正確R印ly消息后，首先利用自身生成的私人數(shù)字b計算 得到用于DH交換的密鑰B，并利用密鑰A和B計算得到共享密鑰KEY-SS，接著再生成隨機 數(shù)Rand_SS，然后利用所述密鑰B、共享密鑰KEY-SS、隨機數(shù)Rand_SS及算法ID計算得到SS 的數(shù)字簽名SSAUTH ; 其中，SS確認是合法的AG發(fā)過來的認證信息后，SS首先產(chǎn)生一個用于DH交換的 私人數(shù)字b，其通常為32位的隨機數(shù)，并按公式(5)計算用于DH交換的密鑰B:
B = gbmod(P) (5) 并按公式(6)計算將與AG共享的鑒權(quán)密鑰KEY-SS :
KEY-SS = Abmod (P) = gabmod (P) (6) 接著SS再生成一個通常為64位的隨機數(shù)RancLss，按公式(7)計算SS的數(shù)字簽 名SSAUTH : SSAUTH = MD5 (KEY-SS， Ki， B， Rand_ss) (7) 步驟406，SS向AG發(fā)送修改(Modify)消息，所述Modify消息中攜帶有由步驟403
得到的用于認證的字段，包括ea、 random、 dhkey和key信息 ea—算法ID，本發(fā)明采用MD5算法，并賦值為1 ; random——SS生成、用于計算SSAUTH的隨機數(shù)，賦值為Rand_ss ;
dhkey——SS根據(jù)g、b、P計算出來的用于DH交換的密鑰，賦值為B ; [OWO] key——SS計算出來的數(shù)字簽名，賦值為SSAUTH。 步驟407 409， AG收到Modify消息后，首先利用自身的私人數(shù)字a及Modify消 息中的密鑰B計算得到共享密鑰KEY-AG，再利用該共享密鑰KEY-AG及收到的隨機數(shù)Rand_ ss、密鑰B與算法ID計算鑒權(quán)值SSKES，并判斷鑒權(quán)值SSKES是否等于SS的數(shù)字簽名SSAUTH， 如果二者相等，則AG向SS發(fā)送正確R印ly消息，否則，發(fā)送錯誤R印ly消息，并結(jié)束當前認 證流程； 其中，按公式(8)計算共享密鑰KEY-AG :
KEY-AG = Bamod (P) = gabmod (P) (8)
按公式(9)計算鑒權(quán)值SSKES :
SSKES = MD5 (KEY-AG， Ki， B， Rand_ss) (9) 如果SSKES = SSAUTH，則說明是合法的SS發(fā)過來的信息，這表示AG與SS相互鑒權(quán)認 證成功，也即表示AG向SS請求注冊成功。之后，SS就可以利用該注冊過程中獲得的共享 密鑰KEY-SS對會話密鑰加密，AG則可利用共享密鑰KEY-AG對被加密的會話密鑰解密。由 于本發(fā)明一直使用注冊過程獲得的共享密鑰對每次呼叫的會話密鑰加密，故用于生成該共 享密鑰的私人數(shù)字a、 b會在整個H. 248協(xié)議會話期間始終保留/使用。如果注冊失敗，則 SS、 AG就均不能使用共享密鑰。 在AG向SS成功注冊后的H. 248協(xié)議接口運行過程中，為防止非法實體冒充AG向 SS發(fā)送消息，或冒充SS向AG發(fā)送消息，SS可定期向AG進行鑒權(quán)，該鑒權(quán)過程如下所述
步驟410， SS向AG發(fā)送Modify消息進行鑒權(quán)，Modify消息中攜帶有用于認證的 字段，包括算法ID、隨機數(shù)d及SS的數(shù)字簽名SSAUTH ;
以下說明這些用于認證的字段的由來 SS首先產(chǎn)生一個通常為128位的隨機數(shù)d，然后使用共享密鑰KEY-SS按公式(10)
計算SS的數(shù)字簽名SSAUTH :SSAUTH = MD5 (KEY-SS ， d) (10) 如此，即得到用于認證的字段，包括ea、 random和key信息
ea—算法ID，本發(fā)明采用MD5算法，并賦值為1 ;
random——SS生成、用于計算SSAUTH的隨機數(shù)，賦值為d ;
key——SS計算出來的數(shù)字簽名，賦值為SSAUTH。 步驟411 413， AG收到Modify消息后，利用共享密鑰KEY-AG及Modify消息中 的隨機數(shù)d與算法ID計算鑒權(quán)值SSKES，并判斷鑒權(quán)值SSKES是否等于SS的數(shù)字簽名SSAUTH， 如果二者相等，說明是合法的SS發(fā)過來的認證信息，則AG利用共享密鑰KEY-AG、隨機數(shù)d 及算法ID計算AG的數(shù)字簽名MGAUTH，之后向SS發(fā)送正確R印ly消息，且所述R印ly消息中 攜帶有用于認證的字段，包括算法ID及AG的數(shù)字簽名MGAUTH ;否則，說明SS是非法的，則 AG向SS發(fā)送錯誤R印ly消息，且所述R印ly消息中不攜帶任何認證字段，以防止非法實體 獲取AG的鑒權(quán)信息，并結(jié)束當前鑒權(quán)流程。
其中，AG按公式(11)計算鑒權(quán)值SSKES :
SSKES = MD5 (KEY-AG， d) (11) 以下說明所述正確R印ly消息中用于認證的字段的由來
AG使用共享密鑰KEY-AG、 MGID和SS在Modify消息中攜帶過來的隨機數(shù)d按公
式(12)計算AG的數(shù)字簽名MGAUTH :MGAUTH = MD5 (KEY-AG， MGID， d) (12) 如此，即得到用于認證的字段，包括ea和key信息 ea—算法ID，本發(fā)明采用MD5算法，并賦值為1 ; key—AG計算出來的數(shù)字簽名，賦值為MGAUTH。 步驟414， SS收到正確R印ly消息后，利用共享密鑰KEY-SS、 MGID、隨機數(shù)d以及
所述正確R印ly消息中攜帶的算法ID，計算出AG的鑒權(quán)值MG^，并判斷鑒權(quán)值MG^是否等
于AG的數(shù)字簽名MGAUTH。如果二者相等，則說明AG是合法的，因此鑒權(quán)成功；否則，說明AG
是非法的，則鑒權(quán)失?。?其中，SS按公式(13)計算MGKES :MGKES = MD5 (KEY-SS， MGID， d) (13) 至此，整個鑒權(quán)過程結(jié)束。如果鑒權(quán)失敗，非法的AG就不能獲得會話密鑰，進而保證會話中傳輸?shù)拿襟w流的安全。 以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
9
權(quán)利要求
一種安全協(xié)商會話密鑰的方法，接入網(wǎng)關向軟交換注冊成功后，二者分別獲取共享密鑰，并各自在自身存儲所述共享密鑰；其特征在于，該方法還包括已注冊的接入網(wǎng)關每次進行會話前，所述軟交換根據(jù)接入網(wǎng)關的請求為會話分配會話密鑰，并且用所述共享密鑰對所分配的會話密鑰進行加密，之后將加密的會話密鑰發(fā)送給所述接入網(wǎng)關；所述接入網(wǎng)關每次收到加密的會話密鑰后，均用所述共享密鑰對已加密的會話密鑰進行解密，獲取會話密鑰。
2. 根據(jù)權(quán)利要求1所述的安全協(xié)商會話密鑰的方法，其特征在于，所述接入網(wǎng)關解密 會話密鑰后，該方法還包括所述接入網(wǎng)關用解密后的會話密鑰對會話中需發(fā)送的媒體流加密、或?qū)捴薪邮盏?的媒體流解密。
3. 根據(jù)權(quán)利要求1或2所述的安全協(xié)商會話密鑰的方法，其特征在于，所述用共享密鑰 對會話密鑰進行加密或解密的算法為MD5。
4. 一種安全協(xié)商會話密鑰的裝置，其特征在于，該裝置包括共享密鑰的產(chǎn)生及存儲模 塊、會話密鑰的分配模塊、會話密鑰的加密模塊、會話密鑰的發(fā)送模塊、會話密鑰的接收模 塊和會話密鑰的解密模塊，其中共享密鑰的產(chǎn)生及存儲模塊，用于在接入網(wǎng)關向軟交換注冊成功后產(chǎn)生共享密鑰，并 存儲所述已產(chǎn)生的共享密鑰；會話密鑰的分配模塊，用于為每次會話分配會話密鑰；會話密鑰的加密模塊，用于利用所述共享密鑰對所分配的會話密鑰進行加密； 會話密鑰的發(fā)送模塊，用于發(fā)送加密的會話密鑰； 會話密鑰的接收模塊，用于接收加密的會話密鑰；會話密鑰的解密模塊，用于利用所述共享密鑰對收到的已加密的會話密鑰進行解密。
5. 根據(jù)權(quán)利要求4所述的安全協(xié)商會話密鑰的裝置，其特征在于，所述共享密鑰的產(chǎn) 生及存儲模塊分別位于所述接入網(wǎng)關及軟交換中。
6. 根據(jù)權(quán)利要求5所述的安全協(xié)商會話密鑰的裝置，其特征在于，所述會話密鑰的分 配模塊及會話密鑰的加密模塊位于所述軟交換中，所述會話密鑰的解密模塊位于所述接入 網(wǎng)關中。
7. 根據(jù)權(quán)利要求6所述的安全協(xié)商會話密鑰的裝置，其特征在于，所述會話密鑰的發(fā) 送模塊位于所述軟交換中，所述會話密鑰的接收模塊位于所述接入網(wǎng)關中。
8. 根據(jù)權(quán)利要求4所述的安全協(xié)商會話密鑰的裝置，其特征在于，所述裝置還包括媒 體流的加密模塊和媒體流的解密模塊，其中媒體流的加密模塊，用于利用解密后的會話密鑰對會話中需發(fā)送的媒體流進行加密； 媒體流的解密模塊，用于利用解密后的會話密鑰對會話中接收到的媒體流進行解密。
9. 根據(jù)權(quán)利要求8所述的安全協(xié)商會話密鑰的裝置，其特征在于，所述媒體流的加密 模塊及媒體流的解密模塊位于所述接入網(wǎng)關中。
全文摘要
本發(fā)明公開了一種安全協(xié)商會話密鑰的方法，包括接入網(wǎng)關向軟交換注冊成功后，二者分別獲取共享密鑰，并各自在自身存儲所述共享密鑰；已注冊的接入網(wǎng)關每次進行會話前，所述軟交換根據(jù)接入網(wǎng)關的請求為會話分配會話密鑰并且用所述共享密鑰對每次分配的會話密鑰進行加密，之后將加密的會話密鑰發(fā)送給所述接入網(wǎng)關；所述接入網(wǎng)關每次收到加密的會話密鑰后，均用所述共享密鑰對已加密的會話密鑰解密，獲取會話密鑰。本發(fā)明還提供一種安全協(xié)商會話密鑰的裝置。本發(fā)明在保證會話密鑰安全的同時，進一步能保證語音通話的安全，且容易實施。
文檔編號H04W12/02GK101790160SQ200910077579
公開日2010年7月28日 申請日期2009年1月23日 優(yōu)先權(quán)日2009年1月23日
發(fā)明者梁麗 申請人:中興通訊股份有限公司