安全實時傳輸協議

安全實時傳輸協議（Secure Real-time Transport Protocol或SRTP）是在實時傳輸協議（Real-time Transport Protocol或RTP）基礎上所定義的一個協議，旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。它是由David Oran（思科）和Rolf Blom（愛立信）開發的，並最早由IETF於2004年3月作為RFC 3711發佈。

由於實時傳輸協議和可以被用來控制實時傳輸協議的會話的實時傳輸控制協議（RTP Control Protocol或RTCP）有着緊密的聯繫，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。

在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即使使用了安全實時傳輸協議或安全實時傳輸控制協議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協議時，必須要用到其消息認證特性。 ^[1] 

由於實時傳輸協議和可以被用來控制實時傳輸協議的會話的實時傳輸控制協議（或）有着緊密的聯繫，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（或）；安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。

在使用實時傳輸協議或實時傳輸控制協議時，使不使用安全實時傳輸協議或安全實時傳輸控制協議是可選的；但即使使用了安全實時傳輸協議或安全實時傳輸控制協議，所有它們提供的特性（如加密和認證）也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協議時，必須要用到其消息認證特性。 ^[2] 

為了提供對數據流的保密，需要對數據流進行加密和解密。關於這一點，安全實時傳輸協議（結合安全實時傳輸控制協議）只為一種加密算法，即AES制定了使用標準。這種加密算法有兩種加密模式，它們能將原始的AES塊密文轉換成流密文：

除了AES加密算法，安全實時傳輸協議還允許徹底禁用加密，此時使用的是所謂的“零加密算法”。它可以被認為是安全實時傳輸協議支持的第二種加密算法，或者説是它所支持的第三種加密模式。事實上，零加密算法並不進行任何加密，也就是説，加密算法把密鑰流想像成只包含“0”的流，並原封不動地將輸入流複製到輸出流。這種模式是所有與安全實時傳輸協議兼容的系統都必須實現的，因為它可以被用在不需要安全實時傳輸協議提供保密性保證而只要求它提供其它特性（如認證和消息完整性）的場合。

儘管從技術上來説安全實時傳輸協議能輕鬆地納入新的加密算法，但安全實時傳輸協議標準指出除上述加密算法以外的新的加密算法不一定能被簡單地添加到一些安全實時傳輸協議的具體實現中去。添加一種新的加密算法並確保它與安全實時傳輸協議標準相兼容的唯一有效方式是發佈一個明確定義該算法的新的伴生的標準跟蹤RFC。 ^[2] 

以上列舉的加密算法本身並不能保護消息的完整性，攻擊者仍然可以偽造數據——至少可以重放過去傳輸過的數據。因此，安全實時傳輸協議標準同時還提供了保護數據完整性以及防止重放的方法。

為了進行消息認證並保護消息的完整性，安全實時傳輸協議使用了HMAC-SHA1算法（在RFC 2104中定義）。這種算法使用的是默認160位長度的HMAC-SHA1認證密鑰。但是它不能抵禦重放攻擊；重放保護方法建議接收方維護好先前接收到的消息的索引，將它們與每個新接收到的消息進行比對，並只接收那些過去沒有被播放過的新消息。這種方法十分依賴於完整性保護的使用（以杜絕針對消息索引的欺騙技術）。 ^[2]