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