CN111711785B - 视频会议媒体流密钥更新方法、系统、设备及存储介质 - Google Patents
视频会议媒体流密钥更新方法、系统、设备及存储介质 Download PDFInfo
- Publication number
- CN111711785B CN111711785B CN202010616110.6A CN202010616110A CN111711785B CN 111711785 B CN111711785 B CN 111711785B CN 202010616110 A CN202010616110 A CN 202010616110A CN 111711785 B CN111711785 B CN 111711785B
- Authority
- CN
- China
- Prior art keywords
- key
- updating
- media stream
- load
- updated
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/14—Systems for two-way working
- H04N7/15—Conference systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26291—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for providing content or additional data updates, e.g. updating software modules, stored at the client
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Telephonic Communication Services (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种视频会议媒体流密钥更新方法、系统、设备及存储介质,所述方法包括:发送端通过SDP交互与接收端协商密钥载荷更新方式;需要更新密钥时,所述发送端新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端;于所述接收端接收到所述密钥载荷后,所述发送端将所述密钥载荷中承载的密钥确定为更新后的密钥。通过采用本发明,提供了一种专门用于密钥更新的RTP格式的密钥载荷,无需每次都使用SDP交互进行密钥协商,实现了媒体流密钥的轻量级和实时更新。
Description
技术领域
本发明涉及数据处理技术领域,尤其涉及一种视频会议媒体流密钥更新方法、系统、设备及存储介质。
背景技术
随着视频会议的普遍性,安全问题也越来越被大家所关注。基于此,也有很多可靠的安全协议被制定,以提高媒体流传输安全性。现在视频会议中使用比较多的加密方式是TLS(Transport Layer Security,传输层安全协议)用来确保信令层面的安全,或者使用SRTP(Secure Real-time Transport Protocol,安全的实时传输协议)来确保码流层面的安全,或者使用量子加密通讯方式。
根据RFC4568(Session Description Protocol(SDP)Security Descriptionsfor Media Streams,会话描述协议(SDP)媒体流的安全描述),SRTP的安全相关协商基于SDP(Session Description Protocol,描述会话的协议),所以密钥的安全基于信令的安全。基于量子通讯的视频会议,其密钥交换是通过量子通讯的方式来保证密钥安全,只通过信令交互密钥的标识ID。可见在安全体系中,密钥的安全是整个安全体系的基石。强大的加密算法、或者量子加密方式,也为密钥的安全传输保驾护航。
但是,现在破解加密算法的时间成本越来越少,使用单一密钥就显得很不安全了,所以在一次会话中不断的更新加密密钥成为了安全加固器,可以防止在被攻击者破解密钥之前及时的更新掉密钥,使得会话更加安全。
目前对于密钥更新方式,多数都是通过SDP的重新交互来完成。使用这种方式将会有三个缺点:第一:SDP的重新交互,基本上是可更新会话里所有的参数信息。所以进行SDP重新交互,需要对每一个会话的数据进行重新判断更新,是一个很重量级的方式。第二:通过信令更新密钥(SDP交互),将会有不及时性,尤其是需要频繁更新密钥的场景,SDP交互会耗费很长时间,从信令侧协商好后再导入到码流处理侧,会导致密钥的更新就会更不及时,往往需要规定很多额外的规则来弥补它的不及时性,比如在安全等级规定的时限或者密钥个数快用完之前的一段时间先进行信令侧交互,或者每次SDP交互带上大量备用密钥。第三:SDP的重新交互,对于密钥更新来说,意味着每一路媒体都要进行密钥更新,对密钥数量分配有限额的使用场景来说就很不友好。
发明内容
针对现有技术中的问题,本发明的目的在于提供一种视频会议媒体流密钥更新方法、系统、设备及存储介质,提供了一种专门用于密钥更新的RTP格式的密钥载荷,无需每次都使用SDP交互进行密钥协商。
本发明实施例提供一种视频会议媒体流密钥更新方法,包括如下步骤:
发送端通过SDP交互与接收端协商密钥载荷更新方式;
需要更新密钥时,所述发送端新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端;
于所述接收端接收到所述密钥载荷后,所述发送端将所述密钥载荷中承载的密钥确定为更新后的密钥。
可选地,所述发送端通过SDP交互与接收端协商密钥载荷更新方式,包括如下步骤:
所述发送端在会话描述信息中添加密钥载荷更新方式定义信息;
所述发送端将会话描述信息通过SDP交互发送给所述接收端;
所述发送端接收到所述接收端的密钥载荷反馈信息时,确定密钥载荷协商成功。
可选地,所述在会话描述信息中添加密钥载荷更新方式定义信息,包括如下步骤:
如果当前采用RTP多路会话模式,在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,所述密钥更新媒体流的描述信息包括密钥载荷的更新方式定义信息。
可选地,所述在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,包括如下步骤:
判断所述会话描述信息中所描述的每路视频会议媒体流采用的密钥是否统一;
如果每路视频会议媒体流采用的密钥统一,在所述会话描述信息中新增一路密钥更新媒体流的描述信息;
如果每路视频会议媒体流采用的密钥不统一,针对每路需要更新的视频会议媒体流单独新增一路密钥更新媒体流的描述信息,并建立所述密钥更新媒体流与所对应的视频会议媒体流的关联关系。
可选地,所述在会话描述信息中添加密钥载荷更新方式定义信息,包括如下步骤:
如果当前采用SSRC多路会话模式,在每路需要更新的视频会议媒体流的描述信息中添加密钥载荷的更新方式定义信息。
可选地,所述密钥载荷更新方法定义信息包括密钥载荷名称、每次更新的最大密钥数和预计更新时长中的一项或多项。
可选地,在所述密钥载荷中添加待更新的密钥,包括如下步骤:
获取待更新的密钥和所述待更新的密钥所更新的视频会议媒体流的SSRC标识,所述待更新的密钥为采用预设加密算法加密的密钥;
将所述待更新的密钥和所对应的SSRC标识添加至RTP格式的密钥载荷中。
可选地,所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端之后,还包括如下步骤:
所述发送端判断是否接收到所述接收端的密钥载荷反馈信息;
如果是,则所述发送端确认所述接收端接收到所述密钥载荷,并将所述密钥载荷中承载的密钥确定为更新后的密钥。
通过采用本发明的视频会议媒体流密钥更新方法,提供了一种专门用于密钥更新的RTP格式的密钥载荷,无需每次都使用SDP交互进行密钥协商,通过RTP格式的密钥载荷实现了媒体流密钥的轻量级和实时更新。
本发明实施例还提供一种视频会议媒体流密钥更新系统,应用于所述的视频会议媒体流密钥更新方法,所述系统包括:
更新协商模块,用于通过SDP交互与接收端协商密钥载荷更新方式;
载荷创建模块,用于在需要更新密钥时,新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
载荷发送模块,用于通过RTP媒体流将所述密钥载荷发送至所述接收端;
更新确认模块,用于在所述接收端接收到所述密钥载荷后,将所述密钥载荷中承载的密钥确定为更新后的密钥。
通过采用本发明的视频会议媒体流密钥更新系统,提供了一种专门用于密钥更新的RTP格式的密钥载荷,无需每次都使用SDP交互进行密钥协商,通过RTP格式的密钥载荷实现了媒体流密钥的轻量级和实时更新。
本发明实施例还提供一种视频会议媒体流密钥更新设备,包括:
处理器;
存储器,其中存储有所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行所述的视频会议媒体流密钥更新方法的步骤。
通过采用本发明所提供的视频会议媒体流密钥更新设备,所述处理器在执行所述可执行指令时执行所述的视频会议媒体流密钥更新方法,由此可以获得上述视频会议媒体流密钥更新方法的有益效果,即提高了密钥更新的安全性、轻量级、及时性和按需更新性。
本发明实施例还提供一种计算机可读存储介质,用于存储程序,所述程序被执行时实现所述的视频会议媒体流密钥更新方法的步骤。
通过采用本发明所提供的计算机可读存储介质,所述介质中存储的程序被执行时执行所述的视频会议媒体流密钥更新方法,由此可以获得上述视频会议媒体流密钥更新方法的有益效果,即提高了密钥更新的安全性、轻量级、及时性和按需更新性。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显。
图1是本发明一实施例的视频会议媒体流密钥更新方法的流程图;
图2是本发明一实施例的RTP载荷格式的示意图;
图3是本发明一实施例的视频会议媒体流密钥更新系统的结构示意图;
图4是本发明一实施例的视频会议媒体流密钥更新设备的结构示意图;
图5是本发明一实施例的计算机存储介质的结构示意图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的实施方式;相反,提供这些实施方式使得本发明将全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的结构,因而将省略对它们的重复描述。
如图1所示,在本发明一实施例中,所述视频会议媒体流密钥更新方法包括如下步骤:
S100:发送端通过SDP交互与接收端协商密钥载荷更新方式;
S200:需要更新密钥时,所述发送端新建RTP(Real-time Transport Protocol,实时传输协议)格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
S300:所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端;
S400:于所述接收端接收到所述密钥载荷后,所述发送端将所述密钥载荷中承载的密钥确定为更新后的密钥。
通过采用本发明的视频会议媒体流密钥更新方法,首先通过步骤S100基于SDP交互协商密钥载荷更新方法后,在需要更新密钥时,可以直接采用步骤S200和S300,采用专门用于密钥更新的RTP格式的密钥载荷进行密钥更新,因此无需每次都使用SDP交互进行密钥协商。因此,该方法通过RTP格式的密钥载荷实现了媒体流密钥的轻量级和实时更新。
在该实施例中,所述步骤S100:发送端通过SDP交互与接收端协商密钥载荷更新方式,包括如下步骤:
S110:所述发送端在会话描述信息中添加密钥载荷更新方式定义信息;
S120:所述发送端将会话描述信息通过SDP交互发送给所述接收端;
S130:所述发送端接收到所述接收端的密钥载荷反馈信息时,确定密钥载荷协商成功。
在步骤S110中,添加的所述密钥载荷更新方法定义信息可以包括密钥载荷名称、每次更新的最大密钥数和预计更新时长中的一项或多项。
例如,在密钥载荷更新方法中定义载荷名称x-updatekey,任意可以表示此功能的名称都可以被使用。该实例中使用x-updatekey来为了表述方便。还可以进一步定义如下信息:
max-n:每次更新的最大密钥数;
update-time:预计更新时长,单位秒,update-time表示了会议的安全等级,一般的,会议等级分为,由低到高:一会一密钥、N小时一密钥、一分一密钥、一秒一密钥、一包一密钥。
max-n和update-time两个参数是可选的,可以根据需要设置或不增加此两个参数。
在发送端首先向接收端呼叫时,发送端在SDP交互过程增加x-updatekey能力。SDP的发送端和接收端需要进行协商,具体采用RTP会话多路模式,还是SSRC(Synchronizationsource,同步信源(SSRC)标识符)多路模式,接收端需要根据发送端的方式。发送端在SDP交互中还需要为密钥载荷增加rtcp-fb的设置,这样在后续密钥更新时,发送端可以通过接收端的rtcp-fb得知接收方是否接收到了更新的密钥。
接收端在接收到带有x-updatekey能力的会话描述信息时,进行判断,如果支持x-updatekey能力,则再回复所述发送端时带上x-updatekey能力,并且还要带上对x-updatekey载荷的rtcp-fb的ack属性。如果接收端不支持x-updatekey,则接收端的SDP中不带此能力,那么后续密钥更新还是走重新SPD交互的过程。所以经过一次SDP交互就可以确认走哪种密钥更新方式。且此能力的载荷值也已经动态协商完成。
在应用中,基于SDP协议的会话可能会采取两种方式:RTP多路会话模式和SSRC多路模式,这两种模式下,在会话描述信息中可以有不同的密钥载荷更新方式定义信息的添加方式。
在该实施例中,所述步骤S110中,在会话描述信息中添加密钥载荷更新方式定义信息,包括如下步骤:
如果当前采用RTP多路会话模式,在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,所述密钥更新媒体流的描述信息包括密钥载荷的更新方式定义信息。
在该实施例中,所述在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,包括如下步骤:
(1)判断所述会话描述信息中所描述的每路视频会议媒体流采用的密钥是否统一;
(2)如果每路视频会议媒体流采用的密钥统一,在所述会话描述信息中新增一路密钥更新媒体流的描述信息,即只需要在SDP交互中添加一路sendrecv属性的密钥更新媒体流m行即可;
具体地,以一路密钥更新媒体流更新所有视频会议媒体流时,以下面的示例来具体说明:
在所述会话描述信息中,包括一路音频媒体流的描述信息,该音频媒体流的携带能力是opus,载荷值是96;一路视频媒体流的描述信息,该视频媒体流的携带能力是h264,载荷值是98;还有一路密钥更新媒体流的描述信息,该密钥更新媒体流的携带能力x-updatekey,载荷值是99,在SDP的会话描述信息中他们分别对应一路m行。那么99的这路RTP会话就可以用来更新96的音频、98的视频媒体流对应的密钥。
v=0
o=snasnasna 2980675221 2980675778IN IP4 host.example.net
s=-
t=0 0
c=IN IP4 192.0.0.1
m=audio 49170RTP/AVPF 96
a=rtpmap:96opus/48000/2
a=rtcp-fb:96nack
m=video 49174RTP/AVPF 98
a=rtpmap:98H264/90000
a=rtcp-fb:98nack
a=fmtp:98packetization-mode=1;profile-level-id=42e01f
m=application 49178RTP/AVPF 99
a=rtpmap:99x-updatekey/4800
a=fmtp:99max-n=1;update-time=10
a=rtcp-fb:99ack
(3)如果每路视频会议媒体流采用的密钥不统一,针对每路需要更新的视频会议媒体流单独新增一路密钥更新媒体流的描述信息,并建立所述密钥更新媒体流与所对应的视频会议媒体流的关联关系,具体地,需要对每一路视频会议媒体流增加一路密钥更新媒体流m行,且要用FID指令关联对应的mid;如果其他视频会议媒体流属性不是sendrecv(发送接收),那么根据实际场景,可添加更新密钥媒体流的属性为sendonly(仅发送)或者recvonly(仅接收)的属性。
具体地,以一路密钥更新媒体流更新部分视频会议媒体流时,以下面的示例来具体说明:
在所述会话描述信息中,包括一路音频媒体流的描述信息,该音频媒体流的携带能力是opus,载荷值是96,其mid是1;一路密钥更新媒体流的描述信息,该密钥更新媒体流的携带能力x-updatekey,载荷值是97,其mid是2;一路视频媒体流的描述信息,该视频媒体流的携带能力是h264,载荷值是98,其mid是3;一路密钥更新媒体流的描述信息,该密钥更新媒体流的携带能力x-updatekey,载荷值是99,其mid是4;在SDP的会话描述信息中他们分别对应一路m行。Group属性的FID指示了:mid为1和2是一个group(即对应于建立所述密钥更新媒体流与所对应的视频会议媒体流的关联关系),那么97的这路RTP会话就只用来更新音频媒体流,载荷是96的会话。Group属性的FID指示了:mid为3和4是一个group,那么99的这路RTP会话就只用来更新视频媒体流,载荷是98的会话。
v=0
o=snasnasna 2980675221 2980675778IN IP4 host.example.net
s=-
t=0 0
c=IN IP4 192.0.0.1
a=group:FID 1 2
a=group:FID 3 4
m=audio 49170RTP/AVPF 96
a=rtpmap:96opus/48000/2
a=rtcp-fb:96nack
a=mid:1
m=application 49172RTP/AVPF 97
a=rtpmap:97x-updatekey/4800
a=fmtp:97max-n=1;update-time=10
a=rtcp-fb:97ack
a=mid:2
m=video 49174RTP/AVPF 98
a=rtpmap:98H264/90000
a=fmtp:98packetization-mode=1;profile-level-id=42e01f
a=rtcp-fb:98nack
a=mid:3
m=application 49176RTP/AVPF 99
a=rtpmap:99x-updatekey/4800
a=fmtp:99max-n=1;update-time=10
a=rtcp-fb:99ack
a=mid:4
在该实施例中,如果当前采用SSRC多路会话模式,所述在会话描述信息中添加密钥载荷更新方式定义信息,包括在每路需要更新的视频会议媒体流的描述信息中添加密钥载荷的更新方式定义信息。
即当前采用SSRC多路会话模式时,无需在会话描述信息中新增更新密钥收发的媒体流m行,在所述会话描述信息中每一路需要更新密钥的视频会议媒体流m行,增加此载荷能力即可。
具体地,以下面一个示例来具体说明:在所述会话描述信息中,有一路音频媒体流的描述信息,该音频媒体流的携带能力是opus,载荷值是96,携带能力x-updatekey,载荷值是97;一路视频媒体流的描述信息,该视频媒体流的携带能力是h264,载荷值是98,携带能力x-updatekey,载荷值是99;在SDP中的会话描述信息中他们分别对应一路m行。那么在同一个音频流的RTP会话中,就可以使用97的x-updatekey载荷更新此rtp会话的密钥。同理,在同一个视频流的RTP会话中,就可以使用99的x-updatekey载荷更新此rtp会话的密钥。
v=0
o=snasnasna 2980675221 2980675778IN IP4 host.example.net
s=-
t=0 0
c=IN IP4 192.0.0.1
m=audio 49170RTP/AVPF 96 97
a=rtpmap:96opus/48000/2
a=rtcp-fb:96nack
a=rtpmap:97x-updatekey/4800
a=fmtp:97max-n=1;update-time=10
a=rtcp-fb:97ack
m=video 49174RTP/AVPF 98 99
a=rtpmap:98H264/90000
a=rtcp-fb:98nack
a=fmtp:98packetization-mode=1;profile-level-id=42e01f
a=rtpmap:99x-updatekey/4800
a=fmtp:99max-n=1;update-time=10
a=rtcp-fb:99ack
在该实施例中,所述步骤S200中,在所述密钥载荷中添加待更新的密钥,包括如下步骤:
S210:获取待更新的密钥和所述待更新的密钥所更新的视频会议媒体流的SSRC标识,所述待更新的密钥为采用预设加密算法加密的密钥;
由于所述密钥载荷中携带的密钥内容也是加密过的(例如可以通过SRTP方式或其他自定义的加密方式),所以携带的待更新的密钥也是安全传输的;
S220:将所述待更新的密钥和所对应的SSRC标识添加至RTP格式的密钥载荷中。
添加的密钥载荷的格式可以如图3所示。其中,RTP head和标准的RTP格式中的RTP报文头一致。RTP报文头中包括如下信息:
CSRC(特约信源(CSRC)标识符),带的是需要更新的视频会议媒体流的SSRC标识,如果多路媒体流使用的是同样的密钥,而且更新的密钥也都相同,那么可以带多个要更新的多路媒体流CSRC,相应地需要在CC(RTP head中的CSRC计数器)里列出CSRC的个数。如果只更新某一路的媒体流,那么只用带一个CSRC。
Payload type,表示密钥载荷的动态类型,需要在SDP的交互中协商出动态类型,
SN,表示sequence number(序列号),遵循RTP标准从某一个值开始后,每发一次包值就增加1;以及
M,表示掩码位,用来标识此次密钥更新是否结束。
具体地,RTP格式的密钥载荷的格式定义如下:
keyinfo size:表示每一个keyinfo占用的字节数,此处keyinfo表示所述密钥载荷所承载的密钥;
keyinfo Count:此RTP包的keyinfo个数;以及
n*keyinfo:按序排列出更新的keyinfo内容,个数是n。
keyinfo的格式是SDP交互过程中协商的密钥格式,所以其格式、占用字节数等都跟SDP协商的结果一致,可以是SRTP的crypto的格式,或者其他自定义的加密格式。所以本发明的方法中可以使用任意加密格式。
进一步地,在添加密钥载荷时,还需要为更新密钥载荷添加rtcp-fb属性,格式为ack,以使用rtcp的ack来确认后续携带更新密钥的RTP数据包被正确收到。
添加rtcp-fb属性的示例为:rtcp-fb 120ack
其中,120表示携带的密钥更新载荷的动载值。ack表示支持对密钥更新载荷使用rtcp-fb的ack确认机制。具体rtcp-bf的机制可以参照标准文档rfc-4585。
通过所述步骤S300,所述发送端将所述密钥载荷发送到所述接收端之后,所述接收端收到RTP格式的密钥载荷,查看其中的CSRC,并将解密后的更新的密钥/密钥表追加更新到CSRC对应的SSRC媒体流的解密密钥缓冲区里,并回复rtcp-fb的ack包。rtcp-fb的ack包也是加密过的(例如可以通过SRTP方式或其他自定义的加密方式),因此ack包也是安全传输的。
在该实施例中,所述步骤S300中,所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端之后,还包括如下步骤:
S310:所述发送端判断是否接收到所述接收端的密钥载荷反馈信息;
S320:如果是,则所述发送端确认所述接收端接收到所述密钥载荷,此次密钥更新成功,然后继续步骤S400:将所述密钥载荷中承载的密钥确定为更新后的密钥,接下来所述发送端和所述接收端之间的媒体流可以采用更新后的密钥进行加密传输,如果采用SRTP方式,MKI(Master Key Identifier)字段也是使用更新密钥的MKI值,或者自定义的加密方式的值,使用x-updatekey的方式不会影响这些方式,接收端的解密媒体流的过程跟标准的SRTP规定的或者自定义的加解密过程一致;
S330:如果否,则所述发送端确认此次密钥更新失败。
因此,所述发送端可以通过是否接收到所述接收端返回的rtcp-fb包的ack包来决策后续视频会议媒体流是采用更新后的密钥去加密,还是仍采用之前的密钥进行加密,以确保对方可以对接收到的视频会议媒体流解密。
如图3所示,本发明实施例还提供一种视频会议媒体流密钥更新系统,应用于所述的视频会议媒体流密钥更新方法,所述系统包括:
更新协商模块M100,用于通过SDP交互与接收端协商密钥载荷更新方式;
载荷创建模块M200,用于在需要更新密钥时,新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
载荷发送模块M300,用于通过RTP媒体流将所述密钥载荷发送至所述接收端;
更新确认模块M400,用于在所述接收端接收到所述密钥载荷后,将所述密钥载荷中承载的密钥确定为更新后的密钥。
通过采用本发明的视频会议媒体流密钥更新系统,首先通过更新协商模块M100基于SDP交互协商密钥载荷更新方法后,在需要更新密钥时,可以直接采用载荷创建模块M200和载荷发送模块M300,采用专门用于密钥更新的RTP格式的密钥载荷进行密钥更新,因此无需每次都使用SDP交互进行密钥协商。因此,该方法通过RTP格式的密钥载荷实现了媒体流密钥的轻量级和实时更新。
本发明实施例还提供一种视频会议媒体流密钥更新设备,包括处理器;存储器,其中存储有所述处理器的可执行指令;其中,所述处理器配置为经由执行所述可执行指令来执行所述的视频会议媒体流密钥更新方法的步骤。
所属技术领域的技术人员能够理解,本发明的各个方面可以实现为系统、方法或程序产品。因此,本发明的各个方面可以具体实现为以下形式,即:完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等),或硬件和软件方面结合的实施方式,这里可以统称为“电路”、“模块”或“系统”。
下面参照图4来描述根据本发明的这种实施方式的电子设备600。图4显示的电子设备600仅仅是一个示例,不应对本发明实施例的功能和使用范围带来任何限制。
如图4所示,电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于:至少一个处理单元610、至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630、显示单元640等。
其中,所述存储单元存储有程序代码,所述程序代码可以被所述处理单元610执行,使得所述处理单元610执行本说明书上述视频会议媒体流密钥更新处理方法部分中描述的根据本发明各种示例性实施方式的步骤。例如,所述处理单元610可以执行如图1中所示的步骤。
所述存储单元620可以包括易失性存储单元形式的可读介质,例如随机存取存储单元(RAM)6201和/或高速缓存存储单元6202,还可以进一步包括只读存储单元(ROM)6203。
所述存储单元620还可以包括具有一组(至少一个)程序模块6205的程序/实用工具6204,这样的程序模块6205包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
总线630可以为表示几类总线结构中的一种或多种,包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。
电子设备600也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信,还可与一个或者多个使得用户能与该电子设备600交互的设备通信,和/或与使得该电子设备600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且,电子设备600还可以通过网络适配器660与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。网络适配器660可以通过总线630与电子设备600的其它模块通信。应当明白,尽管图中未示出,可以结合电子设备600使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
通过采用本发明所提供的视频会议媒体流密钥更新设备,所述处理器在执行所述可执行指令时执行所述的视频会议媒体流密钥更新方法,由此可以获得上述视频会议媒体流密钥更新方法的有益效果,即提高了密钥更新的安全性、轻量级、及时性和按需更新性。
本发明实施例还提供一种计算机可读存储介质,用于存储程序,所述程序被执行时实现所述的视频会议媒体流密钥更新方法的步骤。在一些可能的实施方式中,本发明的各个方面还可以实现为一种程序产品的形式,其包括程序代码,当所述程序产品在终端设备上运行时,所述程序代码用于使所述终端设备执行本说明书上述视频会议媒体流密钥更新处理方法部分中描述的根据本发明各种示例性实施方式的步骤。
参考图5所示,描述了根据本发明的实施方式的用于实现上述方法的程序产品800,其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码,并可以在终端设备,例如个人电脑上运行。然而,本发明的程序产品不限于此,在本文件中,可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质,该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输,包括但不限于无线、有线、光缆、RF等等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或集群上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
通过采用本发明所提供的计算机可读存储介质,所述处理器在执行所述可执行指令时执行所述的视频会议媒体流密钥更新方法,由此可以获得上述视频会议媒体流密钥更新方法的有益效果,即提高了密钥更新的安全性、轻量级、及时性和按需更新性。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
Claims (9)
1.一种视频会议媒体流密钥更新方法,其特征在于,包括如下步骤:
发送端通过SDP交互与接收端协商密钥载荷更新方式;
需要更新密钥时,所述发送端新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端;
于所述接收端接收到所述密钥载荷后,所述发送端将所述密钥载荷中承载的密钥确定为更新后的密钥;
所述发送端通过SDP交互与接收端协商密钥载荷更新方式,包括如下步骤:
所述发送端在会话描述信息中添加密钥载荷更新方式定义信息,所述密钥载荷更新方式定义信息包括密钥载荷名称;
所述发送端将会话描述信息通过SDP交互发送给所述接收端;
所述在会话描述信息中添加密钥载荷更新方式定义信息,包括如下步骤:
如果当前采用RTP多路会话模式,在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,所述密钥更新媒体流的描述信息包括密钥载荷的更新方式定义信息;或者,
如果当前采用SSRC多路会话模式,在每路需要更新的视频会议媒体流的描述信息中添加密钥载荷的更新方式定义信息。
2.根据权利要求1所述的视频会议媒体流密钥更新方法,其特征在于,所述发送端通过SDP交互与接收端协商密钥载荷更新方式中,所述发送端将会话描述信息通过SDP交互发送给所述接收端之后,包括如下步骤:
所述发送端接收到所述接收端的密钥载荷反馈信息时,确定密钥载荷协商成功。
3.根据权利要求1所述的视频会议媒体流密钥更新方法,其特征在于,所述在会话描述信息中新增一路或多路密钥更新媒体流的描述信息,包括如下步骤:
判断所述会话描述信息中所描述的每路视频会议媒体流采用的密钥是否统一;
如果每路视频会议媒体流采用的密钥统一,在所述会话描述信息中新增一路密钥更新媒体流的描述信息;
如果每路视频会议媒体流采用的密钥不统一,针对每路需要更新的视频会议媒体流单独新增一路密钥更新媒体流的描述信息,并建立所述密钥更新媒体流与所对应的视频会议媒体流的关联关系。
4.根据权利要求1所述的视频会议媒体流密钥更新方法,其特征在于,所述密钥载荷更新方式定义信息还包括每次更新的最大密钥数和/或预计更新时长。
5.根据权利要求1所述的视频会议媒体流密钥更新方法,其特征在于,在所述密钥载荷中添加待更新的密钥,包括如下步骤:
获取待更新的密钥和所述待更新的密钥所更新的视频会议媒体流的SSRC标识,所述待更新的密钥为采用预设加密算法加密的密钥;
将所述待更新的密钥和所对应的SSRC标识添加至RTP格式的密钥载荷中。
6.根据权利要求1所述的视频会议媒体流密钥更新方法,其特征在于,所述发送端通过RTP媒体流将所述密钥载荷发送至所述接收端之后,还包括如下步骤:
所述发送端判断是否接收到所述接收端的密钥载荷反馈信息;
如果是,则所述发送端确认所述接收端接收到所述密钥载荷,并将所述密钥载荷中承载的密钥确定为更新后的密钥。
7.一种视频会议媒体流密钥更新系统,其特征在于,应用于权利要求1至6中任一项所述的视频会议媒体流密钥更新方法,所述系统包括:
更新协商模块,用于通过SDP交互与接收端协商密钥载荷更新方式;
载荷创建模块,用于在需要更新密钥时,新建RTP格式的密钥载荷,在所述密钥载荷中添加待更新的密钥;
载荷发送模块,用于通过RTP媒体流将所述密钥载荷发送至所述接收端;
更新确认模块,用于在所述接收端接收到所述密钥载荷后,将所述密钥载荷中承载的密钥确定为更新后的密钥。
8.一种视频会议媒体流密钥更新设备,其特征在于,包括:
处理器;
存储器,其中存储有所述处理器的可执行指令;
其中,所述处理器配置为经由执行所述可执行指令来执行权利要求1至6中任一项所述的视频会议媒体流密钥更新方法的步骤。
9.一种计算机可读存储介质,用于存储程序,其特征在于,所述程序被执行时实现权利要求1至6中任一项所述的视频会议媒体流密钥更新方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010616110.6A CN111711785B (zh) | 2020-06-30 | 2020-06-30 | 视频会议媒体流密钥更新方法、系统、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010616110.6A CN111711785B (zh) | 2020-06-30 | 2020-06-30 | 视频会议媒体流密钥更新方法、系统、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111711785A CN111711785A (zh) | 2020-09-25 |
CN111711785B true CN111711785B (zh) | 2022-07-05 |
Family
ID=72543906
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010616110.6A Active CN111711785B (zh) | 2020-06-30 | 2020-06-30 | 视频会议媒体流密钥更新方法、系统、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111711785B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112235608B (zh) * | 2020-12-11 | 2021-03-12 | 视联动力信息技术股份有限公司 | 一种基于视联网的数据加密传输方法、装置及介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101110672A (zh) * | 2006-07-19 | 2008-01-23 | 华为技术有限公司 | 通信系统中建立esp安全联盟的方法和系统 |
CN102447690A (zh) * | 2010-10-12 | 2012-05-09 | 中兴通讯股份有限公司 | 一种密钥管理方法与网络设备 |
CN108040269A (zh) * | 2017-12-18 | 2018-05-15 | 西安邮电大学 | 一种视频监控系统密钥协商的方法及系统、计算机 |
CN108965302A (zh) * | 2018-07-24 | 2018-12-07 | 苏州科达科技股份有限公司 | 媒体数据传输系统、方法、装置及存储介质 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8578159B2 (en) * | 2006-09-07 | 2013-11-05 | Motorola Solutions, Inc. | Method and apparatus for establishing security association between nodes of an AD HOC wireless network |
CN102724211B (zh) * | 2012-06-29 | 2014-12-10 | 飞天诚信科技股份有限公司 | 一种密钥协商方法 |
-
2020
- 2020-06-30 CN CN202010616110.6A patent/CN111711785B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101110672A (zh) * | 2006-07-19 | 2008-01-23 | 华为技术有限公司 | 通信系统中建立esp安全联盟的方法和系统 |
CN102447690A (zh) * | 2010-10-12 | 2012-05-09 | 中兴通讯股份有限公司 | 一种密钥管理方法与网络设备 |
CN108040269A (zh) * | 2017-12-18 | 2018-05-15 | 西安邮电大学 | 一种视频监控系统密钥协商的方法及系统、计算机 |
CN108965302A (zh) * | 2018-07-24 | 2018-12-07 | 苏州科达科技股份有限公司 | 媒体数据传输系统、方法、装置及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111711785A (zh) | 2020-09-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
RU2427898C2 (ru) | Защита цифрового мультимедиа с различными типами содержимого | |
JP2023099055A5 (zh) | ||
JP5021639B2 (ja) | ストリーミング用制御プロトコルおよびトランスポートプロトコルを使用した、保護付きコンテンツの搬送 | |
RU2417532C2 (ru) | Доставка обновлений политик для защищенного содержимого | |
CN101370004A (zh) | 一种组播会话安全策略的分发方法及组播装置 | |
CN102281261A (zh) | 一种数据传输方法、系统和装置 | |
EP1271830A2 (en) | Negotiated/dynamic error correction for streamed media | |
US9014369B2 (en) | Voice-over internet protocol (VoIP) scrambling mechanism | |
CN105100134A (zh) | 屏幕共享缓存管理 | |
US20230060066A1 (en) | Data transmission method and apparatus, computer readable medium, and electronic device | |
CN1771706A (zh) | 用于安全并且自适应地传送多媒体内容的方法和设备 | |
CN108881801B (zh) | 视频会议的码流传输方法、系统、电子设备、存储介质 | |
WO2011107000A1 (zh) | 对等网络中的资源控制方法、装置和系统 | |
US10743051B1 (en) | Tuning efficiency and delivery of content | |
CN111711785B (zh) | 视频会议媒体流密钥更新方法、系统、设备及存储介质 | |
EP3541007A1 (en) | Cryptographic communication apparatus, cryptographic communication system, cryptographic communication method and computer-readable medium | |
CN101635919B (zh) | 一种ip多媒体系统会议媒体数据的加密方法及系统 | |
JP2008067102A (ja) | コンテンツ配信サーバ | |
WO2019129125A1 (zh) | 智能眼镜与智能设备交互的方法、系统及存储介质 | |
CN107846567B (zh) | 一种srtp能力协商方法及会议终端 | |
CN114205552A (zh) | 码流加密方法、码流解密方法、装置、电子设备和介质 | |
JP2005295468A (ja) | 通信装置及び通信システム | |
CN114978485B (zh) | 语音数据传输方法、系统、电子设备及存储介质 | |
EP2713576B1 (en) | Method and device for processing streaming media content | |
CN113891107B (zh) | 交互式网络电视无线接入的方法、系统、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |