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