• 沒有找到結果。

文字的加解密

在文檔中 安全的視訊會議 (頁 31-0)

第三章 加解密的原理與實作

3.2 加解密的使用介紹

3.2.3 文字的加解密

(1) 序列化物件

簡單來說,序列化物件就是一個能夠以 byte streams 的 格式來讀取與寫入的物件。JAVA 物件序列化的方法,就是用 ObjectOutputStream 去儲存一個可序列化的物件,再用

ObjectInputStream 將物件讀取回來,就完成了物件的序列化。

(2) 文字加解密的過程

由於傳送的文字是 String 的格式,String 又屬於可序列化 的物件,而且 JAVA 提供了 SealedObject 可以用來建立一個加密 物件,所以我們在文字的傳送接收上使用物件的格式。只要我們 將要加密的字串做成 SealedObject,就可以將這個加密後的物 件輸出到網路的另一端。接收端也是接收物件的型態,再將這個 物件解密成字串。這樣就完成了文字傳輸的加解密。程式碼如下 所示:

傳送: SealedObject so = new SealedObject(str,cipher);

dos.writeObject(so);

// str 為 String , dos 為 ObjectOutputStream , cipher 就 是前一小節完成的加解密器

接收: SealedObject so = (SealedObject)dis.readObject();

str = (String)so.getObject(cipher); 定義新的型態之後,在 RTPManager 中新增這種格式,就可以使 用這個格式傳送接收影像或是聲音的訊息。當接收到某個格式的

等),聲音與影像所要求的標頭內容並不相同。新格式的型態交 RTPSocketAdapter 在 RTPManager 中起使它。而這個類別使用到 RTPConnect 這個物件,這個物件中有 getDataOutputStream、

getControlOutputStream、getDataInputStream、

getControlInputStream 的方法,前兩個方法回傳

OutputDataStream,是用來傳送的資料,而後兩個是回傳 PushSourceStream,就是要接收的資料。

傳送的部分,就是回傳的 OutputDataStream,它提供一個 write 的 Method,它會將準備傳送的資料放在 Buffer 中。我們 就先將 Buffer 中 byte 型態的資料先加密,再來用

DatagramSocket 的 send 方法將資料送出,資料是一個個的 DatagramPacket,這樣就完成了 write。

接收的部分,是回傳的 PushSourceStream,它也提供了 Read 的 Method,將接收的資料放進 Buffer。與傳送不同的是,這裡 先用 DatagramSocket 的 receive 將 DatagramPacket 接收,再將 Buffer 中的資料解密。圖 3-5 可以簡單的看出步驟: (藍色線條 為傳送步驟,紅色線條為接收步驟)

(3) 影音的加密方法

Key 與 Cipher 的產生跟文字加解密的部分是相同的,不同 的地方在於最後對資料加密的動作。這裡我們用到了 dofinal 這個方法,dofinal 是對單一 array of bytes 資料進行加解密 的動作。Cipher 除了提供 dofinal 外還有 update,update 的 方法是對有多個 array of bytes 的 Stream 進行加解密,最後 一段 array 再交給 dofinal 加密。在專題裡,我們就是只用 dofinal 這種方式,將單一段接收到的 DatagramPacket 直接加 解密。程式碼如下:

RTPConnect

getDataOutputStream getControlOutputStream

getDataInputStream getControlInputStream

OutputDataStream

PushSourceStream Method

Method

取得要傳送 Socket

Read Method

Write

Read

Datagram Socket Recieve

圖 3-5 視訊傳輸的流程

temp = cipher.doFinal(data); //加密

cipher.doFinal(buffer,p.getOffset(),p.getLength()

,buffer,offset); //解密

從產生 Key 到加密完成的整個流程圖,同時使用了 update 與 dofinal 兩個方法,如 圖 3-6 所示:

準備傳送的 byte 資料

加密後的 byte 資料

接收到的 byte 資料

接收到資料的起始位置

接收到的長度

解密後的 byte 資料 解密後存放資料的起始位置

Cipher c=Cipher.getInstance(information)

建立金鑰

初使化 Cipher

c.init(Cipher.ENCRYPT MODE,key)

byte[] output=c.update(data) 讀取資料

還有資料嗎?

byte [] output=c.doFinal()

還有要加密的資料嗎?

結束 yes

yes no

圖 3-6 加密流程圖

(4) 對傳送的資料作 XOR

第四章 實現多對多機制的設計方法與核心架構

為了讓專題能完成多對多的機制,我們從最簡單的一對一文字會 議開始構想,採用一邊推展進度一邊選擇策略的方式,階段性改良程 式的缺點。另外我們將說明 Server 與 Client 之間的溝通方式,Parser 的使用和整個操作流程。

4.1 達成多對多模式的構想

在專題製作的過程中,我們討論過一些能建立多對多的結構,所 謂多對多,便是希望在整個視訊會議中能夠讓超過兩人的會議順利進 行,換句話說,我們需要一種方式去協調與會者和與會者的溝通。以 下我們將列出從開始到模式底定的各個溝通架構。

4.1.1 使用端採平等方式-無主從模式

這種做法看起來比較單純,沒有主從關係,構想上使用者彼此要 先約定一個時間,然後在時間之內所有使用者都要在網路上,再以事 先約定的位址互相連結,構成多對多模式。圖 4-1 以圖示說明。

圖 4-1 使用端採平等方式-無主從架構示意圖

每部主機透過網際網路或是高速區域網路的方式,互相連結,而 且每部主機都必須接收、傳送文字的資料流,還有影像聲音的 media stream。

缺點:事前的約定相當麻煩,需要各使用者一致化,再者如果使用者 一多,難保訊息的判定錯誤,而且架構過於單純,沒有一個權 限較高的管理員,很難在溝通上取得一個標準。

因此基於這些理由,決定再研擬出較適當的方法。

4.1.2 主從模式-所有訊息及資料都須經過 Server

圖 4-2 主從模式-訊息及資料經過 Server 管制

在這種模式下,使用者功能不變,不同的是多了一台管理者 Server,Server 的功能是幫助使用者進行溝通,由於 Server 預設為 隨時都在網路上,因此這樣就能方便於使用者的連線,使用者可不定 時的連上 Server 以及離線,事先只須約定好會議時所要使用的加解 密 KEY,而且透過 Server 的管理,使用者不但可以動態加入與離開,

還能請求 Server 把自己的影音資料傳給特定使用者,在經由 Server 的判斷下,會議便可以分成各個小群組,換句話說,在同一台 Server

中可能存在兩個以上的會議群組,而且每個群組都有屬於自己的 KEY,因此群組間就有安全的保障。

缺點:由於使用者不管是傳送文字或是傳送影音,其資料都會經過 Server 轉送,因此這將會造成 Server 嚴重的負擔,也就是說 只要上線人數超過一定數量,Server 就可能因資源不足而停 擺,還有,如果所有東西都經過 Server,難保資料不被竊取。

基於上述理由,繼續對此模式進行最後改良。

4.1.3 主從模式-影音使用直接點對點

由於影音資料直接經過 Server,可能會導致資源不足,因此直 接的方式便是將文字與 media stream 分開,利用 Server 的功能,直 接取得欲進行會議者的位址,再分別以各位址為遠端目的主機,將影 音資料傳送過去,圖 4-3 簡單說明此模式。

圖 4-3 主從模式-影音使用直接點對點

黑色線代表 Client 與 Server 之間的規則溝通路線,橘色虛線則 代表 Client 與 Client 之間的影音傳送,當 A 想跟 B、C 進行視訊會 議時,A 就告訴 Server,經由 Server 的 Parser 得知與會者共有 A、

B、C 三人,隨即 Server 回應至 Client,通知 A 關於 B、C 的位址,

通知 B 關於 A、C 的位址,通知 C 關於 A、B 的位址,如此三人便能以 該資訊,將位址送給自己的 sender 以及 receiver,進行 media stream 的傳送與接收工作。

A B

C

Server

4.2 Server 與 Client 的結構及溝通規則設計

在完成了初步的多對多機制後,接下來便要對 Server 與 Client 的溝通方式做一個規劃,於是我們將訊息傳遞的部分分成兩組訊息 Parser,一組給 Server 端使用,另一組則用在 Client 端,原則上訊 息傳遞我們運用了 Java 所提供的 ServerSocket 與 Socket 作為 Server 端與 Client 端的溝通管道。以下分成 Server、Client 與訊 息溝通的實際操作,三個小節來作說明。

4.2.1 Server 端結構與訊息 Parser 結構

在多對多的機制下,一部 Server 主機,必須有能力同時與多部 Client 端主機進行連線,因此 Server 使用了線程(Thread)管理的方 式,隨時都有一個 Socket 等待連線,當有新 Client 要連線至 Server 時,Server 便會開始建構 Thread,並將新的來的 Socket 傳給 Thread 以便能擷取使用者資訊,圖 4-4 說明了 Server 端的基本結構。

圖 4-4 Server 端結構圖

圖中 ClientThread 與 Client 是成對運作的,當有新的 Client 加入時,ServerSocket 會收到通知,於是呼叫 ClientGroup 建立新 的 Thread 進行連接 Client 的工作,每個 ClientThread 都有各自的 I/O stream,它是訊息的出入接口,然而整個 Server 最核心的部分,

ServerSocket ClientGroup

ClientThread 3 ClientThread 1

Main

Client 1

ClientThread 2

Client 2 Client 3

Internet

就屬 ClientGroup,由於它是每個 ClientThread 的上層,相當於一 個管理者,它有建立、刪除、修改 ClientThread 的權利,所有從 ClientThread 收到的訊息都要經過 ClientGroup,如圖 4-5,當 Client 1 要對 Client 3 說悄悄話時,便需要 ClientGroup 的轉送功 能,所以 ClientGroup 就需要有訊息 Parser 的能力。

圖 4-5 Server 的訊息分析服務

分析器(Parser)

Server 的 Parser 所要分析的訊息均來自 Client,因此所有 Server 接收到的訊息都有一定的格式,就像指令或命令一樣,經過 Parser 的翻譯,成為了實際的動作。指令格式如圖 4-6。

ClientGroup

ClientThread 3 ClientThread 1 ClientThread 2

Client 1 Client 2 Client 3

圖 4-6 訊息的指令格式

圖 4-7 中,整個命令分成兩部分,前半部是指令列,後半部是伴 隨的內容值,中間以符號“||”隔開,其中切字串的技巧是運用到了 Java 所提供的 StringTokenizer 類別,使用方法如下:

String sampleCommand ="strA||strB||strC||strD";

StringTokenizer st = new StringTokenizer(sampleCommand, "||");

for (int i=0; i<st.countTokens(); i++) System.out.println(st.nextToken());

/* 此程式片段將會印出 strA strB strC strD */

say 嗨! 你好嗎? 我是你家隔壁的小強。

say || 嗨! 你好嗎? 我是你家隔壁的小強。

將此段訊息,送給 Server 上的其他使用者。

指令列 內容值

Server 的 Parser 所分析的指令如下表:

表 4-1 Server 的指令表

C o m m a n d 說 明

l o g i n

此指令為登入指令,當有新 Client 要登入 Server 時,Client 便送出第一個指令

命令列為whisper,內容為嘿!我告訴你一個秘密喔 || Selina,

其中,內容會繼續以"||"為單位再切出兩個字串,嘿!我告訴你

video || Selina & hebe

命令列為video,內容為Selina & hebe,其中,內容會繼續以

"&"為單位在切出兩個字串,Selina和hebe都是接受者。

Server 的回應指令:

To Selina、hebe and Tom:

video || Tom 想邀請你加入視訊會議 ||

192.168.0.1&192.168.0.2&192.168.0.3 To all users:

list ||Tom(視訊中)#3&Selina(視訊中)#1&hebe(視訊中)#5

AVo f f l i n e

此指令為結束視訊會議指令,當其中 Tom 想結束時,便會有如下 的指令:

AVoffline || Tom 命令列為AVoffline,內容為Tom。

Server 的回應指令:

To all users:

list ||Tom#3&Selina#1&hebe#5

l o g o u t list || Selina#1&hebe#5

4.2.2 Client 端結構與訊息 Parser 結構

與 Server 端比起來,Client 端的結構就比較簡單,傳送與接收

都寫在同一個類別,只需要知道 Server 的位址與 KEY 便可以連上 Server 進入聊天室。圖 4-8 說明了 Client 的結構。

圖 4-8 Client 端結構圖

圖中 Client 為主要核心,它能利用 Socket 連上 Server,所有 的指令訊息也都從這裡進出,因此它必須具備 Parser 的功能,另外 GUI 建立了整個聊天室的外觀和許多操作的介面,方便使用者輸入與 觀看回應結果,AVTransmit 負責將 media stream 以 RTP 封包的方式 傳送出去,AVReceiveAndPlayer 則接收 RTP media stream 並將之撥

Conference

Client GUI

AVTransmit AVReceive

AndPlayer

Internet

Audio & Video Audio & Video

Message

放,呈現在 GUI 元件中,然而 AVTransmit 與 AVReceiveAndPlayer 並 不會直接連到 Server,它們是透過 Client 與 Server 的溝通,取得

放,呈現在 GUI 元件中,然而 AVTransmit 與 AVReceiveAndPlayer 並 不會直接連到 Server,它們是透過 Client 與 Server 的溝通,取得

在文檔中 安全的視訊會議 (頁 31-0)

相關文件