摘  要： SIP協(xié)議是當(dāng)前IP電話中的主流協(xié)議，HTTP摘要認(rèn)證機(jī)制被很多SIP系統(tǒng)作為安全機(jī)制，但存在客戶端不能認(rèn)證服務(wù)器端，且不支持密鑰協(xié)商的缺陷。為解決這一不足，提出了一種基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制，使得SIP安全解決方案更加完善，部署更加靈活。
關(guān)鍵詞： SIP；HTTP摘要認(rèn)證；安全機(jī)制

SIP協(xié)議即會話發(fā)起協(xié)議[1]，是NGN網(wǎng)絡(luò)和3G網(wǎng)絡(luò)的核心協(xié)議，目前在電信網(wǎng)絡(luò)中有著廣泛的應(yīng)用。由于SIP協(xié)議的消息以文本方式編碼，容易閱讀解析，并且SIP消息在開放式的IP網(wǎng)絡(luò)中傳輸，SIP消息容易被攻擊者模仿、纂改，然后加以非法利用，最終導(dǎo)致賬號被盜用、業(yè)務(wù)失敗或被干擾。目前很多SIP系統(tǒng)采用基于HTTP摘要認(rèn)證機(jī)制作為系統(tǒng)的安全解決方案[2-3]，但該機(jī)制有兩個主要的缺陷，即不能滿足客戶端認(rèn)證服務(wù)器端，也不具有密鑰協(xié)商機(jī)制。為能夠?qū)IP消息中的頭域進(jìn)行端到端的加密，本文提出了一種改進(jìn)的HTTP摘要認(rèn)證機(jī)制，解決了基于HTTP摘要認(rèn)證的SIP安全機(jī)制的缺陷。
1 基于HTTP摘要認(rèn)證的SIP安全機(jī)制
    HTTP摘要認(rèn)證機(jī)制解決了基本認(rèn)證機(jī)制密碼明文傳輸?shù)膯栴}，但同樣基于用戶名密碼體系，并沒有建立初始用戶名密碼體系的機(jī)制[4]，SIP系統(tǒng)可以基于HTTP摘要認(rèn)證建立自己的安全機(jī)制。
1.1 認(rèn)證流程
    在基于HTTP摘要認(rèn)證的SIP安全機(jī)制中，摘要認(rèn)證的架構(gòu)與HTTP摘要認(rèn)證的架構(gòu)非常相似，特別是認(rèn)證模式、認(rèn)證參數(shù)、挑戰(zhàn)、域、域值和憑證的BNF都是一樣的。兩者都是基于挑戰(zhàn)-響應(yīng)模式。如果客戶端(UAC)發(fā)起的請求沒有包含認(rèn)證信息，則服務(wù)器(UAS或者Proxy)會向客戶端發(fā)起挑戰(zhàn)，挑戰(zhàn)信息包含在401/407響應(yīng)中，客戶端收到挑戰(zhàn)后，用ACK請求確認(rèn)挑戰(zhàn)，然后重新構(gòu)建包含認(rèn)證信息的請求，服務(wù)器認(rèn)證成功后，則接受此請求。SIP認(rèn)證對特定域有意義，每個保護(hù)域都有自己的用戶名和密碼，服務(wù)器在其挑戰(zhàn)中應(yīng)該包含域信息，提示客戶端提供此域的用戶名和密碼信息。
1.2 存在的缺陷
    摘要認(rèn)證是基于預(yù)分配用戶名密碼的一種認(rèn)證機(jī)制，主要目的是替代基本認(rèn)證，避免密碼在網(wǎng)絡(luò)中明文傳輸。摘要認(rèn)證機(jī)制可以解決注冊劫持、請求欺騙、重放攻擊、篡改消息等安全問題，同時還能提供一定的完整性保護(hù)[5]。
    摘要認(rèn)證的缺陷主要有：(1)沒有提出完備的雙方認(rèn)證機(jī)制，即UAC不能對PROXY和UAS進(jìn)行認(rèn)證，容易遭受偽裝服務(wù)器攻擊；(2)沒有密鑰協(xié)商機(jī)制，不能協(xié)商私密密鑰，然后對SIP指定頭域進(jìn)行加密，避免信息泄漏。
2 基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制
    針對摘要認(rèn)證機(jī)制的兩點(diǎn)主要缺陷，經(jīng)過對摘要認(rèn)證機(jī)制的深入研究和實(shí)踐總結(jié)，論文提出了一種基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制。
2.1 改進(jìn)后的認(rèn)證流程
    呼叫建立的效率與信令的數(shù)量有關(guān)，在SIP協(xié)議上應(yīng)用認(rèn)證方案時，不能過多地引入信令流程，從而較大程度地影響呼叫效率。因此改進(jìn)的認(rèn)證方案充分利用原有的認(rèn)證信令流程，擴(kuò)充了4個SIP頭域：UAC-Authenticate、UAC-Authorization、Encryption-Info、Encrypted-Header，實(shí)現(xiàn)了客戶端與服務(wù)器的雙向認(rèn)證和加密密鑰協(xié)商機(jī)制，而無需擴(kuò)充新的信令流程。以INVITE請求為例，改進(jìn)后的認(rèn)證流程如圖1所示。

    由圖1可以看出，改進(jìn)的摘要認(rèn)證機(jī)制并沒有更改原有的信令流程，而是通過擴(kuò)充SIP頭域來解決摘要認(rèn)證機(jī)制存在的主要缺陷。
    UAC認(rèn)證UAS/PROXY的流程為：
    (1)UAC向服務(wù)器發(fā)起請求，若需要認(rèn)證服務(wù)器，則在請求的UAC-Authenticate頭域中包含挑戰(zhàn)參數(shù)，向服務(wù)器發(fā)起挑戰(zhàn)；
    (2)服務(wù)器在收到含有挑戰(zhàn)信息的請求后，如果是針對自己的挑戰(zhàn)，則獲取UAC的帳號密碼，連同挑戰(zhàn)參數(shù)，生成憑證，并在401/407響應(yīng)的UAC-Authorization頭域中包含此憑證；
    (3)UAC在收到401/407響應(yīng)后，驗(yàn)證響應(yīng)中包含的憑證，如果有效則證明服務(wù)器知道自己的用戶名和密碼，可以進(jìn)行后續(xù)處理。
    密鑰協(xié)商流程為：
    (1)服務(wù)器收到客戶端的請求后，若配置了密鑰協(xié)商策略，則在401/407響應(yīng)的Encryption-Info頭域中提供自己的公鑰加密算法、公鑰、支持的對稱加密算法等信息；
    (2)UAC收到包含Encryption-Info頭域的401/407響應(yīng)時，根據(jù)自己的安全策略，若支持改進(jìn)的摘要認(rèn)證機(jī)制，則通過ACK請求返回自己的對稱加密密鑰(用服務(wù)器提供的公鑰加密)和選擇的加密算法；
    (3)在上述兩步中雙方建立了加密上下文，UAC在再次發(fā)起的請求中可以對某些頭域進(jìn)行加密。
    值得說明的是，一般SIP系統(tǒng)中服務(wù)器作為操作的主導(dǎo)，因此改進(jìn)的認(rèn)證機(jī)制在加密協(xié)商時，只能由服務(wù)器主動發(fā)起協(xié)商，同時為了能夠協(xié)商加密密鑰，服務(wù)器需要有公鑰加密機(jī)制。
2.2 客戶端和服務(wù)器端操作規(guī)范
    類似IETF的RFC3261[1]文檔，對于改進(jìn)的摘要認(rèn)證機(jī)制需要給出客戶端和服務(wù)器端的操作規(guī)范，在此以INVITE請求為例，對客戶端和服務(wù)器端的操作規(guī)范進(jìn)行描述。
      客戶端操作規(guī)范：
      (1)根據(jù)安全策略配置，如果需要對服務(wù)器端進(jìn)行認(rèn)證，則在發(fā)送的INVITE消息中攜帶UAC-Authenticate頭域，包含要認(rèn)證的服務(wù)器端的URL(包含在digest-uri參數(shù)中)、username、qop、nonce等參數(shù)。
      (2)在接收到服務(wù)器端返回的401/407(UAS返回401，Proxy返回407)響應(yīng)后：
      ①如果響應(yīng)包含UAC-Authorization頭域，則計算憑證，如果與服務(wù)器端返回的憑證相同，則表明服務(wù)器端知道UAC的密碼，這樣就完成了對服務(wù)器端的認(rèn)證。如果驗(yàn)證不通過，則發(fā)送ACK對401/407響應(yīng)進(jìn)行確認(rèn)后，UAC不再發(fā)起新的請求；
    ②如果響應(yīng)包含WWW-Authenticate/Proxy-Authenticate頭域，則表明服務(wù)器端要求認(rèn)證UAC，緩存挑戰(zhàn)參數(shù)以在重新發(fā)起的請求中計算憑證；
    ③如果響應(yīng)包含Encryption-Info頭域，則表明服務(wù)器端發(fā)起加密協(xié)商請求，該頭域中包含服務(wù)器端的公鑰及其支持的加密算法等信息。
    (3)UAC對401/407響應(yīng)發(fā)送ACK進(jìn)行確認(rèn)，如果401/407響應(yīng)中包含Encryption-Info頭域，且UAC也配置為支持加密協(xié)商，則ACK請求中應(yīng)包含Encryption-Info頭域，告知UAC隨機(jī)生成的加密私鑰(經(jīng)過服務(wù)器端的公鑰加密)和采用的加密算法。
    (4)UAC重新發(fā)起請求，如果服務(wù)器端要求認(rèn)證UAC，則在新的請求中包含Authorization或者Proxy-Authorization頭域，向服務(wù)器提供憑證。如果之前成功地進(jìn)行了密鑰協(xié)商，則對需要加密的頭域可以用私密密鑰進(jìn)行加密。
    服務(wù)器端操作規(guī)范：
    (1)若客戶端需要驗(yàn)證服務(wù)器端，則服務(wù)器端在收到的第一個INVITE請求中包含UAC-Authenticate頭域，提供digest-uri、username、nonce、qop等挑戰(zhàn)參數(shù)；
    (2)根據(jù)認(rèn)證策略的配置，服務(wù)器端在收到請求時做如下處理：
    ①如果請求包含UAC-Authenticate頭域，且頭域中的digest-uri參數(shù)的指示是自身，表明UAC要認(rèn)證自己，所以要計算憑證，返回401/407響應(yīng)(憑證包含在UAC-Authorization頭域中)；
    ②如果請求中沒有包含UAC-Authenticate頭域，則表明UAC并不想認(rèn)證自己，如果服務(wù)器端不需要認(rèn)證UAC，繼續(xù)處理INVITE請求；
    ③如果服務(wù)器端需要認(rèn)證UAC，則返回401/407響應(yīng)，并在響應(yīng)中包含WWW-Authenticate/Proxy-Authenticate頭域，提供挑戰(zhàn)信息；
    ④如果服務(wù)器端配置了加密協(xié)商策略，則在收到UAC的請求后，返回401/407響應(yīng)，在Encryption-Info頭域中包含自己的公鑰加密算法、公鑰和支持的加密算法，向UAC提起加密協(xié)商挑戰(zhàn)。
    若客戶端與服務(wù)器端要求相互認(rèn)證，且服務(wù)器端配置了加密協(xié)商策略，則在對客戶端請求的401/407響應(yīng)中就會同時包含UAC-Authorization、Encryption-Info、WWW-Authenticate/Proxy-Authenticate頭域。
    (3)接收到UAC對401/407響應(yīng)的ACK確認(rèn)消息后：
    ①如果ACK消息中包含Encryption-Info頭域，則表明UAC支持加密協(xié)商，其中Encryption-Info頭域中包含UAC給定的加密私鑰(用服務(wù)器端的公鑰加密)、加密算法等信息。服務(wù)器端應(yīng)該緩存Encryption-Info頭域的內(nèi)容，以用來處理后續(xù)的請求；
    ②如果ACK消息中沒有包含Encryption-Info頭域，則表明UAC不支持加密協(xié)商。
    (4)經(jīng)過密鑰協(xié)商后，則后續(xù)消息的部分頭域在整個會話期間可能做了加密處理，服務(wù)器端應(yīng)該先對加密的頭域進(jìn)行解密，然后驗(yàn)證UAC提供的憑證。
2.3 擴(kuò)展頭域規(guī)范
    改進(jìn)的摘要認(rèn)證機(jī)制對SIP協(xié)議進(jìn)行了擴(kuò)展，新增UAC-Authenticate、UAC-Authorization、Encryption-Info、Enc-
rypted-Header四個頭域。
    其中UAC-Authenticate頭域的規(guī)范類似于WWW-Authenticate，而UAC-Authorization頭域規(guī)范類似于WWW-Authorization，僅有部分區(qū)別。
    Encryption-Info頭域攜帶了密鑰協(xié)商信息，服務(wù)器在401/407響應(yīng)中用此頭域告知客戶端服務(wù)器側(cè)使用的公鑰加密算法、加密公鑰，支持的對稱加密算法；客戶端在對401/407響應(yīng)的ACK請求中用此頭域告知服務(wù)器使用的對稱加密的私鑰以及選擇的加密算法。該頭域規(guī)范如下：
    Encryption-Info="Encryption-Info"":" Encrypt-Info
    Encrypt-Info=1#(public-key| public-encrypt-algorithm|
encrypt-private-key | algorithm | [encrypt-param])
    public-key="public-key " "= " key-value
    key-value?= quoted-string
    public-encrypt-algorithm=" public-encrypt-algorithm "
"=" key-value
    encrypt-private-key="encrypt-private-key " "=" key-value
    algorithm="algorithm" "=" <"> 1# algorithm-value <">
    algorithm-value="DES" | "DEA" | token
    public-key參數(shù)由服務(wù)器端指定，告知客戶端自己的公鑰。
    public-encrypt-algorithm參數(shù)由服務(wù)器給出，指定了服務(wù)器使用的公鑰加密算法。
    encrypt-private-key參數(shù)給出客戶端指定的對稱加密私鑰，用public-key參數(shù)中指定的公鑰加密后傳給服務(wù)器端。
    algorithm參數(shù)列出了服務(wù)器端支持的對稱加密算法；客戶端發(fā)送至服務(wù)器端的ACK消息中此參數(shù)應(yīng)為客戶端選定的加密算法，且此算法應(yīng)包含在服務(wù)器端支持的加密算法列表中。
    Encrypted-Header頭域表示加密后的頭域，其BNF范式如下：
    Encrypted-Header="Encrypted-Header"":" Encrypt-Value
    Encrypt-Value=quoted-string
    例如對頭域From:B<SIP:B@Nanjing.com>進(jìn)行加密，假設(shè)加密后該頭域成為：Encrypted-Header:8f831abf39815iodhe83d20acA2B，當(dāng)對端收到有加密頭域的SIP消息時，首先對Encrypted-Header頭域進(jìn)行解密處理，還原出原有頭域，然后進(jìn)行后續(xù)處理。
    針對基于HTTP摘要認(rèn)證的SIP安全機(jī)制不能實(shí)現(xiàn)客戶端主動認(rèn)證服務(wù)器端、可能受到偽裝服務(wù)器的安全威脅，同時不能在客戶端和服務(wù)器端進(jìn)行密鑰協(xié)商來對部分頭域進(jìn)行必要的加密處理，本文提出了一種改進(jìn)的HTTP摘要認(rèn)證機(jī)制，基于此機(jī)制的SIP安全方案不但能夠增加SIP系統(tǒng)的安全保護(hù)強(qiáng)度，而且可以針對不同的安全級別靈活部署。
參考文獻(xiàn)
[1] ROSENBERG J，SCHULZRINNE H，CAMARILLO G，et al. SIP：session initiation protocol，IETF RFC3261[S].August 2002.
[2] 婁穎.SIP協(xié)議安全機(jī)制研究[J].廣東通信技術(shù)，2005，24(4)：5-8.
[3] 麋正琨.軟交換組網(wǎng)與業(yè)務(wù)[M].北京：人民郵電出版社，2005：473-510.
[4] FRANKS J，BAKER P H，HOSTETLER J，et al.HTTP  authentication：basic and digest access authentication，IETF RFC2617[S].June 1999.
[5] QIU Q.Study of digest authentication for session initiation  protocol(SIP)[D].University of Ottawa，December 2003.