安全即时通讯之视讯加密系统设计与实现

安全即時通訊之視訊加密系統設計與實現
羅于庭
國立高雄師範大學資訊教育研究所creeds2239@
楊中皇
國立高雄師範大學資訊教育研究所chyang@
摘要
即時通訊(Instant Messaging，IM)是目前最熱門點對點計算(peer-to-peer computing)的網路服務，不僅逐漸成為人們日常生活中非常重要的聯繫方式，更提供了即時文字訊息、語音以及多媒體視訊的互動服務。

但是目前大多數的即時通訊系統大多以實用性與提高方便以提昇市佔率為主要考量，並未著重於安全性問題的部份。

例如微軟的Windows Live Message 著重於使用者網路服務的應用整合，以及登入階段的安全性，使用者之間的多媒體音訊、視訊以及檔案傳遞皆採用明文方式傳遞[1][2]。

為了解決即時通訊的多媒體資料傳輸的安全問題，本研究依據IM的多媒體視訊傳輸主要採P2P的方式進行，加強點對點兩端的視訊封包的安全性，以確保視訊封包的確認性、機密性與完整性。

同時加速實做的效率使其不會大幅提昇視訊傳輸的延遲率，已達到不影響使用者正常使用即時通訊視訊的功能。

在實作上，我們開發符合XMPP (eXtensible Messaging and Presence Protocol)標準的即時通訊用戶端軟體，並且結合SIMPP (Secure Instant Messaging & Presence Protocol)安全即時通訊協定提昇安全性[3]。

同時，我們使用Borland C++開發工具於Windows平台上開發安全的即時通訊客戶端軟體。

底層的函數庫則採用MIRACL與iksemel 以及LockBox開放原始碼元件，以提供密碼學演算法與XMPP協定的功能，視訊函式庫則採用VFW (Video for Windows)達成視訊的擷取的功能。

關鍵詞：即時通訊、點對點計算、XMPP、Jabber、視訊安全。

導論
隨著近年來網路以及多媒體技術的迅速成長，即時通訊的服務目前已經成為了電子郵件(E-mail)、Web 之後的第三大網路應用服務[4]，逐漸成為了日常生活中個人電腦上主要的通訊方式，並且透過幾乎是以即時的傳送與接收訊息方式達到使用者之間的資料傳送，為即時通訊的使用者提供了大大地便利性、娛樂性和即時性。

即時通訊的廣泛應用成為企業內部很重要的一項溝通工具，卻也相對的也提高了企業內部系統的風險性。

不管是員工私下的對談或是企業商業用途的即時通訊，確實做好安全控管的卻是少數。

而現今市面上的即時通訊軟體（如MSN、即時通等）通訊過程中所傳送的資料是沒有經過任何的加密機制，除了需要依賴現有的外掛軟體如SimpLite-MSN、MSN Plus！等，皆需同時兩方客戶端皆安裝並且採用加密機制才能進行訊息的加密功能。

倘若一方並無安裝外掛軟體或是尚未開啟加密機制，則即時通訊依舊處於不安全的網路環境下進行明文傳輸。

傳輸資料過程中是否會被中途的第三者利用Sniffer特殊封包竊取工具所截取側錄都是非常值得重視的問題。

雖然部份商業級用途的即時通訊軟體會特別註明傳送訊息會經過加密，如：IBM Lotus的Instant Messaging Everyplace及微軟的 Live Communications Server 都提供有訊息加密功能[5]。

但是在多媒體訊息如聲音和視訊上的即時通訊軟體大多尚未提供訊息加密保護的服務。

本研究主要為解決即時通訊的媒體資料傳輸的安全問題，加強點對點兩端之間的視訊封包的安全性，以確保其確認性、機密性、完整性，以SIMPP（Secure Instant Messaging & Presence Protocol）安全即時通訊協定提昇其客戶端至伺服端之間的認證安全性為基礎實做安全的視訊服務，開發符合XMPP（eXtensible Messaging and Presence Protocol）標準的即時通訊客戶端軟體[3]。

針對視訊串流封包採用TurboPower密碼學函式庫所提供的AES演算法加密，降低對視訊封包延遲的影響以同時達到訊息加密的目的。

文獻探討 即時通訊服務
隨著網際網路的快速發展，多媒體的應用更為普遍，所以目前的主流即時通訊軟體如Yahoo! Messenger 、Skype 、Google Talk 、Windows Live Messenger 等，不僅提供即時文字傳輸也提供視訊的應用服務，讓即時通訊的應用能夠更加生動與生活化。

網際網路工程任務小組(The Internet Engineering Task Force , IETF)成立即時傳訊與定位協定工作小組（Instant Messaging and Presence Protocol Working Group, IMPP WG ）以能完成共通的即時傳訊與定位協定（Instant Messaging and Presence Protocol , IMPP ）[6]，並且提出即時通訊服務標準規範RFC 2778制定下列兩種服務：
圖二：RFC 2778 Presence Service 模型
（2）現狀資訊服務（Presence Service ）
主要透過Presentity 以及Watcher 讓使用者得以向外發怖自己的線上狀態，方便使用者之間知道是否得以傳送即時訊息進行交談[7]。

即時通訊協定（Instant Messaging ） IETF 當初所提出的IMPP （Instant Messaging and Presence Protocol ）也成為現有的主流即時通訊協定SIMPLE 以及XMPP 所參考的主要架構。

SIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)為IETF 於西元2002年所提出的RFC3428所規範的標準，主要以SIP （Session Initiation Protocol ）為基礎的即時通訊協定，其中SIP 本身主要用途為協商、管理與終止媒體對話行程，此種對話行程是由特定的資料傳送通訊協定加以完成，例如RTP(Real-time Transport Protocol , 即時傳輸協定)，利用SIP 建立多媒體通道對話，隨後利用SDP （Session Description Protocol ）會議描述協定）來完成兩端交換對話的功能。

協調完畢之後即便利用RTP 傳送多媒體（視訊、語音）封包，所以將SIMPLE 用於發展即時通訊多媒體也是非常的合適[6]。

圖一：RFC 2778 Instant Messaging Service 模型 （1）即時訊息服務（Instant MessagingService ）
訊息的傳送具即時性，訊息傳送到伺服器端，隨後伺服端將訊息轉發至接收端的Instant Inbox 中，接收端在由Instant Inbox 取得訊息，其主要特色是採取Client/Server 架構。

XMPP 為IETF 於西元2004年所提出的RFC3920-RFC3923所規範的標準，其最主要的特點在於採用XML （eXtensible Markup Language ）定義描述語言為資料格式。

最初XMPP 是Jabber 即時通訊系統所
採用之通訊協定，用以傳輸即時訊息以及現狀資訊。

另外Jabber網路拓璞架構與電子郵件系統類似，每一個Client都需要有一個本地Server用以接收和發送訊息，Client與Server之間使用TCP Socket且Port 5222 所建立，Server與Server之間亦透過Port 5269來互相傳遞訊息與現狀資訊。

在此架構下，所有的訊息以及資料都必須透過Server才能到達其他Client 端。

因此連接的通訊協商最初也是透過Jabber Server所完成的[6]。

即時通訊系統視訊服務
目前主流的即時通訊軟體如Windows Live Messenger 9.0 是微軟所釋出的即時通訊軟體，中間歷經多次的改版，目前最新的版本整合多種應用服務如視訊、網路電話、互動式遊戲、電子白板、表情符號、動畫快遞等其主要運作於微軟自行制定的MSNP協定上，其中語音和視訊服務透過Messenger VOIP伺服器以直接或是轉接的方式以任何可用的Port在兩端點建立視訊/音訊的服務。

網路攝影機影像和視訊對話則是透過TCP 80以及TCP/UDP 5000-65535進行傳輸[8]。

其中WLM的視訊資料傳遞是透過適當的壓縮後利用SIP提供的SDP協定中以明文方式傳送。

Google
Talk是Google公司所提出的即時通訊軟體服務，其主要的通訊協定核心是採用開放原始碼XMPP/Jabber，並且依照Jingle[9]協定開發檔案傳輸、語音、視訊等多媒體的功能，更釋出libjingle函式庫原始碼以提供使用者開發更多相關的服務[10]。

另外Yahoo! Messenger是由Yahoo所釋出的即時通訊軟體，並且具有非常高的互動性，如電子白板、檔案傳輸、佈景更換、視訊、等豐富的多媒體功能。

其主要的通訊協定為YMSG[11]，其視訊服務品質可以依照頻寬作選擇以獲得最佳化的視訊服務。

即時通訊威脅
目前主要的即時通訊軟體服務較為著重於登入時的帳號密碼安全性的維護，當使用者登入至伺服端時，或者使用者的帳號密碼存在於本機時有提供一定程度的保護，但是在完成了與伺服器的身份驗證之後，轉換至和其他的使用者進行點對點服務時，則大多數的資訊都是採明文的方式傳輸。

所以彼此之間傳輸的訊息即便無法保證其保密性（Confidentiality）、完整性(Data Integrity)、可用性(Availability)、不可否認性（Non-repudiation）等。

圖三、Wireshark封包擷取畫面
如果在通訊的過程中遭到惡意使用者以側錄的方式取得雙方所有的交易封包，在透過軟體如圖三的Wireshark用以分析封包的規則，即可輕易的取得傳輸過程中的資料[12]。

更可對現有的網路通訊過程封包進行攔截與分析。

圖四、MSN Sniffer畫面
另外也有許多網路安全公司針對即時通訊推出了一系列的監聽軟體，如IMDetect的MSN Sniffer以及AIM Sniffer等工具[13]，於企業的用途可能是用於保障企業機密安全，但是落入惡意使用者的手中則變成專屬的封包攔截工具。

圖五、MSN Shadow擷取視訊串流畫面
除了一般的狀態式Sniffer 工具之外，也有其他類 系統架構
似於針對Session-based 媒體服務的Sniffer 工具，可以藉 本研究主要於SIMPP 協定上所實做視訊服務，所以在乾淨的作業系統前提下，登入即時通訊伺服器，雙方所傳遞的登入訊息傳遞皆具有安全性、保密性（Confidentiality ）、完整性（Data Integrity ）、確認性（Authentication ）[3]。

由分析Session 狀態方式以進行封包內容分析[2]，另外 也有一套開放原始碼的軟體如圖五MSN Shadow 提到 可以利用libmimic API 以及MPlayer 利用針對二進 制碼進行視訊編碼與視訊解碼的方式把視訊串流另外 存為AVI 影片格式[14]。

即時通訊安全
至於提高即時通訊傳輸訊息安全性的作法，可以從下面三個層面來探討：
外掛軟體
首先目前針對訊息加密的方式大多數是透過外掛軟體如SimpLite 、IMsecure 、Pidgin-Encrypt 等達成文字訊息保密的目的，但是卻少有外掛軟體是針對即時通訊的視訊進行資料加密的動作，也因此此類的加密軟體，對於即時通訊的視訊傳輸並沒有保密性及安全性的作用。

SSL/TLS
SSL/TLS(Secure Socket Layer)是由網景公司
(Netscape)所提出的基於Web 安全傳輸協定，最後被IETF 組織標準化之後，定義為TLS(Transport Layer Security)，主要是透過公鑰基礎設施(PKI)利用加密演算法提供兩端點身份認證以及資料保密[15]。

以目前XMPP 協定為主的開放式即時通訊軟體，絕大多數都提供了SSL/TLS 連線的方式以保證基本的連線安全，但是其不適合應用於即時通訊傳輸量大的服務身上，如視訊、檔案傳輸等[10]。

圖六、系統架構圖
本系統之視訊架構如圖六所示，完成通訊後會執行以下步驟：
Step1: 先進行截取使用者的視訊影像。

Step2: 分別對影像及做JPEG 壓縮以及存入串流。

Step3: 透過壓縮所得到串流檔案，再經由通訊金鑰做
加密並且傳送到遠端使用者處。

Step4: 遠端接收到密文後，使用通訊金鑰將密文解密
得到壓縮串流。

即時通訊軟體內建加密功能
Step5: 將壓縮檔串流分別經由JEPG 解壓縮讀出影像
並呈現於畫面。

目前即時通訊軟體除了Skype 自身提供了AES 256的演算法加密之外，其對文字、語音、視訊等都具有加密的功能[16]。

為了達到安全的即時通訊視訊的功能，因此本研究透過VFW(Video for Windows)函式庫，先藉由視訊裝置擷取影像資料，將其存入串流，在針對其串流進行加密，最後再透過TCP 協定將加密過後的視訊串流傳送給對方。

對方在收到資料後，需要先藉由金鑰將加密過後的視訊串流進行解密，以還原回視訊影像，最後再將其視訊影像呈現於使用者的畫面。

另外除了商業應用類型的即時通訊軟體如Live Communications Server 本身就是提供較高安全性的服務才具有資料傳輸加密的功能，市面上常見的主流即時通訊服務大多著重於整合應用型的服務，本身則不內建加密的功能。

圖七、視訊服務流程圖
其中加解密的部份是採用對稱式密碼學演算法AES-128，ECB模式，對即時影像資料進行處理。

但是前提需要先於SIMPP完成驗證並且採用連線登入後所產生出的短期會議金鑰以進行加密[3]。

當使用者A 想要與使用者B進行視訊服務時，使用者A首先會先送出一個視訊邀請的請求訊息，使用者B再將決定使否同意進行視訊的傳輸，當使用者B接受視訊服務邀請時，則會將自身的IP位址以及視訊服務所開啟的PORT一併送至使用者A處，此時使用者A收到確認訊息後，即可將自己的加密過後的視訊影像以及IP位址和PORT傳送給使用者B，並且使用共同的金鑰以進行解密。

同時使用者B也可以傳送加密過後的視訊資料傳送給使用者A，此時雙方便處於安全的視訊服務下。

即時通訊安全視訊傳輸設計與實現
本研究以SIMPP(Secure Instant Messaging & Presence Protocol)為客戶端開發基礎，使用者從登入到進行視訊的服務皆在SIMPP的架構上進行，使用者也是藉由其協定取得聯絡人清單後進行安全的點對點的視訊傳輸服務。

程式開發工具採用Borland公司所開發的Borland C++ Builder，作業平台為Windows XP。

視訊函式庫則是採用Microsoft所提供的VFW視訊函式庫，密碼學函式庫則是採用TurboPower公司於2003年釋出的Open Source加密元件LockBox[17]。

其加密元件特別針對於Borland C++及Delphi開發工具所設計，支援許多加密演算法如Blowfish、RSA、triple- DES、Rijndael等，所以可以在開發過程中提昇開發實做效率和開發平台之間的相容性。

表1 即時通訊客戶端程式規格表
開發工具Borland C++ Builder
視訊函式庫Microsoft Video for Windows
密碼學函式庫TurboPower LockBox
視訊加解密 AES
128，ECB
對稱式金鑰來源SIMPP
安全即時通訊伺服器程式採用SIMPP協定為主的伺服器程式。

以Ubuntu作業平台、資料庫的部份則採用開放原始碼MySQL用以存放使用者註冊資料以及驗證資訊。

所使用的密碼學規格如下：
表2 SIMPP密碼學規格表
公開金鑰密碼系統
GF(p)橢圓曲線
(y=x3
-3x+b mod p)
2
金鑰長度
Server 224 位元
Client 192 位元
金鑰交換方式ECDH
數位簽章演算法ECDSA
訊息加解密 128
Bit
AES，CBC
單向雜湊函數SHA-256
在登入即時通訊伺服器之後，即可透過點擊聯絡人清單顯示出對話框，點擊視訊按鈕，以進行視訊邀請，等待對方回應之後便可進行安全的視訊服務。

操作步驟如下：
圖八、視訊邀請
透過聯絡人清單與特定的使用者進行視訊服務時，接收方會顯示邀請的視窗，邀請人則會顯示出圖八的視訊邀請狀態視窗。

圖九、進行視訊服務畫面
在進行安全的視訊之前提必須先透由SIMPP 以安全的模式進行登入，隨後於送出視訊邀請前先取得用以文字以及檔案傳輸服務之對稱式加密金鑰，並用其進行視訊加解密，圖九即安全的視訊服務畫面。

圖十、第三者試圖讀取加密後串流時的畫面 進行視訊邀請前，如果使用者不在線上，則視訊邀請服務自動會被系統取消。

進行安全的即時通訊服務時由於是先透由SIMPP 的安全協議進行連線資訊的傳輸，所以後續在進行安全的視訊資料傳送時，會先在每次送出視訊串流前，一併送出加密過的驗證標籤，接收方在進行視訊串流解密前，會先針對驗證標籤作比對，如果正確才會進行視訊串流的解密，如果驗證失敗，代表傳送者不是發起邀請者，便不會進行視訊串流的解密，並回應視訊邀請者終止服務，即使第三者以攔截封包的方式取得個別視訊串流封包，由於沒有正確的加解密金鑰所以視訊串流將無法還原並且跳出如圖十的錯誤訊息。

結論
由於網路的應用越來越深入我們的日常生活中，加上資訊的普及化使得即時通訊軟體的角色地位也越來越重要，然而現今主要的即時通訊軟體所提供的視訊服務卻都是不安全的。

而本研究主要是以SIMPP 為基礎，將視訊資料進行加密之後才透由網路進行傳輸，即使有心人士想要擷取視訊封包也僅能發現其是一段沒有辦法讀取的串流格式，而無法從中得知視訊
內容，以提供雙方的視訊服務的保密性和安全性。

參考文獻
[1] C. E. Dalton and W. Kannengeisser, “Instant
Headache,” Hong Kong CERT/CC Security Bulletin , 2003, pp. 2-7.
[2] 蘇暉凱, 王建壹, 古文彬, 游千冊, 吳承, “SIP
Phone 狀態式網路監測系統之設計,” 台灣網際
網路研討會, 2004.
[3] 郭宗益, “安全即時通訊系統設計與實現,” 國立
高雄師範大學資訊教育研究所碩士論文, 2007. [4] TWCERT, 即時通訊軟體使用建議與相關安全
防護, TWCERT
技術專欄, 2009.
.tw/document/column/show.php ?key=95
[5] Microsoft Corporation, Live Communications
Server 功能比較 , Microsoft Office Live Communications Server 2003, 2004. /taiwan/office/livecomm/prodinfo/compare.mspx#EFCAC
[6] 何哲勳, 陳俊忞, 邱基峰, “即時訊息與現狀資訊
相關技術-SIMPLE 與XMPP 之研究,＂ 電腦與通
訊, vol.109, pp41-54, 民93.
[7] M. Day, Lotus , J. Rosenberg, dynamicsoft and H.
Sugano Fujitsu, “A Model for Presence and Instant Messaging ,” RFC2778, 2000.
[8] Microsoft, Windows Live Messenger 2009,
Microsoft
技
術
支
援
服
務
,
2009. /kb/960820/zh n, 2009. tl/zh-TW/apis/talk/l -tw
[9] S. Ludwig, J. Beda, P. Saint Andre, R. McQueen, S.
Egan, and J. Hildebrand, “Jingle (XEP-0166),“ XMPP Standards Foundatio /extensions/xep-0166.html [10] Google, “Google Talk Developer Documentation,”
Google Code Labs, /in ibjingle/libjingle_applications.html
[11] S.E.Morris, Sun Microsystems, and Yahoo Inc.,
YMSG Java API - Yahoo Instant Messenger
Support for Java, , 2005. [12] ark , 2009.
[13] 8.
, 2008.
n,” 2005.
ockBox,
,
/projects/tplockbox/
/ The Wireshark team, Wiresh / IMDetect , MSN Sniffer , 200/
[14] Gabriel, MSN Shadow, /projects/msnshadow
[15] , SSL/TLS, Mozilla Developers,
2006. /projects/security/pki/nss/ssl
[16] Tom Berson, Anagram Laboratories, “Skype
Security Evaluatio [17] TurboPower Software Company, L。