主頁 / IP電話加密SIP TLS與SRTP是甚麼？ IP電話加密SIP TLS與SRTP是甚麼？ IP 電話的通話在網絡上以封包形式傳送，若未加密，同一網段內的抓包工具便可還原號碼、帳號甚至整段話音。業界的標準做法分兩層：以 TLS 保護 SIP 信令，以 SRTP 保護話音串流。兩者針對不同的資料、由不同標準定義，亦需分別設定。本文說明兩層加密各自保護甚麼、密鑰如何交換，以及部署時常見的落差。
兩層加密的分工：信令與媒體分開處理 IP 電話的通話由兩股獨立的流量組成。第一股是信令，負責建立、修改與結束通話，內容包括撥出與被撥號碼、註冊帳號、通話狀態與媒體協商參數；第二股是媒體，即實際的話音封包。兩股流量使用不同協定，因此加密亦分別處理。
信令一側由會話啟動協定（SIP）承載。RFC 3261（SIP: Session Initiation Protocol）定義了 SIPS URI 機制，文件說明撥往 SIPS URI 的通話「保證安全、加密的傳輸」，並指出支援 TLS 的用戶代理必須支援 SIPS URI 方案。同一文件在傳輸部分列出預設埠號：SIP 在 UDP、TCP 與 SCTP 上預設為 5060，而在 TCP 之上使用 TLS 時為 5061。
媒體一側由安全實時傳輸協定（SRTP）處理。RFC 3711（The Secure Real-time Transport Protocol）的摘要說明，SRTP 是實時傳輸協定（RTP）的一個設定檔，「可為 RTP 流量及 RTP 的控制流量（即 RTCP）提供機密性、訊息認證與重播保護」。
兩層必須一併啟用才算完整。只開 TLS 而未開 SRTP，號碼與帳號受保護，但話音仍以明文傳送；只開 SRTP 而未開 TLS，話音已加密，但用以解密的密鑰若經未加密的信令傳遞，等同把鎖匙貼在門上。
SIP TLS保護的內容與逐段特性 TLS 在 SIP 上的作用，是把信令訊息放進加密通道傳送，令中途的旁觀者無法讀取或篡改。受保護的內容包括撥出號碼、被撥號碼、註冊用的帳號與認證資訊、通話的建立與結束訊息，以及媒體協商的描述。若信令未加密，這些資訊在網絡上是可讀的文字，帳號與撥號記錄都可被擷取。
需要理解的一項特性是逐段而非端到端。RFC 5630（The Use of the SIPS URI Scheme in SIP）討論 SIPS 與單純使用 TLS 的分別時，明確處理「是否即等於在每一段使用 TLS」的問題，並指出目前並無機制可提供端到端安全的指示。實務含意是：企業與電訊商之間這一段可以確保加密，但通話經對方網絡再轉往其他營運商之後的路徑，並不在企業控制範圍內。
設定層面有幾項要點。TLS 需要憑證，伺服器端憑證應由電話與伺服器都信任的憑證機構簽發，自簽憑證雖可運作，但電話端需匯入信任鏈，維護成本較高。憑證到期是常見的故障原因：憑證過期後電話無法註冊，徵狀是全體內線同時失效，因此憑證到期日應納入定期維護清單。埠號亦需一併確認，防火牆若只放通 5060 而未放通 5061，啟用 TLS 後註冊便會失敗。
SRTP如何加密話音：加密、認證與重播保護 SRTP 提供三項保護。RFC 3711 在預設變換的規定中指出，計數器模式的 AES 應為預設加密演算法，預設密鑰長度為 128 位元，預設的會話鹽值密鑰長度為 112 位元；訊息認證方面，同一文件規定 HMAC-SHA1 應為預設的訊息認證碼，預設的會話認證密鑰長度為 160 位元，並在安全考量中指出應使用完整的 80 位元認證標籤。第三項是重播保護，用以阻止攻擊者把擷取到的封包重複送出。
三項保護的目的各異。加密令旁聽者無法還原話音內容；訊息認證令封包被篡改時可被偵測，例如混入偽造的話音；重播保護則防止把先前擷取的封包重新注入通話。RFC 3711 同時說明，SRTCP 亦有對應的保護，但當中的訊息認證功能是必需的，不可停用。
一項常被誤解的技術細節是標頭並不加密。RFC 3711 第 9.4 節說明，在 SRTP 中 RTP 標頭以明文傳送，以便進行標頭壓縮，這意味著承載類型、同步來源識別碼與時戳等資料對旁聽者是可見的；同一節指出 SRTP 屬低成本方案，容許標頭壓縮以減少帶寬佔用，是否需要保護標頭則由終端的政策決定。實務上這代表旁聽者仍可知道「有一通通話正在進行、使用哪種編碼」，但無法還原話音內容。
密鑰如何交換：SDES與DTLS-SRTP SRTP 本身只定義如何以密鑰保護媒體，密鑰如何送到對端由另一組協定處理，常見有兩種做法。第一種是在信令中夾帶密鑰。RFC 4568（SDP Security Descriptions for Media Streams）定義了單播媒體串流的 SDP 加密屬性，其摘要說明該屬性「描述一個加密密鑰與其他參數，用以在單一訊息或一次來回交換中為單播媒體串流配置安全」，並明確指出「SDP 加密屬性需要一個資料安全協定來保護該 SDP 訊息」。文件示例中的屬性寫法為 a=crypto，加密套件如 AES_CM_128_HMAC_SHA1_80。
這種做法的前提條件相當關鍵。RFC 4568 的安全考量指出，把含有內嵌 SRTP 主密鑰的 SDP 訊息以明文傳送，會令 SRTP 的安全性失效；同一節亦提到當 SDP 訊息的通訊路徑經過會檢視訊息內容的中間系統時，安全性需要另作考慮。換言之，採用這種密鑰交換方式時，SIP TLS 並非可選項，而是必要條件。
第二種做法把密鑰交換移到媒體路徑上。RFC 5764（DTLS Extension to Establish Keys for SRTP）的摘要說明，該文件描述一項數據報傳輸層安全（DTLS）擴展，用以為 SRTP 與 SRTCP 流建立密鑰，而「DTLS 密鑰交換在媒體路徑上進行，與任何頻外信令通道無關」。這種方式令密鑰不出現在信令中，即使信令經過中間系統亦不致洩漏密鑰，是較新部署的常見選擇。設定時需確認兩端支援的方式一致，否則協商會失敗或退回未加密狀態。
部署要點與常見落差 啟用加密後最常見的問題，是設定看似完成而實際並未生效。宜以三項指標核對：電話註冊是否經 TLS 埠完成、通話中的媒體是否顯示為 SRTP，以及在網絡上抓包確認話音載荷無法直接播放。部分系統在協商失敗時會自動退回未加密模式以保持通話可用，這種行為便利但危險，若安全要求嚴格，應設定為強制加密而非可選加密，並接受協商失敗時通話無法建立。
相容性是第二類問題。舊型號電話、傳真閘道、警報撥號器與部分閘道設備未必支援 TLS 或 SRTP；同一系統內混合新舊設備時，宜按設備分組設定，能加密的走加密設定檔，不支援的另設一組並以網絡分段補償。維基百科〈Secure Real-time Transport Protocol〉條目亦指出，在 RTP 應用中使用 SRTP 屬選用性質，即使採用 SRTP，加密與認證等功能亦可分別啟用或停用，唯一例外是 SRTCP 的訊息認證，因此不能假設對端啟用了全部保護。
第三類是運維與效能。憑證到期、系統時間偏差、憑證主機名稱與實際連線名稱不符，都會令 TLS 握手失敗；建議把時間同步與憑證更新一併納入定期檢查。效能方面，加密對現代電話與伺服器的負擔一般有限，但在大量並行通話的閘道上仍需確認處理能力。此外，加密令通話錄音與問題排查的難度上升，錄音應在系統端而非網絡側擷取，排錯亦需依賴系統日誌而非抓包還原內容。
香港企業的加密部署與合規考慮 香港企業採用加密通話的推動力，多來自客戶資料保護的要求而非單純技術偏好。處理個人資料的行業——例如醫療、教育、法律、保險與金融——在通話中經常涉及身分、病歷或帳戶資料，若通話在公司網絡內以明文傳送，任何接入該網段的裝置都有機會擷取。加密媒體與信令屬合乎比例的技術保護措施，亦便於在內部審核或客戶盡職審查時說明。
本地辦公室的網絡架構亦影響加密的必要程度。多數寫字樓單位以同一台交換機同時承載電話、電腦、無線接入點與攝影機，訪客無線網絡有時亦共用同一組設備。這類混合環境下，即使已用 VLAN 分隔語音流量，設定失誤或裝置接錯埠仍可能令語音流量暴露；SRTP 提供的是在網絡分隔之外的第二層保障，兩者宜並用而非互相取代。
跨境與雲端服務是第三項考慮。香港公司常用境外的雲端電話服務或分支機構互連，通話需經公網傳輸，加密的重要性比純內網部署更高。實務建議有三點：與服務供應商確認其支援的加密方式與密鑰交換機制，並要求書面說明；在公司防火牆上開放 TLS 所需埠並限制來源；以及在合約與內部政策中記錄通話加密的範圍，明確指出加密只覆蓋企業可控的網段，通話進入公眾電話網絡後不再受同一機制保護，避免對外承諾超出實際能力。