CN102281261A - 一种数据传输方法、系统和装置 - Google Patents

Abstract

本发明提供了一种数据传输方法、系统和装置，其中，该方法包括：A，发送端判断待传输数据中是否存在需要加密的数据，如果是，利用已确定的加密密钥对所述需要加密的数据进行加密并发送；如果否，直接发送所述待传输数据；B，接收端接收到数据后，如果接收的数据为未被加密的数据，则直接处理接收的数据；如果接收的数据中存在已被加密的数据，则利用已确定的解密密钥对加密的数据进行解密，并处理解密后的数据。采用本发明，能够降低编码端加密运算性能，以及解码端解密运算性能。

Description

一种数据传输方法、系统和装置

技术领域

本发明涉及通信技术领域，特别涉及一种数据传输方法、系统和装置。

背景技术

实时传输协议(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报文头的格式示意图；

图3b为本发明实施例应用的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报头字段和有效载荷(Payload)字段，其中，有效载荷字段用于携带数据，RTP报头字段具体内容参见图3a所示，包括以下各个字段：

版本号(V)字段、填充位(P)字段、扩展位(X)字段、CSRC计数器(CC)字段、标记位(M)字段、载荷类型(PT)字段、序列号(sequence number)字段、时间戳(time stamp)字段、同步源(SSRC：Synchronization Source)标识符(identifier)字段、贡献源(CSRC：Contributing Source)标识符(identifier)字段。

其中，版本号(V)字段、填充位(P)字段、CSRC计数器(CC)字段、标记位(M)字段、载荷类型(PT)字段、序列号(sequence number)字段、时间戳(time stamp)字段、同步源(SSRC：Synchronization Source)标识符(identifier)字段、贡献源(CSRC：Contributing Source)标识符(identifier)字段的具体定义与现有技术类似，这里不再赘述。而X字段，本实施例中，如果该X字段置为第一标识，则表示该RTP报文的有效载荷字段中携带了加密数据，其中，关于该加密数据的描述可通过RTP扩展头表示。这里，RTP扩展头的具体内容可参见图3b所示，其包含配置文档定义(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-dependent data)字段可供用户自主定义，其他字段都严格遵守RTCP。基于此，这里可分别对subtype字段、Name字段和Application-dependent data字段作如下定义：

subtype字段，用于表示APP报文是否携带随机密钥，具体地，如果subtype字段取值为1，则表示该APP报文携带了随机密钥；否则，表示没有携带随机密钥。

Name字段，用于携带APP报文的加密信息，这里取值为加密(ENCRYPT)，表示该APP报文为加密报文；

Application-dependent data字段，用于携带随机密钥。

如此，发送端和接收端通过解析接收的APP报文所携带的subtype字段、Name字段和Application-dependent 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分别与上述步骤302a至步骤303a类似，这里不再赘述。

步骤505，发送端利用步骤504生成的第二加密密钥对步骤501生成的第一解密密钥进行加密，之后，发送加密后的第一解密密钥至接收端。

这里发送端可通过图3b所示的APP报文发送加密后的第一解密密钥，此时需要对该APP报文的subtype字段取值为2，用于表示携带了新的密钥，使名字name字段设置为用于表示加密的标识即ENCRYPT，以及使应用数据application-dependent 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所示的接收端设备，具体分别如上所述。

以上对本发明实施例提供的装置和系统进行了描述。

由以上技术方案可以看出，本发明中，并非像背景技术描述的第二种方案那样，只能针对待传输数据进行全部加密，而是动态有选择性地对待传输数据加密，比如对待传输数据中的部分数据加密，这显然降低了编码端加密运算性能，以及解码端解密运算性能的要求；

进一步地，本发明中，发送端和接收端需要周期性地更新自身要使用的密钥，降低密钥被破解的几率，以保证密钥由于保持不变而被窃听所导致的安全问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (13)

1.一种数据传输方法，其特征在于，该方法包括：

A，发送端判断待传输数据中是否存在需要加密的数据，如果是，利用已确定的加密密钥对所述需要加密的数据进行加密并发送；如果否，直接发送所述待传输数据；

B，接收端接收到数据后，如果接收的数据为未被加密的数据，则直接处理接收的数据；如果接收的数据中存在已被加密的数据，则利用已确定的解密密钥对加密的数据进行解密，并处理解密后的数据。

2.根据权利要求1所述的方法，其特征在于，在所述发送端通过单播方式发送数据时，所述加密密钥和所述解密密钥分别由第三方设备确定，并由该第三方设备分别通知给发送端和接收端；或者通过以下步骤确定：

发送端和接收端各自生成随机密钥；

发送端和接收端交互各自生成的随机密钥；

发送端根据预先配置的共享密钥、自身生成的随机密钥和所述接收端生成的随机密钥生成所述加密密钥；接收端根据预先配置的共享密钥、自身生成的随机密钥和所述发送端生成的随机密钥生成所述解密密钥。

3.根据权利要求1所述的方法，其特征在于，在所述发送端通过组播方式发送数据时，所述加密密钥和所述解密密钥通过以下步骤实现：

发送端生成其所处的组播组对应的所述加密密钥和所述解密密钥；

在所述接收端加入所述组播组之后，发送端和接收端各自生成随机密钥，并交互各自生成的随机密钥；

发送端根据预先配置的共享密钥、自身生成的随机密钥和所述接收端生成的随机密钥生成第一加密密钥；接收端根据预先配置的共享密钥、自身生成的随机密钥和所述发送端生成的随机密钥生成第二解密密钥；

发送端利用所述第一加密密钥对所述解密密钥进行加密，之后发送加密后的解密密钥至接收端，由所述接收端利用所述第一解密密钥对接收的加密后的解密密钥进行解密，得到所述解密密钥。

4.根据权利要求2或3所述的方法，其特征在于，所述发送端和接收端通过应用指明功能APP报文交互各自生成的随机密钥，具体包括：

所述发送端和接收端分别使APP报文的子类型subtype字段设置为用于表示携带了随机密钥的标识、使名字name字段设置为用于表示加密的标识，以及使应用数据application-dependent data字段设置为自身生成的随机密钥，之后发送完成了所述设置的该APP报文给对端。

5.根据权利要求1至3任一所述的方法，其特征在于，所述步骤A中的判断为：

A1，发送端判断待传输数据是否为被默认要求加密的数据，所述被默认要求加密的数据为帧内编码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任一项所述的接收端设备。

Images