1. 1 指導教授：柯開維 博士 日期： 2007. 07. 24 學生：馮文志 具適應性傳輸頻寬、編碼與安全機制之 無線網際網路電話系統之研製 The Study and Implementation of Adaptive Bandwidth, Encoding Adjustment, and Security Mechanisms for Wireless Internet Phone 2007 資訊工程系碩士論文口試

2. 2 綱要 前言 緒論 相關技術背景之探討 具適應性傳輸頻寬與編碼之無線網路電話系 統之設計 具安全機制之無線網路電話系統之設計 結論 未來展望 實機展示

3. 3 前言 網路電話系統 無線環境中的網路電話系統 網路電話之控制訊息與語音可能穿越未知的網域

4. 4 語音傳輸與頻寬需求 網路頻寬之需求無法滿足現今數位資料的傳 輸，進而影響其資料傳輸的品質。 無線網路電話系統之安全機制 網路科技進步的同時又衍生出了很多的安全問 題，例如，非法攔截、監聽別人傳送之訊息與 通話內容。 研究背景

5. 5 適時提高語音的通話品質 系統自動偵測網路環境自動維護通話之品質。 使用者自行調整編碼格式，以便維護通話之語音品質。 加強無線網路電話系統之安全機制，對抗以 下攻擊： Replay Attack Password Guessing Attack Man-in-the-Middle Attacks Denial of Service (DoS) eavesdropping 研究目的

6. 6 相關技術背景之探討 無線網路電話與語音編碼傳輸技術 無線網路電話中的安全技術

7. 7  利用 PCM 、 ADPCM 和 AMR (Adaptive Multi-Rate) 等多種編 碼方式。  利用 RTP (Real-Time Transport Protocol) 傳送語音資料。  利用 RTCP (Real-Time Transport Control Protocol) 傳送 遺失封包的多寡的統計數據。 相關技術背景之探討 - 無線網路電話與語音編碼傳輸技術

8. 8 AMR 語音編解碼子系統是能一套 提供八種位元率的語音表示法，可 以針對不同的網路品質，切換成不 同的位元率，它使用一些編碼演算 法來得到接近清晰品質的語音。 未經壓縮 16 bits 精確度、 8KHz 取 樣頻率的 PCM 訊號位元率 (bit rate) 是 128kbps ，但是經過 AMR 壓縮過 後位元率 (bit rate) 可達到 4.75kbps 至 12.2kbps 不等，壓縮率相當高， 約 10~25 倍左右不等。 例如，每秒取樣 8000 點，每點 16 bits ，一個 AMR frame 為 160 點， 可將 8000 分成 50 frame ，一個 frame 之大小為 2560bits(160*16) 。 以 AMR 12.2k 為例可將 2560bits 編 成 244bits ，約壓縮 9~10.5 倍。 AMR (Adaptive Multi-Rate Speech Code ) 簡介 Bit-rate Total Bits AMR 12.2 244 AMR 10.2 204 AMR 7.95 159 AMR 7.4 148 AMR 6.7 134 AMR 5.9 118 AMR 5.15 103 AMR 4.7595

9. 9 利用 Diffie-Hellman 的方法交換 私鑰 將 SIP 訊息用 S/MIME 方法加密 與認證 針對不同媒體資料的加密與認證 利用 Session Key Generator 產生 不同的金鑰來完成 不同語音區塊利用 Key Stream Generator 產生不同的金鑰來加 密與認證 用 AES-CTR 的方法對 RTP/RTCP 加 密 用 HMAC-SHA1 方法對 RTCP 認證 DA 39 A3 EE 5E 6B 4B 0D 32 55 BF EF 95 60 18 90 AF D8 07 09 L?Z? 肐 x<OL 罊 g 相關技術背景之探討 - 無線網路電話中的安全技術

10. 10 系統研製概念與原理 系統架構 研究結果與測試 具適應性傳輸頻寬與編碼之無線網路電話系統之設計

11. 11 自動調性應編碼格式 中斷式：利用 RTCP (Real-Time Transport Control Protocol) 報告， 由 RTP 遺失封包的多寡統計，瞭解網路傳輸狀況，作為系統 頻寬速率調整之依據，調整時由 SIP 訊息來通知對方已調整 之編碼速率。 透通式：系統調整編碼格式時不用 SIP 訊息來通知對方， 由封包中的某些資訊來達到共識。 使用者自行調整編碼格式 中斷式：同上 透通式：同上 系統研製概念

12. 12 手動調整編碼方式 中斷式：下拉視窗 ( 圖一 ) 手動選取一 Codec ，系統會將 User 選取的 Codec 名 稱加到 SIP Message 中傳送到對方，接 收端解開 SIP Message 封包之後立刻切 換成對應的 Codec ，如圖二中 PayloadType 值為 0 ，表示要用 PCM Codec 通話。 透通式： Codec 系統切換到 AMR 子系 統時會提供八種 Codec ，八種 Codec 之 間如何切換是依據 AMR Frame 的第一 個 Byte 中的 FT( 圖三 ) 來決定，所以並不 會用 SIP Message 相互通知。 圖一 手動選擇 Codec 圖二 SIP Message 圖三 AMR Frame Header 系統研製原理 - I

13. 13 系統研製原理 - II Bit rate Bits per frame 12.2K244 10.2K204 7.95K159 7.4K148 6.7K134 5.9K118 5.15K103 4.75K95

14. 14 自動調整編碼方式 中斷式：系統依據 RTCP 中統 計資訊，判斷目前的網路狀況 並選擇一適合的 Codec ，系將此 Codec 名稱加到 SIP Message 中 通知對方。如圖三 Fraction Lost 值為 40 ，表示目前的封包 遺失率為 40% 。 透通式：同手動調整編碼方式 系統研製原理 - III 圖四 RTCP 封包中的統計資訊

15. 15 系統研製原理 - IV

16. 16 系統研製架構

17. 17 具適應性傳輸頻寬與編碼之無線網路電話之系統架構 Wireless Internet

18. 18 CSS (Coding Switch Subsystem ) AMRS (Adaptive Multi-Rate Speech Code Subsystem ) RRSS (RTP/RTCP Sending Subsystem ) RRRS (RTP/RTCP Receiving Subsystem ) 系統架構 - 四個子系統 microphone

19. 19 依據 SIP Message 或 RTCP 資訊， 手動式 (Manual) 或自動式 (Auto) 配置一適合目前網路狀況的編碼 方式。 在切換編碼方式之前， CSS 會先 判斷使用者是透過 SIP 訊息來改編 碼方式即「手動式」，或是由系 統自動配置一個適合目前的網路 編碼方式即「自動式」。 若由 SIP 控制訊息來指定編碼 方式，則系統必須使用其指定 的編碼方式。 若系統依據 RTCP 資訊，則系 統自行判斷適合目前網路狀況 的編碼方式。 CSS (Coding Switch Subsystem )

20. 20 將系統取樣的 PCM samples 傳送給 AMRS 子系 統，由依選定的速率編碼，再封裝成 AMR Frame 格式。 封裝成 AMR Frame - 在此 Frame 的前面加上 1Byte 的 Header ，傳給 RRSS 子系統封裝成 RTP 封包，其中 Header 的內容為： F ：同 RTP Payload 所有 Frame 除最後一個 Frame 設為 0 以外其它 Frame 的此位元都應 設為 1 。 FT ： Frame 的格式 (Frame Type) ，表示此 Frame 是用何種速率編碼，讓接收端以對 應的速率解碼。 Q ：對此 Frame 求要比較嚴謹暗示某些對 應參數必須設為 1 ，表示此 Frame 的 quality 。 將 RRRS 中接收到的 AMR Frame 傳送給 AMRS ， AMRS 取出 Header 中的 FT 值以對應 的解碼方式進行解碼，最後重建 PCM samples 。 RFC 3267 AMRS (Adaptive Multi-Rate Speech Code Subsystem )

21. 21  控制 RTP/RTCP 連線機制。  責負封裝使用者或是系統指定 的編碼方式，將編碼好的資料 封裝成 RTP 的封包。  傳送封包的情況統計之後產生 一份報告，將這些份報告彚整 之後封裝到 RTCP 封包中，並 週期性地傳送 RTCP 封包。 RRSS (RTP/RTCP Send Subsystem)

22. 22  將系統或使用者所指定的編碼 格式用相對應之編碼格式解碼  將編碼之後的資料送至輸出裝 置（例如：喇叭）。  分析由 RRSS 子系統所傳送過 來的 RTCP 封包。將分析之後 的資料送到 CSS ，做為判斷網 路品質與更改變編碼格式的依 據。  將收封包的情況統計之後產生 一份報告，將這些份報告彚整 之後封裝到 RTCP 封包中，週 期性地 (3 sec) 傳送 RTCP 封包。 RRRS (RTP/RTCP Receive Subsystem)

23. 23 編碼名稱 調升速率調降速率 封包遺失率 對應速率 (Bps) 封包遺失 率 對應速率 (Bps) PCM 128Kbps (16KBps) -- > 50% 約 8 K ADPCM 32Kbps (4KBps) < 15% 約 3.4K > 50% 約 4 K AMR 12.2 ( 約 1.5KBps) < 15% 約 1.3K > 50% 約 2 K AMR 10.2 ( 約 1.27KBps) < 15% 約 1.07K > 50% 約 1 K AMR 7.95 ( 約 0.98KBps) < 15% 約 0.83K > 50% 約 0.49 K AMR 7.4 ( 約 0.92KBps) < 15% 約 0.78K > 50% 約 0.46 K AMR 6.7 ( 約 0.84KBps) < 15% 約 0.71K > 50% 約 0.42 K AMR 5.9 ( 約 0.74KBps) < 15% 約 0.63K > 50% 約 0.37 K AMR 5.15 ( 約 0.65KBps) < 15% 約 0.55 K > 50% 約 0.33 K AMR 4.75 ( 約 0.59KBps) < 15% 約 0.5K -- 系統編碼 (CODEC) 「自動切換」原則

24. 24 具安全機製之無線網路電話系統之設計 系統研製概念與原理 系統架構 研究結果與測試

25. 25 具安全機制之無線網路電話系統架構 Wireless Internet

26. 26 避免「 DoS Attack 」與「 Replay Attack 」攻擊 - 認證 SIP 註 冊訊息與 RTCP 訊息之完整性。 避免「 Password Guessing Attack 」與 「 Man-in-the-Middle Attacks 」 - 將夾帶在邀請訊息中的主金鑰與重訊息加密與 認證。 避免「 Eavesdropping 」 - 對不同的語音區塊利用金鑰串產生 器產生不同的金鑰加密。 設計通話金鑰產生器產生不同的金鑰對不同的媒體資料加 密，避免只用一把金鑰對不同媒體資料加密。 系統研製概念

27. 27 註冊訊息完整性之認證 – 應用 S/MIME 技術 系統研製原理 沒有安全機制之註冊訊息 具有安全機制之註冊訊息 SIG[H[M]] = Message SHA-1 AES

28. 28 註冊訊息完整性認證之流程 系統研製原理 Authentication Key

29. 29 邀請訊息之加密與認證 - 應用 S/MIME 技術 系統研製原理 沒有安全機制之邀請訊息 具有安全機制之邀請訊息 Enveloped Data= Master Key AES Base64

30. 30 邀請訊息之加密與認證 - 應用 S/MIME 技術 系統研製原理 Private Key

31. 31 系統研製原理 語音加密 – Session Key Generator MAY be public Option

32. 32 系統研製原理 Secure RTP/RTCP Secure RTP Secure RTCP

33. 33 系統研製原理 語音加密 – 金鑰串產生器與 RTP/RTCP 加密 Option C97ADC9F2BDF2ED2 678226AB078474A6 494056D75C5AF205 CED309D7DE925B1E D16B7BF86CC129EC 02C425BD10788594 426DEBD9FEC381BD 0772444518B45D90 BDCD07F949265EED CD4AFE074909CDE9 Key Stream Plaintext Ciphertext

34. 34 系統研製原理 RTCP 之認證與流程

35. 35 系統架構

36. 36 使用者可依據目前的聲音品質自行「手動」選擇語音編 碼格式，進而改變其語音傳輸的頻寬需求，讓語音品質 達到可接受的範圍。 系統可以監督網路通訊品質，依據 RTCP 統計資訊，能 「自動」的方式配置一個適合目前網路狀況的編碼格式， 自動維護語音通訊品質。 在維護語音品質之同時也提供一個安全而完善之通話環 境，確保通話容內之私密性。 結 論結 論

37. 37 移植到嵌入式系統中使其成為一實用之系 統 建立多方通話功能，並能選擇將傳送到特 定對象之語音加密 Automatically adjust silence detection level 在 WiMAX 環境中建構此系應用系統 Voice Server, Voice Mail, Answer Machine 未來展望

38. 38 展演 3 – 手動方式調整編碼格式 展演 4 – 自動方式調整編碼格式 Case 1 – 用 NetLimiter 製造封包遺失的情況 Case 2 – 網路環境好但用到低速的編碼格式 展演 1 – SIP 註冊訊息之認證 展演 2 – SIP 訊息加密與認證流程 展演 5 – 語音加密 系統展演

39. 39 Comparison With SJphone and Skype  Codec Adjust Policy ： SJphone V.S. Ours System  Security Policy ： Skype V.S. Ours System

40. 40 Narrow-band audio codec G.729 Audio Recording (coming soon) Secure Media (coming soon) Off-Line Direct Codec Narrow-band audio codec AMR Audio Recording Secure Media On-Line/Off-Line Direct Codec Automatically Adjust Codec GSM 6.10 CODEC 8KBps SJ Labs ILBC CODEC – 30ms 13.32KBps SJ Labs ILBC CODEC – 20ms 15.2KBps G.711 A-Law 64KBps G.711 u-Law 64KBps G.729 8KBps PCM 128Kbps (16KBps) ADPCM 32Kbps (4KBps) AMR 12.2 ( 約 1.5KBps) AMR 10.2 ( 約 1.27KBps) AMR 7.95 ( 約 0.98KBps) AMR 7.4 ( 約 0.92KBps) AMR 6.7 ( 約 0.84KBps) AMR 5.9 ( 約 0.74KBps) AMR 5.15 ( 約 0.65KBps) AMR 4.75 ( 約 0.59KBps) Codec Adjust Policy ： SJphone V.S. Ours System 資料來源： http://www.sjlabs.com

41. 41 Registration ： Central Server private Signing key, SS. The Corresponding public verification key, VS, and an identifier for the key pair are installed in every Skype client at build time. Peer-to-Peer Key Agreement ： Master Key (MK) is attached in invitation Message (256 bits), the MK is retained memory until the client is closed. Audio Encryption ： Audio is encrypted by XORing the plaintext with key stream generated by 256-bit AES depends on MK, salk key, and the sequency within Packet. Security Policy ： Skype V.S. Ours System (1) Registration ： Get Authentication Key by Server and ClientExchange Key with Diffie- Hellman (D-F). Key Agreement through intermediary node ： 1. Get Private Key (PK) by D-F. 2. Encrypted MK by AES. 3. Attached MK cipher in invitation message. 4. Authentication message with DSA. Audio Encryption ： Audio is encrypted by XORing the plaintext with key stream generated by Key Stream Generator depends on Encryption Key generated by Session Key Generator, salt key and SSRC within packet Different Block Different Key Skype Ours System 資料來源： http://www.anagram.com/ http://www.anagram.com/ Anagram Laboratories Palo Alto, CA

42. 42

43. 43 取樣速率： 0.125ms 取一點 ( 每點 16bits) ，一秒取 8000 點 ( 共 128kbits) 在 PCM Mode 情況下每秒共傳送 16kbytes( 與 NetLimiter 所擷取一秒約 15.5~16kbytes 相符 ) 。 AMR 的取樣與編碼速率： 每秒可取 8000 點，將 8000 分成 50 組，每組 160 點 (160*16 = 2560bits) 。以 AMR 12.2k 為例可將 2560bits 編成 244bits ，約壓縮 9~10.5 倍。 RTP 封包傳送速率： 每 200ms 傳送一個 RTP 封包，每秒 傳送五個封包，每個封包約 3.2Mbytes 。 RTCP 封包傳送速率： 每 5000ms 傳送一個 RTCP 封包， 每 5 秒傳送一次 RTCP 封包，佔 RTP 頻寬之 25% 。所以五秒 內約掉 10 個幫包以上則會自動調整編碼格式。 聲音取樣頻率與相關數據

44. 44 展演 2 – 手動方式調整編碼格式 手動調升 / 降碼編速率 限制或不限制頻寬 由 NetLimiter 就會顯示 對應的 Transfer Rate 看 到編碼率之改變

45. 45 展演 3 – 自動方式調整編碼格式 系統會自動偵測網路環境，試 著往較高的編碼速率調整，一 直到找到一個適合目前網路頻 寬的編碼格式之後穩定下來。 預設在網路環境很好，但使用最低編碼速率之情況： NetLimiter 顯 示出對應的 Transfer Rate No BW limit

46. 46 展演 4 – 自動方式調整編碼格式 網路環境不穩定，頻寬會改變之情況： 假設在網路寬環境很差但 使用的編碼速率為很高。 系統會自動偵測網路環境， 試著往較底的編碼速率調 整，系統會自動找到一個 適當的編碼格式之後穩定 下來。 利用 NetLimiter 的限流功能製造 不同的網路環境 讓此系統偵測。

47. 47  編碼器的流程大致上可分成下列四個步驟： 求出 LPC 係數 求出 open -loop pitch input 求出 codebook index & gain 量化 codebook gain ，並求出 excitation ，更新 filter memory 。 PCM samples Input ARM Output  解碼流程大致可分成下列三個步驟： 把 LSP 做解碼，再將 LSP 轉換成合成濾波器的 A(z) 的係數。 將 pitch index 以及 code index 代入 codebook 中，求出合成濾波器的輸入。 經過 post filter 還原成語音訊號。 ARM input PCM Output

48. 48 Bits (MSB ‑ LSB) Description s1 ‑ s7 index of 1st LSF submatrix s8 ‑ s15 index of 2nd LSF submatrix s16 ‑ s23 index of 3rd LSF submatrix s24sign of 3rd LSF submatrix s25 ‑ s32 index of 4th LSF submatrix s33 ‑ s38 index of 5th LSF submatrix subframe 1 s39 ‑ s47 adaptive codebook index s48 ‑ s51 adaptive codebook gain s52sign information for 1st and 6th pulses s53 ‑ s55 position of 1st pulse s56sign information for 2nd and 7th pulses s57 ‑ s59 position of 2nd pulse s60sign information for 3rd and 8th pulses s61 ‑ s63 position of 3rd pulse s64sign information for 4th and 9th pulses s65 ‑ s67 position of 4th pulse s68sign information for 5th and 10th pulses s69 ‑ s71 position of 5th pulse s72 ‑ s74 position of 6th pulse s75 ‑ s77 position of 7th pulse s78 ‑ s80 position of 8th pulse s81 ‑ s83 position of 9th pulse s84 ‑ s86 position of 10th pulse s87 ‑ s91 fixed codebook gain subframe 2 s92 ‑ s97 adaptive codebook index (relative) s98 ‑ s141same description as s48 ‑ s91 subframe 3 s142 ‑ s194same description as s39 ‑ s91 subframe 4 s195 ‑ s244same description as s92 ‑ s141