??? 摘? 要： 提出一種會話過程中的輕量級雙向認證機制，它基于HTTP摘要認證機制，可以實現逐跳認證，完成端到端的認證，抵抗身份欺騙和拒絕服務等類型的攻擊，從而在系統開銷小的情況下提供了較好的安全保護。?
??? 關鍵詞： SIP; 身份欺騙; HTTP摘要認證; 密鑰協商; 安全機制
?
??? 會話發起協議SIP（Session Initiation Protocol）[1]是位于應用層的信令協議，它可以發起、管理和結束分組網絡中的語音或視頻會話。SIP具有簡單、開放和可擴展等特點，被廣泛用于IP多媒體服務、蜂窩系統與Internet融合等應用領域，已成為下一代電信網絡的主要信令協議之一。?
??? SIP基于文本的特性會帶來許多安全隱患，而且其并沒有自己獨有的安全機制，只是推薦采用了現有的標準安全協議。推薦的傳輸層安全協議/數據報傳輸層安全協議（TLS/DTLS）[2-3]和HTTP摘要認證[4]只提供單向認證，無法很好地抵御外界攻擊。?
??? 針對這種情況，本文提出了一種SIP輕量級雙向認證機制，這種機制基于共享密鑰和改進的HTTP摘要認證，提供了信息完整性校驗。該安全機制有效地利用了SIP已有的結構，只采用一次握手，并避免使用公鑰系統，降低了系統開銷，是種輕量級的機制。它可以抵抗身份欺騙、拒絕服務攻擊等多種威脅[5-6]。?
1 安全現狀及分析?
??? 目前，認證是保證SIP通信安全性的常用手段之一。常用的單向認證卻會導致較為嚴重的安全隱患，易受到中間人攻擊MITM（Man-In-The-Middle）類型的安全威脅。攻擊者通過將SIP注冊消息中的“過期值”改為零偽造出“取消注冊”的消息[8]，便可以立刻清除之前的注冊信息，使被攻擊用戶A被服務器B移除并接收不到來自服務器B的所有后續消息，因為沒有收到任何通知，用戶A認為他與服務器B仍然是連接著的。攻擊者隨后向服務器B偽造REGISTER注冊消息。把服務器B發往用戶A的消息都轉向了攻擊者，同時攻擊者冒充服務器B和用戶A通信。所以，攻擊者會在服務器和用戶都不知情的情況下進行會話劫持。此外，MITM還能引發多種攻擊：對用戶A和服務器B進行竊聽能夠較容易地獲得機密信息，例如私人數據和口令等；用戶A可能會被攻擊者利用，對服務器B或其他目標進行拒絕服務攻擊。?
??? 當前用于身份驗證的方法包括HTTP摘要和TLS/DTLS。HTTP摘要是一種簡單的認證機制，它采用雜湊式（hash）加密方法傳送通信雙方共享的口令，以避免其用明文傳輸；TLS/DTLS基于公鑰技術，為兩個通信實體之間提供數據的保密性和完整性。這兩種認證方式都采用單項認證：使用HTTP摘要的客戶端不能認證服務器并且對消息完整性的保護也不夠充分，比較容易遭受攻擊；TLS/DTLS在實際應用中只是客戶端認證服務器，但服務器不認證客戶端。另外，TLS/DTLS對服務質量（QoS）也會有所影響。使用加密操作的安全協議都將引入處理延時，而SIP會話應該在可以接受的QoS級別內運用安全機制。TLS/DTLS采用了公鑰技術，這項技術需要的計算開銷遠大于密鑰技術和消息摘要技術，從而顯著增加了SIP代理服務器的負擔，這不僅影響了QoS，而且容易受到拒絕服務攻擊[9]。除此之外，TLS/DTLS使用了逐跳的安全認證，使得兩個用戶間的通信路徑上有一個環節缺少TLS/DTLS的保護時，整條路徑都變得不安全。?
??? 為克服上述缺陷，提出了一種輕量級雙向認證機制，它通過加入共享密鑰改善了HTTP摘要。?
2 輕量級雙向認證機制?
2.1 認證機制實現?
??? 這種認證方法的性能損失較小，其輕量級的特點體現在以下兩點：?
??? （1）僅需要一個挑戰—請求過程，握手次數較少。由于當今的處理器變得越來越強大，傳輸數據需要的時間已經逐漸成為認證開銷的主要部分，所以減少消息交互時的握手次數可以減少開銷，增強性能。?
??? （2）沒有采用計算復雜的公鑰算法。之所以不采用公鑰算法是因為盡管它可以提供更高的安全性，但是計算開銷較大，會對SIP會話的QoS有所影響。考慮到密鑰算法和消息摘要算法在性能上的差別并不大（都是以字節為單位），使用了共享密鑰并采用了AES加密算法，其快速和安全性可以平衡SIP通信中QoS和安全性的要求。?
??? 如果缺少信息完整性保證，認證機制也可能受到攻擊。這個輕量級認證機制用共享密鑰提供了SIP消息部分頭域的完整性保護，這些頭域包括Contact、To和From等。選擇性的加密而不是加密整個消息體可以避免分組過大而導致的分片，而分片在SIP實時通信中需要盡量避開[10]。?
??? 這種輕量級雙向認證機制的實現過程為：下游節點在對上游節點的挑戰中加入被共享密鑰加密的信息。當下游節點的身份通過解密被驗證后，上游節點將返回一個請求，其中攜帶著針對下游節點挑戰的認證，這個請求同樣也被加密處理。當來自于上游節點的加密信息被下游節點解密驗證后，身份信任會在兩個節點間建立起來。?
2.1.1? WWW-Authenticate頭域?
??? 為實現輕量級的雙向認證機制，對HTTP摘要里某些頭域的參數值進行了修改。其中對WWW-Authenticate響應的修改如下：?
??? digest-challenge = 1#(realm/[domain]/req-auth-digest/[opaque]/[state]/[algorithm]/[qop-options]/[auth-param] )?
??? req-auth-digest='req-auth-digest''='req-auth-digest-value?
??? req-auth-digest-value = <'> HEX <'>?
??? algorithm = 'algorithm' '=' ('AES'/token)?
??? 如果終端是服務器，domain值必須被包括，而不像原標準那樣只是可選項。如果缺少了domain值，當一個用戶在多個服務器上配置了相同的密鑰，則不同的服務器可能產生相同的挑戰，從而使用戶對于不同的服務器產生了相同的應答。監聽者可能會偽裝成用戶將其發送的加密應答發往不同的服務器并獲得認證。加入domain值可以識別服務器的身份，從而克服了上述問題。?
??? 此雙向認證機制加入了字符串req-auth-digest，處在其中的nonce和req-digest-string一起被共享密鑰加密。在安全機制中，不同的nonce類型擁有不同的特點。大隨機數被認為是最好的nonce類型，但需要較高的成本；時戳類型要求極好的時鐘同步和精確度；序列號類型相對簡單，但易于被預測。因此，當nonce值在明文中傳送時，謹慎地選擇nonce類型很有必要。本文提出的認證機制可以避免因選擇nonce類型而出現的問題，它在挑戰和請求中都對nonce進行了加密，這樣即使是可被預測到的nonce值也能夠使用，用戶代理可以自行選擇合適的nonce類型。字符串req-digest-string涉及到SIP消息頭域的一個子集，其中包含了狀態碼、From、To、Contact、Cseq 和Call-ID。這個字符串采用16進制數編碼，其定義如下：?
??? req-degist-string = <'> ??????? ':' address-specification-in-To? ??????? ':' address-specification-in-Contact? ??????? ':' cseq-value? ??????? ':' called-value ><'>? ??? 在隨后給出的計算方法中，使用共享密鑰通過“secret”對數據內容“data” 加密。? ??? 得到的字符串可表示成Ek(secret, data)，對數據內容“data”采用校驗和算法產生的字符串由H(data)表示，unq(X)則表示引號內的字符串。如果是服務器，必須要求含有H(A1)值。字符串algorithm說明了加密所采用的算法，默認為“AES”。? ??? req-auth-digest-value =<'> 2.1.2? Authorization頭域? ??? Authorization頭域修改如下：? ??? credentials= 'Digest' digest-response? ??? digest-response=1#( username/realm/digest-uri/resp-author-digest/[ algorithm ]/[cnonce]/[opaque]/[message-qop]/[nonce-count]/[auth-param])? ??? resp-author-digest='resp-author-digest''='requestdigest-value? ??? request-digest-value = <'> < Ek’(H(B1), nonce-value?':' unq (resp-degist-string)?[':' nc-value]?[':'unq (cnonce-value)]?[':' unq (qop-value)]?':' H (B2)) > <'>? ??? B1=unq (realm-value) [':' unq (domain-value)]? ??? B2=Method ':' digest-uri-value? ??? 字符串resp-degist-string和WWW-Authenticate中的req-degist-string基本一致，只是少了狀態碼部分。K’表示一個新的密鑰，這個密鑰是按照協商好的算法由共享密鑰計算得到的，如K-1等，其中K代表了初始共享密鑰。? 2.2? 雙向認證過程? ??? 圖1顯示了一個基于雙向認證機制的SIP會話建立過程。假設用戶A和用戶B間的共享密鑰在所示SIP會話發生之前已經配置完成（接下來將討論共享密鑰生成方法）。為了簡化說明，設定SIP代理服務器、SIP注冊服務器和位置服務器均在同一個主機上。? ? ? ??? 用戶A發起一個基于明文的INVITE請求，一旦接收到這個消息，用戶B則認為需要對用戶A進行身份驗證，繼而返回一個特殊的SIP錯誤消息作為挑戰，要求用戶A提供身份證明。錯誤消息401 Unauthorized即用戶B發出的挑戰，它包含了加密后的nonce和req-auth-digest，消息內容如下所示：? ??? SIP/2.0 401 Unauthorized? ??? WWW-Authenticate: Digest? ??? realm='test@host.com',? ??????? req-auth-digest='B9248DC13E14A784604D8F70C8283? ??????? CCA330D0FB19E548E01DEBBDBB31623A1F0FE7F1B? ??? ????? 9D5EC6536B722281FF4B4F7B6FBB9E37C8E1D7167FA? ??? ??? 65FE88242B0575927486CBABB7206A896FD3FD3E1C6? ??????? BBCE'? ??? 用戶A收到錯誤消息后，用共享密鑰對req-auth-digest進行解密，然后通過對nonce值和數據完整性的校驗來驗證用戶B的身份。如果校驗正確，用戶A會通過已經協商好的算法使用初始共享密鑰生成新的密鑰，并對接收到的nonce值和自己所發消息的部分頭域加密，重新產生序列。消息內容如下所示：? ??? INVITE sip:UserB@131.160.1.112 SIP/2.0? ??? Authorization: Digest username='UserA',? ??????? realm='test@host.com',? ??????? uri='/dir/index.html',? ??????? resp-author-digest='DCB38CB9E982F7D2F767DE? ??????? CF3683ECE0CF77A951D6F78C3FC77352B6629375? ??? ???? ?? E5B8AC4A0E8A6F7AFF1FE8F775C3F73D9F626B9? ??????? BE6850EFD98D4792C01A1E60C05A66CE39FC7F6? ??????? E1B027A79CE83FE8795C'? ??? 若解密后的nonce值與保存的nonce值不匹配或者解密后的頭域與消息里的頭域不相符，用戶B將不會做出回應并開始處理失敗的認證；反之，用戶B將返回200 OK。? ??? 上述端到端的認證要求代理服務器在整個過程中始終處于透明狀態，即它們必須原封不動地傳遞WWW-Authenticate和Authorization頭域。如果代理服務器在向服務器或其他實體傳遞用戶請求之前需要認證用戶，可以用Proxy-Authenticate和Proxy-Authorization頭域，它們與WWW-Authenticate 和 Authorization頭域極其類似，被用于逐跳的安全保護。? 2.3 共享密鑰協商? ??? 這種雙向認證機制需要會話雙方進行共享密鑰協商。完美前向保密性要求共享密鑰應定期更新，所以共享密鑰必須在首次使用或密鑰更換時被安全地協商，建議使用Diffie-Hellman算法實現協商過程。為了抵抗MITM攻擊，算法中p和q的數值可以通過帶外信道傳送或PKI發布，然后指數密鑰即可在不安全地信道里傳送。為了傳送指數密鑰，提出了一個新的SIP頭域——K-Exchange，它用于聲明在INVITE請求和200 OK響應中包含了一個指數密鑰。擴展后的消息交換如圖2所示。 ? ? ??? 通信雙方擁有共享密鑰之后，將會有足夠的信息生成共享會話密鑰，它能夠保護隨后媒體數據的完整性和機密性。例如，Ek(nonce)可以作為實時傳輸協議RTP（Real-time Transport Protocol）的共享會話密鑰。? ??? 本文提出了一種SIP輕量級雙向認證機制，它采用通過Diffie-Hellman算法協商的共享密鑰，在不增加握手次數的情況下實現了雙向認證，減少了會話開銷。此外，修改共享密鑰得到的共享會話密鑰能夠用來保護隨后的媒體數據。這種機制可以對諸如身份欺騙、拒絕服務等攻擊提供較好的抵抗。? ??? 目前對這種機制的性能優化程度還沒有做定量的測試與分析，因此設計SIP通信系統模型并在其基礎上進行不同認證機制的開銷比較將成為今后的工作方向。 參考文獻? [1] ROSENBERG J, SCHULZRINNE H, CAMARILLO G. SIP:Session initiation protocol,Internet RFC 3261, 2002, 6.? [2] CHOI C Eun C, CHO H Kee, JAE S. Evaluation of??security protocols for the session initiation Protocol, Computer Communications and Networks, 2007. ICCCN 2007.Proceedings of 16th International Conference,2007.? [3] SALSANO S. VELTRI L, PAPALILO D. SIP security issues: the SIP authentication procedure and its?processing load, Network, IEEE, 2002,16(6):38-44.? [4] LEACH P, LUOTONEN A,STEWART L. HTTP?Authentication:Basic and Digest Access Authentication, RFC 2617, 1999,6.? [5] GENEIATAKIS D,KAMBOURAKIS G,DAGIUKLAS?T,et al.?? A framework for detecting malformed?messages in SIP networks, the Proceedings of 14th?IEEE Workshop on Local and Metropolitan Area?Networks (LANMAN), 2005.? [6] EL S S, URIEN P. SIP security attacks and?solutions: A state-of-the-art review, Information?and Communication Technologies,2006.ICTTA’06.2nd, 2006,2:3187-3191.? [7] 俞志春，方濱興，張兆心.SIP協議的安全性研究，計算機應用，2006，26(9)：2124-2126.? [8] Bremler-Barr, A. Halachmi-Bekel, R. KANGA-SHARJU?J.Unregister attacks in SIP. Secure Network Protocols,2006. 2nd IEEE Workshop, 2006.? [9] KONG L, BALASUBRAMANIYAN V B, AHAMAD M. A?lightweight scheme for securely and reliably locating SIP?users. VoIP Management and Security, 2006,9-17.? [10] Leitold, MEDVE F, KOVACS A, Levente. SIP security?problems in NGM Services,Next Generation Mobile Applications, Services and Technologies, 2007. NGMAST '07.The 2007 International Conference, 2007.
