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

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


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