專利名稱：一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通訊技術(shù)領(lǐng)域，具體涉及一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法。
背景技術(shù)：
H323系統(tǒng)是基于無QOS(服務(wù)質(zhì)量)保證的PBN(分組網(wǎng)絡(luò))實現(xiàn)的。由于PBN本身的技術(shù)原因，使PBN不能夠提供QOS，也不能提供安全的服務(wù)。在H323系統(tǒng)中，如何提供適時安全的服務(wù)是非常重要。
H235協(xié)議V3版以前的版本描述了一些用于H323系統(tǒng)的鑒別和保密技術(shù)，但都是假定在GK(關(guān)守)路由模式情況下的技術(shù)方案。H235協(xié)議V3版的附錄I提出了一種直接路由的安全方案，這種方案主要利用H235V3附錄D和附錄F的基本特性，提供H323系統(tǒng)通信的安全服務(wù)，但是限制在一個GK管理范圍內(nèi)。
在實際的網(wǎng)絡(luò)環(huán)境中，H323系統(tǒng)通常會包括兩個或多個GK，H323系統(tǒng)包括兩個GK的組網(wǎng)邏輯框圖如附圖1所示。
圖1中，虛線表示H225協(xié)議中的RAS消息傳輸，實線表示H225協(xié)議中Q931消息傳輸。EPa和EPb表示兩個不同的H323節(jié)點，GKg和GKh表示兩個不同的GK。GKg是EPa的歸屬GK，GKh是EPb的歸屬GK。
當H323系統(tǒng)包括兩個或多個GK時，通常會通過呼叫前的預約機制，使主叫節(jié)點EPa和GKg之間有共享密鑰Kag，被叫節(jié)點EPb和GKh之間有共享密鑰Kbh，GKg和GKh之間有共享密鑰Kgh，以確保RAS消息的可靠傳輸。
當EPa和Epb之間采用直接路由模式進行呼叫時，為保證Q931消息的可靠傳輸，雙方需要通過RAS消息的可靠傳輸來獲取EPa和Epb之間直接傳輸Q931消息的會話密鑰。
目前，主被叫節(jié)點會話密鑰的分配方法主要有兩種方法一、基于被叫節(jié)點的歸屬關(guān)守產(chǎn)生會話密鑰的密鑰分配方式。
具體實現(xiàn)過程為圖1中，主叫節(jié)點EPa向GKg發(fā)送ARQ(呼叫接入請求)消息，ARQ消息中攜帶了一個ClearToken(明文標記)，這個ClearToken中的tokenOID設(shè)置為″I0″表明EPa支持H235V3附錄I。
GKg在接收到EPa發(fā)來的ARQ消息后，根據(jù)ARQ消息承載的destinationInfo或者destCallSignalAddress字段確定被叫節(jié)點為Epb，由于Epb不屬于其管轄，所以，GKg發(fā)起LRQ(定位請求)消息向GKh查詢EPb的地址。LRQ消息中的endpointIdentifier為主叫節(jié)點EPa的節(jié)點ID(標識符)。
GKg在轉(zhuǎn)化ARQ消息時，如果發(fā)現(xiàn)消息中ClearToken的tokenOID為″I0″，則確定EPa支持H235V3附錄I功能，于是在LRQ消息中也生成一個ClearToken，其中的tokenOID也為″I0″。如果GKg不支持附錄I，就不需要在LRQ消息中創(chuàng)建tokenOID為″I0″的ClearToken，且消息的后續(xù)處理按照不支持附錄I的普通方式進行消息交互。
GKh在接收到LRQ消息后，檢查消息的ClearToken中的tokenOID是否為″I0″，如果tokenOID為″I0″，表明對端支持附錄I。如果GKh自己也支持附錄I，就根據(jù)LRQ提供的被叫節(jié)點信息，查詢被叫節(jié)點EPb是否支持附錄I。
GKh生成EPa和EPb之間的共享密鑰Kab，且產(chǎn)生隨機的challenge，并用GKh和GKg之間的共享密鑰Kgh和challenge以及指定密鑰導出算法導出密鑰EKgh，然后用EKgh加密Kab得到EKab1，并將EKab1和加密參數(shù)配置到一個獨立的ClearToken.h235Key.secureSharedSecret字段的對應(yīng)子字段中。
如果LRQ消息中設(shè)置了endpointIdentifier，GKh需要把這個字段也設(shè)置到ClearToken.h235Key.secureSharedSecret.generalID字段中，并將導出密鑰時用到的算法配置到ClearToken.h235Key.secureSharedSecret.keyDerivationOID字段，將導出密鑰時用到的challenge設(shè)置到ClearToken.challenge字段，同時將ClearToken.generalID設(shè)置為GKg的節(jié)點ID，ClearToken.senderID設(shè)置為GKh的節(jié)點ID，最后把ClearToken的tokenOID設(shè)置為″I3″，在后文中把這個ClearToken記為CTg。
GKh用GKh和EPb之間的共享密鑰Kbh和另外的challenge一起導出密鑰EKbh，并用EKbh加密Kab得到EKab2，并把加密結(jié)果EKab2和加密參數(shù)如加密算法和加密時用到的初始化向量等一起設(shè)置到另外一個ClearToken的h235Key.secureSharedSecret字段中。
如果LRQ消息中設(shè)置了endpointIdentifier，GKh還需要把這個字段也設(shè)置到ClearToken.h235Key.secureSharedSecret.generalID字段中，將導出密鑰時用到的challenge設(shè)置到ClearToken.challenge字段，ClearToken.generalID設(shè)置為EPb的節(jié)點ID，ClearToken.senderID設(shè)置為GKh的節(jié)點ID，最后把這個ClearToken的tokenOID設(shè)置為″I2″，在后文中，把這個ClearToken記為CTb。
在進行了上述設(shè)置后，GKh把LCF消息發(fā)給GKg。
GKg接收到GKh發(fā)來的LCF消息后，取出獨立的ClearToken信息，如果LCF消息中有兩個以上的ClearToken，且其中一個ClearToken的tokenOID為″I3″，即CTg，另外一個ClearToken的tokenOID為″I2″，即CTb，則表明GKh、EPb同意使用附錄I的安全方案。
GKg構(gòu)造ACF(呼叫接入確認)消息，創(chuàng)建一個ClearToken，其中的tokenOID設(shè)置為″I1″，選取一個隨機的challenge設(shè)置到CTa.challenge中，利用CTg提供的參數(shù)如challenge、密鑰導出算法、加密算法、加密用到的初始化向量等和利用challenge和Kgh導出的密鑰Ekgh，解密CT3.h235Key.secureSharedSecret.encryptedSessionKey得到密鑰Kab，GKg根據(jù)Kag和CTa.challenge導出密鑰EKag，用EKag加密Kab并把加密結(jié)果和加密參數(shù)設(shè)置到CTa.h235Key.secureSharedSecret中的對應(yīng)子字段中，把CTb.generalID復制到CTa.h235Key.secureSharedSecret.generalID，把CTb復制到ACF消息中，最后，將ACF消息發(fā)給節(jié)點EPa。
Epa接收到ACF消息后，提取CTa和CTb，并根據(jù)CTa中的信息和利用EPa與GKg的共享密鑰Kag導出的密鑰EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到密鑰Kab。
Epa在獲得會話密鑰Kab后，即可以利用該密鑰創(chuàng)建Setup消息，將ACF消息中的CTb復制到Setup消息中，然后利用共享密鑰Kab設(shè)置H235V3附錄D方案的鑒權(quán)信息，EPa直接向Epb發(fā)送Setup消息。
Epb接收到Setup消息后，提取CTb，根據(jù)CTb.genralID和CTb.sendersID以及CTb.challenge信息利用Kbh導出密鑰EKbh，并解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到密鑰Kab。
EPb根據(jù)Kab對Setup消息進行鑒權(quán)，并進行后續(xù)的Q931消息傳輸。
在該方法中，主叫節(jié)點、被叫節(jié)點之間的會話密鑰Kab在GK的每一跳都要進行加密、解密過程，當GK級數(shù)較多時，會增加消息傳輸時延，而且會話密鑰會在傳輸過程中的每一跳的GK處暴露，安全性能差。
方法二、基于主叫節(jié)點與被叫節(jié)點的歸屬關(guān)守之間進行DH協(xié)商的會話密鑰分配方式。
具體實現(xiàn)過程為圖1中，主叫節(jié)點Epa向GKg發(fā)送ARQ消息時，在ARQ消息中設(shè)置獨立的ClearToken，其中的tokenOID為″I0″，EPa產(chǎn)生用于DH協(xié)商的公開密鑰，并設(shè)置在ClearToken.dhkey中，EPa將ARQ消息傳輸至其所歸屬的GKg。
支持附錄I的GKg接收到ARQ消息后，查詢被叫節(jié)點Epb，由于EPb不在其管理范圍內(nèi)，于是GKg發(fā)起LRQ消息到GKh，LRQ消息中攜帶獨立的ClearToken，其中tokenOID字段為″I0″，且dhkey字段的內(nèi)容與ARQ消息的dhkey字段中的內(nèi)容一樣。
GKg接收到LRQ消息后，根據(jù)LRQ中的ClearToken.tokenOID和被叫的Pb確定主、被叫節(jié)點都支持附錄I時，GKh創(chuàng)建一個ClearToken，設(shè)置tokenOID為″I2″，在后文中，將這個ClearToken記為CTb。
GKh產(chǎn)生DH協(xié)商的公鑰，并與收到的LRQ消息中的DH公鑰一起使用DH算法計算出節(jié)點間直接傳輸Q931消息的會話密鑰Kab。
GKh產(chǎn)生一個隨機的challenge，設(shè)置到CTb.challenge中，然后根據(jù)這個challenge和Kbh導出密鑰EKbh和KSbh。GKh產(chǎn)生一個隨機的初始化向量IV，分別設(shè)置到CTb.h235Key.securitySharedSecret.paramS.IV中。GKh把ENCEKbh，KSbh，IV(Kab)設(shè)置到CTb.h235Key.securitySharedSecret.encryptedSessionKey中。
GKh在LCF中包含GKh產(chǎn)生的DH公鑰和CTb，向GKg發(fā)送LCF消息。
GKg接收到GKh發(fā)來的LCF消息后，獲取CTb和dhkey信息，并將其復制到ACF消息中，將ACF消息發(fā)給節(jié)點EPa。
Epa接收到ACF消息后，根據(jù)消息中的dhkey獲取DH公鑰，并與自己的DH公鑰一起通過DH算法計算出會話密鑰Kab。
Epa在獲得會話密鑰Kab后，即可以利用該密鑰創(chuàng)建Setup消息，將ACF消息中的CTb復制到Setup消息中，然后利用共享密鑰Kab設(shè)置H235V3附錄D方案的鑒權(quán)信息，Epa將Setup消息傳輸至Epb。
Epb接收到Setup消息后，提取CTb，并根據(jù)CTb.genralID和CTb.sendersID以及CTb.challenge信息利用Kbh導出密鑰EKbh，解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到密鑰Kab，EPb根據(jù)Kab對Setup消息進行鑒權(quán)。
該方法需要終端與GK都支持DH協(xié)商過程，其適用范圍受到限制。
綜上所述，現(xiàn)有的主被叫節(jié)點的會話密鑰分配方法存在消息傳輸時延大、安全性能差、適用范圍不廣泛等缺點。

發(fā)明內(nèi)容
本發(fā)明的目的在于，提供一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，通過主被叫節(jié)點的歸屬關(guān)守之間進行DH協(xié)商來分配會話密鑰，實現(xiàn)了提高消息傳輸效率、提高消息傳輸?shù)陌踩阅康摹?br> 為達到上述目的，本發(fā)明提供的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，包括主、被叫節(jié)點的歸屬關(guān)守之間通過DH協(xié)商分配主被叫節(jié)點間的會話密鑰。
所述方法進一步包括a、所述主叫節(jié)點的歸屬關(guān)守GKg接收呼叫接入請求消息，并產(chǎn)生GKg的DH公鑰；b、所述主叫節(jié)點的歸屬關(guān)守將GKg的DH公鑰傳輸至被叫節(jié)點的歸屬關(guān)守；c、所述被叫節(jié)點的歸屬關(guān)守接收GKg的DH公鑰，產(chǎn)生GKh的DH公鑰；d、所述被叫節(jié)點的歸屬關(guān)守將所述GKh的DH公鑰傳輸至所述主叫節(jié)點的歸屬關(guān)守，所述主被叫節(jié)點的歸屬關(guān)守分別根據(jù)GKg的DH公鑰、GKh的DH公鑰通過DH算法確定主被叫節(jié)點間的會話密鑰，并分別傳輸至主被叫節(jié)點。
所述步驟a包括主叫節(jié)點將獨立的明文標記的tokenOID設(shè)置為“I0”，并通過呼叫接入請求消息傳輸至其歸屬的關(guān)守；所述主叫節(jié)點的歸屬關(guān)守在確定呼叫接入請求消息中獨立的明文標記的tokenOID為“I0”時，產(chǎn)生GKh的DH公鑰。
所述步驟b包括所述主叫節(jié)點的歸屬關(guān)守將所述GKg的DH公鑰和需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息承載于定位請求消息中傳輸至被叫節(jié)點的歸屬關(guān)守。
所述步驟b進一步包括所述主叫節(jié)點的歸屬關(guān)守將需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息“I4”承載于定位請求消息的明文標記的tokenOLD中，并將所述GKg的DH公鑰承載于所述明文標記的dhkey中，傳輸至被叫節(jié)點的歸屬關(guān)守。
所述步驟c進一步包括所述被叫節(jié)點的歸屬關(guān)守GKh根據(jù)所述定位請求消息中的需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息產(chǎn)生GKh的DH公鑰。
所述步驟d進一步包括d1、所述被叫節(jié)點的歸屬關(guān)守根據(jù)GKh的DH公鑰、GKg的DH公鑰通過DH算法確定主被叫節(jié)點之間的會話密鑰，并生成CTb；d2、所述被叫節(jié)點的歸屬關(guān)守將所述CTb、GKh的DH公鑰和主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息承載于定位確認消息中傳輸至所述主叫節(jié)點的歸屬關(guān)守；d3、所述主叫節(jié)點的歸屬關(guān)守根據(jù)所述定位確認消息中承載的主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息獲取所述CTb和GKh的DH公鑰；d4、所述主叫節(jié)點的歸屬關(guān)守根據(jù)所述GKh的DH公鑰和GKg的DH公鑰通過DH算法確定主被叫節(jié)點間的會話密鑰，并生成CTa；d5、所述主叫節(jié)點的歸屬關(guān)守通過呼叫接入確認消息將所述CTa、CTb傳輸至所述主被叫節(jié)點。
所述步驟d2進一步包括所述被叫節(jié)點的歸屬關(guān)守將主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息“I5”、GKh的DH公鑰分別承載于定位確認消息的明文標記的tokenOLD、dhkey中，并將所述CTb承載于定位確認消息中，傳輸至所述主叫節(jié)點的歸屬關(guān)守。
所述步驟d5進一步包括所述主叫節(jié)點的歸屬關(guān)守將所述CTa、CTb承載于呼叫接入確認消息中傳輸至所述主叫節(jié)點；所述主叫節(jié)點根據(jù)所述CTa獲取主被叫節(jié)點間的會話密鑰，并根據(jù)所述會話密鑰設(shè)置呼叫建立消息的鑒權(quán)信息，同時，將所述CTb承載于呼叫建立消息中傳輸至被叫節(jié)點；所述被叫節(jié)點根據(jù)所述呼叫建立消息中的CTb獲取所述會話密鑰，并根據(jù)所述會話密鑰對呼叫建立消息進行鑒權(quán)，確定主叫節(jié)點；所述被叫節(jié)點將所述會話密鑰確定為所述主叫節(jié)點與其進行直接路由模式的消息傳輸?shù)臅捗荑€。
所述方法在步驟a之前還包括所述主、被叫節(jié)點將其支持H235 V3附錄I的信息承載于網(wǎng)守發(fā)現(xiàn)請求/注冊請求消息的明文標記中傳輸至其歸屬的關(guān)守。
通過上述技術(shù)方案的描述可知，本發(fā)明只需要主、被叫節(jié)點的歸屬關(guān)守參與主被叫節(jié)點的會話密鑰的分配過程，使會話密鑰只在主被叫節(jié)點的歸屬關(guān)守可見，不但避免了會話密鑰在各中間關(guān)守層層加密、解密而引起的消息傳輸時延大的現(xiàn)象，而且還解決了會話密鑰在各中間關(guān)守暴露、可見而引起的消息傳輸安全性能差的問題；本發(fā)明由于不需要主被叫節(jié)點支持DH協(xié)商，使本發(fā)明的技術(shù)方案適用范圍更加廣泛；從而通過本發(fā)明的技術(shù)方案實現(xiàn)了提高消息傳輸安全性，提高消息傳輸效率的目的。


圖1是包括兩個GK的H323系統(tǒng)的組網(wǎng)邏輯框圖。
具體實施例方式
本發(fā)明的核心是主、被叫節(jié)點的歸屬關(guān)守之間通過DH協(xié)商分配主被叫節(jié)點之間的會話密鑰。
下面基于本發(fā)明的核心思想對本發(fā)明提供的技術(shù)方案做進一步的描述。
本發(fā)明適用于H323系統(tǒng)跨GK管理范圍的直接路由模式，即主/被叫節(jié)點分別注冊在不同的主/被叫GK上，且通訊過程在沒有安全性保證的網(wǎng)絡(luò)如IP網(wǎng)絡(luò)上進行。
實施本發(fā)明技術(shù)方案的前提是GK對其管理節(jié)點的所有RAS消息進行鑒權(quán)，節(jié)點也對其歸屬的GK的RAS消息進行鑒權(quán)，使節(jié)點和其歸屬的GK之間達到相互信任的目的。相互連接的GK之間也進行相互鑒權(quán)，避免GK域間的惡意攻擊，使相互連接的GK之間達到相互信任的目的。通過上述鑒權(quán)過程保證了H.323實體之間RAS信道的安全性。
本發(fā)明中的節(jié)點可以在GK發(fā)現(xiàn)過程中或節(jié)點注冊過程中向其歸屬的GK表明其是否支持H235 V3附錄I，即表明該節(jié)點是否支持本發(fā)明的技術(shù)方案，如節(jié)點在GRQ/RRQ(網(wǎng)守發(fā)現(xiàn)請求/注冊請求)消息中攜帶獨立ClearToken，并把該ClearToken中的tokenOID設(shè)置為“I0”。節(jié)點歸屬的GK接收GRQ/RRQ消息，在識別出ClearToken中的tokenOID為“I0”時，回復GCF/RCF(網(wǎng)守發(fā)現(xiàn)確認/注冊確認)消息，接受該節(jié)點，GCF/RCF消息中攜帶與GRQ/RRQ消息中相同的ClearToken。
在本實施例中，仍然結(jié)合附圖1對本發(fā)明的技術(shù)方案進行描述。
當主叫節(jié)點Epa需要使用直接路由模式呼叫被叫節(jié)點Epb時，主叫節(jié)點Epa需要向其歸屬的關(guān)守GKg發(fā)送ARQ消息。
該ARQ消息中的destinationInfo字段應(yīng)設(shè)置為EPb的標識，且ARQ消息中還應(yīng)該包含一個獨立的ClearToken，該ClearToken的tokenOID可以設(shè)置為“I0”，該ClearToken中的其他字段不需要使用。
在進行了上述設(shè)置后，Epa將ARQ消息發(fā)送至GKg。
主叫節(jié)點的歸屬關(guān)守GKg接收ARQ消息，根據(jù)ARQ消息的destinationInfo字段承載的信息確定被叫節(jié)點為Epb，由于Epb不屬于GKg管理范圍內(nèi)的節(jié)點，因此，GKg需要發(fā)起LRQ消息，以便向GKh查詢EPb的地址信息，同時，由于Epa的歸屬關(guān)守GKg需要采用與被叫節(jié)點EPb的歸屬關(guān)守進行DH協(xié)商過程來分配主被叫節(jié)點的會話密鑰，所以，GKg還需要產(chǎn)生GKg的DH公鑰，并在向GKh發(fā)送LRQ消息時，將GKg的DH公鑰和需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息一起傳輸至GKh。
GKg可以將GKg的DH公鑰設(shè)置在LRQ消息的ClearToken的dhkey中，同時，可以將該ClearToken的tokenOID設(shè)置為“I4”，以表示需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商。在進行上述設(shè)置后，GKg向GKh發(fā)送LRQ消息。
如果GKg與GKh之間存在多級GK，則GKg向其上一級GK發(fā)送LRQ消息，其上一級GK復制該LRQ消息，并依此方法逐級發(fā)送，直到傳輸至被叫節(jié)點的歸屬關(guān)守GKh。
GKh接收LRQ消息，當檢驗到LRQ消息的ClearToken中的tokenOID為“I4”時，確定GKg需要與其進行DH協(xié)商過程以分配主被叫節(jié)點的會話密鑰，GKh開始與GKg進行DH協(xié)商，分配主被叫節(jié)點間的會話密鑰，其具體過程為首先，GKh生成期望的DH公鑰，與從LRQ消息中獲取的GKg的DH公鑰一起作為參數(shù)，使用DH算法計算出主被叫節(jié)點間的會話密鑰Kab。
然后，GKh按照H.235附錄I中描述的方法產(chǎn)生一個ClearToken，并設(shè)置該ClearToken中的tokenOID為“I2”，該ClearToken即為CTb。
最后，GKh生成LCF消息，并使LCF消息包含CTb和一個獨立的ClearToken，將該獨立的ClearToken中的tokenOID設(shè)置為“I5”，將GKh的DH公鑰設(shè)置在該獨立的ClearToken中的dhkey中?！癐5”為主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息，該獨立的ClearToken中的其他字段不使用。
GKh在進行了上述設(shè)置后，將LCF消息發(fā)送至GKg。
如果GKg與GKh之間存在多級GK，則GKh向其上一級GK發(fā)送LCF消息，其上一級GK復制LRQ消息，并依此方法逐級發(fā)送，直到傳輸至主叫節(jié)點的歸屬關(guān)守GKg。
GKg接收LCF消息，當檢驗到LCF消息中獨立ClearToken的tokenOID為“I5”時，GKg從LCF消息的獨立ClearToken的dhkey中獲取Gkh的DH公鑰，并根據(jù)Gkh的DH公鑰、其存儲的GKg的DH公鑰使用DH算法計算出會話密鑰Kab。
GKg按照H.235附錄I中描述的方法產(chǎn)生一個ClearToken，將該ClearToken中的tokenOID設(shè)置為“I1”，該ClearToken即為CTa。
GKg生成ACF消息，并將CTa和LCF消息中的CTb承載于ACF消息中發(fā)送至EPa。
Epa接收ACF消息，獲取ACF消息中承載的CTa，按照H.235附錄I中描述的方法獲得會話密鑰Kab。
EPa創(chuàng)建Setup消息，并將ACF消息中的CTb復制到Setup消息中，使用會話密鑰Kab按照H.235附錄D/附錄F設(shè)置Setup消息的鑒權(quán)信息。
EPa使用直接路由模式向EPb發(fā)送呼叫建立請求消息Setup。
Epb接收Setup消息，從Setup消息中獲取CTb，并按照H.235附錄I中描述的方法得到會話密鑰Kab，同時利用會話密鑰Kab對Setup消息進行鑒權(quán)，根據(jù)鑒權(quán)結(jié)果確定發(fā)送Setup消息的主叫節(jié)點，將會話密鑰Kab確定為Epb與Epa之間進行Q931消息傳輸?shù)臅捗荑€。
主被叫節(jié)點之間的后續(xù)呼叫過程可按照H235附錄D/附錄F進行處理。
雖然通過實施例描繪了本發(fā)明，本領(lǐng)域普通技術(shù)人員知道，本發(fā)明有許多變形和變化而不脫離本發(fā)明的精神，本發(fā)明的申請文件的權(quán)利要求包括這些變形和變化。
權(quán)利要求
1.一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，包括主、被叫節(jié)點的歸屬關(guān)守之間通過DH協(xié)商分配主被叫節(jié)點間的會話密鑰。
2.如權(quán)利要求1所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述方法進一步包括a、所述主叫節(jié)點的歸屬關(guān)守GKg接收呼叫接入請求消息，并產(chǎn)生GKg的DH公鑰；b、所述主叫節(jié)點的歸屬關(guān)守將GKg的DH公鑰傳輸至被叫節(jié)點的歸屬關(guān)守；c、所述被叫節(jié)點的歸屬關(guān)守接收GKg的DH公鑰，產(chǎn)生GKh的DH公鑰；d、所述被叫節(jié)點的歸屬關(guān)守將所述GKh的DH公鑰傳輸至所述主叫節(jié)點的歸屬關(guān)守，所述主被叫節(jié)點的歸屬關(guān)守分別根據(jù)GKg的DH公鑰、GKh的DH公鑰通過DH算法確定主被叫節(jié)點間的會話密鑰，并分別傳輸至主被叫節(jié)點。
3.如權(quán)利要求2所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟a包括主叫節(jié)點將獨立的明文標記的tokenOID設(shè)置為“I0”，并通過呼叫接入請求消息傳輸至其歸屬的關(guān)守；所述主叫節(jié)點的歸屬關(guān)守在確定呼叫接入請求消息中獨立的明文標記的tokenOID為“I0”時，產(chǎn)生GKh的DH公鑰。
4.如權(quán)利要求2所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟b包括所述主叫節(jié)點的歸屬關(guān)守將所述GKg的DH公鑰和需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息承載于定位請求消息中傳輸至被叫節(jié)點的歸屬關(guān)守。
5.如權(quán)利要求4所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟b進一步包括所述主叫節(jié)點的歸屬關(guān)守將需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息“I4”承載于定位請求消息的明文標記的tokenOLD中，并將所述GKg的DH公鑰承載于所述明文標記的dhkey中，傳輸至被叫節(jié)點的歸屬關(guān)守。
6.如權(quán)利要求4所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟c進一步包括所述被叫節(jié)點的歸屬關(guān)守GKh根據(jù)所述定位請求消息中的需要與被叫節(jié)點的歸屬關(guān)守進行DH協(xié)商的信息產(chǎn)生GKh的DH公鑰。
7.如權(quán)利要求2至6中任一權(quán)利要求所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟d進一步包括d1、所述被叫節(jié)點的歸屬關(guān)守根據(jù)GKh的DH公鑰、GKg的DH公鑰通過DH算法確定主被叫節(jié)點之間的會話密鑰，并生成CTb；d2、所述被叫節(jié)點的歸屬關(guān)守將所述CTb、GKh的DH公鑰和主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息承載于定位確認消息中傳輸至所述主叫節(jié)點的歸屬關(guān)守；d3、所述主叫節(jié)點的歸屬關(guān)守根據(jù)所述定位確認消息中承載的主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息獲取所述CTb和GKh的DH公鑰；d4、所述主叫節(jié)點的歸屬關(guān)守根據(jù)所述GKh的DH公鑰和GKg的DH公鑰通過DH算法確定主被叫節(jié)點間的會話密鑰，并生成CTa；d5、所述主叫節(jié)點的歸屬關(guān)守通過呼叫接入確認消息將所述CTa、CTb傳輸至所述主被叫節(jié)點。
8.如權(quán)利要求7所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟d2進一步包括所述被叫節(jié)點的歸屬關(guān)守將主被叫節(jié)點的歸屬關(guān)守間進行DH協(xié)商的標志信息“I5”、GKh的DH公鑰分別承載于定位確認消息的明文標記的tokenOLD、dhkey中，并將所述CTb承載于定位確認消息中，傳輸至所述主叫節(jié)點的歸屬關(guān)守。
9.如權(quán)利要求7所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述步驟d5進一步包括所述主叫節(jié)點的歸屬關(guān)守將所述CTa、CTb承載于呼叫接入確認消息中傳輸至所述主叫節(jié)點；所述主叫節(jié)點根據(jù)所述CTa獲取主被叫節(jié)點間的會話密鑰，并根據(jù)所述會話密鑰設(shè)置呼叫建立消息的鑒權(quán)信息，同時，將所述CTb承載于呼叫建立消息中傳輸至被叫節(jié)點；所述被叫節(jié)點根據(jù)所述呼叫建立消息中的CTb獲取所述會話密鑰，并根據(jù)所述會話密鑰對呼叫建立消息進行鑒權(quán)，確定主叫節(jié)點；所述被叫節(jié)點將所述會話密鑰確定為所述主叫節(jié)點與其進行直接路由模式的消息傳輸?shù)臅捗荑€。
10.如權(quán)利要求2所述的一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其特征在于，所述方法在步驟a之前還包括所述主、被叫節(jié)點將其支持H235 V3附錄I的信息承載于網(wǎng)守發(fā)現(xiàn)請求/注冊請求消息的明文標記中傳輸至其歸屬的關(guān)守。
全文摘要
本發(fā)明提供一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法，其核心為主、被叫節(jié)點的歸屬關(guān)守之間通過DH協(xié)商分配主被叫節(jié)點間的會話密鑰。本發(fā)明只需要主、被叫節(jié)點的歸屬關(guān)守參與會話密鑰的分配過程，使會話密鑰只在主被叫節(jié)點的歸屬關(guān)守可見，減小了消息的傳輸時延，避免了會話密鑰在傳輸過程中的不安全因素，而且使本發(fā)明的技術(shù)方案適用范圍更加廣泛；從而實現(xiàn)了提高消息傳輸安全性，提高消息傳輸效率的目的。
文檔編號H04L9/12GK1815953SQ20051000539
公開日2006年8月9日 申請日期2005年2月4日 優(yōu)先權(quán)日2005年2月4日
發(fā)明者李昆, 王奇 申請人:華為技術(shù)有限公司