Bundesamt für Sicherheit in der Informationstechnik

M 5.135 Sicherer Medientransport mit SRTP

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Leiter IT

Das Real-Time Transport Protocol (RTP) wird zur Übertragung von Mediendaten der IP-Telefonie und das Real-Time Streaming Protocol (RTSP) zu deren Kontrolle eingesetzt. Beide Protokolle bieten keine eigenen Schutzmechanismen gegen das Abhören und gegen Manipulationen von IP-Telefonaten an. Erweiterungen von RTP/RTCP sind SRTP/SRTCP, die Schutzmechanismen für die Übertragung zur Verfügung stellen. Beim Einsatz von VoIP sollte überlegt werden, die Nutzdaten durch den Einsatz von SRTP/SRTCP zu schützen. Die Entscheidung ist zu dokumentieren.

Überblick

SRTP kann in VoIP eingesetzt werden, um Vertraulichkeit, Authentizität und Schutz gegen Replay-Angriffe (Wiedereinspielen von Nachrichten) für die Medienübertragung auf Basis von RTP zu erreichen. Es ermöglicht eine sichere Unicast- und Broadcast-Übertragung. Zum Transport werden die RTP/RTCP-Pakete in SRTP/SRTCP-Pakete eingebettet.

Schlüsselmanagement

Das Protokoll SRTP definiert einen Masterschlüssel und jeweils einen Sitzungsschlüssel für Verschlüsselung und Authentisierung. SRTP enthält keinen eigenen Mechanismus zur Erzeugung und Verwaltung der mindestens 128 Bit langen Masterschlüssel. Dies muss mit anderen Standards, wie z. B. Multimedia Internet Keying (MIKEY) realisiert werden.

Falls SRTP eingesetzt wird, ist festzulegen, in welchen zeitlichen Abständen der Masterschlüssel einerseits und die Sitzungsschlüssel andererseits gewechselt werden.

Verschlüsselung

Bei der Verwendung von SRTP im Rahmen von VoIP sollte in der Regel das symmetrische Verschlüsselungsverfahren AES -CTR (Advanced Encryption Standard - Counter Mode) aktiviert werden. Es eignet sich sowohl für Ende-zu-Ende- als auch für abschnittsweise ("Hop-by-Hop") Verschlüsselung.

Authentizität und Integrität

Authentizität und Integrität von RTP-Nachrichten können in SRTP mittels der Funktion HMAC-SHA1 in Kombination mit einem entsprechenden Sitzungsschlüssel gesichert werden. Dabei beträgt die empfohlene Länge der übertragenen Prüfsumme 80 Bit. Demnach muss die 160 Bit lange Prüfsumme aus HMAC-SHA1 auf 80 Bit reduziert werden. Diese Anpassung verringert zwar die Übertragungsgröße von SRTP-Paketen, schwächt aber den Integritätsschutz der Nachrichten. Daher sollte diese Anpassung nur in Ausnahmefällen aktiviert werden. Alternativ können auch Funktionen verwendet werden, die auf anderen anerkannten Hash-Algorithmen basieren. Für die Auswahl ist zu beachten, dass in einigen verbreiteten Hash-Algorithmen kryptographische Schwächen entdeckt wurden (siehe auch M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens ). Die Auswahl der Hash-Funktion ist zu begründen und dokumentieren.

Der gleiche Sicherheitsmechanismus ist auch für SRTCP vorgesehen.

SRTP erlaubt eine schwächere Authentisierung (z. B. 32 Bit) beziehungsweise gar keine Authentisierung von Nachrichten für solche Anwendungen, bei denen es unwahrscheinlich ist, dass der Angreifer eine verschlüsselte Nachricht so manipulieren kann, dass eine spätere Entschlüsselung eine sinnvolle Nachricht liefern wird. Wenn möglich, sollte die schwächere Authentisierung für RTP-Pakete nicht verwendet werden. Für RTCP sollte bei erhöhten Sicherheitsanforderungen der oben beschriebene Schutz mittels HMAC-SHA1-Prüfsumme aktiviert werden.

Schutz gegen Replay-Angriffe (Wiedereinspielen von Nachrichten)

SRTP bietet Schutz gegen Replay-Angriffe, bei denen ein Angreifer abgefangene RTP- oder RTCP-Pakete speichert und diese später erneut verschickt, um unter anderem Denial of Service Angriffe durchzuführen. Um das Wiedereinspielen von Nachrichten verhindern zu können, muss ein Integritätsschutz und Nachrichten-Authentisierung vorhanden sein. Der Empfänger von SRTP-Paketen führt dann eine so genannte Replay-Liste, die Kennzahlen von vorher empfangenen authentischen Paketen enthält.

Die maximal mögliche Anzahl der gespeicherten Kennzahlen muss vorher festgelegt werden. Beim Empfang eines neuen Pakets wird diese Liste auf Übereinstimmungen untersucht, und die wiederholten Pakete werden verworfen. Bei IP-Telefonen, die einen geringeren Speicher besitzen, ist die Länge der Replay-Liste ein Sicherheitsparameter, der im Fall von erhöhten Sicherheitsanforderungen berücksichtigt werden sollte. Der Umfang der Replay-Liste ist größtmöglich auszuwählen und die Entscheidung ist zu dokumentieren.

Schlüsselmanagement mit MIKEY

MIKEY (Multimedia Internet KEYing) beschreibt das Schlüsselmanagement für die Echtzeit-Multimedia-Kommunikation und ermöglicht den Austausch von Schlüsseln sowie weiteren Sicherheitsparametern zwischen den Teilnehmern. In VoIP kann MIKEY für den Austausch des Masterschlüssels und weiterer Sicherheitsparameter benutzt werden, um eine sichere SRTP-Übertragung zwischen den Endgeräten zu ermöglichen.

MIKEY ist unabhängig vom darunterliegenden Signalisierungsprotokoll, wie H.323 oder SIP. Zudem unterstützt MIKEY einen parallelen Austausch von Schlüsseln und Sicherheitsparametern für unterschiedliche Kommunikationssitzungen und Kommunikationsprotokolle. Demnach ist es möglich, RTP- und RTCP-Verbindungen getrennt voneinander abzusichern. Mit dem Bündelungskonzept von Kommunikationssitzungen erlaubt es MIKEY, einen gemeinsamen Masterschlüssel für mehrere parallele Sitzungen zu benutzen. Somit können z. B. VoIP-Konferenzen effizienter abgesichert werden.

Falls der Einsatz von VoIP mit Hilfe kryptographischer Mechanismen abgesichert werden soll, müssen die von den VoIP-Systemen unterstützten Verfahren für den Schlüsselaustausch in Erfahrung gebracht werden. Von diesen Verfahren ist ein geeignetes Verfahren festzulegen und die getroffene Wahl ist zu dokumentieren.

Prüffragen:

  • Sind die Gründe für beziehungsweise gegen den Einsatz von SRTP dokumentiert?

  • Bei Einsatz von SRTP : sind die sicherheitsrelevanten Optionen der Implementierung des Protokolls dokumentiert?

Stand: 13. EL Stand 2013