Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1576565
  • 博文数量: 239
  • 博客积分: 1760
  • 博客等级: 上尉
  • 技术积分: 1595
  • 用 户 组: 普通用户
  • 注册时间: 2011-01-08 23:53
文章分类

全部博文(239)

文章存档

2016年(1)

2015年(28)

2014年(53)

2013年(42)

2012年(50)

2011年(65)

分类: LINUX

2015-08-28 11:53:42

原文地址:SRTP/SRTCP协议介绍 作者:poseidonqiu

一 概述
随着网络技术的发展和标准的制定,实时音频、视频的应用越来越广泛,这 些应用反过来又促进了相关协议标准的发展。1996年IETF在RFC1889中定义 了传输实时数据的Internet标准协议RTP,并在2003年制定了升级版本RFC3550。 由于网络安全问题日益突出,2004年3月IETF在RFC3711中定义了RTP的一 个扩展协议SRTP来提高RTP应用的安全性,SRTP定义了对RTP与RTCP流进 行加密、认证以及抗重播攻击检测等的实现框架。

二 简介
SRTP & SRTCP
安全实时传输协议 (Secure Real-time Transport Protocol或SRTP)是在实时传输协议(Real-time Transport Protocol或RTP)基础上所定义的一个协议,旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由 David Oran(思科)和Rolf Blom(爱立信)开发的,并最早由IETF于2004年3月作为RFC 3711发布。

由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议(RTP Control Protocol或RTCP)有着紧密的联系,安全实时传输协议同样也有一个伴生协议,它被称为安全实时传输控制协议(Secure RTCP或SRTCP);安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性,就像安全实时传输协议为实时传输协议提供的那些一样。

在使用实时传输协议或实时传输控制协议时,使不使用安全实时传输协议或安全实时传输控制协议是可选的;但即使使用了安全实时传输协议或安全实时传输 控制协议,所有它们提供的特性(如加密和认证)也都是可选的,这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时,必须要用到其 消息认证特性。


为了提供对数据流的保密,需要对数据流进行加密和解密。关于这一点,安全实时传输协议(结合安全实时传输控制协议)只为一种加密算法,即AES制定了使用标准。这种加密算法有两种加密模式,它们能将原始的AES块密文转换成流密文:分段整型计数器模式和f8模式。

除了AES加密算法,安全实时传输协议还允许彻底禁用加密,此时使用的是所谓的“零加密算法”。它可以被认为是安全实时传输协议支持的第二种加密算法,或者说是它所支持的第三种加密模式。事实上,零加密算法并不进行任何加密,也就是说,加密算法把密钥流想像成只包含“0”的流,并原封不动地将输入流复制到输出流。这种模式是所有与安全实时传输协议兼容的系统都必须实现的,因为它可以被用在不需要安全实时传输协议提供保密性保证而只要求它提供其它特性(如认证和消息完整性)的场合。

以上列举的加密算法本身并不能保护消息的完整性,攻击者仍然可以伪造数据——至少可以重放过去传输过的数据。因此,安全实时传输协议标准同时还提供了保护数据完整性以及防止重放的方法。

为了进行消息认证并保护消息的完整性,安全实时传输协议使用了HMAC-SHA1算法。这种算法使用的是默认160位长度的HMAC-SHA1认证密钥。但是它不能抵御重放攻击;重放保护方法建议接收方维护好先前接收到的消息的索引,将它们与每个新接收到的消息进行比对,并只接收那些过去没有被播放过的新消息。这种方法十分依赖于完整性保护的使用(以杜绝针对消息索引的欺骗技术)


三 协议的数据报文结构

数据报文包括包头、数据主体以及认证信息三个部分。

(1)32bits:

V 2bits    版本号,现在已经是版本2

P 1bit 填充位,当负载的长度不够32bits的整数倍时,需要填充位

X 1bit 扩展位,若为1,则固定的包头后增加一个32bits的扩展(rtp extension)

CC 4bits CSRC的数目

M 1bit 允许在比特流中标记重要的事件

PT 7bits 负载类型

序列号16bits   每发送一个RTP数据包,序列号加1,根据此来判断序列号的顺序

(2)时间戳 32bits

(3)SSRC标识符 32bits synchronizating source identifier 识别同步源

(4)CSRC标识符 n个32bits contributing source identifiers 识别负载重的有效贡献源

(5)可选存在的RTP extension

(6)加密的payload(末尾可能包含RTP padding和RTP pad count)

(7)包尾是SRTP MKI(可选),master key identifier,是用来生成session加密密钥的随机位串标识符。

(8)认证标签(Authentication tag)

与RTP包的主要区别是负载加密、SRTP MKI(主密钥标识符,由密钥管理协议决定)、认证标签。

3、协议的工作流程

(1)协议中涉及哪些密钥和重要参数

主密钥 master key

主密钥是一个长度不定的随机位串,用来生成会话密钥

会话密钥 session key

会话密钥就是用于消息加密和认证的密钥

master salt 不知道怎么翻译

salt是指一种在生成会话密码时的输入参数,salt增加了字典式攻击的难度,每增加1bit的salt,就会使字典攻击的难度和时间翻倍。

key_derivation_rate

生成会话密钥的速率,必须是{124……2^24}中的一个,必须为2的幂数

这是两个48bits的时间值,表示master key的有效时间。

ROC(rollover counter)

记录序列号的重置次数,用来计算SRTP包的索引

Index = 2^16 * ROC + SEQ

(2)会话密钥的产生


在协议中,密钥生成过程的描述是通过数学函数来说明的,如下:

key_session = PRF (key_master, x);

r = index/key_derivation_rate;;//label长度8位

key_id =

x = key_id XOR master salt;

PRF是一个AES-cm的对称加密函数。

用框图表示,如下:


其中,IV=[

index=2^16*ROC+SEQ

对于生成的不同密钥,8位的label有不同的值:

session_en_key:消息加密密钥,

session_au_key:消息认证密钥,

session_salt_key:会话salt,

(3)具体工作流程

得到会话密钥后,就可以对消息载荷进行安全操作了。

发送方工作流程:

1)确定加密上下文

2)根据ROC、加密上下文中的最高序列号以及RTP包中的序列号,确定SRTP包索引

index=2^16*ROC+SEQ

3)根据index确定master_key和master_salt(需要密钥管理协议)

4)根据密钥管理协议中的各个参数,通过密钥生成器,得到会话密钥

5)利用会话密钥和传输参数设定,对载荷进行加密,作为数据包中的加密载荷

6)如果MKI字段为1,则加入MKI字段

7)计算认证标签,并加在包尾

8)更新ROC和数据包索引

接收端流程

1)确定加密上下文

2)计算包索引

index=2^16*v+SEQ

v={ROC-1,ROC,ROC+1}/2^32

3)如果MKI字段为1,则根据MKI确定主密钥和主密钥salt,否则用index确定主密钥和salt

4)得到会话密钥

5)重播检查,利用index和重播列表来检查重播,如果为重播数据包,则丢弃,并记录log。

执行认证过程,如果不匹配,则丢弃,并记录log。

6)利用会话密钥解密数据载荷

7)根据index,更新ROC、最大序列号、加密上下文中的s_l值,需要时更新重播列表。

8)从数据包中删除MKI和认证标签。


阅读(7868) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~