一種跨域多網守端到端會話密鑰協商方法

2023-05-05 19:44:46 4

專利名稱：：一種跨域多網守端到端會話密鑰協商方法
技術領域：
：本發明涉及分組網絡通信安全領域，尤其涉及一種跨域多網守直接路由呼叫^t式下端到端通信會話密鑰協商方法。
背景技術：
：在基於分組網絡通信安全領域，密鑰是最為重要的，在網絡上H.323端點之間通過密鑰交換所得到的共享或會話密鑰可以對RAS(註冊、接入與狀態)信令、呼叫信令、R245控制信令等實施身份證實，信令消息完整性檢查以及對媒體數據流進行加/解密等安全措施。目前，多網守路由模式下共享或會話密鑰交換方法，基本採用的是預配置以及電話、E-Mail等帶外方法。直接路由呼叫(以下簡稱DRC)模式是H.323基於分組的多媒體通信系統中呼叫建立的一個重要方法。由於DRC模式下，不能假定二個端點之間的擁有一個預共享秘密或會話密鑰(共享秘密與用戶標識、口令及隨機數等信息一起，通過散列算法可生成會話密鑰)，因此，以上所使用方法要麼難於難布署，要麼不安全而無法在實際中應用。H.235標準定義了一種基於H.323協議集，實現通信安全方法，包括Di伍e-Hellman(迪福-海爾曼，簡稱D-H)公鑰密碼密鑰交換協議，隨機數生成共享秘密並由對稱密碼進行加密保護的密鑰生成與交換方法。但並沒有提出一種跨域多網守的端到端密鑰協商及交換技術，也沒有考慮到充分利用端點與網守的處理能力，及具有不同密鑰協商能力的終端如何動態協商出一種雙方都支持的密碼方法。特別是在H.323多網守環境直接路由呼叫模式下，現存終端設備具備多種建立會話密鑰方法，而通信的二端點之間又不可能事先能預配置的情況下，給互聯互通通信安全帶來困難。
發明內容本發明要解決的技術問題就是提供一種跨域多網守端到端會話密鑰協商方法，克服目前跨域多網守端到端呼叫模式下，密鑰協商方法是基於預先配置而帶來的效率不高，互聯互通性差的限制。為了解決上述技術問題，本發明提供一種跨域多網守端到端會話密鑰協商方法，包括如下步驟(1)在主叫端點使用直接路由呼叫DRC呼叫被叫端點之前，主叫端點根據自身能力和安全策略，選擇是否支持D-H密鑰交換算法，並將該信息放入呼叫接入請求ARQ消息中，發送給其所歸屬的網守，該網守為主叫網守；(2)主叫網守收到ARQ後，向被叫網守發起定位請求LRQ消息，以查詢被叫端點地址；該LRQ消息中，主叫網守根據主叫端點及自身能力及安全策略，選擇是否支持D-H密鑰交換算法，從而為主叫端點選出一種生成會話密鑰的方法；(3)被叫網守收到LRQ後，根據主叫端點、主叫網守的選擇，以及被叫網守是否支持D-H密鑰交換算法和安全策略，最終確定生成會話密鑰的方法，並將該信息及根據該方法生成的共享秘密放入定位確認LCF消息中，用於主叫端點與被叫端點之間的通信，將LCF發送給主叫網守；(4)主叫網守收到LCF消息後，根據已確定的生成會話密鑰的方法，對用於主叫端點的共享秘密進行解密然後再加密轉發或是直接轉發該共享秘密，據此生成ACF消息發送給主叫端點；該ACF消息中還複製了LCF中用於被叫端點的共享秘密；(5)主叫端點收到ACF消息後，根據已確定的密鑰方法，提取與被叫端點所共享的秘密，進而得到會話密鑰。進一步地，生成會話密鑰的方法包括(a)由被叫網守產生共享秘密，主叫網守及主叫端點根據該共享秘密得到會話密鑰；(b)由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰；(c)由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰。進一步地，所述ARQ、LRQ、LCF、ACF均包舍明文標記ClearToken,ClearToken中的tokenOID用於表示主叫端點、主叫網守、被叫網守是否支持D-H密鑰交換算法，或者用於表示該ClearToken包含共享秘密，交給主叫端點或被叫端點使用。進一步地，所述步驟(l)中，若選擇由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則將其D-H公鑰放在ClearToken中的dhkey域中。進一步地，所述步驟(2)中，若主叫端點不支持D-H密鑰交換算法，而主叫網守支持D-H密鑰交換算法，選擇由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰，主叫網守產生D-H公鑰，並將該公鑰存入LRQ中ClearToken中的dhkey域。進一步地，所述步驟(2)中，若由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則將主叫端點發送的ARQ的ClearToken複製到LRQ的ClearToken中。進一步地，所述步驟(3)中，若主叫端點與主叫網守都不支持D-H密鑰交換算法，或者被叫網守不支持D-H密鑰交換算法或安全策略不允許使用D-H密鑰交換算法，則由被叫網守產生共享秘密，將該共享秘密加密後，與加密參數一起放入LCF消息的CTg,h235Key.secureSharedSecret欄位中；同時，被叫網守產生共享秘密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。進一步地，所述步驟(3)中，若主叫端點不支持D-H密鑰交換算法，但主叫網守與被叫網守之間支持D-H密鑰交換算法且GkH的安全策略允許使用D-H密鑰交換算法，則由被叫網守生成D-H公鑰，和LRQ內主叫網守的D-H公鑰一起，使用D-H密鑰交換算法計算出會話的共享秘密，該共享秘密加密後，與加密參數和被叫網守生成D-H公鑰一起放入LCF消息的ClearToken中；同時，計算出的共享秘密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。進一步地，所述步驟(3)中，主叫端點選擇使用D-H密鑰交換算法，且被叫網守的安全策略允許使用D-H密鑰交換算法，則被叫網守生成的D-H公鑰，與從LRQ中獲取的公鑰一起，使用D-H密鑰交換算法計算出共享秘密，該共享秘密加密後，與加密參數和被叫網守生成D-H公鑰一起放入LCF消息的ClearToken中；同時，計算出的共享^!t密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。進一步地，所述步驟(4)中，主叫網守檢查收到LCF，若由被叫網守產生共享秘密，則將該LCF中加密的共享秘密解密，再進行加密，並與加密參數一起保存到ACF的ClearToken的CTA.h235Key.secureSharedSecret欄位中；同時將用於被叫端點ClearToken複製到ACF中。進一步地，所述步驟(4)中，主叫網守檢查收到LCF,若是由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰，從LCF的ClearToken中獲得被叫網守的D-H公鑰，與主叫網守保存的D-H公鑰一同使用D-H密鑰交換算法計算出共享秘密，該共享秘密加密後，與加密參數一起保存到ACF的ClearToken中；同時將用於被叫端點ClearToken複製到ACF中。進一步地，所述步驟(4)中，主叫網守檢查收到LCF，若是由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則直接將LCF中所有的ClearToken複製到ACF的ClearToken中。進一步地，所述步驟(5)中，主叫端點檢查收到的ACF,若由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則從ACF的ClearToken中獲得被叫網守的D-H公鑰，與主叫端點保存的D-H公鑰一同使用D-H密鑰交換算法計算出會話密鑰。進一步地，所述步驟(5)中，主叫端點檢查收到的ACF，若被叫網守產生共享秘密，或由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰，則根據ACF中的ClearToken信息和主叫端點與主叫網守的共享密鑰解密得到會話密鑰。通過上述步驟，通信雙方(端點)可協商出一個可信的動態會話密鑰，利用密碼學將其與呼叫認證捆綁在一起，包括呼叫控制信道中會話密鑰刷新需求。本發明的優點有1.通過動態適配終端與網守的安全能力，可提高密鑰交換的效率，減少延時及網守的處理負荷,同時在實施安全通信過程中，增加了不同安全能力終端互聯互通的靈活性。2.藉助於ARQ/ACF,LRQ/LCF信令執行流程，基於端點與網守是否支持公鑰密碼及對稱密碼算法，動態協商出一種端到端通信中最優的密鑰協商方法，並以此方法完成端點之間的共享秘密或會話密鑰的生成與交換，為後續呼叫信令建立起安全關係，防止信令及數據消息被偽造、完整性及可能的機密性丟失。3.採用的安全技術與現有標準相容，安全體系的布置也比較簡單，並且不需要假定任何附加的安全基礎設施方法。隨著大規模H.323多媒體通信系統的布署與應用，如全球範圍的VoIP網或國家範圍面向公眾的視頻會議/可視電話系統等，在這種多運營商、跨多個管理域分層多網守DRC環境下，使用本發明提供的方法更為方便實用。4.本發明方法也可以應用到其它多網守呼叫才莫式，如部分/路由方式，直接/路由，路由/直接方式及網守路由方式等。附困說明圖1為多網守直接路由呼叫模式場景；圖2為多網守直接路由呼叫模式下共享秘密協商流程圖。具體實施例方式下面結合附圖及具體實施例對本發明進行詳細說明。為說明本發明方法，引用下列符號來表示端點與網守的能力或二者組合，或者用來區分主叫/被叫端點所保存的共享秘密。tableseeoriginaldocumentpage9tableseeoriginaldocumentpage10本發明實施例，採用H.323系統跨網守管理範圍的直接路由模式，並假定主"皮叫端點分別註冊在不同的主W皮叫網守上，通訊過程是在沒有安全性保證的IP網絡上進行。使用的場景如圖1所示。圖1為多網守直接路由模式下的通信場景圖。圖中的網守雲包括一個或多個網守，端點可以連接到相同或不同的網守。直接路由呼叫模型中，網守不參於H,225.0呼叫控制信令，因此不在H.225.0中執行信令隧道。這樣，網守不影響兩個支持信令隧道的端點之間的隧道。直接路由呼叫模型中，H,245控制信道只能直接在端點之間連接。基於H,245控制信道，完成實時數據流傳輸協議(RTP)。在圖l所示的通信過程中，首先，在RAS信道上，端點與網守交換接入消息，然後在呼叫信令信道上交換呼叫信令，然後是H.245控制信道的建立。網守對接入消息的響應決定了是否使用直接路由呼叫模式。雖然端點可以指定優選項，但模式選擇不受端點控制。本發明實施例中，網守對其管理端點的所有RAS消息進行認證與完整性檢查，端點對也對網守的RAS消息進行認證與完整性檢查，從而使端點和所屬網守之間達到相互信任目的，以便能檢查出欺詐的實體，並將被欺詐可能性降到最小。中間網雲中網守與網守之間也進行相互鑑別，避免網守域間的惡意攻擊。在上述條件下，能夠保證H.323端點之間RAS信道的安全性，以此為基礎可實現呼叫信令的安全性。本發明實施例中，方法l表示由被叫網守產生共享秘密，進而可以生成M密鑰；方法2表示由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰；方法3表示由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰。下面結合圖2動態決策流程圖，根據RAS信令與呼叫信令的邏輯順序來說明本發明三種方法是如何依據安全策略動態協商出來，以共同支持端點之間進行密鑰協商。1.ARQ請求階段主叫端點EpA在使用直接路由呼叫模式呼叫被叫端點EpB之前，EpA向歸屬GkG發送ARQ消息，消息中中包含一個獨立的ClearToken，假設為CTA，其中tokenOID根據是否支持D-H而採用不同的設置，這可由用戶根據終端能力與安全策略來設定。如果希望由GK代為生成安全共享秘密，給出一個標識"10",其他欄位不使用；如果EpA希望採用D-H與被叫網守協商共享秘密，則將其D-H公鑰放在的dhkey域中，對tokenOID設定一個相關標識"14",其他欄位不使用。2.LRQ請求階段GkG在收到EpA發來的ARQ後，判斷出不屬於同一管理域，發起LRQ消息向GkH查詢EpB的地址。LRQ消息包含一個ClearToken,其內部各子域的設置規則由EpA能力與GkG所採用具體密鑰協商規程而定，具體設置如下當ARQ中的ClearToken的tokenOID為"10"時，如果主叫網守不支持D-H密鑰交換與協商，這時GkG生成LRQ(圖2數字1)，包含一個ClearToken,其中tokenOID設置為"10"，ClearToken的其他欄位不使用，這些設置說明要採用方法1進行密鑰協商，即需要被叫GK分配共享秘密，假設為Kab。當ARQ中的ClearToken的tokenOID為"10"時，GkG生成LRQ，如果主/被叫網守支持D-H密鑰交換算法，則包含一個ClearToken,其中tokenOID設置一個標識符，如"13"，表明期望與被叫GK使用D-H密鑰交換算法為二邊端點協商出會話的共享秘密。(圖2數字4)GkG產生並設置ClearToken中的dhkey作為D-H公鑰。當ARQ中的ClearToken的tokenOID為"14",應根據安全策略可以選擇使用方法3的過程。GkG生成LRQ(圖2數字9)，其中包舍從ARQ複製過來的ClearToken。3丄CF確認GkH收到LRQ後並識別出EpA與EpB支持這種呼叫模式，根據所含ClearToken的tokenOID執行不同密鑰協商過程來生成基於呼叫的共享秘密(基於該共享秘密，以後通信時生成會話密鑰)Kab與二個獨立的ClearToken。一個用於主叫網守Gkg，假定稱為CTg;另一個用於被叫端點EpB，假定稱為CTb。這個Kab然後通過使用CTg與CTB將分別推送到GkG與EpB。根據tokenOID的不同值，返回不同方法的LCF具體做法如下3.1如果LRQ中的tokenOID為"10",表明採用方法l。LRQ中的"10"表明主叫端點與其歸屬網守都不支持D-H密鑰交換算法，要求#皮叫網守為其生成共享秘密。(圖2數字2)這種情形下，返回的LCF採用方法l,其具體設置過程如下GkH隨機產生Kab。為了加密Kab，首先，GkH產生隨機的challenge,並用和GkG之間的共享密鑰Kgh和challenge以及事先配置的密鑰推導算法導出一個密鑰，如設為EKgh。然後，GkH用EKgh加密Kab得到一共享秘密，如設定為EKabl,並把EKabl和加密參數(加密算法和加密用初始化向量)一起，設置到CTg.h235Key.secureSharedSecret欄位中.，具體細節可參考R235附錄I，並設置CTg的tokenOID為"10"。同時，GkH使用類似的過程產生另一個ClearToken,設置tokenOID為"12"，稱為CTb。最後，GkH生成LCF(圖2數字2)，其中包含CTg和CTb。3.2如果LRQ中的tokenOID為"B"，表明採用方法2或方法1。LRQ中"13"表明端點不支持D-H密鑰交換算法，但網守之間期待支持D-H密鑰交換算法且GkH的安全策略允許使用D-H密鑰交換算法(圖2數字4)。具體過程如下當GkH支持D-H密鑰交換算法且安全能力相匹配，則GkH生成自己D-H公鑰，並和LRQ內GkG的D-H公鑰一起，使用D-H算法計算出會話共享秘密Kab。然後，使用與上面方法1類似過程生成CTb,tokenOID為12"。最後，GkH生成LCF(圖2數字5),其中包含CTb和一個獨立ClearToken(tokenOID為"13")CTg,其中有設置好期望的D-H公鑰。則GkH使用上述方法1過程生成LCF(圖2數字7)。3.3如果LRQ中tokenOID為"14"，表明採用方法3或方法1。LRQ中"14"表示期待GkH支持D-H算法，如果GkH的安全策略允許使用D-H密鑰交換算法，則GkH開始與EpA協商會話密鑰(圖2數字10-11)。具體過程如下首先，GkH生成期望的D-H公鑰，與從LRQ中獲取的公鑰一起，使用D-H算法計算出共享秘密Kab。然後，使用與方法1的過程步驟生成CTb,tokenOID可設為"12"表示。最後，GkH生成LCF，其中包含CTb和一個獨立ClearToken(tokenOID可設為"14")CTg,其中有設置好期望的D-H公鑰。如果GkH不支持D-H算法或安全策略不允許使用D-H密鑰交換算法，GkH可使用方法1過程來生成LCF。4.ACF確認GkG收到LCF後，檢驗消息中的CTg的tokenOID為"13"(圖2數字5)時，採用D-H密鑰交換算法計算出Kab，產生CTa，其內tokenOID設為"II"。具體做法是從獨立ClearToken中獲得GkH的D-H公鑰，與自己保存的D-H公鑰一同使用D-H算法計算出共享秘密Kab;然後使用與下面相同方法生成CTa。最後，GkG生成ACF(圖2數字6),其中包含CTa(tokenOID為"II")和從LCF複製過來的CTb(tokenOID為"12")。如果CTg的tokenOID為"10"(可能對應圖2數字1，5,9三種情形，被叫不支持D-H所返回的標誌)時，首先，GkG可通過CTg中的challenge,IV以及指定的密鑰導出算法導出密鑰Ekgh,或通過其它安全機制來導出；然後，GkG用EKgh解密EKabl得到Kab;最後產生CTa,其內tokenOID設為"II"。CTa的生成做法如下首先，GkG用GkG和EpA之間的共享秘密Kag和challenge以及指定的密鑰導出算法導出密鑰EKag。然後，GkG用EKag加密Kab得到EKabl,並把EKabl和加密參數(加密算法和加密用到的初始化向量)一起，設置到一個獨立的CTA.h235Key.secureSharedSecret欄位中。最後，GkG生成ACF(可能對應圖2數字3,8,13三種情形之一，主叫或被叫不支持D-H所返回的標誌)，其中包含CTa和從LCF複製過來的CTb。如果GkG收到的LCF消息中ClearToken的tokenOID為"14",則GkG生成ACF，其中包含從LCF中複製過來的所有ClearToken(對應圖2數字10-11種情形)。5.SetupEpA收到ACF後，檢驗消息中獨立ClearToken的tokenOID為"14"，則判定為主叫端點與被叫網守，利用D-H算法計算會話密鑰。做法是從ClearToken中獲得被叫方的D-H公鑰，與自己保存的D-H公鑰一同使用D-H算法計算出共享秘密Kab，進而可以計算出會話密鑰。其它情況則直接提取CTa,並根據CTa中信息和其與GkG的共享密鑰Kag導出密鑰EKag,然後使用EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到共享秘密Kab，進而可以計算出會話密鑰。EpA創建Setup消息，把ACF消息中的CTb複製到Setup消息中，然後利用會話密鑰設置H235V3附錄D/附錄F的鑑權信息。EpA直接向EpB發出呼叫建立請求消息Setup。6.後面的呼叫信令設置EpB收到Setup消息後，提取CTb，並根據CTb中信息和其與GkH的共享密鑰Kbh導出密鑰EKbh，然後使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到共享秘密Kab;此時，EpB就可以使用Kab對Setup及後續的呼叫信令消息進行鑑權。通過以上ARQ，LRQ，LCF，ACF信令流的順序執行流程中，依據主叫終，主叫網守與被叫網守是否具備D-H能力的8種狀態，按照不同安全能力、優先級(方法1最低，方法3最高)及其它安全策略來共同實施在網守與網守或終端與網守之間如何動態協商出雙方一致支持的密鑰生成與交換方法，即方法1、方法2或方法3。權利要求1.一種跨域多網守端到端會話密鑰協商方法，包括如下步驟(1)在主叫端點使用直接路由呼叫DRC呼叫被叫端點之前，主叫端點根據自身能力和安全策略，選擇是否支持D-H密鑰交換算法，並將該信息放入呼叫接入請求ARQ消息中，發送給其所歸屬的網守，該網守為主叫網守；(2)主叫網守收到ARQ後，向被叫網守發起定位請求LRQ消息，以查詢被叫端點地址；該LRQ消息中，主叫網守根據主叫端點及自身能力及安全策略，選擇是否支持D-H密鑰交換算法，從而為主叫端點選出一種生成會話密鑰的方法；(3)被叫網守收到LRQ後，根據主叫端點、主叫網守的選擇，以及被叫網守是否支持D-H密鑰交換算法和安全策略，最終確定生成會話密鑰的方法，並將該信息及根據該方法生成的共享秘密放入定位確認LCF消息中，用於主叫端點與被叫端點之間的通信，將LCF發送給主叫網守；(4)主叫網守收到LCF消息後，根據已確定的生成會話密鑰的方法，對用於主叫端點的共享秘密進行解密然後再加密轉發或是直接轉發該共享秘密，據此生成ACF消息發送給主叫端點；該ACF消息中還複製了LCF中用於被叫端點的共享秘密；(5)主叫端點收到ACF消息後，根據已確定的密鑰方法，提取與被叫端點所共享的秘密，進而得到會話密鑰。2.根據權利要求1所述的方法，其特徵在於生成會話密鑰的方法包括(a)由被叫網守產生共享秘密，主叫網守及主叫端點根據該共享秘密得到會話密鑰；(b)由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰；(c)由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰。3.根據權利要求2所述的方法，其特徵在於所述ARQ、LRQ、LCF、ACF均包含明文標記ClearToken,ClearToken中的tokenOID用於表示主叫端點、主叫網守、被叫網守是否支持D-H密鑰交換算法，或者用於表示該ClearToken包含共享秘密，交給主叫端點或被叫端點使用。4.根據權利要求3所述的方法，其特徵在於所述步驟(l)中，若選擇由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則將其D-H公鑰放在ClearToken中的dhkey域中。5.根據權利要求3所述的方法，其特徵在於所述步驟(2)中，若主叫端點不支持D-H密鑰交換算法，而主叫網守支持D-H密鑰交換算法，選擇由主叫網守和4皮叫網守4吏用D-H密鑰交換算法生成會話密鑰，主叫網守產生D-H公鑰，並將該公鑰存入LRQ中ClearToken中的dhkey域。6.根據權利要求4所述的方法，其特徵在於所述步驟(2)中，若由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則將主叫端點發送的ARQ的ClearToken複製到LRQ的ClearToken中。7.根據權利要求3所述的方法，其特徵在於所述步驟(3)中，若主叫端點與主叫網守都不支持D-H密鑰交換算法，或者被叫網守不支持D-H密鑰交換算法或安全策略不允許使用D-H密鑰交換算法，則由被叫網守產生共享秘密，將該共享秘密加密後，與加密參數一起放入LCF消息的CTg.h235Key.secureSharedSecret欄位中；同時，被叫網守產生共享秘密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。8.根據權利要求5所述的方法，其特徵在於所述步驟(3)中，若主叫端點不支持D-H密鑰交換算法，但主叫網守與被叫網守之間支持D-H密鑰交換算法且GkH的安全策略允許使用D-H密鑰交換算法，則由被叫網守生成D-H公鑰，和LRQ內主叫網守的D-H公鑰一起，使用D-H密鑰交換算法計算出會話的共享秘密，該共享秘密加密後，與加密參數和被叫網守生成D-H公鑰一起放入LCF消息的ClearToken中；同時，計算出的共享秘密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。9.根據權利要求6所述的方法，其特徵在於所述步驟(3)中，主叫端點選擇使用D-H密鑰交換算法，且被叫網守的安全策略允許使用D-H密鑰交換算法，則被叫網守生成的D-H公鑰，與從LRQ中獲取的公鑰一起，使用D-H密鑰交換算法計算出共享秘密，該共享秘密加密後，與加密參數和被叫網守生成D-H公鑰一起放入LCF消息的ClearToken中；同時，計算出的共享秘密加密後，與加密參數一起放入LCF消息的另一個用於被叫端點ClearToken中。10.根據權利要求7所述的方法，其特徵在於所述步驟(4)中，主叫網守檢查收到LCF,若由被叫網守產生共享秘密，則將該LCF中加密的共享秘密解密，再進行加密，並與加密參數一起保存到ACF的ClearToken的CTA,h235Key.secureSharedSecret欄位中；同時將用於被叫端點ClearToken複製到ACF中。11.根據權利要求8所述的方法，其特徵在於所述步驟(4)中，主叫網守檢查收到LCF，若是由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰，從LCF的ClearToken中獲得被叫網守的D-H公鑰，與主叫網守保存的D-H公鑰一同使用D-H密鑰交換算法計算出共享秘密，該共享秘密加密後，與加密參數一起保存到ACF的ClearToken中；同時將用於被叫端點ClearToken複製到ACF中。12.根據權利要求9所述的方法，其特徵在於所述步驟(4)中，主叫網守檢查收到LCF,若是由主叫端點與被叫網守使用D-H密鑰交換算法生成務活密鑰，則直接將LCF中所有的ClearToken複製到ACF的ClearToken中。13.根據權利要求12所述的方法，其特徵在於所述步驟(5)中，主叫端點檢查收到的ACF，若由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰，則從ACF的ClearToken中獲得被叫網守的D-H公鑰，與主叫端點保存的D-H公鑰一同使用D-H密鑰交換算法計算出會話密鑰。14.根據權利要求3所述的方法，其特徵在於所述步驟(5)中，主叫端點檢查收到的ACF，若被叫網守產生共享秘密，或由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰，則根據ACF中的ClearToken信息和主叫端點與主叫網守的共享密鑰解密得到會話密鑰。全文摘要本發明公開了一種跨域多網守端到端會話密鑰協商方法，該方法通過ARQ/ACF，LRQ/LCF信令執行流程，基於端點與網守是否支持D-H密鑰交換算法及安全策略，動態協商出一種端到端通信中最優的密鑰協商方法，包括由被叫網守產生共享秘密，主叫網守及主叫端點根據該共享秘密得到會話密鑰；由主叫網守和被叫網守使用D-H密鑰交換算法生成會話密鑰；由主叫端點與被叫網守使用D-H密鑰交換算法生成會話密鑰。並據此完成端點之間的共享秘密或會話密鑰的生成與交換，克服了目前跨域多網守端到端呼叫模式下，密鑰協商方法是基於預先配置而帶來的效率不高，互聯互通性差的限制。文檔編號H04L9/08GK101207478SQ20061016784公開日2008年6月25日申請日期2006年12月18日優先權日2006年12月18日發明者忱盧,張則寶,王雲峰,胡焰龍,陳劍勇申請人:中興通訊股份有限公司