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