安全實時傳輸協議
此條目沒有列出任何參考或來源。 (2017年4月15日) |
安全實時傳輸協議(Secure Real-time Transport Protocol或SRTP)是在實時傳輸協議(Real-time Transport Protocol或RTP)基礎上所定義的一個協議,旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran(思科)和Rolf Blom(愛立信)開發的,並最早由IETF於2004年3月作為RFC 3711發布。
由於實時傳輸協議和實時傳輸控制協議(Real-time Transport Control Protocol或RTCP)有着緊密的聯繫,安全實時傳輸協議同樣也有一個伴生協議,它被稱為安全實時傳輸控制協議(Secure RTCP或SRTCP);安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性,就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。
對於 RTP 和 RTCP 應用程序來說, SRTP 和 SRTCP 是可選項, 而且即使使用了 SRTP 和 SRTCP 協議, 它們提供的各種功能(例如加密和認證) 也都是可以獨立選擇使用或者不使用的. 唯一的例外就是當使用 SRTCP 的時候消息認證(message authentication)是必選的.
數據流加密
編輯為了提供對數據流的保密,需要對數據流進行加密和解密。關於這一點,安全實時傳輸協議(結合安全實時傳輸控制協議)只為一種加密算法,即AES制定了使用標準。這種加密算法有兩種加密模式,它們能將原始的AES塊密文轉換成流密文:
- 分段整型計數器模式——一種典型的計數器模式,它允許對任意塊的隨機訪問——這一點對於實時傳輸協議的數據流在可能丟包的不可靠網絡上進行傳輸是非常必要的。一般情況下,幾乎所有的函數都能被作為計數器使用,只要它在一次循環中重複的次數不要太多就可以。但是,用於實時傳輸協議數據加密的僅僅是一個普通的整型遞增計數器。運行在這一模式下的AES是其默認的加密算法,它使用的是默認128位長度的加密密鑰和默認112位長度的會話鹽密鑰。
- f8模式——輸出反饋模式的一個變種,它增加了定位功能並改變了初始化功能。其加密密鑰和鹽密鑰的默認值和計數器模式下的AES是一樣的。運行在這種模式下的AES被用於UMTS 3G移動網絡。
除了AES加密算法,安全實時傳輸協議還允許徹底禁用加密,此時使用的是所謂的「零加密算法」。它可以被認為是安全實時傳輸協議支持的第二種加密算法,或者說是它所支持的第三種加密模式。事實上,零加密算法並不進行任何加密,也就是說,加密算法把密鑰流想像成只包含「0」的流,並原封不動地將輸入流複製到輸出流。這種模式是所有與安全實時傳輸協議兼容的系統都必須實現的,因為它可以被用在不需要安全實時傳輸協議提供保密性保證而只要求它提供其它特性(如認證和消息完整性)的場合。
儘管從技術上來說安全實時傳輸協議能輕鬆地納入新的加密算法,但安全實時傳輸協議標準指出除上述加密算法以外的新的加密算法不一定能被簡單地添加到一些安全實時傳輸協議的具體實現中去。添加一種新的加密算法並確保它與安全實時傳輸協議標準相兼容的唯一有效方式是發布一個明確定義該算法的新的伴生的標準跟蹤RFC。
認證、完整性和重放保護
編輯以上列舉的加密算法本身並不能保護消息的完整性,攻擊者仍然可以偽造數據——至少可以重放過去傳輸過的數據。因此,安全實時傳輸協議標準同時還提供了保護數據完整性以及防止重放的方法。
為了進行消息認證並保護消息的完整性,安全實時傳輸協議使用了HMAC-SHA1算法(在RFC 2104中定義)。這種算法使用的是默認160位長度的HMAC-SHA1認證密鑰。但是它不能抵禦重放攻擊;重放保護方法建議接收方維護好先前接收到的消息的索引,將它們與每個新接收到的消息進行比對,並只接收那些過去沒有被播放過的新消息。這種方法十分依賴於完整性保護的使用(以杜絕針對消息索引的欺騙技術)。
參見
編輯外部連結
編輯- RFC 3711, Proposed Standard, The Secure Real-time Transport Protocol (SRTP)
- RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
- RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
- RFC 2104, Informational, HMAC: Keyed-Hashing for Message Authentication