Cryptography Reference
In-Depth Information
verbindungslosen UDP-Dienst (User Datagram Protocol). Bei einer Nutzung von TCP
(Transmission Control Protocol) würden bei Übertragungsfehlern IP-Pakete wiederholt werden
und damit Verzögerungen auftreten, was dem Real-Time-Ziel widerspricht.
6.5.1
SRTP und SRTCP
Das
Secure Real-time Transport Protocol
(SRTP) erweitert das RTP-Protokoll um die Mög-
lichkeit, Multimediadaten zu verschlüsseln, ihre Integrität und ihren Ursprung sicherzustellen
und ein Wiedereinspielen von bereits versendeten Paketen zu erkennen. Dieses relativ neue
Internet-Protokoll wurde von Cisco und Ericsson entwickelt und als RFC3711 [RFC3711] im
März 2004 vorgestellt. Da RTP und RTCP eng miteinander verwoben sind, gibt es auch eine
SRTCP-Variante zur Absicherung der Steuerinformationen. Die sicheren Varianten erweitern
jeweils die unsicheren Varianten um die Möglichkeiten, Datenpakete zu verschlüsseln und zu
authentisieren. Es wurde beim Design von SRTP/SRTCP darauf geachtet, RTP/RTCP um
möglichst kompakte Datenstrukturen zu erweitern, damit die Performanceeinbußen durch
Sicherheit bei der Echtzeit-Datenübertragung möglichst gering bleiben.
Zur optionalen Verschlüsselung wird standardmäßig bei SRTP/SRTCP der AES mit einer
Schlüssellänge von 128 Bit eingesetzt. Um eine Verschlüsselung von Datenströmen zu ermög-
lichen, kann der Block-Algorithmus AES (Kap. 2.6) in zwei Modi betrieben werden:
Segmented Integer Counter Mode -
Bei diesem bereits in Kap. 2.7 vorgestellten Zähler-
modus hängt die Verschlüsselung des nachfolgenden Datenpakets nicht von der Verschlüs-
selung des vorherigen ab. Dadurch ist das Verfahren resistent gegen den Verlust eines Da-
tenpakets, der jederzeit bei der Echtzeitkritischen Übertragung in offenen Netzen vorkom-
men kann.
Der
f8-Modus
ist eine Variation des in Kap. 2.7 vorgestellten OFB (Output Feedback Mo-
de), der um eine Suchfunktion und eine veränderte Initialisierung erweitert wurde.
Um nur Integrität und keine Vertraulichkeit sicherzustellen, kann SRTP in der sogenannten
“NULL cipher”-Konfiguration genutzt werden. Die Multimediadaten werden dabei unver-
schlüsselt übertragen. Der Ursprung und die Unveränderbarkeit der Daten ist allerdings über
den durch HMAC gesicherten Nachspann, dem sogenannten „authentication tag“, weiterhin
garantiert. Diese Variante ohne Verschlüsselung entspricht von der Sicherheit einem Einsatz
von IPSec im AH-Modus.
In beiden Sicherheitsprotokollen wird ein HMAC zur Integritätssicherung verwendet. Bei
SRTP steht allerdings nur der SHA1-Hashalgorithmus zur Verfügung. Das 160 Bit Ergebnis
wird noch mal auf die Hälfte verkürzt, d.h. 80 Bit statt der Kürzung auf 96 Bit bei IPSec. Der
HMAC wird über die Nutzlast, die das ursprüngliche RTP/RTCP-Paket enthält, den Header
und eine Sequenznummer berechnet. Durch den Einbezug einer Sequenznummer in die
HMAC-Berechnung kann eine Replay-Attacke unterbunden werden.
Ein Nachteil des SRTP-RFCs (RFC, Request for Comments) ist die feste Verknüpfung mit
dem AES-Algorithmus. Technisch wäre eine Erweiterung um andere Verschlüsselungsverfah-
ren durchaus möglich, allerdings schreibt der Standard vor, AES zu nehmen. Somit können
Standard-konforme SRTP-Implementierungen nur mit AES zusammen realisiert werden.
