王鑫　常静坤

摘 要： SIP协议作为IP电话业务和其他各类媒体业务的核心协议，其安全性一直备受关注。包括Osip2和eXosip2等在内的主流SIP协议栈目前只支持基于MD5加解密的摘要认证机制。针对目前大部分协议栈摘要认证过程中加密机制单一的问题，结合eXosip2协议栈，设计了一种简单的基于客户端加密能力的加密协商机制，扩展了SIP协议的摘要认证机制对其他加密方法的灵活支持。通过对改进方案的评估，认为该方案通过修改协议栈内部函数对SIP协议栈进行安全扩展，降低了工作量，避免了对协议栈中其他环节的影响。

关键词： SIP； eXosip2； SIP应用系统； 注册安全； 安全扩展

中图分类号： TN915.08?34； TP3 文献标识码： A 文章编号： 1004?373X（2015）05?0093?04

Research and implementation of EXOSIP2 based SIP register security extension

WANG Xin1， CHANG Jing?kun2

（1. First Research Institute， Ministry of Public Security of PRC， Beijing 100048， China；

2. Department of Computer Science and Technology， Beijing University of Posts and Telecommunications， Beijing 100876， China）

Abstract： SIP （session initiation protocol） is the core protocol of IP telephone business and other media service business. Its security has been fully concerned. The mainstream SIP stack including Osip2 and eXosip2 only supports the digest authorization mechanism based on MD5 encryption and decryption. Aiming at single encryption mechanism in the process of digest authorization of most protocol stacks， a simple encryption negotiation mechanism based on client?side encryption ability was designed in combination with an open source SIP stack named eXosip2. The flexible support for other encryption methods was extended in the SIP digest authorization mechanism. According to the estimation of the improved scheme， the security extension of the SIP stack was carried out by modifying inner function of the protocol stack， which decreased the workload and avoided the influence on other parts of the SIP stack.

Keywords： SIP； eXosip2； SIP application system； register security； security extension

0 引 言

SIP协议作为IETF提出的重要标准，在IP电话业务中起到了至关重要的作用。目前，在基于现有的开源SIP协议栈进行SIP产品开发的过程中，安全问题逐渐突出。而现有的开源协议栈如Osip2和eXosip2等目前只支持基于MD5的加解密认证机制，在开发的过程中，为了满足用户特定的加密需求还需对协议栈进行修改。增加新的加密方法则会大幅增加工作量，同时会对业务流程中的部分环节造成一定影响。

SIP 协议通过文本方式对信令的内容进行表达，易于理解和实现，但也导致SIP 容易被攻击者加以模仿、篡改，加以非法利用。由于SIP协议自身没有专门的安全补充协议和安全机制，需要通过其他手段来保证SIP通信的安全性。在RFC3261中建议了几种SIP安全机制，包括HTTP摘要（Digest）认证、S/MIME安全机制、TLS 安全机制、IPSec 安全机制等[1?2]。其中，HTTP摘要（Digest）认证作为一切安全机制的前提，主要负责认证会话参与者（如用户代理）的身份和验证消息在传输中是否被篡改。只有对会话参与者的身份进行了有效认证，才有可能保障之后通信的安全。

同时，由于SIP中定义了用户代理、代理服务器、转发服务器和登记服务器等中间实体设备，实体间关系复杂。在这些实体间传递的消息容易被攻击者篡改，同时攻击者也容易通过攻击某一实体（如注册服务器）来侵害和干扰整个业务流程。

SIP面临的安全威胁主要包括注册攻击、篡改消息体、伪装服务器、修改或终止会话、拒绝服务与放大攻击等[3]。通常SIP身份认证机制的主要作用包括以下几个方面：

（1） 保障注册安全

通常情况下，任何需要加入SIP系统的用户代理都需要向注册服务器进行注册，登记其联系信息以便其他用户访问。服务器主要通过用户代理的注册请求中的From头域来判断该用户代理是否有权登记或更改其相应的注册地址（contact字段）。而From头域可由用户代理进行任意更改，因此为用户进行恶意注册提供了方便。攻击者可通过修改该头域冒充修改合法用户或取消在线合法用户的注册地址，从而将所有有关合法用户的请求都定向到攻击者设定的地址。并且，也可以通过修改删除所有在线用户的注册信息，导致注册服务器要求所有用户发送注册进行重新认证，从而导致DoS攻击。

通过SIP身份认证机制（通常为HTTP摘要认证机制），当用户首次向注册服务器发送注册请求时，注册服务器可通过返回401（未授权）状态码要求用户提供身份信息并加以认证。由于注册服务器要求用户代理发送自身的认证信息，增大了攻击者伪造用户身份的难度。同时，在消息传输过程中再加以其他加密方式（如TLS等安全协议），攻击者就无法在中途截取消息进行重放等攻击。

（2） 减轻拒绝服务（DoS）攻击

攻击者可以通过修改或删除所有在线用户的注册信息，导致注册服务器要求所有用户发送注册进行重新认证，从而导致DoS攻击。

通过身份认证的方式对注册环节进行保护，攻击者就无法假冒用户身份对当前合法用户的注册信息进行修改或删除，从而避免了因注册攻击导致的DoS攻击。同时通过在路由层对SIP信令的转发过程增加安全认证机制[4]，也可避免其他节点被攻击者利用进行DoS攻击。

（3） 防范篡改消息体

用户代理通过代理服务器进行路由呼叫，恶意的代理服务器可对SIP消息体进行篡改，诱导接收方用户代理做出错误动作（如修改请求重要性或终止会话等）。恶意服务器也可修改SIP消息体中的SDP消息体，引导RTP流指向窃听设备。

针对这种威胁，需要结合机密性检查、完整性检查和身份认证等安全机制对SIP消息体进行保护。防范恶意代理服务器对消息体的篡改，需要用户代理能够对SIP服务器的身份进行有效鉴别[5]。即在用户收到服务器的401（未授权）响应后，在重新发送注册请求时，携带对服务器的身份认证挑战。目前，HTTP摘要认证仅能实现SIP服务器对所管理区域内内用户代理的认证，无法实现用户代理对服务器的认证、服务器对服务器的认证等。同时，HTTP摘要认证协议也存在一些缺陷，容易受到伪装服务器以及离线密码猜测等攻击[6?7]。

面对以上攻击的威胁，需要一种身份认证机制来明确请求者的身份，从而阻止非法用户入侵SIP网络。Kilinc和Yanik对目前现有的身份认证和秘钥协商方案进行了调查，从方案的性能和安全两个关键指标对各种SIP身份认证和密钥协商协议进行了分类和评估[8]。

目前RF3261中推荐使用HTTP摘要（Digest）认证的方式。为了方便有效地扩展SIP流程中的安全认证方案，本文就如何修改协议栈来支持数字证书等其他加解密认证方式提供一个基于注册流程的解决方法，通过它可以为更完备性的安全方案提供一个新的思路。

1 对协议栈注册安全的扩展

1.1 SIP的认证机制概述

SIP本身并没有认证机制，其认证及参考了HTTP、SMTP等协议的摘要认证机制[1]。摘要认证采用挑战（服务器）响应（客户端）模式，但用户名和密码是经过算法（一般是MD5）加密处理的，同时提供一定的完整性检查。

摘要认证机制的注册安全流程如图1所示。挑战的过程为：首先UA向注册服务器发送一条Register请求；注册服务器发现Register请求没有带有认证信息，返回401（未授权）响应要求UA提供认证。其中401响应的WWW?Authenticate头域会带有realm和nonce等参数。

响应的过程为：UA收到401响应后，根据用户名和密码，以及401中带有的realm和nonce进行口令摘要计算出的结果为response。并发送带有Authorization头域和response的第二个Register给注册服务器。注册服务器对Register请求的结果进行验证，如果检查出UA的身份合法，则向UA发送成功响应200OK，如果身份不合法则发送状态码为403的拒绝服务应答。

1.2 注册流程的扩展

在RFC中为摘要定义了两种算法：MD5和MD5?ses[9]，SIP协议中将MD5选为默认加密算法。SIP具体应用时也可使用其他算法，在摘要认证中可通过修改Algorithm字段来定义要使用的加密算法，但若服务器选择的加密算法无法被用户代理识别，则该挑战（challenge）会被忽略。这种SIP的摘要认证机制中用户代理与服务器间无法针对具体的摘要加密方式进行协商。

通过对摘要认证机制的研究，充分利用SIP协议扩展性强的特点，可以对SIP协议进行扩展，对摘要认证机制进行改进，实现客户端与服务器端的数字摘要认证中加密算法的协商机制。扩展协议栈安全机制的思路如下：

对扩展协议栈进行扩展可以实现UA发送第一条Register时携带自身的认证能力，收到401信令后可以根据401中要求的认证方式，进行不同方式的认证处理，并将经过认证的结果放在第二条Register中发送给服务器。这样协议栈不再只支持MD5的摘要认证，而是可以根据注册服务器返回的401中要求的认证方式，进行认证，提高了协议栈在注册安全领域的灵活性和功能性。扩展后的注册安全流程如图2所示。

2 开源协议栈eXosip2的扩展方法

大部分SIP协议栈都是遵循RFC标准进行设计和开发的，包括Osip2和eXosip2在内的很多协议栈普遍只支持基于MD5加解密的认证机制。目前，基于SIP的开源协议栈有很多，而Osip2和eXosip2是使用C语言开发的协议栈中比较好的。这两个协议栈提供了包括IP网络通信、SIP消息的词法、状态的管理等与上层应用程序通信的接口，通过它们可以简单快速地开发出SIP的UA系统。

Osip2作为公开源码的免费协议栈，具有结构简单小巧、应用性强和应用范围广等特点。Osip2主要提供一些解析SIP/sdp消息的API和事务处理状态机，不提供高层SIP会话控制。Osip2支持线程安全，支持多线程和单线程的编程模式。

eXosip2是Osip2的一个扩展协议集，其部分封装了Osip2协议栈，使得它更容易被使用。它实现了作为单个SIP终端所需的大部分功能，如Register、Call、Message等。eXosip2使用通过定时轮询的方式调用Osip2的transaction处理函数，这部分是协议栈运转的核心。它通过添加/读取transaction消息管道的方式，来驱动transaction的状态机，使得来自远端的SIP信令能汇报给调用程序，来自调用程序的反馈能通过SIP信令回传给远端。

2.1 注册请求的扩展

发送带认证能力的Register时，要在注册消息的Authorization头域里增加当前UA支持的认证机制，可调用eXosip协议栈的osip_message_set_authorization（）函数设定。该函数的主要形式为osip_message_set_authorization（register，"Capability algorithm=＼"SHA1＼""）。其中第一个参数register是要发送的注册消息的数据结构指针，类型为osip_message_t；第二个参数为一个字符串，Capability为Authorization头域的auth_type的值，空格后为将algorithm的值设定为SHA1，它代表当前UA支持的加解密算法。以此类推可将欲扩展利用的字段写入Authorization头域，带在第一条注册消息中发送到注册服务器。

协议栈底层会对Authorization头域设定的字段进行检查，这时需要修改协议栈内部的osip_authorization_parse（）和osip_authorization_to_str（）函数，将其中对扩展字段（例如algorithm）处理的部分进行修改即可。

2.2 挑战过程的扩展

对于收到的401信令，在协议栈中的入口函数是eXosip_default_action（），再经过一系列的注册消息构造函数处理，由于这些函数和认证机制没有关系，因此当执行到_eXosip_register_build_register（）函数才来判断401消息中携带的认证要求。

首先根据MSG_IS_STATUS_4XX来确定当前收到的是401信令，然后比较401消息中WWW?Authenticate头域的auth_type字段的值，如果为空则仍然执行协议栈默认的流程，使用摘要认证（MD5）；如果为Asymmetric，则表示使用数字证书的认证方式，开始执行新加入的数字证书认证流程。当然新加入的针对数字证书的函数也是仿照协议栈中原有的针对MD5的函数，只是在加解密和认证结果的处理部分不一样，这样可以最大化地保持原协议栈的代码连续性，还可以实现新的功能。

2.3 响应过程的扩展

如果收到的401信令表明服务器要求的认证机制为数字证书方式，则进入新添加的函数eXosip_add_authentication_information_Asymmetric（）和__eXosip_create_authorization_header_Asymmetric（）来构造数字证书的认证信息。这两个函数主要是仿照eXosip_add_authentication_information（）和__eXosip_create_authorization_header（）来构造的，只不过对于认证的流程和结果处理不同。

这两个函数主要是将认证的结果放入第二条Register消息的Authorization头域中。要放入的值有两种，一种是根据前一个401信令得到或者默认不变的值，例如nonce，algorithm和auth_type字段；另一种就是加解密的结果，如response字段，它由应用层调用加解密模块的接口进行计算，再传递到底层。

由于eXosip2协议栈只在协议栈内部包含了对于MD5算法的代码，因此要想实现数字证书的认证机制，必须通过外部调用加解密模块的接口。

这需要在应用层UA调用eXosip_default_action（）函数之前进行一系列处理，主要包括：

（1） 判断新的事件是否为401事件。

（2） 如果是401事件，则取出收到的401信令的 WWW?Authenticate头域的nonce和algorithm等值。

（3） 将相关的数值以参数的形式传入加解密模块的接口函数中。

（4） 当接口函数返回加解密的结果后，再将该结果通过eXosip_add_authentication_info_Asymmetric（）函数传递到协议栈底层。该函数是仿照eXosip_add _authentication_info（）函数构造的，可以动态设定eXosip2协议栈的jauthinfo_t数据结构的值。

（5） 协议栈执行到eXosip_add_authentication_information _Asymmetric（）函数后，就会调用eXosip_find _authentication_info_Asymmetric（）函数来取出存到jauthinfo_t的加解密结果的值，再将结果的值作为一个参数传递给__eXosip_create_authorization_header_Asymmetric（）函数，最后这个函数就会把这个值设定到第二个Register的Authorization头域的response字段。

（6） 协议栈构造好新的Register后，就会启动底层的通信接口发送第二条带有认证消息的注册。

（7） 注册服务器验证通过，返回200OK，注册成功。

3 方法评估

Osip2和eXosip2协议栈都是基于MD5算法，来进行注册流程过程中的参数检测和加解密结果计算。UA发出Register消息后，对于收到的401，407以及300～399的消息都是通过eXosip_default_action（）函数来处理的。

对于收到的401信令，协议栈默认只是按照MD5情况下的参数设置进行空值检查等操作，如果要扩展使用数字证书等加解密方案，当收到的401信令的WWW?Authenticate头域的值不符合MD5情况下参数设置时，协议栈就会自动停止处理终止整个注册的流程。

同理对于第二条Register，协议栈也有一系列只针对MD5的检查。这样通过简单地改变注册认证中的Authorization和WWW?Authenticate头域的值来扩展新的认证方案就变得不可行。

如果想跳过eXosip_default_action（）函数，自己来对收到的401信令进行处理。不但工作量巨大，而且需要完成很多协议栈内部的处理，还会影响到注册消息的超时重发以及过期自动重新注册等功能。所以本文采用修改协议栈内部函数的办法，主要思想是对401返回的认证要求进行判断，再根据认证的要求按不同的流程进行处理。只需要对于新的认证方案添加一系列相应的处理函数，完成加解密和重发Register的流程即可，从而保证了协议栈其他部分的运行不受任何影响，如同为协议栈打上一个新的补丁。

协议栈修改前后对于注册流程的变化如图3所示。

4 结 语

SIP协议的摘要认证机制单一，在基于SIP协议栈进行开发的过程中，很多情况下都需要针对特定用户的需求进行安全扩展。本文在SIP协议栈的安全应用方面，以eXosip2协议栈作为研究对象，对SIP协议栈安全机制扩展的思路和实现方法进行了探索，提出了修改现有协议栈来实现数字证书的认证机制的具体方法，主要包括协议栈注册流程的改进和对应注册流程中请求、判断以及加解密等环节的修改方法。通过评估，认为该方案通过修改协议栈内部函数的方法，降低了对SIP协议栈进行安全扩展所需的工作量，避免了对协议栈中其他环节的影响。本文为SIP领域中的其他研究或开发人员提供了一些具体的方法和思路，具有一定的借鉴意义。

参考文献

[1] ROSENBERG J， SCHULZRINNE H. SIP： session initiation protocol RFC3261 [S]. [S.l.]： [s.n.]， 2002.

[2] 陈昌鹏，晋磊，陈凯，等.SIP协议的安全分析[J].计算机应用与软件，2007，24（8）：172?174.

[3] 储泰山，潘雪增.SIP 安全模型研究及实现[J].计算机应用与软件，2004，21（12）：101?104.

[4] 张金玲，廉东本，李想.基于SIP的信令安全网关安全模块[J].计算机系统应用，2014，23（4）：189?192.

[5] 王庆年，徐皓.IP协议Digest认证研究[J].舰船电子工程，2013，23（1）：23?24.

[6] 赵跃华，刘申君.会话初始协议安全认证机制的分析与改进[J].计算机工程，2011，37（20）：114?116.

[7] 彭焕峰.一种基于改进的HTTP摘要认证的SIP安全机制[J].微型机与应用，2011，30（6）：53?55.

[8] KILINC H H， YANIK T. A survey of SIP authentication and key agreement schemes [J]. IEEE Communications Surveys & Tutorials， 2014， 16（2）： 1005?1023.

[9] RIVEST R. The MD5 message?digest algorithm RFC1321 [S]. [S.l.]： [s.n.]， 1992.