專利名稱：一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通訊中的安全性領(lǐng)域，更具體地說，涉及一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法。
背景技術(shù)：
很多國際標準組織都在致力于制定下一代網(wǎng)絡(luò)(NGN)的標準。作為NGN協(xié)議中的非對稱協(xié)議，與承載無關(guān)的呼叫控制協(xié)議(BICC協(xié)議)是由ISUP協(xié)議演進而來的，由ITU-TSG11小組完成標準化，其提供了支持獨立于承載技術(shù)和信令傳送技術(shù)的窄帶ISDN業(yè)務(wù)，BICC協(xié)議屬于應(yīng)用層控制協(xié)議，可用于建立、修改、終結(jié)呼叫。
而RFC 2833協(xié)議描述了在實時傳輸協(xié)議(Real-time Transport Protocol，RTP)包中傳輸雙音多頻(Dual Tone Multi-Frequency，DTMF)信號以及其它網(wǎng)絡(luò)信令和事件的方法。但是當(dāng)2833內(nèi)容沒有進行加密，很容易在網(wǎng)絡(luò)上被其它未授權(quán)人獲得(比如通過抓包工具)并識別其中的內(nèi)容，例如，某些商業(yè)部門(如銀行)或者個人需要安全并保密傳送這些信息，現(xiàn)有的局間BICC呼叫尚不能實現(xiàn)對2833能力協(xié)商和對2833內(nèi)容加密，即在軟交換體系下局間信令BICC，無法實現(xiàn)對2833內(nèi)容進行加密，故其安全性差。因此需要提供一種新的方法來解決2833內(nèi)容安全性的問題。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題在于，針對現(xiàn)有技術(shù)的上述安全性差的不足，提供一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法。
本發(fā)明為解決上述技術(shù)問題所采用的技術(shù)方案是提供一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法，包括(a)主叫方向被叫方發(fā)送BICC呼叫消息；(b)主叫方與被叫方間傳送協(xié)商2833能力及2833加密能力的信息，當(dāng)主叫方和被叫方都具備2833能力及2833加密能力后，雙方進一步協(xié)商加密和解密方式；；(c)主叫方將2833內(nèi)容以雙方協(xié)商的加密方式加密后發(fā)送給被叫方；(d)被叫方以雙方協(xié)商的解密方式對所述加密后的2833內(nèi)容進行解密。
其中，所述2833內(nèi)容為DTMF、網(wǎng)絡(luò)命令或網(wǎng)絡(luò)事件，所述2833能力是指支持2833協(xié)議的能力，所述2833加密能力是指對2833內(nèi)容進行加密的能力。
其中，在步驟(b)中進一步包括所述主叫方或被叫方在APM消息中攜帶有協(xié)商2833能力及2833加密能力的信息，其中協(xié)商2833加密能力的信息中包括有一隨機數(shù)，所述隨機數(shù)為動態(tài)生成。
其中，在步驟(b)之后進一步包括雙方使用該APM消息中的隨機數(shù)及所協(xié)商的加密方式獲得解密方式，包括利用所述隨機數(shù)獲得一2833密鑰。
其中，當(dāng)發(fā)送方與接收方之間對2833能力和2833加密能力協(xié)商失敗后，則由沒有相應(yīng)能力的一方進行拆線。
其中，在步驟(b)中進一步包括主叫方在IAM消息中攜帶協(xié)商2833能力及2833加密能力的信息，被叫方在ACM消息或ANM消息中攜帶協(xié)商2833能力及2833加密能力的信息，所述協(xié)商2833加密能力的信息中均包含有一隨機數(shù)，該隨機數(shù)為動態(tài)生成。
其中，在步驟(b)后進一步包括主叫方與被叫方均使用所述隨機數(shù)及所協(xié)商的加密方式獲得解密方式，包括利用所述隨機數(shù)獲得一2833密鑰。
其中，進一步包括在發(fā)送方與接收方之間對2833能力和2833加密能力協(xié)商失敗后，則由沒有相應(yīng)能力的一方進行拆線。
其中，所述加密方式為MD5加密方式。
實施本發(fā)明的一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法，具有以下有益效果軟交換體系下局間信令使用BICC協(xié)議，可以實現(xiàn)用戶傳遞后續(xù)撥號信息的功能(比如交換機IVR收號，要求輸入賬號、密碼等)，并且可以保證傳遞的內(nèi)容的安全性。


下面將結(jié)合附圖及實施例對本發(fā)明作進一步說明，附圖中圖1是本發(fā)明第一實施例的流程圖；圖2是本發(fā)明第二實施例的流程圖。
具體實施例方式
首先將本發(fā)明中涉及的專業(yè)術(shù)語說明如下BICC與承載無關(guān)的呼叫控制協(xié)議。
2833RFC2833協(xié)議描述了使用RTP包可靠地傳送DTMF、網(wǎng)絡(luò)信令和事件的方法。
軟交換體系下，需要對RTP使用2833進行DTMF、網(wǎng)絡(luò)信令和事件的傳送。然而現(xiàn)有BICC協(xié)議并沒有描述呼叫中主被叫方雙方如何協(xié)商和使用2833進行DTMF、網(wǎng)絡(luò)信令和事件傳送的方法。本發(fā)明提供了一種在軟交換體系下局間信令BICC實現(xiàn)對2833能力協(xié)商和內(nèi)容加密的方法。
在本發(fā)明中，2833加密協(xié)商原則如下主叫方與被叫方的呼叫消息與正常的BICC呼叫消息相同。其中對于2833加密能力使用某種信令進行協(xié)商。其中，2833能力是指該方(主叫方或初叫方)支持2833協(xié)議的能力；2833加密能力是指可以對2833內(nèi)容進行加密的能力；所述2833內(nèi)容包括但不限于DTMF、網(wǎng)絡(luò)信令、事件。只有雙方都具有2833能力和具有相同2833加密能力，才能使用2833加密方式對DTMF、網(wǎng)絡(luò)信令、事件等2833內(nèi)容進行加密并傳遞出去，對方才可通過解密方式從加密后的2833內(nèi)容中獲得原始的2833內(nèi)容。2833加密能力是以雙方都支持2833能力為前提的。2833加密方式和解密方式是指對2833內(nèi)容加密和解密的具體方式，在該兩個過程中需要采用一個相同的密鑰(可稱為2833密鑰)。故雙方需要預(yù)先協(xié)商2833能力及2833加密能力，當(dāng)雙方具備了2833能力及2833加密能力，則協(xié)商具體的加密和解密方式。
下面通過不同的實施例來描述本發(fā)明的實現(xiàn)過程如圖1所示，示出了本發(fā)明第一實施例，描述了局間BICC采用APM如何協(xié)商使用2833以及對2833內(nèi)容加密的流程。
在本發(fā)明中，2833密鑰需要動態(tài)生成，以保證每次呼叫使用的密鑰都不同，從而增加2833加密內(nèi)容的安全性。主被叫雙方需事先協(xié)商雙方使用的2833加解密方法和2833密鑰的加解密方法。
首先，始發(fā)局(主叫方)向落地局(被叫方)傳送初始地址消息IAM，落地局在接收IAM后向始發(fā)局發(fā)回地址全消息(Address Complete Message，ACM)。則始發(fā)局與落地局雙方就可以利用應(yīng)用傳送機制(APM)來攜帶協(xié)商2833能力及2833加密能力的信息(包括一隨機數(shù)A)。雙方都使用APM消息中送來的隨機數(shù)A和事先約定好的加密方式(比如MD5加密方式)得到2833密鑰。在每次呼叫時所產(chǎn)生的隨機數(shù)A均不同，這樣可保證每次呼叫使用的2833密鑰不同。然后落地局向始發(fā)局發(fā)送應(yīng)答消息(Answer Message，ANM)。
雙方通過APM消息確定對端都支持2833和2833加密能力后，就可以采用2833加密方式來發(fā)送2833內(nèi)容了，其規(guī)則如下發(fā)送方在發(fā)送2833內(nèi)容給接收方的時候，把需要發(fā)送的2833內(nèi)容用2833密鑰加密(加密方式需要雙方事先協(xié)商好，要求加密和解密是可逆過程)，加密后的內(nèi)容用2833的方式發(fā)送給接收方。接收方用同樣的2833密鑰和預(yù)先設(shè)定好的解密方法對收到的2833內(nèi)容解密，得到解密后的2833內(nèi)容。這樣雙方在網(wǎng)絡(luò)上傳遞的是加密后的2833內(nèi)容，保證了內(nèi)容的安全性。
在該過程中，如果雙方局間2833能力和2833加密能力協(xié)商失敗，則由沒有相應(yīng)能力的局發(fā)起拆線動作。
如圖2所示，示出了本發(fā)明的第二實施例，描述了局間BICC如何使用IAM、ACM(或者ANM)來協(xié)商使用2833以及對2833內(nèi)容加密的流程。
在本實施例中，始發(fā)局在IAM消息中攜帶協(xié)商2833能力、2833加密能力的信息(包括隨機數(shù)A)，落地局在ACM消息或者ANM消息中攜帶該協(xié)商2833能力、2833加密能力的信息。雙方使用消息中送來的隨機數(shù)A和事先約定好的加密方式(比如MD5加密方式)得到2833密鑰。每次呼叫產(chǎn)生的隨機數(shù)A均不同，這樣可保證每次呼叫使用的2833密鑰不同。
落地局通過IAM消息獲知對端支持2833和2833加密能力，始發(fā)局通過ACM消息或者ANM消息獲知對端支持2833和2833加密能力。這樣就可以采用2833加密方式來發(fā)送2833內(nèi)容了，其規(guī)則與第一實施例中類似，不再詳述。
當(dāng)局間2833能力和2833加密能力協(xié)商失敗，則由沒有相應(yīng)能力的局發(fā)起拆線。
通過本發(fā)明提供的實施例，在軟交換體系下局間信令使用BICC協(xié)議，可以實現(xiàn)用戶傳遞后續(xù)撥號信息的功能(比如交換機IVR收號，要求輸入賬號、密碼等)，并且可以保證傳遞的內(nèi)容的安全性。
權(quán)利要求
1.一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，包括(a)主叫方向被叫方發(fā)送BICC呼叫消息；(b)主叫方與被叫方間傳送協(xié)商2833能力及2833加密能力的信息，當(dāng)主叫方和被叫方都具備2833能力及2833加密能力后，雙方進一步協(xié)商加密和解密方式；(c)主叫方將2833內(nèi)容以雙方協(xié)商的加密方式加密后發(fā)送給被叫方；(d)被叫方以雙方協(xié)商的解密方式對所述加密后的2833內(nèi)容進行解密。
2.根據(jù)權(quán)利要求1所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，所述2833內(nèi)容為DTMF、網(wǎng)絡(luò)命令或網(wǎng)絡(luò)事件，所述2833能力是指支持2833協(xié)議的能力，所述2833加密能力是指對2833內(nèi)容進行加密的能力。
3.根據(jù)權(quán)利要求2所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，在步驟(b)中進一步包括所述主叫方或被叫方在APM消息中攜帶有協(xié)商2833能力及2833加密能力的信息，其中協(xié)商2833加密能力的信息中包括有一隨機數(shù)，所述隨機數(shù)為動態(tài)生成。
4.根據(jù)權(quán)利要求3所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，在步驟(b)之后進一步包括雙方使用該APM消息中的隨機數(shù)及所協(xié)商的加密方式獲得解密方式，包括利用所述隨機數(shù)獲得一2833密鑰。
5.根據(jù)權(quán)利要求1-4任一項所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，當(dāng)發(fā)送方與接收方之間對2833能力和2833加密能力協(xié)商失敗后，則由沒有相應(yīng)能力的一方進行拆線。
6.根據(jù)權(quán)利要求1所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，在步驟(b)中進一步包括主叫方在IAM消息中攜帶協(xié)商2833能力及2833加密能力的信息，被叫方在ACM消息或ANM消息中攜帶協(xié)商2833能力及2833加密能力的信息，所述協(xié)商2833加密能力的信息中均包含有一隨機數(shù)，該隨機數(shù)為動態(tài)生成。
7.根據(jù)權(quán)利要求6所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，在步驟(b)后進一步包括主叫方與被叫方均使用所述隨機數(shù)及所協(xié)商的加密方式獲得解密方式，包括利用所述隨機數(shù)獲得一2833密鑰。
8.根據(jù)權(quán)利要求1、6或7任一項所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，進一步包括在發(fā)送方與接收方之間對2833能力和2833加密能力協(xié)商失敗后，則由沒有相應(yīng)能力的一方進行拆線。
9.根據(jù)權(quán)利要求1、2、3、4、6、7任一項所述的在軟交換中提高局間傳遞內(nèi)容的安全性的方法，其特征在于，所述加密方式為MD5加密方式。
全文摘要
本發(fā)明涉及一種在軟交換中提高局間傳遞內(nèi)容的安全性的方法，包括主叫方向被叫方發(fā)送BICC呼叫消息；主叫方與被叫方間傳送協(xié)商2833能力及2833加密能力的信息，當(dāng)主叫方與被叫方均具備2833能力及2833加密能力，則進一步協(xié)商加密和解密方式；主叫方將2833內(nèi)容以雙方協(xié)商的加密方式加密后發(fā)送給被叫方；被叫方以雙方協(xié)商的解密方式對所述加密后的2833內(nèi)容進行解密。本發(fā)明在軟交換體系下局間信令使用BICC協(xié)議，可以實現(xiàn)用戶傳遞后續(xù)撥號信息的功能，并且可以保證傳遞內(nèi)容的安全性。
文檔編號H04L29/06GK1889706SQ20051010014
公開日2007年1月3日 申請日期2005年9月28日 優(yōu)先權(quán)日2005年9月28日
發(fā)明者何杰成 申請人:華為技術(shù)有限公司