專利名稱：一種數(shù)據(jù)傳輸方法、系統(tǒng)和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，特別涉及一種數(shù)據(jù)傳輸方法、系統(tǒng)和裝置。
背景技術(shù)：
實時傳輸協(xié)議(RTP :Real-time Transport Protocol)是通信技術(shù)中數(shù)據(jù)比如音頻數(shù)據(jù)、視頻數(shù)據(jù)傳輸?shù)闹匾獏f(xié)議，其具體傳輸過程為以RTP封裝的形式封裝待傳輸數(shù)據(jù)，并傳輸至一個以上目的地。這解決了數(shù)據(jù)在IP網(wǎng)絡(luò)上的傳輸，但是，這種傳輸過程中并沒有采用任何安全手段，而IP網(wǎng)絡(luò)為開放的網(wǎng)絡(luò)，基于此，通過IP網(wǎng)絡(luò)傳輸就會影響數(shù)據(jù)安全問題，比如傳輸?shù)臄?shù)據(jù)被竊聽等。為了解決上述數(shù)據(jù)安全問題，現(xiàn)有技術(shù)提供了兩種方案，下面分別對這兩種方案進行描述。第一種方案，該方案主要是使用VPN隧道，并結(jié)合IPSEC方式對待傳輸數(shù)據(jù)進行加密傳輸，具體為分別設(shè)置與發(fā)送端連接的路由設(shè)備和與接收端連接的路由設(shè)備，在該兩個路由設(shè)備之間建立VPN隧道，發(fā)送端對待發(fā)送數(shù)據(jù)進行IPSEC加密，之后，發(fā)送給與自身連接的路由設(shè)備，由該路由設(shè)備發(fā)送給連接了接收端的路由設(shè)備，該連接了接收端的路由設(shè)備接收到數(shù)據(jù)后，對數(shù)據(jù)進行解密，之后發(fā)送給接收端。該第一種方案雖然能夠解決數(shù)據(jù)安全問題，但是，需要中間設(shè)備即連接了發(fā)送端的路由設(shè)備和連接了接收端的路由設(shè)備的支持，并且，在第一種方案中，通過VPN隧道傳輸數(shù)據(jù)時，需要加載隧道頭等頭標信息，而數(shù)據(jù)傳輸過程中的最大傳輸單元(MTU)是固定的， 如此，就需要相應(yīng)地減少傳輸數(shù)據(jù)的長度。為了解決上述第一種方案產(chǎn)生的技術(shù)問題，現(xiàn)有技術(shù)又提出了第二種方案。該第二種方案主要是利用IETF在RFC3711中基于RTP提出的安全實時傳輸協(xié)議(SRTP Security Real-time Transport Protocol)，該 SRTP 是 RTP 的一個擴展協(xié)議,其在 RTP 基礎(chǔ)上加強了保密性，并定義了消息認證和完整性保護。但是，SRTP是基于session級的加密，即在啟動加密時，就要求對待傳輸數(shù)據(jù)進行全部加密。而目前，由于視頻數(shù)據(jù)已經(jīng)達到高清級別，數(shù)據(jù)量非常大，這就要求編碼端具有極高的加密運算性能，以及解碼端具有極高的解密運算性能。然而，目前尚未有一種降低編碼端加密運算性能，以及解碼端解密運算性能的數(shù)據(jù)傳輸方法。

發(fā)明內(nèi)容
本發(fā)明提供了一種數(shù)據(jù)傳輸?shù)姆椒?、系統(tǒng)和裝置，以便降低編碼端加密運算性能， 以及解碼端解密運算性能。本發(fā)明提供的技術(shù)方案包括一種數(shù)據(jù)傳輸?shù)姆椒?，包括A，發(fā)送端判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)，如果是，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密并發(fā)送；如果否，直接發(fā)送所述待傳輸數(shù)據(jù)；
B，接收端接收到數(shù)據(jù)后，如果接收的數(shù)據(jù)中不存在被加密的數(shù)據(jù)，則直接處理接收的數(shù)據(jù)；如果接收的數(shù)據(jù)中存在被加密的數(shù)據(jù)，則利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。一種發(fā)送端設(shè)備，包括判斷單元、加密單元和發(fā)送單元，其中，所述判斷單元用于判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)；所述加密單元用于在所述判斷單元的判斷結(jié)果為是時，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密；所述發(fā)送單元用于發(fā)送所述加密單元加密的數(shù)據(jù)；或者在所述判斷單元的判斷結(jié)果為否時，發(fā)送所述待傳輸數(shù)據(jù)。一種接收端設(shè)備，包括接收單元，用于接收發(fā)送端設(shè)備發(fā)送的數(shù)據(jù)；處理單元，用于在所述接收單元接收的數(shù)據(jù)為未被加密的數(shù)據(jù)時，直接處理接收的數(shù)據(jù)；在接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)時，利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。由以上技術(shù)方案可以看出，本發(fā)明中，并非像背景技術(shù)描述的第二種方案那樣，只能針對待傳輸數(shù)據(jù)進行全部加密，而是動態(tài)有選擇性地對待傳輸數(shù)據(jù)加密，比如對待傳輸數(shù)據(jù)中的部分數(shù)據(jù)加密，這顯然降低了編碼端加密運算性能，以及解碼端解密運算性能的要求。


圖1為本發(fā)明實施例提供的基本流程圖；圖2為本發(fā)明實施例提供的第一詳細流程圖；圖3a為本發(fā)明實施例應(yīng)用的RTP報文頭的格式示意圖；圖北為本發(fā)明實施例應(yīng)用的RTP擴展頭的格式示意圖；圖3c為本發(fā)明實施例一中步驟201的實現(xiàn)流程圖；圖3d為本發(fā)明實施例應(yīng)用的APP報文的格式示意圖；圖4為本發(fā)明實施例提供的第二詳細流程圖；圖5為本發(fā)明實施例二中步驟401的實現(xiàn)流程圖；圖6為本發(fā)明實施例提供的發(fā)送端設(shè)備結(jié)構(gòu)圖；圖7為本發(fā)明實施例提供的接收端設(shè)備結(jié)構(gòu)圖。
具體實施例方式為了使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖和具體實施例對本發(fā)明進行詳細描述。參見圖1，圖1為本發(fā)明實施例提供的基本流程圖。如圖1所示，該流程可包括以下步驟步驟101，發(fā)送端判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)，如果是，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密并發(fā)送；如果否，直接發(fā)送所述待傳輸數(shù)據(jù)。也就是說，如果待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)，則不對待傳輸數(shù)據(jù)進行加密，直接發(fā)送即可。其中，待傳輸數(shù)據(jù)可為音頻數(shù)據(jù)，也可為視頻數(shù)據(jù)，這里不進行限定。至于加密密鑰的具體確定操作分別在圖2中的步驟201或者圖4中的步驟401中進行描述，這里不再詳述。步驟102，接收端接收到數(shù)據(jù)后，如果接收的數(shù)據(jù)為未被加密的數(shù)據(jù)，則直接處理接收的數(shù)據(jù)；如果接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)，則利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。其中，上述處理數(shù)據(jù)具體為將數(shù)據(jù)放入接收端的buffer中，并重新組裝該數(shù)據(jù)。 需要說明的是，如果上述接收到的數(shù)據(jù)中存在已被加密的數(shù)據(jù)和未被加密的數(shù)據(jù)，則執(zhí)行到步驟102時，可先將未被加密的數(shù)據(jù)放入buffer中，并對已被加密的數(shù)據(jù)進行解密，之后，將解密后的數(shù)據(jù)放入buffer中。至于解密密鑰的具體確定操作分別在圖2中的步驟201或者圖4中的步驟401中進行描述，這里不再詳述。至此，完成了對本發(fā)明實施例提供的方法的簡單描述。需要說明的是，上述數(shù)據(jù)比如步驟101中被加密的數(shù)據(jù)或者未被加密的數(shù)據(jù)即待傳輸數(shù)據(jù)可通過RTP報文發(fā)送，其中，該RTP報文包含RTP報頭字段和有效載荷O^yload) 字段，其中，有效載荷字段用于攜帶數(shù)據(jù)，RTP報頭字段具體內(nèi)容參見圖3a所示，包括以下各個字段版本號(V)字段、填充位⑵字段、擴展位⑴字段、CSRC計數(shù)器(CC)字段、標記位(M)字段、載荷類型(PT)字段、序列號(sequence number)字段、時間戳(time stamp) 字段、同步源(SSRC Synchronization Source)標識符(identifier)字段、貢獻源(CSRC Contributing Source)標識符(identifier)字段。其中，版本號(V)字段、填充位⑵字段、CSRC計數(shù)器(CC)字段、標記位(M)字段、 載荷類型(PT)字段、序列號(sequence number)字段、時間戳(time stamp)字段、同步源 (SSRC -Synchronization Source)標識符(identifier)字段、貢獻源(CSRC Contributing Source)標識符(identifier)字段的具體定義與現(xiàn)有技術(shù)類似，這里不再贅述。而X字段， 本實施例中，如果該X字段置為第一標識，則表示該RTP報文的有效載荷字段中攜帶了加密數(shù)據(jù)，其中，關(guān)于該加密數(shù)據(jù)的描述可通過RTP擴展頭表示。這里，RTP擴展頭的具體內(nèi)容可參見圖北所示，其包含配置文檔定義(defined by profile)字段，大小為12比特，該字段在本實施例中保留；擴展頭說明(header extension)字段，大小為4比特，用于對Payload 字段攜帶的數(shù)據(jù)的加密情況的說明；長度(length)字段，大小為2個字節(jié)，即8比特，用于表示header extension字段的長度。也就是說，本實施例通使RTP報頭字段中X字段取值為第一標識來表示加密傳輸，基于此，如果當前傳輸?shù)臄?shù)據(jù)中存在被加密的數(shù)據(jù)，則發(fā)送端就需要使RTP報頭的X字段置為第一標識，用于表示攜帶了加密的數(shù)據(jù)，否則，將RTP報頭的X字段置為其他標識。還需要說明的是，上述圖1所示的步驟101中，發(fā)送端可以通過單播方式發(fā)送數(shù)據(jù)，也可通過組播方式發(fā)送數(shù)據(jù)，下面結(jié)合具體實施例分別進行描述。實施例一參見圖2，圖2為本發(fā)明實施例提供的第一詳細流程圖。該流程是針對發(fā)送端通過單播方式發(fā)送數(shù)據(jù)的情況進行的描述，如圖2所示，該流程可包括以下步驟步驟201，發(fā)送端確定自身要使用的加密密鑰，接收端確定自身要使用的解密密鑰。至于步驟201中的確定操作，其可通過發(fā)送端和接收端協(xié)商實現(xiàn)，也可通過獨立于發(fā)送端和接收端的第三方設(shè)備比如第三方服務(wù)器通知實現(xiàn)，下面以發(fā)送端和接收端協(xié)商為例具體描述步驟201。參見圖3c，圖3c為本發(fā)明實施例一中步驟201的實現(xiàn)流程圖。在該實現(xiàn)流程中， 發(fā)送端和接收端采用實時傳輸控制協(xié)議(RTCP :Real-time Transport ControlProtocol) 進行協(xié)商，在其他協(xié)議比如SIP協(xié)議或者H323協(xié)議等的實現(xiàn)同理，基于此，如圖3c所示，該流程可包括步驟301c，發(fā)送端和接收端各自生成隨機密鑰。步驟302c，發(fā)送端和接收端交互各自生成的隨機密鑰。這里，步驟302c可使用RTCP對應(yīng)的其中一個報文進行交互。本實施例采用RTCP 對應(yīng)的應(yīng)用指明功能(APP)報文實現(xiàn)上述交互操作，該APP報文的格式可以如圖3d所示。其中，子類型(subtype)字段、名字(Name)字段和應(yīng)用數(shù)據(jù)(Application-d印endent data)字段可供用戶自主定義，其他字段都嚴格遵守RTCP?；诖耍@里可分別對subtype 字段、Name字段和Application-cbpendent data字段作如下定義subtype字段，用于表示APP報文是否攜帶隨機密鑰，具體地，如果subtype字段取值為1，則表示該APP報文攜帶了隨機密鑰；否則，表示沒有攜帶隨機密鑰。Name字段，用于攜帶APP報文的加密信息，這里取值為加密(ENCRYPT)，表示該APP 報文為加密報文；Application-dependent data 字段，用于攜帶隨機密鑰。如此，發(fā)送端和接收端通過解析接收的APP報文所攜帶的subtype字段、Name字段和Application-d印endent data字段即可完成上述交互操作。步驟303c，發(fā)送端根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端生成的隨機密鑰生成自身要使用的加密密鑰，接收端根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端生成的隨機密鑰生成自身要使用的解密密鑰。本實施例中，發(fā)送端也可根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端 (即接收端)生成的隨機密鑰生成自身要使用的加密密鑰和接收端要使用的加密密鑰，同樣，接收端也可根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端(即發(fā)送端)生成的隨機密鑰生成自身要使用的解密密鑰和發(fā)送端要使用的加密密鑰，本實施例并不限定，具體是僅生成自身要使用的密鑰還是生成自身要使用的密鑰和對端要使用的密鑰，完全取決于采用的密鑰生成算法。步驟202，發(fā)送端判斷當前待傳輸數(shù)據(jù)是否為被默認要求加密的數(shù)據(jù)，如果否，則執(zhí)行步驟203 ；如果是，執(zhí)行步驟204。這里，步驟202中被默認要求加密的數(shù)據(jù)與待傳輸數(shù)據(jù)的編碼方式有關(guān)，比如，如果該待傳輸數(shù)據(jù)利用基本的編碼方式進行編碼，則被默認要求加密的數(shù)據(jù)為幀內(nèi)編碼幀(I 幀)數(shù)據(jù)，其中，I幀是一種自帶全部信息的獨立幀，其相比于幀間預(yù)測編碼幀(P幀)和雙向預(yù)測編碼幀(B幀)，其為完整圖像數(shù)據(jù)，無需參考其它圖像便可獨立進行解碼，因此，其一般被默認為要求加密，而對P幀數(shù)據(jù)或者B幀數(shù)據(jù)可根據(jù)發(fā)送端當前的加密運算性能或者接收端的請求有選擇性地動態(tài)加密，具體見步驟203中的描述。如果該待傳輸數(shù)據(jù)利用分層編碼方式進行編碼，則該被默認要求加密的數(shù)據(jù)為基本層(BASIC)數(shù)據(jù)，其中，基本層數(shù)據(jù)類似于上述的I幀數(shù)據(jù)，其相比于擴展層(EXTEND)數(shù)據(jù)是完整的數(shù)據(jù)，一般被默認為要求加密，而針對擴展層數(shù)據(jù)，則按照類似上述P幀或者B幀數(shù)據(jù)的方式進行有選擇性地動態(tài)加密。步驟203，發(fā)送端根據(jù)自身的加密運算性能或者接收端請求的需要加密的數(shù)據(jù)信息，判斷是否需要對該待傳輸數(shù)據(jù)進行加密，如果是，執(zhí)行步驟204 ；否則，執(zhí)行步驟207。本實施例可以在上述步驟202判斷出待傳輸數(shù)據(jù)不為被默認要求加密的數(shù)據(jù)時， 不執(zhí)行該步驟203，而是直接執(zhí)行步驟207。本實施例之所以執(zhí)行步驟203，主要是基于實際需求比如發(fā)送端當前的加密運算性能或者接收端請求加密的數(shù)據(jù)信息的考慮，具體為盡管待傳輸數(shù)據(jù)不為被默認要求加密的數(shù)據(jù)，但是，如果發(fā)送端當前的加密運算性能還能滿足對待傳輸數(shù)據(jù)中的部分或者全部數(shù)據(jù)進行加密，或者，接收端請求對該待傳輸數(shù)據(jù)中的部分或者全部數(shù)據(jù)進行加密，則還可以對該待傳輸數(shù)據(jù)中的部分或者全部數(shù)據(jù)進行加密， 即有選擇性地動態(tài)實現(xiàn)了加密，否則，執(zhí)行步驟207。這進一步提高了本發(fā)明實施例的應(yīng)用。步驟204，發(fā)送端判斷是否需要對該待傳輸數(shù)據(jù)進行全部加密，如果是，則執(zhí)行步驟205 ；否則，執(zhí)行步驟206 ；本步驟204是在上述步驟202的判斷結(jié)果為是時，或者在上述步驟203的判斷結(jié)果為是時執(zhí)行的。作為本發(fā)明實施例的一種擴展，在上述步驟202的判斷結(jié)果為是時，或者在上述步驟203的判斷結(jié)果為是時也可不執(zhí)行該步驟204，而是直接執(zhí)行步驟205。這里之所以增加步驟204中的判斷，主要是考慮實際需求比如發(fā)送端當前的加密運算性能或者接收端的請求，具體為如果本步驟204是在步驟202的判斷結(jié)果為是時執(zhí)行的，則，盡管發(fā)送端在上述步驟202中判斷出待傳輸數(shù)據(jù)為被默認要求加密的數(shù)據(jù)，但是如果發(fā)送端當前的加密運算性能滿足不了對該被默認要求加密的數(shù)據(jù)即待傳輸數(shù)據(jù)進行全部加密，或者接收端請求不需要對該被默認要求加密的數(shù)據(jù)即待傳輸數(shù)據(jù)進行全部加密，基于此，就沒必要對被默認要求加密的數(shù)據(jù)即待傳輸數(shù)據(jù)進行全部加密，即可執(zhí)行下述步驟206 ；否則，可對該被默認要求加密的數(shù)據(jù)即待傳輸數(shù)據(jù)進行全部加密，即執(zhí)行下述步驟205 ；而如果本步驟204是在步驟203的判斷結(jié)果為是時執(zhí)行的，則盡管發(fā)送端在步驟203中根據(jù)自身的加密運算性能或者接收端請求的需要加密的數(shù)據(jù)信息判斷出對待傳輸數(shù)據(jù)進行加密，以發(fā)送端在步驟203中根據(jù)接收端請求的需要加密的數(shù)據(jù)信息判斷出對待傳輸數(shù)據(jù)進行加密為例，其他情況實現(xiàn)原理類似，但是，發(fā)送端還要判斷當前的加密運算性能是否能夠滿足對該待傳輸數(shù)據(jù)進行全部加密，如果不能，則就沒必要對該待傳輸數(shù)據(jù)進行全部加密，即可執(zhí)行下述步驟206 ；否則，可對該待傳輸數(shù)據(jù)進行全部加密，即執(zhí)行下述步驟205。這進一步提高了本發(fā)明實施例的應(yīng)用。步驟205，發(fā)送端利用步驟201中確定的加密密鑰對該待傳輸數(shù)據(jù)進行全部加密， 將該加密的數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，并設(shè)置該RTP報文中X字段取值為第一標識，之后發(fā)送完成設(shè)置的RTP報文至接收端。步驟206，發(fā)送端從該待傳輸數(shù)據(jù)中選擇出需要加密的數(shù)據(jù)，利用步驟201中確定的加密密鑰對該需要加密的數(shù)據(jù)進行加密，將該加密的數(shù)據(jù)和待傳輸數(shù)據(jù)中不需要加密的數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，并設(shè)置該RTP報文中X字段取值為第一標識，之后發(fā)送完成設(shè)置的RTP報文至接收端。這里，步驟204如果是根據(jù)當前加密運算性能判斷出不對該待傳輸數(shù)據(jù)進行全部加密，則執(zhí)行到本步驟206時，可以從該待傳輸數(shù)據(jù)中隨機選擇出當前加密運算性能所能滿足的部分數(shù)據(jù)進行加密，如果是根據(jù)接收端的請求判斷出不對該待傳輸數(shù)據(jù)進行全部加密，則執(zhí)行到本步驟206時，可以從該待傳輸數(shù)據(jù)中選擇出接收端所請求的數(shù)據(jù)進行加密。步驟207，發(fā)送端直接將該待傳輸數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，之后發(fā)送完成設(shè)置的RTP報文至接收端。至此，通過以上步驟即可實現(xiàn)了發(fā)送端發(fā)送數(shù)據(jù)的流程。當接收端接收到發(fā)送端通過步驟205、步驟206或者步驟207發(fā)送的RTP報文后， 還可執(zhí)行下述步驟。步驟208，接收端判斷接收的RTP報文的X字段是否置為第一標識，如果是，則執(zhí)行步驟209，否則，直接處理RTP報文攜帶的數(shù)據(jù)。這里，以第一標識為1為例，其他情況實現(xiàn)原理類似，則步驟208中的判斷為接收端判斷接收的RTP報文的X字段是否置為1，如果是，則執(zhí)行步驟209，否則，直接處理RTP 報文攜帶的數(shù)據(jù)。其中，在判斷結(jié)果為是時，則確定該RTP報文中攜帶了加密的數(shù)據(jù)；否則， 確定RTP報文未攜帶加密的數(shù)據(jù)。步驟209，接收端利用在步驟201確定的解密密鑰對該RTP報文攜帶的加密數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。這里，上述步驟208至步驟209中處理數(shù)據(jù)具體為將數(shù)據(jù)送往buffer，并對數(shù)據(jù)執(zhí)行組裝處理等操作。需要說明的是，如果步驟208接收的RTP報文是步驟206發(fā)送的RTP 報文，該RTP報文中攜帶了加密數(shù)據(jù)和未加密的數(shù)據(jù)，基于此，執(zhí)行到本步驟209時，可先將 RTP報文攜帶的未加密數(shù)據(jù)放入buffer，僅對加密數(shù)據(jù)進行解密，之后，將該解密后的數(shù)據(jù)放入buffer，以便進行后續(xù)的組裝處理。至此，通過步驟208至步驟209對接收端的處理流程進行了描述。以上對實施例一進行了完整描述，下面通過實施例二對發(fā)送端通過組播方式發(fā)送數(shù)據(jù)的情況進行描述。實施例二 參見圖4，圖4為本發(fā)明實施例提供的第二詳細流程圖。該流程是針對發(fā)送端通過組播方式發(fā)送數(shù)據(jù)的情況進行的描述，如圖4所示，該流程可包括以下步驟步驟401，發(fā)送端確定自身要使用的加密密鑰，接收端確定自身要使用的解密密鑰。這里，由于組播并非像單播“點對點”的情況，而是點對多點的情況，基于此，其不能像圖3a所示的流程那樣由接收端根據(jù)隨機生成的隨機密鑰生成要使用的解密密鑰，換言之，圖3a所示的流程中，各個接收端要使用的解密密鑰是不同的，而步驟401是針對組播的情況，其要求所有接收端即組播組成員都使用同一解密密鑰，具體實現(xiàn)時由發(fā)送端統(tǒng)一生成接收端要使用的解密密鑰，并發(fā)送給接收端。參見圖5，圖5為本發(fā)明實施例二中步驟401的實現(xiàn)流程圖。在該實現(xiàn)流程中，發(fā)送端和接收端采用RTCP進行協(xié)商，在其他協(xié)議比如SIP協(xié)議或者H323協(xié)議等的實現(xiàn)同理，基于此，如圖5所示，該流程可包括步驟501，發(fā)送端生成其所處的組播組對應(yīng)的加解密密鑰對即第一加密密鑰和第一解密密鑰，并將該第一加密密鑰確定為自身要使用的加密密鑰，以及將該第一解密密鑰確定為該組播組的接收端要使用的解密密鑰。步驟502，在接收端加入發(fā)送端所處的組播組后，發(fā)送端和接收端各自生成隨機密鑰。步驟503，發(fā)送端和接收端交互各自生成的隨機密鑰。步驟504，發(fā)送端根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端生成的隨機密鑰生成第二加密密鑰，接收端根據(jù)預(yù)先配置的共享密鑰、本端生成的隨機密鑰和對端生成的隨機密鑰生成自身要使用的第二解密密鑰。步驟503至步驟504分別與上述步驟30 至步驟303a類似，這里不再贅述。步驟505，發(fā)送端利用步驟504生成的第二加密密鑰對步驟501生成的第一解密密鑰進行加密，之后，發(fā)送加密后的第一解密密鑰至接收端。這里發(fā)送端可通過圖北所示的APP報文發(fā)送加密后的第一解密密鑰，此時需要對該APP報文的subtype字段取值為2，用于表示攜帶了新的密鑰，使名字name字段設(shè)置為用于表示加密的標識即ENCRYPT，以及使應(yīng)用數(shù)據(jù)application-d印endent data字段設(shè)置為加密后的第一解密密鑰，其他字段不變。步驟506，接收端利用步驟504生成的第二解密密鑰對接收的加密后的第一解密密鑰進行解密，將解密得到的第一解密密鑰確定為自身要使用的解密密鑰。至此，通過上述步驟發(fā)送端可得到自身要使用的加密密鑰即第一加密密鑰，接收端得到自身要使用的解密密鑰即第一解密密鑰。步驟402至步驟404分別與上述步驟202至步驟204類似，這里不再贅述。步驟405，發(fā)送端利用步驟401中確定的加密密鑰對該待傳輸數(shù)據(jù)進行全部加密， 將該加密的數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，并設(shè)置該RTP報文中X字段取值為第一標識，之后根據(jù)組播組地址發(fā)送完成設(shè)置的RTP報文。步驟406，發(fā)送端從該待傳輸數(shù)據(jù)中選擇出需要加密的數(shù)據(jù)，利用步驟401中確定的加密密鑰對該需要加密的數(shù)據(jù)進行加密，將該加密的數(shù)據(jù)和待傳輸數(shù)據(jù)中不需要加密的數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，并設(shè)置該RTP報文中X字段取值為第一標識，之后根據(jù)組播組地址發(fā)送完成設(shè)置的RTP報文。步驟407，發(fā)送端直接將該待傳輸數(shù)據(jù)設(shè)置在RTP報文的有效載荷字段，之后根據(jù)組播組地址發(fā)送完成設(shè)置的RTP報文。至此，通過以上步驟即可實現(xiàn)了發(fā)送端發(fā)送數(shù)據(jù)的流程。需要說明的是，發(fā)送端發(fā)送數(shù)據(jù)時可通過RTP報文進行發(fā)送，具體已在上面進行了描述。由于上述步驟405、步驟406和步驟407都是根據(jù)組播地址發(fā)送RTP報文的，換言之，處于該組播地址對應(yīng)的組播組中的所有成員都能接收到該發(fā)送的RTP報文，當其中一個成員記為接收端接收到上述發(fā)送端通過步驟405、步驟406或者步驟407發(fā)送的RTP報文后，還可執(zhí)行下述步驟408至步驟409，這兩個步驟分別與上述步驟208至步驟209類似，這里不再贅述。以上對實施例二進行了完整描述。
需要說明的是，在上述實施例一或者實施二中，發(fā)送端和接收端需要周期性地更新自身要使用的密鑰，降低密鑰被破解的幾率，以保證密鑰由于保持不變而被竊聽所導(dǎo)致的安全問題。至此，通過上面描述完成了本發(fā)明實施例提供的方法的描述。從上面步驟201至步驟207，或者步驟401至步驟407的描述可以看出，本實施例并非背景技術(shù)中描述的在啟動加密時就要求對待傳輸數(shù)據(jù)進行全部加密，而是基于實際應(yīng)用進行有選擇性地動態(tài)加密，比如對被默認要求加密的數(shù)據(jù)進行全部加密，而對其他數(shù)據(jù)不加密或者有選擇性地加密，這顯然降低了編碼端加密運算性能，以及解碼端解密運算性能的要求。下面對本發(fā)明實施例提供的裝置和系統(tǒng)進行描述。參見圖6，圖6為本發(fā)明實施例提供的發(fā)送端設(shè)備結(jié)構(gòu)圖。如圖6所示，該發(fā)送端設(shè)備可包括判斷單元601、加密單元602和發(fā)送單元603。其中，判斷單元601用于判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)；加密單元602用于在判斷單元601的判斷結(jié)果為是時，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密；這里，加密單元602確定的加密密鑰是由第三方設(shè)備通知的，或者由所述發(fā)送端設(shè)備生成，或者由所述發(fā)送端設(shè)備根據(jù)預(yù)先配置的共享密鑰、自身生成的隨機密鑰和與自身進行數(shù)據(jù)交流的對端設(shè)備生成的隨機密鑰確定的，這里不進行限定。發(fā)送單元603用于發(fā)送加密單元602加密的數(shù)據(jù)；或者在判斷單元601的判斷結(jié)果為否時，發(fā)送所述待傳輸數(shù)據(jù)。如圖6所示，判斷單元601可包括第一判斷子單元6011，用于判斷待傳輸數(shù)據(jù)是否為被默認要求加密的，所述被默認要求加密的為幀內(nèi)編碼I幀數(shù)據(jù)或者為分層編碼下的基本層數(shù)據(jù)；第二判斷子單元6012，用于在第一判斷子單元6011的判斷結(jié)果為否時，根據(jù)所述發(fā)送端設(shè)備的加密運算性能或者接收端設(shè)備請求的需要加密的數(shù)據(jù)信息，判斷是否需要對所述待傳輸數(shù)據(jù)進行加密，如果否，則確定待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)；第三判斷子單元6013，用于在第一判斷子單元6011的判斷結(jié)果為是時，或者在第二判斷子單元6012的判斷結(jié)果為是時，判斷是否需要對所述待傳輸數(shù)據(jù)進行全部加密，如果是，則確定所述待傳輸數(shù)據(jù)整體為需要加密的數(shù)據(jù)，如果否，則從所述待傳輸數(shù)據(jù)中選擇出需要加密的數(shù)據(jù)，將該選擇出的數(shù)據(jù)確定為需要加密的數(shù)據(jù)。本發(fā)明實施例還提供了如圖7所示的接收端設(shè)備的結(jié)構(gòu)，如圖7所示，接收端設(shè)備可包括接收單元701，用于接收發(fā)送端設(shè)備發(fā)送的數(shù)據(jù)；處理單元702，用于在接收單元701接收的數(shù)據(jù)為未被加密的數(shù)據(jù)時，直接處理接收的數(shù)據(jù)；在接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)時，利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。這里，接收單元701接收的數(shù)據(jù)是攜帶在實時傳輸協(xié)議RTP報文中發(fā)送的，基于此，處理單元702包括判斷子單元7021，用于判斷接收單元701接收的RTP報文的X字段是否置為用于表示攜帶了加密數(shù)據(jù)的第一標識；
解密子單元7022，用于在判斷子單元7021的判斷結(jié)果為是時，利用已確定的解密密鑰對該RTP報文攜帶的已加密的數(shù)據(jù)進行解密；處理子單元7023，用于處理解密子單元7022解密后的數(shù)據(jù)，或者在判斷子單元 7021的判斷結(jié)果為否時，直接處理所述RTP報文攜帶的數(shù)據(jù)。考慮到本發(fā)明實施例的應(yīng)用，本發(fā)明實施例還提供了一種數(shù)據(jù)傳輸系統(tǒng)，該系統(tǒng)可包括如圖5所示的發(fā)送端設(shè)備和如圖7所示的接收端設(shè)備，具體分別如上所述。以上對本發(fā)明實施例提供的裝置和系統(tǒng)進行了描述。由以上技術(shù)方案可以看出，本發(fā)明中，并非像背景技術(shù)描述的第二種方案那樣，只能針對待傳輸數(shù)據(jù)進行全部加密，而是動態(tài)有選擇性地對待傳輸數(shù)據(jù)加密，比如對待傳輸數(shù)據(jù)中的部分數(shù)據(jù)加密，這顯然降低了編碼端加密運算性能，以及解碼端解密運算性能的要求；進一步地，本發(fā)明中，發(fā)送端和接收端需要周期性地更新自身要使用的密鑰，降低密鑰被破解的幾率，以保證密鑰由于保持不變而被竊聽所導(dǎo)致的安全問題。以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所做的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明保護的范圍之內(nèi)。
權(quán)利要求
1.一種數(shù)據(jù)傳輸方法，其特征在于，該方法包括A，發(fā)送端判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)，如果是，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密并發(fā)送；如果否，直接發(fā)送所述待傳輸數(shù)據(jù)；B，接收端接收到數(shù)據(jù)后，如果接收的數(shù)據(jù)為未被加密的數(shù)據(jù)，則直接處理接收的數(shù)據(jù)； 如果接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)，則利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述發(fā)送端通過單播方式發(fā)送數(shù)據(jù)時， 所述加密密鑰和所述解密密鑰分別由第三方設(shè)備確定，并由該第三方設(shè)備分別通知給發(fā)送端和接收端；或者通過以下步驟確定發(fā)送端和接收端各自生成隨機密鑰；發(fā)送端和接收端交互各自生成的隨機密鑰；發(fā)送端根據(jù)預(yù)先配置的共享密鑰、自身生成的隨機密鑰和所述接收端生成的隨機密鑰生成所述加密密鑰；接收端根據(jù)預(yù)先配置的共享密鑰、自身生成的隨機密鑰和所述發(fā)送端生成的隨機密鑰生成所述解密密鑰。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述發(fā)送端通過組播方式發(fā)送數(shù)據(jù)時， 所述加密密鑰和所述解密密鑰通過以下步驟實現(xiàn)發(fā)送端生成其所處的組播組對應(yīng)的所述加密密鑰和所述解密密鑰；在所述接收端加入所述組播組之后，發(fā)送端和接收端各自生成隨機密鑰，并交互各自生成的隨機密鑰；發(fā)送端根據(jù)預(yù)先配置的共享密鑰、自身生成的隨機密鑰和所述接收端生成的隨機密鑰生成第一加密密鑰；接收端根據(jù)預(yù)先配置的共享密鑰、自身生成的隨機密鑰和所述發(fā)送端生成的隨機密鑰生成第二解密密鑰；發(fā)送端利用所述第一加密密鑰對所述解密密鑰進行加密，之后發(fā)送加密后的解密密鑰至接收端，由所述接收端利用所述第一解密密鑰對接收的加密后的解密密鑰進行解密，得到所述解密密鑰。
4.根據(jù)權(quán)利要求2或3所述的方法，其特征在于，所述發(fā)送端和接收端通過應(yīng)用指明功能APP報文交互各自生成的隨機密鑰，具體包括所述發(fā)送端和接收端分別使APP報文的子類型subtype字段設(shè)置為用于表示攜帶了隨機密鑰的標識、使名字name字段設(shè)置為用于表示加密的標識，以及使應(yīng)用數(shù)據(jù) application-dependent data字段設(shè)置為自身生成的隨機密鑰，之后發(fā)送完成了所述設(shè)置的該APP報文給對端。
5.根據(jù)權(quán)利要求1至3任一所述的方法，其特征在于，所述步驟A中的判斷為Al，發(fā)送端判斷待傳輸數(shù)據(jù)是否為被默認要求加密的數(shù)據(jù)，所述被默認要求加密的數(shù)據(jù)為幀內(nèi)編碼I幀數(shù)據(jù)或者為分層編碼下的基本層數(shù)據(jù)，如果是，確定待傳輸數(shù)據(jù)為需要加密的數(shù)據(jù)，如果否，確定待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述確定待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)之前包括發(fā)送端根據(jù)自身的加密運算性能或者接收端請求的需要加密的數(shù)據(jù)信息，判斷是否需要對所述待傳輸數(shù)據(jù)進行加密，如果否，執(zhí)行確定待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)的操作；如果是，確定待傳輸數(shù)據(jù)為需要加密的數(shù)據(jù)。
7.根據(jù)權(quán)利要求5或6所述的方法，其特征在于，所述確定待傳輸數(shù)據(jù)為需要加密的數(shù)據(jù)包括發(fā)送端判斷是否需要對所述待傳輸數(shù)據(jù)進行全部加密，如果是，則確定所述待傳輸數(shù)據(jù)整體為需要加密的數(shù)據(jù)，如果否，則從所述待傳輸數(shù)據(jù)中選擇出需要加密的數(shù)據(jù)，將該選擇出的數(shù)據(jù)確定為需要加密的數(shù)據(jù)。
8.根據(jù)權(quán)利要求1至3任一所述的方法，其特征在于，所述步驟A中的數(shù)據(jù)攜帶在實時傳輸協(xié)議RTP報文中發(fā)送，其中，如果所述RTP報文中攜帶了加密數(shù)據(jù)，則所述RTP報文的擴展位X字段置為用于表示攜帶了加密數(shù)據(jù)的第一標識；所述步驟B包括所述接收端接收到RTP報文后，判斷該RTP報文的X字段是否置為第一標識，如果是， 則利用已確定的解密密鑰對該RTP報文攜帶的已加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)；如果否，則直接處理RTP報文攜帶的數(shù)據(jù)。
9.一種發(fā)送端設(shè)備，其特征在于，所述發(fā)送端設(shè)備包括判斷單元、加密單元和發(fā)送單元，其中，所述判斷單元用于判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)；所述加密單元用于在所述判斷單元的判斷結(jié)果為是時，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密；所述發(fā)送單元用于發(fā)送所述加密單元加密的數(shù)據(jù)；或者在所述判斷單元的判斷結(jié)果為否時，發(fā)送所述待傳輸數(shù)據(jù)。
10.根據(jù)權(quán)利要求9所述的發(fā)送端設(shè)備，其特征在于，所述判斷單元包括第一判斷子單元，用于判斷待傳輸數(shù)據(jù)是否為被默認要求加密的，所述被默認要求加密的為幀內(nèi)編碼I幀數(shù)據(jù)或者為分層編碼下的基本層數(shù)據(jù)；第二判斷子單元，用于在所述第一判斷子單元的判斷結(jié)果為否時，根據(jù)所述發(fā)送端設(shè)備的加密運算性能或者接收端設(shè)備請求的需要加密的數(shù)據(jù)信息，判斷是否需要對所述待傳輸數(shù)據(jù)進行加密，如果否，則確定待傳輸數(shù)據(jù)中不存在需要加密的數(shù)據(jù)；第三判斷子單元，用于在所述第一判斷子單元的判斷結(jié)果為是時，或者在所述第二判斷子單元的判斷結(jié)果為是時，判斷是否需要對所述待傳輸數(shù)據(jù)進行全部加密，如果是，則確定所述待傳輸數(shù)據(jù)整體為需要加密的數(shù)據(jù)，如果否，則從所述待傳輸數(shù)據(jù)中選擇出需要加密的數(shù)據(jù)，將該選擇出的數(shù)據(jù)確定為需要加密的數(shù)據(jù)。
11.一種接收端設(shè)備，其特征在于，所述接收端設(shè)備包括接收單元，用于接收發(fā)送端設(shè)備發(fā)送的數(shù)據(jù)；處理單元，用于在所述接收單元接收的數(shù)據(jù)為未被加密的數(shù)據(jù)時，直接處理接收的數(shù)據(jù)；在接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)時，利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。
12.根據(jù)權(quán)利要求11所述的接收端設(shè)備，其特征在于，所述接收單元接收的數(shù)據(jù)是攜帶在實時傳輸協(xié)議RTP報文中發(fā)送的，所述處理單元包括判斷子單元，用于判斷所述接收單元接收的RTP報文的X字段是否置為用于表示攜帶了加密數(shù)據(jù)的第一標識；解密子單元，用于在所述判斷子單元的判斷結(jié)果為是時，利用已確定的解密密鑰對該RTP報文攜帶的已加密的數(shù)據(jù)進行解密；處理子單元，用于處理所述解密子單元解密后的數(shù)據(jù)，或者在所述判斷子單元的判斷結(jié)果為否時，直接處理所述RTP報文攜帶的數(shù)據(jù)。
13. 一種數(shù)據(jù)傳輸系統(tǒng)，其特征在于，所述系統(tǒng)包括如權(quán)利要求9至10任一項所述的發(fā)送端設(shè)備和如權(quán)利要求11至12任一項所述的接收端設(shè)備。
全文摘要
本發(fā)明提供了一種數(shù)據(jù)傳輸方法、系統(tǒng)和裝置，其中，該方法包括A，發(fā)送端判斷待傳輸數(shù)據(jù)中是否存在需要加密的數(shù)據(jù)，如果是，利用已確定的加密密鑰對所述需要加密的數(shù)據(jù)進行加密并發(fā)送；如果否，直接發(fā)送所述待傳輸數(shù)據(jù)；B，接收端接收到數(shù)據(jù)后，如果接收的數(shù)據(jù)為未被加密的數(shù)據(jù)，則直接處理接收的數(shù)據(jù)；如果接收的數(shù)據(jù)中存在已被加密的數(shù)據(jù)，則利用已確定的解密密鑰對加密的數(shù)據(jù)進行解密，并處理解密后的數(shù)據(jù)。采用本發(fā)明，能夠降低編碼端加密運算性能，以及解碼端解密運算性能。
文檔編號H04L29/06GK102281261SQ20101020343
公開日2011年12月14日 申請日期2010年6月10日 優(yōu)先權(quán)日2010年6月10日
發(fā)明者任俊峰, 王連朝 申請人:杭州華三通信技術(shù)有限公司