Secure Real-Time Transport Protocol

from Wikipedia, the free encyclopedia

In the Secure Real-time Transport Protocol ( SRTP , English for Secure Real-time Transport Protocol ) is, to use the encrypted version of the Real-time Transport Protocol (RTP). The protocol was presented in March 2004 by the Internet Engineering Task Force (IETF) in RFC 3711 .

It is particularly suitable for encrypted transmission of communication over the Internet and is also being used increasingly in IP telephony . The cryptosystem uses the Advanced Encryption Standard (AES).

Depending on the implementation, the protocol can either be used for transport encryption when transmitting voice data between a terminal on the customer side and the server of the communication provider or for complete end-to-end encryption between communication partners.

A considerable increase in security against attacks can already be achieved through the transport encryption , since it is more difficult for attackers to access the voice data transmitted between the customer device and the communications server of the telephony provider. The controlled authority access to the communication remains possible in the internal area of ​​the communication provider.

The use of SRTP for a connection to the server of the communication provider does not guarantee that transport encryption will also take place in the further course of the communication transmission. In particular, it is still common practice today that the transmission of telephone calls from one provider to another provider is unencrypted. Due to the higher number of simultaneously transmitted voice data at this point, however, access to a specific conversation is very difficult for third parties - with the exception of financially well-funded secret services. This is particularly due to the fact that the voice data are packaged in small packets and transmitted independently of one another.

Due to the legal situation in the respective countries, end-to-end encryption must be set up by the conversation partner themselves, since telecommunications providers are legally obliged to enable authorities to access calls upon court order. For this reason, providers who are subject to the German Telecommunications Act, for example , are not allowed to enable automatic end-to-end encryption. However, it is generally not forbidden in various countries to provide end-to-end encryption yourself. To do this, the end devices must be equipped accordingly on both sides. As a rule, SRTP is also used, but it is controlled by a different protocol, for example ZRTP .

In Germany, individual landline telephony providers now support SRTP. Easybell provides information on its website about how the protocol can be used by its customers for transport encryption . The German Telekom does not advertise the functionality active towards its end customers, but provides interface information for manufacturers of appropriate terminal equipment.

The German-based manufacturer of the FRITZ! Box , AVM , has now implemented the functionality experimentally for some router models.

It should be noted that the encryption supported by the providers mentioned is not end-to-end encryption between the caller and the person being called, but only encryption between a customer's device (router, modem or IP telephone ) and the provider's telephony server.

See also

  • ZRTP (protocol for negotiating cryptographic keys for SRTP)

Web links

Individual evidence

  1. Easybell Help Center on the question Can I encrypt the telephony?
  2. Easybell Help Center on the question Does easybell support SRTP data encryption for VoIP?
  3. Easybell Help Center on the subject of encrypted calls with easybell IP-Phone (Htek UC924)
  4. Technical Specification of the SIP (Gm) interface between the User Equipment (UE) and the IMS platform of Deutsche Telekom , Chapter 4.2.8 "Secure VOIP", accessed on May 7, 2020
  5. Nadine Juliana Dressler: New FritzOS laboratory update brings support for encrypted telephony. In: winfuture.de . December 10, 2019, accessed July 3, 2020 .