基于eXosip2下SIP注冊安全擴展的研究與實現(xiàn)

王鑫　常靜坤

摘 要： SIP協(xié)議作為IP電話業(yè)務(wù)和其他各類媒體業(yè)務(wù)的核心協(xié)議，其安全性一直備受關(guān)注。包括Osip2和eXosip2等在內(nèi)的主流SIP協(xié)議棧目前只支持基于MD5加解密的摘要認證機制。針對目前大部分協(xié)議棧摘要認證過程中加密機制單一的問題，結(jié)合eXosip2協(xié)議棧，設(shè)計了一種簡單的基于客戶端加密能力的加密協(xié)商機制，擴展了SIP協(xié)議的摘要認證機制對其他加密方法的靈活支持。通過對改進方案的評估，認為該方案通過修改協(xié)議棧內(nèi)部函數(shù)對SIP協(xié)議棧進行安全擴展，降低了工作量，避免了對協(xié)議棧中其他環(huán)節(jié)的影響。

關(guān)鍵詞： SIP； eXosip2； SIP應(yīng)用系統(tǒng)； 注冊安全； 安全擴展

中圖分類號： TN915.08?34； TP3 文獻標(biāo)識碼： 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協(xié)議作為IETF提出的重要標(biāo)準(zhǔn)，在IP電話業(yè)務(wù)中起到了至關(guān)重要的作用。目前，在基于現(xiàn)有的開源SIP協(xié)議棧進行SIP產(chǎn)品開發(fā)的過程中，安全問題逐漸突出。而現(xiàn)有的開源協(xié)議棧如Osip2和eXosip2等目前只支持基于MD5的加解密認證機制，在開發(fā)的過程中，為了滿足用戶特定的加密需求還需對協(xié)議棧進行修改。增加新的加密方法則會大幅增加工作量，同時會對業(yè)務(wù)流程中的部分環(huán)節(jié)造成一定影響。

SIP 協(xié)議通過文本方式對信令的內(nèi)容進行表達，易于理解和實現(xiàn)，但也導(dǎo)致SIP 容易被攻擊者加以模仿、篡改，加以非法利用。由于SIP協(xié)議自身沒有專門的安全補充協(xié)議和安全機制，需要通過其他手段來保證SIP通信的安全性。在RFC3261中建議了幾種SIP安全機制，包括HTTP摘要（Digest）認證、S/MIME安全機制、TLS 安全機制、IPSec 安全機制等[1?2]。其中，HTTP摘要（Digest）認證作為一切安全機制的前提，主要負責(zé)認證會話參與者（如用戶代理）的身份和驗證消息在傳輸中是否被篡改。只有對會話參與者的身份進行了有效認證，才有可能保障之后通信的安全。

同時，由于SIP中定義了用戶代理、代理服務(wù)器、轉(zhuǎn)發(fā)服務(wù)器和登記服務(wù)器等中間實體設(shè)備，實體間關(guān)系復(fù)雜。在這些實體間傳遞的消息容易被攻擊者篡改，同時攻擊者也容易通過攻擊某一實體（如注冊服務(wù)器）來侵害和干擾整個業(yè)務(wù)流程。

SIP面臨的安全威脅主要包括注冊攻擊、篡改消息體、偽裝服務(wù)器、修改或終止會話、拒絕服務(wù)與放大攻擊等[3]。通常SIP身份認證機制的主要作用包括以下幾個方面：

（1） 保障注冊安全

通常情況下，任何需要加入SIP系統(tǒng)的用戶代理都需要向注冊服務(wù)器進行注冊，登記其聯(lián)系信息以便其他用戶訪問。服務(wù)器主要通過用戶代理的注冊請求中的From頭域來判斷該用戶代理是否有權(quán)登記或更改其相應(yīng)的注冊地址（contact字段）。而From頭域可由用戶代理進行任意更改，因此為用戶進行惡意注冊提供了方便。攻擊者可通過修改該頭域冒充修改合法用戶或取消在線合法用戶的注冊地址，從而將所有有關(guān)合法用戶的請求都定向到攻擊者設(shè)定的地址。并且，也可以通過修改刪除所有在線用戶的注冊信息，導(dǎo)致注冊服務(wù)器要求所有用戶發(fā)送注冊進行重新認證，從而導(dǎo)致DoS攻擊。

通過SIP身份認證機制（通常為HTTP摘要認證機制），當(dāng)用戶首次向注冊服務(wù)器發(fā)送注冊請求時，注冊服務(wù)器可通過返回401（未授權(quán)）狀態(tài)碼要求用戶提供身份信息并加以認證。由于注冊服務(wù)器要求用戶代理發(fā)送自身的認證信息，增大了攻擊者偽造用戶身份的難度。同時，在消息傳輸過程中再加以其他加密方式（如TLS等安全協(xié)議），攻擊者就無法在中途截取消息進行重放等攻擊。

（2） 減輕拒絕服務(wù)（DoS）攻擊

攻擊者可以通過修改或刪除所有在線用戶的注冊信息，導(dǎo)致注冊服務(wù)器要求所有用戶發(fā)送注冊進行重新認證，從而導(dǎo)致DoS攻擊。

通過身份認證的方式對注冊環(huán)節(jié)進行保護，攻擊者就無法假冒用戶身份對當(dāng)前合法用戶的注冊信息進行修改或刪除，從而避免了因注冊攻擊導(dǎo)致的DoS攻擊。同時通過在路由層對SIP信令的轉(zhuǎn)發(fā)過程增加安全認證機制[4]，也可避免其他節(jié)點被攻擊者利用進行DoS攻擊。

（3） 防范篡改消息體

用戶代理通過代理服務(wù)器進行路由呼叫，惡意的代理服務(wù)器可對SIP消息體進行篡改，誘導(dǎo)接收方用戶代理做出錯誤動作（如修改請求重要性或終止會話等）。惡意服務(wù)器也可修改SIP消息體中的SDP消息體，引導(dǎo)RTP流指向竊聽設(shè)備。

針對這種威脅，需要結(jié)合機密性檢查、完整性檢查和身份認證等安全機制對SIP消息體進行保護。防范惡意代理服務(wù)器對消息體的篡改，需要用戶代理能夠?qū)IP服務(wù)器的身份進行有效鑒別[5]。即在用戶收到服務(wù)器的401（未授權(quán)）響應(yīng)后，在重新發(fā)送注冊請求時，攜帶對服務(wù)器的身份認證挑戰(zhàn)。目前，HTTP摘要認證僅能實現(xiàn)SIP服務(wù)器對所管理區(qū)域內(nèi)內(nèi)用戶代理的認證，無法實現(xiàn)用戶代理對服務(wù)器的認證、服務(wù)器對服務(wù)器的認證等。同時，HTTP摘要認證協(xié)議也存在一些缺陷，容易受到偽裝服務(wù)器以及離線密碼猜測等攻擊[6?7]。

面對以上攻擊的威脅，需要一種身份認證機制來明確請求者的身份，從而阻止非法用戶入侵SIP網(wǎng)絡(luò)。Kilinc和Yanik對目前現(xiàn)有的身份認證和秘鑰協(xié)商方案進行了調(diào)查，從方案的性能和安全兩個關(guān)鍵指標(biāo)對各種SIP身份認證和密鑰協(xié)商協(xié)議進行了分類和評估[8]。

目前RF3261中推薦使用HTTP摘要（Digest）認證的方式。為了方便有效地擴展SIP流程中的安全認證方案，本文就如何修改協(xié)議棧來支持數(shù)字證書等其他加解密認證方式提供一個基于注冊流程的解決方法，通過它可以為更完備性的安全方案提供一個新的思路。

1 對協(xié)議棧注冊安全的擴展

1.1 SIP的認證機制概述

SIP本身并沒有認證機制，其認證及參考了HTTP、SMTP等協(xié)議的摘要認證機制[1]。摘要認證采用挑戰(zhàn)（服務(wù)器）響應(yīng)（客戶端）模式，但用戶名和密碼是經(jīng)過算法（一般是MD5）加密處理的，同時提供一定的完整性檢查。

摘要認證機制的注冊安全流程如圖1所示。挑戰(zhàn)的過程為：首先UA向注冊服務(wù)器發(fā)送一條Register請求；注冊服務(wù)器發(fā)現(xiàn)Register請求沒有帶有認證信息，返回401（未授權(quán)）響應(yīng)要求UA提供認證。其中401響應(yīng)的WWW?Authenticate頭域會帶有realm和nonce等參數(shù)。

響應(yīng)的過程為：UA收到401響應(yīng)后，根據(jù)用戶名和密碼，以及401中帶有的realm和nonce進行口令摘要計算出的結(jié)果為response。并發(fā)送帶有Authorization頭域和response的第二個Register給注冊服務(wù)器。注冊服務(wù)器對Register請求的結(jié)果進行驗證，如果檢查出UA的身份合法，則向UA發(fā)送成功響應(yīng)200OK，如果身份不合法則發(fā)送狀態(tài)碼為403的拒絕服務(wù)應(yīng)答。

1.2 注冊流程的擴展

在RFC中為摘要定義了兩種算法：MD5和MD5?ses[9]，SIP協(xié)議中將MD5選為默認加密算法。SIP具體應(yīng)用時也可使用其他算法，在摘要認證中可通過修改Algorithm字段來定義要使用的加密算法，但若服務(wù)器選擇的加密算法無法被用戶代理識別，則該挑戰(zhàn)（challenge）會被忽略。這種SIP的摘要認證機制中用戶代理與服務(wù)器間無法針對具體的摘要加密方式進行協(xié)商。

通過對摘要認證機制的研究，充分利用SIP協(xié)議擴展性強的特點，可以對SIP協(xié)議進行擴展，對摘要認證機制進行改進，實現(xiàn)客戶端與服務(wù)器端的數(shù)字摘要認證中加密算法的協(xié)商機制。擴展協(xié)議棧安全機制的思路如下：

對擴展協(xié)議棧進行擴展可以實現(xiàn)UA發(fā)送第一條Register時攜帶自身的認證能力，收到401信令后可以根據(jù)401中要求的認證方式，進行不同方式的認證處理，并將經(jīng)過認證的結(jié)果放在第二條Register中發(fā)送給服務(wù)器。這樣協(xié)議棧不再只支持MD5的摘要認證，而是可以根據(jù)注冊服務(wù)器返回的401中要求的認證方式，進行認證，提高了協(xié)議棧在注冊安全領(lǐng)域的靈活性和功能性。擴展后的注冊安全流程如圖2所示。

2 開源協(xié)議棧eXosip2的擴展方法

大部分SIP協(xié)議棧都是遵循RFC標(biāo)準(zhǔn)進行設(shè)計和開發(fā)的，包括Osip2和eXosip2在內(nèi)的很多協(xié)議棧普遍只支持基于MD5加解密的認證機制。目前，基于SIP的開源協(xié)議棧有很多，而Osip2和eXosip2是使用C語言開發(fā)的協(xié)議棧中比較好的。這兩個協(xié)議棧提供了包括IP網(wǎng)絡(luò)通信、SIP消息的詞法、狀態(tài)的管理等與上層應(yīng)用程序通信的接口，通過它們可以簡單快速地開發(fā)出SIP的UA系統(tǒng)。

Osip2作為公開源碼的免費協(xié)議棧，具有結(jié)構(gòu)簡單小巧、應(yīng)用性強和應(yīng)用范圍廣等特點。Osip2主要提供一些解析SIP/sdp消息的API和事務(wù)處理狀態(tài)機，不提供高層SIP會話控制。Osip2支持線程安全，支持多線程和單線程的編程模式。

eXosip2是Osip2的一個擴展協(xié)議集，其部分封裝了Osip2協(xié)議棧，使得它更容易被使用。它實現(xiàn)了作為單個SIP終端所需的大部分功能，如Register、Call、Message等。eXosip2使用通過定時輪詢的方式調(diào)用Osip2的transaction處理函數(shù)，這部分是協(xié)議棧運轉(zhuǎn)的核心。它通過添加/讀取transaction消息管道的方式，來驅(qū)動transaction的狀態(tài)機，使得來自遠端的SIP信令能匯報給調(diào)用程序，來自調(diào)用程序的反饋能通過SIP信令回傳給遠端。

2.1 注冊請求的擴展

發(fā)送帶認證能力的Register時，要在注冊消息的Authorization頭域里增加當(dāng)前UA支持的認證機制，可調(diào)用eXosip協(xié)議棧的osip_message_set_authorization（）函數(shù)設(shè)定。該函數(shù)的主要形式為osip_message_set_authorization（register，"Capability algorithm=＼"SHA1＼""）。其中第一個參數(shù)register是要發(fā)送的注冊消息的數(shù)據(jù)結(jié)構(gòu)指針，類型為osip_message_t；第二個參數(shù)為一個字符串，Capability為Authorization頭域的auth_type的值，空格后為將algorithm的值設(shè)定為SHA1，它代表當(dāng)前UA支持的加解密算法。以此類推可將欲擴展利用的字段寫入Authorization頭域，帶在第一條注冊消息中發(fā)送到注冊服務(wù)器。

協(xié)議棧底層會對Authorization頭域設(shè)定的字段進行檢查，這時需要修改協(xié)議棧內(nèi)部的osip_authorization_parse（）和osip_authorization_to_str（）函數(shù)，將其中對擴展字段（例如algorithm）處理的部分進行修改即可。

2.2 挑戰(zhàn)過程的擴展

對于收到的401信令，在協(xié)議棧中的入口函數(shù)是eXosip_default_action（），再經(jīng)過一系列的注冊消息構(gòu)造函數(shù)處理，由于這些函數(shù)和認證機制沒有關(guān)系，因此當(dāng)執(zhí)行到_eXosip_register_build_register（）函數(shù)才來判斷401消息中攜帶的認證要求。

首先根據(jù)MSG_IS_STATUS_4XX來確定當(dāng)前收到的是401信令，然后比較401消息中WWW?Authenticate頭域的auth_type字段的值，如果為空則仍然執(zhí)行協(xié)議棧默認的流程，使用摘要認證（MD5）；如果為Asymmetric，則表示使用數(shù)字證書的認證方式，開始執(zhí)行新加入的數(shù)字證書認證流程。當(dāng)然新加入的針對數(shù)字證書的函數(shù)也是仿照協(xié)議棧中原有的針對MD5的函數(shù)，只是在加解密和認證結(jié)果的處理部分不一樣，這樣可以最大化地保持原協(xié)議棧的代碼連續(xù)性，還可以實現(xiàn)新的功能。

2.3 響應(yīng)過程的擴展

如果收到的401信令表明服務(wù)器要求的認證機制為數(shù)字證書方式，則進入新添加的函數(shù)eXosip_add_authentication_information_Asymmetric（）和__eXosip_create_authorization_header_Asymmetric（）來構(gòu)造數(shù)字證書的認證信息。這兩個函數(shù)主要是仿照eXosip_add_authentication_information（）和__eXosip_create_authorization_header（）來構(gòu)造的，只不過對于認證的流程和結(jié)果處理不同。

這兩個函數(shù)主要是將認證的結(jié)果放入第二條Register消息的Authorization頭域中。要放入的值有兩種，一種是根據(jù)前一個401信令得到或者默認不變的值，例如nonce，algorithm和auth_type字段；另一種就是加解密的結(jié)果，如response字段，它由應(yīng)用層調(diào)用加解密模塊的接口進行計算，再傳遞到底層。

由于eXosip2協(xié)議棧只在協(xié)議棧內(nèi)部包含了對于MD5算法的代碼，因此要想實現(xiàn)數(shù)字證書的認證機制，必須通過外部調(diào)用加解密模塊的接口。

這需要在應(yīng)用層UA調(diào)用eXosip_default_action（）函數(shù)之前進行一系列處理，主要包括：

（1） 判斷新的事件是否為401事件。

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

（3） 將相關(guān)的數(shù)值以參數(shù)的形式傳入加解密模塊的接口函數(shù)中。

（4） 當(dāng)接口函數(shù)返回加解密的結(jié)果后，再將該結(jié)果通過eXosip_add_authentication_info_Asymmetric（）函數(shù)傳遞到協(xié)議棧底層。該函數(shù)是仿照eXosip_add _authentication_info（）函數(shù)構(gòu)造的，可以動態(tài)設(shè)定eXosip2協(xié)議棧的jauthinfo_t數(shù)據(jù)結(jié)構(gòu)的值。

（5） 協(xié)議棧執(zhí)行到eXosip_add_authentication_information _Asymmetric（）函數(shù)后，就會調(diào)用eXosip_find _authentication_info_Asymmetric（）函數(shù)來取出存到j(luò)authinfo_t的加解密結(jié)果的值，再將結(jié)果的值作為一個參數(shù)傳遞給__eXosip_create_authorization_header_Asymmetric（）函數(shù)，最后這個函數(shù)就會把這個值設(shè)定到第二個Register的Authorization頭域的response字段。

（6） 協(xié)議棧構(gòu)造好新的Register后，就會啟動底層的通信接口發(fā)送第二條帶有認證消息的注冊。

（7） 注冊服務(wù)器驗證通過，返回200OK，注冊成功。

3 方法評估

Osip2和eXosip2協(xié)議棧都是基于MD5算法，來進行注冊流程過程中的參數(shù)檢測和加解密結(jié)果計算。UA發(fā)出Register消息后，對于收到的401，407以及300～399的消息都是通過eXosip_default_action（）函數(shù)來處理的。

對于收到的401信令，協(xié)議棧默認只是按照MD5情況下的參數(shù)設(shè)置進行空值檢查等操作，如果要擴展使用數(shù)字證書等加解密方案，當(dāng)收到的401信令的WWW?Authenticate頭域的值不符合MD5情況下參數(shù)設(shè)置時，協(xié)議棧就會自動停止處理終止整個注冊的流程。

同理對于第二條Register，協(xié)議棧也有一系列只針對MD5的檢查。這樣通過簡單地改變注冊認證中的Authorization和WWW?Authenticate頭域的值來擴展新的認證方案就變得不可行。

如果想跳過eXosip_default_action（）函數(shù)，自己來對收到的401信令進行處理。不但工作量巨大，而且需要完成很多協(xié)議棧內(nèi)部的處理，還會影響到注冊消息的超時重發(fā)以及過期自動重新注冊等功能。所以本文采用修改協(xié)議棧內(nèi)部函數(shù)的辦法，主要思想是對401返回的認證要求進行判斷，再根據(jù)認證的要求按不同的流程進行處理。只需要對于新的認證方案添加一系列相應(yīng)的處理函數(shù)，完成加解密和重發(fā)Register的流程即可，從而保證了協(xié)議棧其他部分的運行不受任何影響，如同為協(xié)議棧打上一個新的補丁。

協(xié)議棧修改前后對于注冊流程的變化如圖3所示。

4 結(jié) 語

SIP協(xié)議的摘要認證機制單一，在基于SIP協(xié)議棧進行開發(fā)的過程中，很多情況下都需要針對特定用戶的需求進行安全擴展。本文在SIP協(xié)議棧的安全應(yīng)用方面，以eXosip2協(xié)議棧作為研究對象，對SIP協(xié)議棧安全機制擴展的思路和實現(xiàn)方法進行了探索，提出了修改現(xiàn)有協(xié)議棧來實現(xiàn)數(shù)字證書的認證機制的具體方法，主要包括協(xié)議棧注冊流程的改進和對應(yīng)注冊流程中請求、判斷以及加解密等環(huán)節(jié)的修改方法。通過評估，認為該方案通過修改協(xié)議棧內(nèi)部函數(shù)的方法，降低了對SIP協(xié)議棧進行安全擴展所需的工作量，避免了對協(xié)議棧中其他環(huán)節(jié)的影響。本文為SIP領(lǐng)域中的其他研究或開發(fā)人員提供了一些具體的方法和思路，具有一定的借鑒意義。

參考文獻

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

[2] 陳昌鵬，晉磊，陳凱，等.SIP協(xié)議的安全分析[J].計算機應(yīng)用與軟件，2007，24（8）：172?174.

[3] 儲泰山，潘雪增.SIP 安全模型研究及實現(xiàn)[J].計算機應(yīng)用與軟件，2004，21（12）：101?104.

[4] 張金玲，廉東本，李想.基于SIP的信令安全網(wǎng)關(guān)安全模塊[J].計算機系統(tǒng)應(yīng)用，2014，23（4）：189?192.

[5] 王慶年，徐皓.IP協(xié)議Digest認證研究[J].艦船電子工程，2013，23（1）：23?24.

[6] 趙躍華，劉申君.會話初始協(xié)議安全認證機制的分析與改進[J].計算機工程，2011，37（20）：114?116.

[7] 彭煥峰.一種基于改進的HTTP摘要認證的SIP安全機制[J].微型機與應(yīng)用，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.