CN108040071B - 一种VoIP音视频加密密钥动态切换方法 - Google Patents

Abstract

本发明主要披露了一种VoIP音视频加密密钥动态切换方法，用于客户端和服务器端协商双方间的密钥协商，该方法包括：步骤a、客户端和服务器端之间通过媒体层套接字进行密钥的初次协商；步骤b、初次协商完成后得到一组SRTP加密密钥，保存客户端确认信息和所述服务器端确认信息，同时开始进行媒体数据加密传输；步骤c、媒体数据加密传输过程中，由客户端或者服务器端发起重协商，更新客户端确认信息和服务器端确认信息。本发明方案的密钥协商过程都通过媒体层套接字发送，并且支持通信双方以任何方式发起重协商，在加密密钥动态切换前后可以保持会话，无需重新销毁创建媒体通道。

Description

一种VoIP音视频加密密钥动态切换方法

技术领域

本发明属于网络通讯技术，尤其涉及网络通讯中的音视频加密技术。

背景技术

在VoIP媒体通信过程中，媒体数据的安全性显得尤为重要，在VoIP中媒体数据通常采用RTP的方式进行数据的互通，而SRTP（Secure Real-time Transport Protocol）是RTP最为常用的安全传输机制，基于密钥加密RTP数据从而提升安全性。密钥对于SRTP协议至关重要，传输双方的数据都依赖于密钥进行加密，因此密钥的安全性与传输双方的数据安全密切相关。SRTP自身不提供密钥协商，通常采用信令的方式进行交换，并且在一次通话过程中，SRTP关联的密钥是固定不变的。通常信令的交互显的比较笨重及低效，且采用信令交换密钥的方式会影响当前媒体的互通连续性，导致用户体验及友好性欠佳。

若以DTLS（Datagram Transport Layer Security）取代现有的密钥交换方式，可直接通过媒体传输的套接字完成SRTP密钥协商，并在整个通话过程中支持动态的密钥重协商。此密钥的重协商过程可在不影响媒体数据传输的前提下完成，并在重协商完成之后进行新旧密钥替换，从而较好地增强了音视频通信的安全性。

在现有技术方案中，信令层完成SRTP密钥协商之后下发给媒体层，媒体层在创建会话之后用下发的密钥进行数据加密，如图1(a)所示。信令层一般是由发起方直接生成用于加密的密钥，通过SIP协议发送给对端，这种方式依赖于信令层其它数据保护机制，方案本身安全性较低。并且由于音视频SRTP加密在媒体层完成，信令层完成协商之后仍需下发密钥，每次需更换密钥时媒体层会话都会中断，需重新创建媒体通道。

发明内容

本发明的目的在于提供一种VoIP音视频加密密钥动态切换方法，该方法基于DTLS实现SRTP密钥协商与动态重协商，重协商过程中不影响媒体数据连续性。

为了实现上述发明目的，本发明的技术方案如下：一种VoIP音视频加密密钥动态切换方法，用于客户端和服务器端协商双方间的密钥协商，该方法包括：步骤a、客户端和服务器端之间通过媒体层套接字进行密钥的初次协商；步骤b、初次协商完成后得到一组SRTP加密密钥，保存客户端确认信息和所述服务器端确认信息，同时开始进行媒体数据加密传输；步骤c、媒体数据加密传输过程中，由客户端或者服务器端发起重协商，更新客户端确认信息和服务器端确认信息。

优选的，当客户端发起重协商时直接进入握手流程。

优选的，当服务器端发起重协商时，发送重协商请求到所述客户端，然后进入等待重协商状态。

优选的，初次协商和重协商均基于DLTS握手协议实现，同时对DTLS握手协议的record进行扩展，在起始record中增加“使用SRTP”字段。

优选的，客户端的Client Hello扩展字段包含：标志位、SRTP列表长度和客户端所支持的SRTP suites列表；服务器端的Server Hello的扩展字段包含：标志位、长度和服务器端选定的SRTP suite。

优选的，初次协商具体包括以下步骤：步骤a1、客户端通过媒体层套接字发送“第一握手请求”发起协商；步骤a2、服务器端通过媒体层套接字接收到“第一握手请求”解析生成cookie并“请求确认”发送至客户端；步骤a3、客户端收到“请求确认”，获取cookie添加生成“第二握手请求”；步骤a4服务器端收到“第二握手请求”后解析其中suites与本地实际条件匹配选择合适的suite发送给客户端；步骤a5、客户端分析确定是否支持重协商。

优选的，加密密钥动态切换方法还进一步包括DTLS证书验证操作，服务器端在生成自签名证书后通过媒体层套接字发送自签名证书，同时生成第一hash指纹上传到信令层，通过SDP协议发给客户端。

优选的，客户端收到hash指纹后下发到媒体层，并且媒体层接收到自签名证书，用相同hash算法生成第二hash指纹，对比第一hash指纹和第二hash指纹进行身份验证。

优选的，初次协商和重协商过程中在第二握手请求中添加重协商信息，重协商信息包括：类型、长度、数据以及标志位。

优选的，客户端和服务器端之间通过“握手完成”record确认握手过程结束，“握手完成”record是DTLS中第一个加密的数据包，加密密钥由DTLS suite确定，客户端“握手完成”record包含12字节的客户端“确认信息”数据，服务器端则包含12字节服务器端“确认信息”数据。

优选的，SRTP加密密钥根据预定算法结合初次协商的扩展部分计算所得,预定算法是包含在SRTP的套件中。

优选的，重协商具体包括：客户端发送包含重协商信息的“握手请求”开始重新握手；服务器端收到包含重协商的“握手请求”后，直接返回发送“握手请求”；密钥协商完成后，通过“握手完成”record更新两端的“确认信息”，用于下一次重协商时的会话验证。

优选的，重协商具体包括：服务器端发送重协商请求；客户端收到重协请求后验证，直接返回发送“握手请求”；密钥协商完成后，通过“握手完成”record更新两端的“确认信息”，用于下一次重协商时的会话验证。

发明披露了一种VoIP音视频加密密钥动态切换方法，在不影响媒体互通连续性的情况下，完成加密密钥的重协商，进而提高媒体互通的安全性。动态密钥切换不中断通话状态及媒体互通连续性，提高了媒体互通的安全性。

附图说明

图1为现有技术与本发明技术方案的通讯架构示意图;

图2为标准DTLS握手流程示意图；

图3为本发明具体实施例中扩展后的协商流程示意图；

图4为本发明具体实施例中重协商流程示意图。

具体实施方式

本发明的基本原理为: 本方案在媒体层基于DTLS协议完成音视频加密密钥的动态切换，利用DLTS协议安全性保证加密密钥不易泄露，并且实现密钥动态切换时会话不中断。本方案整体结构包含三部分，分别是初次协商、SRTP加密传输和重协商，主要协商过程都在媒体传输层完成，与信令层相关性低。

为了使本发明的目的、技术方案及优点更加清楚明白，下面举例说明，应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

图1为现有技术与本发明技术方案的通讯架构示意图。其中，图1中的 (b)是本发明方案的基本结构。如该图所示，本方案初次协商完成后可得到SRTP加密密钥，此时开始进行媒体数据加密传输。在传输过程中，可由客户端（下文简称client）或服务器端（下文简称server）发起重协商，区别在于client直接进入握手流程，而server则是发送重协商请求到client，然后进入等待重协商状态。

本发明实例提供一种VoIP音视频加密密钥动态切换方法，通过媒体层传输套接字完成SRTP加密密钥的动态切换，该方法基于DTLS握手协议完成密钥的初次协商与动态重协商，获取的密钥用于SRTP加密。DTLS是client/server模式，由client发起初次协商，而重协商可由任一方发起。

图2为标准DTLS握手流程示意图。本发明在协商过程中，其核心是DTLS握手协议（handshake protocol），DLTS握手协议安全性高，完成时首先得到主密钥（master key），之后基于主密钥和算法套件(suite)导出用于数据加解密的密钥。client与server间需要多次通信才能协商出主密钥。握手相关的数据包称之为record。由于DTLS面向非可靠传输，因此其握手协议相较于TLS而言针对丢包、乱序等问题做了相应的优化，以提高协商过程的可靠性与安全性。

标准DLTS握手协议基于DTLS suites列表协商得到48字节的主密钥。为了获取用于媒体数据加密的SRTP密钥，本方案对标准DTLS握手协议的record进行扩展，该对标准DTLS进行相应SRTP扩展，目的是协商出SRTP加密密钥。

图3为本发明具体实施例中扩展后的协商流程示意图。如该图所示，在协商开始时双方需要获知对端是否支持SRTP加密以及所支持的加密套件，因此在协商双方起始record中增加“使用SRTP”字段。发起方与接收方的字段内容略有不同，Client Hello扩展字段包含标志位、SRTP列表长度和client端所支持的SRTP suites列表，每个suite表示一组加密套件，用于指定加密算法和数字签名算法。需注意SRTP suites与前述DTLS suites不相关。Server Hello的扩展字段包含标志位、长度和server端选定的SRTP suite，该suite必须为双方共同支持。为实现通信过程中加密密钥的动态切换，DTLS重协商部分也需进行类似扩展。不同的是，初次协商时各record扩展字段固定，而重协商在不同阶段包含不同内容的扩展字段，将在具体实施流程分析部分阐明。另外，client发的是很多个suite，用“suites列表”的描述，而server选定了一个suite。

本方案的重点在于实现音视频加密密钥动态切换，完整实施流程如图4所示，主要包含初次协商和重协商两部分。图中带星号的步骤可以不执行，其中Certificate Request用于server端发起证书验证请求，client收到之后发送其Certificate到server端。本方案通信双方更接近于对等关系，实际没有明确客户端和服务器端之分，只需在DTLS client端验证DTLS server端的Certificate，因此忽略上述records。

初次协商和重协商共同实现音视频SRTP加密密钥动态切换，具体实施流程如下所述：

步骤S1:客户端（client）通过媒体层套接字发送“握手请求”发起协商，其中包含一个32字节随机数和DTLS suites列表，随机数用于之后的密钥协商，suites列表用于确定密钥协商算法套件。record通过媒体层套接字发送到server端。需注意，该“握手请求”主要作用是cookie验证。

步骤S2:服务器端（server）通过媒体层套接字接收到第一个“握手请求”之后进行解析，保存其中随机数。第一个客户端“握手请求”不包含cookie，server根据client的ip生成cookie，并通过“请求确认”发给client。如果一直未收到客户端“握手请求”导致未发送“请求确认”，客户端超时之后会重新发送“握手请求”，同时将超时时间翻倍，即前文所述超时重传机制。

步骤S3:客户端收到服务器端“请求确认”，获取cookie并添加到“握手请求”重新发送。该“握手请求”标准格式与之前基本相同，由于“握手请求”是一种特定格式的数据包，标准的数据格式不够，所以要进行字段扩展。本发明具体实施例中其增加了收到的cookie字段，用于server端的cookie验证。此时必须包含SRTP扩展字段用于初次协商完成时生成加密密钥。通常加密密钥是在client和server端通过协商过程所获取的信息计算得到，并不包含在任何一个数据包内，也不发送到对端，这样才是安全的。需注意，本方案初次协商和重协商都需要添加重协商信息，前者用于相互验证是否支持重协商，后者用于密钥动态切换时的会话验证。重协商信息主要包括类型、长度、数据以及标志位。对于该record，数据部分必须为1字节0x00，或者整个替换成empty_SCSV（Signaling Cipher Suite Value）（具体内容为{0x00, 0xFF}）。empty_SCSV只能用于该record。

步骤S4:服务器端收到第二个客户端“握手请求”之后进行cookie验证，通过后解析“握手请求”包含的suites与本地实际条件匹配，选择合适的suite通过服务器端“握手请求”发送给对端客户端。同时解析重协商信息，满足步骤S3中所述条件时将当前字段重协商信息的标志位设置为true，同时数据部分必须为1字节0x00。客户端收到之后进行验证，满足条件则表示双方都支持重协商。

步骤S5:进行证书验证。现有技术的DTLS协议一般采用CA验证，通常用于server/client结构）。DTLS的证书采用x509证书格式，每个证书包含签名证书、加密算法、密码。证书类型可分为CA证书和self-signed(自签名)证书，由于本方案主要用于p2p通信，采用自签名证书即可。为实现自签名证书的身份验证，server端在生成自签名证书之后，通过媒体层套接字发送自签名证书，同时生成hash指纹（fingerprint）上传到信令层，通过SDP协议发给对端。对端收到指纹后下发到媒体层，并且媒体层接收到自签名证书，用相同hash算法生成另一个指纹，对比两个指纹即可验证身份。

步骤S6:密钥协商过程。此过程是DTLS本身支持，也是安全机制的核心，所需参数由所选密钥协商算法确定，即由服务器端“握手请求”中所选suite确定。以ECDHE（Elliptical Curve, Diffie-Hellman, Ephemeral signed）为例，EC曲线的类型和参数已经在之前握手过程确定，client和server保存椭圆曲线参数G(x, y)，p，n。

server端根据n生成随机私钥a，取值范围[1, n-1]，之后计算公钥Qs=aG。用server端私钥(RSA生成，对应certificate发送的公钥)对Qs进行签名(SHA)，发送给client的报文包含：曲线类型、公钥Qs(非加密)、签名算法、签名(加密的Qs)。

client取出Qs值和签名算法，用保存的server 公钥进行相同方法签名，与取出的Qs进行验证。之后与server端类似，生成client的私钥b以及公钥Qc，公钥签名后发给server。client和server持有自身私钥、对端公钥及相同参数，(client)bQs=baG=abG=aQc(server)，所以两端可以得到相同的预主密钥（pre-master key）。集合保存的随机数和生成的预主密钥，密钥生成算法可计算得到48字节的主密钥（master key）。主密钥并不直接用于数据加密，而是根据加密算法类型导出匹配的DTLS加密密钥。这里是一个中间步骤，client和server都会先得到预主密钥，并且两端预主密钥相同才是成功的协商，预主密钥不用于加密，会用于生成主密钥。

步骤S7:客户端与服务器端之间通过“改变密码规约”确认密钥协商已经完成。

步骤S8:客户端与服务器端之间通过“握手完成”record确认握手过程结束。“握手完成”record是经过加密的数据包，也是DTLS中第一个经过加密的数据包，此时加密密钥由DTLS suite确定，只用于DTLS records的加密，并不用于媒体数据的SRTP加密。SRTP加密密钥由初次协商的扩展部分计算。一般情况只有得到前面的主密钥，才能进行SRTP加密密钥的计算，也就是SRTP加密密钥基于主密钥和扩展部分约定的suite（理解为方法）才能计算，数据+算法=SRTP密钥。

客户端“握手完成”record包含12字节的客户端“确认信息”数据，服务器端则包含12字节服务器端“确认信息”数据，在本方案实现时两端都需保存这24字节的数据，在重协商时被作为重协商信息中的数据部分，用于认证当前会话，并且可简化重协商的握手流程。

步骤S9:根据客户端与服务器端的随机数，主密钥，以及指定的SRTP加密suite，导出SRTP加密密钥。本方案基于SRTP扩展部分的信息生成两组密钥，client端的sendkey与server端的recvkey相同，而server端的sendkey与client端的recvkey也相同，因此可以确保client端和server可以相互解密对方SRTP加密数据。由此完成初次密钥协商，得到通信双方的SRTP加密密钥，之后对媒体数据进行加密解密操作。本方案SRTP加密密钥只在server端和client端本地生成，并且在协商过程进行多次身份验证，因此一定程度避免密钥被第三方获取，安全性有所提高。

本方案与信令层的主要关联在于传递证书指纹，协商过程的records都通过媒体层套接字发送，并且支持通信双方以任何方式发起重协商，在加密密钥动态切换前后可以保持会话，无需重新销毁创建媒体通道。在发起重协商之前，初次协商已经获得一组SRTP加密密钥，会话双方都保存了两端的“确认信息”。

图4是本发明具体实施例中重协商流程示意图。由该图可知，当客户端发起重协商时，直接发送包含重协商信息的“握手请求”开始重新握手，此时重协商信息的数据部分即为初次协商完成时保存的客户端“确认信息”。当服务器端发起重协商，只需发送重协商请求，客户端收到之后开始重新握手。因此，无论初次协商还是重协商，握手过程实际都从客户端发起。

另外，此处的重协商信息的数据部分与步骤S3中不同，步骤S3时还未完成一次完整协商，所以在初次协商时的重协商信息的数据部分都是1字节0x00）。

步骤S10:当服务器端收到包含重协商的客户端“握手请求”时，由于无需再进行cookie验证，所以直接返回服务器端“握手请求”，其中的重协商信息包含两端的“确认信息”。

步骤S11:客户端收到服务器端“握手请求”后验证重协商信息，若和本地保存信息一致，则确认可以进行重协商，之后的握手过程与初次协商时相似，但不再进行证书验证。

步骤S12:密钥协商完成后，通过“握手完成”record更新两端的“确认信息”，用于下一次重协商时的会话验证。

以上所述流程中，重协商验证是否通过取决于初次协商时的扩展信息，如果初次协商时确定至少有一方不支持重协商，则可以根据当前会话的安全性选择禁止重协商或强制支持重协商。本方案主要用于实现SRTP加密密钥动态切换，默认当前SRTP加密的会话是安全的，因此在该情况下选择支持重协商。

在完成协商之后，会话双方获取到新的SRTP密钥，此时发送方基于新的密钥加密数据，而接收方会尝试用两种密钥解密数据，如果用新密钥解密成功，则表示已接收到新密钥加密的媒体流，此时密钥切换完成，之前的密钥则废弃。整个过程中会话双方可以一直不中断传输。

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

Claims (13)

1.一种VoIP音视频加密密钥动态切换方法，用于客户端和服务器端双方间的密钥协商，其特征在于，该方法包括：步骤a、客户端和服务器端之间通过媒体层套接字进行密钥的初次协商；步骤b、所述初次协商完成后得到一组SRTP加密密钥，对所述SRTP加密密钥分别保存客户端确认信息和服务器端确认信息，同时开始进行媒体数据加密传输；步骤c、所述媒体数据加密传输过程中，由所述客户端或者所述服务器端发起重协商，更新所述客户端确认信息和所述服务器端确认信息。

2.根据权利要求1所述的方法，其特征在于，当所述客户端发起重协商时直接进入握手流程。

3.根据权利要求2所述的方法，其特征在于，当所述服务器端发起重协商时，发送重协商请求到所述客户端，然后进入等待重协商状态。

4.根据权利要求2或3所述的方法，其特征在于，所述初次协商和所述重协商均基于DTLS握手协议实现，同时对DTLS握手协议进行扩展，在起始record的握手协议中增加“使用SRTP”字段。

5.根据权利要求4所述的方法，其特征在于，所述客户端的Client Hello扩展字段包含：标志位、长度和所述客户端所支持的SRTP suites列表；所述服务器端的Server Hello的扩展字段包含：标志位、长度和所述服务器端选定的SRTP suite。

6.根据权利要求5所述的方法,其特征在于,所述初次协商具体包括以下步骤:步骤a1、所述客户端通过媒体层套接字发送“第一握手请求”发起协商；步骤a2、所述服务器端通过媒体层套接字接收到所述“第一握手请求”解析生成cookie并“请求确认”发送至所述客户端；步骤a3、所述客户端收到所述请求确认”,获取cookie添加生成“第二握手请求“；步骤a4所述服务器端收到所述“第二握手请求“后解析其中SRTP suites列表与本地实际条件匹配选择合适的SRTP suite发送给所述客户端；步骤a5、所述客户端分析确定是否支持所述重协商。

7.根据权利要求6所述的方法，其特征在于，所述加密密钥动态切换方法还进一步包括DTLS证书验证操作，所述服务器端在生成自签名证书后通过媒体层套接字发送自签名证书，同时生成第一hash指纹上传到信令层，通过SDP协议发给所述客户端。

8.根据权利要求7所述的方法，其特征在于，所述客户端收到所述hash指纹后下发到媒体层，并且媒体层接收到自签名证书，用相同hash算法生成第二 hash指纹，对比所述第一hash指纹和所述第二hash指纹进行身份验证。

9.根据权利要求8所述的方法，其特征在于，所述初次协商和所述重协商过程中在所述第二握手请求中添加重协商信息，所述重协商信息包括：类型、长度、数据以及标志位。

10.根据权利要求9所述的方法,其特征在于,所述客户端和所述服务器端之间通过“握手完成”record确认握手过程结束,所述“握手完成”record是所述DTLS中第一个加密的数据包，加密密钥由SRTP suite确定，所述客户端“握手完成”record包含12字节的所述客户端“确认信息”数据，所述服务器端则包含12字节所述服务器端“确认信息”数据。

11.根据权利要求10所述的方法，其特征在于，所述SRTP加密密钥根据预定算法结合所述初次协商的扩展部分计算所得，所述预定算法是包含在SRTP suite中。

12.根据权利要求11所述的方法，其特征在于，所述重协商具体包括：所述客户端发送包含重协商信息的“握手请求”开始重新握手；所述服务器端收到所述包含重协商的“握手请求”后，直接返回发送“握手请求”；密钥协商完成后，通过“握手完成”record更新两端的“确认信息”，用于下一次重协商时的会话验证。

13.根据权利要求11所述的方法，其特征在于，所述重协商具体包括：所述服务器端发送重协商请求；所述客户端收到所述重协商请求后验证，直接返回发送“握手请求”；密钥协商完成后，通过“握手完成”record更新两端的“确认信息”，用于下一次重协商时的会话验证。

Images