VoIP協議棧的安全性研究

摘 要：本文提出對VoIP協議棧的結構分析，包括VoIP信令（SIP協議），會話描述協議（SDP），密鑰的建立（SDES，，MIKEY，ZRTP），和SRTP協議，對VoIPx協議棧的相關協議作了簡要說明，并分析了其相關的安全性。重點針對SIP、SRTP協議和ZRTP協議分析了其安全隱患并提出相關的改進方案。

關鍵詞：VoIP 協議棧；安全；SDES；SRTP；ZRTP

VoIP是用IP進行語音業務的傳輸，具有設備費用低、話音和數據應用的集成、帶寬需求低、IP的廣泛可用性等特點。在VoIP會話中要想獲得端到端的安全不是一件容易的事。VoIP會話的建立涉及到一系列不同的協議。所有的這些協議必須相互之間正確安全地合作。本文的目標是對VoIP協議棧的協議進行一個結構性的分析，并重點針對SRTP和ZRTP協議的安全性進行分析并提出改進建議。

1 會話描述協議（SIP）

1.1 SIP會話建立

SIP是基于類似于HTTP的請求/應答事務模式，每一個事務由一個請求組成，該請求調用服務器上一個特定的方法或函數并且至少一個回答。事務開始于Alice的軟件電話發出一個INVITE請求給Bob的SIP URL，INVITE請求包含了許多頭域比如：一個用于呼叫的統一標示符，目標地址，Alice的地址和Alice想要和Bob建立的會話的類型的信息。

1.2 SIP協議所受安全威脅

1.2.1 注冊攻擊

SIP系統中所有UAS在某個注冊服務器中注冊，UAC通過服務器查詢它們。注冊攻擊就是攻擊者向注冊服務器偽造注冊行為。例如攻擊者注冊其設備作為被攻擊者的聯系地址，同時注銷被攻擊者的聯系地址，這樣所有發向被攻擊者的請求都會導向攻擊者的設備。

1.2.2 偽造攻擊

偽造攻擊指的是攻擊者改變消息頭域和消息體，模仿消息發出者的身份欺騙合法的接受者。一般有Invite請求偽造，Bye請求偽造，Cancel請求偽造。

1.2.3 監聽

監聽媒體流或SIP消息是對私密性的一種威脅。當局域網的主機通過集線器連接網絡上的業務很容易被監聽。

1.2.4 拒絕服務攻擊（Dos）/分布式拒絕服務攻擊（DDos）

Dos攻擊就是利用合理的服務請求來占用過多的服務資源，從而使合法用戶無法得到服務器的響應。DDos攻擊則是拒絕服務攻擊的發展，通常是攻擊者利用系統管理漏洞逐漸掌握一批傀儡主機的控制權，當攻擊者覺得時機成熟時，控制傀儡自己同時向被攻擊主機發送大量無用分組，這些分組或是耗盡被攻擊主機的CPU資源或是耗盡被攻擊主機的網絡帶寬導致不能接受正常的服務請求，從而出現拒絕服務的現象。

1.2.5 消息篡改

消息篡改意味著消息完整性的違背。如果攻擊者篡改了消息，發送端和接收端消息就不一致。通過消息篡改，攻擊者可以修改SDP，例如；安裝竊聽設備偷聽媒體流。篡改消息威脅所有的SIP消息內容形式，甚至包括媒體會話的密鑰。

2 會話描述協議（SDP）

SDP（會話描述協議）是在RFC4566中定義的，用于會話通告、會話邀請和其他形式的多媒體會話啟動而描述多媒體會話的過[1]。SDP語法簡單易懂，已經被接受作為基于文本的IP信令協議中呼叫參數協商的編碼方法。它定義了會話描述的統一格式，但是不定義多播地址的分配方案和SDP消息的方式，也不支持媒體編碼方案的協商，這些功能由下層傳送協議完成。

3 密鑰交換：SDES，MIKEY

3.1 SDES密鑰協商交換機制

SDES對于密鑰協商是由RFC 3264 SDP offer/answer model 來進行密鑰及加密方式的協商的，對于SRTP SDES而言，其SDP transportation type 必須改為”RTP/SVAP”。比如有兩個User Agent：UA-1，UA-2，當UA-1傳送一個INVITE SDP offer給UA-2，SDP中的media line （m=）必須至少帶有一個有效的SRTP security description（”a=crypto” line），當UA-2收到該SDP offer后則為進行自己本身媒體能力及分析SDP offer提供的SDES的參數進行選擇哪種crypto line為可接受的crypto方式，并產生SDP answer 200 OK回應給UA-1，UA-1接受該消息后必須接受該敘述的參數內容，進行SRTP的傳送給UA-2.

3.2 MIKEY

安全協議需要相應的密鑰管理協議來交換密鑰和相關的安全參數，目前IETF在密鑰管理方案開放方面做了很多工作，如：IPSec廣泛采用IKE（Internet Key Exchange）方案，但是在需要實時數據傳輸和小型交互群組間，需要提供給低延遲和高可靠的解決方案[2]。MIKEY正是用來解決實時多媒體會話的密鑰管理問題。

4 實時傳輸協議（RTP）

實時傳輸協議是一個網絡傳輸協議，它是由IETF的多媒體傳輸小組1996年在RFC1889（后被RFC3550更新）中公布的[3]。RTP協議詳細說明了在互聯網傳輸音頻和視頻的標準數據包格。它一開始被設計為一個多播協議，但后來被用在很多單播應用中。RTP協議常用于流媒體系統（配合RSTP）協議，視頻會議和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。

5 SRTP

為了保證使用RTP/RTCP傳輸音頻或者視頻數據的安全性，目前廣泛采用的是SRTP方案。SRTP為RTP提供用于加密傳輸話音的標準，以解決互聯網上的電話技術應用問[4]。SRTP為RTP提供了安全配置文件（security profile），并支持以下幾個功能：對稱密鑰利用AES算法加密媒體數據來防止竊聽；對發送者進行身份認證以防身份欺騙；對RTP包進行完整性檢查以避免非授權用戶對數據的改變；使用滑動窗口以及接受列表來支持分組回收保護，從而阻止非授權的介入。SRTP的目的是保證RTP和RTCP流的安全性，而不提供安全的網絡安全架構。SRTP使用RTP/RTCP報頭信息與AES算法。得到代數方法上適用于RTP/RTCP有效負載的密鑰流，并支持HMAC_SHA1安全散列驗證算法進行認證功能

5.1 媒體流加密

SRTP用于加密話音分組中的有效負荷，不向分組中添加其他的加密報頭，因此對話音和視頻的端到端傳輸非常高效。SRTP加密的分組與RTP分組相比除了4字節的驗證標記外幾乎沒有區別。SRTP支持AES-128加密算法。與DES和3DES相比，AES提供更高的安全性和更快的速度，尤其是對于較大的負載分組。

5.2 媒體流認證

SRTP可以調用基于散列的消息認證碼（HMAC），使用SHA1算法用于認證功能。圖2為認證流程：

采用認證密鑰對整個RTP報的字段進行摘要計算，得到認證標簽，再與接受到的RTP報中的認證標簽進行比較，如果值相同，這說明該RTP報沒有被中間人篡改。

6 對協議棧相關協議的安全性的改進或建議

6.1 SIP協議安全性建議

為了保證傳輸和網絡層的安全，可以考慮使用TLS和IPsec，另外可以使用證書來提供鑒別。應用一些改進的HTTP摘要認證解決終端系統與中間服務器的SIP安全問題。比如在[6]中作者提出了一種改進的HTTP摘要認證。可以應用SIPS URI方案，該方案提供了一些措施使得數據可以安全到達指定的資源。S/MIME允許SIP UAs在SIP中加密MIME消息體，而端到端的加密消息體不對頭產生任何影響，可以考慮使用S/MIME為消息體提供端到端的機密性和完整性以及相互鑒別。同時S/MIME可以通過SIP消息隧道為SIP頭字段提供一系列的完整性和機密性。

6.2 SRTP的改進

由于對媒體流加密的過程需要耗費時間。這樣會增加語音數據包的延遲，尤其是多個加密點進行加密處理時，會降低整個網絡的性能。SRTP可以采用硬件加密，這樣可以將影響話音質量的風險降至最低。

6.3 ZRTP的改進

⑴ZRTP采用會話密鑰對會話進行加密，由于該會話密鑰具有很輕的健壯性，很難對其進行破譯。如果有中間人對共享密鑰進行了篡改，會造成雙方最終產生的會話密鑰有所不同，從而會導致一方加密的媒體流沒法被對方解密。如果有人對會話密鑰加密后的RTP負載進行篡改，將會導致接收方聽到的話音發生間斷或是表現為噪聲。因此之后建立的SRTP連接沒有必要對整個SRTP負載做哈希摘要認證，而只需對RTP負載之外進行摘要認證，這樣可以減少摘要計算時間，從而可以提高SRTP的摘要認證效率。

⑵密鑰的產生、分發和更新都屬于密鑰管理的范疇，是實現網絡安全和加密的前提，是實現實體認證、媒體流加解密的關鍵環節。可以說密鑰的管理是否有效影響著整個系統安全服務的實現。由于ZRTP不依賴PKI，因此并沒有提供機制安全地交換共享密鑰，只能依靠用戶進行語音識別SAS或是判斷通話內容是否出現異常來識別此次通話是否遭受了中間人攻擊。一旦用戶發現之后，需要斷開此次連接，重新建立一次通話過程，給用戶帶來了不便。特別的，如果用戶每次都不進行SAS的語音識別，很有可能此時已經遭受到了中間人攻擊，造成通信雙方話機上出現的SAS有所區別。

7 總結

本文對VoIP協議棧做了結構性分析，分析了VoIP協議棧的相關協議及其可能受到的威脅或攻擊，重點分析了SRTP和ZRTP協議，并提出相應的改進建議和意見。VoIP網絡是基于分組交換的網絡，遠沒有PSTN線路那么安全，所以需要在VoIP網絡上部署多種安全策略來創建一個相對安全的網絡環境。理論上如果沒有性能限制，任何用于IP網絡的安策略可以用于VoIP，但由于VoIP用戶體驗對性能的要求，能夠在VoIP網絡上部署的安全策略范圍縮小了很多。對VoIP安全問題的研究仍任重而道遠，還有很多需要深入研究問題有待研究。

[參考文獻]

[1]M.Handley，V.Jacobson，C.Perkins RFC4566 SDP： Session Description Protocol IETF Network Working Group July 2006.

[2]J.Arkko E.Carrara MIKEY：Multimedia Internet KEYing RFC3830 IETF Network Working Group August 2004.

[3]H.Schulzrinne S.Casner RFC 3550 RTP：A Transport Protocol for Real-Time Applications IETF Network Working Group july 2003.

[4]M.Baugher D.McGrew RFC3711 The Secure Real-time Transport Protocol （SRTP） IETF Network Working Group march 2004.