第三章 SIP 通話建立信令流程
3.5 啟用 TLS 安全機制之通話建立流程
3. TLS Application Data (INVITE)
5. TLS Application Data (180 Ringing)
PDD
2. TLS Handshake 1. TCP 3-way Handshake
4. TLS Application Data (100 Trying)
TLS
SIP Message (with TLS)
TCP ACK
TCP ACK
UAC SIP/IMS Core
圖 3.5: 通話建立流程 – 啟用 TLS 安全機制
TLS 協定提供資料完整性 (integrity) 與機密性 (confidentiality) 的保護,以及收送雙 方身份真實性的認證。IETF 之 RFC 3261 [2] 將 TLS 定為 SIP 主要的安全機制,3GPP 也 將 TLS 納入 IMS 規範 [20] 中,並可與 IPSec (Internet Protocol Security) [35] 安全機制共 同運作。圖 3.5 說明 UAC 與核心網路之間使用 TLS 安全機制進行傳輸的通話建立流程。
由於 TLS 建置於 TCP 連線之上,所以 UAC 與核心網路必頇先以 TCP 三向交握建立兩端 的連結 (圖 3.5 步驟 1),接著才使用 TLS 交握程序來建立安全連線 (圖 3.5 步驟 2)。
30
31
步驟 2. 伺服器由客戶端的 Client Hello 訊息中選擇接受的參數,並且以 Server Hello 訊 息向客戶端回覆。Certificate 訊息用於傳送伺服器公開金鑰 (public key) 與認證 機構之憑證,以提供客戶端認證伺服器身份的真實性。若伺服器也要求客戶端 進行身份認證,會在傳送 Certificate 訊息之後,再發送 Certificate Request 訊 息告知客戶端身份認證的請求。最後伺服器以 Server Hello Done 訊息來結束此 初步協商。
步驟 3. 若伺服器傳送至客戶端的訊息中 ,含有要求客戶端身份認證的 Certificate Request 訊息,客戶端將利用 Certificate 訊息來傳送自己的公開金鑰與認證機 構憑證給伺服器。Client Key Exchange 訊息用來告知伺服器後續通訊所用的金 鑰資訊,此訊息會使用伺服器的公開金鑰來加密傳送,以確認伺服器公開金鑰 正確性。若客戶端先前已傳送 Certificate 訊息,此時會再以 Certificate Verify 訊息向伺服器證實其公開金鑰與私密金鑰為自己所擁有。Change Cipher Spec 訊息用於啟動雙方所協商的安全服務。最後客戶端再以加密的 Finished 訊息,
告知伺服器完成協商。
步驟 4. 伺服器利用 Change Cipher Spec 訊息,告知客戶端開始啟動安全服務,最後傳 送加密的 Finished 訊息,告知客戶端完成協商。
在 TLS 交握過程中,若採取「伺服器與客戶端相互認證」的方式,伺服器需要多傳 送一個 Certificate Request 訊息向客戶端要請求認證,客戶端也需多傳送 Certificate 與 Certificate Verify 訊息給伺服器。當 UAC 與核心網路之間的安全連線建立完成,後續訊 息將會由發送方加密並包裝成 TLS Application Data 訊息傳送,再由接收方負責解密。如 圖 3.5 步驟 3 至 5,其 TLS Application Data 訊息分別包裝了 SIP 之 INVITE、100 Trying 與 180 Ringing 訊息加密後的結果。UAC 在 TLS 安全機制下,PDD 會多出 TCP 三向交 握、TLS 交握以及上述步驟 3 至 5 訊息加解密所使用的時間。
32 處理器以及 256MB ROM 與 64MB RAM,使用的作業系統為 Microsoft Windows Mobile®
6.0 Professional,並內建 IEEE 802.11 b/g 無線網路 (表 4.1 之 NIC1) 與 HSDPA (High Speed Downlink Packet Access) 蜂巢式無線電通訊模組 (表 4.1 之 NIC2)。本實驗使用開放原始 碼 Fraunhofer FOKUS Open IMS Core [36] 做為核心網路軟體,並安裝於 Ubuntu 9.10 作業 系統上。Open IMS Core 以 3GPP IMS 網路架構為主,並能同時服務 IETF 所規範的 SIP UA,提供了後續實驗所需的各種功能。本論文所開發之 SIP/IMS UA 程式碼可針對