Voice over IP & VoIP Security 國立成功大學 資通安全研發中心主任 電機系暨電腦與通訊研究所副教授 計算機與網路中心網路作業組組長 李忠憲　

Sea Ray Sport Boat September 16, 2006, Miami

VoIP Thief On The Run By hacking legitimate VoIP services and resell some 10 million minutes, Edwin Pena, 23, was able to pay for the Sea Ray as well as three luxury autos by acting as a fraudulent wholesaler of VoIP services.

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

VoIP Overview Born of VoIP Industry H.323 Standard VoIP Phone --- VocalTech 1995 H.323 Standard H.323 by ITU-T for LAN Multimedia (1996) Industries VoIP Gateway, Gatekeeper, Enterprise GW, IAD Mainly Used for Saving Money in Enterprise Reasons for Speed Down Infrastructure Bottleneck New Technologies Wait for a good cut-in point IAD: Integrated Access Device

VoIP Developing New Technologies Ready MGCP, MEGACO/H.248, SCTP/M3UA, SIP/SDP IETF-like Protocols New Products Developed Most Upgraded from H.323 Products Support New Technologies as well as H.323 VoIP Infrastructure Softswitch, Trunk GW, SS7 Signaling GW (SS7 over IP) Market Re-Booming IETF Technologies Dominate SIP Telephony Being Widely Accepted ENUM for IP/PSTN Convergence Being Developed Softswitch vs. SIP Softswitch: Mainly for Class 4/5 Switch Replacement SIP: Provide Telephony from IP’s Point of View

VoIP Status VoIP Infrastructure Ready ENUM for IP/PSTN Convergence Product and Service Start to Boom Technologies Trend with Cost Saving Driving Force of M-Taiwan & WLAN & WiMAX Mandatory in Future All-IP Network SIP Dominating SIP Telephony/CO Signaling/Multimedia Service/3G Key Technologies for IP/PSTN Convergence VoIP in 3G and B3G 3G IMS VoIP over WLAN/Cellular Integration

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

H.323/SIP 通訊協定 H.323 SIP 發展時間 較早 較晚 開發動機 節省電話費 彌補 H.323、MGCP缺點 技術差異性 協定，雖然已升級到第 版,但仍舊建構在舊有的 術之上 SIP為最新的VoIP通訊協定，開發 因為改善舊有技術的瓶頸和缺點 廠商進入門檻 低 較高 語音話質 較差 有品質控管機制來確保話質，較優 對公司原有網路的影響 會將網路速度減慢 50％且 對網路頻寬要求較多 可支援網路環境下各種不同 IP 態，頻寬要求較小 系統當機時 所有安裝客戶均無法相 通話 客戶通話完全不受影響，一樣繼 保持暢通 容量限制 約僅能支援 300~500個 戶 無容量限制，可以無上限地擴充 相容性 較難與以後微軟所推的 SIP新協定相通 可以和 H.323、MGCP協定相通， 被排擠的窘境

為何 H.323漸漸被SIP通訊協定所取代 1. 協議功能模組比較: SIP協議功能模組中用戶代理等價於一個H.323 協議 —TCP協議，所以呼叫建立需要兩個 連接階段：TCP連接建立和呼叫連接建立。 3. 呼叫控制業務: SIP和H.323都支持呼叫保持、呼叫轉移、呼叫前轉、呼 叫等待、電話會議和其他補充業務。 4. SIP的第三方控制: 第三方控制是指不參與會話的第三者具建立呼叫的能 力，這個業務特徵目前只有 SIP具有。 5.能力交換 :能力交換就是彼此交流各自對媒體流的處理能力確定雙方共有 的能力，從而確保多媒體信號被雙方接受。 6.服務品質: 服務品質包含很多不同方面的指標，一個和多媒體流相關的 QoS參數包括帶寬、最大時延、時延抖動封包丟失率。

7.獨立於接入： SIP 是一種純信令協定，因此它可以用於建立與任何 類型的接入網路的話路。 8.話路和業務獨立： 任何情況下， SIP都不限制或定義可以建立的話 路的類型。 9.協定融合： 在當今的無線網路中，有許多不同的協定被設計用來提 供不同業務。SIP是在分組交換域中提供所有業務的融 合協定，它還統一了固定和無線領域。 10.SIP 的商業價值收入商機： 新的融合多媒體業務可以部署在 GPRS、UMTS、xDSL、WLAN等與接入獨 立的域中，因此，即使在推出 3GPP R5 版本 之前，運營商也可以開始創收。 11.經濟高效： 由於 SIP 是與接入獨立的協定，無線運營商將需要投資構 建通用於它們運營的多種接入網路的基礎設施。 12.互聯互通： 許多領先的廠商以及大型運營商選擇 SIP 作?在通用網路提 供融合業務的多媒體協定。

The SIP Trapezoid

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

Firewalls and NATs Behind NAT/Fs Protect a private network from the public network Maps a set of IP addresses to another set of IP addresses Behind NAT/Fs Internal address are not reachable: Easily initiate outbound connections, but more difficult to receive incoming calls

Full cone (FC) NAT/F A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port Any external host can send a packet to the internal host, by sending a packet to the mapped external address.

Restricted cone (RC) NAT/F (1/2) Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.

Restricted cone (RC) NAT/F (2/2)

Port restricted cone (PRC) NAT/F A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.

Symmetric (S) NAT/F (majority) A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host

防火牆/NAT的種類 NAT Type Address binding Port binding Bindings per session UDP NAT TCP NAT Session direction Full Cone no -> 1 yes <-> Restricted Cone Port Symmetric NAT

Two scenarios Private scenario Public scenario

NAT/F 造成的問題 Hard to make incoming connections A media stream Traffic sent to a device on the public network will be dynamically assigned a specific port number at the public address. Initialing an outbound connection is easy, but receiving an incoming call is more difficult, because the internal extension numbers are non-routable from the public- network. ─ Some applications break peer-to-peer protocols such as SIP SIP clients must identify the IP address and ports they will use to receive media streams (in payload of their signaling messages) But they don’t know their externally visible addresses

解決跨越NATs/防火牆方法 1: Universal Plug and Play (1/2) pushed by Microsoft 簡化家庭或企業中智慧設備的連網過程． 透過網路自動彼此連接在一起，而且連接過程中無需用戶的參與和使用中央伺服器． 係基於TCP/IP協定和針對設備彼此間通訊而製定的其他Internet協定． 不依賴於特定的設備驅動程式，而是使用標準的協議 UPnP設備可以自動探索網路並配置網路地址設定． ⊙ NAT穿越技術方式： Voip應用程式先對是否位於一個具有UPnP能力的NAT設備進行檢測。 應用程式將獲得共用的Public IP地址及Port，為NAT做Signaling及media資訊流使用． VoIP使用端就可以將此資訊加入Voip signaling建立通話. 此通話建立後，使用的是public IP，做點對點的傳輸

解決跨越NATs/防火牆方法 1: Universal Plug and Play (2/2) UPnP 缺點 ─ 1.NAT及Voip Client必須支援Upnp ─ 2.Firewall/NAT設備廠商支援Upnp少 ─ 3.適用於小型企業或家庭網路 ─ 4.無法解決由防火牆外對內主動連線問題 ─ 5.安全性問題：對外部開啟一個pinhole，可讓外部Upnp Client動態控制．

解決跨越NATs/防火牆方法 2: STUN (1/2) Simple Traversal of UDP Through Network Address Translators (RFC 3489 ) ─ an application-layer protocol that can determine the public IP and nature of a NAT device that sits between the STUN client and STUN server. ─ Client-server Interrogations

解決跨越NATs/防火牆方法 2: STUN (2/2) 需要在NAT外部架設 STUN Server Client 端需有特殊的 STUN Client 功能 無法穿透 symmetric NAT 未來會被ICE所整合

Simple Traversal of UDP through NAT (STUN) request server Client server N N Determine how if NAT/F exists and how It maps

Security consideration Attacks on STUN Ⅰ:DDOS Against a Target Attacker provie a large number of clients with the same faked MAPPED-ADDRESS that points to the intended target Ⅱ:Silencing a Client Provide the client with a faked MAPPED-ADDRESS that routes to nowhere Ⅲ:Assuming the Identity of a Client The faked MAPPED-ADDRESS points to the attacker themselves. Ⅳ: Eavedropping

Countermeasures I: networks with STUN clients implement ingress source filtering (RFC 2827) II: STUN server be run on hosts dedicated to STUN III: client verifies the credentials provided by the server IV: encryption and message integrity provided with these protocols

解決跨越NATs/防火牆方法 3: TURN ─ 主要是為了解決 symmetric NATs ─ 必須要架設 TURN Server ─ 未來也會被包含進 ICE

Traversal Using Relay NAT (TURN) Server Allocate requrest TURN Client data data destination N N Consumes a lot of BW

解決跨越NATs/防火牆方法 4: ALG Application Layer gateway ─ It Understands the signalling messages and their relationship with the resulting media flows. 能夠識別Signalling messages及相關Media Flow的關係，並完成所需要的一些轉換功能，例如：H.323/MGCP/SIP訊息內的地址轉換。 ─ It can modify the signalling to reflect the public IP address and ports being used by singalling and media traffic. ALG可以替代NAT/PAT完成地址轉換功能，而且其應用不會受到NAT/PAT的影響

解決跨越NATs/防火牆方法 5: Interactive Connectivity Establishment (ICE) Unifies both STUN and TURN Finding all the possible combinations of IP addresses/ports Accumulated and included in the SDP body (ordered list of media attributes called alts) Send media to the first alt in the list … Under development Only media issue, not signaling issues─ 非 protocol 而是 framework

Proprietary solution (ex Skype) Clients form an overlay network Choose some public IP as super node (SNs) Client keeps a list of SNs Call signaling (using TCP) Both have public IP directly exchange data using UDP No both public IP Use SN to forward data For symmetric VoIP NAT/F traversal Require public server that forward packets Become target of denial-of-service attacks

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

NIST Solutions to the VoIPsec Issues Encryption at the End Points Secure Real Time Protocol (SRTP) Key Management for SRTP – MIKEY Better Scheduling Schemes Compression of Packet Size Resolving NAT/IPsec Incompatibilities

Encryption at the End Points endpoints must be computationally powerful enough to handle the encryption mechanism typically endpoints are less powerful than gateways, preferable for the data be encrypted between the endpoint and the router (or vice versa) the increased processing power of newer phones is making endpoint encryption less of an issue.

Secure Real Time Protocol (SRTP) (1/2) RTP is considered insecure; modified RTCP (Real-time Transport Control Protocol) data could even lead to an unauthorized change of negotiated quality of service SRTP was being standardized at the IETF in the AVT working group. (RFC 3711 in 2004) SRTP is independent of a specific RTP stack implementation Multimedia Internet Keying (MIKEY) has been designed to work with SRTP

Secure Real Time Protocol (SRTP) (2/2) AES in counter mode is the default algorithm for encryption pre-defined authentication transform is HMAC-SHA1 default session authentication key-length is 160 bits default authentication tag length is 80 bits a 128-bit master key from the key management.

SRTP provides increased security Confidentiality for RTP and RTCP by encryption of payloads Integrity for the entire RTP and RTCP packets, together with replay protection possibility to refresh session keys periodically permits upgrading with new cryptographic algorithms salting keys to protect against pre-computation attacks Security for unicast and multicast RTP applications

Key Management for SRTP – MIKEY MIKEY: independent of and easily integrated in a multimedia communication protocol (SIP, H.323, …) Establishment of key material within a 2-way handshake, therefore best suited for real-time multimedia scenarios Four options for Key Distribution: Preshared-key Public-key encryption Diffie-Hellman key exchange protected by public-key encryption Diffie-Hellman key exchange protected with preshared-key and keyed hash functions Re-keying & multicast Support

Better Scheduling Schemes A few large packets can clog the queue long enough to make the VOIP packets over 150 ms late (head-of-line blocking), effectively destroying the call One solution implemented in the latest routers is to schedule the packets with QoS prior to the encryption phase QoS prioritizing can also be done after the encryption process provided your encryption procedures preserve the ToS bits from the original IP header in the new IPsec header. Still neither the pre-encryption or post-encryption schemes actually implement QoS

Compression of Packet Size cIPsec: a version of IPsec that compresses the internal header of a packet down to approximately four bytes compression puts more strain on the CPU and memory capabilities of the endpoints the time lost to compression was made up for at the encryption phase, as the crypto-engine is more efficient with the compressed packets

Resolving NAT/IPsec Incompatibilities Realm-Specific IP (RSIP): a replacement for NAT and provides a clear tunnel between hosts and the RSIP Gateway. RSIP supports both AH and ESP IPv6 Tunnel Brokeran:IPv6 tunnel as an IPsec tunnel, and encapsulates an IPv6 packet in an IPv4 packet IP Next Layer (IPNL):a new layer into the network protocols between IP and TCP/UDP UDP encapsulation: most likely widespread, supported by IETF ESP: encapsulating security payload

Basic Security Mechanisms 1) Securing the SIP Session Management HTTP Authentication Secure MIME (S/MIME) TLS IPsec 2) Securing the Real-time Media Streams Secure RTP (SRTP)

Securing the SIP Session Management 在RFC3329這份文件中定義了SIP user agent和它的next-hop SIP entity之間安全機制的協商程序 設計目的 讓兩個User Agent之間可以協商出最適合的安全機制 中間的協商過程必須是安全的 在協商過程中，兩方都必須能夠指出協商程序是成功或失敗的 協商過程不會使雙方有新的狀態產生

協商過程 1. Client ----------client list---------> Server 協商過程可以分成以下五個步驟 1. Client ----------client list---------> Server 2. Client <---------server list---------- Server 3. Client ------(turn on security)------- Server 4. Client ----------server list---------> Server 5. Client <---------ok or error---------- Server

Step 1 client端把自己所支援的安全機制附在request的SIP header裡傳送給server端 Step 2 server端也把自己所支援的機制附在SIP header裡回覆給client端 Step 3 client端選出兩方都有支援且優先權最高的安全機制並啟動 Step 4 client端使用選出的安全機制，把在Step 2裡server端所附的機制當作挑戰值附在SIP header裡送回給server端 Step 5 server端檢驗此挑戰值，如果和原本一樣，表之前的訊息沒有經過竄改，server端送回OK值；否則送回ERROR值

其中sec-mechanism的內容如下 在step 1、step 2和step 4所使用的SIP header分別為Security-Client、Security-Server和Security-Verify，它們有以下的格式 其中sec-mechanism的內容如下

HTTP Authentication 在HTTP authentication裡，提供了一個簡單的challenge-response的機制，讓伺服器要求用戶端提供使用者的帳號、密碼，然後伺服器可以將所輸入的帳號、密碼與伺服器上的比對，以達到「使用者認證」 Basic Authentication scheme Digest Authentication scheme

Basic Authentication scheme 當用戶端要求HTTP認證保護的網址時，伺服器會傳回一道含有WWW認證回應表頭的401狀態表頭。然後，用戶端會出現一個對話盒，要求使用者輸入帳號及密碼，使用者輸入帳號、密碼之後，用戶端會把所輸入的資訊及請求的網址傳送給伺服器，伺服器接著會驗證帳號及密碼是否正確，若正確則傳回用戶端所請求的網址；錯誤，伺服器就會傳回401的狀態，再次請求帳號、密碼

Basic Authentication scheme 缺點 使用者所輸入的帳號、密碼是以未加密（unencrypted form）的格式在網路上傳輸，雖然不是使用純文字的方式，僅有對密碼部分做uuencoded的處理。不過，由於uuencoded是資料編碼常見的技術， 因此解碼程式也非常多，任何人取得了uuencoded的密碼都可以很容易破解，並濫用之 改進方法 使用Digest Authentication scheme

Digest Authentication scheme 當用戶端要求一個受保護的網址時，Digest Authentication scheme 會利用WWW-Authenticate header傳送一個nonce給用戶端，用戶端會將使用者所輸入的帳號、密碼當作Key，將nonce做keyed-hash，再將結果放入Authorization header，然後回傳給伺服器；伺服器根據自己儲存的使用者密碼，也做一次相同的運作，如果兩相比對之後結果是相符的，表示用戶端所輸入的密碼是正確的，則表示認證成功，並送回用戶端所要求的網頁

S/MIME (1/4) S/MIME是由RSA Data Security這家公司提出的一套標準，是一套 需要許可的程式元件封裝單元，用以提供其他郵件處理程式新增 S/MIME的安全服務元件，以達到安全郵件的目的 支援S/MIME的格式的電子郵件程式 Microsoft Outlook/Outlook Express Netscape Messenger Baltimore Technologies' MailSecure OpenSoft ExpressMail等…

S/MIME (2/4) S/MIME其所提供的安全服務包括了： 數位簽章：收件者可以認證使用者的身份，同時，也讓發件者無法否認其發出該信件 郵件內容的機密性：避免郵件內容外洩，或是遭到竄改 依照其所受S/MIME安全服務的不同，PKCS物件資料可以被區分為 數種模式： 封裝資料模式 簽署資料模式 明文簽署資料模式 封裝簽署資料模式

S/MIME (3/4) 封裝資料模式 封裝模式指的是將郵件正文部分加密，保持資料的隱密性，S/MIME中所使用的正文加密演算法為對稱性加密法，提供有tripleDES、RC2/40兩種加密法。而加密正文部分所使用的交談金匙，則以非對稱性加密法RSA加密保護。 簽署資料模式 簽署模式則是對郵件內容正文部分做數位簽章，其一方面可以讓收 件者確認送件者的身份，送件者無法否認送件之外；另一方面， 若是郵件內容在送件過程遭到更改或是發生錯誤，也可以藉由電 子簽章的核對查證。

S/MIME (4/4) 明文簽署模式 在明文簽署模式中，只有簽章資訊區會經由base64轉碼，而郵件內容則依然是以明文傳遞。因此，在明文簽署模式當中，即使收件者的郵件程式沒有支援S/MIME郵件格式，也可以閱讀郵件的內容（但仍不能認證送件者的身份） 封裝簽署模式 郵件的內容可以同時經由簽章服務以及風中服務共同保護，且並 沒有規定流程順序。因此簽署過的文件可以經由封裝加密；封裝 加密過的內容也可以再經由數位簽章保護

TLS (1/2) TLS1.0版本建構在SSL3.1之上，SSL是TLS的前身 TLS安全協定的的設計目標主要有以下的幾個目的： 加密安全性（Cryptographic security）：連線雙方可用TLS 來建立安全的通訊傳輸 相容性（Interoperability）：各程式設計員可各別依TLS的標準，開發各自的應用程式來互相進行安全連線 可擴充性（Extensibility）：TLS提供了一個骨架，可將新的加密演算法加入TLS協定裡。這使得原本的程式不需要再另外設計新的協定、程式庫以配合新的加密方法。在雙方通訊時，會依照彼此可以使用的加密演算法協調出一組適合雙方使用的認證及加密演算法 較佳效率（Relative efficiency）：TLS提供一種稱為連線快取（session caching）的方法可減少每次連線所需重複進行的密碼運算

TLS (2/2) TLS V1.0主要是為了確保 Internet 網路傳輸上的“隱密”、“資料完整性”及”認證”而設計的。它主要分成兩層，包括 TLS 資料加密協定（TLS Record Protocol）及 TLS 交握認證協定（TLS Handshake Protocol） TLS資料加密協定 TLS 資料加密協定是架在像TCP的傳輸協定上，主要功能是提供可靠的通訊管道給各種上層通訊協定，確保傳輸上的隱密及可靠。它主要負責資料的加密、解密 TLS 交握認證協定 用來作為連線雙方的認證、加密金鑰的交換

TLS 資料加密協定 TLS資料加密協定可封裝TCP之上各種通訊協定以對各協定的資料進行切割、 壓縮、加入訊息認證碼（MAC）、加密等處理，最後再把處理過的資料傳 送出去。首先，加密協定會對資料作切割動作，並選擇性的作壓縮，然後 產生MAC作為資料完整性確認之用，最後對資料作加密處理後再交給網路 傳輸層再傳送出去

TLS 交握認證協定 (1/2) TLS 交握認證協定可讓用戶端與伺服器端在進行上層資料傳送前，進行身 份認證，協商共同採用的加密策略、方法、金鑰等，有三基本性質： 連線雙方可通過非對稱式密碼方法互相驗證對方的身份。如作用RSA，DSS。 可確保在協商時共享的秘密值（shared secret）時不會遭受偽裝中間者身分攻擊（man in the middle attack）。 可確保在協商中的通程中，沒有駭客可以修改協商中所傳送的資料。

TLS 交握認證協定 (2/2) 由於上述交握認證協定流程需要雙方商議共同的密碼機制，進行金鑰交換 等動作，當兩端連線頻繁時將造成一些認證頻繁，影嚮執行效率。為了提 高運作效率，TLS協定允許雙方使用之前連線所商議出來的密碼機制，此 方式稱為連線回復（session resumable）

IPSec (1/3) IPSec是針對位於網路層的Internet Protocol所提出的安全性協定。即使位於IP層上層的應用程式或傳輸層沒有提供任何安全性的機制，由於IP層加入了安全機制，因此可保護整個網路通訊的內容 IPSec主要可提供兩種功能： 認證功能(Authentication) 保密功能(Confidentiality) 認證與保密的核心都是加密法(或是雜湊函數)，提到加密法當然就會牽涉到金鑰管理(Key Management)。因此，IPSec也規定了如何交換金鑰，以便建立與管理加密時所需的各類金鑰。

IPSec (2/3) IPSec的運作需先經過以下的步驟： 若從功能面來看，IPSec包含了三種協定，分別提供不同的功能。 在初始化時，雙方必須建立安全聯結(Security Associations)。這個步驟的主要目的是讓雙方對於如何使用IPSec的方式達成共識，例如，選擇何種安全功能；決定加密的演算法；使用金鑰的原則等等 金鑰交換。這個步驟主要是利用非對稱加密法，讓雙方各自擁有相同的秘鑰(Secret Key，專指對稱式加密法所用的金鑰) 開始以安全的管道來傳輸資訊 若從功能面來看，IPSec包含了三種協定，分別提供不同的功能。 金鑰交換協定：負責建立安全聯結與交換金鑰 認證表頭 (Authentication Header，AH)：主要提供認證的功能 資料封裝加密 (Encapsulating Security Payload，ESP)：主要提供加密的功能，也可選擇性地再加上認證的功能 建立IPSec連線使一定會使用金鑰交換協定。至於AH與ESP則是二選一，或是兩者合併使用

IPSec (3/3) IPSec的封包依照不同的模式而不同 傳輸模式：僅加密或認證上層協定的資料。例如，在區域網路中有兩台電腦A與B，A與B可直接建立連線(不必經由路由器或防火牆)，且A與B具有處理IPSec封包的能力時，則可使用IPSec的傳輸模式 通道模式： IPSec會加密或認證整個封包，然後在最外面再加上一個新的IP表頭。當IPSec連線兩端的電腦有一端或兩端不具處理IPSec封包能力，而必須透過具有IPSec能力的路由器或防火牆來代為處理IPSec封包時，即必須使用通道模式

Securing the Real-time Media Streams Secure RTP (SRTP) 安全RTP(SRTP)是當前IETF的一項草案，為 RTP 提供了安全配置檔 (security profile)，向資料包添加了機密性、消息認證及分組重播保 護，專門解決了互聯網上的電話技術應用問題。SRTP 的目的在於只 保證 RTP 和 RTCP 流的安全性，而不提供完全的網路安全架構。 SRTP 使用RTP/RTCP報頭資訊與 AES 演算法，得到代數方法上適用 於 RTP/RTCP 有效負載的密鑰流。SRTP 可調用基於散列的消息認證 碼(HMAC)——將可 SHA1 演算法用於認證功能。

SRTP master key derivation

SRTP-Encryption

SRTP-Authentication

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

VoIP Challenges 從行動電話的成功，我們應不難瞭解一般消費者對於語音通訊的需求不外乎通話成本、品質，乃至於最終的「便利性」；而此便利性除了通話程序易於操作外，切斷那條擾人的電話線更是用戶所求。因此，隨著VoIP結合藍芽、DECT，甚至WiFi等相關技術（如Cellular/WiFi的無縫切換）的逐漸成熟，加上各大相關設備業者的積極投入，全球目前已有一些服務供應商即將試驗或推出Wireless VoIP的服務；此外，與無線技術的結合更被Skype列為主要發展策略。VoIP與無線技術的結合將成為不可逆的趨勢。 由於植基於IP網路，VoIP當然無法避免security方面的相關威脅。根據In-Stat研究顯示，現今採用VoIP的企業普遍都存在著security方面的威脅，且以中大型企業更為嚴重。因此，目前諸如Cisco、Juniper、…等許多網路設備業者也已逐漸開始與相關安全業者進行合作，以提供更安全可靠的VoIP通話。

雖然網路電話產業一片看好，卻出現治安單位對於網路電話監聽的要求。IPOX資深顧問翁秋平表示，電信法規定網路電話業者申請執照時，必需符合「通信保障監察法」，主要是治安單位打擊犯罪、拼治安，因此自2004年11月起，有近百件新申請ISR(INTERNATIONALSIMPLE RESALE，語音轉售)服務的業者執照遲遲未發。 台灣開放網路電話的時程已遠落後日本(2002/10)、韓國 (2004/12)、新加坡 (2005/ 6)，如若在開放管理上過於偏廢，相關服務與產業的發展勢必受到嚴重戕害。網路電話開放與政府正在極力推動的M-Taiwan計畫 (5年370億)、都會無線網路、雙網手機、TW4G(台灣第四代網路系統)、IPv6等大型計畫關係密切，也牽涉到台灣IT產業在未來IP電信產業全球數千億美元商機。

VoIP未來發展與應用 通訊不是只有語音，IP網路作為通訊的傳輸平台，適合各類多媒體資訊。 通訊的用戶介面不是只有話機，各式各樣的通訊終端設備，適合於各種不同用戶的需要。 一個IP連接點，應該是所有服務的起點。 從網路的觀點來看，要促進通訊的發展，以量定價的方式將會漸次被改變成固定費率計價。 傳統電信中，互連互通是各家業者談判時最關鍵的問題。IP電信裡，傳輸互通已經是既定事實，服務互通也較容易。 IP通訊中，號碼不是唯一用戶的認證方式，文字式的ID可能更有威力。 PC做為通訊的終端的情況會越來越成熟，而且軟體跟通訊的結合也會越來越多。

家庭與個人VoIP服務的趨勢 多種不同的終端服務 USB phone Softphone IP Phone WiFi phone Video phone PC與通訊介面的整合 Web phone Messaging 與 forwarding Internet服務、軟體與通訊結合 交友, 聊天室 線上遊戲 電子商務 IP phone USB and Soft phone Video phone VoIP TA / Gateway

企業VoIP服務的趨勢 集中式的電信服務將成為主流 Messaging將是一般企業會普遍採用的通訊方式 多人遠距會是最有經濟效益的應用方式 IP PBX、Hosted PBX、IP Centrix的普及 Call Center的管理 Messaging將是一般企業會普遍採用的通訊方式 語音信箱、即時通訊的普及 多人遠距會是最有經濟效益的應用方式 IP視訊會議、Directory管理、遠端辦公室應用 企業通訊成本會變成固定的支出，而不是不可控制的費用

NW Service Communication Real Time Communication IP通訊的多樣性(SIP) 從語音擴充到動態影像通訊以及行動化通訊 SIP 3rd Generation NW Service Communication Communication Convenience SIP 2nd Generation Ubiquitous Computing NW Appliance Cooperation Presence Management Contents Delivery NW Appliance Control P2P Moving Picture SIP 1st Generation Real Time Communication Mobility Personal Portal Accounting Finance Decision pre-SIP Multi Media Messaging Presence Display Telematics （ITS） Voice Conference TV Phone Instant Message 從IP電話, PC的連接 到 更多行動終端的連接 以及 更多服務的連接 IP Telephony Web Conference 2002 2003 2004 2005 2006 資料來源：OKI

Contents Overview of VoIP System H.323/SIP VoIP: How to penetrate NAT or Firewall VoIP Security VoIP Challenge & Future VoIP Risks, Threats, and Vulnerabilities

VOIP Risks, Threats, and Vulnerabilities Confidentiality and Privacy Switch Default Password Vulnerability Classical Wiretap Vulnerability ARP Cache Poisoning and ARP Floods Web Server interfaces IP Phone Netmask Vulnerability Extension to IP Address Mapping Vulnerability Integrity Issues DHCP Server Insertion Attack TFTP Server Insertion Attack Availability and Denial of Service CPU Resource Consumption Attack without any account information. Default Password Vulnerability Exploitable software flaws Account Lockout Vulnerability

Danke! Thank you!