安全傳輸協定須融於異質環境
安全傳輸協定(Security Transport Protocols)除了可應用在金融交易資料外，亦可應用於網路瀏覽所涉及之相關機密資料。在數位多媒體內容保護技術中，目前有數種安全協定可供使用在資料流(Data Traffic)的保護上，如作用在網路層(Network Level)的IP保護安全協議標準(Internet Protocol Security, IPSec)；作用在傳送層(Transport Level)的安全傳輸層(Transport Layer Security)安全協定(Security Protocols)。但上述安全協定不一定適用各種型態的資料流。為了滿足異質環境(Heterogeneous Environment)及即時應用(Real-time Applications)上之需求，應用層(Application Level)上的安全協定運作更是當務之急。
數位多媒體在傳送的需求大致如上所述，但能應用一般資料安全傳送協定的媒體種類有限，如靜態圖檔或一般媒體檔案利用HTTP方式下載。但是對於如使用RTSP傳送協定的即時串流媒體而言，這些現有的資料安全傳送協定不見得適用。因為即時串流媒體對頻寬(Bandwidth)限制、傳送錯誤敏感性(Transmission-error Sensitivity)、延遲(Delay)與行動終端的運算複雜度等問題，皆異常敏感且容忍性低。也是即時串流媒體在是目前異質環境與即時應用上面對的四個主要問題。
目前關於上述問題的相關IP解決方案，均非針對異質性環境的需求所設計，尤其較少關注到頻寬的消耗與訊號傳遞的來回次數問題。這問題在無線3G網路上會更突顯，因為無線網路的資源有限且頻寬稀有，若使用目前標準IP上的安全協定，可能增加系統營運成本外，還可能無法達到預期的效果。換句話說，以標準IP傳送方式來傳送語音資料(Audio data)，在一個典型的即時傳輸協定(Realtime Transport Protocol, RTP)語音費用負載約為33位元組的情況下，在頻寬使用上是缺乏效率的。
ROHC壓縮封包標頭有效節省頻寬
一般在使用IP安全協定時，這些協定會將本身的標頭(Header)加入封包，甚至在某些加密演算法下，封包還須要入訊息填補(Message Padding)資訊。若該訊息有驗證(Authentication)需要，每一個封包還會加入額外的驗證位元，這些位元皆可能成為有效壓縮標頭的一種障礙。 為兼顧即時媒體傳送安全問題並有效使用頻寬，C. Bormann等人便提出ROHC(RObust Header Compression)技術來有效壓縮封包標頭(Package Header)。ROHC可將IPv4/UDP/RTP的封包壓縮到平均只剩二位元組，對使用RTP協定的語音封包而言可節省頻寬，並可作為有效壓縮即時串流封包標頭的解決方案。
目前此ROHC技術主要被用在通訊連結技術的發展上，尤其是無線網路應用。依據網際網路工程工作特別小組(IETF)資料顯示，ROHC經測試可在WCDMA、CDMA-2000以及EDGE上面運作得宜。不過因複雜度較高，新的ROHC多了簡化實作及更新功能，稱之「ROHCv2專案」，之前的ROHC版本則戲稱為ROHCv1。
ROHCv2專案目的在於不改變ROHC既定的協定架構下，改善壓縮器與解壓縮器之間的封包重排容忍性(Reordering Tolerance)，並降低協定複雜度。要注意的是，ROHCv2主要目的在於降低實作ROHC協定的複雜度，但卻不相容於ROHCv1規格。
IP即時串流封包經過標頭壓縮處理後，在串流媒體服務的型態下，即時傳輸協定主要負責語音(Voice)、視訊(Video)或音訊(Audio)方面的傳送協定。
然而，一般IP安全協定在這些應用上面，有適用上的問題，因此安全即時通訊協定(Secure Real-Time Protocol, SRTP）的發展確實有其必要性。為了RTP的安全保密，IETF發展SRTP以滿足保密媒體串流的要求，一個SRTP封包的架構如圖1所示。
SRTP高彈性擴充解決適用性問題
SRTP的設計架構保留彈性的擴充功能以延長協定可使用的壽命，因此SRTP一開始設計時並非定位為單一產品，其乃以基礎建設骨架(Framework)的方式進行設計。所以在SRTP架構中可以獨立分開實作編碼部分與整合性保護部分，因為在SRTP中並未編碼保護RTP，因此對RTP標頭進行壓縮運作以保留頻寬。另外，在SRTP預定義轉換(Predefined Transforms)中亦提供加密套件，以因應不同異質性環境或即時應用的需求，藉此改善加密套件之間的互通(Interoperability)。
SRTP定義兩種編碼轉換(Encryption Transforms)，一是H. Lipmaa、D. Wagner與P. Rogaway所提議的Counter模式；另一為f8模式。這兩種編碼轉換是基於AES的串流加密器(Stream Ciphers)之區塊式編碼器，避免位元錯誤而波及其他傳送位元。而其預定義的驗證轉換(Authentication Transforms)為HMAC/SHA-1，這兩種驗證方法是經過多重考驗的成熟雜湊架構(Hash-based)函數。
但對於群播(Multicast)用戶而言，其屬性與僅傳送單一用戶者不同。若在群播裡提供原始資料驗證，將花費高成本，目前此方面有效的驗證方法尚未健全。所以SRTP在群組(Groups)應用上，並未提供原始資料驗證的功能選項。群播問題屬較複雜的管理環節，若資料串流又加上編碼或驗證等工作，無疑加重既有系統的負擔。因為每個安全協定都需要「密鑰管理協定(Key Management Protocol, KMP)」以確保未來密鑰交換的安全及規範成員間的安全參數(Security Parameters)，不同的媒體遞送方式，其使用的KMP技術可能存在彼此適用問題。
在群播的管理安全問題上，核心環繞在群組鑰匙管理的機制面。造成該問題複雜化的因素，在於群組內的會員變動率大且架構傾向浮動所致。因此群播(Multicast)中的群組鑰匙管理問題，是目前DRM系統或是媒體本身編碼、驗證機制所共同面對的難題。
在一群播基礎架構裡，每一個遞送資料的通訊區段(Session)安全主要由兩個元件所控制，一個是鑰匙伺服器(Key Server, KS），另一為群組控制者(Group Controller, GC)」。KS負責維護、散播群組所需要編碼/驗證的密鑰；GC則負責群播會員的驗證、認證與存取控制。KS與GC的功能可實作在同一台實體裝置，亦可分開實作。
在群播腳本裡，為確保群播通訊區段的機密性，傳送者(Source)會與合法會員分享一對稱式密鑰(Symmetric Key)，此對稱式加密系統的密鑰便是流量編碼鑰匙(Traffic Encryption Key, TEK），此鑰匙可解開編碼後的群播流量資訊。因此，傳送者會先用TEK將訊息編碼後才進行機密傳送。
因群播會員具有較大流動性，為確保離開的會員不得再觀看機密訊息，KS會重新產生一個新的TEK並遞送給現存會員，往後的機密訊息就以新TEK進行編碼與解碼，此過程即所謂「重發鑰匙(Re-keying)」過程。整個群組密鑰的重新更新與編碼管理過程，稱為「群組密鑰管理(Group Key Management, GKM)」。群組密鑰的管理會隨著會員的增加而趨於複雜，換句話說，會員越大，群組的密鑰更新成本隨之增高。
一個有效的群組密鑰管理需求可分成四大主要類別，分別是鑰匙伺服器需求、安全需求、服務品質(Quality of Service, QoS)需求及群組成員需求。每一個類別下另各有其次要需求，依據Y. Challal及H. Seba看法，這些次要需求可歸納如表1。
對群組鑰匙管理協定(Group Key Management Protocol, GKMP)的描述，在目前常用的集中化、去集中化與分散式三種不同的群組鑰匙管理技術中，哪一個群組鑰匙管理協定才適用？事實上並無一定標準，不過可參考Y. Challal及H. Seba所提的四項需求中，何者能滿足最多次需求者即是。
為使SRTP更加完備，其KMP須滿足SRTP所支援的各種應用需求。但在許多即時應用(Real-time Applications)裡面易存在延遲問題，尤其在無線應用環境裡面，因其環境運算資源(Computational Resources)有限，一旦這些安全協定技術被應用進去，不管協定多有效率，都將會額外耗損端點運算資源或網路頻寬等系統資源，因此若要在無線應用環境裡面運用，其程式大小與運算成本須獲得適當控制。
在系統與端點(End Points)的密鑰常見的協調方式有兩種，一種是以用戶端對用戶端(P2P)的協調方式；另一種是利用KMP方式來發送密鑰及安全參數。前者提供點對點式的便利，但其缺點在設定與運作上會較複雜；後者提供較一致的整體安全控制，不過缺點則是整個系統的運作成本會比前者高。適用哪一種密鑰協調方式，端視應用種類、目的與商業價值而定。因此一個安全協定，意味著高運算資源的消耗，在發展SRTP時，高通透量(High Throughput)與異質環境的滿足是其主要設計核心原則。不過在設計STP的同時，也要設計安全實時控制協定(Secure Real-Time Control Protocol, SRTCP)，RTCP為RTP的控制協定，在設計SRTCP時其所遵循的標準亦比照SRTP的設計標準進行。
基於上述限制，難以將已發展成熟的一般IP安全協定直接套用在無線終端設備，如要在這些行動裝置上面執行公鑰編碼鑰匙(Public Key)運算，將犧牲龐大運算成本，因此在多數情況下對加密系統的選用上，「對稱式編碼(Symmetric Encryption）」方法仍是首選。
串流加密器簡化錯誤位元處理
欲將加密系統用在無線環境，另需注意位元錯誤發生的問題。在某些應用型態，如音訊裡面，錯誤可合理被處理。但若該訊息是被驗證的，即使是一個位元的錯誤也會導致整個封包的丟棄，這對接受端來說，將導致整體感官品質(Perceived Quality)下降。不過即使訊息未經驗證要求，在密碼系統層級上，尤其在加密層面(Decryption Phase)也可能出現位元錯誤問題。因此，接受端的傳播錯誤控制（Propagate Errors Control）是一關鍵的控制技術。
至於一個訊息的錯誤傳播與錯誤位元的發生位置，須看當時所選擇的解碼器種類而定，基於上述理由，串流加密器(Stream Cipher)或許是即時串流應用中較佳選擇，因為這種串流加密器不會像DES和AES區塊加密器一樣，以整批的方式處理傳播錯誤的問題。一個區塊式加密系統與串流式加密系統的運作示意圖如圖2。
SRTP設計優先考量頻寬
因為封包加密/驗證的需求，往往會無形之中增加頻寬的消耗，因此在SRTP的設計理念裡面，頻寬的保留(Bandwidth Preservation)是主要的核心任務之。而頻寬保留的常見作法，通常是使用「封包序號(Package Sequence Number, Packet SN)」來同步化安全演算法(Security Algorithms)。RTP的序號通常位於封包的標頭位置，當系統陸續送出封包時，序號會以單調遞增的方式，如同排隊抽號碼牌的情形一般。陸續增加號碼。SRTP使用的是RTP原有的序號，因此它在同步化(Synchronization)上面並不需要其他額外的欄位。不過遺憾的是RTP序號只有16位元大小，因此當此大小容量被填滿時，RTP序號就會被迫重新計算，如此一來，SRTP所使用的密鑰也要重新加以改變。對應重新計數的SN之密鑰，或許就須要重新執行一次密鑰管理協定(Key Management Protocol, KMP)，這過程就是所謂的「重發行密鑰(Re-keying)」。
在SRTP的基本架構內，一般情況下並不會於RTP封包內加入任何額外的位元，不過在「重發行密鑰」時，除了整合保護所需要的驗證標籤(Authentication Tag)外，還需要一個「主密鑰識別器(Master Key Identifier, MKI)」加入RTP封包，不過此欄位是一選擇性的可變長度欄位(Variable Length Field)。為了頻寬保留，封包的驗證標籤會被切為四位元組大，此作法雖會犧牲一些安全性，但在即時應用上可被接受。
SRTP與實際的密鑰管理協定（KMP）兩者互為獨立運作， SRTP為提供足夠安全功能，其所需要的密鑰數目須依據其所提供的安全功能數目而定。另外，SRTP亦使用主要密鑰(Master Key)與通訊區段密鑰(Session Key)的觀念，由密鑰管理系統負責交換主要密鑰，但通訊區段密鑰則衍生自主要密鑰，亦為實際用於編碼或驗證的密鑰。
為保持SRTP的安全強度，SRTP提供「密鑰更新(Key Refresh)」功能。若此選項一旦啟動，會依據主要密鑰定期產生新的通訊區段密鑰，因為新的通訊區段密鑰乃依據原有主要密鑰而產生，所以啟動此功能並不造成密鑰管理系統的負擔增加。所以一個主要密鑰可能為多個SRTP串流所共享，其並儲存在多媒體通訊區段內以降低密鑰交換數目。
為達共享的目的，應注意避免重複使用密鑰串流。避免重複使用密鑰串流，SRTP提供不同且唯一的起始向量(Initialization Vector, IV)到每一個串流加密器，若無法提供不同且唯一的起始向量至不同加密器，就應使用不同的主要密鑰。另外一種關於有限RTP序號的解決方法，是直接利用RTP的序號來重發行密鑰，但這種方法欠缺前者具備的彈性。此外，執行重發行密鑰過程時會大量消耗系統資源，因此避免一個長時間的通訊區段不斷發出重發行密鑰的要求，所以SRTP在局部使用了一個三十二位元的紀錄器，稱為「反覆計數器(Rollover Counter）」，用以加大原本RTP序號使用的序號數量空間。
(詳細圖表請見新電子科技雜誌255期6月號)
