今天，VoIP網絡或者基于SIP架構的網絡隨著部署環境復雜程度的不斷加強，基于IP的企業通信網絡環境也更加靈活，以及SIP終端用戶的普及，網絡攻擊等安全問題越來越嚴重。在針對SIP網絡的安全問題上，目前存在各種針對SIP網絡安全部署機制的措施，比如使用SBC來處理相對比較復雜的環境，或者針對單點服務器端使用信令加密或者RTP加密來保證其呼叫和語音的安全。關于SBC的安全機制以及商業場景，筆者在很多歷史文檔中有非常深入的討論，讀者可以查閱歷史文檔學習和了解各種應用場景。
今天，為了確保SIP協議及新IP企業通信網絡技術概論這個系列分享的完整性，筆者計劃和讀者分享關于筆者針對SIP端的信令和語音加密以及SIPS使用，TLS，SRTP等問題進行一個全面的討論。在本次分享中，筆者將要討論的核心要點包括：authentication（簽權）和authorization（授權），安全證書處理機制討論，關于SIP、RTP加密的相關技術討論，SIP trunk加密，安全攻擊和響應處理機制，測試工具使用等幾個主要的章節，希望通過這些環節的討論為讀者提供一個全面的關于新IP企業通信中的關于SIP和RTP加密的完整詳解。我們首先從安全機制的基本問題談起-簽權和授權的背景介紹。
關于簽權（authentication）和授權（authorization）的背景介紹
如果我們提到安全證書，我們首先應該了解兩個關于安全認證的基本問題（authentication和authorization）。下面，筆者針對這兩個基本的問題進行討論。
此圖例以及以下圖例均來自于互聯網資源
這兩個基本問題其中一個就是認證簽權（authentication）。另外一個就是授權的問題（authorization）。簡單來說，authentication 是負責處理身份認定的問題，比如登錄系統確認身份等問題。authorization 是一個授權問題，簡言之，就是系統允許用戶登錄以后允許干什么的問題。
在SIP網絡中，我們仍然使用同樣的機制來管理用戶注冊，管理呼叫和其他的業務功能。現在我們以SIP 呼叫或者INVITE舉例來說明其認證的流程。以下示例中使用了SIP代理和用戶驗證服務器，在實際應用環境中，代理服務器可能是一個SIP 服務器端或者IPPBX支持本身自己的數據庫來存儲用戶驗證信息。
在以上圖例中，整個認證過程經過了以下八個核心步驟：
- UA james 首先對proxy 服務器發出INVITE請求表示需要呼叫，驗證身份。
- Proxy 服務器第一次回復407 Proxy Auth Required，表示UA需要發送認證信息，并且對此UA發送nonce（number once） 消息。這個nonce消息會保存到Proxy中。
- UA 收到了nonce 消息以后，獲悉服務器需要重新發送INVITE，并且需要攜帶hash重新認證。因此，UA結合密碼和nonce進行加密運算（MD5）。
- UA 通過MD5運算，最后獲得hash。
- 然后reINVITE 消息，告訴abc.com Proxy， UA攜帶了計算后的hash。
- Proxy服務器通過以前保存的nonce，結合設置的密碼進行計算
- 如果Proxy計算出的hash和UA發送到hash是完全一樣的，則表示密碼匹配成功。
- Proxy服務器接受了這個reINVITE，最后對其UA發送200 OK，確認了用戶身份。
以上過程中，雙方密碼都沒有以明文的形式公開進行傳輸，SIP安全得到了保證。關于MD5在SIP中的運算，我以前在文章中有所介紹。這里，筆者不做過多解釋。關于nonce的算法參考rfc2617. 如果讀者對MD5HA1有興趣的話，也可以參考開源的工具來驗證這些MD5HA1的驗證結果。另外，hash的算法是一個比較復雜的技術范圍，用戶可以參考很多專業的文檔研究其使用方式。目前，大量的數據證明，128 bits的MD5存在很多的缺陷，現在SHA-1相對比較安全，支持了160bits，但是SHA-1 仍然有一些安全問題，所以比較完整的是SHA-2（支持512bits），和最新的SHA-3。更多關于SIP認證技術架構的規范，讀者可以參考最新的RFC8760來學習。
一些開源的用戶也發布了比較多的開源的關于SIPdigestcalculator 計算的工具，讀者可以嘗試測試，使用情況參考鏈接。
SIPdigestcalculator.exe -u username -r realm -p password -n nonce -cn client nonce -nc nonce count -uri SIP URI
筆者介紹了關于呼叫的認證的示例，如果需要關于SIP注冊的示例的話，用戶可以訪問參考鏈接獲得更多關于SIP注冊中簽權的處理流程。
另外，我們在一些工作場景中，經常會看到不同環境中，有時用戶端收到的是401或者407響應消息。401 Unauthorized 一般是通過注冊服務器進行注冊流程處理。
407 錯誤響應碼是代理服務器的協議消息。
407 Proxy authentication required則一般都是Proxy回復的客戶消息, 它和401非常相似，但是它需要UA首先對Proxy認證。401 頭中包含的是WWW-Authenticate，而407 則包含的proxy_authentication。
authorization或者授權是一個相對比較簡單的概念，授權是通過簽權以后，用戶可以訪問的一些服務功能。在一般的呼叫業務場景中，用戶可以通過數據庫的授權設置，允許SIP終端根據不同的授權級別支持各種不同的業務功能，例如某些用戶僅支持語音呼叫，某些用戶可以支持語音和視頻呼叫；某些用戶可以支持多種語音編碼，某些用戶僅支持一種語音編碼；某些用戶可以支持語音郵箱，盲轉，某些用戶則不支持這些功能。這些設置權限都可以作為授權的設置。
在以上討論中，筆者簡單介紹了關于簽權和授權的區別，結合簽權和授權在SIP的具體應用中的示例說明了簽權的流程以及授權的應用場景。在下一個章節筆者將真正進入到關于SIP加密的技術的討論。
關于SIP加密（Encryption）的相關技術討論
目前大部分的SIP網絡的通信交互都是通過互聯網進行的。如果SIP交互通過互聯網傳輸的話，SIP信令和RTP語音流存在很多的安全隱患。這些安全問題已經在互聯網環境中存在了很多年。用戶確實需要通過安全機制對系統進行非常嚴格的安全保障。以下是目前SIP網絡中和IMS網絡所面對的安全威脅：
各種SIP網絡的安全威脅
以上這些問題都涉及了如何設置SIP安全策略的問題。所以，用戶為了盡可能減少這些安全問題，只能通過對SIP加密和語音加密來增加通信的安全或者其他機制來降低安全風險。另外，在IMS網絡環境中，同樣存在著這些風險：
IMS 網絡安全威脅
因此，我們需要一套安全加密機制針對SIP信令和RTP流進行安全設置來保護SIP網絡的安全。加密（Encryption）技術是一個非常龐雜的技術，本人對此技細節沒有更多深入了解，我僅從兩個基本的主流概念中為大家介紹一下關于加密技術的輪廓。加密或者Encryption支持兩種基本的形式的加密類型，一種是symmetric（對稱加密）方式，另外一種則是asymmetric（非對稱）加密方式。它們兩者之間有非常明顯的不同。
對稱加密是一種比較老的加密方式，主要是雙方通過共享秘鑰方式來進行加密和解密處理，其秘鑰可以支持不同的長度，最長可以支持到2048 bits，幾種常見的算法包括DES，3DES，RC4和AES。它可以應用在實時語音視頻傳輸，可滿足加密解密快速處理的要求。但是，其存在的問題也是比較明顯的，密鑰交互雙方需要完全獲悉對端可以支持密鑰共享。如果在非常廣泛的部署環境中，SIP網絡中的各種終端就很難保證其良好的兼容性和安全性，特別是針對TLS-1.3 方面的支持缺乏很好的兼容性。asymmetric（非對稱加密）則具備了比對稱加密更安全的密鑰算法。非對稱加密使用了public key（公鑰）和private key（私鑰）的方式進行加密處理。非對稱加密僅使用了public key公開和對端交互，所以安全性得到了很大提升。但是其算法相對比較復雜，當然其處理速度也相對比較慢，比較有名的算法包括Diffie–Hellman（D-H） 和RSA。
在部署使用加密方式時，除了安全因素以外，我們同樣還要考慮部署成本。我們知道，這個世界上沒有存在絕對的事情。絕對安全需要付出極大的部署成本，不同的加密算法需要耗費不同的系統資源。筆者列出一個簡單的示例說明關于不同加密機制導致的不同的資源要求。Charles Shen在其發表的論文中針對TLS加密方式對系統的性能影響有一個比較完整的研究，讀者可以參考其論文來針對加密處理對系統影響做進一步研究。
關于SIP證書（CA）的處理流程
為了實現TLS處理流程，我們需要一個數字證書。用戶可以購買或者免費使用數字證書實現TLS的安全處理。通常情況下，用戶需要從第三方數字證書發放廠家(Certification authority-CA)購買或者申請一個數字證書。市場上證書簽發的廠家很多，絕大部分是國外的廠家。目前市場中主流的幾個證書廠家的市場份額如下，用戶可以參考。
目前可能開源社區用戶使用的比較多的是免費的Let's Encrypt，其他則是商業證書，用戶需要支付費用購買這些證書。因為Let's Encrypt是免費的證書，而且安裝方便，使用的用戶數量也正在穩步增加，它每天簽發的證書接近3百萬，其用戶數量是非常龐大的。
在數字證書中包含了public key（公鑰）和private key（私鑰）。Public key（公鑰）和private key（私鑰）存在著互相綁定的算法關系。具體的申請處理流程和第三方用戶訪問流程如下：
在實際運行環境中，為了讓用戶對加密有一個比較全面的了解，首先，我們介紹一個比較典型的示例，關于安全證書在購物網站的基本工作原理。
讓我們看看具體的證書實現流程細節：
- 首先，用戶訪問購物網站，例如通過80端口。
- 網站會切換到HTTPS通過端口443 訪問購物網站。當然，現在很多網站都使用了443 端口，用戶不需要訪問80端口。
- 購物網站發送一個public key，然后對其生成一個private保存到服務器端。
- 終端用戶通過瀏覽器和public key自動生成一個新的key消息，然后發送到服務器端，服務器端通過這個消息，然后結合保存在服務器端的private key 進行匹配檢查。如果雙方的key匹配，則進行購物付款交易。
客戶服務器購買了商業證書以后，如果用戶訪問此服務器，服務器就會發送一個public key要求進行證書的核實，終端用戶需要訪問第三方的證書發放機構來驗證是否是有效的證書。如果是否都驗證了證書的有效性，則執行下一步的流程。一般用戶終端會接受一些著名機構發放的證書，有時會彈出對話框，用戶需要點擊瀏覽器對話框接受此證書。當然，證書包括了證書發放者名稱，版本，subject，有效期，算法等修改參數。如果證書失效或者其他參數不兼容，則需要用戶重新安裝。
另外一種發放證書的模式就是自簽的證書，顧名思義，就是用戶服務器端用戶自己創建的證書。以下圖例說明了如何實現自簽證書的流程。
客戶端需要接受服務器端的證書以便保證證書的有效性。這里，筆者要提醒用戶，自簽的證書一般僅使用在測試環境，它的兼容性不好，同時可能導致其他的安全漏洞。
在證書的分發中，我們經常會看到一些用戶公鑰基礎設施。這些基礎設施的創建涉及了非常大型的公司或者組織，需要耗費大量的資源和復雜的平臺環境才能實現。基于目前國產化進程的不斷推進，國內很多比較大型的公司提供了類似的服務。
關于TLS的介紹
SIP的安全機制是基于HTTP的安全機制演進而來的。針對SIP安全機制，目前的安全機制通過不同的層級來實現其安全策略，主要的策略包括應用層安全機制，傳輸層安全機制和網絡層安全機制。
前面我們介紹了一些證書和加密機制的概念和功能流程，現在我們把這些必要的技術整合在一起為讀者詳細說明TLS的處理機制。TLS是基于SSL的新的傳輸層安全機制。目前用戶使用的標準規范是TLS-1.2 版本，最新版本支持TLS-1.3。關于TLS-1.3 版本的詳解，讀者可以參考RFC8446。和TLS-1.2相比，TLS-1.3 處理速度比較快，移除了一些舊的安全協議，更新了比較新的安全協議，例如，H-D，AES等，因此其安全性相比1.2版本有了更多保證。以下是激活http的一個關于TLS實戰的具體處理流程：
很多用戶擔心自己的場景中是否使用最新的TLS版本。關于TLS-1.3的版本問題，用戶可以訪問專業的測試網站可參考TLS的版本支持，直接輸入相應的IP地址就可以獲得TLS版本詳情。筆者為讀者提供了一個測試工具示例，用戶可以直接訪問此網站檢查自己的TLS版本，例如瀏覽器的TLS版本等。
https://www.ssllabs.com/
SIP 信令加密和RTP加密
在以上的章節中，我們介紹了簽權授權，證書，TLS等和SIP加密必要的基礎知識，在具體的SIP呼叫環境中，我們需要根據以上基礎知識對SIP加密做進一步的深入的了解。在關于SIP加密的內容討論中，我們主要針對SIP和SIPS，以及RTP加密進行詳解說明。大家應該知道，我們討論加密的話，我們通常僅籠統地說加密這個概念。事實上，在具體的應用場景中，如果對一個SIP呼叫進行加密的話，我們考慮的因素會遠遠超過了我們的想象。在不同的呼叫場景中會面對不同的挑戰，一個SIP呼叫可能僅僅限于內網呼叫，另外一個呼叫也有可能需要穿越多個網絡環境，其呼叫路徑可能涉及了多個hops節點才能最終抵達呼叫目的地地址。很多時候，如果一個SIP呼叫需要穿越多個hops節點時，很多用戶使用了SIPS的方式：（sips:bob@example.com， 而不是sip:bob@example.com的格式）。但是，使用SIPS需要確保全部的呼叫路徑都能支持TLS，如果其中一個hop沒有使用TLS，此呼叫將可能會失敗。因此，在使用SIPS呼叫時，用戶一定要確保TLS的使用和其兼容性支持。在關于SIPS的支持，RFC5630-3.3對TLS支持進行了非常詳細說明，包括了hop-by-hop檢測等問題的討論。以下示例是在呼叫路徑中某些節點沒有使用TLS的情況。
在大部分使用SIP-TLS的場景中，TLS仍然支持的是hop-by-hop的TLS加密方式。這種方式可以針對自己內網環境中的終端，SIP服務器或者IPPBX加密，或者針對自己的SBC加密。因為運營商自己的網絡之間是相互信任的網絡，運營商之間可以不使用TLS。
在以上的解釋中，筆者說明了使用SIPS或者SIP的簡單場景，在實際部署過程中，SIPS仍然需要面對很多的問題，具體表現在以下幾個方面：
- 讀者應該注意，在使用了TLS加密以后，維護方面就相對比較復雜，一些抓包工具不能有效支持其加密文件的解析，在系統用戶維護方面會帶來很多困難。
- 另外，如果使用SIPS的話，傳輸將使用TCP而不是UDP，一些廠家的SIP終端對TCP支持可能不是非常好，因此，在使用SIPS時要注意這個問題。
- SIPS需要正確的DNS配置，支持NAPTR和SRV。但是在實際的應用場景中，仍然面對地址解析的問題。
- 邊緣設備或者終端支持的證書需要進一步完善和統一，這是SIPS部署時需要完善的兼容性支持。
- tls參數在SIP頭支持還是VIA支持的兼容性問題需要用戶進一步確認核實，這樣會導致很多的兼容性問題。目前在SIP頭中支持tls的方式已經被棄用。
這里，筆者根據前面介紹的TLS處理流程，結合SIP呼叫和讀者再重復一次TLS處理流程。TLS支持的呼叫也經過同樣的處理流程，TLS握手成功以后開始SIP INVITE呼叫。
端對端（Hop By Hop）加密方式是目前部署非常普遍的一種加密方式，一般部署在集成商或者簡單的電話系統中。但是，它存在一些問題，例如，Proxy不能讀取SIP消息，甚至告警消息。另外，因為已經SIP已經加密，運營商或者服務提供商所提供的服務可能不能得到完整的支持。最后，如果是跨國的服務的話，端對端的SIP加密是不允許的。從服務端角度來說，Hop By Hop的加密方式則相對比較好一點。如果遇到跨國的測試時，則可以取消加密，呼叫仍然可以正常工作。另外，Hop by Hop 的方式可以支持SIP修改一些SIP頭參數，例如可以修改Record-Route 或Via 頭域。當然，選擇什么樣的加密方式都是有成本的。兩種加密方式同樣會導致不同的語音數據結果，例如，丟包情況，和時延。以下圖例是兩種方式的延遲測試結果，希望讀者一定要注意：
對RTP語音流加密處理機制
我們前面討論了對SIP信令的加密，但是僅對SIP加密仍然不會實現真正的加密，電話系統必須對語音也進行加密。對語音加密的則稱之為SRTP。在下面的內容中，筆者將從幾個主要的方面針對RTP加密進行剖析，這些主要核心要點包括SRTP使用，Crypt和DTLS等相關細節。
SRTP的主要作用當然是確保語音流和RTP Payload的加密安全，同時防范第三方軟件對語音的注入，確保本身語音的完整性。SRTP不使用PKI的方式來交換密鑰，它使用的是Master key的方式。如果直接通過明文的SDP發送key是不安全的，所以必須使用加密的方式來傳輸。如果發起INVITE之前沒有開啟TLS的話，SDP消息中的k就會被暴露出來，這也是非常不安全的。
如何在傳輸中以安全的方式傳輸SDP中的k是一個非常復雜的流程。以下是一個傳輸SDP k的流程圖。這里需要注意到是，在傳輸過程中，用戶需要設置SRTCP來保護第三方侵入，防止對呼叫方強制發送BYE消息，掛斷呼叫。
cipher加密默認使用的是AES，它是一種高級的加密方式。RFC3711標準對此加密方式的類型和算法有非常詳細的說明，AES本身就非常復雜，筆者對此不是太了解，如果讀者希望獲得更多算法的話，筆者建議讀者查閱RFC 3711。我們現在介紹的SDP中的k屬性，它相對比較簡單，所有的k的消息都在交互中進行。另外一種方式就是使用SDP中的crypto，它也是一種交互機制，但是支持了很多參數，而且比較靈活。它主要描述了前一個單播媒體中的cryptographic suite，key 參數和會話參數。注意，crypto必須出現在SDP的媒體中，不會出現在信令中。基本的語法格式為：
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
在以上的舉例中，SDP包含了3個m 媒體流，但是其中的兩個媒體流則使用了RTP/SAVP傳輸，每個媒體流都有自己的crypto。
關于crypto具體的解釋如下：
- tag 1 定義crypto的suite。一般默認是1。
- AES_CM_128_Hmac_SHA1_80 則表示是SRTP使用的cipher。
- HMAC_SHA1_80是一個80bit的認證tag消息。
- Master key的長度是128 bit（前面已經定義為AES_CM_128），默認的最大生命周期是2^20。
- inLine 是一種Key的方式。這里已經明確，inLine 后面的一串字符（PSXXXVBR）。注意，這里也可能是一個URL。
- 1：32這里不是1 是Master Key ID，32 Bytes長。也可以支持更多更多的Master key，這些key未來可能會更新。
我們的示例中使用的是默認的設置。關于crypto suite在RFC4586中有非常詳細的定義，我們這里不再更多討論。如果讀者有興趣的話，也可以參考AES Crypt 免費開源工具來了解其加密命令使用。
以下是一個終端設置的舉例，用戶必須啟動相應的安全設置和參數。注意，不同的終端可能支持的參數有所不同，用戶要注意檢查。
在SDP中的消息舉例中，這里通常出現的兩個crpto中，用戶會首先選擇第一個crpto。另外，讀者一定要注意，因為加密是雙方的安全機制，需要雙方檢查，同時需要IPPBX本身要配置相應的設置，否則可能導致呼叫失敗。
盡管SIP加密方式已經對SIP信令點安全設置了很多復雜的算法，但是仍然缺乏對呼叫方的身份（Caller Identity）認證經過多次轉發的身份保護機制。如果初始的SIP請求發起方經過多個路徑，當初SIP消息的發起者的身份在到達最終目的地之前可能因為安全的問題發生修改。RFC4474對類似呼叫方身份做了安全的保護。RFC4474在頭域中定義了兩個參數值：Identity和Identity-Info來確保發起請求者的安全。Identity負責傳輸用戶有效性的簽名消息，Identity-Info負責對證書簽名者傳輸一個證明信息。
以下圖例解釋了如何通過SIP頭域中的Indentity和Indentify-Info 發送到呼叫請求中的身份消息。
整個身份驗證的流程經過以下幾個步驟：
- 終端發起INVITE消息，Proxy收到消息以后和自簽的證書服務器進行交互。
- 本地Proxy通過證書服務器，使用hash和from header生成本用戶的Indentity。
- 簽名服務器返回證書消息，Proxy在SIP消息中添加證書的Indentity和Indentity-Info（證書發放簽名）。然后對對端Proxy發起一個INVITE消息。
- 對端Proxy收到INVITE消息以后，通過web server 獲取證書信息，然后提取SIP消息中的Indentity和Indentity-Info，結合hash來計算用戶安全身份。
- 如果驗證成功，則對另外一個終端發起INVITE消息。整個驗證過程結束。
注意，RFC4474僅發布了SIP請求中的安全機制，并沒有規定如果發生錯誤時的響應處理機制。響應處理是一個更加復雜的處理流程，希望未來有更多RFC規定來進一步的優化。
通過以上身份的驗證，整個INVITE信息的安全處理結束后，接下來啟動語音的安全認證流程。這里使用了DTLS（Datagram Transport Layer Security）來驗證Indentity和語音的加密處理。以前我們介紹過，TLS不能支持UDP的傳輸，但是實際工作場景中，仍然有很多應用使用UDP。所以，為了滿足UDP的安全處理機制，通過對TLS拓展實現DTLS的安全機制。DTLS可以適用于時延比較敏感的應用場景和VPN（隧道）等場景。在以下場景中，INVITE完成以后，用戶通過DTLS實現對雙方Indentity加密認證，也包括來對語音進行加密。
當然，以上場景僅是一個非常簡單的雙方呼叫的場景，事實上，在DTLS加密的環境中，很多應用層面的功能需要考慮，例如，匿名呼叫的防范，早期媒體流的處理，分拆SIP請求，多個媒體處理的握手認證流程。如果Proxy在處理這些功能處理時不能正確處理DTLS握手的流程，也同樣會導致很多呼叫問題。關于DTLS的規定，用戶可以參考RFC5763進行進一步的研究，我們這里不做更多討論。
上面我們提到了關于對發起呼叫方的安全控制機制，但是，目前仍然沒有看到非常完整的關于呼叫方安全保障的完整的解決方案，除了RFC4474以外，以下規定也對caller的身份做了相關的規定：
- RFC 4474bis-00是RFC 4474的升級，除了header中的identiy以外使用，不僅僅在from header中使用SIP URL，在from header中還增加了Tel的號碼支持。
- STIR（Secure Telephone Identity）是目前專門針對VoIP-to-PSTN規定的標準，主要目的對發起呼叫者的號碼進行保護和確認。因為，在實際電話應用的場景中，大部分的用戶仍然相信普通電話號碼的呼叫，但是因為網絡的介入，PSTN號碼可能最終被其他非法業務利用來進行非法呼叫。此標準專門針對非法呼叫，語音語音郵箱攻擊等業務設計了不同的機制。具體規定請讀者查閱STIR證書草案。關于最新美國FCC對此規范的強制執行的細節，讀者可以參考鏈接。
- P-Asserted-Identity：服務提供商對號碼服務提供的認證用戶保護。其中，在SIP INVITE的呼叫中包括了caller id消息，Proxy 通過在SIP頭中添加P-Asserted-Identity對呼出的網絡聲明其真實性。
- PSTN網絡中的ISUP通過S/MIME 支持了SIP的SDP加密，需要說明的是，SIP header 不會被加密，仍然需要通過TLS處理。此圖例中，SIP經過兩個Gateway 傳輸，最后到達另外一邊的終端，并且通過MIME來傳輸ISUP消息。
SIP trunk 加密
在前面的提到的安全策略中，我們所探討的都是基于本地認證機制來實現的。這些解決方案相對比較復雜。如果用戶部署了企業IPPBX的話，企業IPPBX通過SIP 中繼實現外部呼叫連接的話，可以通過以下方式實現：
企業用戶的IPPBX 使用TLS時一般需要注意以下幾個方面的問題：
- 企業PBX必須自己對運營商做認證，使用數字證書或者自簽證書實行。運營商可以實現對企業IPPBX的控制和計費等功能支持。
- 如果使用TLS的話，必須對所有介于企業PBX和運營商之間的信令進行加密，所有代理服務器需要TLS支持。
- 所有企業PBX使用的證書對運營商來說是有效的證書。
- 公司可以使用自簽證書來實現對運營商的認證，但是，運營商必須經過調整能夠支持此證書。
除了企業IPPBX使用SIP加密的trunk來實現運營商和企業呼叫之間的加密處理以外，企業IPPBX也可以通過防火墻接入或者SBC的方式來實現。使用對SIP支持比較好的防火墻來對SIP進行安全處理。事實上，類似的方法也可能遇到很多問題。
使用IP-Sec設備或者SBC來連接，通過IP-Sec設備來對所有語音設備進行加密處理。這里要注意，因為IP-Sec設備會處理全部的信令和媒體，增加了很多網絡開銷，帶寬要求也會隨之增加。從目前市場情況來看，如果針對VOIP或者SIP語音應用場景來說，可能SBC是最佳的解決方案。在后期的討論中，我們會重點介紹SBC的作用，讀者可以了解更多比較全面的關于SBC的解決方案。
鼎信通達SBC對接企業IPPBX示例
安全攻擊和響應處理機制
在前面的章節和本章節的前幾個部分我們重點從技術的角度討論了關于SIP中安全機制的設置和一些技術概念。在以下的圖例中，我們看到VOIP用戶仍然面對很多的安全問題，包括上面提到的那些問題，這些安全問題涉及了整個網絡的方方面面，同時也涉及了公司安全策略和各種規章制度。以下是關于SIP網絡安全在不同層級的安全威脅舉例：
研究人員Dimitris Geneiatakis發表的關于幾種SIP安全的匯總：
如果我們回到具體的現實環境中，SIP安全的問題主要包括以下幾個方面：
IMS 網絡安全威脅
通常情況下，VOIP電話系統都會受到至少五種以上的攻擊或侵入。因為篇幅的關系，我們這里不展開討論所有的攻擊方式和細節。關于以上攻擊方式的介紹，請讀者查閱SANS Institute Reading Room 發表的文章，作者重點介紹了各種攻擊方式的概念和基本原理。哥倫比亞大學的SIP研究機構也發布過關于SIP安全的介紹，用戶可以查閱。如果讀者對安全方面的加密算法有非常濃厚的興趣，可以查閱Amruta Ambre發表的關于算法加密討論的文章。以下是一個示例通過修改SIP信息，把真正的呼叫轉入到侵入者自己的終端。因此，用戶必須使用TLS/PKI/SRTP對信令和語音加密。
更多關于使用工具侵入或偽裝的操作方式，請參閱筆者提供的參考資料。
另外一個案例是一個所謂通過釣魚的方式獲取用戶信息。很多時候，釣魚者會給用戶發送郵件或者短信通知用戶呼叫一個電話號碼（例如：07558101000），說銀行有什么業務需要客戶馬上聯系銀行。如果用戶呼叫上面的號碼的話，這時這個號碼會呼叫網關的號碼，然后通過VOIP網關修改路由，最后轉呼到銀行的電話號碼上（真正的銀行號碼：07558100000）。如果用戶不小心的話，可能聽到銀行的呼叫就會按照銀行系統的要求輸入用戶密碼信息（323345），這時，釣魚者可以通過SIP線路上的DTMF按鍵音獲取到用戶的真正的密碼消息。當然，這樣的后果是用戶信息被暴露。
另外，非法的盜打情況也可能經常發生，因為很多國際長途的話費是非常高昂的，犯罪分子利用國際話費結算的差價獲利。中國國內經常會看到電話騷擾，電話盜打，電話欺騙的新聞。國外也有類似的問題發生。
國家安全監管機構，VOIP行業，設備解決方案廠家，用戶等都有非常明確的安全機制來防范安全問題，但是可能仍然會出現安全問題。除了設備或者軟件層面的安全機制以外，我們今天介紹幾個防范措施來最大限度保證用戶的VOIP網絡安全。目前，有效地防范VOIP網絡攻擊的手段很多需要公司系統管理員從不同角度來進行排查，其中也包括了對公司員工的安全教育，公司規定的安全規則，技術手段，安全設備部署等。
關于技術方面的討論我們前面的章節部分和以前的講座中已經做了很多分享，現在，我們再補充一點來自于政府權威機構和研究機構的一些安全建議。
美國國家安全監管機構FBI 建議，FBI的建議中，包括了從地理位置的安全處理，設備的安全處理，人員安全培訓，管理員的安全培訓，采購商的安全處理等方面的內容。以下圖例解釋了多種網絡設備在安全方面的設置和相關的公司規章制度的設立，值得讀者去參考。
美國負責計算機安全的機構NIST也給出了幾個方面的建議，讀者可以作為安全運維等指導：
- 網絡數據和語音分離，私有網絡和公網的分離。
- 使用支持ALG的防火墻或者SBC來提升安全性能。
- 使用比較嚴格的安全認證機制來防范被破解。
- 使用TLS加密方式。
- 盡量少用個人電腦軟電話或者來自未經授權的第三方基于SIP的軟電話。
SIP安全測試工具使用
因為VOIP網絡中可能出現很多網絡安全的問題，公司層面雖然制定了很多安全策略，管理人員也部署了針對安全機制的設備，但是仍然需要一些非常有經驗的系統管理員來進行維護檢測。技術人員必須了解一些安全工具，以免讓攻擊者侵入。俗話說，知己知彼才能百戰百勝。現在，我們羅列幾個已經在VOIP方面使用多年的工具，以便幫助管理員進一步防范攻擊者的攻擊。
以下列表列出了VOIP工程師可能經常使用的排查工具和平臺，大家可以學習：
- 使用Wireshark 工具抓包解析數據：
- Nmap 掃描網絡
- SIPScan和HoverIP：掃描端口，IP地址。
- Authtool 獲取認證的工具，密碼破解。
- 進行洪水工具的工具：
- linux 工具：inviteflood，registerflood
- SIP 信令篡改工具：erase_registrations（刪除注冊），add_registrations（添加注冊流程)
- Linux 系統缺陷檢測工具：protos SIP test suite
- Linux 工具：reghijacker（攻擊注冊流程），authtool（竊取認證消息）
- Linux 工具：sip_rogue（偽裝B2BUA，或者SIP Proxy）
- Linux 工具：teardown 對已創建的SIP 會話拆線工具，自動結束終端通話。
- Linux 工具：check_sync 創建一個SIP 終端重啟命令。
- Linux 工具：redirector 對SIP呼叫執行重定向，可能轉接到非法服務器。
- Linux RTP 語音注入工具：rtpinjector 對RTP語音進行注入。
- “正式的”Linux平臺工具：Asterisk，FreeSWITCH， SIPp以上這些工具或平臺是正規的開源語音平臺，用戶可以通過這些平臺開發呼叫中心，IPPBX，壓力測試等相關業務。
總結
在本文章中，筆者通過基本的安全認證授權背景知識介紹，SIP加密原理，證書簽發，證書驗證流程和具體的SIP呼叫簽權流程介紹了基本的SIP加密方式，并且介紹了SIPS的部署問題，關于TLS加密包括端對端部署的問題，各種加密算法和最新的TLS-1.3使用情況。另外，筆者介紹了各種SIP網絡中所面臨的安全隱患和IMS網絡中的安全威脅，關于針對SIP網絡安全中需要采用的響應措施，SIP trunk加密和企業應用中應該采取的措施和SIP安全工具等管理層面的討論。網絡安全是一個永恒的話題，SIP安全管理也是一個持久關注的話題。為了滿足不斷更新的SIP網絡部署環境以及各種軟硬件的安全隱患，用戶需要通過認知層面的提升才能面對最新的安全問題。筆者自己也缺乏非常充足的知識儲備來面對最新的技術挑戰，筆者希望借此文章對SIP網絡安全問題進行更加深入的討論開始，僅當拋磚引玉，希望和讀者一起共同提高自己的知識認知。
參考資料：
https://www.slideshare.net/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol
https://www.cs.columbia.edu/~hgs/papers/Shen1008_TLS.pdf
https://www.scitepress.org/Papers/2007/24335/24335.pdf
https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-58.pdf
https://github.com/miconda/md5ha1
https://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf
https://allenluker.WordPress.com/2014/07/16/sip-digest-authentication-part-1-sip-registration-method/
https://github.com/OlegPowerC/SIPdigestCalculator
https://datatracker.ietf.org/doc/rfc8760/
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443829&idx=1&sn=a32214c98b2c4c877e8dc624769323dc&chksm=8465bbefb31232f950609bd5b2c9eddf48860f762c6123603c317afa0a0e836b58c10442c590&token=730889991&lang=zh_CN#rd
https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443879&idx=1&sn=f54fc7f5451baf304b3ae2a77ccb269f&chksm=8465bbbdb31232ab12e0acc204ab588316a51d6918b181e55793aaf64d8876493341563387ad&token=895020875&lang=zh_CN#rd
https://www.clickssl.net/blog/what-is-symmetric-encryption#:~:text=%20Symmetric%20Encryption%20Algorithms%20%201%201.%20DES,3.%20AES%20%28%20Advanced%20Encryption%20Standard%29%20More%20
Charles Shen，The Impact of TLS on SIP Server Performance: Measurement and Modelling。
http://www.ciia.org.cn/news/6132.cshtml
https://datatracker.ietf.org/doc/html/rfc8446
https://www.aescrypt.com/linux_aes_crypt.html
