9.5. Integrity of the RTP payload and header (Integrität der RTP-Nutzlast und des Headers)
9.5. Integrity of the RTP payload and header (Integrität der RTP-Nutzlast und des Headers)
SRTP-Nachrichten unterliegen Angriffen auf ihre Integrität und Quellenidentifikation, und diese Risiken werden in Abschnitt 9.5.1 diskutiert. Um sich gegen diese Angriffe zu schützen, SOLLTE jeder SRTP-Stream durch HMAC-SHA1 [RFC2104] mit einem 80-Bit-Ausgabe-Tag und einem 160-Bit-Schlüssel oder einem Message Authentication Code mit gleichwertiger Stärke geschützt werden. Secure RTP SOLLTE NICHT ohne Nachrichtenauthentifizierung verwendet werden, außer unter den in diesem Abschnitt beschriebenen Umständen. Es ist wichtig zu beachten, dass Verschlüsselungsalgorithmen, einschließlich AES Counter Mode und f8, keine Nachrichtenauthentifizierung bieten. SRTCP DARF NICHT mit schwacher (oder NULL) Authentifizierung verwendet werden.
SRTP KANN mit schwacher Authentifizierung (z.B. einem 32-Bit-Authentifizierungs-Tag) oder ohne Authentifizierung (dem NULL-Authentifizierungsalgorithmus) verwendet werden. Diese Optionen ermöglichen die Verwendung von SRTP zur Bereitstellung von Vertraulichkeit in Situationen, in denen
- schwache oder keine Authentifizierung ein akzeptables Sicherheitsrisiko ist, und
- es unpraktisch ist, starke Nachrichtenauthentifizierung bereitzustellen.
Diese Bedingungen werden unten und in Abschnitt 7.5 beschrieben. Beachten Sie, dass beide Bedingungen erfüllt sein MÜSSEN, damit schwache oder keine Authentifizierung verwendet werden kann. Die mit der Ausübung der schwachen oder Null-Authentifizierungsoptionen verbundenen Risiken müssen vor ihrer Verwendung für eine bestimmte Anwendung oder Umgebung durch ein Sicherheits-Audit unter Berücksichtigung der in Abschnitt 9.5.1 diskutierten Risiken berücksichtigt werden.
Schwache Authentifizierung ist akzeptabel, wenn die RTP-Anwendung so beschaffen ist, dass die Auswirkung eines kleinen Anteils erfolgreicher Fälschungen vernachlässigbar ist. Wenn die Anwendung zustandslos ist, ist die Auswirkung eines einzelnen gefälschten RTP-Pakets auf die Dekodierung dieses bestimmten Pakets beschränkt. Unter dieser Bedingung MUSS die Größe des Authentifizierungs-Tags sicherstellen, dass nur ein vernachlässigbarer Anteil der vom SRTP-Empfänger an die RTP-Anwendung übergebenen Pakete Fälschungen sein können. Dieser Anteil ist vernachlässigbar, wenn ein Angreifer, auch wenn er die Kontrolle über die gefälschten Pakete erhält, keine signifikante Auswirkung auf die Ausgabe der RTP-Anwendung haben kann (siehe Beispiel in Abschnitt 7.5).
Schwache oder keine Authentifizierung KANN akzeptabel sein, wenn es unwahrscheinlich ist, dass ein Angreifer den Geheimtext so modifizieren kann, dass er zu einem verständlichen Wert entschlüsselt wird. Ein wichtiger Fall ist, wenn es für einen Angreifer schwierig ist, die RTP-Klartextdaten zu erhalten, da bei vielen Codecs ein Angreifer, der das Eingangssignal nicht kennt, das Ausgangssignal nicht kontrolliert manipulieren kann. In vielen Fällen kann es für den Angreifer schwierig sein, den tatsächlichen Wert des Klartexts zu bestimmen. Beispielsweise könnte ein verstecktes Abhörgerät erforderlich sein, um ein Live-Audio- oder Videosignal zu kennen. Das Signal des Angreifers muss eine Qualität haben, die der des angegriffenen Signals entspricht oder diese übertrifft, da der Angreifer sonst nicht genügend Informationen hätte, um dieses Signal mit dem vom Opfer verwendeten Codec zu codieren. Die Klartext-Vorhersage kann auch besonders schwierig für eine interaktive Anwendung wie einen Telefonanruf sein.
Schwache oder keine Authentifizierung DARF NICHT verwendet werden, wenn die RTP-Anwendung Daten-Weiterleitungs- oder Zugriffskontrollentscheidungen basierend auf den RTP-Daten trifft. In einem solchen Fall kann ein Angreifer möglicherweise die Vertraulichkeit untergraben, indem er den Empfänger veranlasst, Daten an einen Angreifer weiterzuleiten. Siehe Abschnitt 3 von [B96] für ein reales Beispiel solcher Angriffe.
Null-Authentifizierung DARF NICHT verwendet werden, wenn ein Replay-Angriff, bei dem ein Angreifer Pakete speichert und sie dann später in der Sitzung wiedergibt, eine nicht vernachlässigbare Auswirkung auf den Empfänger haben könnte. Ein Beispiel für einen erfolgreichen Replay-Angriff ist das Speichern der Ausgabe einer Überwachungskamera für einen Zeitraum, gefolgt von der Einspeisung dieser Ausgabe in die Überwachungsstation, um die Überwachung zu vermeiden. Verschlüsselung schützt nicht vor diesem Angriff, und Nicht-Null-Authentifizierung ist ERFORDERLICH, um ihn zu besiegen.
Wenn existenzielle Nachrichtenfälschung ein Problem ist, d.h. wenn die Genauigkeit der empfangenen Daten von nicht vernachlässigbarer Bedeutung ist, DARF Null-Authentifizierung NICHT verwendet werden.