解決方法

我們可以在VoIP 的架構中整合 EMSS，其中包括兩件工作：

(1) 在連線階段交換驗證 EMSS 的資訊。

就像SRTP 沒有金鑰交換機制，必須仰賴 MIKEY/SDES 幫它處理一樣，EMSS

本身並沒有牽涉到交換驗證資訊的機制，所以必須在連線階段的時候告訴別 人說：『我待會會在我的語音封包中加入EMSS，驗證所所需的資訊如下…』。

(2) 在語音串流中加入 EMSS 簽章。

我們以圖 42 說明，在語音串流中加入 EMSS 簽章的流程：

圖 42 在語音封包中加入 EMSS 的流程圖

Step1：VoIP Encoder 將使用者發出的聲音編碼成數位格式，成為 Voice Payload。

Step2：從記憶體中取出之前封包的雜湊值，附加到 Voice Payload 中，成為 RTP Payload。

Step3：將 RTP Payload 加上 RTP Header。

Step4：將 RTP 封包封裝成 UDP 格式傳送到受話方。

Low Sender Delay

Low computational overhead

我們透過上述流程發現，在語音串流中加入EMSS，可以達到下列三項目的：

z 語音串流的不可否認性(No-Repudiation) ：EMSS 是串流簽章的一種方法，只 有私鑰擁有者才能在語音封包中建構EMSS authentication chain，認證者使用 簽署者的公鑰還原EMSS 驗證圖形。

z 幾乎沒有傳送端延遲(no sender delay)： EMSS 不需要緩衝語音資料，它在產 生語音資料之後，馬上從記憶體中取出之前運算的雜湊值，並附加在該語音 資料之後即可送出，並不會有回音問題。

z 低運算資源負載(low computational workload)： EMSS 的大部份工作都只在運 算雜湊值，不會對裝置產生太大的負擔。

G.726 ADPCM 30 198 G.728 LD-CELP 30 138 G.729A CS-CELP 20 98 G.729A CS-CELP 30 108

G.729A VAD 180 82

用一個情境來點明問題所在：假使我希望驗證率能滿足百分之九十五，如果 不知道網路環境為何，為了保險起見，我讓每個語音封包的

number_of_hash(number of edges per node)越大越好，比如說 4，但實際上，目前 網路的封包遺失率很低，number_of_hash 只需要 2 就可以達到 95%以上的驗證率，

那多出來的兩個雜湊值就造成了浪費。而另一種相反的情況是，若我總是假設網 路狀況很好(封包的遺失率很低)，並讓每個語音封包的 number_of_hash 為 2，但 偏偏今天網路的封包遺失率很大，那麼我的驗證率將會變得很低。所以最理想的 情況，應該是視網路的狀況，來動態調整number_of_hash 的值才合理。VoIP 中 使用RTCP 的 SR(Sender Report)、RR(Receiver Report)來提供關於 QoS(Quality of Service)的參數，這些參數中包括：兩 RTCP 間隔時間內的封包平均遺失率(average fraction rate)為多少。若我們可以利用這點，來做為動態調整 EMSS 參數值的依 據，那就可以節省頻寬上的浪費。

最後我們將(1)VoIP 整合 EMSS (2)及加入 RTCP 動態調整參數的機制整理如 圖43 所示：

Initiator Responder

Invite Message with (

)

Ack Message with (

)

RTP with EMSS authentication chain

EMSS Signature

RTCP Report

RTP with EMSS authentication chain EMSS

Signaling Phrase：

Step1：在連線建立階段，連線發起者透過 Session Establishment Protocol(SIP、

H.323、web service…etc)，將自己的數位憑證及 EMSS 使用的雜湊演算法、簽章 演算法，最後加上數位簽章傳送給回應者。

Step2：回應者亦透過相同的方式，將自己的數位憑證及 EMSS 使用的雜湊演算 法、簽章演算法，最後加上數位簽章送給發起者。

Conversation Phrase：

Step3：雙方在傳送出去的語音封包中建立 EMSS authentication chain，這點會因 為EMSS 本身的特性滿足 no sender delay 及 low computational overhead 這兩項 需求。

Step4：雙方在談話過程中送出 EMSS 簽章，這點會因 EMSS 本身的特性而滿足 No-Repudiation 這個需求。

Step5：雙方在談話過程中，不斷由背景向彼此發送 RTCP report 封包。

Step6：雙方根據 RTCP 中報告的平均封包遺失率去取得預估的雜湊值數量。

Step7：使用新的雜湊值數量為參數，在語音封包中建立 EMSS authentication chain。

Step3、Step4、Step7 我們可以直接使用 EMSS 方法在語音封包中加入串流簽章，

關於 EMSS 的鏈結方法我們已經在 2.5.3 小節詳細討論過，在此便不多加贅述。

我們接下來將在 3.3 小節討論如何在連線階段交換 EMSS 資訊(Step1、Step2)及 3.4 小節討論根據 RTCP 動態調整參數的機制(Step5、Step6)。