CN115225977B - 一种视频稀疏非对称加密方法 - Google Patents

Abstract

本发明公开了一种视频稀疏非对称加密方法，所述方法通过给播放端用户分配密钥，通过非对称加密方法进行密钥传输，所述密钥根据用户是否有录制文件权限来动态决定密钥是否固定。本发明通过选取关键视频解码信息进行加密，避免了全量加密，从而大幅的降低了计算量；通过采用非对称加密方式进行，通过专用的软件包，密钥的管理更加的严格，避免了密钥泄漏风险，提高了安全性。视频水印的添加进一步提升了视频防录制的安全性；利用现有的模型，易于实现，保持帧序列结构不破坏，便于升级和维护。

Description

一种视频稀疏非对称加密方法

技术领域

本发明涉及实时流媒体视频传输加密技术领域，具体提供一种视频稀疏非对称加密方法。

背景技术

视频加密，是很多网络视频机构，如培训机构等的的命脉所在，如果视频被恶意传播和转售，对于视频教学的机构来说，是损失巨大的。特别是在线教育机构，需要对视频加密，以保护视频权益。

目前常用的加密技术有：

(1)视频码流逐帧，全部加密。例如采用标准加密方法DES加密整个视频流。此方法没有利用到视频流数据本身的特性，实际视频没必要全部加密，只需要加密关键的编解码信息即可，全部加密计算量较大，对于在线视频流很难保证其实时性。对播放端会造成不必要的算力浪费。

(2)完全转码加密。将每一帧标准的视频帧进行重新编码，优点是保密性好，但是算法较为复杂，维护和升级不容易实现，且加密和解密过程需要消耗过多的算力，在实时性要求较高的场景中不适合。

(3)基于hls标准协议的加密。采用aes对称加密算法，优点是兼容性好，适合在浏览器和手机端标准播放环境中使用，缺点是容易被盗取链接，密钥容易被窃取后破解，适用于保密性要求不高的场合。

(4)防盗链机制。防盗链严格来说不是一种视频的加密方式，只是获取视频链接时的保护机制，对于视频本身仍然是明文的，或者可以通过key来直接解码视频，因此在版权要求比较高的场合也不适用于此方法。

(5)flash加密机制。例如基于rtmpe的加密方法提供了一种动态协商密钥加密视频的方法，但基于二进制的传输协议开发较为复杂，且容易出现兼容性问题，不适合一般的通用场景。

发明内容

鉴于以上问题和技术，为提高视频加密安全性，减少视频加密计算量，降低加密模型复杂度，本发明提供了如下技术方案：

一种视频稀疏非对称加密方法，所述方法通过给播放端用户分配密钥，通过非对称加密方法进行密钥传输，所述密钥根据用户是否有录制文件权限来动态决定密钥是否固定。

更进一步的，所述方法的实现还包括：

在加密信息的选择上，只加密视频编解码关键信息，从而减少计算量，提高视频传输效率。

更进一步的，所述方法的实现还包括：

所述视频信息在传输时采用二进制的传输交互协议，包括信令的交互和媒体负载数据的交互。

更进一步的，所述方法的实现还包括：

为了最大限度降低录屏带来的视频传播泄漏影响，在视频播放端解码的码流中增加水印信息。

更进一步的，所述方法的实现包括：

第一步：选择视频编解码关键信息进行加密；

第二步：采用非对称加密方式管理密钥；

第三步；编码水印信息；

第四步：客户端(播放端)解密。

更进一步的，所述视频编解码关键信息包括：视频参数集以及关键帧，其加密报文的实现过程包括：

1)注册阶段

客户端(媒体使用方)先向服务器端(媒体服务系统)进行注册，上传客户端(播放端)账号对应的公钥信息；个人公钥信息和播放账号唯一绑定；未进行注册的客户端(播放端)，后续报文交互会在验证阶段就失败；

2)握手阶段

所述客户端和服务器端首先交互信令，属于会话发起的协商阶段；客户端先向服务器进行注册，上传自己的公钥信息进行验证；

客户端首先发送身份验证报文，服务器则对客户端报文进行验证。

3)音视频数据和控制信令交互

握手成功之后，进行音视频数据和控制信令的交互；传输采用网络序进行，在直播时，数据流向主要是从服务器发送到客户端；

当帧类型为视频参数集或者I帧数据时，则对数据进行加密处理，其他非关键数据例如B帧和P帧以及控制信令，则不加密；

4)挥手阶段

客户端(播放端)需要断开连接时，通过直接切断socket连接，或发送挥手报文实现。挥手报文无须加密。

更进一步的，所述握手阶段的实现过程包括：

所述客户端发送握手报文，传输采用网络序进行，1字节的媒体协议版本号，后面跟4个字节的时间戳信息；

所述客户端(播放端)id号是一个文本字符串，其长度用4个字节来表示，后面是播放端的id值；

所述id值后面是4字节的盐值，用来加到签名中；

盐值后面是32字节的签名值；

签名算法采用私钥签名sign(sha256[1Bversion+4B timestamp+4B id length+id value+4B salt])，服务器端对此签名值进行验证。

更进一步的，所述非对称加密方式管理密钥的实现包括：

对每个用户的密钥都采用非对称加密的方式，可以有效管理密钥泄漏问题；

所述密钥分为动态密钥和静态密钥2种，其中，动态密钥仅用来实时流媒体的传输，适用于无存储需求的用户；静态密钥可实现视频文件的本地存储，存储后的文件也是加密的，用户必须通过对应的密钥来进行解码播放。

更进一步的，所述方法为用户提供专用的软件包进行解密；

所述软件包根据用户信息，通过和服务器之间的报文交互，采用非对称加密的方式传输密钥；握手成功之后，客户端则获取到密钥，根据协议报文，解密之后，将原始的音视频数据送入解码器，在客户端实现解密播放。

更进一步的，所述服务器端接受到客户端的握手请求后，首先按照报文排列顺序进行解析，解析之后得到对应的属性值，如果版本号不一致则握手失败；

解析客户端id之后，先从数据库中读取其公钥值，读取失败则握手失败；

读取成功之后公钥解密密文验证签名，验证失败则握手失败；

通过计算解密之后的签名值，对比成功之后则握手成功。

与现有技术相比，本发明一种视频稀疏非对称加密方法具有以下突出的有益效果：

1、加解密计算量大幅减少

通过选取关键视频解码信息进行加密，避免了全量加密，从而大幅的降低了计算量。

2、加密安全性提升

通过采用非对称加密方式进行，通过专用的软件包，密钥的管理更加的严格，避免了密钥泄漏风险，提高了安全性。视频水印的添加进一步提升了视频防录制的安全性。

3、模型复杂度易于维护

利用现有的模型，易于实现，保持帧序列结构不破坏，便于升级和维护。

附图说明

图1是本发明方法实现整体流程图；

图2是客户端发送握手报文示意图；

图3是服务器端返回握手结果示意图；

图4是音视频和控制信号报文示意图。

具体实施方式

下面将结合附图和实施例，对本发明作进一步详细说明。

如图1所示，一种视频稀疏非对称加密方法，所述方法的实现过程如下:

第一步：选择视频编解码关键信息进行加密：

(1)视频编解码关键信息包括视频参数集和视频关键帧，其中：

对于h264/h265编码视频，视频参数集是其解码的重要信息，缺乏参数集则无法进行视频解码处理。因此参数集需要进行加密处理。同时视频的参数集信息量不大，一般在几十到几百个字节，里面存储了视频的编码类型，编码级别，分辨率等解码信息。视频参数集对于视频解码有着非常重要的作用。

视频关键帧：视频数据尤其本身的特性，因此有专门的压缩算法。压缩后的视频帧序列主要分为IBP帧类型，其中I帧可以独立解码不依赖于其他帧，后续的B帧和P帧则需要依赖于I帧进行解码。因此加密关键帧信息可以起到保护整个视频加密信息的作用，同时又可减少不必要的B帧和P帧的计算量。

(2)加密报文设计

a、注册阶段

媒体使用方需先向媒体服务系统进行注册，上传播放端账号对应的公钥信息。个人公钥信息和播放账号唯一绑定。未进行注册的播放端，后续报文交互会在验证阶段就失败。

b、握手阶段

握手阶段双方首先交互信令，属于会话发起的协商阶段。客户端需要先向服务器进行注册，上传自己的公钥信息进行验证。

客户端首先发送身份验证报文，服务器则对客户端报文进行验证。

如图2所示，客户端发送握手报文，传输均采用网络序进行，1字节的媒体协议版本号，后面跟4个字节的时间戳信息。播放端id号是一个文本字符串，其长度用4个字节来表示，后面则是播放端的id值。后面是4字节的盐值用来加到签名中。最后是32字节的签名值。

签名算法采用私钥签名sign(sha256[1Bversion+4B timestamp+4B id length+id value+4B salt])。服务器会对此签名值进行验证。

如图3所示，服务器接受到客户端的握手请求后，首先按照上述的报文排列顺序进行解析，解析之后得到对应的属性值。版本号不一致则握手失败。解析客户端id之后，需要先从数据库中读取其公钥值，读取失败则握手失败。读取成功之后公钥解密密文验证签名。验证失败则握手失败。通过计算解密之后的签名值，对比成功之后则握手成功。

c、音视频数据和控制信令交互

握手成功之后，则进行音视频数据和控制信令的交互。如图4所示，传输采用网络序进行，在直播时，数据流向主要是从服务器发送到客户端。当帧类型为视频参数集或者I帧数据时，则对数据进行加密处理。其他非关键数据例如B帧和P帧以及控制信令，则不加密。

d、挥手阶段

播放端需要断开连接时，可以直接切断socket连接，也可以发送挥手报文。挥手报文无须加密。

第二步：非对称管理密钥机制

(1)采用非对称加密方式管理密钥：对每个用户的密钥都采用非对称加密的方式，可以有效管理密钥泄漏问题。

(2)密钥的管理：密钥分为动态密钥和静态密钥2种。动态密钥仅仅用来实时流媒体的传输，适用于无存储需求的用户。静态密钥可以实现视频文件的本地存储，存储后的文件也是加密的，用户必须通过对应的密钥来进行解码播放。

第三步:编码水印信息

即使对视频进行了加密处理，用户仍然可以通过录制屏幕的方式获取到播放视频，为了最大限度的降低录制视频对加密安全性的破坏，需要在播放的视频中编码水印信息，从而降低这种破坏的影响。

第四步：播放端解密方式

用户解密时，需要采用专用的软件包。软件包需要根据用户信息，通过和服务器之间的报文交互，通过非对称加密的方式来传输密钥，握手成功之后，客户端则获取到密钥，根据协议报文，解密之后，将原始的音视频数据送入解码器，在客户端实现解密播放。

以上所述的实施例，只是本发明较优选的具体实施方式，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。

Claims (2)

1.一种视频稀疏非对称加密方法，其特征在于，所述方法的实现包括：

第一步：选择视频编解码关键信息进行加密；

第二步：采用非对称加密方式管理密钥；

第三步；编码水印信息；

第四步：客户端解密；

所述视频编解码关键信息包括：视频参数集以及关键帧，其加密报文的实现过程包括：

1)注册阶段

客户端先向服务器端进行注册，上传客户端账号对应的公钥信息；个人公钥信息和播放账号唯一绑定；未进行注册的客户端，后续报文交互会在验证阶段就失败；

2)握手阶段

所述客户端和服务器端首先交互信令，属于会话发起的协商阶段；客户端先向服务器进行注册，上传自己的公钥信息进行验证；

客户端首先发送身份验证报文，服务器则对客户端报文进行验证。

3)音视频数据和控制信令交互

握手成功之后，进行音视频数据和控制信令的交互；传输采用网络序进行，在直播时，数据流向是从服务器发送到客户端；

当帧类型为视频参数集或者I帧数据时，则对数据进行加密处理，其他非关键数据B帧和P帧以及控制信令，则不加密；

4)挥手阶段

客户端需要断开连接时，通过直接切断socket连接，或发送挥手报文实现；

所述握手阶段的实现过程包括：

所述客户端发送握手报文，传输采用网络序进行，1字节的媒体协议版本号，后面跟4个字节的时间戳信息；

所述客户端id号是一个文本字符串，其长度用4个字节来表示，后面是播放端的id值；

所述id值后面是4字节的盐值，用来加到签名中；

盐值后面是32字节的签名值；

签名算法采用私钥签名sign(sha256[1Bversion+4B timestamp+4B id length+idvalue+4B salt])，服务器端对此签名值进行验证；

所述非对称加密方式管理密钥的实现包括：

对每个用户的密钥都采用非对称加密的方式；

所述密钥分为动态密钥和静态密钥2种，其中，动态密钥仅用来实时流媒体的传输，适用于无存储需求的用户；静态密钥可实现视频文件的本地存储，存储后的文件也是加密的，用户必须通过对应的密钥来进行解码播放；

所述方法为用户提供专用的软件包进行解密；

所述软件包根据用户信息，通过和服务器之间的报文交互，采用非对称加密的方式传输密钥；握手成功之后，客户端则获取到密钥，根据协议报文，解密之后，将原始的音视频数据送入解码器，在客户端实现解密播放；

所述服务器端接受到客户端的握手请求后，首先按照报文排列顺序进行解析，解析之后得到对应的属性值，如果版本号不一致则握手失败；

解析客户端id之后，先从数据库中读取其公钥值，读取失败则握手失败；

读取成功之后公钥解密密文验证签名，验证失败则握手失败；

通过计算解密之后的签名值，对比成功之后则握手成功。

2.根据权利要求1所述的一种视频稀疏非对称加密方法，其特征在于，所述方法的实现还包括：

在视频播放端解码的码流中增加水印信息。