一种基于srtp的密钥协商方法
【专利摘要】本发明公开了一种基于SRTP的密钥协商方法，包括发送方检索其支持的AES算法模式，并按加密有效性排序；对各AES算法模式使用随机函数生成相应的密钥；将各AES算法模式及对应的密钥，按密钥协商帧格式封装成密钥协商请求消息数据包并发送给接收方；接收方按照协商请求消息中列出的AES算法模式的顺序，检测其是否支持其中一种模式；接收方将其支持的AES算法模式及对应的密钥，按密钥协商帧格式封装成回复消息数据包并发送给发送方；若回复消息中包含发送方支持的任何一种AES算法模式及对应的密钥，则密钥协商成功；否则密钥协商失败。本发明可提高SRTP的密钥安全性，进而提高SRTP的安全性和实用性。
【专利说明】—种基于SRTP的密钥协商方法
【技术领域】
[0001]本发明涉及一种基于SRTP的密钥协商方法，属于信息安全【技术领域】。
【背景技术】
[0002]实时传输协议RTP(Real-time Transport Protocol)详细规定了互联网上实时传输音频、视频数据的标准数据包格式，满足了实时音频、视频的应用需求。随着网络安全问题的日益突出，为保证实时传输数据的安全性和完整性，安全实时传输协议SRTP (SecureReal-time Transport Protocol)应运而生,它是在RTP基础上定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。
[0003]SRTP的帧格式与RTP类似，只是在RTP数据包的最后增加了主密钥标识和认证标签，即增加了加密和认证功能。这样，SRTP 一方面可以对RTP的有效负载进行AES加密以防止RTP有效负载的暴露，另一方面也可以对整个RTP数据包进行认证以防止重放攻击。
[0004]但是，由于SRTP的密钥一般是通过会话描述协议SDP(Session DescriptionProtocol)进行协商的，而SDP本身并没有得到保护，所以SRTP的密钥也就没有得到真正的保护，这也将导致SRTP的加密及认证失去意义。
【发明内容】
[0005]鉴于上述问题，本发明的目的在于提供一种基于SRTP的密钥协商方法，通过对SRTP的密钥协商过程进行保护，提高SRTP的密钥安全性，从而保证RTP数据包的安全性。
[0006]为实现上述目的，本发明采用以下技术方案:
[0007]一种基于SRTP的密钥协商方法，包括以下步骤:
[0008]I)发送方检索自身支持的AES算法模式，并对检索出的AES算法模式按照加密有效性进行排序；
[0009]2)针对排序好的AES算法模式，使用随机函数，产生出相应格式的密钥；
[0010]3)将排序好的AES算法模式及对应各模式产生出的密钥,按照密钥协商帧格式，封装成密钥协商请求消息数据包；
[0011]4)发送方向接收方发送该密钥协商请求消息；
[0012]5)接收方接收到该密钥协商请求消息，按照协商请求消息中列出的AES算法模式的顺序，检测其是否支持其中一种模式；
[0013]6)接收方将其支持的AES算法模式及对应生成的密钥，按照密钥协商帧格式封装成回复消息数据包，如果接收方不支持所述密钥协商请求消息中任何一种AES算法模式，则回复消息数据包中不包含任何算法和密钥的信息；
[0014]7)接收方向发送方发送该回复消息；
[0015]8)发送方接收到该回复消息，如果该回复消息中包含发送方所支持的任何一种AES算法模式及该模式对应的密钥，则密钥协商成功；否则密钥协商失败。
[0016]进一步地:[0017]所述的基于SRTP的密钥协商方法，还包括步骤:
[0018]9)如果密钥协商成功，发送方和接收方使用协商好的AES算法模式，按照SRTP的协议流程进行通信；如果密钥协商失败，发送方和接收方可以按照RTP的协议流程进行通信，也可以结束通信。
[0019]所述AES算法是指AES加密算法及HMAC_SHA1认证算法。
[0020]所述AES 算法模式包括 AES_CM_128_HMAC_SHA1_80、AES_CM_128_HMAC_SHA1_32 及F8_128_HMAC_SHAl_80o
[0021]所述密钥协商帧格式包括接收方IP地址、端口号，发送方IP地址、端口号、AES算法模式及密钥信息。
[0022]本发明的优点在于:
[0023]1、利用本发明可保证SRTP密钥协商过程的安全性，从而保证SRTP密钥的安全性；
[0024]2、由于提高了 SRTP密钥的安全性，SRTP对RTP有效负载的加密及对整个RTP包的认证功能也就得到了保证，大大提高了 SRTP的实用性；
[0025]3、由于保证了 SRTP的加密及认证功能，从而最大程度的增加了 RTP有效负载的保密性。
【专利附图】
【附图说明】
[0026]图1是本发明基于SRTP的密钥协商方法的流程图；
[0027]图2是本发明基于SRTP的密钥协商过程的时序图；
[0028]图3是本发明的密钥协商帧格式；
[0029]图4是应用本发明的基本拓扑图。
【具体实施方式】
[0030]以下结合附图和实施例对本发明作进一步详细的说明。
[0031]图1是本发明基于SRTP的密钥协商方法的流程图，图2是本发明基于SRTP的密钥协商过程的时序图，如图所示，该密钥协商方法包括以下步骤:
[0032]SlO:发送方检索自身支持的AES算法模式，并对检索出的AES算法模式按照加密有效性进行排序；
[0033]由于SRTP使用AES算法，所以本发明的基于SRTP的密钥协商方法同样遵从AES算法(这里的AES算法是指AES加密算法及HMAC_SHA1认证算法)。该AES算法包括三种模式:AES_CM_128_HMAC_SHA1_80、AES_CM_128_HMAC_SHA1_32 及 F8_128_HMAC_SHA1_80，根据密钥强度的不同，三种模式的加密有效性从高到低排序为:AES_CM_128_HMAC_SHA1_80，AES_CM_128_HMAC_SHA1_32, F8_128_HMAC_SHA1_80 (其中，AES_CM_128_HMAC_SHA1_80 表示使用带有128位AES的counter模式加密算法以及带有80位的HMAC-SHA1认证算法，AES_CM_128_HMAC_SHA1_32表示使用带有128位AES的counter模式加密算法以及带有32位的HMAC-SHAI认证算法，F8_128_HMAC_SHA1_80表示使用带有128位AES的f8模式加密算法以及带有80位的HMAC-SHA1认证算法)。
[0034]Sll:针对排序好的AES算法模式，使用随机函数，产生出相应格式的密钥；[0035]随机函数为可随机产生出字母、数字、其他字符及其组合字符串的函数，三种模式可使用相同的随机函数，只需设置不同的随机函数参数，即可产生出不同长度和格式的密钥字符串。
[0036]以AES_CM_128_HMAC_SHA1_80为例，对于AES_CM_128加密算法而言，利用随机函数可生成由128位主密钥和112位从密钥组成的240位(30个字节)密钥串，该密钥串经过base64编码后，形成40个字节的协商密钥；对于HMAC_SHA1_80认证算法来说，其中80是以80位为单位，对接收的或者发送的rtp包进行认证，并不产生密钥串，最终，本发明中所涉及到的三种模式的密钥串长度是一致的。
[0037]S12:将排序好的AES算法模式及对应各模式产生出的密钥，按照密钥协商帧格式，封装成密钥协商请求消息数据包；
[0038]图3是本发明的密钥协商帧格式，如图所示，按照该密钥协商帧格式，密钥协商请求消息中包括消息类型，接收方的IP地址、端口号，发送方的IP地址、端口号，发送方支持且已排序的AES算法模式及各模式对应的密钥。
[0039]S13:发送方向接收方发送该密钥协商请求消息；
[0040]S14:接收方接收到该密钥协商请求消息，按照协商请求消息中列出的AES算法模式的顺序，检测其是否支持其中一种模式；
[0041]检测某种模式时，若接收方同样支持该模式，则不再向下检测，直接按照该模式及随机函数生成相应的密钥；如果不支持该模式，则按照顺序继续检测下一种模式；如果不支持任何一种模式，则不产生任何密钥；
[0042]S15:接收方将其支持的AES算法模式及对应生成的密钥，按照密钥协商帧格式封装成回复消息数据包，如果接收方不支持任何AES算法模式，则回复消息数据包中不包含任何算法和密钥的信息；
[0043]S16:接收方向发送方发送该回复消息；
[0044]S17:发送方接收到该回复消息，如果该回复消息中包含发送方所支持的任何一种AES算法模式及该模式对应的密钥，则密钥协商成功；否则密钥协商失败；
[0045]S18:如果密钥协商成功，发送方和接收方使用协商好的AES算法模式，按照SRTP的协议流程进行通信；如果密钥协商失败，发送方和接收方可以按照RTP的协议流程进行通信，也可以结束通信。
[0046]以下结合一具体实施例对本发明的基于SRTP的密钥协商方法进行详细说明。
[0047]图4是应用本发明的基本拓扑图。如图所示，假设IP话机A与IP话机B要进行基于SRTP的会话。其中，IP话机A的IP地址为192.168.1.2，端口号为20000，其支持三种AES 算法模式:即 AES_CM_128_HMAC_SHA1_80、AES_CM_128_HMAC_SHA1_32 及 F8_128_HMAC_SHA1_80 ；
[0048]IP话机B的IP地址为192.168.1.3，端口号为30000，其仅支持一种AES算法模式，即 AES_CM_128_HMAC_SHA1_80。
[0049]若IP话机A为主叫方，IP话机B为被叫方，按照本发明的密钥协商方法，IP话机A与IP话机B的密钥协商过程如下:
[0050]I) IP话机A检索到其共支持三种AES算法模式，并按加密有效性由高到低对这三种AES 算法模式进行排序:算法I为AES_CM_128_HMAC_SHA1_80，算法2为AES_CM_128_HMAC_SHA1_32，算法 3 为 F8_128_HMAC_SHA1_80 ；
[0051]2)对于算法1:AES_CM_128_HMAC_SHA1_80，使用随机函数，产生出密钥1:WVNfX19zZffIj dGwgKCkgewkyMjA7 fQp9CnVubGVz|2'20 1:4；
[0052]对于算法2:AES_CM_128_HMAC_SHA1_32,使用随机函数，产生出密钥2:MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm 2~2θ|1:4 ；
[0053]对于算法3:F8_128_HMAC_SHA1_80,使用随机函数，产生出密钥3 =QUJjZGVmMTIzNDU2Nz g5QUJDREUwMTIzNDU2Nz g5|2~20|2:4。
[0054]3)按照密钥协商帧格式，IP话机A生成如下的密钥协商请求消息:
[0055]INVITE 192.168.1.330000192.168.1.220000
[0056]1AES_CM_128_HMAC_SHA1_80
[0057]WVNfX19zZffljdGwgKCkgewkyMjA7fQp9CnVubGVz 2~2θ|1:4
[0058]2AES_CM_128_HMAC_SHA1_32
[0059]MTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5QUJjZGVm 2~20|1:4
[0060]3F8_128_HMAC_SHA1_80
[0061]QUJj ZGVmMTIzNDU2Nz g5QUJDREUwMTIzNDU2Nz g5|2~20|2:4
[0062]4) IP话机A向IP话机B发送步骤3)中生成的密钥协商请求消息；
[0063]5) IP话机B接收到该密钥协商请求消息，将按照算法1、算法2、算法3的顺序检测其支持哪种模式。检测算法I时发现其支持该模式，则不再检测算法2和算法3，而是直接按照算法I及随机函数产生出密钥4:
[0064]SluQCVeeCFCanVmcjkpPywjNWhcYDOmXXtxaVBR 2~20|1:4 ；
[0065]6)按照密钥协商帧格式，IP话机B生成如下的回复消息:
[0066]ACK 192.168.1.220000192.168.1.330000
[0067]1AES_CM_128_HMAC_SHA1_80
[0068]S IuQCVeeCFCanVmcjkpPywjNWhcYDOmXXtxaVBR 2~2θ|1:4
[0069]7) IP话机B向IP话机A发送步骤6)中生成的回复消息；
[0070]8) IP话机A接收到该回复消息，检测到该回复消息中包含其支持的算法I及密钥4，则密钥协商成功；
[0071 ] 9)后续IP话机A与IP话机B使用协商好的AES算法模式，按照SRTP的协议流程进行通话。
[0072]本发明是通过通信双方对SRTP密钥进行协商，即发送方向接收方发送密钥协商请求消息，该请求消息中携带有发送方支持的AES算法模式及密钥，接收方收到该密钥协商请求消息，检测其支持的AES算法模式并生成相应的密钥，并向发送方发送回复消息，若通信双方有共同支持的算法模式，则密钥协商成功，后续使用协商好的AES算法模式按照SRTP流程通信。本发明可提高SRTP密钥的安全性，进而提高SRTP的安全性和实用性。
[0073]以上所述是本发明的较佳实施例及其所运用的技术原理，对于本领域的技术人员来说，在不背离本发明的精神和范围的情况下，任何基于本发明技术方案基础上的等效变换、简单替换等显而易见的改变，均属于本发明保护范围之内。
【权利要求】
1.一种基于SRTP的密钥协商方法，包括以下步骤: 1)发送方检索自身支持的AES算法模式，并对检索出的AES算法模式按照加密有效性进行排序； 2)针对排序好的AES算法模式，使用随机函数，产生出相应格式的密钥； 3)将排序好的AES算法模式及对应各模式产生出的密钥,按照密钥协商帧格式,封装成密钥协商请求消息数据包； 4)发送方向接收方发送该密钥协商请求消息； 5)接收方接收到该密钥协商请求消息,按照协商请求消息中列出的AES算法模式的顺序，检测其是否支持其中一种模式； 6)接收方将其支持的AES算法模式及对应生成的密钥，按照密钥协商帧格式封装成回复消息数据包，如果接收方不支持所述密钥协商请求消息中任何一种AES算法模式，则回复消息数据包中不包含任何算法和密钥的信息； 7)接收方向发送方发送该回复消息； 8)发送方接收到该回复消息，如果该回复消息中包含发送方所支持的任何一种AES算法模式及该模式对应的密钥，则密钥协商成功；否则密钥协商失败。
2.根据权利要求1所述的一种基于SRTP的密钥协商方法,其特征在于:所述的基于SRTP的密钥协商方法，还包括步骤: 9)如果密钥协商成功，发送方和接收方使用协商好的AES算法模式，按照SRTP的协议流程进行通信；如果密钥协商失败，发送方和接收方可以按照RTP的协议流程进行通信，也可以结束通信。
3.根据权利要求2所述的一种基于SRTP的密钥协商方法，其特征在于:所述AES算法是指AES加密算法及HMAC SHAl认证算法。
4.根据权利要求3所述的一种基于SRTP的密钥协商方法，其特征在于:所述AES算法模式包括 AES_CM_128_HMAC_SHA1_80、AES_CM_128_HMAC_SHA1_32 及 F8_128_HMAC_SHAl_80o
5.根据权利要求4所述的一种基于SRTP的密钥协商方法，其特征在于:所述密钥协商帧格式包括接收方IP地址、端口号，发送方IP地址、端口号、AES算法模式及密钥信息。
【文档编号】H04L29/06GK103685181SQ201210339502
【公开日】2014年3月26日 申请日期:2012年9月13日 优先权日:2012年9月13日
【发明者】崔弘睿 申请人:北京大唐高鸿软件技术有限公司